Project

General

Profile

Feature #2542

have subscriber create-on-demand

Added by neels about 2 years ago. Updated 3 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
-
Start date:
10/06/2017
Due date:
% Done:

80%


Description

Especially communal networks that allow 3rd party SIM cards to camp on the network would
greatly benefit from a subscriber create-on-demand feature in the osmo-hlr. A new subscriber
could be rejected from the network at first, but has then left its IMSI and IMEI in the db.

This implies the ability to disable subscribers even though they are present in the HLR,
otherwise anyone showing up would be authorized immediately, which is usually not desirable.

Clarify whether nam_ps/nam_cs or purge_ps/purge_cs are suitable for this purpose,
otherwise we'd need another flag per subscriber saying 'authorized', which could be false
by default for subscriber create-on-demand.


Checklist

  • TTCN3 tests
  • Make related changes in SGSN code (relevant for PS-only subscribers)

Related issues

Related to OsmoHLR - Feature #2541: have IMEI in HLR DBResolved10/06/2017

History

#1 Updated by neels about 2 years ago

#2 Updated by laforge about 1 year ago

#3 Updated by laforge about 1 year ago

  • Assignee set to sysmocom

#4 Updated by laforge about 1 year ago

  • Priority changed from Normal to Urgent

#6 Updated by laforge about 1 year ago

  • Priority changed from Urgent to Normal

#8 Updated by neels about 1 year ago

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

#9 Updated by laforge about 1 year ago

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".

#10 Updated by osmith 8 months ago

  • Status changed from New to In Progress
  • Assignee changed from sysmocom to osmith

#11 Updated by osmith 8 months ago

I'm looking at the legacy openbsc code right now, where this feature is already implemented, and it has the following options:
  • 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?

#12 Updated by keith 8 months ago

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.

#13 Updated by osmith 8 months ago

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.

#14 Updated by osmith 8 months ago

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.

#15 Updated by osmith 8 months ago

  • % Done changed from 0 to 20
So I'm implementing b), in detail:
  • 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.
If somebody would just want to create the subscribers on demand, without the IMEI requirement, they could simply do it with:
  • HLR: subscriber-create-on-demand
Keith's use case would be configured with:
  • 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

#16 Updated by laforge 8 months ago

On Tue, Mar 05, 2019 at 05:23:17PM +0000, osmith [REDMINE] wrote:

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

definitely neither of those two options are something we should implement. Please
put this on hold until we figured out a sane method of doing this.

#17 Updated by osmith 8 months ago

  • Status changed from In Progress to Stalled

#18 Updated by fixeria 7 months ago

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

#19 Updated by rafael2k 6 months ago

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?

#20 Updated by laforge 6 months ago

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 :)

#21 Updated by fixeria 6 months ago

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.

#22 Updated by osmith 6 months ago

  • Status changed from Stalled to In Progress

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

#23 Updated by osmith 6 months ago

  • % Done changed from 20 to 30

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

#24 Updated by osmith 6 months ago

  • % Done changed from 30 to 40
MSC patches submitted:

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.

#25 Updated by osmith 6 months ago

  • % Done changed from 40 to 60

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.

#26 Updated by osmith 5 months ago

  • Checklist item TTCN3 tests added
  • Checklist item Make related changes in SGSN code (relevant for PS-only subscribers) added

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

#27 Updated by osmith 5 months ago

  • % Done changed from 60 to 70

#28 Updated by osmith 4 months ago

  • % Done changed from 70 to 80

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.

#29 Updated by osmith 4 months ago

#30 Updated by laforge 3 months ago

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!

#31 Updated by osmith 3 months ago

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)

#32 Updated by osmith 3 months ago

  • Checklist item TTCN3 tests set to Done

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)