Project

General

Profile

Feature #2542

have subscriber create-on-demand

Added by neels over 1 year ago. Updated 16 days ago.

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

20%


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.


Related issues

Related to OsmoHLR - Feature #2541: have IMEI in HLR DBResolved2017-10-06

History

#1 Updated by neels over 1 year ago

#2 Updated by laforge 6 months ago

#3 Updated by laforge 6 months ago

  • Assignee set to sysmocom

#4 Updated by laforge 6 months ago

  • Priority changed from Normal to Urgent

#6 Updated by laforge 6 months ago

  • Priority changed from Urgent to Normal

#8 Updated by neels 6 months ago

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

#9 Updated by laforge 6 months 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 19 days ago

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

#11 Updated by osmith 19 days 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 19 days 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 18 days 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 18 days 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 17 days 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 16 days 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 16 days ago

  • Status changed from In Progress to Stalled

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)