1. Efficient Application Level Message Coding and Composition
Students: Ella Cohen & Fanny Nahum
Date:

2. ...In this presentation Introduction to the Application Environment
Safety applications and data
requirements
Desirable architectural
features
Broadcast characteristics
Message Dispatcher
Data element dictionary
Message construction
What and when to send
Presentation Summary

3. Introduction
As we move toward the large-scale deployment of wireless inter-vehicle communication systems, we must consider some real-world implementation issues and tradeoffs.
For example, demands on the wireless channel will evolve as more vehicles become equipped, and new and evolving applications generate new data and transmission requirements.
a standardized communication interface is required!
One of our challenges is deployment of a standard system that efficiently uses the finite wireless medium and yet can support future application requirements.

4. “Standardization can only go so far, because we can’t anticipate all possible future needs.”
(Berners-Lee et al. 2001)

5. Safety applications and data requirements
Significant efforts, have been made to identify which communication-enabled vehicular safety applications will provide the greatest benefit
Eight such applications were identified shown in Table 8.1 along with their proposed communication requirements.
We highlight the fact that these requirements have only been proposed
As a consequence, any communication protocol must be sufficiently flexible to enable changing requirements

6. Eight high-priority vehicular safety applications:

7. Considering Table 8.1, it appears that applications with the greatest safety potential rely heavily on single-hop broadcast communication with nearby vehicles and infrastructure
This communication is expected to have devices from various manufacturers implementing distinct applications. Moreover, many vehicles are likely to run multiple safety applications concurrently.
Each application is likely to have different, although overlapping, data element requirements
many safety applications may require the vehicle speed, vehicle location, current turning radius, etc

8. Dedicated short range communications (DSRC)
vehicle
data elements

9. Earlier revisions and problems:
In earlier revisions of the SAE standard (prior to 2006), the messages were all of fixed size, structure, and content.
This approach had the potential to generate packets with redundant data.
Some data in a fixed message might not be used at all, whereas in other cases, individual applications may require a different message
information that changes slowly or infrequently (e.g., windscreen wiper status) need not be sent frequently.

10. Desirable architectural features
Future-proof: Vehicles will broadcast data that is probably valuable for multiple surrounding vehicles with multiple safety applications. However, creating and testing these safety applications is an ongoing effort. Therefore, a scheme must be backward compatible as well as future-proof to newly defined, evolving, or upgraded applications.

11. Flexibility: It seems likely that in the heterogeneous marketplace for vehicles, different vehicles will be running different subsets of safety applications. A scheme should be sufficiently flexible to account for this.

12. Extensible: It is conceivable that not all safety applications will be universally standardized. Hence, a mechanism for adding support for non-standardized data elements (e.g. proprietary to one or more manufacturers) is desirable

13. Unified interface: From an implementation perspective, it is attractive to construct an architecture where policy and self-policing between various applications, within a single vehicle, can be managed in a single entity. Further, authentication and other security primitives would ideally be managed collectively across safety applications.

14. Layered architecture: By providing a layered architecture that abstracts the message sending interface from the application designer, a separation of concerns for the application designer is achieved. This enables easier, faster and more modular development.

15. Low bandwidth usage: The available bandwidth is a finite resource and should be conserved wherever possible. Real-world testing by the VSCC (USDOT 2006) demonstrates that the channel capacity is an issue that will need to be addressed for large-scale deployment and in heavy traffic environments.

16. Information rate: Some data elements, such as headlight status, change infrequently.Thus, a solution should distinguish these properties and transmit information only when it is appropriate.

17. Recognize vehicle capabilities: Not all vehicles will be able (or willing) to measure and transmit certain pieces of information. This should be reflected in the message construction.

18. Enable product differentiation: Vehicle manufacturers desire the ability to provide unique applications and services to their customers. The functionality of these services should not be limited to the applications that are currently deployed or enabled by other vendors.

19. Broadcast characteristics:
Maximum transmission range of 300 meters.
We assume that safety messages broadcast their messages in a single hop.
Messages will contain data elements useful to multiple vehicles in the nearby vicinity.

20. The problems:
The immediate neighbours of a vehicle will change frequently.
Coordinating transmission between vehicles will be difficult.
Packet interference and loss seem likely.

21. A solution proposal:
Message dispatcher architecture

22. General Description: sending message:
The message dispatcher assimilates data requirements from all the on-board applications.
Compiles a single message using a dictionary of defined data elements
Standardized message construction guidelines.

24. General Description - Cont.
Receiving message:
A receiving message dispatcher is responsible for separating the data elements from the received message.
Disseminating data elements from the received message to all on-board applications.
Managing data requirements for surrounding vehicles.

26. Message Dispatcher - Let’s get down to the details:

27. Message Dispatcher - Let’s get down to the details:
The Message Dispatcher’s responsibility is to coordinate all the data exchange requirements of the applications running on a vehicle.
Serving as an interface between the application layer and the communication stack.
Safety applications will register or send data elements to be broadcast to the MD.

28. Message Dispatcher - Cont.
The MD then summarizes these data elements across applications and creates a single packet comprising the minimum set of the data elements to be transmitted.
The MD would also consider data requirements of other surrounding vehicles or roadside units.
The combined message is then sent to the DSRC radio for broadcast.

29. Message Dispatcher - Cont.
Any vehicle that receives a message would provide all on-board applications with the data elements they require.
The message dispatcher design can be divided into two broad topics:
First, the definition of a data element dictionary.
Second, the specification of how these elements should be combined into a message.

30. Data element dictionary

31. Data element dictionary
This section describes how data elements may be identified and formatted in a ‘data element dictionary’.

32. Data element dictionary – Cont.
A message can be constructed by creating a string of unique identifiers followed by the value of the data element.
This unique ID overhead can be reduced when related data elements are grouped into a ‘data frame’.
Each data frame consists of data elements in a specified order and thus their unique IDs are not required within the data frame.

33. Data element dictionary – Cont.
The SAE standard (SAE 2008) identifies over 150 data elements in its dictionary.
Adding or modifying a data element under this architecture is relatively straight- forward.
The data dictionary would need to be updated and resubmitted to a central authority for updating the standard.

34. Message construction
The process for constructing a message amounts to including data elements and frames prefixed by their unique identifier.
A receiving MD can interpret this message based on the contents of its own data dictionary.
The definition of an escape
character can indicate the start
of a data element.

35. Message construction – Cont.
The escape character will immediately be followed by a unique tag, of fixed length, that identifies the subsequent data.
The SAE standard (SAE 2008) divides messages into two sections:
The first section is used to include data frames using their unique identifier followed by the series of data elements comprising the data frame.
The second section is used to include individual data elements that have not already been included in the first section.

36. What and when to send

37. What and when to send
Determining what elements are required to be sent by a vehicle in order to satisfy surrounding vehicles is a general problem in all mobile ad- hoc networks.
There has been no robust methods proposed to obtain specific information from a newly encountered vehicle.
Sending a large packet, comprising all defined data elements, at the maximum required rate among all elements is very inefficient.

38. What and when to send – Cont.
We propose two possible solutions so as to illustrate the utility of the MD architecture:
Match received message: If a message dispatcher receives a message with a data element it is not currently transmitting, it should include its own version of that data element in the following transmission. In this way it ‘matches’ the incoming message. To avoid a ‘racing’ situation, the original sender could include a data element indicating whether its message contents should be matched.

39. What and when to send – Cont.
What is a ‘racing’ situation?
Vehicle A sends a message that the message dispatcher on vehicle B matches on subsequent transmissions. Although Vehicle C is beyond the range of interest of vehicle A, it too begins to match the message resulting in a ‘racing’ condition.

40. What and when to send – Cont.
Request data elements: Define and send a Data Element that specifically requests certain elements. This solution would be useful in probe-type applications where a roadside unit requests information from passing vehicles.

41. Thanks for listening