ABSTRACT

This paper explores the exploitation of Mobile/Multi-access Edge Computing (MEC) for Vehicle-to-Everything (V2X) communications. Certain V2X applications that aim at improving road safety require reliable and low latency message delivery. As the number of connected vehicles increases, these requirements cannot be satisfied by technologies relying on the IEEE 802.11p standard. Therefore, the exploitation of the 4th generation Long Term Evolution (LTE) mobile networks has been considered. However, despite their widespread use, LTE systems are characterized by high end-to-end latency since the messages have to traverse the core network. MEC addresses this problem by offering computing, storage and network resources at the edge of the network closer to the end-users. This paper aims at investigating the benefits MEC may offer toward implementing V2X communications. In this framework, simulation scenarios were examined concerning various V2X use cases implemented employing either LTE or MEC. The simulation results indicate a clear superiority of MEC over LTE, especially in the case of delivering critical data.

Keywords:

V2X, LTE, MEC, Simulation, ns3

1. Introduction

Road accidents cause thousands of fatalities to drivers, passengers and pedestrians every year. Despite efforts of every kind to improve road safety, the reduction rate in fatalities has been only slowly decreasing during the last years [1] . Among the various measures targeting at preventing accidents, the vehicles must be 1) aware of their environment and 2) capable of timely informing the drivers about imminent dangers [2] . However, the sensors that modern vehicles are equipped with do not fully guarantee the drivers’ safety, since they offer insufficient information about the type of traffic affecting the vehicles. Vehicle-to-everything (V2X) communications extend the drivers’ field of view, so that, in cooperation with sensors, they can drastically contribute to avoiding accidents. However, V2X communications do not only aim at improving road safety, but can also improve the quality of experience (QoE) of the drivers by offering additional information about the traffic conditions or the presence of points of interest.

The first standards developed to support V2X communications were based on the IEEE 802.11p standard concerning the physical and MAC layers. However, despite the long-term development of C-ITS (Cooperative-Intelligent Transport System) in Europe and of DSRC (Dedicated Short Range Communication) in the US, there are certain factors that delay the prevalence of the first standards in the market.

The main feature of the IEEE 802.11 series affecting its performance is the use of CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance) to control the access to the wireless medium. This algorithm has been proven to significantly exacerbate the delay and packet delivery ratio (PDR) as the data traffic exchanged by vehicles increases [3] . Therefore, although IEEE 802.11p was designed to serve applications transmitting critical data, such as Cooperative Awareness Messages (CAMs) and Decentralized Environmental Notification Messages (DENMs), it may struggle to achieve the Quality of Service (QoS) requirements, under high network load. The message delivery is also hampered by the use of the 5.9 GHz band, due to the high propagation loss, especially in non-line-of-sight scenarios.

The belated implementation of IEEE 802.11p is not due solely to its poor performance under high load and intense mobility. Providing vehicles with Vehicle-to-Infrastructure (V2I) and Vehicle-to-Network (V2N) services necessitates the very costly coverage of large geographical areas with special-purpose Road Side Units (RSUs). On the other hand, though On Board Units (OBUs) that support IEEE 802.11p are relatively inexpensive, the low complexity of the physical layer leads to poor spectral efficiency [4] . Moreover, as the majority of modern devices support standards characterized by significantly higher spectral efficiency (e.g. HSPA, LTE), their manufacturing costs have fallen significantly in recent years.

The weaknesses of IEEE 802.11p motivate researchers to seek alternative options that could support V2X communications. In this course, the exploitation of cellular systems, particularly LTE and LTE-Advanced (LTE-A) has been considered. The main advantage of centralized over ad-hoc communication is the avoidance of collisions, thanks to the scheduling performed by the evolved Node B (eNB). This feature, combined with the high spectral efficiency standards offered by 3 GPP, guarantees QoS even in cases of high user mobility [3] . Also, due to leveraging the already deployed LTE networks, the deployment of V2X applications will be less costly, as no special equipment will be required. For these reasons, the preference for LTE instead of IEEE 802.11p toward supporting V2X communications has been demonstrated by many regulatory organizations, such as the 5 G Automotive Association (5 GAA) [5] .

Since LTE was originally destined to provide mobile broadband services, several issues arise when LTE is used to serve other purposes such as V2X communications. The main limitation of LTE with regard to V2X is that the packets exchanged between two endpoints must traverse the core network of the Mobile Network Operator (MNO). This compulsory data transport hinders the immediate transfer of critical data, especially under network congestion.

In many V2X use cases, the data exchanged between the users and the network infrastructure is localized in a particular geographical area and does not need to be available to centralized data centers which are remotely dispersed over the Internet. Consequently, the performance of LTE networks when serving specific V2X applications can be significantly improved by using ETSI Mobile/Multi-access Edge Computing (MEC). MEC favors the development of delay and/or loss-sensitive applications, as it offers computing, storage and network resources at the edge of the network, i.e. closer to the end-users [6] . Applications can offload computing tasks to a MEC server, thus reducing both the message delivery latency and the traffic traversing the core network. In this course, in addition to other smart system applications [7] , V2X communications have been identified as one of the most important use cases for MEC.

This paper explores the possible benefits that MEC can offer in implementing V2X services related to road safety and traffic efficiency. In particular, a simulation model was created that approximates an LTE system enhanced with basic MEC capabilities, such as packet routing. The model was tested on serving telematics and emergency message delivery applications and its performance was evaluated with regard to the packet delivery latency and losses. In addition to vehicle users, pedestrian users were deployed to account for the external telecommunication traffic handled by the access and core networks. As intuitively expected, the simulations performed demonstrate that the delay reduction when utilizing MEC gets higher as the use of the core network gets more intense. As such, MEC is proven to enable the deployment of certain delay-sensitive applications which, otherwise, cannot be served efficiently by current LTE networks. Also, the simulations show additional benefits for other LTE services destined for pedestrian users. These benefits are attributed to the reduction of the total traffic traversing the core network.

The rest of the paper is organized as follows. Section 2 provides an overview of the cellular networks capable of hosting V2X services, focusing on the characteristics that can be favorably addressed by MEC. Section 3 elaborates on specific features of the ETSI MEC standards that may be proven useful when deploying V2X applications. Section 4 investigates via simulations the performance enhancement that MEC offers to particular V2X applications. Finally, Section 5 concludes the paper.

2. Using LTE for V2X Communications

Due to its centralized structure, LTE is appropriate for serving specific V2X use cases and the most suitable option, if not the only, for applications requiring Vehicle-to-Network (V2N) communication [8] . Certain V2X applications require that vehicles exchange periodic messages with a server which is capable 1) of estimating the traffic intensity and the drive times and 2) of providing drivers with the relevant information. Although RSUs using the IEEE 802.11p standard could also be used to serve a particular area, the eNBs of the practically ubiquitous LTE systems offer broader coverage without requiring new investments.

Numerous road safety applications can also be supported by existing wireless access technologies. Either ad-hoc or centralized communications are capable of supporting cooperative awareness among vehicles, offering minimum latency or enhanced reliability, respectively. The same applies to communications involving both vehicles and pedestrians, such as applications concerning Vulnerable Road Users (VRUs). However, the LTE option, already supported by all the latest smartphone models, outperforms its alternatives, as it does not require the purchase of any special device.

Moreover, though suitable to serve simple V2X applications, LTE may have difficulties in satisfying the strict specifications of mission critical applications, such as those concerning the delivery of emergency messages under high network traffic. This necessitates specific enhancements to the LTE architecture. The support for V2X communication has been studied and standardized in the latest 3 GPP releases, including recommendations for various V2X use cases and the relevant architecture enhancements.

The LTE architecture destined to support V2X exploits the Device-to-Device (D2D) mode of communication defined in previous releases. D2D communications allow two UEs (User Equipment) to communicate without involving an eNB. This is achieved employing the newly defined PC5 (or sidelink) interface, avoiding the conventional Uu interface which is used for the communication between a user and an eNB. Employing the sidelink interface, the end-to-end latency between two users is minimized due to 1) the elimination of the scheduling performed by the eNB and 2) the avoidance of the transport and the core networks. Therefore, the support of many delay sensitive V2X applications becomes feasible. Moreover, the use of the ad-hoc mode of communications enables service provision outside the coverage area of the eNBs, similarly to IEEE 802.11p, since, to become available to moving vehicles, the UEs have the option to select radio resources from a pre-defined pool.

Despite the advantages offered by the PC5 interface over the Uu interface, certain issues arise that are inherent to ad-hoc communications. On the one hand, when resource allocation is not performed by a single entity, QoS cannot be guaranteed; hence, the performance of the relevant applications may deteriorate if the number of users sharing the available resources is high. On the other hand, when an eNB is not involved in Vehicle-to-Vehicle (V2V) communications, collisions may occur, leading to service availability deterioration.

The ad-hoc mode of communications offered by the 3 GPP Release 14 seems capable of serving applications that are based on cooperative awareness, but it cannot support critical V2X applications. For instance, remote driving would not be feasible, as it requires seamless communication between a vehicle and a remote server with extremely low latency and ultra-high reliability in both directions, characteristics that are not achievable by current cellular technologies. Moreover, the uncertainty of message delivery over the PC5 interface renders the deployment of any degree of autonomous driving questionable, as reliable packet delivery is crucial for the safety of the passengers. The recently completed 3 GPP Release 15 and the upcoming Release 16 promise to overcome such issues by minimizing end-to-end latency, at the same time ensuring high reliability for mission critical communications. This can be achieved by utilizing Edge Computing and Network Function Virtualization, which enables network scalability, as it separates the network functions from the hardware they are running on.

Although 5 G is expected to dramatically influence many applications related to mobile communications, the deployment of 5 G networks is in the primary stages and it is most likely that the early 5 G deployments will not meet all the requirements defined for next generation cellular networks [9] . In this course, as MEC is an access technology agnostic platform which, by enabling applications to be deployed closer to vehicles and pedestrians, shortens the packet delay, promises to enhance existing V2X communications or enable new ones.

3. Enhancing LTE with MEC Capabilities

MEC deployment in LTE networks may enhance or enable a plethora of V2X applications. A MEC server will allow V2X applications to run closer to RSUs, vehicles and sensors, exchanging data with extremely low latency and high reliability. Furthermore, in order to become available to moving vehicles, local information can be transferred between neighboring MEC servers without having to move through the core network. Also, due to the capability offered by MEC hosts of locally processing the information collected by the various entities involved in V2X, MEC can significantly reduce the computational load which, otherwise, should be handled by the core network. Furthermore, MEC is also expected to enhance applications that are not hosted in the edge cloud, since, if necessary, only aggregated messages are sent to the centralized cloud. As verified by this paper, users receiving mobile broadband services will experience lower download latency, due to the reduction of the packet queue time as less communication traffic will be handled by the backhaul network.

To support MNOs to integrate MEC into their network, open specifications are being developed to set the benchmark for equipment vendors and application developers. The relevant standardization was initiated by ETSI with the establishment of the MEC Industry Specification Group (ISG) in 2014 [10] . The first publications specified the requirements that should be satisfied by MEC systems, as well as the MEC reference architecture, while the following ones deal with specific system features.

One of the primary features of the proposed MEC architecture is transparency to the underlying network. Therefore, a MEC host should be capable of serving nodes that support different radio access technologies, without been perceived as an intermediate entity. Though, initially, MEC was intended for 3 GPP networks, it has been proven useful for WiFi, as well as for fixed wireless access. For this reason, to more accurately express the extended objectives of the MEC ISG, the term MEC has been changed from “Mobile Edge Computing” to “Multi-access Edge Computing”. In this course, the next version of MEC specifications, which is currently under development, takes into consideration the support for non-3 GPP access technologies.

The proximity to users offered by MEC will significantly improve the performance of various location-based applications. In particular, V2X applications are expected to better exploit radio network information (RNI) and location-based services, as defined in ETSI GS MEC 012 and 013 respectively. As the majority of V2X applications are related to users located within specific geographical areas, MEC hosts installed at or closely located to the network edges will facilitate the localization of mobile devices and allow for the development of user-based applications. Furthermore, applications running on edge nodes have access to real-time network data, such as the radio channel status and cell utilization, and may use them to offer individualized services. In V2X, the provision of RNI services could be used for addressing issues related to mobility support and traffic coordination among vehicles [11] . The prediction of the QoS achievable in each cell will lead to solutions improving the selection process of both the serving cell and the MEC server, thus guaranteeing optimum QoE and seamless service coverage throughout the vehicle trajectories. QoS prediction can also enhance the performance of certain V2X applications running on a MEC host. For example, in the scenario of assisted overtaking, drivers should be aware in advance that their QoS will deteriorate; in this case, the application informs the driver to postpone the overtaking.

MEC will also contribute to the development of a number of V2X applications which cannot be served by the current generations of cellular technology. Road safety and VRU related applications are expected to immediately benefit from the reduced latency and increased reliability offered by MEC. Moreover, the availability of location-based and RNI services will enable advance driving assistance applications, such as downloading high-definition maps and updating them as the vehicles move. It should be noted that MEC will not be useful solely for mission critical V2X use cases. Storing information in local data caches will facilitate the provision of convenience services, such as local traffic information and software updates, which are only partially supported by the network architectures currently in use. Finally, MEC will greatly facilitate on-board infotainment services, which are expected to become more lucrative as the industry is moving toward fully autonomous vehicles [12] .

In addition to improving user experience and network utilization, the deployment of MEC promises many economic benefits for network providers as well as for third-parties. In the case of V2X, possible third-parties are automotive OEMs (Original Equipment Manufacturers), software and hardware vendors, and other automotive related businesses, such as car rentals, taxi fleets and public transport. Automotive and electronic equipment manufacturers have the opportunity to collaborate toward delivering services to end users employing MEC enhanced LTE networks. Due to the virtualized characteristics of MEC, content providers will have the capability of quickly developing new applications and deploying them using resources made available by cloud service providers. The development of such applications will be facilitated by the definition of appropriate open standards, APIs (Application Programming Interfaces) and SDKs (Software Development Kits).

4. Simulation Scenarios

To simulate traffic, the SUMO tool (Simulation of Urban Mobility) has been used. In particular, a section of Kifissias Avenue in Athens, Greece, approximately 2.5 km long was considered, as shown in Figure 1. Each simulation lasted 700 s and took into account vehicles moving toward both directions, whereas the incoming traffic from adjacent roads was ignored. With regard to the average number of connected vehicles (AvNu) and the vehicle density (Vede) in vehicles/km, three levels have been considered to represent traffic, namely low (AvNu = 127, VeDe = 50.8), medium (AvNu = 304, VeDe = 121.6) and high (AvNu = 510, VeDe = 204).

The traffic data generated by SUMO is introduced to the ns-3.28 tool in order to simulate the communications of vehicles with each other. To simulate how V2X communications are served by LTE systems, the ns3 LENA (LTE EPC Network simulAtor) module has been used, which provides the necessary tools to implement accurate representations of the LTE protocols stack and of the EPC (Evolved Packet Core) functions. In the simulated models, a single eNB node was installed at point A of Figure 1, having coverage of radius equal to 1250 m, and all vehicles were assumed to be equipped with an appropriate UE device. Vehicles entering the coverage area of the eNB node are immediately assigned to it. Once a vehicle leaves the coverage area, its communication with the eNB is terminated.

As, in addition to providing V2X services, the LTE network provides broadband services to pedestrian users in the same area, one of the goals of this paper is to examine how pedestrian users affect V2X communications. These broadband services are characterized by much higher data rates than the ones pertaining to V2X services. To simulate the pedestrian traffic, a certain number of UE nodes were placed on a straight line, at a gradually increasing distance from the eNB, ranging from 100 to 1000 m. Each pedestrian user transmits and receives 512 Byte long UDP packets via the eNB. An on-off model, characterized by random durations for the on and off states, was employed to represent the user uplink (UL) and downlink (DL) traffic. The average data rates assumed in each direction are: $R_{user}^{UL}=100\text{kbps}$ and $R_{user}^{DL}=1\text{Mbps}$ .

The parameters related to the LTE system considered in the simulation are given in Table 1. Though the fading model used in the simulations may not simulate accurately the channel conditions for the pedestrian users due to the high velocity of 60 km/h assumed, it has been adopted since the LENA module requires the same fading model for all the network nodes/users. The use of the EVA model led to pessimistic results, that is, higher latency and losses, for both the vehicles and the pedestrians, especially in the UL transmissions, where the transmit power is much lower than in the DL ones. To compensate for the extremely rapidly changing channel conditions adopted in the simulations for the pedestrian users, the transmit power of their UEs was increased so that the simulation produces results similar to those that would have resulted employing the Extended Pedestrian A (EPA) model with a velocity of 3km/h. Though simplified, the simulation option adopted is adequate for the purposes of this paper because: 1) it is the accuracy of the results concerning the vehicles that matters more, 2) the rapidly changing conditions in the pedestrian channels still yields slightly pessimistic results and 3) the choice of the fading model affects equally the results for the LTE and MEC cases, so the possible benefits of MEC will still be highlighted by the simulations.

4.1. The MEC and LTE Simulation Scenarios

The simulation scenario created to simulate V2X communications employing the LTE system, hereafter called the LTE scenario, is depicted in Figure 2(a), where the delay and the maximum data rate over the relevant links are also shown. The Serving/Packet-Gateway (S/P-GW) node communicates via point-to-point links with two servers, one to serve the vehicle traffic and one to serve the pedestrian traffic. DropTail queues of 100 packets were used for all links.

Since, so far, ns-3 simulation tools for MEC systems have not been developed, to simulate the MEC behavior, the scenario, hereafter called MEC scenario, depicted in Figure 2(b) has been created. In this scenario, a second V2X server was assumed, directly connected to the S/P-GW with a 10 Gbps link of zero delay. The same features were also assumed for the S1-U link. These two hypothetical links can be thought of as virtual interfaces, co-located with the eNB. Routing is controlled by a specific node, which in a practical scenario could be a high-speed SDN switch [13] . Messages originating from/destined for vehicles are exchanged between the eNB and the local V2X server with practically no delay. Moreover, due to the high speed characterizing the links involved, these messages are also not affected by the pedestrian communication traffic.

In contrast to the LTE scenario, in the MEC scenario, the remote V2X server does not communicate directly with the vehicles. Its role is to periodically update the information available at the local server, so that the latter becomes aware of the traffic outside the examined area. On the other hand, the local server sends aggregated messages to the core network, so that the remote V2X server can produce more accurate traffic data regarding the service area.

Access to the Internet is provided by a router, which has a role similar to that of the central S/P-GW of the core network. The router is connected to the local S/P-GW via a link causing the same delay as the one caused by the S1-U link of the LTE scenario which is equal to 10 ms. In the simulations, the speed over this link was intentionally reduced, so that the behavior of this link is close to that of S1-U (see Figure 2(b)). Each pedestrian user exchanges 512 Byte packets with the Internet server. Among these 512 Bytes, 28 Bytes are added due to the IP and UDP headers. Moreover, the S1-U interface adds a total of 40 Bytes to each packet (20 IP + 8 UDP + 12 GTP), all of which are removed when the packets are sent to the Internet. Therefore, to keep the pedestrian traffic unaffected under the MEC scenario, the rate of the link connecting the S/P-GW to the router should be reduced from 100 Mbps to:

$R=100\text{Mbps}\cdot \left(512+20+8\right)/\left(512+20+8+40\right)=93.1\text{Mbps}$ . (1)

Having done the above rate adaptation, the proposed model approximates MEC deployment over the S1-U interface [14] . The rationale behind this adaptation is further justified in Section 4.4 where the performance improvement of mobile broadband services is examined.

4.2. General Traffic Information

The applications examined in this paper are based on possible V2X use cases of LTE suggested by 3GPP [15] . In telematic use cases, a simplified version of which is studied in this section, the vehicles receive periodic messages from a V2X server at a low data rate, since they only need traffic information in the form of text messages. The vehicles also need to transmit periodic messages to the server, which are assumed to contain 1) information about their own state concerning their location, velocity or size and 2) data received from sensors. Thus, to simulate the exchange of data with the V2X server, two UDP streams were assumed for every connected vehicle. Following the relevant 3 GPP recommendations [15] , the DL message payload and the message transmission frequency were set equal to 1000 Bytes and to 1 Hz, respectively. The corresponding numbers for the UL messages were 300 Bytes and 10 Hz, respectively.

Figure 3(a) depicts the simulation results concerning the average delivery latency (AVL) of the periodic messages sent to the vehicles by the V2X server, local or remote respectively, assuming a low mobility level. The reduction in AVL achieved by the MEC scenario is indeed larger than the fixed latency caused by the transport and the core networks which is equal to 20 ms. Moreover, as the number of nearby pedestrian users involved increases, so does the gap between the curves corresponding to the LTE and MEC scenarios, since the capacity limitations of the backhaul link does not affect the packet transfer under the MEC scenario.

Due to constraints in the queue size, packet losses also occur in the LTE system, as shown in Figure 3(b). Though it may seem that the MEC scenario is unaffected by such losses, as in this case packets are subjected to zero queue time, in order to fully evaluate the MEC scenario performance, the traffic moving through the local and the remote V2X servers should also be taken into account. In the MEC scenario, an additional packet flow is active between the two servers to update the local traffic information. The packet size and transmission frequency of this flow are identical to those sent to every vehicle. Instead of calculating the packet delivery ratio of this flow, the average local data renewal latency is determined from:

${\bar{D}}_{\text{renew}}=\left(t_N-t_1\right)/\left(N-1\right)$ (2)

where N is the number of received packets and t_i (i = 1, N) is the time when the i-th packet was received. The above quantity is plotted in Figure 4. As expected, as the number of users increases, the local data is renewed at a slower rate. In a practical scenario, however, the local server would be capable of processing the packets received from the vehicles and, consequently, delivering traffic data to them with minimum losses. Hence, the effect of the backhaul link on the application performance would be moderated.

Though the reduction in latency offered by MEC is significant, the requirements concerning use cases related to traffic information are not strict (e.g. the tolerable latency is 500 ms). Therefore, the MNOs can provide this type of services, without having to invest in MEC deployment.

4.3. Emergency Message Delivery

The imperative necessity for using MEC in V2X applications is justified when mission critical use cases, especially those related to road safety, are considered. In this course, in addition to handling traffic information destined for vehicles, the two models under consideration were compared in the framework of delivering emergency messages destined for vehicles, say the DENMs. In the simulations, a total of 11 simulated events have been considered, where a randomly located vehicle transmits an 800 Byte emergency message to notify all nearby vehicles. As soon as the server responsible for the relevant processing receives this message, it sends an appropriate message to all the vehicles located within a range of 500 m from the vehicle-sender. Figure 5(a) depicts the mean end-to-end delivery latency of emergency messages as well as the range of values among the 11 events considered. As the maximum tolerable latency in emergency use cases is 100 ms, in contrast to the scenario examined in Section 4.2, the data transfer via the transport and core networks causes a severe QoS deterioration to an intolerable level. In a more accurate scenario, however, the latency caused by the backhaul and core networks would be a random variable [16] , an even greater variation between the LTE and MEC performance is expected.

In all the cases examined so far, a favorable case for the network, i.e. the one of low traffic density, was examined. Figure 5(b) shows how the traffic intensity

affects the delivery of DENMs. In these simulations, the number of pedestrians was set equal to 80, as this is the maximum value that yields acceptable results in the case of low traffic. Though in both models under comparison the mean latency and its dispersion get larger when more messages are transmitted, the MEC scenario yields acceptable (i.e. less than 100 ms) end-to-end latency values even under high traffic conditions.

4.4. High-Definition Maps

A message transmission frequency from the V2X server of 1Hz is considered adequate for delivering traffic data via text messages. However, real-time provisioning of high-definition local maps may require high data rates, in many cases up to hundreds of kbps per user. Figure 6(a) shows results concerning higher DL message transmission frequencies that require considerably higher data rates. The traffic level assumed is low and the number of pedestrians is set equal to 80. It is evident that the MEC scenario performance is once again unaffected by the increasing network traffic, whereas, to update local maps in real-time, the LTE option may have to struggle to deliver data at acceptable rates.

Finally, how a potential deployment of V2X applications would affect the rest of the users of a cellular network was examined. In Figure 6(b), the average downlink latency experienced by pedestrian users is plotted with respect to the message transmission frequency. When the communication traffic created by the vehicles is low, the pedestrian traffic is unaffected by the presence of the MEC server, since the total traffic traversing the backhaul network is low and can be easily handled by the available bandwidth. This result also explains the S1-U rate adaptation performed in Section 4.1. However, as the use of the backhaul network in the LTE scenario increases, the MEC scenario exhibits a clear superiority, even though the applications used by the pedestrian users are not hosted in the MEC server. It should be noted that, due to the simplistic model used for the pedestrian traffic and the limitations of the fading model described earlier in Section 4, the exact latency values depicted in Figure 6(b) do not accurately represent an actual mobile broadband scenario. However, the difference between the LTE and the MEC scenario is clearly demonstrated.

5. Conclusions

The simulation results suggest that, although LTE is able to timely deliver traffic data to vehicles, high congestion in the backhaul and core networks might lead to inevitable packet losses, which can be offset by the computing capabilities of a MEC server. However, the true merit of MEC is justified when delivering emergency messages. Even in cases of low traffic density, LTE systems may lead to inefficient delivery of messages to vehicles, especially when the volume of data produced by the pedestrian users becomes high. On the other hand, the use of MEC achieves end-to-end emergency message delivery in less than 100 ms, regardless of the number of connected vehicles. Moreover, the MEC scenario examined in this paper proved to effectively mitigate the impact of connected vehicles on the experience of existing users.

In the future, it is worth studying the contribution of multicast transmission to vehicular communications, such as E-MBMS (Enhanced Multimedia Broadcast Multicast Service), and its possible co-existence with MEC. The co-location of the E-MBMS functions and the MEC server is expected to facilitate the provision of high-resolution maps, resulting in even smaller delivery latencies and a smaller impact on mobile broadband applications. Moreover, a plethora of issues remain to be examined before MEC is implemented in a real network. For example, the capital and operational expenditure of the proposed solution need to be thoroughly considered, before MNOs proceed to invest in MEC deployment. As to the performance evaluation, the development of more accurate models for simulation software will not only enable researchers to examine other innovative applications but will also be useful to MNOs toward exploring the integration of MEC into their network. Finally, in addition to more sophisticated simulation scenarios, a theoretic analysis of V2X scenarios employing MEC could also be performed in order to obtain more accurate results and better evaluate the models used in the simulations.

Conflicts of Interest

The authors declare no conflicts of interest regarding the publication of this paper.

Cite this paper

Grammatikos, P.V. and Cottis, P.G. (2019) A Mobile Edge Computing Approach for Vehicle to Everything Communications. Communications and Network, 11, 65-81. https://doi.org/10.4236/cn.2019.113006

References