The Scientific World Journal

The Scientific World Journal / 2014 / Article
Special Issue

Next-Generation Internet and Communication

View this Special Issue

Research Article | Open Access

Volume 2014 |Article ID 601913 | 9 pages | https://doi.org/10.1155/2014/601913

A Lightweight Neighbor-Info-Based Routing Protocol for No-Base-Station Taxi-Call System

Academic Editor: W. Sun
Received26 Oct 2013
Accepted28 Nov 2013
Published09 Mar 2014

Abstract

Since the quick topology change and short connection duration, the VANET has had unstable routing and wireless signal quality. This paper proposes a kind of lightweight routing protocol-LNIB for call system without base station, which is applicable to the urban taxis. LNIB maintains and predicts neighbor information dynamically, thus finding the reliable path between the source and the target. This paper describes the protocol in detail and evaluates the performance of this protocol by simulating under different nodes density and speed. The result of evaluation shows that the performance of LNIB is better than AODV which is a classic protocol in taxi-call scene.

1. Introduction

The VANET has characteristics of mobile ad hoc network, such as self-organization, flexible structure, multihop routing, dynamic changes of network topology, and need of good scalability. Special application environment, such as narrow road, high density node distribution, high-speed node moving, and other factors, will directly influence the information transmission ability of VANET network, which leads to the increase of packet loss and delay. Meanwhile, the limited wireless channel and huge network scale challenge the data transmission of VANET.

The key to solve the above problems is how to design a routing protocol [17]. Since the nodes in VANET are of high mobility, it results in connection failure while applying routing protocol of the traditional MANET [810], such as AODV [1113] and DSR [14, 15], into the VANET, thus leading to delay or even failure to transmit information to the target node.

Due to the special environment in VANET, it cannot have a widely applicable routing algorithm. The typical algorithm in VANET, such as GSR routing protocol, involves each node storing the neighbor lists, topology table, next hop table, and distance table. All of them maintain the state information of adjacent nodes and choose the appropriate router according to the location and topological information. In small network with high mobility and limited bandwidth, the performance of transmission is good However, it requires the node to maintain the network topology. And with the increase of network size, the routing information that needs to be exchanged will increase exponentially. Another type of algorithm, such as the GPSR [16, 17], is based on position. It depends on the overall geographical location information search system. It cannot work without GPS.

When applied to the urban taxi-calling scene, the VANET vehicle network has the following characteristics. The density distribution of vehicle is uneven. Places such as the business center, theaters, and bus stations are dense. The traditional VANET routing protocols have serious information channel congestion problem. The calling passenger has no special requirements to the not-taken taxis, so all the nearby taxis can serve. While the traditional VANET routing protocols always have designated transmission target, or specifies the routing service of all nodes in the target area, which will lead to huge routing overhead, further deteriorating the channel congestion problem. The data transmission is time valid. Passengers’ calls need to be responded to in a short time, while the routing connection time is fairly long in some of the traditional VANET routing protocols. Therefore, it cannot effectively find not-taken taxis with such application and will have bad effects on passengers’ experiences. We describe some of the work roughly in [18].

This paper aims to solve the quick topology change, short connection duration, and unstable wireless signal quality of the VANET network, thus proposing a kind of lightweight routing protocol applicable to the urban taxi-call without base stations. The protocol maintains and predicts neighbor information dynamically in order to find the reliable path between the source and the target. This paper describes the protocol in detail and evaluates the performance of this protocol by simulating under different nodes density and speed. The result of evaluation shows that the performance of LNIB is better than that of AODV which is a classic protocol in taxi-call scene.

The second chapter analyzes the application and proposes the model; the third chapter describes the routing protocol and its algorithm; the fourth chapter is about the experiment and data analyses; chapter five concerns other related research; the last part will draw a conclusion.

2. Transmission Mode and Analyses

In the taxi-calling scene, the vehicle network has two sets: taxi nodes and passenger nodes . From the start of the call to get on the car or the call to cancel, a connection should be set up in the network. Because the passenger always waits at the original place or moves slowly, suppose is a static node. And only acts as the initiator of data transmission or receiver, not as mediator in other routings. The node can send, receive or act as a routing node to transmit data. Assume that the speed scalar of each node in is .

When initiates a call, the message transits through the taxi nodes, so can quickly find nearby not-taken cars node that can meet the requirements.

Supposing there are two nodes and in the network, the signal coverage radii for them are, respectively, and . If the distance between and is , it can be called “meet.” To be more general, assuming that signal coverage radius of each node in the network is , then “meet” in time means . Define as the minimal number of hops to transmit message from to . Among all that get the call request, is the lowest of .

2.1. Prediction Based on Neighbor Information

In order to percept the current meet nodes in real time, needs to send broadcast packets to notice their own state information periodically. In the starting time of every broadcast cycle, measures their own motion state, including the speed, the current position, and other information. According to the above information, predicts the coordinates at the time of and broadcasts the position. The broadcast cycle is . If is small, then the channel will be occupied by a large number of broadcast packets, thus influencing the normal data transmission. However, large will lose the prediction value due to the frequent changes in actual situation. Therefore, should be set properly, such as 10 seconds. A broadcast cycle can be divided into multiple correction cycles. The node in a correction period measures their movement state. While finding the coordinates’ different between the current forecast coordinate at and the last broadcast coordinates surpasses, it indicates that the vehicle’s driving condition changes. If is greater than a certain value, the node broadcasts the position again to correct the predict position of itself in neighbor nodes’ state table, thus to ensure the prediction accuracy. Suppose the correct period is .

Meanwhile, if receives the position broadcast of the nearby nodes, it maintains an adjacent link (see Table 1) to record node information that meets with . It can be seen from the table that measures its position and velocity at 13:11:12′36 and broadcasts. receives the position broadcast. If , then it can be predicted that, at , and will keep meeting. If is not in the table, adds the information of to the table and sets to be active. If is already in the table, update the information of . When receives the correction broadcast of , the position information of also needs updating. If it can be predicted that and will not meet at , set to be inactive. As to the inactive node in the table, if no broadcasts are received in more than one broadcast cycle, then delete the entry of this inactive node. Each time the passenger calls a taxi, several links will be produced. If and are neighbors and are both in one link, then they set up link ID in the entry for each other in their own table. Link ID is a large number that is randomly generated. It can be assumed that it is unique in a limited region.


Neighbor PositionDirection of speedLink IDReliabilityMeasuring timeState

3120.213476E:
30.321768N
1823786270.9413:11:12′36Active
5120.213484E:
30.321775N
4527667320.8313:10:37′34Inactive

When receives the broadcast of neighbors at time , it will predict coordinates of itself and neighbor nodes at , respectively. If the two cars can keep communication at that time (such as ), the communication is effective. Therefore stores the information of in the table otherwise discards it (such as the ).

In order to provide the position information and routing of not-taken taxis, the hop distance should be introduced when node is broadcasting message (including position and correction broadcast). Periodically sets to 0 and sends broadcast. The discards any broadcast information it received without processing. The sets value to ∞, when no neighbor nodes can reach node. When receives the broadcast of with the active state, if , modifies the value to .

Once changes, will spread to notify neighbor nodes to be updated by periodical breakfast. But each cycle can only update 1 hop on the link. If , it needs cycle to update .

In order to improve the broadcast speed of , the sending phase of each cycle is divided into two time slices. The node of changes, but no broadcast will be broadcasted at the first time slice. If the value has no change after last broadcast, the node broadcasts in the second time slice. Thus, the value of may spread 2 hops in a cycle. For the length of link will be limited in 3-4 hops in the actual system, two cycles can complete the information disclosure of not-taken taxis by the improved broadcast speed.

2.2. Links Setting and Handshake

When launches the call, it needs to find suitable not-taken taxis as soon as possible and make an appointment. In this process, the following questions need to be solved. First, how to find in the shortest time and establish the link to ? Secondly, if there are several nodes, how to choose one of the most suitable ones to make an appointment?

The simplest method is to use the broadcast to send out the call until a node of receives the request and returns a response. The response will go backtracking to the node. If receives several responses, then choose one from them, after which appointment confirmation will be sent to the chosen node through the path just set up. Meanwhile, it will send negative responses to other not-taken taxis. This method is easy to be implemented, but in the real VANET scene, there are serious problems; the message must pass the whole link three times: request, response, and appointment. On the one hand, it will lead to serious delay and difficulties in keeping the link; on the other hand, the flooding of breakfast will deteriorate the network environment and influence the normal communication.

This paper proposes a two-end handshake agreement to great link (show as Figures 1 and 2) According to the neighbor nodes’ information described in Section 2.1, each node can know the nearest (by hop distance) and the shortest route to arrive at the node. If sending the request broadcast, its neighbor node which receives ’s breakfast directly can judge whether it can reach or not. In fact, it is supposed that the whole data transmission is a single route (the node on the link will transmit a message to only one neighbor node). Once is identified as the first hop, the routing from to will also be established. The can directly send a request response to the . If receives responses from several nodes, it chooses a node as to make appointment confirmation and send a veto appointment to other response . After that accepts the confirmation and sends it to the based on the routing information, that is, to transmit message to the neighbor node in which . On the routing, node will record the information of last hop, while receiving the message. Meanwhile, transmit to the next hop which until sent to the node which , that is .

The end of the link also needs handshaking. If several neighbor nodes, in which , are for the same node, they will send appointment requests to the , and the sends a confirmation response to one of them and negative responses to others.

The two-end handshaking method can reduce the three times handshaking to two times, thus reducing the risk of delaying and disconnection. Meanwhile, the broadcast can be controlled in 1 hop and can avoid the flooding.

2.3. Disconnection

Suppose , , , and . If receives the position correction information from , the adjusted position predictions indicate that will lose contact with . Since is the minimum stored in , after node deletes the , it modifies its own value to ∞ and triggers an extra position correction broadcast. Also, when receives the position correction by this broadcast, it continues the same operation.

In the communication process, the effectiveness of link should be guaranteed from the sending of ’s request to ’s response return to . Once a pair of nodes on the link are disconnected, it should be processed correspondently. The relatively ideal way is to find the third node before disconnection and to maintain the link. Another simple method is to notify and to abandon the appointment on both ends. Thus, it can avoid feedback loss which will result in information consistency. Then the initiates the request process again.

As the vehicle’s speed is fast and unstable, the time of link maintains a relatively short time. The frequently broken links will lead to repeated reconnection. To avoid this, higher reliable links are required. So in the ’s neighbor nodes state table, the reliability attribute is added for each neighbor node. The reliability refers to the prediction accuracy at and the help to effective datagram transmission on the link. It mainly depends on the following two conditions: during to period, the relative position between and . If the distance is far, on the one hand, the weak signal can lead to transmission instability; on the other hand, since has been close to the edge of the communication range, the slight change of the vehicles will make out of ’s communication range and cause broken connection. If and are close, the data transmission will take place in a short distance. The datagram will not move a lot in geographical location; thus, it influences the efficiency of data transmission. Thus supposing refers to the transmission reliability of , and

Modify the condition of correcting in Section 2.1. Given the reliable threshold and after node receives the broadcast of node, if state () = active, , and , then modify the value to be .

3. Protocol Implementation

In order to further introduce the implementation of the protocol, the pseudocode algorithms of taxi node and passenger node are given, respectively, in this section. To be simple, based on the discussion in the second section, the following several types of datagram in the taxi-call network will be referred to.

Broadcast represents position broadcast. The taxi node sends periodically, and the nearby taxi node receives.

represents the six kinds of datagrams in the two-end handshaking protocol after the passengers make a request.

represents the cancelation of the reserved datagram while finding the abnormal disconnection.

Algorithm 1 is divided into two parts. The timer gets the position and speed information for a short time (e.g., 3 seconds). If the interval exceeds , then send broadcast to the nodes around. According to the current measured data, the position at can be predicted. If there exists significant difference between the position and the position of the last broadcast, then send broadcast without considering whether the time intervals exceed or not. The timer will also inspect the neighbor node that is not updated over time in the adjacency list and set these nodes as inactive. Since the time in the record is the position measuring time, to consider the communication delay, the overtime window will be slightly amplified to . If not updated for more than two broadcast cycles, then delete the node.

Initialization   ;
Initiate the prediction position   ;
Initialization   ;
Set timer;
Timer_task(){
   Obtain the current position L, speed V, time
    ;
   If (no-load){
     ;
   }
   Calculate prediction position at ( )
   If ( ){
    
    broadcast(L, V, H, );
     ;
    
   }else if ( larger than threshold 0){
   
    broadcast(L, V, H, );
     ;
     ;
   }
   For each node q in table{
    get q's prediction time
    if (state(q) active && ){
      state(q) = inactive;
      if (q have the link ID){
      send to other node which have the same lnik ID as q;
     }
    }
    If ( 2 ){
      Remove q from table;
      }
   }
   Update H;
}
Count = 0; // reset 0 after passengers getting off or appointment cancellation
Block_listen(Message){
   Switch typeof(Message) {
    Case :
     update table
     update H
     if q node that sends gets out of the communication range, and it has link ID in the table
      send to other node
      which have the same link ID as q;
     break;
    Case :
    If ( ){send back}
    break;
    Case :
    If (Message Reserve){
     If ( && count 0){
       Count = 1;
      send (Agree or Disagree) back;
     }else if ( ){
        Set link ID;
        send to all q in table which ;
        }else{
          Set link ID;             
          send to one q which ;             
         }                
      }                
    Case :    
    If (Message Agree){
       Send forward to q which               
        and have the same link ID;          
       delete link ID;                          
      }                         
      If ( ){                 
       Send Confirm back;                        
    }                         
    Default:                          
}                         
}                         

As for the inactive nodes, check whether they are in the current communication connection. If it is true, then send to other connected nodes to cancel the conformation.

The other part of Algorithm 1 is the listener. After the listener receives a datagram, he/she judges data types. If it is the position broadcast datagram, then update the list. Once the predicted node position changes are identified in the current connection and in a short time will overpass the scope of communication, and then notify other nodes on the connection to cancel the appointment. When accepting other types of datagram, again transmit or respond based on the protocol.

Algorithm 2 mainly includes two timers and a listener. When initiating the request, timer1 is set. At the same time, the listener will put the received response to the response queue. When timer1 is triggered, it checks the queue. If the queue is empty, it means no response, and it sends the request again. Otherwise, it chooses the response that has the nearest transmission distance from passengers to not-taken taxis in order to make appointment. And it simultaneously sends veto to other response nodes. After sending the appointment datagram, set timer2. Once no appointment conformation in a certain time , then the timer2 will be launched, and send request again. Attention here, once the listener receives an , the datagram cancellation is caused by connection error. Then immediately start the timer2 and send request again.

Initiation queue = empty
Call_taxi{
   Get its position L
   Broadcast( )
   Set Timer1();
}
Timer1_task(){
   If (queue = empty){
    Call_taxi();
  }else{
  Choose the nearer hop q,
  Produce link ID;
  Send (Reserve, link ID) to q;
  Send (Negative) to other
  }
  Set timer2;
}
Timer2_task(){Call_taxi(); }
Block_listen(Message){
 Switch typeof(Message) {
   Case
      Add q to queue;
    Break;
   Case :
    Cancel Timer2;
    Break;
   Case :
    Set Timer2 current time;
    Break;
   Default:
}

4. Performance Analysis

In order to evaluate the performance of the proposed routing protocol, the paper uses NS2 and VanetMobiSim to simulate.

The NS2’s main parameters are shown in Table 1. The simulation scene size is 5 × 5 square kilometers. In VanetMobiSim simulation, the scene size is 5 × 5 square kilometers too. In the total area there are 20 traffic signals and the entire simulation area is divided into several regions. In every region the density of streets and the allowed maximum speed are different. The regions which have higher street density have lower allowed maximum speed. When vehicles get into the corresponding region, they choose the speed from street allowed maximum speed and self-allowed maximum speed with a low one. In all of our simulations, the empty taxis account for 40%.

We set the interval of route maintain message to be equal to 10 s and then set the maximum speed of taxi nodes to be equal to 60 km/h. When we adjusted the density of taxi nodes, we got the probability of passenger node to find empty taxi node and the probability of node to receive the message from as shown in Table 3.

As shown in Table 3, when node density is too low, the transmission range will be so small that it is hard to maintain the information of nodes for a long time. Hence, when appears, the number of nodes that can communicate with is small and the time of link is short so that it is hard to communicate with . As the node density becomes higher, situations are getting better, but some nodes have higher velocity, which leads to more failure. Because the links chosen are the links that have long duration, so the probability of node receiving acknowledgement messages from node is pretty high.

Then if we fix the density of taxi nodes as 5 per km2 and fix the transmission range as 500 m, we will get the relation of the maximum speed and the successful ratio.

We called it successful calling when the passenger node finds the empty taxi node. In Figure 3, we could see that when the maximum speed of taxi is equal 60 km/h, it has the highest successful ratio which enables the passenger node to find the empty taxi nodes. This is because when the node’s moving speed is low, the node can contact with fewer other nodes. And when the node’s moving speed is high, the network topology changes fast, which causes fewer available routing link and thus causes lower successful calling.

Figure 4 shows the impact of node’s moving speed on the amount of switching packets of entire network.

As shown in Figure 4, the amount of switching packets grows up as the vehicle movement speed increases. This is because when the speed of node movement increases, it causes more correcting message, resulting in the increase of network data traffic. In addition, in one simulation, the routing overhead is higher at the beginning and gradually declines over time. This is because when the simulation starts, all taxi nodes are active at the same time and all taxi nodes broadcast at the same time, which causes more channel collision, leading to an increasing number of retransmissions. As time progresses, due to the correcting message, the taxi routing maintenance cycles gradually stagger and the entire network routing overhead declines.

Then we adjust the density of taxi nodes in the region. The average density of taxi nodes is set at 1–6 per square kilometer and the vehicle maximum speed is set at 60 km/h and then the results are shown in Figure 5.

As shown in Figure 5, when the taxi nodes are scarce, the rate of the success calling drastically reduces. While increasing the number of taxi nodes, the rate of success calling improves accordingly. This is because when the number of taxi nodes is too small, there is no taxi node around passenger node so that the passenger node cannot contact with any node, resulting in more calling failure. When the number of taxi nodes increase and, the passenger node sends an appointment request, the number of alternative routing paths increases, so the node can choose a more stable routing path to delivery packet; thereby the rate of success calling will increase.

At last, we control node velocity between 0 and 20 m/s; interval of 10 s, transmission range is 500 m, and the density is 4 per square kilometers. Compared to AODV (show as Table 4), the results are shown in Table 2. We can see that the proposed routing protocol performs better than AODV. More importantly, our protocol communication data is scattered throughout the network, while AODV is relatively concentrated. As a result, our protocol performs better in the channel collision. It is because AODV requires a great deal of broadcast to maintain the entire link routing information and has no efficient methods to deal with the disconnection of links.


ParametersValues

Loss modelPropagation/TwoRayGround
Physical modelPhy/WirelessPhyExt
AntennaAntenna/OmniAntenna
Transmission rate2 Mbps
Network protocolIEEE 802.11


Transmission range Density of taxi
46
The probability to find The probability to receive from The probability to find The probability to receive from

200 m14.8%78.5%49.8%95.5%
300 m44.3%91.2%78.4%94.2%
500 m61.1%94.1%87.3%94.6%


CBLIGRAODV

Delivery rate/(%)61.152.3
Control message/packet1206.81815.0

5. Conclusion

This paper proposes a routing protocol for taxi-calling application. Firstly, it analyzes scenes of taxi-calling application and studies the differences between the common vehicle application scene and the taxi-calling application scene. Secondly, it proposes the routing information maintaining algorithm based on position prediction which performs better reliability. Thirdly, a self-network forming method for taxi-calling application is drawn up.

Our protocol queries the destination node by nodes’ keeping the information of the hop count to destination and decreases the routing cost. Meanwhile, the validity of routes is guaranteed by predicting the future position of themselves and their neighbors.

This protocol has also been evaluated by a traffic simulator. The results indicate that our protocol can efficiently find the target nodes in the area. It has also been found that the number of broadcasts is affected by nodes’ velocity. And the fact that our protocol generates 30% less messages than AODV has been proven here.

As to future work, our protocol can probably be extended to solve the low delivery rate problem when the density of vehicle is low.

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

Acknowledgment

This work is supported in part by the Natural Science Foundation of China “Research on the snapshot data security storage technology for authorization of release,” no. 61100057.

References

  1. C. Rezende, R. W. Pazzi, and A. Boukerche, “An efficient neighborhoood prediction protocol to estimate link availability in VANETs,” in Proceedings of the 7th ACM International Symposium on Mobility Management and Wireless Access (MobiWAC '09), pp. 83–90, Tenerife, Spain, October 2009. View at: Publisher Site | Google Scholar
  2. T. Zahn, G. O'Shea, and A. Rowstron, “Feasibility of content dissemination between devices in moving vehicles,” in Proceedings of the 5th International Conference on Emerging Networking Experiments and Technologies (CoNEXT '09), pp. 97–108, Rome, Italy, December 2009. View at: Publisher Site | Google Scholar
  3. N. Wisitpongphan, F. Bai, P. Mudalige, and O. K. Tonguz, “On the routing problem in disconnected vehicular ad Hoc networks,” in Proceedings of the 26th IEEE International Conference on Computer Communications (IEEE INFOCOM '07), pp. 2291–2295, Anchorage, Alaska, USA, May 2007. View at: Publisher Site | Google Scholar
  4. A. Boukerche, H. A. B. F. Oliveira, E. F. Nakamura, and A. A. F. Loureiro, “Vehicular Ad Hoc networks: a new challenge for localization-based systems,” Computer Communications, vol. 31, no. 12, pp. 2838–2849, 2008. View at: Publisher Site | Google Scholar
  5. C. E. Perkins and P. Bhagwat, “Highly dynamic destination-sequenced distance-vector routing (DSDV) for mobile computers,” in Proceedings of the Conference on Communications Architectures, Protocols and Applications (SIGCOMM '94), pp. 234–244, 1994. View at: Publisher Site | Google Scholar
  6. T. Spyropoulos, T. Turletti, and K. Obraczka, “Routing in delay-tolerant networks comprising heterogeneous node populations,” IEEE Transactions on Mobile Computing, vol. 8, no. 8, pp. 1032–1047, 2009. View at: Publisher Site | Google Scholar
  7. C. Lochert, M. Mauve, H. Füßler, and H. Hartenstein, “Geographic routing in city scenarios,” Mobile Computing and Communication Review, vol. 9, no. 1, pp. 69–72, 2005. View at: Publisher Site | Google Scholar
  8. M. Jerbi and S. M. Senouci, “Towards efficient routing in vehicular Ad Hoc networks,” in Proceedings of the 3rd IEEE International Workshop on Mobile Computing and Networking, 2006. View at: Google Scholar
  9. H. Menouar, M. Lenardi, and F. Filali, “An intelligent movement-based routing for VANETs,” in Proceedings of the ITS World Congress, London, UK, October 2006. View at: Google Scholar
  10. K. Shafiee and V. C. M. Leung, Connectivity-Aware Minimum-Delay Geographic Routing with Vehicle Tracking in VANETs, Elsevier B.V., 2010.
  11. J. Haerri, F. Filali, and C. Bonnet, “Performance comparison of AODV and OLSR in VANETs urban environments under realistic mobility patterns,” in Proceedings of the Med-Hoc-Net 2006, 5th Annual Mediterranean Ad Hoc Networking Workshop, Lipari, Italy, June 2006. View at: Google Scholar
  12. C. E. Perkins and E. M. Royer, “Ad-hoc on-demand distance vector routing,” in Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications (WMCSA '99), pp. 90–100, New Orleans, La, USA, February 1999. View at: Publisher Site | Google Scholar
  13. T. W. Chen and M. Gerla, “Global state routing: a new routing scheme for Ad-hoc wireless networks,” in Proceedings of the IEEE International Conference on Communications (ICC '98), vol. 1, pp. 171–175, Atlanta, Ga, USA, June 1998. View at: Google Scholar
  14. B. Karp and H. T. Kung, “GPSR: greedy perimeter stateless routing for wireless networks,” in Proceedings of the 6th Annual International Conference on Mobile Computing and Networking (MOBICOM '00), pp. 243–254, Boston, Mass, USA, August 2000. View at: Google Scholar
  15. D. B. Johnson, D. A. Maltz, and J. Broch, “DSR: the dynamic source routing protocol for multi-hop wireless Ad hoc networks,” in Ad Hoc Networking, C. E. Perkins, Ed., chapter 5, pp. 139–172, Addison-Wesley, New York, NY, USA, 2001. View at: Google Scholar
  16. D. B. Johnson, D. A. Maltz, and J. Broch, “DSR: the dynamic source routing protocol for multi-Hop wireless ad hoc networks,” in Ad Hoc Networking, C. E. Perkins, Ed., chapter 5, pp. 139–172, Addison-Wesley, New York, NY, USA, 2001. View at: Google Scholar
  17. Z. Wei and S. Weibin, “Research of GPSR routing protocol for wireless sensor networks,” Electronic Measurement Technology, vol. 33, no. 9, 2010. View at: Google Scholar
  18. G. Wei, Y. Chen, and X. Zhu, “A vanet-oriented routing protocol for intelligent taxi-call systems,” in Proceedings of the IEEE 14th International Conference on Communication Technology (ICCT '12), pp. 41–45, Chengdu, China, November 2012. View at: Publisher Site | Google Scholar

Copyright © 2014 Xudong Zhu et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.


More related articles

849 Views | 393 Downloads | 0 Citations
 PDF  Download Citation  Citation
 Download other formatsMore
 Order printed copiesOrder

Related articles

We are committed to sharing findings related to COVID-19 as quickly and safely as possible. Any author submitting a COVID-19 paper should notify us at help@hindawi.com to ensure their research is fast-tracked and made available on a preprint server as soon as possible. We will be providing unlimited waivers of publication charges for accepted articles related to COVID-19. Sign up here as a reviewer to help fast-track new submissions.