SISTEME ȘI REȚELE DE COMUNICAȚIE

CAP. 1 SISTEME ȘI REȚELE DE COMUNICAȚIE – INTRODUCERE

1.1 MODELE DE REFERINȚĂ - ELEMENTE GENERALE

Deși în prezent sunt dezvoltate o multitudine de sisteme și rețele de comunicație având
nivele diferite de complexitate, toate au la bază un limbaj comun de descriere și se bazează pe
modele de referință clar definite și specificate. Multitudinea de rețele și nivelele diferite de
complexitate au impus modelarea sistemelor și rețelelor de comunicație utilizând structuri bazate
pe niveluri ierarhizate, niveluri ce își oferă unele altora servicii. Serviciile sunt oferite de nivelurile
inferioare celor superioare prin intermediul interfețelor dintre acestea. Un nivel al unei mașini (ca
și componentă a unei rețele – GAZDĂ A din fig. 1, de exemplu) comunică cu un nivel similar din punct
de vedere ierarhic al unei alte mașini (GAZDĂ B din fig. 1) prin intermediul unui protocol specific
acestui nivel. Acest protocol de comunicație este, de fapt, un complex de reguli și convenții ce
permit transferul complet și corect de informație intre cele doua entități la nivel ierarhic respectiv
(fig. 1).

Fig. 1 Model ierarhizat pe 4 niveluri

Transferul de date nu se face direct între nivelurile similare ci prin transferul de pe un nivel
pe altul până când se ajunge la nivelul cel mai de jos (Nivelul 1). Transferul efentiv de date între două

1
 SISTEME ȘI REȚELE DE COMUNICAȚIE

entități (GAZDĂ A și GAZDĂ B, de exemplu – v. fig. 1 se face prin intermediul nivelului fizic care se
afla sub nivelul 1 (nivelul cel mai de jos).

1.2 MODELUL OSI

Modelul OSI are la bază un model propus de Organizația Internațională de Standardizare

(International Standards Organization - ISO) pentru standardizarea interconectării sistemelor
deschise, model numit ISO OSI (OSI = Open Systems Interconnection).
Modelul OSI cuprinde șapte niveluri:
- nivelul FIZIC responsabil de transmiterea biților printr-un canal de comunicație;
- nivelul LEGĂTURĂ DE DATE care asigura un transport sigur, fiabil al datelor;
- nivelul REȚEA determină calea optimă de transfer al datelor într-o rețea constituită din
mai multe segmente;
- nivelul TRANSPORT responsabil de segmentarea datelor pentru a asigura un transfer al
datelor;
- nivelul SESIUNE inițiază, administrează și încheie conexiunile dintre aplicații;
- nivelul PREZENTARE care are rolul de a pregăti datele pentru nivelul APLICAȚIE;
- nivelul APLICAȚIE oferă suport aplicațiilor și proceselor utilizator.

Fig. 2 Modelul OSI

2
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Nivelul FIZIC este responsabil de transmiterea biților printr-un canal de comunicație. Acest
nivel pune la dispoziție prin proiectare toate mijloacele mecanice, electrice, funcționale și
procedurale necesare transmiterii biților între nivelurile superioare (nivelurile LEGĂTURĂ DE DATE).
Gestionarea fluxirilor de date ce sunt transmise de-a lungul mediului de comunicație este realizată
la acest nivel, indiferent de natura sau modul de transmitere a biților (impulsuri electrice în cazul
conexiunilor fizice realizate prin fir de cupru, de exemplu, unde luminoase în cazul conexiunilor prin
fibră optică sau unde radio în cazul comunicațiilor fără fir).
Funcțiile nivelului FIZIC sunt:
- definirea modului în care două sau mai multe dispozitive pot fi conectate fizic;
- definirea modului de transmisie al datelor între două dispozitive (simplex, half-duplex,
full-duplex);
- stabilirea modului de aranjare / interconectare în rețea a dispozitivelor componente
(determină, practic, topologia rețelei);
- determină tipul semnalului utilizat pentru transmiterea informației.
Unitatea de date la acest nivel este bitul.
Nivelul LEGĂTURĂ DE DATE are ca rol principal transformarea unui mijloc de transmisie
oarecare într-o linie sigură de transfer de date, fără a avea erori nedetectate, linie care să fie
disponibila nivelului superior (nivelul REȚEA). Această sarcină este realizată prin forțarea
echipamentelor ce transmit date la un moment dat să descompună datele în cadre (frame-uri, cadre
de date) ce sunt trimise apoi secvențial.
Nivelul LEGĂTURĂ DE DATE definește formatul datelor transferate între dispozitivele din
rețea și este, de asemenea, responsabilul principal al identificării unice a fiecărui dispozitiv dintr-o
rețea locală.
Acest nivel este împărțit în două subniveluri:
- subnivelul MAC (Media Access Control) – controlează modul în care un dispozitiv obține
acces la date și permite transmiterea acestora;
- subnivelul LLC (Logical Link Control) – controlează sincronizarea cadrelor, controlul
fluxurilor de date și verificarea / controlul erorilor.
Funcțiile nivelului LEGĂTURĂ DE DATE sunt:
- completează fluxul de biți ce va fi transferat nivelului FIZIC prin adaugarea unui antet și
a unui sfârșit la cadrele de date;
- antetele care sunt adăugate cadrelor conțin adresele hardware ale sursei, respectiv
destinației datelor; un cadru oarecare format astfel în nivelul LEGĂTURĂ DE DATE este
trimis către adresa de destinație specificată în antet;
- controlul fluxului de date este funcția principală a nivelului LEGĂTURĂ DE DATE; pentru
a nu fi corupte datele transmise se utilizează rate de transfer constante și egale la
transmițător și la receptor – o problemă ce este gestionată la acest nivel este legată de
diferențele de viteze de procesare ale dispozitivelor interconectate - se asigură, de
exemplu, că stația de transmisie, cum ar fi un server cu viteză de procesare mare, nu

3
 SISTEME ȘI REȚELE DE COMUNICAȚIE

depășește din punct de vedere al posibilității de preluare a datelor stația de recepție,

care poate avea o viteză de procesare mai mică;
- controlul erorilor se realizează prin adăugarea în cadrul acestui nivel a unei valori
calculate CRC (Cyclic Redundancy Check) care este plasată la finalul cadrului înainte de a
fi trimis către nivelul FIZIC; dacă pare să apară vreo eroare (CRC incorect) la recepționarea
cadrului / cadrelor, atunci receptorul trimite cerere de retransmitere a cadrelor corupte;
- când două sau mai multe dispozitive sunt conectate la același canal de comunicație,
atunci protocoalele nivelului LEGĂTURĂ DE DATE sunt utilizate pentru a determina ce
dispozitiv are control asupra legăturii la un moment dat.
Unitatea de date la acest nivel este cadrul.
Nivelul REȚEA este responsabil de crearea de circuite virtuale (rute logice) pentru transferul
de date de la un nod de rețea la altul. Acest nivel gestionează, practic, adresarea, rutarea și
localizarea dispozitivelor dintr-o rețea. În cadrul acestui nivel se determină calea ce o urmează
datele de la sursă către destinație ținând cont de condițiile rețelei, de prioritățile serviciilor și de alți
factori.
Funcțiile principale ale nivelului REȚEA sunt:
- interoperabilitatea – funcția principală a acestui nivel; acest nivel furnizează rutele logice
de conectare dintre diferite dispozitive;
- în acest nivel se adaugă adresa sursei și destinației datelor prin adaugarea unui antet
pachetului de date; această adresare este utilizată pentru identificarea dispozitivului in
rețea;
- rutarea este o alta funcție importantă și constă în determinarea căii optime dintr-o
mulțime de căi disponibile pentru transferul de date de la sursă la destinație.
Unitatea de date cu care operează acest nivel este pachetul.
Nivelul TRANSPORT este responsabil de transmiterea completă și corectă a datelor. De
obicei în acest nivel datele se descompun în unități mai mici numite segmente.
Funcțiile principale ale acestui nivel sunt:
- adresare punct de serviciu – calculatoarele, de exemplu, rulează mai multe programe
simultan; din acest motiv transmiterea datelor de la sursă la destinație se face nu numai
de la un calculator la alt calculator, ci și de la un proces la alt proces; nivelul TRANSPORT
adaugă antetul care conține adresa cunoscută sub numele de adresa punctului de
serviciu sau adresa portului; în timp ce responsabilitatea nivelului REȚEA este de a
transmite datele de la un calculator la alt calculator, responsabilitatea nivelului
TRANSPORT este de a transmite mesajul, datele, către procesul corect;
- segmentare și reasamblare – când nivelul TRANSPORT primește mesajul din stratul
superior, acesta împarte mesajul în mai multe segmente și fiecărui segment îi este
atribuit un număr de secvență; acest număr identifică în mod unic fiecare segment în
parte; în sens invers, când datele au ajuns la destinație, nivelul TRANSPORT reasamblează
mesajul pe baza numerelor lor de ordine / secvență;

4
 SISTEME ȘI REȚELE DE COMUNICAȚIE

- controlul conexiunii - nivelul TRANSPORT oferă două tipuri de servicii: serviciu orientat
spre conexiune și serviciu fără conexiune; un serviciu fără conexiune tratează fiecare
segment ca un pachet individual de date și toate segmentele sunt transferate pe rute
diferite pentru a ajunge la destinație; un serviciu orientat spre conexiune face o
conexiune cu nivelul TRANSPORT la mașina (gazda) destinație înainte de livrarea
pachetelor de date, în cazul acestui serviciu (orientat spre conexiune), toate pachetele
de date fiind transferate pe o singură rută;
- controlul fluxului – nivelul TRANSPORT este responsabil și de controlul fluxului de date;
- controlul erorilor – nivelul TRANSPORT este, de asemenea, responsabil pentru controlul
erorilor; nivelul TRANSPORT de la dispozitivul expeditor trebuie să asigure faptul că
mesajul ajunge la destinație fără nicio eroare.
Unitatea de date cu care operează acest nivel este TPDU (Transport Protocol Data Unit).
Nivelul SESIUNE gestionează sesiunile ce se stabilesc între doi interlocutori dintr-un sistem
sau o rețea de comunicație. Gestionarea acestor sesiuni acoperă toate aspectele: inițiere sesiune,
menținere și interacțiune între dispozitivele interconectate.
Funcțiile principale ale nivelului SESIUNE sunt:
- controlul dialogului – nivelul SESIUNE acționează ca un controler de dialog care creează
și menține schimbul de date dintre două procese, schimb de date care poate fi half-
duplex sau full-duplex;
- sincronizare – nivelul SESIUNE adaugă câteva puncte de control atunci când se transmit
datele într-o secvență; dacă apare o eroare în mijlocul transmiterii datelor, atunci
transmisia va avea loc din nou de la ultimul punct de control validat; acest proces este
cunoscut sub numele de “sincronizare și recuperare”.
Unitatea de date cu care operează acest nivel este SPDU (Session (layer) Protocol Data Unit).
Nivelul PREZENTARE se ocupă în principal de sintaxa și semantica informațiilor schimbate
între cele două sisteme interconectate. Acest nivel este, în fapt, un translator de date pentru o rețea.
Acest nivel este o parte a sistemului de operare care convertește datele dintr-un format de
prezentare în alt format. Nivelul PREZENTARE este, de asemenea, cunoscut sub numele de nivel de
sintaxă.
Funcțiile de bază ale acestui nivel sunt:
- traducere – procesele din două sisteme schimbă informațiile sub formă de șiruri de
caractere, numere și așa mai departe; diferite calculatoare folosesc metode de codificare
diferite, stratul de prezentare gestionând interoperabilitatea chiar și în cazul utilizării
diferitelor metode de codificare; acest nivel convertește datele din formatul dependent
de expeditor într-un format comun și schimbă formatul comun în format dependent de
receptor;
- criptare – această funcție este necesară pentru a se asigura accesul securizat,
confidențial, la date;
- compresie – compresia datelor este un proces de comprimare a acestora, adică de
reducere a numărului de biți care trebuie transmiși.

5
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Unitatea de date cu care operează acest nivel este PPDU (Presentation Protocol Data Unit).
Nivelul APLICAȚIE servește ca interfață între utilizatori și o parte din procesele aplicației,
procese ce permit accesarea serviciilor de rețea. Acest nivel se ocupă de probleme precum
transparența rețelei, alocarea resurselor etc. Este important de precizat faptul că nivelul APLICAȚIE
nu este o aplicație în sine. Practic, acest nivel oferă servicii de rețea utilizatorilor finali.
Două exemple de funcții ale acestui nivel funcții ce sunt frecvent utilizate sunt:
- transferul, accesul și managementul fișierelor – nivelul APLICAȚIE îi permite utilizatorului
să acceseze fișierele de pe un calculator la distanță, de exemplu, să preia fișierele de pe
acesta sau, în general, să gestioneze la distanță fișierele de pe acest dispozitiv;
- servicii de e-mail – nivelul APLICAȚIE oferă facilitatea pentru redirecționarea și stocarea
e-mailurilor.
Unitatea de date cu care operează acest nivel este APDU (Application Protocol Data Unit).
Transmiterea de date între două entități (echipamente, dispozitive, procese) se poate
imagina ușor, prin parcurgerea pe niveluri a modelului OSI, în cadrul fiecărui nivel prelucrându-se
corespunzător datele. În exemplul de mai jos, în cadrul fiecărui nivel se adaugă câte un antet specific
nivelului respectiv, antet ce are rolul de a trimite datele în siguranță, necompromise și către
destinatarul bine identificat. În cadrul nivelului LEGĂTURA DE DATE pachetului de date i se adaugă
și un sfârșit de pachet cu rol, de regulă, de verificare la recepție a integrității pachetului.

Fig. 3 Exemplu de transmisie date între două procese utilizând modelul OSI

6
 SISTEME ȘI REȚELE DE COMUNICAȚIE

1.3 MODELUL TCP/IP

Modelul OSI a fost conceput pentru a descrie funcțiile unui sistem de comunicații prin
împărțirea elementelor specifice transferului datelor în componente mai mici și mai simple și cu
funcționalități clare, precise. Modelul TCP / IP a fost proiectat și dezvoltat de către Departamentul
Apărării al Statelor Unite în anii 1960 pentru a permite transmiterea corectă și sigură a datelor între
dispozitive. Acest model este o versiune restrânsă a modelului OSI. Deși inițial a fost dezvoltat
pentru a fi utilizat doar de Ministerul de Apărare, mai târziu a fost adoptat pe scară largă. Scopul
principal al acestui model este de a conecta două mașini la distanță pentru schimbul de informații,
cele două mașini putând funcționa în rețele diferite putând chiar avea arhitecturi diferite. Modelul
TCP/IP conține patru niveluri, spre deosebire de șapte niveluri în cazul modelului OSI (fig. 4).

Fig. 4 Modelele OSI, respectiv TCP/IP

Aceste niveluri sunt apropiate de cele ale modelului OSI. Nivelul APLICAȚIE din modelul
TCP/IP are aceleași funcționalități ca și nivelurile superioare din modelul OSI (APLICAȚIE,
PREZENTARE și SESIUNE). Nivelul TRANSPORT al modelului TCP/IP este similar cu același nivel din
modelul OSI, nivelul INTERNET operează ca și modelul REȚEA, iar nivelul INTERFAȚĂ REȚEA (sau
ACCES REȚEA) are funcționalitățile specifice nivelelor inferioare din OSI (nivelul LEGĂTURĂ DE DATE,
respectiv nivelul FIZIC).
Nivelul INTERFAȚĂ REȚEA este cel mai jos nivel al modelului TCP/IP.
Acest nivel este combinația dintre nivelul FIZIC și nivelul LEGĂTURĂ DE DATE definit în
modelul de referință OSI. Acest nivel definește modul în care datele trebuie trimise fizic prin rețea.
Responsabilitatea principală a acestui nivel este transmiterea datelor între două dispozitive din
aceeași rețea. Funcțiile principale sunt încapsularea datagramei IP în pachetele transmise prin rețea
și maparea adreselor IP în adrese fizice. Protocoalele folosite de acest nivel sunt Ethernet, Token
Ring, FDDI, X.25, Frame Relay.

7
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Nivelul INTERNET este al doilea nivel al modelului TCP/IP. Acest nivel este cunoscut și sub
numele nivel REȚEA. Principala responsabilitate a acestui nivel este de a trimite pachetele din orice
rețea către orice destinație, indiferent de ruta parcursă.
În cadrul acestui nivel sunt utilizate urmatoarele protocoale: IP, ARP și ICMP.
Protocolul IP (Internet Protocol) este cel mai semnificativ protocol din întreaga suită TCP /
IP. Responsabilitățile acestui protocol sunt:
- adresare IP - acest protocol implementează adrese de gazdă logice cunoscute sub
numele de adrese IP; adresele IP sunt folosite de nivelul Internet și de nivelurile
superioare pentru a identifica dispozitivul și pentru a facilita rutarea în Internet;
- comunicare gazdă – gazdă - determină calea prin care urmează să fie transmise datele;
- încapsularea și formatarea datelor - protocolul IP acceptă datele din protocolul nivelului
TRANSPORT; protocolul IP asigură faptul că datele sunt trimise și primite în siguranță,
încapsulează datele într-un mesaj cunoscut sub numele de datagramă IP;
- fragmentare și reasamblare - limita impusă mărimii datagramei IP de protocolul stratului
de legătură de date este cunoscută sub numele de unitate maximă de transmisie (MTU -
Maximum Transmission Unit) ; dacă dimensiunea datagramei IP este mai mare decât
unitatea MTU, atunci protocolul IP împarte datagrama în unități mai mici, astfel încât
acestea să poată fi transmise prin rețeaua locală; la receptor toate fragmentele sunt
reasamblate pentru a forma mesajul original;
- rutare - când datagrama IP este trimisă în aceeași rețea locală transmisia este cunoscută
sub numele de livrare directă; când sursa și destinația se află în rețele diferite, atunci
datagrama IP este trimisă indirect, acest lucru putând fi realizat prin rutarea datagramei
IP prin diferite dispozitive precum router-ele.
Protocolul ARP (Address Resolution Protocol) este utilizat pentru a determina adresa fizică
din adresa IP. Acestui protocol îi sunt asociați doi termeni: cerere ARP, respectiv răspuns ARP. Când
un expeditor dorește să cunoască adresa fizică a dispozitivului, acesta transmite către rețea o cerere
ARP. Fiecare dispozitiv atașat la rețea acceptă cererea ARP, o procesează, dar numai destinatarul
(care își recunoaște adresa IP) îi trimite înapoi adresa fizică sub formă de răspuns ARP. Destinatarul
adaugă adresa fizică atât în memoria cache, cât și în antetul datagramei.
Protocol ICMP (Internet Control Message Protocol) este un mecanism folosit de gazde sau
router-e pentru a trimite notificări înapoi către expeditor cu privire la problemele datagramelor. O
datagramă se transferă de la un router la altul până când ajunge la destinație. Dacă un router nu
poate direcționa datele din cauza unor condiții neobișnuite (legăturile dezactivate, dispozitive
defecte, congestie de rețea etc.), atunci protocolul ICMP este utilizat pentru a informa expeditorul
că datagrama nu poate fi livrată. ICMP folosește în principal doi termeni: test ICMP, respectiv
răspuns ICMP. Testul ICMP este utilizat pentru a testa dacă destinația este accesibilă sau nu.
Răspunsul ICMP este utilizat pentru a verifica dacă dispozitivul de destinație răspunde sau nu.
Responsabilitatea principală a protocolului ICMP este de a raporta problemele, nu de a le
corecta. Responsabilitatea corectării îi revine expeditorului.

8
 SISTEME ȘI REȚELE DE COMUNICAȚIE

ICMP poate trimite mesajele numai către sursă, dar nu către routerele intermediare,
deoarece datagrama IP transportă adresele sursei și destinației, nu și cele ale routerului către care
este transmisă.
Nivelul TRANSPORT este responsabil de fiabilitatea transmiterii datelor, controlul fluxului
de date și corectarea datelor care sunt trimise prin rețea dacă este cazul. În cadrul acestui nivel sunt
utilizate două protocoale: UDP și TCP.
Protocolul UDP (User Datagram Protocol) oferă servicii fără conexiune. Este un protocol
nesigur, deoarece descoperă erorile, dar nu specifică care sunt acestea. UDP descoperă eroarea, iar
prin intermediul unui protocol (ICMP - Internet Control Message Protocol) raportează expeditorului
faptul că pachetul de date a fost deteriorat.
Protocolul UDP conține următoarele câmpuri:
- adresa portului sursă - este adresa programului de aplicație care a creat mesajul;
- adresa portului de destinație - este adresa programului de aplicație care primește
mesajul;
- lungime totală - definește numărul total de octeți ai pachetului de date a utilizatorului în
octeți;
- suma de control (checksum) - este un câmp pe 16 biți utilizat pentru detectarea erorilor.
UDP nu specifică ce pachet este pierdut / compromis. UDP conține doar suma de control, nu
conține niciun ID al vreunui segment de date.
Protocolul TCP (Transmission Control Protocol) oferă servicii complete de strat de transport
către aplicații. TCP creează un circuit virtual între emițător și receptor și este activ pe durata
transmisiei. TCP este un protocol de încredere, deoarece detectează eroarea și permite
retransmiterea cadrelor deteriorate. Prin urmare, se asigură că toate segmentele trebuie primite și
confirmate înainte ca transmisia să fie considerată finalizată și să se elimine circuitul virtual. TCP
împarte întregul mesaj în unități mai mici cunoscute sub numele de segmente și fiecare segment
conține un număr de identificare, număr necesar pentru reordonarea cadrelor în vederea reformării
mesajului original (la sfârșitul primirii tuturor segmentelor TCP le reordonează pe baza numerelor
de identificare).
Nivelul APLICAȚIE este nivelul superior din modelul TCP/IP și este responsabil de gestionarea
protocoalelor la nivel înalt și de problemelor de reprezentare. Acest nivel permite interacțiunea
dintre utilizator și aplicație. În cazul în care mașina trimite date, nivelul APLICAȚIE transmite datele
către nivelul TRANSPORT. În cazul în care mașina primește date, nivelul APLICAȚIE primește date de
la nivelul TRANSPORT. În acest nivel se încadrează doar aplicațiile ce interacționează direct cu
sistemul de comunicații. De exemplu, în acest strat nu se poate include un editor simplu de test,
însă browser-ul WEB ce folosește protocolul HTTP, da.
Cele mai importante protocoale utilizate în acest nivel sunt:
- HTTP (HyperText Transfer Protocol) - reprezintă protocolul de transfer hipertext; acest
protocol permite accesarea datelor de pe Internet; transferă datele sub formă de text
simplu, audio, video. Este cunoscut sub numele de protocol de transfer hipertext

9
 SISTEME ȘI REȚELE DE COMUNICAȚIE

deoarece este eficient în utilizarea în medii hipertext în care există salturi rapide de la un
document la altul;
- SNMP (Simple Network Management Protocol) - este un protocol de gestionare simplă
a rețelei; acest protocol constituie cadrul utilizat pentru gestionarea dispozitivelor de pe
Internet utilizând suita de protocol TCP/IP;
- SMTP (Simple Mail Transfer Protocol) - înseamnă protocolul simplu de transfer de email;
acest protocol este utilizat pentru a trimite datele de la o adresă de email către o altă
adresă de email;
- DNS (Domain Name System) - o adresă IP este utilizată pentru a identifica în mod unic
conexiunea unei gazde la Internet, însă este preferată utilizarea numelor în loc de adrese;
sistemul responsabil de maparea numelor, respectiv a adreselor are la bază protocolul
DNS;
- TELNET (TErminaL NETwork) - este un protocol ce stabilește conexiunea între un
calculator local și unul aflat la distanță în așa fel încât terminalul sistemul la distanță pare
să fie terminalul sistemului local;
- FTP (File Transfer Protocol) - este un protocol de Internet standard utilizat pentru
transmiterea fișierelor de la o mașină la alta.
În prezent este frecvent utilizat modelul TCP/IP cu 5 niveluri. În cazul acestui model, nivelul
INTERFAȚĂ REȚEA este divizat în două niveluri, la fel ca la modelul OSI: nivelul LEGĂTURĂ DE DATE,
respectiv nivelul FIZIC (fig. 5).

Fig. 5 Modelele TCP/IP cu 4, respectiv 5 niveluri

Nivelul FIZIC tratează datele sub formă de biți. Acest nivel gestionează în principal
comunicarea gazdă - gazdă în rețea, definește mediul de transmisie și modul de comunicare între
două dispozitive. Mediul poate fi cu fir sau fără fir, iar modul poate fi simplex, half-duplex sau full-
duplex, toate acestea ca și în cazul modelului OSI. Tot în cadrul acestui nivel se specifică configurația
liniei (punct-la-punct sau multiport), rata de transfer (numărul de biți trimiși în fiecare secundă) și
topologia rețelei. Nu există protocoale specifice care sunt utilizate în acest nivel.

10
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Nivelul LEGĂTURĂ DE DATE este al doilea nivel al modelului TCP/IP. Tratează datele sub
formă de cadre de date (cadre, frame-uri). În acest nivel se adaugă adresa sursei, respectiv adresa
destinației. Nivelul LEGĂTURĂ DE DATE facilitează livrarea de cadre în aceeași rețea. De asemenea,
facilitează controlul fluxului și erorilor transmisiei cadrelor de date. Prin rata de transmisie se
controleaza, de asemenea, fluxul de date. Erorile de transmisie și cadrele de date compromise pot
fi detectate prin sumele de control și se pot retransmite folosind informațiile din antetul specific
acestui nivel.
Internetul obiectelor (Internetul lucrurilor, Internet of Things, IoT) descrie rețeaua de
obiecte fizice sau lucruri care integrează senzori, software și/sau alte tehnologii în scopul conectării
și schimbului de date cu alte dispozitive și/sau sisteme prin intermediul Internetului.
“Lucrurile” au evoluat datorită convergenței mai multor tehnologii precum analize în timp
real, învățare automată, dezvoltarea de dispozitive cu putere de procesare din ce în ce mai mare,
resurse hardware integrate din ce în ce mai bogate etc. Toate acestea au încurajat și întrețin
permanent ideea de interconectare globală. Evident că la aceste aspecte se adaugă și multe alte
avantaje precum costuri de întreținere reduse, timpi de intervenție semnificativ reduși, posibilitatea
de monitorizare și control de la distanță etc.
Deși pe piața consumatorilor tehnologia IoT este în general asociată produselor care aparțin
conceptului de “casă inteligentă”, domeniile de aplicare sunt foarte diverse: sănătate, agricultura
de precizie, învățământ, o gamă largă de domenii inginerești, mediu etc. Deși avantajele sunt
evidente, există și o serie de dezavantaje legate în general de îngrijorări serioase cu privire la
confidențialitate și securitate. Pentru a se reduce aceste riscuri exista preocupari seriaose în
domeniu, inclusiv dezvoltarea de standarde internaționale.
Unele dintre protocoalele de rețea care sunt adoptate pe scară largă în cadrul IoT sunt
protocoale ce se pot asocia direct nivelurilor specifice modelului TCP / IP – fig. 6.

Fig. 6 Asocierea nivelelor modelului TCP/IP cu cele mai utilizate protocoale în IoT

11
 SISTEME ȘI REȚELE DE COMUNICAȚIE

CAP. 2 PROTOCOLUL MQTT

2.1 PROTOCOLUL MQTT – NOȚIUNI INTRODUCTIVE

MQTT (Message Queuing Telemetry Transport) este un protocol simplu, deschis, de
mesagerie care oferă clienților unei rețele constrânși de resurse un mod simplu de a distribui
informații de telemetrie (transmiterea valorilor măsurate de la un senzor amplasat în punctul de
măsurare către o locație separată spațial) în medii cu lățime de bandă redusă (lățimea de bandă
reprezintă capacitatea unei rețele de a transmite o anumită cantitate de date de la un punct la altul
într-un anumit interval de timp). Protocolul MQTT folosește un model de comunicare “publish /
subscribe” (publicare / abonare) și este utilizat pentru comunicarea mașină - mașină (M2M –
Machine-to-Machine). Deși acronimul MQTT este derivat din “Message Queuing Telemetry
Transport” ce s-ar putea traduce ca “transport (de date) de telemetrie în coadă de mesaje”, în MQTT
nu se utilizează cozi de mesaje.
MQTT a fost creat ca un protocol cu costuri reduse din punct de vedere al resurselor
necesare - se adaptează la o lățime de bandă redusă și la limitări severe ale hardware-ului; practic,
MQTT a fost conceput pentru a se implementa în sistemele încorporate. Protocolul MQTT este
potrivit ca și alegere pentru rețelele fără fir care au niveluri diferite de latență datorită
constrângerilor ocazionale de lățime de bandă sau pentru rețelele cu conexiuni nesigure. Ca și
domenii de aplicare, MQTT se poate implementa într-un spectru larg de domenii industriale, de la
industria automotive la energie și telecomunicații.
Inițial MQTT a fost un protocol proprietar, utilizat pentru transferul de date în sisteme SCADA
(Supervisory Control And Data Acquisition) în industria petrolului și gazelor, acesta a devenit ulterior
popular în arena dispozitivelor inteligente, astăzi fiind protocolul open-source principal pentru
conectarea IoT sau IIoT (Industrial IoT).
Destinat optimizării lățimii de bandă disponibile, modelul de transfer de date MQTT (care
este un model publish / subscribe) este o alternativă la arhitectura tradițională de tip client – server.
Spre deosebire de arhitectura client – server, în cazul modelului publish / subscribe clientul care
trimite un mesaj (editorul) este decuplat de clientul sau clienții care primesc mesajele (abonații).
Deoarece nici editorii și nici abonații nu se contactează direct, trebuie asigurată legătura dintre
aceștia, această responsabilitate revenindu-le broker-ilor (fig. 7).
Clienții MQTT includ editorii (publishers) și abonații (subscribers), termeni care se referă la
faptul dacă clientul publică mesaje (publisher) sau este abonat (subscriber) pentru a primi mesaje.
Aceste două funcții pot fi implementate separat (un client poate fi editor sau abonat) sau împreună
(un client poate fi atât editor cât și abonat). În cazul modelelor publish / subscribe (publisher /

12
 SISTEME ȘI REȚELE DE COMUNICAȚIE

subscriber) prin intermediul broker-ului clienții (unul sau mai mulți clienți) se pot “abona” la
subiectele de interes.

Fig. 7 Protocolul MQTT

Dacă conexiunea de la un client abonat la un broker este întreruptă, atunci broker-ul va
memora mesajele și i le va transmite abonatului atunci când se restabilește conexiunea. Dacă
conexiunea de la un client ce publică la broker este întreruptă fără notificare prealabilă, atunci
broker-ul poate închide conexiunea și trimite abonaților un mesaj cu instrucțiuni de la editor.
Pe scurt, modelul publisher / subscriber folosit de protocolul MQTT poate fi descris astfelȘ
- editorii trimit mesajele;
- abonații primesc mesajele de care sunt interesați;
- brokerii transmit mesajele de la editori către abonați;
- editorii și abonații sunt clienți ai unui broker MQTT;
- clienții MQTT pot fi orice dispozitiv sau aplicație care rulează o bibliotecă MQTT.
Un broker MQTT operează ca intermediar între clienții care trimit mesaje (editori) și clienții
care primesc aceste mesaje (abonați). Este posibil ca un broker să fie nevoit să gestioneze un volum
important de clienți MQTT conectați simultan, astfel încât atunci când se alege un broker MQTT
trebuie evaluete caracteristicile acestuia scalabilitate, integrare, capacitatea de monitorizare dar și
capacitățile de rezistență la eșecuri.
O sesiune MQTT este împărțită în patru etape: stabilire conexiune, autentificare, transfer
date și, în final, terminare conexiune.
Un client începe prin crearea unei conexiuni pentru transferul de date prin protocol TCP / IP
către broker utilizând fie un port standard, fie un port personalizat definit de operatorii broker-ului.
Porturile standard sunt 1883 pentru comunicații necriptate și 8883 pentru comunicații criptate -
utilizând Secure Sockets Layer (SSL) / Transport Layer Security (TLS). În timpul inițierii conexiunii SSL
/ TLS, clientul validează certificatul de server și autentifică serverul. De asemenea, clientul poate
furniza un certificat de client broker-ului, acesta fiind responsabil de autentificarea clientului. Deși
nu face parte în mod specific din specificațiile protocolului MQTT, a devenit obișnuit ca broker-ii să
sprijine autentificarea clientului cu certificate SSL / TLS primite de la acesta (de la client).

13
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Deoarece protocolul MQTT își propune să fie un protocol și pentru dispozitive cu resurse
modeste, este posibil ca SSL / TLS să nu fie întotdeauna o opțiune și, în unele cazuri, chiar să nu fie
de dorit. În astfel de situații, autentificarea este prezentată ca un nume de utilizator și o parolă cu
text clar, care sunt trimise de client către server în secvența de pachete specifică inițierii conexiunii
(CONNECT / CONNACK – fig. 8). În plus, unii broker-i acceptă clienți anonimi. În astfel de cazuri,
numele de utilizator și parola sunt lăsate necompletate.
MQTT este considerat un protocol ușor, simplu, deoarece toate mesajele sale au o amprentă
de cod mică. Fiecare mesaj constă dintr-un antet fix - 2 octeți - un antet variabil opțional, mesajul
care este limitat la 256 MB și un nivel de calitate a serviciului (QoS).
În timpul fazei de transfer de date, un client poate efectua operații de publicare, abonare,
dezabonare și testare dispozitiv (”ping”). Operația de publicare trimite un bloc binar de date
(conținutul util) către un subiect definit de editor. MQTT acceptă obiecte mari binare pentru mesaje
(până la 256 MB). Formatul conținutului va fi specific aplicației. Abonarea la subiecte se face folosind
o pereche de pachete (SUBSCRIBE / SUBACK); dezabonarea se efectuează în mod similar
(UNSUBSCRIBE / UNSUBACK). Șirurile de subiecte formează un arbore de subiect, calea către
subiectul propriu-zis fiind formată prin utilizarea unui delimitator special (/) de-a lungul arborelui.
Un client se poate abona “la” și se poate dezabona ”de la” ramuri întregi din arborele subiectului
folosind caractere speciale cu metacaracter. Există două metacaractere:
- un metacaracter cu un singur nivel (caracterul plus: +);
- un metacaracter pe mai multe niveluri, (caracterul ”hash”/diez: #).
Un caracter de subiect special este caracterul $; el exclude un subiect din orice abonare. De
obicei, acest caracter ($) este utilizat pentru transportul mesajelor specifice serverului sau ale
sistemului. O altă operațiune pe care un client o poate efectua în timpul fazei de comunicare este
de testare dispozitiv (ping) folosind o secvență de pachete specifice (PINGREQ / PINGRESP). Această
operațiune nu are altă funcție decât să mențină o conexiune și să asigure o conexiune TCP
neîntreruptă de un gateway sau router. Când un editor sau un abonat dorește să încheie o sesiune
MQTT, acesta trimite un mesaj specific (DISCONNECT) către broker și apoi închide conexiunea.
Aceasta se numește închidere grațioasă, deoarece oferă clientului posibilitatea de a se reconecta cu
ușurință, oferindu-i identitatea clientului și reluând din locul în care s-a rămas. În cazul în care
deconectarea se întâmplă brusc, fără ca editorul să trimită un mesaj specific (DISCONNECT), broker-
ul poate trimite abonaților un mesaj de la editor pe care brokerul l-a memorat anterior. Mesajul se
numește ultima dorință sau testament și oferă abonaților instrucțiuni despre ce trebuie să facă dacă
editorul moare (dispare) subit (în mod neașteptat).
Așa cum s-a mai precizat, simplitatea arhitecturii protocolului MQTT ajută la asigurarea unui
transfer de date fără probleme legate lățimea de bandă disponibilă și, de asemenea, pune presiune
redusă pe resursele hardware (în general CPU și RAM).
Printre avantajele MQTT față de protocoalele concurente merită amintite:
- transmisie de date eficientă și aplicații ușor de implementat;
- încărcare redusă a rețelei datorită pachetelor de date minimizate;
- distribuirea eficientă a datelor;

14
 SISTEME ȘI REȚELE DE COMUNICAȚIE

- implementarea cu succes a teledetecției și controlului;

- livrare rapidă și eficientă a mesajelor;
- folosește cantități mici de energie (nu necesită resurse hardware deosebite);
- optimizează lățimea de bandă a rețelei.

Fig. 8 Tipuri de mesaje MQTT

Comparativ cu protocoalele concurente MQTT are și o serie de dezavantaje:
- MQTT are cicluri de transmisie mai lente comparativ cu alte protocoale similare (de
exemplu protocolul CoAP);
- descoperirea resurselor MQTT funcționează pe abonări flexibile la subiecte diverse, în
timp ce alte protocoale (CoAP, de exemplu) utilizează un sistem stabil de descoperire a
acestora (resurselor);
- MQTT este necriptat (se poate folosi criptarea TLS / SSL doar în anumite situații);
- este dificilă dezvoltarea unei rețele MQTT scalabilă la nivel global;
- MQTT este mai sensibil la subiecte precum securitate, interoperabilitate, autentificare.
Structura subiectului în cazul protocolului MQTT poate forma cu ușurință un arbore complex,
neexistând o modalitate clară de fragmentare în arbori mai mici, ușor de gestionat. Acest lucru face
dificilă crearea unei rețele MQTT scalabile la nivel global, deoarece, pe măsură ce dimensiunea
arborelui subiect crește, complexitatea transmiterii datelor crește.

15
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Un alt aspect negativ al MQTT se referă la lipsa sa de interoperabilitate. Deoarece încărcările

utile ale mesajelor sunt binare, fără informații cu privire la modul în care sunt codificate, pot apărea
probleme - mai ales în arhitecturi deschise în care se presupune că diferite aplicații de la diferiți
producători funcționează perfect între ele.
După cum s-a spus anterior, MQTT are caracteristici de autentificare minime încorporate în
protocol. Numele de utilizator și parolele sunt trimise în text clar (în anumite situații), iar orice formă
de utilizare sigură a MQTT trebuie să utilizeze protocolul SSL / TLS, care, din păcate, nu este un
protocol ușor.
Autentificarea clienților cu certificate de partea clientului nu este un proces simplu și nu
există nicio modalitate în MQTT de a controla cine deține un subiect și cine poate publica informații
despre acesta, cu excepția utilizării mijloacelor proprii. Acest lucru face mai ușoară penetrarea
rețelei cu mesaje dăunătoare, intenționat sau chiar din greșeală.
În cazul MQTT nu există nicio modalitate prin care receptorul de mesaje să știe cine a trimis
mesajul original, cu excepția cazului în care aceste informații sunt conținute în mesajul real. Din
acest motiv, funcțiile de securitate care trebuie implementate în plus față de MQTT tradițional, într-
o manieră proprietar, sporesc amprenta codului și îngreunează implementările.
Datorită simplității sale, MQTT face pereche bună cu aplicațiile care implică monitorizarea
de la distanță, câteva posibile domenii fiind:
- monitorizarea senzorilor din sistemele de supraveghere antiefracție și antiincendiu (de
exemplu detectoarele de fum, senzori de mișcare etc.);
- monitorizarea parametrilor de sănătate utilizând senzori pentru pacienții care părăsesc
un spital;
- senzori care alertează oamenii despre existența unui pericol;
- o altă aplicație posibilă este o aplicație de mesagerie bazată pe text pentru comunicare
în timp real, aplicație care valorifică necesarul redus de resurse al MQTT (date și, implicit,
energie) ; Facebook, de exemplu, folosește protocolul MQTT pentru aplicația Messenger,
nu numai pentru că protocolul conservă energia bateriei în timpul mesageriei de la
telefon mobil la telefon, ci și pentru că protocolul permite livrarea eficientă a mesajelor
în ciuda conexiunilor incoerente la Internet; în plus, majoritatea furnizorilor majori de
servicii cloud, inclusiv Amazon Web Services (AWS), Google Cloud, IBM Cloud și Microsoft
Azure, acceptă MQTT;
- MQTT este potrivit pentru aplicații care utilizează conectivitatea M2M și IoT în scopuri
precum analiza de date în timp real, întreținerea predictivă și monitorizare în diverse
medii (case inteligente, agricultură de precizie, asistență medicală, logistică, industrie și
producție și multe alte domenii).
Deoarece clienții MQTT necesită resurse minime ei pot fi implementați utilizând
microcontrolere ieftine, cu resurse hardware modeste. Pentru optimizarea lățimii de bandă a rețelei,
antetele MQTT sunt mici și, în plus, MQTT permite interconectarea unui număr impresionant de
dispozitive. Ca urmare, MQTT este în prezent unul dintre cele mai frecvent utilizate protocoale în
infrastructura IoT și IIoT.

16
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Câteva exemple de domenii (de actualitate!) în care protocolul MQTT își poate demostra
utilitatea sunt:
- contorizare inteligentă - protocolul MQTT poate fi utilizat pentru a transmite date ce
asigură citiri precise ale contoarelor de energie în timp real, ceea ce permite facturarea
corectă cu precădere în sistemele centralizate;
- centralizarea datelor furnizate de senzori ambientali – senzorii ambientali utilizați în
locații îndepărtate sunt adesea dispozitive cu consum redus de energie, astfel încât
MQTT este o alegere bună integrarea acestor senzori în IoT;
- preluarea informațiilor de stare pentru mentenanța utilajelorde sănătate ale mașinilor;
- sisteme de facturare - MQTT ajută la eliminarea pachetelor de mesaje duplicate sau
pierdute în facturare.
Foarte multe platforme IoT acceptă protocolul MQTT (de exemplu Carriots, Evrythng,
ThingWorx etc.).
Protocolul MQTT are, în mod evident, o serie de protocoale concurente, între care:
- CoAP - Constrained Application Protocol – acest protocol folosește un model de
comunicare de tip cerere / răspuns; CoAP este conceput special pentru hardware cu
resurse limitate; hardware-ul care nu acceptă HTTP sau TCP / IP poate utiliza protocolul
CoAP; acest protocol s-a dezvoltat având ca punct de pornire protocolul HTTP;
- AMQP - Advanced Message Queuing Protocol – la fel ca MQTT, AMQP folosește un model
de comunicare de tip publicare / abonare;
- STOMP - Simple (sau Streaming) Text Oriented Message Protocol – este un protocol
bazat pe text; STOMP este un protocol bazat pe cadre modelate pe HTTP; deși STOMP
este bazat pe text el permite și transmiterea mesajelor binare;
- SMCP - Simple Media Control Protocol – este o stivă de protocol CoAP pentru dispozitive
încorporate; este dezvoltat în limbajul C și poate fi utilizat pentru trimiterea și primirea
de răspunsuri asincrone CoAP;
- SSI - Simple Sensor Interface – este un protocol de nivel APLICAȚIE conceput pentru
comunicarea dintre unități centrale și senzori; datele sunt transmise de către senzori
către unitățile centrale cu amprente mici de cod; în cazul acestui protocol mesajul dintre
senzor și unitatea centrală conține un antet de 2 octeți și datele utile; antetul conține o
adresă pe un singur octet și o comandă sau un tip de mesaj de asemenea pe un singur
octet;
- DDS - Data Distribution Service – este un protocol de nivel APLICAȚIE pentru comunicații
M2M în timp real. Pe baza unui model de publicare - abonare, cum ar fi MQTT,
arhitectura protocolului are noduri configurate ca editor, abonat sau ambele; protocolul
DDS nu necesită niciun dispozitiv intermediar de rețea, editorii putând elibera date
referitoare la subiecte specifice (de exemplu temperatura dintr-o locație, temperatură
furnizată de un senzor de temperatură) și protocolul în sine fiind responsabil de livrarea
către abonat; implementarea protocolului nu necesită configurări de rețea, deoarece
protocolul nu necesită verificarea existenței sau locației nodurilor și, de asemenea, nu
necesită confirmarea livrării mesajului.

17
 SISTEME ȘI REȚELE DE COMUNICAȚIE

2.2 CALITATEA SERVICIULUI

Nivelul calității serviciului sau, pe scurt, calitatea serviciului (referită în continuare ca QoS -
Quality of Service) este un acord între expeditorul unui mesaj și receptorul mesajului, acord care
definește garanția de livrare în condiții bune a mesajului. Există 3 niveluri QoS în MQTT:
- cel mult o dată (0);
- cel puțin o dată (1);
- exact o dată (2).
Când se vorbește despre QoS în MQTT, trebuie luate în considerare cele două direcții ale
difuzării mesajului:
- livrarea mesajului de la clientul editor către broker;
- livrarea mesajului de la broker către clientul abonat.
Cele două direcții de livrare de date au elemente diferite, motiv pentru care trebuie tratate
separat. Clientul care publică mesajul (editorul) definește nivelul QoS al mesajului atunci când acesta
trimite mesajulul către broker. Brokerul transmite acest mesaj clienților abonați utilizând nivelul
QoS pe care fiecare client abonat îl definește în timpul procesului de abonare. Dacă clientul abonat
definește un QoS mai mic decât clientul editor, brokerul transmite mesajul către acesta cu o calitate
a serviciului mai mică.
QoS este o caracteristică cheie a protocolului MQTT. QoS oferă clientului puterea de a alege
un nivel de serviciu care să se potrivească cu fiabilitatea rețelei și logica aplicației. Deoarece MQTT
gestionează retransmiterea mesajelor și garantează livrarea (chiar și atunci când transportul nu este
fiabil), QoS facilitează mult comunicarea în rețelele nesigure.
Nivelul minim QoS este 0 (QoS 0 - cel mult o dată). Acest nivel de serviciu garantează o livrare
pentru care efortul de transfer este minim. Nu există nicio garanție de livrare. Destinatarul nu
confirmă primirea mesajului, iar mesajul nu este stocat și retransmis de către expeditor (fig. 9).

Fig. 9 Nivelul QoS 0

QoS nivelul 1 garantează că un mesaj este livrat cel puțin o dată receptorului. Expeditorul
stochează mesajul până când primește un pachet PUBACK de la receptor, pachet care confirmă
primirea mesajului. Este posibil ca un mesaj să fie trimis sau livrat de mai multe ori.
Expeditorul verifică dacă pentru fiecare pachet PUBLISH trimis cu QoS 1 primește pachetul
PUBACK corespunzător. Dacă nu primește un pachet PUBACK într-un timp rezonabil, expeditorul
retrimite pachetul PUBLISH corespunzător. Când un receptor primește un mesaj cu QoS 1, îl poate
procesa imediat; imediat ce broker-ul a recepționat mesajul, acesta îl trimite către toți clienții
abonați și apoi răspunde cu un pachet PUBACK.

18
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Fig. 10 Nivelul QoS 1

Dacă clientul editor trimite din nou mesajul, acesta validează un fanion “duplicat” (DUP). În
QoS 1, acest fanion DUP este utilizat numai în scopuri interne și nu este procesat de broker sau de
client. Receptorul mesajului trimite un PUBACK, indiferent de fanionul DUP.
QoS 2 este cel mai înalt nivel QoS din MQTT. Acest nivel garantează că fiecare mesaj este
primit o singură dată de către destinatarii. QoS 2 este cel mai sigur dar și cel mai lent nivel QoS.
Garanția este asigurată de cel puțin două fluxuri de date de solicitare, respectiv răspuns între
expeditor și receptor (fig. 11). Expeditorul și destinatarul utilizează identificatorul de pachet al
mesajului PUBLISH original pentru a coordona livrarea mesajului.

Fig. 11 Nivelul QoS 2

Când un receptor primește un pachet QoS 2 PUBLISH de la un expeditor, acesta procesează
mesajul de publicare în consecință și răspunde expeditorului cu un pachet PUBREC, acesta din urmă
recunoscând pachetul PUBLISH corespunzător. Dacă expeditorul nu primește un pachet PUBREC de
la receptor, acesta trimite din nou pachetul PUBLISH cu fanionul duplicat (DUP), procesul repetându-
se până când expeditorul primește o confirmare. Odată ce expeditorul primește un pachet PUBREC
de la receptor, expeditorul poate renunța la pachetul PUBLISH inițial. Expeditorul stochează
pachetul PUBREC de la receptor și răspunde cu un pachet PUBREL. După ce receptorul primește
pachetul PUBREL, acesta poate elimina toate stările stocate și poate răspunde cu un pachet
PUBCOMP. Până când receptorul finalizează procesarea și trimite pachetul PUBCOMP înapoi către
expeditor, receptorul stochează o referință la identificatorul de pachet al pachetului original
PUBLISH. Acest pas este important pentru a evita procesarea mesajului a doua oară. După ce
expeditorul primește pachetul PUBCOMP, identificatorul pachetului mesajului publicat devine
disponibil pentru reutilizare.
Când fluxul de date QoS 2 este finalizat, mesajul este cu siguranță livrat, iar expeditorul are
confirmarea livrării.
Dacă un pachet se pierde pe parcurs, expeditorul este responsabil să retransmită mesajul
într-un timp rezonabil. Acest lucru este valabil indiferent dacă expeditorul este un client MQTT sau
un broker MQTT. Destinatarul are responsabilitatea de a răspunde la fiecare mesaj.

19
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Unele aspecte ale QoS precum declasarea QoS sau unicitatea identificatorilor de pachete
pentru fiecare client sunt foarte importante atunci când se utilizează QoS.
După cum s-a menționat deja, nivelurile QoS dintre clientul care trimite (publică) mesajul și
clientul care primește mesajul pot fi diferite. Clientul care trimite mesajul PUBLISH către broker
definește nivelul QoS al mesajului. Cu toate acestea, atunci când broker-ul livrează mesajul către
destinatari (abonați), brokerul folosește QoS pe care receptorul (abonatul) l-a definit în timpul
abonării. Se consideră, pentru exemplificare, că expeditorul mesajului este clientul A, iar clientul B
este receptorul mesajului. Dacă clientul B se abonează la broker cu QoS 1 și clientul A trimite mesajul
către broker cu QoS 2, brokerul livrează mesajul către clientul B (receptor / abonat) cu QoS 1.
Mesajul poate fi livrat de mai multe ori către client B, deoarece QoS 1 garantează livrarea mesajului
cel puțin o dată și nu împiedică livrările multiple ale aceluiași mesaj.
Identificatorul de pachete pe care MQTT îl folosește pentru QoS 1 și QoS 2 este unic între un
anumit client și un broker în cadrul unei interacțiuni. Acest identificator nu este unic între toți clienții.
Odată ce fluxul este complet, identificatorul pachetului este disponibil pentru reutilizare. Această
reutilizare este motivul pentru care identificatorul de pachete nu trebuie să depășească valoarea
65535. Este nerealist faptul că un client poate trimite mai mult decât acest număr de mesaje fără a
finaliza o interacțiune.
Nu există reguli clare pentru alegerea nivelului QoS, acesta depinde în mare măsură de
fiecare aplicație în parte. Pentru alegerea corectă a nivelului QoS se pot face, însă, o serie de
recomandări.
QoS 0 se poate folosi când:
- există o conexiune stabilă între expeditor și receptor; un caz de utilizare clasic pentru
QoS 0 este conectarea unui client de testare sau a unei aplicații front-end la un broker
MQTT printr-o conexiune prin cablu;
- nu este nicio problemă dacă se pierd ocazional câteva mesaje; pierderea unor mesaje
poate fi acceptabilă dacă datele nu sunt atât de importante sau când datele sunt trimise
la intervale scurte de timp;
- nu este nevoie de așteptarea mesajelor; mesajele sunt așteptate numai pentru clienții
deconectați dacă utilizează QoS 1 sau 2 și o sesiune persistentă.
QoS 1 se poate folosi când:
- trebuie să fie recepționate toate mesajele, iar aplicația poate gestiona duplicatele; QoS
nivel 1 este cel mai frecvent utilizat deoarece garantează că mesajul ajunge cel puțin o
dată, permițând, însă, livrări multiple;
- nu se poate suporta efortul de transfer specific QoS 2 (QoS 1 livrează mesaje mult mai
rapid decât QoS 2).
QoS 2 se poate folosi când:
- este esențial pentru aplicație să se primească fiecare mesaj exact o dată, livrările duplicat
potând dăuna utilizatorilor aplicației sau clienților abonați; trebuie‚ ținut cont de faptul
că interacțiunea QoS 2 necesită mai mult timp pentru finalizare.

20
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Toate mesajele trimise cu QoS 1 și 2 “așteaptă” după clienții offline până când aceștia devin
disponibili din nou. Cu toate acestea, această așteptare este posibilă numai dacă clientul respectiv
are o sesiune persistentă.
2.3 FORMATUL PACHETELOR DE CONTROL MQTT V3.1.1
Protocolul MQTT funcționează prin schimbarea de pachete de control MQTT într-o manieră
bine definită. Un pachet de control MQTT constă din cel mult trei părți (fig. 13).

Antet fix, prezent în toate pachetele de control MQTT

Antet variabil, prezent în unele pachete de control MQTT
Date utile, prezente în unele pachete de control MQTT
Fig. 12 Structura pachetului de control MQTT v3.1.1
Fiecare pachet de control MQTT conține un antet fix – fig. 13 ce conține două câmpuri
specifice, fiecare pe câte 4 biți.

Bit 7 6 5 4 3 2 1 0
octet 1 tipul pachetului de control MQTT semnalizări specifice fiecărui tip de
pachet de control MQTT (fanioane / flag-
uri)
octet 2 ... rest pachet
Fig. 13 Formatul antetului fix al pachetului de control MQTT v3.1.1
Tipul pachetului de control MQTT este specificat în tetrada superioară a primului octet (fig.
14).

Denumire Valoare Direcție date Descriere

Rezervat 0 interzis Rezervat
client → server Clientul solicită conexiune
CONNECT 1
server-ului
CONNACK 2 server → client Confirmare conexiune
PUBLISH 3 client → server sau server → client Publicare mesaj
PUBACK 4 client → server sau server → client Publicare confirmată
PUBREC 5 client → server sau server → client Publicare recepționată
PUBREL 6 client → server sau server → client Publicare eliberată
PUBCOMP 7 client → server sau server → client Publicare completă
SUBSCRIBE 8 client → server Cerere de abonare client
SUBACK 9 server → client Confirmare abonare
UNSUBSCRIBE 10 client → server Solicitare dezabonare
UNSUBACK 11 server → client Dezabonare confirmată
PINGREQ 12 client → server Solicitare testare conexiune
PINGRESP 13 server → client Răspuns la comandă PING
DISCONNECT 14 client → server Deconectare client
Rezervat 15 interzis Rezervat
Fig. 14 Tipul pachetului de control MQTT v3.1.1

21
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Restul de biți (3 - 0) ai octetului 1 din antetul fix conțin fanioane specifice fiecărui tip de
pachet de control MQTT - fig. 15. În cazul în care acesti biti de semnalizare sunt marcati
ca ”Rezervat”, acestia sunt rezervati pentru utilizari viitoare și trebuie să fie setati la valorile indicate.
Dacă se primesc semnalizări nevalide, receptorul trebuie să închidă conexiunea de rețea.

Pachet de Fanioane antet fix Bit 3 Bit 2 Bit 1 Bit 0

control
CONNECT Rezervat 0 0 0 0
CONNACK Rezervat 0 0 0 0
PUBLISH Utilizat in MQTT 3.1.1 DUP1 QoS2 QoS2 RETAIN3
PUBACK Rezervat 0 0 0 0
PUBREC Rezervat 0 0 0 0
PUBREL Rezervat 0 0 1 0
PUBCOMP Rezervat 0 0 0 0
SUBSCRIBE Rezervat 0 0 1 0
SUBACK Rezervat 0 0 0 0
UNSUBSCRIBE Rezervat 0 0 1 0
UNSUBACK Rezervat 0 0 0 0
PINGREQ Rezervat 0 0 0 0
PINGRESP Rezervat 0 0 0 0
DISCONNECT Rezervat 0 0 0 0
DUP1 = livrare duplicat a pachetului de control PUBLISH
QoS2 = calitatea serviciului pentru pachetul PUBLISH (Quality of Service)
RETAIN3 = fanion retinere pachet PUBLISH
Fig. 15 Fanioanele utilizate in MQTT v3.1.1
Incepand cu octetul al doilea al pachetului incepe campul ”rest pachet” sau ”lungimea
ramasa”. Acest camp reprezinta numărul de octeți rămași în pachetul curent, inclusiv datele din
antetul variabil și sarcina utilă, neincluzand, insa, octeții utilizați pentru a codifica lungimea rămasă
(”rest pachet”).
Lungimea rămasă (”rest pachet”) este codificată utilizând o schemă de codificare cu lungime
variabilă care utilizează un singur octet pentru valori de până la 127. In cazul unor valori mai mari,
cei mai puțin semnificativi șapte biți din fiecare octet codifică datele, iar bitul cel mai semnificativ
bit este folosit ca și un ”bit de continuare” – fig. 16 - fig. 18. Numărul maxim de octeți în
câmpul ”lungime rămasă” este de patru.

Octeti “lungime ramasa” de la ... “lungime ramasa” la ...

1 0 (0x00) 127 (0x7F)
2 128 (0x80, 0x01) 16 383 (0xFF, 0x7F)
3 16.384 (0x80, 0x80, 0x01) 2.097.151 (0xFF, 0xFF, 0x7F)
4 2.097.152 (0x80, 0x80, 0x80, 0x01) 268.435.455 (0xFF, 0xFF, 0xFF, 0x7F)
Fig. 16 Codificarea lungimii ramase a pachetului in MQTT v3.1.1

22
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Cu aceasta codificare se pot trimite pachete cu lungimea de pana la 268.435.455 octeti (256
MB).

Fig. 17 Codificarea lungimii ramase a pachetului in MQTT v3.1.1

Exemplu – Daca se doreste codificarea numarului 400, se vor obtine 2 octeti, deoarece catul
impartirii acestuia la 128 este mai mic decat 128.
400 = 128*3 + 16 = 128 * 0x03 + 0x10
Deci:
- octetul 2 va fi 0x10 OR (SAU logic) 0x80 (=128) = 0x90;
- octetul 3 va fi 0x03.
23
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Fig. 18 Decodificarea lungimii ramase a pachetului in MQTT v3.1.1

Unele tipuri de pachete de control MQTT conțin si un antet variabil. Conținutul antetului
variabil variază în funcție de tipul pachetului.

24
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Antetul variabil al multor tipuri de pachete de control include un câmp de identificare a

pachetului de 2 octeți. Câmpul Identificator pachete al antetului variabil este comun în mai multe
tipuri de pachete. Aceste pachete de control sunt PUBLISH (pentru QoS > 0), PUBACK, PUBREC,
PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK – fig. 19, fig. 20.

Bit 7 6 5 4 3 2 1 0
Octet 1 MSB Identificator pachet
Octet 2 LSB Identificator pachet
Fig. 19 Octeti Identificator pachet

Pachet control MQTT Camp Identificator pachet

CONNECT NU
CONNACK NU
PUBLISH DA (daca QoS > 0)
PUBACK DA
PUBREC DA
PUBREL DA
PUBCOMP DA
SUBSCRIBE DA
SUBACK DA
UNSUBSCRIBE DA
UNSUBACK DA
PINGREQ NU
PINGRESP NU
DISCONNECT NU
Fig. 20 Pachetele de control care conțin identificator de pachete
Pachetele de control SUBSCRIBE, UNSUBSCRIBE și PUBLISH (în cazurile în care QoS > 0)
trebuie să conțină un identificator de pachete pe 16 biți, diferit de zero. De fiecare dată când un
client trimite un pachet nou de acest tip, trebuie să îi atribuie un identificator de pachet neutilizat
în prezent. Dacă un client trimite din nou un anumit pachet de control, atunci trebuie să utilizeze
același identificator de pachet ca in cazul trimiterilor anterioare ale acelui pachet. Identificatorul
pachetului devine disponibil pentru reutilizare după ce clientul a procesat pachetul de confirmare
corespunzător (in cazul unui pachet PUBLISH cu QoS 1 pachetul de confirmare este PUBACK
corespunzător; în cazul QoS 2 este PUBCOMP; pentru SUBSCRIBE sau UNSUBSCRIBE este SUBACK
sau UNSUBACK corespunzător).
Un pachet PUBLISH nu trebuie să conțină un identificator de pachet dacă valoarea sa QoS
este setată la 0.
Un pachet PUBACK, PUBREC sau PUBREL trebuie să conțină același identificator de pachet
ca pachetul PUBLISH care a fost trimis inițial. În mod similar, SUBACK și UNSUBACK treebuie să
conțină identificatorul de pachete care a fost utilizat în pachetul SUBSCRIBE, respectiv UNSUBSCRIBE.
Unele pachete de control MQTT conțin si date utile ca parte finală a pachetului (fig. 12, 21).
În cazul pachetului PUBLISH, de exemplu, acesta este mesajul propriu-zis.

25
 SISTEME ȘI REȚELE DE COMUNICAȚIE

Pachet control Date utile

CONNECT Necesar
CONNACK NU
PUBLISH Optional
PUBACK NU
PUBREC NU
PUBREL NU
PUBCOMP NU
SUBSCRIBE Necesar
SUBACK Necesar
UNSUBSCRIBE Necesar
UNSUBACK NU
PINGREQ NU
PINGRESP NU
DISCONNECT NU
Fig. 21 Pachetele de control care conțin si date utile
2.4 STRUCTURA PACHETELOR DE CONTROL MQTT V3.1.1
2.4.1 STRUCTURA PACHETULUI DE CONTROL CONNECT
După ce o conexiune de rețea este stabilită de un client către un server, primul pachet trimis
de la client către server trebuie să fie pachetul CONNECT.
Un client poate trimite pachetul CONNECT o singură dată printr-o conexiune de rețea.
Datele utile conțin unul sau mai multe câmpuri codificate. Acestea specifică un identificator
unic de client, subiect, mesaj, nume de utilizator și parolă. Toate, cu excepția identificatorului
clientului, sunt opționale, iar prezența lor este determinată pe baza semnalizărilor din antetul
variabil.
2.4.1.1 Antetul fix pentru pachetul CONNECT
Antetul fix contine 2 octeti ce codifica (fig. 22):
- octetul 1 – tipul pachetului de control MQTT;
- octetul 2 – lungimea ramasa (restul pachetului).

Bit 7 6 5 4 3 2 1 0
octet 1 Tip pachet control MQTT Rezervat
0 0 0 1 0 0 0 0
octet 2 rest pachet
Fig. 22 Antetul fix al pachetului CONNECT
2.4.1.2 Antetul variabil pentru pachetul CONNECT
Antetul variabil pentru pachetul CONNECT este format din patru câmpuri: nume protocol,
nivel protocol, fanioane CONNECT și mentinere conexiune.
Numele protocolului este un șir de caractere codificate UTF-8 care reprezintă numele
protocolului, cu majuscule (”MQTT”) – fig. 23. Acest sir de caractere nu va fi modificat de versiunile
26
 SISTEME ȘI REȚELE DE COMUNICAȚIE

viitoare ale specificației MQTT. Dacă numele protocolului este incorect, serverul poate deconecta
clientul sau poate continua să proceseze pachetul CONNECT în conformitate cu alte specificații, nu
in conformitate cu MQTT v3.1.1.

Descriere 7 6 5 4 3 2 1 0
Nume protocol
Octet 1 MSB lungime (0) 0 0 0 0 0 0 0 0
Octet 2 LSB lungime (4) 0 0 0 0 0 1 0 0
Octet 3 ’M’ 0 1 0 0 1 1 0 1
Octet 4 ’Q’ 0 1 0 1 0 0 0 1
Octet 5 ’T’ 0 1 0 1 0 1 0 0
Octet 6 ’T’ 0 1 0 1 0 1 0 0
Fig. 23 Codificarea numelui protocolului in antetul variabil al pachetului CONNECT

Nivelul protocolului este un camp care indica versiunea MQTT printr-un numar pe 8 biți, fara
semn – fig. 24. Valoarea acestui camp pentru versiunea 3.1.1 a protocolului MQTT este 4 (0x04).
Dacă nivelul de protocol nu este acceptat de server, acesta trebuie să răspundă la pachetul
CONNECT cu un cod de returnare ce indica nivelul inacceptabil de protocol și apoi trebuie sa
deconecteze clientul.

Descriere 7 6 5 4 3 2 1 0
Nivel protocol
Octet 7 Versiune protocol (4) 0 0 0 0 0 1 0 0
Fig. 24 Codificarea nivelului protocolului in antetul variabil al pachetului CONNECT

Fanioanele CONNECT sunt reprezentate pe un octet. Octetul CONNECT FLAGS (fanioane

CONNECT) conține un număr de parametri care specifică comportamentul conexiunii MQTT – fig.
24. De asemenea, indică prezența sau absența datelor utile. Serverul trebuie să valideze faptul că
fanionul rezervat din acest octet (bitul cel mai putin semnificativ) este setat la zero, in caz contrar
deconectand clientul.

Bit 7 6 5 4 3 2 1 0
Fanion Fanion Fanion QoS Fanion Fanion Rezervat
nume parola retinere stare stare
utilizator solicitare sesiune
Octet 8 X X X X X X X 0
Fig. 25 Bitii de semnalizare ai pachetului CONNECT

Fanionul stare sesiune specifică, asa cum indica si denumirea, starea sesiunii curente.
Clientul și serverul pot stoca starea sesiunii pentru a permite mesajelor de încredere să
continue pe o secvență de conexiuni de rețea.

27