optimización radio de las tecnologías umts y lte...
TRANSCRIPT
UNIVERSIDAD POLITÉCNICA DE MADRID
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA Y SISTEMAS DE COMUNICACIÓN
Optimización Radio de las tecnologías UMTS y LTE Advanced mediante herramientas de gestión
de la Red Junio 2017
Autor: Raquel Ballestero Sánchez Tutor: Carlos Ramos Nespereira
PROYECTO FIN DE CARRERA PLAN 2000
RESUMEN DEL PROYECTO:
TEMA:
TÍTULO:
AUTOR:
TUTOR: Vº Bº.
DEPARTAMENTO:
Miembros del Tribunal Calificador:
PRESIDENTE:
VOCAL:
VOCAL SECRETARIO:
DIRECTOR:
Fecha de lectura:
Calificación: El Secretario,
TELEFONIA MOVIL
Optimización Radio de las tecnologías UMTS y LTE Advanced mediante herramientas degestión de la Red
RAQUEL BALLESTERO SANCHEZ
CARLOS RAMOS NESPEREIRA
INGENIERÍA TELEMÁTICA Y ELECTRÓNICA
JOSÉ MANUEL PARDO MARTÍN
ANTONIO DASILVA FARIÑA
A raíz del avance tecnológico de las redes y los dispositivos móviles, surge la necesidad desde eloperador de ofrecer a los usuarios la mejor calidad de servicio, para que así puedan ver satisfechas todassus demandas. El objetivo específico de este PFC es realizar un análisis de redes con tecnologías 3G(UMTS, HSDPA, HSUPA) utilizando para ello las herramientas de optimización y gestión CommonExplorer (CEX), Command Handling (CH) y MOshell, definiendo una estrategia de actuación sobre uncaso real. Asimismo, se extrapolará el caso al análisis de una red LTE para comprobar si sería viable o noel estudio realizado para 3G.
2
4
5
AGRADECIMIENTOS
Dentro de este proyecto hay una cantidad de personas que, de manera directa o indirecta han
aportado las ganas y motivación que necesitaba para cerrar esta etapa de mi vida.
En primer lugar, quiero mencionar y dar las gracias a mi tutor Carlos por el interés mostrado
desde el momento en que le planteé el tema como posible pfc, por los ánimos dados para
concluirlo y así poder titularme como ingeniera, por la predisposición para ayudar en las trabas
que he podido encontrarme durante el desarrollo del proyecto. Siempre te estaré
enormemente agradecida por ello.
Especial agradecimiento a mis padres y Álvaro; han sido un apoyo incondicional en cuanto les
planteé que ahora era el momento de terminar lo que había empezado. Sin ellos este libro no
lo habría acabado, me han dado la inyección que necesitaba en esos momentos de flaqueza,
nunca han dudado de mis posibilidades y es algo que no olvidaré jamás.
A mis antiguos compañeros de trabajo, muchos de ellos han ayudado sin esperar nada a
cambio con algunas dudas que me han surgido durante el desarrollo del proyecto.
A Raquel, Diego y Javier, ellos han sido mis consejeros cuando los he necesitado y nunca han
rechazado la ayuda que les he pedido en momentos puntuales. Os voy a estar eternamente
agradecida, chicos.
Y por último y no menos importante, a la UPM por darnos la oportunidad a los rezagados para
cerrar una etapa tan significativa en el futuro laboral.
Este proyecto es para y por vosotros.
GRACIAS
6
7
RESUMEN
En este proyecto fin de carrera se analizará la optimización de las funcionalidades y
parámetros de una red con tecnologías 3G y 4G, utilizando para ello diferentes herramientas
de gestión de red usadas por los operadores (Common Explorer (CEX), Command Handling
(CH) y Moshell), El objeto último de dicho análisis es comprobar si en la práctica se cumplen los
objetivos de prestaciones y calidad especificadas para una red determinada.
Para ello, se hará un estudio preliminar de las zonas donde se van a llevar a cabo trabajos de
reasignación de frecuencias, concretando el número de nodos, las provincias dónde se
implementan, el impacto que tendrá sobre la red, así como los tiempos de implementación de
las diferentes funcionalidades.
Una vez finalizado el estudio preliminar, se procederá a decidir la interfaz a través de la cual se
van a analizar las diferentes funcionalidades. Para ello, se utilizarán las prestaciones ofrecidas
por diferentes herramientas (tools) de optimización y gestión de red:
Common Explorer (CEX) y Command Hadling (CH) son herramientas de gestión (OSS) que
facilitan la implantación de nuevas funcionalidades y la extracción de datos de la red, tales
como la definición de nuevas relaciones de vecindad o cambios masivos de parámetros que
pueden optimizarse a través de OSS.
MOshell, herramienta de acceso a la red de UMTS y LTE. Permite la conexión directa a la RNC y
RBS para la realización de diferentes operaciones y consultas de parámetros. A través de
MOshell se puede ver en tiempo real datos y parámetros de diferentes elementos de red,
simplemente conectándose a la dirección IP de la RNC o nodo.
Para realizar el análisis de la red se procederá a preparar los diferentes archivos de
implementación (scripts) que se utilizarán en el trabajo y, posteriormente, se aplicarán a los
elementos de la red utilizando las funcionalidades de las herramientas descritas. Habrá que
tener en cuenta los posibles escenarios y situaciones que pueden producirse, como un fallo en
el script de carga o la detección de una degradación al llevar a cabo la optimización.
8
9
ABSTRACT
This project thesis will discuss optimization capabilities and parameters of a network with 3G
and 4G technologies, using different tools of management network used by operators
(Common Explorer (CEX), Command Handling (CH) and Moshell). The object of this analysis is
to check compliance objectives specified for a particular network performance and quality in
practice.
There will be a preliminary areas of study where they will carry out work of reallocation of
frequencies, specifying the number of nodes, the provinces where are implemented, the
impact that will have on the network, as well as the time of implementation of the different
features.
After preliminary study, will proceed to decide the interface through which to scan the
different functionalities. The benefits offered by different tools (tools) of network
management and optimization will be used:
Common Explorer (CEX) and Command Hadling (CH) are management tools (OSS) that
facilitate the implementation of new functionalities and the extraction of data from the
network, such as the definition of new relations of neighborhood or massive changes of
parameters that can be optimized through OSS.
AMOS/MOshell, tool access to the UMTS and LTE network. It allows direct connection to the
RNC and RBS for the realization of various operations and query parameters. Through
AMOS/MOshell you can see real-time data and parameters of different network elements,
simply by connecting to the IP address of the RNC or node.
For the analysis of the network will be to prepare the different implementation files (scripts)
that will be used in the work and, subsequently, apply to the network elements using the
functionality of the described tools. We must take into account the possible scenarios and
situations that may occur, as a fault in the load script or detection of degradation to carry out
optimization.
10
11
Contenido INDICE DE FIGURAS Y TABLAS ................................................................................................. 13
1. INTRODUCCIÓN ............................................................................................................... 17
Justificación del proyecto .................................................................................................... 18
2. MARCO REFERENCIAL...................................................................................................... 21
Origen y evolución de la tecnología móvil .......................................................................... 21
Sistema UMTS: Evolución y características ......................................................................... 25
Sistema LTE: Evolución y características ............................................................................. 29
3. PROCEDIMIENTO ............................................................................................................. 35
OSS. Definición y objetivos. ................................................................................................. 35
Introducción AMOS/ Moshell, OSS Common Explorer y Command Handling ................... 40
Aprendizaje herramienta Moshell/AMOS ........................................................................... 40
Aprendizaje herramienta OSS Common Explorer (CEX) ...................................................... 77
Aprendizaje herramienta Command Handling Application (CHA) .................................... 104
ESCENARIO REAL ............................................................................................................... 111
Descripción situación inicial .............................................................................................. 111
Planteamiento del problema ............................................................................................ 115
Posibles soluciones. Parametrización a utilizar ................................................................. 118
4. OPTIMIZACION DE REDES 3G/LTE ................................................................................. 123
OPTIMIZACION RED UMTS ................................................................................................ 123
OPTIMIZACION RED LTE Advanced ................................................................................... 129
5. APLICACIÓN DE SOLUCIONES MEDIANTE EL USO DE HERRAMIENTAS ......................... 135
Implementación manual. Moshell/AMOS y Command Handling .................................... 135
Posibles recursos para optimizar la implementación manual. Scripts. ............................. 144
Implementación automática mediante archivos xml. Common Explorer (CEX) ............... 149
6. RESULTADOS ................................................................................................................. 155
7. CONCLUSIONES Y RECOMENDACIONES ........................................................................ 157
8. BIBLIOGRAFÍA ................................................................................................................ 159
12
13
INDICE DE FIGURAS Y TABLAS
F
Figura 1. Evolución temporal de la generación celular ................................................................................. 9
Figura 10. Estructura de la clase Managed Object (MO) ........................................................................... 30
Figura 11. Ejemplo de script de consulta (.sh) ............................................................................................ 47
Figura 12. Formas de lectura de las estadísticas ........................................................................................ 48
Figura 13. Entorno gráfico de la vista de topología en CEX ........................................................................ 65
Figura 14. Vista de explorador de MOs mediante combinación de cuadros .............................................. 67
Figura 15. Vista de explorador de MOs mediante campo de texto editable .............................................. 67
Figura 16. Vista explorador de MO mostrando menú alternativo de creación/edición de MOs. ............... 68
Figura 17. Selección de la vista de propiedades en relación con la topología ............................................ 69
Figura 18. Vista de propiedades en CEX ..................................................................................................... 70
Figura 19. Definición visualizada al situar el ratón sobre el nombre del parámetro .................................. 70
Figura 2. Previsión del desarrollo de las nuevas tecnologías ...................................................................... 12
Figura 20. Opción de búsqueda dentro de la vista de propiedades ............................................................ 71
Figura 21. Cuadro de diálogo para confirmar las modificaciones en los parámetros indicados ................ 72
Figura 22. Pasos para definir una celda en la vista de comparación de MOs ............................................ 73
Figura 23. Cambiar valor de un atributo en la vista de comparación de MOs ........................................... 74
Figura 24. Modificación del valor en los objetos que aparecen en la vista ................................................ 74
Figura 25. Vista de filtro en CEX ................................................................................................................. 75
Figura 26. Ejemplo de formato drop down selections para el filtro Open .................................................. 76
Figura 27. Opciones que da Filter option .................................................................................................... 76
Figura 28. Formato del filtro check box ...................................................................................................... 77
Figura 29. Formato Relational operators .................................................................................................. 77
Figura 3. Elementos arquitectura red UMTS .............................................................................................. 13
Figura 30. Formato Mixed .......................................................................................................................... 78
Figura 31. Barras de progreso en la vista por la carga de alarmas o elementos seleccionados ................ 79
Figura 32. Vista Bulk CM Progress de CEX .................................................................................................. 81
Figura 33. Vista Sub-Network Consistency Report de CEX .......................................................................... 82
Figura 34. Cuadro de diálogo al solicitar exportar información de la vista de propiedades ...................... 83
Figura 35. Vista de filtro cuando la vista de informe de consistencia de subred de la red está activa....... 83
Figura 36. Vista de relaciones de CEX ......................................................................................................... 84
Figura 37. Cuadro de búsqueda avanzada ................................................................................................. 86
Figura 38. Menú contextual de CEX para abrir otras aplicaciones ............................................................. 87
Figura 39.Visualización de elementos desde la vista de Topología seleccionando diferentes páginas ...... 88
Figura 4. Red HSDPA/WCDMA ................................................................................................................... 16
Figura 40. Aspecto del interfaz gráfico de CHA .......................................................................................... 91
Figura 41. Mensaje de respuesta retardada............................................................................................... 92
Figura 42. Mensaje emergente que aparece al indicar un comando peligroso .......................................... 94
Figura 45. Situación geográfica de las áreas rurales con respecto a Cuenca y a los nodos ....................... 96
Figura 46. Distancia del nodo más cercano de Cuenca al municipio de Nohales ....................................... 97
Figura 47. Distancia del nodo más cercano de Cuenca al municipio de La Melgosa .................................. 98
Figura 48. Situación geográfica de las áreas rurales con respecto a Segovia y a los nodos ....................... 99
Figura 49. Distancia del nodo más cercano de Segovia al municipio de San Cristóbal de Segovia ........... 99
Figura 5. Representación arquitectura LTE................................................................................................. 20
Figura 50. Distancia del nodo más cercano de Segovia al municipio de Perogordo ................................. 100
Figura 51. Situación geográfica de los municipios rurales con quejas de clientes .................................... 102
14
15
Figura 52. Principales categorías de los KPIs para el control del estado de la red ................................... 108
Figura 53. Representación gráfica de los tipos de Handover Intra-freq entre dos celdas ........................ 112
Figura 54. Clasificación de los principales KPIs por categorías en LTE ..................................................... 114
Figura 55. Representación de las principales relaciones de vecindad a definir entre celdas de la misma
tecnología ............................................................................................................................................ 124
Figura 56. Representación de las principales relaciones de vecindad a definir entre celdas de la misma
tecnología ............................................................................................................................................ 127
Figura 57. Estructura fichero .txt para bloquear la tecnología 2G ........................................................... 128
Figura 58. Ejemplo de código para el script de definición de nuevas celdas ............................................ 130
Figura 59. Final del ejemplo de código del script para la definición de nuevas celdas ............................. 130
Figura 6. División espectral en España ......................................................................................................... 7
Figura 60. Ejemplo de script para la creación de vecindades en las nuevas celdas definidas ................. 131
Figura 61. Final del código para la definición de nuevas relaciones en las nuevas celdas ....................... 131
Figura 62. Extracto del código del script a utilizar para definir las nuevas celdas 4G .............................. 132
Figura 63. Extracto del fichero xml para la creación de vecinas ............................................................... 134
Figura 64. Vista de CEX donde se crean las planned área para definir las nuevas vecinas ...................... 135
Figura 65. En Bulk CM Progress aparecerán todas las Planned Area que se han importado ................... 136
Figura 7. Capa gestión de la red ................................................................................................................. 22
Figura 8. Formas de acceso para AMOS/Moshell ....................................................................................... 27
Figura 9. Jerarquía de la clase MO ............................................................................................................. 29
T
Tabla 1. Características técnicas WCDMA .................................................................................................. 15
Tabla 11. División de frecuencias para los principales operadores móviles en España ............................ 100
Tabla 12. Tecnologías disponibles en el cluster de nodos de Cuenca ....................................................... 101
Tabla 13. Tecnologías disponibles en el cluster de nodos de Segovia ...................................................... 103
Tabla 14. Valores a establecer en uarfcndl y uarfcnul para la nueva frecuencia 3G ................................ 105
Tabla 15. Valores a establecer en earfcndl y earfcnul para la nueva frecuencia de 4G .......................... 106
Tabla 16. Rango mínimo de valores en los KPIs de accesibilidad ............................................................. 108
Tabla 17. Celdas 2G a apagar para liberar la frecuencia 900Mhz ........................................................... 119
Tabla 18. Nombres de las celdas definidas para la nueva frecuencia 900Mhz ........................................ 121
Tabla 19. Nombres de las celdas definidas para la nueva frecuencia 800Mhz ........................................ 126
Tabla 2. Aplicaciones disponibles en el OSS ................................................................................................ 24
Tabla 20. Atributos de Utrancell ............................................................................................................... 133
Tabla 3. Posibles estados atributos de MOs ............................................................................................... 30
Tabla 4. Comandos para operaciones de gestión de la configuración ....................................................... 31
Tabla 5. Comandos para operaciones de gestión de los fallos ................................................................... 31
Tabla 6. Comandos más importantes en Moshell/AMOS ........................................................................... 33
Tabla 7. Opciones comando BL ................................................................................................................... 41
Tabla 8. Principales comandos PM para Moshell ....................................................................................... 49
16
17
1. INTRODUCCIÓN
En la sociedad actual nos encontramos con diferentes formas de comunicación que nunca hubiésemos imaginado, utilizando nuestro terminal móvil y comunicándonos por vía telefónica o bien por medio de mensajería instantánea, a través, de un operador móvil con el que se ha contratado una serie de calidades de servicios (QoS), tanto de voz como datos.
La evolución en este aspecto es notoria, si bien el avance de la tecnología móvil y las necesidades de los usuarios han marcado los objetivos y tiempos en el desarrollo de las redes de los operadores de telefonía. La aparición de los Smartphone han marcado un antes y después en la red móvil, creciendo a pasos agigantados en los últimos seis años.
Se ha pasado del uso de tecnologías de acceso a radio como GSM, UMTS a la implementación de mejoras posteriores como HSDPA para llevar todas las funcionalidades de la red 3G al máximo potencial en prestación de servicios en banda ancha. Además en los últimos años ha hecho su aparición LTE, tecnología desarrollada principalmente para cubrir una serie de necesidades de diferentes colectivos: en cuanto a los usuarios, demandan una conexión de datos más rápida y a nivel de fabricación se busca un estándar menos complejo reduciendo además costes.
Y dado que estas tecnologías están íntimamente relacionadas con los modelos de terminales que hay en el mercado, los usuarios que posean móviles de última generación buscarán que las prestaciones ofrecidas por los operadores móviles se adapten a lo que necesitan, que los parámetros de QoS contratados se cumplan.
La manera en la que podremos mantener todas las funcionalidades de UMTS/WCDMA y llevarlas al máximo potencial en prestación de servicios en banda ancha, introduciendo nueva parametrización para controlar nuevas funcionalidades (features) que aporten esa mayor calidad del servicio solicitada, será a través de la optimización de la tecnología espectral HSDPA (High Speed Downlink Packet Access).
En LTE Advanced se optimizan apenas parámetros, ya que ésta tecnología tiene muchas funcionalidades automáticas y está pensada para que la optimización sea dinámicamente realizada por la propia red.
El avance de la tecnología móvil y tras la aparición de UMTS, HDSPA y LTE surge la necesidad de extender los conocimientos teóricos al ámbito práctico para observar el comportamiento de estas redes bajo diferentes condiciones y establecer comparaciones con los resultados que se esperan con el uso de las herramientas presentadas en esta introducción.
Se planteará, por lo tanto, un trabajo específico donde se analicen la optimización de las diferentes funcionalidades y parametrización de una red 3G y, aplicando los conocimientos sobre las herramientas, definiéndose una estrategia de actuación revisando si lo estudiado anteriormente, en la práctica cumple con lo marcado como objetivo (cumplimiento de KPIs fijados, throughput de usuarios, etc). Se analizarán, además, las consecuencias de trasladar el caso planteado al 4G, viendo si sería viable repetir el procedimiento práctico detallado para la tecnología UMTS y si no fuera así, cómo debería proceder en el plano teórico y aplicado al práctico.
18
En el ámbito teórico, se hará un estudio preliminar del contexto donde se va a aplicar el trabajo abarcando el número de nodos, la provincia donde se implementa, el impacto que tendrá sobre la red así como los tiempos de implementación de las funcionalidades.
Una vez finalizado el trabajo preliminar, se procederá a decidir la interfaz a través de la cual se van a implementar los cambios. Para ello, hay varias aplicaciones (tools) en las que nos centraremos: Common Explorer (CEX) es una herramienta del gestor de la Red (OSS) que facilita tanto implementar y extraer información de lo que hay en la red, como definir nuevas relaciones de vecindad o cambios masivos de parámetros que pueden optimizarse a través de OSS. MOshell/Amos, herramienta de acceso a la red de UMTS y LTE, permite conectar directamente a la RNC o RBS donde se quiere hacer una consulta o cualquier otra operación. A través de MOshell/Amos se visualiza lo que hay en el momento definido en los diferentes elementos que forman la red, conectándose a la IP de la RNC o nodo en cuestión.
Ya con el conocimiento del funcionamiento de las herramientas, se procede a preparar los diferentes archivos de implementación (scripts) que se utilizarán en el trabajo y posteriormente se aplican a través de la herramienta o herramientas seleccionadas. Habrá que tener en cuenta los posibles escenarios a los que podemos enfrentarnos, como un fallo en el script de carga o la detección de una degradación al llevar a cabo la optimización, por ejemplo.
Como conclusión, se puede afirmar que, el poder controlar el funcionamiento y el estado de
cada operador con CEX y MOshell/Amos, facilita el trabajo y agiliza la corrección de los
problemas que puedan darse en un momento dado, minimizando el impacto en la red y
evitando molestias en los usuarios que luego pudiese repercutir en su vida cotidiana.
El objetivo del PFC es el estudio de la reasignación de frecuencias en redes UMTS y LTE
utilizando las herramientas de OSS citadas, que permiten reducir tiempos y coste con respecto
a la implementación manual por parte de uno o varios ingenieros.
Justificación del proyecto
Con la palabra inglesa Refarming nos estamos refiriendo a la reutilización de frecuencias con
otras tecnologías diferentes a las previstas en un principio. El objetivo de este proyecto fin de
carrera es entender esta práctica impulsada por los diferentes países, conocer las
herramientas que se necesitan para llevarlo a cabo y el perfil técnico necesario para su éxito.
Este proceso es necesario y conveniente para maximizar el uso del espectro radioeléctrico, por
ello la Unión Europea está apoyando – mediante medidas regulatorias – a todos los países
miembros a llevar a cabo su implantación. Hay unos que lo han puesto en práctica antes que
otros, como por ejemplo Finlandia.
La reasignación se está tratando como una buena oportunidad de expansión para los servicios
de UMTS que ayude a mejorar la cobertura indoor, afectando esto positivamente a la calidad
de acceso a Internet en banda ancha desde el dispositivo móvil. Además, se conseguirá con
19
esto una menor inversión en zonas rurales que permitirán la extensión de la banda ancha a
éstas áreas.
Enfocando a nivel nacional, existen diferentes operadores que están reclamando la utilización
de las frecuencias de GSM – las bandas 900MHz y 1800MHz, propiedad de Telefónica – para
una competición en igualdad de condiciones; por ello, Vodafone, Orange y Yoigo solicitan
5MHz de estas bandas. Finalmente Yoigo no participó en la subasta celebrada en 2011,
produciéndose el reparto entre el resto de operadores.
Figura 6. División espectral en España (1)
Hasta hace relativamente poco tiempo estas bandas eran exclusivas para la tecnología GSM
según las condiciones de adjudicación de las licencias, pero en la actualidad se están utilizando
para otras tecnologías de acceso radio como WCDMA (inicialmente ubicada en 2100MHz). Esto
se ha llevado a cabo debido a que las frecuencias más bajas tienen ventaja frente a las más
altas, como por ejemplo en la penetrabilidad y alcance en el interior de los edificios. Teniendo
en cuenta estas características, se necesitan un menor número de antenas para dar la misma
cobertura y esto se traduce en la reducción del coste del despliegue de red en cualquier zona
urbana o rural. Centrándonos en la parte económica, esto se traduce en un desembolso inicial
menor de la inversión que tendrían que hacer los operadores, facilitando además los trámites
para la obtención de los sites.
Pero según se ha ido avanzando, con la llegada de LTE surgía la misma problemática en cuanto
a la asignación de frecuencias para la tecnología. La Secretaría de Estado de
Telecomunicaciones y para la Sociedad de la Información (SETSI) asignó a 4G/LTE las
frecuencias 1800 y 2600MHz, y ya en 2014/15 se añadió 800MHz. Como hemos mencionado
anteriormente para 3G, la estrategia de utilización se ha centrado en las frecuencias más bajas
por el menor desembolso económico y a nivel de infraestructura que esto supone.
Por todo lo mencionado en este apartado se presentará un caso teórico-práctico centrado en
la asignación de frecuencias para un cluster de nodos en 3G y LTE, enfocándonos en la
20
utilización de las tools proporcionadas por los proveedores a los operadores y las ventajas de
este tipo de prácticas. (1) (2)
21
2. MARCO REFERENCIAL
Cuando se habla de la evolución tecnológica de las comunicaciones tenemos que remontarnos
sorprendentemente a la década de los 60, cuando ya se hablaba del concepto networking1
ligado íntimamente a lo que actualmente es esencial para el Mundo: Internet.
Y más allá de esto, está el desarrollo de las comunicaciones móviles acompañado de la
fabricación de novedosos terminales y que nos permiten disfrutar de datos en cualquier lugar2.
Pero, ¿en qué consiste ese desarrollo del que hablamos? ¿Cómo han ido evolucionando los
sistemas móviles celulares?
La evolución de la telefonía celular con la integración de nuevos servicios y la mejora en la
calidad de la comunicación comienza con la aparición del 1Gi utilizando estos móviles y
prosigue en la actualidad con el despliegue de LTE, desarrollando la cuarta generación de
terminales móviles denominada 4G.
Origen y evolución de la tecnología móvil
Inicialmente, la tecnología móvil se concibió únicamente para voz en los años 403 permitiendo
la comunicación mediante ondas de radio cuya banda de frecuencias no superaban los 600
kHz; se disparó la utilización de la modulación en frecuencia- más conocida como FM- frente a
la modulación en amplitud, AM- dada su superior calidad audio y la gran resistencia a
interferencias. A finales de los años 50 un científico soviético, Leonid Ivanovich Kupriyanovich4,
diseñó y desarrolló sistema de comunicación que consistía en el aprovechamiento de las ondas
de radio y alcanzando una distancia máxima de 30km, pudiendo dar servicio a varios clientes.
Una vez patentado el teléfono móvilii, Kupriyanovich comenzó una investigación y desarrollo
que culminó en la aparición de un diseño más pequeño y cuyo alcance era superior a 30km.
En cuanto al servicio ofrecido con estos equipos, la compañía Bell5 fue pionera en definir el
primer servicio móvil, denominado System Service. No fue demasiado popular dado su elevado
coste y estuvo operando con actualizaciones desde 1945 hasta 1985. A día de hoy, echando la
vista atrás, podemos visionar la mejora notoria en ambos aspectos: tanto de los servicios
ofrecidos como la mejora de las prestaciones del terminal móvil hasta la cuarta generación de
Smartphones.
1 Networking, trabajo en red. Concepto definido por el norteamericano Joseph Carl Robnett Licklider (1915-1990), considerado pionero de Internet. 2 Servicio de datos en movilidad para los clientes con Smartphone que lo contraten. 3 Durante la 2ª Guerra Mundial (1939-1945) Motorola desarrolla un equipo denominado Handie talkie H12-16, permitiendo esto la comunicación con las tropas. 4 Desarrollador del sistema de comunicación inalámbrica, predecesor de la actual telefonía móvil (1929). 5 Los Laboratorios Bell presentaron en 1947 un sistema de servicio móvil de gran capacidad basado en la idea celular. La introducción de transistores fue fundamental para su desarrollo y en 1955, ya se hicieron demostraciones en Madrid.
22
Figura 1. Evolución temporal de la generación celular
Teniendo en cuenta la imagen anterior donde está reflejado el desarrollo en el tiempo de las
cuatro generaciones que hay en la actualidad, vamos a definir cada una de ellas para aclarar
las diferencias que hay:
Los sistemas de primera generacióniii se desarrollaron a finales de la década de los 70
ofreciendo un único servicio, el de llamadas de voz (telefonía). Los más destacados
serían: NMT (Nordic Mobile Telephony), ANMPS (Advanced Mobile Phone Service) y
TACS (Total Access Communication System), este último es una adaptación europea del
sistema AMPS desarrollado por la Administración de Reino Unido.
Los sistemas de segunda generacióniv difieren con respecto a la primera en que
emplean transmisión digital en la interfaz Radio. Además, introduce mejoras en la
calidad y seguridad (cifrada) de llamadas de voz, así como más capacidad. Cabe
destacar en esta generación surgida a principios de los 90 la introducción de otros
servicios novedosos como los mensajes cortosv y datos en modo circuito. Entre los
principales sistemas 2G debemos destacar IS-54 e IS-56 (conocidos como D-AMPS,
versión digital de AMPS), IS-95/cdmaOne (conocido como CDMA, Code Division
Multiple Access), Cellular PCS/IS-136 (conocido como TDMAvi, sistema que está
regulado por la TIA6), PHS (Personal Handyphon System) que fue inicialmente utilizado
en Japón por la compañía NTT DoCoMo con el objetivo de focalizar el estándar en la
6 TIA, Telecommunications Industry Association
23
transferencia de datos diferenciándose del resto de sistemas. Destacar el sistema GSM
(Global System for Mobile Communications) como la tecnología 2G más importante, ya
que con diferencia es la más utilizada a nivel mundial.
Pero una de las principales limitaciones de esta generación más notoria es la baja
velocidad de transmisión de datos; por ejemplo, los servicios de datos modo circuito
de GSM ofrecen un máximo de 9.600 bits por segundo. Por este motivo, se evolucionó
2G al llamado 2’5G que no llega a ser como tal una nueva tecnología, pero si aporta
nuevas extensiones como HSCSD (High-Speed-Circuit-Switched Data), GPRS (General
Packet Radio Service) y EDGE (Enhanced Data rates for GSM Evolution)
Los sistemas de tercera generación7 aparecieron ante las limitaciones del 2G y sus
extensiones anteriormente mencionadas por la creciente demanda de mayores
caudales para acceder a Internet y el soporte de servicios avanzados (en especial, los
servicios multimedia). La respuesta a estas peticiones es el desarrollo de los sistemas
UMTS (Universal Mobile Telecommunications System) y CDMA2000, lo que ha
supuesto una serie de mejoras de capacidades y prestaciones frente a sus antecesores.
En el plano geográfico, tenemos en Europa como sistema 3G de despliegue UMTS
mientras en el resto del mundo, este rivaliza con el CDMA2000, sistema que es de gran
dominio principalmente en EEUU. A nivel de red, UMTS es visto como una evolución
del sistema GSM, pero con una interfaz radio de mayor capacidad y eficiencia; por otro
lado, CDMA2000 es visto como una mejora del sistema CDMA8.
Centrándonos en UMTS, estas redes se basan en un conjunto de especificaciones del
3GPP9 denominado Release 99 (R99). Pero esta versión del estándar UMTS se ha
quedado corta, introduciendo los operadores mejoras para versiones posteriores; se
trata de las tecnologías HSPA, término que hace referencia a un grupo de extensiones
de la interfaz radio UMTS origen, y que se desarrollan para garantizar la mejora de
prestaciones en sentido descendente (HSDPA) y ascendente (HSUPA). Estas
extensiones se definieron en las Release 5 y 6 respectivamente del 3GPP; con ellas es
posible alcanzar tasas de pico teóricas de hasta 14,4 Mbit/s en DL y 2Mbit/s en UL. Las
prestaciones de estas tecnologías son comparables a las de una línea ADSL de 6-10
Mbit/s.
La implantación de las tecnologías HSPA puede considerarse como la entrada a los
sistemas de comunicaciones móviles 3´5G. Pero el incremento del tráfico en la red
móvil implica la mejora de esta, introduciendo los operadores nuevas extensiones
como HSDPA evolucionado (conocida como HSPA+) y LTE10.
La implantación de HSPA+ y LTE marcan la entrada de los sistemas de cuarta
generación, 4G, cuyos servicios comenzaron a ofrecerse por parte de los principales
7 Generación multimedia 8 CDMA sistema comercializado por la compañía Qualmmon y estandarizado por la organización norteamericana TIA con el nombre IS-95. 9 3GPP, Third Generation Partnership Project 10 LTE, Long Term Evolution
24
operadores en 2013. Una de las características de la utilización de este nuevo sistema
es la mejora de cobertura obtenida y transmisión de datos gracias a la utilización de la
banda de 800MHz. En cuanto a la transmisión de datos, las velocidades de bajada
aumentan hasta 300Mbps (37,5 Mbit/s) gracias a la técnica Carrier Agregation,
mediante la cual se harán uso de tres bandas para enviar señales.
Pero debemos tener en cuenta que hay cierta limitación de estos sistemas, puesto que
nuestro terminal móvil tiene que ser compatible con todas las bandas 4G; es necesario,
por tanto, que el Smartphone adquirido por el usuario final soporte las bandas 3/7/20.
En cuanto a la estructura de red en UMTS y su adaptación a nuevos sistemas como LTE,
los cambios son mínimos y pueden ser aplicados gradualmente. A la par que LTE, HSPA
continúa su evolución para mejorar las prestaciones en la tasa de pico de los usuarios
con buena señal. Los operadores con la red 3.5G desplegada se encuentran con la
disyuntiva de si aplicar las mejoras de HSPA+ o adoptar directamente LTE. En
operadores donde solo la red 2G está desplegada el salto a LTE será más inmediato.
A pesar de que actualmente el 4G se encuentra en pleno despliegue nacional, operadores
están mirando más allá y preparando un nuevo salto hacia 5G. La previsión es el futuro
despliegue del nuevo sistema de comunicación móvil hacia el año 2020. Para ello, ya se está
trabajando en prototipos y pruebas para que, en los próximos años se desarrolle un estándar
y productos para el despliegue programado.
Figura 2. Previsión del desarrollo de las nuevas tecnologías
25
Sistema UMTS: Evolución y características
En contraposición a los sistemas de transmisión que utilizan medios de comunicación tales
como la fibra óptica o cobre, el espectro radio es compartido por diferentes tecnologías
potencialmente interferentes.
Como consecuencia, los organismos reguladores, en concreto ITU-R11, desempeñan un papel
muy importante en la evolución de las tecnologías radio desde que deciden qué partes del
espectro y qué cantidad de ancho de banda puede ser utilizado por determinados tipos de
servicio y tecnología. Este rol se ve facilitado por la normalización de las familias de las
tecnologías radio – proceso que no sólo proporciona la especificación de interfaces para
garantizar la interoperabilidad entre equipos de múltiples vendors (Huawei, ZTE, Ericsson, por
ejemplo), sino que también pretende garantizar que el espectro que se ha asignado se utiliza
de la manera más eficiente que sea posible, proporcionando al usuario final servicios
innovadores y una experiencia única.
Centrándonos en lo que este apartado presenta, hablaremos de la tecnología UMTS – también
llamada 3G o WCDMA - como una de las utilizadas por los terminales móviles de tercera
generación. Esta generación tiene como principales las siguientes características:
Permite la transmisión de datos a alta velocidad
Soporta IP y ATM posibilitando así el acceso a Internet
Tras el lanzamiento de GSM, de manera casi simultánea, se empezó a trabajar para la
definición del UMTS. Este cometido fue llevado a cabo por el comité SMG (Special Mobile
Group). Ya hemos hablado anteriormente a grandes rasgos de las diferencias entre 2º y 3º
generación, por lo que vamos a centrarnos en este apartado en las características estructurales
de UMTS.
Estructura de la red UMTS
La imagen que se ve a continuación representa los elementos que forman la arquitectura
básica de red UMTS y que es explicada más en detalle en este punto.
11 ITU-R, International Telecommunication Union – Radiocommunication Sector
26
Figura 3. Elementos arquitectura red UMTS
Una red UMTS consta de 3 dominios interactivos:
Core Network (CN). Proporciona todo el procesamiento y la gestión central para el
sistema. Es, por lo tanto, la entidad global que se conecta a redes externas incluyendo
la red telefónica pública y otras redes de telecomunicaciones celulares. El núcleo de
Red proporciona funciones de transporte – de la información de tráfico y señalización,
incluyendo la conmutación - y de inteligencia – el encaminamiento, que comprenden
prestaciones como la lógica y el control de servicios ofrecidos a través de una serie de
interfaces bien definidas; también se encarga de la gestión de la movilidad-.
Red de acceso Radio (UTRAN). También conocido como Radio Subsistema de Red
(RNS), proporciona y maneja la interfaz aérea de la red global. Proporciona la conexión
entre UE y CN. En UMTS recibe el nombre de UTRAN y está compuesto de una serie de
subsistemas de redes de radio, RNS, modo de comunicación de la red. En cuanto a las
funciones de un RNS, asume la responsabilidad de los recursos y
transmisión/recepción en un grupo de celdas y está formado de una RNC y uno o
varios NodeB; los nodos B se corresponden con las estaciones base. La RNC
(Controlador de la red Radio) es responsable del control de los recursos lógicos de una
BTS (Estación Base Transmisora).
Equipo de usuario (UE). Es la interfaz final con el usuario. Se compone de una tarjeta
SIM (USIM para los sistemas UMTS) que contiene el número de identificación de
abonado móvil internacional (IMSI), así como el número ISDN internacional de
estación móvil (MSISDN). El formato más común de UE es el terminal móvil, pero se
debe tener en cuenta que puede ser cualquier dispositivo que tenga capacidad de uso
de una USIM. También forman parte del UE las redes de transmisión utilizadas para
enlazar los distintos elementos que la integran (como por ej. los protocolos UU y IU)
Para entender mejor la relación entre los elementos que componen la red UMTS, pondremos
un ejemplo que ayudará a situar lo explicado anteriormente:
27
Con un dispositivo 3G (UE) los datos llegan al NodoB, encargado de captar las señales emitidas
por los terminales. Esta información pasa al RNC para procesarla; llamamos UTRAN al conjunto
de NodoB y RNC y desde él, pasa la información al núcleo de la red que está dividido en
conmutadores que distribuyen los datos por los diferentes sistemas. Según vayan a uno u otro
pasarán bien por el MSC12 o por el SGSN13 para después dirigirse al GGSN14.
Como se ha mencionado al principio de este apartado, el núcleo UMTS se plantea como una
evolución de las redes 2G existentes en el momento del lanzamiento, basadas en GSM/GPRS y
en la reutilización de la infraestructura disponible en éstas. La gestión de recursos radio toma
gran relevancia en UMTS gracias a la utilización de WCDMA. Las principales ventajas que
WCDMA proporciona al UMTS:
Convergencia de redes fijas y móviles; igual calidad de servicio.
Servicios multimedia simétricos y asimétricos.
Roaming global
Asignación dinámica de ancho de banda (hasta un máximo inicial de 2Mbps).
Acceso personalizado mediante VHE15, definiendo un perfil de servicio constante y
homogéneo independientemente de la red que sirve al abonado.
Tecnología de paquetes (allways-on) y protocolos IP
Soporte para una amplia gama de terminales Capacidad de una alta densidad de usuarios
Tecnología espectral UMTS/WCDMA y evolución al HSDPA/HSUPA
Cuando hablamos de WCDMA - Wideband Code Division Multiple Access, en español Acceso
múltiple por división de código de banda ancha - hacemos referencia a la tecnología de acceso
móvil en la que se basan varios estándares de 3G, entre ellos el que nos atañe en este
apartado, el estándar UMTS.
Con WCDMA podemos transmitir datos al mismo tiempo y utilizando la misma frecuencia
siendo una manera muy efectiva, especialmente si hay limitaciones en el medio como por
ejemplo el aire. Se basa en un protocolo de varias capas, cada una de ellas con diferentes
funciones y servicios, con interfaces para la comunicación entre ellas y con una serie de
procedimientos para lograr la comunicación entre móviles (transferencia de datos y voz) en
una red celular.
El WCDMA tiene dos modos de operación:
Frequency Division Duplex (FDD). Los enlaces ascendente y descendente utilizan
canales de 5MHz diferentes y separados por una frecuencia de 109MHz. Los sistemas
utilizan el WCDMA-FDD.
Time Division Duplex (TDD). El enlace de subida y bajada comparten la misma banda de
5MHz.
12 MSC, Mobile services Switching Center 13 Serving GPRS Support Node 14 Gateway GPRS Support Node 15 Virtual Home Environment
28
WCDMA utiliza como método de múltiple acceso el CDMA Secuencia Directa (DS-CDMA), con
varios terminales compartiendo una misma banda de frecuencias pero utilizando códigos
diferentes de spread spectrum16. Características técnicas:
WCDMA
Método de múltiplo acceso DS-CDMA, Secuencia Directa CDMA
Factor de reuso de frecuencia 1
Banda por portadora 5 MHz
Chip rate 3,84 Mcps
Frame 10 ms (38400 chips)
Nº de slots/frame 15
Nº de chips/slot 2560 chips (Max. 2560 bits)
Factor de enlace ascendente ensanchado 4 a 256
Factor enlace descendente ensanchado 4 a 512
Tasa del canal 7,5 Kbit/s a 960 Kbit/s.
Tabla 1. Características técnicas WCDMA
La tecnología HSDPA (High Speed Downlink Packet Access) es la evolución más reciente de
UMTS/ WCDMA y que está incluida en las especificaciones de 3GPP Release 5. Consiste en un
nuevo canal compartido en el enlace descendente que mejora de manera notoria la capacidad
máxima de transferencia de información alcanzando tasas de hasta 14Mbps. Soporta tasas de
Throughput promedio aproximadas a 1Mbps y se complementa con HSUPA (High Speed Up
Packet Access).
Entre las características más significativas de HSDPA podemos nombrar el aprovechamiento y
mejoramiento exponencial en la prestación de servicios de banda ancha con un aumento
significativo en la capacidad de datos móviles, con mayor throughput. HSDPA además
incrementa la eficiencia espectral y el aumento de velocidad frente a WCDMA, ya que permite
que la red sea usada a la vez por un número mayor de usuarios al ofrecer hasta cuatro veces
más capacidad que su predecesora. También HSDPA reduce la latencia de la red (<100ms)
disminuyendo por ello los tiempos de respuesta y mejorando notoriamente la interfaz de las
aplicaciones en tiempo real. Otros aspectos contribuyentes en el aumento de las tasas de
velocidad son:
Modulación utilizada: 16 – QAM
Codificación de variables de errores
Redundancia incremental.
16 El espectro de dispersión (spread spectrum) se define como como una técnica de transmisión utilizada para lograr extender el ancho de banda de los datos en banda base antes de la transmisión. La señal se transmite con un nivel bajo de ruido para recuperar en recepción mediante un filtro paso banda, con la misma técnica, la señal original. La velocidad de los códigos usados en esta técnica es mucho mayor que la velocidad de los datos en banda base.
29
Por último, añadir que HSDPA es compatible con la versión 99 de UMTS (R99), con el añadido
de una entidad de repetition/scheduling dentro del nodoB que se encuentra debajo de la capa
de control de acceso al medio R99 (MAC). (2) (3) (4)
Figura 4. Red HSDPA/WCDMA
Sistema LTE: Evolución y características
El sistema LTE puede ser visto como la parte que completa la tendencia de expansión del
servicio. Esto ya fue clave para el objetivo de UMTS y GPRS/EDGE, pero LTE fue diseñado desde
el principio con el objetivo de la evolución de la tecnología de acceso radio suponiendo que
sean todos los servicios de conmutación de paquetes en lugar de seguir el modelo de los
anteriores sistemas de conmutación de circuitos. No hay que olvidar que LTE va acompañado
por un desarrollo hecho por 3GPP de los aspectos no radio del sistema bajo el término
“Evolución de la Arquitectura del Sistema” (SAE en inglés) que define una nueva red de núcleo
de paquetes completamente IP conocida como núcleo de paquetes de red evolucionado
(Evolved Packet Core, EPC). Colectivamente, SAE y LTE forman el Sistema de Paquetes
Evolucionado (Evolved Packet System, EPS), donde ambos – el núcleo de red y el acceso radio –
son íntegramente conmutación de paquetes. Cabe añadir que EPS, aunque es una arquitectura
basada en paquetes, deberá soportar sistemas que admitan tráfico conversacional y en tiempo
real.
30
La primera versión de LTE estuvo disponible ya en la Release 8 de 3GPP. Aquí se aprovechan las
ventajas y desarrollos de HSPA y HSPA+, dando posibilidades de agregar nuevas tecnologías sin
limitaciones de compatibilidad con las versiones anteriores o un ancho de banda de portadora
de 5Mhz. Pero LTE tiene que satisfacer nuevas demandas, como por ejemplo en relación a la
flexibilidad del espectro para el desarrollo; puede operar en FDD y TDD para apoyar la
evolución TD-SCDMA17, interfaz de aire que se encuentra en las redes de comunicación UMTS
de China.
Además de incorporar características de HSPA+, en LTE hay un aprovechamiento máximo de la
tecnología radio, por ello la interfaz radioeléctrica se basa en OFMA para DL y SC-FDMA para
UL. La modulación elegida por 3GPP logra que las diferentes tecnologías de antena (MIMO)
tengan una mayor facilidad de implementación. Ambas tecnologías hacen un uso masivo del
procesado digital de señales (DSP).
La segunda versión de LTE fue desarrollada en la Release 9, y la Release 10 continuó la
progresión hacía el comienzo del siguiente avance importante en la tecnología móvil, LTE-
Advanced.
El proceso de estandarización de LTE fue inaugurado en 2004 cuando un gran grupo de
compañías involucradas en el negocio de las comunicaciones móviles presentaron sus ideas
para la futura evolución de las especificaciones a ser desarrolladas en 3GPP.
Estas ideas incluyeron las percepciones iniciales de los requerimientos que necesitan ser
satisfechos y propuestas de tecnologías adecuadas a cumplirlos.
Requerimientos de LTE
Los requerimientos de LTE Release 8 fueron detallados y refinados, siendo finalizados en junio
de 2005; podemos resumirlos en los siguientes puntos:
Disminución de retrasos. En cuanto al establecimiento de la conexión y el período de
inactividad en la transmisión.
Incremento en la velocidad de datos de los usuarios.
Incremento de la velocidad de bit en el borde de celda, para la uniformidad de la
prestación de servicios.
Reducción del coste por bit, implementando una mejora de la eficiencia espectral.
Una mayor flexibilidad del espectro utilizado, tanto en una nueva banda como en otra
ya existente.
Arquitectura de la red simplificada.
Movilidad continua, incluyendo entre diferentes tecnologías de acceso radio.
Consumo de potencia razonable para el terminal móvil.
17 TD-SCDMA, Time Division –Synchronous Code Division Multiple Access (Acceso múltiple por división de código síncrono de división de tiempo).
31
Para abordar estos objetivos, el diseño del sistema LTE cubre tanto el interfaz radio como la
arquitectura de red radio.
Características LTE
Hay tres características claves en las que LTE basa su funcionamiento: permite altas tasas de
bits con baja latencia, es económico y fácil de desplegar por los operadores y evita la
fragmentación por el tipo de duplexación.
Tasas de bajada y subida pueden alcanzar velocidades de pico de 173 Mbps en DL y 86 Mbps para UL, con 2 antenas en la estación base y 2 en el terminal (y hasta 300 Mbps de bajada con 4x4 antenas).
La facilidad de despliegue de esta red es debido a que los servicios de LTE sólo utilizan
conmutación de paquetes. El sistema switching de paquetes de LTE está muy
optimizado a diferencia de las infraestructuras de redes como GSM y demás, algo
necesario para un mundo en el cada vez hacemos más cosas sobre IP. Por esta razón,
la gestión de GSM y llamadas tradicionales no es posible a través de LTE, únicamente
de sus antecesoras.
LTE se adapta a que la utilización de teléfonos de otras partes del mundo, como puede
ser de China, sea posible gracias a la contemplación en las últimas revisiones del
estándar de la compatibilidad entre FDD que utiliza varias zonas del espectro y TDD
que ocupa una sola zona. Así por tanto, evitamos la fragmentación de los terminales
por el tipo de duplexación.
Otras características a tener en cuenta:
Velocidades: 100 Mbps en DL y 50 Mbps en UL
Flexibilidad del espectro para los operadores: 1.25 MHz, 2.5 MHz, 5 MHz, 10 MHz, 15
MHz y 20 MHz.
Reducción del tiempo que tardan los paquetes en viajar por la red a 10 ms
Amplio radio de cobertura, entre 5km y 100 km
Compatibilidad con redes WLAN y WIMAX.
Garantía de QoS extremo a extremo.
Infraestructura de LTE
Como se ha venido anunciando en este apartado, LTE elimina el dominio de circuitos y
permite mediante una arquitectura basada en IP unificar servicios como voz y datos. La red LTE
32
que trabaja sobre IP se expande desde el eNodeB hasta el núcleo de paquetes, permitiendo un
entorno total IP.
eNodeB es el único elemento que forman la red de acceso radio evolucionada, y funciona
como interface con el terminal de usuario. Algunas de sus funciones son:
Administración de los recursos radio.
Encriptación de la información del usuario.
Compresión de los paquetes que contienen datos.
El SAE18 Gateway está constituido por dos entidades lógicas: Serving Gateway y PDN Gateway.
Ambas cumplen la función de interface entre la red de acceso y las diferentes redes de
paquetes. El Serving Gateway interviene de manera activa en el proceso de movilidad cuando
se produce un traspaso entre eNBs; PDN Gateway es el punto de entrada/salida del tráfico
desde el usuario hasta las redes externas.
MME19 es la entidad de control que lleva a cabo las funciones de señalización, por lo que no
circula a través de este tráfico de datos de los usuarios. Esto es una ventaja que tienen los
operadores, que ayuda a aumentar la capacidad de señalización de forma independiente al
tráfico del usuario.
El plano de control MME es el nodo principal de acceso a la red LTE, gestionando las interfaces
de la red de acceso y el núcleo de la red. Este plano realiza las siguientes funciones:
Control de acceso a la red. Lleva la gestión de la autentificación y autorización para los
equipos de los usuarios. También los ayuda a lograr conectividad IP.
Administración de radio. Gestiona los recursos radio.
Administración de movilidad. Se encarga de proporcionar la interconexión para los
casos de uso que se dan, como el inter-eNB.
Administración del Roaming. Soporta la entrada/salida de los suscriptores móviles de
otros LTE y redes tradicionales.
Administración del seguimiento de zona. Asignación/Reasignación de la identificación
de área de zona.
Arquitectura LTE
En cuanto a la arquitectura de red de la tecnología LTE, se mantiene con respecto a los
anteriores sistemas especificados en 3GPP englobando la definición del UE y de una
infraestructura de red dividida en forma lógica en una estructura de red troncal (CN), y una red
de acceso (AN). Para el LTE, la red de acceso definida es la E-UTRAN y utiliza la tecnología
OFDMA en la interfaz radio para la comunicación con los equipos de usuario.
18 Service Architecture Evolution 19 Mobility Management Entity
33
E-UTRAN (red de acceso) y EPC (red troncal) proporcionan conjuntamente servicios de
transferencia de paquetes IP entre usuarios y redes de paquetes externas tales como
plataformas IMS y/u otras redes de telecomunicaciones como Internet. Las opciones de
calidad de servicio de un servicio de transferencia de paquetes IP puede configurarse según las
necesidades de los servicios finales que lo usen, cuya señalización se lleva a cabo a través de
plataformas de servicios externas y de forma transparente a la EPC. El servicio de
transferencia de paquetes IP ofrecido por LTE entre el equipo de usuario y una red externa se
denomina servicio portador EPS (EPS Bearer Service). Por otro lado, la parte del servicio de
transferencia de paquetes que proporciona E-UTRAN se define E-UTRAN Radio Access Bearer
(ERAB).
Figura 5. Representación arquitectura LTE
Algo a señalar de gran importancia es que la interconexión entre los diferentes equipos físicos donde se situarían las funciones tanto de EPC como de E-UTRAN se realiza mediante tecnologías de red basadas en IP. De esta forma, la red utilizada para la interconexión de las elementos de la red LTE (red de transporte), es una red IP convencional y donde la infraestructura, además de los equipos propios que implementan las funciones de 3GPP también integra otros elementos propios de las redes IP tales como routers, servidores DHCP y servidores DNS. (2)
34
35
3. PROCEDIMIENTO
OSS. Definición y objetivos.
El sistema OSS (Operational Support System) define al administrador de la red empleado por
los diferentes operadores de telecomunicaciones; normalmente la gestión de este elemento es
llevaba a cabo por la empresa que lo desarrolló. En este proyecto fin de carrera los datos
utilizados acerca de este gestor son de la empresa Ericsson, por lo que se basa en la estructura
definida por ella.
OSS hace referencia a los distintos sistemas de red vinculados a la red de telecomunicaciones
como son los procesos de soporte para el inventario de red, servicios de aprovisionamiento,
configuración de los elementos de red y software para la gestión de fallos, entre otros. La
estructuración entendida como varios subsistemas dentro de uno (OSS) nacen por las
demandas de los operadores a la hora de gestionar sus redes móviles; la red cambia
constantemente y todos los grupos que puedan gestionarla realizan modificaciones de
parámetros, actualizaciones de SW, HW, etc. que si no están coordinados afectarán a la
optimización de la red y por tanto se puede ver perjudicado el QoS adquirido con el operador.
En cuanto a lo ofrecido a los distintos operadores en función de las necesidades que tengan
cada uno de ellos, de manera general el OSS está diseñado para agilizar y simplificar la
creación de oferta y automatizar los procesos de cumplimiento, desde la planificación de
aprovisionamiento a la activación.
El término complementario que va de la mano de OSS es más reciente y se denomina Business
Support System (BSS). Este complemento hace referencia a los sistemas de negocio como por
ejemplo procesos de soporte para la toma de órdenes, facturación, cobro, etc. Ambos sistemas
son denominados de manera conjunta OSS/BSS, BSS/OSS o simplemente B/OSS.
En este proyecto nos vamos a centrar únicamente en el sistema OSS que ya de por si es
altamente complejo al estar compuesto de varios servidores con diferentes funciones de
gestión/administración de la red de telecomunicaciones.
En la siguiente imagen se puede observar la integración del sistema OSS en las diferentes redes
de telecomunicaciones así como las diferentes capas de gestión en que se divide la red móvil:
36
Figura 7. Capa gestión de la red
NMS (Network Management Systems). Nivel donde los diferentes sistemas de gestión
se integran, independientemente de si el operador tiene más sistemas
administradores de otro vendor (Huawei, por ej.)
OSS (Operational/Operations Support Systems). Ya presentado en este apartado como
sistema de administración, supervisión y configuración de la red móvil.
NE (Network Element). Son los elementos de red gestionados por el sistema OSS.
Una vez presentadas las capas de gestión, hay que hacer mención a las partes principales de
las que se compone el sistema OSS si bien, pese a que no se realizará un estudio profundo de
todos ellos sí que habrá que hacer hincapié en la que atañe al planteamiento realizado en la
red móvil, el mencionado refarming para un cluster de nodos.
1. FM Fault Management. Su función es la de gestionar las alarmas que provienen de los
elementos de la red móvil. Entre sus tareas se encuentran las de recepción y
almacenamiento de las alarmas y el sincronismo de estas con los elementos que las
han generado.
Aunque no es objeto de este trabajo desarrollar las partes de forma detallada del FM,
sí que se debe saber que todas las alarmas que se generan en cualquier elemento de
red son monitorizadas y tratadas bajo una serie de aplicaciones que, como ocurrirá con
las tools utilizadas para la configuración/optimización, se encuentran alojadas en un
servidor UNIX por el que se accede al interfaz gráfico de todas las herramientas; este
servidor de acceso se denomina UAS (Unix Application Server). Las aplicaciones que
veremos en el UAS y que son necesarias para la gestión de alarmas son:
Alarm Status Matrix [UMTS/LTE]. La matriz de estados de alarma visualiza las
alarmas presentes en el elemento o elementos de red que se quieran
consultar. Las alarmas aparecen mediante un código de colores tipificadas por
si son simplemente warnings o críticas para el elemento de red consultado.
37
Alarm List Viewer [UMTS/LTE]. Se puede acceder a través de la matriz de
estado haciendo doble click sobre la alarma deseada (también mediante el
menú del interfaz gráfico del UAS) y en esta aplicación lo que se visualiza es de
manera detallada toda la información relacionada con ella: severidad, tiempo
del evento, elemento sobre el que se produce, especificación del problema y
posible causa que produjese este problema.
Hay que señalar que además es posible visualizar la alarma en el propio elemento de
red a través de Moshell/amos, mediante el histórico de alarmas del nodo o cualquier
otro elemento solicitado por comandos.
2. PM Performance Management. Esta parte del OSS se encarga de la gestión de las
estadísticas necesarias para la optimización y mantenimiento de una red según los
servicios QoS establecidos con los operadores móviles. Con estas estadísticas podrán
hacerse seguimientos de los principales KPIs que marcan el estado actual de un NE o
varios de ellos, así como ayudarán a hacer recomendaciones al cliente para mejorar
tráfico o reducir el número de caídas de llamadas, por ejemplo. Para la administración
de estas estadísticas de la red hay un servidor dedicado, llamado ENIQ (Ericsson
Network IQ).
En cuanto a las aplicaciones para consultar contadores, modificar perfiles estadísticos,
extraer informes con los parámetros a analizar, etc. a continuación las utilizadas para
las tecnologías UMTS/LTE:
Profiles in OSS, PMS. Con esta tool definimos perfiles estadísticos para que,
posteriormente esta información se vuelque en el servidor ENIQ y pueda así
ser consultada/extraída por el optimizador o ingeniero de red. Muy
importante saber que si el contador o parámetro no está activado e incluido
en este perfil, no volcará datos ni en el NE ni en las diferentes tools de
consulta de estadísticas.
Fichero xml en OSS. Además de estar formado por un UAS destinado para el
acceso al interfaz gráfico el sistema OSS tiene otro servidor importante,
Master Server (MS), encargado de llevar a cabo la ejecución de todas las
aplicaciones, procesos, componentes de la red móvil. El fichero del que
podemos obtener estadísticas únicamente puede ser programado en el MS,
pues es donde está la configuración original de todos los elementos de red; la
información de estadísticos que se quiere reflejar en este xml es de toda la
red. Estos xml se vuelcan en el OSS cada 15 min (ROP) y pueden ser
consultados y exportados a local para trabajar con ellos.
3. CM Configuration Management. Esta parte del sistema OSS engloba las herramientas
destinadas a la configuración de toda una red móvil. Gracias a estas aplicaciones, la
optimización y estrategias que desde el operador se quiere llevar a cabo en la red son
38
mucho más fáciles de implementar, dando infinidad de posibilidades como programar
tareas, volcado de datos de una RNC/BSC/Nodo, crear copias de configuraciones
previo a un upgrade o prueba de features, etc.
Dependiendo de la tecnología, habrá unas aplicaciones destinadas a todas o a una en
concreto. A continuación una breve presentación de todas ellas, donde aparecen las
que ayudarán a la implementación de los casos presentados en este PFC:
Aplicación Tecnología
Radio Network Optimizer (RNO) UMTS/GSM
Software Management Organizer (SMO) UMTS/GSM/LTE
OSS Common Explorer (CEX) UMTS/LTE
BSIM UMTS/LTE
Element Manager (EMAS) UMTS/LTE
ARNE GSM/LTE
Command Handling (CHA) GSM
Cellular Network Administration (CNA) GSM
Winfiol GSM
EAW GSM
Element Management Activity Manager (EMAM) GSM
Advanced Managed Object Scripting (AMOS)/Moshell UMTS/LTE
Tabla 2. Aplicaciones disponibles en el OSS
Radio Network Optimizer (RNO): Aunque esta herramienta realmente es para
sacar datos de parámetros sobre un elemento o un conjunto de ellos, es de
gran ayuda para la optimización de la red. A rasgos generales, en ella puedes
programar perfiles MRR/NCS (tipo de grabaciones según tecnología) con los
parámetros que desees analizar y el tiempo que necesitas para ver su
comportamiento; después, los descargas o bien puedes visualizarlo desde la
misma aplicación. Con esto consigues por ejemplo, observar el
comportamiento en un nodo después de cambiar la inclinación (tilt) o
modificar potencia de sus sectores y comprobar si se está produciendo
overshooting o no.
Software Management Organizer (SMO): Con SMO se pueden consultar las
licencias instaladas en un elemento de red, su configuración y la última copia
disponible de la misma (CV), información del elemento (tipo de HW, SW
instalado, etc.) así como visualizar las estadísticas volcadas en el OSS. Además
de consultar toda esta información, se puede generar CVs o actualizar el SW de
los nodos.
BSIM: Tool encargada de la gestión de los logs del sistema; las plantillas
utilizadas en cada proyecto deben ser adaptadas con las necesidades
específicas de la versión OSS utilizada.
39
Element Manager (EMAS): Gestor de vecindades en la red móvil. Se puede
abrir desde otras aplicaciones – bien desde CEX o desde el explorador OSS -
pues no deja de ser un extra para cambios en red de manera gráfica. Cualquier
cambio que se haga en la vecindad desde EMAS se ve reflejado
automáticamente en red (se puede comprobar entrando en la RNC desde
AMOS).
ARNE: No deja de ser la opción de ver la configuración de los elementos de red
dentro del OSS Explorer.
Element Management Activity Manager (EMAM): Es una de las tools de
gestión del OSS que se utiliza para programar tareas a realizar en elementos de
la red GSM (MSC, BSC, etc.). Se indica en la pantalla de programación el día, la
hora y si deseas que sea periódico así como el nombre del log de la tarea para
ver los resultados y su ubicación.
EAW: Ejecutable que, lanzado en AMOS indicándole el elemento a consultar,
hará un printado de una serie de características del elemento: identificador,
tiempo del sistema.
Cellular Network Administration (CNA): Herramienta destinada a llevar a cabo
todos los cambios en la red GSM para mejorar los parámetros QoS; utilizada
además, para realización de reparentings de una MSC a otra y programar
cambios masivos en los elementos necesarios. Esta tool se utiliza
exclusivamente para GSM, es como CEX para UMTS y LTE; como se indicará
más adelante, las modificaciones a realizar primero se cargan en una planned
y, después de comprobar mediante un consistency check (CC) el impacto de
estos cambios en los elementos afectados, se ejecuta un adjust para que
quede alineado lo que se encuentra en CNA y la red.
WinFiol: Es, como Command Handling (CHA) una herramienta destinada a
realizar cambios directos en uno o varios elementos de la red GSM. El objetivo
de estas herramientas es el mismo que el de CNA con la única diferencia en
que los cambios en WinFiol/CHA se hacen directamente en red, sin tener que
hacer un ajuste para cargarlos; tampoco se realiza un CC para conocer las
posibles discrepancias a la hora de implementarlos. Son más simples; son el
AMOS de LTE y UMTS. Ambas herramientas pueden lanzar los comandos que
se quieran a varios elementos de red de manera simultánea.
Pero todavía quedan un par de aplicaciones a explicar en detalle y que serán las protagonistas
de este trabajo: OSS Common Explorer y AMOS (antiguo Moshell). En los siguientes apartados
se realizará un estudio más detallado de cada una de ellas. (5)
40
Introducción AMOS/ Moshell, OSS Common Explorer y Command Handling
Se presentaron resumidamente una serie de herramientas del sistema OSS para alarmas,
estadísticas y configuración de la red, pero hay dos que no se han tenido en cuenta todavía y
para las que se ha destinado una parte de este proyecto a explicar de manera detallada. Como
el objetivo es aprender en qué consiste el refarming en una red móvil y se ha centrado en
hablar de las tecnologías UMTS y LTE, las herramientas implicadas en el desarrollo e
implementación de este trabajo serán OSS Common Explorer (CEX) y AMOS/Moshell.
AMOS/Moshell es un potente software del sistema OSS para ejecutar en línea de comandos
órdenes de consulta y/o de cambio en elementos de red. Hay que ser cauteloso a la hora de
utilizar esta herramienta, pues cualquier cambio que se lleve a cabo afectará directamente a la
red.
OSS Common Explorer (CEX) es una aplicación de administración de Sub-Red para operación y
mantenimiento. CEX es una plataforma Eclipse Rich Client (RCP) que permite al operador
realizar la configuración de tareas de administración en todos los tipos de dominio
compatibles.
Command Handling (CHA) es una herramienta que proporciona OSS para la gestión de la red
móvil. A través de CHA, se pueden realizar cambios y consultas en elementos GSM.
Aprendizaje herramienta Moshell/AMOS
A la hora de llevar a cabo cambios en la red a través de la línea de comandos puede ser
utilizado tanto Moshell como AMOS. Ambos SWs están diseñados para los mismos objetivos,
con la única diferencia en el grupo destinado a la utilización de estas; AMOS se ha desarrollado
como la versión para el cliente de Moshell y está presente a partir de la versión de OSS-RC 5.3.
Los comandos utilizados en ambos software son idénticos, con la única diferencia de los
indicados a servicio interno del proveedor (Ericsson en este caso): comandos Lab (pset, pcr,
pdeb, etc.) y comandos internos de Ericsson (fset, fget, facc, etc.)
Servicios prestados por AMOS/Moshell:
Servicio de alarma (Alarm Service, AS)
Servicio de configuración (Configuration Service, CS)
Transferencia de fichero (File Transfer, FTP/HTTP)
Servicio de inventario (Inventory Service, IS)
Servicio de log (Log Service, LS)
Notificación
OSE Shell (COLI)
Servicio de medición del rendimiento (Performance Measurement Service, PM)
41
Cómo acceder a AMOS/Moshell
Hay dos formas de acceso a AMOS/Moshell: de manera segura o por el contrario, acceso no
seguro. En la siguiente imagen podemos chequear los protocolos de acceso a través de una
conexión Ethernet o bien IP sobre ATM.
Figura 8. Formas de acceso para AMOS/Moshell
Una vez establecida la conexión al software se debe conocer también la manera de ejecutar
AMOS/Moshell y por tanto, de acceder al elemento de red deseado. Para ello, los pasos a
seguir:
1. Seleccionar en el espacio de trabajo empleado – normalmente utilizado Citrix, bien
instalado en el servidor del proveedor o a través de una plataforma Web, MSDP -
el icono AMOS. Esta acción abre la ventana principal de comandos, eligiendo la IP
a la que se quiere acceder.
2. Indicar comando + elemento que se quiere consultar. Esta acción lanza AMOS
contra el elemento de red especificado. Ahora estaremos dentro del nodo/rnc
para cualquier consulta/operación.
a) amos/moshell [espacio] <node_name>
b) amos/moshell [espacio] <node_IP_address>
Para salir de AMOS, simplemente con ejecutar uno de los siguientes comandos hará que te
sitúes fuera del elemento: exit, q, quit o bye.
AMOS/Moshell: Managed Object Model (MOM)
42
Antes de utilizar el software AMOS/Moshell en cualquiera de sus versiones es importante
conocer la operativa y cuál es la jerarquía por la que se rigen los comandos para cambios o
consultas. Para ello hay que presentar el objeto de modelo de gestión, Managed Object Model
(MOM)
MOM es un documento que describe para cada versión de SW del nodo en particular:
Todos los diferentes tipos de MOs (clases MO)
Atributos contenidos en cada clase MO
Relaciones (padres/hijos) entre las clases MO
Acciones soportadas por cada clase MO
Normalmente este documento está incluido en la librería del proveedor (llamada CPI ó ALEX).
Los MOs están organizados en una estructura jerárquica. Cada instancia MO está identifica de
manera exclusiva en el nodo por su Local Distinguished Name (LDN). Un ejemplo para
entenderlo mejor:
ManagedElement=1
ManagedElement=1, Equipment=1
ManagedElement=1, Equipment=1, Subrack=MS
ManagedElement=1, Equipment=1, Subrack=MS, Slot=19
ManagedElement=1, Equipment=1, Subrack=MS, Slot=19, PlugInUnit=1
ManagedElement=1, Equipment=1, Subrack=MS, Slot=19, PlugInUnit=1, Program=DbmFpgaLoader
La cadena situada en el extremo derecho de un LDN, justo después de la última coma, se llama
nombre distinguido relativo (Relative Distinguished Name, RDN). Es una forma relativa de
hacer frente a una instancia de MO.
ManagedElement=1, Equipment=1, Subrack=MS, Slot=19, PlugInUnit=1, Program=DbmFpgaLoader
ManagedElement=1, Equipment=1, Subrack=MS, Slot=23, PlugInUnit=1, Program=DbmFpgaLoader
El nombre distinguido completo (Full Distinguished Name, FDN) agrega un prefijo de elemento
de red delante del LDN de cada instancia de MO para especificar a qué nodo pertenece este
MO.
SubNetwork=AUS, SubNetwork=H2RG_0201, MeContext= St Leonards Station 2065010, ManagedElement=1, TransportNetwork=1, AtmPort=MS-24-1
A continuación, un esquema de la capa del servicio situando los conceptos presentados
anteriormente en la base de información de la gestión en AMOS:
43
Figura 9. Jerarquía de la clase MO
En la siguiente imagen podemos ver el esquema que sigue la clase MO; se distingue que el ID
es el RDN correspondiente mencionado anteriormente, las acciones del MO y los posibles
atributos que pueden acompañarle, para el mapeo de la operación deseada.
44
Figura 10. Estructura de la clase Managed Object (MO)
Los atributos de los MOs tienen estados que harán posible involucrarlos en la operativa que
quiere llevarse a cabo o por el contrario no poder implicarlos. Veamos a continuación una
tabla con los status que podemos encontrarnos:
Estado Posibles valores
Operación Enable
Disable
Administrativo
Locked
Unlocked
Shutting_down
Disponibilidad
No_Status
In_Test
Failed
Power_Off
Off_Line Tabla 3. Posibles estados atributos de MOs
También hay que tener en cuenta que no sólo del estado de los atributos depende que sean
estos utilizados o no. Algunos MOs han definido acciones que son usadas para ejecutar
operaciones particulares relacionadas con el MO que bien pueden involucrar uno o más
atributos de este o por el contrario no incluir ninguno de ellos por no ser necesario.
45
En relación a este objeto, se cuenta con servicios para gestión de la configuración y de los
fallos de los MOs, presentados de manera ordenada en las siguientes tablas:
Servicio de gestión de la configuración
Operación Propósito
comando/s relacionados en Moshell Protocolo
GetChildren Listado de LDNs de los MOs que hay actualmente en el MIB lt, lc
corba (CM)
GetAttribute Leer el valor de uno o más atributos get, hget, pget, st, prod, inv,etc.
CallAction Llamar a una acción en un MO acc(acl)
SetAttribute Cambiar el valor de un atributo (siempre que no sea restringido o sólo lectura) set, bl, deb
CreateMO Crear un MO Cr
DeleteMO Borrar un MO del, rdel Tabla 4. Comandos para operaciones de gestión de la configuración
Servicio de gestión de los fallos
Operación Objetivo comando/s relacionados en Moshell
Protocolo
GetAlarms Listado de las alarmas activas Al corba
(FM) Acknowledge /unacknowledge
Conoces/desconocer una alarma no soportado en Moshell
Tabla 5. Comandos para operaciones de gestión de los fallos
Ipdatabase
Si no hay un listado de elementos a los que podemos lanzar AMOS/Moshell para poder
acceder a ellos, evidentemente será complicado realizar cualquier tipo de operativa en ellos;
por eso es indiscutible la existencia del fichero ipdatabase donde se pueden almacenar para
cada elemento de la red:
Nombre del nodo (arbitraria)
Dirección IP o nombre DNS
Password (opcional)
Este fichero debe almacenarse en el sistema OSS de la siguiente manera:
/home/nombreusuario/moshell/sitefiles/ipdatabase
46
El cliente O&M20 puede acceder a las MOs a través de una serie de servicios citados a
continuación:
Servicio de configuración (Configuration Service, CS): Leer y cambiar los datos de
configuración; estos están almacenados en los atributos de los MOs.
Servicio de Alarma (Alarm Service, AS): Recuperar la lista de alarmas activas en cada
MO.
Servicio de notificación (Notification Service, NS): Suscribir y recibir notificaciones
desde el nodo, informando sobre parámetros/alarmas cambiados en los MOs.
Servicio de inventario (Inventory Service, IS): Obtener una lista de todos los HW y SW
definidos en el nodo.
Servicio de registro (Log Service, LS): guardar un registro de ciertos eventos como
cambios en la configuración, alarmas generadas y apagadas, nodo y reinicios hechos
en él y eventos JVM.
Medición del rendimiento (Performance Measurement, PM): Instalación de escáneres
de estadísticas o filtros de eventos; los contadores de estadísticas están guardados en
pm-attributes del MO y salen a un fichero XML cada 15 minutos (ROP).
Comandos Moshell/AMOS
Ya se ha explicado anteriormente que para llevar a cabo un refarming es necesario realizar
acciones sobre el clúster de nodos ejecutando según el escenario scripts XML a cargar a través
del interfaz gráfico o una serie de comandos lanzados directamente en el nodo/RNC. Se va por
tanto a hacer una descripción de los comandos al lanzar la ayuda dentro del elemento donde
se lanzó Moshell/AMOS:
Categoría Comando Descripción
basic MO commands
mom[tc] Muestra la descripción de las clases de MO, atributos FM/CM, acciones, enumeraciones y estructuras
lt/ltc[1-9] Carga el árbol de MO (completo o parcial) y construye una tabla de proxy
lc[1-9]/lcc Carga el árbol de MO (completo o parcial) y construye una tabla de proxy
other MO commands
cvls/cvmk/cvms/cvset
comandos relacionados con el backup de la configuración (configuration version, CV)
inv[hr] Inventario completo del SW/HW. Incluye información sobre RPUs, concesión de licencias, JVM, dispositivos, etc.
cab[slxradgtm] Muestras de varias impresiones COLI relativas al hw, sw, reinicios, led, carga de la cpu, errores, disco
Other commands
Uv Muestra o cambia la configuración Moshell (también llamado "variables de usuario")
Pv Muestra variables de secuencias de comandos
!/l Ejecuta un comando UNIX en el PC/Workstation
20 Operations & Maintenance, operación y mantenimiento
47
PM commands
pmom[ac]/lmom[c]
Muestra la descripción de los contadores PM (pmom) o los atributos de log
pget/lpget Lee atributo/s PM del MO
hpget[c]/lhpget[c]
Lee atributo/s PM del MO. Muestra horizontalmente una línea por MO
Help chapters
0 Instalación, seguridad y configuración de usuarios
1 Historial de revisiones
2 Tutorial
3 Sintaxis del comando, expresiones regulares Tabla 6. Comandos más importantes en Moshell/AMOS
Descripciones de comando
A la hora de lanzar una orden en Moshell/AMOS, es conveniente conocer las opciones que se
ofrecen en cuanto a facilitar la ejecución de la acción que se desea llevar a cabo. Para ello, se
utiliza el comando “h” seguido del que queremos conocer las opciones:
RNCXYZ> h get
Esta orden va a mostrar las opciones disponibles para leer atributo/s PM de MOs:
***************************************************************************
Pget/lpget [<moGroup>|<moFilter>|<Proxy(s)>|all] [<attribute-filter>|all] [<value-filter>]
***************************************************************************
MOM navegando desde AMOS
Actualmente hay dos variaciones del comando mom:
mom muestra todos los atributos excepto para los atributos PM
pmom es usado para visualizar los atributos PM
Este comando es verdaderamente útil pues te da toda la información de los MOs que cuelgan
del que se consulta y una explicación de cada uno de ellos. Con “h” sabemos que se pueden
ver las distintas opciones de este comando:
mom[tc] [<moclass/struct/enum>|all] [<attribute/action>|all] [<attr-type>|all][<attr-
flags>|all][<attr-desc>]
Para ver la estructura de árbol del MO, se ejecuta el comando: momt
48
Comando pr/prl
*****************************************************************************
pr/lpr [<moGroup>|<moFilter>|<proxy(s)>]
*****************************************************************************
Muestra los LDNs del MO y los ids del proxy para todos o parte del árbol MO actualmente
cargado en Moshell. En la siguiente imagen se ve el resultado para el MO Carrier:
MO/s donde los LDN/RDN coincidan con el patrón estarán operativos. Si el comando empieza
por “l” a continuación coincidirá con el patrón de LDN. Si el comando no comienza por “l”
entonces el patrón coincidirá con el de RDN.
49
A continuación, un par de ejemplos de expresiones regulares utilizando el comando pr/lpr:
Comando st/lst
Muestra el estado de los MOs (operationalState y administrativeState cuando sea aplicable).
**********************************************************************
st/lst [<moGroup>|<moFilter>|<proxy(s)>|all] [<state-filter>]
**********************************************************************
50
En la siguiente orden ejecutada, podemos ver en qué estado se encuentra los parámetros de
los canales de transmisión en una celda; todos están desbloqueados y habilitados:
Comando str
Muestra el estado de los IubLinks/AbisLinks y sus celdas y canales asociados (solamente
RNC/BSC). Su estructura:
***********************************************************************
str[12ft] [<cvsfile>] [<filter-options>] [| <unix cmds>]
***********************************************************************
Veamos lo que ocurre al lanzar este comando sin opciones:
Si lanzamos str con los siguientes filtros, mostrará el estado de las celdas solamente en el
módulo 3:
51
Comando get/lget
Este comando devolverá el valor de uno o varios atributos para uno o varios MOs. La sintaxis
del comando:
***************************************************************************
get/lget [<moGroup>|<moFilter>|<proxy(s)>|all][<attribute-filer>|all] [<value-filter>]
***************************************************************************
Ejemplo visualizando el valor del parámetro primaryscramblingCode de la celda AMRB10A:
Si lo que se desea es obtener todos los valores de un parámetro para todos los elementos de la
RNC, una opción válida es sustituir el MO por un “.”. Quedaría de la siguiente forma:
RNCSM01> lget . primaryscramblingcode
52
De esta manera, obtendríamos los valores de los SCs para todas las celdas de la RNCSM01.
Esto es aplicable a otros comandos, pero siempre conociendo previamente lo que implica
realizar esta acción.
También hay que hablar de los atributos ocultos (no están descritos en el MOM) y de la forma
que podemos forzar su visibilidad. Se puede utilizar el comando fget que no es más que la
contracción de la expresión inglesa “force get” y por la cual podremos leer el atributo oculto:
Comando kget
El comando kget es idéntico al get excepto que la salida tiene un formato ligeramente
diferente con el fin de permitir la importación de datos en algunas herramientas externas
como MCOM21. kget debe usarse principalmente cuando tenemos volcado de MOs (lt all;
kget).
Comando set/lset
El comando set/lset modifica un atributo en uno o varios MOs. La sintaxis del comando es:
****************************************************************************
set/lset <moGroup>|<moFilter>|<proxy(s)> <attribute> <value>
****************************************************************************
Para cambiar el atributo en uno o varios MOs:
lset cell primarycpichpower 310
21 MCOM, herramienta propia del proveedor Ericsson utilizada para la monitorización de la red. Muestra los nodos geográficamente y es posible ver en qué zonas está peor el performance.
53
Para cambiar atributos de tipo Struct, usar:
set sid sib11 sib11repperiod=128,sib11startpos=20
Ejemplo de cambio de estado administrativo en el MO 159:
En la imagen se ve una parte marcada en rojo; la peculiaridad de este comando es que solicita
la confirmación del cambio que se quiere hacer. Además, en caso de que el valor que se le
quiere dar al parámetro estuviera fuera del rango establecido, aparecería un mensaje de
advertencia justo antes de la confirmación solicitada por AMOS. En este caso, al decirle NO el
cambio que se había lanzado no se ha hecho sobre el MO por lo que se queda igual.
Comando rset
Este comando cambia un atributo que es restringido (se utiliza el comando mom para ver si un
atributo es restringido). Veamos un ejemplo para entender este tipo de operaciones:
Primero, lanzamos un mom para comprobar si el parámetro utrancellid es restricted:
Una vez se ha confirmado que si es restringido, podemos utilizar rset para modificar su valor
en la celda deseada:
54
En caso de no haber comprobado antes si es un atributo restringido, si se lanza set/lset no se
permitirá el cambio:
Comandos de bloqueos/desbloqueos
Para ciertas pruebas en los nodos en ocasiones es necesario bloquear alguna de sus celdas o
todas ellas en una o varias tecnologías; lo mismo ocurre si el performance es tan malo que
degrada los KPIs de la red. Por ello, es necesario conocer algunos comandos de bloqueo y
desbloqueo utilizados en Moshell/AMOS.
bl/lbl. Los comandos bl/lbl modifican el atibuto administrativeState de un MO a 0. Esto
es lo mismo que ejecutar set/lset <mo> administrativeState 0. La sintaxis del comando
es:
*****************************************************************
bl/lbl <moGroup>|<moFilter>|<proxy(s)>
*****************************************************************
55
A continuación, una serie de ejemplos “jugando” con las diferentes opciones:
Comando Explicación
bl aal2.*ca[246] Bloquear aal2paths ca2, ca4, ca6
lbl USMSNE08 Bloquear todos los Mos del emplazamiento USMSNE08 (celdas, canales de control y Iub Link)
bl 234 256 248 Bloquear proxys 234,256 y 248
bl 001500 Bloquear una tarjeta. Esto equivale a: lbl subrack=ms,slot=15,pluginunit=1$ Tabla 7. Opciones comando BL
bls/lbls. La opción “s” es para un soft-block; el atributo administrativestate es
cambiado a 2 (“shutting down”) que significa que el recurso tendrá alrededor de 30
segundos de período de gracia para el traspaso del tráfico a otros recursos, antes de
bloquearse. El administrativeState automáticamente irá a 0 después del período de
gracia de 30 segundos aprox. A continuación, un ejemplo:
Primero lanzamos bls para el handover del tráfico hacia otros recursos
Después del soft-block:
deb/ldeb. Comando para desbloquear MOs. Para desbloquear la celda BCAS01A:
56
Comandos creación/borrado MOs
cr/lcr. Este comando crea un MO, dado su LDN. El LDN no necesita contener
ManagedElement=1 en el inicio. La sintaxis del comando: cr <ldn>
A tener en cuenta sobre el uso de cr:
- Si hay algunos atributos obligatorios para añadir, les pedirá la función.
- Si hay algunos atributos restringidos para añadir, les pedirá la función. El tipo
d para utilizar el valor por defecto (que está a menudo en blanco). La razón por
la que d es necesario es que al no poner nada el comando se aborta.
- Al especificar un atributo de tipo Struct, se usa la siguiente sintaxis:
attr1=val1, attr2=val2, attr3=val3…
del/rdel. El comando del borra uno o varios MOs; rdel elimina el MO junto con hijos y
reservando MOs.
Un MO solamente puede ser borrado cuando su lista ReservedBy está vacía y cuando
no tiene ningún hijo. Si el MO tiene hijos y/o no está vacía su lista del atributo
57
ReservedBy, es posible utilizar en su lugar el comando rdel/lrdel. La sintaxis del
comando es:
del/ldel <moGroup>|<moFilter>|<proxy(s)>
A continuación, algunos ejemplos del uso del/rdel:
- Borrado de Iub Link.
- Borrado del iublink=1 con hijos (no acepta del, tenemos que eliminarlo con rdel).
Comando acl/lacl
Los comandos acl/lacl listan acciones que pueden realizarse en un MO. La sintaxis del
comando:
acl/lacl <moGroup>|<moFilter>|<proxy(s)>|all [<action-filter>]
Ejemplo:
58
Comando u+/u-
Es un comando para manejo de modo de deshacer (para deshacer comandos del/rdel/set).
Puede utilizarse para la generación de secuencias de comandos de MO así:
u+ Comenzar “modo de deshacer”
u+s Comenzar “modo de deshacer simulado”
u- Parar el “modo de deshacer” (o el modo de deshacer simulado)
u? Chequear si el “modo de deshacer” está activo o no
u! Convertir los ficheros de comandos moshell a formato trun/emas o deshacer
logfiles a ficheros de comandos
Mientras está ejecutándose el “modo de deshacer”, los datos de MO están guardados
en un especial logfile para todos los MOs donde los siguientes comandos están
corriendo:
-del/ldel
-rdel/lrdel
-bl/lbl
-deb/ldeb
-set
Ejemplos de uso:
59
Modo de deshacer simulado para la generación de script:
60
Alarmas
Para la visualización de las alarmas que hay en el nodo o en la RNC, está el comando “al”. Con
este comando se muestra un listado de alarmas y advertencias activas. La sintaxis del comando
es:
**********************************************************************
al[atkc] [-a | -u <alarm_id>] [| <unix cmds>]
**********************************************************************
La salida puede ser conducida a través de comandos externos unix tales como “sort”, “grep”,
“less”, “more”, etc.
Es posible combinar varias opciones, por ejemplo: al, ala, alatk, alatkc, etc.
- al: El listado de alarmas activas es mostrado en formato resumen, solo cuatro
campos visualizados por alarma.
- ala: Lo mismo que al, pero la lista detallada completa se agrega debajo de la tabla
resumen.
- alt: Lo mismo que al, pero el campo time es añadido a la tabla y las alarmas están
ordenadas cronológicamente.
- alk: Lo mismo que al, pero la lista está separada en dos partes, una para las
alarmas desconocidas y la otra para las alarmas conocidas.
- alc: Lo mismo que al, pero cada alarma es visualizada en formato CSV y todos los
campos son mostrados para cada una de ellas.
61
Comando run
El comando run se encarga de ejecutar un archivo de comandos en formato moshell. Esto se
aplica a comandos tales como “lt/ltc”, “lc/lcc”, “del”, “bl”, “set”, donde la confirmación entra
automáticamente cuando se está ejecutando un archivo de comandos.
Los comentarios pueden ser puestos en el archivo de comandos usando el símbolo #. El
archivo de comandos debería ser una orden por línea. Por ejemplo, a continuación órdenes
que pueden incluirse en un script .sh donde se realizan consulta de tilt en las RNCs a partir de
la información que se proporciona en un listado .txt:
Figura 11. Ejemplo de script de consulta (.sh)
Mobatch
Mobatch es usado para la ejecución de sesiones Moshell en varios nodos en paralelo. El listado
de nodos debe estar definido en un “sitefile”. Cada nodo puede ser listado por su nombre de
nodo; no hay límite de cuantos nodos pueden ser listados en el sitefile.
Mobatch ejecutará una sesión Moshell por cada nodo listado en el sitefile. Hasta 10 sesiones
serán ejecutadas en paralelo en cualquier momento. Este límite de sesiones puede ser
modificado con la opción –p.
A continuación, un ejemplo de la utilización de mobatch utilización el formato de ejecución
señalado: mobatch SiteFile.txt CommandFile.txt LogDirectory
62
Moshell/Amos: Performance Management (PM)
Valores instantáneos de los contadores de MOs de celdas y rbs pueden ser leídos a través de la
operación “GetAttribute”, servicio de CM (comando AMOS “pget”). No es posible leer
contadores instantáneos para MOs de RNC a través del servicio CM.
Los valores de contador para un ROP22 dado pueden ser leídos desde los ficheros XML por ROP,
siempre hay un escáner de estadísticas activo conteniendo estos eventos. Los eventos que han
ocurrido en un ROP dado pueden ser leídos desde los ficheros binarios de ROP, siempre que
haya un escáner de evento activo conteniendo estos eventos.
Figura 12. Formas de lectura de las estadísticas
22 Result Output Period, período de salida de resultado que equivale a 15 minutos.
63
Comandos PM
En la siguiente tabla una presentación de los principales comandos PM para Moshell. Algunos
no están disponibles en AMOS.
Operación Comandos moshell relacionados
Protocolo
Listar filtros de escáneres y eventos pst
corba (PM)
Crear escáner de estadísticas pcr
Parar escáner pbl
Borrar escáner pdel
Resumen de escáner pdeb
Cambiar filtro de evento pset
Ver contenidos del escáner pgets
Leer valor instantáneo del contador pget corba (CM)
Obtener y analizar ficheros de estadísticas por ROP (xml) pmr/pmx
ftp/sftp Obtener y analizar ficheros de eventos por ROP (binary) pme Tabla 8. Principales comandos PM para Moshell
Otros comandos importantes explicados a continuación:
pmom. Mostrar la descripción de los contadores PM (pmom) o el log de atributos
(lmom, solo CDMA). Sintaxis del comando:
***********************************************************************
pmom[acd]/lmom[c] [<moclass>] [<counter>] [<counter-description>] [<counter-type>]
***********************************************************************
Ejemplo:
64
emom. Muestra el listado de eventos disponibles para cada tipo de escáner basado en
eventos. Sintaxis del comando:
***********************************************************************
emom [uetr|gpeh|ctr|all] [<event-filter>]
***********************************************************************
Ejemplo:
Leer los valores del contador individual de pget
65
pget/pdiff puede ser usado para leer valores de contadores instantáneos. Utiliza el servicio de
CM de corba, como “get”. Funciona en la mayoría de MOs excepto en MOs de RNC (Utrancell).
Por tanto, la función es igual que el get/lget pero solamente visualizando los atributos pm. La
sintaxis del comando es:
***********************************************************************
pget/lpget [<moGroup>|<moFilter>|<proxy(s)>|all] [<attributes-filter>|all] [<value-filter>]
***********************************************************************
Ejemplo utilizando pget:
A este comando podemos añadirle una h (hpget), cuya diferencia radica en que ahora los
valores de los atributos se muestran horizontalmente, una línea por MO (en lugar de una línea
por contador).
Ejemplo leyendo incrementaciones del contador PM usando pdiff:
Comando pmx
Muestra los valores de los contadores, extraídos desde los ficheros XML (ficheros ROP). Este
comando está llamando las utilidades pmExtract/pmXtab/pmDiff. Una cosa a tener en cuenta:
66
sólo los contadores que estén definidos en un escáner activo serán guardados en un fichero de
ROP. La sintaxis del comando:
**********************************************************************
pmx[hfdn] [<mofilter>|<mogroup>] [<counter-file>] [-l <PMfiles-directory>] [-m
<minushours>] [-p <plushours>] [-s <startdate>[.<starttime>]] [-e <enddate>[.<endtime>]] [-
a|-d|-h] [| <unix-command>]
**********************************************************************
A continuación, un ejemplo de cómo conseguir el Speech Dropped Call Number durante las
últimas 2 horas:
Comando pmr
Produce reportes de KPI PM, basados en los valores de los contadores en los ficheros de
estadísticas ROP y fórmulas en la documentación CPI. Este comando es tremendamente útil en
el seguimiento de posibles degradaciones en las horas posteriores al trabajo planificado (por
ej., la activación de una funcionalidad o el upgrade de una RNC ó clúster de RBS). Ejemplo de
uso:
- Ejecutando únicamente pmr visualizamos todas las opciones de KPIs a mostrar.
67
- Seleccionamos la opción 4 (HSDPA Tput):
Para este caso, como no hemos seleccionado rango de horas nos muestra las estadísticas del
KPI HSDPA tput de la última hora del sistema. A continuación, añadiendo opciones de tiempo
al comando pmr para el KPI de rssi y potencia transmitida en las últimas 4 horas:
68
pst. Lista todos los escáneres PM y su estado. La sintaxis del comando:
**********************************************************************
pst [<scan-filter>| <scan-proxy>][<scan-state>]
**********************************************************************
Ejemplo:
Otra opción es listar únicamente los escáneres que están activos con pst .act:
69
A continuación, más comandos importantes de PM que no están disponibles en la versión
AMOS:
pcr. Comando para crear un escáner de estadísticas. Su sintaxis:
***********************************************************************
pcr[cfd/lpcr[cfd] <scannerName> <moclass-filter>|<moinstance-filter>|<mo-
group>|<counter-file> [<counter-filter>] [<granularity>]
***********************************************************************
Ejemplo de uso:
pbl. Suspender un escáner. Su sintaxis: pbl <scan-filter>|<scan-proxy>
Ejemplo:
70
pdeb. Reanuda un escáner. Sintaxis del comando: pdeb <scan-filter>|<scan-proxy>
Ejemplo de cómo se reanuda el escáner del proxy 703:
pdel. Borra un escáner. Su sintaxis: pdeb <scan-filter>|<scan-proxy>
Ejemplo de borrado del escáner RLSUCC:
71
pset. Este comando modifica los contenidos de escáner basado en eventos (solo
RNC/RBS/LTE). Su sintaxis: pset[d]
Ejemplo de modificación de contenidos de un escáner:
Configuración HW/SW
Hay comandos con los que podemos ver la versión de SW del elemento deseado y además el
HW que tiene instalado, además de backups de configuración para posibles restarts que se
hagan o carga de antiguos valores después de una degradación del nodo/RNC. A continuación,
los más importantes de Moshell/AMOS.
72
Comando de descripción de HW/SW: inv
Únicamente con ejecutar el comando inv podemos ver un detalle del HW/SW de la RNC:
Ejemplo para la RBS:
Si queremos filtrar y que no se muestren todas las características:
- Para visualizar solamente el SW de la RNC: inv rnc
- Para visualizar solamente HW/SW que está bloqueado o deshabilitado: inv . 0|L
Comando de descripción de HW/SW: bo
El comando bo se encarga de administrar grupos de tablas que se pueden utilizar para ejecutar
comandos COLI en múltiples de ellas. La sintaxis del comando:
***********************************************************************
bo[r]/ba[swdp]/br[wd]/be[0-50]/bp
***********************************************************************
Ejemplos:
73
Ejecutando bp (de cada grupo de tablas, nos indica el número de ellas que hay):
Comando de descripción de HW/SW: cab
Comando que muestra diversas salidas por pantalla COLI relacionadas con hw, sw, restarts,
leds, cpu load, errors, uso de disco/ram. Sintaxis:
***************************************************************************
cab[slxradgtme] [|<unix cmds>]
***************************************************************************
Las opciones disponibles con el comando cab:
- cab: Muestra información de MP/BP HW y el estado de led, temperatura MP y
estado coreMgr
74
- cabt: Lo mismo que cab pero sin la temperatura
- cabx: Lo mismo que cab más la información de HW y led para las tarjetas XP (por
ej.: TMA, MCPA, Fans, etc.)
- cabl: Lo mismo que cab más el procesador de carga MP/BP
- cabs: Lo mismo que cab más la lista de programas ejecutándose en MP/BP
- cabr: Muestra todos los reinicios MP/BP. Los restarts anormales los muestra en
rojo.
- caba: Muestra únicamente los restars anormales MP/BP.
- cabd: Muestra el uso del disco. Discos que están recibiendo más de cierto límite
aparecerá en color. El límite puede estar definido en el archivo cabview.
- cabg: Muestra los errores HW de MP/BP (por ej. Fallo de disco, fallo de RAM, etc.)
- cabm: Muestra el uso de la memoria RAM de MP/BP.
- cabe: Muestra las condiciones de traceo T&E añadidas de MP/BP.
Ejemplos:
Ejecutando cab
Utilizando una de las opciones mencionadas (cabl)
En cuanto al SW, el comando encargado de mostrar toda la información del elemento
consultado es lhsh; a continuación, un ejemplo de la ejecución del comando:
75
Donde podemos ver señalado en rojo una secuencia de 6 números, 001400; es el valor del
controlador de enlace (Link Handler Value, LHN):
Para visualizar la información del disco:
76
Manejo de la versión de configuración (CV)
Hay una serie de archivos de configuración que guardan los valores que tiene el nodo o RNC
creados por los usuarios del sistema OSS que tengan acceso a los elementos de red a través de
AMOS. En caso de haber un apagón del site de forma involuntaria o un restart forzoso, se
cargará la última configuración creada. A continuación, algunos de los comandos más
significativos.
cvls. Lista los CV’s del elemento.
cvmk. Crear un CV remoto. Ejemplo: cvmk CVname indentificacion comentario
cvms. Crear un CV local. Ejemplo: cvms CVname indentificacion comentario
cvset. Arrancar el CV. Ejemplo: cvset CVname
cvrm. Elimina CV. Ejemplo: cvrm CVname
(5)
77
Aprendizaje herramienta OSS Common Explorer (CEX)
Se ha descrito en el capítulo anterior uno de los SW más importantes para la optimización y
mantenimiento de las redes UMTS y LTE, Moshell/AMOS. El manejo de esta herramienta a
nivel avanzado puede conllevar un largo periodo de aprendizaje, pues todas las operaciones se
realizan por línea de comandos y conocer la inmensa cantidad de comandos es bastante
complicado.
En el sistema OSS nos encontramos alternativas para los objetivos que cubre Moshell/AMOS,
pero a través de la interfaz gráfica; estamos hablando del OSS Common Explorer (CEX).
Funciones básicas de CEX
La aplicación CEX muestra información relacionada con la configuración y el mantenimiento de
redes de acceso radio WCDMA y LTE y para la configuración y gestión de otras áreas de
dominio disponibles en la vista Topología, por ejemplo, Cluster, Área, PLMN externo, MSS
(anteriormente llamado CORE), transporte IP y MSCPool.
CEX puede ser utilizado para las siguientes tareas:
Topología de red o configuración
Las vistas de CEX muestran información detallada relativa a los objetos y sus relaciones con
otros objetos de la red. Algunas vistas de configuración pueden utilizarse para limitar el
alcance de los objetos visualizados en otros puntos de vista para mostrar la información de un
tipo particular. Los servicios de visualización de CEX pueden ser útiles para la monitorización
de red y resolución de problemas.
Actualización de configuración de la topología de red
Utilizando varias vistas de CEX, los NEs pueden ser configurados y gestionados, y objetos
añadidos o borrados, según lo permita el contexto de la vista. Los atributos individuales
pueden ser configurados o gran volumen de transacciones pueden utilizarse para realizar
varios cambios a la red.
Inicializando aplicaciones
Un número de operación y aplicaciones de mantenimiento pueden iniciarse desde CEX.
Monitoreo de estado de red y resolución de problemas
Las vistas de CEX pueden utilizarse para monitorizar el estado de la red, revisar la salud de la
red global o de determinadas partes de ella y examinar varios indicadores de rendimiento. Las
vistas pueden ser utilizadas para chequear inconsistencias, evaluar rendimiento y si se
identifican problemas o problemas potenciales, tomar una acción preventiva.
78
Todas estas funciones se van a ver en detalle a través de los siguientes apartados que forman
este capítulo.
Vistas de CEX
Como se ha mencionado anteriormente, CEX está compuesto por vistas, las cuales son las
áreas dentro de la GUI que muestran información de la red en una gran variedad de formas. A
continuación, en detalle cada una de ellas.
Vista de topología
La vista de topología es utilizada para navegar por la red y seleccionar elementos de la misma,
cuyos detalles son visualizados en otras vistas. La vista que estamos viendo visualiza
información de la red relacionando con varios aspectos de esta en páginas separadas. Los NEs
son mostrados normalmente como un icono y etiqueta, por ejemplo:
Los elementos de red u objetos que contienen otros de nivel inferior, mostrarán un icono de
flecha para indicar que esta relación puede ser ampliada y visualizada. Por ejemplo, en la
página WCDMA cuando el icono de RNC es expandido el NodeB que controla se muestra bajo
este.
Esta vista se actualiza automáticamente en respuesta a cambios de los objetos que están
mostrados, por ejemplo, como la planificación de los cambios de estado o adición/eliminación
de elementos de red.
Hay una opción de preferencia para habilitar filtros incluidos/exclusivos. La opción preferente
“incluir automáticamente nuevos nodos en la topología” es chequeada por defecto y significa
que si hay nuevos nodos que son añadidos al sistema, aparecerán en la vista de topología de la
sesión del cliente. El usuario tendrá que desmarcar los nuevos nodos en la vista de topología
de filtro o evitar mostrar el nodo en la topología vista. Si la opción de preferencia está
desactivada, los nuevos nodos no aparecerán en la vista de topología y el usuario tendrá que
verificar manualmente los nodos agregados en el filtro de la topología para verlo en la vista.
En el layout por defecto, la vista de topología está dispuesta verticalmente en el lado izquierdo
de la interfaz gráfica. La vista de topología no se puede cerrar y permanece abierta mientras se
ejecuta CEX.
79
Navegando en la vista de topología
Tenemos las siguientes páginas dentro de la vista de topología:
- Areas
- Cluster
- ExternalPlmn
- GSM
- IMS
- IP Transport
- LTE
- MSCPool
- MSS
- WCDMA
Utilizando el selector desplegable. Cuando CEX se inicia, el elemento raíz se muestra en la vista
de topología. Se tiene que extender este elemento para buscar otros recursos de la red.
La vista de topología también se puede navegar usando el botón de opciones como:
- Flecha arriba: Nos devuelve a la red del nivel superior de los MO
seleccionados.
- Flecha izquierda: Al hacer clic se vuelve al MO anterior.
- Flecha derecha: Al hacer clic se avanza al siguiente MO; este botón estará
habilitado únicamente si hay un siguiente nivel de MO.
- Botón inicio: Lleva a la red de la raíz del MO.
- Botón de búsqueda: Se utiliza para localizar el MO presente en la topología de
red (símbolo de la lupa).
- Botón de etiqueta: Se utiliza para mostrar el MO basado en el tipo de etiqueta
o de identificación.
80
Figura 13. Entorno gráfico de la vista de topología en CEX
Acciones
Las acciones que son posibles realizar en la vista de Topología dependen del contexto. Hay
diferentes acciones disponibles en diferentes páginas en esta vista. Por ejemplo, en la página
WCDMA es posible iniciar la aplicación Node Status Analyser seleccionando un NodeB y
después clicando al botón derecho para desplegar el menú de opciones con la tool
mencionada. Esta opción no está disponible para la página de LTE.
Otras acciones que pueden realizarse en la vista de topología:
Mostrar etiqueta/ID. La vista puede ser configurada para para mostrar el número de
identificación de la MO o la etiqueta de MO.
Seleccionar elementos de red. Haciendo clic sobre el NE.
Buscar en la vista. Se hace clic sobre el icono de la lupa para mostrar la barra de
búsqueda.
Menú de accesos directos. Hacer clic en un elemento de red para mostrar un menú
contextual determinado.
Vista del contenido
81
La vista del contenido muestra objetos de la topología de red que están asociados con el
objeto seleccionado en la vista de topología. Dependiendo del contexto, esta vista muestra
una o más páginas.
El contenido de las páginas se determina por el contexto del tipo de objeto seleccionado en la
vista de topología (y los ajustes en la vista de filtro si se utiliza). La vista del contenido se
actualiza para mostrar los cambios registrados del OSS, por ejemplo MOs añadidos o quitados,
cambios realizados, etc.
Navegando en la vista de contenido
La vista de contenido consiste en una o más páginas mostradas como fichas en el botón de la
vista. Cada página representa objetos que están asociados con el objeto seleccionado en la
vista de topología. Con cada nueva selección en la topología, la vista de contenido se
actualizará.
Cada página visualiza columnas que muestran propiedades y otra información de Managed
Object para objetos seleccionados en la vista de topología. Las columnas que son mostradas
dependen del tipo de objeto; pueden ser cambiadas en el menú de preferencias. La vista de
contenido muestra normalmente la información clave del MO tales como: user Labels, IDs,
varios tipos de MO o del atributo Status, por ejemplo Synchronization Status, y otra
información de resumen como Health State y así sucesivamente.
Acciones
Las acciones disponibles en la barra de la vista de contenido son:
- Buscar
- Exportar. Exportar el contenido seleccionado.
- Preferencias
- Ordenar. Organizar la vista de contenidos en orden ascendente o descendente.
La vista de propiedades es actualizada en respuesta a las selecciones realizadas en la vista de
contenido.
Vista de explorador de MOs
La vista explorador de MO se utiliza para buscar objetos gestionados (MOs) contenido en un
elemento de red.
Para ver los MOs contenidos bajo un NE hay que realizar los siguientes pasos:
1. Desde el menú vista seleccionar MO Browser. Se abrirá el explorador de MO.
2. Seleccionar un NE desde la vista de topología.
82
La vista de explorador de MOs muestra la información del MO del NE. Esta información
puede visualizarse de dos formas:
La sección de selección de MO puede ser una serie de cuadros combinados:
Figura 14. Vista de explorador de MOs mediante combinación de cuadros
La sección de selección de MO puede ser un campo de texto editable:
Figura 15. Vista de explorador de MOs mediante campo de texto editable
Se pueden cambiar estos formatos clicando en el icono de los puntos suspensivos .
La opción predeterminada es una lista de cuadros combinados. Esta lista responde a eventos
de selección en la vista de topología. Cuando un elemento de red se selecciona en la vista de
topología, se muestra un cuadro combinado para cada RDN del objeto seleccionado. Cada una
de estas cajas combo contiene una lista de los elementos secundarios de la RDN.
La vista de propiedades se actualiza para nuevas selecciones en la vista de explorador de MO.
Cuando se utiliza junto con una configuración planificada abierta, la visualización del
navegador MO muestra los valores en las configuraciones válidas y planificadas.
La vista de explorador de MO se utiliza principalmente para la localización de MOs, para
modificar las propiedades del MO en la vista propiedades o para añadir o eliminar MOs.
83
Figura 16. Vista explorador de MO mostrando menú alternativo de creación/edición de MOs.
Vista de propiedades
La vista de propiedades muestra las propiedades de los objetos seleccionados en la vista
activa. No todas las vistas muestran la información en la vista de propiedades. Si la
información de las propiedades no está disponible, se muestra un mensaje indicándolo en la
vista de propiedades.
La vista de propiedades muestra la información en formatos adecuados para los tipos de
objetos seleccionados en la vista activa. Cuando lo permita, los usuarios pueden modificar las
propiedades de MO. La capacidad para editar los atributos depende del contexto en que fue
seleccionado el objeto, de los permisos de usuario, o del estado actual del objeto. Algunas
propiedades se muestran intencionadamente de sólo lectura por ejemplo, RbsConfiguration en
sólo lectura, los atributos mostrados en esta ficha solamente puede ser editada en la vista de
explorador MO.
Las propiedades de la red de elementos u objetos que no son específicos de un managed
object, generalmente se muestran como valores de sólo lectura. Para otras clases de managed
object mostrados en la vista de contenido o de explorador de MO por ejemplo, la vista de
propiedades muestra los datos de atributo almacenado en una base de datos del OSS y
dependiendo del contexto, los datos de atributo pueden ser editados usando la interfaz
proporcionada en la vista.
Cuando se trabaja en una planned configuration23, los valores previstos se muestran en una
columna independiente al lado de los valores válidos existentes. En la planned configuration
únicamente pueden ser editados los valores previstos. Cuando las propiedades han sido
23 Planned Configuration, configuración prevista que se carga en CEX.
84
editadas en una planned, el icono en la vista activa se actualiza para mostrar un símbolo de
lápiz para indicarlo.
Navegando en la vista de propiedades
La vista de propiedades se actualiza al realizar nuevas selecciones en la vista activa, a menos
que se haga clic en el icono de selección de Pin . Cuando está clicado, este icono congela
las propiedades mostradas para el objeto que está actualmente seleccionado en la vista activa
y permite seleccionar nuevos objetos en otras vistas sin cambiar lo que se está visualizando en
la vista de propiedades. Cuando se selecciona este icono, una cinta que contiene el texto se
muestra justo debajo de la ficha de propiedades, lo que indica que ve que la selección se
relaciona con la topología en el siguiente ejemplo:
Figura 17. Selección de la vista de propiedades en relación con la topología
Para liberar las propiedades haga clic en el icono otra vez. Vistas de propiedades adicionales
pueden abrirse haciendo clic en el menú de la vista de propiedades y seleccionando una nueva
vista de propiedades. Esto facilita la visualización de información detallada de propiedades
para dos o más objetos simultáneamente.
Las páginas con fichas se utilizan para agrupar propiedades de configuración según tipo o
función. Se hace clic en una pestaña para seleccionar la información de la propiedad requerida.
La información mostrada en este punto de vista es dependiente del contexto. Las fichas que se
muestran dependen del tipo de MO seleccionado en la vista activa; las diferentes pestañas se
muestran para un UtranCell y un ECell, por ejemplo.
Dentro de una pestaña los atributos de MO se muestran típicamente en secciones plegables,
como podemos ver en la siguiente imagen:
85
Figura 18. Vista de propiedades en CEX
Las secciones plegables se muestran normalmente en formato negrita al texto (Toggle Arrow
en la captura de la vista). Cuando se expanden, las secciones muestran los atributos y sus
valores.
Dependiendo del objeto o tipo de elemento de red, puede mostrarse información diferente en
esta vista. La versión del elemento de red también puede causar que la información en esta
vista se muestre de forma diferente. Por ejemplo, no aparece la sección KPI para nodos LTE.
Si se coloca el puntero del ratón sobre un nombre de atributo se muestra tanto la descripción
del mismo como una información sobre las herramientas. En la siguiente imagen lo vemos
sobre el Cell Identity (cId) de una celda:
Figura 19. Definición visualizada al situar el ratón sobre el nombre del parámetro
86
Si se coloca el puntero del ratón sobre el campo de valor del atributo se pueden ver los rangos
de los valores y los valores de fábrica. La información sobre herramientas muestra
descripciones derivadas del Managed Object Model; esta información indica que el cambio del
valor afecta el tráfico, como en el ejemplo anterior, se muestra un mensaje de confirmación
indicando que el cambio afecta al tráfico cuando se hace clic en el icono guardar.
Donde esté permitido, los valores de los atributos pueden ser cambiados o editados utilizando
los menús desplegables, los botones de selección o los campos editables asociados al atributo.
No se pueden guardar valores que infringen las restricciones. Fuera de rango los valores se
muestran con el texto en color rojo.
Buscar propiedades en la vista propiedades
Para buscar una propiedad particular en la vista de propiedades, se siguen los pasos indicados
a continuación:
1. En la vista de propiedades, se hace clic sobre el botón de búsqueda.
2. Para encontrar una propiedad, se introduce el nombre en el campo “Search”. La vista
de propiedades mostrará los nombres de las propiedades que coinciden con el texto
escrito.
Figura 20. Opción de búsqueda dentro de la vista de propiedades
La opción de búsqueda está habilitada por defecto para dar mayor facilidad al usuario.
Acciones
Donde pueden modificarse los atributos de la propiedad, los nuevos valores introducidos se
guardan clicando el icono “save” de la barra de herramientas de vista. Si se dispone en este
punto de vista, (por ejemplo en ciertas tablas) haga clic derecho en un MO para mostrar el
menú contextual. Si lo permite el contexto, algunos objetos pueden ser eliminados en este
punto de vista. Por ejemplo, las relaciones o canales se pueden eliminar haciendo clic derecho
sobre una fila de la tabla de relaciones y seleccionando la opción Delete (donde estén
disponibles) en el menú contextual. Dependiendo del contexto, los campos de texto pueden
mostrar opciones tales como cortar, copiar, borrar y seleccionar todo, en un menú en esta
vista.
87
A la hora de guardar los cambios, aparecerá un cuadro de diálogo de confirmación que
mostrará una lista de todos los atributos modificados con valores antiguos y nuevos.
Figura 21. Cuadro de diálogo para confirmar las modificaciones en los parámetros indicados
Vista de lista de selección
La vista de lista de selección actúa como una zona o área de la colección general de los objetos
de topología de red (por ejemplo, Node, Cell o LocationArea) o instancias de Managed Object.
La función de esta vista es de coleccionar los NEs que pueden necesitar más acciones. Para
añadir un objeto o un NE a esta vista, se hace clic al botón derecho en cualquiera de las vistas
de topología, de contenidos o de explorador de MO y seleccionar la opción “Sent to Selection
List” o hacer clic y arrastrar el elemento de red a esta vista. Por defecto, esta vista se localiza
bajo la vista de topología.
Acciones
Como en el resto de vistas presentadas en este capítulo, haciendo clic al botón derecho sobre
un NE o un número de NEs de la vista de lista de selección se muestra un menú contextual
dependiente del contexto y similar a lo visto en las capturas anteriores. Dependiendo del
contexto es posible por ejemplo eliminar un objeto.
88
Vista de comparar MO
La vista de comparar MO muestra propiedades para una o más instancias de clases de MO
para comparación y edición (siempre que sea posible). Todos los atributos disponibles para el
MO son mostrados como columnas en esta vista. Cada tipo de MO es mostrado en su propia
pestaña.
Para añadir un MO a esta vista, se hace clic derecho en el MO en las vistas de topología o
contenido y seleccionar la opción “Send to Compare MO”, o hacer clic y arrastrar el MO a esta
vista. En ciertos contextos las opciones de menú permiten al objeto que está seleccionado en
la vista activa u objetos asociados por ejemplo, las relaciones o canales a este punto de vista.
Por ejemplo, para agregar una UtranCell, canal o relación a este punto de vista, se hace clic en
el objeto de la celda en la vista del contenido y se selecciona la opción deseada, como
podemos ver en la imagen:
Figura 22. Pasos para definir una celda en la vista de comparación de MOs
Esta vista tiene alguna limitación:
- Cuando se trabaja con relaciones en esta vista (coverage, gsm o
utranrelations) no es posible seleccionar más de 30 utrancells
simultáneamente. Si se pasa este límite, las opciones estarán deshabilitadas y
no será posible llevarlo a cabo.
- La vista de comparación de MO no mostrará más de 600 entradas por
utrancells o más de 3500 entradas por utranrelations. Si se exceden estos
límites, saltarán unos mensajes de advertencia en el panel de información.
Debido a esto, cuando más de 600 celdas se seleccionan en un momento luego
las opciones de comparar el MO (utranCell, canales, relations) aparecen
atenuadas y no están disponibles para selección.
Acciones
Se puede utilizar la función Export para exportar el contenido de esta vista a un fichero.
89
Para cambiar – cuando sea posible – el valor de un atributo, únicamente se hace doble clic en
el mismo. Utilizar el icono de “save” en la barra de herramientas para guardar los cambios
realizados de esta manera. Es posible seleccionar varias instancias de objetos que se muestran
en esta vista y editar un valor para todos los casos seleccionados, utilizando la opción “Apply
value to Selection” en el menú de acceso directo.
Figura 23. Cambiar valor de un atributo en la vista de comparación de MOs
También es posible seleccionar una instancia de objetos mostrados en esta vista y editar un
valor para todas las instancias en la vista utilizando la opción “Apply Value to All”.
Figura 24. Modificación del valor en los objetos que aparecen en la vista
Vista de filtro
La vista de filtro muestra las opciones de filtro disponibles para la vista activa. Se trata de una
visión sensible al contexto (se muestran opciones de filtro apropiado para la vista) que permite
al usuario limitar la información mostrada en otros puntos de vista. Los filtros permiten a los
usuarios resolver tipos particulares de información de la red en otros puntos de vista, por
ejemplo mostrar u ocultar elementos de la red en estados particulares. La vista de filtro se
actualiza para mostrar los parámetros y opciones de filtro apropiado cada vez que la vista
activa cambia. Donde no hay opciones de filtro disponibles, la vista de filtro se actualiza para
informar al usuario que no se define filtro para la vista activa. El filtro se abre desde el menú
principal seleccionando “View” y a continuación, seleccionar “Filter”. El icono de filtro
identifica la vista cuando está abierta en la interfaz gráfica y cuando se minimiza.
90
Figura 25. Vista de filtro en CEX
La vista de filtro se compone de una serie de menús, cuadros de texto, casillas de verificación y
otras opciones que representan diversos parámetros de filtro que pueden aplicarse. La vista
activa muestra elementos que coinciden con los criterios de filtro. La vista del filtro se muestra
en formatos determinados por la vista activa. Los iconos y las barras de herramientas están
etiquetados o tienen información sobre herramientas que describen su función. Si el cursor del
ratón se sitúa sobre el objeto en la vista se mostrará información sobre las herramientas para
utilizar con dicho objeto.
Las categorías de las opciones de vista de filtro se agrupan de forma lógica, con las opciones
relacionadas ubicadas juntas. Normalmente, las categorías de los filtros están organizadas en
dos secciones dentro de la vista: “Group by” y “Filter”. La opción “Group by”, agrupa los
objetos mostrados en la tabla por el parámetro seleccionado. Esta función sólo está disponible
para ciertos tipos de objetos. Si se selecciona el elemento “none” el icono de ordenación en la
vista activa está deshabilitado.
Acciones
Para la vista de filtro se describirán a continuación varios interfaces que se pueden encontrar y
que son utilizados para modificar la información visualizada en la vista activa.
91
Filtro “Save As”. Permite guardar los ajustes de filtro. (No disponible en todas
las vistas)
Filtro “Open”. Permite al usuario abrir configuraciones de filtro guardadas.
Formato “Drop down selections”. En este formato, los parámetros de filtrado
se muestran como menús con campos de texto desplegables. El filtro “Group
by” es un ejemplo de este tipo.
Figura 26. Ejemplo de formato drop down selections para el filtro Open
Las opciones de este filtro están determinadas por los contenidos de la vista
activa. Por ejemplo, si la vista de las alarmas está activa, las opciones
relacionadas con las propiedades de alarma tales como severidad, fecha, causa
probable, etc.
Normalmente se utiliza este formato para permitir búsquedas dentro de un
rango limitado de parámetros, determinados por el contexto de la vista activa,
que tienen un rango finito de opciones; por ejemplo, tipos de elemento de red
o los parámetros de búsqueda como “Equal to” o “Not Equal to”.
El filtro muestra opciones adecuadas para cada escenario. Por ejemplo, si una
fecha se requiere de entrada, se muestra un campo de selector de fecha. La
vista activa muestra elementos que coinciden con los criterios de filtro.
Filtro “Filter option”. Este filtro tiene dos opciones que vemos en la siguiente
imagen:
Figura 27. Opciones que da Filter option
92
Match All: Se mostrará sólo el contenido que coincida con todo el criterio
requerido seleccionado por el usuario. Corresponde a la lógica AND de las
diferentes opciones de filtro.
Match Any: Se mostrará el contenido que uno de los criterios seleccionados
por el usuario. Corresponde a la lógica OR de las diferentes opciones de filtro.
Formato “Check Box”. En este formato, los parámetros de filtro aparecen
como casillas de verificación que se utilizan en combinación con los iconos o
las etiquetas de texto, indicando los puntos de vista asociada. Si una casilla de
verificación (Check Box) está seleccionada en la vista de filtro, el punto de vista
activo muestra los elementos que coinciden con los criterios de filtro. Ejemplo:
Figura 28. Formato del filtro check box
Formato "Relational operators”. En este formato, los operadores relacionales,
mostrados como desplegable filtros, se combinan con uno o más campos
editables para que el usuario pueda filtrar por los objetos que se relacionan
con los parámetros introducidos en los campos.
Este formato se utiliza habitualmente para filtrar en ordinal o nominal los
valores, tal como un nombre de objeto determinado o una fecha. Por ejemplo,
este filtro puede utilizarse para especificar que la vista activa sólo muestre los
RNCs ID menor que o mayor que un cierto valor.
Figura 29. Formato Relational operators
93
Formato “Mixed”. Dependiendo del contexto de la vista activa, un cierto
número de tipos de filtros pueden ser utilizados en combinación para crear
filtros complejos; con cada tipo de filtro de selección se agrega una capa que
refina los elementos a mostrar en la vista.
Figura 30. Formato Mixed
Filtro “Reset”. Los filtros se pueden restablecer a valores predeterminados
mediante el botón de Reset Filter.
Vista de progreso
La visión de progreso muestra tareas de comunicación permanente cliente-servidor. Carga de
información de registro o recuperación de alarmas, por ejemplo, se muestra en este punto de
94
vista. Seleccionando un nuevo elemento de red en la vista de topología carga la información
del nodo para ese NE. Esto se muestra en la vista del progreso.
Figura 31. Barras de progreso en la vista por la carga de alarmas o elementos seleccionados
No hay ningún elemento de menú o barra de herramientas en el menú principal de este punto
de vista.
Vista Planned Configuration Administration (PCA)
La vista de administración de configuración planeada (Planned Configuration Administration,
PCA) muestra todas configuraciones planificadas (también contempladas como planned areas).
La vista muestra la información resumida del plan en formato de tabla; desde esta vista las
planificaciones pueden ser creadas, activadas, borradas, verificada y otras tantas tareas. El
icono de vista PCA ( ) identifica este punto de vista en la interfaz gráfica.
Cuando una configuración planificada está abierta, CEX muestra una barra de herramientas de
configuración prevista en el mismo nivel que la barra de herramientas de aplicación, justo
debajo del menú principal, como se muestra en la siguiente imagen:
Esta barra de herramientas muestra la importación para abrir la configuración planeada y los
iconos para abrir la configuración válida.
Después de activar una configuración planificada, CEX permanece en esa configuración. Para
volver a la configuración válida, seleccione la opción Network en el menú principal, luego
seleccione Open Valid Configuration o como alternativa, seleccione el icono de abrir la
configuración válida en la barra de herramientas vista anteriormente.
Vista ahorro de energía RBS
95
RPS (RBS Power Save View) es utilizada para reducir el consumo de potencia en una red de
acceso radio, RAN, durante períodos con baja carga de tráfico. Un perfil RPS contiene una lista
de Utrancells que son bloqueadas (turned off) y desbloqueadas (turned on) en determinados
momentos (horarios) definidos en el perfil. La vista RBS Power Save se identifica en el interfaz
de CEX por el icono RPS:
Vista de utilidades
Servicios de uso es el nombre colectivo para un número de servicios que pueden ser utilizados
por CEX. Estos se componen de los siguientes servicios comunes:
Servicio de programación
Servicio de licencias
Servicio de Control de acceso
Servicio de perfiles
Servicio de plantillas
Servicio de agrupación
Servicio compartido
La vista de utilidades está identificada en el interfaz de CEX por el icono:
Vista Bulk CM Progress
La vista Bulk CM Progress (BCG) muestra toda la importación del volumen CM (las planned
areas) y las operaciones de exportación desde que se inició el interfaz de CEX. La vista muestra
un resumen de la información sobre las importaciones y exportaciones en formato de tabla.
Las operaciones pueden ser inspeccionadas o canceladas durante el transcurso de la ejecución.
96
Figura 32. Vista Bulk CM Progress de CEX
Vista de informe de consistencia de sub-red
La vista del informe de consistencia de sub-red muestra información sobre la consistencia de la
sub-red. Los informes de consistencia se presentan en formato de tabla, que muestra la
siguiente información:
Tipo de inconsistencia.
Identidad de tráfico
FDN: El nombre distinguido completo de la MO que la inconsistencia encontraría.
Cuando se selecciona una inconsistencia (fila) en la tabla, su detalle se muestra en la vista
propiedades. Cuando se hacen selecciones múltiples de fila se muestran sólo las propiedades
de la primera fila seleccionada en la vista de propiedades. A continuación, una imagen de la
vista:
97
Figura 33. Vista Sub-Network Consistency Report de CEX
El contenido del informe de inconsistencia puede ser copiado o exportado. Para copiar, haga
clic en una fila y seleccione Copy en el menú contextual. Para exportar el contenido que se
muestra actualmente en la vista hacer clic en el icono de exportación, . Exportar el
contenido completo de la vista crea un registro de instantáneas del informe tal y como
aparece en la imagen.
Para generar ficheros de Export conteniendo información más detallada – del tipo mostrado
en la vista de propiedades - seleccionar las filas necesarias en la vista de informe de
consistencia de sub-red y en la vista de propiedades, hacer clic en el icono de exportación .
Esto muestra el diálogo “Save Consistency Report”. Elegir la ubicación de archivo y el nombre
del archivo, luego guardar el archivo haciendo clic en el botón Save. En un entorno de
Windows, agregar la extensión .txt al nombre de archivo antes de guardar.
98
Figura 34. Cuadro de diálogo al solicitar exportar información de la vista de propiedades
Cuando la vista del informe de consistencia de subred de la red está activa, la vista de filtro
muestra las opciones de filtro apropiadas, véase a continuación:
Figura 35. Vista de filtro cuando la vista de informe de consistencia de subred de la red está activa
99
Los filtros se pueden colocar en: Inconsistency Type, Traffical Identity y FDN, para sólo mostrar
las incoherencias que coincidan con los parámetros especificados. La vista de filtro puede
utilizarse para limitar el contenido mostrado en la vista antes de realizar una exportación.
Vista Base Station Integration Manager
Base Station Integration Manager (BSIM) es una característica de autoconfiguración que
reduce la carga de trabajo para la preparación, las actividades y la coordinación de personal de
trabajo para el proceso de integración de nodos en una red. BSIM reduce la cantidad de datos
que se necesitan introducir en el lugar para iniciar la integración automatizada llevar un nodo b
a servicio.
Vista de logs CIF
El visor de los logs CIF proporciona las siguientes funcionalidades:
- Ver los registros de autogestión CIF almacenados en Sybase.
- Ver de forma interactiva nuevos registros CIF de autoadministración que se
producen
- Filtrar la información de registro que se muestra.
Vista de relaciones
La vista de relaciones muestra relaciones asociadas con un objeto celda seleccionada en la
vista de contenido. Las relaciones se muestran en formato tabla como se puede ver a en la
imagen indicada; cada relación es mostrada en una fila separada en la tabla.
Figura 36. Vista de relaciones de CEX
Para el tipo de objeto seleccionado en la vista del contenido, cada tipo de relación existente se
representa como una pestaña en la parte inferior de la vista. Las fichas que muestran el tipo de
100
relación se determinan por el contexto; por ejemplo, para Utrancells se muestran relaciones
del tipo EutranFreq, Utran, Gsm y Coverage.
Las propiedades de la relación como relation ID, source NodeB o source Cell se muestran como
columnas en la tabla. Se pueden cambiar las propiedades de la relación (columnas) en estas
fichas seleccionando el tipo de relación bajo el título de CEX y moviendo las columnas desde el
campo list of available columns al campo list of selected columns, según sea necesario.
Para seleccionar las opciones de CEX y vista de las relaciones en el cuadro de diálogo de
preferencias, utilizar los botones de opción de la ficha de vista de las relaciones que se muestra
por defecto para cada tipo de objeto.
Búsqueda avanzada
La función de búsqueda avanzada se puede utilizar en las vistas donde aparezca el icono para
ello:
Diálogo de la búsqueda avanzada.
Este diálogo facilita búsquedas personalizadas en una variedad de parámetros basados en el
tipo de objeto del dominio actual, por ejemplo: WCDMA, LTE. El campo Node Type se
selecciona automáticamente basado en el tipo de objeto en la vista activa donde la búsqueda
fue iniciada. La búsqueda avanzada por tipo de conexión MO también está disponible en el
dominio actual.
101
Figura 37. Cuadro de búsqueda avanzada
El tipo de objeto determina los parámetros de búsqueda que se muestran. Por ejemplo, donde
hay un número determinado de valores de ConnectionStatus, solo esas opciones pueden ser
seleccionadas o deseleccionadas. Hay parámetros que varían más, como UserLabel y FDN,
permiten búsquedas definidas por el usuario. Los operadores relacionales como 'equivale a' o
'no equivale a' pueden utilizarse para algunos parámetros que permite el contexto.
Vista de los resultados de búsqueda avanzada
La vista de los resultados de búsqueda avanzada muestra los resultados de las búsquedas
realizadas desde el diálogo de búsqueda avanzada.
Esta vista muestra la salida en formato tabla. Los objetos padre e hijos se muestran en dos
columnas. Hay dos opciones en esta vista:
- Localizar en la vista del contenido: destaca el objeto seleccionado en la ficha
correspondiente en la vista del contenido y el objeto de padres asociados en la
vista de topología.
- Eliminar: elimina la fila seleccionada de la vista.
102
Trabajando con Workspaces
Tanto la configuración especificada por el usuario como la selección de vistas, perspectivas,
preferencias y topologías activas pueden guardarse con la funcionalidad de la exportación del
workspace. Los workspaces guardados pueden ser restablecidos en una fecha posterior con la
funcionalidad de importación del workspace.
Arrancando aplicaciones desde CEX
Hay un número de aplicaciones para configuración y gestión que pueden ser iniciadas desde
las vistas de CEX con uno de los siguientes pasos:
Desde el menú principal seleccionando la opción de herramientas (Tools), se
elige la aplicación requerida.
Desde las vistas individuales las aplicaciones pueden ser iniciadas con el menú
contextual.
Figura 38. Menú contextual de CEX para abrir otras aplicaciones
Aplicaciones que no están disponibles por las razones mencionadas
anteriormente aparecen oscurecidas y no son seleccionables.
103
Visualizando elementos de red WCDMA
Se ha visto una explicación detallada de todas las vistas y el catálogo de opciones que ofrece
CEX como herramienta que toma gran valor en cuando a sacar el máximo partido a la
aplicación. A partir de este momento, este trabajo se centrará en el caso a analizar, que es la
reasignación de frecuencias mencionada en el apartado sobre justificación del proyecto; por
ello, es de gran importancia saber dónde visualizar los elementos de red para las tecnologías
de estudio, 3G y LTE. Este apartado detallará dónde localizar en CEX los elementos de WCDMA
y en el siguiente veremos lo mismo para LTE.
Para ver los elementos de la red WCDMA a cargo del OSS hay que seguir los pasos
mencionados a continuación:
1. Seleccionar la página WCDMA en la vista de la topología, seleccionando nuevamente el
objeto raíz. La vista del contenido muestra páginas de RNC y RXI. El contenido de la
página es el de las listas de RNCs gestionadas por el OSS, junto con algunos datos
básicos: (identificación de RNC, estado de sincronización, estado de conexión y así
sucesivamente). La página de vista RXI contenido muestra información similar para
RXIs.
2. Expandir el objeto raíz en la vista de topología para mostrar los nodos de RNC y RXI por
debajo. Se selecciona una RNC en la vista de topología, como se muestra en la imagen,
para mostrar las páginas de UtranCell y NodeB en la vista de contenido, en donde la
página de NodeB lista todos los NodeB controlado por el RNC.
Figura 39.Visualización de elementos desde la vista de Topología seleccionando diferentes páginas
Aquí, en la página de NodeB, se muestran tanto las RBS como los NodeB. La página de
UtranCell lista todas las celdas gestionadas por la RNC, incluyendo algunos datos
básicos de la configuración y el estado.
3. Seleccionar un nodo en la vista de topología o de contenido para mostrar sus
características en la vista de propiedades. Estas propiedades no pueden editarse.
104
Visualizando elementos de red LTE
Para ver los elementos de red para la tecnología LTE se deben seguir los pasos a continuación
presentados:
1. Seleccionar la página de LTE en la vista de topología y seleccionar el objeto raíz. La
vista de contenido muestra la página SubNetwork, visualizando todo el segundo nivel
de SubNetworks y ERBS.
2. Expandir el objeto de raíz en la vista de topología para mostrar todas las subredes del
segundo nivel y los nodos ERBS de LTE.
3. Seleccionar un nodo ERBS en la vista de topología. La vista de contenido muestra una
página ECell, listando todas las celdas LTE controladas por las RBS de LTE y también
mostrando algo de información sobre la configuración básica y de estado.
4. Seleccionar una RBS LTE en las vistas de topología o de contenido para mostrar sus
propiedades en la vista de propiedades. Estas características no se pueden editar.
5. Seleccionar el segundo nivel de SubNetwork para mostrar sus propiedades en la vista
de propiedades.
Aprendizaje herramienta Command Handling Application (CHA)
Aunque para este proyecto fin de carrera no vamos a tener en cuenta la parte de GSM, es
importante presentar la herramienta análoga a Moshell/AMOS para la configuración de los
parámetros en BTS/BSCs. Se trata de Command Handling Application(CHA).
El acceso a CHA se realiza a través del interfaz gráfico de usuario (GUI) situado en el servidor
UAS explicado anteriormente.
CHA se utiliza para ejecutar el llamado Lenguaje Hombre-Máquina (Man-Machine Language,
MML) y la comunicación del complemento del procesador (Adjunct Processor, AP) con todos
los tipos de sistemas de acceso externo (External Access, EA). Para el resto del apartado, a
tener en cuenta que los comandos MML también se referirán a los comandos de AP.
La aplicación CHA incluye las siguientes funcionalidades:
Sesiones de comandos incluyendo presentación de respuestas inmediatas
Presentación de respuestas retrasadas
Manejo de los ficheros de comandos y el sistema de ficheros de comandos.
Manejo de comandos peligrosos
CHA también proporciona acceso a las siguientes aplicaciones:
105
- Spontaneous Report Manager (SRM)
- Activity Manager (EMAM)
- Command Log Search (CLS)
El propósito de CHA es hacer más fácil para el usuario la comunicación con los elementos de
red (NE). Para las secuencias de comandos que se repiten a menudo, pueden crearse ficheros
de comandos. También es posible ejecutar secuencias de comandos de shell UNIX que puede
contener comandos MML.
En instalaciones de OSS donde la interfaz del navegador y la biblioteca activa Explorer (ALEX)
están incluidas, el usuario puede invocar documentación operacional relacionada con el texto
resaltado por el usuario, por ejemplo una descripción del comando o una descripción de la
impresión.
Un gran número de comandos de teclado configurable de usuario se proporcionan, en orden
para agilizar el trabajo de entrada de comando. El conjunto del teclado de comandos también
permite la navegación sin utilizar el ratón.
CHA soporta los NEs utilizando los siguientes protocolos:
- MTP (Message Transfer Protocol)
- X.29. Protocolo asíncrono de acuerdo a la ITU-T
- Telnet. Telnet sobre TCP/IP ( para AXE con APG40 y APG30)
Cada uno de los protocolos antes mencionados requiere un controlador de acceso externo, External Access Handler (EAH).
Descripción funcional
En este apartado se describirán funciones proporcionadas por CHA.
Sesión de comandos incluyendo presentación de respuesta inmediata.
Presentación de respuesta retardada.
Manejo de archivos de comandos
Manejo de archivo de comandos de sistema
Primitivas de script CFH
Manejo de comandos peligrosos
Sesión de comandos incluyendo presentación de respuesta inmediata
Se proporciona una ventana de comandos de sesión para enviar comandos de MML a un NE
(Network Element) y para presentar respuestas inmediatas desde el NE.
Se puede seleccionar un NE desde una lista de NEs y se conectará a la misma. Varias ventanas
de sesión de comandos pueden estar activas simultáneamente. Así es posible establecer
106
conexiones a NE más de uno a la vez; lo que hay que dejar claro es que un único NE podrá
conectarse a cada ventana de sesión de comandos al mismo tiempo.
Todo tipo de comandos pueden ser enviados a un NE.
Figura 40. Aspecto del interfaz gráfico de CHA
El campo Input Area muestra el historial de comandos introducidos manualmente o un fichero
de comando que se ha creado, editado o ejecutado. La conmutación se realiza fácilmente
entre el historial manual y un número de archivos abiertos. Además, es posible visualizar
cualquiera de los 30 últimos comandos introducidos en el Input Area (puede configurarse
indistintamente el historial real o los últimos 30 comandos diferentes), listas para enviar otra
vez o para ser incluidos en un fichero ya creado o editado.
Los comandos en el campo Input Area pueden enviarse individualmente o en un bloque de
comandos creado por el usuario.
Es posible definir uno o más grupos personales de hasta 30 macros de teclado para una
entrada rápida de comandos de uso frecuente o parte del mismo.
Un indicador de estado por encima del campo Response Area informa sobre el estado de la
conexión del NE. En el pie de la ventana se informa sobre el estado de la aplicación, incluyendo
cambios en el estado de la conexión, por ejemplo, cuando la conexión de un NE ha fallado o ha
expirado el tiempo.
Sucesivas respuestas se presentan como se reciben en el panel de texto del Response Area. Se
puede utilizar el botón Break Response o interrumpir la presentación de las respuestas. Las
107
sucesivas respuestas pueden ser encaminadas hacia un fichero (se detalla en el apartado
“Manejo de archivos de comandos”).
Los contenidos de Response Area o de Input Area, o parte de lo seleccionado en alguno de
ellos puede ser enviado a la impresora, al correo o a un fichero.
Presentación de respuesta retardada
Las respuestas retardadas son respuestas a un comando que llega en una etapa posterior, y
puede ser mostrado tanto en la ventana principal como en una ventana por separado, como se
ve en la siguiente imagen:
Figura 41. Mensaje de respuesta retardada
Se puede interrumpir la presentación de la entrada de respuestas retardadas.
Las respuestas retardadas pueden ser encaminadas a un fichero (el mismo o separado del
fichero de respuestas inmediatas). Los contenidos del Response Area o la parte seleccionada
pueden ser enviados a la impresora, correo o fichero.
Manejo de archivos de comandos
Un fichero de comandos es una secuencia de comandos MML usados en la comunicación con
un NE. Se puede crear un archivo de comandos mediante el editor incorporado en el área de la
entrada, o mediante cualquier otro texto editor con formato ASCII. Se puede crear un listado
de ficheros de comandos. Se pueden ejecutar tantos archivos de comandos como tengan
autorizado para ejecutar los comandos individuales en el archivo.
Los archivos de comandos pueden contener los siguientes bloques:
- Comandos MML
- Comandos Ap
108
- Líneas en blanco
- Comentarios
- Comandos FIOL
Al ejecutar archivos de comandos de acuerdo con lo anterior, se puede ordenar la recepción
síncrona de las respuestas. Esto significa que el comando enviado se pausa para esperar una
respuesta retrasada, antes de que el siguiente comando sea enviado. Esto puede provocar una
cierta pérdida de rendimiento. Se puede también ordenar un mail con el resultado de la
ejecución para el fichero de comando enviado.
Cuando se ejecutan ficheros de comandos, respuestas inmediatas y retardadas pueden ser
encaminadas a destinos específicos. Los posibles destinos son los siguientes:
- Ventana
- Fichero
- Impresora
- Correo
Manejo de archivo de comandos de sistema
Un sistema de archivos de comandos es un script de UNIX Shell que incluye script primitivos
CFH y esto puede invocarse con parámetros (lo vemos en el siguiente apartado). Esto
solamente puede ser creado por un usuario autorizado, esto es, el administrador del sistema.
Puesto que en este proyecto no vamos a profundizar en el uso de CHA únicamente para los
aspectos más importantes, se obvia la creación del sistema de archivos de comandos.
El script Shell puede crearse con cualquier editor de texto que maneje el formato ASCII.
Primitivas de script CFH
Las siguientes primitivas de script CFH para sistema de archivos son proporcionadas por CHA:
CFHStart, utilizado para configurar un enlace con otras primitivas.
CFHConnect, utilizado para establecer una conexión a un NE.
CFHSend, utilizado para enviar comandos MML.
CFHImRouting, utilizado para enrutar respuestas inmediatas.
CFHDelRouting, utilizado para enrutar respuestas retardadas.
CFHRouting, utilizado para enrutar ambas respuestas inmediatas y retardadas.
CFHStop, utilizado para terminar una sesión.
109
Manejo de comandos peligrosos
Los comandos peligrosos es un mecanismo que permite a un operador autorizado a definir
comandos que se considerarán como peligrosos. Para seleccionar comandos de un texto de
advertencia específicos por tipo de NE (la aplicación del sistema en el caso de ALEX) será
mostrado solicitando una segunda orden de ejecución antes de enviar el comando al NE,
cancelar la orden o acceder a la sección apropiada de la librería ALEX (COD, POD, AI, OPI).
Cualquier usuario puede ver o imprimir los comandos peligrosos y mensajes de advertencia
asociados para cualquier Network Element Type. A continuación, vemos en la imagen la
ventana emergente que salta después de introducir un comando peligroso:
Figura 42. Mensaje emergente que aparece al indicar un comando peligroso
110
Especificaciones técnicas CHA
CHA puede ser iniciado y parado por iniciativa del operador y debe ser reiniciado
manualmente después de un reinicio del sistema de OSS.
Si un reinicio del OSS ocurriese durante la transmisión de un fichero de comandos o un Shell
script, esta tiene que comenzar de nuevo de forma manual. Los ficheros de comandos y los
scripts de Shell comenzados con EMAM sobrevivirán un reinicio y se activará en el momento
especificado en caso de que todavía no se iniciaran. Si el comando enviado a EMAM se inició
en el tiempo del reinicio del sistema el archivo de comando ha de ser tratado de la misma
manera como si hubiesen comenzado desde CHA.
Se recibirá, si es especificado, un correo electrónico cuando un fichero de comandos o script
de Shell falla. La transmisión tiene que ser inicializada otra vez de forma manual.
Capacidad
La función no tiene limitación en el número de usuarios ni de NEs y no hay límites de software
en el número de ficheros de comandos o del tamaño de estos. Es posible conectarse a los 20
últimos NEs desde diferentes aplicaciones de manejo de comandos en el mismo cliente.
CHA puede manejar largas cadenas de salida, es posible navegar a través de al menos 1024
líneas.
Seguridad
Las siguientes funciones de seguridad están incluidas en el sistema:
La autorización de acceder a un NE es chequeado por cada usuario.
La autorización a enviar un comando MML es chequeado por cada usuario.
La autorización de ejecutar un fichero de comandos del sistema es revisado por cada
usuario y por el nodo del OSS. La autorización para conectarse a un NE y enviar
comandos se comprueba con la autorización del perfil del propietario del fichero de
comandos del sistema.
(6) (9)
111
ESCENARIO REAL
Descripción situación inicial
Como se ha mencionado anteriormente en este trabajo, el refarming consiste en la
reasignación de frecuencias originarias de la tecnología 2G que van a ser redestinadas hacia 3G
y LTE. A continuación vamos a plantear dos posibles escenarios que pueden darse para
expandir el área de cobertura de un área urbana a zonas rurales y donde se quiere apagar 2G
para añadir esas frecuencias a las tecnologías 3G y LTE.
Caso1: Refarming de la banda GSM a la tecnología 3G
La ciudad de Cuenca dispone de una serie de emplazamientos repartidos por todo el núcleo
urbano que cubren todas las zonas para dar cobertura. A pocos kilómetros de Cuenca se
localizan dos áreas rurales, que son Nohales y La Melgosa; el número de habitantes de ambos
municipios tiene grandes diferencias. Mientras que Nohales contaba con 55.428 habitantes
empadronados en 2015 y La Melgosa solamente tiene 192 habitantes, por lo que las
necesidades de cada uno de ellos será diferente en cuanto a requisitos radio.
A continuación, un mapa con la situación de los nodos en Cuenca así como los municipios a
analizar:
Figura 45. Situación geográfica de las áreas rurales con respecto a Cuenca y a los nodos
112
Distancia más corta de estas áreas rurales con respecto a la ciudad de Cuenca:
Cuenca-Nohales = 3,88 km
Cuenca-La Melgosa= 6,03 km
A nivel de red, ninguno de los municipios cuenta con antenas y la cobertura es proporcionada
por los sites más próximos a cada uno de ellos. Estos están situados en la ciudad de Cuenca.
Para Nohales, el emplazamiento más próximo se encuentra a 3,07 km (B1CU0010) y tiene uno
de sus sectores apuntando directamente al área rural; además, hay un segundo nodo
(B1CU0011) que también es posible candidato a cubrir la zona por una de sus celdas, orientada
en la misma dirección. B1CU0011 está situado a 3.88 km del municipio.
Figura 46. Distancia del nodo más cercano de Cuenca al municipio de Nohales
En cuanto a La Melgosa, las necesidades serán menores por el número de habitantes con los
que cuenta el municipio; se generará menos tráfico de voz/datos en la zona. Hay un sector del
nodo B1CU0015 que está apuntando hacia la zona:
113
Figura 47. Distancia del nodo más cercano de Cuenca al municipio de La Melgosa
El operador que presta sus servicios en esta zona de Castilla La Mancha ha recibido varias
quejas de clientes de Nohales y La Melgosa; las reclamaciones han sido escaladas al grupo de
optimización y después del estudio que han realizado, implementando cambios sobre el
cluster de celdas del área presentada, se ha llegado a la conclusión que es necesario llevar a
cabo un refarming liberando la banda correspondiente a GSM (para este operador en 900
MHz) y asignarlo a la tecnología 3G. Ya se contaba con UMTS en 2100MHz en los nodos de
Cuenca, pero para paliar los problemas que están sufriendo los clientes es necesario ampliar y
proporcionar mayor calidad con una nueva banda en 3G.
Caso 2: Asignación de frecuencias a la tecnología 4G/LTE
La ciudad de Segovia cuenta con un grupo de 3 emplazamientos que cubren las necesidades de
todo el área urbana. En los alrededores de la zona se sitúan varios núcleos rurales que
dependen de estos nodos para recibir todos los servicios proporcionados por el operador a sus
clientes en estos municipios.
114
Figura 48. Situación geográfica de las áreas rurales con respecto a Segovia y a los nodos
Pese a que Segovia tiene un número considerable de municipios colindantes, nos centraremos
en las necesidades de Perogordo y San Cristóbal de Segovia, cuyas quejas han llegado al centro
de atención al cliente del operador móvil.
El área rural de San Cristóbal de Segovia se encuentra a 2,91 km y cuenta con una población
entorno a los 3000 habitantes; pese a la cercanía con la ciudad, hay un gran número quejas
centradas en 4G y después de los estudios realizados por el equipo de optimización de la zona,
se ha concluido que la huella de cobertura proporcionada por los nodos más próximos es
insuficiente. Ya se está utilizando en este cluster la banda 1800 MHz y la idea es añadir una
nueva banda, 800 MHz, cuyo espectro no está siendo utilizado por otras tecnologías.
Figura 49. Distancia del nodo más cercano de Segovia al municipio de San Cristóbal de Segovia
Perogordo sin embargo, es una pequeña localidad a 3,72 km de Segovia que cuenta con un
número mínimo de habitantes, en concreto 8 censados. Al ser municipio donde sería inviable
115
instalar antenas para cubrir la cobertura de la zona, cobra más importancia aún que los nodos
colindantes puedan dar los servicios prestados. El nodo B1SG4403 es el más cercano y
encuentra a 3,07 km; también mallan el área rural los nodos B1SG4402 y B1SG4404.
Figura 50. Distancia del nodo más cercano de Segovia al municipio de Perogordo
Ya vistas ambas zonas donde se pretende realizar reasignación de frecuencias para 3G y LTE, se
abordarán en los sucesivos capítulos la problemática encontrada, posibles soluciones y cómo
implementarlas para que no afecte al performance de las provincias.
Planteamiento del problema
Se han propuesto dos situaciones diferentes para el análisis de la reasignación de frecuencias
en una red móvil, aunque en este apartado se verá todo como un problema común para las
tecnologías 3G y LTE.
Las frecuencias que hay disponibles en España para los principales operadores móviles a día de
hoy son:
800 MHz 900 MHz 1800 MHz 2100 MHz 2600 MHz
Movistar 4G 2G y 3G 2G y 4G 3G 4G
Vodafone 4G 2G y 3G 2G y 4G 3G 4G
Orange 4G 2G y 3G 2G y 4G 3G 4G
Yoigo 2G y 4G 3G Tabla 11. División de frecuencias para los principales operadores móviles en España
116
Nuestro operador móvil que presta servicio en las zonas mencionadas en el apartado anterior
comparte similitudes con Yoigo, utilizando en la actualidad las frecuencias 900MHz para 2G,
2100 MHz para 3G y 1800 MHz para LTE. Se pretende que, tras una serie de licitaciones
públicas el operador pueda hacer uso de la frecuencia 800 MHz para ampliar el mallado de
cobertura en el área urbana y permita cubrir los municipios colindantes, además de la
liberación de la frecuencia 900 MHz para el mismo fin.
En el caso de 3G, el refarming planteado liberando frecuencias de 900 MHz utilizadas por 2G
se produciría sobre el cluster de RBS de Cuenca facilitando así la penetrabilidad en los edificios
y mejorando la calidad de la llamada tanto para el área urbana como las zonas rurales
señaladas.
En Cuenca hay 6 emplazamientos en total que cubren la ciudad y los municipios colindantes:
B1CU0010, B1CU0011, B1CU0012, B1CU0013, B1CU0014 y B1CU0015. Cada uno de ellos
dispone de 3 sectores, y cuentan con todas las tecnologías implementadas. En la siguiente
tabla se puede ver la nomenclatura de cada uno de los elementos del cluster, así como la
frecuencia a la que corresponde:
RBS Celda 3G Frecuencia Celda 2G Frecuencia Celda 4G Frecuencia
B1CU0010
B1CU00101 UMTS 2100 CU00107 GSM 900 L1CU0010A LTE 1800
B1CU00102 UMTS 2100 CU00108 GSM 900 L1CU0010B LTE 1800
B1CU00103 UMTS 2100 CU00109 GSM 900 L1CU0010C LTE 1800
B1CU0011
B1CU00111 UMTS 2100 CU00117 GSM 900 L1CU0011A LTE 1800
B1CU00112 UMTS 2100 CU00118 GSM 900 L1CU0011B LTE 1800
B1CU00113 UMTS 2100 CU00119 GSM 900 L1CU0011C LTE 1800
B1CU0012
B1CU00121 UMTS 2100 CU00127 GSM 900 L1CU0012A LTE 1800
B1CU00122 UMTS 2100 CU00128 GSM 900 L1CU0012B LTE 1800
B1CU00123 UMTS 2100 CU00129 GSM 900 L1CU0012C LTE 1800
B1CU0013
B1CU00131 UMTS 2100 CU00137 GSM 900 L1CU0013A LTE 1800
B1CU00132 UMTS 2100 CU00138 GSM 900 L1CU0013B LTE 1800
B1CU00133 UMTS 2100 CU00139 GSM 900 L1CU0013C LTE 1800
B1CU0014
B1CU00141 UMTS 2100 CU00147 GSM 900 L1CU0014A LTE 1800
B1CU00142 UMTS 2100 CU00148 GSM 900 L1CU0014B LTE 1800
B1CU00143 UMTS 2100 CU00149 GSM 900 L1CU0014C LTE 1800
B1CU0015
B1CU00151 UMTS 2100 CU00157 GSM 900 L1CU0015A LTE 1800
B1CU00152 UMTS 2100 CU00158 GSM 900 L1CU0015B LTE 1800
B1CU00153 UMTS 2100 CU00159 GSM 900 L1CU0015C LTE 1800 Tabla 12. Tecnologías disponibles en el cluster de nodos de Cuenca
La RNC a la que pertenecen los nodos se llama RNC100CLM, la cual cubre toda la comunidad
autónoma de Castilla La Mancha.
Durante los últimos 6 meses, desde el servicio de atención al cliente se han recibido
numerosas quejas por parte de clientes que viven en los municipios de Nohales y La Melgosa,
dificultando la recepción de llamadas y con problemas de cobertura en sus viviendas. Se llevó a
cabo una monitorización específica de los KPIs principales – accesibilidad, disponibilidad,
117
número de llamadas caídas – confirmando las sospechas de los optimizadores, falta de huella
de cobertura y por tanto mala calidad en la llamada en ambas áreas rurales.
Figura 51. Situación geográfica de los municipios rurales con quejas de clientes
Se comprobó que el Refarming de 2G que se estaba implementando en la red todavía no se
había realizado en la RNC100CLM, algo que ya se había ejecutado en la mayor parte de España
y que los resultados habían sido bastante positivos. El equipo de optimización envía los
resultados del análisis al operador para que tome las acciones que estimen oportunas.
La idea para la tecnología 4G es ligeramente distinta, pues las bandas de la frecuencia 800 MHz
no están en uso por ninguna de las tecnologías de nuestro operador lo que disminuirá los
cambios en la red y facilitará la asignación de una nueva frecuencia. La utilización de la banda
de frecuencia 800 MHz frente a la desplegada actualmente para 1800 MHz mejorará el área de
cobertura, pues puede llegar a alcanzar hasta 5 km con una antena, resultando bastante
interesante para áreas poco pobladas como Perogordo y San Cristóbal de Segovia.
En Segovia hay solamente 4 emplazamientos cubriendo la ciudad además de los pueblos
colindantes: B1SG4401, B1SG4402, B1SG4403 y B1SG4404. Todos ellos están compuestos de 3
sectores y tienen las 3 tecnologías radiando. La RNC que cubre esta provincia es RNC123SEG. A
continuación, una tabla con todas las celdas y tecnologías desplegadas en este cluster:
RBS Celda 3G Frecuencia Celda 2G Frecuencia 1 Celda 2G Frecuencia 2 Celda 4G Frecuencia
B1SG4401
B1SG44011 UMTS 2100 SG44017 GSM 1800 SG4401X GSM 900 L1SG4401A LTE 1800
B1SG44012 UMTS 2100 SG44018 GSM 1800 SG4401Y GSM 900 L1SG4401B LTE 1800
B1SG44013 UMTS 2100 SG44019 GSM 1800 SG4401Z GSM 900 L1SG4401C LTE 1800
B1SG4402 B1SG44021 UMTS 2100 SG44027 GSM 1800 SG4402X GSM 900 L1SG4402A LTE 1800
B1SG44022 UMTS 2100 SG44028 GSM 1800 SG4402Y GSM 900 L1SG4402B LTE 1800
118
B1SG44023 UMTS 2100 SG44029 GSM 1800 SG4402Z GSM 900 L1SG4402C LTE 1800
B1SG4403
B1SG44031 UMTS 2100 SG44037 GSM 1800 SG4403X GSM 900 L1SG4403A LTE 1800
B1SG44032 UMTS 2100 SG44038 GSM 1800 SG4403Y GSM 900 L1SG4403B LTE 1800
B1SG44033 UMTS 2100 SG44039 GSM 1800 SG4403Z GSM 900 L1SG4403C LTE 1800
B1SG4404
B1SG44041 UMTS 2100 SG44047 GSM 1800 SG4404X GSM 900 L1SG4404A LTE 1800
B1SG44042 UMTS 2100 SG44048 GSM 1800 SG4404Y GSM 900 L1SG4404B LTE 1800
B1SG44043 UMTS 2100 SG44049 GSM 1800 SG4404Z GSM 900 L1SG4404C LTE 1800
Tabla 13. Tecnologías disponibles en el cluster de nodos de Segovia
En la tabla se ve que en Segovia sí que se ha hecho el Refarming de 2g a la frecuencia G900,
pero el problema denunciado por parte de los clientes que viven en los municipios de San
Cristóbal de Segovia y Perogordo es que no tienen conexión a Internet, en concreto no reciben
4G y además pierden de manera frecuente la conectividad.
El listado de quejas llega hasta el equipo de optimización que encarga un análisis de la calidad
de cobertura en toda la zona por medio de un Drive Test y confirman, efectivamente, los
problemas denunciados además de conectividad 4G limitada en Segovia ciudad. El resultado
de este análisis es compartido con el operador para que tome las decisiones que estimen y así
dar el servicio vendido a sus clientes.
Posibles soluciones. Parametrización a utilizar
Está claro que en los casos presentados en apartados anteriores el resultado final conlleva
añadir una nueva frecuencia en los nodos de los clusters de Cuenca y Segovia. El escenario que
quedará desplegado para 3G y 4G mejorará la calidad de la cobertura tanto en zona urbana
como en los municipios con déficit en voz y datos. A continuación, se presenta un análisis de
las soluciones que se toman para cada una de las tecnologías así como los parámetros que se
tendrán en cuenta a la hora de llevar a cabo la reasignación de frecuencias.
Refarming de 2g a 3g
En el análisis realizado por optimización se confirmaron los pésimos parámetros de calidad
producidos por una mala huella de cobertura que afectaba, tanto a los municipios como al
área urbana. El operador ha decidido programar el refarming de 2G que ya está implementado
en otras zonas de España y asignar la frecuencia a la tecnología 3G.
El refarming es una oportunidad de ampliar la cobertura y reducir costes, pues no sale
rentable además de no estar contemplada la instalación de más nodos en zonas donde el
tráfico es mínimo, como ocurre en Nohales y La Melgosa. Esta reorganización puede verse en
términos generales, como un proceso que constituyen cambios básicos en las condiciones de
uso de frecuencia de una determinada parte del espectro radioeléctrico. Tales cambios
podrían ser:
119
- Cambio de las condiciones técnicas para asignaciones de frecuencias.
- Cambio de aplicación (sistema de comunicación de radio determinado usando
la banda)
- Cambio de asignación a un servicio de comunicación de radio diferente.
Para el caso de Cuenca, se va a liberar la frecuencia que está utilizando 2G actualmente (900
MHz) y se destinará a un servicio diferente, en este caso de la tecnología 3G. La decisión
tomada por el operador se centra básicamente en los beneficios que le aportará UMTS 900
frente a lo que está actualmente desplegado, GSM 900 y UMTS 2100. Las ventajas claves son:
Cobertura. El análisis indica que proporciona entre el 44% (área urbana) y 119%
(área rural) de incremento de cobertura por Node-B comparado con UMTS 2100.
Esto es principalmente debido a las características de propagación de la banda de
frecuencia más baja. Todas las aplicaciones 3G pueden proporcionarse y utilizarse
de forma más eficiente en un área mucho más grande ya que el radio de cobertura
de 900 MHz es casi el doble que la del espectro de 2100 MHz.
Coste efectivo. La pérdida de propagación de ondas de radio está a menos de 900
MHz, por lo que con menos estaciones base necesarias se conduce a ahorros de
alrededor del 50-70% en comparación con las redes desplegadas en el espectro de
3G de 2100MHz. Estos beneficios de cobertura y ahorro de costes significa que el
operador puede traer servicios 3G a las zonas densamente menos pobladas que
fueron previamente antieconómicas cubrir.
Mejor calidad de servicio (QoS). Puesto que son necesarias menos estaciones base
para UMTS 900 que para UMTS 2100, la experiencia del cliente es mejor debido a
que se producen menos handovers (HO). La banda de frecuencias más baja tiene
mayor penetración en el edificio. Más del 70% de llamadas son hechas en el
interior y UMTS 900 puede ayudar a mejorar QoS. (8)
Una vez claros los puntos de mejora que se van a experimentar tras el refarming, hay que
conocer los parámetros que se modificarán para poder llevarlo a cabo. La fase previa a la
puesta en funcionamiento de UMTS 900, se han integrado en cada una de las RBS las celdas
además de definir a nivel de Core la parametrización correspondiente; de todo este trabajo se
encargará el grupo de implementación junto con técnicos de campo si fuese necesario hacer
algún trabajo en local.
En el cluster de nodos de Cuenca, se va aislar el 2G de 900 MHz primero para luego hacer la
migración a 3G 900 MHz.
- Se localizan las celdas 2G del cluster de Cuenca, para borrar la definición de
estas a través de la herramienta del OSS CNA y después se ejecuta un adjust
para dejar sincronizada la base de datos de CNA con lo que hay definido en
red.
- Se define en la RNC al que pertenece el cluster la nueva frecuencia de 900 MHz
a través de Amos/Moshell.
- Se definen las celdas con los valores correspondientes en los parámetros
uarfcn DL y uarfcn UL de cada una de las celdas a través de Amos/Moshell.
- Se definen las relaciones de vecindad necesarias para el HO a través de CEX.
120
UARFCN (UTRA Absolute Radio Frequency Channel Number) es el parámetro por el que se
identifica el canal o banda de frecuencia. UARFCN viene dado por la expresión:
UARFCN = 5 x frecuencia_central (Mhz)
Existen dos tipos de comunicación bidireccional por un único medio en UMTS: FDD y TDD. En
España se utiliza UMTS-FDD (2x35 Mhz), donde el rango de las bandas de subida y bajada
corresponden a:
- Uplink (UL): 880-915 Mhz
- Downlink (DL): 925-960 Mhz
Para el cluster de Cuenca, la frecuencia de bajada será 945 Mhz y la de subida corresponderá a
900 Mhz. Por tanto, los valores a establecer en las RBS serían:
Band Name Uarfcn DL Downlink (MHz) Uarfcn UL Uplink (MHz)
8 900 GSM 3025 945.0 2800 900.0
Tabla 14. Valores a establecer en uarfcndl y uarfcnul para la nueva frecuencia 3G
Los atributos uarfcndl y uarfcnul se definen para cada celda, a nivel de utrancell en la propia
RNC; se lleva a cabo a través de la herramienta Moshell/AMOS.
Además de definir las celdas 3g en la RNC, aquí también se debe definir la nueva frecuencia
mediante FreqBand que indica la banda, para 900 Mhz es 8. Este atributo cuelga del MO
WcdmaCarrier que tendremos que tener también definido a nivel de RNC. Con WcdmaCarrier
definido y FreqBand con la banda correcta, se consigue el HO entre las celdas definidas para la
nueva banda. (7) (9)
Asignación frecuencia 800MHz a 4g
El operador ha manifestado el deseo de añadir la nueva frecuencia liberada para LTE en la
provincia de Segovia. El principal interés se centra en la mejora de QoS en las zonas urbana y
rural, como es el caso de Perogordo y San Cristóbal de Segovia con respecto al cluster de
nodos en Segovia, del cual depende la cobertura que reciban.
Inicialmente, la banda que ocupa la frecuencia 800 Mhz estaba destinada a la TDT pero
después de una gran inversión económica por parte de los principales operadores móviles se
liberó y asignó las licencias que permiten la utilización del espectro. Las principales ventajas de
utilizar esta frecuencia son una mayor velocidad y la mejora de cobertura con respecto a 1800
Mhz. La banda de 800 Mhz al ser más baja permite por un lado tener antenas con un mayor
alcance y por otro mejor cobertura en interiores (mayor penetrabilidad) que con las bandas de
1800 Mhz y 2600 Mhz que se utilizan en la actualidad para 4G.
En el caso del cluster de Segovia no será necesario liberar previamente la banda de otra
tecnología, como fue el caso anteriormente detallado, por lo que únicamente se definirán las
celdas para la nueva banda en cada uno de los eNodeB junto con el valor correspondiente del
parámetro earfcn.
121
EARFCN (E-UTRA Absolute Radio Frequency Channel Number) señala la frecuencia de la
portadora en LTE para UL y DL; su valor oscila entre 0 y 65535.
- EARFCN identifica de manera única la banda de frecuencia y la portadora de
LTE. Por ejemplo, la banda 1 y 4 pueden tener la misma frecuencia RX 2110-
2170 Mhz pero su earfcn es diferente.
- EARFCN es independiente del ancho de banda del canal.
Nuestro operador utiliza LTE-FDD (2 x 15 Mhz) y en nuestro caso, los valores de earfcndl y
earfcnul que hay que setear en las ERBS compatibles con la frecuencia 800 Mhz sería:
Band Name Bandwidth (MHz)
Mode Earfcn DL Downlink (MHz)
Earfcn UL
Uplink (MHz)
20 800 DD 30 FDD 6240 800.0 24240 841.0
Tabla 15. Valores a establecer en earfcndl y earfcnul para la nueva frecuencia de 4G (7)
En LTE, al ser ERBS el controlador de todas las funciones desempeñadas por el nodo y por
tanto por sus celdas definidas, solamente es necesario añadir el valor para earfcndl y earfcnul a
nivel de eNodeB por el SW Moshell/AMOS; el MO del que cuelgan es EUtranCellFDD. Otros
parámetros a definir además de las celdas y earfcn, son:
- dlFrequencyAllocationProportion/ulFrequencyAllocationProportion. Pertenecen
al MO EUtranCellFDD y especifican la cantidad de recursos de frecuencia
asignados a DL/UL, expresado como un porcentaje del ancho de banda
configurado. El valor para ambos parámetros será de 100.
- ChannelBandwith. Se configura en función a la frecuencia central y el ancho, ya
que este atributo especifica justamente el ancho de banda en Mhz. Para
nuestro caso será de 15 Mhz.
Además de los atributos específicos para las nuevas celdas de 800 Mhz, habrá que fijarnos en
las relaciones de vecindad a definir dentro del cluster para posibilitar el HO entre ellas. La
creación de vecinas se implementará con CEX OSS. (13) (14)
122
123
4. OPTIMIZACION DE REDES 3G/LTE
Al realizar implantaciones de nuevas frecuencias en redes 3g/4g como se han presentado en
este proyecto fin de carrera, ya sean sobre una banda libre o ya ocupada por otra tecnología,
habrá que prestar especial atención a los KPIs y contadores que nos proporcionan en qué
estado se encuentran nuestros clusters de Cuenca y Segovia.
No hay que olvidar que el objetivo es alcanzar los requerimientos establecidos con el cliente,
basándose en los siguientes aspectos:
Alcanzar niveles de cobertura adecuados.
Reducir los niveles de interferencia que puedan estar causando nodos
cercanos y que puedan presentar overshooting24.
Asegurar una tasa de HO suficiente que asegure la continuidad de los servicios
a medida que el móvil se desplaza. En los casos vistos en los anteriores
apartados llevan a pensar que el porcentaje de HO deberá ser alto por el
número de nodos que componen los clusters vistos, que son escasos.
En los siguientes puntos se explican los KPIs más importantes a revisar y chequear después de
llevar a cabo el refarming de 2g a 3g y la asignación de 800 Mhz a LTE, con la relevancia de
cada uno de ellos en su respectiva red.
OPTIMIZACION RED UMTS
Antes de ejecutar los comandos y scripts necesarios para hacer la reasignación de frecuencia
de 2G a 3G se lanzará un health check a la RNC del cluster de Cuenca. Es importante que no se
vea afectada ni antes ni después del refarming ninguno de sus principales KPIs.
El cluster de nodos también estará monitorizado durante los 2 primeros días a nivel horario,
inmediatamente después del trabajo, además de hacer un seguimiento hasta la 3º semana a
nivel diario. Los KPIs que se revisarán serán los mismos que los vistos para la RNC pero
únicamente con el agregado del cluster de RBS. En caso de detectarse una degradación de
cualquier KPI, se hará un troubleshooting25 para determinar si hay que hacer rollback –
marcha atrás – del trabajo.
Los KPIs que se van a presentar a continuación no sólo serán claves para confirmar que el
trabajo se ha llevado a cabo exitosamente, si no que nos van a dar en todo momento
24 Sobrealcance de una o varias celdas por no estar optimizado correctamente su tilt y/o los parámetros de potencia de la celda/RBS. 25 Se llama Troubleshooting al seguimiento y análisis llevado a cabo por parte del grupo de optimización cuando se detecta una degradación en un KPI. En algunos casos no se ha llegado a determinar el origen de este problema, por lo que se decide dar marcha atrás al trabajo y analizar a fondo qué puede haber producido esta degradación sin comprometer los niveles óptimos de la RNC.
124
información del estado de la RNC por si hubiese que optimizar para cumplir con los
parámetros acordados con el cliente. Se agrupan en las siguientes categorías:
Figura 52. Principales categorías de los KPIs para el control del estado de la red
Accesibilidad (Accesibility)
En la categoría accesibilidad se van a tener en cuenta también los KPIs de disponibilidad, y que
los niveles mantengan un mínimo valor establecido para un correcto servicio. Los límites
establecidos para estos KPIs:
nombre KPI valor mínimo
CSSR Speech 98%
Cell availability 95%
CSSR PS 98%
CSSR CS 98% Tabla 16. Rango mínimo de valores en los KPIs de accesibilidad
A continuación, una presentación de cada uno de ellos:
Cell availability. La disponibilidad de celda es definida como la longitud de tiempo en
segundos que un celular está disponible para el servicio.
La longitud de tiempo en segundos en el que un celular no está disponible debido a un mal
funcionamiento se llama "tiempo de inactividad no planificado". Este período puede ser
medido por el contador pmCellDowntimeAuto(UtranCell) en segundos.
La longitud de tiempo en segundos que un celular no está disponible debido a mantenimiento
se llama “tiempo de inactividad planificado”. Este período se puede medir por
pmCellDowntimeMan(UtranCell) en segundos.
La fórmula de cell availability se compone de ambos períodos de inactividad, y viene dada de
la siguiente manera:
125
Cell_availability_total (%) = 100 - (100 * (pmCellDowntimeAuto + pmCellDowntimeMan) / (data_coverage * 60))
CSSR (Call Setup Success Rate). Indica la tasa de establecimientos de llamada
realizados con éxito frente a los que se han intentado. A efectos de análisis, esta tasa
se mide en porcentaje % mediante la fórmula:
CSSR (%) = 100 x (Call Setup Successful /Call attempts)
Dentro de los intentos de llamadas habrá que contabilizar las llamadas exitosas, las
interrumpidas cuando ya están establecidas y las que no se llegaron a establecer.
El CSSR hace referencia a la accesibilidad de la red, por lo que si este parámetro tiene un valor
elevado significará que tiene capacidad para establecer la mayoría de las llamadas que se
intentan establecer. Representa el porcentaje de llamadas caídas de todos los intentos
realizados y en el cluster de Cuenca este KPI será bastante sensible a sufrir degradaciones si no
está bien optimizado dado el bajo número de usuarios tanto en el núcleo urbano como las
zonas rurales a las que dotar de mayor calidad del servicio con el refarming.
En UMTS se separa este KPI en función del servicio prestado, por lo que podemos
encontrarnos con un gran número de ellos. Para el caso analizado, se prestará especial
atención a: CSSR Speech or CS (servicios de voz), CSSR PS (para servicios de datos) y CSSR HS
(servicios de HSDPA).
Minutes Speech. Otro KPI importante que se puede englobar en la categoría de
accesibilidad es el del tráfico de voz que lleva la RNC o un agregado de los elementos
necesarios; en el caso de Cuenca, los minutos de voz se verán incrementados después
del refarming ya que ganará el tráfico de 2G con la nueva frecuencia 3G.
Minutes Speech = 60*pmSumBestCs12Establish/(BestCs12Establish (sum))x(data_coverage/60)
Reteneabilidad (Retainability)
Los KPIs que constituyen la categoría Retainability son, junto al anterior grupo presentado, los
más importantes a la hora de optimizar una red UMTS/WCDMA. Todos los KPIs que a
continuación se van a ver están relacionados con el número de llamadas caídas o paquetes
perdidos en una conexión establecida; como en accesibilidad, los KPIs de drops en los nodos de
Cuenca impactarán en gran medida en las estadísticas, pues el tráfico es bastante inferior a los
cluster que se pueden presentar en ciudades como Valencia o Sevilla.
Dropped Call Rate, DCR (%). Es el KPI más común de la categoría. La tasa de llamadas
caídas hace referencia a las llamadas que se han caído de la red antes de ser
finalizadas. Este KPI se mide en porcentaje y normalmente entra dentro de valores
normales los rangos iguales o inferiores a 0.5%. La fórmula general vienen dada por:
DCR (%) = 100 x Nº dropped calls / Nº total calls
126
Dependiendo del tipo de servicio, los KPIs serán DCR Speech, DCR PS y DCR HS entre
otros; estos son los más importantes.
Packet Switched (PS) Interactive Minutes Per Drop. Es importante conocer la cantidad
de tráfico que se pierde en las caídas de llamadas, por lo que DCR va relacionado
directamente con el KPI Minutes Per Drop. La fórmula viene dada por:
Minutes_per_Drop_PS_HS = data_coverage x [(pmSumBestPsHsAdchRabEstablish /
pmSamplesBestPsHsAdchRabEstablish) + (pmSumBestPsEulRabEstablish /
pmSamplesBestPsEulRabEstablish)] / pmNoSystemRbReleaseHs
Existen en el OSS una serie de contadores que nos indican las causas de las llamadas caídas y,
en función de lo que se vea en el performance de la RNC o del cluster de nodos se puede
determinar qué es lo que está fallando y los pasos de optimización que hay que seguir para
recuperar valores óptimos. Estos contadores de causas son:
Drops by Missing Neighbours (MN). Se producen por falta de relaciones de vecindad
entre nodos cercanos. El contador que la representa se llama
pmNoSysRelSpeechNeighbr y por cada llamada caída por este motivo se incrementa en
uno.
Drops by Congestion. La congestión en el enlace descendente limita la admisión a la
celda congestionada. El contador que hace referencia a esta causa de caídas es
pmNoOfTermSpeechCong y viene a definir el número de conexiones de voz radio
servidas por la RNC que han finalizado por congestión.
Drops by Soft Handover (SoHo). Se refiere al número de desconexiones del sistema de
llamadas de voz para localizar la mejor celda en activo debido al soft handover; el
contador que representa estas caídas es pmNoSysRelSpeechSoHo y también incluye
todas las caídas por MN.
Drops by Uplink Synchronization (ULSync). Se producen cuando hay desconexiones
del sistema de llamadas voz para localizar la mejor celda debido a pérdida de
sincronización en el enlace descendiente. El contador que representa estas causas es
pmNoSysRelSpeechUlSynch.
Drops by other causes. Las llamadas que no pueden ser detectadas por un motivo
claro se tipifica como desconocido; no hay un contador vinculado a esta causa, por lo
que para detectarlas se utilizará la siguiente fórmula:
DROP_OTHERS = pmNoSystemRabReleaseSpeech – pmNoSysRelSpeechSoHo –
pmNoSysRelSpeechUlSynch – pmNoOfTermSpeechCong - (pmNoAttOutIratHoSpeech –
pmNoSuccessOutIratHoSpeech –pmNoFailOutIratHoSpeechReturnOldChPhyChFail -
pmNoFailOutIratHoSpeechReturnOldChNotPhyChFail - pmNoFailOutIratHoSpeechUeRejection)
Cuando el número de caídas por causas desconocidas sea elevado, se chequearán
otros parámetros como niveles de interferencia, disponibilidad de los nodos y la RNC,
congestión HS, etc.
127
Movilidad (Mobility)
Las relaciones entre las distintas tecnologías que incluyen los nodos de Cuenca son de gran
importancia debido al bajo número de RBS en la zona, pues recordar que tienen que cubrir
toda el área urbana de la ciudad de Cuenca además de los municipios rurales donde se están
concentrando las quejas de clientes, Nohales y La Melgosa.
Con el refarming de 2g a 3g se reducirá al 0% el éxito de HO entre UMTS y GSM precisamente
por el aislamiento que se llevará a cabo; por el contrario, el HO entre celdas 3G de diferente
banda debe aumentar.
A continuación, los principales KPIs de movilidad a tener en cuenta tanto para la
monitorización antes y después del trabajo como por si fuera necesario optimizar el cluster.
Inter-RAT Handover, IRAT HO. IRAT es utilizado principalmente para el HO entre
diferentes RAT (Radio Access Technology). En este caso, el KPI IRAT HO Success Rate
(%) de llamadas desde 3G a 2G después del refarming debería salir 0%. La fórmula es:
IRAT HO Succ Rate (%) = 100 x (pmNoSuccessOutIratHoSpeech/ (pmNoAttOutIratHoSpeech-
SpeechUeRejection))
Inter-Frequency Handover, IFHO. Este tipo de traspaso permite a la red UTRAN
cambiar la frecuencia del servicio durante el estado del canal dedicado. Como el IRAT
HO, el procedimiento IFHO consta de 2 pasos:
- Las mediciones IFHO
- El traspaso IFHO
La fórmula con la que calcular el % de éxitos de llamadas inter-frequency viene dada
por:
IFHO Succ Rate (%) = 100 x (pmNoSuccOutCnhhoSpeech/pmNoAttOutCnhhoSpeech)
Este KPI después de la reasignación de frecuencias debe aumentar pues el aislamiento
de 2G desviará el tráfico a 3G y los traspasos de llamadas se producirán entre ambas
frecuencias.
Intra-Frequency Handover. Incluye dos tipos de traspaso: intra-frequency soft
handover e intra-frequency hard handover. En la siguiente imagen se muestra cómo se
produce cada uno de ellos, entre dos celdas:
128
Figura 53. Representación gráfica de los tipos de Handover Intra-freq entre dos celdas
En intra-frequency soft handover se establece una nueva conexión entre el UE y la celda 2
mientras que la conexión entre el UE y la celda 1 todavía se mantiene. En este caso, UE
mantiene las conexiones a las celdas 1 y 2 simultáneamente. Después de cumplirse la
condición de desconexión, UE se desconecta de la celda 1.
En intra-frequency hard handover, el UE se desconecta de la celda 1 antes de ajustar la
conexión a la celda 2. Este tipo de traspaso es menos común, pues se utiliza cuando no existe
el interface Iur entre dos RNCs.
Utilización (Usage)
En esta categoría se engloban todos los KPIs que miden RAB (Radio Access Bearer). Se conoce
como RAB al conector para el acceso radio el cual AS26 a la NAS27 y así proporcionar el servicio
de transferencia de información entre la UE y Core Network (CN).
RAB Speech Success Rate. RAB Speech proporciona servicios tales como llamada de
voz CS. Cuando CS tiene éxito, significa que UTRAN está listo para un acceso de servicio
de voz de CS. Es importante evaluar la accesibilidad de discurso de CS en UTRAN. La
fórmula viene dada por:
RAB_Speech_Succ_Rate (%) = 100 x
(pmNoRabEstablishSuccess.Speech/pmNoRabEstablishAttempt.Speech)
26 AS, acceso estrato es un grupo de protocolos específicos de la red de acceso. 27 NAS, no acceso estrato es decir, el resto de protocolos que nos son de red de acceso.
129
Integridad (Integrity)
Integridad se define como la capacidad de un usuario para recibir el servicio solicitado en la
calidad deseada. La integridad se mide en términos de Block Error Rate (BLER), Throughput
Packet y la latency. Para el trabajo de refarming, los más importantes a la hora de monitorizar
la red:
Throughput Packet Switched HSDPA Users (Tput PS HS users). Este KPI caracteriza la
velocidad con que los usuarios reciben y envían datos desde y hacia la red. Es común
que a principios de cada mes las tasas de Tput sean más elevadas ya que las tarifas de
datos de los clientes han comenzado un nuevo periodo de facturación y por tanto, el
consumo de datos se inicializa a 0. Estos contadores son a nivel de UtranCell por lo que
se puede adaptar al estudio del cluster de Cuenca. La fórmula:
TPUT PS HS Users (kbps) = pmSumHsDlRlcUserPacketThp/pmSamplesHsDlRlcUserPacketThp (sum)
Throughput Packet Switched EUL (Tput PS EUL). Indica lo mismo que el utilizado para
usuarios, únicamente que este KPI está orientado a la red, esto es, a la RNC a la que
pertenece el cluster. Por tanto, la información que se recibe de Tput PS EUL es a nivel
RNC exclusivamente; su fórmula:
TPUT PS EUL (kbps) = pmSumEulRlcUserPacketThp/pmSamplesEulRlcUserPacketThp (sum)
(9)
OPTIMIZACION RED LTE Advanced
En la asignación de la frecuencia 800 Mhz en el cluster de Segovia se deberá, como en el caso
de Cuenca, llevar a cabo una monitorización antes del trabajo como después a nivel horario los
primeros días y a nivel diario en las 3 siguientes semanas. Siempre que se detecte una
degradación de alguno de los KPIs bajo monitorización, se llevará a cabo un troubleshooting
para buscar el causante y si fuese por la asignación de la nueva banda, valorar la optimización
o el rollback del trabajo.
A continuación, una imagen donde se puede ver la organización de los KPIs de LTE que son
utilizados para la monitorización y optimización de la red:
130
Figura 54. Clasificación de los principales KPIs por categorías en LTE
Este capítulo se centra en los principales KPIs que son importantes para llevar a cabo la
monitorización de la agregación de la nueva banda en el cluster de Segovia.
Accesibilidad (Accessibility)
Cabe recordar que en LTE el controlador es el propio nodo, por lo que todas las consultas que
se desarrollen en las diferentes tools del OSS tomarán el agregado de un cluster de ERBS o de
celdas 4G. En la categoría de accesibilidad se presentan los KPIs más importantes para
monitorizar antes del trabajo y después.
LTE RRC Success Rate. El procedimiento de configuración de RRC se desencadena por
diversas razones como emergencia o acceso de alta prioridad entre otras. Este KPI
evalúa el la tasa de éxito de conexión RRC de los servicios relacionados con la causa en
una celda o cluster.
LTE RRC Succ Rate (%) =100 x ([pmRrcConnEstabSucc] / ([pmRrcConnEstabAtt]-
[pmRrcConnEstabAttReatt]))
ERAB Setup Success Rate (ALL). Este KPI puede ser utilizado para evaluar el éxito de
conexión ERAB de todos los servicios incluyendo el de voz sobre IP (VoIP) en una celda
o cluster.
ERAB Setup Succ Rate (%) = 100 x
([pmErabEstabSuccInit]+[pmErabEstabSuccAdded])/([pmErabEstabAttInit]+[pmErabEstabAttAdded])
Disponibilidad (Availability)
131
En cuanto a la disponibilidad en el cluster de Segovia, los KPIs de esta categoría tomarán gran
importancia en la monitorización después de añadir la nueva frecuencia pues indicarán si se ha
caído alguna celda o varias de LTE 800.
Cell Availability. Este KPI puede mostrarse como el agregado de todas las ERBS de
Segovia y nos indicará el porcentaje de disponibilidad del conjunto.
Cell Availability (%) = 100 x ((data_coverage * 60) -
([pmCellDowntimeAuto]+[pmCellDowntimeMan])) / (period_duration * 60)
Cell downtime. Nos proporciona el % de tiempo en que una celda o cluster ha estado
caído. A continuación, las fórmulas para el cell downtime manual (celda bloqueada por
el ingeniero) y el auto (cuando la celda se cae sola):
Cell downtime Auto (%)=100 x [pmCellDowntimeAuto]/ ([data_coverage] x 60)
Cell downtime manual (%)=100 x [pmCellDowntimeMan]/([data_coverage] x 60)
Reteneabilidad (Retainability)
En Segovia se prestará especial atención a las llamadas caídas en LTE, pues el tráfico es muy
bajo y cada posible drop puede incrementar enormemente alguno de estos KPIs. A
continuación, los significativos a la hora de monitorizar el cluster:
LTE Call Drop Rate (ALL). Este KPI se utiliza para evaluar el porcentaje de llamadas
caídas de todos los servicios de una celda o cluster, incluyendo VoIP.
LTE Call Drop Rate (%) = 100*([pmErabRelAbnormalEnbAct]+
[pmErabRelAbnormalMmeAct])/([pmErabRelAbnormalEnb]+[pmErabRelNormalEnb]+[pmErabR
elMme])
MPD ERAB Retainability. Muestra cuantos minutos los usuarios finales pierden una
conexión E-RAB de forma anormal durante el tiempo que se utiliza.
MPD ERAB Retainability (min) = 1/(60 x
(([pmErabRelAbnormalEnbAct]+[pmErabRelAbnormalMmeAct])/[pmSessionTimeUe]))
Movilidad (Mobility)
Al igual que se le da importancia en 3G la movilidad entre misma tecnología y diferentes RAT,
para el caso de Segovia se continuará con la monitorización de los KPIs relacionados con este
tipo de HOs. Hay que tener en cuenta que el tráfico 4G será menor que el de 3G, pues
dependiendo de las características de los dispositivos en zonas rurales y urbana, podrán
acceder a la red LTE o no.
132
Intra-Frequency Handover Success Rate. Como el nombre indica, este KPI evalúa los
éxitos de HO entre dos celdas LTE con la misma frecuencia.
Intra Freq HO SR (%) = 100 x
([pmHoPrepSuccLteIntraF]/[pmHoPrepAttLteIntraF])*([pmHoExeSuccLteIntraF]/[pmHoExeAttLteIntraF])
Intra-RAT Handover Success Rate. Con este KPI se calculará el porcentaje de éxito de
HO de tipo intra e inter (diferentes frecuencias dentro de la misma tecnología LTE)
para el mismo operador.
IRAT HO SR (%) = 100 x
([pmHoExeSuccLteIntraF]+[pmHoExeSuccLteInterF])/([pmHoExeAttLteIntraF]+[pmHoExeAttLteInterF])
Session Continuity to WCDMA Activity Rate. Mide el porcentaje de conexiones que se
inician en LTE y continúan en 3G.
Session Continuity to WCDMA Activity Rate (%) = 100 x [pmUeCtxtRelSCWcdma]/
[pmUeCtxtRelNormalEnb]
Session Continuity to GSM Activity Rate. Mide el porcentaje de conexiones que se
inician en LTE y continúan en 2G.
Session Continuity to GSM Activity Rate (%) = 100 x [pmUeCtxtRelSCGsm]
/[pmUeCtxtRelNormalEnb]
Tráfico (Traffic)
La categoría de tráfico agrupa una serie de KPIs de gran importancia en la evaluación del
trabajo de Segovia. Son utilizados para chequear el número de usuarios que tienen conexión
RRC en la celda, el número de usuarios con datos de subida en el buffer o datos de bajada en el
buffer, y también se da el promedio del número de usuarios y el máximo número de usuarios
en una celda o cluster.
Cell UL/DL Traffic Volume. Estos KPIs nos proporcionan el volumen del tráfico de
subida y bajada que tiene una celda o cluster.
Cell UL Traffic Volume (MB) = [pmPdcpVolUlDrb]/(8*1000)
Cell DL Traffic Volume (MB) = ([pmPdcpVolDlDrb]+[pmPdcpVolDlDrbTransUm])/(8*1000)
Average Num Active Users UL/DL. Los KPIs evalúan el promedio del número de
usuarios activos con datos de UL/DL en una celda o cluster.
Avg Num Active Users UL = [pmActiveUeUlSum]/[pmSchedActivityCellUl]
Avg Num Active Users DL = =[pmActiveUeDlSum]/[pmSchedActivityCellDl]
133
Integridad (Integrity)
Como en la categoría de la tecnología 3G, en LTE se mide el Throughput UL y DL. Las fórmulas
vienen dadas por las expresiones:
UL Tput = [pmUeThpVolUl]/([pmUeThpTimeUl]/1000)
DL Tput = ([pmPdcpVolDlDrb]-[pmPdcpVolDlDrbLastTTI] +
[pmPdcpVolDlDrbTransUm])/([pmUeThpTimeDl]/1000)
Latencia (Latency)
Otra categoría de KPIs a tener en cuenta de cara a la optimización LTE es la que se enfoca en la
experiencia del usuario como Integrity; este grupo se llama latency. La latencia es el parámetro
que mide el tiempo – en los KPIs normalmente en ms – que tarda la información en ir desde el
terminal de usuario hasta su destino. En el caso de LTE, se observa una reducción importante
en el tiempo en que tarda la información en atravesar la red con respecto a 3G.
Downlink Latency. Este KPI mide el tiempo que tarda en descargar información desde
un servidor hasta el terminal móvil. La fórmula viene dada por:
DL Latency (ms) = [pmPdcpLatTimeDl]/[pmPdcpLatPktTransDl]
(14)
134
135
5. APLICACIÓN DE SOLUCIONES MEDIANTE EL USO DE
HERRAMIENTAS
Cuando se lleva a cabo un trabajo como el expuesto en este proyecto fin de carrera, el
implementador ha de prepararse tanto para el éxito de la ejecución en red como el fracaso
ante un problema con el que no se contaba. Por ello es de vital importancia, además de tener
listos los scripts y ficheros de los trabajos, preparar los necesarios en caso de necesitar dar
marcha atrás a alguna de las implementaciones, con el objetivo de dejar la red en el estado
inicial antes de la ejecución.
Pero este apartado se centra en materializar y explicar las soluciones que se han propuesto
para los clusters de Cuenca y Segovia, tanto la preparación de los scripts, ficheros y comandos
para cada caso como la implementación en las diferentes herramientas vistas en este
documento.
Implementación manual. Moshell/AMOS y Command Handling
Tanto para la reasignación de una frecuencia como para la asignación de una banda libre a una
tecnología, se deben definir una serie de elementos además de modificar algún que otro
parámetro para que el resultado del trabajo sea exitoso. A continuación se va a ver la llamada
implementación manual por comandos a través del software del OSS Moshell/AMOS – para la
definición en 3G y LTE – y de la tool de 2G CHA, para el refarming.
Refarming 2g a 3g
La reasignación de la frecuencia 900 Mhz de 2G a 3G se va a dividir en dos fases:
1) Aislar 2G de la banda de frecuencia 900 MHz.
2) Definir elementos y parametrización para asignar a 3G.
Para la primera parte, se utilizará Command Handling accediendo por la interfaz del OSS de
2G. En la segunda, únicamente definir elementos y establecer parametrización por comandos
a través de AMOS/Moshell.
Asilamiento 2g: bloqueo BTS
Solamente tenemos definida una frecuencia para 2G y el objetivo es ocupar la misma para la
tecnología 3G. Por ello, no se necesitan borrar frecuencias de las celdas, con bloquear las BTS
es suficiente para que no pase tráfico por 2G. Para hacer el bloqueo, se abre CHA y se conecta
a la BSC de la que cuelga el cluster de Cuenca, en este caso BSC110; las celdas a bloquear:
136
BTS Celda 2G
CU0010 CU00107
CU0010 CU00108
CU0010 CU00109
CU0011 CU00117
CU0011 CU00118
CU0011 CU00119
CU0012 CU00127
CU0012 CU00128
CU0012 CU00129
CU0013 CU00137
CU0013 CU00138
CU0013 CU00139
CU0014 CU00147
CU0014 CU00148
CU0014 CU00149
CU0015 CU00157
CU0015 CU00158
CU0015 CU00159 Tabla 17. Celdas 2G a apagar para liberar la frecuencia 900Mhz
Listado de comandos a ejecutar en la línea de comandos de CHA:
RLSTC:CELL=CU00107,STATE=HALTED;
RLSTC:CELL=CU00108,STATE=HALTED;
RLSTC:CELL=CU00109,STATE=HALTED;
RLSTC:CELL=CU00117,STATE=HALTED;
RLSTC:CELL=CU00118,STATE=HALTED;
RLSTC:CELL=CU00119,STATE=HALTED;
RLSTC:CELL=CU00127,STATE=HALTED;
RLSTC:CELL=CU00128,STATE=HALTED;
RLSTC:CELL=CU00129,STATE=HALTED;
RLSTC:CELL=CU00137,STATE=HALTED;
RLSTC:CELL=CU00138,STATE=HALTED;
RLSTC:CELL=CU00139,STATE=HALTED;
RLSTC:CELL=CU00147,STATE=HALTED;
RLSTC:CELL=CU00148,STATE=HALTED;
137
RLSTC:CELL=CU00149,STATE=HALTED;
RLSTC:CELL=CU00157,STATE=HALTED;
RLSTC:CELL=CU00158,STATE=HALTED;
RLSTC:CELL=CU00159,STATE=HALTED;
Una vez bloqueadas todas las celdas se comprueba que efectivamente, se ha hecho de manera
correcta:
RLSTP:CELL=CU00107;
RLSTP:CELL=CU00108;
RLSTP:CELL=CU00109;
RLSTP:CELL=CU00117;
RLSTP:CELL=CU00118;
RLSTP:CELL=CU00119;
RLSTP:CELL=CU00127;
RLSTP:CELL=CU00128;
RLSTP:CELL=CU00129;
RLSTP:CELL=CU00137;
RLSTP:CELL=CU00138;
RLSTP:CELL=CU00139;
RLSTP:CELL=CU00147;
RLSTP:CELL=CU00148;
RLSTP:CELL=CU00149;
RLSTP:CELL=CU00157;
RLSTP:CELL=CU00158;
RLSTP:CELL=CU00159;
Una vez bloqueadas todas las celdas del cluster de Cuenca, se procede a definir la frecuencia
en la RNC y posteriormente definir las celdas.
138
Definición celdas 3g para 900 MHz
Para la definición de las celdas 3g a nivel radio, se parte de la confirmación por parte del grupo
de ingenieros que se he definido a nivel de Core y RBS la parametrización correspondiente a la
integración de la nueva frecuencia.
Para la agregación de las nuevas celdas UMTS 900 en la RNC, se usará el nombre dado en la
integración de los sectores. A continuación, el cell name ID- en rojo - para cada una de ellas:
RBS Celda 3G Frecuencia 1
Celda 3G Frecuencia 2
B1CU0010
B1CU00101 UMTS 2100 B1CU00104 UMTS 900
B1CU00102 UMTS 2100 B1CU00105 UMTS 900
B1CU00103 UMTS 2100 B1CU00106 UMTS 900
B1CU0011
B1CU00111 UMTS 2100 B1CU00114 UMTS 900
B1CU00112 UMTS 2100 B1CU00115 UMTS 900
B1CU00113 UMTS 2100 B1CU00116 UMTS 900
B1CU0012
B1CU00121 UMTS 2100 B1CU00124 UMTS 900
B1CU00122 UMTS 2100 B1CU00125 UMTS 900
B1CU00123 UMTS 2100 B1CU00126 UMTS 900
B1CU0013
B1CU00131 UMTS 2100 B1CU00134 UMTS 900
B1CU00132 UMTS 2100 B1CU00135 UMTS 900
B1CU00133 UMTS 2100 B1CU00136 UMTS 900
B1CU0014
B1CU00141 UMTS 2100 B1CU00144 UMTS 900
B1CU00142 UMTS 2100 B1CU00145 UMTS 900
B1CU00143 UMTS 2100 B1CU00146 UMTS 900
B1CU0015
B1CU00151 UMTS 2100 B1CU00154 UMTS 900
B1CU00152 UMTS 2100 B1CU00155 UMTS 900
B1CU00153 UMTS 2100 B1CU00156 UMTS 900
Tabla 18. Nombres de las celdas definidas para la nueva frecuencia 900Mhz
Se da por hecho que el usuario que utilizará el implementador tiene permisos de modificación
sobre la red; si no es así, únicamente se podrían ejecutar comandos de consulta pero no
utilizar cualquier comando de modificación en atributos o MOs del NE.
Se accede a la RNC100CLM mediante AMOS:
139
Una vez dentro, definimos la frecuencia para el HO entre celdas de U900 en el cluster de
Cuenca. Primero se cargan todos los MOs para acceder al atributo y después se pide el listado
de la situación inicial:
Las frecuencias definidas en la RNC, incluidas las necesarias para HO entre otras RNCs (estas
bajo el MO Iurlink):
Los comandos para añadir la nueva banda de frecuencia para 900 MHz:
140
La situación final será:
Ya se pueden definir las celdas una vez añadida la frecuencia. Cuando se añade una nueva
utrancell en la RNC, se tienen que setear una serie de atributos necesarios para que la celda
pueda cursar tráfico; entre todos los que se solicitan (primarycpichpower,
maximumtransmissionpower, etc.) están los de frecuencia, uarfcndl y uarfcnul. A continuación,
una muestra de cómo se definen las celdas y los valores a incluir en los atributos de frecuencia:
Después de definir todas las celdas con los valores en sus atributos correspondientes, se
procede a añadir las vecinas; las relaciones han de ser bidireccionales para que el HO 3G-3G
sea exitoso. A continuación, las líneas a ejecutar para crear la relación entre el sector 1 y sector
2 de la nueva frecuencia 900Mhz en la RBS B1CU0010:
En la siguiente imagen se muestran las principales relaciones que se van a añadir nuevas en el
cluster de Cuenca para ganar tráfico 3G:
141
Figura 55. Representación de las principales relaciones de vecindad a definir entre celdas de la misma tecnología
Es de vital importancia añadir, al menos, las representadas en el mapa:
- Relaciones 3G-3G entre los sectores del mismo nodo.
- Relaciones 3G-3G entre sectores de la misma frecuencia.
Además de estas vecinas, para que el HO en 3G sea lo más efectivo posible se deben definir de
la misma manera las relaciones entre UMTS 2100 y UMTS 900. La forma de realizarlo es tal
como se ha explicado anteriormente, – mediante el comando cr en Moshell de manera
bidireccional – por lo que se invertirá gran cantidad de tiempo en agregar todas las relaciones.
Además de ser una tarea laboriosa definir toda la parametrización y elementos de red
mediante comandos, puede llevar a errores que se olvide añadir una celda o que se produzca
un error involuntario por parte del implementador. Por este motivo, para este tipo de trabajos
los ingenieros se encargan de diseñar una serie de scripts mobatch para agilizar el trabajo del
refarming.
Asignación frecuencia 800 Mhz a 4G
Para la asignación de la banda de frecuencia liberada por TDT 800 MHz en Segovia, la ejecución
del trabajo será más sencilla pues no son necesarios pasos previos ya que el propio eNodeB es
controlador de las tareas que desempeña.
El procedimiento que se detallará a continuación se tiene que realizar sobre todos los nodos
del cluster de Segovia. En este caso, se utilizará el nodo L1SG4401 como punto de partida
donde se definirán todos los parámetros y elementos de cara a la asignación de la nueva
frecuencia a 4G.
142
Se accede a través de moshell/AMOS al eNodeB:
Se cargan todos los MOs para poder operar con cualquier atributo y no tener restricciones en
las definiciones de celdas. El comando es lt all.
Se definen las nuevas celdas de la frecuencia LTE 800. Para ello, se ejecutará el comando cr y
durante la creación se solicitarán una serie de atributos necesarios para que la celda comience
a cursar tráfico (PCI, tac, etc.); entre estos parámetros, se encuentran los de frecuencia ul y dl.
En el nodo LTE se repetirá el mismo procedimiento para los otros sectores de LTE 800:
143
Se deben setear también los siguientes atributos para que la celda de la nueva frecuencia
quede correctamente definida:
Este procedimiento se debe hacer de la misma forma para el resto de nodos del cluster de
Segovia. En la siguiente tabla, las futuras celdas de LTE 800 en Segovia a definir:
ERBS Celda 4G Frecuencia 1 Celdas 4G Frecuencia 2
L1SG4401
L1SG4401A LTE 1800 L1SG4401D LTE 800
L1SG4401B LTE 1800 L1SG4401E LTE 800
L1SG4401C LTE 1800 L1SG4401F LTE 800
L1SG4402
L1SG4402A LTE 1800 L1SG4402D LTE 800
L1SG4402B LTE 1800 L1SG4402E LTE 800
L1SG4402C LTE 1800 L1SG4402F LTE 800
L1SG4403
L1SG4403A LTE 1800 L1SG4403D LTE 800
L1SG4403B LTE 1800 L1SG4403E LTE 800
L1SG4403C LTE 1800 L1SG4403F LTE 800
L1SG4404
L1SG4404A LTE 1800 L1SG4404D LTE 800
L1SG4404B LTE 1800 L1SG4404E LTE 800
L1SG4404C LTE 1800 L1SG4404F LTE 800 Tabla 19. Nombres de las celdas definidas para la nueva frecuencia 800Mhz
Una vez definidas todas las celdas en las ERBS, se procede a crear las vecinas más importantes
de cara a poder hacer HO 4G-4G (Intra-Freq) entre celdas. Además de añadir las relaciones,
hay que asegurarse que la funcionalidad para habilitar HO está activada en la ERBS:
featureStateIntraLTEHandover= ACTIVATED
Las relaciones a definir en el cluster de Segovia se pueden ver a continuación en el mapa. Las
que están en rojo son las que se definen entre sectores de la misma ERBS y las verdes son
vecinas con celdas de otros nodos; hay que añadirlas bidireccionales para el éxito de HO.
144
Figura 56. Representación de las principales relaciones de vecindad a definir entre celdas de la misma tecnología
Recordar que se deben definir igualmente las relaciones entre diferentes frecuencias, además
de establecer correctamente la potencia de los sectores que apuntan a los municipios con
problemas de cobertura, Perogordo y San Cristóbal de Segovia.
En el caso de la asignación de LTE 800 a los 4 nodos de Segovia no supone un gasto extra de
tiempo en la implementación del trabajo en sí, pero ésta operativa se hará difícil en cuanto el
número de nodos a agregar una nueva frecuencia sea alto. Por este motivo, es frecuente que
en la fase de preparación del trabajo se definan por parte del implementador una serie de
scripts para agilizar la carga de vecinas y de parametrización.
Posibles recursos para optimizar la implementación manual. Scripts.
En todo trabajo por comando, ya sea un refarming, asignación de frecuencia o un cambio
masivo de atributos, el tiempo jugará en contra cuanto mayor sea el volumen de
modificaciones en los NEs de la red. Es de gran importancia que en la ventana de tiempo que
se abre para los trabajos no se excedan de unas horas durante la noche (cuando el tráfico es
menor y el impacto será menos agresivo sobre la red).
En muchas ocasiones, para minimizar el tiempo de parada – la mencionada ventana – del resto
de trabajos programados por otros grupos, se definen una serie de alternativas que reducen la
implicación del implementador sobre el elemento o elementos de red. Es decir, no tendrá que
entrar elemento por elemento y definir las celdas, frecuencias, parametrización por comando;
145
previamente se crea uno o varios script para, si es posible, incluso programarlos y lanzarlos
automáticamente a la RNC o nodo.
El programarlos dependerá de la importancia y los impactos previstos en red del trabajo. Para
las tareas de refarming y asignación de frecuencias es aconsejable que los scripts sean
lanzados manualmente por el implementador y este supervise la ejecución hasta la
finalización. Además, deberá chequear los logs que genere como salida cada uno de los scripts.
Refarming 2G
Para el refarming habrá que crear varios scripts/ficheros:
- 1 fichero para bloquear el 2G que se lance a través de CHA.
- 1 script para definir frecuencia en la RNC y las celdas U900.
- 1 script para definir las nuevas relaciones de vecindad.
Se podrían compactar los scripts, pero es aconsejable cerciorarse que toda la parametrización
de frecuencia y celdas se define correctamente antes de añadir las relaciones.
Sobre el trabajo del equipo de integración a nivel de Core y RBS, se entenderá que se están
utilizando en todo momento todas las herramientas y procedimientos que minimicen los
tiempos y errores. A tener en cuenta que, como se comentó anteriormente, es posible que se
tenga que trabajar en local para modificar manualmente por un técnico de campo la
inclinación del sector, por ejemplo.
La creación del fichero del bloqueo de las celdas 2G es sencillo: únicamente es necesario un
bloc de notas o editor de texto, se incluyen los comandos a ejecutar uno por línea y se guarda
el archivo como texto:
Figura 57. Estructura fichero .txt para bloquear la tecnología 2G
146
Se sube el fichero al OSS de 2G, en una carpeta habilitada para CHA:
/user_oss/vendor/cha/files/. Este fichero será el primero en ejecutarse y se cargará desde el
menú de CHA; el resultado saldrá en pantalla y se puede comprobar si ha fallado algún
comando – FAULT CODE XX– o por el contrario se ha ejecutado exitosamente.
Para la creación de los scripts será necesario el conocimiento, por parte del implementador, de
comandos Linux y del lenguaje shell.
Los scripts pueden ser definidos de infinitas formas, a continuación lo que se presenta es un
código de ejemplo partiendo de dos ficheros .txt en los que se añade, en uno de ellos la RNC a
consultar y en el otro las celdas a definir, así como los parámetros necesarios para añadir las
nuevas celdas a la RNC. El formato a seguir en los ficheros:
Fichero_Changes.txt
RNC100CLM:
Fichero_celdas.txt
Cellname:param1:param2:..:3025:2800:…:paramN
Cellname:param1:param2:..:3025:2800:…:paramN
Cellname:param1:param2:..:3025:2800:…:paramN
…
En el fichero que incluye las celdas a definir en la RNC de Cuenca hay que conocer,
previamente el orden en el que se solicitan los atributos para setear los correspondientes. Si
por alguna razón se desconoce el valor a incluir, se puede dejar vacía la separación entre :: y
posteriormente definirlo.
A continuación, dos imágenes donde se visualiza el código implementado para ejecutar lo que
se hacía manualmente; se crea un fichero de salida y además información que se visualizará
por pantalla durante la ejecución del script. Esto script se guardan con extensión .sh.
147
Figura 58. Ejemplo de código para el script de definición de nuevas celdas
En la siguiente captura, en la parte final del código, se observa que se comprime el resultado
de la ejecución y se envía a una carpeta de salida pero dejar el trabajo registrado en red.
Figura 59. Final del ejemplo de código del script para la definición de nuevas celdas
El script de las vecinas será similar, pero esta vez se cambia el fichero de celdas por el siguiente
formato:
Cellname1_origen:cellname2_destino:
Cellname2_origen:cellname1_destino:
Cellname1_origen:cellname3_destino:
Cellname3_origen:cellname1_destino:
…
En cuanto a la implementación del script, muy similar al visto:
148
Figura 60. Ejemplo de script para la creación de vecindades en las nuevas celdas definidas
Figura 61. Final del código para la definición de nuevas relaciones en las nuevas celdas
Nueva frecuencia 4G
En el caso de asignación de una nueva frecuencia que no está ocupada, basta con un script con
las celdas definidas y los atributos que se necesitan tener activos y correctamente
parametrizados. Se supone que ya están integradas en la ERBS pero no parametrizadas, es
decir, definidas a nivel radio.
El fichero que se le dará al script para que lea datos tendrá un formato similar al siguiente:
ERBSName: ECellname1:param1: param2:..:24240:6240:..:paramN
ERBSName: ECellname2:param1:param2:..:24240:6240:..:paramN
…
149
Una parte del código del script .sh para definir las celdas en la ERBS:
Figura 62. Extracto del código del script a utilizar para definir las nuevas celdas 4G
Para añadir las vecinas, el formato de datos de entrada (.txt) sería muy similar al visto en 3G.
Este tipo de soluciones son algo complejas, pues requieren a un ingeniero que sea capaz de
preparar estos scripts en Unix además de no tener un pre-check de posibles inconsistencias en
la red al poner operativas las frecuencias. En el siguiente capítulo se abordará esta
problemática y habrá una presentación de las herramientas en las que se pueden apoyar para
evitar este tipo de problemáticas. (15)
Implementación automática mediante archivos xml. Common Explorer (CEX)
Se han visto en detalle los diferentes procesos de implementación de las frecuencias UMTS
900 y LTE 800 en la red móvil, tanto manuales como con ayuda de scripts para reducir los
tiempos de ejecución. Pero no se ha tenido en cuenta un estudio previo sobre el posible
impacto de la ejecución de los trabajos; en el OSS existen una serie de herramientas que,
además de reducir el tiempo más aún permiten visualizar las posibles inconsistencias o errores
si se deciden implementar todos los cambios.
Para la red de 2G es fundamental CNA, pues te hace un test de inconsistencias antes de aplicar
los cambios en red y si este detecta errores, bloquea la ejecución de estos cambios.
En 3G y 4G, la herramienta que nos aportará ese estudio previo y la reducción del tiempo de
ejecución será CEX, de la que ya se ha hablado en este proyecto fin de carrera. Para cargar los
datos en CEX se necesitarán unos ficheros XML adaptados, según lo que se quiera modificar.
150
Refarming 2g a 3g. CEX
Para la implementación y puesta en funcionamiento de la nueva frecuencia en la red 3G, se
proporcionarán ficheros XML con la información necesaria para llevar a cabo el trabajo. Estos
ficheros XML tienen un formato acorde al vendor que trabaja con el operador y que provisiona
el mantenimiento de la red, y deben cumplir una serie de requisitos para que CEX los acepte.
Para el cluster de Cuenca, después de la fase de integración de la nueva frecuencia en cada
uno de los nodos, se definirán las nuevas celdas en la RNC y las vecinas necesarias para que
mejore el área de cobertura en los municipios de Nohales y La Melgosa.
Se definirá en total 1 fichero XML para definir las utranrelation, si en la fase de integración se
han definido los elementos por CEX, no será necesario volver a definirlo en la RNC pues la base
de datos de CEX ya ha sido sincronizada con lo que hay en red (y por tanto, se ha definido
automáticamente las celdas).
Lo que sí que se recomienda es definir un XML de actualización de atributos, donde pueden
añadirse los relacionados con la frecuencia:
Tabla 20. Atributos de Utrancell
151
Para la definición de las vecinas, podemos tomar el siguiente formato válido en CEX:
Figura 63. Extracto del fichero xml para la creación de vecinas (10)
Se cargará en CEX primero el fichero de actualización de los atributos donde se incluirán todas
las celdas y los parámetros a modificar y, una vez comprobado que la creación se ha realizado
correctamente se procede a crear una nueva Planned Area para cargar las nuevas vecinas.
En la pestaña PCA se crearán las Planned Area para cada uno de los ficheros XML y si la
importación no genera ninguna inconsistencia, se procede a cargar en la base de datos de CEX
la nueva parametrización. OSS se encargará automáticamente de sincronizar lo que hay en su
base de datos con lo que está en red definido y así se limpiarán todas las posibles
inconsistencias.
152
Figura 64. Vista de CEX donde se crean las planned área para definir las nuevas vecinas
Asignación LTE 800 con CEX. Funcionalidad ANR
Al igual que para Cuenca se pudo reducir tiempos de ejecución y se aportó un pre-check para
hacer más fiable el trabajo de refarming, en la integración de LTE 800 ocurre algo similar.
La optimización en LTE es mínima, y gran parte del mantenimiento de la red se consigue con la
activación de funcionalidades, dando así a la red una gran autonomía frente a otras
tecnologías como 3G y 2G. Para aprovechar esta ventaja frente a las antecesoras, además de
utilizar CEX para la definición de las nuevas celdas, se tendrá en cuenta una funcionalidad que
genera automáticamente las relaciones de vecindad en función de las necesidades de la red; la
feature de la que se habla es ANR (Automatic Neighbour Relation). (16)
Dado que ANR va añadiendo las celdas vecinas que el teléfono detecta, hay que tener cuidado
con el límite de vecinas – es de 64 en LTE – y, ya en el grupo de optimización, hacer un
chequeo y ajuste periódico para eliminar las relaciones que no son necesarias.
Por tanto, en esta fase de puesta en funcionamiento de LTE 800, se realizarán los siguientes
pasos:
1. Activación AMR en las ERBS.
2. Actualización EUtranCellFDD por medio de CEX.
153
3. Creación de vecinas LTE-LTE, LTE-3G.
Semanalmente se realizará un chequeo de las vecinas para eliminar las que no sean necesarias
y crear las que sean útiles para cubrir zonas con baja cobertura.
Los ficheros xml se cargarán en una Planned Area previamente definida en la vista PCA y, una
vez se importe se irá viendo el resultado del chequeo previo en la vista Bulk CM Progress:
Figura 65. En Bulk CM Progress aparecerán todas las Planned Area que se han importado
154
155
6. RESULTADOS
Ya se decida realizar la implementación de manera manual o bien apoyándose en las
diferentes herramientas y scripts para reducir tiempos y minimizar errores en la fase de
ejecución, finalmente los clusters analizados tendrán nuevas frecuencias para mejorar la
calidad de las llamadas en las zonas pobres de cobertura.
En Cuenca, el refarming de 2g a 3g ampliará la huella de cobertura de los nodos más próximos
a los municipios rurales, reduciendo el porcentaje de llamadas caídas y mejorando los KPIs
principales de accesibilidad, movilidad, entre otros.
Para el cluster de Segovia el objetivo es similar, pues el tráfico en 4G era muy bajo pese a
existir en la zona usuarios con smartphones para LTE y, después de desplegar la nueva banda
han aumentado los kilómetros de llegada en cuanto a cobertura, disminuyendo las quejas de
cliente en ambos municipios. Al estar activa la funcionalidad ANR en los nodos, el trabajo de
los optimizadores se centra en mantener relaciones de vecindad útiles, que abarquen una
cantidad suficiente de tráfico para no descartarla en los chequeos periódicos.
156
157
7. CONCLUSIONES Y RECOMENDACIONES
Cuando un operador decide apostar por un despliegue en el SW y no en equipamiento está
clara la estrategia de minimizar en la medida de lo posible, el gasto económico que conlleva
evolucionar la red a lo que el mercado demanda.
Pero antes de centrar los esfuerzos en añadir una nueva frecuencia o reasignar una que estaba
destinada a otra tecnología, se debe hacer un estudio previo de la zona para visualizar lo que
realmente va a salir rentable a corto y largo plazo. Se han analizado poblaciones rurales, donde
los usuarios posiblemente carezcan de teléfonos inteligentes que requieran lo último del
mercado, pero sin embargo la integración de nuevos emplazamientos es un coste mucho
mayor y que a largo plazo quedaría obsoleto, forzando así al operador a utilizar una nueva
banda. La implantación de 5G prevista en 2019 obligará a muchos cambios de HW, por lo que
desembolsar presupuestos en ello a día de hoy implicaría una pérdida económica para los
operadores innecesaria.
Por tanto, el despliegue de UMTS 900 MHz es positivo al llegar a zonas como Nohales y La
Melgosa, aportando mayor calidad en llamadas y de cara a una futura nueva tecnología no ha
supuesto un desembolso importante para el operador.
Lo mismo ocurre con Segovia; la necesidad de mejorar la red 4G ha visto la oportunidad en
2015 al liberar la banda de 800 MHz y así potenciar las características de LTE en frecuencias
bajas. Ha sido una estrategia acertada por parte del operador para mejorar QoS ya no solo en
los municipios colindantes, si no en la propia ciudad que está provista de pocos nodos para el
núcleo poblacional que es Segovia.
En resumidas cuentas, este tipo de implementaciones son necesarias y muy importantes de
cara a mantener unos compromisos de QoS con los usuarios y que la red no quede obsoleta en
relación al avance tecnológico de los smartphones, así como mantener la competencia con el
resto de operadores del país.
Se recomienda también que, aunque estos trabajos aportan beneficios, se haga previamente
un estudio demográfico y de necesidades en las zonas donde se van a desplegar las nuevas
frecuencias.
Sobre los métodos de implementación de las nuevas frecuencias, se debe siempre apostar por
la automatización de todos los procesos en la medida de lo posible, pues se reducen los
tiempos de ejecución y lo más importante, se puede realizar un chequeo previo sobre si los
cambios que se llevarán a cabo van a impactar de manera negativa a la red.
Gracias al avance del OSS, cada vez hay más herramientas de estudio, gestión y
mantenimiento que ahorrarán mucho trabajo manual a los implementadores haciendo más
independiente la red de los trabajos de optimización necesarios para mantener la calidad. Y
esta evolución no para, pues ya hay estudios para sustituir OSS por bases de datos más
potentes y autómatas.
158
159
8. BIBLIOGRAFÍA
1. Banda Ancha. [En línea] 18 de abril de 2014. https://wiki.bandaancha.st/Refarming.
2. Huidobro, Jose Manuel. El Refarming del espectro. [En línea] 22 de Octubre de 2014.
http://www.zonamovilidad.es/noticia/1139/reportajes/el-refarming-del-espectro.html.
3. González, Tomás, Ortiz, Bolivar y Bonilla, Carlos. Redes UMTS. [En línea] 2013.
https://ehumir.files.wordpress.com/2013/04/articulo-redes-umts.pdf.
4. Tecnología HSDPA/W-CDMA (3.5G). Evaluación de la transferencia de datos de audio/Video.
[En línea] . https://ehumir.files.wordpress.com/2013/04/articulo-redes-umts.pdf.
5. Patrón, David Fajardo. Introducción a WCDMA. Simulación de tramas WCDMA.
6. Sesia, Stefania, Toufik, Issam y Backer, Matthew. LTE: The UMTS Long Term Evolution. From
theory to practice.
7. Ericsson. Guías internas de Ericsson.
8. —. CEX, OSS Common Explorer, User Guide.
9. Manual de procedimientos de gestión y operación para RBSs y BSC Ericsson. [En línea] 2007.
http://myslide.es/documents/manual-de-gestion-y-comandos-gsm.html.
10. Agrawal, Mohit. Spectrum refarming: Roll-out 3G services on 2G spectrum . [En línea]
Diciembre de 2009. http://www.telecomcircle.com/2009/12/spectrum-refarming/.
11. Calculadora de frecuencias. [En línea] . http://niviuk.free.fr/lte_band.php.
12. Team, Telefónica IoT. Telefonica Business Solutions (IoT). [En línea] 30 de marzo de 2016.
https://iot.telefonica.com/blog/moldeando-el-iot-refarming-de-2g-que-significa.
13. Frecuencias y bandas en España. [En línea]
https://wiki.bandaancha.st/Frecuencias_y_bandas_LTE_en_Espa%C3%B1a.
14. LTE (Long Term Evolution): El siguiente nivel. España, dpto de instrumentación Rohde &
Schwarz. Octubre de 2010.
15. Ericsson. Taller de optimización radio 3g avanzada. 2011.
16. Sharawi, Mohammad S. Chapter 11: RF Planning and Optimization for LTE Networks.
Evolved Cellular Network Planning and Optimization.
17. 3GPP TS 32.615 V9.1.0 Technical Specification. [En línea] Junio de 2010.
ftp://www.3gpp.org/tsg_sa/WG5_TM/TSGS5_71/_specs_for_checking/32615-910.doc.
18. 3GPP TS 32.642 V4.5.0. 3rd Generation Partnership Project. [En línea] 03 de 2005.
http://www.qtc.jp/3GPP/Specs/32642-450.pdf.
160
19. Huawei. eRAN ANR Management. Feature Parameter Description. [En línea] 2010.
https://es.scribd.com/document/138647750/ANR-Management-Feature-Parameter-
Description-eRAN2-0-01.
i1G es la abreviación de la telefonía móvil de la primera generación, 1979. ii modelo KL-1 fue patentado el 11 de enero de 1957 con el Certificado de Patente № 115494. iii También llamada generación analógica. iv También llamada generación digital. v Short Message Service, abv. SMS. vi TDMA es conocido también como TIA/EIA136 o ANSI-136)