Edge-powered Assisted Driving
For Connected Cars

Similar to existing works [11, 12, 16, 17], we model the road topology under the control of the edge server as a set of interconnected queues $q_{i}\in\mathcal{Q}$, as exemplified in Fig. 3. Similarly to existing works (including experimental validation [21, 17]), each queue represents a road segment, characterized by, e.g., a certain speed limit and capacity.

Service rates, $\mu_{i}$, are bounded by a maximum value $\mu^{\max}_{i}$, determined by the length of the road segment modeled by queue $q_{i}$, its speed limit, and the inter-vehicle safety distance:

Several traffic flows, $k\in\mathcal{K}$, may travel across the road topology or part of it, each flow being defined as a set of vehicles having the same source and destination within the road topology. Specifically, given a flow $k$ entering and leaving the road topology at queue $q_{i}$ and $q_{o}$, respectively, the parameter $\Lambda^{k}_{i}$ denotes the vehicles arrival rate, while parameter $M^{k}_{o}$ denotes the rate at which they exit the topology. For every flow $k$, there is exactly one queue $i$ for which $\Lambda^{k}_{i}>0$ and one queue $o$ for which $M^{k}_{o}>0$ (see Fig. 3); furthermore, these two quantities are the same, as all vehicles of the flow begin their route at queue $i$ and end it at queue $o$. Note that $\Lambda^{k}_{i}$ and $M^{k}_{o}$ are known parameters for the algorithms, which can be obtained by the edge server leveraging the CAMs periodically transmitted by the vehicles. Vehicles move from a generic queue $i$ to queue $j$ according to probability $\alpha_{ij}$.

Given the above model, our decision variables are the service rates $\mu_{i}$ of queues $q_{i}\in\mathcal{Q}$, and the transition probabilities $\alpha_{i,j}$ (although some $\alpha_{ij}$ can be fixed, e.g., in Fig. 3, $\alpha_{4,5}=1$). The total incoming flow for queue $q_{i}$ is denoted with $\lambda_{i}$ and depends on $\Lambda_{i}^{k}$, $M_{o}^{k}$, $\alpha_{i,j}$; it is given by:

where $\pi^{0}_{i}$ denotes the probability that queue $q_{i}$ is empty. Eq. (2) can be read as follows: the flow entering queue $q_{i}$ is equal to the flow of vehicles that begin their journey therein, plus a fraction $\alpha_{h,i}$ of the vehicles that exit other queues $q_{h}$, but do not leave yet the road topology.

Modeling road topologies as queue networks [11, 12, 16, 17] is a sensible methodology to estimate the travel times of different vehicles or group thereof. However, it is often cumbersome to make decisions based on queue models, owing to the large number of variables therein (the routing probabilities) and the complex way in which such probabilities influence the distribution of the travel times of vehicles of the same flow. To allow for quicker and higher-quality decisions, we now leverage the notion of path, i.e., a sequence of queues with a given source and destination, and per-flow path probabilities.

Vehicle with the same source and destination are said to belong to a flow $k\in\mathcal{K}$, with $\mathcal{K}$ identifying the set of flows. Edge servers can obtain information on the vehicles’ destination from the CAMs they send, or through application-layer communication. Indeed, it is fair to assume that vehicles benefiting from a service, e.g., navigation, agree to disclose their destination, provided that proper anonymization and privacy mechanisms [42] are in place.

Vehicles of the same flow may nonetheless follow different trajectories, hence, traverse different sequences of queues. We define such sequences of queues as paths $w\in\mathcal{W}$. Each path $w$ is an array including the queues traversed by vehicles taking it; given a queue $q_{i}\in\mathcal{Q}$, we write $q_{i}\in w$ if path $w$ includes $q_{i}$. The probability that vehicles of flow $k$ take path $w$ is denoted by $p_{w}^{k}$; each path $w$ is used by one flow $k$ only, indicated as $\kappa(w)\in\mathcal{K}$. Introducing paths allows for a flexible relationship between flows and queues, thus enhancing the realism of our model, while keeping its computational complexity low. Indeed, the set $\mathcal{W}$ and the $\kappa(w)\in\mathcal{K}$ values can be pre-computed, hence, they do not impact the complexity of the decision-making algorithm.

Importantly, given the edge-based policy, vehicles are assigned a path (according to the $p_{w}^{k}$ probabilities) at the beginning of their travel across the considered road topology, before they enter the first queue. Thus, given the path it takes, the queues traversed by a vehicle are unequivocally determined.

The probabilities $p_{w}^{k}$ that vehicles of flow $k$ take path $w$ can be expressed as a function of the probabilities $\alpha_{i,j}$ as:

where $w[n]\in\mathcal{Q}$ is the $n$-th queue included in path $w$. Clearly, the $p_{w}^{k}$ probabilities have to sum up to one:

We stress that, while each path is unequivocally associated with one flow, the opposite does not hold. With reference to Fig. 3, flow $1$ is associated with one path $[q_{1},q_{2},q_{5}]$ only, while flow $2$ can use path $[q_{2},q_{3},q_{5}]$ or $[q_{2},q_{4},q_{5}]$. As for paths and queues, there is a many-to-many relationship between them. In Fig. 3, queues $q_{1}$ and $q_{4}$ belong to one path each, queues $q_{2}$ and $q_{3}$ to two paths each, and queue $q_{5}$ to all three paths.

When considering paths, the local arrival rate at each queue $q_{i}$ in (2) depends on: the paths $q_{i}$ belongs to, the probability that flows take those paths, and the arrival rate of those flows. Specifically,

Notice how (5) expresses the same quantity as (2) earlier. However, (5) leverages our path-based representation, while (2) considers the elementary building blocks of the system, namely, queues and the routing probabilities between them.

For sake of concreteness and as a useful example, in the following we show how the above expressions particularize to the relevant cases [20, 21, 22, 23, 24, 16] where the road segments are modeled as $M/M/1$ or $M^{X}/M/1$ queues [28, 25], with $X$ denoting the (discrete) distribution of the vehicle batch size.

Let us start from the $M/M/1$ case and consider the per-path travel times presented in Sec. 5. Given the expression of the pdf of the sojourn time at an $M/M/1$ queue $q_{i}$, i.e., $f_{i}(t)=(\mu_{i}-\lambda_{i})\mathrm{e}^{-(\mu_{i}-\lambda_{i})t}u(t)$ [43], where $u(t)$ is the step function, we can write: $\mathbf{f}_{w}(s)=\prod_{q_{i}\in w}\frac{\mu_{i}-\lambda_{i}}{s+\mu_{i}-\lambda_{i}}$. Thus, the CDF is given by: $\mathbf{F}_{w}(s)=\frac{1}{s}\prod_{q_{i}\in w}\frac{\mu_{i}-\lambda_{i}}{s+\mu_{i}-\lambda_{i}}$, which is the ratio between two polynomials in $s$: a numerator of degree 0 and a denominator of degree $|w|+1$. It has one pole in $s=0$ and additional $|w|$ poles, one for each queue $q_{i}\in w$, at $s=\mu_{i}-\lambda_{i}$. It is well known that this expression can be decomposed into partial fractions [44]:

where

and $A_{0,w}=1$. Anti-transforming (9), we can write the CDF of the travel time on path $w$ as:

Therefore, combining (7), (8), and (11), and exploiting (4), $\delta^{k}(\omega^{k})$ can be written as:

In the $M^{X}/M/1$ case, vehicles arrive in batches, with size characterized by a given probability mass function (pmf). Let the pmf be $g_{n}=\mathds{P}(\text{batch size}=n)$, $1\leq n\leq G$, with $G$ being the maximum batch size. The expected batch size is $\bar{g}=\sum_{n=1}^{G}ng_{n}$. Then the Laplace transform of the path travel time is [45, Sec. 4.2.1]:

where $\rho_{i}=\frac{\lambda_{i}\bar{g}}{\mu_{i}}$ is the queue utilization and $\Gamma(s)=\sum_{n=1}^{G}g_{n}s^{n}$ is the probability generation function of the batch size pmf. It is important to highlight that (13) is a ratio of polynomials in $s$: a numerator of degree $|w|$ and a denominator of degree $1+|w|(G+1)$. Hence, using the same methodology as above, (13) can be decomposed into partial fractions and anti-transformed, yielding an expression of $\delta^{k}(\omega^{k})$ similar to (12).

As the road topology may include several lanes and road stretches, it is important to understand the complexity of our problem, as well as the viable solution approaches that can be pursued. Indeed, such a complexity has an impact on the computational resources required at the edge to provide timely policy updates.

We first look at the expression for $F_{w}(t)$ in (14), which can be fairly complex even for simple queuing systems, as exemplified in Sec. 5.1 for the $M/M/1$ case. In particular, the $A_{i,w}$ coefficients multiplying the exponential terms can have any sign. One may be tempted to conclude that nothing can be said about the convexity of the problem; instead, it is possible to prove that: (i) in the most general case, the expression is monotonic, namely, non-decreasing; (ii) in a wide set of relevant cases, it is convex.

Monotonic optimization problems [46] can be solved by mapping them into a set of convex sub-problems. Individual sub-problems are then solved to optimality in polynomial time, while the original (monotonic) problem can be solved arbitrarily closed to the optimum, at the cost of increasing the number of sub-problems.

Thm. 1 does not rely on any specific travel time distribution, but only on it being characterized by a CDF. Indeed, Thm. 1 still holds for service time distributions that do not result in a closed-form expression of the sojourn time CDF, as, e.g., in the case of $M/D/1$ queues. The wide scope of Thm. 1 reflects the generality of our framework, which does not depend on any restrictive modeling assumption on the queue service time, but works unmodified under any service time distribution.

We can prove an additional result showing that, under mild conditions, solving the problem of optimizing (14) subject to constraints (1), (4), and (5) can be reduced to a convex problem. The key mathematical concept we leverage is log-convexity. Simply put, a function is log-convex if its logarithm is convex [47]. As an example, the service time distribution of an M/M/1 queue, for $t\geq 0$, is $f_{i}(t)=(\mu_{i}-\lambda_{i})\mathrm{e}^{-(\mu_{i}-\lambda_{i})t}$ and its logarithm is $\log(\mu_{i}-\lambda_{i})+(\lambda_{i}-\mu_{i})t$, which is linear in $t$, hence, convex; it follows that $f_{i}(t)$ is log-convex. Note that log-convexity is a more restrictive condition than convexity, hence, log-convexity implies convexity.

If all queues in the system have a log-convex sojourn time pdf, then the following important result holds.

The condition of Thm. 2 is met by a very large number of relevant queuing systems, including the very popular $M/M/1$ [20, 22, 23, 24] and $M^{X}/M/1$ [19] ones.

Thm. 1 and Thm. 2 imply that our problem can be efficiently solved by commercial, off-the-shelf solvers like CPLEX or Gurobi, especially when the conditions of Thm. 2 hold and the problem is convex. However, numerical solvers encounter significant numerical difficulties when dealing with the objective (14). As demonstrated for instance in Sec. 5.1 for the $M/M/1$ case, the $A_{i,w}$ coefficients therein usually contain a ratio of products of $\mu_{i}-\lambda_{i}$ terms: a small variation in any of the terms can change the sign of the whole coefficient and/or significantly alter its (absolute) value. The issue is compounded by the fact that such values, which can be very large, are then multiplied in (8) by probabilities $p_{w}^{k}$, which could be very small and/or be varied by very small quantities. State-of-the-art interior-points methods are engineered to deal with both challenges, however, their convergence can be slowed down – or prevented altogether – by such numerical difficulties.

Gradient-based methods like the BFGS algorithm [48] may perform better, and more reliably (albeit more slowly) converge. The basic intuition behind gradient-based methods is to start from a feasible solution, and then improve it by performing, at every iteration, the change that results in the largest improvement of the objective function. However, we can achieve faster convergence through an ad hoc algorithm exploiting problem-specific knowledge.

To design an efficient solution, we look at the case of $M/M/1$ queues with the aim to derive some insights of general validity. In particular, an aspect worth investigating is the intuitive notion that equilibrium across queues and paths can lead to better performance. To show this and pick a suitable metric to define such equilibrium conditions, we make the observation below.

We can also prove the following corollary, which holds in the case of multiple paths.

In summary, we observed first that equilibrium conditions are indeed associated with better performance. Second, the best metric to use when defining equilibrium is the difference between the service and arrival rate at each queue, i.e., $\mu_{i}-\lambda_{i}$. We leverage both insights while defining our algorithm, as explained next.

Thm. 1 and Thm. 2 imply that our problem can be solved by performing one or more convex optimizations, even when its objective does not have a closed-form expression. A prominent family of algorithms that solve convex problems is represented by gradient-descent algorithms – from the venerable Newton algorithm to more modern alternatives such as BFGS [48] and stochastic gradient descent [49] (SGD), the latter widely used in machine-learning applications.

Gradient-descent algorithms work iteratively, by changing at each iteration one variable in the current solution, and effecting the change yielding the highest improvement in the objective function. If, as in our case, the problem is convex, any gradient-descent algorithm is guaranteed to converge to the optimal solution.

However, general-purpose algorithms such as BFGS or SGD are unaware of the underlying structure of the problem, and make their decisions in terms of individual variables, i.e., per-path probabilities. This may lead them to make changes that, due to their impact on other paths and flows, have to be undone at a later iteration; the final result is that the optimal is reached in a longer time than needed.

To avoid this problem, we design an iterative algorithm called bottleneck-hunting (BH). Our high-level design objectives can be summarized as follows: (i) follow the same philosophy as gradient-descent, i.e., iteratively improving a solution; (ii) make higher-level decisions, accounting for flows and paths instead of individual optimization variables; (iii) avoid making decisions that need to be undone at later stages. The resulting algorithm is described in Sec. 7.2 and analyzed in Sec. 7.3. It has the same worst-case performance and convergence properties of gradient-based alternatives but, thanks to its awareness of problem-specific information, it exhibits faster average-case performance.

As discussed above, the BH algorithm finds a solution to the problem specified in Sec. 6 faster than general-purpose, gradient-descent-based alternatives. Such a faster convergence is achieved by leveraging problem-specific knowledge and information in order to reduce the number of solutions to try out, hence, of algorithm iterations. Specifically, Thm. 3 and Corollary 1 show that, if a solution where all $M/M/1$ queues of each path have the same load is feasible, then the solution is optimal. It follows that, in those cases, it is never necessary to widen the gap between the most- and least-loaded queues of any path. We take this as a guideline to design the BH algorithm, which iteratively improves a current solution similarly to a gradient-based approach, but avoiding widening the aforementioned gap whenever possible.

With reference to Alg. 1, at every iteration, BH moves a fraction $\phi$ of flow $k^{\star}$’s traffic from path $w^{\star}$ to path $w^{\prime}$. The fraction $\phi$ changes across iterations, and is initialized (Line 1) to a value $\phi_{0}$. Then, at every iteration, BH identifies (Line 3) a set CQ of critical queues, that is, queues that: (i) belong to two paths $w_{1}$ and $w_{2}$; (ii) are not the most loaded queues in $w_{1}$; and, (iii) increasing their load by a fraction $\phi$ of the traffic $\Lambda^{\kappa(w_{2})}$ of flow $\kappa(w_{2})$ renders such queues the most loaded ones in $w_{1}$. It follows that the algorithm will try to avoid routing additional traffic on critical queues in CQ if possible. Based on CQ, a set CP of critical paths, i.e., paths containing at least one critical queue, is identified in Line 4.

Next, BH identifies the set FA of flows that can be acted upon. Flows using at least one non-critical path are tried first (Line 5); if no such flow exists (Line 6), then FA is extended to include all flows in $\mathcal{K}$ (Line 7). The flow $k^{\star}$ to act upon is chosen in Line 8: considering the min-max nature of objective (14), $k^{\star}$ is the flow for which the summation in (14) is largest. For the same reason, the path $w^{\star}$ to remove vehicles from is chosen as the most loaded one, hence, the one associated with the largest term in (14). Similarly, the path $w^{\prime}$ to add traffic to is selected (Line 10) as the least-loaded one among those used by $k^{\star}$; note that this implies choosing a non-critical path if such paths exist.

In Line 11, BH calls the function does_improve, which recomputes (14) and checks whether it improves by moving a fraction $\phi$ of flow $k^{\star}$’s vehicles from path $w^{\star}$ to path $w^{\prime}$. Indeed, the objective may not improve if the current value of $\phi$ is too high, i.e., moving a fraction of traffic $\phi$ increases the traffic intensity on $w^{\prime}$ too much. In this case, such action should be performed at a later iteration, when $\phi$ will be smaller (Line 15). If the objective improves, the $p_{w}^{k}$ variables are updated accordingly (Line 12–Line 13). The algorithm terminates when $\phi$ drops below the minimum value $\phi^{\min}$ (Line 16).

We now analyze two main aspects of BH: (i) its computational complexity, and (ii) its optimality in relevant practical cases. About the former, we prove that BH exhibits a remarkably low, namely, linear complexity.

Furthermore, if the objective function is convex (i.e., if Thm. 2 holds), then BH is guaranteed to converge to the optimal solution:

The intuition behind Proposition 3 is that BH does not waste iterations making changes that would eventually have to be reversed. Even if the worst-case complexity proven in Proposition 2 is the same as other algorithms, the actual number of iterations needed to converge is much smaller (see Sec. 9.4). The difference between BH and gradient-based algorithms is exemplified in Fig. 5, in the case of a path with three $M/M/1$ queues. Both Newton’s algorithm (left) and BH (right) converge to the same optimum solution; also, in both cases the lowest $(\mu_{i}-\lambda_{i})$ value increases from one iteration to the next. However, Newton’s algorithm could occasionally decrease the value $(\mu_{i}-\lambda_{i})$ for some of the least busy queues, and then be forced to undo those changes. BH, instead, never does so, and converges to the optimum faster.

Notice that, Proposition 3 is only guaranteed to hold under the same conditions as for Thm. 2, i.e., when the sojourn time pdfs are log-convex. However, as highlighted by our performance evaluation in Sec. 9, BH exhibits the same desirable behavior under a much wider range of conditions, including those when no closed-form expression of sojourn time distributions exists, e.g., for $M/D/1$ queues.

Finally, we remark that BH exhibits fundamental differences with respect to multi-path packet routing. First, routing protocols (including state-of-the-art QUIC implementations [50]) make their decisions based on the average latency of each route, as opposed to the full latency distribution. Second, routing protocols look at either end-to-end or next-hop latencies, while BH accounts for individual road segments and how each of them contributes to the travel times.

We begin by considering a lane-change service in the small-scale scenario described in Fig. 1 and modeled in Fig. 3. Therein, there are two incoming flows, namely, flows 1 and 2: the former is associated with one path only, the latter with two paths. These two paths are called early and late, referring to the fact that vehicles turn north (respectively) after the first road segment (i.e., $q_{2}$), or after the second one (i.e., $q_{4}$). We set the normalized incoming rate to $\Lambda^{k}=1$ for both flows (rates are normalized to the arrival rate of flow 1), and the maximum normalized service rate to $\mu^{\max}_{i}=3$ for all road segments, except for $q_{4}$ that, owing to the fact that vehicles therein need to slow down, has a maximum normalized service rate $\mu_{4}^{\max}=1.5$. Also, we set $\omega^{k}$ to 5 time units for both flows. In such a scenario, the best values of $\mu_{i}$ coincide with $\mu^{\max}_{i}$ for all road segments, thus the decisions to make are summarized by the variable $p^{2}_{\text{late}}$ (indeed, flow 1 only has one path and $p^{2}_{\text{early}}=1-p^{2}_{\text{late}}$).

The first, high-level question we seek to answer concerns the relationship between the variable $p^{2}_{\text{late}}$ and the value of the objective function (14). Fig. 7 shows that it is advantageous to split the vehicles of flow 2 more or less evenly between its two possible paths.

The third message conveyed by Fig. 7 is about the flexibility of our approach: the purple curve is obtained by modeling road segments as $M/M/1$ queues, using the closed-form expressions in Sec. 5.1, while the gray curve is obtained by using $M/D/1$ queues. Since there is no closed-form expression of the sojourn time distribution in $M/D/1$ queues, we implemented the approximate formula presented in [53], and solved numerically integrals and convolutions. In spite of the very significant differences with respect to the $M/M/1$ case, our approach and BH work with no changes in both cases: our solution strategy does not depend on any specific service time distribution, and does not require such a distribution to have a closed-form expression.

Still for the $M/D/1$ case, Fig. 8 shows the distribution of the per-path travel times, along with a graphical interpretation of the $\omega^{k}$, $\delta_{w}(\omega^{k})$, and $\delta^{k}(\omega^{k})$ quantities. Each curve corresponds to a path, and its color represents the flow each path belongs to (namely, blue: flow 1, red: flow 2). Firstly, we observe that, as the intuition would suggest, a higher value of $p^{2}_{\text{late}}$, i.e., sending more vehicles to path late of flow 2, results in longer travel times for that path, and shorter ones for path early. Secondly, the black vertical line in all plots corresponds to the value of the target travel time $\omega^{k}$; ideally, one would like all CDFs to be at the left of such a line. The intersections between the CDFs and the vertical line represent the probability that vehicles belonging to a flow take a path whose travel time does not exceed $\omega^{k}$, i.e., $(1-\delta_{w}(\omega^{k}))$. Instead, the circles noted on the plots represent the flow-wise performance $\delta^{k}(\omega^{k})$: as specified in (8), such a quantity is defined as a weighted sum of the $\delta_{w}(\omega^{k})$ values, thus, $\delta^{2}(\omega^{2})$ is close to $\delta_{\text{early}}(\omega^{2})$ when most vehicles take path early (left plot), and close to $\delta_{\text{late}}(\omega^{2})$ in the opposite case (right plot).

The lowest circle, and the numerical values reported in the plots, correspond to the largest value of $\delta^{k}(\omega^{k})$, i.e., the value of the objective function in (14): intuitively, reducing the value of the objective function in (14) corresponds to pushing up such a circle as high as possible. Note that the flow with the highest $\delta^{k}(\omega^{k})$ changes for different values of $p^{2}_{\text{late}}$: it is flow 1 in the left plot, and flow 2 in the right one. In the center plot, corresponding to the best solution as identified by both brute force and BH, all paths exhibit roughly the same travel time distribution. This is consistent with the intuition we gather from Thm. 3 and leverage on the design of the BH algorithm: similar path travel times result in better performance. Importantly, the hypothesis of Thm. 3 does not hold in this scenario – and, indeed, path travel times are not exactly the same – nonetheless, the intuition we gather from it is sill valid.

We now move to a medium-scale, lane-change scenario, with three vehicular flows, numbered from 1 to 3, traveling across a three-lane road, as depicted in Fig. 9. Traffic flows originate at the beginning of one of the three lanes and can terminate at the end of any lane, not necessarily the one they started at. Since, in our model, flows must have a unique destination, we introduce a further, fictitious queue $q_{\Omega}$, and make all flows terminate there, as depicted in Fig. 9(bottom). While all other queues are modelled as $M/M/1$, $q_{\Omega}$ is an $M/D/\infty$ queue where the sojourn time coincides with the deterministic service time and can easily be discounted from the per-path and per-flow travel times.

In this scenario, we consider the lane-change service and translate the BH policies into instructions to vehicles, following the methodology described in Sec. 8. Note that the challenge here is not due to an obstacle on the road (which is not present any longer), but to the significant difference among the incoming flows, namely, $\Lambda^{1}=10$, $\Lambda^{2}=1$, $\Lambda^{3}=5$. The maximum service rate of all queues is $\mu^{\max}=15$, while the target travel time is set to $\omega^{k}=1$ for all flows. Note that rate values are normalized to $\Lambda^{2}$, while time values are normalized to $1/\Lambda^{2}$.

Fig. 10(left) presents the CDF of the vehicle travel time for each flow when decisions are made by BH (solid lines), or by the distributed decision scheme [5] (dotted lines), or the bipartite-matching strategy. BH yields much shorter travel times; furthermore, the difference between the flows, which is evident when decisions are made in a distributed manner, almost disappears. The bipartite-matching strategy yields better performance than the distributed one – which, intuitively, is due to the fact that such a strategy uses global information. However, it is unable to match BH due to its inability to break flows across multiple paths, like BH does.

An explanation of the difference between BH and the distributed solution is presented in Fig. 10(center). Each marker in the plot corresponds to one of the $|\mathcal{W}|=35$ existing paths, and its position along the x- and y-axes is given, respectively, by the average travel time over the path and the number of vehicles using it; crosses correspond to distributed decisions, circles to BH. We can observe that, when decisions are made in a distributed fashion, the usage and path travel time change considerably, and the corresponding markers are spread throughout the plot. On the contrary, with BH, the paths have travel times that are not only shorter, but also very similar to each other – hence, the corresponding markers are clustered together, and often overlapping. This is a consequence of how BH chooses the flows and paths to act upon (Line 8 and Line 9 in Alg. 1), which in turn reflects the min-max nature of objective (14): traffic is always moved from more-crowded paths to less-crowded ones.

Fig. 10(right) summarizes how each queue is used by every flow. By comparing hatched bars (distributed decisions) to solid bars (BH), we observe how BH moves a more significant fraction of flow 1’s traffic away from the northernmost lane towards the center (and, also, southern) ones. Counterintuitively enough, the traffic of flow 3 is scarcely moved to the center lane (see $q_{2x}$), which is taken by vehicles of flow 1; rather, a significant portion of flow 2 is moved to the southern lane to make room for flow 1 in the center lane. Such behaviors are unlikely to emerge as a combination of distributed decisions; instead, our comprehensive approach and the BH algorithm are able to identify and enforce them.

Fig. 10(right) also explains why, when distributed decisions are made, the travel times of the lower-rate traffic flows (2 and 3) are quite long and similar to those of flow 1 (see Fig. 10(left)). The reason is that such flows are routed through the center lane, which is also used by vehicles of flow 1, thereby increasing the congestion and travel times of all flows. It also explains how it is possible for BH to reduce the travel times for all flows, contrary to the intuition that removing congestion from one flow unavoidably means increasing it for some other. This is connected with the well-known notion that, in queuing systems, the total traffic is conserved but the sum of sojourn times is not, since sojourn times increase much faster than linearly (hyperbolically, in $M/M/1$ queues) with queue utilization.

Here we still evaluate the BH performance under practical conditions, but we move to a large-scale scenario where a total of $|\mathcal{K}|=5$ flows travel across a road topology including $|\mathcal{Q}|=49$ road segments modelled as $M/M/1$ queues, yielding $|\mathcal{W}|=15$ paths. Both the road topology and the intensity of traffic flows are extrapolated from the real-world mobility trace in [54] (see Fig. 11), obtaining a many-to-many-to-many correspondence between flows, paths and queues.

In such a scenario, we provide a navigation service, aiming at guiding all vehicles from the origin of their trip to their destination, within their target time $\omega^{k}$. In particular, we set the following normalized $\omega^{k}$-values: $\omega^{1}=2$, $\omega^{2}=4$, $\omega^{3}=6$, $\omega^{4}=2$, $\omega^{5}=4$. The source and destination of flows, as well as their intensity (i.e., the number of vehicles belonging to each of them) come from the real-world trace [54]. Notice how flows are fairly diverse in length and parts of the city to traverse: some, like flow 1 and flow 4, only concern suburban areas of the city; others, like flow 3, need to cross the city center. Similarly, some flows (e.g., flow 1 and flow 2) are more likely than others to use the same road segments.

Fig. 12(left) summarizes the CDF of the travel times for each flow: solid lines correspond to decisions made with BH, while dashed lines correspond to distributed decisions made by vehicles based on shortest-path routing. Interestingly, decisions made by BH result in substantially shorter travel times for the busiest flows, namely, flow 3 (yellow lines), flow 5 (gray lines), and flow 2 (red lines). Flow 1 (blue lines) is virtually unchanged, while the least congested flow, flow 4 (green lines), experiences slightly longer travel times. As discussed earlier, BH reduces the travel times of congested flows, without increasing – or, as in this case, increasing to a very limited extent – the others. The matching-based solution yields trip time similar to BH (as both solutions employ global information) but slightly longer (as BH is able to accurately split flows across paths).

Fig. 12(center) provides more details on how such an improvement is achieved. The performance of flows 3 and 5 is improved mostly by avoiding the most crowded paths (rightmost yellow markers), and routing instead more vehicles on less-crowded ones (leftmost markers). This comes at the cost of increasing the load on some of the queues shared with flow 4 (green markers): the circle representing its only path is indeed further right than the corresponding cross. The markers of flow 1 overlap, which is consistent with the fact that, as shown in Fig. 12(left), the flow performance does not change.

Fig. 12(right) focuses on the busiest flow (flow 3), and the queues serving the highest number of vehicles thereof. For each queue, yellow bars represent the number of vehicles of flow 3 traversing it, and black ones the number of vehicles of all other flows. From the figure, it is possible to observe two of the main ways in which BH improves flow 3’s performance. The first is clearly exemplified by queue $q_{64}$: if a queue is heavily used by flow 3, then vehicles of other flows are directed elsewhere, thereby lowering the travel times. In other words, BH improves the travel time of the less fortunate flows (as per (14)), by preventing multiple flows from crowding the same road segments.

The second can be observed in queues $q_{10}$ and $q_{01}$: as far as possible, BH ensures that all queues have the same load. This is again consistent with the insight provided by Thm. 3, that similar loads are associated with shorter travel times.

Summary. As reported in Tab. I and Tab. II, the BH algorithm can consistently outperform its alternatives, in terms of vehicle trip times and queue occupancy. As shown in Tab. I, the average trip time drops by 66% in the lane-changing application (medium scenario), and by 20% in the navigation one (large scenario).

This highlights the validity of the BH approach, which can split flow across paths (unlike the bipartite-matching one), while at the same time accounting for global information and the potentially far-reaching consequences of local decisions (unlike the distributed approach).

Last, we focus on the convergence of BH and compare it against the iterative algorithm BFGS [48], as implemented in the scipy library. Tab. III reports the convergence speed (expressed in number of objective function evaluations) of the two algorithms. BH consistently requires fewer iterations than BFGS to converge, which confirms our intuition that leveraging problem-specific knowledge and insights results in faster convergence. It is also interesting to notice how convergence in the medium-scale scenario takes longer than in the large-scale one, owing to the higher number of paths (hence, of decisions to make) therein.