Documente Academic
Documente Profesional
Documente Cultură
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.
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.
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.
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ă).
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).
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).
0 1 2 3 4 5 6 7 8 9
MSB LSB
mesaj
rezervat
Semnal sincronizare
timp
- 5V
CH x
timp
- 5V
0 1 2 3 4 5 6 7 8 9
ALARMA
Data
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.) :
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.
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ă.
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.
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.