企业官网建设流程全解析

简介：这是一份爱立信TD-LTE基站后台操作与现场维护的实用手册，面向LTE基站工程开通、日常巡检与故障排查人员。内容围绕EM安装与连接、eNB近端侧及OSS侧配置操作展开，并具体讲解IP、Radio Network、Software、Licensing、Upgrade and Backup、Alarm告警等功能块的使用方法，同时包含串口线缆线序、DUL/DUS硬件面板示意图、指示灯说明以及VSWR驻波比和GPS状态现场查询步骤，适合需要掌握爱立信基站维护基础操作的工程师参考。资源包共1个文件，为doc格式文档，压缩包大小约1.98MB，便于离线查阅和打印。目前已有281人学习下载，内容结构清晰，从环境准备到具体命令操作均有说明，可帮助读者快速上手eNB日常维护并建立系统排查思路。

1. 爱立信LTE后台操作指导：一份现场维护手册到底在回答什么问题

晚上十点，代维值班手机响了：某 TD-LTE 站点“小区退服”告警。真正的工作从你登录爱立信LTE后台那一刻才开始。类似《爱立信TD-LTE基站现场维护手册_20140310》这类后台操作指导，本质上是代维项目里沉淀下来的保命流程——它不跟你讲空泛的网管原理，只回答三件事：后台怎么进、故障怎么查、参数怎么改不出大事故。它解决的是“这个站点现在到底什么状态，我下一步动哪个开关”的问题。适合刚接手爱立信设备、从华为或中兴后台转过来的基站维护工程师，也适合需要自己动后台配置的网优兄弟。别小看这份文档，很多现场事故不是不会查，而是操作前少想了一步。

2. 先连上爱立信LTE后台：ENM/OSS-RC登录与三条只读指令

2.1 后台工具与维护账号：选择登录通道的注意点

爱立信LTE后台的入口常见有两套：ENM网管图形界面和 OSS-RC 命令行。图形界面适合多网元批量看告警、导报表，但现场故障处理我更推荐命令行——一个个菜单点过去，光路一卡就烦躁，命令行窗口一条指令出结果，输出还能直接存成文本留痕。2014 年前后国内 TD-LTE 项目里，绝大多数维护动作就是在命令行里完成的。

登录前的准备信息其实就三样：eNodeB 管理 IP、维护账号、密码。部分项目还要求先跳登录网管服务器再连网元，相当于多一层跳板。账号权限要看清：Administrator 能改配置、下发数据，Operator/Maintenance 通常只做查询和日常维护。现场最忌讳拿管理员账号跑只读查询——不是说不能跑，而是多人共用管理员账号时，后面要讲的“操作锁冲突”概率会大很多。

# 方式A：通过网管客户端登进ENM后，再进入命令行视图 # 方式B：直接登录网元维护通道（Telnet/SSH视项目安全策略而定） telnet 10.20.30.40 # 输入维护账号与密码后进入命令提示符 LST CELL:ALL;

登录失败的排查按链路顺序走：先 ping 管理 IP 看通不通，不通查传输和网关；通了但登录报错，多半是账号权限或密码过期；部分项目还有 IP 白名单，换了维护终端就登不上，这个要提前报备。登录成功后，第一件事不是急着查告警，而是先确认自己登对了站——把网元 ID 和工单上的站号对一遍，登错站在现场是常见低级事故。

2.2 先跑通 LST EQP、LST CELL、LST ALMAF 这三条指令

第一次接到一个陌生站点，我一般按固定顺序跑三条只读指令，跑完这个站的底细基本就清楚了。这三条指令也是爱立信LTE后台操作指导里最基础的动作，训个新人先背这三条，比让他翻整本维护手册管用。

LST EQP:ALL; # 列出eNodeB全部硬件单板：BBU、RRU、传输板，看安装状态和操作状态 LST CELL:ALL; # 列出所有小区：Cell ID、TAC、EARFCN、PCI、小区状态都在这里 LST ALMAF; # 列出当前活动告警：严重级别、告警对象、发生时间

LST EQP 看的是“底子”：单板在不在位、有没有硬件故障。LST CELL 看的是“业务能力”：小区能不能放业务、参数配得对不对。LST ALMAF 看的是“为什么出问题”：通常小区状态异常时，活动告警里已经告诉你原因了。三条的先后顺序可以理解为：先看谁坏了，再看影响面，最后看为什么。

LST CELL 是现场截图最多的一条指令，输出字段要认全：

这里有个概念容易混：Local Cell ID 不是全网唯一，它和 eNodeB ID 组合起来才唯一，很多刚转爱立信后台的人把 Cell ID 当成全网唯一，做外部小区时填错，后面切换必翻车。TAC 是跟踪区，不是传统2G/3G的位置区，它的改动影响范围比一般人以为的大得多——这个坑在第 5 章重点讲。跑完这三条指令，把输出存到本地文本文件里，命名带上日期，这就是这个站点最早的维护基线。

3. 小区状态与告警：TD-LTE基站现场维护的两件头等大事

3.1 一次完整的小区状态核查：从告警切入还是从状态切入

处理“小区退服”工单，新手常犯的毛病是直接复位基站——复位一时爽，如果根因是同步或传输问题，基站起来半小时又退服，用户投诉反而更凶。我习惯按“告警→状态→硬件→动作”的顺序来，每一步都看清楚了再动手。

LST ALMAF; # 1. 先看活动告警，定位导致退服的主告警 LST CELL:ALL; # 2. 再看小区状态，确认是未建立还是已降级 LST EQP:ALL; # 3. 最后看硬件单板，排除BBU/RRU/传输板故障 # 仅在确认无业务且有必要时，才做人工作闭塞/解闭塞 BLK CELL:CELLNAME=市区_01; # 闭塞小区：强制中断该小区业务，操作前必须口头确认 UBL CELL:CELLNAME=市区_01; # 解闭塞小区：恢复该小区业务

排障顺序有讲究：LST ALMAF 放在最前面，是因为主告警会直接告诉你方向，比如“驻波告警”你就别去复位基站，去查馈线；“S1断链”你就别动无线侧，去查传输和核心网。LST CELL 放在第二位，是确认影响面——一个站三个小区全部未建立，和只有一个小区未建立，排障优先级完全不同。LST EQP 放在第三位，是确认硬件不是隐性故障。

BLK 和 UBL 是现场最容易出大事的两条指令，它们不会自动恢复。BLK 一个小区等于人为制造一个“退服小区”，所有用户被踢出或无法接入；UBL 则是把业务还回去。每次做闭塞操作前，我要求自己必须确认三件事：这个小区当前有没有用户、有没有重要投诉、解闭塞方案是不是已经写好。曾有兄弟白天 BLK 小区做测试，收工时忘了 UBL，半夜被“无线不可用”投诉叫醒——这种血泪经验后面专门讲。

另外，LST CELL 显示 Operational 不代表用户一定能接入。还有一个容易忽略的状态位叫“小区禁止接入”（Cell Barred），它被置位后小区还是 Operational，但终端不会选上来，用户投诉“有信号上不了网”。所以核查小区状态时，不光看 Cell State，还要看有没有禁止接入相关的配置位。

3.2 常见告警怎么读：驻波、GPS失步、S1断链的处理动作

TD-LTE 现场维护里告警就那么几类，见得多了基本能快速分诊。我个人经验是先把告警分成“无线侧、传输侧、同步侧”三类，再决定下一步动哪里。

GPS 失步在 TD-LTE 里是个特殊存在。TD-LTE 是时分系统，空口必须要严格同步，GPS 一失步，影响的不是单站，可能是周边一片的干扰——基站上行时隙对不上，互相干扰，轻则速率暴跌，重则周边小区全被抬升底噪。处理时不要只盯着报 GPS 告警的这一个站，要看周边基站是不是同时出现了底噪抬升。

LST ALMAF; # 确认时钟/同步类告警的对象和数量 LST GNSS:ALL; # 查GPS/北斗接收状态（部分OSS版本支持） LST CELL:ALL; # 看受影响的载波/小区范围

有个现场很容易漏的场景：用户侧拿着 TD-LTE 无线数据终端（CPE/MiFi）投诉“连不上网”，后台查这个用户所在小区一切正常。这时候别急着改终端参数，先在后台看用户附着记录和该小区当前在线用户数，判断是不是小区容量或接入控制问题。很多所谓“终端不兼容”其实是后台把小区半锁了，终端侧怎么重启都没用。

4. 参数与邻区调整：在爱立信LTE后台改TAC、PCI、邻区的正确姿势

4.1 改参数前先做三查：当前值、依赖关系、回退基线

后台操作指导里最值钱的经验不是怎么改参数，而是改之前做什么。我给自己定了一条死规矩：任何 SET 指令前，先做三查——查当前值、查依赖关系、查回退基线。

查当前值用 LST，这个最直接，但要注意单位。以调整下行参考信号功率为例，不同版本参数名可能是 RSP 或 RS Power，单位是 dBm，现场常见设置在 10~20 之间，具体按规划表来，别凭感觉敲。

查依赖关系才是真正考验经验的地方。改 TAC 要看周边邻区的 TAC 分布、寻呼边界；改 PCI 要扫周边同频小区有没有冲突；改 EARFCN 要考虑终端频段支持和带宽配置。这些依赖关系不查，改完大概率出连锁问题。

查回退基线就是给操作买“后悔药”——把修改前的 LST 输出存成文件，改完再存一份，两者对比。万一改完指标变差，恢复就有依据，不用靠回忆。

# 修改前快照：记录该小区当前全部参数 LST CELL:CELLNAME=市区_02; # 执行修改：调整下行参考信号功率，参数值以规划表为准 SET CELL:CELLNAME=市区_02,RSP=15; # 修改后立即复核，确认状态与参数符合预期 LST CELL:CELLNAME=市区_02;

SET 指令执行后不会自动备份旧值，恢复完全靠人工改回。所以“前后对照”不是流程仪式，是真正的保命习惯。我见过最惨的一次事故：同事在网管上批量改了二十个小区的某个参数，指标恶化后想回退，发现没存任何修改前记录，只能一个站一个站猜。所以我的做法很朴素：改任何一个写类指令（SET/BLK/UBL/CREATE），先在本地记事本里粘贴好修改前输出，标注日期和工单号。

4.2 邻区添加三步：外部小区、同频邻区、激活验证

邻区配置是现场最高频的写操作之一，也是最容易埋雷的。爱立信LTE后台里，邻区关系不是一条指令搞定的，逻辑上分两层：外部小区定义和邻区关系。外部小区是“目标小区的身份信息”，邻区关系是“本小区允许切换到哪些目标”。两步都配好了，切换才可能成功。

# 第一步：创建外部小区定义，参数必须与目标小区实际配置一致 ADD EUTRANEXTERNALCELL:ENODEBID=2234,CELLID=77,TAC=1002,PCI=303,EARFCN=1650; # 第二步：为本小区添加同频邻区关系并激活（异频用EUTRANINTERFREQNCELL） ADD EUTRANINTRAFREQNCELL:CELLNAME=市区_02,NEIGHBORCELLNAME=东郊_03,ACT=ACT; # 第三步：验证邻区已生效 LST EUTRANINTRAFREQNCELL:CELLNAME=市区_02;

参数含义对照：

外部小区参数里最坑的是 CELLID 和 TAC。CELLID 填错，切换请求到了目标基站，目标侧找不到这个小区，直接拒绝；TAC 填错，切换完成后终端做位置更新会失败。这两个错都表现为“切换成功率掉下去”，但告警不一定有明显提示，只能靠逐项核对。

还有一类现场高频事故叫“单向邻区”。A 小区加了到 B 小区的邻区，但 B 小区没加回指 A 的邻区，结果 A→B 切换正常，B→A 切换失败。做邻区调整时，反向关系要同时检查，尤其是只动一个站的场景。

# 双向核查：把源侧和目标侧外部小区表、邻区表、实际小区状态拉出来比对 LST EUTRANEXTERNALCELL:ALL; # 外部小区定义全量 LST EUTRANINTRAFREQNCELL:ALL; # 同频邻区关系全量 LST CELL:ALL; # 实际小区参数，用于核对前两个表

最后一步是激活验证。加完邻区不是看 LST 里出现了就完事，要看 KPI：切换成功率、切换出尝试次数有没有涨。有条件的话做一次后台跟踪或路测，确认切换正常。没有 KPI 佐证的邻区配置，都有可能是“纸面邻区”。

5. TD-LTE后台操作避坑：现场最容易翻车的四个场景

5.1 小区闭塞后忘解列，深夜被“无线不可用”叫醒

现象：白天扩容或测试，临时 BLK 了小区，收工时忘了解闭塞，晚上整片区域出现覆盖空洞投诉，值班电话被打爆。

原因：BLK/UBL 是手工状态，网管不会自动恢复，也没有定时提醒。收工时如果没人核对变更清单，这个小区就会一直“静默退服”，而且告警系统里不一定有明显提示，因为这是人为操作。

解决：把“UBL 检查”写进收工流程。每次 BLK 操作，无论多急，先在交接记录里写清“哪个小区、谁闭的、计划几点解”。收工前用 LST CELL:ALL 全量复查，所有小区必须恢复 Operational 才能离站。条件允许的话，把“检查是否有 BLK 状态小区”做成每天交接班的固定动作。

5.2 改TAC赶上忙时，位置更新风暴打满核心网信令

现象：调整某个站的 TAC 后，忙时核心网信令负荷暴涨，位置更新成功率下降，周边用户出现寻呼失败。

原因：TAC（跟踪区码）改动等于强制终端重新注册跟踪区。一个站覆盖范围内如果有大量空闲用户，改完 TAC 他们会集中发起 TAU 请求，形成位置更新风暴。TAC 不是现场随便改的数字，它由核心网统一规划，边界改动影响寻呼区域和信令负荷。

解决：改 TAC 前先确认两件事：新 TAC 值是不是核心网分配且全网唯一的；改动时间是不是安排在凌晨低峰。一次只改一个边界小区，改完观察 TAU 成功率，不要贪多。忙时打死不动 TAC，这条建议是从翻车现场学来的。

5.3 邻区看着都加了，切换就是失败

现象：外部小区建了、邻区也加了，配置看起来齐全，但切换成功率不到一半，目标小区频繁有切换请求失败。

原因：最常见有三类。一是外部小区表里的 CELLID、PCI、TAC 与目标站实际输出不一致，目标侧找不到对应小区；二是只加了单向邻区，目标小区没有回指，反向切换失败；三是周边同频 PCI 冲突，目标小区识别混乱。

解决：按“实际配置→外部小区表→邻区表”三方比对，逐字段核对。用前面第 4 章的三条 LST 指令拉全量数据，把 CELLID、PCI、TAC、EARFCN 逐项对一遍。再检查双向邻区是否都存在。最后扫一下周边同频小区的 PCI，遵循同频 mod3 不重复的规则，有冲突先改 PCI 再谈切换。

5.4 熟悉的指令报“不存在”，或一直排队不执行

现象：同样的查询指令，上个站点还能跑，这个站点报语法错误；或者指令敲下去后一直转圈不出结果，像是被卡住了。

原因：爱立信不同 OSS 版本、不同 Release 的命令名有差异，小区对象可能叫 CELL，也可能叫 EUTRANCELL，命令动词不同版本也有差别。另一个常见原因是并发锁——其他维护账号正在对同一网元执行写操作，你的指令在排队或直接被拒绝。

解决：遇到命令名不识别，先用 HELP 查当前版本的实际指令，不要硬凭记忆敲。遇到排队不执行，先确认网元上是否有其他账号在线操作，有就等或沟通，避免同时做写操作。只读查询类指令高峰期也尽量错开，减少人为制造的操作冲突。

6. 把高频指令固化成模板：用脚本习惯给后台操作上保险

6.1 一份可复用的后台高频查询批处理

后台操作里真正的高频动作其实是查询，不是修改。我把每日常规体检的查询指令做成了一个固定模板，登录后按顺序执行一遍，不遗漏。

# 登录后标准“体检”序列，逐条执行 LST EQP:ALL; # 硬件单板状态 LST CELL:ALL; # 小区状态与基本参数 LST ALMAF; # 当前活动告警 LST EUTRANEXTERNALCELL:ALL; # 外部小区定义全量 LST EUTRANINTRAFREQNCELL:ALL; # 同频邻区关系全量

执行时注意：如果当前 OSS 版本不支持把整批指令一股脑喂进去，就一条一条复制执行，每一条等回显。模板的作用是防止漏查，不是让你省敲键盘的时间。熟悉这套动作之后，一个站的“体检报告”五分钟内就能出来，这比在图形界面里到处点高效得多。

6.2 变更留痕：每次改参数前必做的“前后对照”

这两年我养成了一个习惯：每次做任何写操作，都建一个以日期命名的文本文件，前半段贴修改前的 LST 输出，中间贴工单号和操作目的，后半段贴修改后的 LST 输出。文件存到共享目录或群里，项目里所有人都能查到。

这个习惯救过我一次。有一回改邻区后出现切换异常，排查到半夜，最后就是靠修改前的输出比对出是 TAC 填错了一位数字。如果没有那份留痕，只能一个个字段猜。

后台操作这事，最怕的不是技术难，而是改完回不了头。把查询模板固化、把变更留痕做扎实，爱立信LTE后台操作就不是高风险动作，而是可以稳定复制的标准流程。希望帮到你。

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