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 almost 2 years 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 almost 2 years 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 almost 2 years 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 almost 2 years ago
This patch ports rest-octet encoding from osmo-bsc to libosmocore: https://gerrit.osmocom.org/#/c/libosmocore/+/10189
#17 Updated by laforge almost 1 year ago
- 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/
#20 Updated by fixeria about 2 months ago
- Status changed from Resolved to New
- % Done changed from 100 to 80
I just noticed that System Information Type 4 still contains GPRS Indicator while osmo-pcu is not connected. Also, System Information Type 13 is still being transmitted by osmo-bts-trx (is it expected?). System Information Type 3 contains no GPRS Indicator as expected.
Updated by neels over 1 year ago
just noticing, there's also a GPRS presence indicator in the rest octets in SI4
- % Done changed from 80 to 90
I've extended the existing TTCN-3 test cases to check GPRS Indicator in SI4 Rest Octets too, see:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18027 BTS: manually compose Rest Octets for SI Type 3 and 4
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18028 BTS: fix missing GPRS Indicator in SI4 Rest Octets
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18029 BTS: refactor f_get_si3(), so it can be used to get SI4
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18030 BTS: verify presence of GPRS Indicator in SI4 Rest Octets
I also noticed that osmo-bts changes unrelated "3G Early Classmark Sending Restriction" field in SI3 Rest Octets:
SI 3 Rest Octets L... .... = Selection Parameters: Not Present .L.. .... = Optional Power Offset: Not Present ..L. .... = SYSTEM INFORMATION TYPE 2ter: Not available ...L .... = Early Classmark Sending: Not Allowed .... L... = Scheduling if and where: Not Present .... .H.. = GPRS Indicator: Present GPRS Indicator .... ..00 0... .... = GPRS RA Colour: 0 .0.. .... = SI13 Position: SYSTEM INFORMATION TYPE 13 message is sent on BCCH Norm (0) ..L. .... = 3G Early Classmark Sending Restriction: Neither UTRAN, CDMA2000 nor GERAN IU MODE CLASSMARK CHANGE message shall be sent with the Early classmark sending ...L .... = SI2quater Indicator: Not Present .... L... = SI21 Indicator: Not Present Padding Bits: default padding
SI 3 Rest Octets L... .... = Selection Parameters: Not Present .L.. .... = Optional Power Offset: Not Present ..L. .... = SYSTEM INFORMATION TYPE 2ter: Not available ...L .... = Early Classmark Sending: Not Allowed .... L... = Scheduling if and where: Not Present .... .L.. = GPRS Indicator: Not Present .... ..H. = 3G Early Classmark Sending Restriction: The sending of UTRAN,CDMA2000 and GERAN IU MODE CLASSMARK CHANGE messages are controlled by the Early Classmark Sending Control parameter .... ...L = SI2quater Indicator: Not Present 0... .... = SI13alt Position: If Iu mode is supported in the cell, SYSTEM INFORMATION TYPE 13alt message is sent on BCCH Norm .L.. .... = SI21 Indicator: Not Present Padding Bits: default padding