23 May
2018
23 May
'18
12:38 p.m.
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?
23 May
23 May
2:34 p.m.
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
4:55 p.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
10:27 p.m.
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..
24 May
24 May
3:47 p.m.
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
28 May
28 May
9:36 a.m.
On 24/05/18 15:47, Neels Hofmeyr wrote:
On Wed, May 23, 2018 at 10:27:38PM +0200, Keith Whyte
wrote:
Yes.. but "detached",
according to who?
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?
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
12:41 p.m.
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
1:14 p.m.
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
31 May
31 May
3:52 a.m.
On 28. May 2018, at 19:14, Keith Whyte
<keith(a)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
23 May
23 May
10:08 p.m.
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?
2163
days inactive
2171
days old
9 comments
4 participants
participants (4)
-
Harald Welte -
Holger Freyther -
Keith Whyte -
Neels Hofmeyr