Integrating Disaggregated OpenAirInterface O-RAN Components with Open5GS 5G Core

The evolution of 5G networks has been marked by a significant shift towards disaggregation and open interfaces. This transformation is particularly evident in Radio Access Networks (RAN), where traditional integrated solutions are giving way to disaggregated components that promote vendor neutrality and operational flexibility. OpenAirInterface (OAI), an open-source initiative by OpenAirInterface Software Alliance (OSA), has emerged as a prominent player in this space by providing disaggregated O-RAN components. Similarly, Open5GS has established itself as a reliable open-source 5G core implementation.

This guide demonstrates the practical integration of OAI’s disaggregated RAN components — UE, DU (Distributed Unit), CU-CP (Centralized Unit — Control Plane), and CU-UP (Centralized Unit — User Plane) with the Open5GS 5G core network. By following this implementation, readers will understand how these components interact within a complete 5G network architecture while maintaining alignment with O-RAN specifications.

Architecture is shown below

N.B — The OAI NR UE is simulated in this writeup.

OAI already provides helm charts for all the RAN functions, please see below:

charts/oai-5g-ran/oai-cu-cp · master · oai / cn5g / oai-cn5g-fed · GitLab

charts/oai-5g-ran/oai-cu-up · master · oai / cn5g / oai-cn5g-fed · GitLab

charts/oai-5g-ran/oai-du · master · oai / cn5g / oai-cn5g-fed · GitLab

charts/oai-5g-ran/oai-nr-ue · master · oai / cn5g / oai-cn5g-fed · GitLab

Key Findings and Solutions

1. Network Slicing Configuration

Working Slice Configuration:

• SST: 1
• SD: 0xFFFFFF

Default Values Discrepancy:

• Open5GS default SD: 1
• OAI default SD: 0xFFFFFF (16777215)

Issue Observed In The UE While Setting Up PDU Session:

"3227807.328419 [NAS] E NSSAI parameters not match with allowed NSSAI. Couldn't request PDU session."

• This occurs when trying to use SST:1, SD:1 configuration
• Issue is under investigation with OAI developers

2. IPv6 Handling in OAI-NR-UE

Issue:

• OAI-NR-UE RF simulator uses IPv6 also for the tunnel interface
• Causes UPF errors in IPv4-only setups:

[upf] ERROR: Invalid packet [IP version:6, Packet Length:48]

Solution:

• Disable IPv6 at kernel level in OAI-NR-UE pod

sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1

Implementation:

• Add these commands to OAI-NR-UE deployment manifest in helm chart before deployment

These findings are particularly valuable for anyone implementing similar integrations and help avoid common pitfalls in the deployment process.

Relevant Configuration Details

Some helm values that were used are shown below:

CU-CP

multus:
  # to remove the default gateway change it with ""
  defaultGateway: ""
  e1Interface: # use this interface if using one interface for all 3GPP interfaces
    create: true
    ipAdd: "10.2.1.16"
    netmask: "24"
    name: "e1"
    # if gatway is empty then it will be removed
    #gateway: ""
    #routes: [{'dst': '10.8.0.0/24','gw': '172.21.7.254'}, {'dst': '10.9.0.0/24','gw': '172.21.7.254'}]
    hostInterface: "ens23"      # Interface of the host machine on which this pod will be scheduled
  n2Interface:
    create: true
    ipAdd: "10.1.2.18"
    netmask: "24"
    name: "n2"
    # if gatway is empty then it will be removed
    #gateway: ""
    #routes: 
    hostInterface: "ens23"      # Interface of the host machine on which this pod will be scheduled
  f1cInterface:
    create: true
    ipAdd: "10.2.5.16"
    netmask: "24"
    name: "f1c"
    # if gatway is empty then it will be removed
    #gateway: ""
    #routes: 
    hostInterface: "ens23"      # Interface of the host machine on which this pod will be scheduled

## configuration file is in template/config.yaml 
## It is taken from https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/ci-scripts/conf_files/gnb-cucp.sa.f1.conf
config:
  timeZone: "Europe/Paris"
  useAdditionalOptions: "--sa --log_config.global_log_options level,nocolor,time"
  cucpName: "oai-cu-cp"
  mcc: "208"   # check the information with AMF, SMF, UPF
  mnc: "93"    # check the information with AMF, SMF, UPF
  tac: "7"     # check the information with AMF
  sst: "1"  #currently only 4 standard values are allowed 1,2,3,4
  #sd: "1"
  amfhost: "10.1.2.16"  # amf ip-address or service-name oai-amf-svc or 172.21.6.94
  n2IfName: "n2"    # if multus.n2Interface.create is true then use n2
  f1IfName: "f1c"   #if multus.f1Interface.create is true then use f1
  e1IfName: "e1"   #if multus.f1Interface.create is true then use e1
  f1cuPort: "2153"   #2153 if using same interface for f1 and n2 else standard port 2152 should be use if f1 and n3 interface are different
  f1duPort: "2153"  

CU-UP

multus:
  # to remove the default gateway change it with ""
  defaultGateway: ""
  e1Interface: # use this interface if using one interface for all 3GPP interfaces
    create: true
    ipAdd: "10.2.1.17"
    netmask: "24"
    name: "e1"
    # if gatway is empty then it will be removed
    #gateway: ""
    #routes: [{'dst': '10.8.0.0/24','gw': '172.21.7.254'}, {'dst': '10.9.0.0/24','gw': '172.21.7.254'}]
    hostInterface: "ens23"      # Interface of the host machine on which this pod will be scheduled
  n3Interface:
    create: true
    ipAdd: "10.1.3.17"
    netmask: "24"
    name: "n3"
    # if gatway is empty then it will be removed
    #gateway: ""
    #routes: []
    hostInterface: "ens23"      # Interface of the host machine on which this pod will be scheduled
  f1uInterface:
    create: true
    ipAdd: "10.2.5.17"
    netmask: "24"
    name: "f1u"
    # if gatway is empty then it will be removed
    #gateway: ""
    #routes: []
    hostInterface: "ens23"      # Interface of the host machine on which this pod will be scheduled

## configuration file is in template/config.yaml 
## It is taken from https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/ci-scripts/conf_files/gnb-cuup.sa.f1.conf
config:
  timeZone: "Europe/Paris"
  useAdditionalOptions: "--sa"
  cuupName: "oai-cuup"
  mcc: "208"   # check the information with AMF, SMF, UPF
  mnc: "93"    # check the information with AMF, SMF, UPF
  tac: "7"     # check the information with AMF
  sst: "1"     #currently only 4 standard values are allowed 1,2,3,4
  #sd: "1"
  cuCpHost: "10.2.1.16" # 
  n3IfName: "n3"   #if multus.n3Interface.create is true then use n3 or you can only use 1 interface n3 or eth0 
  f1IfName: "f1u"   #if multus.f1uInterface.create is true then use f1 or you can only use 1 interface n3 or eth0 
  e1IfName: "e1"   #if multus.e1Interface.create is true then use e1 or you can only use 1 interface n3 or eth0 
  f1cuPort: "2153"   #2153 if using same interface for f1 and n3 else standard port 2152 should be use if f1 and n3 interface are different
  f1duPort: "2153"   #2153 if using same interface for f1 and n3 else standard port 2152 should be use if f1 and n3 interface are different

DU

multus:
  # if default gateway is left blank then it will be removed
  defaultGateway: ""
  f1Interface:  # use this interface if using one interface for all 3GPP interfaces
    create: true
    ipAdd: "10.2.5.18"
    netmask: "24"
    name: "f1"
    # if gatway is empty then it will be removed
    #gateway: "172.21.7.254"
    #routes: [{'dst': '10.8.0.0/24','gw': '172.21.7.254'}, {'dst': '10.9.0.0/24','gw': '172.21.7.254'}]
    hostInterface: "ens23"      # Interface of the host machine on which this pod will be scheduled
  ruInterface:            #Only needed if using a ethernet based RU/USRP
    create: false
    ipAdd: "10.2.6.16"
    netmask: "24"
    name: "ru"
    # if gatway is commented then it will be remove
    #gateway: "192.168.80.1"  #In case you don't have a gateway remove it from here
    ## The value must be [0, master's MTU]. If commented it will masters MTU
    #mtu: 9000
    hostInterface: "ens23"      # Interface of the host machine on which this pod will be scheduled

## If you want to change more configuration parameters then you should mount the config file  
# in templates/configmap.yaml
# Example config files --> https://gitlab.eurecom.fr/oai/openairinterface5g/-/tree/develop/targets/PROJECTS/GENERIC-NR-5GC/CONF 
config:
  timeZone: "Europe/Paris"
  useAdditionalOptions: "--sa --rfsim --log_config.global_log_options level,nocolor,time"
  duName: "oai-du-rfsim"
  mcc: "208"   # check the information with AMF, SMF, UPF
  mnc: "93"    # check the information with AMF, SMF, UPF
  tac: "7"     # check the information with AMF
  sst: "1"  #currently only 4 standard values are allowed 1,2,3,4
  #sd: "1"
  usrp: rfsim   #allowed values rfsim, b2xx, n3xx or x3xx
  f1IfName: "f1"   #if multus.f1Interface.create is true then use f1
  cuHost: "10.2.5.16" ## Ip-address or hostname
  f1cuPort: "2153"   #2153 if using same interface for f1 and n3 else standard port 2152 should be use if f1 and n3 interface are different
  f1duPort: "2153"   #2153 if using same interface for f1 and n3 else standard port 2152 should be use if f1 and n3 interface are different

OAI-NR-UE

config:
  timeZone: "Europe/Paris"
  rfSimServer: "oai-ran"    # ip-address of rfsim or service name oai-gnb or oai-du
  fullImsi: "208930000000031"       # make sure all the below entries are present in the subscriber database
  fullKey: "0C0A34601D4F07677303652C0462535B"
  opc: "63bfa50ee6523365ff14c1f45f88737d"
  dnn: "internet"
  sst: "1"                     # configure according to gnb and amf, smf and upf 
  sd: "ffffff"
  usrp: "rfsim"            # allowed rfsim, b2xx, n3xx, x3xx
  useAdditionalOptions: "--sa --rfsim -r 106 --numerology 1 -C 3619200000 --log_config.global_log_options level,nocolor,time"

The UE configuration in Open5gs:

Same slicing configuration is applied to the AMF and NSSF.

Validation

CU-CP success connection with AMF:

3295872.232649 [ITTI] I Created Posix thread TASK_RRC_GNB
3295872.236146 [ITTI] I Created Posix thread TASK_CUCP_E1
3295872.236137 [E1AP] I Starting E1AP at CU CP
3295872.236147 [NGAP] D servedGUAMIs.list.count 1
3295872.236164 [NGAP] D PLMNSupportList.list.count 1
3295872.236167 [NGAP] D PLMNSupportList.list.count 1
3295872.236244 [GTPU] I Configuring GTPu
3295872.236269 [GTPU] I SA mode
3295872.236293 [GNB_APP] I [gNB 0] Received NGAP_REGISTER_GNB_CNF: associated AMF 1

CU-CP success connection with CU-UP:

3295872.236293 [GNB_APP] I [gNB 0] Received NGAP_REGISTER_GNB_CNF: associated AMF 1
3295872.236359 [E1AP] I E1AP_CUCP_SCTP_REQ(create socket) for 10.2.1.16 len 10
3295872.236400 [F1AP] I F1AP_CU_SCTP_REQ(create socket) for 10.2.5.16 len 10
3295872.236418 [F1AP] I In F1AP connection, don't start GTP-U, as we have also E1AP
3295872.236576 [NR_RRC] I Entering main loop of NR_RRC message task
3295910.502801 [SCTP] W Received SCTP SHUTDOWN EVENT
3295910.502853 [E1AP] I Received SCTP shutdown for assoc_id 113, removing CUCP endpoint
3295910.502901 [NR_RRC] I Received E1 connection loss indication on RRC
3295910.502931 [NR_RRC] W CU-UP for assoc_id 113 not found!
3295912.319106 [NR_RRC] I Accepting new CU-UP ID 3584 name oai-cuup (assoc_id 115)

CU-CP success connection with DU:

3295934.505034 [NR_RRC] I Received F1 Setup Request from gNB_DU 3584 (oai-du-rfsim) on assoc_id 119
3295934.505157 [RRC] I Accepting DU 3584 (oai-du-rfsim), sending F1 Setup Response
3295934.505165 [RRC] I DU uses RRC version 17.3.0

CU-CP successful UE connection:

3312840.256268 [NR_RRC] I Send message to sctp: NGAP_InitialContextSetupResponse
3312840.491405 [NGAP] I PDUSESSIONSetup initiating message
3312840.491553 [NR_RRC] I UE 1: received PDU session setup request
3312840.491589 [NR_RRC] I Adding pdusession 10, total nb of sessions 1
3312840.493979 [NR_RRC] I UE 1: configure DRB ID 1 for PDU session ID 10
3312840.494020 [RRC] A selecting CU-UP ID 3584 based on exact NSSAI match (1:0xffffff)
3312840.494025 [RRC] I UE 1 associating to CU-UP assoc_id 115 out of 1 CU-UPs
3312840.496557 [RRC] I activate SRB 2 of UE 1
3312840.499477 [RRC] I UE 1 trigger UE context setup request with 1 DRBs
3312840.504326 [NR_RRC] I UE 1: Generate RRCReconfiguration (bytes 275, xid 0)
3312840.504690 [RRC] I UE 1: PDU session ID 10 modified 1 bearers
3312840.526183 [NR_RRC] I UE 1: Receive RRC Reconfiguration Complete message (xid 0)
3312840.526226 [NR_RRC] I msg index 0, pdu_sessions index 0, status 2, xid 0): nb_of_pdusessions 1,  pdusession_id 10, teid: 529854768
 3312840.526229 [NR_RRC] I NGAP_PDUSESSION_SETUP_RESP: sending the message

CU-UP showing GTP connection with Open5gs UPF:

[HW]   Version: Branch: HEAD Abrev. Hash: 871078a64d Date: Tue Aug 13 03:57:41 2024 +0000
[UTIL]   threadCreate() for TASK_SCTP: creating thread (no affinity, default priority)
[ITTI]   Created Posix thread TASK_SCTP
[UTIL]   threadCreate() for TASK_GTPV1_U: creating thread (no affinity, default priority)
[ITTI]   Created Posix thread TASK_GTPV1_U
[UTIL]   threadCreate() for TASK_CUUP_E1: creating thread (no affinity, default priority)
[ITTI]   Created Posix thread TASK_CUUP_E1
[E1AP]   Starting E1AP at CU UP
[GTPU]   Configuring GTPu
[GTPU]   SA mode
[GTPU]   Initializing UDP for local address 10.2.5.17 with port 2153
[GTPU]   Created gtpu instance id: 96
[GTPU]   Configuring GTPu address : 10.1.3.17, port : 2152
[GTPU]   Initializing UDP for local address 10.1.3.17 with port 2152
[GTPU]   Created gtpu instance id: 97
[E1AP]   adding UE with CU-CP UE ID 1 and CU-UP UE ID 1
[GTPU]   [97] Created tunnel for UE ID 1, teid for incoming: afcb1e06, teid for outgoing 76ef to remote IPv4: 10.1.3.16, IPv6 ::
[PDCP]   added drb 1 to UE ID 1

OAI-NR-UE logs:

3313317.928399 [PHY] I [RRC]UE NR Capability encoded, 10 bytes (86 bits)
3313317.928410 [NR_RRC] I UECapabilityInformation Encoded 106 bits (14 bytes)
3313317.947831 [NAS] I [UE 0] Received NAS_DOWNLINK_DATA_IND: length 46 , buffer 0x7fb194143bf0
3313317.947862 [NAS] I [UE] Received REGISTRATION ACCEPT message
3313317.947869 [NAS] W This NAS IEI (0x21) is not handled when extracting list of allowed NSSAI
3313317.947871 [NAS] W This NAS IEI (0x5e) is not handled when extracting list of allowed NSSAI
3313317.947885 [NAS] I Send NAS_UPLINK_DATA_REQ message(RegistrationComplete)
3313317.947896 [NAS] I Send NAS_UPLINK_DATA_REQ message(PduSessionEstablishRequest)
3313317.952646 [NR_PHY] I ============================================
3313317.952663 [NR_PHY] I [UE 0] Harq round stats for Downlink: 13/0/0
3313317.952666 [NR_PHY] I ============================================
3313318.152802 [NAS] I [UE 0] Received NAS_DOWNLINK_DATA_IND: length 40 , buffer 0x7fb19411af60
3313318.152850 [NR_RRC] W unknown message type 84
3313318.178857 [NR_RRC] I radio Bearer Configuration is present
3313318.182673 [PDCP] I added drb 1 to UE ID 0
3313318.182717 [SDAP] I Default DRB for the created SDAP entity: 1
3313318.182721 [NR_RRC] I State = NR_RRC_CONNECTED
3313318.182880 [RLC] I Added srb 2 to UE 0
3313318.182904 [RLC] I Added drb 1 to UE 0
3313318.182909 [RLC] I Added DRB to UE 0
3313318.182912 [MAC] I [UE 0] Applying CellGroupConfig from gNodeB
3313318.183433 [NR_RRC] I Measurement Configuration is present
3313318.183452 [NR_RRC] I rrcReconfigurationComplete Encoded 10 bits (2 bytes)
3313318.183449 [NAS] I [UE 0] Received NAS_CONN_ESTABLI_CNF: errCode 1, length 68
3313318.183455 [NR_RRC] I  Logical Channel UL-DCCH (SRB1), Generating RRCReconfigurationComplete (bytes 2)
3313318.183907 [OIP] I Interface oaitun_ue1 successfully configured, IPv4 10.45.0.7, IPv6 (null)

OAI-NR-UE ping test via the tunnel interface:

kubectl -n ran exec -ti deploy/oai-nr-ue -- ip -br a

lo               UNKNOWN        127.0.0.1/8
eth0@if1040      UP             10.244.0.155/24
oaitun_ue1       UNKNOWN        10.45.0.7/24

kubectl -n ran exec -ti deploy/oai-nr-ue -- ping -I oaitun_ue1 4.2.2.2 -c 2
PING 4.2.2.2 (4.2.2.2) from 10.45.0.7 oaitun_ue1: 56(84) bytes of data.
64 bytes from 4.2.2.2: icmp_seq=1 ttl=55 time=35.7 ms
64 bytes from 4.2.2.2: icmp_seq=2 ttl=55 time=33.9 ms

--- 4.2.2.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 33.882/34.808/35.735/0.926 ms

In conclusion, this integration demonstrates the significant strides made in open-source 5G development, particularly in achieving interoperability between different projects. The successful integration of OpenAirInterface’s disaggregated O-RAN components with Open5GS 5G Core showcases the maturity and reliability of these open-source implementations. While simulators like UERANSIM have played a crucial role in 5G development and testing, this implementation takes it further by demonstrating a functional O-RAN deployment with a production-grade 5G core network.

Special appreciation goes to both the OpenAirInterface Software Alliance (OSA) and Open5GS development teams for their outstanding contributions to the 5G ecosystem. Their commitment to open standards and interoperability has made it possible for organizations to deploy and experiment with 5G networks using open-source components, fostering innovation and advancement in telecommunications technology.

This integration serves as a testament to the viability of open-source solutions in building modern 5G networks and paves the way for further development in the O-RAN space.