LTE：上行调度请求

1、LTE：上行调度请求( Scheduling Request ，SR)上行调度请求( Scheduling Request ， SR)如果 UE 没有上行数据要传输， eNodeB 并不需要为该 UE 分配上行资源， 否则会造成资源的浪费。因此， UE 需要告诉 eNodeB 自己是否有上行数 据需要传输， 以便 eNodeB 决定是否给 UE 分配上行资源。 为此 LTE 提供 了一个上行调度请求( Scheduling Request ， SR)的机制。UE 通过 SR 告诉 eNodeB 是否需要上行资源以便用于 UL-SCH 传输，但 并不会告诉 eNodeB 有多少上行数据需要发送

2、(这是通过 BSR 上报的)。 eNodeB 收到 SR 后，给 UE 分配多少上行资源取决于 eNodeB 的实现， 通常的做法是至少分配足够 UE 发送 BSR 的资源。eNodeB 不知道 UE 什么时候需要发送上行数据，即不知道 UE 什么时候 会发送 SR 。因此， eNodeB 需要在已经分配的 SR 资源上检测是否有 SR 上报。在载波聚合中， 无论配置了多少个上行载波单元 ( component carrier )， 都只需要 1个SR就够了，毕竟 SR的作用只是告诉 eNodeB ，本UE有上 行数据要发送了，你看着给点上行资源吧！由于PUCCH只在 PCell 上发送，而

3、SR 只在 PUCCH 上发送，也就是说， SR 只在 PCell 上发送。本文并不介绍 SR 如何编码并在 PUCCH 上传输，这会在以后的 PUCCH 专 题中予以介绍。需要明确的是， 只有处于 RRC_CONNECTED 态且保持上行同步的 UE 才 会发送 SR；且 SR 只能用于请求 新传数据（而不是重传数据） 的 UL-SCH 资源。UE 是因为没有上行 PUSCH 资源才发送 SR 的，所以 UE 只能在 PUCCH 上发送 SR 。eNodeB 可以为每个 UE 分配一个专用的 SR 资源用于发送 SR。该 SR 资源是周期性的， 每 n 个子帧出现一次。 SR 的周期是通过

4、IE ： SchedulingRequestConfig 的 sr-ConfigIndex 字段配置的。由于 SR 资源是 UE 专用且由 eNodeB 分配的，因此 SR 资源与 UE 一一 对应且 eNodeB 知道具体的对应关系。 也就是说， UE 在发送 SR 信息时， 并不需要指定自己的 ID （C-RNTI ）， eNodeB 通过 SR 资源的位置，就 知道是哪个 UE 请求上行资源。 SR 资源是通过 IE ： SchedulingRequestConfig 的 sr-PUCCH-ResourceIndex 字段配置的。SchedulingRequestConfig := CH

5、OICE release NULL, setup SEQUENCE sr-PUCCH-ResourceIndex INTEGER (0.2047), sr-ConfigIndex INTEGER (0.157), n4, n8, n16, n32, n64, spare3, spare2, spare1SchedulingRequestConfig-v1020 := SEQUENCE sr-PUCCH-ResourceIndexP1-r10 INTEGER (0.2047) OPTIONAL - Need ORUE 在某些情况下可能没有 SR 资源。场景一：从 36.331 可以看出， Sch

6、edulingRequestConfig 是一个 UE 级的可选的 IE （ optional ），默认 为 release 。如果 eNodeB 不给某 UE 配置 SR（这取决于不同厂商的实现） ， 则该 UE 只能通过随机接入过程来获取 UL grant （在 RAR 中分配）。是 否配置 SR 主要影响用户面的延迟，并不影响上行传输的功能！ 场景二：当 UE 丢失了上行同步，它也会释放 SR 资源，如果此时有上行 数据要发送，也需要触发随机接入过程。从上面的描述可以看出，当 UE 没有被分配 SR 资源时，基于竞争的随机 接入过程可以替代 SR 的功能用于申请上行资源。但这只适用于低密

7、集度 的上行资源请求的情况。从 36.213 的 节可以看出，只有 PUCCH format 1 （包含 PUCCH format 1/1a/1b )和 PUCCH format 3 可用于发送 SR。其中 sr-PUCCH-ResourceIndex 指定了 UE 在哪个 PUCCH format 1 资源上发送 SR。SR 资源用表示， 其值与 PUCCH format 1的资源索引 相等 如果在同一子帧上，需要同时发送 SR 和 PUCCH format 3 （ HARQACK/NACK ），则 SR 会复用到 PUCCH format 3 发送中（处理方式见 36.212 的 节），而

8、不是在 sr-PUCCH-ResourceIndex 指定的 PUCCH format 1资源上发送。 （关于 PUCCH资源，这里就不做详细说明了， 我会在以后 的博客中予以介绍）sr-ConfigIndex 指定了 SR 的传输周期 和 SR 在该周期内 的子帧偏移 ，对应 36.213 的 Table 。满足如下条件 的上行子帧才能够用于发送 SR：其中 为系统帧号； 为一个系统帧内的 slot 号，取值范围为 019 ；从上面的公式可以看出， 保证了每个 UE 对应的 SR 资源在每 个子帧只出现一次（但 UE 只在有上行数据要发 送却没有上行资源时，才用该资源来发送 SR）。指定了每

9、 个 UE 对应的 SR 资源在其周期内的第几个子帧发送。SR 资源配置如图 1 所示：图 1：SR 资源可以看出， sr-ConfigIndex 和 sr-PUCCH-ResourceIndex 共同决定了一 个唯一的 SR 资源。该资源只能分配给一个 UE ，但只有当 UE 有上行数据 需要发送但却没有上行资源时才会被使用。图2是SR周期配置的一个例子， 3个UE 的周期都为 10ms，但在周期内的子帧偏移各不相同图 2 ：SR 周期配置的一个例子当有上行数据到达并触发 SR时，UE 会选择分配给它的下一个可用的 SR 资源来发送 SR。如图 3 所示：图 3：SR 传输UE 发送 SR

10、以后，无法确定 eNodeB 什么时候会下发 UL Grant ，这取决 于上行资源的调度以及优先级等。如果 UE 等待超时（超时时间由 sr-ProhibitTimer 决定）就重发 SR ，重发次数超过了 SR 的最大重传次 数（由 IE ：SchedulingRequestConfig 的 dsr-TransMax 决定）就会触 发随机接入。 （见 36.321 的 节） 通常， SR 机制是针对整个 UE 的所有逻辑信道的，但在 Rel-9 中， LTE还提供了一种基于逻辑信道进行 SR 请求的机制。对于 eNodeB 创建的每 一个逻辑信道，都有一个 logicalChannelSR-Mask-r9 字段，用于指定当 该逻辑信道有新数据到达时，是否触发 SR。参考资料】1 TS 36.213的 10.1.5 节 介绍 SR 资源2 TS 36.321的 5.4.4