简介短信发送流程学习教案是一份面向通信网络从业者及高校相关专业学生的专业课件聚焦短信从用户发送到接收方成功收到的完整信令链路。资源包内仅含1个演示文稿文件整体体积约158KB以流程节点图配合分步说明的组织方式呈现全篇共8页。目前已有67人学习/下载适用于课程教学、个人自学或网络维护参考。课件系统梳理了漫游用户MO流程、省内互通短信MO流程、省内用户MT流程、漫游用户MT流程及省外用户MT流程五大典型场景逐环节标明MS、BSC、MSC、LSTP、HSTP、SMSC、HLR等网元的交互逻辑详细展示了短信中心对用户号段鉴权、ISMG系统间消息网关转发、跨省HSTP/LSTP转接以及计费话单生成等关键机制。通过对照不同场景下的转发路径和应答消息顺序读者可以清晰理解漫游与本省、省外场景的差异掌握短消息服务中心如何协同归属位置寄存器完成下发同时也能借助流程图中的节点编号快速定位短信发送失败时可能出错的网络环节从而提升对移动通信网元协作与故障排查的综合认知。1. 短信发送流程学习教案.pptx一张流程图讲不透的真实链路第一次给新同事讲短信发送流程我只在幻灯片上画了三个框发送方、短信中心、接收方中间一根箭头标“发送”。台下的人点头一周后他们遇到“短信发出去了但用户没收到”就来问我怎么办。问题就出在那根箭头上——真实链路远不止三步每一步都可能卡住而且每一步卡住的现象都差不多不拆开讲排障就靠猜。所以拿到《短信发送流程学习教案.pptx》这类材料时不要把它当作一条直线流程来教。它真正要解决的是三个问题什么算发送成功、为什么收不到、怎么定位是手机侧还是网关侧的问题。这套内容适合给开发、产品、客服做内部培训也适合做短信网关方案汇报。下面按我自己做短信平台时的思路把这份教案的讲法、做法和坑一次说明白。2. 先把短信发送流程拆成四段从用户可见到信令不可见短信不是点对点直接传的。用户在手机上按下发送消息要先到短信中心SMSC短信中心再想办法找到接收方当前所在的网络位置把消息推过去最后回一个送达回执。这中间至少要经过移动通信网里的好几个网元。教案里最忌讳画一根粗箭头要拆成四段讲发送方到短信中心、短信中心到接收方、状态报告回传、有效期与重试。每一段的“成功”含义都不同。2.1 发送方到短信中心先把“提交”和“发送”分清这一段在信令里叫 MOMobile Originated流程。用户的手机先把短信内容打包通过基站送到当前接入的移动交换中心MSC/VLR再由 MSC 转给短信中心。短信中心收到后会返回一个提交结果通常叫 Submit Result。这个结果才是“短信真的进入短信中心队列”的唯一凭证。很多教案把这一步画成“网络发送成功”这是错的因为此时接收方手机根本还不知道发生了什么。我在培训里会强调三个时间点手机点击发送按钮、MSC 收到消息、短信中心返回确认。学员至少要学会看对应的日志而不是只看界面上的“已发送”。如果短信中心返回的是错误码比如有效期格式不对、短信中心号码无效消息会直接停在半路。用户看到的消息气泡已经发出但实际根本没有进入转发队列。所以这一段的教学重点不是图标而是“提交成功不等于发送成功”。2.2 短信中心到接收方HLR 寻址是绕不开的关键短信中心收到了消息下一步要找接收方这一段的信令叫 MTMobile Terminated流程。短信中心并不直接知道接收方手机在哪里它要去问归属位置寄存器HLR。HLR 里保存着用户当前登记所在的 MSC/VLR 地址短信中心拿到这个地址后才把消息投递给对应的交换设备再由交换设备寻呼手机。如果接收方手机关机或不在服务区HLR 会返回一个“用户不可达”的应答。注意这不是失败短信中心会把消息放进重试队列隔一段时间再投直到超过有效期才丢弃。教案里一定要把这个存储转发机制画出来短信中心是仓库不是邮局里的送信员。初学者容易把短信和微信混在一起以为接收方不上线消息就丢了。实际上短信中心会帮我们等一段时间这也是后面讲有效期参数的入口。2.3 状态报告一个可能丢也可能滞后的信号状态报告Delivery Report是短信中心在接收方手机反馈送达结果之后生成的回执用来告诉发送方“短信已经到达接收方手机”。但有两个客观事实要先讲清楚第一状态报告不是默认必有的要发送方在提交消息时主动要求短信中心才会回第二即便要求了它也可能因为运营商网络原因延迟很久甚至直接缺失。我在教案里放了一张表列状态报告缺失的常见可能接收方关机导致短信中心还在重试、短信中心队列拥堵、接收方网络环境异常、网关侧没有把回执转给我们。这样学员看到“没有回执”时不会立刻判断失败。短信平台里常见的“已提交”“已送达”两个状态PPT 上要做成两种颜色彻底分开。2.4 有效期和重试教案里唯一要讲给开发听的参数短信中心保存一条消息的时间不是无限的。通常会有有效期Validity Period常见设置为 24 小时、48 小时或 72 小时。超过有效期还没投递给接收方短信中心就会把这条消息作废返回一个超时类状态报告。这里的重试是短信中心内部做的发送方接口一旦返回“提交成功”后面再发生什么都不归发送方控制了。这一段通常被培训讲师跳过但它恰好是开发最需要理解的为什么客户端不能无限重发因为没有幂等控制的重发会造出重复短信。我自己做网关对接时会把有效期、重试次数、重试间隔作为必填参数写进接口文档教案里也建议列一张参数表有效期决定最长等待时间重试次数决定最大投递努力间隔决定对交换设备的压力。这三者的关系讲透了学员才算真正理解这条链路。3. 教案 PPT 怎么搭从目录到流程图的落地模板这一章专门说怎么把短信发送流程做成能直接开讲的 PPT。我见过很多同事直接把协议文档截图贴到幻灯片上字小、线乱讲完没人记得住。我的做法是先定页面骨架再给每一页规定要出现的图和参数最后用一页案例轨迹表把前面所有内容串起来。3.1 一套能直接照抄的 PPT 页面结构12 页把链路讲清如果是 30 到 40 分钟的培训建议按下面 12 页来做不多不少。页码页面标题教学目的备注1封面短信发送流程学习教案交代课程范围标题直接写清楚2学完你能回答哪四个问题定下课堂目标成功没收到谁的问题能重发吗3名词表统一术语SMSC、MSC、HLR、状态报告4端到端总览图建立全局一条主链路两条异步分支5发送方到短信中心MO区分提交和发送突出 Submit Result6短信中心到接收方MTHLR 寻址画出存储转发队列7状态报告从哪来讲回执的不确定性强调缺失不等于失败8长短信拆分规则避免字数学员算错举 GSM-7 和中文两个例子9有效期与重试讲开发参数时间线和重试计数器10网关接口时序把流程连到代码提交和回执是两次请求11案例轨迹表综合演练用一条业务短信贯穿12排障决策树培训落地现象到检查点第 2 页的几个问题建议写成“这条短信算成功了吗”“用户说没收到最先看哪个日志”“是发送方的问题还是网关的问题”“能不能重发重发会不会重复”四个问题贯穿整场培训讲到对应页时回头看一眼学员不会走神。第 5 页和第 6 页不要放过多的英文缩写每个英文出现时旁边画一个小框注明功能否则非信令背景的人会卡住。3.2 流程图绘制的统一规范符号、层级、颜色短信流程里会出现大量异步回执、失败分支和定时重试PPT 上如果不统一画法图就变成一团乱麻。我通常给项目定三条规则。第一实线表示本轮同步流程虚线表示异步通知或状态报告。这样学员看到虚线时会习惯性地问“这个回执什么时候到”而不是以为它立刻发生。第二失败路径统一用红色而且只画一跳不要从短信中心画一条红箭头直接到用户这是最常见的逻辑错误。失败要落到具体环节比如“HLR 查询失败”和“MSC 投递失败”是两件事。第三每个环节的命名用“动词 对象”比如“提交短信”“查询路由”“投递消息”“上报回执”不要写“短信中心处理”。处理这个词没有任何信息量。我还在每张流程图的右下角标注当前这张图属于第几段链路方便学员翻回总览图对照。这个习惯是从画系统架构图时学来的层级不清的流程图讲的时候自己都会绕进去。3.3 一页“案例轨迹表”把流程串起来流程图画得再清楚学员最后还是需要一个具体例子把时间轴串起来。我在 PPT 第 11 页放一张轨迹表用一条真实业务短信的时间线展示每个环节发生的事。时间环节状态观察点10:00:00用户点击发送提交中手机界面显示已发送10:00:01手机上报到 MSC提交中日志出现手机号和时间戳10:00:02短信中心返回提交结果已接收Submit Result具备 msg_id10:00:03短信中心向 HLR 查询寻址中查询路由信令10:00:04短信中心向 MSC 投递投递中目标 MSC 地址出现10:00:08接收方手机确认已送达手机亮屏短信可见10:00:15状态报告回传回执已收注意回执比送达慢这张表的妙处在于每个“状态”都是一条可对上的日志关键词。学员把这份表格带回去排障时对照自己手里的系统记录基本能定位是卡在哪一段。如果项目里有真实的数据建议把手机号位和脱敏字段替换成真实样例效果比什么都好。4. 用 Python 把发送流程“跑”一遍状态机模拟与网关接口对接PPT 讲完学员需要一次动手。不需要真的连运营商网关可以用 Python 写一个最小状态机模拟一条短信从提交到收到回执的完整生命周期。这个模拟器既能当教学演示也能在项目里当异步消息处理的小框架。下面给出两段可跑的代码第一段模拟流程第二段演示真实 HTTP 网关对接时的请求写法。4.1 先建一个最小状态机让每条消息按状态流转写模拟器前先把状态定义清楚。一条短信在平台侧至少要有这些状态待提交、已提交到短信中心、已送达、失败、过期。用一个枚举和 dataclass 承载代码里还能顺带统计重试次数。from dataclasses import dataclass from enum import Enum import time class SmsStatus(Enum): PENDING pending # 待提交 SUBMITTED submitted # 已提交到短信中心 DELIVERED delivered # 已送达 FAILED failed # 失败 EXPIRED expired # 超过有效期 dataclass class SmsMessage: msg_id: str phone: str content: str status: SmsStatus SmsStatus.PENDING submit_time: float 0.0 report_time: float 0.0 retry_count: int 0 max_retry: int 2 validity_seconds: int 30逻辑说明这里定义了一个SmsMessage对象msg_id是全链路唯一键后面所有日志和状态报告都靠它关联。retry_count和max_retry模拟短信中心在接收方不可达时的重试行为validity_seconds模拟有效期。实际项目里这些字段会来自网关协议比如 CMPP 的 MsgId 和 SrcId 就对应这里的 msg_id 和来源号码。4.2 模拟短信中心提交、重试、过期一屏看清短信中心的行为不是瞬间完成的我用一个后台线程每隔一秒扫描一次消息队列对超过 2 秒还没投递成功的消息做重试或标记过期。import threading class SmsCenterSimulator: def __init__(self): self.messages {} def submit(self, sms: SmsMessage): sms.status SmsStatus.SUBMITTED sms.submit_time time.time() self.messages[sms.msg_id] sms print(f短信中心已接收: {sms.msg_id}, {sms.phone}) def scan(self): now time.time() for sms in list(self.messages.values()): if sms.status ! SmsStatus.SUBMITTED: continue age now - sms.submit_time if sms.retry_count sms.max_retry: sms.retry_count 1 print(f接收方不可达第 {sms.retry_count} 次重试: {sms.msg_id}) elif age sms.validity_seconds: sms.status SmsStatus.EXPIRED print(f超过有效期消息作废: {sms.msg_id}) else: sms.status SmsStatus.DELIVERED sms.report_time now print(f短信已送达: {sms.msg_id}) simulator SmsCenterSimulator() msg SmsMessage(msg_idMSG001, phone13800138000, content测试短信) simulator.submit(msg) for _ in range(5): simulator.scan() time.sleep(1)参数说明scan()方法里先判断是否已到达最大重试次数。这里为了让演示可控临时把“重试”当作“到达投递成功”的必经路径实际短信中心会在两次重试之间间隔一段时间。你可以把scan()改成按调度周期执行不要在主线程里阻塞项目落地时至少用独立线程或异步任务。代码里的validity_seconds30是演示值真实短信有效期按小时算不要照抄到生产配置里。4.3 对接真实 HTTP 网关提交接口和回执接口是两个动作真实业务里平台通过 HTTP 接口向短信网关提交消息状态报告由网关异步回调到我们提供的回执地址。初学者最容易犯的错是在提交响应里等“送达”这是不可能的。下面是一段提交短信的 Python 请求示例。import requests import uuid def send_to_gateway(api_endpoint, api_key, phone, content, source_code, callback_url): msg_id str(uuid.uuid4()) payload { msg_id: msg_id, phone: phone, content: content, source_code: source_code, # 发送方签名或接入码 report_request: True, # 显式要求状态报告 callback_url: callback_url # 网关回执回调地址 } headers { Authorization: api_key, Content-Type: application/json } resp requests.post(api_endpoint, jsonpayload, headersheaders, timeout15) resp.raise_for_status() result resp.json() return result.get(msg_id) or msg_id逻辑说明msg_id是我们自己生成的网关接口会把它原样带回来回执回调里也靠它匹配原消息。report_request这个参数尤其重要很多网关默认不返回状态报告不传 true 的话平台里永远看不到“已送达”。callback_url是接收异步回执的地址不能和提交接口共用一个接口签名否则提交和回执会互相污染话单。这里timeout15指请求网关的提交超时而不是等送达理解这层区别就理解了短信异步的特性。真实环境里提交响应只代表网关收了不代表用户收到生产上要按这个语义设计状态。5. 短信发送流程教案里的五个高频坑讲错一次现场就翻车这一章是我在这些年对接多个短信网关之后沉淀下来的踩坑记录。每一次都是先有线上工单再回头改教案。写进 PPT 里能让学员少走一轮弯路。5.1 用户看到“已发送”短信中心不一定收下了现象用户手机界面显示消息已发送客服查平台日志发现根本没有这条提交记录。原因手机本地“已发送”只代表消息交给基站的通信模块了不代表短信中心返回了 Submit Result。可能是手机里短信中心号码配置错误也可能当前网络信号差消息根本没进入核心网。解决教案要把“发送成功”的判定标准定义为收到短信中心提交回执或网关接口返回的 msg_id。排障时先查短信中心侧有没有这条消息而不是看用户手机截图。5.2 状态报告缺失不代表短信丢了现象短信实际已经到达接收方手机但平台状态一直停在“已提交”用户也确认收到了。原因接收方手机可能关闭了送达报告或者运营商漫游网络不产生回执再或者网关侧没有把回执推送到我们的回调地址。状态报告本身是增强特性不是短信的基本属性。解决教案里明确写“无回执不等于未送达”并给出三个检查点提交接口是否携带 report_request回调接口有没有返回成功应答给网关msg_id 是否匹配。把这条讲清楚能避免学员在客服电话前反复重发。5.3 长短信拆分规则一变字数立刻对不上现象教案里写一条短信最多 70 个汉字结果用户实际收到两条内容断成两段。原因70 字是纯英文 GSM-7 编码下的单条上限中文走 UCS2 编码每条最多 67 个字符。超过后就按长短信拆分用户在手机上看到的是拼接内容但计费和话单按拆出来的条数算。解决教案放一张参数表区分三种情况GSM-7 编码单条 160 字节约 160 个英文字符UCS2 编码单条 140 字节约 70 个汉字长短信使用多段拼接每条再扣 6 字节头中文变成 67 字每段。讲这个坑时我习惯让学员现场算一条 200 字的中文短信会被拆成几段算完他们就不会把字数阈值背错。5.4 超时重发和“重复短信”其实是同一件事现象用户收到两条完全一样的短信。原因平台调用网关接口时超时发送方没有收到响应于是把同一条消息再提交一次。网关已经接收了第一次请求第二次又创建了新 msg_id用户侧自然收到重复内容。解决提交接口必须传幂等键也就是 msg_id。网关侧用同一 msg_id 去重第二次提交要么返回原结果要么拒绝。教案里我会把重发逻辑画成一张小决策图超时后先查询原消息状态再决定是否重发而不是直接重发。这条对开发和产品都是重要知识。5.5 别把“短信中心号码”和“接收方号码格式”混在一起讲现象学员照着教案里的示例做对接小范围测试全部失败。原因示例文档里手机号写成 11 位纯数字没有区号前缀网关要求 E.164 格式于是号码被当成未知用户拒绝。原因可能也出在短信中心号码上不同运营商不同地区的短信中心号码都不同用户换卡后手机里存的是老号码。解决教案统一用“86 后面跟 11 位号码”作为标准格式另外说明短信中心号码归运营商配置开发不需要在业务代码里硬编码它。这条坑不深但最容易让团队内部争论半天提前讲清楚能少很多无谓工单。6. 把教案改成可验证的排障手册一张状态迁移表的妙用最后一招不是给学员讲的是给讲师和负责人用的。我会在教案最后页放一张状态迁移表让学员把之前所有箭头翻译成“当前状态 触发事件 下一状态”。这张表既是课堂练习也是线上排障时的快速参考。当前状态触发事件下一状态对业务逻辑的提醒pending网关注入成功submitted记录 msg_idsubmitted接收方短信心跳恢复delivering短信中心开始重试delivering手机返回确认delivered以回执回调为准submitted超过有效期expired需要人工标记失败原因any网关返回明确错误码failed不能盲目重发组织学员填这张表时我会让他们把每一行的触发事件写具体不写“网络错误”这种无法判断的词。写“HLR 查询无响应”和写“返回错误码 9”是有本质区别的。上线后这张表要贴到运维文档里一旦报警先按表里的事件找对应状态再决定动作。我做短信平台的教训是最贵的不是网关费用而是问题发生时大家靠猜做决定。教案的价值不在于那几十页幻灯片而在于它能不能让每个参与的人在紧急时刻说出“现在状态是什么、下一步应该看什么”。希望这个思路对你做培训教案和实际对接都有帮助。本文还有配套的精品资源点击获取
