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

[HLL] VP1 Comparison

Status: RO
Content-Length: 3059
Lines: 68



i had a quick look at the protokoll-specs for the "VP1"-Device.
Here is a short comparison:

* They operate their 14400-Modem is *synchronous* operation.
  This means, that they do not have the trouble of baud-rate
  variations between cpu/modem and no inserted/deleted bytes.
  Their assumption about the modem is, that once you are in
  sync, you will continue to get bits at 14400 all the time.
  These bits may be wrong (they use forward-error-correction),
  but you will not loose bits / get extra bits.

  This makes a big difference in low-level frame-layout.
  Because we use a asynchronous channel in between (to our modem),
  we do have the problem of baud-rate-variations.
  Because of this, we cannot make use of 100% bandwitdh.
  We will also have to handle the situation of missing/inserted data.
  Their synchronous communication gives them 14400 Bits all_the_time,
  while our modem might even deliver no data at all (in error-condition).
  This means that we might loose frame-sync due to com-errors,
  they might get wrong bits - but the bit-count (sync-pos) is always ok !

  These differences reflect in theier low-level-framing.
  They sync once - afterwards (ignoring crypto-handshake) they use 100%
  of avaiable bandwidth for gsm-frame-transmission.
  So they use 14400/50=288 Bits for each gsm-frame, expanding those 260
  gsm-bits to 288 (using a method not detailed in the paper, they say
  this point is currently changing). They don't use those extra-bits
  to transmit something like an "user channel" or to send commands
  once the connection is established and voice is exchanging.
  They would have to stop voice, if they want to send any other message.

  ! This format is probably incompatible with standard 14400-Modems !
  ! Modem-Software would have to be able to handle their low-levels !
  ! Won't work with a standard-14400 with async connector and a pc !!

* Crypto-Handshake and Messages look quite good and well-thought.
  It is also quite close to what we were thinking about.

- --> While the "major logic" of their device is close to ours,
    they will not be inter-operateable on modem-links.

    However they could support our modem-standard (but not the other way!).
    (They have close access to modem coding/decoding and could implement
    our standard - we are limited by standard modem-capabilities
    and limitations due to our asynchronous connection with the modem).

    Once we share a common low-level-link, high-levels seem quite the same.
    So we might use the same messages - even if we operate on different links.
    Any copyright-probs when we would do that ?


Version: 2.6.3i
Charset: latin1