Hi,
Since no one has replied to my previous very generic message, I come forward with a proposal hoping to trigger a discussion.
As you know, the current definition of the GSMTAP header has a version field that could enable new versions to be safely introduced. Unfortunately, Wireshark decoder does not check the value of the version field, it just presents the value in the decoded output. It seems that the only way to define a new GSMTAP version that does not break Wireshark decoder is to preserve the initial 16 header octets.
This is the current gsmtap_hdr definition. Some fields are only relevant in the context of a GSM capture, while the meaning of others (notably type, sub_type) has changed over time to describe a payload of a newer technology.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version | hdr_len | type | timeslot | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | arfcn | signal_dbm | snr_db | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | frame_number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub_type | antenna_nr | sub_slot | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When hdr_len is greater than 4 (the length is 4 * 4 = 16 octets), it is possible to store additional information in the header, without breaking any compliant decoder implementation. This new header section could contain a sequence of TLV entries with a 2 octet tag, a 2 octet length field, and a value field padded to the nearest 32 bit boundary.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | tag | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | value | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length field allows decoders to skip unknown tags. To improve storage performance, a subset of tags for values with a length less or equal to 2 octets can be defined (something like this was proposed in 2012 during the GSMTAPv3 session). Like this:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| tag | value (padded to 16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| tag | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | value | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this last variant, we have 32k tags for "small" values and 32k tags for full TLV entries.
Finally, an additional bit can be used to distinguish between official Osmocom tag definitions, and application specific tags, that are valid only within the boundaries of a specific implementation and could be used to embed metadata that has not yet been assigned an official tag.
What are your thoughts about this?
Mauro