基站开站全程拆解：从串口救生到配置版本化，零基础也能看懂
简介：爱立信6601基站开站流程详解，面向基站调测督导与集成测试工程师，提供从硬件检查、软件配置到系统调测的全流程操作参考。文档以单DU为例，兼顾双DU配置场景，帮助技术人员规范完成开站任务。资源为1个doc文件，压缩包大小2.63MB，内容结构完整，包含概述、工具软件、准备工作、硬件状态检查、调测及扫尾工作等环节。目前已有393人学习下载。文档重点突出实操细节，如串口线连接、格式化DUW、IP地址设置、上传启局包到RBS、机柜及操作维护配置等，并配有截图说明，便于对照执行。适合需要快速掌握爱立信6601开站技能或进行现场调测的通信工程师参考。
1. 开站第一性原理：一台新基站为什么连“我是谁”都不知道
一台刚从工厂发货的 RBS6601 基站，在开站之前连“我是谁”都不知道——它没有 IP 地址，没有站点名，没有被网管识别的身份，甚至预装软件版本都可能和入网许可对不上。你没法像配置交换机那样 SSH 上去改几行命令，因为它根本没有一个可访问的地址。开站工程师实际在做的，是把一块混沌的硬件从零“唤醒”成一个有身份、有配置版本、可被网管纳管的网络节点。这条唤醒链路由四样东西接力完成：串口带外通道、链路本地地址、启局包、配置版本（CV）。把这四个环节的底层逻辑拆开，你就理解了所有远程开站、自动开站方案的原始原型。
2. 带外通道与链路本地地址：开站“第一公里”的底层逻辑
2.1 串口 LMT A：为什么设备没有 IP 时只能靠 console
所有网络设备都保留一条不依赖 IP 的管理通道，这就是 console 口。DUW 板上的 LMT A 口是串口，LMT B 口是网口，这两个口的分工从一开始就是明确的：串口负责“救生”，网口负责“运送”。救生指的是格式化硬盘、进备份模式、敲reload --这类底层命令；运送指的是后续的 FTP 上传启局包、浏览器访问 EMAS。不要试图只用网口完成开站的第一跳，因为在设备还没有 IP、文件系统可能还是空白的时候，唯一确定可用的 I/O 就是串口。
我一般会这么理解带外管理的设计动机：CPU 在启动早期、网络协议栈还没起来、磁盘还没挂载的时候，只能通过 UART 输出一个维护提示符。这个提示符不依赖设备当前的健康状态，所以它成了所有故障场景下最后一条命脉。原文流程里，串口线的一端插笔记本、另一端插 DUW 的 LMT A，网线则插 LMT B，正是把“救命通道”和“运输通道”物理分离。
常见的新手误用是拿 USB 转串口线直接插上就开超级终端，结果满屏乱码或根本没有提示符。这通常是驱动没装、COM 口号选错、或者调测线缆的 Tx/Rx 交叉关系不对。串口调测线不是直通线，它是交叉线序，一头插 PC 一头插 DUW，接线时如果线序做反了，数据收发就是鸡同鸭讲。
2.2 169.254.1.1 的玄机：链路本地地址为什么不需要 DHCP
格式化完 DUW 之后，第一件正经事是给设备一个 IP。原文命令是：
> ifconfig le0 169.254.1.1 netmask 255.255.0.0 > reloadle0是以太网接口的设备名，对应 DUW 板上的 LMT B 口所在的网卡。执行完这条命令后，把 PC 端 IP 改成 169.254.1.2、掩码 255.255.0.0，两者就在同一个二层域里直接可达了。
为什么偏偏选 169.254 这个网段，而不是常见的 192.168 或 10.x？因为 169.254.0.0/16 是 IANA 专门保留的链路本地地址段。链路本地地址的意思是：地址只在当前物理链路上有效，不需要 DHCP 服务器分配、不需要网关、不需要 DNS，只要网线物理连通，网络层就能通信。开站现场最常见的状况是网络拓扑未知——你不知道这个站点将来接在什么交换机上、有没有 DHCP、有没有人配过 VLAN。用链路本地地址，就把“能不能通”这件事收敛成最朴素的判断：网线通，就通。
顺带一提，Windows 在网卡拿不到 DHCP 地址时自动分配的 169.254.x.x 也是同一套机制（APIPA）。所以这个地址段本质上就是网络世界的“最后手段”，开站流程把它拿来当第一跳，恰恰是合理的选择——在最不确定的环境里，用最不需要依赖的地址建立确定性。
2.3 格式化 DUW：C2 盘和 D 盘里到底装了什么
原文明确说“格式化 DUW 可省略”，省略的前提是预装软件版本不高于入网许可版本。反过来想，什么情况下必须格式化？预装版本高于入网许可版本时。入网许可是监管层面的软件快照，设备联网前必须匹配，所以要把工厂预装的高版本抹掉，重装合规版本。
格式化操作不是进系统里删文件，而是进备份模式下做的：
> reload -- # 启动备份模式，相当于进入维护用的小系统 > mount_c2 # 挂载 C2 盘，使其可被格式化命令访问 > formathd /c2 # 格式化 C2 盘 > formathd /d # 格式化 D 盘 > vols # 列出卷，确认 C2 和 D 是否已被格式化 > file format # 清除缓存，释放文件占用 > reload - # 退出备份模式，重启我一般会这么理解这套命令序列：reload --是让设备启动到一个独立的备份引导系统，类似 PC 的恢复模式；mount_c2是把原本未挂载的卷暴露给命令环境；formathd才是真正清盘；vols是验证步骤，对应我们在日常操作里“做完检查一遍”的习惯；file format清掉缓存，避免旧的文件系统元数据干扰重启后的首次挂载；最后的reload -回到正常启动路径。
C2 和 D 在 DUW 里承担不同职责。按照这类分布式基站的常见盘符设计，C2 是启动和系统卷，承载引导文件、内核和基础软件镜像；D 是数据卷，承载配置版本、日志、告警记录等运行期数据。这解释了为什么启局包在后续步骤里要分别上传 C2 和 D 两份镜像——它们是两个独立的文件系统，一个管“跑起来”，一个管“记住自己是谁”。
双 DU 站点有一个明确的顺序约束：先格式化辅 DU，再格式化主 DU。理由很朴素——主 DU 是管理入口，是后面所有操作的指挥节点。如果先格式化主 DU，它的管理能力就没了，你拿什么去指挥辅 DU？先格式化辅 DU，主 DU 还能兜底，全程可管可控。
2.4 先辅后主与双 DU 连线：一条看不见的数据面
3×3 站型会用到双 DU，硬件上主 DU 用 DUW30 装在下面，辅 DU 用 DUW20 装在上面。连线关系原文列得很清楚：主 DU 的 RIF 口连辅 DU 的 RIF 口、主 DU 的 IDL 口连辅 DU 的 IDL 口（IDL 电缆上标 PRIM 的一头连主 DU，标 SEC 的一头连辅 DUW）、主 DU 的 AUX 口连辅 DU 的 EC A 口、主 DU 的 EC 口连主 DU 的 EC A 口。
这几条线不是随便插的，它们分别承载不同面：RIF 口是基带数据互连，对应 DU 之间的业务数据面；IDL 口带 PRIM/SEC 方向标识，防止两根线接反导致主辅关系混乱；AUX/EC 口提供辅助控制和管理信令。双 DU 在软件侧还有一个必须做的动作——在 Cabinet 配置里把 Climate System 类型选成 Extended，原文特别警告“如果不选会读不到第二个 DUW”。这是物理连线之外最容易被漏掉的一步：硬件接好了，但配置系统根本不知道第二个 DU 存在，于是它就成了一个“透明”的设备。
3. 启局包与 FTP：软件是怎么“灌”进基站的
3.1 启局包的本质：一份两盘符的最小可启动种子
格式化完成、IP 配置好之后，DUW 还是空的。这时候需要把启局包传上去。启局包本质上是一份按盘符组织的最小可启动镜像集合：C2 盘镜像对应系统卷，D 盘镜像对应数据卷。FTP 上传到 RBS 根目录之后，执行reload让镜像落盘并启动。这个“启局”的叫法很形象——整个基站从一个空白盘开始，靠这份种子把系统跑起来。
在 MS-DOS 窗口下的操作流程是：
> ping 169.254.1.1 # 先确认 PC 和 RBS 的网络连通性 > ftp 169.254.1.1 # 连接基站的 FTP 服务 > binary # 切换为二进制传输，避免镜像被转换损坏 > put C2.iso # 上传 C2 盘镜像到根目录 > put D.iso # 上传 D 盘镜像到根目录 > reload # 重启设备，让镜像生效 > passwd rbs # 设置本地维护账号 rbs 的密码 > setclock 2011-12-14 # 设置系统时钟到当前日期为什么上传后首先要ping？因为前面所有操作都发生在链路本地地址段，PC 和 DUW 之间可能隔着 USB 转串口、可能网线没插牢，任何一环松了，FTP 都会失败。ping 是成本最低的通路验证。
3.2 FTP 上传后的四条命令：reload、passwd、setclock 各自解决什么
reload很好理解——镜像已经落盘，需要重启让新系统接管。但后面两条容易被跳过，跳过之后会踩坑。
passwd rbs设置的是本地维护账号 rbs 的密码。rbs 这个账号用于后续通过 CLI 方式登录设备做维护。常见实现思路是：设备启动完成后，本地维护通道默认生效，但这个账号必须在第一次启动时被初始化一个口令，否则你没法进入受控的维护会话。现场有人图省事跳过这一步，等需要 CLI 排查的时候就傻眼了。
setclock设置的是系统时钟。为什么系统时钟这么重要？最直接的原因是日志时间戳——开站之后所有告警、操作记录都带时间，时钟错了，后续排障时日志序列全乱；更深一层是，这一版的工具链依赖 JAR 签名和时间校验，设备时间和 PC 时间不一致，EMAS 连接就可能被卡在证书校验上（下一章会展开）。原文里setclock 2011-12-14只给了日期参数，说明该命令接受日期级别的设置，精度对开站场景足够了。
3.3 为什么双 DU 只在主 DU 上设置 IP
前面设置 IP 时原文有一句备注：使用双 DU 时，只需在主 DU 上设置 IP 地址。这个设计背后的逻辑是管理面收敛。
双 DU 之间通过 RIF、IDL 等内部互联口连成一体，辅 DU 对外不需要独立的可路由身份。主 DU 作为管理代理，统一承担对外管理面；网管侧、EMAS 侧看到的只是一个 IP。这个取舍的收益很实际：如果两个 DU 各自有 IP，网管系统的自动发现、路由配置、告警上报都会面临“同一站点两个地址”的混乱。收敛到单点之后，辅 DU 的运维完全通过内部互联口被主 DU 代理，站点作为一个整体被纳管。代价是主 DU 成为单点——它挂了，辅 DU 的管理面也跟着断，所以双 DU 的物理连线检查才被放到开站流程的硬件检查阶段重点强调。
4. EMAS 与 CV 机制：改配置为什么像提交一次 commit
4.1 浏览器里的 EMAS：Java Web Start 架构与 JAR 时间戳陷阱
启局包灌完，设备已经有基本软件了，接下来是通过 EMAS 做详细配置。EMAS 不是传统的桌面客户端，它的入口是浏览器——打开 IE，输入http://169.254.1.1/em/index.html，下载安装文件。安装前还必须先装 Java，然后从页面下载 JAR 包，由 Java Web Start 拉起来执行。
为什么用浏览器加 JAR 的组合，而不是做一个厚重的本地安装程序？这要放在这个设备年代的运维场景里看：开站工程师的笔记本是临时工具，换了人、换了电脑就要重新装；浏览器加 Java Web Start 的模式把客户端分发变成了“打开网页点下载”，JAR 即客户端，版本统一由设备端控制，避免本地安装包版本和基站软件版本错位。
这个架构有一个经典翻车点：JAR 包签名证书过期。原文给的排查路径非常具体——如果因为 JAR 问题连不上 RBS6601，先把 PC 时间改到 2011.12.11 之前，登录下载 JAR 并正常使用，再把时间改回当前时间；JAR 已经下载到本地缓存，之后连接不再需要再次改时间。这个现象的原因是 Java Web Start 在启动 JAR 时会校验代码签名证书的有效期，证书过期则拒绝运行。把 PC 时间调到证书有效期内，骗过本地的有效期检查，让 JAR 先落盘缓存；时间改回后缓存里的 JAR 已经能用，因为校验只在下载安装那一步发生。这属于设备软件停止更新后，签名证书自然老化与现场时间不同步叠加产生的经典事故。
4.2 Cabinet Equipment Configuration：机柜身份的五项关键参数
EMAS 连上之后的第一大块配置是 Cabinet Equipment Configuration，翻译过来是机柜设备配置。它做的事情是给基站建立“物理身份”，原文里拆成了几个页面：RBS 产品名称、Climate System 类型、cabinet product data 的产品参数（主 DU 生产日期、RBS 类型、产品号、版本号、串号），然后是电源配置、ethernet link 的 IP 和掩码。
Climate System 类型就是前面说过的坑：单 DU 选 Standard，双 DU 选 Extended，不选 Extended 就读不到第二个 DUW。产品参数页填的是主 DU 的串号和生产日期——这是把“这台物理设备”和“配置系统里的对象”绑定起来的手段。电源配置页对应硬件检查阶段确认过的电源类型和电压；ethernet link 配置页把第 2 章里临时设置的管理 IP 固化进正式配置。
原文在这里有一句非常重要的备注：现场不建议使用“.xml 配置文件”，走手工填写。原因后面避坑章会详细说，核心在于配置文件是静态的，而现场的硬件、连线、版本是动态的，文件里的参数对不上时，配置过程不会给出任何物理层面的校验。
4.3 Wizard 断连现象：为什么“不用管，等它重连”
一个让从 RBS3000 系列转过来的工程师很慌的现象是：Wizard 从 RBS 下载当前配置的过程中，EMAS 和 RBS 的连接会断开。原文明确写了，这和 RBS3000 系列不同，无需操作，稍等片刻 EM 会自动重连。为什么配置工具一读配置，管理连接反而断了？
我一般会这么理解：Wizard 的“下载当前配置”不是只读操作，它会与设备端的配置管理进程建立会话，期间设备可能重置管理面（重新初始化网口或重启配置进程），导致 TCP 连接被掐断。设备从容地做完自己的事，再把管理面重新拉起来，EM 探测到设备重新可达就自动恢复会话。对操作者来说，这个断连是配置流程的一个正常阶段，不是故障。真正需要注意的是别在断连瞬间手动重启设备或拔网线，那会把配置过程打断到一半，留下一个既没成功也没失败的中间态。
4.4 cancel CV 与 Initial_....：配置版本化的原子性设计
Cabinet 配置最后的 Finish 动作背后有一套版本化机制。原文的描述很关键：设置开始后，系统会自动生成一个“cancel CV”，一旦 cancel，会自动 load 这个 cancel CV；finish 后会新生成一个 CV。整个 Cabinet Equipment Configuration 完成后，系统会生成一个名为Initial_....的 CV。
把 CV 理解成 Configuration Version——配置版本。它不是一堆文件，而是一份完整配置的快照。这套机制的实质是配置事务：开始修改前先记录一个回滚点，修改过程中随时可以回到回滚点；只有显式 Finish 才生成新版本，把修改固化下来。
开始配置 -> 自动生成 cancel CV（回滚点） -> 逐页修改参数 -> Finish -> 生成新 CV（Initial_....），新配置固化 -> Cancel -> load cancel CV，配置回滚到开始前这就是为什么配置过程“只能往前走、不能半途乱退”：cancel 不是退出，而是自动加载回滚版本。如果你把一个页面参数改错了，直接 Previous 回去改；如果你点了 cancel，那就不是“返回上一步”，而是整个配置会话作废并回滚到开站前状态。类比一下，这就像数据库事务里的 commit 与 rollback，CV 机制保证了配置变更的原子性——设备配置要么整体变成新版本，要么整体回到原点，不存在中间脏状态。
5. 避坑：开站现场最容易翻车的五个场景
5.1 连接阶段：串口乱码与 EMAS 的 JAR 拦截
现象一：串口线接上 LMT A，超级终端打开后满屏乱码，或者根本没有提示符。原因通常是 USB 转串口线驱动没装对、COM 口号选错、或者调测线缆的 Tx/Rx 线序做反了。解决思路是分三层排查：先到设备管理器确认 COM 口号；再确认终端软件的波特率等参数；最后拿一根已知完好的直通线或交叉线替换对比，判断是不是线序问题。
现象二：浏览器访问 EMAS 下载页面后，启动时报 JAR 错误，无法连接 RBS。原因就是 4.1 说的签名证书过期。解决方法是把 PC 时间改到 2011.12.11 之前，登录下载 JAR 并完成首次运行，再把时间改回当前时间，之后不再需要重复修改。
5.2 配置阶段：Wizard 断连与读不到第二个 DU
现象三：Cabinet 配置 Wizard 开始下载当前配置时，EMAS 提示失去连接。这会让没经验的人误以为设备挂了。原因不是设备故障，而是 RBS 在配置读取过程中重置了管理面，连接被短暂打断。解决方法是别动设备、别关页面，等 EM 自动重连；如果等待超过一两分钟还没恢复，再检查网口灯和 PC 的 IP 有没有被改动。
现象四：双 DU 站点配置完成后只看到一个 DU。原因几乎可以锁定在 Climate System 类型没选 Extended。原文说得直白：“如果不选会读不到第二个 DUW”。解决方法是回到 Cabinet 配置，把 Climate System 改成 Extended 后重新走配置流程。这个坑的隐蔽性在于硬件连线全对、电源全对，就是软件侧的一个下拉选项漏了，第二块 DU 就彻底隐身。
5.3 数据阶段：xml 配置文件为什么不如手工填写靠谱
现象五：现场贪快用了“.xml 配置文件”自动生成配置，结果配置完成后设备和实际硬件对不上，出现异常告警或某些板卡读不到。原因是配置文件是静态的，它的参数来源于之前的某个站型或设计模板，和现场实际的连线方式、硬件版本、串号批次存在偏差；而且配置文件生成的过程会跳过逐项核对，把本应由人眼发现的物理差异掩盖在一份“看起来很完整”的参数里。解决方法是回到原文的建议：现场不用 xml 配置，按 cab 文件手工填写参数；每一步填完都和设计文件核对，Finishing 之前还要整体回看一眼，发现不相符就 Previous 回去改。
这个建议背后是个很朴素的原则：自动化的前提是输入数据可信。开站现场恰恰是输入数据最不可信的地方——线可能接错、板卡批次可能调换、设计文件可能更新不及时。手工填写的每一个字段都是一次显式核对，它慢，但它把人为校验嵌进了流程本身。
6. 设计取舍：从手工开站到零接触配置，串口为什么仍是最后的兜底
这套流程里的每一个环节都在解决同一个问题：如何对一台“未知”设备建立信任。串口解决了无 IP 时代的可达性，链路本地地址解决了无可信网络环境的连通性，启局包解决了空白文件系统的可运行性，CV 机制解决了配置变更的可回退性。四者合起来，构成了一条从物理层到配置层的完整信任链。
今天的开站正在向零接触配置演进：设备出厂预配置管理地址，上电后通过 DHCP 获取临时地址，再通过自动发现协议向网管服务器拉取配置文件。但几乎所有现场自动化开站的兜底方案，仍然保留了一个 console 口和一套串口命令。原因在于，自动化方案依赖的前提是“设备至少能起来、能拿地址、能连网管”，而这三件事在硬件故障、镜像损坏、证书过期时全都可能失效。串口不依赖设备状态，这是它在所有自动化方案演进中始终没有被删掉的原因。
从另一个角度看，手工开站的真正价值不在“敲命令”，而在“看现场”。硬件检查阶段要核对站型、扇区、电源、双 DU 连线、天面安装；这些环节自动化系统看不到，也不负责看。配置可以说自动化，物理检查不行。从那以后我每次开站都强制走一遍“先带外、再版本化、最后收 O&M 通道”的顺序，哪怕面对宣称支持远程开站的新设备也一样——这条链路上的每一个跳板，都对应着一个可能把站点置于死地的故障点。希望帮到你。
本文还有配套的精品资源，点击获取