Bug #3154
closedosmo-hlr should send updated subscriber data to relevant VLR/SGSN only
100%
Description
When subscriber data is changed in the HLR database, osmo-hlr sends Insert Subscriber Data messages to all connected GSUP clients.
This behaviour was introduced in patch https://gerrit.osmocom.org/#/c/7685/ (see osmo_hlr_subscriber_update_notify() in hlr.c) for issue #2785.
As noted in the code comment added in this patch, it would be better to only send notifications to VLR/SGSN which are responsible for the subscriber.
Related issues
Updated by neels almost 6 years ago
- Related to Bug #2796: OsmoHLR doesn't update VLR during UpdateLocation added
Updated by neels almost 6 years ago
- Related to Bug #2785: OsmoHLR forgets to send InsertSubscriberData to VLR/SGSN when data changes added
Updated by laforge almost 6 years ago
- Priority changed from Low to Urgent
this is actually a very serious problem. I dint't really notice this issue until now.
The questions is not one about scalability or size of the network, or one of optimization. By definition, a subscriber record is only present in the one serving VLR (and optionally serving SGSN, if there is packet services).
blindly inserting a subscriber into every HLR/VLR out there will break mobility management across VLR/SGSN coverage areas. What this means is that subscribers can actually witch from one VLR coverage area into another VLR coverage area without having to do a Location Update. Normally, that Location Update is what will trigger creating the subscriber record in the VLR. However, we're blindly creating them in advance on every VLR in the network.
In short: The entire data / consistency model of when subscriber information is where is completely broken by the current behavior :/
I actually think the safe choice for now is to disable sending ISD on subscriber changes until this is sorted out. I'll submit a patch shortly.
Updated by laforge almost 6 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
I've reverted to the old behavior in https://gerrit.osmocom.org/#/c/osmo-hlr/+/9647 and re-opened #2785, so we can mark this bug as resolved.