4.

Conectivitate

4.1. Introducere

Sistemele embedded (încastrate) conțin diferite dispozitive ce trebuie să comunice între ele și,
ce-i mai important, să se și înțeleagă între ele. Pentru toate acestea trebuie să existe o legătură
fizică sau radio între dispozitive (care să asigure transferul paralel sau serial al datelor) și totodată
să existe un set de convenții denumite global protocoale de comunicație. Protocolul are menirea
să asigure corecta vehiculare a informației.

4.2. Protocoale seriale de interfațare

Ansamblul format din legăturile fizice și protocolul de comunicație se numește interfață.

Standardul de interfață cuprinde prescripții impuse tuturor dispozitivelor din sistem. Există
patru tipuri de prescripții:
1. Prescripțiile mecanice se referă la tipurile de conectoare utilizate, modul de fixare a
acestora precum și a aparatelor din sistem, tipurile de cabluri folosite, lungimea maximă a
acestora, precum și alte detalii constructive și prescripții necesare pentru conectarea în
sistem.
2. Prescripțiile electrice precizează parametrii electrici ai căii de comunicație, respectiv
nivelurile logice utilizate, condiții de adaptare a ieșirilor și a intrărilor.
3. Prescripțiile funcționale descriu rolul și modul de utilizare a fiecărei linii din magistrala
standard. De asemenea se referă la mesajele și datele ce pot fi transferate prin interfață și
modul în care se realizează acest transfer.
4. Prescripțiile operaționale se referă la modul în care fiecare aparat din sistem poate să
utilizeze interfața standard pentru a comunica cu celelalte elemente din sistem.
După modul de legare între ele a dispozitivelor avem conexiune punct la punct, când
comunicarea se realizează între două dispozitive și conexiune multipunctuală, când mai multe
dispozitive intercomunică între ele.
În cazul unei conexiuni unul sau mai multe aparate transmit date, și acestea se numesc
transmițătoare și unul sau mai multe sisteme recepționează datele și ele se numesc receptoare.
Pe de altă parte, dispozitivul sau dispozitivele care guvernează comunicarea se numesc
coordonatori (master), iar dispozitivele ce se supun semnalelor de control se numesc subordonate
(slave). Există posibilitatea ca un aparat ce a fost coordonator să devină subordonat și invers,
după cum dictează algoritmul de comunicare. Modul cum se obține și se cedează controlul
comunicării este definit în protocolul de comunicație. Un coordonator poate fi la un moment
dat transmițător sau receptor. La fel și dispozitivul subordonat.
Pentru a reduce numărul de trasee/fire prin care se comunica între diferitele componente
ale unui sistem (de exemplu, microcontroler – periferic), se utilizează comunicația seriala. Practic,
în acest mod se reduce complexitatea sistemului, prețul plătit fiind o viteză ceva mai scăzuta de

1|Pagină
transfer a datelor. Analizând Figura 3.5 observăm existența a trei tipuri diferite de porturi seriale
UART, I2C și SPI.
Forma cea mai simplă de comunicare serială este cunoscută sub denumirea “simplex”. Într-o
comunicație seriala simplex se transmit informații într-o singură direcție (precum stațiile radio). O
conexiune “half-duplex” avem atunci când datele pot fi transmise sau recepționate dar nu simultan.
O legătură de tip “full duplex” permite transmiterea și recepționarea simultană a datelor.

Sincron versus asincron

Există de asemenea protocoale de comunicare serială asincrone și sincrone.

In modul asincron, emițătorul nu trimite un semnal de tact cu datele, ci înserează un pseudo-
impuls de tact, cunoscut ca bit de start, în fața fiecărui cuvânt de date transmis. Viteza de lucru se
stabilește manual la începutul transmisiei. Pentru o corectă informație de fază, receptorul trebuie
sa detecteze începutul bitului de start. Pentru ca aceasta metoda sa funcționeze, trebuie sa existe,
o perioadă de liniște între caractere, realizata cu bitul/biții de stop. Biții de start și de stop
încadrează deci fiecare caracter transmis; caracterul transmis între acești doi biți reprezintă un
cadru de date. Sincronizarea la nivel de bit se realizează cu ajutorul semnalelor de ceas
locale cu aceeași frecvență. Atunci când receptorul detectează începutul unui caracter indicat prin
bitul de start, pornește un oscilator de ceas local, care permite eșantionarea corectă a biților
individuali ai caracterului. Eșantionarea biților se realizează aproximativ la mijlocul intervalului
corespunzător fiecărui bit.
În cazul comunicației sincrone, un cadru nu conține un singur caracter, ci un bloc de caractere
sau un mesaj. Deci, caracterele sunt transmise rapid, unul după altul, fără biți de start și de stop.
Protocolul sincron are nevoie de o conexiune auxiliara: semnalul de ceas.
Din cele prezentate observăm pentru modul asincron de transfer necesitate existenței unei linii
de date (pe care datele se transmit sau recepționează) sau a două linii de date (una din linii pentru
transmisie, cea de a doua pentru recepție) și a unei alte conexiuni de referință. Transferul sincron
aduce o linie în plus – semnalul de tact.
Mai există interfețe seriale ce utilizează și linii de control a fluxului de date. Cea mai
cunoscută interfață standard serială este RS 232.
La ora actuală există 5 standarde mai importante pe piața sistemelor embedded care au la bază
comunicație serială: (1) RS232, (2) I2C sau IIC (introdusă de compania Philips), configurația cea
mai generală posibilă permite existența a mai mulți master mai mulți slave, existând un mecanism
de arbitrare între masteri, (3) SPI (dezvoltat de Motorola) nu permite direct prezenta pe magistrala
a doi sau mai mulți masteri (4) 1Wire (dezvoltat de Maxim), este posibilă configurația mulți slave,
dar în cazul existenței a mai mulți master se poate realiza numai cu o schema de arbitrare externa
și (5) USB.

2|Pagină
 Transmisie diferențială/nediferențială

Actualmente s-au impus două metodele standard pentru realizarea legăturii seriale între două
echipamente sau dispozitive. Acestea sunt următoarele:
1. Cele de tip single-ended sau cu referință la masă, sunt tehnici de transmisie a datelor
ce folosesc reprezentarea prin nivele a biților (precum RS-232) și
2. Tehnicile de transmisie diferențiale, de exemplu interfețele RS-422, RS-485 sau
standardul USB.
În cazul conexiunii single-ended legătura dintre emițător și receptor se realizează prin două
fire, firul de semnal (prin care emițătorul trimite date) și firul de masă. Dacă se dorește, ca la un
anumit moment dat, rolurile emițătorului și al receptorului să se schimbe mai trebuie să existe în
plus și o altă conexiune de date pentru transferul invers al informațiilor.

Figura 4.1. Conexiunea între două dispozitive prin intermediul protocolului RS-232

Valoarea bitului de 1 sau 0 este dată de nivelul de tensiune față potențialul de masă. Dar,
datorită perturbațiilor existente, se acceptă de obicei o plajă a valorilor pe care bitul de 1 sau 0 le
pot lua – vom studia acest lucru mai în amănunt în cadrul protocolului RS-232. Pentru acest tip de
transmisie (single-ended) sistemul de transmisie al datelor este ilustrat în figura de mai jos.

Figura 4.2. Conexiunea single-ended

Această conexiune are avantajul utilizării unui singur fir pentru fiecare canal serial. Dar
performanțele obținute sunt scăzute datorită influenței zgomotului din canal Vn și a tensiunii de
bias (offset) dintre mesele celor două sisteme.
Conexiunea diferențială (differential) se realizează pe două fire pentru fiecare canal.
Modalitatea de conexiune și nivelele de tensiune de ce cele două linii sunt prezentate în Figura
4.3. Emițătorul are două ieșiri simetrice și trimite valorile de tensiune +Vt și -Vt pentru un nivel
logic și valorile în oglindă (-Vt și +Vt) pentru cel de al doilea nivel logic. Receptorul sesizează doar
diferența de potențial între cele două fire (de ex. 2Vt).

3|Pagină
 Figura 4.3. Conexiunea diferențială

Un sistem de recepție a datelor cu intrări diferențiale ar trebui teoretic să răspundă numai la

diferența de potențial dintre intrările sale, notate (+) şi (-); orice tensiune de mod comun, care
apare în raport cu masa (GND), ar trebui să fie eliminată complet, dacă circuitele folosite ar fi ideale.
În realitate, imperfecțiunile circuitelor (mai ales asimetriile), vizibile în special la variații mari de
tensiune, determină pătrunderea perturbațiilor de mod comun, ce pot provoca erori pe recepție.
Mai mult, dacă tensiunile de mod comun sunt mari, acestea pot distruge etajele de intrare ale
sistemelor de măsură.
Un alt avantaj al transmisiei diferențiale a datelor este dat de faptul că întotdeauna, pe cele
două linii, curenții circulă în direcții opuse – datorită acestei cauze câmpurile magnetice generate
se “anihilează” și astfel zgomotele de tip EMI (electromagnetic interference) sunt reduse.
În cazul conexiunii diferențiale legătura dintre emițător și receptor se realizează prin trei fire,
două fire de semnal (prin care emițătorul trimite date) și firul de masă.

Figura 4.4. Conexiunea între dispozitive prin intermediul protocolului RS-485

În principal, avantajele fundamentale ale transmisiei diferențiale de date sunt date de creșterea
vitezei de transfer și creșterea lungimii traseelor de comunicație.

4|Pagină
 Standardul serial RS-232

Specificațiile electrice ale portului serial utilizat la calculatoarele IBM PC au fost definite
în standardul RS-232C (Reference Standard No. 232, Revision C), elaborat în anul 1969 de
către Comitetul de Standarde din SUA, cunoscut azi sub numele de Asociația Industriei
Electronice (EIA – Electronic Industries Association). Standardul a fost elaborat pentru
comunicația digitală între un calculator și un terminal aflat la distanță sau între două terminale,
fără utilizarea unui calculator. La origini, terminalele erau conectate prin linii telefonice, astfel
încât erau necesare modemuri la ambele capete ale liniei de comunicație.
Standardul RS-232C a suferit diferite modificări, fiind elaborate mai multe revizii ale acestuia.
De exemplu, în anul 1987 a fost elaborată o nouă revizie a standardului, numită EIA RS-232D. În
anul 1991, EIA și Asociația Industriei de Telecomunicații (TIA – Telecommunications Industry
Association) au elaborat revizia E a standardului (EIA/TIA RS-232E). Revizia curentă este EIA
RS-232F, publicată în anul 1997. Totuși, indiferent de revizia acestuia, standardul este numit
de cele mai multe ori RS-232C sau simplu RS-232.

Tabelul 4.1. Tensiunile asociate cu fiecare nivel logic

Nivel Emițător (V) Receptor (V)
0 logic +5 ... +15 +3 ... +25
1 logic -5 ... -15 -3 ... -25
Nedefinit - -3 ... +3

La pinii portului serial RS 232 întâlnim doar două nivele logice. Un bit în 1 logic este identificat
de o anumită plajă negativă a tensiunii, în timp ce un bit în zero este dat de o anumită plajă pozitivă
de tensiune. Domeniul standard, acceptat, de variație al nivelelor logice pentru orice pin al portului
serial este dat în Tabelul 4.1.

Figura 4.5. Circuit de interfațare serial

5|Pagină
 Standardul mai impune ca fiecare linie a portului serial să poată susține un scurtcircuit cu
oricare altă linie fără a exista vreo distrugere permanentă a niciuneia dintre cele două linii.
Datorită acestor nivele logice impuse de protocol și care sunt clar diferite față de cele ale
familiilor TTL sau CMOS, familii standard în construcția diferitelor dispozitive cu care dorim să
comunicăm, pentru a ne putea conecta la portul serial al microcontrolerului sau SoC-ului trebuie
să utilizăm un circuit convertor de nivel logic, de tipul ICL (sau MAX) 2321, cu ajutorul căruia se
realizează doar conversia nivelelor logice, deci interfațarea între cele două dispozitive.
Transmisia serială de tip RS-232 este o transmisie asincronă. După cum s-a prezentat și
anterior, pentru transmisia asincrona, un bit de start identifica începutul cuvântului (de exemplu
a octetului sau a celor 7 biți de date – vezi Figura 4.6) ce se va transmite şi unul sau doi biţi
identifica finalul acestuia, nefiind necesară nici un fel de alta sincronizare, vezi Figura 4.7.

LSB MSB

Zonă
nederminată
Bit de
paritate

7 biți de date 2 biți

Bit de de stop
Pachetul de date
start

Figura 4.6. Nivele de tensiune RS232 versus nivelele logice

Biţii de date (5 – 8 biți) sunt trimişi către receptor după bitul de start. Standardul impune ca
bitul cel mai puțin semnificativ să fie primul transmis (bit numit și LSB – least significant bit). Cu
toate acestea există diferite implementări ale portului serial care permit configurarea și
transmiterea drept prim bit a bitului cel mai semnificativ din cuvântul de date – MSB, most
significant bit. O astfel de implementare a portului serial se regăsește în microcontrolerele din
familia MSP430x2xxx produse de compania Texas Instruments.

1
Circuit capabil să fie alimentat cu o tensiune de +5V. Dacă utilizăm microcontrolere care lucrează la tensiuni de
alimentare mai mici, de exemplu 3.6V, trebuie să utilizăm un circuit de tip MAX 3232. Acest circuit este capabil
să lucreze într-o plajă a tensiunilor de alimentare de la 3.0V până la 5.5V.

6|Pagină
 În concordanță cu configurația transmisiei, un bit de paritate poate fi sau nu transmis după
fiecare trimitere de caracter. Acest bit este utilizat pentru a depista erorile din caracterele
recepționate. Paritatea poate fi de două tipuri: pară sau impară. Astfel, în cazul unei transmisii
seriale cu:
 paritate para, bitul de paritate se calculează de o așa natură încât numărul total de
biți în starea 1 din octetul util plus bitul de paritate sa fie par;
 paritate impara, bitul de paritate se calculează astfel încât numărul total de biți în
starea 1 din octetul util plus bitul de paritate sa fie impar.
La final, sunt transmiși 1, 1.5 sau 2 biți de stop – în conformitate cu modalitatea de configurare
a portului serial.
Tot din Figura 4.6 se observă că în repaus linia este în 1 logic.

Figura 4.7. Structura de date asociată cu trimiterea serială a unui octet

Viteza de comunicație (numită și debit binar) este măsurată în biți/s (bps):

1
𝐷 𝑏𝑖𝑡𝑖/𝑠 (4.1)
𝑇
unde T este perioada de timp necesară pentru transmisia sau recepția unui singur bit.

Figura 4.8. Transmiterea unei informații text la o viteză de 115.200 și recepționarea ei la o

viteză de 19.200 bps

7|Pagină
 Porturile seriale ale calculatoarelor permit, de obicei, selecția uneia din următoarele viteze de
comunicație: 150, 300, 600, 1.200, 2.400, 4.800, 9.600, 19.200, 38.400, 57.600, 115.200, 230.400,
460.800 sau 921.600 biți/s. În situația în care vitezele de transfer a datelor între emițător și receptor
nu sunt corect configurate un potențial mesaj text trimis de emițător va fi incorect decodat și va
ieși total neinteligibil, vezi Figura 4.8.
Receptorul realizează citirea datelor în mod secvențial, la jumătatea intervalelor de bit care
urmează bitului de start.
Standardul limitează slew rate-ul la ieșirea circuitului driver la maximum 30 V/us. Această
limitate ține în principal de limitarea zgomotului de interconectare ce ar putea să existe între firele
multiple ale unui cablu.
Lungimea maximă a cablului pentru transferul serial este una dintre problemele aflate în mod
constant în dispută. Standardul fixează această lungime la 50 feet2 sau la o lungime echivalentă
unui cablu cu o capacitate de 2500 pF pentru o viteză de transfer a datelor de 20 kbps. Cu toate că
această ultimă precizare este mereu uitată ea determină în principal lungimea maximă a cablului
de interconectare. Deci în cazul unui cablu de calitate superioară lungimea maximă de
interconectare poate crește (de exemplu pentru cablul UTP CATEG. 5 care are o capacitate
echivalentă de 17 pF/ft lungimea maximă admisibilă poate ajunge până la 147 feet).

Tabelul 4.2. Lungimea maximă a cablului funcție de rata de transfer

Lungimea cablului de transfer

Rata de transfer Lungimea maximă a cablului (feet)

19200 50 (15.24 m)
9600 500 (152.4 m)
4800 1000 (304.8 m)
2400 3000 (914.4 m)

Lungimea menționată anterior pentru cablu, de către standard, este pentru viteza precizată
anterior de transfer. În cazul reducerii vitezei cu un factor de 2 sau 4 lungimea maximă a cablului
crește spectaculos. Firma Texas Instruments a efectuat experiențe la diferite rate de transfer pentru
a stabili, pentru fiecare rată în parte, lungimea maximă admisă pentru cablul de comunicație
serială. Datele sunt prezentate în Tabelul 4.2. După cum se observă la o înjumătățire a ratei de
transfer lungimea cablului crește de 10 ori.
Componenta principală a unui port serial este un circuit UART (Universal Asynchro-nous
Receiver/Transmitter). Acest circuit realizează conversia datelor paralele de la sistem în formatul
necesar pentru transmisia serială și conversia datelor seriale recepționate în formatul paralel
utilizat de sistem. Acest circuit adaugă în mod transparent utilizatorului bitul de start, bitul/biții de
stop și bitul de paritate la datele seriale transmise și detectează acești biți în cadrul datelor seriale
recepționate.
Deși standardul impune ca pe o linie de date să existe maxim un emițător și maxim un receptor,
există multe microcontrolere care implementează un mod specific de gestionare a UART-ului ce

2
1 feet = 0.3048 m

8|Pagină
permite comunicația de tip multiprocesor – un astfel de exemplu sunt microcontrolerele din familia
80C51. În acest mod de lucru există un singur procesor master și 256 de procesoare de tip slave.
Astfel, în cadrul acestei abordări de transfer date, se transmit 9 biți de date – aici, ultimul bit, al
nouălea, înlocuiește bitul de paritate – după care urmează bitul/biții de stop. Atunci când procesorul
master dorește să transmită un bloc de date către unul din procesoarele de tip slave gestionate,
atunci el trimite un octet de adresă (pe 8 biți) care identifică procesorul slave. Octetul de adresă
este diferit de un octet de date prin aceea că bitul al nouălea este 1. În acest moment toate
microcontrolerele de tip slave își opresc activitățile curente și analizează octetul de adresă, dacă se
găsește o potrivire atunci microcontrolerul slave se pregătește pentru recepționarea datelor de la
master. În caz contrar își continuă activitatea normală. Când masterul trimite date ce au al nouălea
bit pus pe zero nici un alt microcontroler nu-și va întrerupe activitatea normală, neluând în
considerare aceste date.
De exemplu, inițial sistemele cu procesoare Intel aveau numai patru porturi paralele seriale
denumite COM1, COM2, COM3 și COM4, dar ulterior numărul acestora crește semnificativ
ajungând la 128 în cadrul sistemului de operare Windows 95. Fiecare port serial are un număr de
registre cu ajutorul cărora acesta poate fi controlat/interogat.

Pin Nume Direcţie Descrieire Pin Nume Direcţie Descrieire

1 CD intrare Carrier Detect 1 SHIELD Shield Ground
2 RXD intrare Receive Data 2 TXD ieşire Transmit Data
3 TXD ieşire Transmit Data 3 RXD intrare Receive Data
4 DTR ieşire Data Terminal Ready 4 RTS ieşire Request to Send
5 GND System Ground 5 CTS intrare Clear to Send
6 DSR intrare Data Set Ready 6 DSR intrare Data Set Ready
7 RTS ieşire Request to Send 7 GND System Ground
8 CTS intrare Clear to Send 8 CD intrare Carrier Detect
9 RI intrare Ring Indicator 20 DTR ieşire Data Terminal Ready
22 RI intrare Ring Indicator
9-19, 21, 23-25 Nu ne interesează

Figura 4.9. Asignarea pinilor pentru conectorii seriali (9 și 25 PIN D-SUB tata) – acești
conectori sunt cei situat pe calculatorul personal
În Figura 4.9 sunt date configurațiile pinilor pentru cele două tipuri de conectorii disponibili
de 9 (DB9S) și 25 (DB25S) de pini. Conectorul cu 25 de pini asigură funcționalitatea totală a
interfeței în timp ce al doilea conector (pe 9 pini) asigură un spațiu minimal pentru dispozitivele
tot mai miniaturizate a zilelor noastre.
Semnificația semnalelor cele mai utilizate este prezentată în continuare:
/DTR (Data-Terminal-Ready) – prin această linie PC-ul comunica modemului ca este
funcțional și este pregătit sa transmită date.
/DSR (Data-Set-Ready) – Modemul comunica PC-ului că este funcțional și este pregătit
să transmită sau să primească date.
/RTS (Request-To-Send) – PC-ul setează acest semnal când are pregătit un caracter
pentru a-l transmite.

9|Pagină
 /CD (Carrier-Detect) – Prin activarea acestui semnal, modemul semnalează
calculatorului faptul că a detectat semnalul purtător al altui modem pe linia
telefonică, deci, există o conexiune cu un modem aflat la distanță. Într-o legătură
serială fără modemuri, activarea semnalului CD indică faptul că este posibilă
comunicația cu un echipament de la celălalt capăt al liniei.
/CTS (Clear-To-Send) – Modemul este pregătit pentru a transmite datele. Computerul
va începe sa transmită date spre modem. Un semnal CTS inactiv va preveni
calculatorul de a transmite date către modem. Aceasta permite modemului
să controleze fluxul datelor transmise de calculator.
TxD Datele sunt transmise serial pe această linie.
RxD Această linie este utilizată de un dispozitiv pentru recepția datelor de la un alt
echipament.
Modalitatea “clasică” de lucru cu portul serial este aceea de a trimite și recepționa datele serial
prin intermediul liniilor RXD și TXD așa cum este prezentat în

Figura 4.10. Modalitatea minimală de conectare a două dispozitive prin intermediul portului
serial RS-232

O legătură de bază RS-232C necesită doar trei conexiuni: una pentru transmisie, una pentru
recepție și una pentru masa electrică comună. Dar pot exista legături seriale care să utilizeze și alte
semnale pentru controlul fluxului de date – așa cum a fost prezentat anterior.

Figura 4.11. Modalitatea de conectare a două dispozitive prin intermediul portului serial RS-
232 capabile să realizeze un control hardware a fluxului de date

10 | P a g i n ă
 Pentru controlul fluxului de date transmise/recepționate între două echipamente prin
intermediul protocolului RS-232 se poate utiliza un protocol hardware sau unul software. În
primul caz se utilizează semnale DTR/DSR sau RTS/CTS prin care unitatea receptoare poate să
oprească temporar fluxul de date transmis. In acest fel se poate sincroniza frecvența de emisie a
datelor la viteza de prelucrare a unității receptoare. A doua metodă nu utilizează semnale de control
hardware, în schimb folosește un set de coduri speciale prin care poate sa oprească (codul XOFF,
cod ASCII 19) sau să repornească (codul XON, cod ASCII 17) fluxul de date. La transmisia în
format binar, codurile de control ar putea sa fie prezente în datele de transmis și astfel această
metodă de transmisie ar fi compromisă.
În general dacă cantitatea de date ce se transferă este mică nu se utilizează nici un mecanism
de control a fluxurilor de date, nici un protocol de tip handshaking.

Figura 4.12. Mecanismul hardware de control a fluxului de date (handshaking)

În situația în care se realizează transferuri ale unor masive mari de date și sincronizarea
emițătorului și a receptorului este posibil să se piardă se folosește un mecanism hardware de
control a fluxului de date. Acest mecanism este prezentat în Figura 4.12. Astfel:
1. Sistemul master (sistemul embedded, PC-ul, etc.) pune pe unu linia DTR semnalizând că
dorește să realizeze un transfer de date.
2. Receptorul semnalizează că este pregătit – în cazul unui modem prin trecerea acestei linii
în 1 (DSR) se semnalizează că o conexiune tocmai a fost realizată.
3. Sistemul master cere permisiunea de a începe transferul de date.
4. Receptorul, sistemul slave (de ex. modemul), informează masterul că este pregătit să
primească datele și în acest moment schimbul de date începe.
5. Când sistemul slave pune pe zero linia CTS, el semnalizează că buffer-ele interne sunt
pline și nu mai poate recepționa alte date. În acest moment master-ul oprește transferul
datelor.
6. În acest moment buffer-ele au fost golite (datele au fost preluate de programul ce rulează
pe slave) iar master-ul poate reîncepe trimiterea datelor.
7. Master-ul nu are disponibile date pentru slave. Slave-ul se va opri din recepționarea datelor
când valoarea liniei RTS este pusă în zero de master.
8. Slave-ul acceptă situația și o confirmă prin punerea în zero a liniei CTS.
9. RTS-ul este pus din nou pe unu logic pentru a reîncepe transmisia datelor.
10. Slave-ul răspunde și acceptă cererea de transfer date.
11. Nu mai sunt date de transmis.
12. Slave-ul confirmă și acceptă noua situație.

11 | P a g i n ă
13. DTR-este pus pe zero.
14. În acest moment modemul închide conexiunea de date și confirmă prin DSR pe zero.

12 | P a g i n ă
 Interfața I2C (Inter-Integrated Circuit Bus)

A fost inventată și propusă de compania Philips în anii 80, acum aceasta s-a transformat în
compania NXP (Next eXPerience). O magistrala seriala de tip I2C (IIC sau I2C) permite
interconectarea componentelor unui microsistem microcontroler, SoC etc. (element de tip master
– cel puțin unul) cu unul sau mai multe elemente de tip slave: memorii de tip EPROM, convertoare
A/D și D/A, senzori, potențiometre digitale și multe alte tipuri de dispozitive periferice. Prin
utilizarea unei magistrale seriale de acest tip se urmărește reducerea costurilor de realizare a
cablajelor imprimate precum și scăderea timpului de realizare a unor prototipuri. Magistrala I2C a
fost gândită în special pentru cuplarea unor dispozitive pe distanțe scurte și foarte scurte.

Figura 4.13. Liniile magistralei I2C și modalitatea de conectare a

diferitelor dispozitive la ea

Magistrala I2C implementează o transmisie seriala sincrona – deci, se utilizează un semnal

separat de ceas alături de semnalul de date. Realizarea unui sistem pe o magistrală I2C presupune
interconectarea unor circuite integrate (specializate) prin numai trei linii: două linii de semnal și
una de masă. Cele două linii de semnal sunt denumite "serial data" (SDA) și "serial clock" (SCL),
vezi Figura 4.13. Fiecare circuit integrat ce se conectează la această magistrală trebuie în mod
obligatoriu să aibă o adresă unică și poate funcționa fie ca transmițător, fie ca receptor, în funcție
de tipul circuitului și de operația executată în acel moment. De exemplu, un afișaj de tip LCD
cu bus I2C poate fi numai receptor, în timp ce un circuit de memorie EEPROM poate fi atât
transmițător de date cât și receptor – evident aceste funcții nu pot fi realizate simultan.

Figura 4.14. Conectarea la liniile magistralei I2C prin intermediul circuitelor de interfațare

13 | P a g i n ă
 Pentru conectarea la magistrala I2C fiecare circuit integrat este prevăzut cu câte un etaj de
interfață pentru fiecare linie a magistralei, Figura 4.14. Ambele linii, SDA și SCL sunt linii
bidirecționale, conectate la plusul sursei de alimentare prin câte un rezistor (denumit rezistor de
“pull-up”). Dacă magistrala este liberă, ambele linii sunt la nivel ridicat. Etajele de ieșire ale
fiecărui circuit care se conectează la magistrala I2C trebuie să aibă o ieșire de tip colector în gol
sau drenă în gol (ieșire ce poate genera nivelul de 0 logic dar nu poate genera nivelul de 1 logic –
de aici necesitatea existenței rezistoarelor de “pull-up”), pentru a putea permite realizarea funcției
ŞI-cablat.
Pe magistrala se pot conecta mai multe module master sau circuite coordonatoare – acestea
sunt circuitele care au inițiativa în transferul de date și ele sunt circuitele care generează semnalul
de tact necesar în realizarea unui transfer. Toate celelalte circuite care pot fi adresate, interogate
de un master sunt module slave sau circuite subordonat. Un modul master poate să inițieze un
transfer doar în situația în care magistrala este libera.
Magistrala I2C implementează un control de tip multi-coordonator, adică se pot interconecta
mai multe circuite care pot avea rolul de coordonator (master). În cazul în care două unități
master inițiază simultan un transfer de mesaj, atunci va avea loc o procedură de arbitraj prin care
se va declara un singur câștigător atunci când există mai multe dispozitive care solicită funcția de
master. Această procedură va fi descrisă în detaliu în cele ce urmează.
Viteza maximă de comunicație originală (atunci când standardul a fost propus) a fost de 100
kHz. În anul 1992 standardul a fost completat cu un nou mod de comunicație – fast-mode, ce
permite o rată de transfer de 400 kHz. La ora actuală există alte trei moduri de comunicație: (a)
fast-mode plus – ce permite viteze de transfer de 1 MHz, (b) modul high-speed – rata de transfer
este 3.4 MHz și (c) ultra-fast mode, cu rata de transfer cea mai mare – de 5 MHz.
Numărul maxim de circuite care se pot conecta la magistrală este limitat numai de capacitatea
maxim admisă pentru fiecare linie, care este de 400 pF.
Deoarece dispozitivele de pe magistrală nu sunt cele care furnizează nivelul de 1 logic, aceasta
ne permite să conectăm diferite tipuri de dispozitive pe magistrală care să fie alimentate la nivele
diferite de tensiune. În acest mod un dispozitiv care este alimentat la o tensiune mai mare (de ex.
5V) poate fi conectat la un circuit care este alimentat la o tensiune mai mică (de ex. 3.6V) fără a
necesita existența unui circuit de interfațare între ele. Pentru a realiza acest lucru trebuie să
conectăm rezistoarele de pull-up ale liniilor SCL și SDA la sursa de valoare mai mică – evident
având grijă ca nivelul de intrare de 1 logic al circuitului alimentat la o tensiune mai mare să se
realizeze.

Figura 4.15. Definirea condițiilor de START și STOP

14 | P a g i n ă
 Protocolul de transfer pe magistrala I2C

Protocolul de transfer al datelor pe magistrala I2C presupune inițierea transferului prin

aducerea magistralei într-o condiție de START, transferul propriu-zis și încheierea transferului
prin aducerea magistralei într-o condiție de STOP.
Condiția de START (S) este definită prin trecerea liniei SDA din 1 în 0, în timp ce linia SCL
este menținută la nivel ridicat, Figura 4.15. Condiția de STOP (P) este definită prin trecerea liniei
SDA din 0 în 1, în timp ce linia SCL este menținută la nivel ridicat, Figura 4.15.
Este obligatoriu ca datele trebuie să fie stabile pe durata în care impulsul de tact este în 1 logic,
modificarea datelor se poate face numai pe durata pauzelor dintre impulsurile de tact, vezi Figura
4.16.

Figura 4.16. Definirea intervalelor în care datele se pot schimba și

în care trebuie să fie stabile

Datele sunt transferate pe magistrala I2C sub formă de octeți. După transmiterea fiecărui octet
transmițătorul trebuie să afle dacă acesta a fost recepționat corect de către receptor. Aceasta se
realizează prin următoarea procedura (vezi Figura 4.17): (a) după transmiterea celui de-al 8-lea
bit, emițătorul lasă în starea liniei de date SDA în 1 logic, (b) dacă recepția s-a făcut corect (fiecare
bit a fost preluat, s-a verificat paritatea, cuvântul recepționat din registrul de deplasare pentru
recepție a fost preluat de registrul tampon pentru recepție), atunci receptorul trage jos linia SDA
pe durata celui de-al 9-lea tact al liniei SCL.

Figura 4.17. Procedura de acceptare a unui octet

15 | P a g i n ă
 Numărul de octeți care poate fi transmis în cadrul unui transfer nu este limitat. În cadrul unui
octet, primul bit transferat este bitul cel mai semnificativ. După primele opt impulsuri de tact
necesare transmiterii unui octet urmează un al nouălea impuls, utilizat pentru recunoașterea
efectuării transferului.

Figura 4.18. Transferul datelor pe magistrala I2C

Dacă, după recepția unui octet, receptorul nu poate recepționa un nou octet (pentru că, de
exemplu, tratează o întrerupere internă prioritară), el poate menține linia SCL la nivel coborât
pentru a forța transmițătorul într-o stare de așteptare. Transferul poate continua când receptorul
este gata, situație indicată prin eliberarea liniei SCL, Figura 4.18. În felul acesta se face adaptarea
vitezei de transmisie după viteza celui mai lent participant.
Întotdeauna, primul octet transmis după condiția de START reprezintă adresa unui slave,
împreună cu tipul operației solicitate (scriere sau citire). Primii șapte biți ai acestui octet reprezintă
adresa. Tipul operației este precizat de bitul 8, notat R/W. Astfel, dacă R/W = 1, coordonatorul va
citi date de la subordonatul adresat iar dacă R/W = 0, coordonatorul va transmite date
subordonatului adresat. Un astfel de transfer complet este ilustrat în Figura 4.19.

Figura 4.19. Transferul unui mesaj pe magistrala I2C.

Utilizarea tehnicii de confirmare a unui transfer corect este obligatorie pentru asigurarea unui
transfer de date fără erori. Impulsul de tact corespunzător fiecărui octet, denumit impuls de
confirmare (acknowledge), este generat de circuitul master. Emițătorul eliberează linia SDA pe
durata impulsului de recunoaștere. Receptorul trebuie să aducă linia SDA la nivel coborât și să o
mențină așa pe toată durata impulsului de tact de confirmare (acknowledge) – al nouălea impuls

16 | P a g i n ă
de tact, ceea ce garantează efectuarea corectă a transferului octetului respectiv. În general, un
receptor adresat trebuie să recunoască fiecare octet transmis. Există și excepții de la această regulă.
Dacă un receptor de tip slave nu recunoaște adresa care i-a fost trimisă pe magistrală (de
exemplu, deoarece nu poate recepționa date deoarece execută o funcționalitate în timp real sau
deoarece nu este adresa lui), subordonatul trebuie să lase linia SDA la nivel ridicat. În această
situație, circuitul master poate genera o condiție de STOP pentru a abandona transferul.
Dacă receptorul subordonat recunoaște adresa care i-a fost trimisă, dar, după transferul unui
număr oarecare de octeți, nu mai poate recepționa alții sau nu îi mai sunt necesare alte valori,
atunci coordonatorul trebuie să abandoneze din nou transferul. Pentru aceasta, după primul octet
care nu mai poate fi recepționat, subordonatul nu mai generează bitul de confirmare, adică lasă
linia SDA la nivel ridicat. În această situație, coordonatorul poate genera condiția de STOP pentru
a abandona transferul.
Dacă circuitul coordonator este receptor și nu mai poate recepționa date sau nu îi mai sunt
necesare, atunci el semnalează aceasta transmițătorului subordonat prin faptul că nu mai generează
recunoașterea după ultimul octet pe care îl poate recepționa. În această situație, transmițătorul
subordonat trebuie să elibereze linia SDA pentru a permite coordonatorului să genereze o condiție
de STOP.
Generarea impulsurilor de tact şi arbitrarea coordonatorilor

Structura I2C este, după cum s-a precizat anterior, o structură multicoordonator, adică într-un
sistem interconectat prin magistrala I2C pot să existe mai multe circuite care pot avea rolul de
coordonator. În cadrul unui transfer, delimitat de condiţiile de START şi STOP, există un singur
coordonator. Se poate întâmpla însă ca mai mulţi coordonatori să încerce simultan să iniţieze un
transfer. Prin urmare, este necesară o procedură de arbitrare în urma căreia să rezulte un
coordonator unic în cadrul fiecărui transfer. Procedura de arbitrare este descrisă în continuare.
Fiecare circuit coordonator generează propriile lui impulsuri de tact. Sincronizarea acestora
este absolut necesară pentru evitarea funcţionării haotice. Sincronizarea este posibilă datorită
funcţiei logice ŞI-cablat, realizată prin legarea împreună a tuturor terminalelor SCL. Sincronizarea
se produce în modul descris mai jos, cu referire la Figura 4.20.
În legătură cu această figură, precum şi cu alte diagrame de timp ce vor fi prezentate, se face
precizarea că semnalele CLK1, CLK2 şi DATA1, DATA2 sunt semnalele aduse la intrările etajelor
de ieşire corespunzătoare, cuplate la liniile SCL respectiv SDA.

Figura 4.20. Sincronizarea impulsurilor de tact

17 | P a g i n ă
 Prima tranziţie 1  0 a unui semnal CLK este cea a semnalului CLK1. Aceasta aduce linia
SCL la nivel coborât şi resetează CLK2. Ambii coordonatori încep să genereze starea 0 a
impulsului de tact. La un moment dat, CLK1 trece în starea 1, însă linia SCL este menţinută în
continuare în starea 0 pentru că starea 0 a tactului CLK2 încă nu s-a încheiat. Până la încheierea
acesteia, CLK1 introduce o stare de aşteptare. În momentul în care CLK2 trece din 0 în 1, linia
SCL este eliberată şi ambii coordonatori încep generarea stării 1 a impulsului de tact. Primul
semnal de tact care trece din nou din 1 în 0 aduce din nou linia SCL la nivel coborât. În acest fel
se generează impulsuri de tact sincronizate. Durata stării 1 este determinată de semnalul CLK cu
cea mai mică durată a stării 1 iar durata stării 0 este determinată preponderent de semnalul CLK
cu cea mai lungă durată a stării 0.
Arbitrarea coordonatorilor se face pe linia SDA, impulsurile de tact generate de coordonatori
fiind sincronizate în modul descris mai sus. Coordonatorul care transmite un nivel ridicat pierde
arbitrarea dacă în acelaşi timp un alt coordonator transmite un nivel coborât (Figura 4.21).
Coordonatorul care pierde arbitrarea trebuie să îşi deconecteze etajul de ieşire date, astfel încât să
nu mai influențeze starea liniei SDA.

Figura 4.21. Arbitrarea a doi coordonatori

Arbitrarea poate continua pe mai mulţi biţi. În prima etapă se compară biţii de adresă. Dacă
ambii coordonatori încearcă să adreseze acelaşi executant, arbitrarea continuă cu compararea
biţilor de date. Deoarece arbitrarea foloseşte biţii de adresă şi de date, nu se pierde informaţia în
timpul acestui proces.
Coordonatorul care pierde arbitrarea poate continua să transmită impulsuri de tact până la
sfârşitul octetului în care pierde arbitrarea.
Dacă un coordonator pierde arbitrarea în faza de adresare, este posibil ca acel coordonator care
o câştigă să încerce să-l adreseze. În această situaţie, coordonatorul care pierde arbitrarea trebuie
să treacă imediat în regim de executant (ascultător).
Observație, deoarece controlul magistralei I2C depinde numai de adresele și datele transmise
de coordonatori, nu există nici coordonator central și nici vreo ordine de prioritate pe magistrală.
Procedura de sincronizare a impulsurilor de tact, descrisă mai sus, se poate utiliza şi pentru
adaptarea vitezei de transfer fie la nivel de octet, fie la nivel de bit.
La nivel de octet, este posibil ca executantul să recepţioneze datele în ritmul impus de
coordonator, însă să necesite un timp mai lung pentru memorarea lor. În această situaţie,
executantul poate menţine linia SCL la nivel coborât, după recunoaşterea recepţionării unui octet,

18 | P a g i n ă
forţând coordonatorul să introducă o stare de aşteptare până când executantul este gata pentru
recepţia unui nou octet.
La nivel de bit, executantul care nu poate recepționa datele în ritmul impus de coordonator
poate încetini acest ritm prin extinderea stării 0 a impulsurilor de tact. În acest mod, viteza oricărui
coordonator se poate adapta la viteza oricărui executant.

Figura 4.22. Coordonatorul transmite unui receptor subordonat. Direcţia nu se schimbă

Figura 4.23. Coordonatorul citeşte de la subordonat imediat după ce a transmis adresa acestuia

Figura 4.24. Coordonatorul lucrează cu doi subordonaţi în cadrul aceleaşi sesiuni

Formatul mesajelor ce se vehiculează pe interfața I2C sunt arătate în Figura 4.22, Figura 4.23,
Figura 4.24.
În Figura 4.24 se arată situația când coordonatorul lansează condiţia de start, apoi adresa unui
subordonat cu care comunică. La terminarea comunicării cu acesta, masterul inițiază o comunicare
cu un al 2-lea subordonat. Pentru aceasta lansează o a doua condiție de start, adresa celui de-al 2-
lea suburdonat cu stabilirea sensului comunicării şi ulterior se realizează transferul. La sfârșit,
coordonatorul încheie cu condiția de stop. A doua condiție de start este necesară deoarece pe durata
condiției de start, circuitele cuplate la I2C se resetează și așteaptă să identifice adresa pe care
urmează să o transmită coordonatorul.

19 | P a g i n ă
Exemplu practic: senzorul de temperatură TMP112 – acesta este senzorul pe care dvs. îl utilizați
în cadrul laboratorului împreună cu sistemul de dezvoltare de tip IoT CC3200.

20 | P a g i n ă
21 | P a g i n ă
22 | P a g i n ă
Scriere de tip octet

În urma condiției de start generată de master, adresa dispozitivului sclav (slave) este plasată
pe magistrală de către sistemul master, care aici va transmite date. Acest lucru indică receptorului
slave adresat, că va urma un octet cu o adresă de cuvânt (adresa la care se va scrie) după ce acesta
va genera bitul de confirmare în timpul celui de-al nouălea ciclu de ceas.

Prin urmare, următorul octet transmis de master este cuvântul de addresă și acesta va fi
scris în indicatorul de adresă al memoriei 24LC02.

După primirea unui alt bit de confirmare (ACK) de la 24LC02, dispozitivul master va
transmite cuvântul de date care trebuie scris în locația de memorie adresată.

În final circuitul 24LC02 confirmă din nou și masterul generează o condiție de oprire.
Aceast fapt inițiază ciclul de scriere intern și, în această perioadă, 24LC02 nu va genera semnale
de confirmare.

Scrierea de tip pagină

Octetul de adresă dispozitiv (aici includem și bitul de scriere/citire), adresa unse se va scrie
în dispozitiv și primul octet de date sunt transmise către memoria 24LC02 în același mod ca într-
o scriere pe un octet. Dar, în loc să genereze o condiție de oprire, masterul transmite până la 8
octeți de date către 24LC02, care sunt stocate temporar în bufferul de pagină în circuit și vor fi
scrise în memorie după ce masterul va transmite o condiție de oprire. Dacă masterul transmite
mai mult de 8 octeți înainte de generarea condiției de oprire, contorul de adrese se va roti și datele
primite anterior vor fi suprascrise, aceasta deoarece circuitul de memorie 24LC02 are o pagină
de 8 octeți. Ca și în cazul operațiunii de scriere a unui singur octet, odată ce condiția de oprire
(stop) pe magistrala I2C este primită, va începe un ciclu de scriere intern a valorilor trimise.

23 | P a g i n ă
Acknowledge Polling
Deoarece dispozitivul nu va confirma roimirea unei informații în timpul unui ciclu de
scriere, acest lucru poate fi utilizat pentru a determina când ciclul este finalizat (această
caracteristică poate fi utilizată pentru a maximiza schimbul de date pe magistrală).

Citirea de la adresa curentă

Circuitul 24LC02 (dar nu numai el) conține intern un contor de adrese care menține adresa
ultimului cuvânt accesat, incrementată cu unul. Prin urmare, dacă accesul anterior (fie o operație
de citire, fie de scriere) trebuia să adreseze o valoare de la adresa n, următoarea operație curentă
de citire/scriere a adresei ar accesa datele de la adresa n + 1. La primirea adresei circuitului slave
cu bitul R/W setat la unul, 24LC02 emite o confirmare și transmite cuvântul de date pe opt biți
de la această adresă. Circuitul master nu va confirma transferul, dar generează o condiție de oprire
și 24LC02 întrerupe transmisia.

Citiri aleatorii
Operațiile de citire aleatorie permit circuitului master (de ex. un microcontroler) să
acceseze orice locație de memorie în mod aleatoriu. Pentru a efectua acest tip de operație de
citire, mai întâi trebuie setată adresa de la care se dorește citirea. Acest lucru se face prin
trimiterea cuvântului adresă de dispozitiv 24LC02 ca parte a unei operații de scriere, urmată de
adresa din dispozitiv de la care se va face citirea.

După trimiterea cuvântului adresă de citire, masterul generează o condiție de start după
confirmare (ACK). Aceasta oprește operațiunea de scriere, dar nu înainte ca indicatorul de adresă
intern să fie setat. Apoi, masterul emite din nou octetul de control, dar cu bitul R/W setat la unu.
24LC02 va emite apoi o confirmare și va transmite cuvântul de date pe opt biți. Circuitul master
nu va confirma transferul, dar generează o condiție de oprire și 24LC02 întrerupe orice transmisie
ulterioară de date.

24 | P a g i n ă
 Citire secvențială

Citirea secvențială este inițiată în același mod ca o citire aleatorie, cu excepția faptului că
după ce 24LC02 transmite primul octet de date, masterul emite o confirmare în opoziție cu o
condiție de oprire într-o citire aleatorie. Aceasta determină 24LC02 să transmită următorul cuvânt
pe 8 biți adresat secvențial (prezentat în figura 8). Pentru a furniza o citire secvențială, 24LC02
conține un registru indicator de adresă intern care este incrementat cu unul la finalizarea fiecărei
operații.

Adresarea în sistemul I2C

În cadrul protocolului I2C se impune ca primul octet după condiţia de start să fie adresa
subordonatului cu care coordonatorul doreşte să facă transfer. Adresa trebuie să urmeze după
condiţia S. Excepţie de la această regulă este situaţia de “adresare generală” la care toate
elementele din sistem trebuie să răspundă şi care se codifică prin doi octeţi. Totuşi, există elemente
care nu răspund (nu este util să răspundă) la “adresarea generală”. Ele vor ignora codul adresării
generale.

Cuvânt 8-biți
Index
Adresă 7-biți Bitul R/W
zonă de Descriere
adresare MSB LSB 1-bit
(4-bit) (3-bit)
1 0000 000 0 Adresare generală
2 0000 000 1 Cuvânt Start
3 0000 001 X Adresă pentru sistemele CBUS
4 0000 010 X Rezervat pentru diferite formate de magistrale
5 0000 011 X Rezervat pentru utilizări viitoare
6 0000 1XX X
Utilizate ca spațiu de adresare
7 1111 1XX 1
8 1111 0XX X Utilizat pentru adresarea pe 10 biți

La adresarea obişnuită, octetul ce urmează după condiţia S codifică pe primii 7 biţi mai
semnificativi ai adresei subordonatului, iar bitul mai puţin semnificativ este bitul R/W şi arată
sensul transferului. Atunci când se transmite adresa, fiecare dispozitiv din sistem compară adresa

25 | P a g i n ă
recepţionată cu propria adresă; dacă constată egalitatea, dispozitivul devine subordonat receptor
sau subordonat transmiţător, funcţie de valoarea bitului R/W.
Adresa unui subordonat poate avea o parte fixă şi o parte programabilă. Partea fixă defineşte
clasa dispozitivului (spre exemplu: memorii, dispozitive de afişare, microprocesoare, etc.) iar
partea programabilă identifică dispozitivul din clasa respectivă. Mărimea părţii programabile
depinde de numărul de pini pentru adresă pe care circuitul îi are. Spre exemplu, un circuit are 4
biţi de adresa fixă şi 3 biţi programabili; aceasta înseamnă că se pot conecta la magistrala I2C 8
dispozitive de acest fel.
Comitetul de coordonare al magistralei I2C a recomandat o alocare a celor 127 de adrese
prezentată în tabelul de mai sus. Adresele 11110xx sunt rezervate pentru adresarea cu 10 biţi,
folosită în sisteme I2C de mare întindere.
Bus-ul CBUS este unul pe trei fire, ce utilizează un format al pachetelor de date diferit de I2C.
Pentru a putea conecta module receptoare la o magistrală I2C s-a rezervat o adresă specială
(‘0000001X’). Dispozitivele pe bus I2C trebuie să ignore toate mesajele către această adresă.

Figura 4.25. Modul de adresare pe 10 biți

Adresarea generală

Este o adresare pentru toate dispozitivele din sitemul I2C care au fost prevăzute să recunoască
adresarea generală. Adresarea generală se face pe doi octeţi (figura 8.31): primul este 0000.0000,
iar al doi-lea octet specifică acţiunea pe care trebuie să o relizeze subordonaţii.

Figura 4.26. Formatul adresării generale

Funcţie de valoarea bitului B din octetul 2 distingem cazurile:

1. Dacă B = 0, al doilea octet are următoarele semnificaţii, funcţie de valoarea în cod
hexazecimal:

26 | P a g i n ă
a. 02h = “scrie adresa subordonat numai soft”. Elementele din sistemul I2C care obţin
partea programabilă a adresei lor prin program intră într-un regim prin care pot fi
programate. Nu se face resetul circuitului.
b. 04h = “scrie adresa subordonatului numai hard”. Elementele din sistemul I2C care
obţin partea programabilă a adresei lor prin starea unor circuite (bistabile,
comutatoare) vor încărca în registrul intern de adresă această parte fixă de adresă.
Nu se face resetul circuitului.
c. 06h = “reset” şi “scrie partea programabilă a adresei hard şi soft” Elementele din
sistem realizează două operaţii: se iniţializează (revin în starea bine definită de
fabricant) şi îşi preiau adresa, atât partea fixă cât şi partea programabilă şi în ordinea
stabilită de proiectantul sistemului. În Figura 4.27 se arată secvenţa de încărcare a
adreselor. Cu ABCD s-a notat partea fixă a adresei.
d. 00h - acest cod nu este permis a fi utilizat ca al doilea octet într-o adresare generală.

Figura 4.27. Secvenţă de programare a adreselor de către coordonator

27 | P a g i n ă
 4.3. Bluetooth

Introducere

Bluetooth reprezintă un set de specificații, un standard de comunicare fără fir, între dispozitive
de diverse tipuri. Tehnologia se bazează pe undele radio. La origine Bluetooth a susținut o
comunicare pe distanțe scurte de tip WPAN (Wireless Personal Area Network). Dar, o dată cu
standardul Bluetooth 5.0 lucrurile s-au schimbat.
Bluetooth a fost inventat, dezvoltat și implementat în anul 1994 în cadrul companiei Ericsson.
Începând cu anul 1998 acest standard a început să fie administrat de grupul Bluetooth Special
Interest Group (SIG), organizație ce se ocupă de dezvoltarea standardului și licențierea lui în
vederea folosirii de către alte companii.
Standardul Bluetooth s-a dezvoltat în mod considerabil pornind de la Bluetooth 1.0 și a evoluat
ulterior în Bluetooth 2.0+EDR, Bluetooth 3.0+HS, Bluetooth 4.0 și ajungând actualmente la
Bluetooth 5.0. Toate acestea sunt dezvoltări ale standardului de-a lungul timpului. De exemplu,
standardul Bluetooth 4.0 se referă la întreaga tehnologie Bluetooth, deci, Bluetooth Smart sau
Bluetooth Low Energy este un subset a standardului Bluetooth 4.0, o componentă ce a fost
adăugată o dată cu adoptarea acestui standard pe data de 30 iunie 2010. Dacă, o parte din aceste
evoluții ale standardului Bluetooth sunt doar dezvoltări incrementale care aduc îmbunătățiri la
ceva existent – de exemplu, Bluetooth 4.1 acceptă ca un dispozitiv să fie de tip multi-rol3 (să
funcționeze simultan și ca un dispozitiv de tip central sau master și ca un dispozitiv periferic sau
slave), în timp ce în specificațiile Bluetooth 4.0 dispozitivul putea avea, la un anumit moment dat,
doar una din aceste funcții. Alte evoluții ale standardului sunt fundamentale. De exemplu,
Bluetooth 4.0 aduce implementarea Bluetooth Smart sau Low Energy. Astfel, în cadrul Bluetooth
4.0 exista două clase de dispozitive: Bluetooth Classic (1.0, 2.0 și 3.0) și Bluetooth Low Energy.
Bluetooth Smart (Low Energy) este un standard total incompatibil cu standardul Bluetooth Clasic.

Scurtă prezentare a diferitelor versiuni ale standardului

Prima versiune, Bluetooth 1.0, deși a pus bazele standardului Bluetooth este considerată una
cu multe probleme. Abia versiunile 1.1 și 1.2 au fost capabile să corecteze cea mai mare parte a
erorilor existente și au adus noi îmbunătățiri care au generat o creștere a performanțelor
standardului. De exemplu, introducerea sistemului radio de tip spectru împrăștiat cu salt adaptiv
de frecvență (adaptive frequency-hopping spread spectrum – AFH) a determinat o creștere a
imunității protocolului la zgomote. Viteza maximă de transfer a datelor a fost de 723.1 Kbps.
Versiunea 2.0 a standardului aduce un salt calitativ prin introducerea specificațiilor Enhanced
Data Rate (EDR) - Bluetooth 2.0 + EDR. EDR urmărește creșterea vitezei de transfer a
protocolului Bluetooth, obținându-se astfel o viteză de 3 Mbps (pentru versiunea 2.1 a
standardului) și 2.1 Mbps pentru versiunea 2.0. Tot versiunea 2.1 a standardului aduce o
îmbunătățire a securității, vitezei de conectare și o reducere a consumului (încă din versiunea 2.0).
O dată cu versiunea 3.0 a standardului Bluetooth își face apariția și Bluetooth High Speed –
Bluetooth 3.0 + HS. Acum viteza de transfer a datelor ajunge până la 24 Mbps dar nu prin
intermediul conexiunii Bluetooth. În această situație Bluetooth-ul este folosit precum un canal de

3
Toate noile caracteristici existente în standardele Bluetooth 4.1 și 4.2 sunt opționale, deci inclusiv funcționalitatea
de tip multi-rol. Adică, nu există obligativitatea implementării lor pentru ca dispozitivul respectiv să fie certificat
de tip Bluetooth.

28 | P a g i n ă
control, prin acesta se realizează negocierea și configurarea conexiunii, schimbul de date se
realizează prin intermediul unei conexiuni Wi-Fi (bazată pe standardul 802.11). Pe lângă această
facilitate, multe alte îmbunătățiri sunt aduse de versiunea 3.0 a standardului.

Tabelul 4.3. Evoluția standardului Bluetooth

2.0 2.1 3.0
Versiune 1.1 1.2 4.0 5.0
+EDR +EDR +HS
Dată 2002 2005 2004 2007 2009 2010 2016
Viteză 723.1 723.1 2.1 3 24 2 0.125, 0.5, 1, 2
conexiune kbps kbps Mbps Mbps Mbps Mbps Mbps
Distanță 10 m 10 m 10m 10 m 10 m 50 m 40, 50, 100, 200 m

Atât EDR cat și HS nu sunt obligatorii fiind opționale doar dispozitivele care menționează
+EDR sau +HS au implementate și aceste funcționalități.
Sinonim numelui Classic Bluetooth este Bluetooth BR/EDR ambii termeni reprezentând unul
și același lucru. Acronimul BR identifică Bluetooth 1.0, 1.1 și 1.2 în timp ce EDR identifică
Bluetooth 2.0.
În anul 2010 a apărut standardul Bluetooth 4.0 care aduce ca noutate absolută Bluetooth Low
Energy (Bluetooth LE, BLE sau Bluetooth Smart). Acest standard include protocoalele Classic
Bluetooth, Bluetooth High Speed – un clasic cu viteză și Bluetooth Low Energy. Introducerea
Bluetooth LE aduce cu sine o nouă stivă de protocoale, Figura 4.28, și multe modificări necesare
scăderii consumului necesar transferului de date pe baza acestui protocol.
În anul 2016 apare versiunea 5.0 a standardului Bluetooth. Toate îmbunătățirile aduse de acest
standard se referă doar la Bluetooth Low Energy, neaducând nimic nou protocolului Bluetooth
Classic. Noile caracteristici ale acestui standard se concentrează, în principal, pe susținerea și
dezvoltarea tehnologiei internetului tuturor obiectelor (IoT) ce necesită dispozitive care să
consume foarte puțin, cu care să se poate comunica la o distanță mult mai mare cu o viteză cât mai
mare. Pentru prima dată se introduce posibilitatea creșterii vitezei de transfer a datelor în
detrimentul distanței sau creșterea distanței și de aici a ariei de acoperire dar se diminuează viteza
de transfer.
În cele ce urmează ne vom concentra prezentare pe protocolul Bluetooth Low Energy cu
referire la standardele Bluetooth 4.0, 4.1, 4.2 și 5.0. Din când în când vom face referire și la
protocolul Bluetooth Clasic dar doar pentru a pune în evidență noile caracteristici ale Bluetooth
LE sau pentru susține diferitele afirmații care compară cele două protocoale: Bluetooth Low
Energy și Bluetooth Clasic.

Stiva de protocoale

Standardul Bluetooth este o colecție de protocoale grupate pe diferite niveluri, straturi. Stiva
de protocoale Bluetooth LE precizează rolul diferitelor componente utilizate în implementarea
standardului de comunicații Bluetooth și a modului în care aceste componente se conectează între
ele pentru schimbul de date.
În cele ce urmează vom insista doar asupra unor componente ale stivei de protocoale Bluetooth,
în principal asupra acelor componente care ne vor fi de folos și ne vor ajuta în dezvoltarea
programelor pe care le vom construi.

29 | P a g i n ă
 Aplicație

(GAP)

Host

Controller
(a) (b)
Figura 4.28. Stiva de protocoale: (a) Bluetooth Clasic și (b) Bluetooth Low Energy

Stratul fizic (PHY)

Stratul fizic este stratul cel mai de jos a stivei de protocoale și definește parametrii fizici,
caracteristici ai transmisiei și recepției radio: banda de frecvență, structura canalelor, nivele admise
ale puterii de emisie, nivelul de sensibilitate al receptorului, tipul modulației, viteza de transfer a
datelor etc.

Tabelul 4.4. Benzile de tipul ISM

Frecvență
Domeniu de frecvență Tip Disponibilitate
centrală
6.765 MHz 6.795 MHz A 6.78 MHz Locală
13.553 MHz 13.567 MHz B 13.56 MHz La nivel mondial
26.957 MHz 27.283 MHz B 27.12 MHz La nivel mondial
40.66 MHz 40.7 MHz B 40.68 MHz La nivel mondial
433.05 MHz 434.79 MHz A 433.92 MHz Nunai în regiunea 14
902 MHz 928 MHz B 915 MHz Nunai în regiunea 25
2.4 GHz 2.5 GHz B 2.45 GHz La nivel mondial
5.725 GHz 5.875 GHz B 5.8 GHz La nivel mondial
24 GHz 24.25 GHz B 24.125 GHz La nivel mondial
61 GHz 61.5 GHz A 61.25 GHz Locală
122 GHz 123 GHz A 122.5 GHz Locală
244 GHz 246 GHz A 245 GHz Locală
Bluetooth ca și Wi-Fi utilizează banda de 2.4 GHz pentru transferul de date. Aceasta este o
bandă radio de tipul ISM (Industrial, Scientific and Medical), vezi Tabelul 4.4. Benzile ISM sunt
rezervate pe plan internațional aplicațiilor industriale, științifice și medicale care utilizează undele

4
Regiunea 1 – este compusă din Europa, Africa, Rusia, Orientul Mijlociu etc.
5
Regiunea 2 – include în principal America la care se adaugă insulele din Pacific (Micronezia, Polinezia și
Melanezia) și Groenlanda.

30 | P a g i n ă
electromagnetice (din aceste benzi) pentru orice alte scopuri care nu implică schimbul de date –
de exemplu, sistemele de încălzire prin intermediul radiațiilor electromagnetice (a microundelor).
În Tabelul 4.4 avem două tipuri diferite de benzi. Tipul A este dedicat exclusiv aplicaților
industriale, științifice și medicale ce utilizează undele radio, în timp ce în benzile de tip B sunt
acceptate și comunicațiile radio, dar cu mențiunea că acestea trebuie să accepte existența unor
puternice perturbații în aceste benzi generate de aplicațiile practice ce utilizează radiațiile
electromagnetice.
Spectrul de lucru al Bluetooth LE este puternic perturbat de multe alte tipuri de dispozitive
precum cuptorul cu microunde (ce operează la 2.45 GHz) sau de multe alte sisteme ce utilizează
comunicații în acest spectru: Wi-Fi, Bluetooth clasic, dispozitive ce utilizează standardul
IEEE802.15.4 (ZigBee, 6LoWPAN etc.), radio modelele, etc.
Tabelul 4.5. Comparație între parametrii transmisiei și performanțele obținute între diferitele
standarde Bluetooth
Clasic BLE
Bluetooth 5
Standard BR EDR Bluetooth 4.0
LE 1M6 LE (S=2) LE (S=8) LE 2M7
GFSK,
index DQPSK/
Modulație GFSK, index modulație: [0.45, 0.55]
modulație: 8DSPK
[0.28, 0.35]
Viteză 2 sau 3
1 Mbit/s 1 Mbit/s 1 Mbit/s 1 Mbit/s 1 Mbit/s 2 Mbit/s
simbol Mbit/s
Viteză date 2 sau 3 500 125
1 Mbit/s 1 Mbit/s 1 Mbit/s 2 Mbit/s
utile Mbit/s Kbit/s Kbit/s
Canale
79 79 40 40 40 40 40
număr
Spațiu
1 MHz 1MHz 2 MHz 2 MHz 2 MHz 2 MHz 2 MHz
canale
Distanță 10 m 10 m 50 m 50 m 100 m 200 m 40 m
În afara de banda pe care o utilizează, Bluetooth LE are anumite similarități cu standardul
Bluetooth clasic. Observăm că atât Bluetooth BR cât și BLE utilizează același tip de modulație
GFSK (Gaussian frequency-shift keying) dar, indexul de modulație este diferit, numărul de canale
este altul (79 versus 40), iar spațiul dintre canale este și el diferit (1 MHz versus 2 MHz). Mai
mult, Bluetooth EDR utilizează un alt tip de modulație – vezi Tabelul 4.5. Datorită acestor
diferențe Bluetooth clasic și Blutooth LE sunt incompatibile și nu pot schimba date între ele.
Cu toate acestea există module radio duale care pot comunica atât cu dispozitive Bluetooth
clasice cât și cu Blutooth LE prin schimbarea parametrilor de modulație și a canalelor de
transmisie/recepție.
Banda în care Bluetooth-ul LE funcționează începe cu frecvența de 2.402 GHz și se sfârșește
cu frecvența de 2.480 GHz, vezi Figura 4.29. În această bandă sunt 40 de canale (numerotate de
la 0 la 39). Dintre aceste 3 canale (canalele 37, 38 și 39) sunt utilizate pentru ca fiecare dispozitiv
să se prezinte (Advertising Channels) și 37 de canale pentru transferul de date (canalele de la 0 la
36). În Figura 4.29 se prezintă frecvențele asociate cu fiecare bandă în parte.

6
Identic ca implementare și performanțele cu Bluetooth 4.0, în cadrul standardului Bluetooth 5 este obligatorie
implementarea lui
7
Este opțională susținerea lui de către stiva de protocoale

31 | P a g i n ă
2402 MHz 37
2404 MHz 0

Canal 1
2406 MHz 1
2408 MHz 2
2410 MHz 3

Canal 2
2412 MHz 4 2412 MHz

2414 MHz 5
6

Canal 3
2416 MHz
2417 MHz
2418 MHz 7
2420 MHz 8

Canal 4
2422 MHz 9 2422 MHz

2424 MHz 10
2426 MHz 38

Canal 5
2426 MHz
2428 MHz 11
2430 MHz 12
Canal 6

2432 MHz 13 2432 MHz

2434 MHz 14
Canal 7

2436 MHz 15
2437 MHz
2438 MHz 16
2440 MHz 17
Canal 8

2442 MHz 18 2442 MHz

2444 MHz 19
Canal 9

2446 MHz 20
2447 MHz
2448 MHz 21
22

Canal 10
2450 MHz

2452 MHz
23 2452 MHz

2454 MHz 24
Canal 11

2456 MHz 25
2457 MHz
2458 MHz 26
2460 MHz 27
Canal 12

2462 MHz 28 2462 MHz

2464 MHz 30
Canal 13

2466 MHz 31
2467 MHz
2468 MHz 32
2470 MHz 33
2472 MHz 34 2472 MHz

2474 MHz 35
2478 MHz 36
C. 14

2480 MHz 39

Figura 4.29. Alocarea benzilor standardului Bluetooth LE comparativ cu Wi-Fi

32 | P a g i n ă
 Pentru reducerea interferențelor cu alte tipuri de rețele ce utilizează aceeași bandă, precum Wi-
Fi, se recomandă ca acestea să fie configurate pentru a lucra pe unul din următoarele canale 1, 6,
7, 8, 9, 10, 11 și 12. Deoarece canalele Wi-Fi 2, 3, 4, 5, 13 și 14 se suprapun și interferează în
special cu Advertising Channels ale standardului Bluetooth se recomandă neutilizarea lor. Dacă,
de exemplu, avem de configurat 3 puncte de acces Wi-Fi (acces points) atunci cel mai indicat este
să utilizăm canalele 1, 6 și 11. În acest mod nu vom avea interferențe între canalele de Wi-Fi și
vom avea interferențe “minime” cu echipamentele ce lucrează pe standardul Bluetoot LE.
Prin creșterea vitezei de transfer a datelor de la 1 Mbps (LE 1M, din Tabelul 4.5) la 2 Mbps
(LE 2M, din Tabelul 4.5), în cadrul Bluetooth 5, modemul radio va sta mai puțin timp deschis
(primind sau transmițând date) și în acest mod se va reduce și energia consumată în transmiterea
aceleiași cantități de date.

Figura 4.30. Formatul pachetului pentru standardele Bluetooth 4.0 și 4.1

Link Layer

Acest strat al stivei de protocoale se ocupă în principal cu realizarea conexiunii, controlul

erorilor și managementul fluxului de date.
Dispozitivele conectate prin intermediul standardului BLE trebuie sa schimbe între ele diferite
informații precum pachetele: de control (pentru configurarea și managementul conexiunilor) și
cele de date (de exemplu, informațiile de la diferiții senzori încastrați pe dispozitivul de tip IoT).
Structura acestor pachete de date este definita la nivelul stratului de link (link layer) și este
prezentată în Figura 4.30 pentru standardul Bluetooth 4.0 și 4.1 și în Figura 4.31 pentru
standardele Bluetooth 4.2 și Bluetooth 5.
De exemplu, formatul pachetului pentru standardele Bluetooth 4.0 și 4.1 este prezentat în
Figura 4.30. Se observă din figură că pachetele de date sunt constituite dintr-o secvență de octeți
fiecare cu un rol bine stabilit. Primul octet (preamble) înglobează o secvență de biți de tipul
10101010 având rolul de a permite receptorului să se sincronizeze. Următorul octet este un cod de
acces de 32 de biți, urmat de un pachet de tip PDU (protocol data unit) – pachet care conține

33 | P a g i n ă
efectiv datele și un cod CRC (Cyclic Redundancy Check) necesar verificării integrității datelor
transmise. În momentul detectării unei erori, atât în cadrul Bluetooth 4.0 cât și a standardului
Bluetooth 5, se cere retransmiterea pachetului. Din Figura 4.30 observăm că informația utilă
maximă, care se poate transmite pe canal, are un număr de 31 de octeți (27 octeți payload + 4
octeți MIC8).
Pentru ușurința implementării în cadrul standardului Bluetooth se definește un singur pachet
de date, atât pentru pachetele de date în care dispozitivul se prezintă (advertising), își anunță
existența celor din jurul său, cât și pentru transferul de date.

Figura 4.31. Formatul pachetului pentru standardele Bluetooth 4.2 și Bluetooth 5

Observăm că una din principalele îmbunătățiri ale standardului a apărut începând cu versiunea
4.2 în care mărimea maximă a pachetului de date util a fost crescută la 251 de octeți – având la
bază un PDU (Protocol Data Unit) cu o lungime variabilă între 2 octeți (atunci când Length = 0)
și 257 octeți (atunci când Length = 255 = 251 octeți payload + 4 octeți MIC).
Atât Bluetooth 4.0 (cu toate versiunile acestui standard) dar și Bluetooth 5 sunt standarde care
folosesc pentru transmisie-recepție tehnica spectrului împrăștiat cu salt în frecvență. Aceasta
înseamnă ca purtătoarea face salturi în frecventa acoperind întreg spectrul dat de cele 37 de canale
utilizate în transmisia de date, numerotate cu valori de la 0 la 36 în Figura 4.29. Rata uzuala a
salturilor este de 800 salturi pe secunda, deci la fiecare 1.25 ms, asigurând astfel o foarte buna
protecție la interferente în banda de 2.4 GHz. Acest mecanism poartă numele de adaptive
frequency hopping (AFH). Prin termenul adaptiv se înțelege că acele canale care sunt în mod
frecvent congestionate vor fi evitate în viitoarele transmisiuni de date.
O altă caracteristică a acestor salturi rapide în frecventa în frecvență a purtătoarei o reprezintă
lungimea mică a pachetelor de date ce sunt tranzacționate – trimise-recepționate. În cadrul
standardului Bluetooth LE fereastra de timp a conexiunii pe un anumit canal este de ordinul a o
ms, comparativ cu Bluetooth Clasic unde acest timp este în jurul a 100 ms. Această caracteristică

8
message integrity check

34 | P a g i n ă
a BLE este un avantaj deoarece dacă un pachet nu este recepționat corect de un dispozitiv, acesta
solicită retransmisia pachetului dar pe un alt canal din lista celor care nu sunt congestionate cu date
diferite de diferite tipuri.
În momentul existenței unei conexiuni de date, în cadrul Bluetooth 4.0, saltul în frecvență, de
la un canal la altul se realizează conform relației:
Canal n+1 = ( Canal n + increment ) mod 37 (4.2)
valoarea de incrementare poate lua valori în intervalul [5, 16] și este aleasă la început când
conexiunea a fost realizată.

Figura 4.32. Exemplu de trei conexiuni realizate printr-un mecanism de salt în frecvență

În Figura 4.32 se prezintă un grafic frecvență canal – timp în care se arată schematic 3
conexiuni active realizate prin intermediul standardului BLE. În imagine se prezintă salturile de
frecvență pentru cele trei conexiuni.
Mai mult pentru emisie și recepție se folosesc și sloturi temporale succesive.
Tot acest strat al stivei realizează și încriptarea comunicației. De exemplu, Bluetooth 4.0
utilizează AES-128.
În plus față de utilizarea celor 3 octeți pentru detecția erorilor (CRC în Figura 4.30 și Figura
4.31) standardul Bluetooth 5 introduce și un algoritm de corecție a erorilor. În acest mod se pot
obține corect pachetele de date chiar la valori mult mai scăzute ale raportului semnal zgomot. De
aici rezultă o creștere a distanței de recepție fără a crește puterea emițătorului. Algoritmul de
corecție a erorilor utilizat aici este FEC (Forward Error Correction), ce implementează două
scheme diferite de codare, denumite S=2 și S=8 (vezi Tabelul 4.5). Rezultatul utilizării acestui
algoritm de corecție este imediat: (a) pentru S=2 distanța de la care se pot recepționa corect datele
se dublează, în timp ce (b) pentru S=8 această distanță devine de aproximativ 4 ori mai mare.
Dezavantajul este dat de o scădere a vitezei de transfer a informație utile datorită adăugării în plus
a unui număr de simboluri necesare corectării potențialelor erori.

35 | P a g i n ă
 L2CAP

Unul din rolurile fundamentale ale stratului L2CAP este de a multiplexa și demultiplexa datele
de la stratul superior sau de la cel inferior permițând fragmentarea pachetelor de mari dimensiuni
(la trimiterea acestora) și reasamblarea lor la recepție.

GATT

Generic Attribute Profile (GATT) stabilește cum datele vor fi organizate și schimbate prin
intermediul unei conexiuni BLE. Deci comunicarea în cadrul standardului Bluetooth LE este
implementată prin intermediul stratului GATT prin utilizarea Attribute Protocol (ATT) sub forma
abordării clasice de tip client/server. Astfel un dispozitiv va fi de tipul server conținând resursele
care pot fi citite sau scrise, resurse organizate într-un tabel de atribute. Serverul acceptă diferite
cereri de la un client și răspunde la acestea. Rolul unui astfel de dispozitiv este echivalent cu cel
de dispozitiv periferic definit în stratul superior GAP (Generic Access Profile). Dispozitivul client
lansează cereri de scriere, citire sau cereri legate de prezența și tipul atributelor existente pe un
server. La toate acestea primește răspunsuri din partea serverului. Clientul se comportă în
conformitate cu rolul de dispozitiv central definit de GAP.

Figura 4.33. Organizarea ierarhică a atributelor

GATT stabilește o organizare ierarhică a atributelor, care la nivelul superior sunt cuprinse într-
o entitate de tip profil server GATT – GATT Server Profile, vezi Figura 4.33.
Fiecare dispozitiv de tip server oferă cel puțin unul sau mai multe servicii. Mai multe servicii
pot fi grupate pentru a forma un profil. Deoarece, în multe aplicații practice, multe profile
înglobează doar un singur serviciu, de multe ori acești doi termeni sunt utilizați pentru a referi unul
și același lucru cu toate că diferența între ei este una foarte clară.
Serviciile sunt colecții de caracteristici, care operează împreună pentru a îndeplini o anumită
funcție specifică. De exemplu, în cazul sensortag-ului CC2650STK, serviciul accelerometru

36 | P a g i n ă
include toate acele caracteristici necesare stocării valorii accelerației pe cele 3 axe, configurării
activării sau nu a anumitor canale și configurării perioadei de eșantionare a accelerațiilor pe cele
trei axe. Serviciile sunt de două tipuri: (a) publice, definite de grupul care gestionează standardul
Bluetooth9 – având un identificator (UUID) pe 16 biți și (b) private, definite de producătorul
dispozitivului care comunică prin Bluetooth – acestea au un identificator pe 128 de biți.
Identificatorii pe 16 biți sunt utilizați în special pentru eficiență, pentru minimizarea numărului de
biți transmiși.
În cadrul protocolului există servicii pe care un dispozitiv trebuie să le implementeze în mod
obligatoriu, precum serviciul Generic Access data, altele care sunt definite de standard dar
implementarea lor este opțională, precum Device Information și servicii private care pot avea orice
structură dorește dezvoltatorul sistemului (evident respectând standardul Bluetooth LE).
Handle UUID Valoare
16 biți 16 sau 128 de biți între 1 și 512 octeți
Figura 4.34. Modul în care este definit un atribut în ATT

Atributul este unitatea cea mai mică de date care poate fi adresată în cadrul GATT și ATT.
Poate fi adresat în cadrul ATT prin intermediul unui hadle pe 16 biți. Atributul are un câmp de
tip, care este identificat prin intermediul unui UUID (Universally Unique Identifier) reprezentat
pe 16, 32 sau 128 de biți – dacă se utilizează o reprezentare a identificatorului pe 32 de biți aceștia
trebuie convertiți la o valoare de 128 de biți înainte de a fi transmiși mai departe prin intermediul
protocolului ATT. În plus atributul mai înglobează și un câmp de date.
Handle

UUID Valoare
57 ... ...
58 2800 00:00:00:00:00:00:00:B0:00:40:51:04:80:AA:00:F0

Caracterisitică
59 2803 12:3C:00:00:00:00:00:00:00:00:B0:00:40:51:04:81:AA:00:F0 Declarație
F000AA81-0451- 00:00:00:00:00:00:
Atribut
60 4000- 00:00:00:00:00:00:
valoare
B000000000000000 00:00:00:00:00:00:
61 2902 01:00 Config.
62 2803 0A:3F:00:00:00:00:00:00:00:00:B0:00:40:51:04:82:AA:00:F0 Serviciu
risitică 2
Caracte

F000AA82-0451-
63 4000- 00:02
B000000000000000
64 2803 0A:41:00:00:00:00:00:00:00:B0:00:40:51:04:83:AA:00:F0
risitică 3
Caracte

F000AA83-0451-
65 4000- 64
B000000000000000
66 ... ...
Figura 4.35. Exemplu de serviciu, caracteristici și atribute extrase din comunicația între două
dispozitive

9
Bluetooth SIG (Special Interest Group)

37 | P a g i n ă
 Mai multe atribute definesc o caracteristică. O caracteristică conține întotdeauna minimal
un atribut de tip valoare și o declarație (un atribut de tip declarație de caracteristică). Declarația va
preceda întotdeauna atributului de tip valoare. Semnificația valorii este dată de cel care a
implementat tabelul de atribute. Declarația descrie dacă valoarea de tip atribut poate fi citită sau
scrisă (drepturile asupra valorii), conține UUID caracteristicii și un handle către atributul de tip
valoare care va urma.
Valorile caracteristicilor (valoarea atributului de tip valoare) care sunt private, au un UUID pe
128 de biți și trebuie definite de către producătorul dispozitivului ce are implementat această
caracteristică. În Figura 4.35 se prezintă doar o secțiune, un singur serviciu, din cele existente în
cadrul Sensortag-ului CC2650STK. Serviciul prezentat este Movement Service. Semnificația
valorilor existente în primul atribut de valoare (cu UUID-ul F000AA81-0451-4000-
B000000000000000, atributul cu handler-ul 60) a fost impusă de producătorii Sensortag-ului și
este următoarea: (a) primii șase octeți sunt valorile de la senzorul giroscopic, câte doi octeți pe
fiecare canal, (b) urmează valorile de la senzorul accelerometric și (c) totul se încheie cu valorile
obținute de la senzorul magnetometric. Valorile asociate cu UUID-ul F000AA82-0451-4000-
B000000000000000 (doi octeți) permit configurarea senzorilor accelerometric, giroscop și
magnetometru, iar valoarea asociată cu UUID-ul F000AA83-0451-4000-B000000000000000
permite configurarea perioadei de achiziție.
În schimb UUID unui atribut, susținut de standard, definește pentru un dispozitiv cum va fi
tratat câmpul valoare din cadrul atributului, vezi Figura 4.34. De exemplu, mergând pe exemplul
practic prezentat în Figura 4.35, UUID = 0x2800 este o declarație de tip Primary Service
Declaration10 aceasta înseamnă că în câmpul valoare se va stoca identificatorul (UUID)
serviciului, care în cazul nostru este F000AA80-0451-4000-B000000000000000. UUID = 0x2803
este o declarație de caracteristică, ceea ce înseamnă că în câmpul valoare primul octet va indica
drepturile de acces (de tip citire/scriere etc.) asupra atributului de tip valoare conținut în
caracteristică, urmează un câmp de legătură cu următorul atribut și UUID-ul atributului de tip
valoare, Figura 4.35.
Valoarea 0x2902 definește un descriptor de tip Client Characteristic Configuration
Descriptor, care este mai mult cunoscut după abrevierea sa CCCD. În momentul în care clientul
scrie valoarea 0x0001 serverul de tip Bluetooth va trimite notificări (notification) aplicației client,
iar pentru scrierea valorii 0x0002 va determina serverul să comute pe modul de transfer indication.
Observăm că toate aceste UUID-uri (0x2800, 0x2803 și 0x2902) sunt pe 16 biți fiind
identificatori publici, definiți de grupul care gestionează standardul Bluetooth. Pe lângă
identificatorii pe 16 biți există și identificatori pe 32 de biți – toți aceștia pot fi utilizați doar cu
UUID-urile definite de standardul Bluetooth. Pentru a reconstrui identificatorii pe 128 de biți din
identificatorii pe 16 biți (0xabcd) sau pe 32 de biți (0xabcdefgh) cu a, b, c, d, e, f, g și h simboluri
în baza 16, aceste valori se înserează în următorul identificator pe 128 biți sub forma:
0000abcd-0000-1000-8000-00805F9B34FB (4.3)
abcdefgh-0000-1000-8000-00805F9B34FB (4.4)
Există patru modalități de transfer a datelor:
 Citire – transferul de date are loc de la server la client. În acest mod un client (de
exemplu o aplicație de pe telefonul mobil) va citi date de pe server (de exemplu un

10
https://www.bluetooth.com/specifications/gatt/declarations

38 | P a g i n ă
 SensorTag);
 Scriere – transferul, de această dată, va fi invers celui prezentat anterior. Clientul va
scrie date în server – de exemplu va configura intervalul de citire a senzorilor sau va
activa dezactiva diferite canale ale senzorilor existenți pe SensorTag;
 Notify – clientul va fi notificat de server atunci când valoarea ce aparține unei anumite
caracteristici se va schimba și această valoare va fi transmisă;
 Indicate – în mod similar ca la punctul anterior (clientul va fi notificat
de obținerea unui nou set de date), dar de această dată serverul așteaptă confirmarea
luării la cunoștință a acestui fapt de către client.

GAP

GAP (Generic Access Profile) este o componentă a arhitecturii Bluetooth, rolul ei principal
este de a susține și preciza cum dispozitivele se descoperă unele pe altele, cum se conectează și
cum se închide o conexiune.
În conformitate cu funcționalitățile susținute de GAP și cu specificitățile standardului
Bluetooth un dispozitiv poate avea unul din următoarele patru roluri:
1. Emițător (broadcaster) – un astfel de dispozitiv va emite continuu pachete de date
transformându-se într-o baliză Bluetooth (Bluetooth beacon): iBeacon, AltBeacon,
EddyStone etc. Un astfel de dispozitiv nu va accepta conexiuni.
2. Observator (observer)
3. Periferic (peripheral)
4. Central (central)

39 | P a g i n ă
 4.4. MQTT

Introducere

Odată cu apariția IoT-ului, a apărut și necesitatea preluării cât mai rapide a unor cantități mari
de date, de la un număr mare și foarte mare de dispozitive (de cele mai multe ori cu capabilități
limitate de stocare și procesare), distribuite pe zone întinse, dispozitive ce au limitări de
conectivitate (având constrângeri importante de lățime de bandă) și, în final, eventual stocarea sau
procesarea acestor date în Cloud. Pentru rezolvarea acestor provocări a fost dezvoltat protocolul
MQTT.
MQTT este un protocol de comunicație prin internet, pe baza protocoalelor de tip TCP/IP,
între un server (denumit message broker) și mai mulți clienți, având ca fundament modelul
"publicare și abonare" (publish and subscribe). MQTT este un protocol de conectivitate de tip
mașină-mașină (M2M) sau Internet of Things (IoT), conceput să fie cât mai simplu și flexibil, cu
cerințe minime de resurse (mărime cod, consum redus de energie, memorie și putere de calcul),
utilizat în conexiuni cu sisteme încorporate plasate la distanță și capabil a fi utilizat pentru toate
tipurile de aplicații IoT – de la cele industriale sau din industria automotive până la cele de tip
bunuri de larg consum. La început MQTT era acronimul la Message Queue Telemetry Transport
- transport de telemetrie în coadă de mesaje. Actualmente, datorită evoluției protocolului, MQTT
nu mai este un acronim, este chiar numele protocolului.
Există o serie largă de aplicații și sisteme cloud care folosesc MQTT, printre aceastea putem
aminti: Facebook Messenger, Instagram, Amazon Web Services, Adafruit, Microsoft Azure, IBM
Cloud, OpenStack sau Node-RED.

Scurt istoric

MQTT a fost creat de Andy Stanford-Clark și Arlen Nipper în anul 1999, în cadrul companiei
IBM. Scopul inițial al acestui protocol de comunicare a fost acela de a permite dispozitivelor de
monitorizare utilizate în industria petrolului și a gazelor să își trimită datele către serverele centrale
plasate la mare distanță față de senzori. În multe situații, aceste dispozitive de monitorizare erau
plasate în locații îndepărtate, pustii, unde orice fel de linie fixă, conexiune cu fir sau conexiune
radio ar fi fost dificilă sau imposibil de stabilit. La acea vreme, singura opțiune pentru astfel de
cazuri erau comunicațiile prin satelit, care erau foarte scumpe și facturate în funcție de cantitatea
de date folosite. Cu mii de senzori în domeniu, industria a avut nevoie de o formă de comunicare
care să poată oferi date suficient de fiabile pentru utilizare, folosind în același timp o lățime de
bandă minimă.
Protocolul MQTT a fost standardizat ca sursă deschisă în cadrul Organizației pentru
Îmbunătățirea Standardelor Informaționale Structurate (OASIS) în 2013. OASIS gestionează în
continuare standardul MQTT.
Acest protocol inițial al companiei IBM fost îmbunătățit de-a lungul timpului. O versiune
importantă a lui a fost 3.1, apărută în anul 2010, versiune de bază care este considerată piatra de
temelie a acestui protocol și care definește momentul în care compania IBM a permis utilizarea
liberă a protocolului de oricine este interesat. În anul 2014, pe 30 octombrie, MQTT versiunea

40 | P a g i n ă
3.1.1 este aprobată de OASIS11. Chiar dacă îmbunătățirile aduse de versiunea 3.1.1 par mici ele
reprezintă un pas uriaș înainte în maturizarea acestui standard. În afară de clarificarea unor
ambiguități din standardul 3.1.0, noua versiune permite utilizarea clienților anonimi, utilizarea
mesajelor MQTT de tip burst (care permit trimiterea unor blocuri de date cât mai repede posibil
fără a menține deschisă o conexiune TCP pe o perioadă lungă de timp) sau utilizarea unor
identificatori de client de o lungime mai mare.
În 2019 a fost lansată versiunea 5 a standardului. Această versiune implementează noi
caracteristici ce au drept obiectiv suportul aplicațiilor de tip IoT bazate pe sistemele de tip Cloud.
De asemenea, s-a pus accentul pe creșterea fiabilității schimbului de mesaje și pe tratarea
diferitelor tipuri de erori.

Figura 4.36. Arhitectura publicare/abonare (publish/susbcribe)

MQTT concepte fundamentale și caracteristici

Publish/Susbcribe

Modelul de mesagerie publicare/abonare (cunoscut sub numele de pub/sub sau

publish/susbcribe) este o alternativă la arhitectura tradițională client-server. În modelul client-
sever, clientul comunică direct cu sistemul final. Modelul pub/sub decuplează clientul care trimite
un mesaj (publisher) de clientul sau clienții care primesc mesajele (subscribers). MQTT
utilizează un server centralizat pentru a primi mesajele de la toate dispozitivele conectate care le
emit și le distribuie tuturor dispozitivelor IoT conectate care ascultă. Serverul respectiv se numește
router sau broker. Dispozitivul susbcriber (sub) trebuie să informez brokerul că dorește să
primească un anumit mesaj specific sau mai multe mesaje. În timp ce un dispozitiv emițător sau
publisher (pub) publică mesaje pentru ca broker-ul să le distribuie către celelalte dispozitive care
11
Diferențele dintre versiunea 3.1.0 și 3.1.1 a protocolului MQTT pot fi găsire aici:
https://github.com/mqtt/mqtt.org/wiki/Differences-between-3.1.0-and-3.1.1

41 | P a g i n ă
le așteaptă. Dispozitivele de tip publisher și cele de tip susbcriber nu se contactează niciodată în
mod direct. De fapt, nici măcar unul dintre acestea nu sunt conștienți de faptul că celălalt dispozitiv
există sau nu. Aceasta deoarece conexiunea dintre ele este gestionată de o a treia componentă
(brokerul). În cadrul standardului 3.1.1 broker-ul MQTT este cunoscut sub numele de server
MQTT. Sarcina broker-ului este de a filtra toate mesajele primite și de a le distribui corect
abonaților.
Unul dintre cele mai importante aspecte al modelului de mesagerie pub/sub este decuplarea
între subscriber și publisher. Această decuplare are mai multe dimensiuni:
1. Decuplarea spațială: subscriber-ul și publisher-ul nu trebuie să se cunoască (de
exemplu, nu există schimb de adrese IP și porturi).
2. Decuplarea timporară: publisher-ul și subscriber-ul nu trebuie să ruleze în același
timp. Chiar în situația în care nu sunt subscriberi conectați, aceasta nu influențează în
nici un mod capacitatea publisher-ul de a trimite mesaje, astfel mesajele vor rămâne
în coadă și nu se pierd până când clientul nu a primit acel mesaj.
3. Decuplarea sincronizării: deoarece MQTT este un protocol asincron nu este necesară
blocarea operațiunilor de pe publisher și subscriber în timpul publicării sau așteptării
primirii de noi mesaje.
Această decuplate între publisher și subscriber, atât în timp cât și in spatiu, determină ca
protocolul MQTT să functioneze perfect pentru aplicații în care se stabilesc conexiuni ocazionale
cu furnizori de servicii în care actiunea trebuie sa fie independentă de răspuns.

Scalabilitatea protocolului

Scalabilitatea este o provocare pentru orice sistem. Există protocoale care lucrează foarte bine
cu doar câteva sisteme conectate, dar când numărul acestora crește apar problemele de
performanță. Datorită numărului mare de dispozitive existente în cadrul aplicațiilor de tip IoT (ne
putem imagina milioane de dispozitive), protocolul MQTT și serverul care-l deservește trebuie
să fie unul scalabil. În acest mod, trebuie să putem putea adăuga mai multe zeci/sute/mii/etc. de
dispozitive fără a afecta performanțele sistemului global. Pentru aceasta operațiile pe broker
trebuie să poată fi foarte paralelizate și mesajele să poată fi procesate într-un mod bazat pe
evenimente. Un astfel de nivel ridicat de conexiuni poate fi atins cu noduri de broker grupate pentru
a distribui sarcina pe mai multe servere individuale folosind echilibratoare de sarcină.

Filtrarea mesajelor

În cadrul broker-ului, bazat pe protocolul MQTT, acesta utilizează o serie de filtre pentru
mesajele care sunt trimise fiecărui subscriber. Aceste filtre se bazează pe existența unor subiecte
sau topicuri care sunt organizate ierarhic. Aceste topicuri sunt o parte integrantă a fiecărui mesaj
și, din această perspectivă, fiecare mesaj aparține unui topic. În acest fel, un client de tip publisher
poate posta un mesaj pe un anumit subiect, iar toți clienți care se abonează la subiect (deci, toți
subscriber-ii) vor primi mesaje prin intermediul broker-ului. La modul cel mai general,
subiectele sunt șiruri de caractere cu o anumită structură ierarhică care permit filtrarea pe baza
unui număr limitat de expresii.
Desigur există multe implementări de servere MQTT care utilizează și alte metode de filtrare
a mesajelor, de exemplu cele pe baza conținutului mesajului. În această situație clienții care doresc

42 | P a g i n ă
să primească anumite mesaje trebuie să informez broker-ul că dorește să primească un anumit
mesaj specific care include un anumit conținut. Un dezavantaj semnificativ al acestei metode este
că conținutul mesajului trebuie cunoscut în prealabil și nu poate fi criptat.

Mesajele protocolului MQTT

Mesajele sunt niște pachete de date formate din mai multe secțiuni. Structura oricarui pachet
de date de tim mesaj MQTT are următorul format: un header fix, un header de dimensiune
variabila și datele care trebuie transmise. Headerul fix este prezent in toate mesajele și este format
dintr-un octet care reprezinta tipul pachetului/mesajului (Control field) și între 1-4 octeți care sunt
folosiți pentru a codifica lungimea pachetului de date, folosind primii 7 biți ai fiecărui octet ca date
pentru lungime și un bit suplimentar de continuitate pentru a determina că există mai mult de un
octet care alcătuiește lungimea mesajului. Sarcina utilă a mesajului este limitată la doar 256 MB.
În functie de tipul mesajului, headerul variabil și datele pot să lipsească. Prezentăm în continuare
succint câteva tipuri de mesaje:
 CONNECT – acesta este un mesaj trimis catre broker, care cere stabilirea unei conexiuni
de la client emițător la broker.
 CONNACK – mesaj de confirmare, trimis de catre broker, care indică stabilirea sau nu a
unei conexiunii.
 SUBSCRIBE – mesaj trimis catre broker, după ce conexiunea a fost stabilită, care indică
abonarea la un anumit ramură a unui topic sau la mai multe topicuri în același timp. Mesajul
va include atât topicul cât și o indicație despre nivelul de calitate în trimiterea mesajelor pe
topicul respectiv.
 SUBACK – confirmarea abonării, trimisa de broker
 UNSUBSCRIBE – mesaj trimis de un client, care indica dezabonarea de la un anumit
topic.
 PUBLISH - mesaj prin care un client publica date la broker. Contine înglobat și topicul
datelor care se publica. Aceste date sunt specifice fiecărei implementări de sistem IoT în
parte și pot avea semnificația de pornire sau oprire a unui actuator sau pot să conțină
valoarea unui anumit senzor specific.
 DISCONNECT – publisher-ul și subscriber-ul poate trimite un astfel de mesaj către
broker. Acest mesaj informează brokerul că nu va mai avea nevoie să trimită mesaje
pentru un subscriber și că nu va mai necesita primirea de date de la un publisher.

Calitatea comunicațiilor

O altă caracteristică importantantă a mesajelor de tip MQTT este calitatea serviciului (QoS),
de aceasta va depinde robustețea sistemului de comunicații în caz de defecțiuni sau perturbații. În
ceea ce privește calitatea legăturii, s-au implementat trei nivele diferite, care permit realizarea unui
echilibru între minimizarea cantității de date transmise și maximizarea fiabilitîții. Acestea sunt:
 QoS 0 – mesajul MQTT este trimis o singură dată fără a se aștepta confirmarea recepție,
neexistând nici o modalitate de a ști dacă abonații au primit mesajul. Această metodă este
uneori denumită „fire and forget” sau „at most once delivery”. În caz de eșec mesajul nu
va mai fi trimis și a doua oară – datorită lipsei acestei necesități de retrimitere a mesajelor,
acestea nu sunt stocate pentru livrare către clienții deconectați. Această abordare se

43 | P a g i n ă
 folosește atunci când mesajul respectiv nu este critic și când se dorește o minimzare a
cantității de date transmise.
 QoS 1 – mesajul MQTT va fi trimis de câte ori este necesar pentru a garanta livrarea către
client. Brokerul încearcă să transmită mesajul și apoi așteaptă un răspuns de confirmare
din partea abonatului. Dacă nu se primește o confirmare într-un interval de timp specificat,
mesajul este trimis din nou. Dezavantajul este că clientul ar putea primi același mesaj de
mai multe ori. Aceasta metodă este uneori denumită „at least once delivery”.
 QoS 2 – similar cu mesajele de mai sus, dar trimiterea este garantată să fie livrată o singură
dată. Această abordare este adesea folosită pentru sisteme critice în care este necesară o
fiabilitate mare. QoS 2 este uneori denumită „exactly once delivery”.
Pentru situațiile în care comunicațiile sunt fiabile, dar limitate ca bandă de transmisie, QoS 0
poate fi cea mai bună opțiune. Pentru cazul în care comunicațiile nu sunt de încredere, dar în care
conexiunile nu sunt la fel de limitate de resurse, atunci QoS 2 este cea mai bună opțiune. QoS 1
oferă un fel de cea mai bună soluție de compromis între QoS 0 și QoS 2, dar necesită ca aplicația
care primește datele să știe să gestioneze duplicatele.
Atât pentru QoS 1 cât și pentru QoS 2, mesajele sunt salvate sau puse în coadă pentru clienții
care nu sunt conectati și care au o sesiune persistentă stabilită. Aceste mesaje sunt trimise din nou
(în funcție de nivelul QoS corespunzător) odată ce clientul este din nou online.

Securitatea

Scopul inițial al protocolului MQTT a fost acela de a fi capabil să implementeze cea mai
“mică” și mai eficientă transmisie de date pe linii de comunicare scumpe. Ca atare, securitatea nu
a fost o preocupare primordială în timpul proiectării și implementării standardului MQTT.
MQTT permite utilizarea unui nume de utilizator și a unei parolele pentru un client să
stabilească o conexiune cu un broker. Din păcate, numele de utilizator și parolele sunt transmise
în text clar. În 1999, acest lucru a fost mai mult decât suficient, deoarece interceptarea unei
comunicări prin satelit pentru ceea ce era esențial o citire a unui senzor fără importanță ar fi fost
dificil de prohibitiv. Cu toate acestea, astăzi, interceptarea multor tipuri de comunicații de tip rețea
fără fir (WiFi) este banală, ceea ce face ca această autentificare să fie aproape inutilă.
În multe situații practice, utilizarea unui nume de utilizator și a unei parole este necesară nu ca
protecție împotriva unor actori de rea credință, ci ca o modalitate de a evita conexiunile
neintenționate, de a separa clienții pe grupurie etc.
Deoarece protocolul MQTT rulează pe baza TCP/IP, soluția evidentă pentru asigurarea
transmisiilor între clienți și brokeri este implementarea standardelor de securitate SSL/TLS. Din
păcate, acest lucru adaugă cheltuielile substanțiale (de exemplu în putere de calcul necesare
încriptării acestora) la comunicațiile anterioare care se realizau foarte ușor și natural.

Ultima dorință testamentară

În cazul în care apar probleme de comunicație, este posibil ca un publisher sau subscriber să
se deconecteze de la rețea fără nici un avertisment. Astfel aceștia pot înregistra un mesaj care să
fie trimis subscriber-ilor în cazul în care publisher se deconectează în mod neașteptat, aceasta
este o așa-numită ultimă dorinta și testament. Acest mesaj este memorat de broker și este trimis
abonaților în cazul în care publisher sau subscriber se deconectează în mod necorespunzător. De

44 | P a g i n ă
obicei, un astfel de mesaj include informații care să permită identificarea elementului deconectat,
astfel încât să poată fi luate măsurile adecvate.

Conexiunea dintre client și broker

Deoarece MQTT decuplează publisher-ul de subscriber, conexiunile clienților sunt

întotdeauna gestionate de un broker.
În cadrul acestui capitol când vorbim despre un client, ne referim întotdeauna la un client
MQTT. Atât publisherii de subscriberii sunt clienți MQTT. Etichetele de publisher și subscribe
se referă la faptul dacă clientul publică în prezent mesaje sau este abonat pentru a primi mesaje.
Aicea este de menționat că un client MQTT poate simultan publica mesaje și poate fi abonat la
aceleași mesaje sau la alte mesaje. Un client MQTT este orice dispozitiv (de la un microcontroler
până la un server complet) care rulează o bibliotecă MQTT și se conectează la un broker MQTT
printr-o rețea. De exemplu, clientul MQTT poate fi un dispozitiv foarte mic care se conectează
printr-o conexiune wireless. Clientul MQTT poate fi, de asemenea, un calculator personal care
rulează un client grafic MQTT în scopul vizualizării datelor. Practic, orice dispozitiv care vorbește
MQTT printr-o stivă TCP/IP poate fi numit client MQTT. Implementarea de către client a
protocolului MQTT este una foarte simplă, iar protocolul MQTT este foarte ușor de implementat
tehnic la nivelul clientului. Ușurința de implementare este unul dintre motivele pentru care MQTT
este ideal pentru dispozitivele mici. Bibliotecile client MQTT sunt disponibile pentru o mare
varietate de limbaje de programare. De exemplu, Arduino, C, C ++, C #, Go, iOS, Java, JavaScript
și .NET.
Omologul clientului MQTT este brokerul MQTT. Brokerul se află în centrul oricărui
protocol de publish/susbcribe. În funcție de implementare, un broker poate gestiona milioane de
clienți MQTT conectați simultan. Broker-ul este responsabil pentru primirea tuturor mesajelor,
filtrarea acestora, stabilirea clienților abonaț la fiecare mesaj și trimiterea mesajului către acești
clienți abonați. O altă responsabilitate a broker-ului este autentificarea și autorizarea clienților.
Conexiunile sunt făcute prin intermediul TCP/IP, iar serverul sau broker-ul va ține o evidență
a clienților conectați. În mod implicit, dispozitivele vor utiliza portul de comunicații numărul 1883.
Este posibil să întâlniți și portul 8883 dacă utilizați criptarea SSL/TLS pentru creșterea nivelului
de securitate.

Figura 4.37. Realizarea unei conexiuni MQTT

Pentru stabilirea unei conexiuni între un client și un broker, un mesak de tip CONNECT este
trimis de client către broker – acesta este un mesaj complex conținând o serie largă de informații.
Aceste informații includ ID-ul clientului, numele de utilizator, parola etc. Broker-ul sau serverul
MQTT răspunde cu un pachet CONNACK care va informa clientul că conexiunea a fost acceptată

45 | P a g i n ă
sau respinsă. Odată ce conexiunea este stabilită, broker-ul o menține deschisă până când clientul
trimite o comandă de deconectare sau conexiunea se întrerupe.
Deci, pentru a iniția o conexiune, clientul trimite un mesaj CONNECT broker-ului. Dacă
acest mesaj CONNECT este incorect compus (conform specificațiilor MQTT) sau trece prea mult
timp între deschiderea socket-ului asociat și trimiterea mesajului de conectare, broker-ul închide
conexiunea. Un client MQTT care respectă standardul 3.1.1 trimite un mesaj de conectare ce
trebuie să conțină și următoarele informații prezentate în Figura 4.37.

Figura 4.38. Elemente componente ale pachetului MQTT CONNECT

Semnificația acestor elemente ne este necesară în special în momentul în care vom iniția o
comunicare software de la un client către broker, vezi Figura 4.38. Astfel:
 clientId - identificatorul de client este utilizat în identificarea unică a fiecărui client
MQTT care se conectează la un broker MQTT. Prin acest identificator broker-ul
gestionează clientul și starea actuală a acestuia. Prin urmare, acest ID ar trebui să fie
unic pentru fiecare client și broker.
 cleanSession - semnalizează broker-ului dacă clientul dorește să stabilească sau nu o
sesiune persistentă. Într-o sesiune persistentă (cleanSession = false), brokerul
stochează, de exemplu, toate mesajele ratate pentru clientul care s-a abonat cu un nivel
de calitate (QoS) 1 sau 2. Dacă sesiunea nu este persistentă (cleanSession = true),
brokerul nu stochează nimic pentru client și curăță toate informațiile din orice sesiune
persistentă anterioară.
 username/password – clientul MQTT poate trimite un nume de utilizator și o parolă
pentru propria autentificare și autorizare. Cu toate acestea, dacă aceste informații nu
sunt criptate sau protejate în vreun fel – deci, parola este trimisă în plain text. Se
recomandă utilizarea de nume de utilizatori și parolă împreună cu un protocol de
transport încriptat.
 câmpurile de tip will - ultimul mesaj testamentar al clientului face parte din
caracteristica Last Will and Testament (LWT) a standardului MQTT. Acest mesaj
notifică alți clienți atunci când un client se deconectează sau a fost deconectat forțat
(de ex. prin pierderea tensiunii de alimentare sau întreruperea fizică a conexiunii). Când
un client se conectează la un broker, acesta poate oferi broker-ului un mesaj MQTT
și a un topic, prin intermediul mesajului CONNECT. Dacă clientul se deconectează
forțat, broker-ul trimite acest ultim mesaj LWT în numele clientului.

46 | P a g i n ă
  keepAlive - reprezintă un interval de timp în secunde pe care clientul îl specifică și îl
comunică broker-ului la stabilirea conexiunii. Acest interval definește cea mai lungă
perioadă de timp pe care broker-ul și clientul o pot accepta fără a trimite un mesaj.
Clientul se angajează să trimită mesaje regulate PING Request către broker. Brokerul
răspunde cu un răspuns PING. Această metodă permite ambelor părți să stabilească
dacă cealaltă este încă disponibilă.

Când un broker primește un mesaj CONNECT el este obligat să răspundă, conform

standardului MQTT, cu un mesaj CONNACK. Mesajul CONNACK conține două intrări de date
principale: flag-ulun bit care semnalizează existența unei sesiuni anterioare prezente și un cod
răspuns de conectare.

Figura 4.39. Elemente componente ale pachetului MQTT CONNACK

Bitul sessionPresent îi comunică clientului dacă broker-ul are deja o sesiune persistentă
disponibilă din interacțiunile anterioare cu acesta. Când un client se conectează cu cleanSession
setată la adevărat, sessionPresent este întotdeauna fals deoarece nu există o sesiune disponibilă.
Dacă un client se conectează cu cleanSession de valoare falsă, există două posibilități:
1. dacă informațiile despre sesiune sunt disponibile pentru clientId, iar brokerul a stocat
informații despre sesiune, sessionPresent este adevărat.
2. dacă brokerul nu are informații despre sesiune pentru ID-ul clientului, sessionPresent este
fals.
Acest flag a fost adăugat începând cu MQTT 3.1.1 pentru a ajuta clienții să stabilească dacă
trebuie să se aboneze la subiecte sau dacă subiectele sunt încă stocate într-o sesiune persistentă.
Codul de întoarcere (returnCode) îi spune clientului dacă încercarea de conectare a avut
succes sau nu.

Tebelul 4.1. Semnificația diferitelor valori ale lui returnCode

returnCode Semnificație:
0 Conecsiune aceptată
1 Conecsiune refuzată, versiunea protocolului este neacceptată
2 Conecsiune refuzată, identificatorul client nu este acceptat
3 Conecsiune refuzată, serverul nu este disponibil
4 Conecsiune refuzată, numele utilizatorului sau parola sunt incorecte
5 Conecsiune refuzată, nu este autorizare

47 | P a g i n ă