Hi Harald, vacation time, hence slow response. Thank you for your feedback. Here are few answers about your several ideas : b) converting CSN.1 to ASN.1 and back is not straightforward ; there are some structures in CSN.1 (such as recursive construct with a "continuation" bit) which may be hard to translate to ASN.1. I am not confident this would work well. c) this would be great. I was wondering if there exists a real-world GPRS L1 and transceiver that we could use, in addition to the direct / simulated connection to the OsmoPCU ? I am not aware of any unfortunately. d) I am not comfortable to generate a full C or C++ code. On the other side, it would be quite easy to generate headers with proper structs for each object. This would have to link with an appropriate C / C++ encoding runtime.
Regards Benoit 2018-08-01 21:58 GMT+02:00 Harald Welte <[email protected]>: > Hi Benoit, > > On Wed, Aug 01, 2018 at 09:34:27PM +0200, benoit michau wrote: > >> This email to point to a recent development I made on CSN.1, which >> might be of interest to some of you. > > Thanks a lot for implementing this in the first place, and also for > sharing information about it here. > > It's amazing that we finally seem to be getting good CSN.1 tools > > >> I extracted and consolidated all >> CSN.1 definitions from 24.008, 44.018 and 44.060 (the "consolidation" >> part was quite hard...). > > I think the biggest problems are the many syntax errors in the official CSN.1 > syntax in the specs. I once tried to parse it from proprietaryt CSN.1 tools, > and it was a nightmare. In fact, there are companies selling the cleaned up > and fully confirming syntax for money. > > Somebody should submit your fixed versin to 3GPP so they can release a > correct syntax at least... > >> I have also developped a CSN.1 to Python >> translater, and a runtime to encode / decode any CSN.1 structures. > > Thanks. What we need to figure out now is how to make best use of this from > within > Osmocom. OsmoPCU is - as you know - implemented in C. Rewriting it in > python is > unfortunately not an option, if not alone for performance reasons :/ > > However, it would be great if we could benefit from your work in other ways, > such as > > a) for unit testing our code (particularly the hand-written encoders/decoders) > > b) for integration testing. Unfortunately TTCN3/TITAN doesn't have any CSN.1 > tools, > so we cannot use a "trusted, aut-generated" encoder/decoder from our > existing > integration tests. However, maybe there are ways we can integrate your > python > CSN.1 with TTCN-3? MAybe it's possible to auto-generate ASN.1 syntax and > an ASN.1(BER)-to-CSN.1 > transcoder in python. Then we could use TTCN3 templates in the TITAN > world, and > we'd simply call a function to encode as ASN.1-BER, and then into your > transcoder to create > CSN.1 from that (and vice versa)? > > c) something like a MS-side (E)GPRS RLC/MAC implementation in python. We > could then use this > over "virtual/simulated" radio against OsmoPCU. > > d) maybe generate C / C++ encoder/decoder from your python framework, since > it fully > parses and understands the syntax tree... > > I'm not a python expert and I have not used your code yet, so I'm not sure > what is > realistic/possible. But for sure it would be really great to use generated > parser/encoders > for CSN.1 in one way or another... > > If you (or anyone else) have any further ideas to share, please feel free to > do so! > > Regards, > Harald > -- > - Harald Welte <[email protected]> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6)
