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的周期是通过IE:SchedulingRequestConfigsr-ConfigIndex字段配置的。

由于SR资源是UE专用且由eNodeB分配的,因此SR资源与UE一一对应且eNodeB知道具体的对应关系。也就是说,UE在发送SR信息时,并不需要指定自己的ID(C-RNTI),eNodeB通过SR资源的位置,就知道是哪个UE请求上行资源。SR资源是通过IE:SchedulingRequestConfigsr-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所示:

1SR资源

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

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

2SR周期配置的一个例子

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

3SR传输

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

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:

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

对应下行系统带宽,RBG的总数为:

其中,前个RBG的大小为P;如果 % P > 0,则最后一个RBG的大小为

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

二、资源分配类型0Resource 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。

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的总数。其中前12个RBG的每个RBG大小为2,最后一个RBG的大小为1(如图4所示);

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所示)。

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

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

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

6DCI 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数为



13



12

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

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

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

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



2  (13 – 11)



1  (12 - 11)

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

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

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

结果如下:

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。

结果如下:

10:每个子集的bitmap的每个比特表示的VRB25 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。

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

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个到个。(的计算见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

时间: 2024-10-12 12:05:01

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

LTE学习之路(7)——LTE系统消息

1 系统消息包含: 主信息块(Master Information Block,MIB) 多个系统信息块(System Information Blocks,SIBs) 2 MIB 承载于BCCH——>BCH——>PBCH上 包括有限个用以读取其他小区信息的最重要.最常用的传输参数(如:系统带宽.系统帧号.PHICH配置信息) 时域:紧邻同步信道,以10ms为周期重传4次 频域:位于系统带宽中央的72个子载波(1.08MHz) 3  SIBs 除MIB外的系统信息,包括SIB1~SIB12:

请求(Request)的参数(Parameter)里包含特殊字符(#等)的正确处理方式

遇到一个问题 在一个地址链接(URL)里使用  url?param1=val1&param2=val2  的方式传递参数,结果在获取参数值时发现不是当初设定的值. 具体案例 以特殊字符井号(#)为例. 部分参数值丢了 JS里设置参数 window.location="some_web_project/xxx.jsp?param_key=abc#xyz"; Java中取参数值 Sting paramVal = request.getParameter("param_ke

微信应用号小程序发起请求wx.request(OBJECT)

微信应用号小程序发起请求wx.request(OBJECT) wx.request(OBJECT) ? wx.request发起的是https请求.一个微信小程序,同时只能有5个网络请求连接. OBJECT参数说明: 参数名 类型 必填 说明 url String 是 开发者服务器接口地址 data Object.String 否 请求的参数 header Object 否 设置请求的header , header中不能设置Referer method String 否 默认为GET,有效值:O

访问请求参数request.getParameter()

访问请求参数request.getParameter() 制作人:全心全意 getParameter() 例: 传递参数页: <%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8"%> <%@ page import="java.util.Date"%> <%@ page import

未能加载视图状态。正在向其中加载视图状态的控件树必须与前一请求期间用于保存视图状态的控件树相匹配。例如,当以动态方式添加控件时,在回发期间添加的控件必须与在初始请求期间添加的控件的类型和位置相匹配

信息: 未能加载视图状态.正在向其中加载视图状态的控件树必须与前一请求期间用于保存视图状态的控件树相匹配.例如,当以动态方式添加控件时,在回发期间添加的控件必须与在初始请求期间添加的控件的类型和位置相匹配. 数据源: System.Web 堆栈信息: 在 System.Web.UI.Control.LoadViewStateRecursive(Object savedState) 在 System.Web.UI.Control.LoadChildViewStateByIndex(ArrayLis

HTTP请求415错误 – 不支持的媒体类型(Unsupported media type)

HTTP请求415错误 – 不支持的媒体类型(Unsupported media type) 通常有以下情况: 1:检查你的 http 请求头信息,比如 因为 User-Agent 被服务器设置 拒绝请求了: 比如你写的的爬虫,就很有可能因为没有伪装成浏览器,被拒绝请求 user-agent 详情 2:查看你的 http 请求方法,以及服务器端的设置 比如:有一个 强制用 post 请求的接口,你是不是用了非post 请求 3:post 请求参数设置,是不是必须的,json 格式 比如下面,两段

LTE下行物理层传输机制(6)-下行资源分配方式(Resource Allocation Type)

下行RB的资源分配(Resource Allocation)有三种方式,分别是资源分配方式0.资源分配方式1和资源分配方式2.在上一篇博文<LTE下行物理层传输机制(5)-DCI格式的选择和DCI1A>中提到DCI1A的时候,提到DCI1A只能分配连续的RB,以及这种方式下RIV(Resource Indication Value )的计算,那么这种分配方式其实就是资源分配方式2.而DCI2和DCI2A格式使用的则是另外2种不同的分配方式,即资源分配方式0和资源分配方式1.因此在讲DCI2和D

iOS 请求出现 &quot;Request failed: bad request (400)&quot;

主要出现如下错误: 请求失败-Error Domain=com.alamofire.error.serialization.response Code=-1011 "Request failed: bad request (400)" UserInfo={com.alamofire.serialization.response.error.response=<NSHTTPURLResponse: 0x7cec30d0> { URL: https://api.weibo.co

小程序之发起请求 wx.request(object)的坑

这是官方的API,然后官方的实例中 wx.request({ url: 'test.php', //仅为示例,并非真实的接口地址 data: { x: '' , y: '' }, header: { 'content-type': 'application/json' }, success: function(res) { console.log(res.data) } }):假如你按着官方的文档写你就掉坑里了,你会发现请求回来的数据在调试的时候可以看见,等放到手机真机预览的时候你就发现请求回来