Project

General

Profile

Bug #3716

Use SACCH for MO/MT SMS signalling during a voice call

Added by fixeria 13 days ago. Updated 10 days ago.

Status:
Stalled
Priority:
Low
Assignee:
-
Category:
A interface
Target version:
-
Start date:
11/30/2018
Due date:
% Done:

80%

Spec Reference:

Description

It seems to be normal to use SACCH instead of FACCH for SMS during a voice call.
In this case every second Measurement Report is replaced by GSM 04.11 messages.

It is supported in OpenBSC, because the information about RAN connection is easily
available there, but OsmoMSC has no access to this information (yet?), so FACCH is used.

See paging_cb_mmsms_est_req() in 'src/libmsc/gsm_04_11.c':

/* FIXME: specify SACCH in case we already have active TCH */
trans->dlci = 0x03;

We should detect somehow if a subscriber has an active TCH connection, and use SACCH.
We can also make this feature configurable from the VTY.

History

#1 Updated by laforge 12 days ago

On Thu, Nov 29, 2018 at 11:47:38PM +0000, fixeria [REDMINE] wrote:

It seems to be normal to use SACCH instead of FACCH for SMS during a voice call.

I think it's even a clear requirement in the spec to do so.

It is supported in OpenBSC, because the information about RAN connection is easily
available there, but OsmoMSC has no access to this information (yet?), so FACCH is used.

See paging_cb_mmsms_est_req() in 'src/libmsc/gsm_04_11.c':

> /* FIXME: specify SACCH in case we already have active TCH */
> trans->dlci = 0x03;
> 

We should detect somehow if a subscriber has an active TCH connection, and use SACCH.

Actually, I think it would be rather odd if we even went through the paging code if we know
there's already a connection.

In fact, shouldn't gsm411_mmsms_est_req() detect that there's already asubscr_conn, and only ever
call subscr_request_conn() and hence trigger a paging request if there is no pre-existing
connection?

We currently check for "if (trans->conn != NULL)", which is true if gsm411_alloc_mt_trans()
detects the subscriber already has an active connection. When gsm411_mmsms_est_req() is
then executed, we should go into the "if (trans->conn != NULL)" clause and never end up
hitting the code path you describe?

We can also make this feature configurable from the VTY.

no. We should always send any SMS over SAPI3 on the SACCH if a TCH is active. Please
note that prioritization of SAPI 0 (signalling) over SAPI 3 (SMS) is also important
to handle correctly here. Not sure if we do that properly.

#2 Updated by fixeria 12 days ago

  • Status changed from New to Feedback
  • Assignee set to fixeria

I think it's even a clear requirement in the spec to do so.
We should always send any SMS over SAPI3 on the SACCH if a TCH is active.

Ok, I found it: GSM TS 04.11, sections 2.2-2.3.

Actually, I think it would be rather odd if we even went through
the paging code if we know there's already a connection.

But what if BSC would allocate a TCH channel (e.g. due to SDCCH congestion)?
Should we consider this case?

Please note that prioritization of SAPI 0 (signalling) over SAPI 3 (SMS)
is also important to handle correctly here. Not sure if we do that properly.

Where should I look to verify this?

Thanks for your notes!

#3 Updated by fixeria 12 days ago

The situation is even more complicated than I initially thought.

First of all, I've introduced a regression during the recent refactoring.
Here is a fix: https://gerrit.osmocom.org/#/c/osmo-msc/+/12043/

Also, I think this is a task of the BSC/BTS to decide, which lchan to use,
i.e. SDCCH or SACCH. Why should the MSC care about that?

Finally, I just tested a MT SMS transfer (initiated from the VTY) during
a voice call between two (not virtual, physical) phones with the fix applied.

Please check out the BSSAP/RSL/LAPDm capture attached:

Frame #76: (BSSAP, SAPI=0x03) MSC initiates MT SMS transfer (CP-/RP-DATA)
Frame #78: (RSL, SAPI=0x00, C-bits: Bm + ACCH) BSC forwards CP-/RP-DATA to the BTS
Frame #83: (LAPDm, SAPI=0x00, FACCH/F) BTS transmits 2nd (final) fragment of CP-/RP-DATA to the MS

Frame #96: (LAPDm, SAPI=0x03, SACCH/F) MS responds with CP-ACK to the BTS
Frame #97: (RSL, SAPI=0x03, C-bits: Bm + ACCH) BTS forwards CP-ACK to the BSC
Frame #98: (BSSAP, SAPI=0x03) BSC forwards CP-ACK to the MSC

Frame #123: (LAPDm, SAPI=0x03, SACCH/F) MS responds with CP-DATA/RP-ACK to the BTS
Frame #124: (RSL, SAPI=0x03, C-bits: Bm + ACCH) BTS forwards CP-DATA/RP-ACK to the BSC
Frame #125: (BSSAP, SAPI=0x03) BSC forwards CP-DATA/RP-ACK to the MSC

Frame #127: (BSSAP, SAPI=0x03) MSC responds with CP-ACK
Frame #129: (RSL, SAPI=0x00, C-bits: Bm + ACCH) BSC forwards CP-ACK to the BTS
Frame #130: (LAPDm, SAPI=0x00, FACCH/F) BTS transmits CP-ACK to the MS

As you can see, during MT message transfer (MSC -> BSC -> BTS -> MS),
OsmoBSC does mangle SAPI value. As a result, the MT transfer happens
on FACCH/F, while the MO transfer happens on SACCH/F. Such a mix!

#5 Updated by fixeria 11 days ago

  • Project changed from OsmoMSC to OsmoBSC
  • Subject changed from Use SACCH for MO/MT SMS during a voice call to Use SACCH for MO/MT SMS signalling during a voice call
  • Category changed from SMS to A interface
  • Priority changed from Low to High
  • % Done changed from 0 to 90

It turns out the problem was in OsmoBSC, not in OsmoMSC. Please see:

https://gerrit.osmocom.org/#/c/osmo-bsc/+/12053

With this change applied, the whole signalling goes through SACCH, as expected.
Manually tested with two (physical, not virtual) phones and osmo-bts-trx.

#6 Updated by fixeria 11 days ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

Both patches have been merged, SMS goes over SACCH now.

#7 Updated by fixeria 10 days ago

  • Tracker changed from Feature to Bug
  • Status changed from Resolved to Stalled
  • Assignee deleted (fixeria)
  • Priority changed from High to Low
  • % Done changed from 100 to 80

We still need a test case that should basically:

1) establish a dedicated TCH channel,
2) send a few messages on SAPI0 and make sure they appear on FACCH,
3) send a few messages on SAPI3 and make sure they appear on SACCH.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)