WSA and Service Initiation Decision Making

1. WSA and Service Initiation Decision Making Daniel Jiang Mercedes-Benz Research & Development North America, Inc. Palo Alto, CA June 23rd, 2009

2. Potential problem with WSA and service initiation process • General model of providing DSRC services • Service provider advertises its presence and list of services • Recipient of advertisement goes to the corresponding service channel to start services if desired • But what if an OBU receives such an advertisement outside of its effective coverage area? • If it starts service initiation, the service quality/success would be problematic • It could also negatively impact its safety communications while doing so Possible WSA reception area Coverage area Reception probability is non-trivial even at long distances

3. Current approach/thinking in IEEE 1609 • Current approach centers on service link quality assessment as a basis for service initiation decision • For example: one would consider starting of a service only if it successfully receive 5 WSAs in a row or the signal quality of the received WSAs are consistently good • However, • It necessarily increases the WSA frequency than needed for advertisement only (e.g., 1Hz) • It measures link quality of CCH rather than SCH • It strongly ties WSA to DSRC transmissions by actual service provider • It doesn’t work if WSA is sent by a proxy or other communication channel • It is an indirect way and less then optimal way to solve a problem (i.e., it’s a hack)

4. Suggested approach • Just include service provider location information in WSA • Purpose • Using location information for service initiation decision is simple and straightforward • It also enables optimizations based on vehicle path considerations • WSA is really just one form of a POI, and should include its location to be complete • One doesn’t need to depend on receiving WSA directly from the provider anymore I can wait for when I am well inside the coverage I should initiate service now Coverage area

5. Transmission location information is defined and available • transmission_location is defined as a 3DLocationAndConfidence data type and contains • 4 Byte latitude • 4 Byte longitude • 3 Byte elevation and confidence • It is now optional for WSA to include this information • Furthermore, in 1609.2 8.1.2.2 Format of secured WSA • “The Security Footer consists of: The generation_time (if appropriate), expiry_time (if appropriate) and transmission_location fields of the ToBeSignedMessage structure. …”

6. There is still some issue • However, the problem is not completely solved • What about the unsecured WSA? • In 1609.3 8.2 WAVE Service Advertisement (WSA) format: “A WSA consists of either an Unsecured WSA or a Secured WSA.” • Optional inclusion of transmission location means recipients of Unsecured WSA can not depend on such information to help their service initiation decisions • Semantically, transmission_location in security payload serves different purpose than identify service provider location per se • That is: it is meant for applications to figure out how to make use of the location information rather than for security to worry about geographic replay attack

7. Proposal • Mandate inclusion of service provider location in WSA • Remove transmission_location from security footer for Secured WSA • Discourage the usage of persistent and high frequency WSA transmissions for service initiation decision