企业官网建设流程全解析

简介：《中兴RNC系统结构介绍.ppt》是一份面向TD-SCDMA网络运维、优化及研发工程师的技术讲解材料，系统梳理中兴通讯ZXTR RNC V3.0无线网络控制器的整体架构。内容从3GPP R4协议背景出发，说明RNC在核心网与Node B之间的承上启下作用，以及控制面/用户面分布式扩展、大容量资源框等设计特点。全文共1个PPT文件，大小6.8MB，属于单文件精讲型资源。已有182人学习，适合作为RNC硬件与组网入门的快速参考。PPT按“系统概述—硬件系统—功能机框—单板介绍—数据流程—配置与组网”展开，重点讲解电源/风扇/业务/走线插箱组成，APBE、SDTB、DTB等接入单板的接口与容量，ROMB、CLKG操作维护单板职责，以及两级交换子系统如何完成信令与业务数据交换。通过这份资料，读者可以掌握各单板功能职责、接口接入方式和数据流向，理解从单资源框到百万用户级组网的容量演进逻辑。

1. 这是给刚接手 TD 项目的人看的：RNC 系统结构到底解决什么问题

一份讲中兴 ZXTR RNC 系统结构的 PPT，对现在的 5G 工程师来说可能觉得过时，但如果你在运营商侧做过 3G 存量网络运维，或者刚转到无线网络控制器调测岗位，会发现 RNC 的系统结构思路至今没变：控制面与用户面分离、两级交换、分布式处理、板卡主备。这套设计直接影响了后来 VoLTE 的 IMS 架构和 5G 核心网的服务化架构，搞懂它，等于补上了移动核心网演进里最关键的承上启下的一环。这份资源讲的是中兴通讯基于 3GPP R4 协议研发的 TD-SCDMA 无线网络控制器，适合刚接手 TD-SCDMA 网络维护、需要写开站报告或做板卡扩容的工程师，也适合做核心网产品对比选型的人拿来当架构参考。

2. 先把 RNC 的角色说透：为什么它是“承上启下”而不是“中间转发”

2.1 RNC 在无线接入网里的定位：一头接核心网，一头管 NodeB

ZXTR RNC 在 3GPP R4 协议体系里属于无线接入网（UTRAN）的控制节点。往上，它通过 Iu-CS 接口连到 MSC（电路域核心网），通过 Iu-PS 接口连到 SGSN（分组域核心网）；往下，它通过 Iub 接口管理 NodeB，通过 Uu 空中接口与 UE 完成 L1 以上的协议处理。注意这个“L1 以上”——物理层的处理在 NodeB 完成，但 MAC、RLC、PDCP 这些层二协议和 RRC 层三信令都在 RNC 终结。也就是说，用户的无线资源调度、连接管理、移动性管理，实际控制点都在 RNC。

很多刚入行的人容易把 RNC 理解成“转发设备”，这是错的。它不是一个透传节点，而是要终结协议栈、做资源分配的设备。比如用户从小区 A 切到小区 B，RNC 要判断目标小区资源是否够、要不要做 Iur 口重定位；比如用户发起 PS 业务，RNC 要决定是走 DCH 信道还是 HSDPA 共享信道，这涉及 RRC 连接建立、无线承载建立、Iu 口 RAB 分配，每一步都是 RNC 在处理。所以 PPT 里说“承上启下的关键地位”，不是客套话——RNC 挂了，整个无线接入网就是瘫痪状态。

2.2 分布式控制面和用户面：一条容量线性增长的路

ZXTR RNC 在设计上有一个核心决策：控制面和用户面全部采用分布式架构。什么叫分布式？就是没有一块中央主控板去处理所有事情，而是把信令处理分散到多块 RCB 板上，把用户面协议处理分散到多块 RUB 板上。用户量上升后，通过增加单板就能实现容量线性增长，整个系统没有集中处理的瓶颈点。

这个设计和早期的 GSM BSC 有本质区别。GSM BSC 时代，很多厂家做的是集中式交换架构，所有呼叫都经过中心交换网，容量到顶就要换整框设备。ZXTR RNC 的做法是：控制面的 RANAP/RNSAP/NBAP/RRC 信令处理由 RCB 板分担，用户面的 FP/MAC/RLC/UP/PDCP/GTP-U 协议栈由 RUB 板分担，两块板都接在二级交换子系统的以太网口上，新增用户就加板，流量上去就加交换容量，不用动整框架构。

容量参数值得记一下，PPT 给了明确的数字：单资源框最大支持 7.5 万话音用户加 7.5 万分组域用户，最大支持 3750 爱尔兰话务量或 225Mbps 数据吞吐量。注意“或”字——3750 爱尔兰和 225Mbps 是两种极限场景，语音密集型场景卡在爱尔兰数，PS 密集场景卡在吞吐量，两者混跑时实际容量要打折扣。整个系统通过机框和机架扩展，最大可以到 100 万用户。这个扩展路径是关键：不是换设备，而是加资源框、加交换框、加控制框，通过二级交换子系统把各个框连起来。

2.3 两级交换子系统的分工：40G 核心交换和百兆汇聚各干各的

ZXTR RNC 的交换单元由两级组成，这个两级设计很多人第一次看会绕晕，我拆开讲。

一级交换子系统是一个容量 40Gbps 的核心交换平台，由 PSN 交换网板和 GLI 线卡组成。它负责 RNC 内部各个功能实体之间的大流量数据交互，包括语音业务、数据业务的承载通道，还负责根据业务要求提供 QoS。二级交换子系统就是以太网交换芯片，负责把控制面数据和用户面数据做汇聚和交换，对应的是 UIMC、UIMU（GUIM）和 CHUB 单板。

为什么搞两级而不是一级大交换？核心原因是流量模型差太多。控制面信令是小包、低频、高实时性要求；用户面业务是大流量、持续、有 QoS 等级差异。把两种流量放在同一个交换平面上，要么交换机要做得很大很贵，要么互相干扰。ZXTR RNC 的方案是：系统内提供两套独立的交换平面，控制面数据走二级交换子系统的百兆以太网汇聚，用户面数据走一级交换子系统的千兆通道。控制面流量小，不需要 40G 大平台；用户面流量大，需要一级交换来保证 QoS 和带宽。

PPT 里还提了一个很实用的工程配置原则：系统只有两个资源框时，用户面可以不采用一级交换子系统；系统资源框数量在 2 到 6 个之间时，用户面采用两块 GLI 线卡完成一级交换平台功能；资源框更多时才需要扩容 PSN。这个原则后面做配置和扩容时会直接用到，建议先抄下来。

2.4 与外部接口：Iub、Iu-CS、Iu-PS、Iur，各自管什么事

RNC 的接口关系在 PPT 的上下文图里画得很清楚：Ethernet、IPOA、Iub、Iu-PS、Iu-CS、Iur、Uu。Iub 是 RNC 到 NodeB 的接口，承载 NBAP 信令和用户面的 FP 帧；Iu-CS 到 MSC，承载 RANAP 信令和 AMR 语音帧；Iu-PS 到 SGSN，承载 RANAP 信令和 GTP-U 数据包；Iur 是 RNC 之间的接口，用于 RNSAP 信令和用户数据的重定位，实现 RNC 间的软切换。

注意 Iur 不是所有网络都会开的。两个 RNC 之间的软切换如果没有配置 Iur，UE 要从 RNC1 切到 RNC2，只能走核心网的 Iu 口重定位，切换时延明显变长。所以很多现网为了省传输资源不配 Iur，但这意味着跨 RNC 切换体验变差。做 Iur 配置时要算清楚：Iur 走 ATM 还是 IP，带宽预留多少，时延预算能不能满足软切换要求，这些不是拍脑袋定的，要看 NodeB 配置和 UE 移动模型。

3. 硬件系统拆解：四个插箱到八类单板，一次讲清

3.1 机架与插箱：电源、风扇、业务、走线，安装顺序有讲究

ZXTR RNC V3.0 的硬件基于中兴 3G 统一平台设计，机架结构从上到下分为电源插箱、风扇插箱、业务插箱、走线插箱。这个顺序不是随便排的：电源插箱放顶层利于散热和布线，风扇插箱紧贴业务插箱送风，走线插箱在底部方便光纤和 E1 线缆的走线路径。

安装时最容易踩的坑是风扇插箱的风向搞反。RNC 设备的散热路径是从底部走线区进风、顶部出风，风扇插箱的风向必须和机柜进风方向一致。如果你把风扇模块装反了或者插箱方向转 180 度，开箱后温度告警很快会起来。每次安装完，检查风扇模块的指示灯和监控面板上的风道状态，PWRD 板会上报风机状态，别等到宕机了才发现热量堆积在业务插箱里。

业务插箱是核心承载区，功能单板都在这里。插箱的槽位分布有讲究：有些槽位是固定给特定单板类型的，比如控制框的槽位和资源框的槽位不能混插。上电前先核对背板丝印和单板丝印是否匹配，不要靠板卡外观看。RNC 单板的拉手条上有防呆设计，但不同类型的单板可能外形相似——APBE 和 APBI 外观接近，插错槽位会直接打背板或导致单板不上电。

3.2 功能单元划分：接入、交换、操作维护、处理、监控各司其职

RNC 功能框内部按功能划分了五个单元。接入单元负责 Iub、Iu、Iur 接口的 STM-1 和 E1 接入；交换单元负责协议和数据的中心交换；处理单元负责控制面信令和用户面信息的处理；操作维护单元负责操作维护信息处理；外围设备监控单元负责电源、风扇、环境监控。这五个单元的关系是：接入单元把外部接口的 ATM 信元或 IP 包收进来，交给交换单元分发给处理单元处理，处理完再通过交换单元送回接入单元发出去，操作维护单元负责盯着这一切，监控单元管环境。

这种功能划分的好处是故障隔离。如果某块 RUB 处理板挂了，只影响它承载的那部分用户，其他板卡照常工作；如果时钟板 CLKG 挂了，全系统同步都会出问题，但接入单元的单板不一定能发现是时钟问题——这就是为什么操作维护单元要单列出来，ROMB 负责收集各单板状态和告警，全网时钟问题第一时间会反映在 ROMB 的告警列表里。

3.3 接入单元单板对比：APBE、APBI、DTB、SDTB、GIPI 怎么选

接入单元是外部接口的入口，PPT 列了五种单板：APBE、APBI、DTB、SDTB、GIPI。这五种板卡的分工和参数直接决定了传输侧怎么接。

先用一张表把参数列清楚：

选型逻辑很简单：传输条件好、带宽需求大的场景选 APBE，一对 STM-1 光纤就搞定；传输资源紧张、只有 E1 线路的场景选 DTB+APBI 组合，用 IMA 协议把多路 E1 捆绑成一个逻辑链路；纯 IP 传输场景选 GIPI，直接连 IP RAN 网络。现网中很多站点是混合配置——Iub 口用 APBE 走 ATM，Iu-PS 口用 GIPI 走 IP，这不是乱配，是因为 SGSN 侧的 IP 承载已经成熟，而 NodeB 到 RNC 的历史传输还是 ATM。

APBI 的处理能力参数要特别注意：它标称 622M，但处理 AAL2 的能力只有 310M，处理 AAL5 是 620M，混合处理时只有 400 到 500M。也就是说，一个 APBI 板如果既跑语音（AAL2）又跑数据（AAL5），实际可用吞吐量不是你想象的 622M，而是 400 到 500M。做传输容量规划时按 400M 算，留足余量，不然峰值流量时板上处理能力不够，会直接丢包。

3.4 交换、处理、操作维护、监控单板各自管什么

交换单元分一级和二级两级。一级交换板是 PSN 和 GLI，PSN 是核心交换网板，GLI 是线卡，负责把 40Gbps 交换能力引到各个资源框。二级交换板是 UIMC、UIMU（GUIM）和 CHUB，负责框内的百兆以太网汇聚。注意 UIMC 和 UIMU 的名字非常容易记混：UIMC 里的 C 是 Control，管控制面汇聚；UIMU 里的 U 是 User，管用户面汇聚。装板的时候看清拉手条上的丝印，UIMC 插到用户面槽位虽然能上电，但汇聚逻辑是不对的，数据流会走错平面。

处理单元是 RCB 和 RUB。RCB 处理控制面协议栈，包括 RANAP、RNSAP、NBAP、RRC 和 No.7 信令；RUB 处理用户面协议栈，CS 业务的 FP/MAC/RLC/UP，PS 业务的 FP/MAC/RLC/UP/PDCP/GTP-U。这里有个知识点：分组域用户面的 GTP-U 终结在 RNC 而不是 SGSN？不对，GTP-U 隧道是 RNC 和 SGSN 之间的，RUB 板处理的是 GTP-U 的封装和解封装，隧道端点在 RNC 侧。理解这一点，你做 Iu-PS 数据流分析时就知道该在 RUB 板上抓包还是去 SGSN 侧抓包了。

操作维护单元包括 ROMB 和 CLKG。ROMB 是全局运维代理，负责收集各单板状态、维护全局静态数据，还可能跑 RPU 模块处理路由协议。CLKG 负责时钟供给和外部同步。外围监控单元包括 PWRD 和告警箱 ALB，PWRD 通过 RS-485 总线收集电源分配器和风机的状态以及温湿度、烟雾、水浸、红外告警，每个机柜一块，所有环境数据上报给 ROMB。

4. 关键单板深入：APBE、RCB、RUB、ROMB 是怎么协同干活的

4.1 APBE 的 ATM 终结过程：从物理接口到 AAL2/AAL5 业务流

很多人对“APBE 完成 AAL2 和 AAL5 的终结”这句话没概念，我展开讲一下。ATM 的传输机制是：物理层 STM-1 帧里承载 ATM 信元，每个信元 53 字节，5 字节头 + 48 字节载荷。ATM 适配层（AAL）负责把上层业务映射到信元里——AAL2 用于语音这类实时小包业务，AAL5 用于数据类大包业务。APBE 板做的事情就是把 STM-1 物理接口上收到的 ATM 信元解出来，识别 VPI/VCI 对应的业务类型，把 AAL2 的语音帧送到 Iub/Iu 的 AAL2 通道，把 AAL5 的信令或数据包送到对应处理板。

按 VPI/VCI 做业务分流是 RNC 数据流分析的核心。Iub 接口上，每个 NodeB 的 NBAP 信令有一个固定的 VPI/VCI 通道，用户面的语音和数据也有各自的 AAL2 通道。APBE 板维护着一张 VPI/VCI 映射表，这张表由 ROMB 下发。日常故障排查时，如果某个 NodeB 的语音业务不通但数据业务正常，大概率是 APBE 板上对应的 AAL2 通道配置被误删或 VPI/VCI 被其他业务占用，这时用网管查 APBE 的通道表，很快能定位。

4.2 RCB 和 RUB 的分工边界：信令和用户面在哪一步分开

RCB 和 RUB 的分工边界，一句话讲清：控制面的 RRC/NBAP/RANAP 信令由 RCB 处理，用户面的语音帧和数据包由 RUB 处理。但实际数据流没这么简单——RRC 信令是 UE 经过 NodeB 的 FP 帧封装后通过 AAL5 通道传到 RNC 的，这些信令帧在 APBE 上解出来，走二级交换的百兆以太网到达 RCB。用户面语音帧走 AAL2 通道，同样在 APBE 上解出来，但走的是另一条路径——经过用户面交换平面到 RUB 板。

也就是说，同一个 APBE 板上，AAL2 通道和 AAL5 通道的数据在接入单元就分流了，之后走两套独立的交换平面。这就是为什么控制面和用户面分离在 RNC 里能做到：物理接口共享接入板，但从接入板往后的所有路径都是各自独立的。做排障时，信令通但业务不通，检查 RUB 板状态和用户面交换链路；业务通但切换失败，检查 RCB 板状态和控制面链路。有了这个分层思维，定位问题能少走很多弯路。

4.3 ROMB 的全局运维代理职责：静态数据管理、各板状态收集

ROMB 单板在 RNC 里的角色像是一个“运维总管”。它负责管理整个 RNC 的全局静态数据，比如小区的配置参数、NodeB 的标识、传输通道的 VPI/VCI 规划，这些数据在系统初始化时由 ROMB 加载，然后下发给各块单板。它还负责各单板状态的管理和信息搜集——每块板的运行状态、告警信息、性能数据都汇总到 ROMB，然后统一上报给 OMC-R。

ROMB 上跑 RPU 模块负责路由协议处理，这意味着 ROMB 在 IP 化组网中还是一个路由节点。RNC 内部的 IP 网段、外部 OMC-R 的网段、其他 RNC 的互联网段，这些路由都由 ROMB 维护。做 IP 化改造或者 RNC 间 Iur 口配置时，ROMB 的路由表是必须检查的项目。常见问题是：Iur 口物理链路通，但两个 RNC 之间 ping 不通——大概率是 ROMB 上的静态路由没配或者下一跳地址写错了。

ROMB 与 OMC-R 之间的通信链路是 HUB 连到交换单元的以太网口，这条链路如果断了，你会发现 OMC-R 上报不上告警，但 RNC 业务是正常的。很多新手遇到“网管看不到设备状态”就直接怀疑 RNC 整机故障，其实先查 ROMB 到 OMC-R 的链路连通性，往往几秒钟就能确认。

4.4 主备与负荷分担：哪些板必须 1+1 备份，哪些能负荷分担

ZXTR RNC 的关键部件全部提供硬件 1+1 备份，RUB 采用负荷分担方式，接入单板按需配置主备。这个设计原则直接决定了你在做板卡配置时怎么选型。

1+1 备份的单板包括 ROMB、RCB、UIMC、GUIM、CHUB、PSN、GLI。这些板卡的作用都是全局性的：ROMB 挂了全局管理就没了，RCB 挂了所有 RRC 信令都断了，PSN 挂了整个用户面交换就瘫了——所以它们必须实时热备。RUB 是处理板，业务分散在多块 RUB 上，一块板挂了只影响它承载的那部分用户，通过负荷分担机制把用户分散开就行，不需要一对一备份，但要保证有一定裕量，板卡故障时剩余板卡能承载全部业务。

接入单元的备份策略最有讲究：APBE 板可以 1:1 备份，备份方式可以是主备倒换也可以是负荷分担。主备倒换的场景是某个 STA 或多个 NodeB 的流量只走主用板，备用板空载；负荷分担方式是业务分散在两块板上，一块挂了另一块接管所有业务。建议日常配置用负荷分担，既利用了两块板的处理能力，又实现了热备，一举两得。

5. 常见问题排查：单板状态、链路告警、容量规划里的血泪经验

5.1 现象：单板状态显示“不在位”，但明明插着板

新装机最常遇到的情况是：板卡明明插在槽位上，但网管上状态是“不在位”或“未激活”。排查思路：先确认单板型号和槽位是否匹配——控制框的槽位只接受 RCB、ROMB、CLKG、UIMC、UIMU 这类板卡，你把 APBE 插到控制框的槽位上，背板总线类型不对，板卡根本不会上电。再查单板的版本是否和系统软件版本兼容，V3.0 的系统如果插了一块 V2.0 的接入板，可能启动到一半就拉不起业务单板。

还有一种常见情况是背板槽位的地址线接触不良。RNC 单板通过背板总线识别槽位号，如果背板有氧化或者灰尘导致个别引脚接触不好，单板启动时读不到正确的槽位地址，就会上报“不在位”。处理办法：拔出单板，用橡皮擦清洁背板金手指，重新插拔一次。如果反复出现同一槽位报不在位，换一个槽位试——大概率是那个槽位的背板地址线有物理损伤。

5.2 现象：UIMC 和 UIMU 装反，控制面数据跑到用户面平面

这个错误非常隐蔽。UIMC 和 UIMU 的外观相同，丝印只有一个字母的差别。如果工程队在安装时把 UIMU 插到了控制面的槽位上，系统启动后不会立刻报错，因为板卡能上电、能注册，但控制面信令的汇聚路径就乱了——信令报文从 APBE 出来，经过二级交换走到了用户面平面，RCB 板上收不到任何信令。

处理办法：核对槽位规划表，把 UIMC 换到控制面槽位、UIMU 换到用户面槽位，然后重启系统。从那以后，我每次做板卡安装验收时，都强制要求施工队按槽位规划表逐槽核对丝印，拍照片存档，杜绝凭“长得一样就随便插”的侥幸心理。

5.3 现象：E1 链路全部告警，但物理线缆是通的

接入单元配了 DTB+APBI 的组合，E1 线也接好了，但网管上报一堆 E1 链路告警。排查步骤：先在 DTB 板侧看 E1 物理层状态——LOS（信号丢失）还是 LOF（帧失步）。如果 LOS，说明 E1 线没信号，检查 DDF 架上的对接头是否拧紧、同轴线是否断裂；如果 LOF，说明物理信号有但帧同步不上，多半是两侧的 E1 时钟配置不一致，RNC 侧用内时钟，对端传输侧用了环路时钟，两个时钟打架。

如果物理层正常但 IMA 组起不来，检查 APBI 板上 IMA 组的配置：每个 IMA 组绑定了几条 E1，链路成员是否都加入了 IMA 组，IMA 组的帧格式是否匹配。常见问题是链路成员配置不一致——一侧 IMA 组绑定了 4 条 E1，另一侧只绑了 3 条，IMA 协议协商失败，这个组直接不能用。

5.4 现象：话务量还没到 3750 爱尔兰，CPU 占用率先爆了

容量规划最容易翻车的地方在于：3750 爱尔兰和 225Mbps 是理论峰值，不是实际可用值。实际画负载时，要考虑三件事：一是 RUB 板的协议处理能力是有限的，每块 RUB 板能承载的语音用户数有上限，7.5 万用户不可能是几块板撑起来的，需要按每块 RUB 的规格反推需要的板卡数量；二是控制面 RCB 板有信令处理能力限制，呼叫建立成功率低时，往往不是无线问题，是 RCB 板信令处理过载了；三是 APBE 板的 AAL2 混合处理能力只有 400 到 500M，不是标称的 622M。

我的习惯是：先按峰值话务量的 70% 配置处理板卡，再按 100% 配置传输带宽。如果话务模型是数据为主的，按单用户 64kbps 到 128kbps 估，再看 RUB 板是否够；如果语音为主，算爱尔兰数和 RCB 信令数。RUB 板是负荷分担的，但负荷分担不是会自动均衡——系统会基于各板负载做动态分配，但如果你新加一块 RUB 板但不启动它承载业务，它就是个摆设，要确认新板已加入资源池。

5.5 现象：Iur 口配置后，RNC 间软切换成功率反而下降

两个 RNC 之间开了 Iur 口，配置了 RNSAP 信令链路和数据承载，但软切换成功率不升反降。排查时先查 Iur 口的传输时延——Iur 口的时延预算非常紧张，如果走的是经过传输网绕远的路径，时延超标，UE 已经离开源小区了目标小区还没来得及完成资源准备，切换自然失败。

另一个坑是 Iur 口的数据承载容量不足。Iur 口上跑的是用户面数据转发，软切换期间的用户数据要经过源 RNC 转发到目标 RNC，这个流量和普通业务流量是叠加的。如果 Iur 口带宽只按信令流量算，不加业务流量冗余，切换期间很容易拥塞丢包。建议 Iur 口的带宽按“切换率 × 单用户业务速率 × 切换时长”来估算，并且留 30% 到 50% 的冗余。

6. 数据流程与配置核查：动手之前先看这几个地方

6.1 数据流向梳理：从 UE 到 NodeB、RNC、核心网，每一步走哪块板

RNC 的数据流程可以分为控制面和用户面两条路径。控制面流程：UE 发起 RRC 连接请求，经过 NodeB 通过 Iub 口的 AAL5 通道送到 APBE 接入板，APBE 解出信令后通过二级交换汇聚到 UIMC，再送到 RCB 板上的 RRC 协议栈处理。RRC 建立完成后，RNC 要发起 Iu 连接建立流程，RANAP 信令同样走 RCB 板，通过二级交换从 APBE 的 Iu-CS 或 Iu-PS 口发往 MSC 或 SGSN。

用户面流程：语音业务在 NodeB 的 FP 层封装后，通过 Iub 口 AAL2 通道送到 APBE，APBE 解出 AAL2 语音帧后走用户面二级交换，汇聚到 RUB 板完成 FP/MAC/RLC/UP 协议处理，然后再次通过交换送回 APBE 的 Iu-CS 口发往 MSC。PS 业务流程类似，只是 RUB 板要额外处理 PDCP 压缩和 GTP-U 封装，从 APBE 的 Iu-PS 口发往 SGSN。

这里要记住一条排障原则：信令链路查控制面路径，业务链路查用户面路径，两条路径在 APBE 接入板之后是完全分开的。如果语音业务单向不通，先定位是上行还是下行问题：上行不通查 NodeB 到 APBE 的 AAL2 通道，下行不通查 MSC 到 APBE 再到 RUB 的路径，两个方向的路径在 RNC 内部是不对称的。

6.2 系统核查命令：一台新装 RNC 上电后的检查顺序

新装或大修后的 RNC，推荐按以下顺序做系统核查。以工程师常用的维护终端操作习惯为例，第一步检查各功能框单板状态是否正常在位，第二步检查时钟同步状态，第三步检查传输链路，第四步检查 OM 通道。每一步的检查要点和确认标准如下：

第 1 步：单板状态核查

登录维护终端后，先列出所有槽位的单板信息，确认各单板状态为“运行”或“主用/备用”，重点关注是否有单板处于“不在位”或“故障”状态。控制框的 ROMB/RCB 主备状态必须明确显示一套主用一套备用；资源框的 RUB 板应该全部在“负荷分担”状态；接入框的 APBE 板如果配置了主备，备用板状态应该是“备用”而不是“不在位”。

第 2 步：时钟同步核查

查看 CLKG 板的工作状态，确认时钟源锁定正常。如果系统配置了外部 BITS 时钟源，确认 CLKG 已经锁定到外部时钟；如果使用自由振荡模式，确认时钟板无告警。时钟异常时，所有 NodeB 都会上报失步类告警，这个顺序排在第 2 位是为了先排除时钟问题再查别的——时钟是全系统的基础，它有问题后面所有业务逻辑都查不明白。

第 3 步：传输链路核查

逐个检查 Iub、Iu-CS、Iu-PS、Iur 口的物理层和 ATM/IP 层状态。物理层看 LOS/LOF 告警，ATM 层看 VPI/VCI 通道是否激活，IP 层看端口 ping 是否通。如果接入单元是 APBE 的 STM-1 接口，确认光模块收到的光功率在正常范围——光功率低于接收灵敏度阈值时，接口会频繁闪断，网管上表现为链路抖动告警，这种问题不是配置问题，是光路问题，需要先清洁光纤连接头。

第 4 步：OM 通道核查

验证 OMC-R 能否正常发现 RNC 并周期上报数据。先在 RNC 侧确认 ROMB 的 OM 链路状态正常，再到 OMC-R 侧查看 RNC 的告警上报和性能数据采集是否正常。OM 通道核查要放在最后，因为它的前提是单板状态、时钟、传输都正常——OM 链路本身是通过以太网走二级交换平面到 ROMB 的，如果前面步骤有问题，OM 通道也会异常。

6.3 版本与配置一致性：扩容时的板卡版本匹配

扩容加板或更换故障板卡时，版本一致性是最大的坑。RNC 系统软件版本是统一的，但每块单板的 FPGA 版本和驱动版本可能不同。比如你扩容一块 RUB 板，系统软件是 V3.0，新板出厂预装的是 V3.1 的 FPGA 版本，插上去后系统可能识别不了，或者识别了但协议处理异常。

我的做法是：新板到现场后，先用维护终端查看板的实际版本，如果和现网不一致，先降级或升级板卡版本再插业务槽位。具体操作上，新版单板一般支持版本回退，用维护终端下发版本加载指令就能完成，不需要拆板返厂。如果板卡插槽后发现版本不匹配导致业务异常，最快的恢复手段是拔出板卡，在独立调试槽位做版本对齐后再插入业务槽。

另外注意，接入单元的主备板卡必须是完全相同的硬件版本——至少硬件版本号和 FPGA 版本号一致，否则主备倒换时协议状态同步会出问题。你不想在凌晨三点被叫起来处理主用板故障后备用板接不上业务的场景，所以每次扩容多买一块同批次板卡做备件，是最省心的策略。

6.4 最后一步：用拨测验证配置，不是开机就行

配置核查完成后，不要急着交工。我会做一轮主动拨测验证——用测试终端在 RNC 覆盖范围内做语音呼叫和 PS 附着测试，这比看任何状态灯都靠谱。

语音测试：测试终端接入网络后发起一次语音呼叫，呼叫建立成功后保持通话 1 分钟以上，再发起一次跨小区切换。关注呼叫接通时延和切换成功率——接通时延超过 5 秒说明 RACH 或信令链路有问题；切换失败则检查目标小区的资源是否够、Iub 传输链路是否有拥塞。PS 测试：做一次 FTP 下载，速率低于标称值的一半时，要查 RUB 板的用户面处理能力和 Iu-PS 口的带宽配置——很多时候不是无线问题，是 Iu-PS 口的传输带宽没配够。

拨测时用维护终端盯 RNC 侧的相关单板状态。语音主叫时，观察 RCB 板信令处理是否正常流程；切换发生时，观察 RUB 板的用户面数据和 APBE 板的 AAL2 通道状态。把业务侧和单板侧的数据对照起来看，才能确认配置真正生效。拨测全部通过后再生成验收报告，这比单纯看单板“运行”状态有说服力得多。

从那以后，我每次做完 RNC 的配置核查，都强制走一遍完整拨测流程——语音、PS、切换各来一次，数据留存归档。这个过程会暴露很多网管上看不出来的隐患，比如 Iu-PS 口带宽配置错误、RUB 板在峰值流量时的处理延迟、APBE 板混合业务的吞吐量瓶颈。这些坑，早一天发现就少一次半夜上站的经历，希望帮到你。

本文还有配套的精品资源，点击获取