This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Sun, May 20, 2018 at 05:14:41AM -0400, loay abdelrazek wrote: > Hi Harald > > Yes yes I totally understand , so what could be the cases for sending the > IMSI and what would be the possible remediation for such thing It sounds like you actually don't "totally" understand and are asking for a 101 on IMSI and TMSI? The subscriber is identified to the network by its IMSI, which stays constant. A new TMSI is given on every Location Update, meaning it changes all the time, which is good for privacy. The network does its best to remember the last TMSI the phone has been given. But before the network can know who that subscriber is, things have to start out with the IMSI. That's normally when the phone asks for a Location Update for the first time. Usually the new TMSI is sent to the phone ciphered, so that the IMSI <-> TMSI mapping is essentially secret. A TMSI is short-lived and an MSC may decide not to store IMSI<->TMSI mappings forever, for various/unknown reasons. So as soon as there is no TMSI left in the MSC's subscriber state, the only way to page is by IMSI. Also, the phone may have forgotten its TMSI, e.g. after roaming to a different network. But: AFAICT, under "proper" operations, a subscriber should have a TMSI after a Location Update, and either detach when it leaves or be implicitly detached by timeout. So as long as it is Page-able by the MSC, it should have a TMSI as well. In other words, the MSC should either have a TMSI to page for, or the subscriber's state should be "not attached", i.e. can't page anyway. Bottom line, whenever paging goes out by IMSI, the MSC has actively decided to not bother about privacy (by implementation, config or by licensing details). IIRC, the only way to get an IMSI paging out of osmo-msc is to globally switch off TMSI allocation. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180522/1478524c/attachment.bin>