当UE和网络之间需要传输业务时，核心网检测并向PDU Session内的传入分组分配所谓的QoS Flow ID，而RAN建立不同的QoS Flow并将其映射到不同的无线承载中。

不仅是gNB，而且UE需要知道特定分组属于哪个QoS流以执行某些动作。换句话说，gNB必须能够将相应的信息包括到下行分组中；对于上行方向上的UE也是如此。

SDAP header format

SDAP报头可以完全不存在，这种操作模式被称为“透明模式”。换言之，除非由RRC在每个DRB的基础上明确地配置，否则UE不应期望任何SDAP相关信息的存在。

由于SDAP报头存在于特定DRB，因此值得注意的是，SDAP报头的前提思想之一是传达特定分组属于哪个QoS Flow ID的信息。这是通过在分组报头中包含相应的QoS Flow ID（QFI）字段来实现的。同时，在某些情况下，该QoS Flow ID可能不存在，即QoS Flow ID不一定总是包含在内。基于此，SDAP header的结构可分为以下主要选项：

• 全静态SDAP报头；

• 半静态SDAP标头（带有强制部分和可选部分）；

• 全动态SDAP报头（整个报头可以不存在）。

Fully static SDAP header

从该选项的名称可以看出，前提思想是SDAP标头是完全静态的，即一旦配置，它就具有固定大小。基于此，SDAP报头的示例性结构可能如下图1所示。应当注意，由于QFI字段始终存在于该解决方案中，因此UE无法知道其是否需要更新由反射QoS触发的映射规则。因此，应该存在另一个字段，因此称为“R”字段，在UE需要更新其反射QoS关联的情况下，该字段将由gNB设置。

该解决方案的优点是SDAP报头具有固定结构，该结构简化了UE实现，即它可以立即读取整个报头，而不需要在理解整个结构时采取额外的动作。缺点是，对于在特定DRB上发送的每个PDCP SDU，将存在整个SDAP报头。

Semi-static SDAP header

在半静态SDAP报头的情况下，最终报头结构可能如下所示。SDAP报头可以包括固定的1-octet部分，其将包含指示QoS Flow ID（QFI）信息是否存在的“Q”字段。如果设置了“Q”字段，则意味着固定的1个八位字节部分后面是QFI字段。

值得注意的是，“Q”字段隐含地用于两个目的：它指示QFI字段的存在，同时它要求UE更新反射QoS映射信息。UE需要明确地接收QoS Flow ID值的唯一原因是能够更新其在IP flow、QoS Flow ID和DRB之间的关联。否则，不需要QoS Flow ID字段。

与其他选项相比，此解决方案在开销和灵活性之间提供了很好的权衡。一方面，不需要将QoS Flow ID字段附加到每个PDCP SDU中，因为反射QoS动作应该在UE侧仅触发一次。此后，不再需要QoS Flow ID。这种方法的缺点是，在UE能够理解QFI字段是否存在以及PDCP PDU开始的位置之前，UE将需要采取更多关于首先读取固定的1-octet字节部分的动作。

Fully dynamic SDAP header

从名称中可以看出，SDAP报头可以完全不存在，其存在/不存在将由例如PDCP报头中的相应控制位来指示。从这个意义上讲，这个解决方案与上面中的解决方案非常接近，唯一的区别是对应的“存在”位将驻留在PDCP报头中，而不是SDAP报头开头的固定部分中。生成的SDAP头可以像只包含QFI字段的头一样简单。然而，如果将来需要，也可以考虑为额外的控制信息添加1-octet字节报头。

此解决方案的优点是，在本文档中考虑的所有选项中，其开销最低。如果不需要QoS Flow ID信息，则PDCP SDU中不包括任何内容。缺点是UE必须采取额外的行动，才能理解包报头结构。此外，这种方法打破了构建协议层的一些逻辑原则，因为现在PDCP层必须向另一层传递特定信息。

在体系结构上，有两个级别的映射：IP_flow-to-QoS_flow和QoS_flow-to-DRB。由于这些映射原则上可以彼此独立地进行更新，因此在SDAP报头中引入两个单独的比特用于反映QoS动作，涵盖了以下场景。

1.要求UE更新IP_flow-to-QoS_flow和QoS_flow-to-DRB映射。最预期的场景是当新的IP流到达时，它被分类为新的QoS流和（可能是新的）DRB。

2.要求UE仅更新IP_flow-to-QoS_flow映射。最预期的场景是当新的IP流到达时，但它被分类为现有的QoS流，QoS_flow-to-DRB映射已经存在。

3.要求UE仅更新QoS_flow-to-DRB映射。最预期的场景是当IP流已经存在并且已经被CN分类时，RAN只需要将该流移动到不同的DRB中。

分析了所有这些场景后，可以得出结论，即SDAP报头中的一个位可以安全地支持所有场景。换句话说，当某个分组到达并且在SDAP报头中设置了相应的反射QoS比特时，UE将更新/检查IP_flow-to-QoS_flow和QoS_flow-to-DRB映射。尽管有人可能认为它迫使UE执行不必要的动作，但应该避免为每个传入分组触发反射性QoS动作，并且网络只有在确实需要时才触发这些动作，即当必须更新某些内容时。

QoS flow ID size

QoS Flow ID大小有效地确定了核心网在向RAN发送数据时能够发送多少不同的QoS流。作为示例，如果QoS Flow ID大小为1字节，则可以向gNB发送多达256个QoS流的信号。由于每个PDU会话的QoS流ID值是特定的，因此对于大多数使用情况，256个流应该足够了，特别是考虑到每个UE建立的DRB的数量将低得多，并且将由UE实际可以支持的DRB数量来控制。换言之，即使核心网可以潜在地检测传入数据并将其分类为多达256个QoS流，它们中的大多数将被映射到共享相同RLC和PDCP状态机的相同DRB。基于此，对于大多数情况，QoS Flow ID的1个字节应该是足够的，特别是当UE是移动电话或类似类型的设备，其将不能支持大量DRB时。

可以考虑甚至更小的QoS Flow ID大小（6或7比特），以满足更小的SDAP报头开销。然而，它将允许核心网络将传入流量分别分类为64或128个流，这对于倾向于建立大量TCP连接的富多媒体设备来说可能是不够的。

此外，还值得注意的是，UE可以是服务于每个设备具有多个流的多个终端设备的某种形式的客户驻地设备。对于这种情况，核心网可以识别的QoS流总数可能超过256个。将QoS Flow ID大小扩展到2字节将允许每个PDU会话最多发送65536个流，这应该涵盖所有主要情况。