Video of Working Meeting on Higher Bitrate M17
Specification of M17:
P4DX architecture document:
https://github.com/phase4ground/docum…
M17 is P4DX native digital uplink protocol.
There are at least three use cases of M17.
One, 9600 bps voice for VHF/UHF.
Two, the idea of 9600 bps data or packet mode, also VHF/UHF.
Three, higher bitrate mode for microwave.
There is a data type specifier in the current specification. Reserved protocol types are RAW, AX.25, APRS, 6LoWPAN, IPv4, SMS, and Winlink.
What we’re talking about today is what, if anything, needs to be added to the specification in order to enable high bitrate operation for microwave, and also to figure out if anything needs to be done for IP over M17 or M17 over IP.
From Slack:
Ron
What needs to be defined is how to do IP over M17. In the M17 specification, there’s a protocol identifier for IPv4, but that’s it.
And here is a review of the conversation from 2021. This was the starting point for the conversation in this video recording.
Ron
M17 supports IPv4, but I’m not exactly sure how. The M17 specification seems pretty vague on that particular point
Howie
Assume we consider M17 stream mode operating in an FDM manner with a receiver for each uplink channel. Each channel can be given a GSE label that could map to an uplink center freq. The 4FSK modulated data is demodulated but not decoded. Instead, the data streams are clocked into individual buffers and used to generate the GRE frames. The idea is to keep the M17 frames intact so that on the ground earth station the demodulated data is identical to the uplinked frame which can be processed by the existing M17 decoder software. You listen to a channel by selecting the label for the stream you want to listen to. The limiting factor becomes how fast you can assemble the uplink channels into GRE frames.
I don’t think there is any need or desire to use anything other than native M17 on the uplink. While GSE is normally used for IP transport I think we could put the M17 frames into the GSE data field. At that point the only overhead is on the downlink with the addition of the GSE headers and LSF management. I have not looked closely at the sizes of the required fields are or how much processing it would take to multiplex multiple uplink streams into a composite downlink. At this point I am just brainstorming.
Anshul
looks like we don’t need IP as an intermediate step. I agree with @ab2s that there is no need to use anything other than native M17 on the uplink. GSE should encapsulate M17 frames and produce BBFRAME as it normally does for IP packet.
It implies we will be not using any IP stream/packets on uplink. Everything uplink will be M17 based.
Do you see any concerns here . Else, I will proceed with implementation of GSE block in firmware keeping this decision in mind.
Consensus on:
- Validity of use case for higher bitrate M17 for P4DX uplink.
- IP over M17 could use an example (as could all the types in this field), but the type field indicating IPv4 is sufficient for carrying IPv4 within M17. M17 packet is small enough to where IP fragmentation will probably occur.
- M17 over IP is defined in the appendix, it works as implemented in the reflector network, and did not appear to need any additional work.
- P4DX could provide a spigot of M17 uplinks over IP, using the protocol in the appendix, as a Groundsat feature. This would not affect the air interface.
- We discussed the XOR with random data aspect (covert SPARROW channel here? Yes/maybe if there’s a known message)
- Discussed asking for a P4 Type Field Indicator. Smart receivers won’t need this, but it would allow people to move between 9600 bps M17 and higher bitrate M17.