CN103686926A - 上行承载请求的接纳判决方法 - Google Patents

Abstract

本发明公开了一种上行承载请求的接纳判决方法，包括：当网络侧接收到用户设备UEi的上行承载请求时，确定该UEi的PUSCH上传输数据所需要功率的线性值

确定该UEi的PUCCH上传输控制信息所需要功率的线性值

判断所述

和

是否满足

如果是，则接纳所述上行承载请求，否则，拒绝所述上行承载请求，其中，所述

为预设的所述UEi的最大允许发射功率的线性值；所述η为预设的为所述UEi的功率传输预留的平均统计余量。本发明适应于LTE-A系统中对上行承载请求的接纳判决。

Description

上行承载请求的接纳判决方法

技术领域

本发明涉及移动通信技术，特别是涉及LTE－A系统中上行承载请求的接纳判决方法。

背景技术

目前在LTE系统中，由于用户上行存在最大发射功率的限制，当用户向网络侧请求承载时，网络侧需要根据用户剩余功率的资源大小，来对是否接纳用户的承载请求做出合理的判决。在现有的承载请求接纳判决方法中，采用的判决公式为P_{i_PUSCH}≤ηP_i，max,其中P_{i_PUSCH}(dBm)为UE所需要的发射功率，P_i,max表示用户i的最大允许发射功率的线性值；η表示为功率传输所预留的平均统计余量。

但是，与以往的系统不同，LTE-A系统支持载波聚合技术，并且支持物理上行控制信道（PUCCH）和物理上行共享信道（PUSCH）同时传输。而上述传统的用户业务的接纳判决方法中，在估计UE所需要的发射功率时，只考虑单个载波并且PUSCH单独传输的情况，显然，上述方法将无法适用于PUCCH和PUSCH同时传输的情况。

由此可见，现有的上行承载请求接纳判决方法不适用于LTE-A系统。

发明内容

有鉴于此，本发明的主要目的在于提供一种上行承载请求的接纳判决方法，该方法适用于LTE-A系统。

为了达到上述目的，本发明提出的技术方案为：

一种上行承载请求的接纳判决方法，包括：

当网络侧接收到用户设备UEi的上行承载请求时，确定该UEi的PUSCH上传输数据所需要功率的线性值

确定该UEi的PUCCH上传输控制信息所需要功率的线性值

判断所述

和

是否满足

如果是，则接纳所述上行承载请求，否则，拒绝所述上行承载请求，其中，所述

为预设的所述UEi的最大允许发射功率的线性值；所述η为预设的为所述UEi的功率传输预留的平均统计余量。

综上所述，本发明提出的上行承载请求的接纳判决方法，针对LTE-A系统支持多个载波聚合且PUCCH和PUSCH同时传输的特性，对用户的PUCCH的发射功率需求和PUSCH的发射功率需求分别求相应的线性值，然后将两者相加作为对用户发射功率的估算，从而可准确估算出用户已接纳承载占用的发射功率和请求承载需要的发射功率，进而可对是否接纳承载请求进行准确判断。因此本发明适应于支持多个载波聚合且PUCCH和PUSCH同时传输的LTE-A系统中。

附图说明

图1为本发明实施例一的流程示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图及具体实施例对本发明作进一步地详细描述。

本发明的核心思想是：针对LTE-A系统支持多个载波聚合且PUCCH和PUSCH同时传输的特性，本发明在估计UE所需要的发射功率时，将同时考虑PUCCH和PUSCH上发射功率的需求，即对用户的PUCCH的发射功率需求和PUSCH的发射功率需求分别求相应的线性值，然后将两者相加作为对该用户的发射功率的估算，从而可准确估算出用户已接纳承载占用的发射功率和请求承载需要的发射功率，最后将该估算结果和用户的最大发射功率限制相比较，来判决是否接纳用户的上行承载请求。

图1为本发明实施例一的流程示意图，如图1所示，该实施例主要包括：

步骤101、当网络侧接收到用户设备UEi的上行承载请求时，确定该UEi的PUSCH上传输数据所需要功率的线性值

确定该UEi的PUCCH上传输控制信息所需要功率的线性值

本步骤中，将分别确定PUSCH和PUCCH上所需功率的线性值

和

以便此后根据二者来准确估算用户的发射功率，从而可以基于此对是否接纳用户设备的承载请求进行准确判断。

较佳地，可以采用下述方法来确定UEi的PUSCH上传输数据所需要功率的线性值

首先，按照

计算所述UEi已经接纳承载和新申请接纳承载所需要的物理资源块PRB数量N_i。

其中，P_{i_average}为所述UEi所有激活载波的平均传输效率，GBR_m为已接纳的所述UEi的第m个保证比特速率（GBR）业务承载的保证比特速率，M为已接纳的所述UEi的GBR业务总数；MinBR_n为已接纳的所述UE i的第n个Non-GBR业务的需求比特速率，N为已接纳的所述UEi的非保证比特速率（Non-GBR）业务总数，ΔR为所述UEi当前请求接纳承载需要的比特速率总和，具体地，当请求业务为GBR业务时，该值为请求业务的保证比特速率，当请求业务为Non-GBR业务时，该值为请求业务的需求比特速率。

这里，需要说明的是，对于具有数据突发特性的Non-GBR业务来说，虽然QoS指标里面没有比特速率方面的要求，但是可以根据业务类型和要求，对Non-GBR业务进行建模后，通过仿真来统计确定该业务的分组时延满意度或分组丢失率达到一定的百分比情况下，所需要的适当比特速率需求MinBR_n，然后以MinBR_n作为Non-GBR业务的需求比特速率，MinBR_n的具体设置方法已为本领域人员所掌握，在此不再赘述。

然后，利用所述N_i，按照P_{i_PUSCH}＝10log₁₀(N_i)+P_{O_PUSCH}+α·PL_i+Δ_TF+f(s)，计算在PUSCH上所述UEi所需要的发射功率P_{i_PUSCH}。

其中，所述P_{0_PUSCH}为预设的所述UEi所在激活载波小区专属的PUSCH发射功率初始值，这里取多个激活载波的平均值。

所述α为预设的所述UEi所在激活载波小区的路损补偿系数平均值，α∈{0,0.4,0.5,0.6,0.7,0.8,0.9,1}，是一个3bit高层配置的小区级参数。

所述PL_i为所述UEi的所有激活载波小区的下行路损平均值。

所述Δ_TF为与UEi的调制编码MCS格式对应的传输效率调整系数，具体由高层配置。

f(s)为当前子帧的PUSCH发送功率调整值；s为当前子帧的编号。

需要说明的是，上述P_{0_PUSCH}、α、PL_i和Δ_TF等参数的设置或计算方法，同现有系统，在此不再赘述。

最后，利用所述P_{i_PUSCH}，按照

计算所述

较佳地，可以按照下述方法确定UEi的PUCCH上传输控制信息所需要功率的线性值

首先，利用当前上行子帧对应的下行子帧的HARQ反馈的比特数n_HARQ，按照

计算PUCCH格式关系值h(n_CQI,n_HARQ,n_SR)。

这里，需要说明的是，h(n_CQI,n_HARQ,n_SR)为PUCCH格式关系值，在现有系统中不同PUCCH格式的计算公式不同，在进行接纳判决时，PUCCH的格式还不确定，所以在这里将选取最大值的情况，即按照

计算h(n_CQI,n_HARQ,n_SR)，如此，可以涵盖所有PUCCH格式的情况，并使本发明的具体实现更加简单。

然后，利用所述h(n_CQI,n_HARQ,n_SR)，按照P_{i_PUCCH}=P_{0_PUCCH}+PL_i+h_i(n_CQI,n_HARQ,n_SR)+Δ_{F_PUCCH}+Δ_TxD+g(s)，计算在PUCCH上所述UEi所需要的发射功率P_{i_PUCCH}。

其中，所述P_{0_PUCCH}为预设的所述UEi所在激活载波小区专属的PUCCH发射功率初始值，这里取多个激活载波的平均值；所述PL_i为所述UEi的所有激活载波小区的下行路损平均值。

所述Δ_{F_PUCCH}为预设的与所述UEi的PUCCH格式对应的第一功率调整系数，其值可由高层配置。

Δ_TxD(F')为预设的与所述UEi的天线模式和PUCCH格式对应的第二功率调整系数，具体地，如果UE配置为2天线端口发送PUCCH，每种PUCCH格式对应的Δ_TxD(F')值由高层配置，否则Δ_TxD(F')＝0。

g(s)为当前子帧PUCCH的发送功率的调整值，s为当前子帧的编号。

需要说明的是，上述P_{0_PUCCH}、PL_i、Δ_{F_PUCCH}、Δ_TxD(F')和g(s)等参数的具体配置或获取方法同现有系统，在此不再赘述。

最后，利用所述P_{i_PUCCH}，按照

计算所述

步骤102、判断所述

和

是否满足

如果是，则接纳所述上行承载请求，否则，拒绝所述上行承载请求。

这里，所述为预设的所述UEi的最大允许发射功率的线性值。

所述η为预设的为所述UEi的功率传输预留的平均统计余量，其取值范围为（0，1）。η的具体配置方法同现有系统，即η的取值根据调度算法进行合理的功率预留，保证一定百分比的TTI子帧内的发射功率值不会超过其最大发射功率值为准，具体的，η的取值可以由仿真得到，仿真过程中，根据特定的调度算法，计算一定时间周期内，UE在特定的上行传输比特速率要求下，其PRB在TTI上的数量分布情况，以此进行合理确定。例如，UE上行比特速率要求是10K时，对某个特定的调度算法进行仿真，发现其中80％以上传输数据的TTI子帧上，上行传输速率达到了12K以上，则可以设置功率余量为η=10/12=83％。

综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (3)

1.一种上行承载请求的接纳判决方法，其特征在于，包括：

当网络侧接收到用户设备UEi的上行承载请求时，确定该UEi的物理上行共享信道PUSCH上传输数据所需要功率的线性值

确定该UEi的持物理上行控制信道PUCCH上传输控制信息所需要功率的线性值

判断所述

和是否满足

如果是，则接纳所述上行承载请求，否则，拒绝所述上行承载请求，其中，所述为预设的所述UEi的最大允许发射功率的线性值；所述η为预设的为所述UEi的功率传输预留的平均统计余量。

2.根据权利要求1所述的方法，其特征在于，所述确定该UEi的PUSCH上传输数据所需要功率的线性值

包括：

按照

计算所述UEi已经接纳承载和新申请接纳承载所需要的物理资源块PRB数量N_i；其中，P_{i_average}为所述UEi所有激活载波的平均传输效率，GBR_m为已接纳的所述UEi的第m个GBR业务承载的保证比特速率，M为已接纳的所述UEi的GBR业务总数；MinBR_n为已接纳的所述UEi的第n个Non-GBR业务的需求比特速率，N为已接纳的所述UEi的Non-GBR业务总数，ΔR为所述UEi当前请求接纳承载需要的比特速率总和；

按照P_{i_PUSCH}=10log₁₀(N_i)+P_{O_PUSCH}+α·PL_i+Δ_TF+f(s)，计算在PUSCH上所述UEi所需要的发射功率P_{i_PUSCH}；其中，所述P_{0_PUSCH}为预设的所述UEi所在激活载波小区专属的PUSCH发射功率平均初始值，所述α为预设的所述UEi所在激活载波小区的路损补偿系数平均值；所述PL_i为所述UEi的所有激活载波小区的下行路损平均值；所述Δ_TF为与所述UEi的调制编码（MCS）格式对应的传输效率调整系数；f(s)为当前子帧的PUSCH发送功率调整值；s为当前子帧的编号；

按照

计算所述

3.根据权利要求1所述的方法，其特征在于，所述确定该UEi的PUCCH上传输控制信息所需要功率的线性值

包括：

利用当前上行子帧对应的下行子帧的HARQ反馈的比特数n_HARQ，按照

计算PUCCH格式关系值h(n_CQI,n_HARQ,n_SR)；

利用所述h(n_CQI,n_HARQ,n_SR)，按照P_{i_PUCCH}=P_{0_PUCCH}+PL_i+h_i(n_CQI,n_HARQ,n_SR)+Δ_{F_PUCCH}+Δ_TxD+g(s)，计算在PUCCH上所述UEi所需要的发射功率P_{i_PUCCH}；其中，所述P_{0_PUCCH}为预设的所述UEi所在激活载波小区专属的PUCCH发射功率平均初始值；所述PL_i为所述UEi的所有激活载波小区的下行路损平均值；所述Δ_{F_PUCCH}为预设的与所述UEi的PUCCH格式对应的第一功率调整系数；Δ_TxD(F')为预设的与所述UEi的PUCCH格式和天线模式对应的第二功率调整系数；g(s)为当前子帧PUCCH的发送功率的调整值，s为当前子帧的编号；

利用所述P_{i_PUCCH}，按照

计算所述

Images