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