0% ont trouvé ce document utile (0 vote)
240 vues7 pages

Suivi des Transferts et Alarmes Nokia

Ce document contient de nombreuses informations techniques sur des projets et problèmes liés à des équipements réseau. Il y a des mises à jour sur des transferts de sites, des upgrades de logiciels, des alarmes et des problèmes techniques qui nécessitent une investigation ou résolution.

Transféré par

Abdourahmane Ba
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
240 vues7 pages

Suivi des Transferts et Alarmes Nokia

Ce document contient de nombreuses informations techniques sur des projets et problèmes liés à des équipements réseau. Il y a des mises à jour sur des transferts de sites, des upgrades de logiciels, des alarmes et des problèmes techniques qui nécessitent une investigation ou résolution.

Transféré par

Abdourahmane Ba
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

=> relance faite auprès de l’UPR W

=> bien faire les mêmes vérifications avant toutes reprises en exploitation, surtout coté SE
-> suite aux premiers transferts blanc W50 : bcp de sites vides : responsabilité coté UPR et Nokia,
mais en majorité UPR.
-> on passe tout de même les transferts de resp coté DERS , mais activation de l’UPR en cas d’inter
COMET
-> travail bien avancé coté UPR, docs plutôt à jour
> réserve sur les infos BDE lors de transferts, en cas d’incident on leur envoi le tk
 09/05 : demande d’intégration des LL des sites 3G
 27/06 : prise en compte des fichiers LL en cours pour la 3G
 08/08 : mise en production de la version intégrant les LL 3G

RET :
En partant avec un SI propre, est que l’on lance l’exploitation des RET sur NOKIA ?
présentation de ce qui est en place sur E// et voir avec les UPR si ok pour partir la dessus @ Julien
-Formations en cours coté Econocom nokia, sbts throubleshooting => suivi par l’équipe Nokia
-Immersion pilote econocom dans les locaux orange => prévoir une date avec plus d’inter
-supervision via QS uniquement, et WS à supprimer
-Mise en place des fiches alarmes Nokia pour présentation Econocom début janvier
-RAS suite aux premiers passages des sites sous resp. Orange
-inter aérien des sites sous resp nokia => il faut voir directement avec PMP

-alerte sur les FDW ou swan non initialisés


-reprise activité pilotage par le CDS : W27 sur les inter modules radio et investigations antennaires
=> Comment va être géré l’entrée PABX => prise du SVI le 03/07 par econocom
-suivi des alarming Pre Prod / maquette : OK pour les sortir de la supervision QS
-plan canicule : tempo mise en place sur l’été : Com faite auprès de NOKIA pour attendre 72H
-modifier les fiches alarmes pour préciser l’utilisation des FICHES EXPLOITATION
-KINSEI bien appeler le pilotage Orange
-MAJ des FE version SRAN17 + doc airscale => voir le wiki
-possibilité de faire des tests de boucle en TDM/ATM ? voir avec P2S lors des appels OWF
-SWAN pas commencé lors des interventions : relance faite vers l’UPR SE
-Appel pour le NOC mal routé et arrivent coté Econocom : à surveiller
-exemple de site passé chez orange mais tjrs en zzz et sous noria en resp noria : Brest_jaures
-Attention lors de la sup HNO : bien faire le routage entre les incidents traités par Econocom et ceux
traités par Orange
- Suite aux transferts de sites les tickets sont repris avant transfert ce qui désactive les activations en
cours => Gabriel regarde si cela pose un problème aux comet
-alerte sur les alarmes SRAN16 qui restent bloquées car le mode maintenance est activé après les
premières actions
-Faire attention aux sites en mode maintenance, bien vérifier qu’il soit en service. , ex : 1810N40175
-lock 2G en MML tres long cell par cell , privilégier le lock BCF
-surveiller lenteur des lock 3G : exemple à étudier
-script rx level en attente sur WE2/SE2 => OK
-surveiller les modifications ZZZ_ -> SBTS_
-transfert du traitement de nouvelles alarmes en pilotage depuis W01
-2eme partie des transferts d’inter à partir de W07-08 (ALD,…)
-alerte sur les tk qui sont clos de manière trop rapide : exemple cloture lors d’une inter spie pour re-
enclenchement disjoncteur. Point remonté à Nokia par Tristan
-alerte lors d’un ER , problème pour recontacter Econocom par l’ingénieur Nokia, vérifier le numéro
donné : bien donner le numéro direct du groupement
-Rappel à faire au HNO sur les tk RET à ne pas traiter
-Script Rx level, si pb de lancement nous remonter le point pour supprimer la clé ssh sauvegardée (pb
qui arrive suite au changement de la carte système d’un site)
=> nvlle erreur sur le script SUPER_CANNES_BIS
-petit rappel FC MHA à faire

Point droits netact à affiner:


-point à monter avec Vincent courant septembre
-autorisations support sur les personnes du oneroof
-MAJ du group OFR PILOTAGE : ajout des droits pour l appli site configuration tool

Alarmes externe :
-modification des criticités en cours
-point en cours sur overlay 4G et reprise lrcab
alarmes externes des baies énergies remontées sur fseb et alarmes externes classiques sur falu
-présentation FC Tristan : mise à dispo sur le wiki
-Alerte sur le nombre de tk alarmes externes : environnement
=> Faire un bilan des premières interventions (listes des tk, analyse des inter, pb d’installation ? pb
connu ?)

-Beaucoup de reprise de l’existant fALU (pb boucle, config en mineur)


-point fait avec l’UPR : véifier les criticités dans leur macro de generation scf
-pas mal d’alarme point à faire entre Econocom et Env . techn => vague de froid W9
-harmonisation des règles de filtrages/tempo (48h) des alarmes température sur Nokia
-pb de rupture de stock bornier WAGO début 2018 => résolu, reprise des sites en cours
-Le NOC Nokia arrive à saturation, certains sites peuvent donc être transférés avec des alarmes
externes présentes en réserve. Si défaut avéré coté baie Nokia, on leur retourne le tk
-Alarme externe sur BBU airscale : changement des numéros à étudier : test ok sur le live
- mail d’alerte remonté 06/12 sur alarmes airscale avec fseb
- MAJ faite sur le réseau sur les ID des alarmes ext, à surveiller
- Alerte de Tristan sur les criticités des alarmes mineurs

SWAP :
Phase 1 : pas de fin avant 2018
Phase 2 : dérogation de démarrage W42, Go officiel W46
4Gonly : démarrage W42, possibilité de transfert site à site dès W50
 tests sur le SI pour préparation au transfert de responsabilité
 DOE en cours de finalisation sur les 4GOnly => OK W52,
 test de transfert à blanc de 50 sites le 20/12/2017
 premiers transferts à Orange => S4 > OK
 en attente du script Rx level pour un lancement massif
o présentation sur Netact W/SE, FC présente sur le WIKI
 MDR prévue en S7 : 13/02 pour BSC / RNC Lyon : RNC fait
 NETACT -> point en cours sur les recettes NO GO W05, et tk OK W24
 Alerte sur :
o le PR 77 sleeping cell 2G (en attente de log)
o PR 75 pour cell 4G down sans alarme, paramètre ActiveBBflex à préciser
o en MP4.01 : alerte les ref MHA incompatibles
o problème de purge de BCKP sur les RNC => modification des command calendar pour
séparer la bckp de la purge. Fait sur tout le réseau, à vérifier lors des intégrations
o PR69 : limitation sur les sites en 2M, attente IPSATION
o PR60 : instabilité des sites tdm suite à un reset, reproduire le pb
 suivi des mauvaises installations, exemple par mail
 4Gonly : ok pour transférer avec RPS (photos) et on laisse le DOE à faire lors du swap 2G/3G
=> transfert de 150 sites W20
 début de reprise des 4G only par Nokia, alerte sur les qualités d’installations Orange
 750 DOE « light » proposés au transfert, avec version finale du DOE à livrer avant fin 2018,
vérifiée par l’UPR
o 1ere vague de 100 en W30 => 69 acceptés
o 2eme vague de 150 en W32 => 91 acceptés
o 3eme vague de 200 en W34 => 46 acceptés
o 4eme vague de 200 en W35 => 37 acceptés
o bilan => transféré 344 / nok doe 299
 fin des transferts de Milieu de Réseau
-W15 + de sites en exploit Orange que NOC

Kinsei :
On récupère les 13 sites de Villefranche
Point à monter pour étudier la supervision airscale : point 01/09
 Lien entre QS et ST1 non configuré, adaptations nécessaires coté QS/NORIA, à mutualiser
avec la 17.8 ?
 nécessité de remplir noria pour ces 13 sites, mais pas prévus
- lien dans SAMI pour le ST1 à mettre en place
-bilan des sites cleaning : liste des tickets et incidents liés
-W43 upgrade en cous NETACT ST1 plus MRBTS
-W44 création de la fdd7 en 3G 2100, + extinction FDD12 pour visualiser impact client
-W46 création cell LTE 2100
-W48 2eme fibre installée sur les modules 2100
-W49 : Upgrade en SRAT17A load P8 de l ioms et les enodeB
-W51 : premiers tests de catM en cours, mais des problèmes sur les mobiles
-W05 : upgrade des sites 4G en FDD-LTE 17A 0.2
-W08 : visites sites pour étudier l’environnement sonore en fonction des profils de ventilations
-W13 : upgrade Netact
-W14 : upgrade SRAT18 sur 1 sites : Nok pb d ipsec en cours => résolu suite MAJ Certificat coté SGW
-W17 : upgrade 11 site en SRAT18
-W25 : tests de débits non atteins, restitution sur le cat-M fait le 19/06
-PMR en cours d’étude
-tests de débits liaisons à prévoir : 16-17-18 / 07
-alerte sur une chute de pagging, ok suite reset, à garder en obs

77xx:
-FC détection chaine de bout en bout SBtS KLM
- alarmes de non configurations des liaisons masquées => il reste 350 alarmes dans le calque 77XX
-mail de qualification des alarmes pour phare :
-passe de SAR8 à sarM pour les sites bas de réseau
=> Point en cour sur les alarmes : document envoyé par nokia
-reunion le 15/03 ->
 7750 la listes alarmes de la MIB est actée par elr et transmis entre : routeur -> phare
-> BEM -> QS
o pb en cours : soupçon de dé séquencement : alarmes bloquées dans QS
o champs resp dans noria des routeurs non envoyés à QS => mise en place 12
juin
 7705
o liste des alarmes MIB (1500) envoyée à Nokia pour sélection des alarmes
pertinentes, = > manque le nom d’alarme dans le fichier envoyé
 qualification des alarmes faite coté sup
o test de la chaine main/bckp routeur -> phare, pb de flux = > OK depuis
o flow d’alarme important entre 7705 et phare : sapCemPacketDefectAlarm
inhibée directement dans les routeurs. Travail en cours pour inhiber les
alarmes logiques et garder que la supervision des ports physiques
 pas faisable au niveau routeur, filtrage à mettre en place coté Phare : test W27
 Nokia doit aligner status admin et opérational down : attente état du réseau de routeur
 > fait W30 => mise en place des alarmes sous QS -> en Obs
o mise en service des alarmes dans QS le 07/06 > pb de plateforme > arrêt
immédiat
-test SI routeur avec nouvel EDS XFR110 à faire en W49 => OK, mais ID de la ressource pas très clair
=> Problème d’absence d’@IP sous noria => A jour
=> NORIA ne référence que les milieux de réseau, pas les 7705 bas de réseau
=> Problème de nom pour les routeurs d’Annecy : corrigé
-> coté SI comment identifier les sites avec routeur ?
* Récupérer la conf des routeurs 7750 pour extraire les lignes ATM/TDM
* à ajouter au wiki
-> création d’un calque Orange responsabilité
-> Droits de visu à vérifier coté Econocom : QKHT7165
- visite site sur un routeur 7705 bas de réseau : FC / FM présente sur le wiki
- comment sont prises en compte les deconf 77xx lors des passages en IP => procédure à établir
-les routeurs 7750 rentrent dans le contrat de maintenance avec Nokia, comme les 7705 => contrat
OK , passage de 4 routeurs le 29/05 , passage de 8 nouveaux routeurs 7705 en W34
-attente de procédure standard en cas d inter sur site => procédure fournie W39 , à relire
-> procédure envoyée au CDS pour tester la récupération du fichier de conf
-> pb de recupération des fichiers depuis le sam sans le disque reseau, WA à travailler
-cactus en cours
-> Incident routeur sur OrleanSV => chaine de soutien complexe
 Vendredi => chgmt de carte coté routeur => bagots visibles sur les BSC Alu
 Nouvelle dégradation au cours du WE => difficulté à joindre les bons interlocuteurs
 Lundi -> Inter sur les routeurs par Nokia
RAI sur l’incident de NANTES prévue 06/02 => process à clarifier, présentations du process à prévoir

Réparation :
Demande de MAJ des FSMF en 16.10 et modules milieu réseau
 retour positif de nokia sur la fsmf, en attente de la partie contractuelle
-proposition commerciale faite et acceptée pour les 90 premières cartes
-go pour upgrade en SRAN16.10
-étude en cours pour upgrade par CTDI (60E par carte)
 BCN attente retour sur la gestion de la maintenance et upgrade palier
-retour officiel : BCN identiques en 3G/2G, procédure d upgrade envoyée, plusieurs alertes
en cours,
=> Problème de compatibilité entre BCN RNC et BSC et problème de mise à jour de notre
version eSW qui est trop ancienne
=> négo en cours pour faire faire le remplacement des châssis par Nokia
HW version des cartes NOKIA imposent une dépendance fonctionnelle => on en met pas en
place de notre coté
 depuis fin 2017 les SW usine des FSMF sont passés en version 2.0 => BTSMANGER2.0 dispo
sous le wiki, envoyé à CTDI
 test des cartes CTDI sur pre prod => NOK cartes en SRAT16
 en attente de 2 nouvelles cartes => reçues le 24/04
Premiers envois fait, pas de problème particulier, point analyse technique (FF/NNF) à acter avec
Nokia
-alerte sur FXDD (900) coté SWAP sur un grand nombre HS sur SE
> Attente du SRAN17-2.3 pour évolution de la gestion de puissance sur les amplis
> 1 nouvelle occurrence coté W le 19/02, à surveiller
-alarmes TX of Order vues en gd nombre coté pilotage sur FXED
- alerte sur les consommations de SFP Nokia : bien les remettre en stock en cas de test non concluant
- A surveiller les FDP Airsecale avec les pb de BB Bus error vue entre les cartes sur la partie gauche,
mais OK sur la partie droite. 2 cas vue de notre coté. la_baule_christina a surveiller
- Cartes en retour de réparation mises en SRAN17 depuis 02/2019 par CTDI

Chantier alarmes :
Criticité et pertinence à suivre : Gabriel en point d’entrée
-suivi des alerteurs suivant :
19134 : alarme faisant la concaténation des alarmes 7104 sous cause 134 (écart main div de 4db) qui
sont présentes pendant 8 h. Attention cette alarme ne se clear pas, il faut le faire manuellement
 les alarmes 19134 sont à activer coté ORANGE depuis W09 => pas d’équivalent, mais passage
de l’alarme 7104 – 134 en informing delay de 26000s
 chantier QS alarming (Persée) lancé
 Attention à la version SRAN17
o premier fichier rempli avec les alarmes déjà vues, évolution en cours
o FA en cours de création

Suivi problèmes :
-2 cartes à changer sur rennes BSC & RNC + 3 tombées suite aux upgrades : 2 PR ouverts
=> 1er retour : 1 des cartes était HS mais sans alarme et l’alarme serait remontée suite au
reset. Carte BMPP2 changée sur Clermont le 07/01 par Laurence, nouvelle inter même pb =>
ouverture d’un PR qui confirme le pb BCN => inter le 13/03 : OK suite remplacement BCN
=> test de chgmt de carte MDR à faire sur la pre prod : sur site BSC le 04/10
-> procédure testée, mais la carte n’est pas montée, nouvelle carte à tester 25/10 nouvel
echec, retour sur site le 31/10 => carte OK avec la même procédure
-> test carte supportant l’OMU et remplacement Disque => 07-08 / 02
-alerte sur les paramétrages BTSMED/DNS => valeurs spécifiques par netact
-sites bloqués en reseting => WA faire un reboot SSH, script mis en place sur les OSS
=> 35_FC_RAN_NOKIA_Reboot [Link]
-Pb sur les BTSMediator qui sont en saturation en nombre de cell : limite à 11K => perte de la sup de
milliers de sites le 17/10 sur SE => WA de reset de site par script Nokia
-> upgrade cpu et RAM des VM Mediator => fait, limite à 12K
-> MAJ des BTSMediator en version 2.1 => fait, limite à 16K
-> validation express du load 17.3MP2.1 => NOK
-> ajout des Netact SE2 et WE2 qui va donner de l’air aux mediators
-Nouvel incident : suite TP BIOM et passage d’un script TLS par nokia sur SE
=> perte de l’enregistrement de 100-200 sites sur SE1 et WE1 – résolu apres ER le 22/01 23h
=> Sur SE1 il reste entre 60 et 100 sites qui sont enregistrés NE3SW mais pas connecté au
BTSMed, analyse coté Nokia
-Suite uprgade du BTSMED17A 2.3.1 perte d’une trentaine de sites => application WA + duplication
des PM ce qui a impacté OSIRIS => rappel apres de Nokia pour appliquer leur script de purge
-nouvel Incident le 29/01 => perte de l’OAM au niveau national, suite retour au routage initial il reste
165 sites bloqués => ouverture d’un ER pour appliquer le script NOKIA de toggle TLS
-Saturation du tronçon CEM2/3 sur la zone de GRENOBLE, impact fort sur la 3G lors des busy hour en
station => corrigé par upgrade du lien de 10Gbps->20Gbps
-Disparition du BCKP sur LYONLA1 , réactivation du cronJob et libération d’espace mémoire, alarme
existante ?
-incident sur CHASSIEU_EUREXPO => pb suivi par nokia depuis novembre : perte de l’asia et des cells
4G => inter le 28/01 pour downgrader la baie et modifier le cablage, puis le 29/01 pour changement
de l’ASIA/1 et ABIA/3 => OK suite au chgmt de l’ASIA
-Alerte sur le scripts Rxlevel, qui ne fonctionne pas suite a un changement de FSM, la nouvelle clé
RSA n’est pas connue, il faut la mettre à jour.
-ER booting failure sur RNC LYONLA , RAS depuis
-Dégradation CSSR DATA sur 2 BSC de NICE => WA reset des PCUM, PR fait mais pas de trace,
nouvelle occurrence sur Clermont (nouvelles traces envoyées).
=> RCA donnée, pb sur les processeurs impaires avec des buffer en overlow au bout de 248 jours
-RNC MARSEILLE_RN2 dégradation CSSR CS 05/03 : WA reset USPU
-BSC Clermont_BN_1 : impact data sur 50 sites suite auto restart PCU le 23/03 sur PCU 0/1, mauvaise
reprise => WA reset PCU 3 le 25/03 et il restait 10 sites impactés => reset PCU 0 le 26/03
- BSC ROUENM_BN_1 changement carte ETMA(BMPP2) ok (13/03)

Vous aimerez peut-être aussi