[aprssig] APRS protocol replacement ideas: protobuf

[Andrew Pavlin]

 Remember that one important key factor of APRS is _efficiency_! Due to the FCC limits on symbol rates in the various bands (plus the issues in connecting higher baud rate data modems to a radio without a direct discriminator tap), trying to share a channel requires short packets. That was one of the reasons for Mic-E: to have the packet take as few bits as absolutely possible while still complying with AX.25 and still sending something useful. Mic-E actually sends more useful payload data per packet than the JT protocols! That saves air time, and reduces collisions that lower the available bandwidth. If we start using a more verbose protocol, then we have longer packets, and more likelihood of a single bit error that makes the whole thing useless. We could go to FX.25 (or another FEC protocol that gains more efficiency by losing backwards compatibility with AX.25) so we can recover from single bit errors (and possibly two), but that makes our packets even longer with the redundancy, and doesn't make them any more intelligible when a collision occurs.
I'm working on another project actually using PSK1000R and Google Protocol Buffers, and with all the subframe overhead for allowing some subframes to get through in interference, plus station identifications, I can get a maximum payload of useful data of only about 1800 bytes (after compression) in a 30-second superframe (and this was for a protocol design assuming only two stations in handshake for file transfer, like fldigi/flamp, so I didn't have to worry so much about collisions or hidden transmitters). So, don't look at protobufs as a savior. If anything, it will allow the packets to grow rapidly with extra optional fields, so that the channel is clogged faster with longer transmissions and more collisions. And protobufs isn't self-describing at the wire level, any more than APRS or OpenTRAC is. So we'd have to be very stringent about what new fields could be added into each hierarchy level of a protobufs-based protocol (like Scott was with OpenTRAC).

So don't go for a potentially fatter protocol unless we can get the bandwidth to use it effectively (like everyone going to 9600 baud). And WB2OSZ already wrote up an excellent whitepaper on why 9600 baud is really only effectively twice as fast as 1200 baud, given our shared channel situation.
Andrew, KA2DDO

    On Saturday, February 12, 2022, 12:40:16 PM EST, Scott Howard <showard at nd.edu> wrote:  
 
 On Sat, Feb 12, 2022 at 3:04 AM Heikki Hannikainen <hessu at hes.iki.fi> wrote:
>
> On Fri, 11 Feb 2022, Weston Bustraan wrote:
>
> > I can say that it was not easy to navigate the many exceptions and and
> > oddities in the APRS 1.0.1 spec when implementing a parser, and OpenTRAC
> > seems much more consistent, but the OpenTRAC spec does not seem to be
> > fully complete. For example, I would expect that any new protocol that
> > would supplant APRS would be supporting a UTF-8 character set instead of
> > just ASCII.
>
> Yes! Implementing all variations and details of APRS is quite difficult
> indeed, as there are so many completely different position formats, and
> various quirks in which order extension fields should be decoded in, and
> the specifications do not detail all of those. It is unnecessarily complex
> and an awful lot of work.

protobuffs sounds great, and I think both you and Weston hit on one of
the key points to the future of APRS. I think that whatever protocols
come up next, the priority should be on extensibility so that things
like protobuffs could be used. I think getting away from ASCII towards
binary buffers (UTF-8) would be a way to achieve what Mic-E does
without leaking between protocol layers (allow for more efficient
payloads without hacking DEST), but that would need some kind of
extensible spec. For "official" data types, the schema is published
and well known (maintained in some document somewhere). For
new/experimental extensions, maybe have one packet send out the schema
and the second the payload (kind of like telemetry does). It can use
protobuffs or just our own protobuffs-lite.

Since much of the new applications of APRS is in embedded systems,
computer modems, and web applications, new protocols can be
implemented and adopted faster than they can be approved by some
centralized body (e.g., if some arduino library compatible with
aprs.fi and direwolf implements something, it'll go live immediately).
I think that would be amazing, and the type of innovation we want to
see. Therefore, some standard as to how that can be done might be
better than trying to formalize every use case or application.

(Of course, APRS has to support the legacy applications and protocols.)

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20220212/50cf7b09/attachment.html>