Skip to content

Usage

Jump to bottom
Lucas Baleeiro Dominato edited this page Sep 3, 2022 · 62 revisions

We have now different types of test for testing some kinds of behaviors from Core, that are show below.

  • Load test with queued UEs (are not sent at the same time):

    • One UE at a time. Each UE is separated by an interval of 10 seconds

    • This test simulates a GNB with multiple UEs

    • Configurations in config/config.yml. MSIN number will be incremented by one for each of the UEs (starting from the MSIN specified in the configuration file in the MSIN field)

    • You can use the command to test with number of UEs: $ ./app load-test -n <number of UEs that you want to test in load tests>

    • For example for testing with 3 UEs: $ ./app load-test -n 3

    • If registration of UEs are successful so you can test connectivity of UEs with internet as show below:

        $ ping google.com -I uetun1
  $ ping google.com -I uetun2
  $ ping google.com -I uetun3

  • Test UE registration, GNB registration and PDU session request:

    • You can use command to test: $ ./app ue
    • Configurations in config/config.yml.
    • If registration of UE is successful so you can visualize an interface in your host with name "uetun1". Then check connectivity of UE with internet as show below:
      $ ping google.com -I uetun1

  • Test GNB registration:

  • Test AMF availability:

    • This test checks AMF availability
    • This test generates a request per second to AMF to verify its availability
    • The timeout to wait the AMF response is 1 second
    • In logs, 0 means unavailability and 1 means availability in the respective second
    • We recommend putting a value of 3 in the logs in config/config.yml to only see test information
    • You can use the command to test: $ ./app amf-availability -t <duration of the test in seconds>

  • Test AMF responses per second:

    • This test works concurrently, and generate a batch of requests of GNB to AMF to verify its availability
    • We recommend putting a value of 3 in the logs in config/config.yml to only see test information
    • You can use the command to test: $ ./app amf-load-loop -n <number of requests per second> -t <duration of the test in seconds>

  • Test latency of UE registration:

    • This test will create an queue of UE registration requests (using the same configuration information specified in the configuration file) and calculate the latency for each request
    • Each request starts after the previous one ends
    • Timeout is set to 10 000 ms for UE registration
    • Configurations in config/config.yml
    • We recommend putting a value of 3 in the logs in config/config.yml to only see test information
    • You can use the command to test: $ ./app ue-latency-interval -n <number of requests>

Additional comments

To generate simultaneous registration requests and PDU Session Requests you can try to create multiple instances of the tester using containers, for example.

For tests, you have to include IMSI UEs in web UI of test core as show below.

Example: if you want to test 10 UEs you have to included IMSI UE range to 2089300000001 from 2089300000010 in web UI. You can change other values in config/config.yml for example opc,k, msin, hplmn as you interest and used them in testing.

Example: if you want to test 2 UEs you have to include imsi 2089300000001 and 2089300000002 in web UI of test core.

Clone this wiki locally