USSD信令通道与USSDC会话机制及路由排障

简介：中国移动通信USSD应用接口协议系列企业标准文档，面向移动通信网络工程师、业务平台开发人员及通信专业师生，用于系统了解USSD业务从系统结构、组网方式到应用接口的实现要求。文档以QB-D-069-2009《USSD业务总体技术要求》为主线，串联应用接口协议、设备规范、业务流程、编号方式、计费与信息安全、标准编号等章节，并对API、HLR、HPLMN、MAP、MML、MS、MSC、MSISDN等关键接口与网元实现作出说明，适合作为设备选型、工程设计、业务规划与运维管理的技术依据。内容还对比USSD与短消息在信道占用、传输速率和响应方式上的差异，阐释其透明承载与面向连接特性，便于理解业务设计中的取舍。压缩包内共1个doc文件，约781KB，体量轻便，便于离线查阅与检索。已有577人学习，可作为USSD业务入门与规范对照的参考资料。

1. 一条 *100# 为什么不用“发送”：USSD 的本质是信令通道上的对话

很多开发者第一次接触 USSD，会下意识把它当成“发一条格式特殊的短信”——在手机上敲 *100#、按拨号键、等回复。这是一个容易让人翻车的误判。USSD 从设计之初就没走短信那条路：它占的是 GSM 补充业务的信令通道，不在网关里排队等存储转发，而是在 MSC/VLR、HLR 和 USSD 中心之间维持一条面向连接的会话。这个底层差异直接解释了为什么 USSD 必须有对话标识、必须有会话超时、长消息要拆包重组，以及服务号码前三位为什么被切成 70-79 和 150-199 两个路由域。该企业标准把“非结构化补充业务数据”从承载、组网到接口一层层固定下来，正好是拆解这类信令业务设计逻辑的标本；理解了它，再看任何一条 *100# 背后的每一跳，都不再是黑匣子。

2. 承载层拆解：USSD 为什么不存储转发却能保持会话

2.1 SDCCH 与 FACCH：信道选择如何决定速率

标准里有一句很容易被跳过的话：非通话态下 USSD 和 SMS 共用 SDCCH 信令信道，速率约 600bit/s；通话态时 USSD 改用 FACCH，速率约 1000bit/s。这个“约 600 对约 1000”的差异不是工程师随手写下的近似值，它来自两种信道的复用方式不同。SDCCH 是独立专用控制信道，手机空闲时只分配这一条窄带控制信道，文电要在这里排队走，速率自然被压到 600bit/s 量级；FACCH 则是快速随路控制信道，它借用业务信道的时隙块传信令，通话态下业务信道本来就存在，控制信息搭上现有链路，速率反而比空闲态更高。

理解这一点很关键：USSD 的速率上限并不是由某个应用层协议决定的，而是由“手机当前占着哪条信道”决定的。这也是为什么同一段交互，用户在通话中发起会比空闲态发起更快完成。很多做行业应用的开发者抱怨“客户在电话里操作比挂断后再操作快”，其实原因并不复杂——信道不同，速率就不同。

注意：不要把 600bit/s 当成端到端吞吐来估算业务容量，它只描述无线侧信令信道的承载能力，USSD 真正能跑多快还受限于 USSDC 的处理能力和 SP 侧的响应速度。

2.2 透明管道与不存储转发：会话为什么必须两端同时在线

USSD 与 SMS 最根本的机制差异在标准里写得直白：USSD 在会话过程中一直保持无线连接，提供透明管道，不进行存储转发；SMS 在物理承载层没有会话通道，只是一个存储转发系统。这句话换一种说法就是——USSD 没有“暂存区”。SMS 消息发到短信中心后可以先落盘，等收件人上线再投递；USSD 不行，手机这头和 SP 那头必须同时处在一条被 USSDC 中继起来的会话里，一方掉线，整条会话就失去意义。

这带来两个直接后果。第一，USSD 的响应是实时的，用户敲完 *100# 就能在几秒内看到下一级菜单，不需要等短信中心排队重试；第二，实时也意味着脆弱——任何一方在约定窗口内没有回话，USSDC 就必须主动释放资源，否则会话表会被长期挂起的“半条连接”占满。标准里之所以会给出 30 秒、180 秒、60 秒、10 分钟这一串超时数字，本质上就是在给“没有暂存区”这个机制补上资源回收的规矩。

把这两点合起来看，USSD 的设计动机就很清楚了：它不是要做一个“更快的短信”，而是要把移动网当成一根透明的承载管道，让运营商和应用方在这根管道上跑自己的交互逻辑。短信那种“发出去就不管”的模型，在需要多轮菜单、需要实时扣费、需要会话级上下文的场景里根本不成立。

2.3 USSD 与 SMS 的机制对比

把两者的差异摊在一张表里，比逐条读文字更容易记住设计边界：

这张表里最容易被低估的是“会话保持”这一行。正因为 USSD 有会话，它才需要对话标识（把多条消息归到同一个对话上）、才需要业务转移（把一条会话从旧应用切到新应用）、才需要区分 PSSR、USSR、USSN 三种发起方向。SMS 没有这些概念，因为它的每一条消息都是自包含的。反过来，SMS 有短信中心这个天然的落盘节点，USSD 没有，所以 USSDC 必须自己把对话状态存进数据库——标准 7.1.4 节列出的对话标识、文本内容、起止时间、状态、交互次数、有效期、发起者地址、目标地址、应用类别、来源、当前消息发送状态、失败原因，这一长串字段全部是在为“没有暂存区”这件事兜底。

3. USSDC 内部结构：信令接口、核心处理与两种 SP 接入

3.1 信令接口单元：USSDC 首先是七号信令网里的一个信令点

标准把 USSDC 的逻辑结构拆成信令接口单元、核心处理单元、数据库服务器、USSD 网关、USSD Portal、网管接口模块和计费话单接口模块。排在第一位的信令接口单元负责七号信令网的信令接入，要同时满足 MAP Phase2+、国内 No.7 信令规范和 SCCP 三套规范。这意味着 USSDC 在网络里的身份不是一个普通的应用服务器，而是一个带信令点编码的 SP——标准 9.2 节明确写了这一点，9.1.2 节又把它的 SSN 定成 0x08，与短消息中心保持一致。

这两个编号细节值得停下来想一想。信令点编码让 USSDC 能被七号信令网路由到，SSN 0x08 则让 MAP 层能把“非结构化补充业务数据”这类消息准确地投递给它。很多初学者会问“为什么 USSDC 不能像 Web 服务器那样只暴露一个 IP”，答案就在这里：它的入口是信令网，不是 IP 网。信令接口单元要做的事情，是把 MAP 消息从 SCCP 连接上解出来，交给核心处理单元；再把核心处理单元产出的响应重新封装成 MAP 消息送回去。这一层如果做不好，上层业务逻辑写得再漂亮也没有用。

3.2 核心处理单元：协议解析、路由分析与转发的中枢

核心处理单元被标准描述为“USSDC 的中央控制单元，进行协议解析、路由分析、业务请求和响应的转发”。这三件事听起来平常，但放到 USSD 的场景里每一件都不轻松。协议解析要把 MAP 消息里的 MSISDN、USSD 串、DCS 编码逐字段拆开；路由分析要根据业务接入码判断这条请求该交给哪个应用、该走网关还是 Portal；转发则要在手机侧会话和 SP 侧会话之间做双向中继，保证两边看到的是同一个对话标识。

这里有一个容易被忽略的约束：标准要求 USSD 中心支持同一个移动用户同时存在多个 USSD 对话连接，无论会话是用户发起还是应用发起。这条要求直接决定了核心处理单元不能用“一个用户一条连接”的简单模型，它必须维护一张以对话标识为主键的会话表，并且允许同一个 MSISDN 下挂多条并行会话。凡是做过会话型系统的人都知道，并行会话加上超时释放，几乎必然引出“会话泄漏”和“串话”两类问题——标准在 7.1.3 节专门写“判别响应时间超出允许范围的对话，并采取相应措施及时释放异常占用的资源”，就是在提醒实现方：会话表不是只增不减的。

3.3 USSD 网关：让 SP 拿到会话控制权的接入模式

标准把 SP 接入分成两条路，第一条是 USSD 网关。通过网关接入的 SP 可以获得对 USSD 对话的完全控制，网关与 SP 之间的接口是 UAP 协议，底层走 TCP/IP。这里的“完全控制”是关键词：SP 自己决定下一句菜单说什么、什么时候结束会话、要不要切到别的业务。网关在这种模式下更像一个透明中继加连接收敛器，它不替 SP 做业务决策。

标准 5.2 节把网关的四个作用写得很清楚：多个 USSDC 需要连同一个 SP 时统一管理、收敛链接；提供不同地区 USSD 系统的互连，实现跨地区业务转移；降低 USSD 应用和 USSD 中心之间的耦合，避免应用故障直接影响中心；网关与应用之间、网关与中心之间都走 TCP/IP。这四条里最值得琢磨的是第三条——解耦。如果让每一个 SP 都直连 USSDC，那么 SP 侧的一次重启或一次流量突刺，就可能把信令侧的资源拖垮；中间加一层网关，等于在信令域和应用域之间加了一道缓冲带。这不是为了多一个网元而多一个网元，而是把“信令网的稳定性”和“应用侧的灵活性”这两个目标拆到两个进程里去实现。

3.4 USSD Portal：预置菜单模式下的另一种取舍

第二条接入路是 USSD Portal。它与网关的差别在于控制权归属：通过 Portal 接入的 SP 必须把菜单预置在 Portal 上，SP 不能在用户浏览过程中控制会话。Portal 自己负责菜单呈现和导航，只在用户访问到特定菜单项时，按照 SP 预先设置的条件向 SP 上报通知消息。Portal 与 SP 之间的接口可以是 CMPP 或 UAP，同时 Portal 还要提供与 DSMP 的接口，用于 SP 鉴权、订购关系生成等管理动作。

把网关和 Portal 放在一起看，其实是一组很典型的设计取舍：网关给 SP 最大自由度，代价是 SP 必须自己实现会话状态机、自己处理超时和异常；Portal 把菜单和导航收归平台，SP 只做“被通知”和“返回内容”，自由度小但接入成本低。标准没有说哪一种更好，它只是把两种模式都定义出来，让运营方按业务复杂度去选。做行业应用、交互流程固定的场景，Portal 模式足够；做需要动态菜单、需要根据用户输入实时改变下一步的业务，网关模式才是正解。

3.5 模块化拆分：为什么网关和 Portal 初期是模块、后期是网元

标准 5.2 节还有一段很务实的描述：考虑到 USSD 短期内业务量不会太大，各地区如有需求，可以把 USSD 网关作为 USSDC 的一个功能模块提供，不作为独立网络节点；Portal 在建设初期也可以作为 USSDC 的一个功能模块。随着业务量扩大、全网有多套 USSDC 时，为保证业务一致性，不同 USSDC 上的 Portal 模块需要做数据同步，这时就可以考虑把 Portal 从 USSDC 里剥离出来，作为独立网元设备。

这段文字的价值不在于它描述了某个具体版本，而在于它展示了一种很典型的演进思路：先按功能模块做，接口边界划清楚但不急着拆进程；等业务量把模块之间的耦合逼到非拆不可的时候，再按已经划好的边界拆出去。标准因此专门要求 USSDC 在设计时进行模块化设计，保证网关和 Portal 模块的独立性——这句话翻译成工程语言就是：今天你可以把它们编译在同一个进程里，但调用关系必须走明确定义的接口，不能靠共享内存或全局变量偷懒。凡是经历过“单体拆微服务”项目的开发者，看到这里应该都会会心一笑：拆得动的前提，是当初就没把边界焊死。

4. 路由与会话：服务号码段如何决定 HPLMN 与 VPLMN 的分流

4.1 70-79、100-149 与 150-199：三个号段背后的路由域

标准 9.1.4 节把服务号码的取值和路由原则绑在一起写：70-79、100-149 用于 HPLMN，当收到拜访用户的这类 USSD 消息时，表示用户请求使用归属网络的 USSD 服务，服务网络应把消息直接转发到 HPLMN；150-199 用于 VPLMN，由拜访网络决定对消息的处理。这三段号码不是随便切的，它们对应的是两种完全不同的组网方式。

HPLMN 号段走的是归属地应用：USSDC 与 HLR 建立连接，HLR 按接入码配置到 USSDC 的路由数据，用户无论漫游到哪里，请求最终都会被送回归属网络的 USSDC 处理。VPLMN 号段走的是拜访地应用：USSDC 与 MSC/VLR 建立连接，拜访地 MSC/VLR 直接把请求路由到本地 USSDC，不绕回归属地。标准在 6.1 节把这两种组网方式分别画了图，并在 4.3.3 节给出业务建议：银行类、金融类业务建议做成全国业务，信息类点播和行业应用建议做成省内业务。

4.2 归属地应用与拜访地应用：为什么全国业务反而建议走拜访地

这里有一个反直觉的点。按常识，“全国业务”听起来应该由归属地统一处理，但标准在 6.1.2 节明确建议：对于全国业务采用拜访地应用的组网方式，由拜访地 MSC/VLR 直接接入 USSDC，避免路由迂回。原因在于信令路径的长度。如果全国业务也走归属地，一个在异地漫游的用户发起的请求要先从拜访地 MSC 送到归属地 HLR，再由 HLR 转到归属地 USSDC，响应还要原路返回；而拜访地接入让请求在本地 MSC 就分流到本地 USSDC，信令跳数少得多。

省级业务则相反，标准建议采用归属地应用：用户可以在任何支持 USSD 功能的交换机下使用归属地业务，不需要拜访地做特殊数据配置。这背后的权衡是配置成本与路由成本之间的取舍——省级业务量相对小、覆盖范围有限，让每个拜访地都为它配路由不划算，宁可多绕一点路，换取“拜访地零配置”。

4.3 网络侧发起的两条路：HLR 转发与取路由直连 MSC

用户发起的会话（PSSR）路由相对直观，网络侧发起（USSR、USSN）的路由则有一个明显的设计分叉。标准 6.2 节给了两种方式：一种是通过 HLR 转发，USSDC 把业务请求发给 HLR，HLR 转发到用户拜访的 MSC/VLR，整个交互过程中每一次交互都要 HLR 中转；另一种是从 HLR 查询路由后直接下发，USSDC 发起下行业务前先到用户归属 HLR 查路由信息，再根据路由直接把请求送到拜访 MSC/VLR。

第一种是 ETSI 规定的标准方式，第二种是非 ETSI 规范定义的方式，借用了短消息下发时的思路。标准在 8.2.2 节给出了明确建议：Push 类应用建议采用第二种方式，把 USSD 会话对 HLR 的影响减至最少。这个建议背后的动机不难理解——HLR 是移动网里负载最敏感的几个网元之一，如果每一次下行的 USSD 交互都要它中转，业务量一上来 HLR 就先撑不住；而“查一次路由、后续直连 MSC”把 HLR 从“中继节点”降级成“路由查询节点”，负载模型完全不同。

注意：取路由直连 MSC 虽然对 HLR 友好，但它依赖 HLR 返回的位置信息足够新。如果用户在这期间发生了位置更新，直连过去的会话可能落空，实现时需要把这种情况和超时释放逻辑一起考虑。

4.4 过渡期混合组网：当交换机不支持目标方案时怎么落地

标准附录 A 处理的是一个很现实的问题：目标网方案要求 MSC/VLR 能分析业务接入码、区分拜访地应用和归属地应用，但现网交换机并不能都支持。附录里直接点名了支持情况——拜访地应用的路由方式只有部分厂家设备支持，能提供 6.3.0 以上 MAP 接口的又是另一批厂家。在设备能力参差不齐的情况下，全国业务怎么开？

附录给出的答案是过渡期混合组网：不支持拜访地接入的地区，可以让 MSC/VLR 把所有 USSD 请求都转发给用户归属 HLR，由 HLR 再分析接入码转发到相应 USSDC；支持拜访地接入的地区，则在该地区单独采用拜访地方式。附录用四个 Case 把路由讲得很细：A 地用户未漫游、B 地用户漫游到 A 地、A 地用户漫游到 B 地、B 地用户未漫游，四条路径分别对应“本地 MSC 直送”“拜访 MSC 直送”“拜访 MSC 送回归属 HLR”“本地 MSC 送本地 HLR”。业务响应一律按请求的逆行方向返回。

这段过渡方案的价值在于它承认了一个事实：规范目标和现网能力之间永远有落差，与其等设备全部升级完再开业务，不如先定义一套兼容路径把业务跑起来，再逐步收敛到目标方案。做系统设计的人应该对这种“目标态 + 过渡态”双轨定义不陌生——它不是妥协，而是把演进路径也当成设计的一部分写进标准。

4.5 会话生命周期：30 秒、180 秒、60 秒、10 分钟这组数字怎么来的

标准 7.1.3 节给出了一组很具体的超时参数：一次 USSD 交互建议移动用户侧 30 秒、应用服务侧 30 秒；移动用户侧响应时间最大值 180 秒，应用服务侧最大值 60 秒；一次 USSD 对话的有效时间不超过 10 分钟。这组数字不是拍脑袋来的，它们对应的是会话生命周期里三个不同的阶段。

第一层是单次交互的等待窗口：用户敲完输入，30 秒内没提交，USSDC 就认为这一步失败；SP 收到请求后 30 秒内没返回，同样按失败处理。第二层是单侧响应的硬上限：用户侧给到 180 秒，是因为要留出输入长内容、看清菜单再操作的余量；应用侧只给 60 秒，是因为 SP 是机器，机器不该让用户等超过一分钟。第三层是整条会话的总寿命：10 分钟一到，无论当前进行到哪一步，USSDC 都应释放连接。

这三层结构其实是在回答一个问题：一条没有暂存区的会话，资源该按什么粒度回收？按单次交互回收太激进，用户切个应用回来会话就没了；按整条会话回收又太粗，一个卡住的步骤会占着资源直到 10 分钟上限。分三层设置，等于给“正常慢”和“异常挂起”划了不同的处理线。标准还补了一句“USSD 中心应能针对具体业务进行用户侧和应用侧超时的配置”，这说明 30/180/60/10 分钟只是建议值，真正上线时要按业务类型调——银行转账和天气查询对“用户输入慢”的容忍度显然不一样。

5. 常见问题与排查：从接入码解析到超时释放的踩坑记录

5.1 接入码明明合法却提示“无法识别”

现象：用户在终端上输入13911# 或 #1790921#，终端能呼出，但 USSDC 返回业务不存在或直接挂断。原因通常不在号码本身，而在业务接入码的格式匹配。标准 4.2 节给了两种格式：格式一是以 * 或 # 组合成的 1-3 位前缀开头，后接三位 100-199 的服务号码，再接可选的 * 分隔参数，以 # 结束；格式二是 70-79，后面不再跟任何字符。很多实现方把格式一的“前缀 1-3 位”理解成固定 3 位，遇到 *100# 这种一位前缀加三位服务号的组合就解析失败。解决方式是按标准把前缀长度做成 1-3 位的可变匹配，并且在解析前先区分这条请求到底落在格式一还是格式二。

5.2 中文 USSD 在中间网元被丢弃

现象：英文 USSD 一路通畅，换成中文菜单后用户收不到回复，或者回复变成乱码。原因出在 DCS 字段。标准 7.1.9 节专门写了这一条：MSC/VLR、HLR、USSDC 应支持 DCS 为非 0x0F 编码的 USSD 消息传输，包括终端到 SP、SP 到终端两个方向，网络设备可设置忽略检查 DCS 字段以便透明传输。汉字 USSD 按 GSM 03.38 使用 UCS2(16bit)-GB13000 编码，DCS 不再是默认值，某些网元如果按老逻辑做严格校验就会把消息拦下。排查时先抓 MAP 消息看 DCS 字段值，再确认沿途网元是否开了忽略检查，两步基本能定位。

5.3 长消息拆分后对端拼不回来

现象：一条超过 229 个汉字的 USSD 消息，终端显示被截断，或者 SP 侧收到的内容缺一段。标准 7.1.10 节要求终端和 SP 应用服务器支持长 USSD 信息的拆分和组合，终端至少支持 229 个汉字，可选支持 389 个汉字。问题往往出在拆分边界和重组顺序上：拆分方按字节切，重组方按字符切，遇到 UCS2 双字节字符就会在边界处切坏一个字符；或者拆分时没带序号，重组方按到达顺序拼，网络侧乱序就拼错。解决方式是在拆分协议里同时带“总片数 + 当前片序号”，并且按字符边界而不是字节边界切分。

5.4 业务转移之后旧会话悬挂

现象：用户从银行业务菜单跳转到另一个业务接入码，新业务能正常响应，但 USSDC 的会话表里旧对话一直不释放，跑一段时间后资源告警。标准 7.1.7 节定义的业务转移，是把当前 USSD 对话中 USSDC 到 USSD 业务应用之间的呼叫分支切断，并转移到新接入码指定的应用上，此后对话继续。注意“切断的是 USSDC 到应用这一段”，不是整条会话。如果实现方在转移时只建了新分支、没断旧分支，旧应用侧的连接就会挂着。排查时看转移前后 USSDC 到 SP 的连接数是否一增一减配平，不配平就说明旧分支没断干净。

5.5 超时配置按默认值上线，长流程业务频繁中断

现象：一个需要用户输入账号、密码、验证码三段内容的教育类 USSD 流程，用户操作稍慢就被中断，投诉集中在“输到一半就没了”。原因是直接沿用了标准建议的 30 秒用户侧超时，而这个建议值针对的是单步短交互。标准明确说“USSD 中心应能针对具体业务进行用户侧和应用侧超时的配置”，说明它本来就预期实现方按业务调。解决方式是把用户侧单步超时按步骤类型分级配置，输入类步骤给更长窗口，菜单选择类步骤维持短窗口，同时确保任何一步的超时都不会突破 10 分钟的会话总上限。

6. 从 UCS2 到端到端加密：USSD 设计里的几个取舍

6.1 为什么汉字编码选 UCS2-GB13000 而不是直接传 GB 码

标准 7.1.5 节规定汉字 USSD 编码方案应符合 GSM 03.38，即支持 UCS2(16bit)-GB13000，人工输入汉字的终端应支持 GB13000 CJK 部分。这个选择看起来绕了一圈——先 UCS2 再映射到 GB13000，为什么不直接传 GB 码？原因在于 GSM 03.38 是信令层的通用字符集规范，它定义的是 7bit 默认字母表加 UCS2 扩展这条路径，网元只要按 03.38 解析就能拿到统一的 16bit 码点；至于这个码点对应 GB13000 里的哪个汉字，是终端和 SP 之间的事。把“传输编码”和“字符集映射”分开，网元就不需要理解中文，只需要理解 UCS2。这是一个很典型的“把复杂度推到端点”的取舍：中间网元越笨，越稳定。

6.2 消息级计费与对话级计费为什么同时存在

标准第 11 章允许的计费方式很宽：按月租收基本费、按对话持续时长、按对话次数、按信息内容、按字节流量都可以。同时 7.1.6 节又要求为每一条消息产生话单，并在消息级话单里增加一个字段指示该消息是否计费。这两层并不矛盾——对话级计费记录回答“这次会话总共该收多少”，消息级计费记录回答“这条消息收不收、收多少”。业务开展初期业务量不大时，标准甚至建议把所有点播消息通过短信下发、借短信实现间接计费，USSD 只做导航，从而避免对计费中心做改动。这个建议的动机很务实：计费系统的改动成本远高于业务侧，能在业务侧绕开就先绕开。

6.3 端到端加密为什么落在 SIM 卡上

标准第 13 章讨论安全时，把 USSDC 到银行应用服务器之间的保护和端到端保护分成了两个层次。前者可以用专线直联或 IPSec；后者如果要做端到端的 USSD 串加密，必须在终端侧实现加解密算法，标准给出的落点是“可以通过 SIM 卡实现”。这个落点不是随便选的——USSD 的明文串要经过终端、基站、MSC/VLR、HLR、USSDC 好几跳，任何一个中间节点都可能看到内容，而 SIM 卡是整条链路上唯一一个既属于用户、又具备安全计算能力、还不受网络侧控制的执行环境。把密钥和算法放在卡里，等于把信任锚点从网络侧挪到了用户侧。代价是业务方要适配不同卡商的 API，这正是“安全强度”和“接入成本”之间那道绕不过去的取舍。

写到这里，我对这类信令型规范最大的教训是：不要用“应用层协议”的直觉去读它。应用层协议出问题可以重试、可以落盘、可以补偿；USSD 这条链路上没有暂存区，超时就是超时，断就是断。从那以后我每次评估一个 USSD 流程，都会先把“这条会话在哪一步可能挂起、挂起后谁来释放”在纸上走一遍，再去看代码——这个习惯帮我省掉了不少上线后的资源告警。希望帮到你。

本文还有配套的精品资源，点击获取