专利名称：用于无线网络的服务质量调度器的制作方法
技术领域：
本发明一般涉及通信，尤其涉及用于无线网络的服务质量调度。
背景技术：
无线通信系统广泛地用于提供各种类型的通信，如语音和数据通信。典型的无线数据系统、或网络，提供对一个或多个共享资源的多用户接入。系统可以采样多种多址技术，例如频分复用(FDM)、时分复用(TDM)、码分复用(CDM)及其它技术等。
示例性的无线网络包括基于蜂窝的数据系统。若干例子如下(1)“TIA/EIA-95-B Mobile Station-Base Station Compatibility Standard forDual-Mode Wideband Spread Spectrum Cellular System”(IS-95标准)，(2)名为“第三代合作伙伴计划”(3GPP)的组织提供的标准，收录于包括文件号为3G TS 25.211，3G TS 25.212，3G TS 25.213和3GTS 25.214的一组文件中(W-CDMA标准)，(3)名为“第三代合作伙伴计划第二组”(3GPP2)的组织提供的标准，收录于“TR-45.5Physical Layer Standard for cdma2000 Spread Spectrum Systems”(IS-2000标准)中，以及(4)符合TIA/EIA/IS-856标准(IS-856标准)的高数据速率(HDR)系统。
无线系统的其它例子包括无线局域网(WLAN)，如IEEE 802.11标准(即802.11(a)，(b)或(g))。对这些系统的改进可以通过使用包括正交频分复用(OFDM)调制技术的多入多出(MIMO)WLAN来实现。
随着无线系统设计的进步，可以提供更高的数据速率。更高的数据速率提供了高级应用的可能，其中有语音、视频、快速数据传输及其它应用等。然而，不同应用可能对其各自的数据传输有不同的要求。许多类型的数据可能有时延和吞吐量要求，或者需要服务质量(QoS)保证。现有系统可以提供对请求的“竭尽全力”(best effort)调度，但实践中对共享资源的自组织(ad hoc)服务却是标准(即载波检测多址(CSMA))。如果不进行资源管理，系统的容量就会下降，同时系统不能高效运作。此外，如果同等地对待所有业务(包括自组织接入或竭尽全力服务)，有些应用会受到限制或者完全不能工作(例如突发的、相对低时延的视频流)。因此，在本领域中需要无线网络的QoS调度技术。
发明内容
根据本发明的一方面，提供了一种能够采用接纳表(admissionprofile)与多个远程装置互操作的通信装置，该接纳表包括多个时间段，以及，在多个时间段中每一个时间段内有针对零个或多个远程装置的容量预留信息，该通信装置包括一个调度器，用于在多个时间段中的每个时间段内，对于多个数据传输指示中的每个指示，判断与该数据传输指示相对应的远程装置在接纳表中是否有容量预留信息，并根据该数据传输指示分配容量。另一方面，数据指示对应于一个或多个服务等级。另一方面，分配是按服务等级依次进行的。剩余容量可以依据数据传输要求的大小增序为优先级而进行分配。另一方面，接纳表根据可用系统容量进行更新，以接受具有一些流参数特征的新流。本发明还阐述了其它不同方面。
图1是通信系统的示例性实施例；图2是通信设备(即接入点或用户终端)的示例性实施例；图3示出了对多个用户终端/应用的三种数据进行调度；图4示出了接纳控制的例子；图5是一个示例性接纳控制单元的流程图；图6是调度器方法的通用实施例的流程图；图7示出了在QoS调度后分配剩余资源的另一种方法；图8示出了在数据类型信息已知的情况下在QoS调度后分配剩余资源的另一种方法。
具体实施例方式
这里使用的“示例性的”一词意味着“用作例子、例证或说明”。这里被描述为“示例性”的任何实施例不应被解释为比其它实施例更优选或更具优势。
图1示出了一个示例性的通信系统100。系统100包括无线局域网(WLAN)190，该局域网190包括接入点(AP)110和多个用户终端(UT)130A-130N。接入点120包括调度器120和接纳控制单元125(还有其它组件，细节未示出)。接纳控制单元125进行接纳控制，调度器120对数据业务进行调度。下面详细描述不同的实施例。接入点120连接至如因特网、企业内部网等的外部网络140，或其它数据连接。在本示例性的实施例中，网络140遵守因特网协议(IP)，因此网络上的业务通信包括IP分组。本领域的技术人员应理解，本发明披露的原则不限于此，其也可用于任何数据网络。为了便于说明，应用程序150被示为与外部网络140连接。通常，应用程序150驻留在服务器，或者任何其它装置上，其它装置包括另一用户终端，不时地试图和一个或多个用户终端130建立数据连接。这种连接，在此也称为数据流，或更简单地称为流，可以通过AP 110建立，该流可以通过空中接口180发送给相应的UT和该UT中的应用程序。同样地，运行于用户终端上的应用程序，如UT 130A上的应用程序160A-160N，会试图同一个设备和/或另一个用户终端上的应用程序或网络建立连接。同样，这样的连接可用通过AP 110建立。
调度器120和接纳控制单元125在接入点110中的位置只是作为示例。在其它实施例中，它们不需是处于同地的。在其它实施例中，一个或多个UT可包括一个调度器和/或接纳控制单元。一个或多个UT可以通过信令决定由一个指定的UT进行调度和/或接纳控制。在这种情况下，指定的UT就是事实上的接入点。指定的UT可随时间改变。一个或多个UT可同外部网络140连接。或者，可以没有从WLAN到外部网络的连接。还可以考虑有管理的点对点连接。例如，接入点(或指定的UT)可以管理接纳控制和/或调度两个其它用户终端间的连接。依照这种方式，数据传输直接在点之间进行，只有如请求和准许(grant)这样的控制信令传送到进行管理的接入点(或指定的UT)，或从此接收到。本领域的技术人员根据本发明的原理，也可以很容易地采用包括这些选项和其它选项的多种配置。这里经常用作例子的是包括接入点和一个或多个星形拓扑连接的用户终端的示例性实施例。这是描述本发明的其它方面的一个有用示例，但是本发明并不限于此。
WLAN 190可以处理不同类型的业务，包括实时业务，如视频，视频点播、多播视频、游戏程序和标准TCP/IP网络浏览。数据应用程序流的特点可能不同。例如，不同的流可能有不同的时延和/或容错要求。通常认为，语音数据要求低时延以避免接听者可觉察的延迟。然而，本领域存在不同的语音编码方法，其允许语音数据的“有损”传输，即，语音质量受稳定低等级误帧率的影响不大。另一方面，例如，下载文件对时延可能不如此敏感。然而，可能要求文件必须无误差地被接收到。为了为多种预期服务提供可接受的性能，调度器120提供服务质量(QoS)管理。
在一个示例性的实施例中，业务分为两组QoS敏感业务与尽力而为业务(BET，Best-Effort Traffic)。对时延和/或带宽要求严格的业务被置入QoS敏感组中。其余的被置入尽力而为组中。调度器120采用带宽预留的方法管理QoS敏感业务，下面对此进行详细描述。接纳控制单元125根据流的特性和可用的资源数量，采用接纳控制，接受或拒绝所提供的流。尽力而为业务采用简单的循环队列方式进行管理。这些及其它实施例，在下面进行详细描述。
在该示例性的实施例中，空中接口180是采用正交频分复用(OFDM)的多入多出(MIMO)WLAN。或者，可以采用包括FDM、CDM、TDM的其它空中接口。其它技术，如空间分集，可用来让多个用户访问一个或多个公共接口。空中接口的不同标准和设计定义了通过共享通信资源进行发送和接收的一种或多种信道类型。通常，预先指定一个或多个控制信道，以及一个或多个数据信道。通常定义广播信道，用于向多于一个的目的方同时发出信令(如前向链路上的消息)。通常采用随机接入信道，以使设备访问网络(如在反向链路上发起通话的UT)。在本发明的范围内，可以采用任何数据和/或控制信道配置。用户(即，通过网络140连接的应用程序150，或用户终端130)请求接入共享资源，而不考虑采用了哪个信道或信道类型。调度器采用下面详细描述的一种或多种技术来分配资源。本领域的技术人员很容易地就可以将这里披露的原理应用于各种不同的通信系统。
图2是一个示例性通信装置，如用户终端130或接入点110，的框图。本例中示出的框通常是用户终端130或接入点110包括的组件的一个子集。本领域的技术人员可以很容易地在任何数量的接入点或用户终端配置中采用图2所示的实施例。请注意，使用术语前向链路和反向链路仅供讨论之便。接入点110和基站功能类似，用户终端以典型的星形拓扑交互时，前向链路和反向链路是很适当的。然而，如上文所述，本发明的范围包括自组织(ad hoc)网络(其中多个用户终端130中的任何一个作为实际上的接入点110)、有管理的点对点连接等。本领域的技术人员应该明白，使用这些术语不会限制本发明的领域，而是适用于所用的上下文的习惯用法。
信号由天线210接收并发送给接收机220。天线210可以包括一个和多个天线。接收机220根据WLAN 190系统进行处理，该系统可能对应于一个或多个如前面所列举的无线系统标准。接收机220进行各种处理，如射频(RF)到基带转换、放大、模数转换、滤波等。本领域已知有各种不同的接收技术。接收机220可用来测量前向和反向信道的信道质量，但是，为清晰起见，图中仅示出了单独的信道质量估计器235。信道质量估计器235可用于确定信道质量，并由此估计可支持的数据速率。当通信设备知道它需要发送的数据量或传输需要的持续时间及可支持的数据速率时，就可以确定其需要的资源并相应地进行请求。在该示例性实施例中，通信设备确定需要发送的OFDM符号的数量。本领域的技术人员应该明白，可以采用多种方法来确定为了在变化的信道上发送已知量的数据而需要的共享资源量。或者，传输请求可以包括数据量和信道质量指示。这样，调度器可以根据这些因素确定要准许的OFDM符号量。
来自接收机220的信号在解调器225根据一种或多种通信设计或标准进行解调。在一个示例性的实施例中，采用了可以对MIMOOFDM信号进行解调的解调器。在其它实施例中，可以支持其它的标准，多个实施例可以支持多种通信格式。解调器230可以进行RAKE接收、均衡、组合、解交织、解码和接收到的信号格式所要求的其它功能。本领域存在不同的解调技术。在接入点110中，解调器225可以根据反向链路进行解调。在用户终端中，解调器225可以根据前向链路进行解调。这里描述的数据信道和控制信道都是在接收机220和解调器225中可接收和解调的信道的例子。如前文所述，前向数据信道解调可根据控制信道上的信令进行。
消息解码器230接收解调后的数据，并提取在前向或反向链路上分别发送给用户终端130或接入点110的信号和消息。消息解码器230对建立、维护和中止系统中的数据会话所采用的不同消息进行解码。消息可包括传输请求、传输准许或任何数目的控制信道消息。本领域存在不同的消息类型，所支持的不同的通信标准或设计中对其有所说明。该消息发送给处理器250进行后续处理。消息解码器230的部分或全部功能可在处理器250中执行，但是，为清晰起见，示出了一个分离的块。另一种情况是，解调器225可对某些信息进行解调，并将其直接发送给处理器250(例如，单比特消息如ACK/NAK或功率控制升/降命令)。
信道质量估计器235与接收机220连接，用于进行各种功率电平估计，以用于这里描述的过程及通信中的其它处理如解调中。信道质量估计器235示为独立模块，只是出于清晰讨论的目的。将这个模块结合到其它如接收机220或解调器225等模块中也是很常见的。可以进行不同类型的信号强度估计，其取决于所进行估计的信号和系统类型。具体而言，针对MIMO信道(M个发射信道和N个接收信道)，信道估计是一个MxN的矩阵。通常情况下，在本发明范围内，可用任何形式的信道质量矩阵估计块来取代信道质量估计器225。
信号通过天线210发送，天线210可包括多个天线。发送的信号在发射机270中，根据如前文所列举的一种或多种无线系统标准或设计进行格式化。发射机270可包括的组件有，例如，放大器、滤波器、数模(D/A)转换器、射频(RF)转换器等。待传输的数据由调制器265提供给发射机270。数据和控制信道可以根据多种格式进行格式化，以便于进行传输。在前向链路数据信道上待传输的数据，可以在调制器265中根据依照C/I或其它信道质量测量的调度算法指示的速率和调制格式进行格式化。调制器265可包括的组件有，例如，编码器、交织器、扩频器以及任何类型的调制器。
消息发生器260可用于生成这里所描述的不同类型的消息。例如，可以产生请求消息，来请求对空中接口的接入，以便于进行传输。响应于请求消息，可以产生用于传输的准许消息，该准许消息包括发出请求的用户终端可用的共享资源的分配信息。其它类型的控制消息可以在接入点110或用户终端130中产生。
在解调器225中接收并解调的数据可以发送给处理器250，以进行数据通信，或发给其它不同组件。同样，待传输的数据可以从处理器250发送给调制器265和发射机270。例如，不同的数据应用程序可以出现在处理器250，或者通信设备110或130(未示出)包括的其它处理器上。接入点110可以通过网络接口280，与一个或多个外部网络如因特网或网络140连接。用户终端130或接入点110可以包括通向外部设备如膝上型电脑(未示出)的连接。
调度器，如前文所描述的调度器120，可以驻留在处理器250中。接纳控制单元125可以驻留在控制器250中。下面将进一步详细描述不同的实施例。
处理器250可以是通用微处理器、数字信号处理器(DSP)或专用处理器。处理器250可以执行接收机220、解调器225、消息解码器230、信道质量估计器235、消息发生器260、调制器265、发射机270或者网络接口280以及其它通信设备要求的任何其他处理中的部分或全部功能。处理器250可与专用硬件连接，以支持这些功能(未示出细节)。数据或语音应用程序可以是外部的，如外部连接的膝上型电脑或与网络的连接，可以运行于通信设备110或130(未示出)中的其它处理器上，也可以运行在处理器250上。处理器250和存储器255连接，存储器可用于存储数据以及用于执行这里描述的不同过程和方法的指令。本领域的技术人员应该明白，存储器255可由不同类型的一个或多个组件组成，这些部件整个或部分嵌入在处理器255中的存储器中。存储器255可采用这里描述的一个或多个队列。存储器255适于存储一个或多个接纳表，对此下面进一步详细描述。
在该示例性的实施例中，采用了单个媒体访问控制(MAC)帧，其可支持多个UT流及每个UT可有多个流。定义了包括多个MAC帧的超帧。在本例中，超帧中MAC帧的数目是16个。
在该示例性的实施例中，在每个MAC帧的开始，发送一个控制信道(CCH)，其包括当前MAC帧的前向和反向链路段上所有活动流的调度信息。前向链路调度由从UT反馈的链路数据速率信息协助。反向链路调度由UT提供的队列状态信息和隐含链路数据速率信息(例如，请求的容量和数据命令及链路质量都有关)协助。休眠的UT可利用随机接入信道(RCH)来请求系统资源。另一种选择是，接入点也可以轮询用户终端。请注意，在管理的点对点连接中，从调度器的角度来看，所有对等UT间的传输可以视为反向链路调度的一部分。
通常情况下，人们希望在接入点收到链路状态信息的时间和在CCH上给UT发送所得调度信息的时间之间的延迟最小化。如果射频(RF)信道在所得传输发生之前改变，则过度的延迟可能导致在一个特定MAC帧中分配的数据速率作废。在该示例性的实施例中，MAC帧的目标延迟(大约2ms)被用作目标。
在该示例性的实施例中，发送给UT的前向链路数据在接入点以队列形式存储。数据种类类型可能或者不能识别队列。或者，各个队列可由通过网络140连接的应用程序维护。在本例中，反向链路数据存储在各个用户终端的队列中。请注意，使用术语反向链路和前向链路并不排除点对点连接(其中，数据在对等方之间传输，而不是发向/来自接入点或管理UT)，或这里披露的其它连接中的任何一种。对共享的通信资源的接入请求可以识别发出请求的数据类型，或者是单个请求包括多种分类。在该示例性的实施例中，就多个OFDM符号发送一个请求。或者，可就共享资源(即时隙、信道、功率等)的任何部分发出请求。请求可以反映请求方根据数据量和支持的比特率调整了请求大小，这是由于信道状况变化而导致的。这种类型的请求的优点是，在管理的点对点情况下，调度器不需要对等方之间的信道测量结果，也不需明确地确定反向链路信道的质量(即，在前向链路和反向链路不一定对称的情况下)。或者，请求可以不指定要求的资源量，而是指定数据量和一些信道质量指示。任何类型的请求或请求类型的组合，都可以由调度器支持。
为清楚起见，可以假定不同的用户终端是固定的，但本发明的范围不限于此。为清楚起见，不讨论移动UT在多个接入点间的切换。不管移动与否，任何UT和接入点间的无线信道都可因为不同的干扰原因而随时间变化。因此，任何UT的前向和/或反向链路的容量都会出现波动。
如前文所述，UT流分为两类，即尽力而为型和QoS敏感型。对时延不敏感的流，提供尽力而为服务。带宽预留和接纳控制相结合，可用于QoS敏感的流。调度器120也支持独立时延控制。为QoS敏感的流分配资源的额定固定部分，这是基于每MAC帧的方式或者超帧的分布方式(即16个MAC帧)实现的。额定分配是信源业务情况的函数，其在统计方面的特征表现为一组参数，这些参数可以包括平均速率、最大速率、突发度、最大时延等。接纳控制单元125利用这些以及其它参数，来确定满足流的QoS要求所需的额定速率和调度表。
从下面的详细描述可知，调度任务是很复杂的，原因在于信源的瞬时数据速率和信道可支持的比特率都可能变化。许多数据应用程序有突发的业务情况。例如，MPEG(国际标准化组织/国际电工技术委员会-运动图像专家组)编码的视频表现出的峰均值比可达10∶1。无线信道的信噪比(SNR)可因为遮蔽(shadowing)和干扰(无论UT是移动的或固定的)而大幅度变化，因此链路支持的数据速率也大幅度变化。
可以通过将合适的接纳策略和统计复用相结合，来满足QoS保证并获得良好的系统效率。当一个流要求额定分配的资源时，如果有剩余资源，则还可为其分配额外的资源。当支持大量的流时，统计复用的优点是很明显的，可以获得良好的系统效率。
下面详细描述接纳控制和调度的不同实施例。一个示例性的实施例概括如下。MAC帧中未使用的资源供应给其它流使用。瞬时要求超出额定分配的QoS敏感流首先得到服务。依照一种方式来分配未使用的资源，以使得满足QoS需求的流的数目最大化。如果在服务了QoS敏感的流后还有剩余资源，那么，接下来服务尽力而为流。未使用的资源以循环方式分配给尽力而为流。还可以选择使用公平策略。
图3示出了多个用户终端/应用程序的三类数据的调度。在一个示例性的实施例中，调度器把业务分为三个组。每个组内的优先级排序以不同方式实现。在本例中，每个UT管理各个业务类的不同队列。在每个业务类中，UT可以有多个流。在该示例性的实施例中，队列以面向字节的缓冲器的形式管理。调度器根据先进先出(FIFO)的原则服务队列中的字节。在其它实施例中可以采用任何形式的队列和接入顺序。
第一类业务，即无线链路控制(RLC)业务和UT无线链路连接的管理相关联，通常对时间非常敏感。因此，在本例中，RLC业务在所有业务类中优先级最高。调度器首选把资源分配给有待处理RLC的UT。RLC业务通常只占用总资源的一小部分。因此，为清楚起见，除非下面明确指出，下面的实施例讨论的是其它两种业务类型。本领域的技术人员可以很容易地采用这里描述的任何一个实施例中来处理第三种业务类型，如RLC。
第二类业务，即QoS敏感的流，为了满足如最大时延和/或传输突发数据的容量的需要，要求更严格的传输参数。可以通过接纳控制单元，为QoS敏感的流分配总资源的额定部分。QoS业务优先级高于尽力而为业务(BET)，即第三类业务。请求的资源明显超出其额定分配量的流，更可能得到恶化的服务。QoS业务可以占用总资源的相对大一部分，这依赖于系统的管理方式。
第三类业务BET优先级最低。下面详细描述一些处理BET的技术。
在图3中，多个用户终端UTA-UTN有多个队列310A-310N。请注意，这些队列可以在接入点110维护，以进行前向链路传输。在这种情况下，接入点准确知道哪个队列包含哪种数据类。各个用户终端130A-130N可以维护类似的队列。在传输请求中，用户终端可能会或者并不向接入点指示传输请求中包括的(若干或单个)数据类型。下面详细描述的不同示例性实施例包括这两种情况，以及两者的结合。通常，根据本申请的教导，本领域的技术人员可以根据本发明采用一个调度器来对前向或者反向链路进行调度，或者同事调度两者。
RLC调度功能模块320对各个RLC队列的排列的RLC数据进行调度。QoS调度功能模块330对各个QoS队列进行调度。同样，BET调度功能模块340对BET队列进行调度，BET队列的优先级最低。该图的下方示出了UTA-UTN的所得传输。请注意，作为示例性的例外情况，QoS队列310B的一部分在该UT的BET部分进行调度，而不是在QoS部分进行调度。这示出了请求超出额定QoS分配的一个例子。在这种情况下，BET分配足以满足任何其余QoS业务的要求，而不会产生QoS恶化。图3只是调度和数据类型的一个例子。下面详细描述不同的实施例。
下面详细描述两个基本方面接纳控制和分组调度。一个示例性的系统采用接纳控制单元控制QoS敏感业务的服务接受或拒绝。调度器可以记录接纳的流并试图维持它们的协商服务速率。
接纳控制如果需要的话，可以为QoS敏感的业务预留最大数目的时隙(即OFDM符号)FR。(FR也可设成可用时隙的总数)。如果还有剩余的时隙FR，就将其预留给尽力而为业务。可用的总资源(如前文所述，不包括RLC和类似的控制类业务)用FA表示
FA＝FR+FB(1)接纳控制单元可使用FR来决定是否将资源分给请求指定QoS的流。接纳控制单元可以采用“每个流”的不同变量来决定是否接纳一个流。下面是几个例子，其它例子对本领域的普通技术人员来说也是显而易见的。
可以指定不同的信源表征变量。例如，可以为流i指定带宽预留请求ar(i)，这是以比特/秒表示的数据速率要求，可基于和该流相关的QoS参数来计算。描述信源时可以采用漏斗模型(leaky bucketmodel)，即，平均可持续速率、峰值速率和突发性。还可以定义信源的最大时延dmax(i)，以获得调度流的高效方法。
还可以指定不同的链路表征变量。例如，可以定义链路上观测到的平均可实现数据速率r(i)(对于前向链路和反向链路采用不同的变量)。r(i)是和每个终端的物理层相关联的可实现速率的平均值，可在注册/校准期间确定。该值还可能根据链路状况(即衰落、路径损耗、干扰等)随时间波动。
在本例中，接纳控制单元根据这些参数，为QoS组中的流分配额定时隙分配量。该额定分配量保证在一个特定时间间隔，会分配到固定数量的时隙(即整数倍个帧)。依赖于这些参数，额定分配量可能导致每个MAC帧有固定数目的时隙，或者每个超帧(即16个MAC帧)有固定数目的时隙。
如果信源数据速率超过协商的速率，或链路数据速率降低到低于协商的速率，为了满足其需要，流会请求额外的时隙。在这种情况下，统计复用可以提供足够的流裕量，以满足每个流的不足。统计复用的效率和共享该资源的用户数目成正比。通常，用户越多，效率就较高。
在本例中，分配给流i的分配量表示为φ(i)＝min(φmax，φ(i)) (2)其中 请注意， 是对x取整，φmax是能够分配给一个流的最大分配量的上限。本领域的技术人员应该明白，在一些实施例中，φmax值越小，系统效率就越高。然而，在有些情况下，限制φmax可能会限制较高速率服务的覆盖区域。本领域的技术人员在采用不同实施例时，应该根据这个折衷来选择φmax。
总的分配量是QoS组Na中每个流的分配量的和FR=Σi=1Naφ(i)---(4)]]>一个特定流的需求表示为 其中br(i)是信源的瞬时比特率，r(i)是链路上观测到的数据速率。总的需求表示为 当总需求量超过总分配量时，就会发生服务中断。在一个示例性实施例中，接纳控制算法拒绝给任何会使D＞FR的概率超过中断门限(如0.1％)的流提供服务。请注意，中断不一定意味着对所有流的服务中断。一个特定流的中断概率取决于其它瞬时流需求。
在一个示例性的接纳控制实施例中，为每个有QoS流的UT分配一个占空因数和MAC帧相位参数。占空因数表示和该流的调度间隔相关的周期性(如每10个MAC帧1个时隙)。相位参数表示流传输的MAC帧的标号(如0到15)。当对每个UT处理多个QoS流时，占空因数最高的流可以确定和该UT相关的所有QoS流的调度。
请考虑下面示于图4中的例子。假定一个流的速率请求对应于每个超帧(即32ms)375个时隙的需求。为了满足该流的速率参数，为其分配每个MAC帧平均23.4375个时隙。进一步假定该流的最大时延参数为dmax(i)＝5个MAC帧(即10ms)。下面是一个允许的分配方案MAC帧#4117个时隙MAC帧#9117个时隙
MAC帧#14117个时隙MAC帧#1524个时隙接纳控制单元对一个超帧中的16个MAC帧构建一个分配矢量A[i]＝{0，0，0，0，117，0，0，0，0，117，0，0，0，0，117，24}(7)设R[i]为MAC帧0、1、…15的总时隙分配矢量。那么，接纳控制单元可以确定A[i]的相移kA，其用于预留随后分配中可用的资源。图4示出了R[i]的一个例子，及对A[i]进行相移为kA＝15并和R[i]相加的结果。
本领域的技术人员应该理解用于确定是否接纳一个流的不同标准，以及如何为一个接纳的流分配资源。例如，一帧的容量可以既分配给QoS业务，又分配给BET业务。该分配结果可以是每个帧固定值，或可以进行调整，以增加封包效率。对每种分配方案而言，都存在封包效率和接受额外流的能力间的折衷。本领域的技术人员可以根据不同的因素，采取不同的实施例做出分配决定，例如，某一时刻预期数目的QoS流的统计特性，及多个流的预期参数(即相位和占空因数等)。
此外，本领域的技术人员应该理解可实现的效率和QoS维护间可能存在折衷。例如，考虑这样一个流，其速率和最大时延允许其每第4个MAC帧在一个时隙内以满意的效果被发送出去，实现的封包效率是80％。或者，该流可以40％的时隙封包效率每两个MAC帧在一个时隙内传送。第一种调度方案从系统效率的角度考虑是优选的。然而，从QoS的角度来看，第二种调度方案更优，因为其可以提供额外的链路裕量，来处理链路数据速率的降低。在确定流调度方案时，可以采用有能力平衡期望的效率等级和/或QoS维护的接纳控制单元。
图5是一个示例性接纳控制单元500的流程图。在步骤510，一个应用程序为一个新的QoS流发出接纳请求。该请求包括该流的期望特性的参数。这些参数的例子如前文所述。请回想一下，通常，接纳控制单元根据预期参数(即平均参数)做出接纳决定。然而，调度器会根据实时数据传输请求分配容量，实时数据传输请求是随实际的数据量和时变通信信道的当前状态而改变的。
在步骤520，接纳控制单元根据现有的接纳表，评估所请求的新流的容量可用性，接纳表指明了已经接纳的流的期望数据需求。前文根据图4，描述了一种根据现有表确定如何纳入所请求接纳的流的示例性方法。在判断步骤530，如果有足够的容量能满足吞吐量需求以及其它QoS需求(如占空因数和时延需求)，就转向步骤540。在步骤540，向发出请求的应用程序发送一条消息，指示新的流已被接纳。发送请求的应用程序然后就可以启动和新的流相关的任何一个过程或多个过程。
在判断步骤530，如果没有足够容量，则转向步骤570。在步骤570，向请求方应用程序发送拒绝新流的消息。然后，过程结束。
在步骤550，接纳新的流后，修改接纳表，以包括针对新流的承诺。本领域的技术人员应该理解，在本发明范围内，有多种表示接纳表的方法。在该示例性的实施例中，以OFDM符号的形式来分配容量。采用的是包括16个MAC帧的MAC超帧。接纳表包括在各个MAC帧中分配给各个接纳流的OFDM符号数目的承诺或协定。在其他实施例中，可以分配其它的容量单元，如TDM系统中的时隙、CDM系统中的功率和/或编码等。接纳表可以采用不同级别的时间粒度，也可以是持续时间不同的周期长度。此外，针对一个流的承诺不必限于特定的帧。例如，可为一个流分配多个帧内特定数量的符号，作为其接纳表承诺的一部分。调度器可以灵活地决定将哪个帧分配给该流，只要在特定范围内满足协定的最小要求即可。
在步骤560，将更新后的接纳表提供给调度器。任何将接纳表提供给调度器的方法均落入本发明的范围内。例如，调度器可以仅仅能够从和接纳控制单元共享的存储器中访问接纳表。在另一个实施例中，接纳表可以通过消息发送给调度器。并不需发送整个接纳表，因为可以将新增加的流与以前接纳的流相结合，从而形成当前的接纳表。然后，过程结束。请注意，可以根据期望重复该过程，以使应用程序利用调度器预留带宽。
另外请注意，也可以从接纳表中去掉一些流，这对本领域的技术人员来说是显而易见的。图5未示出其细节。应用程序可以发送一条消息，指示一个流不再必要。或者，可以发送一个新的请求，以修改流。另一种选择是，如果应用程序不遵守其协议参数，则调度器可以指示接纳控制单元除去该流。这种情况下，可以完全中断该流，或者将其变为尽力而为状态。这种情况下，如果QoS的最小要求不能得到满足，则应用程序可能会被迫中止和该流相关的过程。该应用程序可以根据调整后的参数，重新请求接纳一个流，并和调度器建立QoS维持的服务(即服务重新协商)。
QoS调度在采用QoS调度的一个基本实施例中，为一个流发出传输(即接入)请求。该请求无需识别进行传输的业务类型，简单地指示业务量即可。在这种情况下，发出请求的应用程序可以根据优先级排列其队列中的数据(即QoS先于BET)。请注意，在一个实施例中，调度器和一个或多个队列处于同地，例如在一个有前向链路业务队列的接入点中，或者如前文所述，在一个作为接入点的或管理一个或多个点对点连接的UT中，在这样的实施例中，传输请求不是必需的，因为处于本地的不同队列的数据指示了传输需要。在一个基本实施例中，队列中的数据类型可能未知，在这种情况下，发送请求的应用程序应当根据优先级排列发送到该队列中的数据。在这些基本情况下，QoS调度可以利用接纳表中约定的承诺进行。
如果存在关于队列中数据的额外信息，则可以提供额外的功能和控制。例如，如果调度器和一个或多个与不同流相关的队列处于同地，并且这些队列是独立的，或者这些队列提供了数据类的指示(如QoS或BET)，那么，调度器就知道等待传输的有多少数据及是什么类型的数据。在这种情况下，调度器可以对不同类型的数据进行优先级排列。一个示例性的实施例可以是有前向链路流的接入点。请注意，如果从信源到UT有多于一种的数据种类，则产生这些流的应用程序可能需要指示数据种类。在这种情况下，反向链路调度可能是如前所述的基本调度，而前向链路调度可能要考虑不同数据类型(下面进一步描述)。
或者，传输请求也可以指示数据类型。如果有多于一类的数据等待传输(即从UT)，则请求可以指示每类数据有多少在等待传输。在这种情况下，调度器可以象处理处于同地的队列一样处理数据种类。
在一个实施例中，可以利用请求类型和队列的任意组合。当存在具体的消息时，调度器可以简单地利用它，当没有这种消息可用时，调度器可以不利用这种消息而继续处理。在任何实施例中，调度器可以利用在不同应用程序/流和接纳控制单元之间协定的接纳表，如前文所述，来实现这里描述的QoS调度优点。
图6示出了调度器方法600的概括性实施例的流程图。方法600可用于前面描述的简单情况及其任意结合，在这些情况下，存在关于数据种类的高级消息。图7进一步示出了步骤640的另一种情况，其适用于数据类型未知的情况。图8进一步示出了步骤64的另一种情况，其适用于数据类型已知的情况。图8还示出了本发明的其它方面。
方法600开始于步骤610，这里，从接纳控制单元接收到更新后的接纳表。如前文针对图5所述，接纳表可简单地存储于共享存储器中，这样接纳控制单元和调度器都可以访问它。在另一个实施例中，接纳表的更新传输给调度器，并和调度器现有的接纳表的当前状态相结合。请注意，针对QoS流容量的承诺可以随时间加入或去除。
在步骤620，调度器从多个用户终端和/或应用程序收到多个传输请求(即通过网络140收到)。在步骤630，对于在接纳表中有协议的UT/应用程序，为其分配最多达协议量的容量。在一个示例性的实施例中，每个UT/应用程序在当前帧中，有预留用于传输的协定数目的OFDM符号(前文结合图4描述了一个这样的例子)。请注意，和步骤630相关的分配方案可能无法满足全部请求的数据量。这是因为，变速率数据源经常比用于协议的平均量产生更多的数据。此外，无线信道变坏可能需要额外的容量(即OFDM符号、时隙、功率等)来发送期望的数据量。
在步骤640，如果还有额外的容量可用于分配，则可将其分配给任何剩余未满足的请求。步骤640的其它情况在图7和图8示出，下面将进一步描述。在一个实施例中，剩余的容量可以采用任何数目的尽力而为类型策略进行分配。例如，容量可以在剩余的请求中可以循环方式分配。在另一个实施例中，一个帧中有协议QoS分配的UT/应用程序在剩余的BET分配中可以给予优先级，其理论依据是，在步骤630中未被分配资源的一些或全部剩余请求，可能是超过协议分配量的QoS数据。剩余者的分配也可以采用其它公平原则。可以利用额外级别的优先级排序，例如一些UT/应用程序在BET分配中优先级高于其它UT/应用程序。可以采用这些技术的任意组合。其它选择在下面详细描述。
本领域的技术人员可以容易地将这里的教导扩展到其它的种类以及任何种类的结合。例如，为了清楚起见，如前文所述，这里描述的不同实施例都省略了对RLC业务的描述。在一个示例性的实施例中，RLC业务可能是优先级最高的业务，但是要求总容量中相对较小的一部分。因此，处理该第三种、优先级最高的数据类的方法之一是为每个发出请求的、RLC数据可能是其请求之一部分的UT分配少量容量。其余容量可以根据这里描述的QoS或BET调度来分配。显然，如果识别出请求中有RLC业务，或以其它方式知道其存在(即，包括在处于同地的队列中)，则可采用直接的方式进行分配。
图7示出了步骤640的另一种替代实施例，用于在QoS调度后分配剩余容量。作为对前述不同方法的一种替代，图7示出的步骤640的实施例可用来试图使请求得到准许的UT/应用程序数目最大。在步骤710，对前文所述的未被分配或仅仅部分分配的请求进行排序，最高次序与请求大小(或其剩余部分)成反比。在步骤720，剩余容量根据从高到低的次序分配给请求。如果由于容量不足而无法进行最后一次分配，就对该请求进行部分分配。因此，根据本方法，满足了可以处理的最大数目的请求。本实施例可以结合前述其它各种实施例使用。
如前文所述，当调度器知道与请求相关或处于队列中的数据类型时，这一信息可以加入调度决定中。为了说明这一原理，请参考下面的例子。对调度器管理的每个QoS流，维持一个活动标记。在任一特定帧中，为该帧中有额定时隙分配的所有被接纳QoS流设定活动标记(如图4所示)。在当前MAC帧中，首先服务所有设有活动标记的QoS流。其它QoS流在当前MAC帧中可能或者不能得到服务，者取决于是否还有未用的FR资源。本例中，如前文所述，FR可以是为QoS服务所预留的容量的限制，FR可以预留用于尽力而为业务。应该明白的是，如果需要的话，可以将FR设成全部容量。如果调度器知道是否有一个或多个部分分配的请求包括QoS数据，并且其它请求是尽力而为业务，那么，调度器将优先级给予其余QoS业务。如果一部分FR没有全部分配，调度器最好提前工作(work ahead)，这样可以减少以后的负载。如果分配给QoS服务的容量FR数量有限，则采用这种方法预先占用当前BET请求是合适的。然而，提前工作(下面详细描述)可以在有未分配容量的任何时候进行。
在本例中，活动QoS敏感流分为两组一组有正的流裕量D+的，而另一组有负的流裕量的D-i∈D-，如果(i)＞φ(i) (8)i∈D+，如果(i)≤φ(i) (9)D+中的流不会遇到中断，因为其流需要小于或等于其分配量。此外，D+中有正流裕量的流贡献出未用时隙集合M，其可优先排序方式供其它QoS流使用。根据是否有未使用的资源，D-中的流可以或不能接收其需求。
如果D-非空，则任何未用时隙都可以供这组中的流首先使用。有几种把未用时隙分配给D-中活动QoS流的方法。本例的目的是使满足其QoS需要的流的数目最大化。这通过对D-中的流根据它们的流裕量mi进行排序实现。即，裕量|mi|最小的流排序最高。请注意，mi属于D-意味着mi是负值。
在本例中，调度器从剩余裕量集合中分配最小数量的时隙，以使D-中排序最高的流满足需求(i)。重复进行这一过程，直到剩余裕量集合用尽或者所有活动的QoS流都得到服务为止。如果最后一个QoS流未得到完全满足，其可得到部分分配。未能完全满足的流可能会遇到变差的服务。本例可能会引起未收到其分配量的流。这种情况下，可能会发生缓冲器溢出及分组丢失。为了防止这种情况，来自特定流的QoS队列的缓冲器溢出可以放置在用户的尽力而为队列的前端。
如果服务完全部活动的流后还有未用时隙，则FR的剩余部分可提供给在其QoS队列上有数据但是在当前帧没有活动标记的QoS流的组。这种“提前工作”调度能力是早先引入的，其通常在调度器可以访问未来待传输数据，即希望在下一帧或多帧中传输的数据的情况下进行。在一个实施例中，接入点带有调度器，并且维护前向链路数据队列。因此，如果需要的话，调度器可以在合适的情况下提前工作。在一个实施例中，仅仅根据接纳表，来调度反向链路数据QoS请求，所以，调度器不能知道用户终端未来的数据，故只在前向链路上提前工作。对这条反向链路而言，调度器不区分MAC帧中安排好的数据以外的QoS和BET数据(根据接纳表)。也就是说，一旦在反向链路段上满足了特定流的QoS业务需要，调度器就将UT数据的剩余部分视为BET业务。本领域的技术人员应该明白如何在前向链路或反向链路，以及调度器的任何位置使用本原理。具体而言，该调度器可以处于指定UT中，后者采用前述过程，为管理的点对点连接提供调度。此外，还请注意，从UT的角度来看，在本例中，数据可以任何希望的方式在UT队列中排列(例如，提前工作的QoS数据可以排在UT的BET队列前)。因此，如果希望的话，UT甚至可以在调度器不提前工作的时候提前工作。
为非活动的前向链路QoS流分配未用时隙(提前工作)可以如下进行。非活动前向链路QoS流根据其相位参数进行优先级排序。即，将在下一个MAC帧变为活动的非活动前向链路流得到最高优先级。这一相位组中的流优先级排序的方式为，最大数目的流可以得到满足(如前所述)。因此，首先服务队列中数据量最少的非活动流。调度器继续对这些非活动QoS流进行提前工作，直到FR中的所有时隙均已被占用或者所有QoS队列为空为止。
图8示出了步骤640的另一种实施例，其用于在请求传输的数据的一些信息已知的情况下(或在队列中处于同地)，在QoS调度后对剩余容量进行分配。该实施例和前文描述的正、负流裕量的例子可兼容，并且也可以使用提前工作。
该过程从判断步骤810开始。如果没有剩余容量可供分配，则过程停止。如果有剩余容量，则转到步骤820。在步骤820，对QoS请求进行排序。也可以采用不同的排序方法。在本实施例中，为了服务最多的请求，请求按照与大小成反比进行排序。
在步骤830，选择下一最高排序的请求(对于第一次迭代，用最高排序)。在步骤840，将剩余容量分配给所选择的请求。如果请求的剩余部分大于剩余容量，则将剩余容量进行分配。在判断步骤850，如果剩余容量用尽，则过程停止。如果还有容量剩余，则转到判断步骤860。
在判断步骤860，如果还有其它QoS请求未得到分配，则返回步骤830，选择下一个最高排序的请求，重复前面描述的过程。如果所有QoS请求都得到处理，则转到步骤870。
步骤870用虚线表示，这表明提前工作是可选的。如果需要的话，调度器可以提前处理未来的QoS帧。前面已经描述了进行提前处理的例子。
在步骤880，任何剩余的容量都分配给尽力而为业务。可以采用任何尽力而为方法。在一个实施例中，采用循环调度方法服务尽力而为业务。这种方法对不同用户终端或同一个用户相关的多个流，不能提供QoS区分。然而，如前文所述，用户可以自由对队列中的分组进行优先级排序，以支持其希望的任何QoS方案。如果希望进行附加级别的用户间优先级排序，可以采用信令，以使调度器协助进行这种优先级排序，这对本领域的技术人员来讲是显而易见的。
应当注意的是，前文所描述的所有实施例中，方法步骤可以互换而不偏离本发明的范围。这里披露的描述，本申请的说明书在很多地方提及和MIMO OFDM系统相关的信号、参数和过程，然而，本发明的范围不限于此。本领域的技术人员可以容易地把本申请的原理应用于不同的其它通信系统。这些及其它修改对本领域的技术人员来说是显而易见的。
本领域技术人员应当理解，可以使用多种不同技术和方法表示信息和信号。例如，在贯穿上面的描述中提及的数据、指令、命令、信息、信号、比特、符号和码片可以用电压、电流、电磁波、磁场或粒子、光场或粒子、或者上述的任意组合来表示。
本领域技术人员还会明白，这里结合所公开的实施例描述的各种示例性的逻辑框、模块、电路和算法步骤均可以电子硬件、计算机软件或二者的结合来实现。为了清楚地示出硬件和软件之间的可交换性，以上对各种示例性的组件、框、模块、电路和步骤均以其功能性的形式进行总体上的描述。这种功能性是以硬件实现还是以软件实现依赖于特定的应用和整个系统所施加的设计约束。熟练的技术人员能够针对每个特定的应用以多种方式来实现所描述的功能性，但是这种实现的结果不应解释为导致背离本发明的范围。
利用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程的逻辑器件、分立门或者晶体管逻辑、分立硬件组件或者它们之中的任意组合，可以实现或执行结合这里公开的实施例描述的各种示例性的逻辑框图、模块和电路。通用处理器可能是微处理器，但是在另一种情况中，该处理器可能是任何常规的处理器、控制器、微控制器或者状态机。处理器也可能被实现为计算设备的组合，例如，DSP和微处理器的组合、多个微处理器、一个或者更多结合DSP核心的微处理器或者任何其他此种结构。
结合这里公开的实施例所描述的方法或者算法的步骤可直接体现为硬件、由处理器执行的软件模块或者这二者的组合。软件模块可能存在于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、移动磁盘、CD-ROM或者本领域熟知的任何其他形式的存储媒质中。一种典型存储媒质与处理器耦合，从而使得处理器能够从该存储媒质中读信息，且可向该存储媒质写信息。在替换实例中，存储媒质是处理器的组成部分。处理器和存储媒质可能存在于一个ASIC中。该ASIC可能存在于一个用户站中。在一个替换实例中，处理器和存储媒质可以作为用户站中的分立组件存在。
提供所述公开的实施例的上述描述可使得本领域的技术人员能够实现或者使用本发明。对于本领域技术人员来说，这些实施例的各种修改是显而易见的，并且这里定义的总体原理也可以在不脱离本发明的范围和主旨的基础上应用于其他实施例。因此，本发明并不限于这里示出的实施例，而是与符合这里公开的原理和新颖特征的最广范围相一致。
权利要求
1.一种用于对通信系统中的数据传输进行调度的调度器，所述调度器包括第一逻辑，用于判断与一个或多个数据传输指示相对应的一个或多个远程装置中的每一个远程装置在接纳表中是否有容量预留信息；以及第二逻辑，用于在有容量预留信息时根据数据传输指示分配容量。
2.如权利要求1所述的调度器，其中，所述第二逻辑根据所述容量预留信息限制所述分配。
3.如权利要求2所述的调度器，其中，在有剩余容量的情况下，所述第二逻辑还响应于任何未满足的数据传输指示，根据所述数据传输指示的未分配部分大小的增序，分配所述剩余容量。
4.如权利要求1所述的调度器，其中，多个数据传输指示中的每一个和多个服务等级中之一相关联。
5.如权利要求4所述的调度器，其中，所述第二逻辑响应于和第一组服务等级中的一个或多个服务等级相关联的一个或多个传输指示，根据所述接纳表，分配容量，并且，在有剩余容量的情况下，响应于和第二组服务等级中的一个或多个服务等级相关联的一个或多个传输指示，分配剩余容量。
6.如权利要求5所述的调度器，其中，所述第一组包括一个或多个服务质量有保证的服务等级。
7.如权利要求5所述的调度器，其中，所述第二组包括一个或多个尽力而为的服务等级。
8.一种通信装置，能够与多个远程装置一同操作，且采用接纳表进行工作，该接纳表包括多个时间段以及在所述多个时间段中的每个时间段内的针对零个或多个远程装置的容量预留信息，所述通信装置包括调度器，用于在所述多个时间段中的每个时间段内，对于多个数据传输指示中的每一个数据传输指示，判断与所述数据传输指示相对应的远程装置在所述接纳表中是否有容量预留信息，以及，根据所述数据传输指示，分配容量。
9.如权利要求8所述的通信装置，其中，所述调度器根据所述容量预留信息限制所述分配。
10.如权利要求9所述的通信装置，其中，在有剩余容量的情况下，所述调度器还响应于任何未满足的数据传输指示，根据所述数据传输指示的未分配部分大小的增序，分配所述剩余容量。
11.如权利要求8所述的通信装置，还包括接收机，用于接收包括有数据传输指示的请求消息。
12.如权利要求8所述的通信装置，还包括一个或多个数据队列，在队列中有数据存在时产生数据传输指示。
13.如权利要求8所述的通信装置，还包括发射机，用于发送一个或多个指示所述分配容量的准许消息。
14.如权利要求8所述的通信装置，还包括接纳控制单元，用于接收接纳请求，所述接纳请求包括与来自远程装置的数据流相对应的流参数；在所述流参数和所述接纳表相结合不会超过系统容量时，有条件地接纳所述流；以及修改所述接纳表，以便于在接纳时将所述流加入。
15.如权利要求8所述的通信装置，其中，每个远程装置可对应于多个数据传输指示，每个指示和一个服务等级相关联。
16.如权利要求15所述的通信装置，其中，所述调度器响应于和第一组服务等级中的一个或多个服务等级相关联的一个或多个传输指示，根据所述接纳表，分配容量，并且，在有剩余容量的情况下，响应于和第二组服务等级中的一个或多个服务等级相关联的一个或多个传输指示，分配剩余容量。
17.如权利要求16所述的通信装置，其中，所述第一组包括一个或多个服务质量有保证的服务等级。
18.如权利要求16所述的通信装置，其中，所述第二组包括一个或多个尽力而为的服务等级。
19.如权利要求15所述的通信装置，其中，所述调度器响应于和一个或多个在所述接纳表中有容量预留信息的远程装置相关联的一个或多个传输指示，分配容量，为每个远程装置分配的容量受限于其相应的容量预留信息；然后，在有剩余容量的情况下，响应于和第一组服务等级相关联的未满足传输指示，分配剩余容量；以及然后，在有剩余容量的情况下，响应于和第二组服务等级相关联的传输指示，分配剩余容量。
20.如权利要求19所述的通信装置，其中，在有剩余容量的情况下，所述调度器还在响应于和所述第二服务等级相关联的指示进行分配之前，响应于和所述第一服务等级相关联的一个或多个未来时间段中的数据传输指示，分配容量。
21.如权利要求19所述的通信装置，其中，响应于未满足指示的分配是根据所述数据传输指示的未分配部分大小的增序而进行的。
22.一种通信系统，包括多个远程装置；接纳表，其包括多个时间段，以及，在所述多个时间段中的每个时间段内的针对零个或多个远程装置的容量预留信息；以及通信装置，其包括一个调度器，该调度器用于在所述多个时间段中的每一个时间段内，对于多个数据传输指示中的每一个数据传输指示，判断与所述数据传输指示相对应的远程装置在所述接纳表中是否有容量预留信息，以及，根据所述数据传输指示，分配容量。
23.一种调度方法，包括从一个或多个远程装置接收一个或多个传输指示；以及根据接纳表，准许所述传输请求中的一个或多个。
24.如权利要求23所述的方法，还包括接收接纳请求，该接纳请求包括与来自远程装置的数据流相对应的流参数；在所述流参数和所述接纳表相结合不会超过所述系统容量时，有条件地接纳所述流；以及修改所述接纳表，以便于在接纳时将所述流并入。
25.一种调度方法，包括对于多个时间段中的每一个和对于多个数据传输指示中的每一个，判断与所述数据传输指示相对应的远程装置在接纳表中是否有容量预留信息；以及当所述接纳表中有容量预留信息时，根据所述数据传输指示分配容量。
26.如权利要求25所述的方法，其中，一个或多个所述数据传输指示是从一个或多个远程装置接收到的。
27.如权利要求25所述的方法，其中，一个或多个所述数据传输指示是响应于队列中存在数据而产生的。
28.如权利要求25所述的方法，其中，多个所述数据传输指示中的每一个对应于多个服务等级中之一。
29.如权利要求28所述的方法，其中，首先为对应于第一服务等级的多个数据传输指示分配容量，然后，如果还有剩余容量的话，再为对应于一个或多个第二服务等级的多个数据传输指示分配剩余容量。
30.一种调度方法，包括接收对应于多个远程装置的多个传输指示；访问接纳表，以判断一个或多个传输指示在所述接纳表中是否有相关联的预留信息；根据所述找到的预留信息，分配容量；将剩余的容量分配给剩余的多个传输指示；以及根据所述容量分配情况，发送一个或多个准许消息。
31.一种装置，包括传输请求接收模块，用于从一个或多个远程装置接收一个或多个传输请求；以及传输请求准许模块，用于根据接纳表准许一个或多个所述传输请求。
32.如权利要求31所述的装置，其中，所述接纳表包括多个帧，以及，在每帧有和一个远程装置相关联的零个或多个容量值。
33.如权利要求31所述的装置，其中，所述接纳表是根据一个或多个数据流的占空因数和帧相位而产生的。
34.如权利要求31所述的装置，还包括接纳请求接收模块，用于接收接纳请求，所述接纳请求包括与来自远程装置的数据流相对应的流参数；有条件接纳模块，用于在所述流参数和所述接纳表相结合不会超过所述系统容量时有条件地接纳所述流；以及修改模块，用于修改所述接纳表，以便于在接纳时将所述流并入。
35.一种通信系统，包括接收模块，用于从一个或多个远程装置接收一个或多个传输请求；以及准许模块，用于根据接纳表准许所述传输请求中的一个或多个。
36.计算机可读介质，用于执行包括下列步骤的方法从一个或多个远程装置接收一个或多个传输请求；以及根据接纳表，准许一个或多个所述传输请求。
37.如权利要求36所述的介质，用于执行以下步骤接收接纳请求，所述接纳请求包括与来自远程装置的数据流相对应的流参数；在所述流参数和所述接纳表相结合不会超过所述系统容量时，有条件地接纳所述流；以及修改所述接纳表，以便于在接纳时将所述流并入。
全文摘要
根据本发明的一方面，提供了一种通信设备，其采用接纳表，能够与多个远程设备互操作，该接纳表包括针对零个或多个远程设备的容量预留信息，该通信设备包括一个调度器，用于判断对应于数据传输指示的远程设备在接纳表中是否有容量预留信息，并根据数据传输指示分配容量。另一方面，数据指示对应于一个或多个服务等级。剩余容量可以依据数据传输需求量大小的增序为优先级，而进行分配。另一方面，对接纳表进行更新，以便于根据可用的系统容量，接受特征为流参数的新流。
文档编号H04L12/28GK1906900SQ200480040712
公开日2007年1月31日 申请日期2004年11月24日 优先权日2003年11月26日
发明者J·罗德尼·沃尔顿, 桑吉夫·南达 申请人:高通股份有限公司