Mobile networks are standardized mainly by 3GPP, a process the guest lecture (Francesco Foresta, JMA Wireless) describes with three honest caveats: it is discussed mostly among vendors, who tend to lock in as much as possible; it allows some gray areas that lead to unstandardized elements impossible to interoperate (lock-in!); and it is broad — anything outside the principal working groups may be standard but unused.
The market context explains the pressure. Network elements are typically proprietary black boxes: need to manage a box? Write a custom script or procedure. Changing device? A new custom procedure. No internal knowledge? Dependency on the vendor. Meanwhile Over-The-Tops (Google, Amazon, Netflix, …) capture the revenues while telco operators are squeezed from two sides — pushed by OTTs to provide better services (4G → 5G) and by customers to lower prices. Traffic demand grows relentlessly (Super Bowl data usage went from ~10 TB in 2015 to 66.5 TB in 2018, mostly WiFi), but revenues stay flat while network costs climb: traditional network equipment costs challenge growth needs.
Looking at the traditional xG RAN (Radio Unit + BaseBand Unit), the slide lists four structural problems: (1) proprietary network; (2) lack of clear northbound APIs for MANO — valid for all domains; (3) closed solution; (4) monolithic solution. The consequence is lock-in: the customer depends on the vendor for maintenance and updates — an OPEX increase. This is the exact "ossified network" problem of chapter 1, now in the radio access.
Because 3GPP is mainly driven by vendors, the O-RAN alliance was created, mainly driven by operators, to achieve a multi-vendor, interoperable, autonomous RAN through three levers:
The resulting architecture replaces the proprietary RU↔BBU link with an Ethernet-based network: a standard fronthaul allows vendor interoperability, the BBU software runs on open cloud platforms (BBU SW 1, BBU SW 2 as virtualized instances), and clear APIs for all MANO aspects are defined — SDN orchestration treats all the RAN elements as network devices. The market requires open-minded solutions: cloudification of the RAN over standard open cloud platforms, and multi-operator interoperable solutions.
This also improves geographical scalability: it becomes easier to split the RAN into several virtualized elements and orchestrate them, enabling distributed and scalable architectures. Function placement runs along a spectrum: site location → far edge → edge, with DU SW (distributed-unit software) at the far edge and CU SW (centralized-unit software) at the edge — the functional split of chapter 12 made deployable. As VMs or containers, CU and DU are orchestrated by OpenStack, Kubernetes, etc. on open cloud platforms.
O-RAN standardizes 4G and 5G 3GPP gray areas such as fronthaul networking, virtualization and orchestration (aligned with ETSI MANO), and FPGA abstraction layers. Most of the specs can be supported even for 2G — all the still-active xG standards are covered. Backward compatibility is not an afterthought; it is how a deployed network migrates without being rebuilt.
MANO (Management and Orchestration) moves network functions from bare metal / proprietary environments into a common, shared environment — "open" — owned by the operator. The question is how, in a standard way. Two approaches:
| Platform-dependent solutions | Open solutions |
|---|---|
| VM-only related solutions, or container-only related solutions — tied to one platform's way of doing things. | Open efforts, mainly for VMs, aligned with ETSI MANO and the broader open-source ecosystem. |
SDN then works at different levels of the stack: open cloud platforms' networking strongly relies on SDN, and the VNFs themselves expose SDN APIs to get configured — in the slide, the DU SW and CU SW instances on the open cloud platforms are reached over NETCONF. This is the same story as chapter 2 (NFV) and chapter 8 (control planes talking to data planes), now applied to the RAN: the network functions are software, and software is configured programmatically.
MANO = moving network functions from bare metal or proprietary boxes into a common shared environment owned by the operator, done in a standard way (ETSI MANO; open efforts mainly for VMs). The RAN elements become manageable assets — exactly the asset-centric view of chapters 10 and 11, now at the scale of an entire mobile network.
The hard question: how do you enforce performance when VNFs share a server? The lecture lists four techniques, in increasing order of "getting the kernel out of the way":
| Technique | Mechanism |
|---|---|
| Resource pinning | cgroups and namespaces (containers!), CPU pinning, etc. — binding a VNF to specific cores and limiting its resource group. |
| SR-IOV | Partitioning a NIC such that no switching is performed on the kernel — virtual functions pass packets directly to the guest. |
| DPDK | A set of libraries allowing "zero-copy" work — the kernel is not involved in packet creation; the application polls the NIC directly (userspace networking). |
| Accelerators | PCIe devices that offload intensive computing functions, paired with SR-IOV and DPDK. Are there common APIs? O-RAN is working on it. |
These are the same acceleration techniques chapter 2 promised to revisit — the performance gap between software forwarding and the wire. The continuum is the course's own: namespaces (chapters 2–4) → OvS/DPDK (chapter 2) → P4 in silicon (chapters 5–8). In the mobile context the question is where the baseband and user-plane functions run, and how fast the shared infrastructure can forward their packets.
The lecture ends with an honest doubt: shifting to Open RAN requires cloud infrastructure and high-performance hardware — how could an operator maintain them without competences? Is shifting to Open RAN a new lock-in, no longer on traditional vendors but on infrastructure vendors (Intel, Red Hat, …)? O-RAN is trying to assess the risks. The benefit, though: O-RAN allows high-quality smaller companies to partner together and achieve great results, with better CAPEX/OPEX.
Operators want to manage the devices — configure, read, get alarms, get performance data. The OAM requirements:
The answer has two halves, and the division of labour is precise. YANG (RFC 6020) is a data modelling language: it explicitly and precisely determines the structure, syntax and semantics of the externally visible data — the data model. NETCONF (RFC 6241) is the protocol with primitives to view and manipulate that data: the data encoding is defined by the data model. Together: "by defining YANG models, through NETCONF we get the APIs to submit any operations to these devices although they are black boxes for the client."
NETCONF uses XML encoding over an SSH/TCP transport stack, and it embodies consistent transactions (ACID): validate/backup/restore are available through different configuration stores — Startup, Running, Candidate (confirm-commit). The operational benefits are the three pains of manual configuration, removed: immediate configuration validation through YANG models (no need to figure out the order of config changes), no need to recover if a change fails (no transaction content has been activated), and confirm or roll-back.
Every NETCONF session starts with an <hello> message, during which the server exposes its capabilities: some are defined by the NETCONF spec, each YANG data model is an additional capability, and extensions and other standards can be added. By declaring support for a capability in <hello>, the client knows which operations it can submit to the device.
The layering model, top to bottom:
<get>, <get-config>, <edit-config>, <copy-config>, <lock>/<unlock>, <commit>, …;<rpc> / <rpc-reply> framing, <notification>;Configuration data lives in datastores: the startup datastore (what the device loads at boot), the running datastore (the active configuration), and the candidate datastore (a scratch space you edit freely and commit with a single <commit> — with confirm-commit for roll-back). <get> returns running configuration plus state data; <edit-config> applies a change to a target datastore.
YANG itself is a tree-structured, human-readable modelling language for configuration and state data, providing data and types to model devices, and allowing constraints (range, must, when, min-elements, max-elements) — configuration validity does not depend on state. Models move to XML easily (YIN is defined in the same RFC); moving to JSON is more complex but feasible if the implementation sticks to the YANG model.
The closing picture is 5G end-to-end programmability: NETCONF reaches every segment — the RU, the DU, the CU, the core functions — and YANG models appear at every level: O-RAN YANG for the RAN, 3GPP YANG for the core, with proprietary models and the OpenConfig effort filling the gaps (the "YANG?" question marks in the slide are the grey areas where interoperability is still being negotiated). This is the mobile-network version of the course's core claim: a network that can describe and expose itself, in standardized, machine-readable form.
The concrete demonstration is Zero Touch Provisioning (ZTP) in O-RAN: the standard defines how a Remote Unit (RU) should call home for its Distributed Unit (DU) — no human intervention. The steps, in order:
After step 9 the DU has all the knowledge it needs from the RU — the RU is up and running. Note the pattern: it is the same sequence chapter 10's PKIOTA compressed into two steps (connect the device, sign and push its certificate), now standardized for the radio access. Provisioning, like everything else in this course, is a programmable-network problem.
Chapter 1 asked how a forty-year-ossified network becomes programmable. The answer accumulated across the course: namespaces and containers (chapters 2–4), P4 data planes and controllers (chapters 5–8), the industrial asset view (chapters 9–11), the mobile architecture (chapter 12) — and here, the RAN and core themselves become software, modelled in YANG, configured over NETCONF, orchestrated by MANO, accelerated by SR-IOV/DPDK. There is no Telco without software — which is also why this course exists.
(1) It is discussed mostly among vendors, who tend to lock in as much as possible; (2) it allows gray areas that lead to unstandardized elements impossible to interoperate (lock-in); (3) it is broad — anything besides the principal working groups may be standard but not in use.
(1) Proprietary network; (2) lack of clear northbound APIs for MANO (valid for all domains); (3) closed solution; (4) monolithic solution. Consequence: lock-in and OPEX increase, with the customer dependent on the vendor for maintenance and updates.
O-RAN is a standardization alliance mainly driven by operators (unlike 3GPP, driven by vendors) to achieve a multi-vendor, interoperable, autonomous RAN through: virtualized network elements (smarter techniques), whitebox hardware (shareability), and standardized interfaces where 3GPP lacked (avoiding lock-in).
The proprietary RU↔BBU link becomes an Ethernet-based network with a standard fronthaul enabling vendor interoperability; BBU software runs on open cloud platforms (BBU SW instances); clear APIs for all MANO aspects are defined, with SDN orchestration treating all RAN elements as network devices. It improves geographical scalability (DU SW at far edge, CU SW at edge, orchestrated by OpenStack/Kubernetes).
MANO (Management and Orchestration) moves network functions from bare metal / proprietary environments into a common, shared, "open" environment owned by the operator, in a standard way. Approaches: platform-dependent solutions (VM-only or container-only related) vs open solutions (open efforts, mainly for VMs, aligned with ETSI MANO).
Open cloud platforms' networking strongly relies on SDN (the infrastructure fabric is SDN-controlled), and the VNFs themselves expose SDN APIs to get configured — e.g. DU/CU software instances reached over NETCONF. Configuration and data-plane behaviour are both programmatic.
Resource pinning (cgroups, namespaces, CPU pinning), SR-IOV (partitioning a NIC so no switching is performed on the kernel — virtual functions), DPDK (zero-copy libraries, kernel not involved in packet creation — userspace polling), accelerators (PCIe devices offloading intensive computing, paired with SR-IOV/DPDK; O-RAN working on common APIs).
Every device should expose the same API; every device should have the same data model (or at most extended); nice to have: transactions ("change IP to 1.1.1.1/24 on device X" atomically), several datastores, easy validation.
YANG (RFC 6020) is the data modelling language: it explicitly and precisely determines the structure, syntax and semantics of the externally visible data. NETCONF (RFC 6241) is the protocol with primitives to view and manipulate that data — the data encoding is defined by the data model. By defining YANG models, NETCONF gives the APIs to submit operations to devices that remain black boxes for the client.
The operator request (e.g. "change IP address to 1.1.1.1/24 on device X") is validated against the YANG model; depending on the configuration store, changes are validated and committed; then a callback (C, Python, Erlang, …) runs the internal OAM procedure (e.g. rewrite a config file and restart the network service). NETCONF embodies ACID transactions with Startup/Running/Candidate stores and confirm-commit.
The server exposes its capabilities: some defined by the NETCONF spec, each YANG data model as an additional capability, plus extensions and other standards. By declaring support for a capability in <hello>, the client knows which operations it can submit to the device. NETCONF also supports event notifications (subscribe, get notified on conditions, keep track of alarms).
The RU calls home for its DU: retrieve DHCP/MAC/VLAN/IP/network info; perform synchronization; manage the DU–RU NETCONF/SSH connection; capability discovery; user accounts and access control; DU retrieves RU info, SW management, RU firmware updates; C/U transport connectivity and delay profile; FM/PM activation; service active — all without human intervention.
Shifting to Open RAN requires cloud infrastructure and high-performance hardware — how could an operator maintain them without competences? Is Open RAN a new lock-in, this time on infrastructure vendors (Intel, Red Hat, …)? O-RAN is assessing the risks; the benefit is that high-quality smaller companies can partner together, allowing better CAPEX/OPEX.