Requirements Analysis of IP and MAC Protocols for Dedicated Short Range Communications (DSRC)

Transcription

1 Requirements Analysis of IP and MAC Protocols for Dedicated Short Range Communications (DSRC) James T. Yu, School of Computer Science, Telecommunications, and Information Systems DePaul University ABSTRACT This paper presents an analysis of the technical requirements for Internet Protocol (IP) and Medium Access Control (MAC) protocol to support Dedicated Short Range Communications (DSRC) which is a critical element of the Intelligent Transportation System (ITS). This study classifies the DSRC applications into four categories: unicast vehicle-to-vehicle, unicast roadside-to-vehicle, broadcast vehicle-to-vehicle, and broadcast roadside-to-vehicle. A detailed message flow diagram is developed for each category. This paper also analyzes various optional procedures in the standard where these procedures should be considered requirements in DSRC. A major contribution of this study is to introduce a new feature, bridging with layer-3 forwarding, to support multi-hop DSRC communications.. 1 Introduction Intelligent Transportation System (ITS) involves applying advanced information, networking, and other technologies to improve the economic and safety of the transportation system [1][2], which includes, but not limited to highways, railroads, and rural/urban/suburban roads. The foundation of ITS is a communication system for real-time information gathering and analysis where such a system shall use radio frequency (RF) for wireless communications. This paper discusses the technical requirements of a new wireless standard, Dedicated Short Range Communications (DSRC), and its applications in supporting ITS. In recognition of this need, Federal Communication Commission (FCC) allocated 75 MHz spectrum in the 5.9GHz band for DSRC in 1998 [3], which is above the Unlicensed National Information Infrastructure (UNII) band used by the IEEE a standard [4] GHz UNII lower band (4 channels) a GHz UNII mid-band (4 channels) GHz UNII upper band (4 channels) GHz DSRC (7 channels) Figure 1. DSRC Spectrum band This new spectrum is different from the legacy DSRC spectrum as shown in Table 1 [5]. Table 1. Legacy and New DSRC Standards Legacy New Band MHz 5,850-5,925 GHz Spectrum 12 MHz 75 MHz Data Rate 0.5M bps 1-54 Mbps Max Range 100 m 1,000 m Min 500 m 10 m Separation nonoverlapping Channel 1 or 2 7 The DSRC standard supports vehicles with an on-board device (OBD) to communicate with a roadside unit (RSU), or other traveling vehicles. FCC provides several examples of DSRC applications: travelers' alerts, automatic toll collection, traffic congestion detection, emergency dispatch services, and electronic inspection of moving trucks through data transmissions with roadside inspection facilities. We classify these applications into unicast (one sender and one receiver) vs. broadcast (one sender and many receivers) and RSU-to- (R2V) vs. -to- (V2V) as shown in Table 2.

2 Table 2. Examples of DSRC Applications R2V V2V Unicast toll payment, and road side inspection data sharing, paging, and VoIP Broadcast safety message, road service, and travel information emergency and service vehicles In general, DSRC applications should meet the following requirements: 1. Low Latency Real-time information should be received by traveling vehicles or RSU with low or minimum latency. If the latency is too long, the vehicle may be out of the RF range before the communication is complete. 2. High mobility Study has shown that signalto-noise ratio goes up and throughput goes down as traveling speed increases [6]. As a result, applications in a fixed wireless environment may not work properly in a mobile environment. We need to consider the factor of high mobility in DSRC application development. 3. High reliability Information from emergency vehicle or RSU has impact on public safety, so their reception by the traveling vehicle should be guaranteed. The distance and data rate requirements for the DSRC applications are given in Table 3. Table 3. Range and Data Rate Requirements Range Data Rate Toll Payment 30 m 1 Mbps Emergency 1,000 m 6 Mbps Roadside Safety 300 m 18 Mbps Message V2V Private Voice and Data 100 1,000m 6-54M bps In 2001, the DSRC standards writing group, a sub-group of ASTM, selected the IEEE a as the technology for national interoperability of DSRC applications. The extension of the MAC layer for DSRC is currently under the IEEE Project P The protocol architecture of DSRC is given in Figure 2. Note that the applications could be directly over the MAC layer without TCP/UDP or IP. The Robust Header Compression (ROHC), or RFC 3095, is used for voice applications, and not needed for data-only applications. UDP ROHC Applications TCP Figure 2. DSRC Protocol Architecture MAC Overview The IEEE standard [7] is widely used in the Wireless Local Area Network (WLAN), and it is a shared medium (RF channel) environment where all stations compete to access the medium, but only one station can transmit data at a time. If two or more stations try to send the data at the same time, collision would occur and data is lost. In the wired world (as specified in [8]), a station can detect collision signals and run a back-off algorithm to address the collision problem. In WLAN, collision is like noise, and stations cannot distinguish collisions from other noise. As a result, the standard adopts the method of Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) and provides two access methods, Distributed Coordination Function (DCF) and Point Coordination Function (PCF). DCF is a required procedure of the standard. In the DCF scheme, all stations content for the medium. If the medium is busy, each station runs a back-off algorithm to avoid collisions. PCF is an optional procedure of the standard. In the PCF scheme, there is a central Point Coordinator (PC). The PC sends a beacon message to inform all stations to stop their DCF activities. The PC then polls each station for data transmission. During this Contention Free Period (CFP), stations are not allowed for data transmission until they are polled. The PCF scheme is similar to the token ring protocol [9][10], and is more effective in supporting real-time DSRC applications. The standard provides an optional handshaking procedure which uses two control messages, Request to Send (RTS) and Clear to Send (CTS). A station first sends an RTS IP MAC MAC Extension (802.11) (P1609.4) PHY MAC (5.9G (802.11) Hz) PHY (5.9G Hz)

3 message to the receiver which responds back with a CTS message. After the handshaking procedure, the sender starts data transmission. This RTS/CTS procedure adds overhead to the communication and yields poorer performance than the basic DCF procedure [15]. However, it is needed in two cases: high contention and hidden station environments. The V2V communication on highway has a linear network topology, and the hidden station problem is common as illustrated in Figure 3 [11]. A B C Figure 3. Hidden Station Problem In this example, A could not sense the activity of C which does not see A either. When both vehicles try to send data to B, it causes frame collision and data is lost. The solution to this problem is the RTS/CTS handshaking procedure. When B responds back to A with CTS, C also sees the CTS which contains a timer for C to hold its activity. Because of the linear topology of traveling vehicles on the highway, the RTS/CTS procedure is needed for V2V applications. The standard supports two operation modes: ad hoc and infrastructure. The ad hoc mode is used for direct connection among a group of wireless stations. The infrastructure mode requires the use of a wireless access point (WAP) which is a layer-2 bridge device to forward frames between wireless stations and wired LAN. The operation of the infrastructure mode requires four MAC address fields, instead of two address fields in The following three communication scenarios show how to use these four address fields (A1, A2, A3, and A4). a. A (WS) => B (WS) (ad hoc mode) b. A => W1 => B (one WAP) c. A => W2 => W3 => B (multiple WAPs) Table Addressing Schemes Scenario A1 A2 A3 A4 a B A BSS- --- ID b (A=>W1) W1 A B -- b (W1=>B) B W1 A --- c (A=>W2) W2 A B --- c (W2=>W3) W3 W2 B A c (W3=>B) B W3 A --- Scenario-a is an ad hoc operation for V2V communications. Scenario-b is an infrastructure operation where W1 is a WAP. In general, an RSU operates as a WAP which provides the layer 2 bridging function between vehicles and roadside information servers. In the current practice, a wireless station is manually configured in ad hoc or infrastructure mode, but not both. This practice is not practical for DSRC because a vehicle needs to operate in both ad hoc mode (V2V applications) and infrastructure mode (R2V applications). To address this issue, we propose a new procedure for the switch-over of the operation modes. An OBD, by default, operates in the ad hoc mode. RSU sends a beacon message periodically which contains Target Beacon Transmission Time (TBTT). When an OBD receives the beacon message, the OBD shall switch to the infrastructure mode and starts its Network Allocation Vector (NAV) as specified by TBTT. During the NAV, the station stops its own activities unless it is polled by RSU. After NAV, the OBU switches back to the ad hoc mode. Scenario-c has a complex addressing scheme and the devices in the middle (W2 and W3) are usually called wireless bridge or wireless repeater to distinguish themselves from the low cost WAP. We identify a critical issue with supporting Scenario-c in the mobile environment. If an OBD functions as a wireless bridge (scenario-c), it could dynamically create a layer-2 loop with other OBDs within the RF range. This layer-2 loop causes broadcast storms and floods the network with duplicate messages. In the wired environment, this issue is addressed by the Spanning Tree Algorithm and Protocol (STP) [12], while STP is not supported in yet. Therefore, Scenario-c cannot be supported in DSRC.

4 3 Requirement Analysis The major categories of DSRC applications are given in Table 2. This section presents detailed technical requirements for each category of DSRC applications. 3.1 Highway Toll Highway toll is a R2V unicast application. The requirement is to send vehicle identification to the toll booth and charge the toll to the vehicle account. Because of the financial implication, it requires a security mechanism to protect vehicle identification. The Wired Equivalent Privacy (WEP) of the current uses private (shared) key and is considered too weak for this application. The new i standard which is based on 802.1X [13] and advanced encryption protocols is too complex. Our proposal is to use public key (a.k.a. key pair) to encrypt vehicle identification. The use of public key can be summarized as follows: G[ F(V.ID + Public key) + Private key] = V.ID where F is an encryption algorithm and G is a decryption algorithm. A vehicle receives the public key from the security server at the toll booth, and uses it to encrypt the message of vehicle account information. When the security server receives the encrypted message, it uses the private key to decrypt the vehicle account information. As discussed earlier, R2V should operate with PCF, instead of DCF, for communication between vehicles and the toll access point (AP). The AP periodically sends the beacon message to start the contention free period (CFP). When a vehicle receives the beacon message, it stops its DCF activities immediately, and sends an association message to the AP. Note that it is possible to have multiple vehicles send association messages to the AP which uses a polling algorithm to respond to each association request. The detailed message flow diagram is illustrated in Figure 4. We should note that the beacon message for the toll application is not the same as the current PCF beacon (type=00 and subtype=1000). Beacon, in the context of this paper, represents the start of a Contention Free Period (CFP) where vehicles should stop their DCF activities immediately. Beacons for different DSRC applications should use different codes for type and subtype. Signal Light Pass/fail signal Security Server Access Point beacon association request association response (security key) encrypted vehicle identification ACK disassociation Figure 4. Message Flow for Highway Toll In this toll application, a vehicle may continue receiving the beacon message after completing the transaction. In this case, the OBD still needs to stop its activity for the duration specified by the beacon timer to avoid collisions, but the OBD does not need to send an association message. Our lab experiment shows that the latency of is approximately one ms for small messages (up to 128 bytes), and this latency is about the same for a, b, and g. Based on this data, we estimate that the complete message flow of Figure 4 would take no more than 10 ms. The PCF interval for each vehicle could be set at 25 ms to protect frame loss due to collision or noise. When a vehicle travels at 100km/hour toward a toll booth with an RF range of 30m, the message flow should be completed in one second: 30 m 100 km/hour 1 sec For the distance span of 30m, there should be no more than 3 vehicles. As a result, we could conservatively engineer 5 time slots for PCF per second where each time slot is 25 ms. This engineering rule sets the interval between beacons at 200 ms, and it would have little impact (in terms of spectrum utilization) on other DSRC applications. Another important note of the proposed mechanism is that this application does not need an IP layer. Another unicast R2V application is automatic inspection of moving trucks through data transmissions with RSU. The message flow is similar to the highway toll except that a truck needs to transmit more information to the RSU.

5 3.2 Safety Message and Travel Information This application of safety message transmission requires a Roadside Unit (RSU) functioning as an information server which sends broadcast information to incoming vehicles. This information could be weather, road sign, road warning, traffic congestion report, and/or other information of interest to drivers. Because of the characteristics of the broadcast messages, the vehicle does not need a handshaking procedure and there is no need for association either. However, the vehicle must stop its own activity to avoid collisions with the broadcast data. Another important note is that these broadcast messages are for the vehicle itself and not to be forwarded. If the destination MAC address is FF-FF-FF-FF-FF-FF, this broadcast message would be forwarded by any device functioning as a layer-2 bridge (such as WAP). In order to prevent the forwarding of such broadcast messages, we propose to use the reserved Universal Address (a.k.a. Bridge Group Address) [14], and this group of addresses has the format of C2-XX-XX-XX. When an OBD receives a MAC frame with this address, the OBD accepts the frame and sends it to upper layer. Another requirement is an UDP socket server on OBD. This socket server is always on and waiting for incoming information messages. We need a standard destination port number (e.g., UDP=555) for the vehicle to receive broadcast messages. The addresses of the broadcast message and the message flow diagram are given in Figure 5. DA: C2-XX-XX-XX DA (IP): UDP Dst. Port = XXXX Information server Access Point Broadcast Information SA: (MAC) SA (IP): Safety or Travel Information beacon ACK (optional) Figure 5. Message Flow of Safety Information When an OBD receives the beacon message, it should stop its own activity immediately and wait for the broadcast message. The ACK from the vehicle is an optional procedure which could be required by the law to confirm the reception of the safety information. The message flow is expected to complete in 5 ms. Because the RF detection range is up to 300m, the time window for a vehicle to get the safety message is up to 10 seconds. If we engineer the information server to broadcast the message at a one-second interval, a vehicle would receive this safety message 10 times and its reception is almost guaranteed. Unlike the toll application, a vehicle should continue displaying the broadcast message to remind the driver for highway safety. Because of the long interval between beacons and the short interval for the message flow, this application has even less interference to other DSRC applications than the toll application. 3.3 Emergency and Service The application of emergency or service vehicles is also a broadcast service which informs other vehicles of their arrival. Emergency vehicle may travel at a very high speed and is coming from behind. Service vehicle may travel at a very low speed and is in the front. The message flow for both applications is similar to RSU except for the following two differences: An emergency vehicle operates in the ad hoc mode, instead of the infrastructure mode. Therefore, a vehicle does not need to change its operation mod when receives a beacon message from an emergency vehicle. The interval between beacons should be shorter than the RSU application because of a higher probability of lost beacons. Emergency beacon Safety Information (broadcast message) ACK (optional) Figure 6. Message Flow of Emergency As discussed earlier, the concept of beacon is to initiate a contention free communication service, and it is not limited to PCF. Different

6 DSRC services will have different beacon messages and use different codes for the type and subtype fields in the MAC frame. 3.4 Private V2V Communications There are various V2V applications. One example is the replacement of CB radio with VoIP. Network gaming is another potential V2V application. The V2V scenarios are covered in the following diagram: Figure 7. V2V Scenarios Each box in Figure 7 represents a traveling vehicle, and the dotted line represents an effective RF channel between two vehicles. As discussed earlier, V2V operates in the ad hoc mode. In this example A can reach C & D, but cannot reach E & F due to the RF range. The current standard is sufficient to support direct V2V communications. Security is required for unicast applications, and the current WEP is considered acceptable for personal applications. Business applications should use a stronger security mechanism, such as Temporal Key Integrity Protocol (TKIP) or Advanced Encryption Protocol (AEP). 3.5 Extension of V2V We also studied how to expand the V2V application where a vehicle is served as a bridge to extend the communication distance. This multi-hop application was considered in another paper [16] but there was no detailed study on it. If OBD of -C (see Figure 7) can be configured as a WAP, s A & B could communicate with s E & F. However, our analysis shows that an OBD cannot and should not be dynamically configured as a WAP for the following reasons: o A B C D When WAP is present, the operation mode changes from ad hoc to infrastructure. It is too much overhead for a vehicle to continuously monitor its neighboring vehicles to determine when to use the ad hoc mode and when to use the infrastructure mode. E F o When operating in the infrastructure mode, an OBD can associate with only one WAP. Given that multiple vehicles could function as a WAP, it would be very confusing for an OBD to select a WAP in real-time. In the standard, the selection of WAP is a manual process and is not supported with a dynamic procedure. o Address Resolution Protocol (ARP) could also be an issue as it involves broadcast messages. When multiple OBDs could forward the same broadcast message, it could easily create a broadcast storm and congest the whole network. Although the standard does not support the bridging capability between vehicles, we identify a new feature in Windows XP, called bridging with layer3 forwarding (L3F). In this case, all OBUs are operating in the ad hoc mode, and each OBU maintains a L3F table. A vehicle periodically sends a control messages to inform its neighboring vehicles of its IP and MAC addresses. This control message also uses the reserved Universal MAC Address: C2- XX-XX so that a receiver knows the message is to update its L3F table only. If an entry is not referenced after the specified timer (say 3 min), the entry is removed from the L3F table. The L3F tables of OBD-A and OBD-C are given below: Table 5. L3F Table of OBD-A ( A) IP address MAC address BSSID Timer IP-B MAC-B xxxx 3 min IP-C MAC-C xxxx 3 min IP-D MAC-D xxxx 3 min Table 6. L3F Table of OBD-C ( C) IP address MAC address BSSID Timer IP-A MAC-A xxxx 3 min IP-B MAC-B xxxx 3 min IP-D MAC-D xxxx 3 min IP-E MAC-E xxxx 3 min IP-F MAC-F xxxx 3 min When OBD-A ( A) needs to communicate with OBD-F ( F), it first sends an ARP request. Both OBD-C and OBD- D receive the ARP request, and their L3F tables have the destination IP address. As a result, both respond with their own MAC address back to OBD-A, but only one entry (say OBD-C) is recorded in the ARP table of OBD-A. OBD-A then sends the data frame using the MAC address of OBD-C.

7 A1 A2 A3 A4 DA: OBD-C SA: OBD-A BSSID not used When this frame arrives at OBD-C, it checks the destination IP address with the L3F table and then replaces DA with the MAC address of OBD-F and SA with its own MAC address. The source and destination IP addresses stay the same. OBD-C then forwards this frame to OBD- F via the wireless medium. A1 A2 A3 A4 DA: OBD-F SA: OBD-C BSSID not used OBD-F accepts this frame and knows it is from OBD-A because the source IP address is from OBD-A. When F moves within the RF range of A, its control message (from F to A) will update A s ARP table. With the update, OBD-C does not provide the L3F function for A or F any more. We conducted extensive functional and performance tests of bridging with L3F at our wireless lab. The results meet our expectation, and the performance (latency and throughput) is comparable to that of layer-2 forwarding. 4 Conclusions This paper presents four categories of DSRC applications: unicast R2V, unicast V2V, broadcast R2V, and broadcast V2V. Each category of applications has unique IP and MAC requirements as illustrated by a message flow diagram. A major contribution of this paper is to identify a new feature, bridging with layer-3 forwarding, to extend the communication distance in a wireless environment. This feature is available in the Windows XP operating system and can be easily ported to OBD to support the V2V applications. In this paper, we consider each OBD operates in a single RF channel. In theory, an OBD could operate in multiple frequency channels and support more than one application simultaneously. The use of multiple RF channels in DSRC is another topic of our further study and research. [2] B. Abdulhai, ITGS, Eh! Meet Canada s Flagship ITS Centre and Testbed, IEEE Intelligent Systems, January 2003, pp [3] FCC Engineering and Technology News, Report No. ET 98-7, July 11, 1998 [4] Wireless LAN Specifications for High- Speed Physical Layer in the 5GHz Band, IEEE a [5] Home/ General Info/DSR General What is.htm [6] J. P. Singh, et. al. Wireless LAN Performance under Varied Stress Conditions in Vehicular Traffic Scenarios, IEEE VTC, Fall 2002 [7] Wireless LAN MAC and PHY Specifications, IEEE [8] CASA/CD Access Method and Physical Layer Specifications, IEEE [9] Token Ring Access Method and PHY Specifications,: IEEE [10] Duke Lee, et. al., A Wireless Token Ring Protocol for Intelligent Transportation Systems. The 4 th IEEE International Conference on Intelligent Transportation Systems, August, [11] Ting-Chao Hou, et. al., Transmission Behavior of IEEE WLAN Stations in String Topologies, the 2004 International Conference on Wireless Networks, June 2004 [12] MAC Bridges, IEEE 802.1D [13] Port-Based Network Access Control, IEEE 802.1X i (WLAN security) is still a draft standard. [14] MAC Bridges, IEEE 802.1D-1998, Table 7-9, p. 52 [15] G. Bianchi, Performance Analysis of the IEEE Distributed Coordination Function, IEEE ISAC, vol. 18, no. 3, March [16] J. Zhou and S. Roy, MAC for Dedicated Short Range Communications in Intelligent Transport System, IEEE Communications, December 2003, pp REFERENCES [1] F-Y Wang, et. al. The VISTA Project and Its Applications, IEEE Intelligent Systems, November 2002, pp