[HLL] Frames again...

[xorrox@gmx.net (Volker Ernst)]

Status: RO
Content-Length: 3820
Lines: 115

-----BEGIN PGP SIGNED MESSAGE-----

Hi,


here is a "layered approach" to define our data-format.

It mainly repeats the "quick and dirty" proposal,
but seperates things into several "layers" to make life easy.


LEVEL 0
- -------

This level must provide a way to send and receive frames.

How this is done depends very much on the media used.
A frame is a collection of data-bytes (min/usually 34 bytes,
but can be more). No assumptions about the meaning/contens
of the data being transported are made other than:
* Data being transported must be random noise
  (This is usually true because data is crypted.)  <-- NOTE_1

A method to accomplish this task over async serial lines
has been proposed earlier. This includes adding the 0x42,
leaving 1 Byte of extra-space and methods for the rx to sync.

Additional methods to transport our packets via synchron-links
or packet-switching-networks may be specified later.


LEVEL 1
- -------

This level takes care about splitting/assembling our frames.
It knows about several possible ways to use frame-bandwidth.

So it mainly interprets the 4 mode-bits and splits frames accordingly.
Our frames might be structures as described in the "quick and dirty"
proposal earlier. Fields should be in this sequence:
*   4 Bits coding operation-mode "mode-bits"
* 260 Bits coding used as "G-channel" (13000 Baud @ 20mSec/Frame)
*   8 Bits coding used as "X-channel" (  400 Baud @ 20mSec/Frame)
This makes up a minimum frame of 34 bytes.
If frames are longer, any extra bytes belong to the "X-channel".

Now the mode-bits encode the usage of frame-fields.
There are 5 basic operation-modes:
0 - "Null"-Mode, 
    G+X-channel ignored, used for sync-purposes and dummy
1 - <reserved>
2 - "Silence/Command"-Mode
    G+X-channel are combined, data is stream-based
    and belongs to the "command/status"-link used for handshake (Level 2)
3 - "Silence/UserData"-Mode
    G+X-channel are combined, data is stream-based
    and belongs to the "transparent user-data-channel"
4 - "Talking/Command"-Mode
    G-channel is block-based and carries gsm-frames
    X-channel is stream-based "command/status"-link (Level 2)
5 - "Talking/UserData"-Mode
    G-channel is block-based and carries gsm-frames
    X-channel is stream-based "user-data-channel"

So what this level will output (if decoding rx-frames) will be:
* Gsm-blocks of 260-bits
* Stream-based "command/status"-link
* Stream-based "user-data-channel"-link
Gsm-block-handling is already specified and will not be mentioned here.
Command/status-link is a character-stream and given to "Level 2" below.
User-data-channel is a character-stream provided to the user via rs232-i/o.


LEVEL 2
- -------

This level describes how commands are passed via the
stream-based "command/status"-link described above.

It should define rules how to
* identify the start and len of messages
* how to verify that a received message is ok (crc)
* what handshake-messages to send if you want
  to send a command to the other side.
  This includes the format of reply-messages.

[Sorry - but specifying the details still has to be done...]


LEVEL 3
- -------

This level should specify the meaning of individual messages,
as well as high-level-flow-control for message-exchange.

Maybe we can be very close to the "VP1" on this level !

[Sorry - but specifying the details still has to be done...]


COMMENTS REQUESTET !


Volker

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1

iQCVAgUBNLOBi0iof7Gu0VvJAQH6eQP+M6JUJWcbDQrAYDBmL4R5OZjpELhYd0m7
vF777CO55vsBryl9nRehI4YfzKQ6yAI11RYyUS7OrbpiytOTilnQru2DvhXhoTBS
3bIEMIbPVd47vHesY/VHmTkWFkHSDJwnSg0pCR/LKK4FsFhexvzJCZEVBqie95l+
deTdQKHVfE8=
=gdRo
-----END PGP SIGNATURE-----