CN1841989A - 实现有线网络内的高吞吐量带宽分配的方法和系统 - Google Patents

Abstract

本发明公开了一种实现有线网络内的高吞吐量带宽分配的方法和系统。所述系统包括有线调制解调器终端系统和多个线缆调制解调器。所述方法允许线缆调制解调器使用“信道绑定”技术同事在多个上行信道上向CMTS发送数据。通过针对上行信道绑定组内的每个上行信道从CMTS向线缆调制解调器发送唯一的带宽分配消息，可实现带宽分配，其中所述唯一带宽分配消息的组合总地分配了整个绑定组上请求的带宽。

Description

实现有线网络内的高吞吐量带宽分配的方法和系统

技术领字段

本发明涉及数据通信系统，更具体地说，涉及在有线通信系统中传输数据的方法。

背景技术

传统的有线通信系统一般使用有线调制解调器头端管理与多个有线调制解调器的通信。该头端定义了能使有线调制解调器发送载波信号上行数据流至头端的上行数据流操作特性。上行数据流可包括分配给有线调制解调器的多个信道。这些信道通过在不同频率下工作而彼此分隔开。

一个或多个有线调制解调器使用指定的频道来传送携带有请求和/或数据的载波信号至头端。头端通过与物理频谱连接的解调器接收上行数据流信号，该物理频谱使调制解调器和头端互连。解调器恢复载波信号中含有的请求和/或允许信息，并转发此信息至媒体访问控制器(MAC)以进行额外的处理。

有线运营商希望可以对每个用户提供更高的上行数据流带宽以与光纤到用户(FTTx)以及其它小型商业服务竞争。例如，有线运营商规定了对单个用户或用户群的上行数据流吞吐量目标为100Mbps。但是，在上行数据流中使用很高阶的调制技术(例如1024QAM)和更宽的信道目前来说是不可行的。

因此，需要一种可行的方法和系统以在有线通信系统中提供更高的上行数据流吞吐量。

发明内容

在有线数据通信系统中实现更高的上行数据流吞吐量的一个方法是使一个用户或用户群同时在多个上行信道上进行传输。这种将较小带宽的上行信道绑定在一起建立较大带宽的管道的技术在本申请中又称为“信道绑定”技术。本申请中介绍一种在有线通信系统中实现上行信道绑定的方法和系统。

本说明书描述了一个或多个结合有本发明的特征的实施例。本说明书中描述和引用的实施例，如“一个实施例”、“实施例”、“示例”等等，表示该实施例包括有特定的特征、结构或特性，但不是每个实施例都必须包括该特征、结构或特性。此外，以上词组不一定是指相同的实施例。此外，当在一个实施例中描述某一特征、结构或特性时，对本领字段的普通技术人员来说，很显然该特征、结构或特性还可用于本申请中介绍或未介绍的其他实施例中。

根据本发明的第一实施例，提供一种在有线调制解调器中端系统(CMTS)中实现有线网络内的高吞吐量带宽分配的方法。根据所述方法，多个上行信道被绑定成一组。随后，从有线调制解调器接收带宽请求。作为对接收到所述带宽请求的响应，为所述绑定组中的每个上行信道发出一唯一的带宽分配消息，所述唯一带宽分配消息的组合分配了整个绑定组上请求的带宽，由所述有线调制解调器用于传输数据包流至CMTS。

根据本发明的第二实施例，提供一种在有线调制解调器内实现有线网络内的高吞吐量传输的方法。根据所述方法，传输带宽请求至CMTS。随后，接收到多个带宽分配消息，其中每个带宽分配消息与上行信道绑定组中的一个上行信道唯一地关联，并且所述多个带宽分配消息共同地分配了整个上行信道绑定组上请求的带宽。随后，根据所述多个带宽分配消息通过所述上行信道绑定组将数据包流传输至CMTS。

根据本发明的第三实施例，提供一种实现有线数据网络内的高吞吐量带宽分配的系统。所述系统包括用于绑定多个上行信道的CMTS以及用于发送带宽请求至所述CMTS的有线调制解调器。所述CMTS进一步用于将所述绑定组中每个上行信道的唯一带宽分配消息传输至所述有线调制解调器，其中所述唯一带宽分配消息的组合共同地分配了整个绑定组上请求的带宽。所述有线调制解调器进一步用于根据所述多个带宽分配消息，通过所述上行信道绑定组传输数据包流至所述CMTS。

根据本发明的一个方面，提供一种在有线调制解调器终端系统(CMTS)内实现有线网络内的高吞吐量带宽分配的方法，所述方法包括如下步骤：

将多个上行信道绑定为一组；

从有线调制解调器接收带宽请求；

响应所述带宽请求的接收，为所述绑定组内的每个上行信道发出唯一的带宽分配消息，其中所述唯一带宽分配消息的组合共同地分配整个绑定组上所请求的带宽，以由所述有线调制解调器传输数据包流至CMTS。

优选地，所述为绑定组中每个上行信道发出唯一的带宽分配消息包括为所述绑定组中每个上行信道发出唯一的有线电缆数据服务传输规范(DOCSIS)MAP信息。

优选地，所述方法进一步包括：

通过所述绑定组内的上行信道接收由所述有线调制解调器发送的多个片段，其中所述多个片段在所述唯一带宽分配消息中指定的时间传送，且所述每个片段包括唯一的序列号；

基于所述唯一的序列号将所述多个片段中的信息组合以重建所述数据包流。

优选地，所述方法进一步包括：

分配一组唯一的标识符给所述有线调制解调器，其中每个所述唯一的标识符分别对应所述绑定组内的一个上行信道；

并且所述从有线调制解调器接收带宽请求包括对包括有所述一组唯一标识符中的一个唯一标识符的消息监视所述绑定组内的上行信道。

优选地，所述分配一组唯一的标识符给所述有线调制解调器包括分配一组唯一的标识符给与所述有线调制解调器相关联的服务流。

优选地，为所述绑定组中的特定上行信道发出唯一带宽分配消息包括发出包括有与特定上行信道相关的一个唯一标识符和与此相关的微时隙分配信息的消息。

根据本发明的一个方面，提供一种在有线调制解调器内实现有线网络内的高吞吐量传输的方法，所述方法包括如下步骤：

发送带宽请求至有线调制解调器终端系统(CMTS)；

接收多个带宽分配消息，其中每个所述带宽分配消息与上行信道绑定组中的一个上行信道唯一关联，并且所述多个带宽分配消息共同地分配整个上行信道绑定组上所请求的带宽；

依据所述多个带宽分配消息，通过所述上行信道绑定组传输数据包流至所述CMTS。

优选地，所述接收多个带宽分配消息包括接收多个DOCSIS MAP消息。

优选地，所述依据多个带宽分配消息通过所述上行信道绑定组传输数据包流至所述CMTS包括：

将所述数据包流分割为多个片段；

将唯一的序列号插入每个所述片段内；

在所述多个带宽分配消息指定的时间通过所述上行信道绑定组中的上行信道传输所述多个片段中的每个片段。

优选地，所述方法进一步包括：

从所述CMTS接收一组唯一的标识符，其中每个所述唯一的标识符分别对应所述上行信道绑定组中的一个上行信道；

并且所述发送带宽请求至CMTS包括通过与某一特定的唯一标识符相关联的上行信道发送包括有所述特定的唯一标识符的带宽请求。

优选地，所述方法进一步包括：

将所述一组唯一的标识符与服务流相关联。

优选地，每个所述带宽分配消息包括有对应的一个唯一标识符和与此相关的微时隙分配信息。

根据本发明的一个方面，提供一种实现有线网络内的高吞吐量带宽分配的系统，包括：

有线调制解调器终端系统(CMTS)，用于将多个上行信道绑定为一组；

有线调制解调器，用于发送带宽请求至所述CMTS；

其中所述CMTS进一步为所述绑定组中的每个上行信道发送唯一的带宽分配消息给所述有线调制解调器，所述唯一带宽分配消息的组合共同地分配整个绑定组上所请求的带宽；

其中所述有线调制解调器进一步依据所述多个带宽分配消息，通过所述上行信道绑定组传输数据包流至所述CMTS。

优选地，所述CMTS为所述绑定组中的每个上行信道发送唯一的DOCSISMAP信息至所述有线调制解调器。

优选地，所述有线调制解调器将所述数据包流分割为多个片段，将唯一的序列号插入每个所述片段内，并在所述多个带宽分配消息指定的时间通过所述绑定组内的上行信道组传输所述每个片段至所述CMTS。

优选地，所述CMTS进一步从所述有线调制解调器接收所述多个片段，并基于所述唯一的序列号将所述多个片段内的信息组合以重建所述数据包流。

优选地，所述CMTS进一步分配一组唯一的标识符给所述有线调制解调器，其中所述每个唯一的标识符分别对应所述绑定组中的一个上行信道；

并且所述有线调制解调器通过与某一特定的唯一标识符相关联的上行信道发送包括有所述特定的唯一标识符的带宽请求。

优选地，所述CMTS分配一组唯一的标识符给与所述有线调制解调器相关联的服务流。

优选地，所述CMTS为某一特定上行信道发送包括有与所述特定上行信道相关的一个唯一标识符和与此相关的微时隙分配信息的唯一带宽分配消息。

本发明的各种优点、各个方面和创新特征，以及具体实施例的细节，将在以下的说明书和附图中进行详细介绍。需要注意的是，本发明并不限于本说明书中描述的实施例。本说明书中介绍的实施例仅用于说明的目的。基于本申请提供的启示，其他各种实施例对于本领字段的普通技术人员来说是显而易见的。

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1是根据本发明一个实施例实现上行信道绑定的语音和数据通信管理系统的示意图；

图2是根据本发明一个实施例实现有线网络内的高吞吐量带宽分配和传输的流程图；

图3是根据本发明一个实施例实现有线网络内的高吞吐量带宽分配和传输的流程图；

图4是根据本发明一个实施例具有不同微时隙大小的四个上行信道的信息量分段的示意图；

图5是根据现有的DOCSIS实现的片段级连(fragmented concatenation)的示意图；

图6是根据本发明一个实施例的连续级连(continuous concatenation)和分段(fragmentation)的示意图；

图7是根据本发明一个实施例利用片段头的连续级连和分段的示意图；

图8是根据本发明一个实施例的连续级连和信息量分段的步骤的流程图；

图9是根据本发明一个实施例的连续级连和信息量分段的步骤的流程图；

图10是根据本发明一个实施例实现图8-9中使用片段头进行分段的处理过程的附加步骤的流程图；

图11是根据本发明一个实施例实现图8-9中使用片段头进行分段的处理过程的附加步骤的流程图；

图12是根据本发明一个实施例的捎带请求(piggyback requesting)片段头的步骤的流程图；

图13是根据本发明一个实施例的竞争请求(contention requesting)绑定的上行信道的步骤的流程图；

图14是现有的用于未分段单数据包和未分段数据包级连的具有12字节偏置的DOCSIS信息量编码技术的示意图；

图15是现有的用于分段单数据包的DOCSIS信息量编码技术的示意图；

图16是现有的用于分段数据包级连的DOCSIS信息量编码技术的示意图；

图17是根据本发明一个实施例在分段前对单个MAC帧执行的基线保密接口(BPI)加密的示意图；

图18A是根据本发明一个实施例的支持上行信道绑定的有线调制解调器(CM)的初始化步骤的流程图；

图18B是根据本发明一个实施例的支持上行信道绑定的CM的初始化步骤的流程图；

图19是根据本发明一个实施例的基于队列长度的请求帧格式的示意图；

图20是根据本发明一个实施例的片段头格式的示意图；

图21是根据本发明一个实施例的绑定上行信道描述符(B-UCD)消息格式的示意图；

图22是根据本发明一个或多个实施例在CMTS中使用B-UCD消息改变上行信道绑定组内的信道设置的步骤的流程图。

以上附图中，近似的标号数字表示相同的、功能近似的和/或结构近似的部件。部件第一次出现的附图由对应标号数字中最左边的数字表示。

具体实施方式

1概述

现有的CableLabsCertifiedTM有线调制解调器项目接口规范，又称为有线电缆数据服务传输规范(DOCSIS)，在本说明书中称作“传统”规范(例如，DOCSIS 2.0、DOCSIS 1.1和DOCSIS 1.0)，规定了有线通信系统的接口要求，但没有规定实现上行信道绑定的接口要求。因此，在一个实施例中，本发明实现上行信道绑定技术作为现有DOCSIS接口规范的扩展。有线电视实验室公司(Cable Television Laboratories，Inc.)2005年公布的DOCSIS 2.0射频接口规范SP-RFIv2.0-I04-030730在此作为本申请的引用文件。

1.1系统概述

图1所示为语音和数据通信管理系统100。语音和数据通信管理系统100可支持现有的DOCSIS接口要求，也可支持本发明采用上行信道绑定技术对现有DOCSIS接口要求的扩展。

系统100包括管理通信节点106和一个或多个广泛分布的远程通信节点102a-102n(统称为“远程通信节点102”)。系统100可实现于任何多媒体分布网络中。此外，需要理解的是，本发明的方法和系统管理语音、数据、视频、音频、消息、图形、其他格式的媒体和/或多媒体或上述任何媒体的组合的交换。

管理通信节点106位于中央以命令和控制与远程通信节点102以及远程通信节点102彼此之间的交互操作。管理通信节点106管理上行信息流调制并仲裁远程通信节点102彼此之间的带宽。如下详细描述，管理通信节点106分别通过发送上行信道描述符(UCD)消息和MAP消息至远程通信节点102来建立上行时隙结构和分配上行带宽。一个实施例中，所述UCD和MAP消息由现有的DOCSIS规范来定义。

一个实施例中，管理通信节点106是用于有线通信网络的头端控制器的一个部件。因此，管理通信节点106是有线调制解调器终端系统(CMTS)或其中的一个部件。一个实施例中，至少一个远程通信节点102是有线调制解调器(CM)或其中的一个部件。另一个实施例中，管理通信节点106是CMTS，且至少一个远程通信节点102是电视机机顶盒的一个部件。

作为CM的一个部件，远程通信节点102可传输一个或多个服务给用户。该服务可包括电话、电视广播、收费节目、互联网通信(例如万维网)、无线电广播、传真、文件数据传输、电子邮件服务(email)、消息、视频会议、现场直播或延时媒体播放(如演说、辩论、展示、通知、新闻、体育赛事或演唱会)等等。

每个远程通信节点102分配有一个或多个服务标识符(SID)编码，管理通信节点106使用此SID编码来分配带宽。SID主要用于识别来自远程通信节点102的特定信息流。然而，本领字段的技术人员明显可知，还可以指定其它标识符来区别各个远程通信节点102和/或来自节点102的信息流。因此，一个实施例中，指定SID或其他类型的标识符以识别属于一个或多个远程通信节点102的特定服务。一个实施例中，分配SID或其他类型的标识符来指定与源远程通信节点102无关的特定服务或服务组。一个实施例中，分配SID或其他类型的标识符以指明服务质量(QoS)，如优先级递减的语音或数据、不同压缩算法下的话频线、最佳数据等等。在一个分配多个SID给一个远程通信节点的实施例中，主SID用于识别该远程通信节点或来自该远程通信节点102的普通信息流，而一个或多个其它SID用于识别其它具体的信息流，如电话、视频流、消息、视频会议等等。

一个实施例中，管理通信节点106和远程通信节点102被集成以支持各种协议，如互联网协议(IP)、传输控制协议(TCP)、用户数据报协议(UDP)、实时传输协议(RTP)、资源预留协议(RSVP)等等。

通信管理系统100还包括节间设备(internodal infrastructure)105。如图1所示，节间设备105提供管理通信节点106和远程通信节点102之间的互连。节间设备105支持有线、无线或这两种传输媒介，包括卫星、陆地(例如光纤、铜线、双绞线、同轴线、光纤同轴复合线(HFC)等等)、无线电、微波、自由空间光系统和/或任何其它传输类型或方法。

从管理通信节点106到远程通信节点102的方向上传输的数据流在本申请中称为下行数据流。一个实施例中，下行数据流被分入一个或多个下行信道中。每个下行信道传送不同类型的信息给远程通信节点102。所述下行数据流信息包括电视信号、数据包(包括但不限于IP数据报)、语音包、控制消息等等。一个实施例中，下行数据流的格式为动态图像专家组(MPEG)传输集中子层。然而，本领字段的普通技术人员显然可知，还可以支持其它数据格式。

从远程通信节点102到管理通信节点106的方向上传输的数据流在本申请中称为上行数据流。上行数据流被分入一个或多个上行信道中。每个上行信道将数据包猝发串从远程通信节点102传输至管理通信节点106。本发明的一个实施例中，将多个上行信道绑定在一起成为一个绑定信道组以增加上行数据流的吞吐量。在该上行数据流中，每个信道被分割为多个可分配的时隙(例如，微时隙)，而远程通信节点102在分配的时隙内发送脉冲信号。如上所述，时隙的结构由管理通信节点106来定义和分配。

如图1所示，管理通信节点106的一个实施例包括上行物理层解调器(USPHY)108、下行物理层调制器(DS PHY)110、媒体访问控制器(MAC)112、存储器114、软件应用程序120和主时钟源116。US PHY 108构成管理通信节点106和节间设备105的上行信道之间的物理层接口。管理通信节点106针对每个上行信道具有一个单独的US PHY 108。因此，US PHY 108接收和解调所有来自远程通信节点102的猝发串(bursts)。

相反的，DS PHY 110构成管理通信节点106和节间设备105的下行信道之间的物理层接口。因此，语音、数据(包括电视或无线电信号)和/或预定给一个或多个远程通信节点102的控制消息在DS PHY 110处收集并传输至各自的远程通信节点102。DS PHY 110调制和/或格式化上述信息以便进行下行传输。

MAC 112从US PHY 108接收上行信号或提供下行信号至DS PHY 110。MAC 112用作管理通信节点106的数据链路层的较低子层。在实施例中，MAC112支持分段、级连、有效载荷帧头压缩/扩展和/或对通过物理层(即节间设备105)传输的信号进行误差检查。

存储器114与MAC 112互相通信以存储MAC 112处理的信号。存储器114也存储各种用于支持处理活动的辅助数据。所述辅助数据包括安全协议、标识符、规则、策略等等。

MAC 112通过数据总线118连接至软件应用程序120，所述数据总线118为现有的双向数据总线。软件应用程序120运行在一个或多个处理器(或硬件辅助设备，如场编程门阵列(FPGA)或专用集成电路(ASIC))以接收控制消息、语音和/或来自MAC 112的数据并执行进一步处理。如图所示，软件应用程序120包括分类器/路由器124和带宽(BW)分配控制器128。带宽分配控制器128管理上行和/或下行调制和带宽分配。分类器/路由器124提供分类和/或优先化与远程通信节点102的通信的规则和策略。分类器/路由器124还通过主干网络140将来自远程通信节点102的信号路由至预定的地址。

主干网络140是有线、无线或有线无线结合的局字段网(LAN)、广字段网(WAN)和/或光网络(如企业内部网络、本地互联网、全球互联网(包括万维网)、虚拟个人网络等等)的一部分。因此，管理通信网络节点106使用主干网络140与通信管理系统100外部的另一设备或应用程序通信。所述设备或应用程序可以是服务器、网页浏览器、操作系统、其他类型的信息处理软件(如文字处理软件、电子制表软件、财政管理软件等等)、电视或无线电发射器、另一个远程通信节点102、另一个管理通信节点106等等。

根据本发明的一个实施例，当通信管理系统100用于实现上行信道绑定时，该上行信道必须与主时钟源116同步。同步将在第8节中详细讨论。

1.2信道绑定概述

如上所述，在有线通信系统中实现较高的上行信息流吞吐量的一个方法是使单个用户或用户群可同时通过多个上行信道进行信息传输。本发明的一个实施例中，上行信道绑定过程由CMTS作为带宽允许过程(bandwidth grantingprocess)的一部分来控制。例如，CMTS可以是通信管理系统100的管理通信节点106，如图1所示。

当CM为与其相关的一个上行信道上的给定服务流发出带宽请求时，CMTS选择是否在给定信道或多个信道上允许该请求。CMTS负责对各个上行信道分配带宽。这种集中控制可使系统达到最好的统计多路复用可能，并允许CMTS执行绑定组内的上行信道的实时负载平衡。当CM接收到多个信道的带宽允许(bandwidth grants)后，CM根据每个允许的传输时间和每个允许的大小分割其传输。CM在每个允许内传送的信息内放置一个递增的序列号。该允许可以在任何或所有上行信道上及时交错，并要求CM在所有绑定的上行信道上同时进行传输。随后，CMTS使用置入该信息中的序列号以重建原始数据流。

本发明的一个实施例要求上行信道与主时钟源(如图1所示的主时钟源116)同步。尽管不必实现在本发明中，但是这一同步要求简化了CM中的时钟字段和时序恢复。除了该同步要求，对上行绑定组中的任何信道的物理层(PHY)参数不再有其他要求。所述各个信道可以是DOCSIS 2.0规范中规定的调制类型、符号率、TDMA(时多分址)或S-CDMA(同步码多分址)的任意混合，并可以是临近或非临近上行信道的任意组合。

图2是根据本发明一个实施例在CMTS内实现有线网络内的高吞吐量带宽分配的步骤的流程图200。流程图200的步骤，如下进一步描述，可应用于图1所示的语音和数据传输管理系统100，其中管理通信节点106对应CMTS，远程通信节点102对应CM。

处理过程开始于步骤205，CMTS接收来自CM的带宽请求。请求的带宽将由CM用于传输数据包流至CMTS。在步骤210中，CMTS选择是否允许CM对单个上行信道或属于一个绑定组的几个上行信号所请求的带宽。如步骤215所示，如果CMTS选择对单个上行信道允许请求的带宽，那么处理跳至步骤230，在步骤230中CMTS通过以现有的方式对单个上行信道发出一个或多个允许来分配所请求的带宽。随后步骤235中，在该允许期间内，CMTS接收由CM以现有的方式发送的数据包流。

然而，如果在步骤215中CMTS选择对绑定上行信道组中的所有信道允许所请求的带宽，那么处理跳至步骤220，在步骤220中，CMTS通过对该绑定组中的每个上行信道发送一个或多个允许来分配所请求的带宽。如下详细描述，该步骤涉及为绑定组中的每个上行信道发送单独的MAP信息。在步骤220执行过程中，CMTS还执行与绑定组中所述多个上行信道相关的实时负载平衡。随后，在步骤225中，CMTS基于每个允许期间通过绑定组中每个信道发送的数据或信息量内嵌入的序列号来重建所述由CM发送的数据包流。需要注意的是，参照图1，此处所描述的带宽分配功能由管理通信节点106中的带宽分配控制器128执行。

图3是根据本发明一个实施例在有线调制解调器内实现有线网络内的高吞吐量传输的步骤的流程图300。流程图300中的步骤，如下进行详细描述，可在图1所示的语音和数据通信管理系统100中实现，其中管理通信节点106对应CMTS，以及远程通信节点102对应CM。

处理开始于步骤310，在步骤310中，CM发送带宽请求至CMTS。请求的带宽由CM用于传输数据包流至CMTS。在步骤320中，CM从CMTS接收对应带宽请求的允许，所述允许适用于属于一个绑定组的多个上行信道。如下详细描述所述，步骤320涉及为绑定组中的每个上行信道接收单独的MAP信息。在步骤330中，CM根据每个允许的传输时间和允许的大小将数据包的传输进行分割。需要注意的是，该允许可以在任何或所有上行信道上及时交错，并要求CM在所有绑定的上行信道上同时进行传输。在步骤330过程中，CM对在每个允许期间传输的信息量内嵌入递增的序列号。这些序列号由CMTS用于重建原始数据流。

1.3术语

如上所述，一个实施例中，本发明的上行信道绑定技术实现为现有DOCSIS接口规范的扩展。因此，以下介绍几个新的术语以描述上行信道绑定接口规范，即现有DOCSIS接口规范的扩展规范。

本申请中所使用的术语“绑定的上行信道描述符(B-UCD)”指规定包含于上行绑定组内的信道标识符的下行信息。

术语“片段”描述带宽分配，可包括下面的特性：(1)分配给特定的SID(即，可以是单播、多播或广播)；(2)由连续的微时隙组成；(3)使用特殊的时隙使用码(IUC)。

用于描述实现上行信道绑定的现有DOCSIS接口规范的扩展规范的这些新术语以及其他术语将在接下来的章节中进行详细描述。

2.信息分段(Traffic Segmentation)

2.1分段概述

如上所述，上行信道绑定是实现有线通信系统中较高的上行信息吞吐量的一种方法。在本发明的一个实施例中，CMTS将上行信道绑定处理作为带宽允许处理的一部分来控制，并基于CM请求的带宽及上行信道上的其它信息量决定如何分割带宽。

一个绑定组中的上行信道可具有非常不同的物理层特性。例如，一个信道可支持160ksps的速率以及正交相移键控(QPSK)数据区和TDMA帧，而另一个信道可支持2.56Msps的速率以及64QAM数据区和S-CDMA帧。集中控制使得CMTS可执行绑定组中不同上行信道的实时负载平衡。

图4是根据本发明一个实施例的具有不同微时隙大小的四个上行信道405、410、415和420的信息量分段的示意图。405、410、415和420中每行代表一个上行信道的带宽。垂直线划分出微时隙的边界。为了最小化图4要求的水平空间的大小，该示例使用比传统的DOCSIS网络更短的数据包。然而，该示例中的垂直线也可以代表多个微时隙而不是一个微时隙。

图4中块内的字母A-D表示CMTS已分配了对应模块带宽的服务流。在这个示例中，CMTS选择允许服务流A的请求，允许服务流A仅使用信道405和信道410的带宽。同样地，CMTS选择允许服务流B仅使用信道415和信道420的带宽。CMTS选择允许服务流C使用所有四个上行信道405、410、415和420上的带宽。表示服务流E和服务流D的块代表对非请求允许服务(UGS)流的小量允许(small grant)。

图4中分配给同一信道中的同一服务流的每组相邻块/微时隙表示一个片段。因此，对服务流B的允许包括2个片段425和430，对服务流C的允许包括4个片段435、440、445和450。由于对信道405上的服务流A的允许由被服务流E分开的2个部分组成，因而对服务流A的全部允许由3个片段组成，即信道405中的片段455和460及信道410中片段465。从物理层开销(overhead)的角度来看，这些片段的每一个被看作是一个现有的DOCSIS允许。每个片段在开始处需要有头码，在末尾处需要有保护时间(guard time)。每个片段的物理层属性由信道的物理参数和该片段的IUC类型来指定。

2.2连续级连和分段

以上定义了通用带宽分段结构，有效填充允许的带宽片段的机制将在下面描述。为了描述本发明的有效填充允许的带宽片段的实施例，对比本发明的实施例和现有的方法有助于理解本发明。例如，一种现有的填充允许的带宽片段的方法是以下将要介绍的现有DOCSIS级连和分段技术。

2.2.1现有的DOCSIS级连和分段

现有的DOCSIS系统中，CM决定是否在某个时间发送一个数据包或一组数据包(即，级连)上行数据流，并发送一个请求，请求传输给定信息量所需的带宽量。CMTS决定其如何允许请求的带宽以及是否以一个允许或整个时间段上的多个允许来分配带宽。如果CMTS决定以一个允许来允许该请求，CM不做任何修改即传输该信息。如果CMTS决定以分分布在整个时间段上的多个允许来允许该请求，则CM必须分割该数据包或数据包的级连。现有的DOCSIS分段方法在每个片段内封包有片段头和片段循环冗余码(CRC)，对每个片段增加总数为16字节的开销。利用现有的DOCSIS封包技术获得的片段与未分段的DOCSIS帧看起来相同，从而使CMTS硬件具有更兼容的功能。

现有的DOCSIS系统要求请求和允许之间握手(handshaking)以避免不必要的分段。如果CMTS发送的允许对于CM尝试上行发送数据包或数据包的级连来说太小的话，这种分段就会发生。为了使CM和CMTS在请求/允许过程中保持对齐，现有的DOCSIS系统使用CM仅有一次突出的请求的惯例。所述一次突出请求规则(one request outstanding rule)可避免某些请求/允许对齐的问题。在一个示例中，一次突出请求规则可避免下面的情况：CM发送2个请求，一个为数据包A请求100个微时隙，另一个为数据包B请求75个微时隙，并且因为两者之间的竞争，CMTS只接收到为数据包B的请求。在另一个示例中，一次突出请求规则可避免下面的情况：CMTS接收针对数据包A和B的请求，在两个单独的DOCSIS MAP消息中允许该请求，并且第一MAP消息因为噪音脉冲串的原因而丢失。一次突出请求规则可避免某些请求/允许对齐问题，但不能解决所有的问题。

同样的，总是会发生错误情况，导致CMTS和CM出现请求/允许不对齐的情况。一种错误情况是CMTS未准确地设置其每个MAP内的确认时间，或者CMTS不恰当地忽略掉对请求已被考虑但尚未允许的SID的未决定的允许。MAP中不准确的确认时间会导致CM发送数据包请求时，因为接收的确认时间不准确而认为请求被丢失，并重新请求数据包的情况。同时，CMTS允许最初的请求，并随后允许来自CM的再次请求，认为该再次请求是对另一数据包的新请求。这一事件顺序导致对于CM来说该允许是未被请求的允许。CM会尝试对任何在其队列中接下来出现的数据包使用这个“未被请求的允许”，如有需要，还将分割该数据包。依靠请求和允许的时间，上述系统将保持请求/允许的不一致(由多余的允许而产生)直到所述SID的信息流停止。

除了因为分段开销而导致的带宽浪费之外，现有的分段级连DOCSIS封包方法还因发送片段的规则而导致带宽的低效率。只要CM在传输片段，且MAP中没有尚未决定的允许，不关其序列中是否有其它数据包到达，CM发送带宽请求，请求发送剩下的数据包所需要的带宽。CM不能为新数据包请求额外的带宽，直到CM接收到足够的允许以发送剩下的片段。此外，对于一个允许，最后一个片段内的任何额外空间都不能用于其他数据包，CM必须插入填充信息(padding)以填满浪费的空间。

图5是现有的分段级连的DOCSIS封包方法的示意图。图5中示出了数据包的原始级连505，CM为该数据包发送带宽请求，图中还示出了待传输的后续数据包的队列510。CM接收到3个允许515、520和525，并将原始级连505分割入3个传输允许中。每个传输515、520和525包括对应的分段的片段头535a、535b和535c。如图5所示，片段级连的DOCSIS封包方法的缺点是CM必须使用填充信息(padding)540填充该允许中浪费的带宽，而不是使用队列510中下一个待传输的数据包来填充第三允许525。

正像在某些情况下现有的片段样级连DOCSIS封包方法导致带宽的浪费一，现有的DOCSIS级连使用包含整个级连的长度信息的级连头(concatenationheader)，因而效率也很低。因此在未改变级连头的情况下，不能随后将数据包加入该级连中。如果到达CM的允许足够的大，以至于能包含该连接以及该级连开始后到达的额外数据包，CM也不能将新的数据包加入该级连中。

例如，如图5所示，原始级连505包括包含级连505的长度信息的级连头530。因此，CM必须使用填充信息540来填充第三允许525，而不是使用来自队列510的下一个待传输的数据包填充允许525。有些情况中，改变级连结构特别有用，例如，当一个级连被分割时，当PHY参数和微时隙大小间隔尺寸导致一个猝发串中有太多未使用的字节时，以及当CM接收到其认为是未被请求的允许时。

2.2.2本发明的连续级连和分段

根据本发明的一个或多个实施例，提供一种当请求和允许不匹配时，实现更有效的带宽使用的新机制，具有较小的片段开销并允许在级连传输开始后改变该级连的长度。当允许的大小和数据包边界不一致时，这种机制能实现更有效的带宽使用。一种这样的机制嵌入在连续级连和分段(CCF)的概念中。与现有的DOCSIS封包方法不同的是，CCF采用数据流类型的方法。数据包在不使用级连头的情况下插入到允许的带宽中。

图6是根据本发明一个实施例的CCF的示意图。图6中示出了数据包的原始级连605，CM为其发送了带宽请求，还示出了随后待传输的数据包的队列610。与图5中所示的方法不同的是，CM在未使用分段头的情况下，将原始级连605分割入3个允许615、620和625中。在这种情况下，CM使用队列610中随后待传输的数据包填充第三允许625，所以没有带宽浪费。

在图5所示的现有DOCSIS方法中，因为使用了包含级连505的长度信息的级连头530，带宽被浪费。CM必须使用填充信息540填充第三允许525，不传输整个队列510的数据包，而不是使用队列510中随后待传输的数据包填充第三允许525。在图6所示的CCF方法中，因为没有使用级连头，所以没有带宽浪费。CM可使用队列610中随后待传输的数据包填充允许625，仅留下数据包630待传输，而不是使用填充信息(padding)。

在图6所示中CCF实现中，一旦上行猝发脉冲因噪音而丢失，CMTS MAC层便无法找出一组允许中数据包的边界。在现有的DOCSIS下行数据流中，使用MPEG指针来指出MPEG帧中DOCSIS MAC头的开始。在上行方向中，通过定义，脉冲MAC边界总是与数据包、级连或片段头的开始对齐。在图6的CCF实现的例子中，然而，如果允许620中的数据因为噪音而丢失，MAC层便无法找出允许625内的数据包的边界。因此，CCF需要一个附加的机制以区分DOCSIS帧边界。

根据本发明的一个实施例，使用CCF填充允许的带宽的一种有效率的机制是使用片段头来帮助重建数据。在一个实施例中，片段头包含有指向片段中第一DOCSIS头的指针。所述指针与现有DOCSIS下行数据流中用以识别数据包边界的MPEG指针近似。通过对每个片段使用固定的开销，无论何时CMTS选择分割一个允许为多个较小的允许，CMTS可很容易地计算出其必须允许多少额外的带宽。

图7是根据本发明一个实施例利用片段头的CCF技术的示意图。图7中示出了数据包的原始级连705，CM为其发送了带宽请求，还示出了随后待传输的数据包的队列710。在这种情况下，CM分别使用片段头730a、730b和730c将数据包原始级连705分割为3个允许715、720和725以便传输。允许715内的片段头730a指向片段头730a后的第一字节。允许720内的片段头730b指向第三数据包737的DOCSIS头736。允许725内的片段头730c指向第六数据包742的DOCSIS头741。因此，如果任何片段丢失，CMTS仍可找到余下的片段的数据包边界。CMTS MAC使用允许的大小来确定从每个允许中提取出多少个MAC字节。只要CM没有待发数据，CM与其在现有DOCSIS系统中一样填充该允许。

片段头格式的例子在本说明书7.2节中详细描述。在一个实施例中，片段头含有可选的捎带字段(piggyback field)，CM可使用该字段来请求额外的带宽。使用可选的捎带字段的规则在本说明书3.2.1节中详细描述。

片段头的使用占用每个片段相对较小的开销，实现允许带宽的最佳使用。如果没有片段头，CCF技术将不得不阻止数据包生成片段边界，潜在地浪费大量的上行带宽，或者，不得不接受在出现片段丢失的情况下因CMTS不能找出MAC帧的边界而产生的大大增加的误码率。

图8-9是根据本发明一个或多个实施例的连续级连和信息量分段的步骤的流程图。图10-11是根据本发明一个或多个实施例使用片段头实现图8-9所示的分段处理的附加步骤。

图8是在CM内实现连续级连和信息量分段的步骤的流程图800。在步骤805中，CM请求带宽以发送上行队列中的数据包。在步骤810中，CM接收多个来自CMTS的允许。所述允许将请求带宽的分配定义为多个绑定的上行信道上的多个微时隙。

在步骤815中，CM将队列中的数据包级连。在另一个实施例中，当分配的带宽超过请求的带宽时，CM连续的级连队列中的数据包，这样的话，已在队列中的数据包与新到达的数据包级连，直到该多信道允许被填满。例如，图7所示为CM如何将原始级连705中的数据包与来自队列710的随后待传输的数据包级连以填充允许725。在另一个实施例中，当队列为空时，CM以固定字节的形式(例如，对上行信道绑定的“FF”)填充该允许的带宽。

在步骤820中，CM通过将级连的数据包分割为多个片段来填充多个允许。每个片段的大小对应一个上行信道中相邻微时隙的子集。CM在未使用DOCSIS级连头的情况下使用级连的数据包填充该允许。在步骤825中，CM将上述片段发送至CMTS。

图10是使用带片段头的分段方法实现图8中步骤820的额外步骤。在步骤1005中，CM分割至少一个级连的数据包，从而使被分割的数据分布在多个片段中。在步骤1010中，CM在每个片段中插入片段头以帮助区分片段内的数据包边界。例如，如图7所示，CM分别将片段头730a、730b和730c插入允许715、720和725中以便传输。在另一个实施例中，片段头中包括指向该片段内第一DOCSIS头的地址的指针。例如，如图7所示，片段头730b指向片段720的第一DOCSIS头736。当该片段没有第一DOCSIS头时(例如一个大数据包分成两个以上的片段时位于中间的片段)，片段头中的指针有效位被清除。在另一个实施例中，片段头包括有固定量的开销。

图9是在CMTS内实现连续级连和信息量分段的步骤的流程图900。在步骤905中，CMTS从CM接收用于传输上行队列中的数据包的带宽请求。在步骤910中，CMTS发出多个允许，将请求的带宽分配为多个绑定的上行信道上的多个微时隙。在步骤915中，CMTS从CM接收多个片段。所述片段包括队列中数据包的级连，并且每个片段的大小对应于一个上行信道内的相邻微时隙的子集。在步骤920中，CMTS从接收的片段中重建数据包队列。

图11是使用带片段头的分段方法实现图9中步骤915和920的附加步骤。在步骤1105中，CMTS接收多个片段，该多个片段包括有至少一个被分成多个片段的数据包。在步骤1110中，CMTS基于插入每个片段的片段头中的信息重建数据包队列。在一个实施例中，CMTS基于每个片段头内指向对应片段中第一DOCSIS头的指针重建数据包队列。

2.2.3不带片段头的分段

某些服务流具有唯一的属性，所述属性使得CMTS在CM未发送请求的情况下便已知传输的大小。在这种情况下，根据本发明的一个实施例，CCF中片段头的使用可使用现有的DOCSIS请求/传输策略基于服务流来激活和禁用。请求/传输策略的值将规定对于一个特定服务流，片段头是否激活或禁用。对于片段头被禁用的服务流，CM仍可使用CCF的级连部分，但禁止使用分段部分。因此片段头被禁用的服务流的所有片段仅包含完整的数据包或多个完整的数据包。若一个片段丢失，CMTS MAC可知，下一片段的边界与数据包的边界一致，并可继续处理接收的数据包。

在片段头被禁用的情况下，CMTS不能对服务流分配一个以上的上行信道的带宽。这一约束的原因是整个信道上的数据包顺序在没有片段头的情况下不能得到保障。

当规定对服务流进行片段头禁用操作时，捎带请求时应使用现有的DOCSIS基线保密接口扩展头(BPI EHDR)或现有的DOCSIS请求扩展头(EHDR)。EHDR字段提供对MAC帧格式的扩展，用于现有的DOCSIS系统以实现数据链路安全以及帧分割，但还可进行扩展以支持附加功能，例如当服务流被规定进行片段头禁用操作时的捎带请求。片段头激活时，不需要EHDR内的请求字段，这时因为片段头格式允许进行捎带请求。

需要注意的是，片段头禁用操作用于UGS数据流以及其他类型的CMTS已知服务该数据流需要的带宽量的数据流。本领字段的普通技术人员可知，为了处理允许的片段比请求量小的情况，还可以定义片段头禁用操作的其他用途(例如最佳效果)，以增强请求/传输策略和CM操作规则。

片段头激活/禁用操作以每个数据流为基础来规定。UGS服务可既适用于片段头激活操作又适用于片段头禁用操作。

执行片段头禁用操作的一个理由是最小化UGS流的开销。对于小的数据包来说，即使是增加2字节，相对于发送的数据量来说也是很大的开销。通过对UGS数据流提供片段头禁用操作，本发明的一个实施例可将这些小数据包的开销最小化。

3.请求带宽

为了描述本发明使用绑定的上行信道请求带宽的实施例，本申请中将所述实施例与现有的方法进行对比以帮助理解。例如，现有的DOCSIS请求/允许机制允许CM针对CM支持的每个上行流SID请求单个数据包或多个数据包的级连。一旦CM针对给定的SID发送带宽请求后，CM必须等到它接收到来自CMTS的分配带宽的允许(或多个允许)后，才能针对同一SID请求额外的带宽。这些约束(即一次仅有一个请求突出和一个数据包或级连)在大多数情况下可以防止CM和CMTS的请求/允许出现不一致。在上行吞吐量为大约100Mbps时，需要修改现有的DOCSIS请求/允许机制以允许CM在给定的时帧内请求更大量的带宽。

对上行信道绑定的系统的一种这样的修改是给定与特定SID相关的QoS参数的情况下，允许CM对所有准备好发送的数据包请求带宽。除了对某些服务流的限制比对传统信息流的限制高之外，所述方法与现有的建立最大可允许级连的DOCSIS方法类似。因为，通常情况下，CM会请求更多的带宽，CM想要在一个请求内请求更多的带宽。

现有DOCSIS系统使用负荷请求(burdened requesting)方法来允许CM为已准备发送的数据包请求带宽。使用负荷请求，CM以“负荷”微时隙的形式请求带宽。负荷请求包括有对传输数据包所需要的PHY开销的估算。在现有DOCSIS系统中，PHY“负荷”的计算由CM在其发送请求前执行。负荷请求可以简化CMTS处的计算，因而CMTS可不需要做任何额外的计算就可以很容易的允许请求的带宽。然而，由于CM能够同时在具有不同PHY参数的多个上行信道上进行传输，以及CMTS能够在多个上行信道上对给定的CM允许带宽，负荷请求导致CMTS的工作量增加。如果负荷请求用于绑定的上行信道系统中，为了估算原始的有效载荷大小，CMTS必须执行反向计算以减少PHY开销。然后，CMTS必须将有效载荷分割在多个上行信道上并计算与每个部分允许相关的PHY开销。

在本发明的一个实施例中，绑定的上行信道系统使用卸载请求(unburdened requesting)方法允许CM为已准备发送的数据包请求带宽。使用卸载请求方法，CM以“卸载”字节的形式请求带宽，因为CM不知道CMTS会选择哪个信道以允许请求的带宽。

在一个实施例中，请求字段被扩展以包括2字节的长度字段以及4字节的间隔(granularity)，以允许CM在单个请求内可请求最高256千字节。如果CM需要在给定的时间为特殊的服务流请求大于256千字节，CM必须等到第一请求被确认后才能请求额外的带宽。256千字节的最大请求大小可实现长达20ms的MAP周期，假如这样的话，可允许单个服务流发送最高100Mbps的数据传输率。在一个实施例中，请求大小的间隔可通过绑定上行信道描述符(B-UCD)消息进行编程，并可编程为除4字节之外的其它值以获得256千字节的最大请求大小。

3.1请求机制

如上所述，一种实现更大上行带宽请求的机制是允许CM请求其当前基于已准备上行发送的数据包所需要的所有上行带宽。所述请求机制允许CM基于队列长度发送带宽请求至CMTS，该队列长队包括所有的上行数据包以及数据包的已知MAC头。根据本发明的一个实施例，基于队列长度的请求必须与上述CCF技术结合使用，因为CMTS不知道单个数据包的边界，且在没有找出数据包边界的情况下，不能允许请求。当针对队列长度发送请求时，CM考虑所有想要传输的数据包及所需要的带宽量，包括所有已知的MAC层开销。在一个实施例中，图3所示的步骤310可通过基于队列长度的请求来实现，这样的话，CM基于数据包的上行队列的长度来发送带宽请求至CMTS。在另一个实施例中，图3所示步骤310可通过基于队列长度的请求来实现，因此，带宽请求包括与上行队列中数据包相关的MAC层开销所需的带宽。

根据本发明的一个实施例，当针对队列长度发送请求时，CM请求的带宽不包括片段头开销的任何估算值，因为CM不知道CMTS会使用多少个片段来分割其允许带宽。相反，当CMTS发送允许至CM时，CMTS将必要的附加带宽加入以补偿片段头的开销。在一个实施例中，如图8所示，当在处理流程800中使用具有片段头的分段方法时，CM不为片段头开销请求带宽。在这种情况下，在步骤805中，CM请求卸载带宽量(unburdened amount ofbandwidth)以传输上行队列的数据包；在步骤810中，CM接收来自CMTS的多个允许，该允许中包括有附加的带宽量以为每个片段头的固定开销提供带宽。同样地，在另一个实施例中，如图9所示，在处理流程900中使用具有片段头的分段方法时，CMTS补偿片段头的开销。在这种情况下，在步骤910中，CMTS发出多个包括有附加带宽的允许，以为每个片段头的固定开销提供带宽。

根据本发明的一个实施例，CM为任何CM可用的上行信道上的给定服务流发送带宽请求。在一个实施例中，如图3的步骤305中，CM在可用的上行信道上发送带宽请求至CMTS。CMTS可选则对其接收该请求所使用的上行信道允许带宽，或对任何其它与CM相关的上行信道，或对任何与CM相关的上行信道的组合允许带宽。

为了为上行信道上的SID分配提供最大的灵活性，根据本发明一个实施例的系统识别一组由上行信道绑定组中的每个上行信道的一个SID组成的SID组，并且从请求/允许的角度来看，这些DIS视为相同。这样一组SID在本申请中称为“SID_Cluster”。SID_Cluster的一个例子如表1描述。

SID_Cluster	US#1 SID	US#2 SID	US#3 SID	US#4 SID
					Cluster_0	58	479	85	1001

表1：  SID_Cluster示例

SID_Cluster由CMTS分配给CM上的特定服务流。在上述分配后，只要CM使用所述服务流做出请求，CM就必须使用适用于其用于发送请求的上行信道的由SID_Cluster指定的SID。例如，参照表1所示的SID_Cluster示例，当在上行信道2(US#2)上发送带宽请求时，与SID_Cluster0相关联的CM将使用SID 479。同样地，无论CMTS何时允许与特定SID_Cluster相关联的一个CM的请求，都必须使用由适用于选择的上行信道的SID_Cluster指定的SID来允许该请求。例如，仍然参照表1中的示例，如果CMTS选择使用上行信道3(US#3)允许来自SID 479的请求，CMTS将为上行信道3(US#3)在MAP内设置对SID 85的允许。

根据本发明的一个实施例，CMTS使用针对每个信道的单个MAP来发送所有信道上的允许。如果CMTS决定不允许所有的请求带宽，可以在MAP信息中发送传统的DOCSIS允许未决(grant pending)(其为零长度的允许，表示一个请求已经被接收并处于未决状态)，直到接收的所有针对该SID_Cluster的请求被填满。或者，CMTS可选则不发送允许未决，并让CM再次请求所需的带宽的余下部分。

根据本发明的一个实施例，当CM做出带宽请求时，其必须存储所请求信道(即，CM发送请求的上行信道)上的微时隙计数值，以及发送请求时信道绑定组中的其他信道上的下一个最接近的微时隙计数值。随后，CM查找对绑定组内所有信道上的请求SID_Cluster的允许。如果绑定组中所有信道的MAP内的确认时间超过了请求的时间，并且在任何一个上述MAP中均没有针对请求SID_Cluster的允许未决，则CM需要再次请求该原始请求中的任何未允许的部分。当CM做出该再次请求时，其包含有用于待发送的信数据包的新请求带宽。

对于给定的SID_Cluster，CM被允许有多个突出的请求(outstandingrequests)，并且当服务流被提供时，可对该服务流提供不止1个的SID_Cluster。一旦CM为服务流发送带宽请求，用于该服务流的请求/传输策略控制CM在接收到允许或允许未决形式的确认前，是否可以针对该服务流做出另一个请求。如果请求/传输策略禁止做出多个突出的竞争请求，则CM不能不能请求额外的竞争带宽，直到其接收到表示CMTS已经接到到带宽请求的确认。该确认可采用允许或允许未决的形式。一旦CM接收到确认后，便可请求额外的带宽，尽管CMTS尚未填满之前的请求。前述内容在接下来的例子中给出说明，该示例中CM在其初始请求中请求16千字节。作为响应，CMTS决定以2组8千字节的允许形式来允许CM的请求，其中每个允许加上了分段开销，并且该两组允许在时间上分隔来并出现在不同的MAP中。CM接收到第一允许后，其请求已经被确认，现在CM可为任何自CM做出初始请求后到达的新的数据包做出请求。

如上面提到的，根据本发明的一个实施例，可将不止一个的SID_Cluster分配给一个服务流。该服务流的请求策略参数决定何时CM在SID_Cluster之间切换。在一个实施例中，需要CM和CMTS支持每个服务流至少2个SID_Cluster。CMTS被要求始终使用同一SID_Cluster进行允许。当下述任何一种情况发生时，CM需要停止在给定SID_Cluster上做出请求：(1)达到每个SID_Cluster突出请求的最大数量；(2)达到每个SID_Cluster突出字节的最大数量；(3)达到每个SID_Cluster请求的最大总字节数；或(4)达到SID_Cluster内的最大时间。

根据本发明的一个实施例，CM不能在一个时间内使用不止一个的SID_Cluster为给定的服务流请求带宽。CM可在任何时间切换至不同的SID_Cluster，但在上述4种情况下，需要停止对当前SID_Cluster做出请求。一旦CM停止使用特定的SID_Cluster，就不能再使用该SID_Cluster来请求带宽，直到针对该SID_Cluster的所有余下的带宽请求均被满足。如果绑定组中所有信道上的确认时间段超过了请求时间，并且在当前MAP中没有出现允许未决，那么，如果请求仍未被填满，则CM使用任何可用于请求的SID_Cluster来再次请求该SID_Cluster上尚未允许的带宽。

因为CMTS可使用多组允许以允许来自单个请求的带宽，可能发生的情况是CM和CMTS会因为请求丢失和MAP丢失而暂时不一致，其中该请求丢失因出现上行脉冲错误和冲突而产生，该MAP丢失因下行错误而产生。根据本发明的一个实施例，CM必须使用请求的确认时间来在决定进行再次请求前确定CMTS是否已经接收到该请求。无论何时CM接收到针对上行绑定组中任何信道上的MAP中的请求SID_Cluster的允许未决，CM都不能对SID_Cluster再次请求带宽。依据服务流的请求策略参数，CM可以请求用于该服务流的上行传输的新带宽。一旦CM接收绑定组中所有信道上的MAP，且该MAP不包括给定SID_Cluster的允许未决时，依据请求策略参数，CM可使用捎带机会或竞争机会请求任何未传输的数据包的带宽，其请求时间早于当前MAP内的确认时间。需要注意的是，请求时间迟于确认时间的请求仍可处于传送中或等待CMTS的处理。在确定是否需要再次请求前，CM需要等待在绑定组中所有信道上的确认时间超过请求时间。这一要求可实现CMTS信道调度器的独立操作。

在丢失MAP过程中的操作中，假设CM在其初始请求中发送16千字节请求。CMTS接收该请求并发送包含有对该CM的一组允许的一组MAP(一个MAP信息对应一个上行信道)。一个MAP因为脉冲噪音被损坏，所以CM抛弃该MAP信息。同时，CM接收针对其它上行信道的未损坏的MAP。CM根据正确接收的MAP中的允许传送数据包。因为CM未收到针对其中一个信道的MAP，该MAP包含有超过请求时间的确认时间，所以，CM不能够在此确定是否所有的请求均被允许。下一组MAP到达，CM注意到所有信道上的确认时间超过请求时间，并且针对该请求SID_Cluster没有允许未决。CM由此可知，CMTS没有针对该SID_Cluster的突出的请求。然而，CM仍有待发送的来自原始16千字节请求的数据。CM针对该16千字节中的余下部分以及任何新的准备好为该服务流上行发送的数据包发送新的带宽请求。

3.2捎带请求(piggyback requesting)

捎带请求涉及到用于请求额外带宽的单播数据分配中带宽的使用。该请求的效果是在数据传输的顶部“捎带”。在本发明的一个实施例中，CM何时可为给定的服务流捎带请求的规则基于CCF中是否使用了片段头。片段头的使用以每个服务流为基础。使用片段头和禁用片段头的捎带请求的规则的示例在下面提供。

3.2.1使用片段头的捎带请求规则的示例

捎带请求基于每个服务流执行，因此CM仅可捎带为其发送数据的同一服务流请求的带宽请求。

当针对上行绑定组内任一信道的MAP内出现针对请求SID_Cluster的允许未决时，CM不能为之前使用该SID_Cluster发送请求的数据包请求带宽。CM可捎带之前未使用该SID_Cluster发送请求的数据包的带宽请求。

当CM为上行绑定组内的每个信道接收针对请求的SID_Cluster没有出现允许未决的MAP时，若该绑定组内所有信道的MAP内的请求时间早于确定时间时，CM可再次请求之前已请求的带宽。CM也可在该请求中包含任何新到达的数据包的带宽。

图12是根据本发明一个实施例在CM内使用片段头的捎带请求的流程图1200。该处理流程中假设CM之前已经针对给定的与特定上行绑定组相关联的SID_Cluster发送了带宽请求给CMTS。

流程图1200开始于决定步骤1205。如果，在步骤1205中，片段头被激活，那么流程1200进行至步骤1210。在决定步骤1210中，如果从CMTS接收的MAP包括有对上行绑定组中一个信道的允许未决，那么，在步骤1215中，CM使用片段头内的捎带字段(piggyback field)仅为上行队列中新到达的数据包请求额外的带宽。然而，如果从CMTS接收的针对上行绑定组中每个信道的MAP中没有允许未决，那么，在步骤1220中，若每个MAP内的请求时间早于确认时间，CM使用片段头中的捎带字段再次请求之前已请求的带宽。在另一个实施例中，在步骤1220中，CM还使用片段头中的捎带字段为上行队列中任何新到达的数据包请求带宽。

3.2.2禁用片段头的捎带请求规则的示例

当用于某一服务流的片段头被禁用时，CM可使用BPI EHDR或请求EHDR发送捎带请求。当CM为其希望发送捎带请求的原始数据发送请求时，CM必须使用BPI EHDR或请求EHDR。

当针对上行绑定组内任一信道的MAP内出现针对请求SID_Cluster的允许未决时，CM不能为之前使用该SID_Cluster发送请求的数据包请求带宽。CM可捎带之前未使用该SID_Cluster发送请求的数据包的带宽请求。

当CM为上行绑定组内的每个信道接收针对请求的SID_Cluster没有出现允许未决的MAP时，若该绑定组内所有信道的MAP内的请求时间早于确定时间时，CM可再次请求之前已请求的带宽。CM也可在该请求中包含任何新到达的数据包的带宽。

再参照图12，流程1200所示为当片段头被禁用时CM内捎带请求的步骤。该处理流程中假设CM之前已经针对给定的与特定上行绑定组相关联的SID_Cluster发送了带宽请求给CMTS。

处理开始于决定步骤1205。在步骤1205中，如果片段头未被激活，流程1200进行至决定步骤1225。根据决定步骤1225，如果从CMTS接收的MAP中包括有对上行绑定组内的一个信道的允许未决，那么，在步骤1230中，CM使用BPI EHDR或请求EHDR仅为上行队列中新到达的数据包请求带宽。然而，如果从CMTS接收的对上行绑定组内每个信道的MAP中没有允许未决，那么，在步骤1235中，当每个MAP中请求时间早于确认时间时，CM使用BPI EHDR或请求EHDR再次请求之前已请求的带宽。在另一个实施例中，在步骤1235中，CM还使用BPI EHDR或请求EHDR为任何新到达的数据包请求带宽。

3.3竞争请求(contention requesting)

根据本发明的一个实施例，在绑定上行信道系统中可使用竞争请求。绑定信道上的竞争请求与传统DOCSIS未绑定信道上的竞争请求近似。绑定组中每个上行信道分配有一组序列号中的一个序列号。CM对所有信道上的请求机会(request opportunities)以时间顺序计数。当两个或多个上行信道上的请求机会的起始时间对齐时，只要所有的机会相对于CM随机选择的补偿值(backoffvalue)被计数，则由CM决定选取这些机会的顺序，该补偿值定义了CM在做决定之前，必须放过多少个请求机会。

根据本发明的一个实施例，CMTS必须将请求机会分配给在给定信道上发送请求所需的所个微时隙内，因为对于CM来说，在所有信道上对请求机会计数比在单个上行信道上计数要难。例如，如果某一个信道上每个请求需要2个微时隙，那么CMTS必须将请求区分配为多个的2个微时隙(例如，5个微时隙的请求区在该信道上是不允许的)。需要注意的是，在现有DOCSIS系统中，不禁止CMTS分配大小不正确的请求区。

当重新计数请求以修改补偿窗口(backoff windows)时，CM必须仅计数在竞争区内发送的请求。因此，以捎带模式发送的请求和因噪音而丢失的请求不影响CM发送竞争请求所使用的补偿窗口。

图13是根据本发明一个实施例使用绑定的上行信道进行竞争请求的步骤的流程图1300。在步骤1305中，CMTS在多个绑定上行信道中的一个上行信道上分配多个请求机会，所述多个分配的请求机会是多个在该信道上发送数据所需的多个微时隙。在步骤1310中，CMTS在绑定上行信道上的至少一个请求机会内从CM接收带宽请求。

3.3.1对传统竞争重试计数(legacy contention retry accounting)的影响

DOCSIS 2.0规范规定，如果CM重试竞争请求不成功达到16次，CM应放弃其请求的数据包或级连，并开始对该服务流的下一个数据包或级连的请求处理。在本发明的一个实施例中，采用多个突出请求和连续级连以及分段，则需要对重试阈值的不同定义。对于根据本发明实施例工作的CM，“请求重试”参数被重新定义为“针对给定服务流的带宽分配请求的连续竞争重试的数量”。DOCSIS 2.0规范的“Contention Resolution Overview”章节中包括下面的要求：“该重试步骤继续，直到达到最大重试数量(16)，这时必须丢弃PDU”。在本发明的一个实施例中，该要求变为“该重试步骤继续，直到达到临近竞争重试的最大数量(16)，这时CM放弃从上行传输队列的首部开始的对应作后一次为服务流发送数据包的请求的那些数据包”。

4.允许带宽(granting bandwidth)

在本发明的一个实施例中，CMTS调度器(scheduler)基于绑定组中的所有上行信道的可用带宽对各个信道分配带宽。任何单个信道上的请求可分配有对应该请求服务流的绑定组内上行信道的任何组合上的带宽。以这种方式，CMTS可执行上行信道上的实时负载平衡。同样地，CMTS可考虑每个上行信道上的物理层参数和请求的字节数，以确定所有信道上的最优分配方案。

在本发明的一个实施例中，CMTS使用传统的DOCSIS MAP信息发送允许给CM。因为每个信道的上行参数互相之间不同，MAP的分配起始时间互相之间也不同。因为分配起始时间和确认时间有很大的不同，在本发明的一个实施例中，在确定是否需要再次请求前，CM必须等待所有上行信道的确认时间超过请求时间。

在传统的DOCSIS系统中，CMTS可忽略一个请求的一部分或整个请求。忽略来自实现本发明的CM的请求可导致性能的降低(相对于传统的系统)，因为如果有多个突出请求，实现本发明的CM可能需要更长的时间检测丢失的请求。

在本发明的一个实施例中，CMTS需要能够对上行绑定组中任何信道允许带宽，不管带宽请求在哪个信道上接收。

5.基线保密的影响(baseline privacy impact)

传统的DOCSIS基线保护接口(BPI)为DOCSIS MAC层中的一组扩展服务，用以对CMTS和CM之间的信息流进行加密以对RF网络中的用户提供数据加密服务。为了描述本发明绑定上行信道上的信息流加密的实施例，将本发明的实施例和现有技术进行比较以帮助理解。

5.1现有的DOCSIS信息流加密

现有的DOCSIS系统根据信息流是否在DOCSIS MAC层中被分各段，以两种不同的方法处理信息流加密。如下进行详细描述的图14-16所示为现有的DOCSIS信息流加密技术。

对于需要加密的未分割单个MAC帧的传输，所述帧从DOCSIS MAC头后12字节开始到数据包的CRC均被加密。所述12字节偏置使得接收的实体在解密之前在目的地址/源地址(DA/SA)的组合(未使用有效负载头压缩的情况下)上进行滤波。该12字节的偏置还可以实现更强的密码，因为频繁出现的目的地址串和源地址串仍为可视的，这样便不会为电脑黑客提供解码提示。

对于未分段的级连，级连中的每个MAC帧被视为未分段的单个MAC帧来对待。未加密和加密帧的混和将出现在一个级连中。只要MAC管理信息(假设未加密)和加密数据包含在一个级连中，上述混和现象就会出现。图14是对未分割的单个数据包1401和未分割的级连数据包1402执行具有12字节偏置的现有DOCSIS信息量加密的示意图。如图14所示，未分割的单个数据包1401包括通过数据包的CRC的未加密DOCSIS MAC头1410、从该未加密DOCSIS MAC头1410开始的12字节偏置1405以及跟在该12字节偏置1405后面的已加密有效载荷1415。同样地，数据包级连1402的每个帧包括跟在从对应的未加密DOCSIS MAC头1420、1430、1440、1450和1460开始的12字节偏置1405后面的已加密有效载荷部分1425、1435、1445、1455和1465。

对已分割的单个帧和已分割的级连的处理与其未分割的形式不同。图15所示为对已分割的单个数据包1500执行现有的DOCSIS信息量加密的示意图。原始数据包1500被分割为3个允许1501、1502和1503。每个数据包片段1505、1510和1515封包有对应的片段头1520、1525和1530以及对应的片段CRC1535、1540和1545。如图15所示，每个片段1505、1510、1515从对应片段头的末尾至对应片段CRC均被加密。

因为一个级连内的片段边界很少与数据包边界对齐，因此现有的DOCSIS信息流加密技术将数据包的级连视为一个大的MAC帧。因此，对于已分割的数据包级连，每个级连片段封包有片段头和片段CRC。随后，对该片段从片段头的末尾至片段CRC执行加密。用于未分割的帧的12字节偏置不能用于已分割的帧，因为这12字节为用户数据而不是DA/SA对。

图16是对已分割的数据包级连1600执行现有的DOCSIS信息量加密的示意图。数据包级连1600通过3个允许1601、1602和1603被分割为3个具有对应的片段头1606、1611和1616的片段1605、1610和1615。需要注意的是，片段1605、1610和1615中所有数据包以同样的方式加密(即，对每个片段从对应的片段头末端至对应的片段CRC执行加密)。

参照图16，如果允许1601中的第一数据包1620应该被加密，但第二数据包1625应该不被加密，但两个数据包均将被加密。因此，如果级连1600本该包含有BPI密钥交换消息并被分割，该BPI密钥交换消息将在一个或多个片段1605和1610内被加密。如果该密钥交换消息被加密，且使用的密钥不正确，CMTS将不能够对包含有该新密钥的消息进行解密。因为这个原因，传统的DOCSIS信息流加密技术禁止CM在级连内包含BPI密钥交换消息。

5.2对绑定上行信道的信息流加密

对于绑定上行信道系统，CMTS决定如何分割上行信道上的带宽，且事先不知道CM会在给定片段中传输哪种类型的数据包。因此，除非在用于绑定上行信道系统的现有DOCSIS协议中加入额外的机制，否则不能够确保BPI密钥交换消息具有其自己的片段。

与其在该协议中加入其他机制，还不如使用下面的方法来避免绑定上行信道系统中BPI密钥交换消息的加密：(1)基于每个片段执行BPI加密，或(2)次级服务流专用于实现上行信道绑定以发送BPI密钥交换消息的每个CM，或(3)在分段前基于每个协议数据单元执行BPI加密。所述三种方法在下面进行详细描述。

5.2.1 CM强制单个数据包传输

避免对绑定上行信道系统的BPI密钥交换消息加密的一种机制是以片段为基础进行加密，即总是强制BPI密钥交换消息为一个片段内仅有的数据包。此方法要求所有需要BPI的片段的片段头包括有BPI头。此方法还要求CM具有智能请求代理(requesting agent)，且能够停止BPI密钥交换消息周围的请求引擎。

例如，考虑表2中所示的数据包顺序。假设表2所示为CM的特定服务流中排队等待上行传输的数据包的当前列表。为了防止第五个数据包内的BPI密钥交换消息与其它数据包包含在一个片段中，CM首先为队列中头4个数据包发出请求。一旦CM接收到对该头4个数据包的允许后，CM仅为第五数据包发送请求。随后，CM在为第六和第七及队列中的其他数据包发送带宽请求前，再次等待以便该允许填满第五数据包的传输。这种方法效率较为表2中所示的队列中的7个数据包发送一个请求的效率更低。

队列中数据包序号	数据包类型
		1	用户数据
2	用户数据
		3	SNMP响应
4	用户数据(确认)
		5	BPI密钥交换消息
6	用户数据(确认)
		7	用户数据

            表2 CM队列中的数据包

5.2.2使用BPI禁用的专用服务流

另一个避免对绑定上行信道系统的BPI密钥交换消息加密的机制是对仅用于BPI密钥交换消息以及用于其他不需要加密的消息的每个执行上行信道绑定的的CM使用专门的次级服务流。在所述方法中，无论何时请求发送BPI密钥消息的带宽，CM都使用BPI-OFF服务流。虽然所述方法避免对BPI密钥交换消息加密的问题，但其对每个CM均需要额外的服务流。增加额外的服务流对于有线运营商来说不是想要的，因为这样会增加DOCSIS设备的数量并需要使用DOCSIS机顶网关(DSG)以进行机顶盒控制。

5.2.2基于PDU而不是片段进行加密

在绑定上行信道系统中，与其基于每个片段加密或为BPI密钥交换消息要求专用的服务流，还不如在分段前基于每个PDU(即，基于单个MAC帧)执行BPI加密。为了使CMTS能够处理未绑定上行信道信息流和绑定上行信道信息流的混和，对各个数据包执行的加密使用与上述现有的BPI和BPI Plus加密技术相同的规则和12字节偏置。

图17是根据本发明一个实施例在分段前基于每个PDU执行BPI加密的示意图。如图17所示，原始数据包级连1700和后续待传输数据包的队列1704使用现有的BPI加密技术进行加密。每个被加密的数据包1710、1715、1720、1725、1730、1735和1740跟在从对应的DOCSIS头开始的12字节偏置1705后面。接着，已加密的数据包被分割入允许1701、1702和1703中。

根据本发明的一个实施例，因为现有的BPI EHDR内的捎带字段太小以至不能够在多个4字节中发送卸载请求，需要对现有的DOCSIS BPI EHDR进行修改，使其包括更长的捎带字段以用于无片段头的情况，或使其不包括捎带字段已用于有片段头的情况。这些修改后的BPI EHDR类型在7.3.1节中进行详细描述。

6.系统初始化

图18A和18B是根据本发明一个实施例用于对绑定上行信道系统中的CMTS初始化的CM内的步骤的流程图1800。在CM获得适当的下行信道后，在步骤1805中，CM寻找绑定上行信道描述符(B-UCD)消息。在步骤1810中，如果CM不能在预定的时帧内找到B-UCD消息，那么，在步骤1815中，CM返回传统的未绑定上行信道操作。

如果CM在预定的时帧内找到B-UCD消息，那么，在步骤1820中，CM开始为与B-UCD相关的上行信道存储MAP消息。在步骤1825中，CM还开始存储与B-UCD标识的绑定组中的每个信道相关的上行信道描述符(UCD)消息。

在步骤1830中，CM开始对绑定组中的一个上行信道进行排列。在步骤1835中，一旦CM接收到上行信道排列完成的指示，CM在该信道上发送基于队列长度的带宽请求以实现初始化处理的余下部分。

在步骤1840中，在注册过程中，CM通知CMTS其可以绑定多少个上行信道。在步骤1845中，在同一注册过程中，CMTS通知CM其希望CM使用多少个上行信道。注册消息属性在7.4.3节中进行详细描述。

在完成注册过程前(例如，在发送REG-ACK信息给CMTS之前)，CM使用额外的发射器尝试以并行方式排列由CMTS分配的由上行绑定组指定的附加上行信道，如步骤1850所示。这一分配可通过DOCSIS REG-RSP消息来实现。此外，对这些附加信道的排列技术可在REG-RSP消息中指定。在一个实施例中，如果CM不能够成功地对所有规定的上行信道排列，CM发送具有失败码的REG-ACK给CMTS。

在步骤1855中，CM最终确定是否成功的对所有指定的上行信道进行排列。如果是，那么CM可对非排列信息流使用每个指定的上行信道，如步骤1865所示。如果否，那么CM将执行部分信道操作(如上所述)，其中仅有指定的上行信道的一部分用于非排列信息流，如步骤1860所示。

在本发明的一个实施例中，CMTS必须继续为CM已经发送排列完成指示的绑定组中每个上行信道提供单播排列机会给CM。如果CM在预定的时帧内(例如，传统的DOCSIS T4时帧)未接收单播排列机会，或达到发送排列请求数据包(例如，传统的DOCSIS RNG-REQ消息)的阀值，那么CM会从其未使用上行信道列表中移除相关的上行信道，并继续对剩余的上行信道进行操作，如下面的“部分信道操作”一节所描述。

6.1部分信道操作

如果在进入操作状态后的任何时间，CM超过其位置排列的重试阀值或在预定的时帧(例如，传统的DOCSIS T4时帧)内未接收对给定上行信道的单播排列机会，CM认为自己不再对该特定上行信道进行排列，并停止传输除了该上行信道上排列数据包之外的任何信息。CM必须响应该上行信道上单播排列机会，但直到接收到该上行信道排列完成信息之前，一定不能传输任何非排列数据包。

最后，CMTS意识到CM不再在该上行信道上进行排列。CMTS以如下的内容作出响应：(1)允许CM继续在该绑定组的剩余信道上进行操作，并仅在CM排列的剩余信道上分配允许；(2)命令CM通过DCC移至不包含该问题信道的一个不同的绑定组；(3)如果问题广泛存在，CMTS可选择通过改变B-UCD从绑定组中移除问题信道；或者(4)CMTS可指示CM通过适当的信息重启。

7.详细的MAC改变

如上所述，在一个实施例中，本发明的上行信道绑定技术实现为传统的DOCSIS接口规范的扩展。因此，如下介绍几个新的和修改的MAC格式以扩展传统DOCSIS接口规范以支持上行信道绑定。

7.1请求信息

在本发明的一个实施例中，为了使CMTS能够区别传统的基于负荷微时隙的DOCSIS带宽请求和基于卸载字节的绑定上行信道的带宽请求，定义一个新的请求头。该新的请求头被传统的DOCSIS系统忽略。例如，表3所示为绑定上行信道系统中扩展后包括有新的基于队列长度请求帧类型的传统DOCSIS 2.0 FC_PARM字段。

FC_PARM	头/帧类型
		00000	时序头
00001	MAC管理头
		00010	传统请求帧
00011	片段头
		00100	基于队列长度的请求帧
11100	级连头

表3MAC-特定头(MAC-Specific Headers)和帧类型

图19所示为基于队列长度的请求帧格式1900的示意图。除了MAC_PARM字段为2字节而不是1字节之外，所述格式与传统DOCSIS请求帧格式近似。如图19所示，队列长度为基础的请求帧1900包括4个字段：帧控制(FC)字段1905、MAC_PARM字段1910、SID字段1915和头校验序列(HCS)字段1920。FC字段1905包括3个字段：FC类型字段1925、FC PARM字段1930和EHDR_ON字段1935。所述队列长度为基础的请求帧1900的字段如下表4进行详细描述。

字段	使用情况	大小
			FC	FC_TYPE＝11；MAC-Specific头FC_PARM[4:0]＝00100；仅MAC请求头无数据PDU跟随EHDR_ON＝0；无ENDR被允许	1字节
MAC_PARM	REQ2，请求的字节总数单位为N字节，其中N在绑定上行信道描述符消息中指定	2字节
			SID	服务ID	2字节
EHDR	未允许的扩展MAC头	0字节
			HCS	MAC头校验序列	2字节
	队列长度为基础的请求MAC头的长度	7字节

        表4队列长度为基础的请求帧格式

7.2片段头格式

如上所述，为了对绑定上行信道执行分割，在每个片段内插入片段头。图20是根据本发明一个实施例的片段头格式2000的示意图。片段头长度为8字节。如图20所示，片段头2000包括7个字段：指针字段有效(PFV)字段2005、预留(R)字段2010、指针字段2015、序列号2020、SID_Cluster(SC)字段2025、请求字段2030和MAC头校验序列(HCS)字段2035。片段头2000的字段在下面的表5中进行详细描述。

字段	使用情况	大小
			PFV	指针字段有效。设为1表示指针字段有效，设为0表示指针字段内没有有效的指针。	1位
R	预留的，由CM设为0	1位
			指针字段	当PFV位是1，这个字段的值是经过片段头末尾的字节的数量，接收器在寻找DOCSIS MAC头时必须跳	14位

	过该字节。因此，指针字段的值为0及PFV设为1表示DOCSIS MAC头在片段头后开始。
			序列号#	基于特定的服务流的每个片段，序列号增加1。	13位
SC	片段头的下一个字段中的与请求相关的SID_Cluster。有效的SID_Cluster范围是0到M-1，其中M是分配到该服务流的SID_Cluster的数量。	3位
			请求	以N字节为单位的请求的字节的总数，其中N在绑定上行信道描述符消息中指定。	2字节
HCS	MAC头校验序列。与所有MAC头上使用的HCS相似，在片段头的所有其它字段上计算得出。	2字节

                        表5片段头字段

7.3扩展的头格式

根据本发明的一个或多个实施例，几个新的DOCSIS EHDR类型和长度可加入现有的DOCSIS规范中以适用于上行信道绑定，如下表6所示。新的EHDR类型包括：EH_TYPE＝1且EH_LEN＝4和EH_TYPE＝7且EH_LEN＝3和5。

EN_TYPE	EN_LEN	EH_VALUE
			0	0	空配置设定，可用于填充扩展头。EN_LEN必须为0，但配置设置可重复。
1	3	微时隙中的请求。请求(1字节)；SID(2字节)[CM→CMTS]
			1	4	Nx字节的队列长度为基础的请求；N在B-UCD中指定；请求(2字节)；SID(2字节)[CM→CMTS]
2	2	请求的确认；SID(2字节)[CM→CMTS]
			3(BP_UP)	4	上行秘密EH分量[DOCSIS]

	5	具有片段EH分量的上行秘密[DOCSIS]
			4(BP_DOWN)	4	下行秘密EH分量[DOCSIS]
5	1	服务流EH分量；有效载荷头压缩头下行数据流
			6	1	服务流EH分量；有效载荷头压缩头上行数据流
6	2	服务流EH分量；有效载荷头压缩头下行数据流(1字节)，未请求的允许同步头(1字节)
			7(BP_UP2)	3	没有捎带请求的上行秘密EH分量
7(BP_UP2)	5	具有捎带基于队列长度的请求的上行秘密EH分量，Nx字节，其中N在B-UCD中指定
			8-9		预留的
10-14		预留的[CM←→CM]
			15	XX	扩展的EH分量；EHX_TYPE(1字节)，EHX_LEN(1字节)，EH_VALUE(长度由EHX_LEN决定)

                表6扩展的头格式

本说明书中的表6和随后的某些表格涉及到B-UCD消息中指定的字节请求乘法器(记作“N”)。然而，需要注意的是，在本发明的一个可选实施例中，字节请求乘法器事实上编码为有线调制解调器注册过程中中继的服务流参数。

7.3.1长度为4的请求EHDR

当上行信道绑定对CM有效，且片段头对给定服务流无效时，CM在没有基线保密头的情况下，有机会在数据包上捎带请求。为了处理这种情况，长度为4的第二种类型的请求EHDR可用于本发明的实施例中，如下表7所示。

EH分量字段	使用情况	大小
			EH_TYPE	EH_TYPE＝1	4位
EH_LEN	片段头禁用操作的EH_LEN＝4	4位

EH_VALUE

请求多个N字节(2字节)、SID(2字节)，N在B-UCD中指定

4字节

                表7长度为4的请求EHDR

7.3.2 BP_UP2

在本发明的一个实施例中，上行信道绑定和基线保密(baseline privacy)有效的情况下可使用BP_UP2 EHDR。当上行信道绑定对CM有效，且片段头对给定SID有效，任何对该SID的捎带请求将使用该片段头中的捎带机会。因此，对于该SID，BPI EHDR中不需要使用捎带字段。CM将对片段头可用的SID使用长度为3的BPI_UP2 EHDR。长度为3的BPI_UP2 EHDR的字段如表8所示。

EH分量字段	使用情况	大小
			EH_TYPE	EH_TYPE＝7，用于绑定信道	4位
EH_LEN	EH_LEN＝3，用于片段头可用操作	4位
			EH_VALUE	密钥序列(4位)、版本(4位)、激活(1位)、触发(1位)、SID(14位)	3字节

        表8长度为3的BP_UP2 EHDR(片段头可用)

当信道绑定对CM有效，且片段头对给定服务流不可用的情况下，BPIEHDR可实现捎带请求机会。CM将对片段头不可用的SID使用长度为5的BPI_UP2 EHDR。长度为5的BPI_UP2 EHDR的字段如表9所示。

EH分量字段	使用情况	大小
			EH_TYPE	EH_TYPE＝7，用于绑定信道	4位
EH_LEN	EH_LEN＝5，用于片段头不可用操作	4位
			EH_VALUE	密钥序列(4位)、版本(4位)、激活(1位)、触发(1位)、SID(14位)，请求(2字节)	5字节

        表9长度为5的BP_UP2 EHDR(片段头禁用)

7.4 MAC管理消息改变

根据本发明的一个或多个实施例，多个MAC管理消息属性被修改，并且创建了多个新的MAC管理消息以支持绑定的上行信道。这些已修改的MAC管理消息和新的MAC管理消息如下表10所示。

改变	类型值	版本	消息名称	消息描述
					已修改	6	1	REG-REQ	注册请求
已修改	7	1	REG-RSP	注册响应
					已修改	14	2	REG-ACK	注册确认
已修改	32	2	DCC-REQ	动态信道改变请求
					新的	34	4	B-UCD	绑定上行信道描述符
新的	36	4	B-RNG-Abort	绑定信道排列中断
					新的	37	4	B-RNG-Abort-ACK	绑定信道排列中断确认

                表10新的和已修改的MAC管理消息

7.4.1绑定上行信道描述符(B-UCD)

根据本发明的一个实施例，绑定上行信道描述符(B-UCD)消息由CMTS在周期时间间隔内传输以定义绑定上行信道组的特性。需要为每个绑定上行信道组发送单独的一个B-UCD消息。B-UCD格式的第一部分与传统DOCSIS单信道上行信道描述符(UCD)消息格式近似，因此可使用相同类型的滤波来滤波信道ID和改变计数值。CMTS还必须为每组绑定上行信道中的每个信道发送UCD消息。

图21是根据本发明一个实施例的上行信道描述符(B-UCD)消息格式2100的示意图。B-UCD消息格式2100包括MAC管理消息头2101、所有绑定上行信道的类型长度值(TLV)元组编码信息(tuple encoded information)2102和如下的参数：绑定上行信道标识符2105、配置改变计数值2110、请求间隔参数2115和下行信道标识符2120。这四个参数2105、2110、2115和2120定义如下：

绑定上行信道ID：此消息涉及的上行绑定信道的标识符。此标识符由CMTS任意地选择，且仅在MAC子层字段中唯一。注意：上行信道ID＝0预留给表示电话返还[DOCSIS6]。

配置改变计数值：只要此信道描述符改变，由CMTS增加1(以字段大小为模)。如果此计数在随后的UCD内保持不变，CM可快速地决定信道操作参数没有改变，并可忽略剩下的消息。

请求间隔：此字段以字节的形式指定第二类请求的间隔N。法定值为N＝1，2，4，8和16。

下行信道ID：此消息被传输的下行信道的标识符。此标识符由CMTS任意选择，并且仅在MAC子层字段中唯一。

所有其他的参数被编码为TLV元组2102。使用的类型值如下表11。

名称	类型(1字节)	长度(1字节)	值(可变长度)
				绑定组大小	1	1	绑定组中的信道数量(1至M)
子信道	2	1	绑定组中信道ID。此TLV对绑定组中的每个上行信道重复。

                    表11绑定信道TLV参数

CMTS可使用B-UCD消息改变绑定组中信道的数量。例如，CMTS可使用B-UCD消息增加或减少绑定组中信道的数量，并且CMTS也可使用B-UCD消息以2个步骤的处理替代绑定组中的信道。图22是根据本发明一个实施例在CMTS中使用B-UCD消息改变绑定上行信道组内的信道设置的步骤的流程图2200。在步骤2205中，CMTS在周期时间段内发送定义绑定组特性的B-UCD消息。

7.4.1.1从上行信道绑定组中移除信道

在步骤2210中，如果CMTS决定改变绑定组中信道的数量，那么流程2200进行至步骤2215。在步骤2215中，如果CMTS决定移除绑定组中的信道，那么流程2200进行至步骤2230。在步骤2230中，为了从绑定组中移除上行信道，CMTS首先必须停止对将要移除的目标上行信道停止映射任何时间定义的绑定配置(即，对请求区、排列区、数据允许等等的分配)。随后，在步骤2235中，CMTS使用修改后的绑定组中信道的数量和减少后的信道列表更新B-UCD，同时对配置改变计数值字段加1。因为在MAP信息中没有对应B-UCD改变计数值的改变计数值，当CM处理B-UCD消息时，CM处会发生改变。因此，CMTS必须在传输新的B-UCD前，停止发送允许给目标信道上绑定的CM。

7.4.1.2对上行绑定组加入信道

在步骤2215中，如果CMTS决定对绑定组加入信道，那么流程2200进行至步骤2220。当CMTS想要对绑定组加入上行信道时，CMTS更新B-UCD，如步骤2220所示。可加入额外的上行信道(基于注册过程中指定的绑定信道的最大数量)的CM将尝试排列新的上行信道。所述排列可使用REG_RSP消息定义的排列技术来实现。

7.4.1.3替换上行绑定组内的信道

在步骤2210中，如果CMTS决定不改变绑定组中信道的数量，那么流程2200进行至步骤2245。在步骤2245中，如果CMTS决定替换绑定组中的信道，那么流程2200进行至步骤2250。为了以另一个信道替代上行绑定组中的一个信道，CMTS首先必须停止对将要移除的目标信道发送允许，如步骤2250所示。随后，CMTS必须发送新的B-UCD，以新的信道代替信道列表中的旧信道，如步骤2255所示。CMTS还必须更新B-UCD中的改变计数值。因为MAP信息中没有对应B-UCD改变计数值的改变计数值，当CM处理B-UCD信息时，CM处会发生改变。因此，CMTS在传输新的B-UCD之前，必须停止发送允许至将要删除的目标信道上的绑定CM。当CM接收到带有替换的B-UCD时，其必须放弃在被替代的信道上传输的任何突出请求。可加入额外的上行信道(基于注册过程中指定的绑定信道的最大数量)的CM必须尝试在新的上行信道上排列。所述排列可使用REG_RSP消息指定的排列技术来实现。

7.4.2MAP消息

在本发明的一个实施例中，MAP消息未绑定地在下行信道中发送。当本发明的一个实施例使用旧的(例如，传统DOCSIS)MAP结构时，还提供有确认时间的已修改的定义，以允许CMTS具有更好的灵活性。新的定义是：在此信道的MAP中处理和反映的(通过允许或允许未决)CMTS初始化(微时隙)的最近时间。

7.4.3注册消息

根据本发明的一个或多个实施例，以下注册参数被修改或加入传统的DOCSIS规范中以控制上行信道绑定的使用。

7.4.3.1上行信道绑定性能TLV

传统DOCSIS调制解调器性能编码的值字段描述了特定CM的性能，例如对特定特征的与实现相关的限制或CM可支持的特征的数量。在本发明的一个实施例中，上行信道绑定性能TLV参数被加入传统的DOCSIS调制解调器性能编码中，并且其值代表CM的上行信道绑定支持。此类型是5.13，长度是1字节。所述值如下：0＝不支持分段或上行信道绑定；1＝仅支持单个上行信道上的分段；2＝支持2个信道上的上行信道绑定；M＝支持M个信道上(M的最大值为255)的上行信道绑定。

7.4.3.2最大级连脉冲(Maximum Concatenated Burst)TLV

最大级连脉冲TLV参数是现有Upstream-Specific Qos参数编码的一部分，并定义服务流允许的最大级连脉冲串(以字节)。在本发明的一个实施例中，因为级连的概念与上行信道绑定不同，当上行信道绑定处于有效状态时，改参数被改变以定义CM可在单个请求中请求的字节的最大数量。

7.4.3.3最大请求字节突出TLV

在本发明的一个实施例中，最大请求突出TLV参数被加入传统的DOCSIS系统的Upstream-Specific Qos参数编码内以处理上行信道绑定。此参数限制CM发出突出请求时可请求的带宽量。所述类型为23.25，且长度为4。所述值是CM可能突出请求的字节的最大数量。与上述修改的最大级连脉冲TLV参数相结合，此参数可代替传统DOCSIS系统中最大级连脉冲提供的功能。

7.4.3.4请求/传输策略TLV

Upstream-Specific Qos参数编码内的请求/传输策略TLV参数指定了对给定服务流的请求/允许处理的特性。在本发明的一个实施例中，此参数被修改以包括有额外的值，用以控制片段头和突出请求的使用。所述类型为24.16，长度为4。所述值为9＝服务流禁止使用片段头，10＝服务流禁止使用竞争区以发送多个突出的带宽请求。

7.4.3.5次级信道排列技术TLV

次级信道排列技术TLV参数指定了对次级上行信道初始排列时CM使用的排列技术，其长度为1，值为0＝使用广播初始排列区；1＝使用单播初始排列区；2＝使用广播或单播初始排列区。

7.4.4配置文件改变

下面的内容描述根据本发明一个实施例的配置文件改变。

7.4.4.1突出请求的数量的限制

此参数允许运营商限制特定的服务流可具有的每个SID_Cluster的突出请求的数量。例如，如果所述值是1，CM对每个SID_Cluster一次仅可做出一个请求。在本发明的一个实施例中，如果所述参数在CM初始的DSx请求或REG-REQ中被忽略，CMTS必须在对应的响应中指定一个数量。所述类型是24.(待确定)，长度是1，以及值是突出请求(值为0代表限制未指定)的最大数量。

7.4.4.2上行绑定组替换值(override)

当出现时，此参数提供上行绑定组的替换值。长度是1，值为上行绑定组的信道ID。

7.4.5DCC-REQ消息

在本发明的一个实施例中，动态信道改变(DCC)消息的含义被修改以用于上行信道绑定操作。在传统的DOCSIS系统中，CMTS可传输DCC请求(DCC-REQ)消息以使CM改变其正在发送数据的上行信道，以及其正在接收数据的下行信道，或者两者。

7.4.5.1绑定上行信道ID

当出现时，绑定上行信道ID TLV指定CM执行动态信道改变时必须使用的新的绑定上行信道ID。绑定上行信道ID TLV是当前绑定上行信道ID的替换值。CMTS必须确保新信道的绑定上行信道ID与旧信道的绑定上行信道ID不同。

如果上行绑定组被改变，绑定上行信道ID TLV必须包括在其中。绑定上行信道ID TLV用于将CM移至不同的上行绑定组，将CM从绑定上行信道移至未绑定上行信道，以及将CM从未绑定上行信道移至绑定上行信道。

其类型是9，长度是1。值是0-255；绑定上行信道ID。值为0表示CM证被移至没有上行信道绑定的信道。当值为0时，上行信道ID TLV用于指示CM移至何处。需要注意的是，在CM证由一个绑定组中移出，但仍还有一个上行信道留在该绑定组的情况下，新的上行信道ID可与当前信道ID匹配。

7.5传输区排序

下面描述根据本发明一个实施例的传输区排列。

7.5.1计数竞争区(counting contention regions)

在本发明的一个实施例中，CM必须根据下面的规则，以时间顺序推迟绑定信道组中所有的信道上的竞争请求机会：

(1)只要2个或多个上行信道的TDMA请求机会的起始时间相同，CM可在这些机会中选择排序；

(2)尽管因为绑定组中其它信道上的机会而不必连续，一个信道上的TDMA竞争机会在时间顺序上应该被推迟；

(3)随后的S-CDMA帧中的S-CDMA竞争机会不应排在同一信道上较早的S-CDMA帧的竞争机会之前。

7.6.2所有片段上的信息流的排序

在本发明的一个实施例中，CM必须基于每个片段的起始时间将信息流放入片段中。服务流队列首的信息流必须放入首先传输的片段中，以下情况例外：

(1)只要2个或多个上行信道的TDMA请求机会的起始时间相同，CM可在这些机会中选择排序；

(2)一个信道上的TDMA传输机会应用于以时间为顺序的分段中；

(3)后一S-CDMA帧中S-CDMA竞争机会不应排在同一信道上较早S-CDMA帧中的传输机会之前。

8.系统同步要求

本发明的一个实施例要求绑定组中的上行信道与一个下行信道或彼此同步的多个下行信道相关联。例如，如图1所示，系统100包括有主时钟源116以辅助实现该同步。

这一同步要求表示，CM可使用一个恢复时钟生成在绑定上行组内所有的信道上进行传输需要的时序。主时钟源的相位可从一个上行信道到另一个上行信道进行转换，这一相位差在排列时需要考虑。

CM将在上行绑定组内的每个信道上进行排列，并且对每个信道可能具有不同的排列偏置。

9.各种改变

下面描述根据本发明一个实施例传统的DOCSIS规范实现上行信道绑定的各种改变。

9.1动态UCD改变

对于传统的DOCSIS“动态(on-the-fly)”的UCD改变，CM和CMTS忽略影响请求/允许大小的突出请求。随后CM切换至新的信道参数并使用新的参数再次请求带宽。动态UCD改变的操作可通过本发明以字节为基础的请求、CCF和多信道调度特征来解释。因为CM以字节发送请求，并不知道请求会在绑定组中的哪个信道被允许，因此CM必须不能忽略任何对UCD改变的突出请求。CMTS可放弃已经计划的分配给改变的信道的请求，或者修改分配给该信道的允许以匹配新的UCD参数。如果CMTS放弃请求，CM最后将再次请求需要的带宽。对于信道改变，包括基于每个微时隙的改变或涉及SCDMA激活的改变，针对已改变上行信道的CM请求时间不再适用于新的上行信道参数。在这些情况下，CM必须将用于该信道的所有突出请求而存储的请求时间替换为CM使用该信道的新UCD改变计数接收的第一MAP的分配起始时间。

9.2附录B改变

附录B将被修改，使得CM MAP处理时间的定义为到达CM的MAP的最后一位和该MAP有效之间的时间。

9.3对CM和CMTS排列的改变

根据本发明的一个实施例，用于CM-CMTS交互操作的DOCSIS MAC要求被修改，要求CMTS为上行绑定组内的所有信道发送单播维护机会给CM。同样的，如果CM在其上行信道上具有T4，则应阻止CM重启。

10.用于绑定信道的其它机制的讨论

用于绑定上行信道以达到上行信道中更高带宽“管道”的其它机制在下面的章节描述。如上所述，实现绑定的上行信道的系统提供增加的数据率和吞吐量，对比未实现绑定上行信道的系统，好处是增加了多路增益统计值和自动负载平衡。

10.1物理层(PHY)绑定

在物理层绑定的一个方法是使用一个宽带信道以提供更高的最大吞吐量和更大的多路增益统计值。与之前描述的本发明的实施例不同的是，此方法不允许未实现上行信道绑定的CM使用全部的频谱，并且不允许未实现上行信道绑定的CM和实现上行信道绑定的CM有效地共享同一宽频带。

在物理层编码级绑定的第二种方法是在多个信道上编码。该编码包括向前纠错、相关的交错和扰码(scrambling)。与之前描述的本发明的实施例不同的是，对于信道绑定发生在物理层之上的情况，此方法将信道绑定实现至PHY编码相结合，因而其在不影响上行信道绑定实现的情况下改变编码是很麻烦的。

10.2 MAC层绑定的变化

根据之前描述的本发明的实施例，如果上行信道绑定发生在传输的片段级上，该片段可在绑定信道组中的任何信道上传输，而与如何做出请求或在哪个信道上做出请求无关。在确定了该片段在一个特定的信道上通过来自CMTS的允许传输后，该片段将在恰当的时间使用该信道和为该信道定义的脉冲串细节参数来发送。

绑定信道组中信道上的片段可为一个完整的DOCSIS帧、DOCSIS帧的级连、DOCSIS帧的一个片段或DOCSIS帧级连的一个片段。DOCSIS帧的级连可在任何位置处被分割，根据分割的类型，该位置可以是帧边界，也可以不是帧边界。因此，根据本发明之前描述的实施例，在MAC层片段边界处的绑定为DOCSIS MAC层提供了更好的灵活性，同时维持了信号处理结构和物理层的灵活性。MAC层的上行信道绑定的两种变化如下所述。

10.2.1请求同样的信道参数

MAC层绑定的一种变化要求CMTS在所有绑定信道上同时以及在相同的时间段内允许CM传输机会。与之前描述的本发明的实施例不同的是，此方法不够灵活以在同样的信道上适应不支持供除各种服务的UGS机会之外的上行信道绑定的CM。此方法也同样约束当信道有不同PHY参数(如数据传输率、调制顺序和微时隙大小等等)时的调度实现。

10.2.2CM控制绑定

MAC层绑定的另一个变化允许CM做出多个关于绑定信道组使用什么信道和如何对数据进行排序的“决定”。此方法允许CM决定在特定时间内使用哪个上行信道，此方法将系统测试和认证变得更复杂，这是因为CM的操作不确定。由于每个CM的操作不同，这种不确定的操作使得字段调试很难进行。

根据本发明的一个实施例，CMTS调度器对绑定信道组中信道上的所有传输机会进行调度，无论所述传输是专用的、允许的或是竞争机会。与CM控制的上行调度方法不同的是，CM的操作是确定的并由CMTS的带宽分配来规定。通过CMTS控制的上行调度，CMTS是唯一知道每个上行信道上的负载的实体，并且这样的话，CMTS是唯一能够准确地执行负载平衡和决定CM应该在哪个信道或哪几个信道上进行传输的实体。

10.3在高于MAC层的更高层上的绑定

MAC层上实现MAC层绑定和分段的一种可选方法是在IP层分段。IP分段是分割数据以适合来自CMTS的允许量的一种可选方法。然而，每个IP片段具有与原始IP数据包相同的格式。特别的，每个片段中包括有20字节的最小IP头。因此，需要被分割多次的长数据包会造成多次的IP开销。除了每个允许内的DOCSIS MAC头的多次出现之外，如果每个片段的高层头重复多次，在高于MAC层的较高层上的上行信道分段的其他方案也会造成额外的开销。

根据本发明的一个实施例，在MAC层执行数据分段以适应来自CMTS的允许量。此方法的分段开销比传统的分段方法和在高于MAC层的层进行分段的方法的效率更高。

11.总结

以上介绍了本发明的各种实施例，应该理解的是，以上各种实施例仅仅是对本发明的示例说明，不是对本发明的限制。本领域的普通技术人员可知，可对本发明进行各种形式和细节的改变而并不脱离本发明权利要求定义的范围。因此，本发明的范围并不限于公开的具体实施例，而由权利要求及其等效替换来定义。

Claims (10)

1、一种在有线调制解调器终端系统内实现有线网络内的高吞吐量带宽分配的方法，所述方法包括如下步骤：

将多个上行信道绑定为一组；

从有线调制解调器接收带宽请求；

响应所述带宽请求的接收，为所述绑定组内的每个上行信道发出唯一的带宽分配消息，其中所述唯一带宽分配消息的组合共同地分配整个绑定组上所请求的带宽，以由所述有线调制解调器传输数据包流至CMTS。

2、根据权利要求1所述的方法，其特征在于，所述为绑定组中每个上行信道发出唯一的带宽分配消息包括为所述绑定组中每个上行信道发出唯一的有线电缆数据服务传输规范MAP信息。

3、根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

通过所述绑定组内的上行信道接收由所述有线调制解调器发送的多个片段，其中所述多个片段在所述唯一带宽分配消息中指定的时间传送，且所述每个片段包括唯一的序列号；

基于所述唯一的序列号将所述多个片段中的信息组合以重建所述数据包流。

4、根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

分配一组唯一的标识符给所述有线调制解调器，其中每个所述唯一的标识符分别对应所述绑定组内的一个上行信道；

并且所述从有线调制解调器接收带宽请求包括对包括有所述一组唯一标识符中的一个唯一标识符的消息监视所述绑定组内的上行信道。

5、根据权利要求4所述的方法，其特征在于，所述分配一组唯一的标识符给所述有线调制解调器包括分配一组唯一的标识符给与所述有线调制解调器相关联的服务流。

6、一种在有线调制解调器内实现有线网络内的高吞吐量传输的方法，所述方法包括如下步骤：

发送带宽请求至有线调制解调器终端系统；

接收多个带宽分配消息，其中每个所述带宽分配消息与上行信道绑定组中的一个上行信道唯一关联，并且所述多个带宽分配消息共同地分配整个上行信道绑定组上所请求的带宽；

依据所述多个带宽分配消息，通过所述上行信道绑定组传输数据包流至所述CMTS。

7、根据权利要求6所述的方法，其特征在于，所述接收多个带宽分配消息包括接收多个DOCSIS MAP消息。

8、一种实现有线网络内的高吞吐量带宽分配的系统，包括：

有线调制解调器终端系统，用于将多个上行信道绑定为一组；

有线调制解调器，用于发送带宽请求至所述CMTS；

其中所述CMTS进一步为所述绑定组中的每个上行信道发送唯一的带宽分配消息给所述有线调制解调器，所述唯一带宽分配消息的组合共同地分配整个绑定组上所请求的带宽；

其中所述有线调制解调器进一步依据所述多个带宽分配消息，通过所述上行信道绑定组传输数据包流至所述CMTS。

9、根据权利要求8所述的系统，其特征在于，所述CMTS为所述绑定组中的每个上行信道发送唯一的DOCSIS MAP信息至所述有线调制解调器。

10、根据权利要求8所述的系统，其特征在于，所述有线调制解调器将所述数据包流分割为多个片段，将唯一的序列号插入每个所述片段内，并在所述多个带宽分配消息指定的时间通过所述绑定组内的上行信道组传输所述每个片段至所述CMTS。

Images