Feature #4796: Downlink Repeated FACCH Support - OsmoBTS - Open Source Mobile Communications

Custom queries

all-by-project

Actions

Copy link

Feature #4796

closed

Downlink Repeated FACCH Support

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

Status:

Resolved

Priority:

Low

Assignee:

dexter

Category:

Target version:

Start date:

10/09/2020

Due date:

% Done:

100%

Spec Reference:

3GPP TS 44.006 Section 10

Description

In 3GPP Rel-7 (?) of GERAN, the concept of "repeated FACCH" 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.

Downlink repeated FACCH basically works by re-transmitting FACCH frames in downlink even before T200 expires. (this obviously steals additional voice frames, as FACCH always does). Those retransmissions happen 8/9 TDMA frames after the original transmission, i.e. after 33/37ms.

LAPDm commands can always be re-transmitted even without the MS indicating any support.
LAPDm responses can only be re-transmitted if the MS indicates the "Repeated ACCH Capability"

As outlined in Section 2 of GP-042668, it is expected that this would particularly help hand-over performance in frequency hopping networks, as the Handover Command there often requires two FACCH blocks to be correctly received by the MS.

Related issues

Related to OsmoBTS - Feature #4794: Downlink Repeated SACCH support

Resolved

dexter

10/09/2020

Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by laforge over 3 years ago

Related to Feature #4794: Downlink Repeated SACCH support added

Actions

Copy link

% Done changed from 80 to 90

The downlink FACCH repeated is now implemented on the higher l1sap.c layer. In theory all BTSs should now support Repeated Downlink FACCH.

https://gerrit.osmocom.org/c/osmo-bts/+/21014 l1sap: add repeated downlink FACCH

Actions

Copy link

#10

Updated by dexter over 3 years ago

% Done changed from 90 to 80

The Patch I have submitted to gerrit received some review. I have fixed the comments, but unfortunately I was overlooking that we still need to filter by command/response frames when the MS did not indicate repeated _ACCH support. Also we need to adjust T200.

Actions

Copy link

#11

Updated by dexter over 3 years ago

Finding out which LAPDm frame is a command frame and which one is not works fine so far. but unfortunately determining the state of the Repeated ACCH Capability bit in CM3 is more difficult as expected. First of all CM3 is not transmitted automatically (not necessarily, there is still early CM sending), it must be inquired by sending a CLASSMARK ENQUIRY to trigger sending a CLASSMARK CHANGE, which then contains the CM3. This is triggered by the core network (MSC) using a CLASSMARK REQUEST message. For now I have patched osmo-msc, so that it sends a CLASSMARK REQUEST before the ciphering starts, so now we get the CM3.

The problem is now that there I see no way to communicate the Repeated ACCH Capability bit back to the BSS. From what I can see, the BTS must parse the CM3 in the CLASSMARK CHANGE and track to which subscriber the Repeated ACCH Capability bit belongs. As far as I know the BTS does none of this. We would need to watch the assignment command to see to which TS the MS is going and track and memorize what CM3 had signaled while the MS was on the SDCCH.

A different solution also might be to trigger the CLASSMARK ENQUIRY automosuly while on the TCH but this is probably a bit too late.

Actions

Copy link

#12

Updated by dexter over 3 years ago

We have now discussed the problem and we came to the conclusion that it is best to add a propritary flag to RSL CHAN ACT and RSL CHAN MODE MODIFY. This way the BSC can control the status of the ACCH Capability bit in the lchan on the BTS. Since the BSC keeps a lot of state it should also be no problem to keep track of the ACCH Capability bit in CM3 / Classmark Update there. Extending the spec this way should be fine, also other BTS types have their specialties here and there.

The BTS side already works fine. Depending on the ACCH Capability bit (which is now communicated via RSL CHAN ACT / MODE MODIFY messages) the FACCH repetition either works with LAPDm command frames only or with all downlink FACCH LAPDm frames. Also the T200 counter value is doubled dynamically if the ACCH Capability bit is set.

(I could make the early classmark sending work, it turned out that it was disabled in my BSC config.)

Actions

Copy link

#13

Updated by dexter over 3 years ago

% Done changed from 80 to 90

I have now finished the implementation of the repated FACCH capability. Since there is indeed no way to signal the ACCH Capability bit back to the BTS when the channel is activated or modified. I have now added a propritary IE as discussed recently. This works fine so far. Unfortunately it turned out that parsing the ACCH Capability bit from CM3 is actually very difficult because the CM3 IE is an CSN.1 encoded bitstream. I have added a parser+tests for this to libosmocore, so that we now can parse the CM3 message as well. (CM1 and CM2 can be parsed by just overlaying a C struct)

https://gerrit.osmocom.org/c/libosmocore/+/21082 gsm_08_58: add propritary IE to signal Repeated ACCH Capability [NEW]
https://gerrit.osmocom.org/c/libosmocore/+/21083 gsm_04_08: add parser for Mobile Station Classmark 3 [NEW]
https://gerrit.osmocom.org/c/osmo-bsc/+/21084 abis_rsl: parse cm3 and indicate ACCH repetition cap to BTS [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/21014 l1sap: add repeated downlink FACCH

There is still some stuff left to do. The abis manual osmobts-abis.pdf must be updated. Also a wireshark patch is needed to display the new IE.

Actions

Copy link

#14

Updated by dexter over 3 years ago

The repeated FACCH related patches are still in review. I have now fixed most issues there, what I have not addressed yet is the question when the FACCH repetition should be turned on. At the moment it is, if it is enabled in the BSC VTY, permenantly on. This comes at the cost of a few voice blocks of course. With the FACCH the this is probably not as paroblematic as with the SACCH since the FACCH only tends to be active at the beginning and at the end/handover of a call (and SMS?). In #4795 I am thinking of a criteria that can be used to decide if the repetition should be turned on or off.

See also:
https://gerrit.osmocom.org/c/osmo-bts/+/21014 l1sap: add repeated downlink FACCH
https://gerrit.osmocom.org/c/libosmocore/+/21186 gsm_08_58: add struct for RSL_IE_OSMO_REP_ACCH_CAP
https://gerrit.osmocom.org/c/osmo-bsc/+/21164 bts: add repeated acch mode flags + vty config
https://gerrit.osmocom.org/c/osmo-bsc/+/21084 abis_rsl: parse cm3 and indicate ACCH repetition cap to BTS

Actions

Copy link

#15

Updated by dexter over 3 years ago

I have now added a criterion to decide when the FACCH is turned on or off. I am using the RXQUAL value the MS sends us with the measurement values. Also if the MS decides to turn on repeated DL-SACCH, we should definitely enable repeated FACCH too.

See also: https://gerrit.osmocom.org/c/osmo-bts/+/21014 l1sap: add repeated downlink FACCH

Actions

Copy link

#16