LTE：上行调度请求（Scheduling Request，SR） LTE：下行资源分配类型

标签：

http://blog.sina.com.cn/s/blog_927cff010101a7yh.html

上行调度请求（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 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（HARQ ACK/NACK），则SR会复用到PUCCH format 3发送中（处理方式见36.212的5.2.3.1节），而不是在sr-PUCCH-ResourceIndex指定的PUCCH format 1资源上发送。（关于PUCCH资源，这里就不做详细说明了，我会在以后的博客中予以介绍）

      sr-ConfigIndex指定了SR的传输周期和SR在该周期内的子帧偏移，对应36.213的Table 10.1.5-1。满足如下条件的上行子帧才能够用于发送SR：

      其中为系统帧号；为一个系统帧内的slot号，取值范围为0~19；的值对应子帧号。

      从上面的公式可以看出，保证了每个UE对应的SR资源在每个子帧只出现一次（但UE只在有上行数据要发送却没有上行资源时，才用该资源来发送SR）。指定了每个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以后，无法确定eNodeB什么时候会下发UL Grant，这取决于上行资源的调度以及优先级等。如果UE等待超时（超时时间由sr-ProhibitTimer决定）就重发SR，重发次数超过了SR的最大重传次数（由IE：SchedulingRequestConfig的dsr-TransMax决定）就会触发随机接入。（见36.321的5.4.4节）

      通常，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节      介绍SR流程

[3]      TS 36.331的6.3.2节      IE: SchedulingRequestConfig

[4]      《4G LTE/LTE-Advanced for Mobile Broadband》的13.2.2.2节

[5]      《LTE - The UMTS Long Term Evolution, 2nd Edition》的16.3.7节

http://blog.sina.com.cn/s/blog_927cff010101a042.html

http://blog.sina.com.cn/s/blog_927cff010101a05x.html

下行资源分配类型

      本文主要介绍下行物理信道PDSCH的3种资源分配类型：Type 0、Type 1和Type 2。

      具体使用哪种资源分配类型取决于所选的DCI format以及DCI内相关bit的配置。

      每种DCI format支持哪种资源分配类型，以及有哪些与资源分配相关的bit，详见36.212的5.3.3节。由于这篇文章主要是介绍几种下行资源分配类型，而不是介绍DCI format的，所以文章中只是略微提及，并不做深入分析。

      图1是几种下行DCI format与下行资源分配类型的对应关系：

图1：DCI format与下行资源分配类型的对应关系

      注意：（1）下行资源是基于VRB而是PRB分配的。当然，VRB与PRB有一定的对应关系，详见36.211的6.3.2节；（2）DCI format 1/2/2A/2B/2C同时支持Type 0和Type 1，具体使用哪种类型是通过1比特的域（见图3）来指定的。

一、RBG介绍

      介绍资源分配类型Type 0和Type 1之前，需要先介绍一下RBG的概念。

      RBG（Resource Block Group，资源块组）是一组连续的集中式VRB（localized VRB）。RBG的大小（P，即每个RBG中包含的VRB数。最后一个RBG包含的VRB数可能小于P）与系统带宽相关，对应关系见图2：

图2：RBG size与下行系统带宽的关系（36.213的Table 7.1.6.1-1）

      对应下行系统带宽，RBG的总数为：

      其中，前个RBG的大小为P；如果 % P > 0，则最后一个RBG的大小为。

      以下行系统带宽 = 50 RB为例，其P值为3，RBG的总数为17，前16个RBG各包含3个VRB，最后一个RBG只包含2个VRB。

二、资源分配类型0（Resource allocation type 0）

      在资源分配类型0中，DCI format 1/2/2A/2B/2C通过一个bitmap来指示分配给UE的RBG。bitmap共包含比特，每1比特对应1个RBG，最高位表示RBG 0，最低位表示RBG   - 1，依此类推。如果某个RBG分配给了某个UE，则bitmap中对应比特置为1；否则置为0。

图3：DCI format 1/2/2A/2B/2C中与Type 0相关的字段

      以小区系统带宽25 RB为例。

      1）通过查36.213的Table 7.1.6.1-1可以知道，RBG大小P = 2；

      2）RBG的总数。其中前12个RBG的每个RBG大小为2，最后一个RBG的大小为1（如图4所示）；

图4：资源分配类型0的RBG资源（25 RB）

      3）即bitmap共包含13比特。

      4）假如分配给某UE的资源的bitmap为：1001110100010，则该UE被分配了RBG 0、RBG 3、RBG 4、RBG 5、RBG 7、RBG 11（如图5所示）。

图5：资源分配类型0的例子（25 RB）

      从上面的例子可以看出：1）资源分配类型0支持频域上的非连续RB分配；2）调度的粒度比较粗：调度的最小单位是RBG，对于较大的带宽而言，无法按照单个RB来分配资源。当payload较小时，可能会造成资源的浪费。

三、资源分配类型1（Resource allocation type 1）

      在资源分配类型1中，所有的RBG被分为P个子集，P为RBG的大小（见图2）。每个RBG子集p（）包含从RBG p开始，间隔为P的所有RBG。分配给某个UE的VRB资源必须来自于同一个子集。

      在资源分配类型1中，DCI format 1/2/2A/2B/2C通过3个域来指示分配给UE的VRB（注意：与资源分配类型0不同，这里是VRB，而不是RBG）。

图6：DCI format 1/2/2A/2B/2C中与Type 1相关的字段

      第一个域包含比特，用于指定所选的RBG子集，即p的值。

      第二个域包含1比特（shift bit），用于指定子集内的资源是否偏移，1表示偏移，0表示不偏移。

      第三个域包含一个bitmap，bitmap的每一比特对应所选RBG子集中的一个VRB（注意：不是RBG）。最高位表示子集中的第一个VRB，最低位表示子集中的最后一个VRB，依此类推。如果某个VRB分配给了某个UE，则bitmap中对应比特置为1；否则置为0。bitmap的大小，即bitmap包含的比特数为

      一个选定的RBG子集中的VRB起始于该子集中的最小VRB号 + 偏移量，并对应bitmap中的最高位。该偏移量以VRB的数量表示，并且是发生在选定的RBG子集内的偏移。如果DCI的资源块分配信息中的第二个域为0，则RBG子集p的偏移；如果DCI的资源块分配信息中的第二个域为1，则RBG子集p的偏移，且bitmap中的最低比特位调整为对应RBG子集中的最后一个VRB。

      为RBG子集p包含的VRB数，计算公式如下：

      对于RBG子集p而言，其bitmap中的每一比特i（）对应的VRB可通过如下公式计算：

      关于偏移可能较难理解，莫急，对照后面的例子来学习，会比较清晰的。

      还是以小区带宽25 RB为例。

      1）通过查36.213的Table 7.1.6.1-1可以知道，P = 2，即有2个子集：子集0（从RBG0开始）和子集1（从RBG1开始）；

图7：资源分配类型1中的子集（25 RB）

      2） = 1，即第一个域使用1比特指定所选的RBG子集；

      3）第二个域使用1比特指定RBG子集中的资源是否偏移；

      4）bitmap包含的比特数 = 13 -1 -1 = 11；即bitmap只能对应11个VRB。

      5）每个RBG子集p包含的VRB数为

      可以看出，bitmap不足以表示每个子集中包含的所有VRB。

      6）接下来，我们详细介绍第二个域，即shift bit对bitmap所表示的VRB的影响。

      如果shift bit为0，RBG子集p的偏移；

      如果shift bit为1，RBG子集p的偏移为

     从之前的分析可以看出，每个子集包含哪些RBG是确定的，也就是说，包含哪些VRB也是确定的。对应图7，每个子集可用的VRB集合如图8所示：

图8：资源分配类型1中每个子集可用的VRB集合（25 RB）

      当shift bit = 0时，根据下面的公式，可知道bitmap（对于25RB带宽，共11比特）的每一个比特对应哪个VRB。

      结果如下：

图9：每个子集的bitmap中的每个比特对应的VRB（25 RB, shift bit = 0）

      从图9可以看出，如果shift bit = 0（不发生偏移），每个子集的bitmap对应的VRB，是从图8给定的VRB集合中的第一个VRB开始（对应子集0，起始VRB为VRB0；对应子集1，起始VRB为VRB2），顺序选取11个VRB。

      当shift bit = 1时，根据下面的公式，可知道bitmap（对于25RB带宽，共11比特）的每一个比特对应哪个VRB。

      结果如下：

图10：每个子集的bitmap的每个比特表示的VRB（25 RB, shift bit = 1）

      从图10可以看出，如果shift bit = 1（发生偏移），每个子集的bitmap对应的VRB，是从图8给定的VRB集合中的第一个VRB，加上偏移量开始（对应子集0，偏移量 = 2，即在图8给定的p = 0的VRB集合中，往前移2个，得到起始VRB为VRB4；对应子集1，偏移量 = 1，即在图8给定的p = 1的VRB集合中，往前移1个，得到起始VRB为VRB3），顺序选取11个VRB。

      图11介绍了使用资源分配类型1的例子（25 RB）：

      上半部分对应：资源分配类型1；子集0；shift bit 为0；bitmap 为10011101000。即分配该UE的资源为：VRB0、VRB5、VRB8、VRB9、VRB13。

      下半部分对应：资源分配类型1；子集0；shift bit 为1；bitmap 为10011101000。即分配该UE的资源为：VRB4、VRB9、VRB12、VRB13、VRB17。

图11：资源分配类型1的例子（25 RB）

      关于资源分配类型1的更多例子，还可以参考[6]。

      从上面的例子可以看出：1）资源分配类型1支持频域上的非连续RB分配；2）和资源分配类型0相比，资源分配类型1支持粒度为1 RB的分配；3）资源分配类型0和资源分配类型1使用相同的bit数来表示资源的分配；4）bitmap的比特数实际上比RBG子集中的VRB数要少，通过shift bit，bitmap才能覆盖所有的VRB。

三、资源分配类型2（Resource allocation type 2）

      在资源分配类型2中，分配给UE的资源为一段连续的VRB，其VRB可以是集中式（localized），也可以是分布式的（distributed）。

      对于DCI format 1A/1B/1D而言，有一个bit（对应Localized/Distributed  VRB assignment flag）用于指示是集中式VRB（该bit为0）还是分布式VRB（该bit为0）。

图12：DCI format 1A中与Type 2相关的字段 

      对于集中式VRB分配而言，分配给一个UE的资源可以从1个VRB到整个系统带宽的所有VRB。

      如果DCI format 1A使用分布式VRB分配方式，且其DCI的CRC由P-RNTI、RA-RNTI或SI-RNTI加扰，则分配给对应UE的VRB数可以从1个到个。（的计算见36.211的6.2.3.2节，这里就不做介绍了）

      如果DCI format 1A/1B/1D使用分布式VRB分配方式，且其DCI的CRC由C-RNTI加扰，则当下行带宽为6~49 RB时，分配给对应UE的VRB数可以从1个到最多个；则当下行带宽为50~110 RB时，分配给对应UE的VRB数可以从1个到最多16个。

      对于DCI format 1A/1B/1D而言，资源分配由一个资源指示值RIV来表示。通过这个值，可以推导出分配给UE的起始RB（）以及连续分配的RB的长度（）。计算公式如下：

      如果 ，则；否则。其中且不超过。

     当UE收到一个RIV后，如何计算和？

     通过可以知道是还是，并最终计算出和。

      由于且不超过，且必定有，故，也就有

      1）当时，；

      2）当时，。

      UE收到RIV后，计算的值x，

      1）如果，则得知，也就得到了最终结果；

      2）如果，则得知，也就得到了最终结果。

      图13介绍了DCI format 1A/1B/1D使用资源分配类型2的例子（25 RB）：

      起始RB（）为3，连续分配的VRB数（）为8，，所以。

图13：资源分配类型2的例子（25 RB）

      DCI format 1C只支持分布式VRB分配方式。对于DCI format 1C而言，分配给某个UE的资源可以从个到最多个VRB。其中为增长的步进值，并与下行系统带宽相关（如图14）。

图14：值与下行系统带宽的对应关系

      对于DCI format 1C而言，资源分配也是通过一个资源指示值RIV来表示。通过这个值，可以推导出分配给UE的起始RB（）以及连续分配的RB的长度（）。计算公式如下：

      如果，则；否则。其中，并且。而且不超过 。

      对于DCI format 1C而言，UE收到一个RIV后计算和的方式与DCI format 1A/1B/1D类似，这里就不做介绍了。

       假设是在DCI format 1C中的资源分配且系统带宽为25 RB，，，则有

      因为，所以 = 12 * (4 - 1) + 1 = 37。

      从上面的例子可以看出：1）资源分配类型2只支持连续VRB的分配；2）对于资源分配类型2，DCI format 1A/1B/1D与DCI format 1C的格式是不同的，DCI format 1C多了步进的概念；3）与资源分配类型0/1只支持集中式VRB分配不同，资源分配类型2既支持集中式VRB也支持分布式VRB。

注：本来想修改一下博文，但新浪博客有问题，保存时只有部分内容保存了下来，所以从其他转载的文章拷贝过来，如果对你的阅读产生了干扰，请见谅！

【参考资料】

[1]      TS 36.213的7.1.6节     Resource allocation

[2]     TS 36.212的5.3.3节     Downlink control information

[3]     TS 36.211的6.2.3.1节   Virtual resource blocks of localized type

[4]     《4G LTE/LTE-Advanced for Mobile Broadband》的10.4.4节

[5]     《LTE - The UMTS Long Term Evolution, 2nd Edition》的9.3.5.4节

[6]     《Type 1 Resource Allocation in LTE》by Prakash 

[7]      《Resource Allocation Type》

LTE：上行调度请求（Scheduling Request，SR） LTE：下行资源分配类型

标签：

原文地址：http://www.cnblogs.com/virusolf/p/4423515.html