Cellular Network Infrastructure » Radio Access Network » OsmoBTS

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?

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.

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.

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

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

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

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

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

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

Got permission from Jolly :)

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/

both patch and test have been merged.

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

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

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

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

• https://gerrit.osmocom.org/c/libosmocore/+/20541
• https://gerrit.osmocom.org/c/osmo-bts/+/20542
• https://gerrit.osmocom.org/c/osmo-bts/+/20542

all patches merged