Project

General

Profile

Actions

Bug #2796

closed

OsmoHLR doesn't update VLR during UpdateLocation

Added by laforge about 6 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
12/30/2017
Due date:
% Done:

100%

Spec Reference:

Description

For some reason, the VLR column in the HLR table is not updated when a subscriber performs an Update Location procedure.


Related issues

Related to OsmoHLR - Bug #3154: osmo-hlr should send updated subscriber data to relevant VLR/SGSN onlyResolved04/10/2018

Actions
Related to OsmoMSC - Bug #3355: OsmoMSC doesn't provide unique IDTAG_SERNR in IPA CCMResolvedstsp06/23/2018

Actions
Related to OsmoSGSN - Bug #3356: OsmoSGSN doesn't provide unique IDTAG_SERNR in IPA CCMIn Progressosmith06/23/2018

Actions
Related to OsmoMSC - Bug #3601: OsmoMSC's GSUP client doesn't send CN domain to the HLRResolvedneels09/28/2018

Actions
Actions #1

Updated by neels about 6 years ago

What should go in the VLR column? We have the IPAC_IDTAG_SERNR producing something like "SGSN-00-00-00-00-00-00" and "MSC-00-00-00-00-00-00". The HLR also has sgsn_number and sgsn_address columns, could be set to the same / to the remote GSUP client address, by switching on osmo_gsup_message.cn_domain...

Actions #2

Updated by neels about 6 years ago

the IDTAG_SERNR is handled in osmo_gsup_server_ccm_cb() in osmo-hlr/src/gsup_server.c

Actions #3

Updated by laforge about 6 years ago

In a real 3GPP HLR with MAP, it's the global title of the respective VLR which is stored.

For us, it is "any other unique identifier of the VLR", and I think it hasn't been specified yet so far.

I'm against using the IP address, as this will break all kinds of dynamic address or NAT scenarios (which currently work as GSUP is a strict client->server protocol).

IDTAG_SERNR might be an idea, maybe also some other IDTAG? We should make it user-configurable then to ensure multiple MSCs have differnet identifiers.

Actions #4

Updated by neels almost 6 years ago

  • Related to Bug #3154: osmo-hlr should send updated subscriber data to relevant VLR/SGSN only added
Actions #5

Updated by laforge over 5 years ago

  • Related to Bug #3355: OsmoMSC doesn't provide unique IDTAG_SERNR in IPA CCM added
Actions #6

Updated by laforge over 5 years ago

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

Updated by neels over 5 years ago

(isn't this related to some of stsp's work in the HLR?)

Actions #8

Updated by neels over 5 years ago

With the next C3 approaching, I took a look at this again.

I have a patch that stores the IPAC_IDTAG_SERNR for VLR and SGSN number in the HLR database.
The only problem is that this vlr_number is specified as 15 digits max,
while the MSC and SGSN currently send e.g. 'MSC-00-00-00-00-00-00' -- that's 21 characters.

So the current patch says "skipping 'MSC-00-00-00-00-00-00' != 'MSC-00-00-00-00'" -- mismatch because the id is truncated on its round trip through struct hlr_subscriber and the database.

Would it be a bad idea to just make the vlr_number and sgsn_number fields in hlr_subscriber longer? They are currently limited by GT_MAX_DIGITS, which makes sense if it really were a Global Title. But all it would take is to enlarge the vlr_number and sgsn_number storage in struct hlr_subscriber.

DB wise, SQLite db bootstrapping gives a length indication of VARCHAR, but in fact this is just an optional indicator, and SQLite happily stores any length of string without modifications.

Another idea would be to strip the dashes, because MSC000000000000 is exactly 15 digits.

None of this is really nice though. Any ideas? Does it need to be nice?

Actions #9

Updated by neels over 5 years ago

  • Related to Bug #3601: OsmoMSC's GSUP client doesn't send CN domain to the HLR added
Actions #10

Updated by laforge over 5 years ago

I think the key aspect here is that the storage is completely transparent and
can store either ACII or binary data. global titles have no good/standard ASCII
representation, as they include tons of fields like NPI, TON, which are meta-data
next to the actual digits of the 'phone number'.

OsmoHLR should ideally treat this address as an opaqua block and not attempt to
interpret its content, assume it's ASCII or follows any specific format. It's just
something the VLR and SGSN specify during IPA CCM, and which is stored in the database
and used to route later requests to that given VLR or SGSN.

Having said that, we can of course increase the size of the field in the database.

Actions #11

Updated by laforge over 5 years ago

Since June, the laforge/ussd branch of osmo-hlr.git contains an untested commit to store the VLR identity in UpdateLocation. It's ChangeID Ib2611421f3638eadc361787af801fffe9a34bd8a

Actions #12

Updated by neels over 5 years ago

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

https://gerrit.osmocom.org/11232 is a combination of the mentioned branch and what I had tossed up.

Actions #13

Updated by neels over 4 years ago

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

merged more than a year ago ... sorry about missing update

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)