Mobility Offer Allocations in Corporate Settings

Corporate mobility is often based on a fixed assignment of vehicles to employees. Relaxing this fixation and including alternatives such as public transportation or taxis for business and private trips could increase fleet utilization and foster the use of battery electric vehicles. We introduce the mobility offer allocation problem as the core concept of a flexible booking system for corporate mobility. The problem is equivalent to interval scheduling on dedicated unrelated parallel machines. We show that the problem is NP-hard to approximate within any factor. We describe problem specific conflict graphs for representing and exploring the structure of feasible solutions. A characterization of all maximum cliques in these conflict graphs reveals symmetries which allow to formulate stronger integer linear programming models. We also present an adaptive large neighborhood search based approach which makes use of conflict graphs as well. In a computational study, the approaches are evaluated. It was found that greedy heuristics perform best if very tight run-time requirements are given, a solver for the integer linear programming model performs best on small and medium instances, and the adaptive large neighborhood search performs best on large instances.


Introduction
The transportation sector is facing major changes due to digitalization and urbanization. Novel sharing concepts that offer mobility as a service arise. While such changes can be observed in many areas, corporate mobility has not changed significantly for decades. Many companies assign cars to certain employees based on their hierarchy level. Usually, such cars can be used for business and private trips. This fixed assignment This work has been partially funded by the Climate and Energy Funds (KliEn) within the strategic research program "Leuchttürme der Elektromobilität" under grant number 853767 (SEAMLESS).
of one car to one employee can result in rather large but inefficient fleets with cars being used only less than one hour per day on average [1,2]. Furthermore, such cars are often larger than necessary since all mobility needs of the employee have to be covered with just one car. At the same time, other employees are neglected in such concepts. Often, an additional fleet of vehicles is available for business trips. These pool cars are booked using the first-come, first-served principle.
This paper proposes a novel concept for a corporate mobility service to improve this situation. The main idea is to focus on employees' mobility demands rather than on fixed assignments of cars to employees.
Similar to car rental systems [3], travelers book mobility rather than a specific car.
A mobility demand can represent business travels (e.g. travel to a customer location for a meeting from 2:00pm to 4:00pm) as well as private travels (e.g., weekend trip). A mobility offer is one possible way to satisfy a mobility demand. For the meeting example from above, one mobility offer is to reserve a pool car from 1:30pm to 4:30pm. Another mobility offer is to take the train leaving at 1:15pm and returning at 4:45pm. The final assignment of cars or other transportation modes to travelers is done via an automatic mobility offer matching system. This is modeled by the Mobility Offer Allocation Problem (MOAP). The corresponding optimization model and solution techniques are presented in this paper. The objective is to determine an integrated allocation that fulfills all mobility demands and respects the vehicle fleet size while minimizing expenses and emissions.

A Corporate Mobility Offer Concept with Flexible Bookings
The Mobility Offer Allocation Problem was put into practice as part of an applied research project in Austria 1 . This paper focuses on modeling and solving the Mobility Offer Allocation Problem. The research project adressed the corporate mobility concept in a broader way. The concept aims at improving costs and environmental impacts by shrinking the fleet size due to improved utilization, and by electrifying the fleet due to increased flexibility (e.g., small electric cars for city trips, large combustion engine cars for holiday trips).
To fully exploit those benefits, corporate mobility should be available for all employees and for business as well as for private trips. The following five main components were addressed in the implementation of this corporate mobility concept: Fleet of pool cars: The appropriate mix and size of the fleet has to be determined based on the company's specific needs. This fleet might consist of various car types: from small one-or two-seated city cars over vans to small-or medium-sized (light) trucks. Considering private trips in addition to business trips could improve company fleet utilization while reducing the need for personally owned cars. In the literature, a lot of work is dedicated to finding optimal fleet compositions [4]. Battery electric cars should be incorporated to reduce emissions [5]. Additionally, fleets could be made available not only to employees but also to the public since this demand is often complementary.
Integration of alternative mobility offers: The concept of mobility as a service should not be limited to fleet vehicles [6]. Alternative modes of transportation such as public transportation, bicycle and car sharing systems, or taxis should be considered as well. The system should automatically determine possible alternative mobility offers. A seamless integration of such offers could advance the use of low-emission transport modes.
Flexible booking and accounting system: Users should be able to state preferences in an easy-to-use booking system. Reserving specific cars should be allowed only if necessary. Suitable mobility offers are then assigned automatically. Additionally, the booking system needs to incorporate an accounting system where individual trips can be billed according to their context (e.g., business trips are accounted to the company while private trips are billed to the traveler).

Key-less access:
A key-less solution eases access to cars. This means each user of the system should have a digital device to access and drive company cars. This could be an RFID chip card or an application on a mobile phone.
Motivational strategies: Appropriate motivational strategies should be applied in order to achieve the needed mind shift. Studies have shown that users are hardly willing to waive amenities they are already used to [7]. Economic incentives and motivational strategies as proposed in behavioral economics could be applied [8]. Not only future travelers need to be convinced, but also upper management, the accounting department, or the fleet management division.

Related Work
From an application point of view, only few similar approaches have been found in the literature. A related system for sharing electrical vehicles in corporate contexts developed in an applied project is presented in Ostermann et al. [9] which underlines the relevance of the subject at hand. The method for scheduling vehicles within that system is described in Koetter et al. [10]. The proposed approach aims at minimizing fragmentation within the usage of the vehicle fleet in order to leave room for assigning novel requests.
Their solution approaches stem from control theory and operating systems, whereas our paper considers the problem from an operations research point of view. Betz et al. [11] propose an approach which integrates the scheduling of charging battery electric vehicles. They propose a time indexed mixed integer linear programming (ILP) formulation with discrete time periods of 15 minutes. In this approach, each vehicle class is solved independently. The authors report computational times of 2 hours for instances with 30 demands (called trips in their paper). A similar problem, also including charging scheduling, is tackled in Sassi and Oulamara [12]. They propose a mixed integer linear programming model and a heuristic approach. For the exact approach, the authors report computational times of one hour for instances with about 120 demands (called tours in their paper). Their ILP model avoids overlapping vehicle assignments by including one constraint for each possible vehicle assignment. We use a stronger formulation based on cliques in a conflict graph. Though not explicitly considering the charging process of vehicles (and thus being less general regarding this aspect), the problem considered in our paper is more general with regard to mobility options.
In particular, vehicle dependent journey intervals (possibly mode of transport dependent) and alternative journey intervals (e.g., modeling appointment alternatives) are considered, whereas the approaches from the literature mentioned before assume identical journey intervals for each vehicle. Also, our approach can include different vehicle admissibility for each demand.
In this paper, the problem is modeled as a generalized operational fixed interval scheduling problem.
Consider Kolen et al. [13] for a survey on interval scheduling and Kovalyov et al. [14] for fixed interval scheduling. Kovalyov et al. [14] define the fixed interval scheduling problem as follows. We are given n independent non-preemptive jobs to be processed on m independent parallel machines, where each machine can process at most one job at a time. Each job has a machine-dependent weight and a set of fixed intervals in which it can be processed at a specific machine. Now, the aim of the tactical fixed interval scheduling problem is to minimize the number of needed machines given that all jobs have to be scheduled [15]. The goal of the operational fixed interval scheduling problem is to maximize the weight of the jobs that can be scheduled on a given set of machines [16]. In our application, machines correspond to vehicles, jobs to mobility demands, and the possible assignments of a job to a machine at a specific interval to mobility offers.
Ng et al. [16] present heuristics for a special case of the operational fixed interval scheduling problem, to which we compare our developed algorithms in Section 6.
Similarly, vehicle scheduling problems (see Bunte and Kliewer [17] for an overview) are often found in the context of public transport planning. They deal with the task of assigning and sequencing vehicles to trips with fixed travel times. Some variants of vehicle scheduling account for multiple vehicle types [18] or allow slightly changing the timetable of the trips [19]. Classical vehicle scheduling problems deal with public transport, e.g., bus service planning. Another variant is the rental vehicle scheduling or vehicle-reservation assignment problem. In these problems, there are usually multiple depots where the fleet is located, there are dynamic booking requests, substitutions (e.g., to a better vehicle class) are possible, and there is the need of vehicle relocations between the depots. Oliveira et al. [3] give an overview of problems arising in the context of fleet and revenue management of car rental companies. In Ernst et al. [20], a car rental problem is modeled using a set of assignment problems with linking constraints and tackled using a Lagrangean heuristic. A real-world use case of such problems is shown in Ernst et al. [21] in which a fleet of around 4000 vehicles of a company located in Australia and New Zealand is scheduled. Another practical application was tackled in Oliveira et al. [22] which also presents an integer linear programming model and a matheuristic to solve the problem.
Interval scheduling problems are based on the concept of interval graphs, in which conflicts between intervals are represented as undirected edges. Interval graphs are a widely studied graph class in algorithmic graph theory, e.g., as a subclass of chordal graphs [23]. Since in our case each interval has a transport mode dependent cost, the problem is also close to the weighted interval graph coloring problem which is proven to be NP-hard in Escoffier et al. [24]. Another related problem is the maximum weighted independent set problem for interval graphs which is discussed, e.g., in Bar-Noy et al. [25]. In contrast to the problem considered in our work, the maximum weighted independent set problem is, however, solvable in polynomialtime because of its restriction to interval graphs. Another related problem is the interval scheduling problem with a resource constraint [26] which is, in contrast to the MOAP, not a variant of a multiple-interval scheduling problem. Many problems, like independent set, dominating set, and clique, are shown to be NP-hard for multiple-interval graphs whereas they are not for 1-interval graphs [27]. Similar models are also used in course timetabling, consider, e.g., the overview provided in Burke et al. [28]. Related are also variants of graph coloring problems [29].

Contributions and Structure of this Paper
We propose a flexible booking system which leads to the introduction of an NP-hard mobility offer allocation problem. Solution methods with varying trade-offs between run-time and solution quality are described and evaluated. This work complements the existing literature as it focuses on a real-world application of multi-interval scheduling which has found only little attention in the literature. The mobility offer allocation problem is equivalent to interval scheduling on dedicated unrelated parallel machines [16].
To emphasize the application specific focus of this paper, we use the name mobility offer allocation problem.
We will demonstrate its relatation to fixed interval scheduling problems and show that MOAP is NP-hard to approximate. Known heuristics are outperformed by the proposed methods. We define problem specific conflict graphs for representing and exploring the structure of feasible solutions. We develop a characterization of all maximum cliques in these conflict graphs, revealing symmetries which allow to formulate stronger integer linear programming models. We also present an adaptive large neighborhood search based approach which makes use of conflict graphs as well. A computational study using two sets of benchmark instances confirms that, as one would expect, the greedy heuristics perform best if very tight run-time requirements are given, a solver for the integer linear programming model performs best on small and medium instances, and the adaptive large neighborhood search performs best on large instances. The integer linear programming approach of this paper solves instances with up to 200 demands in less than one second. Instances with up to 2000 demands are solved to optimality within one hour of computational time.
The outline of this paper is as follows. Section 2 formally defines the problem and discusses the modeling. Section 3 defines conflict graphs as a foundation for the solution approaches proposed in Section 4. Then, Section 5 discusses how symmetries can be exploited by grouping vehicles into disjoint classes. A description of benchmark instances along with a computational study is presented in Section 6, followed by conclusions and an outlook in Section 7.

Problem Description and Complexity
First, this section formally specifies the problem that is investigated. Then, it discusses how that model can capture various practical requirements. Finally, the section shows that the problem is NP-hard to approximate within any factor.

Formal Problem Description
In the Mobility Offer Allocation Problem, we are given a set of mobility demands D and a fleet of vehicles V representing resources with limited availability. For each mobility demand d ∈ D, we are given a set of mobility offers O d forming the overall set of offers O =˙ d∈D O d . Note that for different mobility The problem is to select exactly one mobility offer for each demand such that the total cost of the selected offers is minimal while overall feasibility is ensured. Feasibility is achieved if for each pair of selected offers i.e., the journey intervals of all selected offers that use the same vehicle do not overlap.

Discussion
Although the problem description given above might appear simplistic, many features and aspects of practical concerns can be included due to the way mobility offers are generated. We consider this simplicity to be an important advantage of the chosen modeling. A mobility offer can comprise a complex itinerary consisting of many different locations. In a real world setting, the offers are not given beforehand, instead they are computed on demand. Known approaches for route planning (see [30] for an overview) can be employed for computing routes for the given vehicles and user needs to accurately compute journey intervals.
In particular, alternative modes of transports in addition to the given fleet of cars can be included. This can, e.g., comprise public transport operators, taxi cooperations, and bike sharing providers. We assume an infinite capacity for these modes. Related mobility offers do not require a vehicle from the given fleet (i.e., v o = * ) and thus are never in conflict to each other. Note that the journey intervals of offers not only include travel times, but also service times, waiting times, or even visits of multiple customers with additional travel times in between. Different offers belonging to the same demand may feature differing journey intervals. In particular, it is possible to include multiple offers per vehicle with different journey intervals for modeling alternative dates for the same appointment. Demands can also be used to model maintenance tasks for the vehicles of the fleet, with corresponding offers defining possible maintenance dates.
Multiple offers can require the same vehicle at the same time. This does not violate the requirement that the offer sets of different mobility demands must be disjoint. Consider for example two demands A and B which both could be satisfied by using a vehicle v. In this example, we have an offer o A whose selection would mean the car will be assigned to satisfy demand A, and a different offer o B whose selection would mean the car will be assigned to satisfy demand B. In this case, at most one of these offers can be selected in a feasible solution.
A core assumption is that each vehicle is assigned to a fixed location where all trips start and end. Yet, different vehicles can be located at different places. This assumption holds in many corporate contexts and also in related use-cases such as, e.g., car sharing systems where each vehicle is bound to one fixed location.
Beside the administrative reasons observable in practice (e.g., maintenance responsibilities), station based systems have some inherent advantages: First, there is no need to consider vehicle relocations due to the imbalance of travel demand. Second, station based systems are robust against canceled trips. Canceling a trip in advance cannot cause a problem if vehicle locations are fixed, but canceling a trip from A to B in a more flexible system could render other trips starting from B impossible. Certainly, there are scenarios where allowing relocations is reasonable. However, such scenarios are not considered in this work.
Especially in practical applications, feasibility of the problem instances cannot always be ensured. A reasonable assumption, however, is to add an offer to each demand denoting a taxi trip which has high cost but is always feasible. When taxis are not available, an artificial offer o ∈ O representing a regret cost can be added to each demand denoting that this demand cannot be fulfilled. Therefore, infeasibilities are not explicitly considered in the proposed solution algorithms.

Complexity
The mobility offer allocation problem is equivalent to the interval scheduling on dedicated unrelated parallel machines (ISDU) introduced in [16]. A mapping between instances of ISDU and instances of MOAP is given by identifying machines with vehicles, jobs with mobility demands, and intervals with mobility offers. Unavailability intervals can be represented by artificial mobility demands with a single associated offer. ISDU is shown to be NP-hard in [16] by stating that it is a generalization of interval scheduling on dedicated identical parallel machines (ISDI), which is shown to be NP-hard by [31]. Throughout this paper we use the notation introduced for the mobility offer allocation problem as this allows us to discuss in terms of the problem domain. In addition, Theorem 1 relates MOAP to another problem from the literature and shows the stronger result that MOAP is NP-hard to approximate within any factor by reducing the interval scheduling problem with machine availabilities (ISMA) to the mobility offer allocation problem (MOAP).
These results suggests that heuristics might be necessary for solving large and difficult instances. Theorem 1. If P = N P , then for any factor there is no polynomial-time approximation algorithm for the mobility offer allocation problem.
Proof. We show that the MOAP is NP-hard to approximate within any factor by a polynomial-time reduction from the Interval Scheduling with Machine Availabilities (ISMA) problem which has been shown to be NPcomplete in [13]. An instance of the ISMA problem is defined as follows: There are m machines, continuously available in [a i , b i ] with i = 1, . . . , m and n jobs requiring processing from s j to f j with j = 1, . . . , n.
The question is whether a feasible schedule exists such that each job is processed by a machine within its availability interval such that no two jobs overlap. From that we construct an instance of MOAP by creating whether there exists a feasible allocation of exactly one offer to each demand with cost smaller than 1 is also an answer to the ISMA problem. Now, assume there exists a polynomial-time algorithm for MOAP which is able to find a solution within a factor of α to the optimal solution. In case there exists a feasible schedule for the given ISMA problem the objective function value found by that approximation algorithm must be zero.
Thus, the polynomial-time approximation algorithm for MOAP would solve the ISMA problem. Unless P = N P , such an algorithm cannot exist.

Conflict Graphs
Conflict graphs are a well-known modeling technique, used, e.g., for solving coloring or scheduling problems. They are a fundamental concept for the solution approaches proposed in this paper. In particular, interval graphs in interval scheduling as discussed in Kolen et al. [13] are conflict graphs. An interval graph is an undirected graph whose nodes correspond to intervals on the real number line and whose edges identify overlaps between the intervals. Similarly, we define an offer conflict graph for identifying all possible conflicts between mobility offers. Nodes in the conflict graph correspond to mobility offers. Edges identify pairs of offers that may not be selected at the same time. Subsequently, based on the offer conflict graph, cliques in that offer conflict graph are identified and a demand conflict graph is introduced.

Offer Conflict Graphs
First, for each vehicle v ∈ V , a conflict graph identify mobility offers that use the same car and have overlapping journey intervals. Each conflict graph G v O is an interval graph. Secondly, we have for each mobility demand d ∈ D a conflict graph O is a complete graph since exactly one offer must be chosen for each demand. Then, the offer conflict graph

Cliques in Offer Conflict Graphs
In a general undirected graph G = (V, E), a subset of nodes C ⊆ V is a clique if and only if there exists an edge between each pair of nodes in C, i.e., ∀ c 1 , c 2 ∈ C : if G does not contain another clique K, such that C ⊂ K. For general graphs, the number of maximum cliques can be exponential in the number of nodes [32]. However, all maximum cliques in the offer conflict graph can be enumerated efficiently and their number is at most |D| + v∈V |O v |. This is shown in the following.
Proof. Let K ⊂ V be a maximum clique.
must exist an edge {a, b} ∈ E with a ∈ O c and b ∈ O d since K is a clique. By construction of the conflict graph, this edge can be only induced by a vehicle conflict because c and d belong to different demands. Thus, Since there is no vehicle conflict, k can be connected to both nodes, a and b, only due to a demand conflict. However, there cannot be a demand conflict to both nodes at the same time, since they correspond to different demands.
Since K is a maximum clique, there cannot be a node Theorem 2 shows that there are only two types of maximum cliques in the mobility offer conflict graph.
Next, we describe the construction of the conflict graph by enumerating the cliques identified above. The first type of cliques (offers belonging to the same demand) can be derived directly from the problem instance.
The second type of cliques (offers belonging to the same vehicle with overlapping time intervals) can be computed independently for each vehicle. As proposed in [33], this can be done by adapting the algorithm of [34] for finding a minimum coloring of an interval graph. The following algorithm describes that adaption.

Algorithm 1. This algorithm successively reports all maximum cliques in an interval graph G = (V, E).
We assume the interval graph to be given by its implicit representation, i.e., a set of intervals in the real line. The start and end dates of the intervals are denoted as left and right endpoints, respectively.

1.
Maintain an initially empty set of nodes C, representing the current maximum clique candidate.
2. Sort the 2 · |V | endpoints of the intervals of V in ascending order. In case of ties with left and right endpoints of journey intervals, right endpoints always come first.
3. Scan the list of sorted endpoints. Let e be the current endpoint.
If e is a left endpoint: Add the corresponding offer to C.
If e is a right endpoint: 1. If the previous endpoint was a left endpoint, report C as a newly found maximum clique.

2.
Remove e from the current maximum clique candidate C.
The runtime complexity of Algorithm 1 is O(|V | · log |V |), not including the output complexity of reporting newly found maximum cliques. The number of maximum cliques in an interval graph G = (V, E) is at most |V | since for each node in Algorithm 1 at most one maximum clique is reported. Since each clique can contain at most |V | nodes, the runtime complexity of the algorithm including the effort for reporting all maximum cliques is O(|V | 2 ). Now, we can make the following observation regarding the number of maximum cliques.
Corollary 1. The number of maximum cliques in a mobility offer conflict graph is at most Proof. This follows from Theorem 2 and the fact that the number of maximum cliques in an interval

Demand Conflict Graphs
We now introduce demand conflict graphs in order to identify potentially conflicting mobility demands.
These graphs are applied in Section 4.3 for defining an efficient destroy operator of a large neighborhood search based approach. The following definition of a demand conflict graph is described in terms of the quotient graph of an offer conflict graph. Beforehand, we recall the definition of a quotient graph which is a known concept from graph theory (see, e.g., [35] or [36]).
The nodes V q of the quotient graph are then given by A demand conflict graph G D = (D, E D ) is defined as the quotient graph of an offer conflict graph  that demand conflict graphs are related to multiple-interval graphs as described in [27]. The perspective of demand conflict graphs also allows to see the MOAP as a weighted variant of the known list coloring problem described in [29], with colors corresponding to vehicles.

Solution Approaches
We propose a variety of solution approaches including an ILP model using a general purpose solver, greedy algorithms, and an adaptive large neighborhood search. All are evaluated against two sets of benchmark instances in Section 6. For solving the ILP, the mixed integer linear programming solver IBM ILOG CPLEX Optimizer, version 12.6.2, is used. For larger instances, this exact approach is not successful anymore which is why we also propose heuristic solution algorithms. All proposed methods make use of the conflict graphs introduced in Section 3.

Integer Linear Programming Model
The definition of the offer conflict graph leads to an integer linear programming model which is presented next. We define binary decisions variables x o ∈ {0, 1} for each mobility offer o ∈ O denoting whether or not an offer is selected. We denote the set of maximum cliques in the conflict graph G v of a vehicle v ∈ V by The objective function (1) minimizes the sum of the costs of selected offers. Constraints (2) ensure that for each mobility demand exactly one offer is selected. Constraints (3) prevent selecting offers which require the same vehicle at the same time. Constraints (2) and (3)

Greedy Heuristic
We propose a greedy heuristic which iterates over all mobility demands and selects a feasible (i.e., nonconflicting) mobility offer with minimum cost in each iteration. The set of already selected offers during For a demand d ∈ D without any selected offer, its offers eligible for selection are given by The offer to select is arbitrarily chosen from argmin o∈L d (c o ). Hence, the order of the iteration is an important choice which strongly influences the overall objective value. Therefore, we propose the following sort criteria where a mobility demand l ∈ D is chosen before a mobility demand r ∈ D if Random : The ordering is determined by random sampling without replacement.
This leads to seven different variants of the greedy algorithm. They are used stand-alone, for initial solution generation, and as a part of the repair methods of the ALNS. In detail, the greedy offer selection algorithm works as follows. 2. Mark each offer as selectable.

Scan the list of sorted offers:
If the current offer o ∈ O is selectable: -Report the offer o as selected.
-Mark all offers o with {o, o } ∈ E as not selectable.
Algorithm 2 has a runtime complexity of O(|O| · log |O| + |E|) since the offers O are sorted and iterated once, and each edge {o, o } ∈ E is touched at most once.

Adaptive Large Neighborhood Search
We propose an adaptive large neighborhood search (ALNS) metaheuristic, whose foundation has originally been introduced by Shaw [37]. It was further developed by [38] who introduced an adaptive choice of its operators in [39].
The repair operator is chosen analogously. While the LNS accepts only improving solution candidates, for the acceptance criterion of the ALNS we use a simulated annealing based approach as suggested in [39]. A generated solution s t is accepted with probability exp(− c(s t )−c(s) where T > 0 is the temperature. The temperature starts with an initial value T start and decreases after each iteration to T := c · T by using a cooling rate c with 0 < c < 1. As described in [39], setting the start temperature is crucial for the algorithm's performance, but depends on the problem instance. Therefore, the same method as in [39] is used. The start temperature is set such that the first generated solution after the initial solution that is w percentage worse is accepted with probability p w , where w and p w are parameters of the ALNS. The weights of the selected destroy and repair operators with indices i and j are adjusted after each iteration by setting ρ − i = λρ − i + (1 − λ)σ and ρ + j = λρ + j + (1 − λ)σ. The parameter λ with 0 < λ < 1 is a decay parameter determining the impact of the previous weight value. The value σ modifies the weight depending on the performance of the destroy and repair operation pair. It is set in the following way (σ 1 , σ 2 , and σ 3 are parameters of the ALNS): i.e., the new solution candidate improves the best found solution s b .
• σ = σ 3 if s t is accepted but c(s) < c(s t ), i.e., the new solution does improve neither the best nor the current solution but is still accepted due to the acceptance criterion.
Additionally, σ = 0 if the new solution candidate has already been generated, i.e., is a duplicate. Duplicate checking is implemented by using a hash set storing all hashes of generated solution candidates. Furthermore, since the exact repair method (see Section 4.3.2) is expected to consume much more time than the greedy repair method, σ is scaled by the time needed for performing the corresponding repair operation. This reduces the bias towards strong but time-consuming operators. Corresponding destroy and repair operators are described in the following sections. Then, the selected offer of the corresponding demand of each visited node is deselected.

Repair Operators
Two different variants of repair operators are used. One is based on the ILP model introduced in Greedy Repair The greedy repair method is based on the greedy heuristic introduced in Section 4.2. By using Algorithm 2 for the repair method as in the initial solution generation, the algorithm would always end up in the same solution no matter which offers are removed. Therefore, a randomization is introduced guided by the parameter 0 < r rep < 1 which determines the size of a restricted candidate list (RCL), commonly used in the context of a Greedy Randomized Adaptive Search Procedure ( [44]).
Assume we are given an ordering (d 1 , . . . , d k ) with k ≤ |D| of the demands which have not been assigned an offer yet. Instead of choosing the demands in exactly this order, the demand to consider next is chosen from the RCL, which is composed of the next r rep |D| demands, uniformly at random.
Then, like in the greedy heuristic, the cheapest feasible offer for this demand is chosen. Each sort criterion for the demands from Section 4.2 can be used.

Vehicle Classes
Often, one would expect a corporate fleet of vehicles to include many vehicles that could be used interchangeably. This assumption allows to eliminate symmetries not exploited in the approaches presented so far in this paper. Section 5.1 provides an extended problem description which introduces vehicle classes. Section 5.2 proposes an adapted ILP model which makes use of this additional information. Since this adapted ILP model proved to be very efficient in computational experiments (see Section 6), no additional heuristic methods which exploit the information on vehicle classes were developed. In Section 5.3, this modeling is compared to the MOAP of Section 2 and it is discussed in which cases the underlying assumption of vehicle interchangeably applies in practice.

Modified Problem Description
The problem description of Section 2 is modified as follows. As an additional input, we are given a set of vehicle classes W . A given mapping ϕ : V → W assigns each vehicle v ∈ V to a vehicle class ϕ(v) ∈ W .
All vehicles of the same class must be indistinguishable, i.e., there must exist an journey interval and cost preserving bijection between the offers of two arbitrary vehicles from the same class. All mobility offers requiring a vehicle from the same class are subsumed in an abstract mobility offer o ∈Ō, assigned to the vehicle class w o ∈ W ∪ { * }, replacing the vehicle v o ∈ V assigned to each offer in the original problem definition. As before, w o = * denotes that an abstract mobility offer o ∈Ō does not require any vehicle.
The problem is to select exactly one abstract mobility offer for each demand such that the total cost of the selected offers is minimal, and to choose for each selected offer o ∈Ō with w o = * a vehicle s o ∈ ϕ −1 (w o ) while overall feasibility is ensured. Feasibility is given if for each pair o, p ∈Ō of selected offers assigned to the same vehicle s o = s p ∈ V , it holds that T o ∩ T p = ∅, i.e., the journey intervals of all selected offers that use the same vehicle do not overlap. We refer to this problem as the Mobility Offer Allocation Problem with Vehicle Classes (MOAPVC).

Integer Linear Programming Model
The ILP model introduced in the following selects abstract mobility offers. It is ensured that the number of simultaneous selections of abstract mobility offers that use the same vehicle class does not exceed the number of vehicles available in that class. From the problem definition, it follows directly that vehicles of the same class have identical conflict graphs. Thus, we obtain a conflict graph G w for each vehicle class w.
Analogously to Section 4.1, we denote the set of maximum cliques in the conflict graph G w of a vehicle class w ∈ W by C w . Decision variables x o ∈ {0, 1} determine whether an abstract mobility offer o ∈Ō is selected. The number of vehicles in a vehicle class w ∈ W is determined by ϕ −1 (w) .
The objective function (5) remains unchanged and minimizes the sum of the costs of chosen offers. As before, constraints (6) ensure that for each mobility demand exactly one offer is chosen. Constraints (7) prevent that more vehicles than available are used at the same time.
A solution of this ILP model only provides an assignment of selected offers to vehicle classes, but not to individual vehicles. From a solution of this ILP, an assignment to individual vehicles can be computed as follows. For each vehicle class, we consider the interval graph that contains the journey intervals of all selected abstract mobility offers which require that vehicle class. Assigning offers to vehicles then corresponds to finding minimum colorings of these interval graphs with colors corresponding to vehicles. The polynomialtime algorithm of [34] provides an efficient procedure for this task.
In practical scenarios and in current literature there often exists a vehicle hierarchy. This results in upgradable vehicles such that a vehicle of a higher class can be used instead of one of the requested class.
This feature is implicitly covered by this modeling approach by generating additional offers for each vehicle class higher than the requested class. Additionally, the costs of these offers for higher classes should be increased to impede their selection.

Discussion
In application scenarios where vehicle interchangeability is given, the ILP model proposed in this section can help to compute solutions more efficiently. In cases where vehicle interchangeability is not given, methods from Section 4 can be applied. Note that instances of the MOAP and the MOAPVC can be directly transformed into each other by either omitting vehicle class information or by introducing artificial vehicle classes consisting of single vehicles. Thus, both problem definitions are equally general.
In practice, the identification of vehicles to be used interchangeably depends not only on distinguishing features such as the number of seats, trunk size, cost, energy consumption, or others, but also on the possibility for users to choose mobility options based on such features. In addition to that, vehicle specific appointments for technical inspections or maintenance prevent interchangeability. An interesting use-case where vehicle interchangeability does not apply are car sharing systems where each vehicle is bound to one fixed location. There, although many vehicles might be of exactly the same type, most users would accept only vehicles located conveniently, e.g., close to their home address. This choice differs for individual users (i.e., demands), thus preventing vehicle interchangeability. If vehicle classes are not given as an explicit input but are still comprised in many problem instances, one could try to detect them automatically, e.g., following the linear time approach of [45] for deciding interval graph isomorphisms.

Experimental Evaluation
All algorithms presented in Section 4 are implemented in Java 1.8. The general purpose mixed integer linear programming solver IBM ILOG CPLEX Optimizer, version 12.6.2, is used for solving the ILP model.
All numerical experiments were conducted using one core of an Intel Xeon 2643 machine with 3.3 GHz and 16 GB RAM each running Linux CentOS 6.5.

Instances
In order to evaluate the presented solution approaches, two sets of instances are generated. The first set of instances, denoted as AG, is created randomly and the created mobility offers have no connection to real-world data. The second set of instances, denoted as RW, is based, to a certain degree, on real-world statistical data and some assumptions about travel behavior.
There are several structural differences in the two instance sets which reflects the generality of the proposed model. Instance set AG contains multiple, non-overlapping time windows for mobility demands so that multiple offers for same vehicles may have different journey intervals. This enables modeling alternative dates for one demand. Instance set RW, on the other hand, does not allow alternative dates but the journey intervals of the mobility offers are considered more realistically based on spatial, demographic, and economic data from Vienna, Austria. The start and end time of the mobility offers consider the overall difference in the demand over the time of the day and also differentiate between weekdays and weekends.
The data for both instance sets and the source code of the instance generators are made publicly available (https://github.com/ait-energy/seamless). This sections gives an overview of the rather complex instance generation procedures. We refer to Appendix A for a more detailed description of the instance set RW. In the following, determining a random number according to a discrete uniform distribution over integers [a, b] is denoted by ∼DU [a, b].

Artificially Generated Instances (AG)
First, random instances were created aiming at covering a wide range of scenarios. This instance generation procedure reflects, to some extent, the generality of the proposed modeling. Most parameters of the generator are fixed in order to limit the number of instances. Four parameters are varied which results in an overall number of 144 parameter combinations. For each combination, one instance is randomly generated.
The instances aim at representing scenarios with a mixed fleet of vehicles and mobility demands representing a variety of situations. A fixed number of demands |D| to be generated is chosen from the set is chosen. This base duration of a demand predominantly determines the duration of the journey interval of its offers. For each mobility offer to be generated (i.e., each journey interval and vehicle), a relative start date is chosen from ∼DU [2,168]. Finally, the cost of a mobility offer is determined by choosing, once for each demand, a cost per time factor ∼DU [10,30]. This is then used to determine the cost of each offer by multiplying it with the duration of its journey interval and the relative cost of the category of the used vehicle.
Supplementary to offers using the considered fleet, mobility offers representing the utilization of public transportation or taxis are included. Thus, suitable offers which do not require any vehicle are generated.   Table 1 provides an overview of all varying instance generation parameters, which yield an overall number of 144 possible combinations. Table 2 shows the number of offers and vehicles for the 16 instances generated with a vehicle acceptance probability of P a = 0.6 and a probability for long demands P l = 0.02.

Instances based on Real-World Requirements (RW)
The second set of instances is based on spatial, demographic, and economic data of Vienna, Austria.
The instance generation is based on a defined set of transport modes which are categorized into foot, public transport, bike, battery electric vehicle (BEV) and subtypes corresponding to specific car models,  Table 3 provides an overview of the average size of the instances regarding the number of offers and number of vehicles. Appendix A provides a more detailed description of this instance generation procedure.

Computational Results of the ILP Model
Extensive computational experiments using both instance sets were performed. For determining CPLEX parameters, we used the built-in parameter tuning tool on the set of training instances also used for ALNS parameter tuning (see Section 6.3) with a time limit of one hour. It turned out that the default parameters of CPLEX worked best. Tables 4 and 5 show results obtained by the exact solution approach using the ILP model from Section 4.1 for instance set AG and RW, respectively. In Table 4 results are aggregated over the instance generation parameters |D|, P u , P a , and P l and in Table 5  The large gaps indicate that the solution found for the larger instances are quite poor. For P u = 20 % and for P u = 80 %, more instances are solved to optimality or only a small gap is obtained. Instances with lower vehicle utilization rates (P u = 20 %) are easier to solve because they have less conflicts between offers.
Instances with higher vehicle utilization rates (P u = 80 %) have fewer feasible solutions which makes them easier to solve as well. The impact of the parameters P l and P a is less clear. Long mobility demands increase the number of conflicts which explains that instances with large values of P l are harder to solve. Instances with lower values for P a seem to be easier, which might result from fewer decision variables. In instance set RW, CPLEX was able to solve all instances with |P | ∈ {500, 750} to optimality within the time limit of one hour. The larger instances with |P | ≥ 1250 are harder to solve. The difficulty increases with |P | but also with ν. The large optimality gaps for these instances and the high runtimes show the necessity of a fast and efficient heuristic algorithm. For the largest instance set with |P | = 1750 and ν ≥ 0.10, CPLEX could not even find any feasible solution in 8 cases. When using vehicle classes instead, all instances can be solved within a few seconds. As described before, this model has much less variables and constraints and can therefore be solved faster. Interchangeable vehicles only exist for instances RW, therefore we only report the results for this instance class.  for the ALNS utilizing all three destroy operators each with r des = 0.15 and with the two repair operators, exact repair and greedy repair with sorting criterion MaxMinCost and r rep = 0.1. The parameter space in which irace operates is shown in Table 6.

Computational Results of the ALNS
The resulting parameter configurations are shown in Tables 7 and 8. Note that the σ-values may seem counter-intuitive at first glance because σ 1 < σ 2 < σ 3 . However, this can be explained by the following observations: First, a higher σ 2 and σ 3 value encourages diversification especially at the beginning of the algorithm because then it is more likely to accept a non-improving solution candidate. Second, for the exact repair operator the value of σ 3 is irrelevant because the generated solution candidate cannot be worse than the solution candidate before the destruction. Therefore, a higher σ 3 value encourages the use of the greedy repair method which is more likely to improve the solution at the beginning of the algorithm. In the remaining section, we refer to these values when mentioning the Random, Time Interval, Demand Conflict Graph, or ALNS configuration.
As expected, the performance of the greedy algorithms strongly depends on the sorting criterion that is used. Figure 2 compares the greedy algorithms on instance set AG normalized by relative differences to the best solution obtained by all algorithms for the corresponding instance. Additionally, we compare our proposed greedy algorithms to the greedy algorithm G1-MW proposed in [16], where G1-MW is the best performing heuristic evaluated in that paper (see Table 2 Figure 4 shows the results on instance set RW in which the numerical values are aggregated over the instances with the same value for |P | and ν by computing the mean of the relative differences to the best found objective values. These results confirm the conclusions from the results of instance set AG to some extent. In these instances, CPLEX as well is able to solve the small to medium instances and the ALNS seems to be the best choice for larger instances when comparing the average value over all instances. For the larger instances, CPLEX and also the LNS configuration Demand Conflict Graph are in some cases not able to find feasible solutions. Therefore, we conclude that for smaller instances with |P | ≤ 1000 the CPLEX model can be used if the run-time is not that important. On the other hand, for larger instances and when short run-times are required, the ALNS is recommended. Note that although the relative differences are much smaller in this instance set compared to the previous, the absolute values of the objective function are much larger due to the structure of the instances. To summarize, Table 9  To assess the convergence behavior of the ALNS, Figure 5 shows the decrease over time of the objective function value for 30 independent runs of the ALNS on one instance. Therefore, the currently best objective values of each run are collected in discrete time intervals of 10 seconds over the whole run-time of one hour. We observe a much higher variance between runs during the initial phase of the search. Even the worst runs after about 1000 seconds outperform the best runs before 200 seconds. Thus, performing multiple independent runs with the goal of obtaining a better overall result can be recommended only if the available time per run is sufficiently high. Additionally, we evaluated the time needed to find the best solution within a runtime of 1000 seconds for the instances RW. The results showed that for the smaller (E500, E750) and larger (E1500, E1750) instances the best solution was found in only about 44.81% of the runtime and for the medium (E1000, E1250) instances in about 68.08% of the runtime. This indicates that for these instances the ALNS is usually able to converge to its final value in between 7 and 11 minutes of runtime.
Finally, we analyze the properties of the results regarding their application to practical use cases. Therefore, we computed the average utilization of the shared fleet vehicles P * u and the relative number of trips  using one of these vehicles V u . For the average utilization, we computed the total reservation times of the vehicles and compared these to the whole time horizon of the specific instance. We show these values for instance set AG in Table 10 and for instance set RW in Table 11. In the latter table we additionally compare the changes of the traditional fleet size to the shared fleet size ∆V and the change in the vehicle utilization rates ∆P * u . To compute these values we assumed a classical one-to-one assignment of vehicles to employees, i.e., in the instances with |P | we assumed a fleet size of 500.
The results of instance set AG show a generally higher utilization rate than in instance set RW and increasing with higher values of |D| and |P u |. Since the instance generation procedure of the instance set AG does not distinguish between day and night trips, the demand is more evenly distributed which results in the increase of the utilization rate. Also, the utilization increases with a higher demand to vehicle ratio and clearly with an increasing input vehicle utilization ratio. Considering the results of instance set RW, we see a reduction of the fleet size between 50 and 85% while the average utilization rates are increasing in most cases. There are, however, some cases in which the vehicle utilization rates are actually lower than in the case of fixed vehicle assignments. This is because the goal of the algorithm is not to maximize the vehicle usage but to find the most cost-effective mobility offer allocations. This means that in many cases the alternative offers, e.g., public transport, are actually better for the company and are therefore chosen over a shared fleet vehicle. The same effect can also be observed when looking at the number of offers using fleet vehicles which are also rather low. If desirable, the objective function of the optimization problem could be replaced by a utility maximization function in order to increase the utilization values P * u and V u . In this work, however, we did not pursue this variant because we believe in the benefit of offering alternative mobility offers to employees.

Conclusion and Outlook
This paper introduces the Mobility Offer Allocation Problem for corporate mobility services and solution algorithms to solve it. We propose a methodology that integrates a mixed fleet of vehicles with other mobility options such as public transportation or taxis. An experimental evaluation shows the trade-offs of the proposed solution methods regarding computational times and solution quality for different kinds The conflict graph based modeling of the problem facilitates the inclusion of additional constraints. For example, a consideration of persons, potentially involved in multiple appointments, can be included via additional conflict edges. Another possible extension would be to suggest multiple employees to share a vehicle if their requests are similar, e.g., [47]. This could be modeled by introducing offers that satisfy more than one demand. A major limitation of the proposed modeling is that mobility offers refer to fixed journey intervals. In case the sequencing of offers becomes relevant, one would obtain a variant of the well-known Vehicle Routing Problem. Though journey intervals cannot, locations actually can vary in the presented modeling. Assuming a future scenario with a fleet of self-driving vehicles, each mobility demand could state a fixed start and end location specifying a request for a ride between given locations taking a fixed amount of time. Then, two offers using the same vehicle are in conflict if driving from the end location of the earlier offer to the start location of the later offer is not possible within the given time. So, an adapted conflict graph based modeling could prove useful also for such scenarios. The approach also aims at fostering the use of battery electric vehicles by helping to achieve utilization rates required for compensating high purchase prices. Recharging processes can either be included simplistically, by prolonging the journey intervals of mobility offers, or, a more detailed modeling could combine ideas from this work and that of [12], where battery loading states are modeled explicitly.
Overall, we believe the proposed modeling provides a flexibility that offers a range of interesting applications not restricted to corporate environments, e.g., a large housing unit equipped with a fleet of cars shared by the inhabitants. A larger scale application would be to implement the approach for station based car-sharing providers. Then, a company is constructed consisting of one or more depots ∆ ⊂ L, where each δ ∈ ∆ is represented by its geographic coordinate and L is the set of all possible locations. The company has a set of employees P , and a number of available instances n k of each transport class k ∈ K. Note that n k = ∞ for foot, public transport, and taxi.
Each employee p ∈ P has a gender θ p ∈ {f, m}, a hierarchy status h p ∈ {b, m, w} (boss, middle management, worker), an associated office location δ p ∈ ∆, a home location l p ∈ L, a work start time τ s ∈ N, and a work end time τ e ∈ N For all k ∈ K it is specified if employee p is willing to accept offers using transport mode k, denoted by ω pk ∈ {0, 1}, ∀k ∈ K, p ∈ P .
Then, for each employee p ∈ P on each day t ∈ T of the considered time horizon T an ordered list of events E pt = (e pt 0 , . . . , e pt n ) is generated (representing a working day of this employee) consisting of the following attributes: Furthermore, for each pair of locations l 1 , l 2 ∈ L a distance d k ij , travel time t k ij , and cost matrix c k ij is computed for each k ∈ K based on the route from l 1 to l 2 in the road network.

Value Settings.
This section describes how the independent values of the variables described above are set. Some of the variables are chosen randomly following the stated probability distribution. In these cases the actual instance is generated by drawing one sample of each of these distributions.  Generation of the Mobility Offers. Based on the data described above we extract mobility demands and offers which form the actual instance of our optimization problem. First, we generate the set of mobility demands D by considering the events E p = t∈T E pt of each employee p ∈ P . Since we assume that the company fleet is located at the depots ∆, each mobility demand d ∈ D consists of a tour starting and ending at the office location δ p of the corresponding employee p. Therefore we construct the set of demands D p = {d p 0 , . . . , d p m } with d p i = (e p j , e p j+1 , . . . , e p q ) ⊆ E p with q > j for all j = 0, . . . , n with t e p j = t e p q = w, ∀i ∈ 0, . . . , m for each employee p ∈ P .
For each p ∈ P and each d ∈ D p a set of mobility offers O d is created. There is one offer for each transport class k ∈ K which is accepted by the employee, i.e., for which ω pk = 1, denoted by Finally, the cost c o of each offer o ∈ O d , ∀d ∈ D p , p ∈ P is generated based on the cost matrix of the relevant events and the corresponding transport class k. The salary costs which depend on the duration of the offer are, however, only considered for work events, i.e., the journeys from work to the meetings and from the meetings back to work. More specifically, the cost of an offer o ∈ O d with d p = (e p j , e p j+1 , . . . , e p q ), ∀p ∈ P contains the setup costs C S and the travel costs C T is C o = C S + C T with: