CN103650440B - 用于在通信网络中优先化并调度数据包的检测系统和方法 - Google Patents

Abstract

系统和方法提供一种参数化调度系统，所述参数化调度系统并入终端用户应用认知且可与包括来自异构应用的数据流的调度组一起使用。在多个协议级上分析数据包以检测与传递所述数据包相关的特征。所述数据包被过滤，使得有效地执行检测所述特征。所述检测的特征可用于调度所述数据包的传输。所述检测的特征可用以动态改变调度参数。所述动态调度参数可响应于循环的网络模式、一次性事件、应用特征、协议特征、设备特征、服务等级协议或其组合而最大化用户体验质量（QoE）。调度参数也可将“持续时间忽视”和“近因效应”的概念并入终端用户对视频质量的感知，以在拥塞期间管理视频流量。

Description

用于在通信网络中优先化并调度数据包的检测系统和方法

发明背景

本发明一般涉及通信系统领域且涉及用于在通信网络中优先化并调度数据包的检测系统和方法。

在例如互联网协议（IP）网络的通信网络中，每个节点和子网对于可在任何给定时间有效传输的数据量都有限制。在有线网络中，这通常是设备容量的函数。例如，千兆以太网（Gigabit Ethernet）链接可传输不超过十亿位元流量每秒。在无线网络中，容量由使用的信道带宽、传输技术和通信协议来限制。无线网络还由分配到服务区的频谱量和发送和接收系统之间的信号的质量约束。因为这些方面可以是动态的，所以无线系统的容量可随时间变化。

另外，每个节点对于处理可执行都有限制。增加可用处理可能很昂贵或者可能需要使节点停止使用。另外，节点可能具有许多不同的竞争可用处理的功能。即使当足够的处理容量可用时，它的使用也带来例如功率消耗方面的成本。

发明概要

提供用于提供并入终端用户应用认知的参数化（或基于权重的）调度系统，和它们的有效实施方式的系统和方法。本文公开的系统和方法可包括具有包括来自异构应用的数据流的调度组的通信系统。一些实施方案使用包检查以供终端用户应用对数据流量进行分类。可基于应用类别、具体应用、个别数据流或其一些组合来创建调度组内的个别数据队列。实施方案使用应用信息结合应用因子（AF）来修改调度器参数（例如，权重、信用或借记），从而区别处理分配到调度组的数据流。在实施方案中，提供一种用于通过使用动态AF设置来调整不同用户应用的相对重要性以响应于循环的网络模式、一次性事件、应用特征或任何它们的组合来最大化用户体验质量（QoE）的方法。

在实施方案中，提供一种用于通过动态管理调度权重来最大化视频应用的用户QoE的方法。该方法将“持续时间忽视”和“近因效应”的概念并入终端用户对视频质量（即，视频QoE）的感知，以便在拥塞期间优化管理视频流量。

在实施方案中，提供一种用于在无线通信系统中调度数据包的传输的基于权重的调度系统。所述系统包括分类和排队模块、权重计算模块和调度器模块。分类和排队模块被配置来接收包括来自多个异构数据流的数据包的输入流量。所述分类和排队模块也被配置来分析每个数据包并基于所述数据包的属性将所述数据包分配到调度组。所述分类和排队模块还被配置来输出一个或多个数据队列和与所述一个或多个数据队列中的每一个中的所述数据包相关的分类信息。所述权重计算模块被配置来接收来自所述分类和排队模块的所述分类信息并计算所述一个或多个数据队列中的每一个的权重并输出所述计算的权重。所述调度器模块被配置来接收来自所述分类和排队模块的一个或多个数据队列并接收来自权重计算模块的计算的权重。所述调度器模块还被配置来基于计算的权重从一个或多个数据队列选择数据包并将选定的数据包插入输出队列来通过物理通信层传输。

在实施方案中，提供一种用于在通信网络中优先化并调度数据包的方法。所述方法包括接收多个数据包；对多个数据包进行分类；将多个数据包分离成多个调度组；将多个数据包分离成多个数据队列；确定权重以与数据队列中的每一个相关联。所述权重至少部分由与所述数据包相关的应用类型来确定。所述方法还包括基于与数据队列相关的权重来从多个数据队列选择数据包；基于与数据队列中的每一个相关的权重来将选定的数据包插入输出数据队列；和通过物理通信层传输来自输出数据队列的多个数据包以通过网络通信介质传输。

在实施方案中，提供一种用于操作通信设备以调度数据包的传输的方法。所述方法包括：接收来自通信网络的数据包；对所述数据包进行分类；基于所述分类将所述数据包分离成调度组，所述调度组中的每一个与至少一个数据队列相关；将所述数据包中的每一个插入与所述对应的调度组相关的所述数据队列中的一个；确定与所述数据包相关的应用；确定所述数据队列的权重，所述权重至少部分基于与所述对应的数据队列中的所述数据包相关的所述应用；考虑到所述权重，将所述数据包从所述数据队列调度到输出队列；和将所述数据包从所述输出队列传输到所述通信网络。

在实施方案中，提供一种用于调度数据包的传输的通信设备。所述通信设备包括：分类和排队模块，其被配置来接收数据包的，所述分类和排队模块还被配置来分析所述数据包的属性，并基于所述属性将所述数据包分配到调度组，所述分类和排队模块还被配置来输出数据队列中的所述数据包，其中所述调度组中的每一个与所述数据队列中的至少一个相关，所述分类和排队模块还被配置来确定与所述数据包相关的应用，并输出关于所述应用的信息；权重计算模块，其被配置来利用来自所述分类和排队模块的所述应用信息来计算并输出指示所述数据队列的相对优先级的权重；和调度器模块，其被配置来以考虑到来自所述权重计算模块的所述权重的顺序从所述数据队列选择数据包并将所述选定的数据包插入输出队列来通过物理通信层传输。

在实施方案中，提供一种用于操作通信设备以调度数据包的传输的方法。所述方法包括：接收来自通信网络的数据包；确定与所述数据包相关的应用；将所述数据包中的每一个插入多个数据队列中的一个；确定所述数据队列的调度器参数，所述调度器参数包括基于与所述对应的数据队列中的所述数据包相关的所述应用的因子；考虑到所述调度器参数，将所述数据包从所述数据队列调度到输出队列；和将所述数据包从所述输出队列传输到所述通信网络。

在实施方案中，提供一种用于调度数据包的传输的通信设备。所述通信设备包括：分类和排队模块，其被配置来接收数据包并输出数据队列中的所述数据包，所述分类和排队模块包括被配置来分析所述数据包的属性、确定与所述数据包相关的应用并输出关于所述应用的信息的包检查模块；调度器参数计算模块，其被配置来计算并输出指示所述数据队列的相对优先级的调度器参数，所述调度器参数包括基于来自所述包检查模块的所述应用信息的因子；和调度器模块，其被配置来以考虑到来自所述调度器参数计算模块的所述调度器参数的顺序从所述数据队列选择数据包并将所述选定的数据包插入输出队列来通过物理通信层传输。

在实施方案中，提供一种用于操作通信设备以调度数据包的传输的方法。所述方法包括接收来自通信网络的数据包；监控接收的数据包中含有的一个或多个连接以检测所述连接的特征；将所述数据包中的每一个插入多个数据队列中的一个；确定所述数据队列的调度器参数，所述调度器参数包括基于与所述对应的数据队列中的所述数据包相关的所述检测的特征的因子；考虑到所述调度器参数，将所述数据包从所述数据队列调度以进行传输；和基于所述调度来传输所述数据包。

在实施方案中，提供一种通信设备。所述通信设备包括被配置来接收数据包、分析所述接收的数据包，并考虑到调度器参数调度所述接收的数据包以从所述通信设备传输的参数化调度模块，所述参数化调度模块包括包检查模块，所述包检查模块包括：被配置来确定应进一步检查所述接收的数据包中的哪一个的流量监控模块；被配置来检测关于用于传输所述数据包的连接的信息的连接检测模块；被配置来检测关于与所述数据包相关的流、会话和应用的信息的流和会话检测模块；和被配置来存储所述检测的信息的状态模块。

本发明的其它特征和优势将从以举例的方式示出本发明的方面的以下描述显而易见。

附图简述

本发明的结构和操作上的细节可部分通过研究附图来收集，在附图中相同的元件符号表示相同的部件，且其中：

图1是根据实施方案可实施本文公开的系统和方法的无线通信网络的框图；

图2是根据实施方案可实施本文公开的系统和方法的另一无线通信网络的框图；

图3是根据实施方案的站的功能框图；

图4是根据实施方案示出协议层的图表；

图5是根据实施方案示出可用以实施调度技术的参数化调度模块的框图；

图6是根据实施方案示出排队系统中异构输入流量和个别队列之间的关系的框图；

图7是根据实施方案使用参数化调度技术来使将通过网络介质传输的数据包排队的方法的流程图；

图8是根据实施方案示出无线通信系统的框图；

图9是根据实施方案示出用于增强型分类/排队模块中的增强型包检查模块的框图；

图10是根据实施方案示出用于增强型分类/排队模块中的增强型包检查模块的框图；

图11是示出可用于本文公开的各种技术中的应用类别和具体应用之间的映射的实例的表；

图12是根据实施方案示出封装在TCP/IP帧内的RTSP包的实例的图表；

图13是根据实施方案的包检查模块的功能框图；

图14是根据实施方案示出包括RTP标头和RTP有效载荷的RTP包的实例的图表，所述RTP有效载荷含有H.264视频数据；

图15是根据实施方案示出具有填充的八位字节的RTP包的实例的图表；

图16是根据实施方案示出每应用类别每具体应用基础上的示例性应用因子分配的表；

图17是根据实施方案示出增强型权重因子计算的表；

图18是示出可用于本文公开的增强型权重因子或信用计算中的系数的管理的时序图；

图19是根据实施方案的计算系数的方法的流程图；

图20是根据实施方案示出由具有增强型数据包分类和排队的参数化调度系统进行的流量整形的图表；

图21是根据实施方案的包检查模块的功能框图；

图22是根据实施方案用于检测连接初始化的过程的流程图；

图23是根据实施方案用于监控连接的过程的流程图；和

图24是示出示例性视频下载的比特率与时间的关系的图表。

具体实施方式

提供用于提供并入终端用户应用认知的参数化调度系统的系统和方法。本文公开的系统和方法可与含有来自异构应用的数据流的调度组一起使用。一些实施方案使用数据包检查以供终端用户应用对数据流量进行分类。可基于应用类别、具体应用、个别数据流或其一些组合来创建调度组内的个别数据队列。实施方案使用应用信息结合应用因子（AF）来修改调度器参数，从而区别处理分配到调度组的数据流。在实施方案中，提供一种用于通过使用动态AF设置来调整不同用户应用的相对重要性以响应于循环的网络模式、一次性事件或两者来最大化用户QoE的方法。在实施方案中，提供一种用于通过动态管理调度参数来最大化视频应用的用户QoE的方法。所述方法将“持续时间忽视”和“近因效应”的概念并入终端用户对视频质量（即，视频QoE）的感知，以便在拥塞期间优化管理视频流量。

本文公开的系统和方法可应用于各种容量有限的通信系统，包括但不限于有线技术和无线技术。例如，本文公开的系统和方法可用于蜂窝2G、3G、4G（包括长期演进（“LTE”），LTE高级，WiMax）、WiFi、超移动宽带（“UMB”）、电缆调制解调器和其它有线技术或无线技术。虽然本文用以描述具体实施方案的用语和术语可应用于特定技术或标准，但是本文描述系统和方法并不限于这些具体标准。

基本部署

图1是根据实施方案可实施本文公开的系统和方法的无线通信网络的框图。图1示出包括宏蜂窝、微微蜂窝和企业毫微微蜂窝的通信系统的典型基本部署。在典型部署中，宏蜂窝可在一个或许多个频道上传输并接收，所述频道与小型（SFF）基站（包括微微蜂窝和企业或住宅毫微微蜂窝）使用的一个或许多个频道分开。在其它实施方案中，宏蜂窝基站和SFF基站可共享相同的频道。地理因素和信道可用性的各种组合可产生各种可影响通信系统的吞吐量的干扰情形。

图1示出典型的微微蜂窝和企业毫微微蜂窝在通信网络100中的部署的实例。宏基站110通过回程连接170连接到核心网络102。在实施方案中，回程连接170是双向链路，或两个单向链路。从网络102到宏基站110的方向被称为下游方向或下行方向。从宏基站110到核心网络102的方向被称为上游方向或上行方向。订户站150（1）和150（4）可通过宏基站110连接到核心网络102。在实施方案中，订户站150和宏基站110之间的无线链路190是双向点对多点链路。从宏基站110到订户站150的无线链路190的方向被称为下行方向或下游方向。从订户站150到宏基站110的无线链路190的方向被称为上行方向或上游方向。订户站有时被称为用户设备（UE）、用户、用户设备、手持机或终端机。在图1示出的网络配置中，办公楼120（1）造成覆盖阴影104。经由回程连接170连接到核心网络102的微微站130可在覆盖阴影104中提供对订户站150（2）和150（5）的覆盖。订户站150（2）和150（5）可通过与订户站150（1）和150（4）与宏基站110之间的无线链路190相同或类似的链路连接到微微站130。

在办公楼120（2），企业毫微微蜂窝140向订户站150（3）和150（6）提供室内覆盖。企业毫微微蜂窝140可通过利用企业网关103提供的宽带连接160经由ISP网络101连接到核心网络102。

图2是根据实施方案实施本文公开的系统和方法的另一无线通信网络的框图。图2示出通信网络200中的典型基本部署，包括部署在住宅环境中的宏蜂窝和住宅毫微微蜂窝。宏蜂窝基站110通过回程连接170连接到核心网络102。订户站150（1）和150（4）可通过宏基站110连接到网络。在住宅220内，住宅毫微微蜂窝240可向订户站150（7）和150（8）提供家中覆盖。住宅毫微微蜂窝240可通过利用缆线调制解调器或DSL调制解调器203提供的宽带连接260经由ISP网络101连接到核心网络102。订户站150（7）和150（8）可通过与订户站150（1）和150（4）与宏基站110之间的无线链路190类似的链路连接到住宅毫微微蜂窝260。

有线形式和无线形式的数据网络（例如，IP）均对特定连接或用户具有最小储备容量，且因此需求可能超出容量。这种拥塞效应可能发生在有线网络和无线网络上。

在拥塞期间，网络设备必须确定允许哪些包在网络上行进，即，哪些流量被转发、延迟或丢弃。在简单的例子中，数据包被添加到固定长度的队列，且在容量允许时被发送到网络。在网络拥塞期间，固定长度的队列可填充容量。当队列已充满时到达的数据包通常被丢弃，直到队列被排出足够的数据以允许排队更多数据包。所述先进先出（FIFO）方法具有公平对待所有数据包的缺点，而不管用户、应用或紧急性。这是不期望的响应，因为它忽略了每个数据流可能基于产生流量的应用（例如，语音、视频、电子邮件、互联网浏览等）而具有独特的数据包传送要求。由于包延迟和/或丢弃，所以不同的应用以不同方式降级且降级了不同的严重程度。因此，FIFO方法被认为不能管理流量以最大化通常被称为体验质量（QoE）的终端用户的体验。

作为响应，已开发出技术来分类数据包并处理具有不同的重要性级的数据流且/或管理区别的服务等级。数据流可以是来自单个用户应用的相关数据包的流，例如，YouTube视频的视频包或视频Skype会话的视频包部分。

图3是站277的功能框图。在一些实施方案中，站277是无线或有线访问节点，例如，基站、LTE eNB（演进节点B，其也常被称为eNodeB）、UE、终端设备、网络交换机、网络路由器、网关、订户站或其它网络节点（例如，图1和图2中示出的宏基站110、微微站130、企业毫微微蜂窝140、企业网关103、住宅毫微微蜂窝240、电缆调制解调器或DSL调制解调器203，或订户站150）。站277包括通信地耦合到传输接收模块（收发机）279和存储模块283的处理器模块281。传输接收模块279被配置来传输并接收与其它设备的通信。在一个实施方案中，以无线的方式传输和接收所述通信。在这样的实施方案中，站277通常包括用于传输和接收无线电信号的一个或多个天线。在另一实施方案中，通过线缆传输和接收所述通信。在许多实施方案中，除了传输接收模块279之外，站277还经由另一通信信道来传输并接收通信。例如，通过基站中的传输接收模块279接收的通信可在处理之后在回程连接上传输。类似地，从回程连接接收的通信可通过传输接收模块279传输。

处理器模块281被配置来处理由站277接收并传输的通信。存储模块283被配置来存储数据供处理器模块281使用。在一些实施方案中，存储模块283也被配置来存储用于实现本文关于站277描述的功能的计算机可读指令。在一个实施方案中，存储模块283包括非临时性机器可读介质。为了解释的目的，站277或例如基站、订户站和毫微微蜂窝的它的实施方案被描述为具有某些功能。应理解，在一些实施方案中，这个功能由处理器模块281结合存储模块283和传输接收模块279来实现。

图4示出了可用于描述通过网络的数据流的示例性协议层1400。网络使用协议层来从一层提供的功能抽象出另一层的功能。这可允许可更便携地将应用用于不同的网络。应用程序1410是软件或实施方案如视频Skype的具体应用的其它过程。在例如图1和2中描述的网络中，数据包流的初始化和随后的终止可由特定网络应用或服务触发。关于终端用户应用或服务的使用的数据包流可被称为会话。会话的实例包括使用来自膝上型计算机的Skype应用的互联网语音协议（VoIP）呼叫，使用在基于Android的移动电话上运行的YouTube应用的流媒体视频回放，或使用在启用IP多媒体子系统（IMS）的长期演进（LTE）移动网络上运行的苹果的iChat应用的双向（2-way）视频通话。会话层1420是存在视频Skype呼叫的实际例子或会话的层。

网络中许多不同的节点（例如，应用服务器、代理服务器、例如网络交换机或路由器的传输设备、存储设备、例如智能电话、平板计算机，或膝上型计算机的终端用户设备）可发起或参与会话。节点可同时主持一个或多个会话。所述同时会话可彼此独立（例如，同时使用Facebook和电子邮件的用户）或彼此相关（例如，产生两个视频串流会话的浏览会话）。会话可在两个节点之间建立。或者，会话可被视为例如通过使用组播和广播协议的一个节点与许多节点之间的关系。

会话可用各种准则来表征或分类。一个准则是由用户发起并负责启动会话的具体应用（例如，应用程序或软件1410）。具体应用的实例包括YouTube应用（app）、Chrome互联网浏览器和Skype语音通话程序。另一准则是描述特定会话提供的整体功能的应用类别。示例性应用类别包括流式视频、语音呼叫、互联网浏览、电子邮件和游戏。

流层1430是存在组成会话的个别数据流的层。会话可包括使用相同或可能不同的下层连接的一个或多个独立数据流。例如，单个VoIP电话呼叫会话可包括两个数据流。一个数据流可使用UDP连接来提供双向语音流量（其可为有效载荷或数据平面包）。例如当使用会话初始化协议（SIP）时，第二数据流可使用一个或多个TCP连接来处理呼叫建立/拆除（其可为信令或控制平面包）。在另一实例中，对于视频Skype通话，可能存在载送SIP信令、开始、停止或控制会话的一个流；使用实时传输（RTP）协议来载送语音包的第二流；和使用RTP协议来载送视频包的第三流。

连接层1440是通过逻辑链路层1450提供的某个逻辑链路传输流层1430数据的层。连接层1440协议不是特定于应用也不是特定于物理介质。连接可指的是用以传输会话数据和消息的下层协议且可以指的是用以建立（发起）或删除（终止）连接的数据包、消息和交易组。例如，可经由使用IP地址和端口号的组合的互联网协议（IP）网络的两个节点之间的传输控制协议（TCP）来建立面向连接的套接字。一旦被建立，该TCP连接可用以传输数据包，例如，超文本传输协议（HTTP）串流视频会话的数据包。作为TCP连接的替代，可建立数据报套接字来使用用户数据报协议（UDP）传输流量。

在视频Skype实例中，在连接层1440，SIP信令流1432是通过由源IP地址和目的地IP地址和TCP端口识别的TCP/IP连接来传输的，而语音流1434和视频流1436各自是通过由源IP地址和目的地IP地址和UDP套接字识别的UDP/IP连接来传输的。虽然UDP协议被认为是无连接的，但是也使用术语“连接”来描述确保流的数据包从数据源传输到数据宿的UDP机制是很方便的。

逻辑链路层1450是存在从上述层抽象出实际物理介质和其传输机制的逻辑链路的层。例如，在LTE系统中，视频Skype会话的多个连接（每个连接均载送流）被载送在LTE数据无线电载体（DRB）（例如，通过图1的无线链路190）内。在数据遍历图1的回程链路170期间，DRB可以是从数据包网关到eNodeB的隧道的延续。

性能要求

一种在不同数据流之间分配重要性并优化资源分配的方法是通过使用期望的性能要求。例如，性能要求可包括期望的数据包吞吐量，和容忍延迟和抖动。可基于数据或支持应用的类型来分配这样的性能要求。例如，互联网语音协议（VoIP）电话呼叫可被分配有适于通过IP网络基于数据包的传输语音的以下性能要求：吞吐量=32千比特每秒（kbps）、最大延迟=100毫秒（ms），且最大抖动=10ms。相反，载送视频的数据流可能需要实质上更大的吞吐量，但可允许以下稍宽松的延迟和抖动性能：吞吐量=2兆每秒（Mbps）、最大延迟=300ms、最大抖动=60ms。

位于网络节点处的调度算法可使用这些性能要求来进行数据包转发决定以试图最好地满足每个流的要求。流的性能要求的总和通常被描述为服务的质量或QoS、流的要求。

优先级

另一种分配重要性的方法是通过在不同数据流之间使用相对优先级。例如，例如IEEE 802.1p和IETF RFC 2474 Diffserv的标准定义了IP帧标头内载送所述优先级信息的比特。该信息可被网络节点的调度算法用以进行转发决定，与IEEE 802.11e无线标准的情况相同。数据包或数据流的附加特征也可映射到优先级值，并传递到调度算法。例如，标准802.16e允许将例如IP源/目的地址或TCP/UDP端口号的特征映射到相对流优先级，同时也考虑到例如吞吐量、延迟和抖动的性能要求。

调度组

在一些系统中，数据流可被分配到由调度方法、成员数据流、调度要求或或其一些组合的一个或多个共同特征定义的离散数量的调度组。

例如，调度组可由将在成员数据流上使用的调度算法定义（例如，调度组#1可使用比例公平算法（proportional fair algorithm），而调度组#2使用加权循环算法（weighted round-robin algorithm））。

或者，调度组可于对类似应用（例如，语音、视频或后台数据）的数据流进行分组。例如，Cisco定义了六个组来区别语音、视频、传信、后台和其它数据流。所述应用的区别可与应用到每个调度组的唯一调度算法组合。

在另一实例中，第三代合作伙伴计划（3GPP）已建立了称为QoS类识别符（QCI）的构造以供长期演进（LTE）标准使用。QCI系统具有由性能要求、调度器优先级和用户应用的组合定义的9个调度组。例如，QCI index=1引用的调度组由以下特征定义：

（1）性能要求：延迟=100ms、丢包率=10^-2、保证比特率

（2）优先级：2

（3）应用：交谈语音

术语‘服务类别’（或CoS）有时用作调度组的同义词。

基于权重的调度系统

在上文描述的系统中，一个或多个数据流可被分配有重要性和期望的性能等级。该信息可用以将数据包从每个数据流分配到调度组和数据队列。调度算法也可使用该信息来确定在有线系统和无线系统中优先处理哪些队列（且因此哪些数据流和数据包）。

在一些调度算法中，通过使用调度权重将每个队列的重要性和期望的服务等级传达到调度。例如，加权循环（WRR）和加权公平排队（WFQ）调度方法都使用权重来在数据队列之间调整服务。在一些调度算法中，通过使用信用和借记将每个队列的重要性和期望的服务等级传达到调度。例如，按比例公平调度（PFS）方法可使用信用和借记来在数据队列之间调整服务。一些算法使用权重并将它们转为将在调度轮期间提供的数据包或字节数量形式的信用。

在WRR中，在每个调度轮中服务所有非空队列，其中每个队列提供的数据包的数量与队列的权重成正比。权重可衍生自各种输入，例如购买服务的相对等级（例如，金、银或铜服务）、最小保证比特率（GBR）或最大允许的比特率。在一个实例中，三个队列可具有待处理的数据。队列1、2和3的队列权重分别是1、3和6。如果在每一轮期间将提供20个数据包，那么队列1、2和3将分别被给予20个数据包预算的10%、30%和60%或2、6和12个数据包的信用。本领域技术人员应认识到，也可应用其它权重且权重、信用和率的概念可互换。

WFQ算法类似于WRR，因为建立并提供了加权数据队列以试图在数据流上提供公平的等级。与WRR相反，WFQ通过查看提供的字节数量而不是数据包的数量来提供队列。WFQ在数据包可被分为若干片或段的系统中运作良好，例如在WiMAX系统中。在三个队列具有待处理的数据且队列1、2和3的队列权重分别是1、3和6的实例中，权重将转为在所述调度轮期间可用带宽的10%、30%和60%的信用。

PFS算法通常使用例如GBR或最大允许率的率的函数以直接计算每个队列每调度轮接收的信用。例如，如果服务被允许有每秒768千字节的速率，且每秒100调度轮，那么服务的队列将接收信用为每调度器轮7680字节。调度轮期间实际分配到队列的量从队列的积累信用借记而来。信用可一轮一轮地被调整或积累以试图平衡多个队列的性能要求。例如，被分配的资源小于它的最小GBR规格的第一队列可能具有有效地使其权重相对于被分配的容量实质上高于其GBR的第二队列增加的积累信用（通常高达某一允许的上限），从而有效地使第二队列积累负信用或借记。

图5是根据实施方案示出用以实施上述各种参数化调度技术和下文描述的增强型参数化调度技术的参数化调度模块300的框图。图5示出的参数化调度系统可实施以使用一个或多个调度组。在一个实施方案中，关于图5的特征描述的功能由图3的处理器模块281来实施。

输入流量305可包括一组异构的个别数据流，每个个别数据流都具有独特的用户、会话、逻辑连接、性能要求、优先级或进入调度系统的策略。分类和排队模块310被配置来评估每个数据包的相对重要性和分配的性能要求并将数据包分配到调度组和数据队列。根据实施方案，分类和排队模块310被配置来使用例如802.1p或Diffserv的上述方法中的一个来评估每个数据包的相对重要性和分配的性能要求。

根据实施方案，实施参数化调度系统300以使用一个或多个调度组，且每个调度组可具有与所述调度组相关的一个或多个数据队列。根据实施方案，每个调度组可包括不同数量的队列，且每个调度组可使用不同的方法来将数据包分组为队列或其组合。下文提供对输入流量、调度组和数据队列之间的映射的详细描述。

根据实施方案，分类和排队模块310输出一个或多个数据队列315和分类信息330，分类信息330被接收为调度器参数计算模块335的输入。短语“输出一个或多个数据队列”旨在包括填充数据队列而不需要实际传输或传递队列。根据实施方案，分类信息330可包括分类结果、数据包大小、数据包数量和/或当前队列利用率信息。调度器参数计算模块335被配置来在每个队列基础上计算新的调度器参数（例如，权重和/或每调度器轮信用）。调度器参数计算模块335可被配置来基于各种输入来计算新的参数，所述输入包括分类信息330、可选运营商策略和服务等级协议（SLA）信息350和可选调度反馈信息345（例如，从调度器模块320接收到的流历史或资源利用率）。然后，调度器参数计算模块335可将调度器参数340输出到一个或多个调度器模块320。

调度器模块320接收由分类和排队模块310输出的调度器参数340和数据队列315（或访问所述数据队列）。可用各种方式来实施本文描述的数据队列。例如，它们可能含有实际数据（例如，数据包）或者只是数据（数据包）的指针或识别符。调度器模块320使用更新的调度器参数340来例如使用上述方法（例如PFS、WRR或WFQ）中的一个以确定将数据包（或数据包的片段）从数据队列315转发到输出队列325的顺序。在实施方案中，输出队列325实施为指向数据队列315的指针。输出队列325中的流量被出队且馈送到物理通信层（或‘PHY’），以在无线介质或有线介质上传输。

图6是示出基于权重的排队系统中异构输入流量与个别队列之间的关系的框图。图6更详细地示出了图5示出的分类和排队模块310的操作。

异构输入流量305被输入包检查模块410，包检查模块410表征每个数据包以如上所述评估性能要求和优先级。基于所述信息，每个数据包被分配有三个调度组420、425和430中的一个。虽然图6示出的实施方案只包括三个调度组，但是其它实施方案可包括更多或更少数量的调度组。然后，所述数据包可被分配到与调度组中一个相关的数据队列（491、492、493、494或495）。数据包可基于性能要求、优先级、附加用户特定策略/SLA设置、独特的逻辑连接或其一些组合被分配到与调度组相关的具体数据队列。在一个实施方案中，分类和排队模块310分析沿例如从客户端向服务器和从服务器向客户端的两个方向流动的数据包，且使用来自沿一个方向流动的数据包的信息以分类沿另一方向流动的数据包。然后，包检查模块410除了异构输入流量305以外还可接收来自第二方向的输入流量，或者可接收来自表征沿第二方向传递的数据包的另一检查模块的信息。

在一个实例中，LTE eNB被配置来将每个QCI分配到个别调度组（例如，具有QCI=9的数据包可被分配到一个调度组而具有QCI=8的数据包被分配到不同的调度组）。另外，可基于用户ID、载体ID、SLA或其一些组合将具有QCI=9的数据包分配到个别队列。例如，每个LTE UE可具有默认载体和一个或多个专用载体。在QCI=9的调度组中，来自默认载体的数据包可被分配到一个队列，而来自专用载体的数据包可被分配到不同的队列。

图7是根据实施方案使用参数化调度技术来排队将通过网络介质发送的数据包的方法的流程图。可使用图5、6、9和10中示出的系统来实施图7示出的方法。根据实施方案，图7示出的方法是根据实施方案使用上文所述的各种参数化调度技术和下文所述的增强型参数化调度技术来实施的。

方法始于接收将被调度以通过网络介质发送的输入流量（步骤1205）。根据实施方案，网络介质可为有线介质或无线介质。根据实施方案，输入流量是上文描述的输入流量305。输入流量可包括一组异构的个别数据流，每个个别数据流都与用户、会话、逻辑链路、连接、性能要求、优先级或策略相关。根据实施方案，分类和排队模块310可执行步骤1205。根据实施方案，包检查模块410可执行该评估步骤。

然后，可将输入流量分类（步骤1210）。根据实施方案，分类和排队模块310可执行步骤1210。在该分类步骤中，输入流量被评估以确定每个数据包的相对重要性并确定每个数据包是否都分配了性能要求。例如，在LTE网络中，数据包网关可将数据包分配到具体的逻辑链路或载体。这是通过将相同的隧道ID分配到相同的逻辑链路（逻辑信道）的数据包来指示的。当建立逻辑载体时，隧道ID被映射到LTE调度组（即，QCI）。这又暗示了与调度组相关的某些性能要求。隧道ID可被检测且用以确定性能要求和调度组并将数据包分配到队列。类似地，在WiMAX中，服务流ID可用于类似目的。根据实施方案，包检查模块410可执行所述评估步骤。所述信息然后可被分类和排队模块310用以确定数据包应添加哪些调度组。

输入流量然后可被分离成多个调度组（步骤1215）。分类和排队模块310可使用来自分类步骤的信息来确定应将每个数据包添加到的调度组。根据实施方案，分类和排队模块310的包检查模块410可执行该步骤。根据实施方案，使用例如802.1p或Diffserv的上述方法中的一个来评估每个数据包的相对重要性和分配的性能要求。

然后，可将包括输入流量的数据包插入与调度组相关的一个或多个数据队列（步骤1220）。根据实施方案，分类和排队模块310的包检查模块410可执行所述步骤。

然后可计算数据队列中的每一个的调度器参数（步骤1225）。根据实施方案，由调度器参数计算模块335来实施该步骤。基于在步骤1210中创建的分类信息来计算数据队列中的每一个的调度器参数。分类信息330可包括分类结果、连接识别符（例如，源IP地址和目的地IP地址、TCP端口、UDP套接字）、逻辑链路识别符（例如，LTE中的隧道ID或载体ID、WiMAX中的服务流ID或连接ID）、数据包大小、数据包数量和/或当前队列利用率信息。调度器参数的计算也可考虑到其它输入，所述输入包括可选运营商策略和服务等级协议（SLA）信息和可选调度反馈信息。

一旦已经将数据包添加到队列，数据包可基于与所述队列相关的调度器参数（例如，权重和信用）选自队列中的每一个，且被插入输出队列（步骤1230）。输出队列中的数据包然后可被出队且馈送到物理通信层（或‘PHY’），以在无线介质或有线介质上传输（步骤1235）。根据实施方案，调度器模块320可实施所述方法的步骤1230和1235。

一些系统中的缺点

在WRR、WFQ、PFS或其它基于权重或信用的算法中，一些系统将数据包分配到队列并基于优先级、性能要求、调度组或其一些组合来计算调度器参数。在这些方法中有许多缺点。

例如，考虑到性能要求的调度器的配置通常很复杂，从而要求网络运营商具有相当的知识和技巧，且调度器可能无法充分地实施以将数据流与不同的应用区分。这导致在单个队列或调度组中高重要性数据流和低重要性数据流的不当分组。例如，考虑IEEE 802.16网络。如参看图4描述地区别个别流有时是不可能或不实际的，在所述情况下可使用下层信息。例如，可仅使用网络的网关IP地址（即，IP“源地址”）来识别上行链路（UL）数据流（或服务流）。在所述情况下，WiMAX UL调度器策略及参数同等处理路由器“后方”的所有数据流（而不考虑应用或性能要求）。

基于优先级的权重或信用计算系统有许多潜在的缺点。用以分配优先级的系统可能并未意识到用户应用，且在一些情况下无法正确区分正传输到特定用户或传自具体用户传输的多个数据流。优先级分配是静态的，且无法被调整以考虑变化的网络条件。优先级信息可能会归因于网络设备的错误配置而丢失，或者甚至归因于网络运营商策略而被剥离。可用优先级的数量可能是有限的，例如IEEE 802.1p标准只允许8个等级。另外，当数据包通过通信系统传输时，可能会归因于从一个标准到另一标准的转译差异而产生不匹配。

图8是根据实施方案示出无线通信系统的框图。在图8示出的系统中，数据源510（例如VoIP电话，流媒体视频服务器、流媒体音乐服务器、文件服务器或P2P应用的其它设备）经由通信链路515连接到互联网520。在互联网520内，存在一个或多个被配置为将流量导向适当数据包目的地的网络路由器525。在该实例中，互联网流量被沿着链路530载送到移动网络535。流量通过网关540传递到链路545上并进入无线电访问网络（RAN）550。RAN 550的输出通常为链接到用户终端560（例如，手机）的无线、射频连接555。

图8示出的实例中可存在两个不同优先级系统之间的差异。例如，VoIP电话通常被配置来使用IEEE 802.1p或IETF RFC 2474（“diffserv”）数据包标记优先化系统来用升高的优先级标记数据包，所述优先级指示某一期望处理的等级。例如，在RFC 2474中，此类优先级落入三种类别中的一个：默认类、确保类和快速类。在后两种类别中，存在关于期望的相关性能要求的子类别。是VoIP电话的数据源510产生的数据包因此将在具有所述优先级标记的通信链路515和530上行进。当数据包到达移动网络网关540时，这些优先级需要被转入在移动网络内建立的优先化系统。例如，在LTE网络中，可执行到QCI的映射。该转译可能会产生问题。例如，可能完全忽略diffserv信息。或者diffserv信息可用以分配不适于进行语音服务的QCI等级。另外，diffserv信息可用以分配细粒度比diffserv等级小的QCI等级，因此向VoIP数据包分配与来自许多其它应用的数据包相同的QCI等级。

一些系统已致力于组合优先权及性能要求的概念，以便向调度系统提供附加信息。。例如，在802.16中，流（或“服务”）的重要性由优先级值（基于数据包标记，例如802.1p）和性能要求的组合定义。虽然例如802.16的组合系统可向调度器提供一组更丰富的信息，但是上文所描述的缺点仍存在。

单独使用调度组或结合上述技术使用调度组具有许多关于终端用户QoE的缺点。例如，调度组的可用数量在一些系统中受限制，这可防止必要的细粒度控制来将最佳的QoE传递到每个用户。另外，一些系统通常使用“尽力”调度组来描述具有最低重要性的那些队列。数据流可落入这样的组，因为它们确实不重要，但也因为当需要较高的重要性时，未通过上述方法将所述流正确分类（有意地或无意地）。

所述问题的实例是出现‘过多’语音和视频服务或应用。所述服务提供使用网络运营商的可见性和/或控制外的服务器和服务的容量。例如运营商提供的语音或视频的来自运营商拥有或认可的来源的数据流可被区别到不同的服务流、载体（逻辑链路），或在到达例如基站的无线访问节点之前的连接。所述区别常映射到调度组和队列中的区别。然而，来自其它来源的服务和所得数据流都可被捆绑在一起到默认、常尽力的逻辑链路或载体。例如，Skype和Netflix分别是两个支持语音和视频的基于互联网的服务或应用。来自所述应用的数据流可由无线运营商(例如Verizon或AT&T)提供的数据服务载送，对于所述无线运营商，所述数据流可显示为非优先化数据而不是被识别为语音或视频。因此，当通过无线网络传输时，所述应用产生的数据包可在‘尽力’的基础上处理，而不给它们超过例如网页浏览、电子邮件或社交网络更新的典型尽力服务的优先级。

一些系统实施对调度权重或信用的动态调整。例如，为了达到例如保证比特率（GBR）或最大延迟的性能要求，调度权重可向上调整，或者当特定数据流的实际、调度吞吐量降至接近保证最低限度时，可积累它的调度信用。然而，权重或信用的所述调整未考虑到QoE对终端用户的影响。在之前的实例中，增加权重或积累信用来达到GBR限制可导致QoE没有明显改良，但大量降低具有低权重每调度轮信用或积累信用（或借记）的竞争队列的QoE。

因此，需要一种系统和方法来改良区别对待来自分组到相同调度组的异构应用的数据包流，如对于“尽力”调度组常见的情况。另外，需要将提供到参数化调度的信息扩展超过优先级和性能要求以通过网络最大化用户QoE。

增强型分类技术

如上所述，通信系统可使用分类和排队方法来基于性能要求、优先级和逻辑连接区别数据流。

为了在一些系统中解决上述缺点，可增强图5的分类和排队模块310以提供增强型分类和排队模块310′（图9和图10）。根据实施方案，在图5示出的参数化调度系统300（其可包括增强型分类和排队模块310′）中示出的功能可在单个无线网络节点或有线网络节点中实施，所述单个无线或有线网络节点例如基站、LTE eNB、UE、终端设备、网络交换机、网络路由器、网关或其它网络节点（例如，图1和图2中示出的宏基站110、微微站130、企业毫微微蜂窝140、企业网关103、住宅毫微微蜂窝240和电缆调制解调器或DSL调制解调器203）。在其它实施方案中，图5示出的功能可分布在多个网络节点上。例如，在LTE网络中，增强型数据包检查可在EPC数据包网关或其它核心网关设备中执行，而排队、调度器参数计算模块335和调度器模块320位于eNB基站中。其它功能分区也同样可能。增强型分类和排队模块310′可分析每个数据包的应用类别和/或具体应用并进一步区别由传统分类和排队方法组合在一起的数据包流。关于流或会话的应用类别或具体应用的信息可通过分类信息330传递到调度器参数计算模块335。增强型分类可在传统分类之后执行为如图10示出的单独的步骤，或者可并入如图9示出的传统分类步骤，从而提供更详细的分类供在调度组内使用。

除非特别说明，否则图9的元件如相对于图6描述地操作。然而，增强型包检查模块410′执行本文描述的增强型数据包检查技术。如图9示出，在一些实施方案中，增强型包检查模块410′产生附加数据队列491′、495′和495″。

除非特别说明，否则图10的元件如相对于图6描述地操作。除了包检查模块410，还提供增强型包检查模块410′。在一个实施方案中，增强型包检查模块410′在已被分类为不同调度组的数据包上操作。虽然示出为分开的模块，但是应理解，包检查模块410和增强型包检查模块410′可实施为单个模块。如图示出，在一些实施方案中，增强型包检查模块410′产生附加数据队列491′、495′和495″。

根据实施方案，可在增强型分类和排队模块310′的增强型包检查模块410′中实施本文公开的增强型分类步骤。例如，双向视频会议、单向视频流、在线游戏和语音是一些不同应用类别的实例。具体应用指的是用以产生在源和目的地之间行进的数据流的实际软件。一些实例包括：YouTube、Netflix、Skype和iChat。每个应用类别可具有许多具体应用。图11提供的表示出了应用类别被映射到具体应用的一些实例。

根据实施方案，增强型分类和排队模块310′可检查IP源地址和目的地址以确定数据流的应用类别和具体应用。使用IP源地址和目的地址，增强型分类和排队模块310′可执行反向域名系统（DNS）查找或互联网WHOIS查询以建立域名和/或采购或接收基于互联网的流量的登记的受让人。域名和/或登记的受让人信息然后可用以基于域或受让人的目的先验知识来建立数据流的应用类别和具体应用。应用类别和具体应用信息一旦得出就可存储供重复使用。例如，如果一个以上的用户设备访问Netflix，那么增强型分类和排队模块310′可被配置来缓存所述信息，使得增强型分类和排队模块310′将不需要确定同一用户设备或另一用户设备通过网络对Netflix的后续访问的应用类别和具体应用。

例如，如果具有特定IP地址的流量产生包括名称‘Youtube’的反向DNS查找或WHOIS查询，那么所述流量流可被认为是使用Youtube服务（具体应用）的单向视频流（应用类别）。根据实施方案，可维持域名或受让人和应用类别和具体应用之间的综合映射。在实施方案中，所述映射被定期更新以保证映射保持最新。

根据另一实施方案，增强型分类和排队模块310′被配置来检查与各种通信协议相关的数据包的标头、有效载荷字段或两者，并将其中含有的值映射到应用类别或具体应用。例如，根据实施方案，增强型分类和排队模块310′被配置来检查含有在HTTP标头中的Host字段。Host字段通常含有域或受让人信息，如以上实施方案中所描述，所述域或受让人信息用以将所述流映射到特定应用类别或具体应用。例如，HTTP标头字段“v11.lscache4.c.youtube.com”可由分类器检查并映射到应用类别=视频流、具体应用=Youtube。

根据另一实施方案，增强型分类和排队模块310′被配置来检查超文本传输协议（HTTP）数据包内的‘内容类型’字段。基于多用途互联网邮件扩展（MIME）格式中指定为由互联网工程任务组（IETF）定义的定义，内容类型字段包括有关有效载荷的类型的信息。例如，以下MIME格式将指示单播或广播视频数据包流：视频/mp4、视频/quicktime、视频/x-ms-wm。在实施方案中，增强型分类和排队模块310′被配置来将HTTP包映射到视频流应用类别（如果增强型分类和排队模块310′检测到HTTP包内的这些MIME类型中的任何类型）。

在另一实施方案中，增强型分类和排队模块310′被配置来检查先于数据流发送的协议。例如，增强型分类和排队模块310′可被配置来基于用以设置或建立数据流的协议来识别应用类别或具体应用，而并非使用用以传输数据流的协议来识别这个信息。也就是说，增强型分类和排队模块310′可通过分析控制数据包流而不是与连接层1440相关的信息来识别应用类别或具体应用。根据实施方案，先于数据流发送的协议用以识别关于应用类别、具体应用和特征的信息，所述应用类型、具体应用及特征允许启动后立即能够识别传输数据量的连接。

例如，在实施方案中，增强型分类和排队模块310′被配置来检查可用以建立多媒体流会话的实时流协议（RTSP）包。RTSP包被囊封于TCP/IP帧内且载送于IP网络上，如图12中的基于以太网系统示出。

RTSP（H.Schulzrinne等人所著的IETF RFC 2326，Real TimeStreaming Protocol（RTSP））建立并控制多媒体流会话，其中客户端与服务器交换消息。从客户端发送到服务器的RTSP消息是请求消息。请求消息的第一行是请求线。请求线是由以下3个元素形成：（1）方法；（2）Request-URI；和（3）RTSP-Version（RTSP-版本）。

RTSP定义了包括OPTIONS、DESCRIBE、ANNOUNCE、SETUP、PLAY、PAUSE、TEARDOWN、GET_PARAMETER、SET_PARAMETER、REDIRECT和RECORD的方法。下文是使用方法DESCRIBE的客户端（“C”）与服务器（“S”）之间的消息交换的实例。来自服务器的响应消息具有消息主体，其与具有空白线的响应消息标头相分离。

RTSP消息中的Request-URI始终含有如RFC2396中定义的绝对URI（T.Berners-Lee等人所著的IETF RFC2396，“Uniform ResourceIdentifiers(URI):Generic Syntax”）。RTSP消息中的绝对URI含有网络路径及资源在服务器上的路径。以下是上文列出的消息中的绝对URI。

rtsp://s.companydomain.com:554/dir/f.3gp

RTSP-Version指示RTSP消息中使用了哪个版本的RTSP规格。

在一个实施方案中，增强型分类和排队模块310′被配置来检查RTSP请求消息中的绝对URI并提取网络路径。网络路径通常含有域或受让人信息，如以上实施方案中所描述，所述信息用以将流映射到特定应用类别或具体应用。例如，RTSP绝对URI“rtsp://v4.cache8.c.youtube.com/dir_path/video.3gp”可由分类器检查并映射到应用类别=视频流、具体应用=Youtube。在一个实施方案中，增强型分类和排队模块310′检查从客户端发送到服务器的数据包，以便对从服务器发送到客户端的相关数据包进行分类。例如，从客户端发送的RTSP请求消息的信息可用于对来自服务器的响应进行分类。

RTSP协议可借助使用使用PLAY功能中发信号的Range参数来指定视频会话的回放时间的范围。请求可包括时间的有界（即—开始、停止）范围或时间的开端式范围（即，仅开始时间）。时间范围可使用正常回放时间（npt）、smpte或clock参数来指示。Npt时间参数可以hours:minutes:seconds.fraction（时:分:秒.分数）格式表达或根据ISO8601格式时间戳的绝对单位来表达。Smpte时间值以hours:minutes:seconds.fraction格式表达。Clock时间值以根据ISO 8601格式时间戳的绝对单位来表达。Range参数用法的实例如下所示：

Range：npt＝1:02:15.3-

Range：npt＝1:02:15.3-1:07:15.3

Range：smpte＝10:07:00-10:07:33:05.01

Range：clock＝19961108T142300Z-19961108T143520Z

在一个实施方案中，增强型分类和排队模块310′被配置来检查RTSP消息并使用npt、smpte或clock字段从视频流提取Range信息。本领域技术人员应理解，RTSP包内的npt、smpte和clock参数可使用替代语法来传达上文所描述的信息。

RTSP协议包括用以传达在服务器与客户端之间的多媒体会话的细节的DESCRIBE功能。所述DESCRIBE请求基于指定请求的信息的内容和格式的会话描述协议（SDP在RFC 2327和取代RFC 2327的RFC 4566中定义）。使用SDP，m-field定义介质类型、网络端口、协议和格式。例如，考虑以下SDP介质描述：

m＝audio 49170 RTP/AVP 0

m＝video 51372 RTP/AVP 31

在第一实例中，音频流是使用用于端口49170上的数据传输的实时协议（RTP）来描述，且基于RTP音频视频资料（AVP）号0中描述的格式。在第二实例中，视频流是使用用于端口51372上数据传输的RTP来描述，且基于RTP音频视频资料（AVP）号31。

在两个RTSP实例中，m-field足以将数据流分类到特定应用类别。由于m-field读取通信协议（RTP）和IP端口号，所以随后的数据流可被识别并映射到刚刚导出的分类信息。然而，仅借助该信息无法分类为具体应用。

从服务器返回到客户端的SDP消息可包括附加字段，其可用以提供关于应用类别或具体应用的附加信息。

SDP消息含有RTP中传输的视频流和音频流的有效载荷类型。一些RTP视频有效载荷类型在RFC 3551中定义（H.Schulzrinne等人所著的IETF RFC 3551，“RTP Profile for Audio and Video Conferenceswith Minimal Control”）。例如，MPEG-1或MPEG-2基础视频流的有效载荷类型是32，且H.263视频流的有效载荷类型是34。然而，一些视频编解码器（诸如，H.264）的有效载荷类型是动态分配的，且SDP消息包括视频编解码器的参数。在一个实施方案中，视频编解码器信息可用于对视频数据流进行分类，并基于视频编解码器特征而以不同方式处理视频流。

SDP消息也可含有在RFC 4566中定义的属性“a=framerate:<frame rate>”，其指示视频的帧率。SDP消息还可包括属性“a=framesize:<playload type number><width><height>”，所述属性在3GPP PSS（3GPP TS 26.234，“Transparent End-to-EndPacket-switched Streaming Service,Protocols and Codecs”）中定义，所述属性可包括在SDP消息中以指示视频的帧大小。由于历史的原因，一些应用可使用诸如“a=x-framerate:<frame rate>”或“a=x-dimensions:<width><height>”的非标准属性来传递“a=framerate:<frame rate>”和“a=framesize:<playload type number><width><height>”中的类似的信息。在一个实施方案中，增强型分类和排队模块310′被配置来检查SDP消息并提取视频的帧率或视频的帧大小或两者（如果对应字段存在），并使用帧率或帧大小或两者来提供关于将流映射到特定应用类或具体应用的附加信息。

在一个实施方案中，增强型分类和排队模块310′直接检查网络数据包，以便检测在两个端点之间流动的这些数据包是否含有使用RTP协议（H.Schulzrinne等人所著的IETF RFC 3550，“RTP:A TransportProtocol for Real-Time Applications”）载送的视频数据，且增强型分类和排队模块310′执行这个操作而无需检查SDP消息或任何其它含有描述RTP流的信息的消息。例如，当SDP消息或另一含有类似信息的消息未传递通过增强型分类和排队模块310′时，或者增强型分类和排队模块310′的某个实施方式选择不检查这类消息时，这种情况可能发生。RTP流是在两个端点之间流动并使用RTP协议载送数据的数据包流，且端点由（IP地址、端口号）对定义。

图13是增强型包检查模块410′的实施方案的功能框图。在所述实施方案中，增强型包检查模块410′包括RTP流检测模块7110和视频流检测模块7120，以用于检测UDP或TCP包是否含有使用RTP协议传输的视频数据。增强型包检查模块410′也可实施通常由另一逻辑模块7100表示的其它功能。在一个实施方案中，增强型包检查模块410′接收沿两个方向流动的输入流量，并使用来自沿一个方向流动的数据包的信息对沿另一方向流动的数据包进行分类。增强型包检查模块410′可从另一模块接收关于沿另一方向流动的流量的信息而并不接收流量本身。

RTP流检测模块7110根据RTP包标头的格式来解析UDP或TCP有效载荷的最初若干比特，并核查RTP标头字段的值以确定在两个端点之间流动的流是否是RTP流。

图14是示出RTP包的示例性结构的图表，RTP包包括RTP标头和RTP有效载荷。在图14中，例如，RTP有效载荷含有H.264视频数据。RTP标头格式不依赖于RTP有效载荷中载送的介质类型，而RTP有效载荷格式是介质类型特定的。如果UDP或TCP包的有效载荷含有RTP包，那么RTP标头中若干字段的值将具有特殊样式。下文列出所述特定样式中的一些作为实例。参看图14括号中的短名称。RTP流检测模块7110可使用这些样式中的一个、这些样式的组合或下文未列出的其它样式来确定流是否是RTP流。

字段“RTP version”（“V”）总是2。

如果字段“padding bit”（“P”）被设置为1，那么数据包的最后八位字节是填充长度，该填充长度是填充在数据包尾的八位字节的数量。图15示出在数据包尾具有填充的八位字节的所述RTP包。填充长度不能超过RTP有效载荷的总长度。

字段“playload type”应保持不变。

字段“sequence number”在2个连续数据包之间大部分的时间应增加1。当所述数据包重新排序，或者一个数据包被丢弃或者序列号滚动时，序列号有间隙。所有的这些状况在正常运行时应发生相对较少。

字段“timestamp”应具有特殊样式，其取决于介质类型，如下文参看视频流检测模块7120所进行的详细描述。

如果检测到流是RTP流，那么视频流检测模块7120将对RTP包标头字段和RTP有效载荷执行进一步的检查，以检测RTP流是否载送视频且哪个视频编解码器生成视频流。

与视频相关的一些RTP有效载荷的有效载荷类型在RFC 3551中定义。然而，对于具有动态分配的有效载荷类型的视频编解码器，编解码器参数包括于SDP消息中。然而，SDP消息可能不可用于视频流检测模块7120。

如果视频流检测模块7120检测到有效载荷类型是动态分配的，那么它收集关于流的统计数据。例如，可收集RTP标头字段“时间戳”的值、RTP包大小及RTP包数据率的统计数据。视频流检测模块7120可随后使用所收集的统计数据中的一个或统计数据的组合来确定RTP流是否载送视频数据。

视频流通常具有良好定义的帧率，诸如，24FPS（帧每秒）、25FPS、29.97FPS、30FPS或60FPS等。在一个实施方案中，视频流检测模块7120至少部分地基于RTP包时间戳的值是否以在普通帧时间距离的整数倍（普通帧率的倒数）内变化来检测RTP流是否载送视频数据。

与音频流相比，视频流通常具有较高的平均数据率且其瞬时数据率具有较大波动。在另一实施方案中，视频流检测模块7120至少部分基于平均RTP数据率的量值和瞬时RTP数据率的波动来检测RTP流是否载送视频数据。

RTP有效载荷格式特定于介质。例如，RTP包中的H.264有效载荷始终以NAL单元标头开始，所述NAL单元标头的结构在RFC6814（Y.K.Wang等人所著的IETF RFC 6184，“RTP Payload Format forH.264Video”）中定义。在一个实施方案中，视频流检测模块7120至少部分基于RTP有效载荷的最初若干比特的样式来检测哪个视频编解码器产生RTP流中载送的视频数据。

增强型排队

根据实施方案，增强型分类和排队模块310′也可被配置来实施增强型排队技术。如上所述，增强型分类一旦完成，增强型分类和排队模块310′可基于使用上述增强型分类技术所导出的附加信息而将数据包分配给一组增强型队列。例如，在实施方案中，数据包可通过以下各项分配给一组队列：应用类别、具体应用、个别数据流或其一些组合。

在一个实施方案中，增强型分类和排队模块310′被配置来使用包括用于每一应用类别的唯一队列的调度组。例如，LTE eNB可将所有QCI=6数据包分配到单个调度组。但是使用增强型排队，QCI=6内已分类为视频聊天的数据包可被分配到一个队列，而分类为语音的数据包可被分配到不同的队列，从而允许区别调度。

在另一替代实施方案中，增强型分类和排队模块310′被配置来使用包括用于每一具体应用的唯一队列的调度组。例如，实施增强型排队的LTE eNB可将分类为含有Youtube串流视频的QCI=9数据包分配到一个调度队列，而将分类为Netflix串流视频的数据包分配到不同的调度队列。即使上述应用是相同的应用类别，在这个实施方案中数据包可被分配了不同的队列，因为上述应用是不同的具体应用。

在又一实施方案中，增强型分类和排队模块310配置使得调度组可由用于每一数据流的唯一队列组成。例如，LTE eNB可将所有QCI=9数据包分配到单个调度组。基于上述增强型分类方法，每个数据流被分配唯一队列。例如，考虑调度组为五个移动电话用户提供服务的示例性实施方案，每个移动电话用户运行两个具体应用。在一个实施方案中，如果每个移动设备的应用被映射到移动设备的默认无线电载体，那么这将导致五个队列（每一队列用于一个移动设备）载送使用原始分类和排队模块的异构数据。然而，在一个实施方案中，支持十个数据流的增强型分类和排队模块310创建十个队列。在替代性实例中，五个移动设备中的每一个设备具有使用相同具体应用的两个数据流。在这种情况下，数据流还可基于（例如）端口号或会话ID而分类为独立队列，从而产生十个队列。

上述增强型分类和排队技术可用以改良无线或有线网络通信系统中的排队。本文公开的技术可与其它用于将数据包分配到队列以提供改良排队的方法相组合。

应用因子

根据实施方案，调度器参数计算模块335被配置来当计算调度器参数时使用增强型策略信息以解决上述一些权重或信用计算技术的QoE缺点。根据实施方案，增强型策略信息350可包括基于应用类别和具体应用分配重要性的定量等级和相对优先级。本文的所述因子为应用因子（AF），且AF的目的是向运营商提供调整相对重要性且最终调整增强型分类和增强型排队之后队列的调度参数的方法。在另一实施方案中，AF是通过使用不需要运营商参与的内部算法或默认算法来建立的。

图16是根据实施方案示出在每个应用类别和每个具体应用基础上的示例性AF分配的表。在不可能识别数据包或数据流载送的具体应用的情况下，可对应用类别内‘未知’类别进行AF分配。为了优化QoE的吞吐量和延迟敏感应用，已向视频和语音应用分配了比后台数据和社交网络流量（AF在范围0-2中）高的AF值（除了一个以外都是6或更高）。

在视频聊天类别中，运营商可能发现一个视频聊天服务（例如，iChat）实质上比另一视频聊天服务（例如，Skype视频）更繁重（例如，需要更多容量、具有更少的延迟或抖动容限），且可试图通过向Skype视频聊天分配比iChat高的AF值（8比5）来鼓励使用更加网络友好的应用。

类似地，运营商可能以认为查看简短免费的服务（例如YouTube视频）是不重要的为代价而通过调整与这些服务相关的AF来决定维护例如Netflix的有偿服务的QoE。已经与具有高的AF（分别是8和6）的运营商战略地结合的运营商可能期望有容量来增强某些语音服务（例如，Vonage的Skype音频），同时给所有剩余（即，非战略的）的语音服务分配极低的AF 1。

本领域技术人员应理解，不同AF值可用以创建特定应用类别和具体应用之间的不同和改变的权重或信用关系。本领域技术人员也应理解可如何添加图16示出的应用类别和具体应用之外的附加应用类别和具体应用。

另外，本领域技术人员应理解，可基于节点类型和/或节点位置不同地分配AF。例如，服务郊区、住宅区域的LTE eNB可被配置来使用一组AF，而服务高速公路的LTE eNB可被配置来使用一组不同的AF。

调度参数

根据实施方案，增强型调度器参数计算模块335也可被配置来实施用于确定权重或信用因子的增强型技术。如上所述，一些权重或信用计算算法可基于各种输入调整个别队列的调度参数。例如，在图5示出的参数化调度器模块中，调度器参数计算模块335可被配置来基于各种输入来计算新的调度器参数，包括分类信息330、可选运营商策略和SLA信息350，和可选调度反馈信息345（例如，从调度器模块320接收的流历史）。

根据实施方案，增强型调度器参数计算模块335可使用附加权重和信用计算因子来提高QoE性能。例如，在实施方案中，附加权重因子可用以产生如下示出的增强型权重（W′）：

W′(q)=a*W(q)+b*AF(q)

其中：

W′=增强型队列权重

q=队列索引

W=使用常规权重计算导出的队列权重

a=系数映射W到W′

AF=应用因子

b=系数映射AF到W′

例如，在实施方案中，图17示出了在单个队列、尽力调度组内具有5个活动流（由流索引i指定）的LTE eNB基站（例如，在LTE中，QCI=9）。由于常规技术中描述的缺点，所以在所述调度组中，有许多应用类别和具体应用被分配到单个队列。在该实例中，所有数据包被分配到相同的队列，从而导致调度器在应用类别和/或具体应用之间没有形成区别。

例如，流#1的Facebook请求和流#4的Skype视频聊天会话都被分配到同一队列。因为来自两个流的数据包在同一队列中，所以两个流必须以非差异化的方式共享由调度器提供的资源。例如，数据包可从单个队列以FIFO方法来服务，从而从两个流创建数据包的“第一个到达”的服务。这在网络拥塞期间是不理想的，由于视频聊天会话就用户QoE而言对包延迟或丢弃比对Facebook更新更敏感的事实。

相反，如果应用上述增强型权重计算技术（可在增强型调度器参数计算模块335中实施），那么五个流中的每一个（在图17中由索引i指定）可被分配到唯一队列（在图17中由索引q指定）。每个队列然后可被分配有唯一增强型权重作为应用类别和具体应用的函数。例如，图17中列W1和W2展示假设每个数据流i被分配到唯一队列q，基于应用类别、具体应用和图16示出的AF的增强型队列权重计算结果。

使用W′的方程（上文描述）来计算每个流的权重W1和权重W2，其中系数‘a’设置为1，且系数‘b’分别设置为0.5和1。也就是说：

W1(q)=W(q)+0.5*AF(q)

W2(q)=W(q)+AF(q)

可通过再次将数据流#1与流#4进行比较看出计算的影响。对于W1，视频聊天流的权重为7，现在大于Facebook流的权重4。由于在W2的计算中，系数‘b’增加到1.0，流#4和#1之间的权重差进一步增加（分别为11和5）。

对于W1和W2的实例，Skype流将分配有比Facebook流多的资源。这增加了Skype会话将受到调度器偏爱的可能性且可在网络拥塞期间改进会话性能和QoE。虽然这以牺牲Facebook会话为代价，但是代价是不对称的：包延迟/丢弃比起视频聊天会话的相当的数据包处理将对于Facebook会话具有较小影响（即，不太明显）。因此，应用认知调度系统已提供相对于终端用户QoE的更优化的响应。

在替代性实例中，图17中的每个数据流用于不同的移动设备，且可在QCI9的调度组内不同的队列中。在一些系统中，分配到每个队列的权重将不考虑具体应用或应用类别。然而，如本文描述，在一些实施方案中，权重被区别对待。

类似地，可使用公式C′(q)=a*C(q)+b*AF(q)来计算增强型每调度轮信用的基于信用的调度算法，其中在增强型权重计算公式中，C（表示信用）代替W（表示权重）。在每个调度轮，所述增强型信用将添加到队列的积累信用（可能为上限），而分配的带宽将从积累信用借记。对于基于信用和权重的计算，以相同的方式使用AF，但是由于调度算法中使用的权重和数据率之间的典型范围差，所以在基于信用的方程和基于权重的方程中，AF的范围可不同。

本领域技术人员也应认识到，上述系统和方法可延伸到队列包括来自一个以上的数据流、一个以上的具体应用、一个以上的应用类别或其组合的数据包的情况，对于所述情况，总调度可能合适。例如，增强型权重或信用可被分配到包括由三个不同手机产生的三个Skype/视频聊天数据流的队列。另外，上述系统和方法可适用于一个或多个调度组中的所有队列或只是队列的子集。例如，增强型参数计算和增强型排队可适用于LTE QCI=9调度组，但是已知参数计算可适用于LTE QCI=l-8调度组。另外，系数‘a’和‘b’的映射可被调整为调度组或队列的替代分组的函数。例如，系数‘b’对于包括LTE QCI=9队列的调度组可设置为1，而对于LTE QCI=8队列设置为0.5。

时变应用因子

根据实施方案，增强型调度器参数计算模块335也可被配置来将应用因子（AF）从常数扩展到一个或多个时变函数AF(t)。根据一些实施方案，基于预设调度来调整AF。运营商可能期望在一天当中对应用进行一次特定处理而在其它时间进行不同的处理。

例如，在一个实施方案中，增强型调度器参数计算模块335被配置来尤其对于提供传输路由的单元和部分在典型的上下班时间使用“rush hour”AF值，其中语音通话是在移动网络上运行的主要应用。对于这些时间（例如，周一至周五，7am到9am和4pm到7pm），所有语音应用被分配有AF=10，从而改善了服务等级高于所有其它应用（参看图16）。在所述时间段之外，增强型调度器参数计算模块335被配置来还原为常规AF值。

在另一实例中，增强型调度器参数计算模块335被配置来在最有可能使用过多（OTT）视频服务期间与所述服务连用较大AF值。例如，增强型调度器参数计算模块335被配置来尤其对于服务住宅区域的网络，在周末的晚上使用较大AF值。再次参看图16，例如，OTT视频的峰值设置可包括在周五和周六的7-1lpm之间将视频流应用（例如，未知视频流和Netflix）设置为AF=10。

具体应用类或具体应用的数据的总体数量可用于计算并分配AF。例如，如果所有数据都来自同一具体应用，那么可能不需要调整AF，因为所有流将保证同等的用户体验（然而，即使这样，例如帧每秒或每流的数据速率的特征仍可用以如下文所述修改AF）。如果有极少的数据需要高质量的用户体验，例如只有一个活动Netflix会话而所有其它数据都是电子邮件，那么Netflix流的AF可增加比保证最优质的体验（例如，最少的数据包丢失）可能情况下正常多得多，从而知道所有或大多数其它数据是延迟容忍的且可具有内置的重传机制。在替代性实施方案中，AF被计算作为同质或类似数据流需要的总的可用带宽的百分比的函数。例如，Netflix流可始于高AF，但是随着更高百分比的数据使用量被Netflix消耗，所有Netflix流的AF可降低，或者新的Netflix流的AF可降低，而现有Netflix流的AF不变。

本领域的普通技术人员将认识到，定期的、基于调度的AF调整可基于任何循环周期，包括但不限于，一天中的时间、一周中的一天、潮汐、季节和节假日。另外，在实施方案中，增强型调度器参数计算模块335被配置来使用非循环的调度来响应于地方体育、商业和社区活动或其它一次性调度的事件而调整AF。根据一些实施方案，AF值可由网络运营商手动被配置来进行非循环的调度。根据其它实施方案，增强型调度器参数计算模块335被配置来获取存储在网络上（或者，在一些实施方案中，推到实施增强型调度器参数计算模块335的网络节点上）的事件信息，且增强型调度器参数计算模块335可根据事件的类型自动更新AF值。根据实施方案，增强型调度器参数计算模块335也可被配置来实时更新AF值以适应突发事件，包括天气变化、自然灾害或其它灾害或执法/军事活动。

依赖于应用特征的应用因子

根据实施方案，增强型调度器参数计算模块335可被配置来将应用因子（AF）从应用类别和具体应用的函数延伸到也依赖于应用特征。根据一些实施方案，基于视频帧大小、视频帧率、视频流数据率、视频流的持续时间、相对于视频流数据的总量传递的数据量、视频编解码器类型或所述视频应用特征中任何应用特征的组合进一步调整AF。

在实施方案中，优化标准是增加满意用户的数量。基于这个标准，视频数据流的AF由与视频流的数据率成反比的量来调整。较低的AF可在拥塞期间产生将比使用较高AF时丢弃的数据包更多的丢弃的数据包。对于类似量的质量下降，降低较高数据率的视频流的AF可比降低较低数据率的视频流的AF释放更多的网络带宽。在拥塞期间，优选的是先降低较高数据率的视频流的AF，所以可最大化满意用户的数量。

在实施方案中，优化标准是最小化不完美的数据包传输产生的可感知的视频假影。在这个标准下，视频流的AF调整了与帧大小成正比但与帧率成反比的量。例如，较低的AF可在拥塞期间产生将比使用较高AF丢弃的帧更多的丢弃的帧。比起以每秒30个帧操作的视频流的个别帧，以每秒60个帧操作的视频流的个别帧是在给定时间段的数据的较少百分比。由于以每秒60个帧操作的视频流中帧的丢失比起以每秒30个帧操作的视频流中帧的丢失不太明显，所以以每秒30个帧操作的流可给予比以每秒60个帧操作的流更高的AF。

在实施方案中，可将数据流的AF动态调整与剩余将被传递的数据成正比的量。例如，如果刚开始数据传输，那么较低的AF可被分配到数据流。另举一例，如果整个数据流的传送将要结束，那么较高AF可被分配到数据流。

在实施方案中，视频数据流的AF被调整了依赖于检测到的视频编解码器类型的值。较低的AF可被分配到对于数据包丢失更加鲁棒的视频编解码器。例如，SVC（H.264可伸缩视频编码扩展）视频流可被分配有比非SVC H.264视频流低的AF。

在实施方案中，视频数据流的AF基于视频数据流的持续时间、视频数据流中剩余的时间量或其组合来调整。例如，运营商可确定比起较短的10秒钟的Youtube片段，将较高AF分配到全长Netflix电影，因为比起简短的视频片段，客户对于长篇电影的质量可具有更高的期望。在另一实例中，运营商可确定比起刚开始的视频数据流，将较高的AF动态分配到即将完成的视频数据流，以使观看完视频数据流的客户具有最好的印象（参看下文描述的近因效应）。

描述视频数据流的持续时间的信息可使用上述增强型分类方法来获得，包括RTSP消息交换期间指示的Range信息。关于视频数据流中剩余的时间量的信息可例如通过从Range信息中指示的停止时间减去当前视频回放时间来计算。当前视频回放时间也可通过检查个别视频帧或通过维持在回放开始重置的自由运行的时钟来获得。本领域技术人员应理解，可能有替代性的方法来获得当前视频回放时间。

在实施方案中，视频数据流的AF是基于用以显示视频数据流的特定客户端设备或设备类别来调整的。设备类别可包括手机、智能手机、平板计算机、膝上型计算机、PC、电视或用以显示视频数据流的其它设备。设备类别还可被分为子类别以包括特定容量。例如，具有WiFi容量的智能手机可与不具有WiFi容量的智能手机不同地对待。

特定设备可表示制造商、型号、配置或其一些组合。苹果iPhone4（智能手机）或摩托罗拉Xoom（平板计算机）是特定设备的实例。

客户端设备类别、子类别或特定设备可使用各种方法得出。在实施方案中，设备类别可使用如上所述的视频帧大小得出。例如，HTC霹雳（Thunderbolt）智能手机使用800像素×480像素的屏幕分辨率。增强型包检查模块410′可使用上述方法来检测或估计这个值并基于关于每个设备类别或特定设备使用的屏幕分辨率的范围的先验知识来确定设备类别。

在实施方案中，关于设备类别、子类别或特定设备的信息在网络上客户端设备和实体之间传递。例如，在无线网络100中，当客户端设备最初加入网络时，客户端设备150可将描述供应商和型号的信息发送到核心网络102。该信息可例如由基站110的增强型包检查模块410′获得供在以后的时间使用。

一旦获得，设备类别、子类别或特定设备可用以基于运营商设置调整AF。例如，在图16中，如果设备类别被确定为大屏幕电视（其中对高品质回放的期望被视为关键），那么Netflix（具体应用）的AF可从7上升到9。

在实施方案中，AF可进一步被通过运营商策略/SLA 350传递的一个或多个服务等级修改。例如，运营商可出售手机Netflix程序包，其中客户支付附加费用以在手机上支持改良的视频体验（例如，质量、数量、访问）。对于参与所述计划的客户，运营商可分配图16中示出的视频流应用类别的增加的AF。例如，Netflix AF可从7增加到9，Youtube AF可从4增加到7，且未知视频流类别AF可从5增加到7。另外，SLA可用以区别客户，从而管理特定客户的数据是否有资格通过AF修改接收优待。本领域技术人员应认识到，根据服务等级调整AF可结合或可不结合设备类别、子类别或特定设备使用。

除了直接向终端用户出售零售服务以外，网络运营商可另外或替代地向第二运营商（称为虚拟网络运营商或VNO）批发出售网络容量，所述第二运营商然后可向终端用户出售零售服务。例如，移动网络运营商X可建立和维持无线网络并确定将网络容量的某一部分出售给运营商Y。运营商Y随后可创建提供给公众的零售服务，所述零售服务使用运营商X容量以提供服务，这对于终端用户可能不知情。

在实施方案中，AF可进一步由可使用网络上的容量的VNO的存在修改。例如，运营商X可具有两个VNO客户：Y和Z，每个都具有不同的服务协议。如果运营商X同意向VNO Y提供比VNO Z好的服务，那么对于给定设备类别、应用类别和具体应用，与VNO Y客户相关的数据流可被分配有比与VNO Z客户相关的流高的AF。在另一实例中，运营商X可直接向终端用户出售零售服务且签订合同以向VNO Y出售服务。在这种情况下，运营商X可选择通过向与它的客户相关的流分配比与VNO Y客户相关的流的更大的AF来向它的客户提供更高的服务等级。增强型分类方法可用以识别与不同VNO客户相关的流量，例如包括检查IP网关地址、VLAN ID、MPLS标签或或它们的一些组合。本领域技术人员应认识到可能存在其它方法来在VNO客户和运营商之间分离流量。

持续时间忽视和近因效应

另一种增强权重功能的方法将映射系数b扩展到在每队列基础上分配的时变功能。即，b是时间（t）和队列（q）的函数，b(q,t)。在一个实施方案中，响应于载送视频数据流（流或双向）的流的调度器决定，或先于载送视频数据流（串流或双向）的流的调度器决定，实时调整b(q,t)，其中每个数据流在唯一队列上。所述实施方案可通过利用如Aldridge等人和Hands等人描述的近因效应（RE）和持续时间忽视（DN）概念来进一步减小最大负载而具有最小的QoE损失，参看Aldridge,R.；Davidoff,J.；Ghanbari,M.；Hands,D.；Pearson,D.所著的“Recency effect in the subjective assessment of digitally-codedtelevision pictures”Image Processing and its Applications，1995.，FifthInternational Conference on,vol.,no.,pp.336-339,4-6 July 1995和Hands,D.S.；Avons,S.E.所著的“Recency and duration neglect insubjective assessment of television picture quality”Journal of AppliedCognitive Psychology，vol.15,no.6,pp.639-657,2001，所述内容以引用方式并入本文。

DN的概念是视频回放期间查看的减值的持续时间不如它的严重程度那么重要。因此，对于传输通过多用户、容量受限的网络的视频，已丢弃了来自视频流的一个或多个视频包的调度可能优选地（从QoE的角度看来）继续丢弃来自所述流的数据包，而不是选择丢弃来自另一视频流的数据包，只要丢包率不超过预设阈值即可。例如，基于DN概念，对于5个不同视频流中的每一个，在10秒内丢弃单个视频流的5%的数据包比起在2秒内丢弃5%的数据包提供改良的网络QoE。

RE的概念是视频回放的观众在某一时间量后往往会忘记视频减值而因此基于最近观看时间段判断视频质量。例如，如果在视频片段的最近15秒内视频暂停（即，停止回放）达2秒，那么观众可将视频回放主观判断为“差”；而如果相同的2秒减值发生在视频片段结束前1分钟，那么观众将回放判断为“一般”。

为达这个目的，在每队列（且在这个情况下，每数据流）基础上，使用图18示出的时序图和图19示出的方法来管理增强型权重方程（W′(q)=a*W(q)+b*AF(q)）或增强型信用方程（C′(q)=a*C(q)+b*AF(q)）的系数‘b’。根据DN的概念，丢失了数据包的视频流可“容忍”附加适度的数据包丢失（或某个其它评价指标）而不会大幅下降用户QoE。这个下降的扩展缓解了部分或可能全部的网络拥塞，因此有利于可被提供未被降级的服务的剩余用户流。在降级期间之后，根据RE的概念，视频流被提供有增加的性能达某一时间段。

如图18示出，在有意降级期间，b(i)的值被从标称值b0向下调整了量Δ1达时间段tdn。之后是增强期间，其中b(i)增加了大于b0的Δ2（Δ2可为0）。该增强时段段持续了时间段tre的剩余部分，此后系数b(i)返回到其正常值=b0。

图19示出根据实施方案用于在调度系统中将权重或信用分配到队列的方法。在实施方案中，图19示出的方法在调度器参数计算模块335中实施。

图19示出的方法始于根据策略分别将增强型权重或信用方程的系数a和b设置为a0和b0（步骤1105）。然后评价一个或多个算法准入条件（步骤1110）。在一个实施方案中，算法准入条件是来自调度的由于网络中当前或预测拥塞等级而视频流i必须发起算法的信号。在替代性实施方案中，准入条件基于调度从视频流i检测到一个或多个丢弃或延迟的数据包。本领域技术人员应认识到，可使用调度和分类信息的各种组合来创建附加准入条件。本领域的普通技术人员还应认识到，准入条件可基于满足一个或多个标准，所述标准基于各种形式的信息，包括触发器、警报、阈值或其它方法。

一旦满足准入条件，就发起两个阶段的定时算法。流时间被重置为零（步骤1120）且b(i)的值减小了量Δ1（步骤1130）。

确定当前帧丢弃率是否超过流i的阈值（步骤1140）。例如，在实施方案中，阈值被设置为在1秒内为5%。在其它实施方案中，可基于流的期望的性能特征来设置所述流的不同阈值。

如果流的帧丢弃率超过阈值，那么有意降级阶段终止且方法以步骤1155继续。否则，如果帧丢弃率不超过阈值，那么确定定时器是否已经达到tdn。如果定时器已达到或超过tdn，那么有意降级阶段终止且方法以步骤1155继续。否则，如果未达到tdn，那么方法返回步骤1140，其中再次确定当前帧丢弃率是否超过流i的阈值。

在再次检查定时器之前，系数b(i)被设置为值b0+Δ2（步骤1155）。确定定时器已达到tre（步骤1160）。如果未达到tre，那么方法返回步骤1160。否则，如果定时器已达到tre，那么方法返回步骤1105。

根据替代性实施方案，通过步骤1160进行的迭代可在时间段tre逐步调整Δ2朝向零。根据另一替代性实施方案，在步骤1140中评价例如包延迟、抖动、预测的视频质量评分（例如VMOS）或或它们的一些组合的替代性（或附加）度量。在又一实施方案中，步骤1140调整使得如果评价指标超过阈值，那么值Δ1被控制减小了量Δ3，然后进行到步骤1150（而不是步骤1155）。

在一些系统中，例如，对于图9中的队列491和491′，识别为来自具有不同调度需要的两个应用的数据可能难以分成不同AF的应用的独立的队列。相反，两个应用的数据将保持在如图6示出的相同的队列491中。例如，这可能在LTE系统中发生，其中来自两个不同应用的数据可被核心网络映射到相同的数据载体。从核心网络装备（例如，移动性管理实体（MME）、服务网关和数据包网关）和UE看来，数据载体是不可分割的且具有当每个数据包通过空中发送时可包括在每个数据包的标头中的载体ID。另外，如果载体在确认模式（AM）下操作，那么属于载体的数据包标记有序列号。将来自两个应用的数据分成不同AF的应用的不同的调度队列可使得它们乱序到达UE。这可使UE与流不同步。延迟的数据包可能假定丢失，从而产生不必要的重传请求。序列号也可部分用于加密和解密数据包。乱序数据包可使加密/解密过程不同步，从而导致所述过程失败。如果序列号乱序，那么它也可影响标头压缩算法的效能，从而减小压缩机制中一个的益处。

可用各种方式来克服这些问题。在一个实施方案中，数据被分成可被给予不同AF的独立的队列491和491′。在这种情况下，优选地将序列号、加密和标头压缩应用于队列的出口，使得数据似乎从单个队列拉出，其中调度顺序似乎是接收顺序。然而，这计算起来很复杂，且处理顺序，尤其是加密，可导致对计算资源的需求严重。在另一实施方案中，不是将队列491分成队列491和491′，而是可基于数据载体上当前载送的应用类别或具体应用的组合而不是个别具体应用类或具体应用来确定队列491的AF。例如，如果视频数据是在逻辑链路或载体上检测的，那么即使载体也可具有定期检查电子邮件更新的后台应用，它也可具有被修改以响应视频的QoE要求的AF。当视频的使用减少时，AF可返回到更适于尽力数据流量的值。这计算起来不太复杂，且在例如串流视频的情况下达到类似的结果，其中当具有很高要求的应用有效时，相同载体上的大多数其它数据（如果有的话）的带宽相对于很高要求的应用将很小。即，当使用应用时，用户将集中于视频、语音、游戏、视频会议，或其它高带宽应用。为了另外防止具有通常要求更高的性能的应用不是载体上的大量数据的情况，例如当电子邮件下载非常大的附件时回放低比特率的YouTube视频，应用因子可为来自具体应用类或具体应用的载体上的流量百分比的函数，而不仅是具体应用类或具体应用。

增强型权重方程W′(q)=a*W(q)+b*AF(q)，和增强型信用方程C′(q)=a*C(q)+b*AF(q)可被进一步修改以也包括附加因子的影响，例如队列的当前状态、通信链路的当前状态，和数据流的附加特征。这可产生以下形式的方程：

W″(q)=a*W(q)+b*AF(q)+c1*F1(q)+c2*F2(q)+...，和

C″(q)=a*C(q)+b*AF(q)+c1*F1(q)+c2*F2(q)+...，

其中W″是经修改的权重且C″是经修改的信用、F1和F2是附加权重或信用因子，且c1和c2是用于将附加因子映射到经修改的权重或经修改的信用的系数。

使用乘法的附加因子而不是加法的附加因子，或加法的和乘法的附加因子（例如，W″(q)=a*W(q)+b*AF(q)*c1*F1(q)+c2*F2(q)+...）的组合来调整权重或信用是可能的，从而允许缩放权重或信用改变。

在实施方案中，队列的权重或信用可基于队列深度来调整。如果提供例如视频或VoIP流的队列达到它的容量的x%，那么权重或信用可动态增加附加因子，直到队列下降到低于x%满，此时增加不再适用。附加因子自身可为应用特定的，例如，其中不同的附加因子比起语音更适用于视频，或者可依赖于服务的数据率。在一些实施方案中，通过在权重和信用增加开始和结束的缓存占用量之间包括Δ来提供滞后。另外，当队列x′%满时，其中x′>x，权重或信用可进一步增加。在又一实施方案中，队列的权重或信用可由与队列深度成正比的因子的部分或全部地调整。除了应用因子（AF）以外或者作为应用因子（AF）的替代，这些技术还允许将附加因子应用到个别流。

在另一实施方案中，队列的权重或信用可基于包丢弃率来调整。如果提供例如视频或VoIP流的队列超过容量且数据包被丢弃，那么就监控丢弃率。通过丢弃率超过阈值，那么权重或信用可动态增加附加因子，直到丢弃终止或下降到低于规定的可接受等级，此时增加不再适用。附加因子自身可为应用特定的，例如，其中不同的附加因子比起语音更适用于视频，或者可依赖于服务的数据率。在一些实施方案中，通过在权重和信用增加开始和结束的丢弃率之间包括Δ来提供滞后。另外，当丢弃率超过更高阈值时，权重或信用可进一步增加。在又一实施方案中，队列的权重或信用可由与包丢弃率成正比的因子的部分或全部地调整。

在实施方案中，队列的权重或信用可基于包延迟来调整。如果提供例如视频或VoIP流的队列的平均（或在某一时间段的最大）包延迟超过阈值，那么权重或信用可动态增加附加因子，直到包延迟下降到低于规定的可接受等级，此时增加不再适用。附加因子自身可为应用特定的，例如，其中不同的附加因子比起语音更适用于视频，或者可依赖于服务的数据率。在一些实施方案中，通过在权重和信用增加开始和结束的平均（或在某一时间段的最大）包延迟之间包括Δ（delta）来提供滞后。另外，当包延迟超过更高阈值时，权重或信用可进一步增加。在又一实施方案中，队列的权重或信用可由与包延迟成正比的因子部分或全部地调整。

在实施方案中，队列的权重或信用可基于包出口率来调整。如果提供例如视频或VoIP流的队列的平均（或在某一时间段的最小）出口率下降到低于规定的可接受等级，那么权重或信用可动态增加附加因子，直到出口率上升到高于规定的可接受等级，此时权重或信用的增加不再适用。附加因子自身可为应用特定的，例如，其中不同的附加因子比起语音更适用于视频，或者可依赖于服务的数据率。在一些实施方案中，通过在权重和信用增加开始和结束的平均（或在某一时间段的最小）出口率之间包括Δ来提供滞后。另外，当出口率下降到低于甚至更低的阈值时，权重或信用可进一步增加。在又一实施方案中，队列的权重或信用可由与出口率成反比的因子的部分或全部地调整。

在快速变化的RF环境中，例如在具有自适应调制和编码的移动网络中，附加因子可用以基于空中因子来快速调整权重和信用。当用户装备具有良好的接收信号质量以从基站进行传输时，例如LTEeNodeB的基站可用更高的数据率且/或具有更高的成功接收可能性将数据发送到用户装备。同样地，当基站具有良好的接收质量以从用户装备进行传输时，用户装备可用更高的数据率且/或具有更高的成功接收可能性将数据发送到基站。如果观察到信号质量高度可变，那么附加因子可适用于当基站和所述用户装备之间的信号质量良好时增加特定用户装备的数据流的权重且当信号质量较差时减小权重，从而向第二用户装备的数据流提供带宽。所述调整可为应用特定的。例如，包括视频的队列的权重可具有适用以保证良好信号质量的最佳使用的附加因子，而相同的用户装备的例如电子邮件的延迟和容错服务可具有不同的因子或者不具有附加适用的因子，这更依赖于内置于例如TCP或LTE协议栈的协议的重试。

除了可响应于上述环境因子而适用于权重或信用的附加因子，权重和信用或修改它们的应用因子可基于使用的传输协议的知识来进一步修改。例如，例如TCP重试、LTE确认模式、自动重试请求（ARQ），或混合ARQ（HARQ）的具有一个或多个可用重试机制的服务可具有适用于数据流的寿命或动态响应于例如信号质量和丢弃率（例如，由于拥塞）的环境因子的不同的附加因子。

在实施方案中，可使用上述技术来检测或估计数据流的平均比特率。其它方法也可取决于应用而可用。例如微软HTTP平滑流、苹果HTTP实时流、Adobe HTTP动态流，和通过HTTP（DASH）的MPEG/3GPP动态自适应流的HTTP流是支持不同比特率的视频流的应用的一个类别。在HTTP流中，每个视频比特流产生为编码器进行的独立解码的电影片段的集合。属于不同比特率的比特流的视频片段对齐回放时间。在统称为播放列表文件或清单文件的一个或多个文件中会话的开始，例如每个比特流的平均比特率和每个片段的回放持续时间的关于比特流的信息被发送到视频客户端（可能是用户装备）。所述信息可由例如基站的网络节点检测。在现场活动的HTTP流中，播放列表文件或清单文件可适用于某些演示期间，且客户端需要获取新的播放列表文件或清单文件来得到关于比特流和比特流中片段的更新的信息。

由于客户端具有关于它将回放的比特流和片段的信息，所以它将基于它的信道条件的当前估计从不同比特率的比特流获得片段。例如，由于感知的信道条件的变化，用户装备中视频客户端可获取来自高比特率的比特流的第一片段，和来自低比特率的比特流的第二片段，以及来自中等比特率的比特流的接下来的两个片段。信道条件常由视频客户端基于例如传输最后的片段或多个先前的片段所用的时间和所述片段的大小的信息来估计。这个方法的一个缺点是视频客户端可能响应速度不够快以快速改变信道条件。在一个实施方案中，例如基站的无线访问节点将当前信道条件发信号到视频客户端，使得客户端可具有关于信道条件的更精确的信息并相应地请求下一片段或以下多个片段。在替代性实施方案中，客户端可从例如图3的站的传输接收模块279的物理层实施接收关于当前信道条件的信息。

在一个实施方案中，包检查模块410（图6、图13）或增强型包检查模块410′（图9、图13）检测HTTP流会话是否存在，并保留播放列表和清单文件的副本。在一个实施方案中，包检查模块通过检测客户端请求获取哪些片段和传递所述片段所用的实际时间来估计某一时间段的数据流的比特率。

基于动态计算或估计的数据流的比特率，可修改队列的权重或信用。在实施方案中，动态计算或估计的比特率被比作队列出口率，且队列的权重或信用用上述技术来调整。另外，在用例如权重不直接基于比特率的WFQ或WRR的基于权重的调度算法调度的调度组中排队数据流的情况下，数据流的队列可使用使信用基于比特率的例如PFS的基于信用的调度技术来移到另一调度组。

包检查模块410可将具体应用的估计的比特率与用于从相关站进行传输的可用信道带宽作比较。瞬时可用的传输带宽可高于来自具体应用的输入流量的比特率。例如，使用以2×2多输入、多输出（MIMO）模式操作的20MHz信道的LTE基站的瞬时数据率约为150Mbps，而串流视频的平均数据率可为2Mbps且峰值数据率可为4Mbps。在一个实施方案中，无线访问节点可缓冲应用的数据并修改调度器参数以用有利的方式来影响瞬时数据率和突发持续时间。

图20示出由参数化调度系统进行的流量整形的实例。参数化调度系统300（图5）从输入通信链路接收传入流量307并通过输出通信链路发送传出流量327。在图20示出的实例中，传入流量307包括来自一个或多个应用的流量。所述流量的部分属于数据流。参数化调度系统300的包检查模块410（或增强型包检查模块410′）可检测来自数据流的包，且另外检测对应于包传递突发持续时间和比特率的传入流量样式390。参数化调度系统300可修改调度参数（或参数）来控制传出流量327的特征。例如，参数化调度系统300可改变更新例如积累信用的其它调度器参数的窗口。这允许将传出包突发的带宽的分配与需要通过输出通信链路传输的传入包突发的可用性更好地对齐。这可结合基于应用类别、具体应用、调制和编码方案或某些组合来修改例如权重和信用的调度器参数。

可组合调度器参数的修改以改变应用的传出流量样式395，从而相对于传入流量样式390具有有高瞬时比特率和短的持续时间的包传递突发。这可具有许多益处。如果调制和编码方案例如由于流动性而快速改变，那么可修改调度器参数来在良好的信号质量期间优先以高速率突发数据，从而通过对于更多数据使用更高效的调制和编码方案有效增加总的系统容量。也可期望增加两个突发之间的空闲时间量，从而可能使用户装备上的接收器进入睡眠模式达较长的时间。这可用以减小用户装备接收器必须打开以从无线访问节点接收数据的时间量。这可降低用户装备的功率消耗。例如，在3GPP HSDPA或LTE中，这可实施以与不连续接收（DRX）协议对齐。

本领域技术人员应理解，即使上述功能通常描述为似乎它们位于例如基站的站中，但是在一些实施方案中，功能可位于其它设备中。执行排队和调度的任何设备可执行算法。例如，当确定怎样调度数据包以进行上行传输或确定哪些队列从基站请求带宽上行时，用户装备可执行所述算法。调度基站回程上的带宽或来自基站的带宽的设备或模块可执行算法。

在一个实施方案中，分布功能。例如，参看图8，网关540可检测载体、连接或流上的应用类别、具体应用，或传输协议的动态的存在和后续不存在。网关540可将所述信息发信号到无线电访问网络（例如，基站）550以用于计算AF或附加因子。在另一实施方案中，网关540计算应用因子或增强型权重或信用并将它们发信号到无线电访问网络550。在实施方案中，无线电访问网络550将例如缓冲占用、信号质量、丢弃率等的信息发信号到网关540，且网关540使用所述信息来调度它的出口流量。另外，网关540可组合来自无线电访问网络550的信息以计算附加因子或增强型权重或信用并将它们发信号到无线电访问网络550。

在实施方案中，例如AF的信息单独或与例如缓冲占用、信号质量、丢弃率、估计的比特率等的附加因子组合可用以计算对通常在网络端点之间建立逻辑信道期间建立的GBR设置的调整。例如，在LTE网络中，eNB调度参数计算模块335可使用特定数据流计算的AF来通过将消息发送到EPC包网关以请求对对应的数据载体的GBR的修改。在替代性实施方案中，eNB调度参数计算模块335可另外请求QCI改变，例如从不支持GBR载体的QCI改变成支持GBR载送的QCI。所述请求可在数据流的寿命期间进行一或多次，且可单独使用或组合上述技术使用，这取决于eNB存在的条件。

高效检测

在分类和排队模块310中对包的处理需要某些成本。对于在微处理器、数字信号处理器（DSP）或类似设备上运行的软件中实施的功能，处理成本涉及软件指令的计算复杂性和完成处理需要的所得数量的处理器周期（或指令）。所述工作通常以单位‘每秒百万指令’（MIPS）表示或表示为给定微处理器的总的可用MIPS的百分比（例如，过程X使用总的可用MIPS的50%）。对于集成电路硬件中实施的功能，处理成本可表示为用以执行所述功能的模片区（例如，平方毫米、门的数量、查找表的数量）和硬件的功耗（例如，以毫瓦或瓦计）。处理成本也可表示为增加的解决方案成本和客户的价格。因此，高效的包检查对于降低处理成本是有价值的。

图21是包检查模块1500的另一实施方案的功能框图。包检查模块1500可用作本文描述的分类和排队模块中一个中的增强型包检查模块。包检查模块1500可有效地识别应用类别、具体应用，和应用信息。增强型包检查模块1500包括确定应进一步检查哪些包的流量监控模块1520；检测传输形成会话的流的连接的连接检测模块1530；检测流、会话和应用信息的流和会话检测模块1540；和维持状态和历史的状态模块1550。包检查模块1500也可实施通常由其它逻辑模块1570表示的其它功能。包可通过第一双向接口1510或第二双向接口1560进入包检查模块1500。通过第一双向接口1510进入的包通过第二双向接口1560退出，反之亦然。

通过双向接口1510、1560进入包检查模块1500的包可最初由流量监控模块1520检查。流量监控模块1520可检查沿单个方向或两个方向流动的包。在实施方案中，包可通过队列或缓冲器在包检查模块1500中延迟，以向例如连接检测模块1530和流和会话检测模块1540的其它模块提供时间，从而检查并处理被识别的包以进行进一步的检查和处理。或者，为了限制传输延迟，可复制一些或所有包（或包的一部分）以进行进一步的检查和处理，而原始包被转发到朝向传输的路径中的下一步骤。例如，原始包可被提供到数据队列315，从而馈送图5示出的参数化调度模块中的调度器330。

为了提高包处理效率，包检查模块1500可使用一个或多个技术来基于具有低处理成本的简单的标准过滤包，使得只有包检查模块1500接收的包的子集经过具有较高处理成本的较复杂的包检查。

在实施方案中，流量监控模块1520可过滤包，使得连接检测模块1530或流和会话检测模块1540只检查上行包。过滤降低了检测在网络的边缘的节点（例如，图8中无线通信系统的用户终端设备560或图1中无线通信网络的客户端设备150）发起的连接、流或会话的处理成本。对于其中上行载送的流量比例如移动网络（例如，LTE、WiMAX或3G蜂窝）或家庭互联网络（例如，光纤到户（FTTH）网络、DOCSIS电缆调制解调器网络或DSL网络）的下行链路载送的流量小的网络，这特别有利。

例如，流量监控模块1520可过滤包，使得连接检测模块1530可只接收并检查上行包以通过检测从客户端（例如，用户终端设备560）发送到服务器（例如，数据源510）的SYN消息来检测TCP连接的初始化。所述技术也可反向应用以提高从服务器发起的（例如，来自数据源510或核心网络102内）会话的处理效率。

在实施方案中，一个或多个特征可用以过滤包并降低处理成本，从而基于使用的协议来检测新的连接。例如，当试图检测新的UDP或TCP连接或流时，可使用移动网络运营商（MNO）已只使用某一源IP地址或源IP地址范围来配置它的网络的知识。或者，TCP源或目的地端口号可用以过滤包。例如，为了降低处理成本，可使用初始检查阶段来只发送具有包括TCP目的地端口80的标头的包来进行进一步的HTTP协议处理。

在实施方案中，流量监控模块1520可只监控分配到特定服务类别的包。例如，在LTE无线电访问网络中，流量监控模块1520可基于服务类别过滤包并只将对应于最低服务类别QCI=9的包传递到连接检测模块1530和/或流和会话检测模块1540以进行进一步的处理而忽略分配到所有其它服务类别QCI=1-8的包。在又一实例中，流量监控模块1520可监控去往或来自为MNO的‘金’服务等级额外付费的用户的所有包，而可不监控去往或来自参与MNO的‘银’或‘铜’服务等级的用户的包。许多其它过滤系统也是可能的。另外，一个或多个过滤可彼此逻辑组合来使用和/或结合其它检测技术来使用。

在实施方案中，基于包大小的过滤可用于流量监控模块1520中。例如，在连接或会话初始化期间检测特定包消息时，可能有对应于感兴趣的具体消息的狭窄范围的包大小。如果包在大小范围（最小和最大）内或大于或小于大小阈值就只转发包以进行附加处理的包过滤器可用以降低处理成本。例如，视频串流会话可基于实时流协议（RTSP）的特征来检测。RTSP包封装在TCP/IP帧内且通过IP网络载送，例如，如图8示出的无线通信系统中示出。

RTSP建立并控制与交换消息的客户端和服务器的多媒体流会话。从客户端发送到服务器的第一RTSP消息是请求消息。请求消息的第一行是请求线。请求线由以下3个元素组成：（1）方法；（2）Request-URI；和（3）RTSP-Version（RTSP-版本）。RTSP定义了包括OPTIONS、DESCRIBE、ANNOUNCE、SETUP、PLAY、PAUSE、TEARDOWN、GET_PARAMETER、SET_PARAMETER、REDIRECT和RECORD的方法。

在实施方案中，流和会话检测模块1540可通过检查被识别以由流量监控模块1520进行进一步处理的上行包来在视频串流会话建立的DESCRIBE阶段期间捕获信息。可使用包括在TCP有效载荷内RTSP消息中的文本‘DESCRIBE’上的字符串（即，字符文本）匹配来检测客户端DESCRIBE包。这个情况下的服务器响应将在通常更重负载的下行方向上传输。这个服务器响应可包括可用以确定应用类别（例如，视频串流）的关键信息（例如，‘m=video’字段）。为了降低检测服务器回复的处理成本，流量监控模块1520可被配置来如果所述包具有950和970字节之间的有效载荷大小就只识别来自相关TCP连接的包以进行进一步的RTSP处理。为了进一步降低处理成本，在附加实施方案中，基于大小过滤包和后续RTSP处理只可有效达有限的持续时间或在检测到客户端发送的DESCRIBE包之后对于有限数量的包有效。例如，包括上述过滤技术的试图检测DESCRIBE响应的包检查系统只可有效达1秒，此后，检查过程终止。

在替代性实施方案中，使用RTSP协议来初始化视频串流会话可通过检测客户端发出的RTSP PLAY命令来检测。通常在更重负载的下行方向上载送到客户端的服务器响应包括可存储在状态模块1550中的回放范围字段。检测来自服务器的RTSP PLAY响应可例如通过只传递大小为360-380字节的包以进行进一步的RTSP处理来改良。为了进一步降低处理成本，由包大小过滤和RTSP处理只可有效达有限的持续时间或在检测到PLAY包之后对于有限数量的包有效。例如，检测PLAY响应的包检查只可有效达1秒，此后，检查过程终止。

数据包或消息大小过滤器可用以降低其它协议、应用类别和具体应用的处理成本。流量监控模块1520可同时使用若干过滤机制。例如，流量监控模块1520可同时通过LTE载体或QCI过滤、在已检测的TCP连接上过滤，且过滤包大小达有限时间段。

连接检测模块1530检查包以确定用以支持应用流或会话的网络连接何时发起或终止。连接检测模块1530可检查被识别以由流量监控模块1520进行进一步处理的包，从而检测新的TCP连接的初始化。当新的LTE用户装备（UE）150附接到图1的通信网络中LTE增强型节点B（eNB）微微站130时，或者当在LTE UE和eNB之间创建新的专用数据载体时，示例性连接可在图8的无线通信系统的用户终端560和数据源510之间发生。连接检测模块1530检查的包可为被识别以由流量监控模块1520进行进一步处理的包。

在实施方案中，流量监控模块1520可基于包与一个或多个以下特征的相关性来用独特的方式（包括不用监控）监控包：逻辑链路（例如，LTE数据载体）、连接（基于连接检测模块1530进行的之前的检测）、数据流、应用会话（基于流和会话检测模块1540进行的之前的检测）、服务类别、网络服务等级协议（SLA）或网络策略设置。

在连接检测模块1530检测到新的连接之后，上下文表项可在状态模块1550中创建。在检测到终止的连接之后，上下文表项可在状态模块1550中删除或修改。在实施方案中，状态模块1550维持每个检测的连接的上下文。上下文可包括通常对应于开放系统互连（OSI）层模型的层的特征。示例性特征包括：

层1-2：以太网MAC地址、3GPP载体ID或隧道ID、3GPP移动电话识别符（例如，IMSI、IMEI、GUTI、S-TMSI）

层3：源/目的IP地址

层4：协议类型（例如，TCP、UDP）

层5：源/目的TCP端口#、协议类型（例如，RTP、RTCP、RTSP）

在替代性实施方案中，实时或历史度量也可被收集并存储在连接的上下文表项中。例如，上下文表项可包括关于连接的持续时间（例如，秒数）、传递的字节数量、传递的包数量、平均比特率（例如，千位/秒）、最大比特率（例如，在时间间隔内测量）的信息。除了用于分析，实时度量也可用于响应性调整例如应用因子的调度器参数。历史度量可用于预测调整调度器参数。上下文也可包括也可用以调整调度器参数的会话质量度量（例如，包丢失统计数据、包重传统计数据，和包错误率）。

在实施方案中，状态模块1550中存储的上下文可包括与活动连接（即，已发起但还未终止的那些连接）相关的项目。在替代性实施方案中，上下文可另外保留连接的历史，包括关于已终止的连接的信息。在实施方案中，与终止的连接相关的上下文表项可包括与活动连接的项目相同的信息（例如，上文列出的特征的组合）。替代或另外，与终止的连接相关的上下文表项可包括总结连接历史的信息。例如，上下文表项可包括上述特征的子集加例如传递的字节总数量或连接的持续时间的信息。

在实施方案中，上下文可由状态模块1550以文件、数组、链表或提供随机读/写访问的其它适当存储机制的形式存储。

进一步的包检查可由流和会话检测模块1540执行以识别包括连接上的会话的流的初始化或终止并识别应用类别、具体应用或其它特征。可由流和会话检测模块1540识别的示例性特征包括：

层6：技术类型（HTTP、HTTPS、FTP、远程登录）

层7：应用类别（例如，串流视频、双向视频通话、语音、电子邮件、互联网浏览、游戏、机器对机器数据等）和具体应用（例如，YouTube、Netflix、Hulu、Skype、Chrome等）。

除了上文列出的特征或作为上文列出的特征的替代，许多其它连接、流、会话和应用特征也可被识别。

在实施方案中，流和会话检测模块1540检测的应用类别、具体应用和上述其它特征添加到状态模块1550中连接的上下文表项。

包检查模块1500可在单个无线或有线网络节点中实施，所述单个无线或有线网络节点例如基站、LTE eNB、UE、终端设备、网络交换机、网络路由器、网关、回程设备或其它网络节点（例如，图1和2中示出的宏基站110、微微站130、企业毫微微蜂窝140或企业网关103或者实施回程或在核心网络中网络网关中实施的设备）。在其它实施方案中，包检查模块1500的功能可分布在多个网络节点上。在示例性LTE网络中，流量监控模块1520、连接检测模块1530和流和会话检测模块1540可位于数据包网关中，而状态模块1550可位于eNB基站中。许多其它功能分区也同样可能。另外，包检查模块1500的个别模块可分布在多个设备上。另外，包检查模块1500的各种模块的功能可用图21示出的方式以外的方式来划分、分布和/或组合。

在实施方案中，包检查模块1500内的功能可被划分，使得功能的一个子集只处理数据平面包而功能的不同子集只处理控制平面包。例如，用以在LTE eNB基站中检测新的UE或新的数据载体的连接检测模块1530中的功能可只处理3GPP控制平面包。或者，用以在LTEeNB基站中检测LTE数据载体上新的TCP连接的连接检测模块1530中的功能可只处理数据平面包。

图22是检测连接初始化的过程的流程图。所述过程被描述为由包检查模块1500实施，但是所述过程也可由其它模块来实施。在步骤1610，包被流量监控模块1520和连接检测模块1530检查以识别新的连接。例如，在LTE基站中，流量监控模块1520可检查层1或2标头以识别新的3GPP载体ID。随后，连接检测模块1530可检查包以通过检测包来识别用于在TCP客户端和TCP服务器之间建立TCP（例如，SYN、SYN-ACK、ACK）的TCP连接的建立。替代或另外，连接检测模块1530可检查包以识别状态模块1550当前未知或者已知但处于终止状态的连接信息。例如，连接检测模块1530可检查包以识别IP源地址和目的地址与状态模块1550当前未知或者已知但处于终止状态的TCP端口的组合。

在步骤1615，连接检测模块1530确定步骤1610中监控的流量是否构成新的连接。在实施方案中，连接检测模块1530保留连接建立协议（例如，TCP SYN、SYN-ACK、ACK消息）的状态并基于来自所述协议的成功的结果来识别新的连接。在替代性实施方案中，连接检测模块1530将步骤1610期间收集的连接识别信息与存储在状态模块1550中的上下文作比较。如果连接识别信息（例如，逻辑链路、IP地址、UDP套接字）匹配状态模块1550存储的上下文中的现有、活动连接，那么连接信息就被认为用于现有连接而不是新的连接且控制返回步骤1610。然而，如果状态模块1550存储的现有、活动上下文中没有连接信息，那么已识别了新的连接。在步骤1620，连接信息存储在上下文中，所述上下文由状态模块1550存储。过程然后继续到步骤1625，其中发起对连接的监控以检测关于连接状态和与在连接上传输的流量相关的任何流、会话和应用的信息。然后，过程返回到步骤1610以监控新的连接。检测连接初始化的过程的步骤可同时执行。另外，所述过程可通过添加、省略、重新排序，或改变步骤来修改。

图23是监控连接的过程的流程图。所述过程可用以执行图22示出的检测连接初始化的过程的步骤1625。监控连接的过程被描述为由包检查模块1500实施，但是所述过程也可由其它模块来实施。图23示出的监控连接的过程监控特定连接的流量。因此，包检查模块1500可执行每个活动连接的过程的实例。

在步骤1630，监控与特定连接相关的包。基于过滤标准，流量监控模块1520识别与特定连接的状态有关的包以由连接检测模块1530进行进一步处理，并识别与流创建和终止和将所述包转发到流和会话检测模块1540有关的包。流量监控模块1520也可识别包以进一步检查感兴趣的流、会话或应用信息。所述包可被转发到另一模块，例如，另一逻辑模块1570、状态模块1550，或流和会话检测模块1540。例如，流量监控模块1520可被配置来定期识别来自特定视频流的包，使得例如另一逻辑模块1570的另一模块可确定当前回放状态。替代或另外，流量监控模块1520可检测特定连接的TCP重传请求，使得状态模块1550可记录用于评估通过连接提供的服务的质量的度量。流量监控模块1520也可被配置来识别流量样式并使用所述样式来帮助进行应用检测。

在步骤1640中，连接检测模块1530检查包以确定被监控的连接是否已终止。例如，对于TCP连接，其中FIN消息对（其中从TCP服务器和TCP客户端中的每一个发送一条消息）是一种终止TCP连接的正规的方法。如果从TCP客户端和TCP服务器都检测到FIN消息，那么连接检测模块1530可推断TCP连接已终止。为了降低计算复杂性和处理成本，只检测到两个FIN消息中的一个或另一个可用以确定连接已终止。当连接检测模块1530只在载送较小流量的链路方向上检测到FIN消息时，处理成本可进一步降低。例如，在许多移动网络上，上行方向常载送比下行方向少的流量。因此，在这种情况下，在链路190的上行方向上检测到FIN消息需要检查较少的包，因此需要比在下行方向上检测到FIN消息或检测到两个FIN消息低的处理成本。

用于检测连接、流和会话的初始化和终止的不同方法可具有例如就处理容量而言的不同的成本。所述方法也可具有不同的鲁棒性。可能有与某些方法相关的成本，借此，只有当如果有足够的计算资源可用时才使用所述方法，或者使用较不鲁棒但成本更低的方法。可用计算资源可例如随着温度、电池电量、省电模式或者内存利用率而动态变化。计算资源也可根据如总系统比特率（例如，兆/秒）、包率（例如，包/秒）、活动连接、流和/或会话的数量测量的网络流量负载而变化。

如果步骤1640确定连接已被终止，那么在步骤1650更新所述状态。在实施方案中，关于终止的连接的项目和所有信息可从状态模块1550存储的上下文删除。在替代性实施方案中，连接的历史记录和指示它不再活动的项目的当前状态的更新一起可保留在上下文表项中。这可用于预测调度器参数的更新。在更新状态模块1550之后，控制进行到步骤1655，其中监控连接的过程终止。终止所述过程可包括归还用以执行监控的资源。

如果连接未被终止，那么过程继续到步骤1660。在步骤1660，流和会话检测模块1540检查包以检测新的流或会话的初始化并识别应用类别、具体应用，或其它会话或流特征。检测新的流或会话可使流量监控模块1520修改用以识别包以进行进一步处理的方法。例如，如果流被确定为通过TCP的视频流，那么流量监控模块1520可被配置来定期识别包，从而检测或估计视频回放进度。所述进度可例如由监控HTTP服务器的GET响应和客户端侧TCP ACK消息中的TCP序列号来监控。

在实施方案中，先前检测的特征（例如，在图22的检测连接初始化的过程的步骤1615中检测）也可用以确定已发起流并识别与所述流相关的会话的应用类别和/或具体应用。例如，在TCP连接建立期间检测的IP源地址和目的地址可用以确定数据流或会话的应用类别和具体应用。使用IP源地址和目的地址，包检查模块1500可执行反向域名系统（DNS）查找或互联网WHOIS查询以建立域名和/或采购或接收基于互联网的流量的登记的受让人。域名和/或登记的受让人信息然后可用以基于域或受让人的目的先验知识来建立数据流的应用类别和具体应用。应用类别和具体应用信息一旦得出就可存储供例如状态模块1550或另一逻辑模块1570重复使用。例如，如果一个以上的用户设备访问Netflix，那么包检查模块1500可被配置来保留信息，使得包检查模块1500将不需要确定同一用户设备或另一用户设备对Netflix的后续访问的应用类别和具体应用。

例如，如果具有特定IP地址的流量产生包括名称‘Youtube’的反向DNS查找或WHOIS查询，那么所述流量流可被认为是使用Youtube服务（具体应用）的单向视频流（应用类别）。在实施方案中，可维持域名或受让人和应用类别和具体应用之间的综合映射。所述映射被定期更新以保证映射保持最新。

在实施方案中，组合下层连接信息的在步骤1660检测的流和会话信息与状态模块1550存储的现有流和连接信息作比较。如果在存储的上下文中没有与检测的流和连接信息的匹配，那么流可被宣布为新的并在步骤1670中存储为与状态模块1550中下层连接相关的新的流项目。

在实施方案中，可比较关于多个流的信息以确定新的流是否构成新的会话或者新的流是否是现有会话的部分。例如，如果流被检测为在与先前检测相同的用户的相同的逻辑链路上通过RTP的视频流、通过RTP的仍活动的语音流和先前检测的最近的SIP信令流，那么流的组合可被识别为对话视频（例如，视频Skype）会话。

在另一实例中，可检测LTE语音（VoLTE）和与VoLTE组合的交互式视频。即使可加密服务建立的IP多媒体子系统（IMS）信令（如在LTE中的情况），检测也可发生。例如，包检查模块1500可检测核心网络和用户装备之间的IMS信令，在此之后不久，创建具有与语音一致的比特率（例如，32kbps）的载体或流。所述信息可用以推断VoLTE会话是在新的载体或流上发起的。信息的示例性使用由图5的调度器参数计算模块335进行以调整调度器参数。如果具有与视频一致的比特率的第二载体或流被建立有适当的时间关系，那么可推断组合表示交互式语音加视频会话。已知所述交互的语音部分对于用户的体验质量而言比视频部分重要，调度器参数计算模块335可比起视频载体而优先化语音载体。视频部分可被认为是具有比例如视频点播的其它视频使用低的优先级，而语音部分被给予较高优先级。

在另一实例中，如果紧随载送具有不同回放范围的所述视频的部分的流，确定流载送具有某一回放范围的串流视频，那么两个流可识别为所述视频串流会话的部分。状态模块1550维持较早流的状态（甚至在终止之后）允许发生所述相关性。在实施方案中，保存的上下文用流、会话、应用类别和上述具体应用信息来更新。所述流关系可用以确定设备信息。例如，检测到多个顺序流与单个流用于YouTube视频可用以区分使用iOS操作系统的苹果产品与运行Android（安卓）操作系统的设备。检测到流、会话、应用和设备信息可用于计算例如影响权重和信用的应用因子的调度器参数。历史也可用于预测修改调度器参数。

替代或另外，关于特定会话的详细的特征也可基于包标头中可用的信息或来自包流分析的信息（如可在步骤1630中执行）添加到上下文（步骤1670或步骤1630）。例如，描述串流视频会话的上下文也可包括以下特征：视频片段持续时间、分辨率、帧率、比特率、容器格式、视频编码解码器（编解码器）格式和配置、客户端设备（例如，安卓智能手机、苹果iPad、电视机顶盒）。特征可例如用以修改调度中使用的应用因子。与串流视频相关且与其它应用类别相关的其它特征也可被识别并存储在上下文中。

一旦在步骤1670更新状态或上下文或如果在步骤1660没有检测到新的会话，那么过程继续到步骤1680。在步骤1680，流和会话检测模块1540试图识别流和它相关会话的终止。由于一个以上的流可存在于连接上，所以在实施方案中，过程可试图识别一个以上的流的结束。另外，步骤1680可通过将流与会话的上下文作比较来确定流的终止是否造成会话的终止。如果流是与会话相关的最后一个活动流，那么会话可被认为终止。或者，会话可能不立即终止。例如，在会话是iPhone上YouTube应用的实例的情况下，会话可由多个顺序流组成。维持通过这些流的会话有利于计算调度器参数，从而维持体验质量。

使用HTTP协议发起会话的客户端可使用HTTP GET命令来从HTTP服务器请求具有特定内容长度的HTTP文件。在实施方案中，对于使用HTTP协议发起的会话，会话终止可通过监控客户端侧TCPACK号来检测。如果HTTP服务器的GET响应始于TCP序列号N且HTTP响应体的长度（内容长度）是L，那么当客户端发送ACK号等于N+L的TCP段时，会话可被认为终止。或者，为了提供固定比特长度的实施，当TCP连接上没有包的间隔（例如，一分钟或更长）接在ACK号等于（N+L）模数2EXP B的TCP段之后，其中B是TCP段号字段的比特长度，会话可被认为终止，从而允许TCP序列号回绕。

为了降低处理成本，流和会话检测模块1540可被配置来定期而不是连续检查客户端ACK号。检查其它信息也可随着时间的推移间歇地执行。间歇处理可以规则或不规则的时间间隔发生。检查期间可为固定的或可基于传输中剩余包的数量来调整。例如，在检测到新的HTTP会话之后，流和会话检测模块1540可在每1秒期间监控包100ms。当会话接近完成时，流和会话检测模块1540可被配置来例如如以下表格中示出检查较大比例的包。

在以上实例中，会话完整性可计算为发送的当前字节（最新的客户端ACK号减去N）除以将要发送的总字节（L）。其它技术可用以调整包监控时间，从而可对处理成本和/或终止检测精确性产生进一步改良。

由于通过使用上述技术有错过检测会话终止的风险，所以流和会话检测模块1540也可使用这个技术结合其它方法，例如如下文所述的会话超时（例如，在特定时间段不发送会话包）或比特率技术。

如果不检测终止的会话，那么过程返回步骤1630。如果在步骤1680确定会话已终止，那么过程继续到步骤1690并更新状态。在实施方案中，通过去除当前会话、应用类别、具体应用和状态模块1550存储的相关信息来更新状态。在替代性实施方案中，会话的历史记录也可由状态模块1550保留。这个历史记录可包括当会话活动时存储在上下文中的一些或所有会话特征。一旦状态已被更新，过程就返回步骤1630，其中发生对连接的进一步监控。在只有单个会话可与每个连接相关的替代性实施方案中，过程可从步骤1690进行到步骤1655。

在实施方案中，数据流的稳态比特率可用以识别新的会话的应用类别或具体应用。例如，具有比特率为64kbps的双向数据流的会话可基于与G.711编解码器相关的比特率被表征为‘语音’应用类别。在替代性实施方案中，只有在会话进行了大于最小时间段（例如，3秒）的时间段之后，所述流才可被认为是语音应用类别。为了提供具有不同的压缩比的语音编解码器和具有可变比特率容量的编解码器的广泛应用，上述技术可被进一步修改以检测比特率在例如8kbps到64kbps的最小和最大值之间的双向数据流。

类似技术可用以检测是否存在串流视频。例如，包检查模块1500可通过测量在某一时间段内的平均、单向比特率在预定最小和最大比特率范围（例如，在1Mbps和4Mbps之间）内来检测高清（例如，1080p）视频串流会话的存在。另外，比特率样式（即，在某一时间段内测量并追踪的比特率）也可用以确定应用类别或具体应用。例如，使用HTTP协议的YouTube视频服务器在短、高速率突发的样式下将数据发送到安卓智能手机，然后是长、极低速率的静默期。所述样式的实例在图24的比特率与时间的关系图表中示出。包检查模块1500可被配置来使用突发阈值的组合（例如，大于某一最小比率的突发）和爆发期和静默期之间的比率来检测这个样式。另外，流量监控模块1520或流和会话检测模块1540可检测静默期中零长度TCP保持活动消息，从而增加确定样式用安卓YouTube应用表示YouTube视频会话的信心。在替代性实施方案中，这些检测特征可为例如客户端设备、使用历史（例如，高清视频的最近回放）、传输信道条件，或网络运营商的其它因子的函数。所述因子可提前知道。

比特率和/或比特率样式的使用可延伸到检测其它应用类别或具体应用。其它实例包括游戏、机器对机器通信和视频会议。

另外或替代，比特率和比特率样式的使用可被流和会话检测模块1540用以确定流已终止（步骤1680）。例如，如果已检测到流且流被分类为串流视频会话（通过比特率检测或其它方法），那么流和会话检测模块1540可在流的开始且其后定期测量平均比特率（例如，2Mbps）。如果在特定时间段（例如，3秒）或在特定数量的采样上（例如，每秒300毫秒采样）比特率下降到低于特定阈值（例如，测量的平均比特率的10%），那么流可被认为终止。为了降低处理成本，比特率监控可配置为较不频繁。或者，为了提高检测速度，比特率监控可配置为更加频繁。

在实施方案中，比特率监控可根据流或会话来独特地使用或配置。例如，对于基于HTTP的视频串流会话，终止场景可被认为是数量有限且可靠的。在所述场景中，比特率监控可用作回退或安全网以检测通过未知或不可预知的原因终止的不可能的情况或者错过预期终止协议的情况。在所述情况下，比特率监控可被设置为极其频繁（例如，每10秒）以最小化处理成本。或者它可被禁用以最小化处理成本。相反，对于具有包检查模块1500未知的协议、应用类别，和/或具体应用的会话、流或连接，可能不能基于协议消息的检测和检查来检测流的终止的风险很高。在所述情况下，可极其频繁地（例如，每100毫秒）监控比特率，因为比特率监控有可能是用于检测流或会话终止的唯一机制。

在替代性实施方案中，比特率和比特率样式的使用可被连接检测模块1530用以（步骤1640）确定连接处于非活动和/或错误状态且应被认为终止。例如，如果基于TCP的连接的平均比特率在指定的时间长度（例如，分钟或小时）下降到零，那么连接检测模块1530可推断连接已经例如使用FIN消息以不产生有序的连接拆除的方式断开。在替代性实施方案中，连接检测模块1530可计数沿一个或两个网络方向的TCP段。如果在指定的时间长度，段的总数为零，那么连接检测模块1530可推断连接可被认为终止。

在实施方案中，应用类别或具体应用可通过检查建立会话的协议来建立。例如，为了识别基于HTTP的视频流，流和会话检测模块1540可被配置来检查超文本传输协议（HTTP）包中的‘内容类型’字段。基于多用途互联网邮件扩展（MIME）格式中指定为由互联网工程任务组（IETF）定义的定义，内容类型字段包括有关有效载荷的类型的信息。例如，以下MIME格式将指示单播或广播视频包流：视频/mp4、视频/quicktime、视频/x-ms-wm。为了降低处理成本，应用检测模块可被配置来只有在上行方向上成功检测到HTTP‘Get’请求之后且只在有限的时间量（例如，2秒）检查包中下行方向上的‘内容类型’字段。

根据实施方案，流和会话检测模块1540被配置来检查HTTP标头中包括的Host字段。Host字段通常包括域或受让人信息，所述域或受让人信息可用以将所述流映射到应用类别或具体应用。例如，HTTP标头字段“v11.lscache4.c.youtube.com”可被检查并映射到应用类别=视频流、具体应用=YouTube。为了降低检测客户端发起的视频会话（例如，由图8的无线通信系统的用户终端560发起）的处理成本，在实施方案中，检测Host字段可只在沿上行方向行进的包上执行。另外，由于Host字段包括在客户端发起的HTTP GET命令（如以下示例性GET命令中示出）深处，所以检测并解析Host字段的方法只有在HTTP消息开始成功检测到GET字符串之后才可发起。

为了进一步提高效率，在实施方案中，上述技术可逻辑组合，使得使用一种技术检测应用类别或具体应用暂停通过其它技术来进行所述连接的附加包检查。例如，如果一种检测YouTube的技术成功，那么使用HTTP MIME方法的包检查可暂停。

在替代性实施方案中，为了进一步提高效率，应用类别或具体应用可通过使用服务类别（CoS）包标记来确定。例如，MNO可确定使用LTE QCI=3来进行实时游戏且使用QCI=5来进行IMS信令并使用这个信息来在LTE eNB中配置包检查模块1500。因此，具有这些特征的到达eNB的包可被快速评价并从进一步处理删除。

在实施方案中，逻辑链路的终止或关于逻辑链路的终止的消息可被连接检测模块1530用以确定连接已终止。例如，在LTE网络中，向UE指示RF链路的丢失的从物理（PHY）层传递到无线资源控制（RRC）层的信令消息可被连接检测模块1530用以终止与UE相关的所有会话和连接。

在实施方案中，通过网络载送的控制平面消息用以检测连接检测模块1530进行的数据平面连接的终止。例如，接入层（AS）控制平面消息被LTE UE发送到服务eNB以发起并确认UE移交到新的目标eNB。这些消息可被连接检测模块1530检测并可用以宣布与UE相关的所有会话、流和连接的终止。在替代性实例中，eNB和UE之间的AS控制平面消息用于释放（终止）专用数据载体。这些消息可被连接检测模块1530检测并用以宣布与数据载体相关的所有连接已终止。

技术人员应理解，结合本文公开的实施方案描述的各种说明性逻辑块、模块、控制器、单元和算法步骤常可实施为电子硬件、计算机软件或两者的组合。为了清楚地说明硬件和软件的这种可互换性，各种说明性组件、单元、块、模块和步骤已在上文一般就它们的功能进行了描述。此类功能性实施为硬件或软件取决于特定系统和施加在整个系统的设计约束。技术人员可针对特定系统以变化的方式实施所描述的功能性，但是不应将实施确定导致偏离本发明的范围。另外，单元、模块、块或步骤中功能的分组是为了便于描述。具体功能或步骤可在不偏离本发明的情况下移离一个单元、模块或块。

结合本文公开的实施方案描述的各种说明性逻辑块、单元、步骤和模块可用通用处理器、数字信号处理器（DSP）、专用集成电路（ASIC）、现场可编程门阵列（FPGA）或其它可编程逻辑设备、离散门或晶体管逻辑、离散硬件组件，或设计来执行本文描述的功能的它们的任何组合来实施或执行。通用处理器可为微处理器，但是在替代情况下，处理器可为任何处理器、控制器或微控制器。处理器还可实施为计算设备的组合，例如，DSP和微处理器的组合、复数个微处理器、结合DSP核心的一个或多个微处理器，或任何其它这类配置。

结合本文公开的实施方案描述的方法或算法的步骤和方块或模块的过程可直接在硬体中、在处理器执行的软件模块（或单元）中或两者的组合中实施。软件模块可驻留在RAM存储器、快闪存储器、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM，或机器或计算机可读存储介质的任何其它形式的。示例性存储介质可耦接到处理器，使得处理器可从所述存储介质读取信息并向所述存储介质写入信息。在替代情况下，存储介质可以集成到处理器。处理器和存储介质可驻留在ASIC中。

提供公开的实施方案的以上描述来使得本领域任何技术人员能够进行或使用本发明。对这些实施方案的各种修改对于本领域技术人员显而易见，且本文描述的一般原则可在不偏离本发明的精神或范围的情况下应用于其它实施方案。因此，应理解，本文所呈现的描述和附图表示本发明的当前优选的实施方案，且因此表示本发明所广泛预期的主题。应进一步理解，本发明的范围完全涵盖对于本领域技术人员可能变得明显的其它实施方案。

Claims (23)

1.一种用于操作通信设备以调度数据包的传输的方法，所述方法包括：

接收来自通信网络的多个数据包；

确定与所述数据包中至少一个相关的至少一个应用；

将所述数据包中的每一个插入多个数据队列中的一个；

确定对于所述数据队列中每一个的调度器参数，对于所述数据队列中的至少一个的所述调度器参数包括与所述至少一个应用相对应的至少一个应用因子，所述至少一个应用与所述数据包中的所述至少一个相关，所述调度器参数还包括至少一个数据队列特征因子，所述至少一个数据队列特征因子基于与其对应的数据队列的特征；

至少部分地基于对于每个数据队列的调度器参数，将所述数据包从所述多个数据队列中的每一个调度到输出队列；和

将所述数据包从所述输出队列传输到所述通信网络。

2.如权利要求1所述的方法，所述至少一个数据队列特征因子包括多个数据队列特征因子，所述多个数据队列特征因子是所述至少一个应用因子的乘法因子。

3.如权利要求1所述的方法，其中所述多个数据队列特征因子包括对于所述至少一个应用因子的加法因子。

4.如权利要求1所述的方法，其中所述至少一个数据队列特征因子包括相对应数据队列的深度。

5.如权利要求1所述的方法，其中所述至少一个数据队列特征因子包括相对应数据队列的丢弃率。

6.如权利要求1所述的方法，其中所述至少一个数据队列特征因子包括相对应数据队列的延迟。

7.如权利要求1所述的方法，其中所述至少一个数据队列特征因子包括相对应数据队列的出口率。

8.如权利要求1所述的方法，其还包括确定与所述至少一个应用中的一个相关的数据包的比特率，且其中所述调度器参数还包括与所述应用中的所述一个相关的所述多个数据队列中的一个的出口率，所述出口率被比作与所述应用中的所述一个相关的所述数据包的所述比特率。

9.如权利要求1所述的方法，其中用于所述数据队列中至少一个的所述调度器参数还包括基于用于传递所述数据包的通信链路的特征的至少一个通信链路特征因子。

10.如权利要求9所述的方法，其中所述至少一个通信链路特征因子包括信号质量指示。

11.如权利要求9所述的方法，其中所述至少一个应用包括视频流，且所述方法还包括将关于所述通信链路的所述特征的信息传输到第二通信设备，以供所述第二通信设备用来选择所述视频流的片段。

12.如权利要求1所述的方法，其中对于所述数据队列中的至少一个的所述调度器参数还包括基于用于传递所述数据包的协议的至少一个协议因子。

13.如权利要求1所述的方法，其还包括将关于所述至少一个应用的信息传输到第二通信设备以用于调度来自所述第二通信设备的数据包的传输。

14.如权利要求1所述的方法，其还包括将关于所述至少一个数据队列特征因子的信息传输到第二通信设备以用于调度来自所述第二通信设备的数据包的传输。

15.如权利要求1所述的方法，其还包括检测所接收的多个数据包中的流量样式，且其中用于所述数据队列中至少一个的所述调度器参数还基于所检测的流量样式。

16.如权利要求15所述的方法，其中确定所述调度器参数以增加从所述输出队列传输到所述通信网络的所述数据包之间的空闲时间。

17.一种用于调度数据包的传输的通信设备，所述通信设备包括：

分类和排队模块，其被配置来接收多个数据包并输出数据包到多个数据队列中，所述分类和排队模块包括被配置来分析所述数据包的属性、确定与所述数据包中至少一个相关的至少一个应用、并输出关于所述至少一个应用的应用信息的包检查模块；

调度器参数计算模块，其被配置来计算并输出指示所述多个数据队列的相对优先级的调度器参数，用于所述数据队列中至少一个的所述调度器参数包括基于来自所述包检查模块的所述应用信息的至少一个应用因子和至少一个数据队列特征因子，所述至少一个数据队列特征因子基于与其对应的数据队列的特征；和

调度器模块，其被配置来以考虑到来自所述调度器参数计算模块的所述调度器参数的次序从所述数据队列选择数据包并将所述选定的数据包插入输出队列来通过物理通信层传输。

18.如权利要求17所述的通信设备，其中所述至少一个数据队列特征因子包括相对应数据队列的深度。

19.如权利要求17所述的通信设备，其中所述至少一个数据队列特征因子包括相对应数据队列的丢弃率。

20.如权利要求17所述的通信设备，其中所述至少一个数据队列特征因子包括相对应数据队列的延迟。

21.如权利要求17所述的通信设备，其中所述至少一个数据队列特征因子包括相对应数据队列的出口率。

22.如权利要求17所述的通信设备，其中用于所述数据队列中至少一个的所述调度器参数还包括基于所述物理通信层的特征的至少一个物理通信层因子。

23.如权利要求17所述的通信设备，其中用于所述数据队列中至少一个的所述调度器参数还包括基于用于在物理通信层上传递所述数据包的协议的至少一个协议因子。