针对XR服务的容量提升
为了提高XR服务的容量，可以从新的BSR表、延迟状态报告（delay status reporting）和配置的授权增强。
新建BSR表
可以基于三个参数定义新的BSR表：缓冲区大小的最小值和最大值以及编码点的总数。这三个参数可以在规范中预定义或通过动态信令（例如RRC配置）提供给UE。从UE的角度来看，动态信令将要求UE在从网络接收到一组新的BSR表参数之后动态地计算BSR表。这增加了UE的实现复杂性和计算负担。
此外，新BSR表的目标范围是已知的，因为它只需要将视频帧的可能大小范围与公共/已知视频编码率相匹配。因此，几乎不需要动态生成新的BSR表。
合理的假设是，一些LCG（logical Channel Group），例如具有高业务量的LCG，可以使用新的BSR表来利用其更高的分辨率。其他LCG，例如具有低数据速率的LCG，仍然可以使用传统BSR表，因为当缓冲区大小很小时，它具有非常小的步长。因此，为了保持增强型BSR MAC CE的格式简单，可以在新BSR表中具有与传统BSR表相同数量的编码点。
如上所述，不同的LCG使用不同的BSR表是有益的，以利用所有表（增强型和传统型）所能提供的最佳范围/分辨率。为了实现这一点，网络可以配置LCG应该使用哪个BSR表来编码和报告其缓冲区大小。
预计新的BSR表将具有比旧表更短的范围（否则，在相同的编码点数量下，其分辨率不能更高）。因此，LCG必须同时使用新的和旧的BSR表，这取决于其缓冲区大小。更具体地说，如果其缓冲区大小在BSR表的范围内，则使用新的BSR表。否则，将使用旧版本。
出于上述相同的原因，增强型BSR MAC CE需要包括新字段（例如，如果仅定义了一个新BSR表，则为新位图），以指示LCG已使用哪个BSR表来编码其缓冲区大小。否则，网络将无法知道使用哪个BSR表来解码LCG的缓冲区大小。
延迟状态报告（DSR：Delay status reporting ）
哪个实体应该报告DSR？例如，它应该是每个LCG还是每个LCH（logical Channel）。一般认为每个LCH可能不是必要的，特别是如果允许DRB拥有多个LCH。出于LCG用于BSR报告的相同原因，认为网络可能只会将具有兼容优先级（时延要求）的LCH分组到同一LCG中。因此，LCG可以是DSR报告实体的一个好选择。
XR应用程序可以生成不同类型的流。一些流具有严格的时延要求，而其他流则没有。对于那些没有严格时延要求的流，它们可能不需要报告其延迟状态，即使这样的报告是由另一个流触发的。因此，网络可以配置哪些LCG应报告其延迟状态。并非每个LCG都需要在DSR中报告其延迟状态。
对于XR业务的延迟要求（例如15毫秒），这不是非常紧急的，UE没有必要在其PUSCH传输中包括DSR。相反，网络可以为LCG配置触发DSR的时间阈值，即，如果在对应于LCG的层2缓冲器中缓冲的数据中的最大剩余时间低于配置的时间阈值时，UE触发DSR。
关于剩余时间，它可以被定义为PDU或PDU set的剩余延迟预算，即从当前时间到延迟截止时间的持续时间。PDU集合中的PDU的延迟截止时间可以定义为PDU集合中第一个接收到的PDU的时间加上相应QoS flow的PSDB。对于其他类型的PDU，延迟截止时间定义为PDU的到达时间加上其相关QoS流的PDB。
除了由时间阈值触发的DSR，还可以有其他类型的DSR触发。例如，DSR的另一个触发器可以是移动性事件。例如，在UE切换到新小区之后，目标小区可能不知道UE的延迟状态。如果UE具有剩余数据低于阈值的数据，则它应该触发DSR并将其发送到目标小区。
具有定时器触发的DSR也是有用的，因为BSR可以由事件和定时器触发。
DSR的基本目的是通知网络时延接近截止日期的数据量。当发送DSR时，UE应利用该机会报告被配置用于延迟状态报告的所有LCG的延迟状态，而不仅仅是其数据触发该DSR的LCG。
根据报告的首选粒度，网络可以配置一个或多个报告阈值。UE然后报告剩余时间低于报告阈值的数据量。例如，假设网络配置了两个报告阈值T1和T2，其中T1＜T2。然后，UE报告剩余时间短于T2的数据量以及剩余时间在T1和T2之间的数据量。
用于确定每个报告阈值的数据量的剩余时间可以不同于触发DSR的剩余时间，因为通常在触发DSR时的时间和通过PUSCH发送DSR的时间之间存在额外的延迟。
CG（Computer Animation）增强
物理层已同意在每个时段引入多场合CG。
首先，这种新型CG配置适用于type-1和type-1 CG。
要指定多场合CG，需要两个新参数：一个周期内的场合之间的周期性和每个周期的场合数。
对于第一个参数，最好允许一个时间段内的事件之间有一个可配置的时间间隔，而不是限制一个时间内的所有事件都是连续的。当突发内的数据没有背靠背到达或者分组之间存在抖动时，这种灵活性允许更有效地使用UL无线资源。该参数可以由RRC配置，因为不需要动态采用该参数。
第二个参数，即每个周期的次数，可以将RRC配置为基线。然而，允许动态适应的进一步增强值得讨论。众所周知，许多XR应用响应于网络条件的波动而动态地采用其编码速率或帧速率。由于每个周期的出现次数直接取决于视频帧大小，而视频帧大小又直接取决于编码速率，因此从时延减少和容量改善的角度来看，动态采用该参数是有用的。例如，网络可以预先配置一组大小，然后使用MAC CE动态地指示每个周期的次数。
引入多场合CG的一个关键动机是，只需要一个CG配置就可以支持具有周期性突发的XR流量。然而，众所周知，XR流量具有非整数周期性，这与当前CG配置不匹配。多场合CG也存在同样的问题。
在传统中，基于使用CG配置的周期性、时机的时间位置和为CG配置的HARQ进程的数量的公式来确定CG时机的HARQ process ID。现在使用多场合CG，配置中可以有两个周期。因此，需要重新考虑HARQ process ID的公式。
可以有不同的选项。例如，可以采用在多TB DCI中使用的设计，即重用传统公式来确定CG中第一次的HARQ process ID。然后，以该process ID为起点，HARQ process ID对于每个后续情况递增1，直到达到HARQ进程的数量或下一周期的开始。另一种选择是重复使用传统公式，但用一段时间内的周期性来替换公式中的CG周期性。我们认为后者的计算更简单，对现有规范的更改也更少，因此更可取。
如果UE已经发送了针对CG时机的跳过指示，则即使存在符合CG条件的后续数据，也不应允许UE继续使用该时机，因为网络可能已经为其他授权或其他用户重新分配了该无线资源。
一些XR业务流可能需要具有非常短周期的CG，例如姿态或控制消息，或每个周期具有多个场合的CG。在这种情况下，对于UE来说，在每个CG场合指示跳过是更昂贵的。或者在网络配置多个CG并且这些CG具有重叠的场合的情况下，UE为这些CG中的每一个发送跳过指示是非常低效的。因此，跳过指示可以对应于CG的多个连续场合或多个CG的重叠场合。
当配置Rel-16增强型UL跳过时，如果UCI与PUSCH场合重叠，则UE需要在该PUSCH上复用UCI，即使UE没有符合使用PUSCH的数据（即，必须发送伪TB）。这种行为对于UE来说是低效的，但避免了gNB在同一时隙中对PUCCH和PUSCH进行盲解码。
然而，如果为UE配置了用于CG的跳过指示，则可以避免这种低效。更具体地，如果UE具有其PUCCH时机与CG时机重叠的UCI并且不具有任何符合CG时机的UL数据，则UE在CG时机之前发送UL跳过指示。然后网络知道UE不会通过PUSCH传输任何内容，并且它只需要解码PUCCH。对于UE，它仍然可以通过PUCCH传输UCI，并且不需要PUSCH传输。该行为消除了gNB侧的解码模糊性，并且与Rel-16行为相比。
在XR应用程序生成的流中，可以定期进行UL姿势更新。这些更新是频繁的（例如每4ms更新一次），通常大小较小（例如100B），并且具有严格的延迟要求（例如10ms PDB）。考虑到这些特殊特性，更明智的做法是让UE通过CG而不是动态UL授权来发送姿态更新。
使用CG发送周期性姿态更新的好处是，这些传输不会使UE保持在DRX活动时间。更具体地，一旦突发（例如，视频流）结束，UE可以进入非活动状态以节省电力（例如，由网络终止或由DRX非活动定时器到期终止）。同时，UE仍然可以使用CG来继续发送姿态更新。
然而，这种配置的功率节省可能仍然有限。这是因为在CG上的每个PUSCH传输之后，UE需要启动HARQ RTT定时器，然后启动HARQ reTx定时器，以监控PDCCH的潜在重传。由于姿势更新的短周期性和HARQ reTx定时器的典型长度（例如几毫秒），UE将不能在两个DRX周期之间有太多的睡眠时间。下面的图1说明了这样一个示例及其缺点。
如图1所示，避免额外PDCCH监控的一种可能的增强是在CG上PUSCH传输之后禁用HARQ RTT定时器和HARQ reTx定时器。由于小的PDU大小和低的姿态更新比特率，可以在不依赖HARQ重传的情况下以良好的可靠性发送它们。例如，可以使用保守的MCS和高重复级别发送它们。
这种增强可以在每个CG的基础上实现，这取决于CG用于哪种类型的流。
