Big companies and universities are working on V2X technologies. But what about V2P(Vehicle to Pedestrians/Motorcyclists/Bicyclists). Most professionals think this is only about V2V(Vehicle to Vehicle) and V2I (Vehicle to Infrastructure). I am doing a feasibility study on what is possible in the field of V2P Pedestrians and bicycle communication. Any contribution would be appreciated.
It would be nice if we could adjust an android phone to listen to the 5.9 GHz with a 10 MHz bandwidth. I know that some Atheros chipsets are capable of switching to the correct frequency with the correct bandwidth. Ubuntu code has already implemented parts to do the real thing and I also find hints everywhere that the OpenWRT could do something similar. I will be looking for hardware to support this. Also here I would appreciate all the help I can get.
Hardware found so far which can work on the 5.9GHz and have a mode for 10MHz wide channels:
- Atheros AR5414 (ATH5K driver)
- Atheros AR92xx (ATH9K driver)
- UNEX VTX-201 (unex.com.tw)
- U-BLOX THEO-P1 (Evaluation kit for THEO-P1 series with USB communication)
With standard wifi (802.11a/b/g/n) a station needs to join a Basic Service Set (BSS) before they can transmit and receive data. With 802.11p this works differently. This technique is also called 802.11-OCB (Outside Context of BSS (Basic Service Set)). There is no connection made to a wifi access point. All communication is broadcasted and a setup to join a BSS is not needed. There is also no time to join a BSS. Messages should be sent, rceived, interpreted and acted on within milliseconds.
With 802.11-OCB the addressing is usually done using broadcast messages where the destination physical address is ff:ff:ff:ff:ff:ff (broadcast). There are some exceptions. Suppose that Station-A wants to send a message which is relevant in a target area and Station-A is not in the vincinity. However Station-A is aware that Station-B is significantly closer to the target area
and is able to broadcast the messages from Station-A. In that scenario Station-A is sending the messages directly to the physical address of Station-B which in turn can broadcast the message from Station-A in the designated target area.
Now I will be looking a little closer at the messages themselves (using Wirehark). There are dissectors available which can interpret ETSI messages. The messages do not contain an IP section and are purely to be sent locally using 5.9 GHz radios. This does not scale that easy.
What it does contain:
- Ethernet II section
- GeoNetworking header
The source physical address (??:??:??:00:01:00) and destination physical address (ff:ff:ff:ff:ff:ff) is included. Also it includes the type which is in this case ETSI TC-ITS (0x8947)
Type: Any(0), Beacon(1), GeoUnicast(2), GeoAnycast(3), GeoBroadcast(4), TSB(Topologically Scoped Broadcast: 5) or LS (6)
Subtype: Circle(0), Rectangle(1) or Ellipse(2);
This is the umbrella term for all specific usecases like:
Vehicle to Vehicle
- Collision warning (avoidance) systems
- Support for autonomous driving
- Upcoming emergency vehicles
Vehicle to Infrastructure
- SPAT (Signal phasing and timing) for knowing when the trafficlight will turn green
- RWW (RoadWorksWarning) to warn when there will be roadworks, including the closed lanes and the speed limits
- Support for autonomous driving
Vehicle to Pedestrians
Pedestrians receive warnings to prevent collisions. A list of who can be a P.
Vehicle to Cloud
- All other use-cases where real-time is not that important.
- Parking information
- Real-time traffic jams / suggested alternative routes
- Reservation of charging spots
- Maximum speed per location
- Mobile speed traps