CN102104974A

CN102104974A - 上行预调度处理方法、装置和系统

Info

Publication number: CN102104974A
Application number: CN2011100480880A
Authority: CN
Inventors: 朱俊; 王胜
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2011-02-28
Filing date: 2011-02-28
Publication date: 2011-06-22
Anticipated expiration: 2031-02-28
Also published as: CN102104974B; WO2012116604A1

Abstract

本发明实施例提供一种上行预调度处理方法、装置和系统。其中，方法，包括：获取用户设备的业务属性信息，所述业务属性信息用于判断所述用户设备是否可能发送突发上行数据；若根据所述业务属性信息确定所述用户设备可能发送突发上行数据，则对所述用户设备进行上行预调度处理。相对于现有技术需要通过8个TTI才能完成上行突发数据的调度来说，本发明实施例缩短了上行突发数据的调度时间，可以满足较高的时延需求以及QoS的需求。

Description

上行预调度处理方法、装置和系统

技术领域

本发明实施例涉及通信领域，尤其涉及一种上行预调度处理方法，装置和系统。

背景技术

用户设备(User Equipment，以下简称：UE)在向基站，例如eNodeB发送数据之前，需要得到基站的上行调度授权。

在现有技术中，基站一般采用周期性地为UE分配上行资源的方式，使UE在被分配的上行资源上发送数据。但是，UE时常需要突发性地向基站发送数据，例如UE在与网络侧设备进行文件传输协议(File Transfer Protocol，以下简称：FTP)业务时，需要突发性地向基站发送反馈ACK消息。如果此时UE并未得到基站的上行调度授权，则UE需要向基站发送调度请求指示(Schedule Request Identify，以下简称：SRI)消息，基站可以为UE分配上报缓冲区状态报告(Buffer State Report，以下简称：BSR)的资源，并通过上行授权(Uplink Grant，以下简称：UL Grant)通知UE。在4个传输时间间隔(Transmission Time Interval，以下简称：TTI)后，UE可以在该资源上上报BSR给基站；基站根据UE上报的BSR，为UE的上行数据分配上行传输资源；再在4个TTI后，UE将上行数据发送给基站。

由此可知，现有技术对于UE有突发上行数据的情况来说，至少需要8个TTI，才能完成UE的上行突发数据的调度操作，因此，现有技术对UE突发的上行数据的处理无法满足较高的时延需求，也无法满足业务质量(Quality of Service，以下简称：QoS)的需求。

中国专利申请CN101835262A公开了一种资源分配方法，包括：基站确定基站有空闲的可调度资源；基站判断用户设备UE是否有待传数据；若判断结果为UE有待传数据，则基站根据预先设置的预调度数据量主动给UE分配预调度资源。美国专利申请20090109912A1公开了一种预调度上行资源的方法和装置。其全部内容通过引用结合在本申请文件中。

发明内容

本发明实施例提供一种上行预调度处理方法、装置和系统，以使得对UE突发的上行数据的处理满足较高的时延需求。

本发明实施例提供一种上行预调度处理方法，包括：

获取用户设备的业务属性信息，所述业务属性信息用于判断所述用户设备是否可能发送突发上行数据；

若根据所述业务属性信息确定所述用户设备可能发送突发上行数据，则对所述用户设备进行上行预调度处理。

本发明实施例提供一种上行预调度处理装置，包括：

第一获取模块，用于获取用户设备的业务属性信息所述业务属性信息用于判断所述用户设备是否可能发送突发上行数据；

上行预调度模块，用于若根据所述业务属性信息确定所述用户设备可能发送突发上行数据，则对所述用户设备进行上行预调度处理。

本发明实施例还提供一种上行预调度处理系统，包括：基站，其中所述基站包括上述的上行预调度处理装置，所述基站用于与至少一个用户设备通信。

本发明实施例中，基站可以根据UE的业务属性信息，确定可能发送突发上行数据的UE，并对UE进行上行预调度处理，从而使得UE可以在上行预调度的资源上发送上行突发数据。因此，相对于现有技术需要通过8个TTI才能完成上行突发数据的调度来说，本发明实施例缩短了上行突发数据的调度时间，可以满足较高的时延需求以及QoS的需求。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明上行预调度处理方法一个实施例的流程图；

图2为本发明上行预调度处理方法另一个实施例的流程图；

图3为本发明上行预调度处理装置一个实施例的结构示意图；

图4为本发明上行预调度处理装置另一个实施例的结构示意图；

图5为本发明上行预调度处理系统一个实施例的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

以下实施例中的基站和/或终端包括的通用的部件，不再一一列出。这些通用的部件包括但不限于：基带处理部件；中射频处理部件；传输部件；处理器；内存；天线部件；输入输出装置。每个基站与一个或者多个小区对应。每个小区可以服务一个或多个终端。终端包括但不限于：手机，笔记本电脑，无线通信模块。

图1为本发明上行预调度处理方法一个实施例的流程图，如图1所示，本实施例的方法可以包括：

步骤101、获取用户设备的业务属性信息。该业务属性信息可用于判断用户设备是否可能发送突发上行数据。

举例来说，基站，例如eNodeB等可以在每个TTI中，执行本实施例的步骤。

具体来说，基站可以获取UE的业务属性信息。基站可以在UE接入小区的过程中，或者在UE发送上行数据的过程中获知该业务属性信息。该业务属性信息可以反映UE是否存在向基站发送突发上行数据的可能性。

需要说明的是，本实施例并不限定该业务属性信息的具体内容，本领域技术人员可以理解的是，只要能够反映UE是否存在突发上行数据的可能性的任意信息均可以用于实现本实施例的技术方案，而且，本实施例也不限定该业务属性信息采用的是现有技术中基站已存储的信息，还是通过其它技术手段探测获取的信息。另外，在本实施例中，基站并不限于只获取一个UE的业务属性信息。其在实际实现过程中，可以获取多个UE的业务属性信息。

步骤102、若根据所述业务属性信息确定所述用户设备可能发送突发上行数据，则对所述用户设备进行上行预调度处理。

基站若根据获取的业务属性信息，获知UE可能发送突发上行数据，则基站可以不用等待UE发送SRI，而可以对UE进行上行预调度处理。在本实施例中，该上行预调度处理可以采用现有技术的上行预调度处理实现，例如基站可以向UE发送UL Grant消息，UE在接收该UL Grant消息后，如果有突发上行数据，则可以直接向基站发送突发上行数据。

需要说明的是，由于基站可以确定多个UE均可能发送突发上行数据，因此，基站既可以对多个UE均进行上行预调度处理，也可以按照一定的策略，例如优先级顺序等，对多个UE中的某一个或者某几个UE进行上行预调度处理。

本实施例中，基站可以根据UE的业务属性信息，确定可能发送突发上行数据的UE，并对UE进行上行预调度处理，从而使得UE可以在上行预调度的资源上发送上行突发数据。因此，相对于现有技术需要通过8个TTI才能完成上行突发数据的调度来说，本实施例缩短了上行突发数据的调度时间，可以满足较高的时延需求以及QoS的需求。

图2为本发明上行预调度处理方法另一个实施例的流程图，如图2所示，本实施例的方法可以包括：

步骤201、获取UE的业务质量类别标识信息。

为了降低本实施例的执行复杂度，本实施例可以选取基站已经存储的信息作为业务属性信息。业务质量类别标识(QoS Class Identifier，以下简称：QCI)即为其中的一种。QCI可以反映UE的业务属性，基站可以采用QCI信息作为是否需要对UE进行上行预调度处理的判决依据。该QCI信息可以是在UE接入网络，或者发起业务请求的过程中，基站从网络侧获取并存储的业务属性信息。

步骤202、根据业务质量类别标识信息，确定UE可能发送突发上行数据。

基站可以根据QCI信息确定UE是否会发送突发上行数据。

具体来说，对于每个UE，基站中都存在其对应的QCI信息。基站可以根据UE对应的QCI信息，确定该UE是否存在发送突发上行数据的可能性。

由于对于每个UE来说，其既可能只开通了单个业务，也可能同时开通了多个业务，对应地，每个UE的QCI信息中，既可能只包含了单个业务的属性信息，也可能包括了多个业务的属性信息。因此，在具体实现时，即可包括下述两种技术方案：

若该UE为单业务UE，也即该UE只开通了单个业务，其QCI信息中仅包含了该业务的属性信息，因此，基站可以根据该业务的OCI信息，确定该UE是否存在发送突发上行数据的可能性；

若该UE为多业务UE，也即该UE同时开通了多个业务，其QCI信息中包含了各个业务的属性信息，因此，基站可以根据各业务的QCI信息，确定该UE是否存在发送突发上行数据的可能性。举例来说，基站若确定各个业务的QCI信息中，只要有一个业务的QCI信息表示该UE可能发送突发上行数据，则确定该UE存在发送突发上行数据的可能性。

在本发明的一个实施例中，还可以是在QCI信息中，或者与QCI信息类似的信息中设置预调度属性信息。这样，可以根据预调度属性信息，直接确定UE可能发送突发上行数据，从而可以进行上行预调度处理。

步骤203、判断系统级判决条件是否满足，若满足，则执行步骤204，否则结束。

由于基站对UE的突发上行数据进行上行预调度处理可能会影响到基站对UE的正常调度以及本身的操作性能，因此，本实施例可以设定系统级判决条件，从而使得基站可以根据其系统资源或者性能判断是否能够对可能发送突发上行数据的UE进行上行预调度。

具体来说，由于上行预调度可能会引入系统资源浪费的问题，所以本实施例中，上行预调度的前提条件是上行负载较轻，物理上行共享信道(Physical Uplink Shared Channel，以下简称：PUSCH)信道资源有富余。因此，本实施例可以采用带宽利用率作为系统判决条件，当带宽利用率大于第一阈值，表明PUSCH信道资源可能没有富余，则基站不启动上行预调度；而小于第一阈值，表明PUSCH信道资源可能有富余，则基站可以启动上行预调度。

由于上行预调度也可能会引入邻区干扰的问题，因此本实施例还可以将预调度带宽占系统总带宽的比率作为系统判决条件，当预调度带宽占系统总带宽的比率大于第二阈值，表明预调度带宽占比较高，则基站不启动上行预调度；当小于第二阈值，表明预调度带宽占比不高，则基站可以启动上行预调度，因此，采用预调度带宽占系统总带宽的比率作为系统判决条件，可以限制上行预调度的总带宽，从而降低对邻区的干扰。

在具体实现时，基站还可以将当前带宽利用率和预调度带宽占系统总带宽的比率均作为系统级判决条件。当两个参数同时满足预设的条件时，基站即可确定启动上行预调度处理。

需要说明的是，本领域技术人员可以根据对基站系统性能要求等因素，对上述第一阈值和第二阈值的大小进行设置，本实施例不再赘述。

另外，本实施例也并不限定基站只能采用上述两种参数作为系统判决条件，本领域技术人员可以根据需要采用其它参数丰富系统判决的内容。举例来说，由于上行预调度还可能会引入增大UE能耗的问题，因此基站还可以将预调度最小时间间隔门限作为系统判决条件。预调度时间间隔＝当前调度时刻-上次调度时刻，当预调度时间间隔的值小于预调度最小时间间隔，则基站不启动上行预调度，从而可以减少UE的上行预调度次数，进而降低UE的能耗。另外，需要说明的是，上述步骤202和步骤203之间也可以没有先后顺序。

步骤204、根据所述业务质量类别标识信息，获取各用户设备允许的最大调度间隔和对应的预调度数据量。

一旦基站根据步骤202和步骤203的判决确定要对UE进行上行预调度后，基站可以根据QCI信息，获取UE允许的最大调度间隔和对应的预调度数据量。举例来说，基站在完成步骤204后，可以为各UE建立如表1所示的预调度属性列表。

表1

步骤205、根据上次被调度时刻、本次被调度时刻以及所述允许的最大调度间隔，计算获取各用户设备的优先级顺序。

由于基站可能确定存在多个UE需要进行上行预调度处理，但是系统资源，例如带宽等十分有限，因此，基站可以将这些需要进行上行预调度处理的UE形成上行预调度队列，并对上行预调度队列中的这些UE按照优先级排序。

优先级＝(上次被调度时刻-本次被调度时刻)/允许的最大调度间隔。

其中，上次被调度时刻、本次被调度时刻均为基站可以直接获取的时间参数。

步骤206、根据用户设备的优先级顺序以及对应的预调度数据量，对可能发送突发上行数据的用户设备进行上行预调度处理。

基站可以按照优先级顺序，对上行预调度队列中的UE依次进行上行预调度处理。可以理解的是，一旦基站可用的系统资源用尽，则该上行预调度队列中剩余的UE将不会被进行上行预调度处理。在具体实现时，基站可以采用表1中的预调度数据量对UE进行上行预调度处理。

本实施例可以设计一个系统级预调度总开关Pre-Allocation_Switch，该开关可以控制基站是否需要进行本实施例中步骤201～步骤206的上行预调度处理流程。例如，系统级预调度总开关开启，基站需要进行本实施例中步骤201～步骤206的上行预调度处理流程；系统级预调度总开关关闭，基站不需要进行本实施例中步骤201～步骤206的上行预调度处理流程。

本实施例中，基站可以根据UE的QCI信息，确定可能发送突发上行数据的UE，并通过系统级判决，确定基站自身是否能够对这些需要上行预调度的UE进行上行预调度处理。而且在调度过程中，还可以充分考虑各UE的优先级顺序，从而使得基站既可以为可能发送突发上行数据的UE预先调度上行资源，又能够尽可能避免该上行预调度对系统性能的影响。因此，本实施例相对于现有技术需要通过8个TTI才能完成上行突发数据的调度来说，缩短了上行突发数据的调度时间，满足较高的时延需求以及QoS的需求。

图3为本发明上行预调度处理装置一个实施例的结构示意图，如图3所示，本实施例的装置，可以包括：第一获取模块11和上行预调度模块12，其中，第一获取模块11用于获取用户设备的业务属性信息，所述业务属性信息用于判断所述用户设备是否可能发送突发上行数据；上行预调度模块12用于若根据所述业务属性信息确定所述用户设备可能发送突发上行数据，则对所述用户设备进行上行预调度处理。

本实施例的装置可以用于执行图1所示方法实施例的方法，其实现原理和技术效果类似，此处不再赘述。

图4为本发明上行预调度处理装置另一个实施例的结构示意图，如图4所示，本实施例的装置在图3所示装置的基础上，进一步地，还包括：启动模块13和第二获取模块14。上行预调度模块12进一步可以包括：判断单元121、第一确定单元122、第二确定单元123以及预调度处理单元124之一或其任意合理组合。其中启动模块13用于若当前带宽利用率小于第一阈值和/或预调度带宽占系统总带宽的比率小于第二阈值，则确定启动所述上行预调度模块12，第一获取模块11具体用于获取所述用户设备的业务质量类别标识信息；判断单元121用于判断所述用户设备是单业务用户设备还是多业务用户设备；第一确定单元122用于若判断单元121判断所述用户设备为单业务用户设备，则根据该单业务的业务质量类别标识信息，确定所述用户设备可能发送突发上行数据；第二确定单元123用于若判断单元121判断所述用户设备为多业务用户设备，则根据该多业务中的各业务的业务质量类别标识信息，确定所述用户设备可能发送突发上行数据；预调度处理单元124用于根据第一确定单元122或者第二确定单元123确定的结果，根据用户设备的优先级顺序以及对应的预调度数据量进行上行预调度处理；第二获取模块14用于根据所述业务质量类别标识信息，获取各用户设备允许的最大调度间隔和对应的预调度数据量；根据上次被调度时刻、本次被调度时刻以及所述允许的最大调度间隔，计算获取各用户设备的优先级顺序。

本实施例的装置可以用于执行图2所示方法实施例的方法，其实现原理和技术效果类似，此处不再赘述。

图5为本发明上行预调度处理系统一个实施例的结构示意图，如图5所示，本实施例的系统可以包括：基站1和用户设备2，其中该基站1可以包括上述图3或4所示的装置的结构，其可以用于执行图1或图2所示方法实施例的方法，其实现原理和技术效果类似，此处不再赘述。需要说明的是，本实施例中仅示出了一个用户设备，本领域技术人员可以理解的是，与基站1通信的用户设备2可以为多个，每个用户设备2均可以采用与图1或图2所示的方法与基站1通信。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过硬件模块或硬件模块的组合，处理器和内存等芯片组的组合，或者程序来指令相关的硬件、处理器、芯片组来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读内存(ROM，Read-Only Memory)、随机存储器(RAM，Random Access Memory)、磁盘或光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims

1.一种上行预调度处理方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，对所述用户设备进行上行预调度处理之前，还包括：

判断当前带宽利用率是否小于第一阈值，和/或判断预调度带宽占系统总带宽的比率是否小于第二阈值；

其中，若当前带宽利用率小于第一阈值，和/或预调度带宽占系统总带宽的比率小于第二阈值，则继续执行所述上行预调度处理。

3.根据权利要求1或2所述的方法，其特征在于，所述业务属性信息包括业务质量类别标识信息；

根据所述业务属性信息确定所述用户设备可能发送突发上行数据，包括：

根据所述业务质量类别标识信息，确定所述用户设备可能发送突发上行数据。

4.根据权利要求3所述的方法，其特征在于，所述根据所述业务质量类别标识信息，确定所述用户设备可能发送突发上行数据，包括：

若所述用户设备为单业务用户设备，则根据该单业务的业务质量类别标识信息，确定所述用户设备可能发送突发上行数据；

若所述用户设备为多业务用户设备，则根据该多业务中各业务的业务质量类别标识信息，确定所述用户设备可能发送突发上行数据。

5.根据权利要求3所述的方法，其特征在于，对所述用户设备进行上行预调度处理，包括：

根据用户设备的优先级顺序以及对应的预调度数据量进行上行预调度处理。

6.根据权利要求5所述的方法，其特征在于，所述根据用户设备的优先级顺序以及对应的预调度数据量进行上行预调度处理之前，还包括：

根据所述业务质量类别标识信息，获取各用户设备允许的最大调度间隔和对应的预调度数据量；

根据上次被调度时刻、本次被调度时刻以及所述允许的最大调度间隔，计算获取各用户设备的优先级顺序。

7.一种上行预调度处理装置，其特征在于，包括：

第一获取模块，用于在传输时间间隔中，获取用户设备的业务属性信息，所述业务属性信息用于判断所述用户设备是否可能发送突发上行数据；

8.根据权利要求7所述的装置，其特征在于，还包括：

启动模块，用于若当前带宽利用率小于第一阈值和/或预调度带宽占系统总带宽的比率小于第二阈值，则确定启动所述上行预调度模块。

9.根据权利要求7或8所述的装置，其特征在于，所述业务属性信息包括业务质量类别标识信息；

所述上行预调度模块，包括：

判断单元，用于判断所述用户设备是单业务用户设备还是多业务用户设备；

第一确定单元，用于若所述判断单元判断所述用户设备为单业务用户设备，则根据该单业务的业务质量类别标识信息，确定所述用户设备可能发送突发上行数据；

第二确定单元，用于若所述判断单元判断所述用户设备为多业务用户设备，则根据该多业务中的各业务的业务质量类别标识信息，确定所述用户设备可能发送突发上行数据；

预调度处理单元，用于根据所述第一确定单元或者第二确定单元确定的结果，根据用户设备的优先级顺序以及对应的预调度数据量进行上行预调度处理。

10.根据权利要求9所述的装置，其特征在于，还包括：

第二获取模块，用于根据所述业务质量类别标识信息，获取用户设备允许的最大调度间隔和对应的预调度数据量；根据上次被调度时刻、本次被调度时刻以及所述允许的最大调度间隔，计算获取用户设备的优先级顺序。

11.一种上行预调度处理系统，其特征在于，包括：基站，其中，所述基站包括如权利要求7～10中任一项所述的上行预调度处理装置，所述基站用于与至少一个用户设备通信。