简介中国移动通信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 的机制对比把两者的差异摊在一张表里比逐条读文字更容易记住设计边界维度USSDSMS承载信道空闲态 SDCCH、通话态 FACCH主要走 SDCCH 控制信道传输模型面向连接的会话经 USSDC 中继存储转发经短信中心会话保持一次会话内可多轮往返每条消息独立无会话概念接收方离线会话建立失败无落盘暂存消息在短信中心驻留等待典型速率约 600bit/s空闲、约 1000bit/s通话与 USSD 共享控制信道资源交互能力支持菜单、输入、二次确认单次单向为主这张表里最容易被低估的是“会话保持”这一行。正因为 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 服务服务网络应把消息直接转发到 HPLMN150-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 把业务请求发给 HLRHLR 转发到用户拜访的 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 流程都会先把“这条会话在哪一步可能挂起、挂起后谁来释放”在纸上走一遍再去看代码——这个习惯帮我省掉了不少上线后的资源告警。希望帮到你。本文还有配套的精品资源点击获取