i use the calling party's BTS, because the subscriber database does not contain the current BTS number of the subscriber last seen. (or detached)
i agree that the subscriber gives us information about the paged bts and we can resolve the gsm_network from that also.
-----Ursprüngliche Nachricht----- Von: Harald Welte [mailto:laforge@gnumonks.org] Gesendet: Samstag, 23. Mai 2009 08:30 An: Andreas.Eversberg Cc: openbsc@lists.gnumonks.org Betreff: Re: patch: 8_paging
Hi again,
On Sat, May 23, 2009 at 02:23:11PM +0800, Harald Welte wrote:
On Thu, May 21, 2009 at 02:27:36PM +0200, Andreas.Eversberg wrote:
Paging refers to a BTS. To page a mobile phone, the current location is required. If paging succeeds or expires, the BTS structure is also given to the callback function (cbfn).
Because paging refers to a BTS, the cbfn (callback function) must include a pointer to bts.
The paging response includes a lchan pointer, which can be resolved to the physical channel / timeslot and to the trx and finally to the BTS. Is this not sufficient?
Ah, ok, in the case we do not successfully allocate a lchan, then that's obviously NULL.
Still, when you call paging_request() you actually pass on a number of parameters, including:
1) the BTS on which you want to page (whcih, indeed, is currently the BTS of the calling party rather than the called party). So this parameter is likely to get removed soon.
2) The subscriber that was called. This should be used by paging_request() to resolve the BTS that this subscriber was last seen/registered to.
3) a reference to the call, which is treated as an opaque pointer that is passed back as a reference when calling the call-back function. So if the bts of the calling or called party needs to be known, it should probably be referenced from that data structure.
Or am I missing something?
Hi Andreas,
On Sat, May 23, 2009 at 09:47:01AM +0200, Andreas.Eversberg wrote:
i use the calling party's BTS, because the subscriber database does not contain the current BTS number of the subscriber last seen. (or detached)
Well, from my understanding, at least in typical GSM network operation, the network never really knows the exact BTS. It only knows the 'location area' in which the phone was last seen.
A location area can be as small as a single BTS, but it can also contain any number of BTS.
If a network pages a MS, it checks the HLR/VLR for the location area the MS was last seen in. If there are multiple BTS in that location area, _all_ of those BTS need to page for the MS.
So I think for OpenBSC, we do as follows:
1) We assume that in the typical small network, users will configure the network to only have a single BTS per location area.
2) If a user has multiple BTS in a location area, we should (maybe not right now, but at least at some point in the future) send the paging request on every BTS in that location area
The subscriber database even right now contains the location area code (LAC) as a field in the database. the db.c code re-reads this lac from the SQL table, so you can lookup the subscriber by its extension, then determine its LAC, lookup the BTS based on the LAC and then send the paging requests there.
-----Ursprüngliche Nachricht-----
If you don't mind, I would like to ask you to not full-quote the previous messages on the list. Thanks.
Cheers,
On Sat, May 23, 2009 at 09:48:04PM +0800, Harald Welte wrote:
The subscriber database even right now contains the location area code (LAC) as a field in the database. the db.c code re-reads this lac from the SQL table, so you can lookup the subscriber by its extension, then determine its LAC, lookup the BTS based on the LAC and then send the paging requests there.
I have just added a function gsm_bts_by_lac() which should allow you to search for a BTS based on the LAC of the called subscriber.
What we're still missing (but that's an optimization) is some code that removes the LAC (or sets some 'detached' flag) in the Subscriber table once we get the IMSI DETACH.
Right now, when a subscriber is called after he has DETACHed, we still try to page him. Well, I can live with that for now, we're not running out of paging slots any time soon :)
Regards,
-
Andreas.Eversberg -
Harald Welte