Project

General

Profile

Actions

Bug #3154

closed

osmo-hlr should send updated subscriber data to relevant VLR/SGSN only

Added by stsp almost 6 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
-
Target version:
-
Start date:
04/10/2018
Due date:
% Done:

100%

Spec Reference:

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

Related to OsmoHLR - Bug #2796: OsmoHLR doesn't update VLR during UpdateLocationResolvedneels12/30/2017

Actions
Related to OsmoHLR - Bug #2785: OsmoHLR forgets to send InsertSubscriberData to VLR/SGSN when data changesResolvedneels12/28/2017

Actions
Actions #1

Updated by neels almost 6 years ago

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

Updated by neels almost 6 years ago

  • Related to Bug #2785: OsmoHLR forgets to send InsertSubscriberData to VLR/SGSN when data changes added
Actions #3

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.

Actions #4

Updated by laforge almost 6 years ago

Actions #5

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.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)