ε-Ride: An Adaptive Event Driven Windowed Matching Framework in Ridesharing

Ridesharing services aim to reduce the users’ travel cost and optimize the drivers’ routes to satisfy passengers’ expected maximum matching times in practice request dispatching. Existing works can be roughly classified into two types, i.e., online-based and batch-based methods. The former mainly focuses on responding quickly to the requests, and the latter focuses on meticulously enumerating request combinations to improve service quality. However, online-based methods perform poorly in service quality due to the neglect of the sharing relationship between requests, while batch-based methods fail on efficiency. None of these works can smoothly balance the service quality and matching time cost since the matching window is not sufficiently explored or even neglected. To cope with this problem, we propose a novel framework E-Ride, which comprehensively leverages the matching time window based on the event model. Specifically, an adaptive windowed matching algorithm is proposed to adaptively consider personalized matching time and provide a matching solution with higher service rates at lower latencies. Besides, we maintain the request groups through a mixed graph and further integrate the subsequent arrival requests to optimize the matching results, which can scale to or satisfy online use demands. The extensive experimental results demonstrate the efficiency and effectiveness of our proposed method.


I. INTRODUCTION
R IDESHARING services have made a significant contribution to modern transportation, facilitating the relief of traffic pressure and reduction of exhaust pollution [1], [2]. In urban transportation, ridesharing service provides a travel mode between the public transit and the cab service, balancing the charging cost and travel convenience. So that, it has become an essential travel option in their daily lives. In the ridesharing services, passengers are willing to accept a limited detour to share available seats with other passengers in exchange for a discount. Therefore, the existing ridesharing service providers, such as Didi [3] and Uber [4], continuously strive to improve service quality for their users by minimizing total travel cost [5]- [8] or maximizing the platform service rates [9], [10].
In reality, passengers usually hold specific requirements for the response time of a ridesharing system and are eager for a high-quality matching to save the travel cost. In general, requests willing to wait longer tend to be better matched. Therefore, a sound ridesharing system requires a trade-off between the response time and the service quality. Existing widely-applied request dispatching methods can be roughly classified into two types, i.e., online-based mode and batchbased mode.
In online-based methods [5], [6], [11], [12], the requests are assigned to the candidate vehicles with an updated route sequentially in chronological order. The online-based methods have widely adopted insertion [13] operator for the route planning. The insertion method plans a locally optimal route for the vehicle in linear time by inserting the source and destination of the request into the vehicle's route, without reordering waypoints among the original route (as shown in Figure 1). While in batch-based methods [14]- [17], the requests are usually grouped over a fixed time window and then executed once with the specific matching algorithm between the request group and candidate vehicles (i.e., bipartite graph matching, linear programming [14]). The stateof-the-art online-based methods [13], [18] are efficient in response time, which benefits from its linear time complexity. Although batch-based algorithms tend to have higher service quality by meticulously enumerating feasible request groups, it takes more time for computation. Moreover, in the batchbased algorithm, the request that arrives closer to the batch trigger time will be dispatched immediately, but such justarriving requests are willing to wait for more time to get a better matching result.
If it is feasible to plan a route that serves a set of requests simultaneously, then we call these requests are shareable. In this paper, we achieve a fine-grained implementation of request matching based on the concept of a matching window to achieve better service quality. We illustrate our motivation with the following example. Example 1. In the road network consisting of nodes a ∼ g shown in Figure 2, there are four online arrivals requests r 1 ∼ r 4 . The details of the requests are shown in Table 1. Suppose that the vehicles have enough capacity to accommodate three requests simultaneously, while it takes one unit of time to travel one unit of distance on the road network. If the request dispatching framework adopts the batch mode and the processing interval T = 3, since requests r 1 , r 2 and r 3 are shared to save 11 units of total travel distance (let cost(R) denote the shortest travel distance to serve all requests r ∈ R, then the saved travel distance is denoted as r∈R cost({r}) − cost(R)), so the dispatching framework will dispatch r 1 , r 2 and r 3 to the same vehicle.
But the request r 3 has just been released on the platform, and in fact, r 3 would like to wait for some more time to get a better match rather than leaving immediately. When r 4 is released to the platform, we can get a better assignment scheme with groups of {r 1 , r 2 } and {r 3 , r 4 }, which saves 16 units of total travel distance in sum.
Specifically, in this paper, we construct an edge for any two shareable requests based on the online arrival requests as nodes to obtain a dynamic shareability network, which helps prune infeasible request groups to improve the efficiency of request group enumeration. Furthermore, we maintain the request group for each request within a mixed graph structure named as State Graph. As the arrival and leaving of requests, the state graph is continuously adjusted and optimized until the node of request reaches the maximum time it is willing to wait, or the current matching is challenging to be improved anymore. Additionally, to balance response time and service We summarize the contributions of this paper as follows.
• We study a novel dynamic windowed ridesharing problem that takes the requests' personalized matching time into consideration. • We devise an event-driven windowed matching algorithm, EGWM, which maintains and improves the request groups within the matching windows and provides a request matching solution with higher service rates at lower latencies. • We propose an adaptive windowed matching algorithm based on the KL-UCB [19] policy, which adaptively balances the service quality and matching time through a userdefined parameter ϵ to meet different application scenarios. • We conduct extensive experiments over two real-world datasets to demonstrate that our method achieves a better service quality with shorter running time than the existing methods.

II. PROBLEM DEFINITION
In this section, we introduce and analyze the dynamic windowed ridesharing problem DWRP studied in this paper. We used a directed weighted graph to represent the road network, where each node in the graph represents an intersection, and each edge indicates the road between intersections. Besides, each edge in the graph is associated with a weight cost(u, v), which indicates the cost to travel from u to v. In this paper, cost(u, v) shows the average travel time.

A. DEFINITIONS
Definition 1 (Request). Let r i = ⟨s i , e i , n i , t i , d i , w i ⟩ denote an online request r i released at time t i , which contains n i passengers departing from s i and requires to arrive at e i VOLUME 4, 2016 the in-neighbors of node v in graph G before the deadline d i . w i is the maximum tolerable waiting time for system to match.
In practice, riders' patience is limited, so the ridesharing platform must complete each request's matching within the maximum tolerable waiting time w i . So we define the Matching Window of the rider as follows.
denote a matching window of rider r i which starts from the release time t i to the maximum waiting time t i + w i .
We denote the request r b as available for r a if and only if T a ∩ T b ̸ = ∅ (i.e., |t a − t b | ≤ min(w a , w b )). For each vehicle v j , it may be assigned with several numbers of mutually available requests R j simultaneously. Therefore we also need to plan a route S j for each vehicle v j , which consists of a sequence of pickup and drop-off locations for the requests r ∈ R j . We define the route for each vehicle as follows.
Definition 3 (Route). Given a set of m requests R, let S = ⟨o 1 , ..., o 2m ⟩ denote the route where o x is the source location s i or destination e i of request r i ∈ R.
We mark a route as feasible if and only if it satisfies the following three constraints: • Sequential constraint. The pickup location s i of request r i ∈ R i should be located before the drop-off location e i in the feasible route. • Capacity constraint. At any location o x ∈ S, the total number of riders on the vehicle should not exceed the capacity of the vehicle.
With the definitions above, we define the Dynamic Windowed Ridesharing Problem as follows.
Definition 4 (Dynamic Windowed Ridesharing Problem). Given a set R of n online requests with personalized matching window T i for each r i ∈ R, and a vehicle set W with maximum capacity constraint, the Dynamic Windowed Ridesharing Problem (DWRP) requires planning a feasible route for each vehicle w ∈ W to serve r ∈ R, which minimizes a specific utility function.
In this paper, we refer to the following unified cost U C defined in [18] as the optimization utility function.

B. BRUTE-FORCE SOLUTION
Given a group of requests R, we call they are shareable if and only if there exists a feasible route S for serving r ∈ R simultaneously. The existing batch-based methods [14]- [17] for the Dynamic Ridesharing Problem are based on a twophase framework: (1) the enumeration of shareable request groups among the request in each batch; (2) the matching between request groups and vehicles to minimize the utility function. However, since each request r i ∈ R needs to be matched within the matching window T i in the DWRP, existing batch-based methods [14]- [17] cannot be directly applied. Thus, in the Brute-Force algorithm of DWRP, we preprocess the matching window as shown in Figure 3 to fit the batch-based algorithm. That is, in each batch-based algorithm's trigger timestamp t, we prioritize and process those advent requests r x ∈ R whose matching window deadline w x expires earlier than the next batch time t+τ . The detailed algorithm of Brute-Force is shown in Algorithm 1 Firstly, we retrieve the advent requests R − , which expire before the next trigger time t + τ (line 3). Then we tried to select request groups for each vehicle w ∈ W (line 4-10). Specifically, we first enumerate request groups of size up to the vehicle capacity constraint c (line [5][6][7][8]. After that, we select the group g * ∈ G with the minimum unified cost and plan a route S j for w j to serve r ∈ g * (line 9-10). Complexity Analysis. For each vehicle w, we need to enumerate up to c i C i n request groups. Since the capacity constraint c ≪ n in practice, c i C i n can also be noted as O(n c ). Then, to identify whether the riders in each group are shareable, we need to examine up to A 2c 2c candidate routes ⟨o 1 , . . . , o 2c ⟩, and check whether each route satisfies the deadline constraint in linear time. Therefore, the time complexity of the Brute-Force algorithm is O(m × n c × (2c)! × 2c).

III. GRAPH-BASED WINDOWED MATCHING
In Section II-B, we present the Brute-Force algorithm by prioritizing the advent requests based on the existing batchbased framework. However, it has not tailored design to the features of the matching window for the DWRP problem, which may result in insufficient utilization of the personalized allowed matching time of requests. Meanwhile, it's inefficient on the enumeration of candidate request groups, which costs up to O(n c ) times. Therefore, in this section, we propose a well-tailored E-Ride framework based on the event model for the DWRP. Additionally, we also proposed the concept of the shareability graph. We pruned the infeasible groups by their shareable relationships in the shareability graph, facilitating a more efficient enumeration of candidate request groups.

A. DYNAMIC SHAREABILITY GRAPH
Shareable request group enumeration is a fundamental operator in batch-based methods. Therefore, to optimize the efficiency of the shareable request group enumeration, we first define the following shareability graph for visualizing the shareable relationships between requests intuitively.
Definition 5 (Shareability Graph). Given a set of requests R, SG = ⟨R, E⟩ denotes the shareability graph of R, where e = (r i , r j ) ∈ E reflects that request r i and r j are shareable.
Here, clique [21]- [23] is an extensively studied subgraph structure. And k-clique is a subset of k nodes in the graph that satisfies any two distinct nodes in the k-clique are adjacent in graph theory. With the shareability graph, we have the following Theorem III.1 for enumerating those request groups that form a k-clique in the sharability graph rather than an arbitrary enumeration, which helps to reduce the search space by pruning infeasible groups.
Theorem III.1. Given a feasible route S for k requests, the corresponding nodes of these k requests form a k-clique in the shareability graph.
Proof. We will prove it by a contradiction. Suppose a feasible route S of k requests whose corresponding nodes did not form a k-clique in the shareability network. Thus, at least two nodes r a and r b that are not connected. We derive the subroute S ′ from S by removing location o x except the source and destination of r a and r b . Since removing existing waypoints reduces the detour, the subroute S ′ is also a feasible route. According to the definition of the shareability graph, there must exist an edge between r a and r b , which contradicts our assumption. In summary, these k requests form a k-clique in the shareability graph.
With the Theorem III.1, we have that a shareable request group of size k in the shareability graph must constitute a k-clique. Dynamic update of the shareability graphs. While in the online scenario, we have to maintain the shareability graph dynamically as requests arrive or leave the platform.
• On the arrival of a request r a , we first have to filter out all candidate shareable requests for r a . Since the shareable requests often share similar sources to meet the constraint of deadline, we can quickly filter out the candidate shareable requests R a by maintaining a grid index. Next, we try to construct a feasible route for each candidate request r b ∈ R a by insertion [13], and we add an edge e = (r a , r b ) to the SG if such a route exists. • On the leaving of a request r a , we simply update the sharability graph SG by removing the corresponding node r a with all related edges represents the neighbors of node v in the SG.

B. AN OVERVIEW OF THE E-RIDE FRAMEWORK
We first briefly introduce the essential parts of our E-Ride framework, as illustrated in Figure 4.
• Event Handler. The E-Ride framework mainly works on the event model, which will make corresponding actions according to the type of the arriving events. The dynamic windowed ridesharing problem is an online problem where requests arrive at the platform dynamically. Both the arrival and leave of a request will affect the matching result of previously released requests in the platform, which makes it necessary for the framework to handle both cases, and we call these the arrival and leave of a request as events. As the VOLUME 4, 2016 arrival event arises, the framework will update the graph structure maintained for the requests within its matching window for optimizing the requests' groups. • Graph-Based Matching. Graphs are powerful tools for maintaining relationships between nodes. Thus we store the groups among requests that are still within the matching window in the framework via a mixed graph (i.e., State Graph in Section III-C). As new request r i arrives, we update the existing request groups stored in the graph if only if r i can provide optimization (lower unified cost) for some existing groups. • Indexing Structure. Since vehicles are always moving in the platform, the index structure adopted by the framework needs to satisfy the requirement of fast updates. A simple but effective way is to divide the full map into m × n grid cells. As the vehicle's location is updated, we can calculate the new grid based on the latitude and longitude of the vehicle in constant time to complete the update. Moreover, based on the grid index, we can achieve the approximate range query in constant time, speeding up the search of candidate vehicles in the assignment phase. The brief processing flow of E-Ride is shown in the Algorithm 2. As a new request r σ(i) arrives, we first include the node r σ(i) into the shareability graph SG. Then, we try to find out all candidate nodes R in the shareability graph SG that can share a trip with r σ(i) , and update the shareability graph by adding undirected edges between r σ(i) and r j ∈ R (line 1-5). After that, we triggered the arrival handler (Algorithm 3) to seek for the optimal request group of node r σ(i) by enumerating candidate cliques in SG with Theorem III.1 and update it to the state graph M G. And for each unit time t, we check if requests in SG exceed the matching window T r (line 7-9). If the request needs dispatch immediately, we will perform the request group dispatching by triggering the leave handler (Algorithm 4).

C. GRAPH-BASED WINDOWED MATCHING
In the dynamic windowed ridesharing problem, requests can be temporarily stored in the platform within the matching window in exchange for better request groups. Therefore,

Algorithm 2: Event-driven Windowed Matching
Input: The request arrival sequence σ with a matching window T and a vehicle set W . Output: An updated route set S for vehicles W . 1 SG ← initialize a empty shareability graph 2 foreach arrival request r σ(i) according to σ do to maintain the temporary request groups in the platform, we extend the shareability graph SG to the following state (mixed) graph by adding a directed edge set A. For the convenience of explanation, in the following, we take the notation commonly used in the graph theory: N + (r i ) denotes the set of the out-neighbors of the node r i , N − (r i ) for the inneighbors, and N (r i ) for all undirected neighbors.
Definition 6 (State Graph). Let the mixed graph M G = ⟨R, E, A⟩ denotes the state graph on the shareability graph SG = ⟨R, E⟩, where for each of the node r i ∈ R with its in-neighbors N − M G (r i ) indicates the request group stored in the state graph.
For example, with the state graph shown in Figure 5, the request node r 2 with its in-neighbors N − M G (r 2 ) = {r 3 , r 4 } indicates the reqeust group Q 1 stored in the state graph M G. The node r 1 's in-neighbors N − M G (r 1 ) = ∅ shows that request r 1 forms a self-contained group.
Because of the mutual sharing relationship between requests, we assign each node in the state graph to be seller or buyer to avoid redundant group enumeration. The node as a buyer implies that the node has selected a previously arrived node in the shareability graph to form a group. Conversely, a node as a seller means that it was "bought" (selected) by several nodes labeled with buyer to share their trips. Therefore, for any request r in the sharability graph, two types of request groups need to be analyzed: the group of r as buyer and seller. We present the "bought" relationship by the directional edges A in the state graph M G. And because of the capacity constraint c and the uniqueness of the request, the number of in-neighbors and out-neighbors of request r i in the state graph M G should satisfy the following two constraints.
Therefore, a request group consists of only one seller node and less than c buyer nodes in the state graph. We note a request group with seller node r i as And we define the group confliction as Definition 7 once the given request group pairs share a same seller node.

Definition 7 (Group Confliction). Given a pair of groups
we say that Q a and Q b are conflict if and only if r a = r b . Moreover, we denote the nodes Q a \ Q b and Q b \ Q a as conflict nodes for Q a and Q a , respectively. Example 2. Consider the state graph in the middle of Figure 5, the seller node r 2 together with the buyer nodes r i and r 4 form the request group Q * i , and the seller node r 2 also form the request group Q 1 with the buyer nodes r 3 , r 4 . Therefore, we say Q 1 and Q * i are conflict groups. And r 3 is the conflict node for group Q * i . The E-Ride framework always maintains and improves the request groups in the state graph so that the request groups within it have a better unified cost after several rounds of iterations. Since a better request group G implies that the requests r ∈ G are well shared, the induced sub-groups in the state graph also perform better in the unified cost. Therefore, we adopt the following two strategies in the group enumeration for a newly arrived request r i : 1) Add arrived request r i to an existing request group G; 2) Take some requests from the existing group to generate a new request group with the arrived request. After updating the state graph, the critical decision for the request r i is to continue waiting for a better request group or to be scheduled with the current one after events are triggered. Since we cannot predict whether a better request group will emerge or not in the online scenario, a simple but feasible solution is to make a decision randomly. That is, for each request r i , it will decide with a probability of 1/2 independently to stay and wait or to leave immediately.
With the above state graph and update strategies, we propose a novel matching algorithm, Event-driven Graphbased Windowed Matching (EGWM). Once a new request r i is released on the platform, EGWM first enumerates and searches for the optimal request group Q i of r i as a buyer and updates them to the state graph M G. While updating the requests r ∈ Q i may cause some conflict request groups to be unavailable. Therefore, we will recursively update such affected (conflict) nodes. Since subsequent arrival requests may improve the current request group Q i (r i as seller), it is not reasonable to dispatch Q i immediately compared to the online-based methods. Thus, we will "toss a coin" to decide that the request group Q i stays in the M G or dispatch. But the request r i will stay in the SG and M G for at most w i time because of the constraint of the matching window. And the request r i will trigger a timeout event requiring us to dispatch Q i after w i time elapses. The details of the arrival handler are shown in the Algorithm 3. We first enumerate the request groups for r i by iterating over its neighbors r p ∈ N (r i ). With the Theorem III.1, we only need to enumerate the k-cliques that contain r i . (line 3-10). We work differently depending on the current label of the neighbor r p . In case the neighbor r p as seller, which means that it already belongs to a request group Q p , we try to enumerate among the nodes r ∈ Q p and insert the feasible request groups to the priority queue Q sorted by the unified cost (line 4-5). Note that we only take the clique Q, which satisfied U (Q) > U (Q p ). Suppose neighbor r p is the buyer in the state graph. In that case, we try to take r p from VOLUME 4, 2016 the group Q p it currently belongs, and forms a new group Q i = {r i , r p }, because the enumeration among the requests in Q p has already been checked in the enumeration of the seller in Q p (line 6-8). The newly generated group Q i to be considered as a valid candidate request group only when the unified cost satisfied U (Q i ) + U (Q p \ Q i ) > U (Q p ) (line 7-8). And if r p is not yet labeled in M G, then this 2-clique can be directly considered an available candidate request group (line 9-10). After that, we take the clique Q * i with the minimum unified cost from the priority queue Q as the optimal request group of r i and update it to the state graph M G (line 12). If the request group Q * i enumerated by the seller r p of the original group Q p (i.e., Q * i is the conflict group with Q p ), the conflict nodes Q * i ← Q p \ Q * i need to be updated due to the unavailability of r p (line 16). Therefore, we clear the original labels from M G and rehandle the conflict nodes by Algorithm 3 recursively (line [17][18][19]. Since it is hard to determine whether a better request group will emerge shortly, we decide whether to assign the current request groups directly by tossing a coin, and we dispatch the request r i by Algorithm 4 to complete the assignment. Specifically, we retrieve the request group Q * i in the state graph M G (line 1-6) and assign it to the nearest available vehicle (line 7). Finally, we remove the nodes r ∈ Q * i and related edges associated with the assigned requests from the SG and M G.
Example 3. Let's consider the requests in Example 2. Assume that there exists a newly arrived request r i who triggers an arrival event, and the updated shareability graph is shown in left of Figure 5. We first iterate over all neighbors of r i , N (r i ), and try to enumerate the optimal request group. Since r 2 is currently a seller, we enumerate all cliques containing r i and r 2 , i.e., {r i , r 2 },{r i , r 2 , r 3 },{r i , r 2 , r 4 },{r i , r 2 , r 3 , r 4 }, and we add them to the priority queue Q with their corresponding unified cost. Then we visit the neighbor r 4 , and because the label of r 4 is buyer, we check the sum of the unified cost of the group Q 1 \ {r 4 } after the loss of r 4 from the original group Q 1 with the newly generated group {r i , r 4 }. We add the new request group to Q because U ({r i , r 4 })+U (Q 1 \{r 4 }) > U (Q 1 ). The operations on the remaining neighbors are omitted here. After that, we pick the request group Q * i = {r i , r 2 , r 4 } with the minimum unified cost from the priority queue Q and update the label of r i to buyer with its associated edges to M G. Since group Q * i is enumerated based on the neighbor r 2 labelled as seller, so the conflict node r 3 ∈ Q 1 \Q * i should be updated by Algorithm 3 for a new group. Finally, we derive the state graph as shown in right of Figure 5.

IV. ADAPTIVE DISPATCHING WITH KL-UCB POLICY
In Section III-C, the EGWM algorithm refines the processing framework for the matching window feature in the DWRP problem. However, the stochastic dispatch policy has not taken the response time metric into account, which has a significant impact on users' experiences. Therefore, the EGWM

Algorithm 4: Leaving Event Handler
Input: The leaving request r i , the state graph M G and the vehicle set W . Output: An updated set of workers and the updated state graph M G.
i and related edges from SG and M G can not balance response time and service quality for different practical scenarios. Moreover, random dispatching is not a wise choice for different requests. Thus, in this section, we propose an online learned policy method based on the Multi-Armed Bandit (MAB) model to make dispatching decisions dynamically.

A. ONLINE LEARNED DISPATCHING POLICY
The Multi-Armed Bandits (MAB) [24] problem is a classical machine learning problem, demonstrating the dilemma of exploration and exploitation. In the MAB problem, the agent selects the action without prior knowledge of the reward for t rounds and maximizes the cumulative expected reward (minimize expected regret). Through multiple rounds of interaction with the environment, the agent will gather observations of the distribution of rewards for each action. Therefore, the agent would like to select the best performing action from historical observations to obtain a relatively high reward (Exploitation) and try some actions that have not been observed enough to obtain potentially high payoffs (Exploration). Note that over-exploitation may cause agents to miss the optimal action, while over-exploration will cause agents to pay too much learning cost. How to balance exploitation and exploration is the critical issue to be considered by the solution algorithms of MAB.
To balance the exploration and exploitation, the Upper Confidence Bound (UCB) method is a typical strategy, which maintains a upper confidence bound of the reward for each action a i by the empirical mean rewardQ t (a i ) of past observations and the confidence radiusÛ t (a i ). And the confidence radiusÛ t (a i ) is a function of N t (a), which will decrease as the number of observations N t (a) of a i increases. Thus, in the UCB methods, we always greedily choose the action a * t with the maximum upper confidence bound in round t as shown in Equation 6.
In [19], divergence, which satisfies a uniformly better expected reward. The formal description of KL-U CB(a i ) for each arm a i is shown in Equation 7, which can be efficiently calculated by Newton iteration.
, where N t (a i ) and S t (a i ) denote the number of times action a i gets selected and the total reward of a i in t rounds; c is a parameter for the regret bound; d(p, q) is the Bernoulli Kullback-Leibler divergence as shown in Equation 8.

B. ADAPTIVE WINDOWED MATCHING
In the DWRP problem, the balance between response time and service quality can be regarded as whether to leave the platform early or not. The action of early leaving can reduce the request's response time while staying in the platform as long as possible may improve the request group and thus improve the service quality to reduce the cost. The KL-UCB policy can be conveniently embedded in such a process. We can consider staying and leaving as two candidate actions and design the reward function to maximize the desired objective by learning a better strategy through continuous online iterations. For KL-UCB to be able to balance the response time and the service quality, we define the following reward function r∈Q cost(r) where the left part of Reward(Q, w) evaluates the ratio of travel time saved by the request group; the right part analyzes the time saved by the earlier response with respect to the maximum allowed matching time; the parameter ϵ balances these two components so that they can be applied to scenarios with different emphases. Based on the KL-UCB Policy with the reward function above, we have the following adaptive matching algorithm S j ← planning route for serving r ∈ Q * i 8 remove r ∈ Q * i and related edges from M G 9 return S = {S j |w j ∈ W } shown in Algorithm 5. As new request r i arrives, we first enumerate the request groups for r i and update the state graph M G by following the same methods as in Algorithm 3, lines 1-21 (line 1). Then we retrieve the recommended action a * i with the largest KL-UCB from the policy instance P of the platform (line 2). Once the recommendation a * i of P is to dispatch r i immediately (line 3-8), we will select the service vehicle w * i by the reward function and feed the reward to the policy instance P (line 5-6). Finally, we plan the route S j for the selected vehicle w * j and remove the request r i with related edges from the state graph M G (line 7-8).

A. EXPERIMENTAL SETUP
Datasets. The request datasets of Chengdu (noted as CHD) and New York City (noted as NYC) were used to demonstrate the effectiveness and efficiency of our proposed methods in this paper. The road networks of both cities are downloaded from Geofabrik [25] and segmented by Osmconverter  with each edge on the road network is the average travel time of the road segment. Since there is no field about the number of riders in CHD dataset, we generate the field based on the distribution in NYC as [18]. And we set the deadline of request r i as d i = t i + γ · cost(r i ), which is a commonly used configuration in many existing works [11], [20], [30].
In the experiments for analyzing the effects of different parameters, we used data from CHD on October 31, 2016, and NYC on April 09, 2016, for a full day for testing. These datasets are available on Didi GAIA [31] and NYC Official Website [32], respectively. The detailed experiment-related parameters are shown in Table 3 (default parameters are in bold). Implementation. We simulated the ridesharing and the driver's moving based on the released time of the requests. We pre-map the sources and destinations of the requests to the nearest nodes on the road network through the VP-Tree [33]. The initial location of the worker is set to the earliest occurrence of GPS track points in the dataset. The pruning strategy based on Euclidean spaces is approximated by multiplying the average travel time by the maximum speed.
Environments. All algorithms are implemented with C++ and compiled with -O3 optimization. The algorithms run on a single server equipped with Xeon(R) Silver 4210R CPU @ 2.40GHz and 128GB RAM. Besides, all algorithms are implemented in a single thread.

B. APPROACHES AND MEASUREMENTS
We compare the following four algorithms in the experimental study.
• pruneGDP [18]. It inserts the request into the vehicle's current schedule sequentially and selects the vehicle with the least increased distance for service. • BF [15]. The Brute-Force method shown in Algorithm 1.
It is in batch mode and enumerates all request groups for each vehicle's candidate requests in random order. We performed preprocessing as shown in Section II-B to accommodate the matching window. • EGWM. The event-driven based algorithm proposed in Section III maintains the request group by graphs. It continuously iterates to optimize the request group within the matching window allowed by request. Also, it utilizes a randomized approach to decide whether a request is to be dispatched before the maximum matching window or not. • AWM. It is a variant of the EGWM algorithm proposed in Section IV, which dynamically learns to decide whether a request is dispatching before the maximum matching window based on the KL-UCB policy. Additionally, the reward function's adaptation parameter ϵ has been finetuned for better service quality by default. We report all algorithms' unified cost, service rate, and overall running time. Specifically, the unified cost adopts the evaluation of total revenue in [18], and the varying penalty coefficient p r is equivalent to the balance between income per unit time and fare per unit distance. The service rate evaluates the number of requests the platform accepts with a limited number of vehicles. The overall running time demonstrates the efficiency of the algorithms for processing the same number of requests. We early terminated those not completed experiments within 12 hours.

C. EXPERIMENTAL RESULTS
Effect of the number of vehicles. Figure 6 shows the results of varying the number of vehicles from 1K to 5K. As the number of vehicles increases, so does the service quality of the evaluated methods. The BF algorithm leads other methods for the uniform cost, which mainly benefit from its brute force enumeration strategy. The EGWM and AWM have a very close performance with the BF algorithm. However, in terms of the overall running time, because of the high time complexity of the brute force computation in the BF algorithm, it takes nearly up to three hours and six hours to run on the two test datasets, respectively. In contrast, the performance of the EGWM and AWM methods proposed in this paper is 61.03 times and 148.70 times faster compared with the BF algorithm on the CHD and NYC datasets (as shown in Figure 6(e) and 6(f)). It mainly results from the fact that the clique enumeration strategy proposed in Section III-A avoids unnecessary enumeration of request combinations, and we store the better request group through the state graph and keep optimizing them, which provides a near online performance. Benefiting from the linear time complexity of the online algorithm GDP , it is leading in terms of overall running time. However, it performs not well in service quality (service rate and unified cost) because it does not analyze request groups among requests. Furthermore, the superiority of EGWM and AWM gradually appears when the number of vehicles is large enough. As shown in Figure 6(c) and 6(d), when the number of vehicles is 5K, the service rate of EGWM and AWM achieves 4.85% and 3.2% improvement compared to the BF algorithm (about 12125 and 8000 requests, respectively).
Effect of the number of requests. Figure 7 presents the results of varying the number of requests from 10K to 250K. Because the number of accepted and rejected requests increased significantly, the unified costs of all experiment algorithms are growing. For service rate shown in Figure 7(c) and 7(d), the AWM algorithm performs the best, achieving improvements ranging from 3.57% ∼ 34.61% and 2.84% ∼ 30.66% over other methods on the two datasets CHD and NYC, respectively. For the running time, the insertion-based VOLUME 4, 2016 methods are still faster. In Figure 7(e), EGWM and AWM are 9.26× ∼ 78.3× faster than BF on CHD. And on the NYC dataset, the AWM algorithm performs even 401.52× faster than the BF algorithm as shown in Figure 7(f). Effect of deadline. Figure 8 presents the results of the varying deadline of requests by changing the deadline parameter γ from 1.2 to 2.0. The results for service rate are similar among the compared algorithms when we strictly set the deadline of requests, i.e., γ = 1.2. The reason is that the number of candidate vehicles for each request reduces significantly with a minor deadline, making it challenging to achieve noticeable performance improvements by applying request group analyzing strategies. However, the AWM algorithm achieves similar service quality using only 0.6% of the running time of the BF. The superiority of AWM is more explicit compare to the EGWM, where the AWM is 1.98× and 5.95× faster than EGWM on two datasets when γ = 1.2. With the increase of deadline, the superiority of group-based algorithms (i.e., BF, EGWM and AWM) gradually realizes. The service rate of these methods achieves more than 90% when the deadline is 1.8×. Note that BF performs inefficiently on two datasets with γ ≥ 1.8, which is primarily due to the increase of request groups with the relaxation of the deadline. Besides, BF enumerates all the combinations of requests and schedules almost for each vehicle. However, in EGWM and AWM, the request groups are stored in the state graph and improve gradually. Moreover, the request group only updated when the following arrived requests improved the utility. Thus, the time cost for the request group enumeration is significantly reduced in EGWM and AWM, benefiting from our "event-driven" execution strategy. The results of BF in CHD with γ = 2.0 and NYC with γ ≥ 1.8 are not presented because the running time exceeds the limit of our experiment settings (i.e., 12 hours). In addition, AWM performs the best in terms of unified cost and service rate as shown in Figure 8(a) to 8(d), which improves up to 31.6% and 82.97% compared with other algorithms on two datasets. Effect of vehicle's capacity constraint. Figure 9 illustrates the results of varying the vehicle's capacity from 2 to 6. In terms of unified cost, BF and AWM have similar results on the CHD dataset, but BF leads on the NYC dataset by enumerating the best request group. However, since the number of request groups increases dramatically with vehicle capacity for the BF method (e.g., when c = 6, the BF algorithm needs to enumerate C 6 n different request groups), the BF algorithm cannot finish within the given time limit when c ≥ 5. The unified cost of AWM is slightly better than that of EGWM on two datasets, which mainly benefited from the decision of the KL-UCB policy. As for service rate, AWM is still the best among all tested algorithms (except c = 2 on NYC). In terms of running time, AWM is the fastest among group-based methods (BF, EGWM and AWM), which is 8.03× ∼ 147.85× faster than BF. Discussion The linear insertion method benefits from its linear time complexity, which allows the request to be scheduled to the vehicle within a short time after arrival. However, such an approach suffers from poor performance on service rate and unified cost due to the low level of sharing between requests. On the other hand, the windowed matching model requires requests to stay on the platform for a relatively short time window, which is a trade-off between matching time and service quality. The experimental results also show that although the windowed matching model requires waiting and a longer matching time than the online-based model, such waiting is acceptable in real-life scenarios. Summary of the experimental study: • The group-based methods (i.e., BF, EGWM, AWM) have superior performance on service quality (i.e., higher service rates and lower overall costs) compared to the onlinebased methods (i.e., pruneGDP). For example, the AWM achieves a service rate improvement up to 35% compared to the other tested algorithm. • The EGWM and AWM algorithms can lead and show excellent performance in most cases. For example, AWM runs up to 401.52 times faster than BF in Figure 7(f).
In other words, AWM can process NYC requests in 3 minutes, but BF takes up to 5.8 hours • The KL-UCB strategy has a noticeable effect on improving the service quality. For instance, AWM has improved the service rate of the random policy over EGWM by up to 8.44% and 6.73% on the two datasets, respectively.

VI. RELATED WORK
The ridesharing problem can be reduced to a variant of the Dial-a-Ride (DARP) problem [34], [35], aiming to plan the vehicle routes and trip schedules for n riders who specified source and destination with practical constraints. The existing works on ridesharing services are categorized as static and dynamic, depending on whether all requests are known in advance. Most of the existing works [36], [37] on DARP are in static environment. For the dynamic ridesharing problem, the existing solutions are mainly in online mode [5], [6], [13], [18] or batch mode [14]- [16], [38].
In online mode, insertion [39] is the state-of-the-art operation of the existing works [40], [41] in route planning, which inserts the pickup and drop-off locations of a new request into the vehicle's schedule without reordering. Tong et al. [18] proposed an insertion method based on dynamic programming, which checks the constraints in constant time and dispatches requests in linear time. Huang et al. proposed the structure of kinetic tree in [6] to trace all feasible routes for each vehicle to reduce the total drive distance. The kinetic tree always provides the optimal vehicle schedule whenever the schedule changes (i.e., a new rider arrives).
Batch-based algorithms partition the requests into groups and assign groups to their appropriate vehicles. Alonso-Mora et al. [14] proposed RTV-Graph to model the relationship and constraints among requests, trips, and vehicles, where trips are the groups composed of shareable requests. The RTV-Graph minimizes the utility function by linear programming to allocate between vehicles and trips. The time cost for enumerating trips in building RTV-Graph grows exponentially.
Zeng et al. [15] proposed an index called additive tree for pruning the infeasible groups during the group enumeration and greedily chose the most profitable request group for each vehicle.
The structure of the shareability graph is intuitive, and thus some similar structures have been used in some existing works, which are designed in different ways for the vehiclerequest matching. Wang et al. [42] formulate a tree cover problem to serve urban demands with as few vehicles as possible. Alonso-Mora et al. [14] optimally assign vehicles to shareable groups of customers through linear programming. Zhang et al. [43] formulate the passenger matching as a monopartite matching problem and solve it by Irving-Tan algorithm.

VII. CONCLUSION
In this paper, we study the dynamic ridesharing problem with a personalized matching window. Concretely, we first proposed an event-driven framework, E-Ride, which maintains the request groups through a state graph extended by the shareability network. Then, we propose an efficient request group enumeration strategy based on the k-clique in the shareability graph, which helps to improve the request groups by the arrival of the subsequent requests efficiently. Furthermore, to satisfy different application scenarios, we designed the reward function for the KL-UCB policy to learn the dispatching strategy dynamically to balance the matching efficiency and service quality. In the experimental study, the extensive experiment results demonstrated that our method achieves a better service rate, less unified cost, and shorter running time than the state-of-the-art methods.