Project

General

Profile

Feature #3075

do not transmit SI13 when the PCU is not connected

Added by neels over 2 years ago. Updated 18 days ago.

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

90%

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.
si3_rest_octets.pcapng.gz si3_rest_octets.pcapng.gz 443 Bytes fixeria, 05/04/2020 06:45 PM

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 secondsRejected03/08/2018

Related to OsmoBTS - Bug #4032: RLL/LAPDm ABM has no TTCN3 testsResolved05/29/2019

History

#1 Updated by neels over 2 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

#2 Updated by laforge over 2 years 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 over 2 years ago

  • Assignee set to stsp

#4 Updated by stsp over 2 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?

#5 Updated by stsp over 2 years ago

  • Status changed from New to In Progress

#6 Updated by neels over 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.

...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 over 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.

#8 Updated by stsp over 2 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

#9 Updated by neels over 2 years ago

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

#10 Updated by stsp over 2 years ago

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

#11 Updated by stsp about 2 years 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 about 2 years ago

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

#13 Updated by stsp almost 2 years ago

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

#14 Updated by stsp almost 2 years ago

Got permission from Jolly :)

#15 Updated by laforge over 1 year ago

#16 Updated by laforge over 1 year ago

  • Status changed from In Progress to Stalled
  • Assignee changed from stsp to sysmocom
  • % Done changed from 0 to 20

#17 Updated by laforge over 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/

#18 Updated by laforge over 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

both patch and test have been merged.

#19 Updated by laforge over 1 year ago

  • Related to Bug #4032: RLL/LAPDm ABM has no TTCN3 tests added

#20 Updated by fixeria 7 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

#21 Updated by fixeria 6 months 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

#22 Updated by fixeria 6 months 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

#23 Updated by fixeria 6 months 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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)