Q1: What are telco requirements to make a 5G journey successful?
Telcos need to implement 5G while simultaneously lowering operating costs and improving agility. Zero-touch provisioning of the network and automated ongoing maintenance of that network are necessary to achieve these goals.
Q2: What are telco challenges?
The transition from VNF to CNF and the transition to public cloud provide opportunities for cost savings and increased agility. To take advantage of this, telcos must meet the challenges of managing large numbers of sites, zero-touch automation with a human-free control loop, optimization of scarce edge resources, and addressing the limitations of legacy out-of-band network automation.
Q3: What is missing in the industry with automation?
Having multiple automation control planes for different types of infrastructure and different types of network functions makes it impossible to provide interconnected automations that maintain consistency across layers. It also makes it impossible to automatically adapt interrelated layers when one of them changes.
Nephio consolidates on Kubernetes as the automation control plane. This enables us to bring all the declarative, active reconciliation benefits to the entire stack.
Q4: What’s wrong with my existing Infrastructure-as-Code (e.g., Helm-based) automation?
Complex templates that intermingle code and data are exceptionally difficult to test and maintain.
Also, because templates generate manifests as output, you can’t edit those manifests afterwards (they’ll be overwritten next time you run the template). This means every single field in every resource ends up as an input to the templates. The results are massive lists of parameters that are not easily understood.
Conditionally generated config based on those inputs makes intent-based continuous reconciliation difficult or impossible. It also results in debugging issues – you have to backtrack from what is in your cluster through all the conditionals to figure out how to fix a problem.
These are just a few of the challenges that the Configuration-as-Data approach helps solve.
Q5: What is cloud native?
“Cloud Native” has many facets, far more than just “containerized”. Just containerizing won’t yield the cost, scalability, and efficiency benefits of the cloud.
For Nephio, one of the most important is the separation of the requirements a workload has for the infrastructure, from the implementation of that requirement. For example, in Kubernetes, the user can create a Service resource, but doesn’t need to have any awareness of how the network is plumbed to make that Service a reality. This allows that implementation to vary across platforms and cloud vendors, increasing portability of those workloads.
Current CNFs (and VNFs) have struggled to rigorously maintain this separation, resulting in network function deployments that still rely too much on knowing the very specific configuration of the underlying hardware. This prevents realization of the primary benefits of cloud, since cloud-enabled scalability, self-healing, redundancy, and agility all depend on the “fungibility” of the layers below the CNFs.
Another critical aspect of “cloud native” for network functions is the use of declarative configuration with active reconciliation. This is a core principle of Kubernetes; rather than reacting to commands and events, Kubernetes seeks to reconcile “observed state” with “intended state”.
Q6: How do we get to a true cloud native solution?
Nephio addresses this in two primary ways: 1) working towards Kubernetes-based APIs at all layers of the stack while working with the community to ensure those APIs provide proper separation between the layers; and 2) extending intent-based automation up the stack through the Kubernetes based automation framework.
Q7: What are the benefits of using Kubernetes?
Kubernetes is a proven platform for declarative management and active reconciliation, and is extremely extensible via Customer Resource Definitions (CRDs). It is also widely used and familiar to many developers today.
Q8: What is KRM, CaD? And why is it important?
Kubernetes Resource Model, or KRM, is the basic structure of all Kubernetes API objects (aka “resources”). It provides a consistent, extensible schema for describing declarative resources.
Configuration-as-Data, or CaD, is a methodology for configuration management that rigorously enforces well-structured declarative configurations, and separates those configurations from the code that operates on them. This makes the configurations amenable to manipulation by well tested, reusable code, and enables robust, semantically aware merges of edits made by humans, bulk editing tools, and automations.
These are closely connected in Nephio, where KRM is the “well-structured declarative” format on which CaD relies. Without the ability to manage the configurations as data – allowing human edits and automated tooling to coexist peacefully – it is impossible to handle the complexity and scale needed by Nephio.
Q9: What are the different layers of telecom automation and what is Nephio focused on?
Nephio considers three broad layers of telecom automation: end-to-end service orchestration, domain orchestration, and infrastructure orchestration. Nephio’s focus is on domain automation, while also utilizing infrastructure orchestration as a pluggable southbound interface. Nephio’s goal is to capture sufficient elements from each layer as CRDs to enable true declarative management at the domain level.
Q10: What are synergy between O-RAN, 3gpp, ONAP, EMCO and Nephio?
Nephio is complementary to many of the existing open source efforts. Nephio’s goal is to develop open automation configuration in conformance to the O-RAN and 3GPP specifications.
ONAP end-to-end service orchestration can interface with Nephio using open APIs for domain automation.
EMCO is a complementary LFN project that can integrate with Nephio.
Nephio’s goal is to deliver carrier-grade, simple, open, Kubernetes-based cloud-native intent automation and common automation templates that materially simplify the deployment and management of multi-vendor cloud infrastructure and network functions across large scale edge deployments. Nephio enables faster onboarding of network functions to production including provisioning of underlying cloud infrastructure with a true cloud native approach, and reduces costs of adoption of cloud and network infrastructure.
Q11: What are the benefits of Nephio?
For telcos, Nephio provides an open, simple, widely adopted Kubernetes based cloud-native automation that enables multi-vendor support, faster onboarding, easier life-cycle management, embedded control-loop, active reconciliation and service assurance — reducing cost by efficiency and agility.
For cloud providers, Nephio provides a common cloud-based automation framework based on well-proven Kubernetes technology. This minimizes the levels of custom automation solutions needed for each application. Kubernetes based automation enables faster development with known technology and assures network functions will deploy and run reliably on top of the cloud.
For network function vendors, Nephio enables easier multi-vendor integration with cloud providers, makes network function onboarding to cloud easier, and improves the overall customer experience with simple and reliably integrated cloud native automation.
Q12: Were there previous efforts?
There are ecosystem projects that are point solutions to specific network function requirements. For example, the existing Pod extension in Kubernetes such as Multus. These are critical and necessary, but they do not address the whole problem. These efforts have been disjointed and individualized for different use cases. A broader effort is needed to coordinate the efforts, identifying and closing gaps.
None of these efforts address the broader, multi-vendor and multi-site automation problem.
Q13: Why do we need different players across the telco industry to make this possible? What are we asking of different members?
Nephio aims to provide an open, cross-vendor solution. This applies to cloud vendors and network function vendors. We need involvement from all of these parties to ensure that Nephio can meet the needs of each vendor, and to ensure that customers can still take advantage of each vendor’s unique, differentiating features.
We also need help from service orchestration vendors to ensure that Nephio meets their domain automation requirements, and of course from telcos – the end customers – to provide depth of understanding of the requirements and to focus our efforts on the most critical requirements.
Q14: Will this group be open to global customers?
Yes, Nephio is open to all.
Q15: How do I contribute to this community?
Your company can join the community by providing a supporting quote which will be displayed in the website.
There is no membership fee to join. You can engage in the TSC or contribute to one or many of the working groups.
Q16: What level of commitment is required from each member?
Nephio members can decide on their engagement level. Deliverables of Nephio benefit the whole industry and active engagement is required by all to improve the state of cloud native automation. Active contributions from members are welcome.
Refer to the TSC charter for further details.
Q17: What are the timelines of Nephio?
Launched on April 12th, 2022.
First TSC meeting is targeted in April, 2022, further details to follow.
First release in late 2022/early 2023.
