[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[HLL] Re: NEW Frames

Status: RO
Content-Length: 3100
Lines: 71



> >* To be able to sync on each frame-start, we start transmitting
> >  each frame with a fixed byte value. What about 0x42 ?
> >  This leaves us 34 bytes in the frame for further usage...
> >  (Operating crypto on 17 blocks of 2 bytes each).
> >  It's easy to detect the 0x42 in the encrypted data-stream,
> >  as it repeats every 35 bytes while everything else is random.
> >  (This assumption makes it impossible to use double-xor...)

> Hmmm.... What would be the point of the 0x42? The device can't see the
> difference between a ox42 that's frame=start or a randomly occuring
> 0x42. Unless we start excaping it of course. If there's an error in
> the transmission, sync easily might be lost as well.

Well, the idea is to use a "digital pll" to recover "frame clock".
This means that you watch data for several frames, before you
finally decide where frames start. Given that the rest of the data
is random, you will only see 0x42 repeating in 35-byte-distance on one
position. Once you are in sync, the system automatically resyncs if
sync should be lost, because it will adapt to the new sync position
the more easy the closer it is to the orginal one.
The algorithm for this digital pll is quite simple and short.

It is quite effective, you can even cope with trashed 0x42 etc.
Also it does not follow every "trash" on the line, because sync
is generated over several frames.

You could further enhance it by building a digital pll to recover
a virtual 50-Hz Gsm-Clock for output of gsm-frames, instead of
calculating the byte-count until the next sync-pos.
This takes into account that frames are transmitted every 20mSec.
So frame-starts will be 20mSec in distance, no matter what byte-count.
Would be even less sensitive to inserted/deleted bytes.

No need to escape anything, in either case.

> Why not use something with a variable length frame. This way you can
> use longer frames, and reduce the overhead, and thus put a slightly
> more explicit header on things.

On one hand you would have to find a way to sync on frame-start anyway.
On the other hand, you can easyly modify the above digital pll to lock
on variable frame-length. So you can automatically detect frame-length.

Given the facts that you will want to transmit frames every 20mSec,
their length is a function of the (fixed) baud rate. So there is no need
to change frame-length once connected at a certain baud-rate. 
So it should be enough to detect frame-len at connection-start using the pll.

> Also, how many bits/s does the GSM codec _need_?

If you want 8kHz sample-rate the compressed rate is 260 bits/20mSec.
This makes 13000 bits/sec. All those bits are used and necessary !


Version: 2.6.3i
Charset: latin1