Configuratie van upstream plannermodus voor Cisco uBR CMTS

Inleiding

Dit document behandelt de configuratie van de upstream plannermodus voor de Cisco Universal Broadband Router (uBR) reeks Cable Modem Termination Systems (CMTS).

Dit document is gericht op personeel dat werkt met het ontwerp en het onderhoud van snelle data-over-kabelnetwerken die gebruik maken van latentie en jitter-gevoelige upstream services, bijvoorbeeld spraak- of video-over-IP.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Data-over-Cable Service Interface Specifications (DOCSIS) systemen

• Cisco uBR-serie van CMTS

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• Cisco uBR CMTS

• Cisco IOS®-softwarerelease treinen 12.3(13a)BC en 12.3(17a)BC

Opmerking: Raadpleeg voor informatie over wijzigingen in latere releases van Cisco IOS-software de juiste releases die beschikbaar is op de website Cisco.com.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Achtergrondinformatie

In een DOCSIS-netwerk (Data-over-Cable Service Interface Specifications) controleert CMTS de timing en snelheid van alle upstream transmissies van kabelmodems. Veel verschillende soorten diensten met verschillende latentie-, jitter- en doorvoervereisten worden tegelijkertijd uitgevoerd op een modern DOCSIS-netwerk upstream. Daarom moet u begrijpen hoe CMTS beslist wanneer een kabelmodem stroomopwaartse transmissies namens deze verschillende soorten diensten kan maken.

Dit witboek bevat:

• Een overzicht van de upstream-planningsmodi in DOCSIS, inclusief de best mogelijke inspanning, Unrequested Grant Service (UGS) en real-time polling Service (RTPS)

• De bediening en configuratie van de DOCSIS-compatibele planner voor Cisco uBR CMTS

• De bediening en configuratie van de nieuwe planner voor lage latentie voor Cisco uBR CMTS

Upstream planning in DOCSIS

Een DOCSIS-compatibele CMTS kan verschillende upstream planningsmodi voor verschillende pakketstromen of toepassingen bieden via het concept van een servicestroom. Een servicestroom vertegenwoordigt een stroomopwaartse of een stroomafwaartse stroom van gegevens, die een servicestroom-ID (SFID) uniek identificeert. Elke servicestroom kan zijn eigen QoS-parameters (Quality of Service) hebben, bijvoorbeeld een maximale doorvoersnelheid, een minimale gegarandeerde doorvoersnelheid en prioriteit. In het geval van upstream servicestromen kunt u ook een planningsmodus specificeren.

U kunt meer dan één upstream servicestroom voor elke kabelmodem hebben om verschillende typen toepassingen te kunnen verwerken. Bijvoorbeeld, web en e-mail kunnen één servicestroom gebruiken, spraak over IP (VoIP) kan een andere gebruiken, en Internet gaming kan nog een andere servicestroom gebruiken. Om voor elk van deze toepassingen een geschikt type dienst te kunnen leveren, moeten de kenmerken van deze dienstenstromen verschillend zijn.

De kabelmodem en CMTS kunnen de correcte types van verkeer in de geëigende dienstenstromen met het gebruik van classificators leiden. Classifier zijn speciale filters, zoals toegangslijsten, die pakketeigenschappen zoals UDP en TCP poortnummers aanpassen om de juiste servicestroom voor pakketten te bepalen om door te reizen.

In figuur 1 heeft een kabelmodem drie upstream servicestromen. De eerste servicestroom is gereserveerd voor spraakverkeer. Deze servicestroom heeft een lage maximale doorvoersnelheid, maar is ook geconfigureerd om een lage latentie te bieden. De volgende servicestroom is voor algemeen web- en e-mailverkeer. Deze servicestroom heeft een hoge doorvoersnelheid. De laatste servicestroom is gereserveerd voor peer-to-peer (P2P) verkeer. Deze servicestroom heeft een restrictievere maximale doorvoersnelheid om de snelheid van deze toepassing te beperken.

Afbeelding 1 - Een kabelmodems met drie upstream servicestromen

De servicestromen worden ingesteld en geactiveerd wanneer een kabelmodem voor het eerst online komt. Verstrek de details van de servicestromen in het DOCSIS-configuratiebestand dat u gebruikt om de kabelmodem te configureren. Verstrek minstens één servicestroom voor het stroomopwaarts verkeer en één andere dienstenstroom voor het stroomafwaarts verkeer in een DOCSIS-configuratiebestand. De eerste upstream en downstreamservicestromen die u in het DOCSIS-configuratiebestand specificeert, worden de primaire servicestromen genoemd.

De servicestromen kunnen ook dynamisch worden gecreëerd en geactiveerd nadat een kabelmodemmodule online komt. Dit scenario is over het algemeen van toepassing op een servicestroom, die overeenkomt met gegevens die behoren tot een VoIP-telefoongesprek. Een dergelijke servicestroom wordt gegenereerd en geactiveerd wanneer een telefoongesprek begint. De servicestroom wordt dan gedeactiveerd en verwijderd wanneer de verbinding wordt beëindigd. Als de servicestroom alleen bestaat wanneer dit nodig is, kunt u upstream bandbreedte-bronnen en systeem CPU-lading en -geheugen opslaan.

Kabelmodems kunnen te allen tijde geen upstream-transmissie maken. In plaats daarvan moeten modems op instructies van CMTS wachten alvorens zij gegevens kunnen verzenden, omdat slechts één kabelmodem gegevens over een stroomopwaarts kanaal tegelijkertijd kan verzenden. Anders kunnen transmissies elkaar overschrijden en corrumperen. De instructies wanneer een kabelmodem een transmissie kan maken komen van CMTS in de vorm van een bericht van de Toewijzing MAP van bandbreedte. Cisco CMTS stuurt elke 2 milliseconden een MAP-bericht door om de kabelmodems te vertellen wanneer ze een transmissie van welke aard dan ook kunnen maken. Elk MAP-bericht bevat informatie die de modems precies vertelt wanneer ze een transmissie moeten maken, hoe lang de transmissie kan duren en welk type gegevens ze kunnen verzenden. Hierdoor botsen kabelmodemgegevenstransmissies niet met elkaar en voorkomen ze gegevenscorruptie. In dit gedeelte worden enkele manieren besproken waarop CMTS kan bepalen wanneer u een kabelmodemtoestemming kunt geven om in de upstream een transmissie te maken.

Beste inspanning

Optimale planning van de inspanningen is geschikt voor klassieke internettoepassingen zonder strenge eisen op latentie of jitter. Voorbeelden van deze toepassingen zijn e-mail, web browsing of peer-to-peer bestandsoverdracht. Best inspanning schema is niet geschikt voor toepassingen die gegarandeerde latentie of jitter vereisen, bijvoorbeeld spraak of video via IP. Dit komt doordat in verzadigde omstandigheden een dergelijke garantie niet op de beste inspanningsmodus kan worden verleend. Met DOCSIS 1.0-systemen kan alleen dit type planning worden gebruikt.

De best mogelijke servicestromen worden doorgaans geleverd in het DOCSIS-configuratiebestand dat bij een kabelmodem is gekoppeld. Daarom zijn de best mogelijke servicestromen over het algemeen actief zodra de kabelmodem online komt. De primaire upstream servicestroom, dat is de eerste upstream servicestroom die bevoorraad wordt in het DOCSIS-configuratiebestand, moet een optimale servicestroom in de inspanningsstijl zijn.

Hier zijn de meest gebruikte parameters die een optimale servicestroom in de DOCSIS 1.1/2.0-modus definiëren:

• Max. doorlopende verkeerssnelheid (R)

  Het maximum Aanhoudende Verkeerssnelheid is de maximumsnelheid waarmee het verkeer via deze servicestroom kan werken. Deze waarde wordt uitgedrukt in bits per seconde.

• Maximale verkeersbelasting (b)

  Max. doorvoersnelheid verwijst naar de uitbarstgrootte in bytes die van toepassing is op de emmer-snelheidsbeperking die de doorvoersnelheid vanaf het begin afdwingt. Als er geen waarde wordt gespecificeerd is de standaardwaarde van 3044 van toepassing, wat de grootte van twee volledige Ethernet frames is. Stel voor grote maximale duurzame verkeerssnelheden deze waarde in op ten minste de maximale doorlopende verkeerssnelheid gedeeld door 64.

• Verkeersprioriteit

  Deze parameter heeft betrekking op de prioriteit van verkeer in een dienstenstroom die van 0 (de laagste) tot 7 (de hoogste) loopt. In de stroomopwaarts gelegen fase is al het verkeer dat nog in behandeling is voor de dienstenstromen met een hoge prioriteit gepland voor de transmissie vóór het verkeer voor de dienstenstromen met een lage prioriteit.

• Reservepercentage

  Deze parameter geeft een minimale gegarandeerde doorvoersnelheid in bits per seconde aan voor de servicestroom, vergelijkbaar met een geëngageerd informatiesnelheid (CIR). De gecombineerde minimum gereserveerde tarieven voor alle servicestromen op een kanaal mogen de beschikbare bandbreedte op dat kanaal niet overschrijden. Anders is het onmogelijk de beloofde minimumreserveringen te garanderen.

• Maximum aantal gecondenseerde lasten

  Maximum aantal geconvergeerde Burst is de grootte in bytes van de grootste transmissie van aaneengeschakelde frames die een modem namens de servicestroom kan maken. Zoals deze parameter impliceert, kan een modem meerdere frames verzenden in één uitbarsting van transmissie. Als deze waarde niet is gespecificeerd, gaan DOCSIS 1.0 kabelmodems en oudere DOCSIS 1.1-modems ervan uit dat er geen expliciete limiet is ingesteld op de aaneengeschakelde burstgrootte. Modules die compatibel zijn met meer recente herzieningen van DOCSIS 1.1 of latere specificaties gebruiken een waarde van 1522 bytes.

Wanneer een kabelmodem gegevens heeft om namens een stroomopwaartse dienstenstroom te verzenden, kan de modem de gegevens zonder vertraging naar het DOCSIS netwerk doorsturen. De modem moet door een proces gaan waar de modem exclusieve upstream transmissietijd van de CMTS vraagt. Dit aanvraagproces garandeert dat de gegevens niet in botsing komen met de transmissies van een andere kabelmodem die op hetzelfde upstream kanaal is aangesloten.

Soms organiseert CMTS bepaalde periodes waarin CMTS kabelmodems toelaat om speciale berichten te verzenden genaamd bandbreedteverzoeken. Het bandbreedteverzoek is een zeer klein frame dat details bevat van de hoeveelheid gegevens die de modem wilt verzenden, plus een IDD (Service identifier) die overeenkomt met de upstream-servicestroom die de gegevens moet verzenden. CMTS houdt een interne tabel bij die de nummers van SID's aan de upstream-servicestromen aansluit.

CMTS organiseert bandbreedte om kansen te vragen wanneer geen andere gebeurtenissen in de upstream gepland zijn. Met andere woorden: de planner biedt mogelijkheden voor het aanvragen van bandbreedte wanneer de upstream-planner niet heeft gepland voor een best-inspanningssubsidie, of UGS-subsidie of een ander soort subsidie die op een bepaald punt moet worden geplaatst. Daarom, wanneer een upstream kanaal zwaar gebruikt wordt, bestaan er minder mogelijkheden voor kabelmodems om bandbreedte verzoeken over te brengen.

CMTS waarborgt altijd dat een klein aantal van de mogelijkheden van het bandbreedteverzoek regelmatig gepland zijn, ongeacht hoe gecongested het upstream kanaal wordt. Meervoudige kabelmodems kunnen bandbreedteverzoeken tegelijkertijd verzenden en elkaars transmissies beschadigen. Om het potentieel voor botsingen te verminderen die bandbreedteverzoeken kunnen corrupt maken, is een "backoff and retry" algoritme aanwezig. De volgende secties van dit document bespreken dit algoritme.

Wanneer CMTS een bandbreedte verzoek van een kabelmodem ontvangt, voert CMTS deze acties uit:

1. CMTS gebruikt het SID nummer dat in het bandbreedteverzoek is ontvangen om de servicestroom te onderzoeken waarmee het bandbreedteverzoek is geassocieerd.

2. CMTS gebruikt dan het token emmer algoritme. Dit algoritme helpt de CMTS om te controleren of de servicestroom de voorgeschreven maximum aanhoudende snelheid zal overschrijden als de CMTS de gevraagde bandbreedte verleent. Hier is de berekening van het algoritme van een token:

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

   waarin:

   • Max(T) geeft het maximale aantal bytes aan dat op de servicestroom in de tijd T kan worden verzonden.

   • T vertegenwoordigt tijd in seconden.

   • R geeft het maximale duurzame verkeerstarief aan voor de servicestroom in bits per seconde

   • B is de maximale verkeersuitbarsting voor de servicestroom in bytes.

3. Wanneer CMTS vaststelt dat het bandbreedteverzoek binnen doorvoergrenzen is, stelt CMTS de details van het bandbreedteverzoek aan de upstream planner in de wachtrij. De upstream planner beslist wanneer je het bandbreedte-verzoek wilt inwilligen.

   De Cisco uBR CMTS implementeert twee upstream planner-algoritmen, de DOCSIS-conforme planner en de lage latentieserver. Zie het gedeelte DOCSIS-conforme planner en het gedeelte Low Latency Queueing van dit document voor meer informatie.

4. CMTS bevat dan deze details in het volgende periodieke bericht van de Toewijzing MAP van bandbreedte:

   • Wanneer de kabelmodem kan verzenden.

   • Voor hoe lang de kabelmodem kan verzenden.

Bandbreedteaanvraag, algoritme en opnieuw proberen

Het bandbreedte aanvraagmechanisme gebruikt een eenvoudig "backoff en retry" algoritme om het potentieel voor botsingen tussen meerdere kabelmodems te verminderen maar niet volledig te elimineren die gelijktijdig bandbreedte-verzoeken verzenden.

Een kabelmodem die beslist een bandbreedteverzoek te verzenden moet eerst op een willekeurig aantal mogelijkheden van het bandbreedteverzoek wachten om door te gaan alvorens de modem de transmissie maakt. Deze wachttijd helpt de mogelijkheid van botsingen te verminderen die door gelijktijdige transmissie van bandbreedte verzoeken voorkomen.

Twee parameters noemden het gegevensback-upbegin en het gegevensback-upeinde bepaalt de willekeurige wachttijd. De kabelmodems leren deze parameters als deel van de inhoud van het periodiek upstream kanaal descriptor (UCD) bericht. CMTS zendt het UCD-bericht namens elk actief upstreamkanaal elke twee seconden door.

Deze schaduwparameters worden uitgedrukt als "vermogen van twee" waarden. De modems gebruiken deze parameters als twee om te berekenen hoe lang te wachten alvorens zij bandbreedte verzoeken verzenden. Beide waarden hebben een bereik van 0 tot 15 en het doel van het terugdraaien van de gegevens moet groter zijn dan of gelijk aan het teruglopen van de gegevens.

De eerste keer dat een kabelmodem een bepaald bandbreedteverzoek wil verzenden, moet de kabelmodem eerst een willekeurig aantal tussen 0 en 2 aan de macht van gegevensbackoff start min 1 kiezen. Als bijvoorbeeld gegevensbackstart op 3 is ingesteld, moet de modem een willekeurig aantal tussen 0 en (2³ - 1) = (8 - 1) = 7 kiezen.

De kabelmodem moet dan op het geselecteerde willekeurige aantal van bandbreedte verzoeken om transmissiemogelijkheden om door te gaan alvorens de modem een bandbreedte verzoek overbrengt. Dus terwijl een modem geen bandbreedte verzoek bij de volgende beschikbare kans wegens deze gedwongen vertraging kan verzenden, vermindert de mogelijkheid van een botsing met de transmissie van een andere modem.

Natuurlijk is hoe hoger de waarde van de terugloop van gegevens, lager de mogelijkheid van aanrijdingen tussen bandbreedteaanvraag. Grotere data backoff start waarden betekenen ook dat modems potentieel langer moeten wachten om bandbreedte verzoeken te verzenden, en dus upstream latency groeit.

CMTS bevat een ontvangstbevestiging in het volgende bericht van de MAP-toewijzing van bandbreedte. Deze erkenning informeert de kabelmodem dat het bandbreedte verzoek met succes werd ontvangen. Deze erkenning kan:

• of precies aangeven wanneer de modem de transmissie kan maken

  OF

• alleen aangeven dat het bandbreedteverzoek is ontvangen en dat een tijdstip voor verzending zal worden bepaald in een toekomstig MAP-bericht.

Als CMTS geen ontvangstbevestiging van het bandbreedteverzoek in het volgende MAP bericht bevat, kan de modem concluderen dat het bandbreedteverzoek niet werd ontvangen. Deze situatie kan zich voordoen als gevolg van een botsing of door lawaai vóór de stroom, of als de servicestroom de voorgeschreven maximale doorvoersnelheid overschrijdt, indien het verzoek wordt ingewilligd.

In beide gevallen, is de volgende stap voor de kabelmodem om achteruit te gaan, en te proberen om het bandbreedteverzoek opnieuw te verzenden. De modem verhoogt het bereik waarover een willekeurige waarde wordt geselecteerd. Om dit te doen, voegt de modem één aan de waarde van het spektakel van gegevens toe. Als de waarde voor het terugzetten van gegevens 3 is, en CMTS niet één bandbreedteaanvraag-transmissie ontvangt, wacht de modem een willekeurige waarde tussen 0 en 15 bandbreedteaanvraag-kansen voor de hertransmissie. Hier is de berekening: 23+1 - 1 = 24 - 1 = 16 - 1 = 15

De grotere reeks waarden vermindert de kans op een andere botsing. Als de modem verdere bandbreedteverzoeken verliest, blijft de modem de waarde verhogen gebruikt als macht van twee voor elke hertransmissie tot de waarde gelijk is aan gegevenspolitie eind. De kracht van twee moet niet groter worden dan de eindwaarde voor het teruglopen van gegevens.

De modem zendt een bandbreedteverzoek tot 16 keer terug, waarna de modem het bandbreedteverzoek verwerpt. Deze situatie doet zich alleen voor in zeer overvolle omstandigheden.

U kunt de eindwaarden voor de gegevensback-up en de eindwaarden voor de gegevensback-up per kabel upstream op een Cisco uBR CMTS met deze opdracht voor de kabelinterface configureren:

kabel upstream upstream-poort-id data-backoff data-backoff-start data-backoff-end

Cisco raadt u aan de standaardwaarden voor data-backoff-start en data-backkoff-end parameters te behouden, die 3 en 5 zijn. De op beweringen gebaseerde aard van het best inspanningsplanningssysteem betekent dat het voor de best mogelijke inspanningsservicestromen onmogelijk is om een deterministisch of gegarandeerd niveau van upstream latentie of jitter te bieden. Bovendien kunnen verzadigde omstandigheden het onmogelijk maken om een bepaald niveau van doorvoersnelheid te garanderen voor een optimale dienstenstroom. U kunt echter wel de eigenschappen van de servicestroom gebruiken, zoals prioriteit en minimale gereserveerde snelheid. Met deze eigenschappen kan de servicestroom het gewenste niveau van doorvoersnelheid in geconcentreerde omstandigheden bereiken.

Voorbeeld van het algoritme Backoff and Retry

Dit voorbeeld omvat vier kabelmodems genaamd A, B, C en D, aangesloten op hetzelfde stroomopwaarts kanaal. Op hetzelfde moment genaamd t₀, besluiten modems A, B en C om bepaalde gegevens in de upstream te verzenden.

Hier is het terugslag start ingesteld op 2 en data backoff eind is ingesteld op 4. Het bereik van intervallen waarvandaan de modems een interval kiezen voordat ze een bandbreedte-aanvraag proberen te verzenden is tussen 0 en 3. Hier is de berekening:

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

Hier is het aantal bandbreedte om kansen te vragen die de drie modems kiezen om van tijd t₀ te wachten.

• Modem A: 3

• Modem B: 2

• Modem C: 3

Merk op dat modem A en modem C hetzelfde aantal mogelijkheden om te wachten kiezen.

Modem B wacht op twee mogelijkheden van het bandbreedteverzoek die na t₀ verschijnen. Modem B geeft dan het bandbreedteverzoek door, dat CMTS ontvangt. Zowel modem A als modem C wachten op 3 mogelijkheden van het bandbreedteverzoek om na t₀ over te gaan. De modems A en C verzenden dan verzoeken om bandbreedte tegelijkertijd. Deze twee bandbreedteverzoeken botsen en worden corrupt. Als resultaat hiervan, bereikt geen van beide verzoeken met succes de CMTS. Afbeelding 2 toont deze opeenvolging van gebeurtenissen.

Afbeelding 2 - Bandbreedteaanvraag Voorbeeld Deel 1

De grijze balk boven in het diagram vertegenwoordigt een serie van bandbreedte verzoekmogelijkheden beschikbaar aan kabelmodems na tijd t₀. De gekleurde pijlen vertegenwoordigen bandbreedte verzoeken die de kabelmodems verzenden. Het gekleurde vakje in de grijze balk vertegenwoordigt een bandbreedteverzoek dat de CMTS met succes bereikt.

Het volgende MAP-bericht dat vanuit CMTS wordt uitgezonden bevat een subsidie voor modem B maar geen instructies voor modems A en C. Dit wijst op modems A en C dat zij hun bandbreedteverzoeken moeten opnieuw verzenden.

Bij de tweede test moeten modem A en modem C de macht van twee verhogen om te gebruiken wanneer zij het bereik van intervallen berekenen van wie te kiezen. Modem A en modem C kiezen een willekeurig aantal intervallen tussen 0 en 7. Hier is de berekening:

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

Stel dat de tijd dat modem A en modem C de noodzaak om te verzenden realiseren op ₁ realiseren is. Ga er ook van uit dat een andere modem D besluit om sommige upstream gegevens tegelijkertijd te verzenden, t₁. Modem D staat op het punt om voor het eerst een bandbreedte-verzoekoverdracht te maken. Daarom gebruikt modem D de originele waarde voor gegevensterugvloeiing start en gegevensterugkoppeling eindresultaat, namelijk tussen 0 en 3 [(22 - 1) = (4 - 1) = 3 intervallen].

De drie modems kiezen dit willekeurige aantal bandbreedte vragen mogelijkheden om te wachten van tijd t₁.

• Modem A: 5

• Modem C: 2

• Modem D: 2

Zowel modems C als D wachten op twee mogelijkheden voor bandbreedteaanvraag die na tijd t₁ verschijnen. De modems C en D verzenden dan verzoeken om bandbreedte tegelijkertijd. Deze bandbreedteverzoeken botsen en bereiken derhalve niet de CMTS. Modem A biedt vijf mogelijkheden voor bandbreedteaanvraag om door te gaan. Vervolgens stuurt modem A het bandbreedteverzoek door, dat CMTS ontvangt. Afbeelding 3 toont de botsing tussen de transmissie van modems C en D en de succesvolle ontvangst van de transmissie van modem A. De begintijd referentie voor dit cijfer is t₁.

Afbeelding 3 - Bandbreedteaanvraag Voorbeeld 2

Het volgende MAP-bericht dat vanuit CMTS wordt uitgezonden bevat een subsidie voor modem A maar geen instructies voor modems C en D. Modems C en D realiseren zich de noodzaak om de bandbreedteverzoeken opnieuw te verzenden. Modem D staat nu op het punt om het bandbreedteverzoek voor de tweede keer te verzenden. Daarom gebruikt modem D gegevensbackout start + 1 als de kracht van twee om te gebruiken in de berekening van de intervallen om te wachten. Modem D kiest een interval tussen 0 en 7. Hier is de berekening:

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

Modem C staat op het punt om het bandbreedteverzoek voor de derde keer te verzenden. Daarom gebruikt modem C start van de terugkoppeling + 2 als de macht van twee aan in de berekening van de intervallen om te wachten. Modem C kiest een interval tussen 0 en 15. Hier is de berekening:

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

Merk op dat de kracht van twee hier dezelfde is als de eindwaarde van het gegevensback-up, die vier is. Dit is het hoogste dat de kracht van twee waarde voor een modem op dit stroomopwaarts kanaal kan zijn. In het volgende bandbreedteverzoek transmissiecyclus, kiezen de twee modems dit aantal van bandbreedte verzoeken mogelijkheden om te wachten:

• Modem C: 9

• Modem D: 4

Modem D kan het bandbreedteverzoek verzenden omdat modem D wacht op vier bandbreedtevraagmogelijkheden om door te gaan. Bovendien kan modem C ook het bandbreedteverzoek verzenden, omdat modem C nu transmissie voor negen mogelijkheden van het bandbreedteverzoek verdedigt.

Helaas, wanneer modem C een transmissie maakt, belemmert een grote golf van ingress lawaai de transmissie, en CMTS niet om het bandbreedte verzoek te ontvangen (zie Afbeelding 4). Als resultaat hiervan ziet modem C er opnieuw niet in om een subsidie in het volgende MAP bericht te zien dat CMTS overbrengt. Dit maakt modem C poging tot een vierde overdracht van het bandbreedteverzoek.

Afbeelding 4 - Bandbreedteaanvraag Voorbeeld Deel 3

Modem C heeft de eindwaarde van de gegevensback van 4 al bereikt. Modem C kan het bereik niet uitbreiden dat wordt gebruikt om een willekeurig aantal te wachten intervallen te kiezen. Daarom gebruikt modem C nogmaals 4 als de macht van twee om het willekeurige bereik te berekenen. Modem C gebruikt nog steeds het bereik 0 tot 15 intervallen volgens deze berekening:

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

Bij de vierde poging is modem C in staat om een succesvolle bandbreedte verzoekoverdracht te maken zonder conflict of lawaai.

De meerdere bandbreedte verzoeken om terugzenders van modem C in dit voorbeeld toont aan wat op een verstopt upstream kanaal kan gebeuren. Dit voorbeeld demonstreert ook de mogelijke problemen die bij de beste planningsmodus betrokken zijn en waarom de best mogelijke planning niet geschikt is voor services die strikt beheerste niveaus van pakketvertraging en jitter vereisen.

Verkeersprioriteit

Wanneer CMTS meerdere hangende bandbreedte verzoeken heeft van verschillende servicestromen, kijkt CMTS de verkeersprioriteit van elke servicestroom in om te beslissen welke eerst om bandbreedte toe te kennen.

CMTS verleent transmissietijd aan alle hangende verzoeken van dienstenstromen met een hogere prioriteit vóór bandbreedte verzoeken van dienstenstromen met een lagere prioriteit. In gespannen upstreamomstandigheden leidt dit over het algemeen tot een hogere doorvoersnelheid voor dienstenstromen met hoge prioriteit in vergelijking met dienstenstromen met lage prioriteit.

Een belangrijk feit om op te merken is dat terwijl een hoge prioriteit best energie servicestroom waarschijnlijk sneller bandbreedte zal ontvangen, de servicestroom nog steeds onderhevig is aan de mogelijkheid van bandbreedte om botsingen te vragen. Om deze reden is de prioriteit van het verkeer weliswaar de doorvoersnelheid en de latentiekenmerken van een dienstenstroom kan verbeteren, maar is de prioriteit van het verkeer nog steeds geen geschikte manier om een dienstengarantie te bieden voor toepassingen die daarvoor een vereiste vormen.

Reservepercentage

De best mogelijke inspanningsservicestromen kunnen een minimaal gereserveerde tarief ontvangen om aan de eisen te voldoen. CMTS waarborgt dat een servicestroom met een gespecificeerd minimum gereserveerd tarief bandbreedte in plaats van alle andere best-inspanningsservicestromen ontvangt, ongeacht prioriteit.

Deze methode is een poging om een soort geëngageerde informatie rate (CIR) dienst te verlenen vergelijkbaar met een frame-relaisnetwerk. De CMTS heeft toegangscontrolemechanismen om ervoor te zorgen dat het gecombineerde minimum gereserveerde tarief voor alle aangesloten dienstenstromen op een bepaalde upstream de beschikbare bandbreedte van het upstreamkanaal niet kan overschrijden, of een percentage daarvan. U kunt deze mechanismen activeren met deze upstream poortopdracht:

[no] kabel upstream upstream-port-id toegangscontrole max-reserveringsgrens

De max-reserveringslimiet parameter heeft een bereik van 10 tot 1000 procent om het abonnementsniveau aan te geven in vergelijking met de beschikbare ruwe upstream-doorvoersnelheid die de CIR-diensten kunnen gebruiken. Als u een maximum van maximum reservering-reservering van meer dan 100 vormt, kan de upstream de diensten van de stijl CIR met de gespecificeerde procentuele grens oversubscripen.

De CMTS staat niet toe dat nieuwe minimum gereserveerde tariefdienstenstromen worden vastgesteld als zij de upstream-poort ertoe zouden aanzetten het geconfigureerde maximum-reserveringspercentage van de beschikbare upstream-kanaalbandbreedte te overschrijden. De minimum gereserveerde dienststromen zijn nog steeds onderworpen aan potentiële botsingen van bandbreedteverzoeken. Als zodanig kunnen de minimum-gereserveerde dienstenstromen geen echte garantie bieden voor een bepaalde doorvoersnelheid, vooral in zeer overbelaste omstandigheden. Met andere woorden, de CMTS kan alleen garanderen dat een minimum gereserveerde servicestroom in staat is om een bepaalde gegarandeerde upstream-doorvoersnelheid te bereiken als de CMTS alle vereiste bandbreedte-verzoeken van de kabelmodem kan ontvangen. Dit vereiste kan worden bereikt als u van de servicestroom een RTPS-servicestroom (realtime poling Service) maakt in plaats van een optimale servicestroom. Zie het gedeelte Real Time Polling Service (RTPS) voor meer informatie.

Giggyback-bandbreedtes

Wanneer een upstream best force servicestroom frames doorgeeft met een hoge snelheid, is het mogelijk om bandbreedte-verzoeken naar upstream gegevensframes op te sturen in plaats van afzonderlijke transmissie van de bandbreedte-verzoeken. De details van het volgende verzoek om bandbreedte worden simpelweg toegevoegd aan de header van een pakket gegevens dat in de upstream naar de CMTS wordt verzonden.

Dit betekent dat het bandbreedteverzoek niet aan bezwaren is onderworpen en derhalve een veel grotere kans heeft dat het verzoek de CMTS bereikt. Het concept van de verzoeken van de bandbreedte van de pigterug verkort de tijd die een Ethernet frame vereist om de klantUitgangshouding (CPE) van de eindgebruiker te bereiken, omdat de tijd die het kader in upstream transmissie neemt, vermindert. Dit komt doordat de modem niet door het backkoff hoeft te gaan en het bandbreedte-aanvraagproces opnieuw probeert, dat aan vertragingen kan worden onderworpen.

Piggyback van bandbreedteverzoeken komt gewoonlijk in dit scenario voor:

Terwijl de kabelmodems wachten om een kader, bijvoorbeeld X, in de upstream te verzenden, ontvangt de modem een ander frame, bijvoorbeeld Y, van een CPE om in de upstream te verzenden. De kabelmodem kan de bytes van het nieuwe frame Y aan de transmissie niet toevoegen, omdat dat het gebruik van meer upstream tijd dan de modem toelaat. In plaats daarvan vult de modem een veld in in de DOCSIS-kop van frame X om de hoeveelheid transmissietijd aan te geven die voor frame Y vereist is.

CMTS ontvangt frame X en ook de details van een bandbreedteaanvraag namens Y. Op basis van beschikbaarheid verleent CMTS de modem verdere zendtijd namens Y.

In zeer conservatieve termen, aangezien 5 milliseconden tussen de transmissie van een bandbreedteverzoek en ontvangst van bandbreedte toewijzing evenals MAP ontvangstbevestiging verstrijken die tijd voor gegevensoverdracht wijst. Dit betekent dat voor pigmentondersteuning, de kabelmodem frames van de CPE binnen minder dan 5ms van elkaar moet ontvangen.

Dit is het opmerken waard, omdat een typische VoIP-codec zoals G.711 over het algemeen een periode tussen de frames van 10 of 20 ms gebruikt. Een typische VoIP-stream die over een best mogelijke servicestroom werkt kan geen gebruik maken van een pigmentondersteuning.

concatenatie

Wanneer een upstream best force Service flow frames doorgeeft met een hoge snelheid, kan de kabelmodem zich bij een paar frames voegen en om toestemming vragen om de frames allemaal tegelijk te verzenden. Dit heet aaneenschakeling. De kabelmodem moet slechts één bandbreedteverzoek namens alle frames in een groep aaneengeschakelde frames verzenden, wat efficiëntie verbetert.

Concatenation treedt meestal op in omstandigheden die vergelijkbaar zijn met gynaecologie, behalve dat voor conversie meerdere frames vereist zijn dat er in de kabelmodem een wachtrij wordt geplaatst wanneer de modem besluit een bandbreedte-aanvraag te verzenden. Dit impliceert dat aaneenschakeling gewoonlijk plaatsvindt tegen hogere gemiddelde kadertarieven dan pigmentsteun. Bovendien werken beide mechanismen gezamenlijk samen om de efficiëntie van het inspanningsverkeer te verbeteren.

Het veld Maximum aantal ingesloten lasten dat u voor een servicestroom kunt configureren beperkt de maximale grootte van een aaneengezet frame dat een servicestroom kan verzenden. U kunt ook de opdracht default-phy-burst van de kabel gebruiken om de grootte van een aaneengezet frame en de maximale barstgrootte in het modulatieprofiel van het bovenste kanaal te beperken.

De configuratie is standaard ingeschakeld op de upstream poorten van de Cisco uBR-serie CMTS. U kunt echter aaneenschakeling op een per-upstream-poort basis controleren met de [no] kabel upstream upstream-poort-id aaneenschakeling [docsis10] kabelinterfaceopdracht.

Als u de DOCSIS10-parameter configureren is de opdracht alleen van toepassing op kabelmodems die in DOCSIS 1.0-modus werken.

Als u deze opdracht wijzigt, moeten kabelmodems zich opnieuw op CMTS registreren om de wijzigingen van kracht te laten worden. De modems in de aangetaste stroom moeten worden teruggezet. Een kabelmodem leert of de aaneenschakeling wordt toegestaan op het punt waar de modem registratie als deel van het proces van online te komen uitvoert.

fragmentatie

Grote frames duren lang om in de upstream te verzenden. Deze zendtijd staat bekend als de serialibreer vertraging. Vooral grote stroomopwaartse frames kunnen zo lang duren om te verzenden dat ze pakketten die behoren tot de tijdgevoelige services, zoals VoIP, onschadelijk kunnen uitstellen. Dit geldt in het bijzonder voor grote aaneengeschakelde frames. Om deze reden werd fragmentatie geïntroduceerd in DOCSIS 1.1 zodat grote frames kunnen worden gesplitst in kleinere frames voor transmissie in aparte uitbarstingen die elk minder tijd nodig hebben om te verzenden.

Fragmentation maakt het mogelijk kleine, tijdgevoelige frames uit te schakelen tussen de fragmenten van grote frames in plaats van te wachten op de transmissie van het gehele grote frame. De transmissie van een kader als meerdere fragmenten is iets minder efficiënt dan de transmissie van een frame in één rand door de extra set DOCSIS-headers die elk fragment moeten begeleiden. Maar de flexibiliteit die fragmentatie aan het stroomopwaarts kanaal toevoegt rechtvaardigt de extra overheadkosten.

Kabelmodems die in DOCSIS 1.0-modus werken, kunnen geen fragmentatie uitvoeren.

De fragmentatie is standaard ingeschakeld in de upstream poorten van de Cisco uBR-serie CMTS. U kunt echter fragmentatie op a per-upstream-poort basis inschakelen of uitschakelen met de opdracht [no]-kabel upstream-id-fragmentatie-kabelinterface.

U hoeft de kabelmodems niet opnieuw in te stellen, anders wordt de opdracht uitgevoerd. Cisco raadt u aan altijd fragmentatie mogelijk te maken. Fragmentation treedt normaliter op wanneer CMTS van mening is dat een groot gegevensframe de transmissie van kleine tijdgevoelige frames of bepaalde periodieke DOCSIS-beheergebeurtenissen kan verhinderen.

U kunt DOCSIS 1.1/2.0 kabelmodems forceren om alle grote frames te fragmenteren met de [no] kabel upstream upstream-poort-id fragmentatie-kracht [drempelaantal fragmenten-] kabelinterfaceopdracht.

Deze optie is standaard uitgeschakeld. Als u geen waarden voor drempel en aantal-van-fragmenten in de configuratie specificeert, wordt de drempel ingesteld op 2000 bytes en het aantal fragmenten wordt ingesteld op 3. De opdracht fragment-force vergelijkt het aantal bytes dat een servicestroom om transmissie vraagt met de gespecificeerde drempelparameter. Als de verzoekgrootte groter is dan de drempel, verleent CMTS de bandbreedte aan de service-flow in "aantal-van-fragmenten" gelijk grote delen.

Bijvoorbeeld, veronderstel dat voor een bepaald upstream fragment-force is ingeschakeld met een waarde van 2000 bytes voor drempelwaarde en 3 voor number-of-fragmenten. Ga er dan vanuit dat een verzoek om een barst van 3000 bytes te verzenden aankomt. Aangezien 3000 bytes groter zijn dan de drempel van 2000 bytes, moet de subsidie gefragmenteerd zijn. Aangezien het aantal-van-fragmenten op 3 is ingesteld, is de transmissietijd drie even grote beurzen van 1000 bytes elk.

Zorg ervoor dat de grootte van de afzonderlijke fragmenten niet groter is dan de capaciteit van het gebruikte kabellijnkaarttype. Voor MC5x20S lijnkaarten mag het grootste individuele fragment niet groter zijn dan 2000 bytes. Voor andere lijnkaarten, zoals MC28U, MC5x20U en MC5x20H, mag het grootste individuele fragment niet groter zijn dan 4000 bytes.

Ongevraagde subsidie-service (UGS)

De Unmanaged Grant Service (UGS) biedt periodieke subsidies voor een upstream servicestroom zonder dat er een kabelmodem nodig is om bandbreedte-verzoeken te verzenden. Dit type service is geschikt voor toepassingen die op regelmatige tijdstippen vaste grootte-frames genereren en niet verdragen op pakketverlies. Voice-over-IP is het klassieke voorbeeld.

Vergelijk het UGS-planningssysteem met een tijdsleuf in een TDM-systeem (Time Division Multiplexing) zoals een T1- of E1-circuit. UGS biedt een gegarandeerde doorvoersnelheid en latentie, die op hun beurt een continue stroom van vaste periodieke intervallen levert om door te geven zonder dat de client regelmatig om bandbreedte vraagt of vraagt. Dit systeem is perfect voor VoIP omdat spraakverkeer over het algemeen wordt doorgegeven als een continue stroom van periodieke gegevens met een vaste omvang.

UGS werd bedacht wegens het ontbreken van garanties voor latentie, jitter en doorvoersnelheid in de best mogelijke planningsmodus. De beste planningsmodus biedt niet de garantie dat een bepaald frame op een bepaald tijdstip kan worden doorgegeven, en in een systeem met congestie is er geen zekerheid dat een bepaald frame überhaupt kan worden doorgegeven.

Merk op dat, hoewel UGS-servicestromen het meest geschikte type servicestroom zijn om VoIP-verkeer aan toonder over te brengen, zij niet geschikt worden geacht voor klassieke internettoepassingen zoals web, e-mail of P2P. De reden hiervoor is dat klassieke internettoepassingen geen gegevens genereren met vaste periodieke tussenpozen en in feite aanzienlijke tijdsperiodes kunnen doorbrengen zonder dat gegevens worden doorgegeven. Als een UGS-servicestroom wordt gebruikt om klassieke internetverkeer over te brengen, kan de servicestroom gedurende aanzienlijke perioden ongebruikt blijven als de applicatie even stilvalt. Dit leidt tot ongebruikte UGS-subsidies die een verspilling van bandbreedte in de bovenloop vertegenwoordigen, wat niet wenselijk is.

De UGS-servicestromen worden gewoonlijk dynamisch ingesteld wanneer ze nodig zijn, in plaats van dat ze voor levering worden voorzien in het DOCSIS-configuratiebestand. Een kabelmodem met geïntegreerde VoIP-poorten kan de CMTS gewoonlijk vragen om een geschikte UGS-servicestroom te maken wanneer de modem detecteert dat een VoIP-telefoongesprek gaande is.

Cisco raadt u aan geen UGS-servicestroom in een DOCSIS-configuratiebestand te configureren, omdat deze configuratie de UGS-servicestroom actief houdt zolang de kabelmodem online is, ongeacht of de services deze gebruiken. Deze configuratie verspilt upstream bandbreedte omdat een UGS-servicestroom constant upstream transmissietijd reserveert namens de kabelmodem. Het is veel beter om UGS-servicestroom dynamisch te laten maken en verwijderen, zodat UGS indien nodig actief is.

Hier zijn de meest gebruikte parameters die een UGS-servicestroom definiëren:

• Ongevraagd subsidiebedrag (G)—De grootte van elke periodieke subsidie in bytes.

• Nominale Grant Interval (I) — Het interval in microseconden tussen de beurzen.

• Gratis Grant Jitter (J)—De toegestane variatie in microseconden van exact periodieke subsidies. Met andere woorden, dit is de speelruimte van de CMTS wanneer de CMTS op tijd een UGS-subsidie proberen te plannen.

Wanneer een UGS-servicestroom actief is, biedt CMTS (I) milliseconden een kans voor de servicestroom om te verzenden bij Unsolicated Grant Size (G) bytes. Hoewel de CMTS de subsidie precies elke (I) milliseconden aanbiedt, kan het tot (J) milliseconden laat zijn.

Afbeelding 5 toont een tijdlijn die aantoont hoe UGS-subsidies kunnen worden toegewezen met een bepaalde subsidieomvang, subsidieinterval en getolereerde jitter.

Afbeelding 5 - tijdlijn die Periodieke UGS-subsidies toont

De groene gepatenteerde blokken vertegenwoordigen tijd waarin de CMTS upstream transmissietijd aan een UGS-servicestroom besteedt.

Real Time Polling Service (RTPS)

Real Time Polling Service (RTPS) biedt periodieke, niet-contentgebaseerde, bandbreedteaanvraag-kansen, zodat een servicestroom tijd heeft gewijd aan het verzenden van bandbreedteverzoeken. Alleen de RTPS-servicestroom is toegestaan om deze unieke bandbreedte te gebruiken. Andere kabelmodems kunnen geen bandbreedte vraag botsing veroorzaken.

RTPS is geschikt voor toepassingen die halfperiodieke frames met variabele lengte genereren en een gegarandeerde minimumdoorvoersnelheid vereisen om effectief te kunnen werken. Videotelefonie via IP of online gaming van meerdere spelers zijn typische voorbeelden.

RTPS wordt ook gebruikt voor VoIP-signaleringsverkeer. Hoewel VoIP-signaleringsverkeer niet met een extreem lage vertraging of jitter hoeft te worden verzonden, moet VoIP een hoge kans hebben om de CMTS binnen een redelijke tijd te kunnen bereiken. Als u RTPS in plaats van best inspanningsschema gebruikt kunt u worden verzekerd dat de signalering van de spraak niet significant vertraagd of gedaald is wegens herhaalde bandbreedte verzoeken botsingen.

Een RTPS-servicestroom heeft doorgaans deze kenmerken:

• Nominale stemverhouding — het interval in microseconden tussen de bandbreedteaanvraag kansen.

• Gratis Poll Jitter—De toegestane variatie in microseconden uit exact periodieke peilingen. Anders gezegd, dit is de speelruimte die CMTS heeft wanneer ze een RTPS-bandbreedte-aanvraag op tijd proberen te plannen.

Afbeelding 6 toont een tijdlijn die aantoont hoe RTPS-peilingen worden toegewezen met een bepaald nominaal steminterval en een getolereerde poll-jitter.

Afbeelding 6 - tijdlijn die periodiek RTPS-opiniepeiling toont

De kleine groene gepatenteerde blokken vertegenwoordigen tijd waarin CMTS een RTPS-servicestroom biedt, een unieke bandbreedte-aanvraag.

Wanneer CMTS een bandbreedte verzoek namens een RTPS-servicestroom ontvangt, verwerkt CMTS het bandbreedteverzoek op dezelfde manier als een verzoek van een "best inspanning"-servicestroom. Dit houdt in dat naast de bovengenoemde parameters ook eigenschappen als maximale doorlopende verkeerssnelheid en verkeersprioriteit in een definitie van RTPS-dienstenstroom moeten worden opgenomen. Een RTPS-servicestroom bevat over het algemeen ook een minimaal gereserveerde verkeerssnelheid om er zeker van te zijn dat het verkeer dat met de servicestroom gepaard gaat, een vastgelegde bandbreedte-garantie kan ontvangen.

Ongevraagde subsidieservice met activiteitsdetectie (UGS-AD)

Ongevraagde subsidiedienst met activiteitsdetectie (UGS-AS) wijst de zendtijd van de UGS-stijl alleen toe aan een servicestroom wanneer UGS-AS pakketten echt moet verzenden. Wanneer CMTS ontdekt dat de kabelmodem geen frames voor een bepaalde periode heeft verzonden, biedt CMTS de mogelijkheden van de bandbreedte van de RTPS stijl in plaats van de beurzen van de stijl UGS. Als CMTS vervolgens ontdekt dat de servicestroom bandbreedteverzoeken indient, keert CMTS de servicestroom terug naar het bieden van UGS-stijfschenken en houdt op met het bieden van RTPS-bandbreedtevraagmogelijkheden.

UGS-AD wordt doorgaans gebruikt in een situatie waarin VoIP-verkeer dat spraakactiviteitsdetectie (VAD) gebruikte, werd verzonden. De detectie van spraakactiviteit veroorzaakt het VoIP-eindpunt om de transmissie van VoIP-frames te stoppen als UGS-AD een pauze in de spraak van de gebruiker detecteert. Hoewel dit gedrag bandbreedte kan opslaan, kan het problemen met de spraakkwaliteit veroorzaken, vooral als het VAD of UGS-AD activiteitsdetectiemechanisme iets activeert nadat de eindpartij opnieuw begint te spreken. Dit kan leiden tot een poppend of klik geluid aangezien een gebruiker na stilte weer het woord neemt. Om deze reden wordt UGS-AD niet op grote schaal ingezet.

Geef de configuratie-opdracht van de kabelservicestroom inactiviteit-drempelwaarde in-seconden uit om de periode in te stellen waarna de CMTS een inactieve UGS-AD-servicestroom van de UGS-modus naar de RTPS-modus switches.

De standaardwaarde voor de drempelwaarde in-seconden parameter is 10 seconden. De UGS-AD-dienstenstromen hebben over het algemeen betrekking op de eigenschappen van een UGS-dienstenstroom, het nominale steminterval en de getolereerde poll-jitter die met RTPS-dienstenstromen verband houdt.

Niet-realtime stembureaus (nRTPS)

De planningsmodus voor de niet-realtime pollingsservice (nRTPS) is in wezen dezelfde als RTPS, behalve dat nRTPS over het algemeen gekoppeld is aan niet-interactieve diensten zoals bestandsoverdracht. De niet-real-time component kan impliceren dat het nominale steminterval voor de verzoeken om unieke bandbreedte niet precies regelmatig is of kan voorkomen met een snelheid van minder dan één per seconde.

Sommige kabelnetwerkexploitanten kunnen ervoor kiezen om nRTPS in plaats van RTPS te gebruiken om spraaksignaleringsverkeer over te brengen.

Schedulingsalgoritmen

Voordat u een discussie hebt over de specificaties van de DOCSIS-conforme planner en de planner voor de lage latentie-wachtrij, moet u de trade-offs begrijpen die u moet maken om de kenmerken van een upstreamplanner te bepalen. Hoewel de discussie over planneralgoritmes vooral betrekking heeft op de UGS-planningsmodus, is de discussie ook van toepassing op RTPS-diensten.

Wanneer u besluit hoe u UGS-servicestromen wilt plannen, zijn er niet veel flexibele opties. U kunt de server niet wijzigen om de omvang van de subsidie te wijzigen of het interval voor het toekennen van UGS-servicestromen te wijzigen, omdat een dergelijke verandering ervoor zorgt dat VoIP-oproepen volledig mislukken. Maar als je de jitter verandert, werken oproepen wel, maar mogelijk met een verhoogde vertraging van de oproep. Bovendien heeft wijziging van het maximale aantal oproepen dat in een upstream is toegestaan geen invloed op de kwaliteit van individuele oproepen. Neem daarom deze twee belangrijkste factoren in aanmerking wanneer u grote aantallen UGS-servicestromen plant:

• Jitter

• UGS-dienstenstroomcapaciteit per stroomopwaartse stroom

Jitter

Een getolereerde subsidiepost wordt gespecificeerd als een van de eigenschappen van een UGS - of RTPS - dienstenstroom. Gelijktijdige ondersteuning van bepaalde dienstenstromen met zeer weinig getolereerde jitter en andere met zeer grote hoeveelheden jitter kan echter inefficiënt zijn. Over het algemeen moet u een uniforme keuze maken met betrekking tot het type werktuig dat stroomt in een stroomopwaartse fase.

Als er een laag jitterniveau nodig is, moet de planner onflexibel en rigide zijn wanneer hij subsidies verstrekt. Bijgevolg moet de planner beperkingen stellen aan het aantal UGS-dienstenstromen die in een stroomopwaarts gelegen fase worden ondersteund.

Jitterniveaus hoeven niet altijd extreem laag te zijn voor VoIP van normale gebruikers, omdat de technologie van jitterbuffers hoge niveaus van jitter kan compenseren. De moderne adaptieve VoIP-jitterbuffers kunnen compenseren voor meer dan 150 ms of jitter. Maar een VoIP-netwerk voegt de hoeveelheid buffering toe die voor de latentie van pakketten geldt. Hoge niveaus van latentie kunnen bijdragen aan een slechtere VoIP-ervaring.

UGS-servicesstroomcapaciteit per upstream

De fysieke laageigenschappen zoals de kanaalbreedte, het modulatieregeling en de foutcorrectiestroom bepalen de fysieke capaciteit van een stroomopwaarts gelegen. Het aantal gelijktijdige UGS-servicestromen dat de upstream kan ondersteunen, is echter ook afhankelijk van het planneralgoritme.

Als extreem lage jitterniveaus niet nodig zijn, kunt u de starheid van de planner versoepelen en rekening houden met een hoger aantal UGS-servicestromen die de upstream tegelijkertijd kan ondersteunen. U kunt een hogere efficiëntie van het niet-spraakverkeer in de stroomopwaartse richting bereiken als u de jittervereisten versoepelt.

Opmerking: Met verschillende planningsalgoritmen kan een bepaald stroomopwaarts kanaal verschillende UGS - en RTPS - servicestromen ondersteunen. Dergelijke diensten kunnen echter niet 100% van de stroomopwaartse capaciteit in een DOCSIS-systeem gebruiken. Dit komt doordat het upstream kanaal een deel moet wijden aan DOCSIS beheerverkeer, zoals de eerste onderhoudsberichten die kabelmodems gebruiken om eerste contact te maken met de CMTS, en het onderhoud van het station houdt het verkeer in stand dat wordt gebruikt om ervoor te zorgen dat kabelmodems connectiviteit aan CMTS kunnen onderhouden.

De DOCSIS-conforme planner

De DOCSIS-conforme planner is het standaardsysteem voor het plannen van upstream services op een Cisco uBR CMTS. Deze planner was ontworpen om de scherpte die de UGS en RTPS-service ervaren, tot een minimum te beperken. Met deze planner kunt u echter nog een zekere mate van flexibiliteit behouden om het aantal gelijktijdige UGS-oproepen per upstream te optimaliseren.

De met DOCSIS conforme planner wijst vooraf de upstream-tijd toe voor UGS-servicestromen. Voordat er andere bandbreedtetoewijzingen zijn gepland, stelt de CMTS in de toekomst tijd beschikbaar voor subsidies die behoren tot actieve UGS-dienstenstromen, om ervoor te zorgen dat geen van de andere soorten dienstenstromen of verkeersstromen de UGS-subsidies verruilt en een significante jitter veroorzaakt.

Als de CMTS verzoeken om bandbreedte ontvangt namens de dienstenstromen van de best-inspanningsstijl, moet de CMTS de transmissietijd voor de best mogelijke inspanningsdienstenstromen rond de vooraf toegekende UGS-subsidies plannen om geen invloed te hebben op de tijdige planning van elke UGS-subsidie.

Configuratie

De DOCSIS-conforme planner is het enige beschikbare upstream planneralgoritme voor Cisco IOS-softwarereleases 12.3(9a)BCx en hoger. Daarom vereist deze planner geen configuratieopdrachten voor de activering.

Voor Cisco IOS-softwarereleases 12.3(13a)BC en later is de DOCSIS-conforme planner een van twee alternatieve planneralgoritmen, maar is ingesteld als de standaardplanner. U kunt de DOCSIS-conforme planner voor één, alle of een aantal van deze planningtypen inschakelen:

• UGS

• RTPS

• NRTPS

U kunt de DOCSIS-conforme planner voor elk van deze planningtypen expliciet inschakelen met de kabel upstream-poort-planningtype [RTTP’s] | RTT | ugs] mode docsis kabelinterfaceopdracht.

Het gebruik van een met DOCSIS compatibele planner maakt deel uit van de standaardconfiguratie. Daarom moet u deze opdracht alleen uitvoeren als u het niet-standaard planneralgoritme voor lage latentie wachttijden wijzigt. Zie het gedeelte Low Latency Queueing voor meer informatie.

Toegangsbeheer

Een groot voordeel van de met DOCSIS conforme planner is dat deze planner ervoor zorgt dat de UGS-servicestromen niet hoger zijn dan de upstream. Indien een nieuwe UGS-dienstenstroom moet worden vastgesteld en de planner ontdekt dat een vooraf vastgesteld subsidieschema niet mogelijk is omdat er geen ruimte meer over is, wijst de CMTS de nieuwe UGS-dienstenstroom af. Als de UGS-servicestromen die VoIP-verkeer transporteren, een upstream-kanaal mogen overschrijven, gaat de kwaliteit van alle VoIP-oproepen ernstig achteruit.

Om aan te tonen hoe de met DOCSIS conforme planner waarborgt dat de UGS-servicestromen nooit de upstream overschrijden, raadpleegt u de cijfers in dit gedeelte. De cijfers 7, 8 en 9 tonen de tijdlijnen voor de toewijzing van bandbreedte.

In al deze cijfers geven de gekleurde delen de tijd weer waarop kabelmodems subsidies ontvangen voor hun UGS-dienstenstromen. Er kunnen tijdens die periode geen andere upstream transmissies van andere kabelmodems optreden. Het grijze deel van de tijdlijn is nog niet toegewezen bandbreedte. Kabelmodems gebruiken deze keer om bandbreedteverzoeken te verzenden. CMTS kan deze tijd later gebruiken om andere soorten services te plannen.

Afbeelding 7 - vooraf schema’s voor DOCSIS-conforme planning voor drie UGS-servicestromen

Voeg nog twee UGS-dienstenstromen toe van dezelfde subsidieomvang en met dezelfde subsidieinterval. Toch heeft de planner geen problemen met het vooraf plannen.

Afbeelding 8 - DOCSIS-conforme planning voor planning van vijf UGS-servicestromen

Als u twee UGS-servicestromen toevoegt, vult u alle beschikbare upstream-bandbreedte in.

Afbeelding 9 - UGS-servicestromen gebruiken alle beschikbare uploadbreedte

De planner kan hier geen verdere UGS-servicestromen toegeven. Als een andere UGS-servicestroom actief probeert te worden, realiseert de met DOCSIS conforme planner zich dan dat er geen ruimte is voor verdere subsidies, en voorkomt het instellen van die servicestroom.

Toelichting: Het is niet mogelijk om een upstream met UGS-dienstenstromen op te vullen, zoals in deze reeks cijfers wordt getoond. De planner moet andere belangrijke types van verkeer omvatten, bijvoorbeeld, de handhaving van het stationsonderhoud en het best mogelijke verkeer van inspanningsgegevens. Bovendien is de garantie om overabonnement met de met DOCSIS compatibele planner te voorkomen alleen van toepassing als alle servicestroom planningsmodi, namelijk UGS, RTPS en nRTPS, de met DOCSIS compatibele planner gebruiken.

Hoewel de expliciete configuratie van de toegangscontrole niet nodig is wanneer u de met DOCSIS conforme planner gebruikt, raadt Cisco u aan ervoor te zorgen dat het stroomopwaarts kanaalgebruik niet toeneemt tot niveaus die het beste inspanningsverkeer negatief kunnen beïnvloeden. Cisco raadt ook aan dat het totale upstream-kanaalgebruik niet meer dan 75% mag bedragen voor aanzienlijke hoeveelheden tijd. Dit is het niveau van upstream-benutting waarbij de beste inspanningsservices veel hogere latentie en langzamere doorvoersnelheid beginnen te ervaren. UGS-diensten werken nog steeds, ongeacht de upstreambenutting.

Indien u de hoeveelheid verkeer die in een bepaalde upstream is opgenomen, wilt beperken, dient u de toegangscontrole voor UGS, RTPS, NRTPS, UGS-AD of best-inspanningsverkeer te configureren met de mondiale, per kabelinterface of per upstream-opdracht. De belangrijkste parameter is het exclusieve drempelprocent veld.

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]

Hier zijn de parameters:

• [upstream <upstream-nummer>]: Specificeer deze parameter als u de opdracht wilt toepassen op een bepaalde upstream in plaats van een kabelinterface of mondiaal.

• <UGS|AD-UGS|RTPS|NRTPS|BE>: Deze parameter specificeert de dienstregelingsmodus waarvoor u toegangscontrole wilt toepassen.

• <miniem-drempelpercentage>: Deze parameter geeft het percentage van upstreamgebruik aan door het geconfigureerde planningtype waarbij een minimaal alarm naar een netwerkbeheerstation wordt verzonden.

• <belangrijk drempelpercentage>: Deze parameter specificeert het percentage upstream gebruik door het geconfigureerde planningtype waarbij een groot alarm naar een netwerkbeheerstation wordt verzonden. Deze waarde moet hoger zijn dan de waarde die u hebt ingesteld voor de <small-drempelwaarde-percent> parameter.

• <exclusieve drempelwaarde>: Deze parameter vertegenwoordigt het percentage upstreamgebruik dat uitsluitend is gereserveerd voor het gespecificeerde planningstype. Als u de waarde voor <niet-behalve-drempelwaarde-percentage> niet specificeert, vertegenwoordigt deze waarde de maximale limiet op het gebruik voor dit type servicestroom. Deze waarde moet groter zijn dan de waarde van <major-threshold-percent>.

• <zonder drempelwaarde>: Deze parameter vertegenwoordigt het percentage upstreamgebruik boven de <exclusieve drempelwaarde-procent> die dit planningtype kan gebruiken, zolang een ander planningtype het nog niet gebruikt.

Ga er bijvoorbeeld vanuit dat u de UGS-servicestromen wilt beperken tot 60% van de totale beschikbare upstream-bandbreedte. Ga er ook van uit dat u netwerkbeheerstations heeft laten weten dat als het percentage van de upstreambenutting als gevolg van de UGS-diensten meer dan 40% is gestegen, er een klein alarm moet worden gestuurd en meer dan 50%, een groot alarm moet worden gestuurd. Deze opdracht geven:

kabeltoelating-besturing us-bandbreedte-UGS-ondergeschikt 40 majoor 50 exclusieve 60

Scheduling van optimalisatieservice met fragmentatie

De met DOCSIS conforme planner organiseert eenvoudigweg de best mogelijke verkeer rond vooraf toegewezen UGS- of RTPS-subsidies. De cijfers in deze paragraaf tonen dit gedrag aan.

Afbeelding 10 - Eerdere inspanningssubsidies in afwachting van planning

Afbeelding 10 toont aan dat de upstream drie UGS-dienstenstromen heeft met dezelfde subsidieomvang en subsidieinterval van tevoren gepland. De upstream ontvangt bandbreedteverzoeken namens drie afzonderlijke dienstenstromen, A, B en C. Service flow A vraagt om een gemiddelde transmissietijd, dienstenstroom B vraagt om een kleine hoeveelheid transmissietijd en dienstenstroom C vraagt om een grote hoeveelheid transmissietijd.

Kies evenveel prioriteit als elk van de beste servicestromen. Ga er ook van uit dat CMTS de bandbreedte-verzoeken voor elk van deze subsidies ontvangt in volgorde A en vervolgens C. De CMTS verleent eerst transmissietijd voor de subsidies in dezelfde volgorde. Afbeelding 11 toont hoe de met DOCSIS conforme planner deze subsidies toewijzen.

Afbeelding 11 - Optimale prestatiekredieten gepland rond vaste UGS-subsidies voor servicesstromen

De planner kan de subsidies voor A en B samenpersen in de kloof tussen de eerste twee blokken van UGS-subsidies. De subsidie voor C is echter groter dan de beschikbare leemten. Daarom wordt de subsidie voor C rond het derde blok UGS-subsidies in twee kleinere subsidies, C1 en C2, gefragmenteerd. Fragmentation voorkomt vertragingen voor UGS-subsidies en zorgt ervoor dat deze subsidies niet onderworpen zijn aan jitter die de beste inspanning veroorzaakt.

Fragmentation verhoogt enigszins de DOCSIS-protocoloverhead bij gegevensoverdracht. Voor elk verzonden extra fragment moet ook een extra set DOCSIS-headers worden verzonden. Zonder fragmentatie kan de planner echter niet efficiënt de best-inspanningssubsidies tussen vaste UGS-subsidies onderbreken. Fragmentation kan niet voorkomen voor kabelmodems die in DOCSIS 1.0 modus werken.

Prioriteit

De met DOCSIS conforme planner plaatst subsidies die in afwachting zijn van toewijzing in een wachtrij die is gebaseerd op de prioriteit van de servicestroom waartoe de subsidie behoort. Er zijn acht DOCSIS-prioriteiten met 0% als laagste en 7% als hoogste. Elk van deze prioriteiten heeft een gekoppelde wachtrij.

De met DOCSIS conforme planner gebruikt een strikt prioriteitswachtrij-mechanisme om te bepalen wanneer subsidies van verschillende prioriteit toegewezen transmissietijd worden toegewezen. Met andere woorden: alle subsidies die opgeslagen worden in wachtrijen met hoge prioriteit moeten worden bediend voordat subsidies worden verstrekt in rijen met lagere prioriteit.

Ga er bijvoorbeeld van uit dat de met DOCSIS conforme planner vijf subsidies in een korte periode ontvangt in de volgorde A, B, C, D, E en F. De planner-rijen elk van de beurzen in de wachtrij die overeenkomt met de prioriteit van de dienstenstroom van de subsidie.

Afbeelding 12 - Subsidies met verschillende prioriteiten

De met DOCSIS conforme planner-planners leveren de best mogelijke inspanning op rond de vooraf geplande UGS-beurzen die in afbeelding 12 als gepatenteerde blokken verschijnen. De eerste actie die de met DOCSIS-conforme planner neemt, is het controleren van de prioriteitswachtrij. In dit geval heeft de eerste 7 wachtrij subsidies die klaar zijn om te plannen. De planner gaat verder en kent transmissietijd toe voor subsidies B en E. Aankondiging dat de subsidie van E fragmentatie behoeft, zodat de subsidie geen afbreuk doet aan de timing van de vooraf toegekende UGS-subsidies.

Afbeelding 13 - Prioriteit 7 voor planning

De planner zorgt ervoor dat alle prioriteit 7 subsidies transmissietijd ontvangen. Vervolgens controleert de planner de prioriteit 6 wachtrij. In dit geval is de prioriteit 6 rij leeg zodat de server naar de prioriteit 5 rij beweegt die subsidie C bevat.

Afbeelding 14 - Prioriteit 5 voor planning

De planner gaat dan op een zelfde manier door de lagere prioriteitsrijen verder tot alle rijen leeg zijn. Als er een groot aantal subsidies te plannen zijn, kunnen nieuwe bandbreedte-verzoeken de CMTS bereiken voordat de met DOCSIS conforme planner de toewijzing van transmissietijd aan alle hangende subsidies heeft voltooid. Veronderstel dat CMTS op dit punt in het voorbeeld een bandbreedteaanvraag G van prioriteit 6 ontvangt.

Afbeelding 15 - Er wordt een wachtrij voor een prioriteitsverlening 6

Hoewel de subsidies A, F en D langer wachten dan de nieuw in de wachtrij staande subsidie G, moet de met DOCSIS conforme planner de volgende transmissietijd aan G toewijzen omdat G de hogere prioriteit heeft. Dit betekent dat de volgende bandbreedte-toewijzingen van de DOCSIS-conforme planner G, A dan D zullen zijn (zie afbeelding 16).

Afbeelding 16 - Subsidies voor prioriteit 6 en 2 voor planning

De volgende subsidie die gepland moet worden is F, als u ervan uitgaat dat er ondertussen geen hogere prioriteit wordt verleend aan subsidies die in de wachtrij worden geplaatst.

De DOCSIS-conforme planner heeft nog twee wachtrijen die niet in de voorbeelden zijn genoemd. De eerste rij is de rij die wordt gebruikt om periodiek het onderhoud van het station te plannen en het verkeer te handhaven om kabelmodems online te houden. Deze rij wordt gebruikt om kansen voor kabelmodems te plannen om het CMTS periodiek bewaard levend verkeer te verzenden. Wanneer de DOCSIS-conforme planner actief is, wordt deze wachtrij eerst voor alle andere wachtrijen geplaatst. Het tweede is een wachtrij voor subsidies die worden toegewezen aan dienstenstromen met een gespecificeerd minimumtarief (CIR). De planner behandelt deze CIR-wachtrij als een prioriteit 8-wachtrij om ervoor te zorgen dat de servicestromen met een gecommitteerd tarief de vereiste minimale doorvoersnelheid ontvangen.

Onfragmenteerbare DOCSIS 1.0-subsidies

Uit de voorbeelden in de voorgaande paragraaf blijkt dat subsidies soms in meerdere stukken moeten worden gesplitst om te voorkomen dat er een klacht wordt ingediend bij vooraf toegekende UGS-subsidies. Dit kan een probleem zijn voor kabelmodems die in DOCSIS 1.0-modus op upstream segmenten met een aanzienlijk aantal UGS-verkeer werken, omdat een DOCSIS 1.0-kabelmodem kan vragen een kader te verzenden dat te groot is om in de volgende beschikbare transmissiemogelijkheden te passen.

Hier is een ander voorbeeld, dat veronderstelt dat de planner nieuwe beurzen A en B in die volgorde ontvangt. Ga er ook van uit dat beide subsidies dezelfde prioriteit hebben maar dat subsidie B voor een kabelmodem is die in DOCSIS 1.0 modus werkt.

Afbeelding 17 - DOCSIS 1.1 en DOCSIS 1.0 in afwachting van subsidies

De planner probeert eerst tijd toe te wijzen voor subsidie A. Vervolgens probeert de planner de volgende beschikbare transmissiemogelijkheid toe te wijzen om B toe te kennen. Er is echter geen ruimte voor subsidie B om niet gefragmenteerd te blijven tussen A en het volgende blok UGS-subsidies (zie figuur 18).

Afbeelding 18 - DOCSIS 1.0 Grant B geblokkeerd

Daarom wordt subsidie B uitgesteld tot na het tweede blok van de UGS-subsidies, wanneer er ruimte is voor subsidie B. Merk op dat er nu ongebruikte ruimte is voordat het tweede blok met UGS-subsidies begint. Kabelmodems gebruiken deze keer om bandbreedteverzoeken naar de CMTS te verzenden, maar dit vertegenwoordigt een inefficiënt gebruik van bandbreedte.

Herzie dit voorbeeld en voeg een extra twee UGS de dienststromen aan de planner toe. Hoewel subsidie A kan worden gefragmenteerd, is er geen mogelijkheid voor de niet-gefragmenteerde subsidie B te voorzien, omdat subsidie B te groot is om te passen tussen blokken van UGS-subsidies. Deze situatie laat de kabelmodem geassocieerd met subsidie B niet toe om grote frames in de upstream over te brengen.

Afbeelding 19 - DOCSIS 1.0 Grant B kan niet worden gepland

U kunt de planner toestaan om een blok UGS-beurzen simpelweg te duwen of iets uit te stellen om ruimte te maken voor subsidie B, maar deze actie veroorzaakt jitter in de UGS-dienstenstroom. Als u nu veronderstelt dat u de jitter tot een minimum wilt beperken, is dat een onaanvaardbare oplossing.

Om deze kwestie met grote niet-fragmenteerbare DOCSIS 1.0-beurzen te overwinnen, vooraf geplande DOCSIS-conforme planner regelmatig blokken van upstream tijd zo groot als het grootste frame dat een DOCSIS 1.0-kabelmodem kan verzenden. De planner doet dit voordat er UGS-servicestromen gepland zijn. Deze keer is doorgaans het equivalent van ongeveer 2000 bytes van upstream transmissie, en wordt het "Unfragmentable Block" (het niet-gefragmenteerde blok) of het "UGS free blok" genoemd.

De met DOCSIS conforme planner verleent geen UGS- of RTPS-subsidies in de aan onfragmenteerbaar verkeer toegewezen tijden, zodat er altijd een mogelijkheid is om grote DOCSIS 1.0-beurzen te plannen. In dit systeem beperkt de reservering van tijd voor niet-fragmenteerbaar DOCSIS 1.0-verkeer het aantal UGS-servicestromen dat de upstream tegelijkertijd kan ondersteunen.

Afbeelding 20 toont het niet-verbrokkelbare blok in de blauwe en vier UGS-dienstenstromen met dezelfde subsidieomvang en subsidieinterval. U kunt geen andere UGS-servicestroom van dezelfde subsidieomvang toevoegen en deze upstream toekennen, omdat UGS-subsidies niet mogen worden opgenomen in het blauwe, onfragmenteerbare blok-gebied.

Afbeelding 20 - Het niet-fragmenteerbare blok: Er kunnen geen verdere UGS-subsidies worden toegestaan

Hoewel het niet-fragmenteerbare blok minder vaak is gepland dan de periode van de UGS-subsidies, heeft dit blok de neiging tussen alle blokken van UGS-subsidies een ruimte van niet-toegewezen bandbreedte te creëren die even groot is als zelf. Dit biedt ruime mogelijkheden om grote niet-fragmenteerbare subsidies te organiseren.

Terugkomend op het voorbeeld van subsidie A en DOCSIS 1.0 Grant B, kunt u zien dat met het niet-fragmenteerbare blok op zijn plaats de met DOCSIS conforme planner nu met succes subsidie B kan plannen na het eerste blok van UGS-subsidies.

Afbeelding 21 - Vereveningssubsidies met het gebruik van het niet-fragmenteerbare blok

Hoewel subsidie B van DOCSIS 1.0 volgens de planning succesvol is, is er nog steeds een klein gat in ongebruikte ruimte tussen subsidie A en het eerste blok UGS-subsidies. Dit gat vertegenwoordigt een suboptimaal gebruik van bandbreedte en demonstreert waarom u DOCSIS 1.1 mode kabelmodems moet gebruiken wanneer u UGS services implementeert.

Standaard kabeluitbarsting

Standaard op een Cisco uBR CMTS is de grootste uitbarsting die een kabelmodem kan verzenden 2000 bytes. Deze waarde voor de grootste upstream burst-grootte wordt gebruikt om de grootte van het niet-gefragmenteerde blok te berekenen als de DOCSIS-conforme planner gebruikt.

U kunt de grootste barstgrootte wijzigen met de kabel default-phy-burst max-bytes-Enabled-in-burst per kabelinterfaceopdracht.

De <max-bytes-Enabled-in-burst> parameter heeft een bereik van 0 tot 4096 bytes en een standaardwaarde van 2000 bytes. Er zijn een aantal belangrijke beperkingen op de manier waarop u deze waarde moet instellen als u de waarde wilt wijzigen vanuit de standaardwaarde.

Voor kabelinterfaces op de MC5x20S lijnkaart, stelt u deze parameter niet boven de standaard 2000 bytes in. Voor alle andere lijnkaarttypen, inclusief de MC28U, MC5x20U en MC5x20H lijnkaarten, kunt u deze parameter instellen op maximaal 4000 bytes.

Stel de <max-bytes-Enabled-in-burst>-parameter niet lager in dan de grootte van het grootste Ethernet-frame dat een kabelmodem moet verzenden, inclusief DOCSIS of 802.1q overhead. Dit betekent dat deze waarde niet lager moet zijn dan ongeveer 1540 bytes.

Als u <max-bytes-Enabled-in-burst> op de speciale waarde van 0 instelt, gebruikt CMTS deze parameter niet om de grootte van een upstream breuk te beperken. U dient andere variabelen te configureren om de upstream-barstgrootte te beperken tot een redelijke limiet, zoals de maximale aaneengeschakelde burst instelling in het DOCSIS-configuratiebestand of de kabel upstream fragment-force opdracht.

Wanneer u de standaardinstelling van de kabel verandert-of uitbarsting-om de maximale stroomopwaartse rand te wijzigen, wordt de grootte van het UGS-vrije blok eveneens dienovereenkomstig aangepast. Afbeelding 22 toont aan dat als u de standaardinstelling van de kabel-om-burst-instelling vermindert, de grootte van het UGS-vrije blok vermindert en als gevolg daarvan de met DOCSIS conforme planner meer UGS-aanroepen op een upstream kan toestaan. In dit voorbeeld, verminder de kabel default-phy-burst van de standaardinstelling van 2000 tot een lagere instelling van 1600 om plaats voor nog een UGS servicestroom in werking te laten treden.

Afbeelding 22 - Verminderd aantal standaardinstellingen-bursten vermindert de niet-fragmenteerbare blokgrootte

Verlaging van de maximaal toegestane barstgrootte met de kabel default-phy-burst opdracht kan de efficiëntie van de upstream voor het best mogelijke verkeer enigszins verminderen, omdat deze opdracht het aantal frames vermindert dat binnen één barst kan worden aaneengezet. Een dergelijke vermindering kan ook leiden tot een grotere fragmentatie wanneer de upstream een groter aantal actieve UGS-dienstenstromen heeft.

Verminderde aaneengesloten burstgrootte kan de snelheid van het uploaden van gegevens in een best mogelijke servicestroom beïnvloeden. Dit komt doordat transmissie van meerdere frames tegelijkertijd sneller is dan transmissie van een bandbreedteaanvraag voor elk frame. Verminderde aaneenschakelingsniveaus kunnen de snelheid van downloads ook potentieel beïnvloeden door een verminderde capaciteit van de kabelmodem om grote aantallen TCP ACK pakketten aan te sluiten die in de upstream richting reizen.

Soms kan de maximale uitbarstgrootte zoals ingesteld in de "lange" IOC van het kabelmodulatieprofiel toegepast op een stroomopwaarts gelegen, de grootste uitbarstgrootte bepalen. Dit kan voorkomen als de maximale uitbarstgrootte in het modulatieprofiel minder is dan de waarde van de kabel default-phy-burst in bytes. Dit is een zeldzaam scenario. Als u echter de kabel default-phy-burst parameter van het standaard 2000 bytes verhoogt, controleert u de maximale barstgrootte in de configuratie van de "long" IUC om er zeker van te zijn dat de barsten niet worden beperkt.

De andere beperking tot de upstream-barstgrootte is dat een maximum van 255 minuten kan worden doorgegeven in één keer. Dit kan een factor worden als de grootte van het minisleuf is ingesteld op het minimum van 8 bytes. Een minislot is de kleinste eenheid van upstream transmissie in een DOCSIS-netwerk en is meestal gelijk aan 8 of 16 bytes.

Stapelbalk

Een andere manier om de met DOCSIS conforme planner aan te passen om een hoger aantal gelijktijdige UGS-stromen in een upstream toe te staan, is de planner toe te staan grote uitbarstingen van onfragmenteerbaar best-verkeer kleine hoeveelheden jitter aan UGS-servicestromen te laten introduceren. U kunt dit doen met de interfaceopdracht voor unfrag-sleuf-jitter van de kabel.

In deze opdracht wordt <val> gespecificeerd in microseconden en heeft een standaardwaarde van nul, wat betekent dat het standaardgedrag voor de met DOCSIS conforme planner is om niet-fragmenteerbare subsidies toe te staan om jitter te veroorzaken voor UGS en RTPS-servicestromen. Wanneer een positieve, niet-fragmenteerbare slots is gespecificeerd, kan de met DOCSIS conforme planner UGS-subsidies tot <val> microseconden uitstellen vanaf het moment dat de UGS-subsidie idealiter in een planning moet worden geplaatst, om zo jitter te veroorzaken.

Dit heeft hetzelfde effect als de vermindering van de niet-fragmenteerbare blokgrootte met een lengte die gelijk is aan het aantal microseconden dat is opgegeven. Als u bijvoorbeeld de standaardwaarde voor default-phy-burst (2000 bytes) handhaaft en als u een waarde van 1000 microseconden specificeert voor een niet-fragmenteerbare sleuf, dan vermindert het niet-fragmenteerbare blok (zie Afbeelding 23).

Afbeelding 23 - Niet-gefragmenteerde splitsbare sleuf voor niet-gefragmenteerde sleuven voor het niet-gefragmenteerde blokformaat

Opmerking: Het aantal bytes waarop de 1000-microseconde-tijd overeenkomt, is afhankelijk van hoe snel het upstream-kanaal is geconfigureerd om te werken met de instellingen voor de kanaalbreedte en het modulatieschema.

Opmerking: Met een niet-nul onfragmenteerbare sleuf kan de met DOCSIS-compatibele planner het aantal UGS-beurzen verhogen dat een upstream op dezelfde manier ondersteunt als een lagere default-phy-burst.

Toelichting: Terug naar het voorbeeld met een grote subsidie A van DOCSIS 1.1 gevolgd door een grote niet-fragmenteerbare subsidie B van DOCSIS 1.0 om op een stroomopwaarts tijdstip te plannen. U stelt de onfragmenteerbare sleuf-jitter in op 1000 microseconden. De DOCSIS-conforme planner gedraagt zich zoals in de cijfers in deze sectie wordt getoond.

Toelichting: Ten eerste kent de planner transmissietijd toe voor subsidie A. Hiervoor fragmenteert de planner de subsidie in de subsidies A₁ en A₂, zodat de subsidies voor en na het eerste blok van de UGS-subsidies passen. Om subsidie B te kunnen plannen, moet de planner beslissen of de planner de niet-fragmenteerbare blokkering in de vrije ruimte kan inpassen na A₂ zonder vertraging aan het volgende blok UGS-subsidies te verlenen met meer dan de geconfigureerde niet-fragmenteerbare sleuf van 1000 microseconden. Deze cijfers tonen aan dat als de planner-plekken B naast de A₂-lijn toekennen, het volgende blok UGS-verkeer met meer dan 1500 microseconden wordt uitgesteld of teruggeduwd. Daarom kan de planner geen subsidie B rechtstreeks na subsidie A₂ plaatsen.

Afbeelding 24 - Subsidie B kan niet worden gepland naast subsidie A2.

De volgende stap voor de met DOCSIS conforme planner is om te zien of de volgende beschikbare opening kan worden gebruikt voor subsidie B. Afbeelding 25 toont aan dat als de planner B verleent na het tweede blok van UGS-subsidies, het derde blok niet meer wordt vertraagd dan de geconfigureerde niet-fragmenteerbare sleuf van 1000 microseconden.

Afbeelding 25 - Subsidie B gepland na het tweede blok UGS-subsidies

Met de wetenschap dat de invoeging van subsidie B op dit punt geen onaanvaardbare reden voor UGS-subsidies oplevert, voert de met DOCSIS in overeenstemming zijnde planner subsidie B in en vertraagt zij enigszins het volgende gedeelte van UGS-subsidies.

Afbeelding 26 - Niet-gefragmenteerde subsidie B is gepland en UGS-subsidies worden uitgesteld

Opdracht uitvoer tonen

U kunt de opdracht van de interface-kabel-interface-nummer mac-server upstream-nummer gebruiken om de huidige status van de DOCSIS-conforme planner af te meten. Hier is een voorbeeld van de uitvoer van deze opdracht zoals gezien op een Cisco uBR7200VXR met een MC28U lijnkaart.

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

In deze sectie wordt elke regel van de uitvoer van deze opdracht uitgelegd. Merk op dat dit gedeelte van het document ervan uitgaat dat u al vrij vertrouwd bent met de algemene concepten voor DOCSIS-upstream.

• DOCSIS 1.1 MAC-server voor Cable3/0/U0

  De eerste regel van de opdrachtoutput geeft de upstream poort aan waarop de gegevens betrekking hebben.

• Wachtrij[Ring Polls] 0/128, 0 druppels, max. 1

  Deze lijn toont de staat van de rij die de handhaving van de stations of het oplopen van kansen in de met DOCSIS conforme planner voedt. 0/128 geeft aan dat er op dit moment 0 van de maximaal 128 in behandeling zijnde veelzijdige kansen in de wachtrij zijn.

  De druppelteller geeft het aantal keer aan dat een veelvoud aan kansen niet in de rij kon worden geplaatst omdat deze rij al vol was (dat wil zeggen, 128 hangende openingskansen). Deze vallen zouden waarschijnlijk alleen in een stroomopwaarts gelegen periode plaatsvinden met een extreem groot aantal kabelmodems online en indien er een groot aantal UGS- of RTPS-servicestromen actief waren. Deze wachtrij wordt met de hoogste prioriteit onderhouden wanneer de DOCSIS-klachtenplanner wordt uitgevoerd. Daarom is een daling in deze wachtrij zeer onwaarschijnlijk, maar waarschijnlijk duidt dit op een ernstige overtekening van het stroomopwaarts kanaal.

  De max teller geeft het maximale aantal elementen aan die aanwezig en in deze rij zijn sinds de opdracht Mac-planner van de showinterface kabel de laatste keer werd uitgevoerd. In het beste geval zou dit zo dicht mogelijk bij nul moeten blijven.

• Wachtrij[CIR-subsidies] 0/64, 0 druppels, max 0

  Deze lijn geeft de staat weer van de wachtrij die subsidies voor dienstenstromen beheert met een minimum gespecificeerd verkeerstarief. Met andere woorden, deze diensten in de rij verlenen subsidies voor toegezegde informatieruimte (CIR). 0/64 geeft aan dat er momenteel 0% van de 64 in behandeling zijnde subsidies in de wachtrij staat.

  De druppelteller geeft het aantal keer aan dat een CIR-subsidie niet in de wachtrij kon worden geplaatst omdat deze wachtrij al vol was (d.w.z. 64 beurzen in de wachtrij). In dit geval kunnen druppels zich ophopen als de UGS-, RTPS- en CIR-servicestromen de stroomopwaarts onderschrijven en de noodzaak van een striktere toegangscontrole aangeven.

  De max teller geeft het maximale aantal beurzen in deze rij aan sinds de opdracht voor de laatste run van de showinterface kabel-planner. Deze rij heeft de tweede hoogste prioriteit, zodat de met DOCSIS conforme planner tijd toewijst voor elementen van deze rij voordat de plannerdiensten de beste inspanningswachtrijen hebben.

• Wachtrij[subsidies] x/64, y drups, max z

  De volgende acht ingangen tonen de staat van de rijen die subsidies voor prioriteit 7 door 0 dienstenstromen beheren. De velden in deze ingangen hebben dezelfde betekenis als de velden in de CIR-wachtrij. De eerste rij die in deze groep moet worden bediend, is de BE (7) wachtrij en de laatste die moet worden bediend is de BE (0) wachtrij.

  In deze wachtrijen kunnen vallen als een hoger prioriteitsniveau van het verkeer alle upstreambandbreedte verbruikt of als er overabonnement van de upstream-servicestromen met UGS, RTPS en CIR-stijl optreedt. Dit kan erop wijzen dat de DOCSIS-prioriteiten voor grote dienstenstromen opnieuw moeten worden beoordeeld of dat er behoefte is aan een striktere toegangscontrole in de upstream.

• Req-sleuven 36356057

  Deze lijn geeft het aantal mogelijkheden voor bandbreedte aan die zijn geadverteerd sinds de upstream is geactiveerd. Dit aantal moet voortdurend toenemen.

• Req/gegevenssleuven 185165

  Hoewel de naam suggereert dat dit veld het aantal aanvragen of gegevensmogelijkheden toont dat op de upstream wordt bekendgemaakt, geeft dit veld het aantal perioden weer dat de CMTS adverteert om geavanceerde spectrumbeheerfuncties te vergemakkelijken. Deze teller zal naar verwachting toenemen voor upstreams op MC28U en MC520 lijnkaarten.

  De kansen van het verzoek/van de Gegevens zijn het zelfde als mogelijkheden van het bandbreedte verzoek behalve dat kabelmodems ook kleine bursten van gegevens in deze periodes kunnen verzenden. Cisco uBR Series CMTS's plannen momenteel geen echte aanvraag/gegevensmogelijkheden.

• Mint MTP-sleuven 514263

  Deze lijn geeft het aantal initiële onderhoudsmogelijkheden weer die zijn geadverteerd sinds de upstream is geactiveerd. Dit aantal moet voortdurend stijgen. Kabelmodems die een eerste poging doen om connectiviteit op CMTS te vestigen gebruiken aanvankelijke onderhoudsmogelijkheden.

• STN MTP-sleuven 314793

  Deze lijn geeft het aantal mogelijkheden aan om het onderhoud van het station in stand te houden of te variëren die in de stroomopwaarts worden aangeboden. Als er online kabelmodems in de upstream zijn, moet dit getal voortdurend verhoogd worden.

• Korte subsidiemarges 12256, Lange subsidiegeld 4691

  Deze lijn geeft het aantal in de upstream aangeboden gegevenssubsidies aan. Als er kabelmodems zijn die upstream gegevens verzenden, moeten deze getallen continu toenemen.

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

  Deze lijn vertegenwoordigt het aantal gegevensbeurzen die in advanced time Division Multiaccess mode (ATDMA) op de upstream worden aangeboden. Als er kabelmodems zijn die in DOCSIS 2.0 modus werken en ze upstream gegevens verzenden, moeten deze getallen voortdurend toenemen. Merk op dat ATDMA het UGS-verkeer afzonderlijk administratief verwerkt.

• AS-sleuven 27629

  Deze lijn toont het aantal perioden dat is gewijd aan het geavanceerde spectrumbeheer. Om een geavanceerd spectrumbeheer mogelijk te maken, moet de CMTS regelmatig de tijden plannen waarin elke kabelmodem een korte transmissie moet maken, zodat de interne spectrumanalysefunctie de signaalkwaliteit van elke modem kan evalueren.

• Fragmentation-telling 41

  Deze lijn toont het totale aantal fragmenten dat de upstream poort zal ontvangen. Een kader dat in drie delen was gefragmenteerd zou deze teller met drie delen veroorzaken.

• Fragmentatietest uitgeschakeld

  Deze lijn geeft aan dat de test kabel fragmentatie opdracht niet is aangehaald. Gebruik deze opdracht niet in een productienetwerk.

• Avg upstream kanaalgebruik: 26%

  Deze lijn toont het huidige stroomopwaarts kanaalgebruik door stroomopwaartse gegevenstransmissies. Dit omvat transmissies die worden verricht via korte, lange, ATDMA korte, ATDMA long- en ATDMA UGS-subsidies. De waarde wordt elke seconde berekend als voortschrijdend gemiddelde. Cisco raadt aan deze waarde tijdens piekgebruiksuren niet hoger te laten zijn dan 75% op een uitgebreide basis. Anders kunnen eindgebruikers prestatieproblemen beginnen op te merken met het best mogelijke verkeer.

• Vg procent van de slots: 73%

  Deze lijn toont het percentage stroomopwaartse tijd gewijd aan bandbreedteverzoeken. Dit komt overeen met de hoeveelheid vrije tijd in de stroomopwaarts, en vermindert derhalve, naarmate het percentage van de upstreamkanaalbenutting van Avg stijgt.

• Aanloopsnelheid: 2%

  Deze lijn geeft het percentage van upstream tijd aan die besteed wordt aan initiële veelzijdige kansen die kabelmodems gebruiken wanneer ze pogingen ondernemen om initiële connectiviteit met CMTS te vestigen. Deze waarde moet altijd een laag percentage van de totale benutting blijven.

• Avg procent minislot verloren op late MAP's: 0%

  Deze lijn geeft het percentage upstream-tijd aan dat niet was gepland omdat de CMTS geen MAP-bericht van bandbreedte-toewijzing naar kabelmodems in de tijd kon verzenden. Deze parameter moet altijd dicht bij nul zijn maar kan grotere waarden op systemen gaan tonen die een extreem hoge CPU-lading hebben.

• RSVV-staat schema: Subsidies 0, aanvragen 0

  Deze lijn toont het aantal UGS-servicestromen (subsidies) of RTPS-servicestromen (verzoeken) die vooraf zijn toegewezen aan de met DOCSIS-conformiteit, maar nog niet zijn geactiveerd. Dit gebeurt wanneer u een kabelmodemmodule met bestaande UGS- of RTPS-servicestromen van de ene upstream naar de andere verplaatst door middel van een taakverdeling. Merk op dat dit getal alleen van toepassing is op subsidies die de DOCSIS-conforme planner gebruiken, en niet de LLQ-planner.

• Tabeladm-state overgesteld: Subsidies 6, 0, tot 27%

  Deze lijn geeft het aantal UGS-stijl servicestromen (subsidies) of RTPS-stijl servicestromen (verzoeken) aan die vooraf zijn toegewezen aan de DOCSIS-conforme planner voor deze upstream. Tot op heden is het geschatte gebruik van de totale beschikbare upstream bandbreedte door deze servicestromen. Merk op dat dit getal alleen van toepassing is op subsidies die de DOCSIS-conforme planner gebruiken, en niet de LLQ-planner.

• <Scheduling>: x SID’s, reserveringsniveau in bps y

  Deze lijn geeft het aantal <Scheduling-type> servicestromen of SID’s aan die in de upstream aanwezig zijn, en de hoeveelheid bandbreedte in bits per seconde die deze servicestromen gereserveerd hebben. Voor de best mogelijke inspanning en de servicestromen van de RTPS-stijl, is de bandbreedte alleen gereserveerd als de servicestroom een minimum gereserveerde snelheid heeft ingesteld.

Voordelen en nadelen van de DOCSIS-conforme planner

Het doel van de met DOCSIS compatibele planner is de jitter voor UGS- en RTPS-servicestromen tot een minimum te beperken en ook onfragmenteerbare DOCSIS 1.0-bursten aan te brengen. De ruil die de met DOCSIS conforme planner maakt om deze doelstellingen te bereiken, is dat het maximale aantal UGS-servicestromen dat per upstream wordt ondersteund, kleiner is dan het theoretische maximum dat een DOCSIS upstream fysiek kan ondersteunen, en dat het beste inspanningsverkeer onderhevig kan zijn aan een mate van fragmentatie.

Terwijl de met DOCSIS conforme planner iets minder dan het theoretische maximum aantal gelijktijdige UGS-servicestromen op een upstream ondersteunt en terwijl sommige andere planningsimplementaties meer UGS-servicestromen per upstream kunnen ondersteunen, moet u zich op de trade-off concentreren.

Geen enkele planner kan bijvoorbeeld itterless UGS-servicestromen ondersteunen die dicht bij 100% bandbreedte van een upstream-kanaal consumeren en tegelijkertijd grote, niet-gefragmenteerde aangelegde frames vanuit DOCSIS 1.0-modems ondersteunen. Met betrekking tot het ontwerp van de met DOCSIS conforme planner zijn twee belangrijke punten te begrijpen.

• 75 % is de maximaal gewenste opstroombenutting .

  Cisco heeft ontdekt dat wanneer een upstream consequent draait op meer dan 75% gebruik, inclusief gebruik als gevolg van UGS-servicestromen, de beste prestaties van het inspanningsverkeer merkbaar worden beïnvloed. Dit betekent dat als UGS en VoIP-signalering meer dan 75% van de stroomopwaarts verbruiken, elk normaal IP-verkeer dat via de best-inspanning servicestromen wordt vervoerd, te lijden heeft onder extra vertraging waardoor de doorvoersnelheid en de responstijd aanzienlijk lager zijn. Deze verslechtering van de prestaties op hogere gebruiksniveaus is een eigenschap die de meeste moderne multi-access netwerksystemen delen, bijvoorbeeld, Ethernet of draadloze LAN’s.

• Wanneer de doorgaans upstreamkanaalbreedte van 3,2 MHz wordt gebruikt, kan de met DOCSIS-compatibele planner UGS-servicestromen gebruiken tot ongeveer 75% van het upstream-kanaal. Deze servicestromen geven G.711 VoIP-oproepen over.

Deze twee punten geven inzicht in de ontwerpoverwegingen waarmee rekening werd gehouden toen de met DOCSIS conforme planner werd gebouwd. De DOCSIS-conforme planner is zodanig ontworpen dat voor typische UGS-servicestromen (G.711) en met de meest gebruikte kanaalbreedte van 3,2 MHz, de oproep per upstream-beperkingen van toepassing worden op ongeveer 75% van het gebruiksteken. Dit betekent dat de planner met succes jitter minimaliseert en ook een redelijk aantal UGS-servicestromen in de upstream toestaat.

Met andere woorden: de met DOCSIS compatibele planner is ontworpen om correct te functioneren in DOCSIS-productienetwerken en niet om UGS-servicestromen te laten gebruiken tot een onrealistisch hoog percentage van de upstreambandbreedte. Dit scenario kan zich voordoen bij een gecontroleerd testscenario.

U kunt de met DOCSIS compatibele planner aanpassen om een groter aantal UGS-oproepen per upstream te ontvangen, hoewel dit ten koste gaat van UGS-jitter en de efficiëntie van het inspanningsverkeer. Hiervoor moet u de default-phy-burst parameter beperken tot de minimum aanbevolen instelling van 1540 bytes. Als u verdere aanroep dichtheid nodig hebt, stel de kabel upstream unfrag-sleuf-jitter dan in op een waarde zoals 2000 microseconden. Maar Cisco adviseert deze instellingen niet over het algemeen voor een productienetwerk.

Een ander voordeel van de met DOCSIS conforme planner is dat er geen verplichting bestaat dat CMTS-exploitanten de toegangscontrole voor UGS- en RTPS-dienstenstromen expliciet configureren. Dit komt doordat de planningsmethode van vóór de toewijzing de mogelijkheid van een accidentele overinschrijving elimineert. Hoewel dit het geval is, suggereert Cisco nog steeds dat de exploitanten ervoor zorgen dat de totale upstream-benutting niet meer dan 75% bedraagt voor langere perioden tijdens het piekuur. Daarom adviseert Cisco de configuratie van toegangscontrole als beste praktijk.

Een nadeel van de met DOCSIS conforme planner is dat de vaste positie van UGS-subsidies kan vereisen dat de best mogelijke inspanningssubsidies worden gefragmenteerd wanneer het gebruik van UGS hoog is. In het algemeen veroorzaakt fragmentatie geen merkbare prestatiesproblemen, maar leidt het tot een lichte toename van de latentie voor het inspanningsverkeer en een toename van de overheadkosten van het protocol op het stroomopwaarts kanaal.

Een ander nadeel is dat wanneer DOCSIS 1.0-kabelmodems grote, niet-fragmenteerbare upstreamtransmissies willen maken, er een vertraging kan zijn voordat een passende kloof tussen blokken van vooraf geplande UGS-subsidies verschijnt. Dit kan ook leiden tot een grotere latentie voor het DOCSIS 1.0-upstreamverkeer en een minder dan optimaal gebruik van de beschikbare upstreamtransmissietijd.

Ten slotte is de met DOCSIS conforme planner ontworpen om het best te werken in omgevingen waar alle UGS-servicestromen dezelfde subsidieomvang en subsidieinterval delen. Dat wil zeggen, waar alle VoIP-oproepen dezelfde codec delen, zoals packetisering G.711 voor 10 of 20 ms, wat zich zou voordoen in een typisch Packetable 1.0-gebaseerd systeem. Wanneer er verschillende beursintervallen en -groottes aanwezig zijn, vermindert de capaciteit van de met DOCSIS conforme planner om een groot aantal UGS-servicestromen te ondersteunen, in een stroomopwaartse fase. Daarnaast kan voor sommige subsidies een zeer kleine hoeveelheid post (minder dan 2 ms) voorkomen, aangezien de planner probeert de UGS-dienstenstromen te onderbreken met verschillende periodes en afmetingen.

Aangezien PacketCable MultiMedia (PCM)-netwerken meer prevalent worden, kan dit gebruik vaker voorkomen voor een verscheidenheid aan VoIP-codecs met verschillende pakketreizen, zodat deze tegelijkertijd kunnen worden gebruikt. Dit type omgeving kan zich lenen aan de Low Latency Queueing-planner.

De Low Latency Queueing

De LLQ-planner (Low Latency Queueing) is geïntroduceerd in Cisco IOS-softwarerelease 12.3(13a)BC. LLQ is de alternatieve methode om de upstream services op een Cisco uBR CMTS te plannen. Deze planner was ontworpen om het aantal UGS - en RTPS - servicestromen te maximaliseren en de upstream kan gelijktijdig ondersteunen en tevens de efficiëntie van het inspanningsverkeer verbeteren in aanwezigheid van UGS - dienstenstromen. De overdracht is de planner van de LLQ die geen garanties biedt ten aanzien van de rechtvaardiging van de UGS- en RTPS-dienstenstromen.

Zoals het gedeelte DOCSIS-conform planner wordt besproken, kent de met DOCSIS conforme planner vooraf transmissietijd toe voor UGS- en RTPS-servicestromen. Dit is vergelijkbaar met de manier waarop een TDM-systeem (legacy time Division Multiplexing) bandbreedte toewijzen aan een service om bepaalde latentieniveaus te garanderen.

In moderne op pakketten gebaseerde netwerken is de lage latentie een methode die routers gebruiken om ervoor te zorgen dat pakketten die met hoge prioriteit worden geassocieerd, zoals spraak en video, in een netwerk vóór andere pakketten met lagere prioriteit kunnen worden geleverd. Dit is ook de methode die moderne routers gebruiken om te verzekeren dat latentie en scherpte voor belangrijk verkeer worden geminimaliseerd.

Het gebruik van het woord "garantie" voor het op TDM gebaseerde systeem en "geminimaliseerd" voor het op LLQ gebaseerde systeem in relatie tot jitter en latentie. Hoewel een garantie voor nullatentie en jitter wenselijk is, is de ruil daarvoor dat een dergelijk systeem gewoonlijk niet flexibel is, moeilijk te hervormen is en over het algemeen niet gemakkelijk kan worden aangepast aan veranderingen in de netwerkomstandigheden.

Een systeem dat latentie en scherpte minimaliseert in plaats van een strikte garantie te bieden, kan flexibiliteit bieden om zichzelf voortdurend te optimaliseren in het licht van veranderingen in de netwerkomstandigheden. De planner van de lage latentie gedraagt zich op een zelfde manier als het op pakketrouter gebaseerde LLQ systeem. In plaats van een van te voren vastgesteld systeem voor de toewijzing van UGS-subsidies, voorziet dit systeem in de "zo spoedig mogelijk" van de subsidies op het punt waar deze moeten worden gepland.

De benadering die subsidies voor UGS-dienstenstromen toekent, moet zo snel mogelijk worden toegewezen, maar niet noodzakelijkerwijs met een optimale frequentie, dit systeem geeft strikte garanties voor een grotere UGS-capaciteit en minder fragmentatie van inspanningsgegevens.

Configuratie

Voor Cisco IOS-softwarereleases 12.3(13a)BC en later is de LLQ server één van twee alternatieve planneralgoritmen. U kunt LLQ voor één, alle of een aantal van deze planningsmodi inschakelen:

• UGS

• RTPS

• NRTPS

De LLQ server is standaard niet ingeschakeld. U moet de LLQ-server expliciet inschakelen voor de vereiste upstream planningstypen. Gebruik de kabel upstream upstream-poort met schema’s [NRTT’s] | RTT | ugs] mode llq kabelinterfaceopdracht.

In het algemeen kunt u de LLQ-planner voor alle vermelde planningsmodi inschakelen als dit de gewenste planningsmodus is. Hier is een voorbeeld van een situatie waarin u LLQ-planning voor slechts één type planningsmodus wilt inschakelen maar de DOCSIS-conforme planner voor anderen wilt behouden:

Voor RTPS geldt geen strikte voorwaarde voor RTPS - diensten, maar voor UGS - diensten. In dit geval kunt u de LLQ-server voor RTPS-servicestromen inschakelen en de DOCSIS-conforme planner voor UGS behouden.

LLQ Scheduling

De LLQ-planner werkt op dezelfde manier als de prioriteitswachtrij-functie van de DOCSIS-conforme planner met de toevoeging van een speciale LLQ-wachtrij, die voorrang heeft boven alle andere wachtrijen.

De LLQ server start een timer namens alle actieve UGS (en RTPS) servicestromen. De timer is ingesteld om één keer per "subsidieinterval" uit te gaan. Als de timer afloopt, wordt een UGS-subsidie in de LLQ-wachtrij geplaatst. Aangezien deze subsidie in de LLQ-wachtrij met topprioriteit wordt geplaatst, is de subsidie gepland op het volgende moment waarop er vrije ruimte is.

De diagrammen in deze paragraaf tonen een voorbeeld van een systeem met drie actieve UGS - dienstenstromen met dezelfde rentesubsidie. Afbeelding 27 toont de timers voor de UGS-servicestromen links met het label UGS-1 en UGS-3. De gele pijl reist met de klok mee. Wanneer de gele pijl naar boven wijst naar de rode stip, wordt een subsidie van de GS toegevoegd aan de LLQ Quwachtrij. U kunt ook de bekende acht prioriteitswachtrijen 0 tot 7 zien en een nieuwe LLQ-wachtrij die voorrang krijgt boven alle wachtrijen. Tot slot, rechts, is de tijdlijn van de toewijzing van bandbreedte die beschrijft hoe de subsidies op de upstream gepland zijn. Voor extra helderheid omvat de bandbreedteverdelingstijdlijn een "huidige tijd"wijzer. Deze wijzer beweegt vooruit langs de tijdlijn als het voorbeeld voortschrijdt.

Afbeelding 27 - Het systeem voor lage wachtrijen

De eerste gebeurtenis die voorkomt is dat de UGS-1 timer links bovenaan vervalt. Een corresponderende subsidie wordt in de LLQ-wachtrij geplaatst. Tegelijkertijd is een inspanningssubsidie, genaamd A, met prioriteit 2 in de wachtrij geplaatst.

Afbeelding 28 - De subsidie voor UGS-1 en de prioriteitssubsidie A worden in een wachtrij geplaatst

De planner van de LLQ wijst nu de zendtijd toe aan de in behandeling zijnde subsidies in de volgorde van prioriteit. De eerste subsidie voor het ontvangen van zendtijd is de subsidie voor UGS-1 die in de LLQ-wachtrij wacht. Geef het volgende.

Afbeelding 29 - Subsidie UGS-1 en Grant A worden toegewezen aan de transmissietijd

De volgende gebeurtenis is dat de UGS-2 timer verloopt en ervoor zorgt dat een subsidie voor de UGS-2 servicestroom in de LLQ-wachtrij wordt geplaatst. Tegelijkertijd wordt een prioriteit 0 subsidie B in de wachtrij geplaatst en wordt prioriteit 6 subsidie C in de wachtrij geplaatst.

Afbeelding 30 - UGS-2 timer vervalt. Subsidies B en C worden in een wachtrij geplaatst

De planner van de LLQ wijst wederom zendtijd toe in de volgorde van de subsidieprioriteit, wat betekent dat eerst de planner tijd toewijst aan de subsidie voor UGS-2, dan voor subsidie C en uiteindelijk voor subsidie B.

Afbeelding 31 - Subsidies UGS-2, C en B worden toegewezen voor de transmissietijd

Stel dat geen best inspanningssubsidie de planner een tijdje binnengaat. De UGS-timers verlopen elk een paar keer meer. U kunt nu het soort periode zien waarmee de planner subsidies toekent aan de UGS-servicestromen. Ze lijken regelmatig verdeeld te zijn. Ga ervan uit dat wanneer de subsidies op deze manier in relatie tot elkaar verschijnen op de tijdlijn van de bandbreedte toewijzing, zij geen significante jitter ervaren.

Afbeelding 32 - UGS-1, UGS-2 en UGS-3 ontvangen een aantal subsidies. Grant D wordt in een wachtrij geplaatst

Afbeelding 32 geeft de ideale positie aan voor de volgende UGS-2 subsidie. Indien UGS-2 de subsidie ter plaatse kan krijgen, zal UGS-2 geen enkel argument voor de subsidie krijgen. Merk op dat er nog tijd is voor de volgende UGS-2 subsidie in de wachtrij voor LLQ.

Afbeelding 32 geeft ook aan dat een zeer hoge prioriteit 0 subsidie D net in de prioriteitswachtrij 0 is opgenomen. De volgende actie die de LLQ-planner neemt is het plannen van de transmissietijd voor subsidie D.

Afbeelding 33 toont dit scenario. Bedenk de klok mee naar het punt waar de volgende subsidie voor UGS-2 in de wachtrij staat.

Afbeelding 33 - Grant D ontvangt transmissietijd. Subsidie voor UGS-2 wordt in een wachtrij geplaatst

Subsidie D lijkt te zijn voorzien op het tijdstip waarop de volgende UGS-2-subsidie op 0-post moet worden toegewezen. Nu is de vraag waarom de planner van LLQ toestaat dat subsidie D op dat moment wordt gepland en geen subsidie D uitstelt tot na de subsidie voor UGS-2 of waarom D niet gefragmenteerd is. Het antwoord is dat de LLQ-planner geen transmissietijd voorwijst voor UGS-dienstenstromen. Daarom is de planner van de LLQ niet van tevoren op de hoogte waar UGS-subsidies op de tijdlijn voor de toewijzing van bandbreedte zullen worden geplaatst. De LLQ-server weet niet van UGS-subsidies totdat deze in de LLQ-wachtrij staan. In dit voorbeeld is subsidie D al gepland op het moment dat UGS-2 in de wachtrij wordt geplaatst.

De planner van de LLQ organiseert de subsidie voor UGS-2 bij de volgende beschikbare gelegenheid, maar deze subsidie wordt enigszins vertraagd ten opzichte van de ideale positie, wat per definitie betekent dat deze specifieke subsidie enige twijfel oplevert.

Afbeelding 34 - Subsidie voor UGS-2 wordt verlengd en Experiences Jitter

Terwijl de met DOCSIS conforme planner deze jitter had kunnen vermijden, vermijdt de LLQ-planner een vertraging of fragmentatie van subsidie D ten koste van slechts een klein bedrag aan jitter. Een jitterbuffer op een VoIP-eindpunt kan deze jitter gemakkelijk compenseren.

De andere situatie waarin zich een klacht kan voordoen is wanneer de LLQ-timer voor meerdere dienstenstromen tegelijkertijd vervalt en de UGS-beurzen wachten op andere UGS-beurzen die in de LLQ-wachtrij in de wachtrij staan. De LLQ server is ontworpen om de kans op dit voorval te minimaliseren. De planner verspreidt automatisch de verlooptijden voor de servicestroom timers.

Volgens de DOCSIS-conforme planner heeft de LLQ-server nog twee wachtrijen die de voorbeelden niet vermelden. Hier zijn de rijen:

1. De eerste rij wordt gebruikt om periodiek het onderhoudsverkeer van het station te plannen om kabelmodems online te houden. Deze rij wordt vlak na de LLQ-wachtrij bediend.

2. Het tweede is een wachtrij voor subsidies die worden toegewezen aan dienstenstromen met een minimaal gereserveerd tarief (CIR-dienstenstromen). Deze CIR-wachtrij wordt behandeld als een "prioriteitswachtrij van 8" om ervoor te zorgen dat de dienstenstromen met een vastgelegd tarief hun vereiste minimumdoorvoersnelheid ontvangen.

Toegangsbeheer

In tegenstelling tot de met DOCSIS conforme planner gebruikt de LLQ-planner geen pre-planningssysteem dat een accidentele overabonnement op een upstream met UGS en RTPS-servicestromen stopt. Dit is waarom u de upstream toegangscontrole expliciet moet configureren op elke upstream die de LLQ server gebruikt. Deze configuratie zorgt ervoor dat de totale upstream bandbreedte van de UGS-servicestromen niet hoger is dan normaal.

Cisco suggereert over het algemeen dat u het gebruik van een stroomopwaarts kanaal niet toestaat om 75% voor uitgebreide periodes tijdens piekgebruiksperiodes te overschrijden. Als het UGS-verkeer bijvoorbeeld meer dan 75% van de upstream-bandbreedte consumeert, zullen de beste inspanningsgegevens te lijden hebben onder excessieve latentie en problemen met de doorvoerprestaties.

Als een CMTS-operator de negatieve gevolgen voor het inspanningsverkeer kan accepteren, kunt u de UGS-servicestromen meer dan 75% van de beschikbare upstream-bandbreedte laten consumeren. U moet echter ook rekening houden met de impact op Layer 2-beheerverkeer op het stroomopwaarts kanaal. U moet tijd toestaan voor de eerste en stationsonderhoudsberichtgeving (kabelmodemkeepalives). Als je hiermee geen rekening houdt en het UGS-verkeer bijna 100% van de bandbreedte consumeert, kunnen kabelmodems niet online komen of offline vallen.

Hier is een voorbeeldconfiguratie voor toegangscontrole. Dit voorbeeld beperkt de UGS-dienstenstromen op een bepaalde upstream tot 50% van de beschikbare bandbreedte van de upstream. Deze vorm van de opdracht geeft SNMP-trap ook door naar elke geconfigureerde netwerkbeheerstations, wanneer de kleine en grote drempels van 30% en 40% van het gebruik zijn bereikt. Deze opdracht is:

kabel upstream upstream-nummer access point-control UGS-type met grote bandbreedte-UGS-kleine 30 belangrijke 40 exclusieve 50

Zie het gedeelte Admission Control onder het gedeelte DOCSIS-compatibele Scheduler van dit document voor het configureren van de toegangscontrole.

Opdracht uitvoer tonen

Geef de opdracht toe van de interface-interface-number mac-server upstream-number om de huidige status van de LLQ-planner te meten.

Hier is een voorbeeld van de uitvoer van deze opdracht. De delen van de opdrachtoutput die anders zijn dan wanneer de DOCSIS-compatibele planner actief is, worden in vet tekst weergegeven:

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

Zie het gedeelte Uitvoer van opdracht voor een uitleg van de onbewerkte tekstregels in deze uitvoer voor DOCSIS-conforme planner.

Hier zijn de beschrijvingen voor de vet lijnen van de opdrachtoutput van de show:

• Wachtrij[LLQ-subsidies] 0/64, 0 druppels, max. 3

  Deze lijn toont de staat van de LLQ rij, die subsidies voor de types van de dienststroom beheert die in het lijnen upstream planningtype van de kabel worden gespecificeerd [NTP's | RTT | ugs] mode llq opdracht. 0/64 geeft aan dat er momenteel 0% van de 64 in behandeling zijnde subsidies in de wachtrij staat.

  De druppelteller geeft het aantal keer aan dat de planner geen UGS-subsidie of RTPS-enquête in de rij kon houden omdat deze wachtrij al vol was (met andere woorden wanneer 64 beurzen in de wachtrij staan). Als zich in deze rij druppels voordoen, is de meest waarschijnlijke verklaring dat de upstream wordt overtekend met de UGS- of RTPS-servicestromen en dat je een striktere toegangscontrole moet toepassen.

  De max teller geeft het maximale aantal beurzen aan die in deze rij zijn sinds de opdracht Mac-planner van de showinterface kabel de laatste keer werd uitgevoerd. Indien aanwezig heeft deze rij de hoogste prioriteit van alle opgegeven wachtrijen.

• r4k teken in 1ms 600000

  Dit veld vertegenwoordigt een interne tijdvariabele die de LLQ-server gebruikt om er zeker van te zijn dat subsidies met hoge precisie in de LLQ-wachtrij worden geplaatst.

• Totale geplande gebeurtenissen 5009

  Deze lijn geeft het aantal keer aan dat de LLQ server probeert een subsidie in de rij te stellen sinds de laatste keer dat de opdracht Mac-planner van de showinterface kabel voor deze upstream werd uitgevoerd. Deze teller wordt teruggesteld elke keer dat de show opdracht wordt uitgevoerd.

• Er was geen zoekopdracht nodig 5009

  Nadat de planner van de LLQ een subsidie wachtrij heeft geplaatst, probeert de planner van de LLQ om de service-flow-timer te resetten om zich voor te bereiden voor de volgende keer dat er een subsidie in de wachtrij wordt geplaatst. Als er geen problemen zijn met het opnieuw instellen van de timer, wordt deze teller steeds verhoogd. Deze teller moet idealiter dezelfde waarde hebben als de teller van de Totale planningsgebeurtenissen.

• Eerdere vermelding gratis 0, volgende vermelding gratis 0

  Geen van deze tellers neemt ooit toe in huidige releases van Cisco IOS-software. Deze tellers blijven altijd op nul staan.

• Kan niet plannen 0, herstel mislukt 0

  Deze lijn geeft het aantal keer aan dat de LLQ server niet in staat was om te regelen dat de subsidie-timer van een servicestroom goed werd ingesteld. Dit mag alleen gebeuren als de planner van de LLQ een extreem groot aantal subsidies met zeer lage subsidieintervallen verwerkt. Het is zeer onwaarschijnlijk dat deze tellers ooit zullen toenemen op een productienetwerk. Een toename van deze tellers kan erop wijzen dat UGS en RTPS-servicestromen meer bandbreedte verbruiken dan fysiek beschikbaar is in de upstream. In dit scenario moet je passende toegangscontrolemaatregelen uitvoeren.

• Cursietijd 1341 vermelding 61

  Deze lijn toont interne timers voor de server LLQ gemeten in milliseconden. Wanneer het hier vermelde "entry"-veld gelijk is aan het veld "Entry" dat is opgenomen in de statistieken per servicestroom, wordt een subsidie in de LLQ-wachtrij geplaatst.

Deze statistieken worden herhaald voor elke servicestroom die de LLQ-planner omgaat. In dit voorbeeld zijn er drie van dergelijke dienstenstromen.

• Punt 188, punt 13

  Als de waarde "Entry" gelijk is aan het veld "entry" in het vorige item, vervalt de timer voor deze servicestroom en gaat een subsidie naar de LLQ-wachtrij. Dit veld stelt elke keer dat de servicestroom een 'subsidie' in de wachtrij heeft, opnieuw in.

• SID: 416

  De SID’s (Service Identifier) voor de servicestroom waarvan de plannerprogramma’s van de LLQ worden toegekend.

• IUC: 5

  De intervalgebruikscode die in een MAP-bericht wordt geadverteerd voor subsidies die tot deze dienstenstroom behoren. Dit is bijna altijd 5 voor "Short data", 6 voor "Long Data" of 11 voor "Advanced PHY UGS" wanneer een UGS-stijl servicestroom in gebruik is. Voor RTPS stijl servicestroom is deze waarde altijd 1 voor "Aanvraag".

• grootte_ms: 17 size_byte: 232

  De omvang van de subsidie in minipercelen, gevolgd door de grootte van de subsidie in bytes. Een minislot is de kleinste eenheid van upstream transmissie in een DOCSIS-netwerk en is meestal gelijk aan 8 of 16 bytes.

• Frag: N

  Geeft aan of de subsidie verbroken is. Op dit moment wordt deze waarde altijd op N ingesteld.

• Invaal: 20

  De subsidie- of steminterval in milliseconden.

• type 8

  8 geeft aan dat deze servicestroom UGS is, 10 geeft RTPS aan en 11 geeft NRTPS aan.

• perfecte tijd ref 188

  Het ideale tijdstip waarop deze subsidie gepland moet zijn. Dit is gewoonlijk hetzelfde als "Ingang" bovenaan. Zo niet, dan is er een aanwijzing dat er in de aanloop naar het land een sterke overbelasting bestaat die een striktere toegangscontrole nodig heeft.

• scheefheid vanaf ref 0

  Het verschil tussen het tijdstip waarop deze subsidie is gepland en het tijdstip waarop de subsidie het meest ideaal moet zijn gepland. Dit is het verschil tussen "entry" en "perfect time ref". Daarom moet deze waarde normaal nul zijn.

• prioriteit 10

  In huidige releases van Cisco IOS-software wordt deze waarde altijd op 10 ingesteld maar in de toekomst kan variëren.

• positie 188 , bin 13

  Deze velden moeten gelijk zijn aan "Entry, Bin" bovenaan deze lijst.

Voordelen en nadelen van de LLQ Scheduler

Het doel van de LLQ-planner is de UGS- en RTPS-capaciteit voor stroomopwaartse kanalen te vergroten en de efficiëntie van het inspanningsverkeer te vergroten. De ruil die de LLQ-planner doet om deze doelstellingen te bereiken, is dat deze planner niet expliciet garanties geeft voor de UGS- en RTPS-servicedoorstroming. De LLQ-planner organiseert UGS-beurzen en RTPS-opiniepeilingen die zo dicht mogelijk bij de ideale tijd liggen, om de jitter tot een minimum te beperken.

De LLQ-planner is ook in staat om meerdere UGS-servicestromen beter te verwerken met verschillende beursinters en subsidieformaten dan de met DOCSIS-compatibele planner. Deze optie kan nuttig zijn in een PCMM-omgeving waar verschillende typen VoIP-oproepen en mogelijk andere toepassingen tegelijkertijd op één upstream-kanaal worden verzonden.

De LLQ-planner organiseert het best inspanningsverkeer efficiënter omdat de LLQ-planner de kans op fragmentatie van subsidies vermindert. Wanneer onfragmenteerbare DOCSIS 1.0-bursts gepland zijn, creëert de LLQ-server geen gaten in ongebruikte bandbreedte voor UGS-subsidies of RTPS-opiniepeilingen zoals de DOCSIS-conforme planner soms doet. Dit leidt tot een beter gebruik van de beschikbare upstreamtijd.

Hoewel de UGS-jitter over het algemeen hoger is wanneer u de LLQ-server gebruikt dan wanneer u de DOCSIS-conforme planner gebruikt, zijn in typische DOCSIS- of PacketCable-netwerken de LLQ-plannerniveaus binnen de capaciteit van de VoIP-buffertechnologie voor endpoints. Dit betekent dat er geen merkbare impact is op de VoIP-callkwaliteit wanneer u de LLQ-server in een correct ontworpen VoIP-netwerk gebruikt.

Je kunt jitter beperken die voortkomt uit grote stroomopwaarts uitbarstingen. Zorg er voor dat u de kabel default-phy-burst parameter vasthoudt aan de standaardwaarde van 2000 bytes of minder. Als een systeem een bijzonder langzaam stroomopwaarts kanaal gebruikt, bijvoorbeeld met een 800 kHz of een kleinere kanaalbreedte, kunt u verdere reducties in scherven bereiken als u grote bursten in kleinere buren wilt splitsen met de opdracht upstream van de kabel.

Wanneer de LLQ server in gebruik is, moet u kabeltoegangscontrole configureren om overabonnement op het upstream kanaal te voorkomen. De actievere UGS-dienstenstromen dan de upstream fysiek kan worden afgehandeld, leiden tot een slechte spraakkwaliteit in alle UGS-servicestromen in de stroomopwaartse richting. In extreme gevallen betekent dit ook dat kabelmodems offline vallen en dat nieuwe kabelmodems niet online kunnen komen. Cisco beveelt aan dat CMTS-exploitanten de toegangscontrole zodanig configureren dat het totale upstreamgebruik op een upstreamhaven niet voor langere perioden boven de 75% ligt.

Conclusies

De Cisco uBR-serie van DOCSIS CMTS-producten biedt twee alternatieve upstream planningsalgoritmen, en kan dus voorzien in een verscheidenheid aan netwerkvoorwaarden.

De DOCSIS-conforme planner, die voor een lage jitter is geoptimaliseerd, is het meest geschikt voor typische PacketCable 1.x-spraaksystemen met een uniforme VoIP-codec en op de plaats waar de standaard niveaus van upstreamkanaalgebruik door UGS-servicestromen zijn gewenst.

De Low Latency Queueing-planner is ontworpen voor ondersteuning van hogere dan normale niveaus van upstreamgebruik door UGS-servicestromen, een verhoogde efficiëntie van het inspanningsverkeer en systemen die UGS- en RTPS-servicestromen met verschillende beursinters en subsidiegroottes gebruiken.

Bijlage A: Minislot

Een minislot is de kleinste transmissieeenheid in de DOCSIS stroomopwaarts. Wanneer een kabelmodemmodule een bandbreedte-verzoek aan CMTS doorgeeft om upstream transmissietijd te vragen, vraagt de modem in eenheden van minuten in plaats van in bytes of milliseconden. Daarnaast bevat het bericht, wanneer een MAP-bericht van de bandbreedtetoewijzing de modems informeert over wanneer ze kunnen verzenden en hoe lang, de informatie in eenheden van minuten.

Het maximale aantal minislots dat een modem kan vragen om in één inbraak te verzenden is 255. De grootte van de minisleuf wordt gespecificeerd in eenheden die DOCSIS ticks worden genoemd. Een DOCSIS-toets is gelijk aan 6,25 microseconden in de tijd.

Als u de grootte van de minisleuf in teken voor een upstream poort wilt instellen, geeft u de kabel upstream <upstream-nummer> minislot-grootte [1] uit | 2 | 4 | 8 | 16 | 32 | 64 | 128] kabelinterfaceopdracht.

Met bepaalde stroomopwaarts gerichte kanaalbreedten is alleen de grootte van de miniatuur toegestaan. Deze tabel toont geldige minisleuven versus DOCSIS upstream kanaalbreedten, en geeft ook de lengte weer in modulatieregeling symbolen van een minisleuf met geldige instellingen.

Opmerking: Een X-teken geeft een ongeldige combinatie aan.

	Kanaalbreedte	200 kHz	400 kHz	800 kHz	1,6 MHz	3,2 MHz	6,4 MHz
Grootte minislot in teken
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

Om het aantal bytes te berekenen die per minislot worden verzonden, vermenigvuldigt u de symbolen per minislot met het aantal bits per symbool voor het geconfigureerde modulatieschema. Verschillende modulatieregelingen verzenden verschillende aantallen bits per symbool zoals in deze tabel wordt getoond:

DOCSIS 1.1 TDMA-modulatiesystemen	its per symbool
QPSK	2
16-QAM	4

DOCSIS 2.0 ATDMA-modulatiesystemen	its per symbool
met 8 QAM	3
32-QAM	5
64-QAM	6

Met een kanaalbreedte van 1,6 MHz en een grootte van 4 teken in de miniatuur kunt u de eerste tabel bijvoorbeeld gebruiken om aan te komen op een getal van 32 symbolen per minislot. Gebruik de tweede tabel om dit getal naar bytes te converteren, omdat een QPSK-symbool 2 bits bevat. Eén minislot in dit voorbeeld is gelijk aan 32 symbolen per minislot * 2 bits per symbool = 64 bits per minislot = 8 bytes per minislot.

Vergeet niet dat het maximale aantal minislot dat een kabelmodem kan aanvragen om te verzenden 255 is. Daarom is in dit voorbeeld upstream de grootste uitbarsting in bytes die een modem kan maken 255 minuten * 8 bytes per minislot = 2040 bytes.

Merk op dat dit getal in bytes de post-forward error correctie is en het post fysieke laag overhead getal. Fout bij correctie en andere overhead van de DOCSIS PHY-laag voegt ongeveer 10 tot 20% toe aan de lengte van een Ethernet-kader wanneer deze door het upstream-kanaal passeert. Om het precieze cijfer af te leiden gebruikt u het modulatieprofiel dat op de upstreampoort wordt toegepast.

Deze discussie is belangrijk omdat een eerder gedeelte van dit document aangeeft dat een van de limieten op de maximale barstgrootte van een kabelmodemmodule de waarde is die is ingesteld in de opdracht Default-phy-burst. Als de kabel default-phy-burst opdracht is ingesteld op 4000 bytes in de context van dit voorbeeld, is de beperkende factor of de burst size de 255 minislot limiet (2040 bytes minus overhead) in plaats van de kabel default-phy-burst waarde.

U kunt verschillende expressies van de grootte van de minisleuf voor een upstream waarnemen met de opdracht voor controller-interface-nummer stroomopwaarts en getallen. Hierna volgt een voorbeeld:

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 raadt u aan de grootte van de minisleuf zodanig in te stellen dat een minisleuf gelijk is aan 16 bytes of de laatst toegestane waarde. Een kleine grootte van 16 bytes geeft kabelmodems de mogelijkheid om een post FEC burst van maximaal 255 * 16 = 4096 bytes te genereren.

Bijlage B: MAP-voorsprong

CMTS genereert periodiek een speciaal bericht dat een bandbreedte toewijzing-MAP wordt genoemd dat kabelmodems van een precies tijdstip informeert wanneer modems transmissies op het upstream kanaal kunnen maken. De elektrische signalen die het MAP-bericht verzenden nemen een eindige tijd om zich fysiek door het HFC-netwerk (hybride glasvezel coax) te verspreiden van CMTS naar alle aangesloten kabelmodems. Daarom moet het MAP-bericht zo snel mogelijk worden verzonden dat de modems het bericht kunnen ontvangen en de upstream-transmissie kunnen uitvoeren, zodat ze de CMTS op het aangewezen tijdstip bereiken.

De MAP vooruitlooptijd of de MAP vooruitziende tijd vertegenwoordigt het verschil tussen het tijdstip waarop de CMTS het MAP-bericht genereert en het tijdstip waarop de eerste door de MAP bestelde transmissie door de CMTS moet worden ontvangen. Deze keer is een combinatie van deze vertragingen in een DOCSIS-systeem:

• De tijd die de CMTS nodig heeft om het MAP-bericht in software te construeren en om het bericht in de wachtrij te plaatsen voor en te verwerken door het downstreamtransmissiecircuit. De waarde van deze component is specifiek voor verschillende platforms en architecturen en is in het algemeen een vaste waarde.

• De latentie die de downstreaminterleaving-functie toevoegt, die wordt gebruikt om fouten vooruit te corrigeren om te beschermen tegen impulsruis. Om deze waarde te veranderen, verander de downstreamparameters.

• Het tijdstip dat elektrische signalen nemen om door het HFC-netwerk te reizen van CMTS naar de kabelmodem en dan terug. DOCSIS specificeert een maximum één-weg-trip-tijd tussen de CMTS en de kabelmodem van 800 microseconden. Deze waarde varieert afhankelijk van de fysieke lengte van de kabelfabriek. Ook de downstreammodulatieregeling en de stroomopwaarts gelegen kanaalbreedte- en modulatieregeling beïnvloeden deze waarde.

• De tijd voor de kabelmodem om een ontvangen bericht van de KAART te verwerken en kan voor upstream transmissie worden voorbereid. Deze vertraging mag niet meer dan 200 microseconden bedragen, plus enige vertraging van de stroomopwaartse tussenkomst overeenkomstig de richtsnoeren in de DOCSIS-specificatie. In werkelijkheid kan deze tijd tot 300 microseconden of tot 100 microseconden bedragen, afhankelijk van de aanmaak, het model en de firmware revisie van kabelmodems.

Afbeelding 35 - Onderdelen in de MAP-tijd vooraf

De tijd van de kaartvoorschot kan de latentie van upstream transmissies aanzienlijk beïnvloeden omdat deze waarde de minimale vertraging vertegenwoordigt tussen de tijd wanneer de CMTS weet dat een kabelmodem een transmissie wil maken en de tijd wanneer de modem die transmissie mag maken. Om deze reden, minimaliseer de map voorschot tijd om stroomopwaarts latentie te verminderen.

Merk op dat in een verstopte stroomopwaarts gelegen periode ook andere factoren de stroomopwaarts latentie beïnvloeden. Bijvoorbeeld, vertraagt dat het backoff en het herprobeer bandbreedte het algoritme veroorzaakt, en de wachtrij van hangende beurzen achter elkaar.

Afbeelding 36 toont de relatie tussen een MAP die door de CMTS wordt gegenereerd en de corresponderende gegevensontvangst in de upstream.

Afbeelding 36 - Verband tussen de MAP-generatie en de ontvangst van upstreamgegevens

Diepte van tussenstuk

De eerste factor in de plattegronden die kunnen variëren is de stroomafwaartse tussenruimte zoals gebruikt voor de bescherming van impulslawaai. In deze tabel is de aan downstreamtransmissies toegevoegde latentie voor verschillende uitlader- en interleaver-increment weergegeven:

Opmerking: Hoe groter de tapegrootte, hoe krachtiger de foutcorrectie, maar ook hoe groter de veroorzaakte vertraging.

I (aantal taps)	J (verhoging)	Latency 64-QAM	Latency 256-QAM
8	16	220 µsec	150 µsec
16	8	480 µsec	330 µsec
32	4	980 µsec	680 µsec
64	2	2000 µsec	1400 µsec
128	1	4000 µsec	2800 µsec
12 (EuroDOCSIS)	17 (EuroDOCSIS)	430 µsec	320 µsec

U kunt de parameters van de tussenverlader instellen met de kabel stroomafwaarts onderverdiepte [8] | 16 | 32 | 64 | 128] configuratie van de kabelinterface

Opmerking: De waarde voor I (aantal taps) is gespecificeerd en een vaste corresponderende waarde voor J (toename) zoals in de tabel automatisch wordt weergegeven, is van toepassing. Voor de EuroDOCSIS-modus (bijlage A) worden de parameters voor de tussenfase vastgesteld op I = 12 en J = 17. De standaardwaarde voor I is 32, wat een standaardwaarde voor J van 4 oplevert.

Routeslag

De tweede factor die bijdraagt aan de vooraf te bepalen tijd die kan worden gevarieerd is de elektrische rondreistijd tussen de CMTS en kabelmodems. De fysieke afstand tussen de CMTS en kabelmodems en de verwerkingsvertraging die inherent is aan de kabelmodems beïnvloeden deze waarde.

De DOCSIS-specificatie verplicht ervoor te zorgen dat de maximaal toegestane één-weg-propagatietijd tussen de CMTS en de verste kabelmodem in het systeem niet meer dan 800 microseconden bedraagt. Dit impliceert een retourtijd, met uitzondering van de vertraging bij kabelmodemverwerking, van ongeveer 1600 microseconden.

De lichtsnelheid in een vacuüm is ongeveer 186.000 mijl per seconde (300.000 kilometer per seconde) en de snelheid van de voortplanting voor vezels wordt gewoonlijk aangegeven op 0,67. Daarom is de maximaal toegestane eenrichtingsafstand tussen een CMTS en een kabelmodem ongeveer:

	Distance = Velocity * Time

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

       		 = 100 miles or 161 kilometers.

Volgens de DOCSIS-specificatie mag de vertraging bij de kabelmodemverwerking niet groter zijn dan 200 microseconden plus enige upstream interleaving. In zeldzame gevallen kunnen bepaalde oudere merken kabelmodems echter wel 300 microseconden nodig hebben om een MAP-bericht te verwerken. nieuwere typen kabelmodems met krachtigere CPU’s kunnen tot 100 microseconden duren om een MAP-bericht te verwerken.

Stel dat kabelmodems gemiddeld voldoen aan de DOCSIS-specificatie. Daarom moet de maximale retourtijd 1600 + 200 = 1800 microseconden bedragen.

De meeste kabelsystemen zijn veel korter dan 100 mijl. Daarom is het niet optimaal voor een CMTS om altijd aan te nemen dat de elektrische rondreistijd tussen de CMTS en de verst mogelijke kabelmodem de maximumwaarde van 1800 microseconden is.

Voor een ruwe schatting van de grootste verwachte elektrische rondreis, de afstand tussen de CMTS en de kabelmodem optellen en vermenigvuldigen met 16 microseconden per mijl (10 microseconden per km). Stel vervolgens de afstand van een coax op en vermenigvuldig deze waarde met 12,4 microseconden per mijl (7,6 microseconden per km). Voeg vervolgens de 200 microseconde verwerkingsvertraging toe.

Een HFC-segment met in totaal 20 mijl vezel en een kilometer coax tussen de CMTS en de verst mogelijke kabelmodem kan bijvoorbeeld een elektrische rondreizendvertraging verwachten van:

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

= 532.4 microseconds

In dit cijfer wordt geen rekening gehouden met extra vertragingen als gevolg van upstream- en downstreamkanaalkenmerken en verschillen in modemverwerkingstijden. Daarom is deze waarde niet geschikt om te gebruiken bij het berekenen van de MAP vooruitgangstijd.

Een nauwkeuriger manier om de rondreistijd in een systeem te bepalen is de "Timing Offset" voor kabelmodems te observeren zoals gezien in de uitvoer van de show kabelmodemopdracht.Als onderdeel van het regelproces dat kabelmodems gebruiken om communicatie met de CMTS te onderhouden, berekent CMTS de rondreistijd voor elke kabelmodem. Deze rondreis verschijnt als "Timing Offset" in de opdrachtoutput van de kabelmodemmodule in eenheden van 1/10.24 MHz = 97,7 nanoseconden, timing-offset of offset-eenheden instellen. Om de timing offset voor een modem naar microseconden te converteren, vermenigvuldigt u de waarde met 25/256 of verdeelt u de waarde zeer ruwweg met 10.

Hier is een voorbeeld waarin de timing-offsets van verschillende modems in de opdrachtoutput van de showkabelmodems worden geconverteerd naar een microseconde waarde:

Opmerking: de microseconde waarde staat cursief.

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

In dit geval is de verste modem elektrisch de laatste modem met een timing offset van 6030. Dit is gelijk aan een retourtijd van 6030 * 25/256 = 589 microseconden.

Statische MAP-voortgang

In een systeem waarin u weet dat de lengte van het HFC-netwerk aanzienlijk minder dan 100 mijl is, kunt u de CMTS configureren om een maximale ronde reistijd te gebruiken die minder is dan de standaard 1800 microseconden wanneer u de MAP vooruitgangstijd berekent.

Om CMTS te dwingen om een douanewaarde voor ronde-trip tijd in de MAP-voorschot berekening te gebruiken, geeft de kabel kaart-voorschot statische max-ronde-trip-tijd kabelinterfaceopdracht uit.

Het bereik voor max-ronde-trip-tijd is 100 tot 2000 microseconden. Als er geen waarde is opgegeven voor de max-round-trip-tijd, is de standaardinstelling van 1800 microseconden van toepassing.

Opmerking: U kunt het statische sleutelwoord vervangen door het dynamische sleutelwoord. Zie de volgende paragraaf.

Zorg ervoor dat de gespecificeerde rondreis-tijd inderdaad groter is dan de grootste CMTS om modem ronde reistijd op het stroomafwaarts kanaal te kabelmodems. Als een kabelmodem een grotere ronde reistijd heeft dan die gespecificeerd in maximum-ronde-trip-tijd, kan de modem het moeilijk vinden om online te blijven. Dit komt doordat een dergelijke modem niet voldoende tijd heeft om op een MAP-bericht te reageren en derhalve niet met de CMTS kan communiceren.

Als de time offset van een kabelmodem, omgezet naar microseconden, de gespecificeerde max-ronde-trip-tijd overschrijdt, wordt de modem gemarkeerd met de slechte timing-offset vlag. Deze offset-vlag verschijnt als een uitroepteken (!) naast de timing-offset van de kabelmodem in de opdrachtoutput van de kabelmodem. Deze situatie kan zich voordoen als de max-round-trip-tijd parameter te laag is ingesteld of als de kabelmodem te weinig lijdt aan een probleem waar de timing-offset onstabiel is en constant stijgt in de tijd.

Hierna volgt een voorbeeld:

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)

In dit voorbeeld, wordt de kaart-voorschot statische 500 opdracht gespecificeerd. Een van de kabelmodems die op de kabelinterface zijn aangesloten, heeft echter een tijdoffset van meer dan 500 microseconden (gelijk aan 500 * 256/25 = 5120 offset-eenheden).

Merk op dat de timing offset van de laatste kabelmodem is gemarkeerd met de slechte timing offset vlag, een "!". Dit is ook vastgemaakt aan de maximaal toegestane waarde van 5120 eenheden, ook al kan de echte timing offset veel hoger zijn. Deze kabelmodem kan offline gaan en lijden aan slechte prestaties.

De slechte timing offset-vlag blijft voor de kabelmodem ingesteld, zelfs als de timing-offset lager is dan de max-ronde-trip-tijd. De enige manier om de vlag te wissen is de modem tijdelijk uit de toonkabel modemlijst te verwijderen. Hiervoor kunt u de opdracht verwijderen van de heldere mac-adres van de kabelmodem gebruiken. U kunt ook de kabelinterface of de upstream poort herstellen.

Om de bediening van het statische algoritme van de kaartvooruitgang op een upstream-basis te observeren, geeft u de opdracht van de de kabel van de controller-interface-nummer upstream upstream-nummer uit. Hierna volgt een voorbeeld:

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

Het veld Map Advance (Static) toont een map waarin 3480 microseconden van tevoren wordt aangegeven. Als u de downstreaminterlader-eigenschappen of de max-round-trip-tijd-parameter wijzigt, wordt de verandering weerspiegeld in de statische plattegrondewaarde.

Dynamisch MAP-geavanceerde ondersteuning

Voor het gebruik van de statische MAP-voorberekening om de MAP-voorgangstijden te optimaliseren, dient de CMTS-exploitant de grootste ronde-reistijd op een kabelsegment handmatig te bepalen. Indien de stroomafwaarts of stroomopwaarts gelegen kanaalkenmerken veranderen of indien de omstandigheden van een plant veranderen, kan de maximale rondreistijd aanzienlijk veranderen. Het kan moeilijk zijn de configuratie voortdurend bij te werken om rekening te houden met de verandering in systeemomstandigheden.

Het dynamische MAP geavanceerde algoritme lost dit probleem op. Het dynamische MAP geavanceerde algoritme scant periodiek de van de showkabelmodemlijst om naar de modem te zoeken met de grootste aanvankelijk regelende timing offset, en gebruikt dan automatisch die waarde om de MAP vooruitgangstijd te berekenen. De CMTS gebruikt dus altijd de laagst mogelijke map vooruitrichtingstijd.

De eerste regelingstijd offset voor een kabelmodem is de tijdoffset die de modem meldt op het punt waar de modem online komt. In de meeste gevallen, is dit dicht bij de aanhoudende timing offset zoals gezien in de opdrachtoutput van de showkabelmodem. Sommige typen kabelmodems hebben echter een probleem wanneer de timing offset in de tijd omhoog kruipt naar zeer grote waarden. Dit kan de map vooruitlopen op de tijdberekening. Dus slechts de eerste regelingstijd offset, die alleen wordt bijgewerkt als een modem online komt, wordt gebruikt. Om de eerste regelafstand timing offset en de doorlopende timing offset voor een kabelmodem te bekijken, geeft u de opdracht kabelmodemmodule met breedband uit. Hierna volgt een voorbeeld:

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

In dit voorbeeld is de aanhoudende time offset (2566) iets hoger dan de initiële time-offset (2560). Deze waarden kunnen enigszins afwijken. Als de waarden echter meer dan een paar honderd eenheden verschillen, kan er een probleem zijn met de timing-offset-controle van de kabelmodem.

Om de berekening van de dynamische plattegronden te activeren geeft u de opdracht om de kabelplattegrond-geavanceerde dynamische veiligheidsfactor max-, retourvlucht-tijd kabelinterfacekaart uit.

De veiligheidsfactor-parameter varieert van 100 tot 2000 microseconden. Deze parameter wordt toegevoegd aan de MAP-tijd, zodat een kleine waarborg wordt geboden om rekening te houden met eventuele extra onverwachte vertragingen bij de doorgifte van signalen. De standaardwaarde is 1000 microseconden. Voor stabiele kabelsystemen die geen significante veranderingen ondergaan in de kabelinstallatie of in de stroomopwaarts of stroomafwaarts gelegen kanaalkenmerken, moet echter een lagere waarde worden gebruikt, zoals 500 microseconden.

De max-ronde-trip-tijd parameter varieert van 100 tot 2000 microseconden. Deze parameter wordt gebruikt als een bovenste limiet voor de tijdoffsets van kabelmodems die op het kabelsegment worden aangesloten. De standaardwaarde is 1800 microseconden. Als de time offset van een kabelmodem, geconverteerd naar microseconden, de gespecificeerde max-ronde-trip-tijd overschrijdt, wordt deze gemarkeerd met de slechte timing-offset vlag.

Stel de max-ronde-trip tijdparameter in op een niet-standaardwaarde als u weet dat de lengte van het kabelsysteem aanzienlijk minder dan 100 mijl is, en als u weet wat de maximum normale tijdoffset moet zijn voor kabelmodems die op het segment zijn aangesloten.

Neem de bediening van het dynamisch map voorschot algoritme op een stroomopwaartse basis in acht met de opdracht van de controlelekabel van het upstream upstream-nummer. Hierna volgt een voorbeeld:

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

De Tx Timing Offset-waarde toont de grootste timing offset voor alle kabelmodems die op de upstream zijn aangesloten in timing-offseteenheden. Gebruik deze waarde om de MAP-vooruitgangstijd te berekenen. Het veld Map Advanced (Dynamisch) toont de tijd die u in de kaart wilt verwerken. Deze waarde kan variëren als de offset voor vaste tijd verandert, als de waarde voor de veiligheid wordt gewijzigd of als de eigenschappen voor de downstreamparameter worden gewijzigd.

Het dynamische MAP voorschot algoritme hangt af van of kabelmodems hun eerste regelende timing offset aan CMTS correct rapporteren. Helaas, sommige maken en modellen van kabelmodems rapporteren de aanvankelijke planning van tijdverschuivingen als waarden die aanzienlijk lager zijn dan de echte waarde. U kunt dit waarnemen wanneer modems tijdoffsets tonen die dicht bij nul of zelfs negatieve waarden zijn.

Foutberichten vergelijkbaar met %UBR7200-4-BADTXOFFSET: Slechte timing offset-2 gedetecteerd voor kabelmodem 00ff.0bad.caf3 kan op dergelijke kabelmodems verschijnen. Deze typen kabelmodems rapporteren hun timing-offsets niet op een DOCSIS-conforme manier, kan het dynamisch map-voorschot algoritme niet correct een map-voorschot tijd berekenen die gegarandeerd is om elke kabelmodemtijd te geven om te ontvangen en te reageren op MAP-berichten.

Als dergelijke kabelmodems op een kabelsegment aanwezig zijn, schakelt u het dynamische MAP voorschot algoritme uit en keert u terug naar het statische MAP voorschot algoritme. Raadpleeg waarom bepaalde kabelmodems een negatieve tijdoffset weergeven. voor meer informatie .

Gerelateerde informatie

• Technische ondersteuning en documentatie – Cisco Systems

Revisiegeschiedenis