# Modeling Network-Controlled Device-to-Device Communications in SimuLTE
## 4 Overview of the SimuLTE Architecture
### Resource Allocation at the eNB  
Resource allocation is done at the MAC layer of the eNB. Our model of the latter contains two classes, namely LteSchedulerEnbDI and LteSchedulerEnbUI, which perform the scheduling of DL and UL frequency resources to backlogged UEs on each TTI and are represented in Figure 7.  
Considering the DL direction, the LteSchedulerEnbDI function first checks whether some MAC PDUs in the H-ARQ buffers are awaiting retransmission through the troschedule() function and allocates resources to them. Then, the schedule() function allocates resources for new data transmissions. Recall that the data that will form MAC PDUs are fetched from the eNB's RLC buffer. Thus, the LteSchedulerEnbDI should query the RLC module whenever it needs to know the amount of buffered data, i.e., at least once per TTI and for all the UEs under the control of the eNB. This would require \(O(N)\) OMNeT++ messages per TTI to be exchanged between the MAC and RLC modules. To abate this overhead, we endowed the eNB MAC module with virtual RLC buffers (VRBs), storing the length of each UE's RLC buffers directly in the MAC. VRBs are updated only when a new RLC SDU is received from the PDCP, in which case the RLC module send one OMNeT++ message to the MAC indicating the length of that SDU (and this is unavoidable), and upon transmission of a MAC PDU, by subtracting the relevant amount of dequeued bytes at the RLC. All the lookups of the UE's RLC buffers required by the LteSchedulerEnbDI on each TTI are instead done on the VRBs, which saves a considerable overhead. The LteSchedulerEnbDI builds a set of active UEs, i.e., those with a non-empty RLC buffer, and runs a scheduling policy that sorts them according to a specified policy. Note that the scheduling policy is a separate plugin entity: this allows SimuLTE to implement several policies that can be used interchangeably, e.g., MaxC/1 or Proportional Fair. Then, the scheduler scans the sorted list and allocates a number of RBs to the UEs depending on its CQI and the length of its VRB. The operation terminates when the list is empty or there are no more available RBs. At the end,  
Figure 7: Scheduling operations.  
the scheduler obtains an allocation map (described previously) and a schedule list, shown in Figure 8. The latter indicates how many bytes are served for each UE and is used to request the RLC module to send down one RLC PDU of the given size for each UE. The MAC module forms the TB by adding its header to such RLC PDU and sends it to the PHY module.  
UL scheduling mirrors the above checklist, with some peculiar differences. The first function called by the LteSchedulerEnbUI is the raschedule(), which allocates one RB to UEs that performed a successful RAC request during the last TTI, which the latter normally use to transmit their BSR (see Figure 2). Moreover, the eNB maintains BSR buffers, which store the estimated backlog of UEs, and are updated on reception of new BSRs from the UEs and decreased on reception of traffic from UEs. The alert reader will note that BSR buffers play exactly the same role as VRBs in the DL, i.e., that of enabling the eNB MAC to estimate the backlog for a UE. In fact, we exploited this to make scheduling policies independent of the scheduling direction: the same scheduling policy can work seamlessly for both the UL and the DL.  
Finally, we observe that, in the UL, the scheduling operation consists in sending a scheduling grant to each UE in the list. The latter is a control packet indicating how many bytes it can transmit, using which RBs.