Suomessa on totuttu huippunopeisiin mobiilin- ja kiinteän laajakaistan yhteyksiin.  Paljon nopeampiin kuin EU ”nopean laajakaistaliittymän määritelmä”.  Samalla kuin 5G markkinointikone rummuttaa samaa kaavaa ”lisää kapasiteettia ja pieni siirtoviive” ja toinen leiri haluaa ”valokuitua jokaiseen kotitalouteen” on syytä tuoda keskusteluun muitakin näkökulmia päätöksentekoon.

On hyvä, että infrastruktuurimme Suomessa tietoverkkojen osalta kehittyy, mutta käyttäjälle sovelluksen nopeus on pääosin kiinni ihan muusta kuin verkon liittymän kaistanleveydestä. Turhasta ei kannata kenenkään maksaa.

Vertailemme mielellämme liittymien nopeuksia puhelimien ja työasemien testiohjelmilla niiden oletusasetuksilla. Tämä on helppo tapa vakuuttua, että saimme mistä maksoimme. Mikä sitten mättää, kun yrityksen sovellukset eivät tunnu nopeutuvan verkkoinvestoinneista ja lupauksista huolimatta?

Internet-maailmassa lähes kaikki laatua edellyttävät sovellukset käyttävät TCP-protokollaa. Tässä protokollassa kolme tärkeintä suorituskykyyn liittyvää muuttujaa ovat A) TCP ikkunan koko, B) WAN-verkon edestakainen siirtoviive sekä C) TCP pakettihävikki. Tästä voidaan helposti laskea suurin tiedonsiirto nopeus, joka voidaan saavuttaa. Oletus TCP ikkunakoolla kaava:

(65535 bytes * 8 bits/byte) = bandwidth * 0.030 second
bandwidth = (65535 bytes * 8 bits/byte) / 0.030 second
bandwidth = 524280 bits / 0.030 second
bandwidth = 17476000 bits / second

Esimerkkinä 10Gbps WAN-yhteys Helsingin ja Irlannin välillä, jossa edestakainen siirtoviive E2E on noin 30 millisekuntia.  Oletus TCP ikkunan koko 64KB (65536 Bytes) x 8 = 524288 bits, joka jaetaan siirto viiveellä 0,030 (30 millisekuntia). Paras mahdollinen tiedonsiirtonopeus on 17476266 bits per second eli vain 17.4 Mbps. Mikäli työasemasi on vaikkapa Intiassa 120 ms päässä, on vastaava tiedonsiirtonopeuden maksimi 4,3Mbps. Aika heikko lukema hankittuun kapasiteettiin nähden?

Alkuperäisen TCP rajoituksen kiertämiseksi on kehitetty käyttöjärjestelmään TCP Windows Size Scaling, jolla ikkunan kokoa voidaan nostaa lähes 1 gitatavuun (GB).  Tällä päästäisiin täyttämään 10 Gbps yhteys, joskin kyseessä on hyvin teoreettinen laskenta.

(10 Gbps * 30ms/1000sec) / 8bits/byte = window size
(10000 Mbps * 0.030 second) / 8 bits/byte = 37.5 MB

Modernit päätelaitteet ja pilvipalvelut pyrkivätkin adaptiivisesti ja asteittain kasvattamaan TCP ikkunan kokoa saavuttaakseen mahdollisimman suuren tiedonsiirtonopeuden. Käytännössä kovin suureen ikkuna kokoon ei päästä tai sitä ei haluta tarjota johtuen muista seikoista.

Yksi suurimpia haasteita on WAN verkon pakettihävikki (packet loss). Mikäli paketteja pudotetaan matkalla olevien laitteiden kuormituspiikkien, turhan liikenteen, virheellisen konfiguraation tai muiden sovellusten priorisointien tieltä joudutaan kaikki paketit uudelleen lähettämään joista kuittausta ei saatu. Tämä puolestaan laskee siirtonopeutta merkittävästi.  2% pakettihävikki pudottaa läpäisykykyä 6 – 25 kertaa heikommaksi siirtoviiveestä riippuen.

Toinen haaste on vanhan päätelaitteen TCP stack ja kyky puskuroida dataa, joka edellyttää huomattavan suurta keskusmuistin allokoimista ja prosessointitehoa.  Yritysmaailma ja erityisesti teollisuuden tuotantojärjestelmien vaihtaminen ei ole realistista nopealla aikataululla, vaikka verkkokapasiteettia saadaankin.  TCP Windows Scaling ei myöskään ole tuettu vanhoilla käyttöjärjestelmillä.

Kolmas haaste on jaettujen pilvipalveluiden suuri samanaikaisten käyttäjien määrä. Yhdelle käyttäjälle tai sovellukselle ei voida allokoida 100% resursseista. Tämä on helppo todentaa verkkoanalysaattorilla. Olen juhannuksena mobiiliyhteyden päässä ja siirrän 1GB pakatun tiedoston pilvestä työasemalleni. Työasemani ehdottaa jatkuvasti paljon suurempaa TCP ikkunan kokoa, mutta pilvipalvelu ei nosta arvoa pyydettyyn. Latenssi on noin 130ms. Todellinen tiedonsiirtonopeuteni jää 100Mbps mobiililiittymällä noin 0,5Mbps.

Tuoko 5G pienen latenssin vai onko se vain markkinointia?

5G teknologiaa hehkutetaan usein pienen siirtoviiveen teknologiana. Valitettavasti nykyisellä pilvi arkkitehtuurilla 5G radion siirtoviiveen hyöty tai parannus 4G vastaavaan on olematon. 99% siirtoviiveestä päätelaitteelta Azure tai AWS pilveen on edelleen jäljellä 5G siirtymisen jälkeenkin.  TCP protolla toimii kuten ylläkuvatussa esimerkissä ja kaavasta voi helposti laskea lopputuleman.  Nykyisellä pilvi arkkitehtuurilla siirtyminen 5G ei siis muuta sovelluksen suorituskykyä päätelaitteelle, vaikka liittymän nopeuslupaus ja testiohjelman ”speed test” tulos olisi kuinka suuri.

Siirtoviivettä saadaan pienemmäksi vain prosessoimalla sovellusta lähempänä päätelaitetta ja käyttötapahtumaa. Tästä puhutaan termillä Edge Computing. Esimerkiksi Ethernet lähiverkossa (LAN) siirtoviive on reilusti alle 1 millisekunti (5-125 mikrosekuntia), pakettihäviö ja viiveen vaihtelu olematon.  Nopeaa reagointikykyä ja prosessointia edellyttävä sovellus ohjaus onkin toteutettu paikallisella palvelin prosessoinnilla ja LAN-verkolla viimeiset 25 vuotta.  Edge Computing ei siis ole uusi konsepti, mutta kehittyy nopeasti pilviarkkitehtuurin laajentamiseksi saumattomaksi kokonaisuudeksi kokonaisratkaisun osalta.

5G teknologian osana on mahdollista toteuttaa Edge Computing konsepti. Olen kuitenkin varsin skeptinen sen toteutumisen mahdollisuuksista erityisesti B2B ratkaisuissa. Teollisuuden automaation osaprosessoinnin siirtäminen paikallisen 5G operaattorin hostaamaksi ja sen integroiminen julkisen pilven ratkaisuun kansainvälisen yrityksen toimintakentässä tuntuu kohtuullisen monimutkaiselta sekä teknisen toteutuksen että sopimusjuridiikan osalta. Sovelluksen prosessoinnin siirtäminen paikallisverkosta radioverkon taakse ei myöskään paranna siirtoviivettä, vaan heikentää sitä.  Lisäksi prosessoinnin tulisi toimia, vaikka WAN-verkko olisi alhaalla. Kun 5G sisätilapeitto nostaa vielä merkittävästi kustannuksia ja jokaisessa maassa on oletettavasti hieman erilainen toteutusmalli, on vaikeaa löytää business casea.  Kuluttajille 5G Edge Computing löytynee jollakin aikavälillä sovellutus mobiilipäätelaitteelle. 

Jäitä hattuun – Optimoi verkko ja sen kustannukset

Verkon optimoinnissa latenssi/siirtoviive, TCP ikkuna ja pakettihäviö merkitsevät enemmän. Tässä neljä tärkeää asiaa parhaan käyttökokemuksen saamiseksi ja kustannusten optimointiin.

  • SD-WAN ratkaisuissa ei kannata katsoa pelkästään paikallisen liittymän nopeutta, mutta yhteyden laatua ja liikenteen suuntautuvuutta. Internet kapasiteetti yksin ei ole tae yleisestä sovelluksen nopeudesta.
  • WAN-verkon suunnittelussa kannattaa liikenneprofiiliin ja sovelluksen toimintaan perehtyä ennen suurempien päätösten tekemistä huolellisesti. WAN-verkko on suuri kiinteä kulu yritykselle. Tietämällä tarpeen ja faktat voit säästää paljon.
  • WAN verkon laadun osalta pakettihäviö ja viiveen vaihtelut kannattaa laittaa seurantaan tai selvittää vähintään säännöllisesti. Pienikin korjaus voi parantaa merkittävästi käyttökokemusta.
  • Yritysten liikkuvien käyttäjien kapasiteettina yli 50Mbps liittymä nopeudet kannattaa harkita tarkkaan. Erityisesti mikäli käytät pilvi palveluita.

 

Hannu Rokka, Senior Advisor

5Feet Networks Oy