
简介爱立信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 格式化 DUWC2 盘和 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 机制改配置为什么像提交一次 commit4.1 浏览器里的 EMASJava 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 CVfinish 后会新生成一个 CV。整个 Cabinet Equipment Configuration 完成后系统会生成一个名为Initial_....的 CV。把 CV 理解成 Configuration Version——配置版本。它不是一堆文件而是一份完整配置的快照。这套机制的实质是配置事务开始修改前先记录一个回滚点修改过程中随时可以回到回滚点只有显式 Finish 才生成新版本把修改固化下来。开始配置 - 自动生成 cancel CV回滚点 - 逐页修改参数 - Finish - 生成新 CVInitial_....新配置固化 - Cancel - load cancel CV配置回滚到开始前这就是为什么配置过程“只能往前走、不能半途乱退”cancel 不是退出而是自动加载回滚版本。如果你把一个页面参数改错了直接 Previous 回去改如果你点了 cancel那就不是“返回上一步”而是整个配置会话作废并回滚到开站前状态。类比一下这就像数据库事务里的 commit 与 rollbackCV 机制保证了配置变更的原子性——设备配置要么整体变成新版本要么整体回到原点不存在中间脏状态。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 连线、天面安装这些环节自动化系统看不到也不负责看。配置可以说自动化物理检查不行。从那以后我每次开站都强制走一遍“先带外、再版本化、最后收 OM 通道”的顺序哪怕面对宣称支持远程开站的新设备也一样——这条链路上的每一个跳板都对应着一个可能把站点置于死地的故障点。希望帮到你。本文还有配套的精品资源点击获取