https://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-04-30T12:03:41ZOpen Source Mobile CommunicationsOsmoHLR - Bug #3154: osmo-hlr should send updated subscriber data to relevant VLR/SGSN onlyhttps://osmocom.org/issues/3154?journal_id=90782018-04-30T12:03:41Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/2796">Bug #2796</a>: OsmoHLR doesn't update VLR during UpdateLocation</i> added</li></ul> OsmoHLR - Bug #3154: osmo-hlr should send updated subscriber data to relevant VLR/SGSN onlyhttps://osmocom.org/issues/3154?journal_id=90792018-04-30T12:04:05Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-3 priority-high3 closed" href="/issues/2785">Bug #2785</a>: OsmoHLR forgets to send InsertSubscriberData to VLR/SGSN when data changes</i> added</li></ul> OsmoHLR - Bug #3154: osmo-hlr should send updated subscriber data to relevant VLR/SGSN onlyhttps://osmocom.org/issues/3154?journal_id=99252018-06-15T15:49:13Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Low</i> to <i>Urgent</i></li></ul><p>this is actually a <strong>very serious</strong> problem. I dint't really notice this issue until now.</p>
<p>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).</p>
<p>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.</p>
<p>In short: The entire data / consistency model of when subscriber information is where is completely broken by the current behavior :/</p>
<p>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.</p> OsmoHLR - Bug #3154: osmo-hlr should send updated subscriber data to relevant VLR/SGSN onlyhttps://osmocom.org/issues/3154?journal_id=99262018-06-15T15:49:37Zlaforge
<ul></ul> OsmoHLR - Bug #3154: osmo-hlr should send updated subscriber data to relevant VLR/SGSN onlyhttps://osmocom.org/issues/3154?journal_id=99282018-06-15T16:08:03Zlaforge
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>I've reverted to the old behavior in <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-hlr/+/9647">https://gerrit.osmocom.org/#/c/osmo-hlr/+/9647</a> and re-opened <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: OsmoHLR forgets to send InsertSubscriberData to VLR/SGSN when data changes (Resolved)" href="https://osmocom.org/issues/2785">#2785</a>, so we can mark this bug as resolved.</p>