vlr+hlr: Insert Data

[Jacob Erlbeck]

Hi,

On 02/09/2017 02:53 PM, Neels Hofmeyr wrote:
> What should we do if the HLR sends no Insert Data?
> 
> When a subscriber does a Location Updating, the VLR sends a Location Updating
> request to the HLR. The HLR typically responds with a Location Updating Result
> as success and, in a *separate* message, sends an Insert Data to the VLR to
> tell it the subscriber's MSISDN. So it is possible to do a successful Location
> Updating without being told the MSISDN (as my test verifies).

I did not find much in 29.002 that tells otherwise. There is only figure
19.1.1/3 which states that the insert messages are not optional by not
using italics. The automatons in 19.1.1/6 and 19.1.1/13 do not impose
such a restriction.

> 
> What should the VLR do if it never receives the Insert Data from the HLR? In
> that case the subscriber is attached but cannot be reached by MSISDN. Should
> we actively wait for Inser Data and reject the subscriber if not successful?

The MS can still be happy without an MSISDN: GPRS, USSD, MT-calls,
MT-SMS shouldn't need it. Or the HLR may decide to send an update with
an MSISDN later on (or change it).

> 
> It would be fairly easy to just send the MSISDN along in the Location Updating
> Result. Why this separate message?

In my understanding, the MAP UpdateLocationArg and UpdateLocationRes
messages rather contain information directly related to the location
update. The subscriber infos are modified by the insertSubscriberData
and deleteSubscriberData operations which can also appear in different
application contexts (networkLocUpContext, subscriberDataMngtContext,
...). So it makes sense to separate that from the UpdateLocationRes
message. In addition, you can send any amount of subscriber data items
but the maximum size of each single MAP message may be limited.

Nevertheless it's difficult to handle in cases where you just need some
information about a certain IMSI. That is why it is done differently in
GSUP where the complexity of MAP can be handled by a separate proxy, and
there is no such a size restriction.

Jacob

> 
> Thx,
> 
> ~N
>