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中，形成配置层→资源层→映射层的三级架构：

graph TB
    subgraph "RRC配置三层架构"
        A["SchedulingRequestConfig<br/>（SR配置层）<br/>TS 38.331 Section 6.3.2"] --> B["SchedulingRequestResourceConfig<br/>（SR资源层）<br/>TS 38.331 Section 6.3.2"]
        B --> C["PUCCH-Config → PUCCH-ResourceSet<br/>（PUCCH物理资源层）<br/>TS 38.331 Section 6.3.2"]
        A --> D["LogicalChannelConfig<br/>（逻辑信道映射层）<br/>sr-ConfigIndex"]
    end

    subgraph "关键参数"
        A1["sr-TransMax: 最大SR发送次数<br/>{n1,n2,n4,n8,n16,n32,n64}"]
        B1["periodicityAndOffset: SR时机的周期和偏移<br/>sr-ProhibitTimer: SR禁止定时器<br/>resource: 关联的PUCCH资源ID"]
        C1["PUCCH Format 0: 1-2符号<br/>PUCCH Format 1: 4-14符号"]
        D1["logicalChannelSR-DelayTimer<br/>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配置包含：

2.2 SchedulingRequestResourceConfig IE

每个SR配置可关联一个SR资源，核心参数：

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）：

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机制的核心是一个精确的状态机，由三个定时器/计数器驱动。下图展示其状态转换：

stateDiagram-v2
    [*] --> Idle: 无数据待发
    Idle --> SR_Triggered: Regular BSR触发<br/>且无UL Grant

    SR_Triggered --> Waiting_SR_Occasion: SR资源已配置
    SR_Triggered --> RA_Procedure: SR资源未配置<br/>→ 直接触发RA

    Waiting_SR_Occasion --> SR_Sent: SR时机到达<br/>sr-ProhibitTimer未运行<br/>SR_COUNTER < sr-TransMax
    SR_Sent --> Waiting_UL_Grant: 启动sr-ProhibitTimer<br/>SR_COUNTER++

    Waiting_UL_Grant --> SR_Success: 收到C-RNTI UL Grant<br/>→ 取消SR，计数器清零
    Waiting_UL_Grant --> Waiting_SR_Occasion: sr-ProhibitTimer超时<br/>且SR_COUNTER < sr-TransMax
    Waiting_UL_Grant --> SR_Failure: SR_COUNTER ≥ sr-TransMax<br/>未收到UL Grant

    SR_Failure --> RA_Procedure: 释放PUCCH资源<br/>触发CBRA
    SR_Success --> Idle: 数据发送完成

    RA_Procedure --> Idle: RA成功，gNB重配SR资源
    RA_Procedure --> RLF: RA也失败<br/>→ 触发RLF

4.1 定时器链的时间计算

SR从触发到成功（或失败）的总时间取决于三个参数的协同：

SR最小周期 = periodicityAndOffset决定的SR时机间隔

SR最大等待时间（SR失败前） = sr-TransMax × max(periodicityAndOffset, sr-ProhibitTimer)

以一个典型配置为例：

最大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与BSR的联动机制

SR并非孤立运作，它与BSR（Buffer Status Report）形成"敲门→汇报"的两阶段上行调度博弈：

flowchart TD
    A["数据到达<br/>RLC Buffer"] --> B{"有UL Grant?"}
    B -->|是| C["发送Padding BSR<br/>或Periodic BSR<br/>（搭载在PUSCH上）"]
    B -->|否| D["触发Regular BSR"]
    D --> E{"SR资源配置?"}
    E -->|已配置| F["发送SR<br/>（PUCCH敲门）"]
    E -->|未配置| G["发起CBRA<br/>（PRACH敲门）"]
    F --> H{"gNB响应?"}
    H -->|UL Grant| I["发送BSR MAC CE<br/>（PUSCH汇报缓存状态）"]
    H -->|无响应| J["SR重试/失败回退"]
    I --> K["gNB按需分配<br/>后续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）

六、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

失败回退的时间成本

对于URLLC业务，SR失败意味着端到端时延从<1ms飙升至数百毫秒，几乎等同于业务中断。

七、PUCCH Format选择与SR物理层实现

SR在物理层通过两种PUCCH Format承载（TS 38.213 Section 9.2.4）：

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可以减少PUCCH信道占用率（PUCCH Utilization），在用户密集场景（如体育场、地铁）中，每UE减少一次SR发送就释放一个PUCCH RE，大规模用户下可节省显著的PUCCH资源。但代价是增加了首包时延。

九、抓包识别与排错实战

9.1 抓包识别SR流程

在L1/L2 MAC Log中识别SR流程的关键事件：

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：关键演进

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 — Section 5.4.4 Scheduling Request handling, Section 5.1 Random Access procedure
2. 3GPP TS 38.331 V19.x.x — Section 6.3.2 SchedulingRequestConfig, SchedulingRequestResourceConfig, LogicalChannelConfig IE定义
3. 3GPP TS 38.213 V19.x.x — Section 9.2.4 SR transmission on PUCCH物理层过程
4. ShareTechnote - 5G SR — SR RRC配置参数详解与PUCCH资源映射
5. RF Wireless World - 5G NR Scheduling Request — SR信令流程图解
6. CSDN - NR Scheduling Request深度解析 — SR物理层资源配置与PUCCH Format分析
7. WirelessBrew - SR 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 等场景全覆盖。