<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Cloud-Native on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/cloud-native/</link><description>Recent content in Cloud-Native on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/tags/cloud-native/index.xml" rel="self" type="application/rss+xml"/><item><title>5G Core (5GC)</title><link>https://lesitedefrancois.be/en/telco/5gc/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/telco/5gc/</guid><description>&lt;p&gt;The &lt;strong&gt;5G Core (5GC)&lt;/strong&gt; is the packet core network architecture defined by &lt;strong&gt;3GPP&lt;/strong&gt; from &lt;strong&gt;Release 15&lt;/strong&gt; onward as the control and user-plane backbone of standalone 5G deployments. It replaces the Evolved Packet Core (EPC) of 4G LTE not through incremental evolution but through a deliberate architectural break: where the EPC was built around monolithic, hardware-bound network functions interconnected by point-to-point interfaces, the 5GC is designed from the ground up around a &lt;strong&gt;Service-Based Architecture (SBA)&lt;/strong&gt; — every network function exposes its capabilities as a set of services over a &lt;strong&gt;common HTTP/2 bus&lt;/strong&gt; (the Service-Based Interface, SBI), and any authorised consumer NF can discover and invoke those services through the &lt;strong&gt;NRF (Network Repository Function)&lt;/strong&gt; without bilateral peering agreements or proprietary protocols. This shift reflects two structural requirements of 5G that EPC could not satisfy: &lt;strong&gt;network slicing&lt;/strong&gt; — the ability to run logically independent end-to-end networks (each with its own QoS, isolation, and lifecycle) on shared physical infrastructure — and &lt;strong&gt;cloud-native deployment&lt;/strong&gt;, where NFs run as containerised microservices on commodity compute, can be horizontally scaled, and are managed by standard Kubernetes-compatible orchestration rather than vendor-specific element managers. The 5GC also enforces a hard separation between &lt;strong&gt;Control Plane (CP)&lt;/strong&gt; and &lt;strong&gt;User Plane (UP)&lt;/strong&gt; — the &lt;strong&gt;CUPS&lt;/strong&gt; principle inherited from 3GPP Release 14 and fully operationalised here — so that the &lt;strong&gt;UPF (User Plane Function)&lt;/strong&gt; handling packet forwarding, QoS enforcement, and traffic anchoring can be distributed to the edge independently of the control logic, enabling ultra-low-latency and MEC scenarios without redesigning the control plane. The architecture is access-agnostic: the same 5GC serves &lt;strong&gt;NR (New Radio)&lt;/strong&gt;, &lt;strong&gt;eLTE&lt;/strong&gt;, &lt;strong&gt;Wi-Fi (untrusted/trusted non-3GPP access)&lt;/strong&gt;, and fixed-wireless access through a unified &lt;strong&gt;N2/N3&lt;/strong&gt; reference point toward the access network and a common &lt;strong&gt;UE context&lt;/strong&gt; model in the AMF.&lt;/p&gt;</description></item><item><title>DPDK</title><link>https://lesitedefrancois.be/en/telco/dpdk/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/telco/dpdk/</guid><description>&lt;p&gt;The &lt;strong&gt;Data Plane Development Kit (DPDK)&lt;/strong&gt; is an &lt;strong&gt;open-source&lt;/strong&gt; set of libraries and &lt;strong&gt;poll-mode drivers (PMDs)&lt;/strong&gt; that move &lt;strong&gt;packet processing&lt;/strong&gt; from the kernel to &lt;strong&gt;userspace&lt;/strong&gt;, enabling telco and cloud applications to achieve &lt;strong&gt;millions of packets per second&lt;/strong&gt; per core with &lt;strong&gt;predictable latency&lt;/strong&gt;. DPDK bypasses the traditional socket stack: applications &lt;strong&gt;busy-poll&lt;/strong&gt; NIC queues (or &lt;strong&gt;virtio/vhost&lt;/strong&gt; rings), use &lt;strong&gt;hugepages&lt;/strong&gt; to reduce TLB misses, and pin threads to &lt;strong&gt;NUMA-local&lt;/strong&gt; cores — a model suited to &lt;strong&gt;UPF&lt;/strong&gt;, &lt;strong&gt;vRouter&lt;/strong&gt;, &lt;strong&gt;CG-NAT&lt;/strong&gt;, &lt;strong&gt;load balancers&lt;/strong&gt;, and &lt;strong&gt;5G user-plane&lt;/strong&gt; functions where per-packet syscall overhead is unacceptable.&lt;/p&gt;</description></item><item><title>SR-IOV</title><link>https://lesitedefrancois.be/en/telco/sr-iov/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/telco/sr-iov/</guid><description>&lt;p&gt;&lt;strong&gt;SR-IOV (Single Root I/O Virtualisation)&lt;/strong&gt; is a &lt;strong&gt;PCI-SIG&lt;/strong&gt; specification that lets one physical &lt;strong&gt;PCIe&lt;/strong&gt; device (typically a &lt;strong&gt;NIC&lt;/strong&gt; or accelerator) expose multiple lightweight &lt;strong&gt;Virtual Functions (VFs)&lt;/strong&gt; — each assignable directly to a &lt;strong&gt;VM&lt;/strong&gt; or container — while a &lt;strong&gt;Physical Function (PF)&lt;/strong&gt; remains for management and global configuration. VFs bypass much of the hypervisor’s software switching path, delivering &lt;strong&gt;lower latency&lt;/strong&gt;, &lt;strong&gt;higher throughput&lt;/strong&gt;, and more &lt;strong&gt;deterministic&lt;/strong&gt; behaviour than &lt;strong&gt;paravirtualised virtio&lt;/strong&gt; alone — properties valued in &lt;strong&gt;telco NFV&lt;/strong&gt; (vEPC, vRAN CU/DU, firewall, DPI) and in &lt;strong&gt;cloud-native&lt;/strong&gt; packet workloads on &lt;strong&gt;Kubernetes&lt;/strong&gt;.&lt;/p&gt;</description></item></channel></rss>