LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型

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

上行调度请求(Scheduling RequestSR

      如果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的周期是通过IESchedulingRequestConfigsr-ConfigIndex字段配置的。

      由于SR资源是UE专用且由eNodeB分配的,因此SR资源与UE一一对应且eNodeB知道具体的对应关系。也就是说,UE在发送SR信息时,并不需要指定自己的ID(C-RNTI),eNodeB通过SR资源的位置,就知道是哪个UE请求上行资源。SR资源是通过IESchedulingRequestConfigsr-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资源用LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第1张图片表示,其值与PUCCH format 1的资源索引LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第2张图片相等。

      如果在同一子帧上,需要同时发送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的传输周期LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第3张图片和SR在该周期内的子帧偏移LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第4张图片,对应36.213的Table 10.1.5-1。满足如下条件的上行子帧才能够用于发送SR

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第5张图片

      其中LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第6张图片为系统帧号;LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第7张图片为一个系统帧内的slot号,取值范围为0~19LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第8张图片的值对应子帧号。

      从上面的公式可以看出,LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第9张图片保证了每个UE对应的SR资源在LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第10张图片个子帧只出现一次(但UE只在有上行数据要发送却没有上行资源时,才用该资源来发送SR)。LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第11张图片指定了每个UE对应的SR资源在其周期内的第几个子帧发送。

      SR资源配置如图1所示:

 

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第12张图片

1SR资源

 

      可以看出,sr-ConfigIndexsr-PUCCH-ResourceIndex共同决定了一个唯一的SR资源。该资源只能分配给一个UE,但只有当UE有上行数据需要发送但却没有上行资源时才会被使用。

      图2是SR周期配置的一个例子,3个UE的周期都为10ms,但在周期内的子帧偏移各不相同。

 

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第13张图片

2SR周期配置的一个例子

 

      当有上行数据到达并触发SR时,UE会选择分配给它的下一个可用的SR资源来发送SR如图3所示:

 

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第14张图片

3SR传输

 

      UE发送SR以后,无法确定eNodeB什么时候会下发UL Grant,这取决于上行资源的调度以及优先级等。如果UE等待超时(超时时间由sr-ProhibitTimer决定)就重发SR,重发次数超过了SR的最大重传次数(由IESchedulingRequestConfigdsr-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与下行资源分配类型的对应关系:

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第15张图片

1DCI 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

 

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第16张图片

2RBG size与下行系统带宽的关系(36.213Table 7.1.6.1-1

      对应下行系统带宽LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第17张图片,RBG的总数LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第18张图片为:

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第19张图片

      其中,前LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第20张图片个RBG的大小为P;如果LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第21张图片 % P > 0,则最后一个RBG的大小为LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第22张图片

      以下行系统带宽LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第23张图片 = 50 RB为例,其P值为3,RBG的总数LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第24张图片为17,前16个RBG各包含3个VRB,最后一个RBG只包含2个VRB

 

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

      在资源分配类型0中,DCI format 1/2/2A/2B/2C通过一个bitmap指示分配给UE的RBG。bitmap共包含LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第25张图片比特,每1比特对应1个RBG,最高位表示RBG 0,最低位表示RBG  LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第26张图片 - 1,依此类推。如果某个RBG分配给了某个UE,则bitmap中对应比特置为1;否则置为0

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第27张图片

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

 

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

      1)通过查36.213的Table 7.1.6.1-1可以知道,RBG大小P = 2

      2)RBG的总数LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第28张图片。其中前12个RBG的每个RBG大小为2,最后一个RBG的大小为1(如图4所示);

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第29张图片

4:资源分配类型0RBG资源(25 RB

      3)即bitmap共包含13比特。

      4)假如分配给某UE的资源的bitmap为:1001110100010,则该UE被分配了RBG 0、RBG 3、RBG 4、RBG 5、RBG 7、RBG 11(如图5所示)。

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第30张图片

5:资源分配类型0的例子(25 RB

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

 

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

      在资源分配类型1中,所有的RBG被分为P个子集,P为RBG的大小(见图2)。每个RBG子集pLTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第31张图片)包含从RBG p开始,间隔为P的所有RBG。分配给某个UE的VRB资源必须来自于同一个子集。

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

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第32张图片

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

      第一个域包含LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第33张图片比特,用于指定所选的RBG子集,即p的值。

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

      第三个域包含一个bitmap,bitmap的每一比特对应所选RBG子集中的一个VRB注意:不是RBG)。最高位表示子集中的第一个VRB,最低位表示子集中的最后一个VRB,依此类推。如果某个VRB分配给了某个UE,则bitmap中对应比特置为1;否则置为0。bitmap的大小,即bitmap包含的比特数LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第34张图片

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第35张图片

      一个选定的RBG子集中的VRB起始于该子集中的最小VRB号 + 偏移量LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第36张图片,并对应bitmap中的最高位。该偏移量以VRB的数量表示,并且是发生在选定的RBG子集内的偏移。如果DCI的资源块分配信息中的第二个域为0,则RBG子集p的偏移LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第37张图片;如果DCI的资源块分配信息中的第二个域为1,则RBG子集p的偏移LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第38张图片,且bitmap中的最低比特位调整为对应RBG子集中的最后一个VRB

      LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第39张图片为RBG子集p包含的VRB数,计算公式如下:

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第40张图片

      对于RBG子集p而言,其bitmap中的每一比特iLTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第41张图片)对应的VRB可通过如下公式计算:

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第42张图片

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

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

      1)通过查36.213的Table 7.1.6.1-1可以知道,P = 2,即有2个子集:子集0(从RBG0开始)和子集1(从RBG1开始);

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第43张图片

7:资源分配类型1中的子集(25 RB

      2LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第44张图片 = 1,即第一个域使用1比特指定所选的RBG子集;

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

      4)bitmap包含的比特数LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第45张图片 = 13 -1 -1 = 11;即bitmap只能对应11个VRB

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

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第46张图片

13

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第47张图片

12

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

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

      如果shift bit为0,RBG子集p的偏移LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第48张图片

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

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第49张图片

2  (13 – 11

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第50张图片

1  (12 - 11

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

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第51张图片

8:资源分配类型1中每个子集可用的VRB集合(25 RB

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

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第52张图片

      结果如下:

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第53张图片

9:每个子集的bitmap中的每个比特对应的VRB25 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

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第54张图片

      结果如下:

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第55张图片

10:每个子集的bitmap的每个比特表示的VRB25 RB, shift bit = 1

      从图10可以看出,如果shift bit = 1(发生偏移),每个子集的bitmap对应的VRB,是从图8给定的VRB集合中的第一个VRB,加上偏移量开始(对应子集0,偏移量LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第56张图片 = 2,即在图8给定的p = 0的VRB集合中,往前移2个,得到起始VRB为VRB4;对应子集1,偏移量LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第57张图片 = 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

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第58张图片

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

 

三、资源分配类型2Resource 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)。

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第59张图片

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

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

      如果DCI format 1A使用分布式VRB分配方式,且其DCI的CRC由P-RNTI、RA-RNTI或SI-RNTI加扰,则分配给对应UE的VRB数可以从1个到LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第60张图片个。(LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第61张图片的计算见36.211的6.2.3.2节,这里就不做介绍了)

      如果DCI format 1A/1B/1D使用分布式VRB分配方式,且其DCI的CRC由C-RNTI加扰,则当下行带宽为6~49 RB时,分配给对应UE的VRB数可以从1个到最多LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第62张图片个;则当下行带宽为50~110 RB时,分配给对应UE的VRB数可以从1个到最多16个。

      对于DCI format 1A/1B/1D而言,资源分配由一个资源指示值RIV来表示。通过这个值,可以推导出分配给UE的起始RB(LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第63张图片)以及连续分配的RB的长度(LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第64张图片)。计算公式如下:

      如果LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第65张图片 ,则LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第66张图片;否则LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第67张图片。其中LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第68张图片且不超过LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第69张图片

     UE收到一个RIV后,如何计算LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第70张图片LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第71张图片

     通过LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第72张图片可以知道是LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第73张图片还是LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第74张图片,并最终计算出LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第75张图片LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第76张图片

      由于LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第77张图片且不超过LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第78张图片,且必定有LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第79张图片,故LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第80张图片,也就有

      1)当LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第81张图片时,LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第82张图片

      2)当LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第83张图片时,LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第84张图片

      UE收到RIV后,计算LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第85张图片的值x,

      1)如果LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第86张图片,则得知LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第87张图片,也就得到了最终结果LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第88张图片

      2)如果LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第89张图片,则得知LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第90张图片,也就得到了最终结果LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第91张图片

 

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

      起始RB(LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第92张图片)为3,连续分配的VRB数(LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第93张图片)为8,LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第94张图片,所以LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第95张图片

 

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第96张图片

13:资源分配类型2的例子(25 RB

 

      DCI format 1C只支持分布式VRB分配方式。对于DCI format 1C而言,分配给某个UE的资源可以从LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第97张图片个到最多LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第98张图片个VRB。其中LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第99张图片为增长的步进值,并与下行系统带宽相关(如图14)。

 LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第100张图片

14LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第101张图片值与下行系统带宽的对应关系

      对于DCI format 1C而言,资源分配也是通过一个资源指示值RIV来表示。通过这个值,可以推导出分配给UE的起始RB(LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第102张图片)以及连续分配的RB的长度(LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第103张图片)。计算公式如下:

      如果LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第104张图片,则LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第105张图片;否则LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第106张图片。其中LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第107张图片LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第108张图片并且LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第109张图片。而LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第110张图片且不超过 LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第111张图片

      对于DCI format 1C而言,UE收到一个RIV后计算LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第112张图片LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第113张图片的方式与DCI format 1A/1B/1D类似,这里就不做介绍了。

       假设是在DCI format 1C中的资源分配且系统带宽为25 RB,LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第114张图片LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第115张图片,则有

LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第116张图片

      因为LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第117张图片,所以LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型_第118张图片 = 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》

转载于:https://www.cnblogs.com/virusolf/p/4423515.html

你可能感兴趣的:(LTE:上行调度请求(Scheduling Request,SR) LTE:下行资源分配类型)