srsran / srsRAN_Project

Open source O-RAN 5G CU/DU solution from Software Radio Systems (SRS) https://docs.srsran.com/projects/project
https://www.srsran.com
GNU Affero General Public License v3.0
514 stars 175 forks source link

Adding a slice section to ue_zmq.conf causes attach to Open5GS to fail #165

Closed s5uishida closed 1 year ago

s5uishida commented 1 year ago

Issue Description

Adding a slice section to ue_zmq.conf causes InitialUEMessage, Registration request to Open5GS to fail.

Setup Details

I added a slice section to ue_zmq.conf as below.

[slicing]
enable = true
nssai-sst = 1
nssai-sd = 1

Also I added a slice section to gnb_zmq.yaml.

slicing:
  - sst: 1
    sd: 1
#  - sst: 1
#    sd: 2

Open5GS log is as follows.

08/11 13:41:18.787: [amf] INFO: InitialUEMessage (../src/amf/ngap-handler.c:372)
08/11 13:41:18.787: [amf] INFO: [Added] Number of gNB-UEs is now 1 (../src/amf/context.c:2510)
08/11 13:41:18.787: [amf] INFO:     RAN_UE_NGAP_ID[0] AMF_UE_NGAP_ID[5] TAC[1] CellID[0x19b0] (../src/amf/ngap-handler.c:533)
08/11 13:41:18.787: [amf] INFO: [suci-0-001-01-0000-0-0-0000000000] Unknown UE by SUCI (../src/amf/context.c:1776)
08/11 13:41:18.787: [amf] INFO: [Added] Number of AMF-UEs is now 1 (../src/amf/context.c:1563)
08/11 13:41:18.787: [gmm] INFO: Registration request (../src/amf/gmm-sm.c:1061)
08/11 13:41:18.787: [gmm] ERROR: Non cleartext IEs is included [0xc] (../src/amf/gmm-handler.c:116)
08/11 13:41:18.787: [gmm] ERROR: Unknown reg_type[0] (../src/amf/gmm-sm.c:1080)
08/11 13:41:18.787: [gmm] ERROR: gmm_handle_registration_request() failed [95] (../src/amf/gmm-sm.c:1084)
08/11 13:41:18.787: [amf] ERROR: Unknown reg_type[0] (../src/amf/nas-path.c:215)
08/11 13:41:18.787: [amf] WARNING: [(null)] Registration reject [95] (../src/amf/nas-path.c:219)
08/11 13:41:18.789: [amf] INFO: UE Context Release [Action:3] (../src/amf/ngap-handler.c:1632)
08/11 13:41:18.789: [amf] INFO:     RAN_UE_NGAP_ID[0] AMF_UE_NGAP_ID[5] (../src/amf/ngap-handler.c:1633)
08/11 13:41:18.789: [amf] INFO:     SUCI[Unknown] (../src/amf/ngap-handler.c:1636)
08/11 13:41:18.789: [amf] INFO: [Removed] Number of gNB-UEs is now 0 (../src/amf/context.c:2517)
08/11 13:41:18.789: [amf] INFO: [Removed] Number of AMF-UEs is now 0 (../src/amf/context.c:1656)

The pcap log at this time is as follows. slice_section_exist.zip

Frame 113: 112 bytes on wire (896 bits), 112 bytes captured (896 bits)
Linux cooked capture v2
Internet Protocol Version 4, Src: 192.168.0.111, Dst: 192.168.0.121
Stream Control Transmission Protocol, Src Port: 38412 (38412), Dst Port: 37003 (37003)
NG Application Protocol (DownlinkNASTransport)
    NGAP-PDU: initiatingMessage (0)
        initiatingMessage
            procedureCode: id-DownlinkNASTransport (4)
            criticality: ignore (1)
            value
                DownlinkNASTransport
                    protocolIEs: 3 items
                        Item 0: id-AMF-UE-NGAP-ID
                        Item 1: id-RAN-UE-NGAP-ID
                        Item 2: id-NAS-PDU
                            ProtocolIE-Field
                                id: id-NAS-PDU (38)
                                criticality: reject (0)
                                value
                                    NAS-PDU: 7e00445f
                                        Non-Access-Stratum 5GS (NAS)PDU
                                            Plain NAS 5GS Message
                                                Extended protocol discriminator: 5G mobility management messages (126)
                                                0000 .... = Spare Half Octet: 0
                                                .... 0000 = Security header type: Plain NAS message, not security protected (0)
                                                Message type: Registration reject (0x44)
                                                5GMM cause
                                                    5GMM cause: Semantically incorrect message (95)

The logs of gnb and srsue were as follows.

# ./gnb -c gnb_zmq.yaml
Lower PHY in executor blocking mode.

--== srsRAN gNB (commit 1afd7240f) ==--

Connecting to AMF on 192.168.0.111:38412
Available radio types: zmq.
Cell pci=1, bw=10 MHz, dl_arfcn=368500 (n3), dl_freq=1842.5 MHz, dl_ssb_arfcn=368410, ul_freq=1747.5 MHz

==== gNodeB started ===
Type <t> to view trace
# ./src/srsue ue_zmq.conf
Reading configuration file ue_zmq.conf...

Built in Release mode using commit fa56836b1 on branch master.

Opening 1 channels in RF device=zmq with args=tx_port=tcp://192.168.0.122:2001,rx_port=tcp://192.168.0.121:2000,base_srate=11.52e6
Supported RF device list: zmq file
CHx base_srate=11.52e6
Current sample rate is 1.92 MHz with a base rate of 11.52 MHz (x6 decimation)
CH0 rx_port=tcp://192.168.0.121:2000
CH0 tx_port=tcp://192.168.0.122:2001
Current sample rate is 11.52 MHz with a base rate of 11.52 MHz (x1 decimation)
Current sample rate is 11.52 MHz with a base rate of 11.52 MHz (x1 decimation)
Waiting PHY to initialize ... done!
Attaching UE...
Random Access Transmission: prach_occasion=0, preamble_index=0, ra-rnti=0x39, tti=334
Random Access Complete.     c-rnti=0x4601, ta=0
RRC Connected

If make slicing.enable = false in ue_zmq.conf, it works fine.

Expected Behavior

I want to specify slice and attach UE with ZMQ to Open5GS.

Actual Behaviour

Steps to reproduce the problem

Additional Information

The environment of gNodeB with ZMQ (srsRAN_Project) and UE with ZMQ (srsRAN_4G) are as follows.

gnb_id: 0x19B

slicing:

amf: addr: 192.168.0.111 # The address or hostname of the AMF. bind_addr: 192.168.0.121 # A local IP that the gNB binds to for traffic from the AMF.

ru_sdr: device_driver: zmq # The RF driver name. device_args: tx_port=tcp://192.168.0.121:2000,rx_port=tcp://192.168.0.122:2001,base_srate=11.52e6 # Optionally pass arguments to the selected RF driver. srate: 11.52 # RF sample rate might need to be adjusted according to selected bandwidth. tx_gain: 75 # Transmit gain of the RF might need to adjusted to the given situation. rx_gain: 75 # Receive gain of the RF might need to adjusted to the given situation.

cell_cfg: dl_arfcn: 368500 # ARFCN of the downlink carrier (center frequency). band: 3 # The NR band. channel_bandwidth_MHz: 10 # Bandwith in MHz. Number of PRBs will be automatically derived. common_scs: 15 # Subcarrier spacing in kHz used for data. plmn: "00101" # PLMN broadcasted by the gNB. tac: 1 # Tracking area code (needs to match the core configuration). pdcch: dedicated: ss2_type: common # Search Space type, has to be set to common dci_format_0_1_and_1_1: false # Set correct DCI format (fallback)

log: filename: /tmp/gnb.log # Path of the log file. all_level: info # Logging level applied to all layers. hex_max_size: 0

pcap: mac_enable: false # Set to true to enable MAC-layer PCAPs. mac_filename: /tmp/gnb_mac.pcap # Path where the MAC PCAP is stored. ngap_enable: false # Set to true to enable NGAP PCAPs. ngap_filename: /tmp/gnb_ngap.pcap # Path where the NGAP PCAP is stored.


- `ue_zmq.conf`

[rf] freq_offset = 0 tx_gain = 50 rx_gain = 40 srate = 11.52e6 nof_antennas = 1

device_name = zmq device_args = tx_port=tcp://192.168.0.122:2001,rx_port=tcp://192.168.0.121:2000,base_srate=11.52e6

[rat.eutra] dl_earfcn = 2850 nof_carriers = 0

[rat.nr] bands = 3 nof_carriers = 1

[pcap] enable = none mac_filename = /tmp/ue_mac.pcap mac_nr_filename = /tmp/ue_mac_nr.pcap nas_filename = /tmp/ue_nas.pcap

[log] all_level = info phy_lib_level = none all_hex_limit = 32 filename = /tmp/ue.log file_max_size = -1

[usim] mode = soft algo = milenage opc = E8ED289DEBA952E4283B54E88E6183CA k = 465B5CE8B199B49FAA5F0A2EE238A6BC imsi = 001010000000000 imei = 353490069873319

[rrc] release = 15 ue_category = 4

[nas] apn = internet apn_protocol = ipv4

[slicing] enable = true nssai-sst = 1 nssai-sd = 1

[gw]

netns = ue1

ip_devname = tun_srsue ip_netmask = 255.255.255.0

[gui] enable = false

s5uishida commented 1 year ago

For free5GC, UE was able to connect to free5GC 5GC using the ue_zmq.conf with the slicing section enabled.

s5uishida commented 1 year ago

This issue has been clear a little.

When added the slicing section to ue_zmq.yaml, srsue created an InitialUEMessage appended NSSAI to the Plain NAS 5GS Message, and sent it to AMF.

On the other hand, according to the specification below, NSSAI is not specified to be included in cleartext IE.

3GPP TS 24.501 - 4.4.6 Protection of initial NAS signalling messages

When the initial NAS message is a REGISTRATION REQUEST message, the cleartext IEs are:

- Extended protocol discriminator;
- Security header type;
- Spare half octet;
- Registration request message identity;
- 5GS registration type;
- ngKSI;
- 5GS mobile identity;
- UE security capability;
- Additional GUTI;
- UE status; and
- EPS NAS message container.

Open5GS checked this and returned an error.

So I think that srsue needs to follow the above specification.

I'm sorry if I misunderstood.

Best regards,

--Shigeru

andrepuschmann commented 1 year ago

Hey @s5uishida - thanks for digging into this issue yourself. Your conclusion seems correct - NSSAI IE is not allowed to go over the air in cleartext. Please feel free to open a ticket in srsRAN_4G for it. Closing this one here. Thanks