hi,
i did some heavy tests this weekend with many mobile stations at once. with these patches all ressources (channels / subscribers) were released cleanly. even when mobile stations request more than 4 channels at a time (the current SDCCH4 is full), there is no ressource getting stuck anymore.
patch 39: the location update process did not work, if mobile station uses tmsi when comming from a different network. in this case the reject-timer must also be started, and we wait for imsi identity response. in case we can't find the subscriber or if we have an unimplemented location update, we release location update process and send a reject.
patch 40: in case of a channel breakdown, the signal handler for releasing lchan is called. the wrong pointer was used as lchan. (see last hunk) also we don't need to check use counter of lchan, if we receive an "cause 22 error". the lchan gets released anyway, if use counter becomes 0. (see first hunk). also i think we can force channel release when we receive an error indication. this can easily be tested: remove the battery during active call, then send a message to the mobile station (hang up on the remote). the message cannot be delivered, so the BTS send us an error indication, the channels and the call process gets released.
patch 41: the pointer "tall_bsc_ctx" belongs to the gsm_data.c file, not to include file.
patch 42: again my traffic channel patch. the mobile requests a channel. in case of a location update, we deliver the requested channel type. if we receive a channel request for other reasons, i force a TCH_F channel. this is requied, because we cannot change (modify) the channel right now. also i check if we have a TCH_F channel when we want to make a call to the mobile. if so, the channel is used, if not, paging is stated as if we would have no channel. so it is possible to call a mobile during location update, when it holds not a TCH_F channel.
patch 43: this small fix will not check for given subscriber/imsi here. this is already done in the next "if"-condition.
patch 38: still i use this little hacked install patch to install library and include files, so other applications like LCR can use openbsc without refering to the openbsc source directory. i use that install-hook, because i don't know much about autoconf. maybe there is a better way to do that.
anyway i don't get any measurement reports at all. i tried two BTS' and used the firmware as described in the wiki.
regards,
andreas
Dear Andreas,
I'll try to review your patches ASAP, but due to my current workload I think I might not find time before the weekend...
anyway i don't get any measurement reports at all. i tried two BTS' and used the firmware as described in the wiki.
I'm once again travelling and won't be in Berlin (with my BS-11) for at least another month, so I cannot do any tests by myself. I only have a nanoBTS 1800 with me here in Hamburg.
However, since Dieter has been seeing the measurement reports, I would hope he is able to verify wether it works for him with the current git version of OpenBSC, or what kind of changes he needs to make it work. Sorry :(
Cheers,
On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
patch 38: still i use this little hacked install patch to install library and include files, so other applications like LCR can use openbsc without refering to the openbsc source directory. i use that install-hook, because i don't know much about autoconf. maybe there is a better way to do that.
There is. Currently all the libraries are noinst libraries.. I did sent a patch to the mailinglist you could attempt to extent and make ready?
z.
On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
patch 39: the location update process did not work, if mobile station uses tmsi when comming from a different network. in this case the reject-timer must also be started, and we wait for imsi identity response. in case we can't find the subscriber or if we have an unimplemented location update, we release location update process and send a reject.
Sorry, to me it seems the patch is doing something else...
1.) if (!subscr) { DEBUGPC(DRR, "<- Can't find any subscriber for this ID\n"); /* FIXME: request id? close channel? */ + release_loc_updating_req(lchan); + gsm0408_loc_upd_rej(lchan, reject_cause); return -EINVAL; }
I think we can just move the schedule_reject from two lines below the if to the top. What do you think?
2.) The patch changes the policy from delayed reject (to not make the MS come back immediately) to a direct one. What is the reasoning?
On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
patch 40: in case of a channel breakdown, the signal handler for releasing lchan is called. the wrong pointer was used as lchan. (see last hunk) also we don't need to check use counter of lchan, if we receive an "cause 22 error". the lchan gets released anyway, if use counter becomes 0. (see first hunk). also i think we can force channel release when we receive an error indication. this can easily be tested: remove the battery during active call, then send a message to the mobile station (hang up on the remote). the message cannot be delivered, so the BTS send us an error indication, the channels and the call process gets released.
Okay. As stupid as it might sound please split that into three patches.
1.) Fixing my stupidity in gsm0408_handle_lchan_signal!!! sorry for making you suffer from it and thanks for fixing it.
2.) static int rsl_rx_rll_err_ind(struct msgb *msg)
3.) Explain why
+// if (msg->lchan->use_count > 0) { +// }
is a good change and should be applied?
thanks
Hi all On Mon, Jun 29, 2009 at 02:57:16PM +0200, Holger Hans Peter Freyther wrote:
On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote:
patch 40: in case of a channel breakdown, the signal handler for releasing lchan is called. the wrong pointer was used as lchan. (see last hunk) also we don't need to check use counter of lchan, if we receive an "cause 22 error". the lchan gets released anyway, if use counter becomes 0. (see first hunk). also i think we can force channel release when we receive an error indication. this can easily be tested: remove the battery during active call, then send a message to the mobile station (hang up on the remote). the message cannot be delivered, so the BTS send us an error indication, the channels and the call process gets released.
Okay. As stupid as it might sound please split that into three patches.
1.) Fixing my stupidity in gsm0408_handle_lchan_signal!!! sorry for making you suffer from it and thanks for fixing it.
I've applied this as a single commit now.
2.) static int rsl_rx_rll_err_ind(struct msgb *msg)
I've modified it to check for the cause, i.e. only release the channel in case T200 is expired. I'm not sure if we need to give up that quickly on other types of error indications.
3.) Explain why
+// if (msg->lchan->use_count > 0) { +// }
is a good change and should be applied?
done, too.
patch 43: this small fix will not check for given subscriber/imsi here. this is already done in the next "if"-condition.
thanks, applied.
-
Andreas.Eversberg -
Harald Welte -
Holger Hans Peter Freyther