Re: [Drip] Comment on -arch-22

[Jens Finkhaeuser <[e-mail]>]

Hi,

there is some conflict between the aviation world and the Internet world, and since they meet in UAS, that's where the conflict happens.

------- Original Message -------

On Thursday, March 24th, 2022 at 13:05, Robert Moskowitz <[e-mail]> wrote:

> Handoff among different links (and different link technologies) is something we are trying to address. In our own test flights, for C2 (not UAS RID), we have used HIP, MP-TCP and other protocols to fail over transparently

Yes, we essentially replicate MP-TCP components but for strictly datagram/packet oriented "links" (terminology is a mess here with respect to ISO/OSI but it seemed the best compromise). This is borne out of issues with MP-TCP we've had in practice in border regions and completely unrelated to drones.

The protocol we've built here is a (set of) state machine(s) that observe/manage unidirectional flows and consider a multi-link established if at least one unidirectional flow in either direction is active. I suppose it's a generalized form of MP-TCP's behaviour. Data is encapsulated and sent over the highest priority egress flow.

In practice, we've mostly used UDP/IP uniflows that then come in pairs, so the protocol is a little overgeneralized for this case. However, it allows us to use different send and return channels.

I've written a draft paper about this, but it never got all that far due to other work items gaining priority. If there's an interest in this in the IETF, I wouldn't quite know which WG or when to carve out time to convert this to an IETF appropriate form. Plus, my employer would have to agree.

Not that this is the main topic here.

> Bob Moskowitz and I would appreciate any inputs/help we can get on leveraging DRIP (focused on UAS RID) to facilitate robust identity-oriented V2I communications for C2, DAA, etc. :-)

Well, when I mentioned this aviation - network "conflict" above, we've noted during our cooperation that the transparent failover is not something that sits all too well with the aviation world. They're very much in favour of higher level functions being in control of the failover. That's something we can address, but detracts a little from the simplicity of a plugin-in, multi-link technology. Live and learn.

More to the point: I think the identifier/locator split you're proposing as well as the specific formats for each are just fine, for what it's worth, but my initial caveat that I haven't had all that much time yet for review still stands.

First point last: I think the majority of BVLOS scenarios do assume Internet connectivity. Strictly speaking that's not true, but it is in practical terms.

EASA consideres different categories of drones; we tend to focus on the "specific" category, which has weight/range/lift characteristics suitable for commercial or emergency delivery missions. Because of the commercial application, there's a strong desire to have low cost - both in hardware and operations - which must be balanced against the safety needs of the regulators.

So any connectivity options are essentially based on off the shelf offerings, which also means from a reliability/security perspective they're treated as black channel. But for the purposes here, within size, weight and power limits, it's easier to cram more of them into a drone and get reliability from a software layer above than to invest into different radio technology.

So in practical terms, most commercial mission profiles will be able to rely on 3GPP availability (maybe failing over to Wifi), which means Internet access. That much is very true.

But a variety of commercial or emergency applications are very explicitly about remote or inaccessible areas. One scenario we're discussing revolves around a rescue situation within a burning chemical factory. You send in a robot on wheels and a swarm of drones to map the area. The robot will most certainly act as radio base station for the drones, and it may also act as a limited ground control station - especially when it's own link to the outside of the building is interrupted. Even if that link is stable, a mobile ground control station placed outside of the building in a van may not provide Internet access in all areas. Identification becomes necessary whenever the drone loses and regains connectivity to its GCS, whichever that is.

The good news here is that this doesn't necessarily need to fit into U-SPACE's network identification needs. It may be enough for U-SPACE to cordon off the entire area because of the emergency situation, and let identification become an entirely local concern. But the same drone may need to report to U-SPACE in the next mission, so building distinct and incompatible identification systems does not seem sensible.

I really do need to read the DRIP drafts in much more depth... I saw the "last call" and did a bit of a panic review. I'll be able to get to that... maybe next week? I'll let you know.

Jens