implementare voip pe o centrala telefonica

Vizitati www.tocilar.ro ! Arhiva online cu diplome, cursuri si referate postate de utilizatori.

Implementarea interfatei VoIP pe o centrala telefonica digitala

CAPITOLUL 1. Tehnologia “Voice over IP”

De ce VoIP ?

Referinţe bibliografice: [1], [8], [17]

Modul de transmisie a vocii prin intermediul telefoniei tradiţionale a atins o adevarată

plafonare, privit din punctul de vedere al inovaţiilor, al uşurinţei de manevrare şi, mai ales, al

preţurilor scăzute la care se poate realiza. Componentele de bază ale telefoniei clasice –

terminalul telefonic, centralele de tip PABX, reţeaua de comutaţie – se străduiesc să ţină

pasul cu accelerata rată de inovaţii care au la bază Internet-ul. Chiar şi serviciile îmbunătăţite,

dintre care amintim “call forwarding”, “call waiting”, “call ID”, nu pot furniza cerinţele

actuale, ale erei “e-commerce”.

În zilele noastre, utilizatorul de telefonie foloseşte telefonul pentru a realiza sau primi

apeluri sau pentru a-şi asculta mesajele vocale. Dar, în acelaşi timp, ar dori ca, în acelaşi

terminal telefonic, să aibă integrate şi facilităţi de navigare pe Internet, verificarea “e-mail”-

ului, etc. Telefoanele clasice de astăzi nu pot furniza aceste facilităţi. În contrast cu toate

aceste limitări, comunicaţiile bazate pe Web au revoluţionat modul de viaţă al fiecăruia dintre

noi. Fiecare poate avea prin intermediul Internet-ului acces la servicii de date, multimedia,

video, etc. Numai in ultimii ani, Internet-ul a generat mai multe inovaţii şi soluţii de

comunicare decât reţeaua telefonică tradiţională în întreaga sa existenţă. Următorul pas pe

care trebuie să-l facem este ca acelaşi ritm de inovaţii să-l aplicăm şi în telefonie şi în modul

de transmisie a vocii.

Reţelele de tip IP ( Internet Protocol ) devin din ce în ce mai atractive pentru a fi

folosite drept suport pentru transportul de voce. S-a avut in vedere pentru luarea acestei

decizii mai ales preţul în continuă scădere al transportului de date. Ne aflăm aşadar în faţa

unui pas important către convergenţa vocii, video şi comunicaţiilor de date prin Internet. S-a

demonstrat fezabilitatea transportului de voce si semnalizării prin Internet, însă furnizarea de

servicii publice şi produse de înaltă calitate, dar mai ales convingerea şi atragerea publicului

către noua tehnologie sunt de-abia la început.

Pagina 1 din 133


VoIP ( Voice over IP ) poate fi definită ca posibilitatea de a realiza apeluri telefonice

şi de a trimie facsimile folosind reţeaua de date IP, cu o calitate sporită şi un raport ridicat

calitate/preţ. Introducerea VoIP pe scară largă poate fi privită ca o

fereastră deschisă pentru producătorii care se vor afla într-o continuă competiţie,

pentru furnizorii de servicii, care vor beneficia de sporirea volumului de trafic transportat, cât

şi pentru utilizatorii finali care sunt interesaţi de integrarea aplicaţiilor de voce şi date în

scopul reducerii cheltuielilor.

Producătorii de tehnologie VoIP sunt conştienţi că nu vor reuşi să înlocuiască

telefonia clasică, nici măcar să realizeze o schimbare dramatică în scurt timp. Scopul lor

imediat ar fi acela de a reproduce calităţile oferite la momentul actual de PSTN ( Public

Switched Telephone Network ) la un preţ semnificativ mai scăzut şi de a oferi o alternativă

viabilă acesteia. Prima măsură de succes pentru VoIP ar putea fi reducerea costurilor

convorbirilor realizate pe distanţe mari.

O altă aplicaţie imediată pentru telefonia IP este transmisia facsimilelor în timp real.

Până acum, serviciile de transmitere de facsimile foloseau în mod obişnuit conexiuni PSTN

de dial-up, la viteze de 14.4 Kbps. Calitatea transmisiilor prin intermediul fax-ului era

afectată de întârzierea prin reţea, compatibilitatea maşinilor şi calitatea semnalului analogic.

Pentru trimiterea fax-urilor prin intermediul reţelelor de pachete, o unitate de interfaţă va

trebui să realizeze pachetizarea datelor de transmis, conversia de semnalizări şi protocoalele

de control şi să se ocupe de asigurarea transferului complet al datelor scanate. Pierderea de

pachete şi întârzierea capăt-la-capăt au o importanţă negativă mult mai mare decât în

aplicaţiile de voce.

Majoritatea aplicaţiilor pe suport VoIP sunt considerate de timp real. Se aşteaptă

totuşi şi implementare serviciilor de voce de tip store-and-forward. Un exemplu ar fi acela de

prelucrare a mesajelor de voce local, care apoi să fie trimise către o căsuţă poştală de mesaje

vocale prin intermediul Intranet-ului sau al serviciilor Internet. Documentele însoţite de

mesaje vocale, fişiere multimedia, etc. nu vor mai reprezenta un lucru ieşit din comun în

viitorul apropiat folosind tehnologia VoIP.

Creşterea pieţei de desfacere a aplicaţiilor bazate pe serviciile VoIP se aşteaptă să fie

considerabilă în următoarea perioadă datorită unor mari avantaje. În general, acestea se pot

împărţi în mai multe categorii:

Pagina 2 din 133


Reducerea costurilor – Se pot realiza mari reduceri de cheltuieli în cazul convorbirilor

pe distanţe mari, lucru care este foarte important pentru multe companii, mai ales pentru cele

cu piaţa de desfacere internaţională.

Simplitate – Integrarea serviciilor de voce şi date într-o unică reţea de transport

permite reducerea numărului de echipamente complementare.

Aplicaţii avansate – Avantajele pe termen lung ar fi acelea că VoIP include suportul

pentru aplicaţiile multimedia şi multiserviciu (e-commerce, etc.), aplicaţii care astăzi nu pot fi

realizate prin intermediul sistemului telefonic.

Câteva exemple de aplicaţii VoIP care vor fi dezvoltate ar fi:

PSTN gateway – realizează interconectarea dintre PSTN şi reţeaua IP. Acest

dispozitiv poate fi integrat în PABX, sau poate funcţiona ca un dispozitiv de sine stătător.

Telefoane Internet – telefoanele obişnuite pot fi îmbunătăţite pentru a putea fi aparate

cu acces Internet, alături de serviciile obişnuite pe care le furnizează.

Legăturile inter-office folosind reţeaua privată de date Intranet – Se pot înlocui

legăturile pe liniile telefonice prin intermediul reţelei private, realizându-se economii

financiare substanţiale.

Acces la distanţă – Un mic birou poate avea acces la serviciile de date, voce, facsimil

folosind Intranet-ul.

Apeluri telefonice realizate de la un PC mobil prin intermediul Internet-ului , etc.

Obiectivul numărul 1 al proiectanţilor în domeniul VoIP este destul de simplu:

adăugarea facilităţilor ce ţin de telefonia clasică ( voce şi semnalizări ) reţelelor bazate pe

tehnologia IP şi interconectarea acestora atât cu reţeaua telefonică publică, cât şi cu reţelele

telefonice private. Se urmăreşte de asemenea menţinerea actualelor standarde de calitate ale

convorbirilor telefonice.

Fig. 1.1.1. Arhitectura VoIP. [16]

Provocările cărora proiectanţii trebuie să le

găsească soluţii sunt:

Pagina 3 din 133


Calitatea convorbirilor realizate peste reţeaua IP trebuie să fie dacă nu mai mare, cel

puţin ca cea oferită de reţeaua telefonică publică PSTN, în ciuda faptului că se pot străbate

reţele cu un QoS ( Quality of Service ) variabil.

Reţeaua suport IP trebuie să aibă stricte criterii de performanţă, incluzând aici un cât

mai mic număr de convorbiri rejectate, pachete pierdute; întârzierea prin reţea trebuie să fie

cât mai mică, iar apelurile pierdute datorită problemelor reţelei cât mai puţine.

Controlul apelului din reţeaua IP trebuie să fie transparent semnalizărilor telefonice,

astel încât utilizatorului să nu-i pese pe baza cărei tehnologii se realizează conexiunea.

Serviciile de interconectarea PSTN/VoIP implică utilizarea de “gateway”-uri între

reţeaua de voce şi reţeaua IP.

Cursa având ca scop producerea de echipamente VoIP care să acopere o cât mai mare

paletă de cereri venite din partea beneficiarilor este în plină desfăşurare. Este nevoie de

adoptarea şi implementarea multor standarde, iar actualelor reţele le este necesară

implementarea QoS-ului. Adoptarea VoIP-ului trebuie să fie o alternativă viabilă chiar în

contextul scăderii pronunţate şi constante a preţurilor la telefonie.

Asigurarea unui nivel calitativ cel puţin egal cu al serviciilor PSTN este privită ca o

cerinţă de bază, în ciuda argumentelor venite din partea anumitor producatori potrivit cărora

problema cost-funcţionalitate-calitate ar fi prioritară. Deşi QoS se referă în principal la

fidelitatea de a transmite voce şi facsimil, se poate de asemenea aplica şi la disponibilitatea

reţelei la facilităţi ale reţelei telefonice ( conferinţă, afişarea numărului apelantului, etc. ) şi

scalabilitate.

Una dintre cele mai importante evoluţii oferite de VoIP este pre-procesarea software a

conversaţiilor de voce. S-a ajuns la concluzia ca 50 – 60 % din discursul telefonic dintre 2

persoane este de fapt … pauză. De accea, inginerii au găsit o metodă contra acestui neajuns:

suprimarea pauzelor. Poate cea mai mare facilitate a VoIP-ului este aceea că, astfel, de acum

încolo plata se va face conform cu volumul de trafic generat, nu ca până acum ca produs de

bandă x timp, produs ce duce la o irosire a resurselor reţelei.

1.2. Probleme şi constrângeri

Referinţe bibliografice: [1], [8], [9], [13], [17], [18]

Pagina 4 din 133


Implementările tehnologiei Voice over IP (VoIP) permit utilizatorilor să transporte

traficul de voce folosind o reţea de tip IP ( Internet Protocol ). 3 mari motive au dus la

dezvoltarea şi evoluţia accelerată a pieţei în domeniul VoIP:

Costurile reduse ale convorbirilor telefonice.

Integrarea serviciilor.

Integrarea infrastructurilor de oferire a serviciilor de voce si date.

Internet Protocol este un protocol de nivel 3, corespunzător stivei OSI, fără conexiune

în care pachetele pot urma diferite rute pe drumul lor spre destinaţie. Aceste rute sunt în

acelaşi timp încărcate cu trafic aferent atâtor altor comunicaţii. Protocolul permite alocarea

eficientă a resurselor reţelei, pe măsură ce pachetele sunt îndrumate pe diferite căi mai puţin

congestionate.

Evoluţia tehnologiei Voice over IP a avut şi are o mulţime de obstacole datorate

suportului de transmisie a pachetelor de voce, am numit aici reţelele de tip Internet Protocol

(IP). Acestea, fiind de tipul “best-effort”, nu garantează serviciile oferite. Datele pot ajunge la

recepţie în ordine schimbată faţă de cea de la emisie, pachetele pot urma diferite rute prin

reţea, cu diferite încărcări ale link-urilor, sau pot fi, în cazul cel mai grav, pierdute în situaţii

de congestie. Timpul de traversare a reţelelor este variabil în limite foarte largi. Pentru a

corecta şi a masca nivelelor superioare aceste neajunsuri ale reţelei se folosesc la nivel

“transport” protocoalele TCP şi/sau UDP, în funcţie de aplicaţia dorită.

Aparent, toate aceste “defecte” ale reţelelor de tip IP fac imposibilă dezvoltarea

aplicaţiilor de timp real, în general, şi a celor de voce, video, multimedia, în special, aplicaţii

care sunt în mod critic dependente de timp şi care au nevoie de asigurarea unui QoS destul de

ridicat din partea reţelei suport. În general, în acest tip de aplicaţii nu se foloseşte protocolul

de transport TCP pentru că deşi el garanteaza furnizarea la nivelele superioare a

secvenţialităţii pachetelor, tehnicile lui de control de congentie, control de flux, dar mai ales

control al erorilor prin retransmisie folosind timere nu numai că nu ajută în problema de faţă,

dar încurcă teribil fluxul de date de timp real.

Menţinerea unei calităţi acceptabile, în ciuda problemelor legate de variaţia

performanţei reţelei este reuşită prin folosirea mai multor tehnici: compresia, eliminarea

pauzelor din vorbirea umană şi implementarea QoS-ului în reţelele de transport. Evoluţia

accelerată a componentelor hardware din ultima vreme a făcut posibile multe dintre aceste

tehnici folosite.

Pagina 5 din 133


Problemele specifice trasportului de voce venite din partea reţelei, cărora proiectanţii

au trebuit să le găsească soluţii ar putea lua următoarele aspecte:

Întârzierea capăt-la-capăt – este una dintre cele mai neplăcute probleme care apar în

cazul transportului vocii pachetizate peste o reţea IP. Ea este la originea a 2 probleme: ecoul

şi suprapunerea parţială a discursului telefonic.

Ecoul este cauzat de reflexia vocii celui care vorbeşte, produsă la celălalt capăt al

convorbirii telefonice, care ajunge la urechea vorbitorului. Ecoul devine o mare problemă

atunci când întârzierea dus-întors are o valoare mai mare de 50 milisecunde. În condiţiile în

care ecoul este considerat o mare limitare a calităţii, transmiterea vocii peste o reţea de

pachete trebuie să ţină seama de controlul ecoului, dar mai ales de modalităţi de reducere a

lui.

Suprapunerea discursului devine semnificativă dacă întârzierea într-un singur sens

depăşeşte 250 milisecunde.

Sursele de generare a întârzierii capăt-la-capăt, în cazul unui apel având ca suport o

reţea de pachete, sunt:

Întârzierea de acumulare – uneori numită şi întârzierea algoritmică, ea este cauzată de

nevoia de a colecta mai multe eşantioane de voce pentru a fi procesate de către codor.

Aceasta depinde de tipul de codor de voce folosit şi poate ajunge de la peioada de eşantionare

( 0.125 ms ) la câteva milisecunde. O listă reprezentativă de codoare de voce folosite este:

G.726 – ADPCM – 16, 24, 32, 40 kb/s – 0.125 ms

G.728 LD – CELP – 16 kb/s – 2.5 ms

G.729 CS – ACELP- 8 kb/s – 10 ms

G.723.1 – Codor multirată – 5.3, 6.3 kb/s – 30 ms.

Întârzierea de procesare – este cauzată de procesele de codare si colectare a

eşantioanelor de voce, codate deja, pentru a fi “împachetate” şi trimise în reţeaua IP.

Întârzierea de codare – depinde în egală măsură de timpul de execuţie al procesului şi

de tipul algoritmului folosit. De obicei, sunt colectate mai multe cadre de voce codată într-un

singur pachet de date, pentru a reduce overhead-ul în reţeaua de pachete. Spre exemplu, 3

cadre de voce codată cu G.729, însemnând 30 milisecunde de discurs, pot fi adunate şi

incluse într-un singur pachet.

Pagina 6 din 133


Întârzierea în reţea – are drept cauze timpul de propagare pe mediul fizic,

protocoalele folosite pentru transmisia pachetelor de date materializate prin întârzierile

datorate procesărilor în routerele intermediare şi buffer-ele folosite pentru înlăturarea jitter-

ului pachetelor în partea de recepţie. Timpul de întârziere este funcţie de capacitatea link-

urilor de date de pe drumul parcurs de pachete şi de întârzierile care apar în procesarea lor pe

măsură ce traversează reţeaua IP. Buffer-ele care ajută la eliminarea jitter-ului ( variaţiile

momentelor la care pachetele ar fi trebuit să sosească, dacă n-ar fi fost afectate de întârzierea

prin reţea ) adaugă întârziere. Această întârziere ar putea avea o importantă contribuţie la

întârzierea totală, pe măsură ce variaţia întârzierii pachetelor în reţea poate avea valori între

70-100 ms, în anumite reţele IP.

Figura 1.2.1. Întârzierea în reţea datorată procesării în nodurile traversate şi în “jitter

buffer”-ul de

recepţie. [17]

Figura 1.2.2. Întârzierea totală de transmisie. [17].

Jitter-ul – reprezintă variaţia momentelor la care pachetele ar fi trebuit să sosească la

recepţie, în cazul în care nu

ar fi fost afectate de

întârzierea traversării reţelei.

Pagina 7 din 133


Figura 1.2.3. Jitter-ul – variaţia momentelor de sosire a pachetelor IP. [17].

Problema reducerii întârzierii totale include şi necesitatea eliminării acestui jitter.

Acest lucru presupune adunarea pachetelor şi menţinerea lor suficient de mult, permiţând

astfel şi celui mai lent, celui mai afectat de reţea, să ajungă la recepţie în timp util pentru a fi

redat în secvenţa corectă.

Cele 2 scopuri urmărite, de minimizere a întârzierii şi de înlăturare a jitter-ului, au

produs diverse scheme de adaptare a buffer-ului de recepţie pentru a corespunde cerinţelor

variabile în timp ale înlăturării jitter-ului. Această adaptare are atât scopul explicit de a

minimiza dimensiunea şi întârzierea buffer-ului pentru eliminarea jitter-ului, cât şi prevenirea

golirii buffer-ului.

În cele ce urmează, vom prezenta 2 soluţii de adaptare a dimensiunii “jitter buffer”-

ului. Ele au o mare dependenţă de reţeaua de pachete care este folosită drept suport de

transmisie.

Prima variantă ar fi măsurarea variaţiei nivelului de pachete din “jitter buffer” de-a

lungul unei perioade de timp şi adaptarea prin creştere a dimensiunii buffer-ului pentru a se

potrivi jitter-ului calculat. Această soluţie dă cele mai bune rezultate în cazul reţelelor care

cauzează un jitter consistent de-a lungul timpului, spre exemplu reţelele ATM.

A doua variantă este de a contoriza numărul de pachete care sosesc cu întârziere şi de

a raporta numărul acestor pachete la numărul de pachete corect procesate. Această proporţie

poate fi apoi folosită la ajustarea “jitter buffer”-ului, care să poată face faţă în cazul unei

predeterminate rate

permise a pachetelor sosite cu întârziere. Soluţia are mare utilizare în cazul reţelelor

cu variaţie foarte mare a intervalelor de sosire a pachetelor. Este cazul aici şi al reţelelor de

tip IP.

Trebuie totuşi menţionat că, pe lângă aceste tehnici descrise, reţeaua, de orice tip ar fi

ea, trebuie configurată şi gestionată pentru a furniza întârzierea şi jitter minime, permiţând

astfel un QoS consistent.

Compensarea pachetelor pierdute în reţea – pierderea pachetelor conţinând

eşantioanele codate, sau necodate de voce poate fi o şi mai severă problemă, în funcţie de

tipul de reţea folosit. Din cauza faptului că reţeaua IP este o reţea care nu garantează

serviciile oferite de ea, pachetele de voce sunt expuse la un risc de pierdere mult mai mare

decât în cazul altor reţele. În momentul de faţă, reţelele IP tratează pachetele de voce ca pe

Pagina 8 din 133


nişte obişnuite pachete de date. În situaţia apariţiei încărcării excesive cu trafic, sau a

congestiei, cadrele de voce vor fi înlăturate la fel ca orice alt pachet de date. Însă, cadrele de

date nu sunt sub presiunea timpului, iar înlăturarea lor poate fi corectată prin procese de

retransmisie, spre deosebire de pachetele de voce care nu pot fi tratate în această manieră.

Câteva modalităţi de a rezista în faţa pericolului pierderii pachetelor de voce datorat

reţelelor IP ar fi:

Interpolarea pachetelor de voce pierdute – se realizează prin redarea pe perioada în

care pachetul pierdut ar fi trebuit redat, a ultimului pachet recepţionat. Aceasta este o soluţie

simplă care are menirea de a ocupa cumva timpul dintre cadrele neconsecutive de voce

recepţionate. Funcţionează destul de bine în situaţia în care riscul de pierdere al pachetelor

este mic, dar rezultatele ei sunt foarte slabe atunci când pachetele sunt pierdute în rafale.

Trimiterea de informaţie redundantă, în schimbul utilizării benzii – aceasta abordare

transmite o replică a celui de-al “n”-lea pachet de voce împreună cu cel de-al “n+1”-lea. Are

avantajul că este posibil de corectat pierderea exactă a pachetelor. Oricum, marele dezavantaj

al acestei metode este că utilizează mai multă bandă şi generează o mai mare întârziere.

Folosirea unei tehnici intermediare – care să folosească mult mai puţină bandă, iar

codorul să furnizeze informaţie redundantă transportată în cel de-al “n+1”-lea pachet. Aceasta

reduce problema folosirii de bandă suplimentară cerută, dar nu rezolvă adaosul de întârziere.

Compensarea ecoului – Într-o reţea telefonică, ecoul este cauzat de reflexia

semnalului, care are loc în circuitul de trecere de la 4 fire ( câte o pereche pentru fiecare sens

de transmitere a semnalului telefonic ) la 2 fire ( o singură pereche pe care se realizează

ambele sensuri ). Vocea celui care vorbeşte este auzită datorită reflexiei tot de către el.

a. b.

Figura 1.2.4. Ecoul – locul şi motivul apariţiei [18].

a. Trecerea de la 2 la 4 fire în care impedanţa trebuie să fie aceeaşi la ambele capete.

b. Nepotrivirea celor 2 impedanţe – cauza ecoului.

Pagina 9 din 133


Ecoul se întâlneşte în reţeaua telefonică bazată pe comutaţia de circuite, însă acolo

este cu mult mai puţin deranjant, întrucât întârzierea dus-întors prin reţea este mai mică de 50

milisecunde.

În reţelele de pachete, ecoul devine o problemă datorită întârzierii dus-întors prin

reţea, care este în mod obişnuit mai mare de 50 ms. De aceea, eliminarea lui este mereu

folosită. Standardul ITU-T G.165 defineşte cerinţele de performanţă urmărite de dispozitivele

de eliminare de ecou. ITU-T defineşte chiar cerinţe de performanţă mult mai drastice în

specificaţiile G.IEC.

Ecoul este generat către reţeaua de pachete de către reţeaua telefonică. Modulul

pentru eliminarea ecoului compară datele sub formă de voce primite de la reţeaua de pachete

cu datele de voce trimise reţelei. Ecoul produs este rejectat prin intermediul unui filtru digital,

pe calea de transmisie în reţeaua de pachete.

Figura 1.2.5. Eliminarea ecoului prin intermediul unui filtru digital [17].

Pentru a ascunde şi a repara câteva din neajunsurile reţelei IP, care au un impact

foarte grav asupra comunicaţiilor de timp real pe acest suport, se folosesc tehnici ca:

Prioritizarea – are o strânsă legătură cu QoS-ul. Se foloseşte pentru aceasta protocolul

RSVP ( Resourse Reservation Protocol ), care permite sursei de trafic să ceară anumite

caracteristici ale serviciului de transport. Din păcate acest protocol nu a avut un foarte mare

succes şi de aceea răspândirea lui este destul de limitată. Specialiştii IETF (Internet

Engineering Task Force) au abordat o altă soluţie, mai simplă şi mai promiţătoare:

Pagina 10 din 133


DiffServ( Differentiated Services Model ) care foloseşte câmpul ToS ( Type of Service ) din

antetul IPv6 al fiecărui pachet, pe baza căruia clasifică traficul la graniţa dintre client şi ISP.

În ciuda acestor proiecte, în reţeaua IP nu se poate încă vorbi de un QoS viabil.

Fragmentarea IP este realizată în acelaşi mod ca şi la Frame Relay. Deşi cerută pentru

a reduce întârzierea globală a traficului de voce, fragmentarea realizează totuşi adăugarea

unui overhead mare, datorită headerului destul de mare al pachetelor IP. S-a constatat că

traficul de voce pe suport IP consumă din această cauză resursele WAN cu până la 50% mai

mult decât traficul de voce pe suport Frame Relay. Se speră totuşi că pe măsură ce IP-ul se

maturizează, compresia headerului si îmbunătăţirea performanţelor routerelor să elimine

aceste neajunsuri.

Compresia de voce este vitală tehnologiei VoIP datorită faptului că traficul

traversează adesea porţiuni de viteze mai mici. Companii de dimensiuni mici sau mijlocii, de

exemplu, pot fi conectate la VPN ( Virtual Private Network – reţea virtuală privată ) prin

intermediul unor link-uri de doar 28.8 kbps.

Soluţia de eliminare a pauzelor de vorbire, eliminarea ecoului – S-a constatat că până

la 50% dintr-o convorbire telefonică obişnuită este reprezentat de fapt de linişte ( doar unul

din interlocutori vorbeşte, pauze dintre cuvinte, etc ). Din acest motiv, o mare parte din

capacitatea de transfer a conexiunii de tip full-duplex se iroseşte.

1.3. Arhitectura sistemelor VoIP


“Voice over IP” este o tehnologie nouă, care vine să ofere o alternativă modului de

transmisie a vocii, în special, şi a altor servicii oferite de reţeaua de comutaţie de circuite. Ca

orice inovaţie, care vine să revoluţioneze realmente modul de transmisie a poate celui mai

vechi şi încetăţenit mod de comunicare verbală la distanţă între oameni, am numit aici

telefonia clasică, s-a lovit încă din prima clipă de suspiciunea utilizatorilor, problemele

reţelelor de tip IP, noul suport de transmisie a vocii, dar, poate cel mai important obstacol,

nivelul uriaş al investiţiilor făcute în reţeaua de telefonie deja dezvoltată.

În tot acest context, VoIP a trebuit să-şi facă loc pe piaţă, oferind cel puţin la fel de

ieftin aceleaşi calitate a serviciilor de voce, să se integreze în sistemul de comunicaţie şi să-şi

Pagina 11 din 133


pună la punct metode de colaborare, în principal, tocmai cu reţeaua telefonică, ale cărei

servicii i le concurează şi cărora le oferă alternativă. Acest lucru trebuie realizat datorită

faptului că, oricât de mare va fi amploarea dezvoltării VoIP, nu va reuşi să înlocuiască

serviciile de telefonie clasică.

Obiectivele de realizat pentru o bună funcţionare ar fi:

Controlul apelului şi al semnalizărilor diferite în cele 2 reţele de transport, astfel încât

utilizatorului obişnuit să-i fie indiferent pe ce suport se transmite semnalul vocal.

Intercomunicarea şi interoperabilitatea echipamentelor celor 2 reţele, PSTN (Reţeaua

telefonică de telefonie publică cu comutare de circuite) şi reţeaua de pachete, de tip IP. Acest

lucru implică folosirea unor punţi ( gateway ), care au rolul de a realiaza trecerea de la modul

diferit de trasmisie a datelor în cele 2 reţele.

Managementul sistemelor, adresarea, securitatea şi permisiunea de acces care trebuie

asigurate din ambele părţi.

Odată începută cursa de proiectare şi implementare de produse VoIP, care să se

muleze pe o mare varietate configuraţii deja existente, au trebuit concepute şi publicate o

multitudine de noi standarde care aveau în vedere mai ales noua tehnologie apărută. Toate

acestea au făcut ca sistemele VoIP să conţină mai multe plane funcţionale.

Aceste plane nu fac altceva decât să aducă soluţii structurate transportului de voce şi

interoperabilităţii cu celelalte reţele de date.

Figura 1.3.1. Arhitectura structurii

funcţionale a sistemelor “Voice over IP“ [16].

Pagina 12 din 133


Despre planul transportului de voce, incluzând aici vocea propriu-zisă, reprezentarea

şi codarea ei, şi controlul apelului telefonic, ne vom referi mai pe larg în subcapitolele

următoare.

La nivelul interopareabilităţii dintre PSTN şi reţeaua de pachete IP, trebuie manevrate

2 mari tipuri de informaţii: vocea propriu-zisă, pe de o parte, şi informaţiile de semnalizare,

pe de altă parte.

Figura următoare reliefează modul în care componentele software a unui sistem VoIP,

localizate uzual în componentele hardware indicate, interfaţează cu ambele fluxuri de

informaţie şi le transformă într-unul singur, transmis reţelei de pachete. Aceste funcţii

software se împart în 4 mari categorii:

Figura 1.3.2. Arhitectura software a unui sistem VoIP [13]

Modulul de pachetizare a vocii – cunoscut şi sub numele de modulul de procesare a

vocii, funcţionează de regulă într-un DSP ( Digital Signal Processor ), pregăteşte eşantioanle

de voce pentru transmisia în reţeaua IP. Funcţiile sale realizează şi eliminarea ecoului,

compresia de voce, detecţia pauzelor în discursul telefonic, eliminarea jitter-ului,

sincronizarea ceasului şi pachetizarea vocii.

Modulul de realizare a semnalizării telefonice – interacţionează cu echipamentele

telefonice, translatând semnalizările telefonice în schimbări de stare, folosite de către

modulul de protocoale de reţea pentru stabilirea, menţinerea şi eliberarea conexiunilor.

Schimbările de stare sunt ridicare de receptor, terminare apel, etc. Acest software suportă de

Pagina 13 din 133


regulă semnalizări E&M de tipul I, II, III, IV, V, FXO, FXS, ISDN acces de bază şi acces

primar.

Modulul de protocoale de reţea – procesează informaţiile de semnalizare şi le

converteşte din semnalizări specifice reţelei telefonice în protocoale de semnalizare în mod

pachet, folosite la stabilirea conexiunilor în reţeaua IP ( ex: Q.933 ). De asemenea, adaugă

headere pacheteleor de voce şi de semnalizare înainte de a fi transmise.

Modulul de management a reţelei – asigură interfaţa de gestiune a vocii, pentru

menţinerea şi configurarea celorlalte module ale sistemului. Toate informaţiile de gestiune

sunt definite în ANSI.1 şi sunt compatibile cu sintaxa protocolului SNMP v.1 ( Signalling

network-management protocol ).

Pachetul software este partiţionat pentru a asigura o bine definită interfaţă către

aplicaţia ce rulează în DSP, utilizabilă pentru mai multe aplicaţii şi protocoale de pachetizare.

DSP-ul procesează eşantioanele de voce şi pasează pachetele de voce microprocesorului

însoţite de header-ele generice de voce.

Microprocesorul este responsabil de transferul pachetelor şi adaptarea header-elor

generice în header-ele specifice protocolului de transport în timp real al pachetelor de voce

( ex: Real Time Protocol - RTP ). De asemenea, tot microprocesorul realizează şi procesarea

informaţiilor de semnalizare şi le converteşte din protocoalele de semnalizare telefonică în

protocoale de semnalizare în reţeaua de pachete ( ex: H.323 ).

Partiţionarea oferă o interfaţă clară între funcţiile generice de procesare de voce, de

exemplu compresie, eliminare de ecou şi detecţia de activitate vocală, şi semnalizările

specifice aplicaţiei şi procesările protocoalelor de voce.

1.3.1. Modulul de procesare a vocii

Referinţe bibliografice: [1], [8], [13], [17], [18]

După cum şi titlul anuţă, acest modul al arhitecturii software a unui sistem VoIP are în

principal rolul de a procesa eşantioanele de voce. De obicei, aceste funcţiuni sunt realizate cu

ajutorul unui DSP ( Digital Signal Processor ). Raportul calitate/preţ al acestor dispozitive a

înregistrat o evoluţie vertiginoasă în ultima vreme, performanţele sale, dar mai ales preţul în

Pagina 14 din 133


continuă scădere transformîndu-l într-o componentă ideală pentru arhitectură hardware a

sistemelor de procesare a eşantioanelor de voce.

Pentru o mai bună structurare a funcţiunilor şi sarcinilor pe care le are de îndeplinit,

modulul de procesare de voce este la rândul lui împărţit în mai multe submodule:

Interfaţa PCM – are sarcina de a recepţiona eşantioanele de voce, modulate folosind

modulaţia impulsurilor în cod, de pe fluxul PCM digital şi de a le direcţiona către modululele

software din DSP-urile responsabile de procesarea lor. Apoi le transmite interfeţei digitale şi

continuă etapa de reeşantionare a cadrelor de ieşire către interfaţa analogică.

Generatorul de tonuri – generează tonuri DTMF ( Dual Tone Multifrequency ) şi

tonuri specifice apelului telefonic sub comanda sistemului de operare folosit în echipamentul

respectiv ( ex: telefon, fax, modem, PABX ). Este configurabil pentru funcţionarea în mai

multe sisteme de standardizare.

Eliminarea ecoului – realizează suprimarea parametrizabilă a ecoului în cazul

trasmisiilor de voce în modul full-duplex, conform cu specificaţiile ITU G.165, G.168.

Detectorul de activitate vocală şi măsurare a nivelului de zgomot – Monitorizează

semnalul recepţionat pentru a fi detectată activitatea vocală în discursul telefonic. Atunci

când se detectează linişte pe o perioada de timp a cărei durată se poate parametriza, software-

ul informează protocolul de pachetizare a vocii. Aceasta previne ca informaţiile de la ieşirea

codorului să fie transportate de-a lungul reţelei în momentele de pauză, fără ca să existe

informaţie utilă de transmis, lucru ce duce la reducerea utilizării inutile resurselor reţelei.

Software-ul realizează de asemenea şi o măsurare a nivelului de zgomot în starea de

pauză a interfeţei telefonice, iar apoi raportează aceste informaţii protocolului de pachetizare

a vocii din terminalul distant pentru a tine cont la redare de perioadele de linişte detectate.

Detectorul de tonuri – detectează recepţia tonurilor DTMF şi a tonurilor specifice

stabilirii apelului telefonic. Aceste detecţii sunt raportate sistemului de operare pentru

activarea a diverse funcţii specifice.

Modulul de codare a vocii – are rolul de a coda vocea inainte de a fi transmisă în

reţeaua IP. Este capabilă de numeroase rate de compresie folosind diverşi algoritmi de

codare.

Fax software – realizează funcţiunile secifice de trimitere de facsimile prin

demodularea datelor PCM, extragerea informaţiilor relevante, împachetarea şi transmiterea

Pagina 15 din 133


pe reţeaua IP. Prin această procedură se produc reduceri semnificative ale benzii inutil

utilizate.

Unitatea de redare a vocii – buffer-ează pachetele de voce sosite din reţea şi le trimite

codorului de voce pentru redare. Asigură în acelaşi timp:

un buffer de tip FIFO ( First In, First Out ) care menţine eşantioanele de voce înainte

ca să fie realizată înlăturarea jitter-ului datorat reţelei.

un mecanism de măsurare a jitter-ului care permite un control adaptiv al întârzierii de

tip FIFO.

Protocoalele de pachetizare a vocii folosesc un câmp ce conţine numere de secvenţă

în interiorul fluxului de pachete pentru menţinerea temporară a integrităţii vocii de-a lungul

redării. Folosind această metodă, transmiţătorul inserează în fiecare pachet conţinutul unui

contor ce evoluează modulo 216, permiţând receptorului să detecteze pierderea de pachete şi

să reproducă intervalele de linişte într-o redare corectă.

Protocolul de pachete de voce – este în care se încapsulează vocea compresată şi

datele de fax pentru a fi transmise celuilalt capăt pe suportul reţelei de date.

Controlol interfeţei – coordonează schimbul de informaţii de monitorizare şi control

dintre DSP şi sistemul gazdă, prin intermediul unui mecanism de cutie

poştală. Informaţiile interschimbate includ date de configurare, rapoarte de stare, etc.

Mediul intern de funcţionare în timp real – asigură mediul de operare al software-ului

funcţional în DSP. Furnizează funcţii de sincronizare, gestiunea task-urilor şi a memoriei,

controlul timer-ilor.

Figura următoare sintetizează arhitectura software-ului care rulează într-un DSP. El

procesează eşantioanele de voce de pe flux PCM şi le converteşte într-un format digital

potrivit transmiterii în reţeaua de pachete IP.

Pagina 16 din 133


Figura 1.3.1.1. Structura modulului de procesare a vocii. [13].

1.3.2. Modulul de semnalizare şi management

Referinţe bibliografice: [1], [8], [13], [17], [18]

Software-ul sistemelor VoIP asigură buna funcţionare a semnalizării telefonice,

pentru a detecta prezenţa unui nou apel şi a cifrelor reprezentând adresa sa, folosite de sistem

la rutarea către portul destinaţie. Sunt suportate o mare varietate de protocoale de

semnalizare, specifice reţelei telefonice. De regulă, software-ul şi datele de configurare

pentru cartelele de voce pot fi încărcate de la un sistem de management, pentru a permite

instalare rapidă şi uşoară, îmbunătăţiri făcute de la distanţă.

Modulul software interacţionează cu DSP-ul pentru detecţia şi generarea tonurilor

DTMF şi interacţionează cu interfaţa telefonică pentru funcţiunile de semnalizare. El are, de

asemenea, rolul de a recepţiona datele de configurare de un agent de gestiune a reţelei şi de a

utiliza serviciile oferite de sistemul de operare.

Pagina 17 din 133


Modulul de transfer a semnalizării telefonice – are, după cum ne-am obişnuit, o

arhitectură structurată pe blocuri funcţionale.

Software-ul pentru interfaţa telefonică – monitorizează, de obicei, interfaţa de

semnalizare a modulului.

Unitatea de protocol de semnalizare – este constituită din maşina de stări, care

realizează buna funcţionare a protocoalelor de semnalizare ( ex: E&M ).

Modulul de control al reţelei – realizează transferul semnalizărilor telefonice într-un

format adecvat protocoalelor de stabilire de sesiune pentru comunicaţia de voce pachetizată.

Translaţia adreselor – realizează corespondenţa dintre planul de adresaree telefonică,

descris de recomandările E.164, în adrese care pot fi folosite în reţeaua de pachete ( ex:

adrese IP sau DLCI (Data Link Connection Identifier), în cazul reţelelor Frame Relay ).

Driverul pentru interfaţa cu DSP-ul – facilitează transferul de informaţii între

microprocesorul gazdă al sistemului şi DSP-uri.

Modulul pentru protocolul de reţea – are submodule obligatorii:

Stiva de semnalizare IP – presupune controlul apelului şi al transportului, folosind

specificaţiile H.323, incluzând H.225, H.245, RTP/RTCP , TCP, UDP şi IP. La toate aceste

soluţii software ne vom referi mai pe larg în subcapitolele ce urmează.

Stiva de protocoale de semnalizare ATM.

Stiva de protocoale Frame Relay.

Modulul de management a reţelei – constă în 3 mari servicii:

Interfaţa fizică către terminalul telefonic.

Serviciul oferit canalului de voce – are ca funcţiuni următoarele:

procesarea semanlului pe canalul vocal.

Conversia eşantioanelor PCM în pachete de voce compresată.

Serviciul de control al apelului pentru analiza informaţiilor de control apel şi stabilirea

convorbirilor între terminalele telefonice.

1.4. Tipuri de conexiuni

Referinţe bibliografice: [1], [9], [12], [14]

Pagina 18 din 133


În ciuda inconvenienţelor de ordin tehnic în faţa cărora s-a aflat, datorită problemelor

de asigurare a QoS-ului de către reţelele IP, tehnologia VoIP a avut o mare şi rapidă

dezvoltare. Ea are rolul de a integra serviciile de transport de voce în reţelele de tip IP şi de a

realiza o bună comunicare cu reţeaua publică de telefonie PSTN.

Figura 1.4.1:

Integrarea serviciilor de

voce în reţelele IP. [14].

În modul

tradiţional de funcţionare

al serviciilor de telefonie publică, până acum apelurile aveau se realizau prin stabilirea unor

canale virtuale comunicaţie de-a lungul reţelei de comutaţei de circuite, care erau apoi

folosite pentru transmiterea vocii. Semnalul vocal urma acelaşi traseu stabilit în faza de

iniţializare a apelului, traseu virtual care la sfârşitul comunicaţiei este eliminat din

funcţionarea sistemului.

Noua tehnologie VoIP, datorită tendinţei de integrare şi necesităţilor de comunicare,

oferă mai multe modalităţi de conexiune pentru realizarea apelului şi transferului de voce.

Figura următoare prezintă variantele de realizare conexiunilor amintite. Ele pot fi:

PC–PC – legătură telefonică între 2 calculatoare echipate cu software adecvat

comunicaţiilor de voce în timp real (ex: Microsoft NetMeeting) şi cu hardware specializat

pentru comunicaţii de voce ( placă de sunet, microfon, căşti audiţie ). Conexiunea se poate

realiza folosind numai Intranet-ul privat al companiei, sau reţeaua publică de pachete IP.

PC–Telefon – legătură telefonică între un calculator multimedia şi un post telefonic

obişnuit, abonat al reţelei publice. Comunicarea se face în mod pachet folosind reţeaua

Intranet, ieşind

apoi în reţeaua publică IP, iar apoi, prin intermediul dispozitivelor de

intercomunicaţie (gateway), datele reprezentând vocea sunt transferate reţelei telefonice cu

comutare de circuite şi apoi postului telefonic dorit.

Pagina 19 din 133


Telefon–telefon – legătură telefonică între 2 posturi telefonice normale. Diferenţa este

că legătura de comunicaţie se realizează astfel încât semnalele de voce traversează o reţea

publică sau privată IP şi revin apoi în reţeaua telefonică, pe traseul lor către destinaţie.

Figura 1.4.2. Tipuri de conexiuni VoIP

1.5. Protocoale şi soluţii software


În dinamica muncă de proiectare şi producţie, în dorinţa de a scoate cât mai repede

ceva cât mai bun pe piaţă, fiecare mare producator a adoptat o soluţie proprietară care să-l

mulţumească pe el şi care să-i accelereze procesul de dezvoltare. De aceea, în tot acest cadru

a fost nevoie de o autoritate care să aducă şi să impună anumite standarde ce trebuie urmate

pentru o bună intercomunicare. Prima măsură a fost înfiinţarea “VoIP Forum”, unde fiecare

mare producător care avea câte un cuvânt de spus s-a înscris. Marile grupuri de standardizare

şi grupuri decizionale, ITU-T, IETF, ETSI, etc., s-au grăbit de asemenea să adopte propriile

Pagina 20 din 133


standarde. Totul a culminat însă, în 1996 cu apariţia primei versiuni a specificaţiilor H.323.

Au urmat apoi în 1998 versiunea 2, în 2000 versiunea 3, actualmente funcţionând versiunea

4.

Intitulate generic “Audiovisual and multimedia systems”, H.323 reprezintă un

standard care specifică protocoalele, componentele şi procedurile care furnizează serviciile de

comunicare multimedia – audio, video şi date în timp real, peste o reţea de pachete bazată pe

protocolul IP. H.323 este parte a recomandărilor ITU-T, denumite generic H.32x care descriu

funcţionarea comunicaţiilor peste diverse tipuri de reţele de pachete.

Figura 1.5.1. Funcţionalitatea H.323.

Reţelele bazate pe transmisia de pachete fac parte LAN-urile (local area network) IP

sau IPX (Internet packet exchange), reţelele private de instituţie, reţelele metropolitane

(MAN) şi cele de intindere mare (WAN). H.323 poate fi funcţiona într-o mare varietate de

aplicaţii: numai audio(telefonie prin Internet), audio şi video (videofonie), audio şi date,

video şi date. H.323 poate fi, de asemenea, aplicat comunicaţiilor multimedia de tip

multipunct.

Specificaţiile H.323 v.1 emise de către ITU-T Study Group 16 în octombrie 1996

aveau ca obiect sistemele de tip video-telefon şi echipamente pentru reţelele LAN care să

furnizeze un QoS negarantat. Rapiditatea dezvotării aplicaţiilor VoIP şi a telefoniei prin

Internet a pavat drumul spre o revizuire a specificaţiilor H.323. Inconsistenţa standardelor

deja adoptate a fost scoasă la lumină de produsele oferite care erau incompatibile. Odată cu

evoluţia VoIP, noi cerinţe au apărut la orizont, ca, de exemplu, asigurarea comunicaţiei între

un multimedia-PC (terminal H.323) şi un telefon obişnuit funcţionând în reţeaua PSTN.

Aceste cerinţe au dus la necesitatea unui standard pentru telefonia prin Internet. Astfel, în

ianuarie 1998 a fost publicată versiunea 2 H.323-ului – sisteme de comunicaţie multimedia

bazate pe comutaţia de pachete.

Pagina 21 din 133


Completări referitoare la transmiterea fax-ului peste o reţea de pachete, comunicarea

gatekeeper-gatekeeper şi mecanisme de conectare rapidă au forţat apariţia îmbunătăţită a

specificaţiilot H.323 versiunea 3 în anul 2000.

Unul dintre obiectivele dezvoltării standardelor H.323 este interoperabilitatea cu alte

reţele de pachete ce oferă servicii multimedia. Acest lucru se face prin folosirea “gateway”-

urilor care realizează translaţia semnalelor de date şi a semnalizărilor cerute pentru o bună

conlucrare.

Standardul H.323 specifică 4 tipuri de componente, care legate între ele, asigură buna

funcţionare a serviciilor multimedia punct-la-punct sau multipunct. Aceste componente ar fi:

Terminale

Gateway-uri

Gatekeepere

MCU (multipoint control units) – ajută controlul comunicaţiilor de tip multipoint.

Figura 1.5.2. Arhitectura şi componentele reţelei H.323. [14].

Terminalul

Folosit pentru comunicaţiile multimedia bidirecţionale, de timp real, ca terminal poate

fi folosit un calculator personal (PC), sau un dispozitiv de sine stătător, care pot rula aplicaţii

multimedia şi stiva H.323. El suportă comunicaţii audio şi opţional video sau de date. Pentru

că serviciul de bază oferit de un terminal H.323 este acela de comunicaţii audio, el joacă un

rol cheie în serviciile de telefonie IP.

Gateway

Are rolul de a conecta 2 reţele diferite. Un gateway H.323 realizează

intercomunicarea între o reţea H.323 şi reţele de alt tip. Conectivitatea între diferite reţele este

Pagina 22 din 133


realizată prin translaţia protocoalelor pentru efectuarea şi eliberarea apelului, conversia

formatelor datelor şi transferarea informaţiilor din reţelele conectate de gateway.

Gatekeeper

Poate fi considerat creierul reţelelor H.323, întrucât este punctul în care se

concentrează realizezea tuturor apelurilor. În ciuda faptului că nu sunt necesare, ele asigură

buna funcţionare a unor importante servicii: adresarea, autorizarea şi autentificarea

terminalelor şi a gateway-urilor; gestiunea lăţimii de bandă folosită; controlul taxării, etc. Pot

de asemenea asigura servicii de rutarea a apelului.

MCU – Multipoint Control Unit

Furnizează suportul pentru comunicaţii de tip multipunct între 3 sau mai multe

terminale H.323. Toate terminalele realizează câte o conexiune cu MCU. El gestionează

resursele conferinţei, negociază cu terminalele în scopul determinării

codorului audio/video ce urmează a fi folosit şi poate manevra fluxul de date. Deşi

gateway-urile, gatekeeper-ele şi MCU sunt componente separate, pot însă fi implementate în

aceeaşi maşină, ca un singur dispozitiv fizic.

O zonă H.323 este colecţia tuturor terminalelor, gateway-urilor şi MCU-urilor

gestionate de un singur gatekeeper. Poate exista cel puţin un terminal şi poate include

gateway-uri sau MCU, dar cu siguranţă un singur gatekeeper. O zonă poate fi independentă

de topologia reţelei, sau poate fi constituită din mai multe segmente conectate prin routere,

sau alte dispozitive.

Protocoalele specificate de standardul H.323, clasificate pe structura funcţională sunt

prezentate în figura următoare şi descrise mai jos:

Codoare şi decodoare audio (audio codec).

Codoare şi decodoare video (video codec).

H.225 - registration, admision, status (RAS).

H.225 - semnalizarea apelului.

H.245 - semnalizarea controlului.

RTP – Real-time Transfer Protocol – protocol pentru transmiterea datelor de timp-

real.

RTCP – Real-time Control Protocol – protocol pentru controlul transmiterii datelor de

timp-real.

Pagina 23 din 133


Figura 1.5.3. Stiva H.323 [10].

Audio CODEC – are rolul de a coda pentru transmisie semnalului audio de la

microfon, la terminalul emiţător. La terminalul receptor, va decoda semnalul primit ce va fi

trimis spre redare. Întrucât serviciile audio sunt minimul oferit de standardul H.323, toate

terminalele trebuie să aibă suport pentru cel puţin un codec audio, aşa cum este specificat în

recomandarea ITU-T G.711 (codare decodare audio 64 kbs). Pot fi folosite alte codec-uri

audio: G.722 (64, 56, 48 kbs), G.723.1 (5.3 şi 6.3 kbs), G.728(16 kbs) şi G.729(8kbs).

Video CODEC – codează imaginile primite de la camera de luat vederi pentru

transmisie, în cazul terminalului H.323 emiţător şi decodează imaginile recepţionate pentru a

le trimite apoi la dispozitivul de vizualizare, la terminalul receptor. Pentru că serviciile video

sunt opţionale conform specificaţiilor H.323, suportul pentru codecii video este opţional, de

asemenea. Totuşi, orice terminal ce asigură comunicaţii video trebuie să suporte codare-

decodare video, conform specificaţiilor ITU-T H.261.

H.225. Registration, Admission and Status – este un protocol ce funcţionează între

terminale, sau gateway-uri, pe de o parte şi gatekeepere, pe de altă

Pagina 24 din 133


parte. Este folosit pentru a realiza înregistrarea, controlul accesului, schimbările în

lăţimea de bandă şi a stării dispozitivelor terminale şi gatekeepere. Mesajele de tip RAS sunt

schimbate folosind un canal de comunicaţie RAS, deschis între terminal şi gatekeeper înainte

de deschiderea oricărui alt canal de comunicaţie.

H.225 Semnalizarea apelului – protocol folosit pentru stabilirea unei conexiuni între

cele 2 dispozitive terminale. Acest lucru este realizat prin schimbarea de mesaje de tip H.225

prin intermediul canalului de semnalizare. Acesta se poate deschide între 2 terminale H.323,

sau între un terminal şi un gatekeeper.

H.245 Semnalizarea de control – se foloseşte pentru a schimba mesaje de control de

tip capăt-la-capăt menite să controleze funcţiunile terminalului H.323. Aceste mesaje

transportă informaţii referitoare la:

capacităţile de comunicare.

Deschiderea şi închiderea canalelor logice folosite pentru transportul fluxului de date.

Mesaje de control al transmisiei.

Comenzi generale şi indicaţii.

RTP – Real-time transport protocol – asigură serviciile de livrare capăt-la-capăt a

fluxurilor audio şi video de timp-real. În majoritatea cazurilor în care RTP-ul este folosit

pentru transportul de date în reţelele de pachete IP, el funcţionează având ca protocol de

transport UDP-ul (User Datagram Protocol). Împreună în acest context, asigură funcţiunile

unui protocol de nivel transport. RTP-ul oferă identificarea tipului de date transportat, numere

de secvenţă, amprente de timp şi monitorizarea pachetelor sosite. UDP oferă multiplexarea şi

serviciul de sume de control. RTP poate fi însă folosit şi în combinaţie cu alte protocoale de

nivel transport.

RTCP – Real-time Transport Control Protocol – folosit de regulă alături de RTP, are

menirea de a asigura serviciile de control în cele 2 terminale ale transportului pachetelor.

Principala sarcină a RTCP-ului este de a asigura un “feedback” al calităţii transportului

datelor. Pe lângă acest lucru, RTCP-ul mai are rolul de a transporta un identificator al

nivelului transport al unei surse RTP, folosit de receptoare pentru sincronizarea audio şi

video.

1.5.1 Funcţiunile componentelor H.323


Pagina 25 din 133


Am enumerat în subcapitolul anterior componentele pentru asigurarea serviciilor de

comunicaţie multimedia pe suportul unei reţele de pachete IP. Figura următoare are, pe lângă

rolul de a le reaminti, şi rolul de a prezenta modalitatea lor de interconectare şi

intercomunicare.

Figura 1.5.1.1. Componentele şi integrarea lor in reţeaua H.323 [14].

Terminalul H.323 – trebuie să asigure următoarele funcţiuni:

H.245 pentru crearea canalelor de transmitere a datelor multimedia şi pentru schimbul

de informaţii referitoare la disponibilităţile tehnice ale terminalelor.

H.225 pentru stabilirea apelurilor şi realizarea semnalizării telefonice.

RAS, pentru schimbul cu gatekeeper-ul al informaţiilor de înregistrare şi control al

accesului.

RTP/RTCP pentru secvenţarea şi amprentele de timp adăugate pachetelor audio şi/sau

video.

Terminalele compatibile H.323 trebuie să asigure codare/decodare G.711. Opţional,

mai pot lucra componente de codare/decodare video, protocoale pentru conferinţă T.120, sau

funcţiuni de MCU.

Pagina 26 din 133

Terminal

H.323

Terminal H.323

Terminal

H.323


Gateway – asigură translaţia protocoalelor pentru stabilirea şi eliberarea apelului,

conversia formatelor de date între diferite reţele şi transferul de informaţii între reţelele de tip

H.323 şi non-H.323.

Figura 1.5.1.2. Stiva de protocoale a unui gateway H.323-SCN. [10].

În partea aplicaţiilor H.323, un gateway rulează H.245 pentru schimbarea

informaţiilor privitoare la disponibilităţile tehnice, H.225 “call signalling” pentru stabilirea şi

eliberarea apelurilor şi H.225 RAS pentru înregistrare, acces şi stare în raport cu gatekeeper-

ul. Înspre reţeaua cu comutaţie de circuite, sunt funcţionale componente specifice reţelelor

SCN (Switched Circuit Network)(ex. ISDN, SS7).

Terminalele comunică cu gateway-ul folosind protocolul H.245 de control al

semnalizării şi H.225 pentru semnalizarea apelului. Gateway-ul translatează transparent

aceste informaţii către reţeaua non-H.323 corespondentă şi invers. Transferul formatelor

informaţiilor audio, video, sau de date poate fi realizat tot de către gateway. Pot exista situaţii

în care acest transfer audio sau video nu este necesar, în cazul în care cele 2 terminale

folosesc moduri de comunicare identice. Un exemplu îl poate constitui un gateway către o

reţea ISDN, mai precis către un terminal H.320. Ambele terminale necesită G.711 audio şi

H.261 video, deci un mod comun. Gateway-ul are caracteristici pentru ambele terminale,

H.323 şi non-H.323. El este totuşi o componentă logică ce poate asigura mai multe convorbiri

simultane şi poate fi implementat ca o parte a unui gatekeeper sau MCU.

Gatekeeper (GK) – asigură serviciile de control al apelurilor pentru terminale, ca

translaţia adreselor, managementul benzii. Existenţa şi folosirea lor în reţelele H.323 este

opţională. Dacă sunt prezente totuşi, terminalele şi gateway-urile trebuie să folosească

Pagina 27 din 133


serviciile oferite de ele. Standardele H.323 specifică serviciile precise care trebuie asigurate şi

alte funcţionalităţi opţionale ce pot fi asigurate.

O facilitate opţională este rutarea semnalizării apelului. Terminalele trimit mesaje

pentru semnalizare apel gatekeepr-ului, iar acesta le rutează către celălalt terminal. O altă

variantă ar fi ca acest lucru să se facă fără tranzitarea gatekeeper-ului. Această funcţie este cu

atât mai valoroasă cu cât monitorizarea apelurilor de către gatekeeper asigură un control mai

bun al apelurilor din reţea, de vreme ce deciziile de rutare luate de GK sunt bazate pe o mare

varietate de factori.

Figura 1.5.1.3 Funcţiunile GK. [10].

Un GK ese opţional într-un sistem H.323. Serviciile oferite de el sunt definite de către

RAS şi includ translaţia adreselor, controlul accesului, managementul zonei H.323. Reţelele

H.323 care nu au implementate GK, nu beneficiază de asemenea facilităţi, însă este

recomandat ca acolo unde există gateway-uri de telefonie IP să existe si GK, care să

translateze adresele telefonice E.164 în adrese de transport din reţeaua IP. Ca şi gateway-ul,

este o componentă logică, iar ea poate fi implementată ca parte a unui gateway, sau MCU.

1.5.2 Sarcini obligatorii ale unui gatekeeper


Un gatekeeper are o prezenţă opţională în reţeaua H.323. În situaţia în care se

foloseşte, vine să mărească controlul asupra apelurilor efectuate şi, conform standardului

H.323, trebuie să îndeplinească anumite funcţiuni obligatorii.

Pagina 28 din 133


Translaţia adreselor – Apelurile efectuate din interiorul reţelei H.323 pot folosi un

înlocuitor al adresei terminalului destinaţie, în timp ce apelurile realizate din afara reţelei

H.323 şi primite de un gateway pot folosi numere de telefon conform specificaţiei E.164

asupra numerotaţiei PSTN, pentru a adresa un terminal. Gatekeeper-ul este cel care

translatează numerele de telefon E.164, sau înlocuitorii lor în adrese de reţea (ex:

205.255.195.89:5004 pentru o reţea IP) pentru terminalele destinaţie.

Controlul accesului – GK poate controla accesul terminalelor în reţeaua H.323. El

foloseşte pentru aceasta mesaje RAS, cereri de admisie(ARQ), confirmări(ACF) şi respingeri

(ARJ). Un caz simplu ar fi ca controlul admisiei să fie o funcţie nulă, care să admită toate

terminalele din reţeaua H.323.

Controlul lăţimii de bandă – GK asigură suport pentru controlul benzii prin

intermediul folosirii mesajelor de tip RAS, cereri de alocare de bandă(BRQ),

confirmări(BCF) şi refuzuri(BRJ). Spre exemplu, dacă un gestionar de reţea semnalizează o

depăşire a unui număr de comunicaţii simultane în reţeaua H.323, gatekeeper-ul poate refuza

ulterioare conexiuni odată atins un prag. Rezultatul este limitarea benzii totale alocate la o

anumită fracţiune din banda disponibilă. La fel ca şi în cazul anterior, controlul benzii poate

fi o funcţie nulă ce acceptă toate cererile de bandă.

Managementul zonei – gatekeeper-ul are rolul de a asigura funcţiile mai sus amintite

pentru terminalele, gateway-urile şi unităţile MCU ce se găsesc în zona sa de control.

Semnalizarea de control a apelului – GK poate ruta mesajele de semnalizare a

apelului dintre terminale. Într-o comunicaţie punct-la-punct, GK poate procesa

mesaje H.225 de semnalizare a apelului. Alternativ, GK poate permite terminalelor

să-şi trimită direct, unul celuilalt mesaje de semnalizare a apelului H.225.

Autorizarea apelului – Atunci când un terminal trimite mesaje H.225 de semnalizare a

apelului către GK, acesta din urmă poate accepta sau respinge apelul, potrivit specificaţiilor

H.225. Motivele refuzului pot avea în vedeere restricţii de acces sau de timp către sau de la

un gateway.

Gestiunea apelului – GK-ul poate avea şi menţine informaţii despre toate apelurile

H.323. Astfel poate controla zona sa prin furnizarea informaţiilor proprii funcţiei de gestiune

a benzii, sau, prin rerutarea apelurilor către terminale pentru a obţine traficul echilibrat.

Pagina 29 din 133


CAPITOLUL 2. Arhitectura centralei telefonice digitale “TOPEX 1000D”

2.1. Prezentare generală

Referinţe bibliografice: [6], [7]

Centrala TOPEX 1000D este o centrală telefonică digitală cu o capacitate maximă de

1536 abonaţi locali şi 120 joncţiuni. Ea este concepută într-o arhitecură modulară ce permite

configurarea într-o gamă foarte diversă. Centrala este realizată cu componente electronice

moderne, specializate pentru comunicaţii digitale.

Centrala are o arhitectură ierarhizată pe mai multe nivele de comandă. La alegerea

arhitecturii s-a avut în vedere dublarea elementelor de comandă şi a câmpului de comutaţie.

În proiectarea centralei s-a avut în vedere împingerea inteligenţei spre periferie în

scopul diminuării efortului de calcul al unităţii centrale şi, implicit, simplificarea programelor

executate la acest nivel, dar, pe de altă parte, creşterea calităţii serviciului.

Asigurarea fiabilităţii se face prin duplicare în regim de divizare de trafic la nivel

central sau reconfigurări de grup, în sensul că o unitate are disponibilităţi pentru a prelua

încărcarea unităţii vecine în cazul defectării acesteia.

Figura următoare prezintă principalele module componente ale centralei:

Figura 2.1.1. Blocurile componente ale centralei TOPEX 1000D

Unitatea centrală este realizată cu două procesoare care lucrează paralel, tratarea

apelurilor fiind distribuită în mod egal între ele. În cazul defectării unuia dintre procesoare,

Pagina 30 din 133


procesorul rămas în funcţiune va prelua tratarea tuturor apelurilor. Aceasta va duce la

scăderea capacităţii de trafic a centralei, dar nu duce la ieşirea din funcţionare a acesteia.

Rolul unităţii centrale este de a identifica portul de destinaţie pe baza informaţiei de

numerotaţie primită de la unitatea de grup şi de a stabili o legătură prin reţeaua de

comunicaţie între unitatea de grup sursă şi unitatea de grup căreia îi aparţine portului

destinaţie. Grupul destinaţie va fi fie un grup de abonaţi locali, fie un grup de trunchiuri.

Identificarea se va face de către procesul de rutare pe baza tabelei cu identificatori telefonici

(număr de apel telefonic) ai porturilor centralei.

Câmpul de comutaţie este realizat cu matrici de comutaţie spaţio-temporale format

din două subcâmpuri echivalente cu o structură Kloss pătrată 512 x 512. Cele două plane

funcţionează în paralel. În cazul defectării unuia din ele, celălalt poate prelua tot traficul din

centrală.

Unităţile de grup de abonaţi conţin interfeţele de abonaţi locali, modulul de test şi

procesorul de grup de abonaţi. Interfeţele sunt realizate pe module de opt abonaţi. O unitate

de grup de abonaţi are capacitatea de 128 linii şi este controlată de procesorul de grup.

Unităţile de joncţiuni analogice conţin interfeţele de joncţiuni care pot fi de tip E&M

la 4/6 fire sau joncţiuni de curent continuu , modul de test şi procesorul de grup de joncţiuni

analogice.

Unitatea de grup trunchi digital conţine două interfeţe de trunchi digital conforme

specificaţiilor G.701 şi un procesor de grup.

Unităţile de grup sunt interconectate două câte două printr-o magistrală de control.

Acest lucru face posibil ca în cazul defectării unui procesor de grup, procesorul celeilalte

unităţii să preia şi abonaţii procesorului defect.

Unităţile de grup sunt conectate la unitatea centrală prin fluxuri PCM prin care se

asigură transmiterea vocii cât şi comunicarea între procesoarele de gup şi unitatea centrală.

Unităţile de grup sunt echipate de asemenea cu generator de apel.

Tensiunile necesare alimentării unităţii centrale şi a unităţilor de grup sunt obţinute cu

ajutorul unor convertoare DC/DC care sunt alimentate la -48V şi care furnizează tensiunile de

± 5Vcc.

Sursele de alimentare şi generatorul de apel sunt dublate: au două secţiuni identice,

una activă şi una de rezervă.

Pagina 31 din 133


Blocul de alimentare conţine un filtru de separare a tensiunii de -48V în -48V

analogic pentru alimentarea buclei şi -48V digital pentru alimentarea convertorilor DC/DC.

De asemenea mai conţine siguranţe pentru fiecare unitate de grup.

Blocul de alimentare conţine redresorul de -48V şi bateriile.

Taxarea este asigurată de către procesorul de administrare şi taxare, informaţia de

taxare fiind memorată pe harddisk şi trimisă la centrul de supraveghere.

Ca facilităţi de abonat, centrala asigură serviciile standard pentru o centrală digitală:

apel de urmărire, apel programat, semnalizare apel în aşteptare, restricţionare acces cu parolă,

numerotaţie automată.

2.2. Arhitectura hardware


Schema bloc a centralei telefonice care evidenţiază şi a structura arhitecturii hardware

este prezentată în figura de mai jos:

Pagina 32 din 133


Figura 2.2.1: Arhitectura hardware a centralei telefonice TOPEX 1000D

Abrevierile din figură au următoarele semnificaţii:

PCTA - Procesor Central de Tratare Apeluri;

UA - Unitate de Abonaţi;

UTD - Unitate de Trunchi Digital

Procesorul de mentenanţă şi administrare este realizat pe un calculator compatibil

IBM-PC. Procesorul de mentenanţă gestionează baza de date cu configutraţia centralei, baza

de date de taxare şi testarea periodică a centralei. Comunicaţia cu procesoarele centrale se

face serial.

Pagina 33 din 133


Procesorul Central de Tratare Apeluri ( PCTA ) este cel care gestionează resursele

centralei. Procesoarele de grup sunt interogate periodic de către procesoarele centrale asupra

stării liniilor. La iniţierea unui apel procesorul central stabileşte conexiunea prin câmpul de

comutaţie şi asigură sincronizarea proceselor ce cooperează la tratarea apelului. Tot

procesorul central asigură taxarea convorbirilor.

Procesoarele de grup ( PG ) gestionează abonaţii locali şi trunchiurile. Ele comunică

procesorului central informaţii privind starea liniilor şi gestionează resurele locale care permit

accesul la câmpul de comutaţie central. Procesoarele de grup comunică cu Unitaăţile de

Abonat (UA) şi cu Unităţile de Trunchi Digital (UTD) pe o magistrală serială. Fiecare

procesor de grup gestionează două magistrale seriale (Bus0 şi Bus1). Bus0 este folosită

pentru a comunica cu unitaţile de abonat proprii, iar Bus1 este folosit pentru a prelua unităţile

de abonat ale unui procesor de grup defect.

Unităţile de abonat ( UA )conţin opt interfeţe de linie de abonat. Acestea sunt

supravegheate de un procesor local care comunică procesorului de grup evenimentele apărute

pe linie.

Unităţile de trunchi digital ( UTD ) conţin o interfaţă de trunchi digital. Aceasta este

controlată de un procesor local care comunică procesorului de grup evenimentele de pe

fiecare canal.

Comunicaţia între procesoarele centrale şi procesoarle de grup se relizează prin

fluxurile PCM pe două canale rezervate pentru comunicaţie.

Fiecare procesor de grup este conectat printr-un flux PCM la fiecare din cele două

procesoare centrale. În funcţionarea normală apelurile sunt tratate alternativ de un PCTA sau

de altul. Dacă unul din procesoarele centrale se defectează atunci procesorul rămas funcţional

va prelua tratarea tuturor apelurilor, capacitatea de realizare a convorbirilor înjumătăţindu-se.

2.2.1 Procesorul Central de Tratare Apeluri


Procesorul Central de Tratare Apeluri este cel care gestionează activitatea întregii

centrale.

Pagina 34 din 133


Principalele funcţii ale acestuia sunt:

tratarea tuturor cererilor de apel;

gestiunea conexiunilor prin câmpul de comutaţie;

comunicaţia cu procesoarele de grup;

generarea taxării;

iniţierea programelor de test la nivelul procesoarelor de grup;

detectarea configuraţiei centralei.

Datorită importanţei procesorului central acesta este dublat. În funcţionare normală,

tratarea apelurilor este distribuită uniform între ambele procesoare centrale. În cazul

defectării unuia dintre ele, toate apelurile vor fi tratate de procesorul rămas funcţional.

Evident că aceasta va duce la o scădere a capacităţii de trafic, dar centrala va continua să

funcţioneze. Defectarea unuia din procesoarele centrale se alarmează la terminalul de

administrare şi mentenanţă.

Figura următoare prezintă principalele elemente componete ale procesorului central

de tratare apeluri:

Pagina 35 din 133


Figura 2.2.1.1 - Schema bloc a Procesorului Central de Tratare Apeluri

Interfaţa de bus asigură amplificarea semnalelor de adrese, date şi control, generează

semnale de selecţie pentru accesul la câmpul de comutaţie şi sincronizează funcţionarea

procesorului cu cea a câmpului de comutaţie pe timpul acceselor la acesta din urmă.

Câmpul de comutaţie este realizat cu 4 comutatoare spaţio-temporale interconectate

ca în figura următoare. Se obţine un comutator spaţio-temporal cu 16 fluxuri PCM de intrare

şi 16 fluxuri PCM ieşire. Un grup de abonaţi este conectat la câmpul de comutaţie printr-o

pereche intrare/ieşire realizându-se o concentrare de 4 la 1 ( 128 abonaţi la 32 canale

temporale ). Deoarece arhitectura centralei prevede dublarea câmpului de comutaţie, în

funcţionare normală se realizează o concentrare 2 la 1. Prin câmpul de comtaţie se face şi

comunicaţia cu procesoarele de grup. Fluxurile PCM sunt trimise şi recepţionate prin

amplificatori diferenţiali cea ce oferă o imunitate mai mare la perturbaţii.

Pagina 36 din 133


Figura 2.2.1.2. - Schema bloc a câmpului de comutaţie

Generatorul de ceas generează semnalele de sincronizare pentru întreaga centrală. Se

generează semnalul de sincronizare de cadru F0 şi un ceas de 4MHz. Semnalele sunt trimise

diferenţial prin amplificatoarele de emisie. Pe centrală există două generatoare de ceas (câte

unul pe fiecare procesor central), la un moment dat centrala lucrând cu semnalele generate

numai de unul dintre ele. În caz că dispar semnalele de sicnronizare de la un generator de

ceas se comută automat pe semnalele de la celălalt generator.

Selecţia semnalelor de sincronizare şi generarea semnalelor locale se face cu circuitul

bază de timp.

Generatorul de întreruperi divide semnalul F0 şi generează cereri de întrerupere care

activează procesul de comunicaţie cu procesoarele de grup.

2.2.2 Procesorul de grup

Pagina 37 din 133



Procesorul de grup se află pe nivelul ierarhic numărul 2 si are rolul de asigura

supravegherea abonaţilor ( pentru grupurile de abonaţi ) şi a joncţiunilor ( pentru grupurile de

trunchi digital ), gestionează canalele temporale de pe fluxurile PCM locale şi controlează

accesul la fluxurile PCM spre câmpul de comutaţie.

Schema bloc a Procesorului de Grup este prezentată în figura de mai jos:

Figura 2.2.2.1 . Procesorul de Grup – schema bloc

Comutatorul spaţio-temporal este folosit pentru a dirija canalele din fluxurile PCM

locale grupului spre fluxurile PCM care merg la câmpul de comutaţie. În afară de funcţia de

comutaţie, comutatorul spaţio-temporal mai asigură comunicaţia cu procesoarele centrale.

Fluxurile PCM 0 la 3 sunt folosite local pentru semnalele de convorbire de la abonaţi.

Pagina 38 din 133


Fluxurile PCM 4 şi 5 sunt folosite pentru generarea tonurilor şi a semnalelor multifrecvenţă.

Fluxurile PCM 6 şi 7 se utilizează pentru legătura cu câmpul de comutaţie.

Pentru grupurile de abonaţi locali procesorul de grup se echipează cu circuite

emiţătoare/receptoare DTMF. Pentru grupurile de trunchiuri se echipează cu circuite de

semnalizarea multifrecvenţă R2 (MFR2). Atât blocul DTMF cât şi cel MFR2 sunt relizate cu

procesoare digitale de semnal.

Blocul MFR2 conţine 8 perechi de regiştri înainte/înapoi. Un procesor de grup pentru

trunchi digital poate controla 2 trunchiuri digitale ceea ce înseamnă 8 perechi de regiştri la 30

de joncţiuni.

Blocul DTMF conţine 12 perechi de emiţători / receptori pentru 128 abonaţi.

Baza de timp primeşte semnalele de sincronizare de la unul din generatoarele de ceas

şi generează semnalele locale de sincronizare asigurând relaţiile de fază corecte. Sunt

generate C4 - 4,096 MHz necesar comutatorului spaţio-temproal, C2 2,048 MHz - ceasul de

bit pentru fluxurile PCM şi F0 - semnalul de sincronizare de cadru. Semnalul de ceas C2 şi

semnalul de sincronizare de cadru sunt trimise şi spre unităţile de abonaţi prin amplificatoare

diferenţiale.

Logica de sincronizare generează, pornind de la C2 şi F0, semnalele de sincronizarea

a emisiei (FSx) şi a recepţiei (FSr), pentru generatorul de tonuri şi blocurile DTMF sau

MFR2. Această logică conţine un circuit de tip TSAC (Time Slot Assignment Circuit) şi

logica de comandă a acestuia de către microprocesor.

Generatorul de întreruperi divide semnalul de sincronizare de cadru F0 şi generează

cereri de întrerupere pentru comunicaţia cu procesoarele centrale.

Microprocesorul are două interfeţe seriale. Ambele sunt folosite pentru comunicaţia

cu unităţile de abonaţi.

Toate semnalele sunt emise şi recepţionate prin amplificatori diferenţiali ceea ce

asigură o imunitate sporită la perturbaţii.

2.2.3 Unitatea de abonaţi


Unitatea de abonat conţine 8 interfeţe analogice de linie. Unitatea este controlată de

un microprocesor care supraveghează starea fiecărei linii şi trimite spre procesorul de grup

mesaje de notificare. Schema bloc a unităţii de abonat este prezentată în figura de mai jos:

Pagina 39 din 133


Figura 2.2.3.1 – Unitatea de Abonaţi – schema bloc

O interfaţă foloseşte acelaşi canal temporal atât pentru emisie cât şi pentru recepţie.

Circuitul de sincronizare este realizat cu un circuit integrat specializat de tip TSAC şi este

comandat de către microprocesor prin doi biţi ai unui port de ieşire.

În cadrul unui grup fiecare unitate de abonat are o adresă unică codificată pe 5 biţi.

Această adresă este folosită pentru identificare în cadrul comunicaţiei cu procesorul de grup.

Adresa este cablată pe fundul de sertar şi este citită prin circuitul de citire a adresei.

Rolul UCP de pe unitatea de abonat este de a degreva procesorul de grup de

prelucrarea evenimentelor rapide care apar pe linia de abonat. UCP detectează închiderea şi

deschiderea telefonului precum şi cifrele formate în mod puls şi trimite spre procesorul de

Pagina 40 din 133


grup mesaje de notificare. La comanda procesorului de grup UCP poate conecta o interfaţă la

un canal temporal şi poate trimite curent de sonerie.

Unitatea de abonat este interogată periodic de către procesorul de grup pe una din

magistralele seriale 0 şi răspunde cu evenimentele apărute. Dacă unitatea nu primeşte mesaj

de interogare un anumit timp va selecta automat cealaltă magistrală pe care este interogată de

alt procesor de grup.

În figura 2.2.3.2 este prezentată schema bloc a unei interfeţe de linie analogică.

Interfaţa conţine 3 relee: releu pentru testul liniei de abonat, releu pentru testul interfeţei de

abonat şi reşeu de apel. În figură releele sunt desenate în poziţia normală de funcţionare.

Linia este alimentată în curent continuu prin două generatoare de curent care au o impedanţă

mare în curent alternativ. Semnalul de convorbire este aplicat printr-un transformator unui

circuit de trecere de la 2 la 4 fire şi apoi spre CODEC. Rolul circuitului de trecere de la 2 la 4

fire este de a separa calea de emisie de cea de recepţie.

Figura 2.2.3.2 - Schema bloc a unei interfeţe de linie analogică

Pagina 41 din 133


Detectorul de curent este folosit pentru a detecta starea telefonului.

Pentru testul liniei de abonat se comandă atragerea releului de test al liniei. Linia de

abonat va fi pusă prin contactele acestui releu pe o linie de test care este conectată la un

echipament de test.

Pentru testul interfeţei de abonat se comandă atragerea releului de test al interfeţei.

Prin contactele acestui releu interfaţa este conectată la o linie din echipamentul de test al

interfeţei de abonat.

Pentru a genera curent de sonerie se comandă atragerea releului de apel. Cadenţarea

apelului se face din releu.

2.2.4. Unitatea de trunchi digital


Unitatea de trunchi digital conţine o interfaţă de trunchi digital. Schema bloc a uităţii

de trunchi digital este cea din figura 12. Interfaţa de trunchi este controlată de unitatea

centrală de prelucrare realizată în jurul unui microprocesor din familia Intel 8051.

Pagina 42 din 133


Figura 2.2.4.1 - Schema bloc a uităţii de trunchi digital

Logica de interfaţă asigură interfaţarea microprocesorului cu comutatorul spaţio-

temporal. Comutatorul este folosit pentru controlul interfeţei de trunchi digital şi pentru

conecatrea acesteia la fluxurile PCM ale grupului.

Comunicaţia cu procesorul din grup se face pe fluxul PCM.

Interfaţa serială este folosită în faza de test al unităţii de trunchi digital.

Interfaţa propriu-zisă de trunchi digital este realizată cu un circuit hibrid specializat

pentru interfaţa CEPT de trunchi digital, conform cu recomandările CCITT G.704 pentru

PCM30 . Are facilităţi ca: inserarea şi detectarea semnalelor de sincronizare, codeare şi

decodare HDB3, atenuare programabilă şi CRC opţional.

Conform specificaţiilor interfeţei CEPT cadrele PCM sunt grupate în multicadre

( vezi figura 2.2.4.2). Un multicadru este format din 16 cadre. Într-un cadru PCM se folosesc

Pagina 43 din 133


numai 30 de canale temporale pentru canale telefonice ( canalele 1-15 şi canalele 17-31 )

rămânând două canale folosite unul pentru semnalele de sincronizare de cadru şi multicadru

(canalul temporal 0) şi altul pentru semnalizare de linie pentru canalele telefonice ( canalul

temporal 16 ).

Figura 2.2.4.2 - Interfaţa CEPT

Semnalul de sincronizare de cadru se trimite în canalul temporal 0 în cadrele pare.

Semnalul de sincronizare de cadru conţin un 0 pe poziţia bitului 2. Bitul 1 este rezervat

pentru utilizare internaţională, bitul 3 este 0 iar biţii 4, 5, 6, 7 şi 8 au valorile 11011. În

cadrele impare canalul temporal 0 este folosit pentru a indica alarme. În acest caz bitul 2 este

1, bitul 3 este folosit ca indicator de alarmă către echipamentul PCM distan iar biţii 4, 5 , 6, 7

şi 8 au semnificaţie naţională.

Semnalele pentru semnalizarea de linie a canalelor telefonice (A,B,C şi D ) sunt

trimise în canalele temporale 16 ale cadrelor 1-15. În cadrul 1 se trimit semnalizarile pentru

canalul telefonic 1 şi 17, în cadrul semnalizările pentru canelele telefonice 2 şi 18, ş.a.m.d.

Semnalizarea de linie se face conform protocolului R2 digital. În cadrul acestui

protocol se utilizează două căi de semnalizare, înainte şi înapoi, pentru fiecare folosindu-se

câte 2 biţi af şi bf pentru sensul înainte ab şi bb pentru sensul înapoi..

2.3. Arhitectura software

Pagina 44 din 133



La realizarea software-lui s-au avut în vedere următoarele obiective:

modularitate

extensibilitate atât a hardware-ului cât şi a software-ului

siguranţă în funcţionare

întreţinere comodă

adaptare la structura distribuită a sistemului

independenţă cât mai mare în raport cu hardware-ul

Prinicipalele caracteristici ale software-ului sunt:

arhitectură modulară, ierarhizată, distribuită

diviziune funcţională pentru componentele software

distribuire optimă între procesoarele sistemului - sarcinile complexe care nu necesită

un răspuns critic în timp la nivel central: - sarcinile de timp real la nivel periferic

organizare stratificată

Arhitectura software-ului este schiţată în figura 2.3.1:

Figura 2.3.1 - Arhitectura software a centralei TOPEX 1000D

Componenta OAM - Operare, mentenanţă, administrare

Pagina 45 din 133


Are ca scop comunicaţia om-maşină, întreţinerea bazelor de date pe disc, sistem de

alarme, comunicaţie cu centrul de supraveghere, modificarea configuraţiei, gestiunea

resurselor. Funcţiile realizate de acest modul sunt:

Operare, administrare, acestea includ:

măsurători de trafic şi performanţe

gestiunea centralei

modificări de date semipermanente ( plan numerotaţie, categorii, rutare, tarife )

gestiunea reţelei - analiza situaţiilor de congestie internă/externă, rapoarte, modificări

de alocare la comanda operatorului

Mentenanţă

lansare de teste pentru linii, trunchiuri, circuite auxiliare

interacţiune a operatorului cu sistemul de alarme

Componenta IS - întreţinere şi siguranţă

Are ca scop menţinerea stării de funcţionare a centralei prin teste periodeic de

ansamblu şi interacţiunea sistemului de operare pentru reconfigurări. Această componentă

softare este cea care asigură la nivel software comutarea componentelor dublate.

Are ca funcţii:

localizarea defectelor l anivelul UA, PG sau PCTA

reiniţializarea modulelor software şi hardware

efectuarea testelor şi tratarea erorilor

comanda reconfigurărilor, prin interacţiune cu sistemul de operare

comanda alarmelor

reîncărcări de software

Componenta TA - tratarea apelurilor

Tratarea apelurilor la nivel logic are ca scop tratarea apelurilor locale, de ieşire şi de

intrare, independent de sistemul de semnalizări şi de hardware.

Are ca funcţii:

stabilirea / menţinerea/ eliberarea apelurilor normale

identificarea linie şi a tipului de apel

determinarea restricţiilor/drepturilor

achiziţia adresei-destinaţie ( de la sofftware-ul de semnalizare şi suport )

Pagina 46 din 133


taxare

comanda conexiunilor

eliberarea ressurselor

stabilirea/menţinerea/eliberarea apelurilor cu cereri de servicii adiţionale

Idependenţa faţă de sistemul de semnalizări şi de hardware este realizată de software-

ul de semnalizare şi suport.

Acesta realizeză:

tratarea semnalizărilor

detecţia evenimentelor de semnalizare

virtualizarea evenimentelor ( independenţa de harware-ul de semnalizare)

translatarea evenimentelor de semnalizare în mesaje cu semnificaţie telefonică.

alocarea/eliberarea resurselor de semnalizare

- gestiunea şi alocarea resurselor pentru apel

comanda interfeţelor telefonice

Componenta SO + BD - Sistem de operare, baza de date

Are ca scop:

gestiunea resurselor hardware şi software ale sistemului

interfaţarea cu hardware-ul

tratarea erorilor şi reconfigurarea sistemului ( prin inreacţiune cu componenata IS )

furnizarea unui suport de comunicaţie între procese

gestionarea bazei de date

Funcţiile realizate sunt:

- nucleu, care asigură:

planificarea în timp real a proceselor

gestiunea / protecţia memoriei

control temporizări

control întreruperi

intrări/ieşiri la nivel fizic

- program de comunicaţie de mesaje între procese

- iniţializare / reconfigurare

- gestiunea bazei de date

Modul de distribuire a componentelor software descrise mai sus la nivelul

procesoarelor este arătat în figura 2.3.2:

Pagina 47 din 133


Figura 2.3.2 - Distribuţia componentelor software în procesoare

Capitolul 3 “VoIP card” – VoIP gateway

3.1 Prezentare generală

Până la îndeplinirea uneia din marile dorinţe în privinţa realizării comunicaţiilor, am

numit aici integrarea serviciilor, mai este mult timp, datorită unor variate motive: probleme

specifice fiecărui tip de reţea, nivelul investiţiilor în infrastructura deja existentă, etc. Din

acest motiv, pentru buna intercomunicare între diferitele reţele ce au fiecare particularităţile

sale (formatul datelor, semnalizări, etc.), se folosesc dispozitivele numite gateway.

Un gateway se află la graniţa dintre 2 reţele diferite şi are rolul de a realiza

interconectarea acestora. El trebuie să aibă module de funcţionare specifice celor 2 reţele şi

trebuie să realizeze translaţia semnalizărilor şi formatelor diferite de date cu care se lucrează.

Gateway-ul H.323 este o componentă esenţială bunei intercomunicări a reţelei H.323

cu celelalte reţele telecom fiind una din cele 4 componente ale unei reţele H.323, iar alături

de terminale, el are un caracter obligatoriu.

“VoIP card” este un gateway de voce, o poartă de ieşire pentru transportul vocii

folosind ca suport reţeaua IP. Ca orice gateway, sunt obligatorii implementările

Pagina 48 din 133


funcţionalităţilor pentru compatibilitatea cu reţeaua PSTN şi reţeaua de pachete IP şi cea

pentru translaţia formatelor diferite de transmisie a datelor.

“VoIP card” funcţionează în arhitectura generală a centralei telefonice publice

TOPEX 1000D şi reprezintă calea de ieşire pentru transportul vocii peste o reţea pachete de

tip IP.

Pagina 49 din 133


3.2 Amplasarea cartelei în arhitectura

funcţională a centralei


Proiectarea şi implementarea funcţională a centralei telefonice publice TOPEX 1000D

s-a realizat avându-se în vedere obiective ca: modularitate, extensibilitate atât a hardware-

ului, cât şi a software-ului, independenţă cât mai mare în raport cu hardware-ul, împingerea

“inteligenţei” cât mai aproape periferia funcţionalităţilor. Toate acestea au dus la obţinerea

unei arhitecturi ierarhizate şi distribuite, organizare stratificată şi posibilităţi de dezvoltare

ulterioară a diversor aplicaţii.

“VoIP card” este o aplicaţie care trebuie să se integreze foarte bine în arhitectura

funcţională (hardware şi software) deja construită a centralei telefonice, mai ales că are rolul

de a realiza comunicarea centralei telefonice cu alt tip de reţea de transport, bazată pe

comutaţia de pachete IP, total diferită de comutaţia de circuite.

În urma analizei celei mai bune poziţionări a cartelei în arhitectura generală a

centralei, analiză care a avut în vedere diverşi factori de decizie, s-a decis folosirea ei pe

ultimul nivel ierarhic, cel al nivelul Unităţii de Abonaţi (UA).

Figura 3.2.1. ilustrează amplasarea cartelei în arhitectura structurală a centralei

telefonice:

Pagina 50 din 133


Pagina 51 din 133


3.3 “VoIP card” – extensie a funcţionalităţilor centralei telefonice


Dezvoltarea structurată a arhitecturii centralei telefonice TOPEX 1000D şi

împingerea “inteligenţei” până aproape de periferie în scopul diminuării efortului de calcul al

unităţii centrale de calcul, au permis proiectarea destul de facilă a unui gateway H.323, care

să realizeze puntea de legătură pentru transportul semnalelor de voce pe suportul constituit de

o reţea de pachete IP.

Anunţam în subcapitolul precedent faptul că în urma analizei privitoare la cea mai

bună amplasare a cartelei în arhitectura funcţională a centralei telefonice, aceasta va fi pe

ultimul nivel al ierarhiei structurale.

Întrucât cartela funcţionează pe acelaşi ultim nivel, ca şi Unitatea de Abonaţi, în

raport cu ansamblul structural ea intercomunică în aceeaşi manieră ca şi cartela UA. Un rol

foarte important în această situaţie îl are componenta hardware de adaptare la “fundul de

sertar”, fiind poarta de intrare sau/şi de ieşire a semnalelor prin intermediul cărora cartela

interacţionează cu sistemul (semnale de ceas, alimentare, fluxuri PCM, etc.).

Gateway-ul “VoIP card” poate fi privit ca un periferic de tip “slave” al Procesorului

de Grup(PG) şi ca o joncţiune de intrare/ieşire a sistemului.

Fiind un subordonat direct al Procesorului de Grup (PG), la fel ca şi în cazul UA-ului,

se folosesc aceleaşi modalităţi de comunicare cu “VoIP card”. Comunicaţia de voce se

realizează prin intermediul celor 2 fluxuri PCM folosite pentru abonaţii aferenţi lui, pe care le

primeşte folosind adaptorul de fund de sertar, iar comunicaţia de semnalizare se face folosind

o reţea de comutaţie de mesaje, prin protocoale de acces multiplu cu arbitraj centralizat,

arbitrul aflându-se în PG:

Din punctul de vedere al posibilităţii de realizare a apelurilor, trebuie amintit că,

întrucât, în principiu, gateway-ul este o poartă de transfer între 2 reţele de tip diferit, nu se

poate vorbi despre satisfacerea unor apeluri locale folosind “VoIP card”. Pot fi însă cu

succes îndeplinite apeluri de intrare sau apeluri de ieşire ale centralei telefonice în

reţeaua H.323.

Pagina 52 din 133


La stabilirea unui apel telefonic de către un abonat local, acesta va fi pus în faţa

următoarelor variante, iar în funcţie de opţiunea abonatului telefonic, are loc în Unitatea

Centrală analiza şi decizia asupra interfeţei de ieşire a apelului:

Unitatea de Abonat (UA), pentru apeluri locale.

Joncţiune digitală, pentru apeluri de ieşire prin reţeaua telefonică.

VoIP card, pentru apeluri de ieşire prin reţeaua IP.

Prezintă interes varianta în care opţiunea abonatului este de a folosi ca poartă de ieşire

a apelului gateway-ul VoIP. În această situaţie, prima măsură ce va fi luată este de a

semnaliza PG-ului intenţia de realizare a unui apel. Cel din urmă îi va aloca pe fluxul TDM

de comunicare cu UA-urile un canal temporal pentru transmiterea eşantioanelor de voce. În

acelaşi timp va anunţa gateway-ul de opţiunea de efectuare a unui apel şi va aloca de

asemenea un canal temporal pe fluxul PCM cu care comunică cu gateway-ul, canal pe care în

PG vor fi comutate apoi eşantionalele de voce. “VoIP card”-ul, prin modulul său ce

realizează interfaţarea şi comunicarea cu reţeaua telefonică va prelua conţinutul canalului

corespunzător şi buffer-a în memoria sistemului. De acolo, vor intra în sarcina modulului de

procesare a vocii, iar modulul de interfaţă şi comunicare cu reţeaua H.323 va iniţia şi stabilii

funcţionarea unui apel în reţeaua de pachete.

În cazul apelurilor de intrare, detectate de către modulul de interfaţă şi comunicare cu

reţeaua H.323 al “VoIP card”, celălalt modul de interfaţă cu reţeaua telefonică semnalizează

operaţia PG-ului, care alocă un canal temporal pe fluxul TDM prin intermediul căruia

comunică. Acest canal va permite transportul eşantioanelor recuperate, furnizate de către

modulul de procesare a vocii, către PG, locul unde vor fi comutate către un abonat local, sau

pe flux PCM la PCTA şi apoi către joncţiunea digitală de ieşire, în cazul unui apel de tranzit.

Pagina 53 din 133


Capitolul 4. VoIP card”–Implementare software

4.1 Scurtă prezentare hardware


Evoluţia spectaculoasă a tehnologiei de producere a circuitelor integrate a dus la

obţinerea unor performanţe deosebite din partea lor, dar mai ales un raport performanţă/preţ

foarte ridicat. Dintre acestea, DSP-urile au avut un mare salt calitativ, lucru care le-a

transformat în componente aproape ideale pentru multe aplicaţii de timp real, un exemplu

fiind şi cea de faţă.

Cartela VoIP are o structură hardware care să permită dezvotarea şi funcţionarea

modulară a unui gateway VoIP, structură prezentată în capitolul 1. Echipată cu 4 DSP-uri

Analog Devices AD2181, poate realiza preluarea, compresia şi transferul către procesorul

gazdă a 16 canale PCM 64 kbs. Principalele sale blocuri hardware componente sunt:

Adaptor de fund de sertar.

Matrice de comutaţie spaţio-temporală.

DSPk, k=1,4.

Logică de interfaţă

Host PC.

Adaptorul de fund de sertar – deşi nu are o foarte academică denumire, este foarte

important pentru buna comunicare a cartelei cu centrala telefonică. El are rolul de a-i asigura

plăcii accesul la alimentarea electrică ( -48V, -5V, GND, +5V), semnalele de sincronizare de

bit şi de cadru, venite de la Procesorul Central de Tratare Apeluri şi, nu în ultimul rând

fluxurile PCM de 2 Mbs de comunicare cu PCTA şi PG.

Matricea de comutaţie spaţio-temporală – construit în jurul unui chip MT 8980, blocul

are rolul de a comuta spaţio-temporal canalele temporale a 8 fluxuri PCM de 2 Mbs.

DSPk – cartela conţine 4 DSP-uri de tip Analog Devices AD2181. Acestea au o mare

putere de lucru şi sunt potrivite aplicaţiilor de pachetizare şi transmisie a vocii.

DSP-ul AD2181 are un spaţiu de memorie internă de 16Kx24 biţi memorie de

program de tip RAM şi 16Kx16 biţi pentru memoria de date, nefiind permis accesul

decât pe 16 biţi în acest spaţiu,. El mai poate folosi insă alte 4 zone de memorie

externe: de date, de program, I/O şi byte memory. Pentru lucrul cu aceste zone de memorie,

sunt furnizate semnale de selecţie a fiecăreia din cele 4 zone.

Pagina 54 din 133


În aplicaţia de faţă nu este folosită decât memoria de octeţi (“byte memory”), ca zonă

de memorie externă. Deşi volumul de memorie ce poate fi adresat şi folosit de DSP ca

memorie de octeţi este de 4Mbytes, ce sunt organizaţi în 256 pagini a câte 16Kx8 biţi, se

foloseşte doar un singur chip de memorie de 512Kx8 biţi.

Pentru o bună comunicare cu procesorul gazdă, AD2181 are 4 porturi: [5]

2 porturi seriale, configurabile prin intermediul unor regiştrii interni de control.

Portulul de acces BDMA (Byte-memory Direct Memory Access), ce poate fi folosit

pentru “boot”-are şi acces pe 8 biţi la memoria externă.

Portul IDMA(Internal Direct Memory Access) – port paralel ce poate fi folosit pentru

“boot”-are, sau accese din partea procesorului gazdă. DSP-ul asigură 6 pini de control pentru

buna funcţionare a portului IDMA.

Host PC [19]– este folosit un embedded PC/104 cu un procesor de 40MHz,

compatibil 386SX şi 8Mb memorie RAM. Pentru interfaţa cu reţeaua Ethernet lucrează un

chipset Realtek 8139 şi portul fizic compatibil 10Base-T NE2000.

Pentru stocarea datelor, suportul fizic este un DiskOnChip cu capacitatea de 2 Mb,

existând porturi pentru legătură cu HDD şi FDD.

Pe lângă portul de reţea, placa mai beneficiază de 4 porturi seriale, port paralel şi,

poate cel mai important, mai ales privit din direcţia comunicaţiei cu “VoIP card”, portul ISA,

cu 104 pini. Aceştia furnizează semnalele de control, bus-ul de date, bus-ul de adrese,

semnalul de ceas ISA (8MHz), cererile de întrerupere venite din partea DSP-urilor.

Logica de interfaţă – alcătuită dintr-o multitudine de componente digitale, are rolul a

realiza decodificarea adreselor, obţinerea unor semnale de control, cererea de întrerupere de 2

ms şi interfaţa de acces la DSP-urile şi procesorul gazdă, PC/104.

Schema hardware de principiu a “VoIP card” care prezintă componentele mai sus

amintite şi modul lor de intercomunicare este prezentată în figura 4.1.1:

Pagina 55 din 133


Figura 4.1.1. Schema hardware de principiu a “VoIP card”

Pagina 56 din 133


4.2 Software-ul aplicaţiei


Datorită complexităţii unui gateway, de orice fel ar fi el, trebuie să aibă mai multe

plane de funcţionare, unele specifice celor 2 reţele la graniţa cărora se doreşte acţiunea sa şi

unul de translaţie a celor 2 formate diferite de date cu care se lucrează.

Figura 4.2.1 Gateway IP/PSTN

Un gateway de voce nu este cu nimic diferit acestui principiu, iar funcţiunile lui se pot

împărţi în 4 module de activitate:

Modulul de pachetizare a vocii. – cunoscut şi sub numele de modulul de procesare a

vocii, funcţionează de regulă într-un DSP ( Digital Signal Processor ), datorită puterii sale

ridicate de calcul.

Modulul de realizare a semnalizării telefonice – interacţionează cu echipamentele

telefonice, translatând semnalizările telefonice în schimbări de stare, folosite de către

modulul de protocoale de reţea pentru stabilirea, menţinerea şi eliberarea conexiunilor.

Modulul de protocoale de reţea – procesează informaţiile de semnalizare şi le

converteşte din semnalizări specifice reţelei telefonice în protocoale de semnalizare în mod

pachet, folosite la stabilirea conexiunilor în reţeaua IP ( ex: Q.933 ).

Modulul de management a reţelei – asigură interfaţa de gestiune a vocii, pentru

menţinerea şi configurarea celorlalte module ale sistemului.

Pagina 57 din 133


Folosind hardware-ul mai înainte prezentat pe scurt, aplicaţia urmăreşte să

implementeze cele 4 module.

După cum am văzut în figura 1.3.2, cele 4 module ale software-ului rulează practic în

cele 2 unităţi de prelucrare a datelor, am numit aici procesorul gazdă, reprezentat de PC/104

şi cele 4 DSP-uri.

În cele 4 DSP-uri rulează modulul de procesare a vocii, implementat prin programe

care urmăresc:

Preluarea fluxurilor PCM de 2 Mbs de la PG (Procesorul de Grup).

Selectarea şi preluarea în buffer-ele de recepţie a canalelor temporale corespunzătoare

conexiunilor telefonice care se doresc a fi transportate pe suportul reprezentat de reţeaua IP.

Realizarea codării, conform specificaţiilor G.711, G.722, G.723.1, G.728.

Plasarea lor în zona de date, reprezentată de 2 buffer-e de unde procesorul gazdă le va

prelua. DSP-ul semnalizează din care buffer trebuie citit.

Buffer-ează pachetele de voce primite de la host, recepţionate din reţea.

Preluarea lor din zonele de memorie, reprezentate de asemenea de 2 buffer-e.

Decodarea acestora conform aceloraşi specificaţii mai sus amintite.

Alocarea pe fluxul PCM de comunicare cu PG-ul a canalelor temporale.

Inserarea în aceste canale a eşantioanelor de voce refăcute, de transmis către

terminalul telefonic.

Generează cererea de întrerupere către host.

Codul sursă pentru compilare, care apoi va fi încărcat prin IDMA şi rulat în DSP-uri

este scris atât în limbajul C++, cât şi în limbaj de asamblare specific AD2181.

Software-ul care rulează în procesorul gazdă, am numit aici modulul PC/104, are rolul

de a implementa celelalte 3 module ale structurii aplicaţiilor de voce: modulul de realizare a

semnalizării telefonice, modulul de protocoale de reţea, modulul de management a reţelei. Pe

lângă acestea, tot in PC/104 trebuie implementată şi buna comunicare cu DSP-urile.

4.2.1 Suportul dezvotării aplicaţiei în PC/104

Referinţe bibliografice: [2], [3], [4], [5], [19], [20], [21]

Modulul PC/104 ( [19] ) este un minicalculator integrat compatibil 386SX, cu 4MB

memorie RAM. Este foarte util în aplicaţiile de control şi comunicare cu alte dispozitive

periferice datorită portului ISA de 104 pini, punând la dispoziţie BUS-ul de adrese, BUS-ul

Pagina 58 din 133


de date, semnale de control, cereri de întrerupere, etc. Nu este obligatorie folosirea tuturor

acestora, acest lucru rămânând la latitudinea proiectantului.

Toate aceste facilităţi mai sus amintite îl fac foarte potrivit pentru sarcina sa de

procesor gazdă în cazul aplicaţiei noastre, unde pe lângă cele 3 module trebuiesc

implementate controlul şi gestiunea celor 4 DSP-uri şi a matricii de comutaţie.

Întreg software-ul aplicaţiei se află stocat pe un DiskOnChip cu capacitatea de 2MB.

S-a folosit un sistem de operare Microsoft DOS 6.22, care, deşi nu conţine stivă

TCP/IP, este de mici dimensiuni şi reprezintă un bun suport al aplicaţiilor implementate în

limbajul C++, mai ales celor dezvoltate cu mediul Borland C++ 3.1.

Inconvenientul reprezentat de lipsa suportului de comunicare cu reţeaua IP a fost

înlăturat prin folosirea stivei TCP/IP “WATTCP” ( [4], [20] ) folosibilă în aplicaţii de

comunicare, chiar şi de timp real, sub sistemul de operare MS-DOS. Dacă ar trebui să o

raportam la nivelul OSI, atunci trebuie spus că funcţionează la nivelele 3 şi oferă interfaţa

pentru funcţii specifice nivelului 4 (sockeţi, porturi, etc.)

Pentru funcţionarea stivei WATTCP trebuie mai întâi încărcat “packet driver”-ul

specific fiecărui chip-set de reţea. Acesta este furnizat de către producătorul NIC-ului

(Network Interface Card – placa de reţea) şi reprezintă interfaţa dintre stiva software şi

mediul fizic de transmitere a pachetelor de date(nivel 2 OSI simplificat). În aplicaţia de faţă,

“packet driver”-ul este conţinut în fisierul “pktdrv.com” şi este încărcat la pornirea hardware-

ului printr-un instrucţiunea “c:\pktdrv.com 0x60”, aflată în fisierul “autoexec.bat”.

Odată încărcat driverul, care instalează o întrerupere de DOS pentru lucrul cu placa de

reţea, utilizarea software-ului TCP/IP se face posibilă prin copierea a 7 fişiere

de tip header (“*.h”) în directorul “include” al mediului de dezvoltare Borland C++

3.1 şi includerea lui “tcp.h” în fişierul conţinând codul sursă al aplicaţiei dorite. În afară de

aceasta, mai trebuie inclus în proiectul de lucru un fişier de tip “.lib”, “wattcp.lib”, în funcţie

de modelul de lucru utilizat: small, large, huge.

Dacă până acum nu am vorbit decât despre modul de folosire a stivei WATTCP,

trebuie spus că pentru configurarea informaţiilor de reţea IP sunt 2 modalităţi. Prima este cea

în care aflarea lor se face prin BOOTP, în cazul în care în subreţeaua locală se află un server

dedicat acestor tranzacţii. În cel de-a 2-a situaţie, aceste informaţii trebuiesc introduse

manual, iar pentru aceasta trebuie ca în directorul în care se află executabilul aplicaţiei să

Pagina 59 din 133


existe un fişier de configurare cu numele “Wattcp.cfg”. Acesta, scris în mod text, trebuie să

aibă următoarea formă:

print="Packet-driver incărcat…"

my_ip=194.156.176.99

netmask=255.255.254.0

nameserver=194.156.176.1



gateway=194.156.176.1

domainslist="topex.rdsnet.ro"

Ca un sprijin al folosirii stivei Wattcp în aplicaţia de faţă, trebuie spus că ea reprezintă

principalul mijloc al realizării comunicaţiilor în reţelele de tip IP pentru sistemele ce folosesc

DOS-ul ca sistem de operare şi, poate şi datorită distribuirii ei gratuite, este la baza unei

multitudini de aplicaţii utilitare de tip telnet, ssh, client ftp, client POP3, web browsing, etc.,

de asemenea accesibile gratuit.

Aplicaţiile de voce, indiferent pe ce suport de transport, sau sistem de operare în care

rulează sunt aplicaţii de timp real. O implementare secvenţială, cu un singur fir de execuţie

(single thread) nu este suficientă unor situaţii în care timpul reprezintă un factor esenţial în

buna lor funcţionare. De aceea am preferat folosirea unui kernel de timp real, numit (/COS II

(MicroController Operating System, versiunea 2). ( [3], [21] ).

(/COS II, evoluţie a lui (/COS, este un “sistem de operare” cu kernel de timp-real

destinat aplicaţiilor integrate. Cea mai mare parte a lui este scrisă în ANSI-C, iar anumite

componente, dorite cât mai puţine datorită dorinţei de portabilitate, sunt scrise în limbajul de

asamblare dedicat microprocesorului folosit.

(/COS II poate fi portat pe o mare varietate de procesoare, cu condiţia ca ele să

asigure “stack pointer” şi regiştrii CPU, care pot fi introduşi şi scoşi din stivă. De asemenea,

compilatorul C trebuie să permită scrierea de scrierea de porţiuni de cod în limbaj de

asamblare. (/COS II poate rula pe cele mai multe procesoare de 8, 16 32, sau 64 de biţi,

microprocesoare şi DSP-uri.

/COS II este o soluţie foarte scalabilă, această reflectându-se în posibilitatea de a

alege doar acele servicii care sunt necesare aplicaţiei proiectate, lucru care reduce volumul de

memorie RAM/ROM ce urmează a fi folosit. Scalabilitatea este implementată prin

Pagina 60 din 133


intermediul unor variabile configurabile ce includ la compilare doar secţiunile de cod

(serviciile) dorite.

La fel ca majoritatea kernel-urilor de timp-real, /COS II este de tip preemptiv

(programatorul kernel-ului lansează în execuţie mereu task-ul cu prioritatea cea mai mare).

/COS II-ul poate gestiona un număr de 64 task-uri. Dintre acestea, 8 sunt folosite de

sistem, lucru ce face posibilă utilizatorului folosirea a 56. Fiecare task necesită propria sa

stivă de lucru, configurabilă din punctul de vedere al volumului de memorie alocat, pentru

reducerea necesarului de memorie RAM al aplicaţiei.

Câteva din serviciile oferite de /COS II sunt: mailbox-urile, cozi, semafoare, funcţii

de gestiune a timpului, etc. De asemenea, pot fi folosite întreruperi organizate pe 255 de

nivele, care pot suspenda execuţia unui task.

Calităţile de mai sus amintite, adaugate celor omise fac /COS II-ul un foarte bun

sistem de operare de timp-real, care, datorită programării task-urilor cu care el lucrează,

permit dezvoltarea în bune condiţii a aplicaţiilor real-time, “multi-thread”.

Figura 4.3.1.1 prezintă componentele software care vor reprezenta stratificat suportul

de dezvoltare al aplicaţiei.

Pagina 61 din 133


Figura 4.2.1.1 Componentele care ajută la buna dezvoltare şi funcţionare a aplicaţiei.

4.2.2 Funcţionarea software a PC/104

Referinţe bibliografice: [2], [3], [4], [5], [19], [20], [21], [22]

După ce a fost încărcat “packet driver”-ul, modulul hardware PC/104 este pregătit

pentru rularea aplicaţiei. Se lansează în execuţie executabilul rezultat în urma compilării

proiectului “rtp_ucos.prj”. Pentru dezvoltarea şi compilarea acestuia s-a folosit mediul

Borland C++ 3.1, iar codul sursă a fost scris în limbajul C++ cea mai mare parte a sa, anumite

fragmente fiind scrise în limbaj de asamblare 8086.

Fişierul “rtp_ucos.prj” se va încărca la deschiderea mediului de dezvoltare în

directorul ce conţine aplicaţia, iar el conţine fişierele care vor fi compilate, create legăturile,

rezultând fişierul executabil. Proiectul ce va fi compilat conţine următoarele:

Fişiere pentru funcţionarea /COS II-ului. [3].

Ucos_II.c – include la compilare codul sursă pentru asigurarea tuturor serviciilor

oferite de C/OS II(mailbox, semafoare, gestiunea task-urilor şi a timpului, etc.), servicii care

în funcţie de valorile atribuite variabilelor din fişierul de configurare “OS_cfg.h” sunt sau nu

incluse în aplicaţia dorită.

OS_Cpu_C.c – defineşte o funcţie de creare a stivei de lucru a fiecărui task şi funcţii

ce sunt apelate la crearea unui task, la ştergerea lui, la schimbarea de context, sau la fiecare

tick.

Pc.c – defineşte funcţii legate de interfaţa de afişare şi folosirea tastaturii, salvarea

contextului DOS la pornirea C/OS II-ului, restabilirea sistemului de operare la finalul

aplicaţiei C/OS, instalarea de noi vectori de întrerupere şi stabilirea frecvenţei de “tick”.

OS_Cpu_A.asm – scris în întregime în limbaj de asamblare, conţine funcţii privitoare

la punerea în funcţiune a task-ului cu prioritatea cea mai mare în momentul pornirii C/OS-

ului, efectuarea de “task switch”, servirea întreruperii de “tick”.

Wattcphg.lib – este compilat împreună cu celelalte fişiere ale proiectului şi realizează

interfaţa dintre funcţiile de bibliotecă ale stivei WATTCP şi “packet driver”, pentru

asigurarea suportului de comunicaţie în reţeaua IP. Este

Pagina 62 din 133


dependent de modelul folosit în dezvoltarea aplicaţiei, în situaţia de faţă utilizându-se

modelul “huge”.

Fişiere pentru gestiunea şi intercomunicarea cu DSP-urile. [5].

Exe2idma.c – conţine funcţia de încărcare a programului în DSP prin portul de

IDMA.

Interrs.c – instalează noi rutine de întrerupere folosite în aplicaţie, dupe ce în prealabil

au fost salvate cele iniţiale, pentru a putea fi restabilite la ieşirea din aplicaţie.

2181.c – funcţii de interfaţă cu DSP-ul: instalare, scriere prin IDMA, citire prin

IDMA, resetare, rutină de întrerupere.

Mat.c – funcţii de interfaţă cu matricea de comutaţie

DSP.c – conţine funcţii pentru controlul şi transferul prin portul IDMA.

Fişiere pentru dezvoltarea task-urilor de lucru. [3], [4], [22].

Tks_com.c – funcţii de creare a task-urilor, control transmisiei şi recepţiei şi

transmisiei de pachete RTP, etc.

Rtp_ucos.c – are rolul de a integra şi lansa în execuţie toate funcţionalităţile aplicaţiei,

mai sus amintite.

În afară de fişierele mai sus enumerate, în directorul de lucru mai sunt fişiere de tip

header (“*.h”) care conţin declaraţii de funcţii şi variabile, incluse în fişierele cu extensia

“*.C”. Nu trebuie uitate fişierele “wattcp.cfg”, ce conţine informaţiile de configurare pentru

comunicarea în reţeaua IP (adresa IP, DNS server, gateway, etc.) şi fişierul “ts2181.dat” care

conţine programul compilat care va fi încărcat în DSP.

Fişierul Rtp_ucos.c este cel care conţine funcţia “main( )” şi el este cel care apelează

celelalte funcţii şi macrouri pentru dezvoltarea aplicaţiei. El include toate fişierele de tip

header din directorul curent.

Prima lui sarcină este să efectueze etapa de iniţializare, iar pentru aceasta apelează

funcţia “sock_init( )” care are rolul de a iniţializa modulul şi stiva TCP/IP de comunicare,

după care se iniţializează cele 4 DSP-uri, prin intermediul procedurii “init_dsps ( )”. Aceasta

resetează DSP-urile, dezactivează întreruperile şi citeşte 2 din cele 3 flaguri ale fiecăruia.

Ultima iniţializare are în vedere matricea de comutaţie.

A 2-a etapă o constituie încărcarea programelor în DSP-uri. Boot-area DSP-urilor

poate fi făcută în 2 moduri, iar pentru selecţia unuia dintre ele se folosesc 2 pini: BMODE şi

MMAP. Cele 2 moduri de încărcare a programelor sunt: prin portul BDMA, sau prin portul

Pagina 63 din 133


IDMA. Toate cele 4 DSP-uri de pe placă sunt configurate pentru boot-area prin IDMA. În

secvenţa de boot-are, DSP-ul opreşte execuţia până când procesorul gazdă încarcă Program

Memory folosind portul IDMA. Execuţia programului începe în momentul în care, la sfârşitul

încărcării, este scrisă şi locaţia PM 0x0000.

Portul de IDMA (Internal DMA) ( [5] ) este un port paralel de intrare/ieşire, care

permite citirea/scrierea memoriei interne, mai puţin direct regiştrii interni, de către un

procesor gazdă. DSP-ul asigură 5 pini pentru controlul transferului prin IDMA.

Citirea/scrierea din/în memoria internă se face în 2 paşi: întâi se face înscrierea în

IDMA Control Register a adresei din memoria de date/program la/de la care se va realiza

transferul, iar apoi, prin folosirea pinilor de control se comandă scrierea sau citirea la/de la

adresa mai inainte încărcată.

Încărcarea programelor în DSP-uri se face apelând funcţia “dsp_install( )”, definită în

fişierul “2181.c”. Ea efectuează următoarele operaţii: resetează chipul şi dezactivează

întreruperile pentru a salva pointerul către funcţia dată ca argument la apelare. După

eliberarea semnalului reset şi activarea întreruperilor se apelează funcţia “load_prg( )” care

este descrisă în fişierul “exe2idma.c” şi care are ca argumente adresa unui port de ieşire

corespunzator DSP-ului în care se face încărcarea şi numele fişierului ce conţine programul

compilat, cu extensia “.dat”. După înscrierea prin portul de IDMA a anumitor linii din fişierul

respectiv în zona de memorie de program PM a DSP-ului (Program memory), nu toate având

semnificaţie utilă, este înscrisă apoi la adresa PM 0x0000 adresa de la care DSP-ul să înceapă

rularea programului.

Urmează operaţia de instalare a noilor întreruperi, efectuată de

“instalare_intreruperi( )”, care este descrisă în “Interrs.c”. Această funcţie, după ce apelează

alte 3 funcţii ce descriu în limbaj de asamblare rutina de execuţie a noilor întreruperi dorite

(întreruperea de DSP, de 2 ms şi int_arb), salvează vechii vectorii de întrerupere pentru a

putea fi restabiliţi la ieşirea din program şi instalează noile întreruperi pe IRQ 7, IRQ 5 şi

IRQ 15.

Dacă până acum s-au efectuat etapele de iniţializare, încărcare a programelor în DSP-

uri şi instalare a noilor întreruperi, generic spus punerea în funcţiune a cartelei, în cele ce

urmează are loc iniţializarea C/OS –ului.

Pagina 64 din 133


C/OS II-ul este un kernel de timp-real care, deşi lucrează în MS-DOS, pe durata

funcţionării aplicaţiilor sale, salvează contextul acestuia, urmând ca la revenirea din aplicaţie

să fie restabilit.

El se constituie dintr-un programator de procese (task-uri), conform anumitor

priorităţi. Datorită scalabilităţii sale, permite includerea la compilare doar a anumitor servicii,

în funcţie de dorinţă utilizatorului. Aceasta se realizează prin setarea anumitor variabile în

fişierul de configurare “Ucos_cfg.h” [3] (numărul de task-uri dorite, prioritatea minimă,

includerea serviciilor de semafor, mailbox, facilitatea de creare de task-uri, de distrugere sau

suspendare a lor, de schimbare a priorităţilor, etc.).

Ca orice programator de procese, C/OS-ul la rândul lui are un IdleTask, un task pus

în execuţie atunci când nici un altul nu este în starea “ready to run” (“gata de execuţie”). În

cazul faţă, el se numeşte “OSTaskIdle( )” ( [3] ), este setat pe prioritatea minimă

(OS_LOWEST_PRIO) şi nu face altceva decât să incrementeze un contor de 32 de biţi,

OSIdleCtr, care este folosit de un alt task,OSTaskStat( ), la determinarea încărcării

procesorului. OSIdleTask nu poate fi niciodată şters de către o aplicaţie sotfware.

(C/OS II-ul conţine un task ce asigură statistici de-a lungul funcţionării. Numit

“OSTaskStat( )” ( [3] ), el este folosit dacă variabila OS_TASK_STAT_EN este setată pe

valoarea 1, în fişierul OS_Cfg.h. Acest task se execută la fiecare secundă şi determină

încărcarea procesorului, iar prioritatea sa este OS_LOWEST_PRIO-1.

Revenind la aplicaţia noastră, după etapa de iniţializare este apelată funcţia

“OSInit( )”, care are pe lângă rolul de a iniţializa funcţionarea C/OS II-ului, rolul de a crea

cele 2 task-uri mai sus descrise: OSTaskStat( ) şi OSTaskIdle( ).

Următorul pas este acela de salvare a contextului de lucru al sistemului de operare,

MS-DOS, prin apelarea “PC_DOSSaveReturn( )”, pentru a putea fi reinstalat la ieşirea din

aplicaţie, urmat de instalarea unui vector în tabela de întreruperi

a rutinei de tratare a “OSCtxSw” ( contorizează numărul de schimbări de context

petrecute într-o secundă în funcţionarea (C/OS II-ului ).

În acest moment, (C/OS-ul este initializat, cele 2 task-uri create şi contextul DOS

salvat. Pentru punerea lui în funcţiune trebuie creat “TaskStart( )”, un task care va fi primul

rulat de (C/OS, avea prioritatea maximă pe toată perioada de funcţionare a aplicaţiei şi care

va crea celelalte task-uri dorite. Odată cu apelarea funcţiei “OSStart( )”, funcţia “main( )” se

Pagina 65 din 133


încheie, punând în funcţiune kernelul (C/OS-ului, întreaga gestiune a proceselor fiind lăsată

în seama lui.

“TaskStart( )”-ul are ca primă sarcină dezactivarea întreruperilor pentru a instala

rutina de întrerupere pentru “clock tick” şi de a seta valoarea frecvenţei sale de apariţie la

OS_TICK_PER_SEC, valoare modificabilă în fişierul de configurare “Os_cfg.h”. Sunt

activate apoi întreruperile şi apelată OSStatInit( ), funcţia de punere în funcţiune a

TaskStat( ).

Din punctul de vedere al programatorului, un task este o buclă infinită care este pusă

în execuţie în funcţie de politica trasată ( prioritate, perioadă de suspendare, autosuspendare,

etc. ). El poate fi suspendat, se poate autosuspenda, i se poate schimba prioritatea, poate fi

şters, etc. În aplicaţia de faţă, TaskStart( ) are rolul de a crea task-urile de comunicare

(trimitere, recepţie de pachete, etc.), după care, partea sa repetitivă este constituită din

afişarea pe ecran a numărului de task-uri funcţionale, a numărului de schimbări de context ce

au loc în fiecare secundă, a procentului de încărcare a procesorului şi a verificării dacă nu s-a

manifestat dorinţa de oprire a aplicaţiei, ce se poate realiza prin apăsarea tastei “Esc”. După

îndeplinirea acestor sarcini, “TaskStart( )”-ul este suspendat o secundă, de către programator

datorită apelului “OSTimeDlyHMSH(0,0,1,0)”.

În situaţia opririi aplicaţiei, sunt efectuate toate operaţiile de revenire în starea iniţială

a sistemului. Acestea sunt închiderea tuturor socket-ilor deschişi de procesele de trimitere şi

recepţie de pachete IP( “RTPclose( )” ), restabilirea vechilor vectori de întrerupere

( “revenire_intreruperi_initiale( )” ), “dezinstalarea” celor 2 DSP-uri folosite

( “dsp_unistall( )” ) şi restabilirea contextului de lucru al MS-DOS, salvat la începutul

funcţionării C/OS-ului (“PC_DOSReturn( )”).

Înainte de a intra în secţiunea repetitivă, sunt create celelalte task-uri, prin apelul

funcţiei “initiere_comunicare( )”.

Task-urile vor fi create în funcţie de anumite variabile de configurare ce se găsesc în

fişierul “Ts_cfg.h”. De-a lungul dezvoltării aplicaţiei până în stadiul actual, s-au realizat teste

de transmisie şi recepţie de pachete de tip RTP cu 3 maşini pereche: o maşină aflată în

reţeaua IP locală, o alta în reţeaua ISP-ului (RDSnet) (IP: 193.231.233.156), iar cea de-a 3-a

din Internet (IP: 193.41.127.218), toate rulând un sistem de operare Linux. Din această cauză,

în fişierul mai sus amintit sunt definite 3 variabile, pentru fiecare adresă IP cu care se doreşte

comunicare. În funcţie de valorile lor ( 0/1 ), se crează sau nu câte o pereche de task-uri, de

recepţie şi trimitere de pachete RTP. Tot pentru configurarea task-urilor pe care le va

Pagina 66 din 133


gestiona (C/OS-ul, în acelaşi fişier mai poate fi modificată încă o variabilă

(TCP_TICK_ON_OFF), de care va depinde crearea sau nu a task-ului ”Task_tcpTick( )”.

Fişierul de configurare, “Ts_cfg.h”, mai cuprinde prioritatea fiecărui task ce urmează

a fi creat, porturile locale şi ale maşinilor distante. Întrucăt standardul H.323, indiferent ce

versiune ar fi el, nu specifică porturi dedicate transferului RTP/RTCP, de aceea au fost alese

numere de porturi care să nu fie specifice altor tipuri de comunicaţii (“well-known ports”).

Presupunând că în momentul compilării proiectului, cel puţin una din variabilele de

configurare a comunicaţiei au valoarea “1”, iar TCP_TICK_ON_OFF este “1”, funcţia

“initiere_comunicare( )” are următoarele funcţiuni: deschide câte un fişier pentru salvarea

tuturor evenimentelor (primire/recepţie de pachete, etc.) care au loc pe parcursul comunicării

cu fiecare maşină-pereche, după care se apelează funcţia “RTPInit( )” ce are rolul de a afla

adresa IP a maşinii distante folosind DNS-ul, în cazul în care aceasta nu este astfel

identificată de la început, deschiderea “socket”-ilor pe portul local folosit şi, în sfârşit,

salvarea în fişierul specificat ca parametru a rezultatului operaţiei. Este apelată apoi

“sock_recv_init( )”. Funcţie specifică stivei WATTCP, ea iniţiază procesul de recepţie de

pachete IP, pe un socket şi într-un buffer specificate ca parametrii la apelare. După realizarea

cu succes a etapelor anterioare, este în sfârşit creată perechea de task-uri de

transmitere/recepţie de pachete RTP, prin apelul “OSTaskCreate( )”, ce are ca parametrii

numele task-ului creat, stiva proprie fiecăruia şi prioritatea iniţială.

4.2.2.1 Task-ul de transmitere de pachete RTP

Task-ul cu numele generic “Task_send_XXX” realizează complet operaţia de

trimitere de pachete RTP, către maşina pereche (protocol de preluare în buffer-ul de trasmisie

a eşantioanelor de voce din memoria de date a DSP-ului, “împachetarea” loc în structuri de

tip RTP, transmiterea în reţeaua IP).

Pachetele RTP sunt definite în fişierul “Tks_com.h” prin intermediul structurii de mai

jos:

typedef struct {

unsigned char cc:4;

unsigned char extension:1;

unsigned char padding:1;

unsigned char version:2;

Pagina 67 din 133


unsigned char payloadtype:7;

unsigned char marker:1;

unsigned short seqnum;

unsigned long timestamp;

unsigned long ssrc;

unsigned char data[RTP_MAXPACKETSIZE];

} RTPpacket;

Câmpurile structurii sunt identice cu ale pachetelor RTP, conform RFC 1889 [22].

Întrucât fiecărei maşini pereche îi corespunde un task de transmitere de pachete RTP,

înainte de a intra în partea sa repetitivă, sunt iniţializate cu valori aleatoare pe 16, respectiv 32

de biţi 2 variabile locale, folositoare apoi la completarea câmpurilor structurii RTP.

După intrarea în ciclul funcţional, pentru umplerea zonei de date utile a pachetelor

RTP se foloseşte transferul eşantioanlelor de voce prin portul de IDMA din memoria de date

internă a DSP-ului.

Datorită staţionarităţii semnalului vocal, se vor împacheta în structuri RTP secvenţe

de voce de 20 ms. Întrucât sunt preluate de pe flux PCM canale de voce eşantionată cu

frecvenţa de 8 KHz (perioada de eşantionare de 125 s), cele 20 ms dorite sunt reprezentate

160 eşantioane de 8 biţi.

La fiecare început de ciclu al task-ului de transmitere de pachete, prima sarcină este

de a verifica completitudinea transferului anterior prin portul de IDMA. Aceasta se realizează

prin apelul funcţiei “poll(dsp_no)”, descrisă în fişierul “dsp.c”. Ea testează

pentru DSP-ul cu numărul dsp_no de pe placă pinul IACK\, ce indică transfer IDMA

complet. În cazul în care funcţia întoarce valoarea “0”, task-ul apelează

“OSTimeDlyHMSM(0,0,0,5)”, iar programatorul suspendă execuţia sa pentru 5 milisecunde.

La reprogramarea task-ului, acesta revine în starea de test şi, presupunând că procesorul

gazdă poate de această dată avea acces la memoria internă a DSP-ului prin portul de IDMA,

începe etapa de preluare de eşantioane. Prima măsură este aceea de a opri funcţionarea

programatorului de timp-real al task-urilor, pentru a evita o posibilă situaţie în care, în timpul

preluării eşantioanelor din memoria DSP-ului, task-ul de preluare să fie suspendat şi pus în

funcţiune altul mai prioritar, care să intervină în zona de interes şi căreia să-i schimbe

conţinutul. Suspendarea programatorului se realizează prin apelul funcţiei

“OSSchedLock( )”.

Pagina 68 din 133


Mecanismul de preluare a eşantioanelor presupune existenţa a 2 buffere în DM

(memoria internă de date a DSP-ului). Amândouă au câte 160 de locaţii de 16 biţi, nefiind

permise accesele pe 8 biţi în DM. La o locaţie de memorie, tot din DM, pe care procesorul

gazdă o verifică în momentul începerii operaţiei de preluare de eşantioane, DSP-ul

semnalizează buffer-ul în care momentan scrie. Astfel, dacă de la anterioara citire nu s-a

modificat conţinutul locaţiei de semnalizare, nici o operaţie nu este efectuată de către

procesorul gazdă, în caz contrar preluându-se în buffer-ul de recepţie din host cele 160 de

locaţii de 16 biţi din DM. Toate transferurile de date din memoria internă a DSP-ului sunt

realizate folosind portul de IDMA.

Întrucât fiecare din cele 2 DSP-uri instalate în aplicaţia de faţă realizează preluarea a

câte 4 canale temporale de pe flux PCM, adresele din memoria internă ale celor 2 buffer-e şi

a locaţiei din DM folosită pentru semnalizarea unuia dintre ele, folosite la preluarea de către

host a eşantioanelor de voce, sunt indicate în tabelul 4.2.3.1.

Astfel funcţionând protocolul pentru preluarea eşantioanelor, execuţia task-ului de

trimitere de pachete RTP implementează printre altele acest mecanism.

După ce funcţionarea programatorului a fost oprită, este verificată locaţia de memorie

folosită pentru indicarea buffer-ului de preluare, operaţie realizată de “dsp_rdbloc( )”, căreia i

se indică ca argumente “dsp_no” şi adresa locaţiei de semnalizare aferentă canalului dorit.

Dacă de la anterioara ei sondare nu s-au înregistrat

modificări, programatorul este repus în funcţiune, iar task-ul suspendat pentru 5ms,

după care este reluată partea sa repetitivă. În cazul în care între locaţia citită acum şi cea

anterior citită sunt modificări, înseamnă că DSP-ul a completat cele 160 de locaţii ale unui

buffer, iar ele pot fi preluate prin portul de IDMA în buffer-ul de recepţie a lor din “host”,

folosind funcţia “dsp_rdbloc( )”, căreia i se dau ca argumente de acestă dată adresa de început

a buffer-ului din DM ce se doreşte transferat corespunzător canalului de voce transmis,

numărul de citiri prin IDMA (160) şi “dsp_no”.

La sfârşitul transferului prin IDMA al eşantioanlelor de voce din DM, programatorul

C/OS-ului este deblocat şi repus în funcţiune de funcţia “OSSchedUnlock( )”. Pentru

transmiterea lor în reţeaua IP se apelează mai întâi funcţiile “initializare_packet_rtp( )” şi

“RTPpacket_data( )”. Prima dintre ele completează câmpurile headerului pachetului RTP

care va fi transmis, iar cea de-a doua completează câmpul de date al pachetului, după ce

înainte va fi păstrată doar partea mai puţin semnificativă a conţinutului locaţiilor de 16 biţi

Pagina 69 din 133


transferate din memoria DM. Odată completate câmpurile structurii, pentru transmiterea

pachetului se apelează “sock_fastwrite( )”, funcţie specifică stivei WATTCP.

Înainte de a termina partea repetitivă a task-ului, este incrementat modulo 216 un

contor care va completa numărul de secvenţă al pachetului RTP următor ce va fi transmis,

după care task-ul este suspendat pentru 14 ms.

4.2.2.2. Task-ul de recepţie a pachetelor RTP

Pentru fiecare maşină pereche de comunicare se crează în urma apelului funcţiei

“initiere_comunicare( )” câte un task cu numele generic “Task_recv_XXX( )”de recepţie a

pachetelor RTP. El este responsabil cu recepţia pachetelor de tip RTP sosite pe socket-ul

corespunzător, gestionarea lor şi transmiterea blocurilor de câte 160 eşantioane către DSP-ul

corespunzător. În general, recepţia şi redarea blocurilor de eşantioane primite de la maşina

pereche, reprezentând semnalele de voce ale celuilalt interlocutor, sunt mai delicate. Cauza o

constituie reţeaua IP, cu problemele sale de transport prezentate mai pe larg în anterioarele

capitole, reţea care poate întârzia sosirea pachetelor RTP, poate schimba secvenţialitatea

datelor datorită protocolului de transport folosit. De aceea, în maşina de recepţie trebuie luate

măsuri de buffer-are şi reordonare a pachetelor recepţionate.

Fiecare task de recepţie are rolul de a primi din reţea şi de a transmite către DSP

eşantioanele de voce. Apelul se identifică prin zona de memorie din DSP-ul cu care se

lucrează şi numărul portului pe care se va face recepţia.

Recepţia pachetelor se face prin apelul funcţiei specifice stivei WATTCP “sock_recv(

)” , căreia i se dau ca parametrii socket-ul deschis pe portul corespunzător şi buffer-ul de

recepţie. Pentru buna funcţionare a recepţiei de pachete IP pe socket-ul respectiv, înainte de

crearea task-urilor, în corpul funcţiei “initiere_comunicare( )”, a fost apelată, pentru fiecare

maşină pereche de comunicaţie, “sock_recv_init( )”, funcţie ce are rolul de a prelua într-un

buffer de dimensiune 64 KB pachetele recepţionate pe socket-ul deschis pe portul local

dedicat primirii pachetelor, dat ca parametru, până în momentul citirii lor cu ”sock_recv( )”.

Odată funcţia “Task_recv_XXX( )” intrată în ciclul ei repetitiv, la fiecare programare

a task-ului, acesta citeşte într-un ciclu “while” prin intermediul “sock_recv( )”, funcţie care

întoarce numărul de pachete citite din buffer-ul de recepţie, toate pachetele primite de la

anterioara apelare. Ele sunt preluate într-un tablou de structuri de tip “RTPpacket”.

Pagina 70 din 133


Pachetelor RTP, datorită problemelor de transport ale reţelei IP, descrise în capitolul I

al lucrării, pot sosi în altă ordine decât la emiterea lor. De aceea, după ieşirea

din ciclu “while”, odată cu terminarea preluării, acestea sunt transferate într-un buffer

cu 64 locaţii, reprezentate de structuri de genul:

typedef struct{

unsigned short indicator_locatie;

unsigned short seq_num;

char es_voce[160];

} LocatieBuffer;

Acest buffer “LocatieBuffer buffer[64];“ este folosit ca un buffer circular, în fiecare

locaţie memorându-se un indicator de ocupare, numărul de secvenţă al pachetului RTP în

care a fost primit blocul de eşantioane şi datele propriu-zise. El are un “pointer” de citire

(următoarea locaţie de unde va fi trimis la DSP-ul corespunzător un bloc de 160 de

eşantioane ) şi unul de scriere care reprezintă următoarea locaţie liberă în care se poate pune

un bloc, în funcţie şi de numărul de secvenţă al pachetului RTP din care provine, dar mai ales

de ordinea pachetelor primite.

Primul ciclu efectuat de tesk-ul “Task_recv_XXX( )” preia din buffer-ul de recepţie al

“sock_recv( )” pachetele primite, iniţializează buffer-ul circular, completează un număr de

locaţii egal cu numărul de pachete primite şi se autosuspendă pentru 80 ms.

Următoarele 3 parcurgeri ale ciclului au rolul de a prelua la rândul lor din acelaşi

buffer de recepţie pachetele primite şi completate noi locaţii din tabloul de structuri de tip

“LocatieBuffer”, după care task-ul se autosuspendă tot câte 80ms.

Mecanismul de completare a locaţiilor are, pe lângă rolul de a reface secvenţialitatea

pachetelor RTP primite, şi rolul de a permite reintegrarea în fluxul de date a pachetelor

întârziate. Buffer-ul va conţine blocurile de eşantioane, într-o strânsă legătură cu numărul de

secvenţă al pachetelor RTP în care au fost transportate. Astfel pachetele care au sosit înaintea

celor aşteptate, dar nu mai mult decăt o limită stabilită, sunt introduse în buffer. La fel se

întâmplă cu cele întârziate în cazul în care poziţia în care ar trebui introduse în bufferul

circular ar fi ulterioară pointerului de citire.

După cele 4 parcurgeri ale ciclului de lucru, parcurgeri în care nu s-a realizat altceva

decât completarea unor locaţii din buffer-ul circular, are loc procesul de iniţializare. El

Pagina 71 din 133


urmăreşte să detecteze locaţia corespunzătoare numărului minim de secvenţă al unui pachet

RTP primit, care reprezintă începutul unei secvenţe de

“MIN_SEQ” pachete. Se iniţializează pointerul de citire din buffer cu indicele locaţiei

mai sus amintite, se transmite DSP-ului corespunzător blocul de 160 eşantioane, după ce în

prealabil ele au fost incluse ca partea mai putin semnificativă a unor cuvinte de 16 biţi pentru

transferul în DSP’s DM şi task-ul se autosuspendă pentru 18 ms datorită apelului

“OSTimeDlyHMSH(0, 0, 0, 18)”.

La fiecare parcurgere ulterioară a ciclului funcţiei, după ce sunt completate locaţii din

memoria buffer-ului cu pachetele recepţionate, conform mecanismului mai sus prezentat, este

transferat în memoria DM a DSP-ului prin portul de IDMA un bloc de 160 de eşantioane,

folosind apelul funcţiei “dsp_wrbloc( )”, având ca parametrii indicatorul DSP-ului, numărul

de scrieri, 160, adresa din memoria DM.Odată transferul încheiat, este incrementat pointerul

de citire şi task-ul se sutosuspendă 18 ms.

În situaţia în care pointerul de citire “ajunge“ din urmă pointerul de scriere în buffer,

s-a detectat lipsa unui bloc de eşantioane, lipsă datorată pierderii pachetului RTP aferent. Se

trimite în această situaţie DSP-ului informaţia de lipsă eşantioane, urmănd a se reda “linişte”.

Zonele din memoria internă DM a DSPK-ului, atât cele folosite la transferul către

DSP al blocurilor de eşantioane, cât şi indicatorul buffer-ului utilizat, corespunzătoare celor 4

canale de voce procesate de fiecare, sunt prezentate în tabelul 4.2.3.1. În cele mai sus descrise

este folosit un singur buffer dinDM, însă dezvoltarea ulterioară a aplicaţiei va necesita 4, cu

indicator de buffer pentru scriere.

4.2.3 Zone de memorie folosite pentru preluarea pachetelor de eşantioane

Referinţe bibliografice: [5]

Am prezentat în subcapitolul precedent mecanismele funcţionale atât pentru preluarea

de către PC/104 a eşantioanelor de voce din memoria DM internă a DSP-ului, cât şi pentru

“livrarea” celor primite prin intermediul pachetelor de tip RTP din reţeaua IP. Pentru buna

manevrare a lor şi succesul transferului sunt folosite anumite zone din DM, memoria internă

a DSP-ului.

Pagina 72 din 133


Modelul AD2181 dispune de o memorie internă de date de 16Kx16 biţi, folosibili

exclusiv zona superioară de date rezervată regiştrilor de control mapp-aţi în memorie, aflaţi

între 0x3FDF – 0x3FFF. Nu sunt permise însă accesele pe 8 biţi la locaţiile din memoria DM.

Fiecare DSP este folosit în aplicaţia de faţă pentru preluarea şi transmiterea către host

a 4 canale temporale, preluate de pe fluxul PCM de comunicare cu PG-ul, corespunzătoare a

4 apeluri solicitate, fie de intrare, venite via gateway, fie de ieşire, caz în care un abonat şi-a

manifestat opţiunea de transport a vocii folosind reţeaua H.323.

Pentru transmiterea eşantioanlor de la DSP la host se folosesc 2 buffer-e de memorie

de 160 locaţii şi încă o locaţie verificată în permanenţă pentru indicarea celui din care se

poate citi.

Pentru transmiterea către DSP a eşantioanelor despachetate din structurile de date de

tip RTP venite din reţeaua IP, sunt folosite un număr de 4 buffer-e de 160 locaţii în memoria

internă a DSP-ului şi o alta pentru semnalizarea buffer-ului din care se pot citi datele.

Pentru sintetizarea şi detalierea locaţiilor din memoria DSP-ului, s-a întocmit tabelul

4.2.3.1:

Pagina 73 din 133


DSPk Transmiterea eşantioanelor de la

DSPk host

Transmiterea eşantioanelor de la

host DSPk

Buferr Indicator

buffer

Buferr Indicator

buffer

canal 0 0. 0x1000 – 0x109F

1. 0x10A0 – 0x113F

0x3FCF 0x1400 – 0x149F

0x14A0 – 0x153F

0x1540 – 0x15DF

0x15E0 – 0x167F

0x3FCE

canal 1 0. 0x1800 – 0x189F

1. 0x18A0 – 0x193F

0x3FCD 0x1C00 – 0x1C9F

0x1CA0 – 0x1D3F

0x1D40 – 0x1DDF

0x1DE0 – 0x1E7F

0x3FCC

canal 2 0. 0x2000 – 0x209F

1. 0x20A0 – 0x213F

0x3FCB 0x 2400 – 0x249F

0x24A0 – 0x253F

0x2540 – 0x25DF

0x25E0 – 0x267F

0x3FCA

canal 3 0. 0x2800 – 0x289FF

1. 0x28A0 – 0x293F

0x3FC9 0x2C00 – 0x2C9F

0x2CA0 – 0x2D3F

0x2D40 – 0x2DDF

0x2DE0 – 0x2E7F

0x3FC8

Tabelul 4.2.3.1 Zonele de memorie din DM DSP pentru transferul eşantioanelor DSP

host.

Concluzii

La momentul apariţiei sale, VoIP a fost o tehnologie care pe toată lumea a încântat, a

atras atenţia tuturor proiectanţilor şi marilor producători de echipamente de telecom, dar mai

ales furnizorilor de servicii de telecomunicaţii, în general, şi telefonie în special. În condiţiile

în care Internet-ul şi era “e-commerce” sunt într-o nebănuit de vertiginoasă ascensiune, iar

reţelele de pachete de tip IP par că vor reprezenta suportul telecomunicaţiilor de “mâine”,

Pagina 74 din 133


ideea de a transporta una din cele mai vechi şi încetăţenite modalităţi de comunicare între

oameni oferite de operatorii telecom folosind suportul reprezentat de reţelele de pachete a dat

mari speranţe tuturor celor interesaţi.

Tehnologia s-a lovit încă de la început de o ostilitate destul de mare din partea unora,

iar acest lucru s-a datorat în cea mai mare măsură nivelului uriaş de investiţii care au fost

realizate în reţeaua pentru telefonia clasică, bazată pe comutaţia de circuite. Un al doilea

motiv ar fi acela de “refuz” venit din partea utilizatorului obişnuit de telefon clasic, care era

destul de reticent în a se familiariza cu noua tehnologie.

Marii proiectanţi şi producători de echipamente au investit sume considerabile în

dezvoltarea de produse care să aibă la bază noua tehnologie. Ei au demarat proiecte ample,

folosind soluţii proprietare care să ajute la evoluţia rapidă a produselor. În tot acest cadru,

organismele internaţionale pentru standardizare au intervenit pentru aducerea la un numitor

comun a caracteristilor funcţionale.

Însă, odată început lucrul, s-a ajuns la concluzia că problemele de transport prezentate

în capitolul I, datorate suportului de comunicaţie, am numit aici reţeaua de pachete IP

(Intranet, MAN, WAN, Internet), sunt destul de serioase şi împiedică dezvolarea rapidă care

era anunţată.

Au apărut o mulţime de protocoale mulate pe cererile venite din partea transportului

de date de timp real, în general, şi de voce în particular, şi care au rezolvat într-o măsură mai

mare sau mai mică problemele. În ciuda lor, deşi la început se anunţa o mare revoluţie în

transportul serviciilor, s-a ajuns la concluzia că mai este destul de mult de lucru până la

obţinerea unor produse performante.

Una din cele mai mari probleme a fost realizarea intercomunicaţiei cu reţeaua PSTN

deja existentă, pe care, în nici un caz nu o poate înlocui. Pentru asta au fost create porţi de

transfer de la reţeaua H.323 la PSTN sau orice alt tip de reţea transportoare de voce.

“VoIPcard” face parte din entuziastmul reprezentat de VoIP. Ca şi în cazul altor

producători şi s-a confruntat cu rezolvarea problemelor specifice de care am tot vorbit pe

larg. “VoIP card” este un gateway şi reprezintă poarta de ieşire a vocii pentru transportul

peste o reţea de pachete IP. Dezvoltarea unui gateway de voce trebuie să aibă în vedere atât o

mulţime de probleme specifice celor 2 reţele între care realizează comunicaţia, cât şi să

respecte standardele de translaţie a formatelor diferite de date.

Pagina 75 din 133


Procesul de dezvoltare a unui astfel de echipament este destul de îndelungat şi

necesită un anumit grad de experienţă.

Dezvoltarea unui gateway implică implementarea celor 4 module, care rulează atât în

procesorul gazdă, cât şi în DSP-uri. Aplicaţia prezentată în capitolul 4 a fost dezvoltată pe

parcursul unui semestru, iar pentru realizarea unei etape de test este necesară şi dezvoltarea

software-ului pentru rularea în DSP-uri. Timpul necesar s-a dovedit a fi insuficient şi

experienţa avută în proiectare destul de mică. Am încercat să-mi focalizez atenţia spre o

anumită porţiune, care să poată fi continuată ulterior, chiar şi de către altcineva care n-a

participat la proiectarea iniţială.

Rezultatul de până acum a fost prezentat pe larg în capitolele 3 şi 4, însă această a fost

doar temelia pentru dezvoltarea ulterioară. Aplicaţia a fost dezvoltată în urma unei munci de

documentare asupra componentelor folosite şi a tehnologiei VoIP. Materialele folosite pentru

aceasta sunt prezentate în bibliografie.

Cu speranţa aprecierii muncii depuse şi a prezentării generale efectuate, vom prezenta

în cele ce urmează o parte din codul sursă al aplicaţiei descrise în capitolul 4.

Pagina 76 din 133


ANEXE

A

N

E

X

A

A

.

D

i

c

ţ

i

o

n

a

r

d

e

a

c

r

o

n

i

m

e

A

AAA Authentication Authorization and Accounting

AAL2 ATM Adaptation Layer type 2

Pagina 77 din 133


ADPCM Adaptive PCM

ADSL Asymmetric Digital Subscriber Line

AI Artificial Intelligence

ANSI American National Standards Institution

API Application Programming Interface

ARP Address Resolution Protocol

ARQ Automatic Request for retransmission

AS Application Server

ATM Asynchronous Transfer Mode

AUI Attachment Unit Interface

B

BER Bit Error Rate

B-ISDN Broadband ISDN

BNC British Naval Connector

BRI Basic Rate Interface (2B+D)

BSC Base Station Controller

BSS Base Station Subsistem

BTS Base Transceiver Subsystem

C

CBR Constant Bit Rate

CEPT Conference Europeene des Administrations des Postes et des

Telecomunications

CERT Computer Emergency Response Team

CES Circuit Emulation Services

CHAP Challenge Handshake Authentication Protocol

CLI Command Line Interface

CLP Connectionless Protocol

CODEC Coder & Decoder

COP Connection-oriented Protocol

CPU Central Processing Unit

CRC Cyclic Redundancy Code

CSPDN Circuit Switched Public Data Network

CSU Channel Service Unit

Pagina 78 din 133


CTI Computer Telephony Intergation

D

DCE Data Communications Equipment

DES Digital Encryption Standard

DiffServ Differrentiated Services

DLC Data Layer Control

DNS Domain Name Server

DSU Data Service Unit

DTE Data Terminal Equipment

DTMF Dual Tone Multifrequency

DVB-T Digital Video Broadcasting

E

EN Enterprise Network

ETSI European Telecommunications Standards Institute

F

FAXoIP Fax over IP

FCS Frame Check Sequence

FDDI Fiber Distributed Data Interface

FDT Formal Description Technique

FIFO First In First Out

G

GSM Global System for Mobile

GSTN General Switched Telephone Network

GUI Graphical User Interface

H

HDLC High-level Data Link Control

HDSL High bit-rate Digital Subscriber Line

HTTP Hypertext Transfer Protocol (RFC2068)

I

Pagina 79 din 133


IANA Internet Assigned Numbers Authority

ICMP Internet Control Message Protocol

IEEE Institute of Electrical and Electronics Engineering

IETF Internet Engineering Task Force

IGMP Internet Group Message Protocol

IN Intelligent Network

IOS Internetwork Operating System

IP Internet Protocol

IPX Internetwork Packet Exchange

ISDN Integrated Services Digital Network

ISO International Standard Organization

ISP Internet Service Provider

ITU International Telecommunication Union

IWF InterWorking Function

K

KBPS KiloBytes Per Second

L

LAN Local Area Network

LANE LAN Emulation

LCP Link Control Protocol (a component from PPP)

LIFO Last In-First Out

LLC Logical Link Connection

LMI Local Management Interface

LSB Less Significant Bit

M

MAC 1. Medium Access Control 2. Message Authentication Code

MAN Metropolitan Area Network

MCU Multipoint Control Unit

MGCP Media Gateway Control Protocol

MHz MegaHertzs

MIB Management Information Base

Pagina 80 din 133


MPLS Multi-Protocol Label Switching

MS Mobile Station

MSB Most Significant Bit

MSC 1. Message Sequence Chart; 2. Mobil Switching Center;

MTU Maximum Transmission Unit

N

NEBS Network Equipment Building Standards

NIST National Institute of Standards and Technology

O

OAM Operations, Administration and Maintenance

OMS Operation and Maintenance Subsystem

OSI Open Systems Interconnection

OUI Organizationally Unique Identifier

O&M Operations And Maintenance

P

PABX Private Automatic Branch eXchange

PC Personal Computer

PCM Pulse Code Modulation

PCTA Procesor Central de Tratare Apeluri

PDC Personal Digital Communication

PDCP Packet Data Convergence Protocol

PDH Plesiochronous Digital Hierarchy

PDN Packet Data Network

PDU Protocol Data Unit

PG Procesor de Grup

PID Process IDentifier

PLMN Public Land Mobile Network

POTS Plain Old Telephone Service

PRI Primary Rate Interface

PSPDN Packet Switched Public Data Network

PSTN Public Switched Telephone Network

PVC Permanent Virtual Circuit

Pagina 81 din 133


Q

QoS Quality of Service

R

RAND RANDom number

RAS 1. Registration, Admisions, and Status; 2. Remote Access Server;

RSVP Resource Reservation Protocol

RTCP Real Time Control Protocol

RTP Real Time Protocol

RTSP Real Time Stream Protocol

RTT Round Trip Time

S

SAP 1. Session Announciament Protocol; 2. Services Access Point

SAR Segmentation & Reassembling

SCCP Signaling Connection Control Part (ITU-T Q.711-714)

SCN Switched Circuit Network

SCTP Stream Control Transmission Protocol

SDH Synchronous Digital Hierarchy

SDLC Synchronous Data Link Control

SGMP Simple Gateway Control Protocol

SID Security ID

SIM Subscriber Identity Module

SIP Session Initiation Protocol

SLIP Serial Line Internet Protocol

SMTP Simple Mail Transfer Protocol

SNA Serial Number Arithmetic (RFC 1982)

SNMP Simple Network Management Protocol

SOHO Small Office Home Office

SONET Synchronous Optical Network

SPID Service Profile IDentifier

SS7 Signaling System Number 7

SSH Secure SHell

SSL Secure Socket Layer

Pagina 82 din 133


SSP Service Switching Point

STP Signaling Transfer Point

SVC Switched Virtual Circuit

T

TCAP Transactional Capabilities Application Part

TCP Transmission Control Protocol

TDMA Time Division Multiple Access

TE Terminal Equipment

TMN Telecommunications Management Network

TOS Type Of Service

TTL Time To Live

TUP Telephone User Part

U

UA Unitate Abonaţi

UBR Unspecified Bit Rate

UDP User Datagram Protocol

UMTS Universal Mobile Telecommunication System

UNI User-Network Interface

URL Universal Resource Locator

UTD Unitate de Trunchi Digital

V

VCC Virtual Channel Connection

VLAN Virtual LAN

VoD Video on Demand

VoFR Voice over Frame Relay

VoIP Voice over IP

VON Voice On the Network

VPC Virtual Path Connection

VPN Virtual Private Network

VToA Voice Telephony over ATM

W

Pagina 83 din 133


WAN Wide Area Network

WATM Wireless ATM

WLAN Wireless LAN

WLL Wireless Local Loop

ANEXA B. Software-ul aplicaţiei

ANEXA B1. Fişiere header (.h)

Includes.h

/************************** MASTER INCLUDE FILE

**************************/

#include <stdio.h>

#include <string.h>

#include <ctype.h>

#include <stdlib.h>

#include <conio.h>

#include <dos.h>

#include <setjmp.h>

#include <tcp.h>

#include "Ts_Cfg.H"

#include "os_cpu.h"

#include "os_cfg.h"

#include "pc.h"

#include "ucos_ii.h"

OS_cfg.h

/****************************** uC/OS-II The Real-Time Kernel

***************

uC/OS-II CONFIGURATION

*********************************************************************

*******/

Pagina 84 din 133


#define OS_MAX_EVENTS 5 //Max. number of event control blocks in your

//application.MUST be >= 2

#define OS_MAX_MEM_PART 5 //Max. number of memory partitions. MUST be

>= 2

#define OS_MAX_QS 3 // Max. number of queue control blocks in your

//application.MUST be >= 2

#define OS_MAX_TASKS 15 // Max. number of tasks in your application ... //MUST

be >= 2

#define OS_LOWEST_PRIO 15 // Defines the lowest priority that can be

//assigned.MUST NEVER be higher than 63!

#define OS_TASK_IDLE_STK_SIZE 512 // Idle task stack size (# of 16-bit //wide

entries)

#define OS_TASK_STAT_EN 1 // Enable (1) or Disable(0) the //statistics task

#define OS_TASK_STAT_STK_SIZE 512 // Statistics task stack size (# of 16-//bit

wide entries)

#define OS_CPU_HOOKS_EN 1 // uC/OS-II hooks are found in the processor port

files

#define OS_MBOX_EN 0 // Include code for MAILBOXES

#define OS_MEM_EN 1 // Include code for MEMORY MANAGER (fixed //sized

memory blocks)

#define OS_Q_EN 0 // Include code for QUEUES

#define OS_SEM_EN 1 // Include code for SEMAPHORES

#define OS_TASK_CHANGE_PRIO_EN 0 // Include code for OSTaskChangePrio()

#define OS_TASK_CREATE_EN 1 // Include code for OSTaskCreate()

#define OS_TASK_CREATE_EXT_EN 0 // Include code for OSTaskCreateExt()

#define OS_TASK_DEL_EN 1 // Include code for OSTaskDel()

#define OS_TASK_SUSPEND_EN 1 // Include code for OSTaskSuspend() and

//OSTaskResume()

Pagina 85 din 133


#define OS_TICKS_PER_SEC 100 // Set the number of ticks in one second

RTP_Ucos.h

#include <stdio.h>

#include <tcp.h>

//Initiere conexiune RTP

int RTPinit( char *localip, char *remoteip, word RTP_PORT_DIST, word\

RTP_PORT_LOCAL, udp_Socket *socket, char buff_adresa[], FILE *fisier );

Stacks.h

#include "os_cpu.h"

extern OS_STK TaskStk_tcpTick[2048];

extern OS_STK TaskStk_send_FServ[TASK_STK_SIZE];

extern OS_STK TaskStk_recv_FServ[TASK_STK_SIZE];

extern OS_STK TaskStk_send_INC[TASK_STK_SIZE];

extern OS_STK TaskStk_recv_INC[TASK_STK_SIZE];

extern OS_STK TaskStk_send_ONIX[TASK_STK_SIZE];

extern OS_STK TaskStk_recv_ONIX[TASK_STK_SIZE];

extern OS_STK TaskStartStk[TASK_STK_SIZE]; // TaskStart stack

Targtype.h

#ifndef __TARGET_TYPES_H__

#define __TARGET_TYPES_H__

#define u_char unsigned char

#define int16 int

#define u_int16 unsigned int

#define int32 long

#define u_int32 unsigned long

Pagina 86 din 133


#endif

Ts_cfg.h

//variabile de configurare a task-urilor...

#define COMUNIC_INCREMENTAL 1

#define COMUNIC_ONIX 1

#define COMUNIC_FServ 1

#define TCP_TICK_ON_OFF 1

//prioritati task-uri

#define TASK_TICK_PRIO 7

#define TASK_RECV_INC_PRIO 1

#define TASK_RECV_ONIX_PRIO 2

#define TASK_RECV_FServ_PRIO 3

#define TASK_SEND_ONIX_PRIO 4

#define TASK_SEND_INC_PRIO 5

#define TASK_SEND_FServ_PRIO 6

//adrese IP masini distante

#define LOCALIP "192.168.1.99"

#define REMOTEIP_FServ "192.168.1.201" //server "FileServer"

#define REMOTEIP_INC "193.231.233.156" //server "incremental.ro"

#define REMOTEIP_ONIX "193.41.127.218" // server Onix la Valcea...

//porturi masini distante

#define RTP_LOCALPORT_INC 8901

#define RTP_LOCALPORT_ONIX 8902

#define RTP_LOCALPORT_FServ 8903

#define RTP_PORT_INC 8801

#define RTP_PORT_ONIX 8802

#define RTP_PORT_FServ 8803

Pagina 87 din 133


#define TASK_STK_SIZE 1024 // Size of each task's stacks (# of WORDs)

#define RTP_MAXPACKETSIZE 256

#define ERR_CONECTARE -1

#define ERR_DESCH_FISIER -2

#define ERR_NO_TASKS -10

#define INIT_OK 99

2181.h

#include "dsptargt.h"

typedef void (*ISR_FP)(u_int16 w);

typedef void* (*FPTR)(int ndx, u_int16 event);

int dsp_install(int ndx,char *fname,ISR_FP fp);

void dsp_uninstall(int ndx);

void dsp_reset(int ndx);

int dsp_swdchk(int ndx);

int dsp_rdbloc(int ndx,u_int16 *bb,int cnt,u_int16 adr);

int dsp_wrbloc(int ndx,u_int16 *bb,int cnt,u_int16 adr);

void dsp_isr(void);

void init_dsps(void);

DSP.h

#include <stdio.h>

#include <conio.h>

#include "2181.h"

#include "mat.h"

#define MAXDSP 4

typedef void* (*FPTR)(int ndx,u_int16 event);

Pagina 88 din 133


void trt_dsp0(u_int16 w);

void trt_dsp1(u_int16 w);

int poll(int ndx);

int blk2bmcmd(int ndx,u_int16 bmadr,u_int16 page,u_int16 mode,u_int16 len);

DSPtargt.h

#include <dos.h>

#include "targtype.h"

#define IDMA_ADDR(port,val) outport(port,val)

#define IDMA_WR(port,val) outport(port+2,val)

#define IDMA_RD(port) inport(port+2)

#define set5c0(w) outportb(0x5c0,w)

#define read5c0() (inportb(0x5c0))

Interrs.h

#include <conio.h>

#include <stdio.h>

#include "mat.h"

#include "2181.h"

#define ERR_INT_2MS -1

#define ERR_INT_ARG -2

#define ERR_INT_DSP -3

void instalare_intreruperi(void);

void revenire_intreruperi_initiale(void);

void interrupt int2ms(void);

void interrupt int_arb(void);

Pagina 89 din 133


void interrupt irqdsp(void);

Tks_com.h

#include <stdio.h>

#include <tcp.h>

#include "ts_cfg.h"

#define DSP_0 0

#define DSP_1 1

#define DSP_2 2

#define DSP_3 3

extern FILE *fisier_inc,*fisier_onix, *fisier_FServ;

//packet RTP

typedef struct {

unsigned char cc:4; // CSRC count

unsigned char extension:1; // header extension flag

unsigned char padding:1; // padding flag

unsigned char version:2; // protocol version, de obicei 2

unsigned char payloadtype:7; // payload type

unsigned char marker:1; // marker bit

unsigned short seqnum; // sequence number

unsigned long timestamp; // timestamp

unsigned long ssrc; // synchronization source

unsigned char data[RTP_MAXPACKETSIZE]; // date efective.

} RTPpacket;

typedef struct{

unsigned short indicator_locatie;

unsigned short seq_num;

char es_voce[160];

Pagina 90 din 133


}LocatieBuffer;

int initiere_comunicare(void);

void RTPclose();

void initializare_packet_rtp( RTPpacket *pck, unsigned int seq_num, unsigned long

timestamp );

void RTPpacket_data( RTPpacket* pck, unsigned int payload[160]);

void ordonare_packete_receptionate(RTPpacket* pck_receptionate[], int nr_pckt);

void Task_tcpTick(void *data); // Function prototypes of tasks

void Task_recv_INC(void *data);//Task de receptie a packetelor incremental.ro

void Task_send_INC(void *data); //Task de trimitere de packete incremental.ro

void Task_recv_ONIX(void *data); //Task de receptie a packetelor Onix

void Task_send_ONIX(void *data); //Task de trimitere de packete Onix

void Task_recv_FServ(void *data); //Task de receptie a packetelor FileServer

void Task_send_FServ(void *data); //Task de trimitere de packete FileServer

Pagina 91 din 133


ANEXA B2. Fişiere sursă (.C)

Rtp_UCOS.C

/******************************** uC/OS-II

********************************/

#include "includes.h"

#include "Tks_com.h"

#include "Rtp.h"

#include "Interrs.h"

#include "Dsp.h"

#include "Stacks.h"

#include "Dsptargt.h"

/******************************* VARIABILE

********************************/

OS_EVENT *RandomSem;

struct time ora_curenta;

int dspno=0, dspno1=1;

//adrese masini de comunicare

longword masina_dist, masina_locala;

/*************************** FUNCTION PROTOTYPES

***************************/

void TaskStart(void *data); // Startup task

void RTPclose(void); // Inchidere socketi

/****************************** MAIN

***************************************/

int main (void)

{

int prg_len, i, j, err;

char timp_curent[25];

u_int32 cntciclu, cnterr;

Pagina 92 din 133


static FPTR fp[MAXDSP];

//initializare stiva comunicatie...

sock_init();

//initializare DSP-uri...

init_dsps();

//validare bufferi simetrici

asm{

mov dx, 0x5e0;

mov al, 0x5f;

out dx, al;

}

//incarcarea programelor in DSP-uri...

prg_len=dsp_install( dspno, "ts81.dat", trt_dsp0 ); //incarcare program DSP 0...

printf( "prg_len[%d]=%04X\n", dspno, prg_len );

prg_len=dsp_install( dspno1, "ts81.dat", trt_dsp1 ); //incarcare program DSP1...

printf( "prg_len[%d]=%04X\n", dspno1, prg_len );

//salvarea, modificarea, setarea noilor vectori de intrerupere pe IRQ 5,7,15

instalare_intreruperi();

PC_DispClrScr(DISP_FGND_WHITE + DISP_BGND_BLACK); // Clear the screen

OSInit(); // Initialize uC/OS-II

PC_DOSSaveReturn(); // Save environment to return to DOS

PC_VectSet(uCOS, OSCtxSw); // Install uC/OS-II's context switch vector

RandomSem = OSSemCreate(1); // Random number semaphore

OSTaskCreate(TaskStart, (void *)0, (void *)&TaskStartStk[TASK_STK_SIZE - 1],

0);

OSStart(); // Start multitasking

Pagina 93 din 133


return 0;

}

/*************************** STARTUP TASK

**********************************/

void TaskStart (void *data)

{

UBYTE i, err;

WORD key;

char s[100];

data = data; // Prevent compiler warning

OS_ENTER_CRITICAL();

PC_VectSet(0x08, OSTickISR); // Install uC/OS-II's clock tick ISR

PC_SetTickRate(OS_TICKS_PER_SEC); // Reprogram tick rate

OS_EXIT_CRITICAL();

OSStatInit(); // Initialize uC/OS-II's statistics

PC_DispStr(26, 0, "uC/OS-II, The Real-Time Kernel", DISP_FGND_WHITE +

DISP_BGND_RED + DISP_BLINK);

initiere_comunicare();

PC_DispStr( 0, 23, "#Tasks : xxxxx CPU Usage: xxx #Task switch/sec: xxxxx ",

DISP_FGND_WHITE);

PC_DispStr(28, 24, "<-PRESS 'ESC' TO QUIT->", DISP_FGND_WHITE +

DISP_BLINK);

for (;;) {

sprintf(s, "%5d", OSTaskCtr); // Display #tasks running

PC_DispStr(17, 23, s, DISP_FGND_BLUE + DISP_BGND_CYAN);

sprintf(s, "%3d", OSCPUUsage); // Display CPU usage in %

Pagina 94 din 133



sprintf(s, "%5d", OSCtxSwCtr); // Display #context switches per second


OSCtxSwCtr = 0;

PC_GetDateTime(timp_curent); // Get and display date and time

PC_DispStr(0, 24, timp_curent, DISP_FGND_BLUE + DISP_BGND_CYAN);

fprintf( fisier_inc, "TaskStart \n");

fprintf( fisier_FServ, "TaskStart \n");

fprintf( fisier_onix, "TaskStart \n");

if (PC_GetKey(&key) == TRUE)

{ // See if key has been pressed

if (key == 0x1B)

{ // Yes, see if it's the ESCAPE key PC_DispStr(35, 15, "Ma opresc...",

DISP_FGND_BLUE + DISP_BGND_CYAN);

RTPclose();//inchiderea socketilor...

revenire_intreruperi_initiale();

//dezinstalarea celor 2 DSP-uri...

dsp_uninstall(dspno);

dsp_uninstall(dspno1);

OSTimeDlyHMSM( 0, 0, 0, 250 );

PC_DOSReturn(); // Return to DOS }

}

OSTimeDlyHMSM(0, 0, 1, 0); // Wait one second

}

}

Pagina 95 din 133


/******************************** TASKS

************************************/

//Afiseaza in coltul din stanga-jos a ecranului ceasul curent...

void AfisareCeas_Task( void *data )

{

UBYTE err;

static char timp_curent[25];

data=data;

for(;;)

{

PC_GetDateTime(timp_curent); // Get and display date and time

PC_DispStr(0, 24, timp_curent, DISP_FGND_BLUE + DISP_BGND_CYAN);

OSTimeDly( OS_TICKS_PER_SEC);

}

}

// Deschidere si conectare socketi pentru RTP ...

int RTPinit(char *localip, char *remoteip, word RTP_PORT_DIST, word

RTP_PORT_LOCAL, udp_Socket *socket, char buff_adresa[25], FILE *fisier )

{

localip=localip;

//Aflare adresa IP masina distanta...DNS querry

if( !(masina_dist=resolve( remoteip ) ) )

{

printf("Nu s-a putut afla adresa IP a '%s'...\n", remoteip);

return 1;

}

printf("Adresa masinii distante este %s...\n", inet_ntoa( buff_adresa, masina_dist ) );

if( !udp_open( socket, RTP_PORT_LOCAL, masina_dist, RTP_PORT_DIST, NULL

) ) return ERR_CONECTARE;

fprintf( fisier, "Deschidere socket %d\n", udp_open( socket, RTP_LOCALPORT,

masina_dist, RTP_REMOTEPORT, NULL ) );

Pagina 96 din 133


fprintf( fisier, "Masinile s-au conectat cu succes...\n" );

return 0;

}

Pagina 97 din 133


2181.C

#include <stdio.h>

#include <conio.h>

#include "2181.h"

#include "mat.h"

#include "dsp.h"

FPTR fp[MAXDSP];

u_int16 far bb1[0x400],bb2[0x400];

u_int16 far bb1_[MAXDSP][0x400],bb2_[MAXDSP][0x400];

u_int16 bstart[MAXDSP],page[MAXDSP];

u_int16 flag[MAXDSP];

void trt_dsp0(u_int16 w)

{

flag[0]=1;

flag[2]=1;

#pragma argsused

} //trt_dsp0

void trt_dsp1(u_int16 w)

{

flag[1]=1;

flag[3]=1;

#pragma argsused

} //trt_dsp0

int poll(int ndx) //verifica existenta transferului prin IDMA...

{

u_int16 tmp;

tmp=0;

dsp_rdbloc(ndx,&tmp,1,0x7400);

return tmp;

} //poll

Pagina 98 din 133


int blk2bmcmd(int ndx,u_int16 bmadr,u_int16 page,u_int16 mode,u_int16 len)

{

u_int16 cc[4];

if(poll(ndx)) return 0;

if(len>0x400) return 0;

cc[0]=1;

cc[1]=bmadr&0x3fff;

cc[2]=(page<<8)|(mode&0x07);

cc[3]=len;

dsp_wrbloc(ndx,cc,4,0x7400);

return 1;

} //blk2bmcmd

Exe2IDMA.C

#include <stdio.h>

#include "dsptargt.h"

static u_int16 addr,w1,w2,_w1,_w2;

static char line[90];

int load_prg(u_int16 port,char *fname)

{

FILE *prg_file;

int state;

u_int16 prg_len,crt_addr;

state=0;

_w1=0x1800;

_w2=0x000F;

prg_file=fopen(fname,"r");

if(!prg_file)

Pagina 99 din 133


{

IDMA_ADDR(port,0);

IDMA_WR(port,_w1);

IDMA_WR(port,_w2);

return 0;

} //endif

prg_len=0;

crt_addr=0;

while(fgets(line,80,prg_file))

{

switch(state){

case 0:

trt_state0:

if(line[0]!='@')

{

//unrecognized line

fputs(line,stderr);

break;

} //endif

if(line[1]=='P')

{

state=1;

break;

} //endif

if(line[1]=='D')

{

state=2;

break;

} //endif

break;

case 1:

if(!sscanf(line,"%04X",&addr))

Pagina 100 din 133


{

state=0;

break;

} //endif

addr&=0x3fff;

if(!addr)

{

state=5;

break;

} //endif

IDMA_ADDR(port,addr);

crt_addr=addr;

state=3;

break;

case 2:

if(!sscanf(line,"%04X",&addr))

{

state=0;

break;

} //endif

addr&=0x3fff;

addr|=0x4000;

IDMA_ADDR(port,addr);

crt_addr=0;

state=4;

break;

case 3:

if(!sscanf(line,"%04X%02X",&w1,&w2)) goto trt_state0;

IDMA_WR(port,w1);

IDMA_WR(port,w2);

crt_addr++;

break;

case 4:

if(!sscanf(line,"%04X",&w1)) goto trt_state0;

Pagina 101 din 133


IDMA_WR(port,w1);

break;

case 5:

if(!sscanf(line,"%04X%02X",&_w1,&_w2)) goto trt_state0;

IDMA_ADDR(port,1);

state=3;

break;

default:

state=0;

break;

} //endswitch

if(crt_addr>prg_len) prg_len=crt_addr;

line[0]=0;

} //endwhile

fclose(prg_file);

IDMA_ADDR(port,0);

IDMA_WR(port,_w1);

IDMA_WR(port,_w2);

return prg_len;

} //load_prg

Interrs.C

//acest fisier continele rutinele de tratare a intreruperilor

#include <stdio.h>

#include <conio.h>

#include "mat.h"

#include "2181.h"

Pagina 102 din 133


#define INT2ms

#define INT_arg

#define INT_dsp

u_int16 flag2ms, flag_arb;

u_int16 xmsg[8],rmsg[8];

void interrupt (*oldvect0d)();

void interrupt (*oldvect0f)();

void interrupt (*oldvect77)();

void instalare_intreruperi();

void revenire_intreruperi_initiale();

void interrupt int2ms() //IRQ5

{

int i;

asm{

mov dx,0x5F8;

mov al,0;

out dx,al;

}

flag2ms=1;

for(i=0;i<8;i++)

{

MATWR(CML,i<<5,xmsg[i]);

rmsg[i]=MATRD(DMEM,i<<5);

} //endfor i

//EOI

asm{

Pagina 103 din 133


mov al,0x20;

//out 0xA0,al; //necesar pt IRQ8..IRQ15

out 0x20,al;

}

} //int2ms

void interrupt int_arb() //IRQ15

{

int i;

asm{

mov dx,0x5F8;

mov al,0;

out dx,al;

}

flag_arb=1;

//EOI

asm{

mov al,0x20;

out 0xA0,al; //necesar pt IRQ8..IRQ15

out 0x20,al;

}

} //int_arb

void interrupt irqdsp() //IRQ7

{

dsp_isr();

//EOI

asm{

mov al,0x20;

Pagina 104 din 133


//out 0xA0,al; //necesar pt IRQ8..IRQ15

out 0x20,al;

}

} //irqdsp

void instalare_intreruperi()

{

#ifdef INT2ms

oldvect0d=getvect(0x0d);

setvect(0x0d, int2ms); //instaleaza intreruperea de 2ms pe INT5

asm{

cli;

}

outport( 0x21, inport( 0x21 ) & 0xDF ); //porneste interuperea

asm{

sti;

}

#endif

#ifdef INT_arg

oldvect0f=getvect(0x0f);

setvect( 0x0f, irqdsp); //instaleaza intreruperea de DSP pe INT7

asm{

cli;

}

outport( 0x21, inport(0x21)&0x7F ); //porneste interuperea

asm{

sti;

}

#endif

#ifdef INT_dsp

oldvect77=getvect(0x77);

setvect( 0x77, int_arb ); //instaleaza intreruperea int_arb pe INT15

Pagina 105 din 133


asm{

cli;

}

outport( 0xA1, inport(0xA1) & 0x7F ); //porneste interuperea

asm{

sti;

}

#endif

} //instalare_intreruperi

void revenire_intreruperi_initiale()

{

#ifdef INT2ms

outport( 0xA1, inport(0xA1)|0x80 );

setvect( 0x77, oldvect77 );

#endif

#ifdef INT_arg

outport( 0x21, inport(0x21)|0x80 );

setvect( 0x0F, oldvect0f );

#endif

#ifdef INT_dsp

outport( 0x21, inport(0x21)|0x20 );

setvect( 0x0D, oldvect0d );

#endif

}

Ucos_II.C

#define OS_GLOBALS

#include "includes.h"

Pagina 106 din 133


#define OS_MASTER_FILE //Prevent the following files frm including includes.h

#include "os_core.c"

#include "os_mbox.c"

#include "os_mem.c"

#include "os_q.c"

#include "os_sem.c"

#include "os_task.c"

#include "os_time.c"

Tks_com.C

#include <stdio.h>

#include <string.h>

#include <stdlib.h>

#include <conio.h>

#include <dos.h>

#include <time.h>

#include <tcp.h>

#include "Tks_com.h"

#include "Ts_cfg.h"

#include "os_cpu.h"

#include "os_cfg.h"

#include "ucos_ii.h"

#include "pc.h"

#include "RTP_Ucos.h"

#include "Stacks.h"

#include "Dsp.h"

#include "Rtp.h"

FILE *fisier_inc, *fisier_onix, *fisier_FServ;

char timp_curent[25];

Pagina 107 din 133


udp_Socket RTPsocket_inc, RTPsocket_onix, RTPsocket_FServ;

char buf_adresa_inc[48], buf_adresa_onix[48], buf_adresa_FServ[48];

int rtp_ret_inc, rtp_ret_onix, rtp_ret_FServ;

//buffere de preluare esantioane din DSP de unde se vor impacheta...

unsigned int buffer_dspread[MAXDSP][160];

unsigned int buffer[4][4]={\

0x5400, 0x54A0, 0x5540, 0x55E0,\

0x5C00, 0x5CA0, 0x5D40, 0x5DE0,\

0x6400, 0x64A0, 0x6540, 0x65E0,\

0x6C00, 0x6C2F, 0x6D40, 0x6DE0,\

}; //adresele celor 4 buffere coresp. fiecarui canal...

//buffere de receptie a packetelor

unsigned char far buf_inc[0xFFFF];

unsigned char far buf_onix[0xFFFF];

unsigned char far buf_FServ[0xFFFF];

//surse de pachete RTP...

source Incr_source, Onix_source, FServ_source;

//stacks

OS_STK TaskStk_tcpTick[2048];

OS_STK TaskStk_send_FServ[TASK_STK_SIZE];

OS_STK TaskStk_recv_FServ[TASK_STK_SIZE];

OS_STK TaskStk_send_INC[TASK_STK_SIZE];

OS_STK TaskStk_recv_INC[TASK_STK_SIZE];

OS_STK TaskStk_send_ONIX[TASK_STK_SIZE];

OS_STK TaskStk_recv_ONIX[TASK_STK_SIZE];

OS_STK TaskStartStk[TASK_STK_SIZE]; // TaskStart stack

Pagina 108 din 133


void initializare_packet_rtp( RTPpacket* pck, unsigned int seq_num, unsigned

long timestamp )

{

pck->cc=0;

pck->extension=0;

pck->padding=0;

pck->version=2;

pck->payloadtype=8; //PCM legea A, 8KHz...

pck->marker=0;

pck->seqnum=htons( seq_num );

pck->timestamp=htonl( timestamp );

pck->ssrc=htonl( 0 );

}

//functie ce umple zona utila de date a pachetului RTP...

void RTPpacket_data( RTPpacket* pck, unsigned int payload[160])

{

static int i;

for(i=0;i<160;i++)

{

pck->data[i]=(char)(0x00FF & payload[i]);

}

}

unsigned int ordonare_packete_recept(RTPpacket* pck_recep[],int nr_pckt)

{

int poz, cnt;

unsigned int minim;

RTPpacket* pck_temp;

poz=0;

while(poz<nr_pckt)

Pagina 109 din 133


{

minim=pck_recep[poz]->seqnum;

for(cnt=poz;cnt<nr_pckt;cnt++){

if(minim>pck_recep[cnt]->seqnum)

{

minim=pck_recep[cnt]->seqnum;

pck_temp=pck_recep[poz];

pck_recep[poz]=pck_recep[cnt];

pck_recep[cnt]=pck_temp;

}

}

poz++;

}

return minim;

}

void completare_locatieBuffer(RTPpacket* pck, LocatieBuffer* locatie)

{

int k;

locatie->indicator_locatie=1; //locatie ocupata...

locatie->seq_num=pck->seqnum;

for(k=0;k<160;k++) locatie->es_voce[k]=pck->data[k];

}

int initializare_sursa(source *s, RTPpacket* pck[], unsigned int cnt)

{

static int i=1;

while(s->probation)

{

if(cnt-i>0)

if(pck[i]->seqnum==s->max_seq+1)

{

s->probation--;

s->max_seq=pck[i]->seqnum;

Pagina 110 din 133


i+=1;

}

printf("Sursa nu poate fi initializata !\n");

OSTimeDly(10);

return NO_INIT;

}

init_seq(s, pck[i]->seqnum);

return SEQ_INIT_OK;

}

void Task_send_INC (void *data)

{

//preia, impacheteaza si trimite in retea esantioanle de voce ale unui canal

//indicator de stare la adresa 3FCF din DataMemory

//bufferi de preluare de pachete la adresele 0x1000 si 0x10A0 din DSP_0 DM...

INT16S lun_pack;

unsigned int i,j;

static unsigned int indic_buffer_citire;

static unsigned int seq_num;

static unsigned int indic_buffer_citire_anterioara=0;

static unsigned long time_stamp;

static RTPpacket pck;

data=data;

randomize();

//initializarea random a numarului de secventa si timestamp-ului

seq_num=random( 0x10000 );

time_stamp=random( 0x10000 );

for(;;)

{

while( poll(DSP_0) ) OSTimeDlyHMSM(0,0,0,5);

OSSchedLock();//suspenda functionarea programatorului...

Pagina 111 din 133


dsp_rdbloc(DSP_0, &indic_buffer_citire, 1, 0x7FCF);

//verifica daca s-a mai citit din buferul indicat

if(indic_buffer_citire!=indic_buffer_citire_anterioara)

{

if (indic_buffer_citire==0x0000 )

dsp_rdbloc( DSP_0, buffer_dspread[DSP_0], 160, 0x5000 );

else

dsp_rdbloc( DSP_0, buffer_dspread[DSP_0], 160, 0x50A0 );

indic_buffer_citire_anterioara=indic_buffer_citire;

OSSchedUnlock();//repune in functiune programatorul..

initializare_packet_rtp(&pck, seq_num, time_stamp);

RTPpacket_data(&pck, buffer_dspread[DSP_0] );

lun_pack=12+160;

fprintf( fisier_inc, "\t\t\tTrimis %d\tSeq# %d: %s\n",

sock_fastwrite( &RTPsocket_inc, &pck, lun_pack ), seq_num, pck.data );

seq_num=(seq_num+1)&0xFFFF;

time_stamp=(time_stamp+160)&0xFFFF;

OSTimeDlyHMSM(0,0,0,14);

}

else {



}

}

}

void Task_recv_INC (void *data)

{

Pagina 112 din 133


short nr_rulari, cnt;

LocatieBuffer buffer[64];

short pointer_scriere, pointer_citire;

short i,j,k;

short dif_seqnum, seqnum_exp;

short nr_pcks_consec, indic_loc, gasit;

RTPpacket packete_recept[10];

data=data;

gasit=0;indic_loc=0;

pointer_scriere=10;

nr_rulari=0;

for(;;)

{

cnt=0;

while( sock_recv( &RTPsocket_inc, &packete_recept[cnt] ,sizeof( RTPpacket ), 0 )

>0 )

{

fprintf( fisier_inc, "Primit \tsecv %d\n", ntohs(packete_recept[cnt].seqnum) );

cnt+=1;

}

if(cnt>0) {

if( nr_rulari==0) {

ordonare_packete_recept(packete_recept, cnt);

completare_locatieBuffer(&packete_recept[0], &buffer[pointer_scriere]);

pointer_scriere+=1;

seqnum_exp=packete_recept[0].seqnum;

for(i=1;i<cnt;i++)

{

Pagina 113 din 133


dif_seqnum=(packete_recept[i].seqnum-seqnum_exp);

if(dif_seqnum>0)

{

if (dif_seqnum==1)

{

pointer_scriere+=1;

seqnum_exp+=1;

goto completare0;

}

if(dif_seqnum<MAX_DROPOUT)

{

completare0:

completare_locatieBuffer(&packete_recept[i],\

&buffer[pointer_scriere+dif_seqnum]);

}

} //dif_seqnum>0...

else //dif_seqnum<0...pachete intarziate

{

if( (-10)<dif_seqnum<0 )



}

}//for

nr_rulari+=1;

OSTimeDly(8);//suspenda pe 8 ticks

}//nr_rulari=0...

if(nr_rulari<4)

{

for(i=0;i<cnt;i++)

{


if(dif_seqnum>0)

Pagina 114 din 133


{

if (dif_seqnum==1)

{

pointer_scriere+=1;

seqnum_exp+=1;

goto completare;

}


completare:

{



}

}//dif_seqnum>0...

else //dif_seqnum<0 pachete intarziate...

{

completare_locatieBuffer(&packete_recept[i], &buffer[pointer_scriere+dif_seqnum]);

}

}//for

nr_rulari+=1;


}//nr_rulari<4

//"locatii" pline dupa 4 rulari...

//initializare sursa...inceputul celei de-a 4-a rulari

if(nr_rulari==4)

{

for(k=0;k<10;k++)

if(buffer[k].indicator_locatie==1)

{

indic_loc=k;

gasit=1;

break;

Pagina 115 din 133


}

if(gasit==0) indic_loc=10;

pointer_citire=indic_loc;

while(nr_pcks_consec<MIN_SEQ)

{

if(buffer[indic_loc+1].indicator_locatie==1)

{

nr_pcks_consec+=1;

indic_loc+=1;


}

else//detectie gaura in secventa

{

nr_pcks_consec=0;

for(i=0;;i++)

if(buffer[indic_loc+i].indicator_locatie==1)

{

indic_loc+=i;


break;

}

}

}//while... detectat secv de MIN_SEQ pcks...

goto trs_pkt;

}//initializare la a 4-a rulare...

trs_pkt: //transmitere bloc 160 esantioane al DSP

if(pointer_scriere<=pointer_citire)

{

while(poll(dsp_0)) OSTimeDlyHMSM(0,0,0,5);

OSSchedLock();

dsp_wrbloc(dsp_0, &buffer[pointer_scriere], 160, 0x5400);

OSSchedUnlock();

OSTimeDlyHMSH(0,0,0,17);

Pagina 116 din 133


}

else //pointer citire ajunge din urma pointer scriere

{

dsp_wrbloc(dsp_0, &buffer_liniste, 160, 0x5400);

}

}//if cnt=0...

else OSTimeDly( 4 );//nu s-au primit packete...

}

}

void Task_send_ONIX (void *data)

{

//preia, impacheteaza si trimite in retea esantioanle de voce ale unui canal

//indicator de stare la adresa 3FCE din DataMemory

//bufferi de preluare de pachete la adresele 0x1800 si 0x18A0 din DSP_0's DM

INT16S temp_cnt, lun_pack;

unsigned int i,j;






data=data;

randomize();



for(;;)

{



Pagina 117 din 133


dsp_rdbloc(DSP_0, &indic_buffer_citire, 1, 0x7FCD);



{



else






lun_pack=12+160;






}

else OSTimeDlyHMSM(0,0,0,5);

}

}

void Task_recv_ONIX (void *data)

{




Pagina 118 din 133


short i,j,k;




data=data;


pointer_scriere=10;

nr_rulari=0;

//numarul minim necesar de pachete sosite in secv pentru initializarea sursei

Incr_source.probation=MIN_SEQ;

for(;;)

{

cnt=0;


>0 )

{


cnt+=1;

}

if(cnt>0) {

if( nr_rulari==0) {


completare_locatieBuffer(&packete_recept[0], &buffer[pointer_scriere]);

pointer_scriere+=1;


for(i=1;i<cnt;i++)

{


Pagina 119 din 133


if(dif_seqnum>0)

{

if (dif_seqnum==1)

{

pointer_scriere+=1;

seqnum_exp+=1;

goto completare0;

}


{

completare0:



}

} //dif_seqnum>0...


{




}

}//for

nr_rulari+=1;


}//nr_rulari=0...

if(nr_rulari<4)

{

for(i=0;i<cnt;i++)

{


if(dif_seqnum>0)

{

Pagina 120 din 133


if (dif_seqnum==1)

{

pointer_scriere+=1;

seqnum_exp+=1;

goto completare;

}


completare:

{



}

}//dif_seqnum>0...


{


}

}//for

nr_rulari+=1;


}//nr_rulari<4



if(nr_rulari==4)

{

for(k=0;k<10;k++)


{

indic_loc=k;

gasit=1;

break;

}

Pagina 121 din 133





{


{

nr_pcks_consec+=1;

indic_loc+=1;


}


{

nr_pcks_consec=0;

for(i=0;;i++)


{

indic_loc+=i;


break;

}

}


goto trs_pkt;




{


OSSchedLock();

dsp_wrbloc(dsp_0, &buffer[pointer_scriere], 160, 0x5C00);

OSSchedUnlock();


Pagina 122 din 133


}


{

dsp_wrbloc(dsp_0, &buffer_liniste, 160, 0x5C00);

}

}//if cnt=0...


}

}

void Task_send_FServ (void *data)

{

//preia, impacheteaza si trimite in retea esantioanle de voce ale unui canal din DSP_1

//indicator de stare la adresa 3FCF din DataMemory

//bufferi de preluare de pachete la adresele 0x1000 si 0x10A0 din DSP_1's DM

INT16S lun_pack;

unsigned int i,j;






data=data;

randomize();

//initializarea random a numarului de secventa si timestamp-ului



for(;;)

{



Pagina 123 din 133


dsp_rdbloc(DSP_1, &indic_buffer_citire, 1, 0x7FCF);



{



else






lun_pack=12+160;






}

else OSTimeDlyHMSM(0,0,0,5);

}

}

void Task_recv_FServ (void *data)

{




short i,j,k;

Pagina 124 din 133





data=data;


pointer_scriere=10;

nr_rulari=0;

//numarul minim necesar de pachete sosite in secv pentru initializarea sursei

Incr_source.probation=MIN_SEQ;

for(;;)

{

cnt=0;


>0 )

{


cnt+=1;

}

if(cnt>0) {

if( nr_rulari==0) {


completare_locatieBuffer(&packete_recept[0],\ &buffer[pointer_scriere]);

pointer_scriere+=1;


for(i=1;i<cnt;i++)

{


if(dif_seqnum>0)

Pagina 125 din 133


{

if (dif_seqnum==1)

{

pointer_scriere+=1;

seqnum_exp+=1;

goto completare0;

}


{

completare0:



}

} //dif_seqnum>0...


{




}

}//for

nr_rulari+=1;


}//nr_rulari=0...

if(nr_rulari<4)

{

for(i=0;i<cnt;i++)

{


if(dif_seqnum>0)

{

if (dif_seqnum==1)

Pagina 126 din 133


{

pointer_scriere+=1;

seqnum_exp+=1;

goto completare;

}


completare:

{



}

}//dif_seqnum>0...


{


}

}//for

nr_rulari+=1;


}//nr_rulari<4



if(nr_rulari==4)

{

for(k=0;k<10;k++)


{

indic_loc=k;

gasit=1;

break;

}


Pagina 127 din 133




{


{

nr_pcks_consec+=1;

indic_loc+=1;


}


{

nr_pcks_consec=0;

for(i=0;;i++)


{

indic_loc+=i;


break;

}

}


goto trs_pkt;




{


OSSchedLock();

dsp_wrbloc(dsp_1, &buffer[pointer_scriere], 160, 0x5400);

OSSchedUnlock();


}

Pagina 128 din 133



{

dsp_wrbloc(dsp_1, &buffer_liniste, 160, 0x5400);

}

}//if cnt=0...


}

}

//task care face tcp_tick() si ca urmare raspunde la ping...

void Task_tcpTick (void *data)

{

data=data;

for(;;)

{

tcp_tick( NULL );

OSTimeDly( 5 );

}

}

int initiere_comunicare(void)

{

if( COMUNIC_INCREMENTAL ){

PC_GetDateTime( timp_curent );

fisier_inc = fopen( "rez_incr.txt", "wt" );

if( !fisier_inc )

{

printf("Nu s-a putut deschide fisierul 'rez_inc.txt' pentru salvarea rezultatelor...\n");

goto com_onix;

}

fprintf(fisier_inc,"Fisier deschis cu succes...la ora %s\n", timp_curent);

rtp_ret_inc=RTPinit( LOCALIP,REMOTEIP_INC, RTP_PORT_INC,

RTP_LOCALPORT_INC, &RTPsocket_inc, buf_adresa_inc, fisier_inc );

fprintf( fisier_inc, "RTPinit=%d\nLet's begin...\n", rtp_ret_inc);

Pagina 129 din 133


fprintf(fisier_inc,"Sock_recv_init %d\tBuffer %d\tRTPpacket_size %d\n",\

sock_recv_init( &RTPsocket_inc, buf_inc, sizeof( buf_inc ) ), sizeof( buf_inc ),

sizeof( RTPpacket ) );

OSTaskCreate(Task_recv_INC, (void *)0, (void

*)&TaskStk_recv_INC[TASK_STK_SIZE - 1], TASK_RECV_INC_PRIO );

OSTaskCreate(Task_send_INC, (void *)0, (void

*)&TaskStk_send_INC[TASK_STK_SIZE - 1], TASK_SEND_INC_PRIO );

}

else

{

printf("Nu s-a dorit comunicatie cu Incremental...\n");

goto com_onix;

}

com_onix:

if( COMUNIC_ONIX ){


fisier_onix = fopen( "rez_onix.txt", "wt" );

if( !fisier_onix )

{

printf("Nu s-a putut deschide fisierul 'rez_onix.txt' pentru salvarea rezultatelor...\n");

goto com_FServ;

}

fprintf(fisier_onix,"Fisier deschis cu succes...la ora %s\n", timp_curent);

rtp_ret_onix=RTPinit( LOCALIP,REMOTEIP_ONIX, RTP_PORT_ONIX,

RTP_LOCALPORT_ONIX, &RTPsocket_onix, buf_adresa_onix, fisier_onix );

fprintf( fisier_onix, "RTPinit=%d\nLet's begin...\n", rtp_ret_onix);

fprintf(fisier_onix,"Sock_recv_init %d\tBuffer %d\tRTPpacket_size %d\n",\

sock_recv_init( &RTPsocket_onix, buf_onix, sizeof( buf_onix ) ), sizeof( buf_onix ),

sizeof( RTPpacket ) );

OSTaskCreate(Task_recv_ONIX, (void *)0, (void

*)&TaskStk_recv_ONIX[TASK_STK_SIZE - 1], TASK_RECV_ONIX_PRIO );

OSTaskCreate(Task_send_ONIX, (void *)0, (void

*)&TaskStk_send_ONIX[TASK_STK_SIZE - 1], TASK_SEND_ONIX_PRIO );

Pagina 130 din 133


}

else

{

printf("Nu s-a dorit comunicatie cu Onix...\n");

goto com_FServ;

}

com_FServ:

if( COMUNIC_FServ ){


fisier_FServ = fopen( "rez_FServ.txt", "wt" );

if( !fisier_FServ )

{

printf("Nu s-a putut deschide fisierul 'rez_FServ.txt' pentru salvarea rezultatelor...\n");

goto tcp_tick;

}

fprintf(fisier_FServ,"Fisier deschis cu succes...la ora %s\n", timp_curent);

rtp_ret_FServ=RTPinit( LOCALIP,REMOTEIP_FServ, RTP_PORT_FServ,

RTP_LOCALPORT_FServ,&RTPsocket_FServ, buf_adresa_FServ, fisier_FServ );

fprintf( fisier_FServ, "RTPinit=%d\nLet's begin...\n", rtp_ret_FServ);

fprintf(fisier_FServ, "Sock_recv_init %d\tBuffer %d\tRTPpacket_size %d\n",\

sock_recv_init( &RTPsocket_FServ, buf_FServ, sizeof(buf_FServ) ),

sizeof(buf_FServ), sizeof(RTPpacket) );

OSTaskCreate(Task_recv_FServ, (void *)0, (void

*)&TaskStk_recv_FServ[TASK_STK_SIZE - 1], TASK_RECV_FServ_PRIO );

OSTaskCreate(Task_send_FServ, (void *)0, (void

*)&TaskStk_send_FServ[TASK_STK_SIZE - 1], TASK_SEND_FServ_PRIO );

}

else

{

printf("Nu se doreste comunicatie de nici un fel...\n");

tcp_tick:

if(TCP_TICK_ON_OFF)

Pagina 131 din 133


OSTaskCreate(Task_tcpTick, (void *)0,

(void*)&TaskStk_tcpTick[TASK_STK_SIZE - 1], TASK_TICK_PRIO );

return ERR_NO_TASKS;

}

return INIT_OK;

}

void RTPclose(void)

{

sock_close(&RTPsocket_inc);

sock_close(&RTPsocket_onix);

sock_close(&RTPsocket_FServ);

}

Pagina 132 din 133


ANEXA B3. Fişierul “Wattcp.cfg”

print="Packet driver incarcat…"

my_ip=192.168.1.99

netmask=255.255.255.0


gateway=192.168.1.1

domainslist="topex.rdsnet.ro"

Pagina 133 din 133

http://www.tocilar.ro/

implementare voip pe o centrala telefonica

Documents