Project

General

Profile

Actions

Bug #3548

closed

COMPLETE LAYER 3 INFORMATION does not contain Codec List (BSS Supported) information element

Added by dexter over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
09/12/2018
Due date:
% Done:

100%

Spec Reference:

Description

3GPP TS 48.008 3.2.1.32, COMPLETE LAYER 3 INFORMATION clearly states that the information element Codec List (BSS Supported) must be included when AoIP is used. "Codec List (BSS Supported) shall be included, if the radio access network supports an IP based user plane interface."

The lack of the mentioned information element may cause interop problems with thrid party MSCs.


Files

Actions #1

Updated by dexter over 5 years ago

Attached one finds a trace from a MO call with osmo-bsc and osmo-msc.

From what I unterstand the IE Codec List (BSS Supported) is all about what the BSS supports. So there we would send what codecs/rates the BTS which currently handles the call can support. In 3GPP TS 48.008 3.1.1.1 one can read:

"The MSC is the entity that carries out the necessary analysis on the call control information received from the MS or
fixed network customer. If an IP based user plane interface is supported, the Codec List (BSS supported) shall be taken
into account, considering the Codec capabilities of the core network, aiming for true end-to-end Codec negotiation and
for common supported Codec(s)."

Also when I look at the trace, the codecs that the MS supports become known way later with the SETUP. The CM SERVICE REQUEST carries a Mobile Station Classmark 2, but that one is only about basic capabilities like encryption PS capability etc, but not codecs.

So I think what we need to do is to lookup what codecs are configured for the BTS in particular VTY (VTY-Setting) and package that info into a Codec List.

Actions #2

Updated by laforge over 5 years ago

On Wed, Sep 12, 2018 at 04:41:09PM +0000, dexter [REDMINE] wrote:

So I think what we need to do is to lookup what codecs are configured for the BTS in particular VTY (VTY-Setting) and package that info into a Codec List.

well, to be more precise, what we need to support is the intersection of
  • BTS hardware/firmware capabilities (nanoBTS doesn't do HRv1, BS11 doesn't do AMR, ...)
  • BSC VTY/config file policy for BTS (if any)
  • BSC VTY/config file policy for BSC/"msc" (if any)
Actions #3

Updated by dexter over 5 years ago

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

Codec List (BSS Supported) is now included in COMPLETE LAYER 3 INFORMATION. Unfortunately I still have problems getting the configuration for AMR (S0-S15) right. While the unit-tests work there is still something wrong in the real world. I keep getting 0x0000 as configuration for AMR. All other codecs that do not have S0-S15 look good so far.

The following related patches are now in review:

https://gerrit.osmocom.org/#/c/libosmocore/+/10961 gsm0808: add function to convert amr gsm0408 setings to gsm0808
https://gerrit.osmocom.org/#/c/osmo-bsc/+/10963 codec_pref: add AMR configuration bits to make_scl_config in unit-test
https://gerrit.osmocom.org/#/c/osmo-bsc/+/10964 codec_pref: fix missing breaks in switch-case statement
https://gerrit.osmocom.org/#/c/osmo-bsc/+/10965 codec_pref: Add Codec List to COMPLETE LAYER 3 INFORMATION

I also added a TTCN3 test that at least checks if the Codec List (BSS Supported) is present in COMPLETE LAYER 3 INFORMATION

https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/10966 MSC_ConnectionHandler: Make sure COMPLETE LAYER 3 INFORMATION contains a ...

Actions #4

Updated by neels over 5 years ago

Just a side note, you mentioned that you would rather not include this IE for SCCPlite, but 48.008 3.2.1.32 says:

NOTE 4: Codec List (BSS Supported) shall be included, if the radio access network
supports an IP based user plane interface.

We use osmo-mgw == an IP based user plane interface for both AoIP and SCCPlite, so this is mandatory for all our A-interface implementations.
So add this IE for SCCPlite as well, please.

Actions #5

Updated by laforge over 5 years ago

On Fri, Sep 21, 2018 at 12:04:25PM +0000, neels [REDMINE] wrote:

We use osmo-mgw == an IP based user plane interface for both AoIP and SCCPlite, so this is mandatory for all our A-interface implementations.
So add this IE for SCCPlite as well, please.

sorry, but absolutely not!

either there is an BSSAP/SCCP interface using circuit identity codes adhering to the specs
before AoIP was introduced, or it is an AoIP interface.

So for SCCPlite, everything must look exactly like in legacy E1/TDM based networks.

Actions #6

Updated by dexter over 5 years ago

  • % Done changed from 50 to 80

I think we now have a good speech codec list in the COMPLETE LAYER 3 INFORMATION message. The test look good so far, but I get build failures on jenkins which I do not understand yet.

See also:

https://gerrit.osmocom.org/#/c/osmo-bsc/+/11058 gsm_data.c: Set reasonable AMR codec defaults in gsm_bts_alloc()
https://gerrit.osmocom.org/#/c/osmo-bsc/+/11059 assignment_fsm: only include speech codec (choosen) on AoIP networks
https://gerrit.osmocom.org/#/c/osmo-bsc/+/10965 codec_pref: Add Codec List to COMPLETE LAYER 3 INFORMATION [WIP]

Actions #7

Updated by neels over 5 years ago

laforge wrote:

On Fri, Sep 21, 2018 at 12:04:25PM +0000, neels [REDMINE] wrote:

We use osmo-mgw == an IP based user plane interface for both AoIP and SCCPlite, so this is mandatory for all our A-interface implementations.
So add this IE for SCCPlite as well, please.

sorry, but absolutely not!

either there is an BSSAP/SCCP interface using circuit identity codes adhering to the specs
before AoIP was introduced, or it is an AoIP interface.

Wait, what? To me it looks like our user plane is definitely going over IP?
Maybe we should talk about that in person some time to clarify...

Actions #8

Updated by laforge over 5 years ago

On Sun, Sep 23, 2018 at 02:09:30PM +0000, neels [REDMINE] wrote:

either there is an BSSAP/SCCP interface using circuit identity codes adhering to the specs
before AoIP was introduced, or it is an AoIP interface.

Wait, what? To me it looks like our user plane is definitely going over IP?

This is a way too literal and narrow look on the subject matter.

Put yourself into the position of the 3GPP spec author when you update a specification
that so far only supported E1/T1/TDM based transmission and you now add AoIP support to it.

If you then phrase something like "an IP based user plane interface", then you are referring
to AoIP. Even more so, you are referring to the specific use case where AoIP is used for signaling,
and also an IP/RTP bearer is negotiated in AoIP signaling. Remember, even in AoIP signaling,
you can still negotiate a TDM-based bearer using CIC!

The person updating the 3GPP spec clearly is not thinking about some proprietary, vendor-specific,
nowhere-specified hack that some people at some point have put together at ip.access, Altobridge
and others to transport the classic A interface over an IP bearer - because to him that doesn't
exist, as it wasn't part of 3GPP specs.

Actions #9

Updated by dexter over 5 years ago

  • % Done changed from 80 to 90

The build problem is now fixed. The problem was that osmo-bsc couln't re-read the config once it was written. The reason for this was that the config only allows a set of up to four rates (active set). I had selected more. We now have a reasonable default of four codecs and the python tests are fine again. I also removed the WIP flag for 10965.

Actions #10

Updated by dexter over 5 years ago

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

The related patch made it into master. Osmo-bsc now includes the speech codec list in the assignment complete message when the network is an AoIP network. When sccp-lite is in use the IE is omitted.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)