Notes

vRAN과 Telco Edge

Traditional RAN과 vRAN의 차이를 RAN 구성 요소, NFV, O-RAN, edge computing, automation, private 5G, troubleshooting 관점에서 정리한 DevOps 네트워킹 개념 노트

Published: Jun 2, 2026
Updated: Jun 2, 2026
Area: Computer Networks
Type: concept
Series: Cloud Networking
Category: Notes

vranranradio-access-networktelco-cloudedge-computingnfvo-ranprivate-5gautomationobservabilitykubernetes

RAN을 cloud 운영 모델로 옮긴다는 의미

RAN(Radio Access Network)은 스마트폰, 5G modem, IoT device 같은 무선 단말이 이동통신망에 접속할 때 가장 먼저 만나는 access network다. 사용자가 모바일 데이터를 사용할 때 단말은 radio signal을 통해 cell tower 또는 radio unit과 통신하고, RAN은 이 traffic을 mobile core network와 연결한다.

Smartphone / UE
  ↓ radio signal
Cell Tower / Radio Unit / Antenna
  ↓
RAN processing
  ↓
Mobile Core Network
  ↓
Internet / Application / Cloud

vRAN(Virtualized Radio Access Network)은 이 RAN 기능을 전용 hardware appliance 중심으로 운영하던 방식에서 분리해, cloud 또는 edge platform 위의 software workload로 운영하려는 접근이다.

Traditional RAN:
전용 장비 + vendor-specific hardware + site 중심 운영

vRAN:
RAN 기능의 virtualization + cloud/edge platform + COTS hardware + automation

vRAN의 핵심은 단순히 “RAN 장비를 VM으로 바꾼다”가 아니다. RAN network function을 software-defined infrastructure 위에 올리고, capacity 조정, 배포, 장애 대응, workload placement, monitoring을 cloud operating model에 가깝게 가져가는 것이다.

RAN이 담당하는 역할

RAN은 단순히 안테나만 의미하지 않는다. 무선 단말과 core network 사이에서 radio access를 구성하는 복잡한 시스템이다.

RAN은 대략 다음 일을 수행한다.

무선 신호 송수신
주파수 자원 할당
단말과 기지국 간 연결 관리
handover 처리
무선 구간 암호화와 오류 정정
MIMO, beamforming 등 radio 기능 처리
core network로 traffic 전달

즉 RAN은 mobile network에서 무선 access 구간의 compute, signal processing, scheduling, mobility management를 담당한다.

RAN의 주요 구성 요소

구성 요소	의미
UE	User Equipment. 스마트폰, 5G router, IoT device 등
Antenna	전기 신호를 radio wave로 방사하거나 수신
Radio / RU	digital data와 radio signal 사이의 변환, RF 처리
Baseband / BBU	무선 신호 처리, scheduling, encoding/decoding 등
Fronthaul	radio unit과 baseband processing unit 사이 연결
Backhaul	RAN과 mobile core network 사이 연결
Core Network	인증, session, routing, mobility, policy 등을 담당

조금 더 단순화하면 다음과 같다.

Antenna:
전파를 보내고 받음

Radio Unit:
RF 신호와 digital 신호 사이 변환

Baseband:
무선 통신을 위한 복잡한 digital signal processing 수행

Core:
subscriber, session, policy, internet 연결 처리

RAN은 radio와 compute가 강하게 결합된 영역이다. 그래서 일반적인 web service보다 latency, jitter, synchronization, hardware acceleration 요구사항이 훨씬 까다롭다.

Traditional RAN의 기본 구조

Traditional RAN은 vendor가 제공하는 전용 hardware appliance와 software stack이 묶여 있는 구조로 운영되는 경우가 많다.

Cell Site
├── Antenna
├── Radio Unit
├── Baseband Unit / proprietary hardware
└── Vendor-specific RAN software

이 구조에서는 특정 vendor의 radio, baseband, management system이 tightly coupled되어 있을 수 있다.

Vendor A Radio
  ↔ Vendor A Baseband
  ↔ Vendor A Management Stack

특징	설명
전용 장비 중심	RAN 기능이 vendor-specific appliance에 묶임
site 중심 배포	기지국 site마다 장비 설치와 구성 필요
긴 lifecycle	hardware 도입, 설치, 검증, 교체 주기가 김
vendor dependency	특정 vendor stack에 종속되기 쉬움
scaling 제약	capacity 증설이 hardware 증설과 강하게 연결
automation 어려움	cloud-native 방식의 dynamic orchestration과 거리가 있음

Traditional RAN이 단순히 나쁜 구조라는 뜻은 아니다. 이동통신망은 reliability, latency, synchronization, radio performance 요구사항이 높기 때문에 전용 장비 중심 구조가 오랫동안 합리적이었다. 다만 5G 이후 traffic 패턴과 use case가 다양해지면서 더 유연한 운영 방식이 필요해졌다.

vRAN의 기본 개념

vRAN은 RAN의 일부 network function, 특히 baseband processing과 control 기능을 전용 hardware appliance에서 분리해 software로 virtualize하고, 이를 cloud platform 또는 COTS hardware 위에 배포하는 방식이다.

Traditional RAN:
RAN function = proprietary hardware box 안에 고정

vRAN:
RAN function = software workload로 분리
             = cloud / edge platform 위에 배포
             = automation으로 scale, move, update 가능

Traditional RAN과 vRAN의 가장 큰 차이는 RAN 기능이 어디에 묶여 있는가다.

구분	Traditional RAN	vRAN
실행 위치	전용 RAN appliance	cloud/edge platform, COTS server
hardware	proprietary hardware 중심	general-purpose hardware 활용 가능
software	vendor hardware와 tightly coupled	software-defined RAN function
scaling	장비 증설 중심	workload scaling과 automation 가능
배포 속도	상대적으로 느림	software deployment 방식에 가까움
운영 방식	site별 수동 운영 비중 큼	orchestration과 automation에 적합
vendor lock-in	높을 수 있음	open interface와 결합 시 완화 가능
장애 대응	장비 교체·현장 작업 필요 가능	software redeploy, workload rebalance 가능

vRAN과 NFV

vRAN은 넓게 보면 NFV(Network Functions Virtualization)의 적용 사례다. NFV는 router, firewall, load balancer 같은 network function을 전용 hardware appliance가 아니라 software로 구현해 VM, container, cloud infrastructure 위에서 실행하는 접근이다.

Traditional network function:
전용 장비에서 실행

Virtualized network function:
software workload로 실행

vRAN은 이 개념을 RAN에 적용한다.

Traditional RAN baseband function
  ↓
Virtualized RAN function
  ↓
Cloud / Edge infrastructure

구분	일반 NFV	vRAN
대상	firewall, router, load balancer, VPN 등	RAN baseband/control function
목표	network appliance의 software화	RAN function의 software화
실행 환경	VM, container, cloud platform	telco cloud, edge cloud, COTS server
주요 과제	throughput, HA, lifecycle	latency, jitter, sync, radio performance까지 포함

왜 RAN을 virtualize하려고 하는가

RAN을 virtualize하려는 이유는 이동통신망의 traffic과 use case가 더 복잡해졌기 때문이다.

5G 이후 network는 다음 요구사항을 동시에 처리해야 한다.

스마트폰 대용량 트래픽
IoT device 대량 접속
저지연 industrial control
AR/VR
autonomous vehicle
private 5G
stadium/event traffic burst
rural coverage
enterprise network slicing

Traditional RAN은 이런 변화에 대응할 때 hardware와 site configuration에 많이 의존한다.

새 capacity 필요
  ↓
장비 구매
  ↓
현장 설치
  ↓
설정
  ↓
검증
  ↓
운영 반영

vRAN은 이 과정을 software와 automation 중심으로 바꾸려는 접근이다.

새 capacity 필요
  ↓
RAN function scale-out
  ↓
workload placement
  ↓
automation policy 적용
  ↓
monitoring 기반 조정

vRAN의 architecture 감각

vRAN을 단순화하면 다음과 같다.

Radio Unit / Antenna
  ↓ fronthaul
Virtualized RAN functions
  ↓
Cloud / Edge platform
  ↓ backhaul
Mobile Core Network

5G RAN에서는 기능을 RU, DU, CU로 나누어 배치할 수 있다.

RU: Radio Unit
DU: Distributed Unit
CU: Central Unit

구성 요소	일반적 역할
RU	radio frequency 처리, antenna와 가까운 위치
DU	lower-layer baseband processing, latency-sensitive 처리
CU	higher-layer protocol 처리, 더 중앙화 가능
Edge Cloud	DU/CU 등 virtualized function 실행 가능
Orchestrator	배포, scaling, monitoring, healing 자동화

실제 RAN function split은 latency budget, fronthaul bandwidth, synchronization, hardware acceleration 요구사항에 따라 달라진다. 하지만 vRAN의 핵심은 이 기능들을 전용 장비가 아니라 cloud/edge platform 위의 software function으로 배치할 수 있게 하는 것이다.

vRAN과 O-RAN의 차이

vRAN과 O-RAN은 자주 함께 언급되지만 같은 개념은 아니다.

vRAN:
RAN function을 virtualize하는 것

O-RAN:
RAN 구성 요소 간 interface를 open하고 multi-vendor interoperability와 automation을 강화하는 architecture

구분	vRAN	O-RAN
핵심 관심	virtualization	open interface, interoperability, intelligence
주요 질문	RAN function을 cloud/software로 실행할 수 있는가?	여러 vendor의 RAN 구성요소를 표준 interface로 연결할 수 있는가?
실행 형태	VM/container/COTS hardware	O-CU, O-DU, O-RU, RIC, SMO, O-Cloud 등
목표	flexibility, automation, scaling	openness, multi-vendor, AI/ML optimization
관계	O-RAN에서 vRAN이 활용될 수 있음	vRAN과 결합할 때 효과가 커질 수 있음

즉 vRAN은 “가상화된 RAN”, O-RAN은 “개방형 RAN architecture”로 이해하면 된다.

Automation과 vRAN

vRAN이 중요한 이유 중 하나는 automation과 잘 맞기 때문이다.

monitoring 기반 상태 수집
  ↓
policy 기반 판단
  ↓
RAN function scale-out / scale-in
  ↓
workload placement 변경
  ↓
configuration update
  ↓
closed-loop automation

Cloud-native 관점으로 바꾸면 다음과 유사하다.

Cloud-native 개념	vRAN에서의 의미
workload scheduling	RAN function을 적절한 edge/cloud node에 배치
autoscaling	traffic load에 따라 RAN processing capacity 조정
health monitoring	RAN function 상태와 KPI 모니터링
self-healing	장애 function 재시작 또는 다른 node로 이동
rolling update	RAN software version을 점진적으로 배포
policy automation	SLA, latency, capacity 기준으로 자동 조정

다만 RAN workload는 일반 web workload보다 훨씬 엄격한 성능 요구사항을 가진다. 따라서 automation policy도 단순 CPU 사용률만 보는 방식으로는 부족하다.

Use Case 1: Traffic burst 대응

경기장, 콘서트장, 축제, 대형 컨퍼런스, 군중 밀집 지역에서는 특정 시간에 mobile traffic이 급증한다.

평소:
cell site traffic 낮음

이벤트 시간:
수만 명이 동시에 upload, streaming, messaging, payment 사용

Traditional RAN에서는 이런 peak를 위해 해당 지역에 충분한 hardware capacity를 미리 설치해야 할 수 있다.

Peak traffic 기준으로 장비 설치
  ↓
평소에는 capacity가 놀 수 있음
  ↓
이벤트 없을 때 resource utilization 낮음

vRAN에서는 RAN processing function을 software적으로 확장하거나, edge/cloud resource를 더 유연하게 할당할 수 있다.

Event detected
  ↓
traffic forecast 증가
  ↓
nearby edge cloud capacity 확보
  ↓
vRAN workload scale-out
  ↓
event 종료 후 scale-in

이 접근은 항상 최대 capacity를 고정 배치하는 방식보다 resource utilization 관점에서 유리할 수 있다.

Use Case 2: 장애 대응과 workload rebalance

Traditional RAN에서는 특정 site의 baseband hardware나 관련 장비에 문제가 생기면 해당 site의 service quality가 떨어질 수 있다.

Cell site hardware failure
  ↓
capacity loss
  ↓
coverage or throughput degradation
  ↓
field maintenance 필요

vRAN에서는 RAN function이 software workload로 분리되어 있으므로, 장애가 발생한 compute node나 software instance에서 다른 node로 function을 옮기거나 재시작하는 방식이 가능해진다.

Monitoring detects failure
  ↓
orchestrator marks node unhealthy
  ↓
vRAN function is restarted or relocated
  ↓
traffic is rebalanced
  ↓
service impact reduced

Radio unit, antenna, fiber, power 같은 physical element가 사라지는 것은 아니다. RU나 antenna 자체가 고장 나면 현장 조치가 필요하다. 다만 baseband processing이나 control plane function 일부가 virtualized되어 있으면 software layer에서 빠르게 복구하거나 다른 resource로 옮길 수 있는 범위가 넓어진다.

Use Case 3: Private 5G와 enterprise site

공장, 항만, 병원, 물류센터, 캠퍼스, 군사시설 같은 곳에서는 public mobile network와 다른 요구사항이 있다.

낮은 latency
높은 reliability
현장 내부 data 처리
보안 격리
특정 application SLA
local breakout
edge computing 연동

vRAN 방식에서는 enterprise edge cloud나 MEC facility에 RAN function 일부를 software로 배포하고, 현장 요구사항에 맞게 조정할 수 있다.

Enterprise Site
├── Radio Units
├── Edge Cloud
│   ├── vDU
│   └── vCU
├── Local 5G Core or UPF
└── Industrial Applications

이 구조는 private 5G, MEC, network slicing, local data processing, industrial IoT, campus network automation과 연결된다.

vRAN에서 cloud의 의미

vRAN에서 말하는 cloud는 꼭 hyperscaler public cloud만 의미하지 않는다. RAN workload는 latency와 reliability 요구사항이 매우 높기 때문에 다양한 위치에 배치될 수 있다.

central data center
regional data center
edge cloud
telco cloud
MEC site
on-premises enterprise edge
cell site 근처 compute node

중요한 것은 RAN function을 software workload로 다루고, cloud platform의 scheduling, automation, lifecycle management 방식을 활용한다는 점이다.

vRAN cloud platform:
COTS hardware
virtualization layer
container platform
real-time tuned OS
hardware accelerator
orchestration
monitoring
automation

즉 vRAN은 단순히 RAN을 public cloud에 올린다는 의미가 아니라, RAN workload를 cloud operating model로 운영한다는 의미에 가깝다.

vRAN과 Edge Computing

vRAN은 edge computing과 강하게 연결된다. RAN은 사용자와 가까운 radio access 구간에 있기 때문에 latency에 민감하다. 모든 RAN processing을 먼 central cloud로 보내면 fronthaul latency와 bandwidth 요구사항이 커질 수 있다.

따라서 vRAN에서는 어떤 function을 어디에 둘지 결정하는 것이 중요하다.

RU:
site 또는 tower 근처

DU:
latency-sensitive하므로 edge에 가까이 배치하는 경우 많음

CU:
상대적으로 중앙화 가능

Core / UPF:
use case에 따라 regional 또는 edge 배치 가능

이 구조는 다음 질문을 만든다.

어떤 RAN function은 cell site 근처에 남겨야 하는가?
어떤 function은 regional data center로 모을 수 있는가?
어떤 function은 central cloud에서 실행해도 되는가?
fronthaul latency budget은 충분한가?
hardware acceleration이 필요한가?

vRAN의 장점

장점	설명
Hardware dependency 완화	RAN function을 proprietary appliance에서 분리
Faster deployment	software deployment와 staged rollout에 가까운 운영 가능
Elastic scaling	traffic load에 따라 scale-out/scale-in 또는 rebalance 가능
Automation	KPI 기반 closed-loop operation과 self-healing 가능
Multi-vendor 가능성	O-RAN 같은 open interface와 결합 시 vendor lock-in 완화 가능

Software workload는 hardware appliance보다 배포와 업데이트를 자동화하기 쉽다.

new RAN function version
  ↓
CI/CD 또는 orchestration
  ↓
staged rollout
  ↓
monitoring
  ↓
rollback if needed

물론 telecom-grade validation은 여전히 엄격해야 한다. 운영 모델이 software deployment에 가까워진다는 뜻이지, 일반 웹 애플리케이션처럼 단순해진다는 뜻은 아니다.

vRAN의 어려움과 trade-off

vRAN은 기존 장비를 단순히 VM으로 바꾸면 끝나는 기술이 아니다. RAN은 매우 까다로운 workload다.

Latency requirement

RAN processing은 latency에 민감하다. 특히 lower-layer PHY 처리, scheduling, HARQ 관련 처리 등은 매우 짧은 시간 안에 완료되어야 한다.

일반 web workload:
수 ms~수백 ms 지연도 허용되는 경우 많음

RAN workload:
microsecond~millisecond 단위의 deterministic processing 요구

Hardware acceleration

일부 RAN function은 CPU만으로 처리하기 어렵거나 비효율적일 수 있다.

FEC accelerator
FPGA
SmartNIC
GPU
ASIC
DPDK
SR-IOV
real-time kernel tuning
NUMA pinning
CPU isolation

COTS hardware를 쓴다고 해서 hardware 최적화가 사라지는 것은 아니다. 오히려 어떤 function을 CPU에서 처리하고, 어떤 function을 accelerator로 offload할지 설계해야 한다.

Fronthaul bandwidth와 synchronization

RU와 DU 사이의 fronthaul은 bandwidth와 latency 요구사항이 높다.

RU ↔ DU:
low latency
high bandwidth
precise timing
synchronization

기능을 더 중앙화하면 pooling과 efficiency는 좋아질 수 있지만, fronthaul 요구사항이 커질 수 있다.

Operational complexity

vRAN은 cloud 운영 기술을 요구한다.

Kubernetes 또는 cloud platform 운영
real-time workload scheduling
network acceleration
observability
closed-loop automation
security policy
lifecycle management

통신사의 네트워크 운영 조직은 전통적인 RAN 장비 운영뿐 아니라 cloud infrastructure 운영 역량도 가져야 한다.

vRAN과 Cloud Native

vRAN은 단순 virtualization에서 더 나아가 cloud-native 방식으로 진화할 수 있다.

Virtualized:
VM 위에 RAN function 실행

Cloud-native:
containerized function
microservice architecture
Kubernetes orchestration
CI/CD
observability
policy automation
self-healing

하지만 RAN workload는 일반 web application과 다르다.

일반 Kubernetes app:
stateless web service, API server, batch job

vRAN workload:
real-time signal processing, strict latency, hardware-aware scheduling

vRAN에서 cloud-native를 적용하려면 다음이 필요하다.

real-time kernel tuning
CPU pinning
hugepages
SR-IOV
DPDK
hardware accelerator integration
deterministic networking
precise time synchronization
telco-grade observability
zero-touch provisioning
lifecycle orchestration

RAN 관련 용어 구분

용어	의미
RAN	단말과 core network를 연결하는 radio access network
D-RAN	site별로 분산된 traditional RAN 구조
C-RAN	baseband function을 중앙화 또는 pooling하는 architecture
vRAN	RAN function을 virtualize해 cloud/COTS platform에서 실행
O-RAN	open interface와 multi-vendor interoperability를 지향하는 RAN architecture
Cloud RAN	RAN function을 cloud platform에서 운영하는 넓은 개념
Open RAN	open interface 기반의 개방형 RAN 생태계 지향

간단히 보면 다음과 같다.

RAN:
무선 access network 전체

vRAN:
RAN function의 virtualization

O-RAN:
RAN interface와 ecosystem의 openness

Cloud RAN:
cloud platform 기반 RAN 운영 모델

vRAN과 O-RAN은 함께 사용될 수 있지만 같은 단어는 아니다.

운영 방식의 변화

Traditional RAN 운영은 장비 중심이다.

장비 설치
장비 설정
site별 capacity 계획
vendor-specific upgrade
현장 유지보수

vRAN 운영은 platform 중심으로 바뀐다.

common hardware pool
cloud platform
RAN software lifecycle
orchestration
policy-based automation
KPI monitoring
workload placement

이 변화는 통신사 네트워크 운영을 다음과 가깝게 만든다.

Telco network operations
  +
Cloud infrastructure operations
  +
DevOps / SRE practices

DevOps 관점에서 보면 vRAN은 다음 질문을 던진다.

RAN function을 어떻게 배포할 것인가?
어떤 metric으로 health를 판단할 것인가?
장애 시 어떤 policy로 workload를 옮길 것인가?
rollback은 어떻게 할 것인가?
capacity는 어떻게 예측하고 자동 조정할 것인가?
vendor별 component를 어떻게 통합 검증할 것인가?

Network Slicing과 RIC

5G에서 자주 언급되는 network slicing과 vRAN도 연결된다. Network slicing은 하나의 physical network infrastructure 위에 use case별 logical network slice를 만드는 개념이다.

eMBB slice:
high throughput mobile broadband

URLLC slice:
ultra-reliable low-latency communication

mMTC slice:
massive IoT device connectivity

Enterprise private slice:
특정 기업 전용 SLA

vRAN은 RAN resource를 더 software-defined 방식으로 운영하게 하므로, slice별 resource allocation과 policy enforcement를 더 유연하게 만들 수 있다.

O-RAN과 함께 나오면 RIC(RAN Intelligent Controller)도 중요하다.

Near-RT RIC:
near-real-time control loop
대략 10ms~1s 수준의 제어

Non-RT RIC:
non-real-time optimization
policy, training, analytics, long-term optimization

RIC는 RAN을 data-driven 또는 AI/ML-driven 방식으로 최적화하는 controller에 가깝다.

traffic steering
load balancing
interference management
energy saving
handover optimization
slice-aware scheduling
QoE optimization

보안 관점

vRAN과 O-RAN은 open interface, virtualization, cloud platform을 활용하기 때문에 보안 모델도 달라진다.

Traditional RAN은 비교적 closed vendor system으로 운영되는 경우가 많았다. vRAN/O-RAN 환경에서는 다음 공격 표면이 늘어날 수 있다.

cloud platform
container runtime
management API
orchestrator
open fronthaul interface
RIC applications
multi-vendor integration point
software supply chain

따라서 vRAN에서는 다음 보안 설계가 필요하다.

workload isolation
secure boot
image signing
SBOM 관리
runtime security
management plane 접근 제어
zero trust networking
encrypted interface
certificate lifecycle 관리
RIC app 검증
multi-vendor component validation
observability와 audit logging

vRAN은 hardware appliance를 software로 바꾸는 것뿐 아니라, telecom network를 cloud security model로 재설계하는 일이기도 하다.

성능 검증 관점

vRAN에서 가장 민감한 질문은 전용 장비만큼 성능이 나오는지다.

RAN은 다음 요구사항을 만족해야 한다.

high throughput
low latency
low jitter
synchronization
high availability
radio performance
energy efficiency
deterministic processing

vRAN 검증은 일반 application benchmark보다 훨씬 까다롭다.

검증 항목	의미
Throughput	cell 또는 sector당 처리 가능한 traffic
Latency	scheduling과 signal processing 지연
Jitter	처리 시간 변동성
CPU utilization	RAN function별 CPU 사용률
Accelerator efficiency	FEC 등 offload 성능
Fronthaul performance	RU-DU 간 latency와 bandwidth
Packet loss	packet processing 안정성
Sync accuracy	time synchronization 정확도
Handover performance	이동 중 연결 품질
Energy efficiency	traffic당 전력 사용량
Failure recovery	장애 시 복구 시간

vRAN은 software가 실행되는지만 보는 것이 아니라, radio network quality까지 검증해야 한다.

Troubleshooting 관점

vRAN 환경에서 장애가 발생하면 원인이 여러 계층에 걸쳐 있을 수 있다.

radio layer 문제인가?
fronthaul 문제인가?
vDU/vCU software 문제인가?
cloud platform 문제인가?
hardware accelerator 문제인가?
timing/sync 문제인가?
orchestration 문제인가?
network policy 문제인가?

특정 cell의 throughput 저하

가능한 원인은 다음과 같다.

radio interference
RU 문제
fronthaul congestion
vDU CPU saturation
accelerator bottleneck
scheduler configuration 문제
slice policy 문제
transport network packet loss

Latency spike

가능한 원인은 다음과 같다.

CPU scheduling jitter
NUMA placement 문제
container noisy neighbor
real-time kernel tuning 부족
fronthaul latency 증가
hardware accelerator queue delay
power management 설정 문제

특정 RU 연결 실패

가능한 원인은 다음과 같다.

open fronthaul 설정 오류
timing synchronization 실패
VLAN/VXLAN/network policy 문제
certificate 또는 authentication 실패
DU-RU compatibility 문제
fiber 또는 physical link 문제

Automation이 workload를 잘못 옮기는 경우

가능한 원인은 다음과 같다.

metric 수집 지연
KPI threshold 설정 오류
resource request/limit 부정확
latency constraint 미반영
accelerator availability 미확인
placement policy 오류

vRAN troubleshooting은 기존 RAN troubleshooting과 cloud infrastructure troubleshooting을 모두 포함한다.

DevOps 관점에서 보는 vRAN

vRAN은 통신 network function이 software delivery, platform operation, automation, observability의 대상이 되는 전환이다.

vRAN 운영에는 다음 요소가 중요하다.

Infrastructure as Code
GitOps
CI/CD
image registry
configuration management
policy as code
observability
automated rollback
canary deployment
closed-loop automation
SLO/SLA monitoring

다만 일반 web service와 달리 vRAN에는 telecom-grade constraint가 있다.

real-time processing
strict latency
hardware acceleration
regulatory requirement
radio performance
synchronization
high availability
multi-vendor validation

따라서 vRAN은 통신망에 DevOps를 적용하는 가장 복잡한 형태 중 하나다.

앞선 네트워킹 개념들과의 연결

Virtual Networking

vRAN은 virtual networking 위에서 동작한다.

vRAN function
  ↓
virtual network
  ↓
edge cloud
  ↓
transport network
  ↓
radio unit

RAN function이 VM/container workload가 되면 vNIC, virtual switch, SR-IOV, DPDK, overlay/underlay, network policy가 모두 중요해진다.

VPC

Private 5G나 telco cloud 환경에서는 VPC 또는 VPC와 유사한 isolated network boundary 안에 vRAN function을 배치할 수 있다.

Telco Cloud / Edge VPC
├── vCU
├── vDU
├── management plane
├── monitoring
└── automation controller

NAT와 Firewall

vRAN management plane과 data plane은 엄격히 분리해야 한다.

management traffic
control traffic
user plane traffic
fronthaul traffic
sync traffic

Firewall policy, segmentation, zero trust 접근 제어가 중요하다.

CDN과 Edge Computing

CDN은 content를 edge로 가져오는 기술이고, vRAN은 radio access function을 edge/cloud platform에서 운영하는 기술이다. 둘 다 사용자 가까운 곳에서 처리한다는 edge computing 관점과 연결된다.

CDN:
content delivery를 edge로 가져옴

vRAN:
radio access processing을 edge/cloud platform으로 가져옴

자칫 실수하기 쉬운 부분

실수	문제
vRAN을 단순 VM 이전으로 이해	RAN은 latency, jitter, sync, accelerator 요구사항이 매우 높음
vRAN과 O-RAN을 동일시	vRAN은 virtualization, O-RAN은 openness와 interface 중심
cloud를 public cloud로만 해석	telco cloud, edge cloud, MEC, enterprise edge도 포함 가능
autoscaling을 단순 CPU 기준으로 설계	radio KPI, latency, fronthaul, accelerator 상태를 함께 봐야 함
COTS hardware면 accelerator가 필요 없다고 가정	FEC, DPDK, SR-IOV, real-time tuning이 필요할 수 있음
RU/DU/CU placement를 단순화	function split과 latency budget이 설계 핵심
보안을 기존 closed RAN 수준으로만 고려	cloud platform, API, supply chain, RIC app 등 공격 표면 증가
일반 web service처럼 troubleshooting	radio domain과 cloud infra domain을 함께 봐야 함

정리

vRAN은 traditional RAN의 전용 hardware 중심 구조에서 RAN network function을 분리해 cloud/edge platform과 COTS hardware 위의 software workload로 운영하려는 접근이다.

항목	정리
RAN	단말과 core network를 연결하는 radio access network
Traditional RAN	전용 hardware와 vendor-specific stack 중심
vRAN	RAN function을 virtualize해 cloud/edge platform에서 실행
NFV와 관계	network function virtualization을 RAN에 적용
O-RAN과 차이	vRAN은 virtualization, O-RAN은 open interface와 interoperability 중심
Edge와 관계	latency-sensitive RAN function을 사용자 가까운 edge에 배치
핵심 가치	flexibility, automation, scaling, workload rebalance
주요 과제	latency, jitter, synchronization, hardware acceleration, fronthaul
운영 변화	장비 중심 운영에서 platform 중심 운영으로 이동
DevOps 관점	CI/CD, observability, automation, policy, rollback, SLO 관리 필요

vRAN을 이해할 때 가장 중요한 점은 RAN을 일반적인 cloud workload처럼 단순화하지 않는 것이다. vRAN은 cloud operating model을 RAN에 적용하려는 접근이지만, 그 대상은 radio access network라는 매우 엄격한 성능 요구사항을 가진 영역이다. 따라서 software-defined 운영의 유연성과 telecom-grade 성능 보장을 함께 만족해야 한다.