Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » The binary RAW encoder of Titan : part I(Basic principles)
The binary RAW encoder of Titan : part I [message #1710497] Wed, 07 October 2015 07:52
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member
Greetings,

We have seen in the previous posts that an ASN.1 protocol specification consists of two parts: an abstract syntax, which declares the structures used in messaging, and a transfer syntax, which describes how the above structures will be transferred over the wire in a binary form. For ASN.1 , standard binary codecs, such as BER or PER , the latter offering compression, can be used.

For TTCN-3 , we are facing exactly the same problem: the message structures can be comfortably described by the language;
on the other hand , the standard leaves the encoding/decoding of these structures to the latitude of implementors.

A large part of the protocols fall in the category of protocols with tabular description, meaning that the messages are represented in form of a table
( I'm sure each of you have seen at least one of these, IP being probably the most well known; RFCs abound with such tables). This table offers both a structural representation and encoding instructions. Now that we are here, let me add that this is probably not the best way to represent a protocol; in my opinion , formal schemas should be preferred whenever possible, as they leave less room to interpretation and ambiguities.
However, formal schemas are usually part of a more lengthy standardization process, which means less time to market, less flexibility etc. so we have to live with what we have been given.
Back to the tables: the structural part can be easily represented in TTCN-3, but what should we do with the encoding instructions?
In a first approach, these instructions can be embodied into external functions written in C++: if the function is called with a value of type MyType, the function will execute the steps needed to represent the value in binary form. An external function declaration in the TTCN-3 code will connect the abstract part and the transfer part.
Although technically correct, this solution suffers of two issues at least: first, a new codec has to be produced manually for each new type to be encoded.
Secondly, the structural and encoding instructions are disconnected: one has to look into the TTCN-3 code and the encoding function simultaneously to be able to trace the process for e.g. debugging purposes. Possible, but not convenient.

A lot more flexible solution, which Titan adopted, is to decorate the TTCN-3 structures with encoding instructions, which are compiled by Titan, thus generating codecs automatically.
As in the above case, an external function declaration to connect to the generated code is still needed, but that's all. Pure genius , isn't it?
Well, this is too rooted in ASN.1s ECN (Encoding control notation) , which also describes such a controllable encoder/decoder.

For example, the encoding instructions for an integer could look like this:

 {
  module MyModule
 
 type integer INT1
with {
  variant "COMP(signbit)";
  variant "FIELDLENGTH(8)"
} 


}
with { encode "RAW" } 


where FIELDLENGTH specifies the length of the encoded type in bits
and COMP specifies the type of encoding of negative values

so a value

const INT1 c_i := -1 


will be encoded as:

c_i: 10000001 '81'O


with a leading sign bit

The module containing the type declarations has to have an attribute 'encode "RAW"'.

As the structures and encoding instructions appear together, following the encoding is a lot easier. To permit Titan to distinguish between structural and encoding instructions, for the latter the standardized "variant <attribute>" mechanism is used. This also permits code portability: a different implementation than Titan can simply ignore these attributes.

Of course, if for any reason the built-in auto-generated codec is not sufficient, the possibility to write a custom one still exists, only the external function declaration has to be pointed towards the custom piece of code.

So the workflow of translating a tabular protocol into TTCN-3 of Titan is that first the structural info has to be coded into corresponding TTCN-3 structures; than this has to be decorated with appropriate encoding instructions, and finally the external function declaration has to be added.


Next , we will look into the possible attributes in detail. An extensive description of these can be found in the Titan reference guide.



Regards

Previous Topic:JSON in Titan IV, usage of IPL4 test port and extracting messages from a TCP stream
Next Topic:The binary RAW encoder of Titan : part II
Goto Forum:
  


Current Time: Tue Jun 15 20:37:15 GMT 2021

Powered by FUDForum. Page generated in 0.01666 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top