Bragt i Computerworld d. 24 juli 2014
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.
Når vi snakker hastighed så er der et loft, altså den højest mulige hastighed som er defineret dels af den teoretiske grænse, som gode gamle Claude Shannon har beskrevet, og dels en praktisk/implementeringsmæssig grænse. 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å 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 standard scenarier 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 IPTV.
TIP: Hvis du sidder og føler dig lidt ensom i supporten for en ISP og trænger til at snakke med nogen, så flip et par linjer for IPTV kunder…
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 performance tab 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 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 data pakker er fejlbehæftede (hvilket detekteres vha. CRC algoritmen). Kundens oplevelse er, at data pakken skal retransmitteres eller er tabt. Ved surf giver det sig udslag i øget latenstid og ved IPTV giver det potentielt et glitch[1] på TV billedet.
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:
- Din linje oplever en DS-CRC fejl præcist en gang i minuttet.
- 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.
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.
Sammenhængen mellem QoS og QoE er ikke lineær
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 specificerer følgende QoE kriterier[3] 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 oplevelsen 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 atiklen om støj er der 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.
[1] Et glitch defineres som en fejl af kort varighed. Se f.eks. http://en.wikipedia.org/wiki/Glitch
Faktisk vil 10 på hinanden SES betyde at linket reinitialiserer, men det er ikke relevant for forklaringen.
[3] TR126, Tabel 12&14