@Roman-Dyzhyk

LTE-M is a good decision for multiple reasons:

• It supports HTTP(S) so I can directly reach my cloud endpoint without the need to build new CoAP/UDP proxies.
• Roaming. Virtual MNO’s like ibasis offer great coverage for LTE-M in many countries with a single SIM. This saves a lot of headache for global products. I have yet to see a similar offer for NB-IoT.
• Larger data bundles. Generally LTE-M data is cheaper and can be bought in larger quantities. This means I can ocasionally roll out an update without blowing up my data bundle.
• It supports most low power features (except RAI) and increased coverage benefits.

The biggest advantage I see today for NB-IoT is ability to use release assist (RAI). RAI has proven to be the biggest energy saver for simple TX only sensors and the fact none of the LTE-M networks or modules supports it is a major drawback for LTE-M. I understand this will be adressed in coming 3GPP releases but those are months if not years away. The fact that RAI is available today for NB-IoT means it will always beat LTE-M in energy consumption.

Hoi iedereen,

Ik vroeg mij af of het ook mogelijk is om downlink berichten te sturen naar een groep devices ipv een enkel device. Nu werkt het goed op basis van device ID, met een handjevol devices is dat nog te doen. Het wordt echter al gauw te veel bij meerdere devices. Is dit mogelijk? Zo niet, kan deze feature geïmplementeerd worden?

@Roalnd-Baldin Would be interesting to see how it compares to our measurements on modules. I also used this tool from Nordic Semiconductor: https://devzone.nordicsemi.com/nordic/power/w/opp/3/online-power-profiler-for-lte

@felixdonkers Volgens T-Mobile zelf is het guard band operation: https://docs.iot.t-mobile.nl/docs/general-settings

@niels-veul Hoi Niels. Verkeer tussen jouw applicatie en het T-Mobile netwerk is altijd in JSON formaat via HTTP(S). Verkeer tussen jouw modem en het T-Mobile netwerk kan UDP of CoAP zijn. Je zou het dus zo kunnen zien:

Modem <- [UDP] -> T-Mobile CDP <- [HTTP] -> Jouw applicatie

Dit betekent dus dat je nooit ‘direct’ over het open internet met een modem praat, zoals je LTE-M demo. Er zit altijd een proxy tussen, het CDP. Om te praten met het T-Mobile netwerk zul je dus een applicatie moeten opzetten die om kan gaan met HTTP.

@Mert-Karabagli hi, please check the following page for the correct settings https://docs.iotcreators.com/docs/general-settings

@afzal_m hi Afzal, maybe a good idea to provide commands for different modems? Because commands are always modem specific

@pieterhoenderken Hoi Pieter, als het goed is kun je hiervoor de register application API call gebruiken (in postman). Die stuurt namelijk vanaf het CDP een leeg datapakket naar je north application, voor jou dus node-RED. Als Node-RED correct geconfigureerd is zal deze een 200 (OK) response sturen naar het CDP. Een correcte connectie tussen de north application en het CDP is hiermee bevestigd.

@Timo-Siekmann Hi Timo, just to let you know, I have seen latency up to 30 seconds in extremely poor conditions (RSRP < -130 dBm). So what you are seeing is expected at those low RSRP levels. If you were to plot this on a graph you would see a correlation between ping and RSRP (and EC level).

@techniek Mooi experiment Henk.

Ik heb nog een aantal opmerkingen / vragen:

• Heb je bij iedere meting via het +NUESTATS commandado gekeken welk ECL niveau gebruikt werd? In mijn metingen zie ik soms ECL niveau 1 ondanks goede signaalcondities. Figuur 1 lijkt een ander ECL niveau te gebruiken, ik zie daar meerdere pieken welke ik op andere metingen niet zie.
• Klopt het dat een device dat UDP gebruikt langer blijft luisteren dan een device dat CoAP gebruikt? Het verbaast mij dat ik tussen +CSCON: 1 en CSCON: 0 een verschillend stroomfiguur zie voor beide metingen.

In je tekst schrijf je dit:

With the early release enabled the radio module will be forced to go into sleep (PSM) mode and not stay several seconds first in idle mode (where it listens for downlink messages).

• Volgens mij bedoel je hier connected mode. De interval tussen +CSCON: 1 en +CSCON: 0 wordt verkleint met het gebruik van assisted release, zie figuur 2. De idle mode is de interval tussen CSCON:0 en NPSMR: 1 en wordt dus bepaald door de T3324 idle timer, zie ik ook deze foto van rohde en schwarz:
  

• Aanpassen CPSMS parameters. Is het al mogelijk om de PSM timers aan te passen op het device? T3324 (idle) en T3412 (TAU) zijn configureerbaar via AT+CPSMS maar het netwerk lijkt dit nog niet te ondersteunen.

• Het gebruik van de connected mode lijkt een wel/niet verhaal. Óf mijn device blijft 20 seconden luisteren naar downlink berichten, of hij doet dit niet. Kan ik deze tijd niet variabel maken? Een device hoeft in heel veel gevallen niet zo lang te luisteren, enkele seconden volstaat.

• Heb je ook gekeken wat er gebeurt als we PSM niet activeren? Het device blijft dan periodiek pagen. De interval van de pages (ongeveer 10 seconden) heb ik tot nu toe nog niet kunnen verklaren, ik denk dat het iets te maken heeft met eDRX aangezien het device dan in idle modus blijft.

• Wat is precies het nut van de pages? Kunnen we op deze momenten downlink berichten ontvangen, zo ja, lukt dit dan zowel met UDP als met CoAP?

• CoAP lijkt meer energie te verbruiken dan UDP. Waarom zouden we dan alsnog CoAP gebruiken? Wat krijgen we terug voor dit (bijna dubbele!) stroomverbruik?

• Hogere ECL en een hoger zendvermogen is niet meegenomen in de metingen. Het is daarom niet met zekerheid te zeggen dat de data in iedere situatie geldig is. Zeker in situaties met slechtere signaal condities waar ECL: 2 optreedt zal de batterij minder lang meegaan dan in de tabel staat.

• Ook een grotere pakketgrootte heeft invloed op het stroomverbruik. Er kunnen namelijk 512 bytes verstuurd worden in een enkel uplink bericht. Misschien interessant om hier ook nog naar te kijken.

Also on the network side we will see improvements with 3GPP release 14, which include:
a new NB2 modem category with double data rates,

a new power class of 14 dBm to support coin-cell battery operation e.g. for wearables,

extentions on the early release, with AS release assistance indication,

And general capacity increases on the number of devices supported on the network…

• Het proces van het uitrollen van features verward mij nog een beetje. Als ik naar de roadmap kijk dan zie ik geen van de features die je nu noemt. Wanneer is het T-Mobile NB-IoT netwerk release 14 ‘ready’? 3GPP release 14 is namelijk al frozen in juni 2017: http://www.3gpp.org/release-14

Al met al is het stroomverbruik nog steeds een ingewikkeld verhaal met veel factoren die meespelen.

@HaraldNaumann With your incredible bias towards LTE I do not trust your results anymore

@HaraldNaumann This is exactly why I never ask you, because you immediately try to sell me things

@HaraldNaumann Yes, but when we want the exact numbers you tell us to buy your cookbook or attend your webinar. So how can we be educated then?

@Alessandro-Parmigiani

Is the inactivity timer always containing C-DRX cycles like in the picture?

It should. Unless C-DRX is disabled by the network, which appears to be the case. This is strange because it saves power. Have you tried to activate PSM and CSCON URC’s? That would help you in debugging.

From here you can see the DRX cycles after the connection mode. This is why I’m thinking that the inactivity timer is contained between the actual data transmission (spikes on the right) and the beginning of the DRX cycles

Yes I think so as well. You can get a lot more info if you enable aforementioned URC’s and hook up the serial debug port to the otii serial input.

@Alessandro-Parmigiani Do you have the same picture including time/current scale? It would be very helpful to figure out what is going on

@Alessandro-Parmigiani

@Alessandro-Parmigiani said in RRC inactivity timer duration for NB-IoT and LTE-M:

• From your experience, is the RRC inactivation time related to the number of LTE frames, in this case 5 s ~ 5.12 s, therefore 512 frames or can it also be uncorrelated?

I do not know. The module normally does not expose such details. You would need to have a network simulator or a module which supports extensive tracing on L1/L2/L3 (like the Sequans for example).

• Is the RRC inactivation time ending where the spikes on the right begin? Or is the transition to idle mode also included?

I believe the large spikes on the right signal RRC release. The very low power level afterwards suggests PSM mode. Your module also seems to be skipping the C-DRX phase, according to power consumption it is continuously in receive mode… I wonder why that is?

@Alessandro-Parmigiani Hi Alessandro. I have experimented a lot with this on various networks/modules and in general my experience is that RRC inactivity cannot be controlled by the device. The only succesful way I have found to circumvent the RRC inactivity period is to use Release Assist.

However, release assist has some downsides. I have found that it only works on NB-IoT, I have not found any LTE-M modules/networks that support it. The implementation also highly depends on which module you are using. Release assist does lead to significant power saving, in some specific cases (like uplink only nodes) more than 90% of power can be saved.

In general it is very hard to visualize the RRC timer. The best method I found is to activate the +CSCON URC. This will tell you when the modem has left RRC connected state.

However, I do not know the specifics for the T-Mobile network. I am just a user

@Crowdsourcer I don’t know. BQ24195 is pretty solid. Probe it if you need to.

@Crowdsourcer That can be many things. Maybe the LiPo is bad, has too little charge or has too low capacity/current capability? I would suggest to test using a bench power supply and try to steadily lower the voltage. If that also doesn’t work then perhaps the module is faulty

@bertrik Hi,

My perspective:

1. No, for powerconsumption the amount of data doesn’t matter at all. I have sent KB’s in one go and the change in power consumption vs a payload of a few bytes was practically 0, although it does get worse under poor signal conditions. The overhead of signalling with the basestation will consume the majority of the power. I believe you can send up to 512 bytes in a single packet…