nrf9160 multiple cell location - how to perform neigbour cell detection?

[barbiz]

Hello,

I know this topic has been discussed yet and I have read all the relevant posts.

What we have to do is multiple cell geolocation with nrf9160. The "multiple" here is the keyword, because in my tests, it was impossible to get more than the connected cell. Although I checked the coverage MAP and I know for sure multiple nearby cells are available.

We tried, as everybody else, the %NCELLMEAS and %NBRGRSRP commands, but we only manage to get the serving cell.

I also know that this is due to a specification on the 3GPP standard:

"Neighboring cell measurements are valid and available only when neighbors are being monitored, which means that the strength and quality of the current cell signal do not meet the network configured level. For more information, see the requirements in 3GPP TS 36.304."

However, it seems strange to me that:

• a specific example is given "multicell_location" that will almost never work for me
• other modules (such as QUECTEL BG95/96) do have a method to perform nearby cell scanning (and thus clearly overcome the limit of the standard)

So what I wanted to understand is:

• is there any news on the topic? This is really important for non-GNSS location applications and could make a big difference
• if not, is there any plan to implement a deeper call search function?
• are the %XDEEPSEARCH or %PERIODICSEARCHCONF somewhat related to this?

Thanks to everybody that will help me. I am puzzled by the fact that this point seems not properly addressed yet.

[Didrik Rokhaug]

Thanks for the trace. But I see that in this trace, you actually got a neighbour:

AT_STRING <= %NCELLMEAS: 0,"0097A56F","22210","69D9",80,6354,319,67,32,192580,  6354,329,54,6,0,  77807\r\n

I've added some extra spaces to the above response to show the neighbour more clearly.

[barbiz]

You are right. This means it happens sometime. I attach here a new trace, where, according to the serial log, the radio find 0 neighbours. This was tried 10 times in a row with the same result before taking the trace.

[00:04:50.873,413] <inf> multicell_location_sample: Button 1 pressed, starting cell measurements
%NCELLMEAS: 0,"0097A56F","22210","69D9",96,6354,319,66,22,301198,270183
[00:05:01.810,821] <inf> multicell_location_sample: Neighbor cell measurements received
[00:05:01.820,159] <inf> multicell_location_sample: Neighbor cells found: 0
[00:05:01.828,491] <inf> multicell_location_sample: Current cell:
[00:05:01.835,693] <inf> multicell_location_sample: MCC: 222
[00:05:01.842,590] <inf> multicell_location_sample: MNC: 010
[00:05:01.849,456] <inf> multicell_location_sample: Cell ID: 9938287
[00:05:01.857,147] <inf> multicell_location_sample: TAC: 27097
[00:05:01.864,227] <inf> multicell_location_sample: EARFCN: 6354
[00:05:01.871,490] <inf> multicell_location_sample: Timing advance: 96
[00:05:01.879,364] <inf> multicell_location_sample: Measurement time: 301198
[00:05:01.887,817] <inf> multicell_location_sample: Physical cell ID: 319
[00:05:01.895,965] <inf> multicell_location_sample: RSRP: 66
[00:05:01.902,832] <inf> multicell_location_sample: RSRQ: 22
[00:05:01.909,729] <inf> multicell_location_sample: *** No neighbor cells found ***trace-2022-04-08T11-16-52.159Z.bin

Marco

[Didrik Rokhaug]

The current neighbour cell measurement algorithm is heavily biased towards low power consumption, which means that it will try to not search for new cells as much as possible, just measure the ones it already knows about (if it has previously searched for neighbours on instruction from the network).

However, if you start the search with AT%NCELLMEAS=2, you can tell the modem to prioritise finding neighbours higher. However, it is still not a guarantee that it will actually find anything. Another limitation is that it will only search for NB-IoT (or LTE-M), and not "normal" LTE cells.