简介中兴LTE网管操作指导书最全版是一份面向LTE网优与运维人员的实操手册重点解决翻频改造中的参数修改与脚本制作难题。内容从规划数据导出与脚本表整理讲起覆盖小区属性表修改、4G到4G外部小区表调整以及4G到2G外部小区与邻区表“先删除原有外部小区和邻区、再按新LAC/CI继承添加”的特殊处理方式同时对脚本导入中的整表同步、增量同步环节做了明确说明。指导书还延伸介绍了干扰与性能监控手段包括频谱扫描监控小区级干扰、实时CPU利用率观察、小区信令跟踪、灌包测试以及基于A4事件的测量配置和LTE SON X2功能商用部署要点方便一线工程师按流程查漏补缺。资源为单个doc文档压缩包大小48.51MB图文步骤清晰可直接用于LTE日常维护、翻频项目与网络优化现场。目前已有390人学习下载适合需要快速掌握中兴LTE网管操作、尤其是翻频与邻区调整流程的通信工程师。1. 中兴 LTE 网管操作翻频与日常维护的核心链路真正动手做过中兴 4G 翻频的工程都清楚小区属性表只是第一张多米诺骨牌。改了 PCI、频点、LAC/CI 之后4G 到 4G 外部小区表、4G 到 2G 的外部小区表和邻区表如果不跟着改轻则邻区漏配重则切换失败、掉话率飙升。这份《中兴 LTE 网管操作指导书》就是把这条链路完整串起来的实战手册从翻频脚本制作、三步导入同步到频谱扫描、CPU 监控、信令跟踪、灌包验证和小区级 A4 事件创建。它适合正在做中兴 4G 日常运维、频率重耕、割接验证以及准备 SON X2 功能部署的无线工程师——新手能照着步骤做出第一版脚本熟手也能用来规范自己的操作顺序避免在最容易被忽略的外部小区表和同步勾选上翻车。提示本文按指导书的操作主线展开所有步骤都以中兴 ZXUN RAN 网管为操作对象脚本制作以 Excel 规划数据为基础。2. 翻频脚本制作四张表按顺序改别从邻区表下手2.1 规划数据导出与 Index 索引定位翻频脚本制作的第一步不是打开 Excel 就开始改而是先把修改区的规划数据从网管里带出来。指导书里明确强调导出时先选择修改区数据配置好导出范围再点导出。这里有一个容易被忽略的细节导出后得到的是一个压缩包解压开后不要急着在第一个 SHEET 里翻数据而是直接进第二个 SHEET名字为 Index这个 SHEET 相当于整份规划数据的目录索引里面带蓝色字体索引点击即可直接跳转到对应的小区属性表。我一般会在拿到解压文件后先确认这个 Index SHEET 里的表名清单把它当作校验基准。因为后续四张表的修改都基于同一份规划数据Index 里能看到哪些表有数据、哪些表为空能提前判断这次翻频涉及的表范围。如果 Index 里出现表名缺失大概率是导出时表类型没勾全需要返回重新导出。# 解压规划数据包的常见做法Windows 环境直接右键解压即可 # 如果是在 Linux 跳板机上操作使用 unzip 命令 unzip 修改区规划数据.zip -d /data/refarming_plan/ ls -la /data/refarming_plan/ # 确认解压后包含 Index SHEET 对应的 Excel 文件再开始后续修改参数说明导出范围是修改区而不是全网这一步是为了控制脚本体量避免整表同步时波及无关小区导出格式选择 Excel因为后面的脚本制作要在 SHEET 间跳转修改Index SHEET 是整个文件的目录索引蓝色字体索引是超链接不是普通文本Excel 里需要用鼠标点击才能跳转。从实际操作来看导出规划数据时最容易出问题的是修改区选择。修改区是按基站或按小区圈定的圈小了会导致脚本不完整圈大了会让整表同步的耗时翻倍。建议按翻频方案的方案编号逐站核对确保修改区覆盖所有待翻频站点。2.2 小区属性表和 4G-4G 外部小区表同方案不同列从 Index 跳转到小区属性表后接下来就是按翻频方案逐小区修改。需要修改的字段一般是物理小区标识PCI、频点EARFCN、LAC、CI 等核心参数每一行代表一个小区修改完成后把对应行的操作指示列标成M表示这条记录需要执行修改操作。然后删除不需要修改的数据行只保留标记了M的小区。这里有一个排序上的坑小区属性表是按小区维度组织的一行一个小区的完整属性但 4G 到 4G 外部小区表是按邻区关系组织的它记录的并不是本小区自己是什么而是本小区看到的对端小区长什么样。所以修改外部小区表之前必须先搞清楚翻频方案里哪些小区的 PCI/频点发生了变化再同步更新外部小区表里对应的对端记录。4G-4G 外部小区表和 4G 邻区表之间有一个强依赖关系基站与小区之间加邻区之前必须先添加外部小区。如果外部小区表里对端小区的 PCI/频点没改而后台已经按新 PCI 建立了邻区就会造成外部小区和实际邻区配置不一致切换时目标小区无法被正确识别。表名数据来源修改的核心字段操作方式4G 小区属性表规划数据 Index 跳转PCI、EARFCN、LAC、CI逐行修改标记 M删除无关行4G-4G 外部小区表同一份规划数据对端小区 PCI、EARFCN按翻频方案同步修改4G-2G 外部小区表同一份规划数据LAC、CI先删除原记录再按新 LAC/CI 添加4G-2G 邻区表同一份规划数据LAC、CI、邻区属性先删除原邻区按继承关系添加4G 小区属性表和 4G-4G 外部小区表有一个共性都是改而不是删。只要小区本身还存在属性表就是更新记录外部小区表也是更新对端描述。但 4G-2G 的表完全不同这一点指导书里特别做了区分也是翻频脚本制作里最容易做错的一步。2.3 4G-2G 外部小区与邻区表先删后加继承关系不能断4G 到 2G 的外部小区表和邻区表修改方式异于 4G 侧。原因在于 2G 侧没有像 4G-4G 那样方便的按对象更新机制外部小区和邻区的识别依赖 LAC 和 CI 的组合。翻频方案一旦改了 LAC 或 CI原来记录里的 LAC/CI 就失效了直接在原记录上改会造成网管侧无法正确解析。所以指导书明确要求把原有的 4G-2G 外部小区和邻区先删除再按照新的 LAC 和 CI在原有的邻区关系上继承添加。继承添加这四个字值得展开。删除旧的外部小区之后邻区表里关联这个外部小区的记录也要一并处理——很多人在修改时只删了外部小区表走完导入手续后才发现邻区表还残留着对已删除外部小区的引用导致全网邻区一致性检查报错。正确的顺序是先处理 4G-2G 邻区表把涉及这些 2G 小区的邻区记录删掉再删对应的外部小区表记录导入时则反过来先加外部小区表再加邻区表保证添加时外部小区已经存在。# 制作 4G-2G 表时用 Python 脚本辅助校验先删后加逻辑 import pandas as pd # 读取规划数据中的四张表 cell_table pd.read_excel(plan.xlsx, sheet_name小区属性表) ext_4g_table pd.read_excel(plan.xlsx, sheet_name4G-4G外部小区表) ext_2g_table pd.read_excel(plan.xlsx, sheet_name4G-2G外部小区表) nbr_2g_table pd.read_excel(plan.xlsx, sheet_name4G-2G邻区表) # 校验4G-2G 邻区表里引用的外部小区必须存在于 4G-2G 外部小区表 nbr_keys set(zip(nbr_2g_table[LAC], nbr_2g_table[CI])) ext_keys set(zip(ext_2g_table[LAC], ext_2g_table[CI])) missing nbr_keys - ext_keys if missing: print(以下邻区缺少对应的外部小区, missing) else: print(校验通过所有 4G-2G 邻区均有外部小区对应)这段脚本的逻辑说明它把邻区表和外部小区表按 LAC 和 CI 两个字段做集合比对找出邻区表里有、外部小区表里没有的记录。常见做法是每次制作完脚本都跑一遍防止出现删除顺序和添加顺序不一致造成的死链。参数说明LAC 和 CI 是 2G 侧定位小区的唯一组合键不能只比其中一列如果规划数据里的列名和这里不一致需要先对齐表头再执行。做完四张表的修改脚本制作这一环才算完成。此时不要急着导入下一步的表头检查能帮你避免大部分导入后才发现的数据错位问题。3. 脚本导入三步走表头一致性和同步勾选是分水岭3.1 表头检查导出的规划数据就是校验基准脚本制作完之后指导书里有一句看似轻描淡写、实则决定成败的要求检查表头是否和导出来的规划数据完全一致不一致需调整好。这里的表头包括列顺序、列名、单元格格式任何一个不一致导入时都会出现数据串列。最常见的串列是这种情况手工在 Excel 里加了一列备注或者删除了某列导致 PCI 那一列整体右移结果导入时把备注文字填进了 PCI 字段网管直接报参数不合法。更隐蔽的是日期列、数值列被 Excel 自动转成了文本格式导入识别类型失败。所以我现在的习惯是脚本文件只保留规划数据原有的 SHEET 和列结构任何附加信息都往右添加导入前再用一行脚本来做表头比对。import pandas as pd # 以网管导出的原始规划数据为基准 base pd.read_excel(规划数据原始导出.xlsx, sheet_name小区属性表, nrows0) new pd.read_excel(翻频脚本_修改后.xlsx, sheet_name小区属性表, nrows0) base_cols list(base.columns) new_cols list(new.columns) if base_cols new_cols: print(表头完全一致可以导入) else: print(表头不一致差异如下) print(原始表头, base_cols) print(新表头, new_cols) # 逐列标记差异位置方便快速定位 for i, (b, n) in enumerate(zip(base_cols, new_cols)): if b ! n: print(f第 {i1} 列不一致原始[{b}] vs 新[{n}])这段脚本的逻辑说明用nrows0只读取表头不读数据对比两边的列名列表逐列输出差异位置。参数说明nrows0是 pandas 读取 Excel 时只取表头行的技巧速度快不占内存列顺序比较用的是列表相等判断因为导入模板对列顺序敏感不能只看列名集合是否相同。表头检查通过之后脚本就具备了导入条件。接下来进入指导书说的三步导入导入网管、整表同步、增量同步。3.2 脚本导入 整表同步 增量同步三步顺序不能乱第一步把修改好的脚本数据导入网管这一步实际上是上传待同步的配置数据到网管缓冲尚未对现网生效。第二步整表同步将目标表的全部记录按脚本内容整体覆盖同步完成后网管上该表的数据就是脚本里的数据。第三步增量同步把脚本中标记的变更增量刷到现网设备上。整表同步和增量同步的差别非常关键。整表同步操作的是表级别勾选后会把该表的全量数据推给基站适合表格内记录条数不多、且需要保证网管与基站完全一致的场景。增量同步操作的是记录级别只下发有变化的记录。翻频这种大批量修改通常两步都要走先整表保证表结构一致再增量保证变更落实到位。同步方式数据范围适用场景断链站处理脚本导入脚本中的全部记录将修改传到网管缓冲未生效不需特殊处理整表同步目标表全量数据表内记录批量刷新、结构重构不勾选断链站增量同步脚本中有变化的记录把变更下发到现网不勾选断链站注意断链站指与网管断连的基站如果勾选了断链站同步任务会一直等待或反复重试拖慢整批下发进度。指导书强调断链站不需要勾选实际执行时把断链站排除在同步之外等基站恢复链路后再补发。三条步骤做完后建议先看同步成功率和失败明细。中兴网管的同步任务页面会列出每条记录的执行状态失败的要逐条看失败原因——多数是网元不存在、参数类型不合法、或者该小区已被锁定。把这些失败项在 Excel 里标记出来修正后再次增量同步直到全部成功。3.3 断链站处理与回退预案断链站是翻频操作里绕不开的现实问题。整表同步和增量同步都不勾选断链站意味着断链基站会暂时保持旧配置。如果这个站恰好是周边站的邻区会出现周边站已经翻频完成、断链站还在用旧 PCI/频点的情况。此时邻区关系中既有新配置又有旧配置切换表现会不稳定这是正常现象不必惊慌。我一般会在动手前先导出全网断链站清单评估断链站对本次翻频方案的影响面。如果断链站较多先安排现场处理链路问题再启动翻频流程。如果只有零星几站可以先行操作等链路恢复后补一次增量同步。这里要特别提醒补同步时只补断链站涉及的记录不要重新做整表同步否则会把已完成的站点再全量刷一遍浪费资源和时间。回退预案同样要在导入前想清楚。翻频最怕的是同步到一半发现方案有问题此时全网小区处于新旧混配状态。常见做法是把原始规划数据留存一份方案调整后基于原始数据重新生成脚本而不是在已修改的脚本上再往回改。因为修改过多次的脚本很难判断哪些行已经下发、哪些行没下发一旦搞混回退就会变成二次事故。4. 实时监控三板斧频谱扫描、CPU 利用率、小区信令跟踪4.1 频谱扫描小区级干扰和底噪的实时图翻频操作完成后第一件需要确认的事情是空口环境是否干净。指导书里的实时监控小区级干扰频谱扫描就是为了解决这个问题。频谱扫描在网管上配置完成后能看到小区在目标频段上的底噪分布以频谱扫描图的形式实时呈现。实际操作步骤如下在网管菜单进入频谱扫描功能选择待扫描小区配置扫描的起始频点和终止频点选择合适的 RB 粒度然后启动扫描任务。扫描结果出来后会叠加显示在频谱图上干扰抬升的位置和幅度一目了然。扫描参数 | 常见取值 | 说明 起始频点 | 按翻频后 EARFCN 下边界 | 扫描范围的起点建议比实际频点低 1-2MHz 以观察邻频干扰 终止频点 | 按翻频后 EARFCN 上边界 | 扫描范围的终点同样建议留出边界 RB 粒度 | 100kHz 或 200kHz | 粒度越小越精细但扫描耗时增加 平均次数 | 8 次或 16 次 | 用于平滑瞬时波动底噪稳时可减少需要说明的是频谱扫描显示的是上行接收频段的底噪它对上行干扰敏感对下行干扰没有直接反映。如果频谱图上出现明显的尖峰或平台抬升优先怀疑外部干扰器、相邻小区频点重叠或天馈系统问题。做完翻频之后先扫一遍频谱能及时发现频点规划是否引入了新的互扰。4.2 CPU 利用率监控判断干扰还是负荷的辅助证据实时 CPU 利用率监控在指导书里紧跟在频谱扫描之后它的作用是回答另一个问题小区性能异常到底是干扰导致还是负荷过高导致。频谱扫描能看底噪但底噪抬升未必一定是外部干扰也可能是业务量上来后 RRU 或基带板的处理负荷升高。CPU 利用率监控就是把这块证据补齐。操作上和频谱扫描类似进入实时监控菜单选择 CPU 利用率监控添加需要监控的小区或基带板。网管以曲线形式实时刷新 CPU 占用率一般持续观察 5-10 分钟就能看到日常业务高峰期的趋势。这里有一个分辨技巧如果 CPU 利用率高但频谱扫描底噪正常基本可以判定是业务负荷或异常调度导致的如果 CPU 利用率高且频谱底噪也高才需要往干扰方向排查。反过来频谱正常但 CPU 异常高还要注意是不是开启了某些特殊功能导致额外开销比如 SON X2 功能刚部署时自动邻区关系的计算和 X2 链路维护都会增加 CPU 开销。4.3 小区信令跟踪灌包之外的定位手段频谱扫描和 CPU 监控能定位有没有问题、问题大概在什么方向但要精确定位到具体用户、具体信令流程需要用到小区信令跟踪。指导书里把小区信令跟踪放在实时监控这组操作里常见做法是先启动跟踪再复现业务最后在跟踪结果里查找异常。小区信令跟踪的配置要点和上面的监控有区别跟踪的对象是小区级别但看到的内容是信令级别的。启动跟踪前要选接口类型Uu 接口可以看到 RRC 连接建立流程、测量报告、切换命令S1/X2 接口可以看到核心网交互和基站间交互的信令。跟踪时长一般配置 15-30 分钟跟踪文件会比较大下载后需要配套的分析工具打开。# 信令跟踪文件分析的常见处理方式 # 1. 从网管下载跟踪文件通常为 .pcap 或网管自定义格式 # 2. 用 Wireshark 打开 pcap 文件按基站 IP 过滤 tcpdump -r cell_trace.pcap -nn host 10.92.x.x # 3. 统计 RRC 连接建立请求次数和失败次数 tcpdump -r cell_trace.pcap -nn host 10.92.x.x and port 36412 | wc -l信令跟踪的价值在于它能看到完整的事件链一个用户在什么时间发起了 RRC 连接请求、用的什么原因值、网络回了什么消息、切换时目标小区识别是否成功。翻频之后如果出现特定区域的切换失败先跟踪该小区 Uu 口的测量报告看 UE 上报的 PCI 是否和新规划一致能快速区分是邻区漏配、外部小区表错误还是终端行为异常。提示信令跟踪是定位手段不是排查终点。跟踪结果只能告诉你哪一步失败了失败原因需要结合频谱扫描、CPU 监控和配置查询综合判断。5. 避坑清单翻频操作中五个让我翻过车的细节5.1 整表同步勾选了断链站任务卡住不动现象整表同步开始后同步任务长时间处于等待状态进度条不动其他站点的同步也被阻塞。原因勾选了处于断链状态的站点网管侧在等待该基站回应超时时间较长期间整个同步队列被卡住。解决同步任务不要勾选断链站。操作前先导出断链站清单将断链站排除在同步范围之外断链站恢复后再单独执行一次增量同步。如果已经卡住先终止当前任务排除断链站后重新发起。5.2 表头顺序不一致PCI 数据串列到频点字段现象脚本导入网管成功但同步后查询小区发现部分小区 PCI 变成了奇怪的值和方案完全不符。原因修改脚本时在表格中间插入或删除了列导致表头顺序和原始规划数据不一致导入时数据按新表头逐列对应实际值被放进了错误字段。解决导入前跑表头比对脚本确保列名、列顺序完全一致。如果确实需要加列做备注必须加在表格最右侧且不要修改原表头行的任何内容。事后如果已经导入错误数据需要重新生成正确脚本做整表同步覆盖回来。5.3 4G-2G 外部小区表只删没加邻区全部失效现象翻频导入后4G-2G 邻区关系全部丢失终端在 4G 驻留时无法重选或切换到 2G 网络。原因制作脚本时只删除了原有 4G-2G 外部小区和邻区记录但添加新记录这一步没有做对。常见的原因是 LAC 或 CI 填写有误或者删除和添加顺序颠倒导致添加时外部小区不存在邻区添加失败。解决严格按照先删邻区、再删外部小区导入时先加外部小区、再加邻区的顺序执行。制作完脚本后用 2.3 小节里的校验脚本检查邻区表引用的外部小区是否全部存在。5.4 增量同步遗漏了修改区边缘站邻区半配现象翻频完成后全网大部分小区切换正常但修改区边缘的个别小区切换失败且失败方向固定指向几个邻小区。原因制作脚本时修改区圈选不完整边缘站的邻区涉及了修改区外的对端小区这些站的记录没有包括在脚本中增量同步自然没有下发。解决导出规划数据时按修改区 一层邻区的原则向外扩一圈保证边缘站的邻区关系涉及的站点都包含在脚本里。遇到已经完成的翻频出现漏配查询该站的邻区表把缺失的外部小区和邻区补做一次增量同步。5.5 LAC/CI 修改后 2G 侧邻区未更新出现重复配置现象4G-2G 邻区表导入成功但网管报出 LACCI 重复的配置错误且这些错误集中在同一个 2G 小区上。原因LAC 或 CI 修改后2G 侧如果已经存在同 LACCI 的邻区记录通常是历史遗留或周边站点也配了同样的组合新加记录就产生了冲突。解决添加新 4G-2G 邻区之前按 LACCI 查一下全网是否已有重复记录有则先删除旧记录再添加。此外翻频改动 LAC/CI 之后还要注意现网是否在同一改动区域内存在 V2X 场景下的 LTE 侧行链路资源池配置——侧行链路资源池依赖频点资源如果翻频动到了侧行链路使用的频段外部小区表的变化会直接影响车联终端的同频感知这类场景的邻区校验要格外仔细。6. 灌包测试与小区级 A4 事件翻频后的验证闭环6.1 灌包测试从远程桌面到基站的一条命令链翻频完成后光看配置同步成功还不够必须验证实际业务速率和切换行为。指导书里的灌包测试就是验证数据业务承载能力的直接手段。先找到网元 IP如 10.92.x.x登录远程桌面在运行窗口输入命令登录基站侧。FTP 登录基站获取灌包测试脚本然后 telnet 到基站 IP在基站侧启动灌包。# 灌包测试的典型操作链IP 以实际网元为准 # 1. FTP 登录基站获取灌包工具 ftp 10.92.x.x # 输入用户名密码后 get packet_test_script.docx quit # 2. telnet 登录基站 telnet 10.92.x.x # 进入基站命令行后执行灌包测试脚本 packet_test -u 10.92.x.y -p 5000 -t 60 -b 100M灌包测试的关键是看两个层面的速率空口侧实际速率和传输侧速率。如果空口速率明显低于传输侧优先怀疑空口质量、调制方式受限或干扰如果两侧速率都低则要检查传输链路和核心网侧配置。灌包时长一般设 60 秒带宽按基站能力配置测试过程中同时打开频谱扫描观察灌包期间底噪是否异常抬升。6.2 小区级 A4 事件与 SON X2两级验证手段灌包验证的是数据转发能力切换验证则依赖测量事件。指导书里创建小区级测量事件以 A4 事件为例A4 事件的含义是邻区质量高于绝对门限常用于跨频切换。翻频后修改了频点必须用 A4 事件替代同频常用的 A3 事件否则 UE 在异频场景下不会触发测量上报。操作上进入网管的小区测量配置选择创建小区级 A4 事件配置事件参数后添加索引集并关联到需要验证的小区。关键参数包括 A4 门限、迟滞和触发时间。参数 | 常见取值 | 说明 MeasA4Threshold | 按覆盖目标设定 | 邻区 RSRP 高于该值即触发上报 迟滞 | 1-3 dB | 防止信号在门限附近抖动导致频繁上报 触发时间 | 320ms-640ms | 信号连续满足条件的时间要求事件创建完成后配合 SON X2 功能做自动验证。指导书附带的是《LTE SON X2 功能商用部署指导书 V3.20.30》这个版本主要是让 X2 邻区关系自动发现和维护人工翻频后SON X2 会在后台自动校正漏配的 X2 邻区减少手工维护成本。从那以后我每次做完翻频脚本都会强制走一遍表头比对 → 脚本校验 → 同步确认 → 频谱扫描 → 灌包验证的完整流程缺任何一步都不敢提交割接报告。翻频这东西看着是改参数实际是改整个无线环境的平衡每一步都值得多看一眼。希望帮到你。本文还有配套的精品资源点击获取