-specific access class barring algorithm, shown in Figure 13.46 for mobile-originated data call type as an example, to evaluate whether the cell should be considered to be barred or not based on [8]. First the UE will evaluate if the received system information block (SIB) number 2 contains access class barring parameters for the initiated call setup cause or not. Then in case the access class barring parameters are included and the UE has all the valid access classes within the 11-15 range, as stored in the USIM, set to non-zero values, the UE considers the cell to be barred for the specific call setup cause. Next the UE will draw the random number, rand in Figure 13.46, uniformly distributed within the range 0 rand < 1 and in case the rand value is higher than or equal to the access class barring factor - parameter (ac-BarringFactor, delivered to the UE in SIB2) value - then the cell is considered to be barred. The barring time, Tbarring, is defined according to [8] and given in Eq. 13.1: (0.7 + 0.6* rand)* ac - Barring Time (13.1) With the service-specific access class barring it is possible to define barring probability depending on the call type, for example, mobile-originated data call can have different proba- bility for cell barring than mobile-terminated data call. By enabling the service-specific access class barring it is possible to limit the RRC connection setup rejections due to the RRC- connected users reaching maximum capacity and therefore avoid the PUSCH SINR collapse and huge signalling load. For dimensioning purposes the signalling amount per subscriber needs to be estimated and therefore the number of subscribers needs to be estimated. This can be done based on mobility LTE Small Cell Optimization MO-Data Setup SystemInformationBlockTyp e2 includes "AC barring parameter" set as ac-BarringForMO-Data draw a random number Wait for T303=(0.7+0.6*rand)* 'rand' : 0 rand < 1 ac-BarringTime rand < ac- Consider access to the cell as BarringFactor ? barred Access to the cell Figure 13.46 Service-specif