do not transmit SI13 when the PCU is not connected
- 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.
#4 Updated by stsp about 1 year ago
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.
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?
#6 Updated by neels about 1 year 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.
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 about 1 year 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.
#10 Updated by stsp about 1 year ago
This patch ports rest-octet encoding from osmo-bsc to libosmocore: https://gerrit.osmocom.org/#/c/libosmocore/+/10189
- Status changed from Stalled to In Progress
- Assignee changed from sysmocom to laforge
- % Done changed from 20 to 80
A new, updated patch has been submitted as https://gerrit.osmocom.org/#/c/osmo-bts/+/10170/ and tested using newly-developed TTCN-3 tests from https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14215/