Feature #3075
closeddo not transmit SI13 when the PCU is not connected
100%
Description
- 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.
Files
Related issues
Updated by neels over 5 years ago
- Related to Bug #3042: in the presence of two BTS, a subscribed phone seems compelled to repeatedly Location Update every ~15 seconds added
Updated by laforge over 5 years ago
Even more important than not sending SI13 is to not send the indication that SI13
is present (In SI3 or SI4, AFAIR).
Updated by stsp over 5 years 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?
Updated by neels over 5 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.
...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.
Updated by stsp over 5 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.
Updated by stsp over 5 years 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
Updated by neels over 5 years ago
just noticing, there's also a GPRS presence indicator in the rest octets in SI4
Updated by stsp over 5 years ago
This patch ports rest-octet encoding from osmo-bsc to libosmocore: https://gerrit.osmocom.org/#/c/libosmocore/+/10189
Updated by stsp over 5 years ago
This issue is currently waiting for confirmation from several authors to allow us to re-licence their code from AGPL to GPLv2+.
Updated by stsp about 5 years ago
This issue is still waiting for a response from Jolly to our question about the license change.
Updated by stsp about 5 years ago
We haven't received a written statement by Jolly yet. Still waiting.
Updated by laforge over 4 years ago
- Status changed from In Progress to Stalled
- Assignee changed from stsp to 4368
- % Done changed from 0 to 20
Updated by laforge over 4 years ago
- Status changed from Stalled to In Progress
- Assignee changed from 4368 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/
Updated by laforge over 4 years ago
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
both patch and test have been merged.
Updated by laforge over 4 years ago
- Related to Bug #4032: RLL/LAPDm ABM has no TTCN3 tests added
Updated by fixeria over 3 years 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
Updated by fixeria over 3 years ago
- % 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
Updated by fixeria over 3 years ago
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
vs
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
Updated by fixeria over 3 years ago
I also noticed that osmo-bts changes unrelated "3G Early Classmark Sending Restriction" field in SI3 Rest Octets:
https://gerrit.osmocom.org/c/libosmocore/+/18036 rest_octets: fix encoding of 3G Early Classmark Sending Restriction
Updated by laforge almost 3 years ago
- Status changed from New to Resolved
- % Done changed from 90 to 100
all patches merged