Imbunatatirea Calitatii Serviciilor In Comunicatiile Mobile

Introducere

2 Sisteme de comunicații mobile

2.1 GSM

2.2 GPRS

2.3 E-GPRS (EDGE)

2.4 UMTS

2.5 HSDPA

2.6 Evoluția către rețele IP (all IP Networks)

2.7 CDMA2000

2.8 Sistemul WiMAX și alte sisteme bazate pe OFDM

2.9 LTE

2.10 ATCA

2.11 Integrarea platformei experimentale cu un sistem de testare de la distanță

3 Servere și servicii în comunicații mobile

3.1 Servere

3.2 Serviciile

3.3 Servicii multimedia și conceptele de rețea

3.4 Serviciile în telecomunicații

3.5 Managementul rețelelor de comunicații mobile

3.6 Integrarea de servere și servicii pe ATCA

3.7 Tehnici de programare a serviciilor și integrare business

4 Algoritmii QoS în comunicațiile mobile.

4.1 Probleme legate de calitatea serviciilor (QoS)

4.2 Mecanismele pentru asigurarea QoS

4.3 Algoritmi de formare a traficului: „Leaky bucket” și „Token Bucket”

4.4 Servicii diferențiate (DiffServ)

4.5 Servicii integrate (IntServ)

4.6 Asynchronous Transfer Mode – ATM

4.7 Multiprotocol Label Switching (MPLS)

4.8 QoS în rețelele de comunicații mobile

4.9 Mașini algoritmice utilizate în modelare

5 QoS pentru streaming mobil de date

5.1 Calitatea tele-transmisiei de date pentru măsurări mobile

5.2 Sistem Dublu-Microcontroler cu Tele-Monitorizare prin Modem GSM

6 Optimizarea QoS în comunicații mobile de date

6.1 Formula propusă pentru QoS cu dublă ponderare

6.2 Utilizarea QoS pentru Realocarea Traficului în

7

Bibliografie

Introducere

Comunicațiile mobile au cunoscut o dezvoltare explozivă în ultimii ani, pătrunzând în cele mai diverse domenii și cuprinzând tot mai multe tehnologii. Rețelele wireless completează și chiar înlocuiesc rețelele cablate în multe locuințe și birouri. În completarea rețelelor wireless vin rețelele de telefonie mobilă care oferă rate de transfer comparabile cu rețelele wireless, dar cu avantajul unei acoperiri mai mari. Având în vedere disponibilitatea atâtor modalități de transmisii de date, se pune problema posibilității păstrării unei conectivități continue, neîntrerupte, atât timp cât avem la dispoziție cel puțin una din aceste rețele. În această lucrare am propus câteva modalități de realizare acestui deziderat.

Lucrarea debutează cu prezentarea celor mai importante sisteme de comunicații mobile, cu

accent pe cele celulare – GSM, GPRS, UMTS, CDMA2000, WiMAX, LTE (Long Term Evolution). De asemenea este prezentată arhitectura ATCA (Advanced Telecom Computing Architecture). Se accentuează contribuțiile autorului la modernizarea arhitecturii, echipamentelor, interfețelor hardware și software (drivers) pentru adăugarea capabilităților de telemăsurare care vor fi valorificate în capitolul 6.

Capitolul 3 prezintă servere și servicii specifice pentru comunicațiile mobile. Orientarea

spre servicii reprezintă o perspectivă modernă concretizată în toată lucrarea și încununată de dezvoltările din prima partea a capitolului 6. Capitolul 3 include o substanțială contribuție a autorului prin integrarea de servicii pe platforma ATCA utilizând soluții durabile (open-source) pentru GGSN (Gateway GPRS Support Node) și mai ales pentru IMS (OpenIMS) – o implementare IP Multimedia Services. Soluțiile găsite de autor sunt validate de un studiu de caz de comutație a fluxurilor multimedia cu evidențierea valorilor specifice QoS. Capitolul se încheie cu integrarea acestor servere și servicii în „rețele pentru managementul rețelelor”, TMN (Telecom Management Networks – standardul TM.3000 al ITU cu accent pe funcțiile care permit analiza și managementul calității).

Capitolul 4 prezintă QoS în perspectiva folosirii în comunicațiile multimodale. Autorul

propune o unificare a parametrilor ce determină QoS pentru diversele moduri ale unor transmisiuni combinate (multimodale). Perspectiva este în continuare axată pe testabilitate în medii emulate/simulate cu accent pe mașinile algoritmice de stare (ASM – Algorithmic State Machines) care stau la baza modelelor comportamentale (de tip cutie albă – „white box behavioral models”) din telecomunicații (modele care le completează pe cele de tip cutie neagră – „black box” limitate la interfațare). Autorul realizează o parametrizare pentru un studiu de caz bi-modal 3G – WLAN în contextul unuia din cele mai răspândite medii de simulare: „OPNET” și detaliază cele mai importante ASM.

Capitolul 5 este dedicat QoS pentru streaming mobil. Conceptele sunt concretizate într- o serie de aplicații de telemăsurare. Autorul detaliază condiționarea QoS și în general a performantelor de funcționare amănunțită a subsistemelor dintr-o rețea de comunicații mobile, cu analiză de protocol, diagrame și caracteristici diverse, interpretate în sensul selectării celor mai bune soluții.

Capitolul 6 este dedicat optimizării QoS în comunicațiile mobile de date. Se utilizează

funcții de timp real, charging și PDC (Performance Data Collection) pentru redimensionarea (realocarea) traficului în comunicații mobile multimodale. Abordarea este top-down: autorul creează un serviciu dedicat bazat pe BPEL, pentru implementarea deciziei multicriteriale privitoare la „handover parțial” pe baza PDC, în vederea managementului bazat pe QoS al comunicațiilor mobile multi-modale, cu accent pe comutația fluxurilor multi-media în contextul protocoalelor SIP și RTP.

În partea a doua a acestui capitol autorul validează conceptul de realocare a traficului pe baza QoS într-o configurație OPNET 3G/WLAN. Se propune modelul detaliat al unui terminal mobil bi-modal fiind implementate principalele ASM descrise în capitolul 4. Conceptele sunt într-o configurație GPRS/3G/WLAN. Sunt interpretate datele și observațiile dintr-un scenariu de handover WiFi ↔ GPRS (UMTS – 3G) cu implementare MobileIP.

2 Sisteme de comunicații mobile

Acest capitol oferă o privire de ansamblu asupra sistemelor de comunicații mobile, cu un accent deosebit pe comunicațiile celulare, evidențiind unele caracteristici ale parametrilor de calitate a serviciilor (QoS – Quality of Service). Aceste caracteristici vor fi utilizate apoi în capitolul 4.

2.1 GSM

Sistemul GSM este prezentat în special pentru importanța pe care încă o are pentru comunicațiile mobile, având încă cea mai mare acoperire dintre toate sistemele de comunicații mobile celulare și, de asemenea, pentru faptul că este baza pe care s-au dezvoltat două dintre sistemele de comunicații de date mobile orientate pe pachete: GPRS și EGDE.

Două dintre caracteristicile sale îl fac nepotrivit pentru transmisia de date:

• Timpul mare de stabilire pentru conexiunile de date, de ordinul zecilor de secunde

• Rata de transfer mică, de numai 9,6 kbiți/s, insuficientă pentru majoritatea aplicațiilor. După cum se poate vedea în figura următoare, rețeaua celulară GSM este alcătuită din Access Network (rețeaua de acces – BTS și BSC, alcătuind BSS) și Core Network (MSC, HLR, VLR,EIR și AuC).

Figura 2-1 Arhitectura sistemului GSM

GSM este o rețea celulară – telefoanele mobile se conectează la ea căutând celule din apropiere. Deoarece tipul de transmisie este unul de tip comutare de circuite, pentru conexiunea de date GSM, caracteristicile de întârziere și jitter sunt excelente, însă resursele consumate și lățimea de bandă oferită, chiar și prin HSCSD, sunt mult prea mici pentru o utilizare realistă, singura utilizare putând fi în transmisiile de date de volum mic (9,6 kbiți/s pana la 57,6 kbiți/s).

Deși sistemul GSM este de foarte mare succes, el va fi înlocuit treptat cu UMTS sau, chiar în unele cazuri, probabil că sa se va face tranziția direct la tehnologii LTE. De asemenea, se prefigurează deja și înlocuirea UMTS cu LTE.

2.2 GPRS

GPRS este un serviciu care oferă efectiv acces radio pe bază de pachete pentru utilizatori GSM și Time Division Multiple Access (TDMA) deopotrivă. Principalele avantaje ale GPRS sunt rezervarea resursele radio numai atunci când datele sunt disponibile pentru a le trimite, și reducerea dependenței de circuite comutate a rețelelor tradiționale.

În figura 2.2 este prezentat un exemplu de rețea GPRS cu interconectare cu rețelele fixe

de date.

Figura 2-2 Arhitectura rețelei GPRS

Standardul inițial GPRS face uz de sistemele radio standard GSM. Acest lucru include, de asemenea, schemele de modulare și structurile de cadru standard GSM și TDMA. GPRS prevede alocarea și repartizarea dinamică a canalelor radio pentru servicii de pachete de date, în funcție de cerere.

Parametrii QoS suportați de GPRS pot fi separați în două categorii, în funcție de versiunea de specificații pe care o respectă Rel 97/98 sau R99.

Parametrii luați în considerare pentru evaluarea unei conexiuni de date sunt:

– pentru QoS R97/R98:

A. Clasa de precedență (precedence class) B. Rata de transfer medie (mean troughput) C. Clasa de întârziere (delay class)

D. Clasa de fiabilitate (reliability class)

– pentru QoS R99:

A. Clasa de trafic

B. Rata de bit garantată – atât downlink cât și în uplink

C. Întârzierea de transfer

D. Raportul de erori al SDU

Acești parametri sunt cei mai relevanți în streaming-ul de date și, de asemenea, au corespondenți în parametrii QoS ai altor rețele de transport.

2.3 E-GPRS (EDGE)

Rel'99 introduce Enhanced Data Global Evolution (EDGE) pe interfața radio. Specificațiile Rel'99 și cele de mai târziu se bazează pe interfața EDGE de radio GERAN. Trecerea la EDGE nu necesită actualizări ale rețelei de bază (Core Network), sistemul fiind„backwards compatible”. Cele mai multe au introdus stațiile de bază capabile EDGE treptat, minimizând modificările rețelei cât mai mult posibil. E-GPRS folosește, în plus față de GPRS,6 scheme de codificare.

Parametrii QoS suportați de EDGE sunt aceeași ca și cei pentru GPRS (respectândspecificațiile Release 97/98 sau Release 99), cu diferența că sunt suportate și rate de bit mai mari, de până la 384 de kbiți/s. De aceea, se vor reține doar parametrii ce vor fi evaluați în cazul streaming-ului de date, prezentați mai sus, pentru GPRS.

2.4 UMTS

Ca structură rețeaua UMTS este foarte asemănătoare cu rețeaua GPRS prezentată anterior. Diferența este că locul BSC-ului este preluat de RNC (Radio Network Controller), iar locul BTS-ului este preluat de către NodeB. De asemenea, aceste elemente de rețea au în plus și funcționalități noi.

Când se definesc clasele de calitate a serviciilor pentru UMTS trebuie luate în considerare restricțiile și limitările interfeței radio. Nu este rezonabil să se definească mecanisme complexe, asemenea celor din rețelele de telefonie fixă, datorită caracteristicilor de eroare la transmisie prin interfața radio. Mecanismele de asigurare a calității serviciilor oferite în cazul rețelelor celulare trebuie să fie robuste și capabile să asigure o rezoluție rezonabilă a calității serviciilor.

Există patru tipuri diferite de clase pentru calitatea serviciilor: clasa conversațională („conversațional”), clasa fluxurilor de date („streaming”), clasa interactivă („interactive”), clasa de fundal (background).

Principala diferență dintre aceste clase este reprezentată de sensibilitatea traficului la întârzieri: prin urmare, clasa conversațională este destinată traficului foarte sensibil la întârzieri, în timp ce clasa de fundal este cea mai puțin sensibilă la întârzieri. Totuși, nu există o regulă strictă de mapare a traficului la aceste clase, în sensul că un utilizator poate solicita pentru un serviciu interactiv o clasă de trafic conversațional.

Pentru rețelele UMTS, atributele calității serviciilor sunt aceleași ca și cele pentru

GPRS/EDGE Release 99.

2.5 HSDPA

HSDPA este o altă soluție aplicată ca răspuns la necesitatea de lățime de bandă mai mare. Esența HSDPA este multiplexarea de mai multe canale de downlink (dacă este disponibilă) pentru a crește lățimea de bandă disponibilă. Cu toate acestea, există algoritmi destul de complecși pentru controlul admiterii, pentru a evita situația când utilizatorii HSDPA împiedică accesul altor utilizatori HSDPA precum și a celor normali.

Pentru rețelele HSxPA, atributele calității serviciilor sunt aceleași ca și cele pentru UMTS Rel 99, cu mențiunea că valorile pentru rata de bit maximă și pentru rata de bit garantată pot avea valori până la16 Mbiți/s în Release 5 și Release 6 și 256 Mbiți/s în Release 7.

2.6 Evoluția către rețele IP (all IP Networks)

UMTS Release 5 se bazează pe punerea în aplicare parțială a Protocolului Internet (IP) de comutare de pachete în cadrul rețelei de bază (CN), pentru a se face trecerea la o arhitectură all- IP. În această versiune, pachetele pot fi transportate de la un capăt la celălalt al rețelei folosind transportul IP, cu un serviciu de orientat pe comutație de pachete (EDGE/UMTS/HSxPA) conectat la o rețea IP Multimedia Subsystem (IMS).

2.7 CDMA2000

CDMA2000 este o familie de standarde de telecomunicații mobile 3G care utilizează CDMA. Este a doua generație de comunicații celulare digitale CDMA, succesor direct al IS-95. Standardele CDMA2000 1x, Rev. 0, CDMA2000 EV-DO Rev. A și CDMA2000 EV-DO Rev. B, sunt interfețe radio aprobate pentru standardul ITU IMT-2000 și un succesor direct al IS-95 (cdmaOne). CDMA2000 este standardizat de 3GPP2. Deși ambele utilizează WCDMA, CDMA2000 este un concurent incompatibil cu celalalt standard 3G major UMTS.

CDMA2000 1x este de asemenea cunoscut ca CDMA2000 1xRTT în care caz, denumirea "1xRTT" este folosită pentru a identifica versiunea tehnologiei de radio CDMA2000, care funcționează pentru o pereche de canale radio de 1.25MHz (un singur canal de 1.25 MHz, spre deosebire de trei canale de 1.25 MHz în 3xRTT). 1xRTT aproape dublează capacitatea de voce în rețele IS-95. CDMA2000 include protocoale de control al accesului la media și legătură și de control al QoS. În IS-95, nici una dintre acestea nu au fost prezente, iar nivelul de legătură la date a constat practic într-o livrare "best effort" RLP – această configurație este încă folosită pentru voce.

CDMA2000 1xEV-DO (1x Evolution-Data Optimized, inițial 1x Evolution-Data Only),cunoscut și sub numele 1xEV-DO, EV-DO, EVDO, sau doar DO, este o evoluție a CDMA20001x cu capacitate mare (High Data Rate – HDR). CDMA2000 1xEV-DO în revizia A, suportă rate de date în downlink de până la 3.1 Mbiți/s și rate de date în uplink de până la 1.8 Mbiți/s pentru un echipament utilizator dedicat transportării de pachete de date de viteză mare. CDMA2000 1xEV-DO în revizia B suportă rate de date în downlink de până la 4,9 Mbiți/s, prin multiplexare rata maximă ajungând până la 14,7Mbiți/s. De asemenea sunt redusă latența și interferențele de pe sectoarele adiacente. CDMA2000 1xEV-DV (1x Evolution-Data/Voice), suportă rate de date în downlink de până la 3.1 Mbiți/s și rate de date în uplink de până la 1.8 Mbiți/s. 1xEV-DV poate suporta, de asemenea, servirea concomitentă a utilizatorilor sistemelor mai vechi 1x de voce, 1x de date, precum și de mare viteză 1xEV-DV în cadrul aceluiași canal radio. Din cauza lipsei de interes din partea operatorilor de transport, dezvoltarea de CDMA2000 1xEV-DV a fost oprită.

CDMA2000 nu a stabilit în mod explicit obiective pentru QoS, nici nu a definit clase proprii similare UMTS. Totuși, în practică, suportă aceeași gamă generală de aplicații și oferă niveluri adecvate de calitate prin utilizarea caracteristicilor la nivelul legăturii radio și a capabilităților Mobile IP. Pentru aplicații de tip comutare de circuite, informația QoS se înregistrează în mesajele inițiale de semnalizare pentru configurarea apelului (mesaje SIP). Factorii cheie în realizarea acestui lucru sunt descrierea serviciului, care conține cererea și lățimea de bandă, precum și modul „asigurat” sau „neasigurat” (assured sau nonassured). Pe legătura de radio sunt definite ca setul 1 și 2.

La nivelul de date utilizator, QoS se bazează pe diferitele clase Diffserv. Acestea pot fi solicitate de către stațiile mobile prin intermediul informațiilor QoS cerute prin mesaje SIP sau pe baza profilului utilizator DiffServ 3GPP2 al acestuia, înregistrat în serverul RADIUS de „domiciliu” (home RADIUS server). Aceste setări DiffServ sunt incluse în mesajele tunelate către serverul de domiciliu „Home Agent”.

2.8 Sistemul WiMAX și alte sisteme bazate pe OFDM

OFDM reprezintă o abordare de design de sistem diferită. Aceasta poate fi gândită ca o combinație de modulație și scheme de acces multiplu care segmentează un canal de comunicare în așa fel încât mai mulți utilizatori să îl poată partaja. Întrucât segmentele TDMA sunt legate de timp, și segmente CDMA de codurile de răspândire, segmentele OFDM sunt legate de frecvență. Această tehnică împarte spectrul de frecvențe într-un număr de tonuri echidistante și poartă o parte din informațiile utilizatorului pe fiecare ton. Un ton poate fi gândit ca o frecvență, similar felului în care fiecare notă de pe un pian reprezintă o frecvență unică. OFDM poate fi privită ca o formă de multiplexare (FDM) cu divizare în frecvență.

FLASH-OFDM folosește arhitectura IETF, utilizând tehnologia IP de gestionare a mobilității (Mobile IP), securitate IP și de IP QoS, aceasta eliminând necesitatea unor protocoale costisitoare pentru rețelele de acces radio.

2.9 LTE

LTE Long Term Evolution (LTE) reprezintă următorul pas în dezvoltarea 3GPP (3rd Generation Partnership Project) la nivel mondial în rețelele de telefonie mobilă de bandă largă. Standardizarea LTE a început cu Release-ul 8 din 3GPP. Principiile de bază ale arhitecturii LTE SAE includ:

•Rate de transfer mari prin intermediul unor tehnologii de acces radio eficiente, bazate pe tehnologii de nivel fizic ca Orthogonal Frequency Division Multiplexing (OFDM) și Multiple-Input Multiple-Output (MIMO) (un sistem 4×4 MIMO sporește rata de downlink de până la 326 Mbps).

•optimizări ale întârzierilor și o arhitectură simplificată

•protocoale bazate pe IP pe toate interfețele

•arhitectura armonizată pentru 3GPP accesează și interacționează cu entități non-3GPP, interoperabilitatea optimizată cu tehnologii de acces 3GPP și CDMA, precum și utilizare de abonați și soluții de control de servicii comune.

Noile entități funcționale de rețea ale Evolved Packet Core (EPC) sunt: Mobility

Figura 2-6 a) Arhitectura Non-roaming EPS

Management Entity (MME) responsabilă cu semnalizarea NAS (non-Access Stratum) și cu securitatea NAS și cu Idle Mode Mobility Management, Serving Gateway (SGW) cu rolul principal de a ruta și de a transmite pachetele de date de pe user-plane și Packet Data Network Gateway (PGW) este interfața cu PDN. În cazul în care UE accesează mai multe PDNs, pot exista mai mult de un PDN GW pentru acel UE.

Marele avantaj al arhitecturii LTE este acela că permite conexiunea și handover-ul la alte tehnologii de acces fără fir sau fixe, cu fir, oferind furnizorilor de servicii capacitatea de a livra mobilitate continuă.

Datorită corespondenței dintre funcțiile elementelor din diferite tehnologii 3GPP, se pot face anumite asociații logice. Core-ul comun SGSN / MME poate fi văzut ca un singur element: folosește date oferite de abonat, MME și SGSN au același PDP / purtătoare pentru abonați iar modelul QoS este similar. Rețeaua este optimizată prin utilizarea unui GW. Aceleași grupări funcționale pot fi făcute pentru Serving și PDN-Gateway ca un gateway comun.

2.10 ATCA

ATCA este un standard internațional ce definește o arhitectură de telecomunicații deschisă. Specificațiile se referă la toate cerințele electrice și mecanice necesare pentru a crea o platformă standard. Principalul obiectiv al ATCA este de a permite construirea unor sisteme convergente de tip „carrier grade”; se dorește convergența accesului de telecom și a funcțiilor echipamentelor de vârf în cadrul aceleiași platforme modulare. Această caracteristică de modularitate, permite atât producătorilor cât și utilizatorilor să folosească aceeași carcasă/infrastructură de integrare (backplane) pentru mai multe tipuri de produse, utilizând diferite module.

Rețeaua implementată pe arhitectura ATCA emulează arhitectura CN de GPRS, RAN-ul, un PDN extern și câteva servere cu aplicații larg utilizate în rețele de telecomunicații reale.

Software-urile de emulare SGSN, GGSN și IMS pot fi instalate, configurate și rulate pe platforma ATCA. De asemenea serviciile suplimentare testate, ca „handover decision” sunt implementate pe un blade ATCA.

Prin deploymentul serviciului de decizie de handover pe un sistem ATCA sedemonstrează posibilitatea integrării acestui serviciu într-o rețea aparținând unui operator, dupăcum se va vedea în capitolul 6.

2.11 Integrarea platformei experimentale cu un sistem de testare de la distanță

Testarea de la distanță cu echipament real este o mare provocare tehnologică în această perioadă de globalizare. Contribuțiile prezentate mai jos conectează platforma experimentală la infrastructura unui laborator Siemens de comunicații mobile.

Este prezentată extensia realizată de autor asupra unui Centru Mobil de Comutație din laboratoarele Siemens PSE România, soluție adoptată apoi și la laboratoarele Siemens PSE Austria. Prin această extindere s-a asigurat accesarea de la distanță a dispozitivelor de stocare de tipul Magnetic Disk Drive (MDD) și Magnetic Optical Disk (MOD) compatibile SCSI din cadrul centrelor de comutație MSC (Mobile Switching Centers) și semnalizare SS7 ale rețelei de telecomunicații

Dispozitivele de stocare de tipul MDD și MOD trebuiau să fie conectate la un PC dedicat, cu interfețe specializate și costisitoare (rack-uri SCSI), pentru operațiunile de formatare (în cazul sistemelor proprietare, de genul Siemens „WinDiskus”, incompatibile FAT32 sau NTFS) și pentru instalarea sistemelor de operare de tipul ”Application Program Software”(APS). Orice altă operațiune de adăugare sau instalare necesita acest tip de manipulare, la locația sistemului respectiv și consumatoare de timp. Cu ajutorul unui PC, conectarea se face atât în modul multi-device și în modul multi-controller astfel încât, dispozitivele de stocare pot fi accesate în mod direct fără a mai fi necesară oprirea controller- elor și transportarea dispozitivelor.

La PC-ul menționat mai sus s-a adăugat o placă cu relee ”reed” conectată pe portul Paralel și controlată de un program dedicat care poate seta un octet (sau chiar un bit) pentru o anumită perioadă de timp, când se apasă un buton virtual din interfața de acces de la distanță ("VNC"). Comutatorul minimal de pornire care se conectează la GND (masă) este dublat în paralel de starea de ”normal-deschis” a releelor. Principiul poate fi extins la celelalte tipuri de operațiuni (oprirea/pornirea alimentării) și reprezintă o importantă contribuție dacă se consideră cele trei aspecte ale automatizării: ”generare”-”măsurare”(practic concepte duale)-”comutare”. O cameră web a fost instalată pentru a verifica starea LED-urilor din panoul de control al comutatorului.

Prin această soluție bazată pe comenzi AT trimise către terminalele mobile aflate în laboratorul de la distanță, în baza extensiei hardware implementate de autor, testele făcute de ” Integratorii de Proiect” în GSM-GPRS-UMTS se pot realiza teste cu echipament real (RET – „Real Equipment Testing”). Extensia hardware deservește o gamă largă de telefoane mobile din seriile Sx5/Mx5..

Pe lângă aceste contribuții la subsistemele hardware, autorul a abordat și mediile software de testare bazate pe programe de fuziune a bazelor de date cu parametrii operatorului, capabilitățile furnizorului și seturile de comenzi – pentru a furniza planul de testare și seturile tip „service packages” de mari dimensiuni. Autorul a realizat utilitare de descărcare (din spațiul central de stocare Siemens), asamblare și etichetare automată a modulelor software de corecție – „patches” – lucru care necesita înainte un mare efort din partea inginerilor de testare.

3 Servere și servicii în comunicații mobile

3.1 Servere

În lumea de astăzi avem o multitudine de servicii oferite în toate domeniile: în telecomunicații, în rețele de calculatoare, în Internet. Software-ul ca un serviciu (SaaS) este tot mai mult utilizat, oferind atât stabilitate cât și performanță:

•prin utilizarea unei ferme de servere se ajunge atât la stabilitate și cât și la performanță(de exemplu infrastructura Google și Amazon Elastic Compute Cloud – Amazon EC2)

•accesibilitatea se obține prin utilizarea internetului pentru accesul la resurse. Așadar,serviciile sunt disponibile oriunde Internet-ul este disponibil, deci aproape peste tot.

Cu toate acestea, nu putem vorbi despre server fără a discuta despre servicii pentru că ele sunt ceea ce oferă serverele clienților.

Arhitectura client-server este o arhitectură de calcul, care separă un client de un server și este aproape întotdeauna folosită într-o rețea de calculatoare. Fiecare client sau server conectat la o rețea poate fi numit în continuare un nod. Tipul cel mai comun al arhitecturii client-server are doar două tipuri de noduri: clienți și servere. Aceasta permite dispozitivelor partajarea fișierelor și resurselor.

Serverul oferă unul sau mai multe servicii pentru client. În rețelele de telecomunicații putem găsi serverele și serviciile furnizate de servere în mai multe locuri: Intelligent Networks (IN) – SCP – Service Control Point, împreună cu SDP – Service Data Point și de SMS – Service Management System: acestea oferă diferite servicii clienților abonații mobile sau fixe. Serviciile sunt administrate la sistemele de servicii de management și apoi puse la dispoziția abonaților prin SDP și SCP; MNP Portabilitatea numerelor mobile (sau LNP – Local NP, WLNP – Wireless Local NP). Pentru a oferi serviciul NP, rețeaua de telecomunicații are nevoie de un server de MNP care va oferi informații de rutare pentru un anumit abonat (fix sau mobil).

Fiecare instanță a software-ului client poate trimite cererile de date la unul sau mai multe servere conectate. La rândul său, serverele pot accepta aceste cereri, le pot prelucra și pot returna informațiile solicitate la client. Cu toate că acest concept poate fi aplicat dintr-o varietate de motive pentru mai multe tipuri diferite de aplicații, arhitectura rămâne fundamental aceeași.

3.2 Serviciile

Serviciul este ceea ce serverul oferă clientului, atunci când răspunde la cererea clientului. De exemplu, în rețelele de telecomunicații inteligente (IN), serviciile oferite sunt: numere de telefon gratuite, mobile Number Portability (MNP) serviciul de portare a numărului și Number Translation Service (NTS) serviciul de translatare a numărului, televoting, servicii preplătite, VPN – Virtual Private Network, portabilitatea numerelor. Exemple din rețelele de calculatoare sunt: servicii web, serviciile de transfer de fișiere și servicii de baze de date

Servicii multimedia și conceptele de rețea

După cum se reflectă în termenul multimedia, serviciile noi ar necesita existența simultană a mai mult de un singur tip de informație. Din punct de vedere al rețelei, aceasta înseamnă că fie diferite tipuri de informații ar trebui să fie tratate ca un flux unic, fie că diferite fluxuri de informații care aparțin aceleiași sesiuni de utilizator ar trebui să fie păstrate sincronizate, astfel încât, aplicațiile să funcționeze corespunzător, între utilizatorii de comunicare. În primul caz, video, audio și datele sunt codificate de terminal și depuse la rețea ca un flux unic de informare, în timp ce, în al doilea caz, rețeaua oferă mecanisme de identificare și de manipulare a fluxurilor de informații corelate.

Presupunând că fiecare flux este transmis printr-o conexiune separată, existența mai multor fluxuri pentru o singură sesiune conduce la conceptul de mai multe apeluri multiconectate, o cerință ce este valabilă în general pentru comunicații multicast independent de modul în care sunt prezentate informațiile în rețea. În sesiunile de multicast un utilizator ar trebui să se poată conecta sau deconecta în orice moment, ceea ce înseamnă că fiecare conexiune individuală din cadrul unei sesiuni ar trebui să fie tratată ca o singură entitate.

O altă cerință ce decurge din natura serviciilor multimedia este interactivitatea și negocierea cu rețeaua și/sau de terminalele de recepție, care este considerată ca fiind capacitatea utilizatorului de a controla și modifica sesiunea sa nu numai în faza de stabilire și încheiere a conexiunii, dar și pe toată durata de viață a sesiunii. Un exemplu tipic este serviciul Video on Demand în care caz se presupune că utilizatorul navighează printre diferite surse video.

Protocolul Internet a fost inițial dezvoltat pentru a susține un simplu serviciu de transfer de date fiabil și fără orientare pe conexiuni, prin rețele locale (LAN) interconectate cu routere.

Quality of Service (QoS) a fost menținut prin protocoale de nivel superior ca TCP / IP, care oferă un mecanism de retransmitere a pachetelor, pentru a retransmite datele pierdute. Creșterea cererii pentru servicii multimedia în timp real și creșterea dramatică a Internetului a dus la conceptul de servicii integrate de Internet, care ar trebui să poată oferi în afară de livrarea garantată de pachete, alte cerințe QoS mai stricte, precum întârziere și sincronizare "end-to-end''. Pentru a face acest lucru, rețeaua ar trebui să recunoască și să manipuleze clase de servicii diferite, în timp ce utilizatorul să poată solicita un serviciu într-o clasă de calitate deosebită. Deoarece nu există nicio semnalizare pentru comunicare user- rețea la Internet, mai multe mecanisme de control au fost dezvoltate în acest scop.

Protocolul cu Rezervare de Resurse (RSVP) oferă mijloacele pentru cererea utilizatorului prin care solicită o anumită categorie de servicii și pentru a transfera acesta cerere la routerele de Internet care rezervă resursele de rețea corespunzătoare fluxului necesar.

În prezent, RSVP permite utilizatorului să aleagă între trei clase de servicii, fiecare oferind caracteristici QoS distincte. Serviciul "garantat" oferă o întârziere delimitate și nici o pierdere de transmisie pentru traficul conform, serviciul „încărcare controlată” tolerează puține pierderi, garantând o de lățime de bandă minimă și este orientată spre aplicații care se adaptează la întârziere, în timp ce serviciul „best effort” nu oferă nici o garanție și este adecvat pentru serviciile care se adaptează la întârziere și lățimea de bandă disponibilă.

3.4 Serviciile în telecomunicații

Inteligența permite unui sistem să exploateze capacitățile sale de bază pentru a îmbogăți setul de servicii oferite. Rețeaua de telefonie oferă o facilitate simplă de comutație și nu este potrivită pentru introducerea de rutări noi, de capacități de tarifare și de translație de numere într-un mod de sine stătător, fără ajutor. Disponibilitatea switch-urilor controlate prin program a deschis calea introducerii serviciilor bazate pe comutație, numite servicii suplimentare, subliniind în același timp, potențialul și limitele acestui tip de soluție. Prestarea de servicii suplimentare impune modificarea și îmbogățirea procesării de bază a apelurilor, efectuate de switch-uri ce furnizează serviciul de apelare, în toate nodurile care suportă noile funcționalități.

Ideea fundamentală din spatele IN este de a plasa inteligența cerută necesară pentru furnizarea unui serviciu complex în servere IN dedicate, în loc să modifice software-ul de prelucrare a apelului în fiecare switch din rețea. Procedând astfel, funcționalitatea switch-ului este limitată la prelucrarea de bază a apelului, având în plus, la identificarea apelării unor servicii IN și la rutarea acestor apeluri la serverul IN. Prima soluție a fost pusă în aplicare în Statele Unite la începutul anilor 80 pentru a sprijini serviciul numărului verde. Serviciul Numărul Verde, numit și serviciul 800, permite părții apelate prin intermediul numărului 800 să plătească pentru costul apelurilor primite. Cum un număr mare de servicii poate fi furnizat combinând componente de servicii de nivel scăzut, un răspuns bun la această problemă este standardizarea componentelor serviciilor.

Suportul adecvat de rețea pentru serviciile multimedia necesită o arhitectură mai abstractă decât standardele IN actuale. Aici se poate deja vorbi de arhitectura IMS, care adaugă serviciile multimedia pentru rețelele cu comutație de pachete.

3.5 Managementul rețelelor de comunicații mobile

Telecommunication Management Network este un model de protocol definit de ITU-T pentru gestionarea unor sisteme deschise într-o rețea de comunicații. Acesta face parte din seria M.3000 a recomandării ITU-T și se bazează pe specificațiile de management OSI în recomandările ITU-T seria X.700 (figura 3-1).

TMN oferă un cadru pentru realizarea de interconectări și comunicații între sisteme eterogene de operare și rețelele de telecomunicații. Pentru a realiza acest lucru, TMN definește un set de puncte de interfață pentru elementele care efectuează procesarea efectivă a comunicațiilor (cum ar fi o centrală de procesare a apelurilor) pentru a fi accesate de către alte elemente, cum ar fi stații de lucru de management, pentru monitorizarea și controlul acestora. Interfața standard permite ca entitățile de la diferiți producători să fie încorporate într-o rețea sub un control de management unic.

Figura 3-1 Modelul de

management al rețelelor de comunicații

Pentru comunicarea între sistemele de management și NE (elemente de rețea), se folosește protocolul comun de gestionare a informațiilor.

Serviciilor se ocupă de crearea, administrarea și contorizarea serviciilor. Nivelul de management al Rețelei are funcțiile de alocare a resurselor distribuite: configurare, monitorizare și control. Nivelul de management al Elementelor de Rețea face comanda nodurilor de rețea – transmiterea, colectarea și procesarea informațiilor (înregistrări) de stare (inclusiv alarme) în vederea automatizării mentenanței hardware și software.

TMN-ul prezintă cinci funcții de bază: managementul erorilor (FM – Fault Management detecție, înregistrare, raportare, izolare), managementul conturilor (AM – Account Management colectarea, salvarea și livrarea informațiilor de contorizare și de plată), managementul performanțelor (PM – Performance Management, colectarea, salvarea și livrarea datelor statistice de funcționare, în vederea optimizării rețelei), managementul configurațiilor (CM – Configuration Management instalarea echipamentului de rețea, setarea de parametri, configurarea capacităților utilizate), managementul securității (SM – Security Management administrarea funcțiilor de autorizare și de acces multiplu, protecția la intruziune).

Datele oferite de sistemele de management al rețelelor pot fi utilizate ulterior pentru postprocesare în sisteme SPOTS (Suport, Planificare, Operare & mentenanță și analiza Traficului în Sistem) și pentru optimizarea serviciilor oferite abonaților, după cum este propus în capitolul 6.

Un protocol utilizat în TMN este SNMP. În utilizarea tipică a SNMP, există o serie de sisteme care sunt gestionate și unul sau mai multe sisteme de gestionare a acestora. O componentă software numită agent rulează pe fiecare sistem gestionat și raportează informațiile, prin intermediul SNMP la sistemele de gestionare. În esență, agenții SNMP expun datele de gestionare a sistemelor administrate sub formă de variabile (cum ar fi "memorie liberă", "numele de sistem", "numărul de procesele", "ruta default"). Configurarea și operațiunile de control sunt utilizate numai atunci când schimbările sunt necesare pentru infrastructura de rețea. Operațiunile de monitorizare sunt de obicei efectuate în mod regulat.

SNMP folosește un design extensibil, în care caz informațiile disponibile sunt definite în baze de informații de gestiune (management information bases – MIB). MIB-ul descrie structura de gestionare a datelor unui subsistem al unui obiect; el utilizează un spațiu de nume ierarhic care conține identificatori obiect (OID). Se poate spune că fiecare OID identifică o variabilă sau un set ce poate fi citit prin SNMP. MIB-ul utilizează notația definită de ASN.1. În domeniul telecomunicațiilor și al rețelelor de calculator, Abstract Syntax Notation One (ASN.1) este un standard de notație flexibil, care descrie structuri de date pentru reprezentarea, codificarea, transmiterea, precum și decodare datelor.

ASN.1 este un standard comun ITU-T și ISO, inițial definit în 1984, ca parte a CCITT X.409: 1984. ASN.1 a primit propriul său standard, X.208, în 1988 (revizuit în 1995) din cauza aplicabilității largi., versiunea actuală este seria X.680. Un subgrup adaptat ASN.1, Structura de Management al Informației (SMI), este specificată în SNMP pentru a defini seturi de obiecte legate de MIB; aceste seturi sunt numite module de MIB.

Un sistem de management de rețea (SNM) execută aplicații de monitorizare și control al dispozitivelor gestionate. NMS-urile execută cea mai mare parte a prelucrării și folosește cea mai mare parte a resurselor de memorie necesare pentru gestionarea rețelei.

Aceste date furnizate de sistemul TMN, prin intermediul serviciilor SPOTS, utilizând protocoale SNMP și Q3 vor fi utilizate ca date de intrare (opționale) pentru serviciul de decizie de handover prezentat în capitolul 6. Acesta este implementat pe platforma telecom ATCA ce este prezentată în continuare.

3.6 Integrarea de servere și servicii pe ATCA

Pe platforma ATCA au implementate componentele unui sistem IMS, bazat pe pachetul open-source OpenIMS. 3GPP a standardizat funcții în loc de noduri, astfel arhitectura IMS este o colecție de funcții interconectate prin interfețe standard. Se poate observa că terminalul folosește o legătură radio pentru a se atașa la rețea și că IMS suportă și alte tipuri de metode de acces. De exemplu PDA-urile se pot conecta la IMS, iar WLAN, ADSL, UMTS sau HSDPA sunt metode de acces.Arhitectura IMS se află în teste de integrare și îmbunătățire cu mai mulți operatori din întreaga lume. De aceea eforturile de cercetare și dezvoltare relative la NGN (Next Generation Networks) vor capta atenția unei audiențe mari, în special în aria dezvoltare a serviciilor. Componentele OpenIMS sunt: Proxy Call Session Control Function, Interogating Call Session Control Function, Serving Session Control Function, Home Subscriber Service și serverul de aplicații.

Dacă în domeniul VoIP există mai multe proiecte open-source pentru clienți SIP, servere VoIP, cum ar fi Asterisk, toate bazate pe standardele IETF, în cadrul IMS, până la apariția OpenIMS Core, nu exista nici un proiect open-source. Proiectul OpenIMS Core implementează funcțiile de control al sesiunii (CSCF-urile) și un HSS minimal, care împreună, formează nucleul tuturor arhitecturilor IMS/NGN specificate de 3GPP, 3GPP2 și ETSI TISPAN. Cele patru componente sunt bazate pe soluții gratuite (SIP Express Router sau MySQL).

Funcțiile de control a sesiunii sunt bazate pe proiectul open-source SER (SIP Express Router) și reprezintă o extensie a acestuia. SER este un server SIP de înaltă performanță și configurabil aflat sub licența open-source GNU GPL. Se poate comporta ca o autoritate de înregistrare, server de redirectare și poate fi configurat pentru roluri special, cum ar fi load balancing sau interfață către anumite servere de aplicații.

Proiectul OpenIMS are la bază trei componente, bazate pe SER, pcscf, icscf și scscf.

SER pcscf este punctul de graniță între nucleul arhitecturii IMS și utilizator. Numai utilizatorii înregistrați au dreptul de a introduce mesaje în nucleu. SER icscf și SER scscf sunt conectate la FHoSS prin interfața Cx. Modulele SER comunică între ele prin interfața Mw folosind SIP.

Evaluarea comportării fiecărei entități a fost făcută prin studiul unor scenarii specifice standardelor IMS, prin analiză de protocol. Arhitectura studiată se poate segmenta în trei nivele logice: nivelul utilizatorului, cel al platformei OpenIMS și cel corespunzător serverelor de aplicații. Pentru realizarea studiului componentelor nivelului platformei IMS s-au configurat clienți la nivelul utilizatorului și servere de aplicații la nivelul corespunzător.

Platforma OpenIMS este foarte extensibilă, ceea ce permite dezvoltarea altor componente specifice NGN. La nivelul serverelor de aplicații se poate atașa orice tip de server ce poate procesa mesaje SIP, și ideal, și negociere Diameter pentru o emulare cât mai aproape de platformele existente a interfeței Sh. SIP este folosit pentru a mapa adresa IP, la care poate fi găsit utilizatorul, din identitatea publică a utilizatorului respectiv.

3.7 Tehnici de programare a serviciilor și integrare business

În paragraful de față propun programarea serviciilor pe baza BPEL (Business Process Execution Language), în cadrul uni concept larg, tot mai răspândit în telecomunicații – „integrarea business”. Această tendință actuală urmează după recenta „integrarea IT” – a rețelelor de calculatoare cu rețelele de comunicații – posibilă datorită comutației unificate (pe care am ilustrat-o prin implementarea în ATCA, prezentată în capitolul 2) și a tehnicilor de comutare a fluxurilor multimedia („streaming”) – pe care am orientat majoritatea studiilor de caz și a părților experimentale ale acestei lucrări de doctorat.

Această secțiune prezintă principalele concepte SOA și oferă o scurtă prezentare a BPEL. Folosind BPEL, în capitolul 6 se va implementa un serviciu pentru Management bazat pe QoS în Comunicații Mobile în Multi-modale.

Portabilitatea serviciilor dezvoltate este unul din avantajele principale – soluția dezvoltată cu BPEL trebuie sa fie portabilă intre diferite sisteme de operare și platforme.

Utilizând această abordare SOA, se poate lua un serviciu de evaluare QoS care a fost dezvoltat deasupra infrastructurii de comunicații mobile existente, și integra într-un proces de afaceri care oferă realocarea de trafic. Pentru design-ul acestui proces se va utiliza BPEL. BPEL (The Business Process Execution Language) este un limbaj bazat pe XML și oferă întreprinderilor un standard industrial pentru orchestrația și execuția procesului de afaceri. Folosind BPEL, un proces de afaceri care integrează o serie de servicii discrete este proiectat într-un flux de procese de tip end-to-end. BPEL se bazează pe schema XML, pe protocolul SOAP, precum și pe Web Services Description Language (WSDL). Fiecare componentă permite executarea unui set specific de sarcini: mediul de proiectare (JDeveloper BPEL Designer sau Eclipse BPEL Designer) permite proiectarea și instalarea proceselor BPEL. Când proiectarea este completă, procesul este implementat din mediul de proiectare în serverul Oracle BPEL. Dacă implementarea reușește, procesul BPEL poate fi gestionat din consola Oracle BPEL.

4 Algoritmii QoS în comunicațiile mobile

În prezent, algoritmii calității serviciilor (QoS) pot fi găsiți aproape peste tot și mai ales în domeniile în care resursele disponibile sunt limitate și se intenționează maximizarea utilizării resurselor. Un astfel de domeniu este cel al telecomunicațiilor mobile.

În domeniul rețelelor cu comutație de pachete și rețele informatice, termenul de calitatea serviciilor – Quality of Service (QoS) în ingineria traficului se referă la probabilitatea rețelei de telecomunicație de a satisface un anumit contract de trafic, sau, în multe cazuri, este folosit informal pentru a se referi la probabilitatea reușitei unui pachet de a trecere prin două puncte din rețea în perioada de latență dorită.

În domeniul telefoniei, calitatea serviciilor de telefonie QoS a fost definită de ITU ca efectul cumulativ al tuturor imperfecțiunilor care afectează o conversație telefonică asupra satisfacției abonatului. Această definiție include în evaluare factorul uman și implica o ponderare subiectiv adecvată a diverselor defecte, cum ar fi zgomotul și tonurile de pe circuit, nivelul volumului, ecouri sesizabile, etc. și include nivelul de serviciu.

Odată cu apariția rețelelor de telefonie digitale, au apărut noi tipuri de deficiențe, cum ar fi efectele erorilor de biți în codec-uri, împreună cu o tendință de a exprima QoS din punct de vedere al parametrilor de inginerie, care pot fi măsurați în mod obiectiv, eliminând incertitudinea cu privire la subiectivitatea umană.

4.1 Probleme legate de calitatea serviciilor (QoS)

Pe măsură ce călătoresc de la origine la destinație, pachetele pot trece prin situații multiple care se pot clasifica în următoarele probleme: pachete pierdute, întârzieri, jitter, livrare out-of-order și erori.

4.2 Mecanismele pentru asigurarea QoS

Calitatea serviciilor poate fi asigurată prin supradimensionarea generoasă a rețelei, astfel încât liniile interioare să fie considerabil mai rapide decât liniile de acces. Această abordare este relativ simplă și poate fi fezabilă din punct de vedere economic pentru rețele de bandă largă cu încărcări de trafic ușoare și previzibile. Performanța este rezonabilă pentru multe aplicații, în special pentru cele de natură să tolereze jitter mare.

Serviciile comerciale VoIP sunt adesea competitive în raport cu serviciul de telefonie tradițional, în ceea ce privește calitatea apelului, chiar dacă, de obicei, mecanismele de QoS nu sunt utilizate la conectarea utilizatorului la ISP-ul său și la conexiunea furnizorului de VoIP la un ISP diferit. Cu toate acestea, în condiții de încărcare mare, calitatea VoIP scade la calitatea celularului sau chiar mai rău. Matematica traficului de pachete de date indică faptul că o rețea cu QoS poate suporta de patru ori mai multe apeluri cu cerințele de jitter stricte decât o rețea fără QoS. Măsura în care se face supradimensionarea în liniile interioare necesară înlocuirii QoS depinde de numărul de utilizatori și cerințele lor de trafic. Deoarece Internet-ul a ajuns acum la peste un miliard și jumătate de utilizatori, șansele ca supradimensionarea să elimine nevoia de QoS sunt mici din moment ce VoIP și serviciile video devin tot mai frecvente.

Inițial s-a utilizat filozofia "IntServ" de a rezerva resurse de rețea. În acest model,

aplicațiile foloseau Protocolul de Rezervare Resurse (Resource Reservation Protocol RSVP) pentru a solicita și rezerva resursele rețelei. A doua abordare și cea acceptată în prezent este "DiffServ" sau servicii diferențiate. În modelul Diffserv, pachetele sunt marcate în funcție de tipul de serviciu de care acestea au nevoie. Ca răspuns la aceste marcaje, routerele și switch- urile utilizează strategii diferite de așteptare pentru a se adapta la cerințele de performanță. (La nivelul de IP, marcajele differentiated services code point (DSCP) utilizează cei 6 biți din antetul pachetului IP. La nivelul MAC, se poate utiliza VLAN, IEEE 802.1Q, MPLS și IEEE

802.1D pentru a transporta, în esență, aceleași informații).

4.3 Algoritmi de formare a traficului: „Leaky bucket” și „Token Bucket”

Algoritmul găleții care curge „Leaky bucket” poate fi înțeles conceptual după cum urmează: pachetele sosite (network layer PDUs) sunt plasate intr-o găleată care este găurită în partea de jos. Găleata poate pune în coada de așteptare cel mult b octeți. Dacă un pachet sosește când găleata este plină, pachetul este eliminat. Pachetele se scurg prin gaura din găleată în rețea la o rata constanta de r octeți pe secundă, nivelând astfel vârfurile de trafic.

Dimensiunea „b” a găleții este limitată de memoria disponibilă a sistemului. Algoritmul

„Generic Cell Rate” utilizat în modelarea traficului rețelelor ATM este echivalent cu algoritmul găleții care curge.

Implementarea algoritmului Leaky-bucket nu folosește eficient resursele disponibile în rețea. Deoarece rata de scurgere este un parametru fix, sunt multe cazuri în care volumul traficului poate fi foarte scăzut și mari porțiuni din resursele de rețea (în special, lățimea de bandă) să nu fie utilizate. Prin urmare, nu există niciun mecanism în acestui algoritm care să permită fluxurilor individuale să accelereze până la viteza de port și să consume în mod eficient resursele de rețea atunci când acestea nu sunt disputate. Implementarea găleții cu jetoane suportă, cu toate acestea, fluxurile de trafic cu caracteristici de rafală. Implementările galeții care curge și a galeții cu jetoane pot fi combinate pentru a oferi un maxim de control și eficientă în fluxurile de trafic dintr-o rețea.

Algoritmul găleții cu jetoane este similar în anumite privințe cu algoritmul găleții care curge dar diferența primară este aceea ca găleata cu jetoane permite traficului în rafale să-și continue cursul până la parametrul de revărsare al găleții. Găleata cu jetoane este un mecanism de control care dictează când poate fi transmis traficul, în funcție de prezența jetoanelor în găleată. Găleata cu jetoane conține jetoane, fiecare dintre ele reprezentând o unitate de biți. Administratorul de rețea specifică numărul de jetoane necesar pentru a transmite un anumit număr de biți; atunci când jetoanele sunt prezente, un flux este permis pentru transmiterea de date. În cazul în care nu există jetoane în găleată, un flux nu poate transmite pachetele sale. Prin urmare, un flux poate transmite pachete până la vârful ratei de revărsare dacă în găleată există jetoanele corespunzătoare și dacă pragul de revărsare este configurat corespunzător.

Algoritmul poate fi înțeles din punct de vedere conceptual, după cum urmează: un jeton este adăugat în găleată la fiecare 1 / r secunde. Găleata poate suporta maxim b jetoane. Dacă un jeton sosește când găleata este plină, acesta este eliminat. Când sosește un pachet (PDU la nivel de rețea) de n octeți, din găleată sunt scoase n jetoane, iar pachetul este trimis în rețea. În cazul în care mai puțin de n jetoane sunt disponibile, niciun jeton nu este eliminat din găleată, iar pachetul este considerat a fi non-conform.

Algoritmul permite vârfuri de până la b octeți, dar pe termen lung, transmiterea de pachete conforme este limitată la rata constantă r. Pachetele non-conforme pot fi tratate în diverse moduri: abandonate, puse în coada de așteptare pentru transmiterea ulterioară în momentul în care s-au acumulat în găleată suficiente jetoane sau transmise, dar marcate ca fiind non-conforme, cu posibilitatea ulterioară de a le elimina dacă rețeaua este supraîncărcată.

4.4 Servicii diferențiate (DiffServ)

Deoarece rețelele moderne de date transportă multe tipuri de servicii, de la voce, video, streaming de muzică, pagini web și email, multe dintre mecanismele QoS propuse care au permis acestor servicii să coexiste erau atât complexe cât și incapabile să răspundă cerințelor Internetului public. Pentru a contracara această problemă, în 1998, IETF a publicat RFC 2475 arhitectura DiffServ.

Diffserv este un mecanism de gestionare a traficului, bazat pe clase, fără să intre în detaliile fluxurilor de date pe care le procesează. În contrast, IntServ este un mecanism detaliat, bazat pe flux. Decât să diferențieze traficului în rețea, pe baza cerințelor unui flux individual, Diffserv funcționează pe principiul clasificării traficului, fiecare pachet de date fiind plasat într-un număr limitat de clase de trafic. Fiecare router din rețea este configurat să diferențieze traficul în funcție de clasa sa. Fiecare clasă de trafic poate fi gestionată în mod diferit, asigurând un tratament preferențial pentru traficul cu prioritate crescută din rețea.

Modelul Diffserv nu alege căror tipuri de trafic trebuie să li se acorde prioritate, deoarece acest lucru este lăsat la latitudinea operatorului de rețea. Diffserv oferă, pur și simplu, un cadru care să permită clasificarea și tratamentul diferențiat.

Diffserv recomandă totuși un set standardizat de clase de trafic (discutate mai jos) pentru a face mai simplă interoperabilitatea între rețele diferite și echipamente diferite ale furnizorilor. Un grup de routere care implementează politici comune definite administrativ DiffServ sunt denumite Domeniu DiffServ.

Traficul de rețea care intră într-un domeniu Diffserv este supus clasificării și de condiționării. Traficul poate fi clasificat de către mai mulți parametri diferiți, cum ar fi adresa sursă, adresa de destinație sau de tipul de trafic și încadrat într-o anumită categorie de trafic. Clasificatorii de trafic pot onora orice marcaj Diffserv în pachetele primite sau pot alege să ignore sau să treacă peste aceste marcaje. Traficul din fiecare clasă poate fi în continuare condiționat de supunerea acestuia la limitatori de rată, monitori de trafic sau modelatori.

Comportamentul Per-Hop este indicat codând o valoare de 6 biți – numită Differentiated Services Code Point (DSCP) în câmpul de 8 biți de Servicii Diferențiate (DS) ai antetului pachetului IP. În teorie, o rețea ar putea avea până la 64 (26) clase de trafic diferite folosind marcaje diferite în DSCP. RFC Diffserv recomandă, dar nu cer, anumite codificări care oferă unui operator de rețea o flexibilitate mare în definirea claselor de trafic. În practică, însă, cele mai multe rețele utilizează în mod frecvent următoarele comportamente Per-Hop: Default PHB – care este de obicei traficul best-effort, Expedited Forwarding (EF) PHB – pentru pierderi mici, latență scăzută în trafic, Assured Forwarding (AF) – grup ce asigură livrarea pachetelor cât timp acestea respectă rata subscrisă și Class Selector PHBs – care sunt prevăzuți să mențină compatibilitatea inversă cu domeniul de precedență IP

Pentru a preveni problemele asociate cu eliminarea cozii, adesea se utilizează algoritmi de detectare aleatorie (RED) sau detectare aleatorie ponderată (WRED) pentru eliminarea de pachete. De obicei, traficul de modelare este necesar pentru a codifica precedența de eliminare. În mod obișnuit, traficului alocat unei clase ii este inițial acordat o precedență de eliminare scăzută. Pe măsură ce rata de trafic depășește pragurile subscrise, policer-ul va crește precedența de eliminare a pachetelor ce depășesc pragul.

Înaintea Diffserv, rețelele IP puteau folosi câmpul de precedență în octetul Type of Service (TOS) din antetul IP pentru a marca traficul prioritar. Octetul TOS și precedența IP nu au fost utilizate pe scară largă. IETF a fost de acord să reutilizeze octetul TOS ca DS pentru rețelele Diffserv. În scopul de a menține compatibilitatea inversă cu dispozitivele de rețea care încă utilizează câmpul Precedenta, Diffserv definește clasa Selector PHB. Codepoint-urile Class Selector sunt de forma "xxx000". Primii trei biți sunt biți de precedență IP. Fiecare valoare de precedență IP poate fi mapată într-o clasă Diffserv. În cazul în care un pachet este primit de la un router care nu suporta Diffserv și care a utilizat markeri de precedență IP, routerul Diffserv poate înțelege în continuare codificarea ca un codepoint Class Selector. Un flux de date care arată principiul Diffserv poate fi văzut în figura următoare:

Un avantaj al Diffserv este că toată modelarea și clasificarea se face la granițele dintre norii Diffserv. Acest lucru înseamnă că, în nucleul Internet-ului, routerele pot continua rutarea, fără a le păsa de complexitatea obținerii plăților sau de executarea acordurilor.

Un dezavantaj este acela că, detaliile despre modul în care fiecare router face față unui domeniu de servicii este oarecum arbitrar și este dificil de prezis comportamentul end-to-end (de la un capăt la altul). Acest lucru este complicat suplimentar dacă un pachet traversează doi sau mai mulți nori Diffserv înainte de a ajunge la destinație.

Cel mai mare dezavantaj al Diffserv este că, la cel mai înalt nivel, el poate fi privit ca o soluție tehnică pentru o problemă care nu există. Deoarece Diffserv este pur și simplu un mecanism folosit pentru a decide care pachete să fie întârziate și care eliminate, în detrimentul altora, în situația în care nu există suficientă capacitate în rețea, se consideră că, atunci când Diffserv lucrează prin eliminarea selectivă a pachetelor, traficul de pe legătura în cauză trebuie să fie deja foarte aproape de saturație.

Orice creștere ulterioară a traficului va duce la eliminarea serviciilor de tip best-effort. Deoarece traficul pe Internet este foarte fluctuant, este destul de sigur ca acest lucru să se întâmple în mod regulat în cazul în care traficul pe o legătură este aproape de limita de la care Diffserv devine necesar.

Prin urmare, Diffserv este, pentru cei mai mulți ISP, în principal, un mod de araționaliza utilizarea rețelei de către client pentru a permite o supra-rezervare mai mare a capacității lor.

4.5 Servicii integrate (IntServ)

În rețelele de calculatoare, IntServ sau serviciile integrate sunt o arhitectură care specifică elementele care garantează calitatea serviciilor (QoS) în rețele. IntServ, de exemplu, poate fi folosit pentru a permite ca fluxul video și cel audio să ajungă la receptor fără întrerupere. IntServ specifică un sistem QoS detaliat, care este adesea în contrast cu sistemul de control Diffserv mai puțin detaliat.

Ideea IntServ este aceea ca fiecare router din sistemul implementează IntServ și fiecare aplicație care necesită un fel de garanții trebuie să facă o rezervare individuală. "Flow Specs" descrie pentru ce este rezervarea, în timp ce "RSVP" este mecanismul de bază pentru a-l semnala de-a lungul rețelei.

Resource ReSerVation Protocol (RSVP) este descris în RFC 2205. Toate mașinile din rețea, capabile să transmită date QoS trimit un mesaj PATH la fiecare 30 de secunde, care se răspândește prin intermediul rețelelor. Cei care vor să le asculte trimit un mesaj RESV corespunzător (prescurtarea de la "reserve") care apoi urmează calea înapoi la expeditor. Mesajul RESV conține specificațiile de debit.

Routerele între expeditor și receptor trebuie să decidă dacă acestea pot suporta rezervarea solicitată și, în cazul în care ele nu pot, trimite un mesaj de respingere la receptor pentru a-l informa. În caz contrar, odată ce accepta rezervarea, trebuie să efectueze traficul.

Routerele apoi păstrează descrierea fluxului și, de asemenea, un set de politici asociate.

Dacă nu se recepționează nimic pentru o anumită perioadă de timp, atunci cititorul va expira și rezervarea va fi anulată. Aceasta rezolvă problema pentru cazul în care expeditorul sau receptorul sunt opriți în mod incorect, fără a anula rezervarea. Routerele individuale pot alege setul de politici de trafic pentru a verifica dacă el este conform cu specificațiile de debit.

Problema cu IntServ constă în faptul că multe stări trebuie să fie stocate în fiecare router. Ca rezultat, IntServ lucrează la o scară mică, dar pe măsură ce se trece la un sistem de dimensiunea Internetului, devine dificilă urmărirea tuturor rezervărilor. Ca urmare, IntServ nu este foarte popular.

O cale de a rezolva această problemă este utilizarea abordării multi-nivel, în care rezervarea resurselor per-microflow (de exemplu, rezervări de resurse pentru utilizatorii individuali) se face în rețeaua de margine, în timp ce, în rețeaua de bază, resursele sunt rezervate numai pentru fluxurile agregate. Routere care se află între aceste niveluri diferite trebuie să se adapteze la lățimea de bandă totală rezervată de la rețeaua centrală, astfel încât, cererile de rezervare pentru fluxurile individuale din rețeaua de margine să poate fi satisfăcute mai bine. A se vedea RFC 3175.

În mod tradițional, aceste servicii diferite au fost realizate prin intermediul rețelelor separate: voce pe rețeaua de telefonie, datele privind rețele de calculatoare sau rețele locale (LAN), teleconferințe video de pe rețele corporative private, precum și de televiziune, difuzate la radio sau prin rețele de cablu. Aceste rețele sunt, în mare parte, proiectate pentru o anumită aplicație și nu sunt potrivite pentru alte aplicații.

De exemplu, rețeaua de telefonie tradițională este prea zgomotoasă și ineficientă pentru comunicarea de date în burst-uri (dar totuși pentru ultima porțiune, la majoritatea furnizorilor încă se folosesc firele de cupru tradiționale cu tehnologii ca xDSL). Rețelele de televiziune care folosesc mediul radio sau cablul sunt rețele cu emisie masivă, dar cu facilități minime de comutare.

Este de dorit să existe o singură rețea pentru furnizarea tuturor acestor servicii de comunicații în scopul de a realiza economii de partajare. Aceasta economie motivează ideea generală a unei rețele integrate de servicii. Integrarea evită nevoia de rețele suprapuse, ceea ce complică gestionarea rețelei și reduce flexibilitatea în introducerea și evoluția serviciilor. Această integrare este posibilă o dată cu progresele în domeniul tehnologiilor de bandă largă și de procesare de mare viteză a informațiilor.

Deși există structuri de rețea care pot întreține servicii în bandă largă, un procent tot mai mare de bandă largă și furnizorii de MSO optează pentru structurile de rețea pe fibră optică pentru a sprijini atât cerințele de lățime de bandă prezente cât și viitoare.

Rețelele moderne trebuie să transporte trafic integrat care constă în voce, video și date.

Tipurile de trafic susținute de o rețea de bandă largă pot fi clasificate în funcție de trei caracteristici: lățime de bandă (bandwidth), latență, variația întârzierii (Cell-delay variation – CDV).

4.6 Asynchronous Transfer Mode – ATM

ATM a fost menit să asigure un standard de rețea unificat, care ar putea sprijini atât rețelele cu canal sincron (PDH, SDH) cât și rețeaua bazată pe pachete (IP, Frame Relay, etc), în timp ce susține mai multe niveluri de calitate a serviciului pentru traficul de pachete.

Ca rezultat, ATM oferă o tehnologie extrem de complexă, cu caracteristici destinate aplicațiilor care variază de la rețelele globale de telecomunicații la rețele private locale de calculatoare. ATM a fost un succes parțial ca tehnologie, cu răspândire pe scară largă, dar în general utilizat numai ca transport pentru traficul IP; scopul său, de a oferi o tehnologie unică integrată pentru LAN-uri, rețele publice și serviciile de utilizator a eșuat în mare măsură. În momentul de față ATM este utilizat în „backbone-urile” multor operatori de rețele de telefonie mobilă, fiind utilizate pentru semnalizare, date de voce și trafic (planul de utilizator IP ).

ATM este un nivel de transport bazat pe canale. Acest lucru este cuprins în conceptul de cale virtuală (VP) și circuit virtual (VC). Fiecare celulă ATM are o pereche Virtual Path Identifier de 8 sau 12-biți (VPI) și Virtual Circuit Identifier de 16-biți (VCI) definită în antetul său. Lungimea VPI variază în funcție de destinație, dacă celula este trimisă pe interfața de rețea (pe marginea rețelei) a utilizatorului, sau dacă este trimisă pe interfața de rețea a rețelei (în interiorul rețelei). Pe măsură ce aceste celule traversează o rețea ATM, trecerea se realizează prin schimbarea valorilor VPI / VCI. Deși valorile VPI / VCI nu sunt neapărat consecvente de la un capăt la celălalt al conexiunii, conceptul unui circuit este coerent (spre deosebire de IP, caz în care fiecare pachet ar putea ajunge la destinație printr-o cale diferită de a celorlalte pachete). Un alt avantaj al utilizării de circuite virtuale este posibilitatea de a le folosi ca pe un strat de multiplexare, care să permită diferitelor servicii (cum ar fi voce, frame relay, IP, SNA, etc) să partajeze o conexiune ATM comună, fără a interfera.

Un alt concept ATM cheie este cel al contractului de trafic ATM ce fac parte din

mecanismul prin care este asigurată "Quality of Service" (QoS). Există patru tipuri de bază (și mai multe variante), fiecare cu câte un set de parametri care descriu conexiunea: CBR – rata de biți constantă, VBR – rata de biți variabilă, ABR – rata de biți disponibilă, UBR – rată de biți nespecificată, VBR – are variante în timp real și în timp non-real.

Majoritatea claselor de trafic introduc și conceptul de toleranță la variația întârzierii celulelor (Cell Delay Variation Tolerance CDVT), care definește "aglomerarea" celulelor în timp. Contractele de trafic sunt de obicei menținute prin utilizarea de "Shaping" (formare), o combinație de așteptare și de marcare de celule și aplicate de către "Policing” (politică).

Formarea traficului se face de obicei la punctul de intrare într-o rețea ATM și încearcă să se asigure că fluxul de celule va îndeplini contractul său de trafic. Pentru a menține performanța rețelei este posibil să se reducă parametrii unor circuite virtuale împotriva contractelor lor de trafic. În cazul în care un circuit depășește contractul său de trafic, rețeaua poate fie să elimine celulele, fie să marcheze bitul Cell Loss Priority (pentru a identifica o celulă ca fiind ''de eliminat''). Politica de bază funcționează pe principiul celulă cu celulă, dar acest mod de lucru este sub nivelul optim pentru traficul de pachete încapsulate (deoarece eliminarea unei singure celule invalidează întreg pachetul). Ca urmare, scheme ca Partial Packet Discard (PPD) sau Early Packet Discard (EPD) au fost create pentru a renunța la o serie de celule, pana la începerea unui nou cadru.

Acest lucru reduce numărul de celule redundante în rețea, economisind lățime de bandă pentru cadrele complete. EPD și PPD lucrează cu conexiuni AAL5 deoarece utilizează bitul de la sfârșitul cadrului pentru a detecta sfârșitul pachetelor.

4.7 Multiprotocol Label Switching (MPLS)

În crearea de rețele informatice și de telecomunicații, Multiprotocol Label Switching (MPLS) este un mecanism de suport de date care emulează unele proprietăți ale unei rețele cu comutație de circuite peste o rețea cu comutație de pachete. MPLS funcționează la un nivel de model OSI, care este considerat în general că se întinde între definițiile tradiționale ale nivelului 2 (nivelul legăturii de date) și nivelului 3 (nivelul de rețea) și astfel, adeseori este menționat ca fiind protocol de "nivel 2.5". Acesta a fost proiectat pentru a oferi un serviciu unificat de suport de date atât pentru clienții pentru comutația de circuite cât și pentru clienții pentru comutația de pachete ce oferă un model de serviciu de datagrame. Acesta poate fi folosit pentru a transporta mai multe tipuri de trafic, inclusiv pachete IP, precum și ATM, SONET și cadre Ethernet.

Figura 4-5 Antetul MPLS

O prima motivație în proiectarea MPLS a fost aceea de a permite crearea de switch-uri de mare viteză simple, deoarece, pentru o lungă perioadă, a fost imposibil să se transmită pachete IP în întregime în hardware. Totuși progresele în VLSI au făcut posibile astfel de dispozitive. Avantajele sistemice ale MPLS, cum ar fi capacitatea de a suporta mai multe modele de servicii, de a gestiona traficul, etc., rămân valabile.

MPLS acționează prin adăugarea la începutul pachetelor a unui antet MPLS, care conține una sau mai multe "etichete". Aceasta se numește o stivă de etichete. Fiecare intrare din stiva de etichete conține patru câmpuri: o etichetă de valoare de 20 de biți, un câmp de 3 biți pentru prioritatea QoS, un bit „sfârșitul stivei”și un câmp TTL (timp de viață) de 8 biți. Aceste pachete MPLS etichetate sunt transmise (comutate este termenul corect) după o căutare în tabela de etichete, în locul unei interogări în tabela de rutare IP. Căutarea de etichetă și comutarea de etichete pot fi mai rapide decât obișnuita interogare a tabelei de rutare, pentru că pot avea loc direct în hardware și nu în CPU.

Când un pachet etichetat este primit de către un router MPLS, este examinată eticheta cea mai de sus. Pe baza conținutului etichetei, o operație de swap (schimbare), push (punere) sau pop (scoatere) poate fi efectuată pe stiva de etichete a pachetului. Routere pot avea tabele de căutare predefinite care, în funcție de eticheta cea mai de sus a pachetului care intră, le spune ce tip de operațiune sa facă, astfel încât routerele să poată procesa pachetele foarte repede. Forwardarea pachetului se face pe baza conținutului etichetelor. La routerul de tip egress, atunci când ultima etichetă a fost scoasă, rămân doar datele. Acesta poate fi un pachet IP, sau oricare dintre o serie de alte tipuri de pachete de date. Routerul de tip egress trebuie să aibă, prin urmare, informații de rutare pentru datele pachetelor, deoarece acesta trebuie să le transmită fără ajutorul unor tabele de căutare a etichetelor. Un router de tranzit MPLS nu are nici o astfel de cerință. În unele cazuri speciale, ultima etichetă poate fi de asemenea scoasă la penultimul nod (nodul anterior router-ului de tip egress). Aceasta se numește „Penultimate Hop Popping” (PHP). Acest lucru poate fi interesant în cazurile în care router-ul de tip egress are multe pachete care părăsesc tunele MPLS, consumând astfel cantități mari de timp de procesare. Prin folosirea PHP, routerele de tranzit conectate direct la acest router de tip egress reduc din încărcare, eliminând singure ultima etichetă. MPLS poate utiliza infrastructuri de rețea ATM existente, întrucât fluxurile sale etichetate pot fi mapate la identificatorii de circuite ATM virtuale și viceversa.

4.8 QoS în rețelele de comunicații mobile

Ultimele specificații din 3GPP (începând cu Release 6) fac conversia spre o "All IP Network". În UMTS și standardele succesoare (HSxPA, LTE) QoS se poate regăsi pe mai multe interfețe în interiorul unei rețele de comunicații mobile. Se poate vedea de asemenea că VoIP a câștigat mult în ultimii ani.

Pe interfața Uu singura posibilitate pentru QoS este aceea de a avea parametri diferiți pentru fiecare purtătoare – Radio Access Bearer, cum ar fi modul de transmitere confirmat sau neconfirmat (neconfirmat pentru aplicațiile pentru care întârzierea mică este mai importantă decât eroarea în pachete).

Interfața Iu este interfața dintre RNC și SGSN. O parte din caracteristicile de QoS ar trebui să fie deja aplicate în direcția uplink de către RNC urmând principiul de a limita fluxul cât mai curând posibil, astfel încât, cât mai puține resurse să fie folosite în rețea. Acest lucru înseamnă că GGSN ar trebui să limiteze fluxul pentru direcția downlink. Pe această interfață putem vorbi despre QoS legat numai de nivelul de utilizator, deoarece nivelul de control are deja resurse proprii alocate. Conexiunea de control are propriul său canal virtual, cu o rată de biți garantată. În specificația 3GPP este menționat faptul că aici, pachetele din fluxuri diferite pot fi marcate în conformitate cu DSCP specifice. Acest lucru depinde desigur de clasa de trafic. Acest lucru influențează modul în care pachetele sunt tratate în SGSN în funcție de diferitele RNC-uri de la care vin sau în funcție de aplicația de care aparțin pachetele. De exemplu pachetele pentru un transfer FTP dintr-un context PDP cu clasa de trafic "background" pot fi eliminate atunci când nu există suficiente resurse disponibile pentru o sesiune de streaming de date dintr-un context PDP cu clasa de trafic "streaming". În acest fel, traficul pentru FTP este redus în mod automat în timp ce cererea de streaming încă își primește datele cu parametrii garantați (rata de bit și de întârziere).

Un avantaj al punerii în aplicare a DiffServ în rețelele de telefonie mobilă este acela că întreaga rețea are același proprietar, astfel încât DSCP sunt definite pentru întreaga rețea, în timp ce furnizorii de rețele fixe trebuie să facă acorduri între ei. Nivelul de transport pentru interfața Iu este ATM până la Release 6 din specificațiile 3GPP, iar începând cu Release 6, acesta poate fi și IP.

Acesta oferă o mai mare flexibilitate în implementare și în același timp costurile pot fi reduse, deoarece în cazul folosirii rețelelor Ethernet pentru transportul IP echipamentele sunt deja uzuale și prin urmare, mai ieftine.

Pe interfața Gn tehnologia Diffserv de pe planul utilizator al interfeței Iu, se aplică de asemenea, dar diferența este că în SGSN DSCP-urile pot fi modificate, dar nu obligatoriu, pentru a se potrivi cu cele de la GGSN. Acest lucru poate fi util și pentru abonații care sunt în roaming, deoarece, în acest fel se pot face acorduri cu partenerii de roaming pe interfața Gp.

Pe interfața Gi DSCP-urile pot fi schimbate, dar de data aceasta în scopul de a se adapta la alte posibile soluții QoS care sunt disponibile în continuare la furnizorul de Internet. Pe această interfață GGSN limitează traficul downlink în funcție de QoS stabilit pentru un anumit context PDP.

4.9 Mașini algoritmice utilizate în modelare

Procesarea pe baza QoS este modelată – în abordarea generică pentru domeniul telecomunicațiilor – cu mașini algoritmice de stare (ASM-Algorithmic State MAchines) – Automate cu Stări Finite (FSM – Finite State Machines) precum „ip_dispatch” și „ip” (care vor fi utilizate efectiv în implementările din capitolul 6).

Mașina algoritmică de stare ip_dispatch cuprinde următoarele stări: primele 4 stări inițializează atât diferitele variabile de simulare cât și parametrii de MPLS (dacă este cazul), următoarea stare cmn_rte_tbl asigură redistribuirea informațiilor de rutare între diferitele protocoale de rutare din acest nod, în starea inactive se intră în cazul în care nicio interfață nu este activă, în starea init_too se finalizează inițializarea iar la final se intră in starea idle în care se așteaptă pachete ce vor fi apoi forwardate mai departe în baza adresei destinație.

Este foarte important ca în cazul existenței mai multor interfețe IP (ca în cazul unui terminal multimodal) să fie definit indexul adresei IP pe conexiunile ce intră în acest ASM, pentru a se putea mapa adresele IP definite în atributele nodului cu interfețele fizice definite în modelul nodului.

5 QoS pentru streaming mobil de date

5.1 Calitatea tele-transmisiei de date pentru măsurări mobile

Rețelele celulare wireless sunt omniprezente în zilele noastre în aplicații de transmiterea datelor în scopuri civile / de uz general, fiind disponibile acum pentru mai mult de 3 miliarde de abonați la nivel mondial și având un impact major asupra vieții lor personale și profesionale.

Am efectuat un studiu de caz bazat pe un banc de lucru cu viteză mare de achiziție a datelor, prin intermediul unui osciloscop digital cu transmisie în timp real: schema de conversație în timp real este caracterizată de faptul că, timpul de transfer ar trebui sa fie scăzut (datorită naturii conversaționale a schemei) și în același timp, de faptul că relația de timp (variația) între entitățile de informare a fluxului ar trebui să se mențină similar fluxurilor de timp real. Întârzierea maximă a transferului este dată de percepția umană a conversației audio și video. Prin urmare, limita maximă acceptabilă a unei întârzieri de transfer este foarte strictă, deoarece o întârziere de transfer care nu este suficient de scăzută va determina o lipsă de calitate inacceptabilă.

La măsurători s-au luat în considerare diferite aplicații, precum telemedicina, comunicațiile industriale.

Figura 5-1 Scenarii pentru măsurători de la distanță prin PLMN

cu transmisie descendentă (DownLink) b) cu transmisie ascendentă (UpLink)

Mediul de testare cu echipamentul PLMN Siemens a inclus : Rețeaua de Acces Radio (RAN) – BTS/Node-B UMTS,BSC/RNC UMTS, Centrul de comutație al traficului de voce (Switching Center)- MSC și TRAU , Centrul de comutație al traficului de data (Data Center) – SGSN și GGSN CISCO. Atât sonda cât și clientul pot fi ficși sau mobili, locali sau la distanță. Se pot imagina scenarii diferite, cu unități mobile de test (de exemplu, vehicule, pacienți) având atașate înregistratoare și transmițătoare de date și/sau echipe mobile de supraveghere- diagnostic-intervenție, etc.

Obiectivul este acela de a stabili o conexiune de măsurare la distanță fiabilă și de a realiza câteva teste pentru a determina modalitatea cea mai eficientă în transmiterea experimentală a datelor electronice, în ideea unui efect în timp real în manipularea și operarea la distanță a echipamentelor.

Pentru aceasta s-a folosit transmiterea de tip TCP/UDP. Elementele rețelei în acest caz sunt împărțite în : mediul de transport al rețelei, care permite transmisia, și echipamentul de achiziție a datelor. Identificarea impactului pe care îl are limitarea tehnică a acestora asupra măsurării la distanță este unul din scopurile acestui studiu.

Echipamentul pentru achiziția de date (DAQ) (împreuna cu senzorii/traductorii și prelucrarea semnalului local) aplicat pe unitatea test, conectat la PC portabil ("palm-top" or "lap-top") sau fix ("desk-top") este denumit ''sondă''. PC-ul fix sau mobil din partea de recepție este clientul care colectează valorile măsurate de la distanță. Sonda și clientul pot avea conexiuni mobile (de ex. acces wireless folosind un modem mobil pentru conectarea la un PC).

Majoritatea testelor s-au efectuat pe o platformă GPRS/EDGE. Din punct de vedere al accesului radio, transmisia este de tip Up Link (UL) dacă pornește de la terminalul mobil spre rețea și Down Link (DL) în cazul opus. În general, îmbunătățirile rețelei se fac mai întâi în sensul Down Link (DL) pentru a mări lățimea de bandă disponibilă. Enhanced Data Rates pentru Evoluția GSM (EDGE) este o consolidare de tip suprapunere pentru GSM 2G/2.5. Ratele de date posibile la nivel fizic pentru DL sunt de până la 236.8 kbiți/s, pentru 4 timesloturi (maximul teoretic este de 473.6 kbiți/s, pentru 8 timesloturi) în modul de pachete. După ce Activarea de Context PDP este acceptată de rețea la cererea terminalului mobil, abonatul și PC-ul lui conectate prin intermediul unei legături USB sau Bluetooth, pot să comunice pe Internet sau cu alți abonați din rețea pe baza IP-ului atribuit de GGSN.

La celălalt capăt, stația sau clientul (în funcție de situație, a se vedea Figura 5-2) sunt conectate pe interfața Internet/Gi.

Achiziția de date a fost efectuată prin utilizarea osciloscopului digital PCS VELLEMAN-500, fie cu date simulate (în "modul demo") fie cu măsurare reală. Osciloscopul oferă un număr reglabil de mostre pe cadru transmis (200 – 5000, capacitatea buffer-ului ; valoarea implicită este 1000) a semnalului măsurat – real sau simulat intern. Cele două rate principale aplicate transmisiei de date sunt: rata de eșantionare (o valoare reglabilă de la 1250 la 50.000.000 de eșantioane/s) aplicată la semnalul măsurat, precum și rata la care buffer-ul este citit. Aceste două valori trebuie să fie corelate; citirea buffer-ului nu ar trebui să se facă decât după stocarea următoare în buffer – a se vedea formula (3) de mai jos.

Măsurarea efectivă a semnalului cu osciloscopul produce simultan 5000 de eșantioane depozitate în memoria buffer-ului I/O – prima locație stochează Rata Eșantioanelor [Hz], a doua locație Scala Completă [mV], a treia locație Offset-ul [mV] și celelalte locații, până la 5000, datele dobândite (cu 8 biți / eșantion scalat și centrat). Rata de eșantionare, SR și numărul de citiri (NOR) pe secundă sunt:

ceea ce duce la Timpul de Așteptare (TTW), până când buffer-ul este plin și poate fi citit din nou:

În cazul transmisiei TCP, ne interesează în mod deosebit Timpul Round-Trip (RTT) care se măsoară între momentul de timp în care un pachet IP este trimis și momentul de timp în care confirmarea corespunzătoare acestuia este primită. Aceasta este întârzierea care ar putea fi percepută de către un operator.

În cazul transmisiei UDP, un parametru important în studiul calității serviciilor îl reprezintă jitter-ul. Acesta reprezintă variația intervalului de timp dintre două eșantionări succesive și are un efect asupra operatorului uman similar cu cel al RTT-ului în cazul TCP. Înainte de fiecare măsurare, legătura de date este investigată cu un test de lățime de bandă și fiabilitate (pierdere de pachete, întârzieri), folosind un instrument dedicat, Iperf (cu interfață grafică Jperf) pentru măsurarea lățimii de bandă TCP / UDP maxime. Pentru măsurarea lățimii de bandă (și pentru alți parametri QoS) am utilizat Ethereal / Wireshark. Lățimea de bandă în graficele Jperf a fost exprimată în kbps (Y-kbps, XS).

Eșantioanele sunt citite din buffer-ul de memorie și apoi transmise clientului prin IP – TCP cu mecanism propriu de detectare a erorilor și UDP cu detectare a erorilor simple (conexiunea este încheiată atunci când eșantioanele sunt pierdute). În acest proces, eșantioanele nu sunt modificate în niciun fel, astfel încât, la client vor fi aceleași caracteristici metrologice ca cele ale osciloscopului digital utilizat.

În scopul de a programa transmisia și recepția de date la nivelul sondei și al clientului, s-a utilizat LabView, care poate rula, de asemenea, pe smartphone-uri (s-a utilizat HTC P3600 – GSM-GPRS-EGDE / 3G-UMTS-HSDPA / WiFi / Bluetooth / IrDA / GPS / Windows Mobile 5.0). Streaming-ul de date a fost făcut prin intermediul TCP sau UDP de către PDP (Packet Data Protocol) stabilit în prealabil, între terminalul mobil și PLMN (GGSN), utilizând funcțiile definite pentru transportul TCP și UDP. Toate testele au fost efectuate cu 200 de eșantioane.

La „sondă” (partea de server), „VI” care controlează osciloscopul digital (folosind driver-ele oferite de VELLEMAN) ca un ''digitizer", citește datele din buffer-ul de memorie (unde au fost obținute), cu o frecvență care depinde de valoarea bazei de timp (aceasta este prima citită din memorie). Octeții sunt apoi trimiși la conexiunea TCP, precedați de numărul de eșantioane care urmează să fie trimise. Astfel, lungimea de pachete IP este proporțională cu numărul de eșantioane trimise. Programele pot recunoaște și trata erori de transmisie. Ecranul osciloscopului digital Velleman PCS-500 a fost simulat la client (partea receptoare), acesta procesând datele trimise de la sondă.

Calitatea bună a serviciilor (QoS) a permis clientului de la distanță să perceapă datele măsurate și să interacționeze cu interfața emulată a Osciloscopului (" skin ") imediat, în timp real (fără o întârziere perceptibilă, așa cum este definită în documentul 3GPP QoS) , similar operării “on-site”. În cazul în care o eroare de transmisie are loc în mediul de transmisie, aceasta este tradusă în întârzieri la partea receptoare și în consecință, forma de undă afișată (“oscilograma”) este oprită temporar.

Acest studiu de caz evoluează de la soluțiile precedente de măsurare la distanță dezvoltate la Universitatea "Transilvania" din Brașov, în colaborare cu Universitatea Tehnică Națională din Atena , bazate pe arhitectura client/server (serverul de web & servere banc de lucru – la nivel de ''sondă'' cu Instrumentul național PCI-6024E sau AT-mio-16E10 DAQ), care implică mediul de transmisie Ethernet.

Accentul în acest studiu a fost pus pe capabilitățile cheie ale rețelei celulare de “streaming” de date în timp real, evaluate în Downlink (DL) și uplink (UL): în DL, "clientul" mobil a constat în terminalul GSM / GPRS / UMTS / HSDPA conectat la hardware-ul de date de reprezentare și de software (a se vedea Figura 5-1.a); în UL, "sonda" mobilă a constat în terminale GSM / GPRS / UMTS / HSDPA conectate la achiziția de hardware & software.

Terminalul mobil este conectat la rețea cu modul de pachete de date activat. Datele din măsurătorile reale sau simulate sunt transmise între client și sonda VI-S. Clientul semnalează primirea datelor printr-o "sincronizare" elementară (recunoașterea unui caracter simplu trimis la server). După fiecare 50 secunde, setarea Time / Div de pe osciloscop a fost scăzută de la rata de pornire de 100ms până la unele mai mici ca 1µs. Acest lucru a dus la umplerea mai deasă a buffer-ului și la o rată mai mare de transmitere. Cu cât este mai mare rata, cu atât este mai mare probabilitatea unui RTT mai lung (TCP) sau Jitter mai mare (UDP).

Primul scenariu este cu acces EDGE pentru transferul DL TCP reprezentat în Figura 5- 1.a. Lățimea de bandă disponibilă este măsurată cu Jperf și Ethereal / Wireshark, atât la client cât și la sondă. După cum este ilustrat în Figura 5-2.a, la începutul transmiterii, timp de aproximativ 2 secunde, nu există niciun transfer de date din partea ''sondei " (server-ului). Acest lucru este cauzat de configurarea canalelor radio. Vârful de la client este cauzat de umplerea bufferelor de transmisie. După ce canalele de radio sunt setate, bufferele sunt golite, fapt care creează un vârf în transmisia de date. Creșterea mică (dar stabilă) a lățimii disponibile de bandă este cauzată de ajustarea dimensiunii ferestrei TCP.

În figura 5-3.a se ia în considerare modificarea pas cu pas a bazei de timp a osciloscopului și se poate observa că rata de biți este în creștere în mod proporțional. În momentele în care baza de timp este pornită, există unele vârfuri cauzate de faptul că, în acele momente osciloscopul nu furnizează eșantioanele la aceeași viteză ( este necesar un timp scurt pentru stabilizarea acestei viteze).

Figura 5-2 Jperf/Iperf măsurători ale lățimii de bandă [kbps]în cazul transferului DL TCP pentru ”sondă” (a) și client (b)- 70 kbps

Figura 5-3 Ethereal/Wireshark măsurători ale transferului EDGE prin TCP la ”sondă”

pentru variația bazei de timp de la 100ms la 5 µs

Din Figura 5-4 , se poate observa că cele mai multe dintre valorile RTT sunt situate în jurul a 700ms. Există, de asemenea, pachete cu o RTT de câteva secunde. Aceste întârzieri sunt provocate de pierderea de pachete pe interfața radio. Pentru prima parte a măsurătorii ilustrate în Figura 5-5, se poate observa tranziția aproape constantă atunci când se mențin primele valori ale bazei de timp.

În a doua parte, atingându-se capacitatea canalelor ("congestie"), în momentul în care rata de biți necesară se apropie de lățimea de bandă disponibilă, sunt pierdute din ce în ce mai multe pachete, provocând variații mari în grafic (care scade dramatic în timpul negocierii retransmiterii).

Figura 5-4 Ethereal/Wireshark măsurători ale timpului de transfer total (RTT) la ”sondă” pentru transferul DL TCP cu perioade de congestie

Figura 5-5 Ethereal/Wireshark măsurători de trafic la ”sondă” pentru transfer DL

TCP cu perioade de congesti

Diagrame similare au fost reprezentate grafic pentru aceleași criterii ca în cazul anterior (DL TCP). Următoarea interpretare a rezultatelor evidențiază principalele diferențe între DL UDP și DL TCP.

Pentru accesul EDGE cu transferul DL UDP (figura 5-6) nu este vizibil nici un efect al buffering-ului la ”sondă” (server), deoarece UDP nu este un protocol orientat pe conexiune. Buffering-ul are efecte vizibile asupra receptorului (clientului). Datorită buffering-ului inițial și a faptului ca nu există nici un mecanism de actualizare a ferestrei TCP, lățimea de bandă disponibilă scade ușor.

Figura 5-6. Jperf/Iperf măsurători ale lățimii de bandă [kbps] în cazul transferului

DL UDP pentru ”sondă”(a) și client (b) – 70 kbps

Se poate observa faptul că protocolul UDP nu este orientat pe conexiune, timpul de configurare al canalelor radio este mai scurt în partea ”sondei” și nu există nici un efect de ”buffer”-are. Spre deosebire de acesta, în cazul clientului există un efect de ”buffer”-are initial și se poate observa o ușoară scădere a lățimii de bandă disponibilă, datorată lipsei mecanismelor de control al transferului specifică UDP. După cum s-a subliniat anterior, ”buffering”-ul nu este vizibil la ”sondă” (server) datorită naturii protocolului UDP neorientat pe conexiune și astfel, rata de biți nu este influențată de retransmisia sau pierderea de pachete.

”Buffering-ul” este vizibil la client, deși nu în aceeași măsură ca pentru TCP (în UDP nu este implementata retransmiterea). În cazul în care rata de biți se apropie de lățimea de bandă disponibilă, numărul de pachete pierdute crește, ceea ce face transmiterea nesigură.

Jitterul este în creștere ușoară în timpul transmisiei, deoarece pachetele sunt stocate în ”buffer” unde rămân din ce în ce mai mult timp 110 ms.

Pentru accesul EDGE pentru transferul UL TCP lățimea de bandă a fost investigată mai întâi cu ajutorul Jperf / Iperf și Ethereal / Wireshark atât la sondă cât și la client. În cazul în care atât ”sonda” cât și clientul sunt mobili, limitările UL se aplică în ambele cazuri. Acest lucru presupune o serie de întârzieri care mărginesc rata de transfer printr-un acces UL. Lățimea de bandă în UL, este foarte similară cu lățimea de bandă DL, dar proporțional mai mică (datorită numărului redus de canale GPRS / EDGE disponibile pentru UL) – această observație este valabilă pentru toate măsurătorile de performanță referitoare la transferul UL TCP.

Pentru accesul EDGE pentru transferul UL UDP, în primul rând este investigată lățimea de bandă folosind Jperf / Iperf atât la sondă cât și la client. Același fenomen poate fi observat pentru UDP ca și pentru TCP: bufferele de pe server sunt întâi umplute, apoi sunt golite provocând un vârf în trafic. Se poate observa că rețeaua acceptă vârfuri foarte scurte de date. Lățimea de bandă disponibilă este mai mică în UL decât în DL (pentru că, de obicei, sunt mai puține posturi de radio disponibile pentru DL decât pentru UL), dar comportamentul general este similar cu cel din cazul DL. Din măsurători se poate observa că jitterul nu este constant la începutul transmiterii ca urmare a configurației canalelor de radio. Conexiunea este sigură din momentul în care toate canalele de radio sunt configurate, după un timp măsurat de aproximativ 10 s.

În continuare se prezintă datalogging și modulul de Supervisory Control al National Instruments LabVIEW este dedicat controlului de la distanță, prin conectarea într-o rețea de dispozitive pentru transferul de achiziție (ieșire)/sau (intrare), datele de control la bazele de date distribuite

Variabilele partajate LabVIEW permit programarea eficientă a aplicațiilor distribuite.

Datele pot fi partajate între ”VIs” care rulează în noduri diferite ale unei rețele Ethernet într-un mod optimizat în comparație cu alte metode de partajare de date utilizabile în LabVIEW (de exemplu UDP / TCP, cozile și Real-Time FIFOs).Variabilele partajate sunt configurate la timpul de editare a proiectului de (folosind dialoguri de proprietate) și nu au nevoie de coduri de configurare incluse în aplicații. Sunt trei tipuri de variabile partajate: cu un singur proces, timp de declanșare, publicate în rețea (acestea din urmă sunt folosite în aparatul prezentat).

Crearea de variabile partajate în ierarhia acestui proiect, a fost realizată prin click- dreapta pe nodul principal de calcul din configurarea noastră (hosting the server) denumit „My Computer” prin selectarea New> Variable se afișează dialogul proprietăților variabilelor partajate unde noua variabilă poate fi configurată.

NI Publish and Subscribe Protocol (NI-PSP) este un protocol de rețele simplificat, optimizat pentru a fi transportorul variabilelor partajate publicate în rețea. Desfășurarea de variabile partajate publicate în rețea se face spre un motor de variabile partajate (SVE), care găzduiește în rețea valori ale variabilelor partajate.

Când se scrie către un nod de variabile partajate, LabVIEW trimite noua valoare către SVE care desfășoară și găzduiește variabila (în cazul nostru serverul „My Computer” cu adresa de Intranet WLAN 192.168.1.3). Bucla de prelucrare SVE publică valoarea, astfel încât orice abonat (de exemplu, un telefon mobil Client Smartphone Pocket PC) primește valoarea actualizată.

Server-ul VI preia datele de la interfața serială – a se vedea VISA (”VXI (Plug & Play), sistemele de alianță”) citește (R) de control; aceste date (de exemplu temperaturi) pot fi achiziționate de către un stand de lucru de laborator. VI transformă aceste date în format zecimal și va publica valorile măsurate de temperatură în Variabile1, partajată. În ceea ce privește temperatura de intrare, (care poate fi trimisă de la terminalul client către un sistem de control automat al temperaturii) valorile ei sunt citite de la Variable3, partajată, convertite din zecimale și trimise (prin intermediul VISA scrie (W) de control) către interfața serială.

Clientul VI citește Variable1 partajată (care reprezintă temperatura măsurată) și o

afișează. Scrie în Variable3 partajată valoarea temperaturii de intrare (preluată de sistemul de control de la distanță automat HVAC). O configurare pilot de test a fost construita în jurul unui server PC, conectat la Intranetul unui router „Linksys Wireless-G”.

Pentru a verifica statutul și configurarea acestuia , PDA-ul HTC P3600 rulează un

instrument „vxUtil” de la Cambridge Computer Corp, care permite DNS Audit / DNS Lookup / Finger / Get HTML / Info / IP Subnet Calculator / Password Generator / Ping / Ping Sweep / Port Scanner / Quote / Time Service / Trace Route / Wake On LAN / Whois.

Este prezentat și un studiu de caz – Achiziția mobilă de date și Tele-transmiterea prin

PDA. Problema abordată este integrarea unui sistem pentru DAQ + logare și/sau tele- transmisie care poate fi personal și portabil. Cele mai multe dintre soluțiile pre-existente comparabile, sunt extrem de specializate și de proprietare (de exemplu prin soft-urile dedicate hardware-firmware ale micro-controlerelor), acestea nefiind întotdeauna foarte accesibile. Configurare realizată utilizează PDA-uri comune care au plugged-in un card micro DAQ de uz general și cu o interfața comună (CF – „Compact Flash”), un card de memorie comun de capacitate mare (SD – Secure Digital „) și care rulează un software de instrumentație universal

– NI LabVIEW (LV). LV poate efectua nu numai achiziții de date și logare, dar și prelucrare

(de exemplu, filtrarea digitală, de identificare, clasificare, compresie, etc.) și comunicare.

Dacă PDA-ul are și capabilități „SmartPhone”, poate transfera, de asemenea, date prin

intermediul comunicațiilor mobile (de exemplu, spre un server central). În caz contrar, o alternativă ieftină (care a fost integrata de autor) este conectarea la telefonul mobil al proprietarului, care poate fi controlat, de exemplu, prin comenzi AT (pentru dial-up, GPRS și/sau transmisie de SMS). Se poate utiliza înregistrarea datelor la nivel local, pentru achiziția de date și diagnosticarea detaliată (uman și/sau automat), în timp ce transmisia tele-mobilă poate fi utilizată în principal pentru actualizări și alarme.

Pentru monitorizarea de la distanță, multe dispozitive portabile au fost dezvoltate pentru achiziția, înregistrarea, prelucrarea și transmiterea datelor achiziționate. Procesarea semnalului digital (DSP) permite o analiză complexă și oferă posibilitatea luării deciziilor în timp real. Autorul a dezvoltat diferite sisteme de tele-monitorizare în ultimii ani. O soluție „twin- microcontroler” are un microcontroler alocat controlului achiziției de date și prelucrării și altul alocat gestionării comunicațiilor (interfațarea și controlul unui modem GSM). Astfel de soluții dual-procesor sunt comune, chiar și telefoanelor SmartPhones (doar recent DSP și prelucrarea de uz general au fost aduse la o bază comună).

Sistemul cel mai recent implementat de către autor, cu arhitectura reprezentat în Figura 5-7, constă în 4 canale, card DAQ de 200kS/s, mai exact CF NI 6004, conectate în slot-ul.

Compact Flash a unui PDA HP iPAQ 2210. Autorul a folosit în configurația de încercare o sondă portabilă formată din senzori / traductoare și circuitele de condiționare de semnal.

Figura 5-7 Configurație Test pentru DAQ mobi

Deoarece majoritatea PDA-urilor Compact Flash disponibile în prezent pe piață nu incorporează tehnologii de comunicații mobile precum GSM / UMTS sau WiFi, care ar permite sistemului să transfere datele obținute direct către un server la distanță, autorul a decis să utilizeze un telefon mobil obișnuit pe post de modem GSM / GPRS. PDA-ul este conectat la telefonul mobil prin Bluetooth și utilizează comenzi AT standard pentru a transfera un mesaj (care include datele achiziționate și/sau în mod special parametrii rezultați) către telefonul mobil care trebuie să transmită aceste date la un server de la distanță, utilizând GPRS (și/sau cel puțin SMS).

Software-ul pentru achiziția cât și pentru transmiterea de date a fost implementat cu ajutorul modulului PDA LabVIEW, un subset de funcții NI LV concepute special pentru PDA- uri. Achiziția datelor se face folosind NI DAQmx Base, un set de drivere și funcții pentru plăci DAQ făcute de NI. O sarcină DAQ trebuie să fie definită, specificând atribute cum ar fi rata de eșantionare, canalele utilizate, numărul de probe, etc. Crearea sarcinii DAQ este realizată folosind DAQ Configuration Utility inclus în LV.

5.2 Sistem Dublu-Microcontroler cu Tele-Monitorizare prin Modem GSM

Tele-măsurarea are o gamă largă de aplicații dintre care monitorizarea proceselor industriale sau, în cazul de față, monitorizarea de la distanță a pacienților la domiciliul acestora, permițându-le să ducă o viață cât mai apropiată de normal.

Sistemul realizat de autor utilizează un microcontroler dedicat expedierii de comenzi către un modem GSM sau un telefon mobil cu capabilități de modem.

O primă aplicație este destinată tele-monitorizării pacienților cu suferințe cardiace, în afara spitalului. În acest caz, viteza intervenției este esențială astfel că serviciul de ambulanță trebuie anunțat urgent la apariția oricăror probleme, fie prin expedierea unui SMS preluat automat sau prin inițierea unui transfer de date către server-ul de la spital care interpretează informația și ia automat măsuri de alarmare.

SMS-ul este mai sumar decât transferul de date astfel că, dacă în afara informațiilor de

presiune arterială și puls, sistemul cu microcontroler trebuie să proceseze semnalele complexe

– gen EKG – sunt necesare operațiuni de condiționare și conversie AD și extragerea unui set de parametri relevanți și/sau compresie.

Sistemul a fost realizat monobloc, pe o placă de cablaj pe care principalele subansamble sunt convertorul AD tip ADS1211 și microcontrolerele AT89S53 și AT89C2051 (figura 5-8).

Convertorul analog-digital sigma-delta ADS1211 are precizie sporită (rezoluție de 24 biți și o rată maximă de eșantionare de 17KHz), auto-calibrare și patru intrări pentru a prelua semnale multiple. Aceste calități permit utilizarea lui nu numai la măsurări mai simple (puls sau tensiune arterială) dar și în cea mai pretențioasă aplicație – monitorizarea EKG.

Figura 5-8 Schema bloc a sistemului de tele-monitorizare

Interfața serială dintre CAD tip ADS1211 și AT89C2051 este sincronă, cu ceas de aprox. 1MHz. Microcontrolerul AT89C2051 este master. Transmisia este inițiată doar când CAD are date valide în registrele sale (semnalizare “high” pe pinul său Data Ready). Microcontrolerul AT89C2051 poate transmite comenzi către CAD sau parametri care îi determină modul de funcționare și totodată datele recepționate de la convertorul AD către buffer-ului de memorie al celui de al doilea microcontroler, AT89S53, prin interfața paralelă. Comunicația dintre cele două microcontrolere se face prin interfața paralelă, mai rapidă, pentru a economisi din timpul de procesare al microcontrolerelor (alocat, în special, analizei semnalelor bio-medicale). Protocol de comunicație este de tipul STROBE/READY.

Al 2-lea microcontroler, AT89S53, poate fi programat printr-o interfață serială foarte practică prin care se poate (re-)scrie memoria lui (flash) de program. Așadar, microcontrolerul AT89S53 poate fi reprogramat în sistem (fără a fi nevoie de a fi scos și montat pe un programator extern), doar printr-un simplu cablu trifilar.

Se poate implementa astfel și o modalitate de a reconfigura sistemul de la distanță, prin recepția de mesaje GSM-SMS speciale (de exemplu, pentru a modifica numerele dial-up) în sens invers (de la sistemul expert care centralizează datele) față de modul normal de lucru. Această conexiune serială standard poate fi utilizată și drept cale de rezervă pentru date.

6 Optimizarea QoS în comunicații mobile de date

Conform standardelor ITU pentru TMN (Telecom Management Networks), sistemele mobile de comunicații includ servere centrale cu funcționalitate pentru colectarea datelor de performanță (PDC – Performance Data Collection). PDC poate oferi valori măsurate în permanență (și câteva statistici), prin teste de performanță, care sunt specifice QoS. În scopul de a colecta valorile de trafic, PDC, poate fi asociat cu mecanismul de charging (taxare) – înregistrare în timp real a tuturor informațiilor utile – contoare (de timp, pentru volum), jitter, RTT (round-trip-Time), rata de biți etc., incluse în "charging tickets".

În domeniul comunicațiilor mobile de date pot fi luate caracteristicile unui PDP Context, prin sistemul de semnalizare SS7, direct pentru un terminal de date mobil, în faza de activare a

contextului. Acest set de parametri poate fi totodată folosit pentru condiționarea calculului QoS.

6.1 Formula propusă pentru QoS cu dublă ponderare

Am considerat două tipuri de seturi de criterii, suficient de generale pentru a fi comune pentru diferite rețele fără fir (de exemplu, 3G, Wi-Fi, EV-DO etc), care pot funcționa în cadrul unei comunicări optimizate multi-modale.

•Profilul de abonat care poate conține un set primar de ponderi convenționale – de exemplu, pe o scară de la "student" la "manager": de la nivelul "student" profilul va fi orientat pe costuri reduse în timp ce la nivelul „manager" alocarea resurselor este mai importantă (lățime de banda garantată, întârzieri reduse etc.). În dezvoltările viitoare, unele dintre aceste ponderi ar putea fi configurate chiar de către abonat, care poate transmite la server o serie de modificări ale propriilor profile.

•Termeni ponderați asociați nivelului aplicație din stiva OSI. Se pot lua, ca referință, cele 4 clase definite de standardele 3GPP, definite de altfel și la descrierea sistemului UMTS:

La prima vedere pare că toate intrările (în procedura de calcul) sunt la același nivel de importanță, dar unele condiții trebuie să fie impuse de către aplicație. De exemplu:

•La nivelul „conversațional”, atât pentru legătura uplink și downlink, jitter-ul va fi luat în considerare cu un factor de ponderare diferit de zero, în timp ce, în restul claselor, aceasta poate fi considerat egal cu zero.

•Pentru „clasa background” sau „clasa conversațională”, cel mai important factor de ponderare este costul, nu rata de biți. Se va opta pentru o rată de transfer mai redusă dar ieftină (adesea WiFi e practic gratuit față de 3G), în defavoarea unui bitrate sporit dar mai costisitor.

Calculul QoS va lua în considerare costuri diferite pentru traficul efectiv de „uplink” și „downlink” și tarife speciale pentru rezervarea de resurse (lărgime de bandă etc.) și garantarea unor limite conexiuni cu întârziere minimă, jitter minim, RTT minim etc.

Factorul „întârziere” („delay”) este foarte important și de aceea el va fi considerat separat, chiar dacă ar fi putut fi considerat direct în calculele factorului de calitate pentru „uplink” și „downlink”.

Valorile obținute de la rețea pot fi tratate separat față cele de la terminalul mobil (nod de calcul mobil, "telefon inteligent", "comunicator" etc.).

Formula propusă pentru calculul QoS prin sumă dublu ponderată:

N

Qos=∑ W profile ,k *W class,k * P normalized,k

K=1

Normalizarea parametrului pk se face la cerințele aplicației, maximul valorii fiind limitat la 1.

Valoarea cerută de aplicație se va afla fie la numărător, fie la numitor, în funcție de

modul în care valoarea ne-normalizată ar trebui să fie maximă sau minimă în mod ideal.

De exemplu, pentru N = 4 parametri măsurați – GBR (Garantat Bit Rate), TDELAY

(Total Delay), JITTER și ER (Error Rate) – și 4 profile (Premium, Voce, normal, și de bază), este prezentat un posibil set de ponderi și normalizări:

w Premium, 1 = 1, w Premium, 2 = 1, w Premium, 3 = 1, w Premium, 4 = 1

w Voice, 1 = 0.75, w Voice, 2 = 1, w Voice, 3 = 1, w Voice, 4 = 0.5

w Normal, 1 = 1, w Normal, 2 = 0.5 , w Normal, 3 = 0.5 , w Normal, 4 = 0.75

w Basic , 1 = 1 , w Basic , 2 = 0.25 , w Basic , 3 = 0.25 , w Basic , 4 = 0.5

Alte exemple, pentru alte tipuri de aplicații ar fi:

• Aplicație VoIP – clasă de trafic conversațional:

o wVoice,1 = 0.75, wVoice, 2 = 1, wVoice, 3 = 1, wVoice, 4 = 0.5 (pentru un utilizator

interesat, în general, de aplicații VoIP)

o pnormalized,1 = GBR /Appl_GBR = 1

o pnormalized,2 = Appl_ TDELAY/ TDELAY = 1

o pnormalized,3 = Appl_ JITTER / JITTER = 1

o pnormalized,4 = Appl_ JITTER / JITTER = 0.5

• Web Browsing:

o wNormal,1 = 1, wNormal,2 = 0.5, wNormal,3 = 0.5, wNormal,4 = 0.75

o pnormalized,1 = GBR /Appl_GBR = 0.5

o pnormalized,2 = Appl_ TDELAY/ TDELAY = 0.5

o pnormalized,3 = Appl_ JITTER / JITTER = 0.25

o pnormalized,4 = Appl_ JITTER / JITTER = 1

QoS3G și QoSWi-Fi sunt calculate, precum și raportul lor; handover-ul Wi-Fi la 3G este

decis dacă QoS3G / QoSWi-Fi este de peste 1.1 (QoSWi-Fi / QoS3G scade sub 0.9). Valoarea de

10% este aleasă convențional pentru toleranță la handover – cu scopul de a asigura un handover

fără oscilație.

Serviciul este implementat „Top-Down” pe baza BPEL, cu un bloc de calcul programat în limbajul C.

Integrarea și testele de validare se vor face într-un studiu de caz bazat pe scenarii de evaluare a QoS pentru comunicațiile mobile bi-modale (3G/WLAN).

Se poate lua în considerare și o abordare bazată pe programarea PHP a unei funcții de consolă asociată acestui server rezident la operatorul de comunicații, conformă cerințelor

specifice OMA (Operation-Maintenance-Administration). Consola poate avea, pe lângă funcțiile de configurare și monitorizare, o importantă funcționalitate de abonare.

Datele de intrare sunt ponderi caracteristice profilului abonatului și ponderi

caracteristice aplicației folosită de abonat. Se pot trata separat valorile provenite de la rețea față

de cele provenite de la terminalul mobil (nod mobil de calcul, „smartphone”, „communicator”

etc).

Se alege formatul XML pentru cele două „intrări” în calcul:„Profile” și „Performance Data”.

Formula prezentată anterior pentru calculul QoS ca sumă dublu-ponderată este implementată în următoarea porțiune de cod:

// evaluate pdc data double qos =

w_pr_gbru * w_cl_gbru * avbu / np_gbru + w_pr_gbrd * w_cl_gbrd * avbd / np_gbrd + w_pr_tdelay * w_cl_tdelay * np_tdelay / delay + w_pr_jitter * w_cl_jitter * np_jitter / jitter + w_pr_er * w_cl_er * np_er / errorRate;

Interfața dezvoltată emulează funcționalitatea HLR (Home Location Register – sau a unei baze de date similare pentru WLAN, ca de exemplu HSS pentru rețelele ce au implementat IMS), care oferă ServiceClassConfig(uration) și este prezentată în atât în forma HTML cât și sursă XML.

Prin această interfață, ponderile pot fi introduse pentru diferitele clase de aplicații cât și a profilelor abonat (profiluri de utilizator). Un astfel de exemplu XML pentru servicii, cât și un exemplu HTML, respectiv XML, pentru userprofile sunt prezentate în figurile următoare.

Același input poate fi utilizat pentru date de normalizare (cu toate acestea, acești numitori și numărători pot fi introduși direct în calculul QoS dublu-ponderat).

Având aceste date, acum se poate calcula nivelul de QoS oferit de rețelele de transmisie

și apoi să se decidă care dintre rețele va ruta majoritatea traficului.

În evaluarea QoS disponibilă, fiecare valoare relevantă măsurată de Performance Data

Collector (avbu – rata de biți disponibila pentru upload; avbd – rata de biți disponibilă pentru download, etc.) va fi întâi multiplicată cu o pondere reprezentând profilul abonatului (w_pr_), apoi cu o pondere reprezentând clasa de servicii, și în cele din urmă normalizată (multiplicată sau împărțită) cu parametrii (np_) de normalizare de referință.

// evaluate pdc data double qos =

w_pr_gbru * w_cl_gbru * avbu / np_gbru +

w_pr_gbrd * w_cl_gbrd * avbd / np_gbrd + w_pr_tdelay * w_cl_tdelay * np_tdelay / delay + w_pr_jitter * w_cl_jitter * np_jitter / jitter + w_pr_er * w_cl_er * np_er / errorRate;

Ar putea fi, de asemenea, luat în considerare, într-un mod similar, QoS necesare

aplicației, cu un handover parțial la QoS cel mai bun actual calculat numai dacă această valoare scade sub QoS necesar (aceasta înseamnă că nu este niciun efort de handover pentru aplicații de cost mic, ce nu cer resurse multe).

Din RFC2326, se poate lua un exemplu de o aplicație de streaming care poate determina parametrii necesari de la un mesaj "DESCRIBE" trimis la serverul de streaming media:

În mod similar, aplicațiile VoIP pot determina cerințele pentru bitrate, întârzieri/jitter și rata de erori acceptabilă de la codec-urile folosite sa codeze datele de voce (la nivel de utilizator, de obicei, este folosit același protocol (RTP) pentru streaming și pentru conferințe voce/video).

În cazul în care nu sunt găsiți toți parametrii pentru o aplicație specifică (cum ar fi navigarea web pentru care întârzierea nu este foarte importantă și jitter-ul nu este deloc relevant), se pot folosi valori implicite acceptabile. În mod ideal, dacă avem aplicații care rulează într-un nod mobil multimodal, ar trebui sa aibă măcar o descriere a profilului QoS care sa poată fi folosită pentru calcularea sumei ponderate.

6.2 Utilizarea QoS pentru Realocarea Traficului în

Comunicații Mobile Multi-modale

Studiul de caz se referă la un terminal mobil bi-modal (3G și WiFi), pornind de la ideea unui transfer parțial (nu „handover” total) – de exemplu 10%-90% – al legăturii. Menținerea la nivel minimal a căii cu QoS redusă (cu reducerea drastică a consumului energetic, evidentă, de exemplu, pentru GPRS) are avantajul de a păstra implicit o cale de semnalizare (practic, „pe canal comun”). Este importantă și posibilitatea de reluare (relativ simplă) a preponderenței pe canalul respectiv, dacă sporește QoS (fără complicațiile repornirii părții radio, chiar dacă s-ar putea imagina comanda ei internă – la nivelul terminalului mobil – prin cealaltă parte, rămasă activă).

Se va lua o decizie binară, bazată pe calculul QoS (ca sumă ponderată de parametri de

performanță) și compararea lui cu o valoare de prag sau cu „funcția cost” a QoS pe cealaltă

cale.

Datele sunt centralizate la serverul de comunicații, care are funcția de management PDC – Performance Data Collection (parametrii de performanță – „benchmarks” sunt specifici QoS). PDC este conformă cu standardele TMN (Telecom Management Networks ale ITU – International Telecommunications Union”).

Structura schemei de simulare este minimală, se simulează doar o parte din rețeaua

UMTS (partea de date – PS) în paralel cu partea de transfer fără fir, prin WiFi.

Figura 6-2 Schema de simulare – privire de ansamblu

Figura 6-3 Schema de simulare – detaliere a subrețelei

Se observă elementele specifice Mobile IP (valabile atât pentru MIPv4 cât și pentru MIPv6): HA, Home Agent – Router_HA, adăugat ca extensie Mobile IP pentru rețeaua wireless; FA, Foreign Agent – Router_FA, adăugat ca extensie Mobile IP pentru rețeaua 3G, GGSN-ul neavând suport pentru Mobile IP; CN – Correspondent Node rol jucat de VoIP Gateway.

Fiecare nod este alcătuit din mai multe blocuri de procese, care la rândul lor sunt definite asemenea unor mașini algoritmice de stare. Blocurile de procese sunt organizate asemenea modelului stratificat ISO-OSI în sensul că fluxul de date coboară de la nivelul Aplicație către nivelul Fizic în cazul în care stația de lucru transmite pachete, iar la recepția unui pachet fluxul este în sens invers, ascendent.

În funcție de rezultatul obținut de la serviciul de evaluare a QoS, în blocul „ip” este decisă rețeaua radio folosită, pe baza IP-ului de interfață folosit.

În configurarea modului bi-modal o mare importanță are asignarea unui parametru „ip addr index” fiecărui flux de pachete ce este conectat la modulul „ip” (descris de ASM-ul

„ip_dispatch” prezentat mai sus, în capitolul 4).

Pentru nodul multimodal se configurează atât parametrii de conexiune la rețeaua

WLAN cât și cei pentru conectarea la rețeaua UMTS.Pentru configurarea atributelor nodului mobil se selectează câmpul „Attributes” princlick dreapta pe nod. De aici se pot alege aplicațiile care rulează pe acest terminal, în funcție de aplicațiile definite de blocul Application Definition. Se pot seta și diverși alți parametri, în funcție de protocoalele suportate.

Deoarece interfața UMTS am adăugat-o manual, unele atribute nu vor apărea în meniu

decât după ce vor fi selectate din lista de atribute și setat numele corespunzător (care, în mod normal, este setat implicit).Parametrii UMTS au valori implicite, dar unele câmpuri trebuie verificate cu atenție deoarece au o importanță majoră în derularea simulării (cum ar fi UE Serving SGSN ID).

Figura 6-4 Structura nodului mobil – bimodal

De asemenea se pot alege și parametrii QoS pentru UMTS, care pot aparține celor 4 clase definite de standardele 3GPP, și anume: conversațională, streaming, interactivă sau de fundal (background). Și pentru partea de Wireless se pot seta parametrii de calitate a serviciilor prin funcția de coordonare hibridă (HCF – Hybrid Coordination Function), mai precis prin precizarea parametrilor EDCA (Enhanced Distributed Channel Access).

Configurarea simulării se face alegând tipul de statistici ce vor fi colectate, pe protocol,

global sau individual pe nod de rețea, iar apoi selectând durata pentru care se simulează

scenariul realizat, care în cazul de față este setată la 900 de secunde.

Figura 6-5 Rezultatul simulării

Nodul mobil este un nod bimodal, care suportă atât conexiune Ethernet, cât și WiFi, cu care se poate verifica handover-ul de pe o interfața pe alta Prin interfața Ethernet eth0, nodul mobil comunică direct cu rețeaua home, având adresa IPv6, 3010:1:2:3::1. Interfața Wireless, wlan0, cea care va comunica prin intermediul rețelei vizitate, va primi adresa

2010:a:b:c::3dff:feab:dfa8.

După cum se poate observa din adresele IPv6, rețeaua home are prefixul

2010:1:2:3::/64, iar rețeaua vizitată 3010:a:b:c::/64. Cele 4 zone observate în monitorizarea WIreshark reprezintă următoarele etape: 1.nodul mobil este în rețeaua de domiciliu, 2.MN intră în rețeaua vizitată, dar menținând și legătura cu rețeaua de domiciliu , 3.MN părăsește rețeaua de domiciliu (interfața wlan0 activă), 4.MN revine în rețeaua de domiciliu.

Timpii de handover sunt în jurul la o secundă, dar, având în vedere că testul s-a realizat pentru un scenariu nefavorabil (utilizând protocolul TCP – neutilizat, în general, pentru servicii în timp real), rezultatele sunt acceptabile.

Pentru setarea QoS pentru Mobile IPv6 se utilizează câmpul Traffic Class (Clasă de trafic) – 8 biți ce asociază priorități diferitelor tipuri de trafic; mai precis primii 6 biți formează Differentiated Services Code Point (DSCP), care oferă tratarea diferențială a traficului (QoS): un nod sursă marchează acești biți, iar routerele tratează corespunzător pachetele respective.

Al doilea studiu de caz este un handover de la WiFi la GPRS (UMTS – 3G). Se utilizează

MIPv6. Avantajele oferite de MIPv6 față de MIPv4

•Rutarerea optimizată: Mobile IPv6 oferă posibilitatea de a optimiza ruta, astfel tunelarea prin metoda HA poate fi evitată. MIPv4 folosește rutarerea "triunghiulara" prin HA

•Protocolul MIPv4 are un Agent Străin (Foreign Agent), similar Agentului de Domiciliu (Home Agent), care transmite toate mesajele, odată ce MN este atașat la rețeaua vizitată. Pentru IPv6 nu este nevoie de Agentul Străin, toate mesajele pot fi trimise direct de către MN, fără a fi nevoie de un router intermediar.

•Spațiu mare pentru adrese (128 biți) – în acest mod comunicarea este end-to-end, nu este nevoie de NAT (Network Address Translation)

•Algoritmul de detectare a vecinilor (Neighbor Discovery Algorithm) – mecanismul pentru reconfigurarea adresei care face handoverul transparent pentru utilizator

•Securitate la nivelul rețelei (IPSec)

•Antete Ipv6 simplificate folosind antetele de extensie (inclusiv antetul de mobilitate specializat – Mobility Header)

•Etichetarea fluxurilor

Testele experimentale de configurare testează posibilitatea de integrare între GPRS și rețelele Wi-Fi. Agentul de domiciliu și nodul mobil sunt instalate pe mașini Linux, care sunt apoi integrate în rețelele GPRS și Wi-Fi.

Configurarea a fost minimizată cât mai mult posibil. Astfel, agentul de domiciliu (HA)

este considerat router-ul rețelei de domiciliu dar și router de acces (routerul care face conexiunea la rețeaua străină). De asemenea, a fost implementată și o arhitectură pentru Mobile IPv4, dar accentul a căzut pe versiunea 6. Pentru MIPv4 rețeaua de domiciliu este rețeaua GPRS, iar cea străină, rețeaua WiFi. Traficul a fost generat de către serverul FTP care a jucat rol de nod corespondent.

Pentru a utiliza rețelele tipice GPRS sau UMTS și în principal pentru utilizarea rețelelor

publice de GSM care generează doar rețele IPv4, este necesara o metodă de "by-pass" de rețele IPv4 astfel încât rețeaua sa acționeze ca un IPv6. Soluția este utilizarea tunelării OpenVPN care face și conversia adresei de la IPv4 la IPv6 și de la IPv4 la IPv6:

•Server-ul OpenVPN poate fi instalat direct pe agentul de domiciliu (HA) sau pe un alt terminal din subrețeaua de domiciliu

•Clientul OpenVPN este instalat pe nodul mobil (MN)

Rețeaua GPRS a fost utilizata ca rețea de back-up, datorita ariei largi de acoperire,

astfel, conectarea la rețeaua GPRS este inițiată, dar este utilizata doar în cazul în care rețeaua

wireless nu este disponibilă. Prioritățile sunt stabilite în fișierul mipv6.conf, astfel încât

prioritatea Wi-Fi este setata la nivel superior.

Pentru testele de handover, la nivelul de aplicație au fost utilizate programe de streaming multimedia (voce și video), transfer de fișiere (FTP), precum și mesaje de control ICMP6, toate acestea bazate pe IPv6. De asemenea, parametrii de QOS GGSN au fost setați la valorile maxime. Concluzia este că handover-ul nu este perfect, însă timpul de handover al pachetelor pentru streaming multimedia este scurt, sub 30ms, fapt care este considerat acceptabil.

7 Concluzii finale și contribuții originale la QoS pentru comunicații mobile

Odată cu apariția HSDPA (care uneori este menționat ca 3,5 G), lărgimea de bandă disponibilă pentru serviciile de date din rețelele mobile se apropie de viteza de rețelelor fixe (viteze de până la 7Mbiți/s), devenind o soluție viabilă pentru accesul la Internet. Înainte de HSDPA, rețelele 3G, cu viteze practice de 384 kbiți/s, au fost cu aproape un ordin de mărime sub DSL, fiind, totodată soluții destul de scumpe. Beneficiile UMTS sunt legate de faptul că terminalele mobile sunt compatibile 2G (GSM / GPRS), permițându-le să funcționeze în toate domeniile acoperite de GSM / GPRS.

Primele tehnologii, GSM și GPRS, au oferit viteze relativ mici de acces la rețelele de date, comparabile cu dial-up. GPRS a reprezentat un salt important în tehnologie, prin posibilitatea de taxare la volum și nu la durată și prin timpul de stabilire a conexiunii foarte mic

– nu a prins însă la public imediat, pe măsura așteptărilor operatorilor.

EDGE a venit în întâmpinarea așteptărilor utilizatorilor prin mărirea lățimii de bandă până la 384 de kbiți/s, înlesnind îmbunătățirea rețelelor operatorilor fără necesitatea unor noi benzi de frecvență.

UMTS vine cu îmbunătățiri semnificative atât din perspectiva utilizatorilor cât și a

operatorilor de telefonie mobilă prin lățimea de bandă mărită cât și a tehnologiilor noi (noi tipuri de handover, utilizarea mai eficientă a spectrului, servicii noi – videotelefonia etc).

CDMA2000 este tot un standard din a treia generație de rețele de telefonie mobilă ca și

UMTS, oferind viteze de până la 3,1 Mbiți/s.

HSDPA și HSUPA, tehnologii care combinate dau HSPA, aduc transferul de date mobil mai aproape de cel disponibil în rețelele fixe, făcând posibile aplicații de genul streaming-ului de date mobil, telemăsurare, videoconferințe.

LTE este următorul pas în evoluția către rețelele de generația a patra fiind denumit

câteodată și 3,5G. Tot LTE va fi următorul pas și pentru rețelele CDMA2000, deoarece s-a decis stoparea dezvoltării standardului UMB (Ultra Mobile Broadband), care era planificat a înlocui aceste rețele.Rețelele wireless, cu specificațiile IEEE 802.11a, b, g și n sunt soluții de acces de viteză relativ mare, de până la 11 respectiv 54 și, în cazul 802.11n, chiar 600Mbiți/s iar raza lor de acoperire este relativ mică. Alte rețele de tip broadband sunt rețelele WiMAX. Ele oferă pentru distanțe scurte (de până câțiva km) viteze de ordinul zecilor de Mbiți pe secundă, iar în specificațiile mai recente se introduc implementări de QoS.

Bibliografie

1. Publicații ale autorului:

[1] Sandu F., Borza P.N., , W. Szabo – ”Twin-microcontroller GSM Modem Development System”- Proceedings of the 8th International Conference on Optimization of Electrical and Electronic Equipment – OPTIM ‘2002, Brașov, 16 – 17 May 2002

– o citare, într-un articol publicat în Proceedings of 2006 IEEE International Conference on

Automation, Quality and Testing, Robotics – 25-28 May 2006 Cluj-Napoca, Romania

[2] Szekely I., Sandu F., Balica A., – ”Analysis of Wireless Measurement Transmission Performance” – Proceedings of the 15th IMEKO TC 4 Symposium on Novelties in Electrical Measurements and Instrumentation – Iasi, 19 – 21 September, 2007 [ Paper F166 ] – ISSB/ISBN:

978-973-667-260-6, 978-973-667-262-0

[3] Szekely, I., Balan, T., Sandu, F., Cserey, S. – „Optimization of GSM-UMTS core network for IP convergence in 4G through Mobile IPv6” – Optimization of Electrical and Electronic Equipment, 2008. OPTIM 2008. 11th, conferință IEEE – Proceedings indexate ISI – International Digital Object Identifier: 10.1109/OPTIM.2008.4602483, 2008 , Page(s): 217 – 222 – lucrare selectată pentru a fi inclusă într-o monografie: Adibi S., Mobasher A, Tofighbakhsh M. – editors: Fourth-Generation Wireless Networks: Applications and Innovations – ISBN: 978-1-61520-674-2;

416 pp; IGI Global, 2010

[4] Sandu F., Cserey S., Szekely I.,Balan, T.- „Simulation of an advanced mobile communication network” – Optimization of Electrical and Electronic Equipment, 2008. OPTIM 2008

– IEEE – Proceedings indexate ISI – Digital Object Identifier: 10.1109/OPTIM.2008.4602484, 2008, Pag. 223 – 230.

– o citare, într-un articol publicat de “Hardware Verification Group” – Concordia

University – Montreal, Canada

– o citare, într-un articol publicat la ISCC 2009, IEEE Symposium on Computers and

Communications

[6] Sandu F., Szekely I., Balica A. – "Performance Measurement for Mobile Data Streaming" – Computer Standards & Interfaces – The International Journal on the Development and Application of Standards for Computers, Software Quality, Data Communications, Interfaces and Measurement – Elsevier Publications, ISSN: 0920-5489, Volume 32 , Issue 3 (March 2010), pag.

73-85 – Jurnal indexat ISI

[7] V.Cazacu, I.Székely, F.Sandu – “ECG Tele-monitoring Using Intelligent Network Services” – Proceedings of the 2nd International Conference on Recent Achievements in Mechatronics, Automation, Computer Science and Robotics – May 14-15, 2010, Targu Mures, Romania

[8] V.Cazacu, L.Cobarzan, F.Sandu – “Localization of the Mobile Calls Based on SS7

Information and Using Web Mapping Service” – Proceedings of the 2nd International Conference on

Recent Achievements in Mechatronics, Automation, Computer Science and Robotics – May 14-15,

2010, Targu Mures, Romania

– selecționată spre a fi republicată, în versiune extinsă, în Acta Universitatis Sapientiae, Electrical and Mechanical Engineering – Scientific journal of Sapientia University – Targu Mures – Romania, Vol. 2, 2010 – ISSN 2065-5916

[9] F.Sandu, , C.Costache – “BPEL Implementation of QoS-based Management in Multi- modal Mobile Communications” – Proceedings of the International Conference on Development and Application Systems (DAS 2010), 27-29 May 2010, Suceava, Romania, ISSN 1844-5039, pp 191-196

[10] Kayafas E., Sandu F., Nedelcu A. V., Costache C., , Demeter M. – “Tele-measurement Services for m-Learning”, capitol în monografia „Mobile Web 2.0: Developing and Delivering Services to Mobile Phones” – editori S.Ahson și M.Ilyas , 672 pag., ISBN 978-1-4398008-2-9 – ce va apare la CRC Press / Auerbach Publications în 15 decembrie 2010 – http://www.crcpress.com/product/isbn/9781439800829

[11] V. Cazacu, L. Cobarzan, I. Szekely, F. Sandu – Distributed Testing in Agile Service Development Projects, EPE 2010 – The 6th Conference on Electrical and Power Engineering, Iași, Romania

2. Cărți și articole

[1] Adibi S., Mobasher A, Tofighbakhsh M. –”Fourth-Generation Wireless Networks: Applications and

Innovations” – ISBN: 978-1-61520-674-2; 416 pp; IGI Global, 2010

[2] Ambrosch, W.D., Maher, A., Sasscer, B. – The Intelligent Network: A Joint Study by Bell Atlantic.

IBM and Siemens, Springer-Verlag, 1989. ISBN 3-540-50897-X. ISBN 0-387-50897-X.

[3] Balan Titus-Constantin, Sandu Florin,” Fourth-Generation Wireless Networks: Applications and

Innovations”, Pages: 405-423 pp, IGI Global, 2010

[4] Ban, S., Choi, J.K., Kim, H-S., -”Efficient end-to-end QoS mechanism using regress node resource prediction in NGN network”- The 8th International Conference in Advanced Communication Technology (ICACT 2006), Februarie 2006, Volumul 1

[5] Borcoci, E., Balaci, R., Obreja, S., Iorga, R., -”Concurrent implementation of multi-domain service management for end-to-end multimedia delivery” – The 6th International Conference COMMUNICATIONS 2006, Iunie 2006

[6] Callejo-Rodrigitez, M.A., Enriquez-Gabeiras, J., Burakowski, W., Beben, A.; Sliwinski, J., Dugeon, O., Mingozzi, E., Stea, G., Diaz, M., Baresse, L., -”EuQoS: End-To-End QoS over Heterogeneous Networks, Innovations in NGN: Future Network and Services”- K-INGN 2008, First ITU-T Kaleidoscope Academic Conference, Mai 2008

[7] Chiruvolu, G., Agrawal, A., Vandenhoute, M., -”Mobility and QoS support for IPv6-based real-time

wireless Internet traffic” – IEEE Journal on Selected areas in Communications, Volume 22, Number

4, May 2004

[8] Christoph P. Mayer, Thomas Gamer, “Integrating real world applications into OMNeT++”, Institute of Telematics, Universität Karlsruhe (TH), Technischer Bericht, Nr. TM-2008-2, Feb 2008

[9] Devarapalli, V., Gundavelli, S., Chowdhury, K., Muhanna, A. (2007) – ”Proxy Mobile IPv6 and Mobile IPv6 interworking” – Retrieved June 2008, from http://tools.ietf.org/html/draft-devarapalli- netlmm-pmipv6-mipv6-00

[10] Eichler, G., Hussmann, H., Mamais, G., Venieris, I., Prehofer, C., Stefano Salsano, S., –

”Implementing Integrated and Differentiated Services for the Internet with ATM Networks: A Practical Approach” – IEEE Communications Magazine, Ianuarie 2000

[11] Elena Demaria, Ivano Guardini, Michele La Monaca, “Mobile IPv6 deployment opportunities in next generation 3GPP networks”, IST Mobile and Wireless Communications Summit 2007, Budapest, Hungary

[12] G., Eccles, S., -”Service management for end-to-end QoS multimedia content delivery in heterogeneous environment”- Advanced Industrial Conference on Telecommunications/Service Assurance with Partial and Intermittent Resources Conference/E-Learning on Telecommunications Workshop, AICT/SAPIR/ELETE, Iulie 2005

[13] Ganz, A., Ganz, Z., Wongthavarawat, K., -”Multimedia Wireless Networks: Technologies, Standards, and QoS” – Prentice Hall PTR, 2003.

[14] Giordano, S., Salsano, S., Ventre, G., Giannakopoulos, D., – ”Advanced QoS Provisioning in IP Networks: The European Premium IP Projects” – IEEE Communications Magazine, Ianuarie 2003

[15] H. Holma, A. Toskala, “LTE for UMTS – OFDMA and SC-FDMA Based Radio Access”, John

Wiley & Sons Ltd., ISBN 978-0-470-99401-6, 2009

[16] Hardy, W., -”QoS Measurement and Evaluation of Telecommunications Quality of Service”- John

Wiley & Sons, 2001

[17] I. Baumgart, B. Heep, and S. Krause. OverSim: “A Flexible Overlay Network Simulation

Framework. Proceedings of 10th IEEE Global Internet Symposium”. pages 79–84, May 2007

[18] Iera, A., Molinaro, A., ”Quality of service concept evolution for future telecommunication scenarios” – IEEE 16th International Symposium on Personal, Indoor and Mobile Radio Communications, PIMRC 2005, Volumul 4, Septembrie 2005

[19] Kim, M.; Nam, K.; Lee, J.; Hwang-Soo Lee, – ”A Case Study of Policy-based QoS Management in

3G Networks ” – Vehicular Technology Conference (VTC 2003), the 57th IEEE Semiannual Volume

4, Aprilie 2003

[20] Kong, K., Lee, W., Han, Y., You, H. (2008). Mobility Management for All-IP Mobile Networks:

Mobile IPv6 vs. Proxy Mobile IPv6 (2008), IEEE Wireless Communications, April 2008

[21] Kristaly D.M., Sisak F.,Truican I., Moraru S.A. , Sandu F. – ”Web 2.0 technologies in web application development” – Proceedings of the 1st ACM International Conference on Pervasive Technologies Related to Assistive Environments, PETRA 2008, Athens, Greece, July 16-18, 2008

[22] Lei, J., Fu Xiaoming (2007). Evaluating the Benefits of Introducing PMIPv6 for Localized Mobility Management, Technische Berichte des Instituts für Informatikan der Georg-August-Universität Göttingen, 29. June 2007

[23] Lin, Y., Pang, A., (2005). Wireless and Mobile All-IP Networks, November 2005, Wiley Publishing

Inc.

[24] Lloyd-Evans R. – ”GPRS QoS in Integrated 3G Networks” , Artech House 2002

[25] Marchese, M., -”QoS over Heterogeneous Networks” – John Wiley & Sons, 2007

[26] Nedelcu, A.-V.; Sandu, F.; Machedon-Pisu M., M.; Alexandru, M.; Ogrutan, P. – „Wireless-based remote monitoring and control of intelligent buildings” – Robotic and Sensors Environments, 2009. ROSE 2009. IEEE International Workshop. Digital Object Identifier: 10.1109/ROSE.2009.5355999,

2009, Page(s): 47 – 52

[27] Nishida, K., Yokota, H. (2006) – ” Mobility NETLMM Protocol Applicability Analysis for 3GPP

SAE Network”- Retrieved January, 2008, http://tools.ietf.org/html/draft-nishida-netlmm-protocol- applicability-00

[28] Patel,V, McParland, T.(2008) -”Proposed Guidance for IPS Mobility Management Aeronautical

Communication Panel” – August 2008, Montreal, Canada

[29] Pischella, M. Lebeugle, F. Jamaa – ”UMTS to WLAN Handover based on A Priori Knowledge of the Networks , June 2006

[30] Puschiță, E.; Palade, T.; Sandu, F. – ”Intra-System Mobility Evaluation for Different Wireless Technologies” – Wireless and Mobile Communications, 2006. ICWMC '06, conferință internațională IEEE. Digital Object Identifier: 10.1109/ICWMC.2006.57, 2006

[31] Racaru, F., Diaz, M., Chassot, C., -”Quality of Service Management in Heterogeneous Networks”-

International Conference on Communication Theory, Reliability, and Quality of Service, CTRQ'08, Iulie 2008

[32] S. Mohanty – A new architecture for 3G and WLAN integration and inter-system handover

management, 2006

[33] S. Sesia, I. Toufik, M. Baker, “LTE – The UMTS Long Term Evolution From Theory to Practice”, John Wiley & Sons Ltd, ISBN 978-0-470-69716-0, 2009

[34] Sandu F., Borza P.N. , Kayafas E, Moraru S.A. – ”LabVIEW-based remote and mobile access to real and emulated experiments in electronics” – Proceedings of the 1st ACM International Conference on Pervasive Technologies Related to Assistive Environments, PETRA 2008, Athens, Greece, July 16-

18, 2008

[35] Sandu F., Cserey S, Balan T., Romanca M. – ”Simulation-based UMTS e-learning software” – Proceedings of the 1st ACM International Conference on Pervasive Technologies Related to Assistive Environments, PETRA 2008, Athens, Greece, July 16-18, 2008

[36] Sandu, F.; Romanca, M.; Nedelcu, A.; Borza, P.; Dimova, R -„Remote and mobile control in

domotics” – Optimization of Electrical and Electronic Equipment, 2008. OPTIM 2008. 11th , conferință internațională IEEE . Digital Object Identifier: 10.1109/OPTIM.2008.4602527, 2008, Page(s): 225 – 228

[37] Tanenbaum A.S.- Rețele de calculatoare, ed. a 4-a. Edit. BYBLOS, 2003

[38] Xiuhua, F., Wang, J., Zhou, W., Junde, S., -”End-to-End QoS Architecture and Inter-domain QoS Model across Multiple Domains”- International Conference on communication Technology, ICCT

'06, Noiembrie 2006

[39] Y. Bernet, Y., – ”The Complementary Roles of RSVP and Differentiated Services in the Full-Service

QoS Network” – IEEE Communications Magazine, Februarie 2000

[40] Yousaf, Faqir Zarrar – “An Accurate and Extensible Mobile IPv6 (xMIPV6) Simulation Model for

OMNeT++”, Communication Networks Institute, Dortmund University of Technology, Germany

[41] T. Radulescu, H. G. Coanda “QoS in retelele IP multimedia”, Editura Albastra, ISBN 978-973-650-

219-4, 2007

Listă de abrevieri

3GPP 3rd Generation Partnership Project

3GPP2 3rd Generation Partnership Project 2

AAA Authentication, Authorization and Accounting

AM Account Management

APN Access Point Name

AS Application Servers

ASM Algorithmic State Machine

ASN.1 Abstract Syntax Notation One

ATCA Advanced Telecommunications Computing

Architecture

ATM Asynchronous Transfer Mode

AuC Authentication Center

BCCH Broadcast Control Channel

BGCFs Breakout Gateway Control Functions

BPEL The Business Process Execution Language

BGP Border Gateway Protocol BSC Base Station Controller BSS Base Station Subsystem BTS Base Transceiver Station CBR Constant Bit Rate

CDMA Code Division Multiple Access

CM Configuration Management

CMIP Common management information protocol

CMIS Common Management Information Service CORBA Common Object Request Broker Architecture CS Circuit Switched

CSCF Call/Session Control Functions

DCH Dedicated Channel

DSS1 Digital Subscriber Signalling System No. 1

EDGE Enhanced rates for Data Global Evolution

EDCA Enhanced distributed channel access

EIR Equipment Identity Register eNodeB evolved NodeB

ER Error Rate

eUTRAN evolved UTRAN

EV-DO Evolution, Data Only EV-DV Evolution, Data Voice FACH Forward Access Channel

FDD Frequency-Division Duplexing

FM Fault Management

GBR Guaranteed Bit Rate

GGSN Gateway GPRS Support Node GMSK Gaussian Minim Shift Keying GPRS General Packet Radio Service GRE Generic Routing Encapsulation

GSM Global System for Mobile Communications/Groupe

Spécial Mobile

HCF Hybrid coordination function

HLR Home Location Register

HSCSD High-Speed Circuit Switched Data

HSDPA High-Speed Downlink Packet Access

HSPA High-Speed Packet Access

HSS Home Subscriber Server

HSUPA High-Speed Uplink Packet Access IETF Internet Engineering Task Force IMS IP Multimedia Subsystem

IP Internet Protocol

ITU International Telecommunication Union

LLC Logical Link Control

LTE Long Term Evolution

MAC Media Access Control

MIMO Multiple-Input and Multiple-Output

MIP Mobile IP

MME Mobility Management Entity

MNP Mobile Number Portability

MRF Media Resource Functions MSC Mobile Switching Center NAI Network Acces Identifier NAS non-Access Stratum

NE Network Element

NNI Network to Network Interface

OFDM Orthogonal Frequency-Division Multiplexing

OMA Operation-Maintenance-Administration

PCH Paging Channel

PCI Peripheral Component Interconnect

PDA Personal Digital Assistant

PDC Performance Data Collection

PDN Public Data Network

PDN-GW PDN Gateway

PDP Packet Data Protocol

PDTCH Packet Data Traffic Channel

PGW Packet Data Network Gateway

PICMG PCI Industrial Computer Manufacturers Group

PM Performance Management

PMIP Proxy Mobile IP

PS/PO Packet Switched/Packet Oriented

PSDN Public Switched Data Network

PSK Phase-Shift Keying

PSTN Public Switched Telephone Network

QAM Quadrature Amplitude Modulation

QoS Quality of Service

RAN Radio Access Network

RLC Radio Link Control

RLP Radio Link Protocol

RSVP Resource Reservation Protocol

RTP Real-time Transport Protocol

RTT Round-Trip-Time

RTT Radio Transmission Technology

SaaS Software as a Service

SAP Service Access Point

SCTP Stream Control Transmission Protocol

SDP Service Data Point

SDU Service Data Unit

SGSN Serving GPRS Support Node

SGW Serving Gateway

SIP Session Initiation Protocol

SMS Short Message Service

SNMP Simple Network Management Protocol

SOAP Simple Object Access Protocol

SPOTS Suport, Planficare, Operare & mentenanță și analiza

Traficului în Sistem

SS7 Signaling Sysmtem no 7

TDD Time-Division Duplex

TDM Time Division Multiplexing

TDMA Time Division Multiple Access

TMN Telecommunications Management Network

UMB Ultra Mobile Broadband

UMTS Universal Mobile Telecommunication System

UNI User Network Interface

UTRAN UMTS Terrestrial Radio Access Network

VBR Variable Bit Rate

VLR Visitor Location Register

WIMAX Worldwide Interoperability for Microwave Access

WSDL Web Services Description Language

XML Extensible Markup Language

XPDL XML for Process Description Languages