e2Call a TLC point of view



In 2017 (EU-Council, 2014), countries defined as “pilots” in the HeEro European project will oblige car makers to install, on new brand vehicles, an electronic safety system automatically calling emergency services in case of a serious accident (EU-Commission, Press releases database, 2011). The idea is to manage the car sensors and the processor of the On Board Unit (OBU) to assemble an enhanced eCall that feeds an inference engine to give an interpretation of the accident dynamics to provide more accurate rescues. Using 4G network, cars will also share information about their positions and routes for advanced driver assistance systems based on an on board data processing to avoid collisions. Cars themselves could be used as moving sensors to determine dangerous road conditions and traffic congestion. The research is partially founded by The Autonomous Province of Trento government and developed in collaboration with CRF (Fiat automotive research centre) and Department of Information Engineering and Computer Science of University of Trento.


eCall Standard directive

The OBU, in case of air bag activation, dials 112 European emergency number automatically and at the same time sends a minimum set of the vehicle-state/location data to the emergency centers to get  a prompt  assistance to people involved in the accident. This set is defined Minimum Set of Data (MSD) and contains an Header message type + version, Status source, Cargo type, Identifier MSID (I MEI, IMSI or MSISDN), Latitude WGS84 in degrees, Longitude WGS84 in degrees, Velocity km/h, Direction degrees and a Checksum CRC-8 (Various, 2009). In eCall description is also provided a manual-forced way for activation and a connection backup/retry policy. eCall is regulated by both standard definitions (HeERO, 2014) and EU directives, proposals or recommendations (EU-Commission, eCall: Time saved = lives saved).

The e2Call extended concept

The target of the research is to investigate how to extend eCall, improving road safety, and to offer an higher level vision of traffic network and related events. In our opinion the target could be reached by means of the analysis of the extended data set exposed by OBUs on the market today (such as lateral/longitudinal acceleration; Longitudes, latitude; Velocity, rpm, total distance travelled; Steering angle position; Direction, altitude, velocity via GPS; ASR, ELD, ESC, ABS, FPS, TC, CMM activated; Airbags activation; Yaw rate; Fasten seatbelts; Vehicle Identification Number-VIN; Wheel pressure/temperature; External temperature; Bonnet, trunk, doors open; CMM on/off; Fuel level, fuel in use for double-fuel vehicles) and of extra-vehicle information available like weather forecast, traffic conditions, police broadcasted messages and so on. Also using a dedicated SIM card into the OBU for vehicle connection to transmission network, accurate geo-localization and on-board devices (tablets, smartphones or integrated components) to display information. It will also necessary design an integrated end-to-end software solution able to receive all contributions listed above for improving standard eCall both from vehicle and Public-safety answering point (PSAP) (EU-Parlamient, 2013) points of view.

e2Call in a nutshell

Automatically alerting rescues services in case of car accident is a great improvement in cars safety world. On another hand, if the passengers are unconscious (and, often, it means that the accident is very serious), the PSAP operator receiving the call is only informed about car position and that something happened causing air bag intervention. Collecting car’s sensor data and sending them with a short time history of the evolution (i.e. last 10-20 seconds), an inference engine, based on a knowledge base, improved with experience, can formulate an hypothesis on accident mechanics and consequences. I.e. data coming from vehicle speed sensor, throttle position sensor and ABS intervention sensor can be combined to estimate the type of accident and, in case of internal thermal sensors availability, the quick growth of temperature can suggest the presence of fire. The elementary information collected are sent via e2Call in addition to the minimum set defined in eCall MSD and elaborated by inference engine to assist PSAP operator in evaluating accident consequences. Cars are identified via vehicle identification number (VIN), so if dangerous fuel is used (like LPG) an active alarm can be sent to vehicles travelling in the accident surroundings (RSIS feature). Identity of passengers on car during the accident can be sent also reading (via smartphone camera) their ID on the innovative Trentino Sanitary Card (PAT) when boarding the car. So, the PSAP operator is informed about specific passengers sanitary needs recorded in Trentino on line Medical History TreC (PAT-FBK-APSS, 2014) and appropriate rescues could be dispatched. The initial accidents knowledge base is based on public available data reporting accidents, boundary conditions, car sensors values (if available) and accident consequences but a checking procedure to confront inference engine results with real accident causes and consequences will improve system experience in order to have better guessing in the following iterations.

Virtual Sensors

The new technical evolution of vehicles on board sensors allows to capture, in addition to basic information about the performance, the status of active and passive safety systems and the surrounding environmental conditions. We propose to build a level of standardization and normalization of information that helps to acquire the data provided by the sensors independently of the car maker that assemble them. This is done by using the concept of virtual sensor, as a mapping between the “real” events acquired from physical sensors implemented by the car maker and the macro phenomenon described by the virtual sensor. This sensor may be associated with one or more physical sensors, and will be the EDR input element for the processing performed by the inference algorithms described below. The use of virtual sensors will also allow the creation of a collaborative database where event reports will contribute to improve inference engine results.

The e2Call Inference engine

The e2Call services will rely on so-called knowledge discovery and pattern mining algorithms (Kumar-Tan-Steinbach, 2005). The application of such algorithms has an exploratory nature and we expect them to lead us to the discovery of useful knowledge for the purposes of e2Call. All data that describe the behavior of vehicles (e.g., EDR data remapped by  the virtual sensors) in the case of an accident as well as all data related to the context of the accident (e.g., weather and traffic conditions) can serve as an input for our algorithms. The main task we aim to achieve with these algorithms is to look into historical data containing both vehicular and extra-vehicular for deriving models that help in predicting different possible outcomes of an accident. The types of predictions can be supported by so-called classification algorithms (Mitchel, 1997). We propose to use decision tree learning. Decision tree learning are well fitted for instances that are represented as attribute-value pairs, when the input data may contain errors and missing attribute values and the target function (class attribute) has discrete output values. In addition, they are simple and fast in classifying unseen examples, and they are considered appropriate for knowledge discovery as they do not rely on parameter settings or domain knowledge (Han-Kamber, 2006).  This characteristics make decision tree learning a good choice for our input dataset and predictions we want to make. The predictions made by the classification algorithm described in the previous section are used as an indication of the types of emergency services that need to be activated in order to manage the accident. The realization of the e2Call infrastructure calls for a number of key components that need to jointly work together in order to identify patterns of incidents. The components collect data in the form of events, process each event and populate a Data warehouse. The Pattern mining algorithms identify patterns in the data and build diagnostic models that will be later on used for diagnostic of car crash events. Such diagnosis is forwarded to the Emergency Cockpit so that the PSAP operator can analyze the results and take the appropriate actions to manage the emergency situation.  Besides the visualization of the event classifier, the emergency cockpit can be also used to visualize plain, fact data as contained in the car crash event (EDR data), including, for example, the speed and acceleration of the vehicle during the last 5 seconds previous to the actual crash. The collaborative DB model contains information about accidents and introduce the key concepts of e2Call as presented in Figure 1.  This model can be read starting from the Vehicle entity. A vehicle is typically boarded by one or more Persons of whom one of them acts as the driver. A vehicle that is transiting a road is typically associated with a Context such as the Location, and the Weather and Traffic conditions that characterize such location. A vehicle may be subject to the event of a crash, which is represented by the Accident entity, that typically involves the persons boarding the vehicle(s) and is associated to a location where the event took place.  In this context, the event of an accident should cause the triggering of an eCall that establishes a voice link with an Emergency Operator and, in parallel, sends him the Vehicle Data related to the event. The voice link is used by the emergency operator to try to talk with the persons boarding the vehicle(s) in order to get details about the accident, while the vehicle data is used both to enrich the understanding of the operator about the event and predict a Classification of the accident. Thus, the emergency operator is the agent in charge of managing the accident, and decides on the Actions to be performed and the authorities (Police, Firefighters and Paramedics) to be involved for the assistance services. When the emergency has been addressed, a Report with the details of the accident is filled in by the emergency operator and the authorities involved in the management of the accident and inference engine results evaluated to improve system experience. It has been shown that the dataset size affects the size and complexity of the learned tree, and that the resulting trees built with 100% of the  instances in dataset are not more accurate than the trees obtained with a randomly selected, smaller subset of instances (Oates-Jensen, 1997). The determination of the size of the dataset at which the accuracy reaches its maximum value is in turn a learning process that strongly depends on the characteristics of the data in dataset and it should be therefore determined empirically.


Figure 1 e2Call conceptual model.


Road Safety Information Service

The goals of Road Safety Information Service  (RSIS) are to collect data by car sensors and by other source of data, to analyze them and thus to elaborate information services to be provided in real time to vehicle drivers to improve the road safety. The vehicles, in this scenario, represent “sensors on the roads”. Compared to other traditional monitoring tools (e.g. cameras, patrols, road-side sensors), the added value in being able to use the increased allocation of sensors on modern vehicles is the ubiquity of monitoring which also extends into roads where the deployment of sensors and other instruments would be onerous. External traditional sources of data, such as weather, police and traffic info, are still integrated to compose a complete analysis of traffic situation. Cars are able to record events in real-time on the roads, such as activation of ABS devices, ANTI SKID, etc. These events are sent automatically anonymously to RSIS in order to generate an event of type “almost collision”. The collection of these data, related to the moment and to the place in which they are recorded, are analyzed in RSIS that can create an updated picture of the recorded events and the suspected hazards in the road network and stores their evolution over time, thus creating a historical database. It will allow to highlight statistical anomalies and danger zones. Such information will be usefully shared to drivers of vehicles that are approaching to danger zones. Also road maintenance offices can benefit from RSIS information in order to understand road conditions in critical weather situations and quality of active/passive road signs (i.e. traffic lights, speed limits). Key concepts for this analysis are the geolocation of events compared to the directions of cars. The architecture of RSIS consists first of all of a set of components for the collection and storage of both vehicular and extra-vehicular data. The components collect data in the form of events from cars, meteo and traffic, process each event by an Extract-Transform-Load (ETL) and populate a Data warehouse. The Pattern mining algorithms uses the data stored in the data warehouse to compute patterns of normal behavior on the road segments. The models that result from the mining algorithms are stored back into the data warehouse for future use in the outlier detection phase. The Event listener collects events coming from the bus and are stored into the Staging area. Such events are temporarily collected there in order detect outliers through the Outlier detector. Whenever an abnormal behavior is detected by the Outlier detector, an alarm is raised and forwarded to a Telco gateway, which is in charge of notifying cars about the potential risks of driving through the segment(s) associated with the alarm.


Figure 2 RSIS diagnostic infrastructure.

Figure 2 RSIS diagnostic infrastructure.


The bottom part of the architecture presented in  Figure 2 shows one of the key features of RSIS: the notification of risky driving conditions. Such notifications are created based on the patterns that represent normal driving behavior for the different road segments covered by RSIS. Whenever a number of vehicles successively send EDR records where the parameters in it indicate a deviation from the average behavior for the road segment, such situation should be taken into account in order to identify whether the road segment being transited by these vehicles present a risky condition that can eventually lead to an accident. For instance, a car may send a EDR record in which the parameter that indicates the activation of the ABS system is on for a given road segment. If other cars transiting the same road segment successively indicate the same situation, then it may be an indication that there is something wrong with the road surface such as icy conditions, presence of oil wastes, uneven surface due to deterioration of the road, etc. The first part in identifying risky situations consist in first learning the patterns of normal or average behavior of the road segments. It can be done with the help of standard statistical and machine learning techniques such as the Grubb’s test and unsupervised clustering (e.g., K-means). Once the normal behavior has been identified, new records coming from the vehicles are compared against the patterns in order to tag them as normal or abnormal. Whenever a given number (threshold) of cars reported a deviation from the normal behavior, a notification is created in order to send a warning to all cars transiting the road segment or approaching it. Such notifications are either accepted or rejected by the car’s OBU based on the location of the vehicle and the driving direction. The key concepts we work with in RSIS as presented in Figure 3. We start the description of this model with the Vehicle entity that transits a RoadSegement, which lies in a given Location and belongs to a Road. A RoadSegment is characterized by an Average behavior of the vehicles that transit them. This behavior is computed through pattern mining algorithms on the EDR data produced by cars. From the EDR data and the computed average behavior in a RoadSegment, we can compute outliers that represent a deviation of the behavior of cars from what is considered as “normal”. Such deviations are represented by the Outlier event entity and it can be of two types Near miss and Accident. Whenever an Outlier event is detected, an Alert is raised that is identified from the outlier and EDR event. Such alert is associated with three entities, namely, the Context, the Cause and the Risk/Danger. The Context entity represents the Traffic and Weather conditions associated to the alert, the Cause entity represents the identified conditions that have raised the alert, and finally, the Risk/Danger is a numeric or categorical indicator of the potential risks and danger associated with the alert.

Figure 3 RSIS conceptual model.

Figure 3 RSIS conceptual model.

The RSIS data model is used not only to store historical data about vehicle behavior and driving conditions in the various road segments but will also support the statistical analysis of this data in order to identify patterns and detect situations that deviate from them.

ADAS Services

Analyzing the data on the frequency and type of traffic accidents (Carter-Naing-Simon-Hermitte, 2009), almost half of the accidents happen in urban intersections mainly due to four factors: high amount of traffic, density of vulnerable road users such as pedestrians and cyclists, high concentration of intersections, reduced visibility caused by the presence of narrow streets and buildings close together. In e2Call a system on board, Advanced Driver Assistance System (ADAS), allows to know the vehicles position along the road infrastructure and evaluate the space-time distance between the vehicles incoming in a specific area in order to highlight in advance the hazards along the way. It also suggests corrective actions to the car drivers. To perform the task is essential to know position of the vehicles and road geometry in very precise way. In our trials our partner CRF is using NAVSTAR GPS, corrected with precision systems based on Satellite-Based Augmentation System (SBAS), Ground-Based Augmentation System (GBAS) and highly detailed digital maps dedicated to ADAS applications. The use of e2Call infrastructure and 4g network e2Call feature that allows contiguous vehicles communication makes possible to hypnotize a solution that  lowers the costs of implementation accepting the challenge of maintain the low latency (<100ms) required by the ADAS service.

The 4G Network

When discussing on Dedicated Short-Range Communications (DSRC), the IEEE 802.11p protocol, defined as an extension of 802.11standard family, is deemed one of the most suitable technology to add Wireless Access in Vehicular Environments (WAVE), aiming at supporting car-to-car communications especially for applications requiring low communication latency and high reliability.Even if 802.11p specifically born for proximity communications, its ad-hoc nature entails some drawbacks, potentially critical for certain car-to-car scenarios. One of the key problems identified for the use of 802.11p in vehicular networks is its low scalability (Koucheryavy-Campolo-Vinel-Molinaro, 2011). The protocol performs well under normal traffic circumstances, with very low end-to-end delays due to direct communication between transmitter and receiver, hence avoiding going through network infrastructure. On the other hand, it is not able to provide the required characteristics in high traffic condition, where the system suffers lack of capacity needed to handle the high number of “users”. The main motivation lies in the distributed medium access control scheme adopted for WLAN 802.11 technology, based on CSMA (Carrier Sense Multiple Access). The interference generation, the fluctuant and potentially high delay and the limited capacity can lead to sever performance degradation, not tolerable for many car-to-car communications. The unpredictable delay on different network load condition can be ascribed to the absence of a “coordination node”, able to manage the access of users to the medium. On the other hand, this is the peculiar characteristic of a cellular mobile network, where there are nodes in charge of similar tasks, e.g. the eNB in the new LTE system. From such a consideration, the infrastructure approach can be exploited as a possible communication basis for vehicle communications. In the infrastructure based approach the beacon transmitted by the vehicles are not sent directly to the other vehicles, although to the network node through uplink, and the network node will be in charge to broadcast the information, after proper processing (if needed), through downlink to the other vehicles in the proximity of the relevant transmitters. The beacons can be seen at the same way of others types of traffic which are transmitted in cellular network and, therefore, by means of a proper resource scheduling (located in the node) all the packets related to a certain location can experience similar delays, closed to the mean value. As a consequence, the beacons collision is avoided and the communication can be guaranteed also in high traffic load scenario, hence enabling the service scalability. However, it should be stressed that in case of low traffic a wireless protocol like 802.11p is able to ensure lower delays with respect to a network architecture approach. Nevertheless, the new 3GPP LTE (Long Term Evolution) mobile system has been specified taking into account tight requirements on end-to-end delays that typically can suite the WAVE type communications. The more effective resource allocation and medium access control of mobile radio network also bring to a better capacity performance, since a greater number of users can be managed than 802.11p. Some details and simulation results on technical comparison between 802.11p and LTE can be found in the thesis work (Trichias, 2011). With respect to the coverage of the system, since the range of 802.11p is typically in the order of hundred meters, beaconing itself provides awareness about the vehicles in the vicinity. On the contrary, in an infrastructure architecture there is no direct communication and, hence, the concept of proximity has to be carefully handled with the area where the node decides to forward the relevant information. Among cellular mobile network, LTE can play a main role, thanks to its low delay and high capacity capabilities. The LTE technology, defined as E-UTRA (Evolved-UTRA), has been standardized in 3GPP starting from Release 8 (SÉBIRE, 2010). New radio access network (E-UTRAN) based on OFDM and new packet core network (EPC, Evolved Packet Core) was specified, in order to satisfy tight requirements on delay, data rate, spectral efficiency, mobility, power consumption, etc. (NAKAMURA, 2009). The new E-UTRAN access has been defined with the goal to provide to the users an “always-on” packed based service, where each camped terminal has already at least one IP address assigned. The access network of LTE is characterized by a flat architecture, i.e. consisting only of network nodes (eNodeB) directly connected to the core network nodes (Mobility Management Entity (MME) / Serving Gateway (S-GW) ), avoiding a centralized node (like the controller RNC in UMTS system), which functionalities have been split between the eNodeB and the core network nodes. This new architecture is essential to ensure reduced end-to-end delay, as per related control plane and user plane requirements. Moreover, the exchange of load information between eNodeBs, accomplished through a specific logic interface, is of key importance in the flat architecture used in LTE and enables load balancing algorithms useful to maximize the overall system capacity. Another key characteristic of the LTE system is the introduction of spectrum flexibility, allowing LTE to operate in frequency carriers from 1.25 MHz to 20 MHz (a.k.a. scalable bandwidth) and several different frequency bands, so far from 700 MHz to 2.6 GHz (SKOLD, 2014) e.g. 800, 1800 and 2600MHz for main Europe areas. The possibility to operate up to 20 MHz bandwidth, together with other techniques like Higher Order Modulation (64 QAM) and multiple antennas at both the eNB and the mobile terminal (MIMO, Multiple Input Multiple Output) allows supporting significant increment of the peak throughput. In particular, for the Release 8 of the standard, LTE is able to reach the theoretical throughput of 300 Mbps in downlink with MIMO 4×4 configuration and the maximum bandwidth of 20 MHz, which scale to 150 Mbps for more realistic MIMO 2×2 (LTE basic).  With respect to the coverage, the new LTE system has been optimized for ensuring peak throughput, spectral efficiency and mobility requirements for 5 km cells, with slight degradation for 30 km cells. In particular, in current deployments the cell range can vary from 200 meters in urban environment up to some kilometers for suburban and rural case.  The support of ADAS services through network infrastructure can be feasible whether it is possible to guarantee the requirements of such types of applications, especially regarding the amount of data to be transmitted and the end to end latency. In particular, for the e2Call project packets with size of 1 Kb transmitted with up to 10 Hz frequency have been considered. The latency requirement, referred to the end to end delay from the packet ready to be transmitted and the same available at the receiver, has been set to maximum 100 ms. Due to the high capacity offered by LTE system, the handling of such amount of data should be feasible, and also the required latency should be correctly satisfied through LTE capabilities. When the infrastructure based approach is considered, the transmission among vehicles should be accomplished by means of a proper architecture. From the terminal side, i.e. the vehicle, the transmission and the reception are performed like a traditional service. From the network side, the reception of a packet has to be followed by a point-to-multipoint transmission, in order to transmit the relevant information to the other vehicle in the proximity area. The effective way the network has to close the proximity communication is by exploiting broadcast functionality. Broadcasting is already specified in 3GPP LTE standard from Release 10 as eMBMS (evolved Multimedia Broadcast Multicast Service), the evolution of MBSM standardized in previous LTE releases and systems. The network could hence broadcast the received information to a specific MBSFN (Multimedia Broadcast Single Frequency Network) area, defined as an area of eNodeBs from which the same eMBMS content can be synchronously transmitted, representing the proximity area of the communicating vehicles. However, such features are not yet made available today by vendors, even if planned in their own implementation roadmap. It follows that at the moment other solutions shall be investigated, based on the traditional types of communication currently available and deployed in the mobile network and, in particular, on LTE technology. A basic approach to make few vehicles communicate each other through the network could be based on the IP address that each LTE terminal shall acquire when connected to the LTE network. The network can in fact act as a router to redirect the messages received from specific IP addresses to other well-known IP addresses associated with the in-proximity vehicle. In order to perform this routing functionality, a dedicated server can be connected to the core network node in control of the involved eNodeB(s). Such a server could be provided of static and public IP address made known to the vehicles operating in the communication service concept. The LTE cards on-board of each vehicle acquire their IP address during network attachment and such IP addresses list is made available to the routing server, e.g. offline, or by means of web interface, or also dynamically through a specific application, etc. When an involved vehicle has something to communicate to the vehicles in its proximity, the related packets are sent to the IP address of the routing server. When the routing server receives the packets, it forwards such a stream towards all the other IP address it has in its own list, representing all the vehicles attached to the service in the desired location as depicted in Figure 4.

Figure 4 - IP Packets Broadcast

Figure 4 – IP Packets Broadcast

The concept of proximity area needs to be carefully evaluated in order to limit, as far as possible, the exchange of messages within an area containing the only vehicles potentially interested to the transmitted information, hence avoiding overcharging the in-vehicle processing. If cellular mobile network is used the extension of the area depends on the architectural choice deriving by the specific deployment carried out by the mobile operator. In particular, current mobile networks deployments are based on a Location Area (LA) concept, already used today by the network to send in broadcast control messages to the terminals. The extension of a LA can vary from a cell (ranging from hundreds meters of urban environment to some kilometers of suburban and rural environment) up to the aggregate of several cells (e.g. the mobile radio coverage of a whole city). The choice in the dimension follows specific network planning roles, designed to balance the granularity of territorial location (typical driver for small areas) with respect to the amount of signaling generated by terminals crossing different areas (typical driver for big areas).

The simplest way to reduce the proximity area is hence on a per cell basis, but future solutions could also provide the possibility of using “geo-routing” algorithms, in order to achieve a geographical filtering of the information at the network level so to avoid the broadcast of useless information to vehicles located in other areas. It should be stressed that all the above consideration shall take into account that LTE network is a mobile network, specified to optimize the user experience of traditional network to UE services and vice versa, and not to design a safety network. So, as resilience of system is required, it should be reached via institutional investments.




The key points of e2Call concept are:

  • The inference mechanism that connects data coming from OBU and other sources to give a suggestion to the rescue operator. This kind of information can allow a more effective assistance especially if passengers on board have been previously identified and some special medical help is required.
  • The use of cars as probes to patrol roads practicability, possible traffic signs inadequacy, traffic and weather conditions.

The study about the possibility to use an already large band deployed network (like 4G) in order to manage cars communications and signaling.

Network connected cars can improve safety, car traffic events management and services deployment to customers. Already now, the Italian Courts are accepting events logged by OBUs as valid witnessing in judicial proceedings related to accidents. May be that in the future, drivers with inappropriate behaviors will be automatically monitored and persecuted by Police. In connected cars, drivers and passengers will be constantly informed about the real performances of the road that they are crossing. The information will be  based on an analysis of surrounding weather conditions, temperature, icy surface, incoming intersections and other dangerous conformations of the route. The traffic signs, traffic lights, centrally managed, will reflect the real time situation and not the theoretic decision made when the road was built. The availability of a large band network, on geo localized cars, will allow the delivery of contents related to the travel, special offers and touristic information, improving the interaction between the territory crossed by the roads with great advantages for travelers and new opportunities for merchants and services firms.


  1. Carter-Naing-Simon-Hermitte, M. (2009). Accident causation and pre-accidental driving situations. Trace Project.
  2. EU-Commission. (2011, 09 08). Press releases database. Retrieved 03 2014, from European Union Official Site: http://europa.eu/rapid/press-release_IP-11-1010_en.htm
  3. EU-Commission. (n.d.). eCall: Time saved = lives saved. Retrieved from Digital Agenda for Europe: http://ec.europa.eu/digital-agenda/en/ecall-time-saved-lives-saved
  4. EU-Council. (2014, 03 19). Life-saving eCall system agreed by the Council and European Parliament. Retrieved 08 04, 2014, from Council of the European Union: http://www.consilium.europa.eu/uedocs/cms_data/docs/pressdata/en/trans/141639.pdf
  5. EU-Parlamient. (2013, 06 13). Legislative Observatory. Retrieved 03 2014, 31, from European Parliament: http://www.europarl.europa.eu/registre/docs_autres_institutions/commission_europeenne/com/2013/0315/COM_COM%282013%290315_EN.pdf
  6. Han-Kamber. (2006). Data Mining: Concepts and Techniques 2nd edition. Morgan Kaufmann.
  7. HeERO. (2014). List of eCall standards. Retrieved 03 27, 2014, from HeERO: http://www.heero-pilot.eu/ressource/static/files/ecall_table_of_standards.pdf
  8. Koucheryavy-Campolo-Vinel-Molinaro. (2011). Modeling broadcasting in IEEE 802.11p/WAVE vehicular networks. IEEE Commun. Lett.
  9. Kumar-Tan-Steinbach. (2005). Introduction to Data Mining – 1st. edition. Addison-Wesley.
  10. Mitchel. (1997). Machine Learning. 1st. edition. McGraw-Hill.
  11. NAKAMURA, T. (2009). Requirements for Evolved UTRA (E-UTRA) and Evolved UTRAN (E-UTRAN). 3GPP.
  12. Oates-Jensen. (1997). Machine Learning: Proceedings of the Fourteenth International Conference. In Oates-Jensen, The Effects of Training Set Size on Decision Tree Complexity (pp. 254-262). Morgan Kaufmann.
  13. PAT. (n.d.). Documentazione. Retrieved 3 2014, 31, from PAT Carta dei Servizi: http://www.cartaservizi.provincia.tn.it/documenti/pagina6.html
  14. PAT-FBK-APSS. (2014). Il Progetto. Retrieved 04 02, 2014, from TreC cartella Clinica del Cittadino: https://trec.trentinosalute.net/web/guest/il-progetto
  15. SÉBIRE, B. (2010). Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2. 3GPP.
  16. SKOLD, J. (2014). 3GPP TS 36.104, “Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station (BS) radio transmission and reception”. 3GPP.
  17. Trichias, K. (2011). Modeling and Evaluation of LTE in Intelligent Transportation Systems. University of Twente.
  18. Various. (2009). CEN/TS 15722 “Road transport and traffic telematics – eSafety – ECall minimum set of data (MSD)”. UNI.

Gianraffaele Percannella (TimLab, Italy) with Foches R., Fodrini M., Gasperi T., Gatti F., Giorgianni R. (TimLab, Italy), Daniel F., Rodriguez C. (Department of Information Engineering and Computer Science University Trento) and presented at 10th ERTICO ITS European Congress. Helsinki 2014.