live wire
▸PLATFORM · Quay.io push and pull operations hit intermittent 500 errors during maintenanceRed Hat status▸INTEGRATION · Apache Camel exposes incident and web search as parallel tools for a local agentApache Camel▸AI · Red Hat makes confidential GPU AI GA and previews VM-isolated Agent Sandbox (Aug. 4)Red Hat Blog▸SECURITY · Red Hat fixes Important MariaDB GIS memory-corruption flaw in Hardened ImagesRed Hat Product Security▸SECURITY · Red Hat restores CVE pages after a CWE dependency outage; monitoring continuesRed Hat status▸PLATFORM · Red Hat implements a fix for docs.redhat.com degradation and begins monitoringRed Hat status▸AI · vLLM combines PCP, DCP and host-memory offload to serve 1M-token GLM-5.3 contextsvLLM▸AI · vLLM ships day-zero MiniMax-M3.1-Flash support across NVIDIA and AMD GPUsvLLM▸SECURITY · Red Hat revokes compromised eMudhra certificates across RHEL and OpenShift trust storesRed Hat Product Security▸SECURITY · Red Hat rates PHP2Shell request-handling flaws Important; fixes are rolling outRed Hat Product Security▸AI · IBM maps GPU observability and FinOps controls across OpenShift clustersIBM Community▸IDENTITY · Red Hat shows Data Grid authentication through Keycloak 26 on OpenShiftRed Hat Developer▸AI · Red Hat layers tenant isolation, tool authorization and rate limits onto MCP gatewaysRed Hat Developer▸DATA · Red Hat maps direct LDAP and LDAPS authentication for Data Grid on OpenShiftRed Hat Developer▸PLATFORM · Quay.io push and pull operations hit intermittent 500 errors during maintenanceRed Hat status▸INTEGRATION · Apache Camel exposes incident and web search as parallel tools for a local agentApache Camel▸AI · Red Hat makes confidential GPU AI GA and previews VM-isolated Agent Sandbox (Aug. 4)Red Hat Blog▸SECURITY · Red Hat fixes Important MariaDB GIS memory-corruption flaw in Hardened ImagesRed Hat Product Security▸SECURITY · Red Hat restores CVE pages after a CWE dependency outage; monitoring continuesRed Hat status▸PLATFORM · Red Hat implements a fix for docs.redhat.com degradation and begins monitoringRed Hat status▸AI · vLLM combines PCP, DCP and host-memory offload to serve 1M-token GLM-5.3 contextsvLLM▸AI · vLLM ships day-zero MiniMax-M3.1-Flash support across NVIDIA and AMD GPUsvLLM▸SECURITY · Red Hat revokes compromised eMudhra certificates across RHEL and OpenShift trust storesRed Hat Product Security▸SECURITY · Red Hat rates PHP2Shell request-handling flaws Important; fixes are rolling outRed Hat Product Security▸AI · IBM maps GPU observability and FinOps controls across OpenShift clustersIBM Community▸IDENTITY · Red Hat shows Data Grid authentication through Keycloak 26 on OpenShiftRed Hat Developer▸AI · Red Hat layers tenant isolation, tool authorization and rate limits onto MCP gatewaysRed Hat Developer▸DATA · Red Hat maps direct LDAP and LDAPS authentication for Data Grid on OpenShiftRed Hat Developer
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.