El proyecto tuvo como objetivo modernizar la red 2G/3G de Orange Spain mediante el reemplazo de equipos antiguos por nuevos equipos Ericsson entre enero de 2012 y diciembre de 2013. Se realizaron swaps en los emplazamientos existentes y nuevos despliegues para mejorar la cobertura y capacidad. Sin embargo, el proyecto se retrasó hasta diciembre de 2013 debido a problemas como retrasos en los swaps de transmisión IP, sitios tardíos, paros por calidad y problemas de instalación, lo que result

2. • DEGRADACIÓN/PÉR
DIDA DE SERVICIO
• MODERNIZACIÓN
HW/SW
• AUMENTAR LA
CAPACIDAD DE LA
RED
• RENOVAR LA RED EN
SERVICIO
NECESIDADES OBJETIVOS
RIESGOSSOLUCIONES

3.  El objetivo del proyecto Ran Renewal es la modernización de la
red 2G/3G de OSP(Orange Spain).
 Enero de 2012 hasta Diciembre de 2013.
 Ericsson debe encargarse de principio a fin de todas las tareas.
(Proyecto LLEM)
 La red existente de Orange se modifica de dos formas:
 Swap:Los emplazamientos existentes son reutilizados,
reemplazándose los equipos antiguos, por nuevos equipos
2G/3G Ericsson (RBS6000).
 Despliegue: nuevo emplazamientos para mejorar la cobertura y
aumentar la capacidad.

4.  Estrategia de swap seguida
por Ericsson es la siguiente:
 Swapear a nivel de clúster.
 48 horas de monitorización
para dar marcha atrás, si
existe degradación y volver
a poner el equipo antiguo
(fallback).

5.  OSP controla la calidad
a través de las quejas
de clientes que
reclamará a Ericsson.
 Ericsson debe
adelantarse y contrata
este servicio que tiene
como objetivo que la
red no se degrade tras
la puesta en servicio
del nodo.

6. 1) Comprobación de
alarmas y
configuración:
 Detección fallos de
hardware o instalación.
 STZ.
 Trouble Ticket (TT) para
resolución en remoto
 Work Order (WO) para
resolución en local.

7. 2) Consistency Check:
 Auditoría de parámetros
e inconsistencias en la
fase de configuración
que puede afectar su
rendimiento.
 Para cambios en la red
se crea un CR (Change
Request)
 Se modifica através de
OSS (Operational Support
System Radio & Core).

8. 3) Auditoría de vecinas:
 Se comprueban cosites .
 Mismas vecinas que antes del swap.
 Si faltan vecinas, crear un CR.
 Límite SIB11 en UMTS.
4) Reporte 48h:
 Seguimiento de swaps realizados.
 Incluye kpis diarios y de referencia.
 Comprobar condiciones de aceptación (baseline)
durante 48h.

9. 5) Drive test light:
 Equipo de DT realiza
medidas de verificación de
cada emplazamiento.
 Tems 13 durante 45 minutos
 Documento con plots
(mapas):
 Mejor servidora
 Ec/No y/o RxQual
 RSCP y/o RxLEV

10.  El objetivo de la fase de IT es la aceptación
a nivel de nodo.
 Los umbrales de aceptación son:
 DCR CS & PS: 2 x DCR de referencia < 3%.
 CSSR CS & PS: 4 x tasa de bloqueo de la
referencia < 90%.
 RSSI > -90 dBm.
 Disponibilidad de celda > 95%.
 Tasa de éxito de HO > 95%.

11.  Condiciones de repliegue (FallBack) :
 CSSR > 90%.
 DCR < 3% para CS (voz) y < 5% para PS(datos)
 HO SR > 85% para CS y 50% para PS
 En el caso de que uno de estos kpis no se
cumpla en alguna tecnología, se bloquearan
sus celdas y se realizará fallback de dicha
tecnología a la noche siguiente.

12.  El objetivo de la
fase de
optimización es
la aceptación a
nivel de clúster.
 La condición de
aceptación de
un clúster es la
mejora de los
kpis de
referencia al
menos en un
20% durante
una semana.

13.  Para aceptar cada clúster se entregará
un informe con:
 Estadísticos del clúster antes y después
del swap.
 Drive Test pre-swap y post-swap.
 Aceptación de BSC/RNC: todos sus
clústeres han mejorado 20% respecto al
valor de referencia, durante una
semana.

14.  Contadores
estadísticos: la
herramienta
utilizada es ESAT
(Ericsson Statistics
Analysis Tool) .
 Drive test: La
herramienta
utilizada es TEMS.

15.  Uso de DT:
 Análisis de plots de
DT
 Detecta:
 Sectores cruzados
(crossfeeders)
 Sectores sordos
 Bajo throghput
HSDPA/HSUPA.

16.  Uso de kpis:
 Si los kpis no
cumplen la
referencia, hay
que comprobar:
 Parametrización
 Vecinas
 Tráfico
 Los problemas de
funcionamiento
más comunes:

17.  Sobrealcance
 Nuevas antenas con las mismas
orientaciones, pero con distinta
inclinación (tilt).
 Celdas congestionadas.
 DCR alto por bajo nivel de señal (Signal
Strength-SS).

18.  2G MRR (Measurement
Result Recording) -> TA
 CLMX0300, muestras están
de media a 8 km (1TA
=450m), el primer anillo de
vecinas está a 5km.
 3G -> valor del
propagation delay con
ESAT.
 Distancia esperada que es
1km para este nodo
MADX6387 situado en una
zona urbana.

19.  Interferencia
 Se asigna una frecuencia nueva de la
banda de 900 de OSP a cada celda.
 DCR alto con caídas por mala calidad
(Bad Quality- BQ).
 Programar FAS (Frequency Allocation
Support) -> nueva frecuencia más limpia

20.  Problema de congestión
en las celdas:
 Número de portadoras(2G)
 En el ejemplo:
 Sector 2 más tráfico de voz
, 50% de congestión y
CSSR< 95%.
 Ajustar alguno de los
parámetros de reselección
CRO/PT/LAYER/LAYERTH.

21.  Número de Channel
Elements (3G)
 Ejemplo: aumenta el
comsumo de CE tras el
swap y muchas
peticiones de admisión
rechazadas.
 Afectaría al CSSR.
 Solicitar una
ampliación de CEs.

22.  Problemas de
integración de RNC
nueva.
 Éxito de HO de RNC
antigua < 80%.
 Configuración errónea
del Iur entre RNCs
(Legacy y Ran Renewal).
 Ejemplo de éxito de HO
cero entre la RNC RR y
legacy de Guadalajara
(Iurlink 161).

23.  RSSI (Received Signal
Strength Indicator)
 Si el RSSI > -100dBm es
problemas en el SSRR.
 Afectará en la
accesibilidad de voz y en el
DCR de datos.
 Analizador de espectro->
interferencia externa
(Dirección General de
Telecomunicaciones).

24.  TMA no configurado
 Swaps sin cambio de
SSRR
 Problemas para
cursar tráfico
 CSSR bajo.
 Valores bajos RSSI.
 Configuración en
remoto o local

25.  ROE (Relación de
onda
estacionaria)
 Ejemplo:
 MADX2539 CON
alarma de ROE
(Antenna
Branch)
 CSSR bajo.
 Técnico en local.

26.  DL Power
 Problemas de CSSR RRC y
RAB por congestión por
potencia.
 Bajar el CPICH (Common
Pilot Channel) Power.
 Efectos:
 Reducción de cobertura
 Sincronización inical más
lenta
 Reducción de capacidad
 Disminuye el tiempo de
reselección

27.  El inicio del proyecto
cumplió la fecha solicitada,
el final se alargó hasta
diciembre de 2013.
 Causas:
 Retrasos en los swaps de
transmisión a IP.
 “ Late sites”
 Paro de swaps por calidad.
 Problemas de instalación.
 Desarrollo de herramientas.
 Conclusión: problema de
sobrecoste.