Academia.eduAcademia.edu

Figure 52 – uploaded by Valerio Frascolla

See full PDFdownloadDownload figure
Figure 5-12 presents the service portfolio. Data services and planning services complement the core machine learning services. The services are divided in five categories. Data services and planning services are used to complement machine learning services offered in the portfolio. The categories are explained briefly as follows:

Figure 5 -12 presents the service portfolio. Data services and planning services complement the core machine learning services. The services are divided in five categories. Data services and planning services are used to complement machine learning services offered in the portfolio. The categories are explained briefly as follows:

Related Figures (95)

Dissemination level: Public
Dissemination level: Public
Dissemination level: Public
Dissemination level: Public
Dissemination level: Public
Dissemination level: Public
Dissemination level: Public
Dissemination level: Public
Dissemination level: Public
Dissemination level: Public
2.1 5G Services, Applications and Use Cases QoS, etc.) but also some extended attributes such as the level of resiliency, management anc control desired. The provider must take care of meeting the requirements and managing the available resources.
2.1 5G Services, Applications and Use Cases QoS, etc.) but also some extended attributes such as the level of resiliency, management anc control desired. The provider must take care of meeting the requirements and managing the available resources.
2.2 Network Slicing
2.2 Network Slicing
Figure 2-2: Multi-tenancy in legacy networks and slicing-enabled networks [2-17] .2.1. Network Slicing Context, Definition and Motivation A number of definitions slicing as partitions of connectivity resources were used in the last ten years within the context of research into distributed and federated testbeds and in future internet research [2-7]. More recently in research and SDOs revised definitions were used [2-8][2-9][2- 10][2-11][2-12][2-13]. specific use case, e.g., bandwidth, latency, processing, and resiliency, coupled with a business purpose. Following the 5G verticals paradigm [2-14], an infrastructure provider will assign the required resources for a network slice, that in turn realizes each service of a service provider portfolio (e.g., the vehicular URLLC network slice, the factory of the future URLLC network slice, the health network mMTC network slice, see Figure 2-3. Hence, a network slice comprise: a subset of virtual network infrastructure resources and the logical mobile network instance with the associated functions using these resources. It is dedicated to a specific tenant that, in turn, uses it to provide a specific telecommunication service (e.g. eMBB). The decoupling between the virtualised and the physical infrastructure allows for the efficient scaling-in/out/up/down of the slices, suggesting hence the economic viability of this approach that can adapt the used resources on demand. The network slices will span the whole protocol stack from the underlying (virtualised) hardware resources up to network services and applications running on top of them. This approach is aligned with the industry and telecom perspective, towards 5G [2-15], in order: to meet the demands of extremely diverse use cases. Although, the infrastructure resources coulc be shared among several parallel network slices, every provider may use a specific contro! framework or/and a specific cloud management system and, in addition, all the configuratior effort and fine-tuning of the components may be left to users. Advanced orchestration anc automation is required to release the configuration burden from users and to enable an integratec end-to-end solution. Network Slicing is an end-to-end concept covering all network segment: including radio networks, wire access, core, transport and edge networks. It enables the concurrent deployment of multiple end-to-end logical, self-contained and independent shared o1 partitioned networks on a common infrastructure platform. From a business point of view, a slice includes a combination of all the relevant network resources, network functions, service functions and enablers required to fulfill a specific busines: case or service, including OSS and BSS. The hehavionr af the network clice realized via network clice nctance(c) From the network purpose. Following the 5G verticals paradigm [2-14], an infrastructure provider will assign the
Figure 2-2: Multi-tenancy in legacy networks and slicing-enabled networks [2-17] .2.1. Network Slicing Context, Definition and Motivation A number of definitions slicing as partitions of connectivity resources were used in the last ten years within the context of research into distributed and federated testbeds and in future internet research [2-7]. More recently in research and SDOs revised definitions were used [2-8][2-9][2- 10][2-11][2-12][2-13]. specific use case, e.g., bandwidth, latency, processing, and resiliency, coupled with a business purpose. Following the 5G verticals paradigm [2-14], an infrastructure provider will assign the required resources for a network slice, that in turn realizes each service of a service provider portfolio (e.g., the vehicular URLLC network slice, the factory of the future URLLC network slice, the health network mMTC network slice, see Figure 2-3. Hence, a network slice comprise: a subset of virtual network infrastructure resources and the logical mobile network instance with the associated functions using these resources. It is dedicated to a specific tenant that, in turn, uses it to provide a specific telecommunication service (e.g. eMBB). The decoupling between the virtualised and the physical infrastructure allows for the efficient scaling-in/out/up/down of the slices, suggesting hence the economic viability of this approach that can adapt the used resources on demand. The network slices will span the whole protocol stack from the underlying (virtualised) hardware resources up to network services and applications running on top of them. This approach is aligned with the industry and telecom perspective, towards 5G [2-15], in order: to meet the demands of extremely diverse use cases. Although, the infrastructure resources coulc be shared among several parallel network slices, every provider may use a specific contro! framework or/and a specific cloud management system and, in addition, all the configuratior effort and fine-tuning of the components may be left to users. Advanced orchestration anc automation is required to release the configuration burden from users and to enable an integratec end-to-end solution. Network Slicing is an end-to-end concept covering all network segment: including radio networks, wire access, core, transport and edge networks. It enables the concurrent deployment of multiple end-to-end logical, self-contained and independent shared o1 partitioned networks on a common infrastructure platform. From a business point of view, a slice includes a combination of all the relevant network resources, network functions, service functions and enablers required to fulfill a specific busines: case or service, including OSS and BSS. The hehavionr af the network clice realized via network clice nctance(c) From the network purpose. Following the 5G verticals paradigm [2-14], an infrastructure provider will assign the
Figure 2-4: Architecture functional layers
Figure 2-4: Architecture functional layers
Figure 2-6: Options for slice multiplexing and their relation to the OSI protocol stack [2- 26] This yields several options for the design of network slices, ranging from standalone slices with own HW and spectrum, to slices that are completely unaware of the resources they are using and hence have no (direct) control on the resource scheduling. The differences between these network slicing options will be reflected by the templates of the respective network slices.
Figure 2-6: Options for slice multiplexing and their relation to the OSI protocol stack [2- 26] This yields several options for the design of network slices, ranging from standalone slices with own HW and spectrum, to slices that are completely unaware of the resources they are using and hence have no (direct) control on the resource scheduling. The differences between these network slicing options will be reflected by the templates of the respective network slices.
Figure 2-7: Example of RCMs with shared and independent functions On this basis, inter-RCM RRM is a key aspect to fulfil the business-driven service-level agreements (SLAs) by exploiting the slice-specific QoS enforcement. At RAN level, an efficient sharing of scarce radio resources among the network slices is the key challenge. The efficient multi-slice RRM is realized with the help of the AIV agnostic Slice Enabler (AaSE), which is responsible for monitoring and enforcing SLAs for individual slices by mapping the abstract slice specific SLA definition to the QoS policies, see Figure 2-8a. It monitors the status of the SLAs and adapts QoS parameters accordingly. It could, for example, in case of a network slice with a latency guarantee, assign to all corresponding data flows that are part of it, a certain QoS class. Using Allocation and Retention Priority (ARP), the importance of individual data streams can be configured. It is then a task of the multi-AIV resource mapping, interference management, and real-time resource mapping to realize the corresponding QoS. More details on the pronosed solution as well as simulation results can be found in [2-28]. On this basis, inter-RCM RRM is a key aspect to fulfil the business-driven service-level agreements (SLAs) by exploiting the slice-specific QoS enforcement. At RAN level, an efficient sharing of scarce radio resources among the network slices is the key challenge. The efficient multi-slice RRM is realized with the help of the AIV agnostic Slice Enabler (AaSE), which is responsible for monitoring and enforcing SLAs for individual slices by mapping the abstract slice specific SLA definition to the QoS policies, see Figure 2-8a. It monitors the status
Figure 2-7: Example of RCMs with shared and independent functions On this basis, inter-RCM RRM is a key aspect to fulfil the business-driven service-level agreements (SLAs) by exploiting the slice-specific QoS enforcement. At RAN level, an efficient sharing of scarce radio resources among the network slices is the key challenge. The efficient multi-slice RRM is realized with the help of the AIV agnostic Slice Enabler (AaSE), which is responsible for monitoring and enforcing SLAs for individual slices by mapping the abstract slice specific SLA definition to the QoS policies, see Figure 2-8a. It monitors the status of the SLAs and adapts QoS parameters accordingly. It could, for example, in case of a network slice with a latency guarantee, assign to all corresponding data flows that are part of it, a certain QoS class. Using Allocation and Retention Priority (ARP), the importance of individual data streams can be configured. It is then a task of the multi-AIV resource mapping, interference management, and real-time resource mapping to realize the corresponding QoS. More details on the pronosed solution as well as simulation results can be found in [2-28]. On this basis, inter-RCM RRM is a key aspect to fulfil the business-driven service-level agreements (SLAs) by exploiting the slice-specific QoS enforcement. At RAN level, an efficient sharing of scarce radio resources among the network slices is the key challenge. The efficient multi-slice RRM is realized with the help of the AIV agnostic Slice Enabler (AaSE), which is responsible for monitoring and enforcing SLAs for individual slices by mapping the abstract slice specific SLA definition to the QoS policies, see Figure 2-8a. It monitors the status
Figure 2-8: AaSE for multi-slice RRM (a) and simulation results (b) In Figure 2-9, one additional evaluation study is shown for the scheduler dimensioning and placement of RRM functionalities. For different slices we may have different requirements for spectral efficiency and different RRM centralization requirement. For the example shown in a practical scenario (see Annex A.11 of [2-28]), for uMTC (termed also as URLLC) more than lbps/Hz is an acceptable level, while for eMBB more than 2.5bps/Hz spectral efficiency is required. Thus, we select the level of centralization considering these requiremen s and the interference levels (e.g., for cell edge users we might need centralization to benefit from multi- connectivity at cell edges). The per-AP Spectral Efficiency for this particular simulation setup can be seen in Figure 2-9. As we can observe from the CDF of spectral efficiency, for he uMTC slice we do not need to centralize RRM, unless the users are near the cell-edge (e.g., 5 percentile), since the spectral efficiency KPI is fulfilled. On the other hand, for eMBB the higher the centralization the higher gain we can achieve.
Figure 2-8: AaSE for multi-slice RRM (a) and simulation results (b) In Figure 2-9, one additional evaluation study is shown for the scheduler dimensioning and placement of RRM functionalities. For different slices we may have different requirements for spectral efficiency and different RRM centralization requirement. For the example shown in a practical scenario (see Annex A.11 of [2-28]), for uMTC (termed also as URLLC) more than lbps/Hz is an acceptable level, while for eMBB more than 2.5bps/Hz spectral efficiency is required. Thus, we select the level of centralization considering these requiremen s and the interference levels (e.g., for cell edge users we might need centralization to benefit from multi- connectivity at cell edges). The per-AP Spectral Efficiency for this particular simulation setup can be seen in Figure 2-9. As we can observe from the CDF of spectral efficiency, for he uMTC slice we do not need to centralize RRM, unless the users are near the cell-edge (e.g., 5 percentile), since the spectral efficiency KPI is fulfilled. On the other hand, for eMBB the higher the centralization the higher gain we can achieve.
Figure 2-9: CDF of Spectral Efficiency — Comparison of different splits
Figure 2-9: CDF of Spectral Efficiency — Comparison of different splits
The SDM-O has a complete knowledge of the network managing the resources needed by all the Slices of all tenants. This enables the SDM-O to perform the required optimal configuration in order to adjust the amount of used resources. While the SDM-C directly interfaces with dedicated NFs, the SDM-X controls shared NFs. Together with the SDM-O the SDM-X constitutes the inter-slice management. The inter-slice management and orchestration is a key-feature of the novel 5G architecture as it fosters and supports multi-service and multi-tenancy systems.
The SDM-O has a complete knowledge of the network managing the resources needed by all the Slices of all tenants. This enables the SDM-O to perform the required optimal configuration in order to adjust the amount of used resources. While the SDM-C directly interfaces with dedicated NFs, the SDM-X controls shared NFs. Together with the SDM-O the SDM-X constitutes the inter-slice management. The inter-slice management and orchestration is a key-feature of the novel 5G architecture as it fosters and supports multi-service and multi-tenancy systems.
Figure 2-11: Relationship between stakeholders and Mobile Service Provider in the core place
Figure 2-11: Relationship between stakeholders and Mobile Service Provider in the core place
Figure 2-13: Possible domain ownerships of main functional blocks using the layers introduced before [2-26]
Figure 2-13: Possible domain ownerships of main functional blocks using the layers introduced before [2-26]
Figure 2-15: 5G Logical and Physical Network Softwarisation and Programmability Viewpoint The following Figure 2-15 summarizes the 5G softwarisation and programmability abstractions in the form of a high-level logical design at the network level.
Figure 2-15: 5G Logical and Physical Network Softwarisation and Programmability Viewpoint The following Figure 2-15 summarizes the 5G softwarisation and programmability abstractions in the form of a high-level logical design at the network level.
Figure 2-16: The perceived 5G Business and Management Ecosystem Once the underlying infrastructure programmable, there need to exist components to use that programmability to manage and orchestrate those resources within a domain, across domains, as well as across providers. Providers in the new business ecosystem are not only limited to operators but could be specific technology providers, e.g. factory floors wanting to rent out their resources.
Figure 2-16: The perceived 5G Business and Management Ecosystem Once the underlying infrastructure programmable, there need to exist components to use that programmability to manage and orchestrate those resources within a domain, across domains, as well as across providers. Providers in the new business ecosystem are not only limited to operators but could be specific technology providers, e.g. factory floors wanting to rent out their resources.
Figure 2-17 Domains in the 5G security architecture. NB: Lines from slice domains down to Infrastructure Domains denote that VNFs allocated to a slice make use of certain physical resources.
Figure 2-17 Domains in the 5G security architecture. NB: Lines from slice domains down to Infrastructure Domains denote that VNFs allocated to a slice make use of certain physical resources.
Figure 2-18: Strata of 5G Security Architecture
Figure 2-18: Strata of 5G Security Architecture
complemented with a few new Security Control classes relevant for 5G networks. The exact functions and mechanisms to enforce a specific security control are left for consideration in the detailed design phase.
complemented with a few new Security Control classes relevant for 5G networks. The exact functions and mechanisms to enforce a specific security control are left for consideration in the detailed design phase.
Table 3-1: Key radio access functions in 5G
Table 3-1: Key radio access functions in 5G
Table 3-2: RAN-specific API Calls Dissemination level: Public
Table 3-2: RAN-specific API Calls Dissemination level: Public
Figure 3-1: Considered UP/CP Split Constellations [3-1][3-2]
Figure 3-1: Considered UP/CP Split Constellations [3-1][3-2]
Figure 3-2: Hierarchical CP Design in 5G RAN For non-standalone mm-wave, to minimise interruption times or ideally even to avoid interruptions and to guarantee reliability, we foresee that multi-connectivity essential or rather a fundamental feature in a 5G-access network. Moreover, a U (MC) will be an E must be able to detect and receive from multiple mmAPs to ensure the possibility of MC, link monitoring, and fast selection. To provide redundant coverage, multiple mmAPs are placed wit 5G coverage area, building per UE “serving cluster”. Under the considera hin the low-band ion of backhaul capabilities in current and future low-band radio access nodes, i.e., to relax backhauling requirements with respect to 5G low band access points, we further propose a s and low data rate PDCP. We split the data layer in high data rate and low data plit between high rate flows and in accordance with that, and we define high rate PDCP-H typically hosted in an ed ge cloud and low rate PDCP-L hosted in the low band 5GAP. 5GAP additionally hosts RRC and manages the mm- wave cluster incl. traffic steering from PDCP-H to mmAPs.
Figure 3-2: Hierarchical CP Design in 5G RAN For non-standalone mm-wave, to minimise interruption times or ideally even to avoid interruptions and to guarantee reliability, we foresee that multi-connectivity essential or rather a fundamental feature in a 5G-access network. Moreover, a U (MC) will be an E must be able to detect and receive from multiple mmAPs to ensure the possibility of MC, link monitoring, and fast selection. To provide redundant coverage, multiple mmAPs are placed wit 5G coverage area, building per UE “serving cluster”. Under the considera hin the low-band ion of backhaul capabilities in current and future low-band radio access nodes, i.e., to relax backhauling requirements with respect to 5G low band access points, we further propose a s and low data rate PDCP. We split the data layer in high data rate and low data plit between high rate flows and in accordance with that, and we define high rate PDCP-H typically hosted in an ed ge cloud and low rate PDCP-L hosted in the low band 5GAP. 5GAP additionally hosts RRC and manages the mm- wave cluster incl. traffic steering from PDCP-H to mmAPs.
Figure 3-3: eDSA MAC Framework Architecture and functional blocks
Figure 3-3: eDSA MAC Framework Architecture and functional blocks
Figure 3-4: Hierarchical CP Design in 5G RAN pest cell, since DC wu transmit packets also on links with relatively bad quality and, thereby, aking resources from users who could utilize the link better. An alternative to DC is Fast UP Switching (FS), where the CP is connected to both AIVs at the same time but the UP is only transmitted via one of the AIVs. If the CP is connected to both the LTE access node and the 5G access node, no signaling is required when switching AIV, and the UP switch can be almost instantaneous. The need on the frequency of the radio link feedback between AN-I and AN-O, and accordingly the speed of FS depends on the radio frequency and speed of the UE in order to follow the fast fading. An example set of results are provided in Figure 3-4 [3-10]. It is shown that at low load DC performs better; yet, on the high load FS outperforms DC since DC is impacted by the increased interference due to the simultaneous connection to two AIVs.
Figure 3-4: Hierarchical CP Design in 5G RAN pest cell, since DC wu transmit packets also on links with relatively bad quality and, thereby, aking resources from users who could utilize the link better. An alternative to DC is Fast UP Switching (FS), where the CP is connected to both AIVs at the same time but the UP is only transmitted via one of the AIVs. If the CP is connected to both the LTE access node and the 5G access node, no signaling is required when switching AIV, and the UP switch can be almost instantaneous. The need on the frequency of the radio link feedback between AN-I and AN-O, and accordingly the speed of FS depends on the radio frequency and speed of the UE in order to follow the fast fading. An example set of results are provided in Figure 3-4 [3-10]. It is shown that at low load DC performs better; yet, on the high load FS outperforms DC since DC is impacted by the increased interference due to the simultaneous connection to two AIVs.
Figure 3-5: Network layout for LTE-NR tight interworking simulations [3-13] m distributed in a 2x2 km2 area, with the taller building located in the centre, as shown Figure 3-5. The evaluations compare legacy LTE at 2.6 GHz with 40 MHz bandwidth to standalone NR at 15 GHz with 100 MHz bandwidth, as well as non-standalone deployments with co-located LTE and NR.in a dense urban deployment consisting of 1442 buildings with heights varying between 16 and 148 m distributed in a 2x2 km2 area, with the taller building located in the as shown Figure 3-5. The traffic is served by a macro network with an inner and an outer layer. The inner macro layer contains 7 sites deployed on the building rooftops with 200 m inter-site distance and the outer macro layer contains 28 sites deployed at 30 m height with 400 m inter-site distance. The traffic is generated by deploying 10000 users distributed uniformly randomly in the area with 80% of the traffic generated inside the buildings. Each user downloads a single packet with a size depending on the traffic load.
Figure 3-5: Network layout for LTE-NR tight interworking simulations [3-13] m distributed in a 2x2 km2 area, with the taller building located in the centre, as shown Figure 3-5. The evaluations compare legacy LTE at 2.6 GHz with 40 MHz bandwidth to standalone NR at 15 GHz with 100 MHz bandwidth, as well as non-standalone deployments with co-located LTE and NR.in a dense urban deployment consisting of 1442 buildings with heights varying between 16 and 148 m distributed in a 2x2 km2 area, with the taller building located in the as shown Figure 3-5. The traffic is served by a macro network with an inner and an outer layer. The inner macro layer contains 7 sites deployed on the building rooftops with 200 m inter-site distance and the outer macro layer contains 28 sites deployed at 30 m height with 400 m inter-site distance. The traffic is generated by deploying 10000 users distributed uniformly randomly in the area with 80% of the traffic generated inside the buildings. Each user downloads a single packet with a size depending on the traffic load.
To avoid boundary issues from users located near the edge of the simulation area, the evaluation only considered the performance of users located within the central 1x1 km2. The users outside this area still generate traffic but are only considered as a source of interference. The end-user performance of the evaluated systems is illustrated in Figure 3-6. Figure 3-6: Simulation results for LTE at 2.6 GHz standalone, NR at 15 GHz standalone, and non-standalone deployment with LTE at 2.6 GHz and NR at 15 GHz. (a) 5th percentile; (b) median; (c) 95th percentile user throughput.
To avoid boundary issues from users located near the edge of the simulation area, the evaluation only considered the performance of users located within the central 1x1 km2. The users outside this area still generate traffic but are only considered as a source of interference. The end-user performance of the evaluated systems is illustrated in Figure 3-6. Figure 3-6: Simulation results for LTE at 2.6 GHz standalone, NR at 15 GHz standalone, and non-standalone deployment with LTE at 2.6 GHz and NR at 15 GHz. (a) 5th percentile; (b) median; (c) 95th percentile user throughput.
Figure 3-7 shows the proposed RRM architecture where (RRM and cRRM are deployed.
Figure 3-7 shows the proposed RRM architecture where (RRM and cRRM are deployed.
Figure 3-8: High-level RRM framework. Note the abstraction layer, a critical component of the design separating higher-level algorithms from internal components.
Figure 3-8: High-level RRM framework. Note the abstraction layer, a critical component of the design separating higher-level algorithms from internal components.
Figure 3-9: Group-based initial access gains in terms of average collision rate decrease [3-1] From the evaluation results depicted in Figure 3-9 it is observed that using the group based system access reduces the collision rate significantly. Additionally, the average initial access delay (i.e., random access, random access response, terminal identification, and contention resolution) is reduced, as shown in Figure 3-9, since the devices are accessing the system with fewer collisions and thus experience fewer retransmissions.
Figure 3-9: Group-based initial access gains in terms of average collision rate decrease [3-1] From the evaluation results depicted in Figure 3-9 it is observed that using the group based system access reduces the collision rate significantly. Additionally, the average initial access delay (i.e., random access, random access response, terminal identification, and contention resolution) is reduced, as shown in Figure 3-9, since the devices are accessing the system with fewer collisions and thus experience fewer retransmissions.
Figure 3-10: Low frequency-assisted initial access to a heterogeneous network.
Figure 3-10: Low frequency-assisted initial access to a heterogeneous network.
The RAN design presented in Section 3.1 enables certain network functions to operate on a faster time scale in 5G than in legacy systems. On this basis, traffic steering may not be performed in the form of hard handover on radio resource control (RRC) level between different RATs (e.g., between 3G and 4G) or access nodes, but could be done in a much more agile way and on a faster time scale on lower protocol stack layers. The resultant dynamic traffic steering exploits multi-connectivity (see Section 3.3) and applies traffic flow adaptation on a faster and possibly synchronous time scale. To this end, QoS requirements of the traffic flows are fulfilled considering the real-time radio link conditions pertaining to different AIVs serving the UE. For instance, relative unpredictability of the radio links especially on the higher frequency bands needs to be taken into account when considering high-priority traffic flows, as depicted in Figure 3-11 [3-10]. Current LTE radio link failure detection and recovery mechanisms would take several seconds in order to re-establish the radio bearer, and since this is unacceptable for high- priority traffic, the dynamic traffic steering framework will ensure that the QoS policies received from the 5G core network (CN) are successfully enforced. Some example results are shown in Fig. 3.w, where normalized delay can be improved relative to hard handovers as in legacy (see subfigure b) and, by employing packet duplication, SINR can be increased particularly in the low regime, which can improve the cumulative link reliability (see subfigure c). Figure 3-11: Dynamic Traffic Steering framework (a), delay gains (b) and reliability increase in terms of SINR gains (c).
The RAN design presented in Section 3.1 enables certain network functions to operate on a faster time scale in 5G than in legacy systems. On this basis, traffic steering may not be performed in the form of hard handover on radio resource control (RRC) level between different RATs (e.g., between 3G and 4G) or access nodes, but could be done in a much more agile way and on a faster time scale on lower protocol stack layers. The resultant dynamic traffic steering exploits multi-connectivity (see Section 3.3) and applies traffic flow adaptation on a faster and possibly synchronous time scale. To this end, QoS requirements of the traffic flows are fulfilled considering the real-time radio link conditions pertaining to different AIVs serving the UE. For instance, relative unpredictability of the radio links especially on the higher frequency bands needs to be taken into account when considering high-priority traffic flows, as depicted in Figure 3-11 [3-10]. Current LTE radio link failure detection and recovery mechanisms would take several seconds in order to re-establish the radio bearer, and since this is unacceptable for high- priority traffic, the dynamic traffic steering framework will ensure that the QoS policies received from the 5G core network (CN) are successfully enforced. Some example results are shown in Fig. 3.w, where normalized delay can be improved relative to hard handovers as in legacy (see subfigure b) and, by employing packet duplication, SINR can be increased particularly in the low regime, which can improve the cumulative link reliability (see subfigure c). Figure 3-11: Dynamic Traffic Steering framework (a), delay gains (b) and reliability increase in terms of SINR gains (c).
Figure 3-12: RAN moderation framework considering sBH nodes with normal operation (a), optimized coordinated operation (b), and achievable power consumption gains via optimized operation (c). Sleep modes 1 - 4 indicate the level of power savings that could be achieved at the BS, depending on the available sleep mode duration (0.071 — 1000 ms). RAN moderation framework [3-10] also includes mechanisms exploiting coordination approaches like joint transmission so that the number of cells that should be activated to satisfy the existing traffic can be reduced. Furthermore, mobile access nodes, e.g., vehicular nomadic nodes integrated into cars, within a dynamic radio topology can be activated or deactivated on- demand to cope with changing traffic conditions over time and space.
Figure 3-12: RAN moderation framework considering sBH nodes with normal operation (a), optimized coordinated operation (b), and achievable power consumption gains via optimized operation (c). Sleep modes 1 - 4 indicate the level of power savings that could be achieved at the BS, depending on the available sleep mode duration (0.071 — 1000 ms). RAN moderation framework [3-10] also includes mechanisms exploiting coordination approaches like joint transmission so that the number of cells that should be activated to satisfy the existing traffic can be reduced. Furthermore, mobile access nodes, e.g., vehicular nomadic nodes integrated into cars, within a dynamic radio topology can be activated or deactivated on- demand to cope with changing traffic conditions over time and space.
Figure 3-13: Concept of Self-backhauling A further step of wireless backhauling is self-backhauling, which refers to a set of solutions to provide technology- and topology-dependent coverage extension and capacity expansion utilizing same frequency band for both backhaul and access links, as shown in Figure 3-13. Self- backhauling provides an efficient way to combat infrastructure constraints especially in dense network deployment, where access to fibre may be limited to only some APs. However, self- backhauling also brings challenges to the radio resource management (RRM) between backhaul and access links, which leads to joint backhaul and access RRM optimize system efficiency.
Figure 3-13: Concept of Self-backhauling A further step of wireless backhauling is self-backhauling, which refers to a set of solutions to provide technology- and topology-dependent coverage extension and capacity expansion utilizing same frequency band for both backhaul and access links, as shown in Figure 3-13. Self- backhauling provides an efficient way to combat infrastructure constraints especially in dense network deployment, where access to fibre may be limited to only some APs. However, self- backhauling also brings challenges to the radio resource management (RRM) between backhaul and access links, which leads to joint backhaul and access RRM optimize system efficiency.
Figure 3-14: Illustration of a HetNet with mm-Wave wireless BH and access
Figure 3-14: Illustration of a HetNet with mm-Wave wireless BH and access
Figure 3-15: Comparison of user throughputs for carrier frequency of 28GHz and bandwidth of 1GHz: (a) edge/average user throughputs for 100 users; (b) average user throughputs for different number of users. Monte Carlo simulations are used to evaluate the efficiency of the proposed algorithms in enhancing user throughputs. For the evaluation, we consider a HetNet deployed under a single Manhattan Grid, where square blocks are surrounded by streets that are 200 meters long and 30 meters wide. One BS and four APs are located at the crossroads. 100 UEs are uniformly dropped in the streets. Channel model is consistent with [3-19].
Figure 3-15: Comparison of user throughputs for carrier frequency of 28GHz and bandwidth of 1GHz: (a) edge/average user throughputs for 100 users; (b) average user throughputs for different number of users. Monte Carlo simulations are used to evaluate the efficiency of the proposed algorithms in enhancing user throughputs. For the evaluation, we consider a HetNet deployed under a single Manhattan Grid, where square blocks are surrounded by streets that are 200 meters long and 30 meters wide. One BS and four APs are located at the crossroads. 100 UEs are uniformly dropped in the streets. Channel model is consistent with [3-19].
The allocation of functions between the RU and CU, i.e., the functional split, has a major impa on the transport network and the corresponding NGFI requirements regarding data rate, latenc and synchronization, and by the way to the information accessible by the MEC. Figure 4-1 depic a generic RAN signal processing chain of a mobile network. In principle, the split between R and CU may be between any of the blocks depicted. We focus on three functional splits, whic are capturing the most relevant trade-offs, denoted as A, B, and C in Figure 4-1. In general, spli higher up in the processing chain offer less centralization gains in terms of RRU size an cooperative processing, while reducing the requirements in terms of fronthaul data rate, latenc’ and synchronization. In Figure 4-1, split A places antenna processing in the RU, thus achieving scalable way to accommodate 5G technologies such as Massive-MIMO into current C-RA architectures based on CPRI. Split B is based on the transport of frequency domain symbol which, unlike CPRI, varies according to cell-load and enables statistical multiplexing gain Finally, split C represents an upper-MAC, or PDCP-like split, and may represent backhaul tyr of interfaces. The interested reader can found a detailed analysis of these functional splits in [- 6].
The allocation of functions between the RU and CU, i.e., the functional split, has a major impa on the transport network and the corresponding NGFI requirements regarding data rate, latenc and synchronization, and by the way to the information accessible by the MEC. Figure 4-1 depic a generic RAN signal processing chain of a mobile network. In principle, the split between R and CU may be between any of the blocks depicted. We focus on three functional splits, whic are capturing the most relevant trade-offs, denoted as A, B, and C in Figure 4-1. In general, spli higher up in the processing chain offer less centralization gains in terms of RRU size an cooperative processing, while reducing the requirements in terms of fronthaul data rate, latenc’ and synchronization. In Figure 4-1, split A places antenna processing in the RU, thus achieving scalable way to accommodate 5G technologies such as Massive-MIMO into current C-RA architectures based on CPRI. Split B is based on the transport of frequency domain symbol which, unlike CPRI, varies according to cell-load and enables statistical multiplexing gain Finally, split C represents an upper-MAC, or PDCP-like split, and may represent backhaul tyr of interfaces. The interested reader can found a detailed analysis of these functional splits in [- 6].
For the lower functional splits, the data rates range from 35 to almost 200 Gbps per cell. However, these are peak requirements. We have already remarked that a key benefit of Splits B and C is that the associated transport data rates scale with the actual utilization of resources on the access link. Thus, when using these splits, dimensioning the transport network according to peak data rates is not efficient in most cases. Instead, the NGMN Alliance has derived guidelines for dimensioning transport networks based on busy hour utilization, which leverage the statistical multiplexing occurring in practical networks [4-4]. Figure 4-2: Peak 5G FH data rate, channel coherence time and delay accuracy requirements
For the lower functional splits, the data rates range from 35 to almost 200 Gbps per cell. However, these are peak requirements. We have already remarked that a key benefit of Splits B and C is that the associated transport data rates scale with the actual utilization of resources on the access link. Thus, when using these splits, dimensioning the transport network according to peak data rates is not efficient in most cases. Instead, the NGMN Alliance has derived guidelines for dimensioning transport networks based on busy hour utilization, which leverage the statistical multiplexing occurring in practical networks [4-4]. Figure 4-2: Peak 5G FH data rate, channel coherence time and delay accuracy requirements
Figure 4-3: MCS distribution in the busy hour, and resulting load CDF distributions in the high load and low load scenarios Hereafter we will use two load scenarios to study the requirements of 5G networks. The measured utilization in the 4G network as pt (“Low load scenario”), and the scaled utilization p' (“High load scenario”). We expect the real requirements of a 5G network to lie between these two scenarios. In order to dimension the transport network appropriately, we need to consider the busy hour traffic, which in our live network is found to be from 12:15 h to 13:15 h. Consequently, a busy hour MCS distribution was calculated as the average MCS distribution in that hour, which is depicted in Figure 4-3(a). Note that MCS 10 and 17 are very close to their adjacent MCS in terms of spectral efficiency and are hence not utilized in this network. Finally, the loads of all cells observed in the busy hour were used to accumulate a discrete busy hour load distribution illustrated in Figure 4-3(b).
Figure 4-3: MCS distribution in the busy hour, and resulting load CDF distributions in the high load and low load scenarios Hereafter we will use two load scenarios to study the requirements of 5G networks. The measured utilization in the 4G network as pt (“Low load scenario”), and the scaled utilization p' (“High load scenario”). We expect the real requirements of a 5G network to lie between these two scenarios. In order to dimension the transport network appropriately, we need to consider the busy hour traffic, which in our live network is found to be from 12:15 h to 13:15 h. Consequently, a busy hour MCS distribution was calculated as the average MCS distribution in that hour, which is depicted in Figure 4-3(a). Note that MCS 10 and 17 are very close to their adjacent MCS in terms of spectral efficiency and are hence not utilized in this network. Finally, the loads of all cells observed in the busy hour were used to accumulate a discrete busy hour load distribution illustrated in Figure 4-3(b).
Figure 4-4: 5G Transport data requirements for the low and high load scenarios, functional splits and 5G RANs
Figure 4-4: 5G Transport data requirements for the low and high load scenarios, functional splits and 5G RANs
Figure 4-5: Data plane architecture [4-1]
Figure 4-5: Data plane architecture [4-1]
Figure 4-7: Split option as a function of load for different Compute to network ratios Figure 4-7 illustrates the impact of service requirements in terms of network and compute resources on the optimal split option adopted. Services with high network-to-compute ratios require significant network resources to operate, leading to overutilization of transport capacity. This effect is counter-balanced by the selection of higher split options that require lower bandwidth for the interconnection of RUs with CUs compared to the bandwidth requirements of lower split options (i.e. options 1, 2). Our modelling results have shown that for higher traffic load, the total power consumption increases.
Figure 4-7: Split option as a function of load for different Compute to network ratios Figure 4-7 illustrates the impact of service requirements in terms of network and compute resources on the optimal split option adopted. Services with high network-to-compute ratios require significant network resources to operate, leading to overutilization of transport capacity. This effect is counter-balanced by the selection of higher split options that require lower bandwidth for the interconnection of RUs with CUs compared to the bandwidth requirements of lower split options (i.e. options 1, 2). Our modelling results have shown that for higher traffic load, the total power consumption increases.
Figure 4-8: TALE and KPI mapping methodology
Figure 4-8: TALE and KPI mapping methodology
RAN sharing for 5G can be implemented by adding advanced control features to the current 3GPP LTE. LTE uses Orthogonal Frequency Division Multiplexing (OFDM) for the downlink and Single Carrier Frequency Division Multiple Access (SC-FDMA) in the uplink. The Physical Resource Block (PRB) is the smallest element assigned by the base station scheduler. Transmission Time Interval (TTI) is the duration of a transmission on the radio link. A scheduler can determine to which user the shared resources (time and frequencies) for each TTI should be allocated. As shown in Figure 5-3, the RAN sharing problem is related to the design and implementation of policies that are able to effectively schedule Resource Blocks effectively between different MVNOs with respect to specific differentiation objectives and with isolation guarantees. Figure 5-4 presents a high-level representation of the control plane interaction with different tenants sharing the RAN. The local real time controller (RTC) component of the architecture facilitates efficient policies that share RAN resources. A local real time controller keeps information consistent within its regional and real-time scope of control, meaning that it has to synchronise information from various infrastructure sources to produce a complete local network view. In Section 3.1, the logically centralized controller and the hierarchy control framework from RAN are introduced. Together with the logically centralized controller (C3) integration and a fully programmable underlay, it is able to support the Infrastructure Sharing, the Spectrum sharing and the RAN sharing by coordinating the RAN resource from different abstraction levels by the hierarchy control structure.
RAN sharing for 5G can be implemented by adding advanced control features to the current 3GPP LTE. LTE uses Orthogonal Frequency Division Multiplexing (OFDM) for the downlink and Single Carrier Frequency Division Multiple Access (SC-FDMA) in the uplink. The Physical Resource Block (PRB) is the smallest element assigned by the base station scheduler. Transmission Time Interval (TTI) is the duration of a transmission on the radio link. A scheduler can determine to which user the shared resources (time and frequencies) for each TTI should be allocated. As shown in Figure 5-3, the RAN sharing problem is related to the design and implementation of policies that are able to effectively schedule Resource Blocks effectively between different MVNOs with respect to specific differentiation objectives and with isolation guarantees. Figure 5-4 presents a high-level representation of the control plane interaction with different tenants sharing the RAN. The local real time controller (RTC) component of the architecture facilitates efficient policies that share RAN resources. A local real time controller keeps information consistent within its regional and real-time scope of control, meaning that it has to synchronise information from various infrastructure sources to produce a complete local network view. In Section 3.1, the logically centralized controller and the hierarchy control framework from RAN are introduced. Together with the logically centralized controller (C3) integration and a fully programmable underlay, it is able to support the Infrastructure Sharing, the Spectrum sharing and the RAN sharing by coordinating the RAN resource from different abstraction levels by the hierarchy control structure.
Figure 5-5: The concept of RFB and REE that generalize the execution environment
Figure 5-5: The concept of RFB and REE that generalize the execution environment
representation of the network state and infrastructure resources is crucial for effective RAN coordination and control of programmable infrastructures and services. Moreover, programmable infrastructures require programmability constructs that provide means to observe and manipulate virtual and physical Network Functions (NFs) and their behaviour via high-level abstractions. One example of RAN programmability model is shown in Figure 5-6.
representation of the network state and infrastructure resources is crucial for effective RAN coordination and control of programmable infrastructures and services. Moreover, programmable infrastructures require programmability constructs that provide means to observe and manipulate virtual and physical Network Functions (NFs) and their behaviour via high-level abstractions. One example of RAN programmability model is shown in Figure 5-6.
Figure 5-7. TOSCA relation to NFV
Figure 5-7. TOSCA relation to NFV
Figure 5-8 represents the way in which NSI facilitates the request of connectivity services among providers. Despite connectivity services are covered by NSI, it does not allow by now any capabilities for requesting more advanced services as VNFaaS or NFVIaaS.
Figure 5-8 represents the way in which NSI facilitates the request of connectivity services among providers. Despite connectivity services are covered by NSI, it does not allow by now any capabilities for requesting more advanced services as VNFaaS or NFVIaaS.
Figure 5-9. Support for RAN sharing through Edge Cloud infrastructure The advantage of using OpenFlow (OF) protocol as basis for SFC is that routing can be steered over a specific networking path by programmatically applying OF based rules (flows) on the SDN controller or the virtual switch (OVS) inside the VM hosting the VNF. From a single data center point of view, the SDN controller is placed between components such as the Orchestrator of the Light Data Centre (Light DC), see Figure 5-10. The steering and rule enforcement policy are kept within the controller application logic and enforced over the network that hosts the Light DC specific VNFs. If the routing happens across different Light DCs, then the SFC approach may alter depending on the placement of the controller within the given architecture. This has to be in accordance with the networking protocols to be adopted in that case, as used today for intra data- center routing.
Figure 5-9. Support for RAN sharing through Edge Cloud infrastructure The advantage of using OpenFlow (OF) protocol as basis for SFC is that routing can be steered over a specific networking path by programmatically applying OF based rules (flows) on the SDN controller or the virtual switch (OVS) inside the VM hosting the VNF. From a single data center point of view, the SDN controller is placed between components such as the Orchestrator of the Light Data Centre (Light DC), see Figure 5-10. The steering and rule enforcement policy are kept within the controller application logic and enforced over the network that hosts the Light DC specific VNFs. If the routing happens across different Light DCs, then the SFC approach may alter depending on the placement of the controller within the given architecture. This has to be in accordance with the networking protocols to be adopted in that case, as used today for intra data- center routing.
There is therefore a clear advantage and thereby a market need for integrated services based on machine learning to leverage the output provided by researchers for network management. The work done in 5GPPP phase 1 offers an integrated set of services that can be selected by operators based on the individual needs of an operator. The service portfolio can also be used to complement the tools used for network management to handle FCAPS functionalities (Fault, Configuration, Accounting, Performance and Security).
There is therefore a clear advantage and thereby a market need for integrated services based on machine learning to leverage the output provided by researchers for network management. The work done in 5GPPP phase 1 offers an integrated set of services that can be selected by operators based on the individual needs of an operator. The service portfolio can also be used to complement the tools used for network management to handle FCAPS functionalities (Fault, Configuration, Accounting, Performance and Security).
Figure 5-14: VNFs Onboarding Service and Plug-ins
Figure 5-14: VNFs Onboarding Service and Plug-ins
Figure 5-15: SELFNET VNFs Lifecycle Management The Figure shows the high level VNFM functional split and highlights its main functional entities and the interactions with the other components. This functional split includes those lifecyc management entities needed a the VNF side in sup components (VNF-C). Indeed, VNF developers software components, and eac between VNF-Cs and Virtual depends on specific VNF vend h one is deployed wi and vendors may structure their VNFs in Machines. The way VNFs are structured into VNF-Cs general or and developer fac port of the VNFM operations. Here, following the ETSI NFV principles, each VNF is generally considered as composed by a set of VNF hin an independent Virtual Machine. A VNF- C is therefore associated with a VNF software component, and a 1:1 correspondence exis e O ts y ors. For each VNF-C, a lifecycle management (LCM) agent is embedded in the correspondent Virtual Machine to enable the communication with the VNFM and implement the lifecycle actions on the VNF. This agent enables the containerization of VNF and ETSI MANO EMS components into encapsulated VNFs, providing Y CAMMon interface tawarde the VNEM
Figure 5-15: SELFNET VNFs Lifecycle Management The Figure shows the high level VNFM functional split and highlights its main functional entities and the interactions with the other components. This functional split includes those lifecyc management entities needed a the VNF side in sup components (VNF-C). Indeed, VNF developers software components, and eac between VNF-Cs and Virtual depends on specific VNF vend h one is deployed wi and vendors may structure their VNFs in Machines. The way VNFs are structured into VNF-Cs general or and developer fac port of the VNFM operations. Here, following the ETSI NFV principles, each VNF is generally considered as composed by a set of VNF hin an independent Virtual Machine. A VNF- C is therefore associated with a VNF software component, and a 1:1 correspondence exis e O ts y ors. For each VNF-C, a lifecycle management (LCM) agent is embedded in the correspondent Virtual Machine to enable the communication with the VNFM and implement the lifecycle actions on the VNF. This agent enables the containerization of VNF and ETSI MANO EMS components into encapsulated VNFs, providing Y CAMMon interface tawarde the VNEM
Figure 5-16: Automated Physical and Virtual Infrastructure Deployment Management of the physical layer has been achieved by using the latest version of the MaaS software package provided by Ubuntu. MaaS provides the following primary functions: automatic deployment of Operating Systems in multiple zones, automatic configuration of network interfaces and storage layouts and support for on-demand acquisition of computing resources by multiple users. When a new computing resource is plugged into the infrastructure for the first ime, it is automatically discovered by MaaS, and at this point the resource status is marked as New. This allows the administrator to commission the node by installing an OS in a reserved partition and thus gain the control and governance of the node. This action moves the node to Commissioned status, which in turn allows a user to acquire the computing resource, moving it o Acquired status. Once a node has been acquired, the user can configure the network, layout of he disks, and select the OS he/she wishes to deploy. By installation and configuration of these user-selected options, the node is moved to Deployed status, and at this point, the node is fully operational. Furthermore, network-facing SDN/NFV services or facilities such as OpenStack based VIM and OpenDayLight based SDN controller can be automatically installed. For the Cloud-RAN in a 5G network, these services can be pushed to the RRH and the BBU as part of he automated installation process. Figure 5-16 illustrates this scenario, using LTE evolution based approach as an example, where OpenAirInterface is employed using LXC (Linux Containers).
Figure 5-16: Automated Physical and Virtual Infrastructure Deployment Management of the physical layer has been achieved by using the latest version of the MaaS software package provided by Ubuntu. MaaS provides the following primary functions: automatic deployment of Operating Systems in multiple zones, automatic configuration of network interfaces and storage layouts and support for on-demand acquisition of computing resources by multiple users. When a new computing resource is plugged into the infrastructure for the first ime, it is automatically discovered by MaaS, and at this point the resource status is marked as New. This allows the administrator to commission the node by installing an OS in a reserved partition and thus gain the control and governance of the node. This action moves the node to Commissioned status, which in turn allows a user to acquire the computing resource, moving it o Acquired status. Once a node has been acquired, the user can configure the network, layout of he disks, and select the OS he/she wishes to deploy. By installation and configuration of these user-selected options, the node is moved to Deployed status, and at this point, the node is fully operational. Furthermore, network-facing SDN/NFV services or facilities such as OpenStack based VIM and OpenDayLight based SDN controller can be automatically installed. For the Cloud-RAN in a 5G network, these services can be pushed to the RRH and the BBU as part of he automated installation process. Figure 5-16 illustrates this scenario, using LTE evolution based approach as an example, where OpenAirInterface is employed using LXC (Linux Containers).
Figure 5-17: Implementation Design Architecture for multi-domain orchestration To achieve multi-operator interaction work has been done in defining the interfaces and components between the operators’ multi-domain orchestrators (MdOs), see Figure 5-17. The architecture maps to the overall architecture picture shown in Figure 5-1. The Topology abstraction and discovery system implements the abstraction components of Figure 5-1. While the business level relationships such as pricing are not yet clarified the catalogue management system implements the service repository of Figure 5-1. The detail interfaces are shown showing the different types of functionality that exists between the operators. The section provides a brief overview of the functionalities exposed between the operators. A detailed description of this architecture components is presented in [5-19]. The components of the architecture for inter-operator orchestration can be classified into three main groups, according to the core functionalities of the MdO. The components belonging to the first group are responsible for capabilities and resource acquisition and these ones can be seen on the right part of the MdO architecture. The components belonging to the second class are responsible for service request deployment (e.g., orchestration) and can be seen in the middle of the MdO. Furthermore, the third group contains components that are in charge of service assurance and SI_A manacement: these comnonents are nlaced on the left side of the MdQ.
Figure 5-17: Implementation Design Architecture for multi-domain orchestration To achieve multi-operator interaction work has been done in defining the interfaces and components between the operators’ multi-domain orchestrators (MdOs), see Figure 5-17. The architecture maps to the overall architecture picture shown in Figure 5-1. The Topology abstraction and discovery system implements the abstraction components of Figure 5-1. While the business level relationships such as pricing are not yet clarified the catalogue management system implements the service repository of Figure 5-1. The detail interfaces are shown showing the different types of functionality that exists between the operators. The section provides a brief overview of the functionalities exposed between the operators. A detailed description of this architecture components is presented in [5-19]. The components of the architecture for inter-operator orchestration can be classified into three main groups, according to the core functionalities of the MdO. The components belonging to the first group are responsible for capabilities and resource acquisition and these ones can be seen on the right part of the MdO architecture. The components belonging to the second class are responsible for service request deployment (e.g., orchestration) and can be seen in the middle of the MdO. Furthermore, the third group contains components that are in charge of service assurance and SI_A manacement: these comnonents are nlaced on the left side of the MdQ.
Figure 5-18 Security in the Multi-Operator Scenario
Figure 5-18 Security in the Multi-Operator Scenario
Figure 5-19 Architecture Pillars for Cognitive Management.
Figure 5-19 Architecture Pillars for Cognitive Management.
The architecture of the CSE component in Figure 5-1 re Policy-Based Management (PBM processing methods, are inspired Figure 5-19 and is further reviewed in the following subs based on Network Functions Virtualisation (NFV) and is a standardized management that is a pillar of the Policy Engine. (2) Th CSE, the key focus for automation, are able to take advantage of both batch and streaming by the lambda archi machine learning functionalities rat paradigm in the contex ecture. The lambda arc Analyse, Plan, and Execute parts that share Knowledge (MAPE-K) autonomic loo he CSE re-uses the monitoring data collected by the monitoring engine in Figure 5-1. ies mainly on three pillars depicted in ections: (1) It assumes an environment Software-Defined Networking (SDN). of network e machine learning components of the hitecture is a framework for designing big data applications that serves a variety of use cases with different atency requirements. The CSE is inspired from the lambda architecture but adap her than querying purposes which is the original aim of the ambda architecture. (3) CSE aims to deliver an autonomic network management solution based on machine learning, hence components and workflow were designed to suppor ed to support the Monitor, p. To this end
The architecture of the CSE component in Figure 5-1 re Policy-Based Management (PBM processing methods, are inspired Figure 5-19 and is further reviewed in the following subs based on Network Functions Virtualisation (NFV) and is a standardized management that is a pillar of the Policy Engine. (2) Th CSE, the key focus for automation, are able to take advantage of both batch and streaming by the lambda archi machine learning functionalities rat paradigm in the contex ecture. The lambda arc Analyse, Plan, and Execute parts that share Knowledge (MAPE-K) autonomic loo he CSE re-uses the monitoring data collected by the monitoring engine in Figure 5-1. ies mainly on three pillars depicted in ections: (1) It assumes an environment Software-Defined Networking (SDN). of network e machine learning components of the hitecture is a framework for designing big data applications that serves a variety of use cases with different atency requirements. The CSE is inspired from the lambda architecture but adap her than querying purposes which is the original aim of the ambda architecture. (3) CSE aims to deliver an autonomic network management solution based on machine learning, hence components and workflow were designed to suppor ed to support the Monitor, p. To this end
Figure 5-21 CSE Operational Architecture.
Figure 5-21 CSE Operational Architecture.
Figure 5-23: Autonomic Network Management Framework: SON Engine The concept of 5G SON is addressed in a twofold manner within the SON-based autonomic management engine, as illustrated in Figure 5-23. At first, a set of tactical strategies is expressed by the use of the TAL. Their aim is to specify the human-based tactical approaches regarding the reactions of the system in view or detection of certain events and anomalies in the system being controlled. Secondly, an algorithmic processing of the indicated strategies along the gradually built (machine learning based) artificial intelligence is expected to produce optimal decisions. In he context of this autonomic management framework, TAL constitutes the static definition of the intelligence, usually incorporating experience of network management personnel, that at least, provides the initial starting point where to the common sense intended behaviour is expressed and hat may thereafter be optimized by the artificial intelligence based processing.
Figure 5-23: Autonomic Network Management Framework: SON Engine The concept of 5G SON is addressed in a twofold manner within the SON-based autonomic management engine, as illustrated in Figure 5-23. At first, a set of tactical strategies is expressed by the use of the TAL. Their aim is to specify the human-based tactical approaches regarding the reactions of the system in view or detection of certain events and anomalies in the system being controlled. Secondly, an algorithmic processing of the indicated strategies along the gradually built (machine learning based) artificial intelligence is expected to produce optimal decisions. In he context of this autonomic management framework, TAL constitutes the static definition of the intelligence, usually incorporating experience of network management personnel, that at least, provides the initial starting point where to the common sense intended behaviour is expressed and hat may thereafter be optimized by the artificial intelligence based processing.
1 Overall 5G Architecture, Use Cases and Key requirements
1 Overall 5G Architecture, Use Cases and Key requirements
Dissemination level: Public
Dissemination level: Public
Dissemination level: Public
Dissemination level: Public
Radio/ Wireless Network Interworking and Interfaces
Radio/ Wireless Network Interworking and Interfaces
).2.6 Wireless/Wireline Network Interworking and Interfaces
).2.6 Wireless/Wireline Network Interworking and Interfaces
Related topics:
Computer ScienceArchitecture
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved