Project

General

Profile

Actions

Feature #2541

closed

have IMEI in HLR DB

Added by neels over 6 years ago. Updated about 5 years ago.

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

100%

Spec Reference:

Description

Especially for communal operators that allow 3rd party SIM cards to camp on the network and that deal with "random"
IMSIs showing up to get signed on to the network, it is important to be able to query the subscriber database for
the IMEI.

The IMEI is often the only identification of an MS that is readily available if we haven't given out a SIM card,
and hence the least ambiguous way to associate a random LU to a real-life person waiting to get authorized.

We should transport the IMEI (IMEISV) via GSUP to the HLR and store it in the HLR database, if the VLR is configured
to retrieve the IMEI / IMEISV from the subscriber.

The database scheme as well as the GSUP protocol need to be expanded for this to work.

Note that this use case also depends on the ability to record LU attempts of unknown subscribers,
i.e. a "subscriber create-on-demand" feature like in the old OsmoNITB.


Related issues

Related to OsmoHLR - Feature #2542: have subscriber create-on-demandStalledosmith10/06/2017

Actions
Related to OsmoMSC - Feature #3189: make retrieval of IMEI configurableResolvedosmith04/19/2018

Actions
Related to OsmoHLR - Feature #3732: Support tacdb query in HLRNew12/13/2018

Actions
Related to Cellular Network Infrastructure - Feature #3733: Send IMEI from MSC to HLRResolvedosmith12/14/2018

Actions
Actions #1

Updated by neels over 6 years ago

  • Related to Feature #2542: have subscriber create-on-demand added
Actions #2

Updated by neels almost 6 years ago

  • Related to Feature #3189: make retrieval of IMEI configurable added
Actions #3

Updated by laforge over 5 years ago

  • Assignee set to 4368
Actions #4

Updated by laforge over 5 years ago

  • Priority changed from Normal to Urgent
Actions #6

Updated by laforge over 5 years ago

  • Priority changed from Urgent to Normal
Actions #8

Updated by neels over 5 years ago

I guess I could resolve this one pretty quickly; but this would also qualify for newcomers to familarize with the layers.
needs:

  • MSC+VLR vty config for #3189 -- all ID Request code already exists, just needs a flag flipped by VTY.
  • extend GSUP to add IMEISV
  • adjust HLR to store IMEISV -- db column already exists.
Actions #9

Updated by laforge over 5 years ago

Please keep in mind we do want to keep things in line with the 3GPP
procedures on the MSC/VLR<->HLR/EIR interface!

Simply adding the IMEI to an UpdateLocation request is not going to cu
it. Rather, the VLR needs to invoke the CheckIMEI procedure towards the
EIR, and OsmoHLR then has to implement the EIR functionality in this
context.

So on the protocol level the transactions look like 3GPP. Whether or
not the HLR then dynamically creates a "EIR entry" and acknowledges all
CheckIMEI is an implementation detail that doesn't affect the
transactions/procedures "on the wire".

Actions #10

Updated by osmith over 5 years ago

  • Assignee changed from 4368 to osmith
Actions #11

Updated by laforge over 5 years ago

Some context:

  • Normally, a HLR doesn't store IMEI information, rather the EIR (Equipment Identity Register) does
  • The VLR in the MSC will explicitly issue a CHECK_IMEI procedure, which will send a MAP request
    to the EIR and ask if this IMEI is permitted or not
  • The EIR will respond to the VLR

The purpose of this procedure as per 3GPP specs is to have a blacklist/whitelist of IMEIS that
is pre-populated using out-of-band sources. It is not to dynamically store information about IMEIS.

While we use GSUP and not MAP, we still want to have the same abstract trasactions, procedures
and message flows. This means, we have to implement whatever the MAP CHECK IMEI procedure normally
does, but then OsmoHLR can, optionally, if enabled by VTY, store the received IMEI information in
some table. So rather than a policy check, it would be used for dynamically storing the IMEI/IMSI
mappings as they appear over time.

Please note that the CHECK IMEI procedure in the VLR is an optional procedure, so it must be
enabled in the VLR. I'm not sure if all required code exists and we simply commented it out,
or if it's already enable-able by VTY, ...

Actions #12

Updated by osmith over 5 years ago

  • Status changed from New to In Progress
Actions #13

Updated by osmith over 5 years ago

Please note that the CHECK IMEI procedure in the VLR is an optional procedure, so it must be
enabled in the VLR. I'm not sure if all required code exists and we simply commented it out,
or if it's already enable-able by VTY, ...

Reading #3189, it seems that CHECK_IMEI is already implemented in the VLR (in osmo-msc), but can not be set in the VTY config yet. So I'm looking at this first.

Actions #14

Updated by msuraev over 5 years ago

Actions #15

Updated by osmith over 5 years ago

Actions #16

Updated by osmith about 5 years ago

  • % Done changed from 0 to 30

In HLR, we have a column for IMEISV. However, since we decided to use the Check IMEI mechanism, we only send the IMEI from the MSC/VLR to the HLR/EIR. Not the IMEISV.

For testing purposes I'm just saving the IMEI in the IMEISV column right now, but that will probably lead to confusion in the future. I'm wondering what the best way to continue is here. I came up with these options:

a) Keep using the IMEISV column with the IMEI
b) Update the DB format and add a new IMEI column
c) Update the DB format, add a new IMEI column and delete the IMEISV column

laforge, neels: recommendations?

Actions #17

Updated by laforge about 5 years ago

Hi Oliver,

On Wed, Jan 09, 2019 at 02:29:09PM +0000, osmith [REDMINE] wrote:

a) Keep using the IMEISV column with the IMEI
b) Update the DB format and add a new IMEI column
c) Update the DB format, add a new IMEI column and delete the IMEISV column

laforge, neels: recommendations?

I'm all for option 'b'.

Actions #18

Updated by osmith about 5 years ago

  • % Done changed from 30 to 80

I'm all for option 'b'.

Implemented, patches submitted:
https://gerrit.osmocom.org/#/q/topic:send-imei-to-hlr+(status:open+OR+status:merged)

(CI failures are due to a dependency in libosmocore.)

Actions #19

Updated by osmith about 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)