Project

General

Profile

Bug #3548

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

Added by dexter 12 days ago. Updated about 7 hours ago.

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

80%

Estimated time:
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.

History

#1 Updated by dexter 11 days 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.

#2 Updated by laforge 11 days 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)

#3 Updated by dexter 9 days 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 ...

#4 Updated by neels 2 days 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.

#5 Updated by laforge 2 days 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.

#6 Updated by dexter 2 days 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]

#7 Updated by neels about 8 hours 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...

#8 Updated by laforge about 7 hours 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)