А теперь посмотрим на ISUP. Хороший протокол, отлично работает без SCCP (есть какие-то варианты работы поверх SCCP, но я их не встречал). Зачем же было тогда придумывать SCCP?
А всё дело в задачах. ISUP предназначен для установления голосового канала между двумя заранее определёнными узлами сети. Эти узлы могут быть как внутри одной сети (2 MSC), так и в двух разных сетях (2 GMSC операторов-конкурентов). Кроме того, протокол изначально ориентирован на одну задачу - установить голосовой канал.
Что же делать, если узлы находятся непонятно где и необходимо сделать запрос, который к голосу не имеет никакого отношения? Вот для таких задач и придумали SCCP.
Для использования SCCP, каждому узлу кроме адреса на уровне MTP3 (Point Code, который), назначается ещё и т.н. Global Title (GT). GT - это адрес, например, набранный абонентом номер, который не обязательно явно содержит информацию, позволяющую маршрутизировать сообщение в сети SS7.
Вместе с MTP3, SCCP образует третий уровень эталонной модели взаимодействия открытых систем (OSI RM). Т.е. как и протокол IP, обеспечивает функции по маршрутизации сообщений в сети. Происходит это примерно так:
1. Приложение на узле A отправляет сообщение узлу B.
2. Узел А проверяет свою таблицу маршрутов и:
2.1. находит его. Фактически происходит GTT (об этом ниже) - определяется Point Code для узла B и номер подсистемы (если необходимо). Это значит, что сообщение может быть отправлено с использованием MTP3-маршрутизации: узел А ставит Point Code узла B в DPC и ищет подходящий маршрут (linkset).
2.2. не находит "прямого" маршрута. Если задан маршрут по-умолчанию, то сообщение отправляется на указанный в нём Point Code (Узел C). Ожидается, что узел C знает, что делать с сообщением.
2.3. не находит вообще никакого маршрута. Приложению может быть отправлена ошибка - Message type:UDTS, Return cause:No translation for this specific address.
Пункты 2.1 и 2.3 нас особо не интересуют, поскольку мы рассматриваем случаи SCCP маршрутизации. Поэтому считаем, что сообщение поступило на узел C.
3. Узел С проводит аналогичную процедуру, что и узел А. И снова возможны 3 варианта. Есть смысл рассматривать вариант 1, тот который GTT. Его и рассмотрим.
Итак, узел С получил сообщение и проанализировал SCCP Called Party Address (CdPA). Из чего состоит этот адрес описывать не буду (в Интернет достаточно информации по этому поводу). Выделю только ключевые для этой статьи поля:
- Routing Indicator (в составе Address Indicator). Указывает на тип маршрутизации - по GT или PC+SSN.
- Translation Type. Обычно это значение 0. ITU-T определило некоторые возможные значения и как их следует интерпретировать. На практике, эти значения можно использовать под свои нужды (об этом в примере).
- Numbering Plan (детальнее смотрите на GSM numbering plans)
- Address Information. Непосредственно номер.
Узел С начинает анализ сообщения. RI у нас точно указывает на Route on GT, потому что это мы собираемся делать окончательную трансляцию. В зависимости от значения поля TT, можно выбрать узел получателя сообщения. Например, если ТТ=0, отправить на узел B, а если ТТ=10, то отправить на узел D.
В зависмости от Numbering Plan маршрутитизация также может быть разной. Например, отправлять все сообщения с NP E.214 (такие как MAP Update Location) на роуминг-платформу для принятия решения (пускать абонента в эту сеть или нет). Роуминг платформа после обработки может вернуть сообщение обратно без каких-либо изменений (ну, только OPC и DPC поменяет местами). А чтобы узел C снова не отправил сообщение на роуминг-платформу, то она при отправке установит значение TT отличным от 0. Таким образом можно избежать петель маршрутизации. Хотя сравнительно новые STP могут дополнительно анализировать с какого направления (linkset или свой внутренний указатель) пришло сообщение, поэтому второй раз его на роуминг-платформу не отправят даже если ТТ=0.
Если все предыдущие проверки пройдены, но получатель так и не определён, то осталось поле Address Information. По нему узел C и определяет, что это сообщение для узла B и его подсистемы такой-то (это в случае, если подсистема не была указана в оригинальном сообщении в поле SSN). Point code узла B известен, сообщение отправляется через соответствующий linkset. Дело сделано, GTT осуществлёна.
Теперь немного о классах SCCP:
- Class 0- Basic connectionless class
- Class 1- In-sequence delivery connectionless class
- Class 2- Basic connection-oriented class
- Class 3- Flow control connection-oriented class
Не имел возможности работать с Class 2 и 3, потому что TCAP (а следовательно MAP, CAMEL, INAP) их не используют. Литература гласит, что Class 3 пока-что вообще не используется, а Class 2 используется для "Some BSSMAP messages (Setup)", с которым тоже не имел чести работать.
Что касается отличий Class 0 и Class 1, то тут могу рассказать. Для увеличения надёжности сети, её ключевые элементы, такие как STP, дублируют. Дублируются также и подключения узлов к сети - узлы подключаются к двум STP одновременно. При этом стараются распределить нагрузку между STP равномерно. Это значит, что узел А, отправляя сообщения, часть их отправляет через STP1, а часть через STP2. Иногда бывает так, что на запрос нужно ответить двумя, а то и тремя сообщениями. Если очередность доставки не важна (а это Class 0), то можно смело разбрасывать сообщения между STP. Но если получателю важен порядок сообщений (например, мы отправили TCAP Continue и TCAP End. Очень важно сохранить очередность), то используется Class 1 и все сообщения из цепочки будут отправлены через один и тот же linkset (читай STP), да ещё и через тот же линк (SLS).
Могу подтвердить, что это важная вещь. На практике встречал ситуации, когда 2 сообщения отправленные с интервалом в 10 мс через разные STP, приходили в неправильном порядке и в итоге "ничего не рапотает, насяльника". Картину прояснил только трейс снятый на конечной точке маршрута - коммутаторе. Почему второй STP доставлял сообщение до коммутатора быстрее осталось загадкой.
