LTE上行调度请求SR.docxVIP

} } LTE：上行调度请求( Scheduling Request， SR) (2012-12-27 21:33:51) 转载▼ 标签： 分类： LTE lte sr schedulingrequest 上行调度请求 上行调度请求( Scheduling Request ， SR) 如果 UE 没有上行数据要传输， eNodeB 并不需要为该 UE 分配上行资 源，否则会造成资源的浪费。因此， UE 需要告诉 eNodeB 自己是否有上 行数据需要传输，以便 eNodeB 决定是否给 UE 分配上行资源。为此 LTE 提供了一个上行调度请求( Scheduling Request ， SR)的机制。 UE 通过 SR 告诉 eNodeB 是否需要上行资源以便用于 UL-SCH 传输， 但并不会告诉 eNodeB 有多少上行数据需要发送 (这是通过 BSR 上报的)。 eNodeB 收到 SR 后，给 UE 分配多少上行资源取决于 eNodeB 的实现， 通常的做法是至少分配足够 UE 发送 BSR 的资源。 eNodeB 不知道 UE 什么时候需要发送上行数据， 即不知道 UE 什么时 候会发送 SR。因此， eNodeB 需要在已经分配的 SR 资源上检测是否有 SR 上报。 在载波聚合中， 无论配置了多少个上行载波单元 ( component carrier )， 都只需要 1个 SR 就够了，毕竟 SR 的作用只是告诉 eNodeB ，本 UE 有上 行数据要发送了，你看着给点上行资源吧！由于 PUCCH 只在 PCell 上发 送，而 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 的周期是通过 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 ::= CHOICE { release NULL, setup SEQUENCE { sr-PUCCH-ResourceIndex INTEGER (0..2047), sr-ConfigIndex INTEGER (0..157), dsr-TransMax ENUMERATED { n4, n8, n16, n32, n64, spare3, spare2, spare1} } } SchedulingRequestConfig-v1020 ::= SEQUENCE { sr-PUCCH-ResourceIndexP1-r10 INTEGER (0..2047) OPTIONAL -- Need OR UE 在某些情况下可能没有 SR 资源。场景一：从 36.331 可以看出， SchedulingRequestConfig 是一个 UE 级的可选的 IE（optional ），默认为 release 。如果 eNodeB 不给某 UE 配置 SR （这取决于不同厂商的实现） ， 则该 UE 只能通过随机接入过程来获取 UL grant （在 RAR 中分配）。是否 配置 SR 主要影响用户面的延迟，并不影响上行传输的功能！ 场景二：当UE 丢失了上行同步， 它也会释放 SR资源，如果此时有上 行数据要发送，也需要触发随机接入过程。 从上面的描述可以看出， 当 UE 没有被分配 SR 资源时， 基于竞争的随 机接入过程可以替代 SR 的功能用于申请上行资源。但这只适用于低密集 度的上行资源请求的情况。 从 36.213 的 10.1.1 节可以看出， 只有 PUCCH form