A Reliable Wireless Protocol for Highway and Metered-Ramp CAV Collaborative Merging with Constant-Time-Headway Safety Guarantee

To realize the grand vision of automated driving in smart vehicle cyber-physical systems (CPS), one important task is to support the merging of connected automated vehicles (CAVs) from a metered-ramp to highway. Certain safety rules must be guaranteed. However, this demand is complicated by the inherently unreliable wireless communications. In this article, we focus on the well adopted constant-time-headway (CTH) safety rule. We propose a highway and metered-ramp CAV collaborative merging protocol, and formally prove its guarantee of the CTH safety and liveness under arbitrary wireless data packet losses. These theoretical claims are further validated by our simulations. Furthermore, the simulation results also show significant improvements in the merging efficiency over other solution alternatives. Particularly, the merging success rates are more than 99% better in 11 out of 18 comparison pairs, and 0% (i.e., tied) ∼ 71% better in the remaining 7 comparison pairs.


INTRODUCTION
To realize the grand vision of fully autonomous driving, one of the most promising directions is to first realize it in controlled environments, particularly in highways, where accesses are limited, and connected autonomous vehicles (CAVs) are collaborative [2,13].One important structure for such limited access highways is the metered-ramp [1,15,24,41,45], where local CAVs are stopped by a traffic signal (i.e., the ramp meter) before they enter the highway system via a ramp.Merging of CAVs from the metered-ramp to highway must be supported.The CAVs involved need to collaborate wirelessly to guarantee certain safety rules, as well as achieve good merging efficiency.
However, these demands are complicated by the inherently unreliable vehicular wireless communications.The solution will heavily depend on the targeted safety rule and the chosen wireless communication paradigm.A panacea solution is highly unlikely.In this article, we shall focus on a widely adopted safety rule, the constant time headway (CTH) safety [8,11,14,30,37,39,47].
Intuitively, CTH safety means at any time instance, any follower vehicle must maintain a constant temporal distance from its predecessor vehicle; i.e., the minimal spatial distance needed is proportional to the follower's current speed.For the wireless communications paradigm, there are two basic categories: vehicle to vehicle (V2V) and vehicle to infrastructure (V2I).Each has its pros and cons.Therefore, a mixed (i.e., V2I+V2V) approach, aka V2X, is gaining increasing attention recently [3,12,43,46].In this article, we shall also adopt the V2X approach: the design is centered on V2I, but V2V communications between line-of-sight neighboring CAVs along the highway lane are also exploited as an alternative for ranging.
In summary, this article shall focus on a wireless highway and metered-ramp CAV merging protocol, which guarantees the CTH safety under arbitrary wireless data packet (simplified as "packet" in the following) losses and achieves good merging efficiency.
Merging of vehicles is a hot research topic in smart vehicle cyber-physical systems (CPS).Besides the large volume of works based on the pure V2V or pure V2I wireless communications paradigm (which are to be elaborated in Section 2), V2X solutions are gaining increasing attention recently.Wang et al. [42] develop a merging algorithm using V2V and V2I communications to facilitate merging of CAVs.Virtual vehicles are mapped onto both the highway lane and the ramp to facilitate the merging of individual vehicles and platoons.Ntousakis et al. [32] propose a cooperative merging system model based on V2V and V2I communication which enables the effective handling of the available gaps between vehicles and evaluate its performance and impact on highway capacity by adopting a microscopic traffic simulator.Wang et al. [43] present a distributed consensus-based cooperative merging protocol, where road side unit (RSU) based infrastructure assigns sequence identifications to different vehicles based on their estimated arrival time (V2I communication), then vehicles apply distributed consensus protocol to adjust their velocity and positions in advance with V2V communications.Ahmed et al. [3] describe a freeway merge assistance system utilizing both V2V and V2I communication.The freeway merge assistance system uses an innovative three-way handshaking protocol and provides advisories to guide the merging sequence.However, the above works (including those based on pure V2V or pure V2I paradigm) do not discuss how to deal with arbitrary wireless packet losses.
There are also works focusing only on the application layer, and are independent of the underlying communication infrastructure (may it be V2V, V2I, or V2X-in another sense, this can be viewed as a more generic V2X) [6,9,22,29,31].However, these works also assume the communication infrastructure is reliable, hence do not deal with arbitrary wireless packet losses.
Aoki et al. [5] present a safe highway and ramp merging protocol, which provides safety by using V2V communications and perception systems cooperatively and accommodates losses of wireless packets.In the protocol, packet losses can decrease traffic throughput, but cannot cause 23:4 X. Fan et al. the proposed solution.The introduction, related work, and problem formulation are covered but very brief (about one page total, with only three references).Prototypes of Figures 1, 3-5, Definition 1, a conjecture of Theorem 1, as well as Ineq.(1), (6) have appeared in [17].That is, this sentence occupies a unique paragraph by itself.The content of this article is also included in the PhD dissertation of the first author [16].

PROBLEM FORMULATION
In this section, we present the assumptions on CAV driving dynamics, describe the highway and metered-ramp merging scenario, and specify the demanded CTH safety.

Assumptions on Driving Dynamics
Vehicular driving dynamics modeling is nontrivial (interested readers can refer to [34]).Fortunately, we can make the following assumptions.

CAV Acceleration.
We assume the CAV acceleration strategy along a straight lane is fixed.Specifically, given the initial speed (for straight lanes, we only need to discuss speed, instead of velocity) v low a and the target speed v ) > 0) and strictly monotonic (i.e., speed will strictly monotonically increase from v low a to v high a over time).

CAV Deceleration.
Similar to the acceleration case, in this article, we assume the CAV deceleration strategy along a straight lane is also fixed.Specifically, given the initial speed v

Merging Scenario and CTH Safety Rule
Figure 1 shows the highway and metered-ramp merging scenario in a bird's-eye view.We assume a metered-ramp leads to a straight highway lane.Mathematically, the highway lane is modeled as a real number axis.The metered-ramp is modeled as a half line.The highway lane and the Any CAV merging into the highway lane via this metered-ramp must first stop at p enter to wait for permission to start.Typically, p enter is where a physical infrastructural ramp meter (such as a red/green traffic light) is installed.But the ramp meter can also be virtual: the CAV simply stops at p enter (e.g., assisted by GPS, or simple visual marks painted on the ramp at p enter ) and waits for a wireless permission message (from certain participants of the collaborative merging) to start.
For the time being, we abstract every CAV as a point mathematically (see the • dots in Figure 1), and let p(x, t ) denote the location of CAV x at wall clock time t.Considerations on vehicle body length are discussed in the end of this subsection.Suppose the whole system starts at wall clock time t 0 , when there are n (n < +∞) CAVs driving at the speed limit v lim (a given configuration constant, the maximum allowed speed on a highway lane, see discussions before Assumption 3) along the highway lane.Without loss of generality, denote the leading CAV to be h 1 , which is followed by h 2 , so on and so forth, till the last CAV h n .We call h i s (i = 1, 2, . . ., n) the "highway CAVs".
Also, at t 0 , a CAV r is stopping at p enter on the metered-ramp waiting for permission to start merging onto the highway lane.We call r the "ramp CAV ".Once started, r should first accelerate as per acc(0, v rm , τ a ) (acc is defined in Section 3.1.1)to the speed of v rm (a given configuration constant, the minimum speed allowed on a highway lane, see discussions before Assumption 3) and then maintains this speed to reach p merge .Correspondingly, Ineq.(1) is the configuration prerequisite to make this feasible: where d a (0, v rm ) is the distance needed to accelerate from speed 0 to v rm (see Section 3.1.1,note the corresponding time cost is δ a (0, v rm )).The duration cost for r from the start of acceleration to reaching p merge hence is We also give the following configuration prerequisite: Correspondingly, once r reaches p merge , it will accelerate again according to acc(v rm , v lim , τ a ) to the speed of v lim .The location on the highway lane where r first reaches v lim hence is fixed.Denote it as p critical (see Figure 1).Note we assume when the merging is completed, all CAVs on the highway shall drive at a same constant speed (specifically, v lim ).This is a popular practice adopted by many collaborative CAV driving schemes [10,25,36,40], particularly in the large volume of literature on cooperative 23:6 X. Fan et al.
adaptive cruise control (CACC) [7,14].This practice prevails not only for its simplicity but also for its safety and energy efficiency [7,10,14,25].On the other hand, the ramp CAV r reaching p merge with v rm , the so-called minimum speed allowed on a highway lane, is a design out of caution.It covers the special case where v rm = v lim − ε, where ε > 0 is an arbitrarily small number.
We also assume the following about the CAVs and the road system for the time being.Assumption 3. The road system is equipped with V2I infrastructure.Particularly, a base station BS resides near p merge , which can coordinate the merging between r and h 1 , h 2 , . . ., h n .For the time being, we assume BS and the highway/metered-ramp lanes are equipped with sufficient wired infrastructure sensors, so that upon BS's request, it can instantly know the distance (from p merge ) and speed of any CAV (this assumption will be relaxed in Section 5).
Assumption 4. Each CAV is equipped with redundant ranging sensors (e.g., laser, radar, ultrasonic, computer vision, V2V communications, and human driver as the last resort), so that for any two consecutive CAVs along the highway lane, the follower CAV can instantly detect the predecessor CAV's speed (e.g., based on the follower's own speed and the relative velocity to the predecessor detected by the ranging sensors).Particularly, due to the redundancy, even if the V2V communications fail (so that the predecessor CAV cannot inform its speed via wireless packets to the follower CAV), the ranging sensing can still function correctly.
Definition 1 (CTH Safety).Suppose two vehicles (in math point abstraction) x and y are driving in the same direction along a same lane.Suppose x precedes y at time t.Denote the distance between x and y at t as d (t ), and y's speed at t as v y (t ).We call δ (t ) def = d (t )/v y (t ) the time headway of y (relative to x) at t.If δ (t ) is no less than a given constant Δ * > 0, aka the desired time headway, then we say the ordered tuple (x, y) is CTH-Δ * safe at t.In other words, if d (t ) v y (t )Δ * , then we say (x, y) is CTH-Δ * safe at t. Assumption 5. ∀i ∈ {1, 2, . . ., n − 1}, (h i , h i+1 ) is CTH-Δ * safe at t 0 .Intuitively, suppose a lane has both a minimum speed limit v min and a maximum speed limit v max , Δ * should be set to Δ * * + D 0 v min , where Δ * * is the maximum duration needed to stop a vehicle at any speed v v max using emergency braking (which could be different from the normal deceleration dec, but should be monotonic), and D 0 is the maximum vehicle body length.This way, CTH-Δ * safety rule guarantees y will never hit x, even if x can abruptly stop at any time on the lane.

SOLUTION
In this section, we propose a protocol to realize the aforementioned highway and metered-ramp merging (see Section 3.2) and prove its guarantee of the CTH safety and liveness, even under arbitrary wireless packet losses.

Heuristics
The heuristics of our proposed protocol are illustrated by the automata sketches in Figure 2.
Initially, the base station BS, the ramp CAV r , and the highway CAVs h i (i = 1, 2, . . ., n) all dwell in their respective "Init" mode.Then the ramp CAV r requests permission to start the merging by sending a "MergeReq" wireless packet to BS (see event "SendMergeReq" in Figure 2(b)).If BS receives this wireless packet, it triggers the "GotMergeReq" event (see event "GotMergeReq" in Figure 2(a)).As the action (i.e., the handling routine) is carried out by this event, BS finds the approaching highway CAV closet to p merge , and names it coop (for "Cooperator").BS then enters the transient mode of "L 0 " to take further actions based on coop's distance to p merge .Specifically, Fig. 2. Automata Sketches.Rectangles are modes, arrows between modes are events, and the arrow without source mode indicates the initial mode in the respective automata sketches.Texts in "[]" are the triggering conditions (aka guards) for the corresponding events; texts after the ":" are the actions to be carried out once the corresponding events happen.
(1) If coop is too far away from p merge , BS will directly allow r to start by sending it a "Start" wireless packet (see "Event1" in Figure 2(a)).(2) If coop is too close to p merge , r 's merge request is ignored and r has to request again in the future (see "Event3" in Figure 2(a)).(3) If coop is neither too far away nor too close to p merge (see "Event2" in Figure 2(a)), BS first sends a "SlowDown" wireless packet to coop to request it to decelerate (i.e., to yield).If coop receives this packet, it will acknowledge BS with an "AcceptSlowDown" wireless packet and start a deceleration routine (see "GotSlowDown" event in Figure 2(c)).Upon reception of the "AcceptSlowDown" wireless packet, BS will send a "Start" wireless packet to r to start its merging routine (see "GotAcceptSlowDown" event in Figure 2(a)).Upon reception of the "Start" wireless packet (see "GotStart" event in Figure 2(b)), r will start and accelerate.Once r reaches p merge , it will accelerate to v lim , and later coop will also accelerate to v lim .In addition, when a highway CAV sees its close (current distance is within a certain threshold) predecessor CAV decelerates or accelerates, it will do the same (i.e., "synchronize" with the predecessor, see mode "Sync" in Figure 2(c)).
For the above cases, how "far" is "too far, " how "close" is "too close, " and how to configure the parameters to achieve the CTH-Δ * safety are non-trivial problems.We will clarify them in the detailed protocol design and analysis (see Sections 4.2 and 4.3).
Another challenge is the possibility of arbitrary wireless packet losses.What if the "MergeReq, " "SlowDown, " "AcceptSlowDown, " and/or "Start" wireless packets are lost?Can the CTH-Δ * safety still sustain?Can the CAVs still reset themselves, instead of being stuck in a mode forever?Can the CAVs still merge efficiently?
To address these concerns, we propose to deploy the "lease" design philosophy for distributed systems [18,38].A "lease" is an agreement on timeout, contracted since the early stage of a 23:8 X. Fan et al. distributed collaboration.After the lease is contracted, if wireless packets are lost, the affected entities can reset themselves when the agreed timeout is reached (by looking at their respective local clocks, hence need no more communications).In Figure 2, nearly every mode has its timeout configuration.The exact configurations to choose are also non-trivial problems that affect the CTH-Δ * safety, system liveness, and efficiency.The details and analysis are also elaborated in Sections 4.2 and 4.3.The efficiency is evaluated in Section 6.

Proposed Protocol
We propose our detailed protocol by expanding the automata sketches of Figure 2 with the heuristics described in Section 4.1.The resulting full-fledged hybrid automata [4] A BS (see Figure 3), A r (see Figure 4), and A i (see Figure 5), respectively, define the protocol behaviors of the base station BS, the ramp CAV r , and the highway CAV h i (i = 1, 2, . . ., n).These behaviors are explained as follows; a symbol list is also provided in Appendix A for the reader's convenience.
Base Station BS protocol behaviors (illustrated by hybrid automaton A BS in Figure 3): (1) At any time instance, the base station BS dwells in one of the following modes: "Init, " "L 0 , " and "WaitingForAcceptSlowDown. " (2) Initially, BS dwells in the "Init" mode, and has its local clock τ 's initial value set randomly from [0, Δ min BS ] (e.g., as per uniform distribution), where Δ min BS > 0 is a configuration constant.(3) When dwelling in mode "Init", if a "MergeReq" wireless packet is received from the ramp CAV r , and BS has been continuously dwelling in "Init" for at least Δ min BS seconds (i.e., τ > Δ min BS ), then BS triggers the "GotMergeReq" event.This event carries out the following action (see event "GotMergeReq" in Figure 3 )| is the current distance between p merge and the coop).After the above action, BS enters the transient mode "L 0 ." (4) Mode "L 0 " is a transient mode that BS cannot stay.Upon entrance to "L 0 , " BS immediately triggers one of the following events (see "Event1, " "Event2, " and "Event3, " respectively, in Figure 3): Case1 (Event1) If the highway CAV coop is too far from the merging point p merge , specifically, if δcoop Δ r + Δ * + Δ 1 , where then BS triggers "Event1." This event carries out the following sequential action: send a "Start" wireless packet (with the data payload of 0) to the ramp CAV r , telling r to start immediately (i.e., with 0 delay); set the local clock τ to 0; undefine coop.After the above action, BS returns to mode "Init." Case2 (Event2) If coop is neither too far nor too close to p merge , specifically, if where then BS triggers "Event2." This event carries out the following sequential action: set δ defer to δcoop − Δ 2 ; send a "SlowDown" wireless packet (with the data payload of δ defer ) to coop, telling it to slow down in δ defer seconds; set the local clock τ to 0. After the above action, BS enters mode "WaitingForAcceptSlowDown" for coop's reply.
Note we enforce the following configuration prerequisite: which implies Δ 2 > 0, and also implies because ( 6) Ineq. (7) ensures the guards for "Event1" and "Event2" (see Figure 3) are valid and non-overlapping.Case3 (Event3) Otherwise, i.e., if coop is too close to p merge , specifically, δcoop Δ 2 , then BS triggers "Event3." This event carries out the following sequential action: set the local clock τ to 0; undefine coop.After the above action, BS returns to mode "Init." (5) When dwelling in mode "WaitingForAcceptSlowDown, " the local clock τ grows continuously (i.e., τ = 1), and must not exceed its range constraint of [0, max{Δ nonzeno , δ defer }], where Δ nonzeno > 0 is a configuration constant, and δ defer is set by "Event2." In this mode, BS may trigger one of the following two events (see "GotAcceptSlowDown" and "AcceptSlowDown-Timeout" events respectively in Figure 3): Case1 (GotAcceptSlowDown) If before τ exceeds max{Δ nonzeno , δ defer }, an "AcceptSlow-Down" wireless packet is received from coop, then BS triggers the "GotAcceptSlow-Down" event.This event carries out the following sequential action: send a "Start" wireless packet to r , telling r to start in δ defer seconds (with the packet data payload of δ defer ); set the local clock τ to 0; undefine coop.After the above action, BS returns to mode "Init." Case2 (AcceptSlowDownTimeout) If local clock τ exceeds max{Δ nonzeno , δ defer }, then BS gives up waiting for the "AcceptSlowDown" wireless packet from coop, and triggers the timeout event "AcceptSlowDownTimeout. " This event carries out the following sequential action: set the local clock τ to 0; undefine coop.After the above action, BS returns to mode "Init." Ramp CAV r protocol behaviors (illustrated by hybrid automaton A r in Figure 4): (1) At any time instance, the ramp CAV r dwells in one of the following modes: "Init, " "Requesting, " "DeferringStart, " "AcceleratingOnRamp, " "ConstSpeedOnRamp, " "Accelerat-ingHighwayLane, " and "ConstSpeedHighwayLane. " (2) Initially, r dwells in the "Init" mode, stops at p enter (i.e., p(r , t ) = p enter ), and has its local clock τ 's initial value set to 0.
Legends: Each rectangle box indicates a hybrid automaton mode (simplified as "mode" in the following).Inside a mode, the top line is the mode's name (it is local to the respective hybrid automata), the rest describes the constraints (e.g., a dwelling duration constraint like 0 ≤ τ ≤ Δ nonzeno ) and continuous domain dynamics (typically specified with differential equations, e.g., τ = 1) related to the mode."L 0 " is a transient mode, whose maximum dwelling duration constraint is 0 seconds, i.e., when the execution enters "L 0 ", it must exit "L 0 " immediately (via a qualified event).
The arrow without source mode indicates the starting mode of execution (τ 's initial value is uniformly sampled from [0, Δ min BS ]).Other arrows represent discrete events for the system.Annotations to each event arrow have the following meanings.Before the ":" is the optional event name and the guard (quoted by the brackets "[]"), i.e., the triggering condition for the event.Particularly, "??(x)" means the event is triggered upon the reception of a wireless packet "(x)" (a wireless packet (x) is a tuple of three or four elements, respectively the type, sender, intended receiver, and optional data payload of the packet).Note a sent wireless packet is not always received: the packet could be lost arbitrarily.After the ":" is the action carried out by the event.Particularly, "!(y)" means a wireless packet (y) is sent; and "←" means value assignment.Same legends also apply to Figures 4 and 5. (3) When dwelling in mode "Init, " r is stopping (i.e., | ˙ p(r , t )| = 0) and the local clock τ grows continuously (i.e., τ = 1).But when τ exceeds Δ nonzeno , r triggers the "SendMergeReq" event.This event carries out the following sequential action: send a "MergeReq" wireless packet to BS; reset τ to 0. After the above action, r enters mode "Requesting" to wait for BS's reply.(4) When dwelling in mode "Requesting, " r is stopping (i.e., | ˙ p(r , t )| = 0) and τ grows continuously.If before τ exceeds Δ nonzeno , the reply from BS, i.e., a "Start" wireless packet (with the data payload of value σ defer ), is received, then r triggers the "GotStart" event, resets τ to 0, and enters the "DeferringStart" mode.Otherwise, if no reply from BS is received till τ exceeds Δ nonzeno , then r triggers the "RequestTimeout" event, resets τ to 0, and returns to mode "Init, " giving up waiting for BS's reply.
Highway CAV h i (i ∈ {1, . . ., n}) protocol behaviors (illustrated by hybrid automaton A i in Figure 5): (1) At any time instance, highway CAV h i (i ∈ {1, . . ., n}) dwells in one of the following modes: "Init, " "DeferringDeceleration, " "Decelerating, " "ConstLowSpeed, " "Accelerating, " and "Sync." (2) Initially, h i dwells in mode "Init, " drives at speed v lim , and the state local variable is set to "Init." (3) When dwelling in mode "Init, " h i may trigger one of the following two events (see "GotSlow-Down" and "StartSyncPred" events, respectively, in Figure 5): Case1 (GotSlowDown) If a "SlowDown" wireless packet is received from BS (with the data payload of value δ defer ), then h i triggers the "GotSlowDown" event.This event carries out the following sequential action (see event "GotSlowDown" in Figure 5): send the "AcceptSlowDown" wireless packet to BS; set state to "Coop"; set local clock τ to 0. After the above action, h i enters mode "DeferringDeceleration. " Case2 (StartSyncPred, only applicable for i > 1) If h i−1 is no more than distance ahead of h i and starts to decelerate from speed v lim , then h i triggers the "StartSyncPred" event, sets state to "Sync, " and enters mode "Sync." (4) Once h i enters the "DeferringDeceleration" mode, h i will first wait for δ defer seconds, then (enter "Decelerating" mode with local clock τ reset to 0) decelerate as per and return to mode "Init" (with state reset to "Init").( 5) Once h i enters the "Sync" mode, h i keeps its speed the same as h i−1 's, until h i−1 recovers its speed of v lim .At that moment, h i triggers the "StopSyncPred" event, sets state to "Init, " and returns to mode "Init." We claim the above protocol for BS, r , and h i (i ∈ {1, . . ., n}) guarantees CTH safety and liveness (i.e., entities will not stuck in any mode), even under arbitrary wireless packet losses.In the next subsection, we shall rigorously describe and prove these properties.

Analysis
We claim the following theorem on sufficient conditions for safety and liveness.

Then we have the following claims.
Claim 1 (Safety).∀t ∈ [t 0 , +∞), for any two CAVs x and y on the highway lane, one and only one of the following sustains: (x, y) is CTH-Δ * safe at t, or (y, x ) is CTH-Δ * safe at t. Claim 2 (Liveness (Automatic Reset)).suppose at t 1 ∈ [t 0 , +∞), the base station BS leaves hybrid automaton A BS mode "Init", while highway CAV h i s (i = 1, 2, . . ., n) are all dwelling in respective A i mode "Init", let then ∃t 2 ∈ (t In order to prove Theorem 1, we need to first propose/prove several definitions and lemmas.
Definition 2 (Coop-duration).For a highway CAV h i (i ∈ {1, 2, . . ., n}), suppose its hybrid automaton variable, state, changes from "Init" to "Coop" at t 1 ∈ [t 0 , +∞), then as per Figure 5, the state must change back to "Init" at some finite t 2 (where t Proof.According to Figure 5, if ∃h i , whose state = "Sync" at t, then there must be an h j in a coop-duration at t. Proof.See Appendix C for details.Corollary 1.Throughout [t 0 , +∞), there is no spatial swapping between h i and h j (∀i, j ∈ {1, 2, . . ., n}, i j) along the highway lane.
Proof.Due to Lemma 5, the first swapping never happens.Lemma 6. Suppose ramp CAV r reaches p merge at t 1 ∈ [t 0 , +∞), then for each i ∈ {1, 2, . . ., n}, one and only one of the following claims sustain: (Claim 1) Proof.See Appendix D for details.Now we are ready to prove Theorem 1.

Proof of Theorem 1 Claim 1:
In case x, y ∈ {h 1 , h 2 , . . ., h n }, the claim sustains due to Lemma 5 and Corollary 1 (in case x and y are not consecutive, e.g., x = h i and y = h i+k , where k > 1, then due to Corollary 1, the distance between x and y is no less than the distance between h i+k−1 and y, hence the CTH-Δ * safety rule still sustains for (x, y)).
In case x ∈ {h 1 , h 2 , . . ., h n } and y = r , or the reverse, the claim sustains due to Lemma 6.
Combining the above two cases, the claim sustains.

Case 1.1:
If r receives the "Start" packet at t 1 , then it will be in "ConstSpeedHighwayLane" by ) is a time instance that matches the claim's description (we call such a time instance a "valid time instance" in the following).Case 1.2:If r did not receive the "Start" packet at t 1 .Then, as r sent the "MergeReq" packet at t 1 , it will be at "Init" at t 1 + Δ nonzeno < t 1 + Δ min BS (due to (c2)).Meanwhile, h 1 ∼ h n remains in "Init" at t 1 + Δ nonzeno .Hence t 4 def = t 1 + Δ nonzeno is a valid time instance.Case 2: "Event2" happens at t 1 .Then by t 1 +max{Δ nonzeno , δ defer }, BS should have returned to "Init" and remain there till at least t 1 + Δ min BS .Meanwhile, it will not send another "SlowDown" packet during (t 1 , t 1 + Δ min BS ] at least.(♣) Case 2.1: h coop receives the "SlowDown" packet at t 1 .Then the coop-duration starts at t 1 and ends at t Meanwhile, as per (c2), ∃ε ∈ (0, Δ Due to (♣), a second coop-duration will not start till after t 1 + Δ min BS .Hence due to Lemmas 2 and 3, we know h 1 ∼ h n are all in "Init" at t 6 and at t 7 .Case 2.1.1BS receives "AcceptSlowDown" at t + 1 , it sends ("Start", BS, r , δ defer ) at t + 1 .(a) r receives the "Start" packet at t + 1 .Then it reaches "ConstSpeedHighwayLane" at t 1 + δ defer + Δ r + δ a (v rm , v lim ) < t 6 .Hence t 6 is a valid time instance.
(b) r did not receive the "Start" packet at t + 1 .Then at t 6 , it must be in "Init" or "Requesting".In this case, if r is in "Init" at t 6 .Then t 6 is a valid time instance; If r is in "Requesting" at t 6 .Then r must have switched to "Init" at t 7 .Then t 7 is a valid time instance.
Then similar to the analysis of item (b), if r is in "Init" at t 6 .Then t 6 is a valid time instance; If r is in "Requesting" at t 6 .Then t 7 is a valid time instance.
Combining  The proof of CTH guarantee under arbitrary wireless packet losses of the above priority-based protocol follows the corresponding proof for the proposed protocol, as the priority-based protocol is basically a subset of the proposed protocol.
The other comparison alternative, Wang et al. [43]'s consensus-based protocol, is a highway and ramp merging protocol using V2X communications.The protocol can achieve good CTH safety statistically, but it does not focus on CTH guarantee under arbitrary wireless packet losses.We choose to compare with this protocol because it covers V2X communications, highway and ramp merging, and CTH safety.Similar to Aoki et al. [5]'s work, the focus problem context does not exactly match ours but is among the closest.
Next, we shall discuss the simulator configurations and the evaluation results.
Note the above configurations comply with the constraints demanded by Theorem 1, as well as the recommendations of the consensus-based protocol [43].
At the beginning of each simulation trial, our simulator generates n (n = 120, 180, or 240, respectively for light, mild, and heavy traffic; n's value is fixed for each individual simulation trial) highway CAVs along the highway lane segment [−50, 000m, 0m], where the location at 0m is p merge .The exact initial locations of the n highway CAVs are randomly chosen as per a pseudo-uniform distribution, which takes into consideration of Assumption 5. Specifically, the pseudo-code is as follows: Step1 The generated H is the initial location for the highway CAVs for the trial.
Our simulator also adopts a wireless packet loss rate parameter P, whose value is set to 0.1 (i.e., 10%), 0.5 (i.e., 50%), or 0.9 (i.e., 90%) to evaluate the proposed protocol under mild, moderate, and severe wireless packet losses (P's value is fixed for each individual simulation trial).
For each given n and P values, we run 25 simulation trials.Each trial simulates 10 minutes (unless in some exception cases, see the last paragraph of Section 6.3) of a highway and meteredramp merging scenario.

Safety
Theorem 1 Claim 1 is on the CTH-Δ * safety guarantee.To validate this claim, Table 1 shows the statistics of sampled time headways (relative to the respective immediate predecessor vehicles, see Definition 1) of all vehicles in all simulation trials (for each vehicle simulated, its time headway is sampled every 0.4s).According to Table 1, for the proposed protocol, the time headways are always no less than 3.0s, which means the CTH-Δ * safety (remember Δ * is set to 3s, see Section 6.1) holds. 2 For the priority-based protocol, which basically is a subset of the proposed protocol, the CTH-Δ * safety also holds.For the consensus-based protocol, the time headways cannot always satisfy CTH-Δ * safety.Corresponding failures are highlighted in light gray in Table 1.

Liveness (Automatic Reset)
Theorem 1 Claim 2 is on liveness guarantee, particularly in the sense of automatic reset.It proves the boundedness of reset time.This is confirmed by our simulations.According to Table 2, for the proposed protocol, all reset time costs are within the theoretical bound of Δ max reset = 50.4s.Note for all protocols, for given n, as wireless packet loss rate P rises, more resets return to Stable State 1 instead of Stable State 2 (see Theorem 1-Claim 2 for definitions).The former can happen as fast as a sub-second software reset (though not always); while the latter must involve physical movement, hence usually costs tens of seconds.Also, note that normally each simulation trial lasts 10 minutes (in the simulated universe).But in case by the end of the 10th minute, the system is still waiting for a reset to happen, the simulation will go on till the reset happens.

Merging Success Rate and Time Cost
Besides safety and liveness guarantees, we are also concerned about the merging success rates and time costs.Merging success means before the end of the simulation trial, the ramp CAV is merged into the highway lane, all vehicles on the highway lane reach speed of v lim , and the CTH-Δ * safety is maintained at all times.Merging time cost is the total time cost from the start of the merging scenario to the first time instance when merging success is achieved.For a simulation trial where merging success is never achieved, merging time cost is not applicable.
Table 3 shows the merging success rates and merging time cost statistics.According to the table, for any given n and P (referred to as "(n, P ) combination" or simply "combination" in the following), we have 2 comparison pairs: the proposed protocol versus the priority-based protocol, and the proposed protocol versus the consensus-based protocol.Hence for all the 9 combinations of n and P (light, mild, and heavy traffic versus low, mild, and high wireless packet loss rates), we have 9 × 2 = 18 comparison pairs.Out of these 18 comparison pairs, there are 11 of them, where the proposed protocol's merging success rates are more than 99% better than the comparison counterpart's. 3his improvement is mainly because the proposed protocol focuses on two aspects simultaneously.It not only guarantees CTH-Δ * safety under arbitrary wireless packet losses but also proactively coordinates the highway CAVs and the ramp CAV: when traffic is heavy, it asks the highway CAVs to yield to the ramp CAV.In comparison, neither of the other two protocols focuses on both of the aforementioned aspects.
More specifically, for all the 9 combinations of n and P, the consensus-based protocol fails all the 25 trials (i.e., success rate = 0) for 6 combinations; the priority-based protocol fails all the 25 trials (i.e., success rate = 0) for 3 combinations; while the proposed protocol only fails all the 25 trials (i.e., success rate = 0) for 1 combination, which corresponds to the heaviest traffic and highest wireless packet loss rate (i.e., (n = 240, P = 0.9)).Also, for (n, P ) combinations where the consensus-based protocol succeeds for some trials (i.e., success rate > 0), the proposed protocol's merging time cost statistics are all comparable with (and usually better than) those of the consensus-based protocol's.Same is for the priority-based protocol.

CONCLUSION AND DISCUSSION
In this article, we propose a protocol to realize the safe merging of CAVs on highway and meteredramp.We formally prove that the protocol can always guarantee the CTH safety and liveness, even under arbitrary wireless packet losses.These theoretical claims are verified by our simulations, which also show significant performance improvements over other alternatives.
This article also exemplifies the importance of introducing cyber-physical transactions and hybrid automata in the design and analysis of CPS.Particularly, Lemma 2 isolates possible combinations of discrete events and continuous maneuvres into mutually exclusive coop-durations (i.e., cyber-physical transactions).This greatly simplifies the design and analysis.Meanwhile, the specifications of the protocol and the formal proof of the CTH safety guarantee would be difficult (if not impossible) without the help of hybrid automata.
In future work, we will do the following.(FW1) Take into consideration of wireless transmission and propagation delay.This delay shall be in the order of magnitude of 10 μs, which corresponds to distance errors in the order of magnitude of millimeters.
(FW2) Carry out sensitivity study: allow more variations in the various physical parameters, such as CAV velocities.As demonstrated by this article, the analyses are expected to be nontrivial and deserve multiple articles.Fortunately, the continuous nature of the physical world will bind the deviations from this article's formal models.This can help us to speculate the sensitivity.For example, suppose the CAV velocity error is bounded by V m/sec; as a coop-duration is bounded by Δ max reset , (suppose CTH is satisfied at the start of the coop-duration) then we can expect that the inter-CAV distance error from CTH safety is bounded by 2V Δ max reset when the coop-duration ends.(FW3) Analyze the impacts when the number of packet losses is bounded.For example, whether there can be a time bound on the success of the merging.
(FW4) Derive necessary conditions for safety and liveness.We may start by negating the sufficient conditions listed in Theorem 1.

APPENDICES
A SYMBOL LIST Symbols used in the article are listed alphabetically (Greek before Latin, and upper case before lower case) in the following.(6) δ defer is a runtime variable created by A BS at "Event2" (note Ineq.(7) ensures δ defer > 0), but may be sent to A i (i ∈ {1, 2, . . ., n}) in case h i is chosen as the coop.It basically requests h i to start deceleration (i.e., to yield) in δ defer seconds.(7) σ defer is a runtime variable for A r (see Figure 4).It is the data payload parameter received via the "Start" packet.In case the packet is sent by BS via "Event1" (see Figure 3), σ defer = 0.In case the packet is sent by BS via the "GotAcceptSlowDown" event, σ defer = δ defer .Upon reception of a "Start" packet, r will defer σ defer seconds before actually starting the acceleration (i.e., entering the "AcceleratingOnRamp" mode of A r ).( 8) τ represents a runtime timer; it is a local variable to each hybrid automaton.Note for A BS , the initial value of τ (when the system starts, i.e., at t 0 ) can be any value in [0, Δ min BS ] (e.g., randomly chosen as per uniform distribution from this range); for A r and A i (i = 1, 2, . . ., n), the initial value of τ is 0. ( 9 ( ) Suppose the coop-duration (t 1 , t 2 ] belongs to h ı (ı ∈ {1, 2, . . ., n}).Then we have the following cases.Case 1: First we discuss h j , where j < ı.As coop-durations cannot overlap nor connect, ∀j ∈ {1, 2, . . .,ı − 1}, as per A j (see Figure 5), throughout (t 1 , t 2 ], h j must remain in mode "Init".That is, for any h j and h j+1 (j ∈ {1, 2, . . .,ı − 2}), throughout (t 1 , t 2 ], both retain the speed of v lim .hence (h j , h j+1 ) is CTH-Δ * safe throughout (t 1 , t 2 ].For h ı−1 and h ı , as h ı−1 retains the maximum allowed speed, v lim , throughout (t

2 .
suppose currently the deceleration process has been going on for τ d seconds (τ d 0) and has not yet finished, then the CAV's current acceleration value is fixed, and is a function of v high d , v low d , and τ d .Denote this function as dec(v high d , v low d , τ d ).This function implies that the current speed of the CAV is also a function of v high d , v low d , and τ d , which can be denoted as v d (v high d , v low d , τ d ).This in turn implies that the total duration and distance needed to decelerate from v high d to v low d is a function of v high d and v low d .We denote this duration and this distance to be respectively δ d (v high d , v low d ) and d d (v high d , v low d ).Furthermore, we have Assumption We assume the deceleration process as per dec(v high d , v low d , τ d ) (where v nonzeno (i.e., δ d (v high d , v low d ) > 0) and strictly monotonic (i.e., speed will strictly monotonically decrease from v high d to v low d over time).

Fig. 1 .
Fig. 1.The highway and metered-ramp merging scenario.p(x, t ) is CAV x's location at wall clock time t.Drawn based on our intellectual property.Early version appeared in [17] Figure 1.

Fig. 3 .
Fig. 3. Hybrid automaton A BS for the base station BS.Drawn based on our intellectual property.Early version appeared in [17] Figure 2.

Fig. 4 .
Fig. 4. Hybrid automaton A r for the ramp CAV r (τ 's initial value is set to 0).Drawn based on our intellectual property.Early version appeared in [17] Figure 3(a).
, and note in this article, we assume vehicles cannot move backward), suppose currently the acceleration process has been going on for τ a seconds (τ a 0) and has not yet finished, then the CAV's current acceleration value is fixed, and is a function of v low a , v high a , and τ a .Denote this function as acc(v low a , v high a , τ a ).This function implies that the current speed of the CAV is also a function of v low a , v high a , and τ a , which can be denoted as v a (v low a , v high a , τ a ).This in turn implies that the total duration and distance needed to accelerate from v low a to v high a is a function of v low a and v high a .We denote this duration and this distance to be respectively δ a (v low a , v high a ) and d a (v low a , v high a ).Furthermore, we have Assumption 1.We assume the acceleration process as per acc(v low a , v high a , τ a ) (where 0 v low a < v high a ) is nonzeno (i.e., δ a (v low a , v high a BS, and the ramp CAV r are in respective hybrid automata mode "Init"; or (Stable State 2) at t 2 , h 1 , h 2 , . . ., h n , and BS are in respective hybrid automata mode "Init" and r is in A r 's mode "ConstSpeedHighwayLane".

Case 2.1.1 and Case 2.1.2, Case 2.1 complies with the claim. Case 2.2 h
coop does not receive "SlowDown" at t 1 .Then nothing happens to h 1 ∼ h n during [t 1 , t 1 + Δ min BS ].Let t 8 def = t 1 + max{Δ nonzeno , δ defer }, t 9 def = t 8 + ε, t 10 def = t 9 + Δ nonzeno , where ε is the same ε chosen for Case 2.1.Then (c2) and (c4) imply 0 < t 8 < t 9 < t 10 < t 1 + Δ min BS .Hence at t 9 and t 10 , BS and h 1 ∼ h n are in "Init".Considering r , we have the following two cases.Case 2.2.1 r is in "Init" at t 9 .Then t 9 is a valid time instance.Case 2.2.2 r is in "Requesting" at t 9 .Then t 10 is a valid time instance.Then (c2) and (c4) imply t 1 < t 11 < t 12 < t 1 + Δ min BS .Hence at t 11 and t 12 , BS and h 1 ∼ h n are in "Init".Considering r , we have the following two cases.Case 3.1 r is in "Init" at t 11 .Then t 11 is a valid time instance.
initialize H to empty set; Step2 IF (|H | n) THEN terminate; ELSE Step2.1 randomly choose a point p on the highway lane segment [−50, 000m, 0m] as per uniform distribution; Step2.2IF p does not violate CTH-Δ * safety rule with the points already in H THEN add p into H ; ELSE ignore p; Step2.3 go back to Step2.

Table 2 .
Simulation Results: Reset Time CostSee Table1for definitions of n and P .Note according to Theorem 1-Claim 2, the reset time costs of the proposed protocol shall be upper bounded by Δ max reset = 50.4s.

Table 3 .
Simulation Results: Merging Success Rate and Time Cost See Table1for definitions of n and P ; n.a.: not applicable.
(11)1 , D r are both configuration constants with positive values, see Equation(8), Ineq.(1), respectively.(10)acc is the predefined acceleration strategy, see Section 3.1.1.(11)coopisaruntime variable for hybrid automaton A BS only, whose value can only be "undefined" or h i (i ∈ {1, 2, ..., n}).Intuitively, it refers to the closest approaching highway CAV toward the base station BS.(12) d a (v 1 , v 2 ) is the total distance needed to accelerate from v 1 to v 2 (where 0 v 1 < v 2 ), see Section 3.1.1.(13)d d (v 2 , v 1 ) is the total distance needed to decelerate from v 2 to v 1 (where v 2 > v 1 0),see Section 3.1.2.(14) dec is the predefined deceleration strategy, see Section 3.1.2.(15) p(x, t ) is the location of vehicle x at wall clock time t.Correspondingly, | ˙ p(x, t )| is the speed of vehicle x at t, and ¨ p(x, t ) is the acceleration (deceleration) of x at t. (16) state is a runtime variable for A i (i = 1, 2, . . ., n) only, whose value can only be "Init", "Coop", or "Sync".Note the initial value of state is set to "Init".(17) t is the current wall clock time; it is a global variable.(18) v lim and v rm are configuration constants related to CAV speed.They are, respectively, the maximum and minimum allowed speed on the highway lane.See Section 3.2 and Ineq.(3) for more information.Proof: First, as (t 1 , t 2 ] is the first ever coop-duration, due to Assumption 5 and Lemma 3, h 1 , h 2 , . . ., h n all reside in hybrid automata mode "Init" throughout [t 0 , t 1 ], hence ∀t ∈ [t 0 , t 1 ], (h i , h i+1 ) (i = 1, 2, . . ., n − 1) is CTH-Δ * safe.