短信发送失败排查指南：从‘发送中’到‘发送失败’，你的短信卡在了哪一步？
短信发送失败排查指南：从‘发送中’到‘发送失败’，你的短信卡在了哪一步？
短信作为基础通信服务，其稳定性直接影响用户体验。当一条短信从"发送中"变为"发送失败"时，背后可能涉及无线信号、核心网元、短信中心（SMSC）等多个环节的异常。本文将系统梳理短信传输全链路中的关键检查点，帮助技术人员快速定位问题根源。
1. 短信传输全链路解析
短信业务采用存储转发机制，主要涉及三个核心环节：
- MO（Mobile Originated）流程：主叫用户发送短信至短信中心
- 路由查询流程：短信中心通过HLR查询被叫用户路由信息
- MT（Mobile Terminated）流程：短信中心向被叫用户投递短信
典型失败场景分布比例如下（基于运营商统计数据）：
| 失败环节 | 占比 | 常见原因 |
|---|---|---|
| 无线接入层 | 38% | 信号弱、信道拥塞、终端异常 |
| 核心网传输层 | 25% | 信令超时、网元拥塞 |
| SMSC处理层 | 22% | 中心过载、参数配置错误 |
| HLR/VLR查询层 | 15% | 用户状态异常、路由信息不一致 |
2. 分阶段故障排查手册
2.1 发送端（MO阶段）问题排查
当用户点击发送后出现即时失败提示，通常问题出在MO阶段。建议按以下顺序检查：
终端侧验证：
- 检查手机信号强度（RSRP应＞-110dBm）
- 验证短信中心号码设置（通过
*#*#4636#*#*查看） - 尝试发送测试短信到其他号码
无线网络检查：
# 通过基站日志检查无线连接状态 grep "SMS Submission" /var/log/bsc.log | grep [用户IMSI]- 关注RACH接入成功率
- 检查SDCCH信道占用率（正常＜70%）
核心网信令跟踪：
提示：在MSC上捕获MAP信令，重点关注SRI-SM和ForwardSM消息
2.2 短信中心（SMSC）处理排查
短信到达SMSC后可能因以下原因滞留：
容量问题：
-- 检查SMSC队列深度 SELECT queue_name, current_size, max_size FROM smsc_queues WHERE queue_type = 'INBOUND';当current_size接近max_size时需扩容
HLR查询异常：
- 对比HLR返回的错误码：
ABSENT_SUBSCRIBER：用户关机MEMORY_CAPACITY_EXCEEDED：存储满UNKNOWN_SUBSCRIBER：号码不存在
- 对比HLR返回的错误码：
重发策略配置：
<!-- 典型重发配置示例 --> <retry_policy> <initial_interval>5m</initial_interval> <max_attempts>6</max_attempts> <expiry_time>72h</expiry_time> </retry_policy>
2.3 接收端（MT阶段）问题定位
当短信显示"已发送"但接收方未收到时，需检查MT阶段：
被叫状态检查：
- 通过HLR查询用户最新状态：
hlr_query -m [被叫MSISDN] -c GET_SUBSCRIBER_STATUS - 常见返回状态码：
0x01：正常待机0x02：关机0x04：漫游限制
- 通过HLR查询用户最新状态：
VLR投递验证：
- 检查MSC-VLR接口信令：
tshark -i eth0 -Y "gsm_map.opcode == 0x2b && gsm_map.imsi == [被叫IMSI]" - 关注
AlertSC和ReadyForSM消息
- 检查MSC-VLR接口信令：
终端接收能力：
- 检查被叫终端：
- 存储空间剩余（至少需10KB）
- 短信过滤设置
- 是否启用飞行模式
- 检查被叫终端：
3. 典型故障场景处置方案
3.1 区域集中性故障
特征：同一基站下多个用户发送失败
处置步骤：
- 检查BSC-MSC间七号链路状态
- 验证SCCP子系统状态：
ss7stat -s SCCP -a - 采集无线侧KPI：
- SDCCH掉话率
- 立即指配成功率
- Paging响应率
3.2 特定用户持续性失败
排查流程：
- 提取用户信令跟踪：
cd /opt/traces && zgrep [用户IMSI] *.pcap.gz - 检查HLR用户数据一致性：
SELECT * FROM subscriber_data WHERE imsi = '[用户IMSI]' AND hlr_node = 'PRIMARY'; - 验证VLR中用户状态：
vlr_tool --query --imsi [用户IMSI] --field AttachStatus
3.3 跨运营商短信异常
特殊检查项：
- 互联关口局（GMSC）路由表：
gsm_map_route -d [对方运营商PLMN] - 号码携带数据查询：
npdb_query -n [被叫号码] -t MNP - 信令编解码验证：
wireshark -r trace.pcap -Y "gsm_sms.tp_pid == 0x00"
4. 高级诊断工具与技巧
4.1 信令跟踪组合分析
推荐使用三层关联分析：
- 无线层：通过XCAP协议捕获空口信令
- 核心网层：在MSC采集MAP信令
- 业务层：SMSC交易日志分析
典型关联命令：
# 时间戳对齐分析 paste -d '|' wireless.log core_network.log smsc.log | sort -t '|' -k34.2 性能基线对比法
建立正常情况下的时延基线：
| 流程段 | 标准时延 | 告警阈值 |
|---|---|---|
| MO提交 | 1.2s | >3s |
| HLR查询 | 0.8s | >2s |
| MT投递 | 1.5s | >4s |
| 端到端 | 3.5s | >8s |
4.3 智能日志分析脚本
# 失败模式识别脚本示例 import re from collections import Counter def analyze_sms_failures(log_file): error_patterns = { 'HLR_TIMEOUT': r'HLR response timeout', 'VLR_REJECT': r'VLR returned error code (\d+)', 'SMS_CENTER_QUEUE_FULL': r'queue capacity exceeded' } results = Counter() with open(log_file) as f: for line in f: for err_type, pattern in error_patterns.items(): if re.search(pattern, line): results[err_type] += 1 return results.most_common(3)在实际运维中，我们发现最耗时的往往不是技术排查，而是确定问题边界。曾经处理过一个案例：某省用户投诉短信延迟，最终发现是相邻省份HLR数据同步异常导致的跨省路由错误。这提醒我们，当常规排查无果时，需要扩大检查范围到关联系统。