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/.
Andreas.Eversberg Andreas.Eversberg at versatel.de>> 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). i can test this. i will remove bts pointer and only check lac when detaching. when paging, i will loop all bts and add a paging request to all bts with that pointer. if the paging responds, we receive the lchan and then stop paging requests to other bts' (if any). if we receive resonse, we ignore them, if we already received an lchan. (error case when two mobiles share same imsi or other error cases). what about the "VLR" patch? where is it? why do you need a VLR? (HLR??) >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. check out the patch 27 (application). there is a loop when start paging. it already loops all bts with the LAC. there is an error in that: the current_bts pointer is changed for every paging request. this would be removed, if the bts pointer is removed. also the stopping of parallel paging requests (same subscriber, different bts) is not realized. if you aggree with that, i will implement it this weekend.