USSD业务总体技术要求拆解：从组网路由到联调排查实战-北京尧图网络

简介中国移动通信USSD应用接口协议是一份面向通信行业从业者的企业标准文档围绕非结构化补充业务数据USSD业务展开系统规定了业务流程、编号方式、应用系统接口、计费及信息安全等关键技术要求为设备选型、工程设计、业务规划和网络运维提供直接参考。资源包共1个文件为doc格式文档大小781KB内容涵盖USSD业务总体技术要求、USSD应用接口协议、设备规范及标准编号如QB-D-069-2009、QB-D-070-2009等要点适合移动网络研发、测试及运维人员研读。目前已有576人学习下载文档结构清晰包含术语定义、业务说明、系统结构等模块便于按需查阅。对于需要深入理解USSD技术规范或参与相关项目开发的读者这份标准原文具有较高的参考价值可帮助快速掌握中国移动USSD业务的整体框架与接口要求。1. 为什么一份2009年的USSD企业标准到今天还有拆读价值一份发布快二十年的运营商企业标准很多人第一反应是早过时了。但当你真正对接过USSDCUSSD中心、HLR、MSC这类网元或者给SP侧写过USSD应用接入程序会发现这份某运营商企业标准QB-D-069-2009《USSD业务总体技术要求》依然是全网设备选型、工程设计、路由数据配置和故障排查的共同依据。USSD非结构化补充业务数据业务不靠短信通道转发而是在信令面上建立一条面向连接的会话这套机制二十年来没有本质变化。本文不逐页复述标准原文而是按一线工程师视角把系统结构、组网路由、超时参数、计费与安全这些真正影响落地的部分拆开讲最后给出一份可以直接照用的联调检查思路。2. USSD业务定位与系统结构先把网元分工和接入码规则捋清2.1 USSD不是短信面向连接会话与存储转发的本质区别先说结论USSD本质上是一个面向连接的会话型业务。用户在手机上输入*AAA*BBB#格式的短字符串相当于拨了一个业务号码网络侧为这次交互建立一条虚拟会话通道后续多轮消息都在这条通道上跑直到某一方主动释放。而SMS是存储转发系统物理承载层没有会话通道消息发出去后就与源端无关了。这个区别决定了两种业务的响应速度和交互能力完全不在一个量级。从信道占用看USSD在非通话态使用SDCCH速率约600bit/s通话态切换到FACCH速率约1000bit/s比短信在物理层的传输效率更高。更重要的是USSD每次消息发送不需要重新建立信道响应速度比短信快得多。实际做业务时你会发现用USSD做多级菜单导航、金融类多轮交互体感明显比短信往返顺畅。USSD还有一个对运营商很友好的特性把现有的GSM网络当作透明承载实体运营商和SP可以自行定义符合本地用户需求的业务不受短信中心存储转发逻辑的限制。标准里列出的典型业务包括航班信息查询、体育比赛结果、银行账务查询、支付转账、外汇交易以及工业环境的遥测遥控等。Phase II阶段更是支持手机和网络侧双向发起会话网络侧不仅能发USSD请求还能主动发USSD通知这让PUSH类业务在USSD上有了落地空间。2.2 系统结构USSDC的七个逻辑模块与MSC/HLR分工从组网结构看USSD业务涉及的网元不复杂但分工必须清楚。MSC/VLR负责检查移动台发出的USSD请求是否合法然后分析业务接入码决定把请求交给归属地HPLMN还是拜访地VPLMN处理。如果交给HPLMN处理请求被路由到用户归属的HLR如果由VPLMN处理则直接路由到对应的USSDC。HLR的角色在归属地应用场景中很关键当移动台发起的USSD请求需要HPLMN处理时HLR把请求前转给USSDC当USSDC主动发起USSD请求时HLR还能提供当前移动台的位置信息这是做PUSH类业务的基础。可以简单理解成MSC/VLR是第一道路由判断节点HLR是归属地业务的中间转发节点USSDC才是业务处理的心脏。USSDC在逻辑上被拆成七个模块这个拆分不是纸面功夫直接决定了后期扩容和独立组网的方式逻辑模块主要职责信令接口单元七号信令网接入支持MAP Phase2、国内NO.7、SCCP核心处理单元协议解析、路由分析、业务请求与响应转发数据库应用服务映射关系、对话信息存储USSD网关SP接入采用UAP协议SP可完全控制USSD对话USSD Portal门户菜单预置与呈现SP采用CMPP或UAP协议接入网管接口模块对接统一网管系统提供统计与网络管理计费和话单接口模块生成USSD话单并传送给BOSS系统标准明确要求USSDC设计时做模块化设计保证USSD网关和USSD Portal模块的独立性。这样做的好处很实际业务量小时USSD网关和Portal可以作为USSDC的一个功能模块运行全网有多套USSDC时再把Portal单独剥离成独立网元避免不同USSDC上的菜单数据不同步。2.3 USSD网关与USSD Portal两条SP接入路线的差别对接过SP接入的人最容易在这里犯迷糊USSD网关和USSD Portal都提供SP接入功能到底该走哪条路两者的本质区别在于SP对会话的控制权。通过USSD网关接入的SP可以获得对USSD对话的完全控制。网关负责在SP和USSDC之间做消息透传和业务分发SP可以实时参与多轮交互适合银行类、业务逻辑复杂的应用。而USSD Portal走的是菜单预置路线SP把菜单预先放在Portal上用户在浏览过程中SP不能控制会话只有当用户访问到特定菜单项时Portal根据SP预设条件向SP上报通知消息。这条路线适合信息点播类、内容相对固定的业务。USSD业务网关存在的另一个理由是收敛连接。多个USSDC需要连接同一个SP时如果每个USSDC都直接与SP建链SP侧链路管理和地址配置都会失控。中间加一层网关由网关统一对SP进行管理还可以提供不同地区USSD业务系统的互连实现跨地区业务转移。同时SP应用的故障不会直接影响USSD中心这对保证USSDC的系统稳定性很有价值。网关两侧与SP、与USSDC之间都采用TCP/IP连接用UAP协议交互。提示选择USSD网关还是USSD Portal不要只看省事程度要先确认业务是否需要会话级实时控制。2.4 接入码与业务分类70~79、100~149、150~199的语义USSD业务接入码是路由的第一要素标准里给了两种格式。格式一以*或#组合成的1~3位字符做前缀紧跟三位服务号码100~199后面可接若干通过*分隔的参数以#结束。格式二70~79后面不跟其他任何字符。下面这些字符串都是合法接入码*100#、*139*11#、78、#179*09*21#、**#120*5*3#。服务号码的号段规划是有明确路由含义的。70~79和100~149用于HPLMN也就是归属地应用当收到漫游用户的这类USSD消息时服务网络会把消息直接转发到HPLMN处理。150~199用于VPLMN是拜访地应用由拜访网络决定如何处理适合全国性业务在用户漫游时本地接入避免路由迂回。建议的规划方式是全国业务尤其是银行、金融类采用拜访地应用组网省内业务信息点播、行业应用采用归属地应用组网。业务接入码本身的编码原则也有讲究。方式一是AAA代表业务分类如银行查询、BBB代表不同SP方式二是AAA代表SP、BBB代表业务分类方式三是AAA代表不同USSD中心、BBB代表业务分类。标准建议采用方式一。另外考虑到用户记忆困难可以设置1~2个综合接入号例如#101#作为中文USSD业务门户接入号、#111#作为英文USSD业务门户接入号利用业务转移功能把请求导航到具体业务处理模块或SP。下面给出一段接入码解析脚本对接SP或做路由分析时可以直接拿来验证用户输入的格式# 解析USSD接入码返回格式类型、服务号和扩展参数 # 用途对接SP或路由分析时快速判断业务归属 def parse_ussd_access_code(raw): # 去掉结尾#兼容没有结束符的输入 code raw.rstrip(#) if not code: return None # 格式二70~79纯数字不允许字符串扩展 if code.isdigit(): svc int(code) if 70 svc 79: return {format: 2, prefix: , service: svc, params: []} # 格式一1~3位*或#前缀 100~199服务号可选*参数 stripped code.lstrip(*#) prefix code[:len(code) - len(stripped)] parts stripped.split(*) if parts and parts[0].isdigit(): svc int(parts[0]) if 100 svc 199: return { format: 1, prefix: prefix, service: svc, params: parts[1:], } return None if __name__ __main__: samples [*100#, *139*11#, 78, #179*09*21#, **#120*5*3#] for s in samples: print(s, -, parse_ussd_access_code(s))这段脚本的逻辑是先剥掉结尾的#再判断是纯数字格式还是带前缀的格式一。纯数字且落在70~79区间属于归属地门户接入号格式一则提取服务号和参数列表。参数prefix可以用来识别用户习惯用*还是#开头某些情况下这对接入码兼容性测试有意义。注意脚本只做格式解析真正的路由判断还要结合业务类别、用户归属和MSC/VLR的配置数据不能只靠接入码一个字段下结论。业务分类方面标准从三个维度做了划分。按业务特征分银行、金融类上下行均为USSD信息类点播上行USSD、下行可以是USSD、SMS、MMS或语音行业应用只把USSD当承载。按发起方分移动用户发起的PSSR、网络发起的USSR、网络发起的USSN。按使用范围分全国业务和省内业务银行金融类建议做成全国业务信息点播和行业应用建议做成省内业务。2.5 业务流程三件套PSSR、USSR、USSN怎么用读这份标准时最容易绕晕的是消息名。MAP协议里USSD业务主要涉及三条消息MAP_PROCESS_UNSTRUCTURED_SS_REQUESTPSSR、MAP_UNSTRUCTURED_SS_REQUESTUSSR、MAP_UNSTRUCTURED_SS_NOTIFYUSSN。PSSR对应移动用户发起的业务请求。银行类的余额查询就是一个典型的多轮会话用户输入#101*1#发起请求USSDC返回请输入账号用户输入账号后提示请输入密码密码校验通过后返回余额整个交互在一个USSD会话里完成任何一步输入错误都可以在同一会话内引导重试。信息类点播业务则常采用上行USSD、下行SMS的混合方式用户输入#111*1#查询天气USSDC返回请输入地区代码用户回复区号后查询结果通过短信通道下发。这样做的好处是用户可以把结果保存下来而菜单导航过程依然享受USSD的快速响应。USSR和USSN则用于网络侧发起的业务典型场景是PUSH类应用。USSDC主动向用户发起一个USSD对话比如信息调查反馈用户直接在USSD界面里回复结束后会话释放。点对点USSD业务则比较特殊需要在USSDC上叠加点对点业务模块分别建立与主叫方和被叫方的两段会话连接再由业务模块把两段会话关联起来实现类似聊天的即时交互。这里有个现实约束USSD消息在手机上不能长期存储依赖较强的输入能力交互体验更像IM而不是短信。3. 组网路由与MAP接口拜访地接入、HLR转发和过渡期改造成选择3.1 归属地应用与拜访地应用组网方式和路由判断逻辑组网方式的选择直接决定了信令路由是否绕路。归属地应用采用USSDC与HLR建立连接的方式提供服务服务号码为70~79和100~149各HLR按接入码配置到USSDC的路由数据。当用户漫游时业务请求会从拜访地MSC/VLR途经用户归属HLR再到达USSDC链路相对较长。一个省内可以部署一套或多套USSDC多套时可以按服务号码或按用户号码划分业务分担。拜访地应用则采用USSDC与MSC建立连接的方式服务号码为150~199。全国业务建议采用拜访地组网这样漫游用户发起业务时请求直接从当前拜访地MSC/VLR送到USSDC避免了到归属HLR的迂回省去了HLR的转发负担。代价是各地MSC/VLR都需要配置到全国业务USSDC的路由数据数据维护量更大。省内业务采用归属地组网则有一个很实际的好处在任何支持USSD功能的交换机下用户都能使用归属地业务不需要拜访地做特殊数据配置。实际规划时需要把接入码解析和路由判断结合起来。服务号码落在70~79和100~149时表示用户请求归属网络的USSD服务落在150~199时由拜访网络决定处理方式。一些现网交换机的路由数据配置就是按这个区间做的分号段路由所以接入码规划一旦定下来尽量不要后期混用号段否则MSC/VLR的GT数据要大面积返工。3.2 网络侧发起HLR转发与取路由直发的取舍PUSH类业务也就是SP主动向终端下发信息的场景技术上有两条路坑也不少。第一条是USSDC把业务请求发给归属HLR由HLR转发到用户当前拜访的MSC/VLR这是ETSI规范的标准方式。整个交互过程中每一次消息都要经过HLR中转逻辑最简单协议兼容性也最好但业务量一上来HLR的信令负荷会明显增加。HLR在现网里承担的位置更新、鉴权等基础工作已经非常重再叠加USSD转发流量很容易成为瓶颈。第二条是USSDC先到用户归属HLR查询路由信息拿到当前MSC/VLR地址后直接与MSC建立USSD会话。这种方式不是ETSI标准定义的做法思路其实是从短信下发借用过来的好处是把HLR的影响降到最低HLR只在会话建立前参与一次位置查询后续消息全部在USSDC和MSC之间直通。标准明确建议PUSH类应用采用取路由直发的方式我在现网看到的落地案例也基本都走这条路。两种方式的优劣可以这样概括对比项通过HLR转发HLR取路由后直连MSC规范性ETSI标准方式非标准借用短信下发思路信令路径USSDC→HLR→MSC/VLR往返都经HLR仅建链前查一次HLR之后直连HLR负荷随业务量线性增长基本恒定适用场景小流量、试点验证Push类业务、规模商用提示如果HLR厂家版本较老确认取路由直发方式在当前HLR软件版本上的兼容性必要时先在实验室用小流量验证再上全网。3.3 过渡期混合组网设备不支持时怎么落地标准附录A里有一段容易被忽略但非常重要的话现网交换机厂家并不能对目标网组网方案进行很好支持当时只有少数设备商支持MSC到USSDC的拜访地直连路由。也就是说标准定义的目标网形态不等于现网立刻能落地设备能力是硬约束。过渡期方案的做法是在不支持拜访地接入的地区所有USSD业务请求都转发到用户归属HLR由HLR分析业务接入码并把请求转发到相应USSDC。这样MSC/VLR不再需要判断业务是归属地还是拜访地只需要把所有USSD请求前转给归属HLR即可数据配置大幅简化。代价是HLR负荷压力集中在归属地侧部分地区HLR负荷过大的话就不适合整网采用这个方式。标准给出了一个混合组网模型A地交换机支持拜访地接入方式B地交换机不支持两地MSC/VLR和HLR都支持归属地接入方式。此时路由逻辑按四种情况区分A地用户未漫游从A地接入请求由MSC/VLR直送全国USSD中心B地用户漫游到A地同样从A地MSC/VLR直送USSD中心A地用户漫游到B地请求经B地MSC/VLR送到A地归属HLR再由HLR送到USSD中心B地用户未漫游从B地接入请求送到B地HLR再由HLR送USSD中心。业务响应遵循请求的反向路径返回。这个Case表我建议直接抄到自己的运维文档里。每次配置新接入地区的数据时先判断该地区交换机是否支持MSC到USSDC直达路由再决定配置哪套方案能避免很多业务在某个地市不通的奇怪工单。3.4 MAP接口与协议版本PSSR消息里带MSISDN的细节USSDC与PLMN之间的接口遵循YD/T 1038-2000 MAP Phase2规范涉及三条核心MAP消息MAP_PROCESS_UNSTRUCTURED_SS_REQUEST用于终端发起业务流程中传送用户请求MAP_UNSTRUCTURED_SS_REQUEST用于网络侧与应用侧之间的请求传递MAP_UNSTRUCTURED_SS_NOTIFY用于网络侧向终端发送USSD通知。其中PSSR消息的参数里包含一个重要字段用户的MSISDN。这个字段不是一开始就有的。标准要求USSDC对上述消息的处理依据GSM 0902 v6.3.0R97以上版本该版本在PSSR参数中引入了MSISDN。为什么强调这一点因为如果交换机支持的是更早的MAP版本PSSR消息里可能拿不到主叫MSISDNUSSDC就无法做按号段鉴权、无法记录用户号码、无法生成消息级话单整个业务运营和排障能力都会受限。所以在设备选型和现网改造时一定要核实MAP版本是否满足6.3.0以上这个属于容易被忽略的隐形条件。应用侧对接的细节同样在接口规范中。USSD是面向连接的应用USSDC与SP之间的协议需要能够标识每条消息属于哪个USSD对话连接所以USSDC与外部应用接口采用面向连接的应用协议具体见系列标准中的USSD应用接口协议。另外USSDC的SSN子系统号与短消息中心设为一致即0x08USSD中心自身作为七号信令网的一个信令点SP信令点编码按七号信令规范规划。4. USSDC功能落地参数鉴权、超时、会话存储与长消息配置4.1 用户鉴权与应用管理不鉴权、按号段鉴权的适用边界USSD中心对移动用户发起的请求要能核查主叫标识判断是否为本中心归属用户。标准给定了两种必选鉴权方式不鉴权和按号段鉴权具体采用哪种由运营者根据需要设置。不鉴权适合行业应用这类不涉及资金安全的场景按号段鉴权则适合银行金融类业务可以在USSDC侧配置允许接入的号段范围号段外的用户直接拒绝。与鉴权配套的是应用管理能力。USSDC要和各种应用中心连接比如股票交易所、银行、邮件服务器核心是维护业务接入码和应用服务之间的映射关系。标准明确要求存储四类数据账户标识SP代码、应用类型、业务接入码组、服务器地址。实际配置时这四类数据缺一不可——业务接入码组决定路由服务器地址决定消息往哪发应用类型决定计费和话单策略SP代码决定归属和鉴权。还有一个容易被忽略的业务接入码鉴权功能USSDC应能根据业务接入码核查应用服务侧发起的USSD业务是否合法保留业务接入码与应用服务的对应关系判断应用服务是否可以以该接入码向移动用户发起业务。这个功能对防恶意PUSH非常关键部署独立USSD网关时该功能落在网关上而不是USSDC上这个归属关系在建设时要提前明确。4.2 对话管理超时参数、最大时长与会话数配置对话管理是USSDC的核心能力也是最容易出现配置事故的地方。标准给出的超时建议和最大值非常明确下面这份参数表我建议直接打印出来贴在机房里参数项建议值最大值说明移动用户侧响应超时30秒180秒超时后USSDC释放对话连接应用服务侧响应超时30秒60秒超时后释放应用侧要求更严一次USSD对话有效期不超过10分钟暂无到期强制释放防止资源泄漏同一用户并发对话数支持多个按设备能力用户发起和应用发起均可并存标准允许针对具体业务配置用户侧和应用侧超时而不是全局一刀切。我一般会在银行类业务上把移动用户侧超时适当放宽到60秒左右因为用户输入账号、密码的时间普遍偏慢应用侧保持30秒不变应用服务器响应速度是稳定的。信息点播类业务则两边都用默认的30秒用户输入就是简短的接入码和参数不需要长时间停留。需要注意超时后的动作是释放对话连接这会触发信令面上的释放流程。如果某个USSD会话出现异常占用USSDC还要能识别响应时间超常的对话并主动释放。任意一方释放连接或出现故障时USSDC应释放与另一方之间的会话连接避免出现半边挂起的僵尸会话。4.3 对话存储字段排障时优先盯哪几个USSDC必须对移动用户和应用服务发起的USSD对话数据进行存储标准把存储内容列得很具体USSD对话标识、对话消息的文本内容和长度、对话发起和结束时间、对话状态信息、交互次数、对话有效期、发起者地址和目标地址、应用类别移动用户发起还是网络发起、信息来源移动用户号码或业务接入码、对话当前消息发送状态、失败原因。排障时这些字段的价值差异很大。我最先看的是对话标识、当前消息发送状态和失败原因三个字段。对话标识用于把同一会话的多条消息串起来定位是哪一轮交互出的问题发送状态能看出消息是成功送达还是在网络侧被丢弃失败原因则直接给出信令层面的拒绝理由很多时候比SP侧日志更早暴露真相。交互次数和有效期则用来判断是否发生了超时释放。信息来源字段同样重要。当一条USSD消息来自SP侧时信息来源记录的是业务接入码来自移动用户时记录的是用户号码。如果同一个业务接入码被多个SP共用而这个字段没有做SP级映射后续查话单和定责就会很麻烦。所以对话存储不仅要存还要定期做数据归档供计费稽核和恶意投诉取证使用。4.4 汉字编码与长消息UCS2、DCS、229个汉字怎么配合中文USSD的支持是现网业务绕不开的话题。标准要求汉字USSD编码符合GSM规范03.38v5.6.1采用UCS216bit编码字符集对应GB13000。人工输入汉字USSD消息的终端需要支持GB13000 CJK部分的汉字这个约束在终端选型时要确认。上行链路还有一个特殊的DCS要求。终端至SP应用服务器、SP应用服务器至终端的USSD消息传输网络设备应支持DCS数据编码方案不为0x0F编码的消息类型并且网络设备可以设置忽略检查DCS字段以便进行透明传输。这句话的实际含义是如果DCS指示的是UCS2编码而不是默认的GSM 7-bit字母表MSC/VLR和HLR仍然要把消息原样透传不能因为编码字段不认识就丢弃或者做错误的码型转换。我在现网遇到过的中文乱码一半以上是DCS字段在网络节点被改写导致的。长USSD消息方面终端和SP应用服务器应能支持长USSD信息的拆分和组合终端至少支持229个汉字长度的USSD消息可选支持至少389个汉字长度。注意至少229汉字是终端侧能力不是USSDC的下发上限。实际做业务文案时我一般把单条消息控制在200个汉字以内留出余地给USSDC加消息序号和分片标识如果业务内容确实超过这个长度要确认终端是否支持拆分组合不支持的话就需要调整文案或者改用SMS兜底下发。5. 计费、安全与常见问题排查四个对接现场的高频坑5.1 计费方式从按条、按时长到消息级计费USSD的计费方式设计得比较灵活标准允许根据运营需要按月租收基本费、按对话持续时长计费、按对话次数计费、按信息内容计费或按字节流量计费。这个灵活性在业务初期反而容易造成困惑——到底选哪种需要先想清楚业务形态。对信息点播类业务按对话次数计费最直观用户在USSD菜单里每完成一次有效查询算一次。对行业应用和物联网遥测遥控按字节流量或按时长更贴合实际网络占用。银行金融类业务通常不直接向用户收USSD费而是打包在业务套餐里USSDC侧只负责产生话单供稽核。标准还给出一个过渡期讨巧的做法业务量不大时所有点播消息通过短信方式下发同时通过短信间接计费USSD只做业务导航。这样计费中心软件几乎不用改动业务就能先跑起来。话单层面要区分对话计费记录和消息计费记录两种。对话记录描述一次会话整体的时长、次数、起止时间消息记录描述每一条消息的收发、长度、编码等信息。标准要求在消息级话单中增加一个字段指示该消息是否计费这是做精细化运营的基础。我在对接BOSS时踩过这个坑只开了对话级话单消息级话单没启用导致按条计费的业务全部无法出账。5.2 计费接口与数据存储X.25、RS232、FTP/FTAM的选型边界计费数据的传输方式标准列出了X.25接口、RS232接口、磁带脱机处理以及FTP、FTAM规程传送。这些选项放在今天是有点历史感的但理解它们的适用边界仍然有现实意义。X.25和RS232是早期接计费中心最常用的物理接口特点是简单、可靠、低带宽。磁带脱机处理则是典型的批量文件传输适合每日一次的话单搬运。随着IP承载网普及FTP成了最主流的话单传送方式——USSDC把话单文件按约定格式写入指定目录计费中心定期拉取FTAM则是OSI体系下的文件传输协议在国内运营商老旧的计费系统里还有一些存量应用场景。选型时先看计费中心支持什么再决定USSDC侧配哪个协议不要反过来。计费数据保存方面标准要求USSDC提供有效的计费记录保存手段可以是文件方式或数据库方式。文件方式的好处是格式统一、便于FTP传输坏处是检索和归档需要额外的脚本工具数据库方式查询方便但要注意计费表的数据量增长和清理策略。话单能不能保存、保存多久、怎么防止重复计费这些在USSDC设备选型时就要明确写进技术要求。5.3 安全问题专线、IPSec与SIM卡端到端加密银行类业务对安全性的要求从标准里能明显感受到。用户的账号、密码等敏感信息如果在USSD传输过程中被截获造成的损失是直接的所以标准专门拿出一章讲安全问题。USSDC到银行应用服务器之间的链路安全标准给出了两个选项专线直联和IPSec加密。专线直联的物理隔离最彻底但成本高、开通周期长适合大行、核心交易场景IPSec加密可以在现有IP承载网上建立加密隧道部署灵活适合中小型金融机构或非实时业务。需要说明的是这里说的IPSec是标准的网络层加密机制和运营商内部业务系统之间的安全保护是同一类技术不涉及任何网络访问代理类工具。如果要实现USSD串的端到端加密单靠链路加密还不够。消息在无线网段仍然以明文形式存在所以必须在终端侧实现加密和解密算法通常通过SIM卡实现让USSD数据在终端和银行应用服务器之间做端到端加解密。标准建议加密算法实现和密钥管理可以参考基于短消息承载的手机银行业务处理方式。这块能力依赖终端和SIM卡的协同支持属于想的容易做的难的部分商务和技术都要提前摸底。提示端到端加密需要SIM卡侧配合选型时先确认目标用户群的终端和卡是否具备相应能力否则安全方案只能做到链路层。5.4 常见问题排查四个高频踩坑现场现象一USSD会话在用户输入到一半时被强制释放。用户反馈每次输到密码那一步就断线。原因USSDC用了全局默认的30秒超时没有按业务单独配置银行类业务用户输入账号密码的时间很容易超过30秒。解决按业务接入码单独设置移动用户侧超时银行金融类放宽到60秒左右应用侧超时保持30秒不变改完参数后做一次完整的多轮交互拨测再上线。现象二按条计费业务话单对不上账。计费中心的详单条数和实际业务量偏差明显。原因USSDC只开启了对话级计费记录消息级话单没启用导致按消息条数计费的业务无法出账。解决在USSDC侧检查话单配置启用消息级话单并按标准要求在每条消息记录中增加是否计费指示字段做BOSS联调时用固定业务接入码打样逐条比对消息数与话单数。现象三中文USSD内容在终端上显示乱码。用户看到的是一串无法识别的字符但英文业务正常。原因上行或下行链路上DCS字段不是0x0F某个网络节点对UCS2编码消息做了错误的码型转换或者直接丢弃了消息。解决在MSC/VLR和HLR侧设置忽略检查DCS字段启用透明传输用支持UCS2的测试终端分别从归属地、漫游地场景跑中文消息确认整条链路无乱码。现象四PUSH类业务上线后HLR负荷飙升。USSDC部署前HLR信令负荷正常部署PUSH业务后HLR负荷直接翻倍。原因PUSH类会话走了HLR转发方式每条USSD消息往返都要经HLR中转业务量稍大就把HLR压垮了。解决改造为HLR取路由后直连MSC的方式USSDC先查HLR拿到用户当前位置再直接与MSC建会话改造后对比HLR的MTP/SCCP负荷指标确认下降幅度。现象五长文本USSD消息超过200个汉字后部分终端收不全。内容被截断或者同一会话里出现多条无序消息。原因终端不支持长USSD消息的拆分组合或者SP侧下发时没有按规定分片。解决确认终端能力是否至少支持229个汉字SP侧按附录B要求做消息拆分和组合并让USSDC在对话里正确标识分片归属业务文案上尽量控制长度长内容拆成多轮菜单引导。6. 把标准变成检查清单验收、联调与附录A过渡期方案的用法6.1 用规范生成联调检查清单读这份标准最有价值的落地方式不是通读而是把它编译成一张检查清单每次USSDC新建、升级或SP接入联调时逐项核对检查项标准要求联调验证方法USSDC编号使用E.164号码编码方式同MSCIDSSN为0x08核对HLR和MSC侧配置的USSDC地址与SSN服务号码路由70~79、100~149为HPLMN应用150~199为VPLMN应用逐号段拨测抓取MAP消息确认路由走向超时与有效期建议30秒用户侧/应用侧上限180秒/60秒对话不超过10分钟配置后做超时拨测观察USSDC释放流程消息级计费每条消息产生话单带计费指示字段抽样核对BOSS话单与消息条数汉字与长消息UCS2/GB13000编码DCS可透明传输终端至少支持229汉字用长中文串拨测检查DCS字段与消息分片MAP版本GSM 0902 v6.3.0以上PSSR消息携带MSISDN与交换机厂家确认版本抓包验证消息字段这份清单帮我避免过不止一次返工。尤其PSSR消息携带MSISDN这一项曾经在某个设备上因为MAP版本不达标导致USSDC完全拿不到用户号码按号段鉴权和话单全废最后靠升级版本才解决。6.2 附录A过渡期方案的实际用法附录A在很多项目里被跳过但它是现网落地最有指导价值的部分。它回答了三个实际问题目标网方案要求MSC/VLR、HLR和USSDC都要有连接但现网设备可能不支持MSC到USSDC的直连过渡期可以退化为所有USSD请求都经HLR转发如果部分区域支持直达另一部分不支持就按混合组网方式分别配置数据。具体操作上我会先把现网交换机型号和软件版本梳理一遍逐个确认是否满足两条关键能力一是支持MSC到USSDC的接口方式拜访地应用路由二是MAP接口版本达到6.3.0以上。支持的地区直接按目标网方案配置不支持的地区走HLR转发然后对照标准里的Case表逐类核对用户的归属地、拜访地组合确保每一类用户都能找到正确的路由路径。这里特别提醒混合组网下同一用户漫游到不同地区路由路径是不同的配置完成后务必用漫游测试卡跑一遍完整用例。我记得有一次赶进度直接按目标网方案给一批交换机配了MSC直达USSDC的路由数据结果某区域的部分设备根本不支持这个接口USSD请求全部被转发到HLRHLR信令负荷瞬间翻倍最后只能连夜回退到附录A的过渡期方案。从那以后我每次做USSD相关数据配置都把6.1、6.2节和附录A翻出来对照一遍先确认设备能力边界再决定用哪套组网方式。希望帮到你。本文还有配套的精品资源点击获取

USSD业务总体技术要求拆解：从组网路由到联调排查实战

相关推荐

阿里云SLB-ECS-OSS-RDS四件套迁移实战：从架构分层到数据同步

Halcon HObject转Bitmap24位：内存重排原理与完整实现

VC++与MFC实现CAD绘图软件：源码解析与二次开发实践

更多资讯

表达退化：从原理诊断到白化与对比学习解决方案

AI Agent产品推荐系统开发实战：从需求拆解到上线踩坑

SuperMap-Cesium-3D加载倾斜摄影模型：OSGB转3D Tiles与性能调优实战

CEF4Delphi 86集成指南：Delphi嵌入Chromium的工程化实践

ADS131A02/A04上电初始化失败排查：SPI读0xFF的硬件时序根源

0.96寸OLED IIC驱动电路设计：原理图与PCB实战全解析

今日更新

Cephadm实战指南：Linux系统工程师的生产级Ceph集群部署与排障

不想再被 Token 额度卡脖子？把免费 API 接入 WorkBuddy 的完整教程

ITK中SpatialObject几何体系解析：坐标系、变换与管道集成

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？