# User Association Performance Trade-Offs in Integrated RF/mmWave/THz Communications
## 5 Algorithm Description  
Our algorithm aims to distribute users evenly among base stations to balance the network load among all three frequency bands. Any user association algorithm that is based on simply taking the max SINR would not provide a fair load distribution. It skews associations towards the RF band, which often has higher SINR. It also does not consider load balancing between base stations, and it is prone to ping-pong handovers, as SINR can fluctuate. Combined SINR/Load Balancing user association algorithms take into account both the channel conditions (SINR) and queue length (BS load) when making user association decisions. This allows it to find a good balance between SINR and load distribution. However, they still consider the absolute SINR values directly, without any normalization across bands. This ends up skewing the results, as it does not properly address the bias towards RF bands inherent in the raw SINR values. Normalization or randomized selection is needed. In addition, mmW and THz bands are affected by blockage, but the RF band is not. If we prioritize users based on the future expected blockage probability, since RF has no blockage, the results will be skewed too. The algorithm may still favor associating users to RF BSs if the blockage probability is not considered for RF. To address this, one approach is the following:  
* Incorporate a blockage probability model for each band (mmW/THz higher than RF). * Calculate an expected SINR value that factors in the blockage probability. For example: Expected SINR = Raw SINR \(\times\) (1 \(-\) Blockage Probability)
* Use the expected SINR values (instead of raw SINR) when calculating metrics. However, even with incorporating an expected SINR that factors in the blockage probability, the results may still skew towards RF associations since the blockage probability for RF is effectively zero. A better algorithm would need to normalize/equalize the SINR across bands in a more fundamental way before associating users. A few approaches:  
1. Normalize raw SINR values across bands to a common scale (e.g., 0-1) before any metric calculation. 2. Calculate a score for each user-BS pair that considers both the SINR and blockage risk, rather than just the expected SINR. For example: Score = NormSINR/(1 \(+\) BlockageRisk)
3. Assign users randomly to BSs in different bands based on weighted probabilities, where weights are adjusted based on NormSINR and BlockageRisk. 4 Explicitly require a minimum number/percentage of users to associate to each band to enforce balanced associations. * Introduce an additional \"band preference\" or reward factor for mmW/THz that compensates for their higher risk, to make the bands more competitive against RF. Here, the key challenge is finding a way to equalize the impact of SINR and reliability across bands before associating users, rather than relying on the expected SINR alone. Normalization and introducing separate scoring factors seems needed. We need to bear in mind that not all users in 6G systems have the same needs--some prioritize high data rates, others reliability, latency, etc. This affects which frequency bands may be preferable for different users. Also, this exploits multi-band diversity and dynamically optimizes associations under different channel conditions. 1. The algorithm should categorize users based on their profile/preferences: * High-data-rate users prefer THz. * Low-latency users prefer mmWave. * Users requiring reliable connectivity prefer RF. 2. Then, prioritize associating users to bands that best match their needs: * Higher weight/preference given to preferred bands in scoring. * Explicit cap on preferred band's user limits. 3. User profiling could consider: * Application types (video, voice, and IoT sensors). * Device capabilities. * Service-level agreements. * The profile is learned/updated over time based on user behavior. Here are the steps to implement the multi-band user association algorithm based on the problem statement:  
1.