Simulation of a Prototype 5G Network Integrating D2D Communication and MEC Technology ()
1. Introduction
The 5G is a new generation of mobile telecommunications [1] [2] , which aims to offer sufficient speeds and very high bandwidth. Its mission is to meet the multiple needs of users by offering a smart, fast and efficient network. We will first briefly recall the evolution of the generations of the technology before theoretically studying 5G technology with its challenges and requirements.
The Next Generation Mobile Network (NGMN) leverages the structural separation of hardware and software, as well as the programmability offered by SDN and NFV [3] . As such, the 5G architecture is a native SDN/NFV architecture covering aspects ranging from devices, (mobile/fixed) infrastructure, network functions, value enabling capabilities and all the management functions to orchestrate the 5G system. APIs are provided on the relevant reference points to support multiple use cases, value creation and business models.
The architecture comprises three layers and an E2E (End to End) management and orchestration entity (Figure 1).
The architecture and principles described above (Figure 1) lead to emergence of a set of key components and terminology of a 5G system, as described below:
• The hardware and software basis for the 5G network , the 5G infrastructure (5GI);
• The 5G end-to-end management and orchestration entity (5GMOE);
• The associated 5GI (including any relaying devices) and the 5GMOE supporting communication to and from 5G devices (5GN);
• The equipment used to connect to a 5G network to obtain a communication service, 5G Divice (5GD);
• A communications system comprising a 5G network and 5G devices (5GSYS);
• A 5G slice (5GSL) is a set of 5GFs and associated device functions set up within the 5G system that is tailored to support the communication service to a particular type of user or service.
![]()
Figure 1. 5G network slices implemented on the same infrastructure [3] .
Device-to-device (D2D) communication [4] [5] is one of the most important technologies in 5G. It allows for the fast transmission of large amounts of data between two devices. In this part, we will discuss some aspects to better understand the technology: its categorization, classification, challenges, and applications.
The Multi-access Edge Computing (MEC) standard [5] [6] enables the movement of IT traffic and services from a centralized cloud to an edge network closer to the customer. Instead of sending all the data to be processed to a cloud, the edge network analyzes, processes, and stores the data. This reduces latency and brings real-time performance to high-bandwidth applications.
2. Architecture Model of a 5G Network Integrating D2D and MEC
We consider a device-to-device communication scenario in a 5G cellular network integrating a Multi-Access Edge Computing (MEC) server next to the base station (gNodeB) (Figure 2).
In traditional cellular architecture, the operator still manages data and signaling for communications. The data sent from the EU travels through the entire network to the data center. As a result, latency is likely to be quite long. Today, with the arrival of IoT, the amount of data has become very important. This can cause congestion at the base station and central servers of the network. Thus, to unload BS, D2D technology is one of the promising solutions. Unfortunately, communication will sometimes require operator control. To lighten the load on the core grid, a new MEC technology is being considered.
For a solution to all these problems, we propose a device-to-device (D2D) communication scenario with the MEC server in a 5G cellular network. Our architecture, shown in Figure 2, consists of an access network and a central office network. It consists of a base station (gNodeB), users (car 1, 2, 3), a MEC server and a gateway (UPF) to connect it to the RAN of the core network. The base station controls communication by managing signaling and interference. The MEC server is placed next to the BS to provide data to the devices. It plays the role of the cloud that is in the core network. The MEC server stores the data and then does the calculations for good communication between the devices.
To carry out this work, we had to use the following material and logistical equipment (Table 1).
![]()
Figure 2. Architecture model of our prototype.
![]()
Table 1. Material and logistical equipment.
3. Key Performance Indicators (KPIs)
The key performance indicators (KPIs) of our solution are related to the uRLC (ultra Reliable Low latency Communication) use case, i.e. for ultra-reliable and low-latency communications.
3.1. Latency
It is the contribution of the radio network to the time between the time the source sends a packet and the time the destination receives it (in ms). It is defined as the one-way time that one must successfully deliver a package/message.
This requirement is defined at fine devaluations in the eMBB and uRLC use case.
The minimum requirements for user plane latency are [7] :
- 4 ms for eMBB;
- 1 ms for uRLC.
3.2. Mobility Downtime
Mobility downtime is the shortest system-loaded time that a user terminal cannot exchange user plane packets with a base station during transitions.
This requirement is defined at fine devaluations in the eMBB and uRLC usage scenarios. The minimum requirement for mobility downtime is 0 ms.
3.3. Reliability
Reliability refers to the ability to transmit a given amount of traffic in a predetermined amount of time with a high probability of success [8] .
4. Simulation and Results
4.1. Description of the Simulation Tools
OMNeT++ is a well-known discrete-event simulation framework that can be used to model virtually any type of network, such as wired, wireless, on-chip, sensor, photonics, and more are modules, which can be simple or compound. The modules exchange messages via connections connecting their doors, which act as interfaces. A network is a special compound module with no doors to the outside world that sits at the top of the hierarchy. Connections must follow the module hierarchy: with reference to Figure 3, single module 3 cannot connect directly to module 2, but must instead pass through the compound module door.
We installed the OMNeT 5.6.2 software and then downloaded and integrated the following libraries: Inet and Simu5G.
Inet is a template library for OMNeT++. It implements models of many components of a communication network, such as communication protocols, network nodes, connections, and so on. Inet contains templates for the Internet stack (TCP, UDP, IPv4, IPv6, OSPF, IEEE 802.11, etc.), and supports the development of custom mobility models, QoS architecture, and more.
Simu5G is a simulator for 5G New Radio and LTE/LTE-A networks for OMNeT++ and Inet Frameworks.
Simu5G simulates the data plane of the 5G RAN and core network. It enables the simulation of 5G communications in frequency division duplexing (FDD) and time division duplexing (TDD) modes, with heterogeneous gNB (macro, micro, pico, etc.), possibly communicating via the X2 interface to support transfer and intercellular interference coordination. Device-to-device communications and dual connectivity between an eNB (LTE Base Station) and a gNB (5G NR Base Station) are also available.
To run OMNeT, we use the following command in Figure 4: omnetpp.
4.2. Simulation
➢ Network Configuration
We have configured our architecture on the file written in Network Description Language (NED) and the parameter values are written in the initiation file (INI) see appendix. Figure 5 shows the architecture configured in the *.ned file.
![]()
Figure 3. Connecting the OMNet++ module.
![]()
Figure 5. Network architecture in Omnet.
➢ Network Simulation
After the network was launched, there was an initialization phase for communication between the devices (Figure 6).
➢ Results
In Figure 7, we first see the communication between the devices without the intervention of the operator.
Figure 8 shows the communication between the devices under the control of the base station, i.e. the operator. Packets from each device will travel to the central cloud (CC) via the base station (gNodeB1).
With a large amount of data, there will be congestion in the core network. So to offload the latter, we introduce the MEC server next to the users to store the data (Figure 9). This will make it possible to have communication with very low latency and to have a central network offload.
Figure 9 shows the communication between the devices, the base station (gNodeB) and the MEC server.
We notice the communication between the users and the MEC through the BS works well because the packets coming from the 3 UEs will pass through the station and then go to the MEC server. So our MEC server plays the same role as the central server. It can be applied in emergency communications such as V2I (Car to Infrastructure), Public Safety, etc.
The performance of the MEC server is shown in Figure 10 where it shows the average reaction time of each server entity such as the Mobile Edge Host (MEH), the Mobile Edge Application (MEA).
The average transmission time from gNodeB to ME Host (Mobile Edge Host) and vice versa is 0.19 ms and ME Virtualization is 0.11 ms.
Figure 11 shows the wait time for the 3 packets to be processed by the MEC server.
This histogram shows the time it took for the 3 packets from the users to complete. The time is 3 ms for the 3 users packets, including 1 ms per packet. Thus, the objective of 5G as a function of latency time is achieved (1 ms).
![]()
Figure 7. Communication entre les appareils (D2D).
![]()
Figure 8. D2D-gNodeB-cloud central communication.
![]()
Figure 9. D2D communication with SB and COM intervention.
![]()
Figure 10. The average transmission time of MEC features.
![]()
Figure 11. Packet transmission time from source to destination.
![]()
Figure 12. Illustration of the reliability and authenticity of the network.
![]()
Figure 13. Illustration of the reliability and authenticity of the network.
To see the reliability of the network, let’s look at the results of the data sent by the machine 192 .168.4.1 and received by 10.0.0.2 (Figure 12).
We see that the data that was in the queue (39 bytes) when sending is all received (39 bytes).
The following results (Figure 13) also show that the packets sent are received 100% with the same size and length.
These results show us the system’s ability to transmit a given amount of traffic in a predetermined amount of time with an almost 100% probability of success. This shows the authenticity and reliability of this network.
5. Conclusion
This last chapter was instructive both in terms of the OMNeT software and the implementation of the 5G network. First, we found a network architecture that meets our proposed solution. Then, we simulated the prototype in the OMNeT software with the Simu5G library. We visualized the results and showed that the application of our solution, in the uRLLC use case, was successful because we have high reliability and low latency in the communication system.
Acknowledgements
Many thanks to the Research Commission of the Training and Research Unit for Applied Sciences and Technology (UFR SAT) of the Gaston Berger University of Saint-Louis and to the African Centre of Excellence for Mathematics and ICT (CEAMITIC) of the UGB for their financial support.