國
立
交
通
大
學
網路工程研究所
碩
士
論
文
S t r e e t c a s t - 車 用 網 路 街 道 廣 播 協 定
Streetcast: A Broadcast Protocol for Urban Vehicular
Ad-Hoc Networks
研 究 生：葉侯亨
指導教授：曾煜棋 教授
易志偉 教授
車用網路街道廣播協定
學生：葉侯亨
指導教授：曾煜棋 教授
易志偉 教授
國立交通大學
網路工程研究所
摘要
交通工具以及大眾運輸系統已經變成人們日常生活中不可或缺的一部分。 現在市面上已經有許多輔助行車的工具或是行車間娛樂的產品，如：全球定位系 統(GPS) 、無線數位電視…等。然而人們也希望能夠於行車時，藉由網路資源獲 取更多的行車資訊甚至娛樂；加上無線網路設備的進步，無線設備變的功能強大 又便宜，因此，車間網路變成一個熱門的研究題目。智慧型運輸系統(Intelligent Transportation System, ITS)就是利用車間網路所建立的一個行車輔助系統來 提供即時、廣泛以及無接縫的交通資訊，並且給駕駛一個方便以及安全的駕駛環 境。智慧型運輸系統有許多的應用，如：緊急或危險訊息的傳播、即時道路資訊、 地域性服務或廣告…等。其中，以輔助行車安全的緊急或危險訊息的傳播是最為 重要的，而這類型的訊息傳播通常是藉由廣播來達成。因此，設計一個有效率的 多跳廣播機制在車間網路上，是一個重要的課題；特別是在都市區域的廣播，由 於車輛的擁擠，更是面臨許多問題。在本研究中，我們利用多重播送的機制來以 及利用全球定位系統以及電子地圖來輔助廣播，名為街道廣播。藉由多重播送的機制，我們可以保護無線網路頻道以及達到一定的可靠度；藉由全球定位系統以 及電子地圖，我們可以挑有效率的節點來轉播，以及限制訊息的廣播範圍。同時， 我們也設計了動態調整控制封包的傳送機制，能夠有效的減少多餘的控制封包。 最後我們模擬街道廣播以及利用真實的都市道路以及車流量來評估我們的廣播 機制，而模擬的結果顯示出我們所提出的播送協定在不同的網路流量中，也能在 封包傳送率、端點延遲以及碰撞數方面皆擁有良好的效能。 關鍵字：車間網路、廣播、多重播送、全球定位系統、電子地圖、智慧型運輸系 統、緊急訊息、地域性廣播
Streetcast: A Broadcast Protocol for Urban
Vehicular Ad-Hoc Networks
Student：Hou-Heng Yeh Advisors：Prof. Yu-Chee Tseng
Prof. Chih-Wei Yi
Institutes of Network Engineering
National Chiao Tung University
Abstract
Transportation System has become indispensable in our daily life. There are many commodities for driving assistance and entertainment, for example, Globe Position System (GPS), wireless digital TV, etc. Therefore, people expect to get more information or entertainment services from internet while driving. As the wireless devices become dainty and cheap, vehicular ad-hoc networks (VANETs) become a popular research topic. Intelligent Transportation System (ITS) is established to provide real-time, comprehensive and seamless traffic information, and to give a convenient, safe, and efficient driving experience. There are many applications for ITS, for example, emergency message, real-time traffic information and location based services or advertisements, etc. The dissemination of emergency message is one of the most important applications of them, and they are usually disseminated by broadcast. Therefore, it is an important topic to design an efficient multi-hop
broadcast mechanism for vehicular ad-hoc networks, especially in urban areas. Broadcast in the urban area meets more problems than in the rural area because of the high density and high mobility of vehicles. In this work, we use multicast RTS to protect wireless channel and provide reliability. Moreover, we use the Global Position System (GPS) combined with the digital road map information to assist relay node selection. Meanwhile an adaptive beacon control is proposed to reduce control redundancy. At last, we evaluate our broadcast protocol in the real road map and real traffic flow. The simulation results show that the proposed broadcast protocol has superior performance in terms of packet delivery ratio, end-to-end delay and the number of collisions under different traffic load.
Keywords：VANETs, global positioning system, broadcast, multicast, digital road
誌 謝
首先感謝曾煜棋教授以及易志偉兩位教授，在他們悉心的指導下，不僅使我 在學業和研究上受益匪淺，也在為人處事方面受到提點、給予良好的建議；此外 我也感謝莊宜達學長，因為他的協助，使本論文能夠更嚴謹完整。 我還要感謝實驗室的同學，以及學長、學弟們兩年來在學術上的砥礪與陪 伴。我們一起努力合作完成的大大小小計畫與作業，讓我的兩年研究生活過的既 充實又多彩多姿。 我更要感謝所有關心我的朋友們，因為有你們的支持與關懷，我才能克服種 種嚴苛的問題與困難，並從這些經驗中學習、成長。謝謝大家，因為有你們的鼓 勵，讓我變得更成熟、懂事，除了書本上的知識、專業的技能外，還有更多做事 的態度與方法，更重要的是留下了許多美好的回憶。 最後，謹以此文獻給我摯愛的雙親。 葉侯亨 於 國立交通大學網路工程研究所碩士班 中華民國九十八年六月Contents
1 Introduction 1
1.1 Vehicular Ad Hoc Networks . . . 2
1.2 Motivation . . . 3
1.3 Objectives . . . 5
1.4 Organization . . . 5
2 Related Works for MANET 7 2.1 Broadcasting Techniques for MANET . . . 8
2.2 Multiple Request to Send . . . 10
3 Related Works for VANET 13 3.1 Vector based TRAck DEtection Protocol . . . 14
3.2 TLO Broadcast Method . . . 14
3.3 Urban Multi-hop Broadcast . . . 15
3.4 Smart Broadcast . . . 16
3.6 Role-based Multicast . . . 17
4 Streetcast 19 4.1 Multicast-Request to Send . . . 21
4.2 Relay Node Selection and Neighbor Table Establishment . . . 22
4.3 Adaptive Beacon Control . . . 24
5 Simulation Results 29 5.1 Simulator . . . 29
5.2 Evaluated Protocols . . . 29
5.2.1 Random Backoff Flooding . . . 30
5.2.2 Distance-Based Multicast . . . 30
5.2.3 MPRs (Multipoint Relays) . . . 31
5.3 Simulation Parameters . . . 32
5.4 Simulation Results . . . 35
6 Conclusions and Future Work 40 6.1 Conclusions . . . 40
List of Figures
2.1 BMW and BMMM. . . 10
2.2 Illustration of BACK scheme. . . 11
2.3 Multicast RTS time slots. . . 12
3.1 UMB procedure. . . 16
4.1 Streetcast. . . 20
4.2 MRTS frame format. . . 21
4.3 MRTS timeslot. . . 22
4.4 MRTS for VANETs procedure. . . 23
4.5 Neighbor table with road information. . . 25
5.1 Taipei city map. . . 33
5.2 Taipei city map with RSU. . . 34
5.3 Packet generating rate v.s. Packet delivery ratio . . . 36
5.4 Packet generating rate v.s. End-to-end delay . . . 37
List of Tables
Chapter 1
Introduction
As the improvement of wireless technologies, wireless devices become dainty and cheap. Moreover, transportation system has become a part of our daily life. People would like to surfing the internet while driving. Recently, vehicle manufactures and telecommunication industries gear up to equip each vehicle with wireless devices that allow vehicles to commu-nicate with each other as well as with roadside infrastructures in order to enhance driving safety and improve drivers’ driving experiences. Such vehicular communication networks are also referred to as Vehicular Ad Hoc Networks (VANETs).
Intelligent Transportation System (ITS) is established to provide real-time, comprehen-sive and seamless traffic information, and to give a convenient, safe, and efficient driving experience. In general, the information that users concerned can be classified into three categories - beforehand information, real-time information and afterward information. Be-forehand information includes navigation, traffic flows, public transportation system time
table, and parking information, etc. Real-time information includes location based advertise-ments, announceadvertise-ments, emergency messages, and real-time video steaming. As for afterward information, it includes dynamic traffic information and sense various physical quantities re-lated to traffic distribution. These information and functionalities are considered essential for achieving automatic and dynamic information collection and fusion in the Intelligent Transportation System (ITS). ITS have been envisioned to have a great potential to revo-lutionize human’s driving experiences and create a new framework for traffic flow control in metropolitan areas.
1.1
Vehicular Ad Hoc Networks
The Vehicular Ad hoc Network (VANET) is a special form of Mobile Ad hoc Network (MANET). Mobile Ad hoc network, contrary to infrastructure networks, are self-organized network without the aid of any infrastructures. Ad hoc nodes, different from the devices in the traditional wired networks or the infrastructure wireless networks, have mobility and play both as routers and end systems. Further, the topology changes frequently due to the mobility of ad hoc nodes. Two ad hoc nodes can communicate with each other if they are within the transmission range of each other. While two ad hoc nodes are out of the transmission range of each other, they can communicate with each other through the aid of intermediate nodes. Moreover, the ad hoc networks can be formed by itself and has well survivability as comparing to infrastructure wireless networks.
VANETs are constrained by predefined roads, and most of these roads have speed limit. Moreover, the mobility rate is high in VANETs but the movement of direction and speed are predictable. The scale of VANETs is much larger than MANETs, and the topology of VANETs changes more rapidly than MANETs. On the other hand, the constraints for energy loose because of car batteries.
The VANET is used for dedicated short-range communications (DSRCs) and has emerged as preferred network design choice for the quick transportation systems. Federal communi-cations commission has recently allocated 75 MHz in 5.9 GHz band for DSRC. It is used in the vehicle-to-vehicle (V2V) and vehicle-to-roadside unit (V2R) communications. VANETs do not require any investments except wireless network interface. Moreover, it is predicted that the number of telemetics subscribers in the United State will reach more than 15 million by 2009. The VANET will undoubtedly play an important role in next-generation networks.
1.2
Motivation
The VANET is an emerging network for the Intelligent Transportation System. Automobile manufacturers started planning to embed communication devices into their vehicles for safety, comfortable, and entertainment purposes, and emergency, traffic and weather report, and location based services. One of the most important service among them is safety warning message. The safety warning message is useful for driver in hazardous situations, e.g., dangerous road surface conditions, accidents, unexpected fog banks. Such messages are time-sensitive and localized. These messages are disseminated to intended locations through
multi-hop broadcasts. However, the vehicle traffic and network topology for VANETs are continuously changing, and there is still lack of suitable broadcast mechanisms, capable for delivering the messages to meet the requirements. In order to meet these requirements, the design of broadcast protocols should exploit the peculiar features that differentiate VANETs from traditional wireless ad hoc networks.
Broadcast is a frequently used method for most applications running on wireless environ-ments. However, uncontrolled broadcasts will lead to broadcast storm problems [5] which cause severe collisions, packet redundancy and hidden terminal problems. It is difficult to disseminate the messages efficiently in the VANETs, especially for an urban area. Recently, there are many researches working on multi-hop broadcast problems in the VANETs. In [6], authors designed a broadcast protocol which is used in urban regions. In [7] [8], authors improved the Urban Multihop Broadcast protocol [6] in one way scenario. In [9], the authors considered the broadcasting problems in fragmentations and intersections. In [10], authors addressed the design of position based routing solutions for the support of safety oriented applications. In [11] [12], authors used location information to assist broadcast. In [13] authors presented some analyses work on broadcast in dense Vehicular Networks. In [14], authors proposed a VANET-DSRC protocol for reliable safety messages broadcasting. There are still many researches working on VANET broadcast [15] [16] [17] [18] [19]. In order to reduce the broadcast storm problems, authors [6] [8] [20] [10] [16] [16] [17] [14] [18] proposed a relay-point selection mechanism to reduce the broadcast redundancy and collision num-ber significantly. The relay point selection problem is one of the major issues in VANETs
broadcast.
1.3
Objectives
The two main challenges of broadcast are to protect the communication channels, while disseminating messages over the intended regions and keeping the delay time within the requirements of the applications. In the thesis we propose a new MAC broadcast protocol named streetcast to meet the requirements of the applications and reduce the broadcast storm problems for the dynamic topology in VANETs. In our proposed protocol, we can disseminate messages to vehicles over specific region fast and reliable.
In the proposed protocol, we use Multicast RTS mechanism to protect wireless channel, and avoid the collisions, hidden terminal problems. As we use CSMA/CA-like scheme, we can efficiently improve the delay time and reliability of message broadcast in the VANETs. In addition, we use digital road map information and Global Position System (GPS) to assist the relay point selection. With the digital road map and GPS, we can ensure the propagation of the messages by selecting suitable relay points, and control the disseminate region by the coordinate in the messages.
1.4
Organization
The rest of the thesis is organized as follows: In Chapter 2, we present the related work for broadcast in MANETs and multicast RTS mechanism. Chapter 3 gives the related work for
broadcast in VANETs. In Chapter 4, we describe our streetcast algorithm. And in Chapter 5 is the simulation results and analyses. At last, we draw our conclusion and discuss the future works in Chapter 6.
Chapter 2
Related Works for MANET
A mobile ad hoc network (MANET), sometimes called a mobile mesh network, is a self-configuring network of mobile devices connected by wireless links. No fixed infrastructures are included in the configuration of the networks and some nodes in the networks are expected to assist in the routing of packets. Each device in the MANET is free to move independently in any direction, and will therefore change its links to other devices frequently. Each must forward traffic unrelated to its own use, and therefore be a router. The primary challenge in building the MANET is equipping each device to continuously maintain the information required to properly route traffic. Such networks may operate by themselves or may be connected to the larger Internet.
The growth of laptops and 802.11/Wi-Fi wireless networking have made the MANETs a popular research topic since the mid to late 1990s. Many academic papers evaluate protocols and abilities assuming varying degrees of mobility within a bounded space, usually with all
nodes within a few hops of each other and usually with nodes sending data at a constant rate. Different protocols are then evaluated based on the packet drop rate, the overhead introduced by the routing protocol, and other measures.
IEEE 802.11[1] is a widely adapted wireless LAN standard for wireless unicast commu-nication which uses four-way handshakes (RTS/CTS/DATA/ACK) to reduce collisions and hidden terminal problems, and increase reliability for transmissions, However, IEEE 802.11 does not support reliable multicast/broadcast.
2.1
Broadcasting Techniques for MANET
Network wide broadcasting is the process in which one node sends a packet to all other nodes in the network. In another way, broadcasting is often necessary in MANET routing protocols. For example, many unicast routing protocols such as Dynamic Source Routing (DSR), Ad Hoc On Demand Distance Vector (AODV), Zone Routing Protocol (ZPR), and Location Aided Routing (LAR) use broadcasting or derivation of it to establish routes. However, these protocols all rely on a simplistic form of broadcasting called Flooding, in which each node (or all nodes in a localized area) retransmits each received unique packet exactly once. The main problems with Flooding are that it typically causes unproductive and often harmful bandwidth congestion, as well as inefficient use of nodes resources, and cause broadcast storm problems. As the higher dense of networks, these problems will be more serious.
simulations. The broadcasting schemes can be categorized into four categories, including simple flooding, probability based, area based, and neighbor knowledge based.
• Simple flooding means every node received broadcasting packet will rebroadcasting exactly once.
• Probability based schemes can be subdivided into probability schemes and counter-based schemes. The probability scheme is similar to flooding but nodes rebroadcast messages on probability. In general, the probability is proportional to node densities. In the counter-based scheme, rebroadcasting is according to the count of each packet received by nodes.
• In the category of area based method, each node rebroadcasts messages according to it’s coverage area. Area based method can be subdivided into two schemes, distance based schemes and location-based schemes. In the distance based scheme, rebroadcast depends on the distance between source nodes and destination nodes. In the location-based scheme, every node needs know it’s location by some means, e.g., a Global Positioning System (GPS).
• Neighbor knowledge methods need to know neighbor nodes via periodic ”Hello” pack-ets. According to neighbor information, neighbor knowledge based algorithms may apply various rebroadcast heuristics, including flooding with self pruning, scalable broadcast algorithms (SBA), dominate pruning, multipoint relaying, Ad Hoc broadcast protocol and CDS-based broadcast algorithms.
2.2
Multiple Request to Send
Most wireless technologies use the IEEE 802.11standard MAC protocol, but IEEE 802.11 does not support reliable multicast/broadcast. Many researchers use the batch mode mul-ticast for controlling packet exchange to alleviate hidden terminal problems and achieve re-liable transmission [22] [23]. In [22], authors proposed Broadcast Medium Window (BMW) protocol that only adds the reliable broadcast service to the IEEE 802.11. Basically, BMW realizes the reliable broadcast by using a unicast to each of the one-hop neighbors with the RTS/CTS/DATA/ACK scheme. In [23], authors proposed BatchModeMulticast MAC (BMMM) protocol to add the reliable multicast service to the IEEE 802.11. Basically, BMMM introduces n pairs of RTS/CTS frames and n pairs of RAK (Request for ACK)/ACK frames for the reliable transmission of a DATA frame to n receivers, as the shown in Fig 2.1 showed.
Figure 2.1: BMW and BMMM.
In [24], a source broadcast packets are acknowledged by receivers via a bit sequence during a DIFS interval after DATA transmissions. This interval is divided into mini-slots
and each receiver randomly selects a mini-slot to send a bit sequence named BACK as shown in the Fig 2.2. In [2] [3] [25] [4], authors use Multicast-RTS (MRTS) to protect multiple
Figure 2.2: Illustration of BACK scheme.
receivers. A multicast RTS (MRTS) is an one-to-multiple point transmission handshake. With the MRTS mechanism, senders can send packets to multiple receivers simultaneously and without collisions and hidden terminal problems. There is no upper bound for the number of receivers that need to be protected in the MRTS frame. Thus, the MRTS packet is larger than the packet size in 802.11 making the MRTS frame itself prone to collisions due to hidden terminal problems. A sender transmits MRTS frame first and waits to receive CTSs from receivers. The CTSs are sent according to a schedule calculated from the position index of the addresses of the receivers in the MRTS packet. And then, the sender multicasts data packet to the receivers and waits to receive acknowledgments. The acknowledgments are sent according to the sequence order as in the CTSs transmissions. The data packet size increases by the number of the addresses of receivers included in the header. The time slot is illustrated in the Fig 2.3. In [26], authors modify the MRTS frame to include at most four
addresses of the receivers.
Chapter 3
Related Works for VANET
It would be possible to achieve flexible communications amount vehicles and with roadway or infrastructures through VANETs. Multi-hop data dissemination capability is one of the major advantages of VANET. Multi-hop dissemination can be used for transmissions of safety and emergency warning messages, exchanging neighborhood information queries, and relaying data from sources. Most of all, broadcasting is the most fundamental technique to disseminate messages. The primary goal of broadcast in VANETs is to distribute information from the source to destinations in specified regions. Broadcast is a necessity for VANETs not only for forwarding but also for delivering information without constructing a data path. Various broadcast and flooding protocols have been proposed and evaluated in terms of their reliability. Message dissemination using local information e.g. position and direction, and roadway segments, have been widely studied.
significant transmission overhead due to excessive redundancy. To avoid the well-known broadcast storm problem, most of broadcasting protocols developed for VANETs select only a limited number of nodes relaying the broadcasting data. However, almost all broadcasting methods in VANET utilize position information to select the next relay node. We will introduce parts of representative broadcast schemes in the following sections.
3.1
Vector based TRAck DEtection Protocol
Vector-based TRAck DEtection (V-TRADE) [11] is one of the earliest examples of broad-casting in VANETs. A vehicle classifies its neighbors into multiple classes based on the position and the moving direction. A relay node selects one border node for each class and broadcasts a packet with IDs of the border vehicles. The feasibility is limited due to the excessive control overhead to collect neighboring vehicle positioning information including vehicles traveling in the opposite direction.
3.2
TLO Broadcast Method
In [20], authors proposed an algorithm called ”TLO” (The last one) broadcast method. ”TLO” tries to find the most suitable vehicle to rebroadcast messages. This algorithm uses GPS information (Latitude, Longitude) to know vehicle’s position. A source sends alert messages with its position. Finally, a receiver can calculate the distance from the source. Each node has a neighbor table containing the neighbor position information. So that the
node can choose the relay node from the table. TLO algorithm chooses the farthest as the relay node.
3.3
Urban Multi-hop Broadcast
Urban Multi-hop Broadcast (UMB) [6] segments the road in the direction of dissemination and selects a relay node in the farthest segment by RTB/CTB handshakes. The procedure of directional broadcast is described as follows. A source broadcast a RTB (Request to Broadcast) with it’s position to its neighbors. When nodes receive RTB, they calculate the distance from the source and reply the Black-Burst. The length of Black-Burst, L, is computed as follows:
L = ¹
d
Range ∗ max Slot º
∗ SlotT ime (3.1) where d is the distance between the source and the vehicle, Range is the transmission range, max Slot is the number of segments created, and SlotT ime is the length of one slot. Each node sends the black-burst in the shortest possible time. At the end of the black-burst, it turns around and listen to the channel. If it finds the channel clear, that means the black-burst was the longest and it is now responsible to reply with a CTB (Clear to Broadcast) packet. If it finds the channel busy, that means there are some other vehicles further than it and it does not try to send a CTB packet. When the source get the CTB packet, it broadcasts DATA and waits for ACK from the node who transmits the CTB packet. The RTB/CTB/ACK handshakes provide clear wireless channel, avoid collisions and reliability for broadcasting, and UMB ensures the farthest node be the relay node. The procedure is
show in the Fig 3.1. However, the black-burst is a waste for wireless channel and power, and
Figure 3.1: UMB procedure.
the time of handshakes in RTB/CTB is not efficient enough. Another disadvantage of UMB is that it uses repeating broadcast at intersection resulting in bandwidth waste.
3.4
Smart Broadcast
Smart Broadcast (SB) [8] is similar to UMB, but without considerations for the intersection case. The major difference of SB is that it assigns contention windows based on the position of vehicles relative to a source. The source broadcasts a RTB message first, and then each receiver calculates its distance from the source and decides what sector it belongs to. The sector is split by fixed distance. Nodes in the same sector has the same contention window size, and the further sector gains the shorter time to finish the contention. As a result, the further receiver replies the RTB faster. Moreover, the message propagation time is shorter in SB as compared to UMB, especially when the network is dense. The disadvantages of SB are that it must waste the contention time in propagation, and it only considers the single
direction situation.
3.5
Multi-Hop Vehicular Broadcast
Mariyasagayam et al. [19] proposed enhanced Multi-Hop Vehicular Broadcast (MHVB) protocol which is another position-based flooding scheme. MHVB defines a backfire area and if a node is in the backfire area, it does not relay the broadcast packet. A receiver calculates the distance between the source and itself, and if the distance is farther than the threshold Dmax, the vehicle does not perform the following procedure. The waiting time
before retransmission is calculated based on the distance from the source. Consequently, a vehicle with farther distance to the source waits less time and rebroadcast the packet sooner than the vehicles closer to the source. If the vehicle receives the same packet more than once, it calculates the relative positions of the sender against to itself. If the vehicle locates in the circle formed by the source and the relay node, it cancels the rebroadcast for the packet.
3.6
Role-based Multicast
Role-based Multicast is proposed in [27], which is a form of flooding. Each node rebroadcasts received packets actually once. They rebroadcast the packets after W T (waiting time) as computed by following:
W T = (− ¹
d
Range ∗ max Slot º
where max Slot is the maximum possible number of slots a node waits before forwarding the packet, and d is the distance between the source and the receiver, Range is the transmission range. The waiting time aims the furthest node to broadcast the packet first. As in IEEE 802.11 standard, nodes decrease their waiting time counter when they find the channel clear and freeze them when channel is busy.
Chapter 4
Streetcast
Because of highly suffering from high mobility of vehicles which results in dynamic change of topology in the VANETs, one can not use conventional broadcasting schemes as applied in the MANETs. For flooding-based broadcast mechanisms, they don’t protect wireless channels, resulting in severe collisions and packet loses and low reliability. As for distance based broadcast mechanisms, they use RTB-CTB handshake to protect the wireless chan-nels and use ACKs to ensure reliability. But they need to repeat the handshake procedures at intersection. Which causes data redundancy, and the transmission latency. Streetcast is a broadcast protocol for VANETs which comprises of three components: MRTS, relay points selection and beacon control. Each nodes periodically broadcasts ”Hello” beacons which include neighbor information. The hello beacons are used for one-hop neighbor table construction. We use MRTS mechanism to protect the wireless channels, and digital road map information combined with one-hop neighbor to select relay points for reducing data
redundancy. Meanwhile, the beacon control mechanism can dynamically adjust beacon in-terval to reduce control redundancy. As Fig 4.1 shows, RSU can pick up relay nodes from its one-hop neighbors and disseminate packets over specified road segment. The selected OBUs upon receiving messages disseminate packets to forward direction. The selected OBUs will reply ACKs to ensure the reliability.
4.1
Multicast-Request to Send
In the streetcast, we use multicast RTS (MRTS) to protect the wireless channels for relay nodes. The MRTSs and CTSs frames are used for avoiding collisions and hidden terminal problems, and ACKs are used for reliable transmission. Figure 4.2 illustrates the MRTS frame format. And we fix the number of receiver addresses in the MRTS frame to at most four as in [26], to reduce the collisions and the overhead. MRTS frame contains addresses of all relay nodes.
Figure 4.2: MRTS frame format.
The procedure of MRTS mechanism consists of MRTS, scheduled CTSs, broadcasting DATA, and scheduled ACKs. A source puts the addresses of the relay nodes in the MRTS frame and multicast it to the relay nodes. Nodes receiving the MRTS frame set the NAV (network allocation vector) if they are not the relay nodes. Only the relay nodes reply CTSs to the source in the order according to the sequence in the MRTS frame. The node in Ra1 replies first, then Ra2, Ra3, Ra4. Whenever the source gets any CTSs ,it broadcasts DATA to nodes in the transmission rage. The relay nodes send ACKs to the source with the same
sequence order as in the transmission of CTS after receiving the DATA. The detail time slots for MRTS procedure is shown in Fig 4.3.
Figure 4.3: MRTS timeslot.
The transmission may fail due to lose of CTSs or ACKs. According to the number of received ACKs, a source can decide whether the transmission is success or not, and re-initiate the MRTS procedure. If the fail transmission is due to zero CTS, the source will also re-initiate the MRTS procedure. Figure 4.4 illustrates the detail procedure.
4.2
Relay Node Selection and Neighbor Table
Estab-lishment
In today people equip GPS (Globe Position System) and digital road map navigation system in their vehicles. We make use of coordinates of vehicles obtained from GPS and digital road map information for multiple relay node selections. OBU and RSU maintains a neighbor table. The RSU maintains a neighbor list for each road direction in its neighbor table, and
the OBU only maintains two neighbor lists - forward and backward directions in its neighbor table. Each node in VANETs periodically broadcasts ”Hello” beacons which includes the node’s ID, location and time stamp to their neighbors. When a node receives a ”Hello” beacon, it checks the digital road map and update the neighbor information in the beacon to the corresponding neighbor list and deletes the neighbor if it does not receive a beacon from the neighbor for a ”Hello” life time. For example, in Fig 4.5, RSU A maintains a neighbor table including four neighbor lists for ROAD A, ROAD B, ROAD C and ROAD D. OBU B only maintains forward and backward neighbor lists in the neighbor table for ROAD C. When RSU A receives a beacon from OBU A, it looks up the digital road map for the road segment where OBU A resides in, and find out that OBU A is on the ROAD B, then add OBU A to the neighbor list of ROAD B. Similarly, when OBU B receives a beacon from OBU C’s, it then adds OBU C to the neighbor list of ROAD C - forward.
If there is a data message needed to be broadcasted, a node picks from a neighbor from the neighbor table list with the optimal distance as the relay node for each direction. The optimal distance (Dopt) is conducted in [28]. Note that node deletes the neighbor which is
selected as relay node in neighbor table. When transmission fails, nodes won’t select these bad neighbors as relay nodes again.
4.3
Adaptive Beacon Control
In urban areas, there are thousands of vehicles moving across the intersection in fifteen min-utes, according to the statistic of the Traffic Engineering Office of Taipei City Government.
If each vehicle keeps broadcasting ”Hello” beacon excessively, it will cause numbers of colli-sions and failure transmiscolli-sions. We therefore propose a beacon control mechanism to adjust beacon generation rate.
As we need enough number of neighbors in each neighbor list to select a relay node for each road direction. We derive the expected number of neighbors for each road direction, and then calculate the expected distance for the neighbor with the longest distance close to Dopt. Now, we only consider the single direction case. Suppose that there are α neighbors
sending ”Hello” to a node within the ”Hello” life time, and their distance to the node is (X1, X2, ..., Xα). Note that, we assume l be the one with the farthest distance among those
neighbors and R be the transmission range of nodes. Let F (l) be the CDF for the probability of the event that all neighbors are within the range l.
F (l) = Pr [all neighbors are within the range l] = Pr [X1 ≤ l, X2 ≤ l, ..., Xα ≤ l] = Qα i=1 Pr(Xi ≤ l) = (l R)α (4.1)
The PDF, f (l), can be obtained by differentiating the CDF, F (l), as shown in eq. (4.2). We can obtain the formulate for the expected value of l, E(l) eq. (4.3).
f (l) = d dlF (l) = α( l R) α−1· 1 R (4.2)
E(l) =RR 0 l · f (l)dl =RR 0 l¡F (l)0¢dl = lF (l) |R 0 − R R 0 F (l) dl = l¡l R ¢α |R 0 − R R 0 ¡l R ¢α dl = Rα+1 Rα −α+11 l α+1 Rα |R0 = Rα+1 Rα −α+11 R α+1 Rα = Rα+1 Rα ¡ 1 − 1 α+1 ¢ = R α α+1 (4.3)
To obtain the expected number of neighbors, α, we substitute the value of E (l) with Dopt in eq. (4.3). Finally, we can obtain the value of α as shown in eq.(4.4).
Dopt= α+1Rα Dopt· α + Dopt = Rα Rα − Dopt· α = Dopt α (R − Dopt) = Dopt α = R−E(l)E(l) (4.4)
Each vehicle broadcasts beacons according to the number of neighbors, N. If the number of neighbors in the list for each direction below a threshold α, it broadcasts a ”Hello” beacon by fixed time interval. Otherwise, it broadcasts the ”Hello” beacon according to the beacon generation probability P by eq. (4.5), where r is a adaptive threshold. The more number of neighbors has the lower probability for broadcasting ”Hello” beacons.
p = (100 − N × r)% , N × r ≤ 100 0 , otherwise (4.5)
Chapter 5
Simulation Results
5.1
Simulator
In order to evaluate the performance of the Streetcast, we use the GloMoSim 2.03 simulator, which is an event driven simulator. GloMoSim models every layer of the network protocol suit. The vehicle movement and road structure is simulated by a separated simulator written in C.
5.2
Evaluated Protocols
We compare the performance of random backoff flooding (denoted by Random Backoff), role-based multicast (denoted by Role-based multicast) [27], Multipoint Relays (denoted by MPR) and our streetcast (denoted by Streetcast).
which broadcast packets without the network topology information or any neighbor knowl-edge. They try to reduce collisions by forcing nodes to wait before forwarding the packets. For random-backoff flooding and distance based multicast, each node must rebroadcast once for the received packets. MPR is an efficient link state packet forwarding mechanism which is used in Optimized Link State Routing protocol (OLSR) [29]. MPR uses neighbor infor-mation to select multi-point relay nodes for efficient broadcast.
5.2.1
Random Backoff Flooding
In the random backoff flooding, each node rebroadcast received packets actually once. When a node receives a broadcast packet, it waits for a random duration (W T ) before forwarding the packet.
W T = nSlot ∗ SlotT ime (5.1) , where nSlot is random number between [0, max Slot].
5.2.2
Distance-Based Multicast
Distance-based multicast is a flooding based mechanism, where the waiting time of the nodes is inversely proportional to the distance from the source. The waiting time W T is computed as follows:
W T = (− ¹
d
Range ∗ max Slot º
+ max Slot) ∗ SlotT ime (5.2)
, where max Slot is the maximum possible number of slots a node waits before forwarding the packet. The waiting time ensures the farthest node to broadcast the packet first. On
the other hand, the node closest to the source rebroadcast the packet last.
5.2.3
MPRs (Multipoint Relays)
Each node collects two-hop topology information by periodic ”Hello” beacons and performs the multipoint relay set selection in distributed manner. The node selects the MPRs such that there exists a path to each of its 2-hop neighbors via the MPRs. When a node has a packet to broadcast, it uses nodes in the MPRset to rebroadcast the packet. Neighbors do not belonging to the MPRset process received packets but do not forward them. Only the nodes in the MPRset forward the received packets. In order to decide the membership of nodes in the MPRset, a node periodically sends Hello beacons that contain the neighbor list to its neighbors. Nodes receiving the Hello packet update their two-hop topology tables. The MPRs selection algorithm is showed as follows.
1. MPR(x) ← ∅ /*Initializing empty MPRset*/
2. MPR(x) ←
Those nodes that belong to N1(x)
and which are the only neighbors of nodes in N2(x) 3. While there exists some node in N2(x) not covered by MPR(x)
(a) For each node in N1(x), which is not in MPR(x), compute the maximum number
of nodes that is covers among the uncovered nodes in the set N2(x).
Where Ni(x) refers to the ithhop neighbor set of node x and MPR(x) refers to the MPRset
of node x. A node updates its MPRset whenever it detects a new link in its neighborhood or in its two-hop topology.
5.3
Simulation Parameters
We use the road map of Taipei city as our map information in the simulation as shown in Fig 5.1. The traffic flow applied in the simulation is according to the statistic data collected by the Taipei city traffic engineering office in the year 2008. All nodes (OBUs, RSUs) have the same transmission (and collision) range with r = 80m. Two nodes can directly communicate with each other if the distance between them is less than the transmission radius r = 80m. We use CBR traffic in our simulation, and the CBR data packet size is 512 bytes. The details of simulation parameters are depicted in Table 5.1.
In accordance with the traffic flow collected from the Taipei city traffic engineering office in the year 2008, for example, the intersection of MinQuan Rd. and ChengDer Rd. has MAX/MIN traffic flow about 9768/563 cars in 15 min. The average traffic flow evaluated from the statistic data is about 30cars/100meters. All cars are deployed in the map based on the Poisson distribution with random speed between 30km/hr˜50km/hr and turn to different direction at intersection with equal probability. There are 9 RSUs in the simulation as depicted in Fig 5.2. Each RSU periodically broadcasts packets to the specific coverage area.
Table 5.1: Simulation parameters.
Vehicles speed 30km/hr˜50km/hr Transmission range 80m
Simulator GloMoSim 2.03 Packet sizes CBR 512bytes Simulation time 100 s
Number of lanes 2 lanes per direction,2 directions Channel capacity 2 Mbps
Path loss model Two-Ray
5.4
Simulation Results
In this simulation, we also compare the streetcast with and without beacon control (denoted by Streetcast-no hello control) to validate the effectiveness of beacon control mechanism. We first investigate the impact of packet generation rate on the packet delivery ratio. As we expected, both streetcast versions have higher delivery ratio than random backoff flooding, role-based multicast and MPRs as shown in Fig 5.3. Streetcast has better delivery ratio because of the MRTS protects the wireless channel and selects the relay point to reduce the redundancy. Moreover streetcast use ACK mechanism to achieve reliability. However, the delivery ratios for the all schemes become lower as the increasing of the packet generating rate. We discuss the different of two flooding base mechanism. We can discover the behavior of these two protocol is almost the same before packet generating rate 1(packet/s), but while the increase of packet generating rate the decreasing rate of role-based multicast is higher than random backoff flooding. It is cause by the high node density. The W T of role-based multicast is decided by distance from source, because of the high density more node have almost the same distance, and broadcast at the same time. It will lead to more serious collision than random backoff flooding, so role-based multicast has lower deliver ratio than random backoff flooding. As Fig 5.3 we can discover MPRs has low deliver ratio compare with other protocols. It is because of no mechanism to protect the wireless channel in MPRs, although MPRs select the MPRset to assign the relay point to avoid collision, but MPRs has no remedy mechanism when collision happen. Finally, we investigate both streetcast protocol, they have same high deliver ratio when low packet generating rate. When the
packet generating rate increase, we can discover that beacon control is effectively, streetcast with beacon control is keep better performance than streetcast without beacon control in higher packet generating rate. According to this result, we can prove the beacon control can save bandwidth and reduce collision (show in 5.5), but it still have enough neighbor information to achieve high performance and deliver ratio.
0 0.5 1 1.5 2 2.5 3 3.5 0 0.2 0.4 0.6 0.8 1 1.2
Packet generating rate (packet/s)
Average packet delivery ratio
RandomBackoff Role−based Multicast Streetcast
Streetcast−no hello control MPR
Figure 5.3: Packet generating rate v.s. Packet delivery ratio
Figure 5.4 illustrates the packet generating rate v.s. end-to-end delay. The end-to-end delay is defined as the total time experience as the time a packet generated from the source to the time this packet received by the destination. As shown in this figure, we can see both streetcast versions have better end-to-end delay. Although streetcast must waste time for handshake to protect wireless channel and achieve reliable, but it still have less end-to-end delay. Because of the packet broadcast to destination in both flooding based mechanism
0 0.5 1 1.5 2 2.5 3 3.5 0 2 4 6 8 10 12 14
Packet generating rate (packet/s)
Average end−to−end delay (s)
RandomBackoff Role−based Multicast Streetcast
Streetcast−no hello control MPR
Figure 5.4: Packet generating rate v.s. End-to-end delay
0 0.5 1 1.5 2 2.5 3 3.5 0 2 4 6 8 10 12 14 16 18
Packet generating rate (packet/s)
Average collision (collision/s)
RandomBackoff Role−based Multicast Streetcast
Streetcast−no hello control MPR
cost many hop to broadcast packet to destination, and streetcast will select the relay nodes as far as possible, therefore the propagation of streetcast is faster than both flooding based mechanism. MPRs mechanism select relay nodes according to source’s two-hop neighbor information, MPRs select at least neighbor to cover all two-hop neighbor to relay packets, but MPRs doesn’t select the farthest neighbor to relay packets. Therefore the end-to-end delay of MPRs mechanism is better than both flooding based protocol as the increase of packet generating rate, but worse than streetcast. There is a special phenomenon in role-based multicast, when the packet generating rate is about 2.25 (packet/s), the end-to-end delay is lower than 2 (packet/s). It is cause by the decrease of deliver ratio of role-based multicast.
Figure 5.5 illustrates the packet generating rate v.s. average collision. We can discover streetcast can reduce the collision efficiently. Streetcast can select the relay node to ensure the propagation and reduce the rebroadcast numbers, and then the handshake of streetcast will clear wireless channel and forcing other nodes who is cover in the transmission range to wait for NAV. It is helpful to avoid collision, whereas the collision of hello beacon is the most part of streetcast. Therefore beacon control is efficiently reducing collision number in streetcast. The collision of flooding based protocols is cause by the receiver’s rebroadcast simultaneously; therefore as the increase of network loading the number of collision will increase too. The reason of collision in MPRs mechanism is same with streetcast, it almost cause by hello beacon. But MPRs has no mechanism to clear wireless channel and the packet size of hello is bigger than streetcast, so MPRs has higher collision than both streetcast
versions. Whereas streetcast and MPRs because has reduced rebroadcast number by relay nodes selection to avoid collision, therefore these two protocol has lower collision number than flooding based mechanism.
As a summary for the above simulation evaluation, the simulation results shows that the proposed streetcast that introduces indeed increases more reliability and low collision than other mechanism and the adaptive beacon control plays a significant role in streetcast transmission. Adaptive beacon control provides higher delivery ratio, lower end-to-end delay and lower collision. Moreover, the simulation results show that the streetcast had excellent performance than other protocols.
Chapter 6
Conclusions and Future Work
6.1
Conclusions
In this thesis, we proposed a broadcast protocol for VANETs, called streetcast, that makes use of neighbor information and digital road map information. The streetcast uses MRTS mechanism to protect the wireless channels, avoid collisions and hidden terminal problems, and enhance the reliability. The digital road map information combined with the neighbor information is used for relay nodes selection. Meanwhile, an adaptive beacon control mecha-nism is proposed to reduce the control redundancy. The simulation results show that for the random backoff flooding and the distance-based multicast, they are useful for broadcasting data without knowing the network topology or neighbor information in a loose network, but not suitable for a high density network such as VANET. As for the MPRs mechanism, it use two-hop neighbor information to select the relay node set. However, the MPRs mechanism
has no remedy mechanisms for packet loses, resulting in low packet delivery ratio, high end-to-end delay and numbers of collisions, especially in a dense VANET. The broadcast storm problem is critical that affects the performance of these three protocols.
In summary, the streetcast has superior performance than random backoff flooding, dis-tance based multicast and MPRs in terms of packet delivery ratio, end-to-end delay and collisions under different traffic load.
6.2
Future Work
The adaptive beacon control has many adjustable parameters, and we will keep in researching for the optimal parameters for the adaptive beacon control. We will choose the optimal parameters for not only saving bandwidth in VANETs, but it also providing enough neighbor information to select relay nodes. Moreover these parameters is also helpful in reduce the number of collisions.
In order to complete the streetcast protocol, we will keep in researching on every situation which may happen in the real life and deal with it. For example, there are four road segments in an intersection for general cases as considered in the streetcast, however, there exist more complicate intersections which may have five, six or more roads in a intersection. The problem may be solved by batching the MRTS transmission scheme, and we will consider it in the future.
At last, the GPS signal is not available in sometime and somewhere in our daily life. For example, we can’t receive the GPS signal when we are in a tunnel or when the weather is bad.
Therefore, we will study the case without GPS signal in the future. We can construct the network topology by hello the signal strength of beacons and digital road map information, and use this information to broadcast packets.
Bibliography
[1] “IEEE wireless LAN medium access control (MAC) and physical layer (PHY) specifi-cations,IEEE standard 802.11-1997,” 1997, pp. 194–205.
[2] K.-H. Lee and D.-H. Cho, “A multiple access collision avoidance protocol for multicast services in mobile ad hoc networks,” IEEE Communications Letters, vol. 7, no. 10, pp. 508–510, Oct. 2003.
[3] W. Si and C. Li, “RMAC: A reliable multicast MAC protocol for wireless ad hoc net-works,” in International Conference on Parallel Processing, 2004. ICPP 2004., vol. 1, Aug. 2004, pp. 494–501.
[4] H. Gossain, N. Nandiraju, K. Anand, and D. Agrawal, “Supporting MAC layer multicast in IEEE 802.11 based MANETs: Issues and solutions,” in Annual IEEE International Conference on Local Computer Networks, 2004. 29th, Nov. 2004, pp. 172–179.
[5] S.-Y. Ni, Y.-C. Tseng, Y.-S. Chen, and J.-P. Sheu, “The broadcast storm problem in a mobile ad hoc network,” in MobiCom ’99: Proceedings of the 5th annual ACM/IEEE international conference on Mobile computing and networking, 1999, pp. 151–162.
[6] G. Korkmaz, E. Ekici, F. ¨Ozg¨uner, and U. ¨Ozg¨uner, “Urban multi-hop broadcast pro-tocol for inter-vehicle communication systems,” in VANET ’04: Proceedings of the 1st ACM international workshop on Vehicular ad hoc networks, ”October 1 2004, pp. 76–85. [7] E. Fasolo, A. Zanella, and M. Zorzi, “An effective broadcast scheme for alert message propagation in vehicular ad hoc networks,” IEEE International Conference on Commu-nications, 2006. ICC ’06., pp. 3960–3965, June. 2006.
[8] E. Fasolo, R. Furiato, and A. Zanella, “Smart broadcast for inter-vehicular commu-nications,” Wireless Personal Multimedia Communications, Proc. of WPMC05, Sep. 2005.
[9] S. Khakbaz and M. Fathy, “A reliable method for disseminating safety information in vehicular ad hoc networks considering fragmentation problem,” in The Fourth Inter-national Conference on Wireless and Mobile Communications, 2008. ICWMC ’08., 27 2008-Aug. 1 2008, pp. 25–30.
[10] D. Li, H. Huang, X. Li, M. Li, and F. Tang, “A distance-based directional broadcast protocol for urban vehicular ad hoc network,” in International Conference on Wireless Communications, Networking and Mobile Computing, 2007. WiCom 2007., Sept. 2007, pp. 1520–1523.
[11] M.-T. Sun, W.-C. Feng, T.-H. Lai, K. Yamada, H. Okada, and K. Fujimura, “GPS-Based message broadcasting for inter-vehicle communication,” in ICPP ’00: Proceedings of the
Proceedings of the 2000 International Conference on Parallel Processing, Washington, DC, USA, 2000, p. 279.
[12] S. Oh, J. Kang, and M. Gruteser, “Location-based flooding techniques for vehicular emergency messaging,” in Annual International Conference on Mobile and Ubiquitous Systems, vol. 0, Los Alamitos, CA, USA, 2006, pp. 1–9.
[13] K. Ramachandran, M. Gruteser, R. Onishi, and T. Hikita, “Experimental analysis of broadcast reliability in dense vehicular networks,” in Vehicular Technology Conference, 2007. VTC-2007 Fall. 2007 IEEE 66th, 30 2007-Oct. 3 2007.
[14] M. Taha and Y. Hasan, “VANET-DSRC protocol for reliable broadcasting of life safety messages,” in IEEE International Symposium on Signal Processing and Information Technology, 2007, Dec. 2007, pp. 104–109.
[15] L. Wischhof, A. Ebner, H. Rohling, M. Lott, and R. Halfmann, “Adaptive broadcast for travel and traffic information distribution,” in In Proc. of IEEE Intelligent Vehicle Symposium (IV03, 2003.
[16] G. Korkmaz, E. Ekici, and F. Ozguner, “An efficient fully ad-hoc multi-hop broadcast protocol for inter-vehicular communication systems,” in IEEE International Conference on Communications, 2006. ICC ’06., vol. 1, June 2006, pp. 423–428.
[17] O. Tonguz, N. Wisitpongphan, F. Bai, P. Mudalige, and V. Sadekar, “Broadcasting in vanet,” in 2007 Mobile Networking for Vehicular Environments, May 2007, pp. 7–12.
[18] S. Khakbaz and M. Fathy, “Adding reliability of broadcast methods in vehicular ad hoc networks,” in The Second International Conference on Next Generation Mobile Applications, Services and Technologies, 2008. NGMAST ’08., Sept. 2008, pp. 385–388. [19] T. Osafune, L. Lin, and M. Lenardi, “Multi-hop vehicular broadcast (MHVB),” in 6th
International Conference on ITS Telecommunications Proceedings, 2006, June 2006. [20] K. Suriyapaibonwattana and C. Pomavalai, “An effective safety alert broadcast
al-gorithm for VANET,” International Symposium on Communications and Information Technologies, 2008. ISCIT 2008., pp. 247–250, Oct. 2008.
[21] B. Williams and T. Camp, “Comparison of broadcasting techniques for mobile ad hoc networks,” in Proceedings of the 3rd ACM International Symposium on Mobile Ad Hoc Networking & Computing (MobiHoc 2002), 9-11 June 2002, pp. 194–205.
[22] K. Tang and M. Gerla, “MAC reliable broadcast in ad hoc networks,” in Military Com-munications Conference, 2001. MILCOM 2001. ComCom-munications for Network-Centric Operations: Creating the Information Force. IEEE, vol. 2, Otc 2001, pp. 1008–1013. [23] M.-T. Sun, L. Huang, A. Arora, and T.-H. Lai, “Reliable mac layer multicast in IEEE
802.11 wireless networks,” in ICPP ’02: Proceedings of the 2002 International Confer-ence on Parallel Processing, 2002, p. 527.
[24] S.-T. Sheu, Y. Tsai, and J. Chen, “A highly reliable broadcast scheme for IEEE 802.11 multi-hop ad hoc networks,” in International Conference on Communications, 2002. ICC 2002. IEEE, vol. 1, 2002, pp. 610–615.
[25] C.-Y. Chiu, E. Wu, and G.-H. Chen, “A reliable and efficient MAC layer broadcast (mul-ticast) protocol for mobile ad hoc networks,” in Global Telecommunications Conference, 2004. GLOBECOM ’04. IEEE, vol. 5, Nov.-3 Dec. 2004, pp. 2802–2807 Vol.5.
[26] S. Jain and S. Das, “Exploiting path diversity in the link layer in wireless ad hoc networks,” in Sixth IEEE International Symposium on a World of Wireless Mobile and Multimedia Networks, 2005. WoWMoM 2005., June 2005, pp. 22–30.
[27] L. Briesemeister, G. Hommel, and D. Ag, “Role-based multicast in highly mobile but sparsely connected ad hoc networks,” in in First Annual Workshop on Mobile Ad Hoc Networking ans Computing, 2000, pp. 45–50.
[28] Y. Gao, D.-M. Chiu, and J. Lui, “The fundamental role of hop distance in IEEE 802.11 multi-hop ad hoc networks,” in 13th IEEE International Conference on Network Pro-tocols, 2005. ICNP 2005., Nov. 2005.
[29] T. H. Clausen, G. Hansen, L. Christensen, and G. Behrmann, “The optimized link state routing protocol evaluation through experiments and simulation,” in In Proceed-ing of Wireless Personal Multimedia Communications. Mindpass Center for Distributed Systems, Aalborg University, Fourth International Symposium on Wireless Personal Multimedia Communications, 2001.
