• State Not Answered
  • Replies 26 replies
  • Subscribers 63 subscribers
  • Views 2581 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 298847
Options

PSM active time not Correct

Hkhan7861

Good Day

I have enabled power saving on my nrf9160dk and am using NBIOT.  In doing so I found that there was a 60 sec offset to what I selected and what I wanted the active time to be.  IN doing some research I came across this question :  https://devzone.nordicsemi.com/f/nordic-q-a/87330/nrf9160-not-setting-requested-active-time 

The device is probably stuck in RRC idle for 60s before entering power saving mode.  This answer was never really solved and wanted to know if anybody found a way around this or if I will have to contact my provider?  If so, what would i need them to changed?

Kind regards,

Hassan

Parents Reply Children
  • 0 in reply to Achim Kraus

    Thank you !

    I am trying to contact my provider as we speak and we cannot shorten that time I will be moving toward a UDP based protocol.  Again, thank you for the assistance.

    Kind regards,

    Hassan.

  • 0 in reply to Hkhan7861

    Just to mention:

    UDP for it self lucks "reliability". So you usually need a protocol on top of that, which implements something as "retransmission". CoAP/RFC 7252 is one common solution. You may combine it with DTLS (for now 1.2) and hopefully the merged DTLS 1.2 extension "Connection ID" gets available for zephyr as well. It was merged these day in mbedtls and will take some time until it's available in zephyr.

    Just in the case, you want to have a "preview", you may also have a look at my demo-client (using the Eclipse stack Californium for the server side, and tinydtls on the nRF9160 device).

    zephyr coaps client

    As addition option, you may check, if

    Access stratum Release Assistance Indication instead of Control plane Release Assistance Indication works for you. It requires your network operator to support Release 14 features. using SO_RAI_NO_DATA e.g.3s after you finished your communication, may have a chance. I had no success using SO_RAI_NO_DATA , but according that comments, there should be no general issue.

  • 0 in reply to Achim Kraus

    Good day 

    I tried what you said using "SO_RAI_NO_DATA" and still wasn't successful.  Due to the device needing to be extremely low power, a UDP based protocol is going to make more sense i think.  Have you any experience with lwm2m? if so, do you know if producing your own server is possible and worthwhile? 

    Thank you in advance,

    Hassan.

  • 0 in reply to Hkhan7861

    > Have you any experience with lwm2m? 

    That's a couple of years ago. Lwm2m uses CoAP, and I have much more recent experience with CoAP (and DTLS 1.2 CID).

    > if so, do you know if producing your own server is possible and worthwhile? 

    Let me split that:

    - developing an "own server": I think, the efforts are underestimated. If it's not clear, that you only need a smaller lwm2m subset, I think you will need to spend much more time than expected. It depends also on the programming language you want to use.

    - run an "own server": there are some open source projects (e.g. eclipse/leshan), but AFAIK, they don't offer a "out-of-the-box" service, so that may also end up in developing something on your own. It also requires knowledge about running such an UDP service. 

    So, I guess, it will take too much efforts. At least to begin with lwm2m, I would rather start with one of the offered services and see, how that develops.

    (I'm one of the developers behind "Eclipse/Californium", a very common CoAP/DTLS 1.2 java implementation, also used for leshan. Therefore I'm mainly using Californium to run my own services.)

Related