configuración tcu.doc

CONFIGURACION TCU TME1 (30)

Prepared (Subject resp) No.

Luz Blanco/Manuel Jesús CabezónApproved (Document resp) Checked Date Rev Reference

Pedro Cardete 2014-07-21 C

CONFIGURACIÓN TCU TELEFÓNICA. PROYECTO ANE.Contents1 Historial...................................................................................................22 Introducción............................................................................................33 Descripción del equipo..........................................................................34 Conexión Local.......................................................................................65 Antes de cargar sw...............................................................................116 Carga SW Interno TCU.........................................................................12

6.1 Carga Sw en Plano Primary:....................................................136.2 Carga de SW en Plano Backup:...............................................166.2.1 Por Comando SW (aprovesw):.................................................166.2.2 Por Server SFTP:.....................................................................18

7 Carga de la configuración de la TCU..................................................207.1 Consideraciones iniciales.........................................................207.2 Procedimiento Carga Configuración Script:.............................217.3 Consideraciones Finales..........................................................22

8 TroubleShooting. Verificaciones en caso de problemas.................228.1.1 Comprobación de puertos........................................................228.1.2 Verificar Alarmas......................................................................238.1.3 Comprobación del archivo cargado en la TCU.........................248.1.4 Comprobaciones conectividad OSS y NEDSS.........................268.1.5 Comandos útiles.......................................................................29





1 Historial.

Rev. Date Responsible Comments

Luz Blanco/Isaac Quintana First Draft

A 07-07-2014 Manuel Jesús Cabezón Adaptación a Local.

B 17-07-2014 Manuel Jesús Cabezón Incluir Procedimiento Carga Script. Proceso alternativo.

C 21-07-2014 Manuel Jesús Cabezón Detalle/Ampliación TroubleShooting





2 Introducción.

TCU, Transport Connectivity Unit, es el nuevo equipo Ericsson para integrar todo el tráfico GSM, WCDMA, LTE, encapsulándolo sobre IP, y/o tráfico de Local Area Network (LAN) en un sólo interfaz Wide Area Network (WAN). Este interfaz WAN saca todo el tráfico de la TCU montándolo sobre un soporte físico que puede ser de distinta naturaleza (E1, fibra óptica, Ethernet,…)

La comunicación entre BTSs y/o Nodos B con la BSC / RNC se produce por paquetes IP. Este tráfico IP puede ir montado sobre TDM o capa L2 o capa L3.Las funcionalidades del equipo son:

8 Gigabit Ethernet ports for aggregation of traffic from multiple digital units 8 E1/T1 ports for connecting GSM RBS cards (DUG) IP over the TDM (E1/T1) backhaul (as a solution during migration) Advanced shaping functionality for up to eight queues, with large buffer depth, supporting highest LTE

capacity. Can act as an IP router and/or as an Ethernet bridge suiting all backhaul deployment scenarios. Supports NTP, 1588v2 and synchronous Ethernet for RAN synchronization. Has a local oscillator with 12 months holdover time supporting synchronization over virtually any backhaul

technology, including satellite. Supports native IP transmission (Abis IP) for Ericsson GSM RBSs making a true All IP multi standard

RBS. Provides Ethernet LAN/WAN connectivity for local site equipment

3 Descripción del equipo

El hardware de la TCU está compuesto por una tarjeta de la que vamos a describir a continuación sus interfaces de conexión.





A continuación se detalla la función de los puertos:

PUERTO CONECTOR DESCRIPCIÓN





TCUGPS RJ-45 Puerto GPS, también usado para

calibrar relojLMT RJ-45 Interfaz consola para conexión en

LocalTN A - TN D RJ-45 Transmisión Ethernet. Interfaz

Externo EléctricoTN E - TN H SFP Transmisión Ethernet. Interfaz

Externo ÓpticoET A - ET D Transmisión E1, T1, J1. Interfaz

Externo Eléctrico

Especificaciones Técnicas:

LED DESCRIPCIÓN FUNCIONAMIENTOFallo Rojo, existe fallo

Operación Verde, si están conectados a la TCU

Mantenimiento Amarillo, trabajos de mantenimiento

Estado Amarillo, la tarjeta TCU está trabajando





4 Conexión Local.

La gestión local de la TCU se realiza a través de puerto RJ45 LMT. Para esta comunicación utilizaremos un cable Ethernet (plano o cruzado). La IP de conexión es 192.168.1.1/24 por lo que la configuración de nuestra Conexión de Área Local debe ser la siguiente:

Podemos utilizar para conectarnos la consola de Windows (cmd - Windows Command Prompt) o el Hyperterminal de Windows.





Una vez abierto el programa (Ejecutar – cmd) tendremos que hacer un telnet a la IP de gestión de la TCU.Tendremos que introducir usuario y contraseña:

User: admin

Password: hidden

Si queremos operar sobre la TCU debemos abrir sesiones que nos permiten realizar distintas operaciones sobre ella. Estas sesiones deben abrirse antes de realizar la operación correspondiente y, una vez terminada, hay que cerrarlas. Los tipos de sesiones son los siguientes:

- Sesión software (swsession): esta sesión permite cargar el SW interno de la TCU.

- Sesión (session): la utilizamos cuando queremos cargarle un archivo de configuración xml a la TCU.

- Transacción (transaction): tenemos que abrir esta sesión para poder crear, modificar o borrar cualquier MO de la TCU.

Para la configuración de la TCU mediante un archivo xml o para cargar el SW interno de la misma emplearemos una conexión FTP Segura (SFTP). Esta conexión la estableceremos con un SFTP Server llamado FreeFTPd. Este programa se puede descargar desde la siguiente dirección: http://www.freesshd.com/?ctt=download . La configuración del Server SFTP debe ser la siguiente:

En FTP Setting, pulsar el botón “Add” para añadir usuario





En el campo Login, escribir: “tcu”. Seleccionar en el desplegable Authorization “Password Stored as SHA1 hash” .Y por último, indicar en el campo password: tcu. De esta forma tendremos que el user/password con el que la TCU se conecta a nuestro PC sea “tcu”. En el campo “home directory” indicaremos la ubicación del archivo o SW interno a descargar. Por último, pulsar “Apply” para guardar todos los cambios.





Para arrancar el Server SFTP, seleccionamos SFTP en el menú izquierdo del programa y posteriormente pulsamos el botón “Start”.





Para comprobar que el Server SFTP está activo, seleccionamos “Status” en el menú de la izquierda y comprobamos que el estado del Server SFTP es el que se muestra en la siguiente imagen:





5 Antes de cargar sw

Una vez estamos conectados a la TCU y antes de cargar sw o configuración, hay que verificar una fecha que tiene efecto sobre el futuro funcionamiento del sincronismo en la unidad.

Las TCU’s tienen un oscilador interno para entrega de sincronismo que se calibra en fábrica y que dicha calibración de fábrica es válida por un año.

Comprobar que la fecha de calibración, no ha expirado, o no está próxima a expirar. El comando para verlo es calexpdate

ABLOLLANO000021-OSmon> calexpdate

20150224

OperationSucceeded

ABLOLLANO000021-OSmon>

Si la fecha ya ha pasado o va a pasar en las 2 próximas semanas No integrar esa unidad! Es necesario recalibrarla con un GPS.

Si la fecha es dentro de entre 2 semanas y un mes si es posible no integrar esa unidad, si se integra, muy importante REPORTAR LA SITUACION





Si la fecha es más de un mes desde el día actual continuar con la integración.

6 Carga SW Interno TCU.

El SW interno de la TCU permite el correcto funcionamiento del equipo. Actualmente la versión de SW que se carga en estos equipos es la CXP102165/2 R1AA.

El SW Interno de la TCU se puede descargar del siguiente de en ANTARES.

Se debe descargar para instalar el SW que tengamos comunicado y publicado en la siguiente Tabla, dentro de la Pestaña TME:

ANTARES -> NETWORK OPERATIONS -> DOCUMENTS -> TAC RADIO -> NIVELES SW OPERADORES

El SW interno está compuesto por 5 archivos, siendo el archivo master para esta versión de SW Interno (R1AA) el siguiente: siu02_sw.tar

Podemos comprobar la versión de SW interno que está corriendo en nuestra TCU con el comando rev. Lanzando este comando sobre la TCU nos devolverá una salida como la que sigue:





TFLPSTCRC007841-OSmon> rev

------------------- OSE modules ------------------------------------------oam.chk Operation & Maintenance R1AA01secmgrr.chk Security Manager R1Z04inetr.chk MLPPP Daemon R1V01ltp.chk Local Terminal Port R1Z04snc.chk Synchronization R1Y01pd.chk Packet Distributor R1Z04cesopsn_pwr.chk Circuit Emulation Service R1V01hdlc_pwr.chk HDLC Pseudo-Wire Emulation R1Z04p_relayr.chk Packet Relay R1Z04profiler.chk System Profiler R1G03hwtest.chk Hardware Tester R1V01lcf_cp.chk Local Connectivity Function R1C01bsp.drv Board Support Package R1X02bootstrap.chk Bootstrap R1V02loader.drv Software Loader R1A37np_init_app.drv APP3K Setup R1Z04linuxload.drv Linux Loader R1V01

------------------- Firmware modules -------------------------------------PBOOT CXC 112 3777/2 R5C01PBOOT_DATA X YNP_INIT_T2.OSE CXC 173 3983/2 R5C01FPGA - 0x2272

------------------- Software archives ------------------------------------Primary:OSE CXP102165_2 R1AA02Linux - R1AA02

Backup:OSE CXP102165_2 R1AA02

------------------- Active software --------------------------------------OSE PrimaryLinux Primary

TFLPSTCRC007841-OSmon>

Así comprobamos si el SW que está corriendo sobre nuestra TCU es la que nosotros queremos.

Como vemos en el printado anterior, podemos verificar que existen dos planos de SW en la TCU. El Primary y el Backup.

Debemos tener en consideración si lo que queremos es actualizar el Nivel Sw en el plano Primary o en el Plano de Backup. Es MANDATORIO tener ambos planos SW con el mismo nivel SW. Por ello vamos a considerar ambas opciones:

6.1 Carga Sw en Plano Primary:

Para actualizar el Plano Sw Primary procederemos del siguiente modo:

En primer lugar direccionamos el FreeFTPd hacia la carpeta en la que tenemos el SW interno de la TCU (R1AA). Para ello nos vamos a “Users” en el menú izquierdo del programa y





editamos las propiedades de nuestro usuario. En “Home Directory” enrutamos el FreeFTPd hacia el directorio en el que tenemos el SW interno de la TCU. Concretamente a la carpeta que contiene el archivo master siu02_sw.tar

Una vez hemos finalizado el direccionamiento de Server SFTP nos conectamos a la TCU para lanzar los comandos de carga de SW interno.

Para cargar el SW interno a TCU lo primero que debemos hacer es abrir el puerto SFTP de la TCU que permite la transferencia de archivos entre nuestro PC (Server SFTP) y la TCU. El comando para abrir este puerto es:

OSmon> uselocalsftp on

En segundo lugar, abrimos una sesión SW que permita lanzar los comandos de carga del SW interno a la TCU. A esta sesión le damos un nombre y una vez abierta, lanzamos el comando de carga de SW, el comando download. Para ver el progreso de la carga de SW usamos el comando getswsessionstatus. Debemos esperar hasta obtener con este comando que el download se ha completado. A continuación activamos el sobre cargado a al TCU con el comando activate. En este momento la TCU se reiniciará por lo que perderemos la conexión. Por último debemos cerrar la sesión SW con el comando endswsession.

Se detalla el proceso por comandos:

OSmon> startswsession <nombre de sesion> OperationSucceeded





OSmon> downloadsw <nombre de session> sftp://tcu:[email protected]/siu02_sw.tar OperationSucceeded

OSmon> getswsessionstatus <nombre de session> DownloadInProgress Esperar hasta que acabe OperationSucceeded OSmon> getswsessionstatus <nombre de session> DownloadCompleted tsOperationSucceeded OSmon> activatesw <nombre de sesion> OperationSucceeded

OSmon> endswsession <nombre de session> OperationSucceeded

Podemos comprobar si se ha activado el Nuevo SW interno con el comando rev.

ABLOLLANO000021-OSmon> rev------------------- OSE modules ------------------------------------------oam.chk Operation & Maintenance R1AA01secmgrr.chk Security Manager R1Z04inetr.chk MLPPP Daemon R1V01ltp.chk Local Terminal Port R1Z04snc.chk Synchronization R1Y01pd.chk Packet Distributor R1Z04cesopsn_pwr.chk Circuit Emulation Service R1V01hdlc_pwr.chk HDLC Pseudo-Wire Emulation R1Z04p_relayr.chk Packet Relay R1Z04profiler.chk System Profiler R1G03hwtest.chk Hardware Tester R1V01lcf_cp.chk Local Connectivity Function R1C01bsp.drv Board Support Package R1X02bootstrap.chk Bootstrap R1V02loader.drv Software Loader R1A37np_init_app.drv APP3K Setup R1Z04linuxload.drv Linux Loader R1V01


------------------- Software archives ------------------------------------Primary:OSE CXP102165_2 R1AA02 -> ActualizadoLinux - R1AA02

Backup:OSE CXP102138_2 R2Z11



Después del upgrade de software, hay que dejar el mismo paquete no sólo en “Primary” si no también en “Backup”.

6.2 Carga de SW en Plano Backup:

Chequear con rev:

ABLOLLANO000021-OSmon> rev------------------- OSE modules ------------------------------------------oam.chk Operation & Maintenance R1AA01secmgrr.chk Security Manager R1Z04inetr.chk MLPPP Daemon R1V01





ltp.chk Local Terminal Port R1Z04snc.chk Synchronization R1Y01pd.chk Packet Distributor R1Z04cesopsn_pwr.chk Circuit Emulation Service R1V01hdlc_pwr.chk HDLC Pseudo-Wire Emulation R1Z04p_relayr.chk Packet Relay R1Z04profiler.chk System Profiler R1G03hwtest.chk Hardware Tester R1V01lcf_cp.chk Local Connectivity Function R1C01bsp.drv Board Support Package R1X02bootstrap.chk Bootstrap R1V02loader.drv Software Loader R1A37np_init_app.drv APP3K Setup R1Z04linuxload.drv Linux Loader R1V01






Verificamos en el printado anterior que el Sw cargado en el Plano Backup es distinto al cargado en Primary y tenemos dos opciones para actualizar. Se recomienda realizar la Opción de Comando. Esta opción es una nueva implementación de comando en esta nueva Release Sw de TCU. (Sólo disponible a partir de T13).

6.2.1 Por Comando SW (aprovesw):

Se trata del comando “aprovesw”.

Con este comando se copia el SW que tenemos cargado en el Plano Primary al Backup de forma automática sin tener que disponer de “sftp”. Importante saber que es posible ejecutarlo siempre y cuando queramos actualizar los Niveles SW de la TCU de forma que el Plano Primary quedará copiado al Plano Backup.

No existe impacto puesto que no realiza ‘restart’.

Se muestra situación Inicio y Final y los comando para su ejecución:Posición de Inicio:

ABLOLLANO000021-OSmon> rev ------------------- OSE modules ------------------------------------------oam.chk Operation & Maintenance R1AA01secmgrr.chk Security Manager R1Z04inetr.chk MLPPP Daemon R1V01ltp.chk Local Terminal Port R1Z04snc.chk Synchronization R1Y01pd.chk Packet Distributor R1Z04cesopsn_pwr.chk Circuit Emulation Service R1V01hdlc_pwr.chk HDLC Pseudo-Wire Emulation R1Z04p_relayr.chk Packet Relay R1Z04profiler.chk System Profiler R1G03hwtest.chk Hardware Tester R1V01lcf_cp.chk Local Connectivity Function R1C01bsp.drv Board Support Package R1X02





bootstrap.chk Bootstrap R1V02loader.drv Software Loader R1A37np_init_app.drv APP3K Setup R1Z04linuxload.drv Linux Loader R1V01





Procedimiento Comandos:

En este punto se abre Sesión Sw para preparar la TCU para la copia de SW entre planos. Cuando se ejecuta el comando aprovesw se va sustituyendo ‘*’ por ‘=’ hasta que termina el proceso. Se finaliza cerrando Sesión SW.

ABLOLLANO000021-OSmon> startswsession copyOperationSucceeded

ABLOLLANO000021-OSmon> approvesw copy[==================================================]OperationSucceeded

ABLOLLANO000021-OSmon> endswsession copyOperationSucceeded

Posición Final:











6.2.2 Por Server SFTP:

Se trata del procedimiento clásico volviendo a realizar otro download. Si existen problemas en el método anterior por comando, debemos intentar realizarlo por este procedimento:


OSmon> startswsession <nombre de sesion> OperationSucceeded

OSmon> downloadsw TCU sftp://tcu:[email protected]/tcu02_sw.tar OperationSucceeded

OSmon> getswsessionstatus <nombre de session> DownloadInProgress Esperar hasta que acabe OperationSucceeded OSmon> getswsessionstatus <nombre de session> DownloadCompleted

Podemos comprobar con el comando rev si en backup se ha cargado el mismo SW que en “Primary”

OSmon> rev







Terminar la Sesión de sw:

OSmon> endswsession <nombre de session>





OperationSucceeded

7 Carga de la configuración de la TCU.

La configuración de la TCU se realiza normalmente a través de un archivo xml. Este archivo contiene todos los parámetros y atributos de los mismos necesarios para el correcto funcionamiento de la TCU y del resto de equipos conectados a la misma (RBSs, equipos de transmisión,...).

Con esta configuración se definen, entre otras cosas, los E1 activos, cuáles de éstos van conectados a las RBS y cuáles a los equipos de transmisión, los interfaces IP (WAN,…), se habilitan los puertos Ethernet, y muchos más parámetros que se pueden estudiar abriendo el archivo xml de configuración. En este manual no nos detenemos ver estos parámetros, los cuáles son definidos por el grupo de diseño, y sí vamos a ver cómo podemos cargar esa configuración en el equipo.

A continuación vamos a describir el proceso de carga de este script en la TCU utilizando para ello el Server SFTP y teniendo en cuenta algunas consideraciones previas.





7.1 Consideraciones iniciales.

Si la TCU que se va a integrar contiene definición de MO’s, ya sean que vienen de fábrica o es reutilizada y dispone de MO’s creados, hay que tener en cuenta que es posible que el Script nos falle en el proceso de activación (Activate). En la mayoría de los casos, nos dará errores de ‘mib fault’ o de ‘parse error’.

En ambos, casos se hace necesario realizar un Reset a Valor de Fábrica, que se consigue realizar con el comando:

resettofactorysetting

Importante:

Este comando borra todos los MO’s, por consiguiente, toda la configuración que exista en la TCU. Además se ha detectado que en esta nueva versión SW se crean MO’s de Integración que provocan fallos de ‘Mib Fault’. Por tanto, se hace necesario, tras ejecutar el ‘resettofactorysetting’, lanzar el siguiente comando para el borrado de MO’s de Integración:

OSmon> deleteAiMoOperationSucceeded

Que se encarga de eliminar todos los MO’s de Integración y evita que se produzca conflicto con la carga de la configuración del Script.

7.2 Procedimiento Carga Configuración Script:

En primer lugar direccionamos el Server SFTP a la carpeta que contiene el archivo de configuración. Este paso ya lo realizamos anteriormente cuando enrutamos el Server SFTP hacia la carpeta que contenía el SW interno del nodo. Por tanto vamos a proceder de la misma manera esto es, modificamos las propiedades del usuario “TCU” que tenemos creado en el FreeFTPd de tal forma que en el campo “Home Directory” indicaremos la carpeta en la que está contenido el archivo de configuración xml.

Una vez direccionado el FreeFTPd, lo siguiente es conectarnos a la TCU y abrir su puerto SFTP que permita la transferencia de archivos entre Server SFTP y TCU. Para ello usamos el comando:


Para comenzar la carga del archivo de configuración tenemos que abrir en la TCU una sesión.

OSmon> startsession <nombre de sesion> OperationSucceeded





El commando que comienza la carga del archivo xml es el siguiente:

OSmon> download tcu sftp://tcu:[email protected]/CCGARGFUE001931STNSiteInstall.xmlOperationSucceeded

Para comprobar el estado de la transferencia usamos el siguiente comando:

OSmon> getsessionstatus <nombre de session> DownloadInProgress OperationSucceeded

Una vez finalizada la carga obtenemos el siguiente mensaje:

OSmon> getsessionstatus <nombre de session> DownloadCompleted

Sólo nos queda activar la configuración cargada:

OperationSucceeded OSmon> activate <nombre de sesion> OperationSucceeded

En este punto la TCU se reiniciará y se perderá la conexión con ella. Una vez ha finalizado el reinicio, nos conectamos y finalizamos la sesión anteriormente abierta.

OSmon> endsession <nombre de session> OperationSucceeded

7.3 Consideraciones Finales

Si nos falla el ‘activate’ de la configuración del Script del punto anterior, tenemos que tener en consideración lo explicado en el punto 7.1. Si existen otros problemas, que impidan el ‘activate’ el Técnico debe guardar los log’s como se explica a continuación para futuros análisis.

Es necesario conectar en local y realizar DCG en la TCU. Una vez que dispongamos de la conexión, debemos guardar el log producido cuando ejecutemos el comando: (Información completa).

collectDCGInformation





Añadimos estos dos comandos:

syslog read -s event

syslog read -s system

Al tratarse de una Integración e instalación de un equipo nuevo, se hace importante, verificar que la TCU no presenta alarma. Si se detectan alarmas Revisar Siguiente Punto.

8 TroubleShooting. Verificaciones en caso de problemas.

8.1.1 Comprobación de puertos

Una vez cargada la configuración y conectados todos lo interfaces procederemos a comprobar el estado de todos los puertos. Los interfaces a comprobar dependerán de los escenarios de transmisión que tengamos en el emplazamiento.

En primer lugar chequeamos si todos los interfaces físicos se encuentran arriba. Para ello podemos usar el comando:

getmoattribute stn=0,E1T1Interface=all operationalstate: con este comando vemos si los interfaces E1, tanto hacia la RBS de 2G (E1= 0, E1=1 en algunos casos E1=2, E1=3) como hacia la RBS de 3G E1=2 y 3 están enabled.

ABLOLLANO000021-OSmon> getmoattribute STN=0,E1T1Interface=all operationalState STN=0,E1T1Interface=0; operationalState= enabled;STN=0,E1T1Interface=1; operationalState= enabled;STN=0,E1T1Interface=2; operationalState= disabled;STN=0,E1T1Interface=3; operationalState= disabled;STN=0,E1T1Interface=6; operationalState= disabled;STN=0,E1T1Interface=7; operationalState= disabled;OperationSucceeded

ABLOLLANO000021-OSmon> OperationSucceeded

getmoattribute stn=0, EthernetInterface=all operationalstate: con este comando vemos si los interfaces Ethernet están enabled.

ABLOLLANO000021-OSmon> getmoattribute STN=0,EthernetInterface=all operationalState STN=0,EthernetInterface=DUS1; operationalState= disabled;STN=0,EthernetInterface=DUS2; operationalState= disabled;STN=0,EthernetInterface=DUS3; operationalState= disabled;STN=0,EthernetInterface=DUW1; operationalState= disabled;STN=0,EthernetInterface=DUW2; operationalState= disabled;STN=0,EthernetInterface=Existing_DUW; operationalState= disabled;STN=0,EthernetInterface=MAN_E; operationalState= disabled;STN=0,EthernetInterface=MAN_O; operationalState= enabled;





OperationSucceeded


8.1.2 Verificar Alarmas

Getalarmlist nos da las alarmas de la TCU. Si hay alarmas, solucionar el problema si es posible y si no, reportar el problema, indicando la alarma y el site.

IMPORTANTE: TME va a definir por defecto todos los interfaces y MO’s para futuras ampliaciones, pues lo que tendremos que confirmar con Integración qué alarmas deberíamos solucionar.

ABLOLLANO000021-OSmon> getalarmlist STN=0,E1T1Interface=7;alarmId= 1;eventTime= 2014-06-25 T06:38:27;eventType= "communicationsAlarm(2)";perceivedSeverity= "minor(3)";probableCause= "x733LossOfSignal(329)";specificProblem= "E1/T1 Loss of Signal";additionalText= "LOS";

STN=0,Equipment=0;alarmId= 2;eventTime= 2014-06-25 T06:38:27;eventType= "equipmentAlarm(4)";perceivedSeverity= "major(2)";probableCause= "x733EquipmentMalfunction(315)";specificProblem= "Hardware Fault";additionalText= "Ethernet Interface hardware fault";

STN=0,E1T1Interface=2;alarmId= 3;eventTime= 2014-06-25 T06:38:27;eventType= "communicationsAlarm(2)";perceivedSeverity= "minor(3)";probableCause= "x733LossOfSignal(329)";specificProblem= "E1/T1 Loss of Signal";additionalText= "LOS";



STN=0,TGTransport=ABLOLLANO000021_ETB1;alarmId= 6;eventTime= 2014-06-25 T06:38:27;eventType= "communicationsAlarm(2)";perceivedSeverity= "major(2)";probableCause= "m3100ConnectionEstablishmentError(22)";specificProblem= "STN-to-BSC Link Down";additionalText= "The Primary Control Connection to the BSC is disconnected.";

STN=0,E1T1Interface=2;alarmId= 7;eventTime= 2014-06-25 T06:38:27;eventType= "communicationsAlarm(2)";perceivedSeverity= "warning(4)";probableCause= "x736OutOfService(347)";specificProblem= "E1/T1 unavailable time";





additionalText= "E1/T1 Interface in unavailable state due to set of consecutive SES events";

STN=0,E1T1Interface=3;alarmId= 8;eventTime= 2014-06-25 T06:38:27;eventType= "communicationsAlarm(2)";perceivedSeverity= "warning(4)";probableCause= "x736OutOfService(347)";specificProblem= "E1/T1 unavailable time";additionalText= "E1/T1 Interface in unavailable state due to set of consecutive SES events";



STN=0,EthernetInterface=Existing_DUW;alarmId= 11;eventTime= 2014-06-25 T06:38:27;eventType= "communicationsAlarm(2)";perceivedSeverity= "major(2)";probableCause= "x733LossOfSignal(329)";specificProblem= "Ethernet Interface Down";additionalText= "Ethernet Interface Link Down - physical port TN_H";

OperationSucceeded


8.1.3 Comprobación del archivo cargado en la TCU

Comprobar si la configuración se corresponde con nuestro emplazamiento. Para ello podemos lanzar los siguientes comandos y comprobar que efectivamente la TCU que tenemos es la de nuestro emplazamiento.

TFLPSTCRC007841-OSmon> getcontainment stn=0STN=0;STN=0,Bridge=1;STN=0,Bridge=2;STN=0,Bridge=3;STN=0,Bridge=4;STN=0,Bridge=5;STN=0,Bridge=6;STN=0,Bridge=7;STN=0,E1T1Interface=0;STN=0,E1T1Interface=1;STN=0,E1T1Interface=2;STN=0,E1T1Interface=3;STN=0,E1T1Interface=6;STN=0,E1T1Interface=7;STN=0,Equipment=0;STN=0,EthernetInterface=DUS1;STN=0,EthernetInterface=DUS2;STN=0,EthernetInterface=DUS3;





STN=0,EthernetInterface=DUW1;STN=0,EthernetInterface=DUW2;STN=0,EthernetInterface=Existing_DUW;STN=0,EthernetInterface=MAN_E;STN=0,EthernetInterface=MAN_O;STN=0,IPInterface=Abis;STN=0,IPInterface=OAM;STN=0,IPInterface=Synch;STN=0,IPv6RoutingTable=0;STN=0,MeasurementDefinition=0;STN=0,QosPolicy=0;STN=0,RoutingTable=0;STN=0,RoutingTable=0,IpRoute=2G;STN=0,RoutingTable=0,IpRoute=OAM;STN=0,RoutingTable=0,IpRouteSys=Abis;STN=0,RoutingTable=0,IpRouteSys=OAM;STN=0,RoutingTable=0,IpRouteSys=Synch;STN=0,Synchronization=0;STN=0,Synchronization=0,TimeServer=PTP1;STN=0,Synchronization=0,TimeServer=PTP2;STN=0,TGTransport=TFLPSTCRC007841_ETA1;STN=0,TGTransport=TFLPSTCRC007841_ETA1,SuperChannel=0;STN=0,TGTransport=TFLPSTCRC007841_ETA1,SuperChannel=1;STN=0,TGTransport=TFLPSTCRC007841_ETB1;STN=0,TGTransport=TFLPSTCRC007841_ETB1,SuperChannel=0;STN=0,TGTransport=TFLPSTCRC007841_ETB1,SuperChannel=1;STN=0,TempSensor=0;STN=0,TrafficManager=DUS1;STN=0,TrafficManager=DUS2;STN=0,TrafficManager=DUS3;STN=0,TrafficManager=DUW1;STN=0,TrafficManager=DUW2;STN=0,TrafficManager=Existing_DUW;STN=0,TrafficManager=MAN_E;STN=0,TrafficManager=MAN_O;STN=0,VLANGroup=DUS1;STN=0,VLANGroup=DUS1,VLAN=VLAN_Iub_3G;STN=0,VLANGroup=DUS1,VLAN=VLAN_OAM_4G;STN=0,VLANGroup=DUS1,VLAN=VLAN_S1X2;STN=0,VLANGroup=DUS2;STN=0,VLANGroup=DUS2,VLAN=VLAN_Iub_3G;STN=0,VLANGroup=DUS2,VLAN=VLAN_OAM_4G;STN=0,VLANGroup=DUS2,VLAN=VLAN_S1X2;STN=0,VLANGroup=DUS3;STN=0,VLANGroup=DUS3,VLAN=VLAN_Iub_3G;STN=0,VLANGroup=DUS3,VLAN=VLAN_OAM_4G;STN=0,VLANGroup=DUS3,VLAN=VLAN_S1X2;STN=0,VLANGroup=DUW1;STN=0,VLANGroup=DUW1,VLAN=VLAN_Iub_3G;STN=0,VLANGroup=DUW1,VLAN=VLAN_OAM_3G;STN=0,VLANGroup=DUW2;STN=0,VLANGroup=DUW2,VLAN=VLAN_Iub_3G;STN=0,VLANGroup=DUW2,VLAN=VLAN_OAM_3G;STN=0,VLANGroup=Existing_DUW;STN=0,VLANGroup=Existing_DUW,VLAN=VLAN_Iub_3G;STN=0,VLANGroup=Existing_DUW,VLAN=VLAN_OAM_3G;STN=0,VLANGroup=MAN_E;STN=0,VLANGroup=MAN_E,VLAN=VLAN_2G;STN=0,VLANGroup=MAN_E,VLAN=VLAN_Iub_3G;STN=0,VLANGroup=MAN_E,VLAN=VLAN_OAM_3G;STN=0,VLANGroup=MAN_E,VLAN=VLAN_OAM_4G;STN=0,VLANGroup=MAN_E,VLAN=VLAN_OAM_TCU;STN=0,VLANGroup=MAN_E,VLAN=VLAN_S1X2;STN=0,VLANGroup=MAN_E,VLAN=VLAN_Synch_TCU;





STN=0,VLANGroup=MAN_O;STN=0,VLANGroup=MAN_O,VLAN=VLAN_2G;STN=0,VLANGroup=MAN_O,VLAN=VLAN_Iub_3G;STN=0,VLANGroup=MAN_O,VLAN=VLAN_OAM_3G;STN=0,VLANGroup=MAN_O,VLAN=VLAN_OAM_4G;STN=0,VLANGroup=MAN_O,VLAN=VLAN_OAM_TCU;STN=0,VLANGroup=MAN_O,VLAN=VLAN_S1X2;STN=0,VLANGroup=MAN_O,VLAN=VLAN_Synch_TCU;OperationSucceeded


TFLPSTCRC007841-OSmon> getmoattribute STN=0 STN_Name STN=0; STN_Name= TFLPSTCRC007841;OperationSucceeded

En el atributo STN Name del mo STN=0 debe aparecer el nombre del emplazamiento.

8.1.4 Comprobaciones conectividad OSS y NEDSS.

Es necesario hacer las siguientes verificaciones:

1. Que existe conectividad con el OSS.

Para ver cuál es la IP del OSS al que tenemos que llegar:

OSmon> getmoattribute STN=0 wakeUpRegistrationSTN=0; wakeUpRegistration= 10.53.48.20;OperationSucceeded

Verficar que hay ping:

TFLPSTCRC007841-OSmon> ping -c 4 10.53.48.20PING 10.53.48.20 (10.53.48.20) 56(84) bytes of data.64 bytes from 10.53.48.20: icmp_seq=1 ttl=242 time=37.8 ms64 bytes from 10.53.48.20: icmp_seq=2 ttl=242 time=35.9 ms64 bytes from 10.53.48.20: icmp_seq=3 ttl=242 time=35.5 ms64 bytes from 10.53.48.20: icmp_seq=4 ttl=242 time=36.0 ms--- 10.53.48.20 ping statistics ---4 packets transmitted, 4 received, 0% packet loss, time 3004msrtt min/avg/max/mdev = 35.507/36.324/37.821/0.906 ms


El caso anterior es un ejemplo que existe conectividad. Os detallo un caso sin conectividad y las pruebas a realizar para determinar dónde puede estar el problema:

BALUCRECIA0000461-OSmon> getmoattribute STN=0 wakeUpRegistration STN=0; wakeUpRegistration= 10.53.48.20;OperationSucceeded





BALUCRECIA0000461-OSmon> ping 10.53.48.20PING 10.53.48.20 (10.53.48.20) 56(84) bytes of data.^C--- 10.53.48.20 ping statistics ---3 packets transmitted, 0 received, 100% packet loss, time 2000ms

BALUCRECIA0000461-OSmon>

Si hay conectividad con el OSS, la TCU debería normalmente ser integrada. Si no hay ping como el caso, debemos chequear la conectividad del siguiente salto del OAM, pero no implica que siempre sea responsabilidad de la red de TME.

BALUCRECIA0000461-OSmon> getmoattribute STN=0,RoutingTable=0,IpRoute=all STN=0,RoutingTable=0,IpRoute=OAM; instanceId= OAM;STN=0,RoutingTable=0,IpRoute=OAM; Active= true;STN=0,RoutingTable=0,IpRoute=OAM; destIpSubnet= 0.0.0.0/0;STN=0,RoutingTable=0,IpRoute=OAM; nextHopIpAddress= 10.34.10.1;STN=0,RoutingTable=0,IpRoute=OAM; forwardingInterface= STN=0,IPInterface=OAM;STN=0,RoutingTable=0,IpRoute=OAM; routeType= Static;STN=0,RoutingTable=0,IpRoute=OAM; admDistance= 1;STN=0,RoutingTable=0,IpRoute=OAM; disableConnectivityCheck= true;OperationSucceeded

BALUCRECIA0000461-OSmon> ping 10.34.10.1 PING 10.34.10.1 (10.34.10.1) 56(84) bytes of data.^C--- 10.34.10.1 ping statistics ---2 packets transmitted, 0 received, 100% packet loss, time 1001ms

Para determinar cuál puede ser la causa, debemos chequear si la Vlan OAM es leída por la TCU sobre el Puerto MAN:

BALUCRECIA0000461-OSmon> getmoattribute STN=0,VLANGroup=MAN_O,VLAN=VLAN_OAM_TCUSTN=0,VLANGroup=MAN_O,VLAN=VLAN_OAM_TCU; instanceId= VLAN_OAM_TCU;STN=0,VLANGroup=MAN_O,VLAN=VLAN_OAM_TCU; tagValue= 1460;STN=0,VLANGroup=MAN_O,VLAN=VLAN_OAM_TCU; tagged= true;STN=0,VLANGroup=MAN_O,VLAN=VLAN_OAM_TCU; depBridge= STN=0,Bridge=6;STN=0,VLANGroup=MAN_O,VLAN=VLAN_OAM_TCU; mode= normal;OperationSucceeded

BALUCRECIA0000461-OSmon> showMACFwTable allMAC Port tagValue Forward Timeout588d.09b4.6740 STN=0,EthernetInterface=MAN_O 1460 True 300588d.09b4.6740 STN=0,EthernetInterface=MAN_O 1750 True 3000000.0c07.acd2 STN=0,EthernetInterface=MAN_O 1700 True 3000000.0c07.acdc STN=0,EthernetInterface=MAN_O 1750 True 300588d.0912.fe00 STN=0,EthernetInterface=MAN_O 1460 True 300588d.0912.fe00 STN=0,EthernetInterface=MAN_O 1700 True 30000b0.ae03.2301 STN=0,EthernetInterface=MAN_O 1116 True 3000000.0c07.acf0 STN=0,EthernetInterface=MAN_O 1460 True 300044e.0679.1450 STN=0,EthernetInterface=DUW1 1700 True 300044e.0679.1450 STN=0,EthernetInterface=DUW1 1750 True 300

BALUCRECIA0000461-OSmon>





De esta forma, se puede concluir, que si la Vlan está en la tabla de la TCU, entonces la causa más probable es la pérdida de una ruta. Si la Vlan no está en la tabla de la TCU, la causa más probable es la pérdida de la configuración Vlan en la Transmisión. Es necesario, en ambos casos contactar con TME.

En resumen:

Si el ping no da respuesta, intentar resolver el problema y si no es posible reportar el problema, como “NO conectividad IP hacia el OSS.”

Si el ping se ejecuta correctamente, en este punto, remotamente desde el OSS dicha TCU debería ser accesible vía SSH.

Si hay ping y sin embargo no es posible la conexión remota vía SSH reportar el problema como “No conectividad SSH”.

2. Que existe conectividad con el NEDSS.

Para ver cuál es la IP del NEDSS al que tenemos que llegar:

TFLPSTCRC007841-OSmon> getmoattribute STN=0 systemClockTimeServerSTN=0; systemClockTimeServer= 10.53.48.100;OperationSucceeded

Verificar que hay ping:

TFLPSTCRC007841-OSmon> ping -c 4 10.53.48.100PING 10.53.48.100 (10.53.48.100) 56(84) bytes of data.64 bytes from 10.53.48.100: icmp_seq=1 ttl=241 time=41.3 ms64 bytes from 10.53.48.100: icmp_seq=2 ttl=241 time=39.0 ms64 bytes from 10.53.48.100: icmp_seq=3 ttl=241 time=39.2 ms64 bytes from 10.53.48.100: icmp_seq=4 ttl=241 time=39.2 ms

--- 10.53.48.100 ping statistics ---4 packets transmitted, 4 received, 0% packet loss, time 3003msrtt min/avg/max/mdev = 39.040/39.703/41.333/0.954 ms


Si el ping no funciona, intentar resolver el problema y si no es posible reportar el problema como “No conectividad IP con NEDSS”.

Si el ping funciona correctamente, la TCU debería tener fecha y horas correctas:

TFLPSTCRC007841-OSmon> gettimeCurrent Time [2014-07-07 13:23:41.653]TFLPSTCRC007841-OSmon>





Nota: la TCU tiene UTC time, que es 1 o 2 horas menos que en la Península Ibérica dependiendo de si es horario de invierno o verano respectivamente.

Si la fecha/hora no son correctas (año 1970) volver a comprobar pasados unos 15 min, si no es correcto reportar el problema como “Conectividad con NEDSS pero timestamp incorrecto”

8.1.5 Comandos útiles.

Vamos a describir algunos comandos que nos pueden ayudar en la integración de la TCU.

- getalarmlist: obtención de las alarmas activas de la TCU.- rev: nos indica la versión de SW interno que está corriendo en la TCU.- getcontainmnet stn=0: no muestra todos los objetos creados en la TCU, esto

es, no muestra la configuración cargada con el archivo xml.- getmoattribute stn=0,E1T1Interface=all operationalstate: nos muestra el

estado de los E1 tanto los que están conectados a las RBSs como los que están conectados a los radioenlaces.

- getmoattribute stn=0,ML-PPP=0 operationalstate: se obtiene el estado del protocolo de comunicación TCU-PTN. Si este interfaz está disabled nunca habrá comunicación TCU-PTN aunque todos los puertos E1 estén enabled.

- resettofactorysetting: borrar la configuración de la TCU. Lo utilizamos para configurar una TCU previamente configurada. Si no borramos la configuración previa no podremos cargar un nuevo archivo xml de configuración a la TCU. (Excepto si es un modify).

- ping: realiza un ping desde la TCU a la IP que le indiquemos.- simpleping <ip origen> <ip destino>: realiza un ping a la IP destino indicada

desde la IP origen indicada.- traceroute <ip destino>: muestra las IPs de los equipos que hay entre nuestra

TCU y el equipo al que pertenece la IP destino.

configuración tcu.doc

Documents