vlr+hlr: Insert Data

[Neels Hofmeyr]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170213/072bbe4f/attachment.bin>