干了几年铁路通信的现场维护带新人爬基站的时候被问得最多的一个问题是“现在手机信号哪儿都有铁路上为什么还要单独建一张网”这个问题问到了点子上也正好戳中了GSM-R存在的理由。GSM-R 全称是全球铁路移动通信系统说白了就是一套专门给铁路运营用的数字移动通信网它在公网蜂窝制式的技术底子上加了一批铁路调度、列控、作业联络才需要的专用功能——功能寻址、语音组呼、优先级强拆、紧急呼叫、接入矩阵。它承载的不是普通的打电话而是调度指挥、车地数据、区间作业这些一旦中断就要影响行车安全的业务。我接触这套系统是从车地联调阶段开始的最开始连“为什么要给一台车载台配一个八位数功能号”都想不明白后来在调度台上看着一条条组呼建立记录才慢慢理清楚它整套设计逻辑不是把公网搬过来用而是把铁路的指挥关系、作业流程、优先级次序全部翻译成通信网络里的参数和数据结构。这篇文章我打算把 GSM-R 从头到尾拆一遍讲清楚它是什么、为什么这么设计、网络怎么搭、覆盖怎么算、现场常见故障怎么查。刚入行的通信维护人员看完能建立起完整框架已经做过公网优化的同行看完能把公网经验顺利迁移过来负责项目管理的人看完能明白哪些环节最容易出问题、进度该卡在哪里。1. GSM-R到底是一张什么样的网1.1 从模拟对讲到数字集群的换挡逻辑铁路早期的区间通信靠 450MHz 无线列调模拟制式。一个频点就是一个话路通话靠“抢话”——谁先按下 PTT 键谁说话几个人同时按下去就互相盖台谁也听不清。调度员想同时叫到几个车站值班员只能靠轮流喊喊一遍没人应答就再喊一遍。这套系统在车流密度低的时候是够用的车一多就顶不住呼叫排队、串音、私密性差、覆盖靠中继器硬撑出故障只能靠老师傅的经验和耳朵去判断网管上几乎看不到有用的数据。更要命的一点是它只传语音传不了数据。列车控制一旦上了等级车和地面之间必须实时交换报文位置、速度、限速、进路信息都要周期性地上传下达模拟系统接不了这个活。这是 GSM-R 上马的直接推动力铁路需要的不是“能打电话”而是“能按指挥关系建连、能按优先级抢占、能稳定传数据”的一张专用网。GSM-R 走的路线是数字蜂窝加专用集群。数字化的好处是语音质量稳定、抗干扰能力强、频谱利用率高蜂窝组网的好处是覆盖可以按需扩展隧道、桥梁、山区各有各的做法专用集群的好处是它继承了一整套铁路化的补充业务能把“调度员喊一列车”这件事变成网络里一次可控、可记录、可追溯的组呼建立过程。1.2 它和公网GSM差在哪几个地方很多人第一次听说 GSM-R下意识觉得“不就是 GSM 加个 R 吗”。从空口技术上看确实有大量继承关系——调制方式、时隙结构、信道编码这些都来自成熟的蜂窝标准设备形态也接近。但真正把两者区分开的是下面这几层东西。第一层是频段。铁路用的是专门的频段指配和公网 GSM900 不重叠避免和公众用户抢资源也避免公众话务把铁路业务挤掉。常见的几组划分我整理在下面这张表里各地管理机构的指配不完全一样实际项目里一定要以正式频率文件为准。频段类型上行MHz下行MHz典型用途说明铁路专用扩展频段876–880921–925早期铁路专用指配4MHz 成对铁路实际常用指配885–889930–934部分地区铁路网络实际使用公众蜂窝 900880–915925–960铁路业务不占用第二层是业务能力。公网 GSM 的核心业务是点对点呼叫铁路这边点对点只是基础真正的重头戏是组呼、广播、紧急呼叫、功能寻址。这些业务在协议栈里属于专用补充业务靠核心网里的组呼寄存器、智能网业务控制点配合完成公网设备根本没有这套逻辑。第三层是可靠性和优先级。公网基站挂了用户换个小区接着打铁路基站挂了可能直接导致区间失去联络。所以铁路侧的容灾设计、传输双路由、供电保障等级都更高。同时网络里内置了多级优先级和强拆机制紧急呼叫一旦发起可以抢占正在进行的低优先级通话这在公网里是不可想象的设计。1.3 一张网要背多少种业务规划阶段最容易被低估的就是业务种类的复杂度。一张 GSM-R 网络通常要同时承载下面这些业务而且它们的服务质量要求差别很大行车调度通信调度员与司机、车站值班员之间的点对点和组呼实时性要求最高允许的呼叫建立时延很短。列车控制数据车地之间的安全相关报文传输对丢包率和时延抖动极其敏感中断时间有硬性上限。调车作业通信编组站、货场内部作业人员与调车机之间的短距离通信频繁建连、频繁释放。区间作业联络工务、电务、供电等专业人员在区间内与驻站联络员通信终端多为手持台。应急通信突发事件时的紧急呼叫和现场指挥优先级最高需要能强制建立。列车尾部数据尾部装置的风压、状态信息回传属于低速数据业务。机车同步操控数据重载组合列车中主控机车与从控机车之间的指令传输。看清这张业务清单就明白了一件事GSM-R 的规划难点不在覆盖而在业务并存的资源调度。语音组呼会长时间占用信道数据业务要求持续在线紧急呼叫还要能随时插进来这三者之间必须靠参数和优先级设计来平衡。2. 几个必须吃透的核心技术点2.1 语音组呼VGCS调度一句话喊动一片车语音组呼是 GSM-R 最核心、也最能体现铁路特色的功能。它的工作方式和普通电话完全不同一个组呼由一个组标识定义组内成员分布在多个小区网络只在成员所在的小区分配下行信道上行信道则由组内成员共享采用“先按先得、后按排队”的方式抢占。这个设计的好处是频谱效率高。假设一个调度区段有 30 个组成员分散在 20 个小区如果按点对点开会需要 30 条独立链路用组呼只在下行各小区占用一条信道上行按需分配资源占用可能只有十分之一。建立过程大致是这样调度台发起组呼核心网收到后向组呼寄存器查询这个组的成员分布、组呼区域和属性配置然后向区域内所有基站下发组呼建立请求基站在空口广播组呼通知组内终端识别到自己的组标识后自动接入。整个链条里最容易出问题的环节是组呼寄存器数据配置和接入矩阵匹配这个后面讲故障排查时会重点说。实操中要注意的是组呼一旦建立就一直占用资源直到发起方释放。调度员喊完话忘了挂机这条信道会一直挂着把本小区可用的载频吃掉一个。我见过最离谱的一次一个车站在早高峰时段只剩一个空闲信道排查下来是前一天夜班调度台没释放组呼。所以调度台的挂机习惯和网络的空闲超时保护两头都要抓。2.2 功能寻址与位置寻址只记车次号不记手机号传统通信里你要打给谁就得知道谁的号码。铁路场景下这个逻辑行不通司机换了车次用户号码不变但调度员只认识车次号调度员要叫的是“这个区段里所有车”而不是某个具体的人。功能寻址解决的就是第一个问题。每台机车台、手持台除了用户号码之外还对应一个功能号功能号的编码规则里包含了车次、台类型等信息。调度员拨功能号核心网先去查这张映射表找到对应的用户号码再建立呼叫。车次一改只要更新映射关系调度台的拨号习惯完全不用变。这个设计的价值在于把人员调度和通信寻址彻底解耦。位置寻址解决的是第二个问题。调度员拨一个短号网络根据发起者当前所在的位置把呼叫自动路由到对应的管辖对象上。比如司机在某个区段里拨短号系统会根据当前小区归属的路局、区段自动接到对应的车站值班员或调度台。这中间依赖的是核心网里配置的位置区与管辖关系映射表配置错一个区段呼叫就会跑到隔壁站去这在联调阶段是高频问题。这两套寻址机制在协议里都属于专用补充业务配置数据量大、关联关系复杂。我的经验是联调之前一定要先做一张完整的对照表——车次、功能号、用户号码、所属区段、管辖关系五个字段一个都不能少联调时对着表现场核对比现场瞎猜效率高得多。2.3 优先级与强拆eMLPP紧急呼叫可以“插队”铁路通信网络里的资源是有限的突发情况下如果大家都平等竞争最紧急的那个呼叫反而可能建立不起来。多级优先级和强拆机制就是为这个场景设计的。网络里给每个用户和每个呼叫分配一个优先级等级等级高的呼叫在资源不足时可以先抢占低等级通话占用的信道把对方拆掉之后建立自己的连接。铁路紧急呼叫通常配置为最高等级一旦发起网络会强制释放所需资源。这里有个实操细节容易踩坑强拆不是无条件生效的。它受接入矩阵和组呼属性约束如果某个用户的优先级配置文件里等级没给对紧急呼叫发起时会静默失败界面上只显示“呼叫失败”看不出原因。排查这类问题的正确顺序是先查用户签约数据里的优先级等级再查组呼配置里的抢占策略最后才怀疑无线侧。另外优先级设计要克制。等级给得太随意会出现低优先级业务互相强拆的混乱局面。通常的做法是严格按业务性质分层紧急呼叫最高行车调度次之调车和作业联络再低一级普通数据业务最低。2.4 ACSI接入矩阵谁能进哪个组早就写死了接入矩阵是 GSM-R 里一个听起来很抽象、实际非常关键的机制。它定义了“哪个用户、在什么条件下、可以接入哪个组呼”本质上是一张权限表。举几个典型场景。某条线路的调度组呼只能由本区段的调度台和司乘人员接入其他区段的人不行某个应急组呼日常状态下不开放只有触发条件成立才允许接入跨局运行的车次在进入邻局管界时需要能接入邻局的组呼。接入矩阵配置错误的表现很有特点单机测试全部正常一到多车、多区段联调就出问题要么是别的车进不来要么是本该进不来的人进来了。因为单机测试时根本不涉及权限判断只有并发和跨区段场景才能暴露。提示接入矩阵的修改必须走版本管理。这张表改动一次影响面很大很多单位吃过“临时改一条忘了改回来”的亏。建议所有变更都留变更单联调结束后统一归档核对。3. 组网架构与覆盖设计怎么落地3.1 网络分层从核心网到车载台从架构上看GSM-R 可以分成四层理清这四层对排查故障特别重要因为不同层的症状差异非常明显。核心网层承担交换和业务控制主要网元包括移动交换中心、拜访位置寄存器、归属位置寄存器、鉴权中心、设备识别寄存器以及铁路特有的组呼寄存器。智能网业务控制点用来实现功能寻址和位置寻址这类业务逻辑短消息中心负责调度命令的下发。无线接入层包括基站控制器和基站收发信机。基站控制器管无线资源分配、切换控制、功率控制基站收发信机负责空口收发。这一层是现场维护人员打交道最多的地方。分组域由服务GPRS支持节点和网关GPRS支持节点组成负责承载列控数据、列尾数据这类分组业务。分组域的网络质量直接决定车地数据传输的稳定性。终端层包括机车综合无线通信设备、手持台、车载台、调度台。这里要特别提一下机车综合无线通信设备它通常集成多种通信制式把调度通信、列控数据、列尾查询等功能打包在一台设备里通过统一的操作显示终端给司机使用。这种集成设计降低了司机的操作复杂度但也意味着它的故障影响面比单一终端大得多。层级主要网元典型故障表现排查切入点核心网交换中心、位置寄存器、组呼寄存器呼叫全阻、寻址错乱签约数据、组呼配置无线接入基站控制器、基站局部无信号、切换失败小区状态、传输链路分组域服务节点、网关节点数据不传、时延突增附着状态、路由配置终端车载台、手持台、调度台单台异常、功能缺失终端日志、SIM 数据3.2 覆盖半径怎么算——一份链路预算模板覆盖设计是 GSM-R 工程里最考验基本功的环节因为它不能拍脑袋必须算。我把常用的链路预算逻辑完整写一遍你照着套就能用。先明确一个原则蜂窝系统的覆盖由上行链路决定因为移动台的发射功率和天线条件远不如基站。所以预算要重点算上行。假设一组常见参数手持台最大发射功率 2W换算成 33dBm手持台天线增益按 0dBi 取馈线损耗 1dB作业人员在车厢内或车旁使用时穿透和人体损耗合计取 12dB。那么手持台的有效等效辐射功率是 33 0 − 1 − 12 20dBm。基站侧定向天线增益取 15dBi馈线跳线损耗合计 3dB接收分集增益 3dB接收灵敏度按 −110dBm 取。那么允许的最大路径损耗就是允许路径损耗 移动台 EIRP 基站天线增益 − 馈线损耗 分集增益 − 接收灵敏度 20 15 − 3 3 − (−110) 145 dB拿到 145dB 这个预算值之后代入传播模型换算距离。开阔郊区和乡村场景常用的是 COST-231 Hata 模型频率 930MHz、基站天线挂高 40m、移动台高度 4m 的条件下代入后大致能解出 6km 左右的覆盖半径。要是换成机车台算8W 发射功率、顶部天线有 3dBi 增益、车体穿透损耗只算 6dB有效辐射功率能到 35dBm允许路径损耗直接拉到 160dB对应的距离超过 15km。这组数字说明了一个很实际的结论覆盖设计要以最弱的终端为准。如果服务对象里有大量手持台在区间作业覆盖半径就必须按手持台的结果来定通常是 5 到 8km 一档。如果整条线只服务机车台站间距可以适当放宽。当然还要留出阴影衰落余量、干扰余量再叠加地形修正最终数值一定要靠现场路测确认。注意上面这组参数是教学用的典型假设实际项目里的天线挂高、下倾角、地形地物差异很大。公式算出来的只是理论值千万别拿它直接当施工图用。3.3 隧道、桥梁、山区的差异化覆盖方案开放式区间算完半径基本就能布站了真正麻烦的是特殊区段这三类场景我分别说一下。隧道是 GSM-R 覆盖里最需要单独设计的部分。隧道内电波传播条件极差靠外面的基站打进去一般拐两个弯就衰没了。常规做法是在隧道内敷设泄漏电缆配合洞口的定向天线或者隧道内的射频拉远单元实现连续覆盖。泄漏电缆的开孔率和敷设高度直接影响覆盖均匀性敷设高度通常选在隧道壁中上部既避开车辆限界又保证车顶天线和手持台都能收到。隧道口的切换设计是另一个关键点洞口两侧的信号重叠区要够长否则进出隧道时切换失败率会明显升高。桥梁的问题不是衰减而是反射和多径。钢结构桥梁对电波的反射会造成严重的多径干扰表现为通话中偶尔出现断续、数据业务瞬时误码率升高。常见的缓解手段是调整附近基站天线的方位角和下倾角避免主瓣直接打向桥梁主体同时适当提高该区域的覆盖电平余量。山区的难点在阴影。山体遮挡会形成大片盲区靠提高发射功率解决不了因为在山这边功率再大也翻不过去。这类场景通常要在沿线选制高点设基站或者用小功率的射频拉远单元补盲。选址的时候要特别注意制高点基站虽然覆盖远但越区覆盖会干扰相邻小区的频率复用得配合下倾角和功率调整来控制。3.4 频率规划的硬约束铁路拿到的频率资源很紧通常是 4MHz 成对按 200kHz 载波间隔算下来也就 20 个左右的载频边缘还要留保护带实际可用 19 个上下。这点资源要覆盖整条线路规划上必须精打细算。基础的复用方式是按基站簇划分频率组一个簇几个站、每站几个扇区凑够一组互不冲突的频率。十几到二十个载频的资源量一般能做到每小区一到两个载频。广播控制信道必须单独规划相邻小区绝对不能同频否则终端会频繁重选表现为待机状态下反复占网、呼叫建立成功率下降。干扰控制上同频干扰保护比工程上通常按 12dB 左右取值邻频按 −6dB 左右取值这两个数值是规划软件仿真的约束条件。实际路测时如果某个路段的同频干扰电平超标优先级最高的处理手段是调下倾角压覆盖其次才是调功率最后才考虑改频。这个顺序别搞反了很多现场一上来就改频率结果把整个复用图案打乱问题从一个点扩散成一片。4. 典型应用场景与实操细节4.1 行车调度通信行车调度是整个网络里优先级最高、可用性要求最严的业务。典型流程是调度员通过调度台向管辖区段内的列车发起组呼司机应答双方在半双工或双工模式下通话通话结束后释放。这个场景里最关键的指标是呼叫建立时间。紧急情况下调度员喊一声司机要能在几秒内听到超出这个时间窗口业务价值就大打折扣。影响建立时间的因素按影响程度排序一般是核心网组呼寄存器查询耗时、组呼区域大小、空口寻呼重试次数。提示组呼区域不是越大越好。区域划得太大基站要同时建立大量下行链路建立时间会明显拉长资源浪费也严重。合理做法是按调度区段划分组呼区域跨区段的需求用跨区组呼功能单独处理。实操中还有一个容易被忽视的点是调度台的接入方式。调度台一般通过有线接口接入核心网这条有线链路如果走的是同一套传输网一旦传输出问题无线侧看着一切正常调度台却喊不出去。所以传输的双路由和独立供电在调度台这一侧比在基站侧还要重要。4.2 列控数据承载列控数据的承载是 GSM-R 里技术含量最高、容错空间最小的部分。车地之间要周期性交换安全相关报文包括位置报告、行车许可请求、限速信息等。这类业务的特点是数据量不大但对时延和丢包的容忍度极低中断时间超过规定上限就必须触发降级。网络侧要做的事情包括给列控业务预留专用信道资源、配置独立的分组数据网络标识和接入点、设置专用服务质量参数、在网络拥塞时保证它的优先级。现场常见的问题集中在两点一是分组域的路由配置二是无线侧的切换质量。切换是列控数据最容易出问题的地方。列车高速运行时一次切换的中断时间如果不达标车地通信会出现短暂断链。工程上的应对手段包括优化邻区关系、调整切换门限让切换发生在信号质量更好的位置、缩短切换判决时间。我个人经验是邻区表一定要定期核对线路改造、新增基站之后漏配邻区是最常见的原因而且它的症状很隐蔽——平时看不出来只在特定速度和特定位置才出现断链。4.3 调车作业与编组站调车作业的通信需求和行车调度差别很大。编组站里机车频繁启停、频繁换向作业人员站在车旁或者车上通话特点是呼叫次数多、通话时间短、建连和释放非常频繁。信号环境也复杂站场内钢结构、雨棚、接触网都会造成反射和遮挡。针对这类场景终端上一般会设计专门的调车模式简化操作步骤让作业人员戴着手套也能一键触发。网络侧则要保证站场内的覆盖电平足够均匀不能出现忽高忽低的区域。编组站的覆盖设计通常比区间更密站场内基站或者射频单元的数量明显更多目的就是把电平做平。这类业务还有一个特殊需求是私密性。调车作业的指令直接关系人身和车辆安全不允许无关人员接入组呼。这就要靠接入矩阵严格控制成员范围同时定期核对人员变动后的权限数据。4.4 区间作业、应急救援与列尾区间作业通信服务的是工务、电务、供电这些专业的一线人员。他们通常手持终端在区间内移动与驻站联络员保持联络。这个场景对覆盖的连续性和手持台的上行能力要求很高因为人员会走到离基站较远的位置甚至会临时进入隧道或者桥下。实际维护中我遇到过好几次“机车台通话正常、手持台在某个里程点就是喊不出去”基本都是手持台处于上行受限区解决办法是在那个区段补一个射频单元或者调整天线方向。应急救援场景的核心是紧急呼叫。紧急呼叫触发后网络会按最高优先级建立连接并强制释放所需资源。这个功能的可靠性必须定期验证不能等真出事才发现不好用。我建议每个季度做一次全流程演练从终端触发到调度台接通把每一步的耗时记录下来一旦发现耗时比上次明显增加就要提前查原因。列尾数据是比较容易被忽略的一块。列车尾部装置需要把风压等状态信息回传给司机属于低速数据业务通常走分组域。它的特点是终端位置固定在列车尾部会随列车跑遍整条线路所以对全线的分组域覆盖连续性有要求。排查这类问题时要特别注意它和列控数据走的是同一个分组域如果某段路列控数据正常而列尾数据异常问题大概率在终端的会话配置上而不是网络覆盖。5. 常见故障与排查实录5.1 呼叫类故障呼叫类故障是现场遇到最多的一类我把几种典型症状和对应原因整理一下。症状一拨打功能号呼叫失败但拨用户号码正常。这说明空口、基站、交换都通了问题出在寻址上。排查顺序是先确认功能号映射表里有没有这个车次的记录再确认记录对应的用户号码是否正确最后确认映射关系有没有随车次调整及时更新。车次调整后忘记更新映射是这类故障的头号原因。症状二组呼建立后部分成员听不到。这是典型的接入矩阵或组呼区域配置问题。先确认听不到的那部分成员是否在组呼区域内再查他们的签约数据里有没有这个组的接入权限。跨局运行的车次最容易出这个毛病因为两个局的组呼区域边界和权限配置往往不统一。症状三紧急呼叫发起后无响应。先查发起终端的优先级等级配置很多情况下是等级没给到最高再查网络侧紧急呼叫的抢占策略有没有启用。这两个都正常的话才去查无线侧的资源是否被完全占满。5.2 切换与掉话类故障切换问题最典型的表现是固定位置掉话。列车每次开到某个里程点就掉一次换别的车次也掉这种规律性极强的现象几乎可以锁定为切换失败。排查的第一步是导出该位置的切换测量报告看目标小区的电平是否满足切换门限很多情况下问题就是漏配了邻区。第二种表现是随机掉话没有固定位置。这类问题排查难度大得多需要结合后台的呼叫记录和路测数据分析。常见原因包括上下行链路不平衡、外部干扰、基站传输瞬时闪断。判断上下行是否平衡有个简便方法看基站侧的接收电平和终端侧的上报电平差值如果超过正常范围基本可以确认不平衡。第三种表现是切换成功但通话质量骤降。这类问题通常指向目标小区存在同频或邻频干扰。这时候要回到频率规划那一层去查看该小区与周边小区的频率关系是否合理必要时调整下倾角先压覆盖。5.3 数据业务类故障数据业务的故障排查和语音不一样它有一套固定的检查顺序终端附着状态、分组域路由、服务质量参数、空口质量。终端根本无法附着通常是签约数据里没开通分组业务或者终端的分组数据配置参数不对。附着成功但业务建立不起来一般是接入点名称配置错误或者分组域到应用侧的专线不通。业务能建立但时延抖动大就要看服务质量参数有没有配好以及空口有没有干扰。这里要分享一个我踩过的坑。有段时间某区段列控数据偶尔中断语音完全正常查了半天无线侧没问题。最后发现是分组域的一台设备在做定时重启重启窗口很短语音业务不受影响但列控数据的会话会被打断。这类问题的启示是语音正常不代表网络正常排数据故障一定要看核心网的设备日志和告警不能只看空口指标。5.4 排查速查表把上面这些经验整理成一张表现场可以直接对着查。现象优先排查项次要排查项现场验证方式功能号呼叫失败功能号映射表用户签约数据改用用户号码拨测组呼部分成员听不到接入矩阵、组呼区域成员签约数据逐台终端拨测固定点掉话邻区关系切换门限导出切换测量报告随机掉话上下行平衡、干扰基站传输质量后台呼叫记录加路测数据业务时延大服务质量参数空口干扰抓包看往返时延数据业务偶发中断核心网设备日志分组域路由核对设备重启记录手持台区间喊不出上行覆盖电平天线方向角按里程逐点路测隧道内通话断续泄漏电缆状态洞口切换重叠区隧道内全程拨测6. 从GSM-R往下一代走运维要注意什么6.1 为什么会有下一代铁路移动通信GSM-R 这套技术底子是几十年前的能撑到今天靠的是稳定性和成熟度。但它确实有天花板频谱资源紧张4MHz 的带宽要同时扛语音和数据越到后期越吃力分组域的数据能力有限面对未来更密集的车地数据交互余量不够产业链在逐步收缩专用终端的供应和备件越来越难保障。于是行业里推进下一代铁路移动通信系统的研究和试点技术路线上普遍转向基于新一代宽带移动通信的方案目标是把语音、数据、甚至视频业务统一到一张网上承载。这件事对一线维护人员的实际影响是未来很长一段时间内会是两套系统并存的过渡期。6.2 双网共存期的常见坑过渡期最典型的形态是双模终端加双套网络。机车综合无线通信设备同时支持原有制式和新制式根据线路覆盖情况自动或手动切换。这个阶段最容易出问题的地方有三处。第一处是切换逻辑。线路上一段有新网、一段只有旧网终端在两段之间来回切的时候如果切换门限设置不合理会出现频繁来回切换甚至卡死的情况。调试时的重点是把两套网络的边界区域切换门限拉开足够的迟滞。第二处是数据业务的分流。有些线路把列控数据放在新网上试点调度语音还留在旧网上这就导致一次故障可能涉及两个体系的排查故障定位时间明显变长。这时候一定要提前梳理清楚业务的分布图标注每条线路、每类业务跑在哪张网上。第三处是备件和培训。新老终端同时存在现场人员如果不熟悉新设备的操作和告警含义处理效率会明显下降。我建议双网共存一开始就要同步做培训而且培训要按岗位分开做司机关注操作、调度关注呼叫流程、维护人员关注告警和参数一张 PPT 讲所有岗位效果最差。6.3 给一线维护人员的几条建议最后说几句我自己的体会都是从现场摔打出来的。第一参数和配置要留档而且要和现场实物对上。我见过太多项目图纸上一套、网管里一套、实际设备上又是另一套出了故障三方对不上白白耽误几个小时。每次施工或者变更之后必须更新一次台账哪怕只是改了一个天线的下倾角。第二把例行测试做实别走过场。紧急呼叫、组呼建立、关键区段的数据连通性这些测试项目每次做完都要留记录和耗时数据。数据是纵向对比出来的某一项耗时连续两次上升往往就是故障的前兆。第三多和一线使用者聊天。司机、车站值班员、调度员对通信异常的感知比网管告警还灵敏他们嘴里一句“最近某某地方说话有点断续”往往能让你提前发现一个还没触发告警的隐患。我处理过的几次隐患最早的线索都来自这些闲聊。第四别迷信指标要信现场。后台统计的呼叫成功率漂亮不等于体验好短时断续、瞬时丢字这些小毛病不一定体现在统计报表里。定期的乘车路测比看一百张报表都管用。我到现在还是保持着每条新开通线路头三个月每月跟车跑一趟的习惯很多问题就是在车厢里坐着听出来的。