live wire
▸Red Hat ships important MicroShift 4.16.73 security updateRed Hat Product Errata▸AI · Red Hat maps local AI Inference serving and load tests on RHEL (Oct. 15)Red Hat Emerging Technologies▸PLATFORM · IBM guide maps Secure Execution VMs onto OpenShift Virtualization for LinuxONEIBM Community▸AI · vLLM maps Nemotron 3.5 Super VL across Hopper, Blackwell and Red Hat DSpark (Oct. 15)vLLM Recipes▸AI · AWS contributes push-based KV transfer to vLLM, reporting 3x better TTFT under loadAWS Machine Learning Blog▸AI · AWS contributes bidirectional KV transfer to vLLM, cutting multi-turn TTFT up to 3.3xAWS Machine Learning Blog▸AI · vLLM Semantic Router adds d3-turbo with box and video-tracking decisionsvLLM Semantic Router▸IDENTITY · Keycloak DevDay 2027 opens call for deep technical talks through Oct. 24Keycloak▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security▸Red Hat ships important MicroShift 4.16.73 security updateRed Hat Product Errata▸AI · Red Hat maps local AI Inference serving and load tests on RHEL (Oct. 15)Red Hat Emerging Technologies▸PLATFORM · IBM guide maps Secure Execution VMs onto OpenShift Virtualization for LinuxONEIBM Community▸AI · vLLM maps Nemotron 3.5 Super VL across Hopper, Blackwell and Red Hat DSpark (Oct. 15)vLLM Recipes▸AI · AWS contributes push-based KV transfer to vLLM, reporting 3x better TTFT under loadAWS Machine Learning Blog▸AI · AWS contributes bidirectional KV transfer to vLLM, cutting multi-turn TTFT up to 3.3xAWS Machine Learning Blog▸AI · vLLM Semantic Router adds d3-turbo with box and video-tracking decisionsvLLM Semantic Router▸IDENTITY · Keycloak DevDay 2027 opens call for deep technical talks through Oct. 24Keycloak▸AI · vLLM Recipes maps Muse Spark Open to single-node Blackwell and AMD deployment (Oct. 16)vLLM▸PLATFORM · Clang 23 bytecode interpreter cuts allocations and expands constant-expression supportRed Hat Developer▸PLATFORM · RHEL becomes first-party on OCI; OpenShift subscriptions reach Oracle MarketplaceRed Hat▸AI · vLLM-Omni merges native MOSS-Image serving with parallelism and offloadvLLM▸AI · vLLM adds System One endpoint for Decision 3.0 multimodal routing models (Oct. 15)vLLM▸SECURITY · Red Hat rates OpenShift AI 3.4.5 update Critical; advisory lists hundreds of CVEsRed Hat Product Security
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.