ASTM Architecture Task Force

Scope/Objective:

To develop a DSRC architecture that satisfies all of the North American needs and those of ISO TC204/WG16 also, if possible.

One of the WG16 goal is to include multiple communications links from the vehicle to the roadside, of which DSRC is but one. Thus they require a routing function in L3 that is not among the North American requirements but would be nice to have if it doesn't "cost" us anything. In this case, cost refers to the overall program schedule, any potential negative impacts on the final products, or actual hardware and software cost (in dollars). We are trying to fully support this capability as an option to our systems but not as a required capability.

Both architectural needs are to be capable of supporting multiple on-board data networks, direct interface to an on-board system, or to serve as a stand-alone device. Another difference between the North American and ISO definitions of on-board network interfaces is that ISO insists that the only on-board interface will be via an IP network, whereas the North American approach is to support any and all networks, including the common existing networks based on Controller Area Network (CAN) which is in widespread use for both passenger cars and heavy duty vehicles.

Status: NOTE: CHANGES TO THE ARCHITECTURE RESULTED FROM THE AUGUST MEETING.

We thought we were finished with the architecture, but persistent problems in defining the details of what we have been calling the Communications Services Layer resulted in major changes at the Augus2002 meeting. The result is the proposed architecture that we are now working to. The big difference between this and previous versions is what we are calling (for lack of a better term) a "MAC Extension". The reason this was done was to handle the management of multiple channels on a single radio. The ISO approach works well for managing multiple radios, but cannot control the case of a single radio which must switch between multiple channels. The same problem existed with trying to do this with the previous Communication Services layer. The simple way of describing the problem is that this layer knows nothing about the channels available, when they should be switched (can be between two consecutive packets). This layer is also unable to communicate directly with the lower layers and layer management entities that would be involved in the channel switching.

The resulting architecture puts a new layer between the MAC and LLC to handle the channel management functionality. We are at the moment trying to verify that this can be done in such a way that there are no incompatibility issues with respect to the various headers used by each layer. We will be posting the results of this work as it develops but at present it looks very promising.