Cellular Network Infrastructure » Core Network (CN) » OsmoHLR

like #2541, I could do this one fairly quickly, but could also guide a newcomer through it instead.

neels wrote:

Clarify whether nam_ps/nam_cs or purge_ps/purge_cs are suitable for this purpose,

I would say yes, at least from how I remember the specs. If both CS and PS network access mode are disabled, the subscriber should be rejected for both LU from MSC as well as SGSN. The reject cause should be something along the lines of "service not subscribed".

• subscriber-create-on-demand random <1-9999999999> <2-9999999999>
• subscriber-create-on-demand [no-extension]
• no subscriber-create-on-demand

keith: your use case is creating a subscriber entry in the database without assigning an extension (telephone number), right?

osmith wrote:

keith: your use case is creating a subscriber entry in the database without assigning an extension (telephone number), right?

osmith In fact we do currently use the automatically generated extension, but it would not be strictly necessary, the important thing is that we get the IMSI and IMEI in the database, so that we can look up the IMSI by IMEI as the IMEI is readily and easily available to the phone user.

keith: thanks!

laforge wrote:

neels wrote:

Clarify whether nam_ps/nam_cs or purge_ps/purge_cs are suitable for this purpose,

I would say yes, at least from how I remember the specs. If both CS and PS network access mode are disabled, the subscriber should be rejected for both LU from MSC as well as SGSN. The reject cause should be something along the lines of "service not subscribed".

I have tested this, and the subscriber gets rejected properly when setting nam_ps=0, nam_cs=0 in the HLR DB. However, this happens before transmitting the IMEI, so we need a different solution - I'm looking into it.

From looking at GSUP in wireshark, the communication between MSC and HLR looks like this (tested with a clean HLR database, and also with rebooting the phone afterwards, that yields the same messages):

• UpdateLocation Request
• (Subscriber gets created on demand here; if we create it with cs_nam=0 and ps_nam=0, it will stop right here and show a nice error on the phone)
• InsertSubscriberData Request
• InsertSubscriberData Result
• UpdateLocation Result
• Check IMEI Request (optional; this is where we get the IMEI, so we must not stop before)
• Check IMEI Result (optional)

After this, the mobile phone assumes that it is connected. Which is of course not what we want, because we want to get the IMEI and then kick the phone out of the network again unless it is approved (at least in the relevant use case, we could also make the approving optional).

Check IMEI is optional, and needs to be enabled in the MSC. I hoped to find another authentication check that is done after the Check IMEI messages, but there is none.

Right now I see these two options:
a) HLR needs to tell MSC whether the subscriber is approved, then the MSC kicks non-approved subscribers after optionally running the Check IMEI procedure.
b) Assume that the MSC is always configured to have Check IMEI enabled, when subscriber create-on-demand is enabled in HLR. Then we use the Check IMEI procedure to actually check if the subscriber's IMSI is approved in the HLR. (Against its original purpose, which is verifying the IMEI.)

Both are hackish, but I'm leaning towards b) because it doesn't require any hacks in the MSC software (would even work with something other than osmo-msc, as long as it does Check IMEI).

neels, laforge: if you have time, I'd be interested in your opinions on that.

• Add another VTY option "lu-ignore-nam-cs". The VTY documentation states, that it must only be enabled when the MSC has Check IMEI enabled.
  • When it is set, we will ignore if nam_cs = 0 in the location update, and kick the subscriber from the network when nam_cs = 0 in the Check IMEI step.
  • When it is not set, the location update will fail for subscribers created on demand and they will disconnect before sending the IMEI.
• The purpose of this new option is, that we don't mix the Check IMEI MSC config requirement with the subscriber-create-on-demand option.

• HLR: subscriber-create-on-demand

• MSC: check-imei-rqd 1
• HLR: store-imei
• HLR: subscriber-create-on-demand
• HLR: lu-ignore-nam-cs

WIP branch: osmith/subscriber-create-on-demand

FYI: I also need this feature for upcoming PHDays 2019, so I made some little changes and published a new branch:

https://git.osmocom.org/osmo-hlr/log/?h=fixeria/phdays

fixeria wrote:

FYI: I also need this feature for upcoming PHDays 2019, so I made some little changes and published a new branch:

https://git.osmocom.org/osmo-hlr/log/?h=fixeria/phdays

This is really wonderful! How far are we from having the subscriber create-on-demand feature? Any guidance of what needs to be done?

fixeria wrote:

FYI: I also need this feature for upcoming PHDays 2019, so I made some little changes and published a new branch:

https://git.osmocom.org/osmo-hlr/log/?h=fixeria/phdays

Great! Please submit to gerrit. I have some comments but cannot put them until it's in gerrit :)

Great! Please submit to gerrit. I have some comments but cannot put them until it's in gerrit :)

Done, please see: https://gerrit.osmocom.org/#/q/topic:subscr-create-on-demand+status:open

How far are we from having the subscriber create-on-demand feature? Any guidance of what needs to be done?

First of all, we need to get the existing changes merged to master. Also, would be great to have some testing coverage.

Update from osmodevcon, where we discussed how to move forward with this and have found a clean solution. Here is how it should look like:

• Create HLR VTY options for:
  • create subscriber on demand
  • set flags to enable cs_nam, ps_nam by default

• Create MSC VTY option: do Check IMEI procedure before location update
  • When enabled, we will still send the IMEI to the HLR with the Check IMEI procedure.
  • If the MS is not allowed to access ps and cs, we can reject them in the location update, as usually.

It is also needed to take a look at the OsmoSGSN code, regarding the order, and possibly make checking the IMEI optional there (right now it is always enabled).

WIP branch for osmo-msc: osmith/check-imei-before-lu

• https://gerrit.osmocom.org/#/c/osmo-msc/+/13892 vty: make retrieve-imeisv-early configurable
• https://gerrit.osmocom.org/#/c/osmo-msc/+/13893 vlr: when setting IMEISV, also set IMEI
• https://gerrit.osmocom.org/#/c/osmo-msc/+/13894 vlr: check IMEI early for retrieve-imeisv-early 1

I have tested them locally with real hardware, and adjusted the regression tests. And I ran the TTCN3 tests, they are still working (same result as in jenkins).

I'm working on the HLR patches now, based on @fixeria's branch.

HLR patches submitted, too (or rather, updated the WIP patches I made earlier, which fixeria extended and submitted):

https://gerrit.osmocom.org/#/q/topic:subscr-create-on-demand+(status:open+OR+status:merged)

Improvements from fixeria included. I've added VTY options to allow choosing the default NAM (Network Access Mode), between "none" (Rhizomatica use case), "ps", "cs" and "both" (@fixeria's use case), as well as optionally setting a random MSISDN length.

Tested with real hardware, this works well together with the MSC patches, and allows creating subscribers on demand, with their IMEI saved in the HLR db.

I'm waiting with merging MSC related patches, until the MSC handover patches are in master. (With HLR I am not sure if there are currently open MSC-HO-related patches.)

TTCN3 tests and SGSN adjustments are left to do.

The patches are in master now, and the feature can be used.

keith: see the new "Configuring the Subscribers Create on Demand Feature" section in the user manual:

https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf

TTCN3 tests for OsmoHLR (and related fixes) are submitted now:

https://gerrit.osmocom.org/q/topic:%22subscr-on-demand-tests%22+(status:open%20OR%20status:merged)

Tests for OsmoMSC will follow afterwards.

TTCN3 tests for OsmoMSC submitted:

https://gerrit.osmocom.org/q/topic:subscr-on-demand-tests

osmith wrote:

see the new "Configuring the Subscribers Create on Demand Feature" section in the user manual:

https://ftp.osmocom.org/docs/latest/osmohlr-usermanual.pdf

The manual is a bit less clear than it could be, sorry. I suggest to include "verbatim blocks" with examples of what exactly to configure on the VTY for both MSC and HLR that look like those we have in https://ftp.osmocom.org/docs/latest/osmobsc-usermanual.pdf (even with call-outs [footnote like annotations] if required).

Also, any VTY command, even if presented inline in the manual text should always be presented as monotype, not just put in double-quotes. Thanks!

Update for the manuals, and missing VTY command to change CS/PS NAM: https://gerrit.osmocom.org/q/topic:%22subscr-on-demand-manual%22+(status:open%20OR%20status:merged)

The remaining task would be extending OsmoSGSN to do an optional Check IMEI before doing the Location Update, so the IMEI would be transmitted to the database even for PS-only subscribers. However, OsmoSGSN is apparently completely missing the Check IMEI procedure (see #5183). My understanding is that the PS-only use case is not really interesting here and it's therefore not worth implementing it as part of this issue.

So can I close this?

changing priority to low, apparently not much interest for the OsmoSGSN part