Diseño Despliegue Radio en CDR y MAP_Revisado_V04

DISEÑO Y DOCUMENTACIÓN PARA EL DESPLIEGUE RADIO

Noviembre 2014

Vodafone C2- Confidential Página 1

1.DESPLIEGUE

Nota: La responsabilidad de ejecución cada una de estas tareas se puede encontrar bien en el ANEXO 1 (raíz) o bien en el Timing Chart (ANEXO 15) adjunto al paquete completo de documentación.

1.1 CONFIGURACIÓN DE RED

A. Crear el elemento SINGLE RAN (localización si aplica en caso de nodo nueva cobertura)

Elemento creado con su árbol de desglose– En Datos Generales: Fabricante y Modelo, Titularidad, RAN Sharing y si

el elemento es INDOOR o OUTDOOR en cuanto a su ubicación, no a su cobertura.

– Las tecnologías S/N indicarán lo activo en cada momento.

En configuración de red para la familia Single RAN necesitamos, provisionalmente y hasta comunicación oficial, incluir la información de celdas y los sectores físicos de las diferentes tecnologías que haya en el emplazamiento, pero esa información se reportará desde MAP. Esta es una práctica aún necesaria pero que será sustituida por completo con sólo la documentación en MAP.

Tal y como se encuentra configuración en estos momentos dependiendo del modelo de antena que se vaya a poner en el emplazamiento tendremos que poner tantos sectores físicos como bocas de antena se utilicen en el emplazamiento.

Esto es así porque si sólo creamos un sector físico y tenemos tecnologías que usen bocas distintas se perderá información de los downtilts eléctricos de la tecnología. (Esto mismo como veremos sucede ahora mismo en MAP también de la misma manera).

Pongamos por ejemplo que se van a instalar tres tecnologías: GSM900, U900 y U2100. Sin embargo el modelo de antena es una UD01P_T4 con 2 bocas de antena para las frecuencias del 900 y 2 bocas de antena para el 1800/U2100. En este caso en configuración de red tendremos mal documentado el sistema radiante como vamos a ver.

Tenemos un sector físico para cada sector GUW.1 y GUW.2 pero no tiene por qué coincidir el downtilt (en este caso el 900 tiene 4º de downtilt eléctrico y el U2100 tiene 6º de downtilt eléctrico) y es una información relevante que perderíamos si no separáramos las tecnologías en dos sectores físicos. Además aunque coincidan inicialmente, estos downtilts pueden cambiar con el tiempo y así no podríamos reflejar correctamente este futuro cambio. Es por ello que debemos crear un sector físico por boca de antena que se utilice.


En este caso habría que poner dos sectores físicos para el sector 1 de la siguiente forma:Sector Físico-GU-1Sector Físico-W-1


En cuanto al modelo de antena es importante identificarlo siempre que sea posible con el desplegable del modelo. Si algún modelo no está de alta en Configuración de Red, se comunicará a la zona y se documentará un genérico en CdR. En MAP debe documentarse el modelo correcto.Para el sector 2 en este ejemplo habría que poner dos sectores físicos también con la información de diseño correspondiente.

– Debe estar ticket de seguimiento 0001, que tiene que estar abierto: PIR y Fecha prevista en Servicio. En la fecha prevista de On Air, no se debe poner una fecha futura porque en tal caso no se visualizará en MAP a fecha actual. Es decir, poner la fecha en la que se está creando el ticket.

B. Crear árbol de desglose (comentarios, general y SW)

Es obligatorio rellenar los Datos Generales, con las tecnologías que se vayan activando con la letra S en explotación. Lo que aún no esté activo, tendrá una letra N en la tecnología correspondiente en los Datos Generales del elemento, bien sea que esté en Diseño o en Explotación. Cuando se active una tecnología, se pondrá la fecha de on air en el correspondiente Ticket de Seguimiento y se cambiará a S en el árbol de desglose del elemento, que deberá estar en Explotación desde la primera tecnología que se active. Este proceso se repetirá con cada tecnología / banda que se active.

También es obligatorio rellenar los campos obligatorios correctamente. Es IMPRESCINDIBLE indicar la letra correcta en el campo RAN Sharing, en función de si el elemento da servicio o no a más de un Operador. La Titularidad del Nodo también es auditable y crítica.


Sector Físico-GU-1

Sector Físico-W-1

- SSRR: por el momento se seguirá rellenado la información de HW y Sistema Radiante en CDR, aunque es IMPRESCINDIBLE hacerlo en MAP. En breve, se rellenará únicamente en MAP.

Celdas asociadas a sector físico y datos radio obligatorios.- Celda , Orientación, Tipo de antena, EDT , MDT …- Para meter los downtilts se usará un sector Físico para cada boca de antena con downtilt

independiente. En el ejemplo de abajo es correcto el sector GU.1 y el WK.1 puesto que se comparten bocas de antena en 900 y LTE con U2100. Es incorrecto el sector GUWK.1. porque no nos permite reflejar los tilts independientes entre 900 y 1800-2100.

C. Creación de tickets de seguimiento

Generamos en Configuración de Red un ticket de seguimiento por tecnología. Por defecto, lo hacemos así, PERO EL ORDEN DE LOS TICKETS DEBE CREARSE DE ACUERDO CON LA PLANIFICACIÓN DE ON AIR DE LAS TECNOLOGÍAS / BANDAS. No todas las tecnologías y bandas se activan en cada Site, y esto es un modelo genérico.

Ticket 0001(Se genera automáticamente al crear el elemento), para la MODERNIZACIÓN DEL UMTS2100

– Motivo : “Instalación de Equipo”– Plan : RAN Refresh– Descripción : MODERNIZACIÓN UMTS2100– En los datos, rellenamos con S la tecnología a la que aplica el ticket

(UMTS2100) y con N el resto


– PIR, el que corresponda según la planificación acordada con zona– Rellenamos fechas de replanteo, … y de instalación, y fecha prevista puesta

en servicio (IMPORTANTE PARA QUE APAREZCA EN MAP)– La fecha de puesta en servicio es la del día del swap del UMTS2100 y se

pone ese día, no días o semanas después.

Hay que rellenar en el ticket 0001 y posteriores las fechas básicas del seguimiento, según se van produciendo, no al final del proceso, con el objetivo claro de hacer seguimiento de despliegue en Configuración de Red, evitando información obsoleta y desperdigada en diferentes ficheros:

– Fecha de replanteo– Fecha Envío de Acta– Fecha Aprobación de Acta– Fecha Envío de Planos– Fecha Aprobación de Planos– Fecha Pre-pedido– Fecha Pedido– Fecha ELI (no obligatoria)– Fecha Real fin de instalación– Fecha Real puesta en servicio

Debe quedar relleno así:


Ticket 0002, para el SWAP DE GSM900

– Motivo : “Activación de Nueva Tecnología”– Plan : RAN Refresh– Descripción : SWAP GSM900– En los datos, rellenamos con S la tecnología a la que aplica el ticket

(GSM900) y con N el resto– PIR, el que corresponda según la planificación acordada con zona– Rellenamos fecha real fin de instalación– La fecha de puesta en servicio es la del día del swap del GSM900 y se pone

ese día, no días o semanas después. – Los tickets de seguimiento, una vez creados, hay que abrirlos dando al botón

de “Abrir Ticket”, abajo a la izquierda

Hay que crearlo así:



Ticket 0003, para la ACTIVACIÓN DEL UMTS900– Motivo : “Activación de Nueva Tecnología”– Plan : RAN Refresh– Descripción : ACTIVACIÓN UMTS900– En los datos, rellenamos con S la tecnología a la que aplica el ticket

(UMTS900) y con N el resto– PIR, el que corresponda según la planificación acordada con zona– Rellenamos fecha real fin de instalación– La fecha de puesta en servicio es la del día de la activación del

UMTS900 y se pone ese día, no días o semanas después.



Ticket 0004, para la TRAMITACION DEL UMTS900 Ticket 0005, para la ACTIVACIÓN DEL LTE1800

– Motivo : “Instalación de equipos”– Plan : Proyecto AIRWAYS– Descripción : ACTIVACIÓN LTE1800– En los datos, rellenamos con S la tecnología a la que aplica el ticket

(LTE1800 ) y con N el resto– PIR, el que corresponda según la planificación acordada con zona– Rellenamos fecha real fin de instalación– La fecha de puesta en servicio es la del día de la activación del LTE1800

y se pone ese día, no días o semanas después.

En este ticket se ponen las nuevas RRUs de LTE y la BBU de LTE asociada a este ticket. Si este ticket se crea desde el principio, antes de haber hecho el RR o en el caso de un nodo nuevo; para pasar el ticket 1 a explotación, debería estar cerrado también el ticket del LTE. Para evitar esto, hay que asignar las RRUs de LTE y la BBU de LTE al ticket 1.Y si en algún caso se hace antes el LTE que el RR o el G900, se cambiará el ticket 1 y se pondrá Activación del LTE en el ticket 1. Y el RR del 3G se pasa a otro ticket.

Ticket 0006, para la TRAMITACION DEL LTE1800

Ticket 0007, para la ACTIVACIÓN DEL LTE2600• Motivo : “Instalación de equipos”

– Plan : Proyecto AIRWAYS– Descripción : ACTIVACIÓN LTE2600– En los datos, rellenamos con S la tecnología a la que aplica el ticket

(LTE2600) y con N el resto– PIR, el que corresponda según la planificación acordada con zona– Rellenamos fecha real fin de instalación


– La fecha de puesta en servicio es la del día de la activación del LTE2600 y se pone ese día, no días o semanas después.


Ticket 0009, para la ACTIVACIÓN DEL LTE800º Motivo: “Instalación de equipos”

– Plan : Proyecto AIRWAYS– Descripción : ACTIVACIÓN LTE800– En los datos, rellenamos con S la tecnología a la que aplica el ticket

(LTE800) y con N el resto– PIR, el que corresponda según la planificación acordada con zona– Rellenamos fecha real fin de instalación– La fecha de puesta en servicio es la del día de la activación del LTE800 y

se pone ese día, no días o semanas después.


1.2 Archivo Digital

Con la información habitual:– Actas de replanteo– Planos M2– Planos as built– Proyecto técnico (si aplica)– informes de visitas a obra

Toda la documentación a cargar en AD se explica más concretamente en Anexo 1.4.

1.3 ARGOS

– En principio la información de accesos ya está registrada en ARGOS. Si dentro del Proyecto de Ran Refresh el acceso a alguno de estos emplazamientos es distinto del especificado, el Vendor debe actualizarlo convenientemente

– Si es un site de nueva cobertura, el vendor se encargará de meter en ARGOS la información.


2. RADIO

2.1 RADIO CdR-

HARDWARE

– RRUs (en CdR) : Asegurar que aparecen las RRUs que necesitamos / pedidos, que están bien rellenos los campos de a qué tecnología aplica, … y sobre todo, la potencia de la RRU.

NOTA: En algún momento esto pasará a estar en MAP y haremos carga masiva desde CDR.


2.2 RADIO MAP

Pasos a seguir para la definición de celdas SingleRAN/LTE en MAP y carga de vecinas

Pasos Previos

1.- Asegurar que se dispone de toda la información necesaria:

Celdas que se swapean / se integran nuevas. Información para poder definir en MAP los sectores nuevos ( BCCH , BSIC, Hopfreq, layer, hsn,

nuevas vecinas, relaciones a borrar si es necesario borrar alguna (*) ). Saber si alguno de los nodos nuevos cambia de LAC. Tener claro el RAC que llevarán las celdas en 2G y en 3G. Hay veces en que necesitamos

poner un RAC diferente en 2G dependiendo de la topología de BSCs y SGSNs. Para las celdas 4G hacen falta datos: PCI, TAC, Root sequence index , Downlink earfcn ,

bandwidth, etc (para crear celdas vía fichero se pasa la cabecera a usar). Asegurar el valor de cierto parámetros: Tipo de Hopping que se va a utilizar (sintetizado o

banda base), layer que tendrán las celdas nuevas. Relaciones de vecindad unidireccionales actualmente cargadas en la zona del swap. BSC a la que irán conectadas las nuevas estaciones SingleRAN. RNC a la que irán conectadas las celdas 3G. Datos RADIO de RF Sectors (azimut, tipo de antena, EDT, MDT, longitud de los cables). Las celdas que dan servicio a Orange desde nodos de Vodafone, NO se documentan ni en

MAP ni en CdR. Las celdas que dan servicio a Vodafone desde nodos de Orange, SÍ se documentan en MAP y

en CdR.

(*) si no se tienen, el vendor lo arreglará basado en el criterio enviado por VF para hacerlo en lugar de avisar a VF cuando surja algún problema en este sentido para que se les indique las vecinas que hay que borrar.

2.- Asegurar que los nodos del swap están creados en CdR con los campos necesarios rellenados (indicados en el .xls del NCR1). Se tiene que rellenar el campo Fecha prevista On Air en el ticket de seguimiento con la fecha prevista del swap o con una anterior.En la fecha prevista de On Air, no se debe poner una fecha futura porque en tal caso no se visualizará en MAP a fecha actual. Es decir, poner la fecha en la que se está creando el ticket.

El nodo tiene que tener toda la información básica de atributos completa, que está toda en CDR (deberá haberse rellenado en paso previo de despliegue).

El elemento Single Ran sincronizará en MAP en unas horas (hay 3 procesos diarios de sincronización). Si no se ve en MAP, por cualquier error, el VENDOR tendrá que crear el elemento en MAP a mano (para casos de RR y LTE). El elemento será creado por Vodafone Zona en MAP para los sites de Nueva Cobertura.


Pasos a seguir en MAP

Los pasos resumidos serán:

1.- Meter los datos del elemento. 2.- Obtener información de las celdas a swapear si se trata de un Refresh 3.- Definición de las nuevas celdas en MAP (con datos básicos)4.- Carga de vecindades nuevas, y corrección de las existentes. En 4G se indicarán en MAP sólo las vecinas identificadas como imprescindibles en el documento de estrategia de vecinas de Optimización Móvil Central de Vodafone España.5.- Exportar ficheros para cargar las nuevas vecinas en red6.- Ficheros a anexar en los distintos NCRs a Operaciones VDF / Orange7.- Actualización tras puesta en servicio8.- Borrado de las celdas y nodos swapeados (CdR y MAP). Creación de WO de borrado en red del elemento swapeado.9.- Auditoria y responsabilidad final del vendor de dejarlo acorde a documento.

De manera más extensa se detallan:

1.-Introducir los datos de NodeB (nuevo single RAN que antes iban en CDR)

MAP Base Config.:A nivel de NodeB, se han de rellenar tanto en SINGLE RAN (como en RRHH UMTS)

• RF DLCapacity (mbps) /RFULCapacity (Mbps) ahora para CE donde tipo de HSUPA 2 ms, 64QAM, Dual Carrier (si procede).

• TX DL /TX UL • Poner datos de HSDPA/HSUPA.

MAP Atributes:Descripción: State de DESIGN a ACTIVE.


Hay dos campos de nodeBType y config.NAme se rellenan en MAP.

BANDA BASE: Pestaña MANAGE HW-Node Type- Asegurar que aparecen las tarjetas que necesitamos / pedimos

– Ericsson: Nº de DUGs /DUWs, y tipo. ETMFX– Huawei: BBU3800 o BBU3900 y número de ellas. WBBPs (número y tipo).

WMPT o UMPT. A nivel de tarjetas de transmisión UTRP3 y UPUs de alimentación (CA o CC).

Ejemplo Huawei:

Se pueden importar las tarjetas con la funcionalidad Card Import se encuentra integrada dentro de la opción Import Element, a la cual se accede desde el Menú Network. A través de la importación de un fichero .csv, añadir tarjetas a los equipos que forman parte de la red. Para realizar la importación bastará con seleccionar la opción Card Import en el campo Import Type, e indicar la ruta del fichero fuente y la de un directorio en el que MAP creará un archivo log con el resultado de la importación.

El fichero de importación debe contener una serie de datos mínimos estructurados en las siguientes columnas para que MAP lo acepte como válido.

NODE_ID: indica el ID del nodo;SLOT: indica el slot del equipo donde se va a añadir la tarjeta;CARD_NAME: indica el nombre de la tarjeta que se va a añadir;STATE: indica el estado de la tarjeta que se va añadir.


Pestaña Basic config.:Deben quedar rellenos los campos de capacidad de transmisión, de radio, así como datos básicos.

2.-Obtener información de las celdas a swapear

Los datos de los nodos se pasarán al vendor en forma de fichero Excel con los parámetros básicos. (Si el vendor detectase alguna inconsistencia, se pondrá en contacto con VF para su resolución).


El vendor definirá las vecinas con el criterio que se le indique. Este criterio, salvo excepciones sigue esta norma: Copiar las vecinas actuales 2G si ya existe la celda a refrescar. Para el caso del U900, copiar las vecinas actuales de las F1 de U2100; y también para el caso de nuevos elementos 2G (en sites 3G only). La carga de estos datos, tanto en red como en MAP debe hacerla también.

Pasos a seguir recomendados:

1 Importar las celdas a swapear mediante un fichero .txt

Solo es necesario una columna, sin cabecera, con esas celdas, mediante la opción GIS Task Pane -> Search By = Cells by External File

2 Las celdas seleccionadas aparecerán en la pestaña Find Results. Marcando Edit Checked items abrimos la ventana Cell Site Editor

3 En la ventana Cell Site Editor marcando el botón Export se abre la ventana Cells and Parameters Export

4 En la pestaña 2G Cell marcamos las celdas y los parámetros que se necesiten y exportamos:Los parámetros marcados son un ejemplo, es posible que hagan falta otros.

E// CH_GROUP, DCHNO, BCCH, BSIC, LAC, Freq HOP….


5 Exportar relaciones de vecindad actuales de las celdas a swapear:

Vecinas 2g-2g : En la pestaña 2G Cell Intra-system seleccionamos las celdas y marcamos los parámetros CELL_NAME y NBR_CELL_NAME (*) y exportamos

Vecinas 2g-3g : Exactamente igual que antes pero desde la pestaña 2G Cell inter-system

(*) Añadiendo el parámetro NBR_CONTROLLER_ID sabremos en que BSC/RNC están las vecinas. Lo que puede servir para determinar si es Orange Nokia, Orange H//, etc.

IMPORTANTE: En este punto tendremos las relaciones bidireccionales, o las unidireccionales de salida de las celdas a swapear , pero NO tendremos las relaciones unidireccionales con destino las celdas a swapear ( p,e j , una F2 hacia una celda GSM ) o si la relación de la celda a swapear con otra es bidireccional o unidireccional. Para determinar las relaciones unidireccionales que tenemos en MAP podemos utilizar la tabla MV_MAPDBA_NEIGHBORS (se actualiza cada día a las 12:00h) de webMAP.

Para llegar a esta tabla, desde la ventana principal de webMAP: Operations -> Table View -> Table Browsing. Una vez en ella, marcamos las opciones indicadas:


, y damos al botón Apply Filter. Como todas las tablas de webMAP la podemos exportará a .csv , pero en este caso previamente habremos hecho un filtrado de las relaciones unidireccionales:

Una vez exportada la tabla, filtrando en la columna ORIGIN_CELL_NAME con las celdas a swapear tendremos las relaciones unidireccionales con origen las celdas a swapear. Filtrando en la columna DESTINATION_CELL_NAME con las celdas a swapear tendremos las relaciones unidireccionales con destino las celdas a swapear.

3.-Definición de las nuevas celdas en MAP (con datos básicos)

El primer paso para poder definir las nuevas celdas es asignar controlador a los nodos nuevos (y con ello el LAC):

3.1.- Una vez tenemos seleccionados todos los nodos que compartirán LAC los editamos. Se abre el GIS Task Pane con todos los nodos seleccionados

3.2 Añadimos un Interface ( Abis en este caso) con el botón Add . Una vez seleccionada la

BSCs se habilitará el botón , que nos permite aplicar el cambio a todos los nodos seleccionados


3.3 Añadimos un Interface (Iub en este caso) con el botón Add . Una vez seleccionada la

RNCs se habilitará el botón , que nos permite aplicar el cambio a todos los nodos seleccionados

3.4 Asignación de sector RF a una celda en MAP. SISTEMA RADIANTE.– Por sector: Orientación, Alturas, nº de antenas, tipo de antena, longitud de los cables…– EDT, MDT para las diferentes tecnologías. En el campo “Electric down tilt in degrees”.

(Como vamos a usar un rfsector por boca de antena no tiene sentido cubrir los campos del final “GSM electric donwtilt”, “DCS electric downtilt” y “UMTS Electric Donwtilt”).

– Importante asociar celdas a ANTENAS y documentación de sectores físicos.

Es importante asignar a cada celda el sector RF correspondiente (esto es necesario para otras herramientas nuestras). La manera de hacerlo es la siguiente:

Hay que tener el editor de celda abierto


En la pestaña Physical Attributes, en la parte central de Sector Name, pulsamos el botón Add y nos saldrán los sectores RF de ese emplazamiento.

Obligatoriedad de asignar un RF sector cuando creas una celda en MAP. Obligatorio añadir una columna con el nombre SECTOR_NAMES.


Para crear los RF Sector por fichero ha de usarse un fichero con esta cabecera mínima obligatoria:

Site_IdSector_Name

Antenna_Operator_Code

Azimut:

3536003536_GU_S1_35

UD01P_T4 35

3536003536_GU_S2_130

UD01P_T4 130

3536003536_GU_S3_300

UD01P_T4 300

Posteriormente se asignan las celdas a cada RF Sector:

Site_Id

Cell_Name Sector_Name

Antenna_Operator_Code

Azimut

003536

VA34WG1

003536_GU_S1_35 UD01P_T4 35

003536

VA34WU1

003536_GU_S1_35 UD01P_T4 35

003536

VA34WG2

003536_GU_S2_130 UD01P_T4 130

003536

VA34WU2

003536_GU_S2_130 UD01P_T4 130

003536

VA34WG3

003536_GU_S3_300 UD01P_T4 300

003536

VA34WU3

003536_GU_S3_300 UD01P_T4 300

Para todos los ficheros de importación que se utilizan actualmente se debe incluir el campo SECTOR_NAMES tras el campo CELL_NAMES en la cabecera, pero la columna no ha de rellenarse, ha de quedar vacía. En la versión actual de MAP, este campo puede quedar vacío, pero en versiones posteriores se va a hacer que sea obligatorio rellenarlo (VF indicará el cambio).

Por ejemplo, para cargar un fichero que cambie scrambling code, se utiliza:

Ahora debe quedar así:

Nueva nomenclatura para los RF Sectors en MAP:

Hasta ahora se creaba un RF sector para G900 y para U900, ahora ya creamos solo uno e independizamos la nomenclatura de los códigos de celda.


LLLLLL_T_Sx_A

donde: LLLLLL = Localización (código con 6 caracteres) T = Tecnología (G=GSM900, U=U900, D=DCS1800, W=U2100, J=LTE800, K=LTE1800, L=LTE2600) X = Sector (si es configuración bi-lobular habrá que crear 2 RF Sector con diferente azimut) A = AzimutPor ejemplo:000435_GU_S1_5Especifica la información de la antena que radia GSM900 (celda VA60WG1) y U900 (celda VA60WU1) en el site 000435. Al utilizar las mismas bocas de la antena ambas celdas utilizan el mismo RF-Sector puesto que toda la información del sistema radiante es común (Operator Code, RF Antenna Code, EDT, MDT, RF Cable Type, etc…)

000435_W_S1_5Especifica la información de la antena que radia UMTS2100 (celdas F1-F2-F3: 0306VA1_01, 0306VA1_07 y 0306VA1_04) en el site 000435. Al utilizar las mismas bocas de la antena utilizan el mismo RFSector.

Ejemplo de un posible caso con configuración bi-lobular: 000435_GU_S0_45 y 000435_GU_S0_165.

En el caso de LTE1800, al no utilizarse las mismas bocas que un DCS1800 cosite habría que generar ambos RF Sector porque pueden tener downtilts diferentes. Ej: 000435_D_S1_5 y 000435_K_S1_5.Cuando el LTE1800 y el DCS1800 están ambos.Van por bocas diferentes, y por tanto tienen que tener diferentes datos, de hecho se están cambiando las antenas para esto.


Una vez que hemos asignado el sector RF, tenemos que validar y salvar la ceda.

3.5 La definición de la celda se puede hacer de dos maneras:


-> desde el editor de celda , lo que implica ir una a una .-> importando por fichero (se pueden crear todas a la vez).

La segunda opción es mucho más rápida con el único inconveniente que se tiene que asignar un CID previamente (deberá darse no repetido-si es posible- dentro del rango dado por VF).

Para definir las celdas importando por fichero utilizamos un .csv (por ejemplo para 2G Huawei con la siguiente cabecera):

NODE_IDCELL_NAMESECTOR_NAMESLAYERLACRACCINCCBCCBCCHFREQ_HOPPING

LAYER = Es un valor que se tendrá que consensuar con cada zona.TYPE = 0 ( GSM),1 (DCS )CI = Se le tiene que asignar uno que esté libre en la zona (*)

-> A esta cabecera H// se le añadirán los campos existentes en la cabecera [OSS] CELL_BASIC_INFO_OSS_R11 (el tema de las cabeceras está explicado en el pto. 4) con los valores acordados entre VDF y H// para dejar así homogéneos los valores de red y los de diseño en MAP.

-> Queda por determinar la cabecera con los parámetros necesarios para definir las celdas Ericsson.

Para importar: Menú principal -> Scenario -> Import Cell Data

Import Type -> seleccionamos el tipo de celda ( H// 2G o E// 2G )

IMPORTANTE: Import Only existing Cell Names no tiene que estar marcado


(*) Para saber que CI están libres, se puede hacer un Cell Report en MAP y ver cuáles quedan libres dentro del rango permitido

3.6 asignación de ANTENAS en RF sector.MAP para antenas (en el RF Sectors):

Operator Code. Tiene que ser el nuevo que será del estilo OP361D440A, por ejemplo. Con este código nuevo ya tenemos cargadas todas las especificaciones de las antenas que tienen código, así que no perdemos info. El código viejo sigue existiendo, pero no debe ser usado.

RF Antenna Code. Aquí irá el modelo. Usando el tipo anterior, ya están cargados los modelos correspondientes haciendo referencia al fabricante.

Height in meters. Hace referencia a la altura total, no a la de referencia. Mechanical down tilt in degrees. Electric down tilt in degrees

Cosas que SE PEDIRÁN EN UN FUTURO y no se pueden documentar todavía:

Los campos GSM electrical down tilt in degrees; DCS electrical down tilt in degrees y UMTS electrical down tilt in degrees no aplican ahora, pero en un futuro si tendrán sentido y habrá que rellenarlos (no aplican de momento debido a la definición que hacemos a día de hoy de RF sectors por boca de antena).

Antenas que aún no tienen el código nuevo. Según vayan apareciendo nuevas necesidades se irán introduciendo en la herramienta.

Downtilt LTE 800, Downtilt LTE 1800 y Downtilt LTE 2600. Diplexores, triplexores y quadruplexores y tecnologías a las que afectan. Combinadores híbridos y tecnologías a las que afectan. Combinadores de bajas pérdidas y tecnologías a las que afectan. Splitters, tappers y acopladores y tecnologías a las que afectan. Niveles de diplexión/combinación (aunque si ponen todo lo anterior podría sacarse). Indicación de si es torre, azotea u otro tipo de instalación.

4.-Carga de vecindades nuevas

4.1 MOVERNOS A LA FECHA DEL SWAP (Ver página 32)

4.2 Modificar todas las relaciones de vecindad existentes de las celdas swapeadas Tienen que quedar unidireccionales de salida.Lo podemos hacer importando un fichero con las relaciones de vecindad ( .csv con separador “;” , la primera columna serán las celdas origen, la segunda las celdas destino y no es necesario cabecera ) .

Menú principal -> Scenario -> Import Cell Neighbors


Neighbor Import Type = Remove CellsNeighbor Relationship Type = Uni-directional

Cuidado¡¡ al hacer el mapeo de las columnas si el fichero de entrada tiene en la primera columna las celdas a swapear hay que invertir el mapeo, es decir, Column 0 con Destination_Cell_Name y Column 1 con Origin_Cell_Name

NOTA: si hay que borrar relaciones existentes para dar cabida a las nuevas, será a decisión de la ingeniería de VF: si hacerlo seleccionado la opción Neighbor Relationship Type = bi-directional o borrar solo vecinas en una dirección. En caso de que VF no indique nada al respecto, se realizará bidireccional.

4.3 Importar nuevas relaciones de vecindad:

3.3.1 En el fichero de vecinas sustituimos las celdas a swapear por las celdas nuevas.

3.3.2. Para cargar las vecinas lo hacemos en la misma ventana que para borrar relaciones de vecindad .Ahora las opciones seleccionadas serán:

Neighbor Import Type = Apend CellsNeighbor Relationship Type = Bi-directional*

* Si existiesen relaciones unidireccionales ( que no sean VAG ) el valor de Neighbor Relationship Type = Uni-directional.

¡¡ CUIDADO¡¡ las relaciones de vecindad con celdas VAG ( 99XXAP) se tienen que cargar unidireccionales.


NOTASi. En el mismo fichero se pueden importar relaciones 2g-2g y 2g-3gii. MAP no permite cargar en un mismo fichero relaciones de vecindad uni-direccionales

y bidireccionales por lo que se tendrá que hacer en dos pasosiii. Si se tienen que cargar relaciones bidireccionales no es necesario que en el fichero

este la relación en los dos sentidos ( es decir , dos filas ).El programa se encarga de crear los dos sentidos.

Si un swap 2G está planificado en una fecha determinada y se han cambiado las vecinas a esa fecha en MAP, si después cambia la fecha del swap 2G, también hay que cambiar las vecinas en MAP para adecuarlas a las nuevas fechas.

En el caso de las celdas U900 o en otros trabajos como activación de portadoras nuevas, y que hay que crear vecinas nuevas, el vendor debe actualizar en MAP los parámetros de vecindad 3G-3G, como son BLINDHOFLAG, HOCOVPRIO, idleqoffset2sn, etc.

5.-Exportar ficheros para cargar las nuevas vecinas en red

Las exportaciones se hacen desde la ventana Cells and Parameters Export ( a la que llegamos desde la ventana Cell Site Editor mediante el botón export )

5.1 Tenemos que haber seleccionado primero todas las celdas afectadas:

-> Siemens: Todas las de la zona -> Ericsson: solo las celdas con vecinas “ swapeadas” , las celdas swapeadas y

relaciones nuevas .-> Orange: solo las celdas con vecinas “swapeadas” o relaciones nuevas

5.2 En MAP existen una serie de cabeceras “oficiales” para la exportación tanto de los ficheros de integración como los de vecinas

( todas empiezan con [OSS] ). En este caso las cabeceras que necesitamos son

SIEMENS -> [OSS] Siemens 2G Neighbors Intra-Inter system ( en la pestaña Siemens 2G Cell )

ERICSSON 2G ->Con las celdas E// seleccionadas : [OSS] Ericsson 2G CNA Vecinas , [OSS] Ericsson

2G CNA listas Idle y Active ( ambas están en la pestañan Ericsson 2G Cell )Con las celdas nuevas seleccionadas ( caso H// ): Z5_Foreign_PINZA ( en la pestaña

Huawei 2G Cell ) a la que le añadiremos el parámetro Layer

ORANGE-> Si la celda destino es NOKIA:

[OSS] 3G Nokia definición de vecina 2G ADJG_NSN ( en la pestañan Nokia 3G Cell inter-system ).

Una vez exportado podemos eliminar del fichero todas las relaciones que no tengan como destino celdas “swapeadas” o relaciones nuevas. El campo ADJG_AdjgId tiene que estar vacío.


-> Si la celda destino es Huawei tendremos que rellenar una tabla con el formato acordado con Orange*. Podemos coger la información de las tablas de webMAP ( seleccionamos Vendor = Huawei y Technology = Sharing )

Las cabeceras las seleccionamos en el desplegable Configuration:

Y luego marcamos el botón Load Configuration para cargarla. Una vez cargada ya podemos exportar.

* VDF pasará el fichero a los vendors

6.-Ficheros a anexar en los distintos NCRs a Operaciones VDF / Orange

6.1 Ficheros a anexar en el NCR a O&M VDF

-> Fichero de definición de Inners ( todas las celdas nuevas ): Se pasará un fichero Excel con la siguiente cabecera

MSS CELDA LAC CI BSC EA

En la definición de Inner incluimos EA (Emergency Area) que es el prefijo telefónico fijo quitando el 9 y va por provincias:Por ejemplo:

Provincia Pref. TelefonicoEA

Madrid 91 1Valencia 96 6Burgos 947 47Zaragoza 976 76Salamanca 923 23

- Serán necesarias varias pestañas: Una para indicar las inners que se crean y otra con las inners que se borran ( !!cuidado¡¡ no se pueden borrar las celdas swapeadas hasta que se hayan swapeado )

-> Fichero de definición de locnos ( todas las celdas nuevas ): El LocNo es 4-34607&LAC&CI -> pero el LAC y el CI siempre con 5 cifras es decir se completa con “0” si no las tiene.

Se pasará un fichero Excel con la siguiente cabeceraCrear LOCNO 2GCadenaLACCadenaSACLACFinalSACFinalLOCNO


Asociar LOCNO 2G

-> Fichero de definición de outers ( solo será necesario si las nuevas celdas tienen vecinas con celdas de distinto Server ( MSS ) ) : Se pasará un fichero excel con la siguiente cabecera

NOTA: Si ingeniería VF pasa LAC Outer, se realizarán esta definiciones en lugar de celdas OUTERs.

- Serán necesarias varias pestañas: Una para indicar las outers que se crean y otra con las outers que se borran ( !!cuidado¡¡ no se pueden borrar las celdas swapeadas como outers hasta que se hayan swapeado )

- UMSC : MSS donde está definida la celda- MSC : MSS donde se tiene que definir la celda como outer

IMPORTANTE: Hay que notificar a Operaciones regional que los ficheros de inners y

outers les llegarán con este formato

Siemens:

-> Fichero resultado del export de la cabecera [OSS] Siemens 2G Neighbors Intra-Inter system (guardar con extensión .dat ).

-> Fichero .csv ( Vecinas_Pinza_ZX_WXX.csv ) con la definición de las celdas H// 2g , las E// 2g y las Nokia 2g (AVE ) de la zona. La cabecera tiene que tener los siguientes campos:

BSCCELLMCCMNCLACCINCCBCCBCCHNOC_SYS_TYPECCHPWRMSTXPWR

MNC = 01 (asegurar esto, no funciona si es = 1 )C_SYS_TYPE = GSM900 ( o DCS1800 si hubiese alguna )CCHPWR = 33MSTXPWR = 33

CUIDADO¡¡ En este fichero tienen que estar TODAS las celdas 2g externas a S// estén o no implicadas en el swap.


ejemplo INNERS y LOCNOS.xls

ejemplo OUTERS.xls

UMSC CELDA LAC CI MSC

NOTA: si por lo que sea se ha producido un cambio en alguno de los parámetros indicados en la cabecera del fichero en alguna de las celdas externas existentes se tendrá que anexar otro fichero con esos cambios.

Ericsson

-> Fichero resultado del export de la cabecera [OSS] Ericsson 2G CNA Vecinas , [OSS] Ericsson 2G CNA listas Idle y Active. Con la información obtenida exportando la cabecera Z5_Foreign_PINZA tenemos que rellenar el fichero CNA_foreign.dat ( a pasar por VDF a los vendors )

-> Para el cálculo de los parámetros de potencia en las foreign se pude utilizar la hoja Excel que vdf pasará al vendor. (Ver página 34 )

6.2 Ficheros con relaciones de vecindad 3g de distinto vendor al que realiza el swap

Si existe alguna relación con destino una celda 3G no perteneciente al vendor que realiza el swap también será necesario pasar esos datos con su formato correspondiente en el NCR

6.3 Ficheros a anexar en el NCR a ORANGE

Este NCR no se creará directamente a Orange sino a Operaciones o GTR VF y se enviará asimismo un mail con los ficheros para que Vf pueda hacerlo cargar convenientemente en la red de orange.

Celdas HUAWEI

Se utiliza la plantilla acordada* con ellos para la definición de celdas, con los siguientes nombres de ficheros

GSMCELL_Delete -> Celdas 2G swapeadas a eliminar de la tabla GSMCELLGSMCELL_New -> Nuevas celdas a definir en la tabla GSMCELLGSMNCELL_New -> Nuevas relacionesGSMNCELL_Delete -> Relaciones con celdas swapeadas a borrar

Es necesario indicar el GSMCELLINDEX cuando se trata de borrar celdas. No es necesario cuando se definen las nuevas. La información la podemos obtener en webMAP**

Conviene indicar que primero se deben ejecutar los de borrado y después lo de creado

* VDF pasará la plantilla al vendor (H// o E// ) para poder preparar este fichero** En webMAP seleccionamos Vendor = Huawei y Technology = Sharing

Celdas ERICSSONSe usará el modelo simplex

Celdas NOKIA (quedan pocos sites)

-> Fichero para borrar las celdas swapeadas: Se pasa un fichero Excel con dos columnas


RNC WBTS/WCEL/ADJG2607 WBTS-147/WCEL-39101383/ADJG-16

La información necesaria la podemos obtener en webMAP (ver página 32) en la tabla N3G_ADJG.

->Fichero resultado del export de la cabecera [OSS] 3G Nokia definición de vecina 2G ADJG_NSN con las indicaciones dadas anteriormente.

7.- Actualización tras puesta en servicio

EN LA HERRAMIENTA CONFIGURACIÓN DE RED

Para los SWAPs o nuevos UMTS2100:– Rellenar UMTS2100 Activo = S en Datos generales

Para los SWAPs o nuevos G900:

– Rellenar GSM900 Activo = S en Datos generales

Para la activación de un nuevo UMTS900:

– Rellenar UMTS900 Activo = S en Datos generales


PASAR A EXPLOTACIÓN EL ELEMENTO en CDR.

Y en MAP se cambia State a ACTIVEMAP Atributes:

– Descripción: State de DESIGN a ACTIVE.

Hay que poner Activo tanto el nodo como la localización o site.

8.- Borrado de las celdas y nodos swapeados (CdR y MAP)

Pasado el periodo acordado por VDF se procederá al borrado (paso a histórico ) del nodo swapeado en CdR. El borrado en CdR NO implica el borrado del nodo (todas sus celdas, vecinas) en MAP desde la fecha de borrado (se seguirá pudiendo consultar el nodo en fechas anteriores ).

Por eso, hay que actuar en las dos herramientas.MAP Atributes:

– Debe desactivarse en MAP en el nodo y rellenar la fecha de desactivación (deactivation date en Service Dates).Si el nodo sigue teniendo dependencias de transmisión no borradas no dejará desactivarlo. En este caso hay que borrar dichas dependencias de TX

– Descripción:State de ACTIVE a DEACTIVE. (Esto se cambia el día que se haga el RR)Borrado del elemento de Configuración de Red

– Hay que pasarlo a Histórico

Borrado de la TX en Configuración de Red y MAP– A2Ms, tramos de interconexión, conexiones en los DXXs, …– Borrar asignaciones de recursos en hojas excel de BSCs y DXX que maneja cada

región

ATENCIÓN: Hay nodos que NO hay que pasar a histórico o no hay que desactivar en MAP. Son nodos multi-tecnología (GSM+DCS) en los que se hace el RR del GSM, pero no se hace RR del DCS. En estos casos, el nodo debe seguir activo y lo que hay que desactivar son las celdas GSM.

En MAP: Se desactivan las celdas GSM En Configuración: habría que pasar el nodo a rediseño para borrar los sectores

GSM y dejar sólo los sectores DCS. Se crea un ticket nuevo en diseño que sea proyecto Ran Refresh, Apagado celdas GSM. Se actualizan los datos y la fecha puesta en servicio que será la del RR 2G y se pasa el ticket a explotación

9.-Auditoria.


Se realizarán auditorias de herramientas semanales (MAP, THOPE y CDR).Enviaremos:* Un conjunto de auditorías para analizar la correcta documentación de despliegue relativo a la parte RanRefresh, nueva cobertura y LTE.* Las auditorias se presentarán con una frecuencia semanal. * La idea es ir auditando semanalmente lo puesto ON AIR la semana anterior e ir viendo la corrección de lo pendiente.

Las auditorias elaboradas en WXX auditarán el listado de nodos RanRefresh, nueva cobertura y LTE con dos días de diferencia a su puesta en servicio. Es muy importante por tanto que las fechas queden bien reflejadas en las herramientas desde el minuto uno de su puesta en servicio para realizar este seguimiento.

Auditorias:

Discrepancias RanRefresh y MAP. EstadoSe analizan las diferencias entre el conjunto de nodos RanRefresh desplegados y que: - No aparecen en MAP - Aparecen como RRH-UMTS en MAP - Aparecen con estado de Diseño en MAP - Tienen diferente localización en MAP y CDR - Paso a explotación CdR - Legacy E2G/S2G desactivado/paso histórico MAP/CdR

Discrepancias RanRefresh y MAP. Celdas y RF SectorsSe analizan las diferencias entre el conjunto de nodos RanRefresh desplegados y que: - No tienen celda asignada - No tienen RF Sector asignado - No tienen antena asignada - Tienen RF Sector asignado en el site pero No hay ninguna celda - Celdas con más de dos RF-Sector o con nomenclatura errónea - Tienen nomenclatura de celda incorrecta

Discrepancias RR-MAP-COLECTOR. Tecnología definidaSe analizan las diferencias entre el conjunto de nodos RanRefresh desplegados y que no aparecen en colector o tienen diferente tecnología definida en MAP y Colector, si se añade una nueva tecnología se incluirá: - Nodos RanRefresh que no aparecen en colector - DCS - GSM - U900 - U2100 - LTE800 - LTE1800 - LTE2600 Discrepancias RR-COLECTOR-MAP. Tecnología definidaSe analizan las diferencias entre el conjunto de nodos RanRefresh desplegados y que tienen diferente tecnología definida en Colector y MAP, si se añade una nueva tecnología se incluirá:

- DCS - GSM


- U900 - U2100 - LTE800 - LTE1800 - LTE2600

Discrepancias RR-COLECTOR-MAP. Parámetros RadioSe analizan las diferencias entre el conjunto de nodos RanRefresh desplegados y que tienen diferentes parámetros radio definidos en Colector y MAP:

- 2G. Se chequea BSC-RNC / LAC / CI / RAC / BCCH / BSIC / OPERADOR - 3G. Se chequea RNC / LAC / CI / RAC / SC / UARFCNDL / OPERADOR - 4G. Se chequea parámetros como el TAC, pendiente de definir.

- Related Node Preassigned MAP. Nodos que presentan sólo una preasignación de RNC/BSC en MAP que se crea desde TX y está incompleta, por estar pendiente de confirmación Rf

.

ANEXO MAP

a.- Reportes de celdas:

En la pestaña Reports de la ventana principal si seleccionamos el report Cell Report tenemos todas las celdas de la región. Se pueden hacer filtros llevando el campo seleccionado a la zona:

-> En este report tenemos la información básica de las celdas, que se puede exportar a excel ( seleccionamos primero todas las celdas que queremos exportar )

-> También desde este report podemos ir a la ventana Cell Site Editor. Simplemente con el botón derecho del ratón sobre alguna de las celdas seleccionadas nos aparece la opción de edición:

-> También tenemos disponible el report Node en el que encontramos todos los nodos de la zona (controladoras, BTS, etc )

b.- Modelo de Fechas de MAP

Por defecto al abrir MAP trabajamos a día de hoy .Se puede ver en la parte superior de la ventana principal:

Pero para poder trabajar según lo indicado en este documento será necesario moverse a la fecha prevista del swap. Simplemente marcando la flecha se despliega el calendario:


Seleccionamos la fecha del swap y desde ese momento estamos trabajando en esa fecha.Todos los cambios que hagamos serán efectivos a partir de esa fecha.

c.- Error Log File

Todas las operaciones de carga de vecinas o definición de celdas generan un log de resultado. Conviene mirarlo por si algo ha fallado

d.- WebMAP : Herramienta donde se puede consultar diariamente la información cargada en Red. La ruta para acceder es

http://10.18.159.50/WebMAP/Default.aspx

Operations -> Table view -> Table Browsing

Seleccionamos Vendor , Technology , marcamos DATA (tablas ya procesadas ) y Apply Filter . Nos aparecerán todas la tablas que hay para ese vendor y tecnología:


http://10.18.159.50/WebMAP/Default.aspx

Se pueden exportar.

e.- Calculo parámetros de potencia para las foreign H//

Los parámetros a calcular son: BSPWR, BSTXPOWER, BSRXMIN, BSRXSUFF.

PARAMETER DESCRIPTION VALUE

VALOR POR DEFECTO

bspwr

EIRP for BCCH (reference point is in the "air" immediately after the transmitter antennas and before the receiver antennas = EIRP)

depends on physical configuration (antenna gain, cable losses, bts power…) 50

bstxpwr

EIRP for non BCCH carriers (reference point is in the "air" immediately after the transmitter antennas and before the receiver antennas = EIRP) Normally BSPWR=BSTXPWR

Normally BSTXPWR = BSPWR 50

bsrxmin

minimum uplink signal strength (at the BTS antenna)

0 to 150 (dBm negative) 130

bsrxsuffBSRXMIN (en negativo)+25

(dBm negative) 109

Vamos a la pestaña "Balance Potencia" y rellenamos los campos en Amarillo, que básicamente son:


Potencia salida TRU en dBm (BSPWRB, BSPWRT)

Pérdida cable

Ganancia antena (dBd)

43 3 10

Donde la potencia de salida TRU es:

43dBm con 2TRX (20w por trx)41dBm, con 3TRX (13w por trx)40dBm, con 4TRX (10w por trx)

Y la ganancia de antena:

ANTENAS PINZA TIPO

GANANCIA dBi

GANANCIA dBd

80010203 PANEL 17 14,85739648 PANEL 13,5 11,35

80010204 PANEL 18 15,8580010213 PANEL 17 14,85

736347 OMNI 11 8,85736349 OMNI 10,5 8,35

Y con esto se actualizan los campos en verde, que son los que usamos para la definición de foreign.

f- Sincronización CdR/MAP


Diseño Despliegue Radio en CDR y MAP_Revisado_V04

Documents

Transcript of Diseño Despliegue Radio en CDR y MAP_Revisado_V04