Project

General

Profile

Feature #2969

obtain and store subscriber identity

Added by neels over 3 years ago. Updated about 1 year 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

Associated revisions

Revision 81e912fa (diff)
Added by Neels Hofmeyr over 3 years ago

try to pick up subsrc IMSI on l3-compl

This is a tiny step towards being aware of a connection's subscriber identity.
Iff the Layer 3 Complete message contains an IMSI, associate a bsc_subscr with
the conn, so that subsequent logging and possibly meas_feed contains the IMSI.

For any L3 Complete using TMSI, this has no effect whatsoever.

Related: OS#2969
Change-Id: I3b696a0c0932e3abcb682ba231db65755d8c27a6

Revision 7c68e904 (diff)
Added by Neels Hofmeyr over 3 years ago

store subscriber identity on paging

Another small step towards being aware of the subscriber identity.

Any connection initiated by paging will subsequently log the subscriber's
identity -- of course not necessarily the IMSI, if paging was done by TMSI.

This is only for Paging, not the Paging Response; for that see, L3 Complete.

Related: OS#2969
Change-Id: I0ab7bedfe693bb4e42a04fb0585b94a730ff2d9b

Revision 1bd726a2 (diff)
Added by laforge over 1 year ago

gsm0808: Add gsm0808_create_common_id()

This function encodes a GSM 08.08 / 48.008 "Common ID" message.

Change-Id: I353adc1aa72377f7d4b3336d2ff47791fb73d62c
Related: OS#2969

Revision 210aa95d (diff)
Added by laforge about 1 year ago

Implement support for receiving BSSMAP CommonID from MSC

The MSC may at any time send a BSSMAP CommonID message via a
SCCP connection to inform us of the IMSI of the subscriber. Let's
make use of that information by associating a related bsc_subscr
and updating the identity of the bsc_subscr_conn_fsm for improved
logging / filtering.

Closes: OS#2969
Change-Id: I52c43fb940f0db796adf4c0adb2260321c721c39

Revision a8521eb1 (diff)
Added by laforge about 1 year ago

msc: Disable expecting CommonID when testing 'latest'

As of osmo-ttcn3-hacks.git Change-Id I4976d9bb1f07c8ab4ffa02848414f8ddd1bdfd3f
the test suite expects the MSC to send a CommonID to the BSC. As
older/existing tagged osmo-msc don't do that, we needt odisable that
check when verifying 'latest'.

Change-Id: If2e4cc41cb7b5758a78d694d62b34390a08e6387
Related: OS#2969

History

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

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

  • Priority changed from Normal to Low

#5 Updated by neels almost 3 years 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 over 1 year 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 over 1 year 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 over 1 year ago

  • Checklist item TTCN3 test for BSC side set to Done

#9 Updated by ipse over 1 year 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 over 1 year ago

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

#11 Updated by laforge over 1 year 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 year ago

BSC side commonID patch has finally been merged.

#13 Updated by laforge about 1 year 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)