Issue link: https://www.e-digitaleditions.com/i/1476549
October/November/December 2022 I 17 To start, 5G SA will be a truly data driven network. Everything from service and network orchestration, oper- ations automation, customer experience management, and more will need plenty of data. A tier 1 MNO believes its 5G SA network could generate upwards of 40 petabytes (PB) of data per hour 1 just to run the network and man- age its services! Service assurance costs simply cannot scale at the same rate the network does. No operator can afford this. Generating data is not the only cost to con- sider. Moving, storing, and analyzing monitoring data at the scale imagined is simply too expensive. A smarter, more cost-effective cloud-native way of implementing service assurance is needed. Cloud-native networks introduce a new wrinkle in the service assurance game. The disaggregation of network functions (NFs) into containerized micro- services, combined with the highly dynamic and scalable nature of the network and service layers within the cloud itself, has made it almost impossible to connect the dots between quality of service (QoS) or quality of experience (QoE) issues and the physical network infrastructure that underpins them. This means it can be very difficult and time-consuming to debug issues that span these 2 domains (cloud and infrastructure). Identifying fault domains and pinpointing root cause issues is typically the largest portion of the mean-time-to-repair (MTTR). 2 Eliminating or at least greatly reducing the time taken for domain isolation and root cause analysis (RCA) will lead to a better customer experience and significant operations savings. These network and service layers are not the only dynamic aspect in the cloud-native network. The infra- structure is also highly dynamic. Firmware and software updates, configuration and hardware upgrades will be constant—and any of these could lead to impacts in the cloud layers. The traditional siloed worlds of network and service operations teams and the cloud and IT operations teams must also be addressed. From the perspective of the customer's QoE and service level agreement (SLA) management, these teams need to work as one. Customers will no longer tolerate lengthy repair cycles just because the operator could not identify the root cause in real or near real-time. Poor QoE, perceived or real, is expensive—in traditional operations costs and more importantly, the cost due to high churn rates, customer acquisition, and damage to brand reputation. Customers will "vote with their feet," and once they leave, it is very difficult to get them back. There is also a new challenge looming on the horizon—power management. Traditional data centers operate on the idea that compute, memory, and power are essentially infinite. However, in cloud-native telecommunications networks, this will not always be the case. Mobile edge compute (MEC) locations will be highly resource constrained; as a result, they require better power utilization visibility. Additionally, many countries are implementing or considering implementing green policies that will require proof of compliance. By examining these issues in more detail, a description of a path forward arises that can both meet challenges and provide a platform to deliver a better 5G experience. INTRODUCTION TO 5G SA The 5G SA is driving the most radical change in tele- communications networks since they were invented. The virtualization of the network has eliminated the static physical network elements that defined legacy networks, creating a fluid, highly dynamic, massively scalable, and service agile utopia. A network freed from hardware concerns—fantastic! But not so fast, cloud-native networks still need a physical infrastructure to run on, one that can support this highly dynamic network. No hardware is infallible, and not all problems are obvious. In fact, it is safe to say that while solving many of the CSP's challenges and opening the door to a vast array of new services and capabilities, cloud-native networks have introduced an entirely new fault domain—the cloud infrastructure itself.