PCF service consumer test application

[davidjwbbc]

Purpose

We wish to test our PCF service consumer library against a variety of different PCF implementations by developing a simple PCF service consumer test application.

Functional specification

1. Uses the PCF service consumer library to create (and populate with initial values) an Application Session Context in the PCF.
   • Including subscribing to receive notifications from the PCF concerning the created Application Session Context.
2. Reports any notifications that arrive until either:
   1. The PCF destroys the Application Session Context, or
   2. The user interrupts the program.
      • In this case, the Application Session Context is explicitly destroyed by the application before it exits.

Parameters

The application takes the following command line parameters:

1. The IP address of a UE registered in the 5G System.
2. The source port number (at the UE end) of an application data flow (optional).
3. PCF IP address (optional).
   • If omitted, the BSF service consumer library is invoked to discover the PCF for the given UE IP address.
   • If BSF lookup fails, the NRF is used to find a PCF.
4. List of notification events (optional).
   • If omitted, all event notifications are subscribed to.
5. Set of min/max downlink and uplink bit rate settings (optional).
   • If omitted, no initial values are populated in the Application Session Context when it is created.

[rjb1000]

@waddem01 - You may be interested to monitor progress on this issue.

[davidjwbbc]

Open5GS uses a central library, libogsapp, to manage initialisation, context and tidy up of Open5GS NF applications. This takes the command line arguments and looks for a limited set of options and requires a YAML configuration file to be present. Since we want a little more control over app at the command line, for this test application, we either need to:

1. Replace a lot of the libogsapp library with our own version, replicating most of what is there but customising it for our purposes.
2. Pre-process the command line ourselves, write out a YAML configuration file and only pass to the libogsapp routines a reduced set of command line parameters and the newly written configuration file.

Since the second option is the more lightweight to try, so initially I'll use that and switch to option 1 if we find the libogsapp initialisation is setting things up in a way we don't want (e.g. requiring server details for app so that it can set up a default listening socket).

I already have this prototyped the second option and it is compiling but it's not a very interesting test as it doesn't actually do any BSF/PCF lookup or PCF communication yet. We won't know the extent to which using the PCF and BSF service consumer libraries for communication will trigger requirements in the rest of the Open5GS libraries (libogsapp, libogscore, libogssbi, etc.). I also have an issue with the process signal handling being absent at present and need to add in the ogs_signal_*() calls into the test application in order to deal with signals. This currently results in the test application not tidying up allocated memory and temporary files, and just exiting.

[davidjwbbc]

Added code to:

• Handle IPC signals properly and close down neatly.
• Trigger BSF lookup if PCF address not explicitly specified in the command line parameters.
• Start PCF session (once PCF address is known).
• Create AppSessionContext (once PCF session is established) using supplied bit rates in a MediaComponent.
• Shut down if PCF notifies the destruction of the AppSessionContext.
• Report notifications.
  • Only Access Type Change event is fully reported.
  • Other notifications will only display a report heading.

I now need to test this code and complete the notification reports outputs.

[davidjwbbc]

Testing revealed lots of memory leaks due to the test application not tidying up properly on exit. Fixed this by adding a pcf_service_consumer_final() function to tidy up PCF service consumer library internals and terminating the SBI library services.

Found some logic errors in the PCF service consumer library and have tidied up the code there:

• Now generates a notification server on an ephemeral port and uses the ephemeral port number in the notification URL.
• Added logic to screen out events not generated by the PCF service consumer library and ignore them when processing events.
  • This also allows the library to add more warnings about poorly formatted responses or mismatches between requests and receiving logic.
• Events are now generated for internal client request errors (i.e. errors generated locally - dns lookup failure, connect timeout, etc.), previously these states were ignored.

Should work but I've been unable to do a full test. I don't have a UE registered with the PCF so right now I just get a 404 response from the PCF when trying to create the AppSessionContext. I also haven't tested the NRF/BSF resolution in the test app yet. I need to figure out how to get a UE to register with the PCF, or at least how to fake it, in order to do a full test of this test app.

[rjb1000]

We today identified a need to optionally specify a port number at the command line.

This will allow us to modify the network QoS of a particular application data flow rather than the PDU Session as a whole.

I have added this to the specification at the top of this issue.

[davidjwbbc]

Tested app with new command line options to specify protocol, UE port number, remote host IP and/or remote port number in order to narrow down the AppSessionContext.

For example:

• -a 12.34.56.78:12345 – AppSessionContext applies to all traffic to or from UE at IPv4 address 12.34.56.78 port 12345 (UDP, TCP or SCTP).
• -a 12.34.56.78:12345/tcp – AppSessionContext applies to all traffic to or from UE at IPv4 address 12.34.56.78 TCP port 12345
• -a 12.34.56.78 -r 98.76.54.32:80/tcp – AppSessionContext applies to TCP traffic between the UE at 12.34.56.78 and the HTTP server on 98.76.54.32 (TCP port 80).
• -a 12.34.56.78 -r :443/tcp – AppSessionContext applies to TCP traffic between the UE and any HTTPS server (TCP port 443).

Also fixed some bugs with the BSF discovery.

Have tested on the BBC R&D OpenStack VMs and found that the Open 5GS PCF requires MediaComponent.medType to be set to one of Audio, Video or Control, despite this parameter being specified as optional in TS 29.514. I will add an optional command line parameter which can take an enumerated type of audio, video, data, application, control, text, message or other to use as the media type. The media type parameter will be omitted altogether if not indicated on the command line (which currently fails with the Open5GS PCF, but may work with other implementations).

[davidjwbbc]

Command line option for media type added to the test app.

Current test application options (command help):

$ pcf-policyauthorization -h
Syntax: pcf-policyauthorization -h
        pcf-policyauthorization -a <UE-address> [-r <remote-address>] [-t <media-type>] [-d <bitrate>] [-D <bitrate>]
                                [-u <bitrate>] [-U <bitrate>] [-e <log-level>] [-l <file>] [-m <log-domains>]
                                ( -n <nrf-address> | -p <pcf-address> )

Options:
 -h          --help                 Show this help
 -a IP[:PORT][/PROTOCOL] --ue-address IP[:PORT][/PROTOCOL]
                                    The IP address, port and protocol for the UE, to create an AppSessionContext for.
 -r [IP][:PORT][/PROTOCOL] --remote-address [IP][:PORT][/PROTOCOL]
                                    The remote address, port and protocol, to create an AppSessionContext for.
 -t MEDIA-TYPE --media-type MEDIA-TYPE
                                    The media type to setup the PDU session for.
 -d BITRATE  --min-dl-bw BITRATE    The minimum download bit rate to limit the PDU session to.
 -D BITRATE  --max-dl-bw BITRATE    The maximum download bit rate to limit the PDU session to.
 -u BITRATE  --min-ul-bw BITRATE    The minimum upload bit rate to limit the PDU session to.
 -U BITRATE  --max-ul-bw BITRATE    The maximum upload bit rate to limit the PDU session to.
 -n IP:PORT  --nrf-address IP:PORT  The IP address and port number to contact the NRF at (PCF discovery).
 -p IP:PORT  --pcf-address IP:PORT  The IP address and port number to contact the PCF at (no discovery).

Open5GS Options:
 -e LEVEL    --log-level LEVEL      The logging level to use.
 -l FILE     --log-file FILE        The file to save the log to.
 -m DOMAINS  --domain-mask DOMAINS  The domains to limit the logging to.

Attributes:
  BITRATE    A bit rate in bits per second (can be a decimal fraction).
  DOMAINS    Comma separated list of logging domains to limit logging to.
  FILE       A path to a file in the local file system.
  IP         An IPv4 or IPv6 address.
  LEVEL      The minimum logging level to use: trace, debug, info, warn, error or crit.
  MEDIA-TYPE The media type for the flow: audio, video, data, application, control, text, message or other.
  PORT       A port number between 1 and 65535.
  PROTOCOL   An IP protocol to limit the flow selection to: tcp, udp, icmp or sctp.

If help is requested then the help message will be displayed and the command will exit without any further operation.
Otherwise the UE address must be given and one of either NRF address (discovery mode) and port or PCF address and port
(direct mode).

[davidjwbbc]

Moved the service consumer libraries and test tool into my fork of the rt-5gc-service-consumers repo, ready for a PR sometime next week.

Help text fixed (download => downlink & upload => uplink).

Added some more detail to the notification message output, still more to do.

Need to finish testing the PCF tool against Open5GS PCF.

After I've completed those tasks this should be ready for its first PR.

[davidjwbbc]

Have performed a successful test against a running Open5GS core when connecting directly to the PCF. The tool behaves as expected.

I made a few improvements to the log outputs as what was there already didn't let me track the application's state machine progress clearly.

Unfortunately Open5GS's PCF does not generate notification events, so this part of the code remains untested for now.

The tool occasionally exits with a single event object "leaked". I believe this is because the event processing thread gets cancelled before it has finished processing the current event and therefore never frees the event object. I think this may be solved by disabling the ability to cancel the thread while an event is being processed; this will result in any thread trying to cancel the events thread blocking until the current event processing has finished and the event object has been freed. I need to look up if Open5GS provides some nice cross-platform thread cancel state change macros/functions.

[davidjwbbc]

When testing with the NRF/BSF discovery I ran into a problem where the tool was unable to connect to the NRF. This did let me test the NRF lookup timeout, and implement the parts that were missing. I'll look into why connection to the NRF failed tomorrow.

[davidjwbbc]

Finished off the EventsNotification output functions. These can be tested once we have a PCF that generates events.

[davidjwbbc]

The NRF issue happened because our NRF wasn't listening on its external address.

Also needed to list the external addresses first in the PCF and BSF configuration files, and the local loopback addresses second, as this address order is the advertised order they are presented in. The Open5GS SBI library will only try the first IPv4 or IPv6 address it gets, so the first address needs to be the most accessible.

Having changed these configurations in our local VMs, the tool can successfully look up the PCF, subscribe to an AppSessionContext and then waits for notifications.

[davidjwbbc]

I think this is now ready for first release.