使用 Wavecom 调制解调器通过 AT+CMGL 读取多部分 SMS
Reading Multipart SMS with AT+CMGL using Wavecom modem
我尝试在 PDU 模式下阅读多部分短信。
该消息分为 3 个部分
下面是我使用命令AT+CMGF=0和AT+CMGL=4得到的PDU
Part1:07914150740250F7440B917130263521F600005140723295528AA005C01B5B0301B2E53C194D46A3C96834196D169BD16833DA8C368BCD62B3D82C368BCD62B3586C169BC566B1596C169BC562B3D82C368BCD62B3D82C368BCD62B3DBEC769BDD66B7D90D328B41663768DC0699DD66B7D96D769BDD66B7D96D76BBCD6EB3DBEC36BBCD6EB3DBEC36BBCD6EF7D96D769BDD67F7D96D769FDD67B7FBEC3EBBCFEEB3DB7D769FDD
Part2:07912160130320F8440B917130263521F600005140723295528AA005C01B5B0302CE6EB3DBEC56AB41D9729E8C26A3D164349A8C368BCD68B4196D469BC566B1596C169BC566B1592C368BCD62B3D82C368BCD62B1596C169BC566B1596C169BC566B1D96D76BBCD6EB3DBEC0699C520B31B346E83CC6EB3DBEC36BBCD6EB3DBEC36BBDD66B7D96D769BDD66B7D96D769BDD66B7FBEC36BBCDEEB3FBEC36BBCFEEB3DB7D769FDD
Part3:07914140540500F9440B917130263521F600005140723295528A1805C01B5B0303CEEEB3DB7D769FDD67B7D96D76ABD5
*根据我的理解，为了确定它是否是多部分消息，我必须检查 TP-UDHI 是否设置在第一个八位字节的第六位。在这种情况下，它没有设置。
*PDU 的粗体部分是数据头
*我想为了表明这是一条连接消息，它必须是 00 而不是 C0？
如有错误请指正..
问题 1：在这种情况下，为什么没有设置 TP-UDHI 第一个八位字节是 07？
问题2：为什么UDH的第一个八位字节不是00而是C0？
好的，回答问题 1) 您错过了在 PDU 开头发现的 SMSC 地址。所以实际上你的 PDU header 八位字节是 44。这表明 PDU 中存在 UDH。
这是 SMSC 地址：
07914150740250F7
紧接着是 PDU header 44.
关于问题 2) 事情变得有点复杂。现在我没有发现 UDH 包含任何串联 SMS 的迹象。不要忘记 UDH 不仅仅用于级联消息。它可以包含许多基于 3GPP ETSI 规范 03.40 的其他信息。
仔细查看后，似乎是 SMS 在发送方进行了奇怪的编码，或者移动运营商乱用了 UDH。您正确地将 UDH 隔离为：
C01B5B0302
根据前一个字节，UDH 长度应为 5 个字节。但第一个 IEI（信息元素）具有误导性。 C0 将 IEI 定义为 SC 特定的 IEI，而不是级联的 IEI。然后 1B 的下一个说 IEI 数据应该是 27 字节长，这与 5 的 UDH 长度相矛盾。
所以从我的角度来看，有些东西破坏了 UDH（这可能发生在移动运营商、短信聚合商，甚至是错误的编码器上）。
如果您想尝试删除 C01B 并替换为 0003 以确保 8 位连接引用：
00035b0301
00035B0302
00035B0303
然后你会得到一个 UDH 告诉你 MR 是 91 并且零件指定正确。
我尝试在 PDU 模式下阅读多部分短信。 该消息分为 3 个部分
下面是我使用命令AT+CMGF=0和AT+CMGL=4得到的PDU
Part1:07914150740250F7440B917130263521F600005140723295528AA005C01B5B0301B2E53C194D46A3C96834196D169BD16833DA8C368BCD62B3D82C368BCD62B3586C169BC566B1596C169BC562B3D82C368BCD62B3D82C368BCD62B3DBEC769BDD66B7D90D328B41663768DC0699DD66B7D96D769BDD66B7D96D76BBCD6EB3DBEC36BBCD6EB3DBEC36BBCD6EF7D96D769BDD67F7D96D769FDD67B7FBEC3EBBCFEEB3DB7D769FDD
Part2:07912160130320F8440B917130263521F600005140723295528AA005C01B5B0302CE6EB3DBEC56AB41D9729E8C26A3D164349A8C368BCD68B4196D469BC566B1596C169BC566B1592C368BCD62B3D82C368BCD62B1596C169BC566B1596C169BC566B1D96D76BBCD6EB3DBEC0699C520B31B346E83CC6EB3DBEC36BBCD6EB3DBEC36BBDD66B7D96D769BDD66B7D96D769BDD66B7FBEC36BBCDEEB3FBEC36BBCFEEB3DB7D769FDD
Part3:07914140540500F9440B917130263521F600005140723295528A1805C01B5B0303CEEEB3DB7D769FDD67B7D96D76ABD5
*根据我的理解，为了确定它是否是多部分消息，我必须检查 TP-UDHI 是否设置在第一个八位字节的第六位。在这种情况下，它没有设置。
*PDU 的粗体部分是数据头
*我想为了表明这是一条连接消息，它必须是 00 而不是 C0？
如有错误请指正..
问题 1：在这种情况下，为什么没有设置 TP-UDHI 第一个八位字节是 07？
问题2：为什么UDH的第一个八位字节不是00而是C0？
好的，回答问题 1) 您错过了在 PDU 开头发现的 SMSC 地址。所以实际上你的 PDU header 八位字节是 44。这表明 PDU 中存在 UDH。
这是 SMSC 地址：
07914150740250F7
紧接着是 PDU header 44.
关于问题 2) 事情变得有点复杂。现在我没有发现 UDH 包含任何串联 SMS 的迹象。不要忘记 UDH 不仅仅用于级联消息。它可以包含许多基于 3GPP ETSI 规范 03.40 的其他信息。
仔细查看后，似乎是 SMS 在发送方进行了奇怪的编码，或者移动运营商乱用了 UDH。您正确地将 UDH 隔离为：
C01B5B0302
根据前一个字节，UDH 长度应为 5 个字节。但第一个 IEI（信息元素）具有误导性。 C0 将 IEI 定义为 SC 特定的 IEI，而不是级联的 IEI。然后 1B 的下一个说 IEI 数据应该是 27 字节长，这与 5 的 UDH 长度相矛盾。
所以从我的角度来看，有些东西破坏了 UDH（这可能发生在移动运营商、短信聚合商，甚至是错误的编码器上）。
如果您想尝试删除 C01B 并替换为 0003 以确保 8 位连接引用：
00035b0301
00035B0302
00035B0303
然后你会得到一个 UDH 告诉你 MR 是 91 并且零件指定正确。