企业官网建设流程全解析

简介：爱立信TD-LTE基站现场维护手册以Word文档形式提供了一套完整的后台操作指引，面向从事爱立信LTE基站开局、日常维护与故障排查的现场工程师及网络优化人员。文档以操作维护终端（EM）为主线，先介绍安装与连接操作，再分别说明基站近端侧和网管侧的使用方式，随后讲解IP、无线网络、软件、授权、升级备份、告警等常用功能模块的具体操作步骤，便于维护人员快速完成配置修改、版本升级、数据备份和告警定位。手册还补充了串口连接线缆的线序定义、常用硬件板卡面板示意图、指示灯说明，以及驻波比和全球定位系统状态的现场查询方法，对日常巡检和射频类故障判断具有很强的实用性。资源共1个文件，类型为doc，压缩包整体约1.98MB，轻巧便于携带查阅。目前已有281人学习下载，适合需要系统掌握爱立信TD-LTE基站现场维护操作流程的工程师作为备查工具书。

1. 后台操作在爱立信TD-LTE现场维护里的分量

2014年3月这个时间点，正是TD-LTE大规模商用开站最密集的阶段，一份爱立信LTE后台操作指导能在现场维护手册里流转，说明当时最缺的不是硬件装维技能，而是知道对着哪里敲命令、敲完看什么。基站现场维护有条默认规则：能远程解决的不要着急跑站，必须跑站的也要先在后台拿到足够信息再动身。驻波比告警、小区掉线、传输闪断，每一类故障的定位路径都从后台操作开始。下面的内容覆盖的是爱立信TD-LTE基站日常维护里最常用的那部分后台技能，从接入方式、状态查询、参数变更到典型故障排查，最后收在一个容易被忽略的配置一致性验证上。适合刚接手爱立信设备的外场维护人员，也适合做LTE外场测试想补后台知识的网优工程师。5G基站维护的地基，很大一部分就打在4G时期这套后台操作习惯上。

2. 爱立信LTE基站的组网与后台接口：先搞清楚连到哪台设备上操作

2.1 基带、射频与逻辑节点：后台操作的对象是谁

爱立信TD-LTE基站以RBS 6000系列为主力。从外到内有三个层次：基带单元负责物理层和协议栈处理，RRU射频单元完成信号调制与收发，天馈系统负责电磁波辐射。后台操作的第一件事，是分清这三个层次各自对应的检查对象——基带侧看板卡状态，射频侧看通道驻波比，天馈侧只能靠现场仪表配合确认。

逻辑层面，一个eNB网元是后台操作的一个基本单位。一个eNB下挂多个小区，每个小区对应一个扇区或载波。后台修改频点、PCI、TAC这些参数时，操作对象是小区；重启单板、加载软件包时，操作对象是板卡；查传输链路时，操作对象是S1/X2接口。分不清对象，指令写得再完整也会落到错误的作用域。

TD-LTE采用TDD双工方式，上下行共用同一频段，因此后台参数里比FDD多了时隙配比和特殊子帧配置。这两个参数在不少综合代维站点里属于“不动区”，一旦配错会出现相邻基站互相干扰，而且很难从单站告警里直接看出原因，排查成本远高于参数本身。

2.2 两条接入通道：OMC-R远程登录与本地LCT终端

后台操作的接入通道按场景分为两条。日常批量查询和参数修改走OMC-R（RAN侧网管），通过网管界面或远程终端登录eNB，权限分级、指令留痕都在这条通道上完成。站点偏远或者承载网中断时，OMC-R会失去对基站的管理通道，这时需要到现场用本地维护终端（LCT）接线登录。LCT可以理解为现场维护人员的最后一条命脉，它直接连接基站维护口，不依赖承载网。

现场连接LCT的常见步骤是先找基站主控板上的本地维护以太网口，用网线把笔记本电脑接到该口，将电脑管理网卡的IP地址修改到和维护口同一网段，随后通过终端软件或浏览器访问维护地址。不同产品和软件版本对管理IP段有不同规划，不要照抄网上查到的固定IP，以该站点开局时的分配记录为准。

# 本地LCT连接后的基本连通性确认 ping -c 4 192.168.1.10 # 基站维护口地址，按现场记录替换 traceroute -n 192.168.1.10 # 查看中间跳数，确认是二层还是三层不通 arp -a # 查看是否解析到基站的MAC地址

这条检查链路的逻辑是：先ping确认物理链路通不通；不通时查网卡是否拿到了匹配网段的地址；traceroute结果为空但ping通，说明直接二层可达，不必关心路由。arp能解析出基站MAC时，基本可以确认网线、端口和IP段都没有问题，下一步才登录维护界面。真正的故障排查重点不在登录这个动作本身，而在登录前能确认物理层是通的。

2.3 登录后台后的第一轮信息采集：版本、站名与运行时长

职业习惯决定，每次登录后台先做三件事：看软件版本、看站点名称、看运行时长。版本决定可用指令集和参数范围；站名防止在多站点同时维护时把指令发错对象；运行时长帮助判断设备是否刚经历过重启，重启过的小区状态和告警历史都要重新审视。

爱立信LTE后台保留了文本指令的操作风格。指令通常以<开头，接动词和对象，例如查询类的动词是GET。不同Release版本对指令命名存在差异，现场记不全参数时，输入动词后使用问号或Tab键调出上下文帮助，是比翻手册更快的方式。

<GET SYSTEM; # 查看系统级信息 <GET CELL; # 列出全部小区及基本状态 <GET SOFTWARE; # 查看当前运行的软件版本包 <GET CLOCK; # 查看同步状态（TD-LTE必查项）

这组指令里，SYSTEM返回的是站点级总体信息，先看它能建立起全站状态的大局观；CELL返回小区列表与状态总览，是所有后续操作前的基线；SOFTWARE查看软件版本，与外场记录的版本基线做对照；CLOCK查看同步状态，TD-LTE对时间同步敏感，GPS失步或1588v2链路异常都会在这里体现。登录后建议记录的字段如下：

这一轮信息采集不需要修改任何东西，但能挡住后面大部分误操作。

3. 后台操作的三个核心动作：状态查询、告警解读与参数变更

3.1 小区状态判断：从Normal到Barred的每一步

小区状态是后台操作中最常盯的指标。状态值不是孤立的，而是由“是否闭塞”“是否有告警”“是否低功耗”组合出来的。闭塞动作是操作者主动执行的结果。后台通过状态字段暴露给维护者的信息包括以下几种：

查询时不要只盯着状态文字，要把状态和告警列表放在一起看。一个常见误判是把Barred当成故障。实际上它可能是上个班次的维护人员在修改参数后忘记解除闭塞。正确顺序是：先看是谁在什么时间闭塞的，再看有没有对应的工单记录，最后才决定是否解除。

<GET CELL; # 查看小区状态总览 <GET CELL:CELL=2; # 按小区号精确查看某小区状态 <GET CELLSTATUS:CELL=2; # 查看小区汇总状态与自愈能力状态 <SET CELL:CELL=2,STATE=UNBLOCKED; # 解除小区闭塞（先确认操作记录）

解除闭塞前必须确认操作记录与工单匹配。TD-LTE建网早期出现过不止一次把正在维护的小区提前放行的情况，原因是多人共用同一网管网元，前一个人的维护窗口还没结束。判断依据是操作时间和维护工单窗口是否匹配，不匹配时宁可多打一个电话确认，也不要直接执行解除动作。

3.2 告警查询：先看严重级别，再看同源关联

告警是后台操作里信息量最大的数据源，也是最容易看错的。通常的处理顺序是：先按严重级别过滤，再按网元对象归组，最后按发生时间排序。一上来就翻全部告警，会被大量瞬时告警带偏方向。爱立信后台的告警分级定义了处理的先后关系：

同一故障往往会派生多条告警。例如RRU光模块失联，会产生射频单元断链告警、对应小区不可用告警，还可能带上X2链路异常。先处理根因告警，派生告警会在根因恢复后自动清除。外场维护中常见的错误是盯着派生告警反复处理，却忽略了最前面那条根因告警。

<GET ALARM:SEVERITY=CRITICAL; # 只查Critical级别告警 <GET ALARM:OBJECT=RRU_3; # 按RRU对象过滤告警 <GET ALARM:TIME=20140310-08:00,20140310-20:00; # 按时间窗口过滤 <ACK ALARM:ALARMID=123456; # 确认已处理的告警

时间窗口过滤在做LTE外场测试配合时尤其有用。外场测试反馈某个时段出现异常，后台按这个时段窗口拉告警，能把网络侧动作与外场现象精确对上。告警确认要等处理完再做，先确认再处理会让下一个班次的人误以为这个告警已经被分析过，从而跳过复查步骤。

3.3 参数变更的安全顺序：评估、闭塞、修改、验证

后台操作里风险最高的动作是参数修改。一个频点或TAC配错，影响的不只是本小区，还可能干扰邻区。稳定可复用的执行顺序是：评估影响范围、闭塞小区、修改参数、下发激活、验证状态。

第一步评估先看参数类型。时隙配比、频点、参考信号功率这类参数会影响覆盖和邻区关系，必须提前查邻区表确认不会造成冲突；TAC这类标识参数则需要和核心网侧核对取值范围。第二步是闭塞小区，把新用户挡在门外，再观察存量用户是否已经自然释放。不同参数对业务的影响程度不一样：

以参考信号功率为例，从工程角度看，功率每抬高1dB，覆盖边缘的参考信号接收功率等量抬升1dB，体验改善是线性的，但同频邻区的干扰也会同步加大。这也是为什么RS功率调整看起来简单，却总是需要结合路测数据反复确认。

参数变更指令执行后，不能只看指令返回成功就结束。下发成功不代表激活成功，激活成功不代表邻区关系正确。验证动作包括重新查询参数值、确认小区回到Normal状态、发起一次拨打测试或查看接通率指标。这些步骤做完，一次参数修改才真正闭环。

提示：所有变更类指令在下发前确认当前维护窗口和操作人身份。多个维护人员同时操作同一个网元时，配置覆盖的风险比告警处理本身更难排查。

4. 现场维护场景里的后台排障：从告警到恢复的完整路径

4.1 驻波比告警：后台确认与现场检查的配合

驻波比（VSWR）告警是射频侧最常见的告警之一，含义是天馈系统的阻抗失配程度超过了设定门限。后台能查到的是某个发射通道的驻波比数值、告警门限和告警时间，但驻波比的物理位置在RRU之后的天馈链路里，精确定位要靠现场。后台在处理这类告警时的作用是把问题坐标缩小到具体通道：

<GET VSWR:UNIT=RRU_2; # 查询指定RRU的驻波比数值 <GET RRU:UNIT=RRU_2; # 查看RRU连接与收发通道状态

查到数值异常后，用互换法做硬件定位：把异常通道的射频跳线接到另一个正常的RRU通道，如果驻波比异常跟着跳线走，问题在天馈侧；如果留在原通道，问题在RRU或主集通道。现场检查顺序是接头防水层有没有老化开裂、馈线有没有弯折挤压、避雷器有没有打火痕迹，最后才考虑RRU本身。常见做法是替换射频跳线并重新制作接头，大部分驻波比告警出在接头氧化和进水这两个环节。

4.2 小区不可用与传输断链：按三层次序排查

小区不可用告警出现后，要先分清是射频侧故障、基带侧故障还是传输侧故障。稳定可复用的排查次序是：传输层 → 小区层 → 射频层。传输层用ping和路由检查来确认，小区层看状态机和告警，射频层看RRU连接状态。

ping -c 4 <核心网S1地址> # 验证到核心网的IP连通性 traceroute -n <核心网S1地址> # 观察中间路由是否出现黑洞 <GET S1LINK; # 查看S1链路状态 <GET CELL; # 查看小区是否已自动恢复

传输断链时，站点会出现S1链路告警，小区会自动尝试恢复。有些版本的小区在传输恢复后会自行解除闭塞，有些需要人工确认。这个差异与具体Release相关，维护时不要想当然，连续观察两次自动恢复失败就要按人工流程介入。TD-LTE对时钟同步敏感，GPS失步或1588v2链路劣化同样会导致小区不可用，查询CLOCK状态应放在传输检查之后立即执行。

4.3 板卡级操作：基带板与RRU的处理边界

最后一步才动板卡。查询板卡状态、确认故障单板、远端复位、现场更换，这个顺序能减少误换件。基站板卡状态查询返回的信息包括板卡工作状态、运行温度、在位状态和序列号，这些信息在更换后需要重新核对。

<GET BOARD; # 查看全部板卡在位与工作状态 <GET BOARD:UNIT=BB; # 查看基带板状态 <RESTART BOARD:UNIT=BB; # 重启基带板（业务会中断，慎重） <GET RRU:UNIT=RRU_1; # 查看RRU接入状态

RESTART类操作本质上是对网元的强制干预，执行前要确认维护窗口和非高峰时段。基带板重启会中断该板下所有小区业务，RRU复位只影响对应通道但也会出现瞬时断链。现场更换RRU后，后台需要确认新RRU的光模块识别正常、双通道驻波比恢复、对应小区自动恢复可用，才算完成闭环。常见故障场景分流可以参照下表：

这张表用来做快速分流，避免一开始就把问题定位到微波、光缆或者核心网侧。

5. 收尾技巧：验证配置漂移与版本一致性，避免改过的参数悄悄回退

5.1 用配置导出加比对，让每次参数修改都有据可查

后台操作里最隐蔽的问题是配置漂移——网管里看到的参数和基站实际生效的参数不一致。产生这个问题的原因很多：一次失败的下发半途中断、多人同时登录造成覆盖写、开局数据与现网数据没有同步。危害在于业务可能完全正常，但下一次参数修改会基于一个错误的基线。

<GET CONFIG:FORMAT=TEXT;> 保存为 config_before.txt # 修改后再次执行同一条导出命令，保存为 config_after.txt diff config_before.txt config_after.txt # 在电脑上比较差异

每次参数修改前后各导出一份配置，把两次导出的文本文件放到电脑上做diff，差异清单就是本次修改的完整变更记录。维护记录完整的团队会把这份diff输出连同工单号一起归档，作为后续对账的依据。任何一次修改看起来“没有生效”时，这套对比能马上看出是参数值没写进去，还是写进去之后被其他操作覆盖了。

5.2 用日志时间戳对齐故障时刻，别被时区错位误导

外场测试和外场维护经常遇到一个困扰：测试反馈的时间点和后台日志里的时间点对不上。多数情况不是设备时钟不准，而是时区口径不一致。基站系统时间、网管时间、测试终端时间各自使用UTC或本地时间，对账时先把三者统一到同一时区。

<GET DATE; # 查看基站系统时间 <GET LOG:FROM=20140310-13:00,TO=20140310-14:00; # 按对账后的时刻拉日志

查看最近一次重启的时间戳和对应告警，能判断是自动重启还是人工干预。把外场测试记录的时刻、后台告警时间、系统时间三个值放到同一张表里对比，差值为8小时整大概率是UTC与北京时间的口径差异，不是设备故障。这个习惯延续到5G基站维护里会发现底层逻辑基本没变，变的是指令集和网管形态。下次再遇到外场测试结果与后台数据对不上的情况，先对一遍时区口径，再查配置差异，比反复重启基站靠谱得多。

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