简介GSM-R智能网系统技术文档基于CAMEL3协议系统阐述铁路专用移动通信智能网架构面向铁路通信工程师、网络规划人员、运维人员及通信相关专业读者。文档从智能网起源与发展讲起逐一剖析gsmSSP、gprsSSP、SCP、HLR、VLR、IP、SMP、SMAP、SCEP等核心节点的职责与数据交互并详解SCP异地冗余设置及主备数据实时同步、SSP的OVERLAY与目标网两种组网方式的选型依据。系统功能方面涵盖电路与分组交换呼叫控制、USSD、短消息业务、补充业务通知、移动性管理、用户数据监控等基本和扩展能力接入矩阵结合EIRENE规范解析铁路调度中呼叫权限控制规则。全文为单独一篇doc文档约759KB便于离线阅读和标注。目前已有249人学习下载可作GSM-R技术学习、网络规划设计和铁路通信培训的参考材料。1. GSM-R智能网系统到底解决了铁路调度里的什么问题调度员按车次号呼叫一列行进中的动车司机用司机-本务这样的功能号接通列车刚跨过调度分界点呼叫就自动接到了新任调度台——这些手机号根本不透明的铁路业务靠的就是 GSM-R 智能网系统。它把电信网里业务与交换分离的思路搬进铁路专用移动通信网在 MSC/MSS 之上叠加 SSP/SCP 控制点通过 CAMEL 机制把呼叫暂时拦停、查一次业务库、改一次被叫号码或换一条路由再放回到交换网里继续接续。对铁路通信工程师来说它直接解决调度通信里找不到该找的人、接不到该接的台、紧急呼叫抢不通三个老大难问题。要想知道这套系统怎么落地、参数怎么设、什么环节最容易翻车下面的内容按架构、数据配置、信令调测到现场排障的顺序逐步展开。2. 移动智能网如何变成铁路专用GSM-R智能网的架构与业务映射2.1 智能网四类实体在GSM-R里各管什么智能网不是单独一台设备而是一套把接续逻辑从交换机里抽出来、集中控制的架构。GSM-R 智能网系统沿用智能网标准模型里的四类功能实体SSP 负责识别这个呼叫需要交给智能网处理SCP 负责执行业务逻辑比如查功能号表、做号码翻译SDP 负责存业务数据车次号与手机号的绑定关系、小区与调度区的对应表都在这里SCE 则用来在线编辑和下发业务逻辑。在工程实施中SCP 和 SDP 多数情况下合设为一台设备SSP 则由 MSC/MSS 兼任并不需要额外插一台独立交换机。GSM-R 智能网与公网移动智能网的最大区别在于业务重心。公网智能网里跑得最多的是预付费和彩铃对话模型是收到 InitialDP 后查余额、扣费、播放提示音GSM-R 智能网里则完全围绕调度身份来组织业务SCP 上的核心逻辑是收到呼叫信息后去查功能号表或者位置映射表返回一个真实可接续的号码。这个差异决定了后续所有数据配置的重心都落在号码变换和位置匹配上而不是计费账目上。理解这一点就明白为什么同一套 CAMEL 机制在两个网络里调测的侧重点完全不同。2.2 CAMEL 触发点智能网怎么接管一次 GSM-R 呼叫GSM-R 智能网对呼叫的接管依赖 CAMEL 机制核心是移动用户 HLR 里的 CSICAMEL 签约信息。MSC/SSP 会根据 HLR 下发的 O-CSI 和 T-CSI 中的触发点设置在呼叫的某个特定时刻暂停处理并向 SCP 发出 InitialDP 请求。GSM-R 工程里最常见的是两类触发触发类型通俗说法典型 GSM-R 业务关键数据O-CSI主叫拨号后被拦停主叫功能号预处理、呼出限制主叫 IMSI、主叫号码、被叫号码T-CSI来话到达被叫侧后被拦停功能寻址、基于位置的寻址被叫接入号、被叫号码、位置信息组合触发一次呼叫先后在主叫侧和被叫侧各拦一次号码分析 位置再分析两次 InitialDP 的 serviceKey 不同需要特别注意一次 GSM-R 智能网呼叫可能产生两次触发。主叫侧 O-CSI 先触发一次SCP 可以在这里判断主叫是否有权发起该业务后续被叫号码收集完成后由被叫侧 T-CSI 再触发一次SCP 这时才真正去查功能号绑定表或者位置映射表。很多初次调测的人只关注 T-CSI结果主叫侧数据没配信令跟踪里连第一次 InitialDP 都看不到。2.3 五类 GSM-R 业务落到智能网侧变成什么GSM-R 网络里的传统调度业务并不是全靠智能网才能实现但智能网能让它们从靠交换局数据硬顶变成靠业务逻辑灵活配置。工程上常见的业务映射有以下几类功能寻址把车次号功能码翻译成当前担当该功能的司机手机号SCP 返回的是真实 MSISDN基于位置的寻址根据呼叫所在的小区或位置区判定当前调度区再把呼叫接给对应调度台呼叫优先级识别 eMLPP 级别在智能网层面为高优先级呼叫提供排队和接续保障组呼 VGCS 和广播呼叫 VBS 则借助 SCP 下发的组成员列表和组 ID让 MSC 快速建立组呼信道。这里要澄清一个误区GSM-R 里的无线预占和 eMLPP 资源抢占由 BSS 和交换侧的 MLPP 机制完成智能网不负责抢信道。智能网在优先级业务里的角色是识别呼叫类别、决定是否排队、以及在呼叫接续参数中传递优先级标记。所以实际调测时千万别在 SCP 上试图去实现无线侧的抢占逻辑那是把两套不同层面的机制混为一谈了。3. 让业务跑起来的基础数据HLR签约、SCP数据与MSS触发配置3.1 HLR侧T-CSI/O-CSI签约一个配置片段看懂所有参数GSM-R 智能网的数据配置从 HLR 签约开始。没有 CSIMSC 就不会往 SCP 发 InitialDP后面一切业务逻辑都是空谈。下文给出一个设备无关的签约数据示例实际做数据时按厂商网管界面的等价操作完成// HLR CAMEL 签约数据示例按厂商网管界面等价操作理解 ADD CAMEL-SUB: IMSI460010312345678, T-CSI100, GSMSCF-ADDR86700210001, SERVICEKEY21, DEFAULT-CALL-HANDLINGRELEASE, TRIGGER-TYPET-CSI, TRIGGER-DPROUTING-ADDRESS-ANALYSIS;这段配置里值得逐一说明的参数有五个。IMSI 必须绑定用户唯一标识而不是 MSISDN因为 GSM-R 终端在机车和司机之间频繁换插按手机号签约很容易出现号在人不在的错配。T-CSI 是 HLR 里区分不同触发类别的编号它和 SCP 侧的业务键 SERVICEKEY 不一定相同两边映射关系要单独核对。GSMSCF-ADDR 填的是 SCP 的 GT 地址MSC 靠它做 SCCP 层寻址这个地址一旦写错信令直接走不到 SCP。DEFAULT-CALL-HANDLING 是 SCP 故障或超时情况下 MSC 的兜底动作取值只有 RELEASE 和 CONTINUE 两种。铁路调度通信里我一般建议选 RELEASE理由很直白调度呼叫宁可接不通也不能因为 SCP 故障把紧急呼叫错误接到一个不相干的普通用户那里。TRIGGER-DP 决定在呼叫的哪个阶段拦停常见做法把触发点设在路由地址分析阶段这样被叫号码已经收集完整SCP 拿着完整号码去查库才有意义。3.2 SCP业务数据功能号表与调度区映射怎么建SCP 侧数据是 GSM-R 智能网真正跑业务的地方。工程交付时最花时间的往往不是信令调测而是把两条业务表做扎实。第一条是功能号绑定表核心字段包括车次号、功能码、当前绑定 MSISDN、生效时间和失效时间。需要注意车次号与司机的绑定不是永久关系司机上车值乘时通过注册流程写入 SCP退乘后必须解除绑定否则调度呼叫会接到一个已经下班的司机手机上。第二条是位置映射表核心字段包括位置区编号 LAC、小区标识 CI、调度区编号和该调度区对应的调度台号码。建表时最容易忽略的是跨区覆盖场景一个小区覆盖扇区伸到相邻调度区边界列车在这个小区下呼叫按主服务小区映射会接错调度台。常见做法是把边界小区同时配置归属主调度区并加一条优先级字段让 SCP 按先精确小区、再位置区的顺序匹配。SCP 上业务数据的增加和修改一般通过 SCE 完成。3.3 MSS/SSP侧触发数据GT翻译与IMSI分析的核对项HLR 和 SCP 两侧数据都配好后MSS/SSP 侧还有几个核对项缺一个业务就起不来。第一是确认 MSC 的 IMSI 分析数据里对该号段启用了 CAMEL 触发否则 MSC 收到 CSI 也不会真的去触发智能网。第二是核对 SCCP 层 GT 翻译MSC 到 SCP 方向的路由要有一条SCP 回 MSC 方向的路由也要有一条这两条经常只配了一边。第三是确认两边配置的子系统号 SSN 一致SCP 侧 SSN 配置错误时MSC 发过去的报文会在 TCAP 层直接超时。再有一个是 CAMEL 版本配套。不同阶段版本的 MSC 和 SCP 在 InitialDP 里的字段支持度差异很大例如位置信息字段在 CAMEL2 里并非必选而基于位置的寻址业务必须要用这个字段。遇到SCP 侧收到了 InitialDP 但看不到小区号这类问题多半是版本协商后字段没带上。这些核对项全部过一遍后GSM-R 智能网才具备拨测条件下一步才能谈信令参数。4. 功能寻址一次呼叫的完整信令路径从InitialDP到Connect的关键参数4.1 功能寻址呼叫的信令路径每一步往哪看把 GSM-R 智能网的功能寻址业务跑一遍完整呼叫能直观看到信令参数在哪一步起作用。假设调度员要呼叫车次号 G1234 的司机拨号是接入码加车次号加功能码完整信令路径如下主叫 MSC 根据 O-CSI 触发智能网先向 SCP 发出一条 InitialDP携带主叫号码和原始被叫接入号。SCP 收到 O-CSI 触发的 InitialDP 后检查主叫权限然后返回 Continue告诉 MSC 继续收集被叫号码。MSC 完成号码收集后被叫侧 MSC 根据 T-CSI 触发第二次 InitialDP这时 SCP 才去查功能号绑定表。SCP 查到 G1234 当前绑定司机手机号后向 MSC 返回 Connect携带 destinationRoutingAddress 作为真正的被叫号码。MSC 按普通呼叫接续流程向该手机号发起寻呼呼叫进入正常的 GSM-R 语音通道。工程上我把这条路径当作 GSM-R 智能网调测的标准流。凡是功能寻址不通先按这个顺序查第一次 InitialDP 有没有发出、第一次之后有没有收到 Continue、第二次 InitialDP 有没有带上完整被叫号码、Connect 里的号码对不对。四次交互中任何一次缺失信令跟踪里一眼就能看出来不用靠猜。4.2 CAP消息关键字段locationInformation和destinationRoutingAddressGSM-R 智能网的信令参数主要集中在 CAP 消息里。调测时重点关注下面几个字段它们几乎决定了所有业务能否正确执行// CAP InitialDP 关键字段逻辑示意非真实 ASN.1 编码 { operationCode: initialDP, serviceKey: 21, imsi: 460010312345678, calledPartyNumber: 0089961234, callingPartyNumber: 00898654321, locationInformation: { cellGlobalId: 460-XX-LAC-CI, ageOfLocationInformation: 3 } }InitialDP 里的 serviceKey 是 SCP 识别业务逻辑的入口HLR 签约数据里的 T-CSI 和 SCP 的 SERVICEKEY 需要映射正确IMSI 和 calledPartyNumber 是 SCP 做号码翻译的输入locationInformation 中的 cellGlobalId 在基于位置的寻址里是核心判断依据MSC 必须把这个字段真实上报否则 SCP 不知道呼叫从哪个区来。Connect 消息里的 destinationRoutingAddress 是 SCP 翻译后的真实被叫号码这个号码的 TON/NPI 参数必须和 MSC 的路由分析数据一致不然交换机拿到号码后照样翻译不出去。4.3 超时、缺省动作与优先级传递三个方向的参数取舍GSM-R 智能网里还有一类参数不直接决定业务逻辑但决定业务稳定性。SCP 响应超时计时器就是最典型的一个MSC 发出 InitialDP 后SCP 需要在规定时间内返回 Continue 或 Connect超时后 MSC 按 HLR 签约数据里的 DEFAULT-CALL-HANDLING 执行兜底动作。这个计时器设多少需要权衡太短会让 SCP 负载稍高时就误释放正常呼叫太长则会让调度员在守候时觉得呼叫卡住了。我一般按厂商模板取 5 到 10 秒再结合 SCP 处理能力动态调整。另一个需要关注的参数是呼叫释放原因 cause。SCP 主动拒绝某一呼叫时会在 ReleaseCall 里携带 cause 值这个值最终会透传到交换机的呼叫记录里。工程上建议把 SCP 内各类失败场景的 cause 编码统一规划例如业务键错误、号码绑定不存在、位置映射失败各用不同 cause这样后续查话单和信令跟踪时不用逐条抓包就能快速归类故障。优先级传递方面需要单独提醒eMLPP 优先级在 CAMEL 对话里不是靠 SCP 控制无线资源的SCP 能做的是在 InitialDP 里读取呼叫优先级标记、决定是否让高优先级业务插队并在 Connect 后续接续时把优先级参数带回给 MSC。如果工程现场出现紧急呼叫被智能网排队排住了的问题大概率是触发条件里没排除高优先级呼叫类别而不是 SCP 本身业务逻辑有问题。5. GSM-R智能网现场避坑5个高发故障的定位与处置5.1 CSI 没下发导致呼叫根本不触发现场最常见的故障是HLR 里明明配了签约但拨功能号没有任何反应信令跟踪里连 InitialDP 都看不到。这类问题的原因是 VLR 里缓存的用户签约数据没更新或者终端入网时 HLR 尚未完成 CSI 下发还有一种情况是 MSC 的 CAMEL 版本较老只支持 O-CSI 不支持 T-CSI。解决办法是让终端做一次重新位置更新或者开关机强制从 HLR 拉取最新签约数据同时核对 MSC 的 CAMEL 功能开关。工程交付时我会要求核心网侧在割接后主动触发一次批量位置更新避免列车车载终端长时间不关机、带着旧签约数据一直跑。5.2 被叫号码的 TON/NPI 错配导致翻译翻车另一种高频故障是 SCP 返回的号码在信令里看着正确但 MSC 出局时路由失败呼叫直接释放。抓包分析会发现 Connect 消息里的 destinationRoutingAddress 携带的 TON/NPI 和 MSC 号码分析数据不一致。比如 SCP 按 unknown 格式返回号码MSC 侧则按国内号码规则分析两边对不上交换机自然不认。解决方法是全网统一编号计划SCP 侧返回号码时统一按 E.164 格式化TON 设为 national、NPI 设为 ISDNMSC 侧路由分析按同一规则配置。这个坑在功能寻址业务里尤其高发因为调度员拨的是接入码加车次号而 SCP 返回的是完整手机号码两者的号码属性天然不同。5.3 边界小区映射错位导致基于位置的寻址误判基于位置的寻址出现列车在 A 区却接到 B 区调度台的故障时多数人第一反应是小区表配错了实际查下来常常是边界小区归属模糊。GSM-R 网络里很多基站覆盖远端延伸到相邻调度区列车在边界地带的主服务小区可能一会儿切到 A 区、一会儿切到 B 区如果映射表只按 LAC 粗粒度配置就会出现误判。解决方法是位置映射表做到小区粒度配置 CGI 而不是只配 LAC并且把边界区域的越区覆盖小区明确归属到管辖区验收时安排列车在调度分界点往返跑两次对比两次呼叫接续的调度台是否一致。血的教训是边界场景永远不要拿单一地点的一次拨测结果下结论。5.4 双MSC共用SCP时GT翻译不一致组网规模稍大后GSM-R 智能网经常是两台 MSC 共用一台 SCP故障表现却很怪在 MSC1 下业务一切正常终端漫游或切换到 MSC2 后功能寻址完全失效。原因是 MSC2 侧的 SCCP 层 GT 翻译数据没配全或者 SCP 回程地址在 MSC2 上没有对应翻译更隐蔽的是两台 MSC 的 CAMEL 阶段版本不同MSC2 老版本不支持 SCP 下发的某个字段。排查时先在 MSC2 侧做 SCCP 环回测试确认 GT 路由双向可达再核对两端的 CAMEL 版本协商结果。SCP 侧也可以按 MSC 地址分别配置业务键避免不同 MSC 上报的业务数据互相干扰。5.5 紧急呼叫被智能网拦截引发优先级业务冲突最危险的一类故障是紧急呼叫被智能网拦住了。司机按下紧急呼叫后本应立即通过 eMLPP 预占资源接通调度台结果却没反应或者被排到队列里。查信令会发现紧急呼叫类别被 O-CSI/T-CSI 当成普通呼叫触发了智能网SCP 处理过程中的排队逻辑把高优先级呼叫给拖住了。解决方法是交换侧触发分析数据里必须把紧急呼叫类别排除在智能网触发条件之外让这类呼叫绕过 SCP 直通SCP 侧如需要识别优先级应通过 InitialDP 携带的优先级字段做快速放行而不是进入普通业务队列。任何涉及行车安全的呼叫都不应该依赖 SCP 的正常业务处理时长这必须作为一条硬性设计要求写进实施方案。6. 交付验收这样验证GSM-R智能网信令过滤与场景呼叫矩阵GSM-R 智能网系统验收阶段我一般不会只做拨个号打通就算过而是用两层验证兜底。第一层是信令级验证在 MSC 侧信令监测点抓 SCCP 承载的 TCAP 消息过滤出 CAP 报文重点核对关键路径上的三组消息HLR 位置更新后的 CSI 下发、呼叫触发时的 InitialDP、SCP 应答的 Connect/ReleaseCall。现场抓包时按一次呼叫的对话 ID 关联全部消息检查 InitialDP 里的 locationInformation 是否携带 CGI、Connect 里的 destinationRoutingAddress 的 TON/NPI 是否统一。第二层是业务级验证按场景矩阵逐项拨测不能只测正常路径还要测边界和异常路径。测试场景拨测方法预期结果信令核查点功能寻址调度台拨车次号功能码接通当前绑定司机InitialDP → Connect 号码是否与绑定一致基于位置的寻址列车在调度分界点两侧分别拨测分别接至对应调度台locationInformation 内 CGI 与映射表一致紧急呼叫模拟 eMLPP 最高优先级呼叫快速接通且不排队信令中无 SCP 拦截记录SCP 主备倒换主用 SCP 手动倒换新呼叫恢复且存量呼叫记录可查SCP 侧业务恢复时间达标验收现场最容易漏掉的是 SCP 负荷较高时的超时行为我会专门做一次断点测试在 SCP 侧临时把一条业务数据的查询延时调大观察 MSC 侧是否按 DEFAULT-CALL-HANDLING 正确动作。还有一次教训让我印象深刻功能寻址在测试环境一直正常上了真实列车环境就偶发接错调度台查了一个下午才发现是功能号绑定表里塞了两条数据动检车次和旅客车次绑到了同一个司机号上。从那以后我养成习惯每次验收前先让数据维护方导出一份绑定表做人工复核而不是直接扎进信令里查。验证 GSM-R 智能网先把数据看住再谈链路和信令顺序反了会多走很多弯路。希望帮到你。本文还有配套的精品资源点击获取