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

(1)

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.

(2)

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):

(3)

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

(4)

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:

(5)

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.

(6)

• 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)

BTS cell_reselect_offset 4 (8dB)

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 0 1 /1 0 /2 0 1 1 0 3 /1 0 /2 0 1 1 0 5 /1 0 /2 0 1 1 0 7 /1 0 /2 0 1 1 0 9 /1 0 /2 0 1 1 1 1 /1 0 /2 0 1 1 1 3 /1 0 /2 0 1 1 1 5 /1 0 /2 0 1 1 1 7 /1 0 /2 0 1 1 1 9 /1 0 /2 0 1 1 2 1 /1 0 /2 0 1 1 2 3 /1 0 /2 0 1 1 2 5 /1 0 /2 0 1 1 2 7 /1 0 /2 0 1 1 2 9 /1 0 /2 0 1 1 3 1 /1 0 /2 0 1 1 0 2 /1 1 /2 0 1 1 0 4 /1 1 /2 0 1 1 0 6 /1 1 /2 0 1 1 0 8 /1 1 /2 0 1 1 1 0 /1 1 /2 0 1 1 1 2 /1 1 /2 0 1 1 1 4 /1 1 /2 0 1 1 1 6 /1 1 /2 0 1 1 1 8 /1 1 /2 0 1 1 2 0 /1 1 /2 0 1 1 2 2 /1 1 /2 0 1 1 2 4 /1 1 /2 0 1 1 0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 SumOfDropTCH SumOfCDR

(7)

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.

(8)

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 0 1 / 1 0 / 2 0 1 1 0 3 / 1 0 / 2 0 1 1 0 5 / 1 0 / 2 0 1 1 0 7 / 1 0 / 2 0 1 1 0 9 / 1 0 / 2 0 1 1 1 1 / 1 0 / 2 0 1 1 1 3 / 1 0 / 2 0 1 1 1 5 / 1 0 / 2 0 1 1 1 7 / 1 0 / 2 0 1 1 1 9 / 1 0 / 2 0 1 1 2 1 / 1 0 / 2 0 1 1 2 3 / 1 0 / 2 0 1 1 2 5 / 1 0 / 2 0 1 1 2 7 / 1 0 / 2 0 1 1 2 9 / 1 0 / 2 0 1 1 3 1 / 1 0 / 2 0 1 1 0 2 / 1 1 / 2 0 1 1 0 4 / 1 1 / 2 0 1 1 0 6 / 1 1 / 2 0 1 1 0 8 / 1 1 / 2 0 1 1 1 0 / 1 1 / 2 0 1 1 1 2 / 1 1 / 2 0 1 1 1 4 / 1 1 / 2 0 1 1 1 6 / 1 1 / 2 0 1 1 1 8 / 1 1 / 2 0 1 1 2 0 / 1 1 / 2 0 1 1 2 2 / 1 1 / 2 0 1 1 2 4 / 1 1 / 2 0 1 1 0 20 40 60 80 100 120 140 160 SumOfDropTCH SumOfCDR

(9)

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 Campo Valor en

Upload Significado

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:

(10)

TABLA Campo Valor en

Upload Significado

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)

BTS cell_reselect_offset 4 (8dB)

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:

(11)

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 0 1 / 1 0 / 2 0 1 1 0 3 / 1 0 / 2 0 1 1 0 5 / 1 0 / 2 0 1 1 0 7 / 1 0 / 2 0 1 1 0 9 / 1 0 / 2 0 1 1 1 1 / 1 0 / 2 0 1 1 1 3 / 1 0 / 2 0 1 1 1 5 / 1 0 / 2 0 1 1 1 7 / 1 0 / 2 0 1 1 1 9 / 1 0 / 2 0 1 1 2 1 / 1 0 / 2 0 1 1 2 3 / 1 0 / 2 0 1 1 2 5 / 1 0 / 2 0 1 1 2 7 / 1 0 / 2 0 1 1 2 9 / 1 0 / 2 0 1 1 3 1 / 1 0 / 2 0 1 1 0 2 / 1 1 / 2 0 1 1 0 4 / 1 1 / 2 0 1 1 0 6 / 1 1 / 2 0 1 1 0 8 / 1 1 / 2 0 1 1 1 0 / 1 1 / 2 0 1 1 1 2 / 1 1 / 2 0 1 1 1 4 / 1 1 / 2 0 1 1 1 6 / 1 1 / 2 0 1 1 1 8 / 1 1 / 2 0 1 1 2 0 / 1 1 / 2 0 1 1 2 2 / 1 1 / 2 0 1 1 2 4 / 1 1 / 2 0 1 1

(12)

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

(13)

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.

(14)

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.

(15)

 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.

(16)

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 0 1 / 1 0 / 2 0 1 1 0 3 / 1 0 / 2 0 1 1 0 5 / 1 0 / 2 0 1 1 0 7 / 1 0 / 2 0 1 1 0 9 / 1 0 / 2 0 1 1 1 1 / 1 0 / 2 0 1 1 1 3 / 1 0 / 2 0 1 1 1 5 / 1 0 / 2 0 1 1 1 7 / 1 0 / 2 0 1 1 1 9 / 1 0 / 2 0 1 1 2 1 / 1 0 / 2 0 1 1 2 3 / 1 0 / 2 0 1 1 2 5 / 1 0 / 2 0 1 1 2 7 / 1 0 / 2 0 1 1 2 9 / 1 0 / 2 0 1 1 3 1 / 1 0 / 2 0 1 1 0 2 / 1 1 / 2 0 1 1 0 4 / 1 1 / 2 0 1 1 0 6 / 1 1 / 2 0 1 1 0 8 / 1 1 / 2 0 1 1 1 0 / 1 1 / 2 0 1 1 1 2 / 1 1 / 2 0 1 1 1 4 / 1 1 / 2 0 1 1 1 6 / 1 1 / 2 0 1 1 1 8 / 1 1 / 2 0 1 1 2 0 / 1 1 / 2 0 1 1 2 2 / 1 1 / 2 0 1 1 2 4 / 1 1 / 2 0 1 1

(17)

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

(18)

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:

(19)

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)

(20)

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.

(21)

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

(22)

 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

(23)

 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)

(24)

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.

(25)

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.

(26)

 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:

(27)

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:

(28)

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

(29)

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:

(30)

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

(31)

 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:

(32)

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

(33)

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

(34)

 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

(35)

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

(36)

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á

(37)

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

(38)

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

(39)

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

(40)

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

(41)

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

(42)

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:

(43)

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.

(44)