Skip to content

OpenAirInterface 5G Core Traffic redirect/Redirection Network Deployment and Testing With Gnbsim

SA Traffic Redirection Scenario

Reading time: ~ 20 minutes

Tutorial replication time: ~ 1h

Compute resource recommendation: ~ 6GB RAM, 8CPU

Note: In case readers are interested in deploying debuggers/developers core network environment with more logs please follow this tutorial

  1. Pre-requisites
  2. Building Container Images or Retrieving Container Images
  3. Deploying OAI 5G Core Network
  4. Simulate with gnbsim
  5. Traffic test for Redirection
  6. Trace Analysis
  7. Undeploy Network Functions
  8. Conclusion

For this demo, all the images which use the develop branch have been retrieved from the official docker-hub (see also Retrieving images).

NF Name Branch Name Tag used at time of writing Ubuntu 22.04 RHEL8
NSSF develop v2.0.1 X -
AMF develop v2.0.1 X -
AUSF develop v2.0.1 X -
NRF develop v2.0.1 X -
SMF develop v2.0.1 X -
UDR develop v2.0.1 X -
UDM develop v2.0.1 X -
PCF develop v2.0.1 X -
UPF-VPP develop v2.0.1 X -


This tutorial shows how to configure the Traffic Redirection feature at SMF and UPF, based on policies from the PCF.

We will show and validate: * Traffic redirection scenario for a subscriber (gnbsim) with traffic classification and URL based redirection to destination server

1. Pre-requisites

Create a folder where you can store all the result files of the tutorial and later compare them with our provided result files. We recommend creating exactly the same folder to not break the flow of commands afterwards.

docker-compose-host $: mkdir -p /tmp/oai/redirect-scenario
docker-compose-host $: chmod 777 /tmp/oai/redirect-scenario

2. Building Container Images or Retrieving Container Images

3. Deploying OAI 5g Core Network

We use docker-compose to deploy the core network. Please refer to the file docker-compose-basic-vpp-pcf-redirection.yaml for details.

Docker Networks

In total, 3 different docker networks are used: * public_net (demo-oai) for control plane * public_net_access (cn5g-access) for the N3 interface between gnbsim and gNB * public_net_core (cn5g-core) for the N6 interface between UPF and DN

Deployment and Tracing

The first interface (demo-oai) is used for the control plane, including the N4 interfaces to all UPFs. The others are used for the user plane.

Therefore, we do not need to filter out the UP when tracing on the demo-oai interface. We run the mysql service first, so that we can start the trace before anything is sent over the CP. You can choose to skip this step and deploy all the NFs at once.

docker-compose-host $: docker-compose -f docker-compose-basic-vpp-pcf-redirection.yaml up -d mysql 
Creating network "demo-oai-public-net" with driver "bridge"
Creating network "oai-public-access" with the default driver
Creating network "oai-public-core" with the default driver
Creating mysql ... done

We capture the packets on the docker networks and filter out ARP. 

docker-compose-host $: sleep 1
docker-compose-host $: nohup sudo tshark -i demo-oai -f "not arp" -w /tmp/oai/redirect-scenario/control_plane.pcap > /tmp/oai/redirect-scenario/control_plane.log 2>&1 &

Then, we start all the NFs.

docker-compose-host $: docker-compose -f docker-compose-basic-vpp-pcf-redirection.yaml up -d
mysql is up-to-date
Creating oai-nrf             ... done
Creating oai-udr             ... done
Creating vpp-upf             ... done
Creating oai-pcf             ... done
Creating oai-udm             ... done
Creating oai-ext-dn          ... done
Creating oai-ausf            ... done
Creating oai-amf             ... done
Creating oai-smf             ... done

Checking the Status of the NFs

Using docker ps you can verify that no NF exited, e.g. because of a faulty configuration:

Also all should be in an healthy state before going further. The mysql container may take some time. 

docker-compose-host $: docker ps
CONTAINER ID   IMAGE                 COMMAND                  CREATED          STATUS                    PORTS                          NAMES
16e442edd7b9   oai-smf:develop        "/bin/bash /openair-…"   30 seconds ago   Up 29 seconds (healthy)   80/tcp, 8080/tcp, 8805/udp     oai-smf
17cd7f15c863   oai-amf:develop       "python3 /openair-am…"   31 seconds ago   Up 29 seconds (healthy)   80/tcp, 9090/tcp, 38412/sctp   oai-amf
81d91b0e9719   oai-ausf:develop       "/bin/bash /openair-…"   32 seconds ago   Up 31 seconds (healthy)   80/tcp                         oai-ausf
4c11b8c156fc   trf-gen-cn5g:latest   "/bin/bash -c 'iptab…"   32 seconds ago   Up 30 seconds (healthy)                                  oai-ext-dn
9da12093f3d6   oai-udm:develop        "/bin/bash /openair-…"   33 seconds ago   Up 31 seconds (healthy)   80/tcp                         oai-udm
b867ac7db503   oai-upf-vpp:develop    "/openair-upf/bin/en…"   34 seconds ago   Up 31 seconds (healthy)   2152/udp, 8085/udp             vpp-upf
4e133a45bd0b   oai-pcf:develop        "/bin/bash /openair-…"   34 seconds ago   Up 33 seconds (healthy)   80/tcp, 8080/tcp               oai-pcf
341271bb659a   oai-udr:develop        "/bin/bash /openair-…"   34 seconds ago   Up 33 seconds (healthy)   80/tcp                         oai-udr
aa8cbc6fe533   oai-nrf:develop        "python3 /openair-nr…"   34 seconds ago   Up 33 seconds (healthy)   80/tcp, 9090/tcp               oai-nrf
ac10687810e0   mysql:5.7             "docker-entrypoint.s…"   34 seconds ago   Up 33 seconds (healthy)   3306/tcp, 33060/tcp            mysql

Please wait until all NFs are healthy.

4. Simulate with gnbsim

When the CN is deployed successfully, we can simulate a gNB and UE using gnbsim. Please see the gnbsim tutorial on how to retrieve or build the image.

docker-compose-host $: docker-compose -f docker-compose-gnbsim-vpp.yaml up -d 
Creating gnbsim-vpp ...
Creating gnbsim-vpp ... done

We can verify that the gNB received an IP address and that the PDU session establishment was successful. 

docker-compose-host $: docker logs gnbsim-vpp 2>&1 | grep "UE address:"
[gnbsim]2023/01/13 17:07:05.134094 example.go:332: UE address: 12.1.1.2
It can take some time until the PDU session establishment is complete, so you may have to repeat this command until you see the IP address.

5. Traffic Test for Redirection

Note: As tshark is running in the background, and we run everything in the same terminal, we will stop the control plane traces here. If you want, you can open tshark on another terminal and terminate it whenever it suits you.

docker-compose-host $: sudo pkill tshark 
docker-compose-host $: sleep 5

Before we start the traffic tests, we start the user plane trace without any filter: 

docker-compose-host $: nohup sudo tshark -i cn5g-access -i cn5g-core  -w /tmp/oai/redirect-scenario/user_plane_redirect.pcap > /tmp/oai/redirect-scenario/user_plane_redirect.log 2>&1 &

This capture contains all the UP network interfaces.

Please make a note that, * In the policy decisions file (policies/redirection/policy_decisions/policy_decision.yaml), we configure UE IMSI with PCC rule to be used. We can verify that the UE with the IMSI 208950000000031 is configured to use the PCC rule redirection-rule.

  • Moreover, the PCC rules (policies/redirection/pcc_rules/pcc_rules.yaml) configured for redirection contains flowDescription as permit out ip from any to assigned which is basically means that, to allow all kind of UE traffic and redirection the traffic to destination server address as per traffic control rule defined inpolicies/redirection/traffic_rules/traffic_rule.yaml.

  • As you can see below, in the traffic contorl rule (policies/redirection/traffic_rules/traffic_rule.yaml) we use redirect server address type as URL & redirect server addressas facebook.com.

redirection-scenario:
  redirectInfo:
    redirectEnabled: true
    redirectAddressType: URL
    redirectServerAddress: facebook.com

Note: Currently only URL type of redirection supported

Now, we generate HTTP traffic to destination as google.com, which will be redirected to destination server facebook.com.

docker-compose-host $: docker exec -it gnbsim-vpp curl --interface 12.1.1.2 google.com
<!DOCTYPE html>
<html>
<!--
<?xml version="1.0" encoding="UTF-8"?><WISPAccessGatewayParam xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.acmewisp.com/WISPAccessGatewayParam.xsd"><Proxy><MessageType>110</MessageType><ResponseCode>200</ResponseCode><NextURL>facebook.com</NextURL></Proxy></WISPAccessGatewayParam>
-->
   <head>
      <title>Redirection</title>
      <meta http-equiv="refresh" content="0; URL=facebook.com">
   </head>
   <body>
      Please <a href='facebook.com'>click here</a> to continue
   </body>
</html>

We capture here UPF session details & traffic trace

docker-compose-host $: docker exec vpp-upf bin/vppctl show upf session > /tmp/oai/redirect-scenario/vpp-upf-redirect-session.log 2>&1

We will see in the analysis that the IP packets to google.com are redirected to destination facebook.com over EXT-DN-Internet.

6. Trace Analysis

Now that we have captured control plane and user plane traces, we can stop tshark: 

docker-compose-host $: sudo pkill tshark

Then, we change the permissions of the traces to open them in Wireshark: 

docker-compose-host $: sudo chmod 666 /tmp/oai/redirect-scenario/control_plane.*
docker-compose-host $: sudo chmod 666 /tmp/oai/redirect-scenario/user_plane_redirect.*

As we capture more than one interface, the pcap files are likely out-of-order. To solve this, sort based on the Time column.

Redirection Scenario

The results of this tutorial are located in results/redirect. Click on the files below to view them:

Logs/PCAPs Files
Logs amf.log, ausf.log, control_plane.log, gnbsim-vpp.log, nrf.log, pcf.log, smf.log, udm.log, udr.log, ue-test.log, user_plane_redirect.log, vpp-upf-redirect-session.log, vpp-upf.log
PCAPs control_plane.pcap, user_plane_redirect.pcap

We can verify the PDU session details as per UPF session logs. We should note that the forwarding rule is set with redirect information, describing all HTTP traffic will be redirected to destination URL facebook.com

FAR: 1
  Apply Action: 00000002 == [FORWARD]
  Forward:
    Network Instance: internet.oai.org
    Destination Interface: 1
    Redirect Information: HTTP to facebook.com

In the UE traffic trace at gnbsim-vpp, we can see that the HTTP GET request generated using curl for destination google.com is redirected to new HTTP address facebook.com. This can be also confirmed in the pcap trace user_plane_redirect.pcap, where request packet #4 is destinated for URI google.com & the response packet #6 is with HTTP code (302-redirection) from destination facebook.com

7. Undeploy Network Functions

When you are done, you can undeploy the gnbsim instances and stop the NFs.

First, we stop the gnbsim instances:

docker-compose-host $: docker-compose -f docker-compose-gnbsim-vpp.yaml stop -t 2

Then, we stop the NFs. 

docker-compose-host $: docker-compose -f docker-compose-basic-vpp-pcf-redirection.yaml stop -t 2

Now we are able to collect the logs.

docker-compose-host $: docker logs oai-amf > /tmp/oai/redirect-scenario/amf.log 2>&1
docker-compose-host $: docker logs oai-smf > /tmp/oai/redirect-scenario/smf.log 2>&1
docker-compose-host $: docker logs oai-nrf > /tmp/oai/redirect-scenario/nrf.log 2>&1
docker-compose-host $: docker logs vpp-upf > /tmp/oai/redirect-scenario/vpp-upf.log 2>&1
docker-compose-host $: docker logs oai-udr > /tmp/oai/redirect-scenario/udr.log 2>&1
docker-compose-host $: docker logs oai-udm > /tmp/oai/redirect-scenario/udm.log 2>&1
docker-compose-host $: docker logs oai-ausf > /tmp/oai/redirect-scenario/ausf.log 2>&1
docker-compose-host $: docker logs oai-pcf > /tmp/oai/redirect-scenario/pcf.log 2>&1
docker-compose-host $: docker logs gnbsim-vpp > /tmp/oai/redirect-scenario/gnbsim-vpp.log 2>&1

Finally, we undeploy the gnbsims and NFs to clean up the Docker networks.

docker-compose-host $: docker-compose -f docker-compose-gnbsim-vpp.yaml down -t 2
docker-compose-host $: docker-compose -f docker-compose-basic-vpp-pcf-redirection.yaml down -t 2

8. Conclusion

We shown in this tutorial how the traffic redirection can be configured in the OAI CN with the help of policy configuration at PCF. We have used VPP-UPF for validation of this feature. We have verified the URL based redirection in this tutorial. Other types of redirection, e.g. server address type ipv4/ipv6/SIP URI are not currently supported in VPP-UPF.