OAI에 Free5GC Core 연결하기
개요
OpenAirInterface(OAI) 5G RAN은 기본적으로 OAI-CN5G 코어와 연동되도록 설정되어 있다.
기본 구성에서는 OAI-CN5G의 모든 컴포넌트가 같은 docker 네트워크(192.168.70.128/26) 위에서 동작하며,
gNB가 192.168.70.132의 OAI AMF에 SCTP로 연결하는 구조다.
여기에서는 OAI-CN5G를 완전히 내리고, VMware (192.168.200.100, host-only network) 내에서 돌아가는 docker-compose로 실행 중인 free5GC v4.2.2를 코어 네트워크로 사용하는 것이다.
[VMware VM: OAI gNB 192.168.200.128] [VMware VM: free5GC 192.168.200.100]
| |
| 192.168.200.128 (host-only) | 192.168.200.100 (host-only)
| |
OAI gNB ──── SCTP (N2) ──────────────────> AMF (port 38412, forwarded)
──── GTP-U (N3) ──────────────────> UPF (port 2152/udp, forwarded)
|
docker bridge: 10.100.200.0/24
(AMF: 10.100.200.21, UPF: 10.100.200.11)
(NRF, SMF, UDM, AUSF, UDR, PCF 등)
주요 구성 요소
- OAI gNB VM (192.168.200.128): OAI gNB와 UE가 실행되는 VM
- UE는 network namespace ue1 내에서 실행
- N2 인터페이스로 AMF와 NGAP 통신
- N3 인터페이스로 UPF와 GTP-U 터널 통신
- free5GC VM (192.168.200.100): docker-compose로 free5GC v4.2.2 실행
- Docker 내부 네트워크: 10.100.200.0/24
- AMF는 SCTP 포트 38412를 호스트로 포워딩
- UPF는 GTP-U 포트 2152/udp를 호스트로 포워딩
- 핵심 설정 포인트
- AMF 설정: N2 인터페이스를 외부에서 접근 가능하도록 SCTP 포트 포워딩
- UPF 설정:
- N3 인터페이스를 0.0.0.0으로 바인딩하여 모든 인터페이스에서 수신
- GTP-U 포트 2152/udp를 호스트로 포워딩
- NAT 설정으로 UE 트래픽을 인터넷으로 라우팅
- SMF 설정: UPF의 N3 endpoint를 **호스트 IP (192.168.200.100)**로 설정 (Docker 내부 IP가 아님)
**Note**
| 시도 | 구성 | 실패 원인 | 판단 |
| 1 | OAI = WSL, free5GC = VirtualBox VM |
WSL 네트워크/커널 특성상 SCTP, gNB 쪽 커널 네트워크 요구사항 처리에 제약 | 비추천 |
| 2 | OAI = VirtualBox VM, free5GC = VirtualBox VM |
VirtualBox 환경에서 OAI가 요구하는 CPU 가상화 기능, 특히 AVX 계열 지원 문제 발생 가능 | OAI 구동 불안정 |
| 3 | OAI = VMware VM, free5GC = VirtualBox VM |
VMware Host-only와 VirtualBox Host-only는 서로 다른 가상 스위치라 직접 통신 불가 | 네트워크 연결 복잡 |
| 4 | OAI = VMware VM, free5GC = VMware VM |
같은 VMware VMnet을 공유 가능. NAT + Host-only 구성이 깔끔함 | 추천 |
OAI 쪽 수정해야 되는 파일 -
/home/user/openairinterface5g/targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf
1-1. PLMN 변경 (MCC/MNC)
# 변경 전
plmn_list = ({ mcc = 001; mnc = 01; mnc_length = 2; ...
# 변경 후
plmn_list = ({ mcc = 208; mnc = 93; mnc_length = 2; ...
OAI-CN5G 기본 PLMN은 001/01이지만, free5GC 기본 PLMN은 208/93이다.
gNB가 AMF에 NGAP Setup Request를 보낼 때 PLMN 정보가 포함되는데,
AMF의 plmnSupportList와 일치하지 않으면 Setup Failure로 거부된다.
이때 gNB에 3개의 Network Slice가 정의한다.
snssaiList = ({ sst = 1; sd = 0x000001}, { sst = 2; sd = 0x000002; }, { sst = 3; sd = 0x000003; })
이 값을 기준으로 free5GC 쪽으로 맞춰야 한다.
1-2. AMF IP 주소 변경
# 변경 전
amf_ip_address = ({ ipv4 = "192.168.70.132"; });
# 변경 후
amf_ip_address = ({ ipv4 = "192.168.200.100"; });
OAI-CN5G AMF는 docker 네트워크 192.168.70.132에 있었지만,
이제 free5GC AMF가 VM의 host-only IP 192.168.56.100에서 SCTP를 listen한다.
gNB는 이 주소로 SCTP 연결을 시도한다.
1-3. gNB 네트워크 인터페이스 변경
# 변경 전
GNB_IPV4_ADDRESS_FOR_NG_AMF = "192.168.70.129/24";
GNB_IPV4_ADDRESS_FOR_NGU = "192.168.70.129/24";
# 변경 후
GNB_IPV4_ADDRESS_FOR_NG_AMF = "192.168.200.128/24";
GNB_IPV4_ADDRESS_FOR_NGU = "192.168.200.128/24";
GNB_IPV4_ADDRESS_FOR_NG_AMF: gNB가 AMF와 SCTP(N2) 통신할 때 사용하는 자신의 IP이다.
gNB가 위치한 VM의 IP인 192.168.200.128로 설정한다.
GNB_IPV4_ADDRESS_FOR_NGU: gNB가 UPF와 GTP-U(N3) 통신할 때 사용하는 자신의 IP이다.
같은 인터페이스를 사용하므로 동일하게 설정한다.
Free5GC 쪽 수정해야 되는 파일
free5GC는 free5gc-compose 디렉토리에서 docker-compose로 실행된다. 외부 OAI gNB와 연동하기 위해서는 AMF, UPF, SMF 설정을 수정해야 한다.
1. docker-compose.yaml 수정
- UERANSIM 비활성화
기본 구성에 포함된 UERANSIM 컨테이너는 사용하지 않으므로 주석 처리한다.
# ueransim:
# container_name: ueransim
# image: free5gc/ueransim:latest
# command: ./nr-gnb -c ./config/gnbcfg.yaml
# volumes:
# - ./config/gnbcfg.yaml:/ueransim/config/gnbcfg.yaml
# - ./config/uecfg.yaml:/ueransim/config/uecfg.yaml
# cap_add:
# - NET_ADMIN
# devices:
# - "/dev/net/tun"
# networks:
# privnet:
# aliases:
# - gnb.free5gc.org
# depends_on:
# - free5gc-amf
# - free5gc-upf
- AMF 포트 포워딩 설정
AMF는 N2 인터페이스(SCTP)를 통해 외부 gNB와 통신한다. 기본 설정에 이미 포트 포워딩이 되어 있지만, 확인이 필요하다.
free5gc-amf:
container_name: amf
image: free5gc/amf:v4.2.2
command: ./amf -c ./config/amfcfg.yaml
volumes:
- ./config/amfcfg.yaml:/free5gc/config/amfcfg.yaml
- ./cert:/free5gc/cert
environment:
GIN_MODE: release
ports:
- "38412:38412/sctp" # ← N2 인터페이스 (NGAP over SCTP)
- "8000:8000"
- "9091:9091"
networks:
privnet:
ipv4_address: 10.100.200.21
aliases:
- amf.free5gc.org
depends_on:
- free5gc-nrf
- 설명:
- 38412:38412/sctp: 호스트의 38412 포트를 컨테이너의 38412 포트로 포워딩
- 외부 gNB는 192.168.200.100:38412로 연결하면 Docker 내부의 AMF(10.100.200.21:38412)에 도달
- UPF 포트 포워딩 설정
# docker-compose.yaml
services:
free5gc-upf:
container_name: upf
image: free5gc/upf:v4.2.2
command: bash -c "./upf-iptables.sh && ./upf -c ./config/upfcfg.yaml"
volumes:
- ./config/upfcfg.yaml:/free5gc/config/upfcfg.yaml
- ./config/upf-iptables.sh:/free5gc/upf-iptables.sh
cap_add:
- NET_ADMIN
ports:
- "2152:2152/udp" # ← N3 인터페이스 (GTP-U)
networks:
privnet:
ipv4_address: 10.100.200.11 # 고정 IP 할당
aliases:
- upf.free5gc.org
- 2152:2152/udp: 호스트의 2152 포트를 컨테이너의 2152 포트로 포워딩
- 외부 gNB는 192.168.200.100:2152로 GTP-U 패킷을 전송하면 Docker 내부의 UPF(10.100.200.11:2152)에 도달
- cap_add: NET_ADMIN: UPF가 네트워크 설정(라우팅, iptables 등)을 변경할 수 있도록 권한 부여
- Docker Network 설정
# docker-compose.yaml
networks:
privnet:
ipam:
driver: default
config:
- subnet: 10.100.200.0/24
driver_opts:
com.docker.network.bridge.name: br-free5gc
- Docker bridge 네트워크 privnet을 10.100.200.0/24 대역으로 생성
- 브리지 이름을 br-free5gc로 지정하여 호스트에서 식별 가능
- NF 고정 IP 할당
Docker bridge 네트워크에서 IP를 고정하지 않으면 컨테이너를 재시작할 때마다 IP가 바뀔 수 있다.
모든 주요 NF에 고정 IP를 할당하여 안정적인 통신을 보장한다.
# docker-compose.yaml
services:
free5gc-nrf:
networks:
privnet:
ipv4_address: 10.100.200.10 # 고정 IP
aliases:
- nrf.free5gc.org
free5gc-amf:
networks:
privnet:
ipv4_address: 10.100.200.21 # 고정 IP
aliases:
- amf.free5gc.org
free5gc-upf:
networks:
privnet:
ipv4_address: 10.100.200.11 # 고정 IP
aliases:
- upf.free5gc.org
free5gc-smf:
networks:
privnet:
ipv4_address: 10.100.200.15 # 고정 IP
aliases:
- smf.free5gc.org
# 다른 NF들도 동일하게 고정 IP 할당
free5gc-ausf:
networks:
privnet:
ipv4_address: 10.100.200.12
aliases:
- ausf.free5gc.org
free5gc-nssf:
networks:
privnet:
ipv4_address: 10.100.200.13
aliases:
- nssf.free5gc.org
free5gc-pcf:
networks:
privnet:
ipv4_address: 10.100.200.14
aliases:
- pcf.free5gc.org
free5gc-udm:
networks:
privnet:
ipv4_address: 10.100.200.16
aliases:
- udm.free5gc.org
free5gc-udr:
networks:
privnet:
ipv4_address: 10.100.200.17
aliases:
- udr.free5gc.org
- Docker bridge 네트워크 내에서 각 NF에 고정 IP를 할당
- aliases로 Docker 내부 DNS 이름을 설정하여 *.free5gc.org로 서로 통신 가능
- network_mode: host나 /etc/hosts 수정은 필요 없음
- Docker의 내장 DNS가 자동으로 alias를 resolve하여 NF 간 통신 처리
2. config/amfcfg.yaml 수정
- ngapIpList 변경
# config/amfcfg.yaml
configuration:
amfName: AMF
ngapIpList: # AMF가 SCTP를 listen할 IP 주소
- 10.100.200.21 # Docker 내부 고정 IP
ngapPort: 38412
- ngapIpList는 AMF가 SCTP 소켓을 bind(listen)할 IP 주소이다
- Docker bridge 네트워크에서 AMF의 고정 IP인 10.100.200.21을 사용한다
- 외부 gNB는 192.168.200.100:38412로 연결하면, 포트 포워딩을 통해 Docker 내부의 AMF(10.100.200.21:38412)에 도달한다
2-2. SBI 설정 변경
# config/amfcfg.yaml
configuration:
sbi:
scheme: http
registerIPv4: 10.100.200.21 # NRF에 등록할 IP
bindingIPv4: 0.0.0.0 # 모든 인터페이스에서 listen
port: 8000
- registerIPv4: AMF가 NRF에 자신을 등록할 때 사용하는 IP
- NRF는 Docker bridge 네트워크(10.100.200.0/24)에 있으므로 AMF의 Docker 고정 IP를 사용
- bindingIPv4: SBI HTTP 서버를 bind할 IP
- 0.0.0.0으로 설정하면 모든 인터페이스에서 listen하여 Docker 내부 NF들과 통신 가능
2-3. snssaiList 변경
# config/amfcfg.yaml
configuration:
plmnSupportList:
- plmnId:
mcc: 208
mnc: 93
snssaiList:
- sst: 1
sd: 000001
- sst: 2
sd: 000002
- sst: 3
sd: 000003
gNB에서 정의한 3개 슬라이스와 정확히 일치시킨다.
AMF는 gNB의 NGAP Setup Request에 포함된 슬라이스 정보를 자신의 plmnSupportList.snssaiList와 비교하여,
하나도 매칭되지 않으면 Setup Failure를 응답한다.
Free5GC 쪽 수정해야 되는 파일 - config/smfcfg.yaml
3-1. snssaiInfos 변경
# config/smfcfg.yaml
configuration:
snssaiInfos:
- sNssai:
sst: 1
sd: 000001
dnnInfos:
- dnn: internet
dns:
ipv4: 8.8.8.8
ipv6: 2001:4860:4860::8888
- sNssai:
sst: 2
sd: 000002
dnnInfos:
- dnn: internet
dns:
ipv4: 8.8.8.8
ipv6: 2001:4860:4860::8888
- sNssai:
sst: 3
sd: 000003
dnnInfos:
- dnn: internet
dns:
ipv4: 8.8.8.8
ipv6: 2001:4860:4860::8888
- SMF가 지원하는 슬라이스 목록을 gNB/AMF와 동일하게 맞춘다.
- UE가 PDU Session 수립을 요청할 때 AMF가 SMF를 선택하는데, 이때 SMF의 snssaiInfos에 해당 S-NSSAI가 없으면 PDU Session 수립이 실패한다.
- DNS 설정도 각 슬라이스별로 지정 가능.
3-2. sNssaiUpfInfos 변경
sNssaiUpfInfos:
- sNssai:
sst: 1
sd: 000003
dnnUpfInfoList:
- dnn: internet
pools:
- cidr: 10.60.0.0/16
staticPools:
- cidr: 10.60.100.0/24
- sNssai:
sst: 2
sd: 000001
dnnUpfInfoList:
- dnn: internet
pools:
- cidr: 10.61.0.0/16
staticPools:
- cidr: 10.61.100.0/24
- sNssai:
sst: 3
sd: 000002
dnnUpfInfoList:
- dnn: internet
pools:
- cidr: 10.62.0.0/16
staticPools:
- cidr: 10.62.100.0/24
각 슬라이스별로 UE에 할당할 IP 풀을 분리한다. Slice 1은 10.60.0.0/16, Slice 2는 10.61.0.0/16, Slice 3은 10.62.0.0/16 대역을 사용한다.
SMF는 PDU Session 수립 시 해당 슬라이스의 IP 풀에서 UE에 IP를 할당하고, UPF에 PFCP Session Establishment Request를 보내 포워딩 룰을 설치한다.
3개째 슬라이스(10.62.0.0/16)는 free5GC 기본 설정에 없던 대역이므로, UPF의 dnnList에도 추가해야 한다
(upfcfg.yaml에서 처리).
3-3. UPF N3 Endpoint 설정
외부 gNB가 UPF와 GTP-U 터널을 생성하려면, SMF가 gNB에게 호스트 IP를 알려줘야 한다.
# config/smfcfg.yaml
configuration:
userplaneInformation:
upNodes:
UPF:
type: UPF
nodeID: upf.free5gc.org
addr: upf.free5gc.org # N4 (PFCP) 주소
interfaces:
- interfaceType: N3
endpoints:
- 192.168.200.100 # ← 호스트 IP (외부에서 접근 가능)
networkInstances:
- internet
- endpoints를 upf.free5gc.org (Docker 내부 IP 10.100.200.11)로 설정하면 외부 gNB가 접근할 수 없다
- 반드시 호스트 IP 192.168.200.100으로 설정해야 한다
- SMF는 PDU 세션 생성 시 이 주소를 gNB에게 전달하고, gNB는 이 주소로 GTP-U 터널을 생성한다
Free5GC 쪽 수정해야 되는 파일 - config/upfcfg.yaml
4-1. dnnList에 세 번째 슬라이스 IP 풀 추가
# config/upfcfg.yaml
dnnList:
- dnn: internet
cidr: 10.60.0.0/16
natifname: eth0 # NAT 인터페이스
- dnn: internet
cidr: 10.61.0.0/16
natifname: eth0
- dnn: internet
cidr: 10.62.0.0/16
natifname: eth0
- natifname: eth0: UE 트래픽을 외부 인터넷으로 NAT하기 위한 인터페이스
- UPF 컨테이너의 eth0는 Docker bridge에 연결되어 있으며, 호스트를 통해 인터넷에 접근
4-2. GTP-U 인터페이스 설정
# config/upfcfg.yaml
gtpu:
forwarder: gtp5g
ifList:
- addr: 0.0.0.0 # 모든 인터페이스에서 listen
type: N3
- addr: 0.0.0.0: UPF가 모든 인터페이스에서 GTP-U 패킷을 수신하도록 설정
- 포트 포워딩으로 들어오는 패킷을 받을 수 있도록 함
5. WebUI에 Subscriber 등록!
192.168.200.100:5000으로 접속 (ID: admin, PW: free5gc)
여기 Subscriber에 IMSI, OPc Key, ST, SSD 등을 정확하게 기입한다.
출력되는 Log 분석
먼저 Free5GC의 NF를 Build한다.
cd ~/free5gc-compose
docker compose up -d
다음으로 gNB를 빌드한다.
cd ~/openairinterface5g/cmake_targets/ran_build/build
sudo ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210.conf --gNBs.[0].min_rxtxtime 6 --rfsim
로그는 다음과 같다.
# gNB 실행 시작
./nr-softmodem ... --rfsim
# SA 모드 정상 기동
[UTIL] running in SA mode
# 설정 파일 로딩 / 셀 설정 완료
[RRC] Read in ServingCellConfigCommon ...
[NR_RRC] cell PLMN 208.93 Cell ID 12345678 is in service
# AMF 연결 성공
[GNB_APP] Parsed IPv4 address for NG AMF: 192.168.200.128
[NGAP] Send NGSetupRequest to AMF
[NGAP] Received NGSetupResponse from AMF
# F1(CU/DU) 연결 성공
[NR_RRC] Received F1 Setup Request ...
[NR_RRC] Accepting DU ... sending F1 Setup Response
[MAC] received F1 Setup Response from CU
# RFSIM 대기중 (UE 아직 안 붙음)
[HW] Running as server waiting opposite rfsimulators to connect
[HW] No connected device, generating void samples...
gNB + AMF + Cell 서비스는 정상.
UE(rfsim client)는 아직 미접속.
다음으로 ue1.conf 파일을 실행한다.
cd ~/openairinterface5g/tools/scripts
sudo ./multi-ue.sh -c1
sudo ./multi-ue.sh -o1
sudo ip netns exec ue1 /home/user/openairinterface5g/cmake_targets/ran_build/build/nr-uesoftmodem \
-O /home/user/openairinterface5g/targets/PROJECTS/GENERIC-NR-5GC/CONF/ue1.conf \
-r 106 \
--numerology 1 \
--band 78 \
-C 3619200000 \
--rfsim \
--uicc0.imsi 208930000000001 \
--rfsimulator.serveraddr 10.201.1.100 \
--telnetsrv \
--telnetsrv.listenport 9095
UE 측의 로그는 다음과 같다.
# UE측 로그
nr-uesoftmodem ... --rfsim --uicc0.imsi 208930000000001 --rfsimulator.serveraddr 10.201.1.100
# rfsim gNB 연결 성공
[HW] Trying to connect to 10.201.1.100:4043
[HW] Connection to 10.201.1.100:4043 established
# 셀 탐색/동기화 성공
[PHY] Initial sync: pbch decoded sucessfully
[PHY] Initial sync successful, PCI: 0
[PHY] UE synchronized!
# SIB1 수신 성공
[NR_RRC] SIB1 decoded
# Random Access 성공
[MAC] Initialization of 4-Step CBRA procedure
[PHY] PRACH [UE 0] ...
[PHY] [UE 0] RAR-Msg2 decoded
[NR_MAC] Found RAR with the intended RAPID 28
[NR_MAC] RA-Msg3 transmitted
[MAC] 4-Step RA procedure succeeded. CBRA: Contention Resolution is successful.
# RRC 연결 성공
[NR_RRC] Received NR_RRCSetup
[NR_RRC] State = NR_RRC_CONNECTED
[NR_RRC] Generating RRCSetupComplete
# NAS Registration 시작
[NAS] Generate Initial NAS Message: Registration Request
[NAS] Received NR_NAS_CONN_ESTABLISH_IND
# 무선 품질
[NR_PHY] [UE 0] RSRP = -42 dBm
rfsim 연결 성공 → PBCH 디코딩 성공 → UE 동기화 성공 → SIB1 수신 성공 → PRACH/RAR/Msg3/Msg4 Random Access 성공 → RRC_CONNECTED 진입 → NAS Registration Request 생성
다음은 gNB 측의 로그이다.
# Random Access 시작
[NR_PHY] Initiating RA procedure with preamble 28
[NR_MAC] UE RA-RNTI 0113 TC-RNTI 8fd2: initiating RA procedure
# Msg2(RAR) 전송 / Msg3 수신
[NR_MAC] Send RAR to RA-RNTI 0113
[NR_MAC] PUSCH with TC_RNTI 0x8fd2 received correctly
# UE 컨텍스트 생성
[NR_RRC] Create UE context: UE ID 1 RNTI 8fd2
# Msg4 / RA 완료
[NR_RRC] Send RRC Setup
[NR_MAC] Received Ack of Msg4. CBRA procedure succeeded (UE Connected)
# RRC 연결 완료
[NR_RRC] Received RRCSetupComplete (RRC_CONNECTED reached)
# NAS Registration 절차
[NGAP] Selected PLMN MCC 208 MNC 93
[NGAP] Create UE context (ID 1) for AMF
# 보안 절차 완료
[NR_RRC] Selected security algorithms: ciphering 0, integrity 2
[NR_RRC] Generate SecurityModeCommand
[NR_RRC] Received Security Mode Complete
# UE Capability 완료
[NR_RRC] Generate NR UECapabilityEnquiry
[NR_RRC] Received UE capabilities
# Initial Context Setup 완료
[NR_RRC] Send message to sctp: NGAP_InitialContextSetupResponse
# PDU Session 생성 시작
[NGAP] PDUSESSIONSetup initiating message
[NR_RRC] received PDU Session Resource Setup Request
# GTP 터널 생성
[GTPU] Create tunnel ... outgoing 2 to remote IPv4 192.168.200.100
# DRB 생성 / RRC 재설정
[PDCP] added drb 1 to UE ID 1
[RLC] Added drb 1 to UE 36818
[NR_RRC] Generate RRCReconfiguration
# PDU Session 최종 성공
[NR_RRC] Received RRCReconfigurationComplete
[NR_RRC] PDU Session Setup Response: ID=10
[NGAP] Encoded PDU Session Transfer (10)
# 링크 품질
UE RNTI 8fd2 in-sync average RSRP -44
ulsch_errors 0
dlsch_errors 0
이 로그는 gNB 입장에서 UE 접속이 완전히 성공한 상태이다.
UE가 PRACH preamble 28로 접속 요청했고, Msg1 → Msg2(RAR) → Msg3 → Msg4 ACK 까지 완료되었다.
즉 UE가 셀에 정상 Attach 시작!
이후 RRC 연결 성공으로 UE는 idle 상태를 벗어나 gNB와 제어 연결 완료.
InitialContextSetupResponse로, UE ↔ AMF Registration 정상 완료된 후,
PDU Session ID = 10, Create tunnel, DRB 1 생성로 UE에 IP 데이터 세션 생성 완료 후 GTP-U 터널까지 연결된다.
이 과정에서 AMF측 로그는 다음과 같다.
# gNB NG 연결 수립
Create a new NG connection for: 192.168.200.128:33975
Handle NGSetupRequest
Send NG-Setup response
# UE 최초 접속 / Registration 시작
Handle InitialUEMessage
New RanUe [RanUeNgapID:1][AmfUeNgapID:1]
Handle Registration Request
RegistrationType: Initial Registration
# 가입자 식별
5GSMobileIdentity SUCI ...
New AmfUe ...
supi: imsi-208930000000001
# 인증 절차 성공
Authentication procedure
Send Authentication Request
Handle Authentication Response
# 보안 절차 성공
Send Security Mode Command
Handle Security Mode Complete
# 등록 완료
Handle InitialRegistration
Send Registration Accept
Send Initial Context Setup Request
Handle InitialContextSetupResponse
Handle Registration Complete
# UE 상태 Registered 진입
transition from [ContextSetup] to [Registered]
# PDU Session 생성 요청
Handle UL NAS Transport
Transport 5GSM Message to SMF
Select SMF ... dnn: internet
create smContext[pduSessionID: 10] Success
# gNB로 세션 설정 전달
Send PDU Session Resource Setup Request
Handle PDUSessionResourceSetupResponse
이 AMF 로그는 5GC 코어망 관점에서 UE 등록과 데이터 세션 생성이 완전히 성공했다는 뜻이다.
SMF 로그는 다음과 같다.
# SMF 기동
Start SBI server (listen on smf.free5gc.org:8000)
PFCP Listen on 10.100.200.15:8805
# SMF ↔ UPF PFCP 연결 성공
Sending PFCP Association Request to UPF 10.100.200.11
Received PFCP Association Setup Accepted Response
UPF(10.100.200.11) setup association
# UE PDU Session 요청 수신
Receive Create SM Context Request
HandlePDUSessionEstablishmentRequest
supi: imsi-208930000000001
pdu_session_id: 10
# UE IP 할당
Allocated UE IP address: 10.60.0.1
Selected UPF: UPF
Allocated PDUAdress[10.60.0.1]
# 정책/과금 관련 경고
BSF selection failed: no BSF instances found
chf selection error: no CHF found
# PCC Rule 설치
Install PCCRule[PccRuleId-1]
Install PCCRule[PccRuleId-2]
# UPF에 PFCP 세션 생성 성공
Sending PFCP Session Establishment Request
Received PFCP Session Establishment Accepted Response
# SM Context 생성 성공
POST /nsmf-pdusession/v1/sm-contexts | 201
# gNB 응답 이후 PFCP 세션 수정 성공
Receive Update SM Context Request
Received PFCP Session Modification Accepted Response from AN UPF
POST /modify | 200
# 이후 반복 로그
No report need to be charged
SMF 기동 후 → UPF와 PFCP Association 성공 → UE PDU Session 요청 수신 → UE IP 10.60.0.1 할당 → UPF 선택 → PFCP Session Establishment 성공 → SM Context 생성 성공 → PFCP Session Modification 성공의 순이다.
이후 UE 1에서 8.8.8.8로 Ping을 보내면..
# ue1 네임스페이스 존재 확인
sudo ip netns list
#ue ip주소 확인
sudo ip netns exec ue1 ip route
# ue1 단말의 모든 외부 트래픽은 5G 인터페이스(oaitun_ue1)로 보내라
sudo ip netns exec ue1 ip route add default dev oaitun_ue1
# UE 단말(namespace ue1) 안에서 Google DNS 서버(8.8.8.8)로 ping
sudo ip netns exec ue1 ping -c 4 8.8.8.8
위 명령은 UE1이 Google DNS 서버까지 도달 가능한지 테스트하는 것으로,
최종 경로는 UE1 → gNB → AMF/SMF/UPF → NAT → Internet → 8.8.8.8가 된다.
이를 통해 5G SA 전체망이 정상 동작함을 확인할 수 있다.
WebUI에서도 imsi-208930000000001 사용자가 제대로 Connected됨을 확인할 수 있다!
'RAN CN 테스트베드 구축 > OAI+Free5GC (RAN-Core)' 카테고리의 다른 글
| 5G Network Slicing QoS 실험을 위한 Multi-UE 환경 구축 (0) | 2026.04.30 |
|---|---|
| 실제 UE 5G Traffic Dataset 기반으로 바라본 Network Slicing (0) | 2026.04.29 |
| VM에 Free5GC Docker Compose 설치하기 (0) | 2026.04.26 |
| OAI 5G에서 다중 UE 구성과 Downlink Traffic 생성하기 (0) | 2026.04.25 |
| OAI RAN + Free5GC 환경에서 AI Agent로 네트워크 슬라이스를 통합 제어 Prototype 설계 (0) | 2026.04.23 |