Техническая реализация службы коротких сообщений (GSM)
Служба коротких сообщений реализуется за счет использования части мобильных приложений (MAP) протокола SS7 , при этом элементы протокола коротких сообщений передаются по сети в виде полей в сообщениях MAP. [1] Эти сообщения MAP могут транспортироваться с использованием «традиционной» сигнализации на основе TDM или по IP с использованием SIGTRAN и соответствующего уровня адаптации.
Протокол
[ редактировать ]Сам протокол коротких сообщений определен 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 и телефонной трубкой были опущены, и показан только случай, когда домашняя маршрутизация 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 отправит сообщение Ready-for-SM (мобильное присутствие) в HLR.
- Если память MS заполнена и абонент удаляет некоторые тексты, сообщение Ready-for-SM (доступная память) отправляется из VMSC/VLR в HLR.
После получения указания о том, что сторона-получатель теперь готова принимать короткие сообщения, HLR отправляет сообщение AlertSC MAP каждому из SMSC, зарегистрированных в списке MWD для абонента, заставляя SMSC снова начать процесс доставки коротких сообщений . с самого начала. [1]
Кроме того, SMSC переходит в режим повторных попыток, пытаясь периодически доставлять SM без получения предупреждения. Интервал расписания повторных попыток будет зависеть от исходной причины сбоя: временные сбои сети приводят к короткому графику повторных попыток, тогда как вне зоны покрытия обычно приводит к более длинному графику.
Операции МАП
[ редактировать ]Операции MAP, связанные с передачей коротких сообщений, обобщены в следующей таблице:
Операция | Код | Источник → Цель | КАРТА | ||
1 | 2 | 3 | |||
МТ-ФорвардСМ | 44 | GMSC → MSC/SGSN | − | − | + |
МО-ФорвардСМ | 46 | MSC/SGSN → IWMSC | − | − | + |
Отправитьраутингинформофорсм | 45 | GMSC → HLR | + | + | + |
ФорвардСМ | 46 | GMSC → MSC/SGSN | + | + | − |
ФорвардСМ | 46 | MSC/SGSN → IWMSC | + | + | − |
ОтчетSM-DeliveryStatus | 47 | GMSC → HLR | + | + | + |
АлертСервисЦентрБезРес | 49 | HLR → IWMSC | + | − | − |
ИнформСервисЦентр | 63 | HLR → GMSC | − | + | + |
Алертсервицецентревисрезультат | 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, а не SIGTRAN , то максимальный размер 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-сообщений, исходящих и входящих на мобильные устройства, а была только общая операция ForwardSM.
- ^ Индикацией успеха в этих контекстах является только уведомление о том, что SM было отправлено в Сервисный центр, и не означает успешную доставку до конечного пункта назначения текстового сообщения.
- ^ Хотя MAP (начиная с этапа 2) определяет отдельную операцию для доставки коротких сообщений на мобильных устройствах, часто вместо этого используется операция mo-ForwardSM. В этом случае исходящие и входящие мобильные сообщения различаются путем включения в часть диалога TCAP соответствующего контекста приложения (AC). Соответствующими AC являются shortMessageMO-RelayContext и shortMessageMT-RelayContext. Такое использование единого кода операции обеспечивает простую обратную совместимость с сетями фазы 1 MAP, которые не имеют отдельных операций для коротких сообщений MO и MT.
- ^ Эти сообщения не используются SGSN.
Ссылки
[ редактировать ]- ^ Перейти обратно: а б с д и ж г час Спецификация части мобильного приложения, 3GPP TS 29.002, доступна здесь.
- ^ Перейти обратно: а б с д Спецификация SMS «точка-точка», 3GPP TS 23.040, доступна здесь.
- ^ Спецификация службы сотового вещания 3GPP TS 23.041, доступна здесь.
- ^ Перейти обратно: а б Поддержка службы коротких сообщений (SMS) «точка-точка» (PP) в спецификации интерфейса мобильной радиосвязи, 3GPP TS 24.011, доступно здесь
- ^ 3GPP TS 33.204 Проект партнерства третьего поколения; безопасность пользователей прикладной части транзакционных возможностей (TCAP); Приложение D: Использование подтверждения TCAP для передачи SMS