为了支持XR，3GPP R18都做了哪些增强？

本文来自星球精华帖，“modem帮”知识星球简介

正文开始

在UL和DL中，XR-Awareness有助于优化gNB无线资源调度，但是这里就依赖于 PDU set和data burst。这两个东西是什么意思？其实PDU set就是由一个或多个 PDU组成，这些PDU携带在应用程序级别生成的一个信息单元的payload(例如帧或视频切片)，而data burst是应用程序在短时间内生成和发送的一组data PDU。

这里data burst可以由属于一个或多个 PDU set的多个PDU组成。在data burst期间，数据传输肯定是处于active状态。虽然data burst的持续时间可能有所不同，但可以假设它是保持在同一数量级内。

然而在当前5GS中，QoS flow是PDU session中QoS区分的最细粒度。5G QoS特性由5QI决定。这意味着QoS flow中的每个数据包都按照相同的QoS要求进行处理。

然而对于XR/媒体服务，就要以PDU set的形式区分，通常PDU set的payload对应的就是一组数据包(例如帧、视频切片/图块)。

在媒体层，此类PDU set中的数据包会作为一个整体进行解码/处理。例如，只有在成功传送承载帧/视频切片的所有或一定数量的数据包的情况下，才能解码帧/视频切片。又比如，只有在成功接收到该帧所依赖的所有帧的情况下，客户端才能解码 GOP（图片组）中的帧。因此，PDU set中的数据包组在媒体层中具有固有的相互依赖性。如果不考虑 PDU set中数据包之间的这种依赖关系，5GS就可能出现效率低下的调度。例如，5GS可能会随机丢弃重要数据包，但尝试传递同一PDU set的其他数据包，而这些数据包可能对客户端来说是无用的，因而会浪费无线资源。

为了提升效率并提升用户体验，就需要基于PDU set特性，音频样本、触觉应用或远程控制操作，再考虑到PDU set(例如帧/视频切片)数据包之间的这种依赖关系，因而R18 XR进行的就是PDU set based Qos的处理。

下面就看下PDU set QoS相关参数，这块在TS 23.501中有描述。

XR-Awareness 依赖于 QoS flow、PDU set、Data burst和traffic assistance information。

SMF 可以将PDU set QoS 参数作为 QoS flow的QoS 配置文件的一部分提供给 gNB，以便启用PDU set based QoS 处理。

PDU set QoS 参数包括：

1. PDU Set Delay Budget(PSDB)。

2. PDU Set Error Rate(PSER)。

3. PDU Set Integrated Handling Information(PSIHI)。

在PDU set based QoS 场景，应至少将PSIHI或(PSDB和PSER)中的一项发送到 NG-RAN 以便启用基于PDU set的处理。而NG-RAN收到PDU set QoS参数的话，就会启用基于PDU set的QoS处理并应用PDU set QoS参数。但是在实际配置中，对于给定的QoS flow，PSDB、PSER和PSIHI的值对于UL和DL则可能不同。

那这几个PDU set QoS 参数都是什么意思？我们一个个来看看。

图片

PDU Set Delay Budget(PSDB) 定义了PDU set在 UE 和 UPF 的 N6 终止点之间传输时可能经历的延迟的上限，即第一个PDU的接收时间与成功接收 PDU set的所有PDU的时间之间的持续时间，这里分别针对UL和DL有各自的PSDB。DL PSDB适用于PSA UPF通过N6接口接收的DL PDU set，UL PSDB适用于UE发送的UL PDU set。

每个方向的QoS flow最多会与一个PSDB值相关联。值得注意的是PSDB是可选参数，可由PCF提供。NG-RAN可以使用提供的PSDB来支持调度和链路层功能的配置。当PSDB可用时，那对于NG-RAN中给定的QoS folw，UL或DL PSDB就会取代相应方向的PDB。在NG-RAN中，AN PSDB是通过从PSDB中减去CN PDB得出的。

PDU set Error Rate(PSER)定义了已由链路层协议发送方(例如3GPP接入的RAN中的RLC)处理但未由相应接收方成功传送到上层的PDU set(例如3GPP access的 RAN中的PDCP)的速率上限。因此，PSER 定义了非拥塞相关PDU set losses的上限。PSER的主要目的是要采用适当的链路层协议配置(例如3GPP acces的RAN中的 RLC和HARQ)来达到目的。具体怎么搞PSER，就取决于RAN实现。

到这里不禁要问，怎么样才能算PDU set被成功传送？其实这里也有规定，就像大家想的那样，只有当PDU set中的所有PDU都成功传送时，PDU set才被视为成功传送。

和PSDB类似，QoS flow每个方向最多与一个 PSER 值相关联。值得注意的是PSER是可选参数。如果PSER可用，则UL和DL PSER 将在 NG-RAN中取代相应方向的 PER。

而PDU Set integrated Handling information(PSIHI)代表的是接收端应用层在使用PDU set处理数据时，是否要使用PDU set中的所有PDU。PSIHI也是可选参数。同样的QoS flow每个方向最多与一个PSIHI值相关联。

如果指示需要PDU set中的所有PDU进行Qos flow处理时，PDU set中只要一个PDU发送丢失的情况，那其余的PDU虽然是收到了，那在发送端就可以对其进行discard操作以便释放无线电资源。

这里简单提及下video相关概念，我们都知道视频在本质上将一幅一幅独立的画面进行快速地连续播放，利用眼睛的视觉暂留效应让人产生“动”的感觉。那video中每一幅画面可以称作“帧（frame）”，每秒播放的画面数量被称作“帧率"，也就是常说的FPS，即Frame Per Second。通常眼睛所看到的画面帧率高于每秒约10至12张的时候就会认为是连贯的。帧率越高，画质就越清晰，所以不管是手机还是电视追求的都是高帧率。

那每秒要连续播放这么多画面，视频的大小肯定远大于图片，在线流畅播放占用的带宽也要大得多。这样不做处理，如果要达到在线播放分辨率为4K，帧率为30FPS的视频，就需要占用接近6Gbps的带宽，这种情况下即使是用5G传输也可能亚历山大。

图片

因而就需要对视频进行压缩。那压缩算法就会把视频内容编码为I帧以及P帧。其中I帧是关键帧，必须能够完全独立解码，因此只能使用帧内预测；P帧作为预测帧，仅反映上一个I帧变化的部分，既可以使用帧内预测，也可以使用帧间预测，但离开了I帧就无法解码。除了I帧和P帧之外，还有一种B帧（双向帧）。B帧的编解码可同时参考左右的帧，需要传输的数据量更小。例如上图就是一种压缩算法的图示。

假如通过PSIHI指示接收端应用层在使用PDU set处理数据时，需要使用PDU set中的所有PDU，如果PDU set中的I帧相关的PDU丢失，那即使收到其他相关PDU，最终能展现的video效果可能就相当不尽人意，既然如此不如就discard。

那在UL就可以为特定 DRB 配置PDU set based的discard操作。配置后，当由于discard Timer超时而discard属于此PDU set的一个PDU时，UE就会 discard PDU set中的所有数据包。在考虑 PSDB、PSI、PSIHI参数的情况下，gNB可以基于实现执行DL PDU set discard。对于DL拥塞，gNB可以基于PSI(PDU Set Importance)执行 PDCP SDU discard操作。对于UL，对于PDCP中重要性较低的 PDU set要采用较短的discard timer。

什么样的PDU set可以认为是low importance，这个标准取决于UE实现。

在采取discard操作后，发送端PDCP entity可以通过 PDCP control PDU通知接收端，由于PDCP SDU discard而导致发送端PDCP SN序列中的gap。

这里还要提到Max Data Burst Volume(MDBV)，实际上每个具有Delay-critical resource type的 GBR QoS flow都应与MDBV相关联。MDBV表示5G-AN在5G-AN PDB周期内需要服务的最大数据量。

每个standardized 5QI(Delay-critical GBR资源类型)都与MDBV的默认值相关联。MDBV还可以与standardized 5QI一起发信号给(R)AN，RAN收到后就会使用它代替默认值。MDBV可以与预配置的5QI一起发信号给(R)AN。

图片

上图不同的5QI value对应不同的MDBV，而5QI=87～90 中的interactive services以及Visual content for cloud/edge/split rendering对应的就是XR(AR/VR等)相关的Qos characteristics。

PDU Set相关的参数有了，那具体怎么识别不同的PDU set？再来看下。

为了支持基于PDU set的QoS处理，PSA UPF需要识别属于PDU set的PDU并确定相关PDU set信息，然后将其带在GTP-U header中发给NG-RAN。然后NG-RAN就会使用PDU set信息进行基于PDU set的QoS处理。

这里PDU set信息包括：PDU set sn，PDU set end PDU indication,PDU set内的 PDU sn，PDU set size(以字节为单位)以及PDU set Importance(用于标识 PDU set相对于QoS flow内其他PDU set的相对importance)。

NG-RAN可以在拥塞的情况下使用QoS flow中的Priority Level和QoS flow内的PDU set importance来进行PDU set级别的数据包discard。

除了考虑QoS flow中的PDU set importance之外，NG-RAN在确定需要丢弃哪个PDU set时，还可以考虑同一优先级的QoS flow之间的相对PDU set importance，这就取决于运营商的实施和配置。除此之外，QoS flow中不同PDU set的PDU set信息可能不同。

图片

之前已经说过，PDU set是由一个或多个PDU组成，这些 PDU会承载应用层payload，例如视频帧或视频切片。NG-RAN基于PDU set的QoS处理主要是由 QoS flow的 QoS 配置文件中的 PDU set QoS 参数(例如PSER,PSDB和PSIHI等参数)和 PSA UPF 通过 N3/N9 接口提供的 PDU set信息决定。PDU set based Handling可应用于GBR和non-GBR QoS flow。AF应为动态PCC控制提供与 PDU set相关的辅助信息。AF session可以向NEF/PCF提供以下一个或多个与 PDU set相关的辅助信息：

 1 PDU set QoS 参数(PSER,PSDB和PSIHI)

 2 协议描述：指示服务数据流使用的传输协议(例如RTP、SRTP)和信息，例如以下内容：

(1)RTP或SRTP(Secure RTP,也就是加密的RTP)；

(2)带有RTP header扩展的RTP或SRTP，包括：RTP Header Extension for PDU Set Marking；

(3)RFC 8285定义的其他RTP header extensions；

(4)没有 RTP header extensions但带有 RTP payload format的 RTP 或 SRTP(例如 H.264 或 H.265)；

(5)RTP或SRTP带有用于PDU set marketing的RTP header extension并结合RTP payload foramt(例如 H.264或H.265)；

(6)RTP或SRTP带有遵循RFC 8285的其他RTP header extension并结合 RTP payload format(例如H.264或H.265)。

而上面提到的RTP Header Extension for PDU Set Marking结构如上图(TS 26.522)，通过该header就可以知道PDU set相关的辅助信息，具体field解释如上图右侧。

UE power saving management

图片

为了配置C-DRX 的 UE power saving管理方案，5GC可通过NG AP TSC辅助信息(TSCAI)向gNB提供XR流量辅助信息(适用于 GBR 和non-GBR QoS flow)：

(1)UL 或 DL periodicity；

(2)与 DL周期相关的 N6 Jitter信息；

gNB可以使用此辅助信息来配置DRX，以便达到更好的省电效果。

开头提到了data burst可以由一个或多个 PDU set的多个PDU组成。由此UPF 可以向 NG-RAN 提供End of Data Burst Indication，基于 PCC 规则中的End of Data Burst marking Indication和本地运营商策略，SMF 应请求 UPF 检测data burst的最后一个 PDU，并在DL最后一个 PDU 的 GTP-U header中标记 End of Data burst。gNB 可以使用此信息在可能的情况下将 UE 推回sleep状态。

在UL中UE需要能够动态识别PDU set和data burst，包括 PSI。如何做到这一点取决于UE实现，毕竟UL是UE自己在发送PDU，自然是根据自己的设定确定PDU set和data burst等信息。QoS flow相关信息定下来后并且网络侧有配置相关assistance info，UE就可以通过UE assistance information向gNB指示相关信息。

图片

值得注意的是大多数 XR video帧速率(15、30、45、60、72、90 和 120 fps)对应的周期不是整数(分别为 66.66、33.33、22.22、16.66、13.88、11.11 和 8.33 ms)。gNB 可以配置以有理数表示的 DRX 周期，以便 DRX 周期与这些周期相匹配，例如，对于帧速率为 60 fps 的流量，网络可以为 UE 配置 50/3 ms 的DRX 周期。

网络侧可以配置configured grant，此时可以不配置UE醒来后还要监听进行configured grant UL 重传的grant的设定，这样可以进一步让UE省电。

L1/L2 enhancement for XR

引入了configured grant-based PUSCH传输：

(1)在 CG 配置的单个周期内支持多个 CG PUSCH 传输场合；

(2)指示CG配置中未使用的CG PUSCH场合，并在CG配置的CG PUSCH传输中复用UCI。

图片

为了增强 XR 上行资源的调度，引入了以下改进：

(1) 有设计一个额外的buffer size table，以减少BSR 报告中的量化误差（例如对于高比特率）：对于 LCG，除了常规表之外，是否可以使用新表由gNB 配置；另外当为 LCG 配置新表时，只要该 LCG 的缓冲数据量在新表的范围内，就会使用该表，否则将使用常规表。

(2)通过专用 MAC CE 进行缓冲数据的延迟状态报告 (DSR)：当任何缓冲的 PDCP SDU 在丢弃前的剩余时间低于配置的阈值（gNB 会为每个 LCG 配置的阈值）时，就会针对LCH触发；当为LCH触发时，UE要报告在丢弃前剩余时间低于配置阈值的缓冲数据量以及任何未在任何 MAC PDU 中传输的缓冲的PDCP SDU 的最短剩余时间。除此之外UE可以通过UE assistance info报告每个 QoS flow的UL辅助信息(例如jitter range、burst arrival time、UL data burst periodicity)。如果目标 gNB 在切换准备过程中从source gNB 接收到burst arrival time，则目标 gNB 可以通过考虑 source source gNB 的SFN offset来达到目的。

可能上面有关DSR的描述不是很清楚，这里在解释下为什么会有DSR。我们知道XR流量对延迟有严格要求，需要在请求的 PDB 或 PSDB 超时前传输。然而，某些UL场景下，gNB可能不知道UE bufffer data被discard的“remianing time",这样gNB就无法及时进行UL调度。因而就有了DSR，在UE需要传输紧急数据时，通过DSR可以向gNB指示remianing time，gNB得知后就可以优先调度相应数据来。

图片

在从支持基于PDU set处理的gNB切换到另一个gNB期间，如果目标节点已在 Xn 切换请求确认消息中发出信号表示支持基于PDU set的处理，则source gNB 通过 Xn-U 发出PDU set信息信号。

在切换期间，从RRC_INACTIVE过渡到RRC_CONNECTED或从不支持基于PDU set处理的gNB到支持基于PDU set处理的gNB进行RRC重建，目标/新服务gNB 可以在Path Switch Request过程或Handover resource Allocation过程(NG 切换的情况下)期间向 SMF 指示支持基于 PDU set的处理。如果没有指示，那SMF 就会认为target gNB node不支持基于 PDU set的处理。

在切换期间，从RRC_INACTIVE到RRC_CONNECTED的转换或从不支持基于PDU set的处理的gNB节点到支持基于PDU set的处理的gNB节点的RRC重新建立，target gNB node可以接收从source gNB node转发的未标记的PDU(即没有PDU set information container的 PDU)以及从UPF转发的标记的PDU(即具有 PDU set information container的 PDU)，那具体target gNB node如何处理同一QoS flow的标记和未标记的PDU就取决于实现(......)。

相信到这里对XR相关的概念以及逻辑已经有所了解，那这篇到这里就结束了，接下来我们继续来看下L1/L2 enhancement具体是怎么回事。 

星球帖子合集链接二维码如下(不需要登录飞书即可查看)：