Subject: [geonet/its] 802.11p USB dongles?

From: "Arcot, Kiran K" <[email-masked]>
Date: Tue, 4 Nov 2014 11:42:19 -0500

Hello All,

I am a graduate student at the University of Kentucky and I am looking at
using 802.11p for communication between out quad-copters. To that end is
anyone aware of any 802.11p USB dongles on the market? Are there any open
source drivers (Linux specifically) that are in semi-usable state or in
development?  If so where can one find such a driver for 802.11p cards/USB
dongles?

Thanks,
Kiran Arcot.

---

From: "Arcot, Kiran K" <[email-masked]>
Date: Thu, 6 Nov 2014 11:04:09 -0500

Hello RR,

The idea indeed is to comply with the standards and regulation already
present.

Thanks,
Kiran.

On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy <[email-masked]> wrote:

>     I'd suggest you look for 802.11a compliant dongles that have mad-wifi
> or some other open source driver you can modify.  I'd also recommend you
> NOT use the 5.850-5.925GHz band since that band is reserved for ITS,
>  unless, of course, you plan on complying with the number of standards and
> regulations already in place for use of the band.
>
>
>
> Cheers,
>
>
>
> RR
>
>
>   ------------------------------
>
> *From:* Arcot, Kiran K [mailto:[email-masked]]
> *Sent:* Tuesday, November 04, 2014 10:42 AM
> *To:* [email-masked]
> *Subject:* [geonet/its] 802.11p USB dongles?
>
>
>
> Hello All,
>
>
>
> development?  If so where can one find such a driver for 802.11p
> cards/USB dongles?
>
>
>
> Thanks,
>
> Kiran Arcot.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 06 Nov 2014 17:44:33 +0100

Well - there may be ways to comply to the legislation of 5.9GHz and high 
power levels for ITS, if the flying experimentation happens indoors 
(hangar).

But coming back to the original question: is there an USB dongle 802.11p?

The manufacturer I am familiar with (UNEX, not to name it) only does 
mini-PCI 802.11p cards.

An 802.11p USB dongle format may be useful to some of the most 
constrained linux platforms which feature USB rather than mini-PCI.

If this is done, and given the easiness of running IP on 802.11p, I'd be 
thrilled to see IP between flying objects.

Alex

Le 06/11/2014 17:04, Arcot, Kiran K a écrit :
> On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     __ __ __
>
>     I'd suggest you look for 802.11a compliant dongles that have
>     mad-wifi or some other open source driver you can modify. I'd also
>     recommend you NOT use the 5.850-5.925GHz band since that band is
>     reserved for ITS,  unless, of course, you plan on complying with the
>     number of standards and regulations already in place for use of the
>     band.____
>
>     __ __
>
>     Cheers,____
>
>     __ __
>
>     RR ____
>
>     __ __
>
>     ------------------------------------------------------------------------
>
>     *From:*Arcot, Kiran K [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Subject:* [geonet/its] 802.11p USB dongles?____
>
>     __ __
>
>     Hello All,____
>
>     __ __
>
>     I am a graduate student at the ____University__ of __Kentucky____
>     and I am looking at using 802.11p for communication between out
>     quad-copters. To that end is anyone aware of any 802.11p USB dongles
>     on the market? Are there any open source drivers (Linux
>     specifically) that are in semi-usable state or in development?  If
>     so where can one find such a driver for 802.11p cards/USB dongles?____
>
>     __ __
>
>     Thanks,____
>
>     Kiran Arcot.____
>
>
>
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>

---

From: "Varadi , Andras (lesswire AG Ungarn)" <[email-masked]>
Date: Fri, 7 Nov 2014 12:52:08 +0000

Hi Kiran

I also have some serious concerns about outdoor usage of ETSI G5 in the EU...
Just for an example: how will You tolerate DCC (Decentralized Congestion Control) in Your use case? (which will not let You transmit just any time - and You need DCC to transmit and comply the standards)

USB 11p module (available next year) - http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its-car2x/overview/
More info on availibility from the distributors: http://www.lesswire.com/en/distributors/commercials-new/

Üdvözlettel / Best regards,
   András Váradi

     Project Manager - C2X/ITS Systems
     Customer Support Wireless Modules

     Automotive & WLAN Group 
     lesswire   Hungary | Office: +36 23521 667 | Email: [email-masked] 

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Thursday, November 06, 2014 5:45 PM
To: Arcot, Kiran K; [email-masked]
Cc: [email-masked]
Subject: Re: [geonet/its] 802.11p USB dongles?

Well - there may be ways to comply to the legislation of 5.9GHz and high power levels for ITS, if the flying experimentation happens indoors (hangar).

The manufacturer I am familiar with (UNEX, not to name it) only does mini-PCI 802.11p cards.

An 802.11p USB dongle format may be useful to some of the most constrained linux platforms which feature USB rather than mini-PCI.

If this is done, and given the easiness of running IP on 802.11p, I'd be thrilled to see IP between flying objects.

Alex

---

From: "Arcot, Kiran K" <[email-masked]>
Date: Fri, 7 Nov 2014 13:04:16 -0500

Hi Andras,

Thanks for the links. Will there be support from lesswire for Linux systems
for these USB modules or will the users have to come up with the drivers
themselves? Also, what do you think the price of USB module will be? Or is
it better to ask one of the distributors that question?

As for your DCC question, I have only now started looking in to the whole
802.11p shebang and haven't completely dug in to the requirements to comply
with the standards yet. I have been asking questions of Alexandru Petrescu
in another email chain and following his suggestions of first trying to
find a hardware/driver combination that will allow me to transmit in the
802.11p frequency band with IP.

In short, to answer your question about DCC, I don't know how to handle
that just yet.

Thanks,
Kiran.

On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG Ungarn) <
[email-masked]> wrote:

> Just for an example: how will You tolerate DCC (Decentralized Congestion
> Control) in Your use case? (which will not let You transmit just any time -
> and You need DCC to transmit and comply the standards)
>
> USB 11p module (available next year) -
> http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its-car2x/overview/
> More info on availibility from the distributors:
> http://www.lesswire.com/en/distributors/commercials-new/
>
> An 802.11p USB dongle format may be useful to some of the most constrained
> linux platforms which feature USB rather than mini-PCI.
>

---

From: "Arcot, Kiran K" <[email-masked]>
Date: Fri, 7 Nov 2014 17:23:00 -0500

On Fri, Nov 7, 2014 at 4:11 PM, Richard Roy <[email-masked]> wrote:

>     A few things to remember:
>
>
>
> 1) DCC is not yet mandatory anywhere and hopefully that situation will not
> change.
>
> 2) What needs to be done to address the congestion problem is to use 21rst
> century MAC/PHY technology, not 20th century technology, and it's
> technology that's available now.
>
> 2) If DCC does become mandatory, it is likely to be only be conditionally
> so (at least in Europe), conditioned on the use of ETSI's GeoNetworking
> protocol, and there is little to no chance of that protocol getting out of
> the research labs.
>
> 3) The coupling that people seem to believe exists between 11p and IPv6 is
> a fiction in their minds.  There is NO coupling.  IPv6 can be used as with
> any other lower layer protocols independent of anything to do with 11p.
> That said, there are issues of how to set up addresses in ad hoc networks
> of vehicles, but bridges and meshes (layer 2 addressing) are much better
> suited for that.
>
> 4) IPv6 networking is only required when attempting to use networks to
> communicate between peers.  I'm guessing your aviation application is not
> attempting to control a helicopter over the internet from your home.  Any
> use of a non-deterministic network for such applications is ... well ...
> just not a good idea.
>
>
Hehehe. No, I am not trying to control a helicopter over the internet :-)
 As I mentioned in the original post, I want to be able to communicate
between the quad-copters while they are in flight. I know there are methods
where you can communicate over 802.11 b/g/n with WiFi-P2P/Direct (not sure
which term is more appropriate, Direct probably) where one quad-copter
could act as a soft AP and the others could act as clients. And, I also
know that there are people who already stream video while the quad-copters
are in flight over Wi-Fi as well as actually controlling the flying objects
with a Wi-Fi controller.

But, that is not what I am looking for. I want to be able to send
direction/speed/heading information from the quads to each other while they
are in flight. A radar application so to speak, where each quad essentially
is aware of the other quads in the vicinity. Mind you, the
direction/speed/heading is just the first piece of information that I want
to share among the quads while they are in flight. If I can achieve this I
want to be able to do more than just information sharing. Since, I don't
want to set up a quad-copter as a soft AP I thought 802.11p is appropriate
since that operates outside of a BSS context. I may be wrong. I just don't
know. I am researching this stuff to figure out what is feasible and what
is not.

>
>
> Finally, as I suggested in a previous posting, you can modify a .11a USB
> dongle to run in the 5.9GHz band (i.e. create a .11p dongle) if you have
> access to the firmware.
>

Indeed, I have been looking at USB 802.11a dongles as you suggested and I
can find dual band dongles with chipsets such as RALink RT3572. This is
just an example. And http://wireless.kernel.org/en/users/Drivers indicates
that there are drivers available for RALink chipsets. So, theoretically, it
may be possible to modify the driver. But I have not yet researched if
firmware for the actual chipset is available or not. And the spec sheets of
the chipsets that I have looked at indicate that the frequency range of the
802.11a dongles goes up to only 5825 MHz (802.11a compliance).

I assume that is the reason you say I need access to the firmware so that I
can push the frequency range between 5855 MHz and 5925 MHz for 802.11p
compliance.

Thanks,
Kiran.

> *Sent:* Friday, November 07, 2014 12:04 PM
> *To:* Varadi , Andras (lesswire AG Ungarn)
>
> *Cc:* [email-masked]
> *Subject:* Re: [geonet/its] 802.11p USB dongles?
>
>
>
> Hi Andras,
>
>
>
> Thanks for the links. Will there be support from lesswire for Linux
> systems for these USB modules or will the users have to come up with the
> drivers themselves? Also, what do you think the price of USB module will
> be? Or is it better to ask one of the distributors that question?
>
>
>

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 07 Nov 2014 16:24:46 -0800

Kiran,

Some suggested amendments to the dialog below:

DCC is a congestion control scheme; as such it falls in the general
category of QoS control.  

MACs are access control algorithms and applicable to a single network
segment.  

Don't confuse the two.

More below...

On Fri, 2014-11-07 at 17:23 -0500, Arcot, Kiran K wrote:
>         1) DCC is not yet mandatory anywhere and hopefully that
>         situation will not change.  
>         
>         2) What needs to be done to address the congestion problem is
>         to use 21rst century MAC/PHY technology, not 20th century
>         technology, and it's technology that's available now.

I differ with RR on terminology and a look back in radio history
pre-Internet is why.  There are two kinds of MACs out there: contention
and contention-free.  In Ye Olde Radio days, operators had these
algorithms embedded in their operating protocols:

Contention access was known in YORD as 'free net'.  Contention-free
access was known as 'directed net'.  

Free nets are, of course, simple -- a few rules like listen before talk
so you don't stomp on somebody else's transmission.  There's an
assumption that everybody can hear everybody else -- if you can't hear
someone else, then your set up to unwittingly jam that station.  A pure
CSMA/CD network has no station in charge -- all are theoretically equal
[abusers].
    The overload characteristics of free nets are identical to those of
CSMA MACs today: since everybody is fighting every packet onto the
network, it's unstable under overload -- collisions beget collisions and
shoving more packets onto the network segment only worsens the problem.
That's the worst part.  But CSMA networks are bandwidth-inefficient --
the congestion kicks in at depressingly low levels of baseband
utilization.  There are several efficiency schemes like slotting and
partial centralization (changing CD to CA with the busy tone) that only
postpone the congestion problem -- they do not shape the (Poisson?)
shape of the curve.  Further, there are precious little resources in the
way of network segment management to decant off enough demand to get
back to a workable network segment.
     State of the industry.  Ethernet MACs were written in software
until the late '80s when we started seeing them embedded in ethernet
chips.  A decade later the same thing happened with WiFi, except faster
-- the migration to chips had taken place before it became popular.  

Directed net protocols entail having a base station (BS, there have been
several other archaic names like Net Control).  And a bunch of
subscriber stations (SS).  There most definitely is someone in charge.
Almost all contention-free MACs use a time-slice system where each SS is
allocated a transmit window and is obliged not to transmit at other
times.  The interesting protocol work has to do with how the BS
allocates the time slices to allow new SS to enter the network and to
afford some fairness (multiple definitions).  
     In WiFi, there's exactly one MAC message (the busy tone); in
directed nets such as IEEE 802.16 and TIA LTE there are about four dozen
MAC messages.  The complexity and multi-vendor testing that is required
is much greater.
     Those constraints, however, do solve some of the problems present
in CSMA nets.  A directed net is stable under overload.  Bandwidth
efficiency is much greater: depending on configurations, into the 90+%
territory.  Further, because every SS (and BS) is guaranteed at least
some time to transmit every frame the network segment can be positively
managed.  Without this control, effectiveness of schemes like DCC strike
me as very iffy.

>         
>         2) If DCC does become mandatory, it is likely to be only be
>         conditionally so (at least in Europe), conditioned on the use
>         of ETSI's GeoNetworking protocol, and there is little to no
>         chance of that protocol getting out of the research labs.
>         
>         3) The coupling that people seem to believe exists between 11p
>         and IPv6 is a fiction in their minds.  There is NO coupling.
>         IPv6 can be used as with any other lower layer protocols
>         independent of anything to do with 11p.  That said, there are
>         issues of how to set up addresses in ad hoc networks of
>         vehicles, but bridges and meshes (layer 2 addressing) are much
>         better suited for that. 

RR is exactly right here.  All IEEE 802 networks have an interface at
the top of layer 2 that is pretty much the same -- they pass the
contents of the payload through the interface along with an ethertype.
There are about 5 pages of appendix of different ethertypes that were
allocated but 0800 denotes IPv4 datagrams and 86DD (both hex) denote
IPv6.  In reality most routers ignore the ethertype, simply throwing
away any chunks of data that are not IP (and which version is code in
the first byte).  

What this means is that IPv4, IPv6 and those other 5 pages worth of
frames can all be passed over the network segment.  While I think a
design goal for [its] should be IPv6, I'm not rabid about it.
    (I've been victim of many US DoD attempts at mandating IPv6, all of
which flopped.  IETF has been very careful to accommodate both versions
in just about every RFC in the past few years.  IEEE 802 protocols are
generally agnostic except for things like the MIB which is agnostic if
you write that section of the standard with care.  IPv6 testing can be
fun -- not all the advertising claims are true.)

>         
>         4) IPv6 networking is only required when attempting to use
>         networks to communicate between peers.  I'm guessing your
>         aviation application is not attempting to control a helicopter
>         over the internet from your home.  Any use of a
>         non-deterministic network for such applications is ...
>         well ... just not a good idea.

RR got a couple concepts crossed up here.

Working upward: determinism (or near-determinism) is a characteristic of
contention-free MACs (and definitely NOT CSMA MACs).  

I don't understand what RR is trying to say with the IPv6 and peers.
IPv4 has been doing peer-peer comms for several decades now.  But if
he's thinking about some other protocols (e.g. IPX, Appletalk, 1609??)
then he may be right.  But the concept of peer-peer is essentially a
layer 3 issue not a layer 2 one.  
>         
> 
> 
> Hehehe. No, I am not trying to control a helicopter over the
> internet :-)  As I mentioned in the original post, I want to be able
> to communicate between the quad-copters while they are in flight. I
> know there are methods where you can communicate over 802.11 b/g/n
> with WiFi-P2P/Direct (not sure which term is more appropriate, Direct
> probably) where one quad-copter could act as a soft AP and the others
> could act as clients. And, I also know that there are people who
> already stream video while the quad-copters are in flight over Wi-Fi
> as well as actually controlling the flying objects with a Wi-Fi
> controller.

You've got a host of ifs ands and buts here and it's worth sorting them
out.

If you want n quad-coptors to talk to each other, one way is to equip
them all with some flavor of WiFi and go to it.  All one segment.  Or
one collision domain.  If the number of coptors is low this can work.  
     The protocol problems are the free-net ones outlined above --
you'll have them all.  With hidden hosts and the whole bit.  
     At the RF level, you'll have the distance / interference issues to
deal with.  On trick is to steer the beam -- it's been implemented many
times.  But with the randomness of CSMA MACs, this could be problematic
(I know some 802.16 vendors where were wiretapping the upload map to
inform the beam steering -- clever trick, but it won't work with WiFi
because there is not upload map).  

There's a stand-back-for-perspective issue as well.  Do you need to
communicate directly between the coptors or can you tie each one of them
into terrestrial internet and use it?  If you can, then you beat the
congestion issue into submission by overprovisioning -- it works
everywhere except in the last, wireless LAN, segment at each end of the
catenet.  (making DCC issues kinda problematic).  

> direction/speed/heading information from the quads to each other while
> they are in flight. A radar application so to speak, where each quad
> essentially is aware of the other quads in the vicinity. Mind you, the
> direction/speed/heading is just the first piece of information that I
> want to share among the quads while they are in flight. If I can
> achieve this I want to be able to do more than just information
> sharing. Since, I don't want to set up a quad-copter as a soft AP I
> thought 802.11p is appropriate since that operates outside of a BSS
> context. I may be wrong. I just don't know. I am researching this
> stuff to figure out what is feasible and what is not.

This is not new.  The airlines have been wrestling with the problems for
years, with all the myopias of limited understanding of the internet.  I
first got exposed to the US FAA's Aviation Tracking Network about
1990.  
     In my experience, you're better off planning in the other
direction.  Rather than starting with the flying (or otherwise mobile)
platform and flogging all the radio problems, work the problem by
'extending the internet to mobile platforms'.  That allows you to
leverage the assets (like essentially unlimited bandwidth -- about four
orders of magnitude more) of the fixed internet to offset those iron
limits in RF.  
> 
> 
>  
> 
>          
>         
>         Finally, as I suggested in a previous posting, you can modify
>         a .11a USB dongle to run in the 5.9GHz band (i.e. create
>         a .11p dongle) if you have access to the firmware.
>         
>         
> 
> 
> Indeed, I have been looking at USB 802.11a dongles as you suggested
> and I can find dual band dongles with chipsets such as RALink RT3572.
> This is just an example.
> And http://wireless.kernel.org/en/users/Drivers indicates that there
> are drivers available for RALink chipsets. So, theoretically, it may
> be possible to modify the driver. But I have not yet researched if
> firmware for the actual chipset is available or not. And the spec
> sheets of the chipsets that I have looked at indicate that the
> frequency range of the 802.11a dongles goes up to only 5825 MHz
> (802.11a compliance).
> 
> 
> I assume that is the reason you say I need access to the firmware so
> that I can push the frequency range between 5855 MHz and 5925 MHz for
> 802.11p compliance.
> 
No comments on the dongles; can't help you there.  But any help on the
rest?

> 
> Thanks,
> Kiran.
>  
>          
>         
>         RR
>         
>                                        
>         ______________________________________________________________
>         From: Arcot, Kiran K [mailto:[email-masked]] 
>         Sent: Friday, November 07, 2014 12:04 PM
>         To: Varadi , Andras (lesswire AG Ungarn)
>         
>         
>         Cc: [email-masked]
>         Thanks for the links. Will there be support from lesswire for
>         Linux systems for these USB modules or will the users have to
>         come up with the drivers themselves? Also, what do you think
>         the price of USB module will be? Or is it better to ask one of
>         the distributors that question?
>         
>         
>          
>         
>         
>         As for your DCC question, I have only now started looking in
>         to the whole 802.11p shebang and haven't completely dug in to
>         the requirements to comply with the standards yet. I have been
>         asking questions of Alexandru Petrescu in another email chain
>         and following his suggestions of first trying to find a
>         hardware/driver combination that will allow me to transmit in
>         the 802.11p frequency band with IP.
>         
>         
>          
>         
>         
>         In short, to answer your question about DCC, I don't know how
>         to handle that just yet.
>         
>         
>          
>         
>         
>          
>         
>         
>         Thanks,
>         
>         
>         Kiran.
>         
>         
>          
>         
>         
>          
>         
>         
>          
>         
>         
>          
>         
>         On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG
>         Ungarn) <[email-masked]> wrote:
>         
>         Hi Kiran
>         
>         Just for an example: how will You tolerate DCC (Decentralized
>         Congestion Control) in Your use case? (which will not let You
>         transmit just any time - and You need DCC to transmit and
>         comply the standards)
>         
>         Well - there may be ways to comply to the legislation of
>         5.9GHz and high power levels for ITS, if the flying
>         experimentation happens indoors (hangar).
>         
>         If this is done, and given the easiness of running IP on
>         802.11p, I'd be thrilled to see IP between flying objects.
>         
>         Alex
>         
>         
>         >     so where can one find such a driver for 802.11p
>         cards/USB
>         > dongles?____
>         >
>         >     __ __
>         >
>         >     Thanks,____
>         >
>         >     Kiran Arcot.____
>         >
>         >
>         >
>         >

---

From: "Arcot, Kiran K" <[email-masked]>
Date: Mon, 10 Nov 2014 15:12:51 -0500

Hi Rex,

Thanks for the detailed explanation of the 'contention' and
'contention-free'  MACs. I have answered your questions below.

Thanks,
Kiran.

On Fri, Nov 7, 2014 at 7:24 PM, Rex Buddenberg <[email-masked]>
wrote:

> Yes, I want the copters to communicate directly, but don't want to tie
them to the internet access. It is not important at the present time if the
copters have access to the "greater world" over the the internet. Just
communication between copters is required without being tied to a
terrestrial internet.

---

From: "Arcot, Kiran K" <[email-masked]>
Date: Mon, 10 Nov 2014 15:25:35 -0500

Hi RR,

What you describe may be what I need to use. Here is a unit I found from
Arada systems.

http://www.aradasystems.com/locomate-mini-obu/

It shows the size of the unit with reference to a smartphone in a car. It
also looks like they have a version 2: the LocomateMini2. And the datasheet
has all the acronyms that you mention.

http://www.aradasystems.com/wp-content/uploads/2014/10/LocoMate_mini_Datasheet_Oct14.pdf

It also mentions an SDK for development of applications. I will need to
look at the pricing (at this point I am guessing it is relatively
expensive) and the SDK to see if it matches my requirements. Although, it
is not obvious from the datasheet if it can be interfaced with a
development boards such as a Raspberry Pi, Beagleboard, Odroid XU3 etc.

Thanks,
Kiran.

On Mon, Nov 10, 2014 at 12:34 PM, Richard Roy <[email-masked]> wrote:

>     Arcot,
>
>
>
> What you want to accomplish has already been done in numerous field trials
> of V2V and V2I technology developed over the last 15 years in IEEE 1609 and
> SAE DSRC TC.  You should look into getting a 1609.3 (soon to be v3) WAVE
> compliant stack and look into the SAE J2735 message set to put on top of
> your layer 2 802.11p dongle.  These are layer 3 (null-networking actually)
> and above protocols and message sets for accomplishing exactly what you
> want to do.  You don't need IP for this, and as far as 11p
> (dot11OCBActivated is true) operations, they are exactly what you need.
>
>
>
> Cheers,
>
>
>
> RR
>
>
>
> PS. You might also want to consider a little security (IEEE 1609.2) if you
> are at all concerned about getting hacked (someone sending false BSMs to
> confuse your squadron:^)))
>
>
>
> *Sent:* Friday, November 07, 2014 2:23 PM
> *To:* [email-masked]
> *Cc:* Varadi , Andras (lesswire AG Ungarn); [email-masked]
>
> want to share among the quads while they are in flight. If I can achieve
> this I want to be able to do more than just information sharing. Since, I
> don't want to set up a quad-copter as a soft AP I thought 802.11p is
> appropriate since that operates outside of a BSS context. I may be wrong. I
> just don't know. I am researching this stuff to figure out what is feasible
> and what is not.
>
>
>
>
>
>
>
> just an example. And http://wireless.kernel.org/en/users/Drivers
> indicates that there are drivers available for RALink chipsets. So,
> theoretically, it may be possible to modify the driver. But I have not yet
> researched if firmware for the actual chipset is available or not. And the
> spec sheets of the chipsets that I have looked at indicate that the
> frequency range of the 802.11a dongles goes up to only 5825 MHz (802.11a
> compliance).
>
>
>
> I assume that is the reason you say I need access to the firmware so that
> I can push the frequency range between 5855 MHz and 5925 MHz for 802.11p
> compliance.
>
>
>
> Thanks,
>
> Kiran.
>
>
>
>
>
> RR
>      lesswire   Hungary | Office: +36 23521 667 <%2B36%2023521%20667> |
> Email: [email-masked]
>
>

---

From: "Varadi , Andras (lesswire AG Ungarn)" <[email-masked]>
Date: Tue, 18 Nov 2014 19:02:01 +0000

Dear Arcot, Richard

Sorry for the long delay, I will try to answer short,

>> Will there be support from lesswire for Linux systems for these USB modules or will the users have to come up with the drivers themselves? Also, what do you think the price of USB module will be? Or is it better to ask one of the distributors that question?

AV: We provide products, not pure HW and thus I dont see a way for selling anything without a driver. I do not know who will supply the driver though, the distri, the module, the chip manufacturer or anyone else. This will be determined once we release the product.

----------
please note that these are my personal opinions / feelings:

>> In short, to answer your question about DCC, I don't know how to handle that just yet.
>> 1) DCC is not yet mandatory anywhere and hopefully that situation will not change.

AV: In the EU at least for G5A we are talking about a safety system which needs to be trustworthy, if my cars safety system fails in an urban intersection, because someone is allowed to transmit non-safety data on those channels, then the whole system is useless.
(in this sense if You transmit safety data, then you apply DCC)

>>2) If DCC does become mandatory, it is likely to be only be conditionally so (at least in Europe), conditioned on the use of ETSI's GeoNetworking protocol, and there is little to no chance of that protocol getting out of the research labs.

Its not any more in the research labs:
http://www.etsi.org/deliver/etsi_tr%5C101600_101699%5C101607%5C01.01.01_60%5Ctr_101607v010101p.pdf
http://www.etsi.org/news-events/news/753-2014-02-joint-news-cen-and-etsi-deliver-first-set-of-standards-for-cooperative-intelligent-transport-systems-c-its
(If my links are broken:  ETSI TR 101 607)

>> The coupling that people seem to believe exists between 11p and IPv6 is a fiction in their minds.  There is NO coupling.

No coupling, but IPv6 is a (maybe the best) way to globally address future cars (check ITSSv6 for example), nevertheless, for safety messages (normal) IP has just to big overhead, a CAM or DENM V2V message is much more compact and IP can not fight that. (and we need short/quick transmission times!!)

     Project Manager – C2X/ITS Systems
     Customer Support Wireless Modules

     Automotive & WLAN Group
     lesswire   Hungary | Office: +36 23521 667 | Email: [email-masked]<mailto:[email-masked]>

From: Arcot, Kiran K [mailto:[email-masked]]
Sent: Friday, November 07, 2014 7:04 PM
To: Varadi , Andras (lesswire AG Ungarn)
Cc: [email-masked]
Subject: Re: [geonet/its] 802.11p USB dongles?

Hi Andras,

Thanks for the links. Will there be support from lesswire for Linux systems for these USB modules or will the users have to come up with the drivers themselves? Also, what do you think the price of USB module will be? Or is it better to ask one of the distributors that question?

As for your DCC question, I have only now started looking in to the whole 802.11p shebang and haven't completely dug in to the requirements to comply with the standards yet. I have been asking questions of Alexandru Petrescu in another email chain and following his suggestions of first trying to find a hardware/driver combination that will allow me to transmit in the 802.11p frequency band with IP.

In short, to answer your question about DCC, I don't know how to handle that just yet.

Thanks,
Kiran.

On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG Ungarn) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kiran

     Automotive & WLAN Group
     lesswire   Hungary | Office: +36 23521 667<tel:%2B36%2023521%20667> | Email: [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: its [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alexandru Petrescu
Sent: Thursday, November 06, 2014 5:45 PM
To: Arcot, Kiran K; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [geonet/its] 802.11p USB dongles?

Alex

Le 06/11/2014 17:04, Arcot, Kiran K a écrit :
> On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     __ __ __
>
>     *From:*Arcot, Kiran K [mailto:[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]<mailto:[email-masked]>>]
>     *To:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
its mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/its

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Nov 2014 11:46:52 +0100

Hello,

Here are my thoughts.

Le 18/11/2014 20:02, Varadi , Andras (lesswire AG Ungarn) a écrit :
>>>  Will there be support from lesswire for Linux systems for these USB
>>> modules or will the users have to come up with the drivers themselves?

There is one 802.11p driver used extensively on many platforms.  It is 
based on a  modified version of the Atheros' ath5k driver.  I guess it 
may be used on 802.11p USB dongles as well.

The base ath5k driver is present in the linux kernel and is covered by a 
mixture of GPL/BSD-style licenses as well as a copyright notice.

(see the licensing scheme in the top-level comments in this C file:
http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath5k/base.c )

By this licensing scheme, it is not sure the source code of this 
athk-based 802.11p driver must or may be redistributed freely.  It can 
"alternatively".

Actually, I do think there is a strong need for an open-source GPL-style 
802.11p driver to be maintained on many platforms.  It is relatively 
easy to do one, starting from that ath5k.

> AV: We provide products, not pure HW and thus I dont see a way for
> selling anything without a driver. I do not know who will supply the
> driver though, the distri, the module, the chip manufacturer or anyone
> else. This will be determined once we release the product.
>
> ----------
>
> _please note that these are my personal opinions / feelings:_
>
> AV: In the EU at least for G5A we are talking about a safety system
> which needs to be trustworthy, if my cars safety system fails in an
> urban intersection, because someone is allowed to transmit non-safety
> data on those channels, then the whole system is useless.
>

DCC stands for Decentralized Congestion Control, as specified by
document ETSI TS 102 687.  It is a high-level medium access facilitator: 
power control (raise or lower emission power levels depending on noise), 
bandwidth control (raise or lower).  There are other MAC access 
mechanisms already in place.

Driving safety is indeed of paramount importance.  However, it may be 
hard to rely solely on 802.11p for safety, even if it is enhanced with 
DCC.  Because 5.9GHz is unlicensed spectrum - anyone can emit in this 
space without owning a license from authority - jammers are easy to do.

Driving safety needs to rely on additional mechanisms such as 3D 
reconstruction based on video recognition, radar waves bouncing off 
obstacles (laser, lidar), and as a last resort - human sight, since 
ultimately it is a human that is in charge of all this.

[...]

>>> The coupling that people seem to believe exists between 11p and IPv6 is
>>> a fiction in their minds.  There is NO coupling.

11p and IP are natural fits though.  Both IPv6 _and_ IPv4 work ok very 
easily on 802.11p.

Additional layers between 11p and the IP networking layer may come at a 
cost.

Enhanced IP layers (extension headers, IP control protocols) are another 
matter, of course.

> No coupling, but IPv6 is a (maybe the best) way to globally address
> future cars

I agree.  There is a real case manufacturers are confronted with when 
planning production and assigning IP addresses to them.  IPv4 addresses 
no longer available, NAT clumsy remote software updates, strong IPv6 
migration in the Internet core - are all factors impacting the 
addressing architecture in the long term for the future vehicles.

> (check ITSSv6 for example), nevertheless, for safety
> messages (normal) IP has just to big overhead, a CAM or DENM V2V message
> is much more compact and IP can not fight that. (and we need short/quick
> transmission times!!)

Sorry, I disagree.

The shortest IP message is 40byte long, it is not overhead.

What is the shortest CAM or DENM message?

The latency is precisely the same for both IP and CAM or DENM messages.

(I agree with you though if the functionality of a CAM message like 
"here I am" is implemented in the form of an http/tcp/ip 
request-response "where are you/here I am" between a client and a 
server, with multiple 3-way handshakes).

Alex

> lesswire Hungary***|***Office: +36 23521 667***|***Email:
> [email-masked] <mailto:[email-masked]>
>
> *From:*Arcot, Kiran K [mailto:[email-masked]]
> *Sent:* Friday, November 07, 2014 7:04 PM
> As for your DCC question, I have only now started looking in to the
> whole 802.11p shebang and haven't completely dug in to the requirements
> to comply with the standards yet. I have been asking questions of
> Alexandru Petrescu in another email chain and following his suggestions
> of first trying to find a hardware/driver combination that will allow me
> to transmit in the 802.11p frequency band with IP.
>
> On Fri, Nov 7, 2014 at 7:52 AM, Varadi , Andras (lesswire AG Ungarn)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Hi Kiran
>
> Control) in Your use case? (which will not let You transmit just any
> time - and You need DCC to transmit and comply the standards)
>
>       lesswire   Hungary | Office: +36 23521 667
> <tel:%2B36%2023521%20667> | Email: [email-masked]
> <mailto:[email-masked]>
>
>
> From: its [mailto:[email-masked] <mailto:[email-masked]>] On
> Behalf Of Alexandru Petrescu
> To: Arcot, Kiran K; [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
>> On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy <[email-masked] <mailto:[email-masked]>
>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>
>>     __ __ __
>>
>>     *From:*Arcot, Kiran K [mailto:[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>]
>>     *To:[email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> <mailto:[email-masked]>>
>>[email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: "Varadi , Andras (lesswire AG Ungarn)" <[email-masked]>
Date: Mon, 24 Nov 2014 14:45:16 +0000

Hi Alex

>> Driving safety is indeed of paramount importance.  However, it may be hard to rely solely on 802.11p for safety, even if it is enhanced with DCC.  Because 5.9GHz is unlicensed spectrum - anyone can emit in this space without owning a license from authority - jammers are easy to do

Why do You state that its unlicensed?

" in the licensed ITS band of 5.9 GHz (5.85-5.925 GHz)" - http://en.wikipedia.org/wiki/IEEE_802.11p

     Automotive & WLAN Group 

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Monday, November 24, 2014 11:47 AM
To: [email-masked]
Subject: Re: [geonet/its] 802.11p USB dongles?

Hello,

Here are my thoughts.

>>> modules or will the users have to come up with the drivers themselves?

There is one 802.11p driver used extensively on many platforms.  It is based on a  modified version of the Atheros' ath5k driver.  I guess it may be used on 802.11p USB dongles as well.

The base ath5k driver is present in the linux kernel and is covered by a mixture of GPL/BSD-style licenses as well as a copyright notice.

By this licensing scheme, it is not sure the source code of this athk-based 802.11p driver must or may be redistributed freely.  It can "alternatively".

Actually, I do think there is a strong need for an open-source GPL-style 802.11p driver to be maintained on many platforms.  It is relatively easy to do one, starting from that ath5k.

>>>  1) DCC is not yet mandatory anywhere and hopefully that situation 
>>> will
> not change.
>

DCC stands for Decentralized Congestion Control, as specified by document ETSI TS 102 687.  It is a high-level medium access facilitator: 
power control (raise or lower emission power levels depending on noise), bandwidth control (raise or lower).  There are other MAC access mechanisms already in place.

Driving safety is indeed of paramount importance.  However, it may be hard to rely solely on 802.11p for safety, even if it is enhanced with DCC.  Because 5.9GHz is unlicensed spectrum - anyone can emit in this space without owning a license from authority - jammers are easy to do.

Driving safety needs to rely on additional mechanisms such as 3D reconstruction based on video recognition, radar waves bouncing off obstacles (laser, lidar), and as a last resort - human sight, since ultimately it is a human that is in charge of all this.

[...]

>>> The coupling that people seem to believe exists between 11p and IPv6 
>>> is a fiction in their minds.  There is NO coupling.

11p and IP are natural fits though.  Both IPv6 _and_ IPv4 work ok very easily on 802.11p.

Additional layers between 11p and the IP networking layer may come at a cost.

Enhanced IP layers (extension headers, IP control protocols) are another matter, of course.

> No coupling, but IPv6 is a (maybe the best) way to globally address 

I agree.  There is a real case manufacturers are confronted with when planning production and assigning IP addresses to them.  IPv4 addresses no longer available, NAT clumsy remote software updates, strong IPv6 migration in the Internet core - are all factors impacting the addressing architecture in the long term for the future vehicles.

> (check ITSSv6 for example), nevertheless, for safety messages (normal) 
> IP has just to big overhead, a CAM or DENM V2V message is much more 
> compact and IP can not fight that. (and we need short/quick 
> transmission times!!)

Sorry, I disagree.

(I agree with you though if the functionality of a CAM message like "here I am" is implemented in the form of an http/tcp/ip request-response "where are you/here I am" between a client and a server, with multiple 3-way handshakes).

Alex

> systems for these USB modules or will the users have to come up with 
> the drivers themselves? Also, what do you think the price of USB 
> module will be? Or is it better to ask one of the distributors that question?
>
> whole 802.11p shebang and haven't completely dug in to the 
> requirements to comply with the standards yet. I have been asking 
> questions of Alexandru Petrescu in another email chain and following 
> his suggestions of first trying to find a hardware/driver combination 
> that will allow me to transmit in the 802.11p frequency band with IP.
>
> Congestion
> http://www.lesswire.com/en/products/wireless-modules/car2x/wibear-its-
> car2x/overview/ More info on availibility from the distributors:
> From: its [mailto:[email-masked] <mailto:[email-masked]>] 
> On Behalf Of Alexandru Petrescu
> Well - there may be ways to comply to the legislation of 5.9GHz and 
> high power levels for ITS, if the flying experimentation happens 
> indoors (hangar).
>
> If this is done, and given the easiness of running IP on 802.11p, I'd 
> be thrilled to see IP between flying objects.
>
> Alex
>
>
>> The idea indeed is to comply with the standards and regulation 
>> already present.
>>
>> Thanks,
>> Kiran.
>>
>> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>
>>     __ __ __
>>
>> ---------------------------------------------------------------------
>> -
>> --
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Nov 2014 17:04:59 +0100

Hi András,

There may be a question of terminology here.

Le 24/11/2014 15:45, Varadi , Andras (lesswire AG Ungarn) a écrit :
> Hi Alex
>
>>> Driving safety is indeed of paramount importance.  However, it
>>> may be hard to rely solely on 802.11p for safety, even if it is
>>> enhanced with DCC.  Because 5.9GHz is unlicensed spectrum -
>>> anyone can emit in this space without owning a license from
>>> authority - jammers are easy to do
>

Because I do not need a license from any authority to emit radio in that 
frequency range.

WiFi is unlicensed, whereas GPS or cellular are licensed.

> " in the licensed ITS band of 5.9 GHz (5.85-5.925 GHz)" -
> http://en.wikipedia.org/wiki/IEEE_802.11p

I guess that is wrong.

No?

Alex

>
>
> Üdvözlettel / Best regards, András Váradi
>
> Project Manager - C2X/ITS Systems Customer Support Wireless Modules
>
> Automotive & WLAN Group lesswire   Hungary | Office: +36 23521 667 |
> -----Original Message----- From: its [mailto:[email-masked]] On
> Behalf Of Alexandru Petrescu Sent: Monday, November 24, 2014 11:47
> AM To: [email-masked] Subject: Re: [geonet/its] 802.11p USB dongles?
>
> Hello,
>
> Here are my thoughts.
>
>>>> Will there be support from lesswire for Linux systems for these
>>>> USB modules or will the users have to come up with the drivers
>>>> themselves?
>
> There is one 802.11p driver used extensively on many platforms.  It
> is based on a  modified version of the Atheros' ath5k driver.  I
> guess it may be used on 802.11p USB dongles as well.
>
> The base ath5k driver is present in the linux kernel and is covered
> by a mixture of GPL/BSD-style licenses as well as a copyright
> notice.
>
> athk-based 802.11p driver must or may be redistributed freely.  It
> can "alternatively".
>
> Actually, I do think there is a strong need for an open-source
> GPL-style 802.11p driver to be maintained on many platforms.  It is
> relatively easy to do one, starting from that ath5k.
>
>> selling anything without a driver. I do not know who will supply
>> the driver though, the distri, the module, the chip manufacturer or
>> anyone else. This will be determined once we release the product.
>>
>> ----------
>>
>>>> to
>> handle that just yet.
>> AV: In the EU at least for G5A we are talking about a safety
>> system which needs to be trustworthy, if my cars safety system
>> fails in an urban intersection, because someone is allowed to
>> transmit non-safety data on those channels, then the whole system
>> is useless.
>>
> document ETSI TS 102 687.  It is a high-level medium access
> facilitator: power control (raise or lower emission power levels
> depending on noise), bandwidth control (raise or lower).  There are
> other MAC access mechanisms already in place.
>
> hard to rely solely on 802.11p for safety, even if it is enhanced
> with DCC.  Because 5.9GHz is unlicensed spectrum - anyone can emit in
> this space without owning a license from authority - jammers are easy
> to do.
>
>>>> The coupling that people seem to believe exists between 11p and
>>>> IPv6 is a fiction in their minds.  There is NO coupling.
>
>> No coupling, but IPv6 is a (maybe the best) way to globally
>> address future cars
>
> planning production and assigning IP addresses to them.  IPv4
> addresses no longer available, NAT clumsy remote software updates,
> strong IPv6 migration in the Internet core - are all factors
> impacting the addressing architecture in the long term for the future
> vehicles.
>
>> (check ITSSv6 for example), nevertheless, for safety messages
>> (normal) IP has just to big overhead, a CAM or DENM V2V message is
>> much more compact and IP can not fight that. (and we need
>> short/quick transmission times!!)
>
> Sorry, I disagree.
>
>> Üdvözlettel / Best regards, András Váradi
>>
>> Project Manager - C2X/ITS Systems Customer Support Wireless
>> Modules
>>
>> Automotive & WLAN Group lesswire Hungary***|***Office: +36 23521
>> 667***|***Email: [email-masked] <mailto:[email-masked]>
>>
>> *From:*Arcot, Kiran K [mailto:[email-masked]] *Sent:* Friday,
>> November 07, 2014 7:04 PM *To:* Varadi , Andras (lesswire AG
>> Ungarn) *Cc:* [email-masked] *Subject:* Re: [geonet/its] 802.11p USB
>> dongles?
>>
>> Hi Andras,
>>
>> Linux systems for these USB modules or will the users have to come
>> up with the drivers themselves? Also, what do you think the price
>> of USB module will be? Or is it better to ask one of the
>> distributors that question?
>>
>> As for your DCC question, I have only now started looking in to
>> the whole 802.11p shebang and haven't completely dug in to the
>> questions of Alexandru Petrescu in another email chain and
>> following his suggestions of first trying to find a hardware/driver
>> combination that will allow me to transmit in the 802.11p frequency
>> band with IP.
>>
>> Ungarn) <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Kiran
>>
>> I also have some serious concerns about outdoor usage of ETSI G5
>> in the EU... Just for an example: how will You tolerate DCC
>> (Decentralized Congestion Control) in Your use case? (which will
>> not let You transmit just any time - and You need DCC to transmit
>> and comply the standards)
>>
car2x/overview/ More info on availibility from the distributors:
>> Üdvözlettel / Best regards, András Váradi
>>
>> Project Manager - C2X/ITS Systems Customer Support Wireless
>> Modules
>>
>> Automotive & WLAN Group lesswire   Hungary | Office: +36 23521 667
>> -----Original Message----- From: its [mailto:[email-masked]
>> <mailto:[email-masked]>] On Behalf Of Alexandru Petrescu
>> Sent: Thursday, November 06, 2014 5:45 PM To: Arcot, Kiran K;
>> [email-masked] <mailto:[email-masked]> Cc: [email-masked]
>> <mailto:[email-masked]> Subject: Re: [geonet/its] 802.11p USB
>> dongles?
>>
>> Well - there may be ways to comply to the legislation of 5.9GHz
>> and high power levels for ITS, if the flying experimentation
>> happens indoors (hangar).
>>
>> If this is done, and given the easiness of running IP on 802.11p,
>> I'd be thrilled to see IP between flying objects.
>>
>> Alex
>>
>>
>>> Thanks, Kiran.
>>> On Wed, Nov 5, 2014 at 3:08 PM, Richard Roy
>>> <[email-masked] <mailto:[email-masked]>
>>> mad-wifi or some other open source driver you can modify. I'd
>>> also recommend you NOT use the 5.850-5.925GHz band since that
>>> band is reserved for ITS,  unless, of course, you plan on
>>> complying with the number of standards and regulations already in
>>> place for use of the band.____
>>>
>>> __ __
>>>
>>> Cheers,____
>>>
>>> __ __
>>>
>>> RR ____
>>>
>>> __ __
>>>
>>>
-
>>> <mailto:[email-masked]> <mailto:[email-masked]
>>> <mailto:[email-masked]>>] *Sent:* Tuesday, November 04, 2014
>>> 10:42 AM *To:[email-masked] <mailto:[email-masked]>
>>> <mailto:[email-masked]
>> <mailto:[email-masked]>>
>>> I am a graduate student at the ____University__ of
>>> __Kentucky____ and I am looking at using 802.11p for
>>> communication between out quad-copters. To that end is anyone
>>> aware of any 802.11p USB dongles on the market? Are there any
>>> open source drivers (Linux specifically) that are in semi-usable
>>> state or in development?  If so where can one find such a driver
>>> for 802.11p cards/USB dongles?____
>>>
>>> __ __
>>>
>>> Thanks,____
>>>
>>> Kiran Arcot.____
>>>
>>>
>>>
>>>
>>> _______________________________________________ its mailing list
>> _______________________________________________ its mailing list
>> _______________________________________________ its mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/its
>>
>
>
> _______________________________________________ its mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/its
>
>