Feature #2542
openhave subscriber create-on-demand
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
Updated by neels about 6 years ago
- Related to Feature #2541: have IMEI in HLR DB added
Updated by neels about 5 years ago
like #2541, I could do this one fairly quickly, but could also guide a newcomer through it instead.
Updated by laforge about 5 years 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".
Updated by osmith over 4 years ago
- Status changed from New to In Progress
- Assignee changed from 4368 to osmith
Updated by osmith over 4 years ago
- 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?
Updated by keith over 4 years 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.
Updated by osmith over 4 years 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.
Updated by osmith over 4 years 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.
Updated by osmith over 4 years ago
- % Done changed from 0 to 20
- 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
Updated by laforge over 4 years ago
Updated by fixeria over 4 years ago
FYI: I also need this feature for upcoming PHDays 2019, so I made some little changes and published a new branch:
Updated by rafael2k over 4 years ago
fixeria wrote:
FYI: I also need this feature for upcoming PHDays 2019, so I made some little changes and published a new branch:
This is really wonderful! How far are we from having the subscriber create-on-demand feature? Any guidance of what needs to be done?
Updated by laforge over 4 years ago
fixeria wrote:
FYI: I also need this feature for upcoming PHDays 2019, so I made some little changes and published a new branch:
Great! Please submit to gerrit. I have some comments but cannot put them until it's in gerrit :)
Updated by fixeria over 4 years 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.
Updated by osmith over 4 years 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).
Updated by osmith over 4 years ago
- % Done changed from 20 to 30
WIP branch for osmo-msc: osmith/check-imei-before-lu
Updated by osmith over 4 years ago
- % Done changed from 30 to 40
- 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.
Updated by osmith over 4 years 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.
Updated by osmith over 4 years 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:
Updated by osmith over 4 years 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.
Updated by laforge over 4 years ago
osmith wrote:
see the new "Configuring the Subscribers Create on Demand Feature" section in the user manual:
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!
Updated by osmith over 4 years 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)
Updated by laforge over 2 years ago
- Related to Feature #5183: EIR functionality added
Updated by osmith over 2 years ago
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?
Updated by fixeria almost 2 years ago
- Status changed from In Progress to Stalled
Updated by osmith over 1 year ago
- Priority changed from Normal to Low
changing priority to low, apparently not much interest for the OsmoSGSN part