[Ground-station] Adapting M17 Protocol to Phase 4 Opulent Voice uplink

[Michelle Thompson]

Greetings all!

Here's an update on the uplink.

Paul KB5MU writes "We’ve concluded that there’s no good reason to keep the
code puncturing from M17. As best we can tell, they used puncturing in
order to fit their 3200 bit per second voice codec into a conservative 9
kHz channel width. We are aiming at a wider channel that has no existing
channelization to be compatible with, and we could use the better
performance of an unpunctured code. If you see a flaw in this reasoning,
speak now to save the puncturing.

There’s also a design decision to be made on the uplink interleaver. M17
uses a particular quadratic polynomial interleaver. I’m not sure I
understand why."

For those curious about puncturing, it’s used in a variety of ways.

What is puncturing in the first place? It’s either deliberately not sending
a symbol (the smallest unit of information in digital RF signals. A symbol
stands for some number of bits of data) or it is the practice of replacing
a symbol with some other data to make a sub-channel.

An example of using puncturing to put in other data is in IS-95, where ever
so often, power control commands (up or down) were inserted into the
transmitted signal by overwriting a symbol.

This achieved power control, which is one way to make CDMA much more
efficient.

When you have puncturing with convolutional coding, it’s almost always used
to manipulate the code rate. The code rate is the ratio between the data in
to the convolutional encoder and the data coming out of the encoder, which
is then sent over the air after the data is mapped to symbols.

For the convolutional encoder used in M17, it’s 1 bit in and 2 bits out,
for a code rate of 1/2. If you puncture, or remove a symbol ever so often,
then the resulting signal transmitted over the air has a higher code rate.
This means you get a higher data rate - the number on the top of the
fractional code rate valule.

M17 has 2/3 code rate (0.666) instead of 1.2 (0.5) because of puncturing.

We know that to get something in physics or engineering you have to give up
something. That is true here as well. Higher code rates mean worse
performance at lower signal to noise ratios.Since VHF/UHF ham comms are
almost always done at high power, it doesn’t matter much. The vast majority
of M17 communications is done with internet links and reflectors, where
puncturing is not a factor. Repeaters are generally deployed in a way where
the hit to performance from puncturing is not anywhere close to the top
item of concern. Anyone accustomed to analog repeaters will notice a
performance difference in an M17 repeater, as analog gracefully
deteriorates while M17 will fall off a cliff a bit earlier with puncturing
than without it.

The primary purpose of puncturing in this protocol is to reduce the number
of bits down to the frame size required by the use of CODEC2 3200 bps
frames.

M17 is completely devoted to CODEC2 3200 codec. Everything in the protocol
is hard-coded to that particular codec.

Since we do not have to use such a low-rate codec, and definitely do not
want to use such a low rate codec due to the voice quality, we have to
rewrite the protocol. M17 is forced to because of datarate limitations for
VHF/UHF.

We use a minimum of 16 kpbs OPUS. We don't have the same regulatory limits
for microwave communications. As a side effect of this work, we will be
demonstrating terrestrial microwave HTs.

The interleaver is another story. There’s no multipath at VHF/UHF in the
same sense that we have for broadband microwave. Interleaving is required
to make a convolutional coding system work to its best ability. Multipath
is the source of most burst errors. Burst errors are what interleavers, in
general, are used to resolve.

The way we’ve seen this described is that convolutional encoders are
designed for memoryless channels. Multipath introduces errors with memory.

Rearranging the bits to give space between errors (scrambling or
interleaving) turns a channel with memory into the memoryless channel that
convolutional encoders really want.

Since there are no significant burst errors for a 9kHz signal at VHF/UHF,
the interleaver doesn’t have much to do. Except one thing - provide an
excellent opportunity for education. The greatest value of M17 is quite
possibly as a protocol that is easy to use over the air in educational
settings. It has block coding, convolutional coding, puncturing, and
interleaving. While the vast majority of M17 is lifted from P25 (like all
the ham digital voice modes) it does simplify things compared to DMR.

The downside to using an interleaver is delay.

You also have to have storage.

You want to guarantee that X symbols are separated by at least Y symbols,
then you do have to buffer things up or at least hold certain symbols for
their spot in a shift register with a commutator.

While there is not a whole lot of burst error problems at VHF/UHF, there
are definitely multipath issues for microwave broadband terrestrial
applications.

So yes, I think we will need an interleaver for Opulent Voice. But, do we
need the one that M17 selected? Quadratic Permutation Polynomials are used
in a variety of places, like LTE, for turbo codes.

We need to look at this QPP and figure out whether it’s overkill or not for
what is actually encountered on microwave bands.

The basic idea from QPP is there’s a linear term that distorts the symbol
stream, and then a quadratic term that provides finer “ripples”.

The classic way of doing interleaving is lining all the symbols up in a
matrix and re-distributing rows and columns. You pick how many symbols in a
row you want to guarantee separation, and how far apart those symbols must
at a minimum now be.

We can afford quite a bit of hardware here, but the real question is how
much latency.

Comments and questions are welcomed and encouraged.

-Michelle Thompson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openresearch.institute/pipermail/ground-station-openresearch.institute/attachments/20220702/d8f80dcc/attachment.html>