CN102917401A

CN102917401A - 上行资源请求方法与用户设备

Info

Publication number: CN102917401A
Application number: CN2012103832903A
Authority: CN
Inventors: 方晓波; 钟展辉; 朱文博; 蒋诗梅
Original assignee: Innofidei Technology Co Ltd
Priority date: 2012-10-10
Filing date: 2012-10-10
Publication date: 2013-02-06
Anticipated expiration: 2032-10-10
Also published as: CN102917401B

Abstract

本申请提供了一种上行资源请求方法与用户设备，其中，上行资源请求方法包括：获取当前上行缓冲区的上行缓冲区大小，其中，所述当前上行缓冲区中存储有用户设备待上传的数据；判断所述上行缓冲区大小是否小于设定门限值；若是，则根据所述用户设备的历史上行缓冲区大小和/或本次上传所述待上传的数据的数据帧结构，进行上报缓冲区大小估计，获得缓冲区大小综合评估值；根据所述缓冲区大小综合评估值生成缓冲区状态报告；向基站上报所述缓冲区状态报告，以请求上传所述待上传的数据所需要的上行资源。通过本申请，使得UE上传业务的业务流量更加稳定、也提升了平均流量，保持了业务的稳定性。

Description

上行资源请求方法与用户设备

技术领域

本申请涉及通信技术领域，特别是涉及一种上行资源请求方法与用户设备。

背景技术

第三代移动通信技术后的LTE（Long Time Evolution，长期演进）系统中，在多UE（User Equipment，用户设备）环境下，多个UE之间需要竞争上行资源，以实现上行数据传输。

当UE需要上传数据时，使用SR（Scheduling Request，调度请求）以请求上行共享信道资源供发送上行数据所用。当eNB（Evolved NodeB，演进型基站）收到SR后，还需要UE上报具体的资源需求量以向UE提供上行资源。UE通过BSR（Buffer Status Report，缓冲区状态报告）上报具体的资源需求量。不仅UE发送上行数据必须有上行资源，用于UE要求被调度分配上行资源的BSR也是需要资源来发送的。目前，采用在PUCCH（PhysicalUplink Control CHannel，物理上行链路控制信道）上发送SR或者通过PRACH（Physical Random Access CHannel，物理随机接入信道）发送SR以请求用于发送BSR的上行资源。上行数据的传输需要的资源通过BSR来获得，BSR过程用于给eNB提供UE共有多少数据存在上行的缓冲区里待发送。

目前LTE系统中上行链路主要采用动态资源分配机制，基于上述过程的上行资源调度需要经过以下几个步骤：

步骤1：当UE有发送数据的需求时，通过发送SR向eNB请求上行资源。此时UE只通知eNB有资源需求，步骤3中再通知具体的资源需求量。

步骤2：eNB收到SR后，给UE调度一个较小的上行授权（uplink grant，UL grant），供UE上报具体的资源需求量使用。

步骤3：UE使用eNB分配的UL grant，根据业务情况，通过发送BSR的MAC（Medium Access Control，介质访问控制）控制信息单元上报具体的资源需求量。

步骤4：eNB根据上行信道质量测量结果和UE上报的BSR，按照某种资源调度策略，进行上行资源分配，给UE分配一个较大的UL grant。

步骤5：UE接收资源分配结果的UL grant通知后，按照调度策略对各种业务数据进行资源分配，同一个逻辑信道则按照先后顺序进行资源分配。

上述上行资源调度方案中，由于UE上报的BSR完全取决于当前的业务数据量，而没有考虑UE上报BSR之后到UE接收eNB分配的较大的UL grant这一段时间内的新增的业务量，不利于保持UE业务的稳定性（如造成UE业务流量不稳定、平均流量低等）。例如，UE有可能上报的BSR为0，而实际在UE上报BSR之后到UE接收eNB分配的UL grant这一段时间内有新增的业务量，这种情况下就有可能需要多次通过SR的方式来申请上行调度，获得上行资源，从而造成UE业务流量不稳定、平均流量低等问题。

发明内容

本申请提供了一种上行资源请求方法与用户设备，以解决现有上行资源调度方案没有考虑UE上报BSR之后到UE接收eNB分配的UL grant这一段时间内的新增的业务量，不利于保持UE业务的稳定性的问题。

为了解决上述问题，本申请公开了一种上行资源请求方法，包括：

获取当前上行缓冲区的上行缓冲区大小，其中，所述当前上行缓冲区中存储有用户设备待上传的数据；

判断所述上行缓冲区大小是否小于设定门限值；

若是，则根据所述用户设备的历史上行缓冲区大小和/或本次上传所述待上传的数据的数据帧结构，进行上报缓冲区大小估计，获得缓冲区大小综合评估值；

根据所述缓冲区大小综合评估值生成缓冲区状态报告；

向基站上报所述缓冲区状态报告，以请求上传所述待上传的数据所需要的上行资源。

为了解决上述问题，本申请还公开了一种用户设备，包括：

获取模块，用于获取当前上行缓冲区的上行缓冲区大小，其中，所述当前上行缓冲区中存储有用户设备待上传的数据；

判断模块，用于判断所述上行缓冲区大小是否小于设定门限值；

预估模块，用于若所述判断模块的判断结果为是，则根据所述用户设备的历史上行缓冲区大小和/或本次上传所述待上传的数据的数据帧结构，进行上报缓冲区大小估计，获取缓冲区大小综合评估值；

请求模块，用于根据所述缓冲区大小综合评估值生成缓冲状态报告；向基站上报所述缓冲区状态报告，以请求上传所述待上传的数据所需要的上行资源。

与现有技术相比，本申请具有以下优点：

在LTE系统中，对于UE来说，维持业务的稳定性关键在于能够得到基站的连续调度。本申请中，在UE需要上报BSR时，若判断当前上行缓冲区大小小于设定门限值，则参考历史上行缓冲区大小和/或本次上传待上传的数据的数据帧结构，对下次处理UL grant前的上行缓冲区大小进行估计，给出缓冲区大小综合评估值，将缓冲区大小综合评估值上报给基站。对上报的上行缓冲区大小进行估计得到的缓冲区大小综合评估值，是对BSR上报到对应的UL grant到达这一段时间内的新增的业务量的合理预估，其不仅考虑了用户设备当前上传缓冲区中的业务数据量，还预估了BSR上报到对应的ULgrant到达时间段的可能业务量，从而使得基站能够为UE分配充足的上传资源，不必使UE为了小部分的新增业务量而重新发起资源请求流程，使得UE上传业务的业务流量更加稳定、也提升了平均流量，保持了业务的稳定性。通过外场测试对比发现，未使用本申请方案时的ftp下载，下载速率平均67mbps，且毛刺较多，而使用本申请方案后，ftp下载的流量平稳许多，平均下载速率也提高到85mbps。

附图说明

图1是根据本申请实施例一的一种上行资源请求方法的步骤流程图；

图2是根据本申请实施例二的一种上行资源请求方法的步骤流程图；

图3是根据本申请实施例三的一种上行资源请求方法的步骤流程图；

图4是根据本申请实施例四的一种用户设备的结构框图；

图5是使用本申请实施例前的FTP下载数据示意图；

图6是使用本申请实施例后的FTP下载数据示意图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

实施例一

参照图1，示出了根据本申请实施例一的一种上行资源请求方法的步骤流程图。

本实施例的上行资源请求方法包括以下步骤：

步骤S102：UE获取当前上行缓冲区的上行缓冲区大小。

其中，当前上行缓冲区中存储有UE待上传的数据。

步骤S104：UE判断上行缓冲区大小是否小于设定门限值；若是，则执行步骤S106；若否，则根据上行缓冲区大小生成BSR，并向基站发送该BSR。

其中，设定门限值是需要达到某个预期平稳上行流量对应的ULgrant平均大小，可以由本领域技术人员根据实际情况适当设置，如根据经验值或者根据仿真数据或者根据测试统计结果等，本申请对此不作限制。

其中，根据上行缓冲区大小生成BSR，并向基站发送该BSR，具体可以理解为根据上行缓冲区大小，查表（如36.321协议中的BSR计算表）计算BSR值携带在BSR中上报给eNB，以向eNB请求上传大小为上行缓冲区大小的数据所需要的上行资源。具体可以参考相关现有技术，在此不再赘述。

步骤S106：UE根据UE的历史上行缓冲区大小和/或本次上传待上传的数据的数据帧结构，进行上报缓冲区大小估计，获取缓冲区大小综合评估值。

其中，缓冲区大小综合评估值表示根据当前UE缓冲区（UE BUFFER）的数据及在下一个ULgrant来到之前预期接收到的数据大小。

步骤S108：UE根据缓冲区大小综合评估值生成BSR。

步骤S110：向基站上报BSR，以请求上传待上传的数据所需要的上行资源。

在LTE系统中，对于UE来说，维持业务的稳定性关键在于能够得到基站的连续调度。本实施例中，在UE需要上报BSR时，若判断当前上行缓冲区大小小于设定门限值，则参考历史上行缓冲区大小和/或本次上传待上传的数据的数据帧结构，对下次处理UL grant前的上行缓冲区大小进行估计，给出缓冲区大小综合评估值，将缓冲区大小综合评估值上报给基站。对上报的上行缓冲区大小进行估计得到的缓冲区大小综合评估值，是对BSR上报到对应的UL grant到达这一段时间内的新增的业务量的合理预估，其不仅考虑了UE当前上传缓冲区中的业务数据量，还预估了BSR上报到对应的ULgrant到达时间段的可能业务量，从而使得基站能够为UE分配充足的上传资源，不必使UE为了小部分的新增业务量而重新发起资源请求流程，使得UE上传业务的业务流量更加稳定、也提升了平均流量，保持了业务的稳定性。通过外场测试对比发现，未使用本实施例方案时的ftp下载，下载速率平均67mbps，且毛刺较多，而使用本实施例方案后，ftp下载的流量平稳许多，平均下载速率也提高到85mbps。

实施例二

参照图2，示出了根据本申请实施例二的一种上行资源请求方法的步骤流程图。

本实施例的上行资源请求方法包括以下步骤：

步骤S202：UE收到基站的上行授权。

步骤S204：UE获取本次待上传的数据使用的当前上行缓冲区的上行缓冲区大小。

步骤S206：UE判断上行缓冲区大小是否小于设定门限值，若是，则执行步骤S208；若否，则根据该上行缓冲区大小生成BSR，并向基站发送该BSR。

其中，设定门限值可以由本领域技术人员根据实际情况适当设置，如根据经验值或者根据仿真数据或者根据测试统计结果等，本申请对此不作限制。

步骤S208：UE根据获取的当前上行缓冲区的上行缓冲区大小进行上行缓冲区大小估计，获取缓冲区大小综合评估值。

UE进行上行缓冲区大小估计时，可以根据UE中保存的历史上行缓冲区大小和/或UE本次上传所述待上传的数据的数据帧结构进行估计，获得待上报的上传缓冲区大小。其中，对于每一次上报的上传缓冲区大小，若本次上报的上行缓冲区大小进行过上报缓冲区大小估计，则UE中保存的是本次估计的缓冲区大小综合评估值；若本次未进行过上报缓冲区大小估计，则保存的是本次上报的实际上行缓冲区大小。也即，历史上行缓冲区大小中有可能包括往期的BSR综合评估值，同时也有可能包括往期的实际上行缓冲区大小。

例如，本步骤中，UE将多个历史上行缓冲区大小的均值作为上报的上行缓冲区大小；或者，对该均值进行处理（如通过设置的处理系数），将处理结果作为上报的上行缓冲区大小等。

此外，不同的帧结构，BSR的最短上报周期也不同，FDD（频分双工）和TDD CFG（时分双工配置）0、1、2、6是5ms，而TDD CFG3、4、5则是10ms，可以根据UE本次上传待上传数据使用的帧结构，设置相应的系数，对当前上行缓冲区大小进行处理后上报等。如，根据帧结构设置预估时长系数（如通过对不同帧结构的测试来确定并设置预估时长系数），使用预估时长系数进行上报缓冲区大小估计。

较为优选地，可以根据UE中存储的历史上行缓冲区大小和本次上传数据使用的帧结构进行上报缓冲区大小估计。如，使用预估时长系数乘以设定的历史上行缓冲区大小的均值对上报缓冲区大小进行估计，获取缓冲区大小综合评估值。

步骤S210：UE根据缓冲区大小综合评估值生成BSR，并向基站上报该BSR，以请求上传待上传数据所需要的上行资源。

UE通过BSR携带缓冲区大小综合评估值，请求基站为其分配缓冲区大小综合评估值指示的上行资源。

步骤S212：基站根据上行信道质量测量结果和UE上报的BSR，按照设定的资源调度策略，为UE分配与缓冲区大小综合评估值相适应的上行资源。

本步骤中，设定的资源调度策略可以参照现有技术中的资源调度策略，在此不再赘述。

步骤S214：UE接收资源分配结果的通知，按照设定的调度策略对待上传的数据分配资源，上传待上传的数据。

通过本实施例，如果生成BSR时获取的当前ul buffer size（上行缓冲区大小）小于门限值，需要考虑历史ul buffer size和/或帧结构，对下次处理ulgrant前的ul buffer size进行估计，给出缓冲区大小综合评估值，将综合评估值上报给基站。对上报的上行缓冲区大小进行估计得到的缓冲区大小综合评估值，是对BSR上报到对应的UL grant到达这一段时间内的新增的业务量的合理预估，其不仅考虑了UE当前上传缓冲区中的业务数据量，还预估了BSR上报到对应的UL grant到达时间段的可能业务量，从而使得基站能够为UE分配充足的上传资源，不必使UE为了小部分的新增业务量而重新发起资源请求流程，提高了LTE系统中多UE环境下移动通信终端业务的连续性，克服了现有方案中多UE环境下业务有不够稳定的可能性。

实施例三

参照图3，示出了根据本申请实施例三的一种上行资源请求方法的步骤流程图。

本实施例中，如果生成BSR时获取的当前ul buffer size（上行缓冲区大小）小于设定的门限值，则考虑历史ul buffer size和本次上传数据使用的帧结构，对下次处理ul grant前的ul buffer size进行估计，给出缓冲区大小综合评估值，根据缓冲区大小综合评估值生成BSR，将BSR上报给基站。并且，如果多次ul grant收到后没有数据发送，则取消缓冲区大小的综合评估，进入普通上报模式，也即现有的常规BSR上报模式。

本实施例的上行资源请求方法包括以下步骤：

步骤S302：UE向基站发送SR，请求上行资源。

步骤S304：基站收到SR，向UE返回上行授权ul grant。

步骤S306：UE的UMAC（上行MAC）收到ul grant开始调度流程，进行MAC SDU（Service Data Unit，业务数据单元）组包。

步骤S308：UE判断是否有ul grant浪费，若是，则ul grant浪费次数UlgrantWasteCount加1，执行步骤S310；若否，则置UlgrantWasteCount=0，执行步骤S310。

在ul grant充足却没有MAC SDU可组时，认为此ul grant被浪费，用ul grant浪费次数（UlgrantWasteCount）来评估ul grant的使用情况，其最大值为MAX_ULGRANT_WASTE_NUM。MAX_ULGRANT_WASTE_NUM的具体数值可由本领域技术人员根据实际情况适当设置，如设置为5次，本申请对此不作限制。

由于UE的调度器会先组MAC SDU，之后再计算上报给基站的BSR值，所以UlgrantWasteCount在组MAC SDU时更新，也即，上行授权浪费的次数在UE每次进行MAC SDU生成时更新，然后在计算BSR值时被用来作为打开和取消是否进行上报缓冲区大小估计的判断标准。UlgrantWasteCount初始为0；当ul grant收到后，如果ul grant足够大，但没有组MAC SDU，将UlgrantWasteCount加1；如果组了MAC SDU则将UlgrantWasteCount清0。也即，若UE本次收到ul grant后无MAC SDU生成，则上行授权浪费的次数加1，若UE本次有MAC SDU生成，则将上行授权浪费的次数清零。

步骤S310：UE判断是否需要上报BSR，若是，则执行步骤S312；若否，则结束本次BSR上报流程。

UE判断是否需要上报BSR的过程可以由本领域技术人员参照现有技术实现，在此不再赘述。

步骤S312：UE获取当前ul budffer size（上行缓冲区大小）；执行步骤S314。ul buffer size是UE的UMAC（上行MAC）在组完MAC SDU后查询URLC（Uplink Radio Link Control，上行RLC/上行无线链路控制）获取的，每个逻辑信道组需要记录各自的历史ul buffer size值。

步骤S314：UE判断ul buffer size是否低于设定门限值MIN_UL_BUFF_SIZE，若是，则执行步骤S316；若否，则执行步骤S318。

步骤S316：UE判断UlgrantWasteCount是否大于设定的上行授权浪费次数的最大值MAX_ULGRANT_WASTE_NUM，若否，执行步骤S322；若是，执行步骤S320。

也即，UE判断上行授权浪费（表示基站为UE分配了用于上传数据的上行资源而UE无数据上传）的次数（即UlgrantWasteCount）是否大于设定的上行授权浪费次数的最大值（即MAX_ULGRANT_WASTE_NUM），若是，则根据UE的历史上行缓冲区大小和/或本次上传待上传的数据的数据帧结构，进行上报缓冲区大小估计，根据估计结果生成BSR上报基站；若上行授权浪费的次数小于或等于设定次数，则UE根据当前上行缓冲区的上行缓冲区大小生成BSR并上报给基站。

步骤S318：UE将当前ul buffer size填进历史记录，执行步骤S320。

步骤S320：UE根据当前ul buffer size上报BSR，结束本次BSR上报流程。

即，若上行授权浪费的次数小于或等于设定次数时，则UE根据当前上行缓冲区的上行缓冲区大小生成BSR并上报给基站。

UlgrantWasteCount<=MAX_ULGRANT_WASTE_NUM时，说明ulgrant浪费不多，可以继续尝试综合评估上报BSR流程；如果ulgrant浪费次数已经达到最大次数，说明基站给UE资源足够，需要暂时取消综合评估，避免资源浪费。

步骤S322：UE进行上行缓冲区大小估计，获取缓冲区大小综合评估值，上报BSR，结束本次BSR上报流程。

本实施例中，根据UE的历史上行缓冲区大小和本次上传待上传的数据的数据帧结构，进行上行缓冲区大小估计，获取缓冲区大小综合评估值，生成BSR并上报基站。

UE的每个逻辑信道组需要记录各自的历史ul buffer size值，考虑算法的性能，设定只记录历史上最新的MAX_UL_BUFF_SIZE_RECORD_NUM个ul buffer size。MAX_UL_BUFF_SIZE_RECORD_NUM的值可以由本领域技术人员根据实际情况适当设置，MAX_UL_BUFF_SIZE_RECORD_NUM推荐为50。

进行上行缓冲区大小估计时取MAX_UL_BUFF_SIZE_RECORD_NUM个ul buffer size的均值AvgUlBuffSize。需要说明的是，当进行上行缓冲区大小估计时采集到历史记录不够MAX_UL_BUFF_SIZE_RECORD_NUM个时，使用当前已经采集到的历史记录做均值。一般来说，AvgUlBuffSize越大，综合评估出的缓冲区大小值越大。

并且，不同的帧结构导致当次上报BSR到其对应的ul grant分配的时间间隔不同，一般认为间隔时间越长，获取更多数据的可能性越大。另外不同的帧结构，BSR的最短上报周期也不同，FDD和TDD CFG 0、1、2、6是5ms，而TDD CFG3、4、5则是10ms。本实施例中，采用预估时长系数PreEstimatePara来衡量帧结构。PreEstimatePara大于0，PreEstimatePara越大，综合评估出的BSR值越大。PreEstimatePara具体大小可以由经验获取，对于FDD和TDD CFG 0、1、2、6可以取0.5-1.0，优选地，推荐使用0.8。

对于下次处理ul grant前的ul buffer size，即综合预估的ul buffer size设定为PreEstimateBuffSize，则本实施例中：

PreEstimateBuffSize=AvgUlBuffSize*PreEstimatePara。

本实施例中，在组BSR时，先获取当前ul buffer size，如果ul buffer size小于门限值（MIN_UL_BUFF_SIZE）时才考虑是否要打开缓冲区大小综合评估。如果UlgrantWasteCount小于或等于MAX_ULGRANT_WASTE_NUM，则打开缓冲区大小综合评估，需要进行缓冲区大小综合评估，将综合评估得到的缓冲区大小综合评估值上报给基站。否则，取消缓冲区大小综合评估。

只要没有打开缓冲区大小综合评估，都直接根据当前组BSR时获取的ul buffer size，查表（如36.321协议中的BSR计算表）计算BSR值上报给基站。

此外，在综合评估缓冲区大小时获取的ul buffer size，如小于门限值MIN_UL_BUFF_SIZE，不更新到历史记录中。也即，若缓冲区大小综合评估值大于或等于设定门限值MIN_UL_BUFF_SIZE，则UE使用该缓冲区大小综合评估值对历史上行缓冲区大小历史记录进行更新；若缓冲区大小综合评估值小于设定门限值MIN_UL_BUFF_SIZE，则UE不使用该缓冲区大小综合评估值对历史上行缓冲区大小历史记录进行更新。

在UE上报了BSR后，基站根据该BSR为UE分配上行资源，供UE上传待上传的数据。

在LTE系统中，对于UE来说，维持业务的稳定性关键在于能够得到基站的连续调度，本实施例在上报BSR时，参考了历史ul buffer size和帧结构，对下次处理uplink grant前的ul buffer size进行估计，给出缓冲区大小综合评估值，由缓冲区大小综合评估值生成BSR上报给基站。同时，为了避免uplinkgrant的浪费（即uplink grant足够，同时没有数据要组包），需要增加对综合评估取消的控制，本实施例用uplink grant浪费次数（UlgrantWasteCount）来评估uplink grant的使用情况，其最大值为(MAX_ULGRANT_WASTE_NUM)。UlgrantWasteCount在组MAC SDU时更新，然后在计算缓冲区大小时被用来作为打开和取消的判断标准，UlgrantWasteCount初始为0；当ulgrant收到后，如果uplink grant足够大，但没有组MAC SDU，将UlgrantWasteCount加1；如果组了MAC SDU则将UlgrantWasteCount清0。组BSR时，先获取当前ul buffer size，如果ul buffersize小于门限值（MIN_UL_BUFF_SIZE）时才考虑是否要打开缓冲区大小综合评估；如果UlgrantWasteCount小于等于MAX_ULGRANT_WASTE_NUM，则打开缓冲区大小综合评估，进行上行缓冲区大小估计，将综合评估进而得到的BSR值上报给基站，否则取消综合评估；如果没有打开缓冲区大小综合评估，都直接根据当前的ul buffer size，查表计算BSR值上报给基站。

通过本实施例，提供了一种提高LTE系统中多UE环境下移动通信终端保持业务连续性的方案，优化了上行性能以便尽可能地保持了业务稳定性，克服了现有方案中多UE环境下业务有不够稳定的可能性。

实施例四

参照图4，示出了根据本申请实施例四的一种UE的结构框图。

本实施例的UE中设置有上行资源请求装置，包括：获取模块402，用于获取当前上行缓冲区的上行缓冲区大小，其中，当前上行缓冲区中存储有UE待上传的数据；判断模块404，用于判断上行缓冲区大小是否小于设定门限值；预估模块406，用于若判断模块404的判断结果为是，则根据UE的历史上行缓冲区大小和/或本次上传待上传的数据的数据帧结构，进行上报缓冲区大小估计，获取缓冲区大小综合评估值；请求模块408，用于根据缓冲区大小综合评估值生成BSR；向基站上报BSR，以请求上传待上传的数据所需要的上行资源。

优选地，预估模块406具体用于在根据UE的历史上行缓冲区大小，进行上报缓冲区大小估计，获得缓冲区大小综合评估值时，取UE中保存的设定个数的历史上行缓冲区大小做平均，获得历史上行缓冲区大小均值；根据历史上行缓冲区大小均值，对当前上行缓冲区的上行缓冲区大小进行估计，获得缓冲区大小综合评估值。

优选地，所述设定个数为50。

优选地，预估模块406具体用于在根据UE的历史上行缓冲区大小，进行上报缓冲区大小估计时，若UE中保存的历史上行缓冲区大小的个数少于设定个数，则对UE中保存的历史上行缓冲区大小做平均，获得历史上行缓冲区大小均值。

优选地，预估模块406具体用于在根据本次上传待上传的数据的数据帧结构，进行上报缓冲区大小估计，获得缓冲区大小综合评估值时，根据本次上传待上传的数据的数据帧结构，设置预估时长系数；根据预估时长系数，进行上报缓冲区大小估计，获得缓冲区大小综合评估值。

优选地，当数据帧结构为FDD数据帧结构或为TDD CFG数据帧结构时，预估时长系数为0.5-1.0，推荐为0.8。

优选地，预估模块406具体用于在根据UE的历史上行缓冲区大小和本次上传待上传的数据的数据帧结构，进行上报缓冲区大小估计，获取缓冲区大小综合评估值时，获取UE中保存的设定个数的历史上行缓冲区大小的均值，或者，获取当UE中保存的历史上行缓冲区大小的个数少于设定个数时，UE中保存的历史上行缓冲区大小的均值；以及，获取根据本次上传待上传的数据的数据帧结构设置的预估时长系数；对历史上行缓冲区大小的均值和预估时长系数进行乘法操作，获取缓冲区大小综合评估值。

优选地，判断模块404还用于在确定上行缓冲区大小小于设定门限值之后，预估模块406根据UE的历史上行缓冲区大小和/或本次上传待上传的数据的数据帧结构，进行上报缓冲区大小估计，获得缓冲状态报告缓冲区大小综合评估值之前，判断上行授权浪费的次数是否大于设定次数，并确定上行授权浪费的次数大于设定次数；此时预估模块406根据UE的历史上行缓冲区大小和/或本次上传待上传的数据的数据帧结构，进行上报缓冲区大小估计；其中，上行授权浪费表示基站为UE分配了用于上传数据的上行资源而UE无数据上传。

优选地，请求模块408还用于当预估模块406判断上行授权浪费的次数小于或等于设定次数时，根据当前上行缓冲区的上行缓冲区大小生成BSR并向基站上报BSR。

优选地，上行授权浪费的次数初始为0；UE还包括：更新模块410，用于在每次进行MAC SDU生成时更新上行授权浪费的次数，若UE本次无MAC SDU生成，则上行授权浪费的次数加1，若UE本次有MAC SDU生成，则将上行授权浪费的次数清零。

优选地，本实施例的UE还包括：更新模块410，还用于在预估模块406获取缓冲区大小综合评估值之后，若确定缓冲区大小综合评估值大于或等于设定门限值，则使用BSR综合评估值对历史上行缓冲区大小进行更新；若确定缓冲区大小综合评估值小于设定门限值，则不使用BSR综合评估值对历史上行缓冲区大小进行更新。

本实施例的UE用于实现前述多个方法实施例中相应的上行资源请求方法，并具有相应的方法实施例的有益效果，在此不再赘述。

本申请提供了一种提高LTE系统中多UE环境下移动通信终端保持业务连续性的方案，克服了现有方案中多UE环境下业务有不够稳定的可能性，经外场测试对比发现，本申请的方案达到了更好的效果。如图5所示，是使用本申请方案前的FTP下载数据示意图，图5中，“Data Transfer”表示数据传输，其中“Download”表示下载，“Upload”表示上传，从图中可见，未使用本申请方案的FTP下载中，平均传输速率（Average transfer rate）中的平均下载速率为67.98mbps，且从图下方的“DU Meter”可见，毛刺较多。与图5相对应，图6是使用本申请方案后的FTP下载数据示意图，从图6中可见，使用本申请方案后，平均下载速率为85.36mbps，且流量平稳许多。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置实施例UE而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上对本申请所提供的一种上行资源请求方法和UE进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种上行资源请求方法，其特征在于，包括：

判断所述上行缓冲区大小是否小于设定门限值；

根据所述缓冲区大小综合评估值生成缓冲区状态报告；

2.根据权利要求1所述的方法，其特征在于，根据所述用户设备的历史上行缓冲区大小，进行上报缓冲区大小估计，获得缓冲区大小综合评估值的步骤包括：

对所述用户设备中保存的历史上行缓冲区大小做平均，获得历史上行缓冲区大小均值；

根据所述历史上行缓冲区大小均值，进行上报缓冲区大小估计，获得缓冲区大小综合评估值。

3.根据权利要求1所述的方法，其特征在于，根据本次上传所述待上传的数据的数据帧结构，进行上报缓冲区大小估计，获得缓冲区大小综合评估值的步骤包括：

根据本次上传所述待上传的数据的数据帧结构，设置预估时长系数；

根据所述预估时长系数，进行上报缓冲区大小估计，获得缓冲区大小综合评估值。

4.根据权利要求3所述的方法，其特征在于，当所述数据帧结构为频分双工数据帧结构或为时分双工配置0、时分双工配置1、时分双工配置2、时分双工配置6数据帧结构时，所述预估时长系数为0.5-1.0。

5.根据权利要求1所述的方法，其特征在于，根据所述用户设备的历史上行缓冲区大小和本次上传所述待上传的数据的数据帧结构，进行上报缓冲区大小估计，获取缓冲区大小综合评估值的步骤包括：

获取所述用户设备中保存的设定个数的历史上行缓冲区大小的均值，或者，获取当所述用户设备中保存的历史上行缓冲区大小的个数少于所述设定个数时，所述用户设备中保存的所述历史上行缓冲区大小的均值；以及，获取根据本次上传所述待上传的数据的数据帧结构设置的预估时长系数；

对所述历史上行缓冲区大小的均值和所述预估时长系数进行乘法操作，获取所述缓冲区大小综合评估值。

6.根据权利要求1所述的方法，其特征在于，在判断所述上行缓冲区大小小于所述设定门限值之后，根据所述用户设备的历史上行缓冲区大小和/或本次上传所述待上传的数据的数据帧结构，进行上报缓冲区大小估计，获得缓冲状态报告缓冲区大小综合评估值之前，还包括：

判断上行授权浪费的次数是否大于设定次数，并确定所述上行授权浪费的次数大于所述设定次数；

其中，所述上行授权浪费表示基站为所述用户设备分配了用于上传数据的上行资源而所述用户设备无数据上传。

7.根据权利要求6所述的方法，其特征在于，还包括：

若所述上行授权浪费的次数小于或等于所述设定次数，则所述用户设备根据所述当前上行缓冲区的上行缓冲区大小生成缓冲状态报告；

并向所述基站上报所述缓冲状态报告。

8.根据权利要求1所述的方法，其特征在于，在所述获取缓冲区大小综合评估值的步骤之后，还包括：

若所述缓冲区大小综合评估值大于或等于所述设定门限值，则所述用户设备使用所述缓冲区大小综合评估值对所述历史上行缓冲区大小进行更新。

9.一种用户设备，其特征在于，包括：

10.根据权利要求9所述的用户设备，其特征在于，所述预估模块，具体用于在根据所述用户设备的历史上行缓冲区大小，进行上报缓冲区大小估计，获得缓冲区大小综合评估值时，对所述用户设备中保存的历史上行缓冲区大小做平均，获得历史上行缓冲区大小均值；根据所述历史上行缓冲区大小均值，对所述当前上行缓冲区的上行缓冲区大小进行估计，获得缓冲区大小综合评估值。

11.根据权利要求9所述的用户设备，其特征在于，所述预估模块，具体用于在根据本次上传所述待上传的数据的数据帧结构，进行上报缓冲区大小估计，获得缓冲区大小综合评估值时，根据本次上传所述待上传的数据的数据帧结构，设置预估时长系数；根据所述预估时长系数，进行上报缓冲区大小估计，获得缓冲区大小综合评估值。

12.根据权利要求11所述的用户设备，其特征在于，当所述数据帧结构为频分双工数据帧结构或为时分双工配置0、时分双工配置1、时分双工配置2、时分双工配置6数据帧结构时，所述预估时长系数为0.5-1.0。

13.根据权利要求9所述的用户设备，其特征在于，所述预估模块，具体用于在根据所述用户设备的历史上行缓冲区大小和本次上传所述待上传的数据的数据帧结构，进行上报缓冲区大小估计，获取缓冲区大小综合评估值时，获取所述用户设备中保存的设定个数的历史上行缓冲区大小的均值，或者，获取当所述用户设备中保存的历史上行缓冲区大小的个数少于所述设定个数时，所述用户设备中保存的所述历史上行缓冲区大小的均值；以及，获取根据本次上传所述待上传的数据的数据帧结构设置的预估时长系数；对所述历史上行缓冲区大小的均值和所述预估时长系数进行乘法操作，获取所述缓冲区大小综合评估值。

14.根据权利要求9所述的用户设备，其特征在于，所述判断模块，还用于在确定所述上行缓冲区大小小于所述设定门限值之后，所述预估模块根据所述用户设备的历史上行缓冲区大小和/或本次上传所述待上传的数据的数据帧结构，进行上报缓冲区大小估计，获得缓冲状态报告缓冲区大小综合评估值之前，判断上行授权浪费的次数是否大于设定次数，并确定所述上行授权浪费的次数大于所述设定次数；其中，所述上行授权浪费表示基站为所述用户设备分配了用于上传数据的上行资源而所述用户设备无数据上传。

15.根据权利要求14所述的用户设备，其特征在于，所述请求模块，还用于当所述预估模块判断所述上行授权浪费的次数小于或等于所述设定次数时，根据所述当前上行缓冲区的上行缓冲区大小生成缓冲状态报告并向基站上报所述缓冲状态报告。

16.根据权利要求9所述的用户设备，其特征在于，还包括：

更新模块，用于在所述预估模块获取缓冲区大小综合评估值之后，若确定所述缓冲区大小综合评估值大于或等于所述设定门限值，则使用所述缓冲区大小综合评估值对所述历史上行缓冲区大小进行更新。