# Modeling Network-Controlled Device-to-Device Communications in SimuLTE
## 5 Modeling Device-to-Device Communications in SimuLTE
### Modifying Protocol Layers to Accommodate D2D Data Processing  
As discussed in Section 2, D2D communications traverse all the layers of the LTE protocol stack, top-down in transmission and bottom-up in reception. This allowed us to reuse most of the modeling done for traditional cellular transmissions exploiting inheritance and the modularity of OMNeT++. Thus, for each protocol layer requiring additional D2D-specific operations, we modeled extended versions of the relative submodules, as shown in Figure 9 for the MAC layer. In this case, LteMacUeD2D adds, for example, support for H-ARQ retransmissions for D2D flows and other functionalities described in the following, whereas LteMacEnbD2D provides handling of D2D connections during the resource allocation. We first describe the few modifications required to allow a correct traversal of the protocol stack for transmission/reception of D2D data, and then discuss the more complex issue of mode switching (MS), i.e., what happens when a P2P D2D flow is switched from the SL to the infrastructure path or vice versa. With reference to Figure 10, IP datagrams arriving at the PDCP of the sender UE are associated to a data flow identified by a 4-tuple composed by source/destination IP address and source/destination port. Moreover, they are assigned a direction, which can be UL or the newly added P2P and P2 MP D2D. This way, data having the same 4-tuple, but different flow directions, will belong to different, independent data flows, allowing lower layers to treat them accordingly. In fact, the flow direction for the same source-destination pair can be changed dynamically because of mode switching, discussed later. Regarding P2 MP D2D communications, our implementation maps multicast IP datagrams (i.e.,  
Figure 8: Allocation map (**left**); and schedule list (**right**). those with a multicast IP destination address) to the P2 MP D2D flow direction. The IP datagram is also assigned a multicast group ID by querying the Binder. Finally, the PDCP layer attaches to the resulting PDCP PDU the node ID (or the group ID) of the intended receiver(s), which will be used by lower layers. The RLC layer has no specific functionalities connected to the top-down traversal of D2D data. The latter are stored in RLC transmission buffers just like UL data. However, the RLC plays a pivotal role during MS, as we discuss below. As shown in Section 2, the MAC layer of the UE must notify the eNB when new data are available for transmission, by sending it a BSR. We have added to the BSR a specific field to distinguish among UL, P2P D2D, and P2 MP D2D BSRs. The eNB will use this information to issue transmission grants for the correct direction. Other than this, the operation at the MAC layer of a D2D connection are the same as for UL transmissions, with the only exception that the functions and data structures to handle H-ARQ processes are disabled with P2 MP D2D transmissions. Let us discuss now what happens at the receiver side of a D2D connection, i.e., the bottom-up traversal of the LTE protocol stack for D2D data. The main difference lies within the MAC layer, whereas the RLC and PDCP layers are unaffected (the same operations required for non-D2D data are performed with D2D data as well). As far as P2 MP D2D data are concerned, MAC-layer processing is a simplified version of the one for non-D2D data, the simplification being that no H-ARQ feedback is generated. In our modeling, P2P D2D communications are instead acknowledged at the MAC layer, i.e.,  
Figure 10: Processing of upper-layer packets at the PDCP layer. Figure 9: Example of inheritance of NED structure and C++ class for D2D-specific modules. the receiver sends H-ARQ feedbacks (ACKs/NACKs) upon reception of MAC PDUs.