Project

General

Profile

Feature #2969

obtain and store subscriber identity

Added by neels about 1 year ago. Updated 3 months ago.

Status:
New
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
02/21/2018
Due date:
% Done:

0%

Spec Reference:

Description

osmo-bsc doesn't per se get hold of the subscriber identity except during a Paging Command.
However, osmo-bsc passes through all the DTAP between BTS and MSC, and in fact we have a DTAP filter in place in osmo-bsc's code base, which does obtain the mobile identity from the passing DTAP.
Using that code, it is possible to obtain the subscriber's IMSI/TMSI identity for all connections, and note it in the subscriber_connection's bsc_subscr struct for all other code to benefit from.

This is mainly useful for analysis / logging; for example, a handover log currently shows only the MT subscriber's identity:

DHODEC DEBUG handover_decision_2.c:1129 (lchan 1.020 TCH/F) (subscr unknown) MEASUREMENT REPORT
DHODEC DEBUG handover_decision_2.c:1134 (lchan 1.020 TCH/F) (subscr unknown)   0: arfcn=868 bsic=63 neigh_idx=0 rxlev=35 flags=0
DHODEC DEBUG handover_decision_2.c:1129 (lchan 1.030 TCH/F) (subscr IMSI:901700000014701) MEASUREMENT REPORT
DHODEC DEBUG handover_decision_2.c:1134 (lchan 1.030 TCH/F) (subscr IMSI:901700000014701)   0: arfcn=868 bsic=63 neigh_idx=0 rxlev=60 flags=0

Another example is the meas_feed feature, which in its last working implementation discards measurement reports for unknown subscribers instead of sending them out. (That could be changed, but adding the subscriber identity would probably be better.)


Related issues

Related to OsmoBSC - Feature #2968: resurrect meas_feedResolved2018-02-21

History

#1 Updated by laforge about 1 year ago

Makes sense. Please keep in mind that we also want (at some point) to introduce osmocom-specific
TLVs in 48.008 (BSSAP) message that allow OsmoMSC to inform OsmoBSC with the "subscriber name" (i.e. an
arbitrary string name that can be stored in the HLR with the subscriber for easier logging).

There's a ticket around for this.

#2 Updated by neels 11 months ago

#3 Updated by neels 7 months ago

  • Assignee set to neels

I've got a plan there and had a few patches, assigning to me to not forget about this issue.

#4 Updated by laforge 6 months ago

  • Priority changed from Normal to Low

#5 Updated by neels 3 months ago

just now I come across the BSSMAP Comon ID message. We already send it on IuCS, but not on the A-interface.

"3.1.30 Common ID
The purpose of the Common ID procedure is to inform the BSC about the IMSI of a user.
[...]
If the MS, the BSS and the MSC support DTM and as soon as the IMSI is available at the MSC, the MSC shall send the
COMMON ID message to the BSS."

So, instead of skimming the DTAP that passes the BSC towards the MSC, we should properly implement the Common ID message and handling to populate the IMSI.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)