Capítulo 6: Autoaceptación: Pruebas y Correcciones

Integración de una Estación Base en una Red Móvil Existente
Capítulo 6
Capítulo 6:
Autoaceptación: Pruebas y Correcciones
6.1.- Comprobación de parámetros y encendido
Una vez tengamos nuestro site completamente instalado según la configuración
diseñada y definido en la red según los datos de configuración radio generados para su
integración, es momento de encender el emplazamiento para que comience a dar el
servicio para el que se le diseñó.
Antes de encender el emplazamiento, es necesario realizar una comprobación de
parámetros previa, es decir, hay que comprobar que se han definido en la BTS/BSC o
NodoB/RNC los parámetros y valores que hemos indicado en los datos radio generados.
Esta comprobación rutinaria es solamente para comprobar que todos los
parámetros radio diseñados y enviados para que se carguen en la red han sido cargados
correctamente. Mediante esta comprobación previa se pueden detectar errores de dicha
carga como por ejemplo que no se haya cargado alguna vecindad de las que
pretendíamos definir o que haya habido algún error en las frecuencias de las portadoras
asignadas.
Si se hubiese omitido la carga de algún dato de los diseñados será necesario
rehacer esa carga faltante para que todo quede tal y como se pretendió en el diseño.
Tras esta comprobación inicial, y habiéndonos asegurado de que no ha existido
ningún error en la carga de parámetros radio o que todos están ya definidos sin errores,
tenemos nuestro emplazamiento totalmente listo para empezar a formar parte de la red
móvil existente, por lo tanto se procede a indicar su encendido.
138
Integración de una Estación Base en una Red Móvil Existente
Capítulo 6
6.2.- Análisis estadísticos
Tras solicitar el encendido del emplazamiento, éste comienza a dar servicio
dentro de la red.
Estos momentos tras el encendido son muy importantes y críticos para
comprobar el funcionamiento real de dicho emplazamiento, de manera que si todo
marcha de manera prevista el emplazamiento se mantendrá encendido dando el servicio
para el que se le pretende pero si por el contrario el funcionamiento del emplazamiento
no es tan bueno como se deseaba es posible que sea necesario bloquear/apagar dicho
emplazamiento y realizar una nueva comprobación de los parámetros cargados por si
existiese algún error subsanable.
La comprobación del funcionamiento de un site se realiza mediante los
estadísticos del propio site. Toda la red debe estar monitorizada y de ella se pueden
obtener las estadísticas de tráfico del emplazamiento.
Desde que el emplazamiento se enciende comienza a cursar llamadas de voz y
datos. Desde este primer momento se comienza a contabilizar estadísticas del tráfico
cursado. Este tráfico puede verse afectado por diferentes problemas de llamadas caídas,
bloqueadas o demás problemas debidos a diferentes motivos.
La documentación o informe a presentar tras el encendido de una estación para
la comprobación de su funcionamiento es algo básico, como ya se ha comentado sobre
las estadísticas de las primeras llamadas de voz y datos.
Un ejemplo de informe de comprobación a presentar puede ser el siguiente:
Figura 6.1.- Informe básico de integración
139
Integración de una Estación Base en una Red Móvil Existente
Capítulo 6
6.3.- Medidas de cobertura
Tras un informe básico satisfactorio, con un índice de porcentajes de caídas y
bloqueos bajo y un porcentaje de éxito de handover alto es el momento de realizar el
análisis de medida de cobertura.
Esta fase consiste en realizar medidas de cobertura del site alrededor de toda la
zona de cobertura deseada para comprobar que los niveles de cobertura que se preveían
para la zona a cubrir son los deseados y chequear que se realizan todos los handovers
correctamente en los límites de las celdas.
Estas medidas se realizan mayormente por dos motivos: el primero de ellos es
revisar el funcionamiento del emplazamiento y la posible mejora de él, es decir, se
realiza con esto una primera optimización del site. El segundo motivo para realizar estas
medidas es para entregar un documento a la operadora que revele el perfecto
funcionamiento del site según lo esperado terminando así el proceso al que se le suele
denominar “autoaceptación” del emplazamiento.
La toma de estas medidas se denomina “Drive Test”. Se realizan circulando
alrededor de la zona a medir con un vehículo provisto de terminales móviles realizando
una batería de llamadas de voz y datos de prueba y de manera ininterrumpida
conectados a una herramienta que recopila toda la comunicación entre el terminal móvil
y la red, almacenando todos los mensajes y eventos producidos.
La herramienta más usada por los diferentes operadores para la realización de
los drive test es el TEMS Investigation (herramienta de Ascom, antes de Ericsson).
Figura 6.2.- Equipo Drive Test
140
Integración de una Estación Base en una Red Móvil Existente
Capítulo 6
Para la realización del informe de autoaceptación, se recopilan las medidas
obtenidas mediante la herramienta y se ilustran en un mapa mediante códigos de colores
para diferenciar las diferentes señales o eventos descritos.
Siendo fieles al alcance del proyecto, en el que estamos ilustrando cada uno de
los pasos poniendo ejemplos de las diferentes fases de los procesos, anexaremos a
continuación un ejemplo de las ilustraciones o plots presentados en la documentación
definitiva del informe de autoaceptación a presentar al operador.
•
Ejemplo de drive test para estación de GSM (en concreto GSM900):
En este caso se deberán ilustrar como mínimo dos plots, uno de ellos con el
mapeo de los BCCH, en el que se podrá ver de forma clara a qué sector han estado los
terminales móviles conectados mientras se circulaba por las distintas zonas de cobertura
deseada del site. Otro de los plots necesarios es el de RXLEVEL, como no, es el del
nivel de potencia recibida en el que se comprueba los niveles de cobertura reales
obtenidos por los terminales móviles recogidos por la herramienta usada.
Podemos ver a continuación ambos plots. En el primero observamos la zona que
cubre ambos sectores de este site ejemplo (sector1, BCCH=977, verde y sector2,
BCCH=981, rosa). Se puede observar que se detectan muestras del BCCH=979 que
puede ser de algún site vecino al que se ha hecho handover.
Figura 6.3.- Plot BCCH
141
Integración de una Estación Base en una Red Móvil Existente
Capítulo 6
En el segundo de los plots observamos los niveles de cobertura recibidos
mediante un código de colores. Estos niveles, en porcentaje, deben de superar unos
índices deseados e impuestos por la operadora para denotar al emplazamiento con
funcionamiento correcto y deseado.
Figura 6.4.- Plot RXLEVEL
•
Ejemplo de drive test para un Nodo B (UMTS):
En este caso se deberán ilustrar, al igual que en el caso anterior dos plots, uno de
ellos con el mapeo de los SC (códigos scrambling), en el que se podrá ver de forma
clara a qué sector han estado dando cobertura al terminal y otro plot del RSCP, es decir,
con los niveles de cobertura recibidos.
Ni que decir tiene que los niveles de cobertura recibidos dependen de muchos
factores. A modo de ejemplo, según la posición del site, altura de las antenas, downtilt y
azimuts de ellas es posible que alguna zona disponga de menor cobertura porque no se
hayan ajustado bien estos parámetros hardware. Mediante estas medidas se pueden
detectar estos detalles que pueden ser subsanados modificando dichos valores. También
es posible que la zona con menor nivel de cobertura sea imposible mejorarla puesto que
la propia topología del terreno no lo permite mediante el site instalado.
También se detectan detalles que pueden ser subsanados vía software, por
ejemplo pueden detectarse vecindades faltantes que a priori se suponían innecesarias.
142
Integración de una Estación Base en una Red Móvil Existente
Capítulo 6
A continuación vemos un ejemplo de ilustraciones de los scrambling codes y
cobertura de cada uno de los sectores del nodo que se ha medido.
Figura 6.5.- Plot SC
Figura 6.6.- Plot RSCP
143
Integración de una Estación Base en una Red Móvil Existente
Capítulo 6
6.4.- Documentación asociada
Tras las medidas de drive test se realiza un informe de autoaceptación o “first
tunning” del site en el que se han realizado las medidas.
Además de introducir en este informe los plots que en el apartado anterior hemos
indicado, también se insertan tablas en las que se resume el porcentaje de muestras
tomadas que están por encima del valor deseado. La operadora exige que este porcentaje
sea alto lo que indica que las muestras en la zona medida tiene valores de cobertura por
encima de lo deseado.
Se indicaría de forma similar a esta tabla:
% de muestras por encima del nivel
requerido
¿Cumple
requisitos?
99.94
99.92
100
SÍ
SÍ
SÍ
Sector 1
Sector 2
Sector 3
Figura 6.7.- Tabla resumen muestras por encima del nivel requerido
Además de esto, en el informe se puede acompañar con estadísticas de las
propias pruebas, es decir, el número de llamadas realizadas durante la prueba y el éxito
o fracaso que han tenido.
Sector 1
Sector 2
Sector 3
Intentos
llamada
%Caídas
¿Cumple
requisitos?
%Éxito
Conexión
¿Cumple
requisitos?
22
20
20
0
0
0
SÍ
SÍ
SÍ
100
100
100
SÍ
SÍ
SÍ
Figura 6.8.- Tabla resumen medidas
También se pueden incluir las propias estadísticas del site, al igual que se hizo
en la realización del informe básico tras el encendido, pero en este caso al llevar más
tiempo la estación cursando tráfico, tenemos más margen para sacar estadísticas e
incluso compararlas con las estadísticas que tenía la red del entorno antes de que se
encendiese el site. De esta forma se puede observar claramente si la incorporación de
nuestro nuevo site a mejorado o empeorado la red del entorno.
144
Integración de una Estación Base en una Red Móvil Existente
Capítulo 6
Conexiones
TCH
% Caídas
TCH
% Caídas
SDCCH
% Bloqueo
TCH
% Éxito HO
Vecinas. Semana -1
154770
0.39
0.92
0.38
98.22
Vecinas+BTS. Sem
+1
107163
0.46
0.65
0.33
97.75
Sector 1.
782
0.76
0.09
0
98.52
Sector 2.
1154
0.95
0.03
0.10
98.45
Figura 6.9.- Tabla resumen estadísticas
6.5.- Cambio de parámetros hardware y software
La realización de estas primeras medidas de cobertura, además de para elaborar
el informe de funcionamiento del site también sirven para una primera optimización del
emplazamiento modificando y mejorando valores que a priori parecían correctos pero
finalmente en el marco real en el que se encuentra el site pueden mejorarse.
Estos cambios o modificaciones pueden ser tipo hardware que, en la mayor parte
de los casos, es necesario realizar los cambios físicamente con la visita al site o tipo
software que se pueden asignar remotamente.
Los problemas más comunes detectados que se pueden mejorar o solucionar tipo
hardware son los siguientes:
•
Sectores cruzados: ocurre cuando se le asignan unos BCCH o SC a los sectores
y al realizar las medidas se observa que en realidad esa asignación no
corresponde con los sectores deseados. La solución a este problema consiste en
cablear los cables de las antenas del sector correcto a la toma correcta del sector
en el bastidor.
•
Falta de cobertura en una zona: es posible que una de las zonas en la que se
prevee que nuestro site aporte cobertura no lo hace, no por la topología del
terreno o por algún obstáculo que lo impida, sino por una elección no ajustada
del azimut de alguno de los sectores. En estos caso la solución o mejora puede
venir de ajustar mejor el azimut de alguno de los sectores de manera que el haz
horizontal cubra la zona deseada.
145
Integración de una Estación Base en una Red Móvil Existente
Capítulo 6
•
Subalcance o Sobrealcance: es posible que se detecte que el alcance de uno o
varios de los sectores no sea el deseado, esto puede venir dado por una elección
errónea de la altura de la antena pero en mayor medida es por una elección
errónea de la inclinación del haz, es decir del downtilt que se le ha definido a la
antena sectorial. La solución a esto consiste en ajustar mejor el downtilt del
sector que tiene el alcance no deseado. Ya vimos en el capítulo cuatro que este
downtilt puede ajustarse mecánicamente o eléctricamente.
•
Otros errores: es posible que otros errores hardware ocurran en nuestro site,
como mal funcionamiento de alguno de los equipos o mal conexionado del
cableado. En estos casos se detecta en las medidas que el sector afectado no se
aprecia o se aprecia muy defectuosos. En estos casos se trata de solventar el
problema sustituyendo el equipo defectuosos o cableando correctamente.
Los problemas más comunes detectados que se pueden mejorar o solucionar tipo
software son los siguientes:
•
Vecindades faltantes: Se pueden detectar en las medidas realizadas vecindades
faltantes puesto que al intentar realizar handover con esa vecindad la llamada se
cae provocando el cese de la llamada de prueba. Esto puede ocurrir, no por fallo
en la asignación de vecindades que a priori se ha diseñado, sino por la diferente
topología y orografía del terreno que hace que alguna vecindad lejana llegue a
hacer handover con nuestro sector o incluso en el sobrealcance de esa vecindad.
En estos caso la solución es sencilla, se incluye esa vecindad en la matriz de
vecinas ya definida para que cualquier terminal al intentar realizar handover no
pierda la llamada en curso.
•
Otros errores: es posible que los problemas detectados se deban a multitud de
errores en la parametrización del site y en la asignación de estos valores. Todos
los valores asignados en los datos radio y parámetros definen la manera de
funcionar del site y afectan a su funcionamiento. A modo de ejemplo algunos de
los valores de los que ya hablamos en el capítulo cuatro como la prioridad de
capa o “priority layer” que define qué celda tiene prioridad para dar servicio a un
usuario móvil en el caso de que el terminal móvil reciba cobertura de varias
celdas de distinta tecnología o un parámetro que define cuándo debe realizar
handover un terminal que recibe cobertura de varias celdas.
El ajuste de todos los parámetros se hará según crezca la red mediante el proceso
de optimización del site o la zona. Es necesaria una optimización continua de la red.
146