Project

General

Profile

Actions

Feature #4795

closed

Uplink Repeated SACCH Support

Added by laforge over 3 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
10/09/2020
Due date:
% Done:

100%

Spec Reference:
3GPP TS 44.006 Section 11.3

Description

In 3GPP Rel-7 (?) of GERAN, the concept of "repeated SACCH" was introduced.

The rationale for SACCH improvement can be found in 3GPP TDoc GP-042668 Section 1/2 (even though if later sections have not been implemented as suggested there): Particularly with AMR as a voice codec, the voice quality performance is better than that of control channels (and estimated 5dB).

So in the end, even though the voice channel would still be acceptable, calls fail due to signaling failure, both on SACCH and FACCH.

Uplink Repeated SACCH support basically replaces measurement reports on uplink SACCH (or even pending SAPI3 frames) with re-transmissions of SAPI0 frames. Due to some related logic (and sigaling in the TS 44.004 header), the BTS can then even combine the bursts from multiple transmissiosn to decode the SACCH block.


Related issues

Related to OsmoBTS - Feature #4794: Downlink Repeated SACCH supportResolveddexter10/09/2020

Actions
Related to OsmoBTS - Bug #3056: OsmoBTS doesn't implement SACCH Repetition Order (SRO)Rejected03/11/2018

Actions
Actions #1

Updated by laforge over 3 years ago

  • Related to Feature #4794: Downlink Repeated SACCH support added
Actions #2

Updated by laforge over 3 years ago

Actions #3

Updated by laforge over 3 years ago

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

Actions #4

Updated by dexter over 3 years ago

  • Assignee set to dexter
Actions #5

Updated by dexter over 3 years ago

  • Status changed from New to In Progress
Actions #6

Updated by dexter over 3 years ago

  • % Done changed from 0 to 50

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

Actions #7

Updated by laforge over 3 years ago

On Mon, Nov 16, 2020 at 10:18:47PM +0000, dexter [REDMINE] wrote:

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.

Hoernchen, any ideas on how to achieve this best?

Actions #8

Updated by dexter over 3 years ago

  • % Done changed from 50 to 80

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

Actions #9

Updated by dexter over 3 years ago

  • % Done changed from 80 to 90

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

Actions #10

Updated by dexter over 3 years ago

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.

Actions #11

Updated by dexter over 3 years ago

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

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

Actions #12

Updated by fixeria 4 months ago

  • Related to Bug #3056: OsmoBTS doesn't implement SACCH Repetition Order (SRO) added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)