Project

General

Profile

Feature #2969

obtain and store subscriber identity

Added by neels over 2 years ago. Updated about 1 month ago.

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

100%

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


Checklist

  • BSC side CommonID
  • MSC side CommonID
  • TTCN3 test for BSC side
  • TTCN3 test for MSC side

Related issues

Related to OsmoBSC - Feature #2968: resurrect meas_feedResolved02/21/2018

History

#1 Updated by laforge over 2 years 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 over 2 years ago

#3 Updated by neels about 2 years 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 almost 2 years ago

  • Priority changed from Normal to Low

#5 Updated by neels over 1 year 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.

#6 Updated by laforge 3 months ago

  • Status changed from New to In Progress
  • Assignee changed from neels to laforge
  • % Done changed from 0 to 30

neels wrote:

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.

#7 Updated by laforge 3 months ago

  • Checklist item BSC side CommonID added
  • Checklist item MSC side CommonID added
  • Checklist item TTCN3 test for BSC side added
  • Checklist item TTCN3 test for MSC side added
  • % Done changed from 30 to 40

Seems to work:

20200621202414078 DMSC <0007> bsc_subscr_conn_fsm.c:713 SUBSCR_CONN(msc0-conn1_IMSI001019876543210)[0x562e3ecc2de0]{ACTIVE}: conn detaches lchan lchan(0-0-0-CCCH_SDCCH4-0)[0x562e3ea9d1e0]
20200621202404247 DMSC <0007> osmo_bsc_bssap.c:1089 SUBSCR_CONN(msc0-conn1)[0x562e3ecc2de0]{ACTIVE}: Received Event COMMON_ID.ind

further log messages of the same subscr_conn will print the IMSI in the ID:

20200621202414078 DMSC <0007> bsc_subscr_conn_fsm.c:713 SUBSCR_CONN(msc0-conn1_IMSI001019876543210)[0x562e3ecc2de0]{ACTIVE}: conn detaches lchan lchan(0-0-0-CCCH_SDCCH4-0)[0x562e3ea9d1e0]

Implementing a TTCN3 test is non-trivial, as w have to somehow validate via VTY or CTRL :/

#8 Updated by laforge 3 months ago

  • Checklist item TTCN3 test for BSC side set to Done

#9 Updated by ipse 3 months ago

I just want to add here that while an MSC may send this - it doesn't have to. E.g. in our case we don't see these messages from a Huawei MSC.

It might make sense to keep this ticket open until a DTAP-based implementation is also added for the cases where you don't have control over the MSC and can't use CommonID messages.

#10 Updated by laforge 3 months ago

  • Checklist item MSC side CommonID set to Done
  • % Done changed from 40 to 80

#11 Updated by laforge 3 months ago

ipse wrote:

I just want to add here that while an MSC may send this - it doesn't have to. E.g. in our case we don't see these messages from a Huawei MSC.

It may be a configuration in the MSC. MAy also be related to the 3GPP release that the MSC is implementing (or configured to use). The BSSMAP CommonID seems to be a quite recent addition.

#12 Updated by laforge about 1 month ago

BSC side commonID patch has finally been merged.

#13 Updated by laforge about 1 month ago

  • Checklist item TTCN3 test for MSC side set to Done
  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

ttcn3 tests for MSC side in https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19714

all patches merged.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)