简介这份资源是面向5G NR协议学习者的3GPP TS 37.324 SDAP协议文档聚焦服务数据适配协议Service Data Adaptation Protocol的架构与流程解析适合无线通信工程师、协议栈开发人员及备考5G认证的读者查阅。压缩包内仅含1个docx文件约242KB内容围绕SDAP子层结构、SDAP实体、上下行数据传输、QoS流到DRB映射及反射QoS映射等核心章节展开并附有QFI、RDI、RQI等关键字段说明。文档从功能视角描述SDAP体系结构涵盖SDAP实体建立与释放、UL/DL SDAP数据PDU构造、末端标记控制PDU处理等过程可帮助读者理解QoS流与DRB之间的映射规则及反射映射机制。目前已有584人学习下载适合需要系统研读协议原文、对照实现细节或查漏补缺的读者参考。1. 3GPP 37.324 里的 SDAP它到底在 5G 协议栈里干什么如果你抓过 5G 空口的数据包大概率见过一层既不像 PDCP 也不像 RLC 的头部——它没有序列号长度还随配置变化这就是 SDAP。3GPP 37.324 这份协议专门定义它而 g20 版本是这套规范里被大量商用终端和基站实现引用的一个基线。SDAP 全称 Service Data Adaptation Protocol直译是「业务数据适配协议」它干的事说白了就一件把核心网下发的 QoS 流QoS Flow映射到空口的 DRBData Radio Bearer上并在下行包上打一个 QFI 标记让接收侧知道这个包属于哪条业务流。为什么 5G 要单独搞这么一层因为 4G 时代 QoS 粒度是承载级的一个 EPS Bearer 对应一套 QoS业务和承载基本一对一。到了 5G核心网把 QoS 粒度细化到 Flow 级同一个 PDU Session 里可以同时跑好几条 QoS Flow每条 Flow 有自己的 5QI、保证速率、优先级。但空口侧如果每条 Flow 都建一个 DRB信令开销和调度复杂度会爆炸。SDAP 就是那个「适配器」它允许把多条 QoS Flow 映射到同一个 DRB 上也可以一条 Flow 独占一个 DRB具体怎么映射由网络配置决定。这份协议适合谁看做 5G 终端协议栈的、做基站 L2 的、做核心网 UPF 与空口联调的还有做卫星通信协议栈的——现在 3GPP 卫星相关协议里SDAP 同样是用户面绕不开的一层。如果你只关心「PDU 会话怎么建」那 37.324 不是第一站但如果你要调 QoS 映射、排查业务流跑错承载、或者实现一个最小可用的 SDAP 实体这份文档就是必读。下面我按「先搞懂结构再动手实现最后踩坑」的顺序拆开讲。2. SDAP 的协议结构PDU 格式、QFI 与映射规则怎么读2.1 SDAP PDU 的两种格式与头部字段37.324 里 SDAP PDU 分两种带 DL SDAP header 的和不带 header 的。上行方向如果网络配置了 UL SDAP header终端发的每个包前面会带一个字节的头部下行方向同理但下行头部多了一个关键字段——QFI。先看下行 SDAP Data PDU 的格式。它由三部分组成1 字节的 SDAP header、可选的 SDAP Control PDU用于映射控制、以及实际的用户数据。头部结构如下字段长度含义D/C1 bitData/Control 指示0 表示控制 PDU1 表示数据 PDUR1 bit保留位发送端置 0接收端忽略QFI6 bitQoS Flow Identifier取值 0-63RDI1 bitReflective QoS Flow to DRB Mapping IndicationRQI1 bitReflective QoS Indication注意 QFI 只有 6 bit所以一个 PDU Session 里最多 64 条 QoS Flow。这个数字在核心网规划时就要卡住不是随便扩的。RDI 和 RQI 是反射式 QoS 用的终端收到下行包后如果 RDI 置 1就按这个包的 QFI 和 DRB 映射关系自动更新上行的映射规则不需要网络再发 RRC 信令。这是 5G 省信令的一个设计但也是坑最多的地方后面避坑章节会细说。上行 SDAP Data PDU 的头部更简单只有 D/C 和 R 两个字段没有 QFI。为什么因为上行方向DRB 和 QoS Flow 的映射关系是网络通过 RRC 配置好的基站收到上行包时根据它从哪个 DRB 上来就能反推 QFI不需要在包里再带。这个设计差异是很多人第一次读协议时容易绕晕的点。2.2 QoS Flow 到 DRB 的映射默认映射与显式信令SDAP 的核心功能是映射。37.324 定义了两种映射方式默认映射和显式映射。默认映射的规则是如果一条 QoS Flow 没有收到任何显式的 DRB 映射配置它就映射到该 PDU Session 的默认 DRB 上。默认 DRB 是 RRC 在建立 PDU Session 时指定的通常就是第一个建立的 DRB。这个机制保证了即使映射配置还没下发业务也不会断。显式映射则通过 RRC 的 SDAP-Config IE 下发里面包含两个关键字段mappedQoS-FlowsToAdd和mappedQoS-FlowsToRelease。前者是一个 QFI 列表告诉终端「这些 QFI 映射到我这个 DRB」后者是「这些 QFI 从我这个 DRB 移除」。注意一个 QFI 在同一时刻只能映射到一个 DRB但一个 DRB 可以承载多个 QFI。反射式映射是第三种也是 5G 特有的。它不需要 RRC 信令而是靠下行包的 RDI 位触发。终端收到 RDI1 的下行包后把该包的 QFI 和它所在的 DRB 的映射关系记下来用于上行发送。这个机制在卫星场景里特别有用因为卫星链路 RTT 大等 RRC 重配下来业务可能已经卡了。2.3 用 Python 解析一个 SDAP 下行 PDU光看表格不够直观写段代码把头部拆开。下面这个函数解析下行 SDAP Data PDU 的头部输入是 bytes输出是字段字典def parse_sdap_dl_header(data: bytes) - dict: 解析下行 SDAP Data PDU 头部1 字节 data: 至少 1 字节的原始数据 返回: 包含各字段的字典 if len(data) 1: raise ValueError(SDAP PDU too short) byte0 data[0] # 按 37.324 定义逐位提取 d_c (byte0 7) 0x01 # bit7: D/C r (byte0 6) 0x01 # bit6: 保留 qfi byte0 0x3F # bit5-0: QFI (6 bits) # 注意RDI/RQI 在部分版本中位于后续字节或复用位 # g20 基线里若配置了反射式 QoS需结合 RRC 配置判断 return { d_c: d_c, r: r, qfi: qfi, is_data: d_c 1, header_len: 1 } # 示例一个下行数据包QFI9 raw bytes([0x89]) # 1000 1001 - D/C1, R0, QFI9 print(parse_sdap_dl_header(raw)) # 输出: {d_c: 1, r: 0, qfi: 9, is_data: True, header_len: 1}这段代码的关键在byte0 0x3F0x3F 是低 6 位掩码正好对应 QFI 的 6 bit。D/C 位在最高位右移 7 位取出。参数说明data必须是完整的 PDU 起始字节如果传入的是已经去掉头部的 payload解析结果会错。实际实现里你还需要根据 RRC 配置判断当前 DRB 是否启用了 DL SDAP header因为 37.324 允许网络配置「无头部」模式这时候第一个字节直接就是用户数据不能按头部解析。提示QFI0 是保留值实际业务从 1 开始分配。如果你解析出 QFI0 且 D/C1大概率是头部解析错位或者配置没对齐。3. 动手实现一个最小 SDAP 实体映射表、QFI 标记与收发流程3.1 映射表的数据结构设计实现 SDAP 实体第一件事是设计映射表。它要支持三个操作按 QFI 查 DRB下行发送用、按 DRB 查 QFI 列表上行接收用、动态增删映射RRC 重配和反射式更新用。我一般用两个字典加一个锁来搞Python 里大概长这样import threading class SdapMappingTable: def __init__(self, default_drb_id: int): self.default_drb_id default_drb_id self._qfi_to_drb {} # QFI - DRB ID self._drb_to_qfis {} # DRB ID - set(QFI) self._lock threading.RLock() def add_mapping(self, qfi: int, drb_id: int): 显式映射把 QFI 绑到 DRB自动处理旧映射 with self._lock: old_drb self._qfi_to_drb.get(qfi) if old_drb drb_id: return if old_drb is not None: self._drb_to_qfis.get(old_drb, set()).discard(qfi) self._qfi_to_drb[qfi] drb_id self._drb_to_qfis.setdefault(drb_id, set()).add(qfi) def remove_mapping(self, qfi: int): 移除显式映射回落到默认 DRB with self._lock: old_drb self._qfi_to_drb.pop(qfi, None) if old_drb is not None: self._drb_to_qfis.get(old_drb, set()).discard(qfi) def get_drb(self, qfi: int) - int: 下行发送QFI 查 DRB未配置则用默认 with self._lock: return self._qfi_to_drb.get(qfi, self.default_drb_id) def get_qfis(self, drb_id: int) - set: 上行接收DRB 查 QFI 集合 with self._lock: return set(self._drb_to_qfis.get(drb_id, set()))这里用RLock而不是普通Lock是因为反射式更新可能在持有锁的路径里再次调用add_mapping普通锁会死锁。remove_mapping不删_drb_to_qfis里的空集合是为了避免频繁创建销毁代价是内存里会留一些空 set实际跑起来量很小可以接受。参数说明default_drb_id必须在初始化时传入且不能为 None。如果网络配置的默认 DRB 后续被释放需要外部逻辑保证至少有一个 DRB 可用否则get_drb会返回一个无效 ID。3.2 下行发送打 QFI 标记并选 DRB下行方向SDAP 从核心网收到的是带 QFI 的包通常来自 GTP-U 的 PDU Session Container它要做两件事根据 QFI 选 DRB然后在包前面加上 SDAP header。def sdap_dl_transmit(qfi: int, payload: bytes, mapping: SdapMappingTable, header_enabled: bool True) - tuple: 下行发送处理 qfi: 核心网标记的 QoS Flow ID payload: 用户数据 header_enabled: 该 DRB 是否配置了 DL SDAP header 返回: (drb_id, 待发送字节流) drb_id mapping.get_drb(qfi) if not header_enabled: # 无头部模式直接透传 return drb_id, payload # 构造 1 字节头部D/C1, R0, QFI 低 6 位 header 0x80 | (qfi 0x3F) return drb_id, bytes([header]) payload关键在0x80 | (qfi 0x3F)0x80 把最高位置 1 表示 Data PDU低 6 位放 QFI。qfi 0x3F是防御性写法防止上层传入超过 63 的 QFI 导致位溢出。实际实现里如果 QFI 超过 63应该直接丢包并上报错误而不是静默截断。header_enabled这个参数必须从 RRC 配置里取不能拍脑袋。37.324 允许每个 DRB 独立配置是否带 DL SDAP header同一个 UE 的不同 DRB 可以一个带一个不带。我见过有实现图省事全局开头部结果跟某些核心网对接时包全被丢了因为对方按无头部解析第一个字节被当成了用户数据。3.3 上行接收从 DRB 反推 QFI 并做反射式更新上行方向SDAP 从 RLC 收到包根据它来自哪个 DRB查映射表得到 QFI 集合。如果集合里只有一个 QFI直接标记如果有多个就需要靠反射式映射或者更细的规则来区分——这也是为什么很多实现建议一个 DRB 只映射一条 QFI省得猜。def sdap_ul_receive(drb_id: int, payload: bytes, mapping: SdapMappingTable, reflective_enabled: bool False) - tuple: 上行接收处理 返回: (qfi, 用户数据) qfis mapping.get_qfis(drb_id) if len(qfis) 1: qfi next(iter(qfis)) elif len(qfis) 0: # 没有显式映射用默认 DRB 对应的 QFI通常由 RRC 指定 qfi 0 # 实际实现需查默认 QFI 配置 else: # 多 QFI 映射到同一 DRB需要反射式规则或丢包 if not reflective_enabled: raise ValueError(fAmbiguous QFI for DRB {drb_id}: {qfis}) qfi 0 # 反射式场景下需查反射映射表此处简化 # 上行通常无 SDAP headerpayload 直接透传 return qfi, payload这段代码里len(qfis) 1的分支是实际部署里最容易出问题的地方。协议允许一个 DRB 承载多条 QoS Flow但上行没有 QFI 标记接收侧只能靠反射式映射表或者业务特征来区分。如果网络没开反射式 QoS又配了多 QFI 到同一 DRB那上行就是一笔糊涂账。我的建议是除非你明确知道核心网和基站都支持反射式否则一个 DRB 只配一条 QFI。反射式更新的逻辑应该在下行接收路径里做收到 RDI1 的包后调用mapping.add_mapping(qfi, drb_id)把下行观察到的映射关系同步到上行。注意这个更新是「覆盖式」的会替换该 QFI 原有的映射所以如果网络同时用 RRC 显式映射和反射式映射优先级要理清——37.324 的规定是显式配置优先反射式只在没有显式配置时生效。4. 避坑与排查SDAP 实现里最容易翻车的 5 个点4.1 现象业务能通但 QoS 不生效测速始终跑不满原因QFI 映射到了默认 DRB而默认 DRB 的调度优先级和保证速率是按最低档配的。显式映射的 RRC 信令可能没下发成功或者终端侧mappedQoS-FlowsToAdd解析后没真正写入映射表。解决先在终端侧打印映射表快照确认目标 QFI 是否在_qfi_to_drb里。如果不在抓 RRC Reconfiguration 消息看 SDAP-Config IE 是否携带了该 QFI。如果信令有但表里没有检查解析代码里 QFI 列表的遍历逻辑常见错误是把mappedQoS-FlowsToAdd当成单个值而不是列表处理。4.2 现象下行包解析出 QFI0业务被丢原因DL SDAP header 的启用状态和实际包格式不一致。要么网络没配 header 但终端按 header 解析要么反过来。QFI0 是保留值正常业务不会出现。解决在 RRC 配置里找到该 DRB 的sdap-Config确认headerDL字段是present还是absent。然后在解析函数入口加一个断言如果解析出 QFI0 且 D/C1直接打印原始字节前 4 个字节的 hex对比协议表格逐位核对。十有八九是 bit 序搞反了比如把 D/C 当成了最低位。4.3 现象反射式 QoS 开启后上行映射频繁跳变原因RDI 位的触发条件没卡严。37.324 规定只有 RDI1 且该 QFI 没有显式映射时才更新但有些实现只要收到 RDI1 就覆盖导致显式配置被反射式冲掉。解决在add_mapping调用前加判断先查_qfi_to_drb里该 QFI 是否有显式映射记录用一个单独的_explicit_qfis集合标记。只有不在这个集合里的 QFI才允许反射式更新。这个集合在 RRC 显式映射添加时加入在mappedQoS-FlowsToRelease时移除。4.4 现象卫星场景下 SDAP 重配延迟导致业务中断数秒原因卫星链路 RTT 大RRC 重配信令往返加上处理时间可能超过 1 秒。如果重配期间 SDAP 映射表被清空或锁定业务就断了。解决映射表更新用「先加后删」而不是「先删后加」。具体说收到新的mappedQoS-FlowsToAdd时先把新映射写入再处理mappedQoS-FlowsToRelease。这样在重配窗口内新旧映射同时存在业务不会断。代价是短暂期内一个 QFI 可能对应两个 DRB需要发送侧按「新映射优先」选路。4.5 现象多 QFI 映射同一 DRB 时上行 QFI 标记错乱原因上行没有 QFI 字段接收侧只能靠 DRB 反查。如果一个 DRB 对应多个 QFI且没有反射式映射表就无法区分。解决最稳妥的做法是配置阶段就避免多 QFI 到同一 DRB除非业务明确要求复用。如果必须复用确保反射式 QoS 开启并在上行接收路径里维护一个「最近下行 QFI」缓存按包到达顺序做启发式匹配。但这个方案不可靠只适合对 QoS 标记不敏感的业务。真正的解法是推动网络侧一个 DRB 配一条 QFI这在 37.324 里完全允许只是浪费一些 DRB ID。5. 进阶用日志和计数器验证 SDAP 映射是否正确协议实现完了怎么证明它是对的靠抓包看 QFI 只能验证单包要验证映射表的长期行为得靠计数器和日志。我习惯在 SDAP 实体里埋四个计数器dl_pkts_per_qfi、dl_pkts_per_drb、ul_pkts_per_drb、reflective_updates。每处理一个包就自增对应计数器定期 dump 成表格。下面是一个 dump 函数的示例def dump_sdap_stats(mapping: SdapMappingTable, counters: dict): 打印映射表与计数器快照用于验证 print( SDAP Mapping Snapshot ) for qfi, drb in sorted(mapping._qfi_to_drb.items()): print(fQFI {qfi:2d} - DRB {drb} fdl_pkts{counters[dl_pkts_per_qfi].get(qfi, 0)}) print( DRB Load ) for drb, qfis in sorted(mapping._drb_to_qfis.items()): total sum(counters[dl_pkts_per_qfi].get(q, 0) for q in qfis) print(fDRB {drb}: QFIs{sorted(qfis)} total_dl{total}) print(fReflective updates: {counters[reflective_updates]})跑一段时间后如果某个 QFI 的dl_pkts_per_qfi一直是 0说明映射配了但没业务或者业务走了默认 DRB。如果reflective_updates涨得飞快说明反射式映射在频繁覆盖大概率是 RDI 位判断有问题。这个快照我一般每 10 秒打一次跟核心网的 QoS 统计对账两边数字对不上就说明映射错了。验证反射式 QoS 是否生效有个更直接的办法在下行接收路径里收到 RDI1 的包后打一条日志包含 QFI、DRB ID 和时间戳。然后看上行发送时同一个 QFI 是否走了同一个 DRB。如果下行 QFI9 走 DRB 3上行 QFI9 也走 DRB 3反射式就对了。如果上行走了默认 DRB说明反射式更新没写进映射表或者被显式映射覆盖了。最后说个我自己的习惯每次改完 SDAP 映射相关代码先跑一个最小用例——单 QFI、单 DRB、无反射式确认基础路径通再开反射式确认 RDI 触发更新最后加多 QFI 复用确认上行不丢包。这三步走完基本能覆盖 37.324 里 90% 的坑。卫星场景额外加一步在 RRC 重配期间持续发包确认映射表更新不断流。这套流程帮我省过好几次通宵排查希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是面向5G NR协议学习者的3GPP TS 37.324 SDAP协议文档聚焦服务数据适配协议Service Data Adaptation Protocol的架构与流程解析适合无线通信工程师、协议栈开发人员及备考5G认证的读者查阅。压缩包内仅含1个docx文件约242KB内容围绕SDAP子层结构、SDAP实体、上下行数据传输、QoS流到DRB映射及反射QoS映射等核心章节展开并附有QFI、RDI、RQI等关键字段说明。文档从功能视角描述SDAP体系结构涵盖SDAP实体建立与释放、UL/DL SDAP数据PDU构造、末端标记控制PDU处理等过程可帮助读者理解QoS流与DRB之间的映射规则及反射映射机制。目前已有584人学习下载适合需要系统研读协议原文、对照实现细节或查漏补缺的读者参考。1. 3GPP 37.324 里的 SDAP它到底在 5G 协议栈里干什么如果你抓过 5G 空口的数据包大概率见过一层既不像 PDCP 也不像 RLC 的头部——它没有序列号长度还随配置变化这就是 SDAP。3GPP 37.324 这份协议专门定义它而 g20 版本是这套规范里被大量商用终端和基站实现引用的一个基线。SDAP 全称 Service Data Adaptation Protocol直译是「业务数据适配协议」它干的事说白了就一件把核心网下发的 QoS 流QoS Flow映射到空口的 DRBData Radio Bearer上并在下行包上打一个 QFI 标记让接收侧知道这个包属于哪条业务流。为什么 5G 要单独搞这么一层因为 4G 时代 QoS 粒度是承载级的一个 EPS Bearer 对应一套 QoS业务和承载基本一对一。到了 5G核心网把 QoS 粒度细化到 Flow 级同一个 PDU Session 里可以同时跑好几条 QoS Flow每条 Flow 有自己的 5QI、保证速率、优先级。但空口侧如果每条 Flow 都建一个 DRB信令开销和调度复杂度会爆炸。SDAP 就是那个「适配器」它允许把多条 QoS Flow 映射到同一个 DRB 上也可以一条 Flow 独占一个 DRB具体怎么映射由网络配置决定。这份协议适合谁看做 5G 终端协议栈的、做基站 L2 的、做核心网 UPF 与空口联调的还有做卫星通信协议栈的——现在 3GPP 卫星相关协议里SDAP 同样是用户面绕不开的一层。如果你只关心「PDU 会话怎么建」那 37.324 不是第一站但如果你要调 QoS 映射、排查业务流跑错承载、或者实现一个最小可用的 SDAP 实体这份文档就是必读。下面我按「先搞懂结构再动手实现最后踩坑」的顺序拆开讲。2. SDAP 的协议结构PDU 格式、QFI 与映射规则怎么读2.1 SDAP PDU 的两种格式与头部字段37.324 里 SDAP PDU 分两种带 DL SDAP header 的和不带 header 的。上行方向如果网络配置了 UL SDAP header终端发的每个包前面会带一个字节的头部下行方向同理但下行头部多了一个关键字段——QFI。先看下行 SDAP Data PDU 的格式。它由三部分组成1 字节的 SDAP header、可选的 SDAP Control PDU用于映射控制、以及实际的用户数据。头部结构如下字段长度含义D/C1 bitData/Control 指示0 表示控制 PDU1 表示数据 PDUR1 bit保留位发送端置 0接收端忽略QFI6 bitQoS Flow Identifier取值 0-63RDI1 bitReflective QoS Flow to DRB Mapping IndicationRQI1 bitReflective QoS Indication注意 QFI 只有 6 bit所以一个 PDU Session 里最多 64 条 QoS Flow。这个数字在核心网规划时就要卡住不是随便扩的。RDI 和 RQI 是反射式 QoS 用的终端收到下行包后如果 RDI 置 1就按这个包的 QFI 和 DRB 映射关系自动更新上行的映射规则不需要网络再发 RRC 信令。这是 5G 省信令的一个设计但也是坑最多的地方后面避坑章节会细说。上行 SDAP Data PDU 的头部更简单只有 D/C 和 R 两个字段没有 QFI。为什么因为上行方向DRB 和 QoS Flow 的映射关系是网络通过 RRC 配置好的基站收到上行包时根据它从哪个 DRB 上来就能反推 QFI不需要在包里再带。这个设计差异是很多人第一次读协议时容易绕晕的点。2.2 QoS Flow 到 DRB 的映射默认映射与显式信令SDAP 的核心功能是映射。37.324 定义了两种映射方式默认映射和显式映射。默认映射的规则是如果一条 QoS Flow 没有收到任何显式的 DRB 映射配置它就映射到该 PDU Session 的默认 DRB 上。默认 DRB 是 RRC 在建立 PDU Session 时指定的通常就是第一个建立的 DRB。这个机制保证了即使映射配置还没下发业务也不会断。显式映射则通过 RRC 的 SDAP-Config IE 下发里面包含两个关键字段mappedQoS-FlowsToAdd和mappedQoS-FlowsToRelease。前者是一个 QFI 列表告诉终端「这些 QFI 映射到我这个 DRB」后者是「这些 QFI 从我这个 DRB 移除」。注意一个 QFI 在同一时刻只能映射到一个 DRB但一个 DRB 可以承载多个 QFI。反射式映射是第三种也是 5G 特有的。它不需要 RRC 信令而是靠下行包的 RDI 位触发。终端收到 RDI1 的下行包后把该包的 QFI 和它所在的 DRB 的映射关系记下来用于上行发送。这个机制在卫星场景里特别有用因为卫星链路 RTT 大等 RRC 重配下来业务可能已经卡了。2.3 用 Python 解析一个 SDAP 下行 PDU光看表格不够直观写段代码把头部拆开。下面这个函数解析下行 SDAP Data PDU 的头部输入是 bytes输出是字段字典def parse_sdap_dl_header(data: bytes) - dict: 解析下行 SDAP Data PDU 头部1 字节 data: 至少 1 字节的原始数据 返回: 包含各字段的字典 if len(data) 1: raise ValueError(SDAP PDU too short) byte0 data[0] # 按 37.324 定义逐位提取 d_c (byte0 7) 0x01 # bit7: D/C r (byte0 6) 0x01 # bit6: 保留 qfi byte0 0x3F # bit5-0: QFI (6 bits) # 注意RDI/RQI 在部分版本中位于后续字节或复用位 # g20 基线里若配置了反射式 QoS需结合 RRC 配置判断 return { d_c: d_c, r: r, qfi: qfi, is_data: d_c 1, header_len: 1 } # 示例一个下行数据包QFI9 raw bytes([0x89]) # 1000 1001 - D/C1, R0, QFI9 print(parse_sdap_dl_header(raw)) # 输出: {d_c: 1, r: 0, qfi: 9, is_data: True, header_len: 1}这段代码的关键在byte0 0x3F0x3F 是低 6 位掩码正好对应 QFI 的 6 bit。D/C 位在最高位右移 7 位取出。参数说明data必须是完整的 PDU 起始字节如果传入的是已经去掉头部的 payload解析结果会错。实际实现里你还需要根据 RRC 配置判断当前 DRB 是否启用了 DL SDAP header因为 37.324 允许网络配置「无头部」模式这时候第一个字节直接就是用户数据不能按头部解析。提示QFI0 是保留值实际业务从 1 开始分配。如果你解析出 QFI0 且 D/C1大概率是头部解析错位或者配置没对齐。3. 动手实现一个最小 SDAP 实体映射表、QFI 标记与收发流程3.1 映射表的数据结构设计实现 SDAP 实体第一件事是设计映射表。它要支持三个操作按 QFI 查 DRB下行发送用、按 DRB 查 QFI 列表上行接收用、动态增删映射RRC 重配和反射式更新用。我一般用两个字典加一个锁来搞Python 里大概长这样import threading class SdapMappingTable: def __init__(self, default_drb_id: int): self.default_drb_id default_drb_id self._qfi_to_drb {} # QFI - DRB ID self._drb_to_qfis {} # DRB ID - set(QFI) self._lock threading.RLock() def add_mapping(self, qfi: int, drb_id: int): 显式映射把 QFI 绑到 DRB自动处理旧映射 with self._lock: old_drb self._qfi_to_drb.get(qfi) if old_drb drb_id: return if old_drb is not None: self._drb_to_qfis.get(old_drb, set()).discard(qfi) self._qfi_to_drb[qfi] drb_id self._drb_to_qfis.setdefault(drb_id, set()).add(qfi) def remove_mapping(self, qfi: int): 移除显式映射回落到默认 DRB with self._lock: old_drb self._qfi_to_drb.pop(qfi, None) if old_drb is not None: self._drb_to_qfis.get(old_drb, set()).discard(qfi) def get_drb(self, qfi: int) - int: 下行发送QFI 查 DRB未配置则用默认 with self._lock: return self._qfi_to_drb.get(qfi, self.default_drb_id) def get_qfis(self, drb_id: int) - set: 上行接收DRB 查 QFI 集合 with self._lock: return set(self._drb_to_qfis.get(drb_id, set()))这里用RLock而不是普通Lock是因为反射式更新可能在持有锁的路径里再次调用add_mapping普通锁会死锁。remove_mapping不删_drb_to_qfis里的空集合是为了避免频繁创建销毁代价是内存里会留一些空 set实际跑起来量很小可以接受。参数说明default_drb_id必须在初始化时传入且不能为 None。如果网络配置的默认 DRB 后续被释放需要外部逻辑保证至少有一个 DRB 可用否则get_drb会返回一个无效 ID。3.2 下行发送打 QFI 标记并选 DRB下行方向SDAP 从核心网收到的是带 QFI 的包通常来自 GTP-U 的 PDU Session Container它要做两件事根据 QFI 选 DRB然后在包前面加上 SDAP header。def sdap_dl_transmit(qfi: int, payload: bytes, mapping: SdapMappingTable, header_enabled: bool True) - tuple: 下行发送处理 qfi: 核心网标记的 QoS Flow ID payload: 用户数据 header_enabled: 该 DRB 是否配置了 DL SDAP header 返回: (drb_id, 待发送字节流) drb_id mapping.get_drb(qfi) if not header_enabled: # 无头部模式直接透传 return drb_id, payload # 构造 1 字节头部D/C1, R0, QFI 低 6 位 header 0x80 | (qfi 0x3F) return drb_id, bytes([header]) payload关键在0x80 | (qfi 0x3F)0x80 把最高位置 1 表示 Data PDU低 6 位放 QFI。qfi 0x3F是防御性写法防止上层传入超过 63 的 QFI 导致位溢出。实际实现里如果 QFI 超过 63应该直接丢包并上报错误而不是静默截断。header_enabled这个参数必须从 RRC 配置里取不能拍脑袋。37.324 允许每个 DRB 独立配置是否带 DL SDAP header同一个 UE 的不同 DRB 可以一个带一个不带。我见过有实现图省事全局开头部结果跟某些核心网对接时包全被丢了因为对方按无头部解析第一个字节被当成了用户数据。3.3 上行接收从 DRB 反推 QFI 并做反射式更新上行方向SDAP 从 RLC 收到包根据它来自哪个 DRB查映射表得到 QFI 集合。如果集合里只有一个 QFI直接标记如果有多个就需要靠反射式映射或者更细的规则来区分——这也是为什么很多实现建议一个 DRB 只映射一条 QFI省得猜。def sdap_ul_receive(drb_id: int, payload: bytes, mapping: SdapMappingTable, reflective_enabled: bool False) - tuple: 上行接收处理 返回: (qfi, 用户数据) qfis mapping.get_qfis(drb_id) if len(qfis) 1: qfi next(iter(qfis)) elif len(qfis) 0: # 没有显式映射用默认 DRB 对应的 QFI通常由 RRC 指定 qfi 0 # 实际实现需查默认 QFI 配置 else: # 多 QFI 映射到同一 DRB需要反射式规则或丢包 if not reflective_enabled: raise ValueError(fAmbiguous QFI for DRB {drb_id}: {qfis}) qfi 0 # 反射式场景下需查反射映射表此处简化 # 上行通常无 SDAP headerpayload 直接透传 return qfi, payload这段代码里len(qfis) 1的分支是实际部署里最容易出问题的地方。协议允许一个 DRB 承载多条 QoS Flow但上行没有 QFI 标记接收侧只能靠反射式映射表或者业务特征来区分。如果网络没开反射式 QoS又配了多 QFI 到同一 DRB那上行就是一笔糊涂账。我的建议是除非你明确知道核心网和基站都支持反射式否则一个 DRB 只配一条 QFI。反射式更新的逻辑应该在下行接收路径里做收到 RDI1 的包后调用mapping.add_mapping(qfi, drb_id)把下行观察到的映射关系同步到上行。注意这个更新是「覆盖式」的会替换该 QFI 原有的映射所以如果网络同时用 RRC 显式映射和反射式映射优先级要理清——37.324 的规定是显式配置优先反射式只在没有显式配置时生效。4. 避坑与排查SDAP 实现里最容易翻车的 5 个点4.1 现象业务能通但 QoS 不生效测速始终跑不满原因QFI 映射到了默认 DRB而默认 DRB 的调度优先级和保证速率是按最低档配的。显式映射的 RRC 信令可能没下发成功或者终端侧mappedQoS-FlowsToAdd解析后没真正写入映射表。解决先在终端侧打印映射表快照确认目标 QFI 是否在_qfi_to_drb里。如果不在抓 RRC Reconfiguration 消息看 SDAP-Config IE 是否携带了该 QFI。如果信令有但表里没有检查解析代码里 QFI 列表的遍历逻辑常见错误是把mappedQoS-FlowsToAdd当成单个值而不是列表处理。4.2 现象下行包解析出 QFI0业务被丢原因DL SDAP header 的启用状态和实际包格式不一致。要么网络没配 header 但终端按 header 解析要么反过来。QFI0 是保留值正常业务不会出现。解决在 RRC 配置里找到该 DRB 的sdap-Config确认headerDL字段是present还是absent。然后在解析函数入口加一个断言如果解析出 QFI0 且 D/C1直接打印原始字节前 4 个字节的 hex对比协议表格逐位核对。十有八九是 bit 序搞反了比如把 D/C 当成了最低位。4.3 现象反射式 QoS 开启后上行映射频繁跳变原因RDI 位的触发条件没卡严。37.324 规定只有 RDI1 且该 QFI 没有显式映射时才更新但有些实现只要收到 RDI1 就覆盖导致显式配置被反射式冲掉。解决在add_mapping调用前加判断先查_qfi_to_drb里该 QFI 是否有显式映射记录用一个单独的_explicit_qfis集合标记。只有不在这个集合里的 QFI才允许反射式更新。这个集合在 RRC 显式映射添加时加入在mappedQoS-FlowsToRelease时移除。4.4 现象卫星场景下 SDAP 重配延迟导致业务中断数秒原因卫星链路 RTT 大RRC 重配信令往返加上处理时间可能超过 1 秒。如果重配期间 SDAP 映射表被清空或锁定业务就断了。解决映射表更新用「先加后删」而不是「先删后加」。具体说收到新的mappedQoS-FlowsToAdd时先把新映射写入再处理mappedQoS-FlowsToRelease。这样在重配窗口内新旧映射同时存在业务不会断。代价是短暂期内一个 QFI 可能对应两个 DRB需要发送侧按「新映射优先」选路。4.5 现象多 QFI 映射同一 DRB 时上行 QFI 标记错乱原因上行没有 QFI 字段接收侧只能靠 DRB 反查。如果一个 DRB 对应多个 QFI且没有反射式映射表就无法区分。解决最稳妥的做法是配置阶段就避免多 QFI 到同一 DRB除非业务明确要求复用。如果必须复用确保反射式 QoS 开启并在上行接收路径里维护一个「最近下行 QFI」缓存按包到达顺序做启发式匹配。但这个方案不可靠只适合对 QoS 标记不敏感的业务。真正的解法是推动网络侧一个 DRB 配一条 QFI这在 37.324 里完全允许只是浪费一些 DRB ID。5. 进阶用日志和计数器验证 SDAP 映射是否正确协议实现完了怎么证明它是对的靠抓包看 QFI 只能验证单包要验证映射表的长期行为得靠计数器和日志。我习惯在 SDAP 实体里埋四个计数器dl_pkts_per_qfi、dl_pkts_per_drb、ul_pkts_per_drb、reflective_updates。每处理一个包就自增对应计数器定期 dump 成表格。下面是一个 dump 函数的示例def dump_sdap_stats(mapping: SdapMappingTable, counters: dict): 打印映射表与计数器快照用于验证 print( SDAP Mapping Snapshot ) for qfi, drb in sorted(mapping._qfi_to_drb.items()): print(fQFI {qfi:2d} - DRB {drb} fdl_pkts{counters[dl_pkts_per_qfi].get(qfi, 0)}) print( DRB Load ) for drb, qfis in sorted(mapping._drb_to_qfis.items()): total sum(counters[dl_pkts_per_qfi].get(q, 0) for q in qfis) print(fDRB {drb}: QFIs{sorted(qfis)} total_dl{total}) print(fReflective updates: {counters[reflective_updates]})跑一段时间后如果某个 QFI 的dl_pkts_per_qfi一直是 0说明映射配了但没业务或者业务走了默认 DRB。如果reflective_updates涨得飞快说明反射式映射在频繁覆盖大概率是 RDI 位判断有问题。这个快照我一般每 10 秒打一次跟核心网的 QoS 统计对账两边数字对不上就说明映射错了。验证反射式 QoS 是否生效有个更直接的办法在下行接收路径里收到 RDI1 的包后打一条日志包含 QFI、DRB ID 和时间戳。然后看上行发送时同一个 QFI 是否走了同一个 DRB。如果下行 QFI9 走 DRB 3上行 QFI9 也走 DRB 3反射式就对了。如果上行走了默认 DRB说明反射式更新没写进映射表或者被显式映射覆盖了。最后说个我自己的习惯每次改完 SDAP 映射相关代码先跑一个最小用例——单 QFI、单 DRB、无反射式确认基础路径通再开反射式确认 RDI 触发更新最后加多 QFI 复用确认上行不丢包。这三步走完基本能覆盖 37.324 里 90% 的坑。卫星场景额外加一步在 RRC 重配期间持续发包确认映射表更新不断流。这套流程帮我省过好几次通宵排查希望帮到你。本文还有配套的精品资源点击获取
