Configurazione della modalità utilità di pianificazione upstream per Cisco uBR CMTS

Introduzione

In questo documento viene descritta la configurazione della modalità di pianificazione a monte per i Cisco Universal Broadband Router (uBR) serie di sistemi di terminazione modem via cavo (CMTS).

Il documento si rivolge principalmente al personale che si occupa della progettazione e della manutenzione di reti data-over-cable ad alta velocità che utilizzano servizi a monte sensibili alla latenza e all'effetto jitter, ad esempio servizi voce o video su IP.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Sistemi Data over Cable Service Interface Specification (DOCSis)

• Cisco serie uBR di CMTS

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• Cisco uBR CMTS

• Software Cisco IOS® release train 12.3(13a)BC e 12.3(17a)BC

Nota: per informazioni sulle modifiche nelle versioni più recenti del software Cisco IOS, consultare le note sulla versione appropriate sul sito Web Cisco.com.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Premesse

In una rete DOCSIS (Data-over-Cable Service Interface Specifications), il CMTS controlla i tempi e la velocità di tutte le trasmissioni a monte eseguite dai modem via cavo. Molti tipi diversi di servizi con diversi requisiti di latenza, jitter e throughput vengono eseguiti contemporaneamente su una moderna rete DOCSIS a monte. È quindi necessario comprendere in che modo il CMTS decide quando un modem via cavo può effettuare trasmissioni upstream per conto di questi diversi tipi di servizi.

Il presente white paper include:

• Una panoramica delle modalità di pianificazione a monte in DOCSIS, tra cui il massimo impegno, il servizio UGS (Unsolicited Grant Service) e il servizio di polling in tempo reale (RTPS)

• Il funzionamento e la configurazione dello scheduler conforme a DOCSIS per Cisco uBR CMTS

• Il funzionamento e la configurazione della nuova utilità di pianificazione delle code a bassa latenza per Cisco uBR CMTS

Pianificazione upstream in DOCSIS

Un CMTS conforme a DOCSIS può fornire diverse modalità di pianificazione a monte per diversi flussi di pacchetti o applicazioni attraverso il concetto di flusso di servizio. Un flusso di servizio rappresenta un flusso di dati a monte o a valle che un ID flusso di servizio (SFID) identifica in modo univoco. Ogni flusso di servizio può avere i propri parametri QoS (Quality of Service), ad esempio throughput massimo, throughput minimo garantito e priorità. Nel caso dei flussi di servizi a monte, è inoltre possibile specificare una modalità di programmazione.

È possibile disporre di più flussi di servizio a monte per ogni modem via cavo per supportare diversi tipi di applicazioni. Ad esempio, il Web e l'e-mail possono utilizzare un flusso di servizi, il VoIP (Voice over IP) può utilizzarne un altro e i giochi su Internet possono utilizzare un flusso di servizi ancora diverso. Per poter fornire un tipo di servizio appropriato per ciascuna di queste applicazioni, le caratteristiche di questi flussi di servizi devono essere diverse.

Il modem via cavo e il CMTS sono in grado di indirizzare i tipi di traffico corretti verso i flussi di servizio appropriati utilizzando i classificatori. I classificatori sono filtri speciali, come gli elenchi degli accessi, che corrispondono alle proprietà dei pacchetti, come i numeri delle porte UDP e TCP, per determinare il flusso di servizio appropriato attraverso cui devono passare i pacchetti.

Nella Figura 1, un modem via cavo ha tre flussi di servizio upstream. Il primo flusso del servizio è riservato al traffico vocale. Questo flusso di servizio ha un throughput massimo basso ma è anche configurato per fornire una garanzia di bassa latenza. Il prossimo flusso del servizio è per il traffico generale via Web e e-mail. Il flusso del servizio ha un throughput elevato. Il flusso del servizio finale è riservato al traffico peer-to-peer (P2P). Il flusso del servizio ha un throughput massimo più restrittivo per rallentare la velocità dell'applicazione.

Figura 1 - Modem via cavo con tre flussi di servizi upstream

I flussi di servizi vengono stabiliti e attivati alla prima connessione di un modem via cavo. Eseguire il provisioning dei dettagli dei flussi di servizi nel file di configurazione DOCSIS utilizzato per configurare il modem via cavo. Eseguire il provisioning di almeno un flusso del servizio per il traffico a monte e di un altro flusso del servizio per il traffico a valle in un file di configurazione DOCSIS. I primi flussi di servizi a monte e a valle specificati nel file di configurazione DOCSIS sono denominati flussi di servizi primari.

I flussi di servizi possono inoltre essere creati e attivati in modo dinamico dopo l'attivazione di un modem via cavo. Questo scenario si applica in genere a un flusso di servizio, che corrisponde ai dati che appartengono a una chiamata telefonica VoIP. Questo flusso di servizi viene creato e attivato all'inizio di una conversazione telefonica. Il flusso del servizio viene quindi disattivato ed eliminato al termine della chiamata. Se il flusso del servizio esiste solo quando necessario, è possibile risparmiare le risorse della larghezza di banda upstream e il carico e la memoria della CPU del sistema.

I modem via cavo non possono effettuare trasmissioni upstream in qualsiasi momento. Al contrario, i modem devono attendere le istruzioni del CMTS prima di poter inviare i dati, in quanto solo un modem via cavo può trasmettere i dati su un canale upstream alla volta. In caso contrario, le trasmissioni possono sovraccaricarsi e danneggiarsi a vicenda. Le istruzioni su quando un modem via cavo può effettuare una trasmissione vengono fornite dal CMTS sotto forma di messaggio MAP di allocazione della larghezza di banda. Il Cisco CMTS trasmette un messaggio MAP ogni 2 millisecondi per comunicare ai modem via cavo quando possono effettuare una trasmissione di qualsiasi tipo. Ogni messaggio MAP contiene informazioni che indicano ai modem esattamente quando effettuare una trasmissione, la durata della trasmissione e il tipo di dati che possono trasmettere. In questo modo, le trasmissioni dei dati tramite modem via cavo non entrano in conflitto tra loro ed evitano il danneggiamento dei dati. In questa sezione vengono illustrati alcuni dei modi in cui un CMTS può stabilire quando concedere a un modem via cavo l'autorizzazione a effettuare una trasmissione a monte.

Best-effort

La pianificazione del massimo sforzo è adatta per le applicazioni Internet classiche senza requisiti rigorosi di latenza o jitter. Esempi di questi tipi di applicazioni includono la posta elettronica, l'esplorazione del Web o il trasferimento di file peer-to-peer. La pianificazione basata sul massimo sforzo non è adatta per le applicazioni che richiedono una latenza o un tremolio garantito, ad esempio voce o video su IP. Questo perché in condizioni di congestione non è possibile fornire una garanzia di questo tipo nella modalità "massimo sforzo". I sistemi DOCSIS 1.0 consentono solo questo tipo di pianificazione.

I flussi del servizio "Best FFORT" vengono in genere forniti nel file di configurazione DOCSIS associato a un modem via cavo. Pertanto, i flussi del servizio massimo sforzo sono in genere attivi non appena il modem via cavo è in linea. Il flusso del servizio upstream primario, ovvero il primo flusso del servizio upstream di cui eseguire il provisioning nel file di configurazione DOCSIS, deve essere un flusso del servizio nel miglior modo possibile.

Di seguito sono riportati i parametri utilizzati più comunemente che definiscono un flusso del servizio ottimale in modalità DOCSIS 1.1/2.0:

• Velocità massima di traffico sostenuto (R)

  Velocità massima traffico sostenuto è la velocità massima alla quale il traffico può operare su questo flusso di servizio. Questo valore è espresso in bit al secondo.

• Maximum Traffic Burst (B)

  Il valore di Burst di traffico massimo si riferisce alle dimensioni di burst in byte applicate al limitatore di velocità del bucket di token che applica limiti di velocità effettiva upstream. Se non si specifica alcun valore, viene applicato il valore predefinito di 3044, che corrisponde alle dimensioni di due frame Ethernet completi. Per le velocità massime di traffico sostenuto di grandi dimensioni, impostare questo valore almeno sulla velocità massima di traffico sostenuto divisa per 64.

• Priorità traffico

  Questo parametro fa riferimento alla priorità del traffico in un flusso del servizio compreso tra 0 (il valore più basso) e 7 (il valore più alto). A monte, tutto il traffico in sospeso per i flussi di servizi ad alta priorità viene pianificato per la trasmissione prima del traffico per i flussi di servizi a bassa priorità.

• Tasso riservato minimo

  Questo parametro indica un throughput minimo garantito in bit al secondo per il flusso del servizio, simile a un CIR (Committed Information Rate). Le tariffe minime riservate combinate per tutti i flussi di servizi su un canale non devono superare la larghezza di banda disponibile su tale canale. Altrimenti non è possibile garantire le tariffe minime riservate promesse.

• Burst concatenato massimo

  Il valore di Maximum Concatenated Burst è la dimensione in byte della più grande trasmissione di frame concatenati che un modem può effettuare per conto del flusso del servizio. Come indica questo parametro, un modem può trasmettere più frame in un'unica sequenza di trasmissione. Se questo valore non viene specificato, i modem via cavo DOCSIS 1.0 e i modem DOCSIS 1.1 precedenti presuppongono che non vi sia alcun limite esplicito impostato sulle dimensioni della frammentazione concatenata. I modem conformi alle revisioni più recenti delle specifiche DOCSIS 1.1 o versioni successive utilizzano un valore di 1522 byte.

Quando un modem via cavo ha i dati da trasmettere per conto di un flusso del servizio a monte, il modem non può semplicemente inoltrare i dati alla rete DOCSIS senza ritardi. Il modem deve passare attraverso un processo in cui richiede al CMTS un tempo di trasmissione upstream esclusivo. Questo processo di richiesta garantisce che i dati non entrino in conflitto con le trasmissioni di un altro modem via cavo collegato allo stesso canale a monte.

A volte il CMTS pianifica determinati periodi in cui il CMTS consente ai modem via cavo di trasmettere messaggi speciali denominati richieste di larghezza di banda. La richiesta di larghezza di banda è un frame molto piccolo che contiene i dettagli della quantità di dati che il modem desidera trasmettere, più un ID servizio (SID) che corrisponde al flusso di servizio upstream che deve trasmettere i dati. Il CMTS gestisce una tabella interna che corrisponde ai numeri SID ai flussi di servizi a monte.

Il CMTS pianifica le opportunità di richiesta della larghezza di banda quando non sono pianificati altri eventi nella fase upstream. In altre parole, lo scheduler fornisce opportunità di richiesta della larghezza di banda quando lo scheduler a monte non ha pianificato una concessione di massimo sforzo o una concessione UGS o un altro tipo di concessione da collocare in un punto particolare. Pertanto, quando un canale a monte viene utilizzato intensamente, i modem via cavo hanno meno opportunità di trasmettere le richieste di larghezza di banda.

Il CMTS assicura sempre che un piccolo numero di opportunità di richiesta di larghezza di banda siano pianificate regolarmente, indipendentemente dalla congestione del canale a monte. Più modem via cavo possono trasmettere contemporaneamente le richieste di larghezza di banda e danneggiare le trasmissioni dell'altro modem. Per ridurre il rischio di collisioni che possano danneggiare le richieste di larghezza di banda, è stato implementato un algoritmo di "backoff and retry". Nelle sezioni seguenti di questo documento viene descritto questo algoritmo.

Quando il CMTS riceve una richiesta di larghezza di banda da un modem via cavo, esegue le azioni seguenti:

1. Il CMTS utilizza il numero SID ricevuto nella richiesta di larghezza di banda per esaminare il flusso di servizio a cui è associata la richiesta di larghezza di banda.

2. Il CMTS utilizza quindi l'algoritmo del token bucket. Questo algoritmo consente al CMTS di controllare se il flusso del servizio supererà la velocità massima sostenuta prescritta se il CMTS concede la larghezza di banda richiesta. Di seguito viene riportato il calcolo dell'algoritmo del token bucket:

   Max(T) = T * (R / 8) + B

   dove:

   • Max(T) indica il numero massimo di byte che possono essere trasmessi sul flusso di servizio nel tempo T.

   • T rappresenta il tempo in secondi.

   • R indica la velocità massima del traffico sostenuto per il flusso del servizio in bit al secondo

   • B è il picco di traffico massimo per il flusso del servizio in byte.

3. Quando il CMTS rileva che la richiesta di larghezza di banda rientra nei limiti di throughput, il CMTS accoda i dettagli della richiesta di larghezza di banda all'utilità di pianificazione a monte. L'utilità di pianificazione a monte decide quando concedere la richiesta di larghezza di banda.

   Cisco uBR CMTS implementa due algoritmi di pianificazione a monte, denominati utilità di pianificazione compatibile DOCSIS e utilità di pianificazione delle code a bassa latenza. Per ulteriori informazioni, vedere le sezioni Scheduler compatibile DOCSIS e Scheduler di coda a bassa latenza in questo documento.

4. Il CMTS include questi dettagli nel successivo messaggio MAP di allocazione periodica della larghezza di banda:

   • Quando il modem via cavo è in grado di trasmettere.

   • Per quanto tempo il modem via cavo è in grado di trasmettere.

Algoritmo backoff e riprova richiesta larghezza di banda

Il meccanismo di richiesta della larghezza di banda utilizza un semplice algoritmo di "backoff and retry" per ridurre, ma non eliminare completamente, il rischio di collisioni tra più modem via cavo che trasmettono richieste di larghezza di banda contemporaneamente.

Un modem via cavo che decide di trasmettere una richiesta di larghezza di banda deve attendere il passaggio di un numero casuale di opportunità di richiesta di larghezza di banda prima di poter effettuare la trasmissione. Questo tempo di attesa riduce la possibilità di collisioni dovute alla trasmissione simultanea di richieste di larghezza di banda.

Due parametri denominati data backoff start e data backoff end determinano il periodo di attesa casuale. I modem via cavo imparano questi parametri come parte del contenuto del messaggio UCD (Peridic Upstream Channel Descriptor). Il CMTS trasmette il messaggio UCD per conto di ciascun canale upstream attivo ogni due secondi.

Questi parametri di backoff sono espressi come valori di "potenza di due". I modem utilizzano questi parametri come potenze di due per calcolare il tempo di attesa prima di trasmettere le richieste di larghezza di banda. Entrambi i valori hanno un intervallo compreso tra 0 e 15 e la fine backoff dati deve essere maggiore o uguale all'inizio backoff dati.

La prima volta che un modem via cavo desidera trasmettere una determinata richiesta di larghezza di banda, il modem deve prima scegliere un numero casuale compreso tra 0 e 2 alla potenza dell'avvio del backoff dei dati meno 1. Ad esempio, se l'avvio del backoff dei dati è impostato su 3, il modem deve scegliere un numero casuale compreso tra 0 e (2³ - 1) = (8 - 1) = 7.

Il modem via cavo deve quindi attendere che il numero casuale selezionato di opportunità di trasmissione delle richieste di larghezza di banda passi prima di trasmettere una richiesta di larghezza di banda. Pertanto, mentre un modem non può trasmettere una richiesta di larghezza di banda alla successiva opportunità disponibile a causa di questo ritardo forzato, la possibilità di una collisione con la trasmissione di un altro modem si riduce.

Naturalmente, maggiore è il valore di inizio del backoff dei dati, minore è la possibilità di collisioni tra richieste di larghezza di banda. Valori maggiori per l'avvio in backoff dei dati implicano anche che i modem devono potenzialmente attendere più a lungo per trasmettere le richieste di larghezza di banda, con un conseguente aumento della latenza upstream.

Il CMTS include una conferma nel successivo messaggio MAP di allocazione della larghezza di banda trasmesso. La presente conferma informa il modem via cavo che la richiesta di larghezza di banda è stata ricevuta correttamente. Tale riconoscimento può:

• indicare esattamente quando il modem può effettuare la trasmissione

  O

• Indicare solo che la richiesta di larghezza di banda è stata ricevuta e che un'ora per la trasmissione sarà decisa in un futuro messaggio MAP.

Se il CMTS non include una conferma della richiesta di larghezza di banda nel messaggio MAP successivo, il modem può concludere che la richiesta di larghezza di banda non è stata ricevuta. Questa situazione può verificarsi a causa di una collisione o di un rumore a monte oppure perché il flusso di servizio supera la velocità di trasmissione massima prescritta se la richiesta viene accettata.

In entrambi i casi, il passaggio successivo per il modem via cavo è il backoff, quindi provare a trasmettere di nuovo la richiesta di larghezza di banda. Il modem aumenta l'intervallo nel quale viene scelto un valore casuale. A tale scopo, il modem ne aggiunge uno al valore di avvio del backoff dei dati. Ad esempio, se il valore di inizio del backoff dei dati è 3 e il CMTS non riesce a ricevere una trasmissione di richiesta di larghezza di banda, il modem attende un valore casuale compreso tra 0 e 15 opportunità di richiesta di larghezza di banda prima di ritrasmettere. Ecco il calcolo: 23+1 - 1 = 24 - 1 = 16 - 1 = 15

L'intervallo di valori più ampio riduce la possibilità di un'altra collisione. Se il modem perde ulteriori richieste di larghezza di banda, continua a incrementare il valore utilizzato come potenza di due per ogni ritrasmissione finché il valore non è uguale al back-off dei dati. La potenza di due unità non deve aumentare per essere maggiore del valore finale del back-off dei dati.

Il modem ritrasmette una richiesta di larghezza di banda fino a 16 volte, dopodiché la elimina. Questa situazione si verifica solo in condizioni estremamente congestionate.

È possibile configurare i valori di inizio e fine del backoff dei dati per cavo a monte su un Cisco uBR CMTS con questo comando di interfaccia dei cavi:

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

Cisco consiglia di mantenere i valori predefiniti per i parametri data-backoff-start e data-backoff-end, che sono 3 e 5. La natura basata sui conflitti del sistema di pianificazione del massimo sforzo significa che, per i flussi di servizio del massimo sforzo, è impossibile fornire un livello deterministico o garantito di latenza o jitter a monte. Inoltre, condizioni di congestione possono rendere impossibile garantire un particolare livello di throughput per un flusso di servizio ottimale. Tuttavia, è possibile utilizzare le proprietà del flusso del servizio, ad esempio la priorità e la tariffa riservata minima. Con queste proprietà, il flusso del servizio può raggiungere il livello di velocità di trasmissione desiderato in condizioni di congestione.

Esempio di algoritmo Backoff e Retry

Questo esempio comprende quattro modem via cavo denominati A, B, C e D, collegati allo stesso canale a monte. Nello stesso istante denominato t₀, i modem A, B e C decidono di trasmettere alcuni dati a monte.

In questo caso, l'inizio del backoff dei dati è impostato su 2 e l'estremità del backoff dei dati è impostata su 4. L'intervallo di intervalli da cui i modem scelgono un intervallo prima di tentare di trasmettere una richiesta di larghezza di banda è compreso tra 0 e 3. Di seguito viene riportato il calcolo:

(22 - 1) = (4 - 1) = 3 intervalli.

Di seguito è riportato il numero di opportunità di richiesta della larghezza di banda che i tre modem scelgono per attendere dal tempo t₀.

• Modem A: 3

• Modem B: 2

• Modem C: 3

Si noti che il modem A e il modem C scelgono lo stesso numero di opportunità da attendere.

Il modem B attende due opportunità di richiesta della larghezza di banda che compaiono dopo t₀. Il modem B trasmette quindi la richiesta della larghezza di banda che viene ricevuta dal CMTS. Sia il modem A che il modem C attendono 3 opportunità di richiesta della larghezza di banda dopo t₀. I modem A e C trasmettono le richieste della larghezza di banda contemporaneamente. Queste due richieste di larghezza di banda si scontrano e diventano danneggiate. Di conseguenza, nessuna richiesta raggiunge il CMTS. La Figura 2 mostra questa sequenza di eventi.

Figura 2 - Richiesta di larghezza di banda - Parte 1

La barra grigia nella parte superiore del diagramma rappresenta una serie di opportunità di richiesta della larghezza di banda disponibili per i modem via cavo dopo il tempo t₀. Le frecce colorate rappresentano le richieste di larghezza di banda trasmesse dai modem via cavo. La casella colorata all'interno della barra grigia rappresenta una richiesta di larghezza di banda che raggiunge correttamente il CMTS.

Il successivo messaggio MAP trasmesso dal CMTS contiene una concessione per il modem B ma nessuna istruzione per i modem A e C. Ciò indica ai modem A e C che devono ritrasmettere le richieste di larghezza di banda.

Al secondo tentativo, il modem A e il modem C devono incrementare la potenza di due per calcolare l'intervallo di intervalli da scegliere. A questo punto, il modem A e il modem C selezionano un numero casuale di intervalli tra 0 e 7. Di seguito viene riportato il calcolo:

(22+1 -1) = (23 - 1) = (8 - 1) = 7 intervalli.

Si supponga che l'ora in cui il modem A e il modem C si rendono conto della necessità di ritrasmettere sia t₁. Si supponga inoltre che un altro modem, il modem D, decida di trasmettere alcuni dati upstream nello stesso istante, ovvero t₁. Il modem D sta per trasmettere una richiesta di larghezza di banda per la prima volta. Pertanto, il modem D utilizza il valore originale per l'inizio e la fine del backoff dei dati, ovvero tra 0 e 3 [(22 - 1) = (4 - 1) = 3 intervalli].

I tre modem scelgono questo numero casuale di opportunità di richiesta della larghezza di banda da attendere dal tempo t₁.

• Modem A: 5

• Modem C: 2

• Modem D: 2

Entrambi i modem C e D attendono due opportunità di richiesta della larghezza di banda che compaiono dopo il tempo t₁. I modem C e D trasmettono quindi le richieste della larghezza di banda contemporaneamente. Queste richieste di larghezza di banda si scontrano e quindi non raggiungono il CMTS. Il modem A consente il passaggio di cinque opportunità di richiesta della larghezza di banda. Quindi, il modem A trasmette la richiesta della larghezza di banda che il CMTS riceve. La Figura 3 mostra la collisione tra la trasmissione dei modem C e D e la ricezione della trasmissione del modem A. Il riferimento dell'ora di inizio per questa figura è t₁.

Figura 3 - Richiesta di larghezza di banda - Parte 2

Il successivo messaggio MAP trasmesso dal CMTS contiene una concessione per il modem A ma nessuna istruzione per i modem C e D. I modem C e D riconoscono la necessità di ritrasmettere le richieste di larghezza di banda. Il modem D sta per trasmettere la richiesta della larghezza di banda per la seconda volta. Pertanto, il modem D utilizza l'avvio di ritorno dei dati + 1 come potenza di due per il calcolo dell'intervallo di intervalli da attendere. Il modem D sceglie un intervallo tra 0 e 7. Di seguito viene riportato il calcolo:

(22+1 - 1) = (23 - 1) = (8 - 1) = 7 intervalli.

Il modem C sta per trasmettere la richiesta della larghezza di banda per la terza volta. Pertanto, il modem C utilizza l'inizio del backoff dei dati + 2 come potenza di due a nel calcolo dell'intervallo di intervalli da attendere. Il modem C sceglie un intervallo compreso tra 0 e 15. Di seguito viene riportato il calcolo:

(22+2 - 1) = (24 - 1) = (16 - 1) = 15 intervalli.

Notare che la potenza di due è uguale al valore finale di backoff dei dati, che è quattro. Si tratta del valore massimo consentito per la potenza di due valori per un modem su questo canale upstream. Nel successivo ciclo di trasmissione delle richieste di larghezza di banda, i due modem selezionano il numero di richieste di larghezza di banda che possono attendere:

• Modem C: 9

• Modem D: 4

Il modem D è in grado di trasmettere la richiesta di larghezza di banda in quanto il modem D attende quattro opportunità di richiesta di larghezza di banda. Inoltre, il modem C è anche in grado di trasmettere la richiesta di larghezza di banda, poiché il modem C rinvia ora la trasmissione per nove opportunità di richiesta di larghezza di banda.

Sfortunatamente, quando il modem C effettua una trasmissione, un grande scoppio di rumore in entrata interferisce con la trasmissione, e il CMTS non riesce a ricevere la richiesta della larghezza di banda (vedere la Figura 4). Di conseguenza, ancora una volta, il modem C non riesce a vedere una concessione nel successivo messaggio MAP trasmesso dal CMTS. In questo modo, il modem C tenterà una quarta trasmissione della richiesta di larghezza di banda.

Figura 4 - Richiesta di larghezza di banda - Parte 3

Il modem C ha già raggiunto il valore 4 per il backoff dei dati. Il modem C non può aumentare l'intervallo utilizzato per scegliere un numero casuale di intervalli da attendere. Pertanto, il modem C utilizza ancora una volta 4 come potenza di due per calcolare l'intervallo casuale. Il modem C utilizza ancora l'intervallo compreso tra 0 e 15 intervalli, come indicato di seguito:

(24 - 1) = (16 - 1) = 15 intervalli.

Al quarto tentativo, il modem C è in grado di trasmettere correttamente le richieste di larghezza di banda in assenza di conflitti o rumore.

In questo esempio, le ritrasmissioni delle richieste di larghezza di banda multipla del modem C mostrano cosa può accadere su un canale a monte congestionato. In questo esempio vengono inoltre illustrati i potenziali problemi relativi alla modalità di pianificazione delle risorse ottimali e il motivo per cui tale modalità non è adatta per servizi che richiedono livelli di latenza e jitter dei pacchetti rigorosamente controllati.

Priorità traffico

Quando nel CMTS sono presenti più richieste di larghezza di banda in sospeso provenienti da diversi flussi di servizi, il CMTS controlla la priorità del traffico di ogni flusso di servizio per decidere quali concedere prima la larghezza di banda.

Il CMTS concede il tempo di trasmissione a tutte le richieste in sospeso provenienti da flussi di servizi con una priorità più alta prima delle richieste di larghezza di banda provenienti da flussi di servizi con una priorità più bassa. In condizioni di upstream congestionate, ciò in genere comporta un throughput più elevato per i flussi di servizi ad alta priorità rispetto ai flussi di servizi a bassa priorità.

Un fatto importante da notare è che mentre un flusso del servizio con la massima priorità ha maggiori probabilità di ricevere rapidamente la larghezza di banda, il flusso del servizio è ancora soggetto alla possibilità di collisioni tra richieste di larghezza di banda. Per questo motivo, mentre la priorità del traffico può migliorare le caratteristiche di velocità effettiva e latenza di un flusso di servizio, la priorità del traffico non è ancora un modo appropriato per fornire una garanzia del servizio per le applicazioni che ne richiedono una.

Tasso riservato minimo

I flussi del servizio massimo sforzo possono ricevere una tariffa riservata minima da rispettare. Il CMTS garantisce che un flusso di servizio con una determinata velocità minima riservata riceva la larghezza di banda preferibilmente rispetto a tutti gli altri flussi di servizio di massimo sforzo, indipendentemente dalla priorità.

Questo metodo è un tentativo di fornire una sorta di servizio di tipo CIR (Committed Information Rate) analogo a una rete Frame Relay. Il CMTS dispone di meccanismi di controllo dell’ammissione per garantire che, su un particolare canale a monte, la tariffa riservata minima combinata di tutti i flussi di servizi connessi non possa superare la larghezza di banda disponibile del canale a monte, o una sua percentuale. È possibile attivare questi meccanismi con il comando per porta upstream:

[no] cavo a monte a monte-porta-id controllo-ammissione max-booking-limit

Il parametro max-Reservation-limit ha un intervallo compreso tra 10 e 1000% per indicare il livello di sottoscrizione rispetto al throughput del canale a monte non elaborato disponibile che i servizi di stile CIR possono utilizzare. Se si configura un limite massimo di prenotazione maggiore di 100, la versione a monte può sovrascrivere i servizi di tipo CIR in base al limite percentuale specificato.

Il CMTS non consente di stabilire nuovi flussi di servizi con tariffa riservata minima se causerebbero il superamento da parte della porta a monte della percentuale configurata per il limite massimo di prenotazione della larghezza di banda del canale a monte disponibile. I flussi del servizio con tariffa riservata minima sono ancora soggetti a potenziali collisioni di richieste di larghezza di banda. Di conseguenza, i flussi di servizi con tariffa riservata minima non possono fornire una reale garanzia di un determinato throughput, soprattutto in condizioni di congestione estrema. In altre parole, il CMTS può garantire che un flusso di servizio a tariffa riservata minima sia in grado di raggiungere un determinato throughput a monte garantito solo se è in grado di ricevere tutte le richieste di larghezza di banda dal modem via cavo. Questo requisito può essere soddisfatto se si rende il flusso del servizio un flusso del servizio di polling in tempo reale (RTPS) anziché un flusso del servizio ottimale. Per ulteriori informazioni, vedere la sezione Servizio di polling in tempo reale (RTPS).

Richieste larghezza di banda Piggyback

Quando un flusso del servizio upstream al miglior sforzo trasmette i frame ad una velocità elevata, è possibile incanalare le richieste di larghezza di banda su frame di dati upstream piuttosto che avere una trasmissione separata delle richieste di larghezza di banda. I dettagli della successiva richiesta di larghezza di banda vengono semplicemente aggiunti all'intestazione di un pacchetto di dati trasmesso a monte al CMTS.

Ciò significa che la richiesta di larghezza di banda non è oggetto di contesa e ha quindi maggiori probabilità che la richiesta raggiunga il CMTS. Il concetto di richieste di larghezza di banda piggyback riduce il tempo che un frame Ethernet impiega per raggiungere l'apparecchiatura CPE (Customer Premise Equipment) dell'utente finale, perché il tempo che il frame impiega nella trasmissione upstream si riduce. Ciò si verifica perché il modem non deve passare attraverso il backoff e riprovare il processo di trasmissione della richiesta di larghezza di banda, che può essere soggetto a ritardi.

Il piggyback delle richieste di larghezza di banda si verifica in genere in questo scenario:

Mentre il modem via cavo attende di trasmettere un frame, ad esempio X, nel flusso a monte, il modem riceve un altro frame, ad esempio Y, da un CPE per trasmettere nel flusso a monte. Il modem via cavo non può aggiungere i byte del nuovo frame Y alla trasmissione, in quanto ciò comporta l'utilizzo di un tempo superiore a quello concesso dal modem. Il modem compila invece un campo nell'intestazione DOCSIS del frame X per indicare la quantità di tempo di trasmissione richiesta per il frame Y.

Il CMTS riceve il frame X e anche i dettagli di una richiesta di larghezza di banda per conto di Y. In base alla disponibilità, il CMTS concede al modem ulteriori tempi di trasmissione per conto di Y.

In termini molto prudenti, trascorrono appena 5 millisecondi tra la trasmissione di una richiesta di larghezza di banda e la ricezione dell'assegnazione di larghezza di banda, nonché la conferma MAP che assegna il tempo per la trasmissione dei dati. Ciò significa che, per consentire il piggybacking, il modem via cavo deve ricevere i frame dal CPE entro meno di 5 ms l'uno dall'altro.

Questo è degno di nota perché, un tipico codec VoIP come G.711 generalmente usa un periodo inter-frame di 10 o 20 ms. Un flusso VoIP tipico che opera nel miglior modo possibile nell'ambito di un flusso di servizi non può trarre vantaggio dal piggyback.

Concatenazione

Quando un flusso del servizio upstream al massimo sforzo trasmette i frame a una velocità elevata, il modem via cavo può unire alcuni frame e chiedere l'autorizzazione a trasmettere i frame tutti contemporaneamente. Questo processo si chiama concatenazione. Il modem via cavo deve trasmettere solo una richiesta di larghezza di banda per conto di tutti i frame di un gruppo di frame concatenati, migliorando l'efficienza.

La concatenazione tende a verificarsi in circostanze simili al piggybacking, ad eccezione del fatto che la concatenazione richiede l'accodamento di più frame all'interno del modem via cavo quando il modem decide di trasmettere una richiesta di larghezza di banda. Ciò implica che la concatenazione tende a verificarsi a frame rate medi più elevati rispetto al piggybacking. Inoltre, entrambi i meccanismi operano di comune accordo per migliorare l'efficienza del traffico in base al massimo sforzo.

Il campo Burst massimo concatenato che è possibile configurare per un flusso di servizio limita le dimensioni massime di un frame concatenato che un flusso di servizio può trasmettere. Per limitare le dimensioni di un fotogramma concatenato e le dimensioni massime della frammentazione nel profilo di modulazione del canale a monte, potete utilizzare anche il comando cable default-phy-burst.

La concatenazione è abilitata per impostazione predefinita sulle porte a monte della serie Cisco uBR di CMTS. Tuttavia, è possibile controllare la concatenazione per porta a monte con il comando [no] cable upstream upstream-port-id concatenation [docsis10] cable interface.

Se si configura il parametro docsis10, il comando si applica solo ai modem via cavo che funzionano in modalità DOCSIS 1.0.

Se si apportano modifiche a questo comando, i modem via cavo devono registrarsi nuovamente nel CMTS per rendere effettive le modifiche. È necessario reimpostare i modem sul upstream interessato. Un modem via cavo apprende se la concatenazione è consentita nel punto in cui il modem esegue la registrazione come parte del processo di connessione.

Frammentazione

La trasmissione di frame di grandi dimensioni in upstream richiede molto tempo. Questo tempo di trasmissione è noto come ritardo di serializzazione. I frame upstream di grandi dimensioni possono impiegare così tanto tempo a trasmettere da ritardare in modo dannoso i pacchetti che appartengono a servizi sensibili al tempo, ad esempio il VoIP. Ciò è particolarmente vero per i frame grandi concatenati. Per questo motivo, la frammentazione è stata introdotta in DOCSIS 1.1 in modo che i frame grandi possano essere suddivisi in frame più piccoli per la trasmissione in burst separati che richiedono ciascuno meno tempo.

La frammentazione consente di far intersecare piccoli frame sensibili al tempo tra i frammenti di frame di grandi dimensioni, senza dover attendere la trasmissione dell'intero frame. La trasmissione di un frame come frammento multiplo è leggermente meno efficiente della trasmissione di un frame in un burst a causa dell'ulteriore gruppo di intestazioni DOCSIS che devono accompagnare ciascun frammento. Tuttavia, la flessibilità che la frammentazione aggiunge al canale a monte giustifica il sovraccarico extra.

I modem via cavo in modalità DOCSIS 1.0 non possono eseguire la frammentazione.

La frammentazione è abilitata per impostazione predefinita sulle porte a monte della serie Cisco uBR di CMTS. Tuttavia, è possibile abilitare o disabilitare la frammentazione per porta a monte con il comando [no] cable upstream upstream-port-id fragmentation cable interface.

per rendere effettivo il comando, non è necessario reimpostare i modem via cavo. Cisco consiglia di abilitare sempre la frammentazione. La frammentazione si verifica in genere quando il CMTS ritiene che un frame di dati di grandi dimensioni possa interferire con la trasmissione di frame sensibili al tempo di piccole dimensioni o con determinati eventi di gestione DOCSIS periodici.

Per forzare i modem via cavo DOCSIS 1.1/2.0 a frammentare tutti i frame di grandi dimensioni, usare il comando [no] cable upstream upstream-port-id fragment-force [threshold number-of-fragments] cable interface.

Per impostazione predefinita, questa funzione è disabilitata. Se non si specificano valori per la soglia e il numero di frammenti nella configurazione, la soglia viene impostata su 2000 byte e il numero di frammenti su 3. Il comando fragment-force confronta il numero di byte richiesti da un flusso di servizio per la trasmissione con il parametro di soglia specificato. Se le dimensioni della richiesta sono maggiori della soglia, il CMTS assegna la larghezza di banda al flusso di servizio in "numero di frammenti" parti delle stesse dimensioni.

Si supponga, ad esempio, che per una determinata forza di un frammento a monte sia abilitato un valore di 2000 byte per la soglia e di 3 byte per il numero di frammenti. Si supponga quindi di ricevere una richiesta di trasmissione di una frammentazione da 3000 byte. Poiché 3000 byte è maggiore della soglia di 2000 byte, la concessione deve essere frammentata. Poiché il numero di frammenti è impostato su 3, il tempo di trasmissione è pari a tre concessioni di 1000 byte ciascuna.

Accertarsi quindi che le dimensioni dei singoli frammenti non superino la capacità del tipo di scheda della linea di cavo in uso. Per le schede di linea MC5x20S, il singolo frammento più grande non deve superare i 2000 byte, mentre per le altre schede di linea, tra cui MC28U, MC5x20U e MC5x20H, il singolo frammento più grande non deve superare i 4000 byte.

UGS (Unsolicited Grant Service)

Il servizio UGS (Unsolicited Grant Service) fornisce sovvenzioni periodiche per un flusso di servizio a monte senza la necessità di un modem via cavo per trasmettere le richieste di larghezza di banda. Questo tipo di servizio è adatto per applicazioni che generano frame di dimensioni fisse a intervalli regolari e non ammettono la perdita di pacchetti. La tecnologia Voice over IP ne è un classico esempio.

Confrontare il sistema di programmazione UGS con uno slot temporale in un sistema TDM (Time Division Multiplexing), ad esempio un circuito T1 o E1. UGS fornisce un throughput e una latenza garantiti, che a loro volta forniscono un flusso continuo di intervalli periodici fissi da trasmettere senza che il client debba richiedere o contendersi periodicamente la larghezza di banda. Questo sistema è perfetto per il VoIP perché il traffico vocale viene in genere trasmesso come flusso continuo di dati periodici a dimensione fissa.

UGS è stato concepito per la mancanza di garanzie di latenza, jitter e throughput nella modalità di programmazione ottimale. La modalità di programmazione ottimizzata non garantisce la trasmissione di un frame specifico in un determinato momento, e in un sistema congestionato non vi è alcuna garanzia sulla possibilità di trasmettere un frame specifico.

Si noti che, sebbene i flussi di servizi in stile UGS siano il tipo di flusso di servizi più appropriato per trasmettere il traffico VoIP al portatore, non sono considerati appropriati per le applicazioni Internet classiche, quali Web, e-mail o P2P. Questo perché le applicazioni Internet classiche non generano dati a intervalli periodici fissi e possono, infatti, trascorrere periodi significativi di tempo senza trasmettere i dati. Se un flusso del servizio UGS viene utilizzato per trasmettere il traffico Internet classico, il flusso del servizio può rimanere inutilizzato per periodi significativi quando l'applicazione interrompe brevemente le trasmissioni. Ciò porta a sovvenzioni UGS inutilizzate che rappresentano uno spreco di risorse di larghezza di banda a monte che non è desiderabile.

I flussi del servizio UGS vengono in genere stabiliti in modo dinamico quando sono richiesti, anziché essere sottoposti a provisioning nel file di configurazione DOCSIS. Un modem via cavo con porte VoIP integrate in genere chiede al CMTS di creare un flusso del servizio UGS appropriato quando il modem rileva che è in corso una chiamata telefonica VoIP.

Cisco consiglia di non configurare un flusso del servizio UGS in un file di configurazione DOCSIS perché questa configurazione mantiene il flusso del servizio UGS attivo per tutto il tempo in cui il modem via cavo è online, indipendentemente dal fatto che venga utilizzato da un servizio. Questa configurazione spreca larghezza di banda a monte perché un flusso del servizio UGS riserva costantemente tempo di trasmissione a monte per conto del modem via cavo. È molto meglio consentire la creazione e l'eliminazione dinamica del flusso del servizio UGS in modo che UGS sia attivo quando richiesto.

Di seguito sono riportati i parametri utilizzati più comunemente che definiscono un flusso di servizio UGS:

• Dimensione sovvenzione non sollecitata (G): le dimensioni di ciascuna concessione periodica in byte.

• Intervallo di concessione nominale (I) - Intervallo in microsecondi tra le concessioni.

• Jitter concessione tollerato (J) - Variazione consentita in microsecondi rispetto alle concessioni periodiche. In altre parole, questo è il margine di manovra del CMTS quando il CMTS cerca di programmare una concessione UGS in tempo.

Quando un flusso del servizio UGS è attivo, ogni (I) millisecondi, il CMTS offre al flusso del servizio la possibilità di trasmettere a byte di concessione non richiesti (G). Anche se idealmente il CMTS offre la concessione esattamente ogni (I) millisecondi, potrebbe essere in ritardo di (J) millisecondi.

La Figura 5 mostra una cronologia che mostra come le concessioni UGS possono essere allocate con una data dimensione di concessione, intervallo di concessione e jitter tollerato.

Figura 5 - Linea temporale che mostra le concessioni UGS periodiche

I blocchi con motivo verde rappresentano il tempo in cui il CMTS dedica il tempo di trasmissione a monte a un flusso di servizio UGS.

Servizio di polling in tempo reale (RTPS)

Il servizio RTPS (Real Time Polling Service) offre opportunità periodiche di richiesta della larghezza di banda non basata su conflitti, in modo che un flusso di servizio dedichi tempo alla trasmissione delle richieste della larghezza di banda. Solo il flusso del servizio RTPS può utilizzare questa opportunità di richiesta larghezza di banda unicast. Altri modem via cavo non possono causare una collisione di richiesta della larghezza di banda.

Il formato RTPS è adatto per applicazioni che generano frame a lunghezza variabile su base semestrale e richiedono un throughput minimo garantito per un funzionamento efficace. La videotelefonia su reti IP o i giochi online multi-player sono esempi tipici.

Il protocollo RTPS viene utilizzato anche per il traffico di segnalazione VoIP. Mentre il traffico di segnalazione VoIP non deve essere trasmesso con una latenza o uno jitter estremamente bassi, il VoIP deve avere un'alta probabilità di essere in grado di raggiungere il CMTS in un periodo di tempo ragionevole. Se si utilizza il protocollo RTPS invece della pianificazione basata sulle risorse, si può avere la certezza che la segnalazione vocale non subirà ritardi significativi o non verrà eliminata a causa di collisioni ripetute nelle richieste di larghezza di banda.

Un flusso del servizio RTPS in genere dispone dei seguenti attributi:

• Intervallo di polling nominale: l'intervallo in microsecondi tra le opportunità di richiesta della larghezza di banda unicast.

• Variazione poll tollerata - Variazione consentita in microsecondi rispetto ai poll periodici. In altre parole, questo è il margine di cui dispone il CMTS quando cerca di pianificare in tempo un'opportunità di richiesta della larghezza di banda unicast RTPS.

La Figura 6 mostra una timeline che mostra come i polling RTPS vengono allocati con un determinato intervallo di polling nominale e uno jitter di polling tollerato.

Figura 6 - Linea temporale che mostra il polling RTPS periodico

I piccoli blocchi con motivo verde rappresentano il tempo in cui il CMTS offre un flusso di servizio RTPS un'opportunità di richiesta di larghezza di banda unicast.

Quando il CMTS riceve una richiesta di larghezza di banda per conto di un flusso di servizio RTPS, elabora la richiesta di larghezza di banda come una richiesta proveniente da un flusso di servizio "massimo sforzo". Oltre ai parametri sopra indicati, è necessario includere nella definizione di flusso del servizio RTPS proprietà quali la velocità massima di traffico sostenuto e la priorità del traffico. In genere, un flusso del servizio RTPS contiene anche una velocità di traffico riservata minima per garantire che il traffico associato al flusso del servizio sia in grado di ricevere una garanzia di larghezza di banda riservata.

Servizio di concessione non richiesto con rilevamento attività (UGS-AD)

UGS-AS (Unsolicited Grant Service with Activity Detection) assegna il tempo di trasmissione UGS a un flusso di servizio solo quando UGS-AS deve effettivamente trasmettere i pacchetti. Quando il CMTS rileva che il modem via cavo non ha trasmesso i frame per un certo periodo, offre opportunità di richiesta della larghezza di banda in stile RTPS invece di concessioni in stile UGS. Se il CMTS successivamente rileva che il flusso del servizio effettua richieste di larghezza di banda, il CMTS ripristina il flusso del servizio offrendo concessioni in stile UGS e interrompe l'offerta di opportunità di richieste di larghezza di banda in stile RTPS.

UGS-AD viene in genere utilizzato in una situazione in cui il traffico VoIP che utilizzava il rilevamento dell'attività vocale (VAD) veniva trasmesso. Il rilevamento dell'attività vocale interrompe la trasmissione dei frame VoIP se UGS-AD rileva una pausa nel discorso dell'utente. Anche se questo comportamento può risparmiare larghezza di banda, può causare problemi con la qualità della voce, soprattutto se il meccanismo di rilevamento di attività VAD o UGS-AD si attiva leggermente dopo che il destinatario inizia a parlare. Ciò può causare un rumore simile a uno scoppio o un clic quando l'utente riprende a parlare dopo il silenzio. Per questo motivo UGS-AD non è molto diffuso.

Eseguire il comando di configurazione CMTS globale flow inactivity-threshold-in-seconds per impostare il periodo dopo il quale il CMTS passa un servizio UGS-AD inattivo dalla modalità UGS alla modalità RTPS.

Il valore predefinito del parametro threshold-in-seconds è 10 secondi. I flussi del servizio UGS-AD in genere possiedono gli attributi di un flusso del servizio UGS, l'intervallo di polling nominale e l'attributo di jitter poll tollerato associato ai flussi del servizio RTPS.

Servizio di polling non in tempo reale (nRTPS)

La modalità di programmazione nRTPS (non real time polling service) è essenzialmente la stessa di RTPS, ad eccezione del fatto che nRTPS è generalmente associato a servizi non interattivi come i trasferimenti di file. La componente non in tempo reale può implicare che l'intervallo di polling nominale per le opportunità di richiesta della larghezza di banda unicast non sia esattamente regolare o possa verificarsi a una velocità inferiore a uno al secondo.

Alcuni operatori di rete via cavo possono scegliere di utilizzare nRTPS anziché i flussi di servizi RTPS per trasmettere il traffico di segnalazione vocale.

Algoritmi di programmazione

Prima di una discussione sulle specifiche dello scheduler conforme a DOCSIS e dello scheduler delle code a bassa latenza, è necessario comprendere i compromessi da raggiungere per determinare le caratteristiche di uno scheduler a monte. Sebbene la discussione sugli algoritmi di pianificazione si basi principalmente sulla modalità di pianificazione UGS, la discussione si applica ugualmente ai servizi di stile RTPS.

Quando si decide come pianificare i flussi di servizio UGS, non ci sono molte opzioni flessibili. Non è possibile impostare l'utilità di pianificazione in modo che modifichi le dimensioni o l'intervallo di concessione dei flussi del servizio UGS, in quanto tale modifica provoca un errore completo delle chiamate VoIP. Se tuttavia si modifica l'effetto jitter, le chiamate funzionano, anche se è possibile che la latenza della chiamata sia maggiore. Inoltre, la modifica del numero massimo di chiamate consentite in un upstream non influisce sulla qualità delle singole chiamate. Di conseguenza, quando si pianificano grandi quantità di flussi di servizi UGS, tenere in considerazione i due fattori principali seguenti:

• Variazione

• Capacità flusso di servizio UGS per upstream

Variazione

Un jitter di concessione tollerato è specificato come uno degli attributi di un flusso di servizio UGS o RTPS. Tuttavia, il supporto simultaneo di alcuni flussi di servizi con jitter tollerato molto basso e altri con quantità molto elevate di jitter può essere inefficiente. In generale, è necessario scegliere in modo uniforme il tipo di variazione che il servizio genera in un upstream.

Se sono richiesti bassi livelli di variazione, lo scheduler deve essere rigido e non flessibile quando pianifica le sovvenzioni. Di conseguenza, l'utilità di pianificazione deve porre restrizioni al numero di flussi di servizi UGS supportati su un upstream.

I livelli di jitter non devono sempre essere estremamente bassi per i normali VoIP consumer, in quanto la tecnologia di buffer di jitter è in grado di compensare gli alti livelli di jitter. I moderni buffer di jitter VoIP adattivi sono in grado di compensare oltre 150 ms di jitter. Tuttavia, una rete VoIP aggiunge la quantità di buffer che si verifica alla latenza dei pacchetti. Livelli elevati di latenza possono contribuire a peggiorare l'esperienza VoIP.

Capacità flusso servizio UGS per upstream

Gli attributi del livello fisico quali la larghezza del canale, lo schema di modulazione e la forza di correzione degli errori determinano la capacità fisica di un upstream. Tuttavia, il numero di flussi di servizi UGS simultanei che l'upstream può supportare dipende anche dall'algoritmo dell'utilità di pianificazione.

Se non sono necessari livelli di jitter estremamente bassi, è possibile ridurre la rigidità dell'utilità di pianificazione e provvedere a un numero maggiore di flussi di servizi UGS che l'upstream può supportare contemporaneamente. È possibile ottenere una maggiore efficienza del traffico non vocale nella parte a monte riducendo i requisiti di jitter.

Nota: la presenza di algoritmi di programmazione diversi può consentire a un particolare canale a monte di supportare diversi numeri di flussi di servizi UGS e RTPS. Tuttavia, tali servizi non possono utilizzare il 100% della capacità a monte in un sistema DOCSIS. Infatti, il canale a monte deve dedicare una parte al traffico di gestione DOCSIS, ad esempio i messaggi di manutenzione iniziali utilizzati dai modem via cavo per stabilire il contatto iniziale con il CMTS, e il traffico keepalive per la manutenzione della stazione, utilizzato per garantire che i modem via cavo possano mantenere la connettività al CMTS.

Scheduler compatibile DOCSIS

Lo scheduler conforme a DOCSIS è il sistema predefinito per la pianificazione dei servizi a monte su un Cisco uBR CMTS. Questa utilità di pianificazione è stata progettata per ridurre al minimo il tremolio dei flussi di servizi UGS e RTPS. Tuttavia, questo scheduler consente di mantenere un certo grado di flessibilità al fine di ottimizzare il numero di chiamate UGS simultanee per upstream.

Lo scheduler conforme a DOCSIS prealloca il tempo upstream in anticipo per i flussi del servizio UGS. Prima di programmare altre allocazioni di larghezza di banda, il CMTS riserva tempo per le concessioni che appartengono a flussi di servizi UGS attivi per garantire che nessuno degli altri tipi di flussi di servizi o traffico sposti le concessioni UGS e causi un jitter significativo.

Se il CMTS riceve richieste di larghezza di banda per conto dei flussi del servizio di miglior sforzo, il CMTS deve programmare il tempo di trasmissione per i flussi del servizio di miglior sforzo intorno alle sovvenzioni UGS preassegnate in modo da non incidere sulla programmazione tempestiva di ogni sovvenzione UGS.

Configurazione

Lo scheduler compatibile DOCSIS è l'unico algoritmo upstream disponibile per il software Cisco IOS versione 12.3(9a)BCx e precedenti. L'utilità di pianificazione non richiede pertanto comandi di configurazione per l'attivazione.

Per il software Cisco IOS versione 12.3(13a)BC e successive, lo scheduler conforme a DOCSIS è uno dei due algoritmi alternativi, ma è impostato come scheduler predefinito. È possibile abilitare lo scheduler conforme a DOCSIS per uno, tutti o alcuni dei seguenti tipi di pianificazione:

• UGS

• RTPS

• NRTPS

È possibile abilitare in modo esplicito lo scheduler compatibile con DOCSIS per ognuno di questi tipi di pianificazione con il tipo di pianificazione cavo a monte-porta [nrtps] | rtps | ugs] mode docsis cable interface.

L'utilizzo di una pianificazione compatibile con DOCSIS fa parte della configurazione predefinita. Pertanto, è necessario eseguire questo comando solo se si torna all'algoritmo di programmazione delle code a bassa latenza non predefinito. Per ulteriori informazioni, vedere la sezione Utilità di pianificazione di Accodamento a bassa latenza.

Controllo ammissione

Un grande vantaggio dello scheduler compatibile con DOCSIS è che questo scheduler assicura che i flussi del servizio UGS non sovrascrivano la sottoscrizione upstream. Se è necessario stabilire un nuovo flusso di servizio UGS e lo scheduler scopre che non è possibile eseguire una programmazione preliminare delle concessioni perché non è lasciato spazio, il CMTS rifiuta il nuovo flusso di servizio UGS. Se i flussi di servizi UGS che trasmettono il traffico VoIP sono autorizzati a sovrascrivere un canale a monte, la qualità di tutte le chiamate VoIP diminuisce notevolmente.

Per dimostrare in che modo lo scheduler conforme a DOCSIS garantisce che i flussi del servizio UGS non sovrascrivano mai la versione a monte, fare riferimento alle figure in questa sezione. Le figure 7, 8 e 9 mostrano i tempi di assegnazione della larghezza di banda.

In tutte queste figure, le sezioni a colori con motivi mostrano il momento in cui i modem via cavo ricevono sovvenzioni per conto dei rispettivi flussi di servizi UGS. Durante tale periodo non possono verificarsi altre trasmissioni upstream da altri modem via cavo. La parte grigia della linea temporale è ancora larghezza di banda non allocata. I modem via cavo utilizzano questo tempo per trasmettere le richieste di larghezza di banda. Il CMTS può utilizzare questo periodo di tempo per pianificare altri tipi di servizi.

Figura 7 - Scheduler compatibile con DOCSIS pre-pianifica tre flussi di servizi UGS

Aggiungere altri due flussi del servizio UGS con le stesse dimensioni e lo stesso intervallo di concessione. Tuttavia, l'utilità di pianificazione non ha problemi a pre-pianificarle.

Figura 8 - Scheduler compatibile con DOCSIS pre-pianifica cinque flussi di servizi UGS

Se si aggiungono altri due flussi di servizi UGS, si esaurisce tutta la larghezza di banda a monte disponibile.

Figura 9 - I flussi del servizio UGS utilizzano tutta la larghezza di banda upstream disponibile

Ovviamente, lo scheduler non può ammettere ulteriori flussi di servizi UGS qui. Pertanto, se un altro flusso di servizio UGS tenta di diventare attivo, lo scheduler conforme a DOCSIS si rende conto che non c'è spazio per ulteriori concessioni e impedisce l'istituzione di tale flusso di servizio.

Nota: è impossibile riempire completamente un upstream con flussi di servizio UGS come visto in questa serie di figure. L'utilità di pianificazione deve supportare altri tipi importanti di traffico, ad esempio la manutenzione delle stazioni, i pacchetti keepalive e il traffico dati massimo sforzo. Inoltre, la garanzia di evitare sottoscrizioni in eccesso con lo scheduler conforme a DOCSIS si applica solo se tutte le modalità di pianificazione del flusso di servizio, ossia UGS, RTPS e nRTPS, utilizzano lo scheduler conforme a DOCSIS.

Sebbene non sia necessaria una configurazione esplicita del controllo di ammissione quando si utilizza lo scheduler conforme a DOCSIS, Cisco consiglia di verificare che l'utilizzo del canale a monte non raggiunga livelli che possano influire negativamente sul traffico indirizzato al miglior tentativo. Cisco consiglia inoltre di non superare il 75% dell'utilizzo totale del canale a monte per periodi di tempo significativi. Questo è il livello di utilizzo a monte in cui i servizi di massimo sforzo iniziano a sperimentare una latenza molto più elevata e un throughput più lento. I servizi UGS funzionano ancora, indipendentemente dall'utilizzo a monte.

Per limitare la quantità di traffico ammesso su un particolare upstream, configurare il controllo dell'ammissione per i flussi di UGS, RTPS, NRTPS, UGS-AD o del servizio "Best Esortium" con il comando globale, per interfaccia di cavo o per upstream. Il parametro più importante è il campo percentuale-soglia-esclusiva.

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]

I parametri sono i seguenti:

• [upstream <numero-upstream>]: Specificate questo parametro se desiderate applicare il comando a una particolare interfaccia a monte anziché a un'interfaccia di cavo o a livello globale.

• <UGS|AD-UGS|RTPS|NRTPS|BE>: Questo parametro specifica la modalità di programmazione dei flussi di servizio a cui si desidera applicare il controllo ammissione.

• <percentuale soglia secondaria>: Questo parametro indica la percentuale di utilizzo a monte da parte del tipo di pianificazione configurato in corrispondenza del quale viene inviato un piccolo allarme a una stazione di gestione di rete.

• <percentuale soglia principale>: Questo parametro specifica la percentuale di utilizzo a monte per il tipo di pianificazione configurato in corrispondenza del quale un allarme principale viene inviato a una stazione di gestione di rete. Questo valore deve essere superiore al valore impostato per il parametro <minor-threshold-percent>.

• <percentuale-soglia-esclusiva>: Questo parametro rappresenta la percentuale di utilizzo a monte riservata in modo esclusivo per il tipo di programmazione specificato. Se non si specifica il valore per <non-excl-threshold-percent>, questo valore rappresenta il limite massimo di utilizzo per questo tipo di flusso di servizio. Questo valore deve essere maggiore del valore <major-threshold-percent>.

• <percentuale-soglia-non-excl>: Questo parametro rappresenta la percentuale di utilizzo a monte superiore alla <percentuale-soglia-esclusiva> che questo tipo di programmazione può utilizzare, a condizione che non venga già utilizzata da un altro tipo di programmazione.

Si supponga, ad esempio, di voler limitare i flussi del servizio UGS al 60% della larghezza di banda upstream totale disponibile. Si supponga inoltre di avere stazioni di gestione di rete notificate che se la percentuale di utilizzo a monte dovuta ai flussi di servizio UGS è aumentata oltre il 40%, è necessario inviare un piccolo allarme e oltre il 50%, deve essere inviato un grande allarme. Immettere questo comando

cavo ammissione-controllo usa-larghezza di banda tipo pianificazione UGS minore 40 maggiore 50 esclusivo 60

Pianificazione del traffico in base alle risorse tramite la frammentazione

Il modulo di pianificazione compatibile con DOCSIS pianifica semplicemente il traffico in base alle sovvenzioni UGS o RTPS preallocate. Le figure in questa sezione dimostrano questo comportamento.

Figura 10 - Programmazione in sospeso per l'impegno massimo

La Figura 10 mostra che a monte sono presenti tre flussi di servizio UGS con le stesse dimensioni di concessione e lo stesso intervallo di concessione prepianificato. Il flusso a monte riceve le richieste di larghezza di banda per conto di tre flussi di servizio distinti, A, B e C. Il flusso di servizio A richiede una quantità media di tempo di trasmissione, il flusso di servizio B richiede una piccola quantità di tempo di trasmissione e il flusso di servizio C richiede una grande quantità di tempo di trasmissione.

Assegnare la stessa priorità a ciascuno dei flussi di servizi relativi alle risorse ottimali. Si supponga inoltre che il CMTS riceva le richieste di larghezza di banda per ognuna di queste concessioni nell'ordine A, B e quindi C. Il CMTS alloca prima il tempo di trasmissione per le concessioni nello stesso ordine. La Figura 11 mostra come lo scheduler conforme a DOCSIS alloca tali concessioni.

Figura 11 - Concessioni di ottimizzazione dell'impegno programmate per le concessioni di flusso del servizio UGS fisso

Lo scheduler è in grado di comprimere le sovvenzioni per A e B nel gap tra i primi due blocchi di sovvenzioni UGS. Tuttavia, la sovvenzione per C è maggiore di qualsiasi altra carenza disponibile. Pertanto, lo scheduler conforme a DOCSIS suddivide la sovvenzione per C intorno al terzo blocco di sovvenzioni UGS in due sovvenzioni più piccole denominate C1 e C2. La frammentazione evita ritardi per le sovvenzioni UGS e assicura che queste sovvenzioni non siano soggette a jitter che il traffico di massimo sforzo causa.

La frammentazione aumenta leggermente il sovraccarico del protocollo DOCSIS associato alla trasmissione dei dati. Per ciascun frammento aggiuntivo trasmesso, deve essere trasmesso anche un insieme extra di intestazioni DOCSIS. Tuttavia, senza frammentazione, lo scheduler non può interlasciare in modo efficiente le concessioni di massimo sforzo tra concessioni UGS fisse. Non è possibile frammentare i modem via cavo in modalità DOCSIS 1.0.

Priority

L'utilità di pianificazione compatibile con DOCSIS posiziona i privilegi in attesa di allocazione in una coda in base alla priorità del flusso di servizio a cui appartiene il privilegio. Sono disponibili otto priorità DOCSIS, di cui zero è il più basso e sette il più alto. A ognuna di queste priorità è associata una coda.

L'utilità di pianificazione compatibile con DOCSIS utilizza un meccanismo di coda a priorità ridotta per determinare quando vengono allocate le concessioni con priorità diversa al tempo di trasmissione. In altre parole, tutti i privilegi archiviati nelle code con priorità alta devono essere serviti prima dei privilegi nelle code con priorità inferiore.

Si supponga, ad esempio, che lo scheduler conforme a DOCSIS riceva cinque concessioni in un breve periodo nell'ordine A, B, C, D, E e F. Lo scheduler accoda ognuno dei concessioni in coda che corrispondono alla priorità del flusso di servizio del concessionario.

Figura 12 - Sovvenzioni con priorità diverse

Lo scheduler conforme a DOCSIS pianifica le concessioni di massimo sforzo in base alle concessioni UGS pre-pianificate che vengono visualizzate come blocchi strutturati nella Figura 12. La prima azione intrapresa dallo scheduler conforme a DOCSIS è controllare la coda con la massima priorità. In questo caso la coda con priorità 7 dispone di privilegi pronti per la pianificazione. Lo scheduler procede e assegna il tempo di trasmissione per le sovvenzioni B ed E. Si noti che la sovvenzione E deve essere frammentata in modo che non interferisca con i tempi delle sovvenzioni UGS preassegnate.

Figura 13 - Assegnazioni priorità pianificazione 7

L'utilità di pianificazione verifica che tutti i concessionari con priorità 7 ricevano il tempo di trasmissione. Quindi, lo scheduler controlla la coda priorità 6. In questo caso, la coda con priorità 6 è vuota, quindi l'utilità di pianificazione passa alla coda con priorità 5 che contiene la concessione C.

Figura 14 - Assegnazione priorità di pianificazione 5

L'utilità di pianificazione procede quindi in modo simile attraverso le code con priorità inferiore fino a quando tutte le code sono vuote. Se è necessario pianificare un numero elevato di concessioni, le nuove richieste di larghezza di banda possono raggiungere il CMTS prima che lo scheduler conforme a DOCSIS finisca di allocare il tempo di trasmissione a tutte le concessioni in sospeso. Si supponga che il CMTS riceva una richiesta di larghezza di banda G con priorità 6 in questo punto dell'esempio.

Figura 15 - Sovvenzione con priorità 6 in coda

Anche se le concessioni A, F e D attendono più a lungo della nuova concessione G in coda, l'utilità di pianificazione compatibile con DOCSIS deve successivamente allocare il tempo di trasmissione a G perché G ha la priorità più alta. Ciò significa che le successive allocazioni della larghezza di banda dello scheduler compatibile con DOCSIS saranno G, A e quindi D (vedere la Figura 16).

Figura 16 - Pianificazione delle sovvenzioni con priorità 6 e 2

Il privilegio successivo da programmare è F, se si presume che nessun privilegio con priorità più alta entri nel sistema di coda nel tempo medio.

L'utilità di pianificazione compatibile con DOCSIS ha altre due code non menzionate negli esempi. La prima coda è la coda utilizzata per pianificare il traffico keepalive per la manutenzione periodica della stazione in modo da mantenere online i modem via cavo. Questa coda viene utilizzata per pianificare le opportunità per i modem via cavo di inviare il traffico keepalive periodico CMTS. Quando l'utilità di pianificazione compatibile con DOCSIS è attiva, questa coda viene servita prima di tutte le altre code. La seconda è una coda per le concessioni allocate ai flussi di servizi con una tariffa riservata minima (CIR, Minimum Reserved Rate) specificata. L'utilità di pianificazione considera questa coda CIR come una coda con priorità 8 per garantire che i flussi di servizio con una velocità approvata ricevano il throughput minimo richiesto.

Concessioni DOCSIS 1.0 non frammentabili

Dagli esempi riportati nella sezione precedente, talvolta è necessario frammentare le sovvenzioni in più parti per garantire che l'instabilità non venga indotta nelle sovvenzioni UGS preassegnate. Questo può essere un problema per i modem via cavo che operano in modalità DOCSIS 1.0 su segmenti a monte con una quantità significativa di traffico UGS, in quanto un modem via cavo DOCSIS 1.0 può chiedere di trasmettere un frame troppo grande per essere adattato alla successiva opportunità di trasmissione disponibile.

Di seguito è riportato un altro esempio, in cui si presume che lo scheduler riceva i nuovi privilegi A e B nell'ordine indicato. Si supponga inoltre che entrambe le concessioni abbiano la stessa priorità, ma che la concessione B sia relativa a un modem via cavo che funziona in modalità DOCSIS 1.0.

Figura 17 - Concessioni in sospeso DOCSIS 1.1 e DOCSIS 1.0

L'utilità di pianificazione tenta di allocare prima il tempo per la concessione A. L'utilità di pianificazione tenta quindi di allocare la successiva opportunità di trasmissione disponibile alla concessione B. Tuttavia, non vi è spazio per la concessione B di rimanere non frammentata tra A e il blocco successivo di sovvenzioni UGS (vedere la Figura 18).

Figura 18 - Concessione B di DOCSIS 1.0 posticipata

Per questo motivo, la sovvenzione B è rinviata fino a dopo il secondo blocco di sovvenzioni UGS in cui vi è spazio per la sovvenzione B per adattarsi. Si noti che è ora presente spazio inutilizzato prima della concessione del secondo blocco di UGS. I modem via cavo utilizzano questo tempo per trasmettere le richieste di larghezza di banda al CMTS, ma ciò rappresenta un utilizzo inefficiente della larghezza di banda.

Rivedere questo esempio e aggiungere altri due flussi di servizio UGS allo scheduler. Mentre la sovvenzione A può essere frammentata, non vi è alcuna possibilità di programmare la sovvenzione B non frammentabile perché la sovvenzione B è troppo grande per essere contenuta tra i blocchi di sovvenzioni UGS. In questo caso, il modem via cavo associato alla concessione B non è in grado di trasmettere frame di grandi dimensioni nella parte a monte.

Figura 19 - Impossibile pianificare DOCSIS 1.0 Grant B

È possibile consentire allo scheduler di spingere semplicemente fuori, o leggermente ritardare un blocco di sovvenzioni UGS per fare spazio per la sovvenzione B, ma questa azione causa instabilità nel flusso del servizio UGS. Per il momento, se pensate di voler ridurre al minimo lo jitter, questa è una soluzione inaccettabile.

Per risolvere questo problema con le grandi concessioni DOCSIS 1.0 non frammentabili, lo scheduler compatibile con DOCSIS pre-pianifica periodicamente blocchi di tempo upstream grandi quanto il frame più grande che un modem via cavo DOCSIS 1.0 può trasmettere. Lo scheduler esegue questa operazione prima della pianificazione di qualsiasi flusso del servizio UGS. Questa volta è tipicamente l'equivalente di circa 2000 byte di trasmissione a monte, ed è chiamato il "Unfragmentable Block" o il "UGS free block".

L'utilità di pianificazione compatibile con DOCSIS non concede alcuna concessione di stile UGS o RTPS negli orari assegnati al traffico non frammentabile, in modo da garantire sempre la possibilità di pianificare concessioni DOCSIS 1.0 di grandi dimensioni. In questo sistema, riservando tempo al traffico DOCSIS 1.0 non frammentabile si riduce il numero di flussi di servizi UGS che l'upstream può supportare contemporaneamente.

La Figura 20 mostra il blocco non frammentabile in blu e quattro flussi di servizi UGS con le stesse dimensioni e lo stesso intervallo di concessione. Impossibile aggiungere un altro flusso di servizio UGS con le stesse dimensioni di concessione e lo stesso intervallo di concessione a monte. Non è consentito pianificare concessioni UGS nell'area blu a blocchi non frammentabili.

Figura 20 - Il blocco non frammentabile: Non possono essere accettate altre sovvenzioni UGS

Anche se il blocco non frammentabile è programmato meno spesso del periodo di concessione UGS, questo blocco tende a causare uno spazio di larghezza di banda non allocata grande come se stesso tra tutti i blocchi di UGS concessioni. In questo modo è possibile pianificare grandi sovvenzioni non frammentabili.

Tornando all'esempio del privilegio A e di DOCSIS 1.0 Grant B, è possibile notare che con il blocco non frammentabile, lo scheduler compatibile con DOCSIS può ora pianificare correttamente il privilegio B dopo il primo blocco di concessioni UGS.

Figura 21 - Pianificazione delle sovvenzioni con l'uso del blocco non frammentabile

Anche se la programmazione della sovvenzione B DOCSIS 1.0 è stata completata, esiste ancora una piccola differenza di spazio inutilizzato tra la sovvenzione A e il primo blocco di sovvenzioni UGS. Questa lacuna rappresenta un utilizzo non ottimale della larghezza di banda e dimostra perché è necessario utilizzare modem cablati in modalità DOCSIS 1.1 quando si distribuiscono servizi UGS.

Cavo default-phy-burst

Per impostazione predefinita, su un Cisco uBR CMTS, il burst più grande che un modem via cavo può trasmettere è 2000 byte. Questo valore per la dimensione massima della frammentazione a monte viene utilizzato per calcolare la dimensione del blocco non frammentabile come viene utilizzato dallo scheduler conforme a DOCSIS.

Per modificare le dimensioni massime della frammentazione, usare il comando cable default-phy-burst max-bytes-allowed-in-burst per cable interface.

Il parametro <max-bytes-allowed-in-burst> ha un intervallo da 0 a 4096 byte e un valore predefinito di 2000 byte. Esistono alcune limitazioni importanti relative alla modalità di impostazione di questo valore se si desidera modificare il valore da quello predefinito.

Per le interfacce di cavo della scheda di linea MC5x20S, non impostare questo parametro su un valore superiore a quello predefinito di 2000 byte. Per tutti gli altri tipi di schede di linea, incluse le schede MC28U, MC5x20U e MC5x20H, è possibile impostare questo parametro su un valore di 4000 byte.

Non impostare il parametro <max-bytes-allowed-in-burst> su un valore inferiore alle dimensioni del singolo frame Ethernet più grande che un modem via cavo può dover trasmettere, incluso il sovraccarico DOCSIS o 802.1q. Ciò significa che questo valore non deve essere inferiore a circa 1540 byte.

Se si imposta <max-bytes-allowed-in-burst> sul valore speciale 0, il CMTS non utilizza questo parametro per limitare le dimensioni di una frammentazione a monte. È necessario configurare altre variabili per limitare le dimensioni della frammentazione a monte a un limite ragionevole, ad esempio l'impostazione della frammentazione massima concatenata nel file di configurazione DOCSIS o il comando cable upstream fragment-force.

Quando si modifica la dimensione di burst a fil di default del cavo per modificare la dimensione massima di burst a monte, anche la dimensione del blocco UGS libero viene modificata di conseguenza. La Figura 22 mostra che se si riduce l'impostazione di default-phy-burst del cavo, le dimensioni del blocco UGS libero si riducono e di conseguenza lo scheduler conforme a DOCSIS può consentire più chiamate UGS su un upstream. In questo esempio, ridurre l'impostazione predefinita del cavo phy-burst dall'impostazione predefinita di 2000 a un'impostazione inferiore di 1600 per consentire spazio per un ulteriore flusso di servizio UGS per diventare attivo.

Figura 22 - Riduzione dei burst a fil di default riduce le dimensioni del blocco non frammentabile

La riduzione delle dimensioni massime consentite per la frammentazione con il comando cable default-phy-burst può ridurre leggermente l'efficienza della parte a monte per ottimizzare il traffico, in quanto questo comando riduce il numero di frame che possono essere concatenati in una frammentazione. Una riduzione di questo tipo può anche comportare un aumento dei livelli di frammentazione quando nella fase a monte sono attivi più flussi di servizi UGS.

Dimensioni ridotte della frammentazione concatenata possono influire sulla velocità di caricamento dei dati in un flusso di servizio ottimale. Questo accade perché la trasmissione di più frame alla volta è più veloce della trasmissione di una richiesta di larghezza di banda per ogni frame. Livelli di concatenazione ridotti possono anche influire sulla velocità dei download a causa della minore capacità del modem via cavo di concatenare un grande numero di pacchetti TCP ACK che viaggiano nella direzione upstream.

A volte, le dimensioni massime dello scoppio configurate nella configurazione IUC "lunga" del profilo di modulazione del cavo applicato a un flusso a monte possono determinare le dimensioni massime dello scoppio a monte. Questa condizione si può verificare se le dimensioni massime della frammentazione nel profilo di modulazione sono inferiori al valore predefinito del cavo phy-burst in byte. Questo è uno scenario raro. Tuttavia, se si aumenta il parametro di default-phy-burst del cavo rispetto al valore predefinito di 2000 byte, controllare le dimensioni massime della frammentazione nella configurazione della funzione IUC "long" per assicurarsi che non limiti le frammentazioni.

L'altro limite alle dimensioni di burst a monte è che in un burst è possibile trasmettere un massimo di 255 minislot. Questo può diventare un fattore se le dimensioni del minislot sono impostate sul minimo di 8 byte. Il minislot è l'unità di trasmissione upstream più piccola in una rete DOCSIS e in genere equivale a 8 o 16 byte.

Variazione slot non frammentabile

Un altro modo per regolare lo scheduler conforme a DOCSIS in modo da consentire un numero più elevato di flussi UGS simultanei su un upstream è quello di consentire allo scheduler di introdurre piccole quantità di jitter sui flussi del servizio UGS in caso di grandi burst di traffico di massimo sforzo non frammentabile. A tale scopo, usare il comando cable upstream numero-upstream unfrag-slot-jitter limit val cable interface.

In questo comando, <val> viene specificato in microsecondi e ha un valore predefinito pari a zero, il che significa che il comportamento predefinito per l'utilità di pianificazione compatibile con DOCSIS è quello di non consentire concessioni non frammentabili per causare jitter per i flussi di servizi UGS e RTPS. Quando si specifica un jitter di slot non frammentabile positivo, l'utilità di pianificazione compatibile con DOCSIS può ritardare le concessioni UGS di un massimo di <val> microsecondi da quando la concessione UGS deve essere pianificata idealmente e quindi causare jitter.

Questo ha lo stesso effetto della riduzione della dimensione del blocco non frammentabile di una lunghezza equivalente al numero di microsecondi specificato. Ad esempio, se si mantiene il valore predefinito per default-phy-burst (2000 byte) e si specifica un valore di 1000 microsecondi per il jitter di slot non frammentabile, il blocco non frammentabile si riduce (vedere Figura 23).

Figura 23 - La variazione degli slot non frammentabili pari a zero riduce la dimensione dei blocchi non frammentabili

Nota: il numero di byte a cui corrisponde l'ora di 1000 microsecondi dipende dalla velocità con cui il canale a monte viene configurato per funzionare tramite le impostazioni della larghezza del canale e dello schema di modulazione.

Nota: con uno jitter non frammentabile pari a zero, lo scheduler conforme a DOCSIS è in grado di aumentare il numero di concessioni UGS supportate da un upstream in modo simile a una riduzione della frammentazione predefinita.

Nota: tornare all'esempio con un file DOCSIS 1.1 con privilegi A di grandi dimensioni seguito da un file DOCSIS 1.0 con privilegi B di grandi dimensioni e non frammentabili da pianificare su un file upstream. Il jitter non frammentabile viene impostato su 1000 microsecondi. Lo scheduler conforme a DOCSIS si comporta come mostrato nelle figure in questa sezione.

Nota: in primo luogo, lo scheduler alloca il tempo di trasmissione per il privilegio A. A tale scopo, lo scheduler suddivide il privilegio in concessioni A₁ e A₂ in modo che i concessioni si adattino prima e dopo il primo blocco di concessioni UGS. Per pianificare la concessione B, l'utilità di pianificazione deve decidere se l'utilità di pianificazione può adattare il blocco non frammentabile nello spazio libero dopo la concessione A₂ senza alcun ritardo al successivo blocco di sovvenzioni UGS di un valore superiore alla jitter non frammentabile configurata dello slot di 1000 microsecondi. Queste cifre mostrano che se lo scheduler posiziona la concessione B accanto alla concessione A₂, il blocco successivo di traffico UGS subisce un ritardo, o una riduzione, di oltre 1500 microsecondi. Pertanto, lo scheduler non può assegnare la sovvenzione B direttamente dopo la sovvenzione A₂.

Figura 24 - Concessione B non pianificabile accanto alla concessione A2.

Il passaggio successivo per lo scheduler compatibile con DOCSIS è quello di vedere se il successivo gap disponibile può supportare la sovvenzione B. La Figura 25 mostra che se lo scheduler posiziona la sovvenzione B dopo il secondo blocco di concessioni UGS, il terzo blocco non viene ritardato di oltre il jitter non frammentabile configurato di 1000 microsecondi.

Figura 25 - Concessione B programmata dopo il secondo blocco di sovvenzioni UGS

Poiché l'inserimento del privilegio B a questo punto non causa un'inaccettabile alterazione delle concessioni UGS, lo scheduler conforme a DOCSIS inserisce il privilegio B e ritarda leggermente il seguente blocco di concessioni UGS.

Figura 26 - Pianificazione della sovvenzione B non frammentabile e ritardo delle sovvenzioni UGS

Mostra output comando

È possibile utilizzare il comando show interface cable interface-number mac-scheduler-upstream-number per verificare lo stato corrente dell'utilità di pianificazione compatibile con DOCSIS. Di seguito è riportato un esempio dell'output di questo comando come mostrato su un Cisco uBR7200VXR con una scheda di linea MC28U.

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

In questa sezione vengono illustrate le singole righe dell'output di questo comando. In questa sezione del documento si presume che l'utente abbia già familiarità con i concetti generali della pianificazione a monte DOCSIS.

• Scheduler MAC DOCSIS 1.1 per Cable3/0/U0

  La prima riga dell'output del comando indica la porta a monte a cui si riferiscono i dati.

• Coda[Ring Polls] 0/128, 0 drop, max 1

  Questa riga indica lo stato della coda che invia i pacchetti keepalive o che includono opportunità di manutenzione all'utilità di pianificazione compatibile con DOCSIS. 0/128 indica che attualmente nella coda sono presenti zero opportunità di variazione in sospeso su un massimo di 128.

  Il contatore delle eliminazioni indica il numero di volte in cui non è stato possibile mettere in coda un'opportunità di intervallo perché la coda era già piena, ovvero 128 opportunità di intervallo in sospeso. Le cadute qui si verificherebbero solo probabilmente su un upstream con un numero estremamente elevato di modem via cavo online e se ci fosse un grande numero di flussi di servizi UGS o RTPS attivi. Questa coda viene servita con la priorità più alta quando viene eseguita l'utilità di pianificazione dei reclami DOCSIS. Pertanto, le cadute in questa coda sono altamente improbabili, ma molto probabilmente indicano una grave sovrassegnazione del canale a monte.

  Il contatore max indica il numero massimo di elementi presenti e presenti nella coda dall'ultima esecuzione del comando show interface cable mac-scheduler. Idealmente dovrebbe rimanere il più vicino possibile allo zero.

• Coda[concessioni CIR] 0/64, 0 gocce, max 0

  Questa riga indica lo stato della coda che gestisce le concessioni per i flussi di servizio con una velocità di traffico riservata minima specificata. In altre parole, questo servizio di coda concede per i flussi di servizio CIR (Committed Information Rate). 0/64 indica che attualmente nella coda sono presenti zero su un massimo di 64 concessioni in sospeso.

  Il contatore delle eliminazioni indica quante volte non è stato possibile mettere in coda una concessione CIR perché la coda era già piena, ovvero 64 concessioni in coda. Le cadute possono accumularsi qui se i flussi di servizi in stile UGS, RTPS e CIR sovrascrivono l'upstream, e possono indicare la necessità di un controllo di ammissione più rigoroso.

  Il contatore max indica il numero massimo di concessioni nella coda dall'ultima esecuzione del comando show interface cable mac-scheduler. Questa coda ha la seconda priorità più alta, quindi l'utilità di pianificazione compatibile con DOCSIS alloca tempo per gli elementi della coda prima che l'utilità di pianificazione gestisca le code di massimo sforzo.

• Queue[Concessioni BE(w)] x/64, y drops, max z

  Le otto voci successive mostrano lo stato delle code che gestiscono le concessioni per i flussi di servizio da priorità 7 a 0. I campi in queste voci hanno lo stesso significato dei campi nella voce di coda CIR. La prima coda da servire in questo gruppo è la coda BE (7) e l'ultima da servire è la coda BE (0).

  Le interruzioni possono verificarsi in queste code se un livello di priorità più alto del traffico consuma tutta la larghezza di banda upstream o se si verifica una sovrassegnazione della upstream con flussi di servizio UGS, RTPS e CIR. Ciò può indicare la necessità di rivalutare le priorità DOCSIS per i flussi di servizi di elevato volume o la necessità di un controllo dell'ammissione più severo a monte.

• Slot Req 36356057

  Questa riga indica il numero di opportunità di richiesta della larghezza di banda annunciate dall'attivazione dell'upstream. Questo numero deve essere in continuo aumento.

• Slot dati/richieste 185165

  Benché il nome suggerisca che questo campo mostra il numero di opportunità di richiesta o di dati pubblicizzate a monte, questo campo mostra in realtà il numero di periodi pubblicizzati dal CMTS per facilitare la funzionalità avanzata di gestione dello spettro. Questo contatore dovrebbe aumentare per i flussi a monte sulle schede di linea MC28U e MC520.

  Le opportunità di richiesta/dati sono uguali alle opportunità di richiesta della larghezza di banda, con la differenza che in questi periodi anche i modem via cavo sono in grado di trasmettere piccoli picchi di dati. I Cisco serie uBR CMTS non pianificano al momento reali opportunità di richiesta/dati.

• Slot Init Mtn 514263

  Questa riga rappresenta il numero di opportunità di manutenzione iniziali annunciate dall'attivazione dell'upstream. Questo numero deve essere in continuo aumento. I modem via cavo che eseguono i primi tentativi di stabilire la connettività al CMTS utilizzano le opportunità di manutenzione iniziali.

• Slot Stn Mtn 314793

  Questa linea indica il numero di opportunità di manutenzione della stazione keepalive o range offerte a monte. Se a monte sono presenti modem via cavo in linea, questo numero deve aumentare continuamente.

• Short Grant Slot 12256, Long Grant Slot 4691

  Questa riga indica il numero di concessioni di dati offerte a monte. Se esistono modem via cavo che trasmettono dati a monte, questi numeri devono essere in continuo aumento.

• ATDMA Short Grant Slot 0, ATDMA Long Grant Slot 0, ATDMA UGS Grant Slot 0

  Questa riga rappresenta il numero di concessioni di dati offerte nella modalità ATDMA (Advanced Time Division Multiple Access) a monte. Se sono presenti modem via cavo in modalità DOCSIS 2.0 che trasmettono dati a monte, tali numeri devono essere in continuo aumento. Notare che ATDMA gestisce separatamente il traffico UGS.

• Awacs Slot 277629

  Questa riga indica il numero di periodi dedicati alla gestione avanzata dello spettro. Per una gestione avanzata dello spettro, il CMTS deve pianificare periodicamente orari in cui ciascun modem via cavo deve effettuare una breve trasmissione in modo che la funzione di analisi dello spettro interno possa valutare la qualità del segnale di ciascun modem.

• Conteggio frammentazioni 41

  Questa riga indica il numero totale di frammenti che la porta a monte è programmata per ricevere. Ad esempio, se un frame è stato frammentato in tre parti, il contatore verrà incrementato di tre.

• Test di frammentazione disabilitato

  Questa riga indica che il comando test cable fragmentation non è stato richiamato. Non utilizzare questo comando in una rete di produzione.

• Utilizzo medio canali upstream: 26%

  Questa riga mostra l'utilizzo corrente del canale a monte da parte delle trasmissioni di dati a monte. Sono incluse le trasmissioni effettuate tramite short, long, ATDMA short, ATDMA long e ATDMA UGS grant. Il valore viene calcolato ogni secondo come media mobile. Cisco consiglia di non superare il 75% su base estesa durante i periodi di massimo utilizzo. In caso contrario, gli utenti finali possono iniziare a notare i problemi di prestazioni con il massimo sforzo di traffico.

• Percentuale media di slot di conflitto: 73%

  Questa riga indica la percentuale di tempo upstream dedicato alle richieste di larghezza di banda. Ciò equivale alla quantità di tempo libero nella fase a monte e pertanto si riduce con l'aumento della percentuale di utilizzo medio del canale a monte.

• Percentuale media di intervalli iniziali: 2%

  Questa linea indica la percentuale di tempo a monte dedicata alle opportunità di range iniziali che i modem via cavo utilizzano quando tentano di stabilire la connettività iniziale con il CMTS. Questo valore deve sempre rimanere una bassa percentuale dell'utilizzo totale.

• Percentuale media di minislot persi nelle mappe in ritardo: 0%

  Questa linea indica la percentuale di tempo a monte non pianificato perché il CMTS non è stato in grado di trasmettere un messaggio MAP di allocazione della larghezza di banda ai modem via cavo in tempo. Questo parametro deve sempre essere vicino allo zero ma può iniziare a visualizzare valori più grandi su sistemi con un carico CPU estremamente elevato.

• Stato Rsv Tabella Schermata: Concessioni 0, Richieste 0

  Questa riga indica il numero di flussi di servizi di stile UGS (Grants) o RTPS (Request) con sovvenzioni preallocate nell'utilità di pianificazione compatibile DOCSIS, ma non ancora attivate. Questo si verifica quando si sposta un modem via cavo con flussi di servizi UGS o RTPS esistenti da un upstream all'altro tramite il bilanciamento del carico. Questa cifra si applica solo alle concessioni che utilizzano lo scheduler compatibile con DOCSIS e non lo scheduler LLQ.

• Stato Adm Tabella Schede: Sovvenzioni 6, Richieste 0, Util 27%

  Questa riga indica il numero di flussi di servizi di stile UGS (Grants) o RTPS (Request) per i quali sono state preallocate concessioni nello scheduler compatibile DOCSIS per questo upstream. Util è l'utilizzo stimato della larghezza di banda upstream totale disponibile per questi flussi di servizi. Questa cifra si applica solo alle concessioni che utilizzano lo scheduler compatibile con DOCSIS e non lo scheduler LLQ.

• <Tipo di pianificazione> : x SID, livello di prenotazione in bps y

  Questa riga indica il numero di flussi del servizio <tipo di programmazione> o di SID presenti nel flusso a monte e la quantità di larghezza di banda in bit al secondo riservata da tali flussi del servizio. Per ottimizzare l'impegno e i flussi di servizio di tipo RTPS, la larghezza di banda viene riservata solo se per il flusso di servizio è configurata una velocità riservata minima.

Vantaggi e svantaggi dello scheduler conforme a DOCSIS

L'obiettivo dello scheduler conforme a DOCSIS è quello di ridurre al minimo l'instabilità per i flussi del servizio in stile UGS e RTPS e anche per gestire burst non frammentabili di DOCSIS 1.0. Il compromesso raggiunto dall'utilità di pianificazione conforme a DOCSIS per raggiungere questi obiettivi è che il numero massimo di flussi di servizi UGS supportati per upstream è inferiore al massimo teorico che un DOCSIS upstream può supportare fisicamente e che il traffico corrispondente al massimo sforzo può essere soggetto a un grado di frammentazione.

Mentre lo scheduler conforme a DOCSIS supporta un numero leggermente inferiore al numero massimo teorico di flussi di servizi UGS simultanei su un upstream e mentre alcune altre implementazioni di pianificazione possono supportare più flussi di servizi UGS per upstream, è necessario concentrarsi sul trade-off.

Ad esempio, nessuna utilità di pianificazione può supportare flussi di servizi UGS senza jitter che occupano quasi il 100% della larghezza di banda di un canale upstream e supportano contemporaneamente frame concatenati grandi e non frammentabili dai modem DOCSIS 1.0. Per quanto riguarda la progettazione dello scheduler conforme a DOCSIS, è importante comprendere due aspetti.

• Il 75% è il massimo utilizzo a monte desiderato.

  Cisco ha rilevato che quando un upstream viene eseguito in modo coerente a un utilizzo superiore al 75%, incluso l'utilizzo dovuto ai flussi di servizi UGS, le prestazioni del traffico basate sul miglior sforzo iniziano a essere influenzate in modo significativo. Ciò significa che se i segnali UGS e VoIP consumano oltre il 75% della parte upstream, tutto il normale traffico IP trasmesso dai flussi di servizi best-force inizia a soffrire di una latenza aggiuntiva che causa una velocità di trasmissione e tempi di risposta notevolmente più bassi. Questo peggioramento delle prestazioni a livelli di utilizzo più elevati è una proprietà condivisa dalla maggior parte dei moderni sistemi di rete ad accesso multiplo, ad esempio Ethernet o LAN wireless.

• Quando si utilizza la larghezza del canale upstream tipicamente implementata di 3.2MHz, il programmatore compatibile con DOCSIS consente ai flussi di servizio UGS di utilizzare fino a circa il 75% del canale upstream. Questi flussi di servizio trasmettono chiamate VoIP G.711.

Questi due punti forniscono alcuni spunti sulle considerazioni di progettazione che sono state prese in considerazione quando è stata creata la pianificazione conforme a DOCSIS. Lo scheduler DOCSIS è stato progettato in modo che per i flussi di servizio UGS tipici (G.711) e con la larghezza del canale più comunemente implementata di 3,2 MHz, i limiti di chiamata per upstream inizino ad essere applicati a circa il 75% di utilizzo. Ciò significa che l'utilità di pianificazione riduce al minimo il tremolio e consente un numero ragionevole di flussi di servizi UGS a monte.

In altre parole, lo scheduler conforme a DOCSIS è stato progettato per funzionare correttamente nelle reti DOCSIS di produzione e non per consentire ai flussi di servizio UGS di utilizzare una percentuale eccessiva della larghezza di banda upstream. Questo scenario può verificarsi in uno scenario di test di laboratorio.

È possibile adattare lo scheduler conforme a DOCSIS per supportare un numero maggiore di chiamate UGS per upstream, anche se a scapito dello jitter UGS e dell'efficienza del traffico ottimale. Per questo motivo, è necessario ridurre il parametro phy-burst predefinito del cavo all'impostazione minima consigliata di 1540 byte. Per ottenere una maggiore densità di chiamate, impostate il cavo a monte unfrag-slot-jitter su un valore quale 2000 microsecondi. Tuttavia, Cisco sconsiglia generalmente queste impostazioni per una rete di produzione.

Un altro vantaggio del programmatore compatibile con DOCSIS è che non c'è alcun requisito obbligatorio che gli operatori CMTS configurino esplicitamente il controllo dell'ammissione per i flussi di servizi in stile UGS e RTPS. Questo perché il metodo di pianificazione pre-allocazione elimina la possibilità di sottoscrizioni in eccesso accidentali. Anche se questo è il caso, Cisco suggerisce ancora agli operatori di garantire che l'utilizzo totale a monte non superi il 75% per periodi estesi durante le ore di punta. Pertanto, Cisco consiglia di configurare il controllo dell'ammissione come best practice.

Uno svantaggio dello scheduler conforme a DOCSIS è che la posizione fissa delle concessioni UGS può richiedere la frammentazione delle concessioni di massimo sforzo quando l'utilizzo di UGS è elevato. In generale, la frammentazione non causa problemi di prestazioni evidenti, ma determina un leggero aumento della latenza per il traffico di massimo sforzo e un aumento del sovraccarico del protocollo presente sul canale a monte.

Un altro inconveniente è che quando i modem via cavo DOCSIS 1.0 vogliono effettuare trasmissioni a monte non frammentabili di grandi dimensioni, può verificarsi un ritardo prima che appaia un intervallo appropriato tra i blocchi di sovvenzioni UGS pre-pianificate. Ciò può anche causare un aumento della latenza per il traffico a monte DOCSIS 1.0 e un utilizzo non ottimale dei tempi di trasmissione a monte disponibili.

Infine, lo scheduler conforme a DOCSIS è progettato per funzionare al meglio in ambienti in cui tutti i flussi di servizi UGS condividono le stesse dimensioni e lo stesso intervallo di concessione. Ovvero, tutte le chiamate VoIP condividono lo stesso codec, come la pacchettizzazione G.711 da 10 ms o 20 ms, che si avrebbe in un tipico sistema Packetcable 1.0. In presenza di intervalli e dimensioni di concessione diversi, la capacità dell'utilità di pianificazione compatibile con DOCSIS di supportare un numero elevato di flussi di servizi UGS si riduce a monte. Inoltre, per alcune concessioni può verificarsi una quantità molto ridotta di instabilità (inferiore a 2 ms), in quanto lo scheduler tenta di interlasciare flussi di servizi UGS con periodi e dimensioni diversi.

Con la diffusione delle reti PacketCable MultiMedia (PCMM), può diventare più comune per una varietà di codec VoIP con vari intervalli di pacchettizzazione per essere in funzionamento simultaneo. Questo tipo di ambiente può prestarsi all'utilità di pianificazione di Accodamento a bassa latenza.

Utilità di pianificazione accodamento a bassa latenza

Lo scheduler LLQ (Low Latency Queueing) è stato introdotto nel software Cisco IOS versione 12.3(13a)BC. LLQ è il metodo alternativo per pianificare i servizi a monte su un Cisco uBR CMTS. Questa utilità di pianificazione è stata progettata per massimizzare il numero di flussi di servizi in stile UGS e RTPS che un upstream può supportare simultaneamente e anche migliorare l'efficienza del traffico in presenza di flussi di servizi UGS. Il compromesso è che l'utilità di pianificazione LLQ non offre alcuna garanzia in relazione al jitter per i flussi di servizi UGS e RTPS.

Come spiegato nella sezione DOCSIS Compliant Scheduler, lo scheduler compatibile DOCSIS pre-alloca il tempo di trasmissione in anticipo per i flussi di servizio in stile UGS e RTPS. Analogamente, un sistema TDM (Time Division Multiplexing) legacy alloca la larghezza di banda a un servizio per garantire determinati livelli di latenza e jitter.

Nelle moderne reti a pacchetti, le code a bassa latenza sono il metodo usato dai router per garantire che i pacchetti associati a servizi ad alta priorità, ad esempio voce e video, possano essere consegnati in rete prima di altri pacchetti a bassa priorità. Questo è anche il metodo usato dai moderni router per garantire che latenza e jitter siano ridotti al minimo per il traffico importante.

L'uso del termine "garanzia" per il sistema basato su TDM e "minimizzato" per il sistema basato su LLQ in relazione a jitter e latenza. Anche se è auspicabile una garanzia di latenza zero e di jitter, il vantaggio è che un sistema di questo tipo è solitamente inflessibile, difficile da riconfigurare e generalmente incapace di adattarsi facilmente ai cambiamenti delle condizioni della rete.

Un sistema che riduce al minimo la latenza e il tremolio, piuttosto che fornire una garanzia rigida, è in grado di fornire flessibilità per continuare a ottimizzarsi in caso di cambiamenti nelle condizioni della rete. L'utilità di pianificazione delle code a bassa latenza si comporta in modo simile al sistema LLQ basato su router di pacchetti. Anziché un sistema di assegnazione prestabilito per le sovvenzioni UGS, questo sistema fissa le sovvenzioni "il prima possibile" al punto in cui devono essere programmate.

L'approccio che concede per i flussi di servizi UGS deve essere allocato il prima possibile, ma non necessariamente con una periodicità perfetta, questo sistema contratta le garanzie di jitter rigoroso per una maggiore capacità UGS e una minore frammentazione dei dati di massimo sforzo.

Configurazione

Per il software Cisco IOS versione 12.3(13a)BC e successive, lo scheduler LLQ è uno dei due algoritmi di scheduler alternativi. È possibile abilitare LLQ per una, tutte o alcune delle seguenti modalità di pianificazione:

• UGS

• RTPS

• NRTPS

L'utilità di pianificazione LLQ non è attivata per impostazione predefinita. È necessario attivare esplicitamente lo scheduler LLQ per i tipi di pianificazione upstream richiesti. Utilizzare il tipo di programmazione cavo upstream-porta [nrtps] | rtps | ugs] mode llq cable interface.

In generale, è possibile abilitare lo scheduler LLQ per tutte le modalità di programmazione elencate, se questa è la modalità di programmazione desiderata. Di seguito è riportato un esempio di una situazione in cui si desidera abilitare la pianificazione LLQ per un solo tipo di modalità di pianificazione ma mantenere la pianificazione compatibile con DOCSIS per gli altri:

I flussi del servizio RTPS non hanno requisiti rigorosi per il jitter, a differenza dei flussi del servizio UGS. In questo caso, è possibile abilitare lo scheduler LLQ per i flussi del servizio RTPS e mantenere lo scheduler compatibile con DOCSIS per UGS.

Operazione LLQ Scheduler

L'utilità di pianificazione LLQ funziona allo stesso modo della funzione di coda di priorità dell'utilità di pianificazione compatibile con DOCSIS con l'aggiunta di una speciale coda a bassa latenza (LLQ), che ha la precedenza su tutte le altre code.

L'utilità di pianificazione LLQ avvia un timer per conto di tutti i flussi di servizi in stile UGS (e RTPS) attivi. Il timer è impostato per spegnersi una volta ogni "grant interval". Alla scadenza del timer, una concessione UGS viene inserita nella coda LLQ. Poiché questa concessione viene inserita nella coda LLQ che ha la priorità massima, la concessione viene pianificata al successivo momento possibile in cui è disponibile spazio libero.

I diagrammi in questa sezione mostrano un esempio di sistema con tre flussi di servizio UGS attivi con lo stesso intervallo di concessione. La Figura 27 mostra i timer per i flussi del servizio UGS sulla sinistra, etichettati da UGS-1 a UGS-3. La freccia gialla viaggia in senso orario. Quando la freccia gialla punta verso l'alto verso il punto rosso, alla coda LLQ viene aggiunta una concessione UGS. È inoltre possibile visualizzare le otto code di priorità familiari da 0 a 7 e una nuova coda LLQ che ha la priorità su tutte. Infine, a destra, è la linea temporale di allocazione della larghezza di banda che descrive come vengono programmate le concessioni a monte. Per maggiore chiarezza, la linea temporale di allocazione della larghezza di banda include un puntatore "ora corrente". Questo puntatore si sposta in avanti lungo la linea temporale mentre l'esempio procede.

Figura 27 - Sistema di coda a bassa latenza

Il primo evento che si verifica è che il timer UGS-1 in alto a sinistra scade. Una concessione corrispondente è in coda nella coda LLQ. Allo stesso tempo, una concessione di massimo sforzo denominata A con priorità 2 è in coda.

Figura 28 - La sovvenzione per UGS-1 e la sovvenzione A con priorità 2 sono in coda

Lo scheduler LLQ alloca ora il tempo di trasmissione alle sovvenzioni in sospeso in ordine di priorità. La prima concessione a ricevere il tempo di trasmissione è la concessione per UGS-1 che attende nella coda LLQ. Viene seguito Grant A.

Figura 29 - Assegnazione di tempo di trasmissione a UGS-1 e Grant A

L'evento successivo da verificare è che il timer UGS-2 scade e causa una concessione per il flusso del servizio UGS-2 da accodare nella coda LLQ. Allo stesso tempo, viene messa in coda una sovvenzione B con priorità 0 e una sovvenzione C con priorità 6.

Figura 30 - Scadenza timer UGS-2. I privilegi B e C sono in coda

L'utilità di pianificazione LLQ assegna nuovamente il tempo di trasmissione in ordine di priorità della sovvenzione, il che significa che prima l'utilità di pianificazione assegna il tempo alla sovvenzione per UGS-2, quindi per la sovvenzione C e infine per la sovvenzione B.

Figura 31 - Concede UGS-2, C e B i tempi di trasmissione allocati

Si supponga che non venga concesso alcun impegno in termini di tempo per accedere allo scheduler per un determinato periodo. I timer UGS scadono un paio di volte in più. È ora possibile visualizzare il tipo di periodo con cui lo scheduler alloca le concessioni ai flussi di servizio UGS. La spaziatura è uniforme. Si supponga che quando le sovvenzioni vengono visualizzate in questo modo in relazione l'una all'altra nella cronologia di allocazione della larghezza di banda, non si verifichino variazioni significative.

Figura 32 - UGS-1, UGS-2 e UGS-3 ricevono diverse sovvenzioni. ID sovvenzione in coda

La figura 32 indica la posizione ideale per la prossima concessione UGS-2. Se UGS-2 può avere la sovvenzione posizionata in questo punto, UGS-2 non sperimenterà alcun jitter per la sovvenzione. Si noti che c'è ancora tempo per la successiva concessione UGS-2 da mettere in coda nella coda LLQ.

La Figura 32 indica anche che una priorità molto grande 0 grant D è appena entrata nella coda priorità 0. L'azione successiva eseguita dallo scheduler LLQ consiste nel pianificare il tempo di trasmissione per la concessione D.

La Figura 33 mostra questo scenario. Avvolgere leggermente l'orologio in avanti fino al punto in cui la concessione successiva per UGS-2 è in coda.

Figura 33 - Concessione D del tempo di trasmissione. Concessione per UGS-2 in coda

La concessione D sembra essere programmata nel momento in cui la prossima concessione UGS-2 deve essere programmata per zero jitter. Ora la domanda è perché l'utilità di pianificazione LLQ consente di programmare la concessione D in quel punto e non ritarda la concessione D fino a dopo la concessione per UGS-2 o perché D non è frammentato. La risposta è che lo scheduler LLQ non prealloca il tempo di trasmissione per i flussi di servizio UGS. Pertanto, l'utilità di pianificazione LLQ non è a conoscenza in anticipo di dove UGS concederà le risorse sulla linea temporale di allocazione della larghezza di banda. L'utilità di pianificazione LLQ non è a conoscenza delle concessioni UGS finché non vengono accodate nella coda LLQ. In questo esempio, quando il privilegio per UGS-2 entra in coda, il privilegio D è già pianificato.

L'utilità di pianificazione LLQ pianifica la sovvenzione per UGS-2 alla successiva opportunità disponibile, ma questa concessione è leggermente ritardata dalla posizione ideale, il che significa per definizione che questa particolare sovvenzione sperimenta qualche jitter.

Figura 34 - Sovvenzione per UGS-2 ritardata e jitter esperienze

Mentre lo scheduler conforme a DOCSIS avrebbe potuto evitare questo jitter, lo scheduler LLQ evita un ritardo o una frammentazione della concessione D a scapito di una piccola quantità di jitter. Un buffer di jitter in un endpoint VoIP può facilmente compensare questo jitter.

L'altra situazione in cui si può verificare uno jitter è quando il timer LLQ per più flussi di servizi scade contemporaneamente e UGS concede l'attesa dietro altre concessioni UGS in coda nella coda LLQ. L'utilità di pianificazione LLQ è stata progettata per ridurre al minimo la possibilità di questo evento. Lo scheduler distribuisce automaticamente i tempi di scadenza per i timer del flusso di servizio.

Come per lo scheduler compatibile con DOCSIS, lo scheduler LLQ ha altre due code che gli esempi non menzionano. Ecco le code:

1. La prima coda viene utilizzata per pianificare il traffico keepalive per la manutenzione periodica della stazione in modo da mantenere online i modem via cavo. Questa coda viene servita subito dopo la coda LLQ.

2. La seconda è una coda per le concessioni allocate ai flussi di servizi con una tariffa riservata minima (flussi di servizi CIR). Questa coda CIR viene trattata come una coda con "priorità 8" per garantire che i flussi di servizi con una velocità impegnata ricevano il throughput minimo richiesto.

Controllo ammissione

A differenza dello scheduler compatibile con DOCSIS, lo scheduler LLQ non utilizza un sistema di pre-pianificazione che arresta l'oversubscription accidentale di un upstream con flussi di servizi UGS e RTPS. Per questo motivo è necessario configurare esplicitamente il controllo di ammissione a monte su qualsiasi upstream che utilizza l'utilità di pianificazione LLQ. Questa configurazione garantisce che la larghezza di banda upstream totale dei flussi del servizio UGS non superi i limiti sani.

Cisco in genere consiglia di non consentire che l'utilizzo di un canale a monte superi il 75% per periodi estesi durante i periodi di massimo utilizzo. Ad esempio, se il traffico UGS consuma più del 75% della larghezza di banda a monte, i dati relativi al massimo sforzo iniziano a soffrire di problemi eccessivi di latenza e prestazioni di throughput.

Naturalmente se un operatore CMTS può accettare le conseguenze negative per il traffico di massimo sforzo, è possibile lasciare che i flussi di servizio UGS consumano più del 75% della larghezza di banda upstream disponibile. Tuttavia, è necessario considerare anche l'impatto sul traffico di gestione di layer 2 sul canale a monte. È necessario attendere il tempo necessario per i messaggi iniziali e di manutenzione della stazione (modem via cavo keepalive). Se non si tiene conto di ciò, e il traffico UGS consuma quasi il 100% della larghezza di banda, i modem via cavo non possono essere connessi o possono rimanere offline.

Di seguito è riportato un esempio di configurazione per il controllo dell'ammissione. In questo esempio i flussi del servizio UGS su un particolare upstream vengono limitati al 50% della larghezza di banda disponibile dell'upstream. Questa forma del comando trasmette inoltre trap SNMP a tutte le stazioni di gestione di rete configurate quando vengono raggiunte le soglie minime e principali del 30% e del 40% di utilizzo. Il comando è:

cavo upstream upstream-number ammissione-controllo usa-larghezza di banda tipo programmazione UGS minore 30 maggiore 40 esclusivo 50

Per informazioni su come configurare il controllo dell'ammissione, vedere la sezione Controllo ammissione nella sezione Scheduler compatibile DOCSIS di questo documento.

Mostra output comando

Eseguire il comando show interface cable interface-number mac-scheduler upstream-number per verificare lo stato corrente dell'utilità di pianificazione LLQ.

Di seguito è riportato un esempio dell'output di questo comando. Le parti dell'output del comando che sono diverse da quando lo scheduler conforme a DOCSIS è operativo sono in grassetto:

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

Per una spiegazione delle righe di testo normale in questo output, vedere la sezione Show Command Output per DOCSIS Compliant Scheduler.

Di seguito vengono descritte le righe in grassetto dell'output del comando show:

• Queue[Concessioni LLQ] 0/64, 0 drop, max 3

  Questa riga mostra lo stato della coda LLQ, che gestisce le concessioni per i tipi di flusso di servizio specificati nel tipo di programmazione upstream dei cavi [nrtps | rtps | ugs] mode llq. 0/64 indica che attualmente nella coda sono presenti zero su un massimo di 64 concessioni in sospeso.

  Il contatore delle eliminazioni indica il numero di volte in cui l'utilità di pianificazione non è stata in grado di mettere in coda una concessione UGS o un polling RTPS perché la coda era già piena (in altre parole, quando sono in coda 64 concessioni). In caso di caduta in questa coda, la spiegazione più probabile è che la parte a monte sia sovrascritta da flussi di servizi UGS o RTPS e si deve applicare un controllo dell'ammissione più severo.

  Il contatore max indica il numero massimo di concessioni presenti nella coda dall'ultima esecuzione del comando show interface cable mac-scheduler. Se presente, questa coda ha la priorità più alta tra tutte le code elencate.

• tick r4k in 1 ms 60000

  Questo campo rappresenta una variabile temporale interna utilizzata dallo scheduler LLQ per garantire che le concessioni vengano inserite nella coda LLQ con alta precisione.

• Totale eventi di programmazione 5009

  Questa riga indica il numero di volte che l'utilità di pianificazione LLQ tenta di mettere in coda una concessione dall'ultima volta che è stato eseguito il comando show interface cable mac-scheduler per questo upstream. Questo contatore viene reimpostato ogni volta che viene eseguito il comando show.

• Nessuna ricerca necessaria 5009

  Dopo che l'utilità di pianificazione LLQ ha accodato una concessione, l'utilità di pianificazione LLQ tenta di reimpostare il timer del flusso di servizio per prepararsi alla successiva accodamento di una concessione. Se non si verificano problemi con il ripristino del timer, il contatore viene incrementato. Questo contatore deve avere idealmente lo stesso valore del contatore Totale eventi di pianificazione.

• Voce precedente libera 0, Voce successiva libera 0

  Nelle versioni correnti del software Cisco IOS, nessuno di questi contatori incrementa. Questi contatori rimangono sempre a zero.

• Impossibile pianificare 0, ripristino non riuscito 0

  Questa riga indica il numero di volte in cui l'utilità di pianificazione LLQ non è stata in grado di disporre la corretta impostazione del timer di concessione di un flusso di servizio. Questa condizione deve verificarsi solo se lo scheduler LLQ gestisce un numero estremamente elevato di concessioni con intervalli di concessione molto bassi. È altamente improbabile che questi contatori aumentino mai su una rete di produzione. Un incremento di questi contatori può indicare che i flussi dei servizi UGS e RTPS consumano più larghezza di banda di quella fisicamente disponibile a monte. In questo scenario, è necessario implementare i comandi appropriati per il controllo dell'ammissione.

• Ora corrente 1341 voce 61

  Questa riga mostra i timer interni per l'utilità di pianificazione LLQ misurati in millisecondi. Quando la "voce" qui elencata è uguale al campo "Voce" elencato nelle statistiche del flusso di servizio, un privilegio viene inserito nella coda LLQ.

Queste statistiche vengono ripetute per ogni flusso di servizio gestito dall'utilità di pianificazione LLQ. In questo esempio esistono tre flussi di servizi di questo tipo.

• Voce 188, Raccoglitore 13

  Quando il valore "Entry" (Immissione) è uguale al campo "Entry" (Immissione) dell'elemento precedente, il timer per questo flusso di servizio scade e un privilegio entra nella coda LLQ. Questo campo viene reimpostato ogni volta che il flusso del servizio ha una concessione in coda.

• SID: 416

  L'identificativo del servizio (SID) per il flusso del servizio che concede le pianificazioni dell'utilità di pianificazione LLQ.

• IUC: 5

  Codice di utilizzo dell'intervallo annunciato in un messaggio MAP per le concessioni che appartengono a questo flusso di servizio. Questo valore è quasi sempre 5 per "Short data", 6 per "Long Data" o 11 per "Advanced PHY UGS" quando è in uso un flusso di servizio di tipo UGS. Per il flusso del servizio di stile RTPS, questo valore è sempre 1 per "Richiesta".

• dimens_m: 17 size_byte: 232

  Dimensioni della concessione in minuti, seguite dalle dimensioni della concessione in byte. Il minislot è l'unità di trasmissione upstream più piccola in una rete DOCSIS e in genere equivale a 8 o 16 byte.

• Frammentazione: N

  Indica se la sovvenzione è frammentabile. Attualmente questo valore è sempre impostato su N.

• Inval: 20

  Intervallo di concessione o polling in millisecondi.

• tipo 8

  8 indica che il flusso del servizio è UGS, 10 indica RTPS e 11 indica NRTPS.

• tempo perfetto rif 188

  L'ora ideale in cui questa concessione deve essere stata programmata. In genere corrisponde alla voce in alto. In caso contrario, vi è l'indicazione di una fase a monte fortemente congestionata che richiede un controllo più severo dell'ammissione.

• inclinazione da rif 0

  Differenza tra il momento in cui la sovvenzione è stata programmata e il momento in cui, idealmente, la sovvenzione deve essere stata programmata. Questa è la differenza tra "Entry" e "Perfect time ref". Pertanto, questo valore deve essere in genere zero.

• priorità 10

  Nelle versioni correnti del software Cisco IOS, questo valore è sempre impostato su 10, ma può variare in futuro.

• posizione 188, collocazione 13

  Questi campi devono corrispondere a "Entry, Bin" nella parte superiore dell'elenco.

Vantaggi e svantaggi dello scheduler LLQ

L'obiettivo dell'utilità di pianificazione LLQ è di aumentare la capacità UGS e RTPS per i canali upstream e di aumentare l'efficienza del traffico nella massima efficienza. Il compromesso raggiunto dall'utilità di pianificazione LLQ per raggiungere questi obiettivi è che questa utilità di pianificazione non fornisce esplicitamente garanzie per l'instabilità del flusso del servizio UGS e RTPS. Al contrario, il programmatore LLQ programma le borse UGS e i sondaggi RTPS il più vicino possibile all'ora ideale al fine di ridurre al minimo l'instabilità.

L'utilità di pianificazione LLQ è inoltre in grado di gestire in modo più efficace più flussi di servizi UGS con intervalli di concessione e dimensioni di concessione diversi rispetto all'utilità di pianificazione compatibile con DOCSIS. Questa funzione può essere utile in un ambiente PCMM in cui diversi tipi di chiamate VoIP e possibilmente altre applicazioni sono tutte servite contemporaneamente sull'unico canale upstream.

L'utilità di pianificazione LLQ pianifica in modo più efficiente il miglior traffico di risorse in quanto riduce la probabilità di frammentazione delle sovvenzioni. Quando sono pianificati burst di DOCSIS 1.0 non frammentabili, l'utilità di pianificazione LLQ non crea gap di larghezza di banda inutilizzata davanti alle concessioni UGS o ai polling RTPS, come talvolta accade con l'utilità di pianificazione compatibile DOCSIS. In questo modo è possibile sfruttare meglio il tempo a monte disponibile.

Sebbene il jitter UGS sia in genere più alto quando si utilizza l'utilità di pianificazione LLQ rispetto a quando si utilizza l'utilità di pianificazione compatibile con DOCSIS, nelle reti basate su DOCSIS o PacketCable standard i livelli di jitter dell'utilità di pianificazione LLQ sono all'interno della capacità della tecnologia VoIP basata sul jitter buffer dell'endpoint. Ciò significa che non vi è alcun impatto significativo sulla qualità delle chiamate VoIP quando si utilizza l'utilità di pianificazione LLQ in una rete VoIP correttamente progettata.

Potete limitare la variazione che deriva da grandi esplosioni a monte. A tale scopo, assicuratevi di mantenere il parametro default-phy-burst del cavo al valore predefinito di 2000 byte o meno. Se un sistema utilizza un canale upstream particolarmente lento, ad esempio con una larghezza di canale pari a 800 kHz o inferiore, potete ottenere ulteriori riduzioni del jitter se forzate la frammentazione di grandi burst in burst più piccoli con il comando cable upstream fragment-force.

Quando il programmatore LLQ è in uso, è necessario configurare il controllo dell'ingresso del cavo per evitare la possibilità di un'iscrizione eccessiva del canale a monte. Flussi di servizi UGS più attivi di quelli che possono essere gestiti fisicamente a monte causano una scarsa qualità della voce in tutti i flussi di servizi UGS a monte. Nei casi estremi, ciò significa anche che i modem via cavo non sono in linea e i nuovi modem non possono connettersi. Cisco consiglia agli operatori CMTS di configurare il controllo dell'ammissione in modo che l'utilizzo totale a monte su qualsiasi porta a monte non superi il 75% per periodi di tempo estesi.

Conclusioni

La serie uBR Cisco di prodotti DOCSIS CMTS fornisce due algoritmi di pianificazione upstream alternativi, ed è quindi in grado di soddisfare una varietà di condizioni di rete.

Il modulo di programmazione conforme a DOCSIS, ottimizzato per il basso jitter, è particolarmente adatto per i sistemi voce Packetcable 1.x con codec VoIP uniforme e in cui si desiderano livelli standard di utilizzo del canale upstream da parte dei flussi di servizio UGS.

L'utilità di pianificazione di Low Latency Queueing è progettata per supportare livelli di utilizzo upstream superiori al normale da parte dei flussi di servizio UGS, una maggiore efficienza del traffico in termini di massimo sforzo e sistemi che utilizzano flussi di servizio UGS e RTPS con una varietà di intervalli di concessione e dimensioni di sovvenzione.

Appendice A Minislot

Un minislot è l'unità di trasmissione più piccola nel DOCSIS a monte. Quando un modem via cavo trasmette una richiesta di larghezza di banda al CMTS per chiedere un tempo di trasmissione upstream, il modem chiede in unità di minuti anziché in byte o millisecondi. Inoltre, quando un messaggio MAP di allocazione della larghezza di banda comunica ai modem quando possono trasmettere e per quanto tempo, il messaggio contiene le informazioni in unità di minislot.

Il numero massimo di minislot che un modem può richiedere di trasmettere in un burst è 255. Le dimensioni del minislot sono specificate in unità denominate tick DOCSIS. Un tick DOCSIS equivale a 6,25 microsecondi di tempo.

Per impostare le dimensioni del minislot in tick per una porta a monte, utilizzare il cavo upstream <upstream-number> minislot-size [1] | 2 | 4 | 8 | 16 | 32 | 64 | 128] cable interface command

Solo determinate dimensioni di minislot sono consentite con particolari larghezze di canali a monte. Nella tabella vengono indicate le dimensioni valide del minislot rispetto alle larghezze del canale a monte DOCSIS e viene inoltre mostrata la lunghezza dei simboli dello schema di modulazione di un minislot con impostazioni valide.

Nota: un segno X indica una combinazione non valida.

	Larghezza canale	200 kHz	400 kHz	800 kHz	1,6 MHz	3,2 MHz	6,4 MHz
Dimensioni in tick
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

Per calcolare il numero di byte trasmessi per minislot, moltiplicare i simboli per minislot per il numero di bit per simbolo dello schema di modulazione configurato. Diversi schemi di modulazione trasmettono un numero diverso di bit per simbolo, come mostrato nella seguente tabella:

Schemi di modulazione TDMA DOCSIS 1.1	Bit per simbolo
QPSK	2
16-QAM	4

Schemi di modulazione ATDMA DOCSIS 2.0	Bit per simbolo
8-QAM	3
32-QAM	5
64-QAM	6

Ad esempio, con una larghezza del canale di 1,6 MHz e una dimensione minislot di 4 tick, potete utilizzare la prima tabella per ottenere una cifra di 32 simboli per minislot. Utilizzare la seconda tabella per convertire questa cifra in byte, poiché un simbolo QPSK contiene 2 bit. Un minislot in questo esempio equivale a 32 simboli per minislot * 2 bit per simbolo = 64 bit per minislot = 8 byte per minislot.

Tenere presente che il numero massimo di minislot che un modem via cavo può richiedere di trasmettere è 255. Pertanto, in questo esempio a monte, il massimo burst in byte che un modem può effettuare è 255 minislot * 8 byte per minislot = 2040 byte.

Notare che questa cifra in byte è la correzione dell'errore di postforward e la figura del sovraccarico del livello fisico di post. Correzione degli errori e altro sovraccarico del livello PHY DOCSIS aggiunge circa il 10-20% alla lunghezza di un frame Ethernet mentre passa attraverso il canale a monte. Per derivare la figura esatta, utilizzare il profilo di modulazione applicato alla porta a monte.

Questa discussione è significativa perché in una sezione precedente di questo documento si afferma che uno dei limiti alle dimensioni massime della frammentazione di un modem via cavo è il valore configurato nel comando cable default-phy-burst. Se il comando cable default-phy-burst è impostato su 4000 byte nel contesto di questo esempio, il fattore di limitazione per le dimensioni della frammentazione è il limite di 255 minislot (2040 byte meno il sovraccarico) anziché il valore cable default-phy-burst.

È possibile osservare diverse espressioni delle dimensioni del minislot per un upstream con il comando show controller cable interface-number upstream upstream-number. Di seguito è riportato un esempio:

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

Cisco consiglia di impostare le dimensioni del minislot in modo che equivalgano a 16 byte o al valore più vicino consentito. Una dimensione di minislot di 16 byte offre ai modem via cavo la possibilità di generare una frammentazione post-FEC fino a 255 * 16 = 4096 byte.

Appendice B Anticipo mappa

Il CMTS genera periodicamente un messaggio speciale chiamato MAP di allocazione della larghezza di banda che informa i modem via cavo di un momento preciso in cui possono effettuare le trasmissioni sul canale a monte. I segnali elettrici che trasmettono il messaggio MAP impiegano un tempo limitato per propagarsi fisicamente attraverso la rete HFC (Hybrid Fiber Coax) dal CMTS a tutti i modem via cavo collegati. Di conseguenza, il messaggio MAP deve essere trasmesso con sufficiente anticipo affinché i modem possano ricevere il messaggio ed essere in grado di effettuare le trasmissioni a monte in modo che raggiungano il CMTS all'ora indicata.

Il tempo di anticipo MAP o il tempo di attesa MAP rappresenta la differenza tra il momento in cui il CMTS genera il messaggio MAP e il momento in cui la prima trasmissione ordinata dal MAP deve essere ricevuta dal CMTS. Questo tempo rappresenta una combinazione di questi ritardi presenti in un sistema DOCSIS:

• Tempo impiegato dal CMTS per costruire il messaggio MAP nel software e per accodare il messaggio ed elaborarlo dal circuito di trasmissione a valle. Il valore di questo componente è specifico per piattaforme e architetture diverse ed è in genere un valore fisso.

• Latenza aggiunta dalla funzione di interfoliazione a valle, utilizzata per la correzione in avanti dell'errore per evitare il rumore d'impulso. Per modificare questo valore, modificate i parametri dell'interleaver a valle.

• Il tempo impiegato dai segnali elettrici per passare attraverso la rete HFC dal CMTS al modem via cavo e quindi tornare indietro. DOCSIS specifica un tempo massimo di trasferimento in un senso tra il CMTS e il modem via cavo di 800 microsecondi. Questo valore varia a seconda della lunghezza fisica dell'impianto di cablaggio. Anche lo schema di modulazione a valle, la larghezza del canale a monte e lo schema di modulazione influenzano questo valore.

• Tempo impiegato dal modem via cavo per elaborare un messaggio MAP ricevuto e per prepararsi alla trasmissione upstream. Non deve essere superiore a 200 microsecondi più eventuali ritardi dell'interleaver a monte, come indicato nelle linee guida della specifica DOCSIS. In realtà, questo tempo può arrivare fino a 300 microsecondi o fino a 100 microsecondi, a seconda della marca, del modello e della versione del firmware del modem via cavo.

Figura 35 - Componenti nel tempo di avanzamento MAP

Il tempo di anticipo della mappa può influire in modo significativo sulla latenza delle trasmissioni upstream perché questo valore rappresenta il ritardo minimo tra il momento in cui il CMTS sa che un modem via cavo desidera effettuare una trasmissione e il momento in cui il modem è autorizzato a effettuare tale trasmissione. Per questo motivo, ridurre al minimo il tempo di anticipo della mappa per ridurre la latenza a monte.

Notare che in un upstream congestionato, anche altri fattori influenzano la latenza upstream. Ad esempio, i ritardi causati dall'algoritmo di backoff e di richiesta della larghezza di banda dei nuovi tentativi e la coda di concessioni in sospeso tra loro.

La Figura 36 mostra la relazione tra un MAP generato dal CMTS e la corrispondente ricezione di dati a monte.

Figura 36 - Relazione tra generazione di mappe e ricezione di dati a monte

Profondità Interleaver

Il primo fattore nel tempo di anticipo della mappa che può variare è l'interlacciatore a valle utilizzato per la protezione dal rumore d'impulso. Nella tabella seguente viene mostrata la latenza aggiunta alle trasmissioni a valle per varie impostazioni di incremento del tocco e dell'interleaver:

Nota: più grande è la dimensione del tocco, maggiore è la potenza della correzione dell'errore, ma anche maggiore è la latenza indotta.

I (Numero di tap)	J (Incremento)	Latenza 64-QAM	Latenza 256-QAM
8	16	220 µsec	150 µsec
16	8	480 µsec	330 µsec
32	4	980 µsec	680 µsec
64	2	2000 µsec	1400 µsec
128	1	4000 µsec	2800 µsec
12 (EuroDOCSIS)	17 (EuroDOCSIS)	430 µsec	320 µsec

È possibile impostare i parametri dell'interleaver con la profondità dell'interfoliazione a valle del cavo [8] | 16 | 32 | 64 | 128] comando di configurazione interfaccia cavo

Nota: viene specificato il valore per I (numero di tap) e viene applicato automaticamente un valore fisso corrispondente per J (incremento), come mostrato nella tabella. Inoltre, per la modalità EuroDOCSIS (allegato A) i parametri dell'interleaver sono fissati su I = 12 e J = 17. Il valore predefinito per I è 32, che dà un valore predefinito per J di 4.

Tempo andata e ritorno

Il secondo fattore che contribuisce al tempo di anticipo della mappa che può essere variato è il tempo di andata e ritorno elettrico tra il CMTS e i modem via cavo. Questo valore viene influenzato dalla distanza fisica tra i modem CMTS e i modem via cavo e dal ritardo di elaborazione inerente ai modem.

La specifica DOCSIS richiede che il tempo massimo consentito di propagazione unidirezionale tra il CMTS e il modem via cavo più lontano nel sistema non sia superiore a 800 microsecondi. Questo implica un tempo di andata e ritorno, escluso il ritardo di elaborazione del modem via cavo, di circa 1600 microsecondi.

La velocità della luce nel vuoto è di circa 186.000 miglia al secondo (300.000 chilometri al secondo) e la velocità di propagazione della fibra è in genere indicata come 0,67. Pertanto, la distanza massima consentita a una via tra un CMTS e un modem via cavo è approssimativamente:

	Distance = Velocity * Time

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

       		 = 100 miles or 161 kilometers.

In base alla specifica DOCSIS, il ritardo di elaborazione del modem via cavo non deve superare i 200 microsecondi più eventuali ritardi di interfoliazione upstream. Tuttavia, in rari casi, alcune vecchie marche di modem via cavo possono impiegare fino a 300 microsecondi per elaborare un messaggio MAP. I nuovi tipi di modem via cavo con CPU più potenti possono impiegare fino a 100 microsecondi per elaborare un messaggio MAP.

Si supponga che i modem via cavo siano, in media, conformi alla specifica DOCSIS. Pertanto, il tempo di andata e ritorno massimo deve essere 1600 + 200 = 1800 microsecondi.

La maggior parte dei sistemi via cavo sono molto più corti di 100 miglia. Pertanto, non è consigliabile che un CMTS presuma sempre che il tempo di andata e ritorno tra il CMTS e il modem del cavo più lontano sia il valore massimo di 1800 microsecondi.

Per una stima approssimativa del tempo di andata e ritorno massimo previsto, sommare la distanza della fibra tra il CMTS e il modem via cavo e moltiplicarla per 16 microsecondi per miglio (10 microsecondi per km). Sommare quindi la distanza di qualsiasi coassiale e moltiplicare tale valore per 12,4 microsecondi per miglio (7,6 microsecondi per km). Aggiungere quindi il ritardo di elaborazione di 200 microsecondi.

Ad esempio, un segmento HFC con un totale di 20 miglia di fibra e un miglio e mezzo di coassiale tra il CMTS e il modem via cavo più lontano potrebbe prevedere un ritardo di andata e ritorno elettrico di:

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

= 532.4 microseconds

Questa cifra non tiene conto dei ritardi aggiuntivi dovuti alle caratteristiche dei canali a monte e a valle e alle variazioni nei tempi di elaborazione del modem. Pertanto questo valore non è appropriato per il calcolo del tempo di anticipo MAP.

Per determinare in modo più accurato il tempo di andata e ritorno di un sistema, è possibile osservare lo "Scostamento tempo" dei modem via cavo, come mostrato nell'output del comando show cable modem.Nell'ambito del processo di scostamento utilizzato dai modem per mantenere la comunicazione con il CMTS, il CMTS calcola il tempo di ritorno di ogni modem via cavo. Questo tempo di andata e ritorno appare come "Scostamento tempo" nell'output del comando show cable modem in unità di 1/10.24MHz = 97.7 nanosecondi chiamate unità di scostamento tempo o unità di scostamento gamma. Per convertire l'offset di sincronizzazione di un modem in microsecondi, moltiplicare il valore per 25/256 o dividere approssimativamente il valore per 10.

Di seguito è riportato un esempio in cui gli offset di temporizzazione di vari modem nell'output del comando show cable modem vengono convertiti in un valore di microsecondo:

Nota: il valore relativo al microsecondo viene visualizzato in corsivo.

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)

In questo caso, il modem più lontano elettricamente è l'ultimo modem con un offset di sincronizzazione di 6030. Ciò equivale a un tempo di andata e ritorno di 6030 * 25/256 = 589 microsecondi.

Anticipo mappa statica

In un sistema in cui la lunghezza della rete HFC è significativamente inferiore a 100 miglia, è possibile configurare il CMTS in modo che utilizzi un tempo di andata e ritorno massimo inferiore ai 1800 microsecondi standard quando si calcola il tempo di anticipo MAP.

Per forzare il CMTS a utilizzare un valore personalizzato per il tempo di andata e ritorno nel calcolo dell'anticipo MAP, eseguite il comando di interfaccia del cavo map-advance static max-round-trip-time statico.

L'intervallo per il tempo di andata e ritorno massimo è compreso tra 100 e 2000 microsecondi. Se non viene specificato alcun valore per max-round-trip-time, viene applicato il valore predefinito di 1800 microsecondi.

Nota: è possibile sostituire la parola chiave static con la parola chiave dynamic. Vedere la sezione successiva.

Verificare che il tempo di andata e ritorno specificato sia effettivamente maggiore del tempo massimo di andata e ritorno del modem via cavo CMTS sul canale a valle. Se un modem via cavo ha un tempo di andata e ritorno maggiore di quello specificato in max-round-trip-time, può avere difficoltà a rimanere in linea. Questo accade perché il modem non ha tempo sufficiente per rispondere a un messaggio MAP e quindi non è in grado di comunicare con il CMTS.

Se l'offset di un modem via cavo, convertito in microsecondi, supera il tempo di andata e ritorno specificato, il modem viene contrassegnato con l'indicatore di offset non valido. Questo flag offset viene visualizzato come un punto esclamativo (!) accanto all'offset di temporizzazione del modem via cavo nell'output del comando show cable modem. Questa situazione può verificarsi se il parametro max-round-trip-time è impostato su un valore troppo basso o se il modem via cavo presenta un problema in cui l'offset di sincronizzazione è instabile e aumenta costantemente nel tempo.

Di seguito è riportato un esempio:

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)

Nell'esempio, viene specificato il comando cable map-advance static 500. Tuttavia, uno dei modem via cavo collegati all'interfaccia ha una compensazione della sincronizzazione superiore a 500 microsecondi (equivalente a 500 * 256/25 = 5120 unità di compensazione della sincronizzazione).

Si noti che l'offset dell'ultimo modem via cavo è contrassegnato con il flag di offset errato, ovvero "!". Anche questo valore è fissato al valore massimo consentito di 5120 unità, anche se l'offset di sincronizzazione reale può essere molto più alto. Il modem via cavo può passare offline e avere prestazioni ridotte.

Il flag di scostamento dell'intervallo non valido rimane impostato per il modem via cavo anche se lo scostamento dell'intervallo scende al di sotto del tempo di ritorno massimo. L'unico modo per eliminare l'indicatore consiste nel rimuovere temporaneamente il modem dall'elenco dei modem via cavo. A tale scopo, è possibile utilizzare il comando clear cable modem mac-address delete. In alternativa, è possibile ripristinare l'interfaccia del cavo o la porta a monte.

Per osservare il funzionamento dell'algoritmo di avanzamento mappa statica su una base a monte, eseguire il comando show controller cable interface-number upstream upstream-number. Di seguito è riportato un esempio:

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

Il campo Anticipo mappa (statico) mostra un tempo di avanzamento della mappa di 3480 microsecondi. Se modificate le caratteristiche dell'interleaver a valle o il parametro max-round-trip-time, la modifica viene riflessa nel valore di avanzamento della mappa statica.

Anticipo mappa dinamica

L'utilizzo del calcolo statico dell'anticipo MAP per ottimizzare i tempi di avanzamento MAP richiede che l'operatore CMTS determini manualmente il tempo di andata e ritorno massimo su un segmento di cavo. Se le caratteristiche del canale a valle o a monte cambiano, o se le condizioni dell'impianto cambiano, il tempo massimo di andata e ritorno può variare in modo significativo. Può essere difficile aggiornare continuamente la configurazione per adattarla alle nuove condizioni del sistema.

L'algoritmo di avanzamento dinamico MAP risolve questo problema. L'algoritmo di avanzamento dinamico MAP analizza periodicamente l'elenco di modem via cavo show per cercare il modem con l'offset di intervallo iniziale più grande, quindi utilizza automaticamente tale valore per calcolare l'intervallo di avanzamento MAP. In questo modo, il CMTS utilizza sempre il tempo di anticipo della mappa più basso possibile.

Lo scostamento temporale iniziale per un modem via cavo è lo scostamento temporale indicato dal modem nel punto in cui si connette. Nella maggior parte dei casi, questo valore è vicino allo scarto temporale in corso, come mostrato nell'output del comando show cable modem. Tuttavia, alcuni tipi di modem via cavo hanno un problema nel caso in cui l'offset di temporizzazione scivoli verso l'alto nel tempo fino a valori molto elevati. Questo può inclinare il calcolo del tempo di anticipo della mappa. Viene quindi utilizzato solo lo scostamento temporale iniziale, che viene aggiornato solo se il modem è in linea. Per visualizzare l'offset di intervallo iniziale e l'offset di intervallo continuo per un modem via cavo, eseguire il comando show cable modem verbose. Di seguito è riportato un esempio:

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

In questo esempio, la differenza di tempo corrente (2566) è leggermente superiore alla differenza di tempo iniziale (2560). Questi valori possono differire leggermente. Tuttavia, se i valori differiscono di più di alcune centinaia di unità, potrebbe esserci un problema con il controllo dell'offset di sincronizzazione del modem via cavo.

Per attivare il calcolo dell'avanzamento della mappa dinamica, usare il comando cable map-advance dynamic safety-factor max-round-trip-time cable interface.

Il parametro del fattore di sicurezza varia da 100 a 2000 microsecondi. Questo parametro viene aggiunto al tempo di anticipo MAP in modo da fornire una piccola protezione per tenere conto di eventuali ritardi imprevisti nella propagazione del segnale. Il valore predefinito è 1000 microsecondi. Tuttavia, per i sistemi di cavi stabili che non subiscono modifiche significative nell'impianto di cablaggio o nelle caratteristiche del canale a monte o a valle, utilizzare un valore inferiore, ad esempio 500 microsecondi.

Il parametro max-round-trip-time è compreso tra 100 e 2000 microsecondi. Questo parametro viene utilizzato come limite superiore per gli offset temporali dei modem del cavo collegati al segmento del cavo. Il valore predefinito è 1800 microsecondi. Se l'offset di tempo di un modem via cavo, convertito in microsecondi, supera il tempo di andata e ritorno massimo specificato, viene visualizzato contrassegnato con il flag di offset dell'intervallo non valido.

Impostate il parametro del tempo di andata e ritorno max su un valore non di default quando sapete che la lunghezza del sistema di cavi è significativamente inferiore a 100 miglia e se sapete quale deve essere l'offset del tempo normale massimo per i modem via cavo collegati al segmento.

Osservare il funzionamento dell'algoritmo di avanzamento della mappa dinamica su una base a monte con il comando show controller cable interface-number upstream upstream-number. Di seguito è riportato un esempio:

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

Il valore Offset temporizzazione Tx mostra l'offset di temporizzazione più grande per tutti i modem via cavo collegati a monte nelle unità di offset di temporizzazione. Utilizzare questo valore per calcolare il tempo di anticipo MAP. Il campo Anticipo mappa (dinamico) visualizza il tempo di anticipo della mappa risultante. Questo valore può variare se l'offset di temporizzazione Tx cambia, se il valore di sicurezza viene modificato o se vengono modificate le caratteristiche dell'interleaver a valle.

L'algoritmo di avanzamento dinamico MAP dipende dal fatto che i modem via cavo indichino o meno correttamente l'offset di intervallo iniziale al CMTS. Purtroppo, alcune marche e modelli di modem via cavo riportano gli offset di intervallo iniziali come valori significativamente inferiori al valore reale. È possibile osservare questo comportamento quando i modem mostrano offset di intervallo vicini allo zero o anche valori negativi.

Messaggi di errore simili a %UBR7200-4-BADTXOFFSET: Offset di temporizzazione errato -2 rilevato per il modem via cavo 00ff.0bad.caf3 può apparire su tali modem via cavo. Questi tipi di modem via cavo non segnalano i rispettivi offset temporali in un modo compatibile DOCSIS, l'algoritmo di avanzamento mappa dinamica non è in grado di calcolare correttamente un tempo di anticipo mappa che è garantito per dare a ogni modem via cavo il tempo di ricevere e rispondere ai messaggi MAP.

Se tali modem sono presenti su un segmento di cavo, disattivare l'algoritmo di avanzamento MAP dinamico e ripristinare l'algoritmo statico di avanzamento MAP. Per ulteriori informazioni, vedere Perché alcuni modem via cavo visualizzano uno scarto temporale negativo? per ulteriori informazioni.

Informazioni correlate

• Documentazione e supporto tecnico – Cisco Systems

Cronologia delle revisioni