This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Tue, Mar 12, 2019 at 05:04:09AM +0100, Neels Hofmeyr wrote: > So it would make sense to have some global struct representing the MS which > both BSC_ConnHdlr instances can access, if that is at all possible ... ? > The really interesting part then is the 24.007 11.2.3.2 N(SD) sequence number patching. Took me a moment to realize that when the one BSC wants to send CC DTAP while the other has advanced in N(SD) sequence numbering, the DTAP sent from TTCN3 is rejected as duplicate because TTCN3 has lost the MS state. So some way or other .. we need to manually tweak the TTCN3 N(SD) state to match the actual DTAP flow, or keep a common MS state in TTCN3 that sorts this out across BSCs. > As a bit of a weak workaround, I could inter-BSC handover right back to the > first BSC and then f_call_hangup() there :P Which works! except for the CC Release not getting recognised because of N(SD). So, yes, I'm seeing the first actual inter-BSC Handovers happening in ttcn3-msc-test :) Next, I'll go for some real-hardware testing. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190312/7a133cf1/attachment.bin>