Description
A Permanent Virtual Circuit (PVC) is a core networking concept from the era of connection-oriented packet-switched technologies like Frame Relay and Asynchronous Transfer Mode (ATM), which were widely used in early 3GPP core network backbones (e.g., GPRS, UMTS). Unlike a Switched Virtual Circuit (SVC) which is set up dynamically on demand, a PVC is statically provisioned by the network operator. It defines a persistent logical pathway, identified by a Data Link Connection Identifier (DLCI) in Frame Relay or a Virtual Path Identifier/Virtual Channel Identifier (VPI/VCI) pair in ATM, between two endpoints in the network. This pathway is 'virtual' because it does not represent a dedicated physical wire; instead, it is a predefined route through a mesh of switches where statistical multiplexing allows the shared physical infrastructure to carry traffic for many such PVCs simultaneously.
Architecturally, a PVC is established through manual configuration on the participating network switches (Frame Relay switches or ATM switches). An operator defines the endpoints (e.g., port and DLCI on Switch A to port and DLCI on Switch Z) and the traffic parameters for the circuit, such as Committed Information Rate (CIR) and Burst Information Rate (BIR). These parameters define the guaranteed and maximum bandwidth for the PVC. Once configured, the path is always available in the switches' routing tables, ready to forward cells or frames. In the 3GPP context, PVCs were commonly used to provide the reliable transport links between core network nodes. For instance, in a GPRS network, PVCs would be established across an ATM or Frame Relay backbone to connect Serving GPRS Support Nodes (SGSNs) with Gateway GPRS Support Nodes (GGSNs), forming the backbone of the GPRS Tunneling Protocol (GTP) tunnel transport.
The operation of a PVC is relatively simple from the endpoints' perspective. A network interface card configured with a specific PVC (via its DLCI or VPI/VCI) treats it as a permanent outgoing path. Any data sent to that logical interface is encapsulated into the appropriate Frame Relay or ATM frame/cell and injected into the network. The pre-configured switches along the path examine the connection identifier in the header and forward the traffic to the next hop according to the static mapping, ultimately delivering it to the destination endpoint. This provides predictable latency and a known path, which is beneficial for network planning and troubleshooting. However, it lacks the flexibility of on-demand connections and can lead to inefficient resource use if the predefined bandwidth is not fully utilized.
Purpose & Motivation
PVC technology was created to provide cost-effective, reliable, and predictable connectivity for enterprise and carrier networks before the widespread adoption of IP/Ethernet as the universal Layer 2/Layer 3 solution. It addressed the need for multiple permanent point-to-point links (like leased lines) without the prohibitive cost of deploying individual physical circuits for each connection. By using PVCs over a shared Frame Relay or ATM cloud, organizations could interconnect multiple sites with a single physical access link to the service provider, dramatically reducing costs while maintaining the appearance and predictability of dedicated circuits.
In the historical context of 3GPP networks (2G GPRS and 3G UMTS), IP infrastructure was not yet ubiquitous or robust enough in carrier backbones. Frame Relay and ATM offered carrier-class features with strong traffic management, quality of service (QoS) guarantees through parameters like CIR, and reliable operation. PVCs solved the problem of interconnecting the newly defined packet-switched core network nodes (SGSN, GGSN) in a stable, manageable way. They provided the predictable transport necessary for GTP tunnels carrying user data. The limitation PVCs addressed was the inefficiency and expense of physical mesh networks, but they themselves introduced the limitation of static configuration, which was later overcome by the dynamic, connectionless nature of IP routing in evolved 3GPP cores like the Evolved Packet Core (EPC) and 5G Core (5GC), where Ethernet and IP transport replaced ATM/Frame Relay and PVCs.
Key Features
- Statically provisioned and permanent logical connection,无需 call setup/teardown for each session
- Identified by a logical identifier (DLCI for Frame Relay, VPI/VCI for ATM)
- Provides predictable path and performance characteristics (e.g., guaranteed CIR)
- Enables statistical multiplexing of multiple logical circuits over shared physical links
- Supports quality of service through traffic contract parameters
- Used as a stable transport for higher-layer protocols like GTP in legacy GPRS/UMTS cores
Evolution Across Releases
PVCs were a foundational transport technology for the packet-switched core network defined in early 3GPP releases. In GPRS and UMTS specifications, PVCs over ATM or Frame Relay networks were the assumed or primary transport option for the Gn interface between SGSN and GGSN, carrying GTP tunnels for user data and signaling.
With the introduction of the Evolved Packet System (EPS) and the Evolved Packet Core (EPC) for LTE, the transport paradigm shifted decisively. The S1-U (eNB to S-GW) and S5/S8 (S-GW to P-GW) interfaces were defined to use IP transport directly over Ethernet or other Layer 2 technologies. PVCs were deprecated as the standard transport mechanism for these new interfaces, marking the beginning of the move towards all-IP transport.
In the 5G System, the transport network is fully IP-based. The N3 (UE to UPF) and N9 (UPF to UPF) interfaces use IP over Ethernet or other Layer 2 services. PVCs are no longer part of the standard architecture for interconnecting 5G Core network functions, which rely on service-based interfaces (SBIs) over HTTP/2 and IP-based packet forwarding.
Defining Specifications
| Specification | Title |
|---|---|
| TS 21.905 | 3GPP TS 21.905 |
| TS 23.060 | 3GPP TS 23.060 |
| TS 24.819 | 3GPP TS 24.819 |
| TS 25.410 | 3GPP TS 25.410 |
| TS 27.060 | 3GPP TS 27.060 |
| TS 29.414 | 3GPP TS 29.414 |
| TS 32.407 | 3GPP TR 32.407 |
| TS 48.016 | 3GPP TR 48.016 |