Project

General

Profile

Bug #3716

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

Added by fixeria about 2 years ago. Updated 5 months ago.

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

100%

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.

Associated revisions

Revision 0620b371 (diff)
Added by Vadim Yanitskiy about 2 years ago

osmo_bsc_bssap.c: fix incorrect link_id assignment

Every DTAP message coming from the MSC has a header (see struct
dtap_header) that contains message type, length, and link ID.
The link ID indicates SAPI and channel type of a given message.

In dtap_rcvmsg() we allocate a new message buffer and copy the
received message into it. The old message buffer is freed by
the caller then.

The link ID value parsed from DTAP header is usually being stored
in the control buffer of a message buffer (i.e. msgb->cb). Due to
a mistake, it was stored in the old (to be freed) message, while
the new (to be forwarded) message always had link_id = 0x00!

This change resolves the problem with sending SMS during a voice
call, when MT signalling goes through FACCH, while MO signalling
goes through SACCH.

Change-Id: I7675e1ce4436fad836778261ac9d446fa8f81483
Related: OS#3716

Revision a88fa1f1 (diff)
Added by fixeria 5 months ago

RSL/BSSAP: fix: properly convert between RSL Link ID and DLCI

Data Link Connection Identifier (DLCI) is defined in 3GPP TS 48.006,
section 9.3.2, and coded as follows:

.... .SSS - SAPI value used on the radio link;
CC.. .... - control channel identification:
00.. .... - indicates that the control channel is not further specified,
10.. .... - represents the FACCH or the SDCCH,
11.. .... - represents the SACCH,
other values are reserved.

RSL Link Identifier is defined in 3GPP TS 3GPP TS 48.058,
section 9.3.2, and coded as follows:

.... .SSS - SAPI value used on the radio link;
...P P... - priority for SAPI0 messages;
CC.. .... - control channel identification:
00.. .... - main signalling channel (FACCH or SDCCH),
01.. .... - SACCH,
other values are reserved.

As can be seen, CC bits in both DLCI and RSL Link Identifier
are coded differently. Therefore, we cannot just assign
one identifier to another, we need to do conversion.

I noticed that osmo-bsc indicates DLCI '01000011'B for SMS
messages sent over SACCH/F (SAPI3), and this is wrong because
'01'B is reserved. Let's fix this.

P.S. Interesting coincidence: section 9.3.2 in both documents.

Change-Id: If4d479a54cad467f53b49065c1c435a4471ac7d2
Related: Ica69ae95b47a67ba99ba9cc36629b6bd210d11e4
Related: OS#3716

History

#1 Updated by laforge about 2 years 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 about 2 years 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 about 2 years 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 about 2 years 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 about 2 years 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 about 2 years 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.

#8 Updated by laforge almost 2 years ago

  • Assignee set to fixeria

#9 Updated by fixeria 5 months ago

  • Status changed from Stalled to In Progress

#10 Updated by fixeria 5 months ago

  • Status changed from In Progress to Feedback
  • % Done changed from 80 to 100

I finally came up with a test case:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20385 BSC_Tests: introduce TC_tch_dlci_link_id_sapi for OS#3716

this test case depends on the following misc/cosmetic changes:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20382 BSC_Tests: s/f_verify_active_layer3/f_mo_l3_transceive/g
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20383 BSC_Tests: parametrize f_mo_l3_transceive()
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20384 BSC_Tests: introduce f_mt_l3_transceive() sending BSSAP -> RSL

Of course, it reveals some problems in osmo-bsc: we cannot assign RSL Link ID to DLCI and vice versa, we need to convert:

https://gerrit.osmocom.org/c/osmo-bsc/+/20386 RSL/BSSAP: fix: properly convert between RSL Link ID and DLCI

and dissection problems in Wireshark:

https://gitlab.com/wireshark/wireshark/-/merge_requests/458/diffs?commit_id=9cef4e36294b3003c37b5369785e0105538573df

#11 Updated by fixeria 5 months ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)