> Jfyi: GSMTAP already has a provision for carrying raw burst bits. This was
> used early on in its history. Just look at the header file and look at all
> the constants that are named BURST in there.
My latest experience with gsmtap to carry burst data wasn't very good.
(when working on passive listening with calypso).
Some of the problems I encountered:
- No support for different data format
(soft/hard bits, with/without the TSC)
- sub_type field is re-used for the type of burst. But then you can't
set to what type of channel/subchannel this burst came from
(SDCCH/TCH/...)
- Can't give the number of the burst (0,1,2,3), so you have to
guess/reconstruct it
I think it maybe time for a gsmtap v3 ...
Something more flexible
I was thinking something with:
[header]
[opt header 0]
..
[opt header n-1]
[payload]
with:
- header having a direct offset pointer to data
- Then each header having a pointer to the next header
This way you could have
- Data Format header
- Cipher parameter header
- Physical channel description header
- Logical channel description header
- ...
And we could add new meta data information without having to rewrite
each tool each time. Sure the generation / parsing would be slighly
more complex than now.
But I think that with appropriate helpers in libosmocore, that
wouldn't be an issue.
Writing precise/defined spec on the wiki would also be a requirement
because some fields are rather obscure right now ... (format of snr /
signal_dbm ?).
If there is interest in such a new format, I can start drafting some specs.
Cheers,
Sylvain
_______________________________________________
A51 mailing list
[email protected]
http://lists.lists.reflextor.com/cgi-bin/mailman/listinfo/a51
