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/.
Harald Welte laforge at gnumonks.orgOn Wed, Jun 03, 2009 at 09:59:11AM +0200, Andreas.Eversberg wrote:
>
> -----Ursprüngliche Nachricht-----
> Von: openbsc-bounces at lists.gnumonks.org [mailto:openbsc-bounces at 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.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20090605/9ff15277/attachment.bin>