LICH Enhancements

I have two proposals for the LICH.

1. Split the superframe into more segments

The current superframe (link setup frame) is split into 5 chunks of 48 bits (240 bits total). I propose splitting this into 6 chunks of 40 bits each. Use the first 8 bits in the LICH as an “info field” containing 3 bits for a superframe segment counter (0…5), and 5 bits in each frame for other uses.

2. Send the superframe less frequently

The current LICH is defined as sending the superframe back-to-back, 5 times a second (or about 4 per second for the previous proposal). M17 transmits 25 frames per second. We could send the superframe once or twice per second instead. This would increase the time required to for receivers to sync with a channel. But it would also provide a side channel for additional information, such as location information (APRS-like data), personal avatars, or many other uses. The LICH is a 1200bps side channel (48 bits per frame, 25 frames per second = 1200bps). By sending the superframe twice per second, we have about 600bps available. By sending the superframe once per second we have a 900bps.

Combining these two ideas, we can use the 5 bits to encode 32 different types of information being sent (text message, location, status text, public key, avatar, etc). Or we can just indicate that it is “data” and require the data format include a data type descriptor. The type of data to be allowed in the LICH is outside the scope of this proposal.

If nothing needs to be sent, then the superframe can be be sent. Or, one can think of this as allowing the superframe to be interrupted 2-3 times per second for additional data.

An argument against the second approach is that this data could be sent by switching to D/V mode. If that approach is taken, it might be useful to be able to switch between 3200bps Voice and 1600/1600bps Data/Voice modes seamlessly during a transmission. DMR uses different sync words for this. But it also uses a longer sync word.

If we went with the second option, any receiver looking for the superframe would look at the new “info” field and start decoding when it indicates a superframe. It would collect all 6 segments and assemble the superframe. If the info field indicates something else being sent, it could watch for that or ignore it.

I like this idea.

I have also raised the need to:

  1. Add some sort of selective transmission code, similar to CTCSS so multiple M17 repeaters don’t open up from one transmission.

  2. The bits that determine whether the transmission is voice, data, or voice and data are fine as they are. However there is an intrinsic link between that and the voice mode. I think this should be broken. My reasoning is that Codec2 is a dynamic development, and newer (i.e. better) and incompatible voice modes will come along. As it stands, it is not possible to include these without problems. Therefore would it not be better to add some bits to indicate the voice mode in use? This will allow expansion in the future, and older firmwares could ignore newer voice codecs which would not be decodable.

  3. I am still rather worried about the encryption side. Apart from taking valuable bits, it is not legal in many countries. It could also be abused and in a worst case scenario, could see M17 banned in some administrations. For a non-commercial DV mode, I don’t see a strong use case for it.

  4. Each LICH fragment should have its own checksum.

  5. With a new frame every 40ms, you don’t need to send a sync vector on every frame. You could send it every other frame, or even slower, and win 16-bits which could be used for other signaling. This is done in dPMR for example.

Jonathan G4KLX

  1. Have you read the spec? See table 4.5. Also:
  2. We can use one of the spare bits from the frame type field.
  3. If you don’t want it or it’s illegal - don’t use it.
  4. We can make the superframe 2 frames longer so we have 10 bits spare (assuming that 8 are already used for the LICH_CNT and something equivalent to Color Code).
  5. Right, that’s not bad. What kind of signalling? Any examples?

Regarding encryption, in the US there is an exception to the prohibition on the use of ciphers in amateur communications. Command and control signals for amateur satellites may be encrypted. It would be cool if M17 were used for this. I do have a real concern about the encryption part: I trust very few people to get it right – or that there are enough people with that expertise in the amateur community peer review every implementation.

I’d like to re-ignite the discussion on my proposal #2. Using a bit in the LICH to indicate alternate data – something like location data – in the LICH field, rather than the LSF. We would allow up to 6 consecutive frames to be used for alternate data, requiring that a full LSF be sent at least twice per second.

#1 is pretty much as you described, with a 4 bit Channel Access Number, leaving 1 last spare bit.
#2 - that last one bit can be used for just that. 0 for the LSF, 1 for DATA. If no data transfer is needed, we can set this to 0 until there’s a need for it.