The growth of the cloud native ecosystem has been explosive, unprecedented, and far reaching. The definition of “cloud native” along with the development and consistent application of cloud native principles provided the foundation upon which developers have built a software cathedral beyond anything imaginable even just 10 years ago. One look at the CNCF landscape shows us how far we have come in a short time and provides a model for what’s possible in the future.

“Cloud Native” of course arose to meet the demands and possibilities of cloud computing – a paradigm shift, transformative force, and catalyst for parallel and supporting innovations, models and ecosystems. Edge Computing is intricately woven into the cloud, while expanding the frontiers of compute, storage, and networking to any edge device that can run Kubernetes. Perhaps not surprisingly, the cloud edge is perhaps the fastest growing area of edge computing, driven by multi-cloud networking, machine learning, storage repatriation and more. 

But edge computing occurs in different environments than cloud computing – constrained by smaller form factors deep in public and private networks. In edge environments, compute, connectivity, storage, and power are all limited, necessitating new approaches and a new set of edge native principles. 

It is in this spirit that discussions began in the IOT Edge Working Group in the middle of 2022. Our goal was to explore what it means to be edge native, the differences and similarities between “cloud native” and “edge native”, and to proffer an initial set of principles for the industry to interpret, apply, and iterate upon. We landed on the following five broad principles:

• Resource and Design Aware (includes 3 sub-principles)
• At Scale Management (includes 3 sub-principles)
• Spanning
• Resource Usage Optimization
• Applications are Portable and Reusable (within limits)

The IoT Edge Woking group debuted the Edge Native Application Principles Whitepaper draft on Github and on the stage at KubeCon + CloudNativeCon North America 2022 and incorporated community feedback into this current draft. We hope to evolve the whitepaper over time as well as develop tangential papers as needed to give developers the guidance needed to accelerate development in the edge frontier. We hope that you will read the whitepaper, try out these principles in practice, and share your feedback with the IOT EDGE working group.

DOWNLOAD THE WHITEPAPER HERE

Aarna.ml presented a number of industry leading initiatives at Mobile World Congress in Barcelona, Feb 27 - Mar 2, in partner booths and select meetings. If you didn't have the chance to meet us in Barcelona, he's a recap.

Booth Demos:

O-RAN orchestration on O-Cloud Optimized for hybrid environments (Aarna.ml, Rebaca Technologies, Red Hat, VoerEir AB). See it in the O-RAN Virtual Showcase.

Orchestration and management of RAN elements using SMO over O1 interface (Aarna.ml, Capgemini Engineering): Zero-touch provisioning (ZTP) of Small cells. See it in the O-RAN Virtual Showcase.

Core Network (CN) for Non-public Networks (NPN) 5G using O-RAN SMO and Automation (Aarna.ml, HFCL)

Other Highlights:

• Partnership with NTT DATA
• O-RAN SMO Leadership
• AMCOP 3.2 Release
• Nephio Leadership
• Aarna Edge Services (AES)

Learn more in the press release.

Didn't have a chance to meet with us Barcelona? Contact us to book a meeting: https://lnkd.in/erBGgPMk

In the world of 5G, edge computing plays a critical role in ensuring low-latency and high-performance applications. However, with the increased mobility of users, there is a need for seamless migration of the Application Function (AF) and User Plane Function (UPF) to another edge cluster. In this use-case, we will simulate UE mobility and explore the AF and UPF migration to another edge cluster, using Aarna’s AMCOP platform In place of real UE (User Equipment) devices, we use a software simulator (UE Sim). 

First, it is important to note that the 5G Core and MEC applications must be deployed in the target cluster, which can communicate with the 5GC via the NEF. Additionally, AMCOP should have at least two target clusters onboard, and the UE simulator must have a PDU session established with UPF in one of the edge clusters. All 5GC functions in this use case belong to the same PLMN.

The following diagram describes the use-case at a high level.

Assuming that the AF (and UPF) are relocated to the other edge cluster, the AF has to now initiate the following procedure in 5GC.

When the UE moves to another location, it triggers the relocation of the AF and UPF to another edge cluster. After the relocation, the AF in the source cluster calls traffic influence APIs exposed by the NEF in 5GC. The NEF should expose the following APIs at the minimum for this to occur:

• Nnef_TrafficInfluence_Create/Update/Delete
• Nsmf_EventExposure_Notify
• Nnef_TrafficInfluence_Notify

The AF then uses the traffic influence API to notify the SMF in the 5GC about the change in traffic patterns. The SMF, in turn, acts upon the traffic influence rules initiated by the AF and updates the PDU session.

It is important to note that AF requests targeting an individual UE by a UE address are routed to an individual PCF using the BSF. This routing ensures that the AF can accurately identify the UE, which is necessary for proper traffic influence.

In summary, with the help of the NEF and SMF, the AF can seamlessly migrate to another edge cluster, ensuring uninterrupted service to the end-users. This use case highlights the importance of proper traffic routing and communication between 5GC functions to ensure a smooth and efficient network experience.

High availability (HA) is an important aspect of any production deployment. In the context of Kubernetes, HA is achieved by deploying multiple nodes for workers as well as masters. This ensures that in case of node failures, the workload can be distributed to other nodes, ensuring high availability.

In the case of AMCOP deployment on Kubernetes, HA is essential to ensure that all services are still reachable in the event of node failures. To validate this, we deployed AMCOP on a multi-node cluster and simulated a graceful shutdown of nodes. During this process, we ran continuous tests that accessed  various services to ensure they were still available, including:

• Cluster automation: This  continuously adds and removes clusters to/from AMCOP. The idea here is that the script will ensure the availability of all cluster management services in the EMCO module of AMCOP.
• CDS Workflow: This continuously tests CBA (Controller Blueprint Archive)  in a loop. This ensures that CDS, Camunda and mariadb pods are live and responding.
• SMO: Similar tests to run basic configuration operations on CU/DU simulators.

To achieve HA, we recommend the following configuration:

• Deploy multiple worker nodes: This ensures that workload can be distributed across multiple nodes and avoids a single point of failure.
• Deploy multiple master nodes: This ensures that if a master node fails, there are other nodes available to take over the workload.
• Use a load balancer: This ensures that requests are distributed evenly across all nodes, preventing any one node from becoming overwhelmed.

It's important to note that while k8s has built-in resilience to handle node failures, there are certain cases where administrator intervention is needed, particularly for stateful applications and persistent volumes. In these cases, it's important to have a disaster recovery plan in place to minimize downtime and ensure data integrity.

In conclusion, HA deployment on Kubernetes is crucial to ensure high availability of services and to minimize downtime in the event of node failures. Continuous testing and monitoring can help ensure that all services are still reachable, and a disaster recovery plan can help minimize the impact of any hardware failures. By following these best practices, AMCOP deployments can ensure a high level of reliability and availability.

‍

Aarna.ml has recently released a new version of its open source orchestration platform, the Aarna.ml Multi Cluster Orchestration Platform (AMCOP) v3.2. This platform aims to solve management complexity for edgenative and 5G network services, providing orchestration, lifecycle management, and real-time policy, closed-loop automation capabilities. This blog post covers the new features, enhancements, and additions in this latest version of AMCOP.

I. New Feature Addition

One of the new features of AMCOP v3.2 is the startup config push from SMO (Service Management Orchestrator) to RAN (Radio Access Network) elements. This feature automatically pushes configuration to a new device when it connects for the first time. To use this feature, the desired startup config must be added to SMO via a REST API before connecting the device. SMO provides APIs to manage (add/view/delete) the desired configuration.

Another new feature is the cell setup/active/inactive capability. SMO will perform cell setup to DU (Distributed Unit) or cell active/inactive to CU (Central Unit) based on the synchronization-state change of the RU (Radio Unit).

AMCOP v3.2 also includes RU carrier activation, which performs active or inactive to all the carriers of the respective RU based on the cell status (in-service/out-of-service) netconf notification from CU/DU.

II. Additional Capabilities on Observability and Monitoring

AMCOP v3.2 has added new capabilities on observability and monitoring. It now includes ELK (Elasticsearch, Logstash, Kibana) integration, which provides centralized logging to identify problems with servers or applications. It allows you to search all the logs in a single place and helps to find issues in multiple servers by connecting logs during a specific time frame. To use this feature, you need to have a separate K8s cluster up and running to deploy the ELK stack.

AMCOP v3.2 also includes Prometheus and Grafana Orchestration, which enables telemetry service for target cluster monitoring. Prometheus federate (scrape approach) is used for target Kubernetes cluster and host server resource monitoring.

III. Addition of a new northbound interface (SOL-005)

AMCOP v3.2 now supports ETSI SOL005 Interface, which is related to network service management and VNF (Virtual Network Function) onboarding towards OSS/BSS (Operations Support System/Business Support System). SOL005 Interface fulfills the requirements defined in ETSI NFV IFA013.

IV. Greater Stability

AMCOP v3.2 has been stabilized for production readiness. Several fixes have been made to harden this version and make it ready for deployment in the production stage. The platform now has better fault management, alarm generation, failure handling, smooth migration, and service deletion.

In conclusion, the latest release of Aarna.ml Multi Cluster Orchestration Platform (AMCOP) v3.2 includes new features and enhancements that enable greater automation, observability, and stability for edge native and 5G network services. The addition of new capabilities on observability and monitoring, as well as the support for a new northbound interface, makes AMCOP v3.2 a more complete and robust platform for managing network services.

Learn more about ACMOP and request a free trial.

STL Partners published an interesting report a couple of weeks ago titled “Why is now the time to rethink edge orchestration?” I fully agree with the entire contents of the report and here is my take on why edge orchestration is different. Different from what, you might ask? Different from telco MANO (management and orchestration) and cloud orchestration. 

I think there are four key reasons why edge orchestration is different:

1. Scale: This is the most obvious reason. The scale of edge orchestration is orders of magnitude greater than traditional networks. It is not unusual to have tens of thousands of edge sites in the enterprise or telco context. Walmart announced 10K edge sites a couple of years ago. I was just talking to a senior executive at Telefonica, and he mentioned that there are 10K central offices and 20K baseband locations just in Spain. Orchestrating hundreds of network services or applications across tens of thousands of sites creates scale complexity.
2. Heterogeneity: I compare the cloud to a departmental store. It is provided by one company; it is consistent, coherent, and orderly. The edge is a bazaar. Just at a cloud edge such as Equinix, you have multiple compute providers (e.g. Equinix Metal, AWS Outposts, HPE Greenlake, Zenlayer), multiple storage providers (e.g. NTAP, Dell APEX, Seagate Lyve, Pure Storage), multiple CaaS providers (e.g. Red Hat OpenShift, AWS EKS Anywhere, Google Anthos), multiple network function providers (Cisco, Fortinet, Palo Alto), and multiple connectivity providers (e.g. Equinix Fabric, Megaport, TATA Communications). Orchestrating environments in a bazaar is much harder than in a departmental store. 
3. Dependencies: The whole mantra of the cloud has been to break the dependency between the workload and the underlying infrastructure. However, at the edge, this is impractical. Networking, machine learning, and AR/VR workloads have infrastructure dependencies. To further complicate matters, these applications also have network service dependencies such as Private 5G. In other words, at the edge, the infrastructure, applications, and network services all have to be orchestrated in a concerted fashion.
4. Dynamism: The edge is dynamic. At the fall 2022 GTC, Chris Lamb from NVidia presented the concept of a multiservice RAN where, like Batman, the RAN infrastructure changes its entire persona from day to night. During the day (or periods of high utilization), the edge runs a RAN workload. During the night (or periods of low utilization), the edge runs AI/ML workloads. There are many other examples and reasons for why the edge is more dynamic than the cloud.

This means that existing orchestration mechanisms don’t work in this new paradigm, and that there is a need for a new set of tools. Please contact us to discuss this topic in more depth.

The Aarna.ml Multi Cluster Orchestration Platform (AMCOP) is purpose built for edge orchestration. Learn more here. Free consultations and trials are available.