简介文档聚焦爱立信LTE后台操作是一份面向网络运维、优化与工程人员的命令手册。手册以具体命令为主线系统梳理了功率查询lh ru psv、PUCCH信令参数查看、邻区关系管理、ENB ID与GPS卫星状态检查、License授权确认、RRU硬件故障排查、时隙与帧同步配置、干扰监测、发射功率调整、单双流判定、B2与A1A2门限调整等常用后台操作并针对每条命令补充知识点解析说明其在功率控制、物理信道承载、网络同步和干扰抑制中的实际作用帮助读者理解命令背后含义并快速定位故障。内容还涵盖mobatch批处理、trace跟踪、CV保存、解闭小区、traceroute路由追踪等进阶技巧适合日常巡检、参数核查与告警处理。资源包仅含1个docx文档大小19KB轻量易携已有463人学习是一份紧凑而实用的爱立信LTE后台命令参考。1. 一本人肉备忘的爱立信 LTE 后台命令手册能不能照着敲接入网后台这活儿比的是谁手里命令全。设备型号一换、网管版本一升级以前背下来的命令经常对不上号翻手册又太慢。这份爱立信 LTE 后台操作指导命令手册就是把日常运维里最高频的那批指令按场景收敛成了一串可以直接抄的列表查功率、查邻区、查干扰、闭站解锁、改门限、加 trace、全网批处理闭站乃至进入 complete 模式改系统常量全都有对应的命令模板。它不解释 LTE 协议原理只解决三个最实际的问题设备不认识、命令记不全、操作不敢下手。新员工照着敲能上手老员工拿来当快速索引也省事。适合日常做 LTE 优化、单验、告警处理和批量脚本维护的人。2. 高频巡检命令分组先会查再谈改后台操作的第一步永远是“查”。查功率、查驻波、查 RRU 故障、查邻区、查时隙、查干扰这些命令在网络上流传得碎片化严重文档里把它们按场景归好了我按实际操作顺序拆开讲。2.1 功率、驻波与 RRU 硬件健康检查功率问题是最常见的投诉来源。站点刚开出来就发现覆盖偏弱第一件事是确认 RRU 有没有实际发射功率而不是直接怀疑天馈接反或者参数没生效。# 查看 RRU 发射功率三个 0 代表从第一个 RRU 的第一个端口开始 lh ru txtorPwr 0 0 0 # 查看功率相关状态 lh ru psv # 检查 RRU 硬件故障 lh ru fm getfaults # 查看驻波比告警门限 get . vswrlh ru txtorPwr 0 0 0的意思是列出指定 RU 端口上的发射功率读数输出里如果看到功率远低于小区配置功率说明 RRU 可能没有起振或者载波未建立。lh ru psv查看的是 RU 的运行状态能看到 Active 还是 Standby。lh ru fm getfaults直接拉 RRU 的硬件故障列表比在网管告警系统里干等刷新快得多。做硬件排障时我一般先跑这三条再结合get . vswr的驻波门限判断天馈系统是否正常。参数说明0 0 0分别是 RU 编号、端口编号和载波编号多 RRU 站点需要逐个 RU 依次指定。如果不带参数直接跑部分网管版本会进入交互式选择。2.2 邻区查询pr relation与全网邻区导出邻区关系是优化工作里最容易被拆散的数据。单站查邻区用pr relation但全网邻区核对必须走 mobatch否则一个站一个站登录半天就过去了。# 单站查询当前所有邻区 pr relation # 单站查看邻区数量统计 prs cellrelation # 全网邻区导出不含 PCI mobatch /home/Administrator/moshell/sitefiles/ipdatabase lt all; alt; pr relation; cvls # 全网邻区导出含 PCI mobatch -o ipdatabase lt all; get ExternalUtranCellTDD physicalCellIdentitypr relation输出的是完整的邻区表包含小区标识、频点、PCI 等关键字段。prs cellrelation只看统计数量用来快速确认这个站的邻区是否漏配。两条命令配合使用先看数量对不对再看明细缺不缺。全网导出的两条命令格式非常像区别在于第一条用pr relation直接输出邻区列表但不含外部小区的 PCI第二条通过get ExternalUtranCellTDD physicalCellIdentity从外部小区定义里取 PCI。需要做 PCI 冲突核查或者邻区冗余分析时用第二条。注意点mobatch -o的-o参数是让输出结果实时打印到终端不加-o时结果会汇总到 log 文件里交互式查看更直观脚本化运行时反而建议不加。pr relation 得到的邻区明细里没有 PCI这是很多人在做全网邻区核查时踩的坑。2.3 时隙、干扰与用户接入状态时隙配比查错会导致上下行速率倒挂干扰查不到会导致速率忽高忽低用户接入数查不到就无法判断小区是否真正在吸收话务。# 查看时隙配置及配比 get . subframe get . framestartoffset # 查看上行干扰功率 pget . pmRadioRecInterferencePwr$ # 查看当前接入用户数 ue print -admitted # 查看频点与基站信息 get . earfcn get . enbidget . subframe输出里重点看特殊子帧配置和上下行配比模式TDD 站点改过specialSubframePattern后必须回来确认这一项。get . framestartoffset是帧同步偏置多个站点如果 offset 不统一切换时容易出问题。干扰用pget . pmRadioRecInterferencePwr$拉的是上行每个 PRB 的干扰功率末尾的$是通配符能匹配同前缀的全部计数器实例。ue print -admitted直接显示当前处于 admitted 状态的用户数是判断小区是否“有人在用”的最快手段。get . earfcn查频点get . enbid查基站全局标识核对工参时这两条命令比翻网管界面快。时隙配比的修改动作和查询是两套指令查询用get . subframe修改走set1加上specialSubframePattern参数这在后面参数修改章节会展开。遇到用户反馈“下载慢、上传正常”的投诉优先看 subframe 配比再看不看干扰这个顺序能省不少排查时间。3. 批量操作与数据提取让命令替人跑腿单站命令记得再熟遇到全网批量操作也只能干瞪眼。mobatch 批处理、grep 数据提取、CV 配置保存这三板斧是后台工程师把工作效率提上去的关键。3.1 mobatch 全网操作从单站命令到全网执行mobatch 的核心逻辑是读入一个站点列表文件对里面每一个站点执行同一串命令。这个站点列表就是 ipdatabase 文件里面每一行是一个站点的 IP 地址信息。理解了这个文件结构全网操作的门槛就降低了。# 全网闭站对所有站点执行 lt all; bl cell mobatch /home/Administrator/moshell/sitefiles/ipdatabase lt all; bl cell # 全网查告警 mobatch /home/Administrator/moshell/sitefiles/ipdatabase lt all; alt # 全网查邻区数量 mobatch ipdatabase lt all; prs cellrelationlt all的作用是加载站点下所有 MObl cell是阻塞小区闭站alt是查告警。mobatch 会把这两条命令按顺序在列表里每一个站点上执行执行结果按站点汇总输出。闭站操作的批次命令里我习惯在bl cell之前加lt all因为不加载 MO 直接操作小区对象部分版本会报对象不存在。全网闭站的场景常见于批量更换传输、批量升级抢修操作前建议先跑一遍mobatch ... lt all确认站点可登录再执行闭站。3.2 数据提取与配置备份grep 合并 logcv 保存现场网管上跑完 mobatch 会产生一堆 log 文件这些 log 文件通常分散在各自的站点目录下手工一个个打开跟大海捞针一样。用 grep 把它们合并到一个文件里是提取数据的标准做法。# 将网管上跑完的 log 内容合并为一个文件并以 excel 格式输出 grep 2014- *.log 111.xls # 保存当前配置 CV cvms # 查看已有配置版本 cvlsgrep 2014- *.log 111.xls的作用是匹配所有 log 文件中包含“2014-”的行把结果重定向到111.xls。这里的“2014-”是时间戳过滤条件实际使用时替换成当天日期或某个批次标记就能只提取对应时间段的操作记录。文件命名里的.xls后缀只是便于用表格工具打开内容本质上是文本。cvms 和 cvls 是配套动作cvms 保存当前配置快照cvls 列出已有快照硬件更换或参数批量修改之前先存一份 cv是花十秒买一份后悔药。3.3 功率调整与单站参数对齐小区功率配置错了最直接的影响就是覆盖范围不对。调功率前必须先确认硬件能力再确认当前生效值最后才动手改。# 查询当前功率配置 get . power # 修改指定小区发射功率60000 表示 60W set SectorEquipmentFunction3 configuredOutputPower 60000get . power查看的是小区功率相关配置输出里包含configuredOutputPower和maxOutputPower等关键参数。修改时指定SectorEquipmentFunction3是定位到第三个扇区功能对象configuredOutputPower 60000把配置功率改为 60000 mW。参数说明60000的单位是毫瓦对应 60W不同 RRU 型号支持的最大输出功率不同改之前一定对照硬件规格。改完后用get . power回查确认生效部分网管版本需要执行激活命令后配置才会下发到 RRU。另一个容易被忽略的细节是功率调大后要观察驻波告警和 RRU 温度超过硬件承受范围会直接触发 shutdown。4. 参数修改与 License 操作改坏了怎么办查询命令只是热身真正的难点在改参数和操作 License。改错一个门限值全网切换行为都会乱License 状态不对基站直接起不来。4.1 切换测量门限该怎么改B2/A1/A2 门限调整切换门限在爱立信设备上是分事件配置的。B2 是异系统切换的事件A1/A2 是同系统内测量控制的事件这两类门限调整直接影响终端的测量上报行为。# 调整 B2 门限将该站 3 小区 B2 门限调整为 -95 set EUtranCellTDD13,UeMeasControl1,ReportConfigB2Utra1 b2Threshold1Rsrp -95 # 调整 A1/A2 门限将该小区 A1/A2 门限调整为 -90 set EUtranCellTDD11,UeMeasControl1,ReportConfigSearch1 a1a2SearchThresholdRsrp -90set后面跟的是完整的 MO 路径EUtranCellTDD13表示 TDD 小区编号 13UeMeasControl1是该小区的测量控制对象ReportConfigB2Utra1是 B2 事件的报告配置实例。b2Threshold1Rsrp -95把这套配置里的 B2 门限设为 -95 dBm。A1/A2 命令同理只是把报告配置对象换成了ReportConfigSearch1参数换成了a1a2SearchThresholdRsrp。门限值填的是负数注意别把负号丢了丢了以后终端测量上报逻辑会直接乱掉。改完后建议在另一个窗口跑get . XXX去核对实际操作中用get . a1a2SearchThresholdRsrp拉当前值最直接。4.2 特殊子帧配比修改set1 与 set 的区别TDD 站点的特殊子帧配比specialSubframePattern决定了 DwPTS、GP、UpPTS 的时隙长度改错了直接上下行吞吐量跳水。文档里特意标注了修改时要用set1而不是set这里面的门道值得说清楚。# 修改特殊子帧配比为 7注意是 set1不是 set set1 EUtranCellTDD specialSubframePattern 7set1和set的区别在于set1会先列出目标 MO 的确认列表执行前让你看清楚这次操作会影响到哪些小区并且要求确认 y/nset直接执行不会弹确认列表。批量站点操作时误用set的风险在于如果参数没带小区编号可能把所有小区一次性改掉而set1至少给一次反悔机会。文档里的操作实例显示set1修改时网管会列出三个 MO 并要求输入 y 确认这是一个保护机制。建议所有涉及多小区批量改参的操作都强制用set1少一次确认就多一分翻车风险。4.3 License 工程模式与告警清理License 故障是新站开站时最常见的拦路虎工程模式下基站处于半激活状态可以做单验但不能商用。了解 License 操作才知道站点为什么“起不来”。# 查询 License 状态 license iu status # 激活无 License 的基站进入工程模式可单验 license iu activate # 修改账户密码后消除 Password File Fault 告警 passwd;rbs;rbslicense iu status查看 License 文件加载状态输出里如果显示License Key File Fault说明 License 文件不匹配或已过期。license iu activate的作用是把基站激活到工程模式让无 License 的站点能进行单站验证但该模式下站点不具备商用能力。单验完成后需要执行去激活操作让基站回归正常状态。passwd;rbs;rbs是修改账户密码后消除 Password File Fault 告警的组合命令分号分隔的三段指令在同一个会话里连续执行rbs 是重启基站进程的操作。新开站遇到起不来先查 License再查 GPS 同步然后查传输这个排查顺序能少走弯路。4.4 修改频点与查询系统指纹# 修改小区频点 acl cell changeFrequency # 查系统指纹指纹信息用于识别配置版本 get 6 # 查询 RRU 具体型号 get AuxpluginunitRRU # 查看 GPS 卫星数量与同步状态 get . inview stsacl cell changeFrequency是操作类命令执行后会进入交互式选择提示你输入要修改的小区和目标频点适合在网管侧手工操作。get 6查的是整个节点的 fingerprint用于确认当前配置版本基线。get AuxpluginunitRRU返回 RRU 型号扩容板卡或更换硬件前必须先确认型号匹配。get . inview查看当前可见卫星数sts是同步状态检查GPS 跑偏导致的基站不同步问题这两条命令配合能快速定位。5. 避坑记录后台操作最容易翻车的五个瞬间后台命令的坑往往不在命令本身而在执行时机和执行上下文。整理几条我实际遇到过的翻车记录每一条都对应文档里某个命令的误用场景。5.1 set 改了全网所有小区而不是目标小区现象只想改一个小区 A1/A2 门限结果全网所有小区都变了。原因set命令后没有指定小区编号直接用了set EUtranCellTDD,UeMeasControl1,ReportConfigSearch1 a1a2SearchThresholdRsrp -90设备把所有小区都当作目标。解决写set命令时EUtranCellTDD后面必须带等号和数字例如EUtranCellTDD11批量场景改用set1让系统先弹确认列表看到脚本里涉及几个 MO 再按 y。从那以后我每次批量改参都强制用set1核对目标数这个习惯救了我好几次。5.2 mobatch 批处理跑完一个站点都没执行现象mobatch 命令敲完终端刷了一屏信息但实际站点没有任何操作日志。原因ipdatabase 指定的路径错误或者站点列表文件里 IP 和登录账号不匹配mobatch 登录失败后在继续跑下一个站点。解决先手动moshell登录列表里的第一个站点确认 IP 和账号正确再执行mobatch ... lt all这种无害命令验证连通性最后才跑bl cell这种操作类命令。注意mobatch不会因为你列表里有一个站点登录失败就停止它会跳过继续跑所以跑完必须检查结果汇总文件里每个站点是否有成功输出。5.3 bl cell 闭站后忘了恢复现象全网闭站操作完成后部分站点迟迟没有恢复业务。原因bl cell执行时没有记录原始状态操作完成后用deb cell逐站解锁漏掉了其中几个站。解决闭站前先跑deb cell确认所有小区处于解锁状态闭站后写一个恢复脚本统一执行deb cell。文档里其实给了对应命令deb cell解锁和bl cell闭锁但实际操作中很多人闭站后直接关了终端恢复时全靠记忆这是最不应该犯的低级错误。我的做法是闭站批次脚本里同时生成恢复批次脚本闭站完成立刻保存一份现场截图双保险。5.4 trace 结束忘了归还默认配置现象做完 trace 后网络侧出现信令采集异常网管人员排查发现 trace 配置还挂在原小区上。原因trace 结束后直接关终端没有执行mon-te default和te default restart把配置还原。解决trace 做完按文档里的流程操作结束抓包后执行mon-te default恢复 monitor 设置再执行te default restart重启 trace 相关进程最后确认fte ststus显示无残留配置。trace 是诊断工具但也是现网风险源开 trace 前要记录原配置关 trace 后必须验证配置已还原。5.5 License 工程模式激活后没去激活站点无法商用现象新站单验完成数据配置全部正确但站点无法商用。原因license iu activate执行后基站进入了工程模式单验结束后没有执行license iu相关命令恢复正式 License 状态基站一直停留在受限模式。解决单验完成后执行license iu status确认当前状态如果还在工程模式则执行license iu activate的反向操作恢复。License 相关操作建议在做之前先截图记录原状态避免误操作后无法还原。进入 complete 模式修改系统常量时也要注意路径parsemom /var/opt/ericsson/amos/jarxml/ERBS_NODE_MODEL_D_1_189_COMPLETE.xml.cache.gz加载后lt all才能看到全部 MO不然很多高级参数就是黑的。6. 用 trace 玩一次信令级排障从原始流到可视化后台操作不只是跑几条命令trace 是信令级排障的利器。文档里把 trace 采集和解析的整条命令链都列出来了这里展开讲透。# 启动 trace 采集并实时解析 /home/user/moshell/monitor6054 100.92.1.50 33077 | ./ltetools/ltng -s | ./ltetools/lteflowfox.pl -lac | tee firsttrace.log这条命令链拆开看monitor6054是 moshell 的 trace 采集脚本100.92.1.50 33077是对端 IP 和端口ltng -s是协议解码工具把原始二进制流转成文本lteflowfox.pl -lac是流程分析脚本-l是记录流程信息-a是所有流程-c是控制面tee firsttrace.log同时把输出写到文件并显示在终端。整条链的作用是采集信令原始流 → 解码成文本 → 按流程归类 → 落盘保存。这个命令链适合做切换失败、掉线率高、RRC 建立失败这类问题的定位你不再需要去网管侧翻原始信令直接在终端里看解析后的流程。掌握 trace 的前提是理解它由采集端和解析端两部分组成。采集端负责把信令从基站拉出来解析端负责把十六进制变成人能看懂的 LTE 信令流程。文档里还给了查看帮助的命令lteflowfox.pl -h第一次使用某个脚本前先跑-h把参数选项过一遍能避免命令行写错方向。完整 trace 流程建议按这个顺序操作先te e all系列命令开启各接口的 trace 采集再执行抓包命令链结束后用mon-te default和te default restart还原现场。我自己的经验是trace 抓完先不要急着关窗口把firsttrace.log里的失败流程关键词过一遍例如 RRC 建立失败、S1AP 重置、切换准备失败等再决定是否调整抓包条件。因为 trace 重开的成本不低一次抓全比反复抓取高效得多。还有一个小建议trace 文件名里带上日期和站点标识例如HLX_issue_cell11_20250421.log归档和回溯时能省不少事。做后台维护这行细节就是效率命令背得再熟不如把每个坑都记下来。文档里那些命令看起来零散组合起来却是一套完整的排障思路希望对你有用。本文还有配套的精品资源点击获取 
长河君 · 2026/10/22 7:40:28 · 阅读 1.2k 爱立信LTE后台命令手册：从功率查询到批量操作与排障实战
简介文档聚焦爱立信LTE后台操作是一份面向网络运维、优化与工程人员的命令手册。手册以具体命令为主线系统梳理了功率查询lh ru psv、PUCCH信令参数查看、邻区关系管理、ENB ID与GPS卫星状态检查、License授权确认、RRU硬件故障排查、时隙与帧同步配置、干扰监测、发射功率调整、单双流判定、B2与A1A2门限调整等常用后台操作并针对每条命令补充知识点解析说明其在功率控制、物理信道承载、网络同步和干扰抑制中的实际作用帮助读者理解命令背后含义并快速定位故障。内容还涵盖mobatch批处理、trace跟踪、CV保存、解闭小区、traceroute路由追踪等进阶技巧适合日常巡检、参数核查与告警处理。资源包仅含1个docx文档大小19KB轻量易携已有463人学习是一份紧凑而实用的爱立信LTE后台命令参考。1. 一本人肉备忘的爱立信 LTE 后台命令手册能不能照着敲接入网后台这活儿比的是谁手里命令全。设备型号一换、网管版本一升级以前背下来的命令经常对不上号翻手册又太慢。这份爱立信 LTE 后台操作指导命令手册就是把日常运维里最高频的那批指令按场景收敛成了一串可以直接抄的列表查功率、查邻区、查干扰、闭站解锁、改门限、加 trace、全网批处理闭站乃至进入 complete 模式改系统常量全都有对应的命令模板。它不解释 LTE 协议原理只解决三个最实际的问题设备不认识、命令记不全、操作不敢下手。新员工照着敲能上手老员工拿来当快速索引也省事。适合日常做 LTE 优化、单验、告警处理和批量脚本维护的人。2. 高频巡检命令分组先会查再谈改后台操作的第一步永远是“查”。查功率、查驻波、查 RRU 故障、查邻区、查时隙、查干扰这些命令在网络上流传得碎片化严重文档里把它们按场景归好了我按实际操作顺序拆开讲。2.1 功率、驻波与 RRU 硬件健康检查功率问题是最常见的投诉来源。站点刚开出来就发现覆盖偏弱第一件事是确认 RRU 有没有实际发射功率而不是直接怀疑天馈接反或者参数没生效。# 查看 RRU 发射功率三个 0 代表从第一个 RRU 的第一个端口开始 lh ru txtorPwr 0 0 0 # 查看功率相关状态 lh ru psv # 检查 RRU 硬件故障 lh ru fm getfaults # 查看驻波比告警门限 get . vswrlh ru txtorPwr 0 0 0的意思是列出指定 RU 端口上的发射功率读数输出里如果看到功率远低于小区配置功率说明 RRU 可能没有起振或者载波未建立。lh ru psv查看的是 RU 的运行状态能看到 Active 还是 Standby。lh ru fm getfaults直接拉 RRU 的硬件故障列表比在网管告警系统里干等刷新快得多。做硬件排障时我一般先跑这三条再结合get . vswr的驻波门限判断天馈系统是否正常。参数说明0 0 0分别是 RU 编号、端口编号和载波编号多 RRU 站点需要逐个 RU 依次指定。如果不带参数直接跑部分网管版本会进入交互式选择。2.2 邻区查询pr relation与全网邻区导出邻区关系是优化工作里最容易被拆散的数据。单站查邻区用pr relation但全网邻区核对必须走 mobatch否则一个站一个站登录半天就过去了。# 单站查询当前所有邻区 pr relation # 单站查看邻区数量统计 prs cellrelation # 全网邻区导出不含 PCI mobatch /home/Administrator/moshell/sitefiles/ipdatabase lt all; alt; pr relation; cvls # 全网邻区导出含 PCI mobatch -o ipdatabase lt all; get ExternalUtranCellTDD physicalCellIdentitypr relation输出的是完整的邻区表包含小区标识、频点、PCI 等关键字段。prs cellrelation只看统计数量用来快速确认这个站的邻区是否漏配。两条命令配合使用先看数量对不对再看明细缺不缺。全网导出的两条命令格式非常像区别在于第一条用pr relation直接输出邻区列表但不含外部小区的 PCI第二条通过get ExternalUtranCellTDD physicalCellIdentity从外部小区定义里取 PCI。需要做 PCI 冲突核查或者邻区冗余分析时用第二条。注意点mobatch -o的-o参数是让输出结果实时打印到终端不加-o时结果会汇总到 log 文件里交互式查看更直观脚本化运行时反而建议不加。pr relation 得到的邻区明细里没有 PCI这是很多人在做全网邻区核查时踩的坑。2.3 时隙、干扰与用户接入状态时隙配比查错会导致上下行速率倒挂干扰查不到会导致速率忽高忽低用户接入数查不到就无法判断小区是否真正在吸收话务。# 查看时隙配置及配比 get . subframe get . framestartoffset # 查看上行干扰功率 pget . pmRadioRecInterferencePwr$ # 查看当前接入用户数 ue print -admitted # 查看频点与基站信息 get . earfcn get . enbidget . subframe输出里重点看特殊子帧配置和上下行配比模式TDD 站点改过specialSubframePattern后必须回来确认这一项。get . framestartoffset是帧同步偏置多个站点如果 offset 不统一切换时容易出问题。干扰用pget . pmRadioRecInterferencePwr$拉的是上行每个 PRB 的干扰功率末尾的$是通配符能匹配同前缀的全部计数器实例。ue print -admitted直接显示当前处于 admitted 状态的用户数是判断小区是否“有人在用”的最快手段。get . earfcn查频点get . enbid查基站全局标识核对工参时这两条命令比翻网管界面快。时隙配比的修改动作和查询是两套指令查询用get . subframe修改走set1加上specialSubframePattern参数这在后面参数修改章节会展开。遇到用户反馈“下载慢、上传正常”的投诉优先看 subframe 配比再看不看干扰这个顺序能省不少排查时间。3. 批量操作与数据提取让命令替人跑腿单站命令记得再熟遇到全网批量操作也只能干瞪眼。mobatch 批处理、grep 数据提取、CV 配置保存这三板斧是后台工程师把工作效率提上去的关键。3.1 mobatch 全网操作从单站命令到全网执行mobatch 的核心逻辑是读入一个站点列表文件对里面每一个站点执行同一串命令。这个站点列表就是 ipdatabase 文件里面每一行是一个站点的 IP 地址信息。理解了这个文件结构全网操作的门槛就降低了。# 全网闭站对所有站点执行 lt all; bl cell mobatch /home/Administrator/moshell/sitefiles/ipdatabase lt all; bl cell # 全网查告警 mobatch /home/Administrator/moshell/sitefiles/ipdatabase lt all; alt # 全网查邻区数量 mobatch ipdatabase lt all; prs cellrelationlt all的作用是加载站点下所有 MObl cell是阻塞小区闭站alt是查告警。mobatch 会把这两条命令按顺序在列表里每一个站点上执行执行结果按站点汇总输出。闭站操作的批次命令里我习惯在bl cell之前加lt all因为不加载 MO 直接操作小区对象部分版本会报对象不存在。全网闭站的场景常见于批量更换传输、批量升级抢修操作前建议先跑一遍mobatch ... lt all确认站点可登录再执行闭站。3.2 数据提取与配置备份grep 合并 logcv 保存现场网管上跑完 mobatch 会产生一堆 log 文件这些 log 文件通常分散在各自的站点目录下手工一个个打开跟大海捞针一样。用 grep 把它们合并到一个文件里是提取数据的标准做法。# 将网管上跑完的 log 内容合并为一个文件并以 excel 格式输出 grep 2014- *.log 111.xls # 保存当前配置 CV cvms # 查看已有配置版本 cvlsgrep 2014- *.log 111.xls的作用是匹配所有 log 文件中包含“2014-”的行把结果重定向到111.xls。这里的“2014-”是时间戳过滤条件实际使用时替换成当天日期或某个批次标记就能只提取对应时间段的操作记录。文件命名里的.xls后缀只是便于用表格工具打开内容本质上是文本。cvms 和 cvls 是配套动作cvms 保存当前配置快照cvls 列出已有快照硬件更换或参数批量修改之前先存一份 cv是花十秒买一份后悔药。3.3 功率调整与单站参数对齐小区功率配置错了最直接的影响就是覆盖范围不对。调功率前必须先确认硬件能力再确认当前生效值最后才动手改。# 查询当前功率配置 get . power # 修改指定小区发射功率60000 表示 60W set SectorEquipmentFunction3 configuredOutputPower 60000get . power查看的是小区功率相关配置输出里包含configuredOutputPower和maxOutputPower等关键参数。修改时指定SectorEquipmentFunction3是定位到第三个扇区功能对象configuredOutputPower 60000把配置功率改为 60000 mW。参数说明60000的单位是毫瓦对应 60W不同 RRU 型号支持的最大输出功率不同改之前一定对照硬件规格。改完后用get . power回查确认生效部分网管版本需要执行激活命令后配置才会下发到 RRU。另一个容易被忽略的细节是功率调大后要观察驻波告警和 RRU 温度超过硬件承受范围会直接触发 shutdown。4. 参数修改与 License 操作改坏了怎么办查询命令只是热身真正的难点在改参数和操作 License。改错一个门限值全网切换行为都会乱License 状态不对基站直接起不来。4.1 切换测量门限该怎么改B2/A1/A2 门限调整切换门限在爱立信设备上是分事件配置的。B2 是异系统切换的事件A1/A2 是同系统内测量控制的事件这两类门限调整直接影响终端的测量上报行为。# 调整 B2 门限将该站 3 小区 B2 门限调整为 -95 set EUtranCellTDD13,UeMeasControl1,ReportConfigB2Utra1 b2Threshold1Rsrp -95 # 调整 A1/A2 门限将该小区 A1/A2 门限调整为 -90 set EUtranCellTDD11,UeMeasControl1,ReportConfigSearch1 a1a2SearchThresholdRsrp -90set后面跟的是完整的 MO 路径EUtranCellTDD13表示 TDD 小区编号 13UeMeasControl1是该小区的测量控制对象ReportConfigB2Utra1是 B2 事件的报告配置实例。b2Threshold1Rsrp -95把这套配置里的 B2 门限设为 -95 dBm。A1/A2 命令同理只是把报告配置对象换成了ReportConfigSearch1参数换成了a1a2SearchThresholdRsrp。门限值填的是负数注意别把负号丢了丢了以后终端测量上报逻辑会直接乱掉。改完后建议在另一个窗口跑get . XXX去核对实际操作中用get . a1a2SearchThresholdRsrp拉当前值最直接。4.2 特殊子帧配比修改set1 与 set 的区别TDD 站点的特殊子帧配比specialSubframePattern决定了 DwPTS、GP、UpPTS 的时隙长度改错了直接上下行吞吐量跳水。文档里特意标注了修改时要用set1而不是set这里面的门道值得说清楚。# 修改特殊子帧配比为 7注意是 set1不是 set set1 EUtranCellTDD specialSubframePattern 7set1和set的区别在于set1会先列出目标 MO 的确认列表执行前让你看清楚这次操作会影响到哪些小区并且要求确认 y/nset直接执行不会弹确认列表。批量站点操作时误用set的风险在于如果参数没带小区编号可能把所有小区一次性改掉而set1至少给一次反悔机会。文档里的操作实例显示set1修改时网管会列出三个 MO 并要求输入 y 确认这是一个保护机制。建议所有涉及多小区批量改参的操作都强制用set1少一次确认就多一分翻车风险。4.3 License 工程模式与告警清理License 故障是新站开站时最常见的拦路虎工程模式下基站处于半激活状态可以做单验但不能商用。了解 License 操作才知道站点为什么“起不来”。# 查询 License 状态 license iu status # 激活无 License 的基站进入工程模式可单验 license iu activate # 修改账户密码后消除 Password File Fault 告警 passwd;rbs;rbslicense iu status查看 License 文件加载状态输出里如果显示License Key File Fault说明 License 文件不匹配或已过期。license iu activate的作用是把基站激活到工程模式让无 License 的站点能进行单站验证但该模式下站点不具备商用能力。单验完成后需要执行去激活操作让基站回归正常状态。passwd;rbs;rbs是修改账户密码后消除 Password File Fault 告警的组合命令分号分隔的三段指令在同一个会话里连续执行rbs 是重启基站进程的操作。新开站遇到起不来先查 License再查 GPS 同步然后查传输这个排查顺序能少走弯路。4.4 修改频点与查询系统指纹# 修改小区频点 acl cell changeFrequency # 查系统指纹指纹信息用于识别配置版本 get 6 # 查询 RRU 具体型号 get AuxpluginunitRRU # 查看 GPS 卫星数量与同步状态 get . inview stsacl cell changeFrequency是操作类命令执行后会进入交互式选择提示你输入要修改的小区和目标频点适合在网管侧手工操作。get 6查的是整个节点的 fingerprint用于确认当前配置版本基线。get AuxpluginunitRRU返回 RRU 型号扩容板卡或更换硬件前必须先确认型号匹配。get . inview查看当前可见卫星数sts是同步状态检查GPS 跑偏导致的基站不同步问题这两条命令配合能快速定位。5. 避坑记录后台操作最容易翻车的五个瞬间后台命令的坑往往不在命令本身而在执行时机和执行上下文。整理几条我实际遇到过的翻车记录每一条都对应文档里某个命令的误用场景。5.1 set 改了全网所有小区而不是目标小区现象只想改一个小区 A1/A2 门限结果全网所有小区都变了。原因set命令后没有指定小区编号直接用了set EUtranCellTDD,UeMeasControl1,ReportConfigSearch1 a1a2SearchThresholdRsrp -90设备把所有小区都当作目标。解决写set命令时EUtranCellTDD后面必须带等号和数字例如EUtranCellTDD11批量场景改用set1让系统先弹确认列表看到脚本里涉及几个 MO 再按 y。从那以后我每次批量改参都强制用set1核对目标数这个习惯救了我好几次。5.2 mobatch 批处理跑完一个站点都没执行现象mobatch 命令敲完终端刷了一屏信息但实际站点没有任何操作日志。原因ipdatabase 指定的路径错误或者站点列表文件里 IP 和登录账号不匹配mobatch 登录失败后在继续跑下一个站点。解决先手动moshell登录列表里的第一个站点确认 IP 和账号正确再执行mobatch ... lt all这种无害命令验证连通性最后才跑bl cell这种操作类命令。注意mobatch不会因为你列表里有一个站点登录失败就停止它会跳过继续跑所以跑完必须检查结果汇总文件里每个站点是否有成功输出。5.3 bl cell 闭站后忘了恢复现象全网闭站操作完成后部分站点迟迟没有恢复业务。原因bl cell执行时没有记录原始状态操作完成后用deb cell逐站解锁漏掉了其中几个站。解决闭站前先跑deb cell确认所有小区处于解锁状态闭站后写一个恢复脚本统一执行deb cell。文档里其实给了对应命令deb cell解锁和bl cell闭锁但实际操作中很多人闭站后直接关了终端恢复时全靠记忆这是最不应该犯的低级错误。我的做法是闭站批次脚本里同时生成恢复批次脚本闭站完成立刻保存一份现场截图双保险。5.4 trace 结束忘了归还默认配置现象做完 trace 后网络侧出现信令采集异常网管人员排查发现 trace 配置还挂在原小区上。原因trace 结束后直接关终端没有执行mon-te default和te default restart把配置还原。解决trace 做完按文档里的流程操作结束抓包后执行mon-te default恢复 monitor 设置再执行te default restart重启 trace 相关进程最后确认fte ststus显示无残留配置。trace 是诊断工具但也是现网风险源开 trace 前要记录原配置关 trace 后必须验证配置已还原。5.5 License 工程模式激活后没去激活站点无法商用现象新站单验完成数据配置全部正确但站点无法商用。原因license iu activate执行后基站进入了工程模式单验结束后没有执行license iu相关命令恢复正式 License 状态基站一直停留在受限模式。解决单验完成后执行license iu status确认当前状态如果还在工程模式则执行license iu activate的反向操作恢复。License 相关操作建议在做之前先截图记录原状态避免误操作后无法还原。进入 complete 模式修改系统常量时也要注意路径parsemom /var/opt/ericsson/amos/jarxml/ERBS_NODE_MODEL_D_1_189_COMPLETE.xml.cache.gz加载后lt all才能看到全部 MO不然很多高级参数就是黑的。6. 用 trace 玩一次信令级排障从原始流到可视化后台操作不只是跑几条命令trace 是信令级排障的利器。文档里把 trace 采集和解析的整条命令链都列出来了这里展开讲透。# 启动 trace 采集并实时解析 /home/user/moshell/monitor6054 100.92.1.50 33077 | ./ltetools/ltng -s | ./ltetools/lteflowfox.pl -lac | tee firsttrace.log这条命令链拆开看monitor6054是 moshell 的 trace 采集脚本100.92.1.50 33077是对端 IP 和端口ltng -s是协议解码工具把原始二进制流转成文本lteflowfox.pl -lac是流程分析脚本-l是记录流程信息-a是所有流程-c是控制面tee firsttrace.log同时把输出写到文件并显示在终端。整条链的作用是采集信令原始流 → 解码成文本 → 按流程归类 → 落盘保存。这个命令链适合做切换失败、掉线率高、RRC 建立失败这类问题的定位你不再需要去网管侧翻原始信令直接在终端里看解析后的流程。掌握 trace 的前提是理解它由采集端和解析端两部分组成。采集端负责把信令从基站拉出来解析端负责把十六进制变成人能看懂的 LTE 信令流程。文档里还给了查看帮助的命令lteflowfox.pl -h第一次使用某个脚本前先跑-h把参数选项过一遍能避免命令行写错方向。完整 trace 流程建议按这个顺序操作先te e all系列命令开启各接口的 trace 采集再执行抓包命令链结束后用mon-te default和te default restart还原现场。我自己的经验是trace 抓完先不要急着关窗口把firsttrace.log里的失败流程关键词过一遍例如 RRC 建立失败、S1AP 重置、切换准备失败等再决定是否调整抓包条件。因为 trace 重开的成本不低一次抓全比反复抓取高效得多。还有一个小建议trace 文件名里带上日期和站点标识例如HLX_issue_cell11_20250421.log归档和回溯时能省不少事。做后台维护这行细节就是效率命令背得再熟不如把每个坑都记下来。文档里那些命令看起来零散组合起来却是一套完整的排障思路希望对你有用。本文还有配套的精品资源点击获取