Гольдштейн Б.С. Сетевое Взаимодействие - Электронный Учебник

Б.С.
Гольдштейн
СПбГУТ им. проф. М.А. Бонч-Бруевича
СЕТЕВОЕ ВЗАИМОДЕЙСТВИЕ
(ЭЛЕКТРОННЫЙ УЧЕБНИК)
Санкт-Петербург, 2008
Предисловие..............................................................................................................4
Часть 1. Сетевые архитектуры, протоколы, сетевое взаимодействие...........7
1.1. Основные понятия телефонной сигнализации........................................7
1.2. Элементы межстанционной сигнализации..............................................9
1.3. Эволюция межстанционной сигнализации.............................................12
1.4. Глобальная информационная инфраструктура....................................14
Литература к части 1...............................................................................................15
Часть 2. Эволюция протоколов сетевого взаимодействия в ТфОП...........16
2.1. Сигнализация по выделенным сигнальным каналам...........................16
2.2. Многочастотная сигнализация................................................................22
Литература к части 2...............................................................................................29
Часть 3. Сетевая общеканальная сигнализация №7......................................30
3.1. Предпосылки общеканальной сигнализации.........................................30
3.2. Принципы сети ОКС7...............................................................................33
3.3. Стек протоколов........................................................................................37
3.4. Подсистема переноса сообщений MTP..................................................40
3.4.1. Уровень 1................................................................................................40
3.4.2. Уровень 2................................................................................................40
3.4.3. Уровень 3................................................................................................48
3.5. Подсистема управления сигнальными соединениями SCCP..............55
3.6. Подсистема средств транзакций ТС.......................................................58
3.7. Подсистема ISUP......................................................................................63
3.8. Протокол интеллектуальной сети INAP..................................................67
3.9. ОКС7 поверх IP.........................................................................................69
3.10. Тестирование ОКС7..................................................................................76
3.10.1. Аттестационное тестирование................................................................77
3.10.2. Тестирование производительности........................................................81
3.10.3. Тестирование совместимости.................................................................81
3.10.4. Тестирование взаимодействия................................................................82
3.10.5. Регрессионное тестирование..................................................................83
3.10.6. Функциональное тестирование...............................................................83
3.11. Сетевой мониторинг ОКС7.......................................................................83
3.12. Заключение части 3..................................................................................96
Литература к части 3.............................................................................................97
Часть 4. Телекоммуникационные протоколы сетей сотовой связи
1
2G, 2.5G, 3G.............................................................................................98
4.1. Сетевое взаимодействие в сотовых сетях.............................................98
4.2. Модель протокола МАР..........................................................................100
4.3. Интерфейсы А, В, Аbis...........................................................................102
4.4. Обновление местоположения с помощью MAP..................................104
4.5. Входящий вызов в СПС из ТфОП.........................................................107
4.6. Исходящий вызов из СПС в ТфОП.......................................................110
Литература к части 4...........................................................................................111
Часть 5. Сетевое взаимодействие при предоставлении услуг
Интеллектуальной сети.......................................................................112
5.1. Эволюция услуг в ТфОП........................................................................112
5.2. Услуги Интеллектуальной сети..............................................................115
5.3. Подход компьютерной телефонии........................................................128
5.4. Услуги ТфОП и IP-сетей.........................................................................130
5.5. Конвергенция сетей и услуг связи.........................................................138
5.6. Заключение.............................................................................................141
Часть 6. Сетевое взаимодействие в NGN.......................................................141
6.1. Softswitch.................................................................................................141
6.2. Системы сигнализации..........................................................................143
6.3. Консорциум IPCC....................................................................................146
6.4. Эталонная архитектура Softswitch........................................................147
6.4.1. Транспортная плоскость........................................................................147
6.4.2. Плоскость управления обслуживанием вызова и сигнализации.......150
6.4.3. Плоскость услуг и приложений..............................................................150
6.4.4. Плоскость эксплуатационного управления..........................................151
6.5. Основы протокола SIP...........................................................................151
6.6. Архитектура сети SIP..............................................................................157
6.7. Структура сообщений SIP......................................................................163
6.8. Команды (запросы).................................................................................167
6.9. Ответы.....................................................................................................172
6.10. Сценарии сеансов связи........................................................................177
6.10.1. Алгоритм установления соединения с участием сервера
перенаправления..............................................................................................178
6.10.2. Алгоритм установления соединения с участием прокси-сервера...180
6.11 Н.323 в процессе эволюции IP-телефонии..........................................181
6.12. Архитектура и основные устройства сети Н.323.................................182
6.12.1. Терминал Н.323....................................................................................183
6.12.2. Шлюз H.323...........................................................................................184
6.12.3. Привратник............................................................................................184
6.13. Протоколы сетевого взаимодействия Н.323.........................................185
Список сокращений..........................................................................................186
2
Предисловие
В электронном учебнике рассмотрен один из важнейших
аспектов современных инфокоммуникационных сетей – сетевое
(межсетевое) взаимодействие - протоколы и интерфейсы,
позволяющие поддерживать соединения между пользователями и
осуществлять иные виды взаимодействия современных
телекоммуникационных сетей и систем. Курс содержит шесть частей.
Первая часть курса посвящена сетевым архитектурам,
протоколам, принципам сетевого взаимодействия: понятию сетевого
взаимодействия; эволюции систем сигнализации телефонных сетей
связи общего пользования (ССОП); основам протоколов TDM- и IP-
коммуникаций, проблемам взаимоувязанности Единой сети
электросвязи (ЕСЭ); модели глобальной информационной
инфраструктуры GII, протоколам и универсальным интерфейсам сети
доступа (AN) и транспортной сети (CN).
Вторая часть посвящена эволюции протоколов сетевого
взаимодействия в сетях фиксированной телефонной связи.
Рассматриваются программно-аппаратные средства сигнализации в
телефонных сетях связи общего пользования, принципы
сигнализации по двум выделенным сигнальным каналам (2bitCAS);
методы и средства адресной и линейной сигнализации, определение
номера вызывающего абонента и принципы учета для начисления
платы за услуги связи (metering for charging), SDL-спецификации
обслуживания входящего, исходящего и входящего междугородного
вызовов, приоритет междугородного вызова, привязка к физическому
уровню.
Третья часть является продолжением части 2 и посвящена
общеканальной сигнализации, стеку протоколов ОКС7 (SS7),
протоколам MTP, ISUP, SCCP, INAP, проблемам SS7 поверх IP,
рабочей группе SIGTRAN, средствам тестирования и мониторинга.
В четвертой части описываются телекоммуникационные
протоколы сетей мобильной связи поколений 1G, 2G, 2.5G, 2.75G, 3G
3
и 4G; основы сетевого взаимодействия в сетях подвижной связи
(СПС), принцип хэндовера; сетевое взаимодействие при роуминге;
протокол МАР стека ОКС7; сетевое взаимодействие в TDM-сетях
фиксированной и подвижной связи; сценарии для разных сетевых
взаимодействий.
Пятая часть описывает сетевое взаимодействие при
предоставлении услуг Интеллектуальной сети: архитектура
Интеллектуальной сети (IN), международные стандарты в области IN,
взаимодействие SSP и SCP; протокол INАР стека ОКС7; cетевое
взаимодействие при предоставлении услуг FreePhone, Televoting.
Ключевая шестая часть начинается с рассмотрения основ
сетевых архитектур сетей следующего поколения NGN (Next
Generation Networks). Там обсуждаются взаимодействие сетей Н.323
и SIP, функциональные возможности Softswitch и первые
международные стандарты в области NGN, рекомендации ITU-T
серии Y, архитектура NGN, стек протоколов Н.323, понятия шлюза и
гейткипера, организация конференций, протокол SIP, сетевое
взаимодействие H.323 и SIP, описание протоколов управления
медиашлюзами MGCP, MEGACO/H.248. Завершают часть 6 разделы,
посвященные тестированию протоколов сетевого взаимодействия
NGN.
Названные выше аспекты тестирования сетевого
взаимодействия составляют основу лабораторных работ по данному
курсу, которые проводятся на базе интерактивного учебного
комплекса СОТСБИ-У.
Учебник адресован магистрантам, изучающим сетевое
взаимодействие. Курс может быть полезен читателям и в качестве
введения в современные сетевые протоколы и в проблемы
тестирования взаимодействия инфокоммуникационных сетей.
4
Часть 1. Сетевые архитектуры, протоколы, сетевое
взаимодействие
Понятие сетевого взаимодействия; эволюция систем
сигнализации телефонных сетей связи общего пользования
(ССОП); протоколы TDM- и IP-коммуникаций, проблемы
взаимоувязанности единой сети электросвязи (ЕСЭ); модель
глобальной информационной инфраструктуры GII, протоколы и
универсальные интерфейсы сети доступа (AN) и транспортной
сети (CN).
1.1. Основные понятия телефонной сигнализации

Рассмотрение сетевого взаимодействия начнем наиболее
распространенных и традиционных сетей связи – телефонных сетей
общего пользования (ТфОП). И хотя сегодня эти сети традиционной
телефонной связи характеризуются лишающим энтузиазма термином
POTS (Plain Old Telephone Services), межстанционная сигнализация в
них практически является первым средством сетевого
взаимодействия в телекоммуникациях.
Согласно определению Международного союза электросвязи ITU
сигнализация – обмен информацией (при автоматической связи),
специально предназначенной для установления и завершения
соединения, а также для управления обслуживанием вызовов и
сетью. В технической литературе можно найти менее строгие
определения, эмоциональнее выделяющие роль, которую система
сигнализации играет в сетях электросвязи. В частности, Ричард
Мантерфильд в книге о сигнализации в электросвязи привел
следующие слова: "Без сигнализации сети связи были бы
безжизненными и пассивными совокупностями компонентов.
Сигнализация – это связка, которая обеспечивает динамизм и
живость, превращая инертные компоненты в одушевленную,
сплоченную и мощную среду". В ряде публикаций роль сигнализации
сравнивают с функциями, которые выполняет нервная система
человека.
Основная цель сетевого взаимодействия в ТфОП – установление
соединений между абонентами. Имеется три аспекта установления
5
соединения: во-первых, АТС должна распознать принимаемый ею
телефонный номер, чтобы направить вызов в абонентскую линию
адресата или к следующей станции в цепочке участвующих в
соединении станций; во-вторых, АТС должна выбрать свободный
канал в нужном направлении и информировать об этом канале
следующую станцию в цепочке; в-третьих, станции должны проверять
этот канал, вести его мониторинг и, наконец, освободить его по
окончании связи. Выполнение этих функций, относящихся к каналу,
требует обмена информацией между станциями, и этот обмен в
телефонных сетях как раз и есть сетевая сигнализация.
Первоначально процедура сигнализации была намного ближе к
исходному значению слова – блоки электромеханических АТС
декадно-шаговой или машинной системы, участвующие в
установлении телефонного соединения, обменивались
электрическими сигналами. Сигнальная информация для конечного
пользователя (абонента) предоставлялась (и продолжает
предоставляться сегодня) путем посылки ему акустических
(тональных) сигналов разных частот и разной длительности. Да и в
самих электромеханических АТС сигнализация ненамного
отличалась от того, что происходит на абонентских линиях при
снятии трубки, при наборе номера на дисковом телефонном
аппарате или при нажатии кнопок на тастатуре: телефонные станции
обмениваются линейными или акустическими сигналами по той же
линии, по которой разговаривают абоненты. Сигнализация этого типа
называется внутриполосной сигнализацией или, более развернуто,
сигнализацией в полосе частот телефонного канала, и она
эксплуатируется сегодня на большей части межстанционных
соединительных линия Единой сети электросвязи (ЕСЭ РФ).
1.2. Элементы межстанционной сигнализации

В этом параграфе мы сосредоточимся, преимущественно, на
межстанционной сигнализации, важность которой постоянно
6
увеличивается с того исторического момента, когда городские
телефонные сети стали состоять более чем из одной телефонной
станции. Последним усилием, направленным на предотвращение
межстанционной сигнализации, был тщательный отбор в
телефонные операторы барышень высокого роста (способных
дотянуться до дальних углов коммутаторных досок) и с громким
голосом (информация о вызываемом абоненте между первым и
четвертым коммутаторами, т.е. из конца в конец коммутаторного зала
первой петербургской телефонной станции, сообщалась устно). Этих
мер хватило ненадолго, и сегодня подавляющее большинство
соединений в телефонной сети проходит через несколько узлов и
станций (рис. 3.1).
Абонент А АТС А Абонент Б
Сигнализация по а.л.
СОЕДИНЕНИЕ
a)
Абонент А АТС А АТС Б Абонент Б
Сигнализация по с.л.
Сигнализация по с.л.
СОЕДИНЕНИЕ
б)
Рис. 1.1. Упрощенные сценарии установления соединения между
абонентами одной АТС (а) и с использованием
межстанционной сигнализации (б)
7
Кроме того, для организации одного соединения часто
используется множество разных систем сигнализации. В качестве
примера можно представить себе петербургского абонента сети GSM,
включающего свой мобильный телефон, скажем, в Майями и через
несколько секунд принимающего из своего же дома в Санкт-
Петербурге вызов, поступивший от принадлежащего ему
стационарного телефона, включенного в одну из координатных
станций Петербургской телефонной сети. Сигнальная информация,
необходимая для обслуживания такого вызова, переносится в сотнях
сигнальных сообщений между самыми разными узлами и станциями
международной и национальных сетей.
Функционирующие сегодня в отечественных ТфОП
межстанционные протоколы начинались с простых систем
сигнализации. В эволюции систем межстанционной сигнализации
можно выделить три фазы:
- импульсная сигнализация;
- многочастотная сигнализация ;
- общеканальная сигнализация.
Сигнализация двух первых типов до сих пор служит средством
взаимодействия АТС двух третей всепланетной ТфОП. То же
соотношение справедливо и для Единой сети электросвязи России.
Эти протоколы рассматриваются и в настоящем параграфе.
Последняя, третья фаза эволюции межстанционной сигнализации
началась одновременно с введением программно-управляемых
узлов коммутации. Сигнализация, представляющая собой
последовательность электрических сигналов, превратилась в
протоколы передачи по специальному каналу данных, относящихся к
большому количеству телефонных каналов, откуда, собственного
говоря, и появилось название «общеканальная сигнализация»,
которой посвящена отдельная глава.
8
Для межстанционной сигнализации всех типов справедливо
следующее (еще одно) определение: сигнализация – это обмен
между сетевыми элементами служебной информацией, на основе
которой сеть обеспечивает создание, сопровождение и разрушение
соединений, используемых ею для предоставления своим абонентам
услуг связи. Отметим попутно, что в сети с коммутацией каналов
(каковой является, в частности, телефонная сеть) сетевые ресурсы,
из которых составляется соединение, закрепляются за ним на все
время пользования услугой связи и не могут быть использованы в
других соединениях.
Системы сигнализации, рассматриваемые в этом параграфе, как
раз и были созданы для сетей с коммутацией каналов. Передача
данных появилась в начале 70-х годов и обусловила создание сетей,
в которых информация пользователей передается в виде коротких
пакетов, перемежающихся периодами «молчания». Поскольку паузы
между пакетами одного информационного потока можно
использовать для передачи пакетов других информационных потоков,
отпала необходимость отводить одни и те же сетевые ресурсы в
безраздельное пользование какому-то одному потоку на все время
его существования. Следовательно, для предоставления услуги связи
сеть не должна создавать т.н. «физическое» соединение. Примером
такой сети является Интернет. Ее возможности используются и в
технологии IP-телефонии, рассмотрению сетевого взаимодействия
для которой посвящается часть 6.
1.3. Эволюция межстанционной сигнализации

Принципы используемых для сетевого взаимодействия
протоколов сигнализации связаны с принципами коммутации и
управления обслуживанием вызовов в коммутационных узлах и
станциях этих сетей, а также с техническими средствами организации
межстанционных соединительных линий. Возможные принципы
сетевого взаимодействия иллюстрируют сигнализация
9
непосредственно по телефонному каналу и сигнализация по
выделенным сигнальным каналам (ВСК), представленные на рис. 1.2
и 1.3, соответственно.
Разговорный канал
Cигнализация
Коммутация и Коммутация и
управление управление
АТС А АТС Б
Рис. 1.2. Сигнализация по телефонному каналу
Сигнализация
Коммутация
Рег/М
управление
Коммутация Сигнализация
Коммутация
Рег/М Рег/М
управление управление
АТС А АТС Б
Рис. 1.3. Сигнализация по выделенному сигнальному каналу (ВСК)
Следующими этапом эволюции систем сигнализации является

общеканальная сигнализация №7 (рис. 1.4). Рассмотрение стека
протоколов сетевого взаимодействия ОКС7 начинается в части 3 и
продолжается в частях 4 и 5 этого курса.
10
Коммутация Коммутация
Управление Управление
АТС А АТС Б
Рис. 1.4. Общеканальная сигнализация №7
И, наконец, к следующему поколению сигнализации можно

отнести рассматриваемую в части 6 сигнализацию IP-телефонии
типа Н.323, MGCP или SIP, которая условно представлена на рис. 1.5
и в которой сигнализацию повторяют, в определенном смысле,
речевые пакеты.
Шлюз А Шлюз Б
Рис. 1.5. Сигнализация IP-телефонии
1.4. Глобальная информационная инфраструктура

Уточним место упомянутых выше протоколов сетевого
взаимодействия в сегодняшней глобальной телекоммуникационной
сети.
О том, что именно эти новые сетевые технологии коммуникации
все более и более превращают мир в подобие глобальной деревни
(The Global Village) было сказано Маршалом Маклюэном,
знаменитым автором «Галактики Гуттенберга» еще в 1968. По всей
видимости, именно оттуда произошел ключевой современный термин
11
глобальная информационная инфраструктура GII (Global
Information Infrastructure).
Сеть доступа Сеть доступа

Access Network Access Network
Абонент Б
Абонент А
Информационный
терминал абонента
Информационный
терминал абонента
Транспортная сеть связи
Core Network
Информационная Информационная
составляющая Телекоммуникационная составляющая составляющая
Рис. 1.6. Глобальная информационная инфраструктура GII

Именно сетевому взаимодействию в Core Network - сердцевине
изображенной на рис.1.6 структуре концепции GII – посвящен этот
курс. Вторая составляющая рис. 1.6 – сеть доступа AN (Access
Network) затрагивается в курсе лишь частично и заслуживает
отдельного рассмотрения.
Литература к части 1
1. Гольдштейн Б.С. Сигнализация в сетях связи. Том 1. – М.:
Радио и связь, 2005.
2. Кох Р., Яновский Г.Г. Эволюция и конвергенция в электросвязи. –
М.: Радио и связь, 2001.
3. Соколов Н.А. Беседы о телекоммуникациях. Монография в
четырех главах. –М.: Альварес Паблишинг, 2003 – 2004.
12
Часть 2. Эволюция протоколов сетевого
взаимодействия в ТфОП
Программно-аппаратные средства сигнализации в телефонных
сетях связи общего пользования, принципы сигнализации по двум
выделенным сигнальным каналам (2bitCAS); методы и средства
передачи адресной и линейной сигнализации, определение номера
вызывающего абонента и принципы учета для начисления платы
за услуги связи, SDL-спецификации обслуживания входящего,
исходящего и входящего междугородного вызовов.
2.1. Сигнализация по выделенным сигнальным каналам

Вернемся к рис. 1.2 из первой части. До появления цифровых
АТС с программным управлением все сигналы передавались по тому
же тракту, что и речь. Именно этот способ и назывался
внутриполосной сигнализацией (in-band). По мере эволюции
межстанционных соединительных линий распространился способ
сигнализации по выделенным сигнальным каналам (ВСК),
ассоциированным с разговорными каналами, что хорошо отражается
английским названием этого способа – channel associated signaling
(CAS). Выделенными сигнальными каналами могут являться
определенные биты в 16-м временном канале ИКМ-тракта или,
например, частотные каналы 2600 Гц и 3825 Гц, но в любом варианте
применение такой, непосредственно связанной с разговорным
каналом сигнализации приводит к недостаточно эффективному
использованию межстанционных соединительных линий. При вызове,
например, из Владивостока в Калининград нужные каналы
занимаются по всей сети заранее, до начала разговора, для
передачи цифр номера и на время посылки вызова вызываемому
абоненту. К тому же, по разным оценкам, от 20 до 35% вызовов не
завершаются разговором вследствие занятости абонента, перегрузки
в сети или из-за того, что вызываемый абонент не отвечает на вызов.
Таким образом, каналы, которые могли бы использоваться для
передачи полезной информации, занимаются для сигнализации, в
13
том числе, и при незавершённых соединениях, доля которых часто
составляет около 40%.
Если отвлечься от средств общения телефонных барышень, то
можно считать, что телефонная сигнализация появилась в 1890 году
как составная часть изобретенной Алманом Строуджером из Канзас-
Сити автоматической телефонной станции, которая была в состоянии
принимать телефонный номер в виде импульсного набора. В течение
следующих ста лет развитие систем сигнализации происходило
вместе с эволюцией коммутационного оборудования. Существовал
довольно длительный период, с 1890 до 1976 года, когда все системы
сигнализации характеризовались следующими общими свойствами:
 они были ориентированы на обычные телефонные услуги POTS;
 они обеспечивали создание и разрушение соединения;
 они предусматривали передачу сигналов либо по тем же каналам,
по которым передавалась речь, либо по выделенным сигнальным
каналам, каждый из которых был закреплен за определенным
речевым каналом.
Более строго, выделенный сигнальный канал, ВСК,
представляет собой ресурс межстанционного тракта передачи
(частоту в аналоговой системе передачи или временной интервал в
системе ИКМ), ассоциированный (поставленный в однозначное
соответствие) с определенным разговорным каналом этого тракта
передачи.
В цифровых ИКМ-системах передачи теоретически имеется
возможность организовать для каждого речевого канала от одного до
четырех ВСК. Реально же используется сигнализация по одному
(1ВСК) или по двум (2ВСК) выделенным сигнальным каналам. В
системе ИКМ-30 (2048 Кбит/с) биты 0, 1 шестнадцатого канального
интервала (16КИ) могут переносить сигнальную информацию для
разговорных каналов с 1 по 15, а биты 4, 5 – сигнальную
информацию для разговорных каналов с 16 по 30.
14
В аналоговых системах передачи с частотным разделением
каналов имеется возможность организовать один ВСК на частоте вне
разговорного спектра, например, на частоте 3825 Гц или 4000 Гц.
Возможна организация второго ВСК в разговорном спектре частот,
например, на частоте 2600 Гц.
К системам сигнализации по ВСК относятся следующие
протоколы: сигнализация 1ВСК для универсальных СЛ двустороннего
использования (индуктивный код), сигнализация 1ВСК для
односторонних СЛ с раздельными пучками СЛ и СЛМ (код «Норка»),
сигнализация 2ВСК для односторонних СЛ с раздельными пучками
СЛ и СЛМ, сигнализация 2ВСК для универсальных СЛ двустороннего
использования.
Сигнализация 1ВСК (индуктивный код) используется в сельских
сетях, где вследствие высокой стоимости линейных сооружений на
участках между ОС-УС и ОС-ЦС рекомендуется использовать общие
пучки местных и междугородных СЛ (универсальных СЛ) в
двустороннем режиме, то есть когда одна и та же линия может
использоваться как входящая и как исходящая.
Сигнализация 1ВСК для односторонних СЛ с раздельными
пучками СЛ и СЛМ (код «норка») используется при установлении
соединений как в городских сетях, так и на участках сельских сетей
ОС-УС, ОС-ЦС, УС-ЦС, ЦС-АМТС.
Сигнализация 2ВСК для универсальных СЛ двустороннего
использования применяется в сельских телефонных сетях на
участках ОС-УС, УС-ЦС. В зависимости от типа станционных
комплектов соединительных линий этот протокол может быть
реализован двумя способами:
Первый способ. Первый ВСК организуется либо в аналоговой
системе передачи на частоте вне разговорного спектра, либо в 0 или
16 канальном интервале цифровой системы передачи, а второй ВСК
– на частоте 2600 Гц в разговорном канале.
15
Второй способ. Оба сигнальных канала организуются в 0 или 16
канальном интервале цифровой системы передачи.
Сигнализация 2ВСК для односторонних СЛ с раздельными
пучками СЛ и СЛМ используется в городских телефонных сетях при
организации связи между декадно-шаговыми и координатными АТС,
а также между цифровыми и электромеханическими АТС.
Логика сигнализации 2ВСК лучше всего иллюстрируется
сценариями, приведенными на рис. 2.1, где в скобках указаны
значения битов в обоих сигнальных каналах для каждого сигнала и
состояния. В сценарии на рис. 2.1а показано, что в исходном
состоянии со стороны исходящей АТС в соединительную линию
передается сигнал «Исходное состояние» (11), а со стороны
входящей АТС – сигнал «Контроль исходного состояния» (01). Когда
исходящая АТС инициирует установление соединения, сигнал
«Исходное состояние» (11) сменяется сигналом «Занятие» (10), в
ответ на который от входящей АТС поступает сигнал
«Подтверждение занятия» (11), после чего система переходит в
предответное состояние, в котором оба сигнала продолжают
присутствовать. Если номер вызываемого абонента передается
декадным способом, то сигнал «Занятие» (10) сменяется поочередно
сигналами «Импульс» (00) и «Пауза» (10) или «Межцифровой
интервал» (10). Различие между паузой и межцифровым интервалом
заключается только в их длительности. При местном вызове
максимальная длительность паузы составляет 150 мс, а если пауза
оказывается длиннее, сигнал (10) идентифицируется как
«Межцифровой интервал». В рассматриваемом сценарии «а»
(абонент Б свободен, первым дает отбой абонент А), когда абонент Б
снимает трубку, от входящей АТС поступает сигнал «Ответ» (10),
после чего система переходит в разговорное состояние. При отбое
абонента А исходящая АТС передает сигнал «Разъединение» (11),
ответом на который служит сигнал «Контроль исходного состояния»
(01), и система переходит в исходное состояние.
16
Исходящая АТС Входящая АТС
(01) Исходное состояние (11)
Занятие (10)
Т1 (11) Подтверждение занятия

Т1
(11) Предответное состояние (10)
Т2
Импульс (00)
Т3
Пауза (10)
Т4
Межсерийный интервал (10)
Т5
(10) Ответ
(10) Состояние разговора (10)
Разъединение (11)
(01) Контроль исходного состояния
Т1 - время ожидания сигнала подтверждения Т3 - время передачи импульса, 50 мс

занятия, 1 с Т4 - время передачи паузы, 50 мс
Т2 - время после приема сигнала Т5 - время передачи межсерийного
подтверждения занятия и до начала интервала, 700 мс
трансляции номера, 400 мс
Рис. 2.1. Сценарии обмена сигналами (местный вызов)

а) абонент свободен, отбой вызывающего абонента
Сценарий «б» отличается от предыдущего тем, что в состоянии

разговора первым дает отбой вызываемый абонент Б. Это приводит к
передаче сигнала «Отбой Б» (00) в сторону исходящей АТС. В ответ
на этот сигнал исходящая АТС передает сигнал «Разъединение» (11),
получает сигнал «Контроль исходного состояния» (01) и переходит в
исходное состояние.
Сценарий «в» – случай занятости вызываемого абонента. В этом
случае, обработав номер абонента Б, входящая АТС передает сигнал
«Занятость» (00), в ответ на который получает сигнал
«Разъединение» (11), передает сигнал «Контроль исходного
состояния» и переходит в исходное состояние.
17
Занятие (10)

Т1
Т2
Импульс (00)
Т3
Пауза (10)
Т4
Т5
(10) Ответ
(10) Состояние разговора (10)
(00) Отбой

б) абонент Б свободен, отбой вызываемого абонента
18
Занятие (10)

Т1

Т2
Импульс (00)
Т3
Пауза (10)
Т4
Т5
(00) Б занят

в) абонент Б занят, разъединение
Несколько более сложны сценарии, которые имеют место при

входящем междугородном вызове, когда предусматривается
возможность вмешательства телефонистки в разговор вызываемого
абонента Б, если он занят местным соединением. Эти сценарии
рассмотрены в [т1].
2.2. Многочастотная сигнализация

О недостатках рассмотренной выше сигнализации по 2 ВСК мы
поговорим ниже при обсуждении ОКС7, а здесь лишь отметим, что в
дополнение к неэффективному занятию станционных устройств,
сигнализация с декадным набором номера замедляет и сам процесс
19
установления соединения, включающий в себя трансляцию номера с
одной АТС на другую и ожидание момента, когда абонент А получит
связь с абонентом Б. За всё это время, вплоть до начала разговора
между абонентами, плата за услуги сети не начисляется, что, к
сожалению, приводит к тому, что операторы не получают никаких
доходов от использования абонентом дорогих сетевых ресурсов. К
тому же, такая «медлительность» сигнализации отчетливо
ощущается абонентами и вызывает у них раздражение.
Значительно ускорить этот процесс позволяет многочастотная
сигнализация. Используемые в ней сигнальные коды оценивают по
следующим показателям: возможное количество кодовых
комбинаций; время передачи кодовой комбинации; возможности
передачи сигналов по линиям разного типа (физическим и
уплотненным аналоговыми или цифровыми системами передачи);
сложность передающих и приемных устройств; дальность передачи;
помехоустойчивость; надежность и способность к обнаружению и
исправлению ошибок.
Каждая комбинация многочастотного кода состоит из двух или
более элементарных сигналов, имеющих разные частоты; чаще всего
используются многочастотные коды вида «n из m» (в АТСК,
например, применяются коды «2 из 5» и «2 из 6»), в которых для
образования элементарных сигналов используются m определенных
частот, а для образования каждой кодовой комбинации используются
n из них. Тот факт, что любая кодовая комбинация содержит одно и то
же количество частот, улучшает помехоустойчивость кода. Возможное
количество кодовых комбинаций в многочастотных кодах такого типа
определяется количеством сочетаний
m!
C mn 
n! m  n ! .
В частности:
20
5!
C 52   10
для кода "2 из 5" 2! 5  2! ,
6!
C 62   15
для кода "2 из 6" 2! 6  2 ! .
Многочастотные коды «2 из 5» и «2 из 6» относятся к
самопроверяющимся, поскольку они позволяют с помощью
несложной схемы выявить на приемной стороне ошибки, возникшие
при передаче (отсутствие одной из частот, присутствие более двух
частот). При необходимости можно запросить повторную передачу
комбинации, принятой с ошибкой. Это позволяет повысить
достоверность передачи. В многочастотном коде используются
частоты разговорного спектра, и потому этот код пригоден для
передачи сигналов по уплотненным линиям. В качестве сигнальных
используются частоты f0=700, f1=900, f2=1100, f4=1300, f7=1500,
f11=1700 Гц (индексы 0, 1, 2, 4, 7 и 11 подобраны так, чтобы их сумма
в каждой комбинации давала ту цифру, которую эта комбинация
обозначает; исключение составляет только цифра 0).
Показанная на рис. 2.2 передача кодовых комбинаций методом
«импульсный челнок» напоминает прямые и обратные движения
ткацкого челнока и происходит следующим образом. Вызывающее
устройство (например, регистр) подключается к вызываемому
устройству (например, к маркеру) и сигнализирует о своей готовности
передать информацию. Маркер посылает сигнал запроса, и в ответ
на него регистр передает некоторую часть информации. Затем от
маркера вновь поступает сигнал запроса (или сигнал подтверждения
приема), регистр передает следующую порцию информации и т. д.
Передав всю информацию, регистр освобождается. При таком
способе повышается достоверность передачи информации, но
возрастает и время ее передачи. Метод «импульсный челнок»
применяется в сетях сложной структуры. Он позволяет по-разному
передавать информацию, накопленную в регистре. В зависимости от
21
вида запроса, регистр может передать одну или несколько цифр
номера, номер полностью, повторно передать цифру, а также
перейти от одного способа передачи сигналов к другому.
Как видно на рис. 2.2, обмен сигналами начинается с сигнала
обратного направления. Почти на каждый сигнал обратного
направления следует ответный сигнал прямого направления.
Длительность сигнала составляет 455 мс. Интервал между приемом
и передачей – не менее 60 мс. Время ожидания очередного сигнала
на входящей АТС составляет 200-250 мс, на исходящей – 3.5-4 с.
Прямое
направление
Обратное
направление
Рис. 2.2. Регистровая сигнализация методом “импульсный челнок”
Кроме метода «импульсный челнок» для передачи регистровых

сигналов используются также методы «импульсный пакет» и
«безынтервальный импульсный пакет». Они применяются тогда,
когда необходимо передавать накопленную информацию с более
высокой скоростью, что обычно требуется при взаимодействии
местной АТС с АМТС.
При передаче сигналов методом «импульсный пакет»
накопленные кодовые комбинации передаются по одной команде
подряд одна за другой с интервалами, необходимыми для того, чтобы
приемное устройство успевало перестроиться на прием очередной
комбинации. В процессе обмена сигналами используются следующие
выдержки времени: Т1=505 мс – длительность передаваемых в
пакете импульсов и пауз между ними; Т2=10 с – время ожидания на
АТС запроса от АМТС после получения сигнала “Подтверждение
занятия”; Т3=3 с – время ожидания обратного сигнала после
передачи пакета.
Пакеты при вызовах разных типов имеют следующую структуру:
22
Междугородный вызов ABC abc xxxx Ka def xxxx “11” (19 цифр)
Вызов абонента зоновой сети “2” abc xxxx Ka def xxxx “11" (17 цифр)
Международный вызов “1” “0” n1…ni Ka def xxxx “11” (19-26 цифр)
Вызов оператора
международного коммутатора
“1” “9” L Ka def xxxx “11” (12 цифр)
междугородного коммутатора
с идентификацией номера
вызывающего абонента “1” “9” S Ka def xxxx “11” (11 цифр)
междугородного коммутатора
без идентификации номера
вызывающего абонента “1” S “11” (3 цифры)
Метод «безынтервальный импульсный пакет» используется в

процедуре автоматического определения номера вызывающего
абонента (АОН) и предусматривает передачу кодовых комбинаций
без интервалов между ними, что значительно уменьшает время
передачи. Разделение кодовых комбинаций на приемной стороне
основано на обнаружении изменения составляющих их частот. Если в
передаваемой последовательности кодовых комбинаций две или
несколько комбинаций подряд одинаковы, то все четные одинаковые
комбинации заменяются сигналом «Повторение» Например, если
требуется передать номер 55433336, то вместо второй из двух
идущих подряд «пятерок», как и вместо второй и четвертой из
четырех идущих подряд «троек», будет передан сигнал "Повторение".
Если обозначить этот сигнал символом х, то номер 55433336 будет
передан как 5х43х3х6.
Любая АТС телефонной сети общего пользования должна, во-
первых, «уметь» определять категорию и номер включенного в нее
телефона вызывающего абонента, чтобы иметь возможность
передать эту информацию по запросу вызванной стороны, и, во-
вторых, «уметь» запрашивать и принимать такую информацию от
встречной станции. АМТС или другая станция (узел), например, узел
спецслужб (УСС) или ступень распределения вызовов (СРВ),
запрашивает данные о категории и номере абонента с целью
23
начисления платы за услугу, а также для определения права
абонента пользоваться этой услугой. АТС может запрашивать
информацию АОН и в случае, если абонентом, к которому поступил
злонамеренный вызов, заказана услуга определения источника
такого вызова.
На АТС предусматривается возможность приема запроса и
передачи информации АОН на разных этапах установления
соединения, а именно:
 после занятия соединительной линии (в случае вызовов к
АМТС);
 при ожидании ответа;
 при ответе вызываемого абонента;
 во время разговора.
Передача информации АОН должна производиться при приеме
запроса – сигнала "Ответ", сопровождаемого частотным сигналом
500 Гц. Запрос может поступать многократно в любой фазе
соединения. Каждый запрос, начиная со второго, предваряется
сигналом «Снятие ответа», по которому соединение переводится в
предответное состояние.
Сигнал 500 Гц может поступить на АТС через 10-400 мс после
сигнала «Ответ». Минимальное время между двумя запросами
составляет 0.3±0.05 с; максимальное время фактически не
ограничено, однако при связи с АМТС оно не превышает 1.2±0.1 с.
Максимальное количество запросов при вызове АМТС – не более
трех (АМТС повторяет запрос после неудачной попытки определения
номера), при вызове местной АТС – не более двух, при вызовах
справочно-информационных, заказных и экстренных служб – не
ограничено.
Цикл передаваемой информации должен содержать одну цифру
категории и семь цифр номера вызывающего абонента, а также один
знак, отмечающий начало (конец) информации. В одном
24
«безынтервальном пакете» (т.н. «кодограмме АОН»), должно
содержаться не менее 13 знаков.
Порядок следования цифр в «безынтервальном пакете» должен
быть следующим:
 начало передачи (комбинация 13);
 цифра категории абонента;
 цифра единиц номера;
 цифра десятков номера;
 цифра сотен номера;
 цифра тысяч номера;
 цифра десятков тысяч (третья цифра индекса станции);
 цифра сотен тысяч (вторая цифра индекса станции);
 цифра миллионов (первая цифра индекса станции);
 начало передачи (комбинация 13).
Независимо от нумерации в местной телефонной сети (5-
значная или 6-значная) АТС должна всегда передавать информацию
АОН в виде семизначного зонового номера. Цифрами,
дополняющими индекс станции до трехзначного, могут быть 2 или 0.
Таким образом, информация АОН, передаваемая способом
«безынтервальный пакет», представляет собой последовательность
двухчастотных комбинаций кода «2 из 6», без пауз между ними.
Длительность передачи каждой комбинации равна 401 мс.
В начале параграфа отмечались недостатки декадного набора и
преимущества многочастотной сигнализации, однако и она не
лишена целого ряда недостатков. Помимо присущих любой
внутриполосной сигнализации ограничений информационного
содержания сигналов, быстродействия и помехоустойчивости, она не
исключает возможность имитации пользователями частотных
сигналов, что может обмануть оператора или нарушить работу сети.
Это же справедливо и в отношении АОН.
25
1. Гольдштейн Б.С. Системы коммутации. Учебник для
ВУЗов. 2-е издание, доп. и испр.//СПб.: BHV-2004.
2. Гольдштейн Б.С., Сибирякова Н.Г., Соколов А.В.
Сигнализация R1.5. Справочник// СПб.: BHV-2004.
26
Часть 3. Сетевая общеканальная сигнализация №7
Общеканальная сигнализация, стек протоколов ОКС7, перенос
транзакций МТР, протокол ISUP, протокол Интеллектуальной
сети INAP, протокол передачи информации для управления
потоками SCTP (Stream Control Transmission Protocol), рабочая
группа SIGTRAN, средства тестирования и мониторинга.
3.1. Предпосылки общеканальной сигнализации

В предыдущих разделах были рассмотрены системы
сигнализации, ассоциированной с каналом и известные в
отечественной литературе под названием сигнализация по
выделенным сигнальным каналам (ВСК) или под фольклорным
названием - R1.5, а в англоязычной литературе – под названием
Channel Associated Signaling (CAS).
С этими системами сигнализации никогда не было особенно
благополучно, а сегодня возникают проблемы, связанные с новыми
инфокоммуникационными услугами и технологиями. Помимо того, что
все эти системы сигнализации весьма медленные, и это вызывает
раздражение у абонентов, которые вынуждены ждать и слушать
почти бесполезные для них звуковые сигналы, они также позволяют
конечным пользователям – абонентам – имитировать те сигналы,
которые используют станции для обмена служебной информацией.
Для российских сетей связи примерами этого являются проблемы
подмены номеров АОН, анти-АОН, несанкционированного
вмешательства в разговор на правах телефонистки междугородной
связи, организация так называемых «вьетнамских» переговорных
пунктов и т.п.
Для повышения эффективности сетевого взаимодействия
потребовался другой тип сигнализации, который не использовал бы
полосу частот телефонного канала. Однако, канал в телефонной сети
ограничен полосой тональных частот, в связи с чем отсутствует
физическая возможность передавать по такому каналу частоты,
лежащие вне этой полосы а потому возникла потребность уже не во
внеполосной, а во внеканальной сигнализации. Было также
27
очевидно, что требовался значительно более широкий спектр
передаваемой сигнальной информации (характеристики
коммутируемых каналов связи, номера вызывающего и вызываемого
абонентов, биллинговая информация, роуминг мобильных абонентов
и т.д.), которая могла бы храниться и передаваться в той же форме,
которая используется при обработке данных. Возникновение
компьютерных сетей подсказало телефонистам подход, при котором
сигнальная информация кодируется в виде набора данных, для
обмена этими наборами используется отдельная сеть передачи
данных. Так возникла концепция общеканальной сигнализации.
Общеканальная сигнализация – это сигнализация,
предусматриваемая передачу сигналов по сигнальному каналу
общему для большой группы телефонных каналов, и не
использующая для этой цели ни один из них.
История развития общеканальной сигнализации начинается в
1968 году стандартизацией ОКС6 для аналоговых систем коммутации
с программным управлением, предусматривает, передачу сигнальной
информации со скоростью 2400 бит/сек. В 1972 году начались
первые исследования в направлении ОКС7, а в 1980 году появились
первые рекомендации по ОКС7 в Желтой книге МККТТ. Реальные
разработки выполнялись по спецификациям ОКС7 в Красной книге
(1984 г.) и Синей книге (1988 г.). По сегодняшним меркам, это -
удивительные темпы разработки, позволившие без суеты и спешки
продумать протоколы и сетевые концепции.
3.2 Принципы сети ОКС7

Итак, существует два принципа организации межстанционной
сигнализации в коммутируемых сетях связи. Один из них, принцип
ВСК, основан на том, что для обмена между станциями сигналами,
нужными для создания, поддержания и разрушения соединения, в
котором участвует определенный межстанционный канал,
используется ресурс, закрепленный именно за этим каналом. Другой
28
принцип основан на том, что для обмена между станциями
служебными сигналами используется сигнальный канал, общий для
некоторой группы межстанционных каналов и/или соединений. Этот
принцип по-английски называется CCS (Common Channel Signaling), а
по-русски – общеканальной сигнализацией.
В разные годы Международный консультативный комитет по
телеграфии и телефонии (МККТТ) разработал стандарты для
нескольких разных систем межстанционной сигнализации, присвоив
каждой из них свой порядковый номер. Системы с номерами от 1 до
5 устроены по принципу ВСК, а системы № 6 и № 7 – по принципу
общеканальной сигнализации. В системах №№ 1 – 5 существует
разделение сигналов на линейные и регистровые, а для их
передачи используются частоты из диапазона 300-3400 Гц (разные в
разных системах) или за верхней границей этого диапазона, но
меньше 4000 Гц. В системах №№ 6 и 7 такое разделение сигналов,
если и существует, то разве лишь по традиции, поскольку все без
исключения сигналы передаются одинаково – в виде сигнальных
сообщений – и воспринимаются одними и теми же устройствами. Обе
эти системы реализуются только на станциях с программным
управлением, а система № 7 – только в сетях с цифровыми
системами передачи.
Система сигнализации ОКС7 является универсальной в том
смысле, что она ориентирована на применение в телефонных сетях,
в сетях передачи данных, на стыках тех и других сетей с ISDN и в
самой ISDN, а также в сетях мобильной связи, в Интеллектуальной
сети и др. Функциональная архитектура ОКС7 является
многоуровневой, причем функции трех нижних уровней, которые
вместе обеспечивают перенос сигнальных сообщений от станции-
отправителя до станции-получателя, образуют платформу MTP
(Message Transfer Part – подсистему переноса сообщений),
необходимую во всех вариантах использования системы, а функции
более высоких уровней, в каждом варианте специфические,
29
выполняются соответствующими подсистемами-пользователями
этой платформы. В частности, при использовании в ТфОП и в ISDN
платформа MTP дополняется «сверху» подсистемой-пользователем
ISUP, а также подсистемой управления сигнальными соединениями
SCCP, которая предусматривает создание в сети ОКС виртуальных
соединений для переноса через эту сеть информации, вообще
говоря, не только сигнальной. Разные прикладные подсистемы,
встраиваемые в систему ОКС7 (TCAP, OMAP, INAP и другие),
обеспечивают техническую эксплуатацию сети ОКС, обмен
информацией между узлами управления услугами и узлами
коммутации услуг в Интеллектуальной сети и т. п. Очень ценное
свойство системы № 7 – она является открытой в том смысле, что
разрешает, по мере необходимости, вводить в нее новые (в том
числе, вновь создаваемые) подсистемы.
АТС
SP&
АТС
SP SP SP
сеть сигнализации
АТС C
АТС A АТС B
сеть разговорных каналов
Рис.3.1. Двухуровневая сеть с ОКС7
Сеть связи, использующая систему ОКС7 (рис.3.1), состоит из

множества коммутационных узлов и станций, соединенных между
собой цифровыми трактами и выполняющих функции пунктов
сигнализации (SP – Signaling Point), которые способны формировать,
передавать, принимать и интерпретировать сигнальные сообщения.
Пункты сигнализации SP связываются между собой цифровыми
30
каналами, обеспечивающими двухстороннюю передачу сигнальной
информации, т.е. выполняющими функции сигнальных звеньев.
Совокупность пунктов сигнализации и сигнальных звеньев образует
сеть общеканальной сигнализации – сеть ОКС7.
Кроме коммутационных станций и узлов, функции пункта
сигнализации SP могут выполнять:
 центры эксплуатационного управления сетью связи (OA&MC
- Operation, Administration and Maintenance Centers),
 узлы управления услугами Интеллектуальной сети,
 транзитные пункты сигнализации (STP - Signaling Transfer
Points).
Каждому SP присваивается свой уникальный код. Любые два SP,
между которыми возможен обмен сигнальной информацией,
являются сигнально связанными. Сигнальная связь (signaling
relation) двух SP может обеспечиваться либо прямым пучком
сигнальных звеньев, либо средствами сети ОКС с организацией
транзита. В первом случае пункты сигнализации (с точки зрения
структуры сети ОКС7) являются смежными, во втором – несмежными.
Наличие в сети ОКС и смежных, и несмежных SP обусловлено
тем, что в такой сети возможно, в принципе, использование трех
режимов сигнализации: связанного, несвязанного и квази-
связанного. В связанном режиме сигнальная информация,
относящаяся к сигнальной связи определенных SP, передается по
сигнальному звену, которое соединяет эти SP непосредственно. В
несвязанном режиме для передачи аналогичной информации
используется последовательно несколько сигнальных звеньев, а к
организации сигнальной связи привлекаются пункты сигнализации,
выполняющие функции транзитных (STP). Квазисвязанный режим
представляет собой частный случай несвязанного режима, а именно
случай, когда путь, по которому сигнальная информация проходит
через сеть, назначается заранее и является на данный период
31
времени фиксированным. Система ОКС7 поддерживает связанный и
квазисвязанный режимы сигнализации.
Возможные разные варианты структуры сети ОКС. На выбор того
или иного варианта могут влиять как структура сети связи,
обслуживаемой сетью ОКС, так и другие факторы. Если сеть ОКС
призвана формировать сигнальные связи, нужные исключительно
для управления коммутацией, самый подходящей структурой, скорее
всего, будет структура, ориентированная преимущественно на
поддержку связанного режима сигнализации и лишь в небольшой
степени – квазисвязанного режима (для малонагруженных
сигнальных связей). Если же сеть ОКС создается как общий ресурс
для удовлетворения всех потребностей в ее возможностях, то
высокая производительность сигнальных звеньев в сочетании с их
резервированием для обеспечения высокой надежности приводит к
структуре, ориентированной, главным образом, на квазисвязанный
режим, и дополненной при этом относительно небольшим
количеством прямых (и сильно загруженных) пучков сигнальных
звеньев, используемых в связанном режиме сигнализации.
Ниже будет показано, что возможности сети ОКС7 не ограничены
лишь функциями сигнализации, связанной с управлением
коммутацией. Для поддержки только сигнализации этого рода
наиболее естественным является связанный режим, что обусловлено
спецификой организации коммутируемых связей в сетях коммутации
каналов, в частности, в телефонных сетях, где соединение всегда
устанавливается последовательно по шагам. Исходящая АТС, выбрав
направление к станции назначения, обменивается сигнальной
информацией с ближайшей (в этом направлении) транзитной
станцией, например, с УИС; затем УИС обменивается сигнальной
информацией с другой транзитной станцией – УВС, а тот, в свою
очередь, – со станцией назначения. То же самое происходит и при
разрушении соединения: на каждом шаге разъединения обмен
сигнальной информацией происходит только между смежными
32
станциями. Ясно, что при таком алгоритме целесообразна такая
структура сети ОКС, когда SP, размещенные в смежных станциях
сети, тоже являются смежными.
Другое дело, если через сеть ОКС7 станут обмениваться
информацией несмежные SP. Поскольку функции транзита могут
быть предусмотрены в любом SP (а не только в STP), структура сети
ОКС7, ориентированная на связанный режим сигнализации,
обеспечит и такой обмен. Однако по мере роста его доли в общем
объеме информации, проходящей через сеть ОКС7, эта структура
будет становиться все менее и менее экономичной, и все более
целесообразной будет структура, предполагающая несвязанный
(квазисвязанный) режим. Примерами ситуаций, когда сеть ОКС
должна обеспечивать обмен сигнальной информацией между
несмежными SP, являются услуги виртуальной частной сети VPN
(Virtual Private Network). Процедуры предоставления услуги VPN
предусматривают ряд действий (проверку принадлежности одной и
той же частной сети, прав связи и т.п.), для выполнения которых
требуется обмен сигнальной информацией между SP, встроенными в
те АТС, абонентами которых являются разные члены VPN, в том
числе, между несмежными SP.
Другая группа примеров связана с организацией
Интеллектуальной сети IN. Для предоставления услуг IN необходим
обмен сигнальной информацией между узлами коммутации услуг
(SSP – Service Switching Points) и узлом управления услугами (SCP –
Service Control Point). Поскольку IN устроена так, что один SCP
обслуживает большое число SSP, пункты сигнализации сети ОКС,
встроенные в эти элементы IN, во многих случаях могут оказаться
несмежными.
Из всего сказанного следует, что в больших сетях связи структура
сети ОКС должна быть ориентирована на то, что в ней, с течением
времени, все более широко будет использоваться квазисвязанный
режим сигнализации.
33
3.3 Стек протоколов
Все эти идеи сети общеканальной сигнализации внедрялись
постепенно. В конце 1970-х годов американская AT&T внедрила во
всей своей сети систему сигнализации ОКС6. Более совершенная
система ОКС7 была специфицирована AT&T в 1980 году, и в том же
году она была утверждена МККТТ (теперь – ITU-T) в качестве
международного стандарта. Перечень рекомендаций МККТТ для
ОКС7 приведен в таблице 3.1. Необходимо, однако, отметить, что в
разных странах внедряются разные версии ОКС7. Например, США,
Канада, Япония и, частично, Китай внедрили у себя версию
Американского национального института стандартов ANSI. В Европе
реализована версия Европейского института стандартизации
электросвязи ETSI. Российские спецификации ОКС7, хотя и следуют
стандартам ETSI, имеют свои национальные особенности.
Таблица 3.1. Перечень рекомендаций ITU-T серии Q по вопросам
ОКС7
Описание подсистем, функций, Рекомендации ITU-T

компонентов
Введение в ОКС7 Q.700
Подсистема переноса сообщений – Q.701 - Q.704, Q.706, Q.707
МТР
Структура сети сигнализации ОКС7 Q.705
Подсистема управления сигнальными Q.711 - Q.714, Q.716
соединениями – SCCP
Подсистема-пользователь – TUP Q.721 – Q.725
Дополнительные услуги Q.730 – Q.737
Эксплуатационное управление сетью Q.750, Q.752 - Q.755
ОКС – ОМАР
Подсистема-пользователь ISUP Q.761 - Q.764, Q.766, Q.767
Прикладная подсистема средств Q.771 – Q.775
транзакций – ТСАР
Тестирование МТР, TUP, ISDN-UP, Q.780 – Q.787
SCCP, TCAP
Подсистема мобильной сети – МАР Q.1051
Прикладная подсистема Q.1205, Q.1208, Q.1211,
34
Интеллектуальной сети – INAP Q.1213 - Q.1215, Q.1218,
Q.1219, Q.1290
Соответствие ОКС7 и модели OSI Q.1400
Рекомендации ITU-Т, приведенные в таблице 3.1,

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

бильной связи эксплуатацион- протокол
стандарта GSM ного управления интеллектуальной
сети
MAP, BSSAP ОMAP INAP
AE AE AE Подсистема Подсистема Подсистема

мобильной связи ISDN процедуры
OMASE стандарта handover сети
ASE ASE NMT-450 мобильной связи
стандарта
NMT-450
Подсистема
средств MUP ISUP НUP
транзакций
TСAP
Подсистема управления
сигнальными соединениями
SCCP
Подсистема переноса сообщений

МТР - Уровень 3

ASE – Сервисный прикладной элемент

OMASE – Сервисный прикладной элемент ОМАР
Рис. 3.2. Структура ОКС7
3.4. Подсистема переноса сообщений MTP

Подсистема MTP содержит три функциональных уровня. Два
нижних уровня MTP соответствуют уровням 1 и 2 семиуровневой
модели взаимодействия открытых систем (OSI). Уровень 3 MTP
соответствует уровню 3 модели OSI лишь частично; т.к. не
35
предоставляет услуг, которые предусматривают создание в сети ОКС
виртуальных соединений.
Рассмотрим подробнее, как организованы функции MTP в
каждом из этих уровней.
3.4.1. Уровень 1
Уровень 1 содержит функции, которые обеспечивают
использование физической среды для передачи битов и формируют
звено передачи данных, несущих сигнальную информацию. Это
звено образуется двумя каналами с противоположными
направлениями передачи (как правило, со скоростью 64 кбит/с в
каждом направлении), оборудованными на концах средствами
формирования интерфейса с вышележащим уровнем. Наличие этих
средств дает возможность уровню 1 стандартным образом
предоставлять уровню 2 услуги передачи битов, обеспечивая
независимость функций уровня 2 MTP (и, тем более, остальных
уровней) от характеристик передающей среды.
Полезно отметить, что цифровой канал (как прямого, так и
обратного направления), используемый для формирования звена
передачи данных, не должен использоваться ни для каких иных
целей. Обычно это - 16-канал из стандартной 30-канальной группы
системы ИКМ-передачи.
Уровень 2 MTP содержит функции формирования (с
привлечением услуг уровня 1) сигнального звена между двумя
смежными SP и реализует процедуры, связанные с передачей
сигнальных сообщений по этому звену. Функции уровня 2 определяют
структуру информации, передаваемой по сигнальному звену, и
процедуры обнаружения и исправления ошибок.
Информация переносится от одного SP к другому в
информационных блоках, имеющих переменную длину и называемых
сигнальными единицами. Существует три типа сигнальных единиц:
36
 значащая сигнальная единица (МSU), которая
предназначена для переноса сигнальных сообщений,
формируемых подсистемами-пользователями,
 сигнальная единица статуса звена (LSSU), предназначенная
для переноса информации о статусе сигнального звена, по
которому она передается,
 заполняющая сигнальная единица (FISU), обеспечивающая
фазирование звена и передаваемая при отсутствии
сигнальных единиц MSU и LSSU.
Для идентификации типа сигнальной единицы используется
один из ее элементов - индикатор длины LI, разным значениям
которого соответствуют:
 LI=0 - заполняющая сигнальная единица,
 LI=1 или 2 - сигнальная единица статуса звена,
 LI2 - значащая сигнальная единица.
Наиболее сложной по своей структуре является значащая
сигнальная единица MSU. Ее формат представлен на рис. 5.3. MSU
содержит ряд полей, в которых размещается фиксированное
количество битов. Уровень 2 MTP обеспечивает присвоение значения
каждому биту внутри каждого поля при передаче и анализ этих
значений при приеме (исключение составляет поле сигнальной
информации, которое имеет переменную длину, и содержание
которого определяется функциями более высоких уровней).
Приведем краткие сведения о каждом поле.
Флаг выполняет функцию разделителя сигнальных единиц. Как
правило, закрывающий флаг одной сигнальной единицы является
открывающим флагом следующей сигнальной единицы.
Последовательность значений битов в поле флага следующая:
01111110.
37
Проверочная Поле сигнальной
Флаг Флаг
комбинация информации SIO LI FIB FSN BIB BSN
F F
CК SIF
8 16 8n, n 2 8 2 6 1 7 1 7 8
FSN - порядковый номер передаваемой сигнальной единицы;

FIB - бит индикации прямого направления (передача сигнала);
BSN - порядковый номер подтверждаемой сигнальной единицы;
BIB - бит индикации обратного направления (передача подтверждения);
LI - индикатор длины; \ - резерв; SIO - байт служебной информации.
Рис. 3.3. Формат значащей сигнальной единицы MSU
Чтобы избежать имитации флага другой частью сигнальной

единицы, MTP, передающая MSU, вставляет ноль после каждой
последовательности из пяти следующих друг за другом единиц,
содержащихся в любом поле MSU, кроме флага. Этот ноль
изымается на приемном конце сигнального звена после обнаружения
и отделения флагов.
Биты индикации направления FIB и BIB говорят о содержании
MSU в том смысле, несет ли она собственно сигнал (FIB - прямое
направление) или выполняет функции подтверждения (BIB -
обратное направление). Вместе с полями FSN и BSN (см. ниже) биты
индикации направления служат для контроля того, совпадает ли
последовательность сигнальных единиц на приеме с
последовательностью их на передаче, и используются в одном из
двух предусмотренных в системе ОКС7 методов исправления
ошибок.
Поля порядковых номеров FSN и BSN используются таким
образом. FSN передается в прямом направлении (то есть в
направлении передачи сигнала) и несет информацию о порядковом
номере той MSU, в состав которой оно входит. BSN передается в
обратном направлении в составе подтверждающей сигнальной
единицы (ею может быть MSU или FISU) и несет информацию о
порядковом номере той MSU, к которой это подтверждение
относится.
38
Индикатор длины LI указывает, сколько байтов содержит
сигнальная единица в полях, расположенных между резервными
битами и проверочной комбинацией CK. Заметим, что формат
заполняющей сигнальной единицы в промежутке между LI и CK не
содержит никаких полей (0 байтов), формат сигнальной единицы
статуса звена содержит в этом промежутке только поле статуса (либо
1 байт, либо 2 байта), а формат значащей сигнальной единицы
предусматривает, как это видно на рис. 5.3, наличие между LI и CK
двух полей - имеющего длину 1 байт поля SIO и имеющего
переменную длину поля сигнальной информации SIF. Из сказанного
сам собой вытекает способ идентификации типа сигнальной
единицы, о котором говорилось выше.
Байт служебной информации SIO содержит два элемента -
сервисный индикатор, указывающий, к какой из подсистем-
пользователей относится содержащаяся в сигнальной единице
информация, и индикатор вида сети (международная,
междугородная, местная).
Поле сигнальной информации SIF содержит целое число байтов
(от 2 до 272). Форматы этого поля определены отдельно для каждой
подсистемы-пользователя.
Поле проверочной комбинации CK содержит 16 битов. Значения
битов вычисляются путем применения образующего полинома к
информации, которая содержится в подготавливаемой к передаче
сигнальной единице. Полином имеет вид х16+ х12+ х5+ 1. Он выбран
таким образом, чтобы оптимизировать процесс обнаружения пакетов
ошибок при передаче.
Проверочные биты образуются из остатка от деления (по модулю
2) величины хk (х15+ х14+ х13+ х12+ .... х2+ х + 1), где k - число битов в
сигнальной единице между последним битом открывающего флага и
первым проверочным битом, кроме битов, введенных, чтобы
исключить имитацию флага, на образующий полином х16+ х12+ х5+1, и
остатка от деления на тот же полином умноженного на х16
39
содержимого сигнальной единицы между последним битом
открывающего флага и первым проверочным битом (не считая битов,
введенных с целью исключить имитацию флага).
Передаваемые проверочные биты являются дополнением до “1”
образовавшегося остатка 16-битового поля, то есть “1” меняются на
“0” и наоборот. Это изменение производится для того, чтобы
минимизировать вероятность ошибки в работе оборудования
принимающей стороны.
Принимаемые биты анализируются на предмет соответствия
между ними и остальной частью принятой сигнальной единицы. Если
соответствия не обнаружено, регистрируется ошибка, а сигнальная
единица стирается. Стирание MSU приводит в действие механизм
исправления ошибок.
В ОКС7 предусмотрены два метода исправления ошибок.
Основной метод исправления ошибок применяется для
сигнальных звеньев, в которых время распространения в одном
направлении не превышает 15 мс. В противном случае используется
метод превентивного циклического повторения. Примером
использования метода превентивного циклического повторения
может служить случай, когда связь организуется по спутниковым
каналам. Сообщения, которые были приняты с искажениями
(например, из-за пакетов ошибок при передаче), передаются
повторно в той же последовательности, в какой они передавались
первый раз, так что для функций уровня 3 не возникает никаких
проблем с доставкой сообщений подсистемам-пользователям без
потерь и дублирования.
Если имеют место постоянные ошибки, уровень 3 уведомляется
об этом для того, чтобы он мог принять соответствующее решение,
например, решение изменить маршрут с использованием в нем
другого сигнального звена.
40
Основной метод исправления ошибок – это метод с
положительным и отрицательным подтверждением и повторной
передачей сигнальных единиц, принятых с искажениями.
Для передачи сигнальной информации от верхнего уровня SP-А к
такому же уровню SP-Б сигнальные единицы передаются через
уровень 3 МТР в уровень 2 МТР SP-А. В уровне 2 SP-А имеются
буфер передачи и буфер повторной передачи. Буфер передачи
используется для сохранения MSU перед ее передачей по
сигнальному звену, то есть действует как запоминающее устройство
до тех пор, пока пропускная способность звена не позволит послать
MSU. Буфер повторной передачи хранит копию MSU на случай, если
SP-Б примет ее с искажениями.
Каждая MSU содержит порядковый номер FSN, бит-индикатор
FIB, порядковый номер BSN и обратный бит-индикатор BIB. Когда
сигнальное звено функционирует нормально, FIB присваивается
конкретное значение (например, 0), и BIB также присваивается это
значение (0). Когда MSU принимается уровнем 2 в АТС А, она
поступает в буфер передачи. Буфер передачи работает по принципу
FIFO, то есть принятая первой MSU должна первой передаваться.
Когда сигнальное звено свободно, и подходит очередь для передачи,
следующей MSU присваивается FSN, на 1 больший (по модулю 128),
чем FSN последней переданной MSU. Затем очередная MSU
передается к SP-Б, а в буфер повторной передачи вводится ее копия.
В SP-Б принятый FSN сравнивается с ожидаемым (предыдущий
FSN плюс 1). Если принятое значение совпадает с ожидаемым,
содержимое MSU направляется в уровень 3. Значение FSN
копируется в поле BSN, а значение BIB остается неизменным. SP-А
воспринимает полученные BSN и BIB как положительное
подтверждение. При приеме верных BSN и BIB SP-А удаляет
содержимое MSU из буфера повторной передачи.
Если сравнение в SP-Б принятого FSN с ожидаемым
обнаруживает противоречие, возникшее, например, вследствие
41
функционирования механизма обнаружения ошибок и стирания
искаженных MSU, величина BIB изменяется на “1”, и SP-А получает
отрицательное подтверждение. В этом случае BSN присваивается
значение последнего правильно принятого FSN.
При приеме отрицательного подтверждения SP-А прерывает
передачу сигнальных единиц, и MSU, находящиеся в буфере
повторной передачи, передаются повторно, начиная с той, FSN
которой на “1” больше FSN последней положительно
подтвержденной MSU. Величина FIB меняется на “1” , а FIB и BIB
будут снова иметь одинаковые величины.
Метод исправления ошибок посредством превентивного
циклического повторения предусматривает положительное
подтверждение, циклическое повторение и упреждающее
исправление ошибок. При этом отрицательное подтверждение не
применяется, а индикацией искажения сообщения служит отсутствие
позитивного подтверждения. Исправление ошибок достигается
программируемым циклическим повторением неподтвержденных
MSU. Каждая сигнальная единица содержит FSN и BSN (как и в
основном методе), но FIB и BIB не используются, и им присваивается
значение “1”.
В период отсутствия новых ожидающих передачи MSU
начинается повторная передача MSU, хранящихся в буфере
повторной передачи. Во время повторной передачи сохраняются
первоначальные FSN. Если поступает новая сигнальная единица,
циклическое повторение прекращается, а новая MSU передается с
FSN, на единицу большим (по модулю 128) последнего присвоенного
значения. Если следующие новые MSU не принимаются,
рекомендуется циклическое повторение.
Неискаженная сигнальная единица положительно
подтверждается путем приема на АТС А значения BSN, равного
присвоенному FSN. После положительного подтверждения
соответствующая MSU удаляется из буфера повторной передачи.
42
Одним из недостатков этого метода является тот факт, что
буферы передачи и повторной передачи могут перегружаться. Для
предотвращения потери сообщения применяется процедура,
называемая вынужденным повторением. Количество MSU и
количество их байтов, хранящихся в буфере повторной передачи,
непрерывно контролируются. Если тот или другой параметр
достигает заранее установленного предельного значения, новые MSU
не принимаются, а приоритет отдается повторной передаче MSU,
хранящихся в буфере повторной передачи. Цикл повторной передачи
продолжается до тех пор, пока значения двух действующих
параметров не станут ниже установленных предельных значений.
Уровень 3 MTP содержит функции, обеспечивающие
транспортировку сигнальных сообщений через сеть ОКС от
подсистемы-отправителя, которая размещена в одном SP, к
подсистеме-получателю, размещенной в другом (не обязательно
смежном) SP. Говоря об обеспечении такой транспортировки, мы
имеем в виду две группы функций:
 функции обработки сигнальных сообщений, то есть, собственно,
функции их коммутации,
 функции адаптации сети ОКС к происходящим в ней изменениям
(перегрузкам или повреждениям элементов сети), то есть функции
эксплуатационного управления сетью ОКС.
Состав функций в каждой из этих групп, а также их связь между
собой и с функциями других уровней MTP иллюстрирует рис. 5.4.
Рассмотрим обе группы функций более подробно.
Функции обработки сигнальных сообщений представлены в
уровне 3 MTP тремя функциональными блоками:
 функциями сортировки сообщений, принимаемых от уровня
2, то есть разделения их на сообщения, адресованные в
“свой” SP, и на сообщения, адресованные в другой SP,
43
 функциями распределения сообщений, адресованных в
“свой” SP, по подсистемам уровня 4,
 функциями маршрутизации сообщений, подлежащих
передаче (как тех, которые пришли от подсистем уровня 4
или от функций эксплуатационного управления сетью ОКС,
размещенных в своем SP, так и тех, которые поступили от
уровня 2, но должны быть направлены в другой SP).
Работа всех трех функциональных блоков базируется на
следующем. Сообщения подсистем-пользователей МТР переносятся
в поле сигнальной информации SIF сигнальных единиц. Структура
сообщения, вообще говоря, бывает разной (в зависимости от его
принадлежности той или иной подсистеме-пользователю), однако его
обязательной частью во всех случаях является так называемая
маршрутная этикетка (см. рис. 5.4), содержащая, в частности,
данные об SP-отправителе (код OPC - Originating Point Code) и SP-
получателе (код DPC - Destination Point Code). Функции сортировки
сообщений, анализируя маршрутную этикетку, определяют, куда
нужно направить сообщение, принятое от уровня 2, - к функциям
распределения сообщений (если DPC совпадает с кодом “своего” SP)
или к функциям маршрутизации сообщений (если совпадения нет).
Третьим элементом маршрутной этикетки является поле
селектора сигнального звена (SLS – Signaling Link Selection), которое
служит для выбора сигнального звена, по которому должно
пересылаться к SP-получателю сообщение. Это звено уровень 3 МТР
либо выбирает сам, либо делает выбор, следуя указанию «сверху»,
т.е. от подсистемы-пользователя.
Функции эксплуатационного управления сетью ОКС тоже
представлены в уровне 3 MTP тремя функциональными блоками:
 функциями управления сигнальным трафиком,
 функциями управления сигнальными звеньями,
 функциями управления сигнальными маршрутами.
44
Функции эксплуатационного управления обеспечивают
пребывание сети ОКС7 в состоянии, когда она способна
предоставлять услуги своим пользователям, и восстановление такого
состояния при нарушениях нормальной работы сигнальных звеньев
или пунктов сигнализации. Эти нарушения могут проявляться либо в
виде полного отказа звена или SP, либо в ухудшении условий доступа
к ресурсу (звену или SP) из-за его перегрузки.
Функции распределения, приняв от функций сортировки
сообщение, этикетка которого содержит в поле DPC код “своего” SP,
анализируют байт служебной информации SIF и направляют
сообщение к подсистеме-адресату.
45
Подсистемы Уровень 3 Уровень 2
уровня 4 МТР МТР
Сетевые функции
Обработка сигнальных сообщений
Распределение Сортировка
сообщений сообщений
Маршрутизация
сообщений
Эксплуатационное управление сетью ОКС
Управление
сигнальным
трафиком
Управление Управление
сигнальными сигнальными
маршрутами звеньями
Тестирование и техобслуживание
(МТР)
Потоки сигнальных сообщений

Контрольная и управляющая информация
Рис. 3.4. Функции уровня 3 МТР
Функции распределения, приняв от функций сортировки

сообщение, этикетка которого содержит в поле DPC код «своего» SP,
анализирует байт служебной информации SIF (см. рис. 3.3) и
направляют сообщение к подсистеме-адресату.
SLS OPC DPC
4 14 14
OPC - код SP-отправителя

DPC - код SP-получателя
46
SLS - селектор сигнального звена
Рис. 3.5. Маршрутная этикетка
Отказ сигнального звена приводит к необходимости его

отключения и перевода обслуживаемого этим звеном потока
сообщений на резервное звено (или на несколько резервных
звеньев). Кроме того, отказ сигнального звена может ухудшить
условия (или совсем исключить возможность) доступа к некоторым
сигнальным маршрутам, что повлечет за собой необходимость
изменения схемы маршрутов.
И отказы (или перегрузки), и их ликвидация, имеют своим
результатом изменение статуса соответствующего ресурса сети с
точки зрения уровня 3 MTP. Сигнальное звено может быть “доступно”
или “недоступно”, причем “недоступным” оно оказывается, когда его
атрибут “статус” принимает одно из следующих значений:
“неисправен”, “деактивизирован”, “блокирован”, “доступ запрещен”, а
“доступным” становится при значениях этого атрибута “восстановлен”,
“активизирован”, “разблокирован”, “доступ разрешен”. По отношению
к сигнальному маршруту или к пункту сигнализации уместны
характеристики “доступен” или “недоступен”.
Когда благоприятная характеристика статуса сигнального звена
или сигнального маршрута меняется на неблагоприятную, вступает в
действие подходящий к случаю функциональный блок.
Функции управления сигнальным трафиком выполняют
процедуры:
 перехода на резервное звено (на резервные звенья),
 возврата на основное звено,
 вынужденной ремаршрутизации,
 управляемой ремаршрутизации,
 эксплуатационного запрета доступа к сигнальному звену,
 управления потоком сигнальных сообщений.
47
Функции управления сигнальными звеньями выполняют
процедуры:
 деактивизации, восстановления, активизации сигнального
звена,
 активизации пучка сигнальных звеньев.
Функции управления сигнальными маршрутами выполняют
процедуры:
 управляемого транзита через данный STP в данном
направлении,
 запрета транзита через данный STP в данном направлении,
 разрешения транзита через данный STP в данном
направлении,
 тестирования группы сигнальных маршрутов.
Служебная информация, которой обмениваются SP при
выполнении названных процедур, переносится через сеть в
сообщениях уровня 3 MTP, имеющих в байте SIO значение
сервисного индикатора (0000), которое является общим для всех
сообщений эксплуатационного управления. Эти сообщения имеют
маршрутную этикетку, формат и содержание которой стандартно
для всех сообщений уровня 3. Отличие заключается в том, что в
сообщениях, относящихся к эксплуатационному управлению
определенным сигнальным звеном, смысл поля SLS состоит не
только в выборе звена для передачи сообщения, но также и в
идентификации звена, которым данное сообщение управляет; если
же сообщение не относится к управлению сигнальным звеном, и
никакой другой код в поле SLS не внесен, то в нем записывается код
0000.
Следующие два элемента в форматах сообщений
эксплуатационного управления - так называемые коды заголовка H0
и H1. Код H0 содержит 4 бита и идентифицирует группу, к которой
относится сообщение. Например:
48
 H0=0001 - сообщения перехода на резервное звено и
обратно,
 H0=0100 - сообщения запрета/разрешения транзита,
 H0=0101 - сообщения тестирования группы маршрутов,
 H0=0110 - сообщения эксплуатационного запрета доступа, и
т.д.
Код H1 тоже содержит 4 бита, но смысл его зависит от того, к
какой группе сообщений эксплуатационного управления он относится.
Например, применительно к сообщениям перехода на резервное
звено и обратно:
 H1=0001 означает сигнал-команду,
 H1=0010 означает подтверждение,
а применительно к сообщениям запрета/разрешения транзита:
 H1=0001 означает, что это - сообщение запрета,
 H1=0101 означает, что это - сообщение разрешения.
Помимо кодов заголовка некоторые сообщения
эксплуатационного управления могут содержать поле с
дополнительной информацией, которая определяет область их
действия и, если нужно, порядковый номер той MSU, которая
предшествовала данному эксплуатационному сообщению.
Как уже упоминалось, необходимость в активизации тех или
иных процедур эксплуатационного управления возникает при
изменениях статуса тех или иных ресурсов сети ОКС. В зависимости
от причины изменения статуса ресурса (неисправность или
воздействие команд эксплуатационного управления) и от того, где это
изменение первоначально зафиксировано (в “своем” или в “не своем”
SP), информацию о нем уровень 3 MTP получает:
 от средств контроля рабочих характеристик сигнального звена в
уровне 2,
 в составе эксплуатационного сообщения, поступившего от другого
SP и доставленного в уровень 3 средствами уровня 2,
49
 от собственных средств эксплуатационного контроля и
управления,
 от центра эксплуатационного управления сетью через интерфейс с
подсистемой SCCP, обеспечивающей взаимодействие уровня 3
MTP с верхними уровнями протокола ОКС7 (TC, OMAP).
Полученные сведения об изменении статуса того или иного
ресурса уровень 3 MTP передает, смотря по обстоятельствам:
 средствам уровня 2,
 другому (или другим) SP,
 собственным средствам эксплуатационного управления,
 в центр эксплуатационного управления сетью.
При выполнении процедур эксплуатационного управления
уровень 3 MTP:
 обменивается эксплуатационными сообщениями с другим (с
другими) SP,
 передает соответствующие случаю индикации (запросы) в
центр и в собственные средства эксплуатационного
управления,
 обменивается с уровнем 2 командами/ответами при
активизации и деактивизации сигнальных звеньев.
3.5. Подсистема управления сигнальными соединениями

SCCP
Подсистема SCCP дополняет уровень 3 MTP функциями,
которых тому не достает для того, чтобы соответствовать уровню 3
модели OSI. MTP и SCCP образуют т.н. подсистему сетевых услуг
NSP (Network Service Part). NSP поддерживает создание между SP
как сигнальных связей, нужных для управления соединениями в сети
коммутации каналов, которую обслуживает сеть ОКС7, так и связей,
не относящихся к таким соединениям, в том числе, сигнальных
связей между несмежными SP. Важную роль здесь играет наличие в
50
SCCP собственной системы адресации, не привязанной, как в MTP, к
номерам телефонных каналов.
SCCP предоставляет своим пользователям как услуги, не
предусматривающие создания в сети ОКС виртуального соединения,
так и услуги, ориентированные на соединение. Имеется четыре
класса услуг SCCP:
0 – базовый класс услуг без соединения; доставка сигнальных
сообщений в заданной последовательности не гарантируется.
1 – класс услуг без соединения; доставка сигнальных сообщений
в заданной последовательности гарантируется.
2 – базовый класс услуг, ориентированных на соединение, без
управления потоком сообщений.
3 – класс услуг, ориентированных на соединение, с управлением
потоком сообщений.
Заметим, что класс 1 сохраняет порядок следования сообщений,
используя механизм присвоения «сверху» значения SLS в
маршрутной этикетке. Благодаря этому на каждом участке маршрута
от SCCP-отправителя к SCCP-получателю все сообщения SCCP,
принадлежащие одному потоку, проходят через одно и то же
сигнальное звено, вследствии чего по всему маршруту сохраняется
очередность их следования.
Сообщение SCCP содержит маршрутную этикетку, код типа
сообщения и параметры. Параметры дополняют данные,
определяемые кодом типа сообщения. В общем случае параметр
состоит из названия, индикатора длины и поля данных. Название
кодируется одним байтом и однозначно определяет параметр.
Индикатор длины указывает количество байтов в параметре, а поле
данных содержит информацию (заметим, что не в каждом параметре
имеются все эти поля).
Существуют параметры трех видов – обязательные с
фиксированной длиной, обязательные с переменной длиной и
необязательные. Обязательные параметры с фиксированной длиной
51
содержатся в сообщениях любого типа. Положение и длина каждого
из этих параметров определяются типом сообщения, а поэтому их
названия и индикаторы длины в сообщения не включаются.
Обязательные параметры переменной длины также содержатся в
сообщениях всех типов. Название любого такого параметра тоже
определяется типом сообщения. Необязательные параметры могут
включаться или не включаться в сообщение того или иного типа.
Каждый необязательный параметр содержит название (один байт) и
индикатор длины (один байт) перед полем данных, передающим
содержание параметра.
Формат сообщения SCCP в общем виде показан на рис. 3.6.
Всего на сегодня специфицировано 19 сообщений (пять из них – для
нужд эксплуатационного управления).
52
Очередность передачи битов
Очередность
передачи
8 7 6 5 4 3 2 1 байтов
~
~ Маршрутная этикетка ~
~
Код типа сообщения
Обязательный параметр А
Обязательная
. фиксированная
. часть
Обязательный параметр F
Указатель начала параметра М

.
.
Указатель начала параметра Р
Указатель начала необязательной части

Индикатор длины параметра М
Обязательная
переменная
~ Параметр М
~ часть
.
.
Индикатор длины параметра Р
Параметр Р
Имя параметра = Х
Индикатор длины параметра Х
Параметр Х
. Необязательная
. часть
Имя параметра = Z
Индикатор длины параметра Z
Параметр Z
~ ~
Конец необязательных параметров
Рис. 3.6. Формат сообщений SCCP

Из экономии места сообщения здесь не описываются, и
перечень их не приводится; сведения об этом можно почерпнуть,
например, из литературы к части 3. Автор считает более важным
обратить внимание читателя на то обстоятельство, что принцип
53
свободного использования в формате сообщения полей
необязательных параметров позволяет гибко модифицировать как
перечень сообщений SCCP, так и содержание любого из них, когда и
если в будущем возникнет потребность в такой модификации.
3.6. Подсистема средств транзакций ТС

Средства транзакций TC – Transaction Capabilities –
предназначены для поддержки взаимодействия между прикладными
процессами (или между разными элементами одного процесса),
размещенными в территориально разнесенных узлах сети связи.
Любой такой процесс (или элемент процесса) внутри одного узла
сети связи является пользователем услугами TC, размещенных на
этом узле. С другой стороны, сами TC того или иного узла являются
пользователем сетевыми услугами, предоставляемыми
размещенной на нем подсистемой NSP.
TC могут поддерживать обмен информацией между:
 коммутационными станциями и/или узлами сети связи,
 станцией (узлом) и базой данных, узлом управления
услугами сети IN, центром технической эксплуатации ЦТЭ и
т.п.),
 специализированными сетевыми центрами.
Пользователями TC могут быть разные приложения, в частности:
 приложения услуг мобильной связи,
 приложения услуг Интеллектуальной сети IN,
 приложения эксплуатационного управления.
Все такого рода приложения можно разделить на две категории:
 требующие обмена данными в реальном времени (т.е. без
ощутимых задержек); объем данных в этом случае
относительно невелик,
54
 не предъявляющие жестких требований в отношении
задержек; при этом объем данных может быть очень
большим.
Как видно из рис. 3.7, функции TC образуют два подуровня –
Подуровень Компонентов (CSL) и Подуровень Транзакций (TSL).
Чтобы стало ясно, в чем тут дело, нужно определить ряд понятий,
связанных с тем, как разделены функции между этими подуровнями и
какие услуги каждый из них предоставляет подуровню,
расположенному выше.
Пользо-- Запрос/Отклик Пользо--

ватель ватель
СSL Компоненты СSL

TC
TSL Сообщения транзакции TSL
SCCP Сообщение SCCP

SCCP
"Данные без соединения"
(Класс 0 или 1)
MTP MTP
Рис. 3.7. Подсистема средств транзакций TC
Взаимодействие между пользователями услугами средств

транзакции (для краткости назовем их TC-пользователями) может
быть представлено в виде обмена командами и ответами,
составляющего диалог TC-пользователя, находящегося в одном
пункте сети ОКС7 и инициирующего взаимодействие, с TC-
пользователем, находящимся в другом пункте этой сети и
являющимся партнером инициатора. Инициатор передает запрос
выполнения партнером определенной операции, а отклик партнера
на этот запрос содержит сведения о результате выполнения
(невыполнения) операции. По отношению ко всем этим действиям
55
принято говорить, что они связаны с обращением к одной и той же
операции.
Запрос (и отклик) представляет собой блок, называемый
компонентом. Компонент, связанный с обращением к определенной
операции, снабжается идентификатором (ID обращения), благодаря
чему одновременно могут быть активными несколько обращений,
причем обращения эти могут относиться как к одной и той же, так и к
нескольким разным операциям.
Множество функций, связанных с обработкой компонентов,
образует верхний подуровень TC – подуровень CSL. Через границу
между этим подуровнем и TC-пользователем компоненты проходят
индивидуально. Пользователь (инициатор) может передать к
подуровню CSL один за другим несколько компонентов до того, как
они будут переданы (в одном сообщении) второму TC-пользователю
(партнеру). Несколько компонентов, принятых в одном сообщении,
всегда передаются пользователю-адресату по одному и в той
последовательности, в какой они были переданы пользователем-
отправителем.
Последовательность компонентов, которыми обмениваются два
TC-пользователя при выполнении одного приложения, образует
диалог. Компоненты содержат параметр, идентифицирующий диалог
(так называемый ID диалога); у всех компонентов одного диалога этот
ID имеет одно и то же значение.
Диалоги могут быть неструктурированными и
структурированными. При неструктурированном диалоге TC-
пользователь передает компоненты, на которые не ожидается
откликов, так что связь между двумя TC-пользователями в явном
виде не определена. Компоненты передаются в однонаправленных
сообщениях, и сам факт передачи однонаправленного сообщения
говорит о неструктурированном диалоге. Пользователь может иметь
дело сразу с несколькими операциями; максимальное число
операций зависит от количества доступных в данное время
56
уникальных значений идентификатора ID обращения. Если при
приеме однонаправленного сообщения обнаружена ошибка
протокола, для уведомления об этом факте отправителя также
используется однонаправленное сообщение.
При структурированном диалоге связь между двумя TC-
пользователями определяется в явном виде – TC-пользователь
указывает начало, продолжение и окончание этой связи. Два TC-
пользователя могут вести одновременно несколько
структурированных диалогов, идентифицируя каждый из них с
помощью уникального ID диалога. Поскольку для каждого ID диалога
существует свое пространство имен ID обращений, один и тот же ID
обращения может повторяться в разных диалогах.
Структурированный диалог предполагается двусторонним – на фазе
его продолжения возможен дуплексный обмен компонентами.
Подуровень CSL предусматривает организацию соответствия
между запросами и откликами. Связанное с запросом операции
значение ID обращения вводится в отклик на этот запрос. Возможны
4 класса операций:
 класс 1 – предусматривается отклик и при удаче, и при
неудаче,
 класс 2 – предусматривается отклик только в случае неудачи,
 класс 3 – предусматривается отклик только в случае удачи,
 класс 4 – отклик не нужен ни в том, ни в другом случае.
Смысл и содержание каждого компонента определяется его
типом. Существуют компоненты следующих пяти типов.
 INVOKE – обращение. Этот компонент запрашивает
выполнение встречной стороной определенной операции. Он
может быть связан с другой операцией, к которой
обращалась встречная сторона.
 RETURN RESULT (NOT LAST) – часть данных с
информацией о результате выполнения операции. Имеется в
виду, что все данные с информацией о результате не могут
57
быть целиком размещены в одном компоненте, так что TC-
пользователю пришлось разделить их на несколько
сегментов. Данный компонент содержит один из этих
сегментов, за которым последуют другие.
 RETURN RESULT (LAST) – последняя (или единственная)
часть данных с информацией о результате выполнения
операции. Этот компонент свидетельствует о том, что
операция успешно завершена.
 RETURN ERROR – успешно завершить операцию не
удалось. Этот компонент содержит информацию о причине
того, что операция не была завершена.
 REJECT – отказ в приеме к обработке компонента,
поступившего от встречной стороны. Компонент содержит
информацию о причине отказа – либо отсутствие ресурсов,
нужных для выполнения операции, либо наличие в
поступившем компоненте той или иной ошибки (компонент
неизвестного типа, с нестандартной или не соответствующей
случаю структурой, с недопустимым или используемым для
другой операции идентификатором обращения, с
неизвестным кодом операции, и т. п.)
Рассмотрим теперь функции и услуги подуровня транзакций
(TSL). Очевидно, что расположенный выше подуровень CSL является
пользователем подуровня TSL (или, для краткости, TSL-
пользователем); другие TSL-пользователи в настоящее время не
определены, однако подуровень TSL устроен так, что они, в
принципе, могут существовать.
Поддержка неструктурированного диалога TSL-пользователей
заключается в том, что TSL обеспечивает передачу сообщения,
содержащего один или несколько компонентов (связанных с
операциями класса 4), от “своего” TSL-пользователя, являющегося
отправителем, к TSL-пользователю, являющемуся адресатом. Если
для поддержки такого диалога требуется передать несколько TSL-
58
сообщений, логическая связь между ними (то есть их
принадлежность одной и той же транзакции) в явном виде не
определяется.
Поддержка структурированного диалога базируется на том, что
каждый TSL-пользователь идентифицирует транзакцию уникальным
ID транзакции, который присутствует во всех TSL-сообщениях,
относящихся к этой транзакции. Для каждой транзакции TSL-
пользователь указывает ее начало, продолжение и окончание; на
фазе продолжения возможен дуплексный обмен между TSL-
пользователями сообщениями “внутри” этой транзакции.
3.7. Подсистема ISUP

Подсистема ISUP – это подсистема-пользователь MTP,
поддерживающая межстанционную сигнализацию в ТфОП и в ISDN.
При поддержке сигнализации в ISDN ISUP пользуется также услугами
SCCP, как это показано на рис. 3.2.
Средства адресации MTP дополнены в ISUP идентификатором
канала, поскольку для того чтобы указать, к какому телефонному
соединению относится сообщение, ISUP указывает номер того
канала, который занят в этом соединении. Дело в том, что ISUP
реализует два метода сигнализации – эстафетный, когда
сообщение передается от одной станции к другой и на
промежуточных станциях может изменяться, и сквозной, когда обмен
сообщениями происходит между конечными точками соединения.
Сквозной метод обычно использует услуги SCCP, либо без создания
сигнального соединения, либо ориентированные на соединение; в
последнем случае процедуры значительно упрощаются.
Сообщений ISUP слишком много. Назовем лишь основные
категории сообщений:
 сообщения управления базовым соединением;
 сообщения управления дополнительными услугами;
 сообщения модификации соединения во время связи;
59
 сообщения эксплуатационного контроля и управления;
 сквозные сообщения.
Принципы форматирования сообщений в ISUP (рис. 5.8)
подобны принципам, принятым в SCCP и описанным выше. Однако
SCCP устроена так, что маршрут, по которому проходит “сквозное”
сигнальное сообщение, никак не связан с маршрутом, по которому
проходит соединение телефонных каналов, а ISUP опирается на
“канальный” подход идентификации транзакции.
МАРШРУТНАЯ ЭТИКЕТКА
ИДЕНТИФИКАТОР КАНАЛА
ТИП СООБЩЕНИЯ
ОБЯЗАТЕЛЬНАЯ ЧАСТЬ
ФИКСИРОВАННОЙ ДЛИНЫ
ОБЯЗАТЕЛЬНАЯ ЧАСТЬ
ПЕРЕМЕННОЙ ДЛИНЫ
НЕОБЯЗАТЕЛЬНАЯ ЧАСТЬ
Рис. 3.8. Структура сообщения ISUP
На рис. 3.9 представлен пример установления базового

соединения в ISDN. В этом примере терминал вызывающего
пользователя А передает по каналу D в интерфейсе UNI сообщение
Q.931 SETUP в сторону своей АТС (исходящей), которая анализирует
его, удостоверяется в его правильности и передает начальное
адресное сообщение IAM протокола ISUP к той транзитной АТС,
через которую, согласно таблице маршрутизации исходящей АТС,
60
должно пройти устанавливаемое соединение. Одновременно
исходящая АТС передает вызывающему абоненту сообщение Q.931
CALL PROCEEDING.
Абонент А Исходящая АТС Транзитная АТС Входящая АТС Абонент Б
Q.931 ISUP ISUP Q.931
SETUP
IAM
CALL PROC IAM
INR
INR
(CPA REQ)
INF
(CPA) INF
SETUP
ALERTING
ACM
ACM
ALERTING CONNECT
Ответ (ANM)
CONNECT Ответ (ANM)
Рис. 3.9. Пример установления базового соединения ISDN
Транзитная АТС находит в своей таблице маршрутизации

входящую АТС и переправляет ей сообщение IAM. Предположим, что
в сообщение IAM не был включен адрес вызываемого пользователя
(CPA), а входящей АТС этот CPA необходим для завершения
установления соединения. Тогда входящая АТС передает к
транзитной АТС сообщение протокола ISUP «Запрос информации»
(INR), содержащее параметр (индикатор запроса), который говорит о
том, что требуется CPA. Транзитная АТС переправляет это
сообщение к исходящей АТС.
61
Исходящая АТС формирует сообщение протокола ISUP
«Информация» (INF) с недостающим CPA и передает его к входящей
АТС. Входящая АТС передает сообщение Q.931 SETUP к
оборудованию вызываемого пользователя Б, которое отвечает на это
сообщением Q.931 ALERTING. Входящая АТС передает в обратном
направлении сообщение протокола ISUP «Адрес достаточен» (ACM).
Когда исходящая АТС получает это сообщение, она передает к
оборудованию вызывающего пользователя сообщение Q.931
ALERTING.
Когда вызываемый абонент отвечает на вызов, его оборудование
передает сообщение Q.931 CONNECT к входящей АТС, которая, в
свою очередь, передает на транзитную АТС сообщение протокола
ISUP «Ответ» (ANM). Транзитная АТС пересылает сообщение ANM к
исходящей АТС, а та передает к оборудованию вызывающего
пользователя сообщение Q.931 CONNECT. В результате между
вызывающим и вызываемым пользователями устанавливается
соединение.
3.8. Протокол интеллектуальной сети INAP

Аспекты сетевого взаимодействия для концепции
Интеллектуальной сети (IN) рассматриваются в части 5 этого курса.
Там упоминаются различные услуги ИС: телеголосование, Free-
phone, телефонные карты и другие. Эти решения базируются на
представленных на рис. 3.10 базовых элементах и распределении
функций Интеллектуальной сети:
SCP – узел управления услугами (Service Control Point),
являющаяся ядром ИС и обеспечивающая выполнение логики услуг.
SCP содержит базу данных с необходимой информацией,
взаимодействует и управляет всеми компонентами Интеллектуальной
сети.
62
SSP – узел коммутации услуг (Service Switching Point), выполняет
функции коммутации абонентов между собой или между абонентом и
интеллектуальной периферией.
IP – интеллектуальная периферия (Intelligent Peripheral)
реализует необходимые для обеспечения услуги функции, например,
воспроизведение речевых информационных сообщений или прием
сигналов многочастотного набора от пользователя.
Функциональный объект поддержки доступа (CCAF – Call Control
Agent Function) обеспечивает пользователю доступ к услугам сети
независимо от лежащих в ее основе технологий. Базовая сеть связи
содержит функцию управления связью пользователя (CCF – Call
Control Function), функцию коммутации услуг и обеспечивает
взаимосвязь этих функций.
Функция управления услугами (SCF) контролирует процесс
предоставления услуг в целом. Функция хранения данных для услуг
(SDF) хранит информацию, необходимую функции (SСF), например,
данные о соответствии между физическим и логическим адресом, а
функция специализированных ресурсов (SRF), реализует запись и
воспроизведение речевых сообщений, а также генерацию и прием
сигналов многочастотного набора (DTMF).
Введение услуг и эксплуатационное управление ими
производятся с рабочей станции посредством функции доступа к
эксплуатационному управлению услугами (SMAF) и функции
эксплуатационного управления услугами (SMF).
Важно отметить, что возможны разнообразные варианты
распределения функций Интеллектуальной сети между физическим
оборудованием (см. рис. 3.10).
63
SSP
IP
CCF SRF
CCAF ISDN
DSS1 L3
E-DSS1 SCP
SSF PRI и BRI LAPD INAP SCF
TCAP
INAP SCCP
TCAP
SDF
MTP
SCCP
INAP
MTP
TCAP
SCCP
MTP
ИКМ
ИКМ
Рис. 3.10. Распределение функций между физическими элементами

ИС
Взаимодействие между функциональными единицами ИС

происходит посредством протокола прикладного уровня INAP,
входящего в стек протоколов ОКС7.
3.9. ОКС7 поверх IP

Универсальность и повсеместное развёртывание систем ОКС7
стимулируют работы по их использованию совместно с протоколами
TCP/IP. Задачами переноса сообщений ОКС7 через IP-сеть
занимается рабочая группа SIGTRAN, входящая в IETF. Протоколы
Sigtran (рис. 3.11) обеспечивают надежную транспортировку
сообщений ОКС7 по IP-сетям.
Во-первых, это протокол передачи информации для управления
потоками SCTP (Stream Control Transmission Protocol), который
поддерживает перенос сигнальных сообщений между конечными
пунктами сигнализации SP в IP-сети. Для организации сигнальной
связи один конечный пункт предоставляет другому перечень своих
транспортных адресов (IP-адреса в сочетании с портом SCTP).
Протокол SCTP позволяет независимо упорядочивать сигнальные
сообщения в разных потоках и обеспечивает перенос сигнальной
информации с подтверждением приема, без ошибок и дублирования,
64
доставку сообщений каждого потока с сохранением очередности их
следования, возможность объединения нескольких сообщений в один
пакет SCTP, фрагментацию данных по мере необходимости,
устойчивость к перегрузкам и т.п.
Протокол адаптации M2UA,

M3UA, M2РA, SUA, IUA
Транспортный протокол
сигнализации SCTP
Протокол Internet (IP)
Рис. 3.11. Стек протоколов SIGTRAN
Во-вторых, для выполнения функциональных и качественных

требований к MTP рабочая группа Sigtran рекомендовала три новых
протокола: M2UA, M2PA и M3UA. Каждый из них будет кратко
рассмотрен ниже, но прежде приведем установленные ITU-Т
требования к переносу сообщений MTP как по сетям с временным
разделением каналов, так и по IP-сетям:
 Для одноранговых процедур уровня 3 MTP требуется время
отклика в пределах от 500 мс до 1200 мс.
 Допускается потеря из-за транспортных сбоев не более одного
из 10 миллионов сообщений.
 Вследствие транспортных сбоев допускается несвоевременная
доставка (включая дублированные сообщения) не более одного
из 10 миллиардов сообщений.
 Не более одного из 10 миллиардов сообщений может
содержать ошибку, не выявленную транспортным протоколом
65
(согласно спецификациям ANSI – не более одного из
миллиарда сообщений).
 Доступность любого пучка сигнальных маршрутов (полная
совокупность разрешенных сигнальных путей от любого пункта
сигнализации в направлении любого пункта назначения)
должна быть не ниже 0.999998 (что соответствует времени
простоя приблизительно до 10 минут в течение года).
 Длина сообщения (принимаемая к обслуживанию полезная
нагрузка) должна составлять 272 байта для узкополосной ОКС7
и 4091 байт для широкополосной ОКС7.
Протокол M2UA уровня адаптации для пользователей уровня 2
MTP (MTP Level-2 User Adaptation Layer) предусматривает набор
услуг, эквивалентный тому, который предоставляет уровень 2 MTP
уровню 3 MTP в обычной сети ОКС7. Протокол используется между
шлюзом сигнализации и контролером транспортного шлюза в VoIP-
сетях. Шлюз сигнализации принимает сообщения ОКС7 через
интерфейс уровня 1 и уровня 2 MTP от конечного или транзитного
пункта сигнализации. Он служит окончанием для звена ОКС7 на
уровне 2 MTP и транспортирует информацию уровня 3 MTP и
вышележащих уровней к контролеру транспортного шлюза или к
другому конечному пункту сети IP, используя протокол M2UA поверх
SCTP/IP.
Протокол M2PA уровня адаптации для одноранговых
пользователей MTP2 (MTP2 User Peer-to-Peer Adaptation Layer), в
отличие от протокола M2UA, используется для полномасштабной
обработки сообщений уровня 3 MTP, которыми обмениваются любые
два узла сети ОКС7, взаимодействующие через IP-сеть. Пункты
сигнализации IP-сети функционируют как обычные узлы ОКС7,
используя IP-сеть вместо сети ОКС7. Каждый пункт сигнализации
сети с коммутацией каналов или IP-сети имеет код пункта
сигнализации ОКС7. Протокол M2PA предусматривает тот же набор
услуг, который предоставляет уровень 2 MTP уровню 3 MTP. Протокол
66
может использоваться между шлюзом сигнализации и контроллером
транспортного шлюза, между шлюзом сигнализации и пунктом
сигнализации IP-сети, а также между двумя пунктами сигнализации
IP-сети. Пункты сигнализации могут использовать протокол M2PA для
передачи и приёма сообщений уровня 3 MTP по IP или уровень 2
MTP для обмена этими сообщениями по стандартным звеньям ОКС7.
M2PA облегчает интеграцию сетей ОКС7 и IP благодаря тому, что он
позволяет узлам сети с коммутацией каналов иметь доступ к базам
данных IP-телефонии и к другим узлам IP-сетей, используя
сигнализацию ОКС7. И, наоборот, протокол M2PA позволяет
приложениям IP-телефонии получать доступ к базам данных сети
ОКС7.
Итак, протоколы M2PA и M2UA имеют следующие различия:
 M2PA – шлюз сигнализации является узлом ОКС7 с кодом
пункта сигнализации;
M2UA – шлюз сигнализации не является узлом ОКС7 и не имеет
кода пункта сигнализации.
 M2PA – соединение между шлюзом сигнализации и пунктами
сигнализации IP-сети представляет собой звено ОКС7;
M2UA – соединение между шлюзом сигнализации и
контроллером транспортного шлюза не является звеном ОКС7. Оно
представляет собой расширение MTP от шлюза сигнализации к
контроллеру транспортного шлюза.
 M2PA – шлюз сигнализации может содержать функции верхних
уровней ОКС7, например SCCP.
M2UA – шлюз сигнализации не содержит функций верхних
уровней ОКС7, поскольку он не содержит функций уровня 3 MTP;
 M2PA – для выполнения функций эксплуатационного
управления опирается на соответствующие процедуры уровня 3
MTP;
M2UA – использует собственные процедуры эксплуатационного
управления;
67
 M2PA – пункты сигнализации IP-сети обрабатывают примитивы
уровня 3 MTP и уровня 2 MTP;
M2UA – контроллер транспортного шлюза переносит примитивы
уровня 3 MTP и уровня 2 MTP к уровню 2 MTP шлюза сигнализации
для их последующей обработки.
Протокол M3UA уровня адаптации для пользователей уровня 3
MTP (MTP Level-3 User-Adaptation Layer) связан с переносом по IP-
сети средствами протокола SCTP сигнальных сообщений подсистем-
пользователей уровня 3 MTP (например, ISUP, SCCP). Подсистема
SCCP может переносить сообщения своих пользователей TCAP или
INAP с помощью либо протокола M3UA, либо другого продукта группы
Sigtran – протокола SUA, который рассматривается ниже. Протокол
M3UA используется между шлюзом сигнализации и контролером
транспортного шлюза или базой данных IP-телефонии. С
концептуальной точки зрения, он расширяет доступ к услугам уровня
3 MTP шлюза сигнализации, охватывая удаленные конечные пункты
IP-сети.
К тому же, протокол M3UA не ограничивает длину сообщения 272
октетами, как это установлено уровнем 2 MTP ОКС7. По этой причине
M3UA/SCTP позволяет переносить крупные блоки информации, не
прибегая к процедурам сегментации/сборки в верхнем уровне. Шлюз
сигнализации будет устанавливать 272-октетное ограничение только
тогда, когда он подключен к обычной сети ОКС7.
Протокол SUA уровня адаптации для пользователей SCCP
поддерживает перенос по IP-сети средствами протокола SCTP
сигнальных сообщений пользователей SCCP ОКС7 (например, TCAP
или INAP). Протокол SUA используется между шлюзом сигнализации
и конечным пунктом сигнализации IP-сети и между конечными
пунктами сигнализации IP-сети. Пример применения SUA приведен
на рис. 3.12.
68
Транзитный пункт
Конечный пункт Шлюз сигнализации
сигнализации сигнализации (STP)
Функция орга-
ТСАР низации меж- ТСАР
сетевого обмена
SUA SUA SCCP SCCP
Управление МТР3 МТР3

SCTP физическим SCTP Адресация кода
соединением МТР2 пункта МТР2
IP IP МТР1 МТР1
IP адресация
IP ОКС 7
Рис. 3.12. Уровень адаптации SUA для пользователя SCCP
SUA поддерживает как услуги SCCP без соединения с

неупорядоченной и упорядоченной доставкой, так и услуги,
ориентированные на соединение, с управлением или без управления
потоком данных и с обнаружением потерь сообщений и ошибок
вследствие несвоевременной доставки сообщений (т.е. классы услуг
SCCP с 0 по 3). В случае услуг без соединения SCCP и SUA
стыкуются в шлюзе сигнализации. С точки зрения пункта
сигнализации ОКС7, пользователь SCCP находится в шлюзе
сигнализации. Сообщения ОКС7 направляются к этому шлюзу на
основании кода пункта сигнализации и номера подсистемы SCCP, а
тот направляет сообщения SCCP к удаленному конечному пункту IP-
сети.
Протокол уровня адаптации для ISDN-пользователя (IUA)
поддерживает перенос через IP-сеть сообщений Q.931. Протокол IUA
исключает использование в системе сигнализации части протокола
MTP. IUA позволяет приложениям верхнего уровня непосредственно
взаимодействовать с транспортным протоколом SCTP.
69
SIGTRAN является не единственной рабочей группой IETF,
участвующей в определении новых протоколов для обеспечения
интеграции сетей ТфОП и IP. Следует еще упомянуть PINT (PSTN
and Internet Interworking – взаимодействие ТфОП и Интернет) и
SPIRITS (Service in the PSTN/IN Requesting Internet Service – запросы
услуг Интернет в ТфОП/IN). В PINT услуги ТфОП активизируются
путем запросов из IP-сети. Java-клиент SIP, встроенный в сервисное
Java-приложение на Web-сервере, создает запросы инициировать
телефонные вызовы в ТфОП. Цель состоит в том, чтобы обеспечить
Web-доступ к речевому контенту и осуществлять
телефонную/факсимильную связь из Интернет. В SPIRITS услуги IP-
сети активизируются путем запросов из ТфОП. SPIRITS, в первую
очередь, касается таких услуг, как уведомление о поступлении нового
вызова в сети Интернет, предоставление идентификатора
вызывающего абонента из сети Интернет и переадресация IP-
вызовов.
Рабочая группа ENUM в составе IETF разрабатывает схему
преобразования телефонных номеров E.164 в IP-адреса, используя
сервер доменовых имён DNS сети Интернет таким образом, что
любое приложение, включая SIP, может найти ресурсы, связанные с
уникальным телефонным номером.
Рабочая группа IPTEL разрабатывает протокол TRIP
маршрутизации телефонных вызовов по IP-сети (telephony routing
over IP), который представляет собой управляемый стратегией
межадминистративный доменовый протокол, информирующий
серверы адресов о доступности телефонных адресатов и
объявляющий атрибуты маршрутов к этим адресатам. TRIP
позволяет поставщикам, во избежание избыточного назначения
ресурсов или дублирования шлюзов, обмениваться информацией
маршрутизации, используя стандартные IP-протоколы.
3.10. Тестирование ОКС7
70
Тестирование качества работы и совместимости протоколов
ОКС7 в современных телекоммуникационных сетях приобретает в
последние годы все более важное значение. При этом особое
внимание уделяется проверке корректности реализации протоколов
сигнализации и их совместимости в оборудовании разных
производителей. Добавление новых услуг и возможностей в
существующее оборудование влечет за собой новые группы
протоколов и необходимость тестирования не только их самих, но и
взаимодействия с существующими, уже однажды проверенными
протоколами. На каждом из этапов, через которые проходит любой
компонент сети связи, начиная от разработки и кончая эксплуатацией
в условиях реальной нагрузки, используются специальные методы
тестирования и анализа качества функционирования, которые
реализуются специализированными программно-аппаратными
средствами, представляющими собой отдельные приборы (протокол-
тестеры или анализаторы) и целые системы распределенного
наблюдения.
Значение термина «тестирование» не определено никакими
стандартами, поэтому многие используют для одних и тех же понятий
разные термины. Кроме того, тестирование является больше
искусством, чем наукой. Это является следствием того,что:
 лишь некоторые термины в этой области стандартизированы в
мировом масштабе или имеют одинаковое толкование среди
специалистов (например, при измерении параметров
производительности можно встретить использование терминов
«тестирование производительности» или «тестирование
нагрузочной способности»);
 отдачу от применения тестового оборудования трудно рассчитать
(например, дать ответ на вопрос о том, как много ошибок было
выявлено с помощью тестового оборудования);
71
 практически невозможно оценить необходимый объем
тестирования (например, ответить на вопрос, можно ли выявить
больше ошибок за счет увеличения количества тестов на 10%).
Вкладывать деньги в тестирование не любят, так как
тестирование не добавляет дополнительных возможностей в уже
закупленное оборудование. Считается, что закупленное
оборудование должно работать безошибочно, если его разработка
выполнена корректно (в полном соответствии со спецификациями
заказчика).
Ниже приводится классификация применяемых в настоящее
время видов тестирования, обосновывается необходимость их
применения и рассматриваются типы тестового оборудования.
3.10.1. Аттестационное тестирование
Тестирование соответствия заданной спецификации является
единственным стандартизированным и широко распространенным
методом проверки корректности реализации протокола. Этот метод
основан на применении специализированного языка написания
тестов TTCN. Тестирование соответствия стандартизировано
международными организациями ETSI, ITU-T и ISO. За основной
документ, который называется ISO 9646, отвечает ISO. Главная идея
стандарта ISO 9646 состоит в том, что спецификация нового
протокола должна содержать комплект тестовых сценариев его
проверки. Вследствие своей узкоспециальной направленности эти
комплекты не являются общедоступными и, как правило, бесплатно
не распространяются. Тестовый комплект состоит из отдельных
тестовых сценариев, каждый из которых проверяет определенную
функцию из спецификации протокола. После прохождения сценария
ему назначается одно из трех значений результата выполнения:
успешный (passed), неубедительный (inconclusive) или неудачный
(failed).
Тестирование соответствия производится с помощью протокол-
тестеров в режиме симулятора протоколов (рис. 5.13). В соответствии
72
с методологией для тестирования каждого уровня протокола
разрабатывается отдельный комплект тестовых сценариев.
Симулятор проверяемого уровня протокола представляет собой одну
из функций профессиональной системы тестирования и использует
для своей работы эмуляторы протоколов нижестоящих уровней.
Стандарт ISO 9646 определяет для тестирования следующие
документы:
 проформа PICS,
 проформа PIXIT,
 структура комплекта ATS и перечень целей тестирования TSS&TP,
 комплект сценариев ATS на языке TTCN.
Так как стандарт любого протокола содержит обязательные и
необязательные части, то в зависимости от действительно
реализованных функций из всего комплекта выбираются лишь
необходимые сценарии. Выбор этих сценариев делается при помощи
специальной проформы PICS, заполняемой производителем
оборудования, которое подвергается проверке. Заполненная
производителем оборудования проформа PICS показывает, в какой
степени реализованы требования соответствующего стандарта (в
основном – необязательной его части). PICS используется для
статической оценки соответствия и выбора из ATS тех тестовых
сценариев, которые необходимы для проверки заявленных в PICS
функциональных возможностей. Для выполнения теста реальной
системы требуется дополнительная информация с описанием
данных, зависящих от тестируемой системы (SUT), таких как
информация маршрутизации, или данных, уточняющих информацию
PICS, например, в отношении диапазона поддерживаемых значений
параметров. Эти данные группируются в специальной форме,
которая называется PIXIT и заполняется лабораторией,
производящей тестирование системы по заявке ее производителя.
На платформе тестирования SNT (табл. 3.2), послужившей
базой, построена полная линейка тестового оборудования, в которую
73
входит компактный анализатор SNTlite, многопортовый
анализатор/симулятор общеканальных систем сигнализации SNT-
7531, анализатор/симулятор систем сигнализации и система
распределенного мониторинга и анализа сетевого взаимодействия
СПАЙДЕР.
Компактный анализатор SNTlite предназначен для оперативной
диагностики проблем, возникающих в процессе эксплуатации
коммутационных систем и требующих выезда специалиста на место
установки оконечного коммутационного оборудования (РАТС,
концентраторов, учрежденческих АТС или оборудования
беспроводного доступа). Анализатор SNTlite выполнен в виде
ноутбука, малогабаритного внешнего интерфейсного модуля для
подсоединения к первичному тракту ИКМ и программного
обеспечения для мониторинга и анализа протоколов российских
версий системы сигнализации ОКС7, применяемых в ЕСЭ РФ.
SNTlite определяет состояние и проверяет качество тракта ИКМ
(BERT).
Рис. 3.13. Протокол-тестеры SNT
Анализатор/симулятор/генератор вызовов SNT используется в

лабораторных работах по данному курсу при изучении сетевого
взаимодействия со стеками протоколов ОКС7, ISDN PRI/BRI,
74
GSM/GPRS, IN, CAMEL, V5.1 и V5.2, QSIG, TCP/IP, FR, X.25, H323
VoIP, а также сигнализации по 2ВСК. Прибор выполнен на базе
промышленного персонального компьютера и может
комплектоваться количеством интерфейсных модулей E1 или ISDN
BRI от одного до четырех, а также одним или двумя интерфейсами
Ethernet. Обладает уникальной функцией мониторинга и анализа
сетевого взаимодействия между 2ВСК и ISUP, 2ВСК и DSS1 для СЛ,
ЗСЛ, СЛМ и МГК. Наличие функций эмуляторов протоколов нижних
уровней и симуляторов пользовательских и прикладных протоколов
ISUP, INAP, DSS1 L3, V5.2 позволяет использовать SNT в учебной
лаборатории, а также при разработке и отладке оборудования.
3.10.2. Тестирование производительности
Комплект сценариев разрабатывается для проверки
правильности реализации протокола сетевого взаимодействия. В
случае успешного прохождения всех сценариев, считается, что
протокол реализован правильно. Однако, одно лишь тестирование
соответствия не может гарантировать корректность реализации
полностью, так как не предполагает проведение тестирования под
нагрузкой и проверку поведения системы при неопределенных
значениях параметров спецификации, оставленных для возможного
применения в будущем. При тестировании измеряются такие
параметры SUT, которые зависят от поступающей на систему
нагрузки, и производится их сравнение с допустимыми значениями.
3.10.3. Тестирование совместимости
Спецификация протокола нередко содержит области
неоднозначного понимания, по-разному интерпретируемые
разработчиками и, следовательно, приводящие к различным
реализациям. Такими областями спецификации являются
опциональные процедуры и параметры, разные значения параметров
и значения таймеров. Неоднозначность спецификации приводит к
тому, что реализации протоколов разными производителями
оборудования не работают совместно, даже если каждая реализация
75
успешно прошла предварительное тестирование соответствия.
Тестирование совместимости является ключевым аспектом для
Операторов, эксплуатирующих оборудование разных
производителей. Очевидно, что сетевые элементы одного
производителя должны корректно работать совместно с сетевыми
элементами другого производителя. Проверка этого может
проводиться в лабораторных условиях или непосредственно в сети
Оператора. На этапе тестирования совместимости проверяется, в
какой степени и при каких условиях разные реализации одного и того
же протокола могут работать совместно, давая ожидаемый результат.
Тесты этого вида могут применяться как ко всем протоколам,
используемым в интерфейсе, так и к какому-либо одному
выбранному протоколу.
3.10.4. Тестирование взаимодействия
Тестирование взаимодействия разных протоколов и систем
сигнализации приобретает важное значение для современных
телекоммуникационных сетей в связи с конвергенцией (взаимным
проникновением) сетей и услуг, наблюдаемой в таких областях как
передача данных, речи и мультимедиа; узкополосные и
широкополосные сети; стационарные и мобильные сети; сети с
временным разделением каналов и IP-сети. Для проведения тестов
взаимодействия при помощи системы тестирования используют
стандартные функции симуляции протоколов, дополненные
графическими редакторами тестовых сценариев и конструкторами
сообщений.
3.10.5. Регрессионное тестирование
С увеличением сложности телекоммуникационной
инфраструктуры процесс тестирования становится все более
систематизированным. В частности, спецификации тестов для
предыдущих версий оборудования используются для выборочной
проверки того, что в новом оборудовании прежние функции,
76
проверенные при тестировании старой версии, по-прежнему
работают правильно. Это называется регрессионным тестированием.
3.10.6. Функциональное тестирование
После регрессионного тестирования применяются тесты для
проверки новых функций. Такой порядок тестирования называется
функциональным. При проведении функционального тестирования
основной акцент делается на проверку системы в условиях
некорректной работы встречной стороны, создаваемых с помощью
симуляторов.
Все функции и протоколы, изучаемые с помощью платформы
SNT, приведены в описании лабораторных работ.
3.11. Сетевой мониторинг ОКС7
Лабораторные работы на базе системы мониторинга и анализа
сетей ОКС7 класса СПАЙДЕР (рис. 3.14) предназначены для
изучения постоянного наблюдения за состоянием элементов сети,
контроля качества связи, сбора информации о возникающих в сети
событиях, архивирования и статистической обработки информации
по разным критериям, трассировки вызовов в пределах сети,
генерации CDR, а также удаленного мониторинга и анализа сетевого
взаимодействия по ОКС7, применяемого в сетях ТФОП/ISDN/IN и/или
GSM/GPRS. Система состоит из нескольких удаленных модулей и,
как правило, одного центра наблюдения, соединенных между собой
по выделенной технологической сети передачи данных, обычно – IP-
сети. Удаленные модули устанавливаются непосредственно на
наблюдаемом объекте и подключаются к первичным трактам ИКМ,
содержащим звенья ОКС7, в режиме пассивного мониторинга.
Один удаленный модуль обеспечивает полнодуплексный
мониторинг и предварительную обработку данных от 32 звеньев в 16
трактах ИКМ. Кроме пересылки в центр наблюдения, данных о
состоянии звеньев и трейсов в реальном времени удаленный модуль
может одновременно выполнять функции локального мониторинга.
77
SP SP SP
Сигнальные звенья Сигнальные звенья
Сигнальные звенья
Спайдер RU Спайдер RU
Сеть TCP/IP
Пользователи
SP
Спайдер CU Спайдер CDR
Рис. 3.14. Организация распределенного мониторинга ОКС7
Существует несколько доводов в пользу периодического или

постоянного мониторинга интерфейса между находящимися в
эксплуатации сетевыми элементами, главные из которых сводятся к
тому, что при этом обеспечивается:
 выявление ошибок при взаимодействии протоколов, не
обнаруженных на других этапах тестирования;
 обнаружение несанкционированного доступа к ресурсам со
стороны отдельных абонентов;
 сбор информации о вызовах (CDR) и транзакциях (TDR);
 трассировка вызовов;
 обнаружение зацикливания сообщений;
 контроль источников и маршрутов прохождения трафика.
Используемая в качестве лабораторной установки система
мониторинга сетевого взаимодействия СПАЙДЕР предоставляет
возможность мониторинга и анализа следующих версий протоколов:
 ОКС7: Подсистема переноса сообщений MTP
78
 MTP (Российские спецификации, 1994)
 MTP (ITU-T: Q.700-Q.709, Blue Book, 1988)
 MTP (ITU-T: Q.700-Q.709, White Book, 1993)
 ОКС7: Подсистема-пользователь ISUP
 ISUP (Российские спецификации, 1994)
 ISUP (Российские спецификации, 2001)
 ISUP (ITU-T: Q.761-Q.764, Blue Book, 1988)
 ISUP (ITU-T: Q.761-Q.764, White Book, 1993)
 ISUP (ITU-T: Q.761-Q.764, White Book, 1997)
 Международный ISUP (ITU-T: Q.767, 1991)
 ISUP MoU (ETSI: ETS 300 121, 1991)
 ОКС7: Подсистема управления сигнальными соединениями
SCCP
 SCCP (Российские спецификации, 1994).
 SCCP (ITU-T: Q.711-Q.716, Blue Book, 1988)
 SCCP (ITU-T: Q.711-Q.716, White Book, 1996)
 ОКС7: Подсистема средств транзакций TCAP
 TCAP (Российские спецификации, 1994)
 TCAP (ITU-T: Q.771-Q.774, Blue Book, 1988)
 TCAP (ITU-T: Q.771-Q.774, White Book, 1997)
 ОКС7: Интеллектуальная сеть
 INAP (Российские спецификации, 1994)
 INAP (ETSI: CS-1 Core INAP, ETS 300 374-1, 1994)
 INAP (ITU-T: Q.1218, 1995)
 Сотовые сети стандарта GSM (2+)
 MAP (GSM 09.02)
 Abis: GSM 08.56 (Layer 2), 08.58 (Layer 3), 04.08(L3 INFO)
 BSSMAP (GSM 08.08)
 DTAP (GSM 04.08)
79
 SS (GSM 04.80)
 SMS (GSM 04.11)
 Прикладная подсистема CAMEL GSM 09.78, Rel. 1997
 GPRS – пакетная передача данных в сетях стандарта GSM:
 Интерфейс Gb: протоколы FR (FRF 1.1), LLC (GSM 04.64),
SNDCP (GSM 04.65), BSSGP (GSM 08.18)
 Интерфейс Gi: протоколы IP (RFC 791), TCP (RFC 793), UDP
(RFC 768), GTP (GSM 09.60)
 Сотовые сети стандарта NМT-450i (NМT Doc 900-2)
 Протокол MUP (NМT Doc 900-2)
 Протокол HUP (NМT Doc 900-2)
 Сети стандарта AMPS/DAMPS (EIA/TIA Interim Standard)
 Протокол IS-41-A/B/C/D
 Цифровая система абонентской сигнализации DSS1
 Первичный доступ (PRI):
 EURO-ISDN (ETSI: ETS 300 011, ETS 300 125, ETS 300 102) PRI
DSS1/PRI (ITU-T: I.431, Q.921, Q.931)
 Базовый доступ (BRI): EURO-ISDN (ETSI: ETS 300 012, ETS 300
125, ETS 300 102) BRI
 DSS1/BRI (ITU-T:I.430, Q.921, Q931)
 Выделенные и частные сети
 QSIG (ETS 300 172, 1995)
 Интерфейс сети абонентского доступа V5
 V5.1 AN/LE (ETS 300 324). Мониторинг LAPV5, PSTN, CC, LC,
PROTECTION.
 V5.2 AN/LE (ETS 300 347). Мониторинг LAPV5, PSTN, CC, BCC,
LC, PROTECTION.
На основе анализа данных от удаленных модулей,
подключенных к каналам передачи сигнальной информации (ИКМ
трактам или их имитаторам), центральный модуль формирует
80
целостную картину работы сетей связи и сетевого взаимодействия.
Лабораторная установка СПАЙДЕР (рис. 3.15.) включает в себя
функциональные модули: СПАЙДЕР Агент, СПАЙДЕР Мониторинг,
СПАЙДЕР DR, СПАЙДЕР AнтиФрод, СПАЙДЕР QoS.
Spider QoS Spider AntiFraud

Анализ качества Обнаружение несанк-
Spider NM обслуживания ционированного доступа
Spider Tracing
Мониторинг сети
Трассировка вызовов Spider DR
сигнализации
Формирование CDR/TDR
Spider Agent
Сбор и первичная обработка данных, передаваемых по сети сигнализации,
мониторинг состояний физических трактов
Рис. 3.15. Функциональные модули системы СПАЙДЕР

СПАЙДЕР Агент – основа системы СПАЙДЕР, обеспечивающая
непосредственное подключение, сбор и сохранение данных. Система
сбора и первичной обработки данных обеспечивает декодирование
сигнальных сообщений, преобразование их во внутренний формат и
сохранение в базе данных.
Модули первичной обработки осуществляют также контроль
состояния тестируемых трактов как на физическом уровне, так и на
уровне подсистемы MTP2 ОКС7 (прием и подсчет ошибок HDLC-
протокола передачи пакетов сигнализации). В одном модуле
первичной обработки реализована возможность сбора данных от 32
двунаправленных сигнальных звеньев.
Подсистема удаленных тестирующих модулей RU состоит из
следующих функциональных компонентов:
 цифрового регенератора ИКМ-сигнала СПАЙДЕР-R,
 концентратора СПАЙДЕР-C,
 обработчика сигнальных каналов СПАЙДЕР-T,
 процессорного модуля СПАЙДЕР-RU.
Модуль СПАЙДЕР Мониторинг предназначен для контроля
состояния сигнальных каналов, для своевременного обнаружения
81
аварийных ситуаций и перегрузок, а также для оценки
эффективности маршрутизации трафика в сети сигнализации.
СПАЙДЕР DR – подсистема сбора детализированной информации о
предоставленных услугах (CDR – Call Detailеd Record, TDR –
Transaction Detailed Record). Формирование этих записей
производится на основе сигнальной информации, и они могут быть
использованы для начисления платы, оценки качества обслуживания
и обнаружения несанкционированного доступа.
Основные функции модуля СПАЙДЕР Мониторинг:
 мониторинг состояния элементов сети сигнализации в режиме
реального времени;
 измерения нагрузки сети сигнализации;
 регистрация аварийных ситуаций и перегрузок с генерацией
предупредительных сообщений;
 сохранение проходящих по сети сигнальных пакетов для
последующего анализа;
 декодирование сигнальных пакетов;
 статистический анализ сигнального трафика.
Подсистема мониторинга и анализа использует информацию,
получаемую из сети сигнализации функциональным модулем
СПАЙДЕР Агент. Функция мониторинга состояний используется для
отображения аварийных ситуаций, возникающих в сети
сигнализации. Определение аварийных и текущих состояний
производится посредством анализа сообщений о статусе сигнальных
звеньев (LSSU). Система обеспечивает постоянное наблюдение за
элементами сети ОКС7, графическое отображение ее структуры,
состояния и нагрузки пучков сигнальных звеньев.
Модуль СПАЙДЕР АнтиФрод (AntiFraud) обеспечивает
обнаружение подозрительных с точки зрения несанкционированного
доступа вызовов в базе CDR, генерацию уведомлений и
формирование отчетов по таким вызовам в удобной форме.
82
СПАЙДЕР Трассировщик – модуль системы СПАЙДЕР,
предназначенный для трассировки вызовов (телефонных вызовов,
SMS и т.д.), т.е отслеживания всего сигнального обмена, связанного с
обслуживанием вызова. СПАЙДЕР QoS предоставляет информацию
о качестве обслуживания QoS (Quality of Services) в сети связи,
полученную на основе анализа данных CDR, которая позволяет
максимально эффективно использовать систему СПАЙДЕР для
улучшения работы сети, оценки эффективности маршрутизации
междугородного и международного трафика и многих других целей.
В целом, система СПАЙДЕР предоставляет оператору
распределенный мониторинг всех элементов сети ОКС7,
централизованный сбор и анализ данных (вне зависимости от типа
станций, включенных в сеть сигнализации), предварительную оценку
и отображение информации о функционировании сети. Система
является также эффективным инструментом для анализа качества
обслуживания и обнаружения несанкционированного доступа. В то же
время, модули системы могут использоваться и в качестве протокол-
тестера для локального мониторинга каналов сигнализации ОКС7.
Доступность информации о сети в режиме реального времени дает
оператору возможность предупредить возникновение перегрузок.
СПАЙДЕР Трассировщик предназначен для трассировки
вызовов в сети сигнализации. Функция трассировки вызовов
позволяет пользователю системы отслеживать последовательности
сообщений, которые связаны с прохождением вызовов в пределах
нескольких сетей (ТФОП, ISDN, GSM или NI), пользующихся услугами
ОКС7.
Параметрами для трассировки вызовов могут быть номера
вызываемого и вызывающего абонентов, NI, OPC, DPC, начала
вызова и любая другая информация, передаваемая по сети
сигнализации в процессе установления соединения.
Возможности трассировки вызова могут быть полезны для
мониторинга процессов взаимодействия между разными сетями,
83
определения корректности маршрутизации речевого и сигнального
трафика и для расследования фактов несанкционированного
доступа.
Трассировка вызовов может выполняться по заданным номерам
вызывающих или вызываемых абонентов c выводом всех
сообщений, относящихся к соединениям.
Возможности Трассировщика:
 трассировка вызовов разных типов (обычные вызовы, SMS
и т.п.),
 трассировка вызовов с учетом коммутации,
 отслеживание процедур аутентификации, эстафетной
передачи при трассировке вызовов в мобильных сетях,
 отображение сообщений в декодированной форме,
 отображение маршрута на карте сети.
Возможна трассировка вызовов как в режиме реального
времени, так и в прошлом или будущем времени. Алгоритм
лабораторной работы трассировки обычного вызова:
1. Пользователь на центральном модуле задает параметры
вызова: коды пунктов источника и назначения (OPC и DPC
соответственно), номера вызывающего и вызываемого
абонентов, интервал времени, в котором поступил (должен
поступить) вызов. Некоторые параметры могут быть не заданы
или заданы в виде маски, например, только первые цифры
номера вызываемого или вызывающего абонентов.
2. Центральный модуль устанавливает по выделенной
транспортной сети соединения со всеми удаленными
модулями и передает им заданные пользователем параметры.
3. Удаленный модуль, зарегистрировав начальное адресное
сообщение IAM, удовлетворяющее заданным параметрам,
пересылает его центральному модулю в виде пакета,
содержащего само сообщение, время регистрации t и
84
уникальный номер сигнального звена в системе мониторинга
СПАЙДЕР.
4. После получения первого сообщения IAM от любого из
удаленных модулей, центральный модуль разгружает
соединения со всеми модулями.
5. Центральный модуль анализирует полученную информацию и,
вновь установив соединения с удаленными модулями,
передает им OPC, DPC, NI (Network Indicator – индикатор сети)
и CIC (Circuit Idenification Code – код идентификации канала),
которые определяют сигнальные сообщения, относящиеся к
вызову, трассировка которого производится, а также время
регистрации первого сообщения IAM tпег.
6. Удаленные модули производят поиск сигнальных сообщений с
указанными полями OPC, DPC, CIC и NI, зарегистрированных
после tнач=tрег –t, где t задан пользователем в архиве, и
пересылают найденные сообщения центральному модулю.
Далее удаленные тестирующие модули RU продолжают
регистрацию и отбор сообщений, относящихся к этому вызову
и передаваемых по сигнальным звеньям и также пересылают
их центральному модулю.
7. Центральный модуль отображает получаемую информацию в
режиме реального времени и может остановить трассировку в
любой момент по запросу пользователя.
8. Получив сообщение RLC, центральный модуль по истечении
интервала времени t закрывает разрушает с удаленными
модулями.
Так как каналы транспортной сети между удаленными и
центральным модулями загружены неравномерно, может возникнуть
ситуация, когда сообщение IAM будет зарегистрировано на
удаленном модуле 1 раньше, чем на модуле 2, но центральный
модуль первым получит пакет от модуля 2. Для того чтобы избежать
потери информации о регистрации сообщения IAM на модуле 1,
85
поиск сообщений в базе на этапе 6 начинается с момента времени,
меньшего чем tрег на t=tсис+tIAM, где tIAM – максимальная сквозная
задержка сообщения IAM в местной (0,9с), междугородной (2,3с),
международной (4с) сетях, а tсис – задержка передачи данных по
транспортной сети (по умолчанию t=5c).
Аналогично, на этапе 8 центральный модуль ожидает сообщения
RLC со всех звеньев в течение t. Пользователь может изменять этот
параметр, но при этом необходимо учитывать, что с увеличением t
возрастает вероятность обнаружения сигнальных сообщений,
относящихся к другим вызовам с теми же OPC, DPC, CIC и NI.
Вероятность наличия таких вызовов зависит от нагрузки на
соединительные линии, а именно от интенсивности поступления
вызовов и продолжительности их обслуживания, а также от
алгоритма выделения речевого канала на АТС. С уменьшением t
возможна потеря системой сообщений IAM и RLC.
Функция декодирования и анализа сообщений позволяет
отображать сообщения в расшифрованном виде с управляемой
степенью детализации и со встроенной функцией интерактивной
помощи в отношении сообщений и параметров выбранного
протокола.
Развитая система фильтрации по разным критериям позволяет
выделить из общей массы сообщений (до нескольких десятков
тысяч, накопленных, например, за сутки наблюдения), только те,
которые содержат необходимую пользователю информацию.
Фильтры позволяют провести детальное исследование обнаруженной
системой СПАЙДЕР Мониторинг проблемы, сокращая требуемое для
этого время до минимума.
Модуль СПАЙДЕР Мониторинг осуществляет сбор
статистической информации о работе отдельных узлов сети
сигнализации по различным параметрам. Предоставляются отчеты
по каждому из протоколов в количественном или процентном
86
формате по определяемым пользователем критериям. В
зависимости от типа измерений критериями могут быть OPC, DPC,
NI; тип протокола; типы сообщений, а также другие критерии
статистики работы элементов сети ОКС7 согласно рекомендации
ITU-T Q.752.
В заключение отметим еще подсистему качества обслуживания
QoS – это набор приложений СПАЙДЕР, предоставляющих отчеты на
основе CDR в удобном и ориентированном на специфические задачи
виде, что позволяет максимально эффективно использовать систему
для улучшения работы сети, оценки эффективности маршрутизации
междугородного и международного трафика и многих других целей.
Модуль СПАЙДЕР QoS использует данные СПАЙДЕР CDR и
позволяет:
 - контролировать качество обслуживания, предоставляемое
другими операторами;
 - производить учет трафика и верифицировать данные биллинга;
 - оптимизировать использование ресурсов сети для увеличения ее
доходности.
Анализ и фильтрация записей CDR позволяют определить
самые длинные сеансы связи и самые активные потоки вызовов,
суммарное время разговора по отдельным направлениям связи,
выявить ЧНН, определить труднодоступные направления и т.п.
Использование набора уведомлений позволяет своевременно
обнаруживать отклонения качества обслуживания от заданного
уровня. Упоминавшийся выше модуль СПАЙДЕР QoS содержит
несколько приложений:
 СПАЙДЕР QoS Long Distance Report – автоматическая и ручная
генерация отчетов о качестве обслуживания и о биллинге по
направлениям и по кодам регионов (для местной/
междугородной/ международной связи).
87
 СПАЙДЕР QoS Mobile Report – генерация отчетов о качестве
обслуживания абонентов мобильных сетей, находящихся в
домашней сети или обслуживаемых при роуминге.
 СПАЙДЕР QoS Alarms – уведомления, генерируемые при
обнаружении отклонений параметров качества обслуживания от
заданного уровня.
Средства генерации отчетов представляет собой самую важную
часть СПАЙДЕР QoS. Они включают в себя автоматическую
периодичную генерацию отчетов, функции ручной генерации отчетов
за произвольный интервал времени, интерфейс для просмотра
отчетов. Отчеты генерируются в универсальном формате csv и могут
обрабатываться с помощью стандартных офисных приложений (MS
Excel, MS Access и т. п.):
 по кодам (междугородным и международным) с анализом до 6
начальных цифр кода;
 по OPC/DPC с возможностью группировки нескольких кодов для
одного оператора;
 по направлениям;
 комбинированно.
Основой анализа по цифрам кода служит рекомендация ITU-T
E.164.
3.12.Заключение части 3
В качестве заключения к части 3 отметим, что рассмотренный в
ней стек протоколов общеканальной сигнализации №7 является
самым удачным изобретением МККТТ (и его преемника – ITU-Т), по
своему значению соизмеримым с созданным IETF другим известным
стеком протоколов TCP/IP. Получив этот результат, ITU-T даже и не
пытался приступить к разработке системы сигнализации №8,
ограничившись уже разработанными семью международными и
двумя региональными (R1 и R2) системами сигнализации, но
постоянно развивая и совершенствую стек протоколов ОКС7.
88
3.13. Литература к части 3
1. Гольдштейн Б.С., Ехриель И.М., Рерле Р.Д. Подсистема МТР.
Стек протоколов ОКС7: Справочник по телекоммуникационным
протоколам. СПб. БХВ, 2003.
2. Гольдштейн Б.С., Ехриель И.М., Рерле Р.Д. Подсистема ISUP.
3. Гольдштейн Б.С., Ехриель И.М., Рерле Р.Д. Подсистема SCCP.
89
Часть 4. Телекоммуникационные протоколы сетей
сотовой связи 2G, 2.5G, 3G
поколения 1G, 2G, 2.5G, 2.75G, 3G и 4G; основы сетевого
взаимодействия в сетях подвижной связи (СПС), принцип
хэндовера; сетевое взаимодействие при роуминге; продолжение
рассмотрения стека протоколов ОКС7; протокол МАР стека
ОКС7; сетевое взаимодействие в TDM-сетях фиксированной и
подвижной связи; сценарии для разных видов сетевого
взаимодействия.
4.1.Сетевое взаимодействие в сотовых сетях

Термин сотовая (cellular) означает, что сеть разделена на ряд
сот – ячеек, географических зон охвата. Каждой соте назначается
частотный диапазон, который можно повторно использовать в других
сотах. В каждой соте имеется своя базовая станция BS (Base
Station), которая содержит радиопередающее и радиоприемное
оборудование и обеспечивает радиосвязь с теми мобильными
телефонами, которые оказываются в пределах данной соты.
Несколько базовых станций подсоединены к контроллеру
базовых станций BSC (Base Station Controller), который содержит
логику управления каждой из этих станций. Все BSC подсоединены к
центру коммутации подвижной связи MSC (Mobile Switching Center),
который управляет установлением соединений к мобильным
абонентам и от них. MSC предоставляет те же функциональные
возможности, что и стандартный коммутатор ТфОП, но еще
поддерживает и ряд специальных функций для мобильной связи. В
частности, MSC должен содержать собственную логику, чтобы иметь
дело с мобильными станциями и поддерживать функции хэндовера и
роуминга.
Технология мобильной связи предполагает, что абоненты могут
свободно перемещаться из соты в соту в пределах сети, а также из
одной сети в другую. Необходимо также, чтобы сеть отслеживала
местонахождение абонента с некоторой точностью, дабы можно
было доставить этому абоненту адресованные ему вызовы. Общее
90
решение этой задачи состоит в следующем. Во-первых, когда
абонент первоначально включает свой мобильный терминал, это
устройство самостоятельно посылает регистрационное сообщение к
местному MSC. В состав сообщения входит уникальный
идентификатор абонента. На основе этого идентификатора MSC
может определить домашний регистр HLR, которому принадлежит
абонент, и передать регистрационное сообщение в HLR, чтобы
информировать его о том, какой MSC в данное время обслуживает
абонента. После этого HLR передает сообщение отмены регистрации
в тот MSC, который до того обслуживал этого абонента (если таковой
имеется) и посылает подтверждение в новый обслуживающий MSC.
Большинство этих сообщений специфицированы в протоколе
сигнализации MAP (Mobile Application Part).
Этот протокол сетевого взаимодействия успешно вписался в стек
ОКС7 наряду с другим протоколом CAP (CAMEL Application Part).
Протокол MAP используется между сетевыми компонентами сетей
подвижной связи (СПС), такими как MSC, BTS, BSC, HLR, VLR, EIR, а
также SGSN/GGSN в GPRS. Всего определено пять приложений MAP
для подсистемы коммутации (MAP-MSC, MAP-VLR, MAP-HLR, МАР-
EIR, MAP-AUC) и приложение BSSAP (BSS Application Part) для
контроллера базовых станций BSC. Основные услуги MAP
специфицированы для сетей GSM, а затем несколько операций были
добавлены для поддержки GPRS (General Packet Radio Service) и
для сетей 3G. Подсистема MAP представляет собой протокол,
который позволяет узлам сети GSM обмениваться информацией друг
с другом с целью предоставления таких услуг, как роуминг, хэндовер,
маршрутизация входящих вызовов и SMS, обмен текстовыми
сообщениями SMS и аутентификация абонента.
4.2. Модель протокола МАР

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

1 подразумевалось, что местонахождение абонента является
постоянным и определяется планом нумерации, который
используется в сети. В сетях же подвижной связи местонахождение
абонента может радикально изменяться без специального
уведомления сети – например, абонент может выключить свой
сотовый телефон в аэропорту, а через пару часов снова включить его
в СПС совсем другой страны. Для входящих к мобильным абонентам
вызовов не существует прямой связи между местонахождением
абонента и номером сотового телефона.
Перед тем как передать телефонный вызов к мобильному
терминалу вызываемого абонента нужно получить в реальном
92
времени информацию о его местонахождении и другую служебную
информацию, а потому такие вызовы требуют обмена большим
количеством служебных сигналов, не относящихся непосредственно
к вызову и/или к сеансу связи. Сама изображенная на рис.4.1 модель
появилась еще до разработки стандарта GSM и первоначально была
введена для систем NMT-450. Уже в сетях NMT-450 были введены
базы данных двух типов: гостевой регистр VLR и домашний
(опорный) регистр HLR.
Каждый VLR обслуживает одну территорию, в границах которой
мобильные терминалы могут перемещаться без обновления данных
о своем местонахождении. Обновление этих данных производится
при переходе абонента из одной территории в другую. VLR содержит
всю информацию о мобильных терминалах, находящихся в данный
момент на его территории, которая необходима для установления
соединений с этими терминалами. Кроме того, VLR управляет
процессом коммутации в центре MSC, являясь в этом смысле
аналогом узла управления услугами Интеллектуальной сети SCP,
обсуждающегося в части 5.
HLR является базой данных, в которой содержится информация
об услугах и возможностях, предоставляемых мобильному терминалу,
а также о его местонахождении в настоящее время. У каждого
оператора GSM обычно имеется только один HLR и несколько VLR.
Кроме HLR и VLR есть еще и другие сетевые элементы: регистры
идентификации оборудования EIR, списки ключей опознавания,
системы речевой почты, SMS-центры, которые тоже соединяются с
MSC и между собой с помощью протокола MAP.
4.3. Интерфейсы А, В, Аbis

Сигнализация передается между MS и сетью, между сетевыми
элементами и при взаимодействии с другими сетями. В основе
протоколов сигнализации лежит стек ОКС7 и протокол LAPD сети
93
ISDN. Рассмотрим несколько подробнее сетевые аспекты
интерфейсов и протоколов (рис.4.2).
Интерфейс между BTS и BSC называют Abis-интерфейс.
Большинство свойств этого интерфейса стандартизовано, кроме той
части, которая связана с конфигурацией и техобслуживанием станций
BTS, из-за чего BTS обычно соединяется с BSC того же
производителя. Один или несколько контроллеров BSC соединяются
с центром коммутации подвижной связи MSC, управляющим
установлением соединения, маршрутизацией вызова и многими
другими функциями. Из-за того что абоненты СПС перемещаются,
MSC, помимо задач обычной АТС, обязан обеспечивать ряд
специализированных функций, связанных, в частности, с
определением местонахождения абонента. Формально интерфейс
между MSC и VLR, называемый B-интерфейсом, стандартизован, но
никто из производителей оборудования, как правило, не
разрабатывал автономные VLR: оба они, MSC и VLR всегда
содержатся на одной и той же платформе, и интерфейс между ними
является внутрифирменным.
АТС сети ТфОП MSC
B
TCAP INAP S
TCAP INAP I D I
T S S
S T
U Голосовые U
U M A
P тракты ИКМ P
P A P
P
SCCP
MTP3 сетевого уровня SCCP
МТР2 уровня канала передачи данных Сигнализация

MTP3 сетевого уровня
МТР1 физического уровня
МТР2 уровня канала передачи данных

HLR
STP
TCAP INAP
SCCP
SCCP
94
Рис.4.2. Стеки протоколов сетевого взаимодействия СПС
Интерфейс между BSC и MSC известен под названием A-

интерфейс. Это интерфейс на базе ОКС7, использующий протокол
SCCP, обсуждавшийся в части 3. Над ним в стеке сигнализации
находится подсистема BSSAP, которая является протоколом,
используемым для коммуникации между MSC и MS. Поскольку MS
обменивается информацией с BSC и MSC по отдельности, BSSAP
делится на две части: протокол управления BSSMAP (BSS
Management Application Part), обеспечивающий процедуры
интерпретации результатов обработки текущих вызовов и управление
ресурсами подсистемы BSS, и подсистема сквозной передачи
сообщений DTAP (Direct Transfer Application Part). Подсистема DTAP
содержит те сообщения, которые прозрачно проходят через BSS от
MSC к MS или наоборот.
14.4. Обновление с помощью MAP данных о

местонахождении мобильного терминала
Выше отмечалось, что основными процедурами MAP являются
изменение абонентских данных в регистрах HLR и VLR, передача
информации о начислении платы, регистрация местонахождения
абонента для сохранения возможности передачи исходящих и
приема входящих вызовов (обеспечение возможности роуминга),
перерегистрация и стирание предыдущей информации о
местонахождении абонента и пр. Рассмотрим подробнее процедуру
обновления данных о местонахождении (Location Update)
мобильного терминала, пребывающего в исходном состоянии (без
соединения). Дело в том, что для минимизации объема транзакций с
HLR этот регистр содержит только информацию о местоположении
MSC/VLR, к которым в данный момент подключен абонент, а уже этот
VLR содержит более детальную информацию об абоненте, такую как
зона, в которой реально перемещается абонент. Таким образом, VLR
95
требует, чтобы его информация о местонахождении абонента
обновлялась каждый раз, когда тот перемещается в другую зону, а
HLR требует обновления своей информации о местонахождении
абонента только тогда, когда тот меняет VLR.
Обновление данных о местонахождении может происходить,
когда
 MS только что включилась;
 MS переместилась в пределах зоны одного и того же VLR, но в
новую зону местонахождения LA;
 MS переместилась в новую зону VLR;
 Сработал таймер обновления местонахождения.
Когда мобильный терминал абонента включается первый раз, он
сканирует радиоинтерфейс на предмет выбора соты с наиболее
мощным принимаемым сигналом, затем декодируется информация,
которая циркулярно передается станцией BTS, и мобильный
терминал регистрируется в соте с самым сильным принимаемым
сигналом (при условии, что эта сота не запрещена). Затем
мобильный терминал регистрируется в сети, инициируя обновление
данных о местонахождении, как показано на рис. 4.3.
96
BSS MSC/VLR HLR/AuC MSC/VLR
MS
Запрос канала
Немедленное
назначение
Запрос обновления
местоположения Завершение информации
L3 (запрос обновления Передача информации
местоположения) аутентификации
Передача информации
аутентификации RR
Запрос аутентификации
Ответ аутентификации
Обновление
местоположения
Отмена
Отмена
Ввод данных об местоположения RR

абоненте
Ввод данных об
абоненте RR
Обновление
местоположения RR
Прием обновления местоположения
Команда сброса
Сброс выполнен
Освобождение
канала
Рис. 4.3. Процедура обновления данных о местонахождении в

сети GSM
Представленная в сценарии на рис. 4.3 последовательность
начинается запросом канала, который передается из мобильного
терминала в подсистему BSS. Запрос содержит данные о причине
установления связи – обновление местонахождения. Далее BSS
назначает канал SDCCH (Stand-alone Dedicated Control Channel) для
этого мобильного терминала и дает ему команду перейти на этот
канал, передав сообщение Immediate Assignment. По получении этого
сообщения мобильный терминал переходит на назначенный SDCCH
и передает запрос обновления данных о местонахождении. Запрос
содержит данные, включающие в себя идентификатор зоны
97
местонахождения, полученный мобильным терминалом, и
идентификатор мобильного терминала. Идентификатором
мобильного оборудования обычно служит либо номер International
Mobile Subscriber Identity (IMSI), либо номер Temporary Mobile
Subscriber Identity (TMSI), о чем мы поговорим в следующей лекции,
посвященной нумерации.
Этот номер передается через BSS в MSC с помощью типового
сообщения Complete Layer 3 Info (завершение информации уровня 3),
входящего в состав SCCP Connection Request протокола SCCP.
Если мобильный терминал пытается зарегистрироваться с
помощью TMSI, а этот TMSI не известен в MSC/VLR, то MSC/VLR
может запросить у мобильного терминала передачу IMSI. Кроме того,
MSC/VLR может запросить у мобильного терминала идентификатор
самого телефонного аппарата IMEI для проверки.
После приема запроса изменить данные о местонахождении
MSC/VLR может попытаться произвести аутентификацию терминала.
Если MSC/VLR уже не имеет аутентификационной информации, он
запрашивает эту информацию у HLR, используя операцию Send
Authentication Info протокола MAP. С помощью этого же протокола
домашний регистр HLR/AuC передает Return Result (RR) подсистемы
MAP с несколькими (до пяти) векторами аутентификации,
известными как триплеты. Каждый триплет содержит случайное
число (RAND) и параметр Signed Response (SRES). Узел MSC
передает в мобильный терминал запрос аутентификации
Authentication Request, который содержит только RAND. В мобильном
терминале выполняется такой же расчет, какой был сделан в
HLR/AuC, затем он передает Authentication Response, содержащий
параметр SRES. В свою очередь, MSC/VLR проверяет соответствие
SRES, принятого от мобильного терминала, параметру SRES,
принятому от HLR/AuC. Если соответствие подтверждено, MS
считается аутентифицированной.
98
На этой стадии MSC/VLR использует операцию Update Location
протокола MAP, чтобы информировать HLR о местонахождении
абонента. Сообщение в HLR содержит IMSI абонента и сигнал Global
Title Address (GTA) от MSC/VLR. Регистр HLR передает в VLR, где
ранее был зарегистрирован абонент (если таковой имеется),
сообщение Cancel Location (отмена местонахождения) протокола
MAP. Тогда VLR удаляет все записанные данные, относящиеся к
абоненту, и посылает в HLR сигнал Return Result.
Регистр HLR использует команду Insert Subscriber Data протокола
MAP для VLR, чтобы информировать VLR о совокупности
относящихся к рассматриваемому абоненту данных, включающих в
себя информацию о дополнительных услугах. В свою очередь, VLR
подтверждает получение информации. Затем HLR передает Return
Result, после получения которого MSC/VLR передает в мобильный
терминал сообщение DTAP Location Updating Accept. Затем он
ликвидирует соединение SCCP с BSS. Это заставляет BSS
освободиться от SDCCH путем передачи в мобильный терминал
сообщения Channel Release.
Для иллюстрации сетевого взаимодействия СПС и ТфОП
рассмотрим входящий и исходящий вызовы для СПС и ТфОП.
4.5. Входящий вызов в СПС из ТфОП

В случае входящего вызова к мобильному терминалу абонент
сети ТфОП набирает номер мобильного абонента MSISDN (Mobile
Station ISDN Number), структура которого рассматривается в
следующей лекции.
На рис. 4.4 показан базовый входящий вызов к мобильному
абоненту из ТфОП. Он начинается с поступления на GMSC
сообщения IAM протокола ISUP, упоминавшегося в лекции 4. Это
сообщение содержит списочный номер вызываемого абонента
MSISDN, на основании которого в GMSC определяется
соответствующий этому абоненту HLR и вызывается операция SRI
99
(Send Routing Information) протокола MAP в направлении к этому
HLR, чтобы позиционировать мобильный терминал. Информация SRI
содержит MSISDN абонента для определения IMSI.
Благодаря заранее произошедшему обновлению данных о
местонахождении HLR знает тот MSC/VLR, который обслуживает
этого абонента, и запрашивает в этом MSC/VLR операцию PRN
(Provide Roaming Number) протокола MAP, которая содержит IMSI
абонента. Этот MSC/VLR назначает из пула временный номер MSRN
(Mobile Station Roaming Number) для данного вызова и возвращает
этот номер в HLR. В свою очередь, HLR возвращает номер MSRN в
GMSC.
Полученный MSRN для ТфОП является реальным
(пересчитанным) номером вызываемого абонента. Его можно
использовать для маршрутизации вызова через любую
промежуточную сеть между GMSC и гостевым MSC/VLR, что
фактически и делает GMSC. Он маршрутизирует вызов к MSC/VLR
путем передачи IAM с MSRN в качестве номера вызываемой
стороны. После того как этот IAM принят, MSC/VLR получает оттуда
MSRN, узнает IMSI, для которого был назначен MSRN, после чего
этот номер MSRN можно вернуть в пул для использования другим
вызовом.
Далее MSC запрашивает в BSS передачу вызова абоненту с
помощью сообщения Paging Request, которое указывает зону
местонахождения, где следует искать абонента. После приема
вызова мобильный терминал пытается получить доступ к сети с
помощью передачи сообщения Channel Request, на которое
подсистема BSS отвечает сообщением Immediate Assignment с
указанием мобильному терминалу переключиться на SDCCH.
Мобильный терминал переключается на этот SDCCH и указывает
сети, что он отвечает на вызов. Тогда BSS пересылает ответ в MSC.
На этой стадии MSC инициирует шифрование, так как передаваемые
через радиоинтерфейс речь и данные должны быть зашифрованы.
100
После получения сообщения Setup мобильный терминал
передает в MSC сообщение Call Confirmed, указывающее, что он
располагает необходимой для установления соединения
информацией. Сообщение Call Confirmed действует как команда MSC
установить тракт до мобильного терминала. Поэтому MSC начинает
процедуру назначения, которая создает канал между MSC и BSS, и
канал между BSS и MS (вместо SDCCH). После создания канала в
мобильный терминал абонента посылается вызов, а в MSC
передается сообщение Alerting. Это сообщение запускает генерацию
акустического сигнала контроля посылки вызова и передачу
сообщения ACM обратно к исходящей АТС телефонной сети общего
пользования через GMSC. Как только вызываемый пользователь
ответит, мобильный терминал передает в MSC сообщение Connect.
Оно запускает передачу из MSC сообщения ANM обратно к
исходящей АТС и открытие двухстороннего тракта. И, наконец, в
вызываемый мобильный терминал передается сообщение Connect
Acknowledgement, и начинается разговор.
101
BSS MSC/VLR HLR GMSC ТфОП
MS
IAM
SRI (MSISDN)
PRN (IMSI)
PRN RR (MSRN)
SRI RR (MSRN)
IAM (MSRN)
Paging
Paging Request
Channel Request
Immediate
Assignment
Paging Response
Complete Layer 3 Info
(Paging response)
Cipher Mode
Command
Ciphering Mode
Command
Ciphering Mode
Complete
Cipher Mode
Complete
Setup
Call Confirmed
Assignment Request
Assignment Command
Assignment Complete
Assignment Complete
Alerting
ACM
ACM
Connect
ANM
ANM
Connect Acknowledge
Рис. 4.4. Вызов из ТфОП в СПС
4.6. Исходящий вызов из СПС в ТфОП

Сценарий базового вызова, исходящего от мобильного
терминала и адресованного абоненту ТфОП, предлагается
разработать читателю самостоятельно. Подскажем только, что после
102
того как BSS выделила мобильному терминалу SDCCH, этот
вызывающий мобильный терминал отправляет в MSC сообщение
CM Service Request1, содержащее информацию о типе услуги,
которую хочет вызвать мобильный терминал (в предлагаемом
сценарии это вызов с мобильного терминала, но может быть также и
другая услуга, например, отправка SMS).
По аналогии с рис. 4.4 сценарий исходящего вызова
заканчивается тем, что после ответа с вызываемого телефона ТфОП
возвращается сообщение Answer Message (ANM). Это приводит к
открытию контроллером MSC двухстороннего тракта до мобильного
терминала, а также к передаче из MSC в мобильный терминал
сообщения Connect. После приема сообщения Connect вызывающий
мобильный терминал отвечает сообщением Connect Acknowledge,
после чего обе стороны ведут разговор, а с точки зрения начисления
платы начат отсчет времени разговора.
1. Гольдштейн Б.С., Ехриель И.М., Рерле Р.Д. Стек ОКС7.
Подсистема МАР. Серия «Телекоммуникационные
протоколы»//СПб.: БХВ-2008
1
Здесь CM означает Connection Management.
103
Часть 5. Сетевое взаимодействие при
предоставлении услуг Интеллектуальной сети
архитектура Интеллектуальной сети (IN), первые международные
стандарты в области IN, предыстория создания IN;
взаимодействие SSP и SCP; протокол INАР стека ОКС7; cетевое
взаимодействие при предоставлении услуг FreePhone, Televoting и
др.; беспроводная Интеллектуальная сеть (WIN); архитектура
CAMEL; протокол САР стека ОКС7
5.1. Эволюция услуг в ТфОП

В связи с эволюцией услуг фиксированных сетей связи уместно
вспомнить одну давнюю историю. Гуляя в тенистой роще, греческий
философ Анаксимен беседовал со своим учеником. "Скажи, –
спросил юноша, – ты прожил долгую жизнь, умудрен опытом и учился
у великих эллинов. Как же так вышло, что и для тебя осталось столь
много неясных вопросов?" В ответ философ очертил посохом перед
собой два круга: маленький и большой. "Твои знания – это маленький
круг, а мои – большой. Но все, что осталось вне этих кругов, –
неведомое. Маленький круг с неведомым соприкасается мало. Чем
шире круг знаний, тем протяженнее его граница с неизвестностью. И
впредь, чем больше ты станешь узнавать нового, тем больше будет
возникать у тебя неясных вопросов".
Именно так обстоит дело с предметом части 5. Можно считать,
что традиционные телефонные услуги ТфОП соответствуют малому
кругу из этой поучительной притчи. Большой круг содержит в себе
постоянно расширяющуюся область новых сетевых
инфокоммуникационных услуг, включая дополнительные услуги
цифровых АТС, услуги Интеллектуальной сети, услуги компьютерной
и IP-телефонии, Web-контакт-центры, другие новые услуги,
являющиеся результатом взаимопроникновения (конвергенции)
телекоммуникационных и информационных технологий и
действительно порождающие сегодня больше вопросов, чем ответов.
104
Исторически первыми в этом перечне были дополнительные
услуги цифровых АТС с программным управлением, примерами
которых являлись:
- сокращенный набор номера – абонент, пользующийся этой
услугой, может установить нужное соединение, набрав вместо
полного номера вызываемого абонента заранее присвоенный ему
сокращенный номер;
- соединение без набора номера (прямая связь) – услуга позволяет
абоненту установить соединение с заранее зарегистрированным
номером, не набирая этот номер (с выдержкой времени или без
выдержки времени);
- повторный вызов абонента без набора номера – услуга
позволяет абоненту, имеющему телефонный аппарат с
многочастотной тастатурой, повторно соединиться с номером,
который был набран последним, не набирая этот номер снова;
- безусловная переадресация – услуга дает абоненту возможность
заказать, на время своего отсутствия, переадресацию входящих к
нему вызовов к другому абоненту;
- переадресация при занятости – услуга предоставляет абоненту
возможность заказать переадресацию к другому абоненту
вызовов, поступающих, когда сам он занят другим разговором;
- уведомление о новом вызове – услуга уведомляет абонента,
занятого разговором с другим абонентом, о том, что его вызывает
третий абонент;
- побудка – услуга позволяет абоненту назначить время, когда
станция должна передать ему автоматически сигнал вызова;
возможен заказ либо однократной побудки, либо многократной (т.е.
ежесуточно, вплоть до отмены услуги);
- наведение справки и конференцсвязь трех абонентов – услуга
позволяет абоненту перевести связь с другим абонентом в режим
удержания и соединиться с третьим абонентом, чтобы навести у
него справку. После ответа третьего абонента, абонент,
105
пользующийся услугой, может организовать конференцсвязь трех
абонентов, вернуться к первоначальному соединению, переведя
связь с третьим абонентом в режим удержания, или вернуться к
первоначальному соединению окончательно, отключив третьего
абонента;
- запрет исходящей связи – услуга позволяет абоненту временно
запретить для своего аппарата исходящую междугородную связь и
связь с платными службами, или исходящую связь всех видов,
кроме связи с экстренными спецслужбами;
- временный запрет входящей связи – услуга заключается в том,
что абонент запрещает направлять к нему либо все входящие
вызовы, либо только местные;
- исходящая связь по коду-паролю – абонент, который пользуется
услугой, запрещающей для его аппарата какой-либо вид
исходящей связи, может получать связь этого вида, используя
всякий раз код-пароль, набираемый перед набором нужного ему
номера;
- определение номера вызывающего абонента – услуга позволяет
абоненту при злонамеренном входящем вызове определить с
помощью администрации номер вызывающего абонента, если тот
включен в ту же местную сеть;
- передача информации АОН к аппарату вызываемого абонента –
эта услуга предоставляется абоненту, если он имеет право
пользования индивидуальной установкой АОН;
- ввод, замена и отмена личного кода-пароля – услуга
предоставляет абоненту право назначать, изменять или отменять
личный код-пароль, необходимый для пользования некоторыми
дополнительными услугами.
Справедливости ради следует отметить, что несмотря на
разнообразие дополнительных услуг в различных системах
современных АТС, практически все они оказались не востребованы
подавляющим большинством абонентов. Иная ситуация
106
складывалась с теми же услугами, но перенесенными со
станционного уровня на сетевой, согласно рассматриваемой в
следующем параграфе концепции Интеллектуальной сети.
5.2 Услуги Интеллектуальной сети

Начинающиеся с 800 телефонные номера соответствовали
первой дополнительной услуге ТфОП, вышедшей за пределы одной
АТС и опирающейся на использование сетевой базы данных. В то же
время (1980 год) в США стали распространяться и сервисные
телефонные карты. Вскоре после этого там же появилась целая
серия дополнительных услуг для абонентов делового сектора под
общим названием «услуги входящей междугородной связи» INWATS
(Inward Wide Area Telecommunications Service) со многими новыми
функциональными возможностями.
Постепенно развивался интеллект службы ‘800', реальные
номера которой вычислялись в базе данных в зависимости от
времени суток, дня недели, географического положения
вызывающего абонента. Сетевая база данных перестала быть просто
средством хранения данных. Ее функции стали заключаться не
только в ответах на запросы, принимаемые от АТС, но и в передаче к
АТС команд, указывающих, каким образом обслуживать вызов. Так
возник узел управления услугами SCP (Service Control Point), а
взаимодействующие с SCP через сеть ОКС7 коммутационные узлы и
станции стали называться узлами коммутации услуг SSP (Service
Switching Point). В рекомендациях ITU-T определены также
вспомогательный узел управления (adjunct, AD), функционально
эквивалентный SCP, но подключаемый к SSP не через сеть ОКС7, а
непосредственно, и узел услуг (service node, SN), аналогичный AD,
но выполняющий, помимо функций SCP, также и функции
интеллектуальной периферии, к которым мы еще вернемся в этой
главе позже. Так или иначе, в компьютерах SCP, наряду с базой
107
данных, была запрограммирована и так называемая логика услуг,
состоящая из сценариев, которые описывают ту или иную услугу.
С этого исторического момента логика услуг окончательно
переместилась за пределы АТС, что и составило суть концепции
Интеллектуальной сети (IN). Общая архитектура IN включает в себя
(рис. 11.1) еще две важные системы – узел среды создания услуг
SCEP и узел эксплуатационного управления услугами SMP, –
которые служат для программирования услуг и для рассылки
программ и данных, необходимых для их выполнения, по логическим
объектам, участвующим в процессе предоставления услуг. Для
поддержки информационных потоков между узлами сети IN
специфицирован прикладной протокол интеллектуальной сети
INAP (Intelligent Network Application Protocol), который определяет
синтаксис и семантику вызываемых операций, назначение и порядок
их обработки. Протокол INAP (российская версия INAP-R) вырос из
транзакций, поддерживающих взаимодействие между АТС и базой
данных через сеть ОКС; в настоящее время он базируется на
прикладном протоколе поддержки транзакций (TCAP) из стека
протоколов системы сигнализации ОКС7, рассмотренного в части 3.
SMP SCEP
TCP/IP
или X.25
SCP
Cеть ОКС7
SSP/IP SSP
INAP
ТФОП
Рис. 5.1. Платформа Интеллектуальной сети
108
Главным преимуществом концепции Интеллектуальной сети
является возможность быстро создавать новые
телекоммуникационные услуги в соответствии со специфическими
для каждой из них требованиями, обеспечивая одновременную и
повсеместную доступность этих услуг для всех абонентов ТфОП.
Сами такие услуги, первоначально стандартизованные ITU-T в списке
CS-1, предоставляют довольно широкие (с точки зрения ТфОП)
возможности. Выпущенные в развитие концепции IN стандарты CS-2,
а также стандарты CS-3 и CS-4 потенциально могут дать еще более
широкие возможности. И все же, главное значение IN для
современных телекоммуникаций – не в списках услуг CS, а в
основной идее, состоящей в том, чтобы отделить логику услуг от
функций коммутации, построив соответствующую платформу. Эту
платформу составляют определенным образом взаимодействующие
функциональные блоки, реализуемые, в общем случае, в разных
физических объектах – узлах IN. Функции коммутации выполняют
узлы SSP, логика услуг размещается в узлах SCP, создается эта
логика в узле SCEP и распределяется по всем SCP узлом SMP. При
создании логики любой услуги используется набор
стандартизованных независимых от услуг конструкционных блоков,
что значительно упрощает работу программистов. Это особенно
важно в связи с тем, что в условиях жесткой конкурентной борьбы
оператор сети связи должен уметь предоставлять услуги,
ориентированные на группы пользователей с сильно
различающимися потребностями, и иметь возможность быстро
создавать и развертывать новые услуги.
Для описания процессов, происходящих в SSP при
предоставлении услуг, установлении соединения и обслуживании
вызова вплоть до разъединения, в концепции IN используется модель
базового процесса обслуживания вызова (BCP – Basic Call Process).
Модель содержит последовательность отображающих состояния
этого процесса точек (PIC – Point in call), между которыми могут
109
присутствовать точки обнаружения (DP – Detection point) обращений к
услугам IN или событий, которые представляют интерес с точки
зрения логики услуг IN. Триггерные точки обнаружения обращений к
услугам – TDP (trigger detection points) – отмечают приостановку
базового процесса BCP для обращения к логике услуг IN,
происходящую в соответствии с заранее назначенным критерием.
Таким критерием может быть определенное сочетание цифр в
набранном абонентом номере, префикс, категория вызывающей
абонентской линии и т.д. Важно отметить, что эксплуатационный
персонал SSP может сам определять триггерные точки (т.е. делать их
обнаруживаемыми) и назначать критерии для обращения к IN в тех
или иных фазах обслуживания вызовов.
Концептуальная модель IN отражает эту архитектуру в терминах
плоскостей (planes). Плоскость услуг касается только описания
услуг в плане их свойств. Глобальная функциональная плоскость
(global functional plane) описывает программные блоки, не зависящие
от услуг (service-independent building blocks, SIB). Распределенная
функциональная плоскость (distributed functional plane) отображает
элементы архитектуры, участвующие в обмене сообщениями IN, в
виде функциональных объектов (functional entities, FE) и
информационных потоков (information flows, IF), которые моделируют
обмен сообщениями между FE. Физическая плоскость (physical
plane) описывает аппаратно-программные блоки, называемые
физическими объектами (physical entities, PE). Модель, показанная на
рис. 5.2, содержит эти четыре расположенные одна над другой
плоскости, дающие (каждая – со своей степенью детализации)
абстрактное представление тех возможностей, которыми обладает
сеть, построенная в соответствии с концепцией IN.
Верхняя плоскость модели – плоскость услуг – представляет
услуги так, как они «видны» конечному пользователю. Такое
представление не содержит информации о способе и деталях
реализации услуги в сети. Зато на этой плоскости видно, что услуги
110
(services) компонуются из одной или из нескольких разных
стандартизованных составляющих, каждую из которых пользователь
воспринимает как одно из характерных свойств или, что то же самое,
как один из атрибутов услуги (service features. SF).
Услуга 1
Услуга 2
SF1
SF3
SF2
Плоскость услуг
SIB1
POI
BCP
POR SIB2
SIBn
Глобальная функциональная плоскость
IF
I EF
F F
EF E EF
F F
A EF
E E
A EF A
FE2 EF
Информационные потоки (IF)
FE1 FE3
Распределенная функциональная плоскость
PE2
FE1 FE2
FE3
P
PE1
Физическая плоскость
BCP Базовый процесс обслуживания вызова PE Физический элемент

EF Элементарная функция POI Инициациирующая точка
FE Функциональный объект POR Точка возврата
FEA Действие функционального объекта SF Атрибут услуги
IF Информационный поток SIB Независимый конструкционный блок
P Протокол
Рис. 5.2. Концептуальная модель IN
На глобальной функциональной плоскости «появляется» сеть

IN в виде единого функционального объекта. На этой плоскости
111
представлены независимые от услуг конструкционные блоки (SIB –
Service independent building block), одним из которых является SIB,
реализующий базовый процесс BCP, а также точка обращения BCP к
другим SIB, называемая инициирующей точкой (POI – Point Of
Initiation) и точки возврата в BCP (POR – Point Of Return). BCP
выполняет традиционные для коммутационной станции функции
(установление соединения, разъединение, хранение оперативных
данных, необходимых для дальнейшей обработки) и имеет
возможность обращаться к другим процессам при обнаружении
запроса услуги IN. POI представляет собой функциональный
интерфейс между логикой BCP и логикой другого процесса, который
обеспечивает предоставление услуги (или одной из составляющих
услуги) IN. После завершения этого другого процесса происходит
возврат через другой функциональный интерфейс (POR) в процесс
BCP, который продолжает работу, используя данные, полученные при
возврате. Необходимость в спецификации точек POI и POR вызвана
тем, что одна и та же «цепочка» SIB может представлять совершенно
разные услуги (или составляющие услуг), смотря по тому, в каких
точках процесса BCP она начинает и/или заканчивает свои действия.
Здесь уместно отметить, что все изложенное в этой части
базируется на рекомендациях серии Q.12xy ITU-T, где индекс x
указывает, является ли рекомендация общей (т.е. применимой ко
всем версиям IN), или относится к определенному набору
функциональных возможностей (CS). Значение 0 указывает, что
рекомендация серии носит общий характер; другие значения
обозначают номер CS. К настоящему моменту опубликованы
рекомендации для CS-1 и CS-2, CS-3, а CS-4 находится на стадии
разработки. Индекс y обозначает тему рекомендации: 0 означает, что
рекомендация является вводной к серии, а 1 обозначает принципы
архитектуры IN. Таким образом, рекомендация Q.1201 посвящена
общим принципам, рекомендация Q.1211 – принципам архитектуры
IN, относящимся к CS-1, и т.д. Значение 9 резервировано для
112
руководства пользователя IN. Представленные на рис. 5.2
функциональные плоскости отражены в остальных значениях
индекса y: 2 – рекомендации, относящиеся к плоскости услуг, 3 – к
глобальной функциональной плоскости, 4 – к распределенной
функциональной плоскости и 5 – к физической плоскости. Значение у
= 8 – это рекомендации для прикладного протокола INAP. Как и для
большинства других стандартов ITU-T, региональные органы
стандартизации разрабатывают национальные спецификации IN.
Несмотря на то, что как в CS-1, так и в CS-2 стандарты для IN
обеспечили формализованную модель создания услуг
спецификациями блоков SIB – рекомендации Q.1203 (общие
аспекты), Q.1213 (CS-1) и Q.1223 (CS-2), – после CS-2
стандартизация SIB прекратилась.
Функциональная архитектура IN CS-1 и механизм активизации
взаимодействия между ее элементами представлены на рис. 5.3,
являющимся, в определенном смысле, развитием рис. 5.1 (более
детально отражены подмножество стандартизованных к настоящему
моменту FE и их взаимосвязь). FE интеллектуальной сети
группируются в соответствии с их ролью в поддержке IN: FE,
участвующие в выполнении услуг, и FE, участвующие в создании
услуг и управлении услугами.
113
SDF
К другим узлам SCP и/или SDP в
SDP этой или другой сети
SCF
SDF
SCP
Сеть ОКС7
SCF
SRF SDF
AD
IP
SCF SRF
SCF SSP
SSF CCF SSF
CCF
SDF CCAF SDF
SRF
SN
Физические объекты (РЕ)

AD Вспомогательный узел управления
IP Интеллектуальная периферия
SSP Узел коммутации услуг
SCP Узел управления услугами
SN Узел услуг
SDP Узел хранения данных для услуг IN
CCF Функциональный объект управления связью пользователя
CCAF Функциональный объект поддержки доступа
SCF Функциональный объект управления услугами
SDF Функциональный объект предоставления данных для услуг
SRF Функциональный объект специализированных ресурсов
SSF Функциональный объект коммутации услуг
Рис. 5.3. Архитектура CS-1 по рекомендации ITU-T Q.1215
К представленным на рис. 5.3 функциональным объектам

относятся
 Функциональный объект поддержки доступа (call control agent
function, CCAF) содержит функции, обеспечивающие доступ
пользователя к услугам IN; может рассматриваться как посредник
телефонного аппарата или ISDN-терминала, с помощью которого
пользователь взаимодействует с сетью.
 Функциональный объект управления связью пользователя (call
control function, CCF) содержит базовые функции обработки
запроса связи и управления коммутацией, включая функции
установления, поддержки и разрушения соединений. Именно CCF
реализует триггерные возможности, которые обсуждались выше,
однако для полной их поддержки, а также для взаимодействия
CCF с функциональным объектом управления услугами, требуется
еще один объект, который имеет название функциональный
114
объект коммутации услуг (service switching function, SSF).
Предполагается, что объекты SSF и CCF физически совмещены,
т.е. они не могут размещаться в разных физических объектах PE.
 Функциональный объект управления услугами (service control
function, SCF) содержит логику услуг и управляет действиями
SSF/CCF и других функциональных объектов.
 Функциональный объект специализированных ресурсов
(specialized resource function, SRF) обеспечивает воспроизведение
записанных речевых сообщений и сбор входных данных от
пользователя (либо в виде сигналов DTMF, либо в виде речевых
сигналов, в зависимости от используемых устройств), отвечает за
организацию конференцсвязи, поддержку факсимильной связи и
преобразование некоторых протоколов, а также за
преобразование «текст-речь» и «речь-текст».
 Функциональный объект предоставления данных для услуг
(service data function, SDF) обеспечивает доступ SCF в реальном
времени к данным, требующимся для предоставления услуг IN, и
проверку этих данных.
На рис. 5.4 представлена модель состояний базового процесса
обслуживания вызова (BCSM) для CS-2, которая специфицирована в
последнем из опубликованных стандартов. BCSM – это модель
действий CCF, необходимых для организации и поддержания связи
между пользователями. BCSM моделирует состояния базового
процесса обслуживания и исходящих, и входящих вызовов, но мы
ограничимся только рисунком, относящимся к исходящему вызову.
Основные состояния процесса в модели O_BCSM (O – outgoing, т.е.
исходящая часть), как их видит АТС, показаны внутри
прямоугольников; их называют PIC (points in call). Кроме того,
имеются и другие состояния, которые называются точками
обнаружения (detection points, DP); на рис. 5.4 они показаны
квадратами. Именно в точках DP АТС может прервать обработку
вызова путем передачи сообщения к SCF. Каждая DP может быть
115
либо задействованной (armed), либо не задействованной (unarmed).
Внешняя логика услуг (внутри SCF) обнаруживает DP только тогда,
когда та задействована. DP может быть задействована либо
статически (со стороны SMF, как результат ввода в действие
атрибута услуги), либо динамически (со стороны SCF). Если DP была
задействована статически, она остается задействованной до тех пор,
пока SMF не выведет её из этого состояния, т.е. пока
предоставляется та услуга, для которой она нужна; такая DP
называется триггерной точкой обнаружения (trigger detection point,
TDP). Если же DP была задействована динамически, она остается в
этом состоянии не дольше, чем длится обусловленное ее
обнаружением взаимодействие между SCF и SSF; такая DP
называется точкой обнаружения события (event detection point,
EDP).
Исх.ст. "Исходное" Исх.ст. "Выход
по исключению"
O_Null O_Exception
Исх.ст. "Отказ от связи"
O_Abandon "Попытка исходящего вызова"
Origination_Attempt
"Проверка права на
исходящий вызов"
Authorize_Origination_Attempt
"Проверка успешна"
Origination_Attempt_Authorized
"Прием информации"
Collect_Information
"Информация накоплена"
Collected_Information
"Анализ информации"
Analyse_Information
"Информация проанализирована"
Analysed_Information
"Выбор маршрута"
Select_Route
"Маршрут не найден"
Route_Select_Failure
"Проверка прав установления связи"
Authorize_Call_Setup
"Установление связи"
Исх.ст. "Запрос от Send_Call
пользователя" Исх.ст. "Занято"
O_Mid_Call "Вызов принят" O_Called_Party_Busy
O_Term_Seized
Исх.ст. "Оповещение"
O_Alerting
Исх.ст. "Отсутствие ответа"
Исх.ст. "Запрос от пользователя"
O_No_Answer
O_Mid_Call "Ответ"
O_Answer
O_Mid_Call Исх. ст. "Активное состояние"
O_Active
"Повторный ответ"
O_Re-answer
Исх.ст. "Связь приостановлена"
O_Suspend
Исх.ст. "Приостановка связи"
Исх.ст. "Разъединение" O_Suspended
O_Disconnect

O_Mid_Call
Переход
Состояние процесса
Точка обнаружения Исх.ст. Исходящая сторона
116
Рис. 5.4. Модель BCSM
В условиях уже упоминавшейся конвергенции сетей и услуг связи

сохраняется ключевой принцип отделения организации новых
телефонных услуг от транспортировки, составляющий основу
Интеллектуальной сети (рис. 5.5). Точно так же, как было только что
описано, узлы коммутации услуг распознают вызовы, требующие
услуг IN, и обслуживают эти вызовы, взаимодействуя с
централизованным узлом SCP. Наличие на рис. 5.5 элементов
мобильной IN подразумевает взаимодействие протоколов INAP и
TCAP с другими протоколами ОКС7 – MAP (Mobile Applications Part),
IS41 и CAMEL (Customized Applications for Mobile Network Enhanced
Logic).
Для расширения представлений об Интеллектуальной сети
следует обратиться к литературе к части 5. Там отмечены основные
преимущества концепции IN в свете проблем конвергенции сетей:
гарантированное сквозное (end-to-end) качество обслуживания (QoS),
экономичное введение новых услуг через INAP или с помощью SN
(Service Node) и др. Благодаря этому, по всей вероятности, именно
Интеллектуальная сеть окажется тем мостом, который позволит
традиционным телефонным сетям (как стационарным, так и
мобильным) взаимодействовать с IP-сетями. Такая тенденция
эволюции Интеллектуальной сети проявляется в создании
протоколов WAP (Wireless Application Protocol), RADIUS (Remote
Authentication Dial-In User Service), LDAP (Lightweight Directory Access
Protocol) и соответствующих этим протоколам технологий.
117
SCEP/SMP
SCP
HLR
Proxy
Сеть Сеть
TCP/IP ОКС7
MSC/SSP IP
Сервер
SSCP IP
Шлюз
Привратник Привратник
SSP IP
Шлюз
Рис. 5.5. Эволюция концепции IN
В рамках представленной на рис. 5.5 эволюции концепции

Интеллектуальной сети, интерес представляют разработки рабочих
групп PINT/SPIRITS (SIP-скрипты и взаимодействие IPSSF с SIP) и
Eurescom (взаимодействие IPSSF с H.323). Эти решения
обеспечивают доступ к услугам IN пользователей IP-телефонии, что
особенно актуально для западноевропейских стран, где были
сделаны значительные вложения в оборудование Интеллектуальных
сетей. PINT и SPIRITS ориентированы на поддержку равноправного
доступа компьютерного терминала с пакетной передачей речи и
обычных телефонов ТфОП или GSM ко всем услугам; оба подхода,
так или иначе, ориентируются на протокол SIР, о чем будет сказано
ниже.
Внедрение Интеллектуальной сети в процессе развития
традиционной ТфОП сдерживалось рядом принципиальных
ограничений подхода IN. К ним относятся:
 необходимость существенных начальных инвестиций,
 относительная сложность протоколов INAP и TCAP,
 невостребованность целого ряда услуг из списка CS-1 (Follow me,
например),
118
 централизация биллинга и управления услугами, ограничивающая
возможности выполнения этих функций конечными
пользователями,
и некоторые другие.
Разрабатываемые сегодня интеллектуальные коммутационные
платформы на базе технологий компьютерной телефонии третьего
поколения сами являются интегрированными коммутаторами и
процессорами поддержки услуг с начислением платы за них. Это
объективно вызывает смещение интеллекта из традиционных узлов
IN к краям сети, чему посвящен следующий параграф.
5.3. Подход компьютерной телефонии

Упоминавшиеся в начале главы и активно распространяющиеся
в ЕСЭ РФ региональные узлы услуг, называемые в рекомендациях
ITU-T узлами услуг SN (Service Node), основаны на технологии
компьютерной телефонии CTI (Computer Telephony Integration).
Оборудование SN всегда гораздо компактнее и дешевле SCP,
размещается, как правило, в одной стойке, использует современные
универсальные промышленные процессоры, речевые порты, порты
трактов E1 с ОКС7 или ISDN PRI, средства, позволяющие
воспроизводить и записывать речь, распознавать сигналы DTMF и
межстанционные сигналы, генерировать стандартные акустические
сигналы (Занято, Ответ станции и др.), а также синтезировать речь из
текста.
Наряду с рекомендациями ITU-T построение SN
регламентируется также стандартами ECTF, среди которых важную
роль играет набор стандартов, первоначально разработанных
Европейской ассоциацией производителей компьютеров (ECMA) и
называющихся CSTA (Computer-Supported Telephony Applications).
Последняя версия CSTA (фаза III) была утверждена в июле 1999 г.
как международный стандарт ISO. Существуют и другие стандарты,
119
применимые в сфере CTI, например, прикладной интерфейс АТС-
компьютер SCAI (Switch-Computer Application Interface).
Следует обратить внимание на сходство методов и терминологии
IN и CSTA, SCAI и т.п. Это и не удивительно, поскольку как
концепции, так и цели CTI очень схожи с концепциями и целями IN.
Базовой концепцией CSTA, например, является соединение, которое
определяется как логический объект, абстрактно отображающий
ассоциацию между определенным устройством CSTA и сеансом
связи, в котором участвует это устройство (устройство CSTA – это
объект, отображающий физический или логический компонент сети,
например, терминал пользователя, сетевой интерфейс и др.; сеанс
связи, или просто сеанс, – это логический объект, отображающий
процесс обслуживания вызова, т.е. процесс предоставления
пользователю нужной ему связи или услуги, сопровождения этой
связи/услуги и ее прекращения/отмены). Переход объекта
соединение от одного состояния к другому вызывается либо
действием пользователя, либо операцией CSTA. Рис. 5.6
демонстрирует модель состояний «соединения» CSTA.
Нулевое
(исходное)
Извещение
о вызове
Иницииро-
вание
Отказ
Поста-
новка
в очередь Х
Х
Х
Установ- Х Х
ление Удержание
соединения
Рис. 5.6. Модель состояний объекта «соединение» CSTA
5.4. Услуги ТфОП и IP-сетей
120
Тенденция конвергенции ТфОП и IP-сетей ведет к переходу от
традиционного подхода Интеллектуальной сети к
неинтеллектуальным IP-сетям с интеллектуальными средствами,
устанавливаемыми на краях сети (вплоть до персональных
компьютеров оконечных пользователей). Это связано с тем, что
практически все элементы архитектуры IP-сетей – шлюзы,
маршрутизаторы, привратники, программные коммутаторы,
терминалы (PC, WAP), клиентские приложения (браузеры, FTP, е-
mail, чат), сетевые серверы (RADIUS, LDAP, DNS), серверы
приложений (HTTP, FTP, Java, SIP, POP3) – управляются совершенно
разными сетевыми структурами, а весьма многие из этих элементов
вообще никак не управляются.
Эта тенденция приводит сегодня к проектированию наиболее
перспективных и доходных IN-услуг, которые в подавляющем
большинстве случаев достаточно быстро окупаются. При этом
проводится интеграция новых и существующих услуг с современной
инфраструктурой IP-сети и услуг Интернет.
Например, совместными усилиями ТфОП и Интернет
реализуется услуга Internet Call Waiting (ICW), обеспечивающая
телефонный вызов пользователя, занятого сеансом с Интернет.
Получив извещение о телефонном вызове, пользователь имеет
возможность приостановить сеанс с Интернет и либо ответить на
этот вызов, либо переадресовать его на другую линию или к
почтовому ящику и т.п. Еще одним примером услуг того же класса
является услуга Click-to-Dial (CTD), дающая пользователю
возможность во время сеанса с Интернет произвести исходящий
телефонный вызов путем активизации пиктограммы на экране
компьютера. Особенно эффективное использование этой услуги
связано с возможностью вызвать телефонного оператора той
компании, которая интересует пользователя, просто нажав на
указатель на Web-странице этой компании.
121
Ее модификация известна как услуга запроса из Интернет
обратного телефонного вызова (Click-to-Dial-Back) и позволяет
пользователю, находящемуся в Интернет, запрашивать телефонное
соединение с другим абонентом, устанавливаемое через ТфОП. Как
и в некоторых других приведенных выше примерах гибридных
(ТфОП/Интернет) услуг, важным предварительным условием
является то, что пользователь услугой должен иметь как телефонный
доступ к ТфОП (через телефонный аппарат), так и доступ к Интернет
(через РС). Типичное применение такой услуги – т.н. онлайновый
шоппинг (online shopping) или Интернет-магазин: пользователь,
просматривающий онлайновый каталог товаров, щелкает мышью на
кнопке, инициируя при этом запрос телефонного вызова к нему от
представителя службы сбыта интересующего его Интернет-магазина.
Следует отметить, что как и в случае с рассмотренными выше
услугами Freephone из списка CS-1, здесь могут быть реализованы
гибкие опции оплаты услуги, а также маршрутизация вызова в
зависимости от времени суток, дня недели, наличия незанятых
операторов на разных объектах и т.д.
Рассмотрим работу услуги click-to-call-back подробнее (рис. 5.7).
Пользователь А хочет, чтобы с ним связался по телефону оператор
службы сбыта того Интернет-магазина, Web-страницу которого он в
настоящее время просматривает, и щелкает мышью на
соответствующей кнопке. Предполагается, что А зарегистрирован у
поставщика услуги и, таким образом, может быть должным образом
аутентифицирован. Сеть Интернет передает полученный от A запрос
на Web-сервер (B), который формирует соответствующий запрос к
SCP (или SN) Интеллектуальной сети (С). В результате выполнения
логики услуги в SCP и под воздействием его команды
соответствующему SSP последний сперва создает соединение с
оператором службы сбыта F (участок 1), затем – соединение с
пользователем А (участок 2) и, наконец, объединяет эти два участка в
двустороннюю связь между А и F. При этом узел SMP отвечает за
122
передачу в SСР логики услуги, созданной в среде SCE, и на Web-
сервер – параметров, относящихся к этой услуге. Услугу click-to-call-
back можно затем дополнить до полноценной функции Сall-центра.
Узел SN может, например, выбирать оператора F в зависимости от
времени суток, дня недели, доступности оператора, его нагрузки по
сравнению с нагрузкой других, не занятых в данный момент
операторов службы, и т.д. Информация об опыте реализации этой
услуги приведена в RFC 2458.
B
Web-
сервер
Интернет
A
C
SCP
SCE SMP или
SN
SSP
I
BR P
D N A
IS и IN
ил
SSP SSP
1 F
2
SCE - Среда создания услуг
SN - Узел услуг (интеллектуальная платформа)
SMP - Узел эксплуатационного управления услугами
SSP - Узел коммутации услуг
Рис. 5.7. Услуга click-to-call-back
Когда услуга click-to-call-back реализована, ее можно творчески

развивать практически безгранично. Начнем с того, что пользователи
могут, регистрируясь на Web-узле, указывать, какие группы товаров
их интересуют. Таким образом, могут создаваться файлы
параметров, описывающие профили пользователей, а с помощью
SMP эти файлы-профили могут рассылаться на все SN и SCP сети.
Далее, услуга может предусматривать предоставление Web-сервером
ее интерактивной видео-презентации, которая может быть
синхронизирована с аудио-презентацией, предоставляемой
специализированным ресурсом интеллектуальной платформы. По
123
окончании презентации интеллектуальная платформа будет
создавать вызов обычным для услуги click-to-call-back путем.
Услуга Internet customer profile management ICPM позволяет
управлять профилем услуги Интеллектуальной сети с персонального
компьютера прямо из Web-страницы. В настоящее время
пользователь услугой IN может управлять ее профилем при помощи
сигналов DTMF или с помощью оператора, что гораздо менее
удобно.
Услуга второй виртуальной линии VSL (virtual second line)
позволяет пользователю ответить на входящий телефонный вызов,
не прерывая сеанса связи с Интернет. Для этого может быть
использован специальный шлюз, преобразующий речевой сигнал в
поток передачи речи к терминалу пользователя по протоколу VoIP
(Voice over IP). Реализация этой услуги представлена на рис. 5.8.
A
1
Сервер
АТС удаленного
доступа
Б
3
3
3
2
3 Интернет
Шлюз
IP-телефонии
Рис. 5.8. Услуга virtual second line
124
Пусть пользователь Б заказал себе услугу второй виртуальной
линии. С точки зрения АТС она представляет собой услугу
переадресации вызова к шлюзу IP-телефонии, когда вызываемый
абонент занят. Если абонент А звонит занятому абоненту Б (маршрут
1), то АТС, согласно логике услуги, переадресует вызов к шлюзу
(маршрут 2), который определяет Интернет-адрес пользователя Б, а
затем переправляет вызов средствами IP-телефонии к РС
пользователя Б (маршрут 3). На экране этого PC появляется
уведомление о входящем телефонном вызове, и затем происходит
телефонный разговор.
Услуга запрос факсимильной связи из Интернет (click-to-fax)
позволяет пользователю запрашивать из сети Интернет (через IP-
хост) передачу факсимильного сообщения по указанному номеру. Эта
услуга особенно привлекательна в тех случаях, когда сообщение
нужно передать лицу, у которого есть факсимильный аппарат, но нет
доступа к Интернет. Рассмотрим в качестве примера сценарий, когда
пользователь Интернет бронирует место в одной из гостиниц на
пляжах Флориды, пользуясь Web-страницей московского
турагентства, содержащей информацию о гостиницах в основных
крупных городах мира. Предположим, что та гостиница в Майами,
которую выбрал пользователь, не имеет доступа к Интернет, но
имеет факсимильный аппарат. Пользователь заполняет бланк заказа
места в гостинице и затем щелкает мышью на кнопке для оправления
заполненного бланка поставщику услуги. Оборудование этого
поставщика формирует запрос факсимильной связи и пересылает
его вместе с бланком заказа на узел ТфОП. При получении запроса и
приложенной к нему информации, ТфОП преобразует информацию в
формат факсимильной связи и пересылает её в гостиницу во
Флориде.
Еще одна услуга – запрос из Интернет ответа по факсу (click-
to-fax-back) – позволяет пользователю, находящемуся в сети
Интернет, запрашивать через IP-хост передачу ему факсимильного
125
сообщения. Теперь клиент из предыдущего примера может запросить
от гостиницы подтверждение, которое та передаст по факсу. Другое
полезное применение этой услуги – случай, когда объем графической
информации, который пользователь должен получить, настолько
велик, что передача её к РС пользователя по Интернет заняла бы
много времени и потребовала бы слишком большого объема
дисковой памяти.
Услуга получение Интернет-контента в речевой форме (voice-
access-to-content) дает возможность пользователю, находящемуся в
Интернет, запросить определенную информацию из Интернет с
передачей ее в речевой форме через ТфОП, используя в качестве
устройства получения информации свой телефонный аппарат.
Вариантом этой услуги является использование телефонного
аппарата как для запроса информации из Интернет, так и для
получения этой информации. Другими словами, пользователь просит
с телефонного аппарата, используя речевые команды, чтобы на его
телефонный аппарат через ТфОП поступила в речевой форме
определенная информация из Интернет. Наиболее перспективна эта
услуга для абонентов сетей мобильной связи, т.к. они смогут
совмещать управление автомобилем с прослушиванием Web-
информации, что сопряжено с гораздо меньшим риском для жизни,
чем получение информации в цифровой форме из Интернет.
Заметим, что слово click (щелчок мышью) в названиях этих услуг
не следует понимать буквально и рассматривать как предписанный
способ активизации услуг. Это слово используется для того, чтобы
подчеркнуть тот факт, что инициирование рассматриваемых услуг
происходит в сети Интернет, где наиболее распространенным
действием пользователя является наведение стрелки мышью на
объект с последующим щелчком кнопкой мыши.
Во встречном направлении, ТфОП с помощью IN может немало
сделать для IP. Сегодня роль оператора местной телефонной сети
сводится, в большинстве случаев, к организации коммутируемой
126
связи между пользователем и Интернет-поставщиком (ISP). Услуги IN
могут помочь оператору местной телефонной сети оптимизировать
доступ к Интернет-поставщику, организовать для таких соединений
альтернативный биллинг, предоставить универсальный номер для
всех ISP Point of Presence (IPоP), организовать бесплатные вызовы
Freephone, предоплаченные вызовы Prepaid calling и т.п. В полном
соответствии с правилом «помогая другим, поможешь и себе»
местная телефонная сеть может не только повысить свои доходы за
счет предоставления IN-услуг для доступа пользователей к Интернет,
но и уменьшить расходы путем наискорейшего отвода IP-трафика из
своей сети к Интернет-поставщику.
Внедрение услуг на основе IP-протокола означает, что
потребуются сведенные вместе IN-услуги передачи речи и передачи
данных. Один аспект этого состоит в том, что IN-услуги перестанут
быть такими, что запрос к IN-серверу создается только при вызове,
обслуживание которого требует обращения к IN. Приложения
передачи данных, функционирующие в системах типа клиент/сервер,
часто требуют выполнения тех же действий для каждого вызова или
сеанса связи и предъявляют высокие требования к существующим
системам ОКС7/IN, а генерирующее эти запросы программное
обеспечение часто имеет более высокий уровень взаимодействия,
чем сигнализация, связанная с телефонным вызовом. Со временем
разница между этими двумя типами IN-приложений будет исчезать,
но сегодняшние платформы IN, ориентированные на речевой трафик
с коммутацией каналов, могут встретить весьма серьезные трудности
при обслуживании трафика передачи данных и пакетов, а также
объединенного трафика.
5.5. Конвергенция сетей и услуг связи

Сетевая структура, иллюстрирующая конвергенцию IN/ТфОП и
IP-сети, представлена на рис. 5.9. Из сказанного выше вытекает
целесообразность организации доступа к услугам IN из
127
коммутационных узлов мобильных сетей и/или из оконечных точек IP-
сетей, аналогичного доступу из узлов коммутации услуг (SSP)
обычных ТфОП. В первую очередь, это относится к организации
триггерных точек в процессе обработки вызова с передачей/приемом
в этих точках сигналов, нужных для последующей маршрутизации, а
также к организации доступа к IN-услугам, предоставляемым
сетевыми компонентами типа SCP. Отметим некоторые другие
аспекты представленной на рис. 5.9 конвергенции ТфОП/IN и IP.
Подключение ТфОП/ISDN к IP с использованием первичного доступа
PRA ISDN зачастую обходится гораздо дороже, чем подключение с
применением широко используемого сегодня операторами связи
протокола сигнализации ОКС7. Для снижения расходов лучше всего
подключать сеть IP к сети PSTN/ISDN через сервер удаленного
доступа RAS, управляемый по протоколу MGCP.
ТфОП
Интеллектуальная
периферия SCP
Интернет-серверы
База данных
ATC
ATC
Привратники
Шлюзы
ИНТЕРНЕТ
ОКС7 АТС IPU
VoIP
SSP
IP IP
Маршрутизатор
Маршрутизатор Коммутатор
RAS
модемы IP-СЕТЬ
Пользователь
Абонент Абонент
IP
Рис. 5.9. Конвергенция IN и IP
При взаимодействии абонентов сети ТфОП/IN с абонентами IP-

сетей, использующих протокол Н.323/SIP, трудно воспользоваться
всеми возможностями современных речевых услуг из-за того, что
совсем не просто решаются задачи взаимодействия систем
сигнализации и адресации. Одно из возможных решений проблемы
128
преобразования адресов из стандарта Е.164 в IP – использование на
границе сети ТфОП транспортных шлюзов для преобразования
сигнализации ОКС7 в Н.323/SIP. Поддержка протоколов Н.323/SIP,
ОКС7 и IN, предусмотренная в контроллере транспортных шлюзов,
открывает доступ к большинству речевых услуг, включая Premium
Rate, виртуальные выделенные сети, Центрекс, завершение
телефонного вызова в случае занятости или отсутствия вызываемого
абонента, идентификацию вызывающего абонента и многие другие.
Средства IP-телефонии расширяют концепцию IN, изначально
созданную для ТфОП, и позволяют реализовать, одинаково легко для
телефона, мобильного терминала и PC, доступ к услугам, которые
могут разворачиваться одинаково просто в телефонных сетях и в
сетях данных, предлагая пользователю, вне зависимости от того,
какой из этих сетей он принадлежит, одинаковые возможности,
сочетая передачу речи и данных, т.е. объединяя преимущества обоих
миров. Более детальное обсуждение услуг Интеллектуальной сети,
управляемых пользователем с помощью телефонного аппарата и
сигнализации DTMF, и услуг IP-сетей, доставляющих пользователю
от соответствующих Web-серверов с помощью протоколов TCP/IP
информацию в форме HTML (HyperText Markup Language) или Java-
апплетов, приводится в книгах, указанных в списке литературы.
Это – книга «Интеллектуальные сети», касающаяся
классического подхода с сосредоточением интеллекта в центре сети,
книга «Call-центры и компьютерная телефония», описывающая
подход Service Node, и книга «IP–телефония», рассматривающая
услуги IP-сетей, третьего компонента процесса конвергенции услуг
инфокоммуникаций. Они вместе иллюстрируют подход взвешенного
применения обоих принципов – и централизованного, и
распределенного интеллекта – с пропорциональным использованием
идей и методов, пришедших из Интеллектуальных сетей ТфОП и из
компьютерных IP-сетей. Такой подход пропорциональной
архитектуры Интеллектуальной сети так и называется PRIN-подход
129
(PRIN - PRoportion Intelligent Network). Суть PRIN-подхода
заключается в том, что ряд услуг, скажем, федерального класса,
реализуется с помощью централизованного SCP, подключаемого по
протоколу INAP, а часть услуг регионального класса проходит через
один из многочисленных узлов услуг SN, распределенных на
окраинах сети и включаемых через интерфейсы PRI, ISUP и даже
2ВСК. Следует подчеркнуть, что совсем не обязательно, чтобы
федеральные услуги организовывались исключительно через SCP.
Сегодня изобретены чрезвычайно интересные технологии
распределенного сетевого интеллекта, позволяющие устанавливать
логику услуг где угодно в сети, а данные для маршрутизации – в
сетевых базах данных, и, таким образом, организовывать
федеральные услуги на базе объединения распределенных SN.
5.6. Заключение
Анализ рассмотренных в главе элементов Интеллектуальной
сети, оборудования компьютерной и IP-телефонии, узлов услуг SN
позволяет сделать заключение о том, что независимо от того, где
расположен интеллект услуги – в центре сети или на ее краях, –
объединенные в процессе конвергенции функциональные
возможности сетей IN и IP позволят наиболее эффективно
организовать сетевое взаимодействие с целью управления как
услугами, уже внедренными или готовыми к внедрению, так и совсем
новыми услугами, которые еще только будут придуманы в результате
объединения усилий специалистов новой индустрии
инфокоммуникаций.
1. Гольдштейн Б.С., Ехриель И.М., Рерле Р.Д. Интеллектуальные
сети//М.: Радио и связь-2000.
2. Гольдштейн Б.С., Фрейнкман В.А. Call-центры и компьютерная
телефония//СПб.: BHV-2002.
130
Часть 6. Сетевое взаимодействие в NGN
Взаимодействие сетей Н.323 и SIP. Функциональные возможности
Softswitch: первые международные стандарты в области NGN,
рекомендации ITU-T серии Y, архитектура NGN, стек протоколов
Н.323, понятия шлюза и гейткипера, организация конференций,
протокол SIP, сетевое взаимодействие H.323 и SIP. Описание
протоколов управления медиашлюзами MGCP, MEGACO/H.248.
Тестирование протоколов сетевого взаимодействия NGN.
6.1. Softswitch
Основу сетевого взаимодействия в сетях связи следующего
поколения NGN (Next Generation Network) составляет гибкий
коммутатор Softswitch. Термин Softswitсh был придуман Айком
Элиотом при разработке интерфейса между интерактивной речевой
системой (IVR) и АТС с коммутацией каналов в операторской
компании MCI. Перейдя в 1997 году из MCI в компанию Level3
Communications, он, вместе с Эндрю Дуганом и Маурицио Аронго,
придумал понятия Call Agent и Media Gateway. Ими же была начата
разработка контроллера транспортного шлюза MGC (Media
Gateway Controller), функции которого, как и функции Call Agent,
собственно говоря, и выполняет Softswitch. Тогда же Кристиан
Хюйтема из компании Bellcore придумал протокол управления
шлюзами сигнализации SGCP (Signaling Gateway Control Protocol).
На базе этих разработок и совместными усилиями этих специалистов
в IETF была создана первая спецификация протокола управления
шлюзами MGCP (Media Gateway Control Protocol). Это одна ветвь
родословной Softswitch.
Другим предшественником Softswitch является привратник GK
(Gatekeeper). Более того, названия контролер MGC и привратник
GK являются терминами, адекватными ранним формам Softswitch.
Понятие привратник зародилась в технологии H.323,
рассматриваемой ниже в этой части.
131
В задачи привратника входит преобразование адресов (имени
или адреса электронной почты – для терминала или шлюза – и
транспортного адреса) и управление доступом (авторизация доступа
в сеть). Согласно принципам рекомендации H.323 привратник должен
управлять действиями в определенной зоне сети, представляющей
собой совокупность одного или нескольких шлюзов и управляющего
ими единственного привратника. При этом привратник
рассматривается как логическая функция, а не как физический
объект.
Softswitch является носителем интеллектуальных
возможностей сетевого взаимодействия, который координирует
управление обслуживанием вызовов, сигнализацию и функции,
обеспечивающие установление соединения через одну или
несколько сетей.
Подчеркнем, что Softswitch – это не только одно из сетевых
устройств. Это также и сетевая архитектура, и даже, в определенной
степени, - идеология построения сети. Именно поэтому основной
упор в приведенном определении сделан на функциональные
возможности. При этом, строго говоря, под данное здесь
определение не подпадают отдельные устройства с ограниченными
функциями – привратники Н.323 или SIP-прокси, которые в
рекламных целях их продавцы также именовали Softswitch.
В первую очередь, Softswitch управляет обслуживанием
вызовов, т.е. установлением и разрушением соединений, выполняя
функции Call Agent . Точно так, как это имеет место в традиционных
АТС с коммутацией каналов, если соединение установлено, то эти
функции гарантируют, что оно сохранится до тех пор, пока не даст
отбой вызвавший или вызванный абонент. В число функций
управления обслуживанием вызова Call Agent входят распознавание
и обработка цифр номера для определения пункта назначения
вызова; а также распознавание момента ответа вызываемой
стороны, момента, когда один из абонентов кладет трубку, и
132
регистрация этих действий для начисления платы. Таким образом,
Softswitch фактически остается все тем же привычным
коммутационным узлом, только без цифрового коммутационного
поля. Отметим, что Softswitch является более точным термином, чем
Call Agent, т.к. последний, в большинстве случаев, предполагает
некое программное обеспечение обслуживания вызовов,
функционирующее на стандартном компьютере.
Другой термин - контроллер транспортного шлюза MGC -
является в большей степени синонимом Softswitch и подчеркивает
тот факт, что он управляет транспортными шлюзами и шлюзами
доступа по протоколу H.248 и ему подобным, рассматриваемым в
главе 6.
Softswitch координирует обмен сигнальными сообщениями
между сетями, т.е. поддерживает функции Signaling Gateway (SG).
Выше сигнализация в сети связи уже сравнивалась с системой
кровообращения в человеческом организме. Если продолжить эту
аналогию, то Softswitch организует это кровообращение и, к тому же,
при необходимости, - переливание крови между разными
организмами. Иначе говоря, Softswitch координирует действия,
обеспечивающие соединение с логическими объектами в разных
сетях и преобразует информацию в сообщениях с тем, чтобы они
были понятны на обеих сторонах несходных сетей, что будет
несколько подробнее рассмотрено в следующем параграфе.
6.2. Системы сигнализации

Основные типы сигнализации, которые использует Softswitch при
сетевом взаимодействии, - это сигнализация для управления
соединениями, сигнализация для взаимодействия разных Softswitch
между собой и сигнализация для управления транспортными
шлюзами. Основными протоколами сигнализации управления
соединениями сегодня являются SIP-Т, ОКС7 и H.323, причем, по
мнению авторов, именно в такой последовательности. В качестве
133
опций используются протокол E-DSS1 первичного доступа ISDN,
протокол абонентского доступа через интерфейс V5 (или его Sigtran-
версию V5U), а также все еще актуальная в отечественных сетях
связи сигнализация по выделенным сигнальным каналам R1.5.
Основными протоколами сигнализации управления
транспортными шлюзами являются MGCP и MEGACO/H.248, а
основными протоколами сигнализации взаимодействия между
коммутаторами Softswitch являются SIP-T и BICC.
На рис. 6.1 представлено взаимодействие Softswitch с
различными существующими и перспективными элементами сети
связи общего пользования (ССОП). Там же видно и разделение
функций Softswitch по управлению соединениями в нижележащем
уровне транспортных (медиа) шлюзов, а также взаимодействие
Softswitch и серверов приложений на верхнем уровне.
Нижний уровень в этом контексте может рассматриваться как
транспортная плоскость, в которой физически передается как
речевой трафик, так и трафик данных. Такая уровневая структура
обеспечивает гибкость выбора аппаратного обеспечения (различных
транспортных шлюзов).
Верхний уровень на рис. 6.1 восходит по своей идеологии к узлу
управления услугами SCP (Service Control Point) классической
Интеллектуальной сети, рассмотренной в части 4. Но, будучи на 20
лет моложе последнего, этот уровень позволяет через прикладные
программные интерфейсы API типа JAIN или PARLAY создавать
массу новых приложений, которые невозможны в архитектуре
традиционной телефонии с коммутацией каналов.
134
Ñåðâåðû ï ðèëî æåí èé
IP-òåëåô î í
Í .323 Áèëëèí ã API WIN SCP IN WEB
Í .323- -R
ñåòü AAA
AP
OSA ,
AY
RA
EL
Ãåéòêèï åð /IN T
PIN M L
PAPL
D
AN
M
IU
CA
R X
S
Í. T
32 S IG
Í .323 3
òåðì èí àë -T Äðóãèå
SIP , SIP
BICC, Softswitch
SIP- H.323
SIP- SIP, SIP-2.0 H.22
òåëåô î í MGC 5, H
ñåòü SIP- P, M .245
ñåðâåð EGA Äðóãèå
Ì ÊÄ SI C O/ H
G .248 IP-ø ëþ çû
, 8 TR
CP .24 AN (IP-ñåòü)
M
MG O/ H
EG
SIP-òåðì èí àë
M O/ H
C
MEGAC
.24
GA
AC
MGCP
GC .2
E
CO P ,
/H
M
P , 48
GA GC
ME M ISUP
,
O/ H.24
2B+D IAD SG Òô Î Ï /ISDN
SHDSL M
SHDSL TD
8
AG PRI AG RTP
IAD
P
ÓÀÒÑ
RT
TG
ADSL Ñåòü
MAK
ÓÀÒÑ RTP IP-ñåòü
MAK TG
RTP
GK - Gatekeeper (Ãåéòêèï åð)

SG - Signalling Gateway (Ñèãí àëüí ûé ø ëþ ç)
ÒG - Trunking Gateway (Ø ëþ ç ñî åäèí èòåëüí ûõ ëèí èé)
AG - Access Gateway (Ø ëþ ç äî ñòóï à)
MAK - Ì óëüòèñåðâèñí ûå àáî í åí òñêèå êî í öåí òðàòî ðû
Рис. 6.1 Softswitch в составе ССОП
В рамках такого «вертикального» подхода на рис. 6.1 показаны

возможности Softswitch, относящиеся к сетевому взаимодействию,
сбору статистической информации, биллинга, мониторинга вызовов и
административных функций, а также взаимодействия с системами
эксплуатационного управления OSS (Operation Support System), в
связи с чем упомянуты протоколы RADIUS и SNMP.
С точки зрения сети коммутации каналов представленный на
рис.6.1 Softswitch заменяет оконечную или транзитную АТС. Он
может поддерживать протоколы ОКС7, E-DSS1, R1.5, V5, выполняя
функции транзитного пункта сигнализации STP или оконечного SP
сети сигнализации ОКС7, причем делать все это более дешевым,
135
простым и удобным в эксплуатации образом, придуманным рабочей
группой SIGTRAN, о чем говорилось в части 3.
Для взаимодействия Softswitch между собой могут применяться
два протокола, один из которых – SIP (SIP-T), разработанный
комитетом IETF и рассматриваемый далее в этой части, а второй –
BICC, специфицированный ITU-T. Сегодня на роль главного
протокола сетевого взаимодействия претендует протокол SIP-T, хотя
BICC обладает возможностью работы и с сигнализацией DSS1, а не
только с ОКС7. Например, в известном решении ENGINE компании
Ericsson взаимодействие между телефонными серверами
(Softswitch) происходит по протоколу BICC CS-1, ориентированном на
работу поверх транспорта ATM (AAL1/AAL2) с последующим
переходом на BICC CS-2, предназначенным для работы в IP-сетях.
Хотя и SIP-T, и BICC представлены на рис. 6.1 и обладают на сегодня
практически одинаковыми функциональными возможностями, а
находящийся в разработке BICC CS-3 даже предусматривает
возможность взаимодействия с SIP-T, всё же практическое
внедрение BICC в оборудовании Softswitch производится обычно из
соображений необходимости работы в ATM-сети. Дальнейшие же
усилия ITU и IETF концентрируются сегодня на развитии SIP и H.248
для сетей NGN.
6.3. Консорциум IPCC

Архитектура Softswitch с самого начала создавалась в органах,
далеких от официальных международных организаций традиционной
телефонии. Первым таким органом был Международный Softswitch-
консорциум ISC (International Softswitch Consortium,),
переименованный позже в IPCC (International Packet Communication
Consortium) и занимающийся продвижением соответствующих
стандартов Softswitch и обеспечением функциональной
совместимости различных технологий Softswitch.
136
При этом IPPC не является органом стандартизации. Он только
продвигает стандарты путем проведения тестов функциональной
совместимости, выработки спецификаций и типовых реализаций для
компаний, желающих разработать приложения на основе стандартов,
установленных IETF и ITU, которые как раз и являются органами
стандартизации. В свою очередь, IPCC организует также проведение
тестов функциональной совместимости, проводит учебные
конференции и учреждает отраслевые рабочие группы по тем или
иным важным направлениям.
6.4. Эталонная архитектура Softswitch

Согласно модели архитектуры Softswitch, разработанной
консорциумом ISC, в этой архитектуре предусматриваются четыре
представленные на рис. 6.2 функциональные плоскости:
 транспортная,
 управления обслуживанием вызова и сигнализации,
 услуг и приложений,
 эксплуатационного управления.
6.4.1. Транспортная плоскость
Транспортная плоскость (Transport Plane) отвечает за
транспортировку сообщений по сети связи. Этими сообщениями
могут быть сообщения сигнализации, сообщения маршрутизации для
организации тракта передачи информации, или непосредственно
пользовательские речь и данные. Расположенный под этой
плоскостью физический уровень переноса этих сообщений может
базироваться на любой технологии, которая соответствует
требованиям к переносу трафика этого типа. Транспортная
плоскость обеспечивает также доступ к сети IP-телефонии
сигнальной и/или пользовательской информации, поступающей со
стороны других сетей или терминалов.
137
Эксплуатационное
управление
Абонентские данные,
поддержка биллинга,
SMNP
Услуги и
приложения
Интеллек-
Сервер услуг и приложений туальные
(SCP, логика управления услугой, сети
ISDN
LDAP-серверы)
вызовами и
SIP, сигнализация Сеть
MGCP, транспортных
Медиа- H.248 Call-Agents, гейткиперы, SIP/SIP-T, коммутаторов
сервер H.323, BICC
контроллеры медиашлюзов
Транспортная
плоскость
Транспортный домен
(маршрутизаторы, ТфОП
коммутаторы, QoS) ОКС7
IP-телефония Домен
IP-PBX взаимодействия
(медиашлюзы,
шлюзы сигнализации и
Домен не IP-доступа взаимодействия) Сети
(шлюзы доступа, IP
VoIP
AG, RAN, IAD)
IP-телефония
УПАТС
Рис. 6.2. Функциональные плоскости архитектуры Softswitch
Как правило, устройствами и функциями транспортной плоскости

управляют функции плоскости управления обслуживанием вызова и
сигнализации, рассматриваемой в следующем подразделе. Сама
транспортная плоскость делится на три домена:
 домен транспортировки по протоколу IP,
 домен взаимодействия и
 домен доступа, отличного от IP.
Домен транспортировки по протоколу IP (IP Transport Domain)
поддерживает магистральную сеть и маршрутизацию для
транспортировки пакетов через сеть IP-телефонии. К этому домену
относятся такие устройства, как коммутаторы, маршрутизаторы, а
138
также средства обеспечения качества обслуживания QoS (Quality of
Service).
Домен взаимодействия (Interworking Domain) включает в себя
устройства преобразования сигнальной или пользовательской
информации, поступающей со стороны внешних сетей, в вид,
пригодный для передачи по сети IP-телефонии, а также обратное
преобразование. В этот домен входят такие устройства, как шлюзы
сигнализации (Signaling Gateways), обеспечивающие преобразование
сигнальной информации между разными транспортными уровнями,
транспортные шлюзы или медиашлюзы (Media Gateways),
выполняющие функции преобразования пользовательской
информации между разными транспортными сетями и/или разными
типами мультимедийных данных, и шлюзы взаимодействия
(Interworking Gateways), обеспечивающие взаимодействие различных
протоколов сигнализации на одном транспортном уровне.
Домен доступа, отличного от IP (Non-IP Access Domain),
предназначен для организации доступа к сети IP-телефонии
различных IP-несовместимых терминалов. Он состоит из шлюзов
Access Gateways для подключения учрежденческих АТС, аналоговых
кабельных модемов, линий xDSL, транспортных шлюзов для
мобильной сети радиодоступа стандарта GSM/3G, а также устройств
интегрированного абонентского доступа IAD (Integrated Access
Devices) и других устройств доступа. Что же касается IP-терминалов,
например, SIP-телефонов, то они непосредственно подключаются к
домену транспортировки по протоколу IP без участия Access
Gateway.
6.4.2. Плоскость управления обслуживанием вызова и
сигнализации
Плоскость управления обслуживанием вызова и сигнализации
(Call Control & Signaling Plane) управляет основными элементами
сети IP-телефонии и, в первую очередь, теми, которые принадлежат
транспортной плоскости. В этой плоскости ведётся управление
139
обслуживанием вызова на основе сигнальных сообщений,
поступающих из транспортной плоскости, устанавливаются и
разрушаются соединения, используемые для передачи
пользовательской информации по сети. Плоскость управления
обслуживанием вызова и сигнализации включает в себя такие
устройства, как контролер медиашлюзов MGC (Media Gateway
Controller), сервер управления обслуживанием вызова Call Agent,
привратник Gatekeeper и LDAP-сервер.
6.4.3. Плоскость услуг и приложений
Плоскость услуг и приложений (Service & Application Plane)
реализует управление услугами и/или приложениями в сети IP-
телефонии, их логику и выполнение. Устройства в этой плоскости
содержат логику выполнения услуги и управляют этими услугами
путем взаимодействия с устройствами, находящимися в плоскости
управления обслуживанием вызова и сигнализации. Плоскость услуг
и приложений состоит из таких устройств, как серверы приложений
Application Servers и серверы дополнительных услуг Feature Servers.
Плоскость услуг и приложений может также управлять
специализированными компонентами передачи пользовательской
информации, например, медиасерверами, которые выполняют
функции конференцсвязи, IVR и т.п.
6.4.4. Плоскость эксплуатационного управления
На плоскости эксплуатационного управления (Management
Plane) поддерживаются функции активизации абонентов и услуг,
техобслуживания, биллинга и другие функции эксплуатационного
управления сетью. Плоскость эксплуатационного управления может
взаимодействовать с некоторыми или со всеми другими тремя
плоскостями либо по стандартному протоколу (например, по
протоколу SNMP), либо по внутренним протоколам и интерфейсам
API.
6.5. Основы протокола SIP

140
Протокол SIP (Session Initiation Protocol) является текст-
ориентированным протоколом прикладного уровня и предназначается
для организации, модификации и завершения различных сеансов
связи, а также мультимедийных конференций, телефонных
соединений, широковещательной рассылки мультимедийной
информации и соединений пользователей с разными
инфокоммуникационными приложениями. С помощью SIP
пользователи могут принимать участие в уже существующих сеансах
связи, а также приглашать и/или быть приглашенными другими
пользователями к участию во вновь создаваемом сеансе.
Тщательный отбор текстовых сообщений для весьма
ограниченного словарного запаса SIP (что подчеркивает эпиграф к
главе) не помешал ему занять лидирующие позиции в сетях NGN.
Недавно вышел справочник по протоколу SIP, подробно
описывающий все особенности работы SIP, который приведен в
списке рекомендованной литературы к этой части.
Первая спецификация протокола SIP согласно опубликованному
IETF в феврале 1996 года документу draft-ietf-mmusic-sip-00,
содержала единственный текстовый запрос. Да и далее, по мере
своего развития в следующих версиях, протокол SIP, базирующийся
на HTTP (Hypertext Transport Protocol), тоже не стал многословным:
по RFC 2543, уже значительно отличающейся от первого варианта,
протокол SIP предусматривает всего 6 запросов.
Уже с самого начала достоинства и простота протокола
(текстовая база, парадигма запрос-ответ) привлекали многих
сторонников, как из научного мира, так и из промышленности. В
марте 1999 года SIP был опубликован в качестве стандарта IETF под
номером RFC 2543, а в июне 2002 года его дополнительно
пересмотрели и дали ему номер RFC 3621. Момент выпуска RFC
2543 совпал с коммерческим этапом IP-телефонии, ее выходом из
исследовательских лабораторий университетов и фирм и вторжением
на телекоммуникационный рынок. В такой обстановке SIP все больше
141
начинали рассматривать как предпочтительный протокол сетевого
взаимодействия для установления сеансов VoIP по IP-сетям. С
самого начала, по сравнению с ближайшим соперником – протоколом
H.323, рассматриваемым ниже, – у него было много преимуществ,
самыми важными из которых были возможность использовать его не
только для установления телефонных сеансов, но и для других услуг,
таких как транспортировка текущих сообщений и уведомление о
присутствии, ну и, конечно, изначальное ориентирование на
Интернет. К тому же, рассматриваемая в следующем параграфе
схема адресации в SIP и ее расширяемость обеспечили успех за
пределами телефонии. Другие протоколы телефонной сигнализации,
включая H.323, не располагают примитивами, которые можно
использовать для реализации таких же услуг, сохраняя ту же
структуру сигнализации.
На самом деле, справедливость восторжествовала с небольшим
опозданием – значительная часть сетей IP-телефонии оказалась
построенной не на SIP, а все плюсы и достоинства этого протокола
раскрылись уже после появления SIP-T. Примерно в это же время в
телекоммуникационный мир пришло понятие Softswitch и, если
можно так выразиться, они нашли друг друга, и SIP-Т занял
лидирующее место и как протокол взаимодействия для разных
Softswitch, без которых уже не представлялись сети IP-телефонии и
NGN, и как протокол установления мультимедийной связи.
Вышеизложенного уже достаточно, чтобы оправдать решение
начать обсуждение протоколов сетевого взаимодействия именно с
SIP, а не с Н.323.
Помимо немногословности в основу протокола SIP были
заложены следующие принципы:
 предоставление услуг независимо от местоположения
пользователя, т.е. персональная мобильность пользователей,
основанная на присвоении пользователю уникального
идентификатора, который позволяет ему перемещаться в
142
пределах сети и получать связь в любом ее месте вне
зависимости от своего местоположения путем дистанционной
регистрации в Softswitch при помощи специального сообщения
REGISTER;
 определение готовности пользователей участвовать в сеансе
связи, для чего в протоколе SIP определены рассматриваемые
ниже специальные коды ответов для предоставления детальной
информации о текущей готовности пользователя к связи;
 масштабируемость сети, построенной на базе протокола SIP;
 интеграция в стек протоколов Интернет, разработанных IETF для
передачи мультимедийной информации и включающих в себя
протокол резервирования ресурсов RSVP (Resource ReserVation
Protocol), рассмотренные в предыдущей главе протокол реального
времени RTP и протокол передачи потоков в реальном времени
RTSP, а также протокол описания сеанса связи SDP (Session
Description Protocol), рассматриваемый ниже в этой главе;
 взаимодействие с протоколами сигнализации Н.323, MGCP,
MEGACO/H.248, DSS1 и ОКС7, включая возможность переносить
в сигнальных сообщениях SIP не только специфический SIP-
адрес, но и телефонный номер формата Е.164 или любого другого
формата;
 расширяемость протокола SIP, характеризуемая возможностью
дополнять протокол функциями поддержки новых услуг и его
адаптации к работе с различными приложениями.
Еще одним важным принципом протокола SIP является его
независимость от транспортных технологий. В качестве транспорта
могут использоваться протоколы UDP или TCP. Протокол UDP
позволяет быстрее, чем TCP, доставлять сигнальную информацию
(даже с учетом повторной передачи не подтвержденных сообщений),
а также вести параллельный поиск местонахождения пользователей
и передавать приглашения к участию в сеансе связи в режиме
многоадресной рассылки. В свою очередь, протокол ТСР упрощает
143
работу с межсетевыми экранами и гарантирует надежную доставку
данных. При использовании протокола ТСР разные сообщения,
относящиеся к одному вызову, либо могут передаваться по одному
TCP-соединению, либо для каждого запроса и ответа на него может
создаваться отдельное TCP-соединение. На практике обычно
используется протокол UDP, который, к тому же, облегчает обработку
ситуаций аварийного переключения серверов. Команды передаются
на порт 5060 по умолчанию. Команды SIP могут также передаваться
на любой другой порт терминала или Softswitch, если номер этого
порта заранее сообщен отправителю. Вариант переноса сигнальных
сообщений SIP транспортным протоколом с установлением
соединения TCP обычно не практикуется. Возможен также перенос
запросов и ответов протокола SIP транспортным протоколом SCTP,
рассмотренным выше в части 3.
В организуемом с помощью SIP сеансе связи может
передаваться мультимедийная информация любого вида: речь,
видео и данные, а также любая их комбинация, в связи с чем
необходимо организовать обмен между участниками предполагаемой
связи сведениями о характере передаваемой информации. Для этой
цели чаще всего SIP дополняется еще одним протоколом – описания
сеанса связи SDP, – информация которого передается в теле
сообщения протокола SIP. Поскольку в течение сеанса связи может
производиться его модификация (например, приглашение других
пользователей к уже существующему сеансу, в частности, к
конференциям в режиме многоадресной рассылки), предусмотрена
передача сообщений SIP с новыми описаниями сеанса средствами
SDP.
Для передачи речевой информации IETF предлагает
использовать протокол RTP, но сам протокол SIP не исключает
возможность применения для этих целей других протоколов сетевого
взаимодействия.
144
Ранее считалось, что SIP уступает Н.323 в организации
мультимедийных конференций. Но по мере эволюции в SIP
реализованы возможности присоединения новых участников к уже
существующему сеансу связи, т.е. двусторонний сеанс связи может
перейти в конференцию. В общем случае SIP предусматривает
организацию конференций трех видов:
 создаваемых в режиме многоадресной рассылки (multicasting),
когда информация передается на один multicast-адрес, а затем
доставляется сетью конечным адресатам;
 создаваемых при помощи устройства управления конференции
MCU, к которому участники конференции передают информацию в
режиме точка-точка, а MCU, в свою очередь, обрабатывает ее и
рассылает участникам конференции;
 создаваемых путем соединения каждого пользователя с каждым в
режиме точка-точка.
Для организации взаимодействия с существующими
приложениями IP-сетей и обеспечения вышеупомянутой мобильности
пользователей протокол SIP использует принцип адресации,
подобный электронной почте. В качестве адресов используются
специальные универсальные указатели ресурсов URL (Universal
Resource Locators), называемые SIP URL.
Различаются SIP-адреса следующих типов:
 имя@домен,
 имя@хост,
 имя@IP-адрес,
 №телефона@шлюз.
SIP-адрес состоит из двух частей. Первая часть адреса – это имя
пользователя, зарегистрированного в домене сети или на рабочей
станции. Если вторая часть адреса идентифицирует какой-либо
шлюз, то в первой указывается телефонный номер абонента.
Во второй части адреса указывается имя домена сети, хоста или
шлюза. Для определения IP-адреса устройства необходимо
145
обратиться к службе доменовых имен DNS (Domain Name Service).
Если же во второй части SIP-адреса размещается IP-адрес, то с
рабочей станцией можно связаться непосредственно.
В начале адреса ставятся ключевое слово, например ’sip:’,
указывающее, что это именно SIP URL. Существуют также другие
URL (например, ‘tel:’). Ниже приводятся примеры SIP-адресов:
sip: alex@niits.ru
sip: boris@218.10.12.123
tel: +78129998877@sip-gateway.ru
Кроме того, разработан ряд методов совместной работы
оборудования SIP с преобразователями сетевых адресов NAT
(Network Address Translator). Существует целый ряд таких решений:
протокол STUN (Simple Traversal of UDP Through NAT); TURN
(Traversal Using Relay NAT); SIP Application Layer Gateways (ALGs);
протокол MIDCOM (Middlebox Communication); SIP Symmetric
Response Routing по RFC 3581; Firewall Enhancement Protocol по RFC
3093 и др.
6.6. Архитектура сети SIP

Как уже отмечалось в предыдущем параграфе, SIP – это
текстовый протокол, прародителем которого, в известном смысле,
является протокол НТТР (Hypertext Transfer Protocol). Протокол SIP
унаследовал от него синтаксис и архитектуру и опирается на запросы
(команды), передаваемые контроллером (Softswitch), и ответы на них.
В оригинальных спецификациях SIP для запросов используется
термин methods. C того времени, когда были определены упомянутые
выше шесть первоначальных запросов, были приняты еще несколько
запросов, которые используются как внутри оборудования, так и в
виде расширений к базовой спецификации протокола. В такой
системе существует два функциональных элемента: клиент и сервер
(рис. 6.3). Клиент передает запросы, в которых указывает, какого рода
услугу он желает получить от сервера. Сервер принимает запросы,
146
обрабатывает их и передает обратно ответ с указанием либо
успешного выполнения запроса, либо ошибки, или обеспечивает
предоставление услуги, затребованной клиентом.
Запрос
Клиент Ответ Сервер
Рис. 6.3. Архитектура «клиент-сервер»
Таким способом SIP обеспечивает управление соединением и

сигнализацию, необходимые для организации мультимедийных
сеансов связи, а также обеспечивает предоставление конвергентных
услуг по IP-сетям. При организации и завершении мультимедийной
связи SIP поддерживает:
 определение местонахождения (User location) пользователя;
 определение готовности (User availability) пользователя, т.е. того,
что встречная сторона готова участвовать в сеансе связи;
 определение функциональных возможностей (User capabilities)
пользователей, т.е. того, какого рода информацией они могут
обмениваться, и параметров этой информации;
 установление сеанса связи (Session setup), т.е. указание
параметров сеанса связи как для вызывающей, так и для
вызываемой сторон;
 управление сеансом связи (Session management), включая
поддержание и завершение сеанса связи, модификацию
параметров сеанса и активизацию услуг.
Важно отметить, что протокол SIP является не вертикально
интегрированной системой, а, скорее, компонентом, который можно
использовать совместно с другими разработанными IETF
протоколами Интернет, что делает его гораздо более эффективным
для построения законченной мультимедийной архитектуры.
Благодаря архитектуре, более эффективной, по сравнению со
147
строительством вертикали, SIP, как правило, используется в
сочетании с другими протоколами, но основное множество его
функций не зависит ни от одного из этих протоколов. Проще говоря,
протокол SIP не определяет услуги, но позволяет пользователям
устанавливать сеансы связи и их параметры для ввода потоков
пользовательской информации “в услуги” и для вывода ее ”из них”.
SIP позволяет создавать мультимедийные конференции по
упрощенному алгоритму и объединять разнородные услуги, например
телефонную связь и веб-приложения, что, в частности, дает
возможность пользователю, находящемуся на веб-сайте компании,
связаться по телефону через Интернет с менеджером этой компании
и получить его консультацию. Протокол SIP устанавливает сеансы,
согласует требования к передаваемой/принимаемой информации,
определяет местоположение пользователей и позволяет
предоставлять современные интеллектуальные услуги, такие как
переадресация вызова, переключение связи, предоставление
идентификационной информации, обеспечение конфиденциальности
связи и интерактивные услуги мгновенного обмена сообщениями
через Интернет для систем мобильной связи третьего поколения.
В спецификациях протокола SIP определены четыре основных
функциональных элемента, которые, в зависимости от конкретных
требований, либо могут реализоваться в виде автономных
компонентов, либо совмещаться на объединенной платформе.
Агенты пользователей UA (User Agents) – терминалы SIP,
которые инициируют запросы, отвечают на запросы и
взаимодействуют с другими агентами пользователей для организации
и завершения сеансов связи. Агенты пользователей могут
взаимодействовать друг с другом непосредственно; однако часто в
сеанс связи бывает вовлечен один или более промежуточных
серверов: прокси-серверов или серверов переадресации.
Клиентская и серверная часть программного обеспечения UA
названы, соответственно, клиентом агента пользователя UAC
148
(User Agent Client) и сервером агента пользователя UAS (User
Agent Server). Заметим, что сервер UAS и клиент UAC могут (но не
обязаны), непосредственно взаимодействовать с пользователем, а
другие клиенты и серверы SIP этого делать не могут. UAC и UAS
могут быть реализованы как непосредственно в терминале
пользователя, так и в программном обеспечении универсальных
устройств доступа, например, мультисервисных абонентских
концентраторов.
Прокси-серверы (Proxy Servers) получили свое название от
английского proxy – ”представитель” и обеспечивают обработку
запросов, поступающих от терминалов пользователей, с целью
предоставления услуг связи. Порядок обработки запроса и
дальнейшие действия прокси-сервера зависят от типа запроса. Это
может быть поиск и вызов пользователя, маршрутизация запроса,
предоставление услуги и т.д. Как и агент пользователя, прокси-сервер
тоже состоит из клиентской и серверной частей, поэтому он может
принимать вызовы, инициировать собственные запросы и передавать
ответы на запросы. Прокси-сервер может быть реализован
совместно с сервером определения местоположения,
рассматриваемым ниже, или помещаться отдельно от него, но иметь
возможность связываться с ним по протоколам LDAP по RFC 1777,
rwnois по RFC 2167 или любому другому протоколу.
Предусматривается два типа прокси-серверов: с сохранением данных
о состояниях stateful и без сохранения данных о состояниях stateless.
Сервер первого типа хранит в памяти историю процесса
обслуживания вызова, в частности, первый поступивший запрос,
который является причиной генерации одного или нескольких
исходящих запросов, также запоминаемых сервером. Все запросы
хранятся в памяти сервера только до окончания транзакции, т.е. до
получения соответствующих ответов. Сервер stateful позволяет
предоставить большее количество услуг и допускает применение
упрощенных терминалов пользователей, но требует большей
149
вычислительной мощности. Прокси-сервер должен работать в
режиме stateful при использовании для передачи сигнальной
информации протокола ТСР, при работе в режиме многоадресной
рассылки сигнальной информации, или при множественной рассылке
запросов, когда один запрос, поступивший на прокси-сервер,
передается одновременно по нескольким направлениям. Сервер
stateless лишь ретранслирует запросы и ответы, которые принимает.
Он требует менее быстродействующей платформы, т.к. ее
производительность не тратится на контроль состояний текущих
процессов обслуживания вызовов, вследствие чего сервер может
обслужить большее количество пользователей. Недостатком такого
режима является то, что он позволяет реализовать лишь наиболее
простые услуги. Впрочем, прокси-сервер может для одних вызовов
функционировать с сохранением данных о состояниях, а для других –
без сохранения, но во всех случаях выполняет свои основные
функции: – пересылает сообщения к агентам пользователей и
предоставляет такие функции, как определение местонахождения
пользователей, авторизация и учет пользователей. В рассмотренной
выше эталонной архитектуре IPCC им соответствуют функция
маршрутизации и функция учета;
Серверы перенаправления (Redirect servers) всегда являются
серверами без сохранения данных о состояниях. Сервер
перенаправления предназначен для определения текущего IP-адреса
терминала вызываемого пользователя. Вызывающий пользователь
посылает на сервер сообщение с известным ему адресом
вызываемого пользователя, а прокси-сервер перенаправляет вызов
на текущий адрес пользователя. Для реализации этой функции
сервер перенаправления должен взаимодействовать с сервером
определения местонахождения. Сервер перенаправления не
терминирует вызовы и не инициирует свои собственные запросы. Он
только сообщает адрес вызываемого пользователя или прокси-
сервера, и уже по этому адресу инициатор запроса передает новый
150
запрос. Сервер перенаправления не содержит клиентскую часть
программного обеспечения. Но пользователю не обязательно
связываться с каким-либо SIP-сервером, он может вызвать другого
пользователя непосредственно, но при условии, что знает его точный
адрес. Сценарий установления соединения в этом случае будет
выглядеть следующим образом: сначала клиент получает от сервера
перенаправления адрес вызываемого UA, а затем связывается прямо
с ним.
Серверы регистрации местонахождения пользователей
(Registrars или Location servers) позволяют агентам регистрировать
свое местоположение, реализуя тем самым услуги мобильности с
помощью протокола SIP. О своем местонахождении пользователь
сообщает специальному серверу с помощью сообщения REGISTER.
Возможны два режима регистрации пользователя: он может
передать свой новый адрес один раз, а может регистрироваться
периодически через определенные промежутки времени. Первый
способ подходит для случая, когда терминал включен постоянно, и
его пользователь не перемещается по сети, а второй – если
терминал пользователя часто перемещается или выключается.
Фактически сервер определения местонахождения пользователя
представляет собой базу адресной информации. Кроме постоянного
адреса пользователя в базе данных указывается один или несколько
текущих адресов. Как уже отмечалось, этот сервер может быть
реализован совместно с прокси-сервером, в этом случае он
называется registrar, или отдельно – тогда его называют location
server, – но с возможностью связываться с прокси. В спецификациях
протокола SIP сервер определения местонахождения представлен
как отдельный сетевой элемент, однако принципы его работы не
регламентированы.
Резюмируя все вышесказанное, отметим, что в сети SIP
присутствуют следующие основные элементы: терминалы, прокси-
серверы и серверы перенаправления.
151
6.7. Структура сообщений SIP
Согласно рассмотренной в предыдущем параграфе архитектуре
«клиент-сервер» все сообщения SIP делятся на запросы клиента
серверу и ответы сервера клиенту. Так, для инициирования
установления соединения вызывающий пользователь должен
сообщить серверу ряд обязательных параметров, в том числе,
параметры информационных каналов, адрес вызываемого
пользователя и другую информацию. Указанные параметры
передаются в соответствующем SIP-запросе. От вызываемого
пользователя передается ответ на запрос, также содержащий ряд
параметров. Все сообщения протокола SIP – запросы и ответы –
представляют собой последовательности текстовых строк, структура
и синтаксис которых, как уже упоминалось ранее, соответствуют
протоколу НТТР. На рис. 6.4 представлена структура сообщения
протокола SIP.
Стартовая строка
Заголовки
Пустая строка
Тело
сообщения
Рис. 6.4. Структура сообщения протокола SIP
Стартовая строка представляет собой начальную строку

любого SIP-сообщения. Если сообщение является запросом, то в
стартовой строке указываются тип запроса, текущий узел-адресат
и номер версии протокола. Если сообщение является ответом на
запрос, то в стартовой строке указываются номер версии протокола,
тип ответа и короткая расшифровка ответа, предназначенная
152
только для обслуживающего персонала и не обрабатываемая
клиентом.
Заголовки сообщений несут информацию об отправителе,
адресате, пути следования и др., в общем, переносят информацию,
необходимую для обслуживания сообщения. В протоколе SIP
определено четыре вида заголовков:
 общие заголовки, присутствующие в запросах и ответах, к
которым относятся, в частности, Call-ID (идентификатор
соединения), Contact (контакт), CSeq (последовательность),
Date (дата), Encryption (кодирование), From (источник запроса),
То (адресат), Via (через), Record-Route (запись маршрута);
 заголовки содержания переносят информацию о размере тела
сообщения или об источнике запроса, начинаются со слова
'Content', например, Content-Encoding (кодирование тела
сообщения), Content-Length (размер тела сообщения), Content-
Type (тип содержимого);
 заголовки, передающие дополнительную информацию о
запросе, например, Accept (принимается), Accept-Encoding
(кодирование принимается), Accept-Language (язык
поддерживается), Authorization (авторизация), Hide (скрыть),
Max-Forwards (максимальное количество переадресаций),
Organization (организация), Priority (приоритет), Proxy-
Authorization (авторизация прокси–сервера), Proxy-Require
(требование прокси-сервера), Route (маршрут), Response-Key
(ключ кодирования ответа), Subject (тема), User-Agent (агент
пользователя);
 заголовки ответов, передающие дополнительную
информацию об ответе, например Allow (разрешение), Proxy-
Authenticate (подтверждение подлинности прокси-сервера),
Retry-After (повторить через некоторое время), Server (сервер),
Unsupported (не поддерживается), Warning (предупреждение),
WWW-Authenticate (аутентификация WWW-сервера).
153
Заголовок состоит из названия, за которым следует отделенное
двоеточием значение заголовка. В поле значения содержатся
передаваемые данные. Если сервер принимает сообщения,
заголовки которых ему не известны, то они игнорируются при
обработке. Поясним некоторые из упомянутых выше, наиболее часто
используемых заголовков.
Заголовок Call-ID – уникальный идентификатор сеанса связи; он
подобен метке соединения Сall reference в сигнализации DSS1.
Значение идентификатору присваивается стороной, инициирующей
вызов. Заголовок Call-ID состоит из буквенно-числового значения и
имени рабочей станции, которая присвоила значение этому
идентификатору. Между ними должен стоять символ @, например,
2345call@niits.ru.
Заголовок То – определяет адресата. Кроме SIP-адреса, здесь
может стоять параметр tag для идентификации определенного
терминала пользователя, например, домашнего, рабочего или
мобильного телефона, в том случае, когда все они зарегистрированы
под одним адресом SIP URL. Запрос может множиться и достичь
разных терминалов одного пользователя; чтобы их различить и нужна
метка tag. Если необходим визуальный вывод имени пользователя,
например, на дисплей, то имя пользователя также размещается в
поле То.
Заголовок From – идентифицирует отправителя запроса; по
структуре он аналогичен полю То.
Заголовок CSeq - уникальный идентификатор запроса,
относящегося к одному соединению. Он служит для корреляции
запроса с ответом на него. Заголовок состоит из двух частей:
натурального числа в диапазоне от 1 до 232 и типа запроса. Сервер
должен проверять значение величины CSeq в каждом принимаемом
запросе, и считает его новым, если значение больше предыдущего.
Пример заголовка CSeq: 2 INVITE.
154
Заголовок Via необходим, чтобы избежать зацикливания запроса,
а также в тех случаях, когда требуется, чтобы запросы и ответы
обязательно проходили по одному и тому же пути (например, при
использовании межсетевого экрана firewall). Дело в том, что запрос
может проходить через несколько прокси-серверов, каждый из
которых принимает, обрабатывает и переправляет запрос к
следующему прокси-серверу, пока этот запрос не достигнет адресата.
В заголовке Via указывается весь путь, пройденный запросом:
каждый прокси-сервер добавляет поле со своим адресом. При
необходимости (например, чтобы обеспечить секретность)
действительный адрес может скрываться. Например, пусть запрос на
своем пути обрабатывался двумя прокси-серверами: сначала
сервером niits.ru, потом sip.telecom.com. Тогда в запросе появятся
следующие поля: Via: SIP/2.0/UDP
sip.telecom.com:5060;branch=721e418c4.1 и Via: SIP/2.0/UDP
niits.ru:5060, где параметр branch означает, что на сервере
sip.telecom.com запрос был размножен и направлен одновременно по
разным направлениям, и наш запрос был передан по направлению,
которое идентифицируется 721e418c4.1. Содержимое полей Via
копируется из запросов в ответы на них, и каждый сервер, через
который проходит ответ, удаляет поле со своим именем.
В заголовок Record-route прокси-сервер вписывает свой адрес –
SIP URL, – если хочет, чтобы следующие запросы прошли через него.
Сообщения протокола SIP могут содержать так называемое
тело сообщения. Некоторые запросы, например, запрос BYE, не
содержат тела сообщения. С ответами дело обстоит иначе: тело
сообщения могут содержать любые ответы, но содержимое их тела
довольно сильно различается.
Заголовок Content-Type определяет формат описания сеанса
связи. Само описание сеанса, например, в формате протокола SDP,
включается в тело сообщения.
Заголовок Content-Length показывает размер тела сообщения.
155
6.8. Команды (запросы)
Запросы (команды) SIP или, как их называют в спецификациях,
SIP-методы (methods), предназначены для выполнения широкого
круга задач при предоставлении базовых и дополнительных услуг
связи в стационарных сетях и в сетях подвижной связи. С помощью
запросов клиент сообщает о своем текущем местонахождении,
приглашает пользователей принять участие в сеансах связи,
модифицирует уже установленные сеансы, завершает их и т.д.
Сервер определяет тип принятого запроса по названию, указанному в
стартовой строке. В этой же строке в поле Request-URI указан SIP-
адрес оборудования, которому этот запрос адресован. Содержание
полей То и Request-URI может быть различным, например, в поле То
указан адрес абонента, а в Request-URI – адрес прокси-сервера,
через который проходит запрос.
Команда INVITE приглашает пользователя принять участие в
сеансе связи и обычно содержит описание сеанса связи, вид
принимаемой информации и параметры (список возможных
вариантов параметров), необходимые для приема информации. В
нем может также указываться вид информации, который
вызывающий пользователь желает передавать, и данные,
необходимые для аутентификации абонента. В случае
необходимости изменения характеристик подготовленных или уже
используемых каналов передается запрос INVITE с новым описанием
сеанса связи. Для приглашения нового участника к уже
установленному соединению также используется сообщение INVITE.
Команда ACK подтверждает прием ответа на команду INVITE,
содержит описание сеанса связи, переданное вызывающим
пользователем и используется только совместно с запросом INVITE,
т.е. этим сообщением оборудование вызывающего пользователя
показывает, что на свой запрос INVITE оно получило окончательный
ответ.
156
Команда CANCEL отменяет обработку ранее переданных
запросов с такими же, как и в команде CANCEL значениями полей
Call-ID, To, From и CSeq, но не влияет на те запросы, обработка
которых уже завершена. Например, команда CANCEL применяется
тогда, когда прокси-сервер размножает запросы для поиска
пользователей по нескольким направлениям и по одному из них его
находит. Тогда обработку запросов, разосланных по всем остальным
направлениям, сервер отменяет при помощи команды CANCEL.
Командой BYE оборудование вызываемого или вызывающего
пользователей завершает соединение. Сторона, получившая запрос
BYE, должна прекратить передачу речевой (мультимедийной)
информации и подтвердить это ответом 200 ОК.
При помощи команды REGISTER пользователи сообщают свое
текущее местонахождение. В этом сообщении содержатся поле То с
адресом, который надо сохранить или модифицировать на сервере,
поле From с адресом инициатора регистрации (зарегистрировать
пользователя может другое лицо, например, секретарь может
зарегистрировать своего начальника), поле Contact с новым адресом
пользователя, по которому должны передаваться все дальнейшие
запросы INVITE (если в команде поле Contact отсутствует,
регистрация остается неизменной, а в случае отмены регистрации
здесь размещается символ “*”), и поле Expires, в котором
указывается время в секундах, по истечении которого регистрация
заканчивается (если это поле отсутствует, то по умолчанию
назначается время – 1 час). Регистрацию можно отменить и
передачей сообщения REGISTER с полем Expires, которому
присвоено значение 0, и с соответствующим полем Contact.
Командой OPTIONS вызывающий пользователь запрашивает
информацию о возможностях терминального оборудования
вызываемого пользователя. В ответ на этот запрос оборудование
вызываемого пользователя сообщает требуемую информацию.
Применение команды регламентировано теми случаями, когда
157
существует необходимость узнать о возможностях оборудования до
установления соединения.
После испытания протокола SIP в реальных сетях оказалось, что
для решения ряда задач вышеуказанных шести запросов
недостаточно. Так, не был предусмотрен способ передачи
информации управления соединением или другой информации во
время разговорной сессии. Для решения этой задачи был предложен
новый запрос INFO, который можно использовать для переноса
между шлюзами сигнальных сообщений в течение сеанса связи, для
переноса сигналов DTMF, созданных в ходе сеанса, для переноса
информации об остатке на счёте (билинговой информации), для
переноса между участниками сеанса связи изображений и другой не
потоковой информации. Запрос INFO не изменяет состояния
процесса обработки SIP-вызовов, как не изменяет и состояния
сеансов связи, инициированных при помощи протокола SIP. Однако
он обеспечивает перенос дополнительной информации прикладного
уровня, которая может способствовать в дальнейшем более
производительному функционированию приложений, использующих
протокол SIP для доставки информации.
Протокол SIP определяет два типа ответов на запрос,
инициирующий соединение: предварительные и окончательные.
Окончательные ответы несут результат обработки запроса и
передаются «надёжно», т.е. с подтверждением. Предварительные
ответы несут информацию о текущей стадии обработки запроса, но
передаются без подтверждения. Однако в некоторых случаях,
включая взаимодействие с ТфОП, необходим механизм,
обеспечивающий надёжность передачи предварительных ответов.
Для этого вводится механизм надёжности по схеме, схожей с
существующими механизмами для окончательных ответов класса 2хх
на запрос INVITE. Используется запрос PRACK, который играет ту же
роль, что и ACK, но для предварительных ответов. Однако здесь
158
имеется принципиальное различие – PRACK является обычным SIP-
сообщением и требует при его получении передачи ответа 200 (ОК).
Возникают случаи, когда необходимо изменить некоторые
параметры сеанса (например, тип кодека) до прихода окончательного
ответа на начальное сообщение INVITE, для чего вводится запрос
UPDATE. Он используется следующим образом: вызывающая
сторона передает сообщение INVITE, в поле заголовка Allow
которого, среди запросов прочих типов, помещается UPDATE для
того, чтобы указать на способность вызывающей стороны принимать
запросы этого типа. Любой ответ (предварительный или
окончательный) вызываемой стороны тоже содержит заголовок Allow
с указанным в нём значением UPDATE. Далее вызывающая сторона
может создать запрос UPDATE, который содержит предложение с
описанием сеанса связи в формате SDP для обновления параметров
сеанса. На этот запрос передается ответ с указанием принятых
параметров (также в формате SDP).
Объекты сети SIP могут подписаться на предоставление
информации о состоянии определённого ресурса или процесса
обслуживания вызова в сети при помощи сообщения SUBSCRIBE.
Объекты, располагающие этими сведениями (или объекты,
действующие от их лица), будут передавать уведомления NOTIFY
каждый раз, когда состояние изменится. Запрос типа MESSAGE
предназначен для реализации служб интерактивного обмена
текстовыми сообщениями с использованием модели, аналогичной
отправке SMS. Запрос REFER, передаваемый отправителем,
предписывает получателю связаться с третьей стороной, используя
контактную информацию, которая содержится в этом сообщении.
Такой механизм может быть использован для многих целей,
например, для переадресации вызова Call Transfer.
6.9. Ответы
159
После приема и интерпретации запроса, адресат (прокси-сервер)
передает ответ на полученный запрос. Назначение ответов бывает
разным, в том числе: подтверждение установления соединения,
передача запрашиваемой информации, сообщение о неисправностях
и т.д. Структуру и виды ответов протокол SIP унаследовал от
протокола НТТР. Определено шесть типов ответов, которые несут
разную функциональную нагрузку. Тип ответа кодируется трехзначным
числом. Самой важной является первая цифра, она определяет
класс ответа, остальные две цифры лишь дополняют первую. В
некоторых случаях оборудованию даже необязательно знать все
коды ответов, но интерпретировать первую цифру ответа оно должно
обязательно.
Ответы делятся на предварительные (информационные) и
окончательные. Информационные ответы показывают, что запрос
находится в стадии обработки, и кодируются трехзначным числом,
начинающимся с единицы 1хх (provisional). Некоторые ответы,
например, 100 Trying, предназначены для обнуления таймеров в
оборудовании пользователя. Если до срабатывания таймера ответ на
запрос не получен, считается, что запрос потерян, и может (по
усмотрению изготовителя) производиться его повторная передача.
Этот информационный ответ аналогичен сообщению CALL
PROCEEDING протокола Q.931. Еще один распространенный ответ
180 Ringing; его назначение идентично назначению сигнала
«Контроль посылки вызова» в ТфОП или сообщению ALERTING
протокола Q.931. Если прокси-сервер передает ответ 181 Call
Forwarding, он может также указать в теле сообщения, к какому
пользователю он переправляет вызов. Ответ 182 Queued for Service
используется в приложениях, которые позволяют ставить текущий
вызов в очередь до тех пор, пока не будут обслужены вызовы,
находящиеся перед ним. Основными пользователями этой
возможности являются отделы обслуживания клиентов в крупных
корпорациях. Ответ 183 Session Progress аналогичен сообщению
160
CALL PROGRESS протокола Q.931 и используется для того, чтобы
заранее получить описание сеанса информационного обмена от
шлюзов на пути к вызываемому пользователю таким образом, чтобы
мог быть проключен ранний речевой тракт ещё до того, как
вызывающий пользователь получит сигнал КПВ. Этот ответ
используется, например, при взаимодействии протокола SIP с сетью
ТфОП, когда передача ответа Session Progress с SDP-описанием
шлюза ТфОП позволяет входящей АТС послать сигнал КПВ. Среди
других вариантов использования этого ответа – воспроизведение
приветственного объявления или музыкальной фразы при входе в
домен перед установлением соединения. Ответ 189 на запрос
REFER используется для предоставления текущей информации о
состоянии соединения, переключаемого на другой номер в фазе
разговора. При этом ожидается получить либо ответ об успешной
обработке, либо ответ об отказе вызываемой стороны.
Окончательные ответы кодируются трехзначными числами,
начинающимися с цифр 2, 3, 4, 5 и 6. Все они означают завершение
обработки запроса, а каждый из них в отдельности – результат
обработки запроса.
Ответы 2хх (success) означают, что запрос был успешно
обработан. Базовым ответом данной группы является сообщение 200
ОК. Значение этого ответа зависит от соответствующего запроса,
например: ответ 200 ОК на запрос INVITE означает, что вызываемый
пользователь согласен принять участие в сеансе связи, а в теле
ответа указываются возможности оборудования вызываемого
пользователя; ответ 200 ОК на запрос BYE означает завершение
связи, а в теле ответа никакой информации не переносится; ответ
200 ОК на запрос CANCEL означает отмену поиска, и в теле ответа
тоже не переносится никакой информации; ответ 200 ОК на запрос
REGISTER означает, что регистрация прошла успешно; ответ 200 ОК
на запрос OPTION означает согласие вызываемого пользователя
161
сообщить возможности своего оборудования, которые и содержатся в
теле ответа.
Ответы 3хх (redirection) информируют оборудование
вызывающего пользователя о новом местонахождении вызываемого
пользователя или переносят другую информацию, которая может
быть использована, чтобы с ним связаться. В ответе 300 Multiple
Choices указывается несколько SIP-адресов, по которым можно
найти вызываемого пользователя, а вызывающему пользователю
предлагается выбрать один из них. Ответ 301 Moved Permanently
означает, что вызываемый пользователь больше не находится по
адресу, указанному в запросе, и направлять запросы нужно на адрес,
указанный в поле Contact. Ответ 302 Moved Temporary означает, что
пользователь временно (промежуток времени может быть указан в
поле Expires) находится по другому адресу, указанному в поле
Contact, и все запросы нужно посылать туда.
Ответы 4хх (client error) информируют о том, что в запросе
обнаружена ошибка. После получения такого ответа пользователь не
должен передавать тот же самый запрос без его модификации. Ответ
400 Bad Request означает, что запрос не понят из-за синтаксических
ошибок в нем. Ответ 401 Unauthorized означает, что запрос требует
проведения процедуры аутентификации пользователя. Существуют
разные варианты аутентификации, и в ответе может быть указано,
какой из них использовать в данном случае. Ответ 403 Forbidden
означает, что сервер понял запрос, но отказался его обслуживать.
Повторный запрос посылать не следует. Причины могут быть
разными, например, запросы с этого номера не обслуживаются и т.д.
Непосредственно из HTTP заимствован ответ 404 Not Found. А ответ
485 Ambiguous означает, что адрес вызываемого пользователя не
однозначен. Ответ 486 Busy Here означает, что вызываемый
пользователь в настоящий момент занят и не желает (не может)
принять входящий вызов.
162
Ответы 5хх (server error) информируют о том, что запрос не
может быть обработан из-за ошибки сервера. Ответ 500 Server
Internal Error означает, что сервер не имеет возможности обслужить
запрос из-за внутренней ошибки. Клиент может попытаться повторно
послать запрос через некоторое время. Ответ 501 Not Implemented
означает, что в сервере не реализованы какие-либо функции,
необходимые для обслуживания запроса. Ответ передается в том
случае, когда сервер не может распознать тип запроса, полученного
им от любого из пользователей. Ответ 502 Bad Gateway
информирует о том, что сервер, функционирующий в качестве шлюза
или прокси-сервера, принимает некорректный ответ от сервера, к
которому он направил запрос. Ответ 503 Service Unavailable
указывает, что сервер не может в данный момент обслужить вызов
вследствие перегрузки или проведения технического обслуживания.
Ответы 6xx (global failure) информируют о том, что соединение
с вызываемым пользователем установить невозможно. Ответ 600
Busy Everywhere сообщает, что вызываемый пользователь занят и
не желает принимать вызов в данный момент. Ответ может
содержать указание на время, подходящее для его вызова. Если с
пользователем можно связаться по другому адресу или, к примеру,
оставить сообщение на речевой почтовый ящик, то используется
ответ 486 Busy Here. Ответ 603 Decline означает, что вызываемый
пользователь не желает принимать входящие вызовы, не указывая
причину отказа. Ответ 604 Does Not Exist Anywhere означает, что
вызываемого пользователя не существует.
Запросы и ответы на них образуют SIP-транзакцию. Она
происходит между клиентом и сервером и включает в себя все
сообщения, начиная с первого запроса и заканчивая окончательным
ответом. После того как мы рассмотрели запросы и разные ответы на
них, видно, что протокол SIP предусматривает различные алгоритмы
установления соединения.
163
6.10. Сценарии сеансов связи
Протоколом SIP предусмотрено 3 основных типа сценариев
установления соединения: с участием прокси-сервера, с участием
сервера перенаправления и непосредственно между
пользователями. Различие между этими сценариями заключаются в
процедуре поиска и приглашения вызываемого пользователя. В
первом случае эти функции возлагает на себя прокси-сервер, а
вызывающему пользователю необходимо знать только постоянный
SIP-адрес вызываемого пользователя. Во втором случае
вызывающая сторона самостоятельно устанавливает соединение, а
сервер перенаправления вызова лишь преобразует постоянный
адрес вызываемого абонента в его текущий адрес. И, наконец, в
третьем случае вызывающему пользователю для установления
соединения необходимо знать текущий адрес вызываемого
пользователя.
Перечисленные сценарии являются базовыми. Прежде чем
вызов достигнет адресата, он может пройти через несколько прокси-
серверов или сначала попасть на сервер перенаправления, а затем
пройти через один или несколько прокси-серверов. Кроме того,
прокси-серверы могут размножать запросы и передавать их по
разным направлениям и т.д.
6.10.1. Алгоритм установления соединения с участием
сервера перенаправления
В этом разделе описан алгоритм установления соединения с
участием сервера перенаправления вызовов. Администратор сети
сообщает пользователям адрес сервера перенаправления.
Вызывающий пользователь передает запрос INVITE (1) на известный
ему адрес сервера перенаправления и порт 5060, используемый по
умолчанию (рис. 4.3), и указывает в запросе адрес вызываемого
пользователя. Сервер перенаправления запрашивает текущий адрес
вызываемого абонента у сервера определения местонахождения (2),
который сообщает ему требуемый адрес (3). Сервер
164
перенаправления в ответе 302 Moved temporarily передает
вызывающей стороне текущий адрес вызываемого абонента (4) или
может сообщить список зарегистрированных адресов вызываемого
пользователя и предложить вызывающему пользователю самому
выбрать адрес. Вызываемая сторона подтверждает прием ответа 302
передачей сообщения ACK (5).
Теперь вызывающая сторона может связаться непосредственно
с вызываемой стороной. Для этого она передает новый запрос
INVITE (6) с тем же идентификатором Call-ID, но с другим номером
последовательности CSeq. В теле сообщения INVITE указываются
возможности вызывающей стороны в формате протокола SDP.
Вызываемая сторона принимает запрос INVITE и начинает его
обработку, о чем сообщает ответом 100 Trying (7) встречному
оборудованию для рестарта его таймеров. После завершения
обработки поступившего запроса оборудование вызываемого
пользователя сообщает своему пользователю о поступлении
входящего вызова, а встречной стороне передает ответ 180 Ringing
(8). После приема вызываемым пользователем входящего вызова
удаленной стороне передается сообщение 200 ОК (9), в котором
содержится описание возможностей вызываемого терминала в
формате протокола SDP. Терминал вызывающего пользователя
подтверждает прием ответа запросом АСК (10). На этом фаза
установления соединения закончена, и начинается разговорная фаза.
По завершении разговорной фазы передается запрос BYE (11),
который подтверждается ответом 200 ОК (12).
165
Сервер
Вызывающий Сервер Вызываемый
определения
пользователь перенаправления пользователь
1. INVITE
2. Запрос определения
3. Ответ с текщим
адресом
4. 302 Moved Temporarily
5. ACK
6. INVITE
7. 100 Trying
8. 180 Ringing
9. 200 ОК
10. АСК
Разговорная фаза
11. BYE
12. 200 ОК
Запросы
Ответы
Рис. 6.5. Сценарий установления соединения через сервер

перенаправления
6.10.2. Алгоритм установления соединения с участием

прокси-сервера.
Теперь рассмотрим алгоритм установления соединения с
участием прокси-сервера. Администратор сети сообщает
пользователям адрес прокси-сервера. Вызывающий пользователь
передает запрос INVITE (1) на адрес прокси-сервера и порт 5060,
используемый по умолчанию (рис. 6.6). В запросе он указывает
известный ему адрес вызываемого пользователя. Прокси-сервер
запрашивает текущий адрес вызываемого абонента у сервера
определения местонахождения (2), который и сообщает ему
требуемый адрес (3). Далее прокси-сервер передает запрос INVITE
166
непосредственно вызываемому абоненту (4). Опять в запросе
указываются возможности терминала, но при этом в запрос
добавляется поле Via с адресом прокси-сервера для того, чтобы
ответы на обратном пути шли через него. После получения запроса и
его обработки оборудование вызываемого пользователя сообщает
ему о том, что поступил входящий вызов, а встречной стороне
передает ответ 180 Ringing (5), копируя в него из запроса поля To,
From, Call-ID, CSeq и Via. После приема вызываемым
пользователем входящего вызова удаленной стороне передается
сообщение 200 ОК (9), в котором содержится описание в формате
протокола SDP возможностей вызываемого терминала. Терминал
вызывающего пользователя подтверждает прием ответа запросом
АСК (10). На этом фаза установления соединения закончена, и
начинается разговорная фаза. По завершении разговорной фазы
передается запрос BYE (11), который подтверждается ответом 200
ОК (12). Все сообщения проходят через прокси-сервер, который
может модифицировать некоторые поля сообщений.
167
Сервер
Вызывающий Вызываемый
Прокси-сервер определения
пользователь пользователь
1. INVITE
2. Запрос определения
3. Ответ с текщим
адресом
4 INVITE
5. 180 Ringing
5. 180 Ringing
6. 200 ОК
6. 200 ОК
7. АСК
7. АСК
Разговорная фаза
8. BYE
8. BYE
9. 200 ОК
12. 200 ОК
Запросы
Ответы
Рис. 6.6. Сценарий установления соединения через прокси-сервер
6.11. Н.323 в процессе эволюции IP-телефонии

В процессе становления VoIP как телекоммуникационной
индустрии появилось довольно четкое разделение между Н.323 и
SIP. В начальном периоде IP-телефонии протокол Н.323 считался
удачным решением для интеграции IP-телефонии в ТфОП (во многом
из-за его принадлежности к ITU-Т и простоты реализации сценария
телефон-телефон, который являлся основным источником дохода
оператора IP-телефонии), а протокол SIP, как считалось вначале,
годился разве что для организации связи в корпоративной IP-сети
(основным аргументом служило отсутствие механизмов
взаимодействия с телефонной сигнализацией). Дальнейшее
развитие SIP и появление SIP-T, о чем уже говорилось в предыдущей
168
главе, серьезно изменило взгляды на IP-телефонию, и
непререкаемым лидером для неё и для NGN в целом стал протокол
SIP. Казалось, естественным было бы теперь отложить в сторону
рекомендацию Н.323 и сосредоточить усилия на развитии SIP-сетей.
Некоторые операторские компании в новых областях так и поступают,
однако по России в целом большая часть сетей IP-телефонии
строилась именно на Н.323, и перспективы немедленного
переоборудования сетей этих Операторов сегодня вряд ли
экономически оправданы.
6.12. Архитектура и основные устройства сети Н.323

На рис. 6.7 изображена архитектура сети, построенной на базе
рекомендации H.323.
Устройство
управления
конференциями
Терминал Терминал
Н.323 Н.323
IP - сеть
Шлюз Привратник Терминал Шлюз

Н.323
ТфОП/ ТфОП/
ISDN ISDN
Терминал Терминал Речевой Терминал Речевой

V.70 Н.324 терминал Н.320 терминал
Рис. 6.7. Архитектура сети Н.323

Основными устройствами сети являются: терминал, шлюз,
привратник и устройство управления конференциями,
рассматриваемые ниже.
6.12.1. Терминал Н.323
169
Первое определение терминала Н.323 выглядело так:
«Терминал H.323 – это оконечное устройство сети IP-телефонии,
обеспечивающее двустороннюю речевую или мультимедийную связь
с другим терминалом, шлюзом или устройством управления
конференциями». При организации децентрализованной
конференции терминал Н.323 мог принимать более чем один поток
речевой информации, и эти потоки могли быть мультиплексированы в
один логический канал. По мере развития IP-телефонии
функциональные возможности терминала Н.323 расширились, а его
определение упростилось. Сегодня под терминалом Н.323
понимается оконечный терминал пользователя, удовлетворяющий
всем требованиям рекомендации H.323, т.е. поддерживающий
передачу текстовых, аудио и видео потоков.
Но в процессе общения пользователям зачастую не требуется
видеть друг друга, а иногда даже и слышать (достаточно обмена
текстовыми сообщениями). Появилось понятие упрощенный
терминал пользователя SET (Simple Endpoint Type). Упрощенный
текстовый терминал – это терминал, который не поддерживает
большую часть рекомендации H.323, но способен вступать в
текстовое взаимодействие с полноценным (или с другим
упрощенным) терминалом H.323, шлюзом или устройством
управления конференциями. Обязательной для него является
поддержка передачи текста (данных) по протоколу T.120. Текстовое
общение может проводиться как в режиме точка-точка, так и в виде
конференции. Следует отметить, что плюсом такого терминала
является относительная простота его реализации, причем функции
передачи текста могут быть достаточными для большого числа
пользователей.
Упрощенный аудио-терминал – терминал, не поддерживающий
часть рекомендации H.323, но способный реализовать аудио-связь с
полненным терминалом H.323 (или с другим упрощенным аудио-
терминалом), шлюзом или устройством управления конференциями.
170
Такой терминал может дополнительно поддерживать передачу
текстовых сообщений. Помимо текстового и аудио-терминалов в
рекомендации Н.323 определяются терминалы других видов, такие
как упрощенный терминал защищенной текстовой, аудио- или
видеосвязи.
6.12.2.Шлюз H.323
Шлюз Н.323 преобразует информацию (сигнализацию, речь и
др.), поступающую со стороны ТфОП с постоянной скоростью, в вид,
пригодный для передачи по IP-сетям, а также производит обратное
преобразование. Последние версии Н.323 не обошли стороной идеи
декомпозиции шлюзов, которые пропитали практически все, что
связано с NGN и IP-телефонией. В рекомендации
идентифицированы интерфейсы и функции, которые должны быть
использованы при декомпозиции шлюзов H.323. Конечные
реализации шлюзов могут являться группой из двух и более
функциональных компонентов внутри одного физического устройства.
По этой причине интерфейсы могут иметь возможность прозрачного
переноса сообщений других протоколов.
6.12.3. Привратник
Первоначальная идея о сосредоточении в привратнике всего
интеллекта сетей IP-телефонии, базирующихся на рекомендации ITU
H.323, не потеряла свою актуальность с изобретением Softswitch, но
видоизменилась следующим образом: к самому Softswitch теперь
предъявляется требование обладать всеми функциями привратника
для управления сетями по протоколу Н.323.
Напомним наиболее важные функции, выполняемые
привратником:
 преобразование alias-адреса в транспортный адрес сетей с
маршрутизацией пакетов IP (IP-адрес и номер порта TCP).
 управления доступом пользователей системы к услугам IP-
телефонии.
171
 контроль и резервирование пропускной способности сети, а также
управление ею.
 маршрутизация сигнальных сообщений между терминалами,
расположенными в одной зоне.
При отсутствии в сети привратника преобразование адреса
вызываемого абонента, поступающего со стороны ТфОП в формате
E.164, в транспортный адрес IP-сетей должно выполняться шлюзом
или полностью возлагаться на Softswitch.
6.13. Протоколы сетевого взаимодействия Н.323

В стек Н.323 входит три основных протокола: протокол
взаимодействия оконечного оборудования с привратником RAS
(Registration, Admission and Status), протокол управления
соединениями H.225 и протокол управления логическими каналами
Н.245, которые представлены на рис. 6.8 совместно с Интернет-
протоколами TCP/IP, UDP, RTP и RTCP, а также с протоколом Q.931.
Как видно на этом рисунке, протокол TCP используется для переноса
сигнальных сообщений H.225 и управляющих сообщений H.245,
сигнальные сообщения RAS переносятся с помощью протокола UDP,
а перенос речевой и видеоинформации производится посредством
использования RTP/RTCP.
0 16 32
Гарантированная доставка Негарантированная доставка

информации по протоколу ТСР информации по протоколу UDP
Потоки речи
H.225 и видеоинформации
H.245
RAS RTCP RTP
соединением (Q.931)
ТСР UDP
IP
Канальный уровень
Физический уровень
Рис. 6.8. Семейство протоколов Н.323
172
1. Гольдштейн А.Б., Гольдштейн Б.С. Softswitch. –СПб.: БХВ, 2006.
2. Кох Р., Яновский Г.Г. Эволюция и конвергенция в электросвязи. –
М.: Радио и связь, 2001.
173
Список сокращений
АЛ Абонентская линия
АТС Автоматическая телефонная станция
БС Базовая станция
ВСК Выделенные сигнальные каналы
ЕСЭ Единая сеть электросвязи
ИКМ Импульсно-кодовая модуляция
ИС Интеллектуальная сеть
MTP Подсистема переноса сообщений
ОКС7 Сеть общеканальной сигнализации
ССОП Cети связи общего пользования
СПС Сети подвижной связи
СРВ Ступень распределения вызовов
ТфОП Телефонные сети общего пользования
УСС Узел спецслужб
2bitCAS Два выделенных сигнальных канала
AN (Access Network) Универсальный интерфейс сети доступа
BS (Base Station) Базовая станция
BSC (Base Station Controller), Контроллер базовых станций
BSSMAP (BSS Management Application Протокол управления
Part)
BCP (Basic Call Process) Модель базового процесса обслуживания вызова
CAS (Channel Associated Signaling) Сигнализация по выделенным каналам
CCS (Common Channel Signaling) Общеканальная сигнализация
CSL Подуровень Компонентов
CPA Адрес вызываемого пользователя
CCAF (Call Control Agent Function) Функциональный объект поддержки доступа
CCF (Call Control Function) функцию управления связью пользователя
CDR (Call Detailеd Record) Подсистема сбора детализированной
информации о предоставленных услугах
CIC (Circuit Idenification Code) Код идентификации канала
CL (Cancel Location ) Отмена местоположения
CSTA (Computer-Supported Telephony Набор стандартов, разработанных Европейской
Applications) ассоциацией производителей компьютеров
DPC (Destination Point Code) SP-получатель
DTAP (Direct Transfer Application Part). Подсистема сквозной передачи сообщений
DP (Detection point) Точки обнаружения
DFP (Distributed functional plane) Распределенная функциональная плоскость
DNS (Domain Name Service). Служба доменновых имен
EDP (Event detection point) Точки обнаружения события
FISU Заполняющая сигнальная единица
GII (Global Information Infrastructure) Глобальная информационная инфраструктура
GFP (Global functional plane) Глобальная функциональная плоскость
GK (Gatekeeper) Привратник
IN Интеллектуальная сеть
ITU Международный союз электросвязи
ID Идентифицирующий диалог
IP (Intelligent Peripheral) Интеллектуальная периферия
IUA Протокол уровня адаптации для ISDN-
пользователя
INAP (Intelligent Network Application Прикладной протокол интеллектуальной сети
Protocol)
ICW (Internet call waiting) Услуга, обеспечивающая телефонный вызов
пользователя
IAD (Integrated Access Devices) Интегрированный абонентский доступ
LSSU Сигнальная единица статуса звена
LI Индикатор длины
174
LU (Location Update) Обновление местоположения
MSC (Mobile Switching Center) Центр коммутации подвижной связи
MAP (Mobile Application Part) Протокол сигнализации
MSRN (Mobile Station Roaming Number) Временный номер
MGCP (Media Gateway Control Protocol) Протокола управления шлюзами
NGN Архитектура сетей следующего поколения
MGC (Media Gateway Controller) Контроллер транспортного шлюза
NP Network Performance Производительность сети
NI (Network Indicator) Индикатор сети
NGN (Next Generation Network) Сети связи следующего поколения
NAT (Network Address Translator) Преобразователь сетевых адресов
OA&MC (Operation, Administration and Центры эксплуатационного управления сетью
Maintenance Centers) связи
OPC (Originating Point Code) SP-отправитель
PINT (PSTN and Internet Interworking) Взаимодействие ТфОП и Интернет
PIC (Point in call) Последовательность отображающих состояния
этого процесса точек
PP (Physical plane) Физическая плоскость
POI (Point Of Initiation) Инициирующие точки
POR (Point Of Return) Точки возврата
PRIN-подход (PRIN - PRoportion Подход пропорциональной архитектуры
Intelligent Network) Интеллектуальной сети
QoS (Quality of Service) Качество обслуживания
SP (Signaling Point) Пункты сигнализации
STP (Signaling Transfer Points) Транзитные пункты сигнализации
SCP (Service Control Point) Узлы управления услугами
SSP (Service Switching Points) Узлы коммутации услуг
SLS (Signaling Link Selection) Селектор сигнального звена
SMAF Эксплуатационное управление услугами
SMF Функции эксплуатационного управления услугами
SCTP (Stream Control Transmission Протокол передачи информации для управления
Protocol) потоками
SPIRITS (Service in the PSTN/IN Запросы услуг Интернет в ТфОП/IN
Requesting Internet Service)
SF (Service features) Атрибуты услуги
SIB (Service independent building block) Конструкционные блоки
SSF (Service switching function) Функциональный объект коммутации услуг
SCF (Service control function) Функциональный объект управления услугами
SRF (Specialized resource function) Функциональный объект специализированных
ресурсов
SDF (Service data function) Функциональный объект предоставления данных
для услуг
SGCP (Signaling Gateway Control Протокол управления шлюзами сигнализации
Protocol)
SET (Simple Endpoint Type) Упрощенный терминал пользователя SET
TC (Transaction Capabilities) Средства транзакций
TSL Подуровень Транзакций
TRIP (Telephony routing over IP) Маршрутизации телефонных вызовов по IP-сети
TDP (Trigger detection points) Триггерные точки обнаружения
TP (Transport Plane) Транспортная плоскость
VPN Виртуальная частная сеть
175

Язык

Гольдштейн Б.С. Сетевое Взаимодействие - Электронный Учебник

Загружено:

Сведения о документе

Описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Описание:

Авторское право:

Доступные форматы

Гольдштейн Б.С. Сетевое Взаимодействие - Электронный Учебник

Загружено:

Описание:

Авторское право:

Доступные форматы

Б.С.

1.1. Основные понятия телефонной сигнализации

1.2. Элементы межстанционной сигнализации

1.3. Эволюция межстанционной сигнализации

Рис. 1.2. Сигнализация по телефонному каналу

Рис. 1.3. Сигнализация по выделенному сигнальному каналу (ВСК)

Следующими этапом эволюции систем сигнализации является

Рис. 1.4. Общеканальная сигнализация №7

И, наконец, к следующему поколению сигнализации можно

Рис. 1.5. Сигнализация IP-телефонии

1.4. Глобальная информационная инфраструктура

Сеть доступа Сеть доступа

Рис. 1.6. Глобальная информационная инфраструктура GII

2.1. Сигнализация по выделенным сигнальным каналам

(01) Исходное состояние (11)

Т1 (11) Подтверждение занятия

(10) Состояние разговора (10)

(01) Контроль исходного состояния

(01) Исходное состояние (11)

Т1 - время ожидания сигнала подтверждения Т3 - время передачи импульса, 50 мс

Рис. 2.1. Сценарии обмена сигналами (местный вызов)

Сценарий «б» отличается от предыдущего тем, что в состоянии

(01) Исходное состояние (11)

Т1 (11) Подтверждение занятия

(10) Состояние разговора (10)

(01) Контроль исходного состояния

(01) Исходное состояние (11)

Рис. 2.1. Сценарии обмена сигналами (местный вызов)

(01) Исходное состояние (11)

Т1 (11) Подтверждение занятия

(11) Предответное состояние (10)

(01) Исходное состояние (11)

Рис. 2.1. Сценарии обмена сигналами (местный вызов)

Несколько более сложны сценарии, которые имеют место при

2.2. Многочастотная сигнализация

Рис. 2.2. Регистровая сигнализация методом “импульсный челнок”

Кроме метода «импульсный челнок» для передачи регистровых

Метод «безынтервальный импульсный пакет» используется в

3.1. Предпосылки общеканальной сигнализации

3.2 Принципы сети ОКС7

сеть разговорных каналов

Рис.3.1. Двухуровневая сеть с ОКС7

Сеть связи, использующая систему ОКС7 (рис.3.1), состоит из

Описание подсистем, функций, Рекомендации ITU-T

Рекомендации ITU-Т, приведенные в таблице 3.1,

Подсистемы мо- Подсистема Прикладной

AE AE AE Подсистема Подсистема Подсистема

Подсистема переноса сообщений

Подсистема переноса сообщений

ASE – Сервисный прикладной элемент

Рис. 3.2. Структура ОКС7

3.4. Подсистема переноса сообщений MTP

FSN - порядковый номер передаваемой сигнальной единицы;

Рис. 3.3. Формат значащей сигнальной единицы MSU

Чтобы избежать имитации флага другой частью сигнальной

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

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

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

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

Функции распределения, приняв от функций сортировки