The manual contains a brief overview of the project source code. The RAN simulator is coded in C/C++
and the controller uses Java
. We start by describing sequence of procedures that take place in the RAN simulator (see Fig. 1).
Fig. 1: Life cycle of simulated UE(s)
Following are the steps:
-
Authentication: In this step, exchange of authentication messages takes place between RAN and the MME via default switch using
UDP
. Also, the MME communicates with HSS which in turn queries theMySql
database usingJDBC
driver. -
Tunnel setup: After successful authentication, the MME initiates tunnel setup procedure. During this step, exchange of control messages take place among MME, SGW-C and PGW-C via Java object calls. Besides,
OpenFlow
rules are installed into the concerned data plane switches, thus, establishing the tunnel. -
Data transfer: This step is optional. During this step,
iperf3
at RAN generates data in the form ofTCP
traffic which flows through the EPC to the sink. -
Detach: During this step, the control applications (MME, SGW-C and PGW-C) delete the
OpenFlow
rules from the respective data plane switches, thus disrupting the tunnel.
RAN:
RAN is a multi-threaded simulator in which each thread simulates the life cycle of a UE. Each iteration of the threads generates a new UE which follows the steps shown in Fig. 1. If sending data, each UE thread uses iperf3 client to connect with a corresponding iperf3 server running on the Sink (see Fig. 2). The structure of the RAN code has been depicted in Fig. 3.
Fig. 2: Overview of the setup
- The main file in the RAN simulator is ran.cpp which is responsible for creating threads for each UE and invoking the procedures for each UE.
- The file ue.cpp abstracts out all the functionalities associated with a UE (Attach, Tunnel setup, Data transfer, Detach, etc). Each thread created by ran.cpp instantiates a UE (ue.cpp) object. Each UE object exploits the methods associated with it to perform various LTE procedures.
- Further, each UE object instantiates a Client (client.cpp) object which contains all socket level attributes and methods. These methods are used by UE object to send/receive messages during various LTE procedures.
- The file utils.cpp contains various utility functions such as hash MAC (Message Authentication Code), Encryption/Decryption, etc.
Fig. 3: Code structure of RAN simulator
Controller:
The controller code contains 3 floodlight modules namely MME.java, SGW.java and PGW.java. Apart from these, other associated files are HSS.java, Utils.java and Constants.java.
- MME.java is the floodlight module which is responsible for interacting with the RAN simulator via the default switch. It contains various cases depending on the type of message received from RAN and a corresponding action. It delegates various events to SGW.java and is responsible for installing/uninstalling
OpenFlow
rules into the default switch. Besides, it also responsible for communicating with HSS.java. - SGW.java performs the control plane functionalities of SGW including installing/uninstalling
OpenFlow
rules into the SGW switch. It also acts as an interface between MME.java and PGW.java. - PGW.java performs the control plane functionalities of PGW including installing/uninstalling
OpenFlow
rules into the PGW switch.
The cipher and integrity checks are not implemented as they should be. Instead, we have just included the cost of these operations by calling their specific methods on dummy data. We faced problems while performing the cipher/integrity checks between C/C++ (for RAN
) and Java (for Controller
).