# NR SPS与CG配置授权双径调度博弈：从VoNR到URLLC的省电密码
在5G网络中，每一个上行数据包的发送都需要gNB的"调度授权"——UE发出调度请求(SR)，gNB回应DCI Grant，UE才能在PUSCH上发送数据。这条"请求→授权→发送"的三步链路，对eMBB大数据业务不算负担，但对VoNR语音包(每20ms一个)或URLLC工业控制包(周期<1ms)而言，PDCCH解码延迟和SR等待开销就是致命的。**SPS(半持续调度)**与**CG(配置授权Configured Grant)**正是NR为周期性业务设计的两条"免调度快车道"，它们在控制面开销、时延、灵活性之间走出截然不同的博弈路径。
---
## 一、双径调度的设计动机：为什么需要免调度？
### 1.1 动态调度的成本天花板
传统的动态调度(Dynamic Scheduling)流程如下：
```mermaid
sequenceDiagram
participant UE
participant gNB
Note over UE: 有上行数据到达
UE->>gNB: SR (PUCCH Format 0/1)
Note over gNB: 等待SR处理 + CCE分配
gNB->>UE: DCI Format 0_1 (UL Grant)
Note over UE: PDCCH解码 (~0.5ms)
UE->>gNB: PUSCH (数据)
Note over UE,gNB: 单次调度延迟: 3~5ms
```
对VoNR而言，语音帧每20ms产生一次，如果每次都要走SR→DCI→PUSCH三步链路，PDCCH开销占用的CCE资源在小区内大量VoNR用户场景下会迅速耗尽盲检预算。对URLLC场景更是如此——工业控制要求端到端时延<1ms，三步链路根本不可接受。
### 1.2 免调度的核心思想
SPS/CG的本质是**"一次配置，周期复用"**：
| 维度 | 动态调度 | SPS/CG免调度 |
|------|---------|-------------|
| 控制信令 | 每次传输需DCI | 仅配置/激活时需DCI |
| PDCCH开销 | O(N×M) (N用户×M周期) | O(N) (仅配置) |
| 调度时延 | 3~5ms | 0ms (资源已预分配) |
| 灵活性 | 最高 | 受周期性约束 |
| 适用场景 | 突发数据 | 周期性数据(VoNR/URLLC) |
TS 38.321 Section 5.8定义了三种免调度机制：
| 机制 | 方向 | 激活方式 | 规范章节 |
|------|------|---------|---------|
| **SPS** | 下行(DL) | RRC配置 + DCI激活(CS-RNTI) | TS 38.321 §5.1.2 |
| **CG Type 1** | 上行(UL) | 仅RRC配置 | TS 38.321 §5.8.2 |
| **CG Type 2** | 上行(UL) | RRC配置 + DCI激活(CS-RNTI) | TS 38.321 §5.8.3 |
---
## 二、下行SPS：从RRC配置到周期性PDSCH的完整链路
### 2.1 SPS配置与激活信令流
```mermaid
sequenceDiagram
participant gNB
participant UE
Note over gNB,UE: Step 1: RRC配置SPS参数
gNB->>UE: RRCReconfiguration
(SPS-Config IE)
Note right of UE: sps-ConfigIndex=1
nrofHARQ-Processes=8
periodicity=20 slots
n1PUCCH-AN=PUCCH资源ID
Note over gNB,UE: Step 2: DCI激活SPS
gNB->>UE: DCI Format 1_1 (CS-RNTI加扰)
Note right of UE: 携带初始频域/时域资源
MCS、HARQ进程号
PDSCH-to-HARQ时序
UE->>gNB: HARQ-ACK (PUCCH)
Note over gNB,UE: Step 3: 周期性PDSCH传输
loop 每 periodicity 个时隙
gNB->>UE: PDSCH (无DCI调度)
UE->>gNB: HARQ-ACK/NACK (PUCCH)
end
Note over gNB,UE: Step 4: SPS释放
gNB->>UE: DCI Format 1_1 (CS-RNTI, 释放指示)
Note right of UE: FDRA=全1, MCS=0,
TB size=0指示释放
UE->>gNB: HARQ-ACK (确认释放)
```
### 2.2 SPS关键参数解析
SPS配置通过`SPS-Config` IE(TS 38.331 Section 6.3.2)传递，核心参数如下：
| 参数 | 含义 | 典型值(VoNR) | 说明 |
|------|------|-------------|------|
| `sps-ConfigIndex` | SPS配置索引 | 0~15 | 标识第几套SPS配置 |
| `nrofHARQ-Processes` | HARQ进程数 | 8 | 用于SPS的HARQ进程池 |
| `periodicity` | SPS周期 | 20 slots (30kHz SCS) | 对应20ms语音帧间隔 |
| `mcs-Table` | MCS表选择 | qam64LowSE | VoNR用低频效MCS表 |
| `n1PUCCH-AN` | SPS释放HARQ-ACK的PUCCH资源 | 资源ID | 仅用于释放确认 |
| `harq-ProcID-Offset` | HARQ进程号偏移 | 0 | 避免与动态调度冲突 |
| `maxHarqProcessNum` | 最大HARQ进程数 | 8 | 与nrofHARQ-Processes关联 |
**SPS激活DCI的特殊性**：DCI Format 1_1用CS-RNTI(Configured Scheduling RNTI)加扰，而非C-RNTI。UE通过RNTI类型识别这是SPS激活而非动态调度。激活DCI中携带的频域资源分配、MCS、PDSCH-to-HARQ反馈时序等参数，将作为后续所有SPS PDSCH传输的模板。
### 2.3 SPS HARQ进程号的确定
SPS的HARQ进程号不需要DCI显式指示，UE通过公式计算(TS 38.321 Section 5.1.2)：
```
HARQ_Process_ID =
[ (SFN × numberOfSlotsPerFrame × numberOfSymbolsPerSlot
+ slot number in the frame × numberOfSymbolsPerSlot
+ symbol number in the slot)
/ periodicity ]
mod nrofHARQ-Processes
```
对于30kHz子载波间隔(每帧20个slot)，20ms周期对应40个slot：
- `periodicity = 40 slots`
- `nrofHARQ-Processes = 8`
- SFN=0, slot=0时：HARQ PID = 0
- SFN=0, slot=40时：HARQ PID = 0 (回到起始)
- SFN=0, slot=8时：HARQ PID = 1
这种确定性映射确保UE和gNB对每个SPS时机的HARQ进程号理解一致，无需额外信令。
### 2.4 SPS释放检测：DCI中的"暗号"
SPS释放通过DCI Format 1_1(CS-RNTI加扰)指示，UE通过以下字段的特定值判断这是释放而非激活(TS 38.214 Section 5.1.2)：
| DCI字段 | 释放指示值 | 说明 |
|---------|----------|------|
| Frequency domain resource assignment | 全1 | 表示无资源分配 |
| Time domain resource assignment | 0 | 固定为0 |
| MCS | 0 (索引) | MCS=0 |
| TB scaling | 0 | 无TB |
| RV | 0 | 冗余版本=0 |
| NDI | 0 (toggle) | 新数据指示 |
| HARQ process number | 0 | 固定 |
| PUCCH resource indicator | 0 | |
| Antenna ports | 0 | |
| DM-RS sequence initialization | 0 | |
**这个设计的精妙之处**：用"全零"状态表示释放，而非引入额外1 bit显式指示。在PDCCH资源紧张的NR系统中，每一个bit都弥足珍贵。
---
## 三、上行CG Type 1：纯RRC驱动的零开销快车道
### 3.1 CG Type 1完整配置流程
```mermaid
sequenceDiagram
participant gNB
participant UE
Note over gNB,UE: Step 1: RRC完整配置
gNB->>UE: RRCReconfiguration
(ConfiguredGrantConfig IE)
Note right of UE: rrc-ConfiguredUplinkGrant包含:
periodicity=20 slots
timeDomainOffset=5
timeDomainAllocation=idx
frequencyDomainAllocation=RB bitmap
mcsAndTBS=固定MCS
antennaPort, dmrs配置
UE->>gNB: RRCReconfigurationComplete
Note over UE: RRC配置完成后立即生效
Note over UE: 无需DCI激活!
Note over gNB,UE: Step 2: 周期性免调度传输
loop 每 periodicity 个时隙
UE->>gNB: PUSCH (无SR/DCI)
gNB->>UE: PHICH/PDCCH (HARQ反馈)
end
Note over gNB,UE: Step 3: 去配置(仅RRC)
gNB->>UE: RRCReconfiguration (释放ConfiguredGrantConfig)
```
### 3.2 CG Type 1的RRC参数全景
CG Type 1通过`rrc-ConfiguredUplinkGrant` IE一次性传递所有传输参数(TS 38.331 Section 6.3.2)：
| 参数 | 含义 | 作用 |
|------|------|------|
| `periodicity` | 授权周期 | 控制传输频率 |
| `timeDomainOffset` | 时域偏移 | 相对于SFN=0的起始偏移 |
| `timeDomainAllocation` | 时域资源分配 | 对应TS 38.214 Table 6.1.2.1.1 |
| `frequencyDomainAllocation` | 频域资源分配 | RB位图 |
| `mcsAndTBS` | 固定MCS/TBS | 所有传输使用相同MCS |
| `antennaPort` | 天线端口 | DM-RS端口 |
| `dmrs-SeqGeneration` | DM-RS序列初始化 | |
| `frequencyHopping` | 跳频配置 | |
| `pathlossReferenceIndex` | 路损参考信号索引 | 功控参考 |
| `precodingAndNumberOfLayers` | 预编码和层数 | MIMO配置 |
| `srs-ResourceIndicator` | SRS资源指示 | 用于功控和波束 |
| `mcs-Table` | MCS表选择 | |
| `transformPrecoder` | 变换预编码使能 | DFT-s-OFDM开关 |
### 3.3 CG Type 1的起始SFN计算
UE收到RRC配置后，需要确定第一个CG传输时机的SFN。计算方法(TS 38.321 Section 5.8.2)：
```
SFN_offset = timeDomainOffset mod 1024
起始SFN = timeDomainOffset / 1024 (整数部分)
```
当 `SFN mod (periodicity / numberOfSlotsPerFrame) == SFN_offset / numberOfSlotsPerFrame` 时，UE在对应slot发送PUSCH。
**设计意图**：`timeDomainOffset`允许gNB精确控制CG Type 1的起始时间，实现小区内多UE的CG时机错开，避免PUSCH碰撞导致的干扰集中。
---
## 四、上行CG Type 2：DCI激活的灵活中间态
### 4.1 CG Type 2两阶段配置与MAC CE确认
```mermaid
sequenceDiagram
participant gNB
participant UE
Note over gNB,UE: Step 1: RRC模板配置
gNB->>UE: RRCReconfiguration
(ConfiguredGrantConfig, 无rrc-ConfiguredUplinkGrant)
Note right of UE: 仅配置: periodicity,
nrofHARQ-Processes,
harq-ProcID-Offset等
不包含时频资源!
UE->>gNB: RRCReconfigurationComplete
Note over gNB,UE: Step 2: DCI激活
gNB->>UE: DCI Format 0_0/0_1 (CS-RNTI加扰)
Note right of UE: 携带: 频域资源,
时域资源, MCS,
DM-RS等参数
Note over UE: UE应用DCI中的参数
Note over UE: 生成Configured Grant Confirmation MAC CE
UE->>gNB: PUSCH + MAC CE (CG Confirmation)
Note right of gNB: LCID = 55
1字节: CG ID (4bit) + R (4bit)
Note over gNB: 收到MAC CE → 激活成功
Note over gNB,UE: Step 3: 周期性传输
loop 每 periodicity 个时隙
UE->>gNB: PUSCH (免调度)
gNB->>UE: HARQ反馈
end
Note over gNB,UE: Step 4: DCI去激活
gNB->>UE: DCI Format 0_0 (CS-RNTI, 全1指示去激活)
UE->>gNB: MAC CE (CG Confirmation)
Note over gNB: 收到MAC CE → 去激活成功
```
### 4.2 MAC CE确认机制的深层博弈
**为什么CG Type 2需要MAC CE确认，而SPS用HARQ-ACK？**
这是上行与下行信令模型的不对称性决定的：
| 维度 | SPS (下行) | CG Type 2 (上行) |
|------|-----------|-----------------|
| 激活方向 | gNB→UE (DL) | gNB→UE (DL) |
| 反馈方向 | UE→gNB (UL) | UE→gNB (UL) |
| 反馈方式 | HARQ-ACK (对DCI本身的确认) | MAC CE (显式确认) |
| 反馈时延 | ~1个slot | ~数个slot |
**SPS场景**：gNB发送DCI激活SPS后，UE在PUCCH上回复HARQ-ACK。这个HARQ-ACK既是对DCI接收的确认，也是对SPS激活的确认——如果UE没收到DCI，自然不会回复ACK，gNB就知道激活失败。
**CG Type 2场景**：gNB发送DCI激活CG后，UE也需要确认。但CG是上行授权——UE在收到DCI后需要**准备上行传输资源**，确认的语义不再是"我收到了DCI"，而是"我已成功配置了上行授权参数"。因此，MAC CE比HARQ-ACK更合适，因为：
1. MAC CE在PUSCH上发送，与后续CG传输共享上行信道
2. MAC CE携带CG-ID，精确指示确认的是哪套CG配置
3. MAC CE的可靠性高于HARQ-ACK(有RLC ARQ保护)
**Configured Grant Confirmation MAC CE格式**(TS 38.321 Section 6.1.3.7)：
```
| CG ID (4 bits) | R (4 bits) |
| 0xxx | 0000 |
```
- LCID = 55 (标识这是CG确认MAC CE)
- CG ID: 4 bits，标识确认的是第几套CG配置(0~15)
- R: 保留位，设为0
### 4.3 CG Type 2去激活的DCI检测
与SPS释放类似，CG Type 2去激活通过DCI Format 0_0(CS-RNTI)的特定字段值指示：
| DCI字段 | 去激活指示值 |
|---------|-----------|
| Frequency domain resource assignment | 全1 |
| Time domain resource assignment | 0 |
| MCS | 0 |
| NDI | 0 |
| RV | 0 |
| HARQ process number | 0 |
---
## 五、三种机制的状态转换全景
```mermaid
stateDiagram-v2
[*] --> 未配置: RRC未配置
未配置 --> RRC已配置: RRCReconfiguration
(SPS-Config / ConfiguredGrantConfig)
state "RRC已配置" as configured
configured --> CG1_激活: CG Type 1
(RRC完成后自动激活)
configured --> CG2_待激活: CG Type 2
(等待DCI)
configured --> SPS_待激活: SPS
(等待DCI)
CG2_待激活 --> CG2_激活: DCI (CS-RNTI) 激活
CG2_待激活 --> 未配置: RRC释放
SPS_待激活 --> SPS_激活: DCI (CS-RNTI) 激活
SPS_待激活 --> 未配置: RRC释放
CG1_激活 --> 未配置: RRC释放
(唯一释放路径)
CG2_激活 --> CG2_待激活: DCI (CS-RNTI) 去激活
+ MAC CE确认
CG2_激活 --> 未配置: RRC释放
SPS_激活 --> SPS_待激活: DCI (CS-RNTI) 释放
+ HARQ-ACK确认
SPS_激活 --> 未配置: RRC释放
```
---
## 六、运营商成本博弈：三种机制的选型决策
### 6.1 场景-机制匹配矩阵
| 业务场景 | 周期 | 包大小 | 推荐机制 | 理由 |
|---------|------|-------|---------|------|
| VoNR语音 | 20ms | 40~200 bytes | SPS(DL) + CG Type 2(UL) | 固定周期，需要灵活激活/去激活 |
| URLLC工业控制 | <1ms | 小包 | CG Type 1 | 极低时延，RRC一次配置永不再等 |
| 视频监控上行 | 33/66ms | 可变 | CG Type 2 | 周期不固定时需DCI重激活 |
| IoT小包上报 | 秒级 | 极小 | CG Type 1 | RRC-only，零PDCCH开销 |
| AR/VR下行 | 11ms | 大包 | SPS | 固定帧率下行推送 |
### 6.2 PDCCH资源节省的量化分析
以一个典型VoNR小区(50个VoNR用户)为例：
| 调度方式 | 每秒DCI数量 | CCE消耗/秒 | PDCCH利用率 |
|---------|-----------|-----------|------------|
| 全动态调度 | 50×50=2500 | 2500×2=5000 | ~83% |
| SPS+CG Type 2 | 50×2=100(仅激活) | 100×2=200 | ~3.3% |
| SPS+CG Type 1 | 50×1=50(仅SPS激活) | 50×2=100 | ~1.7% |
**关键发现**：VoNR场景下，SPS+CG可以将PDCCH利用率从83%降至3.3%以下，释放出的CCE资源可用于eMBB动态调度。这就是为什么VoNR商用网络必须开启SPS/CG——不开则PDCCH成为容量瓶颈。
### 6.3 灵活性-开销的帕累托前沿
```
灵活性 ↑
│ 动态调度
│ ★
│
│ CG Type 2 / SPS
│ ★
│
│ CG Type 1
│ ★
└───────────────────────→ 控制面开销
```
- **CG Type 1**：开销最低(零PDCCH)，但灵活性最差(RRC修改才能调参数)
- **CG Type 2 / SPS**：中等开销(DCI激活/去激活)，中等灵活性
- **动态调度**：开销最高，灵活性最大
---
## 七、HARQ进程管理：免调度的隐藏复杂性
### 7.1 HARQ进程号冲突与规避
免调度机制最易忽略的问题是**HARQ进程号冲突**。CG Type 1的HARQ进程号由公式计算，而动态调度的HARQ进程号由DCI显式指示。如果两者使用了重叠的HARQ进程号空间，就会出现一个进程同时被CG和动态调度使用的冲突。
**解决方案**：TS 38.321引入`harq-ProcID-Offset`参数，将CG的HARQ进程号空间与动态调度空间错开：
```
CG HARQ PID范围: [harq-ProcID-Offset, harq-ProcID-Offset + nrofHARQ-Processes - 1]
动态调度 HARQ PID范围: [0, 15] 中除CG占用的部分
```
**实战建议**：配置CG时必须规划HARQ进程号空间。典型配置：
- CG: harq-ProcID-Offset=8, nrofHARQ-Processes=8 → 使用PID 8~15
- 动态调度: 使用PID 0~7
- SPS: 独立配置harq-ProcID-Offset，避免三方冲突
### 7.2 configuredGrantTimer与HARQ进程保护
TS 38.321引入`configuredGrantTimer`定时器，保护CG的HARQ进程：
- UE在某个HARQ进程上发起CG传输后，启动该进程的`configuredGrantTimer`
- 定时器运行期间，该HARQ进程**不能被动态调度使用**
- 定时器超时后，进程归还给动态调度池
- gNB可以在定时器运行期间通过DCI对该进程进行重传调度
**博弈点**：`configuredGrantTimer`设置过短→HARQ进程过早归还→CG重传机会丢失。设置过长→动态调度可用进程减少→eMBB性能下降。典型值：8~16个slot。
### 7.3 CG Type 1重传的困境
CG Type 1只能用于**初始传输**，重传必须通过动态调度(TS 38.321 Section 5.8.2)。这意味着：
```mermaid
sequenceDiagram
participant UE
participant gNB
Note over UE: CG Type 1时机到达
UE->>gNB: PUSCH (CG初始传输, HARQ PID=8)
gNB->>UE: HARQ NACK (PHICH/PDCCH)
Note over UE: 等待gNB分配动态重传资源
gNB->>UE: DCI Format 0_0 (C-RNTI, 重传调度)
Note right of UE: 指定相同的HARQ PID=8
新频域/时域资源
UE->>gNB: PUSCH (动态重传)
gNB->>UE: HARQ ACK
```
**这就是CG Type 2比CG Type 1更实用的原因之一**——CG Type 2在激活DCI中指定的参数可以作为重传模板，gNB有更多控制权。
---
## 八、抓包识别与故障排查
### 8.1 抓包特征识别
| 机制 | Wireshark过滤 | 关键特征 |
|------|-------------|---------|
| SPS激活 | `rrc.sps_Config` + `dcit.type == 1_1 && rnti == CS-RNTI` | RRC配置后首个CS-RNTI DCI |
| CG Type 1 | `rrc.ConfiguredGrantConfig && rrc.rrc_ConfiguredUplinkGrant` | 含`rrc-ConfiguredUplinkGrant` |
| CG Type 2 | `rrc.ConfiguredGrantConfig && !rrc.rrc_ConfiguredUplinkGrant` | 无`rrc-ConfiguredUplinkGrant` |
| CG激活确认 | `mac.ce_lcid == 55` | MAC CE LCID=55 |
| SPS释放 | CS-RNTI DCI中FDRA=全1, MCS=0 | 特殊DCI字段组合 |
### 8.2 常见故障点
**故障1：CG Type 1配置后UE不发送PUSCH**
排查路径：
1. 检查`timeDomainOffset`是否正确 → UE可能算错起始SFN
2. 检查`pathlossReferenceIndex`对应的RS是否配置 → 功控失效导致UE不发
3. 检查`configuredGrantTimer`是否过短 → 进程冲突
4. 检查UE是否有上行TA(Time Alignment) → TA失效导致UE被barred
**故障2：SPS PDSCH被UE漏收**
排查路径：
1. 检查SPS激活DCI是否被UE正确解码(CS-RNTI加扰)
2. 检查SPS PDSCH的DM-RS配置是否与激活DCI一致
3. 检查HARQ进程号是否与动态调度冲突
4. 检查PUCCH资源是否足够承载SPS的HARQ-ACK
**故障3：CG Type 2 MAC CE未收到**
排查路径：
1. UE可能在CG激活DCI中没有正确识别CS-RNTI(检查RNTI配置)
2. MAC CE可能因UL grant不足无法发送(检查BSR和UL资源)
3. 检查MAC CE的LCID是否正确(应为55)
4. 如果gNB未收到MAC CE，会重发激活DCI
## 九、Rel-18/19增强：Multi-PUSCH CG与SPS多配置
3GPP Rel-18对CG/SPS引入了重要增强：
### 9.1 Multiple CG配置(TS 38.321 Rel-18)
- 单UE最多配置**12套CG配置**(通过`cg-ConfigIndex` 0~11区分)
- 每套CG配置独立周期、独立HARQ进程池
- 允许同一UE同时为VoNR(CG周期20ms)和URLLC(CG周期0.5ms)配置不同CG
### 9.2 SPS Multi-Configuration(TS 38.321 Rel-18)
- 单UE最多配置**8套SPS配置**(通过`sps-ConfigIndex` 0~7区分)
- 可同时支持不同QoS等级的DL业务
### 9.3 CG-UCI(Uplink Control Information on CG PUSCH)
Rel-18引入CG-UCI，允许UE在CG PUSCH中携带控制信息：
- HARQ-ACK反馈
- BSR
- 功率余量报告(PHR)
这使得CG Type 1的UE不需要额外的PUCCH传输控制信息，进一步降低开销。
---
## 常见问题
**Q1: CG Type 1和CG Type 2在RRC配置上的核心区别是什么？**
A: 核心区别在于`rrc-ConfiguredUplinkGrant`字段的有无。CG Type 1的RRC配置中包含此字段，一次性提供所有传输参数(时频资源、MCS、DM-RS等)，配置完即生效。CG Type 2的RRC配置中**不含**此字段，仅提供周期和HARQ相关参数，具体的时频资源由后续DCI(CS-RNTI加扰)激活时提供。
**Q2: 为什么SPS用HARQ-ACK确认激活，而CG Type 2用MAC CE？**
A: 因为SPS是下行机制，gNB发DCI激活后发PDSCH，UE天然会对PDSCH回复HARQ-ACK，这个ACK同时确认了DCI的接收。CG Type 2是上行机制，gNB发DCI激活后，UE需要显式确认"我已经准备好上行传输配置了"，HARQ-ACK只表示"DCI收到了"，MAC CE才表示"配置已应用"。另外MAC CE走PUSCH，有RLC ARQ保护，可靠性更高。
**Q3: 一个UE能同时使用SPS和CG吗？**
A: 可以。典型VoNR场景就是SPS(DL语音) + CG Type 2(UL语音)同时配置。SPS和CG有独立的HARQ进程池(通过不同的harq-ProcID-Offset隔离)。Rel-18后更支持同一方向多套配置并行。
**Q4: CG Type 1重传如何处理？**
A: TS 38.321明确规定CG Type 1仅用于初始传输。如果gNB解码失败(NACK)，必须通过DCI(C-RNTI加扰)分配动态授权进行重传，使用相同的HARQ进程号。这是CG Type 1灵活性不足的主要体现——重传依赖gNB的动态调度响应速度。
**Q5: SPS/CG的periodicity有哪些可选值？**
A: TS 38.321定义了丰富的周期选项，从极短的2 symbols到极长的640 slots。30kHz SCS下常用值：10/20/40/80/160/320 slots，分别对应5/10/20/40/80/160ms。URLLC场景可配置更短周期(如4/8 slots)，IoT场景可配置更长周期。
---
## 参考来源
1. [3GPP TS 38.321 V18.x.x — NR MAC Protocol Specification](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3194) — Sections 5.1.2 (SPS), 5.8.2 (CG Type 1), 5.8.3 (CG Type 2), 6.1.3.7 (CG Confirmation MAC CE)
2. [3GPP TS 38.331 V18.x.x — NR RRC Protocol Specification](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3197) — ConfiguredGrantConfig IE, SPS-Config IE
3. [ShareTechnote — NR Configured Scheduling](https://www.sharetechnote.com/html/5G/5G_ConfiguredScheduling.html) — CG Type 1/2和SPS的可视化流程图
4. [Amarisoft Tech Academy — NR CG (Configured Grant)](https://tech-academy.amarisoft.com/NR_CG.html) — CG机制配置参数和实战分析
5. [ETSI TS 138 321 V17.12.0](https://cdn.standards.iteh.ai/samples/74776/b042d5fcc2f3480d97835a44feca8abd/ETSI-TS-138-321-V17-12-0-2025-04-.pdf) — Release 17正式版MAC层规范
---
> 本文由「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 等场景全覆盖。
