5G小数据传输（SDT）机制深度拆解：RRC_INACTIVE态的RA-SDT与CG-SDT信令全链

一、设计动机：为什么需要SDT

在传统的5G NR网络中，一个处于RRC_INACTIVE状态的终端（UE）若要发送哪怕一个几十字节的业务数据包，都必须经历完整的连接恢复流程：上行数据到达缓冲区 → 触发RRC Resume Request → gNB向"上一个服务gNB"检索UE上下文（Retrieve UE Context）→ 恢复SRB1与若干DRB → 用户面数据传输 → 业务结束 → 网络下发RRC Release（带Suspend Config）将UE重新挂起回RRC_INACTIVE。

对于手机等"人通信"终端，这个开销相对于其传输的MB级、GB级业务流量可以忽略。但对于物联网（IoT）场景——温度传感器、智能水表、资产追踪器、可穿戴设备——情况完全不同：它们频繁地（周期性或偶发性）发送极小的数据包。此时控制面信令的字节数往往数十倍于实际payload。3GPP在Rel-17的工作组讨论中明确指出："As the payload data from an IoT device can be relatively small compared to the control signalling required to send it over the radio interface, making a connection for the small data transmission becomes a concern for both the network and the device"。

SDT（Small Data Transmission，小数据传输）正是为此而生：允许UE在不离开RRC_INACTIVE状态的前提下，并行地发送/接收RRC信令与小数据payload。其本质是把"RRC Resume Request请求"与"用户面首包数据"捆绑在同一次传输机会中一并发送，从而省去"先恢复连接、再传数据"的多轮往返。

SDT在Rel-17（RP-210834等Work Item，由ZTE等主导）正式引入，Rel-18进一步增强了MT-SDT（网络侧触发的下行小数据）、Multiple Data Grants、与RedCap的结合等。本文聚焦TS 38.300/38.331/38.321/38.213中所定义的核心机制与完整信令链。

二、SDT的触发判定：UE侧的"四道闸门"

SDT并非无脑触发。UE在RRC_INACTIVE状态下，上行数据到达后，必须依次通过四个判定条件（定义于TS 38.331的sdt-Config与TS 38.321的MAC判定逻辑），任何一道不过，则回退到传统的RRC Resume或保持空闲：

1. 数据量阈值（Data Volume）：所有"SDT-enabled"无线承载（SRB1及被允许做SDT的DRB）上的待传上行数据总量，必须小于网络配置的ul-DataPDUSize（或称data volume threshold）。一旦超限，说明这次不是"小数据"，直接走正常Resume。
2. RSRP阈值：终端测量的SSB参考信号接收功率必须高于rsrp-ThresholdSSB-SUTC，以保证上行传输质量足够好，避免在边缘覆盖下发起注定失败的SDT。
3. TA有效性（Time Alignment）：终端存储的Timing Advance必须有效，即timeAlignmentTimer未超时。这是CG-SDT的硬性前提——没有有效的TA，预配置授权资源就发不出正确同步的上行。
4. 承载级授权：每个DRB通过sdt-Config中的sdt-allowed逐个配置是否允许做SDT。并非所有业务都适合SDT（例如对时延/可靠性要求极高的URLLC流通常排除）。

这四道闸门的判定流程如下：

flowchart TD
    A[RRC_INACTIVE状态, UL数据到达] --> B{所有SDT-enabled RB<br/>待传数据量 < ul-DataPDUSize?}
    B -- 否 --> Z[回退: 传统RRC Resume流程]
    B -- 是 --> C{测量RSRP ><br/> rsrp-ThresholdSSB?}
    C -- 否 --> Z
    C -- 是 --> D{TA有效?<br/> timeAlignmentTimer未超时}
    D -- 否 --> E{CG-SDT配置且有效?}
    D -- 是 --> E
    E -- 是, 且CG-SDT配置存在 --> F[选择CG-SDT]
    E -- 否 --> G{RA-SDT配置且有效?}
    G -- 是 --> H[选择RA-SDT<br/>4步或2步]
    G -- 否 --> Z
    F --> I[发起SDT传输]
    H --> I
    I --> J{gNB判断是否可继续SDT?}
    J -- 是 --> K[RRC Release带Suspend<br/>回RRC_INACTIVE]
    J -- 否 --> Z

设计意图非常清晰：SDT是"锦上添花"而非"雪中送炭"。它只在终端覆盖好、数据小、TA准、网络允许的"理想窗口"内生效；任何一项不满足，都安全地回退到久经考验的传统流程，保证可靠性不被牺牲。

三、RA-SDT：基于随机接入的小数据传输

3.1 资源隔离——SDT专用前导码

RA-SDT复用4步或2步随机接入过程，但关键差异在于前导码资源池的隔离。gNB在系统消息（SIB1）中通过prach-ConfigIndex、msgA-ConfigCommon下的smallData-r17指示，以及featureCombinationPreambleList，为SDT终端划分出专用的前导码子集（dedicated SDT preambles）。3GPP官方说明明确："the RA radio resources for SDT and non SDT devices are kept separate; that is, these device types do not interfere with each other in random access"。

这样设计的目的有二：其一，gNB在MSG1/MSGA阶段就能通过前导码所属子集提前识别这是一个SDT接入，从而预判后续要按SDT流程处理；其二，避免海量IoT设备的SDT接入与普通终端的初始接入抢占同一前导码池，造成前导码冲突风暴。

3.2 4步RA-SDT信令时序

sequenceDiagram
    participant UE as UE (RRC_INACTIVE)
    participant gNB as Serving gNB
    participant lgNB as Last Serving gNB
    UE->>gNB: MSG1: SDT专用Preamble (PRACH)
    Note over UE,gNB: gNB识别为SDT接入
    gNB->>UE: MSG2: RAR (TC-RNTI + UL Grant)
    UE->>gNB: MSG3: RRCResumeRequest + UL SDT数据 (PUSCH)
    Note right of UE: 39-bit I-RNTI, resumeMAC-I, resumeCause
    gNB->>lgNB: XnAP: Retrieve UE Context Request (I-RNTI)
    lgNB->>gNB: XnAP: Retrieve UE Context Response (DRB/SRB1配置, 安全上下文)
    gNB->>UE: MSG4: 竞争解决 (Contention Resolution Identity)
    Note over UE: TA已确认, SDT会话建立
    gNB->>UE: (可选) DL SDT数据
    gNB->>UE: RRC Release (Suspend Config)
    Note over UE: 回到RRC_INACTIVE

4步RA-SDT的精髓在MSG3：它不仅携带RRC层的RRCResumeRequest消息，还同时捎带（piggyback）了DRB上的上行小数据。这与传统Resume"MSG3只发信令、等连接恢复后才发数据"形成鲜明对比。3GPP描述道："The IoT device initiates the SDT procedure by transmitting an RRC request message and payload data in parallel"。

MSG4完成竞争解决后，TA被网络确认有效，SDT会话正式建立。此后可有零或多轮上下行小数据交互，最终以一条带Suspend Config的RRC Release收尾，UE重回RRC_INACTIVE——全程未进入RRC_CONNECTED。

3.3 2步RA-SDT

2步RA-SDT更进一步：在MSGA（即MSG1+MSG3合并）中，UE一次性发出preamble + PUSCH payload（含RRCResumeRequest + UL SDT数据）。MSGB（MSG2+MSG4合并）回送成功指示与竞争解决。当覆盖良好、冲突概率低时，2步RA-SDT能比4步再省去一个往返，进一步压低时延与功耗。是否启用2步由gNB在SIB1的msgA-ConfigCommon中配置（含smallData-r17标记）。

四、CG-SDT：基于配置授权的小数据传输

CG-SDT是SDT的"无冲突、零信令"版本。当UE因业务周期性而进入RRC_INACTIVE时，网络在其RRC Release（Suspend）消息中预先配置一份Configured Grant Type 1的上行资源（周期、时频位置、MCS等全部预定义）。后续UE只要有小数据，无需任何随机接入，直接在该预配置PUSCH资源上发送RRCResumeRequest + UL数据。

sequenceDiagram
    participant UE as UE (RRC_INACTIVE, 已配置CG-SDT)
    participant gNB as Serving gNB
    participant lgNB as Last Serving gNB
    Note over UE: UL数据到达, 满足SDT四闸门<br/>且CG-SDT资源有效
    UE->>gNB: CG-PUSCH: RRCResumeRequest + UL SDT数据 (无RA)
    Note right of UE: 在预配置授权资源上直发
    gNB->>lgNB: XnAP: Retrieve UE Context Request
    lgNB->>gNB: XnAP: Retrieve UE Context Response
    Note over gNB: 校验resumeMAC-I, 恢复承载
    gNB->>UE: (可选) DL SDT数据 + RRC Release (Suspend)
    Note over UE: 回到RRC_INACTIVE, 等待下一CG周期

CG-SDT的三个突出优势：

• 零冲突：资源为每个UE专用，不存在前导码碰撞，3GPP明确"With CG-SDT there will be no message clashes with other IoT devices"。
• 零接入信令：省去整个RACH过程，时延最低。
• 周期友好：天然契合"每N分钟上报一次"的传感器流量模型。

但其代价是严格依赖TA有效性。CG-SDT不发起RA，网络无法借机校准TA，因此一旦终端移动导致TA漂移，CG-SDT资源即失效，UE须回退到RA-SDT或正常Resume。这也是为何CG-SDT更适合相对静止的IoT终端（如固定安装的水表），而RA-SDT更适合移动性较高的可穿戴设备。

值得注意的是UE的SDT类型选择逻辑（TS 38.331）：若所选上行载波上CG-SDT资源已配置且有效，优先选CG-SDT；否则若RA-SDT配置有效则选RA-SDT；若都不满足，则走非SDT的普通Resume。这一优先级确保"在能省的地方尽量省"。

五、关键Information Element解析

RRCResumeRequest是SDT一切流程的"敲门砖"，其结构定义于TS 38.331 Section 6.2.2。与普通RRCResumeRequest不同，SDT场景下它必须与DRB数据复用，且其完整性保护校验值resumeMAC-I承载着至关重要的安全语义。

classDiagram
    class RRCResumeRequest {
        +rrcResumeRequest_r8: 继承自R8
        +resumeIdentity: 39-bit I-RNTI
        +resumeMAC-I: 16-bit 完整性校验短MAC
        +resumeCause: 恢复原因(traffic/emergency等)
    }
    class sdt_Config_r17 {
        +sdt-Bearer: SRB1/DRB指示
        +ul-DataPDUSize: UL数据量阈值(bytes)
        +rsrp-ThresholdSSB: RSRP门限
        +cg-SDT: CG-SDT资源配置
        +ra-SDT: RA-SDT指示
    }
    class cg_SDT_Config {
        +cg-MinTimer: CG-SDT最小周期计时器
        +cg-SDT-TimeAlignmentTimer: 专用TA定时器
        +configuredGrantConfig: 时频资源配置
    }
    RRCResumeRequest --> sdt_Config_r17 : 配套
    sdt_Config_r17 --> cg_SDT_Config : 包含

resumeMAC-I的安全性尤其值得强调：它让gNB即便尚未检索到完整安全上下文，也能在MSG3/MSGA/CG-PUSCH阶段就初步验证终端身份合法性，防止伪造的SDT请求对网络形成信令风暴攻击。这是SDT在"省信令"与"保安全"之间取得平衡的关键一笔。

六、网络侧核心动作：Retrieve UE Context

无论是RA-SDT还是CG-SDT，gNB在收到携带I-RNTI的首包后，第一件要事都是向"上一个服务gNB"检索UE上下文。因为当前gNB本地并没有这个INACTIVE态UE的任何DRB配置、安全密钥或PDCP状态——这些都被缓存在UE进入INACTIVE前的那个gNB上。

这一步通过Xn接口的Retrieve UE Context Request/Response消息完成。当前gNB用I-RNTI寻址，上个gNB回送完整的承载配置（含PDCP suspend状态、ROHC参数）、安全上下文（keNB*及下一跳参数）、以及UE能力等。拿到上下文后，当前gNB才能恢复SRB1、重新激活SDT-allowed的DRB，并校验resumeMAC-I。

这一机制意味着SDT天然支持RNA（RAN Notification Area）内的移动性：UE在RNA内移动到新的gNB覆盖下，仍能通过SDT + Retrieve UE Context无缝收发小数据，无需回到核心网做完整注册或切换。这与SSC、AMF重分配等核心网流程是互补的两层移动性管理。

七、三种方案的横向对比

可以看到，三者构成一条"时延/信令递减、但对终端条件要求递增"的梯度谱系。网络的聪明之处在于：用Suspend Config中的sdt-Config + 系统消息广播，让终端自动在三者间择优，而非一刀切。

八、RRC状态机中的SDT位置

stateDiagram-v2
    [*] --> RRC_IDLE: 开机
    RRC_IDLE --> RRC_CONNECTED: 初始接入/RRC Setup
    RRC_CONNECTED --> RRC_INACTIVE: RRC Release(Suspend)
    RRC_INACTIVE --> RRC_CONNECTED: 传统Resume / SDT回退
    RRC_INACTIVE --> SDT_Session: 满足四闸门\nRA-SDT或CG-SDT
    SDT_Session --> RRC_INACTIVE: RRC Release(Suspend)
    SDT_Session --> RRC_CONNECTED: gNB判定需完整连接\n(fallback to Resume)
    RRC_INACTIVE --> RRC_IDLE: RNA超时/更新失败
    RRC_CONNECTED --> RRC_IDLE: RRC Release(无Suspend)
    note right of SDT_Session
        SDT会话: UE名义上仍处RRC_INACTIVE
        但SRB1/部分DRB被临时恢复
        全程不进入完整RRC_CONNECTED
    end note

SDT会话（SDT_Session）本质上是一个"伪连接"状态：UE在协议栈层面仍被记为RRC_INACTIVE，但SRB1与若干DRB被临时唤醒以完成收发。一旦会话结束，立即Suspend回INACTIVE。这种"借而不占"的设计，正是SDT省电省信令的根本。

九、抓包识别与实战排错

9.1 抓包识别要点

在空口Log（如QXDM、MiHo、amarisoft trace）与Xn接口（Wireshark + ngap/xnap dissector）中，识别一个SDT流程的关键观察点：

1. SIB1广播：检查是否含smallData-r17、featureCombinationPreambleList含smallData、msgA-ConfigCommon带SDT标记。无则本小区不支持SDT，终端只能走正常Resume。
2. PRACH层：MSG1/MSGA使用的前导码index是否落在"SDT专用前导码子集"范围内（由prach-FeatureCombination指示）。
3. MSG3/MSGA payload：是否同时包含rrcResumeRequest（RRC层，可由rrcResumeRequest-r8/rrcResumeRequest1-r8等message type识别）和 DRB的RLC PDU。这是SDT最硬核的识别标志。
4. Xn接口：紧随其后出现Retrieve UE Context Request（携带I-RNTI而非UE NGAP ID），这是SDT触发了gNB间上下文检索。
5. 结局：流程以RRC Release（带suspendConfig）结束，而非完整的RRCResume + 后续RRC Release。

9.2 常见故障与排查思路

Rel-18在SDT基础上做了若干增强，标准研究人员应关注：

• MT-SDT（Mobile Terminated SDT）：允许网络在有下行小数据时（如服务器主动推送的心跳回复），在INACTIVE态直接下发，而不必先寻呼并恢复连接。
• Multiple Data Grants (MDG)：为一次SDT会话预配置多个上行授权，支持连续多个小包的发送，减少单次会话的发起频率。
• 与RedCap、NR sidelink结合：扩展SDT到更多终端形态与通信模式。
• 能耗优化：基于NOMA、更激进的省电调度等学术提案持续影响后续Rel-19/Rel-20演进。

这些增强共同把SDT从"上行单次小包"推向"上下行双向、多包、多场景"的完整小数据通信框架。

十一、设计哲学小结

SDT的精妙之处不在于某一项技术突破，而在于对"控制面开销 vs 用户面payload"这一比例失衡问题的系统性重构：

• 用前导码子集隔离解决"海量IoT冲击随机接入"；
• 用MSG3/CG-PUSCH捎带首包解决"先连接后传数据的多轮往返"；
• 用Retrieve UE Context解决"RNA内移动性下上下文不连续"；
• 用resumeMAC-I短校验解决"省信令时的身份伪造风险"；
• 用四道闸门 + 三级回退解决"省电省信令不能牺牲可靠性"。

它体现的是3GPP面向IoT时代的一种成熟范式：不是发明全新的物联网专用空口，而是在现有NR框架内，通过精细的资源划分、信令合并与状态机扩展，把"重连接"降维成"轻传输"。对协议开发工程师而言，掌握SDT意味着掌握NR在RRC_INACTIVE态下MAC/RLC/RRC三层如何"临时性、受限地"协同工作；对标准研究人员而言，SDT是观察3GPP如何在兼容性与创新性之间平衡的绝佳样本。

常见问题

Q1: SDT和EDT（LTE的Early Data Transmission）是什么关系？ A: EDT是LTE在R13引入的类似机制（在MSG3携带数据），SDT是NR在Rel-17的对应演进。SDT更全面：不仅支持RA-SDT（对应EDT的思路），还新增了CG-SDT（LTE无对应），并扩展到上下行（MT-SDT）。可理解为EDT在5G NR上的"超集"。

Q2: SDT会话期间，UE到底算RRC_INACTIVE还是RRC_CONNECTED？ A: 严格意义上UE的RRC状态仍为RRC_INACTIVE。3GPP官方明确"the UE stays in the RRC inactive state during the whole process"。但底层SRB1和被授权的DRB被临时恢复可用。这是"伪连接"，会话结束立即Suspend，不留下完整连接状态。

Q3: 为什么CG-SDT比RA-SDT省信令但仍要有RA-SDT？ A: 因为CG-SDT强依赖有效的TA，而TA会随终端移动而漂移、定时器超时即失效。移动性较高的终端（可穿戴、随车设备）难以维持有效TA，CG-SDT用不了；此时RA-SDT可通过RA过程重新校准TA，作为兜底。两者是互补而非替代。

Q4: 如果SDT过程中数据量突然变大怎么办？ A: gNB有权判定本次不适合继续SDT。一旦发现待传数据量、下行数据量、或RSRP变化超出SDT适用范围，gNB会回退（fallback）到完整的RRC Resume，将UE转入RRC_CONNECTED用传统方式处理剩余数据。这一回退由gNB在Retrieve UE Context后基于本地策略决策，保证大数据业务不受SDT限制拖累。

Q5: SDT在切片和QoS层面如何处理？ A: SDT在每个DRB粒度通过sdt-allowed配置，因此运营商可以精细地决定哪些切片/QoS流（如mMTC切片的低优先级传感器流）允许SDT，哪些（如URLLC切片的高可靠流）禁用。这使得SDT能与网络切片隔离策略无缝配合，实现"按业务特征差异化启用小数据优化"。

参考来源

1. 3GPP — Small Data Transmission (SDT) Technology Page — 由3GPP MCC Juha Korhonen撰写，权威描述RA-SDT/CG-SDT的设计动机与流程要点。
2. 3GPP TS 38.300 V18.6.0 — NR and NG-RAN Overall Description (Stage-2) — RRC状态与SDT总体描述章节。
3. 3GPP TS 38.331 — NR Radio Resource Control (RRC) — Section 5.3.13 RRC connection resume procedure；Section 6.2.2 RRCResumeRequest message；sdt-Config/cg-SDT-Config定义。
4. Amararisoft Tech Academy — NR SA SDT (Small Data Transmission) — 含RA-SDT(2步RACH)与CG-SDT的gNB配置参数（rsrp_threshold、ul_data_volume_threshold、t319a、cg-SDT等）与抓包验证方法。
5. IEEE — Efficient Handling of Small Data Transmission for RRC Inactive UEs in 5G — 学术视角下SDT信令开销与能耗的量化分析。
6. 3gpp-explorer — RA-SDT / CG-SDT Glossary — SDT两种形态的系统消息广播与前导码特征组合机制解读。

本文由「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 等场景全覆盖。