Chapter 4 Protocol Design
4.6 PC-ALOHA Protocol
We summarize the above describe into a series of protocols the main operation of PC-ALOHA at each slot when node join the network, operation of EFI sending and receiving routine, and Power Control of congestion node in Figure 17~20. And the PC-ALOHA flow chart has shown in Figure 21.
Protocol 1: Operation of PC-ALOHA at each slot timer Protocol:
/* parameters and Flag defined
WAITING : waiting to contend for a slot CONTENDING : occupation or contending for a slot Status : status of the node
5 set Status=CONTENDING of the node
6 else
7 reset Timer of the node
16 if there isn’t any collision (feedback from receive algorithm) then
17 send the EFI call. call sendFI()
18 set Status=CONTENDING of the node
19 return
20 else // Collision
21 Set Status=CONTENDING of node and contend for slot again.
22 reset Timer of the node
23 Timer of system++
24 return
25 else
26 Timer of system++
27 receive EFI and maintain EFI table only
28 return
Figure 17. Operation of PC-ALOHA at each slot timer Protocol
---
Protocol 2 Operation of EFI sending routine:
--- /*
Parameters and Flag defined
*/
1 if my contending slot is coming then
2 send the EFI packet by transmission power piggybacking my X, Y, 3 and Z coordinate and slot using status of my one-hop neighbors 4 return
Figure 18. Operation of EFI sending routine Protocol.
---
Protocol 3 Operations at the reception of an EFI ---
/*
Parameters and Flag defined
*/
1 if my transmission power >= distance to the transmission node then 2 maintain slot status, distance to the transmission node and who 3 use the slot in its EFI table
4 else
5 mark the slot that only using by two-hop neighbors as FREE 6 return
Figure 19. Operations at the reception of an EFI Protocol
---
Protocol 4 Power Control of congestion node ---
4 check each one-hop neighbor
5 if we can find one-hop node didn’t satisfy GG constraint then 6 set release flag =TRUE
Figure 20. Power Control of congestion node Protocol.
The details of protocol 1 are described as follows:
- line 1: Check if the node is waiting to contend for slot, after listening to the slots occupation for an entire frame
- line 2~5: If the incoming slot is free and the node try to contend for the free slot.
First, the node must send out an EFI packet and change the node status.
- line 6~8: If the node don’t contend for the incoming free slot, it would wait the next free slot coming and repeat line 2~5 steps.
- line 9~14: If the node cannot find any free slot, the node can follow the GG constraint to shrink its transmission power for re-using the reserved slot.
- line 15~24: Check whether all the one-hop neighbors received my EFI. If agree, sends out the EFI packet at the coming slot again. Otherwise, try to wait another free slot coming and contend for it.
- line 25~28: Just listening the EFI packets from one-hop neighbors and maintaining EFI table.
The details of protocol 2 are described as follows:
- line 1~4: Nodes share their perceived information and X, Y, Z coordinate to each other by properly broadcasting packet EFI.
The details of protocol 3 are described as follows:
- line 1~3: If our power range can cover to the transmission nodes, we will record all EFI information from one-hop neighbors in EFI table.
- line 4~6: We must consider unidirectional links. When our power range cannot cover to the transmission nodes, we can mark the slot which using by two-hop neighbor only as FREE.
The Power Control of congestion nodes are described as follows:
- line 1~2: Find out the slot only used by two-hop neighbor from our EFI table
- line 3~6: Find out a one-hop node which didn’t satisfy GG constraint when we adjust the power range. Then, we can guarantee the network still connectivity.
- line 7~8: Go to next step.
- line 9~10: Go to next step.
- line 11~13: If we can find out the one-hop neighbor, shrink our transmission power for re-using the reserved slot.
As shown in Figure 23, we demonstrate the flow chart of PC-ALOHA Protocol.
Figure 21. PC-ALOHA flow chart
As shown in Figure 2, there are 7 nodes contending for 5 slots. After a listen interval, each node has to contend to reserve an available slot and use the slot in subsequent frames. According to our protocol and flow chart, the simulation statuses of each node shown in Figure 22 and described as follows:
-- In Frame 1:
Node B: Try to send an EFI to contend slot 1 for its transmission, and set up the status from WAITING to CONTENDING at same time.
Node C: Try to send an EFI to contend slot 2 for its transmission, and set up the status from WAITING to CONTENDING at same time.
Node F: Try to send an EFI to contend slot 3 for its transmission, and set up the status from WAITING to CONTENDING at same time.
Node D, G: Try to send an EFI to contend slot 4 for its transmission, and set up the status from WAITING to CONTENDING at same time. Actually, the EFIs will collision at node F. In next frame (i.e., frame 2), EFI from its one-hop neighbor, Node F, does not indicate that slot 4 was marked as BUSY by node D or G.
Node A, E: Try to send an EFI to contend slot 5 for its transmission, and set up the status from WAITING to CONTENDING at same time. The EFI will collision at node C. So, node A and E need to listen a frame interval and contend a free slot for its transmission again.
-- In frame 2:
Node B, C and F:
The contending is successful and nodes B, C and F will use the slot 1, slot 2 and slot 3 in subsequent frames as long as the node has packets to send.
Node A, D, E and G:
The contending is unsuccessful. Nodes A, D, E and G have to listen a frame time and try to reserve a free slot again. All of them must set up the status from CONTENDING to WAITING at same time.
-- In frame 3:
Node A: It does not contend a free slot for its transmission in frame 3.
Node D: Send an EFI to contend other slot 4 for its transmission, and set up the status from WAITING to CONTENDING.
Node E, G: Try to wait another free slot 5 coming and contend for it. And set up the status from WAITING to CONTENDING. Nodes E and G are not two-hop neighbor, so they will reserve slot 5 for theirtransmission successfully.
-- In frame 4:
Node A: Node A can not find any free slot for its transmission end of frame 3.
According to our power control protocol shown in Figure 21, it will find slot 3 can be re-used. All of Node A~G will reserve a slot for their transmission in subsequent frames
Figure 22. Reserved slot of each node
☆
Chapter 5
Simulation Results and Analysis
5.1 Simulation Environment
In this section, we compare the performance of the proposed PC-ALOHA MAC protocol with that of RR-ALOHA MAC protocol in ns-2 [23]. The duration of each simulation is 10 seconds. Each simulation runs 20 times. The data rate is 2 Mbps (802.11b). All nodes are assumed to be stationary and their maximum transmission ranges are 250 meters. The EFI frame length is fixed at 80 bytes. The slot time is fixed at 2ms. The numbers of default nodes are 100 nodes, and the deployment region is 1000*1000 meters.
5.2 Results Analysis
A). Frame size vs. Reserving rate:
First, the aim of this experiment is to study the reserving rate relate to the frame size. As shown in Figure 22, the number of nodes is inversely proportional to the percentage of reserved nodes on RR-ALOHA. On the other word, PC-ALOHA needs a fewer slots to achieve 100% reserving rate than RR-ALOHA in a dense network. A larger frame size may incur a larger delay since each node has to wait for a longer period of time before the next frame coming. Otherwise, the smaller frame size can update the message more quickly.
collision
0 50 75 100 125 150
Figure 23. Frame size vs. Reserving rate
B) Single-hop performance:
As shown in Figure 23, RR-ALOHA requires 33 slots to achieve 100% of reserving rate, but PC-ALOHA requires only 28 slots to achieve 100% of reserving rate. PC-ALOHA can save about 15% frame size (28/33 =84.5%). PC-ALOHA frame size is smaller than RR-ALOHA, PC-ALOHA has a lower message update delay. It shows clearly, the slot reserving rate of RR-ALOHA is related to the frames size.
PC-ALOHA always keeps the nodes reserving rate upon 98%. However, it is a dangerous when the channel is congestion in RR-ALOHA network. Because of many nodes have neither the right to transmit nor the guarantee of receiving packet from all its neighbors. In other words, the congestion nodes do not join to the network.
As shown in Figure 24, in order to enhance the slot reserving rate, PC–ALOHA need to reduce the transmissions range for slot time re-using. If the frame size is smaller, nodes will transmit at a smaller transmission range.
0 22 24 26 28 30 32 34 36 38 40
Figure 25. average transmission range C) Convergence :
Although schedule-based MAC protocol can provide each node a contention-free opportunity for data transmission without collision, the node still need to contend for slot reservation by using RR-ALOHA or PC-ALOHA. Especially when it comes to
result, it may take several frames until all the reservation processes complete.
As shown in Figure 25 and Figure 26, the RR-ALOHA protocol slot reserving rate almost can upon 100%. It means that the channel is not congestion. So the power control mechanism did not need to be triggered often. As a result, the PC-ALOHA will not increase the system convergence overhead compared to RR-ALOHA protocol.
Convergence (50 Nodes . Frame size :15 Slots)
Percentage of reserved nodes
RR-50 nodes PC-50 nodes
Figure 26. Convergence (50 Nodes)
Figure 27. Convergence (100 nodes) D) Performance under 100% reserving ratio:
As shown in Table 4, the relationship between slot reserving ratio of nodes and
0 5 10 15 20 25 30 35
Convergence (100 Nodes . Frame size :30 Slots)
RR-100 nodes PC-100 nodes
the number of frame sizes, average flooding hop counts and number of frame sizes, and average relaying delay and number of frame sizes in the different network density.
There are two values in each field. Above number in the field presents the average value and below number in the field presents the maximum one. (e.g., the RR-ALOHA requires 32 slots upon 100% reserving ratio and the maximum number of slot is 33. PC-ALOHA only requires 26.2 slots upon 100% reserving ratio and the maximum number of slot is 28). As a result of the simulation: in the deployment region, the frame sizes under 100% slot reserving ratio is based on the nodes density.
The results show that the PC/RR ratio of required slots decreases as the number of nodes increases, since the higher density, the larger frame size is required, which implies that our approach has more chance to find a free slot by reducing the node’s power. On the other hand, PC–ALOHA will save a larger percentage of frame sizes in the high dense networking.
node
Required slots Hop counts Relaying delay (ms) (Hop count*Frame size)
Table 4. Performance under 100% reserving ratio
E) Flooding Delay
We analyzed transmissions delay problem with the maximum frame size above
simulation case (e.g., 100 nodes frame size is 33 in RR-ALOHA, 28 slots in PC-ALOHA). As shown in Figure 27, (1) in dense networking, RR-ALOHA average delay is higher than PC-ALOHA. (2) The maximum delay in 150 nodes simulation case, RR-ALOHA is higher than PC-ALOHA about 28% and the average delay is about 11%. Therefore, it is a serious issue for safety-critical application message exchange.
0 50 100 150 200
0 20 40 60 80 100 120
Number of nodes
Delay time (ms)
Flooding Delay
PC-AVG. Delay RR-AVG. Delay PC-MAX. Delay RR-MAX. Delay
Figure 28. Flooding Delay
Chapter 6 Conclusion
In this paper, we have proposed a low-delay distributed TDMA Protocol with congestion control for wireless Ad Hoc networks base on previous RR-ALOHA MAC protocol. The most important features of PC-ALOHA MAC protocol are resolving the congestion problem and at the same time achieving a lower end-to-end delivery delay for the Ad Hoc networks. At same time, our PC-ALOHA MAC protocol guarantees the network connectivity even if transmission range of some nodes were reduced. As the result, in dense networking, our protocol decreases at most 28% in delay than RR-ALOHA. It proof our MAC protocol is suitable for the current delay-sensitive safety application, such as Cooperative Collision Avoidance (CCA) in vehicular networks. In future, we will further consider how to assign slots to nodes most quickly and a fewer convergence time in a dense network.
Reference
[1] X. Yang, J. Liu, and F. Zhao, “A Vehicle-to-vehicle Communication Protocol for Cooperative Collision Warning”, In Proceeding of the 1st Annual International Conference on Mobile and Ubiquitous Systems Networking and Services, IEEE Computer Society, Massachusetts, USA, pp. 114 - 123, 2004.
[2] V.S. Raghavan S. Kumar and J. Deng. “Medium access control protocols for ad-hoc wireless networks: A survey.” Elsevier Ad-Hoc Networks Journal, 4(3):
pp. 326 - 358, May 2006.
[3] L. Armstrong, “Dedicated Short Range Communications (DSRC),” [Online].
Available: http://www.leearmstrong.com/dsrc/DSRCHome.htm
[4] M. Torrent-Moreno, P. Santi, and H. Hartenstein, “Fair Sharing of Bandwidth in VANET”, in Proceedings of the 2nd ACM International Workshop on Vehicular Ad Hoc Networks (VANET), Cologne, Germany, pp. 49 - 58, 2005.
[5] Xu Guan, Raja Sengupta, Hariharan Krishnan, Fan Bai “A Feedback-Based Power Control Algorithm Design Based Power Control Algorithm Design for VANET”, Mobile Networking for Vehicular Environments, pp. 67 – 72, 2007.
[6] J. Zang, L. Stibor, et al. “Congestion Control in Wireless Networks for Vehicular Safety Applications”, In Proceeding The 8th European Wireless Conference, Paris, France. pp. 7, 2007.
[7] Fan Yu and Subir Biswas, “Self-configuring TDMA protocol for enhancing vehicle safety with DSRC based vehicle-to-vehicle communication”, IEEE Journal Selected Areas in Communications, vol. 25, no. 8, pp. 1526 – 1537, 2007.
[8] Hassan-Aboubakr Omar, Weihua Zhuang, and Li Li, “VeMAC: A novel multichannel MAC protocol for vehicular ad hoc networks”, in Proc. of IEEE
Conf. on Computer Communication Workshop, pp. 413 – 418, 2011.
[9] F. Borgonove, A. Capone, M. Cesana, and L. Fratta, “ADHOC MAC: New MAC architecture for ad hoc networks providing efficient and reliable point-to-point and broadcast services”, Wireless Networks, vol. 10, pp. 359 – 366, 2004.
[10] Ning Lu, Xinhong Wang, Ping Wang, Peiyuan Lai, Fuqiang Liu “A distributed reliable multi-channel MAC protocol for vehicular ad hoc networks”, in Proc. of IEEE Intelligent Vehicles Symposium, pp. 1078 – 1082, 2009.
[11] Ning Lu, Yusheng Ji, Fuqiang Liu, and Xinhong Wang “A dedicated multi-channel MAC protocol design for vanet with adaptive broadcasting”, WCNC, pp. 1 -6 ,2010.
[12] Jia Liu, Fengyuan Ren, Limin Miao, Chuang Lin “A-ADHOC: an adaptive real-time distributed mac protocol for vehicular ad hoc network”, ChinaCOM, pp.
1 – 6, 2009.
[13] F. Borgonovo, A. Capone, M. Cesana, L. Fratta, "RR-ALOHA, a Reliable R-ALOHA Broadcast Channel for Ad Hoc Inter-Vehicle Communication Networks", Med-Hoc-Net, Baia Chia, Italy, 2002.
[14] B. Hull, K. Jamieson, and H. Balakrishnan, “Mitigating Congestion in Wireless Sensor Networks”, In Proc. of 2nd ACM Conference on Embedded Networked Sensor Systems, pp. 134-147, November 2004.
[15] W. Crowther, R. Rettberg, D. Waldem, S. Ornstein, and F. Heart, “A System for Broadcast Communication: Reservation-ALOHA,” in Proceedings of the Sixth Hawaii International Conference on System Sciences, January 1973.
[16] F. Borgonovo, L. Campelli, M. Cesana, and L. Fratta, “Impact of user mobility on the broadcast service efficiency of the ADHOC MAC protocol”, Proc. IEEE VTC, vol. 4, pp. 2310-2314, 2005.
[17] Marc Torrent-Moreno, Jens Mittag, Student Member “Vehicle-to-Vehicle
Communication: Fair Transmit Power Control for Safety-Critical Information”, IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 58, NO. 7, pp.
3684 – 3703, 2009.
[18] M. Torrent-Moreno, P. Santi, and H. Hartenstein, “Distributed fair transmit power adjustment for vehicular ad hoc networks.” In SECON ’06 3rd Annual IEEE Communications Society, pp. 479-488, 2006.
[19] J. Mittag, F. Schmidt-Eise nlohr, M. Killat, J. Harri and H. Hartenstein,”Analysis and Design of Effective and Low-overhead transmission power control for VANETs.” in Proc. 5th ACM Int. Workshop VANET, pp. 39-48 , 2008.
[20] Ghassan Samara, Sureswaran Ramadas, Wafaa A.H. Al-Salihy “Safety Message Power Transmission Control for Vehicular Ad hoc Networks”, J. Computer Sci., 6 (10): 1027-1032, 2010.
[21] Chunxiao Chigan and Jialiang Li “A Delay-Bounded Dynamic Interactive Power Control Algorithm for VANETs”, IEEE ICC, pp. 5849 – 5855, 2007.
[22] K.R. Gabriel and R.R. Sokal. “A New Statistical Approach to Geographic Variation Analysis.” Systematic Zoology, vol. 18, pp. 259 - 278, 1969.
[23] “The network simulator (NS2) ”, http://www.isi.edu/nsnamlns/
[24] T. Liu, J. A. Sylvester, and A. Polydoros, “Performance evaluation of R-ALOHA in distributed packet radio networks with hard real-time communication,” in Proc. IEEE Veh. Technol. Conf., pp. 554 - 558 vol.2 1995.
[25] R. Verdone, “Multihop R-ALOHA for intervehicle communications at millimeter waves”, IEEE Trans. Veh. Technol., no. 4, pp. 992 – 1005, 1997.
[26] Y. Wang and B. Bensaou, “Achieving fairness in IEEE 802.11 DFWMAC with variable packet size,” in Proc. IEEE Global Telecommun. Conf., pp. 3588 - 3593 vol.6, 2001.
[27] W. Crowther, R. Rettberg, D. Waldem, S. Ornstein and F. Heart, A system for
broadcast communications: Reservation ALOHA, in: Proceedings of 6th Hawaii Internat. Conf. Sist. Sci., pp. 596–603, 1973.
[28] Flaminio Borgonovo, Luca Campelli, Matteo Cesana “Topology Control In Ad Hoc Networks: A MAC Layer Solution”, International Journal on Wireless {&}
Optical Communications, VOL. 3, NO. 1, pp. 101 – 117, 2006.