OAI RAN + Free5GC 환경에서 AI Agent로 네트워크 슬라이스를 통합 제어 Prototype 설계

5G/6G 네트워크 운영에서 점점 더 중요해지는 주제 중 하나는,
RAN과 Core Network를 따로 보지 않고 종단 간으로 함께 최적화하는 것이다.

 

실제 서비스 품질은 무선 구간만 잘한다고 보장되지 않고, 코어망만 확장한다고 해결되지도 않는다.

특히 서로 다른 QoS 특성을 가진 Network slice들이 동시에 동작할 때는, RAN과 CN 사이의 자원 경합이 자연스럽게 발생한다.

 

이러한 문제를 해결하기 위해, OAI gNB와 Free5GC 기반의 실제 NF 환경 위에서 동작하는 AI Agent Prototype을 설계한다.

목표는 단순 시뮬레이션이 아니라, 실제 네트워크 구성요소를 대상으로 관측과 제어를 수행하는 현실적인 Testbed를 만드는 것!

 

동작 과정으로는 iperf3로 Slice별 Traffic을 주입하고, AI Agent가 RAN과 CN의 상태를 함께 관측한 뒤,
ReAct 기반 Tool 호출을 통해 양쪽을 협조적으로 제어하는 구조를 만든다.

이 Agent는 개별 UE를 실시간으로 미세 제어하는 방식이 아니라,
Slice 단위의 non-real-time 루프에서 더 긴 시간축으로 최적화를 수행하는 Orchesrator로 동작한다.

 

 

왜 기존 방식으로는 부족한가

---

기존에 LangChain 기반 Agent는 주로 파이썬 시뮬레이션 위에서 동작하도록 구성되어 있었다.

이 방식은 아이디어를 빠르게 검증하기에는 적합하지만, 실제 네트워크 환경으로 가면 여러 한계가 드러난다.

 

첫째, 시뮬레이터에서는 관측 지표와 제어 결과가 지나치게 정형화되어 있어 현실적인 오퍼레이션 비용을 반영하기 어렵다.

로그 수집 지연, API 반영 시간, 세션 재접속 비용, 컨테이너 리소스 변경 시간 같은 요소들이 빠져 있기 때문이다.

 

둘째, 실제 네트워크에서는 RAN과 CN이 서로 다른 병목을 만들고, 그 병목이 상호작용한다.

예를 들어 처리량 저하가 관측되었을 때 원인이 PRB 포화인지, UPF CPU 과부하인지, 세션 bitrate 제한인지 구분해야 한다.

시뮬레이션 환경에서는 이러한 원인 분리가 지나치게 단순화되는 경우가 많다.

 

셋째, AI Agent의 UE 단위 세밀 제어는 실제 환경에서 비효율적이다.

보통 이러한 세밀 제어는 DRL이나 LSTM 기반 모델들이 UE 레벨 제어를 시도하는 경우가 많다.

그러나 AI Agent가 UE 레벨의 제어를 수행하면 비용이 커지고 실시간 inference latency가 길어져서 제대로 대응하지 못한다.

 

따라서 이번 프로토타입은 개별 UE를 조작하는 대신, 슬라이스 단위로 더 큰 정책 변수를 제어하는 방향을 택한다.

즉, 여기서 정의하는 AI Agent는 per-UE closed loop controller가 아니라, non-real-time slice orchestrator다.

 

 

 

프로토타입 목표

---

이번 설계의 목적은 OAI RAN과 Free5GC Core Network에서 AI Agent가 실제로 어떤 파라미터를 관측하고,

어떤 파라미터를 제어할 수 있는지 명확히 정의하는 것이다.

그리고 LangChain 기반 Agent가 ReAct 패턴으로 도구를 호출해, RAN과 CN에 대해 단계적으로 판단하고 조치하는 현실적인 실행 환경을 구축하는 것이다.

 

이 프로토타입은 다음과 같은 기능 검증을 목표로 한다.

• API 연동이 실제 NF에 대해 안정적으로 동작하는지
• 세션 제어가 slice 수준에서 정책적으로 가능한지
• 에이전트 기반 orchestration이 단순 규칙 기반 제어보다 의미 있는지
• 로그와 telemetry를 바탕으로 원인 추론이 가능한지
• cross-domain 정책 실험이 실제 테스트베드에서 재현 가능한지

실행 환경은 WSL2 안에 LangChain Agent, Free5GC, OAI RF simulator를 함께 올리는 구성으로 잡는다.

이 구조는 완전한 분산 배포 환경은 아니지만, API 연계와 제어 루프 검증에는 충분하며 반복 실험에도 유리하다.

 

 

 

전체 시스템 구조

---

 

 

전체 시스템은 크게 네 개의 계층으로 나눌 수 있다.

 

첫 번째는 트래픽 생성 계층이다. 여기서는 iperf3를 사용해 슬라이스별로 서로 다른 형태의 부하를 만든다.

실제 서비스 트래픽의 완전한 재현은 아니더라도, 대역폭 중심 부하와 지연 민감형 부하를 구분해 주입하는 데는 충분하다.

 

두 번째는 네트워크 실행 계층이다. RAN 측은 OAI gNB가 담당하고, CN 측은 Free5GC의 NF들이 담당한다.

필요 시 slice별로 독립된 UPF를 구성해 코어망 자원도 슬라이스 단위로 분리한다.

 

세 번째는 관측 계층이다. OAI 로그, Prometheus, docker stats, iptables 카운터, Free5GC 로그 등에서 데이터를 수집한다.

이 계층은 단순 모니터링이 아니라, Agent가 reasoning에 활용할 수 있도록 정규화된 텔레메트리 벡터를 제공해야 한다.

 

네 번째는 제어 계층이다. AI Agent는 ReAct 방식으로 현재 상태를 해석하고, 필요한 Tool을 호출해 정책을 적용한다.

이때 Tool은 추상 함수가 아니라 실제 REST API, docker update, tc qdisc, WebUI API 같은 실행 메커니즘에 연결된다.

 

즉, 이 구조의 본질은 트래픽을 넣고, 상태를 읽고, 원인을 추론하고, 도메인별 조치를 선택하고,
다시 효과를 관측하는 closed loop를 구성하는 것이다.

 

 

 

Slice 구성

---

이번 설계에서 중요한 전제는 Agent가 개별 UE를 직접 제어하지 않는다는 점이다. 이유는 크게 두 가지다.

 

하나는 비용 효율성이다.

UE 단위로 상태를 읽고 액션을 내리면, 제어 대상 수가 급격히 늘어나고 모델 추론 비용도 함께 증가한다.

실제 운영에서는 이런 구조가 유지되기 어렵다.

 

다른 하나는 latency다.

UE 레벨 제어는 빠른 반응이 요구되지만, LLM 기반 Agent나 복잡한 reasoning 루프는 그 수준의 저지연 제어에 맞지 않는다.

반면 slice 수준 정책 제어는 더 긴 시간 단위에서 작동해도 충분히 의미가 있다.

예를 들어 PRB quota 재조정, UPF CPU 확장, 세션 AMBR 재설정은 수십 밀리초 이하의 반응보다 수초 단위의 안정적 최적화가 더 중요하다. 따라서 이 Agent는 near-real-time scheduler가 아니라, non-real-time policy optimizer로 정의하는 것이 타당하다.

 

이 네트워크 Slice의 구성은 다음과 같다.

각 Slice는 근본적으로 다른 QoS 요구사항을 가져 RAN-CN 간 자원 경합을 유발하며,
이것은 LangChain으로 구축되는 AI Agent의 RAN-CN 통합 제어의 핵심 동기이다.

슬라이스	S-NSSAI	포함 Application	QoS 특성	UE IP 대역
eMBB	SST=1, SD=010203	Netflix, youtube, Amazon, Afreeca, Navernow	고대역폭, 지연 무관	10.60.0.0/16
URLLC	SST=2, SD=020304	Zoom, Teams, Meet, Geforce, TFT, Batteground, Roblox, Gamobox	저지연(<50ms, 중간 BW)	10.61.0.0/16
Metaverse	SST=2, SD=030405	Zepeto	저지연 + 고대역폭	10.62.0.0/16

 

이 세 슬라이스를 함께 구성하면, 단순히 대역폭만 많이 먹는 경우와 지연이 민감한 경우, 그리고 둘 다 요구하는 경우를 동시에 실험할 수 있다. 특히 Metaverse 슬라이스는 cross-domain 제어 필요성을 가장 극적으로 드러내는 star scenario로 기능한다.

 

 

 

AI Agent의 역할

---

이 Agent의 핵심 가치는 RAN과 CN의 상태를 통합적으로 해석하고, 서로 연관된 병목을 구분한 뒤,

협조된 제어 액션을 생성하는 데 있다.

 

전통적인 도메인 분리형 컨트롤러는 보통 자기 영역의 지표만 보고 판단한다.

RAN-only 컨트롤러는 무선 지표를 중심으로, CN-only 컨트롤러는 코어 지표를 중심으로 움직인다.

하지만 실제 서비스 성능 저하는 대부분 단일 원인이 아니라, 양쪽이 얽힌 결과로 나타난다.

 

예를 들어 RAN에서 PRB가 포화되면 단말 처리량이 떨어지고, 그 결과 CN 쪽에서도 트래픽이 줄어든 것처럼 보일 수 있다.

반대로 UPF CPU가 포화되면 패킷 드롭과 처리량 저하가 생기고, RAN 쪽은 단순히 무선 품질이 나빠진 것처럼 오해할 수 있다.

 

AI Agent는 이런 상호작용을 해석해 “지금 보이는 현상이 어디에서 시작된 병목인가”를 판단해야 한다.

바로 이 지점이 cross-domain orchestration의 본질이다.

 

 

 

RAN 측 관측과 제어: OAI gNB

---

RAN Telemetry

 

RAN telemetry는 OAI gNB의 nrMAC_stats.log를 중심으로 수집한다. 주요 KPI는 다음과 같다.

KPI	수집원	단위	주기
PRB 사용률 (DL/UL %)	nrMAC_stats.log	UE별, slot별	1 tick
DL/UL 처리량 (Mbps)	nrMAC_stats.log	UE별	1 tick
MCS/CQI/BLER	nrMAC_stats.log	UE별	1 tick

 

 

• PRB 사용률 (DL/UL %)
• DL/UL 처리량 (Mbps)
• MCS / CQI / BLER

 

이 지표들은 UE별, slot별 혹은 tick 단위로 수집되며, Agent는 이를 통해 현재 무선 자원 사용 상태와 링크 품질을 파악한다.

 

PRB 사용률은 slice 내 UE들이 무선 자원을 얼마나 소모하고 있는지 보여준다.

DL/UL 처리량은 실효 성능을 나타내고, MCS/CQI/BLER는 단순 혼잡이 아니라 무선 품질 저하인지 여부를 구분하는 데 중요하다.

예를 들어 처리량이 낮더라도 CQI가 높고 BLER가 낮은데 PRB 사용률만 높다면, 무선 품질 문제보다는 자원 포화 가능성이 높다. 반대로 CQI 저하와 BLER 상승이 함께 보인다면 채널 품질 이슈를 먼저 의심해야 한다.

 

 

RAN Control Action

 

RAN 제어 (Control Action) Tool은 다음과 같다.

Tool: set_slice_prb_limit (slice_id, max_prb_dl, max_prb_ul)

항목	설명
구현 방법	OAI MAC 스케줄러(pf_dl/pf_ul)에 RNTI 별 PRB 상한 체크 패치 적용 + gNB 내부 REST API 노출
논문 매핑	ApplyPolicy(PRB_reservation += 10%)의 실제 구현체
적용 지연	1 tick (Rest → MAC 다음 스케줄링 사이클부터 반영)
Fallback	OAI config의 slice별 min/max PRB 파라미터 변경 + SIGHUP reload

 

이 Tool의 역할은 특정 슬라이스에 대해 DL/UL PRB 상한을 설정하는 것이다.

구현은 OAI MAC 스케줄러, 즉 pf_dl / pf_ul 로직에 RNTI별 PRB 상한 체크 패치를 적용하고,

이를 gNB 내부 REST API로 노출하는 방식으로 구성한다.

 

이 제어는 ApplyPolicy(PRB_reservation += 10%) 같은 추상 정책을 실제 시스템 수준의 Action으로 매핑한 구현체이다.

적용 지연은 대략 1 tick이다. AI Agent의 Inference로 정책이 결정되어 REST가 호출 되면,

이후 다음 MAC scheduling cycle부터 반영되도록 설계한다.

 

만약 REST 경로가 불안정하거나 실험 중 API 오류가 발생한다면, fallback으로 OAI config의 slice별 min/max PRB 파라미터를 변경하고 SIGHUP reload로 반영하는 방식도 고려할 수 있다.

즉, RAN 측에서 Agent가 할 수 있는 일은 요약하면 “슬라이스별 무선 자원 비중을 정책적으로 재조정하는 것”이다.

 

 

 

CN 측 관측과 제어: Free5GC

---

CN Telemetry

 

Core Network 측에서는 Free5GC와 UPF 상태를 중심으로 다음 KPI를 수집한다

 

KPI	수집원	단위	주기
UPF DL/UL 처리량	Prometheus :9091	UPF별(=slice별)	1 tick
UPF CPU 사용률 (%)	docker stats / cgroup	UPF 컨테이너별	1 tick
UPF 패킷 드롭률	iptables / UPF 로그	UPF 별	1 tick
PDU 세션 수	SMF 로그 / Prometheus	slice 별	1 tick

 

UPF 처리량은 Prometheus :9091에서 가져오고, slice별 독립 UPF 구성을 전제로 하면 사실상 slice별 처리량 지표로 볼 수 있다.

CPU 사용률은 docker stats 혹은 cgroup 인터페이스를 통해 컨테이너 단위로 읽는다.

패킷 드롭률은 iptables 카운터나 UPF 로그를 통해 추정한다.

 

PDU 세션 수는 SMF 로그 또는 Prometheus 기반으로 추적한다.

이 조합이 중요한 이유는, 단순 처리량만 봐서는 CN 병목을 판단하기 어렵기 때문이다.

예를 들어 처리량이 낮더라도 CPU가 낮으면 부하 부족일 수 있고,

처리량이 낮은데 CPU가 높고 드롭률도 높다면 UPF 병목 가능성이 크다.

 

 

CN Control Action 1: UPF 자원 제어

 

첫 번째 CN 제어 Tool은 다음과 같다.

Tool : set_upf_resource (slice_id, cpu_quota, bandwidth_mbps)

항목	설명
구현 방법	slice별 독립 UPF 컨테이너에 docker update --cpus (cgroup cpu.max) + N6 인터페이스에 tc qdisc HTB 적용
논문 매핑	ApplyPolicy[Core_Bandwidth += 1Gbps]의 실제 구현체
적용 지연	1 tick (docker update + tc 명령 실행 <1초)

 

이 Tool은 slice별 독립 UPF 컨테이너에 대해 CPU quota와 N6 인터페이스 대역폭을 조정한다.

구현은 docker update --cpus를 통한 cgroup cpu.max 조정과, tc qdisc HTB를 통한 bandwidth shaping으로 이뤄진다.

 

이는 ApplyPolicy[Core_Bandwidth += 1Gbps]처럼 기술되는 정책을 실제 NF 제어 액션으로 연결하는 역할을 한다.

적용 지연은 1 tick 수준이다. docker update와 tc 명령 실행이 보통 1초 이내에 끝나므로, policy loop 관점에서는 충분히 짧다.

 

이 Tool은 CN이 병목인 상황에서 직접적인 효과를 가진다.

예를 들어 UPF CPU가 포화되어 패킷 드롭이 생기는 경우, PRB를 아무리 늘려도 해결되지 않는다.

이때는 UPF CPU를 늘리거나, slice별 대역폭 shaping을 조정해야 한다.

 

 

CN Control Action 2: Session AMBR 변

 

두 번째 CN 제어 Tool은 다음과 같다.

Tool: update_session_ambr (slice_id, dl_ambr_mbpos, ul_ambr_mbps)

항목	설명
구현 방법	Free5GC WebUI API (PUT/api/subscriber/{imsi}로 Session-AMBR 변경 + UE 재접속 트리거
적용 지연	2 ticks (WebUI API 호출 + UE 재접속 소요 시간)

 

적용 지연은 2 ticks로 보는 것이 현실적이다.

PI 호출 자체는 빠르지만, 실제 정책이 세션에 반영되려면 UE가 다시 attach/reattach하는 과정이 필요하기 때문이다.

이 액션은 즉각적인 리소스 증설이라기보다, slice별 세션 bitrate ceiling을 정책적으로 조정하는 수단이다.

예를 들어 특정 슬라이스가 과도한 bitrate를 점유하며 다른 슬라이스 SLA를 침해하는 상황이라면,

AMBR을 조정해 traffic envelope를 제어할 수 있다.

 

 

 

제어 포인트 요약

---

정리하면 Agent가 다루는 핵심 제어 포인트는 세 가지다.

 

첫째, RAN에서 set_slice_prb_limit을 통해 slice별 PRB 할당 상한을 조정한다.

이는 무선 자원 배분에 직접적인 영향을 미치며, 반영 지연은 1 tick이다.

 

둘째, CN에서 set_upf_resource를 통해 slice별 UPF CPU quota와 bandwidth를 조정한다.

이는 코어망 처리 능력과 traffic shaping에 영향을 주며, 반영 지연은 1 tick이다.

 

셋째, CN에서 update_session_ambr를 통해 slice별 세션 최대 bitrate를 조정한다.

이는 subscriber/session policy에 반영되며, 적용에는 재접속이 필요하므로 2 ticks 정도의 지연이 발생한다.

 

이 세 가지 제어점은 성격이 서로 다르다.

PRB 제어는 무선 스케줄링 차원의 자원 배분이고, UPF 제어는 NF 자원과 코어 처리 능력 제어이며,

AMBR은 가입자 세션 정책 제어다. Agent는 이들 중 무엇이 현재 병목에 가장 직접적인 액션인지 선택해야 한다.

 

 

 

Cross-Domain 제어가 왜 필요한가

---

이 프로토타입의 핵심 검증 포인트는 바로 여기에 있다.

도메인 분리된 컨트롤러는 cross-domain 병목을 볼 수 없기 때문에, 종단 간 최적해를 놓친다.

이를 테스트베드에서 세 가지 대표 시나리오로 확인할 수 있다.

 

시나리오 1: RAN 병목

---

PRB가 포화되면서 처리량이 저하되는 상황을 가정하자.

이때 CN-only 컨트롤러는 단지 UPF 처리량이 줄어든 것만 보고, CN 대역폭이 부족하다고 오판할 수 있다.

그 결과 불필요하게 UPF 대역폭이나 CPU를 늘리는 액션을 수행하게 된다.

 

하지만 E2E Agent는 RAN telemetry를 함께 본다.

PRB 사용률이 높고, CQI/BLER 패턴이 무선 품질 문제보다는 자원 포화에 가깝다는 점을 확인하면, 근본 원인이 RAN임을 식별할 수 있다. 따라서 CN 자원을 늘리는 대신 PRB 배분을 조정하는 것이 맞다.

 

시나리오 2: CN 병목

---

이번에는 UPF CPU가 포화되어 패킷 드롭이 발생하는 상황이다.

이 경우 RAN-only 컨트롤러는 처리량 감소만 보고 PRB가 부족하다고 오판할 수 있다.

그래서 무선 자원을 더 할당하려고 하지만, 실제로는 CN에서 패킷이 처리되지 못하고 있기 때문에 효과가 없다.

 

반면 E2E Agent는 UPF CPU 사용률과 드롭률을 함께 보고 CN 병목임을 식별한다.

이때는 set_upf_resource로 CPU quota를 늘리는 것이 직접적인 해결책이다.

 

시나리오 3: Metaverse slice의 복합 병목

---

가장 흥미로운 상황은 Metaverse 슬라이스다.

이 슬라이스는 저지연과 고대역폭을 동시에 요구하기 때문에, PRB와 UPF 양쪽이 모두 한계에 접근하기 쉽다.

 

이 경우 RAN-only 혹은 CN-only 컨트롤러는 자기 영역 안에서만 문제를 풀려다 한쪽 최적화에 머무르게 된다.

예를 들어 PRB만 늘려도 UPF가 감당하지 못하고, UPF만 늘려도 무선 구간이 포화되면 효과가 제한적이다.

 

오직 E2E Agent만이 양쪽 상태를 함께 보고, PRB와 UPF 자원을 동시에 혹은 순차적으로 조정해 SLA 충족 가능성을 높일 수 있다. 이 시나리오가 바로 cross-domain orchestration의 존재 이유를 가장 잘 보여준다.