Page 104 - Proceedings of the 2018 ITU Kaleidoscope
P. 104
2018 ITU Kaleidoscope Academic Conference
machine learning frameworks like: TensorFlow, Theano and Configuration Parameters
others. The main feature of this library is its simplicity, that Number o f users 9
allows to build complex neural network topologies with just User mobility RandomWayPointMobility
a few lines of code in a scikit-learn fashion, but keeping
at the same time the power of the neural network engine User speed 1.5 mps
that runs underneath. Using Keras, we built a feedforward Number o f applications 3
fully connected deep neural network composed of n hidden Application type UDP ConstantBitRate
layers in between the input layer whose dimension is given Packet size 1500B
by the cardinality kTk of the state t-uple, and the output
layer whose dimension is given by the cardinality kZk of Simulation Time 420 seconds
the action set. In order to integrate the two systems which
run respectively on Python and on C++ environments, we Table 1 – omnetpp.ini configuration.
implemented a mechanism to let them communicate using
text files. With reference to Fig. 2, the deep RL engine we are proposing, for this reason, we decided to realize a
waits for the generation of the files containing the current scenario with manageable number of users and applications
state of the system, once it receives the data it generates as in order to keep the training time of the DNN not too high.
output a text file which contains the action to execute on the In such a context, the state which defines the network can be
simulator. On the OMNeT++ side, we used an asynchronous expressed as follows:
timer which checks periodically for the action file availability,
as soon as the file is available, the simulator is able to read the
action code and change the server destination address for the
UEs that are running the application indicated in the action
thus emulating the data migration of the application from a
server to another. After the action execution, the RL agent
observes the reward obtained as the combination of several
performance indexes provided by the OMNeT++ simulator
by checking if the action performed has increased it or not.
The reward in this sense is used by the agent as a feedback
which helps it to understand if the action executed is a valid
choice in that specific system state. Figure 4 – OMNeT++/SimuLTE simulation scenario.
5. RESULTS
s =< (UE eNB1 , UE eNB2 , UE eNB3 ,
In this section, we present a preliminary scenario that we built eNB 1 app1 , eNB 1 app2 , eNB 1 app3 ,
to test the feasibility of the system where we only consider the eNB 2 app1 , eNB 2 app2 , eNB 2 app3 ,
presence of MEC servers without the possibility to use the 3 3 3
Cloud. Fig.4 shows the structure of the network composed of eNB app1 , eNB app2 , eNB app3 , (10)
three eNBs a set of devices with K = 9, a set of MEC servers Mec 1 app1 , Mec 1 app2 , Mec 1 app3 ,
with N = 3, a set of applications with M = 3, and a set of Mec 2 , Mec 2 , Mec 2
actions with Z = kNk · kMk where each action corresponds app1 app2 app3 ,
to the migration of an app taken from the Apps set to a server Mec 3 app1 , Mec 3 app2 , Mec 3 app3 ) >
taken from the MEC set. The datarate connection provided where:
by the cables which connect the eNBs is equal to 10 Gbps
except for the ones that connect the routers to the PGW where • UE eNB j represents the number of devices connected to
the datarate is 3 Mbps to emulate a traffic congestion, thus the j-th eNB;
creating a real scenario where we can test the performance of • eNB j represents the number of devices which are
appk
our algorithm. On the OMNeT++ side, it is possible to set running the k-th application in the j-th eNB;
several parameters for the simulation by using a configuration
file called omnetpp.ini; since the number of parameters to set • MEC i appk is a boolean flag that indicates if the i-th MEC
is very large, we synthesized them in a table. server is running the k-th application.
Table 1 shows the main parameters we set for the simulation, With respect to the reward, we first defined as a
we consider a total number of nine users who follow a random QoS performance index the percentage of received data
mobility motion pattern moving at speed equal to 1.5 mps corresponding to the i-th application app i as:
which is a fairly good approximation for the human walking
speed. With respect to the applications, we consider three D app i = Í Received T HR (11)
constant bit rate applications (CBR) that can be run by only Sent T HR · packetSize
one MEC server per time. As already said at the beginning of where the sum is extended to all the UEs that run the i-th
this section, our goal is to test the feasibility of the technique application. In particular, we evaluated the average of the
– 88 –