Hi All,
I have a use case where I'd like to react to MS connecting to the network, that is on initial IMSI ATTACH.
We already have the SMPP alert notification mechanism which can be used, but unfortunately in SMPP the ms_availability_status only has 3 posible values in the spec:
0: Available
1: Denied
2: Unavailable.
So currently if I react to status 0, this would also happen on periodic LURs
I could keep state separately but that sounds prone to errors.
The external process reacting to the alert notification could try somehow to get the previous status from HLR or database, but that sounds like a race condition.
One possibility might be to extend this with a further custom value 3: Available (Initial Attach) or some such?
Any thoughts?
On Wed, May 23, 2018 at 12:38:43PM +0200, Keith Whyte wrote:
0: Available
1: Denied
2: Unavailable.
So currently if I react to status 0, this would also happen on periodic LURs
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".
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?
~N
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.
On 23/05/18 16:55, Harald Welte wrote:
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?
From quick observation on legacy openBSC, we just accept the PERIODIC LUR for a "detached" MS and update the LAC in the HLR. So maybe the easiest thing to do is maintain this state somewhere else - with the processing of the alert on the ESME side.
This is about Search and Rescue use, where the aim is to send informative SMS to an MS that connects 1st time, but not on every periodic LUR. Not necessarily on every IMSI Attach either, although that would be acceptable. But best to store an "intro sent" state in the ESME, even if only in memory. Another way to do it might be to connect something to the subscriber-create-on-demand routine that generate an SMS, but then if the phone was disconnected, changed hands, and reconnected, the new owner would not be informed..
On Wed, May 23, 2018 at 10:27:38PM +0200, Keith Whyte wrote:
From quick observation on legacy openBSC, we just accept the PERIODIC LUR for a "detached" MS and update the LAC in the HLR.
Perodic LU applies to attached MS, not detached ones. Have you got the logic reversed, or is that a bug?
And the legacy OpenBSC has no osmo-hlr, you're referring to the sqlite db?
~N
On 24/05/18 15:47, Neels Hofmeyr wrote:
On Wed, May 23, 2018 at 10:27:38PM +0200, Keith Whyte wrote:
From quick observation on legacy openBSC, we just accept the PERIODIC LUR for a "detached" MS and update the LAC in the HLR.
Perodic LU applies to attached MS, not detached ones.
Yes.. but "detached", according to who?
Have you got the logic reversed, or is that a bug?
Here's what I did. 1) Power on MS, Let it IMSI Attach. 2) Mark the MS as detached in HLR (sqlite) 3) Wait for the PERIODIC LUR.
And the legacy OpenBSC has no osmo-hlr, you're referring to the sqlite db?
Yes, of course.
~N
On Mon, May 28, 2018 at 09:36:59AM +0200, Keith Whyte wrote:
On 24/05/18 15:47, Neels Hofmeyr wrote:
On Wed, May 23, 2018 at 10:27:38PM +0200, Keith Whyte wrote:
From quick observation on legacy openBSC, we just accept the PERIODIC LUR for a "detached" MS and update the LAC in the HLR.
Perodic LU applies to attached MS, not detached ones.
Ah, I understand now. I got the wording the wrong way, thought you wrote "we accept Periodic LU *only* for detached MS" while you meant to say "when a Periodic LU comes in for a detached phone, we simply accept it".
Ok, yes, the idea remains: not trigger SMPP signals on the periodic-ness of the LU, but rather wherever the MSC decides to change between "attached" and "detached".
Whether a "periodic" lu is then also accepted as "imsi attach" or not is then a mere implementation detail of the MSC.
~N
On 28/05/18 12:41, Neels Hofmeyr wrote:
Ah, I understand now. I got the wording the wrong way, thought you wrote "we accept Periodic LU *only* for detached MS" while you meant to say "when a Periodic LU comes in for a detached phone, we simply accept it".
Ah yes. Sorry. "just" can be ambiguous in English. I should endeavor to not use it.
Ok, yes, the idea remains: not trigger SMPP signals on the periodic-ness of the LU, but rather wherever the MSC decides to change between "attached" and "detached".
For the moment, what I've done is extend the SMPP availability statuses and send a different status for IMSI_ATTACH to PERIODIC The my SMPP listener is reacting differently depending on the status.. This works for the moment for the application in hand, but I assume it's not something we want to be concerned about in master.
k
On 28. May 2018, at 19:14, Keith Whyte keith@rhizomatica.org wrote:
For the moment, what I've done is extend the SMPP availability statuses and send a different status for IMSI_ATTACH to PERIODIC The my SMPP listener is reacting differently depending on the status.. This works for the moment for the application in hand, but I assume it's not something we want to be concerned about in master.
Out of my head I don't know which fields/IEs you would use to indicate it but I think it makes sense to differentiate it. It is easier for an app to discard information it doesn't want to have than making it up. ;)
holger
On 23/05/18 14:34, Neels Hofmeyr wrote:
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?
I came to the same conclusion mulling it over while AFK this afternoon. And, what's more , should we also send an "Unavailable" SMPP Alert on subscriber expiration?
-
Harald Welte -
Holger Freyther -
Keith Whyte -
Neels Hofmeyr