Feature #2541

have IMEI in HLR DB

Added by neels about 1 year ago. Updated 18 days ago.

Target version:
Start date:
Due date:
% Done:



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-demandNew2017-10-06

Related to OsmoMSC - Feature #3189: make retrieval of IMEI, IMEISV configurableNew2018-04-19


#1 Updated by neels about 1 year ago

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

#2 Updated by neels 6 months ago

  • Related to Feature #3189: make retrieval of IMEI, IMEISV configurable added

#3 Updated by laforge 20 days ago

  • Assignee set to sysmocom

#4 Updated by laforge 19 days ago

  • Priority changed from Normal to Urgent

#6 Updated by laforge 19 days ago

  • Priority changed from Urgent to Normal

#8 Updated by neels 18 days ago

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

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

#9 Updated by laforge 18 days 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

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)