Re: [PANRG] Question regarding multi-link work

[Jens Finkhaeuser <[e-mail]>]

Hi all,
thank you for the feedback.

I'll take that as an "invitation" (not that it's needed, strictly speaking) to convert the paper to draft form, so we can have a conversation about it. There is currently no public link available; this would make one available.

> 

> And, surprising literally no one, I'm interested in learning more about your thoughts.


I have provided more context elsewhere, and should contribute some of that to a draft started by others on identifier vs. locator semantics for addressing... so this is the short version for now.

"Drone" is a pretty vague concept ranging from military drones to toys; under EU legislation, the "specific" category sits somewhere in the middle and offers commercial opportunities. There are many use-cases envisioned, but the highlights are:

1.  Starting and landing often involve control handover between control stations as well as radio link handover between e.g. satellite and ground based radios.
2.  Drones can be fixed wing or multicopter; fixed wing can land at over 100km/h, which requires radio with low latency and high range - and still handover protocols should require few roundtrips to not stress those margins too much.
3.  The use-cases can be BVLOS (Beyond Visual Line of Sight) or RPAS (Remote Pilot Assisted). The latter means transferring camera and control data, which requires high bandwidth in addition to the low latency. It also implies that some data (e.g. camera) can be transported more lossy than others (e.g. control).
4.  Anything that flies over people's heads needs failover, some regulations require distinct radio technologies for this.
5.  Anything that's supposed to deliver a pizza must be cheap; for that reason, targetting COTS (commercial off the shelf) radio hardware and systems built on top of it is sensible. Another point in that favour are SWaP (Size, Weight and Power) considerations; you essentially want flying mobile phones to facilitate communications and little more.


>From the above, it basically follows that the best starting point is to build on IP (because COTS hardware ends up supporting it), to aim at a lightweight tunnel (so no TCP) to support lossy and lossless semantics.
In addition to the visual line of sight considerations, there are also radio line of sight considerations, so communication endpoints should have relatively aggressive control over their local interpretation of whether a link supports comms or does not - by which I mean that each endpoint should be able to make quick decisions on its own whether it considers each path/link to the other endpoint viable.

It took some swirling around to arrive at the point that maybe the best view then is to consider the set of ingress and egress links, and consider the overall thing established if there's at least one of either. That makes for a relatively good separation into per-link ingress and egress and an overall connection state machine (of course, events from one feed into the other).

Between this and a full protocol for everyday use there's a bit of a gap, in particular with how identification interacts with this. For that purpose I've been poking around in tm-rid@ .

The architecture going with it has similarity to MP-TCP or others; there is a scheduling component that makes real-time decisions on which packet to send over which egress, and a management component that for detecting new links or disturbances that state machines may catch too late (radio degradation), which then feeds that in terms of simple priorities to the scheduler.

Personally, I think that the drone problem space is just demanding enough that it's worth capturing the resulting requirements; a fair few protocols I see under discussion on various lists have less stringent views. Second, I think that the abstract state machines make for a good discussion basis, because they represent a model of thinking about these requirements that is somewhat independent of any specific protocol.

In terms of a concrete protocol, we have one that's sufficient for R&D and would actually work somewhat in production. But it has gaps (see above). I'm working on something complementary in parallel, and hope to combine them in the future. That is something I would really like to write a draft for, when that time comes.

Hope that helps (for now)!

Jens