WG: patch 12 14, 15, 16

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/.

Holger Freyther zecke at selfish.org
Wed Jun 3 08:39:35 UTC 2009


On Wednesday 03 June 2009 09:59:11 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

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.




More information about the OpenBSC mailing list