本文确定了MEC特性，以便为V2X应用程序提供必要的支持。
Key issues：
简单总结：MEC在V2X场景中的主要问题有三个：
1.移动性管理和QoS的保证：这个需要根据车辆的轨迹预测来提前预测QoS好的接入点。
2.多运营商之间的低时延协调：存在运营商是否公用底层网络两种情况，但是哪一种情况都需要MEC host之间 最好存在直连链路以保证MEC之间的低时延。
3.上行可能存在拥塞：需要和vehicle进行协调，根据统计到信息预测可能拥堵时，让vehicle仅仅上传 safety信息 ，暂停上传convenience或其他信息。
1.mobility and QoS support
Solution：predictive QoS support
根据汽车 的导航信息，很容易得到汽车接下来的路线，可用小区(例如,基于ETSI GS MEC 012 [ i.4 ]中定义的RNI服务以及对RNIS的改进)的QoS性能估计可以帮助优化基站和ME主机的选择，使UE车辆在轨迹上始终能够接收到最大的QoE。
应用状态信息迁移到目标表MEC主机是在连接到MEC主机之前完成的，即可以实现对MEC的预测
ETSI GS MEC 012 [ i.4 ]中规定了几个与切换预测相关的特性：·
- CellChangeNotification - -提供UE切换过程状态的更新；信息从切换过程的准备阶段直到整个过程的完成。
- •MeasRepUeNotification -通过与不同触发事件相关的UE测量报告提供进一步的细节。此外，还定义了RAB和S1承载信息的若干特征，这些特征可能有助于QoS预测。然而，当前ETSI GS MEC 012 [ i.4 ]中规定的特征不足以允许对QoS性能(例如延迟、吞吐量、可靠性等)进行必要的预测。期待进一步的增强。
Key issue 2: low latency communication support with multi-operator operation
在多运营商场景下，车辆之间的端到端时延受到移动运营商网络之间数据流量对等点位置的限制。这些对等点通常位于移动运营商网络的中心位置。为了实现多运营商情况下大多数时延敏感的V2X应用的低时延通信，在运营商网络之间启用本地对等点的水平通信路径是必不可少的。下面的条款考虑了在这种情况下不同的商业模式。
Solution：
第一种方式： 运营商之间共享底层网络和MEC 系统；
第二种方式：底层网络由不同运营商运营。
有两种情况：1 ) MEC系统由运营商共享，需要与两个底层网络进行低时延通信；2 )相邻的MEC主机属于不同的运营商，需要对等点之间的低时延通信路径。无论如何，这些案例都需要网络规划，特别是交通网络规划中所涉及的运营商之间的协调。
一个标准化的V2X服务API有利于提高托管在不同MEC主机(在一个MEC系统中或者在不同的MEC系统中)和外部云中的V2X应用之间的协调性。
Key issue 3: communication traffic coordination with vehicles
互联车辆从CAN (控制器区域网络)、歧管雷达、摄像头、行车记录仪等产生车辆信息等各种数据，这些数据将通过无线网络上传，以便在条款5中提供V2X服务。这些信息对通信有不同的要求，但至少需要实时通信的紧急信息应该传输到低延迟、高可靠性的云端。例如，与安全性相关的信息应优先传输，而与便利性相关的信息可能在紧急情况较低的情况下处理。车辆通行拥堵会导致无线网络拥堵，从而降低V2X服务质量。一般而言，LTETM上行无线资源相对于下行无线资源有限，容易出现无线网络拥塞。为了克服这一问题，将车辆与MEC系统进行协调以控制无线网络拥塞是至关重要的。
Solution：
inform communication traffic congestion to vehicles
V2X业务的各种信息可以通过无线网络进行传输。如果MEC系统能够预测性地识别出基于车辆转移的无线网络拥塞，并将其通知给车辆，则非实时信息的传输可以暂停，以便优先处理紧急的V2X通信。无线网络拥塞与车辆数量成正比，由ETSI GS MEC 012 [ i.4 ]中规定的RNI服务进行关联。对连接到基站的车辆数量的估计有助于预测无线网络拥塞。图6.3 . 2.1 - 1给出了对射电单元格的传输映射估计的一个例子。入出口率表示车辆从/到相邻无线小区的速率，可根据ETSI GS MEC 012 [ i.4 ]和ETSI GS MEC 013 [ i.5 ]中规定的位置计算。它还依赖于道路结构，当预测到无线网络拥堵时，可以向拥堵区域内的车辆发出警告。收到警告的车辆避免或推迟传输不需要实时通信的信息。它有助于以低延迟和高可靠性的方式传递紧急信息。此外，如果MEC系统能够识别传输的数据内容以及对无线网络拥塞的影响，则MEC系统可以指示车辆应该暂停数据传输或者暂停多长时间。车辆经过拥堵区域后，悬挂的数据将被传输。
Gap：
下面是几个有助于预测无线网络拥塞的特征。ETSI GS MEC 012 [ i.4 ]规定：
- CellChangeNotification - -提供关于UE切换过程状态的更新；该信息可用于入出口速率。
- RabInfo -提供了一个小区中的活跃UE的数量，有助于预测无线网络拥塞。
- ETSI GS MEC 013 [ i.5 ]规定了以下特征：用户信息-提供了UE所在的地理坐标。这也可能通过识别能够映射到道路结构的详细UE位置来提高预测的准确性。
如前所述，目前没有向UE提供通知的接口。
总结：
- [ CR-1 ]建议MEC系统支持从网络向车辆提供反馈信息的能力，以支持V2X功能，这有助于预测通信信道当前是否可靠。
- [ CR-2 ]建议MEC系统支持在各种连接参数(如潜伏期、PER、信号强度... ...)发生变化时，向车辆提供从网络到车辆的质量相关信息。
- [ CR-3 ]建议MEC系统通过支持通过不同接入技术或网络或移动运营商连接的道路用户之间的V2X信息交换来提供互操作性。
- [ CR-4 ]建议MEC系统实现V2X移动/用户的多运营商运营，以在全国范围内跨接入网覆盖和不同运营商的边界提供服务连续性。
- [ CR-5 ]建议MEC系统在多运营商场景下提供互操作性，使不同系统中的MEC应用能够安全地相互通信，以便在没有蜂窝覆盖( 3GPPTM域外域名)的情况下也能在多运营商系统中实现同步。
- [ CR-6 ]建议MEC系统在多运营商场景下提供互操作性，使MEC应用能够与3GPP网络中与V2X相关的核心网络逻辑功能( e.g. V2X控制功能)进行安全通信，并从3GPP网络中收集PC5 V2X相关信息( e.g. PC5配置参数)。
确定了3个关键问题，并讨论了潜在的解决方案，这些问题涉及到预测性QoS支持和多运营商支持的关键建议。考虑到条款6中提供的差距分析，因此建议：
- •在ETSI GS MEC 002 [ i.9 ]中捕获作为规范需求的合并建议。
- •增强RNI API ( ETSI GS MEC 012 [ i.4 ])，以便允许对QoS性能(例如延迟、吞吐量、可靠性等)进行必要的预测。
- •标准化V2X服务API有利于提高多供应商、多网络运营商和多接入环境中托管在不同MEC主机和外部云中的V2X应用程序之间的协调和互操作性。