无线通信网络中基于QoS性能的接纳控制

摘要

描述了在无线通信网络中基于服务质量(QoS)性能进行接纳控制的技术。可以确定已接纳的数据流的QoS性能(例如，延迟或吞吐量性能)。然后可以基于已接纳的数据流的QoS性能来确定接纳或是拒绝新数据流。已接纳的和新的数据流可以具有延迟界限。已接纳的数据流的QoS性能可由扇区延迟测量值给出，该扇区延迟测量值可以基于实际的分组延迟来确定。每个已接纳的数据流的流延迟测量值可以基于该流的分组的延迟来确定。所述扇区延迟测量值然后可以基于所有已接纳的数据流的流延迟测量值来确定。如果所述扇区延迟测量值小于延迟阈值则可以接纳所述新数据流。

说明书

根据35U.S.C.§119要求优先权

本专利申请要求于2007年9月28日提交的、名称为“QoS PerformanceBased Admission Control in Cellular Networks”、序号为60/975,869的美国临时申请的优先权，该申请已转让给本申请的受让人，并通过引用明确地并入本申请。

技术领域

本公开概括而言涉及通信，具体而言，涉及在无线通信网络中进行接纳控制的技术。

背景技术

为了提供诸如语音、视频、分组数据、消息传递、广播之类的各种通信服务，广泛部署了无线通信网络。这些网络可以是能够通过共享可用网络资源支持多个用户的多址网络。这类多址网络的实例包括码分多址(CDMA)网络、时分多址(TDMA)网络、频分多址(FDMA)网络、正交FDMA(OFDMA)网络和单载波FDMA(SC-FDMA)网络。

在无线通信网络中，基站可以在前向链路和反向链路上与多个终端进行通信。有限数量的网络资源可以对每个链路可用，以支持该链路上所有数据流的传输。数据流可以具有服务质量(QoS)要求，例如延迟界限、平均吞吐量等等。人们希望在每个链路上接纳尽可能多的数据流，同时针对所有或许多的已接纳的数据流提供满意的性能。接纳太多的数据流会导致可用网络资源不足以为已接纳的数据流提供满意的性能。反过来，接纳太少的数据流会导致对可用的网络资源的利用过低。接纳太多或者太少的数据流都具有不良的结果。

发明内容

本申请描述了在无线通信网络中基于QoS性能进行接纳控制的技术。在一个设计中，可以接收到接纳新数据流的请求。可以确定已接纳的数据流的QoS性能，其可以包括延迟性能、吞吐量性能等等。可以基于已接纳的数据流的QoS性能来确定接纳或是拒绝所述新数据流。

在一个设计中，已接纳数据流和所述新数据流可以包括具有延迟界限的加速转发(EF)流。已接纳的EF流的QoS性能可由扇区延迟测量值来量化，该扇区延迟测量值可基于实际的分组延迟来确定。在一个设计中，针对每个已接纳的EF流所流延迟测量值可以基于该EF流的分组的延迟来确定。所述扇区延迟测量值然后可以基于针对所有已接纳的EF流所流延迟测量值来确定。如果所述扇区延迟测量值小于延迟阈值则可以接纳所述新的EF流。

在另一设计中，已接纳数据流和所述新数据流可以包括具有平均吞吐量要求的确保转发(AF)流。已接纳的AF流的QoS性能可以由这些AF流达到的总吞吐量来量化。总剩余吞吐量可以基于已接纳的AF流所达到的总吞吐量和必需的总吞吐量以及已接纳的尽力服务(Best Effort)(BE)流所达到的总吞吐量来确定。如果所述总剩余吞吐量超过所述新的AF流所必需的吞吐量则可以接纳新的AF流。

在一个设计中，总扇区吞吐量可以基于已接纳数据流的吞吐量和所述新数据流所必需的吞吐量来确定。如果所述总扇区吞吐量小于扇区吞吐量阈值则可以接纳所述新数据流。如果所述总扇区吞吐量大于所述扇区吞吐量阈值，则可以基于已接纳数据流的QoS性能来接纳或拒绝所述新数据流。

下面进一步详细描述了本公开的各个方面和特征。

附图说明

图1示出了无线通信网络。

图2示出了基于QoS性能的接纳控制的过程。

图3示出了基于总扇区吞吐量的接纳控制的图。

图4示出了基于吞吐量性能的接纳控制的过程。

图5示出了一个EF流的分组延迟的概率密度函数(PDF)。

图6示出了针对一个扇区中所有EF流所流延迟测量值的PDF。

图7示出了基于延迟性能的接纳控制过程。

图8示出了基于QoS性能的接纳控制过程。

图9示出了用于反向链路的接纳控制过程。

图10示出了基站和终端的框图。

具体实施方式

本申请描述的接纳控制技术可以用于各种无线通信网络，例如CDMA、TDMA、FDMA、OFDMA、SC-FDMA和其他网络。术语“网络”和“系统”通常可以替换使用。CDMA网络可以实现的无线技术有：例如cdma2000、通用陆地无线接入(UTRA)等等。cdma2000涵盖IS-2000、IS-95和IS-856标准。UTRA包括宽带CDMA(W-CDMA)和CDMA的其它变型。TDMA网络可以实现的无线技术有：例如全球移动通信系统(GSM)。OFDMA网络可以实现的无线技术有：例如超移动宽带(UMB)、演进UTRA(E-UTRA)、IEEE 802.20、IEEE 802.16(WiMAX)、802.11(WiFi)、Flash-等等。UTRA和E-UTRA是通用移动通信系统(UMTS)的一部分。3GPP长期演进(LTE)是将要发布的UMTS版本，其利用了E-UTRA。在名为“第三代伙伴项目”(3GPP)的组织的文档中描述了UTRA、E-UTRA、UMTS、LTE和GSM。在名为“第三代伙伴项目2”(3GPP2)的组织的文档中描述了cdma2000和UMB。

为清楚起见，下面针对实现IS-856的高速率分组数据(HRPD)网络来描述本技术的某些方面。HRPD也称为CDMA20001xEV-DO、1xEV-DO、1x-DO和高数据速率(HDR)。

图1示出了无线通信网络100，其可以是HRPD网络。网络100包括多个基站110。基站是与终端进行通信的固定站，也可以称作基站收发机(BTS)、接入点、节点B、演进节点B(eNB)等等。每个基站110为特定的地理区域102提供通信覆盖，并且支持位于覆盖区域内的终端的通信。基站的覆盖区域可划分成多个较小区域，例如，三个较小区域104a、104b和104c。每个较小区域可由相应的基站子系统提供服务。在3GPP2中，根据术语所使用的上下文，术语“扇区”可以表示服务于该覆盖区域的基站和/或基站子系统的最小覆盖区域。在3GPP中，术语“小区”可以表示基站的最小覆盖区域和/或服务于该覆盖区域的基站子系统。为清楚起见，在以下描述中使用了3GPP2中的扇区的概念。在图1示出的实例中，基站110a为扇区A1、A2和A3服务，基站110b为扇区B1、B2和B3服务，基站110c为扇区C1、C2和C3服务。

网络控制器130可以耦合到基站110并为这些基站提供协调和控制。网络控制器130可以是单个网络实体或者是网络实体的集合。

终端120可以分散在整个网络中，每个终端可以是静止的或移动的。终端还可以称为移动站、用户设备、接入终端、用户单元、站等等。终端可以是蜂窝电话、个人数字助理(PDA)、无线通信设备、手持设备、无线调制解调器、膝上型计算机等等。终端可以通过前向链路和反向链路与基站进行通信。前向链路(或下行链路)是指从基站到终端的通信链路，反向链路(或上行链路)是指从终端到基站的通信链路。术语“终端”和“用户”在本申请中可互换使用。

对于每个前向链路和反向链路，扇区可以通过一个或多个数据流与一个或多个终端进行通信。数据流是两个特定端点之间数据的流。数据流还可以称为流、分组流、网际协议(IP)流、无线链路控制(RLC)流、无线链路协议(RLP)流等等。终端可以在每个链路上具有一个或多个数据流，用于与扇区进行通信。在有需要(例如，当启动应用或者激活服务时)并且在扇区处资源可用时可以增加新数据流。已有数据流在不再需要时可以删除，并且可以使用于该数据流的资源对新数据流可用。

网络可以支持各种类型的数据流。不同类型的数据流可以用于不同的业务类别、不同的QoS类别等等。每个数据流类型可以与或不与QoS要求相关联。表1列出了一些类型的数据流并针对每个数据流类型提供了简要描述。

(表1见下页)

表1

  数据流类型  名称  描述  加速转发数据流  EF流  具有延迟界限的数据流  确保转发数据流  AF流  具有平均吞吐量要求的数据流  尽力服务数据流  BE流  不具有延迟界限或吞吐量要求的数据流

在表1中，QoS要求由两个QoS参数来量化：延迟界限和平均吞吐量。平均吞吐量还可以称为必需的吞吐量、必需的速率等等。QoS要求还可以由其它参数来量化，例如峰值吞吐量、分组错误率(PER)等等。QoS流是具有至少一个QoS要求的数据流，例如，延迟界限和/或必需的吞吐量。

EF流和AF流具有QoS要求，是两种类型的QoS流。BE流不具有QoS要求，是非QoS流。EF流的实例是IP语音(VoIP)流。AF流的实例是流式视频流。BE流的实例是用于数据下载的数据流。调度器可以给予EF流最高的优先级，给予AF流次高的优先级，给予BE流最低的优先级。

一般地，扇区在每个前向链路和反向链路上可以支持任意数量的EF流、任意数量的AF流和任意数量的BE流。一旦在给定链路上接纳了EF流或AF流，可以使一定量的资源对该流可用，以满足该流的QoS要求。每个数据流使用的资源量因各种因素而变化，例如数据源所生成数据量的变化、信道状况的变化等等。可在给定量的资源上可靠发送的数据量依赖于信道状况。因此，为了发送较多的数据和/或对于较差的信道状况，需要更多的资源。由于在扇区处的可用资源有限，要接纳的EF流的数量和AF流的数量可以受到控制，以确保已接纳的流的良好性能。

根据一方面，接纳控制可以基于已接纳的数据流的QoS性能来进行。接纳控制可以尝试使接纳的QoS流的数量最大化，而同时确保以高概率满足这些QoS流的QoS要求。这可以增加可用资源的利用率以及网络容量。

给定QoS流的性能可以基于该流的QoS要求来量化。不同类型的QoS流可以具有不同的QoS要求。对于EF流，QoS要求可以包括分组的延迟界限。延迟界限还可以称为延迟要求、最大允许延迟、延迟容限、延迟限度等等。分组的延迟可以定义为分组在空中发送的时刻到网络接收到分组的时刻之间的时间量。如果分组由于违反延迟界限而被调度器从队列中丢弃或者分组在空中传输过程中丢失，则分组的延迟可以设置为较大值。

对于AF流，QoS要求可以包括必需的吞吐量。AF流的吞吐量可以基于给定时间间隔内所发送的数据量来确定。吞吐量可以在多个时间间隔上进行平均或者过滤，以获取AF流平均吞吐量。术语“吞吐量”和“速率”在本申请中可互换使用。

在一个设计中，EF流的QoS性能可由延迟性能来给出，其可基于两个标准来量化：QoS满意和QoS容量。QoS满意可适用于每个EF流。如果有目标百分比(例如，99％)的EF流的分组具有低于延迟界限的延迟，则可以认为EF流达到了QoS满意。QoS容量适用于扇区。扇区的QoS容量可以定义为有目标百分比或更多(例如，至少95％)的已接纳EF流达到了QoS满意。如下面所述，可以基于已接纳的EF流的QoS性能来接纳或拒绝新的EF流。

在一个设计中，AF流的QoS性能可由吞吐量性能来给出，其可基于总剩余吞吐量的标准来量化。每个AF流的剩余吞吐量可以按该AF流达到的吞吐量和必需的吞吐量之间的差来计算。如下面所述，可以基于已接纳的AF和BE流的总剩余吞吐量来接纳或拒绝新的AF流。

图2示出了基于QoS性能的接纳控制过程200的设计。过程200可由调度器来执行，其可以位于基站或者其它的网络实体内。过程200可以用于前向链路、反向链路或者这两种链路上。

可以接收接纳新的QoS流的请求(其可以是EF流或AF流)(框212)。可以如下计算假定已接纳新的QoS流下的总扇区吞吐量(框214)：

R_sector＝R_AF+R_BE+α·R_EF+R_new，                           式(1)

其中R_AF是扇区中所有已接纳的AF流的总吞吐量，

R_BE是扇区中所有已接纳的BE流的总吞吐量，

R_EF是扇区中所有已接纳的EF流的总吞吐量，

R_new是新的QoS流必需的吞吐量，

R_sector是具有新的QoS流的总扇区吞吐量，以及

α＞1是EF流的比例因子。

在式(1)中，比例因子α考虑了如下情形：由于EF流更严格的延迟要求，对于相同的吞吐量，该EF流可能比AF流要求更多的资源。如果新的QoS流是AF流，则R_new可以等于必需的AF流的吞吐量。如果新的QoS流是EF流，则R_new可以等于期望或必需的EF流吞吐量的α倍。R_AF、R_BE和R_EF可以如下通过对单独的AF、BE和EF流所达到吞吐量进行累计来获得：

$R_{\mathrm{AF}}=\underset{i}{\Sigma }{R}_{\mathrm{AF},i},$$R_{\mathrm{BE}}=\underset{j}{\Sigma }{R}_{\mathrm{BE},j},$$R_{\mathrm{EF}}=\underset{f}{\Sigma }{R}_{\mathrm{EF},f},$式(2)

其中R_AF，i、R_BE，j和R_EF，f分别是单独的AF、BE和EF流所达到的吞吐量。

总扇区吞吐量R_sector可以与扇区吞吐量阈值R_max进行比较(框216)。R_max可以依赖于多种因素，例如部署情形。R_max可以针对扇区来指定，可以基于计算机模拟、实验测量等等来确定。不管在哪一情形下，如果R_sector小于R_max，则可以接纳新的QoS流(框218)。否则，可以确定新的QoS流是否为EF流(框220)。如下面所述，如果新的QoS流是EF流，则可以基于已接纳的EF流的QoS性能来接纳或拒绝新的EF流(框230)。否则，亦如下面所述，如果新的QoS流是AF流，则可以基于已接纳的AF流的QoS性能来接纳或拒绝新的AF流(框240)。

过程200使用两步过程来进行接纳控制。在步骤1中，如果总扇区吞吐量低于扇区吞吐量阈值，则可以接纳新的QoS流。步骤1可以基于扇区容量的保守估计来接纳或拒绝新的QoS流。

图3示出了过程200中步骤1进行的接纳控制的图。横轴表示总EF流的吞吐量，纵轴表示总AF流的吞吐量。仅具有EF流(或纯EF容量)的扇区容量由点310给出。仅具有AF流(或纯AF容量)的扇区容量由点312给出。实线320表示扇区的服务区域，其斜率为-1。线320由扇区吞吐量阈值R_max和比例因子α来确定。虚线322表示EF容量下的剩余吞吐量。当EF流达到容量时，对于AF和BE流可能还剩有非零的剩余容量，因为EF容量是由延迟性能定义的。

点330表示已接纳的EF和AF流的当前工作点。点330可以位于服务区域内的任何位置。如果新的QoS流是EF流，则新的工作点将位于点332。反过来，如果新的QoS流是AF流，则新的工作点将位于点334。如果新的工作点处于服务区域内，即，位于实线320下方，则可以接纳新的QoS流。

步骤1可以包括在过程200中(如图2中所示)，也可以忽略。在过程200的步骤2中，可以基于QoS性能来接纳或拒绝新的QoS流，对于EF流和AF流该QoS性能可以以各种方式来确定。

图4示出了基于吞吐量性能对新的AF流的接纳控制过程400的设计。所有已接纳的AF和BE流的总剩余吞吐量R_residual可以如下计算(框412)：

$R_{\mathrm{residual}}=R_{\mathrm{BE}}+\underset{i}{\Sigma }(R_{\mathrm{req},i}-R_{\mathrm{AF},i})=R_{\mathrm{BE}}-R_{\mathrm{AF}}+\underset{i}{\Sigma }{R}_{\mathrm{req},i},$式(3)

其中R_req，i是必需的AF流i的吞吐量。

在式(3)示出的设计中，每个BE流的所有吞吐量可以当作剩余吞吐量并计入总剩余吞吐量中。这是因为，如果针对QoS流需要更多资源，BE流可以在以后进行调度。对于每个AF流，剩余吞吐量是该AF流达到的吞吐量和必需的吞吐量之间的差。剩余AF流的吞吐量可以：(i)如果达到的吞吐量低于必需的吞吐量，则是正的，(ii)否则是负的。

可以确定总剩余吞吐量是否大于新的AF流必需的吞吐量R_new(框414)。如果结果为“是“，则可以接纳新的AF流(框416)。否则，可以拒绝新的AF流(框418)。

过程400可以用于AF流的接纳控制。过程400还可以用于图2中的框240。

由于多种原因，AF流达到的吞吐量可以小于必需的吞吐量。首先，使用该AF流的终端的信道状况可能太差而无法支持必需的吞吐量。在此情形下，该AF流的剩余吞吐量可以用于其它AF流。其次，AF流的来源可能发送少于必需的吞吐量的数据。在此情形下，可以为AF流保留资源，以允许其达到其必需的吞吐量。从而，式(3)中的求和包括所有已接纳的AF流或者其子集。

图4示出了基于总剩余吞吐量来接纳或拒绝新的AF流的一个设计，该总剩余吞吐量可以依赖于已接纳的AF流的剩余吞吐量。还可以基于使用总剩余吞吐量以外的其他标准的QoS性能来接纳或拒绝新的AF流。

在针对EF流的接纳控制的一个设计中，可以探知已接纳的EF流的分组的延迟，并将其用来确定已接纳的EF流的延迟性能，以及确定是否要接纳新的EF流。已接纳的EF流的分组延迟可以以各种方式用于新的EF流的接纳控制。

图5示出了针对一个已接纳的EF流的分组延迟的PDF。横轴表示分组延迟，其从零一直到无穷。分组延迟可以当作具有如图510所示示例性PDF的随机变量。该PDF提供了具有不同延迟的分组的百分比或概率。例如，百分之P_u的分组具有延迟u。一般地，PDF可具有任何形状，其可以依赖于扇区负载、EF流分组的调度、EF流观测到的信道状况等等。该PDF在图5中仅仅是示例性地示出，其对于调度器可能是未知的。

在一个设计中，已接纳的EF流的延迟性能可由流延迟测量值Y_f(k)来量化。可以对流延迟测量值进行定义，使得百分之Q的分组具有优于Y_f(k)的延迟，百分之(100-Q)的分组具有劣于Y_f(k)的延迟。流延迟测量值还可以称为Q百分比(Q-percent)延迟尾(tail)、Q百分值(Q-percentile)延迟等等。如果百分之Q的用于EF流的分组具有低于延迟界限的延迟，则可以认为EF流的延迟性能是满意的。由于对于例如VoIP、视频、游戏等等的服务并不需要100％的可靠性，Q可以设置为小于100的值。Q可以基于需要的质量来选择，可以等于80、90、95、99或其它的数值。

在一个设计中，可以如下对流延迟测量值进行动态地更新：

式(4)

其中X_f(k)是EF流f第k个分组的延迟，

Y_f(k)是EF流f在第k个分组之后流延迟测量值，以及

Δ_UP，f是EF流f的向上步长，Δ_DN，f是EF流f的向下步长。

如果分组通过空中发送，则分组延迟X_f(k)可以是分组实际的延迟；如果分组由于违反延迟界限而被从队列中丢弃，则分组延迟X_f(k)可以是较大的值。向上和向下步长可以如下定义为：

${\Delta }_{\mathrm{DN},f}={\Delta }_{\mathrm{UP},f}·\left(\frac{100-Q}{Q}\right).$式(5)

Δ_DN，f可以是Δ_UP，f的很小一部分。例如，如果Q＝99％，则Δ_DN，f＝Δ_UP，f/99。Δ_UP，f的值可以基于收敛速度和剩余估计误差之间的折衷来进行选择。较大的Δ_UP，f的值可以提供较快的收敛，而较小的Δ_UP，f的值可以提供较小的剩余估计误差。Δ_UP，f可以等于1、2、3、4、5或者其他数量的时隙，其中在HRPD中一个时隙具有的时长为1.667毫秒(ms)。

在式(4)示出的设计中，只要分组通过空中发送或者由于违反延迟界限而被从队列中删除，就对EF流的流延迟测量值进行动态更新。如果该分组的延迟大于当前流延迟测量值Y_f(k-1)，则流延迟测量值按较大的向上步长Δ_UP，f增加。否则，如果分组的延迟小于或等于当前流延迟测量值，则流延迟测量值按较小的向下步长Δ_DN，f减少。流延迟测量值Y_f(k)应当收敛到某一点，在该点百分之Q的分组具有更好的延迟，百分之(100-Q)的分组具有较差的延迟。

图6示出了针对一个扇区中所有已接纳的EF流的流延迟测量值的PDF。横轴表示流延迟测量值，其从零一直到无穷。流延迟测量值可以当作具有如图610所示示例性PDF的随机变量。该PDF对于不同的流延迟测量值提供了已接纳的EF流的百分比或概率。例如，百分之P_v的已接纳的EF流具有的流延迟测量值v。一般地，PDF可具有任何形状，其可以依赖于扇区负载、EF流分组的调度、EF流观测到的信道状况等等。该PDF在图6中仅仅是示例性地示出，其对于调度器可能是未知的。

在一个设计中，扇区中所有已接纳的EF流的延迟性能可以由扇区延迟测量值T(k)来量化。可以对扇区延迟测量值进行定义，使得百分之Z的已接纳的EF流具有优于T(k)的流延迟测量值，百分之(100-Z)的已接纳的EF流具有劣于T(k)的流延迟测量值。Z可以等于80、90、95、99或其它数值。扇区延迟测量值还可以称为扇区延迟尾或其它术语。扇区延迟测量值可以表示已接纳的EF流使用的资源量。

在一个设计中，可以如下对扇区延迟测量值进行动态地更新：

式(6)

其中δ_UP是扇区延迟测量值的向上步长，δ_DN是扇区延迟测量值的向下步长。

向上步长和向下步长可以如下定义：

${\delta }_{\mathrm{DN}}={\delta }_{\mathrm{UP}}·\left(\frac{100-Z}{Z}\right).$式(7)

δ_DN可以是δ_UP的很小一部分。例如，如果Z＝95％，则δ_DN＝δ_UP/19。δ_UP的值可以基于收敛速度和剩余估计误差之间的折衷来进行选择。δ_UP可以等于预定的值(例如，1、3、5等等)除以已接纳的EF流。

在式(6)示出的设计中，只要已接纳的EF流的流延迟测量值被更新，就对扇区延迟测量值进行动态更新。如果流延迟测量值大于当前扇区延迟测量值T(k-1)，则扇区延迟测量值按较大的向上步长δ_UP增加。否则，如果流延迟测量值小于或等于当前扇区延迟测量值，则扇区延迟测量值按较小的向下步长δ_DN减少。扇区延迟测量值T(k)应当收敛到一点，在该点百分之Z的所有已接纳的EF流具有较好的流延迟测量值，百分之(100-Z)的已接纳的EF流具有较差的流延迟测量值。扇区延迟测量值是基于所有已接纳的EF流的Q％百分值延迟的对Z％尾延迟的估计，因此可以当作“尾部的尾部”。

在另一设计中，可以基于分组延迟直接对扇区延迟测量值进行更新：

式(8)

在式(8)示出的设计中，对扇区中所有已接纳的EF流的延迟性能的确定不需要计算单独的EF流的延迟性能。可以基于其延迟低于扇区延迟测量值的分组的目标百分比来选择向上步长和向下步长。扇区延迟测量值还可以以其它方式来确定。

扇区中已接纳的EF流的QoS性能可以由扇区延迟测量值来量化，该扇区延迟测量值可以如式(6)或(8)中所示进行更新。在一个设计中，可以如下基于扇区延迟测量值来接纳新的EF流：

如果T(k)＜T_th，则接纳新的EF流，

否则拒绝新的EF流，

其中T_th是延迟阈值。

可以基于期望的错误接纳概率以及低的假报警概率来选择延迟阈值T_th。错误接纳出现在新的EF流因为T(k)＜T_th而被接纳，但是该EF流接纳后实际的扇区延迟超过了延迟界限时，这样一来新的EF流本应该被拒绝。假报警出现在当新的EF流因为T(k)≥T_th而被拒绝，但是如果接纳该EF流的话实际的扇区延迟处于延迟界限内时，这样一来新的EF流本应该被接纳。人们希望将错误接纳概率保持在目标百分比(例如，5％)以下，使假报警概率尽可能地低。

延迟阈值T_th可以基于计算机模拟、实验测量、现场测试等等来确定。如前面所述，进行计算机模拟来确定延迟阈值以及基于延迟性能来计算EF流接纳控制的性能。针对不同数量的EF流进行多组模拟。每组包括(i)采用位于整个扇区中n个EF流的第一轮模拟，以及(ii)采用n+1个EF流的第二轮模拟，其中对于每一组n是不同的值。对于每一组，开始先进行采用n个EF流的第一轮模拟，并获得扇区延迟测量值。对于第二轮，接纳新的EF流，并进行采用n+1个EF流的模拟。在完成第二轮之后，对实际的扇区延迟T_actual进行确定，并将其与延迟界限进行比较以探知性能对于n+1个EF流是否为可接受的。延迟阈值的选择使得针对第二轮开始时增加的新的EF流获得了目标错误接纳概率和低假报警概率。延迟阈值还可以以其它方式来确定。

前面的描述假定了EF流具有相同的延迟界限和必需的吞吐量。一般地，不同的EF流可以具有不同的延迟界限和/或不同的必需的吞吐量。在一个设计中，每个EF流可以映射到相等数量的基本EF流。基本EF流可以具有特定的延迟界限和特定的必需的吞吐量，其可以基于最常见类型的EF流(例如VoIP流)的延迟界限和必需的吞吐量来定义。

当已接纳的EF流的分组用于更新流延迟测量值时，分组的延迟可以如下进行调整：

${\tilde{X}}_f\left(k\right)=X_f\left(k\right)·\frac{B_{\mathrm{EF},f}}{B_{\mathrm{EF},\mathrm{base}}},$式(9)

其中B_EF，f是已接纳的EF流f的延迟界限，

B_EF，base是基本EF流的延迟界限，以及

是EF流f的第k个分组调整后的分组延迟。

流延迟测量值然后可由调整后的分组延迟来进行更新，例如，如式(4)中所示。如果队列中分组的延迟超过已接纳的EF流的延迟界限(而不是基本EF流的延迟界限)，则可以丢弃队列中的分组。

对于接纳控制，可以基于新的EF流的必需的吞吐量来选择延迟阈值。不同的延迟阈值可以用于不同的必需的吞吐量。在一个设计中，可以如下将新的EF流映射到相等数量的基本EF流：

式(10)

其中R_new是新的EF流的必需的吞吐量，

R_EF，base是基本EF流的必需的吞吐量，

N_new是针对新的EF流的基本EF流的数量，以及

表示上取整运算符。

延迟阈值可以基于基本EF流的数量N_new来选择。表2示出了针对不同数量的基本EF流的一组示例性延迟阈值。

表2

  新的基本  EF流的  数量N_new  延迟阈值  T_th  已接纳的  基本EF  流的数量  1  65  54.7  2  62  53.6  3  58  51.5  4  54  49.1  5  52  47.8

  新的基本  EF流的  数量N_new  延迟阈值  T_th  已接纳的  基本EF  流的数量  6  50  46.6  7  48  45.3  8  45  43.7  9  44  43.1  10  43  42.6

在表2中，延迟阈值以时隙为单位给出。延迟阈值的选择使得当已接纳的EF流近似等于可支持的基本EF流的数量时，错误接纳概率为5％，可支持的基本EF流的数量在表2的第三列和第六列给出。表2还假定了延迟界限为84个时隙。如表2中所示，逐步变小的延迟阈值可以用于要接纳的逐步增多新的基本EF流。具有较大必需的吞吐量的新的EF流可以利用更多的资源，这些资源当扇区延迟测量值较小时可用。

一些EF流可以是弹性的，这表示这些EF流可以把凡是可用的容量都挤出来。如果即使扇区延迟测量值超过延迟阈值也要接纳新的EF流，则对每个已接纳的EF流的吞吐量性能进行检查，以确定高于最低要求的一部分吞吐量是否可以用于新的EF流。

多个新的EF流可能希望同时接纳。这些新的EF流可以映射到相等总数的基本EF流。可以基于基本EF流的总数来选择延迟阈值。或者，可支持的新的基本EF流的数量可以基于针对不同数量的新的基本EF流的扇区延迟测量值和不同的延迟阈值来确定。然后可以基于可支持的新的基本EF流的数量来接纳零个或多个新的EF流。

图7示出了基于延迟性能的新的EF流接纳控制过程700的设计。可以基于该EF流的分组的延迟来更新每个已接纳的EF流的流延迟测量值，例如，如式(4)中所示(框712)。可以基于扇区中所有已接纳的EF流的流延迟测量值来更新扇区的扇区延迟测量值，例如，如式(6)中所示(框714)。或者，可以基于所有已接纳的EF流的所有分组的延迟直接对扇区延迟测量值进行更新，例如，如式(8)中所示。框712和714的操作可以：(i)只要发送了分组或者将其从队列中删除就执行，(ii)基于在更新间隔内发送和删除的所有分组的延迟而在每个更新间隔中执行，或者(iii)以其他方式执行。

可以针对新的EF流来确定延迟阈值，例如，基于新的EF流的必需的吞吐量(框716)。然后对扇区延迟测量值是否小于延迟阈值进行确定(框718)。如果答案是“是”，则可以接纳新的EF流(框720)。否则，可以拒绝新的EF流(框722)。

过程700可以用于EF流的接纳控制。过程700一部分，例如框716～722，还可以用于图2中的框230。

图8示出了用于执行基于QoS性能的接纳控制的过程800的设计。过程800可以用于在前向链路或者反向链路上的接纳控制。可以接收到接纳新数据流的请求(框812)。可以确定已接纳的数据流的QoS性能，其可以包括延迟性能、吞吐量性能等等(框814)。可以基于已接纳的数据流的QoS性能来确定是接纳还是拒绝新数据流(框816)。

在一个设计中，已接纳的数据流和新的数据流可以包括具有延迟界限的EF流。已接纳的数据流的QoS性能可以包括扇区延迟测量值，其可以基于已接纳的数据流的分组的延迟来确定。在框814的一个设计中，每个已接纳的数据流的流延迟测量值可以基于该已接纳的数据流的分组的延迟来确定。流延迟测量值可以：(i)如果分组的延迟超过流延迟测量值，则按向上步长增加，(ii)否则按向下步长减少，例如，如式(4)中所示。每个已接纳的数据流的向上步长和向下步长可以基于其延迟小于已接纳的数据流的流延迟测量值的分组的目标百分比来确定，例如，如式(5)中所示。每个分组的延迟还可以基于其已接纳的数据流的延迟界限和基本延迟界限来调整，例如，如式(9)中所示。调整的延迟然后可以用于增加或减少流延迟测量值。

扇区延迟测量值可以基于所有已接纳的数据流的流延迟测量值来确定。扇区延迟测量值可以：(i)如果已接纳的数据流的流延迟测量值超过扇区延迟测量值，则按向上步长增加，(ii)否则按向下步长减少，例如，如式(6)中所示。向上步长和向下步长可以基于其流延迟测量值小于扇区延迟测量值的已接纳的数据流的目标百分比来确定，例如，如式(7)中所示。在框814的另一设计中，扇区延迟测量值可以基于已接纳的数据流的分组延迟直接进行更新，例如，如式(8)中所示。

在框816的一个设计中，如果扇区延迟测量值小于延迟阈值，就可以接纳新数据流。延迟阈值可以基于新数据流的必需的吞吐量来选择。

在另一设计中，已接纳的数据流和新的数据流可以包括具有吞吐量要求的AF流。已接纳的数据流的QoS性能可以包括达到的总吞吐量。总剩余吞吐量可以基于已接纳的AF流达到的总吞吐量和必需的总吞吐量以及已接纳的BE流达到的总吞吐量来确定，例如，如式(3)中所示。如果剩余吞吐量超过新数据流必需的吞吐量就可以接纳新数据流。

在一个设计中，总扇区吞吐量可以基于已接纳的数据流的吞吐量和新数据流的必需的吞吐量来确定，例如，如式(1)中所示。如果总扇区吞吐量小于扇区吞吐量阈值，就可以接纳新数据流。仅当总扇区吞吐量大于扇区吞吐量阈值时可以执行框814和816。

根据另一方面，CDMA网络中反向链路的接纳控制通过考虑热噪声增加量(RoT)来进行。对于CDMA，多个终端当前可以在反向链路上向扇区进行传输，来自每个终端的传输起了对来自扇区中其它终端的传输的干扰作用。从而CDMA网络的容量会在反向链路上受干扰限制。RoT是扇区中总的噪声和干扰对热噪声的比。RoT是CDMA网络中反向链路上负载的基本度量。

在一个设计中，可以对扇区的RoT进行估计，例如在共同转让的下述美国专利申请中描述的，该申请于2008年2月14日提交、序号为12/031,245、名称为“SCHEDULING BASED ON RISE-OVER-THERMAL INA WIRELESS COMMUNICATION SYSTEM”。可以估计QoS流对RoT的贡献以及非QoS流对RoT的贡献。给定数据流对RoT的贡献可以基于发送数据流的终端的导频每码片能量对总噪声与干扰的比(E_cp/N_t)以及数据流的业务导频比(T2P)来进行估计，如上述序号为12/031,245的专利申请中所描述。RoT贡献还可以基于下面的信息来进行估计：(i)HRPD中的反向活动比特(RAB)、(ii)可由数据流的必需的吞吐量来估计的QoS吞吐量，和/或(iii)其它的信息。RAB比特是指示反向链路对于扇区是否有负载的广播比特。可以通过检查反向链路负载在每个时隙设置RAB比特。当扇区的RAB比特设成“忙”时，扇区中的所有终端可以减少它们的数据速率，除非它们的QoS类型要求特定的数据速率。可以通过以下操作来决定接纳或拒绝新的QoS流：(i)比较新的QoS流的弹性吞吐量和必需的吞吐量以及(ii)如果其必需的吞吐量低于弹性吞吐量就接纳新的QoS流。

图9示出了反向链路接纳控制过程900的设计。一开始，可以确定设置为“忙”的RAB比特的百分比(步骤912)。如框914中所确定的，如果该RAB忙百分比低于RAB阈值，则可以将扇区当成轻微负载的，并可以在扇区中接纳新的QoS流(框926)。

否则，可以确定高于RoT阈值的RoT的百分比(框916)。如框918中所确定的，如果该RoT百分比低于百分比阈值，则可以接纳新的QoS流(框926)。框916和918考虑RoT的尾部，而不是RoT的平均值。RoT和负载可以密切相关，比起均值RoT，EF流的QoS性能可能更为依赖RoT尾部。进一步，RoT尾部可以与位于扇区边缘的终端的功率限制更直接相关。或者，RoT分布可以由高斯分布来近似，该高斯分布的均值和标准差可由RoT测量来进行估计。RoT尾部然后可以基于高斯分布的均值和标准差来确定。

如果框918的答案是“否”，则可以例如基于总扇区吞吐量与已接纳的QoS流的必需的吞吐量之和之间的差来估计弹性吞吐量(框920)。总扇区吞吐量可以基于以下内容来确定：(i)反向速率指示符(RRI)比特，其指示在反向链路上发送的业务信道的速率，(ii)已接纳的QoS流在扇区接收到的全部数据，和/或(iii)其它的信息。如框922中所确定的，如果新的QoS流的必需的吞吐量小于弹性吞吐量，则可以接纳新的QoS流(框926)。否则，可以拒绝新的QoS流(框924)。

终端在其活动集中可以具有多于一个扇区，该活动集可以包含与终端进行通信的所有扇区。对于来自终端的新的QoS流，可由活动集中的所有扇区进行接纳控制。如果新的QoS流将新的扇区加入到活动集中，则可以免除接纳控制，因为该QoS流已在已经处于活动集中的扇区中进行，并且应该被活动集中的新的扇区接受。

新的EF流的必需的吞吐量可以乘以比例因子α，因为EF流具有较短的分组终止目标，其可能要求更多的扇区资源。另外，如果扇区包括在活动集中但不是服务扇区，则可以对新的EF流的必需的吞吐量进行调整，因为该新的EF流在服务扇区和非服务扇区所产生的干扰会很不相同。

对于前向链路和反向链路，针对新数据流的接纳控制可以在连接建立过程中进行。当增加了新数据流时或者当现有的数据流退出休眠时，可以进行接纳控制。对于由于切换而进入的数据流可以免除接纳控制。离开扇区的数据流的数量通常匹配进入扇区的数据流的数量。不过，扇区可以保留一些资源或余地，以适应由于切换而突发进入的数据流。

如果QoS流的性能较差(例如由于不良的信道状况)，则QoS流可以被删除或降级为非QoS流。在一个设计中，如果分组差错率过高(例如高于阈值)，则可以删除EF流。在一个设计中，在以下条件下可以将AF流降级为BE流：(i)其达到的吞吐量与必需的吞吐量相比偏低，(ii)AF流的队列非空，并且(iii)平均请求速率大于阈值，这可以表示该AF流在使用过多的资源。在一个设计中，如果降级的AF流达到的吞吐量一直高于请求的速率并且AF流仅占据扇区资源的一小部分，则该降级的AF流可以升级回AF状态。

前面描述了数据流的接纳控制。一般地，可以针对任何潜在具有QoS要求的量来进行接纳控制。例如，接纳控制可以针对服务、应用、用户、终端等等来进行。因此，本说明书中的术语“数据流”一般地可以表示任何潜在具有QoS要求并且可以对其进行接纳控制的量。

图10示出了终端120的设计框图，其可以是图1的终端中的一个。在反向链路上，编码器1012可以接收一个或多个数据流的数据和在反向链路上由终端120发送的信令。编码器1012可以对数据和信令进行处理(例如，格式化、编码和交织)。调制器(Mod)1014可以进一步对编码数据和信令进行处理(例如，调制、信道化和加扰)以提供输出码片。发射机(TMTR)1022对输出码片进行调节(例如，转换至模拟、滤波、放大和上变频)，生成反向链路信号，其可经由天线1024向一个或多个基站传输。

在前向链路上，天线1024可以接收由一个或多个基站发送的前向链路信号。接收机(RCVR)1026对从天线1024接收到的信号进行调节(例如，滤波、放大、下变频和数字化)以提供采样。解调器(Demod)1016对采样进行处理(例如，解扰、信道化和解调)以提供符号估计。解码器1018进一步对符号估计进行处理(例如，解交织和解码)以提供发送给终端120的解码的数据和信令。编码器1012、调制器1014、解调器1016、和解码器1018可通过调制解调器处理器1010实现。这些单元可以根据网络所使用的无线技术(例如，HRPD、WCDMA等等)来进行处理。控制器/处理器1030可指示位于终端120的各个单元的操作。存储器1032可以存储终端120的程序代码和数据。

图10还示出了图1中的基站110a和110b的设计框图。基站110a可以是终端120的服务扇区，基站110b可以是终端120的邻近扇区或活动集扇区。在每个基站110，发射机/接收机1038可以支持与终端120和其他终端进行无线通信。控制器/处理器1040可以执行与终端进行通信的各种功能。对于反向链路，来自终端120的反向链路信号可由接收机1038进行接收和调节，进一步由控制器/处理器1040进行处理，以恢复终端发送的数据和信令。对于前向链路，一个或多个数据流的数据和信令可由控制器/处理器1040进行处理，并由发射机1038进行调节以生成前向链路信号，其可以发送给终端。存储器1042可以存储基站的程序代码和数据。通信(Comm)单元1044可以支持与网络控制器130进行通信。

图10还示出了网络控制器130的设计框图。在网络控制器130，控制器/处理器1050可以执行各种功能以支持终端的通信服务。存储器1052可以存储网络控制器130的程序代码和数据。通信单元1054可以支持与基站110进行通信。

接纳控制可由基站110、网络控制器130或其它实体来执行。控制器/处理器1040或1050可执行或指示图2中的过程200、图4中的过程400、图7中的过程700、图8中的过程800、图9中的过程900和/或用于本申请描述的技术的其他过程。

本领域技术人员应当理解，信息和信号可以使用多种不同的技术和方法来表示。例如，在贯穿上面的描述中提及的数据、指令、命令、信息、信号、比特、符号和码片可以用电压、电流、电磁波、磁场或磁粒子、光场或光粒子或者其任意组合来表示。

本领域技术人员还应当明白，结合本公开描述的各种示例性的逻辑框、模块、电路和算法步骤均可以实现成电子硬件、计算机软件或其组合。为了清楚地表示硬件和软件之间的可交换性，上面对各种示例性的部件、框、模块、电路和步骤均围绕其功能进行了总体描述。至于这种功能是实现成硬件还是实现成软件，取决于特定的应用和对整个系统所施加的设计约束条件。熟练的技术人员可以针对每个特定应用，以多种的方式实现所描述的功能，但是，这种实现决策不应解释为背离本公开的保护范围。

设计用于执行本申请所述功能的通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立门或者晶体管逻辑、分立硬件组件或者其任意组合，可以实现或执行结合本公开所描述的各种示例性的逻辑框图、模块和电路。通用处理器可以是微处理器，或者，该处理器也可以是任何常规的处理器、控制器、微控制器或者状态机。处理器也可能实现为计算设备的组合，例如，DSP和微处理器的组合、多个微处理器、一个或多个微处理器与DSP内核的结合，或者任何其它此种结构。

结合本公开而描述的方法或者算法的步骤可直接体现在硬件、由处理器执行的软件模块或者二者的组合中。软件模块可以位于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动磁盘、CD-ROM或者本领域公知的任何其他形式的存储介质。示例性存储介质可以耦合到处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。或者，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。该ASIC可以位于用户终端中。或者，处理器和存储介质也可以作为分立组件存在于用户终端中。

在一个或多个示例性设计中，所描述的功能可以在硬件、软件、固件或其任意组合中实现。如果在软件中实现，功能可以作为一个或多个指令或代码在计算机可读介质上存储或传输。计算机可读介质包括计算机存储介质和通信介质，其包括任何有助于将计算机程序从一个位置转移到另一位置的介质。存储介质可以是任何可由通用或专用计算机存取的可用的介质。通过示例性、而非限制性的方式，该计算机可读介质可以包括RAM、ROM、EEPROM、CD-ROM或其他光盘存储、磁盘存储或其他磁存储器件或任何其他介质，该介质可以用于携带或存储指令或数据结构形式的想要的程序代码模块，并且可由通用或专用计算机或者由通用或专用处理器存取。另外，任何连接都可以适当地称为计算机可读介质。例如，如果软件使用同轴电缆、光纤电缆、双绞线、数字用户线(DSL)或例如红外、无线电和微波的无线技术从网站、服务器或其他远方来源来传输，那么同轴电缆、光纤电缆、双绞线、DSL或例如红外、无线电和微波的无线技术包括在介质的定义中。本申请所使用的磁盘和光盘包括紧凑型光盘(CD)、激光视盘、光盘、数字通用光盘(DVD)、软盘和蓝光光盘，其中磁盘通常以磁的方式复制数据，而光盘采用激光以光学的方式复制数据。上述的组合也应当包括在计算机可读介质的范围内。

为使本领域任何技术人员能够实现或者使用本公开，上面围绕本公开进行了描述。对于本领域技术人员来说，对本公开的各种修改都是显而易见的，并且，本申请定义的一般原理也可以在不脱离本公开保护范围的基础上适用于其它变型。因此，本公开并不限于本申请描述的例子和设计，而是与本申请公开的原理和新颖性特征的最广范围相一致。