1 Dec
2012
1 Dec
'12
6:12 p.m.
On Sat, 2012-12-01 at 14:48 +0100, Harald Welte wrote:
Hi Frank,
The current 'hack' allows for 128 concurrent channels, which can be
packed in 3.2 MHz of spectrum so it may or may not be enough. I think if
you need more it might be an idea to start packing the bits into bytes
and multiplex at the levels of strings of packed bytes. But that is a
bit theoretical, since tetra-rx will start to use considerable CPU time
before this limit is reached.
In the current code the bursts could very well be identified with arfcn
in the printed output also, especially if you wish to process the stdout
stream for further analysis.
My original plan with this was to analyze the CMCE messages with an eye
to perform traffic analysis, and I have added some code to
macpdu_decode_resource() to analyze the LLC PDU, but it didn't take me
long to realize that the TM-SDU is actually encrypted, something the
source code comment fails to mention :-) Wireshark has also been serving
me complete garbage because of this :-(
I could clean up the little code I have written here for a commit, but
it is a line of research that I can't continue for lack of unencrypted
data.
f
The easiest method is to use the high order bits
of the input as a
"stream id", and dynamically create new state structs as they appear in
the stream.
I'm not really sure if the high-order bits is the best way to go ahead
with this. How many 'high order' bits are there? Is it sufficient for
number of channels that one might receive, even in a massive parallel
receiver?