Re: [ipwave] Question on actually using 11-OCB

[Robert Moskowitz <[e-mail]>]

Just a quick, partial, response.

On 7/27/23 06:13, Alexandre Petrescu wrote:
>
>
> Le 26/07/2023 à 16:33, Robert Moskowitz a écrit :
>> I am working with Uncrewed Aircraft System (UAS) manufacturers on
>> A2A direct communication for Detect And Avoid (DAA).
>
> Are these UAS featuring one or several OCB antennas and how are they
> pointed, up-down-horizontally?  It is one of the factors that tells how
> to make IP run on them.

The antennas are carefully positioned.  And the vendor I am currently 
working with has a firmware patch from the card vendor (this is one of 
the top-flight wifi cards that they can surface mount on their boards) 
to control which antenna is active.

>
> This DAA, as its name suggests, seems to be important; it has many
> similitudes in car-to-car and sat-to-sat collision avoidance.

Yes it does.  Civil aviation, via passive ADS-B, has been doing DAA 
before any others.  Well naval has a long history as well, but all 
analog until recently.  So there is a body of knowledge in aviation in 
what it takes to do 3D DAA.  But there are lots of arguements...

>
>> See my draft:
>>
>> https://datatracker.ietf.org/doc/draft-moskowitz-drip-a2x-adhoc-session/
>>
>>
>>
>>
>>  > One of the perferred radio links for this is IEEE 802.11-OCB, but
>> running over 2.4Ghz.  With channel 6 being mentioned the most.
>
> This (OCB at 2.4GHz) I am not sure it is possible.  Technically yes, but
> the reglementation - IIRC - seemed to be saying that OCB must be at
> 5.9GHz bands not long ago.  Not sure for now.

I think the regulation is the other way around.  That is 5.9 was 
originally allocated for OCB.  Not that OCB is only usable in 5.9. I was 
working on 11p back in those days.

>
> Or maybe these are new efforts.
>
> (channel 6 is _center_ at 2.4GHz bands, so mandating OCB there might
> disturb many people; I'd have expected to consider OCB maybe more at 1
> or at 12, but I dont have the whole picture.)

Most of this is in the air, away from ground use.  Some will be at 
warehouse landing pads or commercial "Vertiports".  Also studies show 
that most wifi use defaults to channel 1.  Only a few people set their 
channel to something else and a few have software to find "quiet" 
space.  For some reason channel 6 seems to be the least used.  I don't 
have the studies, but others have mentioned this in calls.

>
>> So the challenge at first is what does this take to do?
>>
>> Well I don't have 802.11-2020 but I do have 802.11p-2010.  It seems 
>> that all is needed is to set dot11OCBEnabled to true, and follow sec 
>> 11.19. No firmware hack needed as long as dot11OCBEnabled is available?
>
> I am not sure what is section 11.19, but indeed, it is sufficient to
> turn on OCB mode and there is no need of firmware hacks nowadays.

11.19 STAs communicating data frames outside the context of a BSS

When dot11OCBEnabled is true in a STA:

a)    Synchronization, authentication, association, and frame classes as 
defined in 11.1 and 11.3 are not
used. Data confidentiality as defined in Clause 8 is not used. The STA 
may send management frames
of subtype Action and, if the STA maintains a TSF Timer, subtype Timing 
Advertisement.

b)    The STA may send control frames, except those of subtype PS-Poll, 
CF-End, and CF-End + CF-Ack.

c)    The STA may send data frames of subtype Data, Null, QoS Data, and 
QoS Null.

d)    The STA shall set the BSSID field in all management and data 
frames to the wildcard BSSID value.

and on from there....


>
> There are however, details.
>
> Generally speaking, there are two kinds of OCB cards and their drivers
> on the market: the proprietary expensive with QoS and the cheap open
> source without QoS features in .11 headers.  These cards are
> interoperable somehow, meaning that they understand each other, but they
> dont ensure QoS when mixed.

At least this one is a hig-end wifi company.  Surface mount.  You avoid 
any connection that could loosen from vibrations, as there LOTS of 
vibrations!

And that is it for now.

>
> For the fw hacks: it might be that firmware hacks might be needed for
> the cheap non-QoS OCB cards such as to become QoS aware OCB; this can be
> checked; it was not the case a while back; more years ago it was the
> case that for any OCB mode - be it Qos or notQoS - there was a need of a
> firmware hack.
>
> The RFC IPv6-over-OCB has chosen the path of the expensive cards and
> drivers with QoS; it was in part guided by the experience of a
> particular vehicular manufacturer, thus effectively mandating the use of
> QoS .11 headers for all IPv6.  (this particular manufacturer has other
> very advantageous interests in automobile comm technologies but this
> particular QoS aspect is debatable IMHO).
>
> If I were to re-start and recommend the use of OCB to other
> manufacturers (not the car manufacturers) I'd go the path of cheap cards
> instead, if others would rally.
>
> That said, an important aspect (other than the QoS-nonQoS aspect) is how
> to make IP work on OCB.  Be they QoS-notQoS cards all will support IPv6,
> but how to set up addresses is another matter.  How to run SLAAC, DHCP,
> what prefix lengths, are matters that can be up to discussion. IPMON
> touches a little bit on these aspects too.
>
>> Has anyone had experience(s) with this they can share with me?
>>
>> This would then be an important use of IPv6 over OCB; also
>> leveraging SCHC as an Ethertype:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-intarea-schc-protocol-numbers/ 
>>
>
> Header compression for OCB?  I am not sure there is a need of it? There
> are huge bandwidths now possible with OCB, I'd guess in the range of
> Gbit/s.  This is much more than the initial .11p implementations which
> maxed at around 16mbit/s.
>
> But probably there are other tech arguments for SCHC and OCB.
>
> Alex
>
>>
>>
>>
> thanks
>>
>> Bob
>>
>> _______________________________________________ its mailing list 
>> [e-mail] https://www.ietf.org/mailman/listinfo/its
>
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its