• State Verified Answer
  • Replies 6 replies
  • Subscribers 94 subscribers
  • Views 232 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 361723
Options

nRF9151: GCI searches returning limited results

JordanYates

I have an application that is attempting to use multi-cell positioning based on the results of %NCELLMEAS.
The application is following the flow of the NCS positioning module (EXTENDED_LIGHT -> GCI_DEFAULT -> GCI_EXTENDED_LIGHT).
I am observing that most of the time, the GCI scans are failing to find any cells apart from the currently serving cell.
Differing from other similar questions here, the application is in RRC idle for all of the scan requests.
The initial scan results in multiple neighbor cells found and measured, so it is not an issue of no other towers being nearby (I am ~10km from a city center)

[00:17:12.676,361] <err> modem_monitor:    State: Active
[00:17:23.825,866] <err> modem_monitor:    State: Idle
... Radio in RRC Idle
[00:18:00.633,056] <wrn> task_network_scan: Cell Scan: Mode 2 GCI_Count 0
[00:18:01.463,928] <inf> task_network_scan: Serving Cell Valid: Yes, Neighbour Cells: 3
[00:18:01.463,958] <inf> task_network_scan: Serving ECI: 147045644 (-106 dBm)
[00:18:01.463,958] <inf> task_network_scan: Neighbour: 337 (-118 dBm)
[00:18:01.463,989] <inf> task_network_scan: Neighbour: 238 (-120 dBm)
[00:18:01.463,989] <inf> task_network_scan: Neighbour: 70 (-129 dBm)
[00:18:01.464,141] <wrn> task_network_scan: Cell Scan: Mode 4 GCI_count 7
[00:18:01.836,669] <inf> task_network_scan: Global Cells: 1
[00:18:01.836,669] <inf> task_network_scan: Global ECI: 147045644 (-107 dBm)
[00:18:01.836,791] <wrn> task_network_scan: Cell Scan: Mode 5 GCI_count 7
[00:18:09.843,841] <inf> task_network_scan: Global Cells: 1
[00:18:09.843,872] <inf> task_network_scan: Global ECI: 147045644 (-107 dBm)
... Uplink here, transition to RRC Active
[00:18:12.688,781] <err> modem_monitor:    State: Active
[00:18:25.178,192] <err> modem_monitor:    State: Idle

While the lack of GCI cells is not a huge issue here with the multiple neighbors reported, the application also operates in regions where the network does not provide neighbor information, so the performance of the GCI scanning is critical.
Occasionally the `GCI_DEFAULT` search does find a second cell, but I am yet to see `GCI_EXTENDED_LIGHT` return useful information, despite searching for ~7.5 seconds each run.

I feel like I must be doing something wrong, but I have no idea what it could be.

           Model: nRF9151-LACA
        Firmware: mfw_nrf91x1_2.0.3
            Mode: LTE-M + GNSS (Prefer: No preference)

Parents
  • +1

    Hi,

    Thanks for the trace. I went through it, and you're not doing anything wrong. This is an RF-environment limit at that location, not a bug. The key is that the two searches do different work:

    • EXTENDED_LIGHT just measures cells (PCI + signal), so it lists several neighbors: even weak ones.
    • GCI search must identify each cell by decoding its broadcast (the global cell ID). That only works on cells strong enough to decode, and only decodable cells can be reported as GCI.

    In your trace, the two cells GCI finds are on band 28 and strong. The other neighbors are on band 1 and band 3 and much weaker. Checking every broadcast message the modem decoded across the whole capture, all were band 28, none on band 1 or 3. So only the two strong band-28 cells can be identified, the weaker cross-band neighbors can be measured but not decoded into a global ID.

    That's why GCI returns only those two, and why GCI_EXTENDED_LIGHT never beats GCI_DEFAULT because the extra scan time finds no further decodable cells. Everything else looks healthy. Does it clarify your concern, do let us know if there more I should look into it.

    Best Regards;
    Syed Maysum

Reply
  • +1

    Hi,

    Thanks for the trace. I went through it, and you're not doing anything wrong. This is an RF-environment limit at that location, not a bug. The key is that the two searches do different work:

    • EXTENDED_LIGHT just measures cells (PCI + signal), so it lists several neighbors: even weak ones.
    • GCI search must identify each cell by decoding its broadcast (the global cell ID). That only works on cells strong enough to decode, and only decodable cells can be reported as GCI.

    In your trace, the two cells GCI finds are on band 28 and strong. The other neighbors are on band 1 and band 3 and much weaker. Checking every broadcast message the modem decoded across the whole capture, all were band 28, none on band 1 or 3. So only the two strong band-28 cells can be identified, the weaker cross-band neighbors can be measured but not decoded into a global ID.

    That's why GCI returns only those two, and why GCI_EXTENDED_LIGHT never beats GCI_DEFAULT because the extra scan time finds no further decodable cells. Everything else looks healthy. Does it clarify your concern, do let us know if there more I should look into it.

    Best Regards;
    Syed Maysum

Children
Related
Terms of service