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.

[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.

[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. 

[Charlie]

Hi Achim,

Thanks for sharing your experience and observation. I understand your points and your advice makes sense.

I will forward this to our modem team to see if we can do something in the future.

Best regards,

Charlie

[Charlie]

Hi Achim,

Just get more comments from our modem developer, and we will have more internal discussions on this topic.

Modem event of HPPLMN searches could be possible, but the only thing application could do when the HPPLMN search begins is to deactivate modem. I don't see any other way. That would mean extra signalling to network (Detach and then a new Attach). Also, the same cell may not be even available anymore, which is why searching might be needed anyway. Of course, usually this is not the case with stationary devices. Anyway, deactivating modem when notification of started HPPLMN search is received is not always the optimal either. One cannot either predict how long the HPPLMN search takes, it could be just a few seconds.

I think the value of HPPLMN search timing is already readable via AT command. Might be good idea to add the command to some document, as it requires knowing specifically correct file IDs etc.

If UE is already camped on a cell of the highest priority PLMN in current country, there is no HPPLMN search regardless what is the signal strength of the current cell as long as it still fulfills cell suitability criteria (which is another topic). But if the HPPLMN search is initiated (i.e. the current PLMN is not the highest priority PLMN in current country), the signal strengths in HPPLMN search results are considered so that it needs to be over certain threshold for being suitable to be selected as higher priority PLMN.

%XDATAPRFL and %REDMOB do not limit the HPPLMN search. The latter one has nothing to do with it, but to be exact the data profile has minor affect: When UE has lost the cell or is in limited service (data transfer not possible) UE will search for suitable cell periodically (according to %PERIODICSEARCHCONF). If the HPPLMN timer expires between the periodic searches (while not searching), modem will not immediately trigger the HPPLMN search but waits until it is time for the next periodic search. So, in normal operation there is no affect.

Operators have often separate roaming agreements with other operators. Some agreements cost more than another. This one reason why the operators have prioritized the roaming networks in certain order - there may be other reasons too (alliances etc.). Anyway, by configuring the operator HPPLMN list and the HPPLMN search periods to SIM card, operator can control how often device must search for other PLMNs that are "better" from the operator's perspective.

Overwriting SIM card's HPPLMN search configuration is not possible. That is something that only the operator is allowed to do.

I understand the problem, this is not optimal. I'll still have some internal discussions whether there is anything we could do while still being 3GPP compliant.

Best regards,

Charlie

[Achim Kraus]

> Modem event of HPPLMN searches could be possible, but the only thing application could do when the HPPLMN search begins is to deactivate modem.

That's not my intention. My intention is to make this more visible to the users. Currently only users, which use a PPK (or something similar), are aware of that HPPLMN search. Once the event is available, user may be easier able to see, how much time (and so energy) that takes. If even the reason/trigger is added as parameter, then also irritations (as in my case, because my experience differs from the information here) may be reduced. I didn't want this event to switch off the modem. If someone plans to do that, then it will just be switched off, even before RRC Idle and so no HPPLMN search at all will happen.

> I think the value of HPPLMN search timing is already readable via AT command. Might be good idea to add the command to some document, as it requires knowing specifically correct file IDs etc.

Sure, someone can use the "AT+CRSM". I would prefer to have these values easier visible by a "high-level API". It's the same argument: if users know, how their SIM-card is configured, the behavior gets transparent and results in less surprisingly empty batteries.

> %XDATAPRFL and %REDMOB do not limit the HPPLMN search.

Once I have some more time, I will provide the traces. In my experience, the modem search for a HPPLMN even if that is already active, and using %XDATAPRFL (for now I only used it together with %REDMOB) increases the interval and so less HPPLMN searchs are used. Therefore I think, add the API the read the configuration values the modem is using, and report the event HPPLMN search including the reason.

> Overwriting SIM card's HPPLMN search configuration is not possible. That is something that only the operator is allowed to do.

Sorry, I think the developers stick to the wrong arguments! This HPPLMN search was introduced long ago for Smartphones by google. That kind of devices have a very different "communication profile". There the trade off between the cost for a search and the later costs, when transfer pictures and websites is completely different. I'm pretty sure, just no-one there did reconsider the effects of such a HPPLMN search for IoT devices. At least not for really rare communicating devices.

> 3GPP compliant.

Then explicit state, that overwriting the SIM card configuration is not 3 GPP compliant and violating it may result in being blocked by the M(V)NO. In the end, it's anyway the (M(V)NO, which need to decide what should happen. The users will just then go for the SIM cards, which offers, what the users need, once it gets transparent.