Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
M17 frame description
#11
AES will probably be used in CTR mode, so we would need a frame number too. We need it, so the AES counter value is kept synchronized within all recipients. I have reserved 12 bits (if I remember correctly) for that purpose. 4096*40msec is the longest TX period you can have atm, about 163 seconds.
Reply
#12
(11-30-2019, 11:15 PM)KE0WVA link Wrote: The FCC in the US has its own laws, cryptography in amateur radio is definitely illegal here.

Yep, obfuscation of any kind is illegal in the US, but that doesn't mean we shouldn't support it in the protocol, so long as we also support a null cipher.  We CAN include authentication and message verification and stay within the US laws, though.  It just requires that the payload be in clear text.

(12-01-2019, 02:37 PM)SP5WWP link Wrote: AES will probably be used in CTR mode, so we would need a frame number too. We need it, so the AES counter value is kept synchronized within all recipients. I have reserved 12 bits (if I remember correctly) for that purpose. 4096*40msec is the longest TX period you can have atm, about 163 seconds.
I agree with KE0WVA that we should look into different frame types for call setup and payloads.  You don't need to send the nonce, key_id, or cipher type with every packet, for example.  Just set all that up once, maybe establish a session_id to identify all those parameters (hash of all cipher parameters, maybe with sender and recipient IDs too?), then only include the block counter in every message. 

I do like CTR mode, though, as opposed to a chained mode like CBC.  Means that if you drop a packet, you can pick up the later packets and don't lose the entire session.
73 de KR6ZY
-Mark
Reply
#13
OK, I finally got some spare time.

Quote:I propose using 48 bits for each, the sender and receiver.  With 48 bits, you can encode 9 characters in a 40 character alphabet.
Well, that's a good idea. The encoded callsign could be stored in the codeplug (on an SD card).

Quote:doubling the header space used by source and destination IDs, but you've got 80 bits of "RESERVED" space in the current header.  Not sure if you already had plans for that or not.
Don't worry about it, we are going to rearrange the frame contents anyway.

Quote:The big issue I see with this frame format is that 128 bits of payload in an 808 bit frame is incredibly inefficient.
Yep, we definetly have to change that.

Quote:Frames are 128 bits / 64 symbols / 40ms long. 25 frames/sec
AUDIO: 52 bits audio payload, 52 bits rate 1/2 error correcting code
Quote:does key information need to be included in every frame or can there just be an "encryption setup" type frame at the beginning of transmission?
How would you send sync info like the frame number? An the nonce value? You have to transmit that info regularly throughout the transmission. AFAIK, it's needed for AES in CTR mode. Would you just add that to the frame? Post #5 explains it well - the setup has to be sent periodically (but not necessarily in every frame like it happens at the moment).

Quote:Frame type field of the header format should have at least, say, 4 bits.
Yeah, that leaves some unused bits for future use.

Quote:You don't need to send the nonce, key_id, or cipher type with every packet, for example.  Just set all that up once, maybe establish a session_id to identify all those parameters (hash of all cipher parameters, maybe with sender and recipient IDs too?), then only include the block counter in every message.
We should draw a flowchart for that. Maybe UML or SDL, even? Well... we should describe everything using some kind of description language anyway.
Reply
#14
For my own experiments (linking repeaters, including those using freedv) I created a 48 bit encoding for callsigns that is also ethernet compatible. See http://dmlinking.net/eth_ar.html.
It is already in use for some repeaters around the Eindhoven area.

Another thing I would like to suggest is to use an frame type identifier of 16 bit and use it to identify different protocols.
The current 3k2 codec2 sound okish, but if David comes up with a better mode based on his low bitrate work we might want to be able to switch to a different 3k2 mode without having to redo the protocol and switch automatically.

And finally I would like to suggest the to have a look at the data channel code I wrote for freedv, it allows interleaving data between voice packets (e.g. when no audio is detected) and on a high level provides ethernet frames which allows you to use basically any existing protocol on it.
Reply
#15
I'd like to sum up all suggestions for the frame types. Encoding callsigns on 48 bits sounds great, code provided by Mark works nice.

I see one problem. Imagine that 2 users are making an encrypted QSO. Ok, VOICE frames are being transmitted every 40 msec. What should happen, if someone else (knowing the key) starts to listen? Where should we put ENCRYPTION_SYNC frame? There's no space between VOICE frames. Also, we can't remove 1 voice subframe (20ms of encoded voice) and just place the encryption sync there - the other half would have to be transmitted in plaintext.* Am I correct?

*EDIT:
There will be no voice subframes in CODEC2_MODE_1300 (1300bps). The vocoder takes 320 samples as the input, not 160.
Reply
#16
IIRC, in the US, you're allowed to encrypt data as long as the key(s) are public. So it would be okay to test out the encryption as long the key is made public somewhere.

You're also allowed to cryptographically sign data, since that isn't obscuring anything.

-Dan Fay
Reply
#17
I have edited my first post in this thread. Take a look at the PDF linked there.

(12-02-2019, 11:20 AM)pe1rxq link Wrote: Another thing I would like to suggest is to use an frame type identifier of 16 bit and use it to identify different protocols.

16 bits is a lot. Why 16?
Reply
#18
(12-03-2019, 11:24 AM)SP5WWP link Wrote: I see one problem. Imagine that 2 users are making an encrypted QSO. Ok, VOICE frames are being transmitted every 40 msec. What should happen, if someone else (knowing the key) starts to listen? Where should we put ENCRYPTION_SYNC frame? There's no space between VOICE frames. Also, we can't remove 1 voice subframe (20ms of encoded voice) and just place the encryption sync there - the other half would have to be transmitted in plaintext.* Am I correct?

I suppose the trick, then, is to increase symbol rate just enough to open up gaps that you can use to transmit a header frame.

40ms of audio per frame = 25 frames per second. Increase symbol rate by 20% to make it 30 frames per second, now for every 5 frames of audio you can slip in one frame of header, metadata, encryption setup, etc. Send your encryption setup frame once per second, and somebody just tuning in will miss at most one second of audio.

Sender and receiver will both need to maintain, at minimum, a 40ms buffer of audio to cross those gaps. Total codec delay in audio transmission will be a minimum of 160 ms. I think this is acceptable.

So let's say a symbol rate of 4.8 kbaud, for 9.6 kbits/sec throughput. That's 160 symbols/320 bits per frame. That gives us 128 bits of payload, 128 bits ECC, 64 bits sync and header. That's 3.84 kbits/sec of goodput, 3.2kbits of which is audio, leaving 640 bits/sec for metadata and encryption setup. I think that's pretty reasonable.
Reply
#19
This conversation seems to be taking the protocol in two different directions.  We (read: SP5WWP since this is their baby) need to decide whether M17 is:

1) A minimalist streaming protocol for digital voice, like FreeDV which has a 95% efficiency (1375bps CODEC data in 1450bps over-the-air bitrate: https://freedv.org/freedv-specification/), but with the addition of some features like FEC.

2) A full, layered, packet switched network protocol that can carry nearly any arbitrary data payload.  This is closer to Ethernet/IP, with all the over-head that goes along with that.  Great with large payloads, horrible with lots of small packets.

It feels like SP5WWP's original frame description was an attempt at #1, but with a lot of overhead from #2.  Every packet was the same format, and everything needed to understand a given packet is encoded in that packet.  This makes it very tolerant of lost data, but very inefficient of on-the-air bits.

The conversation here seems like we're headed toward #2.  We can design a very functional protocol for #2, but it will likely be a lot less efficient than #1.  If #1 was SP5WWP's original goal, then I want to make sure it's a conscious decision to work on #2, not a design-by-committee scope-creep decision.
73 de KR6ZY
-Mark
Reply
#20
A little light reading: https://www.etsi.org/deliver/etsi_ts/102...10405p.pdf  DMR Specification.  I'm not trying to recreate DMR, but I'll bet they've done a lot of thinking about these particular problems too.  Let's see what we can learn from their hard work, then adjust things to optimize the M17 for our particular use case.
73 de KR6ZY
-Mark
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)