capÍtulo 7. anÁlisis de degradaciones 7.1...

Diseño y parametrización de una estación de telefonía móvil 2G/3G. Análisis de degradaciones.

Escuela Superior de Ingenieros - Universidad de Sevilla Página 183

CAPÍTULO 7. ANÁLISIS DE DEGRADACIONES

En este capítulo trataremos de explicar los pasos a seguir para hacer un análisis de las

posibles degradaciones sufridas por una estación y la optimización necesaria para dicha

estación y su zona de influencia. Por una parte, hay una serie de problemas que afectan por

igual a las estaciones de 2G y a las de 3G. Y por otra, cada tipo de problema debe ser analizado

independientemente en 2G y en 3G. Es necesario resaltar que muchos de los problemas y

soluciones están relacionados entre sí.

7.1 PROBLEMAS GENÉRICOS

7.1.1 ANÁLISIS DE ALARMAS

En muchas ocasiones, las alarmas que devuelve una estación pueden determinar el

problema de dicha estación.

Entre las alarmas más destacadas suelen estar las de transmisión, fallos de

alimentación y alarmas de hardware.

Figura 7.1.1. Alarmas en nodo B 3G por transmisión



Figura 7.1.2. Alarmas en estación 2G

7.1.2 INDISPONIBILIDAD

La indisponibilidad es una de las causas que provocan degradaciones en los KPIs, no

sólo en la propia estación, sino en toda la zona de influencia. La indisponibilidad puede

deberse principalmente a dos causas:

Transmisión

Alimentación

La determinación de la causa de la indisponibilidad se demuestra mediante las alarmas

de la estación, tal y como se ha observado en el punto anterior. Existen contadores de

indisponibilidad, lo que permiten conocer el tiempo que una estación ha estado indisponible.

Estas indisponibilidades pueden ser permanentes (la estación se cae durante un período de

tiempo prolongado) o discontinuas (la estación sufre caídas intermitentes):

Figura 7.1.3. Indisponibilidades discontinuas en un nodo B



Figura 7.1.4. Indisponibilidad permanente en una estación. Estación caída.

7.1.3 SOBREALCANCE/SUBALCANCE

El sobrealcance/subalcance ya ha sido analizado en los puntos anteriores. Una de las

causas que provoca este problema de diseño es, entre otras degradaciones, un % de llamadas

caídas excesivamente alto. Sin embargo, vamos a analizar cómo mitigar sus efectos.

Con respecto al subalcance, las acciones a tomar serán las siguientes:

Disminución del downtilt de la estación (aumento de tilt o uptilt)

Ajustes en parametrización.

TABLA PARÁMETRO 900 COSITE

BTS rx_lev_access_min 6 (-104dBm)

BTS cell_reselect_offset 9 (18dB)

Figura 7.1.5. Parametrización en BTS recomendada para celda con subalcance

El objetivo de esta parametrización es ampliar el radio de cobertura. Con el parámetro

Rx_Lev_Access_Min en su valor 6 (-104dBm) conseguimos que un terminal móvil pueda

acampar en nuestra celda, y por lo tanto iniciar llamadas con una potencia recibida de -

104dBm, mientras que otras parametrizaciones tienen este valor a 15(-95dBm) o incluso a

valores más restrictivos (micros).

Sobre el parámetro cell_reselect_offset, lo configuraríamos a 9 (18dB). Con esto

conseguimos que en la reselección de nuestra celda esté penalizada con 18dB, o lo que es lo



mismo, el terminal móvil necesitará recibir al menos 18dB mejores de nuestra celda que de su

celda actual para aceptarla como posible celda destino.

En la parametrizción de las adyacencias de nuestra estación, configuraríamos nuestra

celda como 900 cosite:

NOKIA NOKIA 900Cosite -> x

900Cosite -> 900cosite x -> 900Cosite

ADJACENT CELL ho_level_umbrella 15 (-95dBm) 63 (-47dB) 63 (-47dBm)

ADJACENT CELL adj_cell_layer 3 (lower) 1 (same) 2 (upper) Figura 7.1.6. Parametrización en adyacencias recomendada para celda con subalcance

El motivo es que con esta parametrización, favoreceríamos el HO saliente hacia el

resto de estaciones del entorno (Ho_level_umbrella a 15 (-95dBm), adj_cell_layer a 3),

mientras que para el HO entrante se necesitaría un valor de Ho_level_umbrella de 63 (-

47dBm), con un adj_cell_layer de 2. Para la vecindad entre nuestra celda y el resto de celdas

900 cosite se trataría con la parametrización indicada en la tabla anterior. A estos valores de

potencia hay que sumarle el offset que tengan configuradas las definiciones de adyacencia.

En cuanto al resto de estaciones de la zona, habría que hacer un análisis más profundo

sobre la parametrización a utilizar en cada estación, en función de su distancia a nuestra celda,

su TA y su potencia configurada.

Con respecto al sobrealcance, las acciones a tomar serán las siguientes:

• Estudio del TA actual

Con la evolución del TA de una celda, podemos determinar si sufre subalcance o

sobrealcance. En la figura 7.1.7 se ve cómo las muestras con un TA>9 (>5Km) sufren un

aumento notable en los días indicados:

Figura 7.1.7. Análisis de TA de una celda



En la misma celda, se puede comprobar cómo, en los días en los que su distribución de

TA aumenta, se produce un aumento de la degradación en DCR:

Figura 7.1.8. Evolución de DCR de una celda

• Aumento/Corrección del downtilt de la estación

Tras el reajuste del tilt de esta estación, se puede comprobar en la figura 7.1.9 cómo

sus valores de DCR volvieron a valores habituales antes de la degradación. El problema que

sufrió fue un cambio de sistema radiante, donde no se repuso el tilt original.

Figura 7.1.9. Evolución de DCR de una celda tras reajuste de tilt



• Redefinición de adyacencias con respecto a su alcance real

Si la estación no dispone del sistema RET (Remote Electric Tilt), el ajuste de tilt hay que

hacerlo de forma manual sobre el terreno, lo que requiere que un técnico acceda a la antena.

Esto en ocasiones no es posible, con lo que habría que hacer una redefinición software.

Analizando el TA de la estación, tenemos conocimiento de la distancia a la que están parte de

sus muestras, con lo que es conveniente añadir las adyacencias necesarias por esta zona de

cobertura, que, debido a la distancia, posiblemente no se definieron en su fase de integración.

En la figura 7.1.10 se muestra la evolución de una estación tras añadir las adyacencias

necesarias por problemas con su sobrealcance:

Figura 7.1.10. Evolución de DCR de una celda tras carga de adyacencias

- Ajustes en parametrización

Al igual que en el caso de subalcance, podemos modificar la parametrización de la

celda y sus adyacencias para mitigar el efecto de este sobrealcance.

Para la definición de celda, utilizaríamos la siguiente parametrización:

TABLA PARÁMETRO 1800 COSITE CON 900

BTS rx_lev_access_min 15 (-95dB)


Figura 7.1.11. Parametrización en BTS recomendada para celda con sobrealcance

Con esta parametrización conseguiríamos limitar el radio de cobertura de la celda

mediante el parámetro Rx_Lev_access_min a 15 (-95dBm), por lo que se necesitaría recibir del

terminal móvil una potencia de -95dBm para que pueda acampar en nuestra celda (si fuese

necesario podríamos incluso ser más restrictivos). En cuanto al Cell_Reselect_offset,

penalizaríamos la reselección con 8dB (valor estándar para evitar pimponeo).

CDR Voice

0

10

20

30

40

50

60

01

/10

/20

11

03

/10

/20

11

05

/10

/20

11

07

/10

/20

11

09

/10

/20

11

11

/10

/20

11

13

/10

/20

11

15

/10

/20

11

17

/10

/20

11

19

/10

/20

11

21

/10

/20

11

23

/10

/20

11

25

/10

/20

11

27

/10

/20

11

29

/10

/20

11

31

/10

/20

11

02

/11

/20

11

04

/11

/20

11

06

/11

/20

11

08

/11

/20

11

10

/11

/20

11

12

/11

/20

11

14

/11

/20

11

16

/11

/20

11

18

/11

/20

11

20

/11

/20

11

22

/11

/20

11

24

/11

/20

11

0

0,5

1

1,5

2

2,5

3

3,5

4

4,5

SumOfDropTCH

SumOfCDR



Para las adyacencias, utilizaríamos la siguiente parametrización (siendo X nuestra

celda):

NOKIA NOKIA x -> x x -> 900Cosite 900Cosite -> x

ADJACENT CELL ho_level_umbrella 63 (-47dBm) 63 (-47dBm) 15 (-95dBm)

ADJACENT CELL adj_cell_layer 1 (same) 2 (upper) 3 (lower)

Figura 7.1.12. Parametrización en adyacencias recomendada para celda con sobrealcance

Con esto, conseguimos que el HO saliente se produzca con celdas adyacentes con muy

buen nivel de potencia, y dado nuestro sobrealcance, facilitaríamos el HO entrante desde

celdas 900 cosite. Si por el contrario necesitamos que nuestra celda suelte las llamadas lo

antes posible, se puede configurar un ho_level_umbrella a 15 (-95dBm) para todas las

adyacencias y un valor de offset pequeño.

7.1.4 PROBLEMAS EN ELEMENTOS HARDWARE

Los problemas hardware provocan una notable degradación en cualquier estación. La

forma de determinar qué elemento es el que no funciona correctamente se hace

principalmente mediante el análisis de las alarmas de la estación.

En la figura 7.1.13, aparecen alarmas de BBU (Base Band Unit) y VSWR (ROE), lo que

implica que posiblemente se trate de un problema de conexionado entre el cableado y el SSRR.

Figura 7.1.13. Alarmas de estación (I)



En la figura 7.1.14 se puede ver la evolución de una celda que tenía alarmas de MHA

(LNA, Low Noise Amplifier), y que tras ser sustituido tuvo una evolución positiva:

Figura 7.1.14. Alarmas de estación (II)

Figura 7.1.15. Evolución del DCR tras cambio de hardware

En los siguientes apartados analizaremos degradaciones propias de las tecnologías 2G y

3G.

CDR Voice

0

20

40

60

80

100

120

01

/1

0/

20

11

03

/1

0/

20

11

05

/1

0/

20

11

07

/1

0/

20

11

09

/1

0/

20

11

11

/1

0/

20

11

13

/1

0/

20

11

15

/1

0/

20

11

17

/1

0/

20

11

19

/1

0/

20

11

21

/1

0/

20

11

23

/1

0/

20

11

25

/1

0/

20

11

27

/1

0/

20

11

29

/1

0/

20

11

31

/1

0/

20

11

02

/1

1/

20

11

04

/1

1/

20

11

06

/1

1/

20

11

08

/1

1/

20

11

10

/1

1/

20

11

12

/1

1/

20

11

14

/1

1/

20

11

16

/1

1/

20

11

18

/1

1/

20

11

20

/1

1/

20

11

22

/1

1/

20

11

24

/1

1/

20

11

0

20

40

60

80

100

120

140

160

SumOfDropTCH

SumOfCDR



7.2 ESTACIONES 2G

7.2.1 DEGRADACIÓN EN BLOQUEO TCH

Una estación puede sufrir problemas de bloqueo TCH por varios motivos:

Dimensionamiento incorrecto

En el dimensionamiento realizado, la estimación de TRXs integrados es menor de los

necesarios para nuestra estación, lo que provoca congestión TCH.

Diseño incorrecto

Por un mal ajuste de tilt o potencia, puede ocurrir que nuestra estación esté cubriendo

zonas que no sean objetivo de cobertura de nuestra estación y absorba un tráfico no previsto,

lo que puede provocar congestión TCH.

Caída de estaciones adyacentes

Con la indisponibilidad de una estación, todas sus vecinas pueden absorber parte del

tráfico de dicha estación, lo que puede provocar congestión TCH en todas las estaciones

adyacentes.

Para el segundo caso, la solución óptima pasa por hacer un reajuste de los tilts/azimuts

de la estación. Sin embargo existen otros mecanismos para combatir el bloqueo TCH de una

estación:

Activación Half Rate

Este mecanismo ya fue explicado con detalle en la fase de integración. A modo de

recordatorio, permite maximizar el uso del espectro y optimizar la red metiendo a dos móviles

por un solo Radio TimeSlot. Como gran ventaja aporta que es capaz de duplicar la capacidad de

la red sin ninguna inversión en hardware. Como desventaja que codifica la conversación en un

canal de 8 Kbps en vez del habitual de 16 Kbps, aunque esto se hace de forma transparente

para el usuario y sin pérdida de calidad. Por lo tanto, de cara al usuario tenemos el doble de

capacidad efectiva en nuestra estación. La parametrización que debemos modificar para la

activación del half rate en nuestras celdas es la siguiente:

TABLA CampoValor en

UploadSignificado

TRX half_rate_support 1 Yes

TRX ch_type_0...8 2 TCH DualRate

Figura 7.2.1. Parametrización a modificar para la activación de Half Rate

Sin embargo, podemos optar por una solución intermedia, la activación del half rate

dinámico, mediante los siguientes parámetros:



TABLA CampoValor en

UploadSignificado

BTS bts_sp_load_dep_tch_rate_upper 45 45%

BTS bts_sp_load_dep_tch_rate_lower 35 35%

BSC bts_load_dep_tch_rate_upper 100 100%

BSC bts_load_dep_tch_rate_lower 0 0%

Figura 7.2.2. Parametrización a modificar para la activación de Half Rate Dinámico

Los parámetros de esta última tabla equivalen a dos valores umbrales, uno que nos

marcará un límite inferior y el otro el superior. Inicialmente, se comenzará la asignación de

canales en Full Rate, hasta alcanzar la condición de bts_sp_load_dep_tch_rate_upper. A partir

de este umbral, la BSC empezará a asignar canales TCHalf. Seguirá en esta condición siempre

que no se cumpla la condición bts_sp_load_dep_tch_rate_lower. Ambos parámetros serán

dados en % y marcará el comienzo de ocupación de canales tras lo que se realizará la

asignación de canales Half Rate o la vuelta a la asignación en Full Rate.

Ajustes en parametrización

El principal objetivo es reducir el tráfico que cursa nuestra estación, reduciéndole su

radio de cobertura efectivo tal y como ya se ha explicado anteriormente:

TABLA PARÁMETRO 1800 COSITE CON

900

BTS rx_lev_access_min 15 (-95dB)


Figura 7.2.3. Parametrización en BTS recomendada para celda con bloqueo TCH

Con esta parametrización conseguiríamos limitar el radio de cobertura de la celda

mediante el parámetro Rx_Lev_access_min a 15 (-95dBm), por lo que se necesitaría recibir del

terminal móvil una potencia de -95dBm para que pueda acampar en nuestra celda (si fuese

necesario podríamos incluso ser más restrictivos). En cuanto al Cell_Reselect_offset,

penalizaríamos la reselección con 8dB como valor estándar, aunque podríamos ser más

restrictivos siempre y cuando no se degraden las estaciones del entorno.

Integración de nuevos TRXs

Aumentando el número de TRXs de las celdas con problemas, dispondremos de más

canales libres (en principio configurables como TCH o como SD), lo que hará que la congestión

TCH disminuya o desaparezca.

En la figura 7.2.4 se puede observar la correcta evolución de una estación con bloqueo

TCH tras los ajustes en su parametrización y la activación de half rate:



Figura 7.2.4. Evolución bloqueo TCH tras acciones correctoras

Con las medidas de DT se pueden detectar en ocasiones el origen de algunos de estos

problemas, mediante la realización de medidas y pruebas específicas (zonas de mala

cobertura, fallos de HO, búsqueda de zona de caída y bloqueo de llamadas, etc.). A

continuación se puede ver un ejemplo de una llamada bloqueada (block call):

Figura 7.2.5. Bloqueo de llamada detectada mediante análisis de DT

7.2.2 DEGRADACIÓN EN BLOQUEO SD

El bloqueo SD se produce cuando se disponen de menos canales SD de los que necesita

nuestra estación. Las causas pueden ser varias:

Dimensionamiento/diseño incorrecto

El problema de la aparición de bloqueo SD puede deberse a un mal dimensionamiento

de la estación o una mala configuración de canales SD en la integración.

Caída intermitente de estaciones en el entorno

TCH_Blocks

0

10

20

30

40

50

60

70

80

90

01

/1

0/

20

11

03

/1

0/

20

11

05

/1

0/

20

11

07

/1

0/

20

11

09

/1

0/

20

11

11

/1

0/

20

11

13

/1

0/

20

11

15

/1

0/

20

11

17

/1

0/

20

11

19

/1

0/

20

11

21

/1

0/

20

11

23

/1

0/

20

11

25

/1

0/

20

11

27

/1

0/

20

11

29

/1

0/

20

11

31

/1

0/

20

11

02

/1

1/

20

11

04

/1

1/

20

11

06

/1

1/

20

11

08

/1

1/

20

11

10

/1

1/

20

11

12

/1

1/

20

11

14

/1

1/

20

11

16

/1

1/

20

11

18

/1

1/

20

11

20

/1

1/

20

11

22

/1

1/

20

11

24

/1

1/

20

11



Cuando una estación cercana tiene caídas intermitentes, todos los terminales de la

zona comienzan una fase de señalización con las estaciones adyacentes, lo que puede llegar a

provocar congestión SD.

En los siguientes ejemplos se puede comprobar cómo a raíz de las indisponibilidades

aparecidas en una estación, otra de sus estaciones vecinas comienza a presentar congestión

SD.

Figura 7.2.6. Indisponibilidad intermitente en estación

Figura 7.2.7. Congestión SD intermitente por las indisponibilidades de la estación anterior



Figura 7.2.8. Indisponibilidad permanente en estación

Figura 7.2.9. Congestión SD en celda vecina provocada por indisponibilidad anterior

Problemas de HO con las estaciones adyacentes

Cuando un terminal intenta hacer HO hacia otra celda y este traspaso falla,

generalmente se producen nuevos intentos de HO de forma consecutiva, aumentando de

forma notable el tráfico SD, lo que puede ser la causa de la aparición de congestión SD.

Figura 7.2.10. Fallos de HO entrantes a una celda



Figura 7.2.11. Identificación de fallos de HO entrantes a una celda

Zona de cambio de LAC

Cuando un terminal se encuentra en una zona de cambio de LAC entre estaciones, el

tráfico de señalización es mayor al habitual debido a los constantes Location Update

ejecutados, lo que puede provocar congestión SD en una estación. Para evitar esto es

necesario hacer la reconfiguración de canales TCH a SD.

Las soluciones a aplicar son distintas, en función del origen del problema.

Reconfiguración de canales a SD

Si la congestión solamente aparece en SD y no en TCH, se pueden reconfigurar uno o

varios canales TCH a SD, disminuyendo la congestión SD existente.

Ampliación de TRXs

Con la ampliación de TRXs podemos añadir uno o varios canales SD a nuestra BTS, lo

que ayuda a la disminución de congestión SD.

Sin embargo, algunos de estos problemas no llegan a resolverse de esta forma, sino

que es necesario actuar sobre la parametrización de algunas celdas. Es especialmente sensible

el tercer caso descrito, los problemas de HO con las estaciones adyacentes. Para resolver estos

problemas debemos llevar a cabo las siguientes actuaciones:

Revisión de vecindades, especialmente las adyacencias cosites

Es importante que las definiciones de adyacencias tengan todos sus parámetros

correctamente configurados, especialmente el par BCCH-BSIC.



Definiciones de Inners/Areas/Outers

Definición de la celda en la MSC/UMSC a la que pertenece

como Inner/Area (cada BSC/RNC pertenece a una MSC/UMSC

concreta)

Definición de la celda en las MSCs/UMSCs de las celdas vecinas

(como Outer).

Definición de las celdas “vecinas” en la MSC/UMSC origen

(como Outers).

Si dos celdas pertenecen a la misma MSC, no es necesaria la

definición de outer

Definiciones de externas 2G en red UTRAN y definiciones 3G en red

GSM

Figura 7.2.12. Definiciones de externas 2G en red UTRAN y 3G en red GSM

Sobrealcances.

Es necesario un análisis y su correspondiente modificación de Downtilts en caso de ser

necesario.

Análisis de interferencias

Existen programas que hacen una estimación mediante simulaciones de la

interferencia que sufriría una celda con una determinada frecuencia, indicando la o las celdas

con las que se vería interferida. Además, hacen la estimación de la interferencia sufrida por las

frecuencias adyacentes a la indicada para el análisis.



Figura 7.2.13. Estimación de interferencia para una determinada celda y frecuencia (I)

Figura 7.2.14. Estimación de interferencia para una determinada celda y frecuencia (II)

Figura 7.2.15. Evolución del CSSR de una celda tras eliminar interferencias

CSSR

0

20

40

60

80

100

120

01

/1

0/

20

11

03

/1

0/

20

11

05

/1

0/

20

11

07

/1

0/

20

11

09

/1

0/

20

11

11

/1

0/

20

11

13

/1

0/

20

11

15

/1

0/

20

11

17

/1

0/

20

11

19

/1

0/

20

11

21

/1

0/

20

11

23

/1

0/

20

11

25

/1

0/

20

11

27

/1

0/

20

11

29

/1

0/

20

11

31

/1

0/

20

11

02

/1

1/

20

11

04

/1

1/

20

11

06

/1

1/

20

11

08

/1

1/

20

11

10

/1

1/

20

11

12

/1

1/

20

11

14

/1

1/

20

11

16

/1

1/

20

11

18

/1

1/

20

11

20

/1

1/

20

11

22

/1

1/

20

11

24

/1

1/

20

11



Con las medidas de DT también son detectables este tipo de problemas, especialmente

fallos de HO entre adyacencias y definiciones de adyacencias faltantes (“missing neighbour”). A

continuación se pueden ver varios ejemplos de fallos de HO:

Figura 7.2.16. Detección de fallo de HO en medida de DT

Figura 7.2.17. Detección de una “missing neighbour” en medida de DT



7.2.3 DEGRADACION EN CAÍDAS SD

La mayor parte de las caídas SD es provocada por las interferencias sobre nuestra

estación. Para resolver este problema, hay que identificar qué celdas están provocando las

interferencias y, en caso de ser necesario, buscar una frecuencia alternativa para alguna de las

celdas interferidas.

Figura 7.2.18. Estimación de interferencia para una determinada celda y frecuencia.

Habitualmente, además de las caídas SD, estas interferencias provocan la aparición de

fallos de HO:

Figura 7.2.19. Fallos de HO provocados por interferencias



Figura 7.2.20. Caídas SD provocadas por interferencias (I)

Otro de los problemas que provocan estas interferencias, además de las caídas SD y los

fallos de HO, es un aumento notable de la degradación de DCR. Además, al fallar los intentos

de HO, estos intentos se multiplican, lo que hace que el número de conexiones SD se dispare,

pudiendo provocar a su vez congestión SD:

Figura 7.2.21. Caídas SD provocadas por interferencias (II)

Figura 7.2.22. Caídas TCH provocadas por interferencias



Figura 7.2.23. Aumento notable de intentos de captura SD por interferencias

7.2.4 DEGRADACION EN CAÍDAS TCH

Una estación puede degradarse en caídas TCH por multitud de causas. En primer lugar,

es necesario determinar la causa de las caídas TCH, que se suelen dividir en varios grupos:

radio, transmisión o fallos de equipo.

En las causas radio, quedan englobadas todas las relacionadas con definiciones de

adyacencias y parametrización, interferencias o definiciones de Core.

Degradación en DCR por falta de adyacencias

En la figura 7.2.24, la estación EB2861 sufrió una degradación notable tras borrarse

por error las adyacencias indicadas en el sur de dicha estación. Tras la nueva carga de dichas

adyacencias, se observa la correcta evolución de la estación en DCR.

Figura 7.2.24. Localización de la zona de influencia de nuestra estación



Figura 7.2.25. Degradación diaria en DCR de celda por falta de adyacencias

Figura 7.2.26. Degradación horaria en DCR de celda por falta de adyacencias

Figura 7.2.27. Evolución diaria tras redefinición de adyacencias borradas



Degradación en DCR por fallos de HO

Otro de los posibles tipos de fallo en las caídas es por HO. Es posible identificar las

celdas con las que nuestro éxito de HO no es el deseado, lo que nos facilita identificar la causa

de estos fallos de HO.

Habitualmente, estos problemas se deben a que la celda afectada recibe un BCCH de

una celda distinta a la vecina que tiene definida con este mismo BCCH. Por lo tanto, la celda

afectada intenta hacer un HO con la vecina del BCCH recibido, pero al no ser la vecina que

tiene definida se produce un fallo de HO.

Figura 7.2.28. Análisis de caídas TCH por causas

Figura 7.2.29. Análisis de HO con las celdas vecinas

Figura 7.2.30. Estimación de interferencia para una determinada celda y frecuencia



Degradación en DCR provocada por indisponibilidades

Una de las causas más importantes en las degradaciones en DCR son las

indisponibilidades intermitentes en una estación. Cuando una estación sufre una caída

intermitente, todas las llamadas que esté cursando en ese momento sufren una caída, lo que

puede provocar que las caídas TCH se disparen. En los siguientes ejemplos se puede observar

este problema:

Figura 7.2.31. Degradación en DCR por caídas intermitentes (I)

Figura 7.2.32. Degradación en DCR por caídas intermitentes (II)



Nuevamente, los problemas de DCR pueden ser analizados mediante medidas

específicas de un equipo de DT. En la figura 7.2.33 se puede observar cómo se produce una

caída TCH debido a la pérdida de la señal de una estación:

Figura 7.2.33. Drop Call detectado en análisis de medidas de DT por pérdida de señal

Por último, analizaremos el resultado de los reportes de las medidas de un DT para una

llamada iniciada y finalizada correctamente.

Figura 7.2.34. Análisis de llamada correcta



7.3 ESTACIONES 3G

Las degradaciones en nodos B 3G tienen un análisis diferente a los ya vistos para

estaciones de 2G. De un modo genérico, podemos agrupar las degradaciones 3G en dos

grandes grupos: Accesibilidad (CSSR) y Caídas (DROPS). A su vez, dentro de cada uno de estos

grupos, se puede analizar independientemente el tráfico de voz (CS) y el tráfico de datos (PS).

7.3.1 CSSR Y DCR

La capacidad de la red 3G está limitada por cinco factores:

Interferencia

La limitación por interferencia es la que te impide tener un buen throughput, y por lo

tanto, no te permite ofrecer una mayor calidad de servicio a los usuarios. Esta interferencia se

controla mediante el despliegue y el diseño radio, ya que habría que entrar en un compromiso

entre los ajustes de downtilts y otros ajustes que se requieran. Esta interferencia suele estar

producida por celdas vecinas que tienen el mismo RSCP (Received Signal Code Power) que la

celda activa

Potencia

Es la cantidad de energía eléctrica radiada. Este factor está limitado directamente en el nodo B, ya que tiene una máxima potencia de emisión. Y para cada canal se asigna una potencia. Cada usuario consume una potencia específica, por lo que el número máximo de usuarios estará limitado por la potencia disponible en el nodo B.

Channel Elements (CE) Los CE son la unidad utilizada para la capacidad de procesado en Banda Base. El

Hardware de los equipos utilizados tiene una limitación de tráfico que pueden manejar, por lo que, si tienen un número máximo de Channel Elements, no van a poder transmitir más tráfico que el permitido por ese número. El nombre de CE es la manera de llamar a la asignación de recursos necesarios para cada llamada.

Códigos

En este caso, estaría limitado en DL, ya que cada estación base tiene asignado un árbol de códigos ortogonales en DL para asignar a los usuarios que estén conectados a ese nodo B. En el momento que ya no haya más códigos disponibles, no se puede seguir ofreciendo el servicio a los usuarios, a no ser que se amplíe con otro árbol de códigos de canalización permitiendo el uso de un segundo scrambling code, pero en la práctica no se realiza debido a las interferencias, por lo que se define una segunda portadora a una frecuencia diferente. En UL no limitaría, ya que hay un árbol de códigos para cada terminal, por lo que no afectaría el número de usuarios que estuviera conectado a ese mismo nodo B.



IUB

El interfaz IUB es el interfaz que une nodo B y RNC, y por lo tanto, limita en el ancho de banda del canal que se tiene para transmitir la información, en este caso datos, ya que la voz consume un caudal muy reducido (12,2 Kbps).

Por lo tanto, un análisis de problemas de CSSR en un nodo B incluiría un estudio de

cada uno de estos apartados. Existen contadores que permiten identificar las causas de los fallos que provocan esta degradación. En primer lugar, hay que diferenciar 2 tipos de protocolos:

RRC (Radio Resource Control): Control de los recursos radio entre el usuario y la RNC.

RAB (Radio Access Bearer): es el servicio que la red UTRAN proporciona a las capas superiores de la torre de protocolos (gestión de movilidad, gestión de sesión…) para la transferencia de datos de usuario entre el terminal y la red

Dentro de cada uno de estos tipos de protocolos, en las redes 3G existen a su vez

contadores que permiten identificar los tipos de fallos que limitan la accesibilidad (CSSR).

Análisis fallos RRC

El diagrama de flujo completo para conexiones RRC es el siguiente:

Figura 7.3.1. Diagrama de flujo para conexiones RRC



Nosotros nos centraremos en este apartado en el análisis de fallos por causa radio en

el control de admisión. Un diagrama de flujo más simplificado y sobre el que haremos nuestros

análisis será el siguiente:

Figura 7.3.2. Diagrama de flujo para mensajes RRC con fallos por control de admisión

Los contadores que nos indican los fallos de cada uno de estos tipos son los siguientes:

Figura 7.3.3. Tipos de fallos RRC por causa radio



Por lo tanto, en la tabla anterior se recogen todos los tipos de fallos por causa radio

explicados anteriormente:

Congestión en su IUB: VS.RRC.Rej.(DL/UL)IUBBand.Cong

Congestión por CE: VS.RRC.Rej.(DL/UL)CE.Cong

Congestión por potencia: VS.RRC.Rej.(DL/UL)Power.Cong

Congestión por código: VS.RRC.Rej.Code.Cong

Como se ha visto en el diagrama de flujo anterior, la causa radio no es la única. Otras

importantes son por TimeOut y por RadioLinkFailure, con los siguientes contadores:

Timeout of RRC CONNECT SETUP COMPLETE: VS.RRC.FailConnEstab.NoReply

Figura 7.3.4. Diagrama de flujo para mensajes RRC con fallos por TimeOut

RadioLinkFailure: VS.RRC.Rej.RL.Fail

Figura 7.3.5. Diagrama de flujo para mensajes RRC con fallos por RadioLink Failure



Por último, es necesario resaltar que en la fase RRC no es posible diferenciar entre

tráfico de voz y de datos.

Análisis Fallos RAB

El diagrama de flujo completo para conexiones RAB es el siguiente:

Figura 7.3.6. Diagrama de flujo para conexiones RAB

A diferencia de la fase RRC, en la fase RAB ya sí aparece diferenciado el tráfico de voz

(CS) y datos (PS). Nuevamente centraremos nuestro análisis de fallos en los ocurridos por

causa radio en el control de admisión. Un diagrama de flujo más simplificado y sobre el que

haremos nuestros análisis será el siguiente:



Figura 7.3.7. Diagrama de flujo para mensajes RAB con fallos por control de admisión

Por lo tanto, en este caso habrá que analizar contadores independientes para CS y PS:

Tipos de fallos por control de admisión en CS

Figura 7.3.8. Tipos de fallos RAB CS por causa radio



Tipos de fallos por control de admisión en PS

Figura 7.3.9. Tipos de fallos RAB PS por causa radio

Los tipos de fallos RAB (tanto CS como PS) son similares a los vistos en RRC, e

identifican cada una de las causas que pueden limitar la accesibilidad en 3G a nivel radio. En

los tipos de fallos RAB, como ya se ha visto en los fallos RRC, existen nuevamente otros

muchos contadores de fallos, sobre los que no entraremos en más detalle.

7.3.1.1 DEGRADACIÓN EN CSSR_CS y CSSR_PS

La degradación en accesibilidad suele afectar con el mismo patrón a la voz (CS) que a

los datos (PS). Pero dada la prioridad que se le da al tráfico de voz sobre el de datos,

habitualmente la degradación en CSSR_PS suele ser bastante más notable que la degradación

en CSSR_CS.

En la figura 7.3.10 y 7.3.11 se adjuntan gráficas de un ejemplo de degradación

simultánea en CS y PS, donde se puede observar cómo la degradación en PS es más notable

que la sufrida por el tráfico CS:

Figura 7.3.10. Degradación en CSSR_CS



Figura 7.3.11. Degradación en CSSR_PS

Nuevamente, los problemas de indisponibilidad intermitente es una de las causas más

importantes para la degradación en CSSR de un nodo:

Figura 7.3.12. Indisponibilidades intermitentes de un nodo B

Figura 7.3.13. Degradación en CSSR_PS simultánea a las indisponibilidades del nodo B



A continuación se verán algunos ejemplos de los distintos fallos de tipos RAB vistos en

el control de admisión por causa radio:

FALLOS RAB por Congestión en Channel Elements (CE)

Figura 7.3.14. Degradación por fallos RAB por ULCE (CE en Uplink)

FALLOS RAB por congestión en IUB

Figura 7.3.15. Degradación por fallos RAB por congestión en su IUB en DL



FALLOS RAB por POTENCIA

Figura 7.3.16. Degradación por fallos RAB por congestión en potencia en UL

7.3.1.2 DEGRADACIÓN EN CAÍDAS CS y PS

Los problemas en la degradación en caídas CS y PS suelen estar determinados

principalmente por las siguientes causas:

Falta de adyacencias: es imprescindible que el diseño de la estación

sea correcto para evitar la falta de adyacencias importantes de un

nodo B.

Errores en la parametrización de la celda y de las adyacencias:

Pueden producirse problemas ya analizados anteriormente, como

fallos de HO por interferencias, que pueden provocar degradación en

DCR.

Indisponibilidades: Cuando una estación se cae, todas las llamadas de

voz y datos que esté cursando las tira, pudiendo provocar que se

dispare su DCR_CS y DCR_PS

Problemas de Transmisión: Las indisponibilidades no son la única

causa que provoca degradación en DCR, sino también la caída de E1s

en estaciones configuradas con varios E1s.

Congestión en su IUB: Este problema no afecta por igual al tráfico de

voz y datos. Dado que el tráfico de voz es prioritario, si tenemos el IUB

de un nodo congestionado, descartará cualquier tráfico de datos para



asignarle la capacidad al tráfico de voz, provocando que el tráfico PS

pueda degradarse en CSSR y en DCR.

En la figura 7.3.17 se analizará un caso de un nodo B que sufre varias caídas

intermitentes, y tras levantar de forma estable lo hace con un solo E1, perdiendo 3 de los 4 E1s

que tenía originalmente y provocando degradación en CSSR y DCR:

Figura 7.3.17. Indisponibilidades intermitentes en un nodo B

Figura 7.3.18. Análisis de configuración y ocupación del IUB del nodo anterior



Figura 7.3.19. Análisis de caídas TCH relacionadas con la indisponibilidad del nodo B

Figura 7.3.20. Análisis de caídas PS relacionadas con la indisponibilidad del nodo B y la posterior congestión

de su IUB

7.4 DISEÑO INSUFICIENTE EN CAPACIDAD

La congestión en el IUB de un nodo es una de las causas que provocan una

degradación generalizada en todos los KPIs de un nodo, especialmente en CSSR (PS y CS) y

DCR_PS. Los motivos de degradación en accesibilidad son obvios, mientras que la degradación

en DCR_PS se debe a la prioridad del tráfico de voz sobre los datos. Si el IUB de un nodo está



congestionado y llegan nuevas peticiones de tráfico de voz, descartará todos los paquetes de

datos que sean necesarios para aceptar el tráfico de voz, provocando una posible degradación

en DCR_PS. Si a pesar de esto el IUB continuase congestionado, comenzaría la degradación en

CSSR, especialmente en tráfico PS, y posteriormente en menor medida en CSSR_CS.

Es necesario señalar que en nodos con Co-Transmisión (comparten la transmisión el 2G

y el 3G), la tecnología 2G utiliza por defecto 1 E1 de la estación, quedando en resto de E1s para

la tecnología 3G. Sin embargo, en casos de congestión 3G, se puede hacer un trasvase de

capacidad del E1 de 2G sobrante al nodo B si fuese necesario. Se adjuntan varios ejemplos de

nodos con problemas de congestión en su IUB:

Figura 7.4.1. Ocupación de IUB con Co-transmisión 2G/3G en estación con 2 E1s con congestión en 3G

Figura 7.4.2. Ocupación de IUB con Co-transmisión 2G/3G tras modificación en configuración de IUB en

estación con 2 E1s



Figura 7.4.3. Ocupación de IUB con Co-transmisión 2G/3G en estación con 3 E1s con congestión en 3G

Figura 7.4.4. Ocupación de IUB con transmisión independiente para 3G en nodo B con 2 E1s con congestión



A continuación se presenta un ejemplo de una estación que presenta una degradación

enorme en el CSSR, tanto en voz como en datos:

Figura 7.4.5. Degradación enorme en CSSR_CS durante gran parte del día

Figura 7.4.6. Degradación enorme en CSSR_PS durante gran parte del día



El primer paso para detectar el origen de la degradación, es analizar la causa de los

fallos, que en este caso son RAB por congestión en el IUB:

Figura 7.4.7. Análisis de causas de fallos RAB_CS por congestión en el IUB

Figura 7.4.8. Análisis de causas de fallos RRC por congestión en el IUB

Figura 7.4.9. Análisis del IUB del nodo anterior con co-transmisión. Diseño de IUB insuficiente.



7.5 CAÍDAS DE E1s PERMANENTES E INTERMITENTES

La configuración del IUB de una estación no siempre permanece estable, y es muy

habitual sufrir la caída de E1s sin llegar a provocar indisponibilidad de la estación. Esto ocurre

en configuraciones de transmisión en doble ruta, cuando una de las rutas se convierte en

indisponible.

El principal efecto que provocan estas caídas de E1s es la posible congestión en su IUB,

con todos los problemas secundarios derivados de la congestión en el IUB de un nodo ya vistos

en puntos anteriores. Estos problemas pueden ser mitigados con configuraciones

determinadas en la parametrización de un nodo B.

A continuación se analizan dos casos de nodos B que sufren la caída de E1s en su IUB,

provocando, entre otras degradaciones, una notable degradación en DCR_PS:

Figura 7.5.1. Ocupación de IUB. Caída de 2 E1s tras indisponibilidad

Figura 7.5.2. Degradación en DCR_PS tras indisponibilidad y caída de E1s.



Figura 7.5.3. Ocupación de IUB. Caída de 1 E1 y congestión en IUB

Figura 7.5.4. Degradación en DCR_PS tras congestión en IUB

Pero no siempre las caídas de E1s se producen de forma permanente, sino que hay

ocasiones en las que alguno de los E1s cae y levanta de forma constante. Los efectos de esta

situación son aún peores que los ya analizados, porque tras cada caída de alguno de sus E1s, el

nodo está constantemente tirando llamadas de voz y datos:



Figura 7.5.5. Degradación en IUB. Caídas intermitentes de E1.

o RECUPERACIÓN DE E1s

Cuando recuperamos los E1s de una estación, debemos devolver la configuración de

dicha estación a sus valores originales para que el funcionamiento de la estación sea el

correcto:

Figura 7.5.6. Recuperación de 2 E1s en el IUB de un nodo

En el siguiente caso, la acción que se tuvo que llevar a cabo fue el barrero del nodo B en un site

con co-transmisión, dejando solamente el 2G radiando. Tras comprobar cómo los E1s

originales de la estación levantan, se debería proceder con el desbarreo de la tecnología 3G.



Figura 7.5.7. Recuperación de 3 E1s en el IUB de un nodo

capÍtulo 7. anÁlisis de degradaciones 7.1...

Documents