A Framework for Enhancing the Operational Phase of Traffic Management Plans

Road traffic emergencies are dangerous and unexpected situations that require immediate actions by the authorities. These actions involve to attend to the people who have been affected by the emergency and to minimize its consequences. A Traffic Management Plan (TMP) is a set of pre-defined measures and actions designed to produce an effective and efficient use of available resources in order to deal with a specific road incident. The operational phase of a TMP involves the coordination of several independent agencies (road managers, traffic police, firemen, etc.). These agencies must provide the resources required by the TMP in the deployment of the measures and actions. In this paper, a new framework to support the TMP operational phase is presented. This framework models each agency as an intelligent agent and it uses a reverse combinatorial distributed auction as the core component of a negotiation process. The goal of this negotiation process is to obtain a common agreement on the best possible allocation of resources taking into account the role, competencies and interest of the involved agencies. The framework has been implemented in a real scenario with real data. The tests developed have demonstrated that the system is able to manage the resources in terms of the execution time and the quality of the provided solutions.


I. INTRODUCTION
Road traffic incidents are unexpected and it is therefore extremely important that actions taken by all those implicated in the situation are quick, efficient and above all, well coordinated. Incident resolution is key for: a) attending injured people, they need to be assisted as soon as possible, b) reducing traffic congestion, as time goes congestion grows upstream and it may affect neighboring roads and c) avoiding secondary accidents, congestion or cars on the roadside that may produce new incidents. Therefore, it is fundamental for the authorities to apply the adequate tools available in order to deal with the incident. However, this is a difficult task because the incident is unexpected, so the location and severity is unpredictable. Furthermore, there are several independent agencies that must collaborate to solve the incident, e.g., traffic police headquarters, hospitals, civil works agencies, fire stations, etc.
This collaboration is necessary for three main reasons: 1) one agency does not have all the resources needed to solve The associate editor coordinating the review of this manuscript and approving it for publication was Yichuan Jiang . the incident; 2) several agencies may be able to provide the same resource so, which agency should do so? and 3) there is also legal jurisdiction to be taken into account. For example, local traffic police does not have the right to close a motorway. This closure has to be effected by national police, but only after the approval of the road traffic management responsible.
There are different approaches to work and manage traffic incidents. In [1], the Virginia Department of Transportation (U.S.) developed, in 2009, a guidance document to prepare transportation operations. The core concepts related to incident management are 1) Operational Needs, 2) System Overview, 3) Operational Environment, 4) Support Environment, and 5) Operational Scenarios. In [2], a guideline to develop Operational Traffic Management Plan is presented. This guideline is focused on a Risk Management Plan and consists of: a set of procedures and practices and a traffic control diagram for each traffic measure.
In Europe, the Spanish Traffic Directorate developed a methodology to deploy Traffic Management Plans (TMP) [3]. In this document, the need of cross border traffic management coordination is analyzed. This work was extended in the FIGURE 1. TMP description. The definition phase includes the analysis of the possible types of incidents, the road network, the ITS systems and the actors. Once this analysis is done, the TMP is developed, including the scenarios, the measures and the actions. In real time, when an incident occurs, the TMP is activated and the measures and actions have to be deployed accordingly to the scenario.
frame of several Euroregional projects [4], [5], [6]. The work continued in the EasyWay project [7] (where several public and private European traffic organizations were involved) and finally, in 2012, a common guideline identified as ''Traffic Management Plan for corridors and networks'' [8] to develop TMPs was approved by all European countries.
The actions developed by the European Commission, both in the Directive for the ITS framework [9] and the action plan for the deployment of the ITS [10] maintain the relevance of enhancing the use of TMPs in modern traffic management systems.
In the TMP deployment guideline [8], a TMP is defined as a set of pre-defined measures and actions to solve a specific road incident. The operation workflow is: when the incident is detected, the traffic organization responsible identifies the scenario in real time. The scenario describes the incident and it includes: location, severity, current traffic situation and its possible evolution. Using this information, this traffic organization searches for a TMP to determine the different measures to be applied to solve the problem. Each measure implies carrying out several actions. Each action could be taken by several agencies. Once all agencies are ready to carry out the corresponding actions, the related measure can be deployed.
A TMP involves two phases [8]: a definition and an operation phase (see Figure 1). In the definition phase, the problem to be faced is defined and described (road incidents, adverse weather situations, etc.). It includes the road network analysis and the actors involved in resolving the situation. Then, scenarios, measures and actions are described and defined in a coordinated way for all actors. So, this TMP phase is created offline, that is, before the incident occurs.
The operation phase is developed in real-time, that is, an incident has occurred, the related TMP is activated and measures and actions have to be taken. Currently, a human coordination process is performed among the traffic agencies and the agencies involved to determine which resources from which agency have to be deployed in each action and measure. There is no automatic procedure by which each agency is able to reach agreements with other agencies.
A TMP can be explained with an example. An accident occurs on a motorway segment at a peak hour period. Several cars and one truck are involved in the incident. The truck has spread its load on the carriageway. The load contains dangerous goods. It causes a breakdown in the motorway: both lanes in one direction are blocked. Several people have been seriously injured. This description is considered the TMP scenario.
In this scenario, the TMP measures to be deployed are not only focused on dealing with the accident and providing medical aid for the injured people, but also on minimizing its consequences. Thus, some of the measures to be activated are: a) the provision of medical attention at the incident site; b) management of the incident area; c) activate alternative itineraries; d) road maintenance support to clean the road of dangerous goods and e) provide traffic information to drivers.
In order to be ready to take a specific measure, a set of actions must be agreed upon by agencies that manage the requested resources. For example, for measure a, medical attention at the incident site, which hospitals have to provide the required ambulances.
In the proposed TMP example, several agencies are involved. Some of these agencies are: • The traffic management agency providing traffic monitoring and traffic information services. Usually, this agency is responsible for the deployment and coordination of the TMP.
• Traffic police agencies. It can be assumed that at least two different administrations are involved: a Regional or National one responsible for motorway management and a Local one responsible for some parts of the alternative routes.
• Health agencies (Hospital) responsible for providing ambulances. The requested ambulances can be of several types: Advance Life Support (ALS), Basic Life Support (BLS), etc. Therefore, one or more of these agencies may be involved. Thus, all agencies have to collaborate to deploy the TMP. This collaboration is based on common knowledge of the TMP including the incident, its consequences and the actions to be deployed.
In this paper, a new distributed framework to automate the operational phase of a TMP among the involved agencies is presented. This new framework extends the measures that provide information to drivers affected by the incident (as proposed in [11]) and it also automates the measures focused on traffic control and emergency services in order to improve the allocation of resources involved in dealing with the incident (traffic patrols, ambulances, medical care, firemen, etc.). The paper is structured as follows. Second section presents other research works on the coordination of resources from different organizations to support the allocation of resources for traffic accidents. However, as will be explained, none of these described works is suitable for application to the context of TMPs. Then, the reverse combinatorial distributed auction is identified as a suitable candidate to rule the protocol for this automatic allocation of resources. The third section describes the components of the proposed framework: knowledge model, actors and protocols for interaction. Section four describes a direct application of this framework to a scenario using real data for a traffic emergency. The evaluation of the deployed system is described in the following section. Finally, conclusions are drawn.

II. RELATED RESEARCH
Most of the research into coordinating the allocation of resources for traffic emergencies define the proposed systems as multi agent architectures. Modeling each organization as an agent is a natural and direct form of addressing the autonomous behavior an organization can take in any moment. In [12], a multi agent system for coordinating ambulances for medical emergencies is presented. The system tries to improve the use of ambulances so that patients can be assisted as quickly as possible. The system architecture works as teams of ambulance agents plus one ambulance coordinator agent. This coordinator agent is responsible for assigning the different ambulance teams to the different emergency services. It uses a negotiation mechanism, based on auctions, to determine the best use of resources. The different teams of ambulance agents bid for an emergency service based on their own estimated time of arrival at the location of the emergency. This system is only focused on medical services, so a) the congestion of roads near the emergency area is not taking into account in the estimated time of arrival to the location of the incident and b) only ambulances and not other resources (firemen, traffic police, etc.) are involved in the negotiation. Another main constraint is the way the teams of ambulances are defined. These ambulance teams are defined before the negotiation starts, so it is not possible to combine ambulances from different teams of ambulance agents in a single part of the solution provided.
In [13], a new method to improve the allocation of medical resources in a traffic accident is described. The method is based on a genetic algorithm that provides the final set of resources to be sent to the accident area. The method takes into account four different objectives: Maximizing the quality of the assistance, costs, overuse of resources and trespassing the emergency time threshold. The method uses different multi-objective algorithms to select the most adequate set of resources to be used at the accident spot. The method is appropriate for the allocation of resources. However, it uses a centralized approach, i.e., every involved agency stores their up-to-date data on the availability of resources and their current features in the same centralized computational unit that runs the different multi-objective algorithms. Last, it only allocates medical services, so it has the same constraints pointed out in the system described previously.
The work [14] describes an Agent-Based Simulation system (ABS) to analyze the resources allocation in a hypothetical major incident involving two sites. The system implements different kinds of agents corresponding to the different roles identified in the incident analysis. These roles are focused on: ambulance services, fire services and police services. Although the ABS includes the roles of fire services and also police, the incident resolution is only based on how to split the available medical resources for dealing with two incidents that occur simultaneously in the same area.
In [15], a multi agent system for dispatching emergency vehicles is described. Its main objective is to coordinate agents to reach good quality solutions in a distributed way. The system identifies four different types of agents: a) agents responsible for identifying the emergency (called simply agents), b) agents responsible for the management of one area (Zone agents), c) Station agents, who are the responsible for the ambulances and d) vehicle agents, where each agent corresponds to a different ambulance. The system proposes two approaches to coordinate the vehicles. The first approach is based on a Call For Proposal request (CFP) managed by the zone agent to be sent to all station agents. The second approach is based on an auction mechanism. Again, this system is focused only on medical services and no other roles or agencies are involved.
All these described systems are mainly focused on the medical service part. Besides that, they do not work on the basis of a TMP and it would be an extremely complex task to try to adapt any of these systems to work on a TMP as expressed in [8], [16]. VOLUME 8, 2020

A. COORDINATED RESOURCE ALLOCATION IN THE TMP OPERATIONAL PHASE
There are several specific aspects to deal with when defining and solving the automatic arrangement of the required resources in a TMP: 1) there are several different agencies involved, 2) each agency manages its own resources; 3) each agency makes a proper ongoing valuation of the availability and location of its resources; 4) all agencies comply with the laws of collaboration in traffic emergencies; 5) no one agency commands all others due to the administrative and/or legal distribution of responsibility; 6) a TMP does not state which agency has to provide each resource; and 7) every individual resource demanded in a TMP can usually be provided by more than one agency.
The field of auction theory [17] is a natural candidate to be considered when searching for a suitable candidate that deals with the previously related features. More precisely, the model of combinatorial distributed reverse auctions [18] fulfills these aspects. In a reverse auction the auctioneer expresses the required items and the bidders manage items that can be delivered and which satisfy the auctioneer's requirements. Because no bidder has all the required items, the complete solution provided has to combine bids from different bidders. Then, a combinatorial number of bids has to be analyzed and evaluated. In order to make this analysis and evaluation process reliable (from the point of view of the bidders), the role of the auctioneer is assumed (in the sense of distributed role) by the bidders themselves. In this way, each bidder can observe that the bids proposed by whatever other bidder is following the rules of this auction. Also, a bidder can use any other previous partial bid (from whatever other bidder) along with its own valuation of its managed resources to put together new complete bids that can be made. These new complete bids are publicly communicated to the other bidders until none of the other bidders is able to put forward a better complete solution for the requested items. Several auction protocols that rule reverse distributed combinatorial auctions have been proposed in [18], [19], [20] and [21]. However, since the resources required in a TMP are expressed in generic terms (e.g. 2 ambulances with ALS) an auction protocol able to deal with generic resource types is needed. The PAUSETA (Progressive Adaptive User Selection Environment by Type Agreement) auction protocol [22] holds this feature.

B. THE PAUSETA PROTOCOL
Let r i , 1 ≤ i ≤ t, be a generic resource type i (for example, being i the type ambulance with ALS) and t the number of generic types of resources in the auction. Each r i has associated with it the number of resources of type i requested in the solution. In PAUSETA, each bidder values privately the resources that it manages. The bigger the value assigned, the greater is the intention of this bidder in providing that resource to the overall solution. In the process of evaluation of its managed resources a bidder can also exploit the synergy of combining several resources of several types of resources in a single bid.
The number of potential bids is very high, so PAUSETA sets an order in the way bids can be proposed. The PAUSETA protocol runs in t stages. In the first stage an open cry auction protocol is ruled: each bidder proposes as many highest valued individual r i bids of its managed resources of type r i as it has available and are required in the solution.
The other stages run in a different way. In the stage k, 2 ≤ k ≤ t, each proposed bid must satisfy four constraints: 1) it must be a Complete Solution (CS), that is it must contain an offer for every resource requested for the solution; 2) it must outperform the valuation of the previous CS; 3) it can contain whatever other partial bid of a previous CS proposed by whatever bidder of the same stage or from previous stages; and 4) in the stage k each partial bid in the CS may contain up to k types of resources. For example, in stage 3 a solution proposed by a bidder can only be composed of bids of 1, 2, or 3 types of resources and the number and type of resources involved in a solution in this stage 3 must be a plausible CS. When there is no bidder that can outperform the last CS proposed, the current stage k finishes and it starts the stage k + 1. When the last stage, stage k = t, finishes, the last CS is the solution with the highest valuation in the auction, so it becomes the final complete solution agreed by all bidders.
This protocol provides a feasible solution if one exists. In a stage k ≥ 2, any proposed bid involves a plausible CS. This protocol also monotonically finishes because only a CS with a higher valuation than the previous one is allowed in each stage, and the number of stages is limited to t. However, as it happens in all combinatorial auctions, each bidder has to deal with a high number of combinations of its own bids together with the public available bids from other bidders to outperform the current CS. Mendoza and Vidal [23] propose the use of approximate algorithms to deal with this problem. In the PAUSETA protocol a greedy algorithm has been proposed [24] that runs in polynomial time.

III. THE PROPOSED FRAMEWORK
This framework is going to be described by addressing its main components: the knowledge model, the software architecture and the interaction model.

A. KNOWLEDGE MODEL
The knowledge model has been developed using traffic ontologies [25]. The ones developed in [26] and [27] have been updated and extended. These ontologies support data and information from three different domains: • The domain of the traffic environment. It includes structured information of the road network elements (segments, junctions, lanes, itineraries, etc) and incidents (location and severity).
• The domain of emergencies and TMP. It defines features of traffic emergencies and traffic management plans (measures, actions, agencies and actors).
• The domain of negotiation. It describes the elements required to implement the protocol (a reverse distributed combinatorial auction) for the negotiation (environment, bidders, bids, bid sets, and valuation). Figure 2 shows some elements of the traffic environment and emergency domain ontologies.

B. SOFTWARE ARCHITECTURE
The software architecture is defined as a multi agent architecture (MAS) in which each organization involved in a traffic emergency is naturally modeled as an autonomous agent.
There are two kind of agents: 1) Agency agents, which are the responsible for taking action in the case of any traffic emergency, and 2) Platform agents providing utilities inherently related to the maintenance, monitoring and surveillance of the overall MAS.

1) AGENCY AGENTS
Agency agents can play one of two roles: • Incident manager role. The agent that runs this role is in charge of identifying which TMP and scenario have to be activated according to the traffic emergency being detected. From this scenario, the measures and actions required to deal with the problem, including the requirements for the solution and the involved agents providing resources are identified. This agent is also responsible for triggering the negotiation protocol between the involved agencies.
• Resource manager role. An agent running this role manages resources that might be deployed to solve the traffic emergency. The modeled organizations that can run this role are the following: Police, managing police patrols that may be put in the required locations of the road network to control the traffic around the incident spot; Hospital, managing different types of ambulances and medical support; Crane, managing different types of cranes suitable for use with heavy and/or light vehicles; Firemen, managing firetrucks and firemen with diverse material; and Road works maintenance managing the resources needed to clean wreckage from the road. Figure 3 shows the software architecture of an Agency agent. The state of an Agency agent is defined by the current instantiation of its knowledge model. This state is private information in each agent. This state evolves due to the ongoing features of its managed resources and the interaction with the other Agency agents. The engine behavior component conducts the actions of an Agency agent and it is composed of three different modules: • Objectives, interests and usefulness management. This module is responsible for managing the agent goals and to update its knowledge model. It also helps in the valuation process for each resource managed by this agent.
• TMPs. This module is part of an Agency agent with the role of Incident manager. The tasks related to the identification of what TMP to activate as well as its related measures and actions are performed in this module.
• Negotiation Module. This module is responsible for the management of the entire negotiating process. If the role played by an agent is the Incident manager role then: 1) it determines (using the platform agents) which Agency agents with the role of Resource manager are active in the framework; and 2) it notifies these implicated agents of the total generic resources demanded to deal with the traffic emergency detected. If the role played by an agent is the Resource manager role then: 1) it shows an alert to the human user with the information about the traffic emergency notified and 2) it participates with the previously described auction protocol to search for a collaborative solution in arranging the requested resources in this traffic emergency. Besides the behavioral engine, there is also a component for the management of its own resources. This component maintains all the related information on these resources: its VOLUME 8, 2020 characteristics, location and current status (that is, if the resource is currently being used or not and when it will be released). When a negotiation request arrives at an agency, via the negotiation protocol, the behavioral engine analyzes the resources requested. Then both, the behavioral engine and the resource manager, determine what resources can be used in that request and the valuation for each one of these resources to be used in the negotiation process.
Agent communications with other agents are developed in two ways: • Internal communications. Each agency communicates with its own resources for several purposes. These communications are performed with the physical mediums available in each agency (Internet, telephone, radio, etc.).
• External negotiations. These kinds of communications are not only addressed with mainly other Agency agents to run a negotiation process, but also with Platform agents.

2) PLATFORM AGENTS
The Agents Management Service agent (AMS) manages the active agents in this framework. Every Agency agent must sign onto this agent at booting time. The Directory Facilitator agent (DF) manages the roles, features and the services Agency agents may provide. AMS and DF agents are standardized and specified by FIPA [28], and they are included in the JADE middleware tool [29]. Therefore, these agents provide the means to register, deregister, update and search for services for all the other agents. The Interface agent uses a visual component to show the available information regarding the management of the incident. That is, this agent shows the road network, the information related to the activated TMP, the incident signalized information, the activated alternative itineraries and the final location of each requested resource for every measure and action.

C. COMMUNICATION AND INTERACTION MODEL
The communication model used in this framework is message-passing. The syntax and the parameters used in a message follows the FIPA ACL specification [30].
The interaction model describes the interaction protocols in this framework. The following protocols use some standard protocols defined by FIPA in [31]: • Registration Agency-DF. Interaction between an Agency agent and the DF agent. This interaction subscribes the Agency agent and the services it provides into the yellow pages service managed by the DF Agent. The services provided by the agent depend on the agency role (Incident manager or Resource manager). This protocol follows the standard FIPA Request protocol.
• Registration Interface-DF. It is an interaction between the Interface agent and DF agent. Using this protocol, the Interface agent is logged into the yellow pages with a specific service: traffic emergency monitoring. This protocol follows the standard FIPA Request protocol.
• Incident. It is an interaction between the Agency agent with the role of Incident manager and the rest of agents of the framework. Using this protocol, it broadcasts that an incident has been detected and information about its main characteristics. This protocol follows the standard FIPA Inform protocol.
• Search-service. Interaction between an Agency agent and the DF agent. An agent asks the DF agent which agents provide a particular service. This protocol follows the standard FIPA Request protocol.
• Incident Send-needs. Interaction between an Agency agent with the role of Incident manager and other Agency agents with the role of Resource manager that manage resources requested by the measures and actions to be activated in response to the traffic incident detected. This protocol follows the standard Inform FIPA protocol.
• Activate-Measure. Interaction between the agency in charge of the incident management and the agents that have different resources in the measure to be activated. This protocol follows the standard Inform FIPA protocol. The distributed combinatorial reverse auction between Agency agents to fulfill the requirements described by Incident manager is ruled by the Negotiation protocol described bellow.

• Negotiation protocol. It is an interaction among all
Agency agents to support the agreement about who and how the resources requested have to be provided by. The protocol is implemented with several interactions with the standard FIPA Inform protocol acting as basic steps. In Figure 4, the negotiation protocol flow is shown. An Agency agent with the role of Incident manager, identified as A IM , sends a message to initiate the negotiation among all the involved agents that manage resources requested in the solution. This message contains information on what and how many resources of each type are required and who the agents involved are. The following steps implement the PAUSETA protocol defined previously. The first stage starts. Every involved agent values its individual managed resources required in the solution. Then, it broadcasts a message containing as many resource-value pairs as possible for each type of resource. All agents receive these messages from the others and the first stage finishes. In any other k stage, each agent calculates a complete solution (CS k ) that must outperform the previous CS k . This new CS k can only contain several single or joint bids for up to k types of different resources. To build a new CS k an agent can use its own bids or bids proposed by other agents in previously received CSs. If any agent broadcasts a new CS k at this k stage, then the other agents can use any of the bids included in this CS k to calculate a new CS k and broadcast it. The k stage finishes when no new CS k are broadcast. Then, the next stage k + 1 starts for all agents. When the k = t stage finishes, the last CS broadcasted is the one with the highest valuation so it represents the complete final solution. A deep and complete specification of this negotiation protocol is exposed in [24].

IV. TEST-BED IMPLEMENTATION: METROPOLITAN AREA OF CASTELLÓN DE LA PLANA CITY
In order to test the framework functionality a test-bed has been implemented. The metropolitan area of Castellón de la Plana City in Spain has been modeled. The modeled area covers 134 km. of 11 different roads (local, regional and national). The implemented model includes: • 75 road segments and 39 intersections. • 1 police agency with traffic management competences. • 2 different police agencies managing police patrols on headquarters and on roads.
• 3 hospitals. • 2 fire stations. • 2 maintenance companies. • 2 crane agencies. Each one of these organizations in the scenario has been modeled as an Agency agent that uses the knowledge and interaction models described in this framework. The way each agency sets a valuation for each one of its managed resources is driven by the following procedure. The agencies located in urban areas use a set of virtual links to the modeled intersections. Each virtual link models the distance and travel times between the agency and an intersection. Based on this data each Agency agent is able to set a (maybe different) individual valuation for each one of its managed resources.
A crash accident involving cars and one truck carrying dangerous goods has been simulated. The accident has occurred in the CS-22 motorway. This motorway is the main access to the harbor. The accident blocks the motorway: both lanes in the direction of the harbor are blocked and part of the truck load is spread on the carriageway. There are several seriously injured people. The police agency with traffic management competencies identified the TMP to deal with this scenario. The measures to be activated are: a) medical attention at the incident site; b) management of the incident area; c) activate alternative itineraries; and d) road maintenance support to clean the road.
In figure 5, the incident area is presented. Four alternative routes have to be activated. Alternative routes 1 and 2 are activated to support the circulation of vehicles trapped by the blocked motorway. Route 3 is the route recommended for light vehicles, and route 4 is recommended for heavy vehicles.
The required resources to activate the measures and actions are: • Two ALS ambulances. This kind of ambulance can provide surgery to the severely injured people at the incident site.
• Three BLS ambulances. Each ambulance provides medical attention to the injured people that have to have their condition stabilized before being transported to the Hospital.
• Two fireman units to assist in extracting injured people from their cars. They also assist cleaning up the accident site. VOLUME 8, 2020 • Two standard cranes to remove vehicles involved in the incident.
• One special crane to remove the truck.
• Nine police units. One patrol to control in situ the incident area. Eight units to control access to the incident area and to redirect the incoming traffic at the checkpoints of the alternative itineraries.
• One maintenance road unit to assist the carriageway cleaning. Figure 6 presents a snapshot of the interface agent. It shows the locations of the incident and the involved agencies. The police patrols deployed to control the itineraries are also shown. In the lateral panel, the incident and the TMP information is presented.

V. EVALUATION
In order to evaluate the developed test-bed, different tests have been performed. These tests permit the assessment of the test-bed behavior, its viability in terms of execution time, quality of the solutions obtained and scalability.
The value assigned to each resource in each agency for this testbed has been determined largely by the distance the resource must cover from its current position in order to reach the position assigned to it in the management of the incident. However, due to the fact that the area in which these agencies are permitted to operate is sometimes limited (i.e. local police can only operate within the municipal district) this factor must also be taken into account. The result obtained when the negotiation process is finished is the bid that involves the least accumulated distance constrained by these legal limits.
The SCPA (Shortest Common Paths Assignment) algorithm is a centralized algorithm that calculates the shortest route of all resources to all necessary locations to cover all requirements for the management of the incident. The provided solution serves to establish a lower bound regarding the minimum optimum distance traveled by all requested resources to be allocated. The SCPA algorithm solves the well-known transportation problem of linear programming [32]. However, the SCPA cannot be applied in  a TMP scenario because it does not take into account the administrative and legal limitations exposed above. Furthermore, the requirement to get centralized knowledge of the location and state of every resource of every agency that can be involved in the resolution of a traffic incident is very hard to manage in a real environment. Table 1 shows the locations (latitude, longitude) of the incident and the agencies. The first line shows the incident location. The remaining lines show the agency location and the distance from each agency to the incident location using three alternative itineraries.

A. TEST 1.-GENERAL BEHAVIOR
In this test, the system is loaded with the initial configuration of the scenario explained in the previous section. To analyze the results, the test has been run in 100 simulations in which the number of agencies and their available resources remains constant. However, the position of the different mobile resources (police patrols) along the road network have been randomly modified.
The results of this test are presented in Figure 7. It shows the distance traveled comparing the developed system (MAS) and the SCPA algorithm. The graph shows that the distances provided by the algorithm SCPA are always smaller than the distances provided by the proposed system. This situation is expected because, as explained above, the MAS takes into account administrative and legal competences. However, it is important to note that both systems behave accordingly: when one rises or falls the other does likewise. This behavior implies that the response of the developed system mimics the SCPA results.
The statistical analysis, presented in Figure 8, supports this impression. The box plot in Figure 8(a) shows that the results of the two systems have a symmetric distribution: both medians are located approximately at the 50% level in each box, the distribution of values in the second and third inclusive quartiles as well as those in the first and fourth quartiles are similar. The calculation of the mean distances for the negotiation protocol produces a value of 195.6 while the median has a value of 195.3. For the SCPA, both measures, media and median, have the same value: 158.8. Moreover, both systems follow a normal distribution (see Figure 8(b) and (c)). In both charts, the dot pattern follows a straight line, so it can be assumed that the results of both simulations follow a normal distribution.
Finally, the linear correlation analysis presented in Figure 8(d) shows that there is a strong positive linear correlation between the distances covered in both systems (r = 0.7163) which supports the idea that the MAS mimics the results of the SCPA algorithm.

B. TEST 2.-MOBILE RESOURCES SCALABILITY
This test analyzes the system scalability when the number of police patrols available is increased. All other features of the scenario and the requested solution remain the same. To perform this test, a new police patrol has been randomly located in the scenario every 10 simulations. So, in the last 10 simulations there will be 9 more police patrols available. Figure 9 shows the distance covered by all resources involved in the incident resolution compared with the distance covered by applying SCPA. The system behavior is similar to the one obtained in test 1. In this test, the total distance covered decreases as the number of resources increases. This result is as expected, because the more police patrols that are randomly allocated, the greater is the probability that one of them will be closer to the destination requested by the TMP  In test 1, the number of agencies and resources remain constant. In test 3, in every simulation a new cloned agency is added, consequently, the number of resources are also increased.

C. TEST 3.-STRESS TEST
The objective of this test is to check if the developed system is able to provide a solution in a reasonable response time when a large number of agencies and resources are involved in the negotiation. In this test the time taken to complete a negotiation process and reach a final solution is analyzed. To perform this test, a new agency is cloned from existing ones, and added to the system every new simulation. So, in the last simulation there are more than 100 agencies. This is not a real scenario for this simulated traffic emergency, but it will give an idea of how well the framework will behave in other scenarios where more agencies and resources are involved. Figure 10 shows the comparison of the execution times between the previous test 1 and the current test 3. The results of the simulations of test 1 remain practically constant. These results are expected, since the number of agencies and resources remains constant in each simulation, so the resolution of the negotiation protocol has a similar number of exchanged messages and execution times. However, the results of test 3 show oscillations in the simulations. This situation is also expected, as the number of agencies and their resources increases in each simulation, the time to reach a solution involves an increasing number of messages to be exchanged, as well as the number of complete offers that can be made. Despite this oscillation of results, it is important to note that the execution times for test 3 shows a linear trend. This result indicates that the framework is able to effectively manage a negotiation protocol with a large number of agencies and resources.

VI. CONCLUSION
This paper presents a new framework designed to improve the coordination among the agencies involved in the resolution of a traffic incident according to a TMP. The framework works based on a benevolent approach: 1) each agency involved which has resources available that have been requested participates in the coordination; and 2) each involved agency will deploy its own resources as they appear in the complete solution agreed upon. However, this benevolent approach does not imply that each agency has to publish how many available resources it manages and where they are, which is private information. Some of this information will be made public as the coordination process evolves. Therefore, the involved agencies try to self-optimize their own resources in order to improve their own performances and efficiency in the cooperative search for the best possible total solution.
The framework has been applied to deal with a real accident in a real scenario in a test-bed. The different tests performed show very positive and promising results. It is important to note that in the test-bed discussed in this paper there is just one single negotiation process for all the required resources for all the measures and actions of the active TMP. However, it is often necessary for certain measures and actions to be taken more urgently than others. So, instead of running just one single negotiation process, the framework could also be used to initiate a negotiation for the most urgent resources, and later for the less urgent resources. Nevertheless, the evaluation of the test-bed shows that the resolution time of the negotiation is very low: the mean execution time is around 40 seconds in the stress tests shown previously. This time could be considered significant, but in the traffic domain it is totally acceptable. Therefore, once a complete agreed solution has been calculated the measures and actions can be implemented from more urgent to less urgent ones.
The framework presented is a first attempt to automate the coordination among the involved agencies in a TMP. The framework and the test-bed are fully defined, implemented and the evaluation of its results is very positive, but there is still work to be done in order to improve it. For example, the framework only works when the agencies are able to provide all the TMP required resources and only then, can a complete solution be calculated. So, the interaction protocol for a negotiation aimed at providing a partial solution, when a complete one is not possible, has to be defined, analyzed and developed in future work.