HPPLMN search - Please consolidate advice.

[Achim Kraus]

Since being aware of the power consumption of the "HPPLMN searchs", I'm struggling to see the right strategy.

What makes me really wondering, is that the first questions are raising already two years ago:

nrf9160 psm and hplmn search on roaming sim cards

unfortunately, the answer is missing there.

3 months ago in lte_lc_nw_reg_searching and lte_lc_modem_evt_search_done the recommendation was to lock the PLMN.

2 weeks ago in measured scanning procedure a few minutes after connection establishment the recommendation was "use only home network".

Using "only home network", really? Isn't the downside of that, that SIM cards of MVNOs are always roaming?

Therefore I would really appreciate, if Nordic spend some more time in investigate, what users should do.

The first question 2 years ago, mentions, that other modems offers to disable the HPPLMN search. Maybe that's considered.

[Achim Kraus]

I received a very interesting research paper about such HPPLMN search and the pros and cons.

That paper describes, that it's not only about a specific PLMN, it's also about the signal strength for that.

So one additional question:

Does the nRF9160 start a HPPLMN search also, if it's already connected with the highest prio HPPLMN, but the signal strength is less than -85 dBm?

[Charlie]

Hi Achim,

Can you share the link to the paper if it is publicly available? or send me a private message so that I can share it internally with our team.

As you know, our development team intend to keep the current state of the HPPLMN search design on the nRF9160 modem now. I can not promise you any change in the future, but it is better to have more discussion on this topic, so it will help both the user and developer to understand HPPLMN search and how to optimize it further.

I will return back for your question later.

Best regards,

Charlie 

[Achim Kraus]

Unfortunately, it's not public available. If it gets public available, I will update you.

> I will return back for your question later.

Thanks a lot! I really appreciate your information.

[Charlie]

Hi Achim,

Does the nRF9160 start a HPPLMN search also, if it's already connected with the highest prio HPPLMN, but the signal strength is less than -85 dBm?

No it doesn't. The signal strength of the current cell is not considered, but when searching for higher priority PLMN only cells with good enough signal strengths are considered. This is according to 3GPP, too.

Best regards,

Charlie

[Achim Kraus]

"As you know, our development team intend to keep the current state of the HPPLMN search design on the nRF9160 modem now."

"so it will help both the user and developer to understand HPPLMN search and how to optimize it further."

One very easy first step would be:

- add an event for such HPPLMN searchs (see lte_lc_nw_reg_searching and lte_lc_modem_evt_search_done ), that will make it much more obvious, and the users will not longer asking indirect about the extra power consumption (which may be also caused by other topics.)

- report also the SIM data used by the modem, e.g. the interval and the highest PPLMN. (I added that in the meantime by reading the SIM card in my app).

Both will help the users to understand, if they are affected or not.

My experience so far:

iBASIS: 20h, no HPPLM

flolive: 10h, no HPPLM

1nce: 2h, HPPLMN 26201

I need to retest and verify my observed behavior, that will take some time, because I currently would like to focus on an other project (Eclipse/Californium), but I hope I can spend some time at least at the begin of next year.

What I observed:

- my nRF9160 still records such HPPLMN searchs, even if the HPPLMN is already chosen. That may be caused by the signal level, if that's considered.

- using "%XDATAPRFL" and "%REDMOB" both limits the HPPLMN search, in difference to your information. For me, this would be brilliant.

I mainly focus on "long term, static located, battery powered sensors". If I'm able to reduce the HPPLMN searchs, then that works for me. Please consider: using the right protocol (CoAP /DTLS 1.2 CID) really enable user to run such use-cases. My current results even with the Thingy:91 are very promising.

77-17:54:04 [d-hh:mm:ss], Thingy:91 v0.5.99, 0*1791, 1*74, 2*1, 3*0, failures 1
3990 mV 73% battery (low-power)
!Network: CAT-M1,roaming,Band 20,PLMN 26201,TAC 67B9,Cell 01CC2B03,RSRP -94 dBm
!PSM: TAU 86400 [s], Act 8 [s], Released: 10851 ms
Stat: tx 934kB, rx 126kB, max 535B, avg 289B, searchs 82, PSM delays 0

The Thingy:91 is now running for 77 days. It uses PSM and exchanged a encrypted message of about 400 bytes every hour. The battery reached 73%, the amount of data is about 1.1 mBytes.

If you add a "60s 30mA every 2h", then this doesn't work.  

In my experience, the MVNOs are not trying to control the costs by such HPPLM lists, they control that by subscriptions. There also MVNOs, where your subscription is a "general global" one, but even there, I don't see, that a HPPLMN search really helps. 

And the energy consideration depends then a lot from the assumed communication model. If the idea is to search and then use the HPPLMN for many many messages, then there maybe a win. But if you exchange two messages in 2h (e.g. each about 100mC in bad condition, maybe 20mC in perfect conditions), and then a HPPLM search takes about 60s (30mA => 1800 mC) then that search task will not pay off.

So, let's see, what the answer about the consideration of the signal level is.

Maybe a compromise would be, to offer a way to overwrite the SIM card's interval with values in a range from "2h to 240h". 

Anyway, adding the functions above, would make it transparent and with that I guess, you will receive much more useful user feedback.