Posts made by felixdonkers

@andre-rodenburg volgens onze ervaring zijn deze parameters (nog) niet instelbaar omdat dat door het T-Mobile network (nog) niet ondersteunt wordt, zie ook treat: https://forum.iot.t-mobile.nl/topic/178/current-measurements

To enable high-end product development based on the NB-IoT technology it is essential to know and clearly understand the minimal set of common specifications that the global / multi-MNO NB-IoT network will deliver. Despite searching and asking for such minimum set of specifications, I have not yet found any decent definition of what to expect from NB-IoT. The information so far is limited to the general marketing buzz; e.g. low battery consumption due to extra power safe modes, increased coverage due to extra link budget, etc. At the same time I notice (no proof, just a feeling):

• MNO’s asking customers what they would like to be implemented
• an agile approach to implement various features without clear roadmap indicating what to expect when and with what performance
• a trend that features are implemented without global / multi-MNO coordination on common features and performance to ensure proper interoperability (which goes beyond roaming)

This is likely to cause serious product development risks; e.g. will products developed and launched “today” will still work in exactly the same way in the years to come (most products have a life time of at least 7 years), and will products developed and tested in the Netherlands will work in the same way when used outside the Netherlands. The danger is that this approach will lead to “50 shades of NB-IoT”.

I would like to see clear specifications from MNO’s on what to expect from NB-IoT. At the same time, to answer requests from the MNO’s I created a preliminary list of minimum features that I think are important for ‘every’ NB-IOT based product. See below. I invite other developers to comment on this; either make corrections or provide additions. Hoping for an interesting treat .

1. Device shall be able to send small packages (e.g. with measurement data) on a regular interval, e.g. every minute, hour, day, etc.
2. Device shall be able to send occasional alerts, which always is a small package. Delay of transfer towards our cloud is very critical (asap, tbd).
3. The device shall be able to send large files (few MB, e.g. with aggregated measurement data). This happens occasionally (e.g. once a week/month/year).
4. The device shall be able to receive medium size packages (<100kB), e.g. for device settings. This happens occasionally (e.g. once a week/month/year).
5. The device shall be able to receive large size packages (<10MB), e.g. for firmware updates of modem and/or product. This happens very occasionally (e.g. once every quarter/year).
6. The network shall support UDP and allow direct connection our preferred cloud
7. The network shall support interoperability. I.e. a device tested and released in the Netherlands should perform equally when abroad and when connect to the various NB-IOT roaming partners. E.g. wrt speed, QoS performance, battery consumption, …
8. It shall be publicly listed what requirements a device must fulfill to be allowed to connect to the (global) NB-IOT network, e.g. GCF, PTCRB, operator certifications, etc.
9. It shall be publicly listed which modules (brand, type and FW version) have been approved/certified to connect to the (global) NB-IOT network
10. It shall be publicly stated that all (new) NB-IOT features that will be added shall be backward compatible without loss of performance
11. Same NB-IOT features as specified by 3GPP that are not in this list yet ?
12. …

Note: unless stated otherwise, all data transfers shall be:

• with minimum delay, at least within 3GPP NB-IOT spec
• at highest possible speed, as defined by 3GPP NB-IoT spec
• with minimum power consumption for long battery lifetime
• with good QoS, so no loss of data

Main questions:

• feature set: will all these requirements be supported by default. And if not, which requirements need additional SLA’s ?
• roadmap: when will all these requirements be supported ?
• performance: for each feature, what’s the minimum performance that we can expect ?

@Afzal_m Testen gedaan met
1.SARA N211 02B-00
2.06.57,A03.02 en 06.57,A07.03
Cell tower en postcode stuur ik vanavond per PM toe.

@afzal_m Deze vraag kan ik alleen in algemene zin beantwoorden. Ik zal er een separate treat voor opzetten zodat ook anderen hun input kunnen geven.

@afzal_m From recent experiments we noticed that automatic cell hand-over seems to work now, see separate treat on “Interessante RSSI metingen in de auto”. I.e. the system (modem + network) seems to be able to connect to a ‘better’ cell when moving around, even at high speed (80km/h), without intervention from the application software on the crowduino.

Still interesting to learn:

• Will this also work abroad and with other MNO’s (NB-IOT interoperability question) ?

• What if connection is lost after all, e.g. due to a bad signal, how to detect that in a reliable manner? Using parameters CSQ=99 or RSRP=0 does not seem to be reliable. Is there a white paper that describes a solid solution?

• NB-IOT provides various parameters to minimize power consumption; T3314, T3324, etc. I’m wondering how to apply those parameters in the most efficient way. And also what the impact is, e.g. on responsiveness, when changing these parameters. Is there a white paper that demonstrates adequate use of these parameters. And when will they be supported (roadmap question), as experiments have shown that these parameters currently seem to have no noticeable effect.

@andre-rodenburg Leuk artikel, is vergelijkbaar met onze opstelling. Een verschil, wij hebben het display niet boven op de SODAQ stack geplaatst maar ernaast. Da’s beter voor GPS ontvangst. Verder is het zeer waarschijnlijk dat de SODAQ hardware en de antenne niet gecalibreerd zijn mbt RF performance. OOk het NB-IoT network is volgens mij nog niet vrijgegeven. Daarmee zijn alle metingen slechts indicatief en kunnen er geen echte harde conclussies aan verbonden worden.

Mbt RSPS=0 (is inderdaad vergelijkbaar met CSQ=99); ik vraag me af of er op dat moment inderdaad geen signaal is. Mijn plaatjes zijn daarin misschien wat misleidend. De route die we gereden hebben is vanaf het centrum van Eindhoven via noord naar west en daarna via de snelweg naar de High Tech Campus in Eindhoven-zuid. Inde stad was de snelheid nooit hoger dan 50 km/h, op de snelweg niet hoger dan 80km/h . In de grafiek is te zien dat de samples met RSRP=0 alleen aan het begin voorkomen, in de stad dus en niet op de snelweg. De antenne dichtheid is in het centrum prima, geen signaal zou betekenen dat er wellicht black spots zijn (vanwege reflecties ofzo). Langs de snelweg (knooppunt de Hogt), zijn er inderdaad minder antennes, maar daar hadden we wel bereik. Welliswaar met ECL=2, maar toch…

P.s. ben benieuwd wel tool je gebruikt om de plaatjes met antenne posities te maken .

Verder hebben we nog metingen gedaan in diverse parkeergarages in de stad. Helaas hebben we niet kunnen vaststellen dat indoor coverage beter is dan met reguliere 4G. Referentie was een Samsung Galaxy met T-Mobile abonnement. Heeft iemand hier al ervaring mee ?

Kleine toelichting: een aantal keer wordt RSRP waarde = 0 uitgelezen. Kennelijk heeft het modem op dit moment geen valide meetwaarde beschikbaar. Nog onduidelijk is hoe dat komt of hoe dat voorkomen kan worden.

Zoals beloofd hierbij een experiment uit EIndhoven.

• Plaatje 1 geeft de RSRP waardes (vergelijkbaar met de RSSI waarde) als kleurcode weer op de landkaart

• plaatje 2 geeft dezelfde RSRP waardes weer als grafiek

• plaatje 3 geeft de ECL waardes weer op de kaart. Dit is volgens mij nog het meest interessant. De ECL waarde geeft immers weer hoeveel ‘moeite’ het modem moet doen om een bericht te kunnen versturen:

  • ECL=0: De output power van de transmitter wordt automatisch bijgeregeld.
  • ECL=1: De output power van de transmitter staat op maximal vermogen (23dBm) en berichten worden een beperkt aantal maal verstuurd waardoor de kans op succes groter wordt.
  • ECL=2: De output power van de transmitter staat op maximal vermogen (23dBm) en berichten worden een groot aantal maal verstuurd waardoor de kans op success nog groter wordt.

P.s. Ik hoor graag als iemand een betere uitleg heeft voor de betekenis van ECL.

@andre-rodenburg Opvallende verschillen, overigens lijkt dit niet afhankelijk te zijn van de firmware versie. Ook met de (06.57,A03.02) versie had ik dezelfde effecten. Mbt het 2 uur disconnect fenomeen, ikzelf gebruik voor elke Tx een CGATT om te kijken of er nog verbinding is, zo niet dan reset ik het modem en registreer ik opnieuw. Da’s inderdaad niet zo batterij vriendelijk :-(.

@pieterhoenderken NB-IoT supports geo-localisation based on the network itself. At this moment only cell-ID can be used, accuracy of course depends on the cell density. As of release 14, NB-IoT will also support triangulation which is much more accurate (<100mtr). Don’t know what’s currently and will be supported by T-Mobile NL.

Nog een meting, nu met N211 met nieuwe uBlox firmware (06.57,A07.03). De intervaltijd tussen opeenvolgende berichten is nu 60sec. Deze keer komen alle samples in de juiste volgorde binnen en ontbreken er slechts 2 van de 1225 samples (0,16%). Wel zit er nog grote spreiding op het tempo waarin de samples ontvangen worden. In het eerste plaatje is te zien dat de variatie op het interval typisch kleiner is dan +/-20 sec. Op het 2e plaatje is te zien dat er soms grote uitschieters zijn, met als grootste uitschieter bij sample 716. Daar werden een 8-tal samples ca8 minuten gebufferd en daarna alsnog als burst verstuurd.

@afzal_m Krijgen we op 9 maart ook de volgende vraag beantwoord? Wanneer worden de MVP specificaties voor het NB-IoT netwerk gehaald, zowel qua (minimale) functionaliteit en performance, opdat we ook producten kunnen gaan ontwikkelen die zich overal ter wereld hetzelfde gedragen ?

@andre-rodenburg Leuke resultaten, wij doen op dit moment een soortgelijke meting in Eindhoven. Zodra ze bekend zijn zal ik ze publiceren.

P.s.

1. 100 [km/h] is inderdaad wat snel, volgens mij ligt dat op de grens van wat volgens de standaard haalbaar is (nb. CAT-M1 ondersteunt tot 300 [km/h]).
2. waarom gebruik je CSQ en niet de informatie in NueStat (RSRQ) ?

We’re doing an experiment where our wearable NB-IoT device is ‘walked’ around the village by a test person. We want to sent (Tx) a measurement every minute. Obviously, the device will see different cells when walking around. To save battery, we do not want to reregister to the network every Tx. Instead we would like to stay connected to one cell as long as possible, but detect if the current cell is out of range and then connect to the nearest cell. Question: how to detect when a signal is lost? CGATT or COPS do not seem to provide reliable information for this. Any suggestions ?

@nhan-nguyen use the ‘OpenSignal’ app available on iOS and Android. It will gave cell id and LAC code and show the cell to which your phone is connected. This is probably the same cell as for your NB-IOT device.

Kleine aanvulling; in tegenstelling tot eerder bericht treedt het effect ook op bij een N200. Dzw ontbrekende samples, samples in verkeerde volgorde, en veel jitter op de aankomsttijd van een berichtje. Ter illustratie van het laatste hierbij nog een grafiekje dat de jitter illustreert. Weergegeven is de intervaltijd tussen twee opeenvolgende berichten. De berichten worden elke 2,5 minuut verstuurd, om de 150 sec dus.

Vannacht een soortgelijke test gedaan met een tweetal SODAQ NB-IoT boards; eentje met een uBlox N200 en eentje met een N211 modem. Beiden modem bevatten 06.57 firmware (AT+CGMR) en in beide gevallen staat scrambling uit. Het cell-ID = 6405223 (AT+NEUSTATS). In beide gevallen draait exact hetzewlfde programma op de Crowduino (op wat AT-syntax verschillen na vanwege de verschillende modems).

De test is eenvoudig; elke 150 seconde (2.5 min) wordt een bericht van 46 bytes opgestuurd. In die payload zit een teller die bij elk bericht met 1 opgehoogd wordt en een timestamp (msec van de MCU) waarop het bericht verzonden is. In de log bij de ontvanger wordt daar nog een server_timestamp aan toegevoegd zodra het sample bij mij ontvangen wordt. De totale test duurt ~18,5 uur.

Wat opvalt is dat het verzenden met de N200 prima verloopt. Alle samples komen keurig en ook op de juiste volgorde binnen. Met de N211 gaat het minder goed. Dwz regelmatig (om de 1 a 2 uur, geen vast interval) valt de verbinding weg en moet het device opnieuw geregistreerd worden. Na 7.5 uur (180 samples) lukt het helemaal niet meer om verbinding te maken. Wat ook opvalt is dat er regelmatig samples ontbreken en soms ook niet in de juiste volgorde ontvangen worden.

Bovenstaand figuur illustreert dat. Het horen 2 rechte lijnen te zijn; de ene geeft de tellerstand weer, de andere de delta van de tellerstand tussen 2 opeenvolgend ontvangen samples. Positieve waarde betekent dat er een gat in de tellerstand zit, een negatieve waarde betekent dat er oude samples ontvangen worden. Met name vanaf sample 150 (na 6.25 uur) lijkt er iets goed fout te gaan.

Het verschijnsel is niet nieuw, ook in eerdere treats is er al over gesproken. Ben ewrg benieuwd of deze problemen in de volgende netwerk release opgelost gaan zijn.

@andre-rodenburg We used the SODAQ board, cut one of the traces to the uBlox modem and put a 1 ohm resistor in series to measure the current consumption. Since the SIM is also powered by the modem, that current is also included.

@melvinitude Wij hebben onlangs nog getest met 512 bytes en dat werkte prima, zowel upload als download. Is ook conform de NB-IoT spec.

Is there a datasheet of the SIM cards provided by TMNL? I would like to know the current consumption of the SIM.

Today we’ve been doing some current measurements using an SODAQ NB-IoT board with an uBlox SARA-N211-02B (with v6.57 firmware). We notice some ‘strange’ behavior that might be related to the network. See the two pictures below. The first one is when transmitting 32 bytes, this is what I observe:

• sleep mode (~3 seconds)

• connection mode (~200 msec)

• transmit mode (~200 msec)

• receive mode (~22 seconds)

• idle mode (~1 second)

• eDRX mode (~27 seconds)

Now with 512 bytes I see a lot more, which a cannot explain:

• connection mode ? (from t=~3 until t=~23 seconds)

• transmit mode ? (from t=~24 until t=~35 seconds), i.e. 11 seconds for 512 bytes?

• a second transmit mode ? (from t=~56 until t=~58 seconds), why ?

Can this 512 byte transfer behavior be explained ?

Nadere bestudering van de datasheet van een bekend NB-IoT modem leert dat de responsetijd op network commando’s (zoals CGATT) tot 3 minuten kan duren. Da’s wellicht een spec in 3GPP NB-IoT standaard.

Interresante test, ik ervaar hetzelfde maar heb nog geen uitgebreide testen kunnen doen. Ik heb wat aanvullende vragen:

• Welk AT commando is het meest tijdrovend, bijv wachten op AT+CSQ of AT_CGATT? of … ?

• is er nog een afhankelijkheid van de signal kwaliteit (bijv vanwege afstand tot cell / indoor) ?

• is er nog een afhankelijk van tijdstip van de dag (bezetting van de cell) ?