Feature #1924
closedsupport TMSI based UE Register
100%
Description
specifically for the ip.access nano3G, we allow TMSI identification for UE Register requests.
The problem is that so far paging doesn't work when the hnbgw doesn't know the IMSI.
The nano3G apparently forwards whichever UE ID it gets from the phone in the UE Register Request,
which often is a TMSI ID. In that case the hnbgw doesn't know the IMSI of the UE,
resulting in paging not working.
Somehow the hnbgw should be able to find out the IMSI, or we need to fix paging otherwise.
Updated by neels about 7 years ago
If we don't accept a TMSI register, we often have to wait several minutes for a UE to give up
and try with an IMSI registration. That's why we just accept TMSI registration: developing on
the nano3G is really tiresome when having to wait several minutes for each attempt.
However, the paging via the hnbgw depends on the IMSI so far. So if a UE has subscribed by
TMSI, we can't page it.
A workaround is to attempt subscribing the UE to another network and be rejected.
In that case it usually forgets the TMSI it had for "my" network and re-registers with IMSI,
and subsequently paging works.
Maybe we can add a way to page by TMSI -- in the Paging message, apparently both IMSI
and TMSI are available, so we should be able to page by TMSI.
However, the hnbgw also doesn't trace TMSI Reallocation from a Location Updating.
So the TMSI will be a different one from the UE Registration TMSI.
We either need the IMSI or the correct TMSI, meaning that hnbgw needs to eavesdrop on Iuh...
Updated by laforge about 7 years ago
There is something fundamentally flawed with all of this. It is
completely against anything in the 3GPP specs to allow a LU from a
phone of which you don't know its identity (because either you know the
TMSI from a previous TMSI allocation, or because you know the IMSI).
In order to know the paging group of a MS, you need to know the IMSI, as
the paging group is computed from it. That's also the reason why the
IMSI is sent along with the paging request: so that the RAN can compute
the paging group on the air interface to transmit the paging request in.
It is impossible to compute that purely on the TMSI.
I have no clue what's happenign on the nano3G, but it is doing something
wrong here, very clearly. We need to find a work-around.
Please also don't confuse the HNBAP and the MM plane here. While we can
chose to accept the spec-violating UE REGISTER by TMSI on HNBAP, the LU
by TMSI to the MSC should trigger the IDENTITY REQUEST common MM
procedure so that the real identity (IMSI) is known to the MSC.
Updated by neels about 7 years ago
laforge wrote:
Please also don't confuse the HNBAP and the MM plane here. While we can
chose to accept the spec-violating UE REGISTER by TMSI on HNBAP, the LU
by TMSI to the MSC should trigger the IDENTITY REQUEST common MM
procedure so that the real identity (IMSI) is known to the MSC.
That's right, the UE Registration comes by HNBAP, which the hnbgw parses and handles.
The MM messaging to find out the IMSI is done by the MSC, in case the TMSI is not
known to the MSC. But IIRC so far the hnbgw simply forwards these messages.
In order to find out the IMSI, the hnbgw would have to "listen in" on MM packets
and interpret the IMSI out of that -- possibly though the phone does a LU with a TMSI
the MSC already knows, in which case no IMSI will be communicated.
So the hnbgw could alternatively keep track of the TMSI the UE currently uses
and then find out the IMSI from the paging request it receives.
That's the workaround I have in mind for the nonstandard way the nano3G sends UE Register.
Apologies, my wording probably wasn't clear enough.
Updated by laforge about 7 years ago
On Wed, Jan 25, 2017 at 11:04:29AM +0000, neels [REDMINE] wrote:
That's right, the UE Registration comes by HNBAP, which the hnbgw parses and handles.
The MM messaging to find out the IMSI is done by the MSC, in case the TMSI is not
known to the MSC. But IIRC so far the hnbgw simply forwards these messages.
yes. In fact, I don't think we need HNBAP for anything at all ;)
In order to find out the IMSI, the hnbgw would have to "listen in" on MM packets
and interpret the IMSI out of that -- possibly though the phone does a LU with a TMSI
the MSC already knows, in which case no IMSI will be communicated.
Why would we care? Why do we need to know the IMSI or the IMSI/TMSI
mapping in HNBAP? To me, in our use case, HNBAP is as redundant as it
gets. We only implement it to make the hNodeB happy. To us, it wold be
best if HNBAP UE REGISTEr wouldn't evne be required, rihgt?
That's the workaround I have in mind for the nonstandard way the nano3G sends UE Register.
What I'm missign is the motivation of this. For what exactly does the
HNBAP side need this? Is there some later signalling/transactions that
require us to know this relationship of IMSI and TMSI in the hnbgw?
Updated by neels about 7 years ago
- Assignee changed from neels to 118
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.
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?
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...?
Maybe someone can spend an hour investigating this beyond doubt at some point.
(I'd like to go back to the VLR now.)
Updated by laforge about 7 years ago
Hi Neels,
On Wed, Jan 25, 2017 at 11:55:54AM +0000, neels [REDMINE] wrote:
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.
There are plenty of configuration options in the MIB. One way would be
to configure a IMSI white-list inside the cell, and then it would have
to requrest the IMSI from the UE, for sure :)
Related MIB settings can include
csgId (3211) = 0
csgIndicator (3212) = TRUE
excludeAccessModeInHnbRegistration (3609) = FALSE
hnbName (3617) = " "
nonCsgUeAccessDecision (3610) = NON_CSG_UE_ACCESS_DECISION_LOCAL (1)
csgAccessMode (3608) = CSG_ACCESS_MODE_HYBRID_ACCESS (2)
particualrly the latter can be switched between OPEN (what we use),
CLOSED (only IMSIs in the whitelist) or hybrid (preferential for
whitelisted IMSIS, but also accessible to others).
maybe also
defaultUeRejectCause (3616) = DEFAULT_UE_REJ_CAUSE_ROAMING_NOT_ALLOWED_IN_LOC_AREA (13)
defaultUeRejectMethod (3579) = DEFAULT_UE_REJECT_METHOD_AUTO (1)
accessControlList (1947) = ()
accessControlNAuth (1949) = 1
accessControlNIdent (1950) = 1
accessControlNRej (1951) = 3
accessControlTAuth (1952) = 5
accessControlTIdent (1953) = 5
accessControlAttempts (1258) = 0
accessControlFailures (1259) = ()
accessControlSim (2105) = 0
accessControlSuccess (1260) = 0
Maybe someone can spend an hour investigating this beyond doubt at some point.
(I'd like to go back to the VLR now.)
Not now (during working hours). You should already be since yesterday,
IIRC. The deal was one day :) Thanks.
Updated by neels about 7 years ago
laforge wrote:
IIRC. The deal was one day :) Thanks.
I counted the day in hours, distributed over several calendar days :)
Ended up 3h more, mostly because of added testing whether the new ways break the sysmocell5000 3G voice.
Well, the public osmocom redmine is is probably not the place to discuss sysmocom hours anyway...
Updated by neels about 7 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
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.
