Version R2 of the documentation is no longer actively maintained. The site that you are currently viewing is an archived snapshot. For up-to-date documentation, see the latest version.

Nephio R2 Release Notes

Overview

Prerequisites

Please refer to the Install Guide for the prerequisites on supported environments.

Support Matrix

The sandbox environment requires a physical or virtual machine with:

  • Ubuntu-20.04-focal or Ubuntu 22.04 Linux Or Fedora 34
  • Minimum 8 cores and Recommended 16 cores (Needed for end-to-end testing with RAN and core )
  • 32 GB memory
  • 200 GB disk size
  • Default user with sudo passwordless permissions

This installation has been verified on VMs running on Google Cloud.

A Nephio sandbox can be created on any Kubernetes cluster v1.26 and above.

Features

API

Common CRDs provided for 5G Core and RAN services

Web UI

Basic web UI to view and manage the packages and resources within them.

Packages

  • Kpt packages for all free5GC services
  • Kpt packages for all OAI services
  • Packages for the core Nephio services
  • Packages for the Cluster API services for cluster creation
  • Packages for the dependent services

Functionalities

  • Multi-vendor support
    • API changes
    • Generalization
    • Parameterization
    • Reuse of params
  • Multi-cloud support
    • Sandbox
    • GCP
    • OpenShift
  • OAI components
    • Deploying OAI 5G Core and RAN Network Functions (CU-CP, CU-UP, RF Simulated DU)
    • OAI 5G Core network functions are developed using Python KOPF (Kubernetes Operator Framework)
    • End to End call with RF Simulated OAI-NR-UE
  • Integration with new release of Porch
    • Porch is now part of Nephio and hosted in Nephio repository.
    • Stability
    • Security
    • Repo watcher changes
  • Documentation
    • New web based documentation
  • Experimental
    • Nephio SDK
    • Flux-based deployment of Helm charts
    • Helm-to-operator converter
    • Topology Controller - Northbound API to express the network topology

Fixes

  • Removing rigid dependency on Gitea
  • Upgrading the Multus version
  • ConfigMap generator function
  • WebUI configuration options for authentication
  • Reorganizing the package catalog
  • Reduce hard coding of NF parameters
  • Stability of end-to-end tests
  • Porch improvements
  • Documentation enhancements

Limitations

  • For infrastructure automation, only creation of KIND clusters is supported.
  • Inter-cluster networking is not dynamic so as more clusters are deployed, some manual tweaking will be needed for inter-cluster communications.
  • Provisioning of VLAN interfaces on nodes is manual at this time.
  • Feedback of workload deployments from workload clusters to the Management cluster is limited. You may need to connect directly to the Workload cluster via kubectl to debug any deployment issues.
  • Web UI features are limited to view/edit of packages and resources in those packages and their deployment. Additional features will be added in subsequent releases.
  • When the capacities of the UPF,SMF and AMF NFs are changed, the free5GC Operator on the Workload cluster will instantiate a new POD with correspondingly modified resources (CPU, memory etc.) During this process, the pod will restart. This is a limitation of free5GC.
  • Only Gitea works with automated cluster provisioning to create new repositories and join them to Nephio. To use a different Git provider, you must manually provision cluster repositories, register them to the Nephio management server, and set up Config Sync on the Workload cluster.
  • The WebUI does not require authentication in the current demo configuration. Testing of the WebUI with authentication configured has not been done at this time.
  • The WebUI only shows resources in the default namespace.
  • While many types of Git authentication are supported, the testing was only done with token-based Git authentication in Gitea.

Known Issues and Workarounds

  • Packages may take a long time to be approved by the auto-approval controller. If they seem stuck, restarting Porch and the Nephio controllers may help:
kubectl -n porch-system rollout restart deploy porch-server
kubectl -n nephio-system rollout restart deploy nephio-controller
  • Occasional calls to porchctl rpkg copy may fail with a message like Error: Internal error occurred: error applying patch: conflict: fragment line does not match src line. Try again in a little while, this may clear up on its own. Restarting Porch may also help.

  • During specialization, we may have duplicate parameterRef extensions, leading to failed deployments (wrong configurations are generated). The current workaround is to redeploy the package. The bug is due to NFDeploy reconciliation not being correctly idempotent.

  • The free5GC operator may create duplicate entries in the SMF function configuration. This is harmless, but still incorrect.

  • Links in the documentation may not render in Github due to the limitations of the tool being used for web based documentation.