<!-- title: NR跨时隙调度K0/K1时序与处理能力博弈 -->
<!-- domain: ran -->

# NR跨时隙调度K0/K1时序与UE处理能力博弈

## 一、从LTE到NR：为什么需要K0/K1灵活时序

LTE时代，下行调度遵循严格的固定时序关系：PDCCH在子帧n调度PDSCH，PDSCH在子帧n传输，HARQ-ACK在子帧n+4反馈。这套固定4ms的RTT（Round Trip Time）简化了UE实现，但也限制了系统灵活性。

NR引入了三个关键时序偏移参数彻底打破这一固定模式：

| 参数 | 含义 | 定义位置 |
|------|------|----------|
| **K0** | DCI到PDSCH的时隙偏移 | TS 38.214 Section 5.1.2.1 |
| **K1** | PDSCH到HARQ-ACK（PUCCH）的时隙偏移 | TS 38.213 Section 9.2.3 |
| **K2** | DCI到PUSCH的时隙偏移 | TS 38.214 Section 6.1.2.1 |

这套灵活时序的设计意图是三重的：**适配多种子载波间隔（SCS）**、**兼容不同UE处理能力**、**支持URLLC等低时延场景的快速调度**。

```mermaid
sequenceDiagram
    participant gNB
    participant UE
    
    Note over gNB,UE: 时隙 n: gNB发送DCI（PDCCH）
    gNB->>UE: DCI Format 1_1/1_2（含K0值）
    
    Note over gNB,UE: 时隙 n+K0: PDSCH传输
    gNB->>UE: PDSCH（SLIV确定起止符号）
    
    Note over UE: UE处理PDSCH（N1 symbols）
    
    Note over gNB,UE: 时隙 n+K0+K1: HARQ-ACK反馈
    UE->>gNB: PUCCH（ACK/NACK）
    
    Note over gNB,UE: 上行调度链路
    gNB->>UE: DCI Format 0_1/0_2（含K2值）
    Note over gNB,UE: 时隙 n+K2: PUSCH传输
    UE->>gNB: PUSCH
```

## 二、K0：DCI到PDSCH的时隙偏移机制

### 2.1 K0的确定流程

K0不是凭空指定的，它由一条三层配置链决定：

**第一层：RRC配置时域资源分配表。** gNB通过`PDSCH-Config`中的`pdsch-TimeDomainAllocationList`为UE配置一张时域分配表（最多28行）。如果UE未配置该表，则使用TS 38.214 Table 5.1.2.1.1-2/3/4中定义的Default A/B/C默认表。

**第二层：DCI中的Time domain resource assignment字段选择行号。** DCI Format 1_1/1_2中的`Time domain resource assignment`字段值为`m`，指向时域分配表的第`m+1`行。

**第三层：行中包含K0、SLIV和PDSCH映射类型。** 每行提供三个关键参数：K0值、SLIV（Start and Length Indicator Value，编码起始符号S和分配长度L）、映射类型（Type A或Type B）。

```mermaid
flowchart TB
    A["RRC层配置<br/>pdsch-TimeDomainAllocationList<br/>（最多28行）"] -->|"若未配置"| B["使用Default表<br/>Table 5.1.2.1.1-2/3/4"]
    A -->|"若已配置"| C["自定义时域分配表"]
    B --> D["DCI中Time domain<br/>resource assignment字段"]
    C --> D
    D -->|"行索引 m"| E["读取第m+1行"]
    E --> F["K0: 时隙偏移"]
    E --> G["SLIV: 起始符号S + 长度L"]
    E --> H["映射类型: Type A / Type B"]

    style A fill:#1a73e8,color:#fff
    style D fill:#ea4335,color:#fff
    style F fill:#34a853,color:#fff
    style G fill:#fbbc04,color:#333
    style H fill:#34a853,color:#fff
```

### 2.2 Default A表：最常用的默认配置

Default A表（TS 38.214 Table 5.1.2.1.1-2）是Normal CP下最广泛使用的默认时域分配表。以下为FR1 15kHz SCS下的Default A表示例：

| 行索引 | K0 | SLIV解码 (S, L) | 映射类型 | 实际含义 |
|--------|-----|-----------------|----------|----------|
| 0 | 0 | (2, 12) | Type A | 符号2-13，全slot分配 |
| 1 | 0 | (3, 11) | Type A | 符号3-13 |
| 2 | 0 | (5, 9) | Type A | 符号5-13 |
| 3 | 0 | (7, 7) | Type A | 符号7-13 |
| 4 | 0 | (9, 5) | Type A | 符号9-13 |
| 5 | 0 | (2, 3) | Type B | 符号2-4，前向mini-slot |
| 6 | 0 | (4, 3) | Type B | 符号4-6 |
| 7 | 0 | (6, 3) | Type B | 符号6-8 |
| 8 | 0 | (8, 3) | Type B | 符号8-10 |
| 9 | 0 | (10, 3) | Type B | 符号10-12 |

**SLIV编码规则**（TS 38.214 Section 5.1.2.1）：

$$SLIV = \begin{cases} 14 \cdot (L-1) + S & \text{if } (L-1) \leq 7 \\ 14 \cdot (14-L) + (14-1-S) & \text{if } (L-1) > 7 \end{cases}$$

例如SLIV=28：$(L-1)=2 \leq 7$，所以 $28 = 14 \times 2 + 0$，即 $L=3, S=0$。但注意Default A中符号0和1通常保留给PDCCH CORESET。

### 2.3 K0=0 vs K0≥1：同slot调度与跨slot调度的抉择

| 维度 | K0=0（同slot调度） | K0≥1（跨slot调度） |
|------|---------------------|---------------------|
| **时延** | 最低，DCI和PDSCH同slot传输 | 增加1个或多个slot延迟 |
| **UE处理压力** | 最大，需在slot内完成DCI解析到PDSCH接收 | 有缓冲时间，降低处理要求 |
| **适用场景** | URLLC、低时延eMBB | RedCap、IoT、覆盖受限场景 |
| **功耗** | UE需持续监听和处理 | UE可利用间隙省电 |
| **R17+增强** | Rel-17引入minimumSchedulingOffsetK0-r17 | — |

R16/R17引入了`minimumSchedulingOffsetK0`，UE通过`UE-NR-Capability`中的`PDSCH-ServingCellConfig`上报自己支持的最小K0值。若UE上报最小K0=1，则gNB**不能**对该UE使用K0=0的调度。

## 三、K1：PDSCH到HARQ-ACK反馈时序

### 3.1 K1的配置与动态指示

K1通过两条路径确定：

**RRC半静态配置：** `PDSCH-Config`中的`dl-DataToUL-ACK`字段提供一组候选K1值（最多8个），例如 {1, 2, 3, 4, 5, 6, 7, 8}。

**DCI动态选择：** DCI Format 1_1/1_2中的`PDSCH-to-HARQ_feedback timing indicator`字段（3bit或更高）从RRC配置的候选列表中选择具体的K1值。

```mermaid
sequenceDiagram
    participant RRC as RRC层
    participant DCI as DCI层
    participant PHY as PHY层
    participant UC as UCI处理
    
    Note over RRC: dl-DataToUL-ACK<br/>配置候选K1集合<br/>{1,2,3,4,5,6,7,8}
    RRC->>DCI: 提供K1候选列表
    
    Note over DCI: PDSCH-to-HARQ_feedback<br/>timing indicator = 3bits<br/>例如值=2 → 选K1=3
    DCI->>PHY: K1=3 selected
    
    Note over PHY: PDSCH在时隙n接收<br/>HARQ-ACK在时隙n+K1=n+3发送
    
    Note over PHY: 但必须满足N1处理时间约束
    PHY->>UC: PDSCH解码（需N1 symbols）
    UC->>UC: 确认n+K1时隙中<br/>最早可用PUCCH符号 ≥<br/>PDSCH最后符号 + N1
```

### 3.2 K1的隐式约束：N1处理时间检查

K1不是无限可选的。UE必须验证在所选K1值下，HARQ-ACK反馈时刻满足PDSCH处理时间约束。具体检查公式（TS 38.214 Section 5.3）：

$$N_{T,1} + N_{T,2} + N_{d} \leq T_{proc,1}$$

其中：
- $N_{T,1}$ = PDSCH处理时间（OFDM符号数），取决于UE Capability Type
- $N_{T,2}$ = PUSCH准备时间（复用到PUCCH时使用）
- $N_d$ = DCI处理时间
- $T_{proc,1}$ = 从PDSCH最后一个符号到HARQ-ACK第一个符号之间的实际时间间隔

若K1太小导致上述不等式不成立，UE会跳过该PDSCH的接收——这是一个**隐式调度冲突**。

## 四、UE处理能力Type 1 vs Type 2：博弈的核心

### 4.1 N1处理时间表详解

TS 38.214 Section 5.3定义了两套PDSCH处理时间表，分别对应Capability Type 1（基线）和Capability Type 2（增强）。

**Table: Capability Type 1 FR1 N1值（TS 38.214 Table 5.3-1）**

| SCS | DM-RS Type 1<br/>无additional | DM-RS Type 2<br/>无additional | DM-RS Type 1<br/>有additional | DM-RS Type 2<br/>有additional |
|-----|------|------|------|------|
| 15 kHz | **8** sym | **10** sym | **13** sym | **13** sym |
| 30 kHz | **10** sym | **11** sym | **13** sym | **13** sym |
| 60 kHz | **17** sym | **20** sym | **20** sym | **20** sym |

**Table: Capability Type 2 FR1 N1值（TS 38.214 Table 5.3-3）**

| SCS | DM-RS Type 1<br/>无additional | DM-RS Type 2<br/>无additional | DM-RS Type 1<br/>有additional | DM-RS Type 2<br/>有additional |
|-----|------|------|------|------|
| 15 kHz | **3** sym | **4** sym | **5** sym | **5** sym |
| 30 kHz | **4.5** sym | **5** sym | **5.5** sym | **6** sym |

Type 2的N1值约为Type 1的**40%~60%**，这意味着支持Type 2的UE可以使用更小的K0和K1，从而实现更低的端到端时延。

### 4.2 处理能力上报：RRC信令结构

UE通过`UECapabilityInformation`消息上报其处理能力。关键IE结构如下（TS 38.331）：

```
UE-NR-Capability
├── pdsch-ProcessingType1-DifferentTB-PerSlot
│   ├── maxNumberMIMO-LayersPDSCH  (支持的MIMO层数)
│   └── maxNumberProcessedBits      (处理比特数上限)
├── pdsch-ProcessingType2-DifferentTB-PerSlot
│   ├── supported                   (是否支持Type 2)
│   ├── maxNumberMIMO-LayersPDSCH
│   └── maxNumberProcessedBits
├── pdsch-ProcessingType1-SameTB-PerSlot
│   └── maxNumberProcessedBits
├── pdsch-ProcessingType2-SameTB-PerSlot
│   └── supported
├── processingType2Enabled          (全局Type 2使能开关)
└── PDSCH-ServingCellConfig
    └── minimumSchedulingOffsetK0-r16  (最小K0值)
```

```mermaid
stateDiagram-v2
    [*] --> CapabilityType1: 所有UE默认支持
    
    state CapabilityType1 {
        [*] --> K0_ge_0: 基线处理能力
        K0_ge_0 --> Type1_N1_8: FR1 15kHz<br/>DMRS Type1
        K0_ge_0 --> Type1_N1_10: FR1 30kHz<br/>DMRS Type1
    }
    
    CapabilityType1 --> CapabilityType2: UE上报<br/>processingType2Enabled=true
    
    state CapabilityType2 {
        [*] --> K0_eq_0_possible: 增强处理能力
        K0_eq_0_possible --> Type2_N1_3: FR1 15kHz<br/>DMRS Type1
        K0_eq_0_possible --> Type2_N1_4_5: FR1 30kHz<br/>DMRS Type1
    }
    
    CapabilityType2 --> URLLC_Optimized: gNB配置<br/>Type2调度策略
    
    state URLLC_Optimized {
        [*] --> MiniSlot_2_4_7sym: K0=0<br/>mini-slot调度
        MiniSlot_2_4_7sym --> K1_min_1: 最短K1=1<br/>（需满足N1约束）
    }
```

### 4.3 博弈分析：Type 1 vs Type 2的成本密码

| 维度 | Type 1（基线） | Type 2（增强） |
|------|---------------|---------------|
| **芯片成本** | 标准基带处理器 | 需要更强的LDPC解码器和FFT引擎 |
| **功耗** | 正常（N1充裕） | 高（需在更短时间内完成处理） |
| **支持的K0范围** | K0≥0或K0≥1（取决于上报） | K0=0无压力 |
| **支持的K1范围** | K1≥3~4（FR1 15kHz） | K1≥1~2 |
| **空口时延（单向）** | ~4-8 slot | ~1-2 slot |
| **适用终端** | 普通手机、CPE、RedCap | URLLC模组、高端旗舰 |
| **MIMO支持** | 1~4层 | 通常限制1~2层（处理复杂度换时间） |

**运营商博弈点：** 支持Type 2的UE意味着gNB可以使用更激进的K0/K1配置来降低空口时延，但这些UE通常更贵、功耗更高。在RedCap和物联网场景中，运营商往往强制使用Type 1并配置较大的K0/K1，以降低终端成本和延长电池寿命。

## 五、跨时隙调度的完整信令流分析

### 5.1 从Attach到首次PDSCH调度的K0/K1全链路

```mermaid
sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    
    Note over UE,gNB: Step 1: UE能力上报
    UE->>gNB: UECapabilityInformation<br/>（含processingType2Enabled, minK0等）
    gNB->>gNB: 根据UE能力决定<br/>调度策略
    
    Note over UE,gNB: Step 2: RRC重配建立时域参数
    gNB->>UE: RRCReconfiguration<br/>PDSCH-Config<br/>├ pdsch-TimeDomainAllocationList<br/>├ dl-DataToUL-ACK {1,2,3,4}<br/>└ dmrs-DownlinkForPDSCH
    
    Note over UE,gNB: Step 3: 首次下行调度
    gNB->>UE: DCI Format 1_1<br/>Time domain resource assignment = m<br/>PDSCH-to-HARQ_feedback = k
    
    Note over UE: Step 4: UE解析时域分配<br/>查表第m+1行 → K0, SLIV<br/>K1 = dl-DataToUL-ACK[k]
    
    Note over UE,gNB: Step 5: PDSCH传输
    gNB->>UE: PDSCH（slot n+K0）
    
    Note over UE: Step 6: PDSCH处理<br/>N1 symbols处理时间<br/>检查K1是否满足约束
    
    alt K1满足N1约束
        UE->>gNB: PUCCH HARQ-ACK<br/>（slot n+K0+K1）
    else K1不满足N1约束
        Note over UE: UE跳过PDSCH接收<br/>（协议规定行为）
    end
```

### 5.2 DCI 1_1中的时域资源分配字段解码

DCI Format 1_1中与K0/K1相关的关键字段：

| DCI字段 | 比特数 | 作用 |
|---------|--------|------|
| Time domain resource assignment | $\lceil\log_2(N_{rows})\rceil$ | 选择时域分配表的行号，间接确定K0和SLIV |
| PDSCH-to-HARQ_feedback timing indicator | $\lceil\log_2(N_{K1})\rceil$ | 从dl-DataToUL-ACK列表中选择K1值 |

**解码示例：**

假设gNB配置了`pdsch-TimeDomainAllocationList`共16行，`dl-DataToUL-ACK` = {1, 2, 3, 4, 5, 6, 7, 8}。

- Time domain resource assignment字段宽度 = $\lceil\log_2(16)\rceil$ = 4 bits
- 若DCI中该字段值为 `0101`（即5），则选择第6行
- 第6行内容：K0=0, SLIV=60 → S=4, L=3, 映射类型Type B
- PDSCH-to-HARQ_feedback timing indicator字段宽度 = $\lceil\log_2(8)\rceil$ = 3 bits
- 若该字段值为 `010`（即2），则K1 = dl-DataToUL-ACK[2] = 3

## 六、多时隙/多PDSCH调度的K0/K1扩展

### 6.1 同TB多PDSCH调度（Rel-17增强）

Rel-17引入了`pdsch-ProcessingType1-SameTB-PerSlot`和`pdsch-ProcessingType2-SameTB-PerSlot`能力，允许gNB在一个DCI中调度同一TB的多次PDSCH传输（用于重复传输提升覆盖）。

此时K0/K1的处理变化：
- 每次PDSCH重复使用不同的K0值（通过时域分配表中的不同行或同一行中的多K0配置）
- HARQ-ACK只需对最后一次重复反馈
- K1从**最后一次PDSCH重复**的slot开始计算

### 6.2 不同TB多PDSCH调度（Rel-16增强）

`pdsch-ProcessingType1-DifferentTB-PerSlot`允许在一个slot内调度多个不同TB的PDSCH。这对K0/K1的影响是：

- 每个TB需要独立的HARQ-ACK
- K1对所有TB可以相同（通过一个DCI调度）
- UE处理能力约束变为：在单个slot内完成多个PDSCH的解码

**Table: 多PDSCH调度能力对比**

| 特性 | 单TB调度 | 同TB多PDSCH | 不同TB多PDSCH |
|------|---------|-------------|---------------|
| Rel版本 | Rel-15 | Rel-17 | Rel-16 |
| 每slot PDSCH数 | 1 | 最多2~7 | 最多2~4 |
| HARQ-ACK数 | 1 | 1（最后TB） | 每TB各1个 |
| K0使用 | 单一K0 | 可不同 | 可不同 |
| K1计算基准 | PDSCH slot | 最后PDSCH slot | 每个PDSCH slot |
| UE能力要求 | 基线 | SameTB能力 | DifferentTB能力 |

## 七、抓包识别与故障排查

### 7.1 抓包识别K0/K1流程

**步骤1：在MAC/PHY层抓包中找到DCI Format 1_1**

在Wireshark或高通QXDM中过滤DCI Format 1_1消息，定位以下字段：
- `Time domain resource assignment` → 查表得到K0和SLIV
- `PDSCH-to-HARQ_feedback timing indicator` → 查dl-DataToUL-ACK得到K1

**步骤2：找到对应的RRC配置**

在RRC层日志中搜索`PDSCH-Config`消息，提取：
- `pdsch-TimeDomainAllocationList`：完整时域分配表
- `dl-DataToUL-ACK`：K1候选列表

**步骤3：验证时序关系**

在时域上对齐DCI→PDSCH→PUCCH的slot编号：
- DCI在slot n
- PDSCH应在slot n + K0
- PUCCH HARQ-ACK应在slot n + K0 + K1

若实际抓包显示PDSCH不在n+K0，则检查SLIV指示的符号位置是否有效。

### 7.2 常见故障点

| 故障现象 | 根因 | 排查方向 |
|---------|------|---------|
| UE未反馈HARQ-ACK | K1太小，N1约束不满足 | 检查UE Capability Type，增大K1 |
| PDSCH解码失败率高 | K0=0时UE来不及处理 | 改为K0≥1或切换到Type 2 |
| RedCap终端吞吐量低 | K0/K1配置过大 | 评估终端实际处理能力，优化配置 |
| 多PDSCH调度时丢包 | UE不支持DifferentTB-PerSlot | 检查UE能力上报，降低每slot PDSCH数 |
| HARQ-ACK码本不一致 | K1值在DCI中动态变化 | 使用Determined CBG或固定K1 |
| FR2场景调度失败 | N1查错表（用了FR1的表） | 确认使用Table 5.3-2或5.3-4 |
## 常见问题

**Q1: K0=0时UE如何处理PDCCH和PDSCH在同一个slot的冲突？**
A: K0=0时，PDSCH的起始符号由SLIV中的S值决定。Default A表中S最小为2，意味着符号0和1保留给PDCCH CORESET。UE在CORESET中解码DCI后，从符号S开始接收PDSCH。Type 2处理能力的UE能在几个符号内完成DCI解析，因此K0=0对Type 2 UE是可行的。

**Q2: 为什么Rel-16引入了minimumSchedulingOffsetK0，UE不能直接用K0=0？**
A: 部分低成本UE（如RedCap）的基带处理能力有限，无法在同一个slot内完成DCI解码到PDSCH接收的切换。通过上报minimumSchedulingOffsetK0=1，UE通知gNB必须提前至少1个slot下发DCI，给UE留出足够的处理时间。这是UE复杂度与调度灵活性之间的折衷。

**Q3: K1的dl-DataToUL-ACK列表最多8个值，如何支持更多K1？**
A: Rel-15中dl-DataToUL-ACK最多配置8个候选K1值，DCI中用3bit选择。对于大多数场景（eMBB、URLLC）已足够。Rel-16引入了增强的HARQ-ACK码本机制，允许在多slot聚合场景下更灵活的K1处理，但候选值数量限制仍然存在。

**Q4: Type 2处理能力在高MIMO层数下还适用吗？**
A: 不一定。Type 2的N1值假设较低的MIMO层数（通常1~2层）。当UE配置4层或更高MIMO时，实际处理时间可能超过Table 5.3-3中的标称N1值。UE通过`pdsch-ProcessingType2-DifferentTB-PerSlot`中的`maxNumberMIMO-LayersPDSCH`上报其在Type 2模式下支持的最大层数。gNB应据此限制MIMO配置。

**Q5: FR2（毫米波）场景下K0/K1有什么特殊考虑？**
A: FR2使用更大的SCS（60kHz/120kHz），slot时长更短（60kHz时slot=0.167ms），但N1的OFDM符号数更多（因为符号时间更短）。实际处理时间（绝对时间）可能与FR1相当或略长。此外，FR2支持波束赋形，PDCCH和PDSCH可能使用不同波束，需要额外的波束切换时间。因此FR2的K0/K1配置通常比FR1更保守。

## 参考来源

1. [3GPP TS 38.214 V18.5.0](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3216) — NR物理层数据过程，Section 5.1.2（PDSCH时域分配）、Section 5.3（UE处理时间）
2. [3GPP TS 38.331 V18.5.0](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3219) — NR RRC协议，PDSCH-Config IE定义、UE-NR-Capability结构
3. [ShareTechnote - 5G Resource Allocation](https://www.sharetechnote.com/html/5G/5G_ResourceAllocation.html) — K0/K1/K2时域资源分配详细图解
4. [LinkedIn - 5G-NR K0,K1 & K2 for Time Domain DL & UL Resource Allocation](https://www.linkedin.com/pulse/5g-nr-k0k1-k2-time-domain-dl-ul-resource-allocation-naveen-chelikani) — TS 38.214时域分配参数整理
5. [Amarisoft - NR SA TimeDomainAllocationList](https://tech-academy.amarisoft.com/NR_SA_TDLA.html) — PDSCH/PUSCH-TimeDomainAllocationList配置实践

---
> 本文由「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)