*In the v2.1.1 published MEC030 specification, the referenced data type, LinkType, is missing from the GS.
* However, MEC 030 has an on-going WI for maintenace targeting for v2.2.1. This specificaiton is expected to be baselined this WI's latest draft.
*Final draft of MEC030 specification v2.1.10 is used for the development of V2X Information Service in the MEC Sandbox as the published version 2.2.1 was not available at the time of implementation.
* However, version 2.1.10 is a Final Draft and is considered ready for publication after the approval process. In any case, it is highly unlikely for data models and HTTP methods of MEC030 API endpoints to change going from final draft to the published version 2.2.1 of GS MEC030.
| /provide_predicted_qos <br><br>This resource is queried to provide predicted QoS of a vehicular UE based on potential route information. Each UE may have different potential routes under consideration. Route information includes route origin and destination; intermediate waypoints may also be provided. Estimated journey start time and arrival time at each location may also be provided. | Input is a set of potential routes that a vehicle may consider for a journey. <br><br> Note: potential routes having the same origin and destination, journey start time and differing intermediate waypoints may be considered as alternatives of a specific journey. <br><br> Output is the predicted QoS, in the form of Reference Signal Received Power (RSRP) and/or Reference Signal Received Quality (RSRQ), as defined in ETSI TS 136 214. The network emulation algorithms used to calculate RSRP and RSRQ for MEC 012 RNIS are used to caluclate perdicted QoS for MEC 030. | As a Sandbox user, I can use this call to receive predictions of the radio signal conditions expected to be experienced during journey time for different potential routes I may consider (for the same trip or for different planned trips). <br><br> The Link Performance Prediction (LPP) may be integrated as it plays the role of a Prediction Function (PF) which receives route information (route locations, optionally with visiting time information) as input and provides predicted RSRP and RSRQ values for each location of the communicated potential route as output. <br><br>LPP is available in open-source and can be found here: https://github.com/intel/lpp-network-trace <br><br> _LPP integration into the MEC Sandbox and the underlying AdvantEDGE open-source edge emulator is TBD._
|
| /provide_predicted_qos <br><br>This resource is queried to provide predicted QoS of a vehicular UE based on potential route information. Each UE may have different potential routes under consideration. Route information includes route origin and destination; intermediate waypoints may also be provided. Estimated journey start time and arrival time at each location may also be provided. | Input is a set of potential routes that a vehicle may consider for a journey. <br><br> Note: potential routes having the same origin and destination, journey start time and differing intermediate waypoints may be considered as alternatives of a specific journey. <br><br> Output is the predicted QoS, in the form of Reference Signal Received Power (RSRP) and/or Reference Signal Received Quality (RSRQ), as defined in ETSI TS 136 214. The network emulation algorithms used to calculate RSRP and RSRQ for MEC 012 RNIS are used to caluclate perdicted QoS for MEC 030. | As a Sandbox user, I can use this call to receive predictions of the radio signal conditions expected to be experienced during journey time for different potential routes I may consider (for the same trip or for different planned trips). <br><br> The Sandbox has an internal Prediction Function (PF) which receives route information (route locations, optionally with visiting time information) as input and provides predicted RSRP and RSRQ values for each location of the communicated potential route as output. <br><br>The Prediction Function considers diurnal traffic patterns for each zone based on estimated user activity in those areas throughout the day and the predicted QoS values are adjusted accordingly if the visiting time information is also provided in the request depending on the congestion status in those areas around the requested time.
