简介中国移动通信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 服务请求会被转给 HPLMN150~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 说清楚了路由规则场景路由路径A 地用户未漫游使用全国业务A 地 MSC 直接送全国 USSDCB 地用户漫游到 A 地使用全国业务A 地 MSC 直接送全国 USSDCA 地用户漫游到 B 地使用全国业务B 地 MSC → A 地 HLR → 全国 USSDCB 地用户未漫游使用全国业务B 地 MSC → B 地 HLR → 全国 USSDC业务响应路由是请求路径的逆行方向。我一般会建议先摸清现网交换机厂家型号再决定哪些地区能走拜访地接入哪些必须走 HLR 转接别拿着目标网方案硬套现网。3.3 PUSH 下行两条路一条是标准但费 HLR一条是绕行但高效网络侧发起 USSD 业务PUSH 类有两种技术实现。第一种是 ETSI 标准方式USSDC 把请求发给 HLRHLR 转发到用户拜访的 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 发给 MS2MS2 的回复再转回给 MS1。这个双会话关联是联调时最容易漏掉的状态管理点——如果某个会话被异常释放另一边必须同步释放否则会出现“对方还在输入这边已经黑屏”的怪现象。4.4 对话参数超时、会话上限、长消息、计费规范给出了一组必须落地的对话管理参数这是设备配置和 SP 联调的硬指标参数建议值最大值说明移动用户侧响应超时30 秒180 秒超时后 USSDC 释放对话应用服务侧响应超时30 秒60 秒超过则释放防止 SP 故障挂死会话单次对话有效时间—10 分钟到点强制释放防资源泄漏长消息支持—至少 229 汉字可选支持 389 汉字计费方面USSDC 产生对话计费记录和消息计费记录两种话单计费方式可按补充业务月租、对话持续时长、对话次数、信息内容、字节流量灵活选择。话单可通过 X.25、RS232 接口或 FTP、FTAM 规程传送给 BOSS。注意超时配置要能针对具体业务单独设置。把“建议值”当“最大值”用是常见错误——用户侧 30 秒是交互等待建议值180 秒才是容忍上限应用侧 60 秒是硬上限别给 SP 配到 180 秒。5. 常见问题与排查五个翻车现场现象、原因、解决5.1 接入码规划翻车前缀五花八门用户根本记不住现象各地 SP 各自申请接入码出现AAABBB#、#AA*BB# 各种前缀混用用户记不住业务开通率上不去。原因接入码规划没按规范建议的方式一走。规范给了三种编码方式AAA 代表业务分类BBB 代表不同 SPAAA 代表 SPBBB 代表业务分类AAA 代表不同 USSDCBBB 代表业务分类。且前缀可以是 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 规范采用 UCS216bit编码对应 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 接入项目我不会急着写代码而是先按规范做一轮配置体检。下面这份表是我常用的验收清单覆盖了最容易出问题的几个点检查项验收标准对应规范要点接入码格式AAABBB# 或 #AAA*BBB#或 70~79 短号前缀 1~3 位 * 或 # 组合服务号码段合规路由配置归属地/拜访地号码段与 MSC 路由数据一致70~79、100~149 归 HPLMN150~199 归 VPLMNMAP 版本PSSR 参数中携带 MSISDNETSI 09.02 6.3.0 及以上超时参数用户侧 30/180 秒应用侧 30/60 秒会话 10 分钟按具体业务可配置汉字能力中文 USSD 消息无乱码DCS 非 0x0F 可传输GSM 03.38 UCS216bit-GB13000信令验证方面我习惯在 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 消息和超时参数。这套习惯帮我避开过好几次“功能正常但一放量就出问题”的尴尬。如果这份规范文档能帮你少走一段弯路我的目的就达到了。希望帮到你。本文还有配套的精品资源点击获取 USSD业务总体技术要求解读：系统架构、组网路由与排障实践
简介中国移动通信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 服务请求会被转给 HPLMN150~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 说清楚了路由规则场景路由路径A 地用户未漫游使用全国业务A 地 MSC 直接送全国 USSDCB 地用户漫游到 A 地使用全国业务A 地 MSC 直接送全国 USSDCA 地用户漫游到 B 地使用全国业务B 地 MSC → A 地 HLR → 全国 USSDCB 地用户未漫游使用全国业务B 地 MSC → B 地 HLR → 全国 USSDC业务响应路由是请求路径的逆行方向。我一般会建议先摸清现网交换机厂家型号再决定哪些地区能走拜访地接入哪些必须走 HLR 转接别拿着目标网方案硬套现网。3.3 PUSH 下行两条路一条是标准但费 HLR一条是绕行但高效网络侧发起 USSD 业务PUSH 类有两种技术实现。第一种是 ETSI 标准方式USSDC 把请求发给 HLRHLR 转发到用户拜访的 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 发给 MS2MS2 的回复再转回给 MS1。这个双会话关联是联调时最容易漏掉的状态管理点——如果某个会话被异常释放另一边必须同步释放否则会出现“对方还在输入这边已经黑屏”的怪现象。4.4 对话参数超时、会话上限、长消息、计费规范给出了一组必须落地的对话管理参数这是设备配置和 SP 联调的硬指标参数建议值最大值说明移动用户侧响应超时30 秒180 秒超时后 USSDC 释放对话应用服务侧响应超时30 秒60 秒超过则释放防止 SP 故障挂死会话单次对话有效时间—10 分钟到点强制释放防资源泄漏长消息支持—至少 229 汉字可选支持 389 汉字计费方面USSDC 产生对话计费记录和消息计费记录两种话单计费方式可按补充业务月租、对话持续时长、对话次数、信息内容、字节流量灵活选择。话单可通过 X.25、RS232 接口或 FTP、FTAM 规程传送给 BOSS。注意超时配置要能针对具体业务单独设置。把“建议值”当“最大值”用是常见错误——用户侧 30 秒是交互等待建议值180 秒才是容忍上限应用侧 60 秒是硬上限别给 SP 配到 180 秒。5. 常见问题与排查五个翻车现场现象、原因、解决5.1 接入码规划翻车前缀五花八门用户根本记不住现象各地 SP 各自申请接入码出现AAABBB#、#AA*BB# 各种前缀混用用户记不住业务开通率上不去。原因接入码规划没按规范建议的方式一走。规范给了三种编码方式AAA 代表业务分类BBB 代表不同 SPAAA 代表 SPBBB 代表业务分类AAA 代表不同 USSDCBBB 代表业务分类。且前缀可以是 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 规范采用 UCS216bit编码对应 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 接入项目我不会急着写代码而是先按规范做一轮配置体检。下面这份表是我常用的验收清单覆盖了最容易出问题的几个点检查项验收标准对应规范要点接入码格式AAABBB# 或 #AAA*BBB#或 70~79 短号前缀 1~3 位 * 或 # 组合服务号码段合规路由配置归属地/拜访地号码段与 MSC 路由数据一致70~79、100~149 归 HPLMN150~199 归 VPLMNMAP 版本PSSR 参数中携带 MSISDNETSI 09.02 6.3.0 及以上超时参数用户侧 30/180 秒应用侧 30/60 秒会话 10 分钟按具体业务可配置汉字能力中文 USSD 消息无乱码DCS 非 0x0F 可传输GSM 03.38 UCS216bit-GB13000信令验证方面我习惯在 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 消息和超时参数。这套习惯帮我避开过好几次“功能正常但一放量就出问题”的尴尬。如果这份规范文档能帮你少走一段弯路我的目的就达到了。希望帮到你。本文还有配套的精品资源点击获取