현재까지 구현된 것
현재 시스템은 원래 단일 gNB + 다중 UE 구조에서 출발했다.
즉, 하나의 OAI gNB가 RF simulator 서버 역할을 하고, 여러 개의 OAI UE가 클라이언트로 접속하는 구조다.
[gNB / rfsim server]
▲
│
┌──────┼──────┐
│ │ │
[UE0] [UE1] ... [UEN]이 구조에서는 Sionna RT가 UE별 CIR(Channel Impulse Response)을 계산하고,
OAI의 RF simulator 경로에 해당 CIR을 주입한다. 이를 통해 각 UE가 서로 다른 무선 채널을 갖도록 만들 수 있다.
즉, 지금까지 구현한 :per-ue 구조의 의미는 다음과 같다.
| 항목 | 상태 |
| 다중 UE | 가능 |
| 단일 Cell | 가능 |
| UE별 CIR | 가능 |
| UE별 RSRP/KPI 변화 | 가능 |
| 20 UE 확장 | 가능 |
| Handover | 불가능 |
여기까지는 다중 UE, 단일 셀 환경이다.
이 구조는 downlink 관점에서 매우 자연스럽다.
gNB 하나가 여러 UE에게 신호를 보내고, RF simulator 서버가 여러 UE 클라이언트를 받아들이면 되기 때문이다.
새로 구현하려던 목표
다음 목표는 더 현실적인 캠퍼스 디지털 트윈 시나리오다.
즉, Sionna RT 기반 경희대 3D 씬 안에 gNB를 하나 더 추가하고,
UE가 한 셀 영역에서 다른 셀 영역으로 이동하면서 handover가 발생하는 것을 확인하는 것이다.
목표 시나리오는 다음과 같다.
초기 위치: RSRP_gNB2 > RSRP_gNB1
중간 지점: RSRP_gNB2 ≈ RSRP_gNB1
gNB1 근처: RSRP_gNB1 > RSRP_gNB2그리고 이 RSRP 교차 지점 근처에서 handover가 발생해야 한다.
구현 목표를 정리하면 다음과 같다.
| 목표 | 설명 |
| 다중 Cell | gNB 또는 DU를 2개 이상 배치 |
| UE 이동 | UE를 gNB2 영역에서 gNB1 방향으로 이동 |
| 셀별 RSRP 계산 | 각 UE 위치에서 serving/neighbor cell의 수신 세기 계산 |
| A3 조건 판단 | target cell이 serving cell보다 충분히 강해지는지 확인 |
| Handover 실행 | OAI가 실제 F1 handover 절차 수행 |
즉, 궁극적으로는 다음 구조를 만들고 싶은 것이다.
[gNB/DU0]
▲
│
[UE0] [UE1] [UE2] ... [UEn]
│
▼
[gNB/DU1]문제는 이 구조가 단순히 “gNB 하나 더 띄우면 되는 문제”가 아니라는 점이다.
OAI Handover 관점에서 먼저 확인한 것
Sionna-rk는 OAI 소스를 포함하고 있고, 해당 코드베이스에는 F1, N2, Xn handover와 관련된 흔적이 있다.
하지만 OAI 2025.w34 branch에서 검증 가능한 경로는 사실상 F1 handover다.
handover tutorial 자체도 “현재는 F1 handover만 지원된다”고 설명한다.
F1 handover는 하나의 CU 아래에 여러 DU가 붙어 있고, UE가 DU0에서 DU1로 이동하는 구조다.
[UE]
│ Uu
▼
[DU0] ── F1 ──┐
▼
[CU] ── NG ── [AMF]
▲
[DU1] ── F1 ──┘여기서 중요한 점은 CU가 유지된다는 것이다.
즉, AMF 입장에서는 같은 gNB-CU 아래에서 DU만 바뀌는 intra-CU mobility에 가깝다.
OAI tutorial의 F1 handover 예제도 정확히 이 구조를 사용한다.
UE는 처음 DU0에 연결되어 있고, handover 트리거에 의해 DU1로 이동한다.
Measurement Report는 아직 자동으로 동작하지 않는다
일반적인 NR handover는 다음 순서로 진행된다.
1. UE가 serving cell과 neighbor cell을 측정
2. neighbor cell이 serving cell보다 좋아짐
3. UE가 Measurement Report 전송
4. CU/gNB가 handover 결정
5. target cell로 RRC Reconfiguration
6. UE가 target cell에 RACH 수행
7. handover 완료하지만 현재 OAI rfsim UE는 measurement reporting이 완성되어 있지 않다.
OAI tutorial도 “UE의 measurement reporting과 mobility용 RRC Reconfiguration 처리가 완료되어 있지 않지만, RF simulator에서 간단한 handover 테스트는 가능하다”고 설명한다.
따라서 자동 handover는 어렵기에 그ㅜ 대신 OAI tutorial은 telnet을 통해 CU에 직접 handover 명령을 넣는 방식을 사용한다.
echo ci trigger_f1_ho | nc 127.0.0.1 9090DU1이 online된 뒤 위 명령을 보내면 UE가 DU0에서 DU1로 handover되는 것을 확인할 수 있다.
이 방식의 의미는 UE가 Measurement Report를 보내서 handover를 유도하는 것이 아니라,
사용자가 CU에게 “지금 handover 해라”라고 강제로 명령하는 것이다.
OAI 문서도 handover 결정은 network-side에 있고 UE는 measurement를 통해 CU를 보조하는 역할이라고 설명한다.
따라서 Sionna-rk 환경에서 가장 현실적인 구조는 다음과 같다.
[Sionna RT]
│
├─ UE 위치별 CIR 계산
├─ Cell별 RSRP 계산
└─ A3 조건 판단
│
▼
[telnet: ci trigger_f1_ho]
│
▼
[OAI CU]
│
└─ 실제 F1 handover 실행즉, Sionna가 measurement와 handover 판단을 대행하고, OAI가 handover 실행만 담당하는 하이브리드 구조다.
첫 번째 걸림돌: CU 프로세스 크래시
F1 handover를 하려면 기존 monolithic gNB를 다음처럼 분리해야 한다.
기존:
[oai-gnb] + [UE N개]
변경:
[oai-cu] + [oai-du0] + [oai-du1] + [UE]그런데 Sionna-rk가 채널 에뮬레이션을 위해 OAI에 추가한 코드 때문에 CU가 실행되지 않는 문제가 발생했다.
문제의 핵심은 CU에는 PHY gNB 인스턴스가 없다는 점이다.
CU는 RRC, PDCP 등 상위 계층 중심으로 동작하고, PHY/L1은 DU에 있다.
따라서 CU 프로세스에서는 RC.nb_nr_L1_inst = 0이고, RC.gNB[0]가 존재하지 않는다.
그런데 Sionna-rk가 추가한 채널 에뮬레이션 초기화 코드가 CU에서도 다음과 같은 접근을 시도했다.
NR_DL_FRAME_PARMS *fp = &RC.gNB[0]->frame_parms;
init_plugins(fp);CU에서는 RC.gNB[0]가 NULL이므로, 이 코드는 바로 NULL pointer dereference를 일으킨다.
결과적으로 CU 프로세스가 세그멘테이션 폴트로 죽는다.
이 문제는 설정 파일로 피할 수 없다. 이미 코드 레벨에서 CU에 존재하지 않는 PHY 인스턴스를 무조건 참조하고 있기 때문이다.
해결책은 간단하다. CU에서는 채널 에뮬레이션 플러그인 초기화를 건너뛰면 된다.
if (!NODE_IS_CU(node_type)) {
NR_DL_FRAME_PARMS *fp = &RC.gNB[0]->frame_parms;
init_plugins(fp);
}이 가드의 의미는 다음과 같다.
| 조건 | 동작 |
| CU | PHY가 없으므로 init_plugins() 건너뜀 |
| DU | PHY가 있으므로 채널 에뮬레이션 플러그인 초기화 |
| Monolithic gNB | PHY가 있으므로 기존처럼 초기화 |
이 수정은 Sionna CIR을 IQ 샘플에 적용하는 채널 에뮬레이션은 PHY/L1이 있는 DU 또는 monolithic gNB에서 필요하지, CU에서 필요한 기능이 아니기 때문에 논리적으로도 적절하다.
다만 소스만 고쳐서는 안 된다. 컨테이너 안에서 실행되는 nr-softmodem은 이미 컴파일된 바이너리다.
따라서 수정한 소스가 반영되려면 OAI gNB 이미지를 다시 빌드해야 한다.
소스 수정만 함 → 효과 없음
OAI 재컴파일 필요 → 새 nr-softmodem 생성
Docker 이미지 재빌드 → 컨테이너 재기동즉, F1 handover를 살리기 위한 첫 번째 작업은 CU 크래시를 막는 코드 수정과 재빌드다.
여기까지 하면 F1 handover는 되는가?
여기까지 하면 단일 UE 기준의 Handover는 가능하다.
즉, 다음 구조는 가능하다.
[UE 1개 / rfsim server]
▲ ▲
│ │
[DU0] [DU1]
client client
│ │
└── CU ─┘OAI F1 handover tutorial도 이 구조를 사용한다.
일반적인 rfsim 구조에서는 gNB가 서버이고 UE가 클라이언트다.
일반 구조:
[gNB server] ← [UE client]하지만 F1 handover tutorial에서는 이 역할을 뒤집는다.
F1 HO 구조:
[UE server] ← [DU0 client]
[UE server] ← [DU1 client]이렇게 하는 이유는 handover를 하려면 UE가 source cell과 target cell을 모두 볼 수 있어야 하기 때문이다.
UE가 DU0에서 DU1로 handover되려면, 마지막에는 target DU1에 Random Access를 해야 한다.
그러려면 UE와 DU1 사이에 실제 rfsim IQ 링크가 있어야 한다.
그래서 UE를 rfsim server로 만들고, DU0와 DU1이 같은 UE server에 접속하게 만든다.
이 구조에서는 UE 1개가 두 DU를 동시에 볼 수 있다.
따라서 단일 UE + 다중 Cell F1 handover 데모는 가능하다.
다중 UE·다중 Cell handover는 rfsim 구조상 불가능하다
그러나 우리가 궁극적으로 원하는 것은 단일 UE handover가 아니라, 다중 UE + 다중 Cell handover다.
예를 들어 UE 20개가 있고, 각 UE가 위치에 따라 DU0 또는 DU1의 신호를 다르게 받아야 한다.
[DU0]
↙ ↓ ↘
UE0 UE1 UE2 ... UE19
↖ ↑ ↗
[DU1]이 구조가 가능하려면 각 UE가 적어도 두 셀의 radio link를 동시에 볼 수 있어야 한다.
즉, UE0도 DU0/DU1을 봐야 하고, UE1도 DU0/DU1을 봐야 하고, UE19도 DU0/DU1을 봐야 한다.
하지만 OAI rfsim의 기본 토폴로지는 그렇게 되어 있지 않다.
현재 확인한 rfsim 모델의 핵심은 다음과 같다.
| 항목 | 동작 |
| server address | rfsimulator->ip에 단일 serveraddr 문자열 |
| role | SIMU_ROLE_SERVER 또는 SIMU_ROLE_CLIENT 중 하나 |
| server | listen() / accept()로 여러 client 수용 가능 |
| client | 하나의 server에만 접속 |
| --rfsimulator.[0] | 여러 link가 아니라 OAI config 배열 문법 |
즉, 서버는 여러 클라이언트를 받을 수 있지만 클라이언트는 서버 하나에만 붙을 수 있다.
이 제약 때문에 두 가지는 각각 가능하지만, 둘을 동시에 만족할 수 없다.
F1 handover든 N2 handover든 같은 문제가 발생한다
F1 handover가 어려우면 N2 handover로 우회할 수 있지 않을까 생각이 들어 N2 handover의 workflow를 살펴봤다.
F1 handover는 CU 내부 DU 간 handover다.
[DU0] ─┐
├── [CU] ── [AMF]
[DU1] ─┘N2 handover는 서로 다른 gNB 사이에서 AMF를 거치는 handover다.
[gNB-A] ── N2 ── [AMF] ── N2 ── [gNB-B]시그널링 경로는 다르지만 radio 관점에서는 마지막 요구사항이 동일하다.
UE가 target cell에 Random Access를 해야 한다.
handover command 수신
│
▼
target cell 동기화
│
▼
target gNB/DU에 RACH 수행
│
▼
handover complete즉, F1이든 N2든 Xn이든, handover가 실제로 완료되려면 UE와 target cell 사이에 radio link가 있어야 한다.
그리고 rfsim에서는 이 radio link가 socket 연결로 표현된다.
결국 문제는 다음 한 문장으로 요약된다.
Handover 방식이 F1이냐 N2냐가 문제가 아니라,
rfsim에서 UE 하나가 여러 cell radio link를 동시에 가질 수 없다는 것이 문제다.
따라서 N2 handover로 바꿔도 다중 UE·다중 Cell handover 문제는 해결되지 않는다.
현재 상황을 정리하면...
현재까지의 구현 상태는 다음과 같다.
| 단계 | 목표 | 상태 |
| 1 | 단일 gNB + 다중 UE | 구현 완료 |
| 2 | UE별 CIR 적용 | 구현 완료 |
| 3 | UE별 RSRP/KPI 관찰 | 구현 가능 |
| 4 | 단일 UE + 다중 DU F1 handover | 가능, 단 CU 크래시 수정 및 재빌드 필요 |
| 5 | Sionna 기반 A3 판단 + telnet F1 HO | 설계 가능 |
| 6 | 다중 UE + 다중 Cell handover | rfsim 구조상 불가능 |
| 7 | N2 handover 우회 | radio topology 문제 때문에 근본 해결 안 됨 |
그럼 앞으로 어떻게 해야 하나?
1. OAI proxy 또는 별도 multi-cell channel simulator를 사용한다
진짜로 다중 UE·다중 Cell handover를 구현하려면 rfsim의 socket topology를 벗어나야 한다.
필요한 것은 다음 구조다.
┌──────────────┐
[gNB0] ──▶│ │──▶ [UE0]
[gNB1] ──▶│ Channel │──▶ [UE1]
[gNB2] ──▶│ Proxy / │──▶ [UE2]
│ Simulator │──▶ ...
└──────────────┘즉, gNB와 UE가 직접 1:1 또는 1:N socket으로 붙는 것이 아니라, 중간에 channel proxy가 있어야 한다.
이 proxy는 다음 기능을 가져야 한다.
| 기능 | 설명 |
| multi-gNB 입력 | 여러 gNB/DU의 IQ stream 수신 |
| multi-UE 출력 | 여러 UE에게 각자 다른 합성 채널 전달 |
| cell별 channel 적용 | UE별, cell별 CIR 적용 |
| interference/RSRP 계산 | 각 UE 위치에서 여러 셀 신호 세기 계산 |
| RACH 경로 보장 | target cell handover 시 radio link 유지 |
이런 구조가 있어야 각 UE가 여러 셀을 동시에 볼 수 있다.
즉, handover 관점에서 필요한 것은 다음 행렬이다.
DU0 DU1 DU2
UE0 h00 h01 h02
UE1 h10 h11 h12
UE2 h20 h21 h22
...
UE19 h190 h191 h192현재 :per-ue는 사실상 다음만 처리한다.
gNB0
UE0 h00
UE1 h10
UE2 h20
...
UE19 h190즉, column이 하나뿐이다.
진짜 multi-cell handover를 하려면 UE × Cell 채널 행렬 전체를 처리해야 한다.
2. COTS UE와 실제 RF/감쇠기를 사용한다
또 다른 방법은 소프트웨어 RF simulator를 포기하고 실제 RF 환경으로 가는 것이다.
예를 들어 다음과 같은 구조다.
[gNB/DU0] ── RF ──┐
├── [COTS UE]
[gNB/DU1] ── RF ──┘또는 감쇠기와 RF combiner를 이용해 각 셀의 수신 세기를 조절할 수 있다.
이 방식은 실제 radio link가 존재하므로 UE가 여러 셀을 동시에 볼 수 있다. 따라서 handover 관점에서는 가장 자연스럽다.
하지만 하드웨어 비용, RF 설정, 동기화, 실험 재현성 문제가 추가된다.
정리하면...
현재 상황은 다음과 같이 정리할 수 있다.
첫째, 다중 UE·단일 Cell 환경은 이미 구현되어 있다.
OAI rfsim server가 여러 UE client를 받을 수 있고, Sionna-rk의 :per-ue 구조를 통해 각 UE에 독립적인 CIR을 적용할 수 있다. 따라서 20 UE 규모의 단일 셀 실험은 가능하다.
둘째, 단일 UE·다중 Cell F1 handover도 가능하다.
OAI tutorial처럼 UE를 rfsim server로 두고 DU0/DU1을 client로 붙이면, UE 하나가 두 DU를 동시에 볼 수 있다.
여기에 Sionna가 RSRP를 계산하고 telnet으로 ci trigger_f1_ho를 호출하면, measurement reporting이 없는 현재 OAI UE에서도 하이브리드 handover 실험이 가능하다.
셋째, 다중 UE·다중 Cell handover는 현재 rfsim 구조로는 불가능하다.
그 이유는 F1, N2, Xn 중 어떤 handover를 쓰느냐가 아니라,
rfsim의 radio topology가 client → server 1개 구조로 제한되어 있기 때문이다.
Handover가 완료되려면 UE가 target cell에 RACH를 수행해야 하고, 그러려면 UE와 target cell 사이에 실제 IQ link가 있어야 하지만 현재 rfsim 구조는 다수 UE가 다수 cell을 동시에 보는 구조를 만들 수 없다.
따라서 최종 결론은 다음과 같다.
Sionna-rk + OAI rfsim 환경에서는 “다중 UE·단일 Cell”과 “단일 UE·다중 Cell F1 handover”는 각각 가능하지만,
“다중 UE·다중 Cell handover”는 rfsim radio topology의 한계 때문에 불가능하다.
일단 20 UE handover를 구현해야 한다면,
OAI rfsim을 벗어나 multi-UE·multi-cell channel proxy 또는 실제 RF/COTS UE 기반 구조로 넘어가야 한다.
'RAN CN 테스트베드 구축 > Sionna RT-OAI (AI-RAN)' 카테고리의 다른 글
| Sionna-RK 기반 디지털 트윈 환경에서의 F1 Handover 구현 한계와 설계 방안 (0) | 2026.07.08 |
|---|---|
| Sionna-RK 패치를 통한 UE별 채널 기반 디지털트윈 AI-RAN 환경 구성 (0) | 2026.07.02 |
| Sionna-RK에서 UE별 위치 기반 CIR을 반영하기 위한 gNB 패치 과정 (0) | 2026.07.02 |
| Sionna RT와 OAI RF Simulator 연동 및 개선점 분석 (0) | 2026.07.01 |
| WSL2 환경에서 Sionna RT 연결을 위한 OAI RF 네트워크 스택 설치하기 (0) | 2026.06.24 |