CN1741672A

CN1741672A - 一种小区资源分配方法

Info

Publication number: CN1741672A
Application number: CN200410057352.7A
Authority: CN
Inventors: 陈功
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2004-08-26
Filing date: 2004-08-26
Publication date: 2006-03-01
Anticipated expiration: 2024-08-26
Also published as: CN100456876C

Abstract

本发明公开了一种小区资源分配方法，在用户根据其业务请求中的QoS向基站申请小区资源，但由于基站当前可分配资源无法满足QoS要求，导致该用户业务请求将被拒绝时，不是直接拒绝该业务请求，结束本次资源分配操作；而是继续分析用户业务请求的QoS中包含的优先级参数，以判断所述用户业务请求是否能够进行抢占、降速或排队操作，并结合该用户业务请求的QoS要求进行相应的抢占、降速或排队操作，使得该用户业务请求能分配到完成相应的抢占、降速或排队操作后，可满足其QoS要求的小区资源。使用本发明所提供的小区资源分配方法，能够提高小区接入率和用户满意度。

Description

一种小区资源分配方法

技术领域

本发明涉及无线网络资源分配技术，具体涉及一种小区资源分配方法。

背景技术

在移动用户数量急增的今天，基站的系统资源变得相对紧张。以宽带码分多址(WCDMA)系统为例，基站为保证小区用户移动台能进行无线通信，要向小区用户移动台分配包括发射功率和信道码等在内的系统资源，但这些系统资源相对而言是有限的。随着小区用户的增加，基站系统资源就显得相对不足，以至于基站系统资源无法同时满足过多用户用以进行无线通信的资源需求。

当用户要进行无线通信时，用户会使用移动台通过基站向网络侧发送业务请求，位于核心网的服务通用分组无线业务支持节点(SGSN)收到该请求后，会将该请求发送给网关通用分组无线业务支持节点(GGSN)，GGSN会对该业务请求进行QoS协商操作。所述的QoS协商过程为：GGSN判断自身是否能满足其接收到的用户业务请求中包含的QoS要求，如果能满足，则为该用户业务请求分配相应资源，否则，拒绝该用户业务请求。

与此相类似，当GGSN经过QoS协商后，判断出自身能为该用户业务请求分配相应资源，并向SGSN发送针对该用户业务请求的创建响应后，SGSN就会向基站发送用户业务请求激活响应。所述SGSN发送的针对用户业务请求的创建响应以及SGSN向基站发送的用户业务请求激活响应均包含有QoS，且该QoS与用户业务请求中的QoS相同。

这时，基站就根据自身的资源状况对用户的业务请求进行不同处理。具体的处理方法为：如果基站自身当前的资源状况能够满足用户业务请求所包含的QoS要求，则向移动台发送用户业务请求激活响应，同时为移动台分配相应的无线资源；否则，就拒绝该用户业务请求，这里所说的无线资源是指包含发射功率和信道码等在内的小区资源。

基站应用上述方法向用户分配小区资源的流程如图1所示，图1为现有技术小区资源分配流程图，该流程具体包含以下步骤：

步骤101：基站收到SGSN向其发送的针对用户业务请求的激活响应后，获取该激活响应所包含的QoS相关信息。

本步骤中的激活响应所包含的QoS与用户最初向网络侧发送的业务请求所包含的QoS相同。

步骤102：基站判断自身当前可分配的资源是否能满足用户业务请求的QoS要求，如果能满足QoS的要求，则基站获准该用户业务请求，并为其分配相应的小区资源；否则，就拒绝该用户业务请求。

可见，基站应用上述方法向用户分配小区资源时，如果基站因为当前的资源使用率较高，而无法满足用户业务请求所包含的QoS要求，基站就会直接拒绝该用户业务请求。这种资源分配方法，致使在小区资源相对紧张时，一定数量的QoS要求相对较高的业务请求会被断然拒绝，进而导致用户无法进行相关业务，降低了小区的接入率，也降低了用户的满意度。

发明内容

有鉴于此，本发明的主要目的在于提供一种小区资源分配方法，更合理地分配小区资源，以提高小区接入率和用户满意度。

为达到上述目的，本发明的技术方案是这样实现的：

本发明公开了一种小区资源分配方法，该方法包含以下步骤：

a.当基站收到针对用户业务请求的响应后，判断当前可分配的小区资源是否能满足用户业务请求包含的QoS要求，如果能满足，则为该用户业务请求分配小区资源，并结束本流程；否则，进入步骤b；

b.根据所述响应中包含的用户业务请求的优先级参数，判断所述用户业务请求是否可以进行抢占、降速或排队操作，如果可以，则进入步骤c；否则，拒绝该用户业务请求，并结束本流程；

c.进行用户业务请求抢占、降速或排队操作。

如果步骤b中的判断结果是用户业务请求可以进行抢占、降速及排队操作，则步骤c中，针对该用户业务请求进行的相应操作包含以下步骤：

c1.进行抢占操作，并判断抢占是否成功，如果成功，则为该用户业务请求分配小区资源；否则，进入步骤c2；

c2.进行降速操作，并判断降速是否成功，如果成功，则为该用户业务请求分配小区资源；否则，进入步骤c3；

c3.进行排队操作，并判断排队是否成功，如果成功，则为该用户业务请求分配小区资源；否则，基站拒绝该用户业务请求。

如果步骤b中的判断结果是用户业务请求可以进行抢占及降速操作，则步骤c中，针对该用户业务请求进行的相应操作包含以下步骤：

c2.进行降速操作，并判断降速是否成功，如果成功，则为该用户业务请求分配小区资源；否则，基站拒绝该用户业务请求。

如果步骤b中的判断结果是用户业务请求可以进行抢占及排队操作，则步骤c中，针对该用户业务请求进行的相应操作包含以下步骤：

c2.进行排队操作，并判断排队是否成功，如果成功，则为该用户业务请求分配小区资源；否则，基站拒绝该用户业务请求。

如果步骤b中的判断结果是用户业务请求可以进行降速及排队操作，则步骤c中，针对该用户业务请求进行的相应操作包含以下步骤：

c1.进行降速操作，并判断降速是否成功，如果成功，则为该用户业务请求分配小区资源；否则，进入步骤c2；

如果步骤b中的判断结果是用户业务请求只可以进行抢占操作，则步骤c中，针对该用户业务请求进行的相应操作为：

进行抢占操作，并判断抢占是否成功，如果成功，则为该用户业务请求分配小区资源；否则，基站拒绝该用户业务请求。

如果步骤b中的判断结果是用户业务请求只可以进行降速操作，则步骤c中，针对该用户业务请求进行的相应操作为：

进行降速操作，并判断降速是否成功，如果成功，则为该用户业务请求分配小区资源；否则，基站拒绝该用户业务请求。

如果步骤b中的判断结果是用户业务请求只可以进行排队操作，则步骤c中，针对该用户业务请求进行的相应操作为：

进行排队操作，并判断排队是否成功，如果成功，则为该用户业务请求分配小区资源；否则，基站拒绝该用户业务请求。

当基站没有可分配资源时，如果步骤b中的判断结果是用户业务请求可以进行抢占、降速及排队操作，则步骤c中，针对该用户业务请求进行的相应操作包含以下步骤：

c2.进行排队操作，并判断排队是否成功，如果成功，则为该用户业务请求分配小区资源；否则，进入步骤c3；

c3.进行降速操作，并判断降速是否成功，如果成功，则为该用户业务请求分配小区资源；否则，基站拒绝该用户业务请求。

当基站没有可分配资源时，如果步骤b中的判断结果是用户业务请求可以进行降速及排队操作，则步骤c中，针对该用户业务请求进行的相应操作包含以下步骤：

c1.进行排队操作，并判断排队是否成功，如果成功，则为该用户业务请求分配小区资源；否则，进入步骤c2；

所述的抢占操作包含以下步骤：

A1.判断当前所有未建立无线连接的业务请求中，是否有允许被抢占的业务请求已经分得小区资源，如果有，进入步骤A2；否则，抢占失败，基站拒绝该用户业务请求，并结束本流程；

A2.判断所述已经分得小区资源的所有业务请求所分得的小区资源，是否能满足所述的可以进行抢占操作的业务请求，如果能满足，则抢占成功，进而将其中一个分得小区资源的业务请求所分得的小区资源，分配给所述的可以进行抢占操作的业务请求；如果不能满足，则抢占失败，基站拒绝该用户业务请求。

所述的降速操作包含以下步骤：

B1.降低所述用户业务请求的数据传输速率要求，并判断基站可分配资源是否能满足降低数据传输速率要求后的用户业务请求，如果能满足，则降速成功，基站为该用户业务请求分配小区资源，并结束本流程；否则，进入步骤B2；

B2.判断降低数据传输速率要求后的用户业务请求，是否可以继续将其所要求的数据传输速率降低，如果可以，则返回步骤B1；否则，降速失败，基站拒绝该用户业务请求。

所述的排队操作中，为各用户业务请求分别预先设置定时器，该排队操作包含以下步骤：

C1.将需要分配小区资源的所有用户业务请求排列成队列，并启动各用户业务请求对应的定时器；

C2.基站判断当前收到响应的用户业务请求是否可以出队分配资源，如果可以出队分配资源，则进入步骤C3；否则，进入步骤C4；

C3.判断基站可分配资源是否能满足出队的用户业务请求，如果能满足，则排队成功，基站为该用户业务请求分配小区资源，并结束本流程；否则，排队失败，基站拒绝该用户业务请求，并结束本流程；

C4.判断用户业务请求是否在队列中等待超时，如果超时，则排队失败，基站拒绝该用户业务请求；否则，返回步骤C2。

根据所述用户业务请求的业务类型，为该用户业务请求设置刚好能满足其传输时延要求的数据传输最低速率，在用户业务请求所要求的数据传输速率与设置的数据传输最低速率之间划分不同的速率等级，则步骤B1中，降低所述用户业务请求的数据传输速率要求的方法为：将用户业务请求所要求的数据传输速率降低一个速率等级，使该用户业务请求所要求的数据传输速率等级降低为相对较低一级速率等级。

步骤C1中，所述将需要分配小区资源的所有用户业务请求排列成队列的方法为：

根据各用户业务请求的不同优先级等级，将用户业务请求按照优先级等级由高到低的顺序，排列成队列。

与现有技术相比，本发明所提供的小区资源分配方法，在用户根据其业务请求中的QoS向基站申请小区资源，但由于基站当前可分配资源无法满足QoS要求，导致该用户业务请求将被拒绝时，不是直接拒绝该业务请求，结束本次资源分配操作；而是继续分析用户业务请求的QoS中包含的优先级参数，以判断所述用户业务请求是否能够进行抢占、降速或排队操作，并结合该用户业务请求的QoS要求进行相应的抢占、降速或排队操作，使得该用户业务请求能分配到完成相应的抢占、降速或排队操作后，可满足其QoS要求的小区资源。因此，本发明所提供的小区资源分配方法，能够提高小区接入率和用户满意度。

附图说明

图1为现有技术小区资源分配流程图；

图2为本发明抢占操作流程图；

图3为本发明排队操作流程图；

图4为本发明降速操作流程图；

图5为本发明小区资源分配流程图。

具体实施方式

在实际应用中，用户发出的业务请求所包含的QoS中，除了包含信息传输时延，信息传输流量、速率，数据包丢包率，误码率及信噪比等信息之外，还包含与该业务请求所属业务类型有关的优先级参数，但WCDMA网络重点强调数据的点对点传输，而不太注重优先级参数及QoS对数据传输及小区资源分配的影响，所以，所述优先级参数目前只是在无线通信协议中有了初步的定义，而没有在实际应用中得到具体的利用。

本发明正是利用所述优先级参数，对小区资源进行更合理的分配。

本发明总体的小区资源分配方法为：在用户根据其业务请求中的QoS向基站申请小区资源，但由于基站当前可分配资源无法满足QoS要求，导致该用户业务请求将被拒绝时，不是直接拒绝该业务请求，结束本次资源分配操作；而是继续分析用户业务请求的QoS中包含的优先级参数，以判断所述用户业务请求是否能够进行抢占、降速或排队操作，并结合该用户业务请求的QoS要求进行相应的抢占、降速或排队操作，使得该用户业务请求能分配到完成相应的抢占、降速或排队操作后，可满足其QoS要求的小区资源。

所述的优先级参数具体为：抢占参数、优先等级参数和排队参数。

首先，对优先等级参数进行描述。

不同的业务请求根据其业务类型及其QoS的要求被分为不同优先级。当两个以上业务请求同时需要分配小区资源，而当前小区资源又不能同时满足所述业务请求的资源需求时，优先级相对较高的业务请求能够在优先级相对较低的业务请求之前，被分配小区资源；相反，优先级相对较低的业务请求就不能在优先级相对较高的业务请求之前，被分配小区资源。

实际应用中，不同的业务请求包含不同的优先等级参数值，以此参数值表示业务请求的优先级高低，如：将不同业务请求的优先级等级划分为15个等级，由0级优先级到14级优先级，优先级等级依次降低。则，如果某个业务请求包含的优先等级参数值是1，而另一个业务请求包含的优先等级参数值是9，当这两个业务请求同时申请小区资源时，优先等级参数值是1的业务请求就会被优先分配小区资源。

接着，对抢占参数进行描述。

不同的业务请求包含不同的抢占参数，以不同的抢占参数值表示业务请求是否具有抢占能力，以及是否允许被抢占。如：00表示业务请求既不具有抢占能力又不允许被抢占；10表示业务请求具有抢占能力，但不允许被抢占；01表示业务请求不具有抢占能力，但允许被抢占；11表示业务请求既具有抢占能力又允许被抢占。

可见，上述抢占参数值的第一位表示业务请求是否具有抢占能力，第二位则表示业务请求是否允许被抢占。在实际应用中，也可以用其它参数值或其它参数形式表示业务请求是否具有抢占能力，以及是否允许被抢占。

假设业务请求A刚被分配了小区资源，但还没利用该资源继续无线通信，且业务请求A包含的抢占参数值的第二位是1，即该业务请求允许被抢占；同时，业务请求B正在申请小区资源，且业务请求B包含的抢占参数值的第一位是1，即该业务请求具有抢占能力。

当小区资源不能满足业务请求B的资源需求时，如果业务请求A所分得的小区资源能够满足业务请求B所需的小区资源，同时，业务请求B的优先等级参数值大于业务请求A的优先等级参数值，即业务请求B的优先级高于业务请求A的优先级。这时，业务请求A已经分得的小区资源就会被分配给业务请求B，而业务请求A则失去了刚分得的小区资源。这里所述的通过抢占参数进行资源重新分配的操作，可以看作是小区资源的抢占操作。

下面，再对排队参数进行描述。

不同的业务请求包含不同的排队参数，不同的排队参数值则用来表示业务请求在排队方面的能力。假设排队参数值为0时，表示业务请求不可以排队；排队参数值为1时，表示业务请求可以排队。那么，当基站因为资源紧张而无法为多个用户业务请求同时分配资源时，所述的多个用户业务请求中可以排队的用户业务请求就按照优先级顺序，组成一个队列，等待基站为其分配小区资源；而其中不可以排队的用户业务请求则被拒绝。

一般情况下，所述的可以排队的业务请求对数据传输时延要求不高，所以可以在队列中等待分配资源，而不会被由此引起的数据传输时延所影响，如：数据下载类业务；所述的不可以排队的业务请求对数据传输时延要求相对较高，不能花费过多的时间在队列中等待分配资源，如：语音通话类业务。结合上述优先级参数，可以应用两种不同的小区资源分配方法实现本发明目的，这两种方法分别为：抢占操作和排队操作。

下面，就分别对这两种不同的小区资源分配方法进行描述。

首先，对所述的抢占操作进行描述。

当基站收到SGSN向其发送的针对用户业务请求的激活响应后，获取该激活响应包含的QoS，并分析该QoS中包含的优先级参数，以及其它未建立无线连接的用户业务请求的QoS中包含的优先级参数。如果基站通过分析得出：当前收到的激活响应所对应的用户业务请求具有抢占能力，且其它未建立无线连接的用户业务请求中有允许被抢占的用户业务请求，这时，就可以进行抢占操作。

参见图2，图2为本发明抢占操作流程图，该流程具体包含以下步骤：

步骤201：判断允许被抢占的业务请求是否已分得小区资源，如果已分得小区资源，则进入步骤202；否则，抢占失败，基站拒绝当前收到的激活响应所对应的用户业务请求。

步骤202：判断允许被抢占的业务请求所分得的小区资源，是否能满足基站当前收到的激活响应所对应的用户业务请求的QoS要求，如果能满足，则抢占成功，进而将允许被抢占的业务请求所分得的小区资源，分配给基站当前收到的激活响应所对应的用户业务请求；否则，抢占失败，基站拒绝当前收到的激活响应所对应的用户业务请求。

需要说明的是，步骤202中，可能有多个允许被抢占的业务请求所分得的小区资源，都能满足基站当前收到的激活响应所对应的用户业务请求的QoS要求。这时，就从中选择一个优先级等级相对较低的业务请求，将该业务请求所分得的小区资源，分配给基站当前收到的激活响应所对应的用户业务请求。

接着，再对所述的排队操作进行描述。

当基站收到SGSN向其发送的针对多个用户业务请求的多个激活响应时，如果基站因为资源紧张而无法为这些用户业务请求同时分配资源，所述的多个用户业务请求中的可以排队的用户业务请求就按照优先级顺序，组成一个队列，逐个等待分配小区资源；而不可以排队的用户业务请求则被拒绝。这种通过排队分配资源的方法如图3所示，图3为本发明排队操作流程图，该流程具体包含以下步骤：

步骤301：当前无法分得小区资源且可以排队的多个用户业务请求，按照优先级顺序组成一个队列。在队列中，优先级等级相对较高的用户业务请求排在优先级等级相对较低的用户业务请求之前，同时，每个用户业务请求刚进入队列时，都为其设置一定时器，并为定时器设置一定长度的时间周期，同样，新进入队列的用户业务请求也会按照优先级顺序，排在队列中。

步骤302：基站判断当前收到的激活响应所对应的用户业务请求是否已经排在队列的第一位，使得该用户业务请求可以出队分配资源，如果可以出队分配资源，则进入步骤304；否则，进入步骤303。

步骤303：分别判断队列中的各用户业务请求所对应的各定时器是否超时，如果超时，则该超时定时器所对应的用户业务请求排队失败，基站拒绝该用户业务请求；如果没超时，则返回步骤302。

步骤304：基站判断当前可分配资源是否能够满足排在第一位的用户业务请求的QoS要求，如果能满足，则排队成功，该用户业务请求就被调出队伍，并被分配能满足其QoS要求的小区资源，这之后，原来排在第二位的用户业务请求就排在了第一位；如果不能满足，则排队失败，基站拒绝该用户业务请求，同样，这之后，原来排在第二位的用户业务请求就排在了第一位。

以上所述的抢占操作及排队操作均与用户业务请求中的QoS所包含的优先级参数有关，除了可以应用上述抢占及排队操作为用户业务请求分配小区资源外，还可以应用降速操作为用户业务请求分配小区资源。

在实际应用中，不同类型的用户业务请求中的QoS所要求的数据传输速率不同，越高的数据传输速率就需要分配越多的小区资源。一般情况下，用户业务请求所要求的数据传输速率在满足其QoS中的传输时延要求的同时，还存在一定的数据传输速率的降速空间。这使得所述用户业务请求分得能满足其QoS要求的数据传输速率的小区资源后，其实际数据传输速率不仅能满足其QoS中的传输时延要求，而且即使将当前的数据传输速率降低到一定程度后，仍能满足其QoS中的传输时延要求。

例如：基站根据业务请求A的QoS要求的数据传输速率，向发出业务请求A的移动台B分配小区资源后，移动台B与网络侧通信时的数据传输速率为384K比特每秒，但实际上，满足业务请求A的QoS中的传输时延要求所对应的数据传输速率为128K比特每秒，即：只要移动台B与网络侧通信时的数据传输速率不低于128K比特每秒，就可以进行正常通信。这时，移动台B与网络侧通信时的数据传输速率就存在256K比特每秒的降速空间。

这时，可以针对不同类型的用户业务请求，分别设置数据传输最低速率，使该数据传输最低速率刚好能满足用户业务请求的QoS中的传输时延要求。这样，如果当前可分配的小区资源无法满足某用户业务请求中QoS所要求的数据传输速率要求，就可以将该用户业务请求所要求的数据传输速率进行一定程度的降低，使其需要分配的小区资源相应减少，并最终使基站当前可分配资源能够满足该用户业务请求降低数据传输速率要求后的QoS要求，进而使基站能够为该用户业务请求分配相应的小区资源。

当然，如果数据传输速率降低到刚好能满足用户业务请求的QoS中的传输时延要求时，基站的可分配资源还是不能满足该用户业务请求的QoS要求，该用户业务请求所要求的数据传输速率就不能再降低了，否则，即使该用户业务请求分得了小区资源，在数据传输时，也会因为数据传输速率过低而导致传输时延过长，并最终导致通信无法正常进行。

上述这种通过降速分配资源的方法如图4所示，图4为本发明降速操作流程图，该流程具体包含以下步骤：

步骤401：当基站当前可分配资源不能满足用户业务请求的QoS要求，且该用户业务请求要求的数据传输速率可以降低时，对用户业务请求所要求的数据传输速率进行一定程度的降低。

本步骤中的降速范围可以自行设置，如：在用户业务请求所要求的数据传输速率与设置的数据传输最低速率之间划分不同的速率等级。其中，当前用户业务请求所要求的数据传输速率为最高速率等级，所述设置的数据传输最低速率则为最低速率等级；在最高及最低速率等级之间，则按速率由高到低，分别划分多个的速率等级。

当要进行降速时，就可以相应将当前用户业务请求所要求的数据传输速率由最高速率等级降低到与其相邻的较低一级速率等级，即降低一个速率等级。

步骤402：基站判断当前可分配资源是否能满足完成降速后的用户业务请求的QoS要求，如果能满足，则降速成功，基站为该用户业务请求分配相应的小区资源；否则，进入步骤403。

步骤403：基站判断该用户业务请求所要求的数据传输速率是否可以继续降低，如果可以，则返回步骤401；否则，降速失败，基站拒绝该用户业务请求。

所述用户业务请求所要求的数据传输速率是否可以降低，具体是指：将用户业务请求所要求的数据传输速率与设置的数据传输最低速率进行比较，如果所述数据传输速率与所述数据传输最低速率相同，则不能再降低数据传输速率；如果所述数据传输速率高于所述数据传输最低速率，则可以继续降速。

结合业务请求中包含的优先级参数，一般情况下，在小区资源相对紧张时，一个业务请求可以通过抢占、降速、排队三种操作中的一种或多种操作分得小区资源；或可以通过抢占、降速、排队三种操作中的每一种操作分得小区资源，也有可能无法通过任何一种操作分得小区资源。

描述完用以分配小区资源的抢占操作、降速操作及排队操作后，现在，再结合用户业务请求实际有可能进行的抢占、降速或排队操作中的一种或多种操作，对本发明小区资源的分配流程进行详细描述。

参见图5，图5为本发明小区资源分配流程图，该流程具体包含以下步骤：

步骤501：基站收到SGSN向其发送的针对用户业务请求的激活响应后，获取该激活响应所包含的QoS相关信息。

步骤502：基站判断自身当前可分配的资源是否能满足用户业务请求的QoS要求，如果能满足，则基站获准该用户业务请求，并为其分配相应的小区资源；否则，进入步骤503。

步骤503：基站从所述激活响应中获取用户业务请求的QoS要求，并分析该QoS中包含的优先级参数，以及其它当前未建立无线连接的用户业务请求的QoS中包含的优先级参数。如果基站通过分析得出：当前收到的激活响应所对应的用户业务请求具有抢占能力，且其它未建立无线连接的用户业务请求中有允许被抢占的用户业务请求，这时，就可以进行抢占操作。

步骤504：基站通过分析各用户业务请求的QoS要求以及其中的优先级参数，进行如下判断：

如果基站当前收到的激活响应所对应的用户业务请求具有抢占能力，且其它当前未建立无线连接的用户业务请求中有允许被抢占的用户业务请求，则可以进行抢占操作；

如果基站当前收到的激活响应所对应的用户业务请求所要求的数据传输速率可以降低，则可以进行降速操作；

如果基站当前收到的激活响应所对应的用户业务请求可以排队，则可以进行排队操作。

由于一般情况下，一个用户业务请求可能具有抢占、降速、排队三种能力中的一种能力，或同时具有其中的多种能力；而具有相应能力的不同，使得在基站完成上述判断之后，用户业务请求进行的相应操作也会有所不同。

如果通过判断，基站得知当前收到的激活响应所对应的用户业务请求可以进行抢占、降速及排队操作，则进入步骤505；

如果通过判断，基站得知当前收到的激活响应所对应的用户业务请求可以进行抢占及降速操作，则进入步骤511；

如果通过判断，基站得知当前收到的激活响应所对应的用户业务请求可以进行抢占及排队操作，则进入步骤515；

如果通过判断，基站得知当前收到的激活响应所对应的用户业务请求可以进行降速及排队操作，则进入步骤519；

如果通过判断，基站得知当前收到的激活响应所对应的用户业务请求只可以进行抢占操作，则进入步骤523；

如果通过判断，基站得知当前收到的激活响应所对应的用户业务请求只可以进行降速操作，则进入步骤525；

如果通过判断，基站得知当前收到的激活响应所对应的用户业务请求只可以进行排队操作，则进入步骤527。

步骤505：进行抢占操作。

步骤506：判断抢占操作是否成功，如果成功，则基站获准该用户业务请求，并为其分配相应的小区资源；否则，进入步骤507。

步骤507：进行降速操作。

步骤508：判断降速操作是否成功，如果成功，则基站获准该用户业务请求，并为其分配相应的小区资源；否则，进入步骤509。

步骤509：进行排队操作。

步骤510：判断排队操作是否成功，如果成功，则基站获准该用户业务请求，并为其分配相应的小区资源；否则，基站拒绝该用户业务请求。

步骤511：进行抢占操作。

步骤512：判断抢占操作是否成功，如果成功，则基站获准该用户业务请求，并为其分配相应的小区资源；否则，进入步骤513。

步骤513：进行降速操作。

步骤514：判断降速操作是否成功，如果成功，则基站获准该用户业务请求，并为其分配相应的小区资源；否则，基站拒绝该用户业务请求。

步骤515：进行抢占操作。

步骤516：判断抢占操作是否成功，如果成功，则基站获准该用户业务请求，并为其分配相应的小区资源；否则，进入步骤517。

步骤517：进行排队操作。

步骤518：判断排队操作是否成功，如果成功，则基站获准该用户业务请求，并为其分配相应的小区资源；否则，基站拒绝该用户业务请求。

步骤519：进行降速操作。

步骤520：判断降速操作是否成功，如果成功，则基站获准该用户业务请求，并为其分配相应的小区资源；否则，进入步骤521。

步骤521：进行排队操作。

步骤522：判断排队操作是否成功，如果成功，则基站获准该用户业务请求，并为其分配相应的小区资源；否则，基站拒绝该用户业务请求。

步骤523：进行抢占操作。

由图5中所述流程可以看出，如果当前需要分配小区资源的用户业务请求可以进行降速操作也可以进行排队操作，则首先进行降速操作，当用户业务请求无法通过降速操作分得满足其QoS要求的小区资源时，再进行排队操作。这种操作顺序可以使基站有可分配资源，但无法满足用户业务请求的QoS要求时，用户业务请求能通过首先进行的降速操作，尽快分得能满足其降速后的QoS要求的小区资源。

但是，如果基站当前根本没有可分配资源，则即使该用户业务请求进行再大程度的降速操作，也不可能分得能满足其降速后的QoS要求的小区资源，这样，该用户业务请求就会被基站拒绝；但是，如果这时通过排队操作，当轮到该用户业务请求出队申请资源时，基站可分配资源有可能已变为可以满足该用户业务请求的QoS要求，则该用户业务请求就能够分得能满足其QoS要求的小区资源。

所以，在基站当前根本没有可分配资源时，如果当前需要分配小区资源的用户业务请求可以进行降速操作也可以进行排队操作，则首先进行排队操作，再进行降速操作。

由以上所述可以看出，本发明所提供的小区资源分配方法，能够提高小区接入率和用户满意度。以上所述仅为本发明的过程及方法实施例，并不用以限制本发明，凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1、一种小区资源分配方法，其特征在于，该方法包含以下步骤：

c.进行用户业务请求抢占、降速或排队操作。

2、如权利要求1所述的方法，其特征在于，如果步骤b中的判断结果是用户业务请求可以进行抢占、降速及排队操作，则步骤c中，针对该用户业务请求进行的相应操作包含以下步骤：

3、如权利要求1所述的方法，其特征在于，如果步骤b中的判断结果是用户业务请求可以进行抢占及降速操作，则步骤c中，针对该用户业务请求进行的相应操作包含以下步骤：

4、如权利要求1所述的方法，其特征在于，如果步骤b中的判断结果是用户业务请求可以进行抢占及排队操作，则步骤c中，针对该用户业务请求进行的相应操作包含以下步骤：

5、如权利要求1所述的方法，其特征在于，如果步骤b中的判断结果是用户业务请求可以进行降速及排队操作，则步骤c中，针对该用户业务请求进行的相应操作包含以下步骤：

6、如权利要求1所述的方法，其特征在于，如果步骤b中的判断结果是用户业务请求只可以进行抢占操作，则步骤c中，针对该用户业务请求进行的相应操作为：

7、如权利要求1所述的方法，其特征在于，如果步骤b中的判断结果是用户业务请求只可以进行降速操作，则步骤c中，针对该用户业务请求进行的相应操作为：

8、如权利要求1所述的方法，其特征在于，如果步骤b中的判断结果是用户业务请求只可以进行排队操作，则步骤c中，针对该用户业务请求进行的相应操作为：

9、如权利要求1所述的方法，其特征在于，当基站没有可分配资源时，如果步骤b中的判断结果是用户业务请求可以进行抢占、降速及排队操作，则步骤c中，针对该用户业务请求进行的相应操作包含以下步骤：

10、如权利要求1所述的方法，其特征在于，当基站没有可分配资源时，如果步骤b中的判断结果是用户业务请求可以进行降速及排队操作，则步骤c中，针对该用户业务请求进行的相应操作包含以下步骤：

11、如权利要求1至10任一项所述的方法，其特征在于，所述的抢占操作包含以下步骤：

12、如权利要求1至10任一项所述的方法，其特征在于，所述的降速操作包含以下步骤：

13、如权利要求1至10任一项所述的方法，其特征在于，所述的排队操作中，为各用户业务请求分别预先设置定时器，该排队操作包含以下步骤：

14、如权利要求12所述的方法，其特征在于，根据所述用户业务请求的业务类型，为该用户业务请求设置刚好能满足其传输时延要求的数据传输最低速率，在用户业务请求所要求的数据传输速率与设置的数据传输最低速率之间划分不同的速率等级，则步骤B1中，降低所述用户业务请求的数据传输速率要求的方法为：将用户业务请求所要求的数据传输速率降低一个速率等级，使该用户业务请求所要求的数据传输速率等级降低为相对较低一级速率等级。

15、如权利要求13所述的方法，其特征在于，步骤C1中，所述将需要分配小区资源的所有用户业务请求排列成队列的方法为：