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