Predicting a quality of service parameter of a telecommunications network

Abstract

The invention relates to a method for predicting a quality of service, QoS, parameter of a telecommunications network capable of conveying vehicle 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 M measured values of the quality of service parameter for the 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 for the position or zone, the at least one prediction horizon and the M measured values of the quality of service parameter.

Description

Prediction of a quality of service parameter for a telecommunications network Scope 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] Vehicle-to-X (V2X) communications are now key to the operation of modern 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.11p standard; and - cellular V2X technology, or C-V2X for "Cellular-V2X", 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. Operating 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 to improve road safety and traffic flow. 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] In contrast, C-V2X technology offers a wider range and the ability to handle larger volumes of data, but at the cost 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.Conversely, while widely used in early V2X applications, DSRC technology has faced interoperability challenges, which may limit its widespread adoption. Regarding its use for advanced applications: C-V2X technology offers greater flexibility and processing capacity compared to DSRC, thanks to its use of cellular networks. This enables more advanced applications, such as real-time traffic updates, sophisticated safety alerts, and communication 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 parameters than conventional consumer applications. 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. This enables C-V2X applications, such as automated driving or intelligent traffic management systems, to calculate and adjust their operating modes in advance to ensure the continuous safety and availability of these applications. Specifications from the 3GPP organization define QoS parameters and thresholds to be met to guarantee QoS tailored to the requirements of vehicular applications.

[0010] The spatiotemporal dynamics of cellular networks and vehicle mobility can lead to sudden changes in QoS parameters. Abrupt adjustments to vehicular applications, especially those resulting from QoS parameter degradation, can adversely affect the performance of 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 expected changes in QoS parameters. Sudden QoS changes can thus be avoided or mitigated by informing the application servers supporting V2X vehicular applications about connectivity parameters and impending QoS changes, thereby maintaining the security and efficiency of V2X applications.

[0013] The document "Technical Report on Predictive QoS and V2X Service Adaptation", 5GAA, October 2022, identified several use cases that benefit 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 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 includes: - V2X application servers, denoted AS for "Application Server," which act as application functions, denoted AF for "Application Function," 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 the V2X application servers to provide QoS prediction notifications. It manages requests and subscriptions from the V2X application servers and forwards the responses or notifications to them; - a network data analysis function, denoted NWDAF for "Network Data Analysis Function," which is responsible for providing the analyses and predictions of the QoS parameters.It collects network performance data from an administration, operation and maintenance entity, denoted OAM, to evaluate and derive predictions of expected QoS change; - 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 in 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 the period during which the notification service applies, as well as thresholds indicating the QoS parameter levels below or above which a notification must be sent to the V2X application server.

[0017] More specifically, the procedure described in the previously cited document includes the following steps: - The V2X application server obtains application layer information such as the V2X service, the path of interest, the start time of the path of interest, and QoS parameter requirements and thresholds; - The V2X application server subscribes to analytical information for 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 for 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 responsible for 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 notably 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 can 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 that it implements.

[0018] Versions 17 and 18 of the aforementioned technical specification, "Architecture Enhancements for 5G System (5GS) to Support Vehicle-to-Everything (V2X) Services," propose an improvement in the statistical quality of the analytical information provided 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 cell devices that may affect one or more real QoS parameters. Version 18 aims 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 predicting QoS parameters.

[0021] Indeed, the development of V2X applications relies 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 Systems", J3016 / _201401, 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 therefore remains necessary, although the Advanced Driver Assistance System (ADAS) 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," IEEE 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 ADAS systems are based on sensors such as laser detection and ranging, radar, and cameras, these sensors have limitations that 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 ADAS 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 stringent requirements of V2X vehicular applications in terms of quality of service.

[0027] However, even considering 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 increasing strain on telecommunications networks, particularly cellular networks.

[0029] Mobile network operators (MNOs) 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 growing.

[0031] Their application to QoS parameter prediction functions is, however, limited, due to the lack of publicly accessible, high-quality datasets for training predictive models, and the wide variability of situations encountered by vehicles. The document M. 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 accessible databases for such an application.

[0032] There is therefore a need to predict accurately and with good spatial granularity the evolutions 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 enables an application server deploying a V2X vehicular application to vehicles to anticipate variations in QoS parameters.

[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 zone 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; - determining 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, at least one prediction horizon and the M measured values ​​of the quality of service parameter.

[0035] Incorporating real-world measurements of QoS parameters into predictions of its evolution over a forecast horizon allows for consideration of the highly dynamic and variable constraints applied to a telecommunications network, such as a cellular network carrying C-V2X vehicular application data or a satellite network carrying V2X vehicular application data. Furthermore, the prediction can be performed for a specific location, identified by a point position or a zone, since the prediction model can accept a position or zone identifier as input data.

[0036] According to some embodiments, the method may further include transmitting 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, enabling greater robustness and continuity of the vehicle application. This allows for an enhanced user experience in vehicles using the vehicle application, and even improved safety associated with driving.

[0038] According to some 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 process 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 multiple forecast 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 map-based 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] Additionally, for K positions or zones within 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 the respective input data. These K*L predicted QoS parameter values ​​can then be published to the prediction publishing server.

[0045] 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 over various prediction horizons. This allows for the provision of a map accurately illustrating the dynamic evolution of the QoS parameter in the future.

[0046] According to some 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, predictions can be repeated 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] In some 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, measured QoS parameter values ​​can be centralized in a database and retrieved from vehicles operating within the telecommunications network's 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 some 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 shows good robustness against outliers (inliers and outliers).

[0054] For example, in the context of a C-V2X cellular telecommunications network, where inaccurate or noisy data is carried 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, preserving the overall accuracy associated with the prediction, latency, or other QoS parameters, such as bandwidth or the reliability of the cellular telecommunications network connection.

[0055] In addition to the RANSAC model, the Random Forest Estimator (RF) has inherent capabilities to handle complex data and build a set of numerous trees, each learning from a random sample of the training dataset. This approach enables robust predictions by aggregating the results from multiple trees, thus reducing the risk of overfitting and improving prediction reliability, even 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 QoS parameters, latency in particular, of a telecommunications network carrying data from V2X vehicular applications.

[0057] In addition or as an alternative, 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 T1 in what follows. Thus, the prediction model itself can be updated, making it possible to account for 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 T1 can advantageously be equal to one day.

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

[0060] Thus, training data can be updated based on the most recent training data, which improves 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 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.

[0062] Such a server is specifically 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 can use any programming language, and be in the form of source code, object code, or code somewhere 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 device, a hard 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 can be executed 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] In an example implementation, the present technique is implemented using software and / or hardware components. In this context, the term "device" or "module" may refer in this document to a software component, a hardware component, or a set of hardware and software components.

[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] Lare 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] Lare 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; Lare represents the steps of a current 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;

[0074] Lare 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 for illustrative purposes 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 can be satellite according to the invention.

[0077] The 120 cellular network can include a plurality of base stations, including a first base station 121.1 and a second base station 121.2 shown for illustrative purposes on the, 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 120 cellular network via one of the base stations of the 120 cellular network.

[0079] There is no restriction on the number N of vehicles accessing the 120 cellular network, which can include, at any given time, several hundred or thousands of vehicles. The number N is dynamic in that the position of each vehicle changes: a vehicle can enter or leave the radio coverage area of ​​a base station, and can thus enter or leave the overall radio coverage area of ​​the 120 cellular network, which is formed by the union of the radio coverage areas of the 120 cellular network's base stations.

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

[0081] Vehicles 110.1-110.N can access the 120 cellular network via 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 as an 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 then sent to the application server 131, which can build high-definition maps, such as 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 remote driving service that allows a remote operator to control a vehicle. Data captured by the vehicle, including onboard camera videos, is processed in 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 case of QoS parameter degradation, thus adapting the vehicle's speed and trajectory.

[0086] In a third application example, the V2X vehicle application is combined with a high-density convoy service, enabling vehicles to travel in close proximity to reduce fuel consumption and traffic congestion. In this third application example, predicting the evolution of a QoS parameter, particularly in the event of QoS degradation, is highly useful, allowing for autonomous vehicle coordination or requiring 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] 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 the, 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] Interface server 133 provides a service allowing access to predictions of at least one QoS parameter published by prediction server 134 in a prediction publishing server 135.

[0091] 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 for a 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 other 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] As an 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 position information, which can be a point position defined by GPS coordinates, for example, or which can be an identifier of an area, the area being a tile of a given level (the level indicating a zoom level, 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 can be, for example, level 22 of the Tile System of the Bing Maps web service. TM , according to which each tile has a size of 10 meters by 10 meters for example.

[0097] Storing latency values ​​in database 132 allows, as explained below: - the creation of training data for learning the prediction model described below. Specifically, the accumulated latency data can be used to train the prediction model, which is repeated at an initial frequency, corresponding to an initial period T1, which could be, for example, one day. The parameters of the prediction model can thus be updated regularly at this initial frequency; - the creation of 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, for example, between 50 and 200, for example, equal to 100.The prediction model can indeed be used at a second frequency given by the prediction server 134 to determine latency predictions at one or more given prediction horizons within a second period T2 associated with the second frequency. The second period T2 can be between 30 minutes and 2 hours, for example, 1 hour.

[0098] Presents 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 stage 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 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 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 latency values ​​for a large number of positions, for example, for all tiles within a given region.

[0102] At 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 T1, 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 T1 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 mentioned, the T1 period can be one day.

[0104] Thus, at the end of period T1, the process learning phase moves to stage 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 some of the data stored in 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: - structuring the timestamp data associated with latency values, in a predefined format, which allows consistency in the processing of timestamp data; - extracting temporal features from the timestamp data, the features may include the week of the year, the day of the week, the hour, the minute, the second, or even milliseconds.Such detailed extraction of temporal characteristics allows for high granularity in the analysis of temporal trends, enabling the detection of seasonal patterns, hourly fluctuations, or periodic behaviors in the data. This enhances the predictive model's ability to understand the temporal dynamics associated with latency (or another QoS parameter, such as bandwidth or connection reliability). It also includes management of missing latency values, replacing them with zero. This ensures continuity of latency values ​​over time and for all zones or positions. Indeed, the collected latency values ​​are inherently discontinuous because they depend on the presence or absence of vehicles in a given position or zone during a given period.Another way of handling missing values ​​can be provided according to the invention, for example by interpolating latency values ​​actually measured.

[0108] According to the invention, the trained prediction model takes 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] Incorporating the previous M latency values ​​into the prediction model allows for dynamic adaptation to real-time changes, significantly improving latency prediction accuracy. This approach enables 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 create a training dataset, the data from database 132 and processed in step 203 can be organized into several training sets (the training sets forming the training dataset), each training set comprising: - a position identifier, a prediction horizon value H, and M previous values ​​(relative to a given past time t). past ) latency for the position identifier, to form input data during model training; - 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 t) past +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 be able to constitute a test dataset and an evaluation dataset, the data from database 132 and processed during 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 evaluation set having the same composition as a training set, but being made up of separate data 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 (e.g., for all time slots in a day).

[0114] At a stage 204, the prediction server 134 trains the prediction model on the basis of the training data from the processing stage 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 through 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). This combination is particularly well-suited for handling QoS parameter specifics for V2X data transport and ensuring robust and reliable performance.

[0116] The RANSAC model exhibits good robustness to outliers (inliers and outliers). In the context of V2X cellular networks, where inaccurate or noisy data is carried 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 inherent capabilities to handle complex data and build a set of numerous trees, each learning from a random sample of the training dataset. This approach enables robust predictions by aggregating the results from multiple trees, thus reducing the risk of overfitting and improving prediction reliability, even 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 QoS parameters, latency in particular, of a telecommunications network carrying data from V2X vehicular applications.

[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 primary evaluation criterion can be the mean absolute error (MAE), which quantifies the average error between predicted and actual values ​​(ground truth). The MAE criterion provides a measure of the average magnitude of errors in predictions, thus allowing for an assessment of the model's overall accuracy.

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

[0122] (1)

[0123] In which is the predicted value of latency and y i is the actual measured value of latency, where n is an integer representing the number of predictions considered.

[0124] A second evaluation criterion, either as a complement to or an alternative to the first criterion, can 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 compared to the actual values. The MAPE criterion is evaluated using the following formula (2):

[0125] (2)

[0126] Using 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, can be a coefficient of determination, also called R 2The score, which measures the ability of the prediction model to explain the variance of the data around the mean. An R 2 A score close to 1 indicates that the prediction model fits the data well, capturing a large proportion of the variance in the actual values. However, an R 2 A high score may not always mean an accurate prediction in certain contexts. For a series of n predictions against the actual values, the R 2 The score is calculated according to formula (3) below, with the same notations as for formulas (1) and (2):

[0128] (3)

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

[0130] Thus, in 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 created in step 203, which allows the performance of the prediction model to be evaluated on new data.

[0131] At 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 prediction model's ability to accurately predict the QoS parameter, including latency, 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 stage 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 step 209, the optimal prediction model is stored or installed in the prediction server 134, for use during the current phase described below. The prediction model can, for example, be stored in a pkl format.

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

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

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

[0138] The results show that prediction models trained over shorter periods (one day, for example) perform better according to the MAE criterion, indicating a more accurate latency prediction, compared to models trained for longer periods. The same conclusion applies to the MAPE criterion. The third criterion R 2 The score remains high for all strategies, indicating that the ability to explain the variance of the data is similar regardless of the duration of the first period T1.

[0139] This presents 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 T1 of index j: at the end of the previous first period T1 of index j-1, the updated prediction model was stored in the prediction server 134, for use during the first period T1 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 T1, specifically so that several second periods T2 are included in the first period T1 with index j. For example, the second period T2 is equal to 1 hour, in which case if the first period T1 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] As an example, the prediction model is applied four times, for two tiles Tu1 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 identifier of tile Tu2; - the prediction horizon of 10 minutes; - 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 identifier of tile Tu2; - the prediction horizon of 30 minutes; - 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 identifier of tile Tu1; - the prediction horizon of 10 minutes; - the last M latency values ​​for tile Tu1 (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 Tu1 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 identifier of tile Tu1; - the prediction horizon of 30 minutes; - the last M latency values ​​for tile Tu1 (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 T1 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, where K and L are 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 step 303, the set of latency values ​​predicted at step 302 can be published to 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 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 t1, which is a time after the time at which the request is transmitted. The prediction time t1 can, 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 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 t1, if the request includes at least one prediction time. If the request 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 Tu1 and the prediction time t1, the interface server 133 returns to the application server 131 the predicted latency value corresponding to the tile Tu1, and to the horizon t0+10 or t0+30, depending on whether t1 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 predicted latency values ​​at step 312, the application server 131 can anticipate a latency variation, for example, if a threshold is crossed, and can take any anticipatory measures to prevent latency degradation from causing safety issues 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 including: - a threshold value; - one or more positions or tiles.

[0159] In this case, 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, interface server 133 sends a notification to 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 urban traffic optimization. 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 a 131 application server, 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 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, thus helping to prevent accidents by ensuring constant communication between vehicles. For example, connection reliability predictions (which in this case are one of the predicted QoS parameters) can be transmitted by an application server 131 to vehicles 110.1-110.N, which can then take preventative measures in the event of a predicted communication failure, such as activating autonomous safety systems.

[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, adapting the quality of service based on 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 to stream content in a format whose quality depends on bandwidth predictions, thus optimizing the quality of that 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 area.

[0167] In a fifth application, QoS parameter predictions enable real-time map updates. By anticipating 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, 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 then 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 issues before they affect vehicle performance.

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

[0170] Laillustre une structure du server de pronostic 134 selon des embodiments de l'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 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, are stored temporarily or permanently.

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

[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 in reference to the.

Claims

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. 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). 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). 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. 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. 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). 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. 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. 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. Method according to claim 9, wherein the prediction model is a RANdom SAmple Consensus type model, RANSAC, associated with a random forest type estimator. 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 (T1). Method according to claim 8 and claim 11, wherein for an update of the prediction model during a period (T1) of index j, the updated training dataset includes measured values ​​of the QoS parameter collected during a previous period (T1) of index j-1. Prediction server (134) of 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. 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. Computer-readable information carrier, and comprising instructions for a computer program according to claim 14.

Images