企业官网建设流程全解析

简介：中国移动通信USSD应用接口协议是中国移动企业标准体系中的核心规范，主要面向移动网络规划、USSD业务开发及设备维护人员，系统规定了非结构化补充业务数据（USSD）的组网方式、业务流程、编号方式、应用系统接口、计费与信息安全等技术要求，是开展相关业务和设备选型的重要依据。资源包为1个doc文档，大小781KB，内容涵盖QB-D-069-2009、QB-D-070-2009等系列标准编号，并深入展开USSD业务总体技术要求、应用接口协议、终端技术规范、测试规范以及API、HLR、HPLMN、MAP、MS、MSC、MSISDN等关键实现要素。已有576人浏览学习，适合需要了解中国移动USSD标准体系、进行业务集成、设备选型或网络优化的技术人员参考。文档从业务概述到具体协议实现均有清晰说明，可帮助读者快速建立对USSD系列标准的整体认知，理解USSD与SMS在信令通道、传输速率及交互能力上的差异，并作为工程设计与网络运维的实用参考资料。

1. USSD不是短消息的备胎：一份老标准为什么还有人在翻

在即时通讯和 5G 消息满天飞的今天，USSD 仍然是一条绕不开的信令管道——你手机里不少银行、充值和行业应用的快捷入口，走的还是这套 30 年前就定下来的交互协议。这份 QB-D-069-2009《USSD 业务总体技术要求》是中国移动 2009 年发布的企业标准，版本 2.0.0，它定义了 USSD 从系统结构、组网方式到业务流程、编号、计费和信息安全的完整技术基线。虽然发布时间早，但今天做 USSDC 选型、SP 接入联调、MAP 信令排查的人，依然要拿它当最权威的依据。它适合三类人：接入 USSD 业务的 SP 开发、做核心网信令与网络规划的工程师、以及负责 USSD 设备测试验收的从业者。看完你会知道，USSD 和 SMS 的本质差别不在速率，而在“面向连接”这个根子上。

2. 系统结构：USSDC 六个模块、MSC/VLR 与 HLR 的分工边界

2.1 USSDC 不是一台机器，而是六个逻辑模块的集合

USSDC 在逻辑上被拆成信令接口单元、核心处理单元、数据库服务器、USSD 网关功能模块、USSD Portal 功能模块、网管接口模块以及计费和话单接口模块。信令接口单元负责七号信令网接入，要支持 MAP Phase2+、国内 No.7 信令方式和 SCCP；核心处理单元做协议解析、路由分析、业务请求和响应转发。

数据库服务器存的是应用管理数据，包括帐户标识（SP 代码）、应用类型、业务接入码组、服务器地址。换句话说，USSDC 是一台“翻译机+路由器”：把手机的 * 号串翻译成 SP 能懂的请求，再把 SP 的应答翻译回手机的屏幕。

值得注意的是，规范明确要求 USSDC 采用模块化设计，尤其是网关和 Portal 模块要保持独立性。原因是业务量小时它们可以内嵌在 USSDC 里，业务量大后要能独立拆出来单独建设。这个“先合后分”的思路，直接影响你选购设备时的架构判断。

2.2 MSC/VLR 和 HLR：一个管判定，一个管转发

MSC/VLR 在 USSD 业务里只做三件事：检查 MS 发出的 USSD 请求是否合法；分析业务接入码，决定请求该由 HPLMN 还是 VPLMN 处理；按判定结果把请求路由到 HLR 或直接到 USSDC。这个“判定”动作很关键——它是组网方案里归属地应用和拜访地应用的分水岭，后面第 3 章会展开。

HLR 的职责更简单：归属地应用场景下，把 MSC/VLR 转来的 USSD 请求前转给 USSDC；当 USSDC 主动发起下行请求时，HLR 负责提供当前 MS 的位置信息。注意 HLR 在 USSD 链路里是一个“中转站”角色，这是后面 PUSH 业务里 HLR 负荷问题的根源。

2.3 网关和 Portal：看着都是接 SP，控制权完全不同

USSD 网关和 USSD Portal 都给 SP 提供接入，但本质区别在会话控制权。通过网关接入的 SP，能获得对 USSD 对话的完全控制——交互过程里每一步都能参与，适合银行、支付这类需要实时双向交互的业务。而通过 Portal 接入的 SP，必须先把菜单预置在 Portal 上，用户浏览时 SP 不能控制会话，只能在用户访问到特定菜单项时接收上报通知。

接口协议也不同：网关和 SP 之间走 UAP 协议；Portal 和 SP 之间可走 CMPP 或 UAP。这意味着你选哪条路接入，直接决定 SP 侧的协议栈开发量。业务量增长后，如果全网有多套 USSDC，各 USSDC 上的 Portal 模块数据必须同步，这时规范建议把 Portal 单独剥离成网元，减少维护难度。

提示：做设备选型时优先确认厂家是否按模块化设计。如果网关和 Portal 模块耦合过深，后期拆分会非常痛苦。

3. 组网与路由：归属地、拜访地、混合组网怎么选

3.1 一个号码段决定一条路由：70~79、100~149 与 150~199 的分工

用户侧发起的 USSD 请求，路由原则按服务号码段划分：70~79 和 100~149 是归属地应用号码段，交换设备收到这类请求时，代表用户要使用归属网络的 USSD 服务，请求会被转给 HPLMN；150~199 是拜访地应用号码段，由拜访网络决定如何处理。

举个例子：用户漫游在外，拨了归属地应用号码（比如 #101# 这种全国银行类综合接入号），MSC/VLR 会把请求转回用户归属的 HLR，再由 HLR 前转给归属地 USSDC；如果拨的是拜访地应用号码，则直接由拜访地 MSC/VLR 路由到对应 USSDC，不需要绕回 HLR。

规范给出的业务分类建议是：全国业务（如银行、金融类）采用拜访地应用组网方式，直接由拜访地 MSC 接入 USSDC，避免路由迂回；省内业务（信息点播、行业应用）用归属地应用组网方式，用户在任何支持 USSD 的交换机下都能用，不需要拜访地做特殊数据配置。这套建议要跟厂家支持能力配套看，不然会踩大坑。

3.2 过渡期混合组网：并不是所有交换机都支持拜访地接入

规范附录 A 明确写了一个现实约束：目前只有 NOKIA 和华为的交换设备支持拜访地应用路由方式；MAP 协议能提供 6.3.0 以上版本的厂家是 Siemens、Alcatel、华为、中兴。也就是说，按目标网做规划，你的 MSC/VLR 可能不达标。

过渡期的做法是归属地接入为主、拜访地接入为辅的混合组网。规范用四个 Case 说清楚了路由规则：

业务响应路由是请求路径的逆行方向。我一般会建议先摸清现网交换机厂家型号，再决定哪些地区能走拜访地接入，哪些必须走 HLR 转接，别拿着目标网方案硬套现网。

3.3 PUSH 下行两条路：一条是标准但费 HLR，一条是绕行但高效

网络侧发起 USSD 业务（PUSH 类）有两种技术实现。第一种是 ETSI 标准方式：USSDC 把请求发给 HLR，HLR 转发到用户拜访的 MSC/VLR，整个交互过程每次都要 HLR 中转——符合标准但业务量大时 HLR 负荷是硬伤。

第二种是借短消息的思路：USSDC 先到用户归属 HLR 查路由信息，拿到 MS 当前位置后，直接将会话请求发到用户所在的 MSC/VLR，绕开 HLR 的中转。规范明确建议采用第二种方式实现 PUSH 类应用。实际组网里，这条“查路由后直连”的路由，需要 USSDC 支持 MAP 协议 6.3.0 及以上版本，并且要在 PSSR 参数里携带用户 MSISDN，选设备时这两个点必须验。

4. 业务流程与对话参数：四类业务、两类话单、一组超时值

4.1 银行类业务：上下行都走 USSD，整个交互在一个会话里完成

银行类业务包括费用支付、余额查询、转账，安全性要求高，上下行都采用 USSD。以余额查询为例，完整流程是：用户拨 #101*1# → USSDC 转发给银行 SP → SP 回“请输入账号”→ 用户输入账号 → SP 回“请输入密码”→ 用户输入密码 → SP 回“剩余 9533.2 元”。如果密码错误，SP 会回“密码错误，请重新输入”，让用户在同一会话里重输。

值得注意，这类业务端到端安全用专线直联或 IPSec 加密解决；如果想对 USSD 串本身做端到端加密，必须在终端侧（通常是 SIM 卡）实现加解密算法，密钥管理可以参考短消息手机银行的处理方式。这个选型要在业务设计阶段就定下来，后期补加密代价很高。

4.2 点播类业务：上行和菜单交互走 USSD，下行走 SMS

信息类点播业务（天气、航班、票务）用户体验要求是“能保存”，所以采用上行 USSD、下行短信的混合方式。以天气查询为例：用户拨 #111*1# → SP 回“请输入地区代码”→ 用户输入 0755 → SP 确认 ok → 查询结果以短消息下发。整个 USSD 会话只做导航和交互，最终内容落到短信里，用户能留存。

规范特别提到，业务开展初期如果不想改动计费中心软件，可以把所有点播消息通过短信下发，USSD 只做业务导航，利用短消息实现间接计费。这是快速上线的务实方案，比一上来就改造计费系统要稳。

4.3 PUSH 与点对点业务：PUSH 两种方式，点对点要关联两个会话

PUSH 类业务以“信息调查反馈”为例：USSDC 向用户发 USSR“信息调查反馈”，用户回反馈信息，USSDC 回“谢谢反馈”，会话结束。PUSH 的技术差异只在路由层（HLR 转发 vs 查路由直连），对 SP 侧是透明的。

点对点业务则需要 USSDC 上叠加点对点业务模块。以聊天为例，主叫 MS1 拨 #112*13822223333#，USSDC 需要分别建立与主叫方和被叫方的两个会话连接，再由点对点模块把两个会话关联起来。消息是双向转发的：MS1 发内容，模块转成 USSR 发给 MS2；MS2 的回复再转回给 MS1。这个双会话关联是联调时最容易漏掉的状态管理点——如果某个会话被异常释放，另一边必须同步释放，否则会出现“对方还在输入，这边已经黑屏”的怪现象。

4.4 对话参数：超时、会话上限、长消息、计费

规范给出了一组必须落地的对话管理参数，这是设备配置和 SP 联调的硬指标：

计费方面，USSDC 产生对话计费记录和消息计费记录两种话单，计费方式可按补充业务月租、对话持续时长、对话次数、信息内容、字节流量灵活选择。话单可通过 X.25、RS232 接口或 FTP、FTAM 规程传送给 BOSS。

注意：超时配置要能针对具体业务单独设置。把“建议值”当“最大值”用是常见错误——用户侧 30 秒是交互等待建议值，180 秒才是容忍上限；应用侧 60 秒是硬上限，别给 SP 配到 180 秒。

5. 常见问题与排查：五个翻车现场，现象、原因、解决

5.1 接入码规划翻车：前缀五花八门，用户根本记不住

现象：各地 SP 各自申请接入码，出现AAABBB#、#AA*BB# 各种前缀混用，用户记不住，业务开通率上不去。

原因：接入码规划没按规范建议的方式一走。规范给了三种编码方式：AAA 代表业务分类+BBB 代表不同 SP；AAA 代表 SP+BBB 代表业务分类；AAA 代表不同 USSDC+BBB 代表业务分类。且前缀可以是 1~3 位 * 或 # 组合，形式很多，但面向个人用户的应用只建议用 * 或 # 开头。

解决：按方式一规划接入码，并且只提供 1~2 个综合接入号作为门户，比如 #101# 做中文 USSD 综合接入号、#111# 做英文综合接入号，再用业务转移功能把请求导航到具体业务处理模块。行业应用需要遥测遥控的，才考虑用 ** 或 ##* 这种不便于记忆但不需要用户记的前缀。

5.2 过渡期路由配置错误：拜访地接入不是所有交换机都支持

现象：某省开通全国 USSD 业务后，漫游用户拨接入号失败，或请求绕行 HLR 导致时延明显增大。

原因：现网交换设备不支持拜访地应用路由。规范附录 A 明确只有 NOKIA 和华为支持 MSC/VLR 到 USSDC 的直连接入，其他厂家设备无法识别拜访地接入号段的路由配置。

解决：先盘点现网厂家。支持的就按拜访地接入直连 USSDC；不支持的改用归属地接入——MSC/VLR 把所有 USSD 请求都转给归属 HLR，由 HLR 分析接入码再转 USSDC。也可以按 A、B 地混合组网，让支持的地区直连、不支持的绕 HLR，按文中四个 Case 的路由表在 HLR 和 MSC 上逐条配数据并做拨打测试。

5.3 汉字乱码：DCS 字段被忽略，UCS2 编码没打通

现象：SP 下发中文 USSD 消息，部分终端显示乱码；或上行中文消息到 SP 侧变成不可读字节流。

原因：USSD 消息的汉字编码按 GSM 03.38 规范采用 UCS2（16bit）编码，对应 GB13000 字符集。但部分现网 MSC/VLR、HLR 不支持 DCS 非 0x0F 编码类型的传输，悄悄丢弃了 DCS 字段，导致终端和 SP 按不同字符集解读。

解决：网络设备（MSC/VLR、HLR、USSDC）都要支持 DCS 非 0x0F 的 USSD 消息传输，或在设备上将 DCS 检查设置为忽略，做透明传输。终端侧人工输入汉字消息，必须支持 GB13000 CJK 部分汉字。验收时用中文串做循环拨测，同时抓包对照 DCS 字段值，别只在英文环境下测试。

5.4 PUSH 业务把 HLR 压垮：标准方式的中转不是免费的

现象：PUSH 类业务放量后，HLR 信令负荷飙升，影响其他业务。

原因：采用了 ETSI 标准方式下发——每次 USSD 交互都要经过 HLR 转发，业务量一大，HLR 就成了瓶颈。

解决：改用非 ETSI 方式，USSDC 先到 HLR 查一次路由，拿到 MS 所在 MSC 地址后，直接与 MSC 建立 USSD 会话，后续交互不再经过 HLR。这是规范明确建议的方案，但前提是 USSDC 和 MSC 都支持相应 MAP 版本且能在请求里带 MSISDN。联调时建议在 HLR 侧抓 MAP 消息，统计 USSR 的经过次数，来确认是否已经绕开 HLR。

5.5 超时配置拍脑袋：会话资源被“僵尸对话”占满

现象：USSDC 对话资源被大量占用，新请求无法建立会话；或用户已经挂机，会话仍显示“交互中”。

原因：超时参数没按规范配置。用户侧响应超时配得过大，或应用侧 SP 故障后没有及时释放；单次对话也没有 10 分钟上限。

解决：按规范默认值落地——用户侧 30 秒（最大 180 秒）、应用侧 30 秒（最大 60 秒）、单对话最长 10 分钟。同时开启对话跟踪管理，对响应超时的对话主动释放；任意一方释放连接或出现故障时，USSDC 要释放与另一方的对话连接。注意处理点对点业务时，主叫和被叫两个会话要联动释放，不能只放一个。

6. 对接验收：用一套清单和一次抓包确认 USSDC 没配错

接手一个 USSDC 或 SP 接入项目，我不会急着写代码，而是先按规范做一轮配置体检。下面这份表是我常用的验收清单，覆盖了最容易出问题的几个点：

信令验证方面，我习惯在 USSDC 的信令接口单元侧抓一次 MAP 消息，确认消息类型和 SSN。用 tcpdump 抓包：

# 在 USSDC 信令接口单元侧抓 MAP over M3UA 流量 tcpdump -i eth0 -nn -s 0 'host 10.10.1.10 and (port 2905 or port 3905)' -w ussd_map.pcap # 用 wireshark 打开后过滤 USSD 相关 MAP 消息 wireshark ussd_map.pcap

参数说明：2905 是 M3UA 的默认 SCTP 端口，3905 是 M3UA 监听端口；如果 USSDC 走传统 TDM 七号信令，则需要用信令分析仪抓 SCCP 层。打开抓包文件后，重点看三类消息：MAP_PROCESS_UNSTRUCTURED_SS_REQUEST（用户发起请求）、MAP_UNSTRUCTURED_SS_REQUEST（网络发起请求）、MAP_UNSTRUCTURED_SS_NOTIFY（网络通知），同时确认目的 SSN 是 0x08——这和短消息中心一致，配置错会导致对端网元直接丢弃消息。

从那以后，我每次对接 USSD 项目都强制走一遍这套流程：先查交换机厂家是否支持拜访地接入，再对照号码段配置路由，最后抓包验 MAP 消息和超时参数。这套习惯帮我避开过好几次“功能正常但一放量就出问题”的尴尬。如果这份规范文档能帮你少走一段弯路，我的目的就达到了。希望帮到你。

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