DRX LTE Vs Latency

Descargar como pptx, pdf o txt
Descargar como pptx, pdf o txt
Está en la página 1de 10

PÍLDORA #7:

DRX & LATENCIA

Astellia confidential & proprietary / For information purposes only


Astellia confidential & proprietary / For information purposes only
DRX CONCEPTOS TEÓRICOS
DOWNLINK
• DRX is a technology in which a UE can switch between active and sleep states. When the UE needs to receive
downlink (DL) data or signaling, the UE turns on its receiver and enters the active state. In other situations, the UE
turns off its receiver and enters the sleep state to reduce power consumption.

• DRX for UEs in connected mode is provided by LBFD-002017 DRX. DRX for UEs in idle mode is different, which is
described in Idle Mode Management Feature Parameter Description.

• Unless otherwise stated, "DRX" in this document refers to DRX for UEs in connected mode.

Astellia confidential & proprietary / For information purposes only 2


ANÁLISIS XCAP 1/6
Punto de partida:
PAYLOAD=1450
Buenas condiciones RF
Secuencia 1000ms

Astellia confidential & proprietary / For information purposes only 3


ANÁLISIS XCAP 2/6

Fijándonos en el contenido de los dos LOGs de información resaltados arriba. En el LOG LTE LL1 PDCCH
Decoding Results, vemos como el eNB le está enviado al UE a través del PDCCH información de control
de tipo: DCI 2A (dedicado para indicar al UE que tiene información scheduleada en el PDSCH):

Astellia confidential & proprietary / For information purposes only 4


ANÁLISIS XCAP 3/6
Si ahora vamos al log LTE PDSCH Demapper Configuration, vemos que dentro de la misma SFN y Subframe,
el UE está leyendo la información:

Podemos asumir que nuestro ECHO REPLY,


lo tenemos en la SFN=279/Subframe=1.
Sabemos que el RTT de este PING es de
72ms, aproximadamente 7SFN + 2
subframes, ya que 1 SFN=10ms y
1Subframe=1ms.

Astellia confidential & proprietary / For information purposes only 5


ANÁLISIS XCAP 4/6
Bien, dado que el SFN de llegada ha sido el 279 y subframe1, el SFN en el que se envió el ECHO REQUEST tuvo
que ser aproximadamente la 271 la subtrama 9 (72ms antes). Si ahora, vemos como se ha comportado el DRX
durante esta ventana temporal de SFN, tenemos:

Astellia confidential & proprietary / For information purposes only 6


ANÁLISIS XCAP 5/6

Si os fijais, precisamente el primer PDCCH que decodifica el UE tras pasar de SLEEP a ACTIVE es el del SFN=276:

Astellia confidential & proprietary / For information purposes only 7


ANÁLISIS XCAP 6/6
Este comportamiento no se ha visto en los PING del mismo tipo y mismas condiciones RF con periodicidad de
200ms ya que no llegamos a entrar en MODO SLEEP al lanzar iniciar en todas las SFN el timer de inactividad
configurado a 100ms. Fíjate en el ejemplo que te pongo a continuación para un PING de 1450B y buenas
condiciones radio:

Ventana temporal para este PING. Ni


se parte ni se entra en SLEEP nunca.

Astellia confidential & proprietary / For information purposes only 8


ANALISIS CONTADORES
• L.Cdrx.Enter.Num
• L.Cdrx.Exit.Num
• L.Traffic.User.Cdrx.Avg
• L.Cdrx.Active.TtiNum
• L.Cdrx.Sleep.TtiNum
• L.Voip.Cdrx.Active.TtiNum
• L.Voip.Cdrx.Sleep.TtiNum

Astellia confidential & proprietary / For information purposes only 9


ANEXO

Astellia confidential & proprietary / For information purposes only


Astellia confidential & proprietary / For information purposes only

También podría gustarte