{'fraction_non_alphanumeric': 0.02705374330159721, 'fraction_numerical': 0.010353259455803548, 'mean_word_length': 4.4161735700197235, 'pattern_counts': {'":': 0, '<': 1, '<?xml version=': 0, '>': 1, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
A Direction-Based Make-Before-Break Routing Protocol for Vehicular Ad Hoc Networks

In this paper, we present a novel “Make-Before-Break” routing protocol for VANETs (Vehicular Ad Hoc Networks) which brings stability in route even if it contains some nodes moving opposite to the rest. Few of the existing routing protocols contain the mechanism to prevent route disruption caused by link breakages between oppositely moving nodes in a partitioned network. In our protocol, a node does not forward a RREQ (Route Request) received from a node moving in opposite direction unless a special request is made by that node in RREQ packet. The node which accepts this special request and forwards the RREQ, despite moving opposite to the previous node is called complier node. The complier node adds its information in the RREQ packet. On receiving RREQ, the destination knows that complier node is moving towards some successive nodes in the routing path. Through the RREP (Route Reply), it informs those nodes about the complier node. Each of these successive nodes waits for the approaching complier node. When it comes near, each establishes connection with the complier node on its turn. Thus the route from source to destination is maintained. The proposed protocol achieves packet delivery ratio of 85% under very large speed variation condition among vehicles’ speed.

nowadays [1]. Besides numerous safety applications, many entertainment applications of VANETs are being proposed [2][3]. Dedicated data communication between two vehicles on the road requires a fixed multi-hop route between them. Extremely high mobility of vehicles on highways makes the task of providing stable route very challenging. Sometimes when node density is not high, a VANET may get partitioned.
In this case, all the vehicles transferring data are not System) [4][5][6][7]. Some of these position-based routing protocols use a fixed route to transfer data from source to destination while the others just "push" the data towards the destination [8][9].
A GPSR (Greedy Perimeter Stateless Routing) protocol has been proposed in [10] where each node forwards the data packet to the node closest to the destination among its neighbors. Sometimes, at bends on the roads, a node may find no node closer to the destination than itself.
Perimeter routing is employed in such situations i.e. the prescribed node forwards the data to the first of its neighbors in a particular direction, say clockwise. This protocol is not very promising in VANETs where routing holes needing perimeter routing or some other recovery mechanisms frequently occur lowering the performance [11][12].
A broadcasting protocol SIFT (Simple Forwarding over Trajectory) is presented in [13], in which data packets are broadcast after appending trajectory information to them.
If a node not located within the indicated geographical path happens to receive the packet, it drops it. All other receiving nodes initiate countdown timers. The initial value of timer depends on distance from the previous node. The far the distance from previous node, the lower is the initial value of timer. The node whose timer reaches zero first, broadcasts the data packet. The other nodes stop their timers and discard the data packet after hearing this broadcast. A major defect in the above protocol is the delay caused by setting timers [14].
Authors in [15] introduced a scheme to select an optimal route based on the expected lifetimes of individual links.
Observing that on the highways, typically a vehicle stays on the same lane for an exponentially distributed amount of time, it derived equations to compute the time any two vehicles with different speeds are likely to stay in the radio range of each other and found that optimality criterion for a stable route allows only monotone change in speeds of successive intermediate nodes. This is not a complete protocol and assumes that all vehicles including the destination are moving in same direction [16][17].
A Movement Prediction-based Routing Protocol for Vehicle-to-Vehicle Communications has been proposed in [18] where selective nodes with small differences in their speeds are chosen for the route and route remains intact for at least a predetermined amount of time unless some disruption at PHY level causes a link in the route to break early. One of the methods in our algorithm uses this procedure for node selection. This protocol is silent on the methodology required for route maintenance in case where a node finds only oppositely moving nodes in its radio range and selection of none of those can satisfy the criterion or route maintenance for the specified time.
Some protocols deal with VANET routing in areas where traffic is sparse. But the traffic density considered therein is permanently very low and nodes often don't find any neighbor moving in either direction [19]. They have to store data packets till they come across some nodes.
None of the previously published protocols known to authors, has the procedure to enhance lifetime of routes when network is partitioned in one direction only under normal traffic conditions. [20] observed that in VANETs on highways, there are expected 10 partitions in one direction per 10 km (the expectation of partitions in both directions creating a sparse network is of course less) if on the average, a vehicle has radio range of about 200m [21].The objective of this work is to develop a reactive routing protocol for VANETs in a highway environment which can: (i) Ensure long-time route maintenance between source and destination involving some nodes moving opposite to them by replacing a soonto-break portion of route in small time with a new sub-route before breakage.
(ii) Detect loss of data packets because of weakened PHY conditions in time and replace the route like other protocols using fixed routes do.
Our proposed protocol uses packet formats similar to those in AODV (Ad Hoc On-Demand Distance Vector) routing, which gives reasonable performance at low and moderate mobility rates in mobile ad hoc networks [22].The designed protocol was tested in Qualnet 3.9 simulating VANETs on a highway with varying speeds of vehicles, the maximum being 200 km/h. Results show that our protocol outperforms AODV in terms of packet delivery ratio and delay, managing to save time spent in route discoveries.

MAKE BEFORE BREAK ROUTING
An efficient VANET routing protocol exploits the predictability of mobility pattern of vehicles which is often possible with considerable accuracy, thanks to the constraints of road geometry. This section presents a new routing protocol for VANETs on highways, named "A Direction-Based Make-Before-Break Routing Protocol for Vehicular Ad Hoc Networks." In this protocol, propagation of a RREQ is done only by nodes having same direction of motion as its originator, provided the availability. A special node called Complier node may be moving oppositely to the rest of nodes in the route. Each of those nodes, during continuous data transmission, manages to establish connection in quick time with that oppositely moving Complier node which was not its next hop in the route earlier on. Two methods for RREQ dissemination are presented for the proposed protocol. One is the broadcast method in which source and intermediate nodes broadcast the RREQ and multiple RREQs reach the destination node which responds to the one arriving earliest and ignores the rest. Second is node selection method proposed by [18].Each node unicasts the RREQ to a node which is likely to remain in its radio range for a certain period of time. In both methods, each node periodically broadcasts Hello messages containing its location and velocity information.

Principles of Operation
The rules or principles on which our protocol operates are as follows.
(i) Our protocol named as Make-Before-Break protocol is a reactive routing protocol i.e. a source node broadcasts RREQs for a destination node only when it needs to send data to that destination node.  In this way, some RREQs reach D which sends a RREP in response to the first of them. Exact format of the route reply is given in next section but here it will suffice that D sends RREP to S with empty Be Alert For field.

When P Bit is Set to 1 by One of the Nodes in RREQ
Propagation Path: Now consider the scenario shown in because it knows that in its radio range, there is another node (1) travelling in the same direction (thanks to periodic Hello messages broadcast by 1). Node 1 receives this RREQ. Now, node 1 has not received any Hello message from another node (apart from S) moving in the same direction for a while. Therefore, RREQ must be propagated forward by one node or a sequence of nodes moving in direction opposite to node 1 now. So, Node 1 sets P bit = 1, Switch Count = 1, (and Prop Dir = 1 as before) in the received RREQ. Node 1 also puts its location, velocity and hop count to node S in the RREQ (Node 1 is Switcher 1 as per Table 1) and rebroadcasts it. Node 2 receives this RREQ with P bit = 1 and comes to know that there is scarcity of vehicles moving to the right. Complying with the request made by node 1, node 2 further broadcasts the RREQ despite moving oppositely to node 1. Switch Count is maintained as 1 and P bit is set to 0 again because node 2 knows that another node, Node 3, is moving in the same direction as itself and our protocol does not allow unnecessary switching of moving directions of vehicles in the RREQ propagation path. Node 2 also puts its location and velocity in the RREQ (Node 2 is Complier 1 as per Table 1) before broadcasting. Node 3 receives the RREQ broadcast by node 2. It knows that there is no node moving in the same direction as itself so it rebroadcasts RREQ after setting P bit = 1, incrementing Switch Count to 2 and putting its location, velocity and hop count to S (Node 3 is Switcher 2 as per Table 1). In this manner, RREQ reaches node D.
RREP Format: A node receiving the RREQ also makes a routing table entry for itself which tells it how to reach source node S if it requires so in future. This is why same nodes are involved in RREQ propagation in Fig. 1(b) and RREP forwarding in Fig. 2. Now, on reception of RREQ from node 1, node 2 also stores the route to source node S as per  Fig. 3. We have supposed direction of  Table   3. In the RREP, D puts Switch Count = 1 in accordance with the procedure defined in the previous section. Table   3 shows the route inserted by S when RREP reaches it. D is moving nearer to S, 1, and 2. It will cross each one of these in future. Consider a possible situation of future in Fig. 4. If our protocol just confines the RREQ traversal to 1, 2, and 3 having same direction, the fraction of route up to 3 will of course remain stable for a long time but this stability will not be significant since last link in the route (3    D) will break very soon. These breakages during continuous data transmission cause data loss as again and again, route is lost after rediscovery. Similarly, S and 1 also make entries in their Alert tables.

FIG. 2. SWITCH COUNT INCREMENTS IN RREP PACKET
Route Update Message: Note the To Be Told field in Table   4. IP address of S is copied here from the Source IP address field of RREP. It implies that each of the nodes S, 1, or 2, on reception of a Hello message from Approaching node D, will not only change its routing table entry for D (Table 5) but will also send an Update message to D: "I am your next hop for S." On receiving this Update message, D changes its routing table entry for S as shown in Table 5. Because of the Update message, the reverse route from D to S is also maintained just like the forward route from S to D. Hence, our algorithm ensures symmetric routes.
Note that P Bit is never set unnecessarily to 1. Message is always propagated first on nodes travelling in the same direction as the forwarder node as our goal is to increase   . 5)

FIG. 5. UPDATING PROCEDURE: (1) NODE 2 RECEIVES HELLO FROM NODE D, (2) NODE 2 UPDATES ITS ROUTING TABLE ENTRY FOR NODE D,(3) NODE 2 SENDS UPDATE MESSAGE TO NODE D, (4) NODE D UPDATES ITS ROUTING TABLE ENTRY FOR NODE S
(node 2) to source node (S) (2 hops). If node D nominates node 7 (Complier 1) as Approaching node in the Be Alert For field and thus directs nodes S and 1 to perform updates, then after the second update by node S, route will have to be rediscovered as no more update is possible (Fig. 7). Node D thus nominates node 2 (Switcher 1) as Approaching node in the RREP so that nodes 8, 9, and 10 may establish connection with node 2 (3 updates) before ultimate route loss. Table 4 shows the Alert table entries made by 8 and 9 on reception of RREP from D and D itself on reception of RREQ. Note that in the To Be Told field, address of destination node D is copied rather than that of source node S because Approaching node(the leading vehicle of a small queue which is heading towards a large queue of vehicles) here is Switcher 1, not Complier 1. In this manner, we can maintain the route between S and D for long time by incorporating as many updates as possible. is allowed to set P bit TRUE and ask an oppositely moving node to forward RREQ. Asking this many times will kill the purpose. Also, the distance between source and destination nodes in VANETs is limited to a few kilometers and need for making this special request more than twice is not likely to arise.
In Fig. 8 Local Repair: Successive nodes having same direction can also experience link breakages between them because of having different speeds. Make-Before-Break routing has a local repair procedure for these situations. Node 1 detects in Fig. 9 that its link with node 2 has broken so it broadcasts a RREQ which reaches node 3 through node 9. As node 3 has an entry in its Alert Table which tells that D is approaching towards it, so it informs node 9 about this Approaching node D through RREP. Node 9 also becomes alert for D.

Node Selection Method
When RREQ is broadcast, all of the receiving nodes (albeit having same direction here) rebroadcast it. The destination responds to the first request. As pointed out by [18], successive nodes in the route may be almost radio range apart at the time of route [18] have suggested a method to tackle this problem which we use as the node selection method in our algorithm. Each node unicasts the RREQ it generates or receives to a carefully selected node which is likely to remain within its radio range for quite a while.
Consider Fig. 10. Solid cars show the current and dotted circles show the future positions of nodes i and j.
Suppose the present locations of node i and node j are (X i0 ,Y i0 ) and (X j0 ,Y j0 ) respectively. The present distance between them is d and future distance is represented by D. Let the speeds of node i and node j be V i and V j respectively. If they reach the positions indicated by dotted circles in time T, distance between them at that time can be calculated [11]: Where V xi represents the x-component of velocity of i and so on. Our node selection algorithm is given below: (1) Node i finds by applying Equation (2) which of its neighbors will still be in its radio range after T = 6 seconds (which node will satisfy D < R where R is the radio range of node i).
(2) Among those neighbors, the one whose d (present distance from node i) is maximum, is chosen as next hop of node i.
If decision for next hop is made solely on the basis of expected lifetime of the link, we may end up with smaller inter-node distances. This increases the number of hops and adversely affects overall end-to-end delay [15]. The method given above prevents this as any node which remains in the radio range of node i for T > 6 s is a candidate for being selected as next hop of node i. We make the final selection on the basis of separation between selecting and to-be-selected nodes so that total number of hops does not increase significantly.  P bit is not required as a node which receives a unicast RREQ from oppositely moving node, automatically knows it is a Complier node.
The node selection implementation of our Make-Before-Break protocol outperforms the broadcast implementation.
It further reduces the number of control messages as successive nodes having same direction in the route can remain in each other's radio range even for the whole duration of communication.

SIMULATION TESTS AND RESULTS
We have conducted the simulation of prescribed protocols in Qualnet 3.9. From this point onwards, the term "MBB Broadcast" will be used for our protocol with broadcast method.Similarly, we name our protocol with node selection method as "MBB Selection" (MBB stands for Make-Before-Break).

Simulation Setup
We assume a simulation area of 3000x32 m which represents 3 km portion of a highway with 2-way traffic.    Fig. 13(d). Thus the total number of control messages continues to increase. (A RREQ has to be initiated when the link between source node and first intermediate node breaks). Fig. 13(g) shows end to end delay in all three protocols increases with increasing maximum speed. This is a direct follow-up of PDR trend. In MBB, PDR is high so delay is low. Fig. 13(d) shows number of route requests issued for local repair and Fig. 13(e) shows the corresponding time spent to wait for replies to local repair requests. We observe that more repairs are possible in MBB Broadcast than in AODV. This is understandable because in AODV, a node often finds that it cannot repair a route locally as there is danger of loop formation if RREQ reaches the source node. In contrast, MBB is direction-aware routing where RREQ for repair is sent in the direction of destination node only thwarting all chances of loop formation. Repairs are less in MBB Selection because need for repairing route seldom arises thanks to stable routes (leading to high PDR).  Fig . 15 shows the performance metrics' behavior with increasing maximum speed. Fig. 15(a) reveals that PDR of MBB Selection is the highest once again. The PDR for all three protocols however remains lower than that in theprevious scenario. As destination is moving away from the last intermediate node, the sub-route between the destination and the previous node breaks more frequently. Again, route update time is very small (Fig 15(f)), delay increases with increasing maximum speed ( Fig. 15(g)), and route repair time remains in milliseconds for all three protocols ( Fig. 15(e)). Fig. 15

CONCLUSIONS
Vehicles can move with very high speeds in a highway environment. Partitioning of network in one direction under such conditions is not unusual. This brings in the inevitability of including some nodes moving in direction opposite to all others in the route.
Our algorithm prevents the disruption of route caused by link breakages between these oppositely moving nodes.
Simulation results show that our "Make-Before-Break" routing protocol outperforms AODV, yielding packet delivery ratio 31% higher and end to end delay 20% lower than the corresponding outputs of AODV.
At night, traffic is less on highways causing frequent partitions. Our protocol can be used in such conditions.
We suggest our protocol to be used in entertainment