React to IMSI Attach but not PERIODIC

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Wed May 23 14:55:49 UTC 2018


Hi Keith, Neels,

On Wed, May 23, 2018 at 02:34:07PM +0200, Neels Hofmeyr wrote:

> Sounds a bit like SMPP isn't actually intended to be notified of periodic LU?
> After all, those are "just" a GSM implementation detail to say "yes, I'm still
> here, don't implicitly detach me".

SMPP alert is simply notifying the EXME that a given subscrier [again] is reachable.

So *if* the periodic LU really is periodic, and the MSC/VLR already contained
state about this imsi at the time the periodic LU arrives, then I agree we could
remove the SMPP ALERT.

However, the decision would have to be based on whether or not we have just created
new state in this VLR/MSC, and not [only] based on which LU Type the MS was requesting.

For example, I'm not sure if we'd actually reject a periodic LU at a
time where that IMSI is not marked as attached already before.  Do we
reject such a LU and somehow force the MS to perform an "IMSI ATTACH"
type LU, or doe we accept it as an implicit attach?

For "Normal" LU (LAC change), the same rules apply.  If we actually have state for
this IMSI in the VLR already, we can suppress the SMPP ALERT.  If we are
tolerating such a LU to actually create a new subscriber record in the
VLR despite not being IMSI ATTACH, then we would have to generate SMPP
ALERT.

> I don't know it for a fact, but my gut feel says we should simply not alert
> SMPP on periodic LU at all, but only on a change of subscriber availability?

ACK, with implications as stated above.

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list