Project

General

Profile

Bug #3355

OsmoMSC doesn't provide unique IDTAG_SERNR in IPA CCM

Added by laforge 5 months ago. Updated about 2 months ago.

Status:
New
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
06/23/2018
Due date:
% Done:

0%

Resolution:

Description

OsmoMSC currently identifies itself simply as "MSC" over the IPA/GSUP link to OsmoHLR.

This is wrong as it results in all OsmoMSCs (in a multi-MSC network) to register using the same identity, which in turn will render the HLR unable to store which MSC is actually serving the subscriber, and/or to route mesages accordingly.

It appears the change to "MSC" was made in Change-Id: I0a60681ab4a4d73e26fe8f0637447db4b6fe6eb2 from "SGSN-00-00-00-00-00-00" before. Both the old and the new name are wrong though, as they're not unique.

The correct behavior AFAICT is "MSC-" prefix with whatever unque identifier behind. We could make that suffix configurable in the VTY, if there's no other way to derive any other locally unique identifier. MAC adresses work fine for BTSs, but not for MSCs: There might be any number of OsmoMSCs running on the same physical / virtual machine with only one MAC address...


Related issues

Related to OsmoHLR - Bug #2796: OsmoHLR doesn't update VLR during UpdateLocationIn Progress2017-12-30

Related to OsmoSGSN - Bug #3356: OsmoSGSN doesn't provide unique IDTAG_SERNR in IPA CCMNew2018-06-23

History

#1 Updated by laforge 5 months ago

  • Related to Bug #2796: OsmoHLR doesn't update VLR during UpdateLocation added

#2 Updated by laforge 5 months ago

  • Related to Bug #3356: OsmoSGSN doesn't provide unique IDTAG_SERNR in IPA CCM added

#3 Updated by laforge 5 months ago

Note: The identifier must stay unique even across re-starts of the MSC.

#4 Updated by stsp 4 months ago

Would uuid_generate be a reasonable solution?
https://linux.die.net/man/3/uuid_generate

#5 Updated by neels 3 months ago

stsp wrote:

Would uuid_generate be a reasonable solution?
https://linux.die.net/man/3/uuid_generate

The difficulty is to get the same UUID across program restarts, i.e. no random involved.
We should probably use an ID to be set in the config file (and loudly error-log if missing)?

#6 Updated by neels about 2 months ago

it would be good if the identification were at most 15 characters wide, so it fits in the HLR's vlr_number.

#7 Updated by neels about 2 months ago

neels wrote:

it would be good if the identification were at most 15 characters wide, so it fits in the HLR's vlr_number.

OK, turns out the GSUP clients are free to send pretty much anything they wants (in the sense of arbitrary Global Title),
and osmo-hlr should be able to deal with that.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)