Prediction of a quality of service parameter for a telecommunications network

Abstract

The invention relates to a method for predicting a quality of service (QoS) parameter of a telecommunications network capable of carrying vehicular application data. The method comprises, for at least one position or zone within the radio coverage area of ​​the telecommunications network and for at least one prediction horizon: - obtaining M measured values ​​of the quality of service parameter for said position or zone, where M is an integer greater than or equal to 1; - determining (302) a predicted value of the quality of service parameter, for the prediction horizon and for the position or zone, by applying a prediction model to input data comprising a position or zone identifier, at least one prediction horizon, and the M measured values ​​of the quality of service parameter. Fig. 3

Description

Title of the invention: Prediction of a quality of service parameter of a telecommunications network. Field of the invention

[0001] The field of the invention is that of the prediction of quality of service, QoS, parameters of a telecommunications network, in particular for the adaptation of the implementation of vehicular applications based on Vehicle-to-Everything, V2X communications. Previous art

[0002] V2X communications are now key to the operation of modern motor vehicles. These communications allow vehicles equipped with a V2X interface to communicate with each other, with road infrastructure, and with pedestrians, resulting in improved road safety, better traffic efficiency, and an enhanced overall experience for drivers and passengers.

[0003] Two wireless communication technologies dominate in V2X communications: - DSRC technology, for "Dedicated Short-Range Communication", which is based on the IEEE 802.1 IP standard; and - Cellular V2X technology, or C-V2X for "Cellular-V2X" in English, using cellular telecommunications networks associated with 4G and 5G technologies.

[0004] DSRC technology is a short-range wireless communication technology specifically designed for vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications. It operates in the 5.9 GHz frequency band. It enables vehicles to communicate with each other and with surrounding road infrastructure, facilitating the exchange of real-time information that can be used by vehicle functions, thereby improving road safety and traffic performance. DSRC applications include accident prevention systems, traffic alerts, congestion management systems, and other features aimed at increasing the efficiency and safety of the road network.

[0005] DSRC technology offers advantages such as minimal latency and direct connections, ideal for real-time information exchange between vehicles and their environment.

[0006] On the other hand, C-V2X technology offers a wider range and the ability to handle larger volumes of data, but at the expense of slightly higher latencies.

[0007] In addition to latency and range criteria, C-V2X and DSRC technologies can be compared according to the following additional criteria: - Regarding their scalability: as mentioned, C-V2X uses 4G and 5G cellular networks to establish connections, offering high capacity and scalability to increasingly advanced networks as they develop. This is not the case with DSRC technology, which is based on a dedicated frequency band, thus limiting its scalability; - Regarding their interoperability: C-V2X technology, being standardized by organizations such as the "3rd Generation Partnership Project", 3GPP, benefits from broad interoperability between different manufacturers and infrastructures. On the other hand, although widely used in early V2X applications, DSRC technology has encountered challenges in terms of interoperability, which may limit its widespread adoption; - Regarding their use for advanced applications: C-V2X technology offers greater flexibility and processing capacity compared to DSRC technology, thanks to the use of cellular networks. This enables more advanced applications, such as real-time traffic updates, sophisticated safety alerts, and communications with cloud-based services. While effective for basic applications, DSRC technology may have limitations when it comes to processing large volumes of data or managing complex applications.

[0008] Vehicular applications are inherently responsive and require higher QoS parameter criteria than conventional consumer user requirements. These criteria ensure reliable and secure communications within the V2X ecosystem.

[0009] Predictive QoS, or P-QoS for "Predictive Quality of Service," theoretically allows for anticipating cellular network connectivity capacity, thus enabling C-V2X applications, such as automated driving or intelligent traffic management systems, to calculate and adjust their operating mode in advance to guarantee the continuous safety and availability of these applications. Specifications from the 3GPP organization define QoS parameters and thresholds to be met to ensure QoS adapted to the requirements of vehicular applications.

[0010] The spatiotemporal dynamics of cellular networks and vehicle mobility can lead to sudden changes in QoS parameters. An abrupt adjustment of the vehicle application, especially due to a degradation of QoS parameters, can inappropriately affect performance V2X vehicular applications, causing service discontinuity or traffic inefficiency.

[0011] In order to be able to anticipate such variations in QoS parameters, the 3GPP organization proposed, in the technical specification 3GPP TS 23.288, version 17.4.0 Release 17, of May 2022, in section 6.9, a mechanism for prior notification of the predicted QoS, called "QoS Sustainability".

[0012] Such a mechanism relies on predicting an expected change in QoS parameters. Sudden QoS changes can thus be avoided or mitigated by informing the application servers in charge of V2X vehicular applications of the connectivity parameters and impending QoS changes in order to maintain the security and efficiency of the V2X applications.

[0013] The document “Technical Report on Predictive QoS and V2X Service Adaptation”, 5GAA, October 2022, identified several use cases benefiting from QoS parameter prediction notifications, including remote-controlled driving, remote-controlled support, automated intersection crossing, cooperative lane merging, coordinated driving maneuvers, intersection movement assistance, high-density platooning, emergency braking warning, lane change warning, user attention confirmation, left turn assistance in the face of cross traffic, cooperative side parking, software update, and high-definition mapping.

[0014] The aforementioned document introduces a network architecture comprising several entities, for the implementation of predictive QoS.

[0015] Such an architecture comprises: - V2X application servers, denoted AS for "Application Server" in English, which act as application functions, denoted AF for "Application Function" in English, and whose role is to request QoS parameter prediction notifications; - a network exposure function, denoted NEF, which acts as a network function, NF, for "Network Function", which communicates with V2X application servers to provide QoS prediction notifications. It manages requests and subscriptions from V2X application servers and forwards responses or notifications to them; - a network data analysis function, denoted NWDAF for "Network Data Analysis Function", which is responsible for providing analyses and predictions of QoS parameters. It collects network performance data from an administration, operation and maintenance entity, denoted OAM, to evaluate and derive predictions of expected QoS changes; - the OAM entity, which is responsible for monitoring the performance of the telecommunications network, and for transmitting statistical data to the NWDAF function.

[0016] Technical specification TS23.287, "Architecture Enhancements for 5G System (5GS) to Support Vehicle-to-Everything (V2X) Services", version 16, January 2019, introduces a procedure for notifying users of potential changes to QoS parameters of a 5G telecommunications network, upon request from a V2X application server. According to this procedure, the V2X application server provides location information in the form of a path of interest and a time window indicating a period during which the notification service applies, as well as thresholds indicating the QoS parameter levels below or above which a notification must be transmitted to the V2X application server.

[0017] More specifically, the procedure described in the previously cited document comprises the following steps: - the V2X application server obtains application layer information such as the V2X service, the path of interest, a start time of the path of interest, QoS parameter requirements and thresholds; - The V2X application server subscribes to the analytical information of the "QoS Sustainability" service, provided by the NWDAF function, via the NEF function. The NWDAF function is responsible for providing on-demand analytics to other network entities. A subscription message may include an identifier of the requested analytical information and information such as QoS parameter requirements and thresholds, location information, and an observation period; - The NWDAF function collects statistics provided by the OAM entity, which is in charge of monitoring the performance of the telecommunications network. The NWDAF function checks whether the triggering conditions (which may include a comparison with a threshold, multiple comparisons with thresholds, or other specific events) are met and determines the requested analytical information regarding any expected change in a QoS parameter. According to the document "System Architecture for the 5G System Stage 2 (Release 16)", 3GPP TS 23.501 V16.7.0, December 2020, the NWDAF function can, in particular, determine a notification need by comparing the requested analytical information with the provided threshold(s) of QoS parameters in the requested period; - the NWDAF function provides a "QoS sustainability" service notification to the V2X application server, via the NEF function, which may include an identifier of an area to which the analytical information applies, a period, within the observation period, to which the analytical information applies, as well as the threshold(s) crossed by one or more QoS parameters; - depending on the notification received, the V2X application server can adjust the V2X application it implements.

[0018] In versions 17 and 18 of the aforementioned technical specification "Architecture Enhancements for 5G System (5GS) to Support Vehicle-to-Everything (V2X) Services," an improvement in the statistical quality of the analytical information provided is proposed by collecting data on a set of user devices served by a cell of the telecommunications network. However, such granularity does not allow for consideration of the specific context of certain devices within the cell that may affect one or more actual QoS parameters. Version 18 seeks to improve this granularity in the analyses provided by the "QoS sustainability" service.

[0019] However, the aforementioned techniques do not concretely provide how to predict with high accuracy the evolution of a QoS parameter at a given location, or in a given area.

[0020] However, V2X vehicular applications require high accuracy in the prediction of QoS parameters.

[0021] Indeed, the development of V2X applications is based on connected mobility, particularly for the highest levels of autonomy according to the SAE J3016 standard described in the document "Taxonomy and Definitions for Terms Related to On-Road Motor Vehicle Automated Driving Sys7em.s", J3OI6_2OI4OI, SAE International, 2018.

[0022] In this standard, autonomy levels 2 and 3, which are currently available on the market, allow the implementation of semi-automated driving assistance functions.

[0023] Driver assistance thus remains necessary, although the driver assistance system, ADAS for "Advanced Driver Assistance System", can perform certain driving tasks automatically. Level 4 and 5 vehicles involve scenarios in which ADAS can take over driving tasks without requiring user intervention, including in complex situations, as described in the document Naranjo, José, et al. "Cross-Border interoperability for Cooperative, Connected and Autonomous Driving" EE Intelligent Transportation Systems Magazine (2021).

[0024] On the one hand, in autonomy levels 2 and 3, driver-vehicle interaction is frequent and must be taken into account when predicting a QoS parameter. On the other hand, in autonomy levels 4 and 5, very precise QoS parameter predictions are required since the ADAS completely controls the vehicle without human intervention.

[0025] Indeed, although the AD AS system is based on sensors such as laser detection and rangefinding, radar, and cameras, these sensors have limitations which can lead to incorrect decisions and serious accidents. Telecommunications technologies help to overcome these limitations, particularly through the V2X vehicular applications described earlier.

[0026] The dependence of AD AS functions on V2X vehicular communication technologies has been reinforced since the implementation of fifth generation mobile telecommunications networks, which offer wider bandwidths and reduced latencies, thus meeting the strict requirements of V2X vehicular applications in terms of quality of service.

[0027] However, even taking into account the advantages offered by 5G mobile networks, road environments are subject to unpredictable fluctuations due to various factors, such as congestion and rapid vehicle movements. User mobility has a significant impact on the quality of service enabled by the 5G mobile network.

[0028] In addition, the increasing popularity of mobile applications, such as in-car entertainment, is placing increasingly significant constraints on telecommunications networks, such as cellular telecommunications networks in particular.

[0029] Mobile network operators, MNOs for “Mobile Network Operator”, are thus forced to collect a large amount of heterogeneous data to monitor the performance of the telecommunications network and provide a better quality of service.

[0030] To this end, the use of artificial intelligence models based on machine learning is developing.

[0031] Their application to QoS parameter prediction functions is, however, limited, due to the lack of publicly available quality datasets for training predictive models, and the high variability of situations encountered by vehicles. The document A. Skocaj et al., "Vehicle-to-Everything (V2X) Datasets for Machine Learning-Based Predictive Quality of Service," IEEE Communications Magazine, vol. 61, no. 9, pp. 106-112, September 2023, Doi: 10.1109 / MCOM.004.2200723, describes the databases available for such an application.

[0032] There is therefore a need to predict, accurately and with good spatial granularity, the evolution of one or more QoS parameters in a telecommunications network, in order to allow V2X vehicular applications to take such evolutions into account, thereby improving the safety and quality of experience of vehicle users benefiting from such V2X vehicular applications. Object and summary of the invention

[0033] One of the aims of the invention is to overcome at least one of the drawbacks of the aforementioned prior art by proposing a new technique for predicting a QoS parameter adapted for use in a vehicular application based on V2X communication, for example, C-V2X or satellite V2X. This makes it possible for an application server deploying a V2X vehicular application to vehicles to anticipate variations in the QoS parameter.

[0034] To this end, an object of the present invention relates to a method for predicting a quality of service (QoS) parameter of a telecommunications network capable of carrying vehicular application data, the method comprising, for at least one position or area of ​​a radio coverage area of ​​the telecommunications network and for at least one prediction horizon: - obtaining M measured values ​​of the quality of service parameter for said position or zone, M being an integer greater than or equal to 1; - determination of a predicted value of the quality of service parameter, for the prediction horizon and for the position or zone, by applying a prediction model to input data including an identifier of the position or zone, at least one prediction horizon and the M measured values ​​of the quality of service parameter.

[0035] Taking into account real-time measurements of QoS parameters in predicting its evolution over a prediction horizon makes it possible to account for the strong dynamics and variability of the constraints that apply to a telecommunications network, for example, a cellular telecommunications network that carries C-V2X vehicular application data, or a satellite telecommunications network that carries V2X vehicular application data. Furthermore, the prediction can be made for a given location, identified by a point position or an area, since the prediction model is capable of taking a position or area identifier as input data.

[0036] According to embodiments, the method may further include a transmission of the predicted value of the quality of service parameter to an application server configured to deploy a vehicular application to a set of vehicles via the telecommunications network.

[0037] Thus, the predicted QoS parameter value can be used by the application server to take proactive measures that improve the robustness and continuity of the vehicle application. This makes it possible to enhance the user experience in vehicles using the vehicle application, and even to improve safety associated with driving.

[0038] According to embodiments, the method may further include publishing said predicted value of the quality of service parameter in a prediction publishing server accessible via a wide area network.

[0039] Thus, publishing predictions on a publishing server enables the implementation of a "QoS sustainability" service, allowing application servers to make one-time or subscription requests to be informed of changes in the QoS parameter. A wide variety of V2X vehicular applications can therefore benefit from QoS parameter predictions.

[0040] According to embodiments, the method may include determining several predicted values ​​of the quality of service parameter, for said position or zone and for several respective prediction horizons, by several applications of the prediction model to respective input data.

[0041] Predictions for a plurality of prediction horizons allow for a better representation of the future evolution dynamics of the QoS parameter. More precise anticipatory measures can thus be implemented by one or more application servers.

[0042] According to embodiments, the method may include determining at least one predicted value of the quality of service parameter for several positions or areas of the radio coverage area and for at least one prediction horizon, by several applications of the prediction model to respective input data.

[0043] This makes it possible to predict, in a differentiated manner, across several zones or positions within a global telecommunications network coverage area, the evolution of the QoS parameter value. This allows for the provision of mapping information representing the evolution of the QoS parameter, enabling application servers to recommend specific routes to maintain the quality of user experience associated with a V2X vehicular application.

[0044] In addition, for K positions or zones in the radio coverage area and for L prediction horizons, where K and L are integers greater than or equal to 2, K*L predicted QoS parameter values ​​are obtained for the respective K positions or zones and for the respective L prediction horizons by K*L applications of the prediction model to respective input data. The K*L predicted QoS parameter values ​​can be published on the prediction publishing server.

[0045] It is thus possible to predict, in a differentiated manner, across several zones or positions within a global telecommunications network coverage area, the evolution of the QoS parameter value over several prediction horizons. This makes it possible to provide a map accurately illustrating the dynamic evolution of the QoS parameter in the future.

[0046] According to embodiments, the determination of the predicted value, for the prediction horizon and for the position or zone, can be repeated at a frequency associated with a period greater than the prediction horizon.

[0047] Such a period is denoted T2 in the following description. Thus, the predictions can be repeated in order to take into account new input data (in particular the last M measured values ​​of the QoS parameter), which allows for accurate prediction in a very changing environment such as a telecommunications network carrying V2X vehicular application data.

[0048] According to embodiments, the method may include collecting measured QoS parameter values ​​from at least one application server configured to implement a vehicle application for a set of vehicles via the telecommunications network, said measured values ​​being time-stamped and associated with at least one position or zone identifier, and storing said measured QoS parameter values ​​in a database. The M measured QoS parameter values ​​for said position or zone may be obtained from said database.

[0049] Thus, the measured values ​​of the QoS parameter can be centralized in a database and retrieved from vehicles operating within the telecommunications network coverage area, notably via application servers deploying V2X vehicular applications. This allows for real-time enrichment of the database, enabling real-time predictions of the QoS parameter value. Furthermore, having actual measured values ​​rather than estimated values ​​improves the accuracy of the predictions.

[0050] According to embodiments, the prediction model can be obtained by machine learning by training on a training dataset, the training dataset comprising measured values ​​of the QoS parameter associated with respective zone or position identifiers and respective timestamp values.

[0051] The use of machine learning allows the construction of a complex prediction model, with a large amount of input data, capable of accurately predicting the evolution of the QoS parameter for a prediction horizon.

[0052] In addition, the prediction model can be a RANdom SAmple Consensus type model, RANSAC, associated with a random forest type estimator.

[0053] The RANSAC model exhibits good robustness against outliers (inliers and outliers).

[0054] For example, in the context of a C-V2X cellular telecommunications network, in which inaccurate or noisy data is transported due to Given the various environmental factors involved, the RANSAC model's ability to filter out these inconsistencies and focus on significant trends is crucial. The prediction model is thus not disproportionately influenced by outliers, preserving the overall accuracy associated with the prediction, latency, or other QoS parameters, such as bandwidth or cellular network connection reliability.

[0055] In addition to the RANSAC model, the Random Forest Estimator (RF) has inherent capabilities to handle complex data and to build a set of numerous trees, each learning from a random sample of the training dataset. This approach makes it possible to obtain robust predictions by aggregating the results of multiple trees, thus reducing the risk of overfitting and improving the reliability of predictions, including in dynamic and changing environments such as those encountered in V2X vehicular application data transport.

[0056] The combination of a RANSAC type prediction model with an RF estimator thus makes it possible to take into account the temporal and spatial variability of the QoS parameters, latency in particular, of a telecommunications network transporting data from V2X vehicular applications.

[0057] In addition or alternatively, the prediction model can be updated by training on an updated training dataset, at a frequency associated with a period.

[0058] Such a period is denoted Tl in what follows. Thus, the prediction model itself can be updated, which makes it possible to take into account the significant variability of vehicular application data in a telecommunications network, whether over a single day, or depending on the day of the week or the season. The period Tl can advantageously be equal to one day.

[0059] In addition, for an update of the prediction model during a period of index j, the updated training dataset may include measured values ​​of the QoS parameter collected during a previous period of index j-1.

[0060] Thus, the training data can be updated on the basis of the most recent training data, which makes it possible to improve the accuracy associated with the predictions of the prediction model.

[0061] The invention also relates to a prediction server for a quality of service (QoS) parameter of a telecommunications network capable of carrying vehicular application data, the server comprising a processor configured, for at least one position or area of ​​a radio coverage area of ​​the telecommunications network and for at least one prediction horizon, to: - obtain M measured values ​​of the quality of service parameter for said position or zone, M being an integer greater than or equal to 1; - determine a predicted value of the quality of service parameter, for the prediction horizon and for the position or zone, by applying a prediction model to input data including an identifier of the position or zone, at least one prediction horizon and the M measured values ​​of the quality of service parameter.

[0062] Such a server is notably configured to implement the aforementioned prediction process, according to one or the other of its embodiments.

[0063] The invention also relates to a computer program comprising instructions for implementing the QoS parameter prediction method according to the invention, according to any one of the particular embodiments described above, when said program is executed by a processor.

[0064] Such instructions can be stored permanently in a non-transient memory medium of the prediction server implementing the prediction method according to the invention.

[0065] This program may use any programming language, and be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0066] The invention also relates to a recording medium or information medium readable by a computer, and comprising instructions for a computer program as mentioned above.

[0067] The recording medium can be any entity or device capable of storing the program. For example, the medium can include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a mobile medium, a hard disk drive or an SSD.

[0068] On the other hand, the recording medium can be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means, so that the computer program it contains is executable remotely. The program according to the invention can, in particular, be uploaded to a network, for example, an Internet-type network.

[0069] Alternatively, the recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned prediction process.

[0070] According to one embodiment, the present technique is implemented using software and / or hardware components. In this context, the term "device" or " "module" in this document can refer to a software component, a hardware component, or a set of hardware and software components. Brief description of the drawings

[0071] Other features and advantages will become apparent upon reading particular embodiments of the invention, given by way of illustrative and non-limiting examples, and the accompanying drawings, among which:

[0072] Figure 1 represents an architecture in which the method for predicting a quality of service parameter of a telecommunications network is implemented, according to a particular embodiment of the invention.

[0073] The [Fig.2] represents the steps of a learning phase of a method for predicting a quality of service parameter of a telecommunications network, according to an embodiment of the invention, as implemented in the architecture of the [Fig.1]; Figure 3 represents the steps of a common phase of a method for predicting a quality of service parameter of a telecommunications network, according to an embodiment of the invention, as implemented in the architecture of Figure 1;

[0074] Fig. 4 represents a structure of a prediction server for a quality of service parameter of a telecommunications network, according to an embodiment of the invention.

[0075] Detailed description of an embodiment of the invention

[0076] Figure 1 represents an architecture 10 in which a method for predicting a quality of service parameter of a radio communication network 120 is implemented, according to an embodiment of the invention. In the example shown by way of illustration in Figure 1, the telecommunications network 120 is a cellular telecommunications network, for example of the 3G, 4G, 5G, etc. type. Alternatively, the telecommunications network 120 may be satellite according to the invention.

[0077] The 120 cellular network can comprise a plurality of base stations, including a first base station 121.1 and a second base station 121.2 represented for illustrative purposes in [Fig.1], each base station being capable of covering a respective radio coverage area, to communicate bidirectionally with clients located in the radio coverage area.

[0078] In the context of the present invention, the customers considered are a set of N vehicles 110.1 to 110.N capable of accessing the cellular network 120 via one of the base stations of the cellular network 120.

[0079] No restriction is attached to the number N of vehicles accessing the cellular network 120, which may include, at any given time, several hundred or thousands of vehicles. The number N is dynamic in that the position of each of the vehicles evolves dynamically: a vehicle can thus enter or leave a radio coverage area of ​​a base station, and can thus enter or leave a global radio coverage area of ​​the cellular 120 network, constituted by the union of the radio coverage areas of the base stations of the cellular 120 network.

[0080] In order to simplify the description of the invention in what follows, it is considered that N is equal to 3.

[0081] Vehicles 110.1-110.N can in particular access the 120 cellular network by the C-V2X technology described above, which is known and whose operation is not further detailed in this description.

[0082] Vehicles 110.1-110.N use the cellular network 120 as an access network to a wide area network 130 to benefit from one or more connected services. In particular, vehicles 110.1-110.N can access a V2X vehicle service implemented by an application server 131. Note that vehicles 110.1 to 110.N can access several separate application servers 131 for the implementation of different connected services.

[0083] Examples of V2X vehicular services are given below by way of example.

[0084] In a first application example, vehicles 110.1-110.N collaborate on a service for collecting and sharing high-definition (HD) maps, gathering data via various sensors. This captured data is sent to the application server 131, which can then build high-definition maps, for example, regional maps. In this first application example, it is very useful to predict the evolution of a quality of service parameter of the cellular network 120, in order to regulate the number of vehicles involved in distributing and updating the HD map for each region, and to adjust the frequency of the generated messages.

[0085] In a second application example, the V2X vehicle application is a remotely operated driving service that allows a remote operator to control a vehicle. The data captured by the vehicle, including on-board camera videos, are processed in the application server 131. In this second application example, it is very useful to predict the evolution of a QoS parameter in order to allow a transition to a safe mode in the event of a degradation of the QoS parameter, thus adapting the vehicle's speed and trajectory.

[0086] In a third application example, the V2X vehicle application is associated with a high-density convoy service, allowing vehicles to travel in close proximity to reduce fuel consumption and traffic congestion. In this third application example, it is very useful to predict the evolution of a QoS parameter, particularly in the case of QoS degradation, in order to enable autonomous vehicle coordination or request human intervention.

[0087] Other V2X vehicle applications are sensitive to variations in QoS parameters and can be implemented by an application server 131 within the scope of the invention. In particular, other application cases are described below. The invention then makes it possible, as detailed below, to provide a prediction of a QoS parameter to the application server 131, for the implementation of an appropriate anticipatory action, thus ensuring an optimal level of vehicle safety under all circumstances.

[0088] The application server 131 can be a V2X AS application server type server as defined in the aforementioned technical specifications of the 3GPP organization.

[0089] Referring again to [Fig.1], the architecture 10 further includes an interface server 133 of a QoS parameter prediction service and a QoS parameter prediction server 134, implementing a prediction model as described below.

[0090] The interface server 133 provides a service allowing access to predictions of at least one QoS parameter published by the prediction server 134 in a prediction publishing server 135.

[0091] The interface server 133 can be a server fulfilling the NEF function defined in the aforementioned technical specifications of the 3GPP organization.

[0092] The prediction server 134 can be a server fulfilling the NWDAS function defined in the aforementioned technical specifications of the 3GPP organization.

[0093] In what follows, unless otherwise stated and for illustrative purposes only, the QoS parameter is considered to be a latency parameter, latency being a particularly critical parameter in the implementation of V2X vehicular applications, such as the three application examples listed above, which require high responsiveness. The invention, however, relates more generally to the prediction of a QoS parameter of the telecommunications network, particularly a cellular network, which may include bandwidth, connection reliability, and / or any other quality of service parameter.

[0094] The architecture 10 further includes a database 132 capable of storing latency values ​​(or of another QoS parameter according to the invention), measured by the vehicles themselves when using the cellular network 120. Such latency values ​​are thus real latency measurements reported by the vehicles 110.1 to 110.N, for example on a regular basis.

[0095] By way of example, latency values ​​are acquired by application server 131, or application servers 131, and stored in database 132 either directly or via interface server 133.

[0096] According to the invention, any latency value stored in database 132 is: - time-stamped; - associated with location information, which can be a point location defined by GPS coordinates, for example, or which can be an area identifier. The area can be a tile of a given level (the level indicating a zoom level, and therefore a tile size). For example, the area identifier can be a numeric string, called a "quadkey," uniquely identifying a tile for a given level. The given level could be, for example, level 22 of the Bing Maps™ web service's Tile System, where each tile is 10 meters by 10 meters, for example.

[0097] Storing latency values ​​in database 132 allows, as explained below: - to generate training data for learning the prediction model described below. In particular, the accumulated latency data can be used to train the prediction model, which is repeated at an initial frequency, corresponding to an initial period Tl, which could be, for example, one day. The parameters of the prediction model can thus be updated regularly at this initial frequency; - to form input data for the prediction model, specifically the last M latency values ​​associated with a given position or zone, where M can be greater than 10 (e.g., between 50 and 200, for example, equal to 100). The prediction model can then be used at a second frequency provided by the prediction server 134 to determine latency predictions for one or more given prediction horizons within a second period T2 associated with that second frequency. The second period T2 can be between 30 minutes and 2 hours (e.g., equal to 1 hour).

[0098] Figure 2 shows the steps of a learning phase of a method for predicting a QoS parameter according to embodiments of the invention.

[0099] At a step 200, latency values ​​measured by one or more vehicles, time-stamped and associated with position information are collected by application server 131, or by one of the application servers 131.

[0100] At a step 201, the latency values ​​thus collected are stored in the database 132 by the application server 131, for example via the interface server 133.

[0101] Steps 200 and 201 are implemented continuously so as to accumulate latency values ​​obtained for a large number of vehicles and for different positions or tiles within a given region. Furthermore, the latency values ​​can be centralized in the database 132, which can be shared by several application servers 131, dedicated to distinct V2X vehicle applications. This facilitates the creation of a rich database containing values ​​of latency for a large number of positions, for example for all tiles in a given region.

[0102] At a step 202, the prediction server 134 can check the value of a counter. The counter value can be reset each time the counter expires. The counter expires after a duration corresponding to the first period Tl, which corresponds to the update period of the prediction model stored and used by the prediction server 134 according to the invention. Updating the prediction model at each period Tl allows for consideration of the wide variability of constraints that apply to the cellular network 120 and that can affect QoS parameters such as latency.

[0103] As previously stated, the period Tl can be one day.

[0104] Thus, at the end of period T1, the process learning phase moves to a step 203.

[0105] Steps 203 to 206 can be implemented by the prediction server 134 described above, or by another entity capable of accessing network 100. In what follows, it is considered for illustrative purposes only that steps 203 to 206 are implemented by the prediction server 134.

[0106] In step 203, at least a portion of the data stored in the database 132 can be processed by the prediction server 134 to obtain a training dataset for the prediction model. Furthermore, the same processing can be applied to obtain evaluation and test data for the prediction model.

[0107] The processing of step 203 may include: - a structuring of timestamp data associated with latency values, in a predefined format, which allows consistency in the processing of timestamp data; - Extraction of temporal features from timestamp data, with features potentially including the week of the year, day of the week, hour, minute, second, or even milliseconds. Such detailed extraction of temporal features allows for high granularity in the analysis of temporal trends and enables the detection of seasonal patterns, hourly fluctuations, or periodic behaviors in the data, thus enhancing the predictive model's ability to understand the temporal dynamics associated with latency (or another QoS parameter, such as bandwidth or connection reliability); - Handling of missing latency values ​​to replace missing values ​​with a zero value.This makes it possible to ensure continuity of latency values ​​over time and for all zones or positions: indeed, the collected latency values ​​are discontinuous by nature because they depend on the . The presence or absence of vehicles at a given position or zone during a given period. Another method for handling missing values ​​can be provided according to the invention, for example, by interpolating actually measured latency values.

[0108] According to the invention, the trained prediction model takes the following as input: - a position identifier, such as a tile identifier for example; - a prediction horizon H. The prediction horizon can take a value from a predefined set of prediction horizon values, for example 15 minutes, 30 minutes, and 1 hour. In what follows, three horizon values ​​are considered from the predefined set of prediction horizon values, for illustrative purposes only; - M previous latency values, actually measured for the identified tile, or obtained by spatial interpolation between previous latency values ​​measured in two or more tiles around the identified tile.

[0109] As output, the prediction model determines a predicted latency value for the position identifier and for the prediction horizon.

[0110] Taking into account the M previous latency values ​​as input to the prediction model allows for dynamic adaptation to real-time changes, significantly improving the accuracy associated with latency prediction. Such an approach allows the prediction model to learn and adjust in real time, capturing rapid and significant latency changes that could impact the performance of the V2X vehicular application.

[0111] Thus, in order to be able to constitute a training dataset, the data from database 132 and processed during step 203 can be organized into several training batches (the training batches forming the training dataset), each training batch comprising: - a position identifier, a prediction horizon value H and M previous values ​​(relative to a given past time tpast) of latency for the position identifier, to form input data during the training of the model; - the latency value actually measured (from database 132) for the position identifier and in a horizon H after the given past time (i.e. at time tpast+H), the latency value actually measured thus forming the ground truth, with which the predicted latency value can be compared to train the parameters of the prediction model.

[0112] Similarly, in order to create a test dataset and an evaluation dataset, the data from database 132 and processed in step 203 can be organized into several test sets (the test sets forming the test dataset) and several evaluation sets (the evaluation sets forming the evaluation dataset), each test set and set evaluation having the same composition as a training set, but being made up of data distinct from database 132.

[0113] Preferably, the training sets are varied in that the training set includes several sets per prediction horizon and per location identifier, as well as for various given past times (for example, for all time slots in a day).

[0114] At a step 204, the prediction server 134 trains the prediction model on the basis of the training data from the processing trap 203. For this purpose, the input data of each batch can be submitted as input to the prediction model, and the parameters of the prediction model are adjusted according to a difference between the latency prediction at the output of the model and the measured latency value of the training batch (the ground truth).

[0115] No restrictions are attached to the prediction model, which is any model defined by parameters that can be determined by machine learning. Preferably, the prediction model can be of the RANSAC type (RANdom SAMPle Consensus) combined with a random forest estimator, or RF (Random Forest). Such a combination is particularly well-suited for handling QoS parameter specifics for V2X data transport and for ensuring robust and reliable performance.

[0116] The RANSAC model exhibits good robustness to outliers (inliers and outliers). In the context of a V2X cellular network, where inaccurate or noisy data is transmitted due to various environmental factors, the ability of the RANSAC model to filter out these inconsistencies and focus on significant trends is crucial. The prediction model is thus not disproportionately influenced by outliers, thereby preserving the overall accuracy associated with the prediction, latency, or other QoS parameters.

[0117] In addition to the RANSAC model, the RF estimator has intrinsic capabilities to handle complex data and to build a set of numerous trees, each learning on a random sample of the training dataset. Such an approach makes it possible to obtain robust predictions by aggregating the results of multiple trees, thereby reducing the risk of overfitting and improving the reliability of predictions, including in dynamic and changing data environments such as those encountered in V2X vehicular application data transport.

[0118] The combination of a RANSAC-type prediction model with an RF estimator thus makes it possible to take into account the temporal and spatial variability of the parameters QoS, latency in particular, of a telecommunications network carrying V2X vehicular application data.

[0119] Following step 204, the prediction server 134 can evaluate the trained prediction model according to at least one evaluation criterion, at a step 205.

[0120] A first evaluation criterion can be the mean absolute error (MAE), which quantifies the average error between the predicted values ​​and the actual values ​​(ground truth). The MAE criterion provides a measure of the average magnitude of the errors in the predictions, thus allowing the overall accuracy of the model to be assessed.

[0121] The MAE criterion is evaluated by the following formula (1):

[0122]

[0123] Where y is the predicted value of latency and y; is the actual measured value of latency, n being an integer representing the number of predictions considered.

[0124] A second evaluation criterion, in addition to or as an alternative to the first criterion, may be a mean absolute percentage error, or MAPE. The MAPE criterion expresses the error as a percentage between the predicted and actual values, providing an assessment of the relative accuracy of the prediction model. The MAPE criterion thus provides a measure of the accuracy of the prediction model by taking into account the relative proportions of errors with respect to the actual values. The MAPE criterion is evaluated by the following formula (2):

[0125] madv 1?" 1^ (2) MAPE = n 2^- JT" x 100%

[0126] With the same notation as in formula (1).

[0127] A third evaluation criterion, in addition to or as an alternative to the first and / or second evaluation criterion, may be a coefficient of determination, also called the R² score, which measures the ability of the prediction model to explain the variance of the data around the mean. An R² score close to 1 indicates that the prediction model fits the data well, capturing a large proportion of the variance of the actual values. However, a high R² score may not always mean an accurate prediction in certain contexts. For a series of n predictions with respect to the actual values, the R² score is calculated according to formula (3) below, with the same notation as for formulas (1) and (2): [°128] „ , (3) ÆO - 1 “ -y

[0129] And in which represents the average of the real values ​​y;.

[0130] Thus, during step 205, the prediction server 134 can evaluate the prediction model according to at least one of the above evaluation criteria, applied to predictions made on the evaluation dataset constituted in step 203, which makes it possible to evaluate the performance of the prediction model on new data.

[0131] At a step 206, the prediction server 134 can test the evaluated prediction model on the test dataset created in step 203, which allows evaluation of the ability of the prediction model to accurately predict the QoS parameter, latency in particular, for new data.

[0132] After training, evaluating and testing several prediction models, the prediction model offering the most satisfactory performance can be chosen as the optimal prediction model by the prediction server 134 at a step 207.

[0133] At an optional step 208, the optimal prediction model can be optimized, for example by retraining on the complete set of data processed in step 203, readjusting the parameters of the optimal prediction model, or any other optimization to enhance the accuracy of the predictions.

[0134] At a step 209, the optimal prediction model is stored or installed in the prediction server 134, for use during the current phase described with reference to [Fig. 3] shown below. The prediction model can, for example, be stored in a pki format.

[0135] As shown in [Fig.2], the prediction model can be updated at the first frequency, i.e. at the expiration of each first period Tl, based on the data collected and stored in steps 200 and 201 during the previous first period Tl.

[0136] Thus, at the beginning of a first period Tl of index j, the prediction model stored in step 209 during the first period Tl of index j-1, is retrained on the training database updated from the data in database 132 which includes in particular the data collected and stored in steps 200 and 201 during the first period Tl of index j-1.

[0137] The evaluation criteria described above were evaluated for several first-period Tl values, including: - for a first period Tl equal to one day; - for a first period Tl equal to one week; - for a first period Tl equal to one month.

[0138] It follows that prediction models trained over shorter periods (one day in particular) exhibit better performance according to the MAE criterion, indicating a more accurate prediction of latency, compared to models that have benefited from longer training periods. The same conclusion applies to the MAPE criterion. The third criterion R2 score remains high for all strategies, thus indicating that the ability to explain the variance of the data is similar regardless of the duration of the first period T1.

[0139] Figure 3 shows the steps of a common phase of a method for predicting a QoS parameter according to an embodiment of the invention.

[0140] Steps 301 to 303 are implemented by the prediction server 134 described above, during a first period Tl of index j: at the end of the previous first period Tl of index j-1, the updated prediction model was stored in the prediction server 134, for use during the first period Tl of index j.

[0141] Steps 301 to 303 can be iterated, upon the expiration of a counter initialized for a duration corresponding to the second period T2.

[0142] As previously stated, the second period T2 is shorter than the first period Tl, in particular so that several second periods T2 are included in the first period Tl of index j. For example, the second period T2 is equal to 1 hour, in which case if the first period Tl is one day, it comprises 24 periods T2.

[0143] Thus, at the end of a second period T2, determined at step 301 by the prediction server 134, the prediction server 134 can determine at a step 302 a plurality of predicted latency values ​​by applying the prediction model several times: - for a set of positions or tiles; and - for each position or each tile, for one or more prediction horizons shorter than the duration of the second period T2.

[0144] By way of example, the prediction model is applied four times, for two tiles Tul and Tu2 and the given geographical area, and for two prediction horizons for each tile, for example for prediction horizons of 10 minutes and 30 minutes.

[0145] Thus, the prediction server 134 applies the prediction model once to obtain a first predicted latency value, with the following input data: - the tile identifier Tu2; - the 10-minute prediction horizon; - the last M latency values ​​for tile Tu2 (which are the M values ​​collected before a time t0 from which step 302 is implemented) and stored in database 132, or in the absence of latency values ​​for tile Tu2 in database 132, determined by interpolation of latency values ​​collected for neighboring tiles.

[0146] The prediction server 134 applies the prediction model a second time to obtain a second predicted latency value, with the following input data: - the tile identifier Tu2; - the 30-minute prediction horizon; - the last M latency values ​​for tile Tu2 (which are the M values ​​collected before a time t0 from which step 302 is implemented) and stored in database 132, or in the absence of latency values ​​for tile Tu2 in database 132, determined by interpolation of latency values ​​collected for neighboring tiles.

[0147] The prediction server 134 applies the prediction model a third time to obtain a third predicted latency value, with the following input data: - the tile identifier Tul; - the 10-minute prediction horizon; - the last M latency values ​​for tile Tul (which are the M values ​​collected before a time t0 from which step 302 is implemented) and stored in database 132, or in the absence of latency values ​​for tile Tul in database 132, determined by interpolation of latency values ​​collected for neighboring tiles.

[0148] The prediction server 134 applies the prediction model a fourth time to obtain a third predicted latency value, with the following input data: - the tile identifier Tul; - the 30-minute prediction horizon; - the last M latency values ​​for tile Tul (which are the M values ​​collected before a time t0 from which step 302 is implemented) and stored in database 132, or in the absence of latency values ​​for tile Tl in database 132, determined by interpolation of latency values ​​collected for neighboring tiles.

[0149] In practice, the prediction server can apply the prediction model for more than two prediction horizons and / or for more than two positions or tiles. Thus, more generally, the prediction server can apply K*L times the prediction model for K tiles and L prediction horizons, K and L being greater than or equal to 1, with K and / or L preferably greater than or equal to 2.

[0150] A set of predicted latency values ​​is thus obtained in step 302, for one or more positions or tiles of the region and for one or more prediction horizons.

[0151] At a step 303, the set of latency values ​​predicted at step 302 can be published into the prediction publishing server 135 by the prediction server 134.

[0152] Thus, the predictions published in the prediction publishing server 135 can be used by the interface server 133 capable of providing a latency prediction service to the application server(s) 131.

[0153] Thus, at a step 310, the interface server 133 can receive a request from an application server 131, the request indicating: - one or more positions or one or more tiles; - Optionally, at least one prediction time tb that is a time after the time at which the request is transmitted. The prediction time t1 could, for example, be 15 minutes after the time at which the request is transmitted. Alternatively, a series of prediction times including at least two prediction times t1 and t2 are included in the request. Alternatively, the request does not include any prediction times.

[0154] Upon receiving the request, the interface server 133 obtains, at a step 311, from the prediction publishing server 135, a prediction value for each position or tile whose prediction horizon is closest to the prediction time tb if the request includes at least one prediction time.If the query does not include any prediction time, the interface device obtains the prediction values, for each position or tile, for all prediction horizons corresponding to a prediction time that has not yet passed.

[0155] For example, if the request indicates the first tile Tul and the prediction time ti, the interface server 133 returns to the application server 131 the predicted latency value corresponding to the tile Tul, and to the horizon t0+10 or to+30, depending on whether ti is closer to the horizon t0+10 or to the horizon t0+30.

[0156] Interface server 133 transmits a response to application server 131, at a step 312, the response including one or more latency values ​​obtained at step 311.

[0157] Based on the predicted latency value received at step 312, or the latency values ​​predicted at step 312, the application server 131 can anticipate a variation in latency, for example, if a threshold is crossed, and can take any anticipatory measures to prevent latency degradation from causing safety problems or more generally diminishing the user experience in vehicles using the V2X vehicle application implemented by the application server 131. Alternatively or in addition, new V2X vehicle applications can be implemented by one or more application servers 131, based on QoS parameter predictions. Examples of using the service implemented by the interface server 133 for different V2X vehicle applications are described below with reference to various use cases.

[0158] As an alternative to sending a request in step 310, application server 131 can subscribe to a notification service from interface server 133. In this case, a subscription request can be transmitted by application server 131 to interface server 133, the subscription request comprising: - a threshold value; - one or more positions or tiles.

[0159] In this case, the interface server 133 can obtain the predicted latency values ​​for the position(s) or tile(s) published in the prediction publishing server 135. The predicted latency values ​​are compared to the threshold value. If the threshold is exceeded for a position or tile, and for a prediction horizon corresponding to a future time t0+H, the interface server 133 sends a notification to the application server 131, the notification indicating: - the position or tile for which the threshold is exceeded; and - the future time t0+H.

[0160] Thus, for this variant as well, the application server 131, upon receiving a notification, can anticipate a degradation in quality of service, in particular latency, and can take any anticipatory measure to prevent the degradation of latency from causing security problems or more generally diminishing the user experience in vehicles benefiting from the V2X vehicle application implemented by the application server 131.

[0161] In a first application case, the predicted QoS parameter(s) enable optimization of urban traffic. For example, connected vehicles 110.1 to 110.N can select routes based on bandwidth (which in this case is one of the predicted QoS parameters) and latency, thanks to a V2X vehicular application associated with an application server 131, ensuring smooth communications for other vehicular applications such as traffic control or traffic coordination.

[0162] For example, 110.1-110.N vehicles can analyze bandwidth predictions provided by application server 131, to choose routes allowing fast communications for map updates or for traffic signals.

[0163] According to another example for this first use case, an application server 131 uses connection reliability predictions (which in this case is one of the predicted QoS parameters) to prioritize safety messages sent to certain smart traffic lights based on their respective locations, thus ensuring fast responses for traffic regulation.

[0164] In a second application, QoS parameter prediction improves road safety by anticipating fluctuations in connection reliability, thereby helping to prevent accidents by ensuring constant communication between vehicles. For example, connection reliability predictions (which in this case is one of the predicted QoS parameters) can be transmitted by an application server 131 to vehicles 110.1-110.N, which can then take action preventative measures in case of anticipated communication failure, such as activating autonomous security systems for example.

[0165] In a third application, QoS parameter predictions help maintain stable connectivity for emergency vehicles, ensuring rapid response times in critical situations. For example, a V2X vehicle application provided by an application server 131 to emergency vehicles allows them, based on latency predictions, to choose routes offering stable connectivity to transmit vital information to hospitals in real time.

[0166] In a fourth application, QoS parameter predictions enable proactive management of a V2X vehicular application by an application server 131, adapting the quality of service according to predicted variations in QoS parameters. For example, bandwidth predictions (which in this case is a predicted QoS parameter) allow a V2X vehicular service delivering content to vehicles 110.1-110.N to deliver content in a format whose quality depends on bandwidth predictions, thereby optimizing the quality of this content. By predicting a drop in bandwidth in a specific area, the video resolution can be adjusted in real time to maintain uninterrupted streaming to vehicles in that specific area.

[0167] In a fifth application case, QoS parameter predictions enable real-time map updates. By predicting variations in latency and connection reliability, a V2X vehicular application implemented by an application server 131 can schedule and prioritize map updates for specific locations and at specific times, ensuring accurate and up-to-date data in vehicles 110.1-110.N. For example, a low latency prediction over a given period and for a given location or tile makes it possible to determine the best time to update a map, guaranteeing efficient data synchronization without disrupting other V2X vehicular applications that may be used by a vehicle.

[0168] In a sixth application case, a vehicle 110.1-110.N can access variations in a QoS parameter via an application server 131 accessing the interface server 133. The vehicle can thus schedule remote diagnostics or a software update to ensure optimal performance. For example, the vehicle detects a predicted increase in latency and automatically triggers remote maintenance to resolve potential problems before they affect vehicle performance.

[0169] Thus, more generally, the prediction of a QoS parameter allows the optimization of V2X vehicular applications.

[0170] Figure [Fig.4] illustrates a structure of the prediction server 134 according to embodiments of the invention.

[0171] The prediction server 134 includes a processor 401 configured to communicate unidirectionally or bidirectionally, via one or more buses or via a direct wired connection, with a memory 402 such as Random Access Memory (RAM), Read Only Memory (ROM), or any other type of memory (Flash, EEPROM, etc.). Alternatively, the memory 402 comprises several memories of the aforementioned types.

[0172] Memory 402 includes at least one non-volatile memory in which are stored temporarily or permanently the data used and / or resulting from the implementation of steps 301 to 303 previously described, and of steps 202 to 209 when implemented by the prediction server 134.

[0173] In particular, memory 402 can store the prediction model during step 209 described above.

[0174] The processor 401 is capable of executing instructions, stored in memory 402, for the implementation of steps 301 to 303, and optionally steps 202 to 209 described previously.

[0175] The prediction server 134 further includes a network interface 403 capable of communicating with other entities accessing the extended network 130 described with reference to [Fig. 1].

Claims

Demands

1. Method for predicting a quality of service (QoS) parameter of a telecommunications network (120) capable of carrying vehicular application data, the method comprising, for at least one position or zone of a radio coverage area of ​​the telecommunications network and for at least one prediction horizon: - obtaining (200; 201) M measured values ​​of the quality of service parameter for said position or zone, M being an integer greater than or equal to 1; - determining (302) a predicted value of the quality of service parameter, for the prediction horizon and for the position or zone, by applying a prediction model to input data comprising an identifier of the position or zone, the at least one prediction horizon and the M measured values ​​of the quality of service parameter.

2. A method according to claim 1, further comprising a transmission (312) of the predicted value of the quality of service parameter to an application server (131) configured to deploy a vehicle application to a set of vehicles (110.1-110.N) via the telecommunications network (120).

3. A method according to claim 1 or 2, further comprising a publication (303) of said predicted value of the quality of service parameter in a prediction publishing server (135) accessible via a wide area network (130).

4. A method according to any one of the preceding claims, comprising determining (302) several predicted values ​​of the quality of service parameter, for said position or zone and for several respective prediction horizons, by several applications of the prediction model to respective input data.

5. A method according to any one of the preceding claims, comprising determining (302) at least one predicted value of the quality of service parameter for several positions or areas of the radio coverage area and for at least one prediction horizon, by several applications of the prediction model to respective input data.

6. A method according to claims 3, 4 and 5, wherein, for K positions or zones of the radio coverage area and for L prediction horizons, K and L being integers greater than or equal to 2, K*L predicted QoS parameter values ​​are determined (302) for the respective K positions or zones and for the respective L prediction horizons by K*L applications of the prediction model to respective input data; wherein the K*L predicted QoS parameter values ​​are published (303) in the prediction publishing server (135).

7. A method according to any one of the preceding claims, wherein the determination (302) of the predicted value, for the prediction horizon and for the position or area, is repeated at a frequency associated with a period (T2) greater than the prediction horizon.

8. A method according to any one of the preceding claims, comprising collecting (200) measured values ​​of the QoS parameter from at least one application server (131) configured to implement a vehicle application to a set of vehicles (110.1-110.N) via the telecommunications network (120), said measured values ​​being time-stamped and associated with at least one position or zone identifier, and storing (201) said measured values ​​of the QoS parameter in a database; wherein the M measured values ​​of the quality of service parameter for said position or zone are obtained from said database.

9. A method according to any one of the preceding claims, wherein the prediction model is obtained by machine learning by training (204) on a training dataset, the training dataset comprising measured values ​​of the QoS parameter associated with respective zone or position identifiers and respective timestamp values.

10. A method according to claim 9, wherein the prediction model is a RANdom SAmple Consensus type model, RANSAC, associated with a random forest type estimator.

11. A method according to claim 9 or 10, wherein the prediction model is updated by training (204) on the updated training dataset, at a frequency associated with a period (Tl).

12. A method according to claim 8 and claim 11, wherein for an update of the prediction model during a period (Tl) of index j, the updated training dataset includes measured values ​​of the QoS parameter collected during a previous period (Tl) of index j-1.

13. A prediction server (134) for a quality of service (QoS) parameter of a telecommunications network (120) capable of carrying vehicular application data, the server comprising a processor (401) configured, for at least one position or zone of a radio coverage area of ​​the telecommunications network and for at least one prediction horizon, to: - obtain M measured values ​​of the quality of service parameter for said position or zone, M being an integer greater than or equal to 1; - determine a predicted value of the quality of service parameter, for the prediction horizon and for the position or zone, by applying a prediction model to input data comprising an identifier of the position or zone, the at least one prediction horizon and the M measured values ​​of the quality of service parameter.

14. A computer program comprising program code instructions for implementing the method of predicting a quality of service parameter according to any one of claims 1 to 12, when executed by a processor.

15. Computer-readable information carrier, and containing instructions for a computer program according to claim 14.

Images