Packet loss impact
-
Hoi iedereen.
In mijn testen merk ik een redelijk hoge packet loss als het device meerdere berichten snel achter elkaar stuurt. In mijn meting stuurt één device één bericht per seconde. Na 1000 berichten waren er 204 pakketjes kwijt geraakt, een packet loss van 20,4% dus. Hoe komt dit en hoe kunnen we dit voorkomen?
-
Interessante test. Ik heb eerder ook hoge packet loss issues gehad, maar sinds scrambling aan staat was dat (nagenoeg) verdwenen. Nu is 1 bericht per seconde ook wel heel erg veel. Volgens mij is de TMNL netwerk capaciteit berekend op 10 berichten per uur (althans dat is hun eerder gecommuniceerde commerciële aanbod).
Je test is overigens wel erg relevant. Want stel dat je incidenteel een bestandje met uitgebreidere meetdata zou willen opsturen, dan zou je dat binnen de huidige NBIOT implementatie moeten opknippen in korte berichten (bijv 10kB = 20*512B) en apart versturen. Uiteraard mogen er hierbij geen pakketten verloren gaan, en een interval van 1 pakket per 6 minuten is niet wenselijk.
Misschien kun je de test herhalen met andere intervallen, bijvoorbeeld 1 bericht per 5 sec, 10 sec, 20 sec, 1 min, 2 min, 5 min, 10 min, 20 min, etc? Kijken of er een trend waarneembaar is.
p.s. Ben benieuwd hoe het netwerk gaat reageren op de SODAQ test die deze week wordt uitgevoerd; 100 devices op dezelfde mast, het is onbekend van hoeveel berichten per uur deze test uitgaat.
-
Alle verschillende componenten in ons IoT-netwerk hebben features om flood attacks te voorkomen.
Als jouw device elke seconde een bericht stuurt betekent het niet dat de antenne (cell) het ook iedere seconde ontvangt en/of doorstuurt naar andere onderdelen in het netwerk.Als pakketje 1 vertraagd binnenkomt en pakketje 2 op tijd binnen komt, zit er uiteindelijk misschien maar 100 ms tussen wanneer beide pakketjes door andere componenten in het netwerk gaan. In ons core netwerk hebben we derhalve een rule ingesteld dat er minimaal 500 ms tussen de berichten van 1 device moet zitten.
Vandaar dus dat je wat pakketten bent verloren. Met een hogere interval moet dat dus minder zijn.
Je kunt ons verder ook uitdagen door bijvoorbeeld met 5 devices te testen, waarbij elk device om de 5 seconden een berichtje stuurt. Als het goed is krijg je dan alles binnen!
-
@felixdonkers said in Packet loss impact:
Misschien kun je de test herhalen met andere intervallen, bijvoorbeeld 1 bericht per 5 sec, 10 sec, 20 sec, 1 min, 2 min, 5 min, 10 min, 20 min, etc? Kijken of er een trend waarneembaar is.
Ik heb de test herhaalt met een interval van 3 seconden, nu ben ik na 2000 pakketjes er maar 5 kwijt
@afzal_m said in Packet loss impact:
Vandaar dus dat je wat pakketten bent verloren. Met een hogere interval moet dat dus minder zijn.
Je kunt ons verder ook uitdagen door bijvoorbeeld met 5 devices te testen, waarbij elk device om de 5 seconden een berichtje stuurt. Als het goed is krijg je dan alles binnen!
Duidelijk verhaal, bedankt! Maar kunnen we hier ook absolute getallen aan koppelen? Het is erg lastig om nu te bepalen wat de grenzen zijn. Enkele seconden lijkt nu misschien niks maar over langere termijn kan dit wel veel invloed hebben op je batterijduur. Ik begrijp dat dit afhankelijk is van veel factoren, onder andere drukte op het netwerk, drukte per cell, interval van het device etc. Kun je een aanbeveling doen mbt maximale interval?
-
Yeap! Vijf berichten per device per uur.
-
Het blijft overigens wel een lastig verhaal. Als we met iedereen afspreken dat de payload nooit hoger is dan bijvoorbeeld 100 bytes, dan zou het gemiddeld aantal berichten per device ook hoger kunnen zijn.
-
@afzal_m Ik ben vooral benieuwd wat de internationale afspraken hierover zijn, binnen 3GPP of GSMA. Want die 5 berichten per uur, geldt dat ook in andere landen waar T-mobile actief is en geldt dat ook voor andere providers (Vodafone etc)? En als we de applicatie beperken tot 5 berichten per uur, hoeveel % van de berichten gaat er dan maximaal verloren?
Dit zijn belangrijke parameters voor een robuust product ontwerp. -
Zo ver ik weet zijn er geen internationale afspraken over performance. Er zijn daarentegen wel theorieën over hoe de performance en prestaties van NB-IoT zouden kunnen zijn. Met nadruk op ‘kunnen’ en dus geen ‘moeten’.
Ik ben niet in de positie om te vertellen wat er voor andere providers of andere Deutsche Telekom landen geldt. Logisch zou zijn dat alle telecom operators NB-IoT aanbieden zoals het bedoeld is en waarvoor het concept ooit ontworpen is.
Er zijn volgens mij nog niet zoveel telecombedrijven die NB-IoT commercieel aanbieden. En van die paar telco’s die het al wel commercieel aanbieden, zien wij dat ze het als een ‘bit pipe’ aanbieden. Dat snappen wij niet zo goed. Dat was namelijk niet de bedoeling toen men aan de tekentafel stond voor NB-IoT.
Wij zien het in ieder geval als een dienst waarbij we de volgende zaken moeten aanbieden om van toegevoegde waarde te kunnen zijn:
- schaalbaarheid
- veiligheid
- duurzaamheid
- een lange houdbaarheid
- efficientie
Dit bieden we aan in combinatie met de mogelijkheid om 120 berichten per dag over en weer te kunnen versturen. Dit aantal is gebaseerd op de verschillende theorieën waar ik eerder in dit bericht over sprak en tevens bevestigd door de testen die we de afgelopen weken hebben gedaan. Deze vijf berichten per uur moeten ook altijd aankomen bij normale omstandigheden qua coverage.
Als ik iets nader moet toelichten hoor ik het graag!
-
Logisch dat je mikt op een alternatief voor LoRa en Sigfox.
