Re: [Drip] Comment on -arch-22

[Robert Moskowitz <[e-mail]>]

Again, no real time to review and comment in depth, but I am active in 
ICAO and the GRAIN work where aviation and internet are intersecting.  
Big time.  :)

I will only be able to be in the first part of cfrg and then off to the 
dentist.  Yet again.  Sigh.  I hope to be able to function this 
afternoon here.  But Med wants me cracking on the next ver of drip-rid.  ;)

On 3/24/22 08:59, Jens Finkhaeuser wrote:
> 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
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[e-mail]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit