Managementul Reţelelor SDH - Teorie Şi Implementare Practică

www.cartiaz.
ro – Carti si articole online gratuite de la A la Z
Managementul reţelelor SDH – teorie şi implementare

practică
4.1 Managementul reţelelor SDH – prezentare teoretică
4.1.1 Prezentare generală
În capitolele precedente au fost prezentate principiile ce guvernează

sistemele de management al reţelelor numerice integrate. Dintre acestea au
fost evidenţiate sistemele de management pentru SS7 şi reţelele de
management ale telecomunicaţiilor (TMN). Folosind ca bază teoretică de
plecare informaţia referitoare la aceste două sisteme poate fi studiat şi cazul
particular al managementului SDH.
Reţeaua SDH asigură suportul de transport pentru TMN, utilizând
canalele DCC (”Data Communication Channels” – Canale de comunicaţii de
date) [G.831]. Pe aceste canale, fluxul informaţiilor de management se
transmite utilizând un protocol de legătură de date, LAPD [Q.921], un caz
particular al HDLC, asemănător protocolului folosit pentru sistemele SS7,
descris şi în această lucrare.
În [VON98] a fost descris modelul fizic şi logic pe care este structurată o
reţea SDH. În continuare, va fi descris modelul de management al unei
asemenea reţele.
În fig. 4.1 este prezentat un exemplu de reţea SDH care are încorporat şi
propriul sistem de control şi management.
SDH conţine un sistem integrat de management al reţelei, distribuit atât
la nivelul echipamentelor de reţea, cât şi în puncte centrale de gestiune.
Transportul informaţiilor de management între toate aceste noduri se poate
face fie prin intermediul canalelor de comunicaţie integrate în reţea EO
(“Embaded Overhead” – Redundanţă încorporată), fie prin intermediul unor
canale auxiliare special destinate acestui scop.
Conform recomandării G.831 a ITU-T managementul automat al SDH
trebuie să aibă capacitatea de a asigura:
 interacţiunea automată între reţelele de transport administrate de
operatori de reţea diferiţi;
 operarea automată a unei reţele deservite de un operator unic, dar ale
cărei echipamente provin de la furnizori diferiţi;
 optimizarea managementului unui domeniu unic de transport SDH
(furnizor unic, operator unic).
Din această perspectivă, obiectivele pe care şi le propune sistemul de
management al reţelelor SDH pot fi enunţate prin intermediul a şase principii
generale:
1. capacitatea de a stabili, la cerere, un număr de n căi de transport între
două puncte de acces al clienţilor;
131
www.cartiaz.ro – Carti si articole online gratuite de la A la Z
2.capacitatea de a menţine, pentru aceste căi, a unei calităţi înalte a

serviciilor, ceea ce presupune şi capacitatea de refacere automată a căilor
defecte;
3. capacitatea de a furniza monitorizarea permanentă a performanţelor
căilor alocate, atât timp cât acestea se află în serviciu;
4. capacitatea de a asigura o mentenanţă simplă de la distanţă atât în
interiorul unui domeniu gestionat cât şi la graniţa dintre două domenii diferite,
ceea ce presupune identificarea şi localizarea echipamentelor defecte;
5. capacitatea de a genera informaţiile privitoare la alocarea şi utilizarea
resurselor, informaţii necesare ca suport pentru rutare, contabilizare a costurilor
şi planificare a configuraţiei;
6. capacitatea de a furniza suport pentru asigurarea funcţiilor de
management auxiliare, ca de exemplu cele de: inventar, planificare etc.
NM NM
afluenţi
…
ADM MUX
NM
…
…
DCS
NM
 conexiune fizică
afluenţi
MUX  Informaţii de redundanţă încorporată
 Canale auxiliare dedicate

managementului de reţea
Semnificaţia notaţiilor folosite:
MUX  (Multiplexer) = Multiplexor

ADM  (Add Drop Multiplexer) = Multiplexor de inserţie-extracţie
DCS  (Digital Cross-connect System) = Sistem digital de interconectare
NM  (Network Management) = Management de reţea
Fig. 4.1. Exemplu de sistem de management al SDH
Succesul stabilirii unei căi între două puncte de acces depinde în mod
esenţial de respectarea unui mod de identificare unic al acestora din urmă.
Aceasta implică existenţa unui număr global unic de identificare pentru fiecare
punct de acces, care să nu se modifice atâta timp cât nodul respectiv se află
inclus în reţea. Numărul de identificare trebuie să conţină informaţii pe baza
cărora să poată fi determinat operatorul căruia îi aparţine nodul respectiv, cât şi
reţeaua din care face parte. Setul identificatorilor punctelor de acces din cadrul
unei reţele trebuie să asigure o schemă unică de identificare, independentă de
132
schemele similare utilizate în alte reţele. Modul de construire a acestei scheme

de identificare este reglementat în [E.164], iar localizarea şi codarea
identificatorilor punctelor de acces este descrisă în [G.709].
În cadrul unei reţele de management a SDH, funcţiile primare de
management se ocupă, în principal, cu stabilirea, validarea, monitorizarea,
protejarea şi refacerea legăturilor între două noduri de acces.
Pentru stabilirea căilor, structura de control trebuie să asigure prelucrarea şi
transportul mesajelor între procesele de control diferite implicate. Ea operează
cu două tipuri distincte de mesaje, specifice oricărei structuri de control
ierarhizată pe nivele funcţionale (fig. 4.2):
 mesaje transferate între procesele de control situate pe nivele înalte şi
procesele controlate de acestea, situate pe nivele de bază;
 mesaje transferate între procesele pereche situate la acelaşi nivel
ierarhic.
Nivel cale
Nivel secţiune
multiplexare
Nivel fizic Nivel secţiune
regenerare
Fig. 4.2. Structura de control pentru stabilirea unei căi
Poate fi făcută o diferenţiere între modul de stabilire a unei noi căi între doi
operatori de reţea distincţi sau în cazul unei aceleiaşi reţele deservite de un
unic operator.
Atunci când se stabileşte o cale între doi operatori de reţea distincţi pot fi
folosite două protocoale diferite, fie cel de rutare “pas cu pas”, fie cel al rutării
sursei, iar în cazul reţelelor deservite de un singur operator există trei metode
distincte de stabilire a unei căi.
 Metoda centralizată, presupune utilizarea unui punct central unic de
procesare, iar mesajele folosesc alte căi de transfer decât cele utilizate de
elementele reţelei.
 Metoda rutării “pas cu pas”, presupune folosirea unor protocoale de
rutare comune mai multor sisteme de semnalizare. Mesajele de control dintre
nivelele funcţionale implicate aparţin unei aceleiaşi entităţi de procesare.
133
Aceasta poate fi încorporată elementelor de reţea şi atunci va folosi

protocoalele proprii mediului SDH [Q.784], descrise în continuare, fie va fi
externă acestora şi atunci va folosi modul de adresare descris în [M.3010 şi
G.774].
 Metoda rutării sursei, în acest ultim caz, atât protocoalele folosite, cât şi
ruta aleasă vor fi stabilite la primul nod, acela care generează mesajul. De
asemenea, dacă controlorul de procesare se află în interiorul nodului vor fi
utilizate protocoale specifice SDH [G.784], iar în cazul în care acesta este
extern nodului, atunci va fi utilizat modul de adresare specific TMN. Această
metodă nu poate determina, în afara sub-reţelei în care este conţinut nodul
sursă, rutele utilizate, la acest nivel fiind necesare protocoale distincte de
stabilire a legăturii între operatori.
În capitolul precedent a fost descris atât sistemul de semnalizare nr. 7, care
stă la baza semnalizărilor dintre două reţele diferite, cât şi sistemul TMN, a
cărui metodologie de transfer a mesajelor poate fi utilizată cu succes în toate
ER A ER B DM SO
OA OA
FER-FMA FER-FMA DM-FMA SO-FMA
FCM FCM FCM FCM
Qx Q3
ER A, ER B  Element de Reţea A, B
OA  Obiect Administrat
FER  Funcţie Element de Reţea
DM  Dispozitiv de Mediere
SO  Sistem de Operaţii
FMA  Funcţie de Management la nivel Aplicaţie
FCM  Funcţie de Comunicaţii pentru Mesaje
Fig. 4.3. Exemplu configuraţie management SDH implicată în stabilirea unei căi
cele trei metode de mai sus, în cazul în care acestea folosesec drept nod de
control un nod situat în afara reţelei de transport a SDH. În fig. 4.3 este
prezentat un exemplu de configuraţie funcţională SDH specifică procesului de
stabilire a unei căi de comunicaţie între un controler de proces situat în afara
nodurilor A şi B între care este realizată calea.
134
Odată ce o cale a fost stabilită conform uneia din procedurile enunţate mai
sus, ea va trebui validată, ceea ce prespune transmiterea în bandă a codului de
identificare asociat punctului de acces conectat. Acesta va trebui validat la
celălat capăt al legăturii. Odată ce calea sau secţiunea a fost stabilită şi validată
ea va fi permanent monitorizată din punct de vedere al integrităţii mediului
transmis. Monitorizarea se poate realiza utilizând redundanţa de cale sau de
secţiune potrivită, aceasta fiind apoi permanent comparată cu o valoare limită.
Dacă performanţele transmisiunii vor scădea sub acest prag, atunci va fi
declarată apariţia unui nou defect. În cazul în care calea sau secţiunea
respectivă sunt protejate atunci va fi declanşată procedura automată de
refacere a legăturii, conform [G.803].
Au fost descrise până acum obiectivele generale ale managementului SDH.
În continuare, va fi prezentat modul în care aceste obiective pot fi realizate.
4.1.2 Suport de transmisiuni pentru managementul SDH
Aplicaţiile de management al SDH pot fi clasificate după aria de activitate,

ca fiind de două tipuri:
 aplicaţii de management la nivel de reţea;
 aplicaţii de management la nivel de echipament.
După cum a fost prezentat la începutul acestui capitol, informaţiile de
management pot folosi drept suport fizic pentru transmitere fie canalele de
comunicaţie integrate în antetul cadrului de transport, fie canale externe
mediului SDH.
Pentru a localiza în mod corect canalele fizice folosite ca suport pentru
transmiterea informaţiilor de management, în fig. 4.4 a fost prezentată
redundanţa de secţiune SOH (“Section OverHead”) pentru cadrul primar STM-
1.
Informaţiile de management încorporate în cadrul SDH (EO) pot fi la nivelul
lor tributare unui protocol orientat pe bit sau pe mesaj. În primul caz sunt
reprezentate prin anumiţi octeţi din SOH, pe care îi vom descrie în momentul
trecerii în revistă a funcţiei managemetului defectărilor. În cazul în care
comunicaţia foloseşte un protocol orientat pe mesaje, sunt folosiţi biţii D1 ÷
D12, ceea ce înseamnă 12 canale distincte, fiecare cu debitul de 64 kbps, deci
un debit total de 768 kbps.
Primele trei canale, D1 ÷ D3, asigură un debit de transport sincron de 192
kbps, dedicat informaţiilor OAM privitoare la echipamentele terminale ale
secţiunii de regenerare. Următoarele 9 canale, D4 ÷ D12, alcătuiesc un canal
de comunicaţii de date (“DCC – Data Communication Channel”) cu debitul de
576 kbps, dedicat transportului informaţiilor OAM specifice secţiunii de
multiplexare.
1 2 3 4 5 6 7 8 9
RSOH
1 A1 A1 A1 A2 A2 A2 J0 NU NU
2 B1 X X E1 X X F1 NU NU
3 D1 X X D2 X X D3 X X
PTR. 4 H1 h1 h1 H2 h2 h2 H3 H3 H3
135
MSOH
5 B2 B2 B2 K1 X X K2 X X
8 D10 X X D11 X X D12 X X
9 S1 Z1 Z1 Z2 Z2 M1 E2 NU NU
RSOH  (Regeneration Section OverHead) = Redundanţa secţiunii de regenerare

MSOH  (Multiplexing Section OverHead) = Redundanţa secţiunii de multiplexare
Fig. 4.4. Structura SOH pentru cadrul STM-1
Protocolul utilizat pentru transferul informaţiilor pe aceste canale este de

tipul orientat pe mesaje, numit LAPD (“Link Access Protocol channel D” –
Protocol de acces legătură pe canal D), definit în [Q.920 şi Q.921].
Acest protocol este de nivel 2, legătură de date, dacă ne raportăm la
ierarhia stratificată OSI a sistemelor SDH. Scopul său este de a transporta
informaţii între entităţiile nivelului 3 de-a lungul interfeţelor ISDN utilizator-reţea,
folosind canale de tip D. Este un protocol duplex, independent de rata de
transmisie a canalului folosit. Nivelul 3 al arhitecturii OSI solicită servicii de la
nivelul legătură de date prin intermediul primitivelor de servicii. În acelaşi fel
nivelul 2 comunică cu nivelul fizic. Primitivele schimbate între nivelul legătură de
date şi nivelele adiacente acestuia sunt clasificate după patru tipuri distincte:
 primitive CERERE;
 primitive INDICAŢIE;
 primitive RĂSPUNS;
 primitive CONFIRMARE.
În fig. 4.5 este prezentată o posibilă secvenţă a modului în care acţionează
aceste primitive.
Primitiva CERERE este utilizată atunci când nivelul superior cere un
serviciu de la nivelul imediat inferior.
Primitiva INDICAŢIE este utilizată de nivelul furnizor de servicii atunci când
acesta doreşte să anunţe nivelul imediat superior de iniţierea unei activităţi
referitoare la serviciul solicitat.
Primitiva RĂSPUNS este utilizată de un anumit nivel pentru a confirma
nivelului imediat inferior că a recepţionat de la acesta o primitivă de tip
INDICAŢIE.
Primitiva CONFIRMARE este utilizată de nivelul furnizor de servicii pentru a
confirma îndeplinirea serviciului solicitat.
Nivel 3 Nivel 3
CONFIRMARE CERERE INDICAŢIE RĂSPUNS
PAS
136
Nivel 2 Nivel 2
Protocol punct-la-punct la nivelul

Legătură de Date
PAS – Punct de Acces la Serviciu
Fig. 4.5. Secvenţă de acţionare a primitivelor
Protocolul LAPD include funcţii specifice nivelului 2 din ierarhia unui sistem
OSI, după cum urmează:
 furnizarea uneia sau mai multor conexiuni de tip legătură de date pe
canalul D;
 includerea unei secvenţe de control care să permită respectarea unei
ordini corecte în secvenţa sosirii cadrelor la recepţie;
 detecţia erorilor de transmisie, de format şi operaţionale survenite pe o
conexiune tip legătură de date;
 refacerea informaţiilor utile în cazul apariţiei erorilor;
 anunţarea entităţilor de management în cazul apariţiei unor erori ce nu
mai permit refacerea informaţiei;
 controlul fluxului de informaţie.
Deci suportul fizic pentru canalele ECC este constituit de canalale DCC,
care folosesc un protocol de comunicaţie de tip LAPD. Pentru a asigura un bun
suport logic pentru funcţiile de management, trebuie implementate şi anumite
funcţii de control pentru canalele ECC. Astfel, funcţiile de management ale ECC
trebuie să îndeplinească următoarele condiţii:
 refacerea principalilor parametri ai reţelei ce asigură o funcţionare
compatibilă (mărimea pachetelor, calitatea serviciilor, mărimea ferestrei de
retransmisie etc.);
 stabilirea unei rutări a mesajelor între nodurile DCC;
 managementul adreselor de reţea;
 refacerea stării operaţionale a DCC la nodurile aflate în trafic;
 capacitatea de a permite sau interzice accesul la canalele DCC.
Suplimentar faţă de aceste canale de management încorporate în antetul
cadrelor SDH, în acelaşi scop mai pot fi folosite şi canale externe de conectare
la managerul principal al reţelei. Acest mod de abordare se dovedeşte extrem
de util atunci când nu sunt încă interconectate toate inelele SDH, fiind astfel
imposibilă folosirea suportului propriu de management. Canalele externe ce vor
conecta nodurile SDH la punctul principal de control pot folosi două tipuri de
interfeţe cu inelele SDH:
 interfaţa QB3, tip Ethernet 802.3, pentru cazul în care distanţele de
interconectare sunt reduse;
 interfaţa QB2, tip X25, pentru cazul în care distanţele de interconectare
sunt mari.
Folosirea acestor tipuri de interfeţe are un dublu scop:
137
 pot interconecta între ele facilităţile interne de management ale

nodurilor DCS sau MUX;
 pot conecta aceste facilităţi la un punct principal de management,
extern reţelei de transport.
Unul din principalele avantaje ale modului de management al unei reţele
SDH este faptul că are încorporat direct în mediul de transmisuni suportul
pentru TMN, prin intermediul canalelor DCC. Folosirea unui sistem extern de
transport pentru TMN, deşi extrem de utilă mai ales în faza de instalare a
inelelor SDH, poate ridica probleme deosebite de interfaţare, dublate de
inconvenientul că astfel se pierde din caracterul integrat al soluţiei oferite pentru
acest tip de management.
În următorul paragraf va fi descris modul de implementare a funcţiilor de
management specifice TMN în cazul particular al SDH.
4.1.3 Funcţiile de management al SDH
Funcţiile de management ale SDH respectă clasificarea din Recomandarea

M.3010 a ITU-T pentru TMN, clasificare descrisă şi în această lucrare. Conform
acesteia avem următoarele categorii de funcţii de management:
 funcţia de management al defectărilor;
 funcţia de management al performanţelor;
 funcţia de management al siguranţei;
 funcţia de management al configuraţiei;
 funcţia de management al calităţii.
Modul de implementare a acestor funcţii de management este unul ierarhic,
pornind de la structura de control prezentată în fig. 4.2, structură care respectă
stratificarea logică specifică SDH [G.803]. În fig. 4.6 a fost prezentată ierarhia
de management proprie SDH.
În continuare, vor fi descrise principalele funcţii de management specifice
SDH.
A. Funcţia de management al defectărilor
Funcţia de management al defectărilor acţionează atât la nivel de reţea, cât

şi la nivel de echipament, la fel ca toate celelalte funcţii de management.
La nivel de reţea principalul său obiectiv este de a detecta şi identifica
echipamentele defecte. La nivel de echipament acţiunea sa este mai complexă
şi presupune detectarea defectărilor, generarea şi monitorizarea semnalelor de
alarmă, testarea reţelei.
Fiecare echipament din reţea, tratat din punct de vedere obiectual ca un
ER, trebuie să aibă capacitatea să genereze automat semnale de alarmă spre
centrul de management atunci când anumite evenimente/condiţii neacceptabile
apar în funcţionarea sa sau sunt sesizate în fluxurile externe pe care acesta le
recepţionează. Aceste evenimente sau condiţii trebuie clasificate, de către
manager, ca importanţă, în două mari categorii:
 evenimente grave care trebuie raportate imediat, automat, de către
echipament;
138
 restul evenimentelor ce pot apărea, acestea trebuind stocate şi

raportate atunci când echipamentul este interogat de către manager.
Această clasificare încearcă să minimizeze impactul pe care l-ar putea avea
asupra încărcării traficului de management apariţia mesajelor referitoare la
defectări sau proaste funcţionări.
RSTE RSTE
RSOH
Nivel secţiune de
regenerare
RSTE RSTE
MSOH
Nivel secţiune de
multiplexare
RSTE RSTE
HO POH
Nivel cale
RSTE RSTE
LO POH
RSTE  (Regeneration Section = Echipament terminal al secţiunii de

Terminal Equipment) regenerare
MSTE  (Multiplexing Section Terminal = Echipament terminal al secţiunii de
Equipment) multiplexare
HO  (High Order Path Terminating = Echipament terminal al căii de ordin
PTE Equipment) superior
LO  (Low Order Path Terminating = Echipament terminal al căii de ordin
PTE Equipment) inferior
Fig. 4.6. Ierarhie de management SDH
Din aceste motive, sistemul de management al SDH trebuie să fie capabil

să îndeplinească următoarele funcţii dedicate controlului alarmelor:
 raportarea automată a alarmelor;
 posibilitatea de a solicita transmiterea alarmelor;
 posibilitatea de a bloca sau nu transmiterea alarmelor pe ECC;
 posibilitatea de a valida sau invalida funcţia de solicitare a alarmelor;
 posibilitatea de a valida sau invalida funcţia de tranmsitere automată a
alarmelor.
În cele ce urmează vom trece în revistă principalele condiţii de eroare,
precum şi semnalele de eroare şi alarmă ce pot fi generate de echipament către
sistemul de management.
139
Condiţii de eroare
LOS (Loss Of Signal) – Lipsă semnal
Atunci când echipamentul nu recepţionează, înainte de de-scrambler, un bit

de 1 pentru o durată mai mare de 100 µ sec, se declară defect lipsă de semnal
şi dacă defectul persistă mai mult de 2 sec, se generează un semnal de alarmă
LOS spre sistemul de management.
În sens invers, pentru a se declara lipsă defect este necesară recepţia a cel
puţin două module de transport corecte consecutiv. După alte 10 sec de
funcţionare corectă este anulată şi condiţia de eroare, iar echipamentul
resetează semnalul de alarmă, trimiţând spre sistemul de management un
mesaj de ieşire din alarma respectivă.
OOF (Out Of Frame) - Desincronizare
În cazul în care timp de 625 µ sec nu este detectată secvenţa corectă de

sincronizare (octeţii A1 şi A2 din redundanţa de secţiune RSOH) se declară
defect de OOF. Pentru a se declara reintrarea în sincronism trebuie detectate
două secvenţe de sincronizare corecte consecutive.
LOF (Loss Of Frame) – Pierderea sincronismului
Dacă indicaţia de alarmă OOF există pentru mai mult de 3 sec se declară
LOF. Dacă acesta persistă mai mult de 2.5 sec atunci echipamentul trece în
condiţie de eroare, activând indicatorul LOF, simultan cu trimiterea unui semnal
de alarmă specific spre sistemul de management.
Pentru a fi înlăturat defectul LOF trebuie ca echipamentul să stea cel puţin 3
sec fără eroare OOF. După alte 10 sec fără alarmă, condiţia de alarmă este
resetată, iar spre sistemul de management este trimis un mesaj de anulare a
condiţiei de eroare.
LOP (Loss Of Pointer) – Pierderea pointerului
Defectul LOP poate fi detectat în două cazuri distincte:

 sunt recepţionaţi consecutiv cel puţin doi pointeri incorecţi, adică cu
salturi mai mari de o unitate;
 se recepţionează consecutiv 10 indicaţii de încărcătură nouă (NDF –
New Data Flag – Indicator încărcătură nouă).
După mai mult de 2.5 sec de eroare este declarată condiţie de eroare LOP
şi se transmite alarmă spre sistemul de management.
Pentru înlăturarea defectului este necesară recepţionarea a trei pointeri
consecutivi cu valori corecte şi NDF-uri normale. După alte 10 sec de la
dispariţia defectului este înlăturată şi condiţia de eroare, ceea ce conduce la
resetarea semnalului de alarmă şi la transmiterea unui mesaj de anulare a
alarmei spre sistemul de management.
140
În afara acestor posibile defecte mai există şi altele mai puţin importante
sau mai rar întâlnite.
Echipamentul de reţea monitorizează şi propria sa funcţionare, în mod
similar modului în care monitorizează defectele de semnal. Aceasta presupune
monitorizarea blocului de alimentare, blocului de procesare, blocului memoriilor,
precum şi altor blocuri funcţionale. Modul în care se realizează aceste operaţii
sunt specifice producătorului. La ieşirea din condiţiile normale de funcţionare
pentru unul din aceste blocuri este generat un semnal optic de avertizare locală,
dublat de transmiterea unui mesaj corespunzător de alarmare spre sistemul de
management.
Protocolul de comutare automată a protecţiei
În secţiunea anterioară au fost prezentate principalele condiţii de eroare pe

care le poate monitoriza sistemul de management al SDH şi modul în care
acesta reacţionează la detectarea unei condiţii de eroare. Pentru a putea
asigura o funcţionare continuă, la parametrii impuşi, a unei secţiuni de
multiplexare sunt prevăzute aşa numitele canale de rezervă. Un canal de
rezervă poate fi folosit ca protecţie pentru mai multe secţiuni active, iar
declanşarea comutării pe acest canal trebuie să se poată realiza simultan la
ambele echipamente terminale.
Acest protocol (APS – “Automatic Protection Switching”) se declanşează
automat la îndeplinirea uneia din următoarele trei condiţii:
 degradarea peste o anumită limită a calităţii semnalului;
 apariţia pe secţiunea respectivă a unor condiţii noi de eroare;
 primirea unor comenzi externe de comutare forţată a protecţiei.
Pentru controlul acestui protocol există un bloc dedicat pentru management
al protecţiei, care foloseşte drept suport de transport pentru informaţia necesară
octeţii K1 şi K2 din MSOH. Trebuie luată în seamă şi probabilitatea eronării
chiar a acestor octeţi, ceea ce trebuie să conducă la generarea unei condiţii de
eroare specifică.
Semnale de alarmă şi eroare
După cum a fost prezentat în secţiunea dedicată condiţiilor de eroare, atunci

când echipamentul detectează o condiţie de eroare, după un timp prestabilit,
transmite un mesaj de alarmă sau de eroare spre sistemul de management.
În principal, în SDH sunt două mari categorii de semnale de alarmă, după
direcţia spre care sunt generate:
 AIS (”Alarm Indication Signal” – Semnal de indicare a unei alarme) –
este transmis spre echipamentul aflat pe sensul de emisie, deci în aval;
 RDI (”Remote Defect Indication” – Indicator de defect la un terminal
îndepărat) – este transmis amonte, adică spre sistemul de management.
La rândul lor, semnalele AIS pot fi împărţite în trei categorii:
 MS_AIS: este transmis în general atunci când sunt detectate erori de
tip LOS, OOF sau OOF;
 HO_AIS: este transmis în principal la detectarea pierderii pointerului la
cadrele din calea de ordin superior, deci la apariţia defectului HO_LOP;
141
 LO_AIS: se generează în condiţii similare cu semnalul HO_AIS, dar se

referă la pierderea pointerului pentru cadrele dintr-o cale de ordin inferior, deci
atunci când apare defectul LO_LOP.
Pentru semnalele de tip RDI pot fi identificate în mod similar trei sub-tipuri
distincte, corespunzătoare celor trei nivele de management:
 MS_RDI: este transmis nodului de origine al secţiunii de multiplexare,
atunci când în terminal sunt stabilite una din cele trei condiţii de eroare: LOS,
LOF sau OOF;
 HO_RDI: este transmis amonte dacă s-a detectat pe calea de ordin
superior o condiţie HO_LOP sau dacă la acest nivel au fost recepţionate din
amonte MS_AIS sau HO_AIS;
 LO_RDI: este generat dacă la nivelul căii de ordin inferior a fost
detectat un defect de pierdere de pointer, deci LO_LOP sau în cazul în care a
fost recepţionat din amonte unul din semnalele de eroare HO_AIS sau LO_AIS.
Referitor la semnalele de eroare, acestea nu sunt transmise decât în
amonte, spre echipamentul de la care se recepţionează fluxul informaţional şi
sunt denumite REI (”Remote Error Indicator” – Indicator de eroare la terminalul
îndepărtat).
Aceste tipuri de mesaje pot fi la rândul lor catalogate după nivelul fizic de la
care sunt generate, astfel:
 MS_REI: reprezintă un retur distant la BIP_24, fiind generat la nivelul
secţiune de multiplexare;
 HO_REI: reprezintă un retur distant la BIP_8, fiind generat la nivelul căii
de ordin superior;
 LO_REI: reprezintă un retur distant la BIP_2, fiind generat la nivelul căii
de ordin inferior.
Testarea reţelei
Această facilitate a funcţiei de management al defectărilor este foarte utilă

în identificarea unor nefuncţionalităţi apărute în operarea reţelei. Poate fi
divizată în trei sub-funcţii diferite de mentenanţă şi întreţinere [G.784]:
 funcţii de acces la reţea;
 funcţii de diagnosticare;
 funcţii de rebuclare.
Cu ajutorul funcţiilor de acces pot fi monitorizate şi testate echipamentele
din reţea, prin conectare locală sau distantă la facilităţile interne de testare ale
acestora.
Diagnosticarea permite realizarea unei analize a rezultatelor obţinute în
etapele de accesare şi culegere a datelor de la echipamente.
Prin funcţiile de rebuclare pot fi testate separat, progresiv, prin izolare, toate
tronsoanele unei reţele SDH, fiind foarte utile pentru funcţiile de diagnosticare.
B. Funcţia de management al performanţelor
Această funcţie are drept scop monitorizarea continuă a performanţelor

reţelei, utilizând ca principale metode fie citirea parametrilor fizici ai reţelei, fie
colectarea biţilor de redundanţă conţinuţi în antetul cadrului SDH. Au fost
142
acceptate două intervale de măsură [G.783 şi G.784], un interval minim de 15

minute şi altul de 24 h. Parametrii ce urmează a fi monitorizaţi sunt specificaţi în
[G.783], în continuare fiind prezentaţi doar cei mai importanţi dintre aceştia
[conform tab. A-3/G.784]:
CV  Code Violation = Violare a codului

ES  Errored Second = Secundă eronată
SES  Severly Errored Second = Secundă sever eronată
UAS  UnAvailable Second = Secundă indisponibilă (nefuncţională)
PSC  Protection Switching = Număr de comutări ale protecţiei
Count
PSD  Protection Switching = Durata comutării protecţiei.
Duration
Pentru o analiză pertinentă a datelor privitoare la performanţa reţelei este

necesară asigurarea memorării unei anumite istorii funcţionale a obiectului
monitorizat. Pentru acest scop au fost definţi un număr distinct de regiştri,
asociaţi celor două ferestre principale de monitorizare: cea de 15 minute şi cea
de o zi. Pentru fiecare fereastră a fost definit câte un registru pentru situaţia
curentă, un altul pentru situaţia anterioară şi un număr nedefinit de regiştri
pentru ultimele n intervale recente. Toţi aceşti regiştri pot fi citiţi la cerere sau în
mod regulat, actualizarea sau citirea informaţiei făcându-se în mod obligatoriu
fără pierderi.
Pentru toate mărimile monitorizate au fost stabilite nişte limite de variaţie
maxime, depăşirea acestora atrăgând automat după sine generarea unor
mesaje de alarmă sau de eroare, după cum a fost deja descris în secţiunea
anterioară.
Această funcţie de management al performanţelor oferă informaţii foarte
utile atât pentru funcţia de defectări cât şi pentru funcţia de management al
configuraţiei, care va fi prezentată în continuare.
C. Funcţia de management al configuraţiei
Managementul configuraţiei se referă la toate acele funcţii care asigură o

bună configurare a resurselor sistemului de transport şi este util atât în etapa de
instalare a reţelei, cât şi în etapa operaţională. În etapa de instalare nu există
încă operaţional suportul de transmisiuni pentru sistemul de management, deci
sunt folosite soluţiile proprietare ale furnizorului, necesare punerii în funcţiune a
întregului sistem. În etapa operaţională deja trebuie stabilite anumite metode de
control a parametrilor reţelei în vederea optimizării performanţelor acesteia.
Principalul instrument aflat la dispoziţia managerului pentru optimizarea
configuraţiei este funcţia de comutare a protecţiilor. Pentru o folosire uşoară şi
corectă, aceste funcţii de comutare trebuie să poată funcţiona în patru regimuri
distincte:
 regim cu comandă de comutare manuală a intrării/ieşirii din funcţiune a
circuitelor de protecţie;
 regim cu comutare forţată a intrării/ieşirii din funcţiune a circuitelor de
protecţie;
 regim de blocare a comutării circuitelor de protecţie;
143
 regim cu comandă de comutare automată a intrării/ieşirii din funcţiune a

circuitelor de protecţie (cunoscut ca APS).
Aceste trei funcţii de management prezentate mai sus sunt cele mai
importante şi ca atare sunt standardizate în recomandarea G.784 a ITU-T.
În cele ce urmează vom prezenta protocoalele de transfer ale mesajelor de
management de-a lungul reţelei.
4.1.4 Stiva de protocoale pentru canalele de transport al informaţiei de

management
Deoarece SDH este construit conform recomandărilor ISO referitoare la

sistemele deschise, aceasta abordare se va reflecta şi în modul în care este
construită stiva de protocoale specifică transferului informaţiei de management.
Au fost prezentate deja în capitolul 2 modul orientat pe obiecte de abordare
al managementului sistemelor OSI, precum şi conceptul de TMN, utilizat în
reţelele de telecomunicaţii.
Managementul reţelei SDH se bazează la rândul lui pe aceleaşi concepte
orientate pe obiecte specifice sistemelor OSI, putând fi tratat ca un caz special
al TMN.
Pentru exemplificare, în fig. 4.7 este prezentat modelul de stivă de
protocoale pentru canalele de transport al informaţiei de management.
Nivelul fizic este constituit de canalele DCC, care operează la viteza de 192
kbps în secţiunea de regenerare, folosind octeţii D1 ÷ D3, iar în secţiunea de
multiplexare operează la 576 kbps, utilizând pentru aceasta octeţii D4 ÷ D12.
La nivelul 2, cel al legăturii de date este folosit protocolul LAPD, conform
[Q.921]. Acesta asigură un transfer punct-la-punct al NSDU-urilor, utilizând un
singur canal logic între cele două noduri.
Există două modalităţi distincte de abordare, specifice acestui protocol,
utilizând fie UITS (“Unacknowledged Information Transfer Service” – Serviciu
de transfer neconfirmat al informaţiilor), fie AITS (“Acknowledged Information
Transfer Service” – Serviciu de transfer al informaţiilor cu confirmare).
CMISE
Nivel 7 →
ACSE/ROSE
Nivel 6 → X.216 şi X.226
X.215 şi X.225
Nivel 5 →
Nivel 4 → ISO 8073/AD2
ISO 8473/AD3
Nivel 3 →
Nivel 2 → LAPD [Q.921]

144
Nivel 1 → DCC
Fig. 4.7. Stivă de protocoale pentru ECC
La nivelul 3, nivelul reţea, este utilizat un mod de transfer fără conexiune,

NPDU-urile fiind transportate ca datagrame. Pentru a putea transfera
informaţiile de la nodul sursă la cel destinaţie, este necesar ca fiecare nod din
reţea să poată lucra fie ca nod intermediar, fie ca nod final. În acest fel, nodurile
intermediare pot genera, la rândul lor, informaţii de control al rutării, necesare
rutării NPDU-urilor.
Pentru nivelul 4, cel de transport, este utilizat un protocol orientat pe
conexiune, specificat în recomandarea ISO 8073. Acesta este un protocol de
transport clasa 4 (“TP class 4”).
Pentru nivelele 5 şi 6 specificaţiile funcţionale sunt cele descrise în
recomandările X.215 şi X.225 pentru nivelul sesiune şi X.216 şi X.226 pentru
nivelul prezentare.
La nivelul 7 sunt situate funcţiile de management, după cum este descris
şi-n capitolul din acestă lucrare dedicat TMN-ului. În fig. 4.8 este prezentat
nivelul aplicaţie şi protocoalele componente ale acestuia.
Serviciile ACSE sunt utilizate la iniţierea sau închiderea unei asociaţii între
două aplicaţii corespondente. Odată stabilită o asociaţie, ea este folosită pentru
a putea fi transmise mesaje de management la serviciile CMISE.
Pentru operaţiile la distanţă sunt utilizate ROSE care permit unui sistem să
invoce derularea unei operaţii pe un alt sistem şi să ceară, de asemenea, să fie
informat despre modul în care se desfăşoară operaţia comandată.
SM-ASE
Nivel Aplicaţie
CMISE
ACSE ROSE
Fig. 4.8. Protocoale de comunicaţie SDH la nivel aplicaţie
145
La nivelul cel mai înalt este situat CMISE, ca parte componentă a CMIP,
rolul său fiind de a furniza servicii de transfer a informaţiilor de management de-
a lungul întregii reţele de canale ECC. Alegerea acestei clase de servicii pentru
managementul SDH impune o metodă orientată pe obiecte de tratare a
componentelor reţelei.
Pentru managementul reţelei SDH, CMISE oferă următoarele primitive şi
servicii asociate acestora:
 crearea de obiecte → primitiva CREATE;
 ştergerea de obiecte → primitiva DELETE;
 definirea atributelor obiectelor → primitiva SET;
 redefinirea atributelor obiectelor → primitiva GET;
 comanda unor operaţii → primitiva ACTION;
 recepţionarea de rapoarte de la obiecte → primitiva EVENT_REPORT.
Pentru descrierea obiectelor şi a atributelor specifice acestora este utilizat
standardul ASN.1.
Se poate afirma, la finalul prezentării, că managementul SDH este o
aplicaţie a TMN, aplicaţie ce respectă particularităţile transmisive ale mediului
folosit drept suport.
În continuare, este prezentat o metodă practică de implementare, realizată
de către autor, a unei părţi din sistemul de management al unei reţele SDH
implementate la noi în ţară. Au fost folosite drept suport canale exterioare
sistemului de transmisiuni, iar protocolul realizat este o adaptare a protocolului
LAPD la condiţiile particulare ale aplicaţiei respective.
Paragraful următor constituie, de fapt, o parte a unui raport tehnic de produs
prezentat de autor la terminarea fazei de colaborare pentru acest sistem cu
INSCC-Bucureşti, în decembrie 1998.
4.2 Sistem de management pentru o reţea SDH – implementare

practică
4.2.1 Descriere generală a sistemului
După descrierea principiilor ce stau la baza managementului reţelelor

SDH, realizată în secţiunea anterioară, vom prezenta acum un mod practic de
realizare a unui sistem de management dedicat unei reţele SDH, funcţională la
ora actuală în cadrul reţelei de fibră optică a RomTelecom. Sistemul a fost
proiectat pentru a asigura principalele funcţii de management ale tronsonului B
ale reţelei de transmisiuni pe suport de fibră optică, realizat cu echipamente
Fujitsu. În fig. 4.9 este prezentată configuraţia reţelei de transmisuni pentru care
a fost implementat acest sistem de management.
Legendă
 Staţie de comutaţie centrală

146
BACĂU
 Staţie intermediară
SASCUT
 Staţie regenerator
ADJUD
 Staţie terminală
FOCŞANI
 Fibră optică de 140 Mb/s
GALAŢI
BRĂILA
ÎNSURĂŢEI
ŢĂNDĂREI
URZICENI CĂZĂNEŞTI
FETEŞTI
SLOBOZIA CERNAVODĂ
AFUMAŢI MEDGIDIA
BUCUREŞTI
CONSTANŢA
Fig. 4.9. Configuraţia tronsonului B de fibră optică
Sistemul manevrează cu fluxuri tributare de 2 Mbit/s, 34 Mbit/s şi 140

Mbit/s care sunt apoi inserate într-un inel de transport SDH, la nivelul întregii
ţări. Deci, deşi acest tronson este în sine o aplicaţie de transport plesiocronă,
pe suport de fibră optică, poate fi tratată din punctul de vedere al scopului final
ca făcând parte dintr-un sistem SDH. Tipurile de alarme, configuraţii de lucru şi
modul de monitorizare sunt specifice sistemului SDH din care fac parte şi au
fost descrise din punct de vedere teoretic în secţiunea anterioară.
Echipamentele care asigură suportul de transmisuni pe fibră optică sunt
de următoarele tipuri:
 echipament de multiplexare digitală 2M/34M (M13 MUX);
 echipament de multiplexare digitală 34M/140M (M34 MUX);
 echipament terminal de fibră optică 140 Mbit/s (140M OLTE);
 echipament regenerator optic (140M OLRE).
Fiecare dintre aceste echipamente au o structură modulară care le permite
o mare flexibilitate în operare, monitorizare şi mentenanţă. Din punctul de
vedere al sistemului de management ele au fost tratate ca Elemente de Reţea,
atât ân ansamblu, cât şi la nivel de cartelă, constituind astfel clasa obiectelor de
administrat (după cum am arătat în cap. 1 şi cap. 2). În fig. 4.10 am figurat
147
structura unor asemenea blocuri şi cartele din perspectiva sistemului de

management.
rack 1 rack 2 rack 3

cartele
B1 B1 B1
Bloc 3
conector MPT E-SV E-SV E-SV
B2 B2 B2
Bloc 2
blocuri
B3 B3 B3
Bloc 1
MPT (Maintenance Portable Terminal – Terminal portabil de mentenanţă)
Fig. 4.10. Structura şi localizarea obiectelor de management

Fiecare dintre aceste obiecte trebuie să poată fi incluse în sistemul de
management, deci să li se poată aplica funcţiile de management: de
configurare, de defectare şi de performanţă. Sistemul trebuie să fie capabil să
configureze echipamentele în mod optim, să le monitorizeze permanent
performanţele şi să detecteze rapid orice defect apărut în funcţionarea
acestora.
4.2.2 Baza de date a sistemului de management
Pentru a putea asigura toate aceste funcţiuni a fost creată o bază de

date relaţională, inspirată din cerinţele impuse de OSI pentru MIB şi care
conţine principalele mărimi folosite de funcţiile de management. Baza de date
conţine astfel următoarele tipuri de tabele:
 tabela de STAŢII;
 tabela de UNITĂŢI;
 tabela de TIPURI;
 tabela de CANALE;
 tabela de CODURI_ALARMĂ;
 tabela de ALARME;
148
 tabela de FUNC_SPEC;
 tabela de UTILIZATORI.
Tabela de STAŢII
Structura tabelei de STAŢII este prezentată în tab. 4.1.
Nr. crt. CÂMP TIP CÂMP

1. ID_STAŢIE integer
2. NUME_STAŢIE text
3. ID_CANAL integer
4. NR_RACKURI integer
5. NR_RACKURI_DIST integer
6. ADR_PROTOCOL integer
7. ECA_INSTALAT integer
8. ID_DIST_ST integer
9. NR_RACK_CON_DIST integer
Tab. 4.1. Structura tabelei de STAŢII
Semnificaţia câmpurilor folosite în cadrul tabelei de STAŢII este

următoarea:
 ID_STAŢIE - este câmpul de identificare a staţiilor, fiecărei staţii fiindu-i
asociat ca identificator un număr întreg;
 NUME_STAŢIE - asociază fiecărei staţii un nume în clar, care poate fi
afişat pe ecranul consolei de management;
 ID_CANAL - indică canalul de comunicaţie activ pe care îl foloseşte
staţia la un moment dat;
 NR_RACKURI - este indicat numărul total de rack-uri pe care îl
supraveghează sistemul de management în cadrul unei staţii;
 NR_RACKURI_DIST - reprezintă numărul total de rack-uri distante (din
staţiile învecinate) care pot fi administrate de sistemul de management;
 ADR_PROTOCOL - prin acest câmp se transmite adresa de identificare
pe un canal a unei staţii;
 ECA_INSTALAT - indică sistemului de management dacă staţia
respectivă este deservită de propriul agent de management (ECA – Echipament
de Colectare a Alarmelor) sau este administrată de la distanţă de la o staţie
vecină;
 ID_DIST_ST - indică pentru staţiile ce nu sunt dotate cu ECA care este
identificatorul staţiei la care este conectată din punct de vedere al
managementului;
 NR_RACK_CON_DIST - acest câmp este asociat, de asemenea, unei
staţii neechipate cu ECA şi indică numărul rack-ului din staţia vecină la care
este conectat agentul de management.
Tabela de UNITĂŢI
Structura tabelei de UNITĂŢI este prezentată în tab. 4.2.
149

1. ID_UNIT integer
3. NO_RACK integer
4. NO_BLOCK integer
5. NO_UNIT text
6. ID_TIP integer
7. FLUX text
8. OBSERVAŢII text
Tab. 4.2. Structura tabelei de UNITĂŢI
Semnificaţia câmpurilor folosite în tabela de UNITĂŢI este următoarea:

 ID_UNIT - este câmpul de identificare a unităţii (sau cartelei)
funcţionale din echipamentul de comunicaţii;
 ID_STAŢIE - identifică staţia căreia îi aparţine unitatea respectivă;
 NO_RACK - acest câmp specifică numărul rack-ului căruia îi aparţine
unitatea respectivă;
 NO_BLOCK - acest câmp identifică blocul din rack-ul NO_RACK căruia
îi aparţine unitatea respectivă;
 NO_UNIT - acest câmp indică poziţia pe care se află unitatea
funcţională;
 ID_TIP - acest câmp indică tipul cartelei funcţionale;
 FLUX - indică fluxul de ieşire asignat la cartela curentă;
 OBSERVAŢII - în acest câmp pot fi făcute observaţii de către
operatorul de la consolă, relative la funcţionalitatea unităţii respective.
Tabela de TIPURI
Structura tabelei de TIPURI este prezentată în tab. 4.3.

1. ID_TIP integer
2. TIP text
3. DESCRIERE text
Tab. 4.3. Structura tabelei de TIPURI
Semnificaţia câmpurilor folosite în tabela de TIPURI este următoarea:

 ID_TIP - prin acest câmp este identificat tipul unei cartele funcţionale
din echipamentul de transmisiuni sau al unui obiect din structura sistemului de
management (ECA, canal de transmisuni, port ECA etc.);
 TIP - acest câmp oferă o informaţie tip text despre tipul unităţii curente
şi este util atunci când se doreşte afişarea la consolă a unor informaţii în clar
despre unitatea respectivă;
 DESCRIERE - în acest câmp pot fi inserate detalii suplimentare
referitoare la tipul unităţilor sau cartelelor respective.
Tabela de CANALE
Structura tabelei de CANALE este prezentată în tab. 4.4.
150

1. ID_CANAL integer
2. COM_PORT text
3. INSTALAT integer
Tab. 4.4. Structura tabelei de CANALE
Semnificaţia câmpurilor folosite în tabela de CANALE este următoarea:

 ID_CANAL - acest câmp conţine informaţia referitoare la canalul pe
care este legată o staţie şi este în legătură cu tabela de STAŢII;
 COM_PORT - acest câmp conţine adresa portului de comunicaţie
folosit pentru sistemul de management;
 INSTALAT - acest câmp indică faptul dacă un canal identificat prin
ID_CANAL este instalat sau nu.
Tabela de CODURI_ALARMĂ
Structura tabelei de CODURI_ALARMĂ este prezentată în tab. 4.5.

1. ID_COD_ALARMĂ integer
2. COD_ALARMĂ text
3. DESCRIERE_ALARMĂ text
SemnificaţiaTab. 4.5. Structura

câmpurilor tabelei
folosite de CODURI_ALARMĂ
în tabela de CODURI_ALARMĂ este
următoarea:
 ID_COD_ALARMĂ - acest câmp indică ce tip de alarmă a apărut pe o
anumită cartelă funcţională;
 COD_ALARMĂ - acest câmp conţine informaţia despre alarmă
nedecodificată, aşa cum a fost ea recepţionată de la echipament;
 DESCRIERE_ALARMĂ - acest câmp poate conţine informaţii
descriptive despre tipul de alarmă apărută şi poate fi afişat pe consola operator
la cererea managerului.
Tabela de ALARME
Structura tabelei de ALARME este prezentată în tab. 4.6.

1. ID_ALARMĂ integer
3. ID_UNIT integer
4. ID_COD_ALARMĂ integer
5. APARIŢIE datetime
6. DISPARIŢIE datetime
7. DURATĂ long integer
8. READED integer
9. NO_RACK integer
Tab. 4.6. Structura tabelei de STAŢII
151
Semnificaţia câmpurilor folosite în cadrul tabelei de ALARME este

următoarea:
 ID_ALARMĂ - acest câmp indică apariţia unei noi alarme, care va fi
apoi caracterizată de celelalte mărimi din tabel;
 ID_STAŢIE - indică staţia unde a apărut alarma identificată de
ID_ALARMĂ;
 ID_UNIT - acest câmp indică unitatea pe care a fost detectată noua
alarmă;
 ID_COD_ALARMĂ - acest câmp conţine identificatorul tipului de alarmă
apărută;
 APARIŢIE - acest câmp conţine data şi ora exactă la care a fost
înştiinţat serverul despre apariţia noii alarme;
 DISPARIŢIE - acest câmp conţine data şi ora exactă când a dispărut
alarma;
 DURATĂ - în acest câmp este stocată, de fapt, diferenţa dintre valorile
existente în câmpul dispariţie şi câmpul apariţie şi reprezintă durata de timp în
care alarma a fost activă;
 READED - acest câmp indică programului de descărcare a alarmelor
din baza de date faptul că alarma respectivă a mai fost sau descărcată;
 NO_RACK - acest câmp specifică poziţia rack-ului în care este situată
unitatea aflată în alarmă.
Tabela de FUNC_SPEC
Structura tabelei de FUNC_SPEC este prezentată în tab. 4.7.

1. ID integer
2. ID_UNIT integer
3. DATA_ORA_MAS datetime
4. ULTIM_MAS integer
5. BER float
6. EB float
7. EFS float
8. ES float
9. SES float
10. DM float
Tab. 4.7. Structura tabelei de FUNC_SPEC

următoarea:
 ID - este indexul înregistrărilor din tabelă;
 ID_UNIT - acest câmp conţine identificatorul unităţii de pe care s-au citit
valorile mărimilor măsurate (BER, EFS, etc.);
 DATA_ORA_MAS - acest câmp conţine data şi ora când au fost
efectuate măsurătorile de calitate ce sunt înscrise în tabel;
152
 ULTIM_MAS - acest câmp indică faptul dacă măsurătorile au fost

actualizate sau nu;
 BER, EB, EFS, ES, SES, DM - aceste câmpuri conţin valorile
măsurătorilor de calitate efectuate.
Tabela de UTILIZATORI
Structura tabelei de UTILIZATORI este prezentată în tab. 4.8.

următoarea:
 USER_NAME - acest câmp conţine numele utilizatorilor care au acces
la resursele sistemului de management;
 FLAG_ALARME - prin intermediul acestui flag programul PCA
comunică programului PPA că a apărut/dispărut o alarmă în echipamentul de
transmisiuni;
 ID_MPT - acest câmp conţine identificatorul MPT-ului curent, cel de pe
care se citesc alarme sau se descarcă configuraţii pe echipament;
 CMD_MPT - prin intermediul acestui câmp programul PPA transmite
comenzi spre echipamentele aflate în subordine;
 ECRAN_MPT - acest câmp conţine informaţiile pe care programul PCA
le transmite spre ecranul MPT-ului virtual;
 REQUEST_WKS şi ANSWER_WKS - aceste două câmpuri conţin, de
fapt, primitivele necesare comunicaţiei între server şi staţiile de lucru distante;

1. USER_NAME text
2. FLAG_ALARME integer
3. ID_MPT integer
4. CMD_MPT text
5. ECRAN_MPT text
6. REQUEST_WKS text
7. ANSWER_WKS text
8. INTERDICTIE integer
Tab. 4.8. Structura tabelei de UTILIZATORI
 INTERDICŢIE - prin intermediul acestui câmp programul PCA interzice

accesul altui utilizator la un rack pe care tocmai a fost detectată o alarmă,
lăsând astfel timp rezolvării acestei probleme.
4.2.3 Arhitectura sistemului de management
Implementarea funcţiilor de management care au fost stabilite drept

obiectiv a fost realizată prin intermediul unui sistem de management complex,
bazat pe tehnologia client-server şi care este compus dintr-o unitate centrală de
management (PCS – Punct Central de Supraveghere) şi un număr de agenţi
locali de management (ECA – Echipament de Colectare a Alarmelor) (fig. 4.12).
153
Unitatea centrală de management a fost instalată în Bucureşti, iar un

număr de 7 agenţi de management au fost instalaţi în ţară, conform dispunerii
din fig. 4.11. După cum s-a putut observa şi din definirea bazei de date a
sistemului, un agent de management instalat într-o staţie poate servi şi
echipamentele aflate în staţiile vecine, prin intermediul unor canale de
comunicaţii închiriate.
Sistemul construit respectă specificaţiile generale ale unui sistem de
management, aşa cum au fost ele descrise în cap. 1 şi cap. 2 (vezi fig. 2.1),
fiind în acelaşi timp apropiate ca mod de abordare sistemelor de management
cu procesare distribuită, prezentate în cap. 2. După cum s-a putut observa şi
prin trecerea în revistă a principalelor mărimi care sunt stocate în baza de date
a sistemului (tab. 4.1 ÷ tab. 4.8), acest sistem corespunde specificaţiilor unui
sistem de management al SDH (cap. 4.1).
ECA este realizată pe baza unei structuri hardware dezvoltată în jurul
microcontrolerului 87C552. Folosindu-se de capacităţile de achiziţie şi de calcul
ale microsistemului, ECA monitorizează, în principal, un număr de până la 6
entităţi funcţionale distincte, comunicaţia cu acestea realizându-se pe linii
seriale, asincrone, cu viteza de 1200 bps, respectându-se standardul electric
V.28 şi standardul funcţional RS 232.
Fiecare din aceste unităţi funcţionale distincte este prevăzută, în mod
suplimentar, cu un contact static, flotant, prin închiderea acestuia,
semnalizându-se dispozitivului ECA existenţa unei alarme funcţionale. În
momentul recepţionării semnalului de alarmă, ECA se conectează automat la
sistemul respectiv şi pe baza unui dialog interactiv, de tip client-server, citeşte
starea funcţională a echipamentului, determinând astfel tipul alarmei.
Odată obţinute informaţiile complete referitoare la starea echipamentului,
acestea sunt prelucrate în cadrul ECA, formatate şi apoi transmise, prin
modem, echipamentului central de supraveghere, PCS-ul.
Legendă
 Staţie prevăzută cu agent de
 Staţie de comutaţie centrală BACĂU
management
 Staţie intermediară  Canal digital de management

SASCUT
 Staţie regenerator  Staţie prevăzută cu agent de

ADJUD management şi cu manager de
 Staţie terminală reţea
FOCŞANI
 Fibră optică de 140 Mb/s
GALAŢI
BRĂILA
ÎNSURĂŢEI
ŢĂNDĂREI
154
FETEŞTI
SLOBOZIA CERNAVODĂ
URZICENI CĂZĂNEŞTI
AFUMAŢI MEDGIDIA
BUCUREŞTI
CONSTANŢA
Fig. 4.11. Localizarea agenţilor de management în cadrul reţelei
155
PCS
(platformă Windows NT)
Interfaţă multiport serială
asincronă
1 ... 9
Modem asincron Modem asincron

v = 9600 bps Interfaţă v = 9600 bps
Dispozitiv Dispozitiv
Diagnoză Diagnoză
7 Modem asincron Modem asincron
v = 9600 bps v = 9600 bps
Interfaţă
Interfaţă
Interfaţă serială Interfaţă serială Interfaţă serială Interfaţă serială
asincronă asincronă asincronă asincronă
v = 9600 bps v = 9600 bps v = 9600 bps v = 9600 bps
.......
ECA 1 ECA 8
(platformă microcontroller (platformă microcontroller
8x552) 8x552)
Porturi seriale asincrone Porturi seriale asincrone
V = 1200 bps V = 1200 bps
1 2 ... 6 Interfaţă 1 2 ... 6
Porturi seriale asincrone v = 1200 bps Porturi seriale asincrone v = 1200 bps
Ramă Ramă
Fig. 4.12. Schema bloc a sistemului de management PCS-ECA
156
RAMA 1 RAMA 2 RAMA 3 RAMA 4 …… RAMA 6
PCS
IO - 2 IO - 3 IO - 4 IO - 5 IO - 7
GND I.A.C.
MODEM
INT RS232 +5V INT RS232 INT RS232 INT RS232 INT RS232 INT RS232
A1 A2 A3 A4 A6
MULTIPLEXOR
DIGITAL
+5 V GND
A B C E R
Port intrări
A0
Adrese MUX Port serial
PORT TESTARE
A1
INT PC
A2 RS 232
Sistem cu micro-controller
Sursă de
aliment
…
are Port ieşiri

R1 R2 R3 R4 … R8
A5
S1 S2 S3 S4 S8
S.A. …
+ 48 V - U.C.
Fig. 4.13. Schema bloc a echipamentului de colectare a alarmelor (ECA)

Fig. 4.14. Schema bloc a unităţii centrale a ECA
Port TEST
E ER157R
Port intrări
Port ieşiri
RAM (32kB) 87C552 EPROM (32kB) E R E
8000H ÷ 0FFFFH 0000H ÷ 7FFFH
BD0÷ 7 BD0÷ 7 BA0÷ 7 Busul BD0÷ 7 BA0÷ 7 INT.BD
RS 232 R
C5210
B
A Busul
Busul dede
de control
adrese
date BD
BA0÷0÷
77 0÷ 7
S84321…
…
Spre ICA
158
Fig. 5.11 Schema bloc a unităţii centrale a ECA

La rândul său, PCS-ul poate interoga ECA privind starea funcţională a
unui anumit echipament subordonat acestuia. La primirea acestei comenzi,
ECA începe un dialog cu echipamentul respectiv, culege informaţiile cerute, le
formatează, iar în final le transmite PCS-ului.
Există şi un al treilea mod de lucru pentru ECA şi anume configurarea şi
setarea echipamentului subordonat pe baza comenzilor primite de la managerul
sistemului.
Operaţiile de diagnoză şi mentenanţă ale ECA pot fi realizate fie de la
distanţă, prin intermediul unei linii închiriate, utilizându-se modemul ataşat, de la
PCS, fie local, de la un laptop, pentru aceasta ehipamentul fiind prevăzut, în
mod suplimentar, cu un port de acces. Această ieşire poate fi conectată serial,
asincron, cu viteza de 9600 bps la un calculator pentru efectuarea diagnozei
modulului.
4.2.4 Structura hardware a ECA
Echipamentul este constituit din trei blocuri funcţionale distincte (vezi fig.
4.13):
 S.A. – Sursa de Alimentare;
 U.C. – Unitatea Centrală;
 I.A.C. – Interfaţa de Achiziţie şi Control.
Vom descrie, în continuare, pe scurt, compoziţia celor trei blocuri funcţionale.
Sursa de Alimentare (SA)
Este o sursă de alimentare realizată în comutaţie, care trebuie să

furnizeze, pornind de la tensiunea de – 48 V la care este conectată, o tensiune
flotantă de +5V, la un curent nominal 150 mA. Este prevăzută cu protecţie la
suprasarcină de curent, la un curent de aproximativ 500 mA decuplând automat
modulele care se alimentează de la ea.
Sursa de alimentare destinată ECA, este un convertor DC-DC, în
comutaţie, care transformă tensiunea continuă de 48 V (20V ÷ 80V) de
alimentare a ramelor din oficiu PTT, într-o tensiune continuă izolată şi
stabilizată de 5 V.
Unitatea Centrală (UC)
Este o structură de microcalculator (schema bloc din fig. 4.14), construită

pe baza microcontrolerului 87C552, fiind echipată cu o memorie RAM de 32 Kb
şi o memorie EPROM de 32 Kb.
Frecvenţa de lucru a microsistemului este de 15 MHz, obţinută de la
cristalul de cuarţ de 15 MHz ataşat microcontrolerului.
Achiziţia datelor de la IAC se realizează cu ajutorul unui bloc de
comunicaţie serială, pe trei fire (T-transmisie, R-recepţie şi M-masă),
comunicaţia realizându-se asincron, cu viteza de 1200 bps, nivelele electrice
fiind compatibile TTL. Comanda IAC, pentru selecţia canalului de comunicaţie
ce se doreşte a fi stabilit, se realizează prin intermediul a trei fire, notate pe
figura 4.14 cu A, B şi respectiv C. Citirea stărilor de alarmă de la echipamente
159
se face prin intermediul a până la 6 intrări distincte, cu nivele electrice TTL,
notate cu A0÷ 5. Pentru a semnaliza optic exterior direcţia pe care este angajată
comunicaţia la un moment dat, UC-ul este prevăzut cu 8 ieşiri distincte, notate
cu S1÷ 8, ieşiri la care se pot ataşa direct până la 8 LED-uri.
Pentru diagnoza echipamentului, la modulul UC este ataşat un port
serial, prevăzut cu o interfaţa electrică RS 232, la care poate fi conectat un
calculator personal sau un terminal compatibil VT100.
Această unitate asigură prin intermediul IAC controlul echipamentelor
terminale optice, precum şi conectarea acestora la sistem.
Microcontroller-ul în jurul căruia este dezvoltată unitatea de comandă
are în principal următoarele capabilităţi:
 unitate de procesare pe 8 biţi, care în cazul unui ceas extern de 15
MHz are o putere de 0.6 Mips;
 două timere autoîncărcabile pe 8 sau 16 biţi;
 8 convertoare A/D, multiplexate, pe 10 biţi, cu timpul de achiziţie de 50
µ S;
 4 porturi bidirecţionale, de câte 8 biţi fiecare;
 port serial asincron, UART, programabil până la o viteză de 19200 bps;
 port serial sincron, I2C, cu viteza de până la 100 Kbps.
Microsistemul este prevăzut cu 64 Kb memorie, din care 32 Kb sunt
memorie EPROM (necesare păstrării aplicaţiilor), în această configuraţie fiind
plasaţi între adresele 0H ÷ 7FFFH şi 32 Kb memorie RAM, poziţionaţi între
adresele de memorie 8000H ÷ 0FFFFH. În memoria RAM pot fi încărcate şi
rulate programe, astfel că sistemul permite şi rularea unor variante îmbunătăţite
ale software-ului, fără vreo modificare hardware.
Sistemul are un număr de porturi compatibile din punct de vedere electric
TTL, orientate spre funcţiile de achiziţie şi comandă specificate. Porturile A0 ÷
A5 sunt 6 porturi de intrare, conectate prin intermediul IAC la contactele flotante
de alarmă situate pe rack-urile ce trebuiesc monitorizate. Închiderea unuia din
aceste contacte, în cazul apariţiei unei alarme la rack-ul respectiv, conduce la
apariţia unui “zero” electric la intrarea portului Ai respectiv, sistemul fiind astfel
anunţat de alarma respectivă.
Prin cele trei porturi de ieşire (notate A, B şi C) microsistemul comandă
selecţia unuia din cele 6 canale de achiziţie respective.
Observaţie: Actuala configuraţie hardware permite ca fără modificări
majore sistemul să poată fi extins pentru achiziţionarea a până la 255 de canale
distincte.
Porturile de ieşire S1 ÷ S8 comandă aprinderea sau stingerea a 8 LED-uri,
indicând astfel la care canal este conectat sistemul în momentul respectiv.
Interfaţa de Achiziţie şi Control (IAC)
Prin intermediul acestei interfeţe UC-ul preia informaţii şi transmite

comenzi către echipamentele aflate în subordine. Nivelele electrice sunt
adaptate în ambele direcţii de către IAC, aceasta făcând translatarea de la
nivele de ± 12V specifice echipamentelor la nivele de 0/5 V ale UC-ului.
160
De asemenea, prin intermediul acestui modul, se realizează ieşirea spre
modem, pentru conectarea la unitatea centrală de management, PCS, prin linie
telefonică închiriată.
Deci, IAC asigură legătura logică între UC şi echipamentele de
transmisiuni pe suport optic aflate sub supraveghere, permiţând transferul
bidirecţional de informaţii între PCS şi echipamentele terminale optice, astfel
că:
 obiectele administrate pot transmite spre sistem stări de alarmă sau
informaţii privind starea lor funcţională;
 de la sistemul de management pot fi transmise spre agenţi informaţii
necesare configurării acestora sau pot fi comandate anumite teste funcţionale.
4.2.5 Descrierea funcţională a ECA
Caracteristici generale
Rolul ECA este de a asigura interfaţa între PCS şi echipamentele ce

urmează a fi monitorizate şi controlate. Interogarea echipamentelor se
realizează în două situaţii distincte, astfel:
 atunci când PCS-ul o solicită în mod expres pentru a afla starea
acestora sau pentru a o modifica, prin pornirea unui program de “terminal
virtual” prin care operatorul aflat la punctul central poate modifica, pe baza unui
meniu interactiv, setarea parametrilor echipamentelor;
 în cazul în care se detectează o stare de alarmă la unul din terminale,
prin intermediul semnalelor A0÷ 5, moment în care ECA începe interogarea
echipamentului care a semnalizat o stare de proastă funcţionare. Informaţiile
obţinute de la echipament sunt transferate, prin intermediul modemului, spre
PCS, atunci când acesta ajunge cu “apelarea” la ECA-ul corespunzător.
Comunicaţia cu PCS se realizează pe canal închiriat, prin intermediul
unui modem, cu o viteză de transfer de până la 9600 bps, în funcţie de calitatea
canalului respectiv în momentul realizării transferului.
Datorită importanţei transferului corect al datelor, acesta este realizat pe
baza unui protocol de comunicaţie protejat la erori ce pot atinge pragul critic de
10-4. Protocolul este de tip detecţie şi corecţie a erorilor prin retransmisie,
retransmisia efectându-se automat când nu s-a primit confirmarea la blocul
transmis anterior sau la cererea expresă a corespondentului. Am construit acest
protocol bazându-mă de rezultatele obţinute cu protocolul de comunicaţie pe
canal comun, prezentat în detaliu în cap. 3.
Posibilităţi de diagnoză a ECA
Au fost implementate funcţii de management specifice ariei funcţionale a

managementului defectărilor (cap. 1), în particular funcţii de diagnosticare.
Diagnosticarea ECA este organizată pe trei nivele ierarhice, în funcţie de
profunzimea testelor realizate şi de localizarea acestora:
 nivel intern: aparatul efectuează atât la pornire, cât şi în timpul
funcţionării, autotestarea principalelor blocuri funcţionale, iar în cazul detectării
de erori, acestea sunt semnalate PCS-ului prin intermediul modemului, urmate
de restartarea automată a ECA;
161
 nivel local: poate fi comandată efectuarea testelor complete ale
aparatului de la un calculator personal sau un terminal compatibil VT100
conectate la portul local de acces;
 nivel distant: testarea echipamentului poate fi comandată, de la
distanţă, de către PCS.
Efectuarea operaţiilor de diagnoză poate fi permisă, opţional, în mod
selectiv, numai operatorilor avizaţi, selecţia acestora fiind realizată prin parole
de acces.
Controlul şi monitorizarea sistemului
Controlul şi monitorizarea aparaturii de transmisuni pe suport optic se

realizează, prin intermediul ECA, de la un Punct Central de Supraveghere
(PCS). Dialogul între PCS şi ECA este de tip interogare-răspuns, fiind
structurat ierarhic pe modelul CLIENT-SERVER (descris în cap.2). PCS-ul
joacă rolul de client care cere server-ului (ECA în acest caz) efectuarea unor
anumite servicii specifice managementului sistemelor de telecomunicaţii
(configurări de echipamente, detectarea defectărilor, monitorizarea
performanţelor acestora, etc.)
Identificarea echipamentelor accesate se realizează pe baze topologice,
în funcţie de portul fizic al PCS-ului la care acestea sunt conectate.
Din punct de vedere funcţional, în fig. 4.15 sunt reprezentate principalele
blocuri aflate între operatorul uman aflat la consola PCS şi terminalul de
transmisiuni care este monitorizat.
Legendă:
PCS MApl – Modul Aplicaţie;
MBD – Modul Bază de Date;
MApl
MIfC – Modul Interfaţă de Comunicaţie;
MCM – Modul Control şi Monitorizare;
UTO – Unitate Terminală Optică.
MBD
ECA
UTO
MIfC IfC MCM
Fig. 4.15. Schema blocurilor funcţionale ce deservesc comunicaţia PCS-ECA
Aceste blocuri funcţionale sunt astfel constituite încât urmăresc structura

logică a desfăşurării proceselor de management.
162
Operatorul uman, aflat la consola PCS, lansează o cerere către sistem.
Modulul de aplicaţie interpretează această cerere şi apelează baza de date
pentru a culege datele necesare. Acest modul preia apoi cererea,
individualizează abonatul căruia îi este adresată şi o transmite în formatul
necesar către modulul interfaţă de comunicaţie. MIfC este “transparent” faţă de
obiectul cererii, rolul său fiind doar de a transmite neeronată cererea la modulul
corespunzător, MIfC, din ECA, căruia îi este adresată. MIfC din ECA preia
mesajul, îl decodifică şi îl transmite mai departe către modulul de control şi
monitorizare. Acesta interpretează cererea şi interoghează la rândul său
unitatea terminală optică. Răspunsul obţinut de la aceasta parcurge tot circuitul
în sens invers.
Protocolul de comunicaţie între PCS şi ECA
Între MIfC din compunerea PCS şi MIfC din ECA se poate face un
schimb de informaţii, bidirecţional, pe baza unui protocol de comunicaţie, în
mod “transparent”.
Protocolul pe care l-am realizat este de tip “legătură de date”,
asemănător protcolului descris în capitolul 3, diferenţa fiind că în acest caz s-a
preferat un protocol de comunicaţie asincron, adaptat principalelor cerinţe ale
acestor tipuri de legături:
 nivel mediu de erori pe linie ≈ 10-4;
 capacitate mică a canalelor de transmisie (9600 bps);
 autenticitate mare cerută pentru informaţie.
Între cele două noduri terminale, datele vor circula sub formă de cadre de
comandă, cadre de informaţie şi cadre de supraveghere (fig. 4.16).
Câmp de
Comandă
Flag1 Alarme control Flag2
ECA
erori
Cadru de comandă
Câmp de
Flag3 Informaţie control Flag4
erori
Cadru de informaţie
Câmp de
Flag1 Alarme control Flag2
erori
Cadru de supraveghere
Fig. 4.16. Tipuri de cadre specifice protocolului de comunicaţie ECA - PCS
În fig. 4.17 sunt prezentate în mod detaliat detailat toate tipurile de cadre
utilizate în cadrul protocolului de comunicaţii, precum şi componenţa acestora.
163
Delimitarea cadrelor schimbate între ECA şi PCS se face prin intermediul
indicatorilor de început şi sfârşit cadru F1 şi F2. Fiecare cadru conţine un câmp
de control al erorilor, construit prin sumarea orizontală modulo 128 a tuturor
octeţilor din cadru, în afara celor de control.
Protocolul construit permite o verificare complexă a bunei funcţionări a
legăturii, etapele verificării fiind următoarele:
1. se verifică corecta recepţionare a indicatorilor de început şi de sfârşit
F1 şi F2;
2. se verifică dacă suma de control calculată la recepţie este identică cu
cea care a fost recepţionată;
3. se verifică că întotdeauna al doilea câmp al unui cadru de control este
“a”;
4. se verifică apoi sintactic cadrul, deci dacă respectiva comandă face
parte din setul de comenzi acceptate de ECA în acea etapă a programului;
5. se verifică timpul între transmisiile a două caractere succesive, care nu
trebuie să fie mai mare de 5 secunde în general.
Fiecare din tipurile de cadre enumerate mai sus au un rol specific în
comunicaţia dintre ECA şi PCS:
 cadrele de comandă sunt transmise de la PCS la ECA, iar ca rezultat al
acestora ECA poate răspunde tot cu cadre de comandă sau cu cadre de
informaţie în funcţie de destinatarul comenzii. Pentru comenzi care îi sunt
adresate, ECA răspunde tot cu cadre de comandă, iar pentru comenzi care sunt
adresate rack-ului răspunde numai cu cadre de informaţie;
 cadrele de informaţie sunt transmise numai de la ECA spre PCS şi
conţin răspunsul pe care rack-ul îl întoarce la primirea unei comenzi de la
utilizator;
 cadrele de supraveghere se schimbă între ECA şi PCS numai la
iniţiativa PCS şi au rolul de suport pentru întreţinerea funcţionalităţii liniei.
O sesiune de lucru ECA – PCS este alcătuită din următoarele etape:
1. iniţierea legăturii;
2. supravegherea calităţii legăturii;
3. transmiterea informaţiilor utile;
4. închiderea legăturii.
Responsabil pentru supravegherea desfăşurării corecte a acestor etape
este unitatea de management a sistemului, PCS-ul.
Verificarea permanentă a calităţii legăturii este realizată prin transmiterea
periodică a unor “cadre de supraveghere”, în paralel cu efectuarea unui calcul
statistic pentru determinarea aproximativă a ratei de erori existentă la un
moment dat pe linia de comunicaţii.
Informaţia este transmisă în pachete şi nu se trece la următorul pachet
până când nu se primeşte confirmarea recepţionării corecte a pachetului
anaterior. Acest mod de transmisie este avantajat de debitul scăzut al datelor
ce se vehiculează pe acest canal, combinat cu o rată de erori medie a acestuia.
Programele sunt scrise în limbajul C pentru modulul MIfC localizat pe
ECA.
164
F1 a RegStAl c NrCanal r NrRec1 NrRec2 CTRL F2
F3 Informaţie CTRL F4
a) Formatul cadrului ce conţine informaţia recepţionată de către ECA şi transmisă spre PCS
F1 a RegStAl p NrPort CTRL F2
b) Formatul cadrului ce conţine starea alarmelor la porturile ECA
F1 a RegStAl c NrCanal CTRL F2
c) Formatul cadrului emis de ECA la selecţia distantă a unui port
F1 a RegStAl p NrPort CTRL F2
d) Formatul cadrului emis de ECA la selectarea unui port ca port activ
F1 a RegStAl c NrPortT t e/g CTRL F2
e) Formatul cadrului ce conţine rezultatul testării distante a unui port al ECA
F1 a RegStAl c NrRec1 NrRec2 Informaţie CTRL F2
f) Formatul cadrului de retransmisie a datelor spre PCS
F1 a RegStAl s RegStP p NrPort CTRL F2
g) Formatul cadrului ce conţine informaţia privitoare la starea funcţională a porturilor ECA
165
Legendă:
F1  indicator început cadru;

F2  indicator sfârşit cadru;
F3  indicator început cadru auxiliar;
F4  indicator sfârşit cadru auxiliar;
a  caracter ce precede octetul de stare al alarmelor;
RegStAl  registru stare alarme la ECA;
c  caracter ce precede numărul canalului ECA de la care s-a făcut recepţia;
NrCanal  numărul canalului de la care s-a făcut recepţia;
r  caracter ce precede numărul real al caracterelor recepţionate
de către ECA de la echipamentele deservite;
NrRec1  digitul zecilor din numărul caracterelor recepţionate;
NrRec2  digitul unităţilor din numărul caracterelor recepţionate;
CTRL  octet de control al cadrului transmis;
Informaţia  informaţia efectivă recepţionată de ECA de la echipamentele
deservite şi retransmisă spre PCS;
p  caracter ce precede numărul portului activ în acel moment pe
ECA;
NrPort  numărul portului activ pe ECA;
NrPortT  numărul portului testat distant pe ECA;
e  caracter ce indică incorecta funcţionare a portului testat;
g  caracter ce indică corecta funcţionare a portului testat;
s  caracter ce precede registrul de stare al porturilor;
RegStP  registru stare porturi;
Fig. 4.17. Formatul cadrelor ce pot fi transmise de la ECA spre PCS
Trebuie remarcat că pe echipamentul PCS, modulul MIfC este, de fapt,

divizat în două componente: în modulul propriu-zis de comunicaţie (MC) şi un
modul supervizor de reţea (MSR), ca în fig. 4.18.
MSR Reţea Nivel 3 OSI

MifC de la PCS
Legătură de Nivel 2
MC date OSI
Fig. 4.18. Organizarea funcţională a MIfC de pe PCS
166
Funcţionarea programului de pe ECA
Programul de pe ECA este alcătuit dintr-un set de programe, fiecare

specializat pe realizarea unor anumite funcţiuni:
 programul principal de supervizare: este programul care asigură
iniţializarea ECA la pornire, integrarea funcţională a tuturor programelor
componente şi cel care decide restartarea ECA în cazul unor erori mari de
procesare raportate de programul de auto-verificare al ECA (fig. 4.23);
 programul de comunicaţie cu PCS-ul: este programul ce asigură
implementarea protocolului de comunicaţie între ECA şi PCS, asigurând un flux
de date transparent, fără erori spre ECA (fig. 4.22);
 programul de comunicaţie cu ramele: este responsabil cu transmisia
şi recepţia corectă spre/dinspre rame a comenzilor şi informaţiilor primite de la
PCS (fig. 4.20);
 programul de supraveghere şi procesare al alarmelor existente pe
rame: monitorizează permanent starea intrărilor de alarme dinspre ECA, având
un algoritm propriu de luare a deciziei existenţei unei alarme la o ramă (fig.
4.19);
 interpretorul de comenzi: decodifică comenzile primite de la PCS şi cu
avizul programului de supervizare execută aceste comenzi;
 programul de verificare funcţională a porturilor ECA: la iniţiativa
interpretorului de comenzi poate iniţia şi desfăşura un program de verificare
funcţională parţială sau totală a porturilor ECA, prin transmiterea unei secvenţe
de testare spre acestea şi interpretare a datelor recepţionate ca rezultat al
testului (fig. 4.21);
 programul de verificare a bunei funcţionări a ECA: urmăreşte
permanent două aspecte principale ale unei bune funcţionări a ECA:
 funcţionarea principalelor blocuri hardware – memorie EPROM,
RAM, logica de comandă, porturi I/O, etc;
 funcţionarea globală a software-ului, prin efectuarea unor minicicluri
de testare din 50 în 50 de ms, în cazul blocării programului în această etapă
transmite programului de supervizare cererea de restartare a ECA.
Metode de testare a ECA
ECA este un echipament complex, testarea acestuia putându-se executa

atât automat la pornire, cât şi manual, prin intervenţia unui operator extern.
Testarea manuală se poate realiza de către trei tipuri distincte de operatori:
• local, prin intermediul unui buton de test (TEST);
• local, prin intermediul unui terminal ASCII conectat la portul de diagnoză;
• distant, de la PCS, prin intermediul cablului conectat la mufa notată PCS.
Subrutinele de testare permit realizarea unor teste complexe, atât asupra
modulelor interne ale echipamentului, cât şi asupra conexiunilor externe ale
acestuia.
Initializare sub
procesare 167
alarme
Formez masca de
citire a alarmelor
Citesc starea
alarmelor de la
porturi
NU D
Verific
RegStAlVechi ≠ A
RegStAlNoi
Întârziere 20 ms
Recitesc starea
alarmelor de la
porturi
NU DA
Verific
RegStAlVechi ≠
RegStAlNoi & dacă cele
două citiri sunt identice
Reactualizez
RegStAl
Sfârşit procesare Afişez

alarme modificarile la
DGZ şi PCS
Fig. 4.19. Organigrama funcţională a subrutinei de procesare a alarmelor
Iniţializare sub
comunicaţie
168
ramă
Temporizare 30 ms
Transmit un caracter spre PCS;

Incrementez contorul transmisiilor.
Temporizare pre-
programată
DA NU
Terminat
transmisie ?
Temporizare 30 ms
Recepţionez un caracter de la ramă;

Incrementez contorul caracterelor
recepţionate.
NUN DA
U Contoar car.
Rec. ≤ 80
N D
U Timp scurs ≤ A
5 sec.
Descarc datele
Sfârşit subrutină de comunicaţie
recepţionate în buffer-ul de
cu rama
recepţie ramă
Fig. 4.20. Organigrama funcţională a subrutinei de comunicaţie ECA cu o ramă
Iniţializare sub
verificare stare
port ECA
169
Citesc datele de la consolă
sau distant
NU DA
Intrări corecte ?
Setez portul la care

voi face testul!
Transmit şirul de test spre portul

dorit
Aştept 50 ms
NU DA
Recepţie corectă ?
Retransmit şirul de test spre

portul dorit
Aştept 100 ms
NU DA
Recepţie corectă ?
Afişează că portul Afişează că portul

funcţionează
funcţionează
CORECT
INCORECT
Reactualizează
RegStP
Sfârşit subrutină verificare

stare port
Fig. 4.21. Organigrama funcţională a subrutinei de verificare a funcţionalităţii

unui port de pe ECA
Iniţializare sub
recepţie de la
PCS
170
NU DA
Caracter nou
recepţionat ?
DA NU
Cadru în
curs de
NU DA
Caracter NU
Rec. = F2 ? Caracter
Rec. = F1 ?
DA
Resetez cadrul în curs;

Descarc car. Rec. în
Reiniţializez contoarele.
buffer-ul temporar
Incrementez Calculez caracterul de Setez indicatorul cadru în

contoar car. control CTRL curs de recepţie
Rec.
DA NU DA
NU
Contor car. Verific CTRL
Rec ≤ Max corect ?
Resetez cadrul în curs; Descarc buffer-ul

Reiniţializez contoarele. temporar în cel de
recepţie
Verifică datele din

punct de vedere
sintactic şi le
transferă buclei
principale
Sfârşit subrutină recepţie

date de la PCS
Fig. 4.22. Organigrama funcţională a subrutinei de recepţie a ECA
Iniţializare
program
principal ECA
171 principalele
Testare
componente ale ECA
Lansează subrutină verificare

alarme
NU DA
Verifică recepţie
de la PCS ?
NU DA
Verifică recepţie Lansează subrutină procesare

de la consolă ? comunicaţie cu PCS
Lansează subrutină procesare

meniu
Fig. 4.23. Organigrama funcţională a programului principal al ECA
Testele interne se efectuează automat la pornire şi verifică buna

funcţionare a:
 memoriei RAM interne a microcontroller-ului (128 bytes);
 memoria RAM externă (32 Kb);
 memoria ROM externă (32 Kb);
 a microprocesorului pe 8 biţi inclus în microcontroller.
Testele externe asigură verificarea funcţionării corecte a următoarelor
componente:
 blocul de selecţie a porturilor;
 echipamentul vizual de afişare;
 porturile de comunicaţie cu: terminalul de diagnoză, PCS-ul,
echipamentele de multiplexare.
Descrierea testelor:
172
Verificarea memoriei RAM: se efectuează o verificare complexă, prin
operaţii succesive de salvare, scriere, citire şi refacere a întregii memorii RAM,
raportându-se locaţiile de memorie defecte.
Verificarea memoriei ROM: se efectuează calculul sumei de control şi
compararea rezultatului acestuia cu valoarea preânscrisă la o anumită locaţie în
ROM.
Verificarea blocului de selecţie a porturilor: la o comandă externă
este afişată o anumită schemă optică prestabilită, care poate fi verificată vizual
de către operatorul care efectuează testul.
Verificarea porturilor de comunicaţie: presupune existenţa unui
port de conectare, exterior, pe care sunt realizate următoarele legături:
 transmisia legată cu recepţia (pinul 2 legat la pinul 3) în cazul verificării
comunicaţiei;
 pinul de alarmă legat la masă (pinul 1 legat la pinul 7).
Pentru verificarea comunicaţiei programul transmite la portul selectat o
secvenţă de biţi după un model cunoscut anterior, la recepţie urmărindu-se
primirea aceleiaşi secvenţe.
La verificarea alarmei, simpla introducere a conectorului special de
alarme pe un port anume ar trebui să conducă la afişarea unei alarme pe
canalul respectiv:
 clipirea alternantă de 4 ori a LED-ului corespunzător canalului respectiv
şi a LED-ului asociat canalului de diagnoză, timp de 80 de ms;
 afişarea la portul de diagnoză a mesajului:
********************
| Alm. nr. = 4 |
********************,
exemplu pentru cazul în care am avea alarmă pe portul cu numărul 4;

 afişarea aceluiaşi mesaj la portul corespunzător conexiunii cu PCS-ul;
Verificarea şi setarea modemurilor:
Modemurile acceptă mai multe tipuri de teste, cât şi reconfigurarea de la

distanţă. Pentru toate aceste tipuri de teste trebuie intrat în modul linie de
comandă modem.
a. buclă locală de tip analogic
Se vor trimite spre modem caracterele “at&t1” urmate de <CR>.

Modemul trebuie să răspundă cu “OK!” în cazul efectuării corecte a
comenzii şi apoi să efectueze o buclă analogică internă la ieşirea spre linie.
Din acel moment orice caracter introdus de la consolă va trebui “buclat“
de către modem şi va apărea pe ecranul terminalului. Prin caracterele “at&t0”
urmate de <CR> se va ieşi din modul de testare anterior.
b. buclă locală de tip digital
173
Se intră în modul de comandă prin tipărirea carcacterelor “+++”. După
circa o secundă modemul local a realizat o buclă digitală. De la modemul
distant se pot trimite acum scurte mesaje care trebuie să fie reîntoarse de bucla
digitală realizată local. Pentru ieşire din acest mod de testare se trimite spre
modemul local setul de caractere “at&t0”, urmat de <CR>.
c. buclă distantă de tip digital
Pentru aceasta se va ieşi din legătura realizată cu corecţie de erori prin

comanda “atz”, care va reseta modemul de la PCS. Apoi se va încărca în acest
modem comanda “at&m4&w”, urmată de <CR>, iar la primirea răspunsului
“OK!” modemul va fi resetat pentru încărcarea automată a noilor parametri prin
comanda “atz”. Din acest moment modemurile vor reiniţia automat o nouă
legătură, în cazul acesta fără corecţie de erori. După realizarea legăturii, pe
ecranul PCS-ului va apărea mesajul “CONNECT TO 9600”. Acum poate fi
efectuat testul de buclare digitală la distanţă, trimiţându-se un set de caractere
“+++” pentru trecerea în modul comandă, după care prin trimiterea setului de
caractere “at&t6”, urmate de caracterul <CR> se va trece modemul distant în
starea de buclă digitală la ieşirea spre ECA. Odată efectuată buclarea la
distanţă pot fi trimise orice caractere de la consolă, acestea ajungând la
modemul distant de unde se vor reîntoarce la modemul generator, care le va
redirecţiona spre ecranul terminalului PCS.
Ieşirea din acest mod de testare se va efectua tot cu ajutorul comenzii
“at&t0”, urmată de caracterul <CR>.
Dialogul ECA – Utilizator
Setul de comenzi acceptat de către ECA, prin intermediul interpretorului

de comenzi, poate fi împărţit în două, în funcţie de destinatarul acestor
comenzi:
 comenzi destinate ECA, se caracterizează prin faptul că toate încep prin
caracterul “#” şi conţin numai caractere text mici;
 comenzi destinate ramelor, toate acestea folosind caractere text mari şi
se încheie cu <CR>.
Comenzile destinate ECA pot avea până la 40 de caractere ASCII
lungime, trebuie să înceapă obligatoriu cu caracterul “#”, să conţină numai litere
mici sau cifre de la “0” la ”9”, iar între transmisiile a două caractere succesive nu
trebuie să fie în general o pauză mai mare de 5 secunde.
Pachetul de comenzi destinat ECA este descris în continuare:
 “#a” determină ECA să transmită spre DGZ şi spre PCS starea
registrului de alarme:
• spre DGZ se va transmite caracterul “a” urmat de octetul de
alarme la care s-a adăugat pentru formatare valoarea 48D;
• spre PCS pot fi trimise două feluri de mesaje, în funcţie de
regimul de lucru:
 în regim demo se va transmite caracterul “a” urmat de octetul de
alarme la care s-a adăugat valoarea 48D;
 în regim real se va transmite un cadru cu următorul format
“F1aApPCTRLF2”, unde:
174
- F1, indicator 1 cu valoarea 1D;
- F2, indicator 2 cu valoarea 2D;
- a, caracterul “a”;
- A, octetul de alarme, care conţine starea alarmelor
la porturile de la 2 ÷ 7 (canalele 1 ÷ 6), asociat în ordinea C1 la b 0, C2 la b1
etc. la care s-a adăugat pentru formatare valoarea 48D;
- p, caracterul “p”;
- P, numărul canalului selectat în ASCII, cu valori de
la 48D ÷ 55D;
- CTRL, caracterul de control.
 “#b” determină ECA să retransmită spre PCS bufferul datelor

recepţionate în următorul format: “F1aAcNICTRLF2”, unde:
• F1 este indicator început cadru şi are valoarea 1D;
• F2 este indicator sfârşit de cadru şi are valoarea 2D;
• a, adică caracterul “a”;
• A, octetul ce conţine registrul de alarme;
• c, adică caracterul “c”;
• N, numărul de caractere, pe doi octeţi, în format ASCII,
recepţionate de la ramă, fiind contorizate şi caracterele LF introduse de ECA
pentru formatare;
• I, câmp de informaţie care conţine caracterele recepţionate de la
ramă, la care s-au adăugat şi caracterele LF după fiecare CR recepţionat;
• CTRL, caracterul de control.
 “#c” urmat de o cifră de la “0” la “7” (corespunzătoare unui canal din
cele 8) are drept rezultat selectarea timp de o secundă a canalului ales, acţiune
semnalizată şi prin aprinderea LED-ului asociat canalului, în timp ce la
terminalul de DGZ şi cel de la PCS se afişează caracterul ”c” urmat de numărul
canalului introdus;
 “#d”, pentru setarea timpului de citire a unei rame. După introducerea
acestei comenzi va fi afişat un mesaj privind valoarea acestui interval, valoare
care este măsurată în multipli de 500 de ms. Acest mesaj va fi formatat în
funcţie de regimul în care se află ECA:
• regim demo:
•
********************
| Se modifica timp |
| Vechea valoare = x
********************,
unde x reprezintă valoarea indicelului de multiplicare a timpului setată în

acel moment;
În maxim 5 secunde trebuie introdus noul indice de multiplicare, cu valori
în intervalul “1” ÷ “9”, deci se poate obţine o valoare absolută pentru acest
interval temporal între 500 ÷ 4500 ms.
Observaţie: La pornirea programului indicele de multiplicare este setat la
2, deci timpul de citire a unei rame este de 1 secundă.
• regim real: va fi afişat un cadru cu următoarea alcătuire:
“F1aAdTCTRLF2”, unde câmpurile componente au următoarea
175
semnificaţie:
 F1, indicator început de cadru, cu valoarea 1D;
 F2, indicator sfârşit de cadru, cu valoarea 2D;
 a, caracterul “a”, pregăteşte afişarea registrului de alarme;
 A, octetul ce conţine registrul de alarme;
 d, caracterul “d”, pregăteşte afişarea indicelui de multiplicare;
 T, indicele de multiplicare, care a fost formatat prin adăugarea
valorii 48D;
 CTRL, octetul de control al cadrului.
Exemplu afişare cadru: “ a8d63”.
 “#f” este folosit pentru setarea pauzei între transmisia a două
caractere succesive spre ramă. Pauza poate fi selectată în intervalul 0 ÷ 180
ms, în multiplii de indicele de multiplicare, care este de 20 de ms. După
introducerea acestei comenzi, în funcţie de regimul în care este ECA, pe
consola activă va apărea următorul mesaj:
• regim demo:
********************
| Pauza intre trs. |
| Vechea valoare = 7
********************,
în cazul în care vechea valoare a indicelui de multipicare era 7, deci pauza era
de 140 ms.
• regim real:
va fi afişat un cadru “F1aAfFCTRLF2”, unde
 f, caracterul “f”, pregăteşte afişarea indicelui de multiplicare;
 F, indicele de multiplicare, care a fost formatat prin adăugarea
valorii 48D;
Exemplu afişare cadru: “ a8f76”.
După afişarea acestui mesaj de întâmpinare ECA aşteaptă timp de 5

secunde introducerea unei valori pentru indicele de multiplicare, în intervalul “0”
÷ “9”. Dacă este depăşit timpul de aşteptare sau valoarea introdusă nu este în
intervalul impus, programul va ignora această comandă şi va reveni în starea
de aşteptare. Dacă condiţiile sunt îndeplinite corect, în funcţie de regimul
selectat, pe consola activă va fi afişat următorul mesaj:
• regim demo:
********************
| Noua valoare = 6
********************,
176
în cazul în care valoarea nou introdusă este 6 pentru indicele de modulaţie.
• regim real:
va fi afişat un cadru “F1aAfFCTRLF2”, unde
F1, indicator început de cadru, cu valoarea 1D;


F2, indicator sfârşit de cadru, cu valoarea 2D;

 f, caracterul “f”, pregăteşte afişarea indicelui de multiplicare;
 F, noul indicele de multiplicare, care a fost formatat prin
adăugarea valorii 48D;
Exemplu afişare cadru: ” a8f66”
Observaţie: La pornirea programului indicele de multiplicare este setat la

3, deci intervalul iniţial între transmisiile succesive a două caractere este de 60
de ms.
 “#g” este destinat afişării la consola PCS a registrului de stare al
porturilor. Mesajul afişat este formatat într-un cadru de următoarea formă:
“F1aAsRpPCTRLF2”, unde:
 s, caracterul “s”, pregăteşte afişarea registrului de stare al
porturilor;
 R, registrul de stare a porturilor, care a fost formatat prin
adăugarea valorii 48D;
 p, caracterul “p”, pregăteşte afişarea numărului portului activ în
acel moment pe ECA;
 P, numărul portului selectat pe ECA, formatat prin adăugarea
valorii 48D, intervalul 48D ÷ 55D;
 “#l” va determina ECA, indiferent de regimul în care se află să afişeze la
consola activă în acel moment meniul disponibil, în formatul de mai jos:
********************
| Meniu comenzi |
| a - citesc Al. |
| b - retransmisie|
| c - sel. port |
| d - sel. timp |
| f - sel. pauza |
| g - citesc StP. |
| l - meniu |
| m - regim PCS |
177
| n - regim DGZ |
| p - comut. port |
| r - regim real |
| t - verif. tot. |
| v - verif. port |
| u - regim demo. |
| x - RESET |
| y - C-da Modem |
********************.
 “#m” va transfera comanda de la portul de diagnoză (DGZ) la portul de

supervizare (PCS). De asemenea, va comuta modul de lucru trecând în modul real,
cu detecţie de erori. După efectuarea acestei comenzi pe ecranul terminalului de
diagnoză, ca şi pe cel de supervizare va apare mesajul:
********************
| Comanda la PCS |
********************
 “#n” va transfera comanda de la portul de supervizare (PCS) la portul de

diagnoză (DGZ). După efectuarea acestei comenzi pe ecranul terminalului de
diagnoză, ca şi pe cel de supervizare va apare mesajul:
********************
| Comanda la DGZ |
********************
 “#p” urmat de un caracter în intervalul de la “0” la “7“ are drept rezulat

selectarea unui canal de lucru real pentru restul comenzilor ce vor fi trimise de la
operator spre ramă. În mod implicit este setat primul canal spre rame, canalul 1, deci
portul 2. Odată introdusă această comandă, în funcţie de modul de lucru în care se
află setată ECA, pe ecranul terminalului de diagnoză, cât şi pe cel al portului de
supervizare pot apare următoarele mesaje:
• regim demo:
********************
| CANALUL NR. = 5|
********************,
în cazul în care a fost selectat portul cu nr. 5;
• regim real:
“F1aApPCTRLF2”, unde
 a, caracterul “a”, semnifică afişarea registrului de alarme;
 A, registrul de alarme la care s-a adăugat valoarea 48D;
178
 p, caracterul “p” ce pregăteşte afişarea numărului de port
selectat;
 P, numărul portului selectat, intervalul de afişare fiind “0” până la
“7” în ASCII sau 48D ÷ 55D;
 CTRL, caracterul de control, modulo 128;
Exemplu afişare în regim real: “ a8p5=”.
Observaţii:
 pentru protecţia la blocare se impune un interval de 5 secunde între
recepţionarea carcaterului “p” şi recepţionarea numărului portului, iar cazul
depăşirii acestui interval, programul se întoarce automat în bucla principală;
 dacă în loc de numărul portului dorit se introduce “CR”, indiferent de
regim, pe ecran se afişează numărul portului curent selectat;
 orice altă comandă introdusă va determina programul să o ignore şi să
se apoi întoarcă în bucla principală.
 “#r” are drept rezultat comutarea din regimul demonstrativ în regimul

real de lucru, cu detecţie de erori. Confirmarea schimbării modului de lucru se
va face prin afişarea la consola activă a următorului mesaj:
********************
| Regim interogare|
********************
 “#t” are drept rezultat efectuarea unui test global al porturilor, în ordine
crescătoare de la 0 la 7, iar apoi efectuarea aceluiaşi test în ordine
descrescătoare. Pentru fiecare test în parte vor fi afişate rezultatele ca le testele
efectuate prin comanda “v”;
 “#u” are drept rezultat comutarea din regimul real de lucru în regimul
demonstrativ. Confirmarea schimbării modului de lucru se va face prin afişarea
la consola activă a următorului mesaj:
********************
| Regim diagnoza |
********************
 “#v” urmat de un caracter de la “0” la “7” determină ECA să pornească

un program de verificare a bunei funcţionări a portului dorit. Pentru protecţie la
blocare, a fost prestabilit un interval maxim de 5 secunde în care poate fi
introdusă cifra corespunzătoare valorii portului testat. În cazul în care acest
prag va fi depăşit, programul se va întoarce în bucla principală, aşteptând
introducerea altei comenzi. Aceeaşi decizie va fi luată şi în cazul în care
numărul portului nu este introdus corect, în intervalul impus.
Pentru verificare va fi trimisă, spre portul selecţionat, o secvenţă de
caractere prestabilite, iar la port va trebui să fie conectată o mufă de test
(descrisă anterior). În cazul unei funcţionări corecte a portului respectiv va fi
recepţionată secvenţa de caractere trimise în perioada testării. Modul de afişare
a rezulatului testului depinde de regimul în care se află ECA în acel moment:
• regim demo: Pe ecranul terminalului conectat la portul DGZ va
apare numărul canalului testat, urmat de caracterul “G” în cazul unei funcţionări
179
corecte sau de caracterul “E” în cazul unei erori. În paralel este asigurată o
confirmare vizuală pentru operator, prin intermediul LED-urilor situate pe panoul
frontal: dacă rezultatul testului este pozitiv se va aprinde timp de o secundă, în
mod continuu, LED-ul corespunzător canalului respectiv, iar în cazul unei
funcţionări incorecte se vor aprinde alternant (de 4 ori consecutiv, timp de 80
ms), LED-ul asociat canalului testat şi LED-ul de DGZ sau cel de la PCS;
• regim real: spre portul PCS va fi trimis un cadru cu următorul
format: “F1aAcNtRCTRLF2”, unde câmpurile au următoarea semnificaţie:
 F1, indicator de început cadru cu valoarea 1D;
 F2, indicator de sfârşit cadru cu valoarea 2D;
 a, caracterul “a”;
 c, caracterul “c”;
 N, octet ce conţine, în ASCII, numărul canalului care a fost
testat, cu valoare de la 48D la 55D;
 t, caracterul “t”, semnificând faptul că urmează afişarea
rezultatului testului;
 R, rezultatul testului, “e” în cazul în care testul a eşuat şi ”g”
dacă a reuşit;
 CTRL, caracter de control al cadrului.
Observaţie: Odată cu afişarea rezulatelor testului va fi actualizat şi
registrul cu starea porturilor, astfel că pentru test reuşit va fi setat bitul
corespunzător numărului portului (porturile sunt numerotate de la 0 la 7, la fel
ca biţii corespunzători din registrul de stare a porturilor), iar pentru test nereuşit
va fi resetat bitul respectiv.
 “#x” va conduce la resetarea echipamentului ECA, fiind echivalentă cu
efectuarea unui reset “la cald”. Confirmarea acceptării comenzii se va face
vizual, prin afişarea la consola activă a următorului mesaj:
********************
|ECA SE RESTARTEAZA|
********************.
 “#y” comandă de acces la modul de lucru linie de comandă a

modemului ataşat ECA, destinată testării şi setării modemului în modul de lucru
real.
Comenzile destinate ramelor pot avea până la 80 de caractere ASCII
lungime, trebuie să se termine obligatoriu cu caracterul “CR”, să conţină numai
litere mari sau cifre de la “0” la ”9”.
Aceste comenzi vor fi transmise spre rame în mod transparent, inclusiv
caraterul “CR”. Odată transmisă o linie de comandă spre ECA, acesta o va
transmite spre portul activ din acel moment (setat cu “#p…”), pauza dintre
transmisiile a două caractere succesive fiind cea setată prin comanda “#d…”
(valoarea implicită fiind de 60 de ms). Următoarea etapă este recepţionarea
răspunsului de la ECA. Pentru aceasta ECA va “asculta” rama un timp egal cu
cel setat de utilizator prin comanda “#f..”, implicit acesta fiind de o secundă.
Ieşirea din modul ascultare se va face fie la expirarea timpului setat, fie
la depăşirea numărului limită de caractere recepţionate, adică la recepţionarea
celui de al 81lea caracter. Caracterele recepţionate vor fi formatate prin
180
adăugarea caracterului “LF” înaintea fiecărui caracter “CR” recepţionat de la
ramă, urmând apoi stocarea lor într-un buffer de rezervă de unde vor putea fi
rechemate de la PCS prin comanda “#b”, descrisă în meniul de comenzi
accesibile utilizatorului. Transmiterea iniţială a datelor recepţionate spre PCS se
va face respectând un format anume, în funcţie de regimul de lucru în care se
află ECA.
• regim demo: Datele vor fi precedate de un antet care va anunţa
de la ce port au fost recepţionate şi numărul real de caractere recepţionate de
la ramă:
********************
| CANALUL NR. = 6|
| CARACT. REC.= 02|
********************
g,
în exemplul de mai sus datele au fost recepţionate de la portul numărul 6, erau

în număr de 2 şi acestea au fost caracterele “g” şi “CR”.
• regim real: Datele vor fi formatate într-un cadru ce va facilita
detecţia de erori la PCS şi anume: “F1aAcCrR1R2CTRLF2F3ICTRLF4”, unde
câmpurile au următoarea semnificaţie:
 F1, indicator început de cadru control, cu valoarea 1D;
 F2, indicator sfârşit de cadru control, cu valoarea 2D;
 c, caracterul “c”, pregăşte afişarea canalului de unde au fost
recepţionate datele;
 C, numărul portului de la care a fost efectuată recepţia, în format
ASCII, cu valori de la 48D ÷ 55D;
 r, caracterul “r”, pregăteşte afişarea numărului de caractere
recepţionate, pe doi octeţi;
 R1, cifra zecilor la număr, care a fost formatată prin adăugarea
valorii 48D;
 R2, cifra unităţilor la număr, care a fost formatată prin adăugarea
valorii 48D;
 CTRL, octetul de control al cadrului de control.
 F3, indicator început de cadru de informaţie, cu valoarea 3D;
 F4, indicator sfârşit de cadru de informaţie, cu valoarea 4D;
 I, câmpul de informaţie ce conţine datele recepţionate de la ramă;
 CTRL, octetul de control al cadrului de control.
4.3 Concluzii
În cadrul acestui capitol a fost prezentat modul de realizare a

managementului în cadrul reţelelor SDH.
Prima parte, folosind noţiunile şi principiile generale introduse în cap. 2,
au fost descrise sistemele de tipul SDH, acestea putând fi asimilate unei
structuri particulare de sistem cu o arhitectură OSI.
181
Partea a doua a capitolului este dedicată prezentării contribuţiilor pe care
le-am avut în realizarea unui sistem de management integrat pentru o reţea de
transmisiuni pe suport de fibră optică.
Contribuţia adusă de mine la realizarea acestui sistem de management,
realizat în colaborare cu INSCC, constă în următoarele:
 proiectarea şi realizarea practică a echipamentului de colectare a
alarmelor, ECA, în principal unitatea centrală şi interfaţa de comunicaţie cu
clientul;
 proiectarea protocolului de comunicaţie folosit ca suport pentru sistemul
de management (pe baza realizărilor prezentate în cap. 3);
 realizarea în totalitate a setului de programe rezidente pe ECA;
 participarea la definitivarea cerinţelor funcţionale ale bazelor de date
relaţionale de pe PCS;
 realizarea setului de programe ce asigură suportul de comunicaţie pentru
PCS (pentru comunicaţia cu ECA subordonate şi prin intermediul acestora cu
obiectele de administrat);
 proiectarea şi implementarea protocolului de comunicaţie dintre sistemul
de management şi echipamentele ce trebuiau administrate;
 echiparea, punerea în funcţiune şi setarea echipamentelor ECA.
În continuare, sunt descrise cerinţele funcţionale generale pe baza
cărora a fost construit sistemul precum şi baza de date cu informaţii de
management, realizată conform modelului MIB. Au fost utilizate pentru
transportul informaţiilor de management canale de date externe sistemului
(DCC), iar protocoalele de comunicaţie le-am realizat particularizând modelul
folosit pentru canalul comun de semnalizare a cărui realizare am descris-o în
capitolul anterior. Sistemul de management pe care l-am realizat este
operaţional din perioada decembrie 1999 pe tronsonul B de transmisiuni pe
suport de fibră optică al RomTelecom şi funcţionează în condiţii optime, ceea ce
dovedeşte viabilitatea modelului de reţea de management realizată şi
robusteţea protocoalelor de comunicaţii implementate.
182

Managementul Reţelelor SDH - Teorie Şi Implementare Practică

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Managementul Reţelelor SDH - Teorie Şi Implementare Practică

Transféré par

Droits d'auteur :

Formats disponibles

www.cartiaz.

ro – Carti si articole online gratuite de la A la Z

Managementul reţelelor SDH – teorie şi implementare

4.1 Managementul reţelelor SDH – prezentare teoretică

4.1.1 Prezentare generală

În capitolele precedente au fost prezentate principiile ce guvernează

2.capacitatea de a menţine, pentru aceste căi, a unei calităţi înalte a

MUX  Informaţii de redundanţă încorporată

 Canale auxiliare dedicate

Semnificaţia notaţiilor folosite:

MUX  (Multiplexer) = Multiplexor

Fig. 4.1. Exemplu de sistem de management al SDH

schemele similare utilizate în alte reţele. Modul de construire a acestei scheme

Fig. 4.2. Structura de control pentru stabilirea unei căi

Aceasta poate fi încorporată elementelor de reţea şi atunci va folosi

FER-FMA FER-FMA DM-FMA SO-FMA

FCM FCM FCM FCM

Semnificaţia notaţiilor folosite:

4.1.2 Suport de transmisiuni pentru managementul SDH

Aplicaţiile de management al SDH pot fi clasificate după aria de activitate,

Semnificaţia notaţiilor folosite:

RSOH  (Regeneration Section OverHead) = Redundanţa secţiunii de regenerare

Fig. 4.4. Structura SOH pentru cadrul STM-1

Protocolul utilizat pentru transferul informaţiilor pe aceste canale este de

CONFIRMARE CERERE INDICAŢIE RĂSPUNS

Protocol punct-la-punct la nivelul

PAS – Punct de Acces la Serviciu

Fig. 4.5. Secvenţă de acţionare a primitivelor

 pot interconecta între ele facilităţile interne de management ale

4.1.3 Funcţiile de management al SDH

Funcţiile de management ale SDH respectă clasificarea din Recomandarea

A. Funcţia de management al defectărilor

Funcţia de management al defectărilor acţionează atât la nivel de reţea, cât

 restul evenimentelor ce pot apărea, acestea trebuind stocate şi

Semnificaţia notaţiilor folosite:

RSTE  (Regeneration Section = Echipament terminal al secţiunii de

Fig. 4.6. Ierarhie de management SDH

Din aceste motive, sistemul de management al SDH trebuie să fie capabil

LOS (Loss Of Signal) – Lipsă semnal

Atunci când echipamentul nu recepţionează, înainte de de-scrambler, un bit

OOF (Out Of Frame) - Desincronizare

În cazul în care timp de 625 µ sec nu este detectată secvenţa corectă de

LOF (Loss Of Frame) – Pierderea sincronismului

LOP (Loss Of Pointer) – Pierderea pointerului

Defectul LOP poate fi detectat în două cazuri distincte:

Protocolul de comutare automată a protecţiei

În secţiunea anterioară au fost prezentate principalele condiţii de eroare pe

Semnale de alarmă şi eroare

După cum a fost prezentat în secţiunea dedicată condiţiilor de eroare, atunci

 LO_AIS: se generează în condiţii similare cu semnalul HO_AIS, dar se

Această facilitate a funcţiei de management al defectărilor este foarte utilă

B. Funcţia de management al performanţelor

Această funcţie are drept scop monitorizarea continuă a performanţelor

acceptate două intervale de măsură [G.783 şi G.784], un interval minim de 15

CV  Code Violation = Violare a codului

Pentru o analiză pertinentă a datelor privitoare la performanţa reţelei este

C. Funcţia de management al configuraţiei

Managementul configuraţiei se referă la toate acele funcţii care asigură o

 regim cu comandă de comutare automată a intrării/ieşirii din funcţiune a

4.1.4 Stiva de protocoale pentru canalele de transport al informaţiei de

Deoarece SDH este construit conform recomandărilor ISO referitoare la

Nivel 6 → X.216 şi X.226

Nivel 4 → ISO 8073/AD2