A N ADVANCED PLANNER FOR URBAN FREIGHT DELIVERING

The paper aims at introducing an advanced delivery tour planner to support operators in urban delivery operations through a combined approach which chooses delivery bays and delivery time windows while optimizing the delivery routes. After a literature review on tools for the management and the control of the delivery system implemented for optimizing the usage of on-street delivery bays, a prototypical tour delivery planner is described. The tool allows transport and logistics operators to book the delivery bays and to have real-time suggestions on the delivery tour to follow, through the minimization of the total delivery time. Currently, at development phase, the tool has been tested in a target zone, considering the road network and time/city delivering constraints and real-time data about vehicles location, traffic and delivery bay availability. The tool identifies the possible tours based on the delivery preferences, ranks the possible solutions according to the total route time based on information on the road network (i.e. travel time forecasts), performs a further optimization to reduce the total travel times and presents the user the best alternative along with the indications of which delivery bay to use in each delivery stop. The developed prototype is composed by two main parts: a web application that manages communication between the database and the road network simulation, and, an Android mobile App that supports transport and logistic operators in managing their delivering, pre trip and en route, showing and updating routing based on real-time information.


Introduction
Commercial vehicle traffic in inner city areas is a matter of concern for city authorities (Browne et al., 2007;Lindholm, 2013;Gonzales-Feliu et al., 2014;Russo and Comi, 2016;Szczucka-Lasota, 2017) given that it contributes significantly to traffic congestion, pollutant emissions as well as to road safety (Ljungberg and Gebresenbet, 2004;Russo and Comi, 2017).For example, vehicles stopping on second lane or at junctions for performing deliveries cause a reduction of capacity of road link and intersection with relative increasing of travel time (Cascetta, 2011), stop-and-go phenomena with the increase of travel time (economic impacts; Munuzuri et al., 2013) and pollutant emission (environmental impacts) as well as the increasing of interferences among the road users and of probability of accidents (social impacts).From a different point of view, there is a problem in meeting the needs of truck drivers.In fact, some surveys with transport and logistics operators highlighted that, although different actors have their own needs and perceptions (Marcucci andGatta, 2013, 2016 Galkin, 2017).In the authors' knowledge, few studies have investigated the management and control of delivery bay system and have proposed delivery tour planners exploiting the opportunities offered by collecting "big data" on transport network (Nuzzolo et al., 2015;Anda et al., 2017;Comi et al., 2017).Thus, a first objective of the paper is to identify, from the literature on telematics applied to delivery operations, the areas of further research (Section 2).Subsequently, due to the desirability to have delivery tour planners for supporting operators in urban/metropolitan delivery activity, the second macro-objective of the paper germinates, i.e. to develop an advanced delivery tour planner which provides information on the network in real time connected to the reservation status of delivery bays; thus, operators in defining their tours (i.e.routing and delivery bay reservation) are supported (Section 3).In this context, the paper aims to present a preliminary version of an intelligent transport (IT) system for supporting urban delivery operations.This contribution belongs to a broader project named Dyna-Load (Smart urban freight transport: planning and DYNAmic management of urban LOADing and unloading areas).The project proposed a methodology to support planning, real-time managing and controlling operations for a given on-street loading and unloading (delivery) system.The benefits of such a delivery system can be thus evaluated through a discrete-event simulation as shown in Comi et al. (2017 and2018).The delivery bays were assumed to be regulated with a pre-booking parking system that ensures optimal use of dedicated spaces.The first analysis was performed in terms of maximum possible reduction of total service time with a strong enforcement able to limit the illegal parking (Comi et al., 2017).Starting from these results, Comi et al. (2018) investigated the changes of delivery system performances according to better sizing and location of delivery bays.Therefore, below, the IT part of the delivery tour planner is presented, along with the optimization model, and the developed algorithm.The paper is organized as follows.Section 2 points out the methods and models used to support management and control of urban delivery systems, while Section 3 describes the tool developed for supporting operators in urban operations.Finally, some conclusions and further developments are given in Section 4.

Background
Usually, the contribution of telematics in urban delivering was related to support management and control of delivery bay booking.Examples of management systems are those implemented in Paris (Patier, 2006; SyGAL, French acronym for Delivery Areas Management System), Goteborg (Sweden; TELLUS, 2005), Imola (Italy, Ferrecchi, 2013) and Barcelona (Spain; Nuzzolo et al., 2016).More recently, the opportunities offered by telematics were exploited for improving real-time operations control.Sugar (2011) reports the case of the city of Poitiers (France).Differently, the Smart-Freight project is based on the wireless communications among freight vehicles, freight distribution centers and traffic control system (McLeod and Cherrett, 2011).The system was initially proposed in Winchester and, later, in other cities (e.g.Bilbao, Krakow, Helmond and Lyon) part of the FREILOT project (Pluvinet et al., 2012;Patier et al., 2014).Other cases of on-street delivery bays equipped of intelligent transport system (ITS) can be found in Stuttgart (Germany; Marciani and Cossu, 2001), in Lisbon, (Portugal; STRAIGHTSOL, 2014) and, finally, Vienna (Austria) where the i-Ladezone (intelligent monitoring of loading bays) system was implemented (Chloupek and Zajicek, 2013).Thus, although several cities around the world have implemented IT tools for improving delivering operations, the attention was mainly paid to manage and control delivery bay occupation (Gonzalez-Feliu et al., 2013,2014), showing that further works should be done.In this background, a prototypical tool was developed.It allows sequence of delivery stops to be optimised and relative delivery bays to be booked taking into account the real-time status of the network.Then, tours and booking of delivery bays can be updating real time.Below, the developed tool is described in its main components.

The proposed delivery tour planner
According to literature review and guided by the intention of improving delivery operations within urban areas, a tool to support and optimize the delivery operations was designed and tested.Specifically, the logical architecture of the tool was developed to guide transport operators with personalized pre-trip information on delivery bay availability, booking and tour definition.Therefore, in the following subsections, first the user needs, the logical and functional architectures of the tool are described, then the functioning management and controlling criteria are investigated.Subsequently, the system components, modules and its interfaces including the implemented routing algorithm are presented.

User needs, logical and functional architecture
According to the whole framework of DynaLOAD (Comi et al., 2017), user needs were investigated combining desk and survey research results.In particular, a focus group with delegates from nine local transport operators and a web-based survey of Rome transport operators were carried out.Focus-group meetings allowed us to identify the main problems surrounding goods deliveries in the study area (e.g.illegal occupation, lack of surveillance, and distance from shops).The meetings were discussion-based and were designed to gain insight into how supply chains react to new measures and what effect they have on freight activity.Besides, some indications were used for defining the web-survey.The survey aimed to identify and hence to detail the main parameters and constraints to be used as inputs for the system.Transport and logistics operators were asked about their habits and their preferences in delivery operations.For more details refer to Comi et al. (2018).User needs can be classified according to the pretrip and/or en-route delivery tour.The pre-trip support concerns delivery bay booking and delivery tour alternatives according to the desired delivery time and some tour attributes in relation to real-time road congestion and delivery bay availability according to delivery constraints (i.e.time access constraints).Such attributes can be divided into general and delivery-bay specific.General attributes refer to path as well as to departure time, travel time and cost, expected arrival time at destination (e.g.shop), which are usually used to decide each single leg of the tour.In addition to the above general attributes, delivery-bay attributes detail information for the current and forecasted delivery-bay availability status.The en-route advices refer to the delivery tour attributes updating (both general and delivery-bay) on real-time data from the user current position to the destination.It can also consider the generation of new paths from the current position, if the chosen path becomes unavailable due to unexpected events (e.g.accidents or disruptions) or if there are relevant changes due to traffic conditions or in delivery operations (e.g.heavy delays in previous delivery operations).The overall logical architecture of the trip planner is depicted in Figure 1, along with its main components.These support the pre-trip and en-route information, as well as allow the initialisation of individual user parameters and their updating according to user revealed preferences.The system aims to organize delivery trips, minimizing the total time and considering the arrival time variability and parking slots availability.In details, with reference to a target zone, the tool considers the road network and time/city delivering constraints as well as real-time data about vehicles location, traffic and delivery bays availability (current network status).A pre-trip personalized advice module is enabled by the query of user i, who logs into the system.At time τ in which user i asks for a support to travel from origin to delivery point (e.g.shops), the system identifies and ranks the delivery tours choice set of user i, based on his/her preferences and the current information on the road network (i.e.travel time forecasts and automated vehicle location -AVL -real-time data).Thus, user i is asked to choose.Once, she/he chooses the en-route module supports user in performing such a delivery tour, monitoring this process and eventually asking to revise tour, if necessary.In order to provide the user i with a ranking of alternative delivery tours, in the framework of the random utility theory (Ben-Akiva and Lerman, 1985), personal utility parameters βi of user i are used to calculate delivery tour utility for all delivery tours belonging to the delivery tour choice set of user i.The delivery tour chosen by user i is added to the personal database of revealed preferences of user i, which updates the personal parameters by using a user preference learning procedure, similar to that proposed by Nuzzolo and Comi (2016) for transit travellers (updating).In this regard, the system is designed to have an initialization of such parameters through a stated preference (SP) survey, which proposes alternative delivery scenarios and user is asked to choose the preferred ones (initialization).The information on the delivery tour choice of user i represents the main input of the enroute path information module, aiming at supporting user i during the delivery tour and to be developed in the next step of the research.The functional architecture ensures that an overall status of the target zone is stored in a database recording each small variation.In this way, the system can always access to an instantaneous availability status of the delivery bays.The user who wants to use the tool will first have to register in the system and assign at least one vehicle to his account.After the login (pre-trip), a registered user can update or view personal data and proceed to the tour definition (including the booking of required delivery bays).Furthermore, he/she can access to summary information about the planned routing schedule.The system will let the user choose to manually plan a new visit or to generate an optimized booking plan.Booking operation starts with a pre-trip phase where the user defines her/his delivery tour information (where, what and when) about the delivering/picking operation.The manual plan involves the user in the route scheduling by the choice of delivery bays to be reached and preferred time windows.The automatic plan mode analyses individual parameters, delivery tour information, average travelling times, delivery bays availability and -without any user intervention -presents an optimized routing plan.User can now choose to accept or decline the generated plan.Moreover, the user can choose to be assisted during the delivering tour (en-route), by communicating the system last minute variance so that the system can automatically updated the plan considering the user location and the actual traffic situation.This operation can drastically change the planned route redirecting the user to another scheduled address -different by directly next planned onechanging the previous routing order.Last minute scheduling or variation can be requested -through a specific app -only via smartphone by accessing its geo-localization service.The developed prototype is thus composed by two main parts: the main component is a web application that manages communication between the database and the communication responsible with Google API, in order to solve, in general, routing issues and, at this stage of development, to support the travelling salesman problem (TSP).The second component is a mobile App (for Android devices) that can support transport and logistics operators in managing their delivering, currently pre trip and in the next future, including the en route module.The latter is thus designed to be able to show and update routing in real time on the base of the user location and the traffic congestion, pointing out the potentiality offered by real-time data availability.

Functional policies and controlling criteria
Having designed the architectures of tool, the following phase was the definition of the functional policies, performed through a system state analysis.This analysis was critical considering that, in spite of the booking system, users can arrive later or earlier than scheduled time, due to exogenous causes: when this happens, the system has to determine the access priority rules in order to allow user to perform his/her delivery operation.Note that bays cannot be illegally occupied by vehicles not using the booking system nor being transport or logistics operators.Indeed, the presence of an enforcement policy structure was hypothesized: each delivery bay is equipped with a telematics system that avoids illegal usage.The authorities are immediately informed of any unauthorized occupation of the delivery bay; thus, they are immediately able to intervene and eventually to fine the vehicle.Many different booking logics can be supported, according to specific requirements.The management and control system was developed aiming to guarantee delivery bays availability and discouraging undesirable drivers' behaviours (e.g.double parking).As the driver asks for booking delivery bays she/he has to provide as well as information regarding his scheduled delivery tour (i.e.number and location of deliveries, types of freight delivered at each stop, delivered quantities, time constraints, tour time departure).The system identifies the best set of delivery bays among the available delivery spaces, allowing to optimize the time spent for such operations.The user can also provide an initial preferred delivery tour.Then, if all delivery bays are available, these will be booked with respect to the forecasted timing for performing the given deliveries and the time constraints specified by the user.On the other hand, changes to the delivery order can be suggested.The user can accept or not the suggested changes, and inform the system, so that the actual tour will be pointed out.Specifically, the control system involves a set of rules for dealing with the incoming practical situations.The vehicles are detected on the proximity of the city areas (i.e. they are hence equipped by a bidirectional communication system).The vehicles are hence checked to determine whether they are on time, early or late for their booking.This requires forecasting the times required to reach the first and the following booked delivery bays.The vehicles arriving early for their booking could be immediately processed if the delivery bays are available or they could be asked to wait in a designed area until the bay will be available or to update the sequence of delivery bays to be reached.The vehicles arriving late are allowed to use the remaining time left on their booking (subject to a minimum use requirement) or to extend their booking if the time slots are available.Otherwise, an alternative delivery tour is suggested.

System components and modules
The system was developed as a web Java application, with the support of the Spring framework (https://projects.spring.io/spring-framework/),following the modelviewcontroller (MVC) paradigm (Johnson et al., 2017).This paradigm defines a set of rules for the creation of a dynamic web ap-plication, thus allowing the development of applications with decoupled components able to separate the presentation logic from the business one.The system is divided into three main components (Figure 2): − Model (M), describing the methods and the objects used by the application; − View (V), characterising the "views" with which the user will interact, allowing the visualisation on the screen of model's objects.It is represented by a series of dynamic Java Server Pages (JSP), i.e.HTML files that may contain Java code.The presence of the JSP pages implies the use of a server which is able to interpret the active content of the web pages (e.g. the widespread Server Apache Tomcat); − Controller (C), responding to the requests of the users, modifying the view and the model parts.

Fig. 2. Components of the system
Such multi-tier architecture allows the limited propagation of some modifications in the system, thus supporting its maintenance and portability.The three components are "separated", yet they must interact with each other (Figure 3): − the connection between M and V takes place through the set of the JavaBeans (Java classes that encapsulate different objects into a single object) from the JSP; − the connection between M and i takes place through the set JavaBeans from the Servlet (a Java program that runs on a web server to create web applications); − V and C are decupled and are only connected by http requests.The application uses two different databases (Figure 4): one SQL and one NoSQL.The SQL relational base memorises and makes available all data related to the bookings and will be responsible for the creation of the model part of the system.In the relational database, a further dump table was provided in which, periodically, information on the booking already dealt are gathered aiming to streamline the table that will be interrogated on real-time basis by users.The so-called dump table will be used to estimates the quality of the service provided and the accuracy of the forecasting computed in the planning phase.The NoSQL database will memorise every access, every request, every action carried out to and from the application with their timestamp.
The system extensively uses Google Maps' APIs.The APIs used by the system mainly regard geo-localization of addresses (latitude and longitude starting from the address and vice versa), distances calculation and itinerary times as well as the map visualisation.As for the planning of the routing, the APIs are used within the Java code.As for the visualisation of the map a Javascript ad hoc code has been put directly on the dedicated page.The server will also manage the interactions with the smartphones on which the App has been downloaded.The users will have access to some web services (Google's APIs, database updates, creation of objects).The server will answer to such interactions with JSON (java script object notation, which is a standard text-based format for representing structured data based on Ja-vaScript object syntax).It is commonly used for transmitting data in web applications (e.g.sending some data from the server to the client), which will be later interpreted and re-built on the client side.This way, the app will be light, as all the complexity of calculus will be dealt by the main server.

Tool interfaces
Two different versions of the system were developed, depending on the hardware: desktop or mobile.The main difference consists on user login: the former is thought for a company usage, as there could be a single user planning all the trips for the deliveries, the latter is designed to directly assist the single vehicle during his/her deliveries, setting up the pre-trip delivery tour and booking the delivery bays for performing such operations.The system is hence able to connect the vehicle to the company, that has previously registered it in the system.Basically, the versions differ in the ability of the desktop interface to manage different vehicles before the tours starts, while the mobile interface (Fig. 5) provides a dynamic assistance of the vehicle during their trip thanks to the geo-location and instantaneous traffic information.Besides, the desktop interface could be used for fleet management, while in the future a dispatching module could be included for meeting the last second customers' requests.Although delivery tour definition represents the core part of the presented tool, at this stage of research also taking into account the results of surveys (see section 3.1; e.g.knowledge of deliveries to perform in advance), the system finds the optimal path for serving multiple customers and a travelling salesman problem (TSP) was implemented.However, the choice of this optimal path is constrained by the limitations imposed by the user such as the time windows in which to make deliveries and type of goods.Other binding factors are the availability of parking areas to be used for loading and unloading and their distance from the delivery points to serve.In the next future, the tools is planned to be extended in order to include the opportunity to manage the set of deliveries performed by an user without a preassigned set of deliveries to each vehicle.Usually, a solution for a tour determination problem could also found starting from a pre-defined sequence of deliveries and/or from a set of constraint related to time windows within deliveries to be performed.In these cases, travelling salesman problem (TSP) models could be used and usually heuristics approaches are chosen on large instances, due to the implicit TSP model complexity.Here, on the contrary, the presented tool approaches both the problem of choosing the best timing of the deliveriesalso choosing the delivery bay to be used for each destination, is more than one is availableand at the same time aims at reducing the tour time as much as possible.

Fig. 5. Mobile application
Comi, A., Buttarazzi, B., Schiraldi, M., Innarella, R., Varisco, M., Traini, P., Archives of Transport, 48 (4), 27-40, 2018 35 First, the user is asked to input the list of customers to serve (i.e.delivery addresses) and, optionally, eventual constraints in terms of delivery time window per address; then, the system loads the delivery bays positions and their updated status (reservation schedules).In this way, to each delivery address the system links one or more possible delivery bays along with their available 10-minutes time slots.The possible delivery bays are chosen taking into consideration the walking time to reach the delivery address (compute with Euclidean distance as decision parameter) also on the basis of the type and quantity of goods to be delivered.Indeed, according to the results of a first survey carried with logistic operators to investigate their primary requirements (see section 3.1), the needs to find a delivery bay which can allow to complete the delivery operations within 10 minutes has emerged.With this data in input, the tool builds a data graphthrough an adjacency matrix -where all the nodes are represented by all the possible delivery bays plus the start/end address, and the weights of the links are the travel times, computed based on real-time data (if the tour is to start immediately) or estimated data (if the tour generation is performed in advance, e.g. the day before).Traffic information is obtained thorough a query to Google Maps Api.In the future, a transport travel time forecasting module is developed in order to compute more precise travel times (Lam et al., 2002;Kubek et al., 2017).Clearly, if the user has specified constraints in terms of preferred sequence or time windows per certain deliveries, the generated graph results to be smaller.In any way, computation problems do not represent an issue in this case: because the set of deliveries in the tour is generally small, i.e. less than 10, the problem instances to be solved are quite manageable.For this reason, at this preliminary phase, in developing the algorithm to solve the vehicle routing problem, the complete enumeration of the TSP solutions has been chosen.Indeed, the tool performs the following steps: − the tool generates all the possible tours to complete the deliveries, choosingper each delivery addressthe first available time slot among the possible delivery bays; − then, for each tour the total time is computed, summing travel times, delivery operations times and, clearly, eventual slack times that may be present when a delivery bay is not immediately available once a destination is reached; − at this point, for those tours where a slack time is present on the first delivery, the tool delays the start time to reduce the total tour time; − among all possible tours, the one with short total time is presented to the user.More in details, the algorithm consists of: − objective: provide the best tour (i.e. the sequence, the routes, the delivery timings) that user/operator (i.e.truck driver) must follow to minimize the total tour time; − decision variables: ▪ the order in which the deliveries must be executed; ▪ the delivery bays where to park for each delivery; ▪ the time in which each delivery is performed; ▪ the parking slot time period at each delivery bay; ▪ the path to follow between each delivery bay.

− constraints:
▪ all deliveries in the list must be performed; ▪ deliveries must be performed within time windows eventually pre-defined by the operators; ▪ routes and deliveries must be compliant with eventual access constraint defined by public administration; ▪ delivery bay cannot be farther than a given distance (e.g. 10 minutesreturn trip including delivery operations) from the delivery address; ▪ each parking time slot lasts a maximum time according to the characteristics of deliveries to be performed (in minutes); ▪ no more than one operator can park in the same delivery bay at the same time.If the system cannot find a possible solution, it proposes a plan where one or more constraints are relaxed.The user can accept the alternative plan or not.In this second case, he is asked to manually book each delivery bay.Problem data are the following: − geo-localized addresses (delivery points); − type, weight and constraints of goods per delivery; − eventually pre-defined time windows per delivery; − real-time Google API travel times; − real-time delivery bays status.Algorithm steps, in details, are the following: 1) load the delivery address list per the considered vehicle; 2) generate the adjacency matrix with all delivery bays and travel times; 3) start a backtracking procedure to generate all possible paths: 3.1) generate a path: analyze the first delivery address in the adjacency matrix, select the first available time unit of the list among the possible delivery bays inside the time window (e.g.10:00 -12:00) and select an appropriate number of consecutive time slots (e.g.20 minutes time slot, thus 10:00 -10:20) for the delivery based on the type of goods to be delivered; 3.2) go to the next delivery address, add the travel time to reach the new address (e.g. for a 17minute travel time, we will assume that the operator will reach the following address at 10:20 + 17 minutes, then at 10:37) and select the first time slots depending on the type of goods to be delivered (e.g. 10 minutes time slot, thus 10:40 -10:50); 3.3) repeat previous step until the all the deliveries have been performed; 3.4) add the travel time to the start/end destination; 3.5) analyze first delivery searching for a slack time.If a slack time is present, delay operator departure so that slack time is minimal (i.e. less than 10 minutes) and compute total tour time; 4) once backtracking procedure is completed, all paths are computed along with their total tour time.Thus, choose the solution with the minimum time.

Example of application
Let us consider the problem defined by the three parking areas shown in Figures 6-8.Is it assumed a routing path that reaches three delivery bays following a specific order: Area 1 -> Area 2 -> Area 3. In these tables, every area availability is divided in time slots labeled by column on the left.A red box means that the area is busy in that time slot, instead a green one shows the slot chosen by the scheduling algorithm.Initial state is represented in the left table of Figure 7. Suppose now that all reservations associated to the delivery bays can be committed in a single time slot.The system will then choose the first available slot (10:00 -> 10:10) of Area 1 as starting point (Figure 7).Suppose now that the distances between Areas 1-> 2 and Areas 2-> 3 can be covered in 20 minutes.Without considering that some slots are busy, the system could at first assign to Area 2 the 10:40 -> 10:50 slot.
Fig. 6.Slot parking reservation However, according to this example configuration, the user would be forced to waste 1 hour before finding Area 2 available.Now, note that it is not possible to reach Area 3 before 12:10 without changing the areas routing order.The algorithm will then attempt to compress the temporal slots by considering the time necessary to cover the distance between areas.At the end of the whole process, the system will suggest the schedule represented in Figure 8.

First assessment results
The proposed system was tested in the Campo Marzio district, inner area of Rome where passenger and freight traffic are regulated, with restrictions on both access and parking (Comi andRosati, 2013 and2015).In addition, both in the Campo Marzio and in much of the inner area an electronic system of access control is implemented for both passenger and freight vehicles.An investigation concerning the benefits in using such a system in delivering in the district of Campo Marzio (inner area of Rome) was carried out by Comi et al. (2017Comi et al. ( , 2018) ) and the findings being summarized herein.In particular, Comi et al. ( 2017) assessed an action scenario, which includes a ITS system that provides last minute booking according to the real-time status of the delivery system.Use of the ITS system can contribute to reduce the total delivery time by about 66% and a better distribution of arriving vehicles among the available delivery bays can be obtained, showing a reduction of vehicle requests for a specific delivery area of about 65%.A further assessment was performed in order to investigate the changes of delivery system performances according to better sizing and location of delivery bays (Comi et al., 2018).The simulated scenarios included an IT system that, at this stage of development, provides last minute booking according to the real-time status of the delivery system suggesting different delivery bays according to distance from delivery points.Besides, a potential increase of delivery bays was also considered and hence evaluated.The results of the simulations made for the proposed scenarios show the significance to use such a tool.In fact, the use of a system that provides suggestions (and booking) on which delivery bay to use for performing freight operations can help to reduce total delivery time by about 28%.Besides, the simulation showed that the current delivery bay locations of Campo Marzio is not optimal given that there are some delivery bays highly congested and some of them are quite empty, as shown also from the comparison between the total available and required service times.the base scenario, the maximum number of vehicle servable were 259 with averagely 11.26 vehicles for delivery bay.But due to long waiting time, about the 38% of vehicles performed operations out of dedicated spaces.Subsequently some reorganization actions were supposed and assessed (e.g.increasing of enforcement and of number of delivery bays).The obtained results suggest a better use of parking resources avoiding illegal operations, i.e. an increase of 3 delivery bays pushes to an increase of 73% of vehicle served and a better usage of delivery spaces (+37% of vehicles per bays).

Conclusions
The paper presented some results of a research aiming at developing a software tool able to support transport and logistics operators in delivering in urban area through booking delivery bays and delivery tour support.Personalized information is provided to users by real-time data.The tool is part of a broader research project involving planning delivery scenarios and managing and controlling urban onstreet delivery bays.Specifically, the delivery system was supported by a prototypical tool for bay booking and tour planning.The tool allows users to book delivery bays in advance according to the characteristics of their delivery trip in order to perform efficient delivery operations.This tool can represent an effective support both to transport and logistics operators and city administrators.Transport and logistics operators can thus further reduce the time spent for delivery operations as well as their operating costs.City administrators can reduce urban goods traffic impacts and, therefore improve city sustainability and livability.Further developments of this research are in progress.They mainly regard the additional investigation of the learning process (state preference design and quicker up-dating procedure) and that of the enroute personalized information as well as to implement an advanced routing and scheduling procedure that allows user to optimize their whole plan of delivering.
Moreover, due to this satisfactory results, the tool is currently under evaluation for a practical implementation in Rome municipality.Further research would include results on real test cases, to point out the average time and costs gains from its adoption.

Fig. 4 .
Fig. 4. Structure of the databases Vehicle routing problem aims to minimize the transportation costs by a given set of vehicles (fleet) moving from a warehouse.It is thus considered the core of freight distribution management and it is one of the most famous combinatorial optimization problem.A large literature exists which varies from solutions optimizing delivery sequences to solutions that incorporate time windows (i.e.time when customers have to be served) and characteristics of vehicle fleet (among the others, Dantzig and Ramser, 1959; Ghiani et al., 2003; Eksioglu, 2009; Laporte, 2009; Hoff et al., 2010; Qureshi et al., 2014; Toth and Vigo, 2014; Musolino et al., 2016; Cattaruzza et al., 2016; Erdoğan, 2017; Musolino et al., 2019).