Sunteți pe pagina 1din 14

CURS 4 CS ITS

PROTOCOALE DE COMUNICAŢIE ÎN REŢELE ITS


2.1 Prezentare generala
Protocoalele sunt reguli si proceduri de comunicare (considerate, în unele cazuri, limbaje de transmisie a datelor).
Transmitere a datelor printr-o reţea (indiferent de tipul si anvergura acesteia) trebuie sa fie impărtită în etape distincte.
La fiecare etapă datele sunt prelucrate prin proceduri specifice, care nu se mai pot repeta intr-o alta etapă. De asemenea,
fiecare etapă are propriile reguli si proceduri (denumite protocoale).
Rolurile protocoalelor de transmisie sunt diverse, variind de la un protocol la altul, însă se pot încadra în categorii
tipice:
- fragmentarea blocurilor de datele în unităţi standard (pachete);
- completarea pachetelor cu informaţii de adresare;
- pregătirea datelor pentru a putea fi transmise prin reţea;
- criptarea / decriptarea datelor vehiculate prin reţea
- identificarea si eventual corecţia erorilor de transmisie.
Specificarea unui protocol reprezintă definirea sintaxei prin precizarea formatelor unităţilor de date (DU) şi a
semanticii, procedurile de comunicaţie între entităţi. Funcţiunile principale ale unui protocol sunt: gestiunea
(managementul) comunicaţiei şi operaţii asupra datelor (transferul propriu-zis, păstrarea (eventual) secventialitătii
datelor, proceduri pentru controlul erorilor, controlul de flux, resincronizare si/sau alte funcţii speciale. In cadrul unei
reţele se impune operarea cu mai multe protocoale pentru a asigura pregătirea, transferul, recepţionarea si procesarea
datelor. Acţiunile diferitelor protocoale trebuie sa fie coordonate, astfel încât să nu apară conflicte sau operaţii
incomplete. Problema coordonării protocoalelor si a eliminării suprapunerilor se rezolvă prin stratificarea protocoalelor,
în conformitate cu standarde general acceptate. O astfel de stivă (suită) de protocoale realizează o combinaţie de
protocoale care funcţionează unitar. Fiecare nivel specifică un protocol diferit, care se ocupă de o funcţie sau de un
subsistem al procesului de comunicaţie. Prin urmare, fiecare nivel are propriul sau set de reguli. In funcţie de setul de
reguli adoptat, protocoalele se împart in:
a) protocoale de aplicaţie - funcţionează la nivelurile superioare ale modelului OSI. Ele asigură interacţiunea
aplicaţiilor si posibilitatea schimbului de date. Cele mai cunoscute protocoale de aplicaţie sunt:
 APPC - (Advanced Program-to-Program Communication);
 FTAM - (File Transfer Acces and Management) - protocol OSI de acces la fişiere;
 X.400 - protocol CCITT pentru transmisii internaţionale de posta electronica;
 X.500 - protocol CCITT pentru servicii de directoare si fişiere intre diferite si sisteme;
 SMTP - (Simple Mail Transfer Protocol) - un protocol Internet transferul mesajelor e-mail
 FTP - (File Transfer Protocol) - protocol Internet pentru transferul de fişiere;
 SNMP - (Simple Network Management Protocol - protocol simplu de administrare a reţelei) - protocol Internet
pentru monitorizarea reţelelor si a componentelor acestora;
 Telnet - un protocol Internet pentru conectarea la calculatoare gazda aflate la distanta si prelucrarea locala a
datelor.
b) protocoale de transport - permit realizarea unor sesiuni de comunicaţie intre calculatoare si transferul în siguranţă
a datelor. Cele mai cunoscute protocoale sunt:
 TCP - (Transmission Control Protocol) - protocolul TCP/IP pentru transferul garantat al secvenţelor de date;
este un protocol orientat pe conexiuni si a fost proiectat pentru a asigura un flux sigur de octeţi de la un capăt la
celalalt al conexiunii intr-o inter-reţea nesigură;
 UDP - (User Data Protocol - protocol pentru informaţia utilizator) - protocol Internet de transport fără
conexiune;
 SPX - componenta a suitei de protocoale Novell IPX/SPX pentru secvenţe de date;
 NetBEUI [NetBIOS (Network Basic Input/Output System) Estended User Interface] - stabileşte sesiuni de
comunicaţie intre calculatoare (NetBIOS) si, asigura servicii de transport de date (NetBEUI).
c) protocoale de reţea - asigura servicii de conectare (link services). Aceste protocoale se ocupa cu informaţiile de
adresare si de routare, cu verificarea erorilor si cu cererile de retransmisie. Cele mai cunoscute sunt:
 IP - (Internet Protocol) - protocolul TCP/IP responsabil cu dirijarea (routarea) pachetelor;
 IPX - (Internetwork Packet eXchange) - protocolul Netware pentru retransmiterea si dirijarea pachetelor;
d) protocoale ale legăturii de date - asigura servicii de control al comunicaţiei de date. Exemple de astfel de
protocoale:
 HDLC - (High-Level Data Link Control - control de nivel înalt al legăturii de date) - este un protocol orientat
pe biţi si foloseşte inserarea de biţi pentru transparenta datelor;
 SLIP - (Serial Line IP - a fost proiectat pentru a conecta staţiile de lucru Sun în Internet;
 PPP - (Point-to-Point Protocol - protocol punct la punct) - protocol pentru liniile punct-la-punct
e) protocoalele pentru nivelul fizic sunt:
 802.3 - (Ethernet) - este o reţea magistrală care poate transmite date la 10Mbps. Datele sunt transmise prin fir
fiecărui calculator, insă numai cele indreptătite să le recepţioneze confirma primirea. Protocolul CSMA/CD
regularizează traficul prin reţea, permitand transmisia doar atunci când cablul este liber si nici un alt calculator nu
transmite;
 802.4 - (Transferul jetonului) - este o reţea inel care se bazează pe o schema de transfer al jetonului. Fiecare
calculator recepţionează toate datele, insă răspunde numai cel a cărui adresa este menţionată explicit. Jetonul
care, circula pe cablu determina calculatorul care poate emite;
 802.5 - (Token Ring) - este o reţea inel care poate transmite date la 4 sau la 16Mbps, chiar dacă în denumire
apare cuvântul inel, aceasta topologie are forma de stea, fiecare calculator fiind conectat la un concentrator (hub)
central. Inelul (închiderea buclei) se realizează în cadrul concentratorului. Jetonul care circula în inel determina
calculatorul care poate transmite date.

Modelul de referinţă OSI


Deoarece necesitatea apariţiei si implementării reţelelor de date s-a accentuat în anii 1975 - 1980, s-a trecut la o
standardizare a tehnologiei reţelelor si dezvoltarea acestui concept. Organizaţia Internaţională pentru Standardizare
(ISO) a creat un forum si un grup de lucru care au studiat si propus o serie de modele pentru diferite reţele pentru a o
alege pe cea care oferea cea mai bună interconectare. Astfel, în 1984 au creat un model structural de reţea care sa poată
ajuta companiile să dezvolte reţele capabile de a lucra împreună. Modelul teoretic a fost numit „Modelul de referinta
OSI” si a devenit disponibil imediat. Astfel, ISO a decis crearea unui model care utilizează layere (straturi) fiecare layer
ocupându-se cu alta acţiune, toate fiind insă în legătură unul cu altul pentru ca este imposibilă realizarea comunicării fără
parcurgerea tuturor paşilor necesari. Layerele OSI prezintă o serie de avantaje, fiind totodată uşor de implementat si de
invătat. Aceste layere constituie baza unei reţele de date. Modelul de referinţa OSI permite de asemenea stabilirea de
funcţii la fiecare nivel. In modelul OSI exista şapte layere diferite, fiecare având o funcţie specifică. Acest model
simplifica evoluţia, deoarece orice schimbare a unui layer nu le afectează pe celelalte. De asemenea, modelul OSI
standardizează reţeaua si permite interoperabilitatea si modularizarea componentelor fabricate de diverşi producători.

Figura 1.Standardul OSI


1. Nivelul aplicaţie - serveşte drept fereastră prin care aplicaţiile au acces la serviciile de reţea: acest nivel reprezintă
serviciile oferite direct aplicaţiilor de utilizator, cum ar fi software pentru transferul de fişiere, pentru accesul la bazele
de date sau pentru posta electronică. Nivelele inferioare sprijină operaţiile efectuate la nivelul aplicaţie, care răspunde de
accesul general în reţea, controlul fluxului si tratarea erorilor.
2. Nivelul prezentare - determina formatul folosit pentru schimbul de date intre calculatoarele din reţea. In cazul
calculatorului emiţător, acest nivel converteşte datele din formatul transmis de nivelul aplicaţie, intr-un format
intermediar, universal recunoscut. In calculatorul receptor, acest nivel converteşte formatul intermediar intr-un format
care poate fi folosit de nivelul aplicaţie al calculatorului respectiv. Nivelul prezentare gestionează conversia de
protocoale, conversia si criptarea datelor, modificarea sau conversia setului de caractere, precum si interpretarea
comenzilor grafice. De asemenea este realizata comprimarea datelor, pentru a reduce numărul de biţi care trebuie
transmişi.
3. Nivelul sesiune - permite ca două aplicaţii aflate pe calculatoare diferite sa stabilească, să folosească si să încheie o
conexiune numită sesiune. Acest nivel asigură recunoaşterea numelor si alte funcţii, cum ar fi cea de securitate, necesare
pentru ca doua aplicaţii să comunice prin reţea. Nivelul sesiune emite sincronizarea intre procesele de utilizator, prin
plasarea unor caractere de validare în fluxul de date. Astfel, dacă în reţea apare o defecţiune trebuie retransmise doar
datele aflate după ultimul caracter de validare. De asemenea acest nivel implementează controlul dialogului intre
procesele care comunica.
4. Nivelul transport - este un nivel de conexiune suplimentar, aflat sub nivelul sesiune. El asigură transportul
pachetelor de date la destinaţie, fără erori, în succesiune fără pierderi si fără duplicate. Acest nivel reîmpachetează
mesajele, fragmentându-le pe cele de mari dimensiuni în mai multe pachete, sau concentrându-le pe cele mici intr-un
singur pachet. Astfel pachetele sunt transmise mai eficient în reţea. La capătul receptor, nivelul transport despachetează
mesajele, reasamblându-le în forma originală, si transmite de obicei un semnal de confirmare a primirii.
5. Nivelul reţea - este responsabil pentru adresarea mesajelor si conversia adreselor logice si a numelor în adrese fizice.
Acest nivel determina de asemenea ruta (calea de acces) de la destinaţie la sursă. El stabileşte calea pe care trebuie sa o
urmeze datele în funcţie de condiţiile reţelei, prioritatea serviciilor si alţi factori. In plus, gestionează problemele de
trafic în reţea, cum ar fi comutarea intre pachete, routarea si controlul aglomerării datelor. Daca placa de reţea a
routerului nu poate transmite un bloc de date de mărimea celui primit de la calculatorul sursa, nivelul reţea al routerului
fragmentează blocul de date în unităţi mai mici. La destinaţie, nivelul reţea reasamblează datele.
6. Nivelul legătura de date - transmite cadrele de date de la nivelul reţea către nivelul fizic. La capătul receptor, el
împachetează biţii sosiţi de la nivelul fizic în cadre de date. Un cadru de date este o structura logică, organizată, în care
pot fi plasate date. In general, atunci când nivelul Legătura de date transmite un cadru, el aşteaptă o confirmare de la
destinatar. Nivelul Legătura de date destinatar detectează eventualele probleme apărute la cadrul de date pe parcursul
transmisiei. Cadrele de date care nu au fost confirmate sau cele care au fost alterate în timpul transmisiei sunt
retransmise.
7. Nivelul fizic - transmite un sir de biţi, nestructurat printr-un mediu fizic (cablu, fibra optica, radio). Nivelul fizic se
refera la interfaţa efectiva intre sistemul de calcul si mediul de transmisie a datelor. De asemenea, nivelul fizic transporta
semnalele care reprezintă datele generate de nivelurile superioare. Acest nivel defineşte modul în care cablul este
conectat la placa de reţea. De asemenea, el stabileşte tehnica de transmisie ce va fi folosită pentru a transmite datele prin
cablul de reţea.
Procedeul de „încapsulare a datelor” asigura gruparea acestora în pachete exacte, acestea fiind transmise în reţea.
Încapsularea datelor respecta un algoritm specific, exact si bine definit:

Figura 2. Transferul datelor conform structurii OSI


1. crearea datelor - este realizata la nivelul layerelor logice (7-6-5-4), ceea ce înseamnă ca datele sunt convertite
intr-un format care poate fi transmis prin reţea.
2. împachetarea datelor – se face prin segmentarea datelor layerul de transport si se asigura ca gazdele de la
ambele capete ale mediului de transport a datelor pot comunica intr-un mod compatibil.
3. adăugarea adresei reţelei la headere - implică pregătirea datelor intr-un pachet care conţine headerul cu sursa
si adresele logice ale destinaţiei. Aceste headere ajută dispozitivele logice din reţea pentru a transporta pachetul pe o
anumită rută la destinaţia potrivită.
4. adăugarea adresei locale la header - fiecare dispozitiv din reţea trebuie sa pună pachetul de date intr-un cadru
de transmisie. Cadrul permite conectarea la următorul dispozitiv din reţea direct conectat. Fiecare dispozitiv de reţea
conectat pe ruta aleasa necesita ca unitate de transmisie "cadrul (frame on)" pentru a se conecta la următorul dispozitiv.
Algoritmul se numeşte „Token – Ring” (sau algoritmul „jetonului”), acesta asigurând transmisia datelor de către un
dispozitiv (in cadrul sau), dispozitiv care cedează dreptul de transmisie următorului dispozitiv, conform cadrului
corespunzător.
5. convertirea în biţi pentru transmisie - cadrul trebuie sa fie convertit intr-un model de aranjare sub forma de biţi
pentru transmisia prin mediu. Conform modelului OSI, nu contează care este acest mediu, la nivel logic toate mediile
comportându-se la fel. Headerele si trailerele sunt adăugate pe măsură ce datele înaintează prin layerele modelului OSI.
In cadrul unei reţele datele sunt transmise de la o gazdă la alta si fiecare layer OSI comunica cu layerul corespondent
(corespondentul sau) de la destinaţie. Forma de comunicare în cazul în care fiecare layer realizează un schimb de date
(numit PDU - Protocol Data Units) cu layerul aflat la destinaţie poarta numele de comunicare corespondent – la –
corespondent (peer to peer). In cadrul unei reţele fiecare layer depinde de layerul inferior. Layerul aflat cel mai jos
încapsulează PDU-ul de la layerul superior în câmpul sau de date, ii adaugă headerele si trailerele proprii, iar datele trec
la layerul următor. De exemplu layerul 4 adăuga mai multe informaţii la datele provenite de la layerul 5 si le grupează
intr-un segment. Layerul 3 (reţea) trebuie sa transmită datele prin reţea. Le ataşează un header creând un PDU al
layerului 3. In acest moment headerul conţine informaţii logice, dar Layerul 2 încapsulează intr-un cadru informaţia
despre adresa fizică necesară pentru ca transferul sa fie realizat. Layerul de "legătură a datelor" asigura "serviciul"
layerului de reţea prin încapsularea informaţiilor acestuia din urma intr-un cadru. Layerul fizic asigura de asemenea
"serviciul" layerul de "legătura a datelor". Layerul fizic codează cadrul intr-un model de 1 si 0 (biţi) pentru transmisia
prin mediu la nivel fizic.

2.2 Protocolul TCP / IP – retele publice si private de date


Protocolul TCP/IP (Transmission Control Protocol / Internet Protocol) este folosit în acest moment si adoptat ca
standard pentru transmisiile de date din cea mai mare reţea existenta - Internetul. Modelul de referinţa TCP/IP a fost
creat de Ministerul Apărării din SUA pentru a deservi o reţea de mare extindere (mondiala), capabilă să funcţioneze în
orice condiţii, chiar si intr-un război atomic. S-a considerat extrem de important să fie creată o reţea capabilă să opereze
cu o infrastructură distrusă în proporţie de peste 90%, fără sa aibă vreo importanta starea fizică a unor anumite segmente
ale reţelei, fiind disponibile căi redundante pe care protocolul are capacitatea să le identifice si să le folosească. Pe de
alta parte, s-a considerat încă de la început ca o disponibilitate de 100% este imposibil de asigurat în orice condiţii, insă
99%, este un coeficient bun, mai ales în condiţiile în care capabilitatea de transmisie a reţelei depăseste cu mult
necesarul de date. Astfel, US DoD (Departament of Defence) au obţinut un protocol si o reţea inteligentă.
Structura fizică a unui pachet TCP/IP implică o transmisie mai lungă decât la celelalte protocoale de reţea, pachetul fizic
TCP implicând un volum mai mare de date astfel încât informaţiile conţinute să asigure transmisia si retransmisia de la
origine pană la destinaţie indiferent de numărul de noduri de reţea parcurse.
Deşi TCP/IP este un protocol complex si implicit greu de implementat fizic, fiind totodată relativ lent (fată de alte
protocoale) datorita complexităţii lui, acesta asigură cea mai bună corecţie a erorilor de transmisie.

2.3 Protocoale Bluetooth


Ca si modelul OSI, specificaţiile Bluetooth fac uz de soluţia ierarhizării pe nivele a arhitecturii de protocoale. Şi
tot asemeni OSI, scopul final al specificaţiilor Bluetooth este de a permite interoperabilitatea aplicaţiilor realizate
conform acestor specificaţii. Acest lucru se realizează atunci când aplicaţiile din dispozitivele conectate rulează utilizând
protocoale identice. Stive diferite de protocoale sunt utilizate pentru aplicaţii diferite. Independent de aplicaţie, stiva de
protocoale utilizate foloseşte un nivel Bluetooth fizic şi legătură de date comună.
Spre deosebire de transmisia TCP/IP, o aplicaţie Bluetooth nu utilizează obligatoriu toate protocoalele din stivă ci
urmează una dintre căile laterale conform necesităţilor serviciului corespunzător aplicaţiei.
Stiva completă de protocoale conţine atât protocoale specifice tehnologiei wireless Bluetooth (cum ar fi LMP şi L2CAP
– protocoale care vor fi descrise în cele ce urmează), şi acele protocoale, precum OBEX (Object Exchange Protocol),
UDP (User Datagram Protocol) şi WAP (Wireless Application Protocol), care pot fi folosite pentru comunicaţii cu alte
platforme. În proiectarea protocoalelor Bluetooth s-a preferat reutilizarea unor protocoale deja existente pentru scopuri
diferite, la nivele mai înalte.
Deschiderea specificaţiilor Bluetooth permite multor aplicaţii deja dezvoltate de producători să profite de sistemele hard
şi soft compatibile cu aceste specificaţii. De asemenea, producătorii pot implementa protocoale pentru aplicaţiile lor
proprii (proprietare) sau de uz comun, având la bază specificaţiile referitoare la protocoalele tehnologiei wireless
Bluetooth.
Stiva de protocoale utilizate de Bluetooth este structurată pe patru nivele (ca si la modelul TCP/IP), după cum se prezintă
în tabelul de mai jos.

Figura 3. Organizarea nivelelor protocoalelor folosite in standardul Bluetooth

Specificaţiile Bluetooth definesc de asemenea o interfaţă HCI (Host Controller Interface), care oferă interfaţare cu
controller-ul BB şi cu LM şi accesează starea hardware-ului şi a registrelor de control. HCI este poziţionată sub L2CAP,
dar ea poate la fel de bine exista şi deasupra acestuia. Împreună, nivelul de Înlocuire a Cablurilor, nivelul de Control
Telefonic şi nivelul Protocoale Adoptate formează protocoalele orientate aplicaţie, care permit aplicaţiilor să ruleze peste
protocoalele nucleului Bluetooth. Ţinând cont că specificaţiile Bluetooth sun nişte specificaţii deschise, protocoale
adiţionale precum HTTP (HyperText Transfer Protocol) şi FTP (File Transfer Protocol) pot fi adăugate într-o manieră
interoperabilă deasupra protocoalelor de transport Bluetooth sau deasupra protocoalelor orientate aplicaţie. Modelul de
referinţă Bluetooth este asemănător cu OSI pentru stiva de protocoale de comunicaţii. Deşi relaţia nu este exactă, s-a
încercat realizarea unei corespondenţe între modelul OSI şi stiva de protocoale Bluetooth:
1. Nivelul Fizic este responsabil de interfaţa electrică cu mediul de comunicaţie, incluzând modulaţia şi codarea
de canal. Este inclusă deci partea de operaţii radio şi din banda de bază.
2. Nivelul Legătură de Date este responsabil pentru transmisia, încadrarea şi controlul erorilor unei legături
anume şi, ca atare, se suprapune peste sarcinile Link Controller-ului şi părţii de control din banda de bază (baseband -
BB), incluzând verificarea şi corecţia erorilor.
3. Nivelul Reţea este responsabil pentru transferurile de date de-a lungul reţelei, independent de medii şi topologii
specifice ale reţelei. Acesta acoperă capătul superior al Link Controller-ului, setând şi menţinând multiple legături şi
realizează de asemenea şi o mare parte din funcţionalităţile Link Manager-ului. Stratul Transport este responsabil cu
siguranţa şi multiplexarea transferurilor de date de-a lungul reţelei, la nivelul oferit de aplicaţie, şi astfel cuprinde capătul
superior al LM şi acoperă HCI, care oferă de fapt mecanismul actual al transportului de date.
4. Nivelul Sesiune oferă servicii de management şi control al fluxului de date, care sunt acoperite de L2CAP şi
capătul inferior al RFCOMM/SDP.
5. Nivelul Prezentare oferă o reprezentare comună pentru datele stratului Aplicaţie adăugând unele unităţi de
date structurii de serviciu, care este funcţia principală a RFCOMM/SDP.
6. Nivelul Aplicaţie este responsabil pentru mânuirea comunicaţiilor între aplicaţiile gazdă.
Specificaţiile Bluetooth conţin două protocoale, incluzând aici Telephony Control Protocol, care manipulează
semnalele de control a legăturilor wireless, emulând semnalizările ce sunt în mod normal asociate legăturilor cablate.
TCS BIN (Telphony Control Specification Binary) este un protocol care defineşte semnalizările de control a unei
conexiuni (CCS - call control signaling) pentru stabilirea legăturilor vocale şi de date între dispozitive Bluetooth. TCS
BIN este bazat pe Recomandarea Q.931 a Uniunii Internaţionale de Telecomunicaţii (ITU-T), o agenţie a Naţiunilor
Unite. Q.931 conţine specificaţii pentru controlul conexiunilor în ISDN. În plus, Bluetooth SIG a elaborat un set de
comenzi AT care definesc modalitatea în care un telefon mobil sau un modem pot fi controlate în diverse modele de
utilizare. Comenzile AT au la bază Recomandarea ITU-T V.250 şi ETS 300 916 (GSM 07.07). Pentru serviciile de fax,
comenzile AT sunt specificate în conformitate cu alte reglementări (ITU T.31, ITU T.32). Specificaţiile Bluetooth fac uz
de câteva protocoale deja existente care sunt reutilizate pentru diferite scopuri la nivelul unor straturi superioare. Acest
lucru permite aplicaţiilor mai vechi să lucreze cu Bluetooth, contribuind astfel la sporirea interoperabilităţii între
dispozitive.

PPP
Specificaţiile Bluetooth utilizează protocolul PPP (Point-to-Point Protocol), dezvoltat de IETF (Internet
Engineering Task Force). Acest standard defineşte modul în care datagramele IP sunt transmise printr-o legătură serială
punct-la-punct. Datagramele sunt pur şi simplu unităţi (pachete) de date transportate de-a lungul legăturii. PPP are trei
componente de bază, menţionate în continuare.
Protocolul PPP oferă o metodă de încapsulare a datagramelor din legăturile seriale atât sincrone orientate pe biţi,
cât şi asincrone, cu opt biţi de date şi fără biţi de paritate. Aceste legături pot fi atât dedicate sau cu comutare de circuite.
Pentru încapsulare, PPP foloseşte ca bază protocolul HDLC (High-level Data Link Control).
Protocol de Control a Legăturii (LCP – Link Control Protocol)
PPP oferă acest tip de protocol pentru a-şi asigura portabilitatea într-o gamă diversă de medii. LCP este utilizat pentru
stabilirea automată a opţiunilor formatelor de încapsulare, pentru a mânui limitele dimensiunilor pachetelor, pentru a
autentifica capătul pereche al conexiunii, pentru a determina când o legătură funcţionează corect şi când s-a întrerupt sau
chiar pentru a întrerupe conexiunea.

Protocoale de control a reţelei (NCPS – Network Control Protocols)


Legăturile punct-la-punct ridică multe probleme legate de protocoalele de reţea, cum este asocierea şi
managementul adreselor IP. Acest tip de probleme sunt rezolvate de o familie de protocoale – NCPS – care răspund
necesităţilor protocoalelor corespunzătoare lor din la nivelul stratului reţea.
În reţelele wireless Bluetooth, PPP lucrează peste RFCOMM pentru a implementa legături seriale punct-la-punct, de
exemplu între dispozitive mobile şi un punct de acces LAN. Utilizarea PPP înseamnă transportul pachetelor IP la/de la
nivelul PPP şi plasarea lor în LAN.

TCP
Acesta este un protocol orientat conexiune, care face parte dintr-o ierarhie de protocoale ce suportă aplicaţii
multi-reţea. Printre altele, TCP defineşte procedurile de rupere a fluxului de date în pachete, reasamblarea lor la recepţie
şi solicitarea retransmisiei pachetelor afectate de erori. Cum pachetele în Internet pot sosi pe căi diferite, ele se
memorează temporar până la primirea tuturor pachetelor corecte şi apoi se reface din acestea fluxul de date de la
transmisie.
UDP
În timp ce TCP oferă garanţia livrării pachetelor, UDP pur şi simplu plasează mesaje individuale către IP pentru
transmisia pe aşa numitul principiu al efortului minim. Aceasta înseamnă că nu se dă garanţia livrării pachetelor, dar
totuşi există tipuri de comunicaţii pentru care această modalitate e foarte potrivită; aşa sunt accesările rapide ale unor
baze de date (lookup table), cum este DNS (Domain Name System) – o colecţie de baze de date distribuite ce conţin
echivalenţele între numele de domenii în format text şi adresele IP corespunzătoare.
IP
IP transportă datagrame între diferite reţele prin intermediul router-elor, care procesează pachetele de la un
sistem autonom la altul. Fiecare dispozitiv dintr-un sistem autonom are o adresă unică IP. Internet Protocolul adaugă
propriul său antet şi sumă de control pentru a se asigura că datele sunt corect rutate. Router-ele conţin liste cu noduri de
comunicaţie şi cu căile spre aceste noduri. Aceste liste sunt actualizate cu ajutorul unor mesaje specifice transmise în
reţea. Dacă un pachet de date este prea mare pentru a fi acceptat de destinaţie, acesta este segmentat cu ajutorul
protocolului superior TCP. Adoptarea acestor standarde de către specificaţiile Bluetooth permite comunicaţia cu orice
alt dispozitiv conectat la Internet. TCP, IP, PPP sunt toate folosite în acest scop, precum şi pentru OBEX. UDP, IP şi
PPP sunt de asemenea disponibile ca mijloc de transport pentru WAP.

WAP
WAP reprezintă o colecţie de specificaţii pentru trimiterea şi citirea de informaţii şi mesaje Internet pe dispozitive
wireless, precum telefoanele celulare. Informaţiile vizate în principal de WAP sunt ştirile, anunţurile, agendele, ş.a.
Pentru a realiza acest lucru, site-urile Web pentru WAP sunt construite pe baza unei versiuni HTML, şi anume WML
(Wireless Markup Language). De asemenea, WAP a optimizat principiile HTTP şi TCP pentru întârzieri de valori mai
ridicate ale transmisiilor şi pentru benzi de transmisie mici şi medii, prin transmisii binare cu compresii mai bune ale
datelor.
Aplicaţiile WAP sunt construite în interiorul mediului WAE (WAP Applications Environment), care urmăreşte
modelul Web, cu deosebirea că îi adaugă acestuia funcţia Gateway. Altfel spus, la WAE în loc de modelul client-server,
apare modelul client-gateway-server.

vCard şi vCalendar
Acestea sunt specificaţii deschise dezvoltate iniţial de un consorţiu (Versit Consortium) format din IBM, Siemens
şi Lucent Technologies, controlate actualmente de IMC (Internet Mail Consotium) şi fiind dezvoltate în continuare de
IETF.
vCalendar defineşte un format independent de platformă şi modul de transport pentru organizarea agendelor şi
planificării activităţilor personale. Acest format conţine tot felul de componente avansate, precum semnale de alarmare
audio, clasificări ale evenimentelor etc. Acest format este comun, însă interfaţa cu utilizatorul putând diferi de la o
implementare la alta.
vCard este specificaţia pentru cărţi de vizită. Acestea conţin informaţii importante referitoare tot felul de date
personale, dar pot conţine şi date multimedia, precum poze, logo-uri sau clipuri audio.
2.4 Protocolul „Contact ID” – retele radio de semnalizare
Protocolul Contact ID a fost lansat în anii 90 de către firma Ademco, fiind rezultatul unei cercetări solicitate de
Honeywell Sollutinos Group pentru realizarea unui protocol de comunicaţie care să asigure transmisia de semnalizare
sigura pe linii telefonice analogice, fără ca acestea să implice imbunătătiri.

Figura 4. Schema tipica a conexiunii Contact ID

Protocolul de date asigura transmisia următorilor parametrii:


o numele clientului
o linia de alarma care a generat evenimetul
o comanda de alarma
o denumirea liniei de alarma asa cum a fost declarata la client
Transmisia efectiva prin linia telefonica se face în format audio, folosind modularea DTMF (Dual Tone Multi
Frequency) standard cu un limbaj hexazecimal (16 caractere standard). La nivel fizic, standardul DTMF implica a două
frecvente mixate pentru un caracter.
Astfel, folosind un spectru de 8 frecvente în banda audio, dispuse intr-o matrice de 4 x 4 poziţii se asigura
transmisia unul limbaj cu 16 caractere.

1209 Hz 1336 Hz 1477 Hz 1633 Hz


697 Hz „1” „2” „3” „C”
770 Hz „4” „5” „6” „D”
852 Hz „7” „8” „9” „E”
941 Hz „A” „0” „B” „F”
Matricea de codificare DTMF

DTMF (Dual Tone Multifrequency) reprezintă un sistem de semnalizare care înlocuieşte semnalizarea clasică,cu
pulsuri,în reţeaua telefonică. De asemenea sistemul DTMF este utilizat şi în alte aplicaţii : sisteme bancare prin
telefon,poştă electronică pe linie telefonică,control la distanţă prin telefon.
Un semnal multifrecvenţă (DTMF) reprezintă o sumă de două sinusoide convenabil alese; există mai multe standarde
DTMF care diferă prin numărul de frecvenţe alese şi prin valoarea acestora. Cel mai utilizat standard este standardul
CCITT care recomandă două grupuri de frecvenţe : un grup de frecvenţe joase (697Hz,770 Hz, 852 Hz , 941 Hz) şi un
grup de frecvenţe înalte (1209 Hz , 1336 Hz, 1477 Hz, 1633 Hz).
Se remarcă faptul ca frecventele sunt alese astfel încât nici o armonică nu se suprapune peste un canal util, astfel
încât demodularea sa se face uşor si fără masuri de filtrare deosebite. In general demodularea se face cu două etaje PLL
paralele, refacerea digitală realizându-se cu o matrice (format paralel) sau structura de registrii (format serial). Astfel, în
prezent demodularea DTMF se face cu un circuit integrat specializat. Singura restricţie, apărută atât la emisie cat si la
recepţie este generarea asigurarea stabilităţii oscilatorului local, stabilitate care se obţine, în general, cu un oscilator cu
cristal (cuarţ sau ceramic), eventual termocompensat.
Criptarea datelor transmise se face în cod RC4 standard, acesta asigurând verificarea corectitudinii mesajelor prin
confirmarea pe canalul duplex.
In prezent, formatul de semnalizare Contact ID a fost adoptat de aproape toţi producătorii de sisteme si
echipamente de semnalizare si alarmare care folosesc transmisia pe linii telefonice sau compatibile cu acestea.

2.5 Protocolul RC5


Deşi realizat în 1985 (si apoi extins si optimizat 1990) protocolul de transmisie RC5 s-a remarcat printr-o foarte
bună stabilitate funcţională. Protocolul RC5 este dedicat transmisiilor de telecomandă, conceput sa opereze în medii de
transmisie variate (cablu, radio, ultrasonic, optic) astfel ca, la nivel fizic, transmisia se realizează prin intermediul unei
interfeţe de adaptare (in general standardizată în funcţie de tipul aplicaţiei în care operează). Astfel, protocolul RC5 este
serial, asincron si nu foloseşte criptare.
Încă de la etapa de concepţie, specificaţia a impus implementarea integrata a protocolului, beneficiarul (firma Philips)
impunând îmbarcarea acestuia intr-un singur circuit integrat.
Structura unui mesaj transmis se refera la caracterele transmise, un mesaj fiind reprezentat practic de un cuvânt (singular
sau multiplu). Un cuvânt transmis respecta reprezentarea predefinită:

Sicro (3 biti) Identificare (3 biti) Data (5 biti) End (1 bit)

Figura 5. Structura unui mesaj RC5

Deoarece protocolul RC5 a fost conceput pentru transmisii unidirective (de la client către staţia bază, fără posibilităţi de
confirmare) s-a optat pentru transmisii repetate ale mesajului. Astfel, pentru asigurarea fiabilităţii si fidelităţii datelor
transmise, s-a adoptat transmisia multiplă, astfel ca, un cuvânt poate fi transmis de oricâte ori este considerat necesar
(transmisie succesivă).

Sincro 1 - 1 - 1 Sincro 1 - 0 - 1 Sincro 1 - 1 - 1

Cuvant 1 / transmisia 1 Cuvant 1 / transmisia 2 Cuvant 1 / transmisia 3

Figura 6. Semnalul de sincronizare diferenţiat la transmisia succesivă multiplă

O particularitate a protocolului este insă repetarea la nivel de cuvânt transmis (fată de alte protocoale care retransmit un
set de date, numit pachet sau chiar întreg mesajul) astfel încât corecţia se face pe parcursul recepţionării mesajului, iar la
finalul acestuia mesajul este deja corectat. Deşi durata de transmisie este aceeaşi indiferent de tipul repetiţiei (la nivel de
cuvânt, pachet sau mesaj) această metodă este foarte uşor de implementat fizic (electronic, chiar si intr-un singur chip)
deoarece implică registrii de memorie de capacitate redusă.
Pentru a lăsa la latitudinea dezvoltatorilor numărul de retransmiteri repetate ale aceluiaşi cuvânt din mesaj, standardul nu
defineşte numărul de retransmisii, acesta fiind nelimitat. Pe de alta parte, o problemă apăruta în dezvoltarea protocolului
RC5 a fost diferenţierea cuvintelor succesive identice la sistemele de telecomandă optică (folosirea spectrului infraroşu)
astfel încât receptorul să diferenţieze transmiterea multiplă a unui cuvânt (pentru asigurarea redundantei) de două sau
mai multe cuvinte succesive identice. Astfel, s-a stabilit ca standard utilizarea unui preambul variabil, acesta
schimbându-se la fiecare cuvânt transmis.
Spre deosebire de alte sisteme, RC5 a fost definit ca protocol îmbarcat, fiind conceput sa fie implementat în
structuri integrate. In acest fel, se defineşte o tabelă de criptare fizică si o serie de intrări, corespunzătoare liniilor din
tabelă. Derivat din protocolul RC4 optimizat, RC5 a este foarte uşor implementabil în structuri hardware. Astfel, a fost
rapid adoptat ca standard de telecomandă unidirecţional atât pentru dispozitive de uz casnic (telecomenzi casnice) cat si
pentru sisteme industriale (bariere optice multiflux) si de transporturi (transmisie de telecomanda în lungul liniei, la
numărători de osii sau circuite de comanda la bariere).

Figura 7. Reprezentarea tabelei de criptare, conform implementării in memorie

Derivat din protocolul RC4 optimizat, RC5 a este foarte uşor implementabil în structuri hardware. Astfel, a fost
rapid adoptat ca standard de telecomandă unidirecţional atât pentru dispozitive de uz casnic (telecomenzi casnice) cat si
pentru sisteme industriale (bariere optice multiflux) si de transporturi (transmisie de telecomanda în lungul liniei, la
numărători de osii sau circuite de comanda la bariere).

2.6 Protocolul SR-10


Sistemele de balizaj naval sunt în general echipate cu senzori (meteorologici si hidrologici), datele fiind
transmise către nave sau centre de dispecerizare. Transmisia datelor se face prin canale radio (private sau GSM),
protocolul de transmisie cel mai utilizat fiind SR-10. Protocolul SR-10 este cvasi-acceptat în majoritatea sistemelor de
navigaţie.
Parametrii sunt preluaţi de la senzori în formate analogice sau digitale, în conformitate cu standardele producătorilor.
Standardul asigura citirea permanenta a datelor de pe o serie de canale de comunicaţie, canale cablate la bordul balizei.
Aceste canale (de obicei 16) asigură citirea parametrilor de la senzorii din sistem.
Standardul de comunicaţie SR-10 este de tip serial sincron si foloseşte reprezentarea binară în cuvinte reprezentate pe 10
biţi.

0 1 2 3 4 5 6 7 8 9

MSB LSB

mesaj
rezervat

Figura 8. Rezervarea bitului de alarma in cadrul mesajului


La nivel fizic, sistemul foloseşte un ceas intern transmis printr-un pin de sincronizare. Semnalele logice sunt transmise
folosind nivele electrice descrise conform standardului NMEA II (cu masa pozitiva), astfel încât sistemul sa fie
compatibil cu majoritatea senzorilor cu specific naval.

Semnal sincronizare

timp
- 5V

CH x

timp
- 5V

0 1 2 3 4 5 6 7 8 9

ALARMA
Data

Figura 9. Structura transmisiei SR-10

Datele provenite pe canalele de date de la senzori sunt procesate de către calculatorul de la bordul balizei. Acesta
formează, pe baza acestora, rapoarte de stare pe care le transmite, automat sau telecomandat (la cerere) către centrul de
comandă si dispecerizare.
In unele cazuri, rapoartele pot fi solicitate si de alte entităţi decât dispeceratul-bază, baliza verificând nivelul
cererii si, dacă protocolul o impune, răspunde cu un mesaj de raportare a parametrilor solicitaţi (de exemplu, anumite
categorii de nave, pot solicita rapoarte balizelor fără acordul dispeceratului).
Protocolul de transmisie radio nu este standardizat specific, acesta asigurând transmisia integrală a datelor
provenite pe canalele de date de la senzori. Astfel, la baliza se conectează o staţie radio de consum redus dotată cu un
modem FSK, aceasta transmiţând pachetele de date.
In varianta GSM, datele sunt împachetate de către calculatorul de la bordul balizei si transmise modemului GSM
/ GPRS, acesta formând un mesaj (SMS sau GPRS) care este transmis către dispecerat, datele fiind insă transmise exact
în forma în care date provin de la senzori.
Structura mesajului radio / GPRS (Figura 10.) :

Sincro ID baliza Data CH 1 Data CH 2 Data CH 16 Status OUT

Figura 10. Reprezentarea mesajului transmis conform protocolului SR-10

O atenţie aparte se acorda senzorilor de poziţie, cantitatea de informaţie de localizare GPS fiind mai mare decât
posibilităţile de transmisie pe unul sau chiar 2 canale de 10 biţi fiecare.

2.7 Protocolul ATCRSB - sistemul TCAS


Traffic Collision Avoidance System - sistem pentru evitarea coliziunilor în trafic) reprezintă o soluţie relativ
recentă (introdusă ca standard obligatoriu abia în 1999) care permite determinarea avioanelor a căror traiectorie de zbor
se poate intersecta cu traiectoria avionului proprietar sistemului, estimând în acest fel riscul unei eventuale coliziuni si
generând semnale de alertă (in cazul avioanelor pilotate manual) si comenzi de evitare (in cazul avioanelor echipate cu
sisteme de pilotaj automat). TCAS operează independent, fără să comunice cu ATC (Air Traffic Control) sau cu alte
centre de semnalizare de la sol. Astfel, sistemul asigură detecţia avioanelor aflate în apropiere si care sunt echipate cu
transpondere ATCRSB care răspund la interogările A, C sau S, în banda de frecventa alocata transponderelor (1030 –
1090MHz, modulaţie FSK – DCXO, 10KHz / canal) realizând predicţii referitoare la traiectoria ce va fi urmată de acesta
(de remarcat faptul ca sistemul poate calcula numai traiectoria inerţiala a ţintei) si generând evaluări permanente
privitoare la riscul de coliziune.

Figura 11. TCAS – schema bloc si model de comunicatie

Detecţia ţintei se face prin scanarea permanentă a frecventelor de transponder iar la identificarea unui emiţător în
zona de acţiune, TCAS calculează automat distanta, altitudinea, atitudinea, viteza si coordonatele de deplasare ale ţintei
relativ la poziţia sa.
Transmisia ATCRSB se realizează în 4 (patru) faze de comunicaţie (2 secvenţe semiduplex), conform
specificaţiei „Mode S”:
o Comm-A: prima secvenţă este o interogare de lungime totala 112 biţi ce conţine o secvenţa – mesaj de 56 biţi.
Acest mesaj este folosit ca protocol de sincronizare a comunicaţiei generale, fiind difuzat către toţi posibilii
receptori din raza de acţiune (denumit „broadcast protocol”);
o Comm-B: secvenţa primară de răspuns, de lungime totală 112 biţi continand secvenţa de date – mesaj de 56 biţi.
Acest mesaj reprezintă răspunsul la interogarea generală.
o Comm-C: secvenţa de interogare punctuală, de lungime 112 biţi, adresata avionului desemnat ca si corespondent.
Mesajul de răspuns efectiv reprezintă o secvenţa de 80 biţi, transmisă conform protocolului ELM (extended length
message);
o Comm-D: secvenţa de răspuns, de lungime totala 112 biţi, continand informaţia de răspuns, organizata intr-un
mesaj de 80 biţi, transmisa conform protocolului ELM.
Protocolul ATCRSB (Air Traffic Control Radar Beacon System) asigura comunicarea parametrilor aeronavelor
(atât cei de identificare cat si cei de zbor), asigurând atât funcţionarea în mod activ (semiduplex, când ambele aeronave
isi transmit parametrii) cat si în mod pasiv (simplex, când, din diverse motive, doar aeronava corespondenta isi transmite
datele).
O atenţie deosebită se acordă codurilor de transponder alocate situaţiilor (7400, 7500, 7600, 7700) de urgentă,
coduri care, în orice situaţie, prezintă prioritate absolută.

2.8 Protocoale VECOM pentru de identificare a vehiculelor terestre


Standardul VECOM, lansat în 1986 de firma Hanning&Kahl Gmbh (Germania) a fost conceput ca standard simplu,
uşor implementabil si cu fiabilitate si fezabilitate mare. Datorită acestor factori, VECOM este utilizat si astăzi si se
continuă implementarea sa atât în echipamente de cale ferata (tren, tramvai, metrou) cat si în sisteme rutiere. Secvenţa de
transmisie VECOM se transmite de la echipamentul mobil către o bucla fixă, aflată în cale sau în asfalt. Transmisia se
asigură în radiofrecvenţă, cu transmisie cu modulaţie FSK în banda de bază (tipic 80 kHz – „1”, 90kHz – „0”, 100kHz +
300kHz – sincronizare).

Sincronizare – transmisie bucla

Date – transmisie mobil

Rezervat variante imbunatatite


Figura 12. Secventa de transmisie sincronizata VECOM

Structura mesajului VECOM nu este standardizată, insă forma de bază conţine un cuvânt de 32 biţi utili cu care se
asigură sincronizarea si o serie de informaţii de baza referitoare la vehicul.

Sincro / 12 ID Vehicul / 16 biti Directie / 3biti EOF /1bit


bit

Figura 13. Structura mesajului VECOM, 32 biti

La variantele mai evoluate, bitul de încheiere (EOF) este setat NUL (EOF = 0), secvenţa de date fiind completată
cu noi cuvinte de date transmise de vehicul către bucla fixă. Astfel, sistemul de sol (considerat receptor) este compatibil
cu toate sistemele de transmisie mobilă, indiferent de varianta constructivă a acestora.

S-ar putea să vă placă și