https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092017-01-24T16:56:56ZOpen Source Mobile CommunicationsOsmoHNBGW - Feature #1924: support TMSI based UE Registerhttps://projects.osmocom.org/issues/1924?journal_id=29272017-01-24T16:56:56Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>If we don't accept a TMSI register, we often have to wait several minutes for a UE to give up<br />and try with an IMSI registration. That's why we just accept TMSI registration: developing on<br />the nano3G is really tiresome when having to wait several minutes for each attempt.</p>
<p>However, the paging via the hnbgw depends on the IMSI so far. So if a UE has subscribed by<br />TMSI, we can't page it.</p>
<p>A workaround is to attempt subscribing the UE to another network and be rejected.<br />In that case it usually forgets the TMSI it had for "my" network and re-registers with IMSI,<br />and subsequently paging works.</p>
<p>Maybe we can add a way to page by TMSI -- in the Paging message, apparently both IMSI<br />and TMSI are available, so we should be able to page by TMSI.</p>
<p>However, the hnbgw also doesn't trace TMSI Reallocation from a Location Updating.<br />So the TMSI will be a different one from the UE Registration TMSI.</p>
<p>We either need the IMSI or the correct TMSI, meaning that hnbgw needs to eavesdrop on Iuh...</p> OsmoHNBGW - Feature #1924: support TMSI based UE Registerhttps://projects.osmocom.org/issues/1924?journal_id=29332017-01-24T18:58:51Zlaforge
<ul></ul><p>There is something fundamentally flawed with all of this. It is<br />completely against anything in the 3GPP specs to allow a LU from a<br />phone of which you don't know its identity (because either you know the<br />TMSI from a previous TMSI allocation, or because you know the IMSI).</p>
<p>In order to know the paging group of a MS, you need to know the IMSI, as<br />the paging group is computed from it. That's also the reason why the<br />IMSI is sent along with the paging request: so that the RAN can compute<br />the paging group on the air interface to transmit the paging request in.<br />It is impossible to compute that purely on the TMSI.</p>
<p>I have no clue what's happenign on the nano3G, but it is doing something<br />wrong here, very clearly. We need to find a work-around.</p>
<p>Please also don't confuse the HNBAP and the MM plane here. While we can<br />chose to accept the spec-violating UE REGISTER by TMSI on HNBAP, the LU<br />by TMSI to the MSC should trigger the IDENTITY REQUEST common MM<br />procedure so that the real identity (IMSI) is known to the MSC.</p> OsmoHNBGW - Feature #1924: support TMSI based UE Registerhttps://projects.osmocom.org/issues/1924?journal_id=29342017-01-25T10:55:23Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/2934/diff?detail_id=4288">diff</a>)</li></ul> OsmoHNBGW - Feature #1924: support TMSI based UE Registerhttps://projects.osmocom.org/issues/1924?journal_id=29352017-01-25T11:04:29Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>Please also don't confuse the HNBAP and the MM plane here. While we can<br />chose to accept the spec-violating UE REGISTER by TMSI on HNBAP, the LU<br />by TMSI to the MSC should trigger the IDENTITY REQUEST common MM<br />procedure so that the real identity (IMSI) is known to the MSC.</p>
</blockquote>
<p>That's right, the UE Registration comes by HNBAP, which the hnbgw parses and handles.<br />The MM messaging to find out the IMSI is done by the MSC, in case the TMSI is not<br />known to the MSC. But IIRC so far the hnbgw simply forwards these messages.</p>
<p>In order to find out the IMSI, the hnbgw would have to "listen in" on MM packets<br />and interpret the IMSI out of that -- possibly though the phone does a LU with a TMSI<br />the MSC already knows, in which case no IMSI will be communicated.</p>
<p>So the hnbgw could alternatively keep track of the TMSI the UE currently uses<br />and then find out the IMSI from the paging request it receives.</p>
<p>That's the workaround I have in mind for the nonstandard way the nano3G sends UE Register.<br />Apologies, my wording probably wasn't clear enough.</p> OsmoHNBGW - Feature #1924: support TMSI based UE Registerhttps://projects.osmocom.org/issues/1924?journal_id=29362017-01-25T11:23:33Zlaforge
<ul></ul><p>On Wed, Jan 25, 2017 at 11:04:29AM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>That's right, the UE Registration comes by HNBAP, which the hnbgw parses and handles.<br />The MM messaging to find out the IMSI is done by the MSC, in case the TMSI is not<br />known to the MSC. But IIRC so far the hnbgw simply forwards these messages.</p>
</blockquote>
<p>yes. In fact, I don't think we need HNBAP for anything at all ;)</p>
<blockquote>
<p>In order to find out the IMSI, the hnbgw would have to "listen in" on MM packets<br />and interpret the IMSI out of that -- possibly though the phone does a LU with a TMSI<br />the MSC already knows, in which case no IMSI will be communicated.</p>
</blockquote>
<p>Why would we care? Why do we need to know the IMSI or the IMSI/TMSI<br />mapping in HNBAP? To me, in our use case, HNBAP is as redundant as it<br />gets. We only implement it to make the hNodeB happy. To us, it wold be<br />best if HNBAP UE REGISTEr wouldn't evne be required, rihgt?</p>
<blockquote>
<p>That's the workaround I have in mind for the nonstandard way the nano3G sends UE Register.</p>
</blockquote>
<p>What I'm missign is the motivation of this. For what exactly does the<br />HNBAP side need this? Is there some later signalling/transactions that<br />require us to know this relationship of IMSI and TMSI in the hnbgw?</p> OsmoHNBGW - Feature #1924: support TMSI based UE Registerhttps://projects.osmocom.org/issues/1924?journal_id=29372017-01-25T11:55:54Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Assignee</strong> changed from <i>neels</i> to <i>118</i></li></ul><p>In fact I had not taken a closer look at the hnbgw yet, all I saw was that paging works when the UE Registration was by IMSI and fails if it was by TMSI.</p>
<p>Looking at the hnbgw code now, I see that indeed it looks like any and all paging requests are simply fed through to RUA, to every connected hNodeB. It looks like the nano3G itself fails to route the paging, and that we can't do anything about this?</p>
<p>If the fail is entirely within the nano3G and there is no config or similar to fix this behavior, I'm afraid the best way we can fix it is to reject TMSI UE Registration and let the phone fail for 15 minutes, until it sends an IMSI ID and all is well. This is hell for development cycles though. Again, the workaround is to be rejected by a different network to lose the TMSI in the phone, but waiting for the "Searching for Networks" screen is also dev cycle hell :/ This could also mean that whenever a UE moves from one to the next nano3G cell, it will be offline for the first 15 minutes...?</p>
<p>Maybe someone can spend an hour investigating this beyond doubt at some point.<br />(I'd like to go back to the VLR now.)</p> OsmoHNBGW - Feature #1924: support TMSI based UE Registerhttps://projects.osmocom.org/issues/1924?journal_id=29382017-01-25T13:00:36Zlaforge
<ul></ul><p>Hi Neels,</p>
<p>On Wed, Jan 25, 2017 at 11:55:54AM +0000, neels [REDMINE] wrote:</p>
<blockquote>
<p>If the fail is entirely within the nano3G and there is no config or<br />similar to fix this behavior, I'm afraid the best way we can fix it is<br />to reject TMSI UE Registration and let the phone fail for 15 minutes,<br />until it sends an IMSI ID and all is well.</p>
</blockquote>
<p>There are plenty of configuration options in the MIB. One way would be<br />to configure a IMSI white-list inside the cell, and then it would have<br />to requrest the IMSI from the UE, for sure :)</p>
<p>Related MIB settings can include</p>
<p>csgId (3211) = 0<br />csgIndicator (3212) = TRUE<br />excludeAccessModeInHnbRegistration (3609) = FALSE<br />hnbName (3617) = " " <br />nonCsgUeAccessDecision (3610) = NON_CSG_UE_ACCESS_DECISION_LOCAL (1)<br />csgAccessMode (3608) = CSG_ACCESS_MODE_HYBRID_ACCESS (2)</p>
<p>particualrly the latter can be switched between OPEN (what we use),<br />CLOSED (only IMSIs in the whitelist) or hybrid (preferential for<br />whitelisted IMSIS, but also accessible to others).</p>
<p>maybe also<br />defaultUeRejectCause (3616) = DEFAULT_UE_REJ_CAUSE_ROAMING_NOT_ALLOWED_IN_LOC_AREA (13)<br />defaultUeRejectMethod (3579) = DEFAULT_UE_REJECT_METHOD_AUTO (1)<br />accessControlList (1947) = ()<br />accessControlNAuth (1949) = 1<br />accessControlNIdent (1950) = 1<br />accessControlNRej (1951) = 3<br />accessControlTAuth (1952) = 5<br />accessControlTIdent (1953) = 5<br />accessControlAttempts (1258) = 0<br />accessControlFailures (1259) = ()<br />accessControlSim (2105) = 0<br />accessControlSuccess (1260) = 0</p>
<blockquote>
<p>Maybe someone can spend an hour investigating this beyond doubt at some point.<br />(I'd like to go back to the VLR now.)</p>
</blockquote>
<p>Not now (during working hours). You should already be since yesterday,<br />IIRC. The deal was one day :) Thanks.</p> OsmoHNBGW - Feature #1924: support TMSI based UE Registerhttps://projects.osmocom.org/issues/1924?journal_id=29452017-01-26T14:21:55Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>IIRC. The deal was one day :) Thanks.</p>
</blockquote>
<p>I counted the day in hours, distributed over several calendar days :)<br />Ended up 3h more, mostly because of added testing whether the new ways break the sysmocell5000 3G voice.<br />Well, the public osmocom redmine is is probably not the place to discuss sysmocom hours anyway...</p> OsmoHNBGW - Feature #1924: support TMSI based UE Registerhttps://projects.osmocom.org/issues/1924?journal_id=31502017-02-28T02:30:31Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>In a short test (while rebasing the sysmocom/iu branch and verifying that it still works) using the closed access method with explicit IMSIs indeed caused paging to work, despite UE Registration by TMSI. It seems to be entirely an issue within the nano3G indeed.</p> OsmoHNBGW - Feature #1924: support TMSI based UE Registerhttps://projects.osmocom.org/issues/1924?journal_id=31792017-02-28T17:32:56Zlaforge
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Closed</i></li></ul>