Sionna-RK 기반 디지털 트윈 환경에서의 F1 Handover 구현 한계와 설계 방안

Handover 관점에서의 기존 Sionna-rk 환경의 한계

---

지금까지 UE별로 독립적인 CIR(Channel Impulse Response)을 갖도록 디지털 트윈 기반 무선 채널 환경을 구현하였다.

여기에 더 현실적인시나리오 구현을 위해서 캠퍼스 내의 Handover도 구현해야 한다.

따라서 디지털 트윈 환경에서 gNB를 1개 더 설치하고,
UE를 gNB2에서 gNB1 쪽으로 이동시켜가면서 Handover가 일어나는 것을 확인해야 한다.

 

 

구현 목표는 다음과 같다.

1. 디지털 트윈 환경에 gNB를 하나 더 추가한다.
2. UE를 gNB2 영역에서 gNB1 방향으로 이동시킨다.
3. UE 위치 변화에 따라 두 셀의 수신 신호 세기가 달라지는 것을 확인한다.
4. 특정 지점에서 핸드오버가 발생하는지 검증한다.

현재 시스템 구성은 다음과 같다.

• Sionna RT : 경희대 3D 씬에서 레이트레이싱을 수행하여 CIR을 계산한다.
• OAI : gNB PHY 역할을 수행한다. Sionna가 만든 CIR을 ZMQ로 전달받아 IQ 샘플에 적용한다.
• FlexRIC : E2 인터페이스를 통해 KPI를 수집한다.

핸드오버를 수행하기 위해서는 각 셀의 신호가 UE에 얼마나 강하게 도달하는가를 알아야 한다.

즉, 핸드오버를 구현하려면 셀별 RSRP(Reference Signal Received Power)를 계산할 수 있어야 한다.

 

 

 

기존 신호세기 관련 코드

---

telnet_channel.cir_to_channel_params() — 경로손실 계산 코드

 

첫 번째는 telnet_channel.cir_to_channel_params()이다.

# telnet_channel.py
if norm > 1e-10:
    path_loss_db = -20.0 * math.log10(norm)
else:
    path_loss_db = 120.0

rx_power_dbm = tx_power_dbm - path_loss_db

 

여기서 norm은 cir_generator._pack_cir()에서 만든 값이다.

# _pack_cir()
# 유효 경로 필터 → 진폭 상위 32탭(NUM_TAPS)만 유지
norm = float(np.sqrt(np.sum(np.abs(taps_padded) ** 2)))

 

즉, norm은 유효 경로 중 진폭이 큰 상위 32개 탭의 에너지 크기를 나타낸다.
이 값을 이용하면 대략적인 경로손실과 수신전력을 계산할 수 있다.

수식으로 보면 다음과 같다.

path_loss_db = -20 log10(norm)
rx_power_dbm = tx_power_dbm - path_loss_db

 

그러나 이 함수는 현재 실제 CIR 주입 경로에서 호출되지 않는다.
telnet chanmod 기반 경로는 공식 이미지에서 비활성화되어 있기 때문이다.

따라서 이 코드는 “경로손실을 계산할 수 있는 흔적”은 있지만,
현재 시스템에서 실제 채널 주입이나 핸드오버 판단에 사용되는 값은 아니다.

 

 

zmq_cir_channel.cir_to_sigma() — 실제 CIR 주입에 사용되는 코드

 

실제 CIR 주입에 사용되는 것은 zmq_cir_channel.cir_to_sigma() 쪽이다.

# zmq_cir_channel.py
sigma = (reference_norm / norm) * (10 ** (-target_snr_db / 20.0))

 

그리고 _pack_cir_zmq()에서는 CIR 탭을 norm으로 나누어 단위 에너지로 정규화한 뒤 전송한다.
즉, OAI로 전달되는 채널은 절대 크기를 가진 CIR이 아니라, 정규화된 CIR이다.

이를 수식으로 표현하면 다음과 같다.

ȳ[n] = Σ h̄s[l] · x[n - τ] + σ̄s · w[n]

h̄s = hs / ||hs||
σ̄s = min(σ_scaling / ||hs||, σ_max)

 

이 방식은 OAI 채널 에뮬레이터의 공식 설계와 일치하는데, 핵심은 “implicit perfect gain control”이다.

즉, 절대 수신전력 자체는 버리고, 채널 정규화와 노이즈 스케일링을 통해 SNR만 표현하는 구조다.
CIR 탭을 정규화하는 것 자체는 수학적으로 문제가 없고, SNR 관점에서는 올바른 설계다.

하지만 이 방식은 핸드오버 관점에서는 문제가 된다.

 

 

왜 기존 SNR 기반 구조는 핸드오버에 부적합한가

---

zmq_cir_channel.py에 있는 cir_to_sigma()의 SNR 관계를 풀어보면 다음과 같다.

SNR_dB = target_snr_db - 20 log10(reference_norm / norm)

 

이는 매 루프 스텝마다 그 시점의 UE 집합 중 최대 norm으로 다시 계산된다.

앞서 Per-UE CIR을 만들어도 이 reference_norm 산출 로직 자체는 그대로 남아있어서, 결국 cir_to_sigma()에 들어가는 SNR_dB = target_snr_db - 20·log10(reference_norm/norm)는 여전히 "그 순간 가장 센 UE" 기준 상대값이다.

 

즉 기본 동작에서는 매 스텝마다 현재 UE들 중 가장 큰 norm을 reference_norm으로 사용하므로,
그 순간 가장 좋은 채널을 가진 UE가 기준점이 된다.

 

이 구조에서는 다음과 같은 현상이 발생한다.

• UE 간 상대적인 경로손실 차이는 반영된다.
• 하지만 절대 수신 레벨은 고정된 기준을 갖지 못하고 계속 변한다.
• 매 순간 가장 강한 UE는 위치와 무관하게 항상 target_snr_db 근처로 정규화된다.
• 따라서 UE가 실제로 멀어져도 신호가 약해지는 효과가 제대로 표현되지 않을 수 있다.
• 기준이 “현재 가장 센 UE”이므로 시간, 위치, 셀에 걸친 공통 기준이 없다.

핸드오버 판단에서 중요한 것은 두 셀의 RSRP가 어떻게 변하고, 어느 지점에서 교차하는가이다.

예를 들어 UE가 gNB2에서 출발해 gNB1 방향으로 이동한다면, 이상적인 흐름은 다음과 같아야 한다.

초기 위치:  RSRP_gNB2 > RSRP_gNB1
중간 지점:  RSRP_gNB2 ≈ RSRP_gNB1
gNB1 근처: RSRP_gNB1 > RSRP_gNB2

 

이 교차점이 핸드오버 판단의 핵심이지만, 현재 구조처럼 매 스텝 기준이 다시 잡히고,
절대 수신전력이 사라진 상태에서는 두 셀의 RSRP를 공통 기준에서 비교하기 어렵다.
결과적으로 “언제 핸드오버가 발생해야 하는가”를 판단할 수 있는 물리적인 기준이 부족하다.

 

 

 

N2 / Xn / F1 핸드오버 관점에서 본 Sionna-rk OAI 구현 완성도

---

Sionna-rk에서 캠퍼스 디지털 트윈 기반 핸드오버를 구현하기 위해 먼저 확인할 부분은,
바로 현재 포함되어 있는 OAI 소스가 어떤 종류의 핸드오버를 실제로 지원하는가이다.

 

Sionna-rk는 Openairinterface5G의 2025.w34 branch를 사용하는데, sionna-rk/ext/openairinterface5g 내부의 OAI 소스를 직접 확인해보면 OAI 코드베이스 안에는 F1, N2, Xn 핸드오버와 관련된 흔적이 모두 존재한다.

그러나 특별한 패치 없이 현재 sionna-rk 환경에서 실제로 검증 가능한 경로는 F1 핸드오버뿐이다.

N2, Xn 핸드오버는 최신 branch에는 구현되어 있지만 2025년 34주차 기준으로는 F1 Handover만 구현된 것.

 

 

UE가 자신의 신호세기를 측정해서 보고하는지 여부

---

RSRP의 경우 기존 OAI에 측정 처리 코드는 있지만, 측정 "생성" 코드가 없다.

gNB(CU) 쪽의 `rrc_gNB.c:1396-1440`에 UE가 보낸 MeasurementReport에서 서빙셀/이웃셀 RSRP를 3GPP 매핑 공식(rsrp - 157)으로 뽑아내는 코드가 있다. 즉 RRC 계층 RSRP를 소비하는 코드는 존재한다.

 

그러나 sionna-rk의 OAI branch 기준으로는 UE가 실제 신호 세기를 측정해서 보고하는 경로가 아직 미완성인 상태이다.

하지만  sionna-rk/ext/openairinterface5g/doc/handover-tutorial.md를 살펴보면, RF-simulator에서 간단한 Handover 테스트가 가능하다고 되어 있는데, 이는 CU에 수동으로 handover 명령을 넣는 forced/manual handover 테스트로 이루어진다.

 

즉, 보통 실제 NR Handover는 UE가 주변 셀을 측정해서,

1. serving cell보다 neighbor cell이 좋아짐
2. UE가 Measurement Report 전송
3. CU/gNB가 handover 결정
4. UE를 target cell로 이동시킴

과 같은 흐름으로 이어진다.

 

하지만 현재 branch에서는 OAI UE가 measurement reporting을 지원하지 않기 때문에 UE가 스스로 handover를 트리거하지 못하기 때문에 telnet으로 CU에 직접 명령을 보내 수동으로 handover를 트리거하는 식으로 이루어진다.

 

 

 

Handover 구현 방안

---

따라서 현재 Sionna Ray Tracing 환경과 OAI 상황에서 무선 환경에 따라 HO가 실제로 일어나는 상황을 구현하기 위해서는,

우선 현재 하나의 Monolithic gNB로 구현된 oai-gnb 하나를 CU + DU0 + DU1 구조로 쪼개야 한다. (F1 Handover를 위해)

 

F1 connects the gNB-CU and gNB-DU inside a split gNB. F1-C carries F1AP control signaling, while F1-U carries user-plane transport.

 

 

 

구체적인 F1 Handover 과정 

---

F1 핸드오버는 실제로 다음과 같이 이루어진다.

[UE] ── Uu (RRC) ──> [DU0] ──F1AP──> [CU] <──F1AP── [DU1]
                                        │
                                     [AMF] (N2, 변경 없음 — CU가 그대로 유지)

 

1. 측정 설정
   CU가 neighbour-config.conf(A2/A3 이벤트 설정)를 로드하고, RRCReconfiguration으로 UE에 measConfig(measObject, reportConfig=eventA3, measId)를 내려보냄 (rrc_gNB.c:491-561이 이 A1/A2/A3 reportConfig를 실제로 생성).
   
   
2. 측정 보고
   정상 시나리오라면 UE가 이웃 셀(DU1)이 서빙셀(DU0)보다 offset+hysteresis만큼 강해지면 UL로 MeasurementReport를 보냄 — (단, 위에서 확인했듯 OAI rfsim UE는 이 단계를 아예 못 함.)
   
   
3. HO 판정
   CU가 rrc_gNB_process_MeasurementReport → process_Event_Based_Measurement_Report(rrc_gNB.c:1369)에서 eventA3를 확인, 이웃 셀이 F1로 연결된 DU(같은 CU 산하)면 nr_rrc_trigger_f1_ho(rrc, ue, source_du, target_du) 호출.
   
   
4. HO 실행
   타겟 DU(DU1)에 F1AP UE Context Setup → RRCReconfiguration(mobilityControlInfo 포함, rrc_gNB_trigger_reconfiguration_for_handover)을 UE에 전달 → UE가 타겟 DU에 랜덤 액세스 → nr_rrc_f1_ho_complete에서 완료 처리, 소스 DU(DU0)의 UE 컨텍스트 해제.

 

CU가 그대로 유지되므로 N2(AMF)나 Xn 인터페이스는 전혀 관여하지 않는다.

 

 

구현 방안

---

구현 단계에서는 UE Measurement Report 부분을 대체하기 위해 별도의 UE별 Cell RSRP를 계산하는 로직을 만들어서 RSRP 차이가 A3 조건을 넘으면 스크립트가 Telnet으로 citrigger_f1_ho를 쏘는 식으로, "Sionna가 측정을 대행하고 OAI가 HO를 실행"하는 하이브리드 구조가 가장 합리적인 상황이다.

 

UE가 측정보고를 못 하므로, Telnet을 활용해서 3번(HO 판정)을 강제 트리거하는 방식!

echo ci trigger_f1_ho | nc 127.0.0.1 9090

 

이는 common/utils/telnetsrv/telnetsrv_ci.c:194가 nr_HO_F1_trigger_telnet()을 호출하는 구조이다.