Cellular Network Infrastructure » Radio Access Network » OsmoBTS

See also: Chapter 7.2 of "GSM/EDGE Evolution and Performance".

I have started the implementation of repeated uplink SACCH. In my experiments I can see that I am able to turn the repetition at the MS side on and off by setting the SRO bit in the L1 SACCH header of the SACCH block I send. So this part works so far.

When it comes to try the decoding of the current SACCH block by also using the bits from the previous SACCH block I am not entirely sure what to do. The best method to combine the previous with the current transmission seems to be to take the soft bits and just add them. One could also try to combine the bursts separately, given that the SACCH bursts are very far apart from each other this even would even make sense.

However, the most interesting question at the moment is how do we decide if we start/stop the SACCH (and maybe also FACCH) repetition. I think the SACCH repetition is mostly needed when the MS is approaching the outer perimeter of the cell. The SACCH contains the measurement reports. And even if we only get half of them when the repetition is on this is still better then nothing. I think this is the case we should design this for. I would use the the bit errors as a criterion. SACCH is coded as 1/2 viterbi. Maybe turing on the repetition when 1/3 of the received bits is wrong makes sense.

I have already submitted the patch to gerrit, but it is still work in progress:
https://gerrit.osmocom.org/c/osmo-bts/+/21185 WIP: l1sap: add repeated uplink SACCH

I did some experiments and Indeed I can see bad SACCH blocks that get decoded by combining them with the previous SACCH block by just adding the two blocks. I also think that looking at the BER is a good criterion to turn on SACCH repetition. I have implemened it as a hysteresis with hardcoded values. I have oriented myself towards the ranges given GSM 05.08, section 8.2.4. So at about an RXQUAL level of 4 SACCH repetition is turned on and if RXQUAL reaches a better than 3 it is turned off again. The levels are hardcoded at the moment, but they could be configurable. We still have 4 bits in the RSL_IE_OSMO_REP_ACCH_CAP we could use for this.

See also:
https://gerrit.osmocom.org/c/osmo-bts/+/21185 l1sap: add repeated uplink SACCH

The patches are up for review, no open review issues at the moment.

At the moment there are no open review issues. Since there were concerns about the saturated approach when adding the softbis i moved over to an averaged support (first divide by 2, then add). The results were nearly the same.

All related patches are merged, so we can resolve this ticket now.