5glab implementation notes

For this part, each subdirectory of the "src" directory will be explained.

1. Apache2-HTTP2-Python3

This directory contains a Dockerfile as explained in 5glab Architecture doc

The goal of this Dockerfile is providing a base image for other images that will need a stack with Apache2, HTTP2 and Python3.

Basically, it's the server configuration. The Apache configuration is the basic one with HTTPS ad HTTP2 enabled.

It also enables mod_wsgi in order for Apache to serve Python.

Concerning HTTPS, a self signed certificate is generated thanks to OpenSSL. Here is the following command used to generate the certificate :

1
2
3
openssl req -new -x509 -days 365 -nodes -out /etc/ssl/localcerts/apache.pem -keyout /etc/ssl/localcerts/apache.key \
    -subj "/C=FR/ST=Chatillon/L=Chatillon/O=Orange/OU=5gLab/CN=whatever.com" && \
    chmod 600 /etc/ssl/localcerts/apache*

The chmod is mandatory to allow Apache2 using it.

2. NRF

This directory represents the NRF. It contains all its services.

  • NRF Callback Handler

This service doesn't exist in the NRF

It's a temporary application that allows to view notifications flow of the NRF without having a real client.

It's a Django application created with the following commands :

1
2
django-admin startproject callback_handler
django-admin startapp handler

Architecture of the application :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
│   000-default.conf
│   displayNotifications.js
│   Dockerfile
│   index.html
│   notifications.json
│
└───callback_handler
    │   manage.py
    │   requirements.txt
    │
    ├───handler
    │      admin.py
    │      apps.py
    │      models.py
    │      tests.py
    │      urls.py
    │      views.py
    │      __init__.py
    │                 
    └───project_settings
           settings.py
           urls.py
           wsgi.py
           __init__.py

Here we have the architecture generated by Django except the first five files.

The way to create a Django application correctly is discussed in the "Django application Workflow" file.

  • NRF Database

    This directory contains a Dockerfile as explained in 5glab Architecture doc

The goal of this Dockerfile is providing a MongoDB database containerized in a Docker container.

This MongoDB database will store the data of the NRF (NfProfiles and subscriptions)

On the internet, there are already plenty of Dockerfile for MongoDB but they are way to complex to understand and embed useless features. So a simple Dockerfile has been done. There are some comments to understand how to make the image because it's a bit tricky.

  • NRF Discovery Webapp

    This application implements the discovery service of the NRF

It's a Django application created with the following commands :

1
2
django-admin startproject nrf_discovery_api
django-admin startapp disc_api

Architecture of the application :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
│   000-default.conf
│   Dockerfile
│
└───nrf_discovery_api
    │   manage.py
    │   requirements.txt
    │
    ├───disc_api
    │      apps.py
    │      models.py
    │      urls.py
    │      views.py
    │      __init__.py
    │
    └───project_settings
           settings.py
           urls.py
           wsgi.py
           __init__.py

Here we have the architecture generated by Django except the first five files.

The way to create a Django application correctly is discussed in the "Adding a service" file.

The logical part of the application is contained in the "views.py" file.

  • NRF Management Webapp

    This application implements the Management service of the NRF

It's a Django application created with the following commands :

1
2
django-admin startproject nrf_management_api
django-admin startapp nfm_api

Architecture of the application :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
│   000-default.conf
│   Dockerfile
│   README.md
│
└───nrf_management_api
    │   manage.py
    │   requirements.txt
    │
    ├───nfm_api
    │      admin.py
    │      apps.py
    │      models.py
    │      nfInstanceViews.py
    │      serializers.py
    │      subscriptionViews.py
    │      tests.py
    │      urls.py
    │      utils.py
    │      __init__.py
    │
    └───project_settings
           settings.py
           urls.py
           wsgi.py
           __init__.py

The way to create a Django application correctly is discussed in the "Adding a service" file.

The logical part dealing with CRUD on NFInstances is included into "nfInstancesViews.py" file. The logical part dealing with subscriptions is included into "subscriptionsViews.py" file.

The following PyPi packages are used in this application :

  • Django (latest)
  • Django Cors Headers (latest)
  • Django REST Framework (latest)
  • Pymongo (latest)
  • Pytz (latest)

These packages are explained in the python_packages.md file

3. Client

This directory contains a Dockerfile to build an automated test client during deployment and several files to launch the NfApiTester tool

Here is the architecture of this directory :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
│   Dockerfile
│   Http2Client.py
│   payload.json
│   result.json
│   testClient.py
│   testPayload.json
│   TS29518_Namf_Communication.yaml
│   TS29571_CommonData.yaml
│
├───nfApiTester
│   │   NfApiTester.py
│   │   OpenApiParser.py
│   │   TS29510_Nnrf_NFManagement.yaml

Http2Client.py is a class to instantiate an HTTP/2 Client based on curl. Obviously, curl is required in order to make requests. Please read "Prerequisites for local development" in order to install curl on Linux/Windows.

nfApiTester directory contains the tool NfApiTester.py and OpenApiParser.py file. OpenApiParser.py is a class which processes OpenAPI files.

NfApiTester.py must be launched with the following command line in a terminal :

1
python NfApiTester.py

OR

1
python3 NfApiTester.py

A video tutorial can be found in the resources directory of 5glab project.

4. Mitmproxy

Mitmproxy is a MITM tool used to analyze and inspect HTTP requests. It works with HTTP/2 (only ALPN, ie over HTTPS) and HTTP/1.1 obviously. To start the MITM, the following command must be launched :

1
docker start -i mitmproxy

It will launch an interactive interface in the shell where the command was launched. See the video about Deploying in the "resources" directory.

5. OAuth Authorization

The OAuth Authorization directory provides a Spring Boot application which play the role of an Authorization Server. In other words, it will generate tokens using Client Credentials Grant. It means that credentials must be sent to the authorization server in order to get a token.

The application will sign each token with the "nrf-auth.jks" private key. The server can also verify token validity.

The main endpoints are :

/oauth/token (getting a token) /oauth/check_token (verifying a token)

The project contains a JavaDoc that you can open in your favourite browser.

An example of activating token on resource server can be found in views.py from nf discovery webapp.

6. Swagger

Dockerfile for Swagger and OAS files

Architecture of the directory :

1
2
3
4
5
    changeJson.py
    Dockerfile
    nrfDiscoveryApi.json
    nrfManagementApi.json
    README.md

This directory contains a Dockerfile to containerize Swagger.

It also contains the OAS files for each NF in JSON or YAML format. YAML format is preferred since 3GPP use it to write OAS files.

There is also a python script (changeJson.py) which replace href server in OAS files in order to query the right server when using Swagger.