NR R16 上行满功率传输(ULFPTx)
Posted modem协议笔记
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了NR R16 上行满功率传输(ULFPTx)相关的知识,希望对你有一定的参考价值。
微信公众号同步更新,欢迎关注同名“modem协议笔记”
UL full power Tx(ULFPTx Mode),上行满功率传输,是R16版本的一个增强,R15由于受限于codebook和PUSCH功率控制,某些情况下无法达到满功率传输(例如26dBm),这就影响了上行覆盖和速率。R16对其进行了增强,因为并不是在所有情况下,每个 PA都一定能达到终端的功率等级所对应的最大输出功率,针对具有不同功放(PA)能力的终端设计了不同的上行满功率传输方案(不同的ULFPTx Mode),可以使得上行双发的终端在小区边缘以上行满功率( 26dBm)发送,相比 R15 部分终端因协议限制采用 23dBm 单发情况可提升上行覆盖 2~3dB。该功能主要影响上行双发终端的软件修改,能够保证上行双发终端满功率发射上行信号,保证覆盖,是 R16 阶段UE关键技术之一。
在spec上,ul-fullpowerTransmission主要对应在38.213 7.1 PUSCH power control部分,整本spec对ul-fullpowerTransmission的描述就那短短的几行,但是看完后其实并不太清楚这个东西具体是怎么工作的,于是在3GPP 官网开始探索,直到搜到R1-1913107及R4-1900737,加上看了下其他相关的tdoc,才有点拨云见日的感觉。
为搞清楚其工作机制,先看下PA相关的定义,根据R4-19007373中的描述,UE的PA的capability定义如下 :
ue capability 1:在各个tx chain中都支持输出最大额定功率的pa((all full rated PAs));
ue capability 2:任一个tx chain均不支持全额定pa(non full rated PAs);
ue capability 3:tx chain的子集(某一部分)支持全额定pa(Partial full rated PAs)。
以PC3 =23bdm 为例,下图是上述三种PA结构的一种可能。
上述ue capability1/2/3对应的到spec 38.213 7.1 PUSCH power control分别是fullpower/fullpowerMode1/fullpowerMode2。
如开头所述 ULFPTX 产生的背景主要是针对小区边缘的UE,其rank 一般比较低,这时候实现full power 传输对于提升覆盖就显得尤为重要,因而希望在UE采用低阶预编码矩阵也能获得最大的性能,ULFPTX应运而生。考虑到 PA 架构最坏情况的功率缩放机制导致的功率限制;对于一些预编码矩阵,UE只有部分天线端口可以用于传输,所以通过UE报告其不同PA架构的部分能力的方式,然后根据UE能力实现ULFUTX。
这里先看下dbm(功率绝对值)和功率线性值的转换公式如下,dBm表示功率绝对值=10lg(功率线性值/1mw)。
如果功率绝对值是46dbm,其功率线性值= 10^(46 / 10) = 40000mw = 40W,如果功率绝对值是43dbm,其其功率线性值 = 10^(43 / 10) = 40000mw = 20W;从这个例子可以看出以dBm为单位时,加减3dBm相当于线性值下乘除2,也就是2倍的关系。因为3dBm转换成线性值时:功率线性值= 10^(3 / 10) = 2mw,更进一步的dBmValue = 46dBm时,功率线性值= 10^(43 / 10) * 10^(3 / 10) = 20000 * 2 = 40000mw = 40W。因此,当功率加了3dBm,对于功率线性值而言,其实是翻了一倍,如果功率减3dBm,对于线性值而言,其实是缩小了一倍。
接下来主要看下spec中的描述:
ULFPTx主要通过上图中的IE ul-FullPowerTransmission进行区分,根据不同的Mode对线性功率值^P_PUSCH,b,f,c(i,j,qd,l)进行scaling的操作,根据上述功率线性值和功率绝对值之间的关系,其与P_PUSCH,b,f,c(i,j,qd,l)的关系是P_PUSCH,b,f,c(i,j,qd,l)=10lg(^P_PUSCH,b,f,c(i,j,qd,l)),如果UE在对应场景支持full power 传输时,就不会对线性功率^P_PUSCH,b,f,c(i,j,qd,l)进行缩放操作,即下文的s=1,其他情况,就按照s的确定方式进行缩放就行了。下面就具体看下38.213中相关内容。
网络侧根据UE上报的能力(相关的capaility IE附在结尾处),当UE支持ULFPTx时,网络侧会在PUSCH-Config中配置ul-FullPowerTransmission,其值可以配置为fullpower和fullpowerMode1/2。
fullpower和fullpowerMode1
如果 PUSCH-Config 中的 ul-FullPowerTransmission= fullpower时(对应的是all full rated PAs),s=1;
如果 PUSCH-Config 中的 ul-FullPowerTransmission = fullpowerMode1(non full rated PAs)时,并且usage= 'codebook'的 SRS-ResourceSet 中的每个 SRS resource都有一个以上的 SRS 端口时,s为非零PUSCH发射功率的天线端口数与UE在一个SRS resource中支持的最大SRS端口数的比值;
fullpowerMode2
如果PUSCH-Config 中的 ul-FullPowerTransmission = fullpowerMode2(Partial full rated PAs),
1 DCI 中的SRI 对应的SRS resource 是single port,那s=1
2 其他情况 s是非零 PUSCH 传输功率的天线端口数量与 SRS port 数量之比,
而SRS ports数量根据不同的场景确定
(1)当SRS-ResourceSet usage=codebook且配置的SRS Resource 不止一个时,SRS port由DCI 中的SRI对应SRS resource的port决定;
(2)configured grant type 1配置中的SRS-Resourceindicator 对应的SRS resource 的port决定;
(3)当SRS-ResourceSet usage=codebook且配置的SRS Resource 只有一个时,就由这个SRS resource port决定。
但是要注意,如果最终选用的传输TPMI是UE report 的full power TPMI时,s=1,即不进行任何缩放。
值得注意的是在支持fullpowerMode2 时,UE根据自己的能力通过ul-FullPwrMode2-TPMIGroup-r16 上报支持full power的TPMI group,当实际PUSCH传输时如果用的就是支持full power 的TPMI,那UE就可以进行full power传输,即s=1; 其配置结构如下:
ul-FullPwrMode2-TPMIGroup-r16上报的能力包括的IE有(1)twoPorts-r16 对应2bits的bitmap,最左边的bit代表TPMI index=0,第二bit代表TPMI index=1,其中的TPMI index指的是38.211 Table 6.3.1.5-1中的index(Single layer传输),如上图;
(2)fourPortsNonCoherent-r16 和fourPortsPartialCoherent-r16 可配置的TPMI group value 如下表中的G0~6。
另外在38.214中还有找到下面有关fullpowerMode2的描述,
在ul-FullPowerTransmission设置为fullpowerMode2时:
(1)在usage设置为“codebook”的SRS resource set 中,可以配置有一个SRS resource或多个SRS resources,这些SRS resource的SRS 端口数可以相同也可以不同。
(2)当在SRS资源集中配置了多个SRS资源时,可以为usage ='codebook'的SRS resource set中的所有SRS resource 配置最多2个不同的 spatial 关系。
(3)根据 UE 能力,usage设置为“codebook”的SRS resource set 中支持最多 2 个或 4 个 SRS resource。
在ul-FullPowerTransmission设置为fullpowerMode2 且RRC层配置codebookSubset=‘partialAndNonCoherent’ 外加usage=codebook的SRS-resourceSet中包含至少一个 4 ports SRS resource和一个2 ports SRS resource时,2-port的SRS resource的codebookSubset 应该设置为nonCoherent。
没有配置ul-FullPowerTransmission时,
spec还会考虑到R15中原有的情况,即没有ULFPTX的场景,如果PUSCH-Config中没有配置ul-FullPowerTransmission且usage=codebook的SRS-ResourceSet 中的SRS resource 的port大于1个时,s为非零PUSCH发射功率的天线端口数与UE在一个SRS资源中支持的最大SRS端口数的比值。还有最后一句话,即计算出来的PUSCH功率,最后是要在各个非零功率port之间均分的。这里正好看下要对PUSCH 线性功率进行缩放的原因。以上面的non full rated PAs举例说明。
以PC2 26dbm为例,此时max antenna ports =4,有3个非零功率antenna ports, 用最大power 26 dbm 传输的话,如果不进行缩放,P/3=21dbm 即每根天线的传输power 超过了最大额定功率 20dbm;如果按照缩放规则,要对26 dbm的线性功率值400mw 进行3/4的缩放后再均分功率,此时 计算出来的功率正好为20dbm。也就是说对线性功率值要进行缩放的一方面原因是为了防止计算出来的Tx power超过antenna port的最大power能力。
除了上面的描述,在38.101-1中也有对支持UL MIMO ULFPTx UE的描述,即Table6.2D.1-1中的最大输出功率应该满足Table6.2D.1-3中几个场景的ULFPTX 配置。
更具体的,(1)对于fullpowerMode1 UE,2 tx port进行1 layer传输时,ULFPTx 对应上图中的TPMI index 2时;
(2)对于fullpowerMode2 UE,2 tx port进行1 layer传输时,ULFPTx 对应上图中的TPMI index 0和1时;
(3)对于fullpowerMode UE,2 tx port进行1 layer传输时,ULFPTx 对应上图中的TPMI index 0和1时:
上述3个场景中对应的s肯定要为1的,但是最后的ULFPTx power 肯定要与UE 支持的power class有一定的权衡过程。
下面看个例子
如38.211 PUSCH precoding的矩阵,左侧的z(pi)(i)代表每根天线要传输的复值符号,右侧的y(v)(i)就代表各layer要传输的符号,中间的矩阵W就是根据TPMI确定的。
在根据选取TPMI时,要根据SRI指示的SRS resource中的nrofSRS-Ports进行选择(只配置了一个用于codebook 传输的SRS resource时,就不需要SRI指示),假如此时是power class 3(26dbm) UE,SRI 对应 SRS resource 的nrofSRS-Ports=2,UE在一个SRS resource中支持的最大SRS端口数为4 ,进行single layer传输,那UE要根据上面的table 选取TPMI进行 single layer传输,TPMI=0 对应的W= √2[1 0] T; T就当作矩阵转置的意思。
此时W ×[y(0)(i)]=√2[ y(0)(i) 0] T 即z(p0)(i) =√2* y(0)(i) ,z(p1)(i) =0,就是此时只有一根天线有实际符号要传输,另一根天线不用传输任何符号,也就是非零功率天线port个数 =1;
(1)如果ul-FullPowerTransmission=fullpower 时(对应的是all full rated PAs),s=1,此时UE 可以用26dbm 进行传输;
(2)如果ul-FullPowerTransmission = fullpowerMode1(non full rated PAs)时,s=1/4,即此时UE只能用17dbm进行传输;
(3)如果ul-FullPowerTransmission = fullpowerMode2(Partial full rated PAs),如果UE上报的ul-FullPwrMode2-TPMIGroup-r16包含上述TPMI,则可以进行26dbm传输;如果该TPMI不支持UL full power tx,s=1/2,即此时UE只能用23dbm进行传输。
这里只是一个假设,实际配置中还要考虑codebooksbset的限制和UE支持ULFPTx的TPMI的情况,进而不同fullpowermode的UE可用的TPMI也不一样。
最后把ULFPTx相关的能力IE列在下面。
以上是关于NR R16 上行满功率传输(ULFPTx)的主要内容,如果未能解决你的问题,请参考以下文章
[4G&5G专题-100]:MAC层 - 调度 - 4G LTE物理信道的功率控制3 - 上行信道功率控制
[深入研究4G/5G/6G专题-27]: 5G NR开机流程4.5 - RRC连接应答消息MSG4PUCCH上行控制信道首次调度UCI与HARQ应答