苹果专利探索5G实时扩展现实服务为XR提供有效资源分配调度

查看引用/信息源请点击：arstechnica

（XR导航网 2024年03月01日）作为具有高速率、低时延和大连接等特点的新一代宽带移动通信技术，5G通讯是实现人机物互联的网络基础，尤其是对正在发展中的XR而言。

在名为“Scheduling request (sr) enhancements for 5g real-time extended reality (xr) services”的专利申请中，苹果就提出了一种用于5G实时扩展现实服务的调度请求增强，从而为XR提供有效的资源分配和调度。

苹果指出，XR服务特征与周期性、各种流、抖动、延迟和可靠性等相关。通过用于5G实时扩展现实服务的调度请求增强，可以为XR服务特征提供有效的资源分配和调度。其中，有效的资源分配和调度可以使用半持久调度SPS、配置授权、动态调度、动态授权等机制来提供。

在一个实施例中，特定于XR服务的流量处理的示例可以包括由用户设备（UE）使用的缓冲区状态报告BSR过程，以提供有关UE希望在UL方向发送到基站的数据量的信息。根据终端上等待通过物理上行共享通道（PUSCH）在UL方向传输的数据量，基站可以根据PUSCH资源的可用性分配最小的UL授予量。

BSR过程可以使用5位或8位缓冲区大小字段来通知基站关于终端正在从基站请求UL授予的数据量。5位缓冲区大小字段可Table 6.1.3.1-1 of 3GPP Technical Specification (TS) 38.321所述使用，8位缓冲区大小字段可按Table 6.1.3.1-2 of 3GPP TS 38.321所述使用。

在建立了MAC协议数据单元PDU后，数据总量可以对应一个LCH组中所有LCH的数据。在一个示例中，在LCH优先化过程之后，缓冲区大小字段的值可以为零。数据量可以以若干字节表示。5位缓冲区大小字段可以对应短BSR格式，8位缓冲区大小字段可以对应长BSR格式。

因此，发明所述可以提供SR指示，使用例如SR多路复用、有效载荷串联等进行SR指示优化的解决方案。

图1显示了一个无线通信系统示例。如图1所示，无线通信系统100可以包括基站102和104以及UE 106。

UE 106可以具有与使用PUSCH在UL方向发送的与XR服务相关的流相关联的数据。因此，UE可以发送一个SR，并用于分配一个或多个RBs。RBs对应于与要在UL方向发送给LCH或LCG的与XR服务相关的流相关联的数据量。从基站102或104请求RBs的要向UL方向发送的数据量可以使用一个或多个比特来表示。

UE 106可以具有与对应于音频流和/或恒定比特率的数据流的XR服务流量相关的数据。因此，UE 106可以为SR指示使用单位SR缓冲区大小字段。

类似地，对于对应于暂停/控制流的XR服务流量，它可能具有恒定的比特率，UE 106可以使用单个SR缓冲区大小字段来表示SR指示。基站在接收到一个单比特SR指示后，可以根据预先确定的数据字节数分配RBs，以便向UL方向发送。预定的数据字节数可以根据与XR服务流量类型一致的恒定比特率来确定。

然而，与视频流相关的XR服务流量可能具有可变比特率，所以UE 106可能在SR指示中使用多个比特，例如5位或8位。另外，与视频流相关的XR服务流量可以遵循数据的分布。可以通过将缓冲区数据大小指示为量化的缓冲区数据大小来优化SR指示。缓冲区数据大小可以使用均匀量化器和/或非均匀量化器进行量化。

图2示出了SR多路复用的示例。物理上行控制通道(PUCCH)资源集或PUCCH资源列表可用于SR。如本文所述，不同的流可与不同的SR关联。因此，不同SR中的每个SR可能与不同的数据量或有效载荷大小相关联。另外，UE可以将数据发送到与一个或多个不同流相关联的UL方向。

在一个实施例中，分割成两个部分的SR的第一部分可以包括指示SR存在或不存在的位图，并且分割成两个部分的SR的第二部分可以包括与集成SR相关联的每个SR的连接的有效载荷。例如，位图值“10”可以指示单独的SR-1的存在，位图值“11”可以指示SR-1和SR-2的存在，等等。

如图200所示，SR Config-3 206包含PUCCH资源PUCCH-5 206a、PUCCH-6 206b和PUCCH-7 206c的PUCCH资源列表。基于流和/或XR服务场景，以及有效载荷大小，UE 106可以为SR- 3210选择PUCCH资源PUCCH-5 206a。

因此，当UE 106复用多个SR时，UE可以在多个阶段复用SR。所以如本文所述，除了1位SR之外，SR可以使用多个比特来报告与LCHs或与SR相关的LCG对应的更细粒度或附加信息。

另外，多个SR可以映射为一个组来构建一个复合SR。每个映射到积分SR的SR可以是一个1位SR，积分SR可以通过扩展每个1位SR的比特数来传递更多的信息。

在一个实施例中，一组1位SR可以与相同的LCH或LCG相关联，并且一组1位SR的不同SR可以与不同的优先级、不同的XR服务流量流和/或不同的QoS流相关联，从而允许更细粒度的优先级和/或识别/关联XR服务流量流，并改进资源分配。

例如，一组SR可能与与多个QoS流相关联的LCH相关联，并且每个QoS流可能使用自己的SR。另外，每个LCH或LCG的SR优先级可能由网络以这样一种方式分配，即具有需要进一步优先级的子流的LCH或LCG可以利用每个子流单独的SR资源。

图3示出，QoS流映射到基于集成SR的每个单独SR的各种子流的LCH和相应的集成SR。如图300所示，各种QoS流，例如QoS流1302、QoS流2304、QoS流3306、QoS流4308、QoS流5310、QoS流6312、QoS流7314、QoS流8316和QoS流9318，可以映射到不同的LCHs。

例如，QoS流1302、QoS流2304和QoS流3306可以映射到LCH LCH1320。类似地，可以将QoS流4308和QoS流5310映射到LCH LCH322，并且可以将QoS流6312和QoS流7314映射到LCH LCH324。

在这里，QoS流1-7是它们各自LCH的子流。QoS流8 316和QoS流9 318作为单独的流映射到LCH LCH4 326和LCH LCH5 328，而不是作为SR中的子流。

如图300所示，根据要在UL方向发送的数据，可能存在多个SR。因此，可由与LCH 1320和LCH2322相关联的终端生成SR调度请求330。

调度请求330可以基于多个SR，SR对应于各种子流，例如与LCH LCH1 320关联的QoS流1 302、QoS流2 304和QoS流3 306，以及与LCH LCH2 322关联的QoS流4 308和QoS流5 310。

调度请求330可以基于schedulingRequestResourceId的ID来标识，其中schedulingRequestResourceId标识与多个LCH中的一个或多个LCH相关联的调度请求配置。

调度请求332可以基于多个SR，SR对应于各种子流，例如与LCH LCH324相关联的QoS流6 312和QoS流7 314。SR 334和SR 336分别对应于LCH LCH326和328，但不与其他与其他流对应的其他SR集成，而是作为单独的SR 342和344分别发送，包括单个PUCCH资源标识为schedulingRequestResourceId6 342a和schedulingRequestResourceId 7 344a。

映射到LCH的每个QoS流可以具有相同或不同的优先级，并且其在集成SR中的相应SR可以基于与QoS流关联的优先级进行排序。

图8示出了可由用户设备执行的操作的流程图。

在802处，UE可以识别与要在上行链路UL方向发送的数据相对应的多个流。在UL方向上发送的数据会根据各自的XR服务流和/或QoS流具有不同的优先级。

在804中，UE可以将多个流的子集映射到多个逻辑通道的逻辑通道。例如，多个流的流子集(可以映射到LCH LCH1。

在806，,UE可以将两个或多个调度请求SR复用为一个集成SR，以形成一组SR，并用于请求一个或多个物理上行控制通道PUCCH资源。包含在集成SR中的每个SR可以对应于与多个流的子集的至少一个流相关联的数据的调度请求。

图9示出了可由基站执行的操作的示例流程图。

在902，基站可以向用户设备发送描述与多个逻辑信道中的至少一个逻辑信道相关联的调度请求SR优先级的配置。至少一个逻辑通道可以与映射到它的多个流或一个或多个流相关联。

在904，基站可从UE接收单个调度请求，用于请求与至少一个逻辑通道的多个流或一个或多个流相对应的一个或多个物理上行控制通道资源。如本文所述，所述集成SR可包括多个SR，所述集成SR中包含的每个SR可对应于用于与所述多个流的每个流相关联的数据的UL传输的SR。相应地，包含在集成SR中的第一个SR和第二个SR基于它们各自的流具有不同的优先级。

因此，发明描述的各种实施例可以在各种XR服务场景中对SR提供改进或增强。

名为“Scheduling request (sr) enhancements for 5g real-time extended reality (xr) services”的苹果专利申请最初在2022年8月提交，并在日前由美国专利商标局公布。

需要注意的是，一般来说，美国专利申请接收审查后，自申请日或优先权日起18个月自动公布或根据申请人要求在申请日起18个月内进行公开。注意，专利申请公开不代表专利获批。在专利申请后，美国专利商标局需要进行实际审查，时间可能在1年至3年不等。

另外，这只是一份专利申请，不代表一定通过，同时不确定是否会实际商用及实际的应用效果。