適用於Cisco uBR CMTS的上游排程器模式組態

下載選項

PDF (817.7 KB)
在多種裝置上使用 Adobe Reader 檢視
ePub (570.9 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語音或影片）的高速有線電纜資料網路的設計和維護人員。

必要條件

需求

思科建議您瞭解以下主題：

有線電纜資料服務介面規範(DOCSIS)系統
Cisco uBR系列CMTS

採用元件

本文中的資訊係根據以下軟體和硬體版本：

Cisco uBR CMTS
Cisco IOS®軟體版本系列12.3(13a)BC和12.3(17a)BC

注意：有關Cisco IOS軟體更高版本中的更改的資訊，請參閱Cisco.com網站上提供的相應版本說明。

背景資訊

在有線電纜資料服務介面規範(DOCSIS)網路中，CMTS控制有線數據機進行的所有上游傳輸的時間和速率。在現代DOCSIS網路上游同時運行多種具有不同延遲、抖動和吞吐量要求的服務。因此，您必須瞭解CMTS如何決定纜線資料機何時可以代表這些不同型別的服務進行上游傳輸。

本白皮書包括：

DOCSIS中的上游排程模式概述，包括盡力而為、主動授權服務(UGS)和即時輪詢服務(RTPS)
適用於Cisco uBR CMTS的DOCSIS相容排程程式的操作和配置
Cisco uBR CMTS的新低延遲隊列排程程式的操作和配置

DOCSIS中的上游排程

符合DOCSIS的CMTS可以通過服務流的概念為不同的分組流或應用提供不同的上游排程模式。服務流表示服務流ID(SFID)唯一標識的上游或下游資料流。每個服務流都可以有自己的服務品質(QoS)引數，例如最大吞吐量、最小保證吞吐量和優先順序。對於上游服務流，您還可以指定排程模式。

每個纜線資料機可以有多個上游服務流程，以適應不同型別的應用。例如，Web和電子郵件可以使用一個服務流，IP語音(VoIP)可以使用另一個服務流，網際網路遊戲可以使用另一個服務流。為了能夠為這些應用程式中的每一個應用程式提供適當的服務型別，這些服務流的特性必須不同。

使用分類器，纜線資料機和CMTS能夠將正確的流量型別導向適當的服務流。分類器是特殊的過濾器（如訪問清單），它匹配資料包屬性（如UDP和TCP埠號），以確定資料包通過的相應服務流。

在圖1中，電纜數據機有三個上行服務流。第一個服務流保留用於語音流量。此服務流的最大吞吐量較低，但也配置為提供低延遲保證。下一個服務流用於常規的Web和電子郵件流量。此服務流具有高吞吐量。最終服務流將保留給對等(P2P)流量。此服務流具有更嚴格的最大吞吐量，以限制此應用程式的速度。

圖1 — 帶有三個上行服務流的電纜數據機

當電纜數據機首次聯機時，建立並啟用服務流。在用於配置電纜數據機的DOCSIS配置檔案中調配服務流的詳細資訊。在DOCSIS配置檔案中為上游流量調配至少一個服務流，並為下游流量調配另一個服務流。在DOCSIS配置檔案中指定的第一個上游和下游服務流稱為主服務流。

在電纜數據機聯機後，也可以動態建立和啟用服務流。此案例通常適用於服務流，服務流與屬於VoIP電話呼叫的資料相對應。當電話會話開始時，會建立並啟用此類服務流。然後，服務流在呼叫結束時被停用和刪除。如果服務流僅在必要時存在，則可以節省上行頻寬資源以及系統CPU負載和記憶體。

纜線資料機無法隨時進行上游傳輸。相反，數據機必須等待CMTS的指令才能傳送資料，因為一次只能有一個電纜數據機在上游通道上傳輸資料。否則，傳輸可能會相互溢位和損壞。有關何時電纜數據機可以傳輸的說明，以頻寬分配MAP消息的形式來自CMTS。Cisco CMTS每2毫秒傳送一則MAP訊息，告知纜線資料機何時可進行任何型別的傳輸。每個MAP消息都包含指示數據機何時進行傳輸、傳輸可以持續多久以及可以傳輸的資料型別的資訊。因此，纜線資料機資料傳輸不會彼此衝突，並且可避免資料損毀。本節討論CMTS可以決定何時授予電纜數據機在上游進行傳輸的許可權。

盡最大努力

盡力排程適用於對延遲或抖動沒有嚴格要求的經典網際網路應用。這些型別的應用程式套件括電子郵件、Web瀏覽或點對點檔案傳輸。盡力而為排程不適用於需要保證延遲或抖動的應用程式，例如IP語音或影片。這是因為在擁塞的情況下，無法以盡力模式做出此類保證。DOCSIS 1.0系統僅允許此類排程。

盡力服務流通常在與電纜數據機關聯的DOCSIS配置檔案中調配。因此，盡最大努力服務流通常在電纜數據機聯機後立即處於活動狀態。主要上游服務流，即要在DOCSIS配置檔案中調配的第一個上游服務流，必須是盡力而為型別的服務流。

以下是在DOCSIS 1.1/2.0模式下定義盡力服務流的最常用引數：

最大持續流量速率(R)

Maximum Sustained Traffic Rate是流量在此服務流中運行的最大速率。此值以位/秒表示。
最大流量突發(B)

最大流量突發是指適用於實施上行吞吐量限制的令牌桶速率限制器的突發大小（以位元組為單位）。如果未指定值，則應用預設值3044，即兩個完整乙太網幀的大小。對於最大持續大流量速率，請將此值設定為至少最大持續流量速率除以64。
流量優先順序

此引數是指服務流中從0（最低）到7（最高）的流量的優先順序。在上游，高優先順序服務流的所有待定業務被排程為在低優先順序服務流的業務之前傳輸。
最低保留費率

此參數列示服務流的最小保證吞吐量（以位/秒為單位），類似於承諾資訊速率(CIR)。通道上所有服務流的組合最低保留速率不得超出該通道上的可用頻寬。否則，就無法保證承諾的最低保留利率。
最大串聯突發量

Maximum Concatenated 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和(2³ - 1)=(8 - 1)= 7之間的隨機數。

然後，電纜數據機必須等待選定隨機數的頻寬請求傳輸機會通過，然後數據機才會傳輸頻寬請求。因此，儘管由於這種強制延遲，數據機無法在下一個可用機會傳送頻寬請求，但是與另一個數據機的傳輸發生衝突的可能性降低了。

當然，資料回退起始值越高，頻寬請求之間發生衝突的可能性就越低。更大的資料回退起始值也意味著數據機可能需要等待更長時間才能傳輸頻寬請求，因此上行延遲會增加。

CMTS在下一傳輸頻寬分配MAP消息中包括確認。此確認資訊通知電纜數據機已成功收到頻寬請求。此確認可以：

或者準確地指示數據機何時可以傳輸

或
僅指示已收到頻寬請求，並且將在未來的MAP消息中決定傳輸時間。

如果CMTS在下一條MAP消息中不包括頻寬請求的確認，數據機可以斷定沒有收到頻寬請求。如果請求被批准，則由於衝突、上行雜訊或服務流超過規定的最大吞吐量速率而導致出現這種情況。

無論哪種情況，電纜數據機的下一步都是回退，然後嘗試再次傳輸頻寬請求。數據機增加了選擇隨機值的範圍。為此，數據機向資料回退起始值新增一個。例如，如果資料回退起始值為3，而CMTS無法接收一個頻寬請求傳輸，則在重新傳輸之前，數據機將等待一個介於0和15個頻寬請求機會之間的隨機值。計算如下：23+1 - 1 = 24 - 1 = 16 - 1 = 15

值範圍越大，發生另一衝突的機會就越小。如果數據機進一步丟失頻寬請求，數據機會繼續增加每次重新傳輸時用作兩倍功率的值，直到該值等於資料回退結束。2的功率不能增長到大於資料回退結束值。

數據機重新傳輸頻寬請求最多16次，之後數據機丟棄頻寬請求。這種情況僅在極度擁塞的情況下發生。

您可以使用以下纜線介面指令在Cisco uBR CMTS上設定每條纜線上游的資料回退開始值和資料回退結束值：

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

思科建議您保留資料回退啟動和資料回退結束引數的預設值，分別為3和5。盡力排程系統的爭用特性意味著對於盡力服務流，無法提供確定性或保證的上游延遲或抖動水準。此外，擁塞的情況可能使得無法保證盡力服務流的特定吞吐量級別。但是，您可以使用優先順序和最小保留速率等服務流屬性。利用這些屬性，服務流可以在擁塞的條件下達到所需的吞吐量級別。

回退和重試演算法示例

此範例包括連線到同一上游通道的四個纜線資料機，分別為A、B、C和D。在稱為t0_的同一時刻，數據機A、B和C決定在上游傳輸一些資料。

這裡，資料回退開始設定為2，資料回退結束設定為4。數據機首次嘗試傳輸頻寬請求之前從中挑選間隔的間隔範圍在0到3之間。計算如下：

(22 - 1)=(4 - 1)= 3個間隔。

以下是三個數據機從時間t0開始選擇等待的頻寬請求_機會數。

資料機A:3
資料機B:2
資料機C:3

請注意數據機A和數據機C選擇的等待機會數量相同。

資料機B等待t0之後出現的兩個頻寬請求_機會。然後資料機B傳輸CMTS接收的頻寬請求。數據機A和數據機C都等待3個頻寬請求機會在t₀之後通過。然後數據機A和C同時傳輸頻寬請求。這兩個頻寬請求發生衝突並損壞。因此，兩個請求都無法成功到達CMTS。圖2顯示了此事件序列。

圖2 — 頻寬請求示例第1部分

圖表頂部的灰色條表示時間t0之後電纜數據機可用的一系列頻寬請求機會。彩色箭頭表示電纜數據機傳輸的頻寬請求。灰色條中的彩色框表示成功到達CMTS的頻寬請求。

從CMTS廣播的下一個MAP消息包含數據機B的授權，但沒有數據機A和C的說明。這指示數據機A和C需要重新傳輸其頻寬請求。

在第二次嘗試時，數據機A和數據機C在計算要選擇的間隔範圍時需要增加兩個的功率。現在，數據機A和數據機C會選擇0到7之間的隨機間隔數。計算如下：

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

假設數據機A和數據機C意識到需要重新傳輸的時間是t₁。還假設另一個數據機稱為數據機D決定在同一時刻傳輸一些上游資料，即t₁。數據機D將首次進行頻寬請求傳輸。因此，資料機D使用原始值作為資料回退開始和資料回退結束，即0到3 [(22 - 1)=(4 - 1)= 3間隔]。

三個數據機選擇這些隨機數量的頻寬請求機會，從時間t_1等待。

資料機A:5
資料機C:2
資料機D:2

數據機C和D都等待時間t1之後出現的兩個頻寬請求機會。然後數據機C和D同時傳輸頻寬請求。這些頻寬要求會衝突，因此不會到達CMTS。資料機A允許通過五個頻寬請求機會。然後，資料機A傳輸CMTS接收的頻寬請求。圖3顯示了數據機C和D的傳輸與成功收到數據機A的傳輸之間的衝突。此圖的開始時間基準為_t1。

圖3 — 頻寬請求示例第2部分

從CMTS廣播的下一個MAP消息包含數據機A的授權，但沒有數據機C和D的說明。數據機C和D認識到需要重新傳輸頻寬請求。數據機D現在將要第二次傳輸頻寬請求。因此，數據機D使用data backoff start + 1作為2的冪，以計算要等待的間隔範圍。資料機D選擇0到7之間的間隔。計算如下：

(22+1 - 1)=(23 - 1)=(8 - 1)= 7個間隔。

數據機C將要第三次傳輸頻寬請求。因此，數據機C在計算要等待的間隔範圍時使用data backoff start + 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)部分。

傳送頻寬請求

當上游盡力服務流以高速率傳輸幀時，可以將頻寬請求搭載到上游資料幀上，而不是單獨傳輸頻寬請求。下一個頻寬請求的細節被簡單地新增到在上游傳輸到CMTS的資料包的報頭中。

這表示頻寬要求沒有受到爭用，因此要求到達CMTS的機率要高得多。傳送頻寬請求的概念減少了乙太網幀到達終端使用者的客戶端裝置(CPE)所需的時間，因為幀進入上行傳輸的時間減少了。這是因為數據機不需要經過回退和重試頻寬請求傳輸過程，這可能會出現延遲。

在此案例中，通常會發生搭載頻寬請求的情況：

當電纜數據機等待在上游傳輸一個幀（例如X）時，數據機從CPE接收另一個幀（例如Y）以便在上游傳輸。纜線資料機無法將新訊框Y上的位元組新增到傳輸中，因為這會佔用比資料機獲批的上游時間更多的時間。相反，數據機會填充幀X的DOCSIS報頭中的一個欄位，以指示幀Y所需的傳輸時間量。

CMTS代表Y接收幀X以及頻寬請求的詳細資訊。CMTS根據可用性為Y向數據機授予進一步的傳輸時間。

在非常保守的術語中，在傳輸頻寬請求與接收頻寬分配以及分配資料傳輸時間的MAP確認之間只需要5毫秒。這意味著要發生回送，纜線資料機需要從CPE接收彼此相距不超過5毫秒的訊框。

這一點值得注意，因為，典型的VoIP編解碼器（如G.711）通常使用10或20ms的幀間時段。通過盡力而為服務流運行的典型VoIP流無法利用搭載。

串聯

當上游盡力服務流以高速率傳輸幀時，纜線數據機可以將幾個幀連線在一起，並請求允許一次傳輸所有幀。這稱為串聯。纜線資料機僅需代表一組串連訊框中的所有訊框傳輸一個頻寬要求，即可提高效率。

串連通常發生在類似於傳送的情況，不同之處在於，當數據機決定傳輸頻寬請求時，串連需要在電纜數據機內部排隊多個幀。這意味著串連往往會以比傳送更高的平均幀速率發生。此外，這兩種機制通常協同工作，以提高盡力傳輸流量的效率。

您可以為服務流配置的「最大級聯突發量」欄位會限制服務流可以傳輸的級聯幀的最大大小。您還可以使用cable default-phy-burst命令來限制級聯幀的大小以及上行通道調制配置檔案中的最大突發大小。

預設情況下，在Cisco uBR系列CMTS的上游埠上啟用串聯。但是，您可以使用[no] cable upstream-port-id concatenation [docsis10]cable interface命令，基於每個上游埠控制串聯。

如果設定docsis10引數，則該命令僅適用於在DOCSIS 1.0模式下運作的電纜資料機。

如果對此命令進行更改，纜線資料機必須在CMTS上重新註冊，才能使更改生效。必須重置受影響上游上的數據機。電纜數據機在聯機過程中執行註冊時瞭解是否允許串聯。

分段

在上游傳輸大幀需要很長時間。此傳輸時間稱為序列化延遲。尤其是大型上游幀需要很長時間才能傳輸，因此它們可以有害地延遲屬於時間敏感型服務（例如VoIP）的資料包。對於大串接幀尤其如此。因此，在DOCSIS 1.1中引入了分段，以便可以將大幀拆分成較小的幀在單獨的突發中進行傳輸，每個突發傳輸的時間都更短。

分段允許在大型幀的片段之間交錯對時間敏感的小型幀，而不是必須等待整個大型幀的傳輸。由於每個片段需要附加額外的一組DOCSIS標頭，因此將幀作為多個片段進行傳輸比在一個突發中傳輸幀的效率略低。但是，分段增加上游通道的靈活性使額外開銷變得合理。

在DOCSIS 1.0模式下工作的纜線資料機無法執行分段。

預設情況下，在Cisco 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埠的電纜數據機在檢測到VoIP電話呼叫正在進行時，通常可以要求CMTS建立適當的UGS服務流。

思科建議您不要在DOCSIS配置檔案中配置UGS服務流，因為無論是否有任何服務使用它，只要電纜數據機處於聯機狀態，此配置就會保持UGS服務流的活動狀態。此配置會浪費上行頻寬，因為UGS服務流經常代表電纜數據機保留上行傳輸時間。最好動態建立和刪除UGS服務流，以便在需要時啟用UGS。

以下是定義UGS服務流的最常用引數：

Unsolicited Grant Size(G) — 每個定期授予的大小（位元組）。
Nominal Grant Interval(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 — 單播頻寬請求機會之間的時間間隔（以微秒為單位）。
容許的輪詢抖動(Acceived 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抖動緩衝區能夠補償超過150ms的抖動。但是，VoIP網路會增加資料包延遲的緩衝量。高延遲會導致VoIP體驗變差。

每個上游的UGS服務流容量

物理層屬性（如通道寬度、調制方案和糾錯強度）決定上游的物理容量。但是，上游可以支援的同步UGS服務流的數量也取決於排程演算法。

如果不需要極低的抖動水準，則可以放寬排程程式的剛性並滿足上游可以同時支援的較多的UGS服務流。如果您放寬抖動要求，則可以在上游實現更高的非語音流量效率。

注意：不同的排程演算法可允許特定的上行通道支援不同數量的UGS和RTPS服務流。但是，此類服務不能利用DOCSIS系統中100%的上游容量。這是因為上游通道必須專門為DOCSIS管理流量分配一部分，例如纜線資料機用於與CMTS進行初始接觸的初始維護消息，以及用於確保纜線資料機可以保持與CMTS連線的站台維護保持連線流量。

符合DOCSIS的排程器

符合DOCSIS的排程器是在Cisco 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-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%，則必須傳送主要警報。發出以下命令：

電纜准入控制us-bandwidth scheduling-type UGS次要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優先順序，0為最低優先順序，7為最高優先順序。每個優先順序都有一個關聯的隊列。

DOCSIS相容排程程式使用嚴格的優先順序排隊機制來確定何時分配了不同優先順序的授權。換句話說，必須提供高優先順序隊列中儲存的所有授權，然後才提供低優先順序隊列中的授權。

例如，假設符合DOCSIS標準的排程程式在短時間內收到五個授權，順序為A、B、C、D、E和F。排程程式將每個授權排隊到隊列中，隊列與授權的服務流的優先順序相對應。

圖12 — 具有不同優先順序的贈款

DOCSIS相容排程程式圍繞預排程的UGS授權(在圖12中顯示為模式塊)排程盡力授權。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授權中不會引發抖動。在具有大量UGS流量的上游網段上以DOCSIS 1.0模式運行的電纜數據機可能出現問題，因為DOCSIS 1.0電纜數據機可能會要求傳輸一個過大而無法容納下一個可用傳輸機會的幀。

下面是另一個示例，該示例假定排程程式按該順序接收新授權A和B。還假設兩個授權具有相同的優先順序，但授權B用於在DOCSIS 1.0模式下運行的電纜數據機。

圖17 - DOCSIS 1.1和DOCSIS 1.0等待許可

排程程式首先嘗試為授予A分配時間。然後，排程程式嘗試分配下一個可用的傳輸機會以授予B。但是，授予B沒有在A和下一組UGS授予之間保持未分段的空間(請參見圖18)。

圖18 - DOCSIS 1.0授權B延遲

因此，贈款B被推遲至第二批有空間可供贈款B適用的UGS贈款之後。請注意，在第2個UGS授予塊之前，現在有未使用的空間。纜線資料機使用此時間將頻寬要求傳輸到CMTS，但頻寬使用效率很低。

重新檢視此示例，並向排程程式新增額外兩個UGS服務流。雖然授權A可以分段，但無法計畫不可分段的授權B，因為授權B太大，無法在UGS授權塊之間調整。這種情況使與授權B關聯的電纜數據機無法在上游傳輸大型幀。

圖19 — 無法計畫DOCSIS 1.0授權B

您可以允許排程程式直接推出UGS授予塊，或稍微延遲該塊，以便為授予B騰出空間，但此操作會導致UGS服務流中的抖動。目前，如果您想將抖動降至最低，則這種解決方案是不可接受的。

為了通過大型不可分段的DOCSIS 1.0授權解決此問題，DOCSIS相容排程程式定期預排程與DOCSIS 1.0電纜數據機可傳輸的最大幀一樣大的上游時間塊。排程程式在排程任何UGS服務流之前執行此操作。此時間通常相當於約2000位元組的上游傳輸，稱為「不可分段塊」或「UGS空閒塊」。

與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顯示，如果減少電纜預設phy-burst設定，則UGS空閒塊的大小會減小，因此DOCSIS相容排程程式可以在上游允許更多UGS呼叫。在此示例中，將電纜預設phy-burst從預設設定2000降低到更低的設定1600，以允許一個或多個UGS服務流變為活動狀態的空間。

圖22 — 降低的預設phy突發可減小未分段塊大小

使用cable default-phy-burst命令減小最大允許突發大小，可能會輕微降低上游對盡力流量產生的效率，因為此命令會減少一個突發中可串聯的幀數。當上游具有更多的UGS服務流活動時，這種減少還可導致增加的碎片級別。

減少串聯突發大小可能會影響盡力服務流中資料上傳的速度。這是因為一次傳輸多個幀比傳輸每個幀的頻寬請求要快。由於纜線資料機串接大量在上游方向傳輸的TCP ACK封包的效能降低，因此降低的串連層級還可能潛在影響下載速度。

有時，在應用於上游的電纜調制配置檔案的「長」IUC中配置的最大突發量可以確定最大的上游突發量。如果調制配置檔案中的最大突發大小（以位元組為單位）小於電纜預設phy-burst的值，則會發生這種情況。這種情況非常罕見。但是，如果您將電纜的default-phy-burst引數從預設的2000位元組增加，請檢查「long」IUC配置中的最大突發大小，以確保它不限制突發。

上行突發量的另一個限制是，在一個突發中最多可以傳輸255個微小區。如果最小批次大小設定為8個位元組的最小值，則此值可能會成為因子。最小單位是DOCSIS網路中上行傳輸的最小單位，通常相當於8或16位元組。

無法分段插槽抖動

調整符合DOCSIS的排程程式以允許上游上更多同時的UGS流的另一種方法是，允許排程程式允許不可分段盡力流量的大突發向UGS服務流引入少量的抖動。您可以使用cable upstream 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相容排程程式能夠以類似於減少預設phy突發的方式增加上游支援的UGS授權的數量。

注意：返回以下示例：使用大型DOCSIS 1.1授權A和大型不可分段DOCSIS 1.0授權B在上游進行計畫。將不可分段插槽抖動設定為1000微秒。符合DOCSIS的排程器的行為如本節中的圖所示。

註：首先，排程程式為授權A分配傳輸時間。為此，排程程式將授權分段為授權A₁和A₂，以使授權適合第一塊UGS授權之前和之後。為了排程授權B，排程程式必須確定在授權A₂後，排程程式是否可以將不可分段塊放入可用空間，而不對下一塊UGS授權進行超過已配置的不可分段時隙抖動1000微秒的延遲。這些圖顯示，如果排程程式將授權B放在授權A₂旁邊，則下一塊UGS流量將延遲或後推1500微秒以上。因此，排程程式無法直接將授權B放在授權A2_之後。

圖24 — 無法在授權A2旁邊計畫授權B。

符合DOCSIS的排程程式的下一步是檢視下一個可用間隙是否可以容納授權B。圖25顯示，如果排程程式將授權B放在第二個UGS授予塊之後，則第三個塊的延遲不會超過配置的可碎片化插槽抖動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上游排程概念。

適用於Cable3/0/U0的DOCSIS 1.1 MAC排程程式

命令輸出的第一行表示資料所屬的上游埠。
Queue[Rng輪詢] 0/128,0個丟棄，最多1

此行顯示將站台維護keepalive或測距機會饋送到符合DOCSIS的排程程式的隊列的狀態。0/128表示隊列中最多128個待定測距機會中當前為零。

Drops計數器表示由於此隊列已滿（即128個掛起的測距機會），測距機會無法排隊的次數。只有在上行鏈路上有大量電纜數據機線上，並且有大量UGS或RTPS服務流處於活動狀態時，才會發生此處的丟棄。運行DOCSIS投訴排程程式時，此隊列以最高優先順序提供服務。因此，此隊列中的丟棄可能性很小，但很可能表示上游通道的嚴重超訂用。

max計數器表示自上次運行show interface cable mac-scheduler命令以來此隊列中存在的最大元素數。理想情況下，這應儘可能保持接近於零。
隊列[CIR授權] 0/64,0個丟棄，最大0

此行顯示隊列狀態，該隊列管理指定最低保留流量速率的服務流的授權。換句話說，此隊列服務授權承諾資訊速率(CIR)服務流。0/64表示隊列中目前最多64個待批中為零。

Drops計數器表示由於此隊列已滿（即，隊列中有64個授權），CIR授權無法排隊的次數。如果UGS、RTPS和CIR型別的服務流超額訂閱上游，則在此可累積丟包，並表明需要更嚴格的准入控制。

max計數器表示自上次運行show interface cable mac-scheduler命令以來此隊列中的最大授權數。此隊列具有第二高優先順序，因此DOCSIS相容排程程式先為此隊列中的元素分配時間，再為盡力隊列提供服務。
Queue[BE(w)Grants] x/64, y drops，max z

接下來的八個條目顯示了管理優先順序7至0服務流的授權的隊列的狀態。這些條目中的欄位與CIR隊列條目中的欄位具有相同的含義。此組中第一個要服務的隊列是BE(7)隊列，最後一個要服務的隊列是BE(0)隊列。

如果較高優先順序的流量佔用所有上游頻寬，或者發生上游超訂用UGS、RTPS和CIR型別的服務流，則在這些隊列中可能會發生丟棄。這可以表明需要重新評估大流量服務流的DOCSIS優先順序或者需要更嚴格的上游准入控制。
請求插槽36356057

此行表示自上游啟用後已通告的頻寬請求機會數。此數字必須持續增加。
請求/資料插槽數185165

雖然名稱表明該欄位顯示在上游通告的請求數量或資料業務機會數量，但是該欄位實際上顯示CMTS通告的期間數量，以便於高級頻譜管理功能。此計數器預期會增加MC28U和MC520樣式線卡上的上行流。

請求/資料機會與頻寬請求機會相同，不同之處在於，在這些時段內，纜線資料機還能夠傳輸小的資料猝發。Cisco uBR系列CMTS當前未安排實際請求/資料機會。
Init Mtn Slots 514263

此行表示自上游啟用後已通告的初始維護業務機會數。這一數字必須持續上升。初次嘗試建立到CMTS連線的纜線資料機使用初次維護機會。
Stn Mtn插槽數314793

此行表示上游提供的站點維護保持連線或測距機會的數量。如果上游有線上纜線資料機，則此數字必須持續上升。
短期授權插槽12256，長期授權插槽4691

此行表示上游提供的資料授權數。如果有電纜數據機傳輸上行資料，這些數字必須持續上升。
ATDMA短期授予插槽0、ATDMA長期授予插槽0、ATDMA UGS授予插槽0

此行表示上游在高級分時多重進接(ATDMA)模式下提供的資料授權數。如果有纜線資料機在DOCSIS 2.0模式下運作，且它們會傳輸上游資料，則這些數字必須持續上升。請注意，ATDMA單獨考慮UGS流量。
Awacs插槽277629

此行顯示專用於高級頻譜管理的週期數。為了進行高級頻譜管理，CMTS需要定期安排時間，其中每個電纜數據機必須進行短暫的傳輸，以便內部頻譜分析功能可以評估每個數據機的訊號品質。
分段計數41

此行顯示上游埠計畫接收的片段總數。例如，如果幀被分段為三個部分，將導致此計數器增加3。
已禁用分段測試

此行表示尚未呼叫test cable fragmentation命令。不要在生產網路中使用此命令。
平均上行通道利用率：26%

此行顯示按上行資料傳輸的當前上行通道利用率。這包括通過短、長、ATDMA短、ATDMA長和ATDMA UGS授權進行的傳輸。該值每秒作為滾動平均值計算。思科建議此值在使用高峰期不超過75%。否則，終端使用者會開始注意到盡力傳輸流量存在效能問題。
平均爭用插槽百分比：73%

此行顯示專用於頻寬請求的上游時間百分比。這等於上游空閒時間量，因此隨著Avg上游通道利用率百分比的增加減少。
初始測距插槽的平均百分比：2%

此行表示有線數據機在嘗試與CMTS建立初始連線時用於初始測距機會的上游時間百分比。此值必須始終保持總利用率的低百分比。
延遲MAP上平均丟失的微型零件百分比：0%

此行表示由於CMTS無法及時向電纜數據機傳輸頻寬分配MAP消息而未排程的上游時間百分比。此引數必須始終接近於零，但在具有極高CPU負載的系統上可以開始顯示較大的值。
Sched表Rsv-state:授權0，請求0

此行顯示已在DOCSIS相容排程程式中預先分配給它們但尚未啟用的UGS樣式服務流（授權）或RTPS樣式服務流（請求輪詢）的數量。當通過負載平衡將具有現有UGS或RTPS服務的電纜數據機從上游移動到另一上游時，會發生這種情況。請注意，此圖僅適用於使用符合DOCSIS的排程程式（而不是LLQ排程程式）的授權。
計畫表管理狀態：授權6，請求0，直到獲得27%

此行表示已在此上游的DOCSIS相容排程程式中預先為其分配了授權的UGS樣式服務流（授權）或RTPS樣式服務流（請求輪詢）的數量。Util是這些服務流對總可用上行頻寬的估計利用率。請注意，此圖僅適用於使用符合DOCSIS的排程程式（而不是LLQ排程程式）的授權。
<scheduling-type> :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抖動和盡力流量效率。為此，您必須將纜線的default-phy-burst引數降低到建議的最小設定1540位元組。如果您需要更多的呼叫密度，請將電纜上游unfrag-slot-jitter設定為諸如2000微秒的值。但是，思科通常不建議生產網路採用這些設定。

符合DOCSIS的排程程式的另一個優點是，沒有強制要求CMTS操作員明確配置UGS和RTPS樣式服務流的准入控制。這是因為預分配排程方法消除了意外超訂用的可能性。即使如此，思科仍建議運營商確保在高峰時間延長的上游總利用率不超過75%。因此，思科建議將准入控制配置為最佳實踐。

DOCSIS相容排程程式的一個缺點是，當UGS利用率高時，UGS授予的固定位置可能需要將盡力而為授予分段。一般來說，分段不會導致明顯的效能問題，但確實會導致盡力而為流量的延遲略有增加，並且上行通道上存在的協定開銷增加。

另一個缺點是，當DOCSIS 1.0纜線資料機想要進行大的無法分段的上游傳輸時，在預排的UGS授權區塊之間出現適當的間隙之前，可能會有延遲。這也可能導致DOCSIS 1.0上游流量的延遲增加，以及可用上游傳輸時間使用效果不佳。

最後，DOCSIS相容排程程式設計為在所有UGS服務流共用相同的授予大小和授予間隔的環境中發揮最佳作用。也就是說，所有VoIP呼叫共用相同的編解碼器，如典型基於Packetcable 1.0的系統中10ms或20ms分組化G.711。當存在不同的授權間隔和大小時，DOCSIS相容排程程式在上游支援大量UGS服務流的能力會降低。此外，對於某些授權，當排程程式嘗試交錯具有不同週期和大小的UGS服務流時，可能會發生非常小的抖動（小於2ms）。

隨著PacketCable MultiMedia(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調度型別[nrtp | 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-1至UGS-3的UGS服務流的計時器。黃色箭頭沿順時針方向移動。當黃色箭頭指向紅點時，UGS授予會新增到LLQ隊列。您還可以看到熟悉的8個優先順序隊列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 - Grant 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命令輸出部分。

以下是show指令輸出中粗體行的說明：

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

此行顯示LLQ隊列的狀態，該隊列管理有線上行排程型別[nrtps]中指定的服務流型別的授權 | rtps | ugs] mode llq命令。0/64表示隊列中目前最多64個待批中為零。

Drops計數器表示由於此隊列已滿（即，64個授予在隊列中），排程程式無法對UGS授予或RTPS輪詢進行隊列的次數。如果此隊列中出現丟棄，最可能的解釋是上游超額訂閱了UGS或RTPS服務流，您必須應用更嚴格的准入控制。

max計數器表示自上次運行show interface cable mac-scheduler命令以來此隊列中的最大授權數。如果存在，則此隊列在所有列出的隊列中具有最高的優先順序。
r4k計數，1毫秒600000

此欄位表示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，「高級PHY UGS」為11。對於RTPS樣式服務流，「Request」始終為1。
size_ms:17 size_byte:232

以最小單位表示的授權大小，後跟以位元組表示的授權大小。最小單位是DOCSIS網路中上行傳輸的最小單位，通常相當於8或16位元組。
Frag:否

指示授權是否可分段。目前，此值始終設定為N。
Inval:20

授權或輪詢間隔（毫秒）。
型別8

8表示此服務流為UGS，10表示RTPS，11表示NRTPS。
完美時間參考188

必須計畫此贈與的理想時間。這通常與頂部的「Entry」相同。如果沒有，則表明上游存在嚴重擁塞，需要更嚴格的准入控制。
從ref 0傾斜

計畫此授予的時間與計畫授予的時間之差。這是「輸入」和「完美時間參考」之間的區別。因此，此值通常必須為零。
優先順序10

在當前版本的Cisco IOS軟體中，此值始終設定為10，但將來可能會有所不同。
位置188，倉13

這些欄位必須與此清單頂部的「Entry， Bin」相同。

LLQ排程程式的優缺點

LLQ排程程式的目標是增加上游通道的UGS和RTPS容量，並提高盡力而為流量的效率。為實現這些目標，LLQ排程程式所付出的代價是，此排程程式不會明確保證UGS和RTPS服務流抖動。相反，LLQ排程程式將UGS授權和RTPS輪詢排程到儘可能接近理想的時間以最小化抖動。

與DOCSIS相容排程程式相比，LLQ排程程式還能更好地處理具有不同授權間隔和授權大小的多個UGS服務流。此功能在PCMM環境中非常有用，在該環境中，不同型別的VoIP呼叫和可能的其它應用都同時在一個上游通道上提供服務。

由於LLQ排程程式降低了授權分段的可能性，因此LLQ排程程式可以更有效地排程盡力流量。當計畫不可分段的DOCSIS 1.0突發時，LLQ排程程式不會像DOCSIS相容排程程式有時會做的那樣，在UGS授權或RTPS輪詢前建立未使用的頻寬間隙。這樣可以更好地利用可用的上游時間。

儘管使用LLQ排程程式時的UGS抖動通常比使用DOCSIS相容排程程式時高，但在典型基於DOCSIS或PacketCable的網路中，LLQ排程程式抖動級別完全在VoIP端點抖動緩衝區技術的容量之內。這意味著在正確設計的VoIP網路中使用LLQ排程程式時，對VoIP呼叫品質沒有明顯影響。

您可以限制由大型上游突發引起的抖動。為此，請確保將纜線的default-phy-burst引數保留為預設值2000位元組或更少。如果系統使用特別慢的上游通道（例如使用800 kHz或更小的通道寬度），則使用cable upstream fragment-force命令強制將大型突發分解為較小的突發時，可以進一步降低抖動。

當使用LLQ排程程式時，您必須配置電纜准入控制，以防止出現上行通道超訂用的可能性。UGS服務流比上游可以實際處理的流量多，導致上游所有UGS服務流中的語音品質較差。在極端情況下，這也表示纜線資料機離線，且新的纜線資料機無法聯機。Cisco建議CMTS操作員配置准入控制，使任何上游埠上的總上游利用率在較長時間內不高於75%。

結論

Cisco uBR系列的DOCSIS CMTS產品提供兩種可選的上游排程演算法，因此能夠滿足各種網路條件。

DOCSIS相容排程程式（針對低抖動進行了最佳化）最適合於具有統一VoIP編解碼器的典型Packetcable 1.x語音系統，並且需要使用UGS服務流的標準級別的上游通道利用率。

低延遲隊列排程程式旨在支援UGS服務流比正常水準更高的上游利用率、提高盡力流量效率，以及使用UGS和RTPS服務流（具有各種授權間隔和授權大小）的系統。

附錄 A：米尼斯洛

最小單位是DOCSIS上游中最小的傳輸單位。當纜線資料機向CMTS傳送頻寬要求以要求上游傳輸時間時，資料機會以最小單位而不是以位元或毫秒為單位。此外，當頻寬分配MAP消息通知數據機它們何時可以傳輸以及傳輸多長時間時，該消息包含以最小量為單位的資訊。

一個突發中數據機可以請求傳輸的最小批次最大數量為255。最小批次大小以稱為DOCSIS刻度的單位指定。DOCSIS刻度線相當於6.25微秒的時間。

要以刻度為單位設定上游埠的minislot大小，請發出cable upstream <upstream-number> minislot-size [1 | 2 | 4 | 8 | 16 | 32 | 64 | 128] cable interface命令。

對於特定的上行通道寬度，只允許特定的最小批次大小。此表顯示了有效的小批次大小與DOCSIS上游通道寬度，還顯示了具有有效設定的小批次號的調制方案符號長度。

注意：X標籤表示無效組合。

	200千赫	400千赫	800千赫	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位。在本示例中，一個minislot相當於32個符號/minislot * 2個位/符號= 64位/minislot = 8個位元組/minislot。

請記住，纜線資料機可以要求傳輸的最大最小位元數是255。因此，在本範例中，上游資料機可以產生的最大突發（以位元為單位）是255 minislots * 8位元組/最小位元= 2040位元組。

請注意，此圖（以位元組為單位）是後轉發錯誤糾正和後物理層開銷圖。當乙太網幀通過上行通道時，糾錯和其他DOCSIS PHY層開銷會增加大約10%到20%的長度。要獲得精確的數字，請使用應用於上游埠的調制配置檔案。

此討論意義重大，因為本檔案的前一節指出，纜線資料機的最大突發大小限制之一是在cable default-phy-burst命令中配置的值。如果在本示例的上下文中將cable default-phy-burst命令設定為4000位元組，則限制因子或突發大小為255最小批次限制（2040位元組減去額外負荷），而不是電纜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

思科建議您將minislot大小設定為使minislot相當於16位元組或最接近的允許值。16位元組的微型插槽使纜線資料機能夠產生高達255 * 16 = 4096位元組的後FEC突發。

附錄 B：MAP高級

CMTS週期性地產生稱為頻寬分配MAP的特殊消息，該消息通知電纜數據機在上游通道上進行傳輸的精確時間。傳送MAP訊息的電訊訊號需要有限的時間，才能透過混合光纖同軸(HFC)網路從CMTS實際傳播到所有連線的纜線資料機。因此，MAP消息需要足夠早地被傳送，以便數據機接收該消息並能夠進行其上游傳輸，以便它們在指定時間到達CMTS。

MAP提前時間或MAP提前時間表示CMTS生成MAP消息的時間與CMTS需要接收由MAP排序的第一傳輸的時間之間的差。此時間表示DOCSIS系統中存在以下延遲的組合：

CMTS在軟體中構建MAP消息以及消息排隊並由下游傳輸電路處理的時間。此元件的值特定於不同的平台和體系結構，通常是一個固定值。
下游交織功能增加的延遲，用於前向糾錯目的以防止脈衝雜訊。要更改此值，請更改下游交織器引數。
電訊號通過HFC網路從CMTS傳輸到電纜數據機並再次返回所需的時間。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微秒加上任何上游交織延遲。但是，在極少數情況下，某些舊品牌的電纜數據機可能需要長達300微秒來處理MAP消息。使用功能更強大的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微秒。

靜態對映升級

在已知HFC網路長度明顯小於100哩的系統中，您可以在計算MAP提前時間時，將CMTS配置為使用小於標準1800微秒的最大往返時間。

要強制CMTS在MAP提前計算中使用往返時間的自定義值，請發出cable map-advance static max-round-trip-time cable interface命令。

最大往返時間的範圍為100到2000微秒。如果沒有為max-round-trip-time指定值，則應用預設值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微秒的對映提前時間。如果更改下游交織器特性或max-round-trip-time引數，該更改將反映在靜態對映提前值中。

動態對映升級

使用靜態MAP提前計算來最佳化MAP提前時間需要CMTS操作員手動確定電纜段上的最大往返時間。如果任何下游或上游通道特性改變，或者任何裝置條件改變，最大往返時間可以顯著改變。要持續更新配置以適應系統條件的變化是很難的。

動態MAP高級演算法解決了這個問題。動態MAP高級演算法定期掃描show cable modem list以搜尋具有最大初始測距定時偏移的數據機，然後自動使用該值計算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微秒。

max-round-trip-time引數範圍為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 Timing Offset改變、safety-value修改或下游交織器特性改變，則此值可能不同。

動態MAP高級演算法取決於電纜數據機是否正確向CMTS報告其初始測距定時偏移。不幸的是，某些電纜數據機的製造商和型號將初始測距定時偏移報告為顯著低於真實值的值。當數據機顯示接近零甚至負值的定時偏移時，可以觀察到這種情況。

與%UBR7200-4-BADTXOFFSET類似的錯誤消息：在此類纜線資料機上，偵測到纜線資料機00ff.0bad.caf3的錯誤計時偏移–2可能會出現。這些型別的纜線資料機不會以符合DOCSIS的方式報告其定時偏移，動態對映提前演算法無法正確計算保證為每條纜線資料機提供接收和響應MAP消息的時間的地圖提前時間。

如果此類纜線資料機存在於纜線網段上，請停用動態MAP進階演演算法，然後回復到靜態MAP進階演演算法。請參閱為什麼某些纜線資料機顯示負時間偏移？以獲取更多資訊。

適用於Cisco uBR CMTS的上游排程器模式組態

下載選項

無偏見用語

關於此翻譯

目錄

修訂記錄

這份文件是否有所幫助？

讓思科協助您

本文件適用於這些產品