# <center>Setup your own 5G Network</center> In this example, the EPC and en-gNB (NSA mode) and near-RT RIC are assumed to run on the same machine/VM (Machine 1). The UE, if using USRPs should be run on a different machine/VM (Machine 2). But if zeroMQ mode is used, a single machine suffices for all components. Refer to GNU radio integration for instructions to include multiple simulated UEs. # Running the EPC Before we start the EPC, we need to create a separate network namespace for the UE since all components are running on the same machine. ```bash sudo ip netns add ue1 sudo ip netns list ``` Now, in a new command window on Machine 1 run srsRAN EPC: ```bash sudo srsepc ``` The EPC can be run on a different machine and the eNB can connect to it based on its IP address. This IP address has to be specified in the eNB config file. # en-gNB and UE in ZeroMQ Mode Before we proceed further it would be worthwhile to open the logs of `E2 Manager, E2 Termination, Subscription Manager and Application Manager` to trace the flow of messages. The instructions to do this can be found in [Kubectl Commands](https://openaicellular.github.io/oaic/kubectl_commands.html#kubectl-commands) section. ## Running the en-gNB & connecting to near-RT RIC ==**Note:** If you want an xApp to communicate with the RAN, make sure that the xApp is not already deployed on the near-RT RIC platform.== ### Running the en-gNB & connecting to near-RT RIC In a new command window on Machine 1 run srsRAN en-gNB. But before we start the en-gNB, we need to get the current machine’s IP address and the IP address of the E2 Termination service at the near-RT RIC. ```bash export E2NODE_IP=`hostname -I | cut -f1 -d' '` export E2NODE_PORT=5006 export E2TERM_IP=`sudo kubectl get svc -n ricplt --field-selector metadata.name=service-ricplt-e2term-sctp-alpha -o jsonpath='{.items[0].spec.clusterIP}'` ``` ### srsENB in ZeroMQ mode ```bash sudo srsenb --enb.n_prb=50 --enb.name=enb1 --enb.enb_id=0x19B \ --rf.device_name=zmq --rf.device_args="fail_on_disconnect=true,tx_port0=tcp://*:2000,rx_port0=tcp://localhost:2001,tx_port1=tcp://*:2100,rx_port1=tcp://localhost:2101,id=enb,base_srate=23.04e6" \ --ric.agent.remote_ipv4_addr=${E2TERM_IP} --log.all_level=warn --ric.agent.log_level=debug --log.filename=stdout --ric.agent.local_ipv4_addr=${E2NODE_IP} --ric.agent.local_port=${E2NODE_PORT} ``` Once the en-gNB is up and successfully connected to the near-RT RIC, you will see E2 Setup and E2 Response messages on the console. You will also see `RIC Connection Initialized` and `RIC state established` messages. ### srsUE in ZeroMQ mode This command uses the default config file. The following message `RRC NR reconfiguration successful` confirms that the UE has connected to the NR cell. This will be used for the data link, while the LTE cell will be used for control messaging. On a new command terminal on the same machine run, ```bash sudo srsue --gw.netns=ue1 ``` Once the UE connects successfully to the network, the UE will be assigned an IP. ## Exchanging Traffic We outline testing the network through `ping` and `iperf`. ### PING This is the simplest way to test the network. This will test whether or not the UE and core can successfully communicate. - Uplink When using zeroMQ, the ping command should be executed on a new terminal from the UE’s network space ```bash sudo ip netns exec ue1 ping 172.16.0.1 ``` - Downlink For Downlink, on a new terminal run ```bash sudo ping <ue_ip> ``` ### iPerf3 In this scenario, client will run on the UE side with the server on the network side (core). UDP traffic will be generated at 10Mbps for 60 seconds. It is important to start the server first, and then the client. Note: Both the client and server should be run on the same machine but on different terminal windows. - Network Side ```bash iperf3 -s -i 1 ``` - UE-Side Again, since we are using zeroMQ, the iperf client should be run from the UE’s network namespace. ```bash sudo ip netns exec ue1 iperf3 -c 172.16.0.1 -b 10M -i 1 -t 60 ```