简介：这份资源是中国移动通信企业标准中USSD应用接口协议相关的技术文档，面向通信网络工程师、移动业务开发人员及电信标准研究者，用于解决USSD业务在系统结构、组网方式、接口协议与计费安全等方面的规范依据问题。压缩包内共1个doc文件，约781KB，内容涵盖USSD业务总体技术要求、应用接口协议、业务流程、编号方式、应用系统接口、计费与信息安全，以及API、HLR、HPLMN、MAP、MML、MS、MSC、MSISDN等实现要点，并列出QB-D-069-2009、QB-D-070-2009、QB-E-031-2009、QB-E-032-2009等标准编号。目前已有576人学习下载，适合需要查阅行业规范、梳理接口流程或进行设备选型与工程设计的读者参考，可帮助快速定位USSD系列标准的关键条款与技术要求。

1. 从一条*100#说起：这份 2009 年的 USSD 规范为什么现在还有人翻

你在维护一套老短彩信网关或者行业短信平台时，大概率遇到过这种需求：用户不装 App、不发短信，直接在拨号盘敲一串*100#就能查余额、订票、查积分。这就是 USSD，非结构化补充业务数据。它跟短信最大的区别是面向连接、不存储转发，通话态下走 FACCH，速率能到 1000 bits/s 左右，非通话态走 SDCCH 约 600 bits/s，响应比短信快得多。

手头这份《中国移动通信USSD应用接口协议》属于 QB-D-069-2009 系列，2009 年发布实施，是当年各省公司开展 USSD 业务的技术依据。它把系统结构、组网路由、业务流程、编号方式、计费和信息安全都写死了。今天翻它的人，多半不是要从零建网，而是接手了存量系统，需要搞清楚接入码怎么规划、MAP 消息怎么带 MSISDN、超时该配多少。这篇笔记就按「这是什么 → 怎么落地 → 坑在哪」的顺序，把这份规范拆成能照着复现的步骤。

2. 系统结构与组网路由：USSDC、HLR、MSC 三者怎么连

2.1 USSD 中心内部到底分了几个模块

规范第 5 章把 USSDC 逻辑上拆成信令接口单元、核心处理单元、数据库服务器、USSD 网关、USSD Portal、网管接口模块、计费和话单接口模块。这不是为了画图好看，而是决定了你扩容时该动哪块。

信令接口单元负责 7 号信令接入，要支持 MAP Phase2+、NO.7 信令、SCCP 这几套规范。核心处理单元做协议解析、路由分析、请求响应转发。USSD 网关是给 SP 接入用的，SP 通过它拿到对 USSD 对话的完全控制权，接口走 UAP 协议。USSD Portal 则是另一种接入方式，SP 把菜单预置在 Portal 上，用户浏览过程中 SP 控制不了会话，但 Portal 可以在用户访问到特定菜单项时向 SP 上报通知，接口走 CMPP 或 UAP。

这里有个选型判断：如果你的业务方需要实时控制每一步交互（比如银行转账要逐步确认），走 USSD 网关；如果只是固定菜单导航（比如查天气、查话费），走 USSD Portal 更省事。规范里明确说了，建设初期网关和 Portal 都可以作为 USSDC 的功能模块提供，业务量大了再剥离成独立网元。我一般建议初期就按模块化设计，别把网关逻辑硬编码进核心处理单元，否则后期拆分要动大手术。

2.2 归属地应用和拜访地应用的路由差异

这是整份规范里最容易翻车的地方。服务号码的号段直接决定了路由走向：

归属地应用的流程是：MS → MSC/VLR → HLR → USSDC。MSC/VLR 分析接入码后判断是归属地业务，就把请求路由到用户归属的 HLR，HLR 再前转给 USSDC。拜访地应用则是 MSC/VLR 直接路由到对应的 USSDC，不经过 HLR，避免路由迂回。

规范建议全国业务采用拜访地接入方式，因为银行类业务对响应时间敏感，绕 HLR 会增加延迟。但附录 A 里也承认，2009 年现网交换机并不是都支持 MSC/VLR 到 USSDC 的接口，只有部分厂家设备可以。所以过渡期方案是：不支持拜访地接入的地区，全国业务也走归属地方式，形成混合组网。

2.3 网络侧发起业务的两种路由实现

SP 主动推送给用户（PUSH 类业务）有两条路。第一条是 ETSI 标准方式：USSDC 把请求发给 HLR，HLR 转发到用户拜访的 MSC/VLR，整个交互过程每次都要 HLR 中转。第二条是非标准方式：USSDC 先到 HLR 查路由信息，拿到 MS 当前位置后，直接跟拜访 MSC 建立会话，HLR 只参与路由查询，不参与后续交互。

规范明确建议 PUSH 类应用采用第二种方式，理由很直接：业务量大的时候，第一种方式会把 HLR 负荷打满。HLR 是共享网元，你一个 USSD 业务把 HLR 拖垮，影响的是一大片。这个选择在当年是血泪经验，现在做存量系统维护同样适用——只要 HLR 支持路由查询接口，就别让它中转消息。

2.4 一次完整的余额查询流程拆解

以规范第 8 章的银行余额查询为例，上下行都用 USSD 方式，整个交互在一个会话里完成：

# 用户拨号 *100*1# # 服务号码100，附加参数1表示查询余额 # 网络侧交互序列（简化） PSSR: #101*1# # MS发起USSD请求 USSR: 请输入帐号: # USSDC向SP转发，SP返回提示 USSR_RSP: 40001100672812349914 # 用户输入帐号 USSR: 请输入密码: # SP请求密码 USSR_RSP: 361327 # 用户输入密码 PSSR_RSP: 剩余 9533.2 元 # SP返回结果，USSDC回传给MS

这里的关键参数是超时配置。规范 7.1.3 写得很具体：移动用户侧建议 30 秒，应用服务侧建议 30 秒；用户侧响应时间最大 180 秒，应用侧最大 60 秒；一次 USSD 对话有效时间不超过 10 分钟。超时后 USSDC 必须释放对话连接。

我见过有人把用户侧超时设成 300 秒，觉得「给用户多点时间输入」。结果就是异常占用的资源释放不掉，并发一上来 USSDC 直接雪崩。规范给的 180 秒是上限，不是建议值，实际配置建议贴着 30 秒走，特殊业务再单独调。

2.5 业务接入码的编码规则与规划建议

接入码格式一：*AAA*BBB#或#AAA*BBB#，AAA 是三位服务号码（100~199），BBB 是附加参数。格式二：70~79，后面不跟任何字符。

规范给了三种编码原则：AAA 代表业务分类、BBB 代表 SP；AAA 代表 SP、BBB 代表业务分类；AAA 代表 USSD 中心、BBB 代表业务分类。建议采用第一种，因为用户记忆成本最低——*100#是银行、*101#是查询，分类在前更符合直觉。

前缀可以是*、#、**、*#、#**、##*等形式，一到三位。规范建议个人用户应用只用*或#开头，两位三位前缀留给工业控制、行业用户这些不需要记忆的场景。另外可以设 1~2 个综合接入号做门户导航，比如#101#作为中文 USSD 综合接入号，利用业务转移功能把请求导航到具体 SP。

业务转移这个功能值得单独说：它能把当前 USSD 对话从 USSDC 到 SP 的呼叫分支切断，转移到新的业务接入码指定的 SP 上，对话继续。只有业务方可以发起转移命令。做门户导航就靠这个，用户从综合菜单选了一项，后台直接把会话转给对应 SP，用户感知不到切换。

3. 接口信令与 MAP 消息：MSISDN 怎么带、DCS 怎么设

3.1 MAP 消息里必须带 MSISDN

规范 10.1 明确要求：USSD 业务在 MAP 协议中要求在 USSD 会话请求中传递该用户的 MSISDN。涉及的消息主要是MAP_PROCESS_UNSTRUCTURED_SS_REQUEST、MAP_UNSTRUCTURED_SS_REQUEST、MAP_UNSTRUCTURED_SS_NOTIFY。

处理依据是 GSM 09.02 v6.3.0（R97）以上版本，这个版本在 PSSR 参数中引入了 MSISDN。为什么强调这个？因为早期版本的 MAP 消息里没有 MSISDN，USSDC 收到请求后不知道是谁发的，只能靠其他字段反查，效率低还容易出错。要求带 MSISDN 之后，USSDC 可以直接根据主叫号码做鉴权、路由、计费。

附录 A 里特别提到，现网能按要求提供 6.3.0 以上 MAP 协议接口的厂家设备是有限的。如果你现在维护的系统对接的是老交换机，先确认它支持的 MAP 版本，别想当然认为 MSISDN 一定带得上。带不上的话，要么升级交换机软件，要么在 USSDC 侧做号码补全逻辑。

3.2 中文 USSD 的 DCS 编码与长消息拆分

汉字 USSD 编码方案要符合 GSM 03.38（v5.6.1），即支持 UCS2(16bit)-GB13000。终端要支持 GB13000 CJK 部分的汉字。

规范 7.1.9 有一条容易被忽略的要求：MSC/VLR、HLR、USSDC 应该支持 DCS 为非 0x0F 编码的 USSD 消息传输，包括终端到 SP、SP 到终端两个方向。网络设备可以设置忽略检查 DCS 字段，以便透明传输。

0x0F 是什么？是 GSM 7bit 默认编码。非 0x0F 意味着可能是 UCS2 或其他编码。如果网络设备严格检查 DCS 字段，遇到非 0x0F 的消息可能直接丢弃或转码，中文就乱了。所以规范允许网络设备忽略 DCS 检查，做透明管道。

长消息方面，终端和 SP 要支持拆分和组合。终端至少支持 229 个汉字的 USSD 消息，可选支持至少 389 个汉字。这是 2.0.0 版本新增的要求，1.0.0 版本没有。如果你对接的终端是 2008 年之前入网的，可能不支持长消息，发超长内容会被截断。

3.3 对话标识与面向连接的接口设计

USSD 是面向连接的应用，USSDC 与 SP 之间的协议必须是面向连接的。USSDC 要在消息中说明 USSD 对话标识，标识该消息属于哪一个对话连接。

这意味着 SP 侧不能按无状态 HTTP 接口来设计。每个对话要有独立的会话 ID，消息要能关联到具体对话。规范 7.1.4 列出了对话信息必须存储的内容：对话标识、消息文本内容和长度、发起和结束时间、状态信息、交互次数、有效期、发起者地址和目标地址、应用类别、信息来源、当前消息发送状态、失败原因。

这套存储要求决定了 USSDC 的数据库设计。对话标识是主键，状态机要能跟踪每个对话的生命周期。我见过有人用内存缓存存对话状态，重启就丢，用户正在输入的密码直接没了。规范要求存储，就得落库，别偷懒。

3.4 用户鉴权和业务接入码鉴权

USSD 用户鉴权有两种必选方式：不鉴权和按号段鉴权。鉴权方式可根据运营需要设置。不鉴权就是谁都能用，按号段就是只允许特定号段的用户接入。

业务接入码鉴权是另一回事：USSDC 要核查应用服务侧发起的 USSD 业务是否合法，保留业务接入码和应用服务的对应关系，判断 SP 是否可以向移动用户发起该接入码对应的业务。这是防止 SP 越权推送，比如一个天气 SP 不能发银行接入码的业务。

如果独立建设 USSD 网关，业务转移和业务接入码鉴权这两项功能作为对网关的要求。也就是说，网关不只是透传，还要做权限校验。

4. 计费、安全与统计：话单字段和加密边界

4.1 消息级计费与对话级计费的区别

规范 7.1.6 要求为每一条消息产生话单，并在消息级别的话单中增加一个字段，指示该消息是否计费。11.1 又说了，USSDC 产生的话单分为对话计费记录和消息计费记录两种。

这意味着计费系统要能处理两种粒度。对话计费记录关注整个会话的时长、次数；消息计费记录关注单条消息的内容、方向、是否计费。运营者可以按月租收基本费、按对话持续时长计费、按对话次数计费、按信息内容计费或按字节流量计费。

业务开展初期，规范给了一个取巧方案：所有点播消息通过短信下发，用短信来间接计费，USSD 只做业务导航。这样不用改计费中心软件，能快速上线。这个思路现在做新业务冷启动同样适用——先复用成熟计费通道，别一上来就动核心计费系统。

4.2 计费接口与数据存储

计费接口可以通过 X.25、RS232 或其他接口与计费中心相连，也可以采用磁带脱机处理。计费信息应可采用 FTP、FTAM 规程传送。USSDC 要提供有效的计费记录保存手段，文件方式或数据库方式都行。

X.25 和 RS232 现在看很古老，但存量系统里还在跑。如果你要对接老计费中心，先确认它支持哪种接口。FTP 传送话单文件是最常见的，注意文件格式和命名规则要跟计费中心对齐，别自己发明。

4.3 银行类业务的加密边界

规范第 13 章专门讲安全。银行类业务对安全性要求很高，帐号、密码泄漏会给客户造成巨大损失。USSDC 到银行应用服务器之间的安全性问题，可以采用专线直联、IPSec 加密等机制。

如果需要端到端加密，必须在终端侧实现加密/解密算法，可以通过 SIM 卡实现。加密算法的实现和密钥管理、更新，可以参考基于短消息承载的手机银行业务的处理方式。

这里有个边界要清楚：规范只要求 USSDC 到银行服务器之间加密，端到端加密是可选增强。实际做银行类业务，专线直联是底线，IPSec 是标配，SIM 卡端到端加密看业务方需求。别把三层混在一起谈，成本差很多。

4.4 统计与网管接口

规范第 12 章把统计与网络管理的要求指向了《非结构化补充业务数据中心（USSDC）设备规范》。网管接口模块要提供和统一网管系统的接口。这意味着 USSDC 要能上报性能统计、告警、配置数据。

实际运维中，最常看的是对话并发数、消息成功率、超时释放数、各 SP 的流量分布。这些指标能直接反映系统健康度。如果网管接口没对接好，出问题只能登服务器看日志，效率很低。

5. 避坑与排查：超时、编码、路由、鉴权的五个翻车现场

5.1 用户侧超时设太大导致资源耗尽

现象：业务高峰期 USSDC 对话并发数飙升，新请求接入失败，日志显示大量对话处于等待用户输入状态。

原因：用户侧超时配置过大，比如设了 180 秒甚至更长。用户拨了*100#之后不输入，对话一直挂着，占用信令资源和内存。规范建议用户侧 30 秒，最大 180 秒，但很多人直接取最大值。

解决：把用户侧超时改回 30 秒，特殊业务单独配置。同时检查 USSDC 是否有对话跟踪管理机制，能否判别响应时间超出允许范围的对话并及时释放。规范 7.1.3 要求 USSDC 具备这个能力，但配置不对等于没有。

5.2 中文乱码：DCS 字段被网络设备改写

现象：用户输入中文，SP 收到的是乱码，或者用户收到 SP 返回的中文是乱码。

原因：网络设备（MSC/VLR、HLR）严格检查 DCS 字段，遇到非 0x0F 编码的消息做了转码或丢弃。规范 7.1.9 允许网络设备忽略检查 DCS 字段做透明传输，但设备默认配置可能是严格检查。

解决：联系网络侧确认 MSC/VLR、HLR 的 DCS 检查配置，设置为忽略检查或透明传输。同时确认终端和 SP 都支持 UCS2(16bit)-GB13000 编码。如果终端不支持，只能降级用 GSM 7bit，中文就发不了。

5.3 全国业务走归属地路由导致 HLR 过载

现象：全国 USSD 业务上线后，HLR 负荷告警，其他依赖 HLR 的业务受影响。

原因：全国业务采用了归属地接入方式，所有请求都绕 HLR 中转。规范建议全国业务用拜访地接入，但过渡期因为交换机不支持，很多地区走了归属地方式。

解决：确认 MSC/VLR 是否支持到 USSDC 的直接接口。支持的话，把全国业务接入码 150~199 的路由改为拜访地接入。不支持的话，至少把 PUSH 类业务改为「从 HLR 查路由后直接下发」方式，减少 HLR 中转次数。附录 A 的混合组网方案可以参考，A 地支持拜访地接入就走拜访地，B 地不支持就走归属地。

5.4 业务接入码鉴权缺失导致 SP 越权

现象：某个 SP 向用户推送了不属于它业务范围的 USSD 消息，用户投诉。

原因：USSDC 或 USSD 网关没有做业务接入码鉴权，或者鉴权表配置错误。规范 7.1.8 要求 USSDC 保留业务接入码和应用服务的对应关系，判断 SP 是否可以向移动用户发起该接入码对应的业务。

解决：检查业务接入码鉴权表，确认每个 SP 代码只能发起其授权接入码的业务。如果独立建设了 USSD 网关，鉴权功能在网关上做。定期审计 SP 的接入码权限，别让一个 SP 拿到万能接入码。

5.5 长消息拆分后顺序错乱或丢失

现象：用户收到长 USSD 消息，内容顺序乱了，或者只收到前半段。

原因：终端或 SP 不支持长消息拆分组合，或者拆分后没有按序发送。规范 7.1.10 要求终端和 SP 支持长 USSD 信息的拆分和组合，终端至少支持 229 个汉字。

解决：确认终端型号是否支持长消息。不支持的话，SP 侧限制消息长度，超过就截断或改用短信下发。支持的话，检查拆分逻辑是否按序编号，接收侧是否按序重组。长消息的拆分和重组要在应用层做，别指望网络层帮你排序。

6. 从规范到落地：接入码规划表和超时配置的实操建议

6.1 接入码规划表怎么填

把规范第 9 章的编码原则落成一张可执行的规划表，我一般按这个结构来：

填表时注意三点：服务号码 100~149 走归属地，150~199 走拜访地；综合接入号用#101#或#111#，利用业务转移做导航；前缀尽量用*或#开头，方便用户记忆。

6.2 超时参数配置清单

规范 7.1.3 给的超时参数，落地时按这个清单配：

# USSDC 超时配置（建议值） user_side_timeout=30s # 移动用户侧超时，建议30秒 app_side_timeout=30s # 应用服务侧超时，建议30秒 user_side_max=180s # 用户侧响应时间最大值，硬上限 app_side_max=60s # 应用侧响应时间最大值，硬上限 dialog_max_duration=600s # 对话有效时间，不超过10分钟

配置逻辑：建议值贴着 30 秒走，最大值是保护上限，不是目标值。对话有效时间 10 分钟是硬限制，超时必须释放。特殊业务需要更长超时，单独配置，但不要超过规范给的最大值。

6.3 验证方法：用 MAP 消息抓包确认 MSISDN 和 DCS

上线前用信令抓包工具确认两件事：PSSR 消息里是否带了 MSISDN，DCS 字段是否被透明传输。

# 抓包过滤条件（示例） # 过滤 MAP_PROCESS_UNSTRUCTURED_SS_REQUEST 消息 # 检查 PSSR 参数中是否包含 MSISDN 字段 # 检查 DCS 字段值是否为 0x0F 或其他编码

如果 MSISDN 没带，检查交换机 MAP 版本是否达到 6.3.0。如果 DCS 被改写，检查网络设备的 DCS 检查配置。这两项确认通过，基本业务流程就不会出大问题。

6.4 一个具体技巧：用综合接入号做业务灰度

规范建议设 1~2 个综合接入号做门户导航。实际落地时，可以把综合接入号当成灰度入口：新业务先挂到综合菜单下，观察一段时间，稳定了再申请独立接入码。

这样做的好处是：新业务不用一开始就占用稀缺的 100~199 服务号码资源；出问题影响面小，用户从综合菜单进去发现不对，退出就行；收集到足够流量数据后，再决定是否给独立接入码。

我当年接手一个存量 USSD 平台时，发现接入码规划一团乱，100~199 号段被各种临时业务占满，很多业务上线三个月就没人用了，号码却收不回来。从那以后我每次做接入码规划，都强制走一遍「综合接入号灰度 → 独立接入码申请 → 定期回收」的流程。号码资源是有限的，别当免费资源随便发。

希望帮到你。

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