Câble haut débit : Systèmes de terminaison par modem câble (CMTS)

Configuration du mode du planificateur ascendant pour le système CMTS Cisco uBR

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document discute la configuration du mode en amont de programmateur pour la gamme universelle de routeur haut débit de Cisco (ubr) de Systèmes de terminaison par modem câble (CMTS).

Ce document se concentre sur le personnel qui travaillent avec la conception et la maintenance des réseaux de données par câble à grande vitesse qui se servent de la latence et les services ascendants sensibles au jitter, par exemple, la Voix ou le vidéo au-dessus de l'IP.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

  • Données au-dessus des systèmes de la caractéristique d'interface de service par câble (DOCSIS)

  • La gamme d'ubr de Cisco de CMTS

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Ubr CMTS de Cisco

  • Séries de versions du logiciel 12.3(13a)BC et 12.3(17a)BC de ½ du ¿  de Cisco IOSïÂ

Remarque: Pour les informations sur des changements des versions ultérieures du Cisco IOS logiciel, référez-vous aux notes de mise à jour appropriées disponibles au site Web de Cisco.com.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

Dans un réseau de Data-over-Cable Service Interface Specifications (DOCSIS), le CMTS contrôle la synchronisation et le débit de toutes les transmissions en amont que les Modems câble font. Beaucoup de différents types services avec différentes conditions requises de latence, de jitter et de débit fonctionnent simultanément sur un en amont moderne de réseau DOCSIS. Par conséquent, vous devez comprendre comment le CMTS décide quand un modem câble peut faire les transmissions en amont au nom de ces différents types de services.

Ce livre blanc inclut :

  • Un aperçu des modes de établissement du programme d'en amont dans DOCSIS, y compris le meilleur effort, le service non sollicité de Grant (UGS) et le service en temps réel d'interrogation (RTPS)

  • L'exécution et la configuration du programmateur DOCSIS-conforme pour l'ubr CMTS de Cisco

  • L'exécution et la configuration du programmateur de queue de nouvelle basse latence pour l'ubr CMTS de Cisco

Scheduling en amont dans DOCSIS

Un CMTS DOCSIS-conforme peut fournir des modes de établissement du programme d'en amont différent pour différents flux de paquets ou les applications par le concept d'un service circulent. Un écoulement de service représente un en amont ou un écoulement en aval des données, qu'un ID d'écoulement de service (SFID) identifie seulement. Chaque écoulement de service peut avoir ses propres paramètres de Qualité de service (QoS), par exemple, débit maximal, débit et priorité garantis par minimum. Dans le cas des écoulements de service ascendant, vous pouvez également spécifier un mode de établissement du programme.

Vous pouvez avoir plus d'un écoulement de service ascendant pour que chaque modem câble facilite différents types d'applications. Par exemple, le Web et l'email peuvent utiliser un écoulement de service, la voix sur ip (VoIP) peut utiliser des autres, et le jeu d'Internet peut utiliser encore un autre écoulement de service. Afin de pouvoir fournir un type de service approprié pour chacune de ces applications, les caractéristiques de ces écoulements de service doivent être différentes.

Le modem câble et les CMTS peuvent diriger les types appropriés du trafic dans les écoulements appropriés de service avec l'utilisation des classificateurs. Les classificateurs sont les filtres spéciaux, comme les Listes d'accès, qui apparient des propriétés de paquet telles que des nombres d'UDP et de port TCP pour déterminer l'écoulement approprié de service pour que les paquets voyagent.

Dans la figure 1 un modem câblé a trois écoulements de service ascendant. Le premier écoulement de service est réservé pour le trafic vocal. Cet écoulement de service a un bas débit maximal mais est également configuré pour fournir une garantie de basse latence. Le prochain écoulement de service est pour le trafic général de Web et d'email. Cet écoulement de service a un débit élevé. L'écoulement final de service est réservé pour que le pair scrute le trafic (de P2P). Cet écoulement de service a un débit maximal plus restrictif à étrangler soutiennent la vitesse de cette application.

Figure 1 ? Un modem câblé avec trois écoulements de service ascendant

/image/gif/paws/69704/upstrm_sch_config_01.gif

Des écoulements de service sont établis et lancés quand un modem câble est livré d'abord en ligne. Provision les détails des écoulements de service dans le fichier de configuration DOCSIS que vous utilisez pour configurer le modem câble. Disposition au moins un écoulement de service pour le trafic en amont, et un autre écoulement de service pour le trafic en aval dans un fichier de configuration DOCSIS. Les premiers en amont et en aval écoulements de service que vous spécifiez dans le fichier de configuration DOCSIS s'appellent les écoulements primaires de service.

Des écoulements de service peuvent également être dynamiquement créés et lancés après qu'un modem câble soit livré en ligne. Ce scénario s'applique généralement au service un écoulement, qui correspond aux données qui appartiennent à un appel téléphonique VoIP. Un tel écoulement de service est créé et lancé quand une conversation téléphonique commence. L'écoulement de service est alors désactivé et supprimé quand l'appel finit. Si l'écoulement de service existe seulement si nécessaire, vous pouvez économiser les ressources en bande passante amont et le chargement et la mémoire du système CPU.

Les Modems câble ne peuvent pas faire les transmissions en amont n'importe quand. Au lieu de cela, les Modems doivent attendre des instructions du CMTS avant qu'ils puissent envoyer des données, parce que seulement un modem câble peut transmettre des données sur un canal ascendant à la fois. Autrement, les transmissions peuvent déborder et se corrompre. Les instructions pour quand un modem câble peut faire une transmission provenir le CMTS sous forme de message de tableau d'allocation de largeur de bande. Cisco CMTS transmet un message de MAP toutes les 2 millisecondes pour indiquer les Modems câble quand ils peuvent faire une transmission de la sorte. Chaque message de MAP contient les informations qui instruisent des Modems exactement quand faire une transmission, combien de temps la transmission peut durer, et quel type de données ils peuvent transmettre. Ainsi, les transmissions de données de modem câble ne se heurtent pas les uns avec les autres, et évitent la corruption des données. Cette section discute certaines des manières dans lesquelles un CMTS peut déterminer quand accorder une autorisation de modem câble de faire une transmission dans l'en amont.

Meilleur effort

L'établissement du programme de meilleur effort convient aux applications classiques d'Internet sans la condition requise stricte sur la latence ou le jitter. Les exemples de ces types d'applications incluent le transfert de fichiers d'email, de navigation web ou de peer-to-peer. L'établissement du programme de meilleur effort n'est pas approprié aux applications qui exigent la latence ou le jitter garanti, par exemple, la Voix ou le vidéo au-dessus de l'IP. C'est parce que dans congestionné ne conditionne aucune une telle garantie peut être fait en mode de meilleur effort. Les systèmes de DOCSIS 1.0 permettent seulement ce type d'établissement du programme.

Des écoulements de service de meilleur effort provisioned habituellement dans le fichier de configuration DOCSIS associé avec un modem câble. Par conséquent, les écoulements de service de meilleur effort sont généralement en activité dès que le modem câble sera livré en ligne. L'écoulement primaire de service ascendant, cela est le premier écoulement de service ascendant à provisioned dans le fichier de configuration DOCSIS, doit être un écoulement de service de style de meilleur effort.

Voici les paramètres les plus utilisés généralement qui définissent un écoulement de service de meilleur effort en mode DOCSIS 1.1/2.0 :

  • Débit de trafic soutenu par maximum (r)

    Le débit de trafic soutenu par maximum est le débit maximum auquel le trafic peut fonctionner au-dessus de cet écoulement de service. Cette valeur est exprimée dedans dans des bits par seconde.

  • Rafale maximum du trafic (b)

    La rafale maximum du trafic se rapporte à la taille de rafale dans les octets qui applique à la borne de débit de seau à jetons qui impose des limites en amont de débit. Si aucune valeur n'est spécifiée, la valeur par défaut de 3044 s'applique, qui est la taille de deux pleines trames d'Ethernets. Pour le grand maximum les débits de trafic soutenus, ont placé cette valeur pour être au moins le maximum débit de trafic soutenu divisé par 64.

  • Priorité du trafic

    Ce paramètre se rapporte à la priorité du trafic dans un écoulement de service s'étendant de 0 (le plus bas) à 7 (le plus élevé). Dans l'en amont tout le trafic en suspens pour des écoulements prioritaires de service sont programmés pour la transmission avant que le trafic pour le service de faible priorité circule.

  • Débit réservé minimum

    Ce paramètre indique qu'un minimum a garanti le débit dans des bits par seconde pour l'écoulement de service, semblables à un débit de données garanti (CIR). Les débits réservés minimum combinés pour tous les écoulements de service sur un canal ne doivent pas dépasser la bande passante disponible sur ce canal. Autrement il est impossible de garantir les débits réservés minimum promis.

  • Rafale concaténée par maximum

    La rafale concaténée par maximum est la taille dans les octets de la plus grande transmission des trames concaténées qu'un modem peut faire au nom de l'écoulement de service. Pendant que ce paramètre implique, un modem peut transmettre des plusieurs trames dans une rafale de transmission. Si cette valeur n'est pas spécifiée, les Modems câble de DOCSIS 1.0 et les Modems plus anciens de DOCSIS 1.1 supposent qu'il n'y a aucun positionnement de limite explicite sur la taille de rafale concaténée. Les Modems conformes avec des révisions plus récentes du DOCSIS 1.1 ou les caractéristiques postérieures utilisent une valeur de 1522 octets.

Quand un modem câble a des données à transmettre au nom d'un écoulement en amont de service de meilleur effort, le modem ne peut pas simplement expédier les données sur le réseau DOCSIS sans le retard. Le modem doit passer par un processus où le modem demande du délai de transmission en amont exclusif du CMTS. Ce processus de demande s'assure que les données ne se heurtent pas les transmissions d'un autre modem câble connecté au même canal ascendant.

Parfois le CMTS programme certaines périodes lesoù le CMTS permet à des Modems câble pour transmettre les messages spéciaux appelés les demandes de bande passante. La demande de bande passante est une trame très petite qui contient des détails de la quantité de données que le modem veut transmettre, plus un indentifiant de service (SID) qui correspond à l'écoulement de service ascendant qui doit transmettre les données. Le CMTS met à jour une table interne appariant des nombres SID aux écoulements de service ascendant.

Le CMTS programme des occasions de demande de bande passante quand aucun autre événement n'est programmé dans l'en amont. En d'autres termes, le programmateur fournit des occasions de demande de bande passante quand le programmateur en amont n'a pas prévu pour une concession de meilleur effort, ou concession UGS ou un autre type de concession d'être placé à un point précis. Par conséquent, quand un canal ascendant est fortement utilisé, moins occasions existent pour que les Modems câble transmettent des demandes de bande passante.

Le CMTS s'assure toujours qu'un nombre restreint d'occasions de demande de bande passante sont régulièrement programmées, n'importe comment congestionné le canal ascendant devient. Les plusieurs Modems câble peuvent transmettre des demandes de bande passante en même temps, et corrompre les transmissions de chacun. Afin de réduire le potentiel pour les collisions qui peuvent corrompre des demandes de bande passante, un algorithme de « interruption et de relance » est en place. Les parties suivantes de ce document discutent cet algorithme.

Quand le CMTS reçoit une demande de bande passante d'un modem câble, le CMTS exécute ces actions :

  1. Le CMTS utilise le nombre SID reçu dans la demande de bande passante d'examiner l'écoulement de service avec lequel la demande de bande passante est associée.

  2. Le CMTS utilise alors l'algorithme du seau à jetons. Cet algorithme aide le CMTS à vérifier si l'écoulement de service dépassera le débit soutenu prescrit de maximum si le CMTS accorde la bande passante demandée. Voici le calcul de l'algorithme du seau à jetons :

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

    où :

    • Maximum (T) indique le nombre maximal d'octets qui peut être transmis sur l'écoulement au fil du temps T. de service.

    • T représente le temps en quelques secondes.

    • R indique le débit de trafic soutenu par maximum pour l'écoulement de service dans des bits par seconde

    • B est la rafale maximum du trafic pour l'écoulement de service dans les octets.

  3. Quand le CMTS établit que la demande de bande passante est dans des limites de débit, le CMTS aligne les détails de la demande de bande passante au programmateur en amont. Le programmateur en amont décide quand accorder la demande de bande passante.

    L'ubr CMTS de Cisco implémente deux algorithmes en amont de programmateur, appelés le DOCSIS programmateur conforme et le programmateur de queue de basse latence. Voir le programmateur conforme DOCSIS sectionner et la section de queue de programmateur de basse latence de ce pour en savoir plus de document.

  4. Le CMTS inclut alors ces détails dans le prochain message périodique de tableau d'allocation de largeur de bande :

    • Quand le modem câble peut transmettre.

    • Pendant combien de temps le modem câble peut transmettre.

Interruption de demande de bande passante et algorithme de relance

Le mécanisme de demande de bande passante utilise un algorithme simple de « interruption et de relance » pour réduire, mais pour éliminer pas totalement, le potentiel pour des collisions entre les plusieurs Modems câble qui transmettent des demandes de bande passante simultanément.

Un modem câble qui décide de transmettre une demande de bande passante doit d'abord attendre un nombre aléatoire d'occasions de demande de bande passante de passer avant que le modem fasse la transmission. Ce temps d'attente aide à réduire la possibilité de collisions qui se produisent en raison des transmissions simultanées des demandes de bande passante.

Deux paramètres ont appelé le début d'interruption de données et l'extrémité d'interruption de données déterminent le délai d'attente aléatoire. Les Modems câble apprennent ces paramètres comme partie du contenu du message périodique du descripteur du canal ascendant (UCD). Le CMTS transmet le message UCD au nom de chaque canal ascendant actif toutes les deux secondes.

Ces paramètres d'interruption sont exprimés en tant que valeurs de « unité de deux ». Les Modems utilisent ces paramètres comme alimentations de deux de calculer combien de temps attendre avant qu'ils transmettent des demandes de bande passante. Les deux valeurs ont une plage de 0 à 15 et l'extrémité d'interruption de données doit être supérieur ou égal à début d'interruption de données.

La première fois qu'un modem câble veut transmettre une demande de bande passante particulière, le modem câble doit d'abord sélectionner un nombre aléatoire entre 0 et 2 à l'alimentation du début d'interruption de données sans 1. par exemple, si le début d'interruption de données est placé à 3, le modem doit sélectionner un nombre aléatoire entre 0 et (23 ? 1) = (8 ? 1) = 7.

Le modem câble doit alors attendre le nombre aléatoire sélectionné d'occasions de transmission de demande de bande passante de passer avant que le modem transmette une demande de bande passante. Ainsi, alors qu'un modem ne peut pas transmettre une demande de bande passante à la prochaine occasion disponible due à ce retard obligatoire, la possibilité d'une collision avec la transmission d'un autre modem réduit.

Naturellement plus la valeur de début d'interruption de données est élevée, inférieure est la possibilité de collisions entre la demande de bande passante. De plus grandes valeurs de début d'interruption de données signifient également que les Modems potentiellement doivent attendre plus long de transmettre des demandes de bande passante, et ainsi des augmentations en amont de latence.

Le CMTS inclut un accusé de réception dans le prochain message transmis de tableau d'allocation de largeur de bande. Cet accusé de réception informe le modem câble que la demande de bande passante a été avec succès reçue. Cet accusé de réception peut :

  • l'un ou l'autre indique exactement quand le modem peut faire la transmission

    OU

  • indiquez seulement que la demande de bande passante a été reçue et qu'un moment pour la transmission sera décidé dans un futur message de MAP.

Si le CMTS n'inclut pas un accusé de réception de la demande de bande passante dans le prochain message de MAP, le modem peut conclure que la demande de bande passante n'a pas été reçue. Cette situation peut se produire en raison d'une collision, ou du bruit en amont, ou parce que l'écoulement de service dépasse le débit prescrit de débit maximal si la demande est accordée.

Dans l'un ou l'autre de caisse, l'étape suivante pour le modem câble est à l'interruption, et à l'essai pour transmettre la demande de bande passante de nouveau. Le modem augmente la plage au-dessus dont une valeur aléatoire est choisie. Pour faire ainsi, le modem additionne un à la valeur de début d'interruption de données. Par exemple, si la valeur de début d'interruption de données est 3, et le CMTS ne reçoit pas une transmission de demande de bande passante, le modem attend une valeur aléatoire entre 0 et 15 occasions de demande de bande passante avant retransmission. Voici le calcul : 23+1 ? 1 = 24 ? 1 = 16 ? 1 = 15

La plage plus étendue des valeurs réduit la possibilité d'une autre collision. Si le modem perd d'autres demandes de bande passante, le modem continue à incrémenter la valeur utilisée comme unité de deux pour chaque retransmission jusqu'à ce que la valeur soit égale à l'extrémité d'interruption de données. L'unité de deux ne doit pas devenir soit plus grand que la valeur de fin d'interruption de données.

Le modem retransmet une demande de bande passante jusqu'à 16 fois, après quoi le modem jette la demande de bande passante. Cette situation se produit seulement en conditions extrêmement congestionnées.

Vous pouvez configurer le début d'interruption de données et les valeurs de fin d'interruption de données par en amont de câble sur un ubr CMTS de Cisco avec cette interface de câble commandent :

donnée-interruption-fin en amont de donnée-interruption-commencement de donnée-interruption d'en amont-port-id de câble

Cisco recommande que vous reteniez les valeurs par défaut pour les paramètres de donnée-interruption-commencement et de donnée-interruption-fin, qui sont 3 et 5. La nature conflit conflit du système d'établissement du programme de meilleur effort signifie que pour le meilleur effort le service circule, il est impossible pour fournir un déterministe ou garanti de niveau de la latence en amont ou à se trémousser. En outre, les conditions congestionnées peuvent le rendre impossible de garantir un niveau particulier de débit pour un écoulement de service de meilleur effort. Cependant, vous pouvez utiliser des propriétés d'écoulement de service comme la priorité et le débit réservé minimum. Avec ces propriétés, l'écoulement de service peut réaliser le niveau désiré du débit en conditions congestionnées.

Exemple de l'algorithme d'interruption et de relance

Cet exemple comporte quatre Modems câble nommés A, B, C et D, connectés au même canal ascendant. Au même instant appelé t0, les Modems A, le B et le C décident de transmettre quelques données dans l'en amont.

Ici, le début d'interruption de données est placé à 2 et l'extrémité d'interruption de données est placée à 4. La plage des intervalles desquels les Modems sélectionnent un intervalle avant qu'ils premier essai de transmettre une demande de bande passante soit entre 0 et 3. Voici le calcul :

(22 ? 1) = (4 ? 1) = 3 intervalles.

Voici le nombre d'occasions de demande de bande passante que les trois Modems sélectionnent pour attendre du temps t0.

  • Modem A : 3

  • Modem B : 2

  • C de modem : 3

Notez que le modem A et le C de modem sélectionnent le même nombre d'occasions d'attendre.

Le modem B attend deux occasions de demande de bande passante qui apparaissent après que le modem B t0. puis transmette la demande de bande passante, que le CMTS reçoit. Le modem A et le C de modem attendent 3 occasions de demande de bande passante de passer après les Modems A t0. et le C puis transmettent des demandes de bande passante en même temps. Ces deux demandes de bande passante se heurtent et deviennent corrompues. En conséquence, ni l'un ni l'autre demande n'atteint avec succès le CMTS. La figure 2 affiche cette séquence d'opérations.

Figure 2 ? Partie d'exemple de demande de bande passante

upstrm_sch_config_02.gif

La barre grise en haut du diagramme représente une gamme d'occasions de demande de bande passante disponibles aux Modems câble après le temps t0. Les flèches colorées représentent les demandes de bande passante que les Modems câble transmettent. La case colorée dans la barre grise représente une demande de bande passante qui atteint le CMTS avec succès.

La prochaine émission de message de MAP du CMTS ne contient une concession pour le modem B mais aucune instruction pour les Modems A et le C. Ceci indique aux Modems A et au C qu'ils doivent retransmettre leurs demandes de bande passante.

Sur le deuxième essai, le modem A et le C de modem doivent incrémenter l'unité de deux pour les utiliser quand ils calculent la plage des intervalles desquels pour sélectionner. Maintenant, le modem A et le C de modem sélectionnent un nombre aléatoire d'intervalles entre 0 et 7. Voici le calcul :

(22+1 -1) = (23 ? 1) = (8 ? 1) = 7 intervalles.

Supposez que le moment où le modem A et le C de modem réalisent la nécessité de retransmettre est t1. Supposez également qu'un autre modem appelé le modem D décide de transmettre quelques données en amont au même instant, t1. Le modem D est sur le point de faire une transmission de demande de bande passante pour la première fois. Par conséquent, le modem D utilise la valeur initiale pour le début d'interruption de données et l'extrémité d'interruption de données, à savoir entre 0 et 3 [(22 ? 1) = (4 ? 1) = 3 intervalles].

Les trois Modems sélectionnent ces nombre aléatoire d'occasions de demande de bande passante d'attendre du t1 de temps.

  • Modem A : 5

  • C de modem : 2

  • Modem D : 2

Le C de Modems et le D attendent deux occasions de demande de bande passante qui apparaissent après t1 de temps. Le C de Modems et le D transmettent alors des demandes de bande passante en même temps. Ces demandes de bande passante se heurtent et donc n'atteignent pas le CMTS. Le modem A permet cinq occasions de demande de bande passante de passer. Puis, le modem A transmet la demande de bande passante, que le CMTS reçoit. La figure 3 affiche la collision entre la transmission du C de Modems et D, et la réception réussie de la transmission du modem R. La référence heure de début pour cette figure est t1.

Figure 3 ? Partie d'exemple de demande de bande passante

upstrm_sch_config_03.gif

La prochaine émission de message de MAP du CMTS contient une concession pour le modem A mais instruction pour le C et le D. Modems C et D de Modems ne réalise pas la nécessité de retransmettre les demandes de bande passante. Le modem D est maintenant environ de transmettre la demande de bande passante pour la deuxième fois. Par conséquent, début d'interruption de données d'utilisations du modem D + 1 comme unité de deux à l'utiliser dans le calcul de la plage des intervalles pour attendre. Le modem D choisit un intervalle entre 0 et 7. Voici le calcul :

(22+1 ? 1) = (23 ? 1) = (8 ? 1) = 7 intervalles.

Le C de modem est sur le point de transmettre la demande de bande passante pour la troisième fois. Par conséquent, début d'interruption de données d'utilisations de C de modem + 2 comme unité de deux à dans le calcul de la plage des intervalles à attendre. Le C de modem choisit un intervalle entre 0 et 15. Voici le calcul :

(22+2 ? 1) = (24 ? 1) = (16 ? 1) = 15 intervalles.

Notez que l'unité de deux ici est identiques comme la valeur de fin d'interruption de données, qui est quatre. C'est le plus élevé qui la valeur d'unité de deux peut être pour un modem sur ce canal ascendant. Dans le prochain cycle de transmission de demande de bande passante, les deux Modems sélectionnent ces nombre d'occasions de demande de bande passante d'attendre :

  • C de modem : 9

  • Modem D : 4

Le modem D peut transmettre la demande de bande passante parce que le modem D attend quatre occasions de demande de bande passante de passer. En outre, le C de modem peut également transmettre la demande de bande passante, parce que le C de modem reporte maintenant la transmission pour neuf occasions de demande de bande passante.

Malheureusement, quand le C de modem fait une transmission, une grande rafale de bruit d'entrée gêne la transmission, et le CMTS ne reçoit pas la demande de bande passante (voir le schéma 4). En conséquence, de nouveau, le C de modem ne voit pas une concession dans le prochain message de MAP que le CMTS transmet. Ceci fait à tentative de C de modem une quatrième transmission de la demande de bande passante.

Figure 4 ? Partie d'exemple de demande de bande passante

upstrm_sch_config_04.gif

Le C de modem a déjà atteint la valeur de fin d'interruption de données de 4. C de modem ne peut pas augmenter la plage utilisée pour sélectionner un nombre aléatoire d'intervalles pour attendre. Par conséquent, le C de modem emploie de nouveau 4 comme unité de deux pour calculer la plage aléatoire. Le C de modem utilise toujours les intervalles de la plage 0 à 15 selon ce calcul :

(24 ? 1) = (16 ? 1) = 15 intervalles.

Sur la quatrième tentative, le C de modem peut faire une transmission réussie de demande de bande passante faute de conflit ou bruit.

Les plusieurs retransmissions de demande de bande passante du C de modem dans cet exemple explique ce qui peut se produire sur un canal ascendant congestionné. Cet exemple explique également les éventuels problèmes impliqués du mode de établissement du programme de meilleur effort et pourquoi l'établissement du programme de meilleur effort n'est pas approprié aux services qui exigent strictement les niveaux commandés de la latence de paquet et se trémoussent.

Priorité du trafic

Quand le CMTS a plusieurs en attendant des demandes de bande passante de plusieurs des écoulements de service, CMTS regarde la priorité du trafic de chaque écoulement de service pour décider lesquels pour accorder la bande passante d'abord.

Le délai de transmission de concessions CMTS à toutes les demandes en suspens des écoulements de service avec une haute priorité avant des demandes de bande passante de service circule avec une priorité plus basse. En conditions en amont congestionnées, ceci mène généralement au haut débit pour des écoulements prioritaires de service comparés aux écoulements de service de faible priorité.

Un important fait à noter est que tandis qu'un écoulement prioritaire de service de meilleur effort est pour recevoir la bande passante rapidement, l'écoulement de service est sujet toujours à la possibilité de collisions de demande de bande passante. Pour cette raison tandis que la priorité du trafic peut améliorer le débit et des caractéristiques de latence d'un service circulent, la priorité du trafic n'est toujours pas une manière appropriée de fournir une garantie de service pour les applications qui exigent un.

Débit réservé minimum

Les écoulements de service de meilleur effort peuvent recevoir un débit réservé minimum avec duquel pour se conformer. Le CMTS s'assure qu'un écoulement de service avec du débit réservé minimum spécifié reçoit la bande passante de préférence à tous autres écoulements de service de meilleur effort, indépendamment de la priorité.

Cette méthode est une tentative de fournir un type service de style du débit de données garanti (CIR) analogue à un réseau de Relais de trames. Le CMTS a des mécanismes de contrôle d'admission pour s'assurer que sur un en amont particulier le débit réservé minimum combiné de tous les écoulements connectés de service ne peut pas dépasser la bande passante disponible du canal ascendant, ou un pourcentage s'y rapportant. Vous pouvez lancer ces mécanismes avec ceci par commande de port ascendant :

[non] câblez la maximum-réservation-limite en amont de contrôle d'admission d'en amont-port-id

Le paramètre de maximum-réservation-limite a une plage de 10 à 1000 pour cent pour indiquer le niveau de l'abonnement par rapport au débit cru disponible de canal ascendant que les services de style CIR peuvent consommer. Si vous configurez une maximum-réservation-limite de plus considérablement que 100, l'en amont peut des services de style de l'oversubscribe CIR par la limite de pourcentage spécifiée.

Le CMTS ne permet pas de nouveaux écoulements minimum de service de débit réservé à établir s'ils feraient dépasser le port ascendant le pourcentage configuré de maximum-réservation-limite de la bande passante du canal ascendant disponible. Les écoulements minimum de service de débit réservé sont sujets toujours à des collisions potentielles des demandes de bande passante. En soi, les écoulements minimum de service de débit réservé ne peuvent pas fournir une garantie vraie d'un débit particulier, particulièrement en conditions extrêmement congestionnées. En d'autres termes, le CMTS peut seulement garantir qu'un écoulement minimum de service de débit réservé peut réaliser un débit en amont garanti par détail si le CMTS peut recevoir toutes les demandes de bande passante exigées du modem câble. Cette condition requise peut être réalisée si vous faites à l'écoulement de service un écoulement en temps réel de service du service d'interrogation (RTPS) au lieu d'un écoulement de service de meilleur effort. Voyez le pour en savoir plus en temps réel de section du service d'interrogation (RTPS).

Demandes de bande passante de ferroutage

Quand un écoulement en amont de service de meilleur effort transmet des trames à un haut débit, il est possible aux demandes de bande passante de ferroutage sur les trames de données en amont plutôt qu'ont la transmission distincte des demandes de bande passante. Les détails de la prochaine demande de la bande passante sont simplement ajoutés à l'en-tête d'un paquet de données étant transmis dans l'en amont au CMTS.

Ceci signifie que la demande de bande passante n'est pas sujette au conflit et a donc une occasion beaucoup plus élevée que la demande atteint le CMTS. Le concept des demandes de bande passante de ferroutage réduit le temps qu'une trame Ethernet prend pour atteindre l'équipement client (CPE) de l'utilisateur final, parce que le temps que la trame rentre la transmission en amont réduit. C'est parce que le modem n'a pas besoin de passer par l'interruption et de relancer le processus de transmission de demande de bande passante, qui peut être sujet à des retards.

La substitution d'identité des demandes de bande passante se produit typiquement dans ce scénario :

Tandis que le modem câble attend de transmettre une trame, dites X, dans l'en amont, le modem reçoit une autre trame, disent Y, d'un CPE pour transmettre dans l'en amont. Le modem câble ne peut pas ajouter les octets de la nouvelle trame Y en fonction à la transmission, parce que cela comporte l'utilisation d'un temps plus en amont que le modem est accordé. Au lieu de cela, le modem complète un champ dans l'en-tête DOCSIS de la trame X pour indiquer la quantité de délai de transmission exigée pour la trame Y.

Le CMTS reçoit la trame X et également les détails d'une demande de bande passante au nom de Y. sur la base de Disponibilité, le CMTS accorde au modem davantage de délai de transmission au nom du Y.

En termes très conservateurs, aussi courts que 5 millisecondes s'écoulent entre la transmission d'une demande de bande passante et la réception de l'allocation de bande passante aussi bien que TRACENT l'accusé de réception qui assigne l'heure pour la transmission de données. Ceci signifie cela pour que couvrir se produise, le modem câble doit recevoir des trames du CPE dans moins que 5ms de l'un l'autre.

C'est remarquable parce que, un codec typique VoIP comme utilise G.711 généralement une période d'inter-trame de 10 ou de 20ms. Un flot typique VoIP qui fonctionne au-dessus d'un écoulement de service de meilleur effort ne peut pas tirer profit de la substitution d'identité.

Enchaînement

Quand un écoulement en amont de service de meilleur effort transmet des trames à un haut débit, le modem câble peut joindre quelques unes des trames ensemble et demander l'autorisation de transmettre les trames d'un seul trait. Ceci s'appelle l'enchaînement. Le modem câble doit transmettre seulement une demande de bande passante au nom de toutes les trames dans un groupe de trames concaténées, qui améliore l'efficacité.

L'enchaînement tend à se produire dans les circonstances semblables à la substitution d'identité sauf que l'enchaînement exige des plusieurs trames d'être alignées à l'intérieur du modem câble quand le modem décide de transmettre une demande de bande passante. Ceci implique que l'enchaînement tend à se produire à des fréquences de trame moyennes plus élevées que couvrant. En outre, les deux mécanismes fonctionnent généralement ensemble pour améliorer l'efficacité du trafic de meilleur effort.

Le champ de rafale concaténé par maximum que vous pouvez configurer pour un écoulement de service limite la taille maximale d'une trame concaténée qu'un écoulement de service peut transmettre. Vous pouvez également utiliser la commande de par défaut-phy-rafale de câble de limiter la taille d'une trame concaténée et la taille de rafale maximale dans le profil de modulation de canal ascendant.

L'enchaînement est activé par défaut sur les ports ascendants de la gamme d'ubr de Cisco de CMTS. Cependant, vous pouvez contrôler l'enchaînement sur une base de par-en amont-port avec [non] la commande en amont d'interface de câble de l'enchaînement [docsis10] d'en amont-port-id de câble.

Si vous configurez le paramètre docsis10, la commande applique seulement aux Modems câble qui fonctionnent en mode de DOCSIS 1.0.

Si vous apportez des modifications à cette commande, les Modems câble doivent re-registre sur le CMTS pour que les modifications les prennent effet. Les Modems sur l'en amont affecté doivent être remis à l'état initial. Un modem câble apprend si l'enchaînement est permis au point où le modem exécute l'enregistrement en tant qu'élément du processus d'être livré en ligne.

Fragmentation

Les grandes trames prennent un longtemps de transmettre dans l'en amont. Ce délai de transmission est connu comme retard de fabrication en série. Particulièrement les grandes trames en amont peuvent prendre si long pour transmettre qu'elles peuvent nocivement retarder les paquets qui appartiennent aux services sensibles au temps, par exemple, VoIP. Cela vaut particulièrement pour de grandes trames concaténées. Pour cette raison, la fragmentation a été introduite dans le DOCSIS 1.1 de sorte que de grandes trames puissent être coupées en plus petites trames pour la transmission dans des rafales distinctes cette chaque prise moins d'heure de transmettre.

La fragmentation permet de petites, sensibles au temps trames à intercaler entre les fragments de grandes trames plutôt que devant attendre la transmission de la grande trame entière. La transmission d'une trame en tant que plusieurs fragments est légèrement moins efficace que la transmission d'une trame dans un en raison éclaté de l'ensemble supplémentaire d'en-têtes DOCSIS qui doivent accompagner chaque fragment. Cependant, la flexibilité que la fragmentation ajoute au canal ascendant justifie le temps système supplémentaire.

Les Modems câble qui fonctionnent en mode de DOCSIS 1.0 ne peuvent pas exécuter la fragmentation.

La fragmentation est activée par défaut sur les ports ascendants de la gamme d'ubr de Cisco de CMTS. Cependant, vous pouvez activer ou désactiver la fragmentation sur une base de par-en amont-port avec [non] la commande en amont d'interface de câble de fragmentation d'en amont-port-id de câble.

Vous n'avez pas besoin de remettre à l'état initial des Modems câble pour que la commande la prenne effet. Cisco recommande que vous fassiez toujours activer la fragmentation. La fragmentation se produit normalement quand le CMTS croit qu'une grande trame de données peut gêner la transmission de petites trames sensibles au temps ou de certains événements périodiques de Gestion DOCSIS.

Vous pouvez forcer des Modems câble DOCSIS 1.1/2.0 pour fragmenter toutes les grandes trames avec [non] la commande en amont d'interface de câble de fragment-force d'en amont-port-id de câble [nombre-de-fragments de seuil].

Par défaut, cette caractéristique est désactivée. Si vous ne spécifiez pas des valeurs pour le seuil et des nombre-de-fragments dans la configuration, le seuil est placé à 2000 octets et le nombre de fragments est placé à 3. La commande de fragment-force compare le nombre d'octets qu'un écoulement de service demande pour la transmission avec le paramètre spécifié de seuil. Si la taille de demande est plus grande que le seuil, le CMTS accorde la bande passante au service-écoulement dans les pièces également classées de « nombre-de-fragments ».

Par exemple, supposez que cela une fragment-force en amont particulière est activé avec une valeur de 2000 octets pour le seuil et de 3 pour des nombre-de-fragments. Supposez alors qu'une demande de transmettre une rafale de 3000 octets arrive. Car 3000 octets est plus grand que le seuil de 2000 octets, la concession doit être fragmentée. Car les nombre-de-fragments est placés à 3, le délai de transmission est trois concessions également classées de 1000 octets chacune.

Prenez le soin de s'assurer que les tailles de différents fragments ne dépassent pas la capacité du type de linecard de câble en service. Pour des linecards MC5x20S, le plus grand fragment individuel ne doit pas dépasser 2000 octets, et pour d'autres linecards, y compris le MC28U, MC5x20U et MC5x20H, le plus grand fragment individuel ne doivent pas dépasser 4000 octets.

Service non sollicité de Grant (UGS)

Le service non sollicité de Grant (UGS) fournit des concessions périodiques pour un écoulement de service ascendant sans besoin d'un modem câble de transmettre des demandes de bande passante. Ce type de service convient aux applications qui génèrent les trames à taille fixe à intervalles réguliers et est intolérant de la perte de paquets. La voix sur ip est l'exemple classique.

Comparez le système d'établissement du programme UGS à un intervalle de temps dans un système du multiplexage temporel (TDM) tel qu'un circuit de t1 ou d'E1. L'UGS fournit un débit et une latence garantis, qui fournit consécutivement le flux continu des intervalles périodiques fixes pour transmettre sans besoin du client périodiquement de demander ou contester pour la bande passante. Ce système est parfait pour le VoIP parce que le trafic vocal est généralement transmis comme flux continu des données périodiques à taille fixe.

L'UGS a été conçu en raison du manque de garanties pour la latence, le jitter et le débit en mode de établissement du programme de meilleur effort. Le mode de établissement du programme de meilleur effort ne fournit pas l'assurance qu'une trame particulière peut être transmise à un moment particulier, et dans un système congestionné il n'y a aucune assurance qu'une trame particulière peut être transmise du tout.

Notez que bien que les écoulements de service de style UGS soient le type le plus approprié d'écoulement de service pour donner le trafic de support VoIP, ils ne sont pas considérés appropriés pour des applications classiques d'Internet telles que le Web, l'email ou le P2P. C'est parce que les applications classiques d'Internet ne génèrent pas des données à intervalles périodiques fixes et peuvent, en fait, passer des transmissions de données significatives de périodes pas du tout. Si un écoulement de service UGS est utilisé pour donner le trafic sur Internet classique, l'écoulement de service peut disparaître inutilisé pendant des périodes significatives où l'application arrête brièvement des transmissions. Ceci mène aux concessions inutilisées UGS qui représentent un gaspillage de ressources en bande passante amont qui n'est pas desirable.

Les écoulements de service UGS sont habituellement dynamiquement quand ils sont exigés plutôt que provisioned établi dans le fichier de configuration DOCSIS. Un modem câble avec les ports intégrés VoIP peut habituellement demander au CMTS pour créer un écoulement approprié de service UGS quand le modem le détecte qu'un appel téléphonique VoIP est en cours.

Cisco recommande que vous ne configuriez pas un écoulement de service UGS dans un fichier de configuration DOCSIS parce que cette configuration maintient l'écoulement de service UGS actif pour tant que le modem câble est en ligne si n'importe quelle utilisation de services il. Cette configuration gaspille la bande passante amont parce qu'un écoulement de service UGS réserve constamment le délai de transmission en amont au nom du modem câble. Il vaut bien mieux de permettre l'écoulement de service UGS à créer et être supprimé dynamiquement de sorte que l'UGS soit en activité en cas de besoin.

Voici les paramètres les plus utilisés généralement qui définissent un écoulement de service UGS :

  • Taille non sollicitée (G) de Grant — La taille de chaque concession périodique dans les octets.

  • Intervalle nominal de Grant (i) — L'intervalle en quelques microsecondes entre les concessions.

  • Jitter toléré de Grant (j) — La variation permise des microsecondes des concessions exactement périodiques. En d'autres termes, c'est la marge de sécurité que le CMTS a quand le CMTS essaye de programmer une concession UGS à l'heure.

Quand un écoulement de service UGS est en activité, chaque (i) millisecondes, le CMTS offre une occasion pour que l'écoulement de service transmette aux octets non sollicités de la taille (G) de Grant. Bien qu'idéalement le CMTS offre à la concession exactement chaque (i) millisecondes, il peut être tardif par jusqu'(j) à des millisecondes.

La figure 5 affiche une chronologie qui explique comment des concessions UGS peuvent être allouées avec une taille donnée de concession, un intervalle de concession et un jitter toléré.

Figure 5 ? La chronologie qui affiche l'UGS périodique accorde

/image/gif/paws/69704/upstrm_sch_config_05.gif

Les blocs modelés par vert représentent le temps où le CMTS dédie le délai de transmission en amont à un écoulement de service UGS.

Service en temps réel d'interrogation (RTPS)

Le service en temps réel d'interrogation (RTPS) fournit des occasions basées sur non conflit périodiques de demande de bande passante de sorte qu'un écoulement de service ait dédié l'heure de transmettre des demandes de bande passante. Seulement on permet à l'l'écoulement de service RTPS pour utiliser cette occasion de demande de bande passante d'unicast. D'autres Modems câble ne peuvent pas entraîner une collision de demande de bande passante.

RTPS convient aux applications qui génèrent les trames de longueur variable sur une base semi-périodique et exigent d'un débit minimum garanti de fonctionner efficacement. La téléphonie vidéo au-dessus du jeu en ligne IP ou de lecteur multi sont des exemples typiques.

RTPS est également utilisé pour le trafic de signalisation VoIP. Tandis que le trafic de signalisation VoIP n'a pas besoin d'être transmis par extrêmement - la basse latence ou jitter, VoIP doit avoir une probabilité élevée de pouvoir atteindre le CMTS dans un laps de temps raisonnable. Si vous utilisez RTPS plutôt que le meilleur effort vous programmant peut être assurément qui expriment la signalisation ne sont pas sensiblement retardés ou en raison relâché des collisions répétées de demande de bande passante.

Un écoulement de service RTPS possède typiquement ces attributs :

  • Intervalle de sondage nominal — L'intervalle en quelques microsecondes entre les occasions de demande de bande passante d'unicast.

  • Jitter toléré de balayage — La variation permise des microsecondes des balayages exactement périodiques. Mettez une autre manière, ceci est la marge de sécurité que le CMTS a en essayant pour programmer une occasion de demande de bande passante d'unicast RTPS à l'heure.

La figure 6 affiche une chronologie qui explique comment des balayages RTPS sont alloués avec un intervalle de sondage nominal donné et un jitter toléré de balayage.

Figure 6 ? Chronologie qui affiche l'interrogation périodique RTPS

/image/gif/paws/69704/upstrm_sch_config_06.gif

Les blocs modelés petit par vert représentent le temps où le CMTS donne à un écoulement de service RTPS une occasion de demande de bande passante d'unicast.

Quand le CMTS reçoit une demande de bande passante au nom d'un écoulement de service RTPS, le CMTS traite la demande de bande passante de la même manière qu'une demande d'un écoulement de service de « meilleur effort ». Ceci signifie qu'en plus des paramètres ci-dessus, de telles propriétés que le maximum a soutenues priorité de débit de trafic et de trafic doivent être incluses dans une définition d'écoulement de service RTPS. Un écoulement de service RTPS contient généralement également un débit de trafic réservé minimum afin de s'assurer que le trafic associé avec l'écoulement de service peut recevoir une garantie commise de bande passante.

Service non sollicité de Grant avec la détection d'activité (UGS-AD)

Le service non sollicité de concession avec la détection d'activité (UGS-AS) assigne le délai de transmission de style UGS à un écoulement de service seulement quand les besoins UGS-AS réellement de transmettre des paquets. Quand le CMTS le détecte que le modem câble n'a pas transmis des trames pendant une certaine période, CMTS donne des occasions de demande de bande passante de style RTPS au lieu des concessions de style UGS. Si le CMTS le détecte ultérieurement que l'écoulement de service fait des demandes de bande passante, le CMTS retourne l'écoulement de service de nouveau à offrir le style UGS accorde et cesse de donner des occasions de demande de bande passante de style RTPS.

UGS-AD est typiquement utilisé dans une situation où le trafic VoIP qui a utilisé la détection d'activité vocale (VAD) était donné. La détection d'activité vocale fait arrêter le point final VoIP la transmission des trames VoIP si UGS-AD détecte une pause dans le discours de l'utilisateur. Bien que ce comportement puisse sauvegarder la bande passante, il peut poser des problèmes avec la Qualité vocale, particulièrement si le mécanisme de détection de l'activité VAD ou UGS-AD lance légèrement après que les débuts d'interlocuteur d'extrémité pour reprendre parler. Ceci peut mener à un bruit sautant ou cliquant sur pendant qu'un utilisateur reprend parler après silence. Pour cette raison UGS-AD n'est pas largement déployé.

Émettez la commande de configuration globale des seuil-dans-secondes CMTS d'inactivité-seuil d'écoulement de service par câble de fixer la période après quoi le CMTS commute un écoulement inactif de service UGS-AD de mode UGS au mode RTPS.

La valeur par défaut pour le paramètre de seuil-dans-secondes est de 10 secondes. UGS-AD de service d'écoulements bandes généralement que les attributs d'un service UGS circulent et l'intervalle de sondage nominal et l'attribut toléré de jitter de balayage associés avec le service RTPS circule.

Service non en temps réel d'interrogation (nRTPS)

Le mode de établissement du programme non en temps réel de service d'interrogation (nRTPS) est essentiellement identique que RTPS sauf que nRTPS est généralement associé avec des services non interactifs tels que des transferts de fichiers. Le composant non en temps réel peut impliquer que l'intervalle de sondage nominal pour des occasions de demande de bande passante d'unicast ne sont pas exactement militaire de carrière ou peut se produire à un taux de moins d'un par seconde.

Quelques opérateurs de réseau câblé peuvent choisir d'employer le nRTPS au lieu des écoulements de service RTPS pour donner le trafic de signalisation de Voix.

Algorithmes de planification

Avant une discussion sur les particularités du programmateur conforme DOCSIS et du programmateur de queue de basse latence, vous devez comprendre les compromis que vous devez faire afin de déterminer les caractéristiques d'un programmateur en amont. Bien que l'examen des algorithmes de programmateur porte principalement sur le mode de établissement du programme UGS la discussion s'applique également aux services de style RTPS aussi bien.

Quand vous décidez comment programmer des écoulements de service UGS il n'y a pas beaucoup d'options flexibles. Vous ne pouvez pas faire le programmateur changer la taille de concession ou l'intervalle de concession du service UGS circule, parce qu'une telle modification fait échouer des appels VoIP complètement. Cependant, si vous changez le jitter, les appels fonctionnent, quoique probablement avec la latence accrue sur l'appel. En outre, la modification du nombre maximal d'appels permis sur un en amont n'affecte pas la qualité de différents appels. , Considérez par conséquent ces deux facteurs principaux quand vous programmez un grand nombre d'écoulements de service UGS :

  • Jitter

  • Capacité d'écoulement de service UGS par en amont

Jitter

Un jitter toléré de concession est spécifié comme un des attributs écoulement UGS ou RTPS de service. Cependant, le support simultané de quelques écoulements de service avec très le jitter toléré par bas et d'autres avec très un grand nombre de jitter peut être inefficace. Généralement vous devez faire un choix uniforme quant au type de jitter que le service circule l'expérience sur un en amont.

Si des bas niveaux du jitter sont exigés, le programmateur doit être inflexible et rigide quand il programme des concessions. Par conséquent, le programmateur doit imposer des restrictions au nombre d'écoulements de service UGS pris en charge sur un en amont.

Les niveaux de jitter n'ont pas besoin toujours d'être extrêmement - bas pour le consommateur normal VoIP parce que la technologie de mémoire tampon de jitter peut compenser des hauts niveaux de jitter. Les mémoires tampons modernes de jitter de l'adaptatif VoIP peuvent compenser plus que 150ms de jitter. Cependant, un réseau VoIP ajoute la quantité de mise en mémoire tampon qui se produit à la latence des paquets. Les hauts niveaux de la latence peuvent contribuer à une expérience plus pauvre VoIP.

L'UGS entretiennent la capacité d'écoulement par en amont

Les attributs de couche physique tels que la largeur de canal, le schéma de modulation et le point fort de correction d'erreurs déterminent la capacité physique d'un en amont. Cependant, le nombre d'écoulements simultanés de service UGS que l'en amont peut prendre en charge également dépend de l'algorithme de programmateur.

Si extrêmement - les niveaux de gigue faible ne sont pas nécessaires, vous pouvez détendre la rigidité du programmateur et couvrir un nombre supérieur d'écoulements de service UGS que l'en amont peut simultanément prendre en charge. Vous pouvez réaliser un rendement plus élevé du trafic non vocal dans l'en amont si vous détendez les conditions requises de jitter.

Remarque: Les différents algorithmes de planification peuvent permettre à un canal ascendant particulier pour prendre en charge de divers nombres de service UGS et RTPS circule. Cependant, de tels services ne peuvent pas utiliser 100% de la capacité en amont dans un système DOCSIS. C'est parce que le canal ascendant doit dédier une partie au trafic d'administration DOCSIS tel que les messages de maintenance initiale qui utilisation de Modems câble d'établir le contact initial avec le CMTS, et le trafic de keepalive de maintenance de station utilisé pour s'assurer que les Modems câble peuvent mettre à jour la Connectivité au CMTS.

Le programmateur conforme DOCSIS

Le programmateur conforme DOCSIS est le système par défaut pour des services ascendants de établissement du programme sur un ubr CMTS de Cisco. Ce programmateur a été conçu pour réduire le jitter que les écoulements de service UGS et RTPS éprouvent. Cependant, ce programmateur te permet toujours pour mettre à jour un certain degré de flexibilité afin d'optimiser le nombre d'appels simultanés UGS par en amont.

Le programmateur conforme DOCSIS préaffecte l'heure en amont à l'avance pour des écoulements de service UGS. Avant que toutes les autres allocations de bande passante soient programmées, le CMTS a mis de côté l'heure à l'avenir pour les concessions qui appartiennent aux écoulements actifs de service UGS pour s'assurer qu'aucun des autres types de service ne circule ou le trafic déplacent les concessions UGS et entraînent le jitter significatif.

Si le CMTS reçoit des demandes de bande passante au nom des écoulements de service de style de meilleur effort, le CMTS doit programmer le délai de transmission pour les écoulements de service de meilleur effort autour de l'UGS préaffecté accorde afin de ne pas l'affecter sur l'établissement du programme opportun de chaque concession UGS.

Configuration

Le programmateur conforme DOCSIS est le seul algorithme ascendant disponible de programmateur pour les versions du logiciel Cisco IOS 12.3(9a)BCx et plus tôt. Par conséquent, ce programmateur n'exige aucune commande de configuration pour le lancement.

Pour les versions du logiciel Cisco IOS 12.3(13a)BC et plus tard, le programmateur conforme DOCSIS est l'un de deux algorithmes alternatifs de programmateur, mais est placé comme programmateur par défaut. Vous pouvez activer le programmateur conforme DOCSIS pour un, toute l'ou certaines ces derniers les types de établissement du programme :

  • UGS

  • RTPS

  • NRTPS

Vous pouvez explicitement activer le programmateur conforme DOCSIS pour chacun de ces types de établissement du programme avec le type de établissement du programme de port ascendant en amont de câble [nrtps | rtps | commande d'interface de câble de docsis de mode UGS].

L'utilisation du programmateur conforme DOCSIS fait partie de la configuration par défaut. Par conséquent, vous devez exécuter cette commande seulement si vous changez de retour de l'algorithme de queue de programmateur de basse latence de non-par défaut. Voyez le pour en savoir plus de queue de section de programmateur de basse latence.

Contrôle d'admission

Un grand avantage du programmateur conforme DOCSIS est que ce programmateur s'assure que les écoulements de service UGS au-dessus de ne s'abonnent pas l'en amont. Si un nouvel écoulement de service UGS doit être établi, et le programmateur le découvre qu'un pré-programme des concessions n'est pas possible parce qu'aucune pièce n'est partie, le CMTS rejette le nouvel écoulement de service UGS. Si on permet des écoulements de service UGS qui donnent le trafic VoIP à l'oversubscribe un canal ascendant, la qualité de tous les appels VoIP devient sévèrement dégradée.

Afin d'expliquer comment le programmateur conforme DOCSIS s'assure que le service UGS ne circule jamais l'oversubscribe l'en amont, référez-vous aux figures dans cette section. 8 et 9 d'exposition de bande passante d'allocation chronologies de figures 7.

Dans toutes ces figures, les sections modelées en couleurs affichent au temps où les Modems câble reçoivent des concessions au nom de leurs écoulements de service UGS. Aucune autre transmission en amont d'autres Modems câble ne peut se produire pendant ce temps. La partie grise de la chronologie est jusqu'à présent bande passante non affectée. Les Modems câble passent ce temps de transmettre des demandes de bande passante. CMTS peut plus tard passer ce temps de programmer d'autres types de services.

Figure 7 ? Pré-programmes conformes de programmateur DOCSIS trois écoulements de service UGS

/image/gif/paws/69704/upstrm_sch_config_07.gif

Ajoutez deux écoulements supplémentaires de service UGS de la mêmes taille de concession et intervalle de concession. Toujours, le programmateur n'a aucun problème pré-les programmant.

Figure 8 ? Pré-programmes conformes de programmateur DOCSIS cinq écoulements de service UGS

/image/gif/paws/69704/upstrm_sch_config_08.gif

Si vous avancez et ajoutez deux écoulements supplémentaires de service UGS, vous remplissez toute la bande passante amont disponible.

Figure 9 ? Les écoulements de service UGS consomment toute la bande passante amont disponible

/image/gif/paws/69704/upstrm_sch_config_09.gif

Clairement, le programmateur ne peut pas admettre tout autre écoulement de service UGS ici. Par conséquent si des autres essais d'écoulement de service UGS à devenir actifs, le programmateur conforme DOCSIS se rend compte qu'il n'y a aucune pièce pour d'autres concessions, et empêche l'établissement de cet écoulement de service.

Remarque: Il est impossible de remplir complètement en amont d'écoulements de service UGS comme vu dans cette gamme de figures. Le programmateur doit faciliter d'autres importants types de trafic par exemple, Keepalives de maintenance de station et trafic de données de meilleur effort. En outre, la garantie pour éviter le surabonnement avec le programmateur conforme DOCSIS s'applique seulement si tous les modes de établissement du programme d'écoulement de service, à savoir UGS, RTPS et nRTPS, utilisent le programmateur conforme DOCSIS.

Bien que la configuration de contrôle d'admission explicite ne soit pas nécessaire quand vous utilisez le programmateur conforme DOCSIS, Cisco recommande que vous vous assuriez que l'utilisation du canal ascendant ne monte pas aux niveaux qui peuvent négativement affecter le trafic de meilleur effort. Cisco recommande également que l'utilisation du canal ascendant de total ne doive pas dépasser 75% pour des quantités significatives de temps. C'est le niveau du début en amont de services de meilleur effort d'utilisation où éprouver une latence beaucoup plus élevée et un débit plus lent. Les services UGS fonctionnent toujours, indépendamment de l'utilisation en amont.

Si vous voulez limiter le niveau de trafic admis sur un en amont particulier, configurez le contrôle d'admission pour l'UGS, le RTPS, le NRTPS, l'UGS-AD ou le service de meilleur effort circule avec le global, par interface de câble ou par commande en amont. Le paramètre le plus important est l'exclusivité-seuil-pour cent mettent en place.

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]

Voici les paramètres :

  • [<upstream-number> en amont] : Spécifiez ce paramètre si vous voulez s'appliquer la commande à un en amont particulier plutôt qu'une interface de câble ou globalement.

  • <UGS|AD-UGS|RTPS|NRTPS|BE> : Ce paramètre spécifie le mode de établissement du programme des écoulements de service auxquels vous voulez appliquer le contrôle d'admission.

  • <minor-threshold-percent> : Ce paramètre indique le pourcentage de l'utilisation en amont par le type de établissement du programme configuré auquel une alarme mineure est envoyée à une station de Gestion de réseau.

  • <major-threshold-percent> : Ce paramètre spécifie le pourcentage de l'utilisation en amont par le type de établissement du programme configuré auquel une alarme principale est envoyée à une station de Gestion de réseau. Cette valeur doit être supérieur à la valeur vous réglé pour le paramètre de <minor-threshold-percent>.

  • <exclusive-threshold-percent> : Ce paramètre représente le pourcentage de l'utilisation en amont exclusivement réservé pour le programmer-type spécifié. Si vous ne spécifiez pas la valeur pour le <non-excl-threshold-percent>, cette valeur représente la limite maximum sur l'utilisation pour ce type de service-écoulement. Cette valeur doit être plus grande que la valeur de <major-threshold-percent>.

  • <non-excl-threshold-percent> : Ce paramètre représente le pourcentage de l'utilisation en amont au-dessus du <exclusive-threshold-percent> que ce type de établissement du programme peut utiliser, tant que un autre type de établissement du programme ne l'utilise pas déjà.

Par exemple, supposez que vous voulez limiter les écoulements de service UGS à 60% de toute la bande passante amont disponible. Supposez également que vous faites annoncer des stations de Gestion de réseau qui si le pourcentage de l'utilisation en amont dû aux écoulements de service UGS montait plus de 40%, une alarme mineure doivent être envoyées et plus de 50%, une alarme principale devez être envoyé. Émettez la commande suivante :

câblez l'exclusivité 60 du commandant 50 du mineur 40 UGS de programmer-type de nous-bande passante de contrôle d'admission

Le trafic de meilleur effort de Scheduling utilisant la fragmentation

Le programmateur conforme DOCSIS programme simplement le trafic de meilleur effort autour des concessions préaffectées UGS ou RTPS. Les figures dans cette section expliquent ce comportement.

Figure 10 ? Le meilleur effort accorde en attendant le Scheduling

/image/gif/paws/69704/upstrm_sch_config_10.gif

La figure 10 prouve que l'en amont a trois écoulements de service UGS avec la mêmes taille de concession et intervalle de concession pré-programmés. En amont reçoit demande de bande passante au nom de trois distinct service écoulement, A, l'écoulement A B et de C. Service demande d'une quantité moyenne de délai de transmission, l'écoulement B de service demande d'un peu de délai de transmission et le C d'écoulement de service demande d'un grand nombre de délai de transmission.

La priorité égale d'Accord à chacun du service de meilleur effort circule. En outre, supposez que le CMTS reçoit les demandes de bande passante pour chacune de ces concessions dans la commande A puis B, et puis C. Le CMTS alloue d'abord le délai de transmission pour les concessions dans la même commande. La figure 11 affiche comment le DOCSIS des schedulers allocate conformes ces concessions.

Figure 11 ? Concessions de meilleur effort programmées autour des concessions fixes d'écoulement de service UGS

/image/gif/paws/69704/upstrm_sch_config_11.gif

Le programmateur peut comprimer les concessions pour A et B ensemble dans l'écart entre les deux premiers blocs de concessions UGS. Cependant, la concession pour le C est plus grande que n'importe quel écart disponible. Par conséquent, le programmateur conforme DOCSIS fragmente la concession pour le C autour du troisième bloc de concessions UGS dans deux plus petites concessions appelées C1 et le C2. La fragmentation empêche des retards pour des concessions UGS, et s'assure que ces concessions ne sont pas sujettes au jitter que le trafic de meilleur effort entraîne.

La fragmentation augmente légèrement le temps système de protocole DOCSIS associé avec la transmission de données. Pour chaque fragment supplémentaire transmis, un ensemble supplémentaire d'en-têtes DOCSIS doit également être transmis. Cependant, sans fragmentation le programmateur ne peut pas efficacement intercaler des concessions de meilleur effort entre les concessions fixes UGS. La fragmentation ne peut pas se produire pour les Modems câble qui fonctionnent en mode de DOCSIS 1.0.

Priorité

Le programmateur conforme DOCSIS place les concessions qui attendent l'allocation dans des files d'attente basées sur la priorité de l'écoulement de service auquel la concession appartient. Il y a huit priorités DOCSIS avec zéro en tant que plus bas et sept en tant que plus élevé. Chacune de ces priorités a une file d'attente associée.

Le programmateur conforme DOCSIS utilise un mécanisme de mise en file d'attente strict prioritaire pour déterminer quand des concessions de la priorité différente sont allouées délai de transmission. En d'autres termes, toutes les concessions enregistrées dans les files d'attente prioritaire doivent être servies avant des concessions dans les files d'attente de faible priorité.

Par exemple, supposez que le programmateur conforme DOCSIS reçoit cinq concessions dans une brève période dans la commande A, B, C, D, E et F. Les files d'attente du planificateur des travaux chacune des concessions dans la file d'attente qui correspond à la priorité de l'écoulement de service de la concession.

Figure 12 ? Concessions avec différentes priorités

upstrm_sch_config_12.gif

Les concessions conformes de meilleur effort de programmes de programmateur DOCSIS autour des concessions pré-programmées UGS qui apparaissent en tant que blocs modelés dans la figure 12. La première action les prises conformes de programmateur DOCSIS est de vérifier la file d'attente la plus prioritaire. Dans ce cas la file d'attente prioritaire 7 a des concessions prêtes à programmer. Le programmateur avance et alloue le délai de transmission pour les concessions B et E. Notez que la concession E a besoin de fragmentation de sorte que la concession ne gêne pas la synchronisation des concessions préaffectées UGS.

Figure 13 ? Concessions de la priorité de planification 7

/image/gif/paws/69704/upstrm_sch_config_13.gif

Le programmateur veille que toutes les concessions prioritaire 7 reçoivent le délai de transmission. Puis, le programmateur vérifie la file d'attente prioritaire 6. Dans ce cas, la file d'attente prioritaire 6 est allumée vide ainsi les mouvements de programmateur à la file d'attente prioritaire 5 qui contient le C de concession.

Figure 14 ? Concessions de la priorité de planification 5

/image/gif/paws/69704/upstrm_sch_config_14.gif

Le programmateur poursuit alors de la même façon par les files d'attente de faible priorité jusqu'à ce que toutes les files d'attente soient vides. S'il y a un grand nombre de concessions à programmer, les nouvelles demandes de bande passante peuvent atteindre le CMTS avant que le programmateur conforme DOCSIS termine l'allocation du délai de transmission à toutes les concessions en attente. Supposez que le CMTS reçoit une demande de bande passante G de la priorité 6 en ce moment dans l'exemple.

Figure 15 ? Une priorité 6 Grant est alignée

/image/gif/paws/69704/upstrm_sch_config_15.gif

Quoiqu'accorde l'attente A, F et D plus longue que la concession nouvellement alignée G, le programmateur conforme DOCSIS doit ensuite allouer le délai de transmission à G parce que G a la haute priorité. Ceci signifie que les prochaines allocations de bande passante du programmateur conforme DOCSIS seront G, A puis D (voir la figure 16).

Figure 16 ? Priorité de planification 6 et concessions prioritaire 2

/image/gif/paws/69704/upstrm_sch_config_16.gif

La prochaine concession à programmer est F, si vous supposez que concession de haute priorité n'entre pas dans le système de mise en file d'attente au même moment.

Le programmateur conforme DOCSIS a deux files d'attente supplémentaires qui n'ont pas été mentionnées dans les exemples. La première file d'attente est la file d'attente utilisée pour programmer le trafic périodique de keepalive de maintenance de station afin de maintenir des Modems câble en ligne. Cette file d'attente est utilisée pour programmer des occasions pour que des Modems câble envoient au CMTS le trafic périodique de keepalive. Quand le programmateur conforme DOCSIS est en activité, cette file d'attente est servie d'abord avant toutes autres files d'attente. Le deuxième est une file d'attente pour des concessions allouées pour entretenir des écoulements avec du débit réservé minimum (CIR) spécifié. Le programmateur traite cette file d'attente CIR car une file d'attente prioritaire 8 afin de s'assurer que les écoulements de service avec du débit engagé reçoivent le débit minimum exigé.

Concessions de DOCSIS 1.0 d'Unfragmentable

Des exemples dans la section précédente, des concessions doivent parfois être fragmentées dans de plusieurs parties afin de s'assurer que le jitter n'est pas induit dans des concessions préaffectées UGS. Ceci peut être un problème pour les Modems câble qui fonctionnent en mode de DOCSIS 1.0 sur des segments en amont avec une importante quantité de trafic UGS, parce qu'un modem câble de DOCSIS 1.0 peut demander à transmettre une trame qui est trop grande pour s'adapter dans la prochaine occasion disponible de transmission.

Voici un autre exemple, qui suppose que le programmateur reçoit nouveau accorde A et B dans cette commande. Supposez également que les deux concessions ont la même priorité mais que la concession B est pour un modem câble qui fonctionne en mode de DOCSIS 1.0.

Figure 17 ? Concessions en attendant de DOCSIS 1.1 et de DOCSIS 1.0

/image/gif/paws/69704/upstrm_sch_config_17.gif

Les essais de programmateur pour allouer l'heure pour la concession A d'abord. Puis les essais de programmateur pour allouer la prochaine occasion disponible de transmission d'accorder le B. Cependant, il n'y a aucune pièce pour la concession B de rester unfragmented entre A et le prochain bloc de concessions UGS (voir la figure 18).

Figure 18 ? DOCSIS 1.0 Grant B reporté

upstrm_sch_config_18.gif

Pour cette raison, la concession B est retardée jusqu'après que le deuxième bloc de concessions UGS où il y a pièce pour la concession B de s'adapter. Notez qu'il y a maintenant l'espace inutilisé avant que le deuxième bloc de concessions UGS. Les Modems câble passent ce temps de transmettre des demandes de bande passante au CMTS, mais ceci représente une utilisation inefficace de bande passante.

Revisitez cet exemple et ajoutez les deux écoulements supplémentaires d'un service UGS au programmateur. Tandis que la concession A peut être fragmentée, il n'y a aucune occasion pour la concession unfragmentable B d'être programmée parce que la concession B est trop grande pour s'adapter entre les blocs de concessions UGS. Cette situation laisse le modem câble associé avec la concession B incapable de transmettre de grandes trames dans l'en amont.

Figure 19 ? Le DOCSIS 1.0 Grant B ne peut pas être programmé

/image/gif/paws/69704/upstrm_sch_config_19.gif

Vous pouvez permettre au programmateur pour éliminer simplement, ou retardez légèrement un bloc de concessions UGS afin de faire la pièce pour la concession B mais ce jitter de causes d'action dans l'écoulement de service UGS. Pour le moment si vous supposez que vous voulez réduire le jitter, c'est une solution inacceptable.

Afin de surmonter cette question avec de grandes concessions unfragmentable de DOCSIS 1.0, les blocs conformes de pré-programmes de programmateur DOCSIS périodiquement de temps en amont aussi grands que la plus grande trame qu'un modem câble de DOCSIS 1.0 peut transmettre. Le programmateur fait ainsi avant que tous les écoulements de service UGS soient programmés. Ce temps est typiquement l'équivalent d'environ 2000 octets de transmission en amont, et s'appelle le « bloc d'Unfragmentable » ou le « bloc libre UGS ».

Le programmateur conforme DOCSIS des concessions ne place aucun style UGS ou RTPS dans les temps alloués au trafic unfragmentable afin de s'assurer qu'il y a toujours une occasion pour que les grandes concessions de DOCSIS 1.0 soient programmées. Dans ce système, la réservation de l'heure pour le trafic unfragmentable de DOCSIS 1.0 réduit le nombre d'écoulements de service UGS que l'en amont peut simultanément prendre en charge.

La figure 20 affiche que le bloc unfragmentable dans le bleu et quatre écoulements de service UGS avec la même concession classent et accordent l'intervalle. Vous ne pouvez pas ajouter un autre écoulement de service UGS de la mêmes taille de concession et intervalle de concession à cet en amont parce qu'on ne permet pas à des des concessions UGS pour être programmé dans la région unfragmentable bleue de bloc.

Figure 20 ? Le bloc d'Unfragmentable : Aucune autre concession UGS ne peut être admise

/image/gif/paws/69704/upstrm_sch_config_20.gif

Quoique le bloc unfragmentable soit programmé moins souvent que la période des concessions UGS, ce bloc tend à entraîner un espace de la bande passante non affectée aussi grande que lui-même entre tous les blocs de concessions UGS. Ceci présente le moyen suffisant de grandes concessions unfragmentable d'être programmé.

Revenez à l'exemple de la concession A et du DOCSIS 1.0 Grant B, vous peut voir cela avec le bloc unfragmentable en place, le DOCSIS le programmateur que conforme peut maintenant avec succès programmer la concession B après que le premier bloc de concessions UGS.

Figure 21 ? Concessions de Scheduling avec l'utilisation du bloc d'Unfragmentable

/image/gif/paws/69704/upstrm_sch_config_21.gif

Bien que la concession B de DOCSIS 1.0 soit avec succès programmée, il y a toujours un petit écart de la concession inutilisée A de l'espace entre et du premier bloc de concessions UGS. Cet écart représente une utilisation suboptimale de bande passante et explique pourquoi vous devez utiliser des Modems câble de mode de DOCSIS 1.1 quand vous déployez des services UGS.

Par défaut-phy-rafale de câble

Par défaut sur un ubr CMTS de Cisco, la plus grande rafale qu'un modem câble peut transmettre est de 2000 octets. Cette valeur pour la plus grande taille de rafale en amont est utilisée pour calculer la taille du bloc unfragmentable comme utilisations conformes de programmateur DOCSIS.

Vous pouvez changer la plus grande taille de rafale avec la maximum-octet-autoriser-dans-rafale de par défaut-phy-rafale de câble par commande d'interface de câble.

Le paramètre de <max-bytes-allowed-in-burst> a une plage de 0 à 4096 octets et d'une valeur par défaut de 2000 octets. Il y a quelques importantes restrictions sur la façon dont vous devez placer cette valeur si vous voulez changer la valeur de la valeur par défaut.

Pour des interfaces de câble sur le linecard MC5x20S, ne placez pas ce paramètre au-dessus du par défaut de 2000 octets. Pour tous autres types de linecard, y compris les linecards MC28U, MC5x20U et MC5x20H, vous pouvez placer ce paramètre aussi élevé que 4000 octets.

Ne placez pas le paramètre de <max-bytes-allowed-in-burst> inférieur à la taille de la plus grande trame Ethernet simple de la laquelle un modem câble peut avoir besoin pour transmettre comprenant DOCSIS ou 802.1Q au-dessus. Ceci signifie que cette valeur doit n'être aucun plus humblement qu'approximativement 1540 octets.

Si vous placez le <max-bytes-allowed-in-burst> à la valeur spéciale de 0, le CMTS n'emploie pas ce paramètre pour limiter la taille d'une rafale en amont. Vous devez configurer d'autres variables afin de limiter la taille de rafale en amont à une limite raisonnable, telle que la configuration de rafale concaténée par maximum dans le fichier de configuration DOCSIS, ou la commande en amont de fragment-force de câble.

Quand vous modifiez la par défaut-phy-rafale de câble pour changer la taille de rafale d'émission maximale, la taille du bloc libre UGS est également modifiée en conséquence. La figure 22 prouve que si vous réduisez la configuration de par défaut-phy-rafale de câble, la taille du bloc libre UGS réduit, et par conséquent le programmateur conforme DOCSIS peut laisser plus de faire appel UGS à un en amont. Dans cet exemple, ramenez la par défaut-phy-rafale de câble de la valeur par défaut de 2000 à une configuration inférieure de 1600 pour permettre la pièce pour qu'un plus d'écoulement de service UGS devienne actif.

Figure 22 ? La Par défaut-phy-rafale réduite diminue la longueur de bloc d'Unfragmentable

/image/gif/paws/69704/upstrm_sch_config_22.gif

La réduction de la taille de rafale maximale permise avec la commande de par défaut-phy-rafale de câble peut légèrement diminuer l'efficacité de l'en amont pour le trafic de meilleur effort, parce que cette commande réduit le nombre de trames qui peuvent être concaténées à moins d'une éclatée. Une telle réduction peut également mener aux plus grands niveaux de la fragmentation quand l'en amont a un plus grand nombre d'écoulements de service UGS actifs.

Les tailles de rafale concaténées réduites peuvent affecter la vitesse du téléchargement de données dans un écoulement de service de meilleur effort. C'est parce que la transmission des plusieurs trames est immédiatement plus rapide que la transmission d'une demande de bande passante de chaque trame. Les niveaux réduits d'enchaînement peuvent également potentiellement affecter la vitesse des téléchargements dus à une capacité diminuée du modem câble de concaténer un grand nombre de paquets du TCP ACK qui voyagent dans la direction en amont.

Parfois, la taille de rafale maximale comme configurée dans le « long » IUC du profil de modulation de câble appliqué à un en amont, peut déterminer la plus grande taille de rafale en amont. Ceci peut se produire si la taille de rafale maximale dans le profil de modulation est moins que la valeur de la par défaut-phy-rafale de câble dans les octets. C'est un scénario rare. Cependant, si vous augmentez le paramètre de par défaut-phy-rafale de câble du par défaut de 2000 octets, vérifiez la taille de rafale maximale dans la configuration du « long » IUC pour s'assurer qu'il ne limite pas des rafales.

L'autre limite à la taille de rafale en amont est qu'un maximum de 255 minislots peut être transmis dans un éclaté. Ceci peut devenir un facteur si la taille du mini emplacement est fixée au minimum de 8 octets. Un minislot est la plus petite unité de la transmission en amont dans un réseau DOCSIS et est habituellement équivalent à 8 ou 16 octets.

Jitter d'emplacement d'Unfragmentable

Une autre manière de tordre le programmateur conforme DOCSIS afin de permettre un nombre supérieur d'écoulements simultanés UGS sur un en amont est de permettre au programmateur pour permettre de grandes rafales du trafic unfragmentable de meilleur effort d'introduire un peu de jitter aux écoulements de service UGS. Vous pouvez faire ainsi avec la commande val d'interface de câble d'en amont-nombre de câble de limite en amont d'unfrag-emplacement-jitter.

Dans cette commande, le <val> est spécifié en quelques microsecondes et a une valeur par défaut de zéro, ainsi il signifie que le comportement par défaut pour le programmateur conforme DOCSIS est de ne pas permettre à des concessions unfragmentable pour entraîner le jitter pour le service UGS et RTPS circule. Quand un jitter unfragmentable positif d'emplacement est spécifié, le programmateur conforme DOCSIS peut retarder des concessions UGS par jusqu'aux microsecondes de <val> de quand la concession UGS doit idéalement être programmée, et par conséquent le jitter de cause.

Ceci a le même effet que la réduction de la longueur de bloc unfragmentable par une longueur équivalente au nombre de microsecondes a spécifié. Par exemple, si vous mettez à jour la valeur par défaut pour la par défaut-phy-rafale (2000 octets) et si vous spécifiez une valeur de 1000 microsecondes pour le jitter unfragmentable d'emplacement, le bloc unfragmentable réduit (voir la figure 23).

Figure 23 ? Le jitter différent de zéro d'emplacement d'Unfragmentable diminue la longueur de bloc d'Unfragmentable

/image/gif/paws/69704/upstrm_sch_config_23.gif

Remarque: Le nombre d'octets auxquels le temps 1000-microsecond correspond dépend de la façon dont rapide le canal ascendant est configuré pour fonctionner par les configurations de largeur et de schéma de modulation de canal.

Remarque: Avec un jitter unfragmentable différent de zéro d'emplacement le programmateur conforme DOCSIS peut augmenter le nombre d'UGS accorde qu'un en amont le prend en charge de la même façon à avoir une par défaut-phy-rafale réduite.

Remarque: Revenez à l'exemple avec une grande concession A de DOCSIS 1.1 suivie d'une grande concession unfragmentable B de DOCSIS 1.0 pour programmer sur un en amont. Vous avez placé le jitter unfragmentable d'emplacement à 1000 microsecondes. Le programmateur conforme DOCSIS se comporte suivant les indications des figures dans cette section.

Remarque: D'abord, le délai de transmission de schedulers allocate pour la concession R. Pour faire ainsi, le programmateur fragmente la concession dans accorde A1 et A2 de sorte que les concessions s'adaptent avant et après que le premier bloc de concessions UGS. Afin de programmer la concession B, le programmateur doit décider si le programmateur peut s'insérer le bloc unfragmentable dans l'espace libre après que la concession A2 sans retard au prochain bloc de concessions UGS par plus que le jitter unfragmentable configuré d'emplacement de 1000 microsecondes. Ces figures prouvent que si les endroits de programmateur accordent B à côté de la concession A2, le prochain bloc du trafic UGS est retardé, ou refoulé, par plus de 1500 microsecondes. Par conséquent le programmateur ne peut pas placer la concession B directement après la concession A2.

Figure 24 ? Grant B incapable d'être programmé à côté de Grant A2.

/image/gif/paws/69704/upstrm_sch_config_24.gif

L'étape suivante pour le programmateur conforme DOCSIS est de voir si le prochain écart disponible peut faciliter la figure 25 de la concession B. prouve que si la concession B d'endroits de programmateur après que le deuxième bloc de concessions UGS, le troisième bloc ne soit pas retardé par plus que le jitter unfragmentable configuré d'emplacement de 1000 microsecondes.

Figure 25 ? Grant B programmé après que le deuxième bloc de concessions UGS

/image/gif/paws/69704/upstrm_sch_config_25.gif

Avec la connaissance que la mise en place de la concession B en ce moment n'entraîne pas le jitter inacceptable aux concessions UGS, la concession conforme B d'insertions de programmateur DOCSIS et retarde légèrement le bloc suivant de concessions UGS.

Figure 26 ? Unfragmentable Grant B est programmé et des concessions UGS sont retardées

/image/gif/paws/69704/upstrm_sch_config_26.gif

Sortie de la commande show

Vous pouvez utiliser la commande d'en amont-nombre de MAC-programmateur d'interface-nombre de show interface cable de mesurer l'état actuel du programmateur conforme DOCSIS. Voici un exemple de la sortie de cette commande comme vu sur Cisco uBR7200VXR avec un linecard 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

Cette section explique chaque ligne de la sortie de cette commande. Notez que cette section du document suppose que vous êtes déjà tout à fait au courant des concepts de établissement du programme d'en amont général DOCSIS.

  • Planificateur MAC de DOCSIS 1.1 pour Cable3/0/U0

    La première ligne de la sortie de commande indique le port ascendant lequel les données concernent.

  • Alignez [balayages de Rng] 0/128, les gouttes 0, 1 maximum

    Cette ligne affiche l'état de la file d'attente quel Keepalives ou occasions de télémétrie de maintenance de station de flux dans le programmateur conforme DOCSIS. 0/128 indique qu'il y a actuellement zéro hors d'un maximum de 128 occasions de télémétrie en suspens dans la file d'attente.

    Les baisses contre- indique que le nombre de fois où une occasion de télémétrie ne pourrait pas être alignée vers le haut de parce que cette file d'attente était déjà pleine (c'est-à-dire, 128 occasions de télémétrie en suspens). Les baisses ici se produiraient seulement vraisemblablement sur un en amont avec un nombre de Modems câble extrêmement grand en ligne et s'il y avait un grand nombre de service UGS ou RTPS circule l'active. Cette file d'attente est entretenue avec le plus prioritaire quand le programmateur de plainte DOCSIS fonctionne. Par conséquent, les baisses dans cette file d'attente sont fortement peu probables mais indiquent très probablement un surabonnement sérieux du canal ascendant.

    Le compteur maximum indique le nombre maximal de présent d'éléments et dans cette file d'attente puisque la commande de MAC-programmateur de show interface cable était dernier passage. Dans le meilleur des cas ceci devrait rester aussi étroitement à zéro comme possible.

  • Alignez [concessions CIR] 0/64, les gouttes 0, 0 maximum

    Cette ligne affiche l'état de la file d'attente ce qui gère des concessions pour des écoulements de service avec du débit de trafic réservé minimum spécifié. En d'autres termes, cette file d'attente entretient des concessions pour des écoulements de service du débit de données garanti (CIR). 0/64 indique qu'il y a actuellement zéro hors d'un maximum de 64 concessions en suspens dans la file d'attente.

    Les baisses contre- indique que le nombre de fois où une concession CIR ne pourrait pas être alignée vers le haut de parce que cette file d'attente était déjà pleine (c'est-à-dire, 64 concessions dans la file d'attente). Les baisses peuvent s'accumuler ici si oversubscribe d'écoulements de service du style UGS, RTPS et CIR l'en amont, et peuvent indiquer le besoin de contrôle d'admission plus strict.

    Le compteur maximum indique le nombre maximal de concessions dans cette file d'attente puisque la commande de MAC-programmateur de show interface cable était dernier passage. Cette file d'attente a le deuxième plus prioritaire ainsi les schedulers allocate conformes DOCSIS que l'heure pour des éléments de cette file d'attente avant le programmateur entretient les files d'attente de meilleur effort.

  • Alignez [SOYEZ (w) des concessions] x/64, des baisses y, z maximum

    Les huit prochaines entrées affichent l'état des files d'attente qui gèrent des concessions pour des écoulements de service prioritaire 7 à 0. Les champs dans ces entrées ont la même signification que les champs dans l'entrée de file d'attente CIR. La première file d'attente à servir dans ce groupe est la file d'attente de l'ÊTRE (7) et le bout à servir est les 0) files d'attente d'ÊTRE (.

    Les baisses peuvent se produire écoulements de service dans ces files d'attente si un niveau plus prioritaire du trafic consomme toute la bande passante amont ou si surabonnement de l'en amont avec l'UGS, de style RTPS et CIR se produit. Ceci peut indiquer la nécessité de réévaluer les priorités DOCSIS pour des écoulements à fort débit de service ou un besoin de contrôle d'admission plus strict sur l'en amont.

  • Emplacements 36356057 de Req

    Cette ligne indique le nombre d'occasions de demande de bande passante qui ont été annoncées puisque l'en amont a été lancé. Ce nombre doit être continuellement sur une augmentation.

  • Req/emplacements 185165 de données

    Bien que le nom suggère que ce champ affiche le nombre d'occasions de demande ou de données annoncées sur l'en amont, ce champ affiche vraiment le nombre de périodes que le CMTS annonce afin de faciliter la fonctionnalité de gestion du spectre avancée. On s'attend à ce que ce compteur incrémente pour des en amont sur des linecards du style MC28U et MC520.

    Les occasions de demande/données sont identiques que des occasions de demande de bande passante sauf que les Modems câble peuvent également transmettre de petites rafales des données en ces périodes. La gamme CMTSs d'ubr de Cisco ne programme pas actuellement de vraies occasions de demande/données.

  • Init Mtn raine 514263

    Cette ligne représente le nombre d'occasions de maintenance initiale qui ont été annoncées puisque l'en amont a été lancé. Ce nombre doit être continuellement sur l'arrivée. Modems câble qui font des tentatives initiales d'établir la Connectivité aux occasions de maintenance initiale d'utilisation CMTS.

  • Stn Mtn raine 314793

    Cette ligne indique le nombre de keepalive ou d'occasions de télémétrie de maintenance de station données sur l'en amont. S'il y a des Modems câble en ligne sur l'en amont, ce nombre doit être continuellement sur l'arrivée.

  • Grant court raine 12256, les longs emplacements 4691 de Grant

    Cette ligne indique le nombre de concessions de données offertes sur l'en amont. S'il y a des Modems câble qui transmettent des données en amont, ces nombres doivent être continuellement sur l'arrivée.

  • ATDMA court-circuitent les emplacements 0 de Grant, les longs Grant emplacements 0 ATDMA, les emplacements 0 UGS Grant ATDMA

    Cette ligne représente le nombre de concessions de données offertes en mode avancé du plusieurs accès de répartition temporelle (ATDMA) sur l'en amont. S'il y a des Modems câble qui fonctionnent en mode de DOCSIS 2.0, et eux transmettent des données en amont, ces nombres doivent être continuellement sur l'arrivée. Notez qu'ATDMA explique séparément le trafic UGS.

  • Emplacements 277629 système aéroporté de détection et de contrôle

    Cette ligne affiche le nombre de périodes dédiées à la gestion du spectre avancée. Pour que la gestion du spectre avancée se produise, le CMTS doit programmer périodiquement des périodes où chaque modem câble doit faire une brève transmission de sorte que la fonction interne d'analyse du spectre puisse évaluer la qualité du signal de chaque modem.

  • Compte 41 de fragmentation

    Cette ligne affiche le nombre total de fragments que le port ascendant est programmé pour recevoir. Par exemple, une trame qui a été fragmentée dans trois parts entraînerait ceci à l'opposé de l'incrément par trois.

  • Test de fragmentation désactivé

    Cette ligne indique que la commande de fragmentation de câble de test n'a pas été appelée. N'utilisez pas cette commande dans un réseau de production.

  • Moyenne utilisation du canal ascendant : 26%

    Cette ligne affiche l'utilisation du canal ascendant en cours par les transmissions de données en amont. Ceci entoure des transmissions faites par court, long, ATDMA court, ATDMA long et concessions UGS ATDMA. La valeur est calculée chaque seconde comme moyenne de roulement. Cisco recommande que cette valeur de ne pas dépasser 75% sur une base étendue pendant des temps utiles maximaux. Autrement les utilisateurs finaux peuvent commencer à noter des problèmes de performance avec le trafic de meilleur effort.

  • Intervalles de conflit de pourcentage moyen : 73%

    Cette ligne affiche le pourcentage du temps en amont dédié aux demandes de bande passante. Ceci égalise à la quantité de temps disponible dans l'en amont, et réduit donc à mesure que moyenne le pourcentage d'utilisation du canal ascendant augmente.

  • Locations de négociation du débit initiale de pourcentage moyen : 2%

    Cette ligne indique le pourcentage du temps en amont dédié aux occasions de classement initial que les Modems câble utilisent quand ils font des tentatives d'établir la connectivité initiale avec le CMTS. Cette valeur doit toujours demeurer un bas pourcentage d'utilisation totale.

  • Minislots de pourcentage moyen perdus sur de défuntes cartes : 0%

    Cette ligne indique le pourcentage du temps en amont qui n'a pas été programmé parce que le CMTS ne pouvait pas transmettre un message de tableau d'allocation de largeur de bande aux Modems câble à temps. Ce paramètre doit toujours être proche de zéro mais peut commencer à afficher de plus grandes valeurs sur les systèmes qui ont un chargement extrêmement élevé CPU.

  • Rsv-état de Tableau de Sched : Concessions 0, Reqpolls 0

    Cette ligne affiche le nombre d'écoulements de service d'écoulements de service de style UGS (concessions) ou de style RTPS (Reqpolls) qui ont des concessions préaffectées pour elles dans le programmateur conforme DOCSIS, mais pas encore lancé. Ceci se produit quand vous déplacez un modem câble avec le service existant UGS ou RTPS passe d'un en amont à l'autre par l'Équilibrage de charge. Notez que cette figure s'applique seulement aux concessions qui utilisent le programmateur conforme DOCSIS, et pas au programmateur LLQ.

  • Adm-état de Tableau de Sched : Concessions 6, Reqpolls 0, Util 27%

    Cette ligne indique le nombre d'écoulements de service d'écoulements de service de style UGS (concessions) ou de style RTPS (Reqpolls) qui ont des concessions préaffectées pour elles dans le programmateur conforme DOCSIS pour cet en amont. Util est l'utilisation prévue de toute la bande passante amont disponible par ces derniers des écoulements de service. Notez que cette figure s'applique seulement aux concessions qui utilisent le programmateur conforme DOCSIS, et pas au programmateur LLQ.

  • <Scheduling-type> : X SID, niveau de la réservation dans bps y

    Cette ligne indique le nombre d'écoulements de service de <Scheduling-type> ou de SID qui sont présents sur l'en amont, et la quantité de bande passante dans des bits par seconde que ces écoulements de service ont réservés. Pour le meilleur effort et le RTPS le style entretiennent des écoulements, bande passante est seulement réservé si l'écoulement de service a un débit réservé minimum configuré.

Avantages et inconvénients du programmateur conforme DOCSIS

Le but du programmateur conforme DOCSIS est de réduire le jitter service pour UGS et RTPS style circule et incorpore également des rafales unfragmentable de DOCSIS 1.0. Le compromis que le programmateur conforme DOCSIS fait afin d'atteindre ces buts est que le nombre maximal d'écoulements de service UGS pris en charge par en amont est moins que le maximum théorique qu'un en amont DOCSIS peut physiquement prendre en charge, et qui le trafic de meilleur effort peut être sujet à un degré de fragmentation.

Tandis que les supports conformes de programmateur DOCSIS légèrement que moins que le nombre maximal théorique de service simultané UGS circule sur un en amont, et tandis que quelques autres réalisations de établissement du programme peuvent prendre en charge plus d'écoulements de service UGS par en amont, vous devez se concentrer sur le compromis.

Par exemple, aucun programmateur ne peut prendre en charge les écoulements jitterless de service UGS qui consomment de près de 100% la bande passante d'un canal ascendant et prennent en charge simultanément de grandes trames concaténées unfragmentable des Modems de DOCSIS 1.0. En vue de la conception du programmateur conforme DOCSIS il y a deux points importants à comprendre.

  • 75% est l'utilisation en amont desirable maximum.

    Cisco a constaté que quand un en amont fonctionne uniformément à l'utilisation plus considérablement que de 75%, y compris l'utilisation due au service UGS circule, des débuts de représentation du trafic de meilleur effort pour obtenir sensiblement affecté. Ceci signifie que si l'UGS et la signalisation VoIP consomment plus de 75% de l'en amont, tout trafic IP normal a transporté par des écoulements de service de meilleur effort commencent à souffrir de la latence ajoutée qui entraîne sensiblement le débit inférieur et les temps de réponse. Cette dégradation de représentation à des niveaux plus élevés d'utilisation est une propriété qui la plupart de partage moderne de systèmes de réseau multi-accès, par exemple, Ethernets ou réseaux locaux de radio.

  • Quand la largeur du canal ascendant typique déployée de 3.2MHz est utilisée, le programmateur conforme DOCSIS permet à des écoulements de service UGS pour utiliser jusqu'environ à 75% du canal ascendant. Ces écoulements de service donnent G.711 des appels VoIP.

Ces deux points donnent une certaine vue dans les considérations de conception qui ont été prises en considération quand le programmateur conforme DOCSIS a été construit. Le programmateur conforme DOCSIS a été conçu de sorte que pour des écoulements typiques de service UGS (G.711) et avec la largeur le plus généralement déployée de canal de 3.2MHz, l'appel par début en amont de limites pour s'appliquer à environ la marque d'utilisation de 75%. Ceci signifie que le programmateur réduit avec succès le jitter et permet également un nombre raisonnable d'écoulements de service UGS dans l'en amont.

En d'autres termes, le programmateur conforme DOCSIS a été conçu pour fonctionner correctement dans des réseaux de la production DOCSIS, et ne pas permettre le service UGS circule pour épuiser de manière irréaliste un pourcentage élevé de la bande passante amont. Ce scénario peut se produire dans un scénario conçu de test en laboratoire.

Vous pouvez tordre le programmateur conforme DOCSIS pour faciliter un nombre accru d'appels UGS par en amont, quoiqu'au détriment du jitter UGS et de l'efficacité du trafic de meilleur effort. Pour ceci, vous devez ramener le paramètre de par défaut-phy-rafale de câble à la configuration recommandée minimum de 1540 octets. Si vous avez besoin davantage de densité d'appel, placez l'unfrag-emplacement-jitter en amont de câble à une valeur telle que 2000 microsecondes. Cependant, Cisco ne recommande pas ces configurations généralement pour un réseau de production.

Un autre avantage du programmateur conforme DOCSIS est qu'il n'y a aucune condition obligatoire que les opérateurs CMTS configurent explicitement le contrôle d'admission service pour UGS et RTPS style circule. C'est parce que, la méthode de établissement du programme d'affectation statique de place élimine la possibilité de surabonnement accidentel. Quoique ce soit le cas Cisco suggère toujours que les opérateurs s'assurent qu'utilisation en amont de total pour ne pas dépasser 75% pendant des périodes étendues pendant l'heure de pointe. Par conséquent, Cisco recommande la configuration du contrôle d'admission comme pratique recommandée.

Un inconvénient du programmateur conforme DOCSIS est que l'à position fixe des concessions UGS peut exiger la fragmentation des concessions de meilleur effort quand l'utilisation UGS est élevée. Généralement la fragmentation ne pose pas des problèmes de performances apparents, mais mène à une légère augmentation de latence pour le trafic de meilleur effort et à une augmentation du temps système de protocole actuel sur le canal ascendant.

Un autre inconvénient est que quand les Modems câble de DOCSIS 1.0 veulent faire de grandes transmissions en amont unfragmentable il peut y a un retard avant qu'un écart approprié entre les blocs de concessions pré-programmées UGS apparaisse. Ceci peut également mener à la latence accrue pour le trafic en amont de DOCSIS 1.0 et à une utilisation moins-que-optimale de délai de transmission en amont disponible.

En conclusion, le programmateur conforme DOCSIS est conçu pour fonctionner mieux dans les environnements où tous les écoulements de service UGS partagent la mêmes taille de concession et intervalle de concession. C'est-à-dire, où tous les appels VoIP partagent les mêmes codecs, tels que le packetization 10ms ou 20ms G.711 que se produirait dans un système basé de Packetcable 1.0 typiques. Si disparate accordez les intervalles et les tailles sont présentes, la capacité du programmateur conforme DOCSIS de prendre en charge un nombre élevé d'écoulements de service UGS réduit sur un en amont. En outre, un peu de jitter très (moins que 2ms) peut se produire pour quelques concessions pendant que les essais de programmateur pour intercaler le service UGS circule avec différentes périodes et tailles.

Pendant que les réseaux des multimédia de PacketCable (PCMM) deviennent plus répandus il peut devenir plus commun pour un grand choix de codecs VoIP avec de divers intervalles de packetization pour être dans l'exécution simultanée. Ce type d'environnement peut se prêter au programmateur de queue de basse latence.

Le programmateur de queue de basse latence

Le programmateur de queue de bas temps d'attente (LLQ) a été introduit dans la version du logiciel Cisco IOS 12.3(13a)BC. LLQ est l'approche alternative pour programmer des services ascendants sur un ubr CMTS de Cisco. Ce programmateur a été conçu pour maximiser le nombre service UGS et RTPS de style circule un en amont peut le prendre en charge simultanément et également améliorer l'efficacité du trafic de meilleur effort en présence des écoulements de service UGS. Le compromis est le programmateur LLQ ne fait aucune garantie en vue de le jitter pour le service UGS et RTPS circule.

Pendant que la section conforme de programmateur DOCSIS discute, le programmateur conforme DOCSIS préaffecte le délai de transmission à l'avance service pour UGS et RTPS style circule. C'est semblable à la manière qu'un système existant du multiplexage temporel (TDM) alloue la bande passante à un service pour garantir certains niveaux de latence et de jitter.

Dans les réseaux paquet paquet modernes, la basse queue de latence est la méthode que les Routeurs les utilisent pour assurer que des paquets associés avec des services prioritaires, par exemple Voix et vidéo, peuvent être livrés dans un réseau avant d'autres paquets prioritaires inférieurs. C'est également la méthode que les Routeurs modernes les utilisent pour assurer que ces latence et jitter sont réduits pour l'important trafic.

L'utilisation du mot « garantie » pour le système basé sur TDM et « réduit » pour le LLQ a basé le système par rapport au jitter et à la latence. Tandis qu'une garantie pour la latence et le jitter nuls est desirable, le compromis est qu'un tel système est habituellement inflexible, difficile à modifier et généralement incapable de s'adapter facilement aux changements du réseau conditionne.

Un système qui réduit la latence et le jitter, plutôt que fournissant une garantie stricte, peut fournir la flexibilité afin de s'optimiser continuellement face aux changements des états de réseau. Le programmateur de queue de basse latence se comporte d'une manière semblable au système paquet paquet routeur LLQ. Au lieu de l'systèmes pré-programmés d'allocation pour des concessions UGS, programmes de ce système les concessions « dès que possible » au point où ils doivent être programmés.

L'approche qui accorde pour des écoulements de service UGS doit être allouée dès que possible mais pas nécessairement avec la périodicité parfaite, les commerces de ce système outre des garanties strictes de jitter pour la capacité accrue UGS et moins de fragmentation de données de meilleur effort.

Configuration

Pour les versions du logiciel Cisco IOS 12.3(13a)BC et plus tard, le programmateur LLQ est l'un de deux algorithmes alternatifs de programmateur. Vous pouvez activer LLQ pour un, tous ou certains ces modes de établissement du programme :

  • UGS

  • RTPS

  • NRTPS

Le programmateur LLQ n'est pas activé par défaut. Vous devez explicitement allumer le programmateur LLQ pour les types de établissement du programme priés d'en amont. Utilisez le type de établissement du programme de port ascendant en amont de câble [nrtps | rtps | commande d'interface de câble de llq de mode UGS].

Généralement vous pouvez activer le programmateur LLQ pour tous les modes de établissement du programme énumérés si c'est le mode de établissement du programme désiré. Voici un exemple d'une situation où vous voulez activer LLQ programmant pour seulement un type de mode de établissement du programme mais retenir le programmateur conforme DOCSIS pour d'autres :

Les écoulements de service RTPS ne font faire aucune condition requise stricte pour des écoulements de jitter mais de service UGS. Dans ce cas, vous pouvez activer le programmateur LLQ pour des écoulements de service RTPS, et retenez le programmateur conforme DOCSIS pour l'UGS.

Exécution de programmateur LLQ

Le programmateur LLQ fonctionne de la même manière que la fonction de file d'attente à priorité déterminée du programmateur conforme DOCSIS en plus d'une file d'attente à faible latence spéciale (LLQ), qui a la priorité au-dessus de toutes autres files d'attente.

Le programmateur LLQ met en marche un temporisateur au nom de tous les écoulements actifs de service de style UGS (et RTPS). Le temporisateur est placé pour aller hors fonction une fois que chaque « intervalle de concession ». Toutes les fois que le temporisateur expire, une concession UGS est alignée dans la file d'attente LLQ. Pendant que cette concession est placée dans la file d'attente LLQ qui a la haute priorité, la concession est programmée au moment possible suivant où il y a l'espace libre.

Les diagrammes dans cette section affichent un exemple d'un système avec trois écoulements de service UGS d'active avec le même intervalle de concession. La figure 27 affiche les temporisateurs pour les écoulements de service UGS du côté gauche, étiquetés UGS-1 par UGS-3. La flèche jaune voyage dans un sens horaire. Quand la flèche de jaune se dirige vers le haut vers le point rouge, une concession UGS est ajoutée à la file d'attente LLQ. Vous pouvez également voir les huit files d'attente prioritaire familières 0 à 7 et à une nouvelle file d'attente LLQ qui prend la priorité au-dessus de tous. En conclusion, vers la droite, est la chronologie d'allocation de bande passante qui décrit comment des concessions sont programmées sur l'en amont. Pour la clarté ajoutée la chronologie d'allocation de bande passante inclut un pointeur « de temps en cours ». Ce pointeur avance le long de la chronologie pendant que l'exemple poursuit.

Figure 27 ? Le bas système de mise en file d'attente de temps d'attente

upstrm_sch_config_27.gif

Le premier événement qui se produit est que le temporisateur UGS-1 au expire en haut à gauche. Une concession correspondante est alignée dans la file d'attente LLQ. En même temps, une concession de meilleur effort appelée l'A avec la priorité 2 est alignée.

Figure 28 ? Le Grant pour UGS-1 et la priorité 2 Grant A sont alignés

/image/gif/paws/69704/upstrm_sch_config_28.gif

Le programmateur LLQ alloue maintenant le délai de transmission aux concessions en attente dans l'ordre de priorité. La première concession pour recevoir le délai de transmission est la concession pour UGS-1 qui attend dans la file d'attente LLQ. Grant A suit.

Figure 29 ? Grant UGS-1 et Grant A sont alloués délai de transmission

/image/gif/paws/69704/upstrm_sch_config_29.gif

Le prochain événement à se produire est que le temporisateur UGS-2 expire et cause une concession pour que l'écoulement du service UGS-2 soit aligné dans la file d'attente LLQ. En même temps, une concession B prioritaire 0 est alignée et le C de concession prioritaire 6 est aligné.

Figure 30 ? Le temporisateur UGS-2 expire. Les concessions B et le C sont alignés

/image/gif/paws/69704/upstrm_sch_config_30.gif

Le programmateur LLQ alloue de nouveau le délai de transmission dans la commande de la priorité de concession, ainsi il signifie que d'abord le moment de schedulers allocate à la concession pour UGS-2, puis pour le C de concession, et finalement pour la concession B.

Figure 31 ? Les concessions UGS-2, le C et le B sont alloués délai de transmission

/image/gif/paws/69704/upstrm_sch_config_31.gif

Supposez que concession de meilleur effort n'entre pas dans le programmateur pendant un moment. Les temporisateurs chacun UGS expirent plusieurs fois davantage. Vous pouvez maintenant voir le genre de période avec lequel les concessions de schedulers allocate au service UGS circule. Ils semblent être également espacés. Supposez que quand les concessions apparaissent cette manière par rapport à l'un l'autre sur la chronologie d'allocation de bande passante, ils n'éprouvent aucun jitter significatif.

Figure 32 ? UGS-1, UGS-2 et UGS-3 reçoivent un certain nombre de concessions. Grant D est aligné

/image/gif/paws/69704/upstrm_sch_config_32.gif

La figure 32 indique la position idéale pour la prochaine concession UGS-2. Si UGS-2 peut avoir la concession placée à cette zone, UGS-2 n'éprouvera aucun jitter pour la concession. Notez qu'il reste l'heure pour que la prochaine concession UGS-2 soit alignée dans la file d'attente LLQ.

La figure 32 indique également qu'une concession très grande D prioritaire 0 est juste entrée dans la file d'attente prioritaire 0. La prochaine action les prises de programmateur LLQ est de programmer le délai de transmission pour la concession D.

La figure 33 affiche ce scénario. Remontez l'horloge en avant au point où la prochaine concession pour UGS-2 est alignée.

Figure 33 ? Grant D reçoit le délai de transmission. Grant pour UGS-2 est aligné

/image/gif/paws/69704/upstrm_sch_config_33.gif

Grant D semble être programmé au moment où la prochaine concession UGS-2 doit être programmée pour le jitter nul. Maintenant la question est pourquoi le programmateur LLQ permet la concession D à programmer à ce moment là et ne retarde pas la concession D jusqu'après la concession pour UGS-2 ou pourquoi D n'est pas fragmenté. La réponse est que le programmateur LLQ ne préaffecte pas le délai de transmission pour des écoulements de service UGS. Par conséquent, le programmateur LLQ ne se rend pas compte à l'avance où des concessions UGS seront placées sur la chronologie d'allocation de bande passante. Le programmateur LLQ ne sait pas des concessions UGS jusqu'à ce qu'ils soient alignés dans la file d'attente LLQ. Dans cet exemple, avant que la concession pour UGS-2 entre dans la file d'attente, la concession D est déjà programmée.

Le programmateur LLQ programme la concession pour UGS-2 à la prochaine occasion disponible, mais cette concession est légèrement retardée de la position idéale, qui signifie par définition que cette concession particulière éprouve un certain jitter.

Figure 34 ? Grant pour UGS-2 est retardé et les expériences se trémoussent

/image/gif/paws/69704/upstrm_sch_config_34.gif

Tandis que le programmateur conforme DOCSIS pourrait avoir évité ce jitter, le programmateur LLQ évite un retard ou une fragmentation de la concession D aux dépens seulement d'un peu de jitter. Une mémoire tampon de jitter dans un point final VoIP peut facilement compenser ce jitter.

L'autre situation où le jitter peut se produire est quand le temporisateur LLQ pour des écoulements de plusieurs services expire en même temps et concession UGS attendent derrière d'autres concessions UGS alignées dans la file d'attente LLQ. Le programmateur LLQ a été conçu pour réduire la possibilité de cette occurrence. Le programmateur étend automatiquement les temps d'expiration pour les temporisateurs d'écoulement de service.

Selon le programmateur conforme DOCSIS, le programmateur LLQ a deux files d'attente supplémentaires que les exemples ne mentionnent pas. Voici les files d'attente :

  1. La première file d'attente est utilisée pour programmer le trafic périodique de keepalive de maintenance de station afin de maintenir des Modems câble en ligne. Cette file d'attente est servie juste après que la file d'attente LLQ.

  2. Le deuxième est une file d'attente pour des concessions allouées pour entretenir des écoulements avec du débit réservé minimum (le service CIR circule). Cette file d'attente CIR est traitée pendant qu'une « priorité 8" file d'attente afin de s'assurer que les écoulements de service avec du débit engagé reçoivent leur débit minimum exigé.

Contrôle d'admission

À la différence du programmateur conforme DOCSIS, le programmateur LLQ n'utilise pas un système de pré-établissement du programme que la sursouscription accidentelle d'arrêts d'un en amont avec le service UGS et RTPS circule. C'est pourquoi vous devez explicitement configurer le contrôle d'admission en amont sur n'importe quel en amont qui utilise le programmateur LLQ. Cette configuration s'assure que toute la bande passante amont d'écoulements de service UGS ne dépasse pas des limites raisonnables.

Cisco suggère généralement que vous ne permettiez pas à l'utilisation d'un canal ascendant pour dépasser 75% pendant des périodes étendues au cours des périodes maximales d'utilisation. Par exemple, si le trafic UGS consomme plus de 75% de la bande passante amont, des débuts de données de meilleur effort pour souffrir de la latence excessive et des problèmes de performances de débit.

Naturellement si un opérateur CMTS peut recevoir les conséquences négatives pour le trafic de meilleur effort, vous pouvez permettre l'UGS d'entretenir des écoulements consommez un supérieur à 75% de bande passante amont disponible. Cependant, vous devez également considérer l'incidence sur le trafic d'administration de la couche 2 sur le canal ascendant. Vous devez accorder l'heure pour la Messagerie d'initiale et de maintenance de station (Keepalives de modem câble). Si vous ne prenez pas en considération ceci, et le trafic UGS consomme de près de 100% de la bande passante, les Modems câble ne peuvent pas être livré en ligne ou peuvent tomber off-line.

Voici un exemple de configuration pour le contrôle d'admission. Cet exemple limite des écoulements de service UGS sur un en amont particulier à 50% de la bande passante disponible de l'en amont. Cette forme de la commande transmet également des déroutements SNMP à toutes les stations configurées de Gestion de réseau quand les seuils de mineur et de commandant de l'utilisation de 30% et de 40% sont atteints. La commande est la suivante :

câblez l'exclusivité en amont 50 du commandant 40 du mineur 30 UGS de programmer-type de nous-bande passante de contrôle d'admission d'en amont-nombre

Voyez la section de contrôle d'admission sous la section conforme de programmateur DOCSIS de ce document pour que la façon configure le contrôle d'admission.

Sortie de la commande show

Émettez la commande d'en amont-nombre de MAC-programmateur d'interface-nombre de show interface cable de mesurer l'état actuel du programmateur LLQ.

Voici un exemple de la sortie de cette commande. Les parties dont de la sortie de commande soyez différent quand le programmateur conforme DOCSIS est opérationnel sont en texte en gras :

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

Pour une explication des lignes de texte brut dans cette sortie, voyez la section de sortie de commande show pour le programmateur conforme DOCSIS.

Voici les descriptions pour les lignes épaisses de la sortie de commande show :

  • Alignez [concessions LLQ] 0/64, les gouttes 0, 3 maximum

    Cette ligne affiche l'état de la file d'attente LLQ, qui gère des concessions pour des types d'écoulement de service spécifiés dans le type de établissement du programme en amont de câble [nrtps | rtps | commande de llq de mode UGS]. 0/64 indique qu'il y a actuellement zéro hors d'un maximum de 64 concessions en suspens dans la file d'attente.

    Les baisses contre- indique que le nombre de fois le programmateur ne pouvait pas aligner une concession UGS ou le balayage RTPS parce que cette file d'attente était déjà pleine (en d'autres termes, quand 64 concessions sont dans la file d'attente). Si les baisses se produisent dans cette file d'attente, l'explication le plus susceptible est que l'en amont est oversubscribed avec le service UGS ou RTPS circule et vous devez appliquer un contrôle d'admission plus strict.

    Le compteur maximum indique le nombre maximal de concessions qui sont dans cette file d'attente puisque la commande de MAC-programmateur de show interface cable était dernier passage. Quand le présent, cette file d'attente a plus prioritaire de toutes les files d'attente énumérées.

  • r4k fait tic tac dans 1ms 600000

    Ce champ représente une variable de synchronisation interne que le programmateur LLQ emploie afin de s'assurer que des concessions sont placées dans la file d'attente LLQ avec la haute précision.

  • Événements de établissement du programme totaux 5009

    Cette ligne indique que le nombre de fois où le programmateur LLQ essaye d'aligner une concession depuis la dernière époque la commande de MAC-programmateur de show interface cable a été exécutée pour cet en amont. Ce compteur est remis à l'état initial chaque fois que la commande show est exécutée.

  • Aucune recherche n'était 5009 nécessaires

    Après que les files d'attente du planificateur des travaux LLQ une concession, le programmateur LLQ essaye de remettre à l'état initial le temporisateur de service-écoulement pour se préparer à la prochaine fois qu'une concession est alignée. S'il n'y a aucun problème avec une remise du temporisateur, des incréments de ce compteur. Ce compteur doit idéalement avoir la même valeur comme tout le compteur d'opérations de établissement du programme.

  • L'entrée précédente libèrent 0, prochaine entrée libèrent 0

    Ni l'un ni l'autre de ces compteurs n'incrémentent jamais dans des versions en cours de logiciel de Cisco IOS. Ces compteurs demeurent toujours à zéro.

  • N'a pas pu programmer 0, la reprise a manqué 0

    Cette ligne indique que le nombre de fois le programmateur LLQ ne pouvait pas arranger pour le temporisateur de concession d'un écoulement de service à placer correctement. Ceci doit seulement se produire si le programmateur LLQ manipule un nombre de concessions extrêmement grand avec des intervalles très bas de concession. Il est fortement peu susceptible incrémenter jamais ces compteurs sur un réseau de production. Un incrément de ces compteurs peut indiquer que les écoulements de service UGS et RTPS consomment plus de bande passante qu'est physiquement disponible sur l'en amont. Dans ce scénario, vous devez implémenter des commandes de contrôle d'admission appropriées.

  • Entrée 61 du temps 1341 de Curr

    Cette ligne affiche des horloges internes pour le programmateur LLQ mesuré en quelques millisecondes. Quand la « entrée » répertoriée ici égale le champ de « entrée » répertorié dans par statistique de flux de service, une concession est alignée dans la file d'attente LLQ.

Ces des statistiques sont répétées pour chaque écoulement de service que le programmateur LLQ manipule. Dans cet exemple il y a trois tels écoulements de service.

  • Entrée 188, coffre 13

    Quand la valeur de « entrée » est égale au champ de « entrée » dans l'élément précédent, le temporisateur pour cet écoulement de service expire et une concession entre dans la file d'attente LLQ. Remises de ce champ chaque fois que l'écoulement de service a une concession alignée.

  • SID : 416

    L'indentifiant de service (SID) pour l'écoulement de service dont les concessions le programmateur LLQ programme.

  • IUC : 5

    Code d'utilisation d'intervalle a annoncé dans un message de MAP pour les concessions qui appartiennent à cet écoulement de service. C'est presque toujours 5 pour « des données courtes », 6 pour des « longues données » ou 11 pour « l'UGS PHY avancé » quand un écoulement de service de style UGS est en service. Pour le style RTPS entretenez l'écoulement, cette valeur est toujours 1par « demande ».

  • size_ms : size_byte 17 : 232

    La taille de la concession dans les minislots, suivie de la taille de la concession dans les octets. Un minislot est la plus petite unité de la transmission en amont dans un réseau DOCSIS et est habituellement équivalent à 8 ou 16 octets.

  • Frag : N

    Indique si la concession est fragmentable. Actuellement cette valeur est toujours placée au N.

  • Inval : 20

    La concession ou l'intervalle de sondage en quelques millisecondes.

  • type 8

    8 indique cet écoulement de service est UGS, 10 indique que RTPS et 11 indique NRTPS.

  • référence parfaite 188 de temps

    Le moment idéal où cette concession doit avoir été programmée. C'est normalement identique en tant que « entrée » au dessus. Sinon, il y a une indication d'un en amont fortement congestionné qui a besoin de contrôle d'admission plus strict.

  • distorsion de la référence 0

    La différence entre quand cette concession a été programmée et quand la concession idéalement doit avoir été programmée. C'est la différence entre la « entrée » et « la référence parfaite de temps ». Par conséquent, cette valeur doit normalement être zéro.

  • priorité 10

    Dans des versions en cours de logiciel de Cisco IOS, cette valeur est toujours placée à 10, mais peut varier à l'avenir.

  • position 188, coffre 13

    Ces champs doivent être identiques en tant que « entrée, coffre » en haut de cette liste.

Avantages et inconvénients du programmateur LLQ

Le but du programmateur LLQ est d'augmenter la capacité UGS et RTPS pour des canaux ascendants, et d'augmenter l'efficacité du trafic de meilleur effort. Le compromis que le programmateur LLQ fait afin d'atteindre ces buts est que ce programmateur ne donne pas explicitement des garanties jitter d'écoulement pour UGS et RTPS service. En revanche, les concessions UGS de programmes de programmateur LLQ et les balayages RTPS aussi étroitement au moment idéal comme possible en vue de réduisent le jitter.

Le programmateur LLQ peut également manipuler mieux de plusieurs écoulements de service UGS avec différents intervalles de concession et tailles de concession que le programmateur conforme DOCSIS. Cette caractéristique peut être utile dans un environnement PCMM où les différents types d'appels VoIP et probablement d'autres applications sont tous simultanément servis sur l'un canal ascendant.

Le trafic de meilleur effort de programmes de programmateur LLQ plus efficacement parce que le programmateur LLQ réduit la probabilité de la fragmentation des concessions. Quand des rafales unfragmentable de DOCSIS 1.0 sont programmées, le programmateur LLQ ne crée pas des lacunes de bande passante inutilisée devant des concessions UGS ou les balayages RTPS comme le programmateur conforme DOCSIS fait parfois. Ceci mène mieux l'utilisation du temps en amont disponible.

Bien que le jitter UGS soit généralement plus élevé quand vous utilisez le programmateur LLQ que quand vous utilisez le programmateur conforme DOCSIS, dans DOCSIS typique ou réseaux basés sur PacketCable, des niveaux de jitter de programmateur LLQ êtes tout à fait en conformité avec la capacité de technologie de mémoire tampon de jitter de point final VoIP. Ceci signifie qu'il n'y a aucune incidence apparente sur la qualité des communications VoIP quand vous utilisez le programmateur LLQ dans un réseau VoIP correctement conçu.

Vous pouvez limiter le jitter qui provient de grandes rafales en amont. Pour ceci, assurez-vous que vous gardez le paramètre de par défaut-phy-rafale de câble à la valeur par défaut de 2000 octets ou de moins. Si un système utilise un canal ascendant particulièrement lent, dites avec un KHZ 800 ou une plus petite largeur de canal, vous pouvez réaliser d'autres réductions de jitter si vous forcez de grandes rafales à fragmenter dans les plus petites avec la commande en amont de fragment-force de câble.

Quand le programmateur LLQ est en service, vous devez configurer le contrôle d'admission de câble afin d'empêcher la possibilité de surabonnement du canal ascendant. Un service plus actif UGS circule que l'en amont peut physiquement manipuler, mène à la médiocre qualité de voix à travers tous les écoulements de service UGS sur l'en amont. Dans des cas extrêmes, ceci signifie également que les Modems câble hors ligne et nouveaux de chute de Modems câble ne peuvent pas être livré en ligne. Cisco recommande que les opérateurs CMTS configurent le contrôle d'admission tels que toute l'utilisation en amont sur aucun port ascendant n'est pas au-dessus de 75% pendant des longues périodes.

Conclusions

La gamme d'ubr de Cisco de Produits DOCSIS CMTS fournit deux algorithmes de planification en amont alternatifs, et ainsi peut couvrir un grand choix d'états de réseau.

Le programmateur conforme DOCSIS, qui est optimisé pour la gigue faible, approprié plus aux systèmes vocaux typiques de Packetcable 1.x avec un codec de l'uniforme VoIP en place et où les niveaux standard de l'utilisation du canal ascendant par des écoulements de service UGS est désiré.

Le programmateur de queue de basse latence est conçu pour prendre en charge les niveaux élevé-que-normaux de l'utilisation en amont par des écoulements de service UGS, efficacité accrue du trafic de meilleur effort, et les systèmes qui utilisent le service UGS et RTPS circule avec un grand choix d'intervalles de concession et de tailles de concession.

Annexe A : Minislots

Un minislot est la plus petite unité de la transmission dans l'en amont DOCSIS. Quand un modem câble transmet une demande de bande passante au CMTS de demander le délai de transmission en amont, le modem demande dans les unités des minislots plutôt qu'en quelques octets ou millisecondes. En outre, quand un message de tableau d'allocation de largeur de bande informe des Modems de quand ils peuvent transmettre et pendant combien de temps, le message contient les informations dans les unités des minislots.

Le nombre maximal de minislots qu'un modem peut inviter à transmettre dans un éclaté est 255. La taille du mini emplacement est spécifiée dans les unités appelées les coutils DOCSIS. Un coutil DOCSIS est l'équivalent de 6.25 microsecondes à temps.

Pour fixer la taille du mini emplacement dans les coutils pour un port ascendant, émettez la taille du mini emplacement en amont [1 de <upstream-number> de câble | 2 | 4 | 8 | 16 | 32 | 64 | commande de l'interface de câble 128].

Seulement on permet certaines tailles du mini emplacement avec les largeurs du canal ascendant particulières. Cette table affiche des tailles du mini emplacement valides contre des largeurs du canal ascendant DOCSIS, et affiche également la longueur dans des symboles de schéma de modulation d'un minislot avec les configurations valides.

Remarque: Une marque X signifie une combinaison non valide.

  Largeur de la Manche KHZ 200 KHZ 400 KHZ 800 1.6 MHZ 3.2 MHZ 6.4 MHZ
Taille du mini emplacement dans les coutils              
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

Pour calculer le nombre d'octets transmis par minislot, multipliez les symboles par minislot par le nombre de bits par symbole pour le schéma de modulation configuré. Les différents schémas de modulation transmettent des numéros différents de bits par symbole suivant les indications de cette table :

Schémas de modulation du DOCSIS 1.1 TDMA Bits par symbole
QPSK 2
16-QAM 4

Schémas de modulation du DOCSIS 2.0 ATDMA Bits par symbole
8-QAM 3
32-QAM 5
64-QAM 6

Par exemple, avec une largeur de canal de 1.6 MHZ et une taille du mini emplacement de 4 coutils, vous pouvez employer la première table pour arriver à un chiffre de 32 symboles par minislot. Employez la deuxième table pour convertir cette figure en octets, parce qu'un symbole QPSK contient 2 bits. Un minislot dans cet exemple est équivalent à 32 symboles par minislot * 2 bits par symbole = 64 bits par minislot = 8 octets par minislot.

Souvenez-vous que le nombre maximal de minislots qu'un modem câble peut demander de transmettre est 255. Par conséquent, dans cet en amont d'exemple la plus grande rafale dans les octets qu'un modem peut faire est 255 minislots * 8 octets par minislot = 2040 octets.

Notez que cette figure dans les octets est la correction d'erreurs de transfert de poteau et signalez le chiffre supplémentaire de couche physique. La correction d'erreurs et toute autre couche DOCSIS PHY supplémentaires ajoute environ 10 à 20 pour cent à la longueur d'une trame Ethernet pendant qu'elle traverse le canal ascendant. Pour dériver la figure précise, utilisez le profil de modulation appliqué au port ascendant.

Cette discussion est significative parce qu'une première section de ce document déclare qu'une des limites sur la taille de rafale maximale d'un modem câble est la valeur configurée dans la commande de par défaut-phy-rafale de câble. Si la commande de par défaut-phy-rafale de câble est placée à 4000 octets dans le cadre de cet exemple, le facteur de limitation ou la taille de rafale est la limite de 255 minislot (2040 octets sans le temps système) plutôt que la valeur de par défaut-phy-rafale de câble.

Vous pouvez observer différentes expressions de la taille du mini emplacement pour un en amont avec la commande en amont d'en amont-nombre d'interface-nombre de câble de show controller. Voici un exemple :

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 recommande que vous fixiez la taille du mini emplacement tels qu'un minislot est équivalent à 16 octets ou la plus étroite à valeur permise. Une taille du mini emplacement de 16 octets donne à des Modems câble la capacité de générer une rafale du courrier FEC de jusqu'à 255 * 16 = 4096 octets.

Annexe B : Avance de MAP

Le CMTS génère périodiquement un message spécial appelé un tableau d'allocation de largeur de bande qui informe des Modems câble d'un moment précis où les Modems peuvent faire des transmissions sur le canal ascendant. Les signaux électriques qui donnent le message de MAP prennent une durée finie pour propager physiquement par le réseau hybride du coaxial de fibre (HFC) du CMTS à tous les Modems câble connectés. En conséquence, le message de MAP doit être transmis assez tôt pour que les Modems reçoivent le message et pour peuvent faire leurs transmissions en amont de sorte qu'elles atteignent le CMTS au temps indiqué.

Le temps à l'avance de MAP ou le temps de lecture anticipée de MAP représente la différence entre le moment où le CMTS génère le message de MAP et le moment où la première transmission commandée par la MAP doit être reçue par le CMTS. Cette fois représente une combinaison de ces retards actuels dans un système DOCSIS :

  • Le temps l'où le CMTS prend pour construire le message de MAP en logiciel et pour que le message soit aligné et traité par les circuits en aval de transmission. La valeur de ce composant est spécifique à différentes Plateformes et architectures et est généralement une valeur fixe.

  • La latence que la fonction en aval d'interfoliage ajoute, qui est utilisée pour que la correction d'erreurs de transfert garde contre le bruit impulsif. Pour changer cette valeur, changez les paramètres en aval d'interleaver.

  • Le temps que les signaux électriques prennent pour voyager par le réseau HFC du CMTS au modem câble et puis de retour de nouveau. DOCSIS spécifie un un-manière-opération-temps maximum entre le CMTS et le modem câble de 800 microsecondes. Cette valeur varie selon la longueur physique de l'usine de câble. Le schéma de modulation en aval et la largeur du canal ascendant et le schéma de modulation influencent également cette valeur.

  • L'heure pour que le modem câble traite un message reçu de MAP et de peut se préparer à la transmission en amont. Ceci doit n'être pas plus de 200 microsecondes plus n'importe quel retard en amont d'interleaver selon les instructions dans la spécification DOCSIS. En réalité ce temps peut être aussi élevé que 300 microsecondes ou aussi bas que 100 microsecondes selon font, modèle et révision de microprogramme de modem câble.

Figure 35 ? Composants dans le temps à l'avance de MAP

/image/gif/paws/69704/upstrm_sch_config_35.gif

Le temps à l'avance de carte peut de manière significative affecter la latence des transmissions en amont parce que cette valeur représente le retard minimum entre le moment où le CMTS sait qu'un modem câble veut faire une transmission et le moment où le modem est permis pour faire cette transmission. Pour cette raison, réduisez l'heure à l'avance de carte de réduire la latence en amont.

Notez cela dans un en amont congestionné, d'autres facteurs influencent également la latence en amont. Par exemple, retards qui les causes d'algorithme de demande de bande passante d'interruption et de relance, et la queue des concessions en suspens derrière une des autres.

La figure 36 affiche le rapport entre une MAP que le CMTS se produit et les données correspondantes acquittent à l'en amont.

Figure 36 ? Rapport entre la génération de MAP et la réception des données ascendantes

/image/gif/paws/69704/upstrm_sch_config_36.gif

Profondeur d'Interleaver

Le premier facteur dans le temps à l'avance de carte qui peut varier est l'interleaver en aval comme utilisé pour la protection de bruit impulsif. Cette table affiche la latence ajoutée aux transmissions en aval pour différentes prise d'interleaver et configurations d'incrément d'interleaver :

Remarque: Plus la taille de prise est grande, plus la correction d'erreurs est puissante, mais également plus est la latence induite grande.

I (nombre de Prises) J (incrément) Latence 64-QAM Latence 256-QAM
8 16 220 sec de ½ du ¿  ï 150 sec de ½ du ¿  ïÂ
16 8 480 sec de ½ du ¿  ï 330 sec de ½ du ¿  ïÂ
32 4 980 sec de ½ du ¿  ï 680 sec de ½ du ¿  ïÂ
64 2 2000 sec de ½ du ¿  ï 1400 sec de ½ du ¿  ïÂ
128 1 4000 sec de ½ du ¿  ï 2800 sec de ½ du ¿  ïÂ
12 (EuroDOCSIS) 17 (EuroDOCSIS) 430 sec de ½ du ¿  ï 320 sec de ½ du ¿  ïÂ

Vous pouvez placer les paramètres d'interleaver avec le cable downstream interleave-depth [8 | 16 | 32 | 64 | commande de configuration de l'interface de câble 128]

Remarque: La valeur pour I (nombre de Prises) est spécifiée et une valeur correspondante fixe pour J (incrément) comme vu dans la table s'applique automatiquement. Le mode en outre, parce que d'EuroDOCSIS (annexe A) les paramètres d'interleaver sont réparés à I = 12 et J = 17. La valeur par défaut pour I est 32, qui donne une valeur par défaut pour J de 4.

Durée d'aller-retour

Le deuxième facteur qui contribue pour tracer le temps anticipé qui peut être varié est la durée d'aller-retour électrique entre le CMTS et les Modems câble. La distance physique entre le CMTS et les Modems câble et le retard de traitement inhérent dans les Modems câble influencent cette valeur.

Les mandats de spécification DOCSIS que l'un temps de propagation maximal permis de manière entre le CMTS et le autre modem câble dans le système ne soit pas plus de 800 microsecondes. Ceci implique une durée d'aller-retour, à l'exclusion du modem câble traitant le retard, d'environ 1600 microsecondes.

La vitesse de la lumière dans un aspirateur est approximativement 186,000 milles par seconde (300,000 kilomètres par seconde) et la vitesse de la propagation pour la fibre est typiquement citée en tant que 0.67. Par conséquent, l'une distance maximale permise de manière entre un CMTS et un modem câble est approximativement :

	Distance = Velocity * Time

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

       		 = 100 miles or 161 kilometers.

Selon la spécification DOCSIS le modem câble traitant le retard ne doit pas dépasser 200 microsecondes plus aucun retard en amont d'interfoliage. Cependant, dans de rares cas, quelques marques plus anciennes de modem câble peuvent prendre tant que 300 microsecondes pour traiter un message de MAP. De plus nouveaux types de Modems câble avec des CPU plus puissantes peuvent prendre aussi peu que 100 microsecondes pour traiter un message de MAP.

Supposez que les Modems câble sont, en moyenne, conformes avec la spécification DOCSIS. Par conséquent, la durée d'aller-retour maximum doit être de 1600 + 200 = 1800 microsecondes.

La majorité de systèmes de câble sont beaucoup plus courte que 100 milles. Par conséquent il n'est pas optimal pour qu'un CMTS suppose toujours que la durée d'aller-retour électrique entre le CMTS et le autre modem câble est la valeur maximale de 1800 microsecondes.

Pour une évaluation grossière pour la plus grande durée d'aller-retour électrique prévue, ajoutez la distance de la fibre entre le CMTS et le modem câble et multipliez-vous par 16 microsecondes par mille (10 microsecondes par kilomètre). Ajoutez alors la distance de n'importe quel coaxial et multipliez cette valeur par 12.4 microsecondes par mille (7.6 microsecondes par kilomètre). Ajoutez alors les 200 microsecondes traitant le retard.

Par exemple, un segment HFC avec un total de 20 milles de fibre et d'une par mille de coaxial entre le CMTS et le autre modem câble a pu s'attendre à un délai d'aller-retour électrique de :

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

= 532.4 microseconds

Cette figure ne prend pas en considération des retards de frais supplémentaires devant en amont et en aval creuser des rigoles des caractéristiques et des variations des temps de traitement de modem. Par conséquent il n'est pas appropriée l'utiliser cette valeur quand vous calculez le temps à l'avance de MAP.

Une manière plus précise de déterminer la durée d'aller-retour dans un système est d'observer le « décalage temporel » pour des Modems câble comme vu dans la sortie de la commande de show cable modem. Comme partie du processus de télémétrie que les Modems câble les utilisent pour mettre à jour la transmission avec le CMTS, le CMTS calcule la durée d'aller-retour pour chaque modem câble. Cette durée d'aller-retour apparaît comme « décalage temporel » dans la sortie de commande de show cable modem dans les unités de 1/10.24MHz = 97.7 nanosecondes appelées des unités de décalage temporel ou de décalage de télémétrie. Pour convertir le décalage temporel pour un modem en microsecondes, multipliez la valeur par 25/256, ou divisez très rudement la valeur par 10.

Voici un exemple dans lequel les décalages temporels de divers modem in la sortie de commande de show cable modem sont convertis en valeur de microseconde :

Remarque: La valeur de microseconde apparaît en italique.

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)

Dans ce cas, le autre modem loin est électriquement le dernier modem avec un décalage temporel de 6030. Ceci égalise à une durée d'aller-retour de 6030 * 25/256 = 589 microsecondes.

Avance statique de MAP

Dans un système où vous savez que la longueur du réseau HFC est de manière significative moins de 100 milles, vous pouvez configurer le CMTS pour utiliser une durée d'aller-retour maximum qui est moins que la norme pendant 1800 microsecondes où vous calculez le temps à l'avance de MAP.

Pour forcer le CMTS pour utiliser une valeur en douane pour la durée d'aller-retour dans le calcul à l'avance de MAP, émettez la commande statique d'interface de câble de maximum-rond-opération-temps cable map-advance.

La plage pour le maximum-rond-opération-temps est de 100 à 2000 microsecondes. Si aucune valeur n'est spécifiée pour le maximum-rond-opération-temps, le par défaut de 1800 microsecondes s'applique.

Remarque: Vous pouvez remplacer le mot clé statique par le mot clé dynamique. Voyez la section suivante.

Assurez-vous que le Round-Trip Time spécifié est en effet plus grand que le plus grand CMTS à la durée d'aller-retour de modem câble sur le canal descendant. Si un modem câble a une plus grande durée d'aller-retour que cela spécifié à temps, le modem peut le trouver difficile à rester en ligne. Ce ne peut pas parce qu'un tel modem n'a pas le temps suffisant pour répondre à un message de MAP et est donc communiquer avec le CMTS.

Si le décalage de temps d'un modem câble, converti en microsecondes, dépasse le maximum-rond-opération-temps spécifié, le modem est identifié par le mauvais indicateur de décalage temporel. Cet indicateur excentré apparaît comme point d'exclamation (!) à côté du décalage temporel du modem câble dans la sortie de commande de show cable modem. Cette situation peut se produire si le paramètre de maximum-rond-opération-temps est placé si bas ou si le modem câble souffre d'un problème où son décalage temporel est instable et augmente constamment au fil du temps.

Voici un exemple :

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)

Dans cet exemple, la commande de la charge statique 500 de cable map-advance est spécifiée. Cependant, un des Modems câble connectés à l'interface de câble a un décalage temporel de plus considérablement que 500 microsecondes (d'équivalent à 500 * 256/25 = 5120 unités de décalage temporel).

Notez que le décalage temporel du dernier modem câble est identifié par le mauvais indicateur de décalage temporel, « ! ». Ceci est également réparé à la valeur de maximum autorisé de 5120 unités quoique le décalage temporel vrai puisse être beaucoup plus élevé. Ce modem câble peut aller off-line et souffrir du mauvais fonctionnement.

Les mauvais restes d'indicateur de décalage temporel placent pour le modem câble même si le décalage temporel tombe au-dessous du maximum-rond-opération-temps. La seule manière d'effacer l'indicateur est de retirer le modem temporairement de la liste de show cable modem. Pour ceci, vous pouvez utiliser la commande claire d'effacement de mac-address de modem câble. Alternativement, vous pouvez remettre à l'état initial l'interface de câble ou le port ascendant.

Pour observer l'exécution de l'algorithme statique à l'avance de carte sur a par base en amont, émettez la commande en amont d'en amont-nombre d'interface-nombre de câble de show controller. Voici un exemple :

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

Le champ (statique) à l'avance de carte affiche un temps à l'avance de carte de 3480 microsecondes. Si vous changez les caractéristiques en aval d'interleaver ou le paramètre de maximum-rond-opération-temps, la variation est reflétée de la valeur statique à l'avance de carte.

Avance dynamique de MAP

L'utilisation du calcul statique à l'avance de MAP d'optimiser les temps anticipés de MAP exige de l'opérateur CMTS de déterminer manuellement la plus grande durée d'aller-retour sur un segment de câble. Si des caractéristiques d'en aval ou de canal ascendant changent, ou si des conditions de l'entreprise changent, la durée d'aller-retour maximum peut changer de manière significative. Il peut être difficile de mettre à jour continuellement la configuration pour faciliter le changement des conditions du système.

L'algorithme dynamique à l'avance de MAP résout ce problème. L'algorithme dynamique à l'avance de MAP analyse périodiquement la liste de show cable modem pour rechercher le modem avec le plus grand décalage temporel de classement initial, et puis automatiquement les utilisations qui évaluent pour calculer le temps à l'avance de MAP. Ainsi, le CMTS utilise toujours le plus bas possible temps à l'avance de carte.

Le décalage temporel de classement initial pour un modem câble est le décalage temporel que le modem signale au point où le modem est livré en ligne. Dans la plupart des cas, c'est proche du décalage temporel allant en fonction comme vu dans la sortie de commande de show cable modem. Cependant, quelques types de Modems câble ont un problème où le décalage temporel rampe vers le haut au fil du temps aux valeurs très grandes. Ceci peut biaiser le calcul de temps à l'avance de carte. Ainsi seulement le décalage temporel de classement initial, qui est seulement mis à jour si un modem est livré en ligne, est utilisé. Pour visualiser le décalage temporel de classement initial et le décalage temporel actuel pour un modem câble, émettez la commande bavarde de show cable modem. Voici un exemple :

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

Dans cet exemple, le décalage de temps actuel (2566) est légèrement supérieur au décalage temporel de classement initial (2560). Ces valeurs peuvent différer légèrement. Cependant, si les valeurs diffèrent par plus que quelques cent unités, il peut y a un problème avec le contrôle de décalage temporel du modem câble.

Pour lancer le calcul dynamique à l'avance de carte, émettez la commande dynamique d'interface de câble de maximum-rond-opération-temps de sécurité-facteur cable map-advance.

Le paramètre de sécurité-facteur s'étend de 100 à 2000 microsecondes. Ce paramètre est ajouté au temps à l'avance de MAP afin de fournir une petite sauvegarde pour expliquer tous les retards imprévus supplémentaires dans la propagation de signal. La valeur par défaut est de 1000 microsecondes. Cependant, pour les systèmes de câble stables qui ne subissent pas des changements importants dans le câble plantent ou dans des caractéristiques d'en amont ou de canal descendant, utilisez une valeur inférieure telle que 500 microsecondes.

Le paramètre de maximum-rond-opération-temps s'étend de 100 à 2000 microsecondes. Ce paramètre est utilisé comme une limite supérieure pour les décalages de temps des Modems câble s'est connectée au segment de câble. La valeur par défaut est de 1800 microsecondes. Si le décalage de temps d'un modem câble, converti en microsecondes, dépasse le maximum-rond-opération-temps spécifié, il semble marqué avec le mauvais indicateur de décalage temporel.

Placez le paramètre de temps de maximum-rond-opération non à une valeur par défaut quand vous savez que la longueur du système de câble est de manière significative moins de 100 milles, et si vous savez ce qui doit être le décalage de temps réglementaire maximum pour des Modems câble connectés au segment.

Observez l'exécution de l'algorithme dynamique à l'avance de carte sur a par base en amont avec la commande en amont d'en amont-nombre d'interface-nombre de câble de show controller. Voici un exemple :

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

La valeur de décalage temporel de Tx affiche le plus grand décalage temporel pour tous les Modems câble connectés à l'en amont dans des unités de décalage temporel. Employez cette valeur pour calculer le temps à l'avance de MAP. Le champ (dynamique) à l'avance de carte affiche le temps résultant à l'avance de carte. Cette valeur peut varier si le décalage temporel de Tx change, si la sécurité-valeur est modifiée, ou si les caractéristiques en aval d'interleaver sont changées.

L'algorithme dynamique à l'avance de MAP dépend de si les Modems câble signalent leur décalage temporel de classement initial au CMTS correctement. Malheureusement, quelques marques et modèle de Modems câble signalent les décalages temporels de classement initial comme valeurs qui sont sensiblement inférieures que la valeur vrai. Vous pouvez observer ceci quand les Modems affichent les décalages temporels qui sont proches des valeurs zéro ou même négatives.

Messages d'erreur semblables à %UBR7200-4-BADTXOFFSET : Le mauvais décalage temporel -2 détecté pour le modem câble 00ff.0bad.caf3 peut apparaître sur de tels Modems câble. Ces types de Modems câble ne signalent pas leurs décalages temporels d'une manière conforme DOCSIS, l'algorithme dynamique à l'avance de carte ne peut pas correctement calculer une période à l'avance de carte qui est garantie pour donner chaque temps de modem câble pour recevoir et répondre POUR TRACER des messages.

Si de tels Modems câble sont présents sur un segment de câble, désactivez l'algorithme dynamique à l'avance de MAP et retournez à l'algorithme statique à l'avance de MAP. Référez-vous à pourquoi faites quelques Modems câble affichent un décalage de temps négatif ? pour plus d'informations.


Informations connexes


Document ID: 69704