Energiförbrukning LoRaWAN kontra mobil IoT
Jämförelse energiförbrukning mellan LoRaWAN och mobil IoT (NB-IoT, Cat-M1)
OBS! Avsikten med detta inlägg är inte att säga vilken teknik som är bättre eller sämre. Utan snarare för att visa hur mobil IoT och LoRaWAN kompletterar varandra. Ambiductor avser att kunna tillgodose både LoRaWAN och mobil IoT.
Batterilivslängd är i särklass en av de viktigaste övervägandena för LPWAN-applikationer. Anledningen är att när du installerar många sensorer är det väldigt dyrt att fysiskt byta batterier och kommer att förstöra lönsamheten om enheterna bara håller några år. Det är därför alla tekniska lösningar, även LoRaWAN eller mobil IoT (Cat-M1, NB-IoT) verkar hävda batterilivslängden på +10 år men inte tydligt anger enhetens trafikmönster och hur långt enheten ligger från basstation / Gateway.
I denna artikel kastar vi lite ljus över hur LoRaWAN kan hävda så mycket lägre strömförbrukning till NB-IoT. Och hur NB-IoT kan ta itu med fler krävande användarfall med högre trafik, som inte kan hanteras av LoRaWAN. Det finns inget rätt eller fel svar, kraven i applikationen avgör vilken radioteknik som bör användas.
Närmare titta på Access-protokollet bakom LoRaWAN och NB-IoT
Några av IoT-applikationerna, såsom lokaliseringstjänster, använder uppladdningsbara enheter och har batteritid från 7 till 30 dagar, men det finns applikationer där en enhet används på svårtillgängliga platser och behöver batterilivslängd på 10+ år (till exempel smarta mätare belägna i källare inomhus). Rent allmänt använder LoRaWAN klass A-enheter minimal strömförbrukning på grund av enkelheten i radiotrafiken och det faktum att enheten endast är aktiv när den sänder, och sover mest av tiden (se figur 1a nedan). Detta till skillnad från mobil teknik där en enhet periodiskt måste vakna för att synkronisera sig med nätverket, även om det inte har någon data att sända (se figur 1b nedan). Varje datasändningstillfälle i NB-IoT kräver många TX/RX/Idle-övergångar på grund av protokollets komplexitet.
LoRaWANs asynkrona natur gör modulens design mycket enkelt och billigt att utveckla, till skillnad mot mobil teknik som använder avancerade schemaläggningsalgoritmer för att strikt kontrollera effektiviteten hos dyra licensierade spektrum. Mobiltelefonteknik är utan tvekan traditionellt utformad för att utnyttja spektret optimalt, men kraftigt påverkar enheternas strömförbrukning. Mobil NB-IoT och Cat-M1 har många optimeringar i Rel 13, som energisparande mekanism (PSM) och förstärkt DRX (eDRX) för att sätta enheten i viloläge för det mesta, men enheten måste vakna regelbundet för att lyssna på nätverket på grund av synkroniseringen av det mobila IoT-systemet.
Figur 1a. LoRaWAN klass A drift
Figur 1b. NB-IoT-drift [6]
Strömförbrukning hos LoRaWAN jämfört med mobil IoT
Varje enhet, både inom LoRaWAN och mobil IoT måste växla mellan olika lägen (sändning, mottagning, viloläge och sovläge). Det är strömförbrukningen av dessa lägen som definierar energiförbrukningsberäkningen som vi kommer att visa nedan.
Tabell 1 jämför toppströmmen mellan LoRaWAN och NB-IoT och det är uppenbart att LoRaWAN är 3-5 gånger så effektiv när det gäller ström jämfört med NB-IoT. Cat-M1-enheterna är ännu mer krafthungriga, men de tillåter mer kommunikationsmängd för ännu mer krävande applikationer. Mobil IoT är verkligen mer optimerad för höga datahastigheter.
Tabell 1: LoRaWAN strömförbrukning jämfört med mobil IoT
Obs! TX-ström för LoRaWAN baseras på Max LoRaWAN TX-effekt = 14 dBm (EU-föreskrifter)
Jämförelse av olika uppkopplingstillstånd
Låt oss nu titta på de olika uppkopplingstillfällena mellan LoRaWAN och NB-IoT. Uppkopplingen vi jämför är 1 uplink med payload på 50 Byte. Många LoRaWAN-användningsfall som smarta mätare, smarta lampor, spårning m.m. använder endast en payload på 20 Byte eller mindre. Tabell 5 visar jämförelsetiden mellan olika tillstånd (TX/RX/Idle) inom LoRaWAN kontra NB-IoT och på grund av synkroniseringen av mobilt IoT spenderar NB-IoT-enhetr betydande tid i viloläge/RX-tillstånd jämfört med LoRaWAN på grund av strikta synkroniserings- och schemaläggningskrav.
Vi visar här resultat för 50 Byte eftersom det här var vad vi hittade i en 3GPP-studie. Det som är mycket intressant och uppenbart i tabellen nedan är att NB-IoT-enheten spenderar mycket tid i RX/viloläge på grund av komplext protokoll. Och denna tid ökar vid MCL 164 dB (vilket motsvarar område med mindre bra täckning). Effekten av sämre täckning är mest betydelsefull eftersom många IoT-enheter inte är mobila och om de råkar vara vid sämre täckning kommer de att ladda ur mycket snabbt!
Tabell 2: Jämförelse LoRaWAN vs NB-IoT uppkopplingstillstånd (50 Byte upplänk-payload)
Jämförelse av energiförbrukning hos LoRaWAN och NB-IoT
Tabell 3 visar energin det tar att överföra enbart 50 Byte payload och det är uppenbart att LoRaWAN har mycket lägre energiförbrukning än NB-IoT. Det bör också noteras att LoRaWAN har mycket lägre energiförbrukning i sovläge än NB-IoT på grund av att dess strömförbrukning vid sömn är 43 gånger mindre än NB-IoT. Eftersom IoT-enheten sover mesta delen av tiden, betyder det mycket!
Tabell 3: Energijämförelse LoRaWAN mot mobil IoT (Ensam 50 Byte upplänk-payload)
Effekten av strömförbrukningen på NB-IoT och Cat-M1 vid sämre täckning
Från ett IEEE-papper från forskare på Nokia, Telenor och Aalborgs universitet, beräknade de för landsbygdsutbyggnad att det kan finnas upp till 4% och 17% enheter monterade i svårnått inomhusbruk (se bild 2). Dessa enheter ligger vanligtvis i källaren (till exempel svåråtkomliga inomhus-vattenmätare i källare) och förlorar ytterligare 30 dB inomhus-genomsläppsförlust. För täta stadsmiljöer kan det dock finnas fler användare med dålig täckning. Normalt kan dålig signal förbättras genom utplacering av ytterligare små mottagare, men att intäkter från 5-10% användare inte motiverar investeringen.
Fig 3 visar effektkonsumtionen hos dessa enheter med dålig täckning för olika IoT-applikationsscenarier från en studie utförd av samma forskare och det är mycket tydligt att för användare i dålig täckning växer kraftförbrukningen för NB-IoT dramatiskt och kan vara storleksordningar högre än LTE Cat-M1. I dessa scenarier är det kanske inte kostnadseffektivt för en operatör att distribuera småceller, utan istället använda LoRaWAN för att utöka sin täckning för användare med dålig täckning med hjälp av LoRaWAN pico-celler till mycket lägre kostnad. Operatörer kan till och med använda LTE Cat-M1 som uppkoppling från LoRaWAN gateway som visas i figur 4 och erbjuder sålunda ett mycket optimerat sätt att kombinera LoRaWAN och mobil IoT.
Figur 2: Täckningsanalys av mobil IoT (NB-IoT, Cat-M1)
Figur 3: Genomsnittlig energikonsumtion per dag med MCL över 150 dB. (Landsbygdsscenario)
NB-IoT-enheter med dålig täckning drar 5-6 gånger så mycket energi som Cat-M1!
Figur 4: Kompletterande montage av LoRaWAN för att adressera täckningsproblem för mobil-användare med dålig täckning
Operatörer med både LoRaWAN och mobil IoT i sitt utbud har den bästa kapaciteten att nå alla IoT-applikationer
Batterilivslängd jämförelse för LoRaWAN och NB-IoT
Slutligen visar vi batteriets livslängd för LoRaWAN och NB-IoT för enheter som ligger nära, mitten och längst bort från mottagaren vid överföring av 50 Byte payload med olika frekvenser. LoRaWAN erbjuder 3-5 gånger bättre effektivitet jämfört med NB- IoT. Vi antar ett batteri på 5Wh med endast upplänkstrafik. De enheter som får störst påverkan med båda teknikerna är de med dålig täckning och dessa är ex. djupa inomhus-vatten/elmätare (med ytterligare 30 dB penetrationsförlust) som inte är mobila. Batteriets livslängd för enheter (speciellt med dålig täckning) är väldigt kritisk för flera IoT-applikationer eftersom dessa enheter vanligtvis är statiska och det kan vara mycket dyrt att byta batterier eller använda LTE-småceller, vilket påverkar avkastningen negativt för flera IoT-applikationer.
Figur 5: Jämförelse av batterilivslängd (NB-IoT kontra LoRaWAN) (50 Byte upplänk, ingen nedlänk)
Vad som är viktigast i ovanstående figur är den relativa effektiviteten hos LoRaWAN jämfört med NB-IoT snarare än absoluta tal!
Vilka batterier är möjliga för LoRaWAN och mobil IoT?
Fig. 6 visar strömens påverkan på användbar batterikapacitet. Toppströmmen för LoRaWAN är lägst på grund av chipets lägsta komplexitet, medan toppström ökar gradvis för NB-IoT och Cat-M1. Toppström påverkar mycket eftersom det påverkar batteriets livslängd allvarligt. Vi beskriver kortfattat olika typer av batterier på marknaden som passar tillsammans med lämplig teknik:
- LiPo (används i mobiltelefoner): Denna typ av batteri kan inte användas för långsiktig användning på grund av ~ 2% själv-urladdning per månad.
- Alkalisk: Den är användbar men internt motstånd ökar mot slutet av livslängden (kan inte klara hög toppström och lång livslängd) och vid låga temperaturer. Detta batteri kan användas för både LoRaWAN och mobil IoT, men i det senare fallet kommer det att dränera batteriet snabbare med hög toppström.
- Litium-tionylklorid (LTC): Detta batteri är dyrare, har självurladdning ca 3% per år (kräver 2x användbar kapacitet för 15 års livstid). Topströmmen påverkar dock även kapaciteten. Detta batteri kan användas för både LoRaWAN och Cellular IoT.
- Myntcell (bärbara): Det kan inte ge hög toppström så det är endast användbart för LoRaWAN och inte mobil IoT.
Figur 6: Effekt av ström på användbar kapacitet
(Från teknisk specifikation av ER14505M litium-tionylkloridspiralbatteri)
Så, vad är den bästa lösningen?
- Det finns inget rätt eller fel svar. Beslutet att använda rätt anslutning beror uteslutande på IoT-användningsbehov som varierar mycket.
- LoRaWAN passar bäst för applikationer som kräver att man skickar små nyttolaster (<50 Byte) inte mer än 20-30 gånger per dag. Exempel på sådana applikationer är smarta mätare, smarta lampor, övervakning av avfallshantering och så vidare och kräver extremt låg kostnad, låg effekt och mycket liten sällsynt nyttolast.
- NB-IoT passar bättre för applikationer som kräver högre genomströmning jämfört med LoRaWAN på bekostnad av högre effekt.
- edan har vi LTE-Cat M1 som har större kapacitet att bära högre nyttolast, men på bekostnad av högre strömförbrukning.
OBS! Denna artikel är endast en översättning från Actility och hämtar sin data från u-blox.com, vbn.aau.dk, semtech.com, lora-alliance.org och porta.3gpp.org.
Kontakta oss på 08-501 676 76 eller