RAN-CN 시뮬레이션 환경에서 LLM 기반 Resource 할당하기

LLM for Resource Allocation 실험 환경의 목표

---

앞선 실험에서는 RAN과 Core Network 환경을 각각 Python으로 구축하고,

작은 오픈소스 LLM이 RAN PRB allocation 문제를 얼마나 안정적으로 풀 수 있는지 확인했다.

 

그 결과, 작은 모델은 네트워크 도메인에 대한 기본적인 개념 설명은 가능했지만, 실제 자원 할당 문제에서는 여러 한계를 보였다.

특히 PRB 총합 제약을 깨거나, URLLC에서 eMBB로 자원을 넘긴다는 reasoning을 하면서 실제 출력은 반대로 생성하는 등 numerical action과 reasoning 간 불일치가 자주 발생했다.

이를 위해 기존의 Local에서 동작하는 작은 LLM 모델 대신, 사용 모델인 gpt-5-mini 모델의 성능을 확인한다.

 

이번에는 실험 범위를 확장하여 RAN만이 아니라 Core Network까지 함께 고려하는 E2E Resource Allocation 문제를 구성한다. 이는 앞서 살펴본 Cross-Domain Optimization 논문에서 제안한 방향과 맞닿아 있다.

해당 논문은 RAN radio 자원과 CN computing capacity를 함께 최적화해야 E2E SLA Satisfaction을 높일 수 있다고 주장한다. RAN과 CN을 따로 최적화하면 각 도메인에서는 그럴듯한 선택을 할 수 있지만,

전체 E2E 관점에서는 suboptimal decision이 발생할 수 있기 때문이다.

 

이번 실험의 핵심 질문은 다음과 같다.

LLM이 RAN과 CN의 상태 정보를 동시에 보고, E2E SLA 관점에서 통합 자원 할당 결정을 내릴 수 있는가?

 

 

 

1. RAN-CN 통합 자원 할당 문제로 확장하기

---

기존 작은 모델에서의 RAN-only 실험에서는 LLM이 다음 하나만 결정했다.

{"PRB_embb": X, "PRB_urllc": Y}

 

하지만 E2E Network Slicing에서는 RAN만 최적화해서는 충분하지 않다.

사용자의 SLA는 RAN latency와 CN latency가 결합된 E2E latency에 의해 결정된다.

 

따라서 이번에는 LLM이 다음 두 종류의 자원을 동시에 조정하도록 만들었다.

1. RAN: eMBB / URLLC 간 PRB allocation
2. CN: eMBB / URLLC 간 virtualized resource allocation

 

출력 형식도 다음과 같이 확장했다.

{
  "PRB_embb": X1,
  "PRB_urllc": Y1,
  "Resource_eMBB": X2,
  "Resource_URLLC": Y2,
  "reasoning": "brief explanation"
}

 

즉, LLM은 RAN의 PRB 200개를 eMBB와 URLLC에 나누고,

동시에 CN의 resource pool 100개를 eMBB와 URLLC에 나누어야 한다.

 

 

 

2. 통합 Prompt의 기본 구조

---

이번 실험에서는 LLM에게 다음 역할을 부여했다.

You are an intelligent 5G network slicing resource allocation manager responsible for BOTH RAN and CN layers.

 

기존 RAN-only prompt와 달리, 이번에는 LLM이 두 도메인을 모두 고려해야 한다는 점을 명시했다.

시스템 정보는 다음과 같이 설정했다.

- eMBB users: 10-100
- URLLC users: 10-100
- Total PRBs available: 200
- Total CN resource pool: 100

 

SLA 조건은 E2E latency 기준으로 정의했다.

- eMBB: average E2E latency ≤ 200ms
- URLLC: average E2E latency ≤ 10ms

 

여기서 중요한 점은 RAN latency나 CN latency가 아니라, 최종적으로는 E2E latency가 SLA 판단 기준이라는 것이다.

RAN에서 latency가 낮더라도 CN에서 병목이 발생하면 E2E SLA는 깨질 수 있다.

반대로 CN resource가 충분하더라도 RAN PRB가 부족하면 사용자는 SLA를 만족하지 못한다.

따라서 prompt에서도 다음 문장을 강하게 넣었다.

Focus on E2E SLA ratios as the primary metric.
Prioritize end-to-end performance above all other metrics.

 

 

 

3. Iterative Prompting 방식

---

이번 실험의 가장 중요한 특징은 single-shot prompting이 아니라 iterative prompting이라는 점이다.

즉, LLM에게 한 번만 자원 할당을 시키는 것이 아니라, 매 step마다 다음 과정을 반복한다.

1. 현재 RAN/CN allocation으로 simulation 수행
2. RAN, CN, E2E latency 및 SLA ratio 계산
3. 최근 10-step history를 prompt에 삽입
4. LLM이 다음 allocation 결정
5. JSON output parsing
6. 다음 step simulation에 반영

 

이 방식은 강화학습의 closed-loop interaction과 유사하다.

다만 policy network가 직접 학습되는 것은 아니고, LLM이 prompt에 제공된 recent history를 기반으로 다음 action을 결정한다.

 

이처럼 LLM에서의 Iterative Prompting 방식을 사용한 이유는

Network slicing resource allocation은 한 번의 decision으로 끝나는 문제가 아니기 때문이다.

 

특정 allocation이 좋은지 나쁜지는 다음 step의 latency와 SLA satisfaction을 관찰해야 알 수 있다.

예를 들어 URLLC에서 eMBB로 PRB를 1개 넘겼을 때, 당장 URLLC SLA가 유지될 수도 있다.

그러면 추가로 1개를 더 넘길 여지가 있다.

 

하지만 어느 순간 URLLC PRB가 충분하지 않게 되면 URLLC latency가 급격히 증가하고,

SLA satisfaction이 cliff-like하게 무너질 수 있다.

따라서 LLM에게는 단일 시점의 state만 제공하는 것이 아니라, 최근 몇 step 동안의 trend를 제공해야 한다.

 

이번 prompt에서는 다음과 같은 history를 제공했다.

PAST 10-STEP E2E DATA
- E2E_URLLC_SLA_ratio
- E2E_eMBB_SLA_ratio
- E2E_URLLC_latency
- E2E_eMBB_latency

PAST 10-STEP RAN DATA
- RAN_URLLC_SLA_ratio
- RAN_eMBB_SLA_ratio
- RAN_URLLC_latency
- RAN_eMBB_latency
- PRB_URLLC_history
- PRB_eMBB_history

PAST 10-STEP CN DATA
- CN_URLLC_SLA_ratio
- CN_eMBB_SLA_ratio
- CN_URLLC_latency
- CN_eMBB_latency
- Resource_URLLC_history
- Resource_eMBB_history

 

이 구조는 이전 RAN-only 실험에서 얻은 Insight를 반영한 것이다.

row-wise table 형태보다 feature-wise list 형태가 작은 모델에게 더 안정적이었고,

61/100 같은 fraction보다 0.61 같은 ratio 형태가 threshold 판단에 더 유리했다.

 

맨 처음의 상태는 다음과 같았다.

RAN: [PRB_eMBB=100, PRB_URLLC=100]
CN:  [Resource_eMBB=50, Resource_URLLC=50]

 

초기 관측값에서는 URLLC의 E2E SLA ratio가 1.00으로 매우 안정적이었고, eMBB의 E2E SLA ratio는 0.62 수준으로 낮았다. 또한 eMBB E2E latency는 222.37ms로 SLA 기준인 200ms를 초과했다.

이 경우 LLM은 다음과 같은 결정을 내렸다.

{
  "PRB_embb": 101,
  "PRB_urllc": 99,
  "Resource_eMBB": 50,
  "Resource_URLLC": 50,
  "reasoning": "E2E_URLLC and CN_URLLC SLA ratios are 1.00, so shift 1 PRB from URLLC to eMBB while keeping CN unchanged."
}

 

이 결정의 배경은 다음과 같다.

URLLC는 RAN과 CN 모두에서 SLA를 안정적으로 만족하고 있으므로, 우선 RAN PRB 1개를 URLLC에서 eMBB로 이동한다.

반면 CN은 아직 충분히 안정적이므로 그대로 유지한다.

 

 

Safety Guard 설계

---

이번 prompt에서 가장 중요하게 둔 것은 URLLC safety guard다.

URLLC는 latency requirement가 매우 엄격하고, resource가 부족해지는 순간 SLA가 급격히 무너질 수 있다.

따라서 eMBB 성능을 높이기 위해 URLLC 자원을 가져오더라도, URLLC safety constraint는 반드시 보호되어야 한다.

 

Prompt에는 다음과 같은 조건을 넣었다.

- URLLC exhibits cliff-like behavior when under-provisioned.
- Ignore short-term fluctuations.
- React only to sustained multi-step trends.
- If E2E_URLLC_SLA_ratio remains consistently high, URLLC is safely over-provisioned.
- CN_URLLC_SLA_ratio must never fall below 0.98.
- If E2E_URLLC_SLA_ratio falls to 0.90 or below, shift resources back to URLLC.

 

여기서 핵심은 단순히 URLLC SLA가 1.00이면 무조건 자원을 빼앗는 것이 아니다.

LLM은 다음 두 가지를 함께 봐야 한다.

1. E2E_URLLC_SLA_ratio가 최근 step에서 충분히 안정적인가?
2. CN_URLLC_SLA_ratio가 0.98 이상으로 유지되는가?

이 두 조건이 만족될 때만 URLLC가 over-provisioned 상태라고 판단하고 eMBB로 자원을 이동할 수 있도록 했다.

 

1. 초기 Iteration 결과: RAN 중심 조정

---

초기 몇 step에서는 LLM이 매우 일관된 결정을 내렸다.

URLLC E2E SLA ratio는 계속 1.00이었고, CN_URLLC_SLA_ratio 역시 1.00으로 유지되었다.

반면 eMBB E2E SLA ratio는 0.6~0.7 수준에 머물렀고, eMBB E2E latency는 200ms를 넘는 경우가 많았다.

이에 따라 LLM은 다음과 같이 RAN PRB를 조금씩 eMBB로 이동했다.

Step 0: RAN [100, 100], CN [50, 50]
Step 1: RAN [101, 99],  CN [50, 50]
Step 2: RAN [102, 98],  CN [50, 50]
Step 3: RAN [103, 97],  CN [50, 50]
Step 4: RAN [104, 96],  CN [50, 50]
Step 5: RAN [105, 95],  CN [50, 50]
Step 6: RAN [106, 94],  CN [50, 50]

 

이 구간에서 LLM은 CN resource를 건드리지 않았다.

reasoning을 보면, LLM은 CN_URLLC_SLA_ratio가 1.00이지만 CN allocation을 바꾸기보다는 RAN PRB를 먼저 조정했다.

이는 prompt에 포함된 다음 정책의 영향을 받은 것으로 보인다.

When CN_URLLC_SLA_ratio satisfies the URLLC safety condition, 
prioritize improving E2E_eMBB_SLA_ratio by shifting RAN PRBs from URLLC to eMBB.

 

즉, LLM은 eMBB 성능 저하의 우선 조정 지점을 RAN으로 판단했고,

CN은 URLLC safety margin을 유지하기 위해 그대로 두었다.

이 부분은 앞선 RAN-only 실험보다 훨씬 안정적이었다.

PRB 총합은 계속 200을 유지했고, 매 step마다 ±1 PRB constraint도 잘 지켰다.

 

 

2. CN Resource까지 조정하기 시작한 구간

---

몇 step 이후 LLM은 CN resource도 함께 조정하기 시작했다.

예를 들어 다음과 같은 allocation이 등장했다.

RAN: [107, 93]
CN:  [51, 49]

 

이후에는 다음처럼 CN resource가 eMBB 쪽으로 조금씩 이동했다.

CN [50, 50] → [51, 49] → [52, 48] → [53, 47] → [54, 46]

 

초기에는 RAN만 조정하다가, eMBB E2E SLA가 여전히 충분히 높지 않고 URLLC가 계속 안정적이라고 판단되자 CN에서도 eMBB resource를 늘리기 시작한 것이다.

이는 LLM이 단순히 하나의 고정 rule만 반복한 것이 아니라,

RAN과 CN이라는 두 개의 조정 축을 모두 활용하려 했다는 점에서 E2E 관점에서의 Resource Allocation이다.

 

 

3. LLM의 Reasoning은 이전보다 훨씬 안정적이었다

---

작은 모델 기반의 RAN-only 실험에서 가장 큰 문제 중 하나는 reasoning과 action이 자주 어긋난다는 점이었다.

예를 들어 “URLLC에서 eMBB로 PRB를 이동한다”고 말하면서 실제로는 eMBB PRB를 줄이는 경우가 있었다.

 

그러나 이번 integrated prompt에서는 출력이 비교적 안정적이었다.

예를 들어 다음과 같은 reasoning이 반복적으로 등장했다.

E2E_URLLC is consistently over-provisioned.
Shift 1 PRB from URLLC to eMBB to improve E2E_eMBB.
Keep CN allocation unchanged to preserve CN_URLLC safety.

 

그리고 실제 output도 이에 맞게 생성되었다.

{
  "PRB_embb": 106,
  "PRB_urllc": 94,
  "Resource_eMBB": 50,
  "Resource_URLLC": 50
}

 

즉, reasoning의 방향과 action의 방향이 일치했다.

이는 작은 모델 대비 큰 상용 모델이 가지는 효과와 prompt 구조 개선의 효과일 것.

특히 다음 요소들이 안정성에 기여한 것으로 보인다.

1. CURRENT ALLOCATION을 별도로 명시
2. RAN history와 CN history를 분리
3. E2E metric을 primary data로 가장 위에 배치
4. PRB 총합과 CN resource 총합을 constraint로 명시
5. ±1 step adjustment를 반복적으로 강조
6. output format을 pure JSON으로 고정

 

 

 

E2E Metric을 Primary로 둔 효과

---

이번 prompt에서 가장 중요한 설계는 E2E metric을 primary로 둔 것이다.

RAN-only 실험에서는 RAN latency와 RAN SLA만 보고 PRB allocation을 결정했다.

하지만 실제 network slicing에서는 사용자의 최종 SLA가 RAN과 CN의 합성 결과로 결정된다.

 

예를 들어 RAN_eMBB_latency가 낮아졌더라도 CN_eMBB_latency가 높으면,

E2E_eMBB_latency는 여전히 SLA 기준을 넘을 수 있다.

 

이번 prompt는 이 문제를 해결하기 위해 다음 순서로 데이터를 제공했다.

1. E2E DATA
2. RAN DATA
3. CN DATA
4. CURRENT ALLOCATION

 

즉, LLM이 먼저 E2E SLA 상태를 보고, 그다음 RAN과 CN 중 어느 쪽이 병목인지 판단하도록 유도했다.

실제 출력에서도 LLM은 대부분 E2E_URLLC_SLA_ratio를 먼저 언급한 뒤, RAN 또는 CN resource를 조정했다.

 

이것은 앞서 논문에서 강조한 cross-domain reasoning과 연결된다.

도메인별 metric만 보면 각 도메인에서 local optimum에 빠질 수 있지만,

E2E metric을 중심에 두면 전체 서비스 품질 관점에서 decision을 내릴 수 있다.

 

이 효과를 조금 더 구체적으로 확인하기 위해 총 5개의 scope에서 성능평가를 진행했다.

 

• RR Baseline: RAN과 CN 각각에서 학습 없이 정적인 domain-local 자원 할당을 수행하는 기준 성능 평가.
• RAN-specific LLM: RAN 상태만 보고 PRB allocation을 최적화하는 domain-specific LLM 성능 평가.
• CN-specific LLM: CN 상태만 보고 computing/link resource 할당을 최적화하는 domain-specific LLM 성능 평가.
• Combined RAN LLM & CN LLM: RAN LLM과 CN LLM을 함께 사용하되,
  각 도메인이 독립적으로 판단할 때의 E2E 성능 평가.
• Proposed E2E LLM: RAN-CN 상태를 동시에 고려하여 unified allocation decision을 생성하는
  cross-domain LLM 성능 평가.

성능평가 결과는 다음과 같다.

 

 

Total SLA satisfaction at 40 users.

 

40명 사용자 시나리오, 즉 20명의 eMBB 사용자와 20명의 URLLC 사용자가 존재하는 환경에서

E2E LLM 기반 최적화 방식이 가장 높은 SLA 만족 성능을 보였다.

 

E2E LLM은 평균 27.50명의 사용자를 SLA 기준 내에서 만족시켰으며,

이는 RAN LLM과 CN LLM을 각각 독립적으로 사용하는 combined RAN LLM & CN LLM 방식의 26.63명보다 높은 결과다.

 

이는 각 도메인을 개별적으로 최적화하는 방식이 domain-wise로는 합리적인 결정을 내릴 수 있지만,

E2E 관점에서는 suboptimal한 결과로 이어질 수 있음을 보여준다.

 

 

Total SLA Satisfaction as a function of the number of users

 

또한 사용자 수를 10명에서 80명까지 변화시키며 traffic load에 따른 성능을 평가한 결과,

네트워크 부하가 증가할수록 전체 SLA satisfaction ratio는 감소했다.

 

이는 RAN의 radio resource와 CN의 computing capacity에서 resource contention이 심화되기 때문이다.

그럼에도 E2E LLM 방식은 모든 사용자 수 조건에서 baseline보다 일관되게 높은 성능을 보였다.

이는 RAN과 CN을 분리해서 판단하는 방식보다, 두 도메인의 constraint와 bottleneck을 함께 고려하는 unified cross-domain reasoning이 더 효과적인 resource allocation을 가능하게 함을 의미한다.

 

 

Iterative Prompting의 장점

---

이번 실험에서 iterative prompting 방식은 몇 가지 장점을 보였다.

 

첫 번째는 trend-aware decision이 가능하다는 점이다.

단일 step의 metric만 보면 latency fluctuation 때문에 잘못된 결정을 내릴 수 있다.

예를 들어 특정 step에서 eMBB latency가 우연히 낮게 나왔다고 해서 eMBB 자원이 충분하다고 판단하면 안 된다.

최근 10-step history를 제공하면 LLM은 “일시적 개선”과 “지속적 개선”을 어느 정도 구분할 수 있다.

 

두 번째는 conservative control이 가능하다는 점이다.

이번 prompt에서는 RAN과 CN 모두 ±1 step adjustment만 허용했다.

이 때문에 LLM이 한 번에 극단적인 allocation을 출력하는 것을 막을 수 있었다.

 

세 번째는 reasoning log를 통해 decision trace를 확인할 수 있다는 점이다.

각 step에서 LLM은 왜 RAN만 조정했는지, 왜 CN을 유지했는지, 왜 둘 다 조정했는지를 짧게 설명했다.

이 reasoning은 완벽하지는 않지만, closed-loop decision의 해석 가능성을 높인다.

 

이는 네트워크 제어의 핵심적인 문제인 Closed-Loop Control과도 밀접하게 맞닿는다.

 

 

 

 

Resource Allocation을 위한 AI Agent 확장 방향

---

해당 실험은 LLM에게 네트워크 상태를 prompt로 제공하고,

다음 RAN-CN resource allocation 값을 직접 출력하게 하는 방식이었다.

즉, LLM이 하나의 decision maker처럼 동작했다.

 

하지만 실제 네트워크 제어 시스템 관점에서 보면, LLM 하나가 곧바로 자원 할당기를 대체하는 구조는 위험하다.

PRB 총합 제약, CN resource 총합 제약, URLLC safety guard, JSON parsing, fallback policy까지 모두 LLM 내부 reasoning에 의존하게 되기 때문이다.

 

따라서 이 문제는 단순한 Prompt Engineering을 넘어 Agent Engineering, 

더 정확히는 Harness Engineering 관점으로 확장되어야 한다.

 

이러한 관점에서 LLM은 raw allocation number를 직접 생성하는 optimizer가 아니라,

현재 E2E 상태를 해석하고 어떤 방향으로 자원을 움직일지 제안하는 policy reasoning module로 사용되어야 한다.

 

Deterministic한 Python harness는 simulation 실행, metric 추출, action 후보 생성, constraint validation,

safety fallback을 담당하는 구조로 이루어져야 한다.

예를 들어 Harness는 먼저 현재 RAN/CN/E2E latency와 SLA ratio를 계산하고, 가능한 action 후보를 제한된 형태로 만든다.

RAN_ACTION ∈ {URLLC→eMBB, eMBB→URLLC, HOLD}
CN_ACTION  ∈ {URLLC→eMBB, eMBB→URLLC, HOLD}

 

 

이후 LLM Agent는 최근 history와 bottleneck feature를 보고 이 후보 중 하나를 선택한다.

최종 PRB와 CN resource 숫자는 LLM이 직접 계산하지 않고, Harness가 현재 allocation에 action을 적용해 산출한다.

마지막으로 Harness는 PRB_embb + PRB_urllc = 200, Resource_eMBB + Resource_URLLC = 100, ±1 step constraint, URLLC safety threshold를 검증한다.

만약 LLM의 선택이 위험하거나 잘못된 형식이면, predefined fallback policy가 적용된다.

 

이 구조로 바꾸면 LLM의 역할은 더 명확해진다. LLM은 계산기가 아니라, RAN과 CN의 상태를 함께 읽고 E2E 관점에서 병목을 해석하는 reasoning agent가 된다.

그리고 Harness는 그 reasoning이 실제 네트워크 제어에 안전하게 반영되도록 보장하는 control wrapper가 된다.

 

결국 LLM for Resource Allocation의 현실적인 구현 방향은 “LLM 단독 최적화”가 아니라 “LLM Agent + Deterministic Harness” 구조다.

Cross-domain reasoning은 LLM이 담당하고, hard constraint와 safety-critical control은 Harness가 담당한다.

이 분리가 있어야만 LLM 기반 자원 할당이 실험적 prompt 수준을 넘어, 실제 네트워크 슬라이싱 제어 구조로 확장될 수 있다.

 

 

따라서 추후 발전 방향은 다음과 같다.

1. 실제 OpenAirInterface, Free5GC와 같은 Prototype 구축
2. Harness 구조를 갖춘 AI Agent 구축
3. AI Agent와 Prototype 간의 통합 (MCP, A2A)
4. AI Agent의 안전한 Resource Control 방향 설계