Problème de dégroupage ?

Newsgroups : proxad.free.adsl

Subject : Re : probleme inversion

From : [email protected] (Alexandre Archambault)

Date : Wed, 28 Jan 2004 12:40:34 +0100

Message-ID : <1g89qy4.d2cyp1dszrcwN%[email protected]>

References :

MIME-Version : 1.0

Content-Type : text/plain ; charset=ISO-8859-1

Content-Transfer-Encoding : 8bit

Organization : Free

X-No-Archive : yes

Mail-Copies-To : never

X-Computer : Powered by Apple Powerbook G4 Ti & X.3

X-Location : F-75008 – ANJ

X-Langage-Code : no

X-Face : #h,.ZXp6tB+M=E\ !O+hlFcN.vny%3H21eJ8a@&9Rdlzu&zXW\IfPXdm^C/,.:IGrQ@ocrMzCF#@hUE*xzWV0dW

Xref : news.free.fr proxad.free.adsl:208821

Selon jimi dans l’article  :

> il faut combien de temps pour régler un problème d’inversion

> de ligne une fois que le tichet d’incident a été envoyé ?

En *moyenne*, 38 jours.

Ces délais sont essentiellement dû non pas à une mauvaise volonté de FT

comme on peut parfois le lire ici ou là, mais avant tout au fait que FT

ne dispose pas (encore) des bonnes procédures pour identifier et

résoudre efficacement, c’est à dire rapidement, les problématiques

d’inversions de câblage.

En effet, les techniciens dans les répartiteurs se contentaient jusqu’à

présent de faire qu’un simple test de synchro sur les lignes en

inversion, ce qui ne servait à pas grand chose, car si cela permet de

s’assurer qu’il y a bien une continuité métallique entre 2 équipements

(modem ADSL <=> DSLAM), cela ne permet nullement de déterminer

l’allignement d’une ligne, à savoir si une ligne donnée est bien

dégroupée sur le bon opérateur sur la bonne tete de renvoi sur le bon

plot de renvoi.

Concernant cette problématique, Free a mis à disposition des équipes

terrains de FT une plateforme leur permettant d’accéder aux logs DSLAMs

qui permet donc de déterminer si la ligne sur laquelle le technicien FT

observe une synchro arrive bien au bon endroit (car si la plateforme

annonce « ligne non synchronisée » ou « ligne synchronisée » mais avec un

affaiblissement annoncé incohérent avec celui d’une ligne shuntée au

répartiteur – la traversée d’un NRA représente en moyenne 7 dB – soit le

renvoi est pourri, soit c’est une inversion avec une autre ligne). Mais

comme le syndrome du NIH (Not Invented Here) est assez répandu chez FT,

il faut du temps pour que cela puisse faire l’objet de ce qu’ils

appellent une « procédure métier », à savoir la généralisation dans les

NRA dégroupés. Mais il est un fait indéniable que sur les quelques NRA

qui recourent d’eux-même à cette plateforme de test, les délais de

rétablissement ont été considérablement réduits car traité efficacement

dès le premier ticket.

D’autre part, l’essentiel des délais découlent avant tout de délais

administratifs, car en l’absence d’interconnexion directe des différents

SI concernés, tout ce qui est envoyé au GAMOT est retraité manuellement

par les équipes du GAMOT, resaisi dans le SI interne de FT qui le

dispatche ensuite aux conduites d’activités locales concernées.

Résultat, entre le moment où une signalisation est déposée au GAMOT et

celui où ce dernier en accuse réception (en fait, l’OK AR du GAMOT

signifie que la signalisation a été transmise aux conduites d’activités

locales), il peut se passer jusqu’à 10 jours sur chaque signalisation,

et comme l’expertise nécessite au préalable 2 tickets…

FT travaille à l’adaptation de son SI (en fait, de ses nombreux SI, et

comme chez FT les cycles d’implémentation s’évaluent en semestres voire

en années, il faut être patient) pour l’ouvrir aux opérateurs afin que

ces derniers puissent s’y interconnecter en vue de déposer directement

les signalisations et de les tracer en quasi-temps réel.

Sur ce premier point, à savoir le dépôt de signalisation (un peu comme

c’est déjà le cas pour le système de commandes de lignes ADSL et

dégroupées où les différents SI FT <=> Free sont interconnectés), c’est

en cours d’implémentation et en période de test. Sur le second point, ça

devrait pouvoir être effectif d’ici la rentrée prochaine.

Alec,

—