From: git repository hosting Precedence: list To: osmocom-commitlog@lists.osmocom.org Date: Tue, 26 Feb 2013 10:54:59 +0100 Message-ID: Subject: openbsc.git branch zecke/hacks/wip-docs created. 0.12.0-267-gb400fe1 Message: 4 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)". The branch, zecke/hacks/wip-docs has been created at b400fe14e46255997732625ccc29433d7d4b35bd (commit) - Log ----------------------------------------------------------------- http://cgit.osmocom.org/cgit/openbsc/commit/?id=b400fe14e46255997732625ccc29433d7d4b35bd commit b400fe14e46255997732625ccc29433d7d4b35bd Author: Holger Hans Peter Freyther Date: Tue Feb 26 10:54:19 2013 +0100 doc: Create a documentation on the SCCP/lite implementation we have Describe how we handle/dispatch SCCP messages in the osmo-bsc. http://cgit.osmocom.org/cgit/openbsc/commit/?id=862b53ed5d8b095b3f82c6a20d3ef2d00127439a commit 862b53ed5d8b095b3f82c6a20d3ef2d00127439a Author: Holger Hans Peter Freyther Date: Sun Jan 27 15:58:53 2013 +0100 Modify osmo-nitb for load testing a BTS * Send Modify requests during release * Send multiple SACCH deactivates * Optionally do not send IMM.ASSIGNMENT during channel granting to force the phone to send multiple RACH bursts.. * abort() when a channel goes broken http://cgit.osmocom.org/cgit/openbsc/commit/?id=f1d9e10c50537d16e1e2fd77162b8526b45e7caa commit f1d9e10c50537d16e1e2fd77162b8526b45e7caa Author: Holger Hans Peter Freyther Date: Mon Jan 21 09:01:29 2013 +0100 rsl: Re-introduce the SACCH deactivation marker GSM 08.58 is not clear if the SACCH Deactivate is an idempotent operation, it has exposed a bug in my osmo-bts channel release re-work with the queue and I assume the nanoBTS will not deal with it any better. In my tests it was possible to get a N200+1 times error during the channel release procedure which lead to releasing the SACCH again. When this timeout occurs it is very difficult to find out if the SACCH was already deactivated. Re-introduce the usage of the sacch_deact flag in the lchan. When the release is triggered by higher levels the SACCH should be active and we check for this with a log message, in case of the error handling we check if the SACCH was de-activated before de-activating it even if we are requested to do it. This way we know the SACCH will be de-activated at most once. ----------------------------------------------------------------------- hooks/post-receive -- The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)