Hi Jacob,

many thanks for these explanations and pointers!

On Mon, Feb 13, 2017 at 08:13:06AM +0100, Jacob Erlbeck wrote:

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.

Hmm, I don't really see a difference there. To me it all looks like "in case an Insert Subscriber Data {Ind,Req} is received, handle it", and no consequence if it's missing. So the lack of italics itself says it's mandatory? :)

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).

Yes, but I assume "I can call you but you can't call me" is an error state. Anyway, I don't really expect this to happen in practice. Would be nice though to at least detect it and print an error message or something.

...

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.

As far as our GSUP encoding+decoding is concerned, it's all done unconditionally. So if our HLR were to stick an MSISDN TLV in the LU Accept GSUP message, the GSUP client would decode it, and hey, what's this:

/* Handle UpdateLocation Result from HLR */ static int vlr_sub_handle_lu_res(struct vlr_subscriber *vsub, const struct osmo_gsup_message *gsup) { if (!vsub->lu_fsm) { LOGVSUBP(LOGL_ERROR, vsub, "Rx GSUP LU Result " "without LU in progress\n"); return -ENODEV; }

/* contrary to MAP, we allow piggy-backing subscriber data onto the * UPDATE LOCATION RESULT, and don't mandate the use of a separate * nested INSERT SUBSCRIBER DATA transaction */ vlr_sub_gsup_insert_data(vsub, gsup);

osmo_fsm_inst_dispatch(vsub->lu_fsm, VLR_ULA_E_HLR_LU_RES, NULL);

return 0; }

So Harald's VLR code would indeed also handle the MS data glued to the LU Result. All we need is make the HLR send the MSISDN TLV along in the LU Result.

Of course to allow that also means to not insist on the Insert Data message from the HLR. We should probably still print an error message when the LU completes without an MSISDN known in the VLR.

~N

On Mon, Feb 13, 2017 at 02:56:16PM +0100, Jacob Erlbeck wrote:

What about a "data only" SIM card that does e.g. not have a fixed IMSI needing an MT-SMS after initial LU to get a temporary one to be able to do GPRS etc?

Interesting, is IMSI a typo or is this real? Anyway, no MSISDN does seem to be a valid use case, thanks :)

~N

On 13.02.17 08:13, Jacob Erlbeck wrote:

On 02/09/2017 02:53 PM, Neels Hofmeyr wrote:

...

What should we do if the HLR sends no Insert Data?

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.

By the way: Both updateLocation and updateGprsLocation have a skipSubscriberDataUpdate flag, which tells the HLR to skip the insertSubscriberData procedure.

From 29.002 8.1.2.3:

Skip Subscriber Data Update The presence of the parameter is optional and if present it indicates that subscriber data download during the updateGprsLocation procedure may be skipped by the HLR e.g. because the service is solely used to inform the HLR about change of IMEISV. The parameter is used to optimise signalling load during Location Update procedure.

-Tobias