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

[Alexandre Petrescu <[e-mail]>]

Le 27/07/2023 à 15:44, Robert Moskowitz a écrit :
> 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....

Sorry if I say something not appropriate but here goes:

the saying 'STA _may_ send ... QoS Data' is to be understood further. 
If it were IETF text I'd say that that 'may' is not something mandatory, 
meaning QoS Data is not mandatory.

Some manufacturers implement it, others no.

However, the RFC IPv6-over-OCB seems to make it mandatory.

Closed parenthesis.

> 
> 
>>
>> 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!

Makes sense.

But surface mount is also less future proof, meaning that future 
versions of OCB might not be allowed in that vehicle because of that 
surface mount.  It could be that vibrations could be addressed in more 
future proof ways.

But yes indeed it makes sense to have the capability of surface mounting 
and thus address vibrations.

Alex

> 
> 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
>