Project

General

Profile

Feature #3075

do not transmit SI13 when the PCU is not connected

Added by neels about 1 year ago. Updated about 1 month ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
03/19/2018
Due date:
% Done:

0%

Spec Reference:

Description

Looking at the scenario described in #3042:
  • two BTS, both configured for GPRS.
  • none of them having an osmo-pcu running along.
  • result: subscriber continuously does Location Updates between the two in an attempt to establish working data service.
    Do not send SI13 when the PCU is not connected, and see if that stops the cell hopping in the lack of a PCU.

Related issues

Related to Cellular Network Infrastructure - Bug #3042: in the presence of two BTS, a subscribed phone seems compelled to repeatedly Location Update every ~15 secondsRejected2018-03-08

History

#1 Updated by neels about 1 year ago

  • Related to Bug #3042: in the presence of two BTS, a subscribed phone seems compelled to repeatedly Location Update every ~15 seconds added

#2 Updated by laforge about 1 year ago

Even more important than not sending SI13 is to not send the indication that SI13
is present (In SI3 or SI4, AFAIR).

#3 Updated by laforge 9 months ago

  • Assignee set to stsp

#4 Updated by stsp 8 months ago

neels wrote:

Do not send SI13 when the PCU is not connected

As far as I understand, rsl_rx_bcch_info() attempts to tell the PCU to send SI13,
which will always fail as long as the PCU socket is disconnected.
Once the PCU comes up, pcu_rx_txt_ind() will immediately ask the PCU to send SI13.

laforge wrote:

Even more important than not sending SI13 is to not send the indication that SI13
is present (In SI3 or SI4, AFAIR).

This indication is present in SI3 (see gsm_generate_si() in osmo-bsc/system_information.c).

However, the code which generates SI3 lives in osmo-bsc, based on the gprs type of the BTS.
There doesn't seem to be a way to monitor the PCU socket status from osmo-bsc, Is that possible somehow?
Or should the BTS be modifying the SI3 which was provided by the BSC?

#5 Updated by stsp 8 months ago

  • Status changed from New to In Progress

#6 Updated by neels 8 months ago

Ok I see, depending on 'gprs mode (none|gprs|egprs)', osmo-bsc composes an SI3 to indicate GPRS service.
So the situation is about a failing GPRS service, where osmo-bsc expects the PCU to work, but it crashed/is broken/unreachable.
My personal intuition would be that osmo-bts masks the SI3 to indicate no GPRS as long as the PCU isn't connected.

But I'm not sure if that's a good idea semantically, it's a bit of a layering violation.
Maybe some custom non-standard message could tell the BSC that the PCU is down and osmo-bsc masks the SI3 instead?
Patching over SI3 in osmo-bts is certainly the easiest.

...not sure...

On the need to fix: at first I thought it's not critically important, but when in practice a GPRS service breaks down, it would potentially also take down voice with it, because all the phones would start to constantly LU at different cells, trying to catch a working PCU, which would load the network and could disrupt service. So I think in terms of infrastructure stability it's pretty bad to indicate GPRS presence if the BTS knows that the PCU is down.

#7 Updated by stsp 8 months ago

I don't think coupling this behaviour to osmo-bsc would be wise.
What if osmo-bts runs with a BSC from another vendor?

This patch makes the BTS override the GPRS indicator in SI3: https://gerrit.osmocom.org/#/c/osmo-bts/+/10170
Parsing SI3 rest octets is a bit ugly but I don't see a better solution.

#8 Updated by stsp 8 months ago

To make the proposed patch nice we'll need to port some code from osmo-bsc to libosmocore first.

This is step one of that porting process: https://gerrit.osmocom.org/c/libosmocore/+/10185

#9 Updated by neels 8 months ago

just noticing, there's also a GPRS presence indicator in the rest octets in SI4

#10 Updated by stsp 8 months ago

This patch ports rest-octet encoding from osmo-bsc to libosmocore: https://gerrit.osmocom.org/#/c/libosmocore/+/10189

#11 Updated by stsp 8 months ago

This issue is currently waiting for confirmation from several authors to allow us to re-licence their code from AGPL to GPLv2+.

#12 Updated by stsp 6 months ago

This issue is still waiting for a response from Jolly to our question about the license change.

#13 Updated by stsp 4 months ago

We haven't received a written statement by Jolly yet. Still waiting.

#14 Updated by stsp 3 months ago

Got permission from Jolly :)

#15 Updated by laforge about 1 month ago

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)