HPPLMN search - Please consolidate advice.

RE: HPPLMN search - Please consolidate advice.

Achim Kraus — Wed, 14 Jun 2023 19:11:35 GMT

With mfw 1.3.5, the modem will not longer search for the 90140.

See mfw_nrf9160_1.3.5_release_notes.txt:

- Fix for higher priority PLMN search. Global PLMN IDs (start with digit 9) are no more
automatically considered to be suitable for higher priority PLMN search and selection.

RE: HPPLMN search - Please consolidate advice.

Achim Kraus — Tue, 20 Dec 2022 16:41:38 GMT

Thanks, I read the answer on the other ticket.

RE: HPPLMN search - Please consolidate advice.

Achim Kraus — Tue, 20 Dec 2022 16:17:03 GMT

Hi Charlie,

thanks a lot to all, who have answered.

Beside of the general question, I have already a specific question about a specific case.

> I suspect there is a misunderstanding what is actually the highest priority PLMN at that point.

Agreed, yes, therefore an event with the reason helps to understand, which PLMN is considered to be the HPPLMN. Not that in some cases the search is caused not by that misunderstanding.

So, please check the trace in hpplmn search - reason unknown .

RE: HPPLMN search - Please consolidate advice.

Charlie — Tue, 20 Dec 2022 16:03:18 GMT

Hi Achim,

Comments from our modem developer:

1. I already commented the visibility of HPPLMN search. For debugging reasons it might be good idea to be notified by modem, but not that much for the product design (extra signalling etc.).

2. I still stick in the fact that %REDMOD has nothing to do with HPPLMN search (it affects to totally different protocol than EMM which controls HPPLMN search). And %XDATAPRFL affects only when modem does periodic searches (when not camped on cell or camped on limited service cell) - does not affect while modem is in normal service. No need for modem traces to confirm this.

3. I can assure that modem does not search for PLMN which it is already camped on. If there is a search, it is for some other PLMN. I suspect there is a misunderstanding what is actually the highest priority PLMN at that point.

4. I'm pretty sure, just no-one there did reconsider the effects of such a HPPLMN search for IoT devices.

Yes, the HPPLMN search was originally designed for smartphones, but please note that the 3GPP 23.122 chapter "Automatic and manual network selection modes" specifies the search periods and has taken IoT devices into account: for smartphones the unit is 6 minutes whereas for IoT devices the unit is 2 hours. The actual HPPLMN search period is the unit x value T. Therefore, the minimum search period for smartphones is 6 minutes and for IoT devices 2 hours. If we followed the smartphone part, the search period would be 6 minutes instead of the current 2 hours. So 3GPP has considered IoT devices in this, but I agree that not enough.

5. 3GPP compliance & HPPLMN configuration at SIM card. As I have said, HPPLMN configuration cannot be modified by anyone else than the operator. 3GPP 31.102 chapter "EFHPPLMN (Higher Priority search period)" specifies that admin PIN code is needed for updating the file. There is no question about it.

We have a clear understanding what is the problem. I don't think there is more than I can do for this. As it has already been mentioned, changing this would violate 3GPP. Nordic has to consider different aspects such as acceptance tests, conformance tests, operator relations etc. Therefore, continuing the discussion with a modem developer does not seem beneficial at this point.

I would still like to remind that HPPLMN search would be avoided with manual network selection mode. This would work like this:

Activate modem in automatic network selection mode
Wait for modem to Attach
Change the network selection mode to manual (the PLMN modem just Attached).

Then if modem notifies that cell has been lost or UE is in limited service (CEREG status is not roaming or home).

Change the network selection mode back to automatic
Wait for modem to find service again
Change the network selection mode to manual (the PLMN modem just found).

Hi Achim, at this time point, I have included both our modem developers and PMT team in this discussion. All the questions have been answered and a couple of times some of them. I do not think we will have any change to the current HPPLM search method now. I will let you know if we have any improvements in the future.

Best regards,

Charlie

RE: HPPLMN search - Please consolidate advice.

Charlie — Tue, 20 Dec 2022 09:25:39 GMT

Hi Achim,

I have got it from my colleague, I will give you a reply later.

Best regards,

Charlie

RE: HPPLMN search - Please consolidate advice.

Achim Kraus — Fri, 16 Dec 2022 16:43:27 GMT

Not to flush this issue too much, I created a separate issue with my first trace.

hpplmn search - reason unknown

It shows, the the search was executed twice, even if the HPPLMN was chosen and never changed.

RE: HPPLMN search - Please consolidate advice.

Achim Kraus — Thu, 15 Dec 2022 17:15:46 GMT

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

RE: HPPLMN search - Please consolidate advice.

Charlie — Thu, 15 Dec 2022 13:53:41 GMT

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

RE: HPPLMN search - Please consolidate advice.

Charlie — Thu, 15 Dec 2022 10:10:33 GMT

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

RE: HPPLMN search - Please consolidate advice.

Achim Kraus — Thu, 15 Dec 2022 09:59:12 GMT

OK, then my experience is different:

My device starts a HPPLMN search, even if it's already connected to the HPPLMN (see the 1NCE SIM-data)

I will try to create some traces, but as I already wrote, this requires time and for now I have to focus on an other task ;-).

RE: HPPLMN search - Please consolidate advice.

Achim Kraus — Thu, 15 Dec 2022 09:56:46 GMT

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

RE: HPPLMN search - Please consolidate advice.

Charlie — Thu, 15 Dec 2022 09:56:33 GMT

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

RE: HPPLMN search - Please consolidate advice.

Achim Kraus — Thu, 15 Dec 2022 09:21:55 GMT

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.

RE: HPPLMN search - Please consolidate advice.

Charlie — Thu, 15 Dec 2022 09:15:24 GMT

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

RE: HPPLMN search - Please consolidate advice.

Achim Kraus — Thu, 15 Dec 2022 08:14:57 GMT

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?

RE: HPPLMN search - Please consolidate advice.

Achim Kraus — Wed, 14 Dec 2022 19:48:00 GMT

Thanks a lot!

That helps me to optimize the behavior.

RE: HPPLMN search - Please consolidate advice.

Charlie — Wed, 14 Dec 2022 12:54:52 GMT

Hi Achim,

The SIM Card offers at least two lists:

User controlled PLMN selector with Access Technology '6F60'

Operator controlled PLMN selector with Access Technology '6F61'

Which one does Nordic support? What is the priority, when both are used?

Nordic supports both. User controlled PLMN list has higher priority than the operator controlled PLMN list - as per 3GPP.

Does the modem executes such a search, even if in roaming already the highest priority PLMN is active?

No.

What PLMN encoding does Nordic assume/support in the selector list? e.g. is "62F210" interpreted as "26201"?

Yes it is: MCC2MCC1MNC3MCC3MNC2MNC1. If MNC3 is 'F' it is ignored.

Does "%XDATAPRFL" change the interval of the SIM-Card for such a HPPLMN search?

No. Data profile is proprietary functionality and does not break 3GPP specification.

Does "%REDMOB" change the interval of the SIM-Card for such a HPPLMN search?

No.

Best regards,

Charlie

RE: HPPLMN search - Please consolidate advice.

Achim Kraus — Mon, 12 Dec 2022 19:18:33 GMT

> Automatic and manual network selection modes

> it is also in operators interests that the device uses the highest priority network available (based on SIM configuration).

As long as "manual network selection" is used, the interests of the operators seems to be not that important.

The SIM Card offers at least two lists:

- User controlled PLMN selector with Access Technology '6F60'

- Operator controlled PLMN selector with Access Technology '6F61'

Which one does Nordic support?

What is the priority, when both are used?

Does the modem executes such a search, even if in roaming already the highest priority PLMN is active?

What PLMN encoding does Nordic assume/support in the selector list? e.g. is "62F210" interpreted as "26201"?

Does "%XDATAPRFL" change the interval of the SIM-Card for such a HPPLMN search?

Does "%REDMOB" change the interval of the SIM-Card for such a HPPLMN search?

So, yes, if that function is important, I would welcome, if more details about the implementation gets available. Otherwise, my concern would be, that much more energy is used, than everyone assumes.

RE: HPPLMN search - Please consolidate advice.

Achim Kraus — Mon, 12 Dec 2022 19:03:33 GMT

michal

Your expert was saying:

"I have consulted my colleagues about it and using the +COPS command is not recommended for that at all."

Is the above advice/recommendation agreed?

RE: HPPLMN search - Please consolidate advice.

Charlie — Mon, 12 Dec 2022 12:24:44 GMT

Hi Achim,

Thanks for summarising the tickets related to the concern of HPPLMN search causing the extra power consumption. After talking with our development and product management teams, I have a summary about the current state of this topic.

We do not have a plan to disable HPPLMN search at the current time, because it will break the current 3GPP spec.

4.4.3.3.1 Automatic and manual network selection modes of TS23.122

....

For an MS that only supports any of the following or a combination of EC-GSM-IoT or Category M1 or
Category NB1(as defined in 3GPP TS 36.306 [54]): T is either in the range 2 hours to 240 hours, using 2 hour
steps from 2 hours to 80 hours and 4 hour steps from 84 hours to 240 hours, or it indicates that no periodic
attempts shall be made. If no value for T is stored in the SIM, a default value of 72 hours is used.

....

The attempts to access the HPLMN or an EHPLMN or higher priority PLMN shall be as specified below:

...

d1) periodic attempts may be postponed while the MS is in power saving mode (PSM) (see 3GPP TS 23.682 [27A]).

For the customer/developer, this is a clear power consumption issue, but they are not the only stakeholder in this field. When not in home network (i.e. device is roaming), then it is also in operators interests that the device uses the highest priority network available (based on SIM configuration). This is because depending on the subscription, higher roaming prices may be either operator's or customer's responsibility and the ordering of PLMNs configured to SIM card is typically done based on roaming agreements.

Having this said, there is a exception: If application manually selects the network with AT+COPS, then HPPLMN searches are not done because the selected network could not be changed anyway due to the manual network selection mode. Downside in this approach is that if the manually selected network is not available at some point due to movement of the device, modem will keep searching only the manually selected network even though there would be other suitable networks available. Switching back to automatic network selection mode would help in this situation.

The current solution for this issue is to use the local network or lock the PLMN if you clearly know where the devices will be deployed. Some MVNOs start to support eUICC on their SIM cards, which can select local network profiles for cellular connection instead of roaming.

Best regards,

Charlie