-----Ursprüngliche Nachricht----- Von: openbsc-bounces@lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther
I'm not sure what happens to IMSI ATTACHED/DETACHED when doing handover, so far the detach path was written in a way that even a sequence like: new BTS ATTACHED old BTS DETACHED
hi holger,
here is what happens:
BTS(new LAC) ATTACH -> DB = new LAC BTS(old LAC) DETACH -> DB = 0
the mobile attaches to the new LAC, so the database stores the new LAC number. next, the mobile detaches from the old LAC and the database stores 0 for 'not attached'. the database now holds a wrong value.
to solve this, we may only allow detach, if the mobile is not already attached to a different location area:
if (DB == old LAC) then DB = 0 else ignore!
so the mobile can only detach from a BTS with the location it is currently attached.
i checked the code yesterday. i saw that the subscriber is associated to a LAC and a bts when attaching. when detaching, the association to the bts is removed, if not already attached to a different one.
is this correct? as far as i know, the attached subscriber is associated to a LAC only. it may silently change the BTS without location update, if the MCC/MNC/LAC is equal on this BTS. when we page a mobile, we must do it on all BTS of that location area, as far as i know. (see patch 27) if the mobile requests a channel, it chooses one of the BTS. i think we must remove the "current_bts" pointer from the subscriber structure.
andreas
On Wednesday 03 June 2009 09:59:11 Andreas.Eversberg wrote:
-----Ursprüngliche Nachricht----- Von: openbsc-bounces@lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther
I'm not sure what happens to IMSI ATTACHED/DETACHED when doing handover, so far the detach path was written in a way that even a sequence like: new BTS ATTACHED old BTS DETACHED
hi holger,
here is what happens:
BTS(new LAC) ATTACH -> DB = new LAC BTS(old LAC) DETACH -> DB = 0
okay, so my assumption was correct.
to solve this, we may only allow detach, if the mobile is not already attached to a different location area:
if (DB == old LAC) then DB = 0 else ignore!
okay, the same approach as with the bts pointer (unless I fucked up in the code)
is this correct? as far as i know, the attached subscriber is associated to a LAC only. it may silently change the BTS without location update,
You are right. It is wrong. I assumed that BTS <-> LAC map 1:1 but that is not the case. Could you prepare a change to gsm_subscriber to store the LAC + CELL ID and remove the struct gsm_bts pointer or would you be willing to test one? Maybe even carry out the change in the db.c to store/restore the that information (e.g. check my "VLR" patches as this is what we are building).
For the future we would have something like this: 1.) Call +123323 2.) Find the gsm_subscriber and load it from the db 3.) Check the VLR where we currently think it is struct gsm_bts* bts = bts_resolve(subscr->lac, subscr->cell_id); and then page...
z.
On Wed, Jun 03, 2009 at 09:59:11AM +0200, Andreas.Eversberg wrote:
-----Ursprüngliche Nachricht----- Von: openbsc-bounces@lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Holger Freyther
I'm not sure what happens to IMSI ATTACHED/DETACHED when doing handover, so far the detach path was written in a way that even a sequence like: new BTS ATTACHED old BTS DETACHED
hi holger,
here is what happens:
BTS(new LAC) ATTACH -> DB = new LAC BTS(old LAC) DETACH -> DB = 0
are you familiar enough with the protocol to make this kind of statement? I wouldn't be sure. But if you say that switching LAC with IMSI Attach/Detach enabled works this way, ok.
The reason I'm asking is that the phone would have to first go to a different ARFCN, sync to it and send some message, and then go back to the old one. This sounds really strange to me. What if you're in a fast moving vehicle and can no longer go back to the old cell/LAC?
I would assume that an attach in a new LAC would implicitly be treated as a detach in the old cell, without any explicit IMSI DETACH message.
Wikipedia is certainly not the definitive anwer, but as you can see at http://en.wikipedia.org/wiki/IMSI_attach it claims that ATTACH is only performed at the initial switch-on. Later on, it does a regular Location Update.
The 04.08 chyapter 4.4.3 says:
===== The IMSI attach procedure is invoked if the detach/attach procedures are required by the network and an IMSI is activated in a mobile station (i.e. activation of a mobile station with plug-in SIM, insertion of a card in a card-operated mobile station etc.) within coverage area from the network or a mobile station with an IMSI activated outside the coverage area enters the coverage area. The IMSI attach procedure is used only if the update status is UPDATED and if the stored Location Area Identification is the same as the one which is actually broadcasted on the BCCH of the current serving cell. Otherwise a normal location updating procedure (see sub-clause 4.4.1) is invoked independently of the ATT flag indication. =====
So we will certainly get a Loaction Update both on initial phone power-up, as well as when we switch from one LAC to another. We don't really care if it's a IMSI ATTACH type or other type Location Update.
The IMSI DETACH (section 4.3.4) doesn't say anything about changing location area. it is only sent once the SIM is deactivated/removed or the phone switched off.
to solve this, we may only allow detach, if the mobile is not already attached to a different location area:
if (DB == old LAC) then DB = 0 else ignore!
so the mobile can only detach from a BTS with the location it is currently attached.
I don't think we need this, see above.
But what I'm thinking right now is whether we have a DoS here, if somebody spoofs tons of IMSI DETACH messages. But well, not our primary concern right now. As soon as authentication and ciphering is used, it's not that much of an issue anymore anyway.
is this correct? as far as i know, the attached subscriber is associated to a LAC only. it may silently change the BTS without location update, if the MCC/MNC/LAC is equal on this BTS. when we page a mobile, we must do it on all BTS of that location area, as far as i know. (see patch 27) if the mobile requests a channel, it chooses one of the BTS. i think we must remove the "current_bts" pointer from the subscriber structure.
Yes. The 'current_bts' pointer goes back to a time where at least I (and presumably Holger, too) did not yet fully understand the option of a LAC consisting of multiple BTS.
So yes, I think it should be removed. What we'd rather need is a pointer to the current RR (or MM?) connection, if any. So if we have some MT call or other service request, we look up the subscriber and can either use an existing RR/MM connection, or if that one doesn't exist, we fall back to paging of all BTS in the LAC.
The RR/MM connection is represented by what we call "lchan" right now.
On Friday 05 June 2009 16:53:47 Harald Welte wrote:
Wikipedia is certainly not the definitive anwer, but as you can see at http://en.wikipedia.org/wiki/IMSI_attach it claims that ATTACH is only performed at the initial switch-on. Later on, it does a regular Location Update.
Right, the spec agrees here (I stumbled across this today) and we need to fix the code. It is written in 04.08 Section 4.4.3 (IMSI Attach)
"The IMSI attach procedure is used only if the update status is UPDATED and if the stored Location Area Identification is the same as the one which is actually broadcasted on the BCCH of the current serving cell. Otherwise a normal location updating procedure (see sub-clause 4.4.1) is invoked independently of the ATT flag indication."
So I don't fully understand this yet, but it is a strong indication that wikipedia is right...
greetings z.
On Fri, Jun 05, 2009 at 03:30:23PM +0200, Holger Freyther wrote:
On Friday 05 June 2009 16:53:47 Harald Welte wrote:
Wikipedia is certainly not the definitive anwer, but as you can see at http://en.wikipedia.org/wiki/IMSI_attach it claims that ATTACH is only performed at the initial switch-on. Later on, it does a regular Location Update.
Right, the spec agrees here (I stumbled across this today) and we need to fix the code. It is written in 04.08 Section 4.4.3 (IMSI Attach)
"The IMSI attach procedure is used only if the update status is UPDATED and if the stored Location Area Identification is the same as the one which is actually broadcasted on the BCCH of the current serving cell. Otherwise a normal location updating procedure (see sub-clause 4.4.1) is invoked independently of the ATT flag indication."
So I don't fully understand this yet, but it is a strong indication that wikipedia is right...
'update status' is the status as stored in the SIM. UPDATED means that the last Location Update was successful, and the SIM contains a valid LAI.
So IMSI ATTACH is only used if the SIM card is activated in the same LA that it was last active in.
If the SIM was registered to a different network or LA, or actually failed to register to a network (unsuccessful location update), then the status is NOT UPDATED and thus IMSI ATTACH should not be performed, but rather a regular Location Update
So IMSI ATTACH/DETACH really is about a SIM(IMSI) being activated/deactivated in a given LA. activation/deactivation typically is switching the phone on or off.
While moving between location areas [at least in the same network] there should be no IMSI ATTACH, as per the spec.
On Fri, Jun 05, 2009 at 10:37:49PM +0200, Harald Welte wrote:
So IMSI ATTACH/DETACH really is about a SIM(IMSI) being activated/deactivated in a given LA. activation/deactivation typically is switching the phone on or off.
In other words: IMSI ATTACH/DETACH is only used in addition to regular Location Update, and it is used in situations where a MS on a network with ATT=0 would not perform any signalling with the network at all.
-
Andreas.Eversberg -
Harald Welte -
Holger Freyther