Interfata Voip Pentru Centrala Telefonica Digitala Topex 1000d

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.

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:

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:

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]

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.

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 telefo î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.

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.

Î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.

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 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.

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: 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

Referințe bibliografice: [1], [8], [13]

“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 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].

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 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 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 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.

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.

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]

Î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.

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

Referințe bibliografice: [1], [10], [12], [14]

Î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 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.

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 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.

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ă

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

Referințe bibliografice: [1], [10], [12], [14]

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.

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ă 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

Referințe bibliografice: [1], [10], [12], [14]

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.

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.

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, 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ă.

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

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

Schema bloc a centralei telefonice care evidențiază și a structura arhitecturii hardware este prezentată în figura de mai jos:

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.

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

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

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

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:

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.

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

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

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. 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

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

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:

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 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ă

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

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

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.

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 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

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

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

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 )

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:

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 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.

3.2 Amplasarea cartelei în arhitectura

funcțională a centralei

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

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:

3.3 “VoIP card” – extensie a funcționalităților centralei telefonice

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

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.

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.

Capitolul 4. VoIP card”–Implementare software

4.1 Scurtă prezentare hardware

Referințe bibliografice: [5], [6], [7], [19]

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.

Î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:

Figura 4.1.1. Schema hardware de principiu a “VoIP card”

4.2 Software-ul aplicației

Referințe bibliografice: [1], [13], [16]

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.

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 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ă 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

nameserver=149.97.167.134

nameserver=156.198.51.231

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 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.

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

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 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.

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 î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 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;

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( )”.

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 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”.

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 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.

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:

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”, 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.

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.

ANEXE

ANEXA A. Dicționar de acronime

AAA Authentication Authorization and Accounting

AAL2 ATM Adaptation Layer type 2

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

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

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

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

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

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

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

****************************************************************************/

#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()

#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

#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

#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);

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);

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];

}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

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;

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

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 %

PC_DispStr(37, 23, s, DISP_FGND_BLUE + DISP_BGND_CYAN);

sprintf(s, "%5d", OSCtxSwCtr); // Display #context switches per second

PC_DispStr(63, 23, s, DISP_FGND_BLUE + DISP_BGND_CYAN);

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

}

}

/******************************** 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 ) );

fprintf( fisier, "Masinile s-au conectat cu succes…\n" );

return 0;

}

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,0×7400);

return tmp;

} //poll

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,0×7400);

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)

{

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))

{

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;

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"

#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{

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;

//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

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"

#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];

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

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)

{

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;

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…

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 {

OSTimeDlyHMSM(0,0,0,5);

OSSchedUnlock();//repune in functiune programatorul..

}

}

}

void Task_recv_INC (void *data)

{

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++)

{

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 )

completare_locatieBuffer(&packete_recept[i],\

&buffer[pointer_scriere+dif_seqnum]);

}

}//for

nr_rulari+=1;

OSTimeDly(8);//suspenda pe 8 ticks

}//nr_rulari=0…

if(nr_rulari<4)

{

for(i=0;i<cnt;i++)

{

dif_seqnum=(packete_recept[i].seqnum-seqnum_exp);

if(dif_seqnum>0)

{

if (dif_seqnum==1)

{

pointer_scriere+=1;

seqnum_exp+=1;

goto completare;

}

if(dif_seqnum<MAX_DROPOUT)

completare:

{

completare_locatieBuffer(&packete_recept[i],\

&buffer[pointer_scriere+dif_seqnum]);

}

}//dif_seqnum>0…

else //dif_seqnum<0 pachete intarziate…

{

completare_locatieBuffer(&packete_recept[i], &buffer[pointer_scriere+dif_seqnum]);

}

}//for

nr_rulari+=1;

OSTimeDly(8);//suspenda pe 8 ticks

}//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;

}

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;

pointer_citire=indic_loc;

}

else//detectie gaura in secventa

{

nr_pcks_consec=0;

for(i=0;;i++)

if(buffer[indic_loc+i].indicator_locatie==1)

{

indic_loc+=i;

pointer_citire=indic_loc;

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);

}

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;

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();

seq_num=random( 0x10000 );

time_stamp=random( 0x10000 );

for(;;)

{

while( poll(DSP_0) ) OSTimeDlyHMSM(0,0,0,5);

OSSchedLock();//suspenda functionarea programatorului…

dsp_rdbloc(DSP_0, &indic_buffer_citire, 1, 0x7FCD);

//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, 0x5800 );

else

dsp_rdbloc( DSP_0, buffer_dspread[DSP_0], 160, 0x58A0 );

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 OSTimeDlyHMSM(0,0,0,5);

}

}

void Task_recv_ONIX (void *data)

{

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;

//numarul minim necesar de pachete sosite in secv pentru initializarea sursei

Incr_source.probation=MIN_SEQ;

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++)

{

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 )

completare_locatieBuffer(&packete_recept[i],\

&buffer[pointer_scriere+dif_seqnum]);

}

}//for

nr_rulari+=1;

OSTimeDly(8);//suspenda pe 8 ticks

}//nr_rulari=0…

if(nr_rulari<4)

{

for(i=0;i<cnt;i++)

{

dif_seqnum=(packete_recept[i].seqnum-seqnum_exp);

if(dif_seqnum>0)

{

if (dif_seqnum==1)

{

pointer_scriere+=1;

seqnum_exp+=1;

goto completare;

}

if(dif_seqnum<MAX_DROPOUT)

completare:

{

completare_locatieBuffer(&packete_recept[i],\

&buffer[pointer_scriere+dif_seqnum]);

}

}//dif_seqnum>0…

else //dif_seqnum<0 pachete intarziate…

{

completare_locatieBuffer(&packete_recept[i], &buffer[pointer_scriere+dif_seqnum]);

}

}//for

nr_rulari+=1;

OSTimeDly(8);//suspenda pe 8 ticks

}//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;

}

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;

pointer_citire=indic_loc;

}

else//detectie gaura in secventa

{

nr_pcks_consec=0;

for(i=0;;i++)

if(buffer[indic_loc+i].indicator_locatie==1)

{

indic_loc+=i;

pointer_citire=indic_loc;

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, 0x5C00);

OSSchedUnlock();

OSTimeDlyHMSH(0,0,0,17);

}

else //pointer citire ajunge din urma pointer scriere

{

dsp_wrbloc(dsp_0, &buffer_liniste, 160, 0x5C00);

}

}//if cnt=0…

else OSTimeDly( 4 );//nu s-au primit packete…

}

}

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;

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_1) ) OSTimeDlyHMSM(0,0,0,5);

OSSchedLock();//suspenda functionarea programatorului…

dsp_rdbloc(DSP_1, &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_1, buffer_dspread[DSP_1], 160, 0x5000 );

else

dsp_rdbloc( DSP_1, buffer_dspread[DSP_1], 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_1] );

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 OSTimeDlyHMSM(0,0,0,5);

}

}

void Task_recv_FServ (void *data)

{

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;

//numarul minim necesar de pachete sosite in secv pentru initializarea sursei

Incr_source.probation=MIN_SEQ;

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++)

{

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 )

completare_locatieBuffer(&packete_recept[i],\

&buffer[pointer_scriere+dif_seqnum]);

}

}//for

nr_rulari+=1;

OSTimeDly(8);//suspenda pe 8 ticks

}//nr_rulari=0…

if(nr_rulari<4)

{

for(i=0;i<cnt;i++)

{

dif_seqnum=(packete_recept[i].seqnum-seqnum_exp);

if(dif_seqnum>0)

{

if (dif_seqnum==1)

{

pointer_scriere+=1;

seqnum_exp+=1;

goto completare;

}

if(dif_seqnum<MAX_DROPOUT)

completare:

{

completare_locatieBuffer(&packete_recept[i],\

&buffer[pointer_scriere+dif_seqnum]);

}

}//dif_seqnum>0…

else //dif_seqnum<0 pachete intarziate…

{

completare_locatieBuffer(&packete_recept[i], &buffer[pointer_scriere+dif_seqnum]);

}

}//for

nr_rulari+=1;

OSTimeDly(8);//suspenda pe 8 ticks

}//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;

}

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;

pointer_citire=indic_loc;

}

else//detectie gaura in secventa

{

nr_pcks_consec=0;

for(i=0;;i++)

if(buffer[indic_loc+i].indicator_locatie==1)

{

indic_loc+=i;

pointer_citire=indic_loc;

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_1)) OSTimeDlyHMSM(0,0,0,5);

OSSchedLock();

dsp_wrbloc(dsp_1, &buffer[pointer_scriere], 160, 0x5400);

OSSchedUnlock();

OSTimeDlyHMSH(0,0,0,17);

}

else //pointer citire ajunge din urma pointer scriere

{

dsp_wrbloc(dsp_1, &buffer_liniste, 160, 0x5400);

}

}//if cnt=0…

else OSTimeDly( 4 );//nu s-au primit packete…

}

}

//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);

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 ){

PC_GetDateTime( timp_curent );

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 );

}

else

{

printf("Nu s-a dorit comunicatie cu Onix…\n");

goto com_FServ;

}

com_FServ:

if( COMUNIC_FServ ){

PC_GetDateTime( timp_curent );

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)

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);

}

ANEXA B3. Fișierul “Wattcp.cfg”

print="Packet driver incarcat…"

my_ip=192.168.1.99

netmask=255.255.255.0

nameserver=192.168.1.1

gateway=192.168.1.1

domainslist="topex.rdsnet.ro"

Bibliografie

“Rețele de Telecomunicații 2”, curs UPB, anul V, prof. E.Borcoci.

“Sisteme în timp-real în telecomunicații”, curs UPB, anul IV, prof. E.Borcoci.

Jean J. Labrosse-“MicroC/OS-II The Real Time Kernel”–Ed.“CMP Books”, 2000.

Eric Engelke – “WATTCP Programmer’s Reference”, Ediția a 2-a, 2001.

“ADSP-2100 Family – User’s Manual“ – Analog Devices. Ediția a 3-a, sept. 1995.

“Topex 1000D, Centrală telefonică publică – Manual tehnic”, 2000.

G.Niculescu, L.Ioan – “Sisteme de comutație”, Ed. MatrixRom, 2000.

A.Tanenbaum – “Rețele de calculatoare, ediția a 3-a”, Ed. Agora, 1998.

http://www.iec.org/tutorials/voip_voatm

http://www.iec.org/tutorials/h323

http://www.iec.org/tutorials/acc_gate

http://www.iec.org/tutorials/int_tele

http://www.iec.org/tutorials/vfoip

http://www.radcom-inc.com/radcom/technlgy/pdf/finetuning_voip.pdf

http://www.protocols.com/pbook/h323.htm

http://www.itpapers.com/techguide/voiceip.pdf

http://www.cisco.com/networkers/nw99_pres/401.pdf

http://www.cisco.com/networkers/nw99_pres/402.pdf

http://www.fabiatech.com/download/M2330v14.pdf

http://www.wattcp.com

http://www.uCOS-II.com

RFC 1889–“RTP: A Transport Protocol for Real-Time Applications”

http://www.protocols.com/acronyms_list.htm

http://www.elcom.pub.ro/~rlupu/acronyms.html