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