Bug #2796
closedOsmoHLR doesn't update VLR during UpdateLocation
Added by laforge over 6 years ago. Updated over 4 years ago.
100%
Description
For some reason, the VLR column in the HLR table is not updated when a subscriber performs an Update Location procedure.
Related issues
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...
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
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.
Updated by neels almost 6 years ago
- Related to Bug #3154: osmo-hlr should send updated subscriber data to relevant VLR/SGSN only added
Updated by laforge almost 6 years ago
- Related to Bug #3355: OsmoMSC doesn't provide unique IDTAG_SERNR in IPA CCM added
Updated by laforge almost 6 years ago
- Related to Bug #3356: OsmoSGSN doesn't provide unique IDTAG_SERNR in IPA CCM added
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?
Updated by neels over 5 years ago
- Related to Bug #3601: OsmoMSC's GSUP client doesn't send CN domain to the HLR added
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.
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
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.
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
