Project

General

Profile

Bug #3284

GPRS cell re-selection appears sticky in packet transfer / packet idle mode

Added by laforge over 1 year ago. Updated 8 months ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
05/23/2018
Due date:
% Done:

0%

Spec Reference:

Description

We have received some reports from a sysmocom customer, indicating that during inter-BTS cell changes, the cells are too "sticky" if the MS is in packet transfer or packet idle mode.

I would think we should first investigate if the currently implementation is doing anything wrong related to neighbor lists or generally related to GPRS cell changes.

The long-standing issue #2400 comes to my mind. It's about transmitting SI13 during long TBFs, but we might be able to send other SI messages the same way, despite not having a PBCCH:

TS 44.060 5.5.2.1.3: "The network may send neighbour cell PSI and SI messages on PACCH 
in one or more instances of the PACKET NEIGHBOUR CELL DATA message (see sub-clause 8.8.1)."

But to be honest, I don't really understand right now how that would help, either. The MS will have the SI2* from the circuit-switched BCCH, and use that unless it receives some other information via the packet-switched side. As the neighbor lists would be identical in both
cases, there's nothing to be gained by sending them via PBCCH or PACCH. If the MS doesn't perform the cell change soon enough, this is more likely the result of it not performing a sufficient number of neighbor measurements to [soon enough] determine that there are other, much better cells around.

Or, if the measurements are available, the cell re-selection criterion might somehow lead to the wrong result?

One approach is of course NACC, but I think this is only the last alternative if everything else fails. In NACC (network assisted cell change), in which it's no longer the MS but more the network that determines the cell that is to be used. I believe this feature is still mandatory to be supported on phones, and we could at least in theory implement it safely. The more practical issue is that the neigbor cells are only known to the BSC, while the PCU+SGSN are in charge of GPRS. There's no standardized interface between PCU and BSC, and in Osmocom (like ip.access) GPRS/EGPRS implementations, the PCU is actually co-located with the BTS and not the
BSC. So I expect that this would be rather hard to do (but I haven't done a full-blown analysis).

It may also be, that we're doing something wrong in the SGSN, i.e. the MS
actually behaves correctly and tries to access the new cell, but somehow
on the signaling between PCU/SGSN something goes wrong and/or causes
unexpected delays.

Finally, I think there are some timers and parameters that can be tuned.


Related issues

Related to OsmoPCU - Bug #2400: transmit SI13 on PACCH during long TBFsStalled07/25/2017

Related to OsmoPCU - Feature #3285: design + implement tools to analyze inter-PCU cell changesNew05/23/2018

History

#1 Updated by laforge over 1 year ago

  • Related to Bug #2400: transmit SI13 on PACCH during long TBFs added

#2 Updated by laforge over 1 year ago

  • Related to Feature #3285: design + implement tools to analyze inter-PCU cell changes added

#3 Updated by laforge about 1 year ago

#4 Updated by laforge about 1 year ago

  • Assignee changed from lynxis to msuraev

#5 Updated by laforge 8 months ago

  • Assignee changed from msuraev to lynxis

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)