思科uBR CMTS的上游调度程序模式配置

下载选项

PDF (766.4 KB)
在各种设备上使用 Adobe Reader 查看
ePub (569.5 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
Mobi (Kindle) (1.8 MB)
在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看

已更新: 2006 年 4 月 3 日

文档 ID:69704

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。深入了解思科如何使用包容性语言。

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

简介

本文档讨论思科通用宽带路由器(uBR)系列电缆调制解调器终端系统(CMTS)的上游调度程序模式配置。

本文档重点介绍使用延迟和抖动敏感型上游服务（例如IP语音或视频）的高速有线数据网络的设计和维护人员。

先决条件

要求

Cisco 建议您了解以下主题：

有线服务接口规范(DOCSIS)系统上的数据
思科uBR系列CMTS

使用的组件

本文档中的信息基于以下软件和硬件版本：

思科uBR CMTS
思科IOS®软件版本系列12.3(13a)BC和12.3(17a)BC

注：有关Cisco IOS软件更高版本的更改信息，请参阅Cisco.com网站上提供的相应版本说明。

背景信息

在有线数据服务接口规范(DOCSIS)网络中，CMTS控制电缆调制解调器进行的所有上行传输的定时和速率。在现代DOCSIS网络上游同时运行许多不同类型的具有不同延迟、抖动和吞吐量要求的服务。因此，您必须了解CMTS如何决定电缆调制解调器何时能够代表这些不同类型的服务进行上游传输。

本白皮书包括：

DOCSIS中上游调度模式概述，包括尽力而为、未经请求的授权服务(UGS)和实时轮询服务(RTPS)
思科uBR CMTS的DOCSIS兼容调度程序的操作和配置
Cisco uBR CMTS新低延迟排队调度程序的操作和配置

DOCSIS中的上游调度

符合DOCSIS的CMTS可以通过服务流的概念为不同的数据包流或应用提供不同的上游调度模式。服务流代表数据的上游或下游流，服务流ID(SFID)唯一标识该数据流。每个服务流可以有其自己的服务质量(QoS)参数，例如最大吞吐量、最小保证吞吐量和优先级。对于上游服务流，您还可以指定调度模式。

每个电缆调制解调器可以有多个上游服务流，以适应不同类型的应用。例如，Web和电子邮件可以使用一个服务流，IP语音(VoIP)可以使用另一个服务流，而Internet游戏可以使用另一个服务流。为了能够为这些应用提供适当类型的服务，这些服务流的特征必须不同。

电缆调制解调器和CMTS能够使用分类器将正确类型的流量定向到适当的服务流中。分类器是特殊过滤器，如访问列表，与数据包属性（如UDP和TCP端口号）匹配，以确定数据包要经过的适当服务流。

在图1中，电缆调制解调器有三个上行服务流。第一个服务流为语音流量保留。此服务流具有低最大吞吐量，但也配置为提供低延迟保证。下一个服务流用于一般Web和电子邮件流量。此服务流具有高吞吐量。最终服务流为点对点(P2P)流量保留。此服务流具有更严格的最大吞吐量，以限制此应用的速度。

图1 — 带三个上游服务流的电缆调制解调器

当电缆调制解调器首次联机时，服务流会建立并激活。在用于配置电缆调制解调器的DOCSIS配置文件中调配服务流的详细信息。在DOCSIS配置文件中为上游流量调配至少一个服务流，为下游流量调配一个其他服务流。您在DOCSIS配置文件中指定的第一个上游和下游服务流称为主服务流。

电缆调制解调器上线后，还可以动态创建和激活服务流。此场景通常适用于服务流，该服务流对应于属于VoIP电话呼叫的数据。当电话会话开始时，会创建并激活此类服务流。然后，当呼叫结束时，服务流被停用并删除。如果服务流仅在必要时存在，则可以节省上游带宽资源以及系统CPU负载和内存。

电缆调制解调器无法随时进行上行传输。相反，调制解调器必须等待CMTS的指令才能发送数据，因为一次只有一个电缆调制解调器可以在上游信道上传输数据。否则，传输可能会相互溢出并损坏。有关电缆调制解调器何时能进行传输的说明以带宽分配MAP消息的形式从CMTS发出。Cisco CMTS每2毫秒传输一次MAP消息，告知电缆调制解调器何时可以进行任何类型的传输。每条MAP消息都包含信息，用于指示调制解调器确切何时进行传输、传输可持续多长时间，以及它们可以传输的数据类型。因此，电缆调制解调器数据传输不会相互冲突，并避免数据损坏。本节讨论CMTS确定何时授予电缆调制解调器在上游传输的权限的一些方法。

尽力

尽力调度适用于对延迟或抖动没有严格要求的经典互联网应用。这些类型的应用包括电子邮件、网络浏览或点对点文件传输。尽力而为调度不适用于需要保证延迟或抖动的应用，例如IP语音或视频。这是因为在拥塞情况下，不能以尽力而为模式提供这种保证。DOCSIS 1.0系统仅允许此类调度。

尽力服务流通常在与电缆调制解调器关联的DOCSIS配置文件中调配。因此，当电缆调制解调器联机后，尽力服务流通常会处于活动状态。主上游服务流（即要在DOCSIS配置文件中调配的第一个上游服务流）必须是尽力而为的服务流。

以下是在DOCSIS 1.1/2.0模式下定义尽力服务流的最常用参数：

最大持续流量速率(R)

Maximum Estenated Traffic Rate是流量在此服务流上运行的最大速率。此值以比特/秒表示。
最大流量突发(B)

最大流量突发是指应用于实施上游吞吐量限制的令牌桶速率限制器的突发大小（以字节为单位）。如果未指定值，则应用默认值3044，即两个完整以太网帧的大小。对于较大的最大持续流量速率，请将此值设置为至少最大持续流量速率除以64。
流量优先级

此参数是指服务流中从0（最低）到7（最高）的流量的优先级。在上游，优先级高的服务流的所有待处理流量在优先级低的服务流的流量之前被安排用于传输。
最低保留率

此参数表示服务流的最小保证吞吐量，以位/秒为单位，类似于承诺信息速率(CIR)。信道上所有服务流的组合最低保留速率不得超过该信道的可用带宽。否则，就无法保证承诺的最低保留率。
最大级连突发

Maximum Contained Burst是调制解调器可以代表服务流进行的最大连接帧传输的字节数。正如此参数所暗示的，调制解调器可以在一次传输突发中传输多个帧。如果未指定此值，DOCSIS 1.0电缆调制解调器和较旧的DOCSIS 1.1调制解调器假定在串联突发大小上没有设置明确的限制。符合DOCSIS 1.1或更高版本规范的调制解调器使用1522字节的值。

当电缆调制解调器有代表上游尽力服务流传输的数据时，调制解调器不能简单地将数据转发到DOCSIS网络，而不会延迟。调制解调器必须经过调制解调器向CMTS请求排他上行传输时间的过程。此请求过程可确保数据不会与连接到同一上游信道的另一电缆调制解调器的传输发生冲突。

有时，CMTS会安排CMTS允许电缆调制解调器传输特殊消息（称为带宽请求）的特定时间段。带宽请求是一个非常小的帧，包含调制解调器要传输的数据量的详细信息，以及与需要传输数据的上游服务流对应的服务标识符(SID)。CMTS维护一个与上游服务流匹配的SID编号的内部表。

当上游没有安排其他事件时，CMTS会安排带宽请求机会。换句话说，当上游调度器未计划进行尽力而为的授予、UGS授予或某些其他类型的授予将被放置在特定点时，调度器提供带宽请求机会。因此，当上行信道被大量利用时，电缆调制解调器传输带宽请求的机会就会减少。

CMTS始终确保定期安排少量带宽请求机会，无论上游信道变得多么拥塞。多个电缆调制解调器可以同时传输带宽请求，并损坏彼此的传输。为了降低可能损坏带宽请求的冲突可能性，已经部署了“回退和重试”算法。本文档的后续部分将讨论此算法。

当CMTS收到来自电缆调制解调器的带宽请求时，CMTS会执行以下操作：

CMTS使用带宽请求中收到的SID编号来检查与带宽请求关联的服务流。
然后，CMTS使用令牌桶算法。此算法可帮助CMTS检查如果CMTS授予所请求的带宽，服务流是否会超过规定的最大持续速率。以下是令牌桶算法的计算：

最大(T)= T *(R / 8)+ B

其中：
- Max(T)表示在时间T内服务流上可传输的最大字节数。
- T以秒为单位表示时间。
- R表示服务流的最大持续流量速率（以位/秒为单位）
- B是服务流的最大流量突发量（以字节为单位）。
当CMTS确定带宽请求在吞吐量限制内时，CMTS将带宽请求的详细信息排队到上游调度程序。上游调度程序决定何时授予带宽请求。

Cisco uBR CMTS实施两种上游调度程序算法，称为DOCSIS兼容调度程序和低延迟队列调度程序。有关详细信息，请参阅本文档的DOCSIS兼容计划程序部分和低延迟队列调度程序部分。
然后，CMTS在下一个定期带宽分配MAP消息中包括以下详细信息：
- 当电缆调制解调器能够传输时。
- 电缆调制解调器能传输多长时间。

带宽请求回退和重试算法

带宽请求机制采用简单的“回退和重试”算法来减少但不完全消除同时传输带宽请求的多个电缆调制解调器之间发生冲突的可能性。

决定传输带宽请求的电缆调制解调器必须首先等待随机数的带宽请求机会通过，然后调制解调器才能进行传输。此等待时间有助于降低由于同时传输带宽请求而发生冲突的可能性。

数据回退开始和数据回退结束两个参数决定了随机等待周期。电缆调制解调器将这些参数作为周期性上行信道描述符(UCD)消息内容的一部分进行学习。CMTS代表每个活动上游信道每两秒传输一次UCD消息。

这些回退参数表示为“两次幂”值。调制解调器使用这些参数作为2的幂来计算在传输带宽请求之前等待的时间。两个值的范围都为0到15，且数据回退结束必须大于或等于数据回退开始。

当电缆调制解调器首次要传输特定带宽请求时，电缆调制解调器必须首先选择一个介于0和2之间的随机数，使其数据回退开始功率减1。例如，如果数据回退开始设置为3，则调制解调器必须选择一个介于0和(23^{- 1})=(8 - 1)= 7之间的随机数。

然后，电缆调制解调器必须等待所选随机数的带宽请求传输机会通过，然后调制解调器才能传输带宽请求。因此，虽然由于这种强制延迟，调制解调器在下一个可用机会时无法传输带宽请求，但与另一调制解调器的传输发生冲突的可能性会降低。

数据回退起始值越高，带宽请求之间发生冲突的可能性就越低。较大的数据回退起始值也意味着调制解调器可能需要等待更长的时间才能传输带宽请求，因此上行延迟会增加。

CMTS在下一个传输的带宽分配MAP消息中包括确认。此确认通知电缆调制解调器带宽请求已成功接收。此确认可以：

指明调制解调器何时能进行传输

或者
仅表示已收到带宽请求，并且将在将来的MAP消息中确定传输时间。

如果CMTS在下一条MAP消息中未包含带宽请求的确认，则调制解调器可以断定带宽请求未收到。这种情况可能是由于冲突或上游噪音，或者如果请求被批准，服务流超过规定的最大吞吐率。

无论哪种情况，电缆调制解调器的下一步是回退，并尝试再次传输带宽请求。调制解调器增加了选择随机值的范围。为此，调制解调器会向数据回退起始值添加一个。例如，如果数据回退起始值为3，而CMTS未能接收一个带宽请求传输，则调制解调器在重新传输之前会等待一个介于0和15个带宽请求机会之间的随机值。计算如下：23+1 - 1 = 24 - 1 = 16 - 1 = 15

值范围越大，发生另一次冲突的可能性越小。如果调制解调器丢失了更多带宽请求，调制解调器会继续增加每次重新传输时用作2的幂的值，直到该值等于数据回退端。二的幂不得增长到大于数据回退结束值。

调制解调器重新传输带宽请求最多16次，然后调制解调器丢弃带宽请求。这种情况只发生在极其拥塞的情况下。

您可以使用以下cable interface命令在Cisco uBR CMTS上配置每根上游电缆的数据回退开始和数据回退结束值：

cable upstream upstream-port-id data-backoff data-backoff -start data-backoff-end

思科建议保留数据回退启动和数据回退结束参数的默认值，即3和5。尽力而为调度系统的争用性质意味着对于尽力而为服务流，不可能提供确定或保证的上游延迟或抖动级别。此外，拥塞情况可能导致无法保证特定级别的吞吐量以实现尽力服务流。但是，您可以使用优先级和最小保留速率等服务流属性。借助这些属性，服务流可以在拥塞情况下达到所需的吞吐量级别。

回退和重试算法示例

本示例包括四个电缆调制解调器，名为A、B、C和D，它们连接到同一上游信道。调制解调器A、B和C决定在上游传输一些数据，即_t0。

此处，数据回退开始设置为2，数据回退结束设置为4。调制解调器在首次尝试传输带宽请求之前从中选择间隔的间隔范围是0到3。计算如下：

(22 - 1)=(4 - 1)= 3个间隔。

以下是三个调制解调器选择的从时间t₀等待的带宽请求机会数。

调制解调器A:3
调制解调器B:2
调制解调器C:3

请注意，调制解调器A和调制解调器C选择相同数量的等待机会。

调制解调器B等待在t₀之后出现的两个带宽请求机会。调制解调器B随后传输CMTS接收的带宽请求。调制解调器A和调制解调器C都等待3个带宽请求机会在_t0之后通过。调制解调器A和调制解调器C随后同时传输带宽请求。这两个带宽请求发生冲突并损坏。因此，两个请求都未成功到达CMTS。图2显示了此事件序列。

图2 — 带宽请求示例第1部分

图顶部的灰色条表示电缆调制解调器在_t0之后可获得的一系列带宽请求机会。彩色箭头表示电缆调制解调器传输的带宽请求。灰色栏中的彩色框表示成功到达CMTS的带宽请求。

从CMTS广播的下一条MAP消息包含调制解调器B的授权，但没有调制解调器A和C的说明。这表示它们需要重新传输其带宽请求。

在第二次尝试时，调制解调器A和调制解调器C需要增加两个用户的功率，以计算从中选取的间隔范围。现在，调制解调器A和调制解调器C选择一个介于0和7之间的随机数。计算如下：

(22+1-1)=(23-1)=(8-1)= 7个间隔。

假设调制解调器A和调制解调器C实现重新传输需要的时间是_t1。另外假设另一个调制解调器，称为调制解调器D，决定在同一时间传输一些上游数据，t₁。调制解调器D将首次进行带宽请求传输。因此，调制解调器D使用数据回退开始和数据回退结束的原始值，即0到3 [(22 - 1)=(4 - 1)= 3间隔]。

这三台调制解调器选择这些随机数的带宽请求机会从_t1开始等待。

调制解调器A:5
调制解调器C:2
调制解调器D:2

调制解调器C和D都等待两个带宽请求机会出现在_t1之后。调制解调器C和D然后同时传输带宽请求。这些带宽请求会发生冲突，因此无法到达CMTS。调制解调器A允许通过五个带宽请求机会。然后，调制解调器A传输CMTS接收的带宽请求。图3显示了调制解调器C和D的传输与调制解调器A的成功传输之间的冲突。此图的起始时间参考是t₁。

图3 — 带宽请求示例第2部分

从CMTS广播的下一条MAP消息包含调制解调器A的许可，但没有调制解调器C和D的说明。调制解调器C和D意识到需要重新传输带宽请求。调制解调器D现在即将第二次传输带宽请求。因此，调制解调器D使用数据回退开始+ 1作为计算等待间隔范围时使用的2的幂。调制解调器D选择介于0和7之间的间隔。计算如下：

(22+1 - 1)=(23 - 1)=(8 - 1)= 7个间隔。

调制解调器C将第三次传输带宽请求。因此，调制解调器C在计算等待间隔范围时使用数据回退开始+ 2作为2的幂。调制解调器C选择介于0和15之间的间隔。计算如下：

(22+2 - 1)=(24 - 1)=(16 - 1)= 15个间隔。

请注意，此处的2的幂与数据回退结束值（即4）相同。这是该上游信道上调制解调器的两个值的功率最高。在下一个带宽请求传输周期中，两个调制解调器会选择等待的带宽请求机会数量：

调制解调器C:9
调制解调器D:4

调制解调器D能够传输带宽请求，因为调制解调器D等待四个带宽请求机会通过。此外，调制解调器C还能传输带宽请求，因为调制解调器C现在可以延迟传输九个带宽请求机会。

遗憾的是，当调制解调器C进行传输时，大量入口噪声会干扰传输，CMTS无法接收带宽请求(请参见图4)。因此，调制解调器C再次无法在CMTS传输的下一条MAP消息中看到授权。这使调制解调器C尝试第四次传输带宽请求。

图4 — 带宽请求示例第3部分

调制解调器C已达到数据回退结束值4。调制解调器C无法增加用于选择随机数的等待间隔的范围。因此，调制解调器C再次使用4作为2的幂来计算随机范围。调制解调器C仍使用范围0到15个间隔，根据以下计算：

(24 - 1)=(16 - 1)= 15个间隔。

在第四次尝试中，调制解调器C能够在无争用或无噪音的情况下成功传输带宽请求。

本例中调制解调器C的多带宽请求重新传输演示了在拥塞的上游信道上可能发生的情况。此示例还演示了尽力而为调度模式涉及的潜在问题，以及为什么尽力而为调度不适合需要严格控制数据包延迟和抖动级别的服务。

流量优先级

当CMTS有多个来自多个服务流的挂起带宽请求时，CMTS会查看每个服务流的流量优先级，以决定首先向哪些服务流授予带宽。

CMTS在从优先级较低的服务流发出带宽请求之前，向优先级较高的服务流发出的所有待处理请求授予传输时间。在拥塞的上游情况下，这通常导致高优先级服务流的吞吐量高于低优先级服务流。

需要注意的一个重要事实是，虽然高优先级尽力而为服务流更可能快速接收带宽，但服务流仍可能受到带宽请求冲突的影响。因此，虽然流量优先级可以增强服务流的吞吐量和延迟特性，但是流量优先级仍然不是为需要流量优先的应用提供服务保证的合适方法。

最低保留率

尽力服务流可以获得符合要求的最低保留速率。CMTS确保具有指定最小保留速率的服务流优先于所有其他尽力服务流接收带宽，而不考虑优先级。

此方法尝试提供一种类似于帧中继网络的承诺信息速率(CIR)式服务。CMTS具有准入控制机制，以确保在特定上游上所有连接的服务流的组合最小预留速率不能超过上游信道的可用带宽或其百分比。您可以通过以下per upstream port命令激活这些机制：

[no] cable upstream upstream-port-id admission-control max-reservation-limit

max-reservation-limit参数的范围为10%到1000%，表示与CIR样式服务可消耗的可用原始上游信道吞吐量相比的订用级别。如果将最大保留限制配置为大于100，则上游可以按指定的百分比限制超订用CIR样式服务。

如果CMTS不允许建立新的最低保留速率服务流，因为它们会导致上游端口超过可用上游信道带宽的已配置最大保留限制百分比。最低保留速率服务流仍可能受到带宽请求冲突的影响。因此，最小保留速率服务流无法提供特定吞吐量的真正保证，特别是在极其拥塞的情况下。换句话说，如果CMTS能够从电缆调制解调器接收所有所需带宽请求，CMTS只能保证最小保留速率服务流能够实现特定的保证上游吞吐量。如果使服务流成为实时轮询服务(RTPS)服务流而不是尽力而为服务流，则可以达到此要求。有关详细信息，请参阅实时轮询服务(RTPS)部分。

Piggyback带宽请求

当上游尽力服务流以高速率传输帧时，可以将带宽请求背载到上游数据帧上，而不是单独传输带宽请求。下一个带宽请求的详细信息只被添加到在上游传输到CMTS的数据包的报头中。

这意味着带宽请求不受争用的影响，因此请求到达CMTS的可能性要高得多。带宽请求的概念减少了以太网帧到达最终用户的用户驻地设备(CPE)所花费的时间，因为该帧在上行传输中所花费的时间减少了。这是因为调制解调器不需要经过回退和重试带宽请求传输过程，这可能会受延迟的影响。

在以下场景中，通常会发生带宽请求的搭载：

当电缆调制解调器等待在上游传输帧（例如X）时，调制解调器从CPE接收另一帧（例如Y），以在上游传输。电缆调制解调器无法将新帧Y中的字节添加到传输中，因为这涉及使用比调制解调器所允许的上游时间更多的时间。相反，调制解调器在帧X的DOCSIS报头中填入一个字段，以指示帧Y所需的传输时间。

CMTS接收帧X，并代表Y接收带宽请求的详细信息。根据可用性，CMTS代表Y向调制解调器授予进一步传输时间。

用非常保守的术语来说，带宽请求的传输和带宽分配的接收以及为数据传输分配时间的MAP确认之间经过的时间短达5毫秒。这意味着要进行捎带，电缆调制解调器需要从CPE接收帧，其间的帧长度不到5毫秒。

这值得注意，因为G.711等典型VoIP编解码器通常使用10或20毫秒的帧间周期。在尽力而为的服务流中运行的典型VoIP流无法利用搭载。

串联

当上游尽力服务流以高速率传输帧时，电缆调制解调器可以将几个帧连接在一起，并请求允许一次性传输所有帧。这称为串联。电缆调制解调器只需代表一组串联帧中的所有帧传输一个带宽请求，这可以提高效率。

串接通常发生在类似于捎带的情况下，但当调制解调器决定传输带宽请求时，串接需要在电缆调制解调器内排入多个帧。这意味着串联通常以比捎带更高的平均帧速率发生。此外，这两种机制通常协同工作，以提高尽力而为流量的效率。

可以为服务流配置的最大连接突发字段限制服务流可以传输的连接帧的最大大小。您还可以使用cable default-phy-burst命令来限制级联帧的大小和上游信道调制配置文件中的最大突发大小。

默认情况下，在思科uBR系列CMTS的上游端口上启用串联。但是，您可以使用[no] cable upstream upstream-port-id contacinate [docsis10] cable interface命令，逐个上游端口控制串联连接。

如果配置docsis10参数，则命令仅适用于在DOCSIS 1.0模式下运行的电缆调制解调器。

如果更改此命令，电缆调制解调器必须在CMTS上重新注册，以使更改生效。必须重置受影响上游的调制解调器。电缆调制解调器在调制解调器进行注册时，作为上线过程的一部分，它会了解是否允许串联。

分段

大型帧在上游传输需要很长时间。此传输时间称为序列化延迟。特别是大型上游帧可能需要很长的时间才能传输，以至于它们可能有害地延迟属于时间敏感服务（例如VoIP）的数据包。对于大型连接帧尤其如此。因此，DOCSIS 1.1中引入了分段，以便大帧可以分割成较小的帧以在单独的突发中传输，每个突发花费的传输时间较短。

分段允许在大型帧的分段之间交错小的时间敏感帧，而不必等待整个大型帧的传输。由于需要随每个分段一起传输的额外DOCSIS报头集，因此，作为多个分段的帧的传输比在一个突发中传输帧的效率稍低。但是，分段为上游信道增加的灵活性证明了额外开销的合理性。

在DOCSIS 1.0模式下运行的电缆调制解调器无法执行分段。

默认情况下，在思科uBR系列CMTS的上游端口上启用分段。但是，可以使用[no] cable upstream-port-id fragmentation cable interface命令在每个上游端口上启用或禁用分段功能。

您无需重置电缆调制解调器即可使命令生效。思科建议您始终启用分段。当CMTS认为大数据帧可能干扰小时敏感帧或某些定期DOCSIS管理事件的传输时，通常会发生分段。

您可以使用[no] cable upstream-port-id fragment-force [threshold number-of-fragments] cable interface命令强制DOCSIS 1.1/2.0电缆调制解调器对所有大帧进行分段。

默认情况下，此功能被禁用。如果未在配置中为阈值和分段数指定值，则阈值设置为2000字节，分段数设置为3。fragment-force 命令将服务流请求传输的字节数与指定的阈值参数进行比较。如果请求大小大于阈值，CMTS将带宽授予“分段数”等大部分中的服务流。

例如，假设对于特定上游分段强制，阈值为2000字节，分段数为3。然后假设传输3000字节突发的请求到达。由于3000字节大于2000字节的阈值，因此必须对授予进行分段。由于分段数设置为3，因此传输时间为三个大小相等的许可，每个许可1000字节。

请注意，确保单个分段的大小不超过使用中电缆线卡类型的容量。对于MC5x20S线卡，最大的单个分片不能超过2000字节，而对于其他线卡，包括MC28U、MC5x20U和MC5x20H，最大的单个分片不能超过4000字节。

未经请求的授权服务(UGS)

未经请求的授权服务(UGS)为上游服务流提供定期授权，而无需电缆调制解调器传输带宽请求。此类服务适用于定期生成固定大小帧且无法容忍丢包的应用。IP语音是典型的示例。

将UGS调度系统与时分复用(TDM)系统（例如T1或E1电路）中的时隙进行比较。UGS提供有保证的吞吐量和延迟，这反过来又提供固定周期间隔的连续流以进行传输，而无需客户端定期请求或争用带宽。此系统非常适合VoIP，因为语音流量通常作为固定大小的周期性数据的连续流传输。

UGS的产生是因为在尽力调度模式下，对延迟、抖动和吞吐量缺乏保证。尽力调度模式不能保证特定帧可以在特定时间传输，并且在拥塞的系统中根本不能保证特定帧可以传输。

请注意，虽然UGS类型的服务流是传输VoIP承载流量的最合适的服务流类型，但它们不被视为适合传统互联网应用，如Web、电子邮件或P2P。这是因为传统互联网应用程序不会以固定的周期间隔生成数据，事实上，它可能会花费大量时间根本不传输数据。如果UGS服务流用于传输经典互联网流量，则当应用短暂停止传输时，服务流可能会长时间未使用。这会导致未使用的UGS授权，这表示对上游带宽资源的浪费，这是不可取的。

UGS服务流通常在需要时动态建立，而不是在DOCSIS配置文件中调配。带有集成VoIP端口的电缆调制解调器通常会要求CMTS在调制解调器检测到VoIP电话呼叫正在进行时创建适当的UGS服务流。

思科建议您不要在DOCSIS配置文件中配置UGS服务流，因为此配置使UGS服务流保持活动状态，只要电缆调制解调器联机，无论是否有任何服务使用它。此配置浪费了上行带宽，因为UGS服务流会代表电缆调制解调器持续保留上行传输时间。更好的做法是允许动态创建和删除UGS服务流，以便UGS在需要时处于活动状态。

以下是定义UGS服务流的最常用参数：

未经请求的授权大小(G) — 每个定期授权的大小（以字节为单位）。
额定授予间隔(I) — 授予之间的间隔（微秒）。
允许的授予抖动(J) — 允许的与精确定期授予的微秒差异。换句话说，这是CMTS在CMTS尝试按时安排UGS授权时的回旋余地。

当UGS服务流处于活动状态时(每(I)毫秒),CMTS为服务流提供以未经请求的授权大小(G)字节传输的机会。尽管在理想情况下，CMTS仅提供每(I)毫秒的授权，但可能迟到(J)毫秒。

图5显示了一个时间表，演示了如何使用给定的授权大小、授权间隔和容许的抖动来分配UGS授权。

图5 — 显示定期UGS授权的时间表

绿色图案块表示CMTS将上行传输时间专用于UGS服务流的时间。

实时轮询服务(RTPS)

实时轮询服务(RTPS)提供周期性的非争用带宽请求机会，以便服务流有专用时间传输带宽请求。仅允许RTPS服务流使用此单播带宽请求机会。其他电缆调制解调器不能导致带宽请求冲突。

RTPS适用于半周期生成可变长度帧并需要保证最小吞吐量才能有效工作的应用。IP视频电话或多玩家在线游戏是典型的示例。

RTPS也用于VoIP信令流量。虽然VoIP信令流量不需要以极低的延迟或抖动进行传输，但VoIP确实需要具备在合理时间内到达CMTS的高可能性。如果使用RTPS而非尽力调度，则可以保证语音信令不会因重复的带宽请求冲突而显着延迟或丢弃。

RTPS服务流通常具有以下属性：

Nominal Polling Interval — 单播带宽请求机会之间的间隔（微秒）。
Aberted Poll Jitter — 允许的与精确定期轮询的微秒差异。换句话说，这是CMTS尝试按时安排RTPS单播带宽请求机会时的回旋余地。

图6显示了一个时间表，该时间表演示了如何使用给定的额定轮询间隔和容许的轮询抖动来分配RTPS轮询。

图6 — 显示定期RTPS轮询的时间表

小的绿色图案块表示CMTS提供RTPS服务流的单播带宽请求机会的时间。

当CMTS代表RTPS服务流收到带宽请求时，CMTS以与来自“尽力而为”服务流的请求相同的方式处理带宽请求。这意味着除上述参数外，RTPS服务流定义中还必须包含最大持续流量速率和流量优先级等属性。RTPS服务流通常还包含最小保留流量速率，以确保与服务流关联的流量能够接收承诺的带宽保证。

主动授权服务，带活动检测(UGS-AD)

只有当UGS-AS实际需要传输数据包时，具有活动检测(UGS-AS)的未经请求的授权服务才会将UGS样式传输时间分配给服务流。当CMTS检测到电缆调制解调器在某个时间段内未传输帧时，CMTS会提供RTPS式带宽请求机会，而不是UGS式授权。如果CMTS随后检测到服务流发出带宽请求，CMTS会将服务流恢复为提供UGS样式授权，并停止提供RTPS样式带宽请求机会。

UGS-AD通常用于传输使用语音活动检测(VAD)的VoIP流量的情况。如果UGS-AD检测到用户语音暂停，则语音活动检测会导致VoIP终端停止VoIP帧的传输。虽然此行为可以节省带宽，但可能会导致语音质量问题，尤其是当VAD或UGS-AD活动检测机制在终端开始恢复发言后稍微激活时。当用户在静默后继续发言时，这可能导致砰砰声或单击声音。因此，UGS-AD没有广泛部署。

发出cable service flow inactivity-threshold threshold-in-seconds全局CMTS配置命令，以设置CMTS将非活动UGS-AD服务流从UGS模式切换到RTPS模式的时间段。

threshold-in-seconds参数的默认值为10秒。UGS-AD服务流通常具有UGS服务流的属性以及与RTPS服务流关联的额定轮询间隔和容许轮询抖动属性。

非实时轮询服务(nRTPS)

非实时轮询服务(nRTPS)调度模式与RTPS基本相同，但nRTPS通常与诸如文件传输等非交互服务相关联。非实时组件可能暗示单播带宽请求机会的额定轮询间隔不是完全正常的，或者可能以低于每秒一的速率发生。

一些有线网络运营商可以选择使用nRTPS而不是RTPS服务流来传输语音信令流量。

调度算法

在讨论DOCSIS兼容调度程序和低延迟排队调度程序的具体情况之前，您必须了解确定上游调度程序的特性所需做出的权衡。虽然对调度算法的讨论主要集中在UGS调度模式上，但RTPS式服务也同样适用。

当您决定如何安排UGS服务流时，没有太多灵活的选项。您不能使调度程序更改UGS服务流的授权大小或授权间隔，因为这样的更改会导致VoIP呼叫完全失败。但是，如果更改抖动，呼叫会正常工作，尽管可能会增加呼叫的延迟。此外，修改上游允许的最大呼叫数不会影响单个呼叫的质量。因此，当您安排大量UGS服务流时，请考虑以下两个主要因素：

抖动
每个上游的UGS服务流容量

抖动

容许的授权抖动被指定为UGS或RTPS服务流的属性之一。但是，同时支持某些具有极低容许抖动的服务流和其他具有极大抖动的服务流可能效率低下。通常，您必须对服务流在上游上体验的抖动类型进行统一选择。

如果需要低抖动级别，则调度程序在计划授权时需要不灵活和僵化。因此，调度程序需要对上游上支持的UGS服务流数量进行限制。

对于普通消费者VoIP，抖动级别并不总是需要极低，因为抖动缓冲技术能够补偿高级别的抖动。现代自适应VoIP抖动缓冲区可以补偿150毫秒以上的抖动。但是，VoIP网络会增加对数据包延迟产生的缓冲量。高延迟会导致VoIP体验更差。

每个上游的UGS服务流容量

物理层属性（如信道宽度、调制方案和纠错强度）决定上游的物理容量。但是，上游可支持的同时UGS服务流数量也取决于调度程序算法。

如果不需要极低的抖动级别，您可以放松调度程序的刚性并满足上游可同时支持的更多UGS服务流。如果放松抖动要求，您可以在上游实现更高的非语音流量效率。

注意：不同的调度算法可以允许特定上游信道支持各种数量的UGS和RTPS服务流。但是，此类服务无法在DOCSIS系统中利用100%的上游容量。这是因为上游信道必须为DOCSIS管理流量分配一部分，例如电缆调制解调器用于与CMTS进行初始联系的初始维护消息，以及用于确保电缆调制解调器能够与CMTS保持连接的站维护保持连接流量。

DOCSIS兼容计划程序

DOCSIS兼容调度程序是用于在思科uBR CMTS上调度上游服务的默认系统。此调度程序旨在最大限度地减少UGS和RTPS服务流体验的抖动。但是，此调度程序仍允许您保持一定程度的灵活性，以优化每个上游的并发UGS呼叫数。

符合DOCSIS的调度程序为UGS服务流预先分配上游时间。在安排任何其他带宽分配之前，CMTS将为属于活动UGS服务流的授权预留时间，以确保任何其他类型的服务流或流量都不会取代UGS授权并导致严重抖动。

如果CMTS代表尽力而为型服务流接收带宽请求，则CMTS必须围绕预先分配的UGS授权安排尽力而为服务流的传输时间，以便不影响每个UGS授权的及时调度。

配置

DOCSIS兼容调度程序是Cisco IOS软件版本12.3(9a)BCx及更低版本的唯一可用上游调度程序算法。因此，此调度程序不需要激活配置命令。

对于Cisco IOS软件版本12.3(13a)BC及更高版本，DOCSIS兼容调度程序是两种替代调度程序算法之一，但设置为默认调度程序。您可以为以下一种或全部或部分调度类型启用DOCSIS兼容调度程序：

UGS
RTPS
NRTPS

您可以使用cable upstream upstream-port scheduling type [nrtps]为每种调度类型显式启用DOCSIS兼容调度程序 | rtps | ugs] mode docsis cable interface命令。

使用DOCSIS兼容调度程序是默认配置的一部分。因此，只有当您从非默认低延迟队列调度程序算法中恢复时，才需要执行此命令。有关详细信息，请参阅“低延迟队列调度程序”部分。

准入控制

DOCSIS兼容调度程序的一大优势是此调度程序可确保UGS服务流不会超过上游订阅。如果必须建立新的UGS服务流，并且计划程序发现由于没有空间而无法预先安排授权，则CMTS将拒绝新的UGS服务流。如果允许传输VoIP流量的UGS服务流超订用上游信道，则所有VoIP呼叫的质量将严重下降。

要演示DOCSIS兼容调度程序如何确保UGS服务流不会超订用上游，请参阅本节中的图。图7、8和9显示带宽分配时间线。

在所有这些图中，彩色图案部分显示电缆调制解调器代表其UGS服务流接收授权的时间。在此期间，来自其他电缆调制解调器的其它上行传输不会发生。时间线的灰色部分尚未分配带宽。电缆调制解调器使用此时间传输带宽请求。CMTS稍后可以利用此时间安排其他类型的服务。

图7 - DOCSIS兼容计划程序预计划三个UGS服务流

添加两个具有相同授权大小和授权间隔的UGS服务流。但是，调度程序在预调度它们时没有问题。

图8 - DOCSIS兼容计划程序预计划五个UGS服务流

如果继续并添加另外两个UGS服务流，则会占用所有可用的上行带宽。

图9 - UGS服务流消耗所有可用上游带宽

显然，调度程序无法在此处允许任何进一步的UGS服务流。因此，如果另一个UGS服务流尝试变为活动状态，DOCSIS兼容调度程序就会意识到没有空间进行进一步授权，并阻止建立该服务流。

注意：如本系列图所示，不可能用UGS服务流完全填充上游。调度程序需要适应其他重要类型的流量，例如站维护keepalive和尽力数据流量。此外，只有在所有服务流调度模式（即UGS、RTPS和nRTPS）使用DOCSIS兼容调度程序时，才能保证避免与DOCSIS兼容调度程序的超订用。

虽然使用DOCSIS兼容调度程序时不需要显式准入控制配置，但思科建议您确保上游信道利用率不会上升到可能对尽力而为流量产生负面影响的级别。思科还建议，在相当长的时间内，上游信道总利用率不得超过75%。这是上游利用率的水平，在这种水平下，尽力服务开始体验更高的延迟和更慢的吞吐量。UGS服务仍然有效，无论上游利用率如何。

如果要限制特定上游上允许的流量量，请使用全局、每电缆接口或每上行命令为UGS、RTPS、NRTPS、UGS-AD或尽力服务流配置准入控制。最重要的参数是exclusive-threshold-percent字段。

cable [upstream upstream-number] admission-control us-bandwidth
scheduling-type UGS|AD-UGS|RTPS|NRTPS|BE minor minor-threshold-percent 
major major-threshold-percent exclusive exclusive-threshold-percent
[non-exclusive non-excl-threshold-percent]

以下是参数：

[upstream <upstream <number>]:如果要将命令应用到特定上游（而非电缆接口或全局），请指定此参数。
<UGS|AD-UGS|RTPS|NRTPS|BE>:此参数指定要应用准入控制的服务流的调度模式。
<minor-threshold-percent>:此参数表示按配置的调度类型（将次要警报发送到网络管理站）划分的上游利用率百分比。
<major-threshold-percent>:此参数按配置的调度类型指定上游利用率百分比，在该类型下，向网络管理站发送主警报。此值必须高于为<minor-threshold-percent>参数设置的值。
<exclusive-threshold-percent>:此参数表示专为指定调度类型保留的上游利用率百分比。如果未指定<non-excl-threshold-percent>的值，则此值表示此类型服务流的最大利用率限制。此值必须大于<major-threshold-percent>值。
<non-excl-threshold-percent>:此参数表示此计划类型可以使用的上游利用率高于<exclusive-threshold-percent>的百分比，只要其他计划类型尚未使用。

例如，假设您要将UGS服务流限制为总可用上游带宽的60%。另外，假设您有网络管理站通知，如果由于UGS服务流而导致的上游利用率百分比上升超过40%，则必须发送次要警报，并且超过50%，则必须发送重要警报。发出以下命令：

cable admission-control us-bandwidth scheduling-type UGS minor 40 major 50 exclusive 60

使用分段安排尽力而为流量

符合DOCSIS的调度程序只需围绕预分配的UGS或RTPS授权安排尽力流量。本部分中的图显示了此行为。

图10 — “尽力而为授权待定”计划

图10显示上游有三个UGS服务流，其授权大小和授权间隔都相同，且已预先计划。上游代表三个独立的业务流A、B和C接收带宽请求。业务流A请求中量的传输时间，业务流B请求少量的传输时间，业务流C请求大量的传输时间。

对每个尽力服务流给予同等优先级。另外，假设CMTS按A、B、C的顺序接收每个这些授权的带宽请求。CMTS首先按相同顺序为授权分配传输时间。图11显示了DOCSIS兼容调度程序如何分配这些授权。

图11 — 围绕固定UGS服务流授权安排的尽力而为授权

调度器能够在UGS的前两个分组之间的间隙中将A和B的分组压缩在一起。但是，C的补助比任何可用的缺口都大。因此，DOCSIS兼容调度程序将围绕UGS授权的第三块的C授权分段为称为C1和C2的两个较小授权。分段可防止UGS授权的延迟，并确保这些授权不受尽力流量导致的抖动的影响。

分段会略微增加与数据传输相关的DOCSIS协议开销。对于传输的每个额外分段，还必须传输一组额外的DOCSIS报头。但是，如果不进行分段，调度程序就无法在固定UGS授权之间有效地交换尽力而为授权。在DOCSIS 1.0模式下运行的电缆调制解调器不能发生分段。

优先级

DOCSIS兼容调度程序根据授权所属的服务流的优先级将等待分配的授权放入队列。DOCSIS有8个优先级，最低为0，最高为7。每个优先级都有一个关联的队列。

DOCSIS兼容调度程序使用严格的优先级排队机制来确定何时分配不同优先级的授权传输时间。换句话说，在低优先级队列中的授权之前，必须先为存储在高优先级队列中的所有授权提供服务。

例如，假设DOCSIS兼容调度程序在短时间内按顺序A、B、C、D、E和F接收五个授权。调度程序将每个授权在队列中排队，队列对应于授权服务流的优先级。

图12 — 具有不同优先级的赠款

DOCSIS兼容调度程序会围绕图12中显示为图案化块的预先安排的UGS授权安排尽力而为的授权。DOCSIS兼容调度程序执行的第一项操作是检查最高优先级队列。在这种情况下，优先级7队列已准备就绪，可以安排。调度程序继续为授权B和E分配传输时间。请注意，授权E需要分段，以便授权不会干扰预分配的UGS授权的时间。

图13 — 安排优先级7授予

调度程序确保所有优先级7授予接收传输时间。然后，调度程序检查优先级6队列。在这种情况下，优先级6队列为空，因此调度程序将移至包含授予C的优先级5队列。

图14 — 安排优先级5授予

然后，调度程序通过优先级较低的队列以类似方式继续，直到所有队列都为空。如果有大量授权需要安排，则新的带宽请求可以在DOCSIS兼容调度程序完成向所有挂起的授权分配传输时间之前到达CMTS。假设CMTS在本例中的此时收到优先级为6的带宽请求G。

图15 — 优先级6授予已排队

即使授权A、F和D的等待时间比新排队的授权G长，DOCSIS兼容调度程序仍必须将传输时间分配给G，因为G的优先级较高。这意味着DOCSIS兼容调度程序的下一个带宽分配将是G，A，然后是D(请参见图16)。

图16 — 计划优先级6和优先级2授予

如果假设没有更高优先级的授权在平均时间内进入排队系统，则要安排的下一个授权是F。

符合DOCSIS的调度程序还有两个队列，这些队列在示例中未提及。第一个队列是用于安排定期站点维护保持连接流量以保持电缆调制解调器在线的队列。此队列用于安排电缆调制解调器发送CMTS定期保持连接流量的机会。当DOCSIS兼容调度程序处于活动状态时，此队列首先在所有其他队列之前服务。第二个是分配给服务流的授权的队列，具有指定的最小保留速率(CIR)。调度程序将此CIR队列视为优先级8队列，以确保具有承诺速率的服务流接收所需的最小吞吐量。

不可分段的DOCSIS 1.0授权

从上一节的示例中，授权有时需要分段为多个片段，以确保在预分配的UGS授权中不引起抖动。对于在DOCSIS 1.0模式下运行的电缆调制解调器，如果上游网段有大量UGS流量，则可能会出现此问题，因为DOCSIS 1.0电缆调制解调器可能要求传输一个太大的帧，使其无法适应下一个可用的传输机会。

下面是另一个示例，假设调度程序按该顺序接收新的授权A和B。另外，假设两个授权具有相同的优先级，但授权B适用于在DOCSIS 1.0模式下运行的电缆调制解调器。

图17 - DOCSIS 1.1和DOCSIS 1.0待批准

调度程序尝试先分配授予A的时间。然后，调度程序将尝试分配下一个可用的传输机会以授予B。但是，在A和UGS授权的下一块之间，没有允许授予B的空间保持不分段(见图18)。

图18 - DOCSIS 1.0授予B延期

因此，授予B被延迟到UGS的第二个授予块之后，其中授予B有适合的空间。请注意，在UGS的第二块授权之前，现在有未使用的空间。电缆调制解调器使用此时间将带宽请求传输到CMTS，但这表示带宽使用效率低下。

重新访问此示例，并向调度程序添加额外的两个UGS服务流。虽然授权A可以分段，但由于授权B太大，无法在UGS授权块之间进行调整，因此没有机会安排不可分段的授权B。这种情况使与授权B关联的电缆调制解调器无法在上游传输大帧。

图19 - DOCSIS 1.0授权B无法计划

您可以允许调度程序只是推出UGS授权块，或稍微延迟UGS授权块，以便为授权B腾出空间，但此操作会在UGS服务流中造成抖动。目前，如果您假定要将抖动降至最低，这是一个不可接受的解决方案。

为了解决DOCSIS 1.0授权不可分段的大型问题，兼容DOCSIS的调度程序会定期预先调度上游时间块，其大小与DOCSIS 1.0电缆调制解调器可传输的最大帧的大小相同。调度程序在计划任何UGS服务流之前执行此操作。此时间通常相当于大约2000字节的上游传输，称为“Unfragmentable Block”或“UGS free block”。

DOCSIS兼容调度程序不会在分配给不可分段流量的时间内放置任何UGS或RTPS样式授权，以确保总有机会安排大型DOCSIS 1.0授权。在本系统中，为不可分片的DOCSIS 1.0流量预留时间可减少上游可同时支持的UGS服务流的数量。

图20以蓝色显示了不可分片的块，四个UGS服务流具有相同的授权大小和授权间隔。您不能向此上游添加具有相同授权大小和授予间隔的另一个UGS服务流，因为不允许在蓝色的不分段块区域中调度UGS授权。

图20 — 不可分段块：不能再接受UGS授权

即使不可分片块的调度频率比UGS授权的周期要低，该块往往会在UGS授权的所有块之间产生与自身一样大的未分配带宽空间。这为安排大规模不可分段的授权提供了充足的机会。

返回授权A和DOCSIS 1.0授权B的示例，您可以看到，在已部署了不可分段的块后，DOCSIS兼容调度程序现在可以在UGS的第一个块授权后成功安排授权B。

图21 — 使用不可分片块安排授权

虽然DOCSIS 1.0授权B已成功计划，但在授权A和UGS授权的第一个块之间，仍有很小的未使用空间。此差距表示带宽使用次优，并说明了在部署UGS服务时必须使用DOCSIS 1.1模式电缆调制解调器的原因。

Cable default-phy-burst

默认情况下，在Cisco uBR CMTS上，电缆调制解调器可传输的最大突发量为2000字节。最大上游突发大小的此值用于计算DOCSIS兼容调度程序使用的不可分段块的大小。

可以使用cable default-phy-burst max-bytes-allowed-in-burst per cable interface命令更改最大突发大小。

<max-bytes-allowed-in-burst>参数的范围为0到4096字节，默认值为2000字节。如果要更改默认值的值，必须如何设置此值，有一些重要限制。

对于MC5x20S线卡上的电缆接口，请勿将此参数设置在默认值2000字节以上。对于所有其他线卡类型（包括MC28U、MC5x20U和MC5x20H线卡），可将此参数设置为高达4000字节。

请勿将<max-bytes-allowed-in-burst>参数设置为小于电缆调制解调器可能需要传输的最大单以太网帧的大小，包括DOCSIS或802.1q开销。这意味着此值必须不小于约1540字节。

如果将<max-bytes-allowed-in-burst>设置为特殊值0，则CMTS不使用此参数来限制上游突发的大小。您需要配置其他变量以将上游突发大小限制到合理限制，例如DOCSIS配置文件中的最大级连突发设置或cable upstream fragment-force命令。

修改cable default-phy-burst以更改最大上游突发大小时，UGS空闲块的大小也会相应修改。图22显示，如果减少电缆默认物理突发设置，则UGS空闲块的大小会减小，因此DOCSIS兼容调度程序可允许上游上的更多UGS呼叫。在本示例中，将cable default-phy-burst从默认设置2000减少到较低设置1600，以允许为多个UGS服务流留出空间变为活动状态。

图22 — 减少的Default-phy-burst减小了不可分片的块大小

使用cable default-phy-burst命令减小最大允许突发大小可以略微降低上游对尽力而为流量的效率，因为此命令可减少在一个突发中可连接的帧数。这样的减少还可能导致当上游具有更多UGS服务流活动时的更高分段水平。

减少的串联突发大小可能会影响尽力服务流中的数据上传速度。这是因为一次传输多个帧比传输每个帧的带宽请求更快。由于电缆调制解调器连接沿上游方向传输的大量TCP ACK数据包的能力降低，串联级别降低也可能影响下载速度。

有时，在应用于上游的电缆调制配置文件的“长”IUC中配置的最大突发大小可以确定最大的上游突发大小。如果调制配置文件中的最大突发大小小于cable default-phy-burst（以字节为单位）的值，则可能发生这种情况。这种情况很罕见。但是，如果将cable default-phy-burst参数从默认值2000字节增加，请检查“长”IUC配置中的最大突发大小，以确保它不限制突发。

上行突发大小的另一个限制是在一个突发中最多可以传输255微时隙。如果微时隙大小设置为最小8字节，则这可能成为一个因素。微时隙是DOCSIS网络中上行传输的最小单位，通常等于8或16字节。

不可分段的插槽抖动

调整符合DOCSIS的调度程序以允许上游上同时出现更多UGS流的另一种方法是允许调度程序允许大量突发的不可分段的尽力而为流量向UGS服务流引入少量抖动。可以使用cable upstream-number unfrag-slot-jitter limit val cable interface命令执行此操作。

在此命令中，<val>以微秒为单位指定，其默认值为零，这意味着DOCSIS兼容调度程序的默认行为是不允许不可分段的授权导致UGS和RTPS服务流的抖动。当指定正的不可分段插槽抖动时，DOCSIS兼容调度程序可将UGS授权延迟最多<val>微秒，而UGS授权必须在理想情况下进行计划，因此会导致抖动。

这与将不可分片块大小缩减一个等同于指定微秒数的长度的效果相同。例如，如果维护default-phy-burst（2000字节）的默认值，并且如果为不可分片的插槽抖动指定1000微秒的值，则不可分片的块会减少(请参见图23)。

图23 — 非零不可分段插槽抖动减小不可分段块大小

注意：1000微秒时间对应的字节数取决于上游信道配置为通过信道宽度和调制方案设置运行的速度。

注意：在非零不可分割的插槽抖动的情况下，DOCSIS兼容调度程序能够以与具有降低的默认物理突发类似的方式增加上游支持的UGS授权数。

注：返回到具有大DOCSIS 1.1授予A后跟大型不可分割的DOCSIS 1.0授予B的示例，以在上游上调度。将不可分段的插槽抖动设置为1000微秒。符合DOCSIS的调度程序如本部分的图所示。

注：首先，调度程序为授权A分配传输时间。为此，调度程序将授权分段为授权A₁和A₂，以便授权在UGS授权的第一块之前和之后适合。为了调度授权B，调度程序必须确定在授予A₂之后，调度程序是否可以将不可分段的块调整到空闲空间中，而UGS授予的下一个块的延迟比配置的1000微秒的不可分段的插槽抖动大。这些图表显示，如果调度程序在授予A₂的旁边放置授予B，则UGS流量的下一个块将延迟或推回超过1500微秒。因此，调度程序不能直接在授予A₂之后放置授予B。

图24 — 授予B在授予A2旁无法安排。

图25显示，如果调度程序在UGS的第二块授权后放置授权B，则第三个块的延迟不会超过配置的1000微秒的不可分段插槽抖动。

图25 — 在UGS授权的第二个块之后计划授予B

鉴于此时插入授权B不会对UGS授权造成不可接受的抖动，DOCSIS兼容调度程序会插入授权B，并略微延迟以下UGS授权块。

图26 — 计划不可分段的授权B，并延迟UGS授权

show 命令输出

可以使用show interface cable interface number mac-scheduler upstream-number命令来测量DOCSIS兼容调度程序的当前状态。以下是此命令的输出示例，如带MC28U线卡的Cisco uBR7200VXR所示。

uBR7200VXR# show interface cable 3/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable3/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 0
     Queue[BE(7) Grants] 1/64, 0 drops, max 2
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 0
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 1/64, 0 drops, max 1
     Req Slots 36356057, Req/Data Slots 185165
     Init Mtn Slots 514263, Stn Mtn Slots 314793
     Short Grant Slots 12256, Long Grant Slots 4691
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 277629
     Fragmentation count 41
     Fragmentation test disabled
     Avg upstream channel utilization : 26%
     Avg percent contention slots : 73%
     Avg percent initial ranging slots : 2%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 6, Reqpolls 0, Util 27%
     UGS    : 6 SIDs, Reservation-level in bps 556800
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 35 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 0 SIDs, Reservation-level in bps 0

本部分说明此命令输出的每一行。请注意，本文档的此部分假定您已经非常熟悉一般的DOCSIS上游计划概念。

DOCSIS 1.1 MAC调度程序，用于Cable3/0/U0

命令输出的第一行指示数据所属的上游端口。
Queue[环轮询] 0/128, 0丢弃，最多1

此行显示将站维护keepalive或测距机会馈送到符合DOCSIS的调度程序的队列状态。0/128表示队列中最多有128个待定范围商机中目前有零个。

丢弃计数器指示由于此队列已满（即128个挂起的测距机会）而无法将测距机会排队的次数。此处的丢弃只可能发生在具有大量电缆调制解调器的上游，并且如果有大量UGS或RTPS服务流处于活动状态，则可能会发生。当DOCSIS投诉调度程序运行时，此队列以最高优先级提供服务。因此，此队列中的丢包极不可能，但很可能表示上游信道严重超订用。

max计数器指示自上次运行show interface cable mac-scheduler命令以来，此队列中存在的元素的最大数量。理想情况下，这应该保持在尽可能接近零的水平。
Queue[CIR授权] 0/64, 0丢弃，最多0

此行显示队列的状态，该队列使用指定的最小保留流量速率管理服务流的授权。换句话说，此队列服务授予承诺信息速率(CIR)服务流。0/64表示队列中最多有64个待处理的授权中，目前有零个。

丢弃计数器指示由于此队列已满（即，队列中有64个授权）而无法将CIR授权排队的次数。如果UGS、RTPS和CIR类型服务流超订用上游，则丢弃可以在此累积，并且可能表明需要更严格的准入控制。

max计数器指示自上次运行show interface cable mac-scheduler命令以来此队列中的最大授权数。此队列具有第二高的优先级，因此DOCSIS兼容调度程序会为此队列的元素分配时间，然后调度程序才会为尽力而为队列提供服务。
队列[BE(w)授权] x/64,y丢弃，最大z

接下来的八个条目显示管理优先级7到0服务流的授权的队列的状态。这些条目中的字段与CIR队列条目中的字段具有相同的含义。该组中要服务的第一个队列是BE(7)队列，最后要服务的队列是BE(0)队列。

如果更高优先级的流量消耗了所有上游带宽，或者UGS、RTPS和CIR类型服务流发生上游超订用，则这些队列中可能会发生丢包。这可能表明需要重新评估高容量服务流的DOCSIS优先级，或需要对上游实施更严格的准入控制。
需插槽36356057

此行指示自上游激活以来已通告的带宽请求机会数。此数量必须持续增加。
请求/数据插槽185165

虽然名称表明此字段显示在上游上通告的请求或数据业务机会的数量，但此字段实际显示CMTS为促进高级频谱管理功能而通告的期间数。此计数器预期会增加MC28U和MC520样式线卡上的上行流。

请求/数据机会与带宽请求机会相同，但电缆调制解调器也能够在这些时段传输少量突发数据。Cisco uBR系列CMTS当前没有安排实际请求/数据机会。
初始MTN插槽514263

此行表示自上游激活以来已通告的初始维护机会数。这个数字必须持续上升。最初尝试建立与CMTS连接的电缆调制解调器使用初始维护机会。
STN MTN插槽314793

此行表示上游提供的站维护保持连接或测距机会的数量。如果上游有电缆调制解调器在线，则此数字必须持续上升。
短授权插槽12256，长授权插槽4691

此行表示上游上提供的数据授权数。如果有电缆调制解调器传输上行数据，则这些数字必须持续上升。
ATDMA短授权插槽0、ATDMA长授权插槽0、ATDMA UGS授权插槽0

此行表示在上游的高级时分多址(ATDMA)模式下提供的数据授权数。如果有电缆调制解调器在DOCSIS 2.0模式下运行，并且它们传输上游数据，则这些数字必须持续上升。请注意，ATDMA单独计算UGS流量。
Awacs插槽277629

此行显示专用于高级频谱管理的时段数。为了实现高级频谱管理，CMTS需要定期安排每个电缆调制解调器必须进行简短传输的时间，以便内部频谱分析功能可以评估来自每个调制解调器的信号质量。
分段计数41

此行显示上游端口计划接收的分片总数。例如，将帧分成三个部分后，此计数器将增加三个。
分段测试已禁用

此行表示尚未调用test cable fragmentation命令。请勿在生产网络中使用此命令。
平均上游信道利用率：26%

此行显示上游数据传输的当前上游信道利用率。这包括通过短、长、ATDMA短、ATDMA长和ATDMA UGS授权进行的传输。该值以滚动平均值每秒计算一次。思科建议，在高峰使用期，此值不要超过75%。否则，最终用户可能会开始注意到尽力通信的性能问题。
争用插槽的平均百分比：73%

此行显示专用于带宽请求的上行时间百分比。这等于上游的空闲时间量，因此随着Avg上游信道利用率百分比的增加而减少。
初始测距插槽的平均百分比：2%

此行表示电缆调制解调器尝试与CMTS建立初始连接时专用于初始测距机会的上游时间的百分比。此值必须始终保持在总利用率的低百分比。
延迟MAP上丢失的微时隙平均百分比：0%

此行指示因CMTS无法及时向电缆调制解调器传输带宽分配MAP消息而未计划的上行时间百分比。此参数必须始终接近零，但在CPU负载极高的系统上可以开始显示较大的值。
计划表RSV状态：Grants 0、Reqpolls 0

此行显示在DOCSIS兼容调度程序中为其预先分配了授权但尚未激活的UGS样式服务流（授权）或RTPS样式服务流(Reqpolls)的数量。当您通过负载均衡将现有UGS或RTPS服务流从一个上游传输到另一个上游时，就会发生这种情况。请注意，此图仅适用于使用DOCSIS兼容调度程序的授权，而不适用于LLQ调度程序。
计划表ADM状态：Grants 6、Reqmolls 0、Util 27%

此行指示在此上游的DOCSIS兼容调度程序中为其预先分配了授权的UGS样式服务流（授权）或RTPS样式服务流(Reqpolls)的数量。利用率是这些服务流估计的可用上游总带宽利用率。请注意，此图仅适用于使用DOCSIS兼容调度程序的授权，而不适用于LLQ调度程序。
<计划类型> :x SID，预留级别（以bps为单位）y

此行指示上游上存在的<Scheduling-type>服务流或SID的数量，以及这些服务流保留的带宽量（以位/秒为单位）。为了尽力而为和RTPS式服务流，只有在服务流配置了最低保留速率时，才会保留带宽。

DOCSIS兼容调度程序的优点和缺点

DOCSIS兼容调度程序的目标是将UGS和RTPS式服务流的抖动降至最低，同时支持不可分段的DOCSIS 1.0突发。为了实现这些目标，DOCSIS兼容调度程序所做的权衡是每个上游支持的UGS服务流的最大数量小于DOCSIS上游物理支持的理论最大数量，并且尽力而为的流量可能会受到一定程度的分段。

虽然DOCSIS兼容调度程序支持的并发UGS服务流数略低于理论上上游最大数量，而某些其他调度实施可支持每个上游更多UGS服务流，但您必须关注权衡。

例如，任何调度程序都不能支持消耗接近100%上游信道带宽的无抖动UGS服务流，同时支持来自DOCSIS 1.0调制解调器的大型不可分段的连接帧。关于DOCSIS兼容调度程序的设计，需要了解两个重要方面。

75%是最大期望上游利用率。

思科发现，如果上游持续以超过75%的利用率运行（包括UGS服务流的利用率），尽力而为流量性能将开始受到明显影响。这意味着，如果UGS和VoIP信令占用上游75%以上，则通过尽力而为服务流传输的任何正常IP流量都会开始受到额外的延迟的影响，这会导致明显降低的吞吐量和响应时间。这种性能在更高利用率级别下的下降是大多数现代多路访问网络系统共享的特性，例如以太网或无线LAN。
当使用通常部署的3.2MHz上游信道宽度时，DOCSIS兼容调度程序允许UGS服务流利用高达75%的上游信道。这些服务流传输G.711 VoIP呼叫。

这两点有助于深入了解构建DOCSIS兼容调度程序时考虑的设计注意事项。DOCSIS兼容调度程序设计为，对于典型UGS服务流(G.711)，且最常部署的信道宽度为3.2MHz，每个上游的呼叫限制开始应用在大约75%利用率标记上。这意味着调度程序成功地将抖动降至最低，并允许上游中合理数量的UGS服务流。

换句话说，DOCSIS兼容调度程序设计为在生产DOCSIS网络中正常运行，并且不允许UGS服务流使用不切实际的高百分比的上游带宽。此场景可能发生在人工实验室测试场景中。

您可以调整符合DOCSIS的调度程序，以适应每个上游增加的UGS呼叫数，尽管这会损害UGS抖动和尽力而为的流量效率。为此，必须将cable default-phy-burst参数降至建议的1540字节的最小值。如果需要进一步的呼叫密度，请将cable upstream unfrag-slot-jitter设置为2000微秒等值。但是，思科一般不建议对生产网络进行这些设置。

DOCSIS兼容调度程序的另一个优势是，CMTS运营商没有明确为UGS和RTPS式服务流配置准入控制的强制性要求。这是因为，预分配调度方法消除了意外超订的可能性。即使如此，思科仍建议运营商确保在高峰时段的较长时段内上游总利用率不超过75%。因此，思科建议将准入控制配置为最佳实践。

DOCSIS兼容调度程序的一个缺点是，当UGS使用率较高时，UGS授权的固定位置可能需要分段尽力授权。通常，分段不会引起显着的性能问题，但会略微增加尽力而为流量的延迟，并增加上游信道上的协议开销。

另一个缺点是，当DOCSIS 1.0电缆调制解调器想要进行大型的不可分段上游传输时，在预先安排的UGS授权块之间出现适当间隙之前，可能会出现延迟。这也可能导致DOCSIS 1.0上游流量的延迟增加，以及可用上游传输时间的使用不达到最佳状态。

最后，DOCSIS兼容调度程序设计为在所有UGS服务流共享相同授权大小和授权间隔的环境中最佳工作。也就是说，所有VoIP呼叫共享相同的编解码器，例如10毫秒或20毫秒的分组化G.711，这与基于典型Packetcable 1.0的系统中的情况相同。当存在不同的授权间隔和大小时，DOCSIS兼容调度程序支持大量UGS服务流的能力在上游上会降低。此外，当调度程序尝试使用不同的周期和大小交错UGS服务流时，某些授权可能会产生非常小的抖动（小于2毫秒）。

随着PacketCable多媒体(PCMM)网络越来越普遍，具有不同分组间隔的各种VoIP编解码器可以更加普遍地同时运行。此类环境可以借助低延迟排队调度程序。

低延迟队列调度程序

低延迟队列(LLQ)调度程序是在Cisco IOS软件版本12.3(13a)BC中引入的。LLQ是在Cisco uBR CMTS上调度上游服务的替代方法。此调度程序旨在最大化上游可同时支持的UGS和RTPS式服务流的数量，并在存在UGS服务流时提高尽力而为流量的效率。取舍是LLQ调度程序不会就UGS和RTPS服务流的抖动提供任何保证。

如DOCSIS兼容调度程序部分所讨论的，DOCSIS兼容调度程序会提前为UGS和RTPS式服务流预分配传输时间。这类似于传统时分复用(TDM)系统为服务分配带宽以保证某些延迟和抖动级别的方式。

在基于数据包的现代网络中，低延迟排队是路由器用于确保与高优先级服务（例如语音和视频）关联的数据包在其它低优先级数据包之前能够在网络中传输的方法。这也是现代路由器用于确保重要流量的延迟和抖动最小化的方法。

对基于TDM的系统使用“保证”一词，对基于LLQ的系统使用“最小化”一词与抖动和延迟有关。虽然确保零延迟和抖动是可取的，但取舍是，此类系统通常不灵活、难以重新配置，并且通常无法轻松适应网络条件的变化。

一种系统，其能够最大限度地减少延迟和抖动，而不是提供严格的保证，它能够提供灵活性，以便在网络条件发生变化时不断优化自身。低延迟队列调度程序的行为与基于数据包路由器的LLQ系统类似。此系统不是预先安排的UGS授权分配系统，而是在需要安排授权时“尽快”安排授权。

为UGS服务流提供授权的方法必须尽快分配，但不一定是完美的周期性，因此，此系统消除了对增加UGS容量和减少尽力数据分段的严格抖动保证。

配置

对于Cisco IOS软件版本12.3(13a)BC及更高版本，LLQ调度程序是两种替代调度程序算法之一。您可以为以下一种或全部或部分调度模式启用LLQ:

UGS
RTPS
NRTPS

默认情况下，LLQ调度程序未启用。必须为所需的上游调度类型显式打开LLQ调度程序。使用cable upstream upstream-port scheduling type [nrtps | rtps | ugs] mode llq cable interface命令。

通常，如果这是所需的计划模式，则可以为所有列出的计划模式启用LLQ计划程序。以下是一个示例，您希望仅为一种调度模式启用LLQ调度，但为其他模式保留DOCSIS兼容调度程序：

RTPS服务流对抖动没有严格要求，但UGS服务流有。在这种情况下，您可以为RTPS服务流启用LLQ调度程序，并保留UGS的DOCSIS兼容调度程序。

LLQ调度程序操作

LLQ调度程序与DOCSIS兼容调度程序的优先级队列功能工作方式相同，并添加了特殊低延迟队列(LLQ)，该队列优先于所有其他队列。

LLQ调度程序代表所有活动UGS（和RTPS）样式服务流启动计时器。计时器设置为每“授予间隔”关闭一次。每当计时器过期时，UGS授权会在LLQ队列中排队。由于此授权被放在具有最高优先级的LLQ队列中，因此该授权将安排在存在可用空间的下一个可能时刻。

本节中的图显示了一个系统示例，该系统具有三个具有相同授予间隔的活动UGS服务流。图27显示了UGS服务流在左侧的计时器，标有UGS-1到UGS-3。黄色箭头沿顺时针方向移动。当黄色箭头朝红点向上时，UGS授权将添加到LLQ队列。您还可以看到熟悉的八个优先级队列0到7以及优先于所有队列的新LLQ队列。最后，右边是带宽分配时间线，它描述了如何在上游安排授权。为了更加清晰，带宽分配时间行包括“当前时间”指针。当示例继续时，此指针沿时间轴向前移动。

图27 — 低延迟排队系统

出现的第一个事件是左上角的UGS-1计时器超时。相应的授权在LLQ队列中排队。同时，优先级为2的最大努力授权A被排入队列。

图28 - UGS-1的授权和优先级2的授权A已排队

LLQ调度程序现在按优先级顺序为待处理的授权分配传输时间。接收传输时间的第一个授权是在LLQ队列中等待的UGS-1的授权。Grant A如下。

图29 — 授予UGS-1和授予A分配传输时间

下一个事件是UGS-2计时器过期并导致UGS-2服务流的授权在LLQ队列中排队。同时，优先级0授予B被排队，优先级6授予C被排队。

图30 - UGS-2计时器过期。授权B和C已排队

LLQ调度器再次按授予优先级的顺序分配传输时间，这意味着首先调度器为UGS-2的授予分配时间，然后为授予C，最后为授予B。

图31 — 授予UGS-2、C和B分配传输时间

假设暂时没有尽力授权进入调度程序。UGS计时器每次的过期时间都多几倍。现在，您可以看到调度程序为UGS服务流分配授权的周期类型。它们似乎间隔均匀。假设当授权在带宽分配时间线上彼此以这种方式出现时，它们不会经历任何重大抖动。

图32 - UGS-1、UGS-2和UGS-3获得多项授权。授权D已排队

图32表示下一次UGS-2授权的理想位置。如果UGS-2可以将授权置于此位置，则UGS-2不会遇到授权的任何抖动。请注意，下一次UGS-2授权仍有时间在LLQ队列中排队。

图32还表明超大优先级0授予D刚进入优先级0队列。LLQ调度程序的下一个操作是安排授予D的传输时间。

图33显示此场景。将时钟向前调一点，到UGS-2的下一个授权排队的点。

图33 — 授予D接收传输时间。UGS-2的授权已排队

授予D似乎安排在下一次UGS-2授予必须安排为零抖动时。现在，问题是为什么LLQ调度程序允许在此时安排授予D，并且不会将授予D延迟到UGS-2的授予之后，或者为什么D不分段。答案是，LLQ调度程序不为UGS服务流预分配传输时间。因此，LLQ调度程序不会提前知道UGS授权将放在带宽分配时间线上。LLQ调度程序在LLQ队列中排队之前不知道UGS授权。在本例中，当UGS-2的授权进入队列时，已计划授予D。

LLQ调度程序在下一个可用机会安排UGS-2的授权，但此授权稍微从理想位置延迟，从定义上说，这意味着此特定授权会经历一些抖动。

图34 - UGS-2的授予延迟且体验抖动

虽然符合DOCSIS的调度程序本可以避免此抖动，但LLQ调度程序可以避免延迟或分段授权D，而仅以少量抖动为代价。VoIP终端中的抖动缓冲区可以轻松补偿这种抖动。

出现抖动的另一种情况是，多个服务流的LLQ计时器同时到期，UGS授权等待在LLQ队列中排队的其他UGS授权之后。LLQ调度程序旨在将发生此情况的可能性降至最低。调度程序自动延长服务流计时器的到期时间。

根据符合DOCSIS的调度程序，LLQ调度程序还有两个队列，示例中未提及。队列如下：

第一个队列用于安排定期站点维护保持连接流量，以使电缆调制解调器保持在线。此队列在LLQ队列后即可服务。
第二种是分配给具有最小保留速率（CIR服务流）的服务流的授权队列。此CIR队列被视为“优先级8”队列，以确保具有承诺速率的服务流接收其所需的最小吞吐量。

准入控制

与符合DOCSIS的调度程序不同，LLQ调度程序不使用预调度系统，该预调度系统不会使用UGS和RTPS服务流阻止上游意外超订用。因此，必须对使用LLQ调度程序的任何上游显式配置上游准入控制。此配置可确保UGS服务流的上游总带宽不超过正常限制。

思科通常建议，在高峰使用期，不允许上游信道的利用率超过75%。例如，如果UGS流量消耗了75%以上的上游带宽，则尽力而为数据将开始遭遇过度延迟和吞吐量性能问题。

当然，如果CMTS运营商可以接受对尽力而为流量的负面影响，您可以让UGS服务流消耗超过可用上游带宽的75%。但是，您还必须考虑对上游信道上第2层管理流量的影响。您必须留出时间进行初始和站维护消息（电缆调制解调器keepalive）。如果不考虑这一点，并且UGS流量消耗接近100%的带宽，则电缆调制解调器无法联机或可能脱机。

以下是准入控制的示例配置。本示例将特定上游的UGS服务流限制为上游可用带宽的50%。当达到30%和40%利用率的次要和主要阈值时，此形式的命令还会将SNMP陷阱传输到任何已配置的网络管理站。命令如下：

cable upstream upstream-number admission-control us-bandwidth scheduling-type UGS minor 30 major 40 exclusive 50

有关如何配置准入控制，请参阅本文档的“DOCSIS兼容调度程序”部分下的准入控制部分。

show 命令输出

发出show interface cable interface-number mac-scheduler upstream-number命令以测量LLQ调度程序的当前状态。

以下是此命令的输出示例。命令输出中与DOCSIS兼容调度程序运行时不同的部分以粗体文本显示：

uBR7200VXR# show interface cable 5/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable5/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 2
     Queue[BE(7) Grants] 0/64, 0 drops, max 0
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 2
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 0/64, 0 drops, max 5
     Queue[LLQ Grants] 0/64, 0 drops, max 3
     Req Slots 165488850, Req/Data Slots 871206
     Init Mtn Slots 1727283, Stn Mtn Slots 1478295
     Short Grant Slots 105668683, Long Grant Slots 52721
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 1303668
     Fragmentation count 11215
     Fragmentation test disabled
     Avg upstream channel utilization : 6%
     Avg percent contention slots : 91%
     Avg percent initial ranging slots : 3%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 0, Reqpolls 0, Util 1%
     UGS    : 3 SIDs, Reservation-level in bps 278400
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 14 SIDs, Reservation-level in bps 0
     r4k ticks in 1ms 600000
     Total scheduling events 5009
     No search was needed 5009
     Previous entry free 0
     Next entry free 0
     Could not schedule 0
     Recovery failed 0
Curr time 1341 entry 61
Entry 188, Bin 13
    SID: 416 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 13
Entry 188, Bin 14
    SID: 414 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 14
Entry 192, Bin 12
    SID: 415 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 192, skew from ref 0, priority 10
    position 192, bin 12

有关此输出中纯文本行的说明，请参阅DOCSIS兼容调度程序的“显示命令输出”部分。

以下是show命令输出粗体行的说明：

Queue[LLQ Grants] 0/64, 0丢弃，最多3

此行显示LLQ队列的状态，该队列管理在电缆上游调度类型[nrtps]中指定的服务流类型的授权 | rtps | ugs] mode llq命令。0/64表示队列中最多有64个待处理的授权中，目前有零个。

丢弃计数器指示调度程序由于此队列已满而无法对UGS授权或RTPS轮询排队的次数（换句话说，当64个授权处于队列中时）。如果此队列中发生丢包，最可能的解释是上游已超订用UGS或RTPS服务流，您必须应用更严格的准入控制。

max计数器指示自上次运行show interface cable mac-scheduler命令以来此队列中的最大授权数。当存在时，此队列在所有列出的队列中具有最高优先级。
1ms 600000中的r4k计数

此字段表示LLQ调度程序使用的内部计时变量，以确保授权以高精度放入LLQ队列。
计划事件总数5009

此行指示自上次为此上游运行show interface cable mac-scheduler命令以来LLQ调度程序尝试将授予排入队列的次数。每次运行show命令时，都会重置此计数器。
无需搜索5009

在LLQ调度程序对授权进行排队后，LLQ调度程序会尝试重置服务流计时器，以准备下次授权排队。如果重置计时器没有问题，此计数器会增加。此计数器理想情况下必须具有与Total scheduling events计数器相同的值。
上一个条目免费0，下一个条目免费0

这些计数器在Cisco IOS软件的当前版本中均未增加。这些计数器始终保持为零。
无法计划0，恢复失败0

此行表示LLQ调度程序无法安排服务流授权计时器正确设置的次数。只有在LLQ调度程序以极低的授权间隔处理极大数量的授权时，才会发生这种情况。这些计数器在生产网络中增量的可能性很小。这些计数器的增量可能表示UGS和RTPS服务流消耗的带宽比上游物理可用的带宽多。在此场景中，您需要实施适当的准入控制命令。
当前时间1341条目61

此行显示LLQ调度程序的内部计时器，以毫秒为单位。当此处列出的“条目”等于每个服务流统计信息中列出的“条目”字段时，授权将在LLQ队列中排队。

对LLQ调度程序处理的每个服务流重复这些统计信息。在本例中，有三种此类服务流。

第188条，第13条

当“条目”值等于上一项中的“条目”字段时，此服务流的计时器将过期，授权将进入LLQ队列。此字段会在服务流每次将授权排入队列时重置。
SID:416

授予LLQ调度程序计划的服务流的服务标识符(SID)。
IUC:5

在MAP消息中为属于此服务流的授权通告的间隔使用代码。当使用UGS样式的服务流时，这几乎总是5表示“短数据”，6表示“长数据”，11表示“高级PHY UGS”。对于RTPS样式的服务流，“请求”的值始终为1。
size_ms:17 size_byte:232

授予的大小（以微时隙为单位），后跟授予的大小（以字节为单位）。微时隙是DOCSIS网络中上行传输的最小单位，通常等于8或16字节。
帧：n

指示授权是否可分段。目前，此值始终设置为N。
无效：20

授予或轮询间隔（以毫秒为单位）。
类型8

8表示此服务流为UGS，10表示RTPS，11表示NRTPS。
完全时间参考188

必须安排此授权的理想时间。这通常与顶部的“Entry”相同。如果不是，则表明上游严重拥塞，需要更严格的准入控制。
偏离参考0

计划此授权的时间与理想情况下必须计划授予的时间之间的差异。这是“Entry”和“perfect time ref”之间的区别。因此，此值通常必须为零。
第 10 优先级

在Cisco IOS软件的当前版本中，此值始终设置为10，但将来可能会有所不同。
位置188, bin 13

这些字段必须与此列表顶部的“Entry， Bin”相同。

LLQ调度程序的优点和缺点

LLQ调度程序的目标是增加上游信道的UGS和RTPS容量，并提高尽力而为流量的效率。LLQ调度程序为实现这些目标而做的权衡是，此调度程序没有明确提供UGS和RTPS服务流抖动的保证。相反，LLQ调度程序将UGS授权和RTPS轮询安排在尽可能接近理想时间的时间，以尽量减少抖动。

LLQ调度程序还能够比DOCSIS兼容调度程序更好地处理具有不同授权间隔和授权大小的多个UGS服务流。在PCMM环境中，不同类型的VoIP呼叫和可能的其他应用程序都同时在一个上游信道上服务时，此功能非常有用。

LLQ调度程序可以更高效地调度尽力而为流量，因为LLQ调度程序可以降低授权分段的可能性。当安排不可分片的DOCSIS 1.0突发时，LLQ调度程序不会像DOCSIS兼容调度程序有时那样在UGS授权或RTPS轮询前创建未使用带宽的间隙。这样可以更好地利用可用上游时间。

虽然在使用LLQ调度程序时，UGS抖动通常比使用DOCSIS兼容调度程序时高，但在典型的基于DOCSIS或PacketCable的网络中，LLQ调度程序抖动级别完全在VoIP终端抖动缓冲技术的容量内。这意味着在正确设计的VoIP网络中使用LLQ调度程序时，对VoIP呼叫质量没有明显影响。

您可以限制因大型上游突发而产生的抖动。为此，请确保将cable default-phy-burst参数的默认值保持为2000字节或更小。如果系统使用特别慢的上行信道，例如800 kHz或更小的信道宽度，则如果使用cable upstream fragment-force命令强制将大突发分段为较小突发，则可以进一步降低抖动。

当LLQ调度程序正在使用时，您必须配置电缆准入控制以防止上游信道超订用的可能性。比上游可以实际处理的活动UGS服务流更多，导致上游上所有UGS服务流的语音质量较差。在极端情况下，这也意味着电缆调制解调器离线，新的电缆调制解调器无法上线。思科建议CMTS运营商配置准入控制，以便任何上游端口上的总上游利用率在较长时间内不超过75%。

结论

Cisco uBR系列DOCSIS CMTS产品提供两种替代的上游调度算法，因此能够满足各种网络条件。

DOCSIS兼容调度程序针对低抖动而优化，最适合具有统一VoIP编解码器的典型Packetcable 1.x语音系统，并且需要UGS服务流使用上游信道的标准级别。

低延迟队列调度程序旨在通过UGS服务流支持高于正常水平的上游利用率，提高尽力而为流量效率，以及使用UGS和RTPS服务流且具有各种授予间隔和授予大小的系统。

附录 A：迷你

微时隙是DOCSIS上游传输的最小单位。当有线调制解调器向CMTS发送带宽请求以请求上行传输时间时，调制解调器以微时隙为单位请求，而不是以字节或毫秒为单位。此外，当带宽分配MAP消息通知调制解调器它们何时可以传输以及传输时间长度时，该消息以微时隙为单位包含信息。

调制解调器可请求在一个突发中传输的最大微时隙数为255。微时隙大小以称为DOCSIS计时器的单位指定。DOCSIS刻度等于6.25微秒的时间。

要设置上游端口的微时隙大小（以刻度为单位），请发出cable upstream <upstream-number> minislot-size [1 | 2 | 4 | 8 | 16 | 32 | 64 | 128] cable interface命令。

特定上游信道宽度仅允许某些微时隙大小。此表显示了有效微时隙大小与DOCSIS上游信道宽度之比，还显示了具有有效设置的微时隙的调制方案符号长度。

注意：X标记表示无效组合。

	200 kHz	400 kHz	800 kHz	1.6 MHz	3.2 MHz	6.4 MHz
微小尺寸（单位：刻度）
1	X	X	X	X	X	32
2	X	X	X	X	32	64
4	X	X	X	32	64	128
8	X	X	32	64	128	256
16	X	32	64	128	256	X
32	32	64	128	256	X	X
64	64	128	256	X	X	X
128	128	256	X	X	X	X

要计算每个微时隙传输的字节数，请将每个微时隙的符号乘以配置的调制方案的每个符号的位数。不同的调制方案传输每个符号的不同位数，如下表所示：

DOCSIS 1.1 TDMA调制方案	比特/符号
QPSK	2
16-QAM	4

DOCSIS 2.0 ATDMA调制方案	比特/符号
8-QAM	3
32-QAM	5
64-QAM	6

例如，如果信道宽度为1.6 MHz，微小尺寸为4滴度，则可以使用第一个表得出每微小32个符号的数字。使用第二张表将此图转换为字节，因为QPSK符号包含2位。本例中的一个微时隙相当于每个微时隙32个符号*每个符号2个位=每个微时隙64个位=每个微时隙8个字节。

请记住，电缆调制解调器可请求传输的最大微时隙数是255。因此，在本示例中，调制解调器可以做的最大突发量是255微时隙x 8字节/微时隙= 2040字节。

请注意，此图（以字节为单位）是后转纠错和后物理层开销图。纠错和其他DOCSIS PHY层开销使以太网帧通过上游信道时的长度增加大约10%到20%。要导出精确的数字，请使用应用于上游端口的调制配置文件。

此讨论意义重大，因为本文档的前面部分指出，电缆调制解调器最大突发大小的限制之一是cable default-phy-burst命令中配置的值。如果cable default-phy-burst命令在本示例中设置为4000字节，则限制因子或突发大小是255微时隙限制（2040字节减开销），而不是cable default-phy-burst值。

使用show controller cable interface-number upstream-number命令可以观察上游的微小尺寸的不同表达式。示例如下：

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

思科建议您设置微时隙大小，使微时隙等于16字节或最接近允许的值。16字节的微时隙大小使电缆调制解调器能够生成FEC后突发，最大255 * 16 = 4096字节。

附录 B：MAP高级

CMTS定期生成一种称为带宽分配MAP的特殊消息，该消息通知电缆调制解调器调制解调器在上行信道上进行传输的精确时间。传输MAP消息的电信号需要有限的时间来物理地通过混合光纤同轴(HFC)网络从CMTS传播到所有连接的电缆调制解调器。因此，MAP消息需要足够早地传输，以便调制解调器接收该消息并能够进行其上游传输，以便它们在指定时间到达CMTS。

MAP提前时间或MAP查看提前时间表示CMTS生成MAP消息的时间与MAP订购的第一次传输需要由CMTS接收的时间之差。此时间表示DOCSIS系统中存在的以下延迟的组合：

CMTS在软件中构造MAP消息以及该消息排队到下游传输电路并由下游传输电路处理所需的时间。此组件的价值特定于不同的平台和架构，通常是固定的价值。
下行交织函数所增加的延迟，用于前向纠错以防冲激噪声。要更改此值，请更改下游交织器参数。
电信号从CMTS经过HFC网络到电缆调制解调器，然后再返回的时间。DOCSIS指定CMTS和电缆调制解调器之间的最大单向行程时间为800微秒。此值取决于电缆设备的物理长度。下行调制方案和上行信道宽度和调制方案也影响该值。
电缆调制解调器处理收到的MAP消息并能够为上行传输做好准备的时间。根据DOCSIS规范的规定，此延迟不得超过200微秒加上任何上游交织器延迟。实际上，根据电缆调制解调器的制造、型号和固件版本，此时间可以高达300微秒或低至100微秒。

图35 - MAP提前时间中的组件

映射提前时间可以显着影响上游传输的延迟，因为此值表示从CMTS知道电缆调制解调器要进行传输的时间到允许调制解调器进行该传输的时间之间的最小延迟。因此，请尽量缩短映射提前时间，以减少上游延迟。

请注意，在上游拥塞时，其他因素也会影响上游延迟。例如，回退和重试带宽请求算法导致的延迟，以及等待授权的排队。

图36显示了CMTS生成的MAP与上游相应数据接收之间的关系。

图36 - MAP生成与上游数据接收之间的关系

交织器深度

映射提前时间中可改变的第一因素是用于脉冲噪声保护的下游交织器。下表显示了各种交织器分路器和交织器增量设置在下行传输中增加的延迟：

注意：分路器大小越大，纠错能力越强，但诱发的延迟也越大。

I（分路器数）	J（增量）	延迟64-QAM	延迟256-QAM
8	16	220微秒	150微秒
16	8	480微秒	330微秒
32	4	980微秒	680微秒
64	2	2000微秒	1400微秒
128	1	4000微秒	2800微秒
12(EuroDOCSIS)	17(EuroDOCSIS)	430微秒	320微秒

可以使用电缆下游交织深度[8]设置交织器参数 | 16 | 32 | 64 | 128]电缆接口配置命令

注：指定了I（分路数）的值，并自动应用表中所示的J（增量）的固定对应值。此外，对于EuroDOCSIS(Annex A)模式，交织器参数固定在I = 12和J = 17。I的默认值为32,J的默认值为4。

往返时间

CMTS和电缆调制解调器之间的电往返时间是影响映射提前时间的第二个因素。CMTS与电缆调制解调器之间的物理距离以及电缆调制解调器固有的处理延迟会影响此值。

DOCSIS规范要求CMTS和系统中最远电缆调制解调器之间允许的最大单向传播时间不超过800微秒。这意味着往返时间（不包括电缆调制解调器处理延迟）约为1600微秒。

真空中的光速约为每秒186,000英里（300,000千米/秒），光纤的传播速度通常为0.67。因此，CMTS和电缆调制解调器之间允许的最大单向距离约为：

	Distance = Velocity * Time

       		 = (186,000 miles/sec * 0.67) * 800 microseconds

       		 = 100 miles or 161 kilometers.

根据DOCSIS规范，电缆调制解调器处理延迟不得超过200微秒加上任何上游交织延迟。但是，在极少数情况下，某些较旧的电缆调制解调器处理MAP消息可能需要长达300微秒。较新类型的具有更强大CPU的电缆调制解调器处理MAP消息只需100微秒。

假设电缆调制解调器平均符合DOCSIS规范。因此，最长往返时间必须是1600 + 200 = 1800微秒。

大多数电缆系统的长度都比100英里短。因此，CMTS不能总是假设CMTS和最远电缆调制解调器之间的电往返时间是最大值1800微秒。

要粗略估计最大的预期电往返时间，请将CMTS和电缆调制解调器之间的光纤距离加以乘以16微秒/英里（每千米10微秒）。然后将任意同轴电缆的距离相加，将该值乘以每英里12.4微秒（每千米7.6微秒）。然后添加200微秒的处理延迟。

例如，CMTS和最远电缆调制解调器之间光纤总长20英里且同轴度为1英里的HFC网段可能会产生以下电往返延迟：

20 miles * 16 microseconds/mile + 1 mile * 12.4 microseconds/mile + 200 microseconds
 
= 320 microseconds + 12.4 microseconds + 200 microseconds

= 532.4 microseconds

此图未考虑由于上游和下游信道特性以及调制解调器处理时间变化导致的额外延迟。因此，当计算MAP提前时间时，此值不适合使用。

确定系统中往返时间的更准确方法是观察电缆调制解调器的“定时偏移”，如show cable modem命令的输出所示。作为电缆调制解调器用于保持与CMTS通信的测距过程的一部分，CMTS计算每个电缆调制解调器的往返时间。此往返时间在show cable modem命令输出中显示为“Timing Offset”，单位为1/10.24MHz = 97.7纳秒（称为定时偏移或测距偏移单元）。要将调制解调器的定时偏移转换为微秒，请将该值乘以25/256，或将该值大致除以10。

以下示例将show cable modem命令输出中各种调制解调器的定时偏移转换为微秒值：

注意：微秒值以斜体显示。

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F       MAC         Prim RxPwr Timing  Num BPI
                                      State       Sid  (dB)  Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0   online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0   online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0   online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0   online(pt)  19   0.00  6030     0   Y  (589μs)

在这种情况下，最远的调制解调器是最后一个调制解调器，其计时偏移为6030。这相当于往返时间6030 * 25/256 = 589微秒。

静态MAP高级

在您知道HFC网络长度显着小于100英里的系统中，您可以将CMTS配置为在计算MAP提前时间时使用比标准1800微秒小的最长往返时间。

要强制CMTS在MAP提前计算中使用自定义的往返时间值，请发出cable map-advance static max-round-trip-time cable interface命令。

最长往返时间的范围是100到2000微秒。如果未为最长往返时间指定值，则应用默认值1800微秒。

注意：可以将static关键字替换为dynamic关键字。请参阅下一节。

确保指定的往返时间确实大于下行信道上电缆调制解调器往返时间的最大CMTS。如果电缆调制解调器的往返时间比最大往返时间中指定的往返时间长，则调制解调器会发现很难保持在线。这是因为此类调制解调器没有足够的时间响应MAP消息，因此无法与CMTS通信。

如果电缆调制解调器的时间偏移（转换为微秒）超过指定的最大往返时间，则调制解调器将标有错误的时间偏移标志。在show cable modem命令输出中，该偏移标志在电缆调制解调器的计时偏移旁显示为感叹号(!)。如果max-round-trip-time参数设置得太低，或者电缆调制解调器存在定时偏移不稳定且随时间不断增加的问题，则会发生这种情况。

示例如下：

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F      MAC         Prim RxPwr  Timing  Num BPI
                                     State       Sid  (dB)   Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0  online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0  online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0  online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0  online(pt)  19   0.00  !5120    0   Y  (500μs)

在本示例中，指定了cable map-advance static 500命令。但是，连接到电缆接口的电缆调制解调器的定时偏移大于500微秒（等于500 * 256/25 = 5120定时偏移单位）。

请注意，最后一个电缆调制解调器的定时偏移标记有错误的定时偏移标记“！”。此值也固定为允许的最大值5120个单位，即使真正的定时偏移可能要高得多。此电缆调制解调器可能脱机，性能不佳。

即使定时偏移低于最长往返时间，电缆调制解调器的错误定时偏移标志仍会设置。清除该标志的唯一方法是从show cable modem列表中暂时移除调制解调器。为此，可以使用clear cable modem mac-address delete命令。或者，您可以重置电缆接口或上游端口。

要观察每个上游静态映射高级算法的运行情况，请发出show controller cable interface number upstream-number命令。示例如下：

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group is overridden
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 2037
  Ranging Backoff automatic (Start 0, End 3)
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff automatic (Start 0, End 3)
  Modulation Profile Group 43
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 16
  Minislot Size in Symbols = 128
  Bandwidth Requests = 0x6ECEA
  Piggyback Requests = 0xDE79
  Invalid BW Requests= 0x63D
  Minislots Requested= 0x8DEE0E
  Minislots Granted  = 0x7CE03
  Minislot Size in Bytes = 32
  Map Advance (Static) : 3480 usecs
  UCD Count = 289392

Map Advance(Static)字段显示3480微秒的映射提前时间。如果更改下游交织器特性或最大往返时间参数，则更改将反映在静态映射提前值中。

动态预先映射

使用静态MAP提前计算来优化MAP提前时间要求CMTS操作员手动确定电缆段上最大的往返时间。如果任何下行或上行信道特性改变，或者如果任何工厂条件改变，最大往返时间可以显着改变。要不断更新配置以适应系统条件的变化可能会非常困难。

动态MAP高级算法解决了这一问题。动态MAP高级算法定期扫描show cable modem列表以搜索初始测距定时偏移最大的调制解调器，然后自动使用该值计算MAP高级时间。因此，CMTS始终使用尽可能最短的映射提前时间。

电缆调制解调器的初始测距定时偏移是调制解调器在调制解调器上线时报告的定时偏移。在大多数情况下，这接近show cable modem命令输出中显示的正在进行的定时偏移。但是，某些类型的电缆调制解调器存在以下问题：定时偏移会随着时间推移而上升到非常大的值。这会使映射提前时间计算出现偏差。因此，仅使用初始测距定时偏移（仅在调制解调器联机时更新）。要查看电缆调制解调器的初始测距定时偏移和持续定时偏移，请发出show cable modem verbose命令。示例如下：

uBR7200VXR# show cable modem 00aa.bbf3.7858 verbose
MAC Address                         : 00aa.bbf3.7858
IP Address                          : 4.24.64.18
Prim Sid                            : 48
Interface                           : C5/1/U0
Upstream Power                      : 39.06 dBmV (SNR = 36.12 dB)
Downstream Power                    : 14.01 dBmV (SNR = 35.04 dB)
Timing Offset                       : 2566
Initial Timing Offset               : 2560
Received Power                      :  0.00 dBmV
MAC Version                         : DOC1.1
QoS Provisioned Mode                : DOC1.1
Enable DOCSIS2.0 Mode               : Y
Phy Operating Mode                  : tdma
Capabilities                        : {Frag=Y, Concat=Y, PHS=Y, Priv=BPI+}
Sid/Said Limit                      : {Max US Sids=16, Max DS Saids=15}
Optional Filtering Support          : {802.1P=N, 802.1Q=N}
Transmit Equalizer Support          : {Taps/Symbol= 1, Num of Taps= 8}
Number of CPE IPs                   : 0(Max CPE IPs = 16)
CFG Max-CPE                         : 32
Flaps                               : 4(Mar 13 21:13:50)
Errors                              : 0 CRCs, 0 HCSes
Stn Mtn Failures                    : 0 aborts, 1 exhausted
Total US Flows                      : 1(1 active)
Total DS Flows                      : 1(1 active)
Total US Data                       : 321 packets, 40199 bytes
Total US Throughput                 : 129 bits/sec, 0 packets/sec
Total DS Data                       : 28 packets, 2516 bytes
Total DS Throughput                 : 0 bits/sec, 0 packets/sec
Active Classifiers                  : 0 (Max = NO LIMIT)
DSA/DSX messages                    : permit all
Total Time Online                   : 1h00m

在本例中，持续时间偏移(2566)略高于初始测距定时偏移(2560)。这些值可能稍有不同。但是，如果值相差数百个以上，则电缆调制解调器的定时偏移控制可能存在问题。

要激活动态映射预先计算，请发出cable map-advance dynamic safety-factor max-round-trip-time cable interface命令。

安全系数参数范围为100至2000微秒。该参数被添加到MAP提前时间，以便提供小的保护，以便考虑信号传播中任何额外的意外延迟。默认值为1000微秒。但是，对于电缆设备或上游或下游信道特性没有发生显着变化的稳定电缆系统，请使用较低的值，例如500微秒。

最大往返时间参数范围为100至2000微秒。此参数用作连接到电缆段的电缆调制解调器的时间偏移的上限。默认值为1800微秒。如果电缆调制解调器（转换为微秒）的时间偏移超过指定的最大往返时间，则显示该时间偏移标记有错误的时间偏移标记。

当您知道电缆系统的长度显着小于100英里，并且知道连接到网段的电缆调制解调器的最大正常时间偏移值时，将max-round-trip time参数设置为非默认值。

使用show controller cable interface-number upstream-number命令，观察动态映射高级算法在每个上游的运行情况。示例如下：

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

Tx Timing Offset值以定时偏移单元显示连接到上游的所有电缆调制解调器的最大定时偏移。使用此值计算MAP提前时间。Map Advance(Dynamic)字段显示生成的映射提前时间。如果Tx定时偏移改变，如果安全值被修改，或者如果下游交织器特性改变，该值可以改变。

动态MAP高级算法取决于电缆调制解调器是否正确报告其到CMTS的初始测距定时偏移。遗憾的是，电缆调制解调器的一些制造商和型号报告初始测距定时偏移值明显低于真实值。当调制解调器显示接近零甚至负值的定时偏移时，可以观察到这一点。

与%UBR7200-4-BADTXOFFSET类似的错误消息：检测到电缆调制解调器00ff.0bad.caf3的定时偏移–2错误。caf3可能出现在此类电缆调制解调器上。这些类型的电缆调制解调器不以符合DOCSIS的方式报告其定时偏移，动态映射高级算法无法正确计算保证为每个电缆调制解调器提供接收和响应MAP消息的时间的映射提前时间。

如果电缆网段上存在此类电缆调制解调器，请禁用动态MAP高级算法并恢复为静态MAP高级算法。请参阅为什么某些电缆调制解调器显示负时间偏移？。

思科uBR CMTS的上游调度程序模式配置

下载选项

非歧视性语言

关于此翻译

目录

修订历史记录

此文档是否有帮助?

联系我们

本文档适用于以下产品