¿Por qué el esquema de restricción de clase de acceso (ACB) en LTE emplea dos parámetros: ac-BarringFacor y ac-BarringTime?

La importancia de ac-BarringFactor es: si el número aleatorio extraído por el UE es inferior a este valor, se permite el acceso. De lo contrario, el acceso está bloqueado. Los valores se interpretan en el rango [0,1): p00 = 0, p05 = 0.05, p10 = 0.10,…, p95 = 0.95. Los valores distintos de p00 solo se pueden establecer si todos los bits del ac-BarringForSpecialAC correspondiente se establecen en 0.

Ahora allí, considerando que ha prohibido un AC, ahora, ¿cómo va a deshacer esa clase y, en particular, informar al UE de este cambio en la matriz de restricción?

Entonces aquí está la solución,

Si el acceso está bloqueado y los temporizadores T302 y “Tbarring” no se están ejecutando:

  • dibuje un número aleatorio ‘rand’ que se distribuya uniformemente en el rango 0 ≤ rand <1
  • iniciar el temporizador “Tbarring” con el valor del temporizador calculado de la siguiente manera, utilizando el tiempo de restricción de CA incluido en el “parámetro de restricción de CA”:

“Tbarring” = (0.7+ 0.6 * rand) * ac-BarringTime

Ahora deje que el temporizador “TBarring” siga funcionando hasta que caduque.

Para el siguiente intento de acceso, nuevamente se debe repetir el conjunto de pasos estándar. Para el conjunto específico de pasos realizados, es posible que desee pasar por 3GPP TS 36.331 (me referí a la versión 13.1.0, versión 13):

Propuse esta pregunta y quiero poner algo más

En LTE, el esquema de restricción de clase de acceso (ACB) emplea dos parámetros: ac-BarringFacor y ac-BarringTime.

“Rand” es generado por el UE. si Rand

Dado que ac-BarringFacor es suficiente para lograr la restricción de acceso, ¿por qué necesitamos ac-BarringTime?