live wire
▸AI · EAGLE-4 0.1.4 fixes multi-GPU vLLM collective ordering during startupEAGLE-4▸SECURITY: Apache Camel 4.23.0, 4.22.2 and 4.18.5 fix eight component vulnerabilitiesApache Camel▸AI · Red Hat shows DRA doubles llm-d KV-cache throughput by aligning GPUs and RDMA NICsRed Hat Developer▸Red Hat Developer Hub 1.9.10 ships as a Critical security updateRed Hat errata▸OpenShift Dev Spaces 3.31 adds live editor switching and DevWorkspace Operator 1.0Red Hat documentation▸OpenShift Pipelines 1.24.1 tightens Manual Approval Gate RBAC and approval integrityRed Hat release notes▸AI · Red Hat survey: 97% of UK CIOs trust agent security, but 43% can trace data flowsRed Hat▸JAVA · IBM and Kaggle launch a living benchmark for agentic Java framework migrationsIBM Research▸AI · Red Hat tests policy-derived data controls for AI agentsRed Hat▸Apache Camel pattern turns routes into bounded LLM tools and MCP servicesRed Hat Developer▸Atos tunes small models on OpenShift AI for structured German-language analysisRed Hat Developer▸Red Hat publishes checklist for evaluating third-party OpenShift applicationsRed Hat Developer▸SECURITY · OpenShift 4.21.40 patches OpenSSL, OpenSSH and PCRE2 flawsRed Hat Product Security▸SECURITY · Apache Camel fixes A2A webhook SSRF gap in 4.22.2 and 4.23.0 (Oct. 23)Apache Camel▸AI · EAGLE-4 0.1.4 fixes multi-GPU vLLM collective ordering during startupEAGLE-4▸SECURITY: Apache Camel 4.23.0, 4.22.2 and 4.18.5 fix eight component vulnerabilitiesApache Camel▸AI · Red Hat shows DRA doubles llm-d KV-cache throughput by aligning GPUs and RDMA NICsRed Hat Developer▸Red Hat Developer Hub 1.9.10 ships as a Critical security updateRed Hat errata▸OpenShift Dev Spaces 3.31 adds live editor switching and DevWorkspace Operator 1.0Red Hat documentation▸OpenShift Pipelines 1.24.1 tightens Manual Approval Gate RBAC and approval integrityRed Hat release notes▸AI · Red Hat survey: 97% of UK CIOs trust agent security, but 43% can trace data flowsRed Hat▸JAVA · IBM and Kaggle launch a living benchmark for agentic Java framework migrationsIBM Research▸AI · Red Hat tests policy-derived data controls for AI agentsRed Hat▸Apache Camel pattern turns routes into bounded LLM tools and MCP servicesRed Hat Developer▸Atos tunes small models on OpenShift AI for structured German-language analysisRed Hat Developer▸Red Hat publishes checklist for evaluating third-party OpenShift applicationsRed Hat Developer▸SECURITY · OpenShift 4.21.40 patches OpenSSL, OpenSSH and PCRE2 flawsRed Hat Product Security▸SECURITY · Apache Camel fixes A2A webhook SSRF gap in 4.22.2 and 4.23.0 (Oct. 23)Apache Camel
upstreambeat.ai
newsPLATFORM

Telenor uses OpenShift to keep a remote 5G edge running through backhaul outages

A distributed AxyomCore deployment pairs a central core in Fornebu with an autonomous edge core in Svalbard, using OpenShift as the common platform layer.

Central 5G core and autonomous edge core handling outage locally.
Side by side: what changed
By The News Desk· Oct 6, 2026the quick take — two AI hosts go live when you do

Red Hat has detailed a distributed 5G core deployment in which Telenor uses AxyomCore on Red Hat OpenShift to preserve local service when a remote site loses its connection to the central network. The architecture places a central core in Fornebu, Norway, and an on-premise edge core in Svalbard, roughly 2,000 kilometers away. Red Hat published the implementation outline on October 6.

A local core that takes over automatically

During normal operation, the two sites synchronize subscriber data, policies and configuration. When the backhaul link fails, the Svalbard edge core takes over automatically and continues operating as a local 5G network without manual intervention, according to Red Hat. That design is intended to keep voice, data and operational services available at remote sites during disruptions.

AxyomCore supplies the cloud-native 5G core functions, including both control-plane and user-plane capabilities. OpenShift provides the common application-platform layer across the central and edge environments, with the same deployment and lifecycle-management model at each site.

The implementation also keeps a user-plane function at the edge with local breakout. Instead of routing traffic through the central core, applications can communicate locally, reducing latency for workloads such as real-time video, remote control and monitoring systems.

What platform teams can take from it

The noteworthy element is not simply that a containerized network function runs on Kubernetes. The deployment treats loss of the wide-area connection as a normal operating condition: state is synchronized while the link is available, then the local control and user planes sustain service independently when it is not.

For platform teams supporting far-edge sites, the pattern makes three requirements concrete. The application stack must fit constrained locations, lifecycle operations must remain consistent across distributed installations, and service continuity cannot depend on an operator intervening after the link has already failed.

Red Hat says AxyomCore’s network functions have been validated, qualified and deployed in production on OpenShift. The same 5G core functions have also been demonstrated on Google Cloud and Amazon Web Services, though the Telenor example centers on OpenShift spanning the Fornebu and Svalbard locations.

The post does not disclose availability metrics, recovery times or the specific OpenShift topology at either site. Those omissions limit comparison with other edge designs, but the published architecture still provides a useful production reference for autonomous service operation across an intermittently connected edge.

Filed by The News Desk. Corrections: desk@upstreambeat.ai · Our standards →

comments · 0

    Comments are moderated before they appear. Your email is used once to confirm it is you — never shown, never sold. Corrections and questions get an answer from the desk when we have one.