# NB-IoT for D2D-Enhanced Content Uploading with Social Trustworthiness in 5G Systems
## 4 Cooperative Multihop D2D-Based Data Uploading
In fact, if a timeout is enough to identify a packet dropping, a corrupted packet will first have to reach the eNodeB passing through all the intermediate nodes before the system is aware of data corruption (we assume the eNodeB will be able to identify data corruption). We imagine a possible way for the eNodeB (eNB) to detect a packet to be dropped (when a _type B_ malicious node is present). A straightforward solution is to rely on the acknowledgment message (ACK) that has to be sent to the UE once the packet has been received by the network. In this case, once the UE reaches the maximum number of re-transmitted Protocal Data Units (PDUs), a radio link failure (RLF) is triggered and sent over the signal radio bearers (SRBs). Since in our work we assume that malicious nodes of type B drop the packets, we think that the best way to proceed is for the eNB to send the ACKs directly to each UE of the chain. Then, if a RLF is experienced (due to no ACK being received, i.e., the gateway does not forward anything), this is triggered separately by each UE towards the eNB. The identification of a corrupted packet is a bit more complex. This may be done through the checksum of the packets (i.e., at the higher layer of the protocol stack) or, alternatively, through the integrity protection that at the moment is done for the SRBs. We are aware that integrity protection is not present for the data radio bearer (DRBs), but with the ongoing standardization of 5G New Radio (NR) and LTE Evolution (LTE-Evo) we may expect this kind of enhancements or new features. Other solutions may be applied for detecting a not correct node behavior, but this is out of the scope of this work. To cope with the threats coming from the malicious nodes, when defining the cooperative topologies, countermeasures must be considered to offer rational users the possibility to filter out untrusted users, block the unsecure links and avoid unsuccessful opportunistic hop-by-hop D2D interactions, as sketched in Figure 1. The solution we propose for effective and trusted D2D-based data uploading can be summarized as follows:  
**Channel quality indicator (CQI) collection:** the eNodeB collects the CQI values from each unit of UE, relevant to the direct links with all its neighbors and to the uplink toward the eNodeB. **Virtual resource allocation:** the eNodeB considers the situation where the single UE devices are transmitting in unicast over their uplink and computes the radio resources according to the scheduling policy. The so-computed radio resources are considered as \"virtual\" since they are not yet allocated to the UE because the UE may actually form a cooperative multihop topology (i.e., a coalition). Whenever a coalition is formed, the pool of \"virtual\" resources of all the UE in the coalition will be assigned to the respective gateway. **Cooperative coalition formation:** in this step a set of stable coalitions are determined where for each coalition the roles for the nodes in the cooperative D2D-based data uploading are defined, as well as the routing path for the data from each node. To produce stable coalitions, the eNodeB will rely on a game theoretic model such as the one defined in [10]. A classic merge and split algorithm is implemented where the device preference to join or leave a coalition is based on the estimated data uploading time. In the coalition formation algorithm two main constraints are considered: (1) two consecutive nodes in the data routing path built on a cooperative coalition must be in coverage for a D2D link (otherwise the data routing would fail); and (2) the devices in the cooperative coalitions should guarantee a minimum value of trust which we define as _feasibility threshold FT_. Indeed, we consider a coalition as _not feasible_ if at least one link \(i\to j\) in the topology does not meet the constraint:\[pt_{i,j}\cdot d_{i,j}\geq FT \tag{1}\]  
where \(pt_{i,j}\rightarrow[0,1]\) is the _player trust_ that player \(i\) (a device in a coalition) associates to player \(j\) (see Section 5).