De foregående artikler handler om det miljø, som DSL skal fungere i, og nu vil jeg i sommervarmen slappe af med en artikel om, hvilke krav vi så stiller til et DSL-system.
Der er to primære ting, som vi kan stille krav om: Hastighed og stabilitet.
Læs også de forgående artikler i serien:
- Del 1: Dine internetkabler er en Ferrari på en grusvej (om signalstyrker og kabler)
- Del 2: Langsomt internet? Der er nok (også) støj på din linje (om støj på kobberkablerne)
Dette kommer jeg mere ind på i næste artikel, som handler om modulationsteori.
Vi skal selvfølgelig også sikre os, at producenterne af routere og chipsets bliver presset til at gøre sig umage, så der også er defineret en nedre grænse. Men som I kunne læse i artiklerne om kabler og støj, så er hastigheden særdeles afhængig af de faktuelle forhold på linjen.
Dette har man imødegået ved at definere en række standardscenarier for støj og kabeltyper, og man stiller så krav til en minimums-performance under disse forhold. Alt dette foregår i Broadband Forum (BBF), hvor operatører og leverandører fra hele verden deltager.
For VDSL kan kravene f.eks. findes i TR-114 (annex B er den, der gælder for Europa). Jeg kan anbefale, at interesserede snuser rundt inde på http://www.broadband-forum.org/, der er mange spændende ting, man kan læse om.
Hastighed er én ting, men det er min erfaring, at stabilitet er langt mere væsentlig. Der er ikke noget mere irriterende end en internetforbindelse, som er ustabil. Dette er ikke mindst blevet vigtigt, efter at man introducerede fjernsyn over internettet, også kendt som IPTV.
TIP: Hvis du sidder og føler dig lidt ensom i supporten for en internetudbyder og trænger til at snakke med nogen, så flip et par linjer for IPTV-kunder ... så skal telefonen nok ringe.
Hvad er så kravet for DSL?
Hvis vi starter i det teoretiske hjørne, så benyttes termen BER (Bit Error Rate) for transmissionssystemer.
BER er forholdet mellem korrekte bits og fejlbehæftede bits og angives som en negativ potens af 10. Således betyder det, hvis et link har en BER på 10^(-7), at når der sendes 10.000.000 bits må højst én bit være fejlbehæftet.
Tallet er ikke tilfældigt valgt - det er det grundlæggende designkriterium for et DSL system, at BER skal højest være 10^(-7) ved 0 dB margin. Dette tal er ikke specielt imponerende, når man tænker over det. Ved en hastighed på 10 Mbit/s betyder det jo en fejl i sekundet, og hvem kan leve med det?
Det er heldigvis ikke så slemt, for du skal lægge mærke til, at den angivelse er ved 0 dB margin, hvor linjer aldrig kører. I praksis vælger de fleste operatører at køre DSL ved en margin på 6 dB (med andre ord kan støjen øges med 6 dB, uden at linket falder) som er et passende kompromis mellem performancetab og forbedret stabilitet.
Hvis vi antager, at støjen er konstant og fuldstændig hvid, betyder 6 dB margin, at BER falder til omkring 10^(-24), hvilket vil sige en fejl ca. hver 1,5 billioner år. Desværre opfører verden sig sjældent så eksemplarisk, og et mere realistisk bud (baseret på empiriske data) lyder derfor på, at BER <= 10^(-9) ved 6 dB margin.
Dette kan omsættes til, at der under normal operation går mindst 1 time og 40 minutter mellem bitfejl og typisk noget længere (før du går i panik, så husk, at langt de fleste bitfejl rettes af fejlkorrektionsalgoritmerne - mere om dette i en kommende artikel).
Bitfejl, som BER angiver, er ikke en særlig praktisk målemetode, da det per definition forudsætter en seriel strøm af data. DSL implementerer ikke som standard et serielt interface, så det er svært at lave en direkte måling af BER på et DSL system.
Metoden, der benyttes, er i stedet, at estimere BER ud fra antallet af CRC-fejl på linjen (Cyclic Redundancy Check, en meget udbredt algoritme til at detektere fejl i data - For de nysgerrige: http://en.wikipedia.org/wiki/Cyclic_redundancy_check).
Det er vedtaget på baggrund af en analyse og et væld af praktiske målinger, at en CRC fejl svarer til 20 eller 50 bitfejl afhængig af, om DSL systemet benytter FAST eller INTERLEAVED datapath (mere om datapath i en kommende artikel om fejlkorrektion).
Stabilitet, kogt ned til de to primære parametre
Et DSL-system rapporterer en lang række performance- og fejlvariable, og tricket er at nedkoge den store mængde information til kun det relevante.
Når vi snakker stabilitet, er der, set fra brugerens synsvinkel, to primære fænomener, der giver anledning til oplevet ustabilitet:
CRC fejl - mindre fejl på linjen f.eks. forårsaget af støj eller clipping (overstyring af linedriver) resulterer i, at modtagne datapakker er fejlbehæftede (hvilket detekteres vha. CRC algoritmen). Kundens oplevelse er, at datapakken skal retransmitteres eller er tabt. Ved surf giver det sig udslag i øget latenstid, og ved IPTV giver det potentielt et glitch på TV billedet.
Et glitch defineres som en fejl af kort varighed. Se f.eks. forklaring her. Faktisk vil 10 på hinanden SES betyde, at linket reinitialiserer, men det er ikke relevant for forklaringen.
Reinitialiseringer - større fejl (eller gentagne fejl) på linjen resulterer i, at DSL-linket brydes og derefter genforhandles. Kundens oplevelse er et totalt udfald af datastrømmen af typisk 30-60 sekunders varighed. Denne type fejl kan virkelig lave sure kunder, så her bør man som ISP gøre sig ekstra umage!
Tiden har betydning
Forestil dig følgende to tænkte scenarier: Du har 20 Mbps downstream (interleaved), og vi måler på din linje i et døgn:
1) Din linje oplever en DS-CRC fejl præcist en gang i minuttet.
2) Din linje kører fuldstændig perfekt i 23 timer og 59 minutter. I de sidste 60 sekunder kommer der 24 DS-CRC fejl i sekundet.
I begge tilfælde er antallet af CRC fejl 1440, og dermed - hvis vi udelukkende betragter antallet af CRC fejl - er de to linjer præcist lige ustabile. Men er din oplevelse som kunde den samme?
I det første tilfælde er du garanteret, at blive generet af fejlene. I det andet tilfælde er der en ikke ubetydelig sandsynlighed for, at du enten sover eller laver noget andet lige i de kritiske 60 sekunder.
Det sidste scenarie er i øvrigt det mest realistiske - CRC-fejl kommer som regel i bursts.
Derfor er det interessant at kigge på spredningen i tid for CRC-fejlene. Til det benytter vi to tidsbaserede parametre:
- Errored Seconds (ES) - Antallet af 1-sekunders intervaller hvor mellem 1-17 CRC-fejl er detekteret.
- Severely Errored Seconds (SES) - Antallet af 1-sekunders intervaller hvor 18 eller flere CRC-fejl er detekteret.
Genbesøger vi eksemplet ovenfor og introducerer ES i ligningen, kan vi se, at det nu er muligt at skelne de to scenarier.
CRC er stadig 1440, men i det ene tilfælde er ES=1440/SES=0, og i det andet er ES=0/SES=60 [2]. Denne information kan hjælpe med at klassificere fejltype og kilde.
Quality of Experience
CRC, ES, SES, NSA, BER ... fancy forkortelser kan jeg hælde ud af ærmet, men problemet med alle disse parametre er, at det er objektive tal, og vi mangler koblingen over til kundernes subjektive oplevelse.
Hermed vil jeg introducere en ny fancy forkortelse, QoE (Quality of Experience).
Hvor QoS (Quality of Service) er en objektiv parameter, der kan kvantificeres direkte (f.eks. CRC-fejl eller latency), er QoE en subjektiv parameter og dermed et udtryk for, hvordan kvaliteten opfattes af slutbrugeren.
Måleenheden for QoE er typisk MOS (Mean Opinion Score), som fremkommer ved at udsætte en forsøgsgruppe for fejl i tv-oplevelsen og sammenfatte middelværdien af deres resulterende subjektive oplevelse af kvaliteten. Nedenstående graf viser den ikke lineære sammenhæng mellem det objektive og det subjektive.
Det subjektive QoE kriterium kan mappes over i nogle målbare QoS parametre, som vi dermed kan opstille nogle specifikke og målbare krav for.
Broadband Forum TR-126 (Tabel 12&14) specificerer følgende QoE kriterier for IPTV:
- For SD (Standard Definition) TV, maksimum én artefakt per time
- For HD (High Definition) TV, maksimum én artefakt per 4 timer
En artefakt er en fejl på linjen, som giver et synligt resultat på tv'et (sort skærm, glitch, udfald af lyd, etc.).
Hvis vi mapper QoE direkte til QoS vil det sige, at en linje er perfekt til SD IPTV, hvis der mindst går en time mellem hver CRC-fejl og tilsvarende for HD IPTV mindst fire timer mellem hver CRC-fejl.
Dette er dog en absolut worst case-betragtning, idet enkeltstående CRC-fejl overhovedet ikke påvirker tv-oplevelse, da IPTV platformen (i hvert fald den, Fullrate benytter) foretager fejlkorrektion på applikationslaget.
Min erfaring siger, at IPTV er ganske immunt for såvel enkelte som bursts af CRC-fejl, men at REIN (Repetitive Electrical Impulse Noise), som jeg beskrev i artiklen om støj, er den type fejl, som giver størst problemer.
Nok om kvalitet for denne gang. Klummen holder lidt ferie og vender stærkt tilbage med den første artikel om, hvordan vi så implementerer DSL.
God sommerferie til jer alle!
Læs også første artikel i serien: Dine internetkabler er en Ferrari på en grusvej