當UE和網(wǎng)絡之間需要傳輸業(yè)務時，核心網(wǎng)檢測并向PDU Session內的傳入分組分配所謂的QoS Flow ID，而RAN建立不同的QoS Flow并將其映射到不同的無線承載中。

不僅是gNB，而且UE需要知道特定分組屬于哪個QoS流以執(zhí)行某些動作。換句話說，gNB必須能夠將相應的信息包括到下行分組中；對于上行方向上的UE也是如此。

SDAP header format

SDAP報頭可以完全不存在，這種操作模式被稱為“透明模式”。換言之，除非由RRC在每個DRB的基礎上明確地配置，否則UE不應期望任何SDAP相關信息的存在。

由于SDAP報頭存在于特定DRB，因此值得注意的是，SDAP報頭的前提思想之一是傳達特定分組屬于哪個QoS?Flow?ID的信息。這是通過在分組報頭中包含相應的QoS?Flow?ID（QFI）字段來實現(xiàn)的。同時，在某些情況下，該QoS?Flow?ID可能不存在，即QoS?Flow?ID不一定總是包含在內。基于此，SDAP?header的結構可分為以下主要選項：

• 全靜態(tài)SDAP報頭；

• 半靜態(tài)SDAP標頭（帶有強制部分和可選部分）；

• 全動態(tài)SDAP報頭（整個報頭可以不存在）。

Fully static SDAP header

從該選項的名稱可以看出，前提思想是SDAP標頭是完全靜態(tài)的，即一旦配置，它就具有固定大小。基于此，SDAP報頭的示例性結構可能如下圖1所示。應當注意，由于QFI字段始終存在于該解決方案中，因此UE無法知道其是否需要更新由反射QoS觸發(fā)的映射規(guī)則。因此，應該存在另一個字段，因此稱為“R”字段，在UE需要更新其反射QoS關聯(lián)的情況下，該字段將由gNB設置。

該解決方案的優(yōu)點是SDAP報頭具有固定結構，該結構簡化了UE實現(xiàn)，即它可以立即讀取整個報頭，而不需要在理解整個結構時采取額外的動作。缺點是，對于在特定DRB上發(fā)送的每個PDCP SDU，將存在整個SDAP報頭。

Semi-static SDAP?header

在半靜態(tài)SDAP報頭的情況下，最終報頭結構可能如下所示。SDAP報頭可以包括固定的1-octet部分，其將包含指示QoS?Flow ID（QFI）信息是否存在的“Q”字段。如果設置了“Q”字段，則意味著固定的1個八位字節(jié)部分后面是QFI字段。

值得注意的是，“Q”字段隱含地用于兩個目的：它指示QFI字段的存在，同時它要求UE更新反射QoS映射信息。UE需要明確地接收QoS?Flow ID值的唯一原因是能夠更新其在IP?flow、QoS?Flow ID和DRB之間的關聯(lián)。否則，不需要QoS?Flow ID字段。

與其他選項相比，此解決方案在開銷和靈活性之間提供了很好的權衡。一方面，不需要將QoS?Flow ID字段附加到每個PDCP SDU中，因為反射QoS動作應該在UE側僅觸發(fā)一次。此后，不再需要QoS?Flow ID。這種方法的缺點是，在UE能夠理解QFI字段是否存在以及PDCP PDU開始的位置之前，UE將需要采取更多關于首先讀取固定的1-octet字節(jié)部分的動作。

Fully dynamic SDAP header

從名稱中可以看出，SDAP報頭可以完全不存在，其存在/不存在將由例如PDCP報頭中的相應控制位來指示。從這個意義上講，這個解決方案與上面中的解決方案非常接近，唯一的區(qū)別是對應的“存在”位將駐留在PDCP報頭中，而不是SDAP報頭開頭的固定部分中。生成的SDAP頭可以像只包含QFI字段的頭一樣簡單。然而，如果將來需要，也可以考慮為額外的控制信息添加1-octet字節(jié)報頭。

此解決方案的優(yōu)點是，在本文檔中考慮的所有選項中，其開銷最低。如果不需要QoS?Flow ID信息，則PDCP SDU中不包括任何內容。缺點是UE必須采取額外的行動，才能理解包報頭結構。此外，這種方法打破了構建協(xié)議層的一些邏輯原則，因為現(xiàn)在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流到達時，但它被分類為現(xiàn)有的QoS流，QoS_flow-to-DRB映射已經(jīng)存在。

3.要求UE僅更新QoS_flow-to-DRB映射。最預期的場景是當IP流已經(jīng)存在并且已經(jīng)被CN分類時，RAN只需要將該流移動到不同的DRB中。

分析了所有這些場景后，可以得出結論，即SDAP報頭中的一個位可以安全地支持所有場景。換句話說，當某個分組到達并且在SDAP報頭中設置了相應的反射QoS比特時，UE將更新/檢查IP_flow-to-QoS_flow和QoS_flow-to-DRB映射。盡管有人可能認為它迫使UE執(zhí)行不必要的動作，但應該避免為每個傳入分組觸發(fā)反射性QoS動作，并且網(wǎng)絡只有在確實需要時才觸發(fā)這些動作，即當必須更新某些內容時。

QoS flow ID size

QoS?Flow ID大小有效地確定了核心網(wǎng)在向RAN發(fā)送數(shù)據(jù)時能夠發(fā)送多少不同的QoS流。作為示例，如果QoS?Flow ID大小為1字節(jié)，則可以向gNB發(fā)送多達256個QoS流的信號。由于每個PDU會話的QoS流ID值是特定的，因此對于大多數(shù)使用情況，256個流應該足夠了，特別是考慮到每個UE建立的DRB的數(shù)量將低得多，并且將由UE實際可以支持的DRB數(shù)量來控制。換言之，即使核心網(wǎng)可以潛在地檢測傳入數(shù)據(jù)并將其分類為多達256個QoS流，它們中的大多數(shù)將被映射到共享相同RLC和PDCP狀態(tài)機的相同DRB?；诖耍瑢τ诖蠖鄶?shù)情況，QoS?Flow ID的1個字節(jié)應該是足夠的，特別是當UE是移動電話或類似類型的設備，其將不能支持大量DRB時。

可以考慮甚至更小的QoS?Flow ID大小（6或7比特），以滿足更小的SDAP報頭開銷。然而，它將允許核心網(wǎng)絡將傳入流量分別分類為64或128個流，這對于傾向于建立大量TCP連接的富多媒體設備來說可能是不夠的。

此外，還值得注意的是，UE可以是服務于每個設備具有多個流的多個終端設備的某種形式的客戶駐地設備。對于這種情況，核心網(wǎng)可以識別的QoS流總數(shù)可能超過256個。將QoS?Flow ID大小擴展到2字節(jié)將允許每個PDU會話最多發(fā)送65536個流，這應該涵蓋所有主要情況。