The idea is similar to protocol buffers. Tooling is a significant barrier to entry.
- The commercial offerings are very expensive.
- it is a little hard to read, but very difficult to write correctly.
- it is difficult to parse the spec and code generation is non-trivial, and although Basic Encoding Rules are relatively straightforward, Packed Encoding Rules are not. So rolling your own is daunting.
- There are some open source tools but until recently they were unable to parse the latest language features used in LTE. I am convinced it is designed to be hard to parse to protect the encumbents.
- Unless you are using C/C++ (most tools generate these) you have to somehow generate FFI bindings, which you’ll want to automate for a large spec which requires parsing the spec...
> - There are some open source tools but until recently they were unable to parse the latest
> language features used in LTE.
> I am convinced it is designed to be hard to parse to protect the encumbents
I don't think so, and I work for a small company doing LTE products. LTE uses a rather small subset of ASN.1, and it's not a big problem to handle it really. It's not a barrier at all, it's even making things simpler compared to a less formal definition of protocol messages. I experienced informal protocols, with the result of wasting a lot of energy on interoperability tests due to different interpretations. ASN.1 in LTE gets rid of this.
IIRC, ASN.1 was created as a specification language written by humans for humans. Only later on it became used for direct code generation. So its design was not meant to be easy to parse for a compiler, although it's the way it's used now.
There are several reasons to the lack of open source tools IMHO. A full ASN.1 compiler is a complex project, so that's some barrier to entry: not everyone can invest the needed time. The fact that any application typically need only a subset of the full ASN.1 means that there's likely a lot of partial /ad-hoc implementations, so not very fit to open source.
Then there is a cultural aspect leading to a lack of interest: ASN.1 is old and from a specific, non mainstream culture (the telco world). The new kids are just busy with JSON or protocol buffer, even if ASN.1 works very well. It's software, we're all busy re-inventing our own better wheel ;)
I didn’t mean to say LTE is deliberately complex, compared to older specs it’s very simple. I was thinking more of ASN.1 itself which even in later editions added features that only made the parsing and codegen harder, though they made authoring simpler.
Specifically I was looking asn1c but IIRC it could not handle parameterization used in S1AP - maybe 3 years ago? It might have changed right after I tried, I didn’t follow it up and took a different route.
I think we agree, the problem is worsened when you need to support multiple ASN.1 protocols, including MEGACO, S1AP, RANAP, H.323, GSM MAP, TCAP etc - you need a tool that provides a stable and unified API for all protocols. And if you want that, today you still have to pay for it or struggle with multiple tools with different APIs.
Don’t get me wrong I like ASN.1 very much. Text based protocols (esp. over TCP) have caused me more headaches than ASN.1 and ad-hoc binaries protocols combined. HTTP/2 is worth it just for ditching text. The rest of it is just icing :-)
- The commercial offerings are very expensive.
- it is a little hard to read, but very difficult to write correctly.
- it is difficult to parse the spec and code generation is non-trivial, and although Basic Encoding Rules are relatively straightforward, Packed Encoding Rules are not. So rolling your own is daunting.
- There are some open source tools but until recently they were unable to parse the latest language features used in LTE. I am convinced it is designed to be hard to parse to protect the encumbents.
- Unless you are using C/C++ (most tools generate these) you have to somehow generate FFI bindings, which you’ll want to automate for a large spec which requires parsing the spec...