UE和XR之间的PDU set和数据burst

PDU集错误率（PSER：PDU Set Error Rate）定义了已由链路层协议的发送方（例如，3GPP接入的RAN中的RLC）处理但未由相应的接收方成功地传送到上层（PSER定义了非拥塞相关分组丢失率的上限。PSER的目的是允许适当的链路层协议配置（例如，3GPP接入的RAN中的RLC和HARQ）。

但什么是PDU set的成功交付。对于解码基于“all-or-nothing”的PDU set，标准相对简单，因为这些PDU set的成功解码需要将PDU集中的所有PDU发送到应用程序。对于用AL-FEC编码的PDU集，人们可能会争论它们是否应该具有与“all-or-nothing”相同的标准，或者只要传送到应用程序的PDU的数量足以解码PDU集，它们的传送就应该被视为成功。后者应该是正确的答案，因为这是AL-FEC的目的。否则，无需引入PDU集综合处理指示（PSIHI： PDU Set Integrated Handling Indication）。

协议同意MAC和RLC重传/传输基于单个PDU而不是PDU集。因此，链路层协议参数（例如RLC定时器和HARQ的BLER目标）的配置更直接地取决于每个PDU定义的PER，而不是每个PDU集定义的PSER。

然而，CN为具有PDU集的QoS流提供PSER而不是PER到RAN。对于具有不同PDU集综合处理指示（PSIHI）的PDU集，RAN可能或可能无法从PSER导出PER，这取决于它们具有哪种类型的PSIHI。

对于其解码需要“all-or-nothing”的PDU集，如果RAN知道PDU集中PDU的平均数量，则RAN能够（从数字上）从所提供的PSER导出PER，因为这三个数量之间存在分析关系。由于RAN能够确定平均PDU集大小，例如基于来自发信号通知的PDU集大小的统计，因此RAN可以导出PER，然后使用PER来确定相应的链路层参数和定时器。

另一方面，对于用AL-FEC编码的PDU集，对于给定的PSER，RAN需要知道PDU集中PDU的平均数量和FEC码率，以便从数值上导出PER。然而，由于PSIHI中当前不包括FEC码率，RAN将无法基于CN提供的PSER导出PER。在这种情况下，测量也无法帮助，因为RAN可以基于丢弃的PDU来测量PER，但在不知道FEC码率是什么的情况下，无法将其映射到PSER。出于同样的原因，RAN不能基于丢弃PDU的统计来测量实际PSER是什么，因为如果它不知道FEC码率，它将无法确定PDU集是否被成功传递。

因此，基于上述分析，对于基于PDU集的AL-FEC，除了CN当前向RAN提供的内容之外，RAN还需要FEC码率的内容，以便从所提供的PSER导出PER，以便相应地配置其链路层。

XR设备如何连接到3GPP网络可以有不同的架构。

例如，XR设备可以包括3GPP调制解调器，即XR应用和UE位于同一物理设备中。在这种情况下，XR应用程序生成的数据包通过某种类型的外围互连（例如PCI express）从应用程序处理器发送到调制解调器。高数据速率设备中的这种互连通常具有非常高的速度。例如，PCI express 4.0的数据速率为16~64 Gbps，因此通过PCI express的单个通道（每条通道以16Gbps运行）发送1MB数据只需0.5ms。因此，从UE的角度来看，视频帧中的PDU几乎同时到达（例如，PDU集合中的所有PDU到达具有30KHz SCS的载波上的相同时隙）。因此，可能不需要关注PDU集合内的抖动及其对层2协议的影响。

不同的示例是XR应用程序和UE可以位于不同的物理设备上。例如，XR应用程序在耳机中运行，而UE位于智能手机中。它们通过无线链路（如WiFi或蓝牙）连接。在这种情况下，可能有两种不同的可能性：

• 方案1。UE的主机（智能手机）充当一个简单的中继站，仅向XR应用程序转发流量。在这种情况下，无线系留链路可以向UE接收的业务引入不合格的延迟、抖动和重新排序。

• 方案2。UE的主机也参与XR数据的渲染，因为它可能比XR设备具有更多的处理能力。在这种情况下，是UE主机上的应用处理器生成UE接收的PDU。因此，UE在其接收的业务中看到与上述同位置情况相同的延迟和抖动。

在一些使用情况下（例如XR设备通过无线链路连接到UE），PDU可能以不可忽略的抖动到达SDAP。

上述观察结果对PDCP丢弃计时器的建模/配置有影响。PDCP丢弃应该基于每个PDU集执行，并且在某些使用情况下，UL PDU集中的PDU之间可能存在抖动，PDCP丢弃计时器应该是每个PDU集而不是每个PDU。

当UL流量中存在抖动时，网络了解其存在和统计信息是有用的，因为这可以帮助网络更好地配置UE的无线电资源。例如，当配置多场合CG时，网络可以使用抖动信息来选择可以帮助减轻由抖动引起的额外访问延迟的开始偏移。

在XR设备和UE不位于同一位置的情况下，UL PDU的抖动信息对于RAN是有用的，例如用于配置CG。

基于上述分析，在XR设备和UE不位于同一位置的情况下，UE向网络通知其UL抖动信息是有用的。

引入DL PDU集重要性是因为它可以帮助RAN优先考虑对应用程序更重要的PDU集，从而减轻拥塞对用户体验的负面影响。然而，协议只同意DL PDU集，因为UL PDU集的研究是层2的事情。

由于拥塞也发生在上行链路上，并且可以说比下行链路上更可能发生，因此基于重要性指示的区分对于UL PDU集也是有用的。例如，对应用更重要的UL PDU集可以被赋予比其他PDU集更高的调度优先级，以确保它们有更多的机会满足延迟预算要求。

网络和UE可以执行以下操作以启用QoS流中UL PDU集的重要性指示。在当前的PDU集框架中，当网络建立QoS流时，它指示该流是否与PDU集相关联。对于这样的流，UPF然后基于其上层协议报头中携带的信息，用重要性指示来标记PDU集。类似的步骤也可以在UL上执行，即，对于与PDU集相关联的QoS流，UE可以使用UPF在识别DL PDU集重要性方面的相同方法来识别UL PDU集的重要性。然后，如果网络将UE的层2协议配置为支持不同的重要性级别，则UE随后使用所识别的UL PDU集的重要性信息来相应地处理它们。

通过上行链路上的重要指示，UE/RAN可以根据不同PDU集对应用的重要性来不同地处理不同的PDU集。例如，可能希望为具有高重要性的PDU集提供更高的可靠性，例如通过使用不同的PDCP丢弃定时器和RLC定时器，或者通过具有不同LCP优先级和/或LCP限制的专用逻辑信道来支持它们。

CN在数据突发到RAN的GTP-U报头中的最后PDU的报头中提供数据突发结束指示。RAN可以出于省电的目的使用该指示，例如，一旦数据突发结束，就终止UE的DRX活动时间。

类似的突发结束指示对于上行链路也非常有用，特别是对于以上行链路为中心的流量的XR应用。网络通常不知道上行链路上的数据突发何时结束，因为XR流量中数据突发的大小随时间而变化，并且不可预测。然而，在许多使用情况下（或通过实现），UE能够在数据突发结束时从XR应用程序获得指示。如果UE能够向网络提供该指示，则网络可以提前终止UE的DRX活动时间，从而在下一个突发之前给UE更多的睡眠时间。

在以UL为中心的业务的情况下，UE的突发结束指示可以帮助网络提前终止DRX活动时间，从而节省UE功率。

UE可以有多个选项来向网络发送突发结束的信号。例如，UE可以在用户面中（即，在L2PDU的报头中）发信号通知它，或者使用专用L1/L2信令。

在一些部署使用情况下，XR应用程序和UE可能不在同一物理设备中，它们通过无线链路（例如WiFi或蓝牙）连接。在这种情况下，在DL DPU集遍历UE的层2协议栈之后，UE必须通过无线链路将其转发到应用接收器。如果该无线链路使用随机接入协议或在未经许可的频带上运行，则其传输会受到延迟和抖动的影响。因此，当链路接入中存在拥塞时，UE必须决定如何对PDU进行优先级排序，以及是否丢弃那些不太重要或在错过其延迟期限后已过时的PDU。这与RAN在向UE转发DL PDU集时面临的挑战相同。因此，正如RAN需要关于DL PDU集的信息一样，UE也需要关于DL PDU集的信息。