# An Improved Radio Resource Management with Carrier Aggregation in LTE Advanced
## 3 System Model
### Problem Formulation
The probability of exceeding this value must be equal or less than the probability of packet loss. Therefore, the QoS requirement of user \(i\) is defined as  
\[Pr\big{\{}D_{i,j}>\tau_{i}\big{\}}\leq\delta_{i} \tag{8}\]  
Table 3 shows the delay threshold values with corresponding priority levels for different applications. The lower the priority level, the higher the priority in the congested queue such as here where the conversational voice has the highest priority. If queue congestion happens, data packets of the lowest application priority would be discarded first. As the real-life wireless environment is affected by various noise and interference, errors occur in large scale while receiving the data packets. Therefore, a two-state Markov chain model is widely used by previous researchers [30; 31] to assess the performance accurately. This paper calculates the probability of packet loss \(\delta_{i}\) by this Markov model with a closed-form expression [23]. Instead of modeling the queue, the model in [23] considers packet delay which has an advantage that a packet can be dropped, if the packet delay exceeds the threshold value. It is complicated to formulate the expression of the probability of packet loss in terms of its basic parameters. For having a simple and meaningful interpretation, the expression has been simplified by making approximations and restricting the parameter values. According to the Markov model, a success state has small error probability and a failure state has large error probability. This paper considers the success state as a usable system when packets can be transmitted successfully. The error probability, maximum delay, and the probability from failure state to success state are considered in the simplified expression of small error probability scenario. The equation is described in (9). \[\delta_{i}=\epsilon_{i}(1-P_{i})^{\tau_{i}} \tag{9}\]  
where \(\epsilon_{i}\) is the error probability and \(P_{i}\) is the probability from failure state to success state of user \(i\). The error probability \(\epsilon_{i}\) assumed to be small value whereas \(P_{i}\) should be larger than \(\epsilon_{i}\) in success state to make the system usable. The probability of packet loss \(\delta_{i}\) largely depends on the queue length and the delay threshold value. The model in [23] shows that \(\delta_{i}\) can be calculated accurately by considering constant values of \(\epsilon_{i}\) and \(P_{i}\) with varying the delay threshold values. Therefore, for success state, this \begin{table}
\begin{tabular}{c c c} \hline \hline
**Application** & **Delay Threshold in ms** & **Priority Level** \\ \hline Real time gaming & 50 & 3 \\ Live video streaming & 100 & 7 \\ Conversational voice & 100 & 2 \\ HTTP, FTP & 300 & 6 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Delay threshold value for different applications [29]. paper assumes that \(\varepsilon_{i}\approx 0.01\), \(P_{i}\approx 0.1\) and the maximum delay is the delay threshold \(\tau_{i}\) for user \(i\) based on their applications (Table 3). The probability of packet loss \(\delta_{i}\) decreases drastically when \((1-P_{i})\) decreases, especially when delay threshold \(\tau_{i}\) is large with a constant value of \(\varepsilon_{i}\). On the other hand, \(\delta_{i}\) increases if the delay threshold \(\tau_{i}\) is not large enough when the errors are likely to occur. If the packet transmission fails, the packet is retransmitted until it reaches to a delay threshold. After exceeding the threshold value, the packet will be discarded and the next packet transmission will start. The error probability \(\varepsilon_{i}\) is large and \(P_{i}\) is relatively smaller than \(\varepsilon_{i}\) in failure state with large error probability. Therefore, the probability of packet loss in the failure state can be written as  
\[\delta_{i}\approx\varepsilon_{i}\approx 1 \tag{10}\]  
This equation indicates that the outcome of the Equation (7) will be very low. Thus, there will be very low chance that the scheduler allocates any RB to the user.