https://osmocom.org/https://osmocom.org/favicon.ico?16647414092017-10-11T01:50:14ZOpen Source Mobile CommunicationsOsmoHLR - Feature #2567: tell the MSC(s) when subscriber data has changedhttps://osmocom.org/issues/2567?journal_id=56882017-10-11T01:50:14Zlaforge
<ul></ul><p>Hi Neels,</p>
<p>On Tue, Oct 10, 2017 at 03:12:37PM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>Say the operator changes the subscriber's MSISDN in the HLR database,<br />the MSC may still maintain the old MSISDN in the VLR memory. If<br />possible, we should tell the VLR about the change.</p>
</blockquote>
<p>correct. An "insert subscriber data" is required to update the data in<br />the serving VLR + serving SGSN.</p>
<blockquote>
<p>We could send out notifications to all connected GSUP clients.</p>
</blockquote>
<p>I don't think this is a good idea, as (at least with normal MAP<br />semantics) it would <strong>create</strong> the subscriber record in all VLRs/SGSNs<br />unconditionally. I would'nt want to create a "update only, don't<br />create" flag, as that doesn't exist in MAP semantics.</p>
<p>In fact, the message should only be sent to the current serving VLR +<br />serving SGSN, which the HLR should be tracking anyway (in order to be<br />able to route incoming MT-SMS/calls to the right VLR).</p>
<blockquote>
<p>But what if there are bulk changes?</p>
</blockquote>
<p>Like changing every subscribers phone number? I think that's somewhat<br />unlikely? I don't think we should have to care about this now.</p>
<p>Or are you referring to changing 6 parameters of a single subscriber,<br />and you want to avoid 6 consecutive insert subscriber data?</p>
<blockquote>
<p>In that case one might prefer to wait for the next full location<br />updating instead...</p>
</blockquote>
<p>I wouldn't want us to spend too much time worrying about this at the<br />moment. It's unclear if (e.g. in the context of LTE support), we'd be<br />phasing out OsmoHLR in favor of a GPUP-to-DIAMETER translator and a<br />DIAMETER capable HSS. Community Cellular Manager is using their own<br />python GSUP server, too.</p>
<p>For sure, we should track and document known limitations, but before<br />taking action we have to think about how far we want to take OsmoHLR in<br />its current form. This is an open discussion.</p>