We define A_t = {a₁...a_n} as a set of DAs in our system at time t. Each a_i ∈ A_t is modelled with its own properties: position pos_i, velocity v_i, width w_i, length l_i, minimum gap between the agent and the leading agent, and the orientation θ_i. All agents in A_t have the same value of maximum velocity v_max and accelerating rate α.

In this paper, we only focus on static obstructions (e.g., road construction) that occur either within the intersection or at the entrance of intersection. We assume the following about the obstacles:

Let O be an obstacle our system, and it is modelled with its own properties such as the position, the radius of the obstacle r(O), the radius of the safe ring r_safe(O), the circle around the obstacle C(O), and the circle of the safe ring C_safe(O).

Unlike the perfectly configured intersection in Dresner's work where the number of lanes and traffic directions are identical in all directions, we look at more general or non-symmetrical intersections, i.e., with unequal numbers of lanes or nonidentical traffic directions. Additionally, when obstacles are located nearby, this type of intersections has a realistic impact on the traffic, which allows us to study the disruption cause by obstacles in more detail. Moreover, this type of intersection can be seen extensively in many urban areas such as New Delhi, Bangkok, and Manhattan. We, therefore, model the intersection after a real and non-symmetrical intersection in Manhattan that intersects between Park Av South and East 23rd Street. Note that our algorithm works with different intersection settings as well.

In this work, the access of vehicles are scheduled based on the cell-based space reservation similar to Dresner and Stone (2008) where the centre of the intersection is discretised as a grid composed of a number of cells (k) (see Figure 1). These cells help DAs keep track of their used space and time-slots according to the predicted paths and also use to detect conflicts with other DAs preventing overlapping reservations (explains more in section 3). Specifically, this method supports dynamic vehicles trajectories that may happen due to the collision avoidance while several contemporary methods do not (e.g., Zohdy and Rakha, 2016; Lin et al., 2017; Vu et al., 2018).

However, whenever an obstacle is positioned at the exit of the lane, the vehicles in that lane must perform lane changing to avoid the blockage before they begin crossing. These movements interrupt the flow, resulting in increasing delays. Therefore, we introduce an extension to this cell-based approach. In particular, the grid is extended from the intersection area to cover the area around the obstacle according to the position (see Figure 2). The benefit of this extended section is to have the lane-changing movements combine with the crossing movements, allowing those movements to be reserved as one. As a result, DAs can make a reservation promptly after arriving at the queuing area, bypassing the delays that lane-changing movements may cause.

Additionally, to aid the queuing, a virtual stop bar is defined in front of the extended grid. The virtual stop bar's distance is calculated using the Gipps lane-changing model (Gipps, 1986). By limiting the lane changing speed to 25 km/h, a safe distance can be derived, ~7.5 m. DAs explicitly slow down until meeting that speed before changing the lane.

Moreover, to decentralise the system, we introduce a new piece of information for the IMA to hold called a reservation map, which is requestable by the DAs. This map contains a 2D-array of cells, and each cell also contains a vector of numbers representing its specific reserved timestamps. Simply put, this map allows the DAs to determine when and how long each cell is reserved and able to perform the conflict resolution on their own.

DAs have to execute the following operations to reserve the time-slotted space.

The main feature of decentralisation in our algorithm is that the driver agents are fully responsible for computations in two operations: path prediction (2) and conflict resolution (3). The key objective of these two operations is to find a conflict-free path from the agents' position to the target lane.

Unlike the original FCFS, the IMA does perform neither path prediction nor conflict resolution since the path (or requested path) is already included in the requesting message. However, due to concurrency issues that occur in practice, to maintain the synchronisation between agents, the IMA must be responsible for the final permission granting process. In this process, the IMA verifies the validity of the requested path against the current state of the reservation map.

Specifically, the IMA simulates all the movements of the requesting DA and the previously granted DAs with respect to the timestamps while looking for reservation conflicts. If there is no conflict, the IMA will send an approval message with reservation details back to the requesting DA and update the reservation map as usual. However, the conflict may occur when a requesting message of a_i+1 arrives after the reservation map has already been updated by accepting a request from a_i. In this case, the request will be rejected, and a_i+1 has to start the path prediction and conflict resolution from the beginning. The overall interaction flow between the IMA and DAs can be seen as a flow chart in Figure 5.

To compare the computational cost with the original FCFS, in FCFS the cost for the IMA is O[(wcell·kai)/vi]+O(k) per requesting message. This is due to the path prediction and the conflict resolution operations. While, with our approach the computational cost is reduced to O(k) per requesting message. This opens an opportunity to replicate the function of IMA across multiple nodes, i.e., the vehicles, since the computational cost is reasonably small.

Furthermore, our distributed method can reduce the overall number of messages compared to FCFS. This is because, in RIMMCA, DAs can internally resolve the reservation conflicts before sending requests to IMA. While, in FCFS, DAs notice the conflicts only when IMA notifies them via messages. Table 1 shows a comparison of an average number of messages between our method and FCFS. Indeed, it can be seen that with 1,500 vehicles our method requires more messages than FCFS. However, as the number of vehicles increases where the conflicts are likely to occur, our RIMMCA requires significantly less messages than FCFS.

Since SUMO does not support the placement of obstacles, in the following we explain how we deal with obstacles in the simulation. For an in-lane obstacle, we place an immobile vehicle at a specific position on the lane, which partially reduces the lane's available space. It sometimes even blocks the lane exit or entry depending on the position of the obstacle. However, by using the SUMO vehicle objects as obstacles, all simulated vehicles can respond to the blockage themselves (e.g., changing lane and choosing the best driving lane; Erdmann, 2015), without any manipulation from the algorithms. This means that, in the evaluation process, there is no collision avoidance extension required for both TL and FCFS.

Nevertheless, an obstacle in the intersection cannot be expressed with the immobile vehicle in the same way as in-lane obstacles. Otherwise, the car following model from Krauß et al. (1997) will force the crossing vehicles to stop in the middle of the intersection and eventually cause a deadlock (only for TL). Our solution is to represent this obstacle with a point of interest, a circle-shape object provided by SUMO despite having no physical meaning. Moreover, since no study has considered obstructions in the intersection to date, we have to evaluate our algorithm against the naive collision avoidance extension of TL and FCFS, which is a lane closing solution. Specifically, any lanes that are blocked by the obstruction will be closed throughout the run. We refer to the lane closing solution of TL and FCFS as TL-LC and FCFS-LC.

We separate the experiment into two main types: in-lane obstruction type and in-intersection obstruction type. In the first type, to create situations that significantly worsen the throughput, an obstacle is placed at the exit of the left most lane (see Figure 6A). This left most lane is more likely to have a long queue due to the left turn trajectory that heavily conflicts with other trajectories. Having only one obstacle at this position can seriously affect overall traffic throughput. In the second type, we place the obstacle in the middle of the intersection aiming to create three-lane blocking scenarios (see Figure 6B). This three-lane blocking is sufficient to show its effect on the throughput but still maintain a good flow. When more than three lanes are blocked, the throughput becomes poor and even fluctuate whenever the position is changed, and it is difficult to acquire accurate results. This is due to the non-symmetric intersection design.

Note that the purpose of this obstacle placement is to demonstrate how our method performs with baseline cases, not to exhaust the algorithm with such complex situations. For example, in the case of the bigger obstacle, this means more lanes will be blocked, which significantly worsens the performance of TL-LC and FCFS-LC approaches in terms of queue lengths and delays. While, RIMMCA does not rely on the lane-closure approach, the bigger obstacle only has a moderate effect on the results. Evaluation with this case would appear to have considerably better performance than TL and FCFS, which is considered an unfair comparison and overstating the results.

Moreover, with regards to the case of multiple obstruction types at the same time, it will introduce an entirely new problem to the system, namely, multiple obstructions. The solution to this problem would require a more complex algorithm. Even though our proposed method can be modified to avoid obstacles one by one, the resulting manoeuvring path would be only sub-optimal. An additional optimisation process would be required to address this aspect, which will be another challenge to our method. Still, this is beyond our current research scope.

Unlike Dresner and Stone (2008), where FCFS is tested in the ideal conditions, we test our model on the real intersection which is a replica of the intersection in Manhattan. Given that our focused intersection is located in New York, real traffic data is available via New York State Department of Transportation (2016). This dataset provides the average daily traffic count of each road in 2016 allowing us to estimate the value of traffic flow. Specifically, the flow is between 2,300 and 2,500 vehicles/hour, including 10% peak-time increase. Additionally, to create more practical traffic state, we weigh this flow across the two roads based on their actual usage, 67.46% on Park Av South and 32.54% on East 23rd Street. Given this, all simulated vehicles can be generated distributively and realistically per each run.

We leave all vehicles' attributes as default. These attributes include width 1.8 m, length 5 m, maximum speed 11.18 m/s (≈ 40 km/h), acceleration 2.6 m/s², deceleration 4.5 m/s², minimum gap 2.5 m, and etc. The size of the obstacles are r(O) = 2.5 m, r_safe(O) = 4.5 m. Only one obstacle will be placed per run (i.e., simulation instance).

Note that the obstacle safe distance, r_safe(O), is defined using three factors, obstacle radius r(O), vehicle's width w_i, and additional safe gap g_safe. Specifically, r_safe(O) is equal to:

Where SUMO passenger vehicle's width (w_i) = 1.8 m, and g_safe is set to be 1.1 m. Hence, r_safe(O) = 4.5 m as stated. Also, the additional safe gap can be changed dynamically depending on specific vehicle types.

We set each run to be 1 h simulation time with randomly generated input flow and vehicles trips (from the estimated traffic flow and the usage weight). For the evaluation, three traffic measurement units: flow rate (vehicles/hour or veh/h), queue length (metre) and delays (seconds/veh or s/veh) were chosen. Moreover, to gain more accurate results, each experiment was also repeated more than 20 runs. The values reported below are the average over 20 runs.