Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
TÍTULO: Optimización Radio de las tecnologías UMTS y LTE Advanced mediante herramientas de
gestión de la Red
VOCAL:
VOCAL SECRETARIO: ANTONIO DASILVA FARIÑA
DIRECTOR:
Fecha de lectura:
Calificación: El Secretario,
A raíz del avance tecnológico de las redes y los dispositivos móviles, surge la necesidad desde el
operador de ofrecer a los usuarios la mejor calidad de servicio, para que así puedan ver satisfechas todas
sus 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 Common
Explorer (CEX), Command Handling (CH) y MOshell, definiendo una estrategia de actuación sobre un
caso real. Asimismo, se extrapolará el caso al análisis de una red LTE para comprobar si sería viable o no
el estudio realizado para 3G.
2
4
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.
GRACIAS
5
6
RESUMEN
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.
7
8
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.
9
10
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
11
12
INDICE DE FIGURAS Y TABLAS
13
14
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
15
16
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.
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.
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.
17
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.
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
18
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.
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.
19
utilización de las tools proporcionadas por los proveedores a los operadores y las ventajas de
este tipo de prácticas. (1) (2)
20
2. MARCO REFERENCIAL
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.
21
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:
22
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.
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
23
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.
24
Sistema UMTS: Evolución y características
25
Figura 3. Elementos arquitectura red UMTS
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:
26
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:
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.
27
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.
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).
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.
28
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)
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.
29
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.
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:
17TD-SCDMA, Time Division –Synchronous Code Division Multiple Access (Acceso múltiple por división
de código síncrono de división de tiempo).
30
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.
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.
Infraestructura de LTE
31
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:
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:
Arquitectura LTE
32
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).
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)
33
34
3. PROCEDIMIENTO
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.
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:
35
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.
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:
36
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.
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
37
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.
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
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.
38
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).
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)
39
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.
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.)
40
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.
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:
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.
41
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:
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.
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.
42
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.
43
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:
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.
44
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:
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:
/home/nombreusuario/moshell/sitefiles/ipdatabase
45
El cliente O&M20 puede acceder a las MOs a través de una serie de servicios citados a
continuación:
Comandos Moshell/AMOS
46
pmom[ac]/lmo Muestra la descripción de los contadores PM (pmom) o los
m[c] atributos de log
PM
pget/lpget Lee atributo/s PM del MO
commands
hpget[c]/lhpge Lee atributo/s PM del MO. Muestra horizontalmente una línea
t[c] por MO
0 Instalación, seguridad y configuración de usuarios
Help 1 Historial de revisiones
chapters 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:
***************************************************************************
***************************************************************************
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:
47
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.
48
A continuación, un par de ejemplos de expresiones regulares utilizando el comando pr/lpr:
Comando st/lst
**********************************************************************
**********************************************************************
49
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
***********************************************************************
***********************************************************************
Si lanzamos str con los siguientes filtros, mostrará el estado de las celdas solamente en el
módulo 3:
50
Comando get/lget
Este comando devolverá el valor de uno o varios atributos para uno o varios MOs. La sintaxis
del comando:
***************************************************************************
***************************************************************************
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:
51
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:
****************************************************************************
****************************************************************************
21MCOM, 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.
52
Para cambiar atributos de tipo Struct, usar:
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:
Una vez se ha confirmado que si es restringido, podemos utilizar rset para modificar su valor
en la celda deseada:
53
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 <moGroup>|<moFilter>|<proxy(s)>
*****************************************************************
54
A continuación, una serie de ejemplos “jugando” con las diferentes opciones:
Comando Explicación
bl aal2.*ca[246] Bloquear aal2paths ca2, ca4, ca6
Bloquear todos los Mos del emplazamiento USMSNE08 (celdas, canales de
lbl USMSNE08 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
Primero lanzamos bls para el handover del tráfico hacia otros recursos
55
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>
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
56
ReservedBy, es posible utilizar en su lugar el comando rdel/lrdel. La sintaxis del
comando es:
del/ldel <moGroup>|<moFilter>|<proxy(s)>
- 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:
Ejemplo:
57
Comando u+/u-
-del/ldel
-rdel/lrdel
-bl/lbl
-deb/ldeb
-set
Ejemplos de uso:
58
Modo de deshacer simulado para la generación de script:
59
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:
**********************************************************************
**********************************************************************
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.
60
Comando run
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.
61
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.
62
Comandos PM
En la siguiente tabla una presentación de los principales comandos PM para Moshell. Algunos
no están disponibles en AMOS.
***********************************************************************
***********************************************************************
Ejemplo:
63
emom. Muestra el listado de eventos disponibles para cada tipo de escáner basado en
eventos. Sintaxis del comando:
***********************************************************************
***********************************************************************
Ejemplo:
64
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:
***********************************************************************
***********************************************************************
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).
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:
65
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:
**********************************************************************
**********************************************************************
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:
66
- 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:
67
pst. Lista todos los escáneres PM y su estado. La sintaxis del comando:
**********************************************************************
**********************************************************************
Ejemplo:
Otra opción es listar únicamente los escáneres que están activos con pst .act:
68
A continuación, más comandos importantes de PM que no están disponibles en la versión
AMOS:
***********************************************************************
***********************************************************************
Ejemplo de uso:
Ejemplo:
69
pdeb. Reanuda un escáner. Sintaxis del comando: pdeb <scan-filter>|<scan-proxy>
70
pset. Este comando modifica los contenidos de escáner basado en eventos (solo
RNC/RBS/LTE). Su sintaxis: pset[d]
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.
71
Comando de descripción de HW/SW: inv
Únicamente con ejecutar el comando inv podemos ver un detalle del HW/SW de la RNC:
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:
72
Ejecutando bp (de cada grupo de tablas, nos indica el número de ellas que hay):
Comando que muestra diversas salidas por pantalla COLI relacionadas con hw, sw, restarts,
leds, cpu load, errors, uso de disco/ram. Sintaxis:
***************************************************************************
***************************************************************************
73
- 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
74
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):
75
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.
(5)
76
Aprendizaje herramienta OSS Common Explorer (CEX)
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).
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.
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
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.
77
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.
78
Navegando en 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.
79
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.
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.
80
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.
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
- Buscar
- Exportar. Exportar el contenido seleccionado.
- Preferencias
- Ordenar. Organizar la vista de contenidos en orden ascendente o descendente.
Para ver los MOs contenidos bajo un NE hay que realizar los siguientes pasos:
81
La vista de explorador de MOs muestra la información del MO del NE. Esta información
puede visualizarse de dos formas:
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.
82
Figura 16. Vista explorador de MO mostrando menú alternativo de creación/edición de MOs.
Vista de propiedades
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
83
editadas en una planned, el icono en la vista activa se actualiza para mostrar un símbolo de
lápiz para indicarlo.
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:
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.
84
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
85
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.
Para buscar una propiedad particular en la vista de propiedades, se siguen los pasos indicados
a continuación:
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.
86
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
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.
87
Vista de comparar MO
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
Acciones
Se puede utilizar la función Export para exportar el contenido de esta vista a un fichero.
88
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.
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.
89
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.
90
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.
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.
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:
91
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.
92
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.
Vista de progreso
93
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.
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.
94
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
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 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.
95
Figura 32. Vista Bulk CM Progress de CEX
Tipo de inconsistencia.
Identidad de tráfico
FDN: El nombre distinguido completo de la MO que la inconsistencia encontraría.
96
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
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.
97
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
98
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 de relaciones
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
99
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:
100
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.
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:
101
Trabajando con Workspaces
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:
102
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:
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.
103
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:
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.
104
- 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.
Cada uno de los protocolos antes mencionados requiere un controlador de acceso externo,
External Access Handler (EAH).
Descripción funcional
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
105
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.
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
106
sucesivas respuestas pueden ser encaminadas hacia un fichero (se detalla en el apartado
“Manejo de archivos de comandos”).
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:
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.
- Comandos MML
- Comandos Ap
107
- Líneas en blanco
- Comentarios
- Comandos FIOL
- Ventana
- Fichero
- Impresora
- Correo
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.
Las siguientes primitivas de script CFH para sistema de archivos son proporcionadas por CHA:
108
Manejo de comandos peligrosos
109
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.
Capacidad
CHA puede manejar largas cadenas de salida, es posible navegar a través de al menos 1024
líneas.
Seguridad
(6) (9)
110
ESCENARIO REAL
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
111
Distancia más corta de estas áreas rurales con respecto a la ciudad de Cuenca:
Cuenca-Nohales = 3,88 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:
112
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.
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.
113
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
114
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.
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
115
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:
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,
116
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
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.
117
B1SG44023 UMTS 2100 SG44029 GSM 1800 SG4402Z GSM 900 L1SG4402C LTE 1800
B1SG44031 UMTS 2100 SG44037 GSM 1800 SG4403X GSM 900 L1SG4403A LTE 1800
B1SG4403 B1SG44032 UMTS 2100 SG44038 GSM 1800 SG4403Y GSM 900 L1SG4403B LTE 1800
B1SG44033 UMTS 2100 SG44039 GSM 1800 SG4403Z GSM 900 L1SG4403C LTE 1800
B1SG44041 UMTS 2100 SG44047 GSM 1800 SG4404X GSM 900 L1SG4404A LTE 1800
B1SG4404 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
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.
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
118
- 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.
119
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:
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:
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:
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)
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.
120
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.
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:
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)
121
122
4. OPTIMIZACION DE REDES 3G/LTE
No hay que olvidar que el objetivo es alcanzar los requerimientos establecidos con el cliente,
basándose en los siguientes aspectos:
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.
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.
123
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:
124
Cell_availability_total (%) = 100 - (100 * (pmCellDowntimeAuto + pmCellDowntimeMan) / (data_coverage * 60))
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).
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:
125
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:
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:
126
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.
127
Figura 53. Representación gráfica de los tipos de Handover Intra-freq entre dos celdas
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:
128
Integridad (Integrity)
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:
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:
(9)
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:
129
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.
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.
Disponibilidad (Availability)
130
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 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):
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.
[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.
Movilidad (Mobility)
131
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-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.
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.
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.
132
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:
(14)
133
134
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.
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
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.
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:
135
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
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;
136
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.
137
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:
Frecuencia Frecuencia
RBS Celda 3G Celda 3G
1 2
B1CU00101 UMTS 2100 B1CU00104 UMTS 900
B1CU0010 B1CU00102 UMTS 2100 B1CU00105 UMTS 900
B1CU00103 UMTS 2100 B1CU00106 UMTS 900
B1CU00111 UMTS 2100 B1CU00114 UMTS 900
B1CU0011 B1CU00112 UMTS 2100 B1CU00115 UMTS 900
B1CU00113 UMTS 2100 B1CU00116 UMTS 900
B1CU00121 UMTS 2100 B1CU00124 UMTS 900
B1CU0012 B1CU00122 UMTS 2100 B1CU00125 UMTS 900
B1CU00123 UMTS 2100 B1CU00126 UMTS 900
B1CU00131 UMTS 2100 B1CU00134 UMTS 900
B1CU0013 B1CU00132 UMTS 2100 B1CU00135 UMTS 900
B1CU00133 UMTS 2100 B1CU00136 UMTS 900
B1CU00141 UMTS 2100 B1CU00144 UMTS 900
B1CU0014 B1CU00142 UMTS 2100 B1CU00145 UMTS 900
B1CU00143 UMTS 2100 B1CU00146 UMTS 900
B1CU00151 UMTS 2100 B1CU00154 UMTS 900
B1CU0015 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.
138
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:
139
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:
140
Figura 55. Representación de las principales relaciones de vecindad a definir entre celdas de la misma tecnología
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.
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.
141
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:
142
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:
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.
143
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.
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;
144
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
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:
145
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.
146
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:
147
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: ECellname2:param1:param2:..:24240:6240:..:paramN
148
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)
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.
149
Refarming 2g a 3g. CEX
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).
150
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.
151
Figura 64. Vista de CEX donde se crean las planned área para definir las nuevas vecinas
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:
152
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
153
154
6. RESULTADOS
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.
155
156
7. CONCLUSIONES Y RECOMENDACIONES
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.
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.
157
158
8. BIBLIOGRAFÍA
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.
6. Sesia, Stefania, Toufik, Issam y Backer, Matthew. LTE: The UMTS Long Term Evolution. From
theory to practice.
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/.
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.
14. LTE (Long Term Evolution): El siguiente nivel. España, dpto de instrumentación Rohde &
Schwarz. Octubre de 2010.
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.
159
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.
160