Description
A Virtualized Resource (VR) is a key concept within the 3GPP management framework, particularly for the management of virtualized network functions (VNFs) in a cloud-native environment. It represents a logical abstraction of a physical resource, such as a CPU core, a block of memory, a storage volume, or a virtual network interface card (vNIC). These abstractions are created and managed by a virtualization layer (e.g., a hypervisor or container runtime) on top of physical hardware. The 3GPP management system, defined in specifications like 28.520 (Management and Orchestration, MANO), interacts with VRs to allocate, monitor, and orchestrate them for the purpose of instantiating and scaling network functions.
The architecture involves several key entities. The Virtualized Infrastructure Manager (VIM) is responsible for controlling and managing the NFVI (Network Functions Virtualization Infrastructure) compute, storage, and network resources. The VIM exposes these resources as VRs. The NFV Orchestrator (NFVO) and VNF Manager (VNFM) then use these VRs, described in a VNF Descriptor (VNFD), to deploy VNFs. A VNFD defines the VNF's requirements in terms of Virtualized Compute, Storage, and Network Resources (Vnfc, VnfStorage, VnfVirtualLink). During instantiation, the MANO system maps these requirements to available VRs on the infrastructure, creating the necessary virtual machines (VMs) or containers with the specified CPU, memory, and network connectivity.
VRs are dynamic and elastic. Their lifecycle (creation, modification, termination) is managed through standardized interfaces, such as the Or-Vi reference point between the NFVO and VIM. Monitoring of VR performance metrics (e.g., CPU utilization, memory usage, I/O rates) is also standardized, allowing the MANO system to perform automated scaling actions. For example, if a VNF experiences high load, the VNFM can request additional virtualized compute resources (more VRs) from the VIM via the NFVO, leading to the scaling out of the VNF instance. This abstraction is crucial for achieving the goals of NFV: hardware independence, efficient multi-tenancy, and agile service deployment.
Purpose & Motivation
The concept of the Virtualized Resource was introduced to address the limitations of traditional telecom networks built on proprietary, physical appliances. These appliances were tightly coupled to specific hardware, leading to long procurement and deployment cycles, inefficient resource utilization (often over-provisioned for peak capacity), and high operational costs. The shift towards Network Functions Virtualization (NFV), championed by industry forums like ETSI ISG NFV and adopted by 3GPP, required a standardized way to model and manage the software-based resources that would replace physical network functions.
The creation of the VR abstraction in 3GPP specifications, notably from Rel-13 onwards, provided this standardized model. It solved the problem of heterogeneity in cloud infrastructure by defining a common set of resource types (compute, storage, network) and their management interfaces, regardless of the underlying hypervisor (VMware, KVM, etc.) or hardware vendor. This allows network operators to deploy VNFs from different vendors on a common, shared pool of physical resources, enabling true multi-vendor interoperability and preventing vendor lock-in at the infrastructure layer. The VR model is the foundation for automation, elastic scaling, and the efficient "cloudification" of mobile networks, which are essential for supporting diverse 5G and beyond services with varying demands.
Key Features
- Abstraction of physical compute, storage, and network hardware
- Standardized lifecycle management (creation, scaling, termination)
- Defined performance metrics and monitoring capabilities
- Mapping of VNF requirements to available infrastructure resources
- Support for multi-tenancy and resource isolation
- Managed via standardized interfaces (e.g., Or-Vi) in the MANO framework
Evolution Across Releases
Initial introduction of Virtualized Resource concepts and management requirements as part of the early 5G and NFV study phase. Defined basic models for virtualized compute and storage resources and their integration into the network management architecture.
Enhanced VR management procedures and interfaces. Formalized the role of the VIM and defined more detailed resource models, including affinity/anti-affinity rules for placing VRs and initial support for network resource abstraction.
Full integration of VR management into the 5G system architecture. Defined the management services for 5G network functions, ensuring VR models support network slicing, where physical resources are partitioned into multiple logical, isolated VR sets for different slices.
Enhancements for automation and closed-loop operations. Introduced more granular VR monitoring and analytics to support AI/ML-driven orchestration. Improved models for managing VRs in edge computing deployments.
Expansion to support non-public networks (NPN) and industrial IoT. Defined VR management for private 5G networks and enhanced support for specialized hardware accelerators (e.g., for UPF) modeled as specific types of VRs.
Further evolution towards cloud-native principles, with enhanced VR models for containerized network functions (CNFs). Improved lifecycle management for microservices-based architectures and support for function-as-a-service (FaaS) concepts.
Ongoing work to refine VR management for AI-native networks and further integration with open-source cloud platforms. Focus on sustainability, optimizing VR allocation for energy efficiency, and managing VRs across heterogeneous compute domains (cloud, edge, far-edge).
Defining Specifications
| Specification | Title |
|---|---|
| TS 21.905 | 3GPP TS 21.905 |
| TS 22.261 | 3GPP TS 22.261 |
| TS 22.804 | 3GPP TS 22.804 |
| TS 22.873 | 3GPP TS 22.873 |
| TS 26.114 | 3GPP TS 26.114 |
| TS 26.118 | 3GPP TS 26.118 |
| TS 26.119 | 3GPP TS 26.119 |
| TS 26.234 | 3GPP TS 26.234 |
| TS 26.346 | 3GPP TS 26.346 |
| TS 26.511 | 3GPP TS 26.511 |
| TS 26.812 | 3GPP TS 26.812 |
| TS 26.818 | 3GPP TS 26.818 |
| TS 26.841 | 3GPP TS 26.841 |
| TS 26.857 | 3GPP TS 26.857 |
| TS 26.862 | 3GPP TS 26.862 |
| TS 26.891 | 3GPP TS 26.891 |
| TS 26.918 | 3GPP TS 26.918 |
| TS 26.925 | 3GPP TS 26.925 |
| TS 26.928 | 3GPP TS 26.928 |
| TS 26.929 | 3GPP TS 26.929 |
| TS 26.933 | 3GPP TS 26.933 |
| TS 26.956 | 3GPP TS 26.956 |
| TS 26.999 | 3GPP TS 26.999 |
| TS 28.404 | 3GPP TS 28.404 |
| TS 28.405 | 3GPP TS 28.405 |
| TS 28.406 | 3GPP TS 28.406 |
| TS 28.520 | 3GPP TS 28.520 |
| TS 32.401 | 3GPP TR 32.401 |
| TS 32.426 | 3GPP TR 32.426 |
| TS 32.842 | 3GPP TR 32.842 |
| TS 38.300 | 3GPP TR 38.300 |
| TS 38.331 | 3GPP TR 38.331 |
| TS 38.835 | 3GPP TR 38.835 |
| TS 38.838 | 3GPP TR 38.838 |
| TS 38.890 | 3GPP TR 38.890 |