# NR调度请求SR定时器链式博弈与三径失败回退深度解析
## 一、SR机制定位：上行调度的"敲门砖"
在5G NR系统中，UE（用户设备）上行数据传输完全由gNB调度控制。当UE的RLC/PDCP层有新数据到达、缓存中有数据待发、却没有任何有效的PUSCH上行授权（UL Grant）时，UE必须通过**Scheduling Request（SR）**机制向gNB发出"我需要上行资源"的信号。这本质上是一个**MAC层到物理层的跨层请求机制**，定义于**TS 38.321 Section 5.4.4**。
SR的设计哲学可以用一句话概括：**用最小物理层开销换取上行调度机会**。相比于直接发起随机接入（PRACH preamble），SR只需在一个PUCCH资源上发送一个类似"1比特"的请求信号（PUCCH Format 0的序列循环移位或PUCCH Format 1的调制符号），开销远低于4步随机接入的Msg1~Msg4。
但这个"最小开销"的背后，隐藏着一条精心设计的**定时器链**——`sr-ProhibitTimer`控制发送频率、`SR_COUNTER`计数器追踪尝试次数、`sr-TransMax`设定失败门限。三者的协同博弈，直接决定了上行调度的**时延、可靠性和信令开销**之间的平衡。
## 二、SR三层配置架构（TS 38.331 IE解析）
SR的配置分布在RRC层的三个核心IE中，形成**配置层→资源层→映射层**的三级架构：
```mermaid
graph TB
subgraph "RRC配置三层架构"
A["SchedulingRequestConfig
（SR配置层）
TS 38.331 Section 6.3.2"] --> B["SchedulingRequestResourceConfig
（SR资源层）
TS 38.331 Section 6.3.2"]
B --> C["PUCCH-Config → PUCCH-ResourceSet
（PUCCH物理资源层）
TS 38.331 Section 6.3.2"]
A --> D["LogicalChannelConfig
（逻辑信道映射层）
sr-ConfigIndex"]
end
subgraph "关键参数"
A1["sr-TransMax: 最大SR发送次数
{n1,n2,n4,n8,n16,n32,n64}"]
B1["periodicityAndOffset: SR时机的周期和偏移
sr-ProhibitTimer: SR禁止定时器
resource: 关联的PUCCH资源ID"]
C1["PUCCH Format 0: 1-2符号
PUCCH Format 1: 4-14符号"]
D1["logicalChannelSR-DelayTimer
sr-ConfigIndex: 逻辑信道→SR配置映射"]
end
A --- A1
B --- B1
C --- C1
D --- D1
```
### 2.1 SchedulingRequestConfig IE
这是SR的**顶层配置容器**，每个UE最多可配置**8个SR配置**（schedulingRequestToAddModList，SIZE(1..8)），每个SR配置包含：
| 参数 | 取值范围 | 含义 | 设计意图 |
|------|----------|------|----------|
| **schedulingRequestId** | 0~7 | SR配置唯一标识 | 支持多个逻辑信道映射到不同SR配置，实现差异化调度 |
| **sr-TransMax** | {n1,n2,n4,n8,n16,n32,n64} | SR最大重传次数 | 控制SR失败判定的时间窗口，URLLC倾向小值（快速回退RA），mMTC倾向大值（减少RA开销） |
### 2.2 SchedulingRequestResourceConfig IE
每个SR配置可关联一个SR资源，核心参数：
| 参数 | 取值 | 含义 | 实战影响 |
|------|------|------|----------|
| **periodicityAndOffset** | sym{2,6,7}~sl{1,2,4,...,640} | SR发送时机的周期与偏移 | 周期越小→时延越低但PUCCH开销越大；URLLC配sym级，eMBB配sl级 |
| **sr-ProhibitTimer** | {1,2,4,8,16,32,64,128} slots | SR发送后禁止重发的等待时间 | 防止SR"轰炸"gNB；值太大增加时延，太小浪费PUCCH资源 |
| **resource** | PUCCH-ResourceId | 关联的PUCCH资源 | 指向PUCCH-Config中的具体PUCCH Format 0/1资源 |
### 2.3 逻辑信道到SR的映射
在`LogicalChannelConfig`中，通过`sr-ConfigIndex`将逻辑信道映射到特定的SR配置。这意味着**不同优先级的逻辑信道可以使用不同的SR参数**——例如，URLLC承载映射到周期2符号的SR资源，而eMBB承载映射到周期10 slot的SR资源。
## 三、SR完整信令时序图
下图展示了从数据到达、SR触发、到SR成功或失败的完整信令流程（基于TS 38.321 Section 5.4.4）：
```mermaid
sequenceDiagram
participant RLC as RLC层
participant MAC as MAC层
participant PHY as PHY层(PUCCH)
participant gNB as gNB
Note over RLC,MAC: Step 1: 数据到达触发BSR
RLC->>MAC: 新数据到达，触发Regular BSR
MAC->>MAC: 检查：无有效UL Grant?
MAC->>MAC: 检查：SR资源已配置?
Note over MAC: 条件满足 → 触发SR (Pending SR)
Note over MAC,PHY: Step 2: SR发送
MAC->>MAC: SR_COUNTER < sr-TransMax?
MAC->>MAC: sr-ProhibitTimer未运行或已超时?
MAC->>PHY: 指示在PUCCH发送SR(Positive SR)
PHY->>gNB: PUCCH Format 0/1 发送SR
MAC->>MAC: SR_COUNTER++
MAC->>MAC: 启动sr-ProhibitTimer
alt SR成功路径
Note over gNB,MAC: Step 3a: gNB响应
gNB->>PHY: DCI Format 0_1 (C-RNTI加扰的UL Grant)
PHY->>MAC: UL Grant指示
MAC->>MAC: 取消所有Pending SR
MAC->>MAC: SR_COUNTER = 0
MAC->>MAC: 停止sr-ProhibitTimer
MAC->>gNB: PUSCH传输上行数据(含BSR MAC CE)
else SR失败路径
Note over MAC: Step 3b: sr-ProhibitTimer超时
MAC->>MAC: sr-ProhibitTimer超时 → 重新尝试SR
PHY->>gNB: 再次PUCCH发送SR
MAC->>MAC: SR_COUNTER++
Note over MAC: 循环直到SR_COUNTER ≥ sr-TransMax
MAC->>MAC: SR失败！
MAC->>MAC: 取消所有Pending SR
MAC->>MAC: 释放PUCCH SR资源
MAC->>MAC: 触发Contention-Based RA
Note over MAC,gNB: 进入随机接入流程
end
```
### 关键信令节点解析
**Step 1 - BSR触发条件**：TS 38.321 Section 5.4.4规定，SR在以下条件同时满足时被触发：
1. 有Regular BSR被触发（新高优先级数据到达或retxBSR-Timer超时）
2. 没有可用的UL-SCH资源来发送BSR MAC CE
3. SR尚未处于Pending状态
**Step 2 - SR发送条件**：UE在发送SR前必须同时检查三个条件：
1. `SR_COUNTER < sr-TransMax`（未超过最大重传次数）
2. `sr-ProhibitTimer`未运行或已超时（满足最小发送间隔）
3. 当前时刻有可用的SR PUCCH时机（periodicityAndOffset决定）
**Step 3 - SR成功/失败**：
- **成功**：UE收到C-RNTI加扰的DCI 0_0或DCI 0_1（包含UL Grant），即认为SR成功
- **失败**：SR_COUNTER达到sr-TransMax，未收到任何UL Grant
## 四、SR状态机：三阶段定时器链博弈
SR机制的核心是一个精确的状态机，由三个定时器/计数器驱动。下图展示其状态转换：
```mermaid
stateDiagram-v2
[*] --> Idle: 无数据待发
Idle --> SR_Triggered: Regular BSR触发
且无UL Grant
SR_Triggered --> Waiting_SR_Occasion: SR资源已配置
SR_Triggered --> RA_Procedure: SR资源未配置
→ 直接触发RA
Waiting_SR_Occasion --> SR_Sent: SR时机到达
sr-ProhibitTimer未运行
SR_COUNTER < sr-TransMax
SR_Sent --> Waiting_UL_Grant: 启动sr-ProhibitTimer
SR_COUNTER++
Waiting_UL_Grant --> SR_Success: 收到C-RNTI UL Grant
→ 取消SR，计数器清零
Waiting_UL_Grant --> Waiting_SR_Occasion: sr-ProhibitTimer超时
且SR_COUNTER < sr-TransMax
Waiting_UL_Grant --> SR_Failure: SR_COUNTER ≥ sr-TransMax
未收到UL Grant
SR_Failure --> RA_Procedure: 释放PUCCH资源
触发CBRA
SR_Success --> Idle: 数据发送完成
RA_Procedure --> Idle: RA成功，gNB重配SR资源
RA_Procedure --> RLF: RA也失败
→ 触发RLF
```
### 4.1 定时器链的时间计算
SR从触发到成功（或失败）的总时间取决于三个参数的协同：
**SR最小周期** = `periodicityAndOffset`决定的SR时机间隔
**SR最大等待时间（SR失败前）** = `sr-TransMax × max(periodicityAndOffset, sr-ProhibitTimer)`
以一个典型配置为例：
| 参数 | 配置值 | 说明 |
|------|--------|------|
| periodicityAndOffset | sl10（10个slot） | 每10个slot一个SR时机 |
| sr-ProhibitTimer | 8 slots | 每次SR后等待8个slot |
| sr-TransMax | n64 | 最多64次SR |
| 子载波间隔 | 30kHz（μ=1） | 每slot=0.5ms |
**最大SR等待时间** = 64 × 10 × 0.5ms = **320ms**
**对比配置**：如果改为URLLC场景——periodicity=sym6（6个OFDM符号）、sr-ProhibitTimer=1 slot、sr-TransMax=n4：
**最大SR等待时间** = 4 × 6 × (1/28)ms ≈ **0.86ms**（30kHz SCS，每slot 14个符号）
这组数据的差异揭示了SR配置的核心博弈：
| 场景 | 周期 | sr-TransMax | 最大等待 | PUCCH开销 | 典型业务 |
|------|------|-------------|----------|-----------|----------|
| **URLLC超低时延** | sym2~sym6 | n4 | <1ms | 高 | 工业控制、V2X |
| **eMBB均衡** | sl10~sl20 | n16~n32 | 80~320ms | 中 | 视频流、网页浏览 |
| **mMTC省电** | sl80~sl640 | n64 | 数秒级 | 低 | IoT传感器 |
| **VoLTE/VoNR** | sl4~sl10 | n8 | 20~80ms | 中 | 语音通话 |
## 五、SR与BSR的联动机制
SR并非孤立运作，它与BSR（Buffer Status Report）形成**"敲门→汇报"的两阶段上行调度博弈**：
```mermaid
flowchart TD
A["数据到达
RLC Buffer"] --> B{"有UL Grant?"}
B -->|是| C["发送Padding BSR
或Periodic BSR
（搭载在PUSCH上）"]
B -->|否| D["触发Regular BSR"]
D --> E{"SR资源配置?"}
E -->|已配置| F["发送SR
（PUCCH敲门）"]
E -->|未配置| G["发起CBRA
（PRACH敲门）"]
F --> H{"gNB响应?"}
H -->|UL Grant| I["发送BSR MAC CE
（PUSCH汇报缓存状态）"]
H -->|无响应| J["SR重试/失败回退"]
I --> K["gNB按需分配
后续UL Grant"]
G --> L{"RA成功?"}
L -->|Msg2 UL Grant| I
L -->|失败| M["RLF处理"]
```
**关键设计意图**：SR只告诉gNB"我有数据要发"，但不告诉gNB"有多少数据"。gNB在收到SR后，先分配一个**最小UL Grant**（通常只够发BSR MAC CE），UE通过BSR报告具体缓存状态后，gNB再分配足够大的PUSCH资源。这种**两步调度**避免了SR阶段就分配过大资源的浪费。
### BSR触发SR的条件（TS 38.321 Section 5.4.4）
| BSR类型 | 触发条件 | 是否触发SR |
|---------|----------|-----------|
| **Regular BSR** | 新数据到达（优先级高于当前buffer）或retxBSR-Timer超时且buffer非空 | 是（若无UL Grant） |
| **Periodic BSR** | periodicBSR-Timer超时 | 否（等下次UL Grant时搭载） |
| **Padding BSR** | PUSCH有剩余padding空间 | 否（已有UL Grant） |
## 六、SR失败三径回退机制深度解析
当SR_COUNTER达到sr-TransMax时，SR失败处理流程（TS 38.321 Section 5.4.4）如下：
### 第一径：PUCCH资源释放
```
1. 取消所有Pending SR（所有SR配置）
2. 清除SR_COUNTER
3. 停止sr-ProhibitTimer
4. 通知RRC层：释放所有 Serving Cell 的 PUCCH SchedulingRequest资源
```
这是一个**破坏性操作**——UE失去了所有专用SR资源，意味着后续任何上行数据到达都无法再通过SR请求资源。
### 第二径：触发Contention-Based RA
SR失败后，UE立即触发**基于竞争的随机接入（CBRA）**（TS 38.321 Section 5.1）。为什么是CBRA而不是CFRA？
- CFRA（无竞争RA）需要专用preamble分配，通常在切换场景由gNB提前配置
- SR失败意味着UE与gNB之间的PUCCH通信已经断裂，gNB不太可能已经为UE准备了专用preamble
- CBRA虽然有多UE碰撞风险，但能自主发起、无需gNB预配置
### 第三径：RA失败→RLF
如果CBRA也失败（PREAMBLE_TRANSMIT_COUNTER达到preambleTransMax），UE将触发**Radio Link Failure（RLF）**，进入RRC重建流程。
**完整失败链**：
```
SR失败 → PUCCH资源释放 → CBRA发起 → RA成功？
├─ 是 → gNB通过RRC Reconfig重配SR资源
└─ 否 → RLF → RRC Reestablishment/Recovery
```
### 失败回退的时间成本
| 阶段 | 典型时延 | 累计时延 |
|------|----------|----------|
| SR阶段（sr-TransMax耗尽） | 80~320ms（典型） | 80~320ms |
| CBRA 4步完成 | 5~15ms | 85~335ms |
| **RRC重配SR资源** | 10~30ms | 95~365ms |
| **若RA也失败：RLF+重建** | 100~500ms | 180~865ms |
对于URLLC业务，SR失败意味着**端到端时延从<1ms飙升至数百毫秒**，几乎等同于业务中断。
## 七、PUCCH Format选择与SR物理层实现
SR在物理层通过两种PUCCH Format承载（TS 38.213 Section 9.2.4）：
| 特性 | PUCCH Format 0 | PUCCH Format 1 |
|------|----------------|----------------|
| **符号数** | 1~2 OFDM符号 | 4~14 OFDM符号 |
| **信息量** | 1~2 bit（SR=1bit） | 1~2 bit（SR=1bit） |
| **序列** | 低峰均比序列循环移位 | DMRS + 调制符号（BPSK/QPSK） |
| **覆盖** | 弱（短符号） | 强（长符号+跳频） |
| **SR复用** | 不同UE用不同循环移位 | 不同UE用不同正交序列 |
| **适用场景** | 小区中心、URLLC低时延 | 小区边缘、覆盖增强 |
### SR的"正/负"传输
NR中SR的设计非常巧妙——UE不需要每次SR时机都显式发送。当UE没有SR Pending时，在SR时机上**保持静默**（不发送PUCCH）。gNB侧的检测逻辑：
- **检测到PUCCH信号** → Positive SR → 分配UL Grant
- **未检测到PUCCH信号** → Negative SR → 不做任何操作
这种"沉默即否定"的设计，**节省了所有无SR需求UE的PUCCH发射功率**。
## 八、logicalChannelSR-DelayTimer的省电博弈
TS 38.331在`LogicalChannelConfig`中定义了一个容易被忽视的参数——**logicalChannelSR-DelayTimer**。它的作用是：
> 当某个逻辑信道的数据到达时，不是立即触发SR，而是延迟这个定时器的时间后再检查是否仍需要发送SR。
这个参数的博弈点：
| 策略 | 配置 | 效果 | 适用场景 |
|------|------|------|----------|
| **立即SR** | 不配置或0 | 数据到达即触发SR，时延最低 | URLLC、VoNR |
| **延迟SR** | 5~20ms | 等待是否有其他逻辑信道同时有数据，一次SR+BSR解决 | eMBB、背景数据 |
| **长延迟SR** | 20~50ms | 最大化批量调度效率 | 软件更新、IoT上报 |
**运营商博弈视角**：延迟SR可以减少PUCCH信道占用率（PUCCH Utilization），在用户密集场景（如体育场、地铁）中，每UE减少一次SR发送就释放一个PUCCH RE，大规模用户下可节省显著的PUCCH资源。但代价是**增加了首包时延**。
## 九、抓包识别与排错实战
### 9.1 抓包识别SR流程
在**L1/L2 MAC Log**中识别SR流程的关键事件：
| 日志事件 | 含义 | 关键字段 |
|----------|------|----------|
| `SR_TRIGGER` | SR被触发 | sr-ConfigIndex, logicalChannelIdentity |
| `SR_TX` | SR在PUCCH上发送 | pucch-ResourceId, SR_COUNTER |
| `SR_GRANT_RX` | 收到UL Grant（SR成功） | dci-Format, rnti-Type=C-RNTI |
| `SR_FAIL` | SR失败 | SR_COUNTER, sr-TransMax |
| `RA_TRIGGER` | 随机接入触发 | ra-Type=CBRA, trigger=SR_FAILURE |
### 9.2 常见故障场景
**故障1：SR发送但gNB无响应**
现象：UE日志显示SR_TX反复出现，SR_COUNTER递增到sr-TransMax后触发RA。
排查路径：
1. 检查UE PUCCH发射功率是否足够（PUCCH Power Control中的P0和pathloss计算）
2. 检查gNB是否在SR时机对应的PUCCH资源上监听（RRC配置一致性）
3. 检查SR时机的periodicityAndOffset是否与gNB侧配置匹配
4. 检查是否存在PUCCH资源冲突（多个UE被分配相同SR资源）
**故障2：SR成功但UL Grant过小**
现象：UE收到UL Grant，但Grant大小不足以发送BSR+数据。
原因：gNB的SR响应策略——部分厂商实现为"SR响应分配最小Grant"，等待BSR后再分配大Grant。这不是故障，而是设计行为。
**故障3：SR周期配置不合理导致时延过高**
现象：ping时延抖动大，上行首包时延>50ms。
排查：检查periodicityAndOffset是否配置为sl80或更高。对于时延敏感业务，建议调整为sl4~sl10。
## 十、NR SR vs LTE SR：关键演进
| 特性 | LTE SR | NR SR |
|------|--------|-------|
| **最大SR配置数** | 1个 | 8个 |
| **SR周期范围** | {5,10,20,40,80}ms | sym2~sl640（跨3个数量级） |
| **PUCCH Format** | Format 1 only | Format 0 或 Format 1 |
| **逻辑信道差异化SR** | 不支持 | 支持（sr-ConfigIndex映射） |
| **SR延迟机制** | 无 | logicalChannelSR-DelayTimer |
| **SR失败处理** | 触发RA | 释放PUCCH + 触发RA |
| **SR与BWP联动** | 无BWP概念 | SR资源per-BWP配置 |
NR SR相比LTE最大的演进在于**多SR配置+逻辑信道差异化映射**。这使得运营商可以为同一个UE的不同业务（如VoNR语音+视频流+背景数据）配置不同SR参数，实现**精细化上行调度控制**。
## 常见问题
**Q1: SR失败后gNB是否会主动重配SR资源？**
A: SR失败后UE触发CBRA。RA成功后（Msg4竞争解决完成），gNB通常会通过`RRCReconfiguration`消息重新配置PUCCH资源（包括SR资源）。但如果gNB检测到UE处于小区边缘（路径损耗大），可能选择**不重配专用SR资源**，改为让UE使用RA进行上行调度请求，以降低PUCCH开销。
**Q2: sr-ProhibitTimer配置为0或不配置有什么区别？**
A: `sr-ProhibitTimer`是OPTIONAL参数（TS 38.331）。如果**不配置**，UE在SR发送后不启动禁止定时器，可以在下一个SR时机立即重发SR。如果配置为**1 slot**（最小值），UE至少等待1个slot后才能重发。不配置的场景适用于URLLC超低时延需求，但会增加gNB的SR检测负担。
**Q3: 为什么SR只携带1比特信息，不携带BSR？**
A: 这是物理层设计的权衡。PUCCH Format 0只有1~2个OFDM符号，无法承载大量信息。将BSR放在SR中需要更长的PUCCH传输（如PUCCH Format 2~4的CSI复用），会显著增加PUCCH开销。两步设计（SR敲门→BSR汇报）用最小物理层开销换取调度机会，BSR通过gNB分配的UL Grant搭载在PUSCH上发送。
**Q4: 一个UE为什么需要8个SR配置？**
A: 8个SR配置用于支持**差异化业务调度**。例如：SR#0（周期sym6, sr-TransMax=n4）映射到URLLC逻辑信道，SR#1（周期sl10, sr-TransMax=n16）映射到eMBB逻辑信道，SR#2（周期sl80, sr-TransMax=n64）映射到mMTC逻辑信道。gNB通过检测哪个SR资源上有信号，就能推断出UE请求的是哪种业务类型的资源。
**Q5: SR在RRC_INACTIVE状态下能用吗？**
A: 不能。SR需要专用PUCCH资源，而专用PUCCH资源只在RRC_CONNECTED状态下配置。在RRC_INACTIVE状态，UE如果有数据要发送，需要先通过RRC Resume流程恢复到RRC_CONNECTED状态（其中包含RA过程），之后gNB才会配置SR资源。
## 参考来源
1. [3GPP TS 38.321 V19.x.x](https://www.3gpp.org/DynaReport/38321.htm) — Section 5.4.4 Scheduling Request handling, Section 5.1 Random Access procedure
2. [3GPP TS 38.331 V19.x.x](https://www.3gpp.org/DynaReport/38331.htm) — Section 6.3.2 SchedulingRequestConfig, SchedulingRequestResourceConfig, LogicalChannelConfig IE定义
3. [3GPP TS 38.213 V19.x.x](https://www.3gpp.org/DynaReport/38213.htm) — Section 9.2.4 SR transmission on PUCCH物理层过程
4. [ShareTechnote - 5G SR](https://www.sharetechnote.com/html/5G/5G_SR.html) — SR RRC配置参数详解与PUCCH资源映射
5. [RF Wireless World - 5G NR Scheduling Request](https://www.rfwireless-world.com/articles/5g-nr-scheduling-request-procedure) — SR信令流程图解
6. [CSDN - NR Scheduling Request深度解析](https://blog.csdn.net/kakamilan/article/details/103884750) — SR物理层资源配置与PUCCH Format分析
7. [WirelessBrew - SR in 5G-NR](https://www.wirelessbrew.com/5g-nr/scheduling-request-in-5g-nr/) — RRC配置日志分析与多SR配置实战
---
> 本文由「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 等场景全覆盖。
