# NR前导码分配博弈：64码背后的成本密码 ## 一、64个前导码：运营商每天数亿次接入的"门禁卡" 5G NR系统中，每个小区仅有**64个PRACH前导码**可供随机接入使用（TS 38.211 Section 6.3.3.1）。这64个序列由一个或多个Zadoff-Chu（ZC）根序列通过循环移位（Ncs）生成。看似充裕的数字，在实际网络运营中却成为制约接入容量的核心瓶颈。 根据TS 38.321 Section 5.1.2的规定，这64个前导码被分为**三组**： | 前导码分组 | 用途 | 分配方式 | 典型占比 | |-----------|------|---------|---------| | **CBRA Group A** | 小包Msg3的竞争接入 | SIB1广播 | 40-60% | | **CBRA Group B** | 大包Msg3的竞争接入 | SIB1广播 | 0-20% | | **CFRA** | 无竞争专用接入 | 专用RRC信令 | 20-40% | 运营商在规划网络时，必须在这三组之间做出权衡：分给CFRA越多，切换成功率越高，但留给普通用户的CBRA码就越少，接入碰撞概率随之攀升。这就是本文要深入拆解的**前导码分配博弈**——一个看似简单的参数配置，实则直接影响网络KPI和运营成本。 ## 二、前导码分组的协议机制详解 ### 2.1 分组规则：TS 38.321 Section 5.1.2的精确逻辑 前导码分组的完整逻辑定义在TS 38.321 V19.x Section 5.1.2中。其核心参数来自SIB1中的`RACH-ConfigCommon` IE： ``` RACH-ConfigCommon ::= SEQUENCE { totalNumberOfRA-Preambles INTEGER (1..64), ssb-perRACH-OccasionAndCB-PreamblesPerSSB CHOICE { ... }, groupBConfigured CHOICE { ... } OPTIONAL, ra-ContentionResolutionTimer ENUMERATED { ... }, ... } ``` **分组计算流程**如下： 1. **总前导码数**：由`totalNumberOfRA-Preambles`决定（默认64），这些码用于随机接入 2. **CFRA码池**：从总数中减去CBRA码，剩余分配给CFRA 3. **CBRA再分组**： - 若`groupBConfigured`存在，CBRA码被分为Group A和Group B - Group B的起始索引由`ra-PreambleStartIndex`指示 - Group A占据CBRA码池的前半部分  > *图表 1* ### 2.2 Group A vs Group B的选择逻辑 UE选择Group A还是Group B，取决于三个条件的**同时满足**（TS 38.321 Section 5.1.2）： | 条件 | Group A（默认） | Group B（需全部满足） | |------|----------------|---------------------| | Msg3大小 | < `messageSizeGroupA`（默认56 bits） | ≥ `messageSizeGroupA` | | 路径损耗 | 无限制 | `P_CMAX - pathloss > messagePowerOffsetGroupB` | | 配置要求 | 默认存在 | 必须配置`groupBConfigured` | **设计意图**：Group B的存在是为了让UE在Msg3阶段就能发送更大的 payloads（如携带NAS消息的RRCSetupRequest或RRCReestablishmentRequest），避免额外调度开销。但Group B需要UE有足够的发射功率来支持更大的Msg3传输，因此增加了路径损耗校验。 ### 2.3 SSB-to-RO映射：前导码的二维分配 在5G NR中，前导码分配不仅是简单的码字分配，还涉及SSB（同步信号块）与PRACH Occasion（RO）的映射关系。参数`ssb-perRACH-OccasionAndCB-PreamblesPerSSB`定义了： - **N** = 每个RO映射的SSB数量（1/8, 1/4, 1/2, 1, 2, 4, 8, 16） - **R** = 每个SSB对应的CBRA前导码数量  > *图表 2* 这个映射关系直接影响**波束管理**效率——gNB通过UE选择的preamble index就能确定UE的最佳下行波束，无需额外信令。这是NR相比LTE的重要增强。 ## 三、64码瓶颈的数学本质 ### 3.1 接入容量公式 每个小区的随机接入容量可表示为： ``` RACH容量 = CB前导码数 × 每秒RO数 × (1 - 碰撞概率) ``` 其中： - **CB前导码数** = 64 - CFRA分配数 - **每秒RO数** = 由`prach-ConfigurationIndex`查表得出（TS 38.211 Table 6.3.3.2-x） - **碰撞概率** = 1 - e^(-G/N)，G=到达率，N=可用前导码数 以典型配置为例（FR1, Format 0, 10ms周期）： | 参数 | 场景A：城区 | 场景B：郊区 | 场景C：体育场馆 | |------|-----------|-----------|--------------| | PRACH格式 | Format 0 | Format 0 | Format A1 | | 周期 | 10ms | 20ms | 10ms | | 频域RO数 | 1 | 1 | 8 | | CB前导码数 | 52 | 56 | 48 | | 每秒RO数 | 100 | 50 | 800 | | **理论容量** | **5200次/秒** | **2800次/秒** | **38400次/秒** | ### 3.2 碰撞概率与成本链 当接入需求超过容量时，碰撞概率急剧上升。碰撞意味着： 1. **Msg1碰撞**：两个UE选择同一前导码 → gNB只发一个RAR → 只有一个UE收到Msg2 2. **Msg3竞争解决失败**：两个UE都发了Msg3 → gNB用C-RNTI或UE Contention Resolution Identity解决 3. **重传循环**：失败UE启动power ramping → PRACH功率攀升 → 干扰加剧  > *图表 3* ### 3.3 运营商成本视角的量化分析 以一个拥有**5000个基站**的中型运营商为例： | 成本维度 | 保守配置 | 激进配置 | 差异 | |---------|---------|---------|------| | PRACH开销占比 | 0.5%上行资源 | 2.0%上行资源 | +1.5% | | 等效频谱损失 | ~1.5MHz (100MHz带宽) | ~6MHz | 4.5MHz | | 频谱成本/年 | - | - | ~¥270万/年 | | 碰撞重传能耗 | 基准 | -30%（更少碰撞） | 节能 | | 接入时延P99 | 80ms | 25ms | 改善69% | | 用户投诉率 | 基准 | -50% | 显著改善 | > 注：频谱成本按100MHz带宽×3.5GHz频段拍卖均价估算，1%上行开销≈0.5MHz有效频谱损失。 ## 四、前导码分配的三种运营商策略 ### 4.1 策略一："保守型"——最大化PUSCH容量 ``` totalNumberOfRA-Preambles = 64 CFRA = 8 (仅用于切换) CBRA Group A = 52 CBRA Group B = 4 PRACH周期 = 20ms（低密度） ``` **适用场景**：广覆盖低密度区域（农村、公路） **成本特征**： - PRACH开销最小（<0.3%），频谱效率最高 - 高峰期碰撞风险高，mMTC场景不适用 - 年度频谱成本节省约¥50万/千站 ### 4.2 策略二："均衡型"——CBRA/CFRA平衡 ``` totalNumberOfRA-Preambles = 64 CFRA = 16 (切换+定位+SCell) CBRA Group A = 40 CBRA Group B = 8 PRACH周期 = 10ms 频域RO = 2 ``` **适用场景**：城区常规覆盖 **成本特征**： - 切换成功率>99.5%（CFRA保障） - mMTC场景需要ACB（Access Class Barring）辅助 - 运营商最常用的默认配置 ### 4.3 策略三："激进型"——面向mMTC优化 ``` totalNumberOfRA-Preambles = 64 CFRA = 4 (仅核心切换) CBRA Group A = 56 CBRA Group B = 4 PRACH周期 = 10ms 频域RO = 4-8 SSB-per-RO = 1/8 (8个RO映射1个SSB) ``` **适用场景**：智慧城市、工业物联网、体育场馆 **成本特征**： - PRACH开销高（2-3%），但每秒可支持3万+接入尝试 - 需要配合ACB/EAB进行拥塞控制 - 每站额外频谱成本约¥5000/年，但支撑的IoT连接收入远超成本 ### 4.4 三种策略对比 | 维度 | 保守型 | 均衡型 | 激进型 | |------|-------|-------|-------| | PRACH开销 | <0.3% | ~0.8% | 2-3% | | 理论接入容量 | ~2800/s | ~10000/s | ~38000/s | | 切换成功率 | 98.5% | 99.5% | 97.0% | | mMTC支持 | 差 | 中 | 优 | | 年均频谱成本/千站 | ¥0 | ¥30万 | ¥120万 | | 适用连接密度 | <100/km² | 100-1000/km² | >1000/km² | ## 五、SSB-to-RO映射的波束成本经济学 ### 5.1 波束扫描开销 在FR2（毫米波）频段，gNB通过波束扫描发送多个SSB（最多64个，FR1最多8个）。每个SSB需要映射到独立的RO和前导码子集，否则gNB无法判断UE选择了哪个下行波束。 当SSB数量N=8、每SSB的CB前导码R=4时： - CB前导码总数 = 8 × 4 = 32 - CFRA可用 = 64 - 32 = 32 - 这看起来合理，但当SSB数增至FR2的64个时：64 × R=1 仅需64个前导码，全部用完 这意味着**毫米波频段的前导码资源更加紧张**，运营商需要更多的频域RO来扩展容量。 ### 5.2 频域RO扩展的成本计算 频域RO数量由参数`msg1-FDM`控制（取值1, 2, 4, 8），每个频域RO占用6个PRB的上行资源： | msg1-FDM | 频域RO数 | PRACH占用PRB | 占100MHz比例 | 等效成本/年/站 | |----------|---------|-------------|-------------|--------------| | 1 | 1 | 6 PRB | 0.18% | ¥500 | | 2 | 2 | 12 PRB | 0.36% | ¥1,000 | | 4 | 4 | 24 PRB | 0.72% | ¥2,000 | | 8 | 8 | 48 PRB | 1.44% | ¥4,000 | 对于大规模IoT部署（如10万站的智慧城市），从msg1-FDM=1升级到msg1-FDM=8，年度额外频谱成本约为**¥4亿**。但支撑的连接数从10万提升到80万，每连接成本反而下降60%。 ## 六、实战抓包识别与故障排查 ### 6.1 抓包识别PRACH流程 在gNB侧的L1/L2日志中，PRACH流程的关键标识： | 消息 | 关键字段 | 抓包位置 | |------|---------|---------| | Msg1 (PRACH Preamble) | preamble index, SSB index, RO index | gNB L1 PHY log | | Msg2 (RAR) | TC-RNTI, Timing Advance, UL Grant | gNB MAC log | | Msg3 (RRC Request) | UE Identity, Establishment Cause | gNB RRC log | | Msg4 (Contention Resolution) | C-RNTI, MAC CE | gNB MAC log | **常用排查命令**（以O-RAN架构为例）： ```bash # 查看PRACH配置 o-du-cli get-prach-config --cell-id=0 # 实时监控PRACH检测统计 o-du-cli monitor-prach --interval=1s --stats=collision,detection-rate # 导出RACH失败统计 o-du-cli export-rach-stats --start=2026-05-18T00:00:00Z --format=csv ``` ### 6.2 常见故障模式 | 故障现象 | 根因分析 | 排查思路 | |---------|---------|---------| | PRACH检测率<90% | Ncs规划不合理，邻区ZC根序列冲突 | 检查根序列规划表，确认邻区Ncs隔离度 | | 大量Msg1无Msg2响应 | gNB PRACH处理能力不足（基带资源不够） | 检查O-DU基带利用率，考虑增加处理核 | | Msg3竞争解决频繁失败 | Group B配置不合理，弱覆盖UE选了Group B | 检查`messagePowerOffsetGroupB`设置 | | 切换失败率高 | CFRA前导码不足，UE被迫用CBRA切换 | 增大CFRA前导码分配比例 | | IoT设备批量接入拥塞 | CBRA前导码池太小，碰撞风暴 | 配置ACB/EAB + 增大频域RO | ## 七、R17/R18增强：从64码到更多可能 ### 7.1 2-Step RACH（TS 38.321 Section 5.1A） Rel-16引入的2-Step RACH将Msg1+Msg3合并为MsgA，Msg2+Msg4合并为MsgB。这改变了前导码分配的博弈格局： - MsgA的前导码池独立配置，不再与4-Step RACH共享 - 运营商可以灵活配置两套RACH策略并行运行 - 对于小包IoT场景，2-Step RACH将接入时延从~20ms降至~5ms ### 7.2 PRACH增强（Rel-18 NR-RedCap） Rel-18为RedCap（Reduced Capability）设备引入了专用的PRACH资源配置： - RedCap UE可使用独立的RO和前导码池 - 避免RedCap设备与eMBB设备竞争前导码 - 运营商可以为低价值IoT设备配置更小的前导码集，将更多资源留给高价值用户 ### 7.3 AI/ML辅助前导码分配（Rel-19研究） 3GPP TR 37.868研究了利用AI/ML进行RACH优化的可行性： - 基于历史流量模式预测接入峰值 - 动态调整PRACH配置参数 - 据论文报告可降低碰撞率30-50% ## 八、根序列规划：隐形的邻区成本 ### 8.1 Ncs循环移位的规划约束 每个小区的64个前导码由ZC根序列通过循环移位Ncs生成。Ncs的选择取决于小区半径（TS 38.211 Section 6.3.3.1）： | 小区半径 | 推荐Ncs (Format 0) | 每根序列产生前导码数 | 所需根序列数 | |---------|-------------------|--------------------|-----------| | <3km | 34 | 2 | 32 | | 3-7km | 58 | 2 | 32 | | 7-15km | 88 | 1 | 64 | | 15-30km | 119 | 1 | 64 | | 30-100km | 202 | 1 | 64 | **关键约束**：邻区必须使用不同的根序列，否则会产生严重的跨区前导码碰撞。在密集城区，可用根序列数量（总共838个，u∈{1,...,838}）可能不足以支撑所有邻区的需求，迫使运营商选择更大的Ncs值，导致每根序列只能产生1个前导码——需要64个不同的根序列来填满64个前导码。 ### 8.2 根序列规划的运维成本 对于大型运营商（10万+基站），根序列规划是一项持续性的运维工作： - 每次新增基站都需要重新审核邻区的根序列分配 - 室内覆盖小基站的密集部署进一步增加了规划复杂度 - 传统人工规划方式需要2-3人日/百站，自动化工具可将效率提升5-10倍  > *图表 4* ## 九、运营商决策框架：从技术到商业 ### 9.1 投资回报率（ROI）模型 前导码分配策略的ROI可从以下维度评估： **收益侧**： - 更高的接入成功率 → 更好的用户体验 → 更低的流失率 - mMTC支撑能力 → 更多IoT连接收入（ARPU ¥5-20/连接/月） - 更低的接入时延 → URLLC场景溢价 **成本侧**： - PRACH开销导致的频谱效率损失（可量化为每MHz年度成本） - 根序列规划运维人力成本 - 2-Step RACH的gNB软件升级成本 ### 9.2 典型场景ROI估算 | 场景 | 年投入 | 年收益 | ROI | |------|-------|-------|-----| | 城区mMTC优化（增加RO密度） | ¥120万/千站 | IoT连接增收¥300万 | 150% | | 体育场馆临时扩容 | ¥5万/场 | 品牌价值+赞助溢价¥50万 | 900% | | 毫米波SSB-RO优化 | ¥200万/千站 | 企业专线增收¥500万 | 150% | | 根序列自动规划工具 | ¥100万（一次性） | 节省人力¥80万/年 | 80%/年 | ## 常见问题 **Q: CBRA和CFRA的核心区别是什么？什么时候用CFRA？** A: CBRA（Contention-Based RA）是UE随机选择前导码，可能碰撞；CFRA（Contention-Free RA）是gNB通过专用RRC信令（如`RACH-ConfigDedicated`）分配特定前导码给UE，保证无碰撞。CFRA主要用于三个场景：（1）切换时目标gNB通过HO命令分配专用前导码；（2）下行数据到达但UE失步时；（3）SCell添加时的TA获取。运营商通常为切换预留16-20个CFRA前导码。 **Q: 为什么有些运营商关闭Group B？** A: Group B的设计初衷是让Msg3携带更大的payload，减少额外的调度开销。但在实际网络中，大部分初始接入的Msg3都很小（RRCSetupRequest仅约56 bits），Group B的实际使用率很低。关闭Group B可以简化前导码管理，将更多码字留给Group A。只有在大包初始接入频繁的场景（如VoNR的RRC Resume带大缓存状态报告），开启Group B才有意义。 **Q: PRACH前导码碰撞如何检测？** A: gNB L1层通过相关性检测识别前导码。当多个UE使用同一前导码时，gNB可能检测到"多径合并"的效果——相关性峰值异常偏高或出现多个峰值。但gNB通常无法在Msg1阶段直接判断是否碰撞，碰撞的最终确认发生在Msg3竞争解决阶段。运营商可以通过统计"Msg1检测数/Msg4完成数"的比值来间接评估碰撞率，正常情况下该比值应接近1。 **Q: mMTC场景下如何避免前导码风暴？** A: 3GPP定义了多层防线：（1）ACB（Access Class Barring）——UE在发起RACH前先检查接入概率因子；（2）EAB（Extended Access Barring）——针对低优先级IoT设备的扩展接入限制；（3）Backoff Indicator——gNB在RAR中下发回退时间；（4）动态PRACH配置——根据负载自动增加RO密度。运营商应组合使用这些机制，仅靠增加前导码数量无法根本解决问题。 **Q: 根序列规划不好会导致什么问题？** A: 最严重的问题是**跨区前导码碰撞**——邻区UE使用相同的前导码和RO，gNB无法区分。症状表现为：（1）Msg3竞争解决失败率异常升高；（2）切换成功率下降（因为切换场景依赖专用前导码的准确识别）；（3）PRACH检测成功率在小区边缘急剧下降。排查方法是比较问题小区与邻区的根序列配置，确保同频邻区使用不同的根序列索引。 ## 参考来源 1. [3GPP TS 38.321 V19.x — NR MAC Protocol Specification](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3194) — Section 5.1 Random Access Procedure, Section 5.1.2 Resource Selection 2. [3GPP TS 38.331 V19.x — NR RRC Protocol Specification](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3196) — RACH-ConfigCommon, RACH-ConfigDedicated IE定义 3. [ShareTechnote — 5G NR RACH](https://www.sharetechnote.com/html/5G/5G_RACH.html) — PRACH配置与随机接入流程图解 4. [C114通信网 — 5G NR随机接入信号的规划研究](https://www.c114.com.cn/topic/5601/a1101425.html) — PRACH前导格式、Ncs规划和根序列规划实践 5. [IEEE — Preamble Allocation and Access Delay Reduction for mMTC](https://ieeexplore.ieee.org/document/11029069) — 前导码碰撞概率分析与容量优化算法 --- > 本文由「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 等场景全覆盖。