CN1981493A - 在无线通信系统中进行自适应延迟管理的方法和装置 - Google Patents

Abstract

用于对具有不同服务质量(QoS)需求的资源进行分配的自适应延迟管理装置和方法。前向链路(FL)调度器通过根据诸如尽力而为(BE)和快速转发(EF)的优先级类型处理未决的数据队列来准备传输实例。将来自多个队列的数据比特填充入传输实例。使用多种量度以便为传输生成候选组，并且然后从该候选组中选择和构造下一个传输实例。

Description

在无线通信系统中进行自适应延迟管理的方法和装置

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

本专利申请要求2004年5月5日提交的题目为“ADAPTIVEDELAY MANAGEMENT”的临时申请No.60/568,650的优先权，该临时申请已转让给本申请的受让人，从而清楚地将其合并于此作为参考。

本专利申请要求2004年11月4日提交的题目为“ADAPTIVEDELAY MANAGEMENT”的临时申请No.60/625,660的优先权，该临时申请已转让给本申请的受让人，从而清楚地将其合并于此作为参考。

技术领域

本发明一般涉及通信，并且更具体地，涉及在无线通信系统中使用自适应延迟管理的调度传输。

背景技术

无线通信系统包括使用电路交换或固定资源分配类技术对通信进行处理的系统，以及使用分组交换或动态资源分配类技术对通信进行处理的系统。电路交换和分组交换都可以用于有高容量能力的网络中。在电路交换通信系统中，在发送机和接收机之间建立专用通信路径，并且在传输开始之前，认为发射机和接收机之间的网络资源是静态的，并因此创建了“电路”。在整个传输期间，这些资源保持专门用于该电路，并且整个消息沿相同的路径。在分组交换网络中，将消息分解成多个分组，每个分组可以采取不同的路由到达目的地。一旦接收到分组，就对多个分组进行重新汇集，以便重新得到原始消息。在分组交换系统中，在节点之间对代表消息或消息片段的多个分组单独地进行路由。通过临时有利的路由将分组路由到目的地。换言之，即使当在相同两台主机之间传送的所有分组都是单独一个消息的组成部分时，这些所有分组未必都沿着相同的路由。

在分组交换系统或共享分组数据系统中，可以使用网际协议语音(VoIP)服务，模仿电路交换语音通信。典型地，VoIP是延迟灵敏应用或服务，并且因此，使用服务质量(QoS)机制来满足分组传递上的延迟约束。其它服务和传输类型也具有各种延迟需求或目标，以确保QoS。因此，需要在通信系统中对传输进行调度的自适应延迟管理。

附图说明

结合附图，从下文的详细描述中，当前所公开的方法和装置的特征、目标和优势将变得更加显而易见，在附图中，类似的参考符号贯穿全文一致，并且其中：

图1A是无线通信系统；

图1B是支持高数据速率传输的无线通信系统；

图2是无线通信系统中接入网络(AN)的方框图；

图3是在无线通信系统中用于传输的调度算法的流程图；

图4说明了分组数据调度器的分类；

图5说明了用于基于从用户所接收的数据请求来确定信道强度测量的反馈环路；

图6说明了在出现快速转发(EF)时调度器的行为-仅对具有单一业务类型的用户；

图7说明了从有效负载多项式p(z)计算压缩有效负载多项式c(z)；

图8根据一个实施例说明了调度器；

图9根据一个实施例说明了图8的调度器的一部分；

图10说明了用于实现传输的自适应延迟管理的调度算法；

图11根据一个实施例说明了图10的调度算法的一部分；

图12根据一个实施例说明了图10的调度算法的一部分；

图13根据一个实施例说明了图10的调度算法的一部分。

具体实施方式

对支持具有不同QoS需求的服务和应用的通信系统的操作可能不是最理想的并且可能效率低。例如，VoIP应用具有延迟需求。一种方法通过不依赖于负载和覆盖为多个用户提供相等的延迟约束来模仿语音。由于对资源进行分配以保证相等的延迟并且避免可能增加系统容量的优化，所以该方法不是最理想的。在一个实施例中，可以通过为各个用户提供不相等的延迟来增加系统容量，其中，将资源作为负载和覆盖的函数进行分配。

下文的讨论是关于用于系统前向链路(FL)的调度算法，所述系统支持1x EV-DO操作，即支持IS-856规范。在一个实施例中，调度算法利用各种多用户分组和短分组，在试图对FL容量最大化的同时满足各种应用的质量QoS需求。调度算法还可以提供对各种应用的优先次序进行区分的机制。该区分优先次序可以基于应用流的类型、特定的QoS需求、或者流的其它特征。在一个实施例中，基于应用的延迟灵敏度将多个流调度在FL上进行传输。在一方面中，基于延迟灵敏度对多个流进行区分，其中，延迟灵敏度与吞吐量灵敏度相平衡。虽然下文的讨论考虑在1x EV-DO规范的版本A的上下文中实现调度装置和方法，但是该调度装置和方法还可以应用于可替换的系统，特别地，该概念可应用于这样的系统，在该系统中，用户与IS-856规范特别是2002年10月3GPP2C.S0024版本4.0的“cdma2000高速分组数据空中接口规范”中所定义的子类型的给定子组相兼容。

在下文的描述中，诸如“版本A用户”或“与版本A兼容的用户”的术语将用于指接入终端(AT)，该AT支持IS-856特别是2004年3月3GPP2C.S0024-A版本1.0的“cdma2000高速分组数据空中接口规范”中所定义的媒体接入信道(MAC)层和物理层协议子类型。特别地，版本A用户支持增强前向业务信道MAC协议。诸如“版本0用户”的术语用于指支持IS-856中所定义的MAC层和物理层协议子类型的AT，但是该AT不支持版本A中所定义的更新的子类型。

在采用码分多址、CDMA方案的无线通信系统中，一种调度方法在时间复用的基础上、在指定的时间间隔上为每个用户单元分配所有的码信道。诸如基站BS的中心通信节点实现与用户相关联的唯一载频或信道码，以能够与该用户进行专用的通信。还可以在使用物理接触中继交换或分组交换的陆上线路系统中实现TDMA方案。可以将CDMA系统设计为支持诸如以下的一个或多个标准：(1)在这里被称为IS-95标准的“用于双模宽带扩频蜂窝系统的TIA/EIA/IS-95-B移动台-基站兼容标准”；(2)由在这里被称为3GPP的名为“第三代合作计划”的组织所提供的标准，该标准包含在包括文件Nos.3G TS25.211、3G TS25.212、3G TS25.213和3G TS25.214、3G TS25.302在内的一组文件中，在这里被称为W-CDMA标准；(3)由TR-45.5和在这里被称为3GPP2的名为“第三代合作计划2”的组织所提供的标准，在这里被称为cdma2000标准，其以前被称为IS-2000MC；或者，(4)某些其它无线标准。

CDMA系统允许在陆地链路上的用户之间的语音和数据通信。在CDMA系统中，通过一个或多个基站进行用户之间的通信。在无线通信系统中，前向链路指信号从基站传播到用户站的信道，并且反向链路指信号从用户站传播到基站的信道。通过在反向链路上将数据发送到基站，一个用户站上的第一个用户与第二个用户站上的第二个用户进行通信。基站从第一个用户站接收数据，并且将数据路由到正在对第二个用户站进行服务的基站。基于用户站的位置，可以通过单一基站或者多个基站对两个用户站进行服务。在任何情况下，对第二个用户站进行服务的基站在前向链路上发送数据。用户站还可以通过与服务基站的连接与陆地因特网进行通信，而不是与第二个用户站进行通信。在诸如这些符合IS-95的无线通信中，在不相交的频带内发送前向链路和反向链路信号。

图1A作为支持多个用户的通信系统100的例子，并且可以执行本发明的至少某些方面和实施例。可以使用多种算法和方法中的任何一种，在系统100中对传输进行调度。系统100为从102A到102G的多个小区提供通信，由相应的基站104A到104G分别对每个小区进行服务。在该示例性实施例中，一些基站104具有多个接收天线，并且另一些基站104仅具有一个接收天线。类似地，一些基站104具有多个发送天线，并且另一些基站104具有单一发送天线。在发送天线和接收天线的组合上不存在限制。因此，对于基站104，可能具有多个发送天线和单一接收天线，或者可能具有多个接收天线和单一发送天线，或者可能同时具有单一或多个发送和接收天线。

对无线数据传输不断增加的需求以及对通过无线通信技术可以提供的服务的扩展已经导致专用数据服务的发展。一个这种服务被称为高数据速率(HDR)。在被称为“HDR规范”的“EIA/TIA-IS856cdma2000高速分组数据空中接口规范”中提出了示例性HDR服务。通常，HDR服务是对语音通信系统的覆盖，其提供了在无线通信系统中对数据分组进行发送的高效方法。随着被发送数据量和传输数目的增加，用于无线电传输的有限的可用带宽成为急需资源。

图1B说明了通信系统120的结构参考模型，通信系统120具有通过空中接口124与接入终端AT126进行通信的接入网络AN122。在一个实施例中，系统10是码分多址CDMA系统，其在整个系统上具有诸如所指定的HDR标准的高数据速率HDR。AN122通过空中接口124与AT126以及系统120内的其它AT(未示出)进行通信。AN122包括多个扇区，其中，每个扇区提供至少一个信道。将信道定义为用于传输的通信链路组，该传输在给定频率分配内的AN122和AT之间。信道由用于从AN122传输到AT126的前向链路(FL)以及用于从AT126传输到AN122的反向链路(RL)组成。

对于数据传输，AN122从AT126接收数据请求。数据请求指定将要对数据进行发送的数据速率、被发送的数据分组的长度、以及数据将要从其中被发送的扇区。AT126基于AN122和AT126之间的信道质量确定数据速率。在一个实施例中，通过载干比C/I确定信道质量。可选实施例可以使用相应于信道质量的其它量度。AT126通过经由被称为DRC信道的专用信道发送数据速率控制DRC消息来为数据传输提供请求。DRC消息包括数据速率部分和扇区部分。数据速率部分指示所请求的数据速率，用于AN122发送数据，并且扇区部分指示AN122将要从其中发送数据的扇区。典型地，数据速率和扇区信息都是处理数据传输所需的信息。数据速率部分被称为DRC值，并且扇区部分被称为DRC覆盖。DRC值是经由空中接口124发送到AN122的消息。在一个实施例中，每个DRC值对应于以千比特/秒为单位的数据速率，根据预定的DRC值分配，所述数据速率具有相关联的分组长度。分配包括指定空数据速率的DRC值。实际上，空数据速率向AN122指示AT126不能接收数据。例如，在一种情况下，信道质量不足以使AT126正确地对数据进行接收。

在操作中，AT126对信道质量进行连续监测，以便计算AT126可以对下一个数据分组传输进行接收的数据速率。然后，AT126产生相应的DRC值；将该DRC值发送到AN122以请求数据传输。注意，典型地，将数据传输分成多个分组。发送数据分组所需的时间是所采用的数据速率的函数。

DRC信号还提供了信息，信道调度器使用该信息为与每个队列相关的每个远程站确定用于对信息进行消耗(或者对被发送数据进行接收)的瞬时速率。根据实施例，从任意远程站发送的DRC信号指示该远程站可以在多种有效数据速率的任意一种上对数据进行接收。

在图2中说明了通信系统的一个例子，该通信系统支持HDR传输并且适合于将传输调度到多个用户。在下文对图2进行了详细描述，其中，特别对基站820以及与分组网络接口806接口的基站控制器810进行了详细描述。基站控制器810包括用于为系统800中的传输执行调度算法的信道调度器812。信道调度器812确定服务时间间隔的长度，在该服务时间间隔期间，基于远程站对数据进行接收的相关联瞬时速率(如最近所接收的DRC信号中所指示的)将数据发送到任意特定的远程站。服务时间间隔在时间上可以是不连续的，但是可以每n个时隙出现一次。根据一个实施例，首先，在第一个时隙期间对分组的第一部分进行发送，并且在4个时隙后的随后时间对第二部分进行发送。同样，在具有类似4个时隙扩展的多个时隙内对分组的任何后续部分进行发送，即，彼此间隔4个时隙。根据一个实施例，对数据进行接收的瞬时速率R_i确定了与特定数据队列相关联的服务时间间隔长度L_i。

另外，信道调度器812为传输选择特定的数据队列。然后，从数据队列830中取得相关联数量的待发送数据，并且将其提供给信道部件826，以传输到与数据队列830相关联的远程站。如下文所讨论的，信道调度器812选择用于提供数据的队列，在随后的服务时间间隔内使用包括与每个队列相关联的权重在内的信息对数据进行发送。然后，对与被发送队列相关联的权重进行更新。

基站控制器810与分组网络接口806、公共交换电话网络(PSTN)808、以及通信系统中的基站(为简化起见，仅在图3中示出一个基站820)接口。基站控制器810对通信系统中远程站与其它用户之间的通信进行协调，其中，其它用户连接到分组网络接口806和PSTN808。PSTN808通过标准电话网络(图3中未示出)与用户接口。

虽然为简化起见在图2中仅示出了一个选择器部件816，但是基站控制器810包含许多选择器部件816。对每个选择器部件816进行分配，以便对一个或多个基站820和一个远程站(未示出)之间的通信进行控制。如果还未将选择器部件816分配给给定的远程站，则通知呼叫控制处理器818需要对远程站进行寻呼。然后，呼叫控制处理器818指示基站820对远程站进行寻呼。

数据源802包含待发送到给定远程站的一定数据量。数据源802将数据提供给分组网络接口806。分组网络接口806对数据进行接收，并且将数据路由到选择器部件816。然后，选择器部件816将数据发送到与目标远程站进行通信的每个基站820。在示例性实施例中，每个基站820保持数据队列830，该数据队列存储待发送到远程站的数据。

将数据在数据分组中从数据队列830发送到信道部件826。在示例性实施例中，在前向链路上，“数据分组”指最大为1024比特的一定量的数据，以及将要在预定“时隙”(例如：≈1.667毫秒)内被发送到目的远程站的一定量的数据。对于每个数据分组，信道部件826插入必要的控制字段。在示例性实施例中，信道部件826进行循环冗余校验CRC，进行数据分组和控制字段的编码，并且插入一组编码尾比特。数据分组、控制字段、CRC校验位、以及编码尾比特构成了格式化分组。在示例性实施例中，信道部件826然后对格式化分组进行编码，并且在被编码的分组内对符号进行交织(或者重新排序)。在示例性实施例中，以沃尔什(Walsh)码对被交织的分组进行覆盖，并且以短PNI和PNQ码对其进行扩频。将扩频数据提供给RF单元828，该RF单元828对信号进行正交调制、滤波和放大。在空中通过天线将前向链路信号发送到前向链路。

在远程站处，通过天线对前向链路信号进行接收，并且将其路由到接收机。接收机对信号进行滤波、放大、正交解调、以及量化。将数字化的信号提供给解调器(DEMOD)，在解调器处，以短PNI和PNQ码对信号进行解扩，并且以沃尔什覆盖对信号进行解覆盖。将解调后的数据提供给解码器，该解码器进行在基站820处完成的信号处理功能的逆处理，特别地，完成解交织、解码和CRC校验功能。将解码后的数据提供给数据宿。

如上文所指出的，硬件支持在前向链路上对数据、消息、语音、视频以及其它通信的各种速率的传输。从数据队列830发送的数据的速率发生改变，以适应远程站处信号强度和噪声环境的变化。每个远程站最好在每个时隙将数据速率控制DRC信号发送到相关联的基站820。DRC信号将信息提供给基站820，该信息包括远程站的身份以及远程站将要从其相关联数据队列对数据进行接收的速率。因此，在远程站处的电路对信号强度进行测量，并且对远程站处的噪声环境进行评估，以确定将要在DRC信号中发送的速率信息。

由每个远程站发送的DRC信号经过反向链路信道进行传送，并且在基站820处通过连接到RF单元828的接收天线对其进行接收。在示例性实施例中，在信道部件826中对DRC信息进行解调，并且将其提供给位于基站控制器810内的信道调度器812或者位于基站820内的信道调度器832。在第一个示例性实施例中，信道调度器832位于基站820内。在可选实施例中，信道调度器812位于基站控制器810内，并且连接到基站控制器810内的选择器部件816。

在电路交换系统中的传输调度可以包括正比公平算法，其中，为每个用户定义优先级函数。在下文给出了正比公平算法的例子。优先级函数可以将给定用户的被请求的数据速率以及用户的吞吐量考虑在内，其中，典型地，被请求的数据速率是到用户的前向链路信道质量的函数。这样，通过首先对那些与吞吐量相比具有高被请求数据速率的用户进行服务来平衡容量。

根据一个实施例，分组交换系统中的传输调度以用户延迟平衡容量。将应用流作为数据报进行发送，该数据报是在网络上发送的独立、自包含的消息。通常，不保证数据报的到达、到达时间和内容。可以通过不同的路由将与同一个应用流相关联的多个数据报发送到同一个用户。在接收机处对多个数据报进行重组。分组交换系统中的端对端延迟是不固定的，并且因此，调度器可以使用该延迟差异并且为各个用户调整延迟，以便增加容量。例如，对于请求具有低延迟界限和/或延迟变化限制的数据的用户来说，调度器可以减少该用户所体验的延迟。这种应用包括但是不被限制于VoIP、视频等。传输可以具有特定的服务等级(GoS)或QoS需求。例如，VoIP类型通信要求分组到达具有所定义的延迟时间、或者在所允许的延迟期间内。因此，可能期望将那些具有较低延迟时间需求或其它GoS规范的通信或应用列入优先。多媒体会议、视频流、网页浏览、文件传输协议传输，每个都具有特定的GoS需求。

为了实现优先级分类方案，为每个流分配优先级函数。那么，在一个实施例中，可以将用于分组交换调度器的优先级函数(PF)给定为：

PF＝f(延迟)

其中，f()是函数，并且然后基于给定用户或者用于用户的给定应用的延迟需求来确定PF。为每个队列中的每个数据报计算PF；将各个PF进行比较以便对较高优先级的流实例进行识别。由于给定通信的端对端延迟不是固定的，所以分组交换通信允许进行调度，以合并自适应延迟管理。这与电路交换通信形成对比，在电路交换通信中，端对端延迟是固定的。

注意，下文的讨论考虑了支持如IS-856中所描述的高速分组数据(HRPD)服务的cdma2000系统。使用该系统作为例子。本发明可应用于其它系统，在这些其它系统中，根据调度算法选择用户进行服务。

在HRPD系统中，空中接口可以支持多至四个并行应用流。第一个流传送信令信息，并且其它三个流可以用于传送具有不同QoS请求的应用或者其它应用。

为了清楚地对在下文所给出的一个实施例进行理解，提供了下列术语表。下列术语表不是想要穷举。下列术语表不是想要限制本发明，而是为了清楚并且理解通信系统的一个实施例，其中，所述通信系统支持自适应加权调度算法。

术语表

接入网络(AN)——提供在蜂窝网络和分组交换数据网络(典型地，是因特网)以及AT之间的数据连接的网络设备。HRPD系统中的AN等价于蜂窝通信系统中的基站。

接入终端(AT)——提供到用户的数据连接的设备。HRPD系统中的AT对应于蜂窝通信系统中的移动台。可以将AT连接到诸如膝上型个人计算机的计算设备，或者其可以是诸如个人数字助理(PDA)的自包含数据设备。

应用流(Application flow)——用于给定应用流的从源到AT的指定传输路径。通过源、目的地、流量简档和服务质量简档对每个应用流进行识别。

应用数据流(Application stream)——对应于应用的数据通信。大多数应用数据流具有指定的服务质量需求。

自动重复请求(ARQ)——一种机制，其中，发射机基于事件的发生或者不发生发起数据重传。

平均数据速率——给定应用流在时间上的平均输入数据速率。

突发(σ)——对应用流中分组的突发或者密度以及时间关系的测量。

尽力而为(BE)——应用流通常在空中有相对较大的数据量需要接收，而业务的特征是使得可以容忍相对较大的延迟，但是数据丢失率应该非常小。

数据速率控制(DRC)——一种机制，其中，AT将请求的数据速率发送到AN。

不足比特(defbits)——对应于不足分组的比特数目。

延迟界限——允许用于从AN到AT的数据分组传输的指定时间(延迟界限)。

快速转发(EF)——典型地，应用流具有从因特网到达接入网络的少量业务，然而，业务的特征是使得应该在某个相对较小的延迟界限内以合理的数据丢失率将数据分组传送到用户。

前向链路(FL)——从AN到AT的传输空中链路。

行头(HOL)分组——队列中的第一个分组。

高速分组数据(HRPD)——以高数据速率发送分组数据通信的数据服务。也被称为高数据速率(HDR)，并且在名为“cdma2000高速分组数据空中接口规范”的IS-856标准中对其进行详细说明。

抖动——所接收的连续分组之间的时间变化。

抖动界限——给定应用流的抖动上的界限。

运动图像专家组(MPEG)——用于多媒体素材传输的协议。

正比公平(PF)算法——一种调度算法，其中，根据为每个AT计算的选择因子对数据通信进行调度，将所述选择因子计算为被请求数据速率与吞吐量之比。

服务质量(QoS)——关于分组数据通信传输的需求，包括但是不限制于延迟、所需速率和抖动。

反向链路(RL)——从AT到AN的传输空中链路。

传输队列——为给定BTS存储应用流的传输队列。

许多无线通信利用因特网协议(IP)，以便为处理分组数据利用不同的每跳行为(PHB)和不同的路由。通常，因特网由从各个链路层技术构建的多个网络组成，该各个链路层技术依靠IP进行互操作。IP提供了无连接网络层服务，该服务受到随着网络负载而增加的分组丢失和延迟。基本的IP传送模型被称为尽力而为(BE)。然而，某些应用可能需要比简单的BE服务更好的服务。例如，多媒体应用可以指定固定的带宽、低延迟和小抖动。另一种优先级类型是被称为保障转发(AF)的转发行为，其保证了吞吐量级别。

在QoS管理中存在各个方面。QoS管理的某些考虑是共享媒介上的带宽分配以及保证带宽，该共享媒介已知为诸如以太网络或者无线局域网络(LAN)的广播网络。同时在膝上型计算机和其它计算设备中，存在对包括无线能力的日益增长的需求。然而，无线网络是带宽有限的，并且因此容量保持和优化成为关键性的考虑。

图3说明了调度方法，其基于服务级别(GoS)或QoS需求对传输区分优先次序。在AN处，将用于传输的数据存储在存储器存储单元中，该存储器存储单元适合于存储对应于输入应用流的数据队列。为应用流的每个实例存储队列。根据本发明，将应用流分成多个实例，其中，每个实例是八位字节数据。因此，一个应用流可以具有并且通常将具有与其相关的多个队列。那么，每个队列具有相关联QoS和/或GoS优先级类型定义的传输以及接收需求。例如，优先级类型可以基于端对端延迟需求或者基于某些其它质量标准。注意，给定的传输可能属于多种GoS优先级类型中的一种。例如，某些服务允许对数据分组进行单独发送，并且随后在接收机处无连续性损失地对这些数据分组进行再结合，即BE优先级类型。与此相反，诸如VoIP的、被设计为给用户实时体验的应用具有较高的优先级类型，并且被称为快速转发(EF)优先级类型。EF优先级类型包括在延迟界限和延迟变化上具有限制的应用。在当前例子中，调度器对EF通信区分优先次序。也可以将QoS或GoS优先级类型称为QoS类型。另外，每个队列具有与其相关的灵敏度。例如，典型地，EF应用流是延迟灵敏的，这意味着EF应用流的传输具有需要满足的延迟需求。在许多情况下，如果不符合延迟需求，那么就丢弃并且不发送数据。与此相反，典型地，BE应用流是吞吐量灵敏的，这意味着BE应用流的传输具有目标吞吐量需求，但是不必具有EF应用流的严格的延迟需求。

图3根据一个实施例说明了执行自适应延迟管理的调度方法200。在AN内，调度器执行调度算法，提供到多个用户的高速分组数据传输。调度器对数据队列进行检测，以便为数据确定GoS类型。如果任何数据具有给定的GoS优先级类型，即优先级类型比BE定义了更具体的需求，那么在判决菱形202处，过程继续进行到步骤204，以便找到队列中具有最高优先级类型的最早的数据。如这里所使用的，更高的优先级类型指由更严格的规范所定义的GoS优先级类型。例如，一种优先级类型可以指定延迟界限，而另一种可以指定抖动界限。在该情况中，认为指定延迟界限的优先级类型是更高的优先级，并且因此首先对其进行考虑。

根据本实施例，调度器首先基于延迟需求将比特排序成用于传输的多个分组。一旦对高优先级数据进行了调度，就可以应用另一种算法对剩余的分组进行调度。

例如，当EF数据在队列中时，调度器开始使用EF数据为传输构成分组。步骤204基于队列中数据的年龄来选择EF数据。在一个实施例中，随着将数据放入队列，在该时刻该数据接收到时间标志。调度器寻找具有最早时间标志的EF数据，并且将其首先放入分组中。随后，在步骤206中，调度器继续根据EF数据在队列中的年龄将其放入分组中。一旦将所有的EF数据放置入分组中用于传输，那么，调度器就将为其余的数据应用另一种算法。在本实施例中，在步骤208中，调度器将正比公平算法应用到其余的数据，该其余的数据可以是尽力而为(BE)的数据。随后，在步骤210中，根据正比公平算法将BE数据放入分组中。

注意，随着信道状况的增加，用户在更高的速率上请求数据，其具有降低延迟界限的效果。因此，即使当调度器对EF数据区分优先次序时，延迟界限也可以是信道状况的函数。

为了传输BE数据，调度器对分组进行选择以便对吞吐量进行最大化。通常，将吞吐量计算为：

吞吐量＝(比特每分组)/(时隙每分组)

根据一个实施例，可以将PF给定为：

PF＝f(分组年龄)*g(信道状况)*h(小区负载)

其在对传输进行调度中考虑了分组年龄以及信道状况和小区负载。可以将该计算用于对EF数据或BE数据进行调度。

再次返回图2，在一个实施例中，信道调度器832从数据队列830接收信息，该信息指示了为每个远程站进行排队的数据量，也被称为队列大小。然后，信道调度器832基于DRC信息和队列大小为由基站820服务的每个远程站进行调度。如果在可选实施例中使用的调度算法需要队列大小，那么信道调度器812可以从选择器部件816接收队列大小信息。

在将分组传输到一个或多个用户期间，用户在包含部分被发送分组的每个时隙之后发送确认“ACK”信号。由每个用户发送的ACK信号传播经过反向链路信道，并且在基站820处通过连接到RF单元828的接收天线对其进行接收。在示例性实施例中，在信道部件826中对ACK信息进行解调，并且将其提供给位于基站控制器810内的信道调度器812或者位于基站820内的信道调度器832。在第一个示例性实施例中，信道调度器832位于基站820内。在可选示例性实施例中，信道调度器812位于基站控制器810内，并且连接到基站控制器810内的选择器部件816。

本发明的实施例可适用于其它硬件结构，其可以支持可变速率传输。可以容易地对本发明进行延伸，以便覆盖反向链路上的可变速率传输。例如，基站820对从远程站接收的信号的强度进行测量并且对噪声环境进行评估，以便确定从远程站接收数据的速率，而不是基于来自远程站的DRC信号确定在基站820处对数据进行接收的速率。然后，基站820将速率发送到每个相关的远程站，将数据以该速率在反向链路中从远程站进行发送。然后，基站820可以以与这里描述为用于前向链路的方式类似的方式，基于反向链路上不同的数据速率对反向链路上的传输进行调度。

同样，上文所讨论的实施例的基站820使用码分多址CDMA方案向被选择的一个或多个远程站进行发送，而把与基站820相关联的剩余远程站排除在外。在任何特定的时间上，基站820通过使用分配给接收基站820的码字向被选择的一个或多个远程站进行发送。然而，本发明还可以应用于采用不同的时分多址TDMA方法的其它系统，以提供数据来选择将其它基站820排除在外的基站820，从而对传输资源进行最优分配。

信道调度器812在前向链路上对可变速率传输进行调度。信道调度器812从远程站接收队列大小和消息，队列大小是对将要发送到远程站的数据量的指示。信道调度器812最好对数据传输进行调度，以便实现最大数据吞吐量的系统目标，同时符合公平约束。

如图1A中所示，将远程站散布在通信系统中，并且远程站可以在前向链路上与零个或一个基站进行通信。在示例性实施例中，信道调度器812对整个通信系统上的前向链路数据传输进行协调。

根据一个实施例，在计算机系统中实现图2的信道调度器812，该计算机系统包括处理器、随机访问存储器RAM、以及用于存储被处理器(未示出)执行的指令的程序存储器。处理器、RAM和程序存储器可以专用于信道调度器812的功能。在其它实施例中，处理器、RAM和程序存储器可以是用于在基站控制器810处执行附加功能的部分共享计算资源。在示例性实施例中，将通用调度器应用于图2中所说明的系统800，并且在下文对其进行了详细描述。在建立了通用调度器的细节之后，讨论BSC810和BS820内的这些模块，这些模块用于为进行数据传输调度执行优先级功能。

随着对无线数据应用日益增长的需求，对非常有效率的无线数据通信系统的需求也显著增长。IS-95标准可以在前向和反向链路上发送业务数据和语音数据。根据IS-95标准，将业务数据或语音数据分割成20毫秒宽的码信道帧，其具有高达14.4Kbps的数据速率。在IS-95系统中，为每个用户站分配有限数目正交前向链路信道中的至少一个。当基站和用户站之间的通信正在进行时，前向链路信道保持分配给用户站。当在IS-95系统中提供数据服务时，即使当不存在将要被发送到用户站的前向链路数据时，前向链路信道也保持分配给用户站。

语音服务和数据服务之间的显著差异是这样一个事实：即前者强加了严格且固定的延迟需求。典型地，将语音帧的总单向延迟指定为小于100毫秒。与之形成对比，数据延迟可以成为用于对数据通信系统的效率进行优化的可变参数。

语音服务和数据服务之间的另一个显著差异是：前者对于所有用户需要固定且共同的服务等级(GoS)。典型地，对于提供语音服务的数字系统，这转化成对于所有用户固定且相等的传输速率以及对于语音帧错误率的最大容许值。与之形成对比，对于数据服务，GoS可以从用户到用户不同，并且可以是被优化以便增加数据通信系统总效率的参数。典型地，将数据通信系统的GoS定义为在预定量数据的传递中导致的总延迟，该预定量数据在下文中被称为数据分组。

语音服务和数据服务之间的另一个显著差异是：前者需要可靠的通信链路，在示例性CDMA通信系统中，通过软切换提供该可靠的通信链路。软切换导致从两个或多个基站的冗余传输，以提高可靠性。然而，因为可以对错误接收的数据分组进行重传，所以对于数据传输来说，不需要该额外的可靠性。对于数据服务，可以将用于支持软切换的发送功率更加有效地用于发送附加数据。

传递数据分组所需的传输延迟和平均吞吐量速率是用于对数据通信系统的质量和有效性进行定义的两个属性。对于数据通信，传输延迟不具有与对语音通信相同的影响，但是传输延迟是用于对数据通信系统的质量进行测量的量度。平均吞吐量速率是对通信系统的数据传输容量效率的测量。在本领域中存在对于这样的通信系统的需求，该通信系统提供提高的数据吞吐量，并且同时提供适合于在无线信道上提供的服务类型的GoS。

对于通用调度器的需求是基于无线系统中数据传输的需求和目标。对于数据传输，以在数据分组传输中所导致的延迟的形式对吞吐量进行定义，而不是以个别比特或字节的形式对吞吐量进行定义。如大多数情况中那样，诸如因特网协议IP数据报的数据分组是不可分割的单元，仅对部分分组进行接收不包含用户对整个分组进行解码和使用的足够信息，即该分组对于终端用户是无用的。终端用户对数据分组进行接收、在数据分组上进行循环冗余校验CRC、并且对数据进行处理。因此，用户最关心分组的最后一个比特的到达时间，并且不像在数据分组中那样关心各单个比特的延迟。这允许在小于数据分组传输时间的时标上将速率分配给不同用户中相当大的灵活性。此外，在传输控制协议TCP类型连接中，只要变化不是太不可预测以致于引起不必要的TCP重传，分组延迟的某些变化就是可以接受的。

无线信道的另一个特征是信道自身的可变性。在HDR类型系统中，该可变性导致在一段时间周期上所请求速率的变化。为了对信道的使用进行最大化，将调度器设计为对高速用户、即请求最高数据速率的用户进行服务。这意味着当用户所请求的速率较低时，在该时期内偶尔可以不对用户进行服务。当调度器长期不对低速率用户进行服务时，将对总吞吐量进行最大化。然而，理想地，调度器将此与如在上文所解释的分组延迟和延迟变化相对一致的期望进行平衡。

另一方面考虑对系统中多个用户的公平。为了实现公平调度方法，调度器在不同用户之间理想地对总吞吐量进行分配。不同的系统使用不同基础的公平(或者可允许的不公平)，以影响各个系统的需求和期望。公平的概念是许多调度算法中的关键概念。公平在对不同用户进行服务中提供了不同数量的灵活性，并且因此对扇区的总吞吐量具有影响。

根据一个实施例，用于在通信系统中对传输进行调度的、可应用于多种类型用户的方法和装置合并了通用调度器。通用调度器提供了多种不同的调度优先级。由通用调度器对不同类型的用户进行服务，每个用户具有特定的传输需求，这在所有用户上维持了高吞吐量。

在一个实施例中，通用调度器的操作执行了信道状况量度和公平标准的优先级函数，其中，将该优先级函数定义为：

f(A_i(t)，U_i(t))

其中，A_i(t)被称为信道状况量度，并且U_i(t)被称为用户公平量度。函数A_i(t)基于当前信道状况指定了在时刻t对用户i进行服务的期望。函数U_i(t)基于所接收到服务的过去历史指定了在时刻t对用户i进行服务的期望。优先级函数f()将两个期望量度A_i(t)和U_i(t)进行结合，以便为每个用户确定优先级级别。

根据一个实施例，在给定类或类型的用户内，通用调度器对具有最高优先级函数f(A_i(t)，U_i(t))的用户进行服务。在示例性实施例中，优先级函数f(A_i(t)，U_i(t))所取的值随着信道状况函数A_i(t)的增加而增加，并且随着公平函数U_i(t)的增加而减少。从而确定了函数A_i(t)和U_i(t)。此外，优先级函数f()是至少一个时间周期的函数，在该至少一个时间周期上对信道状况量度和用户公平量度进行测量。在可选实施例中，优先级函数f()可以是每用户取决于时间的函数。然而，为简便起见，调度器可以使用对于所有用户共同的合成器函数，并且对用户公平量度进行修改以便反映用户需求。

通用类型的多用户调度器将正在从AN接收服务的用户分为BE和EF至少两大类。也可以执行诸如AF等的其它传输分类。在这里对BE和EF进行了定义。特别地，尽力而为(BE)应用通常在空中具有相对大量的数据需要接收，同时业务的特征是使得可以容忍相对较大的延迟，但是数据丢失率应该非常小；典型地，快速转发(EF)应用流具有从因特网到达接入网络的少量业务，然而业务的特征是使得应该在某个相对较小的延迟界限内、以合理的数据丢失率将数据分组传送给用户。

在诸如1x EV-DO的分组数据系统中，调度器具有对各单独用户允许可变延迟性能以便对容量进行最大化的灵活性。这里，在诸如VoIP的延迟灵敏业务(EF用户)情况下，容量指BE用户的吞吐量以及以可接受性能被服务的用户的数目。

通常，在1x EV-DO中，增加用户的延迟界限提高了对FL的利用，因此增加了系统的BE和EF容量。该容量增加遵循多种因素，这些因素包括但是不限制于更高的打包效率以及利用本地信道状况和多用户分集增益的能力。

在仅具有BE业务的情况下，典型的调度器是正比公平(PF)调度器。由于提供给各单独用户的吞吐量将大约正比于用户的几何条件(geometry)即平均信道状况，所以该调度器是正比公平的。由于吞吐量与公平权衡的益处，正比公平调度器已经是用于仅存在BE业务的调度器的选择。另外，将PF算法设计为利用本地信道峰值同时提供多用户分集增益。如在这里所使用的，将这种PF调度器称为“正比公平吞吐量调度器”。

注意，在仅存在BE业务的情况下，存在另一类调度器：“相等服务级别”调度器。该调度器旨在将相等的吞吐量提供给所有用户。因此，系统容量由最弱的用户来确定。虽然在某些应用中可能期望相等服务等级调度器，但是典型地，这种调度器不能有效地利用空中链路。这些调度器在这里被称为“相等吞吐量调度器”。

上文所描述的PF吞吐量调度器和相等吞吐量调度器在仅具有BE业务的上下文中是有用的。对于延迟敏感EF业务，由于缺少用于延迟控制的机制，这些调度器可能是不足的。

以下提出了延迟灵敏调度装置和方法，其与用于仅存在BE业务的两种方法-即PF吞吐量和相等吞吐量调度器并行工作。在延迟灵敏业务情况下，“正比”对“相等”公平不仅适用于提供给各单独用户的吞吐量，也适用于提供给各单独用户的“延迟”性能。可以以平均延迟或延迟尾重(delay tail weight)等的形式对延迟性能进行量化。注意，可选实施例可以将BE和EF调度合并入共同的方法，同时分别符合吞吐量和延迟灵敏需求。

在一个实施例中，可以为每个用户提供大约相等的延迟性能。该方法类似于相等吞吐量，并且为了术语的对称被称为“相等延迟调度器”。相等吞吐量调度器试图为所有的用户提供相等的吞吐量，因此，系统容量可以由具有最弱覆盖的用户来确定。相等延迟调度器试图为所有的用户提供诸如相等平均延迟或相等延迟尾重的相等延迟性能，并且因此，类似地，系统容量由具有最弱覆盖的用户来确定。

在另一个实施例中，提供给用户的延迟性能正比于用户的平均几何条件。该方法类似于正比公平吞吐量调度器并且被称为“正比公平延迟调度器”。正比公平吞吐量调度器试图为各单独用户提供正比于他们平均几何条件的吞吐量，因此，与相等吞吐量调度器相比，显著地提高了系统容量。类似地，正比公平延迟调度器将为每个单独的用户提供正比于该用户平均几何条件的延迟性能，从而对EF容量进行最大化。

在图4中说明了四种分类的分组调度。平衡QoS考虑来说明每种分类。特别地，PF吞吐量调度器将吞吐量控制与正比公平进行平衡。相等吞吐量调度器将吞吐量控制与相等公平进行平衡。PF延迟调度器将延迟控制与正比公平进行平衡。相等延迟调度器将延迟控制与相等公平进行平衡。

虽然某些调度方法在电路交换系统中是有用的，但是另一些调度方法更适用于诸如1x EV-DO的分组数据系统。在这里所提出的正比公平延迟调度装置和方法可以在电路交换系统上提供分组交换系统的优点。

除了提高系统容量之外，PF延迟调度器还可以增强用户体验。例如，紧密接近BS的用户比远离BS的用户更可能获得较好的延迟性能。这与不取决于用户是否接近AN的延迟性能相反。另外，对于在紧密接近BS的高几何条件的用户，可以以高置信级别对性能进行预测；而对于相等延迟调度器，性能是不能够根据系统上的当前负载预测的。因此，期望调度器提供随着各单独用户的几何条件的增加而增加的服务质量。

同时对BE和EF用户服务的调度器可以利用对正比公平吞吐量和延迟调度的恰当结合。这种调度器将被称为“正比公平吞吐量/延迟调度器”。注意，在一个实施例中，正比公平吞吐量/延迟调度隐含地基于单一扇区服务的各用户的相对几何条件。这被称为“扇区内公平”。在调度器设计中需要考虑的另一个因素是“小区内”公平，可以将其描述为服务的平均级别，可以以提供给BE用户的吞吐量和提供给EF用户的平均延迟等的形式对其进行量化，通过不同的扇区将其提供给被那些扇区服务的用户。

为了继续正比公平吞吐量调度器和正比公平延迟调度器之间的类比，注意，由利用正比公平吞吐量调度器的扇区提供给各单独BE用户的吞吐量随着被那个扇区所服务的用户数目的增加而减少。然而，维持了扇区内公平。类似地，可以允许由利用正比公平延迟调度器的扇区提供给各单独EF用户的延迟性能随着被扇区服务的用户数目的增加而增加。

正比公平吞吐量/延迟调度器利用下列形式的判决量度，以便选择在任意调度判决上对哪些用户进行服务：

DecisionMetric＝f(PacketAge，ChannelCondition，SectorLoad)其中，PacketAge指当前时间和为在基站队列中等待的每个分组所定义的恰当的时间标志之间的差异，ChannelCondition指BS和AT之间的无线电链路的质量，并且SectorLoad指由扇区在当前时间周围的短时间跨度上进行服务的总业务的量和概况。函数f()取决于调度器的特定实现。同时，DecisionMetric可以指比特量度、分组量度、数据报量度、或者任何其它为调度器提供传输实例选择方法的手段。

可以以各种方式将信道状况信息合并入调度器中。例如，正比公平吞吐量调度器使用数据速率控制(DRC)/平均吞吐量，其在本地信道峰值期间趋向于峰值。另一种方法可以是使用DRC/AvgDRC，但是在应用中可以有助于具有更大信道波动的用户。另一种可能性可以是使用反馈环路以便指示信道峰值的某个百分比。在图5中说明了一种这样的环路300。

如图5中所说明的，一个实施例是环路300，该环路300被设计为关于阈值确定可接受的信道质量。输入IDRC是DRC值的函数或索引，例如，是与DRC相关联的数据速率的增函数，其中，IDRC随着被请求数据速率的增加而增加。将IDRC提供给比较单元302和无限脉冲响应滤波器(IIR)306。在一个例子中，将时间常数设置为1秒，然而，可以执行可选的时间常数。将IIR滤波器306的滤波输出提供给求和单元312，求和单元312将阈值提供给比较单元302。比较单元302将IDRC与阈值进行比较。比较的结果指示当前的信道质量是否是可接受的。当信道质量应该是可接受的时，系统确定时间的目标百分比。在本例子中，将目标设置为30％。目标是可变的，并且在操作期间可以对其进行调节。可选系统可以执行其它目标值或方案。比较单元302的输出是二进制{1，0}，其中，1指示可接受的信道质量并且0指示不可接受即低于阈值的信道质量。

继续图5，将比较单元302的输出提供给IIR滤波器304，其中，在本例子中，将时间常数设置为0.5秒。可以执行可选的时间常数。将来自IIR滤波器304的滤波输出提供给比较单元310，用于与输入值进行比较，在本例子中，输入值为0.3。如果比较的结果大于输入值，那么将信号提供给上/下累加器308，以便增加用于确定信道质量的阈值。这指明来自比较单元302的信道质量指示比30％大1。否则，如果比较低于输入值，那么提供给上/下累加器308的信号指示阈值的增加。将上/下累加器308的输出提供给求和单元312。求和单元312对上/下累加器308的输出和IIR滤波器306的输出进行求和，其中，来自IIR滤波器306的输入为比较单元302提供了用于阈值的一般偏差。将求和的结果提供给比较单元302。从比较单元302的输出得到信道评估指示。以这种方式，调度器维持信道评估指示或信道状况信息，以便对当信道状况为良好即信道峰值时的良好时间的百分比进行识别。

可以通过对BE和EF流量进行测量将扇区负载合并入调度器中。最后，调度器所使用的实际判决量度可以不明确地包括信道状况和扇区负载测量。可以通过对一部分EF用户进行测量来自适应地选择每用户所需的延迟界限，其中，对于一部分被发送的IP分组，该一部分EF用户可能不符合它们的延迟界限。

某些调度器所使用的参数被称为流的“QoS类索引”，其定义了那个流的相对优先级。存在可以对QoS类型进行确定的多种方法。在给定的QoS类型中，不同的流可以具有非常不同的业务类型。QoS类索引是对流所需优先级级别的指示，而不是对业务的统计行为的指示。

在一个实施例中，QoS类索引是为调度器选择的、以便为具有较高QoS类索引的流提供较高优先级的非负整数值。这里，QoS类索引0对应于BE/AF流；其中，BE流是AF流的特殊情况，其中，将AF流的最小所需吞吐量值设置为零。QoS类索引1以及更高的值对应于EF流。

注意，为较高的QoS类给予较高的优先级，然而，不一定必然将BE数据调度为在所有在队列中进行等待的EF数据被发送之后被发送。作为例子，调度器可以对多用户分组进行调度，以便发送接近界限数目的EF比特。在相同的传输实例中，调度器还可以包括来自具有兼容DRC即传输格式的用户的BE数据，而不包括来自具有不兼容DRC的用户的EF比特。

可以通过三个参数来近似地表现QoS流的特征：(1)IP数据报大小的分布，(2)IP数据报之间到达时间间隔的分布，以及(3)相对于IP数据报的时间标志的延迟界限，在该IP数据报的时间标志之后，数据报的内容变为无效。

对于BE/AF流，延迟界限没有EF流那么严格，所以对于BE/AF流，将不考虑延迟界限，其中，AF是保障转发流。对于具有相同延迟界限但是在IP数据报大小和到达时间间隔分布中不同的EF流，将调度器设计为几乎线性运转。例如，具有如VoIP流那样相同延迟界限和分组大小分布、但是具有一半到达时间间隔分布的给定流将大约与两个VoIP流表现相同。类似地，具有相同延迟界限和到达时间间隔分布、但是具有两倍的如VoIP流的数据报大小分布的流，对于调度器来说将也大约表现为两个VoIP流。可以容易地将分组大小和到达时间间隔的非整数倍预见为基本“单元”流类型的集合。

然而，与数据报大小和到达时间间隔分布相比，延迟界限对调度器具有非常不同的影响。调度器以较高优先级对待具有较低延迟界限的流。从某种意义上看，将流的延迟界限设置为较低值是增加其QoS类索引的软方式。

如之前在上文所讨论的，传输的调度与准入控制有关，其中，准入控制确定了何时接受用户或流进行处理和调度，随后确定了将在何时并且以何种方式对该流进行发送。换言之，准入控制确定了哪个数据将是适合被包含在传输实例中的，并且然后调度确定了特定数据、格式以及传输实例的次序。因此，调度器操作可以对给定系统中所使用的准入控制方案产生影响。

根据一个实施例，典型地，随着系统负载的增加，对BE/AF流进行调度，使得每个流公平地经受降级。然而，典型地，对于EF流，降级是不均匀的。更具体地说，为了试图恰当地维持较高的QoS类机能，首先对较低的QoS类进行降级。在给定的EF QoS类中并且忽略延迟界限设置中的差异，对具有较低几何条件的用户进行降级，以便保持尽可能多的用户接收到期望的性能。采用该方法以便对所支持的EF用户的数目进行最大化。对于同类EF流，从最低几何条件的用户开始并且蔓延到较高几何条件的用户，对EF用户进行不均匀地降级。该方法具有若干个在调度器外部进行处理的结果，并且更具体地说，具有若干个通过准入控制处理的结果。在下文例子中对这些结果中的某些进行了说明。

在图6中说明了调度器的该功能，其中，以根据几何条件从左到右增加进行分类的次序示出了多个流。对于当前系统负载，调度器给较低几何条件用户较低的优先级，以便对接收到期望QoS的QoS流的数目进行最大化。低几何条件用户的级别向右传播伴随着不断增加的拥塞。调度器通过给这种用户较低的优先级来对这些用户所接收的服务进行降级。然而，它不负责完全去掉一个流，典型地，这是准入控制和其它性能监测方框的功能。

考虑一种情况，其中，所有用户具有诸如VoIP流的单一流并且具有相同的QoS类，并且最高几何条件的用户要求非常高吞吐量的EF流。即使这意味着没有到其他用户的传输，调度器也可以将所有FL时隙分配给最高几何条件的用户。通常，由准入控制处理来处理对于流的准入判决，该准入控制处理考虑系统的当前负载。当准入控制允许该流时，调度器执行任何基本功能并且将所有的FL时隙分配给那个用户。注意，首先对较低几何条件的用户进行降级并不必然意味着调度器对具有可接受接收性能的EF用户的数目进行了最大化。如果所有的用户具有相同的QoS参数和相同的业务类型(例如：仅VoIP)，那么调度器可以对该数目进行最大化。

如果低几何条件的用户要求非常低的吞吐量(例如：1字节每秒)，其中，由于轻度拥塞，调度器对该用户的服务进行降级，那么，即使这将不影响FL性能，调度器也不会将所请求或所期望的吞吐量给该用户。再次，在当前系统负载下，对关于该用户的调度器操作进行预期，这是准入控制的责任。在该情况下，准入控制可以通过增加该用户的QoS类索引迫使调度器对其提供服务。

对于下列讨论，将同类EF业务作为特定情景考虑，其中，所有的用户是具有相同业务模型的EF用户。调度器首先为单用户和多用户传输格式组创建候选传输实例列表。以来自相应用户队列的比特对单用户格式进行填充。以来自具有兼容DRC的用户队列的比特对多用户格式进行填充。

随后，调度器将分组量度分配给候选实例中的每个，并且选择对应于最大分组量度的候选传输实例。分组量度可以是“吞吐量多项式”，其中，将比较操作定义为“词汇的”比较，其提供了定义准确的最大化。

为特定情况考虑分组量度，其中，诸如仅存在VoIP的系统，所有用户是EF用户并且每个用户具有相同类型的一个EF流以及多用户传输格式，其中，为了创建该格式的多用户传输实例，从具有兼容DRC的用户队列填充比特。在这些用户之间，在先进先出基础上，基于相应IP数据报的时间标志对比特进行选择。对于该例子，假定延迟界限是相同的。在具有相同时间标志的比特之间，选择遵循IP分组内的次序，并且在不同用户之间，以使得对在分组中具有数据的用户数目最小化的方式进行选择。

那么，可以将传输实例的有效负载多项式给定为：

p(x)＝B_Dz^-D+B_D-1z^-D+1+…+B₁z^-1+B₀

其中，B_n代表包括在导致n个时隙延迟的候选传输实例中的比特数目。由于当比特已经在队列中存在了超过延迟界限的时间周期并且因此导致多于D个时隙的延迟时，可以从队列中取出该比特，所以D的值可以等于延迟界限。

通过对有效负载多项式进行滤波和子采样来获得吞吐量多项式。一种方法是将有效负载多项式的系数向量分段成N组，然后对每组内的系数进行求和，以获得有效负载多项式的压缩表示。然后，通过对压缩有效负载多项式进行分割获得吞吐量多项式，其中，由用于将要被所有感兴趣用户解码的候选传输实例的期望时隙数目对压缩有效负载多项式进行分割。在图7中说明了该过程，其中，最顶行是有效负载多项式p(x)，最底行是有效负载多项式的压缩表示c(x)。变量x是传输实例索引。

那么，将吞吐量多项式给定为：

T(z)＝c(z)/N_g

其中，N_g是用于所考虑的传输格式的“一般”跨度，并且在下文对其计算方法进行了讨论。然后，将所得吞吐量多项式用作分组量度，用于从一组以类似方式获得的其它可选项中选择候选传输实例。

注意，上文所描述的分组量度暗含了在强行延迟和吞吐量之间的权衡。如果将N-1选择为等于D，即如果c(x)＝p(x)，那么分组量度将强迫导致最大延迟的比特首先传输。随后，在选择候选传输实例中，将考虑导致次最大延迟的比特。这是在对分组量度(即吞吐量多项式)进行比较中所使用的“词汇的”比较的结果。以这种方式，通过对每个多项式的最高次项进行识别来开始比较。如果一个多项式具有较高的次项，那么将该多项式定义为较大的多项式。如果两个多项式具有相同的次项，那么从最高次项开始对其系数进行比较；当在一个多项式中找到较高的系数时，将该多项式定义为较大的多项式。

对系数p(x)进行分割以获得c(x)隐含地忽略了对应于每个分段内的比特所导致的延迟中的差异。反过来，存在对吞吐量的最大化，其现在具有更多的灵活性。如果将p(x)的所有系数合并在单一分段内(例如：c(x)次幂为零)，那么将获得对吞吐量进行最大化中的最大灵活性。

在一个例子中，两个分段(例如：c(x)次幂为一)提供了折衷。最大次幂项具有最大影响。当在各个候选实例之间存在联系时，将考虑c(x)的项。因此，可以不必将p(x)的系数分段成多于两个分段。这导致需要对单一参数进行最优化，我们用α代表该参数并且将其称为“延迟分数”。总之，采用两个分段，c(x)＝(hi2)z^-1+(hi)，其中，“hi2”和“hi”分别是每个分段中比特的数目。更具体地说，hi2是包括在候选传输实例中的比特的数目，该比特导致大于α倍延迟界限的延迟，并且，“hi”是导致较小延迟的比特的数目。

对于用户具有所有EF业务、但是具有不同业务模型(例如：不同延迟界限)的情况，对变量进行修改。具有较小延迟界限的比特早于具有较大延迟界限的比特成为hi2分段的一部分。对此进行实现的自然方法是在将比特填充入候选传输实例中以及在确定比特将在何时成为hi2项的一部分中使用β倍的延迟，这与单独使用“延迟”是相对的。

通常，将β设计为与延迟界限上的一个量成正比。其结果是：具有较低延迟界限的EF比特将趋向于比具有较大延迟界限的EF比特有优先级。

图8根据一个实施例说明了调度器。调度器600包括自适应延迟控制单元602，将其连接到适合于对队列信息进行存储和维持的存储器存储单元604。存储器存储单元604还存储关于每个队列的信息，包括延迟和/或吞吐量灵敏度、诸如EF、BE等的优先级类型、以及诸如其它QoS信息的其它可以被设计在调度器中的信息。将存储在存储器存储单元604中的队列数据和信息提供给比特量度计算单元608和比特填充量度计算单元606。这些单元分别生成比特量度和比特填充量度。将所计算的比特量度提供给比特量度计算单元608、分组量度计算单元616、以及队列选择单元610。将比特填充量度和所选择的队列提供给候选传输实例发生器612。将来自分组量度计算单元616的分组量度以及由发生器612生成的候选传输实例组提供给传输实例选择单元614。

图9详细描述存储器存储单元604，其对具有未决数据的多个队列进行存储。对于每个流，将队列数据存储为队列数据620。对于每个队列620，存在相应的QoS类型或优先级类型622以及灵敏度指示符624。

图10是根据一个实施例说明了调度方法的流程图。方法500首先在判决菱形框502处确定FL是否忙，即时隙是否可用于新的分组传输。如果时隙可用于新的分组传输，那么在步骤504调度器基于所定义和所得到的传输格式的子集生成一列候选传输实例。在步骤506处计算对应于每个候选传输实例的分组量度。在步骤508处，调度器选择具有最大分组量度值的传输实例。在步骤510处，对传输实例进行格式化以进行传输。

图11说明了一个实施例，其用于生成一组候选传输实例并且执行方法500中的步骤504。在步骤520处，调度器为每个队列条目(entry)计算比特量度。在步骤522处，调度器为每个队列计算比特填充量度。在步骤524中，对比特量度值进行比较，以便为传输实例选择一组队列。在步骤526中，将比特填充量度用于使用队列组生成候选传输实例。在下文提供了用于该计算和比较的方法和装置的例子。

注意，在一个实施例中，为每个具有未决数据的用户生成具有单一用户格式的候选传输实例。将传输格式设置为相应于那个用户DRC的规范格式。对于已经从其对NULL DRC进行接收的用户，仅当用户具有未决“EF”数据时，才创建候选传输实例。对于BE/AF用户，由于这些用户试图在无线链路协议(RLP)层维持低掉线率，所以不提供NULL DRC。

为每个所定义和所得到的“规范”多用户格式生成具有多用户格式的候选传输实例。可以使用标志，以便允许在该阶段中所得到的格式。

注意，在步骤506中产生的候选传输实例组是基于“规范”格式。即在该步骤中不包括短分组。其目的是帮助调度器偏向较高几何条件的用户，并且避免低几何条件用户滥用短分组，并且因此减少FL吞吐量。当被选择的候选传输实例具有适合短分组的有效负载时，在打包效率最大化步骤中使用短分组(如图12中所说明)。

可以与图12一致执行打包效率最大化步骤。在该步骤中，被选择的候选传输实例可以根据以下规则经历传输格式的变化：

(1)如果所选择的候选传输实例包含单一用户的数据，那么允许被重新选择的格式是与用户DRC兼容的单用户格式或者多用户格式。

(2)如果所选择的候选传输格式包含两个或多个用户的数据，那么被重新选择的格式仅可以是另一个多用户格式。在任一种情况下，选择可以传送有效负载的最小格式。通过标志对该后变换进一步控制，其可以避免到某些多用户格式的变换。

在一个实施例中，对传输实例进行格式化的步骤510还包括步骤530和步骤532，在步骤530处，调度器对传输实例的打包效率进行最大化，并且在步骤532中，调度器执行先验ACK计算，见图12。另外，步骤530可以包括如图13中所说明的方法。在判决菱形框540处，首先对传输实例进行评估，以便确定是否使用了单用户格式。如果使用了单用户格式，那么在下文对每个步骤进行更详细的描述。

在一个实施例中，调度器确定对应于用户DRC的最大跨度，所选择的传输实例将为所述用户传送数据比特。调度器对所指定的传输时隙的数目进行计数。如果存在尚未对所发送信息即所发送的ACK消息的正确接收进行确认的任何用户，并且如果在任何队列中存在未决的数据，那么AN终止传输。

可选实施例包括用于完成图10中所说明的方法500的具体装置和方法，其包括但是不限制于创建每个候选传输实例的比特填充以及分组量度的计算。

在步骤508中进行分组量度计算，而比特填充是步骤508中对传输实例进行格式化的一部分。通常，可以以来自相同用户的一个或多个流的比特对单用户传输实例进行填充。可以以来自一个或多个用户的比特对具有诸如在表1中“所定义”格式的多用户实例进行填充，其中，该用户已经发送了与多用户格式兼容的DRC。可以以来自一个或多个用户的比特对具有“所得到的”格式的多用户实例进行填充，所述一个或多个用户发送了与多用户格式兼容的DRC并且满足“软兼容(soft compatibility)”的额外需求。如果对相应“被定义”格式进行解码所需的期望时隙数目小于或等于所得到格式的跨度，那么就认为DRC与所得到的多用户格式是软兼容的。可以通过将被接收DRC所需的信号与干扰和噪声比(SINR)与对所得到的格式成功地进行解码(例如：在平均白高斯噪声(AWGN)情况下)所需要的SINR进行比较，以获得所期望的时隙数目。可替换地，可以通过将被请求的速率与所得到格式的有效数据速率进行比较来确定所期望的时隙数目。

下文的描述假定QoS类包括：i)BE/AF；以及一类EF。方法也允许到多个EF类的延伸。根据本实施例，为队列中未决的每个比特分配比特量度，将该比特量度给定为多项式的形式：

b_i(z)＝[hi2]z^-2+[hi]z^-1+[lo]

其中，i是比特的索引，并且仅允许{ji2，hi，lo}三个系数中一个为非零。注意，虽然将描述给定为比特级别，但是典型地，IP数据报内所有的比特具有相同的量度，并且分组量度计算可以不必包括比特级别的累加。

令δ为与来自EF流的比特相关联的当前延迟。为hi2和hi设置下列定义：

hi2＝βδ+μ如果δ＞αDelaybound

并且

hi＝βδ+μ如果δ≤αDelaybound

其中，β是与EF流相关联的参数并且关于延迟界限成反比；其中，μ是一个很大的数；并且其中，α是诸如0.25的固定标量，并且α不取决于EF流的类型。

对于BE/AF流，将lo设置如下：

$\mathrm{lo}=\frac{1}{\mathrm{AvgThroughput}-\mathrm{TrgtThroughput}}$

其中，AvgThroughput是相应用户的平均吞吐量，并且TrgtThroughput是对于该用户所期望的最小吞吐量。对于BE用户，将目标吞吐量设置为零。然后，获得分组量度(例如：吞吐量多项式)，如下：

PacketMetric＝AccumulatedBitMetric/Ng

其中，Ng是在考虑中所定义或所得到的候选传输实例的一般跨度，并且累计比特量度(AccumulatedBitMetric)是相应于被包括(被填充)在候选实例中的所有比特的比特量度之和。可以将Ng值设置为所定义或所得到类型的标称跨度。可替换地，在分组量度等于累计比特量度的情况下，可以将其设置为1。在该情况下，调度器将起作用，以便对每传输实例的有效负载而不是每传输实例的吞吐量进行最大化。这可能引起DRC不灵敏的不期望的影响，因此导致被降级的性能，其中，该降级可以不遵循图6中所说明的行为。另一种方法是将Ng设置为“伪跨度”，对于1和2个时隙的高速分组，可以将其设置为1，对于4个时隙的分组，可以将其设置为2，等，因此基于有效负载对高速分组进行区分，同时通过将Ng设置为较大值来阻碍低速率格式。

下列属性为调度器提供了对高几何条件用户的偏向：

(1)如果DRC与多用户格式兼容，那么它也与所有具有较低标称数据速率的多用户格式兼容；以及

(2)调度器将“吞吐量”多项式用作选择设备。

一种设计在用于比特量度的hi和hi2系数定义中使用了较大的μ值项。由于μ对于所有比特是共同的，所以根据βδ值按次序对比特进行填充。对分组量度进行计算，就好像将比特量度的相应条目改变为1、从而导致分组量度正比于吞吐量多项式。这消除了分组量度中βδ对分组量度计算的影响。

注意，如上文所描述，调度器将固定的延迟界限应用到所有的用户。典型地，体验良好覆盖的用户仅需要延迟界限的一部分。随着用户数目的增加，首先在最弱的用户处开始出现降级，而在较高几何条件处的用户可能不会强烈地受到负载影响。

一个实施例通过对良好EF用户部分进行测量来自适应地设置延迟界限和相关参数(例如α)。可以对调度器所使用的延迟界限进行反复增加或减少，以便将良好用户部分维持在所期望的级别上。在一个实施例中实现了具有用于延迟界限的较低界限的简单一阶循环。

在上文所描述的调度器中，为BE/AF用户定义了比特量度的方法使用了下列计算：

BitMetric＝1/[AvgThroughput-TrgtThroughput]

可以为不同的系统、操作目标和设计执行其它的比特量度定义。

还在表1中分别为1x EV-DO版本0和版本A规范中所定义的两组协议子类型中列出了与每个DRC索引兼容的FL传输格式，所述协议包括在近来贡献中对版本A提议的变化，版本A为DRC索引0x0、0x1和0x2定义了兼容的多用户格式。如在版本A规范中那样，由三个量(分组大小、跨度、前导长度)来代表传输格式。“分组大小”是传输格式所传送的包括循环冗余码(CRC)和尾部在内的比特的数目。“跨度”是传输实例将要在前向链路上占用的时隙的标称(例如：最大)数目。“前导长度”是前导码片的总数目。如在1x EV-DO规范的版本A中那样，以粗体指示用于每个DRC的“规范”传输格式。注意，版本0仅定义了单用户传输格式，而版本A中的某些子类型同时定义了单用户和多用户格式。另外，在版本A中，可以为每个DRC标志定义多个传输格式。AT试图在这些格式中的每个上对分组进行接收。通过它们的唯一的MAC索引对多用户格式进行区分，即用于每个多用户格式的前导使用不同的沃尔什覆盖。单用户格式都使用分配给用户的MAC索引。

表1：用于1xEV-DO版本0和版本A的传输格式

DRC索引	速率( Kbps)	版本0传输格式	版本A单用户传输格式	版本A多用户传输格式
					0x0	0.0	无	(128，16，1024)，(256，16，1024)，(512，16，1024)，(1024，16，1024)	无
0x1	38.4	(1024，16，1024)	(128，16，l024)，(256，16，1024)，(512，16，1024)，(1024，16，1024)	无
					0x2	76.8	(1024，8，512)	(128，8，512)，(256，8，512)，(512，8，512)，(1024，8，512)	无
0x3	153.6	(1024，4，256)	(128，4，256)，(256，4，256)，(512，4，256)，(1024，4，256)	(128，4，256)，(256，4，256)，(5l2，4，256)，(1024，4，256)
					0x4	307.2	(1024，2，128)	(128，2，128)，(256，2，128)，(5l2，2，l28)，(1024，2，128)	(128，4，256)，(256，4，256)，(512，4，256)，(1024，4，256)
0x5	307.2	(2048，4，128)	(512，4，128)，(1024，4，128)，(2048，4，128)	(128，4，256)，(256，4，256)，(512，4，256)，(1024，4，256)，(2048，4，128)
					0x6	614.4	(1024，1，64)	(128，1，64)，(256，1，64)，(512，1，64)，(1024，1，64)	(128，4，256)，(256，4，256)，(512，4，256)，(1024，4，256)
0x7	614.4	(2048，2，64)	(512，2，64)，(1024，2，64)，(2048，2，64)	(128，4，256)，(256，4，256)，(512，4，256)，(1024，4，256)，(2048，4，128)
					0x8	921.6	(3072，2，64)	(1024，2，64)，(3072，2，64)	(128，4，256)，(256，4，256)，(512，4，256)，(1024，4，256)，

				(2048，4，128)，(3072，2，64)
					0x9	1228.8	(2048，1，64)	(512，1，64)，(1024，1，64)，(2048，1，64)	(128，4，256)，(256，4，256)，(512，4，256)，(1024，4，256)，(2048，4，128)
0xA	1228.8	(4096，2，64)	(4096，2，64)	(128，4，256)，(256，4，256)，(512，4，256)，(1024，4，256)，(2048，4，128)，(3072，2，64)，(4096，2，64)
					0xB	1843.2	(3072，1，64)	(1024，1，64)，(3072，1，64)	(128，4，256)，(256，4，256)，(512，4，256)，(1024，4，256)，(2048，4，128)，(3072，2，64)
0xC	2457.6	(4096，1，64)	(4096，1，64)	(128，4，256)，(256，4，256)，(512，4，256)，(1024，4，256)，(2048，4，128)，(3072，2，64)，(4096，2，64)
					0xD	1536.0	None	(5120，2，64)	(128，4，256)，(256，4，256)，(512，4，256)，(1024，4，256)，(2048，4，128)，(3072，2，64)，(4096，2，64)，(5120，2，64)
0xE	3072.0	None	(5120，1，64)	(128，4，256)，(256，4，256)，(512，4，256)，(1024，4，256)，(2048，4，128)，(3072，2，64)，(4096，2，64)，(5120，2，64)

作为提示，传输实例指具有特定比特组的传输格式，该特定比特组来自将要通过该传输格式传送的、所选出的一个或多个队列。候选传输实例指将要通过调度器算法评估而可能传输的传输实例。将多用户传输格式(1024，4，256)、(2048，4，128)、(3072，2，64)、(4096，2，64)和(5120，2，64)称为规范多用户传输格式。将多用户传输格式(128，4，256)、(256，4，256)和(512，4，256)称为“非规范多用户格式”。简单地通过将相应的被定义格式的跨度设置为小于标称值的值来获得所得到的传输格式，就好像通过提前终止从所定义的格式中获得一样。总之，传输格式和实例可以是规范的或者非规范的；可以是单用户的或者多用户的；并且可以是所定义的或者所得到的。术语“标称时隙数目”将被用于指用于所定义传输格式的最大时隙数目以及用于所得到的传输格式的重新定义的最大时隙数目。

下文对调度装置和方法的描述考虑了基于八位字节的调度，其中，可以以任意数量(以八位字节为单位)提供在多个队列中未决的八位字节。典型地，将每个流存储为至少一个数据队列。因此，每个队列具有与其相关的特定QoS需求。以八位字节的形式将数据存储在每个队列中。可以进行调度，其中将少于全八位字节数据放入传输实例或者物理层分组中，在FL上进行传输。

注意，某些应用可能需要基于帧的调度，其中，在物理层分组内，对流的(被封装的)数据报进行无分段服务。还可以将基于八位字节的调度装置和方法延伸到基于帧的调度。

同时注意，准入控制与调度密切相关，其中，基于当前系统负载、并且通过对是否可以对输入流满意地进行服务(即符合QoS目标)而不对已经被准入的流造成不可接受的降级进行预测，准入控制可用于允许/拒绝输入流。

如在这里所使用的，“流”指发向给定用户的数据流。流的源可以是一个或多个用户应用，其包括但是不限制于在许多其它应用中的文件下载(ftp)、网上冲浪(http)、在线游戏、或者VoIP。还可以通过通信系统自身产生诸如信令流的流，其中，提供信令流以便保持系统可操作同时恰当地维持用户对话。流的另一个例子是由测试应用产生的数据流，其中，使用数据流对通信系统的至少一部分进行测试。

换言之，流是数据流，并且是到至少一个用户的通信的组成部分。存在多种应用流，每个具有特定的QoS需求和容限。每个流可以具有诸如目标吞吐量和延迟界限的不同QoS需求组。在下文专门对该需求的例子进行了讨论。

用户可以具有多个具有不同QoS需求的并行流。可以通过诸如VoIP、ftp、信令等的单一应用产生每个流；或者可以通过多个应用产生每个流，其中，通过基站控制器(BSC)将多个应用聚集在单一流中。如果BSC以该方式对流进行聚集，那么对调度器来说，被聚集的流看起来可以是具有良好定义的QoS需求的单一流。调度器不能够对由不同应用生成的、但是被包含在一个聚集流中的数据之进行区分。在下文提出了可以由调度器执行的另一种类型的聚集。

每个流具有至少一个为第一时间传输(被称为FTx)保持数据的队列，并且可以具有用于重传的的额外队列，诸如无线链路协议(RLP)重传队列(流x的RTx队列)和/或MAC层重传队列(被延迟的自动重复请求(ARQ)、或被延迟的ARQ(DARQ)队列)。在一个实施例中，每个队列中的每个八位字节具有良好定义的时间标志，调度器可以通过该时间标志来确定由该八位字节导致的当前延迟。将时间标志分配给诸如(被封装的)数据报的数据突发，这意味着数据突发的每个八位字节具有相同的时间标志。各个数据报可以传送多个应用级别帧，可以由不同时刻处的应用生成该多个应用级别帧。假定应用帧时间标志对于调度器是未知的。由于用户已经在可以通过接收端应用对由其传送的任何应用帧进行解析之前成功地对全部数据报进行了接收，所以该假定是恰当的。

在根据一个实施例的调度器设计中，考虑三个主要的QoS类别。尽力而为(BE)如术语表中所定义的，并且特别指这种流：典型地，其可以提供相对较高的端对端延迟，但是要求低误比特率(BER)。虽然不存在最小吞吐量需求，但是将要被发送的数据大小可以很高。可以被考虑为BE的流的例子包括文件下载(ftp)和网上冲浪(http)。保障转发(AF)是指这种流：通常，其在容忍一定级别的延迟方面类似于BE流；然而，典型地，由于AF流具有最小平均吞吐量，所以其与BE流不同。将应用分类为AF流的例子是由视频会议应用生成的视频流。快速转发(EF)是指这种流：典型地但不是必须地，这种流具有低吞吐量需求并且具有严格的端对端延迟需求。可靠性需求可能不像对于BE流那样严格；丢失诸如1-2％的一小部分应用数据是可以接受的。将应用分类为EF流的例子包括但是不被限制于VoIP和在线游戏。

关于调度装置和方法，BE和AF流之间的不同在于最小吞吐量需求，其对于BE流为零。其它方面，这两个QoS类别是类似的。为了进一步对特定流进行区分，考虑EF类别，其可以包括多种不同类型的应用。在EF类别的流中，可以存在具有不同优先级的流。作为例子，可以认为诸如VoIP和视频会议应用音频部分的应用比视频会议应用视频部分的应用具有更高的优先级。可以认为在线游戏比音频和视频应用具有更低的优先级。

除由用户应用生成的流之外，支持IS-856的系统具有内部生成的流，诸如维持系统运行所需的信令流，并且该系统具有通过测试应用生成的用于对系统进行测试的流。

可以以用变量所描述的多种因素来规定典型的QoS需求，其包括但是不限制于延迟界限、目标吞吐量、可靠性、抖动等。

通过用称为“DelayBound”的变量来识别延迟界限，该“DelayBound”是为每个流指定的参数，其指在其中成功地将数据报传递给用户的最大延迟。相对于数据报的时间标志对延迟界限进行测量，在本实施例中，该数据报的时间标志是八位字节。注意，这与端对端延迟界限不同，端对端延迟界限包括延迟预算成分而不是FL延迟。在一个实施例中，一旦到达了数据报的延迟界限，那么就将数据报从队列中去掉。换言之，如果不能在指定的延迟界限中发送数据报，那么就丢弃该数据报。

通过称为“TargetThroughput”的变量来识别目标吞吐量，其是另一个被指定的QoS参数。目标吞吐量指用于流的最小所需平均吞吐量。可以通过具有恰当时间常数的一阶无限脉冲响应(IIR)滤波器来定义吞吐量的平均。在一个实施例中，将时间常数设置为1毫秒。

第三个QoS需求可以是可靠性。典型地，系统的物理层提供了1％的误分组率(PER)，该1％的PER对于需要特别低错误率的诸如文件下载的应用来说可能是不足的。因此，为了进一步减少在空中的损失，可以利用重传机制。典型的重传机制是分别诸如RTx和DARQ队列的RLP重传和MAC层重传。在此之外，为了为应用提供更多的可靠性，可以将传输控制协议(TCP)用作传输层协议。

在一个实施例中，将调度器设计为对系统容量进行最大化，同时提供流间的公平并且符合用于每个流的某些优先级和QoS需求。容量和公平的概念取决于各个流的QoS需求。对于BE流，可以将容量定义为由扇区发送的总BE吞吐量。对于特定类型的EF流，可以将容量定义为可以支持的、同时符合其QoS需求的用户的数目。在EF流调度的一个例子中，系统对VoIP容量进行定义，使得将VoIP用户的数目选择为该数目：平均起来，其将使得95％的用户，成功地对98％的应用数据帧(或八位字节)进行接收。在一个例子中，由在所指定的延迟界限内被接收的帧以及无传输错误来确定成功。还可以使用可选的成功标准。为了获得流间的公平，可以使用正比公平(PF)标准来调度BE流，并且根据优先级标准对EF流进行调度。以这种方式，随着系统负载增加，BE流遭遇均匀的降级，即无差别地对BE流进行降级。

对于EF流，期望随着系统负载增加或者拥塞发生在用户间具有不均匀的降级。首先被认为具有最低优先级的那些EF流感受到降级。在具有类似QoS需求和相同优先级级别的EF流之间，降级首先影响具有最差信道状况的用户的流。采用该方法，随着系统拥塞的增加，EF流的最大可能数目可以满足它们的QoS需求。通常，该方法导致在用户信道状况及其EF流的延迟统计之间的近似反比关系。将该属性称为“延迟公平”。

“传输格式”是三个一组的形式(分组大小，跨度，前导长度)，其描述了FL分组的某些参数。分组大小指以比特为单位的物理层有效负载大小，跨度指可以对具有该格式的分组进行发送的最大时隙数目，并且前导长度指以码片为单位的前导持续时间。

在支持IS-856的系统中，使用链路自适应来为每个用户确定FL传输数据速率。每个AT发送数据请求，该数据请求指示AT可以对数据进行接收的最大数据速率。该数据请求被称为数据速率控制(DRC)消息。DRC消息格式使用多个DRC索引，每个DRC索引指定一种传输格式。AT在DRC信道上发送DRC消息。除了IS-856版本0中的NULL DRC之外，对于每个有效的DRC索引，存在一个或多个单用户以及零个或多个多用户传输格式，可以在FL上提供这些传输格式以便将数据传送给用户。表1如IS-856中所定义的那样对DRC索引进行了详细描述。另外，表1还包括对应于每个DRC索引的兼容传输格式。

在1x EV-DO版本A规范中，对于每个DRC索引，将兼容单用户传输格式之一定义为用于该DRC的规范格式。注意，如在这里所使用的，DRC对应于由AT所请求的并且由DRC索引所识别的特定格式。通常，如果AT成功地对使用对应于给定DRC的规范格式发送的分组进行解码，那么该AT将也可能成功地对以任何兼容非规范单用户格式或者任何兼容多用户格式发送的分组进行解码。这种情况的例外是DRC索引0x0、0x1和0x2。注意，由于与给定DRC兼容的某些多用户格式可以具有比规范格式更大的前导长度，所以这些格式不一定必然导致数据处理增益。

对于任意DRC，除了与DRC索引0x0兼容的所有格式以及与DRC索引0x1和0x2兼容的多用户格式之外，典型地，非规范格式的有效负载大小小于或等于规范格式的有效负载大小。另外，典型地，非规范格式的跨度大于或等于规范格式的跨度。如果以任意格式对用户进行服务，其中，已经从该用户接收了DRC索引0x0(例如：NULL速率请求)，那么，通常不存在对分组进行可靠接收的保证。同样，对于DRC索引0x1和0x2，由于这些格式的有效负载大小和跨度不满足该属性，所以兼容多用户传输格式不可以确保充分可靠的接收。

在一个实施例中，调度器不可以利用多用户分组来对多个用户进行服务，其中，从该多个用户所接收的DRC是0x0、0x1或0x2。同样，可以将到用户的服务限制在某些情况，其中，从该用户接收了NULL DRC(0x0)。可以将这些状况设计入系统中。

对于多用户传输格式，如果给定的DRC与给定的多用户格式兼容，那么同一DRC与具有较低数据速率的所有多用户格式兼容。

“传输实例”指传输格式和可以由该格式的分组传送的八位字节数据的识别的组合。例如，用于用户的MAC索引组和指向相应队列的指针组可以定义传输实例，其中，分组将八位字节数据传送到所述用户，所述指针组精确地指示将要在分组中传送哪些八位字节。

调度器可以生成假定传输实例组，然后选择这些实例之一用于在FL上进行传输。在该文档中使用的、用于指这些假定传输实例中的任意一个的术语是“候选传输实例”。

在合并自适应延迟管理的调度器的一个实施例中，调度器使用各种量度，并且各种量度包括：1)比特填充量度；2)比特量度；以及3)分组量度。使用比特量度来选择符合合并入当前传输实例条件的队列。比特填充量度确定了在各个队列中是未决的比特(或者八位字节)被包括在给定候选传输实例中的次序。一旦创建了候选传输实例，就为候选传输实例计算分组量度。然后，使用分组量度从一组以类似方式创建的候选传输实例中选择胜出的传输实例。通过简单地对所有包括在候选传输实例中的八位字节的比特量度进行求和，并且用候选传输实例的传输格式跨度去除该和，来确定候选传输实例的分组量度：

$\mathrm{PacketMetric}\left[k\right]=\frac{1}{\mathrm{Span}\left[k\right]}\underset{i\∈P\left[k\right]}{\mathrm{\Σ}}\mathrm{BitMetric}\left[i\right]$

其中，k代表在可选的候选传输实例组内特定候选传输实例的索引，Span[k]代表为相应的传输格式定义的跨度，P[k]代表包括在候选传输实例中的八位字节组，并且BitMetric[i]代表包括在候选实例中的第i个八位字节的比特量度。

因此，如果实际上在FL上对候选传输实例进行服务，那么可以将分组量度解释为对“比特量度的瞬时吞吐量”的估计。

通常，如果八位字节i的比特填充量度大于另一个八位字节j的比特填充量度，那么可以将八位字节i的比特量度设置为大于或等于八位字节j的比特量度。在该情况下，八位字节可以来自不同的队列。类似地，如果八位字节i的比特量度大于另一个八位字节j的比特量度，那么应该将八位字节i的比特填充量度设置为大于或等于八位字节j的比特填充量度，即：

BitMetric[i]＞BitMetric[j]BitStuffingMetric[i]≥BitStuffingMetric[j]

BitStuffingMetric[i]＞BitStuffingMetric[j]BitMetric[i]≥BitMetric[j]

该通用准则确保被填充入候选传输实例的八位字节至少以与随后被填充的另一个八位字节相同的数量对分组量度做出贡献。

可以将这里所描述的所有量度以及可选量度表示为如下的多项式形式：

量度＝[MC0]+[MC1]x+[MC2]x²+[MC3]x³+[MC4]x⁴+[MC5]x⁵+[MC6]x⁶+[MC7]x⁷其中，量度可以是量度类型中的任意一种，并且MC0、...、MC7代表量度系数。如在多项式代数学中那样对两个量度的加法以及标量对量度的乘法(或除法)进行定义；其中，当对两个量度进行求和时，对两个多项式的相应系数进行求和。当通过标量对量度进行相乘(或相除)时，将每个系数乘以(或除以)相同的标量。这使得能够使用比特量度来计算分组量度，其中，如上文所给定的那样计算比特量度。

在词汇意义中对比较操作符“＞、＞＝、＝＝、＜＝、＜”进行定义，即当对两个量度进行比较时，首先对最高次项的系数进行比较。如果相等，那么对次高次项的系数进行比较，等等。如果两个多项式表示的所有对应系数是相等的，那么两个量度就是相等的。将比较操作符用于对比特填充量度进行比较以及对分组量度进行比较。

比特量度、比特填充和分组量度

对于比特量度和比特填充量度，在任意给定的时间上，相应多项式表示中仅一项是非零的。对于给定八位字节的比特量度和比特填充量度来说，非零项的次数是相同的，通常，将通过对应系数的名称来指该非零项的次数。将MC0、...、MC7称为比特(填充)量度(或相应八位字节)的“优先级状态”。比较操作的定义意味着MC0项对应于最低优先级八位字节，并且MC7项对应于最高优先级八位字节。通过由八位字节导致的当前延迟并且通过使用为该八位字节所属的流定义的已知为“优先级阈值”的有序阈值组来确定八位字节i的比特(填充)量度的优先级状态，其中，由八位字节导致的当前延迟给定为：

CurrentDelay[i]＝CurrentTime-TimeStamp[i]

TimeStamp[i]是为八位字节i恰当定义的时间标志。将由优先级阈值定义的每个时间间隔映射到优先级状态。对于每个流，可以单独地将优先级阈值和映射指定给调度器，所述映射是如此定义的时间间隔到优先级状态的映射。将八位字节的CurrentDelay[i]与这些有序阈值组进行比较，以便确定其所落入的时间间隔。这进而定义了比特(填充)量度的优先级状态。

上述的操作为每个流使用了M个优先级阈值和M+1个优先级状态。在调度器的软件实现的一个实施例中，将M的值设置为2。对于每个流，定义了两个优先级阈值和三个优先级状态。虽然在操作期间，可以通过恰当的DSP驱动器命令来改变这些优先级阈值和优先级状态中的每个，但是典型地，在流的生命周期期间，这些优先级阈值和优先级状态可以保持不变。

对于吞吐量灵敏业务流，将比特量度设置为：

${\mathrm{TS}}_{\mathrm{BM}}=\frac{\mathrm{GoSFactor}\·\mathrm{Thrghpt}2\mathrm{DelayConvFactorBM}}{\max (\mathrm{\ϵ},\mathrm{AvgThroughput}-T\arg \mathrm{etThroughput})}$

并且将比特填充量度设置为：

${\mathrm{TS}}_{\mathrm{BSM}}=\frac{\mathrm{GoSFactor}\·\mathrm{Thrghpt}2\mathrm{DelayConvFactorBSM}}{\max (\mathrm{\ϵ},\mathrm{AvgThroughput}-T\arg \mathrm{etThroughput})}$

其中：

1、GoSFactor是基于每个流定义的参数，其用于提供在流上的服务等级的多个级别。

2、AvgThroughput是流的被滤波的(被平均的)总吞吐量，包括流的FTx、RTx和DARQ队列。具有诸如600个时隙(1秒)的时间常数的一阶无限脉冲响应(IIR)滤波器用于平均。

3、TargetThroughput是基于每个流定义的参数。

4、Thrghpt2DelayConvFactorBM是基于每个流定义的参数。

5、Thrghpt2DelayConvFactorBSM是基于每个流定义的参数。

6、ε代表非常小的正数。

对于延迟灵敏流的比特填充量度，将用于优先级状态的多项式系数设置为如下：

DS_BSM＝AccelerationFactor*CurrentDelay+AccelerationOffset其中，AccelerationFactor是每个流定义的参数。加速因子对延迟界限进行了归一化，对于不同的流，延迟界限可以是不同的。作为例子，考虑两个不同的在线游戏。由于两个应用的不同特征，它们可以具有为调度器指定的不同延迟界限设置，然而，一个游戏不一定必然比另一个应用具有更高的优先级。可能期望调度器以相等的优先级对待两个应用。假定第一个游戏具有300毫秒的延迟界限并且第二个游戏具有150毫秒的延迟界限。那么，由于调度器对其进行丢弃，所以在任何时间上将不存在任何属于第二个游戏的、长于150毫秒的八位字节。然而，可以存在属于第一个游戏的、长于150毫秒的八位字节。如果不存在加速因子，这将导致第一个游戏的八位字节获得在第二个游戏的八位字节之上的优先级。通过将每个应用的加速因子设置为与各自的延迟界限成反比例，调度器可以对该非期望的影响进行规范化。

AccelerationOffset是基于每个流定义的参数。可以将加速偏移量的值设置为可以采用的加速因子的最大值的整数倍。该最大值独立于流，并且可以通过软件实现来确定。作为例子，在两个流中，一个具有零加速偏移量，并且另一个具有正加速偏移量，假定两个流的DRC都与任意给定的候选传输实例的传输格式的DRC一致，则将在前一个流的任意八位字节之前将后一个流的八位字节包括在给定的候选传输实例中。

对于比特量度，将用于优先级状态的多项式系数设置为常数值，如下：

DS_BM＝DSBitMetricValue

其中，DSBitMetricValue是每个流定义的、用于软优先次序区分的参数。另外，当两个应用具有大约相等的优先级、但是具有不同的平均输入吞吐量(例如，从因特网到队列)时，可以将用于每个流的DSBitMetricValue设置为关于该流的典型吞吐量成反比例，以便仅仅通过使更多的数据有效地填充FL分组来避免具有较高吞吐量增益优先级的应用。

基于流类型参数，将每个业务流分类为吞吐量灵敏类型或延迟灵敏类型。那么，将比特量度MCX(其中，X是{0，...，7}中的一个元素)定义如下：

类似地，将比特填充量度定义如下：

在一个实施例中，将调度器至少部分实现为软件执行。根据该实施例，可以通过16个比特的量代表比特填充量度，可以将所述16个比特的量表示为[B15...B0]。三个最高比特确定了优先级状态(例如：“000”映射到MC0并且“111”映射到MC7)。剩余的13个最低比特保持其自身的系数值。采用该表示，可以直接在这些16个比特的量之间进行比特填充量度之间的比较操作。

由于可以从比特填充量度中得到信息，所以没有在软件实现中对比特量度进行明确地表示。比特量度的优先级状态与比特填充量度的优先级状态是相同的。

如在上文所描述的，通过应用下列公式来计算候选传输实例的分组量度：

$\mathrm{packetMetric}\left[k\right]=\frac{1}{\mathrm{Span}\left[k\right]}\underset{i\∈P\left[k\right]}{\mathrm{\Σ}}\mathrm{BitMetric}\left[i\right]$

注意，虽然八位字节的比特量度中仅有一项可以是非零的，但是通常，所得分组量度的系数可以是非零的。

许多DRC与具有较小有效负载大小的非规范单用户格式是兼容的，因此，不期望将单用户候选转变成多用户格式以获得ARQ增益。

如果在调度器的选择步骤中胜出的候选传输实例是多用户格式，那么在当前实施例(即：使用可以传送被选择的八位字节数据的最低速率格式)中仅支持(1024，4，256)格式到三种格式({128，256，512}，4，256)中任何一种的变换。

上文所给定的对比特和比特填充量度的讨论考虑了将每个队列中的每个八位字节分配给单独量度的一般情况。然后，在每个时隙对量度重新进行计算。可选实施例减少了这种计算的复杂性。假定通过时间标志对队列进行排序，一个实施例基于该流的队列的队列头八位字节之中最早的时间标志，每流计算一个比特(填充)量度。然后，可以将该量度用于流的当前未决的八位字节。这种简化假定量度是八位字节的当前延迟的单调增函数。否则，就存在队列头八位字节可能阻止连续八位字节被服务的风险。采用该简化，也可以将比特填充量度称为流量度。

另外，任何在流的RTx队列中未决的队列头八位字节很可能早于任何可能在FTx和DARQ队列中未决的队列头八位字节。类似地，任何可能在DARQ队列中未决的队列头八位字节很可能早于FTx队列的队列头八位字节。因此，一个实施例使用RTx、DARQ然后FTx队列的固定次序，来寻找第一个非空队列，以确定将要在流的量度计算中使用的时间标志，而不是寻找这三个队列中最早的时间标志。还可以以RTx、DARQ然后FTx的次序对流的队列进行服务。

根据一个实施例，无论何时FL对于新的传输可用时，就进行诸如图10中所说明的调度。注意，具体实现可以在包括非可用时隙在内的每个时隙上执行某些或全部计算。这是因为直到接入网络确定FL对于新的传输可用时，通常没有剩余很多时间进行包括在调度方法中的计算以确定传输实例。

图10中所说明的调度器方法由四个基本步骤组成：1)生成候选传输实例组；2)在该组中选择一个候选传输实例；3)对打包效率进行最大化；以及4)先验或PACK计算。PACK的计算确定了AT成功地对分组进行解码的概率。

再次返回图10，在步骤504处，调度器生成一系列候选传输实例。具有单用户格式的候选单用户传输实例对应于每个可用用户，其中，可用用户是当前没有由于任何原因被协议子类型禁止服务的用户。此外，从用户接收到的DRC是非空(non-NULL)的，否则，用户将商定MAC层协议，该MAC层协议允许一个或多个传输格式依据NULL DRC被服务。如果为从其接收到NULL DRC的用户创建了候选传输实例，就仅允许该候选实例传送属于具有有限延迟界限的流并且仅来自该流的FTx队列的数据。如表1中所详细描述的，候选实例的传输格式是对应于用户DRC的规范格式。

为五种多用户传输格式(1024，4，256)、(2048，4，128)、(3072，2，64)、(4096，2，64)和(5120，2，64)中的任何一种生成候选多用户传输实例。在多用户格式中对那些具有被请求的153.6Kbps或更高速率的用户进行服务。另外，用户的DRC将要与候选传输实例的格式兼容。此外，多用户候选传输实例将满足下列条件中的一个或全部两个，或者否则根据进一步的考虑将其丢弃；其将传送两个或多个用户的数据，或者传送DRC被擦除的至少一个用户的数据。

通过从一个或多个流填充比特生成任何组中的候选传输实例，其中：1)可以仅以来自相同用户的流的比特对单用户格式进行填充；2)以来自具有兼容DRC的用户的流的比特对多用户格式进行填充。

以比特填充量度的降序排列进行比特填充。如上文所提到的，计算的需求可能导致每流计算一个比特填充量度，然后可以将其用于流队列中的当前未决的八位字节。在该情况下，比特填充量度有助于确定首先将要对哪些流进行服务；然而，它不确定将如何对给定流的八位字节进行服务。这假定在流队列中未决的八位字节以时间标志的次序出现，并且以流的八位字节在队列中出现的次序对它们进行服务。这用于FTx队列，但是不一定用于RTx/DARQ队列。

如上文所提到的，每个流可以具有多个队列，一个队列用于第一时间发送的数据(FTx)，并且其他队列用于重传(RTx队列用于RLP重传并且/或者DARQ队列用于MAC层重传)。如果流具有非空RTx和/或DARQ队列，那么基于非空FTx/RTx/DARQ队列中的任何一个之中的最早的队列头时间标志来计算用于流的比特填充量度。仅为流的队列计算一个比特填充量度。还应该基于FTx/RTx/DARQ队列之间的队列头时间标志的递增次序执行来自给定流的比特填充。

可以将流队列的基于时间标志的次序近似为RTx/DARQ/FTx队列的固定次序。

注意，在生成候选传输实例中，不考虑非规范的单用户格式以及传送少于1024个比特的短多用户格式。将在对打包效率进行最大化步骤中考虑这些格式。调度方法寻求减少复杂度并且寻求每分组打包尽可能多的数据。

通过有效地填充短分组，以避免用户具有弱信道状况但是具有用于与传输增益有关的优先级的大量数据的情况。在该阶段中不考虑非规范和短分组的另一个好处包括但不限制于：避免了可能在基于帧的调度中出现的某些量化影响。

在创建多用户候选中，可能采取进一步的预防措施，以便减轻下文所讨论的延续问题的潜在不利影响。一种这样的方法是：避免在第一个多用户分组开始之后的一定数目的时隙(例如：在给定交织上计数的时隙数目)中，在与之前开始和结束的多用户分组相同的交织上对多用户分组服务。可以将该时隙的数目设置为两个多用户分组的跨度的最小值或者可能将其设置为第一个多用户分组的跨度。该方法有助于使用户能够快速变得符合在新的多用户分组中被服务的条件，从而避免了长期的不合格运行。

关于步骤508，在创建了单用户和多用户候选传输实例的列表之后，调度器选择这些候选中的一个(假定上文所生成的列表包含至少一个候选传输实例)。这通过为列表中的每个候选计算分组量度、并且选择具有最大分组量度的候选作为胜出候选来完成。如果出现不分胜负的情况，期望更优先单用户格式而非多用户格式。同样，期望挑选较高速率的多用户格式而非较低速率的多用户格式。

在步骤510中，对胜出候选传输实例的传输格式重新进行考虑，并且可以将其改变为对其打包效率进行最大化，而不改变被选择为由其传送的八位字节数据组。因此，步骤510的完成可以提供ARQ增益。

如果胜出候选传输实例是单用户格式，那么可以将该格式变换为最低速率非规范单用户格式，该最低速率非规范单用户格式与被服务用户的DRC兼容，该DRC可以传送被选择的八位字节数据。其它实施例也可以将单用户传输实例的格式改变为多用户格式。

AT内部的自适应速率控制机制很可能适合于支持单用户分组。许多DRC与具有较小有效负载大小的非规范单用户格式兼容；因此，不期望将单用户候选变换成多用户格式以获得ARQ增益。

虽然可以将多用户格式变换成任何一个较低速率的多用户格式(只要有效负载合适)，但是由于下文所描述的延续问题的潜在不利影响，所以避免该分布广的格式变换是可取的。

参考图12，调度器可以确定时隙的最大数目(例如：小于被选择传输实例的标称跨度)，在该时隙的最大数目之外，虽然可能没有检测到来自在传输实例中被服务的用户的ACK，但是将不再发送传输实例。由于该步骤是可选的，所以可以将其关闭，使得在检测到来自在分组中被服务的用户的ACK之后、或者在对分组的全部跨度进行发送之后，接入网络终止分组传输。

实现该步骤的一种方法是将传输实例的最大时隙数目设置为：

MaxmumSpan＝min(ScheduledTxFormatSpan，max_{i∈ServedUsers}(DRCSpan[i]))

其中，ScheduledTxFormatSpan是被调度的传输格式的跨度，并且DRCSpan[i]是与来自分组中的第i个被服务用户的被解码DRC相应的规范传输格式的跨度。

已经在上文讨论了某些调度器所采用的参数。这里给出在DSP驱动器接口处提供给调度器的参数。全局参数指那些应用于所有流的参数，并且流参数指那些为每个流单独指定的参数：

1、全局参数：

a.FlowTPutFilterTimeConst——定义了用于生成平均吞吐量AvgThroughput变量的一阶IIR滤波器的时间常数，为每个流保持该平均吞吐量AvgThroughput变量。该滤波器每个时隙迭代一次。到滤波器的输入是从在那个时隙开始的分组中的给定流的队列得到服务的八位字节的数目。在没有新分组传输开始的时隙中，以零输入对滤波器进行更新。

b.Thrghpt2DelayConvFactorBM——用于比特量度计算的、吞吐量灵敏量度到延迟灵敏量度的变换因子。

c.Thrghpt2DelayConvFactorBSM——用于比特填充量度计算的、吞吐量灵敏量度到延迟灵敏量度的变换因子。

d.FlowClass——描述了流是吞吐量灵敏类型还是延迟灵敏类型。

e.FlowEligibleForDRCErasureMapping——将要由DRC擦除映射算法所使用。

f.ErasureMapDelayThreshold——将要由DRC擦除映射算法所使用。

2、流参数：

a.UserId，FlowId——提供了用于索引和确定每个流的所有者的方式。

b.QoSMetricState，PriorityThold[2]——这些将比特(填充)量度的优先级状态描述为当前延迟的函数。PriortyThold[]阵列的元素是包含变量DelayThold和QoSMetricState的结构。当流的CurrentDelay小于PriorityThold[0].DelayThold时，将优先级状态设置为QoSMetricState。如果CurrentDelay大于PriorityThold[0].DelayThold但是小于PriorityThold[1].DelayThold，那么将优先级状态设置为PriorityThold[0].QoSMetricState。如果CurrentDelay大于PriorityThold[1].DelayThold，那么将优先级状态设置为PriorityThold[1].QoSMetricState。对应于优先级状态{MC0，...，MC7}，QoSMetricState变量分别取{0，...，7}值。

c.AccelerationFactor。

d.AccelerationOffset。

e.DelayBound——0代表无限(即在对八位字节进行服务之前永不丢弃它)，否则，其代表相对于给定八位字节的时间标志的延迟量，在其后将八位字节从队列中丢弃。

f.TargetThroughput——在吞吐量灵敏流的比特(填充)量度中使用的参数。

g.FlowAggregateIndex——调度器对FlowAggregateIndex设置为0的流不进行聚集。否则，在调度器处对具有相同(非零)FlowAggregateIndex值的流进行聚集。

FlowAggregateIndex的范围被限制于一个用户，即可以为另一个用户的流重新使用相同的索引而无混淆。

h.IntraFlowPriority——以IntraFlowPriority的次序对聚集流(通过调度器)中有贡献的流进行服务。在具有相同IntraFlowPriority的有贡献的流之间，通过有贡献流的时间标志来确定次序。

i.GoSFactor——用于在流之间提供服务等级的级别。

j.DSBitMetricValue—在MCX的优先级状态中的比特量度系数的值。

注意，在DSP驱动器接口中，没有将流指定为BE、AF、EF，或者没有通过任何其它高级别描述符对流进行指定。而是，DSP驱动器接口为所有的流使用统一并且低级别的描述。在诸如在BSC处的较高级别上，将流的诸如QoS需求和BE/EF/AF分类的高级别描述映射到在DSP驱动接口中为每个流定义的基本参数。通过充分的仿真和测试为可能的流类型生成该映射表。

下面是对各种参数的使用进行说明的例子。对于BE流，可以使用下列参数：

a.QoSMetricState＝0(MC0)

b.PriorityThold[].QoSMetricState＝{任意，任意}

c.PriorityThold[].DelayThold＝{0，0}(无限)

d.DelayBound＝0(无限)

e.TargetThroughput＝0

f.FlowAggregateIndex＝l(对一个用户的所有BE流进行聚集)

g.Thrghpt2DelayConvFactorBM＝16

h.Thrghpt2DelayConvFactorBSM＝128

i.FlowClass＝ThrputSensitive

j.FlowEligibleForDRCErasureMapping＝0

k.ErasureMapDelayThreshold＝0{无限}

对于AF流，可以使用下列参数：

a.QoSMetricState＝0(MC0)

b.PriorityThold[].QoSMetricState＝{任意，任意}

c.PriorityThold[].DelayThold＝{0，0}(无限)

d.DelayBound＝0(无限)

e.TargetThroughput＝A正值

f.FlowAggregateIndex＝0(无聚集)

g.Thrghpt2DelayConvFactorBM＝16

h.Thrghpt2DelayConvFactorBSM＝128

i.FlowClass＝ThrputSensitive

j.FlowEligibleForDRCErasureMapping＝0

l.ErasureMapDelayThreshold＝0{无限}

对于EF流，可以使用下列参数：

a.QoSMetricState＝0(MC0)

b.PriorityThold[].QoSMetricState＝{2，3}

c.PriorityThold[].DelayThold＝{0.25*DelayBound，

0.5*DelayBound}

d.DelayBound＝取决于应用

e.TargetThroughput＝0

f.FlowAggregateIndex＝0(无聚集)

g.Thrghpt2DelayConvFactorBM＝1

h.Thrghpt2DelayConvFactorBSM＝1

i.FlowClass＝DelaySensitive

j.FlowEligibleForDRCErasureMapping＝1

k.ErasureMapDelayThreshold＝0.25*DelayBound将信令流提供如下：

a.QoSMetricState＝7(MC7，最高优先级)

b.PriorityThold[].QoSMetricState＝{7，7}

c.PriorityThold[].DelayThold＝{0，0}(无限)

d.DelayBound＝0(无限)

e.TargetThroughput＝0

f.AggregateIndex＝0(无聚集)

g.Thrghpt2DelayConvFactorBM＝1

h.Thrghpt2DelayConvFactorBSM＝1

i.FlowClass＝DelaySensitive

j.FlowEligibleForDRCErasureMapping＝1

k.ErasureMapDelayIhreshold＝0.25*DelayBound

通过使用下列参数的恰当组合可以对BE/AF流区分优先次序：

1、MC0，...，MC7状态允许严格的优先次序区分。

2、GoSFactor用于软优先次序区分。

3、典型地，TargetThroughput用于需要某一最小吞吐量的AF流。

通过使用下列参数的恰当组合可以进一步对EF流区分优先次序：

1、MC0，...，MC7状态允许严格的优先次序区分。

2、AccelerationOffset在具有相同优先级状态的八位字节之间进行比特填充期间提供了优先次序区分，但是不直接影响最后的分组选择(这是由于该后一步骤使用比特量度计算分组量度，其不取决于AccelerationOffset)。当属于相同用户或两个不同用户的两个流为了被包括在相同的候选传输实例中进行竞争时，具有较大AccelerationOffset的流获得优先级。

3、DSBitMetricValue影响了比特量度，因此它对分组量度具有直接的影响。该参数也可以用于软优先次序区分。当前，未执行该参数。

DSP驱动器接口提供了在调度器处对流进行聚集的灵活方法。注意，由调度器进行的聚集与可以由BSC进行的聚集是不同的。当BSC对一组流进行聚集时，对调度器而言，该聚集看起来是单一流，并且调度器对用于该流的单组参数进行接收。调度器不能单独区分有贡献的流。当在调度器处完成聚集时，调度器将自然地知道有贡献的流。

AvgThroughput变量包括聚集的总吞吐量。在DSP驱动器接口上，把为聚集做贡献的流指定的诸如DelayBound的某些参数设置为相同的值。对于所有有贡献的流设置为相同的变量的列表为：

a.UserID

b.AggregateIndex

c.QoSMetricState

d.PriorityThold[2]

e.AccelerationFactor

f.AccelerationOffset

g.DelayBound

h.TargetThroughput

i.GoSFactor

j.DSBitMetricValue

可以设置为不同的参数是IntraFlowPriority，并且将要设置为不同的参数是FlowID。

在一个实施例中，为聚集流分配单一比特(填充)量度。该量度基于被聚集流中有贡献的流之中最早的时间标志。基于有贡献流的FTx/RTx/DARQ队列的队列头时间标志计算有贡献流的时间标志。然而，当为比特填充选择流时，首先通过分配给每个有贡献流的IntraFlowPriority参数、其次通过有贡献流的时间标志来确定对有贡献流进行服务的次序。通过将IntraFlowPriority参数设置为相同值，可以严格地基于有贡献流的时间标志得到有贡献流的选择次序。IntraFlowPriority参数主要用于BE流。

如在上文所讨论的，每个流具有FTx队列，并且可以具有RTx和/或DARQ队列。在软件实现中，为每个流计算单一比特填充量度。该量度应用于FTx队列中的八位字节以及RTx和DARQ队列中的八位字节。如果选择流对其进行服务，那么也以所确定的次序对各个队列进行服务。

一个软件实施例提供了如果RTx和/或DARQ队列是非空时就增加流的优先级的能力。这通过简单地修改式(3.3-2)中所给定的MetricTS值来实现：

${\mathrm{Metric}}_{\mathrm{TS}}=\frac{\mathrm{GoSFactor}*\mathrm{RetransmissionPriorityFactor}}{\max (\mathrm{\ϵ},\mathrm{AvgThroughput}-T\arg \mathrm{etThroughput})}$

如果RTx和DARQ队列都是空的，那么因子RetransmissionPriorityFactor取值1。如果RTx队列为空但是DARQ队列包含数据，那么它取另一个值。并且，如果RTx队列为非空，那么它取再另一个值。

在1x EV-DO规范的版本A中，某些协议子类型将NULL DRC定义为与一组单用户和多用户传输格式兼容。同样，在该规范的版本0中，为某些协议子类型定义了配置属性，该协议子类型能够使接入网络以(1024，16，1024)单用户传输格式对从其接收到NULL DRC的用户进行服务。

在任何一种情况中，调度器可以创建候选传输实例，该候选传输实例包含用于从其接收到NULL DRC的用户的数据。可以将这称为NULL到速率变换。调度器在NULL到速率变换上施加下列限制：

a.允许对具有有限DelayBound的流进行服务

b.不能对RTx/DARQ队列进行服务

除了这些限制之外，调度器不对从用户接收到的DRC是0x0(即：NULL DRC)还是0x1(即：38.4Kbps)进行区分，在版本A的某些协议子类型中，将0x0和0x1都定义为与相同的传输格式兼容。特定协议子类型定义再次参考表1。

当从用户接收到NULL DRC时，不保证用户将对被服务的分组成功地进行解码。进一步的改进可以包括：实际监测是否用户已经发送了NULL DRC，并且然后在分组中服务的实际上是相当成功的解码。取决于成功的统计，可以为流开/关该变换。一个实施例将为发送NULL DRC的用户创建的候选传输实例按级别分类为低于为发送0x1 DRC的用户创建的候选传输实例。

可以在软件实现中进行某些合理的近似，以便有助于创建候选多用户实例，该候选多用户实例包含用于吞吐量灵敏流的数据。

关于调度器定时，将时隙内的时间线分为两部分：第一个部分是非临界段，并且后一部分是临界段。在临界段期间，用户的DRC值变得可用。然而，临界段不能提供充足的处理器循环以实现在负载最差情况下调度器中包括的计算。因此，可以将这些计算中的某些授权给非临界段。由于在非临界段期间，某些用户的DRC值可能是未知的，所以软件实现使用之前时隙的DRC值，以便构造候选传输实例并且选择胜出的候选。某些用户的DRC值可以发生改变，并且在临界段期间，胜出的候选可以变得无效。为了克服该问题，在非临界段期间选择多于一个强壮的候选。当在临界段中接收到实际的DRC值时，对该被减少的候选组进行重新评估。被减少的候选实例组可以包含：

a.少数(例如：5个)单用户候选

b.一个具有少数空闲用户的多用户候选(如果任意一个被创建)，

其中，如果在该候选中被服务的某些用户变得不兼容，那么可以在该候选中对这少数空闲用户进行服务。

在1x EV-DO版本0中，当DRC信息被擦除时，AN不将分组调度到AT。当AN正在对具有诸如尽力而为业务的非延迟灵敏应用的多个AT进行服务时，可以容忍相对较大的DRC擦除速率而不丢失系统容量(例如：当由于多用户分集时)。当DRC擦除速率过高时，可以由AN将DRC锁定比特设置为零，然后AT可以选择切换到另一个扇区或者切换到固定速率模式。然而，DRC锁定比特生成方法具有内置的延迟以便防止不必要的切换，该延迟至少部分由于滤波。因此，相对较长的DRC擦除行程长度仍可以出现在反向链路上。对于诸如EF业务的延迟灵敏应用，这些擦除可以导致不可接受的服务中断量。DRC擦除映射算法寻求对FL上的服务中断进行最小化。

在两个步骤中对基线算法进行了描述。第一个步骤解释了在DRC擦除映射上的判决。第二个步骤描述了对1x EV-DO版本A的FL调度器的修改。图14描述了由AN在每个时隙间隔为每个AT运行的DRC擦除映射算法，其中，每个AT在可变速率模式中。对于每个AT，在具有由BSC创建的活动队列的小区的每个扇区中为该用户运行该算法。为简便起见，将算法描述为在每个时隙时间间隔上运行，但是仅在每个DRC_Length时间间隔上对参数进行更新。

该算法的主要输出是Erasure_Mapped_flag，其为调度器指示进行了DRC擦除映射并且可以为AT进行有限的FL调度。

DRC_index_store用于存储最新有效的、即被成功解码的DRC索引。Eras_Count用于计算DRC擦除的运行长度。只有当擦除行程长度大于Max_Ers_Len时，才进行DRC擦除映射。该阈值确保仅当服务中断概率相对较高时，进行DRC擦除映射。然而，当相应的FL分组延迟很高时，可以将分组调度到AT。这样，Max_Ers_Len不会太高。对于诸如VoIP的EF流，Max_Ers_Len的合理设置可以在0到16个时隙的范围内。

如图14中所说明的，方法700首先检查是否在判决菱形702处对DRC进行擦除。如果对DRC进行了擦除，就在步骤704处对Eras_Cnt进行递增。随后，在步骤706处将Eras_Cnt与最大值Max_Ers_Len进行比较。如果Eras_Cnt大于Max_Ers_Len，那么就将Erasure_Mapped_flag设置为1，否则就在步骤712处将Erasure_Mapped_flag清空，即设置为0。如果没有在判决菱形702处对DRC进行擦除，那么就在步骤708处将Erasure_Mapped_flag设置为0，将Eras_Cnt设置为0，并且将DRC_Index_Store设置为DRC_Index。处理继续进行到步骤712，其中，将Erasure_Mapped_flag设置为0。

可以对上文所描述的FL调度器进行修改，以便与DRC擦除映射算法一起工作。对于每个AT的每个不同的数据流，如果：

(ErasureMappedFlag＝＝1&&FlowEligibleForDRCErasMapping＝＝1

        &&HeadofQueueDelay≥ErasureMapDelayThreshold)

那么流就合格用于有限的FL调度，其中，FlowEligibleForDRCErasMapping是为DRC擦除映射指示每个业务流的合格性的参数。作为默认，假定EF流合格用于映射而BE和AF流不合格。

HeadofQueueDelay指示在FL队列前面的分组(即：FTx、RTx或DARQ队列中最早的分组)的“Current_Delay”值。ErasureMapDelayThreshold是特定流的用于擦除映射的最小所需延迟(与“PriorithyThold[i].DelayHold”具有类似的效果)。如果流合格用于有限FL调度，那么就在FL调度器上进行下列修改：

a.流作为用于单用户传输实例的候选不合格

b.流合格用于具有被请求DRC索引DRC_index_mapped的多用户传输实例。

可能将DRC_index_mapped作为擦除长度的函数动态地进行改变。这可以通过使用DRC_index_store和Eras_Count来实现。可以将DRC_index的默认设置映射到0x3。对于FL调度器，DRC索引0x3对应于多用户传输格式(1024，4，256)，可能可以将其变换为格式({128，256，512}，4，256)。所有这些多用户格式与所有DRC索引兼容，所以只要AT具有足够的SINR(独立于实际被请求的DRC索引)，它就应该能够对被映射的DRC进行解码。可选算法可以采用更加保守的方法，随着Eras_Count增加，其将可利用的多用户传输格式限制在较低的数据速率。

注意，可以为VoIP打开DARQ可选项。因此，在AT还没有对在第一次传输尝试中被发送的多用户分组进行解码的情况下，DARQ提供了第二次传输尝试的可能性并且减少了剩余分组的错误率。然而，将DARQ性能与ACK信道性能相联系，当DRC正在擦除中时，ACK信道性能可能不是非常可靠。可以为DARQ对ACK/NAK判决阈值进行最优化，这可能取决于DRC索引或者DRC映射状态。另一个实施例进行DARQ传输尝试，在DRC擦除映射的情况下，该DARQ传输尝试仅与诸如(512，4，1024)或者(256，4，1024)的较低速率多用户分组格式兼容。

可选实施例可以为在这里所给出的调度器提供额外的步骤和装置。例如，典型地，BE/AF流利用优先级状态，其具有比该优先级状态严格较低的优先级。这可能导致在EF用户出现情况下BE/AF吞吐量的降级，EF用户最可能使用较高的优先级状态。在某些情况下，可以通过将BE/AF流的优先级增加到较高的状态来增加BE/AF吞吐量。

根据一个实施例，AvgRequestedRate是用户的滤波后的请求速率，其中，将K个用户配置为系统中的BE用户。如果用户的吞吐量用于其BE流，那么AvgThroughput满足：

$\mathrm{AvgThroughput}<\frac{\mathrm{\&alpha;}}{K}\mathrm{AvgRequestedRate}$

然后，可以将用户用于其BE流的优先级状态提高到较高的优先级状态。可以取决于系统的EF负载选择α值，较小的α用于较高的负载。此外，为了该提高，可以将最小被请求速率需求施加给用户。用于提高BE/AF容量的其它方法是可能的。

上文的方法还暗示流的比特(填充)量度的优先级状态可以不仅仅是队列头延迟的函数，也可以是流的吞吐量的函数。

注意，在延迟灵敏状态中，比特填充量度严格地是延迟的函数，并且没有利用用户的本地信道峰值的机制。这里，可以将延迟灵敏状态中的比特填充量度值修改为读取：

MBS_DS＝AccelerationFactor*[CurrentDelay+κCCI]+AccelerationOffset

其中，信道状况指示符(CCI)从集合{0，1}或者区间[0，1]中取值，可以单独地生成CCI，使得当其取较高值时，其指示与用户的长期信道状况相比相对较好的信道状况。同样，κ是CCI到延迟变换因子。它指示当用户的信道状况相对于其自身的信道统计良好时，流将在延迟方面得到多少提高。

如下给出了一种为二元{0，1}情况生成CCI的简单方法。令RateIndex是以增加速率次序被分配给DRC值的整数，其中，因为DRC值不随数据速率单调递增，所以没有使用DRC值。令AvgRateIndex为用户的平均(滤波后)RateIndex。令CCIThreshold为诸如1.2的参数。那么，如果RateIndex＞CCIThreshold*AvgRateIndex，就可以将CCI的值设置为单位1。否则，将其设置为零。在该例子中，如果对应于被接收DRC的当前RateIndex是平均质量的120％或者更高，那么CCI将指示相对较好的信道状况。

预占指在目的地用户对FL传输进行解码之前将其终止。如果出现非常高优先级数据而FL上的所有四个交织(interlace)被相对较低速率的用户占用，那么就可以使用预占。调度算法目前不提供对正在进行的传输进行预占的方式。其一个原因是除非仔细进行监测，否则不受控制的预占可能导致容量损失。

这里所采用的方法是为了避免可能需要预占的境况。如上文所提到的，一个这种状况是所有四个交织被低速率用户所占用。为了避免这种情况，可以利用简单的方法。一种方法是对于具有16时隙和8时隙跨度的格式，不允许超过固定数目的该格式的同时传输。作为例子，可以将该数目设置为2或3。

一个实施例对用户的解码性能进行监测，所述用户发送NULLDRC并且在分组中被服务。取决于在这些NULL-到-速率情况上所测量到的PER，可能为每个用户打开/关闭NULL-到-速率变换。类似地，如果被收集的统计指示接入终端对这些分组进行解码是充分可靠的，就还可能打开/关闭在对RTx/DARQ队列以及在NULL-到-速率实例中具有无限DelayBound的流的队列进行服务上的限制。

用于吞吐量灵敏流的比特和比特填充量度系数提供了在仅有BE系统中的成比例公平(例如：对于所有的流，TargetThroughput＝0且GoSFactor＝1)，该仅有BE系统中的用户具有大量要接收的数据。可以以类似的方式将量度系数的形式应用到其它调度器。为此目的，可以将用于吞吐量灵敏流的量度系数表示为：

${\mathrm{Metric}}_{\mathrm{TS}}=\frac{1}{f\left(\mathrm{AvgThroughput}\right)h\left(\mathrm{AvgRequestedRate}\right)}$

其中，其中f(.)h(.)是一般函数，并且AvgRequestedRate是用户的平均请求速率。设置f(x)＝x和h(x)＝x，这产生大约相等-GoS的调度器。

如下文所总结的，在1x EV-DO规范的版本A中所定义的增强前向业务信道MAC协议在多用户分组之后对用户进行服务上施加约束。版本A规范声明：如果遇到下列情况，将时隙t定义为较早时隙s的延续：

c.接入终端是分组的潜在目标，该分组的传输在时隙s中开始。

d.时隙t在与时隙s相同的FL交织中，即，t-s＝0(模4)。

e.s＜t＜s+4N，其中，N表示对应于在时隙s期间起作用的DRC值的DRC索引的跨度。

f.在时隙t之前，接入网络还没有接收到用于分组的肯定确认，该分组的传输在时隙s中开始。

如果接入终端是由在时隙s中开始的扇区发送的潜在分组目标，那么接入网络在任意时隙t中将不把新的分组从相同的FL数据源发送到接入终端，其中，时隙t是时隙s的延续。

上文所声明的限制对在多用户分组之后可以对哪些用户进行服务施加了约束。作为例子，如果接入网络将多用户分组提供给一组随后提早终止的用户，那么在被服务分组的延续期间，接入网络不能将任何分组(单用户或多用户)提供给在之前分组中没有被服务但是与其格式兼容的用户。在一种情况下，接入网络对153.6Kbps多用户分组进行服务，具有由该分组传送的数据的用户在少于4个时隙中对分组进行解码。如果接入网络立即在同一个交织上对另一个153.6Kbps多用户分组进行服务，那么将不允许在新的传输中对实际请求了153.6Kbps或者任何具有4个时隙跨度的DRC、但是没有在之前分组中被服务的用户进行服务。因此，在新的传输中，只有那些请求了具有小于4个时隙的跨度的DRC的用户、即典型地在较好信道状况上的用户可以被服务。但是这使得甚至更可能提早对新的分组进行解码。该链可以继续直到耗尽具有较高几何条件用户的队列为止。与此同时，将不对正在请求具有4个时隙跨度的DRC的较低几何条件的用户进行服务。该结果对于较低几何条件用户来说将是过多的延迟，并且对于较高几何条件用户来说将是可能很小的延迟增加。

注意，在上文的描述中所提供的实施例、方面和例子与支持高速分组数据协议的系统相关。为了清楚起见以及对所提出想法的理解，给出了该系统。可选系统可以实现在这里所提出的用于自适应延迟管理和调度的方法和装置。

这样，已经描述了用于在通信系统中进行传输调度的新颖和改进的方法和装置。本领域的技术人员将理解：通过电压、电流、电磁波、电磁场或粒子、光场或粒子、或者其任意组合方便地表示可以在贯穿上文的描述中被参考的数据、指令、命令、信息、信号、比特、符号以及码片。本领域的技术人员还将意识到：可以以电子硬件、计算机软件或者其组合来实现结合这里所公开的实施例描述的各种示例性逻辑方框、模块、电路和算法步骤。通常，按照它们的功能对各种示例性部件、方框、模块、电路和步骤进行描述。将功能实现为硬件还是软件取决于特定的应用以及施加在整个系统上的设计约束。熟练的技术人员认识到在这些境况下硬件和软件的可交换性，并且认识到如果为每个特定的应用最好地实现所描述的功能。作为例子，可以以数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其它可编程逻辑器件、分立门或晶体管逻辑、诸如寄存器和FIFO的分立硬件部件、执行一组固件指令的处理器、任意常规可编程软件模块和处理器、或者设计为实现这里所描述的功能的任意组合来实现或执行结合这里所公开的实施例描述的各种示例性逻辑方框、模块、电路和算法步骤。方便地，处理器可以是微处理器，但是可替换地，处理器可以是任何常规处理器、控制器、微控制器、可编程逻辑器件、逻辑元件阵列、或者状态机。软件模块可以驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM、或者本领域中已知的任何其它形式的存储介质中。有利地，将示例性处理器连接到存储介质，以便从存储介质读取信息并且将信息写入存储介质。可替换地，可以将存储介质集成到处理器。处理器和存储介质可以驻留在ASIC中。ASIC可以驻留在电话或其它用户终端中。可替换地，处理器和存储介质可以驻留在电话或其它用户终端中。可以将处理器实现为DSP和微处理器的组合，或者将其实现为与DSP核相关联的两个微处理器，等等。

这样，已经表示和描述了本发明的优选实施例。然而，对本领域的一名普通技术人员来说，可以在不脱离本发明的精神或范围的情况下对这里所公开的实施例进行许多变更，这将是显而易见的。因此，除了与下列权利要求一致之外，本发明不受限制。

Claims (4)

1、一种用于在无线通信系统中对传输实例进行调度的方法，包括：

接收来自多个移动用户的信道状况指示符，其中，所述信道状况指示符对应于前向链路通信；

为所述多个移动用户确定延迟标准；以及

为所述多个移动用户确定传输调度，其中，所述传输调度是所述延迟标准的函数。

2、一种用于在无线通信系统中对传输实例进行调度的方法，包括：

对多个传输队列进行评估，以识别与每个传输队列相关联的应用流的延迟灵敏度和吞吐量灵敏度；

从所述多个传输队列中生成候选传输实例组；

从所述组中选择一个候选传输实例；以及

准备所述选择的候选传输实例以用于传输。

3、如权利要求2所述的方法，其中，生成所述候选传输实例组包括：

为每个队列生成比特量度；以及

为每个队列生成比特填充量度。

4、如权利要求3所述的方法，其中，选择一个候选传输实例包括：

生成分组量度以作为所述比特量度的函数；以及

将所述组中的候选传输实例的所述分组量度进行比较。

Images