<!-- title: 两个小区撞了号：掉话风暴排查记 -->

**概述**：本文回答一个无线运维的经典问题——为什么切换成功率会一夜之间从99.3%跌到95.8%，而功率、邻区、传输全都查不出毛病？答案藏在1008个PCI（物理小区标识）里：一次新站开通，两个相距一公里多的小区用上了同一个号。本文以一次典型排查为主线，讲清PCI的构造原理、三种“撞号”方式的机理差异、从KPI曲线到扫频数据的完整定位链条，以及如何用自动稽核把这类故障扼杀在开站之前。

## 目录

- 一、深夜的割接单，清晨的掉话潮
- 二、PCI：小区的身份证，也是它的指纹
- 三、三种撞号法：冲突、混淆、错位
- 四、48小时排查实录
- 五、改一个号，救一张网
- 六、把撞号扼杀在开站之前
- 七、写给同行的四条经验

## 一、深夜的割接单，清晨的掉话潮

先讲一个我审过无数遍、自己也曾亲手踩过的场景。为避免对号入座，地名和局方做了模糊处理，但每个数字都来自真实工单的量级。

某南方城市，核心商圈半径三公里内密布六十多个宏站、一百八十多个3.5GHz同频5G小区。周三夜里23:40，一张再普通不过的新站割接单执行完毕：三扇区宏站开通，功率核对、邻区核对、传输核对，逐项打勾，网管上看到三个小区全部正常起呼，割接组凌晨一点收工。

第二天上午九点半，优化台的KPI曲线开始不对劲：全市切换成功率从99.3%滑到95.8%，RRC重建比例从0.2%抬到0.9%，翻了三倍多；掉线率从0.15%涨到0.42%。客服侧同步冒出一批投诉，高度集中在两个地点——新站覆盖的商圈路口，和一公里外另一个写字楼的电梯口，投诉内容出奇一致：“信号满格，刷两下就断。”

这种“满格但断”的投诉组合，老网优看到会有生理性警觉：功率和覆盖大概率没问题，问题多半出在“识别”上。终端明明测得到信号，却在切换、重选或重建的某个环节认错了小区。而认错小区最常见的根源，就是两个小区用了同一个物理小区标识——PCI。

## 二、PCI：小区的身份证，也是它的指纹

很多人把PCI理解成小区的“名字”，这个类比只对了一半。名字重复顶多是重名，PCI重复是灾难性的，因为PCI不只是一个编号，它直接决定了小区下行同步信号和参考信号的序列——换句话说，它既是身份证，也是指纹。

按3GPP TS 38.211第7.4.2节的定义（HiCellTek的5G NR PCI规划指南对此有完整梳理），NR的PCI由两部分拼成：PCI = 3×N_ID1 + N_ID2，其中N_ID1取值0到335，N_ID2取值0到2，全部组合一共1008个。LTE时代更紧张，TS 36.211里N_ID1只有0到167，全网只有504个号可用。

1008听起来不少，但摊到密集城区根本不经用。一个一线城市的5G小区数以万计，叠加多层组网——同一片天空下压着700MHz、2.6GHz、3.5GHz多个频段，每个频段都是同频组网——PCI的复用间隔被压缩到极限。规划上只能保证“互为邻区的小区不同号、共用邻区的小区不同号”，远了就管不过来了。

更要命的是，PCI的各位还通过取余运算“遥控”着物理层的关键资源。综合HiCellTek、My Telco Learning等技术资料的说法：

- **PCI mod 3** 决定主同步信号PSS的序列。两个相邻小区如果PCI除以3的余数相同，它们的PSS就是同一序列，在小区边缘重叠区互相打架；
- **PCI mod 4** 决定PBCH解调参考信号在SSB里的摆放位置，余数相同则参考信号撞在同一批子载波上；
- **PCI mod 30** 与解调参考信号、SRS的序列组相关，5Gto6G的PCI规划工具页面直言：共享PCI mod 30的小区会产生相关的DMRS序列，在低信噪比下直接拖垮解调性能。

所以PCI规划从来不是“发个号”这么简单，而是一道立体约束题：既要全网范围内邻区不重号，又要在mod 3、mod 4、mod 30三个维度上错开。漏了任何一维，都是给未来的自己埋雷。

## 三、三种撞号法：冲突、混淆、错位

工程师口中的“PCI问题”其实是三种不同的病，症状、危害和排查抓手都不一样。这也是很多新人排查跑偏的原因——把混淆当成了冲突，在错误的方向上翻工参。

| 类型 | 成因 | 典型现象 | KPI表现 | 确认手段 |
|---|---|---|---|---|
| 冲突（Collision） | 同频的两个相邻或交叠小区配了同一个PCI | 终端无法区分两个小区，随机接入、重选异常 | 接入失败、RRC重建激增 | 扫频：同一PCI在两处出现强信号 |
| 混淆（Confusion） | 本小区的两个邻区（彼此不相邻）用了同一个PCI | 切换命令只带目标PCI，终端找到两个候选，切错或切败 | 切换成功率骤跌，且集中在特定切换带 | 邻区表交叉比对；信令里目标PCI与实际小区对不上 |
| 错位（模三/模四/模三十冲突） | PCI本身不重复，但余数相同 | 小区能区分，但边缘信噪比劣化、同步变慢、吞吐下降 | 边缘速率下滑、时延抖动，用户感知“卡” | 路测SINR热图在重叠区出现凹坑 |

三种病里，冲突最凶、混淆最阴、错位最钝。冲突是“两个人共用一张身份证”，终端在重叠区直接精神分裂；混淆是“你的两个朋友重名”，你喊一声“喂”，过来的是错的那个——切换命令里只写着目标PCI，终端在自己测到的列表里找到俩，选错的概率五五开，而每一次选错都计一次切换失败；错位则是“身份证号不重复，但指纹一模一样”，日常能忍，边缘位置全是内伤。

## 四、48小时排查实录

回到开头的案例。优化中心上午十点拉单排查，整个处置过程浓缩起来是一张时间线表：

| 时间 | 动作 | 关键发现 |
|---|---|---|
| 第一天 23:40 | 新站割接开通，三扇区起呼正常 | 网管逐项核对通过，无人起疑 |
| 第二天 09:30 | KPI曲线异动告警，切换成功率跌破96% | 异常小区簇与新站地理高度重合 |
| 第二天 10:30 | 调取异常小区邻区表与本站参数 | 本站内部无同频重号，初查“无问题” |
| 第二天 13:00 | 信令跟踪：失败切换的目标PCI 87 | 目标PCI在测量报告与实际落地小区对不上 |
| 第二天 15:00 | 扫频车路测，采集全频段PCI与RSRP | PCI 87在相距1.2公里的两个位置均出现，RSRP达-78dBm量级 |
| 第二天 18:00 | 工参表全量比对，锁定老站同号小区 | 新站2扇区与1.2公里外高楼站同号；1扇区与对面路口站模三冲突 |
| 第二天 23:00 | 新小区改配空闲PCI并完成模三/四/三十核对 | 改动窗口避开晚高峰 |
| 第三天 10:00 | 复盘KPI：切换成功率回升至99.1% | 投诉归零，故障关闭，进入防再发整改 |

排查过程中有一段值得展开，因为它是最容易走弯路的地方。上午调本站参数和邻区表时，一切干净——本站三个扇区之间、本站与直接邻区之间都没有重号。如果排查到此为止，结论就会是“无线侧无问题”，然后把锅甩给传输或核心网。转折出在信令上：跟踪失败样本的测量报告，终端上报的是PCI 87，但按该PCI下发切换命令后，终端要么在原小区徘徊，要么落到一个完全不相干的小区上。PCI 87在本站的邻区列表里明明是合法目标——问题一定出在“87不止一个人在用”。

扫频车是定案的铁证。网管数据和信令只能提出嫌疑，只有扫频仪能拿到物理事实：当同一时刻、同一频点上，PCI 87在相距1.2公里的两个方向都测到-80dBm上下的强信号时，冲突板上钉钉。后续工参全量比对把案情补全了：新站的开通脚本套用了另一区域的参数模板，模板里残留着原区域的PCI规划，新站2扇区就这样顶着一个1.2公里外已有小区的号上了线；同时1扇区的新PCI还与正对面路口站的一个小区构成模三冲突，在路口重叠区把PSS搅成一团。一个模板疏忽，两个病灶。

整个故障机理可以画成一张图：

```mermaid
flowchart TD
    A["割接脚本套用外区模板"] --> B["新小区顶用旧PCI 87"]
    B --> C["1.2公里外老小区也是PCI 87"]
    A --> D["1扇区新PCI与路口站模三冲突"]
    C --> E["同频同号：终端无法区分两小区"]
    E --> F["切换命令指向模糊"]
    F --> G["终端切入错误小区"]
    G --> H["切换失败与RRC重建激增"]
    D --> I["路口重叠区PSS互相打架"]
    I --> J["边缘信噪比劣化 用户感知卡顿"]
    H --> K["投诉与KPI曲线同步异动"]
    J --> K
```

## 五、改一个号，救一张网

修复本身简单得近乎羞辱：给新站2扇区换一个空闲PCI，换之前把候选号丢进冲突矩阵，与周边两层站点的所有小区核对mod 3、mod 4、mod 30三个余数，全绿才放行。当晚23点低峰期改划，三分钟后新PCI生效。第二天上午切换成功率回到99.1%，重建比例回落到0.2%，投诉归零。

一个号码，四十八小时的折腾，两天的KPI，一批投诉，一次复盘会。这正是PCI类故障的典型画风——修复成本几乎为零，发现成本极高。

修复之后的验证环节也别省。老规矩是三看：一看切换成功率是否回到基线并稳定二十四小时；二看重建比例是否回落；三看投诉热力图上两个热点是否冷却。还有一条容易被忽略——改PCI会让老用户短暂失步，高峰期改会制造一批新的“满格断流”，所以改划永远放在深夜低峰，这也是把它排在23点的原因。

## 六、把撞号扼杀在开站之前

复盘会的结论只有一句话：这次故障不是“查出来”的，是“漏过去”的。开站核对单上功率、邻区、传输逐项打勾，唯独没有“PCI全网复用核查”这一项——因为大家默认PCI是规划部分配好的。而恰恰是模板复用这个提升开站效率的好习惯，把规划环节整个短路了。

整改落了四件事：

**第一，开站稽核必须含全网冲突矩阵。** 新站参数下站前，用全网工参跑一遍冲突检测：同频同PCI、PCI混淆、模三/模四/模三十三个维度全查。这类工具市面上已经很多，RF Universe的PCI冲突工具就支持按距离筛查同号对、过滤同站对、套用黑名单并直接导出改划建议；5G/6G Academy和5Gto6G也都有免费的在线mod 3/mod 30核查器。工具不难找，难的是把“跑工具”变成流程里的硬卡点。

**第二，参数模板加“地区指纹”。** 模板里凡与地理强相关的参数——PCI、根序列、跟踪区——不允许直接继承，必须留空强制人工填入并过稽核。模板复用省下的十分钟，抵不上一次全网掉话的零头。

**第三，用好网内的自动闭环。** 3GPP在ANR（自动邻区关系）和SON框架里定义了PCI冲突检测与纠正类功能，网络可以在运行中发现可疑的PCI使用并触发重配。需要说明的是，标准允许多种实现，各厂家网管的自动稽核能力、检测范围与默认策略并不相同，具体行为以各厂家官方文档为准。实战建议是：自动闭环当作安全网，不当作免检牌——它反应再快也快不过一次已经发生的切换失败。

**第四，扫频能力常备。** 扫频车不是验收专用品。凡是KPI出现“地理聚集+识别类症状”的组合，第一时间上扫频，别在网管数据里翻半天翻不出结论——同号小区只要不相邻，网管的邻区逻辑里它就是隐形的。

整改后的开站流程长这样：

```mermaid
flowchart TD
    A["新站参数制作完成"] --> B["全网冲突矩阵稽核"]
    B --> C{"三项检测全绿？"}
    C -->|否| D["退回重新分配PCI"]
    D --> B
    C -->|是| E["夜间低峰割接开通"]
    E --> F["起呼与切换抽检"]
    F --> G{"KPI正常？"}
    G -->|否| H["立即回退并扫频定位"]
    G -->|是| I["割接关闭 归档PCI台账"]
```

## 七、写给同行的四条经验

最后把这次复盘压成四条，送给正在值班的同行：

**一、PCI是规划项，不是配置项。** 任何把PCI当普通参数填的动作，都要先过全网冲突矩阵。1008个号在密集城区是稀缺资源，稀缺资源的管理只有一条铁律：分配必须有台账，使用必须可追溯。

**二、模板是好东西，也是短路器。** 它绕过的不是重复劳动，而是核查环节。地理相关参数永远留白，宁可手填一万次，不可错带一次。

**三、“满格但断”先查识别，再查覆盖。** 功率正常、覆盖良好、故障地理聚集、投诉集中在重叠区——这四个特征凑齐，优先怀疑PCI类问题，先拉邻区混淆比对，再上扫频。方向对了，四十八小时能缩到四小时。

**四、错位型冲突没有告警，只有体感。** 模三冲突不会让任何一个计数器越线，它只是默默把边缘信噪比往下摁，最后以“这个路口怎么老这么卡”的投诉形式抵达你面前。所以模三/模四/模三十的稽核不能等出事，要做成开站前的例行体检。

HiCellTek在其PCI规划指南里把这类问题称为“最便宜的严重故障”——修复只要一个数字，代价却可能是一张口碑。每次在KPI曲线上看到那种说不清道不明的凹陷时，不妨先问一句：最近，有没有人开过站？

## 参考来源

1. [5G NR PCI Planning Guide — Mod 3, Mod 30, Confusion | HiCellTek](https://hicelltek.com/en/pci-planning-guide/) — 依据3GPP TS 38.211 §7.4.2系统讲解PCI构造、1008个取值、mod 3/mod 30冲突规则与混淆概念，本文PCI原理部分的主要锚点
2. [PCI Mod 3 Collision Detection in LTE: Audit, Impact and Re-Planning | HiCellTek](https://hicelltek.com/en/blog/pci-mod-3-collision-lte-detection/) — 模三冲突（PSS序列冲突）对小区搜索时延与吞吐的影响及邻区表审计方法
3. [LTE/NR PCI Conflict, PCI Confusion, PCI Collision, Mod of PCIs — 3,4,6,30 | My Telco Learning](https://mytelcolearning.blogspot.com/2022/04/pci-conflict-pci-confusionpci-collision.html) — 冲突、混淆、碰撞三类问题的分类学，以及mod 3/4/6/30各余数对应的物理层资源
4. [5G NR PCI Planner | 5Gto6G](https://5gto6g.com/tools/pci-planner) — 规划工具对mod 3与mod 30冲突的检测逻辑，印证“每次邻区关系都要双查”的工程实践
5. [PCI Planning Tool — 5G NR Mod-3 Checker | 5G/6G Academy](https://www.5g6gacademy.com/tools/pci-planning-tool) — 基于TS 38.211的PSS mod-3与DMRS mod-30在线核查工具，本文稽核工具链部分的来源

---
> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
