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和DCI2A之前,有必要先介绍这2种资源分配方式。

1.资源分配方式0

采用资源分配方式0的DCI有:DCI1、DCI2、DCI2A、DCI2B。每个DCI里都有个资源分配字段,用于表示哪些RB是分配给这个UE的。

在RB资源分配方式0(Resource Allocation Type 0)中,所有的RB资源组成不同的RBG(RB Group),因此分配方式0就是以RBG为基本单位进行分配的。采用这种分配方式,表示DCI中的这个资源分配字段将使用一个bitmap表来分配RB资源,这个bitmap表的每个bit位就表示一个RBG。每个RBG又对应着P个连续的虚拟RB(即VRB,这里的VRB与物理RB是一一对应的,下面简称RB)。每个RBG具体对应多少个RB是与下行带宽相关的,如下表格所示。

比如下行是20MHz的带宽(N_DL_RB=100),那么如果按照资源分配方式0分配RB资源,每个RBG将包括4个RB(P=4)。如果是1.4MHz的带宽(N_DL_RB=6),那么每个RBG就只包括1个RB。

不同的带宽,资源分配方式0所能使用的RBG个数也是固定的。如果用变量N_RBG来表示这个值的话,N_RBG=(N_DL_RB P)向上取整。每个资源分配方式0的DCI,都对应着一个N_RBG比特长度的bitmap资源分配表,这个bitmap分配表被编码到DCI码流中,UE从这个分配表就可以推导出该PDSCH使用的RB资源。

比如3MHz的下行带宽,它的RB个数N_DL_RB=15,P=2,因此N_RBG=N_DL_RB / P)向上取整=(15 / 2)向上取整=8。但是需要注意,如果是(N_DL_RB mod P)!= 0的带宽,它的最后一个RBG的大小和其它的RBG大小是不一样的:最后一个RBG包含的RB个数=N_DL_RB
- P *(N_DL_RB / P),而非最后一个RBG的其他RBG,每个RBG包含的RB个数=P个。比如3MHz下行带宽,除了最后一个RBG,其他(N_DL_RB / P=15 / 2=)7个RBG,每个RBG都有2个RB,此时这7个RBG共占用了7*2=14个RB,小于整个带宽的15个RB,因此最后一个RBG包含的RB个数=N_DL_RB - P *(N_DL_RB
/ P
)= 15 - 2 * (15 / 2)=1个。如下图所示。

另外,既然是bitmap表,就有高低位问题。协议也明确规定,RBG_0对应着这个bitmap的高位即MSB,而RBG_(N_RBG-1)则对应着这个bitmap表的低位即LSB。如果UE解码到某个bit位=1,则表示对应的RBG分配给了这个UE。比如3M带宽时,bitmap表占用的bit位数N_RBG=(15/2)向上取整=8,bitmap码流=二进制Bin(00001011),那么表示该UE使用的RBG资源组分别是RBG4、RBG6和RBG7,因此使用的RB-ID分别是:RB8-RB9,RB12-RB14。所以说,分配方式0可以分配离散的RB资源,只是带宽越大,分配的RB粒度P就越粗。

2.资源分配方式1

采用资源分配方式1的DCI有:DCI1、DCI2、DCI2A、DCI2B,与资源分配方式0相同。每个DCI里都有个资源分配字段,用于表示哪些RB是分配给这个UE的。只是与分配方式0不同的是,资源分配方式1的资源分配字段有个域,而不是只有一个bitmap域,具体见下文。

在资源分配方式1中,所有的RB资源组成了不同的RBG(这点与资源分配方式0相同),而不同的RBG又组成了不同的RBG子集(RBG subset),因此分配方式1是基于RBG子集分配的。所有的RBG被分成P个不同的RBG子集,或者说,RBG子集本身就是一个集合,每个这样的集合由若干个RBG组成,当eNB给某个UE分配资源时,就选择一个RBG子集,然后将该子集中对应的RB置1。总之,每个带宽包含了P个RBG子集,每个RBG子集又包含了若干个RBG,每个RBG同样也包含了P个连续的RB(最后一个RBG包含的RB个数与分配方式0相同),组成示意如下。

不同的带宽,它所包含的RBG子集个数、以及每个RBG所包含的RB的个数,均与上文Table 7.1.6.1-1中的P值相等。上图示意的就是带宽为10MHz时各RBG子集的构成情况,此时N_DL_RB=50,P=3,所以此时就有3个RBG子集,每个RBG包含了3个连续的RB。

从上面的示意图中也可以看到,如果使用分配方式1,那么每个DCI中,必须携带当前选择的子集索引,以及该子集使用的bitmap。不过需要注意的是,此时bitmap表中的每个bit位表示的是对应的RB-ID,而不是RBG,这点与分配方式0不同。

还是以带宽10MHz为例介绍DCI中的RB分配信息如何理解。如下图所示,可以看到,该DCI使用了RBG子集1来指示资源分配,而具体的bitmap表中,bit2、bit3、bit5均等于1,表示子集1的第3个RB、第4个RB和第6个RB均被分配给了这个UE。另外也可以看到,每个UE使用的RB分配指示信息是通过RB-bitmap的形式给出的,这种RB-bitmap(RB0/RB1/RB2/...)是属于同一个RBG子集内的索引,不同RBG子集的RB0/RB1/RB2/...指代的RB-ID是不同的。

上图还可以看到,并不是所有的RBG子集包含的RBG和RB个数都是一样的,比如子集0包含的RBG个数是6个,共有18个RB;而虽然子集1包含的RBG个数也是6个,但只有17个RB;而子集2包含的RBG个数则只有5个,RB个数只有15个。

上面介绍了资源分配方式1的一种实际使用情况,这里还有几个地方没有提到:DCI里面shift字段的含义、上图中RB分配bitmap表占用的bit位个数怎么计算等等。下面就详细说明采用资源分配方式1的DCI中,它的资源分配内容怎么填写。

协议规定,资源分配方式1的资源分配字段占用的bit个数为(N_DL_RB / P)向上取整,包含3个域,这3个域分别是:

(1)RBG子集指示域。该域表示当前的资源分配是在P个RBG子集中选择的是哪个子集,该域占用的bit位个数N = log2(P)向上取整。比如10MHz带宽,P=3,那么N=log2(P)向上取整=log2(3)向上取整=(1.58)向上取整=2,即DCI码流中的RB资源分配字段的前2个bit,是用来表示当前使用的是哪个RBG子集。上图中subset=01,就是表示该DCI分配的子集是子集1。

(2)shift资源偏移域。该域固定占用1个bit,如果该域的值=0,表示选中的RBG子集内的RB不做偏移,值=1表示选中的RBG子集内的RB需要执行偏移,协议使用变量delta_shift(p)来表示第p个子集内的RB偏移量,这个偏移量是从RB低位(即RB0端而不是RB99端)开始偏移的,或者说是从bitmap的MSB位开始偏移的。具体怎么偏移详见下文。

(3)bitmap表域。该域占用的bit位个数N_TYPE1_RB = (N_DL_RB / P)向上取整 - log2(P)向上取整 - 1,每个bit值表示当前RBG子集中的一个RB,该bitmap表的MSB比特位对应着频率低的RB-ID,而LSB比特位则对应RB频率高的RB-ID(这个规则与分配方式0相同)。

上面介绍了采用资源分配方式1时DCI里的资源分配字段所包含的各个域的内容,可以看到,shift域决定了bitmap表域的理解,下面以10M带宽(50个RB)为例再具体解释一下。

(A) 如果各个子集都不偏移即三个子集的shift=0,每个子集的偏移量delta_shift(p)=delta_shift(0)=delta_shift(1)=delta_shift(2)=0,那么:

RBG子集0由RBG0(RB0/RB1/RB2)、RBG3(RB3/4/5)、RBG6(RB6/7/8)、RBG9(RB9/10/11)、RBG12(RB12/13/14)、RBG15(RB15/16/17)组成。

RBG子集1由RBG1(RB0/RB1/RB2)、RBG4(RB3/4/5)、RBG7(RB6/7/8)、RBG10(RB9/10/11)、RBG13(RB12/13/14)、RBG16(RB15/16)组成。

RBG子集2由RBG2(RB0/RB1/RB2)、RBG5(RB3/4/5)、RBG8(RB6/7/8)、RBG11(RB9/10/11)、RBG14(RB12/13/14)组成。

不过需要注意的是,上面每个子集包含的RB个数其实是不一样的(子集0有18个RB,子集1有17个RB,子集2有15个RB),而根据DCI的bitmap表域的计算公式,每个子集只能包含的bit个数N_TYPE1_RB = (50/3)向上取整 - log2(3)向上取整 - 1 = 17 - 2 - 1 = 14,即每次调度的时候,eNB只能分配14个RB给UE,所以在shift=0的条件下,实际上每个子集只有前14个RB能够使用(从RBG0或者RB低频端开始),而RB高频端还有4个RB不能分配使用,如下图所示。

由于每次调度时RB个数有限制,因此某些情况下并不适合使用资源分配方式1,比如测试吞吐量的时候。

(B) 如果子集0使用了偏移即shift=1,则表示需要对组成RBG子集0的RB进行偏移调整,偏移量delta_shift(p)= N_RBGsubset_RB(p) - N_TYPE1_RB=
N_RBGsubset_RB(0) - N_TYPE1_RB。其中,参数N_RBGsubset_RB(p)表示RBG子集p内的RB个数(如果是子集0的话,注意该值等于18而不是等于14),N_TYPE1_RB是bitmap域的比特长度,如下图示意。

从上面的公式中也可以看到,偏移量delta_shift(p)= N_RBGsubset_RB(p) - N_TYPE1_RB 也表示了每个子集中不能分配的RB个数,如子集0中有4个RB不能使用,子集1中有3个RB不能使用,而子集2中则有1个RB不能使用。那么如何决定哪几个RB不能使用,就是shift域的真正目的:如果shift=0,则表示RBG高频端的几个RB不使用,而如果shift=1,则意味着RBG低频段的几个RBG不能使用。

仍然以10MHz带宽为例,此时N_DL_RB=50,P=3。那么shift=1时,判断条件[(N_DL_RB - 1)/P 向下取整] mod P = [(49/3)向下取整] mod 3 = 16 mod 3 =1。因此:

对于子集0来说,p=0<1,所以RB偏移量delta_shift(0)= N_RBGsubset_RB(0) - N_TYPE1_RB = [(50 - 1)/9]向下取整 * 3 + 3 - (17 - 2 - 1) = 5 * 3 + 3 - 14 =4。

对于子集1来说,p=1=1,所以RB偏移量delta_shift(1)= N_RBGsubset_RB(1) - N_TYPE1_RB = [49/9]向下取整 * 3 + (49 mod 3) + 1 - (17 - 2 - 1) = 15 + 2 - 14 =3。

对于子集2来说,p=2>1,所以RB偏移量delta_shift(2)= N_RBGsubset_RB(2) - N_TYPE1_RB = [(50 - 1)/9]向下取整 * 3 - (17 - 2 - 1) = 5 * 3 - 14 =1。

根据公式计算得到三个子集的偏移量delta_shift(p)分别是4、3、1,这与前文示意图中描述的“每个子集中不能分配的RB个数”数值一致。此时实际的分配如下图所示。

从图上可以看到,子集0包含的RB从RB10开始直到RB47,共14个RB,在DCI的bitmap域里,第一个RB对应的就是RB10,其它的依次类推。协议也给出了在shift=1的情况下,每个子集中每个RB的序列,如下图所示。

以10MHz带宽为例,P=3,N_TYPE1_RB=14,i的范围是0~13,因此:

对于子集0,delta_shift(0)=4,i=0(第一个RB位置)时,n_RBGsubset_VRB(0)= (0+4)/3 * 9 + 0*3 +(0+4)mod3 = 9 + 0 + 1 =10;i=13(最后一个RB位置)时,n_RBGsubset_VRB(0)=(13+4)/3 * 9 + 0*3
+ (13+4)mod3 = 45+0+2=47。

对于子集1,delta_shift(1)=3,i=0(第一个RB位置)时,n_RBGsubset_VRB(1)= (0+3)/3 * 9 + 1*3 +(0+3)mod3 = 9 + 3 + 0 = 12;i=13(最后一个RB位置)时,n_RBGsubset_VRB(1)=(13+3)/3
* 9 + 1*3 + (13+3)mod3 = 45+3+1=49。

对于子集2,delta_shift(2)=1,i=0(第一个RB位置)时,n_RBGsubset_VRB(2)= (0+1)/3 * 9 + 2*3 +(0+1)mod3 = 0 + 6 + 1 = 7; i=13(最后一个RB位置)时,n_RBGsubset_VRB(2)=(13+1)/3
* 9 + 2*3 + (13+1)mod3 = 36+6+2=44。

根据公式计算的结果,与上面示意图的移位结果一致。

综上,资源分配方式1的分配粒度是RB,相对分配方式0的RBG分配粒度,更加灵活自由,但由于每次只能分配一个子集的RB资源,所以使用分配方式1时,可供分配的RB最大个数受到了限制,最大流量也会因此受到限制。如果要最大化LTE系统的下行流量,eNB就不能采用资源分配方式1,而需要采用资源分配方式0下的双流模式。

3.资源分配方式2

采用资源分配方式0的DCI有:DCI1A、DCI1B、DCI1C、DCI1D,与资源分配方式0和1没有重叠。这种方式已经在博文《LTE下行物理层传输机制(5)-DCI格式的选择和DCI1A》中提到,这里不再累述。

参考文献:

(1)3GPP TS 36.212 V9.4.0 (2011-09) Multiplexing and channel coding

(2)3GPP TS 36.213 V9.3.0 (2010-09) Physical layer procedures

(3)3GPP TS 36.321 V9.6.0 (2012-03) Medium Access Control (MAC) protocol specification

(4)http://www.sharetechnote.com/

时间: 2024-10-16 07:52:43

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

LTE下行物理层传输机制(9)-集中式和分布式资源映射

LTE系统里,RB资源的动态调度是在eNB侧实现的,这里的"RB资源"实际上是特指虚拟RB(Virtual RB)而不是物理RB(Physical RB).VRB是MAC层在调度的时候使用的,属于逻辑上的概念,而PRB是物理层在实际映射RE资源的时候需要使用的,属于实际物理意义上的概念.VRB和PRB之间,存在着不同的映射关系:最简单的映射关系就是VRB的位置和PRB的位置是相同的,它们之间是一一对应的:另外一种复杂点的关系就是VRB和PRB并不是一一对应的,但是可以依赖某种特定的映射

LTE下行物理层传输机制(7)-DCI2格式和预编码矩阵的选择

TTI是动态调度资源的基本时间单位,每进行一次动态调度就是一个TTI,通常情况下,一个TTI就是1ms.如果eNB在调度下行RB资源的时候,发现可以进行空分复用,或者说1个TTI(Transmission Time Interval)内可以同时传输2个下行传输块(简称TB块,Transport Block),那么这个时候,网侧可能会使用DCI2.DCI2A等格式来传输PDSCH的控制信息.下面就具体介绍DCI2格式的内容,以及什么时候使用DCI2格式. 1.组成DCI2格式的bit内容 DCI2

LTE下行物理层传输机制(1)-天线端口Antenna Port和小区特定参考信号CRS

上篇博文<LTE物理传输资源(3)-时频资源>的最后提到了PCFICH等几种下行物理信道,这篇博文本来想写PCFICH信道的,但在准备写PCFICH的时候,发现需要用到天线端口的相关内容,而这些内容目前还没有写.所以本文就先写天线端口和下行参考信号的相关内容. 1.天线端口(Antenna Port)和参考信号(Reference Signal)的关系 天线端口是一个逻辑上的概念,它与物理天线并没有一一对应的关系.在下行链路中,天线端口与下行参考信号(Reference signal)是一一对

LTE下行物理层传输机制(3)-PHICH信道

在阅读本文之前,建议先看下博文<LTE-TDD HARQ(1)-上行HARQ时序>,以便更好的理解本文内容. 本文主要包括的内容有: (1)什么是PHICH信道,它的作用是什么 (2)怎么来唯一的标识一个PHICH信道 (3)PHICH信道对应的REG实际映射的内容是什么 (4)PHICH信道的位置 1.什么是PHICH信道 PHICH信道即物理HARQ指示信道,英文全称是Physical hybrid ARQ indicator channel,作用是eNB通过该信道向终端反馈上行PUSCH

LTE下行物理层传输机制(5)-DCI格式的选择和DCI1A

PDCCH信道传输的是与物理上下行共享信道(PUSCH.PDSCH)相关的控制信息,即DCI信息(Downlink Control Information),这些DCI信息包含了诸如RB资源分配信息.调制方式MCS.HARQ-ID等等若干相关内容.终端只有正确的解码到了DCI信息,才能正确的处理PDSCH数据或PUSCH数据. 不同的DCI信息,它的目的可以是不同的,比如,有针对下行RB资源进行分配的DCI,有针对上行RB资源进行分配的DCI,有针对上行功率控制进行调整的DCI,有特别针对下行双

如何优化传输机制来实现实时音视频的超低延迟?

1.前言 要在语音视频 SDK 中实现超低延迟,实时的语音视频传输机制是必不可少的,而 FEC 和 ARQ 的智能结合是实时语音视频传输机制的基石. 在语音社交.视频社交.游戏语音和互动直播等领域,关于在语音视频实时传输中实现低延迟这个议题,已经有不少的文章提出各种方案.绝大部分方案的思路都是"优化",比如说,优化编码.推流.传输和播放等各个环节. 愚以为,要在实时语音视频传输中获得超低延迟,是不能单靠挖空心思去"优化"的,而是要依靠实时的传输机制.就像高铁和火车有

红茶一杯话Binder(传输机制篇_上)

红茶一杯话Binder (传输机制篇_上) 侯 亮 1 Binder是如何做到精确打击的? 我们先问一个问题,binder机制到底是如何从代理对象找到其对应的binder实体呢?难道它有某种制导装置吗?要回答这个问题,我们只能静下心来研究binder驱动的代码.在本系列文档的初始篇中,我们曾经介绍过ProcessState,这个结构是属于应用层次的东西,仅靠它当然无法完成精确打击.其实,在binder驱动层,还有个与之相对的结构,叫做binder_proc.为了说明问题,我修改了初始篇中的示意图

红茶一杯话Binder (传输机制篇_下)

红茶一杯话Binder (传输机制篇_下) 侯 亮 1 事务的传递和处理 从IPCThreadState的角度看,它的transact()函数是通过向binder驱动发出BC_TRANSACTION语义,来表达其传输意图的,而后如有必要,它会等待从binder发回的回馈,这些回馈语义常常以“BR_”开头.另一方面,当IPCThreadState作为处理命令的一方需要向发起方反馈信息的话,它会调用sendReply()函数,向binder驱动发出BC_REPLY语义.当BC_语义经由binder驱

红茶一杯话Binder (传输机制篇_中)

红茶一杯话Binder (传输机制篇_中) 侯 亮 1 谈谈底层IPC机制吧 在上一篇文章的最后,我们说到BpBinder将数据发到了Binder驱动.然而在驱动层,这部分数据又是如何传递到BBinder一侧的呢?这里面到底藏着什么猫腻?另外,上一篇文章虽然阐述了4棵红黑树,但是并未说明红黑树的节点到底是怎么产生的.现在,我们试着回答这些问题. 1.1 概述 在Binder驱动层,和ioctl()相对的动作是binder_ioctl()函数.在这个函数里,会先调用类似copy_from_user