Hi all,
I've mentioned this many months before, but Ericsson has now (well, a month ago) finally made a public announcement about the public release of their SS7/SIGTRAN core protocols in TTCN-3. You can read more about it at https://www.eclipse.org/forums/index.php/t/1089686/ - where they actually even refer to us as being the trigger to release them.
There are still many tests to write beyond those currently existing.
Most recently I wrote a set of MGCP tests for our new osmo-mgw, which Philipp is now using to iron out some kinks in the codebase.
The past week I've been working on simulating the minimal subset of N numbers of BSCs and N numbers of MSCs from a single test suite in order to test osmo-bsc_nat, and specifically the "IMSI-based routing to different MSCs" feature that Daniel has been working on. It's still work in progress, but definitely the by far most complex TTCN-3 project that I've written so far.
After completing that, I would like to spend some more time on OsmoBTS and OsmoBSC related tests. The difficulty here is that the more we get to the RAN / air interface, the less existing prtoocols / codecs exist, so e.g. A-bis RSL would first have to be implemented. The good part is that it's actually super easy using the expressive syntax of the TITAN "raw" codec. Basically you define the structure of the data in files like http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_RR_Types.ttcn and you don't have to write a single line for encoding/parsing :)
Regards, Harald
On Fri, Nov 24, 2017 at 08:28:35PM +0100, Harald Welte wrote:
Hi all,
I've mentioned this many months before, but Ericsson has now (well, a month ago) finally made a public announcement about the public release of their SS7/SIGTRAN core protocols in TTCN-3. You can read more about it at https://www.eclipse.org/forums/index.php/t/1089686/ - where they actually even refer to us as being the trigger to release them.
Heh, nice one, complete with an introductory paragraph :)
so e.g. A-bis RSL would first have to be implemented. The good part is that it's actually super easy using the expressive syntax of the TITAN "raw" codec. Basically you define the structure of the data in files like http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_RR_Types.ttcn and you don't have to write a single line for encoding/parsing :)
So you write a "titan struct" and get the binary en/decoding from it, even with conditional presence and cross conditions and all. nice.
Makes me think, could one use that in production code to parse/encode messages? It's C after all, isn't it. I wonder what its C representation looks like, whether it makes working with it any easier than the TLV code we're using.
~N
Hi Neels,
On Mon, Nov 27, 2017 at 01:30:01PM +0100, Neels Hofmeyr wrote:
On Fri, Nov 24, 2017 at 08:28:35PM +0100, Harald Welte wrote:
so e.g. A-bis RSL would first have to be implemented. The good part is that it's actually super easy using the expressive syntax of the TITAN "raw" codec. Basically you define the structure of the data in files like http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_RR_Types.ttcn and you don't have to write a single line for encoding/parsing :)
So you write a "titan struct" and get the binary en/decoding from it, even with conditional presence and cross conditions and all. nice.
Correct. A partial RSL implementation can be seen at http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/RSL_Types.ttcn
My plan is to use this together with the A code for BSC level tests, so one can perform some procedure/activity on both A-bis and A and test if the BSC does what's expected.
Makes me think, could one use that in production code to parse/encode messages?
I wouldn't want to try, at least not on the kind of low-performance systems that we normally work on.
It's C after all, isn't it.
It's C++.
I wonder what its C representation looks like,
You can simply compile a the TTCN module ("make compile") and you get the resulting generated C++ code.
whether it makes working with it any easier than the TLV code we're using.
I think our TLV dode is exceptionally comfortable for a very low-overhead C-language approach. What is the difficulty? Of course it only handles the TLV structure and not the content of any IE. But that's because it is a TLV parser and not anything else...
-
Harald Welte -
Neels Hofmeyr