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.
On Thursday 04 June 2009 10:27:28 Andreas.Eversberg wrote:
check out the patch 27 (application). there is a loop when start paging. it already loops all bts with the LAC.
To be honest the patch 27 is so big that this is not easy to spot. The feature of searching the right bts(es) and trying to page there would be good enough for a patch on its own. :)
Let me use this opportunity to leave my two cents (again). I understand a big patch happens naturally but it would be great if you could attempt to split things up into smaller pieces (patches up to 27 were a great progress). Smaller patches are more easily judged which means they end up in the repository faster which will make everyone involved happy.
but we are certainly on a good way, so please keep up with your good work and I will try to merge patches as fast as possible.
thanks a lot z.
On Thursday 04 June 2009 10:27:28 Andreas.Eversberg wrote:
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??)
Please see the mail "[PATCH 0/3] Channel requests/Management in gsm_subscriber" from 2009-04-19 21:20 and "[RFC] Patches for better channel management". The bottom line of the patches are to make the "paging" layer more internal and request a lchan for a given subscriber (finding the right bts, checking if we have capacity, checking if the MS has capacity, properly queuing things). I will rediff this over the weekend as well.
z.
-
Andreas.Eversberg -
Holger Freyther