WikiDer > Техническая реализация службы коротких сообщений (GSM)

Short Message Service technical realisation (GSM)

В Сервис коротких сообщений реализуется за счет использования Часть мобильного приложения (КАРТА) SS7 протокол, при этом элементы протокола коротких сообщений транспортируются по сети в виде полей в сообщениях MAP.^[1] Эти MAP-сообщения могут транспортироваться с использованием "традиционных" TDM сигнализация на основе или по IP с использованием СИГТРАН и соответствующий уровень адаптации.

Протокол

В Протокол коротких сообщений сам определяется 3GPP TS 23.040 для Служба коротких сообщений - точка-точка (SMS-PP),^[2] и 3GPP TS 23.041 для Служба сотового вещания (CBS).^[3]

Для управления службой коротких сообщений определены четыре процедуры MAP:^[1]

Передача службы коротких сообщений Mobile Originated (MO);
Передача службы коротких сообщений с мобильной оконечной станцией (MT);
Процедура оповещения посредством коротких сообщений;
Процедура набора данных об ожидающем коротком сообщении.

Передача службы коротких сообщений MO

Поток вызовов для мобильной службы коротких сообщений

На диаграмме справа изображен упрощенный поток вызовов для успешной передачи отправленного с мобильного телефона короткого сообщения (SM).^[1]

Когда абонент отправляет короткое сообщение, телефон отправляет текстовое сообщение по радиоинтерфейсу на Центр коммутации мобильной связи (MSC)/Обслуживающий узел поддержки GPRS (SGSN). Наряду с фактическим текстом короткого сообщения, адрес назначения SM и адрес Центр обслуживания коротких сообщений (SMSC) включены, последние взяты из конфигурации телефона, хранящейся на SIM-карте.^[4]

Независимо от технологии радиоинтерфейса, VMSC / SGSN вызывает сервисный пакет MAP MAP_MO_FORWARD_SHORT_MESSAGE для отправки текста на межсетевой MSC центра обслуживания, адрес которого был предоставлен телефоном. Этот сервис отправляет mo-ForwardSM^{[Примечание 1]} Операция MAP с SMSC, указанная в сообщении SM с мобильного телефона, встроенная в Часть приложения "Возможности транзакций" (TCAP) и передается по базовой сети с помощью Часть управления сигнальным соединением (SCCP).^[1]

Межсетевой MSC SMSC при получении сообщения MAP mo-ForwardSM передает SMS-PP^[2] Блок данных протокола приложения (APDU) содержащее текстовое сообщение в фактический сервисный центр (SC) SMSC для сохранения и последующей «пересылки» (доставки) на адрес назначения, и SC возвращает подтверждение, указывающее на успех или неудачу. По получении этого статуса представления от сервисного центра межсетевой MSC отправит соответствующее указание обратно в VMSC / SGSN отправляющего абонента. Затем статус отправки сообщения передается по радиоинтерфейсу на телефонную трубку абонента.^[4]^{[Заметка 2]}

Передача службы коротких сообщений MT

Поток вызовов для мобильной службы коротких сообщений

На рисунке справа изображен поток вызовов для доставки коротких сообщений с мобильного терминала.^[1] Для простоты некоторые взаимодействия между VMSC и VLR, а также VMSC и Handset были опущены, и только в том случае, когда SMS-маршрутизация домой не используется.

Когда SMSC определяет, что ему необходимо попытаться доставить короткое сообщение в пункт назначения, он отправит APDU SMS-PP, содержащий текстовое сообщение, «B-Party» (номер телефона пункта назначения) и другие сведения в MSC шлюза (GMSC ) логический компонент на SMSC.^[2] GMSC, получив это короткое сообщение, должен определить местоположение B-стороны, чтобы иметь возможность правильно доставить текст получателю (термин MSC шлюза в данном контексте указывает на MSC, который получает маршрутизацию). информация из Регистр домашнего местоположения (HLR)). Для этого GMSC вызывает сервисный пакет MAP MAP_SEND_ROUTING_INFO_FOR_SM, который отправляет MAP-сообщение sendRoutingInfoForSM (SRI-for-SM) в HLR целевого номера, запрашивая их текущее местоположение. Это сообщение SRI-for-SM может быть отправлено на HLR в той же сети, что и SMSC, или через межсоединение к HLR в чужой PLMN, в зависимости от того, к какой сети принадлежит целевой абонент.

HLR выполняет поиск в базе данных, чтобы получить текущее местоположение B-стороны, и возвращает его в сообщении подтверждения в объект GMSC SMSC. Текущее местоположение может быть адресом MSC, по которому абонент в настоящее время находится в роуминге, адресом SGSN или и тем, и другим. HLR также может вернуть ошибку, если считает, что пункт назначения недоступен для передачи коротких сообщений; увидеть Не удалось доставить короткое сообщение раздел ниже.

Получив информацию о маршрутизации от HLR, GMSC попытается доставить короткое сообщение получателю. Это делается путем вызова службы MAP_MT_FORWARD_SHORT_MESSAGE, которая отправляет MAP mt-ForwardSM^{[Заметка 3]} сообщение на адрес, возвращаемый HLR, независимо от того, является ли это MSC (доставка SMS с коммутацией каналов) или SGSN (доставка SMS с коммутацией пакетов).

VMSC запросит информацию, необходимую для доставки короткого сообщения получателю, отправив сообщение Send_Info_for_MT_SMS на VLR. Затем VLR инициирует запрос страницы или поиск подписчика для целевых подписчиков. Номер ISDN мобильного абонента (MSISDN), и верните результат в VMSC. Поскольку при типичном развертывании VLR совмещается с MSC, этот поток сообщений обычно является внутренним по отношению к платформе.^{[Примечание 4]} В случае сбоя страницы или поиска абонента VLR укажет причину сбоя VMSC, который прервет процедуру доставки коротких сообщений и вернет ошибку в SMSC (см. Не удалось доставить короткое сообщение раздел ниже). Если страница телефона была успешной, VMSC затем отправит в SMSC, указывая на успешную доставку. Компонент GMSC SMSC передает результат попытки доставки в Сервисный центр. В случае успешной доставки доставленное текстовое сообщение будет удалено из механизма Store and Forward Engine (SFE) и, если потребуется, отправит отчет о доставке отправителю текста.^[2] Если доставка не удалась, SMSC вызывает процедуру повтора, чтобы периодически делать дальнейшие попытки доставки; Кроме того, он может зарегистрироваться в HLR для получения уведомления, когда B-сторона станет доступной для доставки коротких сообщений в будущем (см. Не удалось доставить короткое сообщение раздел ниже).

Не удалось доставить короткое сообщение

Когда VMSC / SGSN указывает на сбой доставки коротких сообщений, SMSC может отправить сообщение в HLR, используя процедуру MAP_REPORT_SM_DELIVERY_STATUS, указав причину сбоя доставки и запросив включение SMSC в список сервисных центров, желающих уведомляется, когда сторона назначения снова становится доступной. HLR установит флаг для учетной записи назначения, указывая, что она недоступна для доставки коротких сообщений, и сохранит адрес SMSC в списке данных ожидающего сообщения (MWD) для стороны назначения. Допустимые флаги: флаг недоступности мобильного устройства (MNRF), флаг превышения емкости памяти (MCEF) и недоступность мобильного устройства для GPRS (MNRG). HLR теперь начнет отвечать на запросы SRI-for-SM с ошибкой, указывая причину сбоя, и автоматически добавит адрес запрашивающего SMSC в список MWD для стороны назначения. (Однако, если для сообщения SRI-for-SM установлен флаг приоритета, HLR ответит адресом VLR, если он доступен)

HLR может быть проинформирован о том, что абонент становится доступным для доставки коротких сообщений, несколькими способами:

Если абонент был отключен от сети, повторное подключение вызовет обновление местоположения в HLR.
Если абонент был вне зоны обслуживания, но не полностью отключен от сети, при возвращении в зону действия абонент будет отвечать на запросы страниц от Регистр местоположения посетителей (VLR). Затем VLR отправит HLR сообщение Ready-for-SM (наличие мобильного устройства).
Если память MS заполнена, а подписчик удаляет некоторые тексты, сообщение Ready-for-SM (доступная память) отправляется из VMSC / VLR в HLR.

После получения указания о том, что сторона-адресат теперь готова к приему коротких сообщений, HLR отправляет сообщение AlertSC MAP каждому из SMSC, зарегистрированных в списке MWD для подписчика, в результате чего SMSC запускает Доставка коротких сообщений процесс снова, с самого начала.^[1]

Кроме того, SMSC войдет в расписание повторных попыток, периодически пытаясь доставить SM без получения предупреждения. Интервал расписания повторных попыток будет зависеть от исходной причины сбоя - временные сбои сети приведут к сокращению расписания повторных попыток, тогда как выход за пределы покрытия обычно приведет к более длительному расписанию.

MAP операции

Операции MAP, связанные с передачей коротких сообщений, сведены в следующую таблицу:

Операция	Код	Источник → Цель	КАРТА
Операция	Код	Источник → Цель	1	2	3
МТ-ФорвардСМ	44	GMSC → MSC / SGSN	−	−	+
МО-ФорвардСМ	46	MSC / SGSN → IWMSC	−	−	+
SendRoutingInfoForSM	45	GMSC → HLR	+	+	+
ФорвардSM	46	GMSC → MSC / SGSN	+	+	−
ФорвардSM	46	MSC / SGSN → IWMSC	+	+	−
ОтчетSM-DeliveryStatus	47	GMSC → HLR	+	+	+
AlertServiceCentreWithoutRes	49	HLR → IWMSC	+	−	−
ИнформСервисЦентр	63	HLR → GMSC	−	+	+
AlertServiceCentreWithResult	64	HLR → IWMSC	−	+	+

ИнформСервисЦентр

InformServiceCentre - это сообщение, HLR может предоставить ответ sendRoutingInfoForSM или reportSM-DeliveryStatus. Сообщение обычно используется для передачи флагов MWD в Центр обслуживания коротких сообщений.^[1]

Транспортные протоколы MAP

В то время как спецификации MAP 3GPP прилагают некоторые усилия, чтобы отделить MAP от уровня, который его транспортирует, обычно транспорт осуществляется через TCAP который, в свою очередь, осуществляется через протоколы SCCP / MTP [1-3] и / или SIGTRAN (SUA, M3UA и т. д.).

Следовательно, конструкция MAP_OPEN напрямую связана с TCAP_BEGIN с контекстом приложения MAP, а MAP_CLOSE - это TCAP_END.

Если сообщение доставляется с использованием MAP фазы 2 или выше и по MTP, а не СИГТРАН тогда максимальный размер PDU MTP может заставить отправителя инициировать отправку сегментированного сообщения. Этот процесс не связан с конкатенация, но просто означает, что транзакция с MSC / SMSC / SGSN включает больше шагов, чем обычно. Рекомендуемый способ^[1] - это пустой TCAP_BEGIN, за которым следует содержимое MAP в TCAP_CONTINUE и завершающееся TCAP_END. TCAP_BEGIN содержит информацию, относящуюся к TCAP, которая в противном случае привела бы к превышению предела из-за дополнительных полей, добавленных на этапе 2 MAP. Точная точка, в которой требуется сегментация, зависит от таких факторов, как длина адресов, но в основном зависит от длина сообщения. Сообщения с 7-битным алфавитом, длина которых составляет 140 символов или больше, обычно подвергаются процедуре сегментации MAP.

Операторы все чаще следуют этой процедуре сегментации и, при необходимости, применяют ее, чтобы избежать воздействия спуфинга SMS на своих клиентов. Это работает, потому что отправляющая сторона должна получить ответы, чтобы отправить сообщение, и поэтому их исходный адрес должен быть правильным.^[5]

Примечания

^ На этапе 1 MAP не было разделения кода операции для SMS-сообщений, отправляемых с мобильного устройства, и для SMS-сообщений с завершением с мобильного устройства, только обычная операция ForwardSM.
^ Признаком успеха в этих контекстах является только уведомление о том, что SM был отправлен в Сервисный центр, и не означает успешную доставку конечному адресату текстового сообщения.
^ Хотя MAP (фаза 2 и далее) определяет отдельную операцию для доставки коротких сообщений с мобильного терминала, вместо этого часто используется операция mo-ForwardSM. В этом случае исходящие и завершенные мобильные сообщения различаются включением в диалоговую часть TCAP соответствующего прикладного контекста (AC). Соответствующие AC - это shortMessageMO-RelayContext и shortMessageMT-RelayContext. Такое использование единого кода операции обеспечивает простую обратную совместимость с сетями MAP фазы 1, в которых нет отдельных операций для коротких сообщений MO и MT.
^ Эти сообщения не используются SGSN.

Navigation