某城市新区批量开通5G基站一周后，切换成功率从99%以上跳水到96%出头，投诉集中在一条快速路上。追了四十八小时，元凶不是天馈，不是传输，而是一串只有1008个取值的小区“工号”——PCI。本文以3GPP TS 38.211/38.300为事实基准，完整复盘一次PCI冲突引发切换劣化的排查与割接处置（案例细节已脱敏，数据为匿名化后的复合复盘），并给出可落地的参数速查表、排查决策树和PCI规划军规。 ## 目录 - 一、KPI跳水：一封凌晨告警邮件 - 二、PCI为什么只有1008个：稀缺资源的物理学 - 三、追凶四十八小时：从KPI下钻到CT测量 - 四、根因：规划导入滞后，ANR好心办坏事 - 五、处置：凌晨割接窗口的PCI重整 - 六、把教训固化成工具链 - 七、经验教训与开通前检查清单 - 参考来源 ## 一、KPI跳水：一封凌晨告警邮件 先交代背景。某省会城市的新区，为了承接一个产业园区开园，一个月内新开了47个3.5GHz宏站、一百八十多个64T64R小区。开网第七天凌晨，网优值班的手机收到性能平台的越限告警：**新区片区切换成功率从上周的99.13%跌到96.42%，RRC重建请求比从0.31%涨到1.87%**。掉话率还没爆，但趋势曲线是一条明显的斜线——这是典型的“慢性病”形态：用户还能用，但体验在恶化。 这里先解释一个背景常识：在网优的KPI体系里，切换成功率是比掉话率更敏感的“前哨指标”。切换失败如果处理不好，下一步就是无线链路失败（RLF）和掉话。所以老网优看到切换曲线跳水，就像老中医看舌苔——病还没发作，先知道哪儿不对劲。 时间线是这样的： | 时间 | 事件 | | --- | --- | | D7 00:40 | 性能平台越限告警：片区切换成功率96.42%，连续3个统计周期走低 | | D7 08:30 | 晨会分派：先查传输和天馈，同时安排路测 | | D7 14:00 | 传输侧自检无异常；投诉工单汇总，47件集中在同一条滨江快速路 | | D8 10:00 | 路测第一轮：快速路两个方向均复现“切换命令发出后T304超时” | | D8 16:00 | 提取CT测量，确认两对同频小区互报同名PCI | | D9 01:00 | 凌晨割接窗口，第一批24个小区改PCI | | D9 07:00 | 晨峰验证：切换成功率回到99%以上 | ## 二、PCI为什么只有1008个：稀缺资源的物理学 要看懂这个案子，得先弄明白PCI是什么。PCI（Physical Cell Identifier，物理小区标识）是小区在物理层的“工号”：终端开机找网，第一步就是同步信号，靠同步信号算出这个508……不对，算出这个0～1007之间的数。按照3GPP TS 38.211的定义，**NR的PCI由主同步序列号N_ID2（取值0～2）和辅同步序列号N_ID1（取值0～335）联合决定：PCI = 3 × N_ID1 + N_ID2，总共1008个取值**。LTE时代这个池子只有504个，NR翻了一倍，但站越来越密，池子反而更紧张了。 为什么“工号”会被做成物理层参数？因为终端要做的是纯粹的硬件级运算：PSS是三条Zadoff-Chu序列，对应N_ID2的三种取值；SSS是336条序列，锁定N_ID1。终端解出PCI后，这个数直接参与后续几乎所有参考信号的生成。这就带来三个经典的“撞号”约束，本文案例的真凶就藏在里面： | 冲突类型 | 物理层表现（依据TS 38.211） | 典型症状 | 定位手段 | | --- | --- | --- | --- | | 同频同PCI（混淆） | 邻区表中无法区分两个同名小区 | 切换命令指向错误目标，T304超时、RLF | CT测量、UE上报CGI仲裁 | | PCI mod 3相同 | N_ID2相同，PSS序列撞车，同步解调性能受损 | 弱场下同步慢、误码抬高 | 规划工具扫描、扫频仪 | | PCI mod 4相同 | PBCH解调参考信号频移位置相同，MIB解调受扰 | 接入慢、SIB解码失败率抬升 | MR数据回放、路测 | | PCI mod 30相同 | 未另行配置序列组时，上行DMRS/SRS序列组相同 | 上行干扰抬升、吞吐劣化 | 上行干扰专项统计 | 补充一句：mod 3和mod 30是从LTE时代一路传下来的老规矩（LTE里mod 3对应CRS频移），NR里对应关系变了，但“错开取值以降低参考信号互相干扰”的思路没变。这些约束的严格程度在不同厂家网管里的实现形态不一——标准允许多种实现，具体行为以各厂家官方文档为准。 还有一层容易被忽略：PCI不是逻辑层参数，改PCI = 小区“换工号”，对终端来说等于消失一个旧小区、出现一个新小区。所以改PCI从来不是改个参数那么简单，它是一场小型割接——这是本文第五节的主题。 ## 三、追凶四十八小时：从KPI下钻到CT测量 第一轮排查走的是标准动作，但值得完整讲一遍，因为每一步排除法都有讲究。 **第一步，下钻失败原因分布。** 把切换失败的信令原因拆开看：准备阶段失败（目标侧准入拒接）占比不高，大头是执行阶段失败——**切换命令（含MobilityControlInfo）下发后，终端在T304计时器超时前没能完成与目标小区的随机接入，占78%**。T304是TS 38.331里定义的切换执行计时器，它超时通常意味着一件事：终端按命令去同步目标小区，但目标“对不上号”或信号不行。 **第二步，查RLF和重建来源。** T304超时后终端会触发RLF并发起RRC重建。统计重建请求的目标小区，发现大量重建被“送回”了切换的源小区——终端兜了一圈又回到原地。这是很有特征的指纹：如果是目标小区信号差，重建会落在信号更好的第三者小区；兜回源小区，说明源小区信号其实很好，问题出在“切换目标指错了方向”。 **第三步，路测验证。** 沿滨江快速路跑了120公里，复现路径：终端在快速路上以80公里时速行驶，服务小区A（PCI=219）发起切换，目标指向C（PCI=219），终端收到切换命令后立刻失步，T304超时，重建回A，稍后A再次发起切换……如此往复。注意这里的细节：**A和C在邻区关系上是两个物理位置不同的站点，却报着同一个PCI**。 ```mermaid flowchart TD A["切换成功率跳水"] --> B["下钻失败原因分布"] B --> C{"T304超时占比高?"} C -->|否| D["查传输与准入"] C -->|是| E["统计RLF重建去向"] E --> F["路测复现加MR回放"] F --> G{"目标小区同频同PCI?"} G -->|是| H["PCI混淆嫌疑上升"] G -->|否| I["查邻区漏配与CIO"] H --> J["CT测量确认成对关系"] J --> K["锁定冲突PCI清单"] ``` **第四步，CT测量坐实。** CT（Cell Topology/小区关系测量）把“哪两个小区互相把对方当成邻区”全部拉出来对账，很快锁定两组冲突：A站与C站同频（3.5GHz同频段组网）且PCI同为219，直线距离1.8公里；另一组mod 3相同的冲突顺带被揪出来。到这里根因已经收口，剩下的问题是：规划明明有工具，为什么会撞号？ ## 四、根因：规划导入滞后，ANR好心办坏事 复盘会发现这不是单一错误，而是两个流程漏洞的叠加。 **漏洞一：规划导入滞后。** 新区47个站的PCI是规划工具统一分配的，规则本身没问题（同频邻区间互异、mod 3错开、预留边界缓冲池）。但开站时，最后一批17个小区的规划文件因为工参表版本对不上，没有及时导入网管，这几个小区用了安装队按临时表设置的默认PCI——其中就有一个219。规划工具算的是“理想世界”，现网跑的是“将错就错”，两套数据从此分叉。 **漏洞二：ANR自动邻区把错误关系合法化了。** ANR（Automatic Neighbour Relations，自动邻区关系）是3GPP TS 38.300定义的自组织网络功能：基站维护一张邻区关系表（NRT），发现漏配邻区时，可以让终端按需去读邻区的系统消息、上报全局小区标识（CGI），自动把邻区关系加上去。这功能平时是救星——漏配邻区导致的掉话它能自己长好。但在这个案子里，它“好心办了坏事”：A站发现快速路方向有强信号小区（其实是C站，报着PCI 219），ANR按PCI去邻区表里找219，找到了某个远端同PCI小区（或判定关系已存在），于是切换目标被错误关联。**终端被指挥去同步一个根本不在那个方向上的“219号”小区，自然失步。** 这就是PCI混淆（PCI confusion）的经典形态：在频率相同的前提下，源小区靠测量报告里的PCI来识别切换目标，一旦两个同频邻区同名，源小区的“点名系统”就失灵了。基站会向终端下发指向错误物理实体的切换命令，终端同步失败、T304超时、RLF、重建回源——循环往复，快速路上就是一片切换黑洞。 ## 五、处置：凌晨割接窗口的PCI重整 改PCI为什么必须走割接流程？因为“换工号”瞬间，所有以旧PCI同步上来的终端都会经历一次隐性的小区消失：正在该小区驻留的用户要重选、重连；周边所有以旧PCI为邻区的配置都可能失效；ANR还会在过渡期疯狂“学习”，进一步搅浑水。所以这场割接按正规军打法组织： **割接方案要点**：涉及重整的小区共77个（冲突直接相关的219两站+mod 3冲突组+边界缓冲池重排），按“外环→二环→核心区”三批推进（24/36/17），每批之间留30分钟观察窗；时间窗选在周二凌晨0:00–4:30，避开园区晚班通勤和晨峰；每批执行前全量备份网管配置与邻区表，回退动作预演过一遍，回退门限定为“切换成功率低于98.5%或重建比超过1%”。 **割接夜的执行顺序**如下： ```mermaid flowchart TD S1["凌晨0点封网确认"] --> S2["备份配置与邻区表"] S2 --> S3["第一批外环改PCI"] S3 --> S4["观察30分钟KPI"] S4 --> T{"门限内?"} T -->|否| U["一键回退旧PCI"] T -->|是| S5["第二批二环推进"] S5 --> S6["清理ANR误学邻区"] S6 --> S7["晨峰前全量验收"] ``` 三个实战细节值得单独说： **第一，先删错误关系，再改PCI。** 如果先改PCI，ANR会在新旧并存的窗口期把矛盾关系重新学一遍。正确顺序是：先把ANR误学出的89条错误邻区关系删除并加入黑名单，再动PCI。 **第二，改完要“重启”邻区关系，不能只改参数。** 新PCI生效后，周边小区的邻区表里还挂着旧PCI条目，要么同步刷新邻区表，要么干脆清空相关邻区关系让ANR重新学习一遍——本案选了后者，重学更干净，但要在白天低话务时段完成，否则重学期间切换会有一段混乱期。 **第三，验收看趋势不看单点。** 4:30收工时KPI已经回绿，但值班组又盯了整个晨峰：切换成功率99.21%，重建比0.34%，快速路复测两趟无复现——这才算闭环。单看凌晨一个点的数据，样本太小，会把“暂时平静”误判成“已经治愈”。 ## 六、把教训固化成工具链 割接成功只是止血，真正值钱的是后续的流程整改。这个案子沉淀下来四件东西： **其一，PCI冲突扫描进日常。** 把“同频同PCI、mod 3、mod 4、mod 30冲突”做成网优平台的每日批处理任务，扫描范围覆盖全量工参，新增小区当天进扫描池。混淆类的扫描逻辑不复杂：凡是“两个同频小区的PCI相同、且存在共同的第三邻区”的组合就报警，人工确认后再处理。 **其二，工参回填闭环。** 事故的种子是“规划文件没导入、安装队用了默认值”。整改后，开通流程加了硬卡点：工参回填与规划文件比对不一致的小区，不允许进入开站清单——让“理想世界”和“现网”永远只有一份真相。 **其三，ANR治理规则。** ANR不能裸奔。给自动邻区加了三条纪律：同频同PCI的邻区关系自动进待确认队列，不许直接生效；跨站距离超过门限自动学到的邻区关系标记可疑；对涉及核心快速路线的小区，邻区白名单优先于自动学习。目标是保住ANR“自愈漏配”的优点，掐掉它“合法化错误”的尾巴。 **其四，监控专项。** 性能平台新增三个专项指标：T304超时占切换失败的比例（正常应低于30%，飙高先怀疑目标识别问题）、RRC重建回源小区的比例、同频同名PCI对数。这三个指标组合起来，就是PCI混淆的“心电图”——下次不用等用户投诉，曲线自己会说话。 ## 七、经验教训与开通前检查清单 最后把这篇文章压缩成一张清单，供开站和网优的同事直接抄走： 1. **PCI是物理层资源，不是网管参数。** 1008个取值在密集组网下是稀缺资源，规划要像管频点一样管PCI，同频邻区绝不允许同名，mod 3尽量错开。 2. **规划世界与现网必须单一真相源。** 规划文件、网管工参、安装队手里的临时表，三份对不上一份，就是下一个219。 3. **ANR要配纪律再上岗。** 自动邻区解决漏配，但同PCI场景它会放大错误，黑名单和白名单是必备的缰绳。 4. **KPI下钻有固定套路。** 切换失败先拆“准备失败还是执行失败”，执行失败看T304超时占比，再看重bau……重建去向——兜回源小区，八成是“目标指错了”，不是“目标不行”。 5. **改PCI=割接，按割接规格组织。** 封网窗口、分批推进、观察门限、回退预案、晨峰验收，一个都不能省。 6. **把单次故障变成批量能力。** 每次复盘的产出物不应该只有报告，而应该是扫描任务、卡点规则和监控专项——让下一次故障在用户感知之前就被抓住。 回到开头的那个凌晨：一条快速路的切换黑洞，追到最后是一串1008取值里的重名号。移动通信网络里没有“小参数”，凡是物理层参与运算的配置，错了都会以掉话的形式找上门来。把每个参数当割接对待，把每次割接当战役对待——这就是运维这门手艺的全部体面。 ## 参考来源 > 注：本文发稿时联机核验通道受限，以下均为长期稳定的一手标准来源入口，文中3GPP相关表述请以最新版本标准文本为准；案例为脱敏复合复盘，数据已匿名化。 1. [3GPP TS 38.211（NR物理层：PSS/SSS与PCI构成）](https://www.3gpp.org/dynareport/38211.htm) — PCI=3×N_ID1+N_ID2、1008取值、PBCH DMRS频移等物理层事实的权威出处 2. [3GPP TS 38.300（NG-RAN总体描述）](https://www.3gpp.org/dynareport/38300.htm) — ANR自动邻区关系、邻区关系表（NRT）与黑名单/白名单机制的定义 3. [3GPP TS 38.331（NR RRC规范）](https://www.3gpp.org/dynareport/38331.htm) — T304/T310计时器、测量事件与RRC重建流程 4. [ShareTechnote 5G PCI专题](https://www.sharetechnote.com/html/5G/5G_PCI.html) — 工程视角的PCI规划与冲突类型速查教程 --- > 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 > 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。