Academia.eduAcademia.edu

Figure 8 – uploaded by Stuart Clayman

See full PDFdownloadDownload figure
FIGURE 5. Forwarding, base station and MEC host.

Figure 5 Forwarding, base station and MEC host.

Related Figures (18)

TABLE 1. Some relevant tools comparable to eXP-RAN. Among the reviewed tools, none of them covers all the requirements (as shown in Table 1). The Very Lightweight Network & Service Platform (VLSP) [12] is a tool that can emulate/simulate different aspects in SDN and virtualized environments. Slice Controller [13] was introduced as a com- panion software for slicing resources of a virtual data center, where an isolated instance of VLSP can act as a Virtual Infrastructure Manager (VIM) of each slice. Since this soft- ware is focused on data centers, network slicing is simplified, while network characteristics, such as generic topologies, link capacity, and propagation delay are not properly represented. Service representation involves the creation of applications in Java, which is the programming language used to develop this software. Monitoring is quite flexible, but was not designed with slicing support as a goal.
TABLE 1. Some relevant tools comparable to eXP-RAN. Among the reviewed tools, none of them covers all the requirements (as shown in Table 1). The Very Lightweight Network & Service Platform (VLSP) [12] is a tool that can emulate/simulate different aspects in SDN and virtualized environments. Slice Controller [13] was introduced as a com- panion software for slicing resources of a virtual data center, where an isolated instance of VLSP can act as a Virtual Infrastructure Manager (VIM) of each slice. Since this soft- ware is focused on data centers, network slicing is simplified, while network characteristics, such as generic topologies, link capacity, and propagation delay are not properly represented. Service representation involves the creation of applications in Java, which is the programming language used to develop this software. Monitoring is quite flexible, but was not designed with slicing support as a goal.
FIGURE 1. eXP-RAN layers.
FIGURE 1. eXP-RAN layers.
FIGURE 2. Example of an eXP-RAN topology. The Infrastructure layer was designed following the stan- dards terminology defined by ETSI — European Telecommu- nications Standards Institute [26]. This layer is responsible for the emulation of the four major network elements in a 5G RAN, which are: (i) edge computing resources (e.g., MEC hosts), (ii) base stations (e.g., 4G/eNodeB, 5G/gNB), (iii) forwarding nodes, and (iv) links. Fig. 2 shows an example of a topology that can be emulated in eXP-RAN with all four types of network elements. Thus, in eXP-RAN, a network topology is emulated by nodes (MEC host, base station, and forwarding nodes) and links.
FIGURE 2. Example of an eXP-RAN topology. The Infrastructure layer was designed following the stan- dards terminology defined by ETSI — European Telecommu- nications Standards Institute [26]. This layer is responsible for the emulation of the four major network elements in a 5G RAN, which are: (i) edge computing resources (e.g., MEC hosts), (ii) base stations (e.g., 4G/eNodeB, 5G/gNB), (iii) forwarding nodes, and (iv) links. Fig. 2 shows an example of a topology that can be emulated in eXP-RAN with all four types of network elements. Thus, in eXP-RAN, a network topology is emulated by nodes (MEC host, base station, and forwarding nodes) and links.
FIGURE 3. eXP-RAN workflow and system modules. Single arrows represent mandatory flow; arrows only with dashed lines identify user inputs; arrows composed by dots and dashed lines represent optional flow; rectangles identify the system modules and circles represent input files.
FIGURE 3. eXP-RAN workflow and system modules. Single arrows represent mandatory flow; arrows only with dashed lines identify user inputs; arrows composed by dots and dashed lines represent optional flow; rectangles identify the system modules and circles represent input files.
TABLE 2. Ethernet-based link profiles (proc. delay = 5 (ys), packet size = 1518 Bytes).
TABLE 2. Ethernet-based link profiles (proc. delay = 5 (ys), packet size = 1518 Bytes).
FIGURE 4. eXP-RAN type of nodes. This subsection details how we implemented the three types of nodes, available in eXP-RAN, to emulate a network topol- ogy. Fig. 4 illustrates the main elements of each node.
FIGURE 4. eXP-RAN type of nodes. This subsection details how we implemented the three types of nodes, available in eXP-RAN, to emulate a network topol- ogy. Fig. 4 illustrates the main elements of each node.
its combined resource of 20 cores, 40 threads, and a boost clock up to 3 GHz, the server could not fulfil the scenarios we wanted to emulate. Given that the real scenarios can easily scale up to more than one hundred nodes (varying from MEC hosts, base stations, and forwarding nodes), each one requiring one CPU core to either generate or process 2.5 Gbps of throughput, our hardware was not able to fulfil these requirements. The Benchmarker module in eXP-RAN was designed with this limitation in mind. The idea is that the Bench- marker configures the tool, so that eXP-RAN can only use the amount of computer resources provided by the user, while generating an emulation very close to real-world performance. To do that, the Benchmarker needs the fol- lowing information: the throughput that should be gen- erated, and the accepted packet loss (i.e., how much
its combined resource of 20 cores, 40 threads, and a boost clock up to 3 GHz, the server could not fulfil the scenarios we wanted to emulate. Given that the real scenarios can easily scale up to more than one hundred nodes (varying from MEC hosts, base stations, and forwarding nodes), each one requiring one CPU core to either generate or process 2.5 Gbps of throughput, our hardware was not able to fulfil these requirements. The Benchmarker module in eXP-RAN was designed with this limitation in mind. The idea is that the Bench- marker configures the tool, so that eXP-RAN can only use the amount of computer resources provided by the user, while generating an emulation very close to real-world performance. To do that, the Benchmarker needs the fol- lowing information: the throughput that should be gen- erated, and the accepted packet loss (i.e., how much
TABLE 3. Capacity and latency requirements for each split, considering 150 Mbps DL and 50 Mbps UL demand.
TABLE 3. Capacity and latency requirements for each split, considering 150 Mbps DL and 50 Mbps UL demand.
FIGURE 7. Packet loss as a function of the generated throughput. small advantage to the older hardware that has a more modest general configuration. The emulation becomes more realistic as the processing power of the hardware running the emulator increases. In this case, as the CPU clock speed increases, the packet loss decreases and the aggregated throughput recommended by the Benchmarker for the emulation also increases.
FIGURE 7. Packet loss as a function of the generated throughput. small advantage to the older hardware that has a more modest general configuration. The emulation becomes more realistic as the processing power of the hardware running the emulator increases. In this case, as the CPU clock speed increases, the packet loss decreases and the aggregated throughput recommended by the Benchmarker for the emulation also increases.
FIGURE 8. Emulated topology randomly generated. Using the Model Adapter module, described in Section III-B, we created six FluidRAN emulated scenarios for evaluation - labelled from A to F. All scenarios are based on the topology shown in Fig. 8. The blue node is the Central Unit (CU), the (eleven) black nodes represent the Remote Units (RUs) / Base Stations (BSs), and the red nodes are the forwarding nodes. Based on the optimization model output, VRAN consists of different functional splits of the BSs indicated in the Fig. 8. Part of the VNFs are run in each RU and the rest are run in the CU. Since each pair RU-CU may have a different split, we labeled each one as a different VRAN service. There are eleven vVRAN services because there are eleven pairs CU-RU, i.e., eleven BSs, which are independently defined by the optimization model. However, many VRAN services have the same functional split because the FluidRAN model compacts Table 3 to only three options, as described above.
FIGURE 8. Emulated topology randomly generated. Using the Model Adapter module, described in Section III-B, we created six FluidRAN emulated scenarios for evaluation - labelled from A to F. All scenarios are based on the topology shown in Fig. 8. The blue node is the Central Unit (CU), the (eleven) black nodes represent the Remote Units (RUs) / Base Stations (BSs), and the red nodes are the forwarding nodes. Based on the optimization model output, VRAN consists of different functional splits of the BSs indicated in the Fig. 8. Part of the VNFs are run in each RU and the rest are run in the CU. Since each pair RU-CU may have a different split, we labeled each one as a different VRAN service. There are eleven vVRAN services because there are eleven pairs CU-RU, i.e., eleven BSs, which are independently defined by the optimization model. However, many VRAN services have the same functional split because the FluidRAN model compacts Table 3 to only three options, as described above.
TABLE 4. Emulated FluidRAN scenarios comparison. Scenarios from B to F do not necessarily have the same shared links in common, since the randomly generated RAN topology and the flows distribution of the VRAN services do not favor this sort of comparison. These scenarios are also differentiated from one another by the place where the MEC service is consumed, i.e., where the mobile users demanding the MEC service are positioned. The positioning of the users affects the MEC service routing and so does the amount of links that are shared between the MEC and the vRAN services.
TABLE 4. Emulated FluidRAN scenarios comparison. Scenarios from B to F do not necessarily have the same shared links in common, since the randomly generated RAN topology and the flows distribution of the VRAN services do not favor this sort of comparison. These scenarios are also differentiated from one another by the place where the MEC service is consumed, i.e., where the mobile users demanding the MEC service are positioned. The positioning of the users affects the MEC service routing and so does the amount of links that are shared between the MEC and the vRAN services.
FIGURE 10. Impact of the MEC service consumed by 100 users. When the number of MEC users increases significantly, it is expected that the impact tends to be notably higher in the vVRAN services. However, the RAN topology and the flow distribution of the VRAN services make it difficult to predict where and the extent of this impact. Again, eXP-RAN pro- vides valuable information through an easy manner. Fig. 10 presents the results when the MEC service is accessed by 100 users, while the remaining configuration is kept identical, as with the previous tests. All the scenarios with the MEC service emulation exhibit severe packet loss and all the VRAN services are affected in at least one scenario, but it is not trivial the way that the MEC service impacted the vRAN services. For example, the ‘VRAN 2’ service is not the most affected service as previously, while the scenarios B and C present the highest packet loss. Differently from the result of the previous tests, under this load, it would be useful to recompute the FRD problem again, including the MEC service as a new VNF.
FIGURE 10. Impact of the MEC service consumed by 100 users. When the number of MEC users increases significantly, it is expected that the impact tends to be notably higher in the vVRAN services. However, the RAN topology and the flow distribution of the VRAN services make it difficult to predict where and the extent of this impact. Again, eXP-RAN pro- vides valuable information through an easy manner. Fig. 10 presents the results when the MEC service is accessed by 100 users, while the remaining configuration is kept identical, as with the previous tests. All the scenarios with the MEC service emulation exhibit severe packet loss and all the VRAN services are affected in at least one scenario, but it is not trivial the way that the MEC service impacted the vRAN services. For example, the ‘VRAN 2’ service is not the most affected service as previously, while the scenarios B and C present the highest packet loss. Differently from the result of the previous tests, under this load, it would be useful to recompute the FRD problem again, including the MEC service as a new VNF.
FIGURE 9. Impact of the MEC service consumed by 10 users.
FIGURE 9. Impact of the MEC service consumed by 10 users.
FIGURE 11. Topology for the emulation of the video service. in Fig. 11. Thus, both network slices share the same physical infrastructure shown in Fig. 11, which involves: a MEC host, three base stations, and three forwarding nodes. This topology could be built by modifying the Infrastructure Description file generated previously and providing it as input to the Infrastructure Manager module. The Service Description file must be created for each tenant and then provided to the Service Manager module.
FIGURE 11. Topology for the emulation of the video service. in Fig. 11. Thus, both network slices share the same physical infrastructure shown in Fig. 11, which involves: a MEC host, three base stations, and three forwarding nodes. This topology could be built by modifying the Infrastructure Description file generated previously and providing it as input to the Infrastructure Manager module. The Service Description file must be created for each tenant and then provided to the Service Manager module.
FIGURE 12. Video stream results.
FIGURE 12. Video stream results.
Related topics:
Computer ScienceRadio Access networkEdge Computing
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved