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 –
   99   100   101   102   103   104   105   106   107   108   109