y-specific information partitions, together with the SW package versions running at each of the vehicles of interest, as inputs for decision making. The outcome of the decision process may be a recommendation to trigger SW update, which is then communicated to the client application in the vehicle, which: a. Has a planned route with suitable radio conditions for the triggered action (e.g. SW downloaded); b. Has outdated SW subject to upgrade. 5. If the planned journey route changes, the procedures are repeated, starting from step 1. Figure 6.4.14 illustrates the scenario described above. We assume that a MEC host is col- located with a road-side unit (RSU), for example, a gNB. We further assume that three vehicles, V1, V2, and V3, are under cellular coverage, where vehicles V1 and V2 have the same planned route from location A to location B, but V3 has planned a different route from location C to location D. Focusing on the use case of SOTA/FOTA updates, we additionally assume that vehicle V1 has the latest version (e.g. v1.3) of a specific SW package installed, whereas vehicles V2 and V3 have an outdated version (e.g. v1.2) installed. The procedure may work as follows: 1. V1 reports its planned journey from location A to location B to the MEC host via trans- mission to the gNB-type RSU; it also informs that it has v1.3 of the SW package installed. 2. V2 reports its planned journey from location A to location B to the MEC host via trans- mission to the gNB-type RSU; it also informs that it has v1.2 of the SW package installed. 3. V3 reports its planned journey from location C to location D to the MEC host via trans- mission to the gNB-type RSU; it also informs that it has v1.2 of the SW package installed. References Location D V3 running V 1.2 Location C RSU/gNB Location A V2 running v1.2 Location B V1 running v1.3 Figure 6.4.14 Cooperative decision making for SOTA/FOTA updates with MEC. 4. All three vehicles report radio signal quality measurements, together with location infor- mation and time stamps; V1 upload