# Optimal User Association Strategy for Large-Scale IoT Sensor Networks with Mobility on Cloud RANs
## 3 Problem Formulation  
In this paper, we consider a C-RAN with densely deployed RRHs. We assume a fronthaul network with wired and possibly optical connections [22], and the IoT devices in the network are mobile. We assume a typical delay-tolerant IoT monitoring application, in which IoT devices transmit fixed-length, small-sized data (or packets) to their associated RRHs at a predefined lowest and constant rate, referred to as robust rate. The rate is robust, meaning that as long as an IoT device is located within the transmission range of its associated RRH, the rate is guaranteed regardless of the interference from nearby IoT transmitters if any. The specifics as to how the robust rate is guaranteed and what happens if not will be addressed shortly. We focus on the uplink transmission in this work; in this case, IoT devices upload their sensed readings or recorded measurement data to their associated RRHs. Time is assumed to be divided into fixed-length slots, and an IoT device can associate with a single RRH at each time slot. On the other hand, an RRH can associate with multiple IoT devices at the same time. To upload data, an IoT device needs to associate with an RRH. Once the association procedure is completed, the IoT device can transmit data to its serving/associated RRH each time slot. We assume that the proximity of an IoT device to nearby RRHs solely determines the possibility of communication and association. That is, if an IoT device \(i\) is within the transmission range of an RRH \(r\), \(i\) can associate and communicate with \(r\). Since RRHs are densely deployed, it is likely that some IoT devices are located within the coverage of multiple RRHs at the same time. We assume that IoT device \(i\) is capable of transmitting \(l_{i}\) number of data packets within a single time slot if the associated RRH has enough space in its buffer. For each time slot, information on the proximity between IoT devices and RRHs is collected and uploaded to BBU. It can be easily and quickly done via simple cooperation between RHHs and IoT devices. Each RRH \(r\) periodically broadcasts short pilot signals at a predefined transmit power, and those IoT devices, which are close enough to the RRH, will be informed that they are within the transmission range of RRH \(r\). Upon receiving the pilot signal from a nearby RRH, each IoT device calculates the downlink channel gain with the known transmit power. Although the wireless link is mostly asymmetric, each IoT device takes the gain as a prediction for the uplink, and uses the gain to check if it can transmit data at the robust rate in the uplink. If it can, the IoT device puts the RRH in the nearby-RRH list. However, the uplink transmission still can fail since the uplink channel gain is a prediction and the IoT devices are mobile. In such cases, the automatic repeat request function or its variants [26] can help to guarantee the successful data delivery. Once the pilot broadcasting period is over, IoT devices upload the list of nearby RRHs to BBU. After collecting such lists, BBU defines a proximity matrix, \(\textbf{N}=[n_{r,i}]_{\{r\in\mathcal{R},i\in\mathcal{I}\}}\), where \(n_{r,i}\) equal to 1 or 0 indicates RRH \(r\) has device \(i\) within its coverage or not, respectively; \(\mathcal{R}\) is the index set of RRHs; and \(\mathcal{I}\) is the index set of IoT devices. Hereinafter, **N** is assumed to be given to (or defined for) each optimization problem. RRHs are homogeneous, and, therefore, they have the same traffic processing capacity, \(c\), per a time slot (RRHs may also have another capacity constraint, limiting the number of users to associate with at the same time. In this work, however, we assume that such constraint is indirectly included in \(c\). For example, \(c\) can take the minimum value between the RRH's data processing capacity and the fronthaul link capacity.). That is, each RRH can process \(c\) number of data packets within each time slot.