一种上行联合接收方法及基站与流程

文档序号:14594520发布日期:2018-06-05 03:40阅读:254来源:国知局

本发明涉及无线通信技术,具体涉及一种上行联合接收方法及基站。



背景技术:

上行联合接收技术通过多个小区间对调度信息和接收信号的交互,可以实现多个小区天线同时对单个用户上行信号的联合接收(被多小区联合接收的用户通常称为协作用户)。对边缘用户的上行联合接收等同于提升上行覆盖。

现有上行联合技术仅能应用在同基站的不同小区间。跨基站应用时,由于交互协作信息需要采用分组传送网(PTN,Packet Transport Network)传输,其跨基站传输带宽和传输时延无法满足基站上行处理时序的要求。目前如果需要跨基站实现上行联合接收技术,需要在基站间引入高速交换设备,各协作小区所在的基站均连接至此高速交换设备,实现跨基站高带宽、低时延的协作信息交互。但是引入跨基站的告诉交换设备会带来较高的成本。



技术实现要素:

为解决现有存在的技术问题,本发明实施例提供了一种上行联合接收方法及基站。

为达到上述目的,本发明实施例的技术方案是这样实现的:

本发明实施例提供了一种上行联合接收方法,所述方法包括:

基站确定终端的网络信号质量不满足预设条件,获得终端的上行数据调度请求;

基于所述上行数据调度请求确定与所述终端的承载属于需要进行上行增强的承载时,通过上行联合接收方式进行上行数据接收。

上述方案中,所述基于所述上行数据调度请求确定与所述终端的承载属于需要进行上行增强的承载,包括:

基于所述上行数据调度请求中所述终端申请的上行发送比特数判断与所述终端的承载是否属于需要进行上行增强的承载。

上述方案中,所述基于所述上行数据调度请求确定与所述终端的承载属于需要进行上行增强的承载,包括:

基于所述上行数据调度请求中所述终端申请的上行发送数据的逻辑信道组判断与所述终端的承载是否属于需要进行上行增强的承载。

上述方案中,所述基于所述上行数据调度请求确定与所述终端的承载属于需要进行上行增强的承载之后,所述方法还包括:

所述基站基于所述终端上报的第一测量报告为所述终端选择协作小区;

所述基站将所述终端的协作信息发送至所述协作小区;所述协作信息包括:上行信道配置信息和/或上行调度的物理资源块信息。

上述方案中,所述基站将所述终端的协作信息发送至所述协作小区,包括:

当选择的协作小区与服务小区为不同基站对应的小区时,所述基站通过X2接口发送所述协作信息至所述协作小区。

本发明实施例还提供了一种基站,所述基站包括:通讯单元和数据处理单元;其中,

所述数据处理单元,用于确定终端的网络信号质量不满足预设条件;

所述通讯单元,用于获得终端的上行数据调度请求;

所述数据处理单元,还用于基于所述上行数据调度请求判断与所述终端的承载是否属于需要进行上行增强的承载;

所述通讯单元,还用于所述数据处理单元确定与所述终端的承载属于需要进行上行增强的承载时,通过上行联合接收方式进行上行数据接收。

上述方案中,所述数据处理单元,用于基于所述上行数据调度请求中所述终端申请的上行发送比特数判断与所述终端的承载是否属于需要进行上行增强的承载。

上述方案中,所述数据处理单元,用于基于所述上行数据调度请求中所述终端申请的上行发送数据的逻辑信道组判断与所述终端的承载是否属于需要进行上行增强的承载。

上述方案中,所述数据处理单元,还用于基于所述上行数据调度请求判断与所述终端的承载是否属于需要进行上行增强的承载之后,基于所述终端上报的第一测量报告为所述终端选择协作小区;

所述通讯单元,还用于将所述终端的协作信息发送至所述协作小区;所述协作信息包括:上行信道配置信息和/或上行调度的物理资源块信息。

上述方案中,所述通讯单元,用于当选择的协作小区与服务小区为不同基站对应的小区时,通过X2接口发送所述协作信息至所述协作小区。

本发明实施例提供的上行联合接收方法及基站,所述方法包括:基站确定终端的网络信号质量不满足预设条件,获得终端的上行数据调度请求;基于所述上行数据调度请求确定与所述终端的承载属于需要进行上行增强的承载时,通过上行联合接收方式进行上行数据接收。如此,采用本发明实施例的技术方案,实现了在不新增硬件设备的前提下,在现有PTN带宽条件内实现跨基站上行联合接收方案,提高弱场VoLTE业务信令的传输可靠性和起呼成功率,或可提高VoLTE业务包上行传输效率,减少丢包和吞字、单通的出现。

附图说明

图1为现有技术中上行联合接收实现方案的示意图;

图2为现有技术中上行联合接收方案的信息交互示意图;

图3为本发明实施例一的上行联合接收方法的流程示意图;

图4为本发明实施例二的上行联合接收方法的流程示意图;

图5为本发明实施例的上行联合接收方案的信息交互示意图;

图6为本发明实施例的基站的组成结构示意图。

具体实施方式

发明人发现,现有长期演进(LTE,Long Term Evolution)网络中,已经出现基于IMS的语音业务(VoLTE,Voice over LTE)业务起呼的上行信令在弱场无法成功发送的问题,导致弱场VoLTE起呼成功率低;或出现弱场VoLTE业务上行传输效率低产生丢包,从而导致VoLTE通话吞字、单通的情况。弱场需要增强上行覆盖,提升VoLTE信令和业务数据包的传输效率,而大部分的上行覆盖弱场存在于不同基站的小区边界处。图1为现有技术中上行联合接收实现方案的示意图;如图1所示,包括:

步骤1、服务小区对接入的所有终端下发协同多点传输(CoMP,Coordinated Multiple Points)的A3事件的测量控制信息,测量控制条件为同频邻区参考信号接收功率(RSRP,Reference Signal Receiving Power)与服务小区RSRP的差值在门限1内;

步骤2、处于小区边缘的终端根据CoMP A3测量控制信息,上报测量报告,服务小区选取测量报告中信号最强的小区作为协作小区;

步骤3、服务小区将上报测量报告的协作用户的上行信道配置(主要为信道探测参考信号(SRS,Sounding Reference Signal)发送周期和发送位置)、上行调度的物理资源块(PRB,Physical Resource Block)信息告知协作小区;

步骤4、协作小区根据SRS配置对协作用户进行信道测量;

步骤5、协作小区根据信道测量结果,在服务小区调度协作用户的相同PRB上,解调协作用户上行接收信号,并将解调软信息发送给服务小区,由服务小区进行软信息合并。

上述方案中,如果步骤2中选取的协作小区与服务小区为不同基站下的小区,则步骤3中的协作信息交互和步骤5中的软信息交互的跨基站交互需要通过高速交换设备实现,具体可如图2所示。

下面结合附图及具体实施例对本发明作进一步详细的说明。

实施例一

本发明实施例提供了一种上行联合接收方法。图3为本发明实施例一的上行联合接收方法的流程示意图;如图3所示,所述方法包括:

步骤101:基站确定终端的网络信号质量不满足预设条件,获得终端的上行数据调度请求。

步骤102:基于所述上行数据调度请求确定与所述终端的承载属于需要进行上行增强的承载时,通过上行联合接收方式进行上行数据接收。

本实施例中,所述上行联合接收方法应用于基站中,终端在所述基站的网络覆盖范围内;所述基站可以为所述终端的服务基站。

本实施例中,所述基站在与终端的承载建立后,所述基站可基于所述终端上报的测量报告判断所述终端的网络信号质量是否满足预设条件。作为一种实施方式,所述基站可基于所述终端上报的测量报告判断终端的网络信号参数是否低于预设阈值;当确定所述终端的网络信号参数低于所述预设阈值时,可确定所述终端的网络信号质量不满足预设条件。其中,所述网络信号参数可以为参考信号接收质量(RSRP,Reference Signal Receiving Power)。

本实施例中,基于所述基站与所述终端之间的承载,所述基站可接收所述终端的上行调度请求,基于所述上行调度请求判断与所述终端的承载是否是需要进行上行增强的特定承载。

作为一种实施方式,所述基于所述上行数据调度请求确定与所述终端的承载属于需要进行上行增强的承载,包括:基于所述上行数据调度请求中所述终端申请的上行发送比特数判断与所述终端的承载是否属于需要进行上行增强的承载。

具体的,基站可根据终端申请上行调度时的发送比特数,判定当前上行调度数据所属的承载是否属于需要进行上行增强的承载;例如,当所述终端申请上行调度的发送比特数在第一范围内时,判定所述上行调度的数据所在的承载属于需要进行上行增强的承载;相应的,当所述终端申请上行调度的发送比特数在第二范围内时,或者不在上述第一范围内时,判定所述上行调度的数据所在的承载属于不需要进行上行增强的承载。

作为另一种实施方式,所述基于所述上行数据调度请求确定与所述终端的承载属于需要进行上行增强的承载,包括:基于所述上行数据调度请求中所述终端申请的上行发送数据的逻辑信道组判断与所述终端的承载是否属于需要进行上行增强的承载。

具体的,基站可根据终端申请上行调度时的逻辑信道组判定当前上行调度数据所述的承载是否属于需要进行上行增强的承载;例如,当所述终端申请上行调度的逻辑信道组号与属于需要进行上行增强的承载所用的逻辑信道组号匹配时,判定所述上行调度的数据所在的承载属于需要进行上行增强的承载;相应的,当所述终端申请上行调度的逻辑信道组号与属于需要进行上行增强的承载所用的逻辑信道组号不匹配时,判定所述上行调度的数据所在的承载不属于需要进行上行增强的承载。

本实施例中,判定与所述终端的承载属于需要进行上行增强的承载时,所述基站可通过激活PTN并通过X2接口发送所述终端的协作信息至协作小区,从而通过协作小区的上行联合接收方式进行上行数据接收。

采用本发明实施例的技术方案,实现了在不新增硬件设备的前提下,在现有PTN带宽条件内实现跨基站上行联合接收方案,提高弱场VoLTE业务信令的传输可靠性和起呼成功率,或可提高VoLTE业务包上行传输效率,减少丢包和吞字、单通的出现。

实施例二

本发明实施例还提供了一种上行联合接收方法。图4为本发明实施例二的上行联合接收方法的流程示意图;如图4所示,所述方法包括:

步骤201:基站在与终端建立承载后、或所述基站对所述终端进行基于所述承载的首次上/下行调度时,向所述终端发送A2测量控制指令,所述A2测量控制指令对应的测量控制条件为终端在服务小区下的RSRP低于第一门限值;

步骤202:所述终端基于接收到的A2测量控制指令、向所述基站上报A2测量报告时,所述基站向所述终端发送CoMP A3测量控制指令,所述CoMP A3测量控制指令对应的测量控制条件为同频邻区RSRP与服务小区RSRP的差值在第二门限值内;

步骤203:处于小区边缘的终端根据CoMP A3测量控制指令,向所述基站上报测量报告,所述基站选取所述测量报告中信号最强的邻小区作为协作小区。

步骤204:所述基站基于所述终端的上行数据调度请求进行承载判定,判断所述上行数据调度请求是否属于承载i(承载i为属于需要进行上行增强的承载)时。

步骤205:当所述基站判定所述上行数据调度请求属于承载i时,将上报测量报告的所述终端的协作信息发送至协作小区;其中,所述协作信息包括上行信道配置信息(其中,上行信道配置信息主要为SRS发送周期和发送位置)和/或上行调度的PRB信息。

步骤206:协作小区所属基站根据所述协作信息(例如上行信道配置信息包括的SRS发送周期和发送位置)对协作用户(即所述终端)进行信道测量;协作小区所属基站根据信道测量结果,在服务小区调度协作用户的相同PRB上,解调所述协作用户(即所述终端)的上行接收信号,并将解调软信息发送至所述终端,由所述基站进行软信息合并。

本实施例中,所述基站作为所述终端的服务小区。

本实施例中,当协作小区所属基站与所述基站为不同基站时,所述基站与所述协作小区所属基站的信息交互(包括协作信息以及承载判定结果的交互以及解调软信息的交互等)可通过X2接口(即PTN)实现。图5为本发明实施例的上行联合接收方案的信息交互示意图;具体可参照图5所示,所述基站可通过X2接口结合现有的PTN设备与协作小区所属基站进行协作信息以及解调软信息的交互。

采用本发明实施例的技术方案,实现了在不新增硬件设备的前提下,在现有PTN带宽条件内实现跨基站上行联合接收方案,提高弱场VoLTE业务信令的传输可靠性和起呼成功率,或可提高VoLTE业务包上行传输效率,减少丢包和吞字、单通的出现。

实施例三

基于实施例一,本实施例针对当前数据调取所在承载是否属于需要进行上行增强的承载的一种判断方式进行进一步详述。具体的,针对VoLTE业务弱覆盖上行传输效率提升的需求,需要上行覆盖增强的承载是传输VoLTE业务包的QoS类别标识(QCI,QoS Class Identifier)1承载。服务小区所属基站可在QCI 1承载建立时启动本发明实施例一的方案。对已经建立QCI 1承载的终端,基站可根据终端申请上行调度时的发送比特数,判定所述上行调度所属的承载。例如,当所述终端申请上行调度的发送比特数为562比特(bit)左右(所述比特数在预先配置的第一范围内)时,所述基站可判定本次申请的上行调度属于QCI 1承载,可进行跨基站上行联合接收;相应的,当终端申请上行调度的发送比特数远大于562bit(该比特数不在所述第一范围内或者该比特数在预先配置的第二范围内)时,所述基站可判定本次申请的上行调度不属于QCI 1承载,或判定本次申请的上行调度属于除QCI 1承载外的其他承载,因而不进行跨基站上行联合接收。

实施例四

基于实施例一,本实施例针对当前数据调取所在承载是否属于需要进行上行增强的承载的另一种判断方式进行进一步详述。具体的,针对VoLTE业务弱覆盖上行传输效率提升的需求,需要上行覆盖增强的承载是传输VoLTE业务包的QCI 1承载。服务小区所属基站可在QCI 1承载建立时启动本发明实施例一的方案。对已经建立QCI 1承载的终端,基站可根据终端申请上行调度时的逻辑信道组号,判定所述上行调度所属的承载。例如:当所述终端申请上行调度的逻辑信道组号(当然,也可能为其他参数,指QCI 1语音包所映射的特定的逻辑信道组)与用于传输QCI 1数据所用的逻辑信道组号匹配一致时,基站可判定本次申请调度的数据属于QCI 1承载,可进行跨基站上行联合接收;相应的,当终端申请上行调度的逻辑信道组号与用于传输QCI 1数据所用的逻辑信道组号匹配不一致时,基站可判定本次申请调度的数据不属于QCI 1承载,因而本次不进行跨基站上行联合接收。

实施例五

本发明实施例提供了一种基站。图6为本发明实施例的基站的组成结构示意图;如图6所示,所述基站包括:通讯单元31和数据处理单元32;其中,

所述数据处理单元32,用于确定终端的网络信号质量不满足预设条件;

所述通讯单元31,用于获得终端的上行数据调度请求;

所述数据处理单元32,还用于基于所述上行数据调度请求判断与所述终端的承载是否属于需要进行上行增强的承载;

所述通讯单元31,还用于所述数据处理单元32确定与所述终端的承载属于需要进行上行增强的承载时,通过上行联合接收方式进行上行数据接收。

本实施例中,所述基站可以为终端的服务基站。

本实施例中,所述通讯单元31在与终端的承载建立后,所述数据处理单元32可基于所述终端上报的测量报告判断所述终端的网络信号质量是否满足预设条件。作为一种实施方式,所述数据处理单元32可基于所述终端上报的测量报告判断终端的网络信号参数是否低于预设阈值;当确定所述终端的网络信号参数低于所述预设阈值时,可确定所述终端的网络信号质量不满足预设条件。其中,所述网络信号参数可以为RSRP。

本实施例中,基于所述通讯单元31与所述终端之间的承载,所述通讯单元31可接收所述终端的上行调度请求,进一步地所述数据处理单元32基于所述上行调度请求判断与所述终端的承载是否是需要进行上行增强的特定承载。

作为一种实施方式,所述数据处理单元32,用于基于所述上行数据调度请求中所述终端申请的上行发送比特数判断与所述终端的承载是否属于需要进行上行增强的承载。

具体的,所述数据处理单元32可根据终端申请上行调度时的发送比特数,判定当前上行调度数据所属的承载是否属于需要进行上行增强的承载;例如,当所述终端申请上行调度的发送比特数在第一范围内时,判定所述上行调度的数据所在的承载属于需要进行上行增强的承载;相应的,当所述终端申请上行调度的发送比特数在第二范围内时,或者不在上述第一范围内时,判定所述上行调度的数据所在的承载属于不需要进行上行增强的承载。

作为另一种实施方式,所述数据处理单元32,用于基于所述上行数据调度请求中所述终端申请的上行发送数据的逻辑信道组判断与所述终端的承载是否属于需要进行上行增强的承载。

具体的,所述数据处理单元32可根据终端申请上行调度时的逻辑信道组判定当前上行调度数据所述的承载是否属于需要进行上行增强的承载;例如,当所述终端申请上行调度的逻辑信道组号与属于需要进行上行增强的承载所用的逻辑信道组号匹配时,判定所述上行调度的数据所在的承载属于需要进行上行增强的承载;相应的,当所述终端申请上行调度的逻辑信道组号与属于需要进行上行增强的承载所用的逻辑信道组号不匹配时,判定所述上行调度的数据所在的承载不属于需要进行上行增强的承载。

作为一种实施方式,所述数据处理单元32,还用于基于所述上行数据调度请求判断与所述终端的承载是否属于需要进行上行增强的承载之后,基于所述终端上报的第一测量报告为所述终端选择协作小区;

所述通讯单元31,还用于将所述终端的协作信息发送至所述协作小区;所述协作信息包括:上行信道配置信息和/或上行调度的物理资源块信息。

本实施例中,所述通讯单元31,用于当选择的协作小区与服务小区为不同基站对应的小区时,通过X2接口发送所述协作信息至所述协作小区。

本实施例中,当协作小区所属基站与所述基站为不同基站时,所述基站与所述协作小区所属基站的信息交互(包括协作信息以及承载判定结果的交互以及解调软信息的交互等)可通过X2接口(即PTN)实现,即所述通讯单元31可通过X2接口结合现有的PTN设备与协作小区所属基站进行协作信息以及解调软信息的交互,具体可如图5所示。

本发明实施例中,所述基站中的数据处理单元32,在实际应用中可由所述基站中的中央处理器(CPU,Central Processing Unit)、数字信号处理器(DSP,Digital Signal Processor)、微控制单元(MCU,Microcontroller Unit)或可编程门阵列(FPGA,Field-Programmable Gate Array)实现;所述基站中的通讯单元31,在实际应用中可通过通信模组(包含:基础通信套件、操作系统、通信模块、标准化接口和协议等)及收发天线实现。

在本申请所提供的几个实施例中,应该理解到,所揭露的设备和方法,可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,如:多个单元或组件可以结合,或可以集成到另一个系统,或一些特征可以忽略,或不执行。另外,所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口,设备或单元的间接耦合或通信连接,可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的,作为单元显示的部件可以是、或也可以不是物理单元,即可以位于一个地方,也可以分布到多个网络单元上;可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外,在本发明各实施例中的各功能单元可以全部集成在一个处理单元中,也可以是各单元分别单独作为一个单元,也可以两个或两个以上单元集成在一个单元中;上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:移动存储设备、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

或者,本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时,也可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括:移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以所述权利要求的保护范围为准。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1