Project

General

Profile

Bug #5188

BSSMAP Cell Identifier IE vs. Cell Identifier List IE: difference in allowed cell id types

Added by neels about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
06/23/2021
Due date:
% Done:

0%

Spec Reference:

Description

In libosmocore, we have enum CELL_IDENT, which gets used in both of
Cell Identifier IE (3GPP TS 48.008 3.2.2.17)
and
Cell Identifier List IE (3GPP TS 48.008 3.2.2.27)

The similar meaning and structuring of these two IEs suggests that the List IE
is simply a bunch of the plain Cell Identifier. However, if you read in 3GPP TS
48.008, comparing 3.2.2.17 and 3.2.2.27, there is this odd difference:

3.2.2.17, Cell Identifier IE:

0000 CGI
0001 LAC+CI
0010 CI
0011 No cell
1000 PLMN+LAC+RNC (-> E-UTRAN)
1001 RNC (-> E-UTRAN)
1010 LAC+RNC (-> E-UTRAN)
1011 SAI
1100 LAC+RNC+CI

3.2.2.27a, Cell Identifier List Segment:

0000 CGI
0001 LAC+CI
0010 CI
0011 No cell
0100 LAI
0101 LAC
0110 entire BSS
0111 MCC+MNC

I noticed this because I was trying to check for the correct target cell
identifier in the BSSMAP Handover Request message; we send a LAI cell
identification in the Cell Identifier IE. wireshark shows the LAI cell
identifer the same way that osmo-msc intends to encode it, but the TTCN3
BSSAP_Templates fail to parse this LAI cell identifier.

So I added this cell id type to BSSMAP_IE_CellIdentifier in
./deps/titan.ProtocolModules.BSSMAP/src/BSSAP_Types.ttcn. and just to confirm
that I'm right i took a quick look in the spec, and then found that the ttcn
definition is in fact on par with the spec: the LAI cell id is not
present in 3.2.2.17 at all!

Now, our libosmocore gsm/protocol/gsm_08_08.h and gsm0808_utils.h are based on
the assumption that the same cell identifiers are used in both of these IEs.

The osmo-bsc and osmo-msc neighbor config for inter-BSC handover is built
assuming that we can send the 3.2.2.27a cell identifiers in the Handover
Request's 'Cell Identifier (Target)' IE.

Apparently the spec intends otherwise.

The effect of this goes across several osmo cn components:

  • We define enum CELL_IDENT in libosmocore.
  • osmo-bsc sends the Handover Request using the 'Cell Identifier (Serving)' and 'Cell Identifier (Target)' IEs.
  • osmo-msc parses these, possibly forwards in inter-MSC handover procedure.

I'm not sure how to resolve this.

  • We could just accept that we're using the 3.2.2.27a identifiers also in 3.2.2.17. It makes an awful lot of sense in fact.
    The wireshark implementation seems to agree with this point, though of course that's not the benchmark.
    It might pose an incompatibility with strictly spec conforming cn implementations.
    And we would need to extend the TTCN BSSAP_Types.ttcn with values that aren't strictly present in 3.2.2.17,
    if we want to test these cell identifier types in our test suite.
  • or we could endeavour to fix the identifiers that we use in the BSSMAP protocol according to spec, in osmo-bsc and osmo-msc
    • either we introduce two distinct enums -- that could ripple through a lot of the cell identifier API, ugly.
    • or we still use the same enum for both, but making distinctions in the implementations which values are used for which.

To enforce that, we may have to adjust which cell identifier types can be used in the neighbor configuration of osmo-bsc and osmo-msc,
or we find ways to, for example, convert all cell identifier types to a supported one.
I guess easiest would be to enforce full CGI everywhere.

Yet easier would be to highlight in the documentation that osmocom is capable of nonstandard cell identifiers,
and to conform to specs users should simply use the full CGI everywhere in the neighbor config.

Any insights or opinions on this?

Associated revisions

Revision 2822d07a (diff)
Added by Neels Hofmeyr about 1 month ago

msc: inter-BSC HO test: use CGI cell ID, not LAI

In the inter-BSC 'Handover Required', do not send a LAI cell identifier,
but a CGI one.

Rationale:

As explained in OS#5188, 3GPP TS 48.008 allows a LAI identification only
in the Cell Identifier List IE, but not in the single Cell Identifier
IE.

In the inter-BSC HO test's Handover Required message, we so far send a
LAI identifier in a List IE to osmo-msc. And so far, osmo-msc simply
echos that in the Handover Request message's single Cell Id IE.

The LAI is, as actually defined in the spec, omitted from the single IE
in deps/titan.ProtocolModules.BSSMAP/src/BSSAP_Types.ttcn, and when
osmo-msc sends the non-standard LAI Id, ttcn3 fails to parse the BSSMAP
Handover Request message: the Cell Identifier IE gets wrong values, and
all remaining IEs are parsed as 'omit' even though they are present on
the wire. So as long as osmo-msc sends back a LAI Id, we cannot sanely
verify the Handover Request received from the MSC.

The CGI identifier type is supported in both IEs. So when the test sends
a CGI identifier in the Handover Required, osmo-msc will also reflect a
CGI identifier in the Handover Request, and ttcn3 parsing works.

This prepares for adding verification of the ciphering in inter-BSC
handover, in turn a preparation for adding tests of A5/4.

Related: OS#5188 SYS#5324
Change-Id: I48276acf923626db171683dfa03ef43614a71380

Revision 36ebc331 (diff)
Added by Neels Hofmeyr 24 days ago

msc: inter-MSC HO test: use CGI cell ID, not LAI

Fixes inter-MSC handover tests: in the inter-MSC 'Handover Required', do
not send a LAI cell identifier, but a CGI one.

This is analogous to the fix applied to inter-BSC HO in
I48276acf923626db171683dfa03ef43614a71380.

Rationale:

As explained in OS#5188, 3GPP TS 48.008 allows a LAI identification only
in the Cell Identifier List IE, but not in the single Cell Identifier
IE.

In the inter-MSC HO test's Handover Required message, we so far send a
LAI identifier in a List IE to osmo-msc. And so far, osmo-msc simply
echos that in the Handover Request message's single Cell Id IE.

The LAI is, as actually defined in the spec, omitted from the single IE
in deps/titan.ProtocolModules.BSSMAP/src/BSSAP_Types.ttcn, and when
osmo-msc sends the non-standard LAI Id, ttcn3 fails to parse the BSSMAP
Handover Request message: the Cell Identifier IE gets wrong values, and
all remaining IEs are parsed as 'omit' even though they are present on
the wire. So as long as osmo-msc sends back a LAI Id, we cannot sanely
verify the Handover Request received from the MSC.

The CGI identifier type is supported in both IEs. So when the test sends
a CGI identifier in the Handover Required, osmo-msc will also reflect a
CGI identifier in the Handover Request, and ttcn3 parsing works.

Related: OS#5188 SYS#5324
Change-Id: I525b5deaa9634fcdb63fbd2c97c767aff045767c

History

#1 Updated by laforge about 1 month ago

On Wed, Jun 23, 2021 at 12:43:19AM +0000, neels [REDMINE] wrote:

Any insights or opinions on this?

The A interface is the most important point of interop between RAN and CN, and
it is important for many users that osmo-bsc interoperates with diffent CN out
there. So I don't think we can deviate here from what the spec permits.

For sure we can optionally extend AoIP if we know osmo-msc is on the other side,
but we always must have a spec compliant use of AoIP as a base line.

#2 Updated by neels about 1 month ago

On Wed, Jun 23, 2021 at 10:10:15AM +0000, laforge [REDMINE] wrote:

For sure we can optionally extend AoIP if we know osmo-msc is on the other side,
but we always must have a spec compliant use of AoIP as a base line.

As long as the neighbors in the osmo-bsc.cfg are configured using CGI or
only-LAC, the Handover Request will be compliant. So instead of enforcing (or
converting), we could tell the users to take care with their neighbor config...

Using other cell identifiers could be seen as a feature. The feature being,
osmo-msc could translate other cell id kinds to CGI before sending in the HO
Request. For that osmo-msc.cfg must also provide the full CGI of neighbors.

so step one would be informing the users to rather use full CGI everywhere.
Apart from that we can analyse how to enforce a valid cell id type in osmo-msc.

#3 Updated by laforge about 1 month ago

On Wed, Jun 23, 2021 at 05:06:21PM +0000, neels [REDMINE] wrote:

As long as the neighbors in the osmo-bsc.cfg are configured using CGI or
only-LAC, the Handover Request will be compliant. So instead of enforcing (or
converting), we could tell the users to take care with their neighbor config...

I would think the default in osmo-bsc should be to only accept spec compliant
neighbor configs. The additional options should be enabled/permitted
only by another vty command like "osmocom-aoip-extensions enabled"

Does that make sense?

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)