长短信(Concatenated SMS)技术解析与AT指令实践

1. 项目概述：长短信发送的技术痛点

每次看到手机里超过70个字符的短信被自动拆分成多条发送，作为通信行业的老兵总有种说不出的别扭。这种被称作"长短信"（Long SMS或Concatenated SMS）的技术，其实早在2003年就被GSM协会纳入标准，但直到今天仍有大量物联网设备和老旧模块无法正确处理。

我经手过的十几个车载T-BOX项目中，至少有7个遇到过AT指令发送长短信失败的问题。最典型的表现是：接收端显示乱序、内容丢失甚至直接拒收。这往往不是硬件问题，而是开发者对协议理解不透彻导致的。

2. 核心协议解析：UDH与文本编码

2.1 短信协议分层结构

普通短信（SMS）本质上是个承载在信令信道上的数据包，最大容量140字节。当内容超过这个限制时，需要通过用户数据头（UDH）实现分片重组：

code复制| 1字节 | 1字节 | 1字节 | 1字节 | 1-153字节 |
|-------|-------|-------|-------|-----------|
| SC    | PDU   | UDL   | UDH   | 实际数据   |

其中关键字段：

• SC：服务中心地址长度（通常为0）
• PDU：协议数据单元类型
• UDL：用户数据总长度
• UDH：用户数据头（长短信关键）

2.2 长短信UDH结构详解

一个典型的长短信UDH包含6字节元数据：

code复制| 0x00 | 0x03 | 0xXX | 0xXX | 0xXX | 0xXX |
|------|------|------|------|------|------|
| IEI  | IEDL | Ref  | Total| Seq  | 保留  |

• IEI(0x00)：信息元素标识，表示这是长短信头
• IEDL(0x03)：后续数据长度
• Ref：2字节随机生成的参考编号（相同长短信需一致）
• Total：总片段数
• Seq：当前片段序号（从1开始）

关键点：所有分片的Ref值必须相同，否则接收端无法重组。我曾遇到过因随机数生成器缺陷导致Ref冲突的案例。

3. AT指令实战：完整发送流程

3.1 基础AT指令准备

以SIM800C模块为例，首先需要确认模块支持长短信：

bash复制AT+CSMS=?
# 正常响应应包含",1"表示支持phase 2+

设置文本模式并启用UDH：

bash复制AT+CMGF=1
AT+CSMP=17,167,0,8

其中CSMP参数解析：

• 17：有效期最大值
• 167：0xA7（二进制10100111）表示启用UDH
• 0：协议标识
• 8：数据编码方案（8-bit）

3.2 分片计算与编码

假设要发送160字符的短信（超过单条70字符限制），需要拆分为3段：

python复制def split_sms(content, max_len=67):  # 67=70-3(UDH开销)
    chunks = [content[i:i+max_len] for i in range(0, len(content), max_len)]
    return chunks

实际发送时需要为每段添加UDH头。以下是生成PDU的Python示例：

python复制import random
ref_num = random.randint(0, 255)  # 生成参考号

def build_pdu(chunks, index):
    udh = f'050003{ref_num:02X}{len(chunks):02X}{index+1:02X}'
    hex_msg = chunks[index].encode('utf-16be').hex().upper()
    return f'00{udh}{hex_msg}'

3.3 实际发送指令

使用AT+CMGS发送每个分片：

bash复制# 第一段
AT+CMGS=23  # 长度值需根据实际PDU计算
> 0005000301CC0331323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536
Ctrl+Z

# 第二段
AT+CMGS=23
> 0005000301CC0231323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536373839303132333435363738393031323334353637383930313233343536
Ctrl+Z

实测技巧：发送后务必检查模块返回的"+CMS ERROR"代码。常见错误：

• 330：网络不支持长短信
• 500：UDH格式错误
• 512：内存不足

4. 疑难问题排查指南

4.1 乱序问题解决方案

现象：接收端显示顺序与发送顺序不一致

排查步骤：

1. 确认所有分片Ref值相同
2. 检查Seq序号是否从1开始连续递增
3. 在UDH后添加时间戳测试网络延迟
4. 使用Wireshark抓取GSM空中接口数据验证

4.2 编码兼容性问题

不同地区运营商对编码的支持差异：

强制指定编码方案：

bash复制AT+CSCS="UCS2"  # 统一使用Unicode

4.3 模块特定问题

常见模块的差异处理：

1. SIMCOM系列：

   • 需要额外设置：AT+CNMI=2,2,0,1,0
   • 发送超时需延长至20秒

2. Quectel系列：

   • 支持AT+QCMGS专用指令
   • 必须启用AT+QCMGDFLT=1

3. 华为ME909：

   • 需禁用流量控制：AT\Q0

5. 性能优化与进阶技巧

5.1 动态分片算法

传统固定分片会导致最后一个分片浪费空间。改进算法：

python复制def dynamic_split(text, header_len=6, max_pdu=140):
    chunks = []
    remaining = text
    ref = random.randint(0, 255)
    
    while remaining:
        chunk_len = (max_pdu - header_len) // 2  # UCS-2每个字符2字节
        chunk = remaining[:chunk_len]
        remaining = remaining[chunk_len:]
        chunks.append(chunk)
    
    return ref, chunks

5.2 发送状态机实现

可靠发送的状态机设计：

mermaid复制graph TD
    A[初始化] --> B{更多分片?}
    B -->|是| C[发送当前分片]
    C --> D{成功?}
    D -->|否| E[重试计数器+1]
    E --> F{重试<3?}
    F -->|是| C
    F -->|否| G[标记失败]
    D -->|是| H[更新分片索引]
    H --> B
    B -->|否| I[完成]

5.3 流量控制策略

根据网络状况动态调整：

1. 监控返回错误码：

   • 如果出现"303"（网络拥塞），等待2^N秒重试（指数退避）
   • "513"（消息队列满）时暂停发送10秒

2. 批量发送时：

   python复制def adaptive_send(messages):
       window_size = 1
       for msg in messages:
           while not try_send(msg):
               sleep(2 ** window_size)
               window_size = min(window_size + 1, 5)
           window_size = max(window_size - 1, 1)
   

6. 实测对比：不同方案性能数据

在城区环境测试（100条160字符短信）：

关键发现：

• 重试机制对成功率影响最大
• 动态分片可节省约8%的流量
• 预编码PDU比实时编码快40%

7. 硬件设计注意事项

1. 天线匹配：

   • 长短信会延长发射时间
   • 需确保天线驻波比<3:1（建议2:1内）

2. 电源管理：

   • 发送时电流突增可能引起电压跌落
   • 推荐并联1000μF电容

3. 散热设计：

   • 连续发送时模块温度可达60℃
   • 至少保留5mm通风间隙

8. 替代方案对比

当长短信不可靠时的备选方案：

在最近的智慧农业项目中，我们最终采用GPRS+短信双通道方案，长短信仅用于关键状态告警，实测将通信可靠性从87%提升到了99.6%。