MuTraff: A Smart-City Multi-Map Trafﬁc Routing Framework

: Urban trafﬁc routing is deemed to be a signiﬁcant challenge in intelligent transportation systems. Existing implementations suffer from several intrinsic issues such as scalability in centralized systems, unnecessary complexity of mechanisms and communication in distributed systems, and lack of privacy. These imply force intensive computational tasks in the trafﬁc control center, continuous communication in real-time with involved stakeholders which require drivers to reveal their location, origin, and destination of their trips. In this paper we present an innovative urban trafﬁc routing framework and reference architecture (multimap trafﬁc control architecture, MuTraff), which is based on the strategical generation and distribution of a set of trafﬁc network maps (trafﬁc weighted multimaps, TWM) to vehicle categories or ﬂeets. Each map in a TWM map set has the same topology but a different distribution of link weights, which are computed by considering policies and constraints that may apply to different vehicle groups. MuTraff delivers a trafﬁc management system (TMS), where a trafﬁc control center generates and distributes maps, while routing computation is performed at the vehicles. We show how this balance between generation, distribution, and routing computation improves scalability, eases communication complexities, and solves former privacy issues. Our study presents case studies in a real city environment for (a) global congestion management using random maps; (b) congestion control on road incidents; and c) emergency ﬂeets routing. We show that MuTraff is a promising foundation framework that is easy to deploy, and is compatible with other existing TMS frameworks.


Introduction
Efficient urban traffic routing is a key challenge in the development of modern intelligent transportation systems (ITS) for smart cities. Urban traffic routing is not only an issue of optimization of individual agent needs but also a problem of citizen wellness and an ecosystem of services with conflicting interests and regulation: individual mobility, multi-modal mobility, safety, noise footprints, pollution and gas emissions, restricted areas that are geo-fenced, time-bounded commercial distribution, city space for public event usage, special fleets management, public transportation, and others [1,2]. All these factors can provide a wide range of data sources and configure the urban computing environment, which ITS must handle to create effective solutions for urban mobility and transportation [3,4]. Urban computing is part of the smart city concept, conceived as the application of information and communication technologies (ICT) to enhance the quality and performance of the services provided to an urban area and its citizens [5,6]. other approaches because it proposes differentiated maps per fleet, complementary to other routing algorithms and traffic agents.
In MuTraff, dynamic maps may be updated in real time depending on traffic conditions. Static maps are pre-configured maps that are applied for a period of time. The main advantage of static maps is that they are simple and stable if the traffic conditions are known in advance, and there is no significant deviation during their application.
MuTraff offers a good balance between computational load, communications, and optimal results retrieval, levering the search for best-routes at the network level, and also enabling for vehicles that can do their own route computation. TWM is compatible with distributed traffic routing approaches by sharing the generated maps for their usage. In the same way, MuTraff can also be easily adapted to a distributed approach where multiple instances of MuTraff may be allocated at road-side units providing local TWM weight maps for routing.
MuTraff framework has a modular design that enables integration with other traffic frameworks. It provides the MuTraff simulator (MTS) component, which has been used in our experiments and it enables microscopic traffic simulation based on Simulation for Urban Mobility (SUMO) simulator [18].
The main contributions of this paper include: (1) Discussion of traffic weighted multimaps (TWM) as an efficient method for stochastic static and dynamic traffic routing; and (2) description of a reference open architecture proposal (MuTraff) for TWM generation and distribution. Both allow for a system that is simple, scalable, secure, and compatible with other existing systems and easily deployable. It also needs less computational and communication requirements than other current solutions.
The paper also shows: (a) How TWM usage helps to reduce traffic congestion in urban networks, even with basic random policies; (b) how TWM implementation improves some smart city transportation-related indicators such as air-pollution, noise-emissions, and energy usage; (c) the positive impact of TWM on individual mobility experience; (d) the effectiveness of TWM when applied to urban incidents as a technique to reroute traffic; and (e) how TWM is used to cover specific fleet requirements.
The paper is structured as follows: There is an initial review of the state-of-art and related works, followed by the introduction of the traffic weighted multimap proposal. Next, we introduce the architectural framework MuTraff that supports TWM, which is the main contribution of the paper. Three case studies are presented using a real traffic network (Alcala de Henares, Spain): (a) traffic congestion control through random TWM maps; (b) congestion management on traffic incidents, and (c) emergency fleets routing. We then expose the simulation results and analyze the impacts of TWM over main urban traffic management concerns: global mobility and congestion, pollution and emissions, noise footprint, and individual driving experience. Finally, we draw conclusions and future research lines on TWM.

Related Works
We first presented the traffic weighted multimaps method in [19] as an introductory proof of concept for congestion mitigation, and tested it on synthetic networks based on grid networks. It is based on a centralized TMS MuTraff (cloud) by receiving and processing traffic information, which is later distributed to the vehicles in traffic weighted multimaps.
There are many centralized TMS proposals that provide viable traffic routing management solutions, as we can see in [20][21][22][23]. Some of these TMS, like SCORPION, UCONDES and others, acquire and periodically process information about the network and the individuals, detect traffic conditions, and generate routes that are distributed to the vehicles. Traffic information is obtained via beacons that are emitted periodically by the vehicles. The TMS then processes the data received using an algorithm such as a neural network, evolutionary algorithm [24,25], anticipatory and negotiation [26], or others. Relevant traffic information is sent to the vehicles in the network, which must decide whether to follow their current route or compute an alternative route. These centralized TMS procedures can choke the network when there is a high density of vehicles, and additional improvements need to be made to reduce the volume of necessary communications.
Many distributed TMS designs have also been proposed to solve the limitations of the centralized TMS [27][28][29] such as DIVERT. The observations and interactions at various vehicle traffic agents provides the core knowledge about traffic conditions and interactions. Distributed cooperative TMS do not require a specific infrastructure for congestion detection as they rely on vehicle interactions to compute routes [16,30,31]. However, in the case of having an inefficient information exchange between vehicles, distributed TMS may suffer from similar issues as the centralized methods. Souza [16,28] proposed opportunistic content sharing by sending local information to certain areas, limiting the amount of communications required in the same way that individual notifications need to be controlled in centralized approaches. It assumes that critical sections are known in advance to limit those communications, being implicit the existence of a centralized TMS. V2I based mechanisms were also proposed in [15] but they have similar constraints as distributed TMS.
An effective implementation of distributed routing requires that all the vehicles in the network have corresponding routing agents installed and running. Vehicle software agents should be available regardless of the vehicle fleet or class (cars, taxis, buses, trucks, vans, etc), and also should be vendor-neutral to assure cross-compatibility. Global adoption of distributed agent-based methods need an industry-wide consensus and would need the adoption of standards across the board, unless they are are capable of demonstrating their effectiveness under low-adoption scenarios. Another important drawback on distributed TMS is that they rely heavily on communications and permanent connectivity, which in turn depends on many factors: real vehicle communications capabilities, radio network properties including weather effects (such as fading), service providers, connectivity offerings, and subscription plans.
The hyperpath routing approach addresses uncertainty and variability of traffic dynamics, where individual traffic agents receive for each origin and destination a tree of alternatives, as opposed to a single route [10,11,13,32]. It feeds off historical data to discern traffic behavior patterns [12,33,34], thus requiring heavy back-end computing to synthesize the pre-trips. TWM is complementary to hyperpaths as it provides different network views for hyperpath calculation.
Urban traffic management using TMS with big-data approaches has been the subject of intensive research already, leading to proposals that differ in the way they implement traffic control and recommendations [35,36]. They are a core part of the smart city infrastructure approach that focuses on global parameters and specific fleet needs [37][38][39][40][41]. Big-data back-ends require real data-sets that are achieved using network sensors and crowdsensing approaches, where both the vehicle agent and the driver agent anonymously collect data from traffic and network status [42][43][44][45][46].
User-equilibrium in traffic flows is described by [47] and has been addressed by traffic routing approaches based on route aggregations as described by [48]. Aggregation also includes traffic routing based on static or dynamic flow exchange between areas (traffic assignment zones, TAZ) [49,50].
TWM is multi-purpose and combines individual, group, and global policies, in contrast to other centralized proposals that are conceived for individual risk-averse policies (minimizing travel-time variance). TWM is a stochastic routing technique,and thus optimal theoretical solutions are not achieved in comparison with other centralized solutions. Instead, TWM is a feasible, compatible, and easily deployable solution.

Traffic Weighted Multimaps
This section provides the TWM model formulation and explains map generation strategies. Table 1 summarizes the model formulation.

TWM Model Formulation
The topological traffic representation of the urban network Θ, is described by a graph of nodes η n connected by unidirectional edges, being each edge i,j a set of links (lanes) that connects nodes η i and η j with a weight β i,j as expressed by Equation (1). Edge travel-time is commonly used to estimate weight β i,j to compute shortest-path calculations.
The traffic network is commonly used by k groups of vehicles [Ω k ] that differ in their mobility features, objectives, and interests. Vehicles are represented by their agents υ k a , where a denotes individuals belonging to the traffic demands of [Ω k ] . The default fleet for non-grouped vehicles is Ω 0 . Agents υ k a move in the traffic network generating a set of trips W k a , which are individually defined by the vehicle identification υ k a , the starting timestamp t 0 a , the starting node O a , the destination node D a , and the set of intermediate planned stops [P k a ] : We define a multi map TWM, denoted by [µ k,m ], as the collection of m weighted views (maps) of the traffic network Θ, which can be used by the k traffic groups that use it.
Each map µ k,m is as a edge weighted β k,m i,j representation of the traffic network Θ (view k, m), which is calculated as the result of applying a function Π over (a) the network topology; (b) traffic groups or fleets [Ω k ]; (c) time-constraints [Γ k,m ] for usage; and (d) network traffic data Φ.
Time constraints [Γ k,m ] consider both periodic scheduled constraints (e.g., based on traffic restrictions, and school paths) and event-based time constraints (e.g., road works, public events, and road incidents).

TWM Generation Policies for Traffic Planning
TWM generation policies are based on two main factors: (a) weight generation functions Π , and (b) map cardinality m. The latter enables that every fleet may use several maps at the same time. We use this parameter to provide route dispersion required for global congestion management. Map cardinality m is a design parameter. It may be part of TWM optimization algorithms planned for future works.
Different strategies may be applied for Π: linear scaling, random distributions, predictions over historical data, optimization functions, genetic algorithms, and others. In this paper we cover basic linear and random functions, leaving the rest for future works. The basic linear scaling function Π std (standard function), generates TWM weights based on scaling edge minimum travel-time tt i,j by a constant factor k 1 . Weight scaling with Π std may be used to encourage (k 1 > 1) or discourage (k 1 < 1) usage of edges: In the incident management scenario we need to over-weight part of the network around the incident to discourage vehicles from using that surrounding area. Adjacent edges may have very different original weights and the scaling factor k 1 is not enough to exclude some edges from the shortest-paths. This is best achieved using an additive factor k 2 as expressed by the linear function Π lin Equation (5). Π lin is useful for dynamic traffic routing applying local penalties or incentives: In the global congestion management scenario, we need for similar trips to select slightly different shortest-path routes. Similar trips are those used by vehicles of the same fleet moving from the same origin TAZ to the same destination TAZ. This is accomplished distributing randomized maps to the vehicles of the same fleet. We use the Π δ random function that modifies the Π std function with a random modifier δ: Routing decisions using TWM with Π δ are going to disperse traffic in the network as shortest-paths will vary their composition. The aim of TWM is to stochastically route groups of vehicles through specific network links in a one-shot fashion by generating maps with different link weights. Initial reference weights that generate different maps are defined in terms of delay for free-flow. Of course, other strategies for generating link weights offline could be based on using volume delay functions and dynamic traffic assignment for traffic prediction.
We use Π δ random in our experiments with normal and uniform distributions using δ as δ normal = normal(a, b) (a stands for the mean value and b stands for the statistical dispersion amplitude) and δ uni f orm = uni f orm(a, b) (ranging from a to b).

TWM for Urban Traffic Routing
Not all the agents will use TWM so we define the adherence factor ψ in Equation (7) as the percentage of agents υ k a TW M that are using it. We use ψ to compare different TWM adoption scenarios.
Agents belonging to Ω 0 fleet (non-classified vehicles) and agents not adhering to TWM use the map µ 0 with β 0 i,j = tt i,j that corresponds to the original physical map. Independently of client or server routing modes, the routing agent υ k a calculates the best route R k,m a in Equation (8) or hyperpath for the trip W k a , using the physical map µ 0 or the TWM µ k,m . Best-route calculation algorithms # can be used for this, such as Dijkstra, A* or others: Total travel-time TT k a of a mobile agent υ k a is composed of congested STT k a and non-congested MTT k a travel-times, as the sum of the partial travel-times at each edge, Equation (9). ∑ STT k a provides a good measure of global congestion in the traffic network.
Effective trip length RL k a run by an agent is the sum of lengths of every edge: For traffic routing performance analysis, we consider at every timestamp t those trips that have been already completed W k a t end , those that have been started W k a t run and not completed W k a t pend , and those that have not been started yet (Equation (11)):

MuTraff Architecture
Multimap traffic management requires a specific architecture approach for a feasible physical deployment. In this paper we propose a full-stack reference architecture called MuTraff (Multimap Traffic Control Architecture) that may be used as stand-alone system or combined with already existing traffic architectures.
From the perspective of a vehicle's agent, MuTraff may be considered as a TWM-based routing service provider that offers custom traffic network maps services, and also efficient origin-destination routing services. From the perspective of the traffic service operator, MuTraff can be considered as a low-impact traffic analysis and optimization tool and a traffic big-data processor.
One of the main objectives of MuTraff is to provide a set of components that integrate seamlessly with current systems by means of standard interfaces, being also compatible with standard traffic agents software. Some of the reference blocks may be provided by existing traffic management frameworks, devices and tools, but some others are new elements added to cover the TWM algorithms and functionality.
Part of the building blocks are already available and others are under construction or in the backlog. Experiment results shown in the paper have been obtained with these blocks. MuTraff main blocks (modules) are shown in Figure 1: • MuTraff big-data core (MDB). It collects data from the different sources available: historical traffic data, traffic planning data, and real-time dynamics monitoring. Historical sources considered are: -Traffic demands (from road sensing), both aggregated and per fleet when available.

-
Edge measures for traffic density, speed and congestion, pollution measures, and noise emissions. These measures are collected from many different sources such as road sensors, vehicle sensors, crowdsensing, and others.

-
Individual historical traffic demands that have been collected from the vehicle mobile agents through crowdsensing mechanisms regarding origin/destination trips and frequencies, and also from back-office routing services. Agents also report information about speeds.

-
Driver experience historical information about map demands, satisfaction, engagement, and others.
Planning data reflects traffic behaviors detected under certain past situations that enable model and pattern detection. Dynamic data are collected in a continuous way from the sensors and from the vehicle agents.
The MuTraff Big-Data component will generate data predictions over each network path indicating traffic density, congestion, speeds, pollution, emissions, and user-experience. It mainly calculates in several time-epochs the weight distribution functions Π for the different traffic networks [Θ i ]. This Big-Data module uses a data-lake approach ( [51][52][53]) to collect data, and may use a machine-learning subsystem to detect traffic patterns and infer the corresponding weights for Π.

•
MuTraff central control station (MCCS). The purpose of this component is to generate traffic weighted maps [µ k,m ] according to the data collected from the big-data module and from the real-time sensor data. Its main module is the MuTraff map manager (MTMapManager) for TWM generation, management and distribution.
The MCCS provides two main families of services for traffic agents, provided as web services: -Map services, for TWM generation and distribution under several policies (broadcast, publish-subscribe, and on-demand). These services are designed to be used at agent-side route calculation.

-
Route services, for querying origin/destination routes or hyperpaths based on server-side TWM maps. These services are used when the agent asks for a route from origin to destination.
MCCS is not intended to be provided as a full featured control station, but to serve as a plugin for other control stations. The MCCS includes all the necessary algorithms for weighted maps generation and also the route generation procedures for individual origin-destination trips. The MCCS is conceived to be offered as a cloud service, with a web portal and a REST-API offering.
If we recall Equation (3): , TWM depends on the traffic area (city), group of fleets, time-constraints, and traffic events. There is no need to recalculate the TWM for every agent call, but just when any of these parameters change. MCCS caches the [µ k.m ] map to provide fast responses to the agents.

•
MuTraff data distribution middleware (DMW). This component enables distributed communications between all the components, and mainly between traffic agents and the MCCS, decoupling core engines from the consuming agents, creating an loosely-coupled and scalable architecture. It is a distributed cloud for server-side middleware that exposes and manages services as APIs using different policies (REST, Pub-sub, and others). Sensors and actuators use both web-services and publish-subscribe real-time queue oriented communications. Agents, sensors and actuators are not part of the middleware using just secured services in the framework.

•
Sensor and actuator network (SAN). These sensor and actuator networks include the common standard traffic measurement and signaling systems. We consider two kinds of sensors: physical sensors and crowdsensing devices to acquire real-time data about the network, traffic status, and driver's behavior. They provide the necessary information to create dynamic traffic assignment, and also provide information about driver's adherence to TWM recommendations.

•
Mobile traffic agents (MTA). Traffic agents are standard navigation software agents. From the route calculation mode perspective, there are three main types of mobile traffic agents: (a) online agents, that require a permanent active data-connection to ask for the best route sets during their trips, (b) autonomous agents that just download the traffic maps and the status information, that execute their own client-side route calculation, and (c) hybrid agents using a download basis that is periodically updated by online real-time data. The MCCS provides TWM services for all of them.

•
MuTraff traffic simulator (MTS), that enables traffic simulation and route evaluations based on TWM maps before they are deployed to real traffic. Generated TWM maps may also be used with almost any of the standard simulation platforms as they act over standard common variables, such as traffic demands per fleet and network maps. Network maps are a key data entry for any existing traffic simulator, so TWM approach is valid for microscopic, mesoscopic, and macroscopic simulators as they all use the network as a basis.
Current simulations presented in this paper have been run on MTS over the well known SUMO traffic microscopic car-following simulator [18]. MTS manages traffic simulation based on vehicle traffic demands, physical road maps, and colored-weighted maps produced from the MCCS. The simulator can be run with the graphical interface typically available for SUMO where individual vehicles are shown over time, but also as a multi-threaded distributed process that scales horizontally. MTS also generates the traffic indicators mentioned in the model formulation Section 3.1.

•
MuTraff traffic and maps toolbox (MTools). New auxiliary tools are being constantly added to the platform to provide additional capabilities to manage and administer data and for simulation purposes. Some of them are:  In Figure 2 we zoom into the building blocks of the server-side components: MCCS, MDB, MTS, and DWM. Also SAN is included for completion purposes.

The MCCS Control Station
The MCCS is a server-side service used to generate Traffic Weighted Maps (TWM [µ k,m ]) according to the data collected from the big-data module and from the real-time sensor data. It is formed by the following architectural modules: • The MuTraff map manager (MTMapManager) in charge of TWM generation, management and distribution based on statistical information. It is responsible for evaluating the Π x functions for each network Θ, and generating [µ k,m ] for every time epoch.

•
The MuTraff route manager is the module responsible for providing the query-based route or multi-path selection for agents (server-side) for those schemes where the agent sends a query for its trip W k a and receives the corresponding R k,m a route or hyperpath R k,m a .

•
The MuTraff BDI (Belief-Desire-Intentions) processor, which is in charge of processing dynamic route demands to predict future traffic trends. This module is part of future work. • The MuTraff AlertManager, responsible for publishing traffic alerts that will reinforce TWM adoption. These alerts are to be exposed both in the signaling panels and also in the mobile agents, promoting route re-evaluation with new TWM sets.

•
The MuTraff device network management, responsible for sensors and actuators management, receiving from and sending data to them.
In its simplest form of operation, generation of maps in MuTraff is made in open loop, without feedback from vehicles or network. TWM maps can be generated considering historical traffic flow data or just applying traffic policies or recommendations. In this case it is not necessary for vehicles or sensors to send data to MuTraff. Consider, for instance, a traffic flow between a densely populated residential area and several educational centers located at a short distance between them. This flow can be known through manual counting, sensor counting, or crowdsourcing. In any of these cases, we may assume that data is obtained offline. This way, the path or paths of the flow can be estimated, and MuTraff will be able to apply a map generation algorithm based of these paths and flows. In addition, we may add dynamic traffic restriction policies for school entrance and exit times. In a scenario in which maps are generated in real-time depending on traffic conditions, counting is done in real time by means of sensors or crowdsourcing. In the case of using sensors, communication latency is not as critical as in the case of crowdsourcing because the number of sensors is significantly lower, and sensor data updates are usually in the order of minutes. In addition, current proposals in the mobile edge computing field would allow distribution of the computational load when estimating traffic flows in a distributed way. Only essential information of flows would be transmitted to MuTraff to generate maps.
In the case of failure in data sensor collection, the most straightforward recovery approach is to switch to open-loop mode (historic based map 'static' generation). However, the most appropriate system response will depend on the specific scenario.

The MDB Data Analyzer
The MDB data analyzer is the other core component in the architecture. It is used to do data-lake oriented processing and data clustering. Its main blocks are:

•
The Traffic Demand Dissagregation unit, devoted to create synthetic statistical models of individual trips from the data collected from the path sensors in the traffic network.

•
The Data-lake component oriented to collect raw-data in a log-oriented way, to create inferences from them.

•
The Data Collection engine used to roughly parse data for injection into the data-lake.

•
And the Traffic Predictor, which will generate distribution functions for the traffic network usage. They will be requested by the MCSS to generate the TWM maps. It is planned to use convolutional neural networks as those described by [54,55].
Dynamic origin destination estimation (DODE) [56] requires W k a data as described in Equation (2). Extracting individual trips and flow data from the traffic link sensors is a non-trivial NP-Hard (non-deterministic polynomial-time hard) and time-dependent problem that requires high computation resources. It has been a subject of intense research for a long time and many approaches and models have been made [57][58][59]. But nevertheless, there are some direct ways of obtaining W k a information: (a) cloud route calculation services that receive directly drivers requests; (b) tracing individual vehicles in the network (using cameras and other mechanisms) ; and (c) using crowdsensing mechanisms by means of a dedicated app or an embedded measurement rootkit in an app. This crowdsensing mechanism provides anonymous origin/destination trip data and the route taken, but only for a few vehicles. MuTraff MDB uses a combination of DODE model and crowdsensing direct data for contrast and validation.

The MTS Simulation Engine
Traffic weighted maps [µ k,m ] may be used directly in current macro, meso, and microscopic traffic simulators, as they all use Θ network map representations. MuTraff implementation distributes either new network maps, or complementary-costs network maps that replace Θ maps for each individual or fleet.
Current MTS implementation uses SUMO, which implements a car-following microscopic simulation environment [9,18], perfectly fitting the proposed architecture. Figure 3 shows MTS main loop and SUMO integration.

The DMW Middleware
The DMW middleware layer offers the following interfaces for the agents (in REST-API mode): • TWM distribution services, based on several models: (1)  Real-time traffic alert services, to be used by road-signaling systems. They are oriented to increase the adherence factor ψ that will produce better traffic distributions. • Agent oriented interfaces that will increase the performance of traffic prediction algorithms. Information provided by the agents is used to create forecasts for weighting the Π functions: -A route interface where the agent queries in advance its routing intentions or queries about distance and travel-times.

-
A feedback interface where the agent scores its utility from using the routing proposal.
TWM formats are customizable, and can be delivered using several methods, both as complete network maps (in OpenStreet MAps (OSM) format, for instance) or just as edge-weight maps, much more reduced in size. Current experiments use SUMO/XML. Different XML tags and attributes are used to describe the destination of a given map and its choice probability.
Many different alternatives in real scenarios may arise with the purpose of sending maps from MuTraff to vehicles, and then selecting the right map in the vehicle. The most straightforward approach is to periodically deliver a message with the updated set of maps. This set is formed by subsets of maps that we want to allocate to fleets or groups of vehicles (each subset to a fleet or group). We say 'group' of vehicles, because we may allocate TWM maps to vehicles attending other criteria than fleet belonging (i.e., 'taxis'). For instance, we could allocate a specific map subset to vehicles located in a predetermined geographic area.
Thus, each map subset in the message must be tagged at least with the 'fleet' or 'group' name, type, and corresponding options depending on type. A probability tag can be used for each map within the range of a subset, to define the choice probability of a map. For instance, a subset of 10 maps tagged with name = 'residential A', type = 'area', options = 'x1, y1, x2, y2', would define a subset that should be allocated to vehicles within geographical area (x1, y1, x2, y2). If for each map within the subset, the probability is defined as 0.1, each vehicle will select randomly any of the 10 maps with probability 0.1. The general idea is to define map descriptions (tags) to allow vehicles to filter maps.
To guarantee that different fleets or groups will only have access to their own maps, and that there is no disclosure of information, the most direct approach is to use https to guarantee server identity and send encrypted information. We assume that the navigation app in the vehicle protects received information from local disclosure. In the case of fleets (i.e., taxis and ambulances), vehicles will need to register the app to qualify themselves as belonging to a given fleet. In the case of maps that are tagged with geographical coordinates, the app will filter out depending on current GPS (global positioning system) vehicle position.

MuTraff Capabilities for Distributed Routing Environments
There is a broad consensus on the suitability of applying distributed routing techniques in connected and autonomous vehicle scenarios (CAV). The MuTraff architecture proposal is centralized from the perspective of creating and distributing maps, but the computational load for route calculation may be distributed. Thus TWM is not conceived categorically as a centralized system.
On the other hand, although MuTraff defines a single central station TMS that generates and distributes maps, it can be perfectly extended to a set of multiple distributed local stations (road-side units), with a bounded range of action that distributes local weights for routing. We can think of a scenario in which multiple local stations cooperate autonomously to generate maps that globally optimize traffic flows. TWM has applicability both in connected and autonomous vehicle environments, where vehicles may have the capacity to receive maps to decide their routes.
Cooperative behavior between vehicles when selecting routes is induced through strategic map generation, while in many other distributed routing systems, cooperation is performed at route level and not map level. Distributed solutions at vehicle-level may allow to compute optimal routes with a finer granularity, but with higher communication requirements. Using MuTraff, a vehicle only needs to receive maps through a broadcast channel. In distributed approaches, vehicles may need to communicate with other vehicles or with the infrastructure in bidirectional channels.

MuTraff Technology and Practices
The MuTraff framework is based on open-source platforms in a modular style based on micro-services [60,61] enabling integration to third party tools. All the components run under light-weight docker containers using Linux [62][63][64], which allows platform agnostic deployments and on-premise or cloud deployments. Docker technology enables fast and simple micro-services adoption and distributed horizontal performance scaling. Implementation technologies selected for the different components are: • MuTraff big-data core (MDB). There are many second generation big-data tools (improving the hive-hadoop reference) that provides the necessary capabilities. We selected Apache Spark [65,66] for the high performance and scalability of the solution. MuTraff also uses maps from OpenStreetMaps [76] and Amitran coding references [77].

Case Studies
The MuTraff framework has been tested with synthetic and real urban network topologies using traffic flows based on field demand measures. Tests have been carried out using MTS simulator.
Several fleets have been considered for the case studies: cars, taxis, buses, and motorcycles with the distribution shown in Table 2. The MTDemandGen tool (MuTraff Traffic Demand Generator) and the SUMO tool od2trips have been used to create the end-user trips for the microscopic simulation. The same demand is used to compare no-TWM scenarios with the TWM application scenarios that use different driver adherences, different map number and configuration, and other parameters. Traffic is modeled using traffic assignment zones (TAZ) that are logical geo-fenced areas that contain interconnected nodes. TAZs are used to group sources and sinks of trips based on their origin and destination. Traffic demand is modeled with the set of flows between TAZs. There is no bulk demand uploading, as MuTraff simulator MTS injects every trip into the network in its specific timestamp. We consider a uniform distribution over time for all vehicles, as we use a single set of maps during the simulation period. In cases of 5-minute demand allocation, we could consider the calculation of maps every T minutes (T = 5, 10, or 15) and distribute them at once or allocate them temporarily. The maps that are assigned in the case studies have a certain temporal validity (temporal restriction), but several sets of maps could be distributed or assigned selectively over time.
As well, the case studies consider several driver adherences to TWM: ψ 0.1 , ψ 0.2 , ψ 0.5 , and ψ 1 as described in Table 3. For the emissions model we have used the HBEFA3 model described in [7], which is available in the core simulation engine. Fleet emissions references are shown in Table 2. We start with a summary of TWM performance indicators that are to be considered. Then the real-urban network of Alcala de Henares is described, and three scenarios of TWM application are evaluated: global traffic congestion reduction , mitigation of traffic congestion at road incidents and emergency fleets routing.  Table 3. Driver adherence.

Global and Individual TWM Performance Indicators
In order to measure the wellness of TWM it is necessary to consider both global and individual impacts. Table 4 summarizes basic TWM indicators.

Global TWM Indicators
Global impacts in the traffic network consider congested edges, mean speed, total travel-times, pollution, noise, and some others: • DTD t dispatched traffic demand, the percentage of routed demand compared against the total traffic demand exposed to the network: • DTD TW M as successfully TWM routed traffic, as ratio of TWM routed traffic versus incoming traffic: • TTS t total time spent by the vehicles in the traffic network: • THS t , total halting time (congestion time, waiting time), as the total sum of halting times of the vehicles in the network: • NHD t volume of halted demand (vehicles) (minimum speed of 0.1 m/s): • VKT total distance traveled by the vehicles that started their trips in the network: • N MS t network mean speed, as mean speed of the running agents in an instant: • N MV t number of active vehicles in the network in an instant, with the variant of NMV(H) for number of halted vehicles: • NEO t network edge occupancy in the network in an instant, with the variant of NEO(C) for number of congested edges: • GET t NOx,CO,CO2,HC,PMx... total gas emissions produced by the routed vehicles: • NET t total noise emissions generated by the routed vehicles: • PCT t Fuel,Electricity total power consumption used by the routed vehicles:

Individual TWM Indicators
Individual impacts consider the user experience factors such as travel-time, trip cost, or route length. Individual concerns are critical for TWM as they influence driver confidence that is based on objective and subjective previous experiences, word-of-mouth experiences, social-media exposition and others. Individual impacts need to consider TWM users as well as non-TWM users.
To measure individual impacts we analyze the changes produced in every agent at the study variables when TWM is used compared to no TWM usage. Relative changes are considered together with paired statistics. The variables under study are: • TTC k rel Individual relative travel time change (as a percentage over original travel-time), where TT k a TW M and TT k a denote travel-time of a single trip using TWM or not respectively: • RLC k rel Individual route length relative change (as a percentage over original route length), where RL k a TW M and RL k a noTW M denote route-length of a single trip using TWM or not respectively: • MR k a Individual motion rate that helps us measure which time percentage of the individual trip routing is spent in vehicle motion (not halted): MR k a provides a method to estimate individual experience when comparing two routing strategies R 1 and R 2 , which have similar travel-times. R 1 has a better driving experience than other R 2 if MR k a R 1 > MR k a R 2 . Travel-times are said to be similar when their relative difference is bounded under a prefixed limit.

Urban Network Description
Alcala de Henares is a mid-size city with a population of 250,000 people, located 30 km north-east of Madrid, Spain. The city implements a wide variety of traffic scenarios as it is crossed by a main highway connecting Madrid and Barcelona that is used daily by thousands of private vehicles and light and heavy commercial distribution. The city has severe traffic restrictions and pedestrian areas due to the protected middle-age downtown and at the same time it contains many public citizen service facilities including part of the university campus. It also combines dense residential areas together with wide open residential ones. The city is surrounded by an industrial belt with many logistic companies established; the belt also contains wide commercial areas and also additional public facilities like hospitals and the rest of the campus. Alcala is very close to Madrid's international airport and business centers, so there is a heavy daily traffic in and out mixing private, public and commercial traffic. It also has a heavy traffic exchange with close villages.

TWM for Static Congestion Management
Our urban traffic network is split into traffic assignment zones (TAZ) in order to establish traffic flows, as shown in Figure 4 and Table 5. These flows are designed based on two data sources covering heavy traffic hours: (a) network sensor measures located in the main road connections; and (b) crowdsensing data obtained from ad-hoc mobile apps. The first data source enables synthetic flow calculation for the O/D matrix as it contains full traffic data but lacks trip O/D data; the second source provides real routes with O/D data and enables synthetic matrix validation. Figure 5 shows the position of vehicles and measures speed (blue for fast vehicles, red for slow ones). Only a small number of vehicles use the crowdsensing sdk-toolkit. Table 6 shows the TAZ traffic matrix for 2 h, where simulation covers an additional hour for traffic completion.     TAZ-50  200  100  100  100  100  100  100  100  100   TAZ-51  200  100  100  100  100  100  100  100  100   TAZ-60  200  50  200  200  100  100  100  100  100  50  50 To obtain good results for static congestion management, we consider two objectives: traffic network usage maximized by vehicles routes, and trip travel-time minimized by means of best-route choice. This can be achieved using optimal distributions based on previous knowledge of real traffic demand or usage of historical data. This need can also be handled in a sub-optimal way by means of the TWM random function Π • Equation (6) with uniformly distributed weights around the edge speeds.
The case study uses a Π • TWM with 16 maps (µ 1 to µ 16 ), which are used by all the vehicles with the same probability as shown in Table 7. Map µ 0 represent the original non-TWM network map that is used for the fixed routes for buses and also for the vehicles that do not adhere to TWM. They are not rerouted.

Ad-Hoc TWM for Incident Management
TWM may be used to reduce incident impact on global congestion. This incident may be planned or accidental. When an incident appears in the network it usually collapses the affected edge or node and the surrounding traffic area.
MuTraff is used to generate an ad-hoc TWM that modifies road weights around the incident edge i,j x with radius R x using Π x → [µ k,m ] x . It merges edge weights of the standard map µ 0 or current [µ k,m ] if other TWM maps were being used. Radius selects the edges belonging to the feasible traffic paths of card(Path i ) R x that converge to i,j x . It is measured in number of edges as once the vehicle has entered an edge it needs to complete the distance, so congestion should be avoided before it enters the edge.
TWM generator allows us to apply several routing policies: (a) apply fixed weight penalty of value K to the selected edges, or (b) apply a random weight penalty amplified by value K to the selected edges. Random distributions allow that different paths will be selected by the vehicles.
Algorithm 1 shows the [µ k,m ] x generation process with Π x : where several data are required: the incidents location, the Π x function to use and its configuration parameters, and the radius distance R x . TWM distribution follows these steps:

1.
Obtain the TWM [µ k,m ] x and set the time constraints [Γ k,m ] on it. Sometimes it is not possible to know in advance the duration of the incident (as in traffic accidents) so it will be managed by means of monitoring.

2.
Publish the TWM . Some of the fleets may not use it, as occurs with public transport using fixed routes.

3.
Check time constraints: (a) If time constraints are known, disable TWM when they expire.

Incident Experiment Design
Traffic incidents have different impacts depending on traffic network usage. Any congestion control algorithm is not going to provide significant improvement in the case of low-congestion scenarios. We select an ad-hoc congested traffic scenario to analyze TWM impacts. It consists of a directional traffic flow of 2000 vehicles in one hour, which crosses the city from traffic assignment zones TAZ-5 and TAZ-50. These TAZs map to downtown dense populated neighborhoods. The network is congested in some points corresponding to edges in the best-route selection.The flow generates some congestion points in the most used edges.
There is one traffic incident in a high occupation edge is shown in Figure 6, not being in one of the congested ones to avoid results skew. The incident occurs when the network starts to be heavily loaded, from time 2000 to 4800 s from a total simulation time of 7200 s (2 h).
A single [µ 1 ] x TWM is used assuming that it is detected, generated, and distributed in the same time instant of the incident occurrence. The TWM is applied to all the fleets except for public transport (buses), which uses regular routes. The algorithm parameters used are: • Impact radius R x = 5 selecting edges in a connected distance around the incident.

•
Additive constant factor of 20 to discourage edge selection in radius, alpha factor of 5 to reinforce selection of edges in the best-route in case they are used k 1 = 5, k 2 = 20.

TWM for Emergency Fleets
As a case study for fleet constraints, we designed a proof-of-concept (POC) scenario for emergency evacuations, where there is a specific area in a central point in the network (gas-station) that requires specific attention. There are three fleets considered: one standard traffic and two emergency fleets (firemen and policemen). The objective is that the emergency fleets run at free-flow in selected areas. Two emergency corridors must be established to the fire-station and the police-station as shown in Figure 7.
We use TWM to send specific maps to the vehicles over-weighting the emergency corridors in order to clear the standard traffic; less vehicles will use the path, only those that do require it. In the same way, a emergency map is created to force those vehicles related to the emergency to use the specific path. This study case differs from the ad-hoc incident management using a differential routing fulfilling specific requirements and constraints for emergency fleets.

Results
Considering the case studies, we analyze the global impacts of TWM (travel-times, congestion, emissions, and pollution), and the impacts on the driving experience.

TWM Global Impacts
Several experiments are run over the city with the traffic demands explained and ψ 0.1 , ψ 0.2 , ψ 0.5 , and ψ 1 driver adherences. We can see the impact of using TWM over travel-times in the histograms in Figure 9, which represent the travel-time distribution for all the trips. Table 10 compares the relative change of TWM usage over the non-TWM scenario considering different driver adherences. TWM usage reduces mean travel-times progressively with driver's adoption, improving travel-time 19.6%. DTD, routed demand, also increases with TWM usage, up to 3.1%. Drivers are using alternative paths as TWM suggested, and this is the reason for this enhancement, but also for the slight mean route length increment (up to 1.9%).   Figure 10 shows total travel-times and total distances for all the vehicles where we can check that TTS has been significantly reduced (14%) and VKT suffers a 5% penalty as the drivers use routes different from the best-cost physical route.  We can observe in Figure 12 left heat-map of the network at timestamp 3000 showing density of halted vehicles and top-used edges. This data may be used for MuTraff feedback and create historical records to create TWM routing based on historical data. This TWM may discourage selecting these edges for the best-routes.  Driver's adherence to TWM is a critical factor for success and improvement. It is achieved by means of three main streams: individual perception that enables viral word-of-mouth adoption, marketing campaigns, and/or legal recommendations or constraints. Individual perception is usually measured by the NPS key performance indicator (net promoting score) that compares promoters and detractors when asked for the individual recommendation based on own experience [78].
Global statistics mask individual perceptions and it makes necessary to compare each single trip under TWM and non-TWM scenarios. Histograms of individual travel-times improvement TTC rel help us to analyze this factor showing how many drivers have been negatively or positively impacted. Real adoption models of TWM should combine both objective factors (route length, travel-time, and cost) and subjective factors (halted-times, crossings, etc). Figure 13 shows TTC rel for ψ 0.5 and ψ 1 adherences. It shows the objective improvement at the right side of both diagrams: A large number of drivers have significantly reduced their travel-times with respect to the original travel-times. They were the previously congested vehicles. TWM benefits reach all the vehicles, not only to those that use TWM. This is the obvious consequence of routing some traffic out of the shortest paths: The whole network status gets improved. Figure 14 shows the cumulative probability distribution for travel-time improvement at ψ 0.1 , ψ 0.2 , ψ 0.5 and ψ 1 adherences. Even at very low adoption scenarios such as ψ 0.1 (10%) the probability of being positively impacted is remarkable. TWM provides early global impacts even with a small volume of drivers.

Comparison of Benefits for TWM and Non-TWM Users
Under normal situations, the traffic network holds TWM and non-TWM users. Traffic variations affect both of them. Figure 15 details two overlapped histograms considering adherences of ψ 0.2 and ψ 0.5 . In the first scenario, the positive slope shows that non-TWM users are being highly improved in their travel-time perception by the TWM users. For ψ 0.5 we see that both populations are obtaining similar benefits. TWM drivers are using alternative TWM best-routes considering new network views, and then clearing edge occupation in the non-TWM best-routes. We call it the TWM route clearing effect.  In spite of these improvements, global metrics in this urban topology are affected by the large routing capacity of the highways in the traffic network that route a large part of the vehicles. We should consider the situation in dense-populated neighborhood with no highways affection. In Figure 17 we have selected a dense-populated area to analyze how pollution has been affected by TWM. Even with very low adherences ( ψ 0.1 ) pollution is reduced very significantly reaching 18% in case of GET PMx . As we increase TWM adoption, we reach up to 40% reduction. The noise footprint is also reduced in a similar way. Individual traffic is best routed by alternative paths.

Dynamic Incident Management
Several driver adherences of ψ 0.1 , ψ 0.2 , ψ 0.5 , and ψ 1 are considered for multimap adoption experiments. Figure 18 and Table 11 show TWM [µ 1 ] x impacts for ψ 0.5 and ψ 1 adherences. TWM clears congestion suggesting best-route alternatives considering over-weighted edges around the incident. Travel-time variation perceived by the drivers in this case raises up to 52% for a full ψ 1 adherence, though it depends on concrete scenario: road network, time-instant, traffic payload, and other factors. Histograms compare the same incident scenario using TWM under two different adherences (0.5 and 1.0; in red) and the non-TWM situation (green). Congestion peaks occur at the right side (green) and progressively cleared with TWM usage (red).   Figure 19 shows the incident impact on global congestion, raising the number of halted vehicles in the network. It also shows the impact of [µ 1 ] x TWM with different adherences on halted vehicles NMV(H), on congested edges NEO(C) and in network mean speed NMS. As the adherence increases, best results are obtained, leading even to full congestion mitigation.  Figure 20 for ψ 1 adherence where it is clear that vehicles that where initially blocked by the incident (right-side) have obtained a great reward for using TWM in terms of travel-time. Very few vehicles have been negatively impacted.  Figure 21 shows that global gas emissions GET NOx,CO,CO2,HC,PMx are reduced in the same rate as the incident is cleared, always depending on the number of TWM adopters for the clearing map. Also noise emissions are reduced, though ψ 1 adherence reverses the situation as vehicles run at higher speed increasing noise.

TWM for Emergency Fleets
Figures 22 and 23 represent the same timestamp in the scenarios of no-TWM and TWM with 50% adherence application. In Figure 22 standard traffic uses the whole network together with the emergency fleets (firemen and policemen). In Figure 23 TWM application has cleared the two emergency corridors, routing standard traffic to alternative paths. Fire and police vehicles run at free-flow speeds, having a low travel-time variance (<1%).

Conclusions and Future Work
Traffic weighted multimaps is a traffic routing mechanism that focuses on multi-objective traffic routing needs. TWM maps are generated for the different traffic groups. TWM relies on big-data usage and enables static and dynamic traffic management and can be used for a wide range of scenarios, from global concerns to spurious incidents. Some of which were shown in this paper, i.e., global congestion management and dynamic incident management. Also, experiments show how individual driving experience is perceived in relationship to TWM adoption models. MuTraff architecture has been introduced as a feasible technical platform that can be seamlessly integrated into existing planning and routing platforms and also existing traffic agents.
The experiments have used a real urban traffic network under real traffic conditions, to show how MuTraff can provide TWM-based solutions that improve all the global indicators: travel-time reduction, congestion reduction (halted vehicles, congested edges, and others), pollution gas emissions, and noise footprints.
Simplicity, scalability, and safety have a cost. TWM is a stochastic routing technique that has not been designed to achieve theoretical optimal solutions as in other centralized routing solutions. Thus, there is plenty of research to be done to design more advanced algorithms to calculate TWM maps and improve routing. The stochastic nature of TWM and the use of random maps do not guarantee to improve travel time for all the vehicles in the network. We need to implement new algorithms to generate maps in specific scenarios: congestion avoidance, evacuation, contingency plans, etc. In our work we are not considering driver behavior from a temporal perspective, which may have a strong influence on the adoption of TWM. This issue requires system dynamics analysis in order to study TWM adoption, where improved and penalized vehicles modulate a feedback loop that will affect the adoption rate. In relation to drivers' behavior during the travel-time, we have not considered the influence of rerouting according to current traffic conditions. The improvement achieved by TWM depends mainly on: (a) scenario conditions, (b) adherence of traffic agents to TWM, and (c) design of the Π x optimization function to cope with congestion situations. TWM has limited impact in low-traffic scenarios, as agents are close to their ideal performance (travel-time), though in all situations network and fleet performance indicators are improved. TWM offers its best performance capabilities in high-density traffic scenarios and congestion, enhancing individual objectives and also improving group and global indicators. Real-time response to network and traffic incidents is fast and effective, and TWM is able to release new ad-hoc multimaps for a new situation using the available information.
The benefits of MuTraff for TWM management include: (a) usage of big-data techniques to handle complex traffic scenarios and control policies where analytical solutions require heavy computing to get optimal solutions; MuTraff provides a fast response pseudo-optimal solution; (b) it offers an early and real-time decision making environment for drivers and traffic authorities; (c) it is conceived as a modular platform based on standard open-source frameworks and is able to evolve rapidly in the future; (d) it offers back-end services for route planning and also REST-APIs for route calculation at agent side, compatible with most of the existing traffic platforms; (e) MuTraff preserves traffic agents autonomy as TWM takes into account individual freedom of route choice; (f) MuTraff preserves data privacy: no individual identification or tracking is required; and (g) it works with partial adoption models as it does not require that all the vehicles use it. It may be used in a biased manner (only for certain categories or policies).
TWM contributes to innovation with a practical and feasible proposal as shown with MuTraff architecture, enabling a big-data based model suitable for application in the broader concept of smart cities. It allows multi-objective management of needs from different traffic categories: standard traffic, public transportation, electric vehicle, pay-to-drive and car-sharing fleets, commercial distribution, disabled people, pollutants, dangerous transport, routing due to weather, timetables, etc. It is self-replenished and self-learning. MuTraff and TWM may be used with standard optimization algorithms and techniques for route calculation. They do not require V2V communications nor specific sensors or signaling, and the computing infrastructure required may be allocated in a cloud with elastic capabilities.
There are many future research possibilities that have been pointed out in the paper: (a) creating optimal static TWM distributions for historical data with evolutionary algorithms, (b) creating dynamic traffic assignment models using TWM based on previous driver experiences as we have shown that they may be critical for TWM adherence, (c) using TWM for zone routing policies as pointed by [49], (d) applying TWM to hyperpath calculation using techniques described by [12,34], (e) creating evolutionary algorithms and optimization functions for finding local area minimum for routing maps that can cover eventual time-dependent situations, and (f) extension of the MuTraff MTS simulator with mesoscopic simulation engines. Acknowledgments: Our thanks to Satya-Insights (http://www.satya-insights.com) for the sharing of Alcala crowdsensing data.

Conflicts of Interest:
The authors declare no conflict of interest.

Abbreviations
The following abbreviations are used in this manuscript: