Project

General

Profile

Feature #4796

Downlink Repeated FACCH Support

Added by laforge about 1 year ago. Updated 10 months 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 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 supportResolved10/09/2020

Associated revisions

Revision a15967ba (diff)
Added by dexter 12 months ago

gsm_08_58: add proprietary IE to signal Repeated ACCH Capability

3GPP TS 24.008, section 10.5.1.7 specifies a Repeated ACCH Capability
bit in the Classmark 3 IE. Unfortunately, there is no way specified how
the Repeated ACCH feature should be controlled on RSL level. Since it is
not unusual that BTS/BSC vendors occassionally add proprietary IEs to
different RSL messages we may pick this as a solution as well and add a
propritary RSL_IE_OSMO_REP_ACCH_CAP IE, so that we can enable repeated
FACCH/SACCH on the BTS side when we send RSL CHAN ACT or RSL CHAN MODE MODIFY
messages.

Change-Id: I61ea6bf54ea90bd69b73ea0f0f3dc19a4214207b
Related: OS#4796 SYS#5114

Revision a4939dc8 (diff)
Added by dexter 12 months ago

gsm_04_08: add parser for Mobile Station Classmark 3

3GPP TS 24.008 section 10.5.1.7 describes a Mobile Station Classmark 3
IE, which is encoded as CSN.1 struct. This means that it can not be
parsed by just casting a memory location to a struct pointer, so lets
add a parser to parse the CM3 IE.

Change-Id: Ic8b2bfd00330235f5bed00771e421588abfaac1f
Related: OS#4796 SYS#5114

Revision 1680a786 (diff)
Added by dexter 12 months ago

abis_rsl: parse cm3 and indicate ACCH repetition cap to BTS

In order to activate FACCH/SACCH repetition on the BTS, the classmark 3
IE in the CLASSMARK CHANGE message must be parsed and depending on the
Repeated ACCH Capability bit the RSL_IE_OSMO_REP_ACCH_CAP is added to
the RSL CHAN ACT und RSL CHAN MODE MODIFY. Since
RSL_IE_OSMO_REP_ACCH_CAP is a propritary IE, it may only be added for
BTS type osmo-bts.

Change-Id: I39ae439d05562b35b2e47774dc92f8789fea1a57
Depends: libosmocore Ic8b2bfd00330235f5bed00771e421588abfaac1f
Related: OS#4796 SYS#5114

Revision 70d78f21 (diff)
Added by dexter 12 months ago

rsl.adoc: add info about RSL_IE_OSMO_REP_ACCH_CAP

The RSL documentation should reflect some explanatory info about the
recently added RSL_IE_OSMO_REP_ACCH_CAP IE.

Depends: libosmocore I61ea6bf54ea90bd69b73ea0f0f3dc19a4214207b
Change-Id: I1d70846c2c184f7a189074c51137bc1f38fb3859
Related: OS#4796 SYS#5114

Revision e36be56f (diff)
Added by dexter 12 months ago

gsm_04_08: add parser for Mobile Station Classmark 3

3GPP TS 24.008 section 10.5.1.7 describes a Mobile Station Classmark 3
IE, which is encoded as CSN.1 struct. This means that it can not be
parsed by just casting a memory location to a struct pointer, so lets
add a parser to parse the CM3 IE.

This is fixed version of Ic8b2bfd00330235f5bed00771e421588abfaac1f,
which got reverted because it used the keyword "class" as struct member,
which lead into problems with c++ builds. This is now fixed.

Change-Id: Id8732551b33616227609cd6fcf6c3133751a89eb
Related: OS#4796 SYS#5114

Revision 33dfe2bc (diff)
Added by dexter 11 months ago

l1sap: add repeated downlink FACCH

3GPP TS 44.006, section 10 describes a method how the downlink
FACCH transmission can be repeated to increase transmission
reliability.

Change-Id: I72f0cf7eaaef9f80fc35e752c90ae0e2d24d0c75
Depends: libosmocore I6dda239e9cd7033297bed1deb5eb1d9f87b8433f
Related: OS#4796 SYS#5114

Revision 7e38cf4e (diff)
Added by dexter 11 months ago

l1sap: also include SRR bit in RSL l1 info field.

The SRR bit, which got specified in 3gpp release 6 to support repeated
ACCH capability is not yet included in the L1 Information IE on RSL
level. Also lets update the spec reference to more modern 3gpp spec ref
numbers.

Change-Id: I987c61608b737521ba36756dabf2f6215b34c2d6
Related: OS#4796 SYS#5114

Revision 0eb479e2 (diff)
Added by dexter 11 months ago

abis_rsl: parse cm3 and indicate ACCH repetition cap to BTS

In order to activate FACCH/SACCH repetition on the BTS, the classmark 3
IE in the CLASSMARK CHANGE message must be parsed and depending on the
Repeated ACCH Capability bit the RSL_IE_OSMO_REP_ACCH_CAP is added to
the RSL CHAN ACT und RSL CHAN MODE MODIFY. Since
RSL_IE_OSMO_REP_ACCH_CAP is a propritary IE, it may only be added for
BTS type osmo-bts.

Change-Id: I39ae439d05562b35b2e47774dc92f8789fea1a57
Related: OS#4796 SYS#5114

History

#1 Updated by laforge about 1 year ago

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

#2 Updated by laforge about 1 year ago

#3 Updated by laforge about 1 year ago

See also: Chapter 7.3 of "GSM/EDGE Evolution and Performance", which also includes a detailed case study on handover performance.

#4 Updated by laforge about 1 year ago

  • Tracker changed from Bug to Feature

#5 Updated by dexter 12 months ago

  • File GP-042668_Enhanced_ACCH.pdf added

#6 Updated by dexter 12 months ago

  • Assignee set to dexter

#7 Updated by dexter 12 months ago

  • File deleted (GP-042668_Enhanced_ACCH.pdf)

#8 Updated by dexter 12 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 80

#9 Updated by dexter 12 months ago

  • % 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

#10 Updated by dexter 12 months 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.

#11 Updated by dexter 12 months 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.

#12 Updated by dexter 12 months 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.)

#13 Updated by dexter 12 months 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.

#14 Updated by dexter 11 months 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

#15 Updated by dexter 11 months 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

#16 Updated by dexter 11 months ago

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

#17 Updated by dexter 11 months ago

I have fixed the currently pending review issues, so no open review issues at the moment.

#18 Updated by dexter 11 months ago

#19 Updated by dexter 10 months 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)