Преобразование текста в формат PDU

Я разрабатываю сервер сообщений, который поддерживает формат PDU (с использованием телефона Android) для отправки сообщений. Я использовал онлайн-кодировщики для преобразования моего текста, но я не знаю реальных шагов для преобразования текста в формат PDU. Я не думаю, что это просто шестнадцатеричное число.

Я использовал команды at для отправки сообщений из гипертерминала.

Кто-нибудь может помочь?

Я использовал AT-команды:

    at
    at+cmgf=0
    at+cmgs=25 (Length i guess)
    >"encoded message"

person Mohammad Rashid    schedule 21.10.2015    source источник


Ответы (1)


Команда AT+CMGS определена в стандарте 3GPP 25.005, а для Режим PDU его синтаксис задается как

+CMGS=<length><CR>
PDU is given<ctrl-Z/ESC>

а в описании это дополнительно указано

PDU должен иметь шестнадцатеричный формат (аналогично указанному для <pdu>) и указываться в одной строке; ME/TA преобразует это кодирование в фактические октеты PDU.

Формат <pdu> определен в разделе Параметры данных сообщения в главе 3.1 Определения параметров:

В случае SMS: 3GPP TS 24.011 [6] адрес SC, за которым следует 3GPP TS 23.040 [3] TPDU в шестнадцатеричном формате: ME/TA преобразует каждый октет блока данных TP в длинное шестнадцатеричное число из двух символов IRA (например, октет с целым значением 42 представляется TE как два символа 2A (IRA 50 и 65))

(SC — это сокращение от Сервисный центр)

И здесь начинается все самое интересное, потому что теперь вам нужно очень, очень, очень глубоко покопаться в этих других спецификациях, чтобы раскрыть фактический формат...


Например, 24.011 описывает низкоуровневый формат данных для сообщений, отправляемых между мобильным телефоном и сетью, где в данном контексте имеют значение только его части.

7.3.1.2 RP‑DATA (от мобильной станции к сети) Это сообщение отправляется в направлении MS ‑> MSC. Сообщение используется для ретрансляции TPDU. Информационные элементы соответствуют 3GPP TS 23.040.

и в приведенной таблице две последние строки являются соответствующими частями, адресом сервисного центра и TPDU.

Information element, Reference, Presence, Format, Length
RP‑Message Type, Subclause 8.2.2, M, V, 3 bits
RP‑Message Reference, Subclause 8.2.3, M, V, 1 octet
RP‑Originator Address, Subclause 8.2.5.1, M, LV, 1 octet
RP‑Destination Address, Subclause 8.2.5.2, M, LV, 1‑12 octets
RP‑User Data, Subclause 8.2.5.3, M, LV, <= 233 octets

Пытаясь копнуть дальше, я застрял, пытаясь выяснить значение номера адреса назначения RP-Destination IEI, и я уже потратил много времени на написание этого ответа. Извините, что остановился здесь. Фактическая кодировка телефонного номера является «нормальной» кодировкой номера BCD вызываемой стороны (10.5.4.7 в 24.008), а TON+NPI совпадает с аргументом <type> в AT+CPBW, например. А кодировка текста - это отдельная история...


Попытка расшифровать части спецификаций 3GPP иногда может быть очень сложной, а возможности неправильной интерпретации могут быть почти бесконечными! Если вы действительно настроены на разработку собственного кода для этого, вам, вероятно, лучше начать читать хорошие вводные сведения о режиме PDU, такие как http://mobiletidings.com/2009/02/11/more-on-the-sms-pdu/1. Или найдите код в уже существующей библиотеке/программе, обрабатывающей режим PDU2.

1 Обратите внимание, что подобные статьи хорошего качества встречаются редко, если в тексте нет ссылок на подробные/технические термины из стандартов 3GPP, что обычно является показателем низкого качества.

2 Опять же, обратите внимание на хорошее качество.

person hlovdal    schedule 22.10.2015
comment
Я получил код для конвертации... но большое спасибо, вы дали мне слишком много для изучения.. :) - person Mohammad Rashid; 26.10.2015