Carti Unite

UNIVERSITATEA TEHNICĂ A MOLDOVEI
SISTEME ȘI REȚELE DE COMUNICAȚII DIGITALE

Partea 1
CICLU DE PRELEGERI
Chişinău
2014
3
Facultatea Inginerie și Management în

Electronică şi Telecomunicaţii
Catedra Telecomunicaţii
SISTEME ȘI REȚELE DE COMUNICAȚII DIGITALE

Partea 1
CICLU DE PRELEGERI
Chişinău
Editura „Tehnica – UTM”
2014
4
Lucrarea de față include prima parte a cursului Sisteme și rețele
de comunicații digitale și este divizată în două compartimente. În
primul compartiment este dată definiția și arhitectura rețelelor de noua
generație NGN, motivele și cauzele migrării rețelelor clasice PSTN spre
rețelele NGN. În partea a doua a lucrării – detaliat, se analizează
protocolul de inițiere a sesiunii SIP.
Obiectivul principal al acestui curs constă în însușirea
cunoștințelor de bază privind rețelele de noua generație inclusiv
arhitectura rețelei, componentele funcționale, protocoalele utilizate,
platformele tehnologice actuale și viitoare.
Cursul Sisteme și rețele de comunicații digitale este destinat
studenţilor UTM cu profilul 525 Electronică şi comunicaţii,
specialităţile Teleradio – comunicații, cu forma de studii la zi şi cu
frecvenţă redusă.
Autor: conf.univ., dr. Ion NAZAROI
Recenzent: conf.univ., dr. Nicolae BEJAN
Redactor: Elvira GHEORGHIȘTEANU
Bun de tipar Formatul 60x84 1/16

Hârtie ofset. Tipar RISO Tirajul 55 ex.
Coli de tipar 4 Comanda nr.
U.T.M., 2004, bd. Ştefan cel Mare şi Sfânt, 168

2068, Chişinău, str. Studenţilor, 9/9
© U.T.
5
INTRODUCERE
Dezvoltarea actuală a sistemelor și rețelelor de comunicaţii digitale,

atît în domeniul comunicaţiilor fixe cît şi al comunicaţiilor mobile, este
orientată pe introducerea şi utilizarea de tehnologii care permit
integrarea diferitelor tipuri de servicii în cadrul reţelelor de
telecomunicaţii unice. Combinarea suportului rețelei de telecomunicaţii
cu cel informatic permite exploatarea capabilităţilor oferite pentru
aplicaţii noi şi performante.
O serie de noi tehnologii, protocoale și echipamente elaborate în
ultimele două decenii au avut o influență hotărîtoare asupra trecerii de
la rețelele clasice la cele de noua generație NGN. Printre principalele
pot fi numite:
 Tehnologiile de acces de bandă largă ADSL, VDSL, FTTx,
LTE, WiMax, etc;
 Sistemul de transmisiuni DWDM (Dense Wavelength
Division Multiplexing – multiplexarea densă a lungimilor de
undă) la nivelul fizic;
 Metoda de comutație rapidă de pachete după etichetă MPLS
(Multiprotocol Label Switching) la nivelul "2.5";
 Dezvoltarea de tehnologii Ethernet dincolo de LAN;
 Noi echipamente terminale, aparate telefonice IP, PC, IPad,
smartphonuri,etc;
 Dezvoltarea de protocoale adecvate pentru a oferi servicii de
comunicații voce bazate pe pachete (SIP, H.323);
 Digitalizarea fluxurilor de media (voce, date, imagini).
În sfîrșit dar nu în ultimul rînd aici se poate de menționat și
dezvoltarea vertiginoasă a serviciilor Internet bazate pe suita de
protocoale TCP/IP.
În același rînd, printre principalele cauze care au determinat
operatorii de telecomunicații tradiționali să inițieze migrarea reţelei PSTN
spre o reţea de nouă generaţie pot fi enumerate:
-tendinţa de utilizare a unei tehnologii mai eficiente decît cele
bazate pe comutaţia de circuite pentru transmiterea traficului de voce, de
comun cu integrarea transmisiunilor voce, date, imagini într-o reţea unică;
6
-solicitări din partea utilizatorilor de noi servicii, în special cele
care necesită o bandă largă de transmisiune cum ar fi acces rapid la
Internet, video la cerere (VoD), IPTV, jocuri interactive ( entertainment),
etc;
-concurenţa ascendentă din partea prestatorilor de servicii de
telefonie internaţională prin Internet astfel ca Skype, Microsoft, Yahoo şi
alte companii, precum şi cea din partea prestatorilor de telefonie IP locali.
Sub influenţa acestor forţe motrice sectorul serviciilor de
comunicaţii a suferit deja schimbări importante pe parcursul cîtorva ani.
Centralele tradiţionale PSTN de clasa 5 şi clasa 4 se substituie cu
Gateway-uri de acces şi trunchiuri sub controlul Softswitch-ului sau a
Media Gateway Controler-ului şi în continuare cu trecerea treptată la
platforma IMS (IP Multimedia Subsystem). Reţelele magistrale migrează
pe tehnologii ALL-IP/MPLS deseori în contextul implementării
sistemelor de transmisiuni DWDM la nivelul fizic. La nivelul doi se
dezvoltă reţelele de transport Giga- şi Metro-Ethernet. Pe larg se
desfăşoară reţelele pe fibră optică inclusiv şi pe ultima milă. Tot mai
mulţi abonaţi utilizează tehnologii de bandă largă ce asigură o viteză
înaltă de acces şi gamă largă de servicii Triple Play. Devine posibilă şi tot
mai des implementată convergenţa fix-mobil. Convergența fix-mobil
(FMC) este tendința de conectivitate între rețelele de telecomunicații fixe
și fără fir (wireless). Scopul FMC este a optimiza transmiterea tuturor
comunicațiilor de date, voce sau video utilizatorilor finali indiferent de
locația lor sau de dispozitivele utilizate.
Obiectivul principal al acestui curs constă în însușirea
cunoștințelor de bază privind rețelele de noua generație inclusiv
arhitectura rețelei, componentele funcționale, protocoalele utilizate,
platformele actuale și viitoare.
Prima parte a cursului de prelegeri include expunerea generală a
reţelelor de noua generaţie şi continuă cu protocolul de semnalizare
cheie pentru aceste reţele – protocolul de iniţiere a sesiunii SIP.
Lucrarea în cauză este destinată studenţilor ultimului an universitar,
masteranzilor, dar autorul speră să fie de folos și tuturor celor din
domeniul TIC interesaţi de subiectele abordate.
7
1. PREZENTAREA GENERALĂ A NGN
1.1 Definiția NGN
Rețea de noua generație NGN (Next Generations Network) este un

termen generic utilizat pentru descrierea rețelelor aflate actualmente în
curs de dezvoltare și implementare intensivă.
Conform definiţiei Uniunii Internaţionale a Telecomunicaţiilor
(ITU), termenul NGN este o rețea bazată pe comutația de pachete,
capabilă să ofere servicii de telecomunicații cu utilizarea a multiple
tehnologii de transport de bandă largă (broadband) cu asigurarea unui
nivel adecvat de calitate a serviciilor (QoS) și la care funcțiile relevante
serviciilor sînt independente de tehnologiile de transport. Ea asigură
acces nerestricționat a utilizatorilor la rețele și furnizori de servicii
competitivi și/sau la servicii la alegerea sa, capabilă să susţină
mobilitate generalizată, conducînd astfel la furnizarea consistentă şi în
mod independent de locaţie servicii către utilizatori [1].
O rețea NGN este caracterizată prin următoarele aspecte
fundamentale:
- bazată pe transfer de pachete IP pentru transportarea tuturor
tipurilor de informaţii;
- organizată pe nivele: acces/ transport, control/semnalizare şi
aplicații/servicii cu interfeţe deschise între aceste nivele ;
- nivelul de control/semnalizare separat de la nivelul de
transport/comutaţie;
- funcțiile referitor la servicii sînt independente de tehnologiile de
transport folosite ;
- suportă o gamă largă de servicii, aplicații și mecanisme bazate
pe servicii în bloc, inclusiv servicii în timp real, de striming și
multimedia;
- capabilă de transmisii de bandă largă cap-la-cap cu asigurarea
calităţii serviciilor (QoS) pentru toate tipurile de trafic;
- convergența serviciilor între rețelele fixe și mobile;
8
- acces nerestricționat al utilizatorilor la diferiți furnizori de
servicii;
- suportă multiple tehnologii de transport pe ultima milă;
- conlucrează cu rețelele existente prin interfețe deschise;
- mobilitate generalizată;
- o varietate de scheme de identificare, care pot fi rezolvate la
adresele IP în scopul de rutare în rețele;
- tehnologii mai ieftine și mai eficiente în comparație cu
tehnologiile actuale;
- conforme cu toate cerințele de reglementare, de exemplu în ceea
ce privește comunicațiile de urgență și de securitate, de
confidențialitate, etc.
Uniunea Internaţională a Telecomunicaţiilor a alocat în mod special
pentru NGN seria Y.2000 și a elaborat deja un șir de recomandări.
Primele printre acestea au fost recomandările – Y.2001 (12/2004)
„Descrierea generală a reţelei NGN” şi Y.2011 (10/2004) „Principii
generale şi modelul etalon generalizat al reţelei de nouă generaţie”.
Printre ultimele publicații ITU-T relevante din această serie la
momentul scrierii acestei lucrări sînt Y.2026(07/2012) ” Cerințe
funcționale și de arhitectură a rețelei de nouă generație privind sprijinul
aplicațiilor și serviciilor în rețelele de senzori omniprezente”, Y.2724
(11/2013) " Cadru pentru susținerea OAuth și OpenID în rețele de noua
generație ", Y.2254 (01/14) ” Capabilitățile de multi-conectare în
sprijinul serviciilor îmbunătățite de telefonie multimedia” și altele.
O altă instituție preocupată de elaborarea standardelor pentru NGN
este Institutul European pentru Standardizare în Telecomunicații ETSI
(European Telecommunications Standardization Institute). ETSI
determină NGN ca o rețea funcțional stratificată cu interfețe deschise
care permite desfășurarea de servicii independente de acces prin
intermediul rețelelor fixe și mobile convergente. Este bazată pe pachete
și utilizează protocolul internet IP pentru a transporta diverse tipuri de
trafic (voce, date, video și semnalizări).
Trebuie remarcat că rețelele NGN se implementează deja de mai
mulți ani într-un șir de țări, inclusiv și în Republica Moldova, astfel
9
tehnologia nu este de fapt ”următoarea tehnologie”, dar ea este deja una
existentă. Termenul este, totuși, acceptat și pe larg utilizat în domeniu.
1.2. Arhitectura NGN
Arhitectura NGN deseori se prezintă pe trei nivele funcționale:

1. Nivelul transport și comutație.
2. Nivelul control rețea și semnalizare.
3. Nivelul servicii, control servicii și aplicații.
În mod simplificat aceste nivele sînt prezentate în figura 1.1.
Application Servers Servicii, control servicii

Management Servers și aplicații
API/Parlay/LDAP
SNMP
…
Softswitches Control rețea și

semnalizare
MGCP
Megaco/H.248
…
Media Gateways Transport și comutație
API - Application Programming Interface
Fig. 1.1. Arhitectura NGN.
Între aceste nivele se stabilesc interfețe standardizate, deschise.

Astfel nivelele devin independente și se pot dezvolta de sine stătător.
10
1.2.1. Nivelul transport și comutație
Nivelul de transport și comutație include două subnivele: rețeaua

core (nucleu, magistrală) și rețeaua de acces (figura 1.2).
Rețeaua core este constituită din rutere magistrale (Core Node) și de
frontieră (Edge Node) și se bazează de regulă pe tehnologia IP/MPLS.
La nivelul fizic se utilizează fibra optică cu sisteme de multiplexare cu
divizarea densă a lungimii de undă DWDM (Dense wavelength division
multiplexing) , Ethernet sau STM-64. Comutația pachetelor IP se
efectuează de rutere sau switch-uri de nivelul 3. Astfel se obține o
infrastructură cu comutație dispersată cea ce este mai eficient decît
concentrarea comutației în cadrul rețelelor de conexiune ale centralelor
digitale sincrone utilizate în PSTN.
Fig. 1.2. Schema de structură a rețelei core și de acces
11
Utilizatorii finali sînt conectați la NGN prin interfața utilizator-la-
rețea (UNI), în timp ce alte rețele sînt interconectate între ele prin
interfața rețea-la-rețea (NNI).
Rețeaua de acces include echipamentul terminal al abonatului, linia
de abonat și nodul de acces (AN) de bandă largă sau îngustă.
Terminalele abonaților pot fi aparate telefonice convenționale,
televizor precum și echipamente cu grad sporit de inteligență bazate pe
IP cum ar fi telefon SIP, notebook, tabletă, smartphon, phablet, etc
(figura 1.3). Liniile de abonat pot fi pe fire de cupru, fibre optice, cablul
coaxial, frecvențe radio, canale prin satelit sau combinarea dintre
acestea.
Fig. 1.3. Setul de terminale la edificiul abonatului.
Tehnologiile utilizate pentru asigurarea accesului de bandă largă sînt

ADSL, VDSL, GPON, DVB (Digital Video Broadcasting), WiFi,
WiMAX (Worldwide Interoperability for Microwave Access) și altele.
Cu diversificarea și creșterea continuă a volumului de date transmise
prin rețea sînt cerute viteze tot mai mari de conectare a punctelor
terminale la nodurile de acces. Doar un singur exemplu arată la ce
12
viteze se planifică să fie asigurat accesul la servicii de comunicații
electronice. În Agenda digitală pentru Europa (DAE), o inițiativă a
strategiei Europa 2020 pentru o economie inteligentă, a fost stabilit
obiectivul de bază ca fiecare cetățean european pînă în anul 2020 să fie
asigurat cu acces de bandă largă a rețelelor de nouă generație la viteza
de cel puțin 30 Mbps, iar pentru 50% din gospodării de cel puțin 100
Mbps.
În calitatea de noduri de acces pot fi utilizate AGW (Access
Gateway), RAGW ( Residential AGW), IAD (Integrated Access
Device), ATA (Analog Telephone Adapter) pentru conectarea
telefoanelor PSTN, iar rutere sau switch-uri pentru puncte terminale
SIP/H.323. Telefoanele convenționale enologice POTS TE se
conectează prin două fire de cupru a/b iar cele digitale ISDN TE prin
interfața U(S/T). Nodurile de acces existente cum sînt centralele
departamentale PBX sau cu acces în protocolul V.5 se conectează la
AGW prin fluxuri digitale E1, SHDSL sau ISDN PRA. Pentru
interconectarea centralelor CTA ale rețelei PSTN se folosesc fluxuri
digitale E1 și TGW (Trunking Gateway). Oricare Media Gateway
asigură trecerea de la fluxurile digitale ale PSTN la fluxurile RTP sau
de semnalizare ale rețelei IP/MPLS (figura 1.4).
Fig. 1.4. Schema de structură MGW

13
1.2.2. Nivelul control rețea și semnalizare
Controlul semnalizării de apel în NGN este efectuat de serverul de

apeluri numit Softswitch. Echipamentul Softswitch îndeplineşte mai
multe funcţii printre care:
- efectuează dirijarea unui apel în reţea pe baza semnalizării și a
informaţiilor legate de abonat;
- controlează serviciile de interconectare pentru media gateway şi
pentru terminalele VoIP;
- permite transferul controlului apelului către un alt element din
reţea;
- păstrarea și gestionarea datelor abonaților în mod direct sau prin
intermediul gateway-lui;
- și alte funcţii de gestionare cum ar fi înregistrarea, gestionare
erori, facturarea, etc.
La acest nivel se referă și gateway-ul de semnalizări SGW care
realizează trecerea de la sistemul de semnalizare pe canal comun SS#7
utilizat în rețeaua cu comutație de circuite SCN (Switched Circuit
Network) la semnalizarea SIGTRAN bazată pe IP a rețelei NGN.
1.2.3. Nivelul servicii, control servicii și aplicații
După cum sa menționat anterior în NGN funcțiile legate de servicii

sînt independente de tehnologiile de transport utilizate. Decuplarea
aplicațiilor de rețele permite prestatorilor de servicii elaborare
aplicațiilor pe diferite platforme și furnizarea serviciilor concurențiale
în condiții non-discriminatorii. Nivelul servicii, control servicii și aplicații
este conectat la nivelul control rețea și semnalizare prin intermediul unor
API-uri (Application Program Interface).
Serviciile multimedia, telefonie, date (WWW, e-mail, etc) și video
(IPTV, video la cerere, videoconferință, etc) pot fi punct-punct, punct-
multipunct sau multipunct-multipunct.
Nivelul servicii, control servicii și aplicații include servere de
aplicații și servere media (teleconferință, Interactive Voice Response -
IVR, etc). Aplicațiile sunt încorporate în serverele de aplicații dedicate
14
acestui scop. Deseori serverele de aplicații sunt completate cu servere care
găzduiesc baze de date cu conținut adițional (sistemul de facturare,
sistemul de administrare al rețelei, administrarea performanței rețelei,
colecții de video-clipuri sau de știri, etc.).
Împreună cu o nouă arhitectură, rețeaua de nouă generație aduce un
nivel suplimentar de complexitate în comparație cu cel al rețelelor fixe
existente. În special, suportul a multiple tehnologii de acces și a
mobilității generalizate aduce la necesitatea susținerea unei varietăți
largi de configurații.
1.3. Protocoale de semnalizare în NGN
Migrarea spre NGN, după cum a fost arătat mai sus, prezintă mai
curînd un proces evoluționist decît revoluționar. Acest proces evident se
soldează în primul rînd cu un impact semnificativ asupra semnalizării
deoarece semnalizarea este punctul de pornire a evoluției rețelei.
Reieșind din acest considerent în cea ce urmează vor fi expuse
principalele protocoale de semnalizare NGN.
Semnalizarea în rețea de telecomunicații înseamnă efectuarea unui
schimb de semnale funcționale între echipamentele ei în scopul
stabilirii, modificării, monitorizării sau eliberării unui apel sau sesiuni
de comunicare. În NGN în acest scop se utilizează un șir de protocoale
numite de semnalizare.
În figură 1.5 se prezintă un fragment al unei rețele NGN cu
includerea principalelor elemente: două Softswitch-uri care controlează
echipamentele rețelei, gateway-ul de acces AGW la care se conectează
terminalele convenționale ale abonaților, gateway-ul de trunchiuri TGW
și cel de semnalizare SGW pentru interconectarea a diferitor tipuri de
rețele - NGN și PSTN și segmente de rețele bazate pe protocolul SIP și
protocolul H.323 la care se conectează terminale SIP sau H.323
respectiv. La nivelul aplicațiilor ca exemple sînt arătate serverul media
și serverele de aplicații ce aparțin unor terțe părți.
15
Fig. 1.5. Fragment rețea NGN și protocoale utilizate.
Din figura 1.5 se poate observa și tipurile de protocoale de

semnalizare și transport ce se utilizează și la care segment al rețelei ele
se referă. Astfel pentru controlul gateway-urilor se utilizează
protocoalele H.248 sau MGCP, pentru semnalizare apel - protocoalele
SIP sau H.323, pentru interacțiunea dintre două softswitch-uri –
protocoalele SIP-T, H 323 sau BICC, pentru transportul fluxurilor de
date utilizator – protocolul RTP/RTCP, etc.
Stiva de protocoale de semnalizare poate fi clasificată în
corespundere cu funcțiile sale: (i) în protocoale de dirijare sesiune
(control apel) și (ii) protocoale de control a media gateway-urilor
AGW, TGW și SGW (figura 1.6).
16
Fig. 1.6. Stiva de protocoale pentru NGN.
La primul tip se referă protocolul de inițiere a sesiunii SIP și

protocolul umbrelă H.323 care vor fi studiate mai detaliat în cadrul
acestui curs. Suita de protocoale SIGTRAN este folosită ca metodă de
transport peste IP pentru pachetele de semnalizare pe canal comun SS7
din rețelele PSTN.
Ca exemple de protocoale de control a media gateway sînt aduse
protocoalele H.248, numit și MEGACO, și protocolul MGCP.
Protocolul MGCP treptat este substituit de protocolul H.248 și deacea
în continuare nu se examinează.
La nivelul de transport sînt indicate protocoalele pe care rulează
protocoalele de semnalizare enumerate. Acestea sînt protocoalele de
transport bine cunoscute UDP, TCP, dar și protocolul de transport cu
controlul fluxului de date SCTP (Stream Control Transmission
Protocol). Pentru comparație pe figură se arată și locul unde în această
arhitectură se situează protocolul de transport în timp real RTP cu
17
ajutorul căruia se efectuează transmisia informației media cum ar fi
vocea, video sau alt tip de date în timp real.
2. PROTOCOLUL DE INIȚIERE A SESIUNII SIP
Protocolul de inițiere a sesiunii SIP (Session Initiation Protocol) a

fost elaborat în cadrul Grupul operativ de inginerie a internetului
(Internet Engineering Task Force - IETF) și publicat pe 270 de pagini
ale standardului RFC 3261 [2] în iunie 2002. Inițial SIP a fost definit de
standardul RFC 2543 în anul 1999.
Protocolul SIP se atribuie nivelului aplicațiilor şi asigură crearea,
modificarea sau încheierea sesiunilor de comunicare multimedia cu
unul sau mai mulți participanți. Conceptul de sesiune a fost introdus
pentru prima dată de protocolul de descriere a sesiunii SDP în RFC
2327 ca un schimb de fluxuri de date multimedia între participanți. Ca
exemple de sesiune pot servi apelul telefonic, conferința video,
controlul de la distanță al unui calculator, schimbul de date între
utilizatori, chatul, schimbul instantaneu de mesaje, etc.
Într-o sesiune SIP este posibilă, de asemenea, suplinirea numărului
participanților la sesiunile deja în desfășurare, de exemplu, în cadrul
unei conferințe multicast. Deși protocolul SIP nu efectuează el însăși
transportul fluxurilor media (acest rol îi revine protocolului RTP), totuși
SIP-ul permite ca aceste fluxuri media să fie adăugate sau îndepărtate
de la o sesiune existentă. O calitate importantă a acestui protocol este
admiterea așa numitei mobilități personale. Acesta înseamnă că
utilizatorul SIP poate accesa rețeaua oriunde, indiferent de locație, fiind
identificat prin unul dintre SIP URI-urile (identificator uniform de
resurse) sale.
Protocolul SIP nu este un sistem de comunicare integrat pe verticală.
El este mai degrabă o componentă care poate fi utilizată de comun cu
alte protocoale IETF pentru a construi o arhitectură multimedia
completă. În mod tipic această arhitectură include așa protocoale, cum
ar fi SDP (RFC 4566 [3]) pentru descrierea sesiunii multimedia, RTP
(RFC 3550), pentru transportul de date în timp real și furnizarea
feedback-ului pentru asigurarea calității QoS, RTSP (RFC 2326)
18
pentru a controla livrarea de media streaming și H.248 pentru controlul
gateway-urilor la PSTN. Prin urmare, SIP se utilizează în asociere cu
alte protocoale pentru a furniza servicii complete utilizatorilor. Totuși,
funcționarea SIP nu depinde de oricare dintre aceste protocoale.
2.1. Componentele funcționale ale rețelei SIP
O rețea bazată pe protocolul SIP include pînă la patru componente

funcționale:
 Agent utilizator (UA - User Agent);
 Server Registrator;
 Proxy Server;
 Server Redirecționare.
Agentul utilizator UA este entitate logică care poate activa în calitate
de agent utilizator client UAC sau agent utilizator server UAS.
Agentul utilizator client UAC este o aplicație care inițiază noi cereri,
iar agentul utilizator server UAS este o aplicație care răspunde la cereri.
Rolul de client sau server al UA se menține doar pe durata tranzacției.
Deci dacă aplicația răspunde la cerere ea joacă rolul de agent utilizator
server cît durează tranzacția, iar dacă mai tîrziu ea generează o cerere
atunci își asumă rolul de agent utilizator client la procesarea noii
tranzacții. De exemplu, în scopul de a iniția o sesiune UAC al
apelantului trimite un mesaj de invitaţie INVITE care este primit de
UAS al solicitatului. Pe de altă parte, pentru a termina sesiunea,
aplicația celui apelat deja în rolul de UAC transmite un mesaj de
eliberare BYE care este primit de către UAS al apelantului. Exemple
de dispozitive ale rețelei SIP care au funcționalitatea de UAC și UAS
sînt telefonul SIP, calculatorul, PDA-ul, gateway-ul, robotul telefonic,
agentul de apel, etc.
Serverul Registrator este o bază de date care indică locația tuturor
agenților utilizatori UA din domeniu. Acesta acceptă cererile de
înregistrare REGISTER de la UA și menține mai multe tipuri de adrese
SIP URI pentru fiecare utilizator. Registratorul indică, de asemenea,
adresa curentă ca prima prioritate de la care utilizatorul dorește să
trimită cererea și la care să primească răspunsul. Deseori serverul
19
Registrator este colocat cu serverul Proxy pentru acest domeniu.
Agentul utilizator poate înregistra mai multe dispozitive. Spre exemplu,
un telefon SIP la oficiu și altul la domiciliu. În același timp pe un singur
aparat pot fi înregistrați mai mulți utilizatori.
Proxy serverul este o entitate intermediară care acționează și ca
server, și ca client în scopul de a face cereri în numele altor clienți.
Serverul proxy primește cereri de inițiere a sesiunii făcute de la UAC și
interogă Serverul Registrator pentru a obține adresa curentă a
destinatarului (UAS). Apoi, înaintează invitația la sesiune direct la UAS
solicitat dacă el este situat în același domeniu sau la un alt server proxy
în cazul în care UAS are reședința într-un alt domeniu.
Serverul Redirecționare este folosit pentru a furniza adrese
alternative pentru o cerere. Pot există mai multe motive pentru care
acest lucru ar fi de dorit. De exemplu, operatorul de rețea poate dori să
trimite adrese alternative de rutare a unei cereri ca un mijloc de
partajare a sarcinii atunci cînd proxy serverul este supraîncărcat.
Este important să se înțeleagă că o entitate SIP nu este un ”obiect”
fizic. Entitățile SIP sînt logice. Serverele enumerate mai sus sînt
entități funcțional distincte dar ele pot fi realizate pe același hardware.
2.2. Structura mesajelor SIP
Protocolul SIP este bazat pe text și utilizează setul de caractere ISO

10646 în codificarea UTF-8 (RFC 2279). El a fost derivat din
Protocolul de Transfer Hypertext (HTTP - Hypertext Transfer Protocol)
dar nu este o extensie a ultimului. SIP se bazează pe tranzacții cerere /
răspuns. Fiecare tranzacție constă dintr-o cerere SIP (care va fi una
dintre mai multe metode - cereri) și cel puțin un răspuns.
Un mesaj SIP este fie o cerere de la un client UAC la un server
UAS, sau un răspuns de la un server la un client. Mesajul este format
din trei părți (fig.2.1) linia de start, anteturile și conținutul (corpul).
20
Linia de start
Anteturile
Linie goală (CRLF)*
Conținutul(corpul)
*) Linia de start, fiecare antet și linia goală trebuie să fie
terminată cu CRLF (Carriadge Return, Line Feed). Linia goală
trebuie să fie prezentă chiar dacă Conținutul (corpul) nu este.
Fig. 2.1. Mesajul SIP
1) Linia de start.
Fiecare mesaj începe cu linia de start. Cu ea începe sau mesajul -
Cerere, sau mesajul - Răspuns după cum urmează:
 Linia - Cerere include tipul cererii, adresa URI, care indică
utilizatorul sau serviciul la care se adresează această
solicitare și versiunea SIP. Fiecare element este separat
printr-un singur caracter SP (spațiu gol).
Tip cerere SP Adresa destinație SP Versiune SIP
(Method SP Request-URI SP SIP-Version)
 Linia-Răspuns este o linie de stare. Ea constă din versiunea

protocolului urmată de un cod numeric și o frază textuală
asociată cu acest cod de răspuns. Fiecare element este separat
printr-un singur caracter SP.
Versiune SIP SP Cod răspuns SP Descrierea textuală
(SIP-Version SP Status-Code SP Reason-Phrase)
2) Anteturile.
Cîmpurile anteturi SIP sînt folosite pentru a transmite atributele
mesajului. Ele conțin informații detaliate despre cerere sau răspuns
care includ de exemplu adresele de destinație și de inițiere, informații
21
de rutare, etc. Antetul SIP este similar în sintaxă și semantică cu antetul
protocolului HTTP (unele antete sînt de fapt împrumutate de la HTTP).
Antetul poate să includă mai multe linii. Unele anteturi SIP, cum ar fi
Via, Contact, Route pot apărea de mai multe ori într-un mesaj sau,
alternativ, pot lua mai multe valori separate prin virgulă într-un singur
antet.
3) Conținutul (corpul).
Corpul mesajului este utilizat pentru descrierea sesiunii inițiate
utilizînd protocolul SDP sau MIME (Multipurpose Internet Mail
Extensions). De exemplu, într-o sesiune multimedia aceste informații
includ tipurile de codecuri audio și video folosite, ratele de discretizare
sau orice alt text sau date binare care descriu cumva sesiunea.
Protocolul SIP face o distincție clară între informațiile de semnalizare,
incluse în linia de start și cîmpurile anteturi, pe de o parte, și
informațiile ce descriu sesiunea, care sînt în afara domeniului de
aplicare a SIP, pe de altă parte.
2.3. Cereri SIP
În specificația RFC 3261 sînt definite șase tipuri de cereri numite

metode (methods): REGISTER pentru înregistrarea de informații de
contact, INVITE, ACK și CANCEL pentru crearea de sesiuni, BYE
pentru terminarea sesiunilor și OPTIUNS pentru interogarea serverelor
cu privire la capabilitățile lor. Ulterior prin alte RFC au fost definite
metode suplimentare (tabelul 2.1). În tabel se aduce descrierea
specificației și se indică numărul RFC prin care ea a fost definită și
luna.anul publicării.
Tabelul 2.1. Lista metode/cereri SIP
Cererea Descrierea RFC
INVITE Stabilește o sesiune între 3261/06.2002*
participanți. și
6026/09.2010
ACK Confirmare transmisă ca 3261
răspuns la cererea INVITE.
22
CANCEL Anulează o tranzacție în 3261
așteptare la care încă nu este
primit răspuns final.
INFO Oferă un mecanism de 6086/01.2011
transport a informației de
nivelul aplicațiilor care poate
îmbunătăți o aplicație SIP
(DTMF, GPS locație).
BYE Încheie o sesiune. 3261

MESSAGE Transferuri de mesaje instant 3428/12.2002
între utilizatori aproape în timp
real. Transferul mesajelor
înainte și înapoi este suficient
de rapid pentru ca participanții
să mențină o conversație
interactivă.
NOTIFY Informează un abonat cu 6665/06.2012

privire la schimbarea de stare a
resursei (s-a petrecut un
eveniment pentru care s-a cerut
confirmare).
OPTIONS Interoghează serverul cu 3261
privire la capabilitățile sale.
PRACK Similar cu ACK, însă pentru 3262/06.2002
transmitere fiabilă a
răspunsurilor provizorii.
PUBLISH Similar cu REGISTER in cea 3903/10.2004
ce privește posibilitatea unui
utilizator să creeze, modifice și
elimine o stare într-o altă
23
entitate care gestionează
această stare în numele
utilizatorului.
REFER Indică faptul că destinatarul 3515/04.2003
trebuie să contacteze o terță
parte, folosind informațiile de
contact furnizate în cerere.
REGISTER Înregistrează informații de 3261
contact.
SUBSCRIBE Cereri de stare curentă și 6665/06.2012
actualizări de stare de la un nod
distant.
UPDATE Actualizează parametrii unei 3311/ 09.2002
sesiuni.
*) RFC 3261 a înlocuit specificația anterioară RFC 2543 din martie

1999.
Mai jos este dată descrierea mai detaliată a fiecărei cereri în parte.
Pentru o studiere mai profundă ce poate consulta RFC-ul corespunzător
indicat în coloniţa 3 a tab.2.1.
Metoda INVITE indică faptul că utilizatorul este invitat să
participe la o sesiune. Corpul mesajului conține o descriere a sesiunii la
care apelantul este invitat. Pentru un apel dintre doi abonați în pereche
(punct-punct), apelantul indică tipul de media/informației, care el este
capabil s-o primească și, eventual, parametrii fluxului media pe care-l
va transmite. Dacă invitația se acceptă atunci cel apelat indică în corpul
mesajului tipul media pe care el, la rîndul său, poate recepționa și
transmite.
Metoda ACK confirmă că clientul a primit răspuns final la o cerere
INVITE. Este posibil ca cererea să conțină corpul mesajului cu
descrierea finală a sesiunii pentru a fi utilizată de cel apelat. În cazul în
care corpul mesajului ACK este gol, atunci apelatul folosește descrierea
sesiune dată în cererea INVITE.
24
Metoda CANCEL anulează o cerere în curs cu aceleași valori de
identificare în cîmpul antetului, dar nu afectează o cerere completată . O
cerere se consideră completată dacă serverul a returnat un răspuns final
de stare.
Metoda INFO este folosită pentru a transporta informații care nu
schimbă starea apelului. Scopul cererii INFO este de a transporta
informații de nivelul aplicațiilor între agenții utilizatori SIP. Datele
aplicației se transferă în cadrul datelor utile ale corpului mesajului
INFO. De exemplu, în protocolul SIP-T (telefonie) astfel sînt transmise
informațiile de semnalizare ISUP. Mesajele INFO diferă de alte mesaje
SIP deoarece ele transportă informațiile aplicațiilor și deacea
dimensiunea și rata mesajelor este direct determinată de aplicație. Unele
aplicații, cum ar fi trimiterea tonurilor DTMF, pot genera o explozie de
pînă la 20 de mesaje pe secundă. Alte aplicații, cum ar fi actualizări
constante de localizare GPS, ar putea genera o rată mare de cereri INFO
pe durata utilizării dialogului INVITE.
Cererea BYE se utilizează de UAC sau de UAS pentru a informa
cealaltă parte a dialogului despre încheierea sesiunii. Un UA care
primește o cerere BYE în cadrul unui dialog existent trebuie să termină
sesiunea încetînd să trimită și să primească fluxuri media.
Metoda MESSAGE este utilizată pentru expedierea de mesaje
instant similar cu trimiterea SMS de la un telefonul celular sau de la un
pager bidirecțional. Cererile MESSAGE în mod normal transportă
conținutul mesajului instant în corpul MIME (Multipurpose Internet
Mail Extensions) al cererii. Dimensiunile datelor mesajului nu trebuie
să depășească 1300 bytes pentru a evita probleme cu segmentarea SIP.
Pentru a nu admite congestii se cere ca clienții să nu trimită o nouă
cerere MESSAGE pînă ce nu vor primi confirmare de primire la cea
anterioară.
Metoda SUBSCRIBE este utilizată pentru a solicita informații
despre starea curentă sau schimbarea de stare a unei resurse de la un
nod distant. Exemple de servicii care folosesc cererea SUBSCRIBE sînt
callback automat (bazat pe evenimentele de stare a terminalului), lista
prietenilor (bazată pe evenimentele de prezență a utilizatorului),
indicarea mesajelor în așteptare (bazată pe evenimentele de schimbare
25
de stare a cutiei poștale). Conceptul general este că entitățile rețelei se
pot abona/subscrie la urmărirea stării resursei sau a apelului în rețea. Ca
urmare aceste entități vor transmite notificări la schimbarea de stare a
resursei, apelului. În cerere se indică durata subscrierii. În scopul
prelungirii abonării este nevoie de actualizare periodică a subscrierii
utilizînd noi cereri SUSCRIBE.
Metoda NOTIFY este transmisă pentru informarea utilizatorilor
despre evenimentele de schimbare de stare la care abonații sau subscris.
Subscrierile sînt create folosind metoda SUBSCRIBE. După acceptarea
cererii de subscriere notificatorul trebuie să trimită imediat cererea
NOTIFY pentru a comunica abonatului care este starea curentă a
resursei. Această cerere NOTIFY este trimisă în cadrul dialogului creat
de cererea SUBSCRIBE.
Metoda OPTIONS permite unui UA de a interoga un alt UA sau un
server proxy despre capabilitățile sale. Aceasta permite clientului UAC
să determine metodele acceptate, tipurile de conținut, extensii, codec-
uri, etc, ale UAS fără a "apela" cealaltă parte. De exemplu, dacă un
client nu este sigur de opțiunile suportate de UAS el îl poate interoga pe
ultimul cu o cerere OPTIONS înainte de a transmite cererea INVITE.
Listare de opțiuni primită de la serverul de destinație va fi returnată în
cîmpul antetului Supported al cererii INVITE. Toți agenții utilizatori
UA trebuie să suporte metoda OPTIONS.
Metoda PRACK (Provisional Response ACKnowledgement
method) se folosește pentru transmiterea fiabilă a răspunsurilor
provizorii. Protocolul SIP definește două tipuri de răspunsuri,
provizorii și finale.
Răspunsurile finale se referă la rezultatul prelucrării cererii și sînt
transmise în mod fiabil. Pe cînd răspunsurile provizorii oferă informații
cu privire la cererea în progres și se transmit conform RFC 3261 în mod
nefiabil. Mai tîrziu însă s-a observat că fiabilitate în mai multe cazuri
este importantă și pentru un răspuns provizoriu, inclusiv pentru a
asigura interoperabilitatea cu PSTN. Deacea în RFC 3262 a fost
propusă o metodă suplimentară PRACK pentru a sprijini o transmisie
fiabilă a răspunsurilor provizorii.
26
Metoda REGISTER este folosită de clienții SIP pentru a înregistra
locația lor curentă (una sau mai multe adrese de contact URI) și
asocierea lor cu o adresă publică ("adresa de înregistrare" în
terminologia IETF și "identitate publică" în terminologie 3GPP).
Serverul SIP, care acceptă aceste cereri se numește registrator
(Registrar).
Metoda PUBLISH este similară cu REGISTER in cea ce privește
posibilitatea unui utilizator să creeze, modifice și elimine o stare într-o
altă entitate care gestionează această stare în numele utilizatorului. De
exemplu, o aplicație de evenimente SIP pentru indicarea mesajelor în
așteptare ar putea folosi mecanismul PUBLISH pentru colectarea
stărilor cutiilor poștale și de voce dintre un set de agenți utilizatori.
Metoda este folosită pentru înregistrarea de stare a evenimentului la
entitatea responsabilă de colectarea aceste evenimente.
Metoda REFER indică faptul că destinatarul trebuie să contacteze o
terță parte, folosind informațiile de contact furnizate în cerere. De
exemplu, aceasta poate fi utilizată pentru transferul apelului.
Metoda UPDATE permite unui client să actualizeze parametrii
sesiunii (cum ar fi tipul fluxurilor media și codecurile lor), dar nu are
nici un impact asupra stării dialogului. Este similar cu re-INVITE dar că
spre deosebire de aceasta poate fi transmis înainte de a fi primit răspuns
la cererea INVITE precedentă. Exemplu. Un apelant trimite o cerere
inițială INVITE, care conține o ofertă. Cel apelat generează un răspuns
la această ofertă. Odată cu finalizarea schimbului de cerere /răspuns,
sesiunea este stabilită, doar că dialogul este încă în stare timpurie.
Apelantul decide să actualizeze unele aspecte ale sesiunii, de exemplu,
să treacă în așteptare/on hold. Deci, el generează o cerere UPDATE, cu
o nouă ofertă.
2.4. Răspunsuri SIP
Linia de stare a răspunsului conține un cod (Status-Code) compus

din trei cifre și o frază textuală asociată cu acest cod de răspuns. Codul
indică rezultatul încercării serverului de a înțelege și de a satisface o
cerere. Cifrele codului sînt destinate utilizării de automate, în timp ce
27
partea textuală ce oferă o scurtă descriere a codului numeric este
destinată utilizatorului uman. Codurile sînt în concordanță cu codurile
de răspuns HTTP/1.1, însă sînt mai extinse. Răspunsurile SIP sînt de
două tipuri și șase clase. Cele mai multe răspunsuri (2xx, 3xx, 4xx, 5xx,
și 6xx) sînt "finale" și termină tranzacția SIP curentă. Răspunsurile 1xx
sînt "provizorii" și nu termină tranzacția SIP. Clasa răspunsului este
determinată de prima cifră a codului. Protocolul SIP/2.0 admite șase
valori pentru prima cifră, deci șase clase:
1xx: Provizoriu – cererea este primită și este în curs de procesare
(caută, apelează, așteaptă, etc.);
2xx: Succes – cererea a fost recepționată, este înțeleasă și acceptată;
3xx: Redirecționare – sînt necesare acțiuni suplimentare pentru a
completa cererea;
4xx: Eroare client – cererea conține greșeli sintaxice sau nu poate fi
procesată de acest server;
5xx: Eroare server – serverul nu a reușit să proceseze cererea aparent
validă;
6xx: Eroare globală – cererea nu poate fi îndeplinită la orice server.
Mai jos se aduc careva exemple de răspunsuri dintre cele mai des
utilizate cu explicațiile de rigoare.
Provizorii 1xx:
Răspunsurile provizorii, cunoscute și ca informaționale, indică că
serverul contactat efectuează unele acțiuni suplimentare și nu are încă
un răspuns definitiv. Serverul transmite răspuns 1xx dacă se așteaptă ca
obținerea unui răspuns final va dura mai mult de 200 ms. Răspunsurile
provizorii nu sînt transmise în mod fiabil.
100 Trying
Răspunsul indică că cererea a fost primită de server dar sînt necesare
careva acțiuni suplimentare (de exemplu, consultarea bazei de date).
180 Ringing
Agentul utilizator a primit cererea IVITE și apelează utilizatorul
solicitat.
Succes 2xx:
Cererea a fost recepționată cu succes, este înțeleasă și acceptată.
220 OK
28
Cererea este procesată cu succes. Informațiile returnate în corpul
răspunsului depind de metoda utilizată în cerere.
Redirecționare 3xx:
Răspunsurile 3xx oferă informații despre noua locația a utilizatorului
sau despre serviciile alternative care ar putea fi în măsură să satisfacă
cererea.
301 Moved Permanently
Utilizatorul nu mai poate fi găsit la adresa indicată în cerere
(Request-URI) ca urmare clientul trebuie să încerce cu noua adresă
indicată în cîmpul antetului de contact. Solicitantul trebuie să
actualizeze orice directoare locale, agende şi cache-uri de localizare a
utilizatorului cu această nouă valoare. Pe viitor cererile vor fi
direcționate la adresa (adresele) nouă.
302 Moved Temporarily
Clientul solicitant trebuie să încerce din nou să transmită cererea dar
la altă adresă (adrese) indicată în cîmpul antetului Contact. Dacă durată
de validitate a noii adrese nu este arătată atunci ea este validă doar
pentru acest caz.
Eroare client 4xx:
Răspunsurile 4xx sînt definite ca un eșec al unei cereri la un anumit
server. Clientul nu trebuie să încerce din nou să transmită aceeași cerere
fără a o modifica.
400 Bad Request
Cererea nu poate fi înțeleasă ca urmare a sintaxei incorecte. În
răspuns se expun motivele mai în detaliu, de exemplu, ”este absent
cîmpul antetului Call-ID”.
401 Unauthorized
Cererea trebuie să conțină autentificarea utilizatorului. Acest răspuns
este emis de agenții utilizator server UAS și serverul Registrator, în
timp ce serverele proxy folosesc în acest sens răspunsul 407 (Proxy
autentificare necesară).
403 Forbidden
Serverul a înțeles cererea, dar refuză s-o îndeplinească. Autorizarea
nu va ajuta și cererea nu trebuie repetată.
405 Not Found
29
Serverul are informații definitive că utilizatorul nu există în
domeniul specificat în cerere.
408 Reguiest Timeout
Serverul nu ar reuși se producă un răspuns într-un timp
corespunzător, de exemplu dacă nu a reușit să determine locația
utilizatorului la timp. Clientul poate repeta cererea fără a o modifica
oricînd mai tîrziu.
415 Unssuported Media Type
Serverul refuză să deservească cererea, deoarece corpul mesajului
cererii este într-un format care nu este suportat de către server pentru
metoda solicitată.
480 Temporarily Unavailable
Sistemul terminal al celui apelat a fost contactat cu succes, dar
solicitantul nu este disponibil pentru moment (de exemplu, a activat
funcția "Nu deranjați", nu este logat, logat, dar într-o stare care
împiedică comunicarea cu el).
Eroare server 5xx:
Răspunsurile 5xx comunică despre eșecul serverului atunci cînd
serverul însăși a comis o eroare.
500 Server Internal Error
Serverul a întîmpinat o condiție neașteptată care a împiedicat
îndeplinirea cererii. Dacă această stare este temporară, serverul va
indica cînd clientul poate încerca din nou cererea folosind cîmpul
antetului Retry-After.
503 Service Unavailable
Serverul este temporar în incapacitatea de a procesa cererea din
cauza suprasolicitării sau lucrărilor de întreținere a serverului.
504 Server Time-out
Serverul nu a primit un răspuns în timp oportun de la un server
extern accesat în încercarea de a procesa cererea.
Eroare globală 6xx:
Răspunsurile 6xx indica faptul ca un server are informații definitive
cu privire la un anumit utilizator, nu doar pe cazul particular de adresă
URI indicată în cerere.
600 Busy Everywhere
30
Sistemul final solicitat a fost contactat cu succes, dar cel apelat este
ocupat și nu dorește să preia apelul în acest moment.
603 Decline
Sistemul final solicitat a fost contactat cu succes, dar utilizatorul în
mod explicit nu dorește sau nu poate participa.
Listă completă a răspunsurilor SIP la data scrierii acestei lucrări
(martie 2014) cu indicarea standardului RFC prin care tipul dat de
mesaj a fost adoptat este dată în tabelul 2.2.
Tabelul 2.2. Lista codurilor de răspunsuri SIP
Cod răspuns Descrierea textuală Referință
1xx Provisional
100 Trying [RFC3261]*
180 Ringing
181 Call Is Being Forwarded
182 Queued
183 Session Progress
199 Early Dialog Terminated [RFC6228]
2xx Successful
200 OK
202 Accepted (Deprecated) [RFC6665]
204 No Notification [RFC5839]
3xx Redirection
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
305 Use Proxy
380 Alternative Service
4xx Request Failure

400 Bad Request
31
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
410 Gone
412 Conditional Request Failed [RFC3903]
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Unsupported URI Scheme
417 Unknown Resource-Priority [RFC4412]
420 Bad Extension
421 Extension Required
422 Session Interval Too Small [RFC4028]
423 Interval Too Brief
424 Bad Location Information [RFC6442]
428 Use Identity Header [RFC4474]
429 Provide Referrer Identity [RFC3892]
430 Flow Failed [RFC5626]
433 Anonymity Disallowed [RFC5079]
436 Bad Identity-Info [RFC4474]
437 Unsupported Certificate [RFC4474]
438 Invalid Identity Header [RFC4474]
439 First Hop Lacks Outbound [RFC5626]
Support
440 Max-Breadth Exceeded [RFC5393]
469 Bad Info Package [RFC6086]
470 Consent Needed [RFC5360]
480 Temporarily Unavailable
481 Call/Transaction Does Not
Exist
32
482 Loop Detected
483 Too Many Hops
484 Address Incomplete
485 Ambiguous
486 Busy Here
487 Request Terminated
488 Not Acceptable Here
489 Bad Event [RFC6665]
491 Request Pending
493 Undecipherable
494 Security Agreement Required [RFC3329]
5xx Server Failure

500 Server Internal Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Server Time-out
505 Version Not Supported
513 Message Too Large
580 Precondition Failure [RFC3312]
6xx Global Failures

600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable
*)Pentru răspunsurile la care specificația nu este indicată se

subînțelege implicit standardul RFC3261 [2].
2.5. Anteturi SIP
Cîmpurile anteturilor SIP conțin informații detaliate despre cerere

sau răspuns. Acestea includ adresele de destinație și de inițiere a cererii,
33
precum și informațiile de rutare. Cîmpurile anteturilor sînt compuse din
nume și valoare care sînt separate prin două puncte (":"):
field-name: field-value
În cîmpul nume se scrie numele antetului. De exemplu dintre cele
din tabelul 2.3. Cîmpul valoare este text codificat în UTF-8 sau
combinație de expresii simbolice (token-uri), spațiu gol, caractere de
separare și șiruri de caractere închise în ghilimele. Cele mai multe
anteturi existente urmează un format comun pentru cîmpurile valori. Ele
sînt bazate pe secvența de perechi ”nume-parametru= valoare-
parametru”, care se divizează prin simbolul punct și virgulă ”;”:
field-name: field-value *(;parameter-name=parameter-value)
De exemplu:
Contact: <sip:alice@atlanta.com>;expires=3600
Parametrii cîmpului de antet SIP și valorile parametrilor trebuie să
fie documentate într-un RFC, în scopul de a fi înregistrate de către
autoritatea IANA. Această documentație trebuie să explice pe deplin
sintaxa, modul de utilizare si semantica parametrului sau a valorii
parametrului. Intenția acestei cerințe este de a asigura
interoperabilitatea între implementări independente și pentru a preveni
coliziunile de nume.
Cea mai mare parte din cîmpurile de antet SIP pot fi extinse prin
definirea de noi parametri. Noii parametri de antet SIP sînt înregistrați
de către IANA [4].
Anteturile SIP se împart în patru categorii: comune (cerere și
răspuns), de cerere, de răspuns și de conținut. Anteturile din categoria
comune, pot fi utilizate atît pentru cerere cît și pentru mesajele de
răspuns. Denumiri de anteturi comune, pentru cereri și pentru mesaje
răspuns sînt prezentate în tabelul 2.3.
Tabelul 2.3 Anteturi SIP [RFC 3261]

Cerere &
Cerere Răspuns
Răspuns
34
Accept Authorization Proxy-Authenticate
Accept-Encoding In-Reply-To Retry-After
Accept-Language Max-Forwards Server
Allow Priority Unsupported
Call-ID (i) Proxy-Authorization Warning
Contact (m) Proxy-Require WWW-Authenticate
Cseq Require
Date Route
Expires Subject (s)
From (f) User-agent
Record-Route
Timestamp
To (t)
Via (v)
Exemple de anteturi de conținut sînt: Content-encoding, Content-
length, Content-type.
Lista actualizată a anteturilor SIP poate fi consultată pe site-ul IANA
[4].
Protocolul SIP prevede un mecanism care permite reprezentarea într-
o formă prescurtată a numelui comun de cîmp de antet. Aceasta ar putea
fi utilă atunci cînd mesajele devin prea mari pentru a fi transmise cu
transportul de care dispune (de exemplu, mai mare de unitatea maximă
de transmisie (MTU) atunci cînd se utilizează protocolul UDP). Numele
de antet poate apărea în forme atît lungi și cît şi scurte în același mesaj.
35
Implementările trebuie să accepte ambele forme și lungi, și scurte ale
fiecărui nume de antet.
Tabelul 2.4 Forma abreviată a anteturilor

Nume antet (Formatul lung) Formatul Compact
Accept-Contact a
Allow-Event u
Call-ID i
Contact m
Content-Encoding e
Content-Length l
Content-Type c
Event o
From f
Identity y
Identity-Info n
Refer-To r
Referred-By b
Reject-Contact j
Request-Disposition d
Session-Expires x
Subject s
Supported k
To t
Via v
În cele ce urmează mai detaliat sînt expuse doar unele dintre cele
mai des utilizate anteturi. La necesitate descrierea anteturilor SIP se
poate consulta în specificațiile RFC. Numărul RFC-ului pentru fiecare
antet SIP este dat în registrul IANA [4].
Accept. Cîmpul antetului inclus în cerere (antet- cerere) poate fi
folosit pentru a specifica anumite tipuri de media care sînt acceptabile
pentru răspuns. Antetul Accept poate fi utilizat pentru a indica faptul că
cererea este limitată în mod specific la un set mic de tipuri dorite.
Exemplu: Accept: audio/*; q=0.2, audio/basic
36
Exemplul ar trebui interpretat ca "prefer audio / de bază, însă poţi
trimite orice tip audio dacă este cel mai disponibil, dar va urma o cădere
în calitate de 80%." Simbolul asterisc indică că se acceptă orice subtip
de media de tipul audio. Factorul de calitate q permite agentului
utilizator să indice gradul relativ de preferință pentru clasă media,
folosind scala de valori q de la 0 pînă la 1. Dacă parametrul de calitate
are valoarea 0, aceasta înseamnă că conținutul este `ne acceptabil"
pentru client. Valoarea implicită este q=1.
Alte exemple.
Accept: application/sdp Este implicit dacă nu este prezent antetul
Accept.
Accept. Text/* Se acceptă orice schemă de codare text.
Accept: application/h.245;q=0.1, application/sdp;q=0.9 Să se
utilizeze SDP dacă este posibil dacă nu atunci H.245.
Accept –Language. Cîmpul de antet Accept-Language este utilizat
în cereri pentru a indica limbile preferate pentru expunerile de motive
sau în descrierea sesiunii, sau în răspunsuri de stare ca descriere în
corpul mesajului. Dacă antetul Accept-Language nu este prezent atunci
serverul trebuie să asume că toate limbile sînt acceptabile pentru client.
Exemplu.
Accept-Language: ro, en-gb;q=0.8, en;q=0.7
Allow. În cîmpul antetului Allow se listează setul de metode care
sînt susținute de UA care generează mesajul. Includerea antetului Allow
în răspunsurile la cereri, cu excepția metodei OPTIONS, reduce
numărul de mesaje necesare.
Exemplu:
Allow: IVITE, ACK, OPTIONS, CANCEL, BYE
Call-ID. Cîmpul de antet Call-ID este obligatoriu în toate cererile și
răspunsuri SIP. Acest antet este folosit pentru a identifica în mod unic
un apel între doi agenți utilizatori. Call-ID-ul trebuie să fie un
identificator aleatoriu criptografic. Caracterul aleatoriu al Call-ID
împiedică o terță parte să ghicească întîmplător sau intenționat Call-ID-
ul și să prezinte cereri false. Call-ID este întotdeauna creat de agentul
utilizator și nu este modificat de careva server.
Forma compactă a cîmpului antetului Call-ID-ul este i.
37
Exemple:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4
Contact. Valoare cîmpului antetului Contact oferă un URI al cărui
semnificație depinde de tipul de cerere sau de răspuns în care este
inclus. O valoare de cîmp antet poate conține un nume de afișare, un
URI cu parametri și parametri de antet. În cazul în care valoarea
cîmpului antet conține un nume de afișare, URI și toți parametrii URI se
includ între "<" și ">". În cazul în care aceste simboluri "<" și ">" nu
sînt prezente, toți parametrii după URI sînt parametri de antet, dar nu
parametri URI.
Există doi parametri suplimentari definiți pentru utilizare în
cîmpurile antetului Contact: q și expires. Ele se plasează la sfârșitul
URI și se separă prin virgulă. Parametrul valoare q este utilizat pentru a
indica preferința relativă, reprezentată de un număr zecimal în intervalul
0 pînă la 1. Parametrul expires indică cît timp URI este valabil și este
folosit doar la înregistrări. Parametrul conține un număr întreg de
secunde sau o dată în formă SIP.
Forma compactă a cîmpului antetului Contact este m (de la
"moved").
Exemplu:
Contact: "Mr. Watson" <sip:watson@worcester.bell-elephone.com>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
Cseq. Cîmpul de antet Cseq (Comand Sequence - Secvență
comandă) este necesar în fiecare cerere și conține un număr de secvență
urmat de numele cererii. Numărul de secvență începe cu orice valoare
arbitrară care crește cu 1 pentru fiecare cerere și trebuie să fie un întreg
fără semn în diapazonul de la 1 pînă la 232 . Antetul CSeq servește la
comanda operațiunilor într-un dialog, pentru a oferi un mijloc de a
identifica în mod unic tranzacția și de a diferenția cererea nouă de
cerere retransmisă. Antetul Cseq al răspunsului la o cerere este copia
valorii cîmpului antetului CSeq din cererea respectivă.
Exemplu:
38
CSeq: 4711 INVITE
Date. Cîmpul antet Date este folosit pentru a transmite data la care
cererea sau răspunsul este trimis (zona de timp GMT). Acest antet este
utilizat atunci cînd dispozitivele derivă ora locală și data din rețea.
Dispozitivul la înregistrare în rețea primește antetul Date în răspuns.
Acest lucru permite agentului utilizator să stabilească în mod automat
data și ora lor. Acest lucru este utilizat, de exemplu, în telefoanele
mobile.
Exemplu:
Date: Sat, 15 Mar 2014 23:29:00 GMT
From. Antetul From indică inițiatorul cererii. Acest cîmp trebuie să
fie prezent în toate cererile SIP și este pur și simplu copiat în
răspunsurile SIP. Antetul From poate conține un nume de afișare
opțional între ghilimele duble, urmat de URI expeditorului cererii (între
semnele "<>''). Sistemul folosește numele de afișare Anonymous
(Anonim, fără ghilimele), în cazul în care identitatea clientului trebuie
să rămînă ascunsă. Antetul poate conține și un tag (etichetă) folosit
pentru a identifica un anumit apel. Tag-ul este un număr aleatoriu
criptografic cu cel puțin 32 de biți de randomizare, care se adaugă la
anteturile From și To pentru a identifica în mod unic un dialog.
Forma compactă a cîmpului antetului From este f.
Exemple:
From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s
From:< sip:+37338551212@gatewaymd2.md>;tag=887s
f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
To. Cîmpul antetului To este folosit pentru a indica destinatarul
cererii și este necesar în fiecare mesaj SIP. Orice răspuns generat de un
UA va conține cîmpul de antet To cu adăugarea unui tag. Valoarea tag-
ului antetului To este folosită alături de tag-ul antetului From și
valoarea Call-ID, pentru a identifica în mod unic un dialog SIP.
Forma compactă a cîmpului antetului To este t.
Exemple:
To: Helpdesk <sip:helpdesk@company.com>;tag=287447
t: <sip:+37338555212@server.phone2net.com>
39
Via. Scopul principal al antetului Via este de a înregistra ruta urmată
de cerere, permițînd astfel SIP proxy intermediare să transmită
răspunsurile SIP înapoi, urmînd aceeași cale. O UA generînd o cerere
înregistrează propria sa adresă în cîmpul antetului Via. În timp ce
ordinea apariției pentru majoritatea anteturilor SIP nu este importantă,
pentru antetul Via ea este semnificativă, deoarece este folosită pentru
rutarea răspunsurilor. Un proxy îndrumînd cererea adaugă în partea de
sus a listei de cîmpuri antet Via un cîmp de antet Via care conține
propria lui adresă. Proxy include și un parametru specific branch care
servește ca un identificator de transfer ramificat ( cererea transmisă în
paralel pe mai multe direcții de plecare) și este utilizat de proxy pentru
a detecta bucle de rutare. Un proxy sau UA generînd un răspuns la o
cerere copie toate cîmpurile de antet Via de la cerere și le include în
răspuns păstrînd ordinea. Apoi trimite răspunsul la adresa specificată în
partea de sus a cîmpului de antet Via. Un proxy cînd primește un
răspuns verifică dacă adresa din partea de sus a cîmpului de antet Via
corespunde adresei lui și o șterge.
Cîmpurile antetului Via conțin numele protocolului, numărul
versiunii și protocolul de transport (SIP/2.0/UDP, SIP/2.0/TCP.), adresa
URI și posibil numărul de port și careva parametri, cum ar fi received,
rport, branch, maddr și ttl. Parametrii sînt necesari în unele cazuri
speciale, de exemplu, dacă pe ruta mesajului sînt NAT (translator de
adresă rețea) sau firewall proxy.
Forma compactă a cîmpului antetului Via este v.
Exemple:
Via: SIP/2.0/UDP 100.101.102.103
;branch=z9hG4bK776a
Via: SIP/2.0/UDP pchome101@aol.com:5060; branch=
z9hG4bK713a2
Valoarea parametrului de ramificație branch este identificatorul
tranzacției SIP inițiată de elementul care introduce antetul Via. Pentru
implementări compatibile cu specificația RFC 3261 [2], valoarea
parametrului de branch trebuie să înceapă cu cookie-ul magic din 7
simboluri "z9hG4bK". Aceste cifre indică faptul că mesajul a fost
40
prelucrate cu ajutorul proceselor și procedurilor definite în RFC 3261
SIP 2.0.
Max-Forwards. Cîmpul antetului Max-Forwards este folosit pentru
a indica numărul maxim de hop-uri pentru transmiterea cererii SIP.
Valoarea cîmpului antetului este un număr întreg din intervalul 0-255
decrementată de fiecare proxy și arată de cîte ori este permisă
redirecționarea cererii. Valoarea inițială recomandată este de 70.
Exemplu:
Max-Forwards: 6
2.6. Localizarea utilizatorilor după adresa SIP
Într-o rețea SIP destinația este determinată după identificatorul

uniform de resurse URI (Uniform Resource Indentifier). Identificatorul
uniform de resurse (URI) este o secvență compactă de caractere
alfanumerice care identifică o resursă abstractă sau fizică. Deci un SIP
URI identifică o resursă de comunicare. La fel ca toate URI-urile, SIP
URI-urile pot fi plasate în pagini web, mesaje e-mail, sau literatură
tipărită. Acestea conțin informații suficiente pentru a iniția și menține o
sesiune de comunicare cu resursa. Ca exemple de resurse de
comunicații pot servi următoarele:
 un utilizator al unui serviciu on-line;
 un apel pe un telefon multi-line;
 o cutie poștală pe un sistem de mesagerie;
 un număr PSTN, la un serviciu de gateway;
 un grup (cum ar fi "vînzări" sau "helpdesk"), într-o
organizație.
Un SIP URI are două formate majore, o formă similară cu o adresă
e-mail sau alta ca un număr de telefon:
 Sintaxa generală pentru adresa SIP în format de e-mail este
user @ host. Partea de utilizator este un nume de utilizator
deseori același ca adresa lui de e-mail. Partea gazdă este un
nume de domeniu care poate fi rezolvată la o adresă IP
folosind sistemul DNS sau direct o adresă de rețea numerică
IP4 sau IP6.
41
 Formatul general al unui număr de telefon în forma de un SIP
URI este phone-number @host;user=phone. Partea gazdă
indica un gateway sau server care poate ajunge la acest
număr de telefon. Parametrul „uzer=phone” indică faptul că
porțiunea de utilizator a URI (partea din stînga semnului @)
trebuie să fie tratată ca un tel URI. Astfel "sip:+373
38555000@domain.com;user=phone" ar trebui să fie tratat ca
tel:+37338555000.
Adresele URI sînt utilizate în mesajele SIP pentru a indica
inițiatorul, destinația curentă și destinatarul final precum și pentru a
specifica adresele de redirecționare.
2.7. Descrierea sesiunii în corpul mesajului
La inițierea sesiunilor VoIP, de teleconferință multimedia sau de

video streaming apare necesitatea de a transmite detalii referitoare la
tipul media, adrese de transport, precum și capacitățile gazdelor
participanților. Aceste tipuri de informații se includ în corpul mesajului
SIP. În cadrul dialogului ofertă/răspuns agenții utilizatori SIP folosesc
protocolul descriere sesiune SDP pentru schimbul de informații despre
sesiune și capabilitățile sale. După ce UAC și UAS au negociat
parametrii sesiunii ea poate fi stabilită.
Descrierea sesiunii în SDP este în întregime textuală cu caractere
ISO 10646 în codificarea UTF-8. Numele de cîmpuri și atribute SDP
folosesc numai subsetul US-ASCII al UTF-8.
Descriere a sesiunii SDP constă dintr-un număr de linii de text de
forma:
<tip> = <value>
unde <tip> este un caracter și
<valoare> este text structurat al cărui format depinde de <tip>.
Protocolul SDP oferă trei categorii de descriere:
 descrieri la nivel de sesiune,
 descrieri de timp,
 descrieri tip media.
42
Unele linii în descriere sînt obligatorii pe cînd altele - opționale, însă
toate trebuie să apară exact în ordinea dată de standardul RFC 4566
(respectarea acestei ordini simplifică detectarea erorilor). Liniile
opționale sînt marcate cu asterix "*". Mai jos se prezintă descriptorii
care sînt admiși.
Descrieri la nivel de sesiune:
 v= (protocol version). Identifică versiunea de SDP. Numărul
versiunii este v=0.
 o= (originator and session identifier). Identifică inițiatorul
sesiunii și sesiunea în sine. Formatul pentru acest descriptor
este:
o=<username><session id><version><network type><address
type><address>
Numele de utilizator este un singur cuvânt (nu poate conține spații) și
este ID-ul utilizatorului inițiator al sesiunii. Parametrului <versiune>
este un număr de versiune pentru sesiunea dată. Pentru <network type>
este folosit "IN" pentru a indica Internetul, dar sînt posibile și alte tipuri
pe viitor (de exemplu, "IMS"). Tipul adresei denotă versiunea de IP
folosită fie IPv4 sau IPv6. Adresa este a gazdei care a inițiat sesiunea.
 s= (session name). Este numele textual al sesiunii.
 i=* (session information). Acest descriptor furnizează
informații suplimentare despre sesiune. Este prevăzut pentru utilizare de
către participanții la sesiune în combinație cu numele de sesiune.
 u=* (URI of description). Descrierea identificatorului
uniform de resurse (URI). Pentru descrierea sesiunii SIP este permisă
utilizarea nu mai mult de un cîmp URI.
 e=* (email address). Descriptorul permite inițiatorului
sesiunii să furnizeze o adresă de e-mail, astfel încît participanții îl vor
putea contacta referitor la sesiune. Pentru fiecare sesiune pot fi furnizate
mai multe adrese.
 p=* (phone number). Similar cu adresa de e-mail, numărul de
telefon poate fi folosit de participanți pentru apela în cadrul sesiunii.
Acest lucru, ca și adresa de e-mail are sens în cazul unor conferințe
multimedia și nu vor fi utilizate pentru comunicații de voce simple.
 c=* (connection information). Informațiile despre conexiune
43
se prezintă în următorul format:
c=<network type><address type><connection address>
Tipul de rețea este aceeași ca și în descriptorul ”o”. Tipul de adresă fie
o adresă IPv4 sau IPv6, iar adresa de conexiune identifica adresa IP
reală care poate fi utilizată pentru conexiuni.
 b=* (bandwidth information lines). Identifică
lățimea de bandă necesara pentru sesiune. Acesta este compus din doi
parametri după cum se arată aici:
b=< bwtype >:<bandwidth >
Unde <bwtype> este un modificator alfanumeric care determină
semnificația cifrei <bandwidth>. Modificatorul poate fi una dintre cele
două valori: fie "CT" - total pentru conferință sau "AS" pentru aplicații
specifice. CT semnifică lățimea de bandă totală pe toate site-urile și
toate media utilizate pentru sesiune. AS denotă lățime de bandă la un
singur site cu o singură aplicație. Valoarea numerică a lățimii de bandă
este exprimată în kilobytes pe secundă.
Descrieri de timp:
 t= (time the session is active). Linia ”t=” specifica pornirea și
oprirea sesiunii. Formatul este: t=<start-time> <stop-time>. Primul
sub-cîmp determină timpul de start iar al doilea sub-cîmp timpul de
oprire a sesiunii. Valorile sînt cifre zecimale exprimate în secunde în
corespundere cu NTP (Network Time Protocol) cu începere din anul
1900 [RFC 5905].
Dacă <stop-time> este setat la zero, atunci durata sesiunii nu este
limitată, deși ea nu va deveni activă pînă după timpul marcat de <start-
time>. Dacă <start-time> este, de asemenea, setat la zero atunci
sesiunea este considerată ca fiind permanentă.
 r=* (zero or more repeat times). Acest cîmp este utilizat pentru a
indica cînd sesiunea se va repeta din nou. Indică deplasarea de la timpul
de pornire (adică în cît timp după ora de start sesiunea va fi repetată).
Formatul pentru cîmpul timp repetare este:
r=<repeat interval><active duration><list of offsets from start time>
Descriptorul indică intervalul de repetare(de exemplu, zilnic), durata
activă a sesiunii la fiecare apariție și deplasarea, prima și ultima delta în
secunde de la ora de începere pentru fiecare dintre sesiunile repetate.
44
Standardul pentru prescurtare permite prezentarea timpului nu doar în
secunde dar și cum se arată mai jos:
r=7d 1h 0 25h
În exemplu, sesiunea se repetă fiecare săptămînă, durata e de 1 oră,
primul offset 0 pentru sesiunea actuală, iar al doilea de 25 ore.
 z=* (time zone adjustments). Acesta permite participanților
să facă ajustări la fusul orar.
Descrieri la nivel de sesiune (continuare):
 k=* (encryption key). Dacă este folosită criptarea atunci acest
cîmp identifica cheile de criptare necesare pentru a citi sarcina utilă.
Standardele nu identifica mecanismul exact pentru schimbul de chei, ci
mai degrabă un vehicul prin care cheile de criptare ar putea fi
schimbate. Formatul acestui descriptor este:
k=<method><key parameter>
 a=* (zero or more session attribute lines – zero sau mai multe
linii cu atribute sesiune). Atributele sînt folosite ca mijloc de extindere a
SDP pentru alte aplicații. De exemplu, dacă o anumită aplicație necesită
un atribut care nu este definit de IETF, atunci aplicația dată poate fi
numită în cîmpul acestui atribut. Orice entitate care recepționează și nu
înțelege acest atribut pur și simplu îl ignoră. Cîmpurile atributelor "de
nivel de sesiune" transmit informații suplimentare care se aplică la
întreaga sesiune dar nu la careva flux media în mod individual.
Descrieri tip media. Descrierea media furnizează informații cu
privire la media specifice pentru o sesiune.
 m= (media name and transport address). Descrierea media
furnizează informații cu privire la fluxurile de media specifice pentru o
sesiune. Formatul pentru descrierea media este după cum urmează:
m=<media><port><proto><media formats>
Subcîmpul <media> descrie tipul de media. În prezent sunt definite
următoarele tipuri de media: "video", "audio", "text", "aplicație" și
"mesaj". Listă poate fi extinsă în viitor.
Subcîmpul <port> este numărul portului de transport la care fluxul
media se transmite. Semnificația portului de transport depinde de
rețeaua utilizată în conformitate cu cîmpul "c =" în cauză și de
protocolul de transport definit în următorul subcîmp <proto>. În
45
prezent există două valori acceptate pentru protocolul de transport: RTP
/ AVP, pentru Real-Time Protocol folosind profilul Audio Video sau
UDP.
Subcîmpul <media formats> identifică formatele media care trebuie
folosite pentru fiecare dintre tipurile de media definite. Formatul media
se identifică printr-un număr care corespunde unui profil de identificare
format. Numerele sînt apoi folosite pentru a indexa careva atribute care
furnizează detalii suplimentare pentru formatul media. Descrierea
media poate fi constituită din unul sau mai multe atribute ("a ="
cîmpuri). Acestea sînt denumite "atribute la nivel de media" și adăuga
informații despre fluxul de media.
De exemplu:
m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2
În exemplul dat se indică că sesiunea va sprijini media de tip audio pe
portul 49232, protocolul de transport utilizat este RTP, profilul audio
video RTP/AVP cu număr de identificare 98 (dinamic). Atributul
furnizează detalii suplimentare în ceea ce privește formatul audio. În
acest exemplu, profile-ul dinamic 98, codare liniară pe 16 biți, rata de
eșantionare de 16000 Hz și 2 canale, deci stereo.
 i=* (media title - titlul media). Pentru definirea fiecărui tip de
media poate fi utilizat un singur cîmp "i =". Cîmpurile acestea
sînt destinate etichetării fluxurilor de media. Se folosesc mai
des atunci cînd sesiunea are mai multe fluxuri media distincte
de același tip de media.
 c=* (connection information -- optional if included at
session level). Informații despre conexiune. Este optional dacă
descriptorul "c =" este inclus la nivelul de sesiune. O descriere sesiune
conține un singur cîmp "c =" la nivel de sesiune și cîmp(uri)
suplimentar(e) "c =" pentru fiecare descriere a media.
 b=* (zero or more bandwidth information lines). Acest cîmp
opțional denotă lățimea de bandă propusă pentru a fi utilizată de
media.
 k=* (encryption key). Cîmpul cheie criptare este permis înainte
de prima intrare media (în cazul în care se aplică pentru toate
46
media în cadrul sesiunii) sau pentru fiecare intrare media în
parte, după caz. Formatul de chei și utilizarea lor sînt în afara
scopului acestei lucrări.
 a=* (zero or more media attribute lines). Descrierea media de
atribute (cîmpuri "a ="), care sînt media specifice. Spre
exemplu atributele a=sendonly și a=recvonly semnifică că
dispozitivul ar trebui să fie pornit în modul doar trimitere sau
respectiv doar recepție.
Un exemplu de descriere sesiune de protocolul SDP este [RFC4566]:
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 8 ( 8 profile static, PCM A-law)
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000 (99 profile dinamic, codare
video h.263 versiunea 1998, rata eșantionare 90000 Hz)
2.8. Exemplu de stabilire a unei sesiuni SIP
Exemplul adus arată funcțiile de bază ale SIP: localizarea unui punct
terminal, solicitarea sesiunii, negocierea parametrilor de sesiune pentru
stabilirea sesiunii și terminarea sesiunii stabilite.
Figura 2.2 prezintă un exemplu tipic de schimb de mesaje între doi
utilizatori, Alice și Bob [2]. Fiecare mesaj este marcat prin litera ”M”
cu un număr de trimitere la text. De asemenea, se arată două servere
SIP proxy care acționează în numele Alice și Bob pentru a facilita
stabilirea sesiunii.
47
Alice's atlanta.com biloxi.com Bob's
softphone proxy proxy SIP Phone
| | | |
| M1 INVITE | | |
|--------------->| M3 INVITE | |
| M2 100 Trying |--------------->| M5 INVITE |
|<---------------| M4 100 Trying |--------------->|
| |<-------------- | M6 180 Ringing |
| | M7 180 Ringing |<---------------|
| M8 180 Ringing |<---------------| M9 200 OK |
|<---------------| M10 200 OK |<---------------|
| M11 200 OK |<---------------| |
|<---------------| | |
| M12 ACK |
|------------------------------------------------->|
| Media Session |
|<================================================>|
| M13 BYE |
|<-------------------------------------------------|
| M14 200 OK |
|------------------------------------------------->|
| |
Fig. 2.2. Exemplu de stabilire a unei sesiuni SIP
Solicitanta este Alice care apelează telefonul SIP al lui Bob utilizînd
SIP URI sip:bob@biloxi.com , unde biloxi.com este domeniul
furnizorului de servicii SIP a lui Bob. Respectiv adresa SIP URI a
Alicei este sip:alice@atlanta.com.
M1 INVITE Alice -> atlanta.com proxy
INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP nu se prezintă)
48
În acest exemplu, tranzacția începe cu cererea INVITE trimisă de
softphone-ul Alicei și adresată lui Bob conform SIP URI. Cererea
conține o serie de anteturi. Cîmpurile anteturilor sînt atribute care
furnizează informații suplimentare despre mesaj. Cererea INVITE de
mai sus include următoarele anteturi:
Via conține adresa (pc33.atlanta.com), la care Alice se așteaptă să
primească răspunsuri la această cerere. Antetul conține și un parametru
branch care identifică această tranzacție.
To cu un nume de afișare (Bob) și adresa SIP URI (sip:
bob@biloxi.com), spre care cererea a fost direcționată inițial.
From conține, de asemenea, un nume de afișare (Alice) și adresa
SIP a solicitantului (sip: alice@atlanta.com). Cîmpul de antet include și
un tag (etichetă) care conține un șir aleator (1928301774), care a fost
adăugat la URI de softphone. Acesta este utilizat pentru identificarea
dialogului.
Call-ID conține un identificator unic global al apelului generat
ca o combinație dintre un șir aleatoriu și numele de gazdă a softphone-
lui sau adresei IP.
CSeq sau Secvența de comanda conține un număr întreg și
denumirea cererii. Numărul CSeq este incrementat de fiecare nouă
cerere din cadrul dialogului și este un număr de ordine tradițional.
Contact conține un URI SIP care reprezintă o rută directă pentru
a contacta Alice compus din nume de utilizator și nume de domeniu.
Astfel viitoarele cereri spre Alice trebuie să sosească la adresa indicată.
Max-Forwards servește pentru a limita numărul de hop-uri ale
cereri pe care le poate face pe drumul spre destinație. Acesta constă
dintr-un număr întreg, care este decrementat cu unu la fiecare hop.
Content-Type conține o descriere a corpului mesajului (nu se
prezentă).
Content-Length conține numărul de octeți din corpul mesajului.
Corpul mesajului descrie sesiunea utilizînd protocolul SDP și este
similar celui din exemplul de mai sus. În scopul optimizării expunerii
aici este omis.
M2 100 Trying atlanta.com proxy -> Alice
SIP/2.0 100 Trying
49
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
Serverul proxy primește cererea SIP de la UAC și o transmite

mai departe din numele solicitantului, iar în sens opus trimite
softphone-ului Alicei răspunsul 100 Trying. Răspunsul 100 Trying
indică faptul că invitația a fost primită și că proxy-ul lucrează în numele
ei pentru a ruta invitația către destinație. Acest răspuns conține aceleași
cîmpuri ale anteturilor To, From, Call-ID, CSeq și Via cu parametrul
branche ca și în M1 INVITE. Aceasta permite softphone-lui Alice să
coreleze răspunsul cu INVITE.
M3 INVITE atlanta.com proxy -> biloxi.com proxy
INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.1
Max-Forwards: 69
CSeq: 314159 INVITE
Content-Length: 142
M4 100 Trying biloxi.com proxy -> atlanta.com proxy
SIP/2.0 100 Trying

;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
50
Serverul proxy biloxi.com primește IVITE și răspunde înapoi
serverului proxy atlanta.com cu mesajul 100 Trying pentru a indica
faptul că a primit INVITE și acum această cerere se procesează.
Serverul proxy consultă baza de date a serviciului de localizare unde
este înregistrată adresa IP curentă a lui Bob.
M5 INVITE biloxi.com proxy -> Bob
INVITE sip:bob@192.0.2.4 SIP/2.0

Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
;received=192.0.2.2
;received=192.0.2.1
Max-Forwards: 68
CSeq: 314159 INVITE
Content-Length: 142
Serverul proxy biloxi.com adaugă un alt cîmp de antet Via cu

propria adresă și transmite cererea INVITE la telefonul SIP a lui Bob.
M6 180 Ringing Bob -> biloxi.com proxy
SIP/2.0 180 Ringing

;received=192.0.2.3
;received=192.0.2.2
;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: 0
Telefonul SIP al lui Bob primește INVITE și îl alertă pe Bob

despre primirea apelului de la Alice. Telefonul lui Bob sună și pentru
informare transmite înapoi prin cele două proxy-uri în sens opus
răspunsul 180 Ringing.
51
M7 180 Ringing biloxi.com proxy -> atlanta.com proxy
SIP/2.0 180 Ringing

;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
Fiecare proxy utilizează cîmpul antetului Via pentru a determina

direcția în care să trimită răspunsul și elimină propria adresa din vîrf.
Toate proxy care au retransmis cererea INVITE trebuie să primească în
direcția opusă mesajele de răspuns la aceasta cerere.
M8 180 Ringing atlanta.com proxy -> Alice
SIP/2.0 180 Ringing

;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
După primirea răspunsului 180 Ringing softphon-ul Alicei

afișează un mesaj pe ecranul PC sau se generează semnalul de revers
apel.
M9 200 OK Bob -> biloxi.com proxy
SIP/2.0 200 OK
;received=192.0.2.3
;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
52
Content-Length: 131
(Bob's SDP nu se prezintă)
După ce Bob ridică receptorul telefonul SIP al lui trimite

răspunsul 200 OK, prin care se informează clientul că cel solicitat a
răspuns la apel. Acest răspuns conține în corpul mesajului descrierea
tipului de sesiune (în protocolul SDP care aici nu se prezintă) care se
dorește să se stabilească cu UAC. Ca urmare, există un schimb în două
faze a mesajelor SDP: inițial de la softphonul Alice trimis spre SIP
telefonul lui Bob în corpul cererii INVITE și apoi prin răspunsul 200
OK în direcție inversă. Datorită acestui mecanism bazat pe un simplu
model de ofertă/răspuns se efectuează negocierea capabilităților
agenților utilizatori ai dialogului. Cîmpurile anteturilor Via, To, From,
Call-ID și Cseq ale acestui răspuns sînt copiate din respectivele cîmpuri
ale cererii INVITE. Telefon SIP a lui Bob a adăugat un tag în cîmpul
antetului To. Această etichetă va fi inclusă de către ambele terminale
ale dialogului în toate cererile și răspunsuri viitoare în cadrul acestui
apel. Cîmpul antetului Contact conține un URI, la care Bob poate fi
contactat în direct de la telefonul lui SIP. Anteturile Content-Type și
Content-Length se referă la corpul mesajului (nu se prezintă) care
conține informații în SDP despre tipul media de la Bob.
M10 200 OK biloxi.com proxy -> atlanta.com proxy
SIP/2.0 200 OK
;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 131
M11 200 OK atlanta.com proxy -> Alice
SIP/2.0 200 OK
53
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 131
Răspunsul 200 (OK) este direcționat înapoi prin cele două proxy-uri și
este primit de softphone lui Alice, care apoi se oprește tonul de revers
apel și indică faptul că a fost răspuns la apel.
M12 ACK Alice -> Bob
ACK sip:bob@192.0.2.4 SIP/2.0

Max-Forwards: 70
CSeq: 314159 ACK
Content-Length: 0
Softphonul Alicei trimite un mesaj de confirmare ACK pentru

telefonul SIP al lui Bob ce confirma primirea răspunsului final (200
OK). În acest exemplu, mesajul ACK este trimis direct de la
softphoneul Alicei la SIP telefonul lui Bob ocolind cele două proxy-uri.
Acest lucru se întâmplă deoarece terminalele au aflat reciproc adresele
din cîmpule antetului Contact prin schimbul de mesaje INVITE/200
OK, care nu erau cunoscute la momentul trimiterii INVITE.
În așa mod sesiunea media între Alice și Bob este stabilită. Agenții
utilizatori trimit pachete media în formatul în care au fost de acord prin
schimbul de SDP. În general, pachetele media cap la cap au o cale
diferită de cea a mesajelor de semnalizare SIP.
M13 BYE Bob -> Alice
BYE sip:alice@pc33.atlanta.com SIP/2.0

Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;tag=1928301774
CSeq: 231 BYE
Content-Length: 0
54
Sesiunea se încheie după ce Bob închide primul telefonul. Se
observă că telefonul SIP al lui Bob menține propriul spațiu de
numerotare CSeq, care în acest exemplu, începe cu 231. Deoarece
cererea M13 Bye se transmite de la Bob adresele URI în anteturile To și
From precum și tag-urile au fost schimbate.
M14 200 OK Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;tag=1928301774
CSeq: 231 BYE
Content-Length: 0
Alice confirmă primirea BYE prin răspunsul 200 OK, care termină
sesiunea. Trimeterea mesajului de confirmare ACK în acest caz nu se
mai cere.
ANEXĂ
Exercițiu. Pentru următoarele fluxuri:
a) Determinați cine trimite și cine primește fiecare mesaj.
b) Desenați diagrama fluxului de apel.
d) Determinați rolul fiecărui flux.
Mesajul 1
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.atlanta.example.com:5061
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:alice@client.atlanta.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: ...
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=
c=IN IP4 client.atlanta.example.com
55
t=0 0
a=rtpmap:0 PCMU/8000
Mesajul 2
SIP/2.0 180 Ringing
;received=192.0.2.103
To: Bob <sips:bob@biloxi.example.com>;tag=23431
CSeq: 1 INVITE
Contact: <sips:b54gh42f5@biloxi.example.com>
Content-Length: 0
Mesagul 3
SIP/2.0 200 OK
;received=192.0.2.103
CSeq: 1 INVITE
Contact: <sips:b54gh42f5@biloxi.example.com>
Supported: replaces, gruu
Content-Length: ...
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=
c=IN IP4 client.biloxi.example.com
t=0 0
Mesagul 4
ACK sips:b54gh42f5@biloxi.example.com SIP/2.0
;branch=z9hG4bK74bfL
Max-Forwards: 70
CSeq: 1 ACK
Content-Length: 0
Mesagul 5
INVITE sips:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061
;branch=z9hG4bKnashds
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=23431
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
CSeq: 1024 INVITE
56
Contact: <sips:bob-Mixer@client.biloxi.example.com>;isfocus
Content-Length: ...
v=0
s=
t=0 0
Mesagul 6
SIP/2.0 200 OK
;branch=z9hG4bKnashds7
;received=192.0.2.113
CSeq: 1024 INVITE
Contact: <sips:alice@client.atlanta.example.com>
Supported: replaces
Content-Length: ...
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=
c=IN IP4 client.atlanta.example.com
t=0 0
Mesagul 7
ACK sips:alice@client.atlanta.example.com SIP/2.0
;branch=z9hG4bKnash3G
Max-Forwards: 70
CSeq: 1024 ACK
Content-Length: 0
Mesagul 8
INVITE sips:carol@chicago.example.com SIP/2.0
;branch=z9hG4bKnashJfd
Max-Forwards: 70
To: Carol <sips:carol@chicago.example.com>
Call-ID: sdjfdjfskdf@biloxi.example.com
CSeq: 42 INVITE
Contact: <sips:bob-Mixer@client.biloxi.example.com>;isfocus
57
Content-Length: ...
v=0
s=
t=0 0
Mesagul 9
SIP/2.0 200 OK
;received=192.0.2.113
To: Carol <sips:carol@chicago.example.com>;tag=341313
CSeq: 42 INVITE
Contact: <sips:carol@client.chicago.example.com>
Supported: replaces
Content-Length: 0
Mesagul 10
SIP/2.0 200 OK
;received=192.0.2.113
CSeq: 42 INVITE
Contact: <sips:carol@client.chicago.example.com>
Supported: replaces
Content-Length: ...
v=0
o=carol 2890844922 2890844922 IN IP4 client.chicago.example.com
s=
c=IN IP4 client.chicago.example.com
t=0 0
Mesagul 11
ACK sips:carol@client.chicago.example.com SIP/2.0
;branch=z9hG4bKnash431
Max-Forwards: 70
CSeq: 42 ACK
Content-Length: 0
58
BIBLIOGRAFIE
1. ITU-T Recommendation Y.2001 (12/2004) - General overview
of NGN (http://www.itu.int), 2005.
2. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, “SIP: session
initiation protocol,” RFC 3261, Internet Engineering Task
Force, June 2002.
3. M. Handley, V. Jacobson, c. Perkins. ” SDP: session
description protocol.,” RFC 4566, Internet Engineering Task
Force, July 2006.
4. http://www.iana.org/assignments/sip-parameters/sip-
parameters.xhtml#sip-parameters-12
CUPRINS
Introducere....................................................................................3
1. Prezentare generală a NGN..............................................5
1.1. Definiția NGN...........................................................5
1.2. Arhitectura NGN.......................................................7
1.2.1. Nivelul transport și comutație.........................8
1.2.2. Nivelul control rețea și semnalizare..............11
1.2.3. Nivelul servicii, control servicii și aplicații 11
1.3. Protocoale de semnalizare în NGN..........................12
2. Protocolul de inițiere a sesiunii.......................................15
2.1. Componentele funcționale ale rețelei SIP................16
2.2. Structura mesajelor SIP............................................17
2.3. Cereri SIP.................................................................19
2.4. Răspunsuri SIP.........................................................24
2.5. Anteturi SIP.............................................................30
2.6. Localizarea utilizatorilor după adresa SIP..............38
2.7. Descrierea sesiunii în corpul mesajului..................39
2.8. Exemplu de stabilire a unei sesiuni SIP..................44
Anexă.............................................................................52
Bibliografie....................................................................56
59
Aprobat
prin Ordinul Ministerului Tehnologiilor
Informaţionale şi Comunicaţiilor
nr.15 din 04 martie 2010
PLANUL NAŢIONAL DE NUMEROTARE*
I. DISPOZIŢII GENERALE
1. Planul Naţional de Numerotare (PNN) telefonică al Republicii Moldova, denumit în

continuare PNN, este elaborat în temeiul Legii comunicaţiilor electronice, nr.241 din 15.11.2007
şi stabileşte structura, formatul şi destinaţia resurselor de numerotare utilizate în Republica
Moldova pentru furnizarea serviciilor de comunicaţii electronice prin intermediul reţelelor
publice de comunicaţii electronice.
2. Resursele de numerotare din PNN, denumite în continuare resursele de numerotare, sînt
atribuite de către autoritatea de reglementare în conformitate cu reglementările în vigoare.
3. Structura resurselor de numerotare din PNN este stabilită în conformitate cu
Recomandarea E.164 a Sectorului de standardizare al Uniunii Internaţionale de Telecomunicaţii
(UIT) şi deciziile/recomandările Conferinţei Europene a Administraţiilor de Poştă şi
Telecomunicaţii (CEPT).
4. Utilizarea resurselor de numerotare din PNN este permisă doar în baza licenţelor de
utilizare a resurselor de numerotare eliberate furnizorilor de reţele şi/sau servicii publice de
comunicaţii electronice autorizaţi în condiţiile legislaţiei în vigoare, cu excepţia numerelor
naţionale scurte de forma 11x pentru servicii de urgenţă şi pentru alte servicii armonizate la nivel
european, care se atribuie şi se utilizează în conformitate cu reglementările speciale emise de
către autoritatea de reglementare.
5. Resursele de numerotare sînt utilizate de către utilizatorii finali pentru originarea
apelurilor către puncte terminale ale unei reţele publice de comunicaţii electronice sau pentru
accesul la servicii publice de comunicaţii electronice.
6. Se interzice modificarea formatului sau destinaţiei resurselor de numerotare.
II. DEFINIŢII
7. În înţelesul prezentului document următorii termeni se definesc astfel:

arie geografică – una din zonele în care este împărţită Republica Moldova din punct de vedere al
resurselor de numerotare geografice, corespunzătoare unui cod al zonei geografice; un cod de
zonă geografică identifică un raion sau un municipiu din Republica Moldova;
cod de ţară (CC – Country Code) – o secvenţă de cifre care indică ţara de destinaţie a apelului.
Codul de ţară pentru servicii de telefonie destinate publicului alocat Republicii Moldova de către
UIT este 373;
cod naţional de destinaţie (NDC – National Destination Code) – secvenţă de cifre de lungimi
variabile, care oferă utilizatorului final informaţii privind aria geografică în care sînt situate
punctele terminale apelate sau categoriile de servicii furnizate sau modalitatea de tarifare a
acestora;
cod de identificare – combinaţie de cifre, utilizate pentru realizarea operării reţelei sau a părţilor
acesteia şi pentru identificarea furnizorului la furnizarea nemijlocită a serviciilor de comunicaţii
electronice;
număr naţional semnificativ (N(S)N – National (Significant) Number) – secvenţă de cifre formată
din codul naţional de destinaţie şi numărul de abonat;
număr de abonat (SN – subscriber number) – secvenţă de cifre din numărul naţional semnificativ
care urmează codul naţional de destinaţie;
număr naţional – număr format din prefixul naţional urmat de numărul naţional semnificativ;
număr internaţional – număr format din codul de ţară al Republicii Moldova şi numărul naţional
semnificativ, precedate de prefixul internaţional;
număr cu acces gratuit pentru apelant (Freephone) – număr nongeografic a cărui apelare nu
presupune plata unui tarif de către apelant indiferent de reţeaua de comunicaţii electronice din
care este originat apelul, tariful fiind achitat de către apelat;
număr pentru servicii cu tarif special (Premium rate) – număr nongeografic care asigură accesul
la servicii de conţinut, la tarife mai mari decît cele aferente apelurilor naţionale, iar tariful
perceput este partajat între furnizorii de servicii de comunicaţii electronice destinate publicului şi
un terţ, care furnizează direct sau indirect serviciul de conţinut, indiferent de modalitatea de
plată;
număr pentru servicii cu cost partajat – număr nongeografic utilizat pentru acces la servicii
pentru care tariful apelului către acest număr este partajat între apelant şi abonatul căruia i s-a
transmis numărul respectiv;
număr independent de locaţie – număr nongeografic din PNN utilizat pentru furnizarea accesului
la reţele şi servicii publice de comunicaţii electronice în puncte terminale fixe sau nomade;
număr de acces universal – număr nongeografic care permite abonaţilor să recepţioneze apeluri
prin intermediul unui număr unic la diferite puncte terminale ale aceleiaşi reţele de comunicaţii
electronice, conform indicaţiilor de rutare furnizate de abonat.
III. STRUCTURA RESURSELOR DE NUMEROTARE
8. Numărul internaţional conform recomandării UIT E.164 pentru arii geografice.

Nivel local SN
Nivel naţional NDC SN
Numărul naţional (semnificativ)
Nivel internaţional CC NDC SN
9. Apelurile către un număr din PNN al unei alte ţări format de la un număr din PNN al
Republicii Moldova se realizează prin formarea prefixului internaţional, urmat de codul ţării de
destinaţie şi de numărul naţional semnificativ al ţării respective.
10. Apelurile efectuate din afara ţării către un număr din PNN al Republicii Moldova se
realizează prin formarea prefixului internaţional al ţării din care este originat apelul, urmat de
codul de ţară al Republicii Moldova şi de numărul naţional semnificativ.
11. Structura generală a PNN al Republicii Moldova este prezentată în Tabelul 1.
Tabelul 1
Formatul Atribuire Tipul de numere
numerelor din
PNN
0 Prefix naţional
00 Prefix internaţional
1XXXXX Coduri şi numere naţionale scurte Non-geografice
2XXXXXXX Numere pentru reţele şi servicii publice de Geografice
comunicaţii electronice furnizate la puncte fixe
3XXXXXXX Numere pentru reţele şi servicii publice de Geografice şi independente
comunicaţii electronice furnizate la puncte fixe şi de locaţie, furnizate la puncte
numere independente de locaţie fixe şi nomade
4XXXXXXX Rezervă
5XXXXXXX Numere pentru reţele şi servicii publice de Geografice
comunicaţii electronice furnizate la puncte fixe
6XXXXXXX Numere pentru reţele şi servicii publice de Non-geografice
comunicaţii electronice furnizate la puncte mobile
7XXXXXXX Numere pentru reţele şi servicii publice de Non-geografice
comunicaţii electronice furnizate la puncte mobile
8XXXXXXX Numere pentru servicii diverse (servicii cu Non-geografice
acces gratuit, servicii cu cost partajat, etc.)
9XXXXXXX Numere pentru servicii cu tarif special Non-geografice
IV. STRUCTURA ŞI DESTINAŢIA RESURSELOR DE NUMEROTARE
12. Tipurile de resurse de numerotare incluse în PNN sînt:

1) prefixe;
2) coduri şi numere naţionale scurte;
3) numere naţionale semnificative
13. Prefixe
1) Prefixul naţional este “0” şi precede numărul naţional semnificativ, în cazul originării unui apel
naţional.
2) Prefixul internaţional este “00” şi precede codul de ţară, în cazul originării unui apel
internaţional.
14. Coduri şi numere naţionale scurte
1) Codurile scurte din şirul de numere “1” se utilizează pentru acces la reţele şi servicii publice de
comunicaţii electronice (Tabelul 2).
2) Numerele naţionale scurte din şirul de numere “1” sînt numere nongeografice şi se utilizează
pentru furnizarea serviciilor armonizate la nivel european, servicii noncomunicaţii, servicii cu tarif
special (Premium rate) etc. (Tabelul 2).
Tabelul 2
Cod / Destinaţie Notă
număr
scurt
1000- Rezervă
1009
1010- Coduri de selectare/preselectare a
1099 transportatorului
11 Servicii armonizate la nivel european
110- Rezervă
111
112 Număr unic pentru apeluri de urgenţă
113- Rezervă
115
116xx Numere naţionale pentru servicii
x armonizate cu caracter social
1160 Număr de urgenţă pentru copii dispăruţi
00
1160 Rezervă
01-116005
1160 Asistenţă telefonică pentru victimele
06 infracţiunilor
1160 Rezervă
07-116110
1161 Asistenţă telefonică pentru copii
11
1161 Nealocabil
12
1161 Rezervă
13-116116
1161 Serviciul medical telefonic care nu intră în
17 categoria cazurilor de urgenţă
1161 Rezervă
18-116122
1161 Asistenţă telefonică care oferă sprijin
23 emoţional
1161 Rezervă
24-116999
117 Rezervă
118x( Numere pentru servicii de informaţii
x)
119 Rezervă
12 Rezervă
1300- Numere scurte pentru servicii
1319 noncomunicaţii
1320- Rezervă
1399
14xxx Servicii de interes general
1500- Numere scurte pentru servicii cu tarif
1559 special (Premium rate)
1560- Rezervă
1599
1600- Coduri de acces la servicii de comunicaţii
1639 electronice
1640- Rezervă
1679
1680- Coduri de acces la servicii publice de Utilizat în reţeaua proprie de
1699 telefonie fixă interurbană/internaţională prin telefonie fixă
operatoare
17xx Numere de rutare
18xx Rezervă
1900- Coduri de acces la servicii transport date Utilizare temporară. Termenul
1949 (Internet) de utilizare va fi stabilit de autoritatea
de reglementare
1950- Rezervă
1999
unde x = 0 …9,
3) Serviciu de informaţii ale furnizorilor de servicii şi reţele de comunicaţii electronice – servicii
de consultare, informaţii privind numărul sau, după caz, numerele de telefon sau de fax al/ale
abonatului şi/sau suportul tehnico-informaţional despre serviciile prestate de către furnizor.
4) Servicii noncomunicaţii – numerele se utilizează de către agenţi economici care deservesc
reţele electrice, reţele termice, gaze, reţele de apă şi canalizare etc.
5) Servicii de interes general - transport auto (inclusiv taxi), aerian, feroviar, servicii medicale etc.
6) Pînă la implementarea “Serviciului de Urgenţă Naţional “112” se vor menţine numerele scurte
pentru acces la serviciile de urgenţă “901”, “902”, “903” şi “904” (pompieri, poliţie, urgenţă
medicală şi serviciul gaze).
15. Numerele naţionale semnificative
În funcţie de semnificaţia şi formatul codului naţional de destinaţie, numerele naţionale
semnificative se împart în următoarele categorii:
1) numere geografice pentru servicii de comunicaţii electronice furnizate la puncte fixe, unde
codul naţional de destinaţie oferă informaţii cu privire la aria geografică în care se află punctul
terminal al reţelei;
2) numere independente de locaţie utilizate pentru servicii de comunicaţii, unde codul naţional
de destinaţie arată că serviciul este furnizat, la puncte terminale fixe sau nomade, punctul
terminal al reţelei nefiind legat de o anumită locaţie geografică;
3) numere non – geografice pentru servicii de comunicaţii electronice, unde codul naţional de
destinaţie arată că serviciile sînt furnizate la puncte mobile, prin intermediul unei reţele publice
mobile;
4) numere non – geografice pentru servicii diverse sau pentru servicii cu tarif special, altele decît
cele pentru servicii de comunicaţii electronice furnizate la puncte mobile, unde codul naţional de
destinaţie oferă informaţii privind serviciul furnizat sau modalitatea de tarifare a acestuia.
16. Schema de repartizare a resurselor de numerotare din PNN este prezentată în
Anexă.
V. REGULILE DE FORMARE ŞI UTILIZARE

A RESURSELOR DE NUMEROTARE
17. PNN este un plan de numerotare de tip închis, care prevede apelarea numerelor
telefonice din PNN, inclusiv celor geografice, prin formarea prefixului “0” şi a numărului naţional
semnificativ (N(S)N) sau a unui număr naţional scurt.
18. În funcţie de lungimea acestora, numerele de abonat pot fi:
1) numere de abonat de 6 cifre pentru municipiul Chişinău, şi de 5 cifre, pentru celelalte arii
geografice utilizate în reţele publice de comunicaţii electronice furnizate la puncte fixe;
2) numere de abonat de 4 cifre, pentru servicii de interes general la nivel local furnizate
utilizatorilor finali dintr-o anumită arie geografică;
3) numere de abonat de 6 cifre care intră în componenţa numerelor independente de locaţie;
4) numere de abonat de 5 cifre, pentru servicii de comunicaţii electronice furnizate la puncte
mobile.
19. Accesul, din diferite arii geografice şi reţele de telefonie fixă şi mobilă celulară, la
codurile şi numerele naţionale scurte din şirul de numere “1” se efectuează fără prefixul “0”.
20. Codurile de selectare a transportatorului din blocul “1010-1099” se utilizează pentru
selectarea serviciilor oferite de un furnizor de servicii publice de comunicaţii electronice, care
realizează transportul apelului din reţeaua în care este originat către reţeaua de destinaţie;
21. Numerele naţionale scurte de forma 11x se atribuie şi se utilizează în conformitate cu
reglementări speciale, pentru serviciile de urgenţă şi pentru alte servicii armonizate la nivel
european.
22. Numărul naţional scurt 116000 – se utilizează pentru serviciul “Linie telefonică de
urgenţă pentru copiii dispăruţi”. Serviciul preia apeluri prin care se anunţă dispariţia unor copii.
221.Numărul naţional scurt 116006 se utilizează pentru serviciul ”Linie de asistenţă telefonică
pentru victimele infracţiunilor”. Serviciul oferă victimelor infracţiunilor posibilitatea de a primi
asistenţă psihologică în astfel de sistuaţii, de a fi informate în legătură cu drepturile lor și cu
modalităţile de exercitare a acestor drepturi, precum și de a fi îndrumate către instituţiile care le
pot sprijini.
23. Numărul naţional scurt 116111 se utilizează pentru serviciul “Linie de asistenţă telefonică
pentru copii”. Serviciul oferă ajutor copiilor care au nevoie de îngrijire şi protecţie și îi pune în
legătură cu diverse organizaţii și resurse.
231. Numărul naţional scurt 116117 se utilizează pentru ”Serviciul medical telefonic care nu
intră în categoria cazurilor de urgenţă”. Serviciul direcţionează apelurile către serviciile medicale
adecvate pentru probleme urgente, dar care nu pun în pericol viaţa, în special, dar nu exclusiv, în
afara programului normal de lucru, în zilele de repaus săptămînal și în timpul sărbătorilor legale.
24. Numărul naţional scurt 116123 se utilizează pentru serviciul “Linie de asistenţă telefonică
care oferă sprijin psihologic”. Serviciul permite apelantului să beneficieze de o relaţie umană
reală, în cadrul căruia este ascultat fără a fi judecat. Acesta oferă sprijin psihologic apelanţilor
care suferă de singurătate, care se află într-o stare de criză psihologică sau care se gîndesc la
suicid.
25. Numerele pentru reţele mobile virtuale (MVNO – Mobile Virtual Network Operator) din
blocul “71000000 – 71999999” sînt utilizate de furnizorii de servicii de comunicaţii electronice
furnizate la punctele mobile care nu deţin o licenţă de utilizare a frecvenţelor radio, dar
furnizează servicii prin utilizarea unor elemente ale altor reţele publice mobile, în baza unor
acorduri încheiate cu furnizorii acestor reţele.
26. Numerele din blocul “80000000 – 80099999”, sînt numere cu acces gratuit pentru
apelant, indiferent de reţeaua din care este originat apelul şi sînt utilizate pentru terminarea
apelurilor, fără a exista posibilitatea de originare a apelurilor.
27. Numerele din blocul “80800000 – 80899999”, sînt utilizate pentru acces la servicii cu cost
partajat. În cazul serviciilor cu costuri partajate furnizate prin intermediul acestor numere, tariful
perceput apelantului, în dependenţă de numerele utilizate, nu poate depăşi tariful unui apel local
în interiorul reţelei locale sau naţional în interiorul reţelei naţionale, după caz.
28. Numerele din blocul “81400000 – 81499999” sînt utilizate pentru acces la diferite servicii
de informaţii de interes general (transport auto, inclusiv taxi, aerian, feroviar, servicii medicale
etc.). Pentru acces la aceste numere se aplică tariful apelului naţional către numerele geografice.
29. Numerele din blocul “82100000 – 82199999” sînt utilizate pentru acces la servicii de
transmisiuni de date şi la Internet prin Dial-up.
30. Numerele din şirul de numere “9” sînt utilizate pentru servicii cu tarif special (Premium
rate) după cum urmează:
1) blocul de numere “90000000 – 90089999” – servicii de conţinut de tip: divertisment, jocuri şi
concursuri;
2) blocul de numere “90090000 – 90099999” – servicii de tip: televotare;
3) blocul de numere “90500000 – 90599999” – servicii de conţinut de tip: informaţii diverse
(generale, de afaceri, de marketing etc.)
4) blocul de numere “90600000 – 90699999” – servicii de conţinut de tip: divertisment pentru
adulţi.
Anexă
SCHEMA DE REPARTIZARE
A RESURSELOR DE NUMEROTARE
I – Numere naţionale
Pref Coduri Număr Destinaţie Aria de

ix naţionale naţional utilizare
naţional de destinaţie semnificativ municipiu/raion
(NDC) Nr. N /naţională
/blocuri max. r. min.
de numere de cifre de cifre
1 2 3 4 5 6
00 Prefix internaţional
01 Rezervat pentru dezvoltări viitoare
02 Numere geografice pentru reţele şi servicii publice
de comunicaţii electronice furnizate la puncte fixe
0 20 Rezervă
0 210 8 Numere geografice Grigoriopol
0 211- Rezervă
214
0 215 8 Numere geografice Dubăsari
0 216 8 Numere geografice Camenca
0 215- Rezervă
218
0 219 8 Numere geografice Dnestrovsk
0 22 8 Numere geografice Chişinău
0 230 8 Numere geografice Soroca
0 231 8 Numere geografice Bălţi
0 232- Rezervă
234
0 235 8 Numere geografice Orhei
0 236 8 Numere geografice Ungheni
0 237 8 Numere geografice Străşeni
0 238- Rezervă
240
0 241 8 Numere geografice Cimişlia
0 242 8 Numere geografice Ştefan Vodă
0 243 8 Numere geografice Căuşeni
0 244 8 Numere geografice Călăraşi
0 245 Rezervă
0 246 8 Numere geografice Edineţ
0 247 8 Numere geografice Briceni
0 248 8 Numere geografice Criuleni
0 249 8 Numere geografice Glodeni
0 250 8 Numere geografice Floreşti
0 251 8 Numere geografice Donduşeni
0 252 8 Numere geografice Drochia
0 253 Rezervă
0 254 8 Numere geografice Rezina
0 255 Rezervă
0 256 8 Numere geografice Rîşcani
0 257 Rezervă
0 258 8 Numere geografice Teleneşti
0 259 8 Numere geografice Făleşti
0 260- Rezervă
261
0 262 8 Numere geografice Sîngerei
0 263 8 Numere geografice Leova
0 264 8 Numere geografice Nisporeni
0 265 8 Numere geografice Anenii Noi
0 266- Rezervă
267
0 268 8 Numere geografice Ialoveni
0 269 8 Numere geografice Hînceşti
0 270 Rezervă
0 271 8 Numere geografice Ocniţa
0 272 8 Numere geografice Şoldăneşti
0 273 8 Numere geografice Cantemir
0 274- Rezervă
290
0 291 8 Numere geografice Ceadîr Lunga
0 292 Rezervă
0 293 8 Numere geografice Vulcăneşti
0 294 8 Numere geografice Taraclia
0 295- Rezervă
296
0 297 8 Numere geografice Basarabeasca
0 298 8 Numere geografice Comrat
0 299 8 Numere geografice Cahul
03 Reţele şi servicii publice de comunicaţii electronice
furnizate la puncte fixe şi numere independente de
locaţie
0 30 8 Numere independente de Naţională
locaţie
0 310- Rezervă
319
0 32 8 Numere geografice Chişinău
0 330 8 Numere geografice Soroca
0 331 8 Numere geografice Bălţi
0 332- Rezervă
334
0 335 8 Numere geografice Orhei
0 336 8 Numere geografice Ungheni
0 337 8 Numere geografice Străşeni
0 338- Rezervă
340
0 341 8 Numere geografice Cimişlia
0 342 8 Numere geografice Ştefan-Vodă
0 343 8 Numere geografice Căuşeni
0 344 8 Numere geografice Călăraşi
0 345 Rezervă
0 346 8 Numere geografice Edineţ
0 347 8 Numere geografice Briceni
0 348 8 Numere geografice Criuleni
0 349 8 Numere geografice Glodeni
0 350 8 Numere geografice Floreşti
0 351 8 Numere geografice Donduşeni
0 352 8 Numere geografice Drochia
0 353- Rezervă
355
0 356 8 Numere geografice Rîşcani
0 357 Rezervă
0 358 8 Numere geografice Teleneşti
0 359 8 Numere geografice Făleşti
0 360- Rezervă
361
0 362 8 Numere geografice Sîngerei
0 363 8 Numere geografice Leova
0 364 8 Numere geografice Nisporeni
0 365 8 Numere geografice Anenii Noi
0 366- Rezervă
367
0 368 8 Numere geografice Ialoveni
0 369 8 Numere geografice Hînceşti
0 370 Rezervă
0 371 8 Numere geografice Ocniţa
0 372 8 Numere geografice Şoldăneşti
0 373 8 Numere geografice Cantemir
0 374- Rezervă
379
0 38 8 Numere independente de Naţională
locaţie
0 390 Rezervă
0 391 8 Numere geografice Ceadîr-Lunga
0 392 Rezervă
0 393 8 Numere geografice Vulcăneşti
0 394 8 Numere geografice Taraclia
0 395- Rezervă
396
0 397 8 Numere geografice Basarabeasca
0 398 8 Numere geografice Comrat
0 399 8 Numere geografice Cahul
04 Rezervat pentru dezvoltări viitoare
05 Numere geografice pentru reţele şi servicii publice
de comunicaţii electronice furnizate la puncte fixe
0 500- Rezervă
532
0 533 8 Numere geografice Tiraspol
0 534- Rezervă
551
0 552 8 Numere geografice Bender
0 553- Rezervă
554
0 555 8 Numere geografice Rîbniţa
0 556 Rezervă
0 557 8 Numere geografice Slobozia
0 558- Rezervă
599
06 Numere nongeografice pentru reţele şi servicii
publice de comunicaţii electronice furnizate la puncte
mobile
0 60-69 8 Telefonie celulară mobilă Naţională
07 Numere nongeografice pentru reţele şi servicii
publice de comunicaţii electronice
0 70 Rezervă
0 71 8 Numere pentru furnizorii de Naţională
reţele mobile virtuale (MVNO)
0 72-75 Rezervă
0 76-79 8 Telefonie celulară mobilă Naţională
08 Numere nongeografice pentru servicii
0 800000 8 Numere cu acces gratuit Naţională
00-80059999 pentru apelant (Freephone)
0 800600 8 International Freephone Naţională
00-80069999 Service
0 800700 8 Numere cu acces gratuit Naţională
00-80099999 pentru apelant (Freephone)
0 801- Rezervă
802
0 803 8 Numere de acces universal Naţională
0 804- Rezervă
807
0 808000 8 Numere pentru servicii cu cost Naţională
00-80849999 partajat (tarif local pentru apelant în
interiorul reţelei)
0 808500 8 Numere pentru servicii cu cost Naţională
00-80899999 partajat (tarif naţional pentru
apelant în interiorul reţelei)
0 809- Rezervă
813
0 814 8 Numere pentru servicii Naţională
transport
0 815- Rezervă
820
0 821 8 Numere de acces la servicii de Naţională
transmisiuni de date şi la Internet
0 822- Rezervă
829
0 83-89 Rezervă
09 Numere nongeografice pentru servicii cu tarif
special (Premium rate)
0 900000 8 Divertisment, jocuri, Naţională
00-90089999 concursuri şi servicii destinate
minorilor
0 900900 8 Televotare Naţională
00-90099999
0 901- Rezervă
904
0 905 8 Informaţii diverse (generale, Naţională
de afaceri, de marketing etc.)
0 906 8 Divertisment adulţi Naţională
0 907- Rezervă
909
0 91-99 Rezervă
* Planul a fost modificat prin Ordinul Ministerului Tehnologie Informaţiei şi Comunicaţiilor nr. 15
din 14.03.2017, în vigoare 19.05.2017.
Planul a fost modificat prin Ordinul Ministerului Tehnologie Informaţiei şi Comunicaţiilor nr. 57
din 02.07.2014, în vigoare 25.07.2014.
din 12.11.2012, în vigoare 07.12.2012.
din 25.11.2011, în vigoare 31.03.2012.
din 20.12.2010, în vigoare 31.12.2010.
Planul a fost aprobat prin Ordinul Ministerului Tehnologie Informaţiei şi Comunicaţiilor nr. 15 din
04.03.2010, în vigoare 21.05.2010.
Ultima actualizare: 25/05/2017

Curs 5 – 6
Sistemul de semnalizare 7 (SS7)
• Sistemul de semnalizare 7 este o arhitectură pentru semnalizare în afara benzii (out-of-

band signaling) ce asigură suport pentru stabilirea apelului, taxare, funcţii de rutare şi
comutare în reţeaua telefonică publică (PSTN – Public Switched Telephone Network)
(Semnalizarea se referă la schimbul de informaţii între componentele apelului, schimb de
informaţii necesar pentru furnizarea şi menţinerea serviciului)
o include funcţii realizate de o reţea de semnalizare şi un protocol care controlează
această reţea.
o este caracterizat de transmisie de pachete de viteză mare şi semnalizare în afara
benzii.
o aplicaţii suportate de către sistemul SS7 sunt:
PSTN.
ISDN.
Interacţiune cu Baze de date Reţea (adică baze de date care stochează
informaţii legate de reţeau de telecomnicaţie) şi Puncte de Control de
Serviuciu pentru controlul serviciilor furnizate
Servicii mobile.
Operaţii de administrare şi întreţinere ale reţelelor de telecomunicaţii.
• Reţeaua SS7 furnizează următoarele funcţii:
Operaţii de bază legate de stabilirea, managementul, taxarea şi eliberarea
unui apel.
Funcţionalităţi îmbunătăţite pentru apeluri: apel în aşteptare, redirectarea
apelului, afişarea numelui/numărului apelant, restricţia/rejecţia unor
apeluri, apeluri cu trei părţi (trei vorbitori).
Gestionarea congestiilor şi a priorităţilor.
Servicii wireless cum ar fi PCS (Personal Communication System),
roaming wireless şi autentificarea abonatului mobil.
Portabilitatea numărului local (LNP - Local number portability).
Servicii cu şi fără taxă.
Schimbul informaţiilor stocate în baze de date localizate în diferite
elemente de reţea (NE - Network Element).
Managementul reţelei pentru comunicaţii eficiente şi sigure.
• Semnalizarea în afara benzii (Out-of-band signaling) – semnalizarea nu are loc pe aceeaşi
cale cu conversaţia (nu are loc în aceeaşi bandă de frecvenţă); un canal digital separat se
utilizează pentru schimbul informaţiei de semnalizare între punctele de comutaţie, canal
numit legătură de semnalizare (signaling link).
o legăturile de semnalizare dedicate transmit informaţia la o rată de 56kbps sau 64kbps.
o canalul D ISDN extinde conceptul de semnalizare în afara benzii la interfaţa dintre
abonat şi centrală.
o avantaje ale semnalizării în afara benzii
se asigură transportul unei cantităţi mai mari de date la o viteză mai mare (de ex. o
legătură de date la 56kbps poate transporta date mult mai rapid decât o tehnică MF)
– stabilire mai rapidă a apelului.
permite semnalizare în orice moment pe toată durata apelului.
permite semnalizarea cu elemente de reţea cu care nu există legătură directă de
trunchi – utilizare mai eficientă a circuitelor de voce în special în apelurile
interurbane şi internaţionale.
se asigură control îmbunătăţit al utilizării frauduloase a reţelei.
oferă suport pentru mai multe servicii.
o implementarea cea mai simplă posibilă a unei semnalizări în afara benzii constă în
alocarea unei căi de semnalizare dedicate între o pereche de comutatoare
interconectate – este vorba de o semnalizare asociată unui grup de trunchiuri – fig. 1.
o semnalizarea asociată este o soluţie bună atât timp cât comutatoarele între care are loc
semnalizarea sunt conectate prin trunchiuri directe – în acest caz particular
semnalizarea asociată este simplă şi eficientă.
Fig. 1 Semnalizare asociată. Principiu
o spre deosebire de semnalizarea asociată, sistemul de semnalizare SS7 implementează

o reţea de semnalizare care permite fiecărui nod să schimbe informaţii de semnalizare
cu oricare alt nod – acest lucru nu este posibil tehnologic dacă se utilizează
semnalizare asociată.
o atât semnalizarea asociată cât şi semnalizarea SS7 sunt semnalizări de tip canal comun
• Arhitectura SS7 – reţeaua include următoarele trei componente esenţiale:

puncte de comutaţie a serviciului (Service Switching Points - SSPs) –
SSP-urile sunt centrale telefonice (locale sau de tranzit) echipate cu
software cu facilităţi SS7 şi legături de semnalizare terminale – ele
iniţiază, termină sau comută apelul; un SSP trimite mesaje de semnalizare
către alte SSP-uri pentru a realiza, controla şi întrerupe circuitele de voce,
operaţii cerute pentru desfăşurarea unui apel; un SSP poate trimite de
asemenea o interogarea la o bază de date (SCP) pentru a determina cum să
ruteze apelul (de ex. apelurile netaxabile). Nodurile SSP sunt punctele de
acces ale serviciului de către utilizatori prin utilizarea unui protocol de
acces.
puncte de transfer a semnalizării (Signaling Transfer Points - STPs) –
STP-urile sunt comutatoare de pachete ale reţelei SS7. Ele recepţionează
şi rutează mesajele de semnalizare către destinaţia corespunzătoare. Un
STP rutează fiecare mesaj recepţionat la o legătură de semnalizare de
ieşire pe baza informaţiei de rutare conţinute în mesajul SS7. Acest
echipament acţionează ca şi concentratoare de reţea şi îmbunătăţesc
utilizarea reţelei SS7 eliminând necesitatea legărilor directe între punctele
de semnalizare. Nodurile intermediare, STP, acţionează ca şi rutere SS7,
asigurând căi multiple între sursa şi destinaţia mesajelor, pentru a fi
posibilă gestionarea defectelor.
♦ STP-urile oferă de asemenea funcţii de rutare speciale pentru
numerele netaxabile de tipul 800, numere de cartele telefonice sau
pentru identificarea abonaţilor mobili.
♦ STP-rile pot fi utilizate şi pentru a analiza mesajele interschimbate
cu alte reţele.
♦ STP-urile sunt desfăşurate de regulă redundant în perechi localizate
în puncte diferite – ele funcţionează redundant pentru a realiza aceeaşi
funcţie.
puncte de control semnalizare (serviciu) (Signaling (Service) Control
Points - SCPs) – SCP-urile sunt baze de date care furnizează informaţiile
necesare pentru capabilităţi avansate de procesare a apelurilor. SCP-urile
sunt desfăşurate de regulă în perechi complementare localizate în puncte
fizice diferite – unul dintre SCP-uri este o rezervă. Nodurile SCP execută
funcţii de control ale reţelei – taxare sau translaţie de numere telefonice
netaxabile.
• Disponibilitatea reţelei SS7 este critică pentru procesarea apelului – fără schimbul de
informaţii dintre SSP-uri nu este posibilă realizarea apelurilor între centrale diferite – din
acest motiv, reţeaua SS7 este construită utilizând o arhitectură cu redundanţă ridicată –
fiecare element individual trebuie să satisfacă condiţii impuse pentru disponibilitate. Sunt
definite protocoale între elementele interconectate, protocoale care asigură capabilităţi de
detecţie a erorilor şi retransmisie a mesajelor eronate pentru a se permite continuarea
serviciului în cazul unor defecţiuni ale legăturilor de semnalizare.
• Fiecare punct de semnalizare din reţeaua SS7 este identificată în mod unic de un cod
numeric (point code - PC). Aceste coduri sunt transportate în mesajele de semnalizare
schimbate între punctele de semnalizare pentru a se identifica punctul de origine
(origination point - OPC) şi punctul de destinaţie (destination point - DPC) al fiecărui
mesaj. Fiecare punct de semnalizare utilizează o tabelă de rutare pentru selecţia legături
de semnalizare corespunzătoare fiecărui mesaj.
• Structura generală a unei reţele telefonice cu semnalizare SS7 este prezentată în fig.2
Fig. 2 Structura generală a unei reţele telefonice digitale cu semnalizare SS7

STP-urile W şi X realizează funcţii identice; ele sunt redundante şi împreună sunt
referite ca şi o pereche asociate de STP-uri; în mod similar, STP-urile Y şi Z formează
o pereche asociată.
fiecare SSP are două legături (sau seturi de legături), unul pentru fiecare STP al
perechii asociate; deoarece STP-urile perechii asociate sunt redundante, mesajele
transmise pe oricare legătură (la oricare STP) sunt tratate în mod echivalent.
STP-urile unei perechi asociate sunt unite de o legătură (sau seturi de legături).
două perechi asociate de STP-uri sunt interconectate de către 4 legături (sau seturi de
legături) – aceste legături se denumesc quad.
SCP-urile sunt de regulă (nu totdeauna) desfăşurate în perechi redundante – ele nu au
legături directe.
arhitecturile de semnalizare de tipul celor prezentate asigură căi de semnalizare
indirecte între elementele reţelei - sunt considerate ca şi reţele care asigură
semnalizare quasi-asociată.
• tipuri de legături de semnalizare SS7
• Structura reţelei SS7 permite diferite tipuri de conexiuni între punctele de semnalizare
(SP). Aceste legături sunt împărţite logic pe tipuri (A la F), în funcţie de utilizarea lor în
reţea;
o toate legăturile sunt identice (legături bidirecţionale la 56 sau 64 kbps) şi suportă
aceleaşi nivele primare ale protocoalelor.
o un slot de timp al sistemului T1 sau E1 poate fi utilizat pentru transmisia mesajelor
SS7.
o în fig. 3 sunt prezentate tipurile de legături de semnalizare.
Fig. 3 Tipuri de legături de semnalizare SS7

legătură A - link A – legătură (link) de acces – conectează un punct de
semnalizare terminal sau punct de semnalizare sursă (de ex. SSP sau SCP) la un
STP; pe legăturile A se transmit doar mesaje generate de către sau destinate
punctului de semnalizare terminal.
legătură B - link B – legătură (link) punte – conectează STP-uri; de regulă, quad-
uri de legături B interconectează STP-urile primare ale unei reţele cu STP-urile
primare ale unei alte reţele; funcţia acestor legături este de a transporta mesaje de
semnalizare dincolo de punctul lor de intrare iniţial în reţeaua de semnalizare către
punctul destinaţie; perechile de STP-uri interconectate se situează la acelaşi nivel
ierarhic.
legătură C - link C – legătură de interconecare (cross link) – conectează perechi
asociate de STP-uri care realizează funcţii identice; aceste legături sunt utilizate
pentru a creşte fiabilitatea reţelei de semnalizare; o legătură C este utilizată doar
atunci când un STP nu are altă rută disponibilă către un punct de semnalizare
destinaţie; legăturile C nu sunt utilizate între perechile asociate de SCP-uri.
legătură D - link D – legătură (link) diagonală – conectează perechi de STP-uri
de la nivele ierarhice diferite (de ex. o pereche de STP-uri secundare -locale sau
regionale- se leagă la o pereche de STP-uri primare -inter-reţea- cu rol de
„gateway” utilizând o configuraţie de legături de tip quad); nu este stabilită o
ierarhie clară asociată unei legături inter-reţea şi astfel legăturile de interconectare
sunt referite fie ca legături B, D sau ca legături B/D.
legătură E - link E – legătură (link) extins – conectează un SSP la un STP
alternativ pentru a furniza o legătură de semnalizare alternativă; legăturile E nu
sunt utilizate de regulă, doar dacă un grad mai ridicat de fiabilitate justifică
cheltuielile suplimentare; aceste legături asigură conectivitate de rezervă la
reţeaua SS7 în situaţia în care STP-ul asociat punctului de comutaţie nu poate fi
atins pe legăturile A.
legătură F - link F– legătură (link) complet asociată – conectează în mod direct
două puncte de semnalizare terminale (SSP-uri sau SCP-uri); aceste legături
permit numai semnalizare asociată; aceste legături nu sunt utilizate de regulă în
reţele care includ STP-uri, deoarece scurcircuitează funcţiile de securitate
asigurate de STP-uri.
• Operaţiile de semnalizare de bază SS7 efectuate pentru realizarea unui apel normal
– a se vedea figura 4 şi 5 pentru un exemplu simplu.
Subscriber
Voice Trunk
Signaling Link
Fig. 4 Apel normal bazat pe semnalizare SS7
o Un abonat conectat la centrala A generează un apel către un abonat conecta la centrala
B – paşii stabilirii, controlului şi întreruperii apelului sunt următorii:
1. Centrala A analizează numerele apelate şi determină că apelul este destinat centralei B
2. Centrala A selectează un trunchi liber către centrala B şi generează un mesaj de adresă
iniţial (initial address message - IAM) – mesaj de bază necesar iniţializării apelului;
mesajul IAM este adresat centralei B.
3. Centrala A accesează una din legăturile de acces (de ex. A-W) şi transmite mesajul
prin această legătură în vederea rutării către centrala B.
4. STP-ul W recepţionează mesajul, analizează eticheta de rutare şi determină că trebuie
rutat către centrala B; STP-ul W transmite mesajul pe legătura B-W.
5. Centrala B recepţionează mesajul, analizează conţinutul acestuia şi determină că
numărul apelat este deservit de el şi că acest număr este liber.
6. Centrala B generează un mesaj de adresă completă (address complete message -
ACM), care indică că mesajul IAM a atins destinaţia potrivită; mesajul identifică
centrala de destinaţie (A), centrala de origine (B), şi trunchiul selectat.
7. Centrala B accesează una din legăturile sale A (de ex. B-X) şi transmite mesajul ACM
pe legătură pentru rutare către centrala A şi în acelaşi timp închide calea audio în
direcţie opusă, trimite semnalul de revers apel pe trunchiul rezervat către centrala A şi
trimite semnalul de apel la abonatul apelat.
8. STP-ul X recepţionează mesajul, inspectează eticheta de rutare şi determină că
mesajul trebuie rutat către centrala A; STP-ul X transmite mesajul pe legătura A-X.
9. La recepţionarea mesajului ACM, centrala A conectează abonatul apelat la trunchiul
selectat (conexiune înspre abonatul apelant) – apelantul poate auzi semnalul de revers
apel trimis de către centrala B.
10. Atunci când abonatul apelat ridică telefonul, centrala B generează un mesaj de
răspuns (answer message - ANM), care identifică centrala destinaţie (A), centrala
origine (B) şi trunchiul selectat.
11. Centrala B selectează aceeaşi legătură A care a fost utilizată şi pentru transmiterea
mesajului ACM (legătura B-X) şi trimite mesajul ANM; în acest moment trunchiul
trebuie conectat la linia chemată în ambele direcţii (pentru a permite conversaţia).
12. STP-ul X recunoaşte că mesajul ANM este adresat centralei A şi o trimite mai
departe pe legătura A-X.
13. Centrala A recepţionează mesajul ANM şi asigură conectarea abonatului apelant la
trunchiul de ieşire (în ambele direcţii), conversaţia putând avea loc.
14. Dacă abonatul apelant întrerupe legătura (în urma conversaţiei), centrala A va genera
un mesaj de deconectare (release message - REL) adresat centralei B, identificându-se
trunchiul asociat apelului; mesajul se trimite pe legătura A-W.
15. STP-ul W recepţionează mesajul REL, determină că este adresat centralei B şi o
trimite mai departe pe legătura W-B.
16. Centrala B recepţionează mesajul REL, deconectează trunchiul de la linia de abonat,
pune trunchiul în stare inactivă, generează un mesaj de realizare a deconectării (release
complete message -RLC) adresată centralei A, şi transmite acest mesaj pe legătura
B-X; mesajul RLC identifică trunchiul utilizat pentru conexiune.
17. STP-ul X recepţionează mesajul RLC, determină că este adresat centralei A, şi o
trimite mai departe pe legătura A-X.
18. La recepţionarea mesajului RLC, centrala A pune trunchiul identificat în stare
inactivă.
Fig. 5 Apel normal bazat pe semnalizare SS7 – reprezentare alternativă
• Interogarea unei baze de date bazat pe semnalizarea SS7 – a se vedea fig. 6
Fig. 6 Interogare bază de date utilizând SS7
o un exemplu posibil este legat de apelul unor numere netaxate 800 sau 888; aceste
numere sunt numere de telefon virtuale, neasignate unei linii de abonat.
o când un abonat formează un număr 800 centrala trebuie să caute instrucţiuni într-o
bază de date – baza de date furnizează fie un număr de telefon real la care apelul
trebuie direcţionat sau va identifica o altă reţea la care apelul trebuie rutat pentru
fiecare apelare – răspunsul generat de baza de date poate fi acelaşi pentru fiecare apel
sau poate varia în funcţie de numărul apelat, perioada de timp a zilei, săptămânii,
anului, sau în funcţie de alţi factori.
o un exemplu simplu, legat de un număr 800 este prezentat în fig. 6.
1. Un abonat conectat la centrala A apelează un număr 800.
2. Când numărul este complet, centrala A recunoaşte că este vorba de un apel la un
număr 800 şi că este necesară asistenţă pentru gestionarea apelului.
3. Centrala A generează un mesaj de interogare legat de numărul 800, mesaj care include
numărul apelant şi cel apelat şi o trimite unui STP la care este conectat (de ex. STP X)
utilizând o legătură A (de ex. A-X).
4. STP X determină că a recepţionat o interogare a unei baze de date legată de numerele
800 şi selectează o bază de date corespunzătoare pentru generarea răspunsului (de ex.
SCP M).
5. STP X trimite mai departe cererea de interogare a bazei de date la SCP M utilizând o
legătură de acces (M-X); SCP M recepţionează mesajul de interogare, extrage şi
analizează informaţiile recepţionate şi pe baza informaţiilor stocate selectează un
număr de telefon real sau o reţea sau ambele la care apelul trebuie rutat.
6. SCP M generează un mesaj de răspuns cu informaţia necesară gestionării
corespunzătoare a apelului, o adresează centralei A, accesează o legătură de acces şi
un STP (de ex. legătura M-W) şi trimite răspunsul.
7. STP W recepţionează mesajul de răspuns, recunoaşte că este adresat centralei A şi o
rutează pe legătura A-W.
8. Centrala A recepţionează răspunsul şi utilizează informaţia găsită la rutarea apelului în
discuţie; accesează un trunchi către destinaţie, generează un mesaj IAM, şi continuă
mai departe cu stabilirea apelului – vezi exemplul anterior.
• Straturile protocolului SS7
• reţeaua SS7 este compus dintr-un set de elemente de reţea interconectate care sunt
utilizate la schimbarea mesajelor de suport pentru funcţii de telecomunicaţii – protocolul
SS7 este destinat pentru facilitarea acestor funcţii şi pentru întreţinerea reţelei care
furnizează funcţiile amintite.
• protocolul SS7 este divizat în mai multe straturi funcţionale – iniţial arhitectura SS7 a fost
destinată telefoniei bazată pe comutaţie de circuite, dar a evoluat pe măsură ce au apărut
noi cerinţe fiind momentan capabilă să permită transferul informaţiilor care nu mai sunt
legate de comutaţia de circuite.
• straturile protocolului SS7 sunt prezentate în fig. 7
Fig. 7 Straturile protocolului SS7 şi

comparaţie cu straturile OSI.
OSI – Open System Interconnection
o Partea de transfer a mesajelor (Message Transfer Part - MTP)
Legătura de date de semnalizare - Signaling Data Link - funcţii: defineşte
caracteristicile fizice, electrice şi funcţionale ale legăturii digitale de semnalizare;
♦ interfeţele fizice definite includ: DS1 (un slot al cadrului T1 cu debitul de
1.544Mbps), E1 (un slot al cadului E1 cu debitul de 2.048Mbps, de regulă slotul
16), V.35 (interfaţă serială sincronă la 64kbps sau 56kbps), DS0 (64kbps), DS0A
(56kbps) – 56kbps este implementarea uzuală.
Legătura de semnalizare - Signaling Link - funcţii: defineşte funcţiile şi procedurile
care asigură transmiterea sigură a mesajului pe legăturile de semnalizare;
♦ aceste funcţii implementează controlul fluxului, validarea secvenţei de mesaje,
detecţie de erori – când apare o eroare pe legătura de semnalizare, mesajul este
retransmis.
Reţeaua de semnalizare - Signaling Network - funcţii: defineşte acele funcţii şi
proceduri de transport care sunt comune legăturilor de semnalizare şi sunt
independente de legăturile individuale de semnalizare;
♦ asigură adresarea nodurilor şi rutarea mesajelor între punctele de semnalizare din
reţeaua SS7.
♦ asigură rerutarea traficului de pe legăturile şi punctele de semnalizare defecte şi
controlează traficul când apar congestii.
♦ asigură transferul mesajelor între punctele de semnalizare de-a lungul reţelei SS7
indiferent dacă există sau nu legătură directă între aceste puncte.
o Partea de control a conexiunii de semnalizare - Signaling Connection Control Part
(SCCP) – furnizează funcţii adiţionale MTP-ului pentru asigurarea serviciilor orientate
şi neorientate conexiune şi pentru asigurarea Translaţiei Globale de Titlu (Global Title
Translation - GTT) – este utilizat ca şi un strat transport cap la cap.
SCCP furnizează numere de subsistem pentru a permite adresarea mesajelor unor
aplicaţii specifice sau unor subsisteme din puncte de semnalizare specifice.
GTT adăugă abilitatea de a se executa rutare incrementală şi eliberează punctul de
semnalizare original de sarcina cunoaşterii tuturor destinaţiilor posibile; un titlu
global este o adresă (un număr 800, cartele de apel, sau număr de abonat mobil) care
este translatată de către SCCP într-un „point code” de destinaţie şi un număr de
subsistem – un astfel de număr de subsistem identifică în mod unic o aplicaţie în
punctul de semnalizare de destinaţie.
SCCP este utilizat ca şi un strat de transport pentru serviciile bazate pe TCAP.
o Partea de utilizator de telefon- Telephone User Part (TUP) – defineşte funcţiile
semnalizării de control internaţionale pentru stabilirea şi întreruperea unei comunicaţii
telefonice clasice – reprezintă o implementare mai veche a lui SS7 şi nu permite
aplicaţii de date.
o Partea de utilizator ISDN - ISDN User Part (ISUP) – defineşte protocoalele utilizate
pentru stabilirea, managementul şi eliberarea circuitelor trunchiuri care transportă voce
şi date între SSP-uri (localizate în PSTN) – este utilizat atât pentru legături ISDN cât şi
non-ISDN – apelurile care au punctul de origine şi punctul destinaţie în aceeaşi centrală
nu folosesc semnalizare ISUP.
o Capabilităţi de tranzacţie - Transaction Capabilities (TC) – furnizează mijloacele
necesare pentru stabilirea unei conexiuni ce transportă date care nu controlează
comutaţia de circuite între două puncte de semnalizare SP.
Partea de aplicaţii a capabilităţii de tranzacţie - Transaction Capabilities
Application Part (TCAP) – asigură schimbul datelor care nu controlează comutaţie
de circuite între aplicaţii localizate în reţeaua SS7 utilizând serviciul SCCP ne-bazat
pe conexiune (connectionless) ca şi un strat de transport. Defineşte mesajele şi
protocoalele utilizate pentru comunicaţia dintre aplicaţiile localizate în nodurile
reţelei SS7.
♦ interogări şi răspunsuri trimise între SSP-uri şi SCP-uri sunt transportate în
mesajele TCAP.
♦ în reţelele mobile, TCAP transportă mesajele „Mobile Application Part” (MAP)
trimise între comutatoare mobile şi baze de date pentru autentificarea
utilizatorului, identificarea echipamentului şi pentru roaming.
o Partea de operare, întreţinere şi administrare - Operations, Maintenance and
Administration Part (OMAP)
OMAP defineşte mesaje şi protocoale utilizate în administrarea reţelelor SS7 –
serviciile furnizate de către OMAP se pot folosi pentru a verifica bazele de date de
rutare şi pentru diagnosticarea problemelor legăturilor – OMAP include mesaje care
utilizează atât MTP cât şi SCCP pentru rutare.
• Transmisia de pachete pe legăturile de semnalizare
• informaţia de semnalizare este transmisă pe legăturile de semnalizare în mesaje, care sunt
numite unităţi de semnal (signal units - SUs).
• există trei tipuri de unităţi de semnal (signal units) definite în protocoalele SS7:
Unităţi de semnal de completare - Fill-In Signal Units (FISUs).
Unităţi de semnal de stare legătură - Link Status Signal Units (LSSUs).
Unităţi de semnal mesaje - Message Signal Units (MSUs).
• Unităţile SU se transmit continuu în ambele direcţii pe o legătură care este în serviciu; un
punct de semnalizare care nu are mesaje sau unităţi de semnal de supervizare (stare
legătură) va trimite pachete FISU pe legătura de semnalizare – pachetele FISU facilitează
transmisia informaţiilor de monitorizare şi a validărilor altor pachete SUs; toate mesajele
sunt compuse din octeţi.
o Unităţile de semnal - Fill-In Signal Units (FISU) – se transmit când nu este prezent alt
trafic SU pe legătură; FISU sunt transmise continuu pe o legătură de semnalizare în
ambele direcţii pentru a menţine legătura funcţională şi sincronizată; aceste unităţi
conţin CRC şi astfel calitatea legăturii este verificată continuu de către SP-urile de la
fiecare capăt al legăturii – a se vedea fig. 8 legat de structura mesajelor FISU.
o Unităţile de semnal de stare legătură - Link Status Signal Units (LSSU) – sunt
utilizate pentru schimbarea informaţiilor de stare legătură între SU-urile localizate la
fiecare capăt al legăturii; aceste pachete sunt utilizate pentru controlul sincronizării
legăturii şi pentru a transmite starea legături la capătul îndepărtat – a se vedea fig. 9
pentru structura mesajelor LSSU. Înainte ca o legătură SS7 să poată fi în stare să
transporte informaţie primită de la nivelele superioare, entităţile de nivel 2 de la cele
două capete ale legăturii realizează o procedură „handshaking” numită perioadă de
probare („proving period”) care durează de la 0.5 la 8.2s (depinzând de
disponibilitatea rutelor deservite de legătura în discuţie). În acest interval pachete
LSSU sunt schimbate între entităţile de nivelul 2, permiţându-se monitorizarea
numărului de erori recepţionate în acest interval. Dacă numărul de erori detectate în
acest interval este sub un anumit prag, legătura intră în starea de serviciu şi poate
transporta pachete MSU cu informaţii primite de la nivelele superioare. Entităţile de
nivel 2 monitorizează de asemenea starea legăturii pe durata transmisiei şi comunică
această starea a legăturii către alte entităţi în mesaje LSSU. De ex. aceste mesaje sunt
transmise când legăturile sunt congestionate sau sunt scoase din serviciu.
o Unităţi de semnal de mesaj - Message Signal Units (MSU) – sunt containere care
transportă mesaje de protocol TUP, ISUP şi SCCP în câmpul de informaţie; aceste
mesaje transportă toate semnalele de control al apelului, interogările de baze de date
şi răspunsurile, datele de management şi întreţinere a reţelei; există de asemenea
funcţii adiţionale specializate pentru aplicaţii mobile celulare; aceste unităţi au
etichetă de rutare care permite unui punt de semnalizare origine să trimită informaţie
către un punct de semnalizare destinaţie de-a lungul reţelei SS7 – a se vedea fig. 10
pentru structura mesajelor MSSU.
Fig. 8 Structura mesajelor FISU
Fig. 9 Structura mesajelor LSSU
Fig. 10 Structura mesajelor MSU
♦ Fanion - Flag (0 1 1 1 1 1 1 0) – indică începutul unei noi unităţi de semnal şi

sfârşitul unei unităţi anterioare; tehnici de manipulare pe bit sunt utilizate pentru a
asigura că această structură nu apare în cadrul mesajului transmis pe legătură –
unitatea SU este refăcută după recepţionarea sa, toate manipulările pe bit fiind
inversate – o manipulare posibilă pe bit constă în inserarea unui bit de zero după
fiecare grup de cinci biţi de unu; orice apariţie a fanionului pe legătură indică
sfârşitul unui SU şi începutul altuia – teoretic pot fi plasate două fanioane între SU-
uri, unul indicând sfârşitul mesajului curent iar celălalt începutul mesajului următor,
dar în practică este utilizat doar un singur fanion.
♦ BSN (Backward Sequence Number) – Număr de secvenţă invers – validează
recepţionarea unităţilor de semnal de către punctul de semnalizare de la capătul
îndepărtat; conţine numărul de secvenţă al unităţii de semnal care este validat
(achitat); fiecare mesaj trebuie să fie validat (achitat) prin intermediul lui BSN.
♦ BIB (Backward Indicator Bit) – Bit indicator înapoi – este utilizat pentru detecţia
erorilor şi indică o validare negativă (răspuns negativ) din partea punctului de
semnalizare de la punctul îndepărtat atunci când este inversat.
♦ FSN (Forward Sequence Number) – Număr de secvenţă direct – conţine numărul de
secvenţă al unităţii de semnalt.
♦ FIB (Forward Indicator Bit) – Bit indicator înainte – este utilizat în eliminarea
erorilor; dacă se recepţionează o validare negativă se retransmit toate mesajele
începând cu cel corupt – în aceste mesaje bitul FIB este inversat.
BSN+BIB şi FSN+FIB sunt utilizaţi pentru a confirma recepţionarea unităţilor SU
şi pentru a asigura recepţionarea în ordine corectă a acestor unităţi; aceste câmpuri
sunt utilizate de asemenea pentru control de flux; numerele de secvenţă ale
mesajelor transmise sunt stocate până când aceste mesaje sunt validate de către
punctul de semnalizare destinaţie.
şapte biţi sunt alocaţi pentru secvenţa directă (înainte) şi în acest fel este posibilă
stocarea a 128 de valori distincte – un punct de semnalizare este restricţionat la
trimiterea a 128 de SU-uri nevalidate înainte să recepţioneze o validare de SU –
prin validarea unui SU, nodul receptor eliberează acel număr de secvenţă SU în
punctul de transmisie, făcându-l disponibil pentru un nou SU ce se va transmite.
♦ Observaţie: Există două metode de control a erorilor pe legăturile SS7: metoda de
bază în care un mesaj este retransmis la recepţionarea unui răspuns negativ
(„acknowledgement” – ACK), metodă ce utilizează câmpurile BSN+BIB,
FSN+FIB şi CK şi metoda „Preventative Cyclic Retransmission” (PCR), caz în
care un mesaj este transmis de mai multe ori atunci când nivelele superioare nu
au nimic de transmis. Metoda PCR este utilizată în general numai pe căi care
prezintă întârzieri foarte mari, cum ar fi legăturile de satelit.
♦ SIO (Service Information Octet) – Octet de Informaţii Serviciu – conţine câmpul
subserviciu şi indicatorul de serviciu – vezi descrierea nivelului MTP3.
♦ SIF (Signaling Information Field) – Câmpul Informaţie Semnalizare – conţine
eticheta de rutare şi informaţia de semnalizare, adică informaţiile din mesajele
SCCP, TCAP şi ISUP– vezi descrierea nivelului 4; LSSU-urile şi FISU-rile nu au
etichetă de rutare şi SIO deoarece aceste unităţi sunt trimise între două puncte de
semnalizare conectate direct.
♦ Length Indicator (LI) – Indicatorul de Lungime – indică numărul de octeţi dintre
acest câmp şi secvenţa de control CRC; se foloseşte pentru testarea integrităţii
unităţilor SU şi pentru diferenţierea tipurilor de SU-uri – FISUs-urile au indicatorul
de lungime 0, LSSU-urile au indicatorul de lungime 1 sau 2 (în general LSSU are
LI=1), iar MSU-urile au indicatorul de lungime mai mare decât 2; doar 6 din cei 8
biţi ai LI sunt utilizaţi pentru stocarea lungimii menţionate – astfel valoarea cea mai
mare care se poate înscrie în câmpul LI este 63 – MSU-urile cu mai mult de 63 de
octeţi după câmpul LI utilizează valoarea 63.
♦ CK (Check bits) – Biţi de control– este o valoarea de CRC utilizată pentru detecţia
erorilor de transmisie.
• Nivelul 3 MTP (MTP3)

♦ Nivelul 3 asigură funcţii de rutare şi gestionare a defectelor pentru transportul
mesajelor. Fiecare nod SS7, care poate fi un switch clasic sau un nod care contine
baze de date de translaţie a numerelor 800, este identificat în cadrul reţelei în mod
unic printr-o adresă SS7 numit „point code”. Reţelele europene folosesc coduri pe
14 biţi, iar cele din americane coduri pe 24 de biţi.
• punctele de semnalizare individuale aparţin unui grup (cluster) de puncte de
semnalizare şi în interiorul acelui grup fiecare punct de semnalizare are un număr
de membru; în mod similar un grup (cluster) este parte a unei reţele – adresa de
rutare are trei nivele de numerotare definite de numerele de reţea, grup şi
membru – fiecare din aceste numere este pe 8 biţi; adresa completă este denumită
codul punct (point code) al punctului de semnalizare, cod care identifică în mod
unic punctul de semnalizare.
♦ O singură legătură SS7 este capabil să transporte trafic de semnalizare pentru mii de
circuite (în funcţie de trafic o legătură SS7 este proiectat în mod normal pentru a
controla între 1000 şi 2000 de circuite). Defecte pe această singură legătură vor
întrerupe toate circuitele controlate. Pentru siguranţă şi pentru a creşte capacitatea de
trafic de semnalizare, mai multe canale de semnalizare sunt prevăzute între două
noduri ce comunică folosind SS7. Colecţia de legături de semnalizare între două
noduri adiacente este cunoscut sub numele de set de legături („link set”), fiecare set
conţinând până la 16 legături – vezi figura 11
Fig. 11 Exemplu de reţea SS7 şi seturi de legături de semnalizare

♦ MTP3 adaugă informaţie în câmpul SIF („Signalling Information Field”) al
pachetului MSU. Aceată informaţie include adresa detinaţie a mesajului
(„Destination Point Code” - DPC), adresa sursă a mesajului („Originating Point
Code” - OPC) un cod de selecţie a legăturii de semnalizare utilizate („Signalling
Link Selection” - sls) pentru distribuirea mesajelor între legăturile de semnalizare
dintr-un set – vezi fig. 12 şi 14.
Fig. 12 Structura antetului MTP3
♦ Nivelul MTP3 distribuie automat mesajele între legăturile dintr-un set şi rerutează
traficul de pe legăturile defecte pe legături funcţionale din acelaşi set. MTP3
încearcă să refacă automat legăturile defecte şi rerutează traficul pe acestea – cele
două proceduri amintite se numesc „Changeover”şi „Changeback”. MTP3 este
capabil de asemenea să distribuie mesaje între legăturile din două seturi diferite
care deservesc aceeaşi destinaţie prin utilizarea unor noduri intermediare, seturile
de legături în discuţie fiind incluse într-un set de căi.
♦ Rutarea mesajelor la o anumită destinaţie de către MTP3 poate fi cvasi-asociată,
caz în care mesajul trece printr-un nod intermediar înainte să ajungă la destinaţie
sau asociată (sau complet asociată), caz în care există o legătură de semnalizare
directă între sursa şi destinaţia mesajelor.
♦ MTP3 asigură un transport sigur de mesaje pentru protocoalele de la nivelul
superiror, care utilizează MTP ca şi un serviciu de transport mesaje – protocoalele
de la nivelul superior sunt numite generic „User Parts”. Pentru a transporta un
mesaj la nivelul superior corespunzător, MTP3 examinează indicatorul de serviciu
(„Service Indicator - SI”), care este o componentă a octetului de informaţii serviciu
(„Service Information Octet” - SIO) – vezi fig. 13 şi 14.
Fig. 13 Structura octetului SIO
octet şi distribuţia mesajelor MTP3
Fig. 14 Structura câmpurilor

SIF şi SIO
♦ SIO (Service Information Octet) – Octet de Informaţii Serviciu – conţine câmpul
subserviciu şi indicatorul de serviciu.
Câmpul subserviciu (Subservice Field) conţine indicatorul de reţea (naţional or
internaţional) şi prioritatea mesajului – mesajele cu prioritate redusă sunt
eliminate pe durata congestiilor; mesajele de testare (supervizare) a legăturilor de
semnalizare au o prioritate mai mare decât mesajele de stabilire apel – fig. 14.
Indicatorul de serviciu (Service Indicator) – specifică utilizatorul MTP, care poate
fi TUP, ISUP, SCCP sau altul – fig. 13.
• Protocoale de nivele 4
♦ Protocoalele de nivelul 4 definesc conţinutul mesajelor şi secvenţele de mesaje
trimise la MTP3 pentru controlul resurselor de reţea, cum ar fi circuite şi baze de
date.
• TUP - Partea utilizator telefonie – „Telephony User Part”
♦ TUP asigură servicii PSTN convenţionale prin reţeaua SS7. TUP a fost primul
protocol de nivel 4 standardizat şi nu oferă servicii ISDN.
♦ Secvenţa de mesaje (semnale) utilizată pentru stabilirea – controlul – desfacerea unei
legături telefonice normale este asemănătoare cu secvenţa de mesaje caracteristică
protocolului ISUP
• ISUP – partea utilizator ISDN – „ISDN User Part” – defineşte protocolul şi procedurile
utilizate pentru stabilirea, managementul şi eliberarea circuitelor trunchiuri care transmit
voce sau date în reţeaua publică comutată – este utilizat atât pentru apeluri ISDN cât şi
apeluri non-ISDN; apelurile care încep şi se termină în aceeaşi centrală nu utilizează
semnalizarea ISUP. Oferă o variatate mai mare de message şi parametrii pentru
implementarea serviciilor de tip ISDN în cadrul reţelei.
• Atât TUP cât şi ISUP asigură mesage şi management adiţional pentru controlul stării
circuitelor. Este posibil să se reseteze un circuit sau un grup de circuite. Circuitele sunt
resetate în mod normal la iniţializarea sistemului sau după un defect. Proceduri similare
există pentru blocarea circuitelor, făcâdu-le nedisponibile temporar pentru apeluri – orice
apel recepţionat pentru un circuit blocat este în mod automat rejectat. Blocarea poate
aşteapta terminarea apelurilor active, operaţie cunoscută sub denumirea de blocare de
întreţinere sau blocare fără eliberare şi este utilizat înaintea operaţiilor de întreţinere.
Blocarea hardware sau blocare cu eliberare este utilizată în cazul detecţia echipamentelor
sau trunchiurilor care întrerup (sau alterează calitatea) circuitele de voce şi determină
întreruperea imediată a circuitelor şi apelurilor asociate.
• structura mesajelor ISUP este prezentată în fig. 15.
Fig. 15 Structura mesajelor
ISUP
câmpul SIF conţine etichetele de rutare: DPC şi OPC.
codul CIC identifică circuitul trunchi rezervat de către centrala care începe apelul. Un
trunchi este identificat în mod unic prin codul CIC şi prin adresele „point code” ale
SSP-urilor conectate prin acest trunchi.
câmpul MSGTYPE specifică tipul mesajelor, adică: IAM, ACM, ANM, REL, şi RLC –
a se vedea fig. 4 şi fig. 5 şi explicaţiile asociate; acest câmp defineşte conţinutul
câmpului mesaj – MSG INFORMATION.
scurtă prezentare a mesajelor:
♦ IAM – Initial Address Message – Mesaj de Adresă Iniţială – conţine informaţia
necesară stabilirii apelului şi este transmis atunci când comutatorul trebuie să închidă
circuitul între partea apelantă şi cea apelată.
IAM conţine numărul apelat în partea variabilă obligatorie şi poate conţine
numele şi numărul părţii apelante în partea opţională – este vorba despre câmpul
MSG INFORMATION.
♦ ACM – Address Complete Message – Mesaj de Adresă Completă – indică faptul că
partea apelată este disponibilă şi că partea îndepărtată a trunchiului a fost rezervată;
comutatorul origine răspunde la un mesaj ACM prin conectarea linie chemătoare
la trunchi – circuitul de voce este realizat de la partea chemătoare până la partea
chemată – semnalul de apel este transmis părţii chemate şi semnalul de revers
apel este trimis părţii chemătoare.
♦ ANM – Answer Message – Mesaj Răspuns – în momentul în care partea chemată
răspunde, comutatorul destinaţie întrerupe semnalul de apel şi de revers apel şi
trimite un mesaj ANM către comutatorul origine;
comutatorul origine începe taxarea după ce verifică că partea chemată a liniei este
conectată la trunchiul rezervat.
♦ REL – Release Message – Mesaj de Eliberare – indică că circuitul a fost eliberat şi
cauza eliberării; un mesaj REL este trimis când una dintre părţile conversaţiei
închide telefonul (trece în stare inactivă ON HOOK); un mesaj de REL este trimis în
direcţia opusă şi atunci când linia apelată este ocupată sau nu există circuit de
trunchi disponibil (funcţional).
♦ RLC – Release Complete Message – Mesaj Eliberare Realizată – validează recepţia
unui mesaj REL (de către partea opusă) a circuitului trunchi şi întrerupe taxarea.
• Partea de control a conexiunii de semnalizare (SCCP) – „Signalling Connection
Control Part”
• SCCP îmbunătăţeşte capacităţile de rutare şi adresare a MTP, permiţând adresarea
componentelor individuale de procesare sau a subsistemelor în fiecare punct de
semnalizare.
• Adresarea SCCP de bază rutează mesage prin reţea utilizănd un număr de subsistem şi un
„point code” pentru a identifica destinaţia. Fiecare subsistem poate fi o baza de date de
translaţie a numerelor. Unui „point code” SS7 i se pot asocia mai multe subsisteme.
• SCCP oferă 4 clase de servicii, numerotate de la 0 la 3 – vezi tab. 1
• Clasele de servicii SCCP cele mai utilizate sunt 0 şi 1, folosite de către nivelul TCAP şi
de către nivele mai mari pentru a controla reţele mobile/wireless şi reţele inteligente.
Clasele 2 şi 3 pot fi utilizate în communicaţii între staţii de bază şi controlere de staţii de
bază.
Clasă Proprietate
0 Fără conexiune. Datele sunt trimise la destinaţie fără a se negocia o sesiune.
1 Fărăr conexiune cu control de secvenţă. Se garantează transportul mesajelor la
destinaţie în ordinea transmisterii.
2 Orientat conexiune. Este negociată o sesiune (conexiune SCCP) înaintea
schimbului de date.
3 Orientat conexiune cu control de flux.
Tab. 1 Clase de servicii SCCP
• SCCP menţine (memorează) o stare pentru fiecare subsistem de care este conştient,
subsisteme care pot active (şi se pot accesa) („Allowed”) sau inactive (şi nu se pot accesa)
(„Prohibited”). Un mesaj poate fi trimis numai la un subsistem activ. La fel, o conexiune
se poate deschide numai către un subsistem activ.
• Mesajul de bază al legăturilor SCCP fără conexiune este aşa numitul SCCP UNITDATA,
numit de asemenea UDT. Când SCCP detectează o destinaţie inactivă pentru un mesaj,
mesajul UDT poate fi eliminat sau poate fi returnat la sursă ca şi un pachet UNITDATA
SERVICE (UDTS), dacă o astfel de opţiune este setată în câmpul de serviciu al
mesajului.
• Pentru a detecta şi raporta starea subsistemelor, SCCP transmite mesaje de management,
încapsulate în mesaje UDT; aceste mesaje sunt trimise între entităţile fiecărui SCCP.
• Mesajele de verificare a stării subsistemelor sunt generate periodic, aproximativ la fiecare
30s, la fiecare subsistem inactiv pentru a se determina când rutarea câtre aceste destinaţii
este posibilă. SCCP oferă de asemenea facilităţi pentru a face subsistemele să cunoască
starea altor subsisteme şi astfel orice modificare în procesul de rutare poate fi raportat
imediat.
• SCCP permite de asemenea o capabilitate de adresare avansată, caz în care un subsistem
este reprezentat printr-o secvenţă de caractere denumită adresă globală sau „Global
Title”. O adresă globală este o metodă de a ascunde un „point code” SS7 şi numărul de
subsistem destinaţie de sursa unui mesaj, de exemplu interconectarea unor reţele diferite
în care nu există alocare comună a adreselor „point code”. O asemenea metodă este
utilizată în roamingul între diferite ţări în sistemele GSM mobile.
• În funcţie de topologia reţelei, adresele globale sunt translatate la nivelul STP sau a unor
centrale „gateway” unde o reţea are funcţii de interconetare cu reţele adiacente.
• Informaţia de adresă trimisă la SCCP pentru rutarea mesajelor poate conţine un „point
code” destinaţie, un număr de subsistem şi opţional o adresă globală. Pentru transmisia cu
succes a mesajului cerinţa minimă este specificarea unui „point code”, pentru ca mesajul
să părăsească nodul SCCP. Dacă adresa „point code” nu este cunoscută, informaţia de
adresă este aplicată unui proces de translaţie a adresei globale („Global Title
Translation”), operaţie care va produce un „point code” destinaţie şi opţional un număr de
subsistem sau o altă adresă globală. Informaţia legată de adresa chemată dintr-un mesaj
conţine un indicator de rutare care instruieşte SCCP ca să ruteze pe bază de „point code”
şi număr de subsistem sau adresă globală. Dacă rutarea se realizează pe baza unei adrese
globale, această adresă este supusă unui proces de translaţie pentru a se produce o nouă
adresă destinaţie, care poate fi un nod de procesare a informaţiei sau un alt nod SCCP
care va putea translata din nou informaţia.
• Fig. 16 arată utilizarea adreselor globale „Global Titles” în operaţii GSM-mobile pentru
localizarea informaţiilor de descriere a abonatului mobil, localizate în subsistemul „Home
Location Register” – HLR al unei alte reţele, situaţie întâlnită în roaming internaţional.
Informaţiile de descriere a abonatului sunt păstrate într-o bază de date în reţeaua proprie a
abonatului, bază de date care trebuie interogată pentru ca abonatul să primească servicii
de la reţeuaua vizitată. Interogarea bazei de date este trimisă prin SCCP cu o adresă
globală contruită din informaţii legate de abonatul mobil – codul de itentitate al
terminalului sau numărul abonatului, informaţii care deţin date suficiente pentru a ruta
mesajul la gateway-ul de ieşire prin utilizarea translaţiei de adresă. Translaţii ulterioare în
cadrul reţelei proprii abonatului vor ruta cererea către baza de date corectă.
Fig. 16 Utilizarea translaţiei de adresă globală (GTT) în roaming mobil

• Translaţia de adresă globală este utilizată de asemenea pentru localizarea unei baze de
date de translaţie a numerelor de telefon netaxabile, bază de date localizată într-un SCP,
prin utilizarea unui număr 800 ca şi o adrersă globală care este translatată într-un STP
pentru a se obţine baza de date care conţine translaţii pentru un domeniu de numere 800.
De ex. 800-1xxxxx poate fi legat de o bază de date A iar 800-2xxxxx poate fi legat de o
bază de date B, după cum se poate vedea în fig. 17.
Fig. 17. Utilizarea translaţiei de adresă globală pentru localizarea translaţiei de numere 800
• Capabilităţi de tranzacţie (TCAP) – „Transaction Capabilities”
• Partea TCAP oferă o metodă structurată pentru a cere realizarea unor operaţii la un nod
îndepărtat, definind fluxul de informaţie pentru controlul operaţiei şi raportarea
rezultatului.
• Operaţiile şi raportarea rezultatelor sunt realizate în cadrul unei sesiuni denumite dialog
(în partea superioară a lui TCAP) sau tranzacţie (în partea inferioară a lui TCAP). În
cadrul unui dialog pot fi active mai multe operaţii la diferite stadii de procesare. Operaţiile
şi rezultatele sunt incluse în elemente de informaţie numite componente. Operaţia
efectuată de TCAP este de a stoca componente de la nivelele superioare în vederea
transmisiei până când se recepţionează (de la nivele superioare) un element de informaţie
de gestionare a transmisiei, moment la care componentele stocate sunt formatate într-un
singur mesaj TCAP şi sunt trimise prin SCCP către alte entităţi TCAP.
• În sensul de recepţie, TCAP despachetează componentele din mesajele recepţionate de la
SCCP şi transmite fiecare componentă ca şi un element separat de informaţie către
protocolul de nivel superior. Fig. 18 arată fluxul de informaţie TCAP
Fig. 18 Fluxul de informaţie TCAP

• Aplicaţiile tipice ale TCAP sunt servicii mobile (de ex. înregistrarea terminalelor aflate în
roaming), servicii de reţele inteligente („Intelligent Networks”), (de ex. apeluri către
numere gratuite şi servicii de cartele de apel – „calling card”) şi servicii de administrare şi
întreţinere (OA&M).
• Partea de aplicaţii mobile ( MAP) – „Mobile Application Part”
• Partea de aplicaţii mobile este utilizat în cadrul reţelelor mobile/wireless pentru a se
accesa informaţii de roaming, pentru a se controla procesul de „hand-over” şi pentru a
asigura servicii de mesaje (SMS). Pentru aceste operaţii se utilizează în mod tipic TCAP
peste SCCP şi MTP ca şi mecanism de transport.
• Reţelele mobile solicită multe accese la baze de date. Punctul de subscriere a unui abonat
este o baza de date cunoscut sub numele „Home Location Register (HLR)”. Când
abonatul intră într-o celulă şi se înregistrează în reţea, informaţiile legate de abonat se
stochează temporar în echipamentele care deservesc celula vizitată într-o bază de date
cunoscut sub numele de „Visitor Location Register (VLR)”. MAP specifică un set de
funcţii şi fluxuri de informaţie care implementează aceste servicii pentru a permite
transferul de informaţie între bazele de date menţionate, pentru a se înregistra, localiza şi
trimite apeluri către abonatul care realizează roaming (termenul se referă şi la intarea în
celule deservite de un alt punct de comutaţie mobil (MSC – „Mobile Switching Center”)
şi nu numai la intrarea în reţele din alte ţări)
• Figura 19 şi tabelul 2 arată cum se rutează apelul către un terminal mobil
Fig. 19 Apelarea unui terminal mobil
1 Abonatul chemător apelează abonatul mobil.

2 Prefixul reţelei mobile determină rutarea apelului către
punctul de comutare gateway al reţelei mobile – GMSC.
3 GMSC utilizează informaţia din număprul apelat pentru a
localiza baza de date HLR al abonatului mobil chemat.
4 HLR este deja informat despre locaţia (adresa) bazei de date
VLR a abonatului mobil şi cere un număr de rutare temporar
pentru a permite rutarea apelului către MSC-ul corect.
5 MSC/VLR răspunde cu un număr de rutare temporar care va
fi valid numai pe durata acestui apel.
6 Numărul de rutare este returnat la GMSC.
7 Apelul se realizează utilizând semnalizare standard ISUP
(sau similar) între GMSC şi MSC-ul vizitat.
Tab. 2 Etapele apelării unui terminal mobil
SISTEME ȘI REȚELE DE COMUNICAȚII

DIGITALE
Partea 2
CICLU DE PRELEGERI
Chişinău
2015
3
Facultatea Inginerie și Management în

Electronică şi Telecomunicaţii
Catedra Telecomunicaţii
SISTEME ȘI REȚELE DE COMUNICAȚII

DIGITALE
Partea 2
CICLU DE PRELEGERI
Chişinău
2015
4
Lucrarea de față include partea a doua a cursului
Sisteme și rețele de comunicații digitale(SRCD) și este
divizată în două compartimente. În primul compartiment
este descris protocolul umbrelă H.323 inclusiv
componentele și protocoalele acestui sistem. Capitolul
finalizează cu aducerea unui exemplu de setare a unui apel
cu implicarea gatekeeper-ului.
În al doilea capitol se expune protocolul de control a
Gateway-lui H.248/MEGACO. Se descrie modelul de
conexiune, comenzile și descriptorii protocolului
H.248/MEGACO. În final se descrie un scenariu de setare a
unui apel H.248.
Obiectivul principal al acestei părți a cursului SRCD
constă în însușirea cunoștințelor de bază privind
protocoalele de semnalizare utilizate în rețelele de noua
generație.
Cursul Sisteme și rețele de comunicații digitale este
destinat studenţilor UTM cu profilul 525 Electronică şi
comunicaţii, specialităţile Teleradio – comunicații, cu forma
de studii la zi şi cu frecvenţă redusă.
Redactor: E. Gheorghișteanu
Bun de tipar 25.05.2015 Formatul 60x84 1/16

Coli de tipar 3,0 Comanda nr. 53
2004, U.T.M., bd. Ştefan cel Mare şi Sfânt, 168
© U.T.M., 2015
5
INTRODUCERE
Prima parte a cursului de prelegeri ”Sisteme și rețele de

comunicații digitale” [1] a inclus expunerea generală a
reţelelor de noua generaţie NGN şi a protocolului de iniţiere
a sesiunii SIP.
Partea a doua a cursului de prelegeri continuă cu
expunerea a altor două protocoale de semnalizare pe larg
utilizate în rețelele de comunicații multimedia, și anume,
protocolul umbrelă H.323 și proltocolul de control a
gateway-lui H.248/Megaco.
Lucrarea în cauză este destinată studenţilor ultimului
an universitar, masteranzilor, dar autorul speră să fie de
folos și tuturor celor din domeniul TIC interesaţi de
subiectele abordate.
1. PROTOCOLUL H.323
1.1 Sumar
Protocolul H.323 a fost elaborat în cadrul Uniunii

Internaţionale a Telecomunicaţiilor (ITU), prima versiune
fiind publicată în 1996. Expunerea ce urmează este bazată
pe versiunea curentă sub numărul 7 adoptată în decembrie
2009 [2].
Recomandarea ITU-T H.323 ”Sisteme de comunicații
multimedia bazate pe pachete” [2] se referă la specificațiile
tehnice pentru sistemele de comunicații multimedia bazate
pe rețele cu comutația de pachete, care nu pot asigura o
calitate garantată a serviciului (QoS). Această recomandare
descrie componentele unui sistem H.323, care include
terminale H.323, Gateway-uri, Gatekeeper și unități de
control multipunct MCU (Multipoint Control Unit) pentru
conferințe (figura 1.1). Mesajele și procedurile de control
6
din cadrul acestei recomandări definesc modul în care
aceste componente comunică.
GK
Terminale
H.323
T
Rețea comutație e
MCU T
IP
GK
T
Gateway
PSTN ISDN
Fig. 1.1 Componentele rețelei H.323

Componentele rețelei H.323 comunica prin schimbul de
fluxuri informaționale, clasificate după cum urmează:
 Audio: vorbire digitalizată și codificată. Fiecare flux
audio are și un semnal de control audio.
 Video: imagini digitale codate în mișcare (nu imagini
statice). Fiecare flux video are un semnal de control video.
 Date: fișiere electronice cum ar fi imagini statice,
imagini de fax și documente.
 Controlul comunicațiilor: semnale pentru a face
schimb de capabilități, deschiderea și închiderea canalelor
logice, modului de control și alte funcții de control al
comunicațiilor.
7
 Controlul apelurilor: semnale pentru stabilirea și
eliberarea apelurilor.
Protocolul H.323 a fost creat aproximativ în același timp
ca și protocolul de inițiere a sesiunii SIP, dar a fost adoptat
pe scară mai largă și desfășurat mai devreme. Astăzi, cele
mai mult din traficul VoIP global se realizează prin
intermediul rețelelor H.323, cu miliarde de minute de trafic
transportate în fiecare lună.
1.2 Terminalul H.323
Conform definiției ITU un terminal H.323 este un punct

final al rețelei care asigură comunicații bidirecționale vocale
sau multimedia, în timp real cu un alt terminal H.323,
gateway sau unitate de control multipunct. Această
comunicare constă în schimbul de fluxuri audio, video,
date și semnale de control între două sau mai multe
terminale. Un terminal poate furniza doar comunicare
audio, sau audio și de date, sau audio și video, sau toate
trei concomitent. Exemple de terminale pot servi telefonul
IP, softphonul, IVR (Interactive voice response), voicemail,
camera video, PC-ul etc. Schema-bloc tipică al unui
terminal H.323 care asigură comunicații multimedia este
prezentat în figura 1.2 [2].
Pe diagramă sînt arătate elementele terminalului:
codecurile video și audio, echipamentul de telematică,
unitatea de sincronizare la recepție, unitatea de control a
sistemului și modulul nivelului H.225.0.
8
Echipam Video codec Sincroni
ent I/O H.261, H.263, zare
recepție
video H.264
(Receive
Echipam Audio codec path
ent I/O G.711, G.722, delay) I
audio G.723, G.728, n
G.729 t
e
Aplicații Nivel
r
date ITU-T
H.225.0 f
utilizator
a
Control sistem ț
Control ă
Interfață H.245
utilizator r
de Control apel e
control a H.225.0 ț
sistemul e
ui a
Control RAS
H.225.0
Fig.1.2 Schema-bloc a terminalului H.323
Codecul video (H.261, H.263, H.264, etc.) codifică

video semnalul transmis de la sursă (de exemplu, camera
de luat vederi) și decodifică semnalul video recepționat din
rețea pentru afișarea lui pe ecran.
Codecul audio (G.711, G.722, G.723, G.726, etc.)
codifică semnalul audio transmis de la microfon și
decodifică semnalul audio recepționat din rețea cu emiterea
lui spre difuzor.
9
Canalul de date utilizator suportă aplicații telematice,
cum ar fi table electronice, transfer de imagine statice,
schimb de fișiere, acces la baze de date, conferințe
audiographice, etc.
Unitatea de sincronizare la recepție include întârzieri la
fluxurile media sosite în scopul sincronizării lor. Intârzierea
introdusă la recepţie are rolul de a elimina jitterul (variaţia
întârzierii) prin memorarea octeţilor de voce şi redarea lor la
recepţie la intervale egale.
Unitatea de control al sistemului (H.245, H.225.0)
asigură semnalizarea pentru funcționarea adecvată a
terminalului H.323. Ea asigură înregistrarea terminalelor la
gatekeeper, stabilirea și încheierea canalelor logice,
controlul apelurilor, schimbul de capabități funcționale.
Unitatea de control a terminalului implementează
protocoalele de control a conexiunilor.
Modulul nivel H.225.0 la transmitere formateaza
semnalele video, audio și date utilizator și de control în
mesaje de ieșire spre interfața de rețea. La recepție
modulul preia semnalele video, audio, date utilizator și de
control din mesajele de intrare de la interfața de rețea. În
plus, el efectuează formarea cadrelor logice, numerotarea
lor secvențială, detectarea și corectarea erorilor.
Conectarea terminalului la rețeaua bazată pe pachete
se efectuează prin interfața de rețea.
1.3 Gatway-ul H.323
Gateway-ul H.323 (GW) este un punct final al rețelei

care asigură în timp real comunicații bidirecționale între
terminale H.323 din rețeaua bazată pe pachete și alte
terminale dintr-o rețea cu comutare de circuite. Funcția
principală a gateway-ului este de a converti vocea sau
informația multimedia venită de la rețeaua cu comutare de
circuite (SCN) într-o formă adecvată pentru transmiterea ei
prin rețele bazate pe IP. Această conversie constă în
10
codificarea informației și încadrarea ei în pachete
RTP/UDP/IP, precum și transformarea inversă în sensul
opus. În plus, gatway-ul trebuie să asigure și schimbul de
mesaje de semnalizare intre SCN și rețeaua H.323. În
figura 1.3 se prezintă un exemplu de configurare gateway
la care din partea ambelor tipuri de rețea se conectează
terminale. Alte configurații de gateway prevăd conectarea
MCU la una din rețele sau la ambele rețele.
Gateway
Funcții Funcții de Funcții
terminal terminal
H.323 SCN sau
conversie
sau MCU
MCU SCN
Rețea IP Rețea cu
comutație
circuite
Fig.1.3 Exemplu configurație gateway IP/PSTN
Astfel un GW are caracteristicile terminalului H.323 sau

MCU în rețeaua IP și realizează funcțiile terminalului SCN
sau MCU SCN în rețeaua cu comutație de circuite.
Gateway-urile care suportă interconectarea doar cu
terminale pentru voce în PSTN sau ISDN trebue să fie
capabile să genereze și să detecteze semnalele DTMF
pentru 0-9, *, și #. În plus, ele pot fi capabile să genereaze
și detecteze semnalele DTMF, tonuri și semnale de
telefonie corespunzătoare acestor evenimente transmise
cu o sarcină utilă RTP specială (mesaje H.245).
11
Dacă gatekeeper-ul nu se folosește în rețeaua H.323
atunci GW trebuie să mai realizeze și translarea numărului
E.164 în adresa de transport a rețelei IP.
Evident că dacă se efectuează o conexiune între două
terminale H.323 aflate într-o rețea IP atunci GW nu este
necesar.
1.4 Gatekeeper H.323
Gatekeeper-ul (în română - Portarul) efectuează

controlul terminalelor, gateway-urilor și MCU interconectate
în cadrul unei zone de rețea H.323. Toate aceste entități se
înregistrează la acest gatekeeper (GK). Diferite părți ale
zonei rețelei H.323 dispersate teritorial pot fi interconectate
prin rutere (figura 1.4).
Fig.1.4 Zona rețelei H.323
12
Ruterele și switch-urile Ethernet funcționează la
nivelele trei și doi și nu fac parte din entitățile rețelei H.323
care activează la nivelul aplicațiilor al stivei TCP/IP.
Zona nu trebuie neapărat să aibă o topologie fizică
asociată. Mai degrabă, o zonă poate fi o structură logică
definită de administratorul de rețea.
Gatekeeper-ul furnizează următoarele servicii:
 Translarea adresei numită alias (numele abonatului,
numărul telefonic, adresa poștei electronice, etc.) în adresa
de transport a rețelei (adresa IP și numărul portului TCP).
Traslarea se efectuează cu ajutorul unui tabel de
corespondență care este actualizat folosind mesajele de
înregistrare descrise mai jos.
 Controlul admisiei terminalelor în rețea. GK-ul
trebuie să autorizeze accesul în rețea utilizînd
semnalizarea RAS descrisă în paragraful 1.6.1.
 Controlul, managementul și rezervarea ratei de
transfer a rețelei. Spre exemplu, GK poate controla numărul
terminalelor care simultan accesează rețeaua.
 Rutarea mesajelor de semnalizare între terminalele
unei zone. Sînt posibile două moduri de rutare. GK-ul poate
organiza canalul de semnalizare direct între terminale sau
cu retransmiterea mesajelor de semnalizare de la un
terminal la altul.
Nu poate exista decît un singur GK activ pe zonă
(figura 1.5).
Fig.1.5 Zone H.323 cu Getekeepere
Fiecare zonă poate suprapune mai multe subrețele cu

un GK care gestionează gateway-urile, terminalele, MCU
din aceste subrețele.
13
1.5 Unitatea de control multipunct MCU
Unitatea de control multipunct (MCU) este un dispozitiv

final al rețelei care asigură organizarea conferințelor
multipunct cu participarea a trei sau mai multor terminale și
gateway-uri. Inițial într-o conferință pot participa doar două
terminale punct-la-punct, dar care ulterior se poate dezvoltă
în una multipunct. MCU este format obligatoriu din
Controlerul Multipunct (MC) și, opțional, din Procesoare
multipunct (MP). În cel mai simplu caz, un MCU poate
consta numai dintr-un MC fără MP.
MC asigură negocierea cu toate terminalele pentru a
atinge niveluri de capacități comune de comunicații (ce
codecuri vor fi folosite), dar el nu efectuează mixarea sau
comutarea fluxurilor audio, video și de date. Funcțiile de
mixare, comutare sau alt tip de procesare a fluxurilor media
se asigură de MP sub controlul MC. Cotrolerul MC poate fi
fizic situat la Gatekeeper, Gateway, terminale, sau MCU.
(figura 1.6) [2].
Fig. 1.6 Locații posibile a MC și MP într-un sistem

H.323
14
Pe figură se prezintă și locația posibilă a procesorului.
Dacă în rețea sînt mai multe controlere MC atunci la
inițirea conferinței se desfășoară procedura de determinare
a echipamentului ”master - slave” pentru a identifica
controlerul MC care va administra această conferință.
1.6 Stiva de protocoale H.323
Protocolul H.323 este numit ”protocol umbrelă”

deoarece include o familie de protocoale. Mai jos ne vom
opri la principalele protocoale ale stivei de protocoale
H.323 și anume:
 Protocolul RAS (Ragistration, Admission and Status)
folosit pentru înregistrarea, admiterea și definirea statutului
dispozitivelor terminale ale rețelei;
 Protocolul de semnalizare apel H.225.0;
 Protocolul de control a canalelor logice H.245.
Fig. 1.7 Stiva de protocoale H.323 în mediul IP

15
Figura 1.7 [2] prezintă locul de plasare a protocoalelor
de semnalizări RAS, H.225.0 și H.245 în rețeaua bazată pe
IP.
Tot aici se observă și modul cum rulează protocoalele
aplicațiilor, fluxurilor media – de date, audio și vido.
Săgeata dintre H.245 și H.225.0 subliniază că mesajele
H.245 pot fi tunelate în H.225.0.
1.6.1 Protocolul RAS
RAS este protocolul de semnalizare utilizat între

gateway și gatekeeper [3]. Canalul RAS este deschis
înainte de orice alt canal și este independent de canalele
de transport media și de semnalizarea de apel (figura 1.8).
RAS folosește User Datagram Protocol (UDP) porturile
1719 (mesaje H.225 RAS) și 1718 (descoperire GK
multicast).
Fig.1.8 Deschiderea canalului RAS
16
Prin mesajele RAS se efectuează un șir de proceduri
după cum urmează:
 Descoperirea garekeeper-ului;
 Înregistrarea dispozitivelor terminale la GK;
 Controlul admiterii dispozitivelor terminale în rețea;
 Localizarea dispozitivelor terminale;
 Controlul benzii de trecere (ratei de biți) în procesul
servirii apelului;
 Obținerea informațiilor de stare de la dispozitivele
terminale.
Descoperirea gatekeeper-ului este o procedură prin
care dispozitivul final determină GK pentru a se înregistra la
el. Acest lucru poate fi realizat manual sau automat.
În cazul procedurii manuale dispozitivul final este
configurat cu adresa de transport a gatekeeper-ului asociat.
În acest fel, dispozitivul știe apriori cu care gatekeeper el
este asociat și deci se poate înregistra la el.
Descoperirea GK in mod automat se efectuează cu
ajutorul mesajelor de descoperire GK (tabelul 1.1):
Tabelul 1.1 Descoperirea GK

GRQ Cerere transmisă de dispozitivul
(Gatekeeper Request) final la GK.
GCF Răspuns de la GK în care se
(Gatekeeper Confirm) indică adresa de transport al
canalului RAS.
GRJ Răspuns al GK în caz de
(Gatekeeper Reject) respingere a înregistrării.
Dispozitivul final transmite în mod multicast mesajul

GRQ la portul UDP 1718 (bine-cunoscut). Unul sau mai
multe GK pot răspunde cu mesajul de confirmare GCF în
care se conține adresa de transport a canalului RAS (figura
1.9).
17
Terminal Gatekeeper
GRQ
GCF/GRJ
Fig.1.9 Descoperire GK automată
Dacă răspunsul este primit de la mai mulți GK atunci

dispozitivul terminal va alege unul la care se va înregistra în
continuare.
Înregistrarea este procesul prin care dispozitivul final se
alătură la o zonă și informează gatekeeper-ul despre
adresele sale de transport și lista adreselor alias.
Înregistrarea trebuie să se producă înainte de orice apel și
poate să se efectueze periodic în funcție de necesități.
În tabelul 1.2 sînt definite mesajele RAS de înregistrare
și de anulare a înregistrării a dispozitivelor finale la GK.
Tabelul 1.2 Înregistrarea la gatekeper

RRQ Trimis de dispozitivul terminal la
(Registration_Request) GK cu adresa canalului RAS.
RCF Răspuns al GK care confirmă
(Registration_Confirm) înregistrarea dispozitivului final.
RRJ Răspuns al GK care respinge
(Registration_Reject) înregistrarea dispozitivului final.
URQ Trimis de dispozitivul final sau de
(Unregister_Request) GK la anularea înregistrării.
UCF Trimis de dispozitivul final sau de
(Unregister_Confirm) GK pentru confirmarea anulării
înregistrării.
URJ Indică că înregistrarea
(Unregister_Reject) dispozitivul final nu a fost anulată
de GK
18
Dispozitivul final trimite cererea de înregistrare RRQ la
adresa de transport a canalului RAS al GK-lui care a fost
primită în procesul de descoperire (figura 1.10).
Gatekeeper-ul poate confirma înregistrarea (RCF) sau o
respinge (RRJ).
Terminal Gatekeeper
RRQ
RCF sau RRJ
Fig.1.10 Inițierea înregistrării terminalului la GK
Dispozitivul final poate anula înregistrarea prin

trimiterea cererii URQ la gatekeeper (figura 1.11). Acest
lucru permite dispozitivulul să modifice adresa alias
asociată cu adresa de transport sau invers. Gatekeeper-ul
răspunde fie cu un mesaj de confirmare UCF sau
respingere URJ în conformitate cu politica sa.
Terminal Gatekeeper
URQ
UCF sau URJ
Fig.1.11 Inițierea anulării înregistrării terminalului la GK
19
Gatekeeper-ul poate iniția anularea înregistrării unui
terminal prin trimiterea cerere URQ la acest dispozitiv
(figura 1.12). Terminalul răspunde cu un mesaj de
confirmare - anulare înregistrare (UCF). Înainte de inițierea
unui apel dispozitivul final va trebui să se re-înregistreze,
posibil la alt Gatekeeper.
Terminal Gatekeeper
URQ
UCF
Fig.1.12 Inițierea de GK anulării înregistrării terminalului
Controlul admiterii dispozitivelor terminale la resursele

de rețea se efectuează prin cererea Admission Reguest
(tabelul 1.3). Cererea de admitere ARQ se trimite de
dispozitivul final către GK la inițierea oricărui apel.
Tabelul 1.3 Mesajele de admitere

ARQ Încercare de un dispozitiv final de a
(Admission_Request) iniția un apel.
ACF Autorizație de GK la admiterea
(Admission_Confirm) apelului. Acest mesaj conține
adresa IP a gateway-ului terminal și
permite GW solicitant să inițieze
procedura de semnalizare pentru
controlul apelui.
ARJ Refuză cererea dispozitivului final
(Admission_Reject) de a avea acces la rețea pentru
aceast particular apel.
20
În mesaj se conține identificatorul dispozitivului care a
trimis cererea ARQ și adresele necesare ale dispozitivului
solicitat. Suplimentar se indică plafonul de sus al ratei de
biți de transmitere și de recepție a traficului utilizatorilor.
Gatekeeper-ul la admiterea apelului include în mesajul de
confirmare ACF valoarea plafonului de sus al ratei de biți și
adresa de transport a canalului de semnalizare a
terminalului solicitat. Dacă lățimea de bandă nu este
disponibilă GK trimite mesajul ARJ.
Localizarea dispozitivelor terminale (tabelul 1.4).
Dispozitivul terminal sau gatekeeper-ul care are adresa
alias pentru un punct final și ar dori să determine
informațiile lui de contact (adresele canalului de
semnalizare și canalului RAS) poate emite cererea de
locație (LRQ). Acest mesaj poate fi trimis la adresa
canalului RAS al unui anumit GK sau în mod multicast pe
adresa bine-cunoscută ( Gatekeeper`s Discovery Multicast)
a mai multor GK-e. Gatekeeper-ul la care punctul final
solicitat este înregistrat va răspunde cu mesajul de
confirmare a locației (LCF) care conține datele de contact
ale dispozitivului solicitat sau ale sale.
Tabelul 1.4 Mesajele de localizare

LRQ Solicită datele de contact pentru una sau
(Location_Request) mai multe adrese E.164.
LCF Confirmare de locație trimisă de GK și
(Location_Confirm) conține adresele canalui de semnalizare
sau canalui RAS ale sale sau ale
dispozitivilui terminal solicitat.
LRJ Locație respinsă-trimis de GK-ele care au
(Location_Reject) primit cererea de localizare LRQ și la care
dispozitivul terminal nu este înregistrat.
Gatekeeper-ul la care dispozitivul terminal solicitat nu

este înregistrat nu va răspunde la LRQ dacă cererea a fost
primită la adresa „Discovery multicast”.
21
Controlul ratei de biți. Controlul ratei de biți (lățimii de
bandă) se efectuează inițial prin secvența mesajelor de
admitere (ARQ / ACF / ARJ). Cu toate acestea,
gatekeeper-ul are posibilitatea să schimbe rata de biți a
dispozitivului terminal în serviciu. Tabelul 1.5 definește
mesajele RAS de control a ratei de biți.
Tabelul 1.5 Mesajele de control a ratei de biți

BRQ Cererea de creștere sau scădere a
(Bandwidth_ ratei de biți a apelului în desfășurare
Change_Request) trimisă de dispozitivul terminal la GK.
BCF Mesaj trimis de gatekeeper dacă
(Bandwidth_ confirmă acceptarea cererii de
Change_Confirm) modificare a ratei de biți.
BRJ Mesaj trimis de gatekeeper dacă
(Bandwith_ respinge cererea de modificare a ratei
Change_Reject) de biți.
Dacă inițiatorul schimbării ratei de biți este GK-ul atunci

dispozitivul terminal obligatoriu acceptă propunerea de
reducere de viteză și decide de sine stătător în caz de
creștere a ei.
Tabelul 1.6 Mesaje informații de stare
IRQ Cerere de stare trimisă de
(Information_Request) gatekeeper la dispozitivul terminal.
IRR Mesaj trimis de dispozitivul terminal la
(Information_Request_ gatekeeper ca răspuns la IRQ sau
Response) dacă ultimul a solicitat actualizărea
periodică a informației de stare.
IACK Confirmare trimisă de gatekeeper ca
(Informațion_Acknowle răspuns la mesajul IRR.
dgement)
INACK Infirmare trimisă de gatekeeper ca
(Information_Negative răspuns la pierderea sau reținerea
_Acknowledgement) mesajului IRR.
22
Informațiile de stare. Dispozitivul terminal poate colecta
și raporta informații despre apelurile servite care se
folosesc pentru calculele contabile sau de facturare.
Gatekeeper-ul poate solicita ca dispozitivul terminal să
raporteze aceste informații (tabelul 1.6).
Gatekeeper-ul nu ar trebui să solicite un anumit tip de
informații de la dispozitivul terminal dacă el nu a anunțat
despre abilitatea sa de a raporta aceste informații.
În faza finală de terminare a unui apel dispozitivul
terminal trimite la GK mesajul DRG (Disengage Request) la
care el va răspunde cu DCF (Disengage Confirm).
1.6.2 Protocolul de semnalizare apel H.225.0
Protocolul de semnalizare apel H.225.0[3] este utilizat

pentru stabilirea conexiunilor între dispozitivele terminale
ale rețelei H.323. Codificarea mesajellor este realizată prin
utilizarea recomandării ITU-T Q.931[4] elaborată anterior
pentru rețelele ISDN. În tabelul 4[3] sînt prezentate
mesajele obligatorii și opționale ale protocolului H.225.0
preluate din Q.931 pentru rețeaua bazată pe pachete. În
continuare vor fi expuse mesajele protocolului H.225.0 mai
des utilizate în procesul de semnalizare a apelului.
SETUP - mesaj trimis de partea apelantă în scopul
stabilirii unei conexiuni. Se transmite către portul TCP bine
cunoscut 1720 al dispozitivului terminal solicitat.
CALL PROCEEDING - mesaj prin care dispozitivul
terminal apelant este informat că apelul este acceptat și
este în proces de servire.
ALERTING - mesaj de informare a dispozitivului
apelant că utilizatorul solicitat nu este ocupat și e-a fost
trimis semnalul despre intrarea de apel.
CONNECT - mesaj de informare a dispozitivului
apelant că utilizatorul solicitat a acceptat apelul. Mesajul
posibil să conțină adresa de transport a canalului de control
H.245.
23
RELEASE COMPLETE – mesaj trimis de dispozitivul
terminal apelat sau apelant cu scopul de eliberare a
conexiunii.
Un scenariu de stabilire a unui apel cu implicarea GK-
lui este prezentat de figura 1.13.
Terminal 1 GK Terminal 2
ARQ(1)
ACF(2)
Setup (3)
Call proceeding (4)
ARQ(5)
ACF(6)
Alerting(7)
Connect(8)
Mesaje H.245
Mesaj RAS
Mesaj semnalizare apel H.225/0
Fig.1.13 Exemplu de scenariu semnalizare apel
24
Odată ce părțile au făcut schimb de mesaje de
semnalizare apel H.225.0 terminalele vor trece la stabilirea
canalului de control. Procedurile recomandării H.245 sînt
folosite peste canalul de control H.245 în scopul schimbului
de capabilități și de deschidere a canalelor media.
Un canal de semnalizare H.225.0 permite
transmisiunea mesajelor diferitor apeluri. Diferențierea
dintre mesaje se face după eticheta call reference. Aceasta
permite GW-lui se reducă simțitor timpul necesar pentru
stabilirea conexiunilor.
Mesajele H.225.0 în sine sînt codate în conformitate cu
regulile de codare pachet (PER- Packed Encoding Rules)
ale ASN.1 (Abstract Syntax Notation One) și transportate
de protocolul TCP.
1.6.3 Protocolul de control a canalelor logice H.245
Recomandarea ITU-T H.245 „Protocolul de control

pentru comunicații multimedia” (05/2011) specifică sintaxa
și semantica mesajelor de control a canalelor logice,
precum și un șir de proceduri folosite pentru negocierea în
bandă la începutul sau în timpul comunicării. Fiecare
terminal deschide doar un singur canal H.245 cu un alt
dispozitiv. Procedurile desfășurate pe canalul de control
H.245 asigură schimbul de capabilități dintre terminale și
deschiderea canalelor pentru transmisiunea fluxurilor
media. Acest canal logic cu numărul 0 permite terminalelor:
a) Determininarea dispozitivului terminal master și
terminal sclav în scopuri de management de protocol;
b) Schimbul de capabilități și preferințe de comunicare;
c) Deschiderea și închiderea canalele logice bi- sau
unidirecționale pentru fluxurile media;
d) Alegerea modului de funcționare;
e) Determinarea timpului de latență dus-întors;
f) Efectuarea semnalizării pe bucla locală în scopuri
de întreținere.
25
Procedurile de determinare master-sclav sînt
utilizate pentru a rezolva conflictele între două dispozitive
terminale care, de exemplu, încearcă să deschidă un canal
bidirecțional. Conform procedurii două puncte finale fac
schimb de mesaje MasterSlaveDetermination pentru a
determina care terminal va fi master și care sclav. Fiecare
terminal poate opera fie ca master sau ca sclav.
Dispozitivul terminal stabilește în cîmpul TerminalType o
valoare care corespunde tipului sau ( vezi tabelul 1 [2]) și
un număr aleatoriu în intervalul de la 0 pînă la ( 224 − 1) în
cîmpul StatusDeterminationNumber. Master va deveni acea
entitate care are în cîmpul TerminalType un număr mai
mare sau, dacă aceste cifre sunt egale, atunci acea care
are valoare inscrisă mai mare în cîmpul
StatusDeterminationNumber. Ca răspuns la mesajele
MasterSlaveDetermination primite ambele dispozitive
transmit mesaje de confirmare
MasterSlaveDetermlnatlonAck, unde se indică care
echipament va fi master și care sclav în această
comunicare.
Schimpul de capabilități între dispozitivele terminale
urmează procedurile definite în ITU-T H.245 [5], care
preved tratarea în mod separat a capabilităților de recepție
și de transmisie. Capabilitățile la recepție determină
abilitatea terminalului de a primi și procesa fluxurile
informațiile primite. Emițătorul va limita conținutul
informațiilor transmise la ceea ce a indicat receptorul că
este capabil de a primi. Capabilitățile la emitere descriu
abilitatea terminalului de a transmite fluxuri de informații.
Descrierea dată oferă terminalului receptor posibilitatea să
aleagă moduri de operare în care preferă să primească
informația.
Coordonarea modului de funcționare între terminale se
efectuează prin schimbul de mesaje TerminalCapabilitySet.
26
În aceste mesaje este inclus tabelul CapabilityTable unde
fiecărui tip de audio sau video codec i se atribuie un
anumut număr. De exemplu, codecurilor audio G.723.1,
audio G.728 și video H.263 le-au fost atribuite numere
separate (1, 2 și 3 respectiv).
Numerele secvențiale enunțate se grupează în structuri
numite AlternativeCapabilitySet. Fiecare set indică modul în
care terminalul este capabil să operareze. De exemplu, o
listă AlternativeCapabilitySet {G.711, G.723.1, G.728}
înseamnă că terminalul poate funcționa în oricare dintre
aceste moduri audio, dar numai în unul. Aceste seturi de
capabilități alternative se grupează în structuri
SimultaneousCapabilities de funcționare simultană. De
exemplu, structura SimultaneousCapabilities care conține
două liste în AlternativeCapabilitySet, anume {H.261,
H.263} și {G.711, G.723.1, G.728}. Aceasta înseamnă că
terminalul pote funcționa simultan cu un codec video și
oricare dintre codec-urile audio.
Capabilitățile actuale stocate în capabilityTable sînt
adesea mai complexe decît prezentate aici. Pentru o detalii
se poate consulta [5].
Dispozitivele terminale au posibilitatea la orice fază a
conexiunii să adaugă noi funcționalități sau să excludă
unele deja enunțate anterior prin transmiterea mesajelor
TerminalCapabilitySet. Terminalul care a receptionat
mesajul TerminalCapabilitySet va trimite mesajul de
confirmare TerminalCapabilitySetAck.
Deschiderea și închiderea canalele logice bi- sau
unidirecționale pentru fluxurile media. Pe fiecare canal logic
se transmit fluxuri informaționale de la un emițător la unul
sau mai multe receptoare. Fiecare dintre ei este identificat
printr-un număr de canal logic, care este unic pentru fiecare
direcție de transmisie. Canale logice sînt deschise și
închise folosind mesajele și procedurile ITU-T H.245:
Terminalul inițiator va trimite mesajul
OpenLogicalChannel. În cazul în care canalul logic
27
transportă fluxuri media utilizînd RTP (audio sau video)
mesajul OpenLogicalChannel va include parametrul
mediaControlChannel care conține adresa de transport a
protocolului de control RTCP. Terminalul receptor răspunde
cu un mesaj OpenLogicalChannelAck. În cazul în care
canalul logic va transporta datele media folosind RTP
unicast, atunci mesajul OpenLogicalChannelAck va include
atît parametrul MediaChannel cu adresa de transport a
protocolului RTP, cît și parametrul MediaControlChannel cu
adresa de transport a canalului RTCP. Dacă cererea a fost
pentru un canal logic unidirecțional, mesajul
OpenLogicalChannelAck indică acceptarea canalului
unidirecțional. În cazul unei cereri pentru un canal logic
bidirecțional, mesajul indică acceptarea canalui logic
bidirecțional și indică parametrii corespunzători pentru
canalul revers.
Închiderea canalelor logice poate fi efectuată cu
mesajul CloseLogicalChannel care este folosit de regulă
pentru a sprijini servicii suplimentare, cun ar fi ”plasat în
așteptare”. Pentru o încheiere de conexiune obișnuită
terminalele fac schimb de mesaje EndSessionCommand.
După schimbul de aceste mesaje sînt închise nu numai
canalele logice dar și canalul de control H.245.
Alegerea modului de funcționare este utilizat de
terminalul receptor pentru a solicita anumite moduri de
transmisie de la terminalul de transmisie. De fapt este o
listă în ordinea de preferință (cel mai de preferat în primul
rînd) a modurilor care terminalul ar dori să primească.
Fiecare mod este descris cu ajutorul unui ModeDescription
care la rîndul său este definit de unul sau mai multe
elemente ModeElements.
ModeElement indică tipul de flux elementar care este
solicitat și, opțional, modul de multiplexare. Tipul de flux
elementar poate fi: Videomode, AudioMode, DataMode,
EncryptionMode și H235Mode. H235Mode indică faptul că
se solicită criptarea informației media.
28
Determinarea timpului de latență dus-întors este
utilizat de entitatea Mode Request Signalling Entity în caz
de timeout. Terminal de ieșire trimite cererea
RoundTripDelayRequest la care terminalul de intrare
răspunde prin RoundTripDelayResponse. Timpul de
propagare a semnalului între două terminale de
comunicare determină întârzierea dus-întors.
Semnalizărea pe bucla locală în scopuri de
întreținere folosește un set de mesaje. Cererea
MaintenanceLoopRequest solicită un anumut tip de buclă.
De exemplu, mesajele mediaLoop și logicalChannelLoop
solicită buclă locală pe un singur canal logic (indicat de
LogicalChannelNumber), în timp ce mesajul systemLoop se
referă la toate canalele logice. Partea vizată răspunde prin
MaintenanceLoopAcknowledge pentru a confirma că
terminalul va efectua bucla conform solicitării sau prin
MaintenanceLoopReject dacă terminalul nu va efectua
bucla.
La primirea comenzi MaintenanceLoopCommandOff
terminalul va deconecta toate buclele și va restabili
canalele audio, video și de date la starea lor normală.
1.7 Exemplu setare apel cu implicarea GK
În finalul expuneri protocolului H.323 se va examina un

exemplu de setare a unui apel între două terminale (de
exemplu, telefoane IP) ale rețelei H.323 (figura 1.14). Se
presupune că în rețea se utilizează gatekeeper-ul. Ambele
terminale sînt înregistrate la acest GK cu utilizarea
mesajelor RAS (vezi tabelul 1.2).
29
TERMINAL1 GK TERMINAL2
Admision Request
Amision Confirm
Setup
CallProceeding
Admision Request
Amision Confirm
Alerting
Connect
TerminalCapabilitySet
MasterSlaveDetermination
TerminalCapabilitySet + Ack
MasterSlaveDetermination +Ack
TerminalCapabilitySetAck
MasterSlaveDeterminationAck
OpenLogicalChannel
OpenLogicalChannel+Ack
OpenLogicalChannelAck
Fluxuri informaționale RTP
EndSessionCommand
EndSessionCommand
ReleaseComplete
DisengageRequest DisengageRequest
DisengageConfirm DisengageConfirm
Fig. 1.14 Fazele de stabilire a unei conexiuni

Notă: RAS; H.225.0; H.245.
30
Terminalul1 care inițiază apelul cunoaște numărul
apelat dar nu cunoaște adresa IP asociată cu acest număr.
Deacea el trebuie să solicite permisiunea GK de a efectua
apelul prin trimiterea cererii de admitere. Cererea de
admitere (ARQ) va conține numărul apelat care va fi
rezolvat la adresă IP a terminalului2. Prin răspunsul său
ACF gatekeeper-ul anunță această adresă terminalului1
(modelul de apel direct, nu prin GK). Terminalul1 va
deschide un canal de semnalizare H.225.0 la adresa
furnizată de GK și trimite mesajul Setup. Terminalul2 va
răspunde mai întîi cu mesajul H.225.0 CallProceeding
pentru a indica că a început să lucreze la stăbilirea apelui.
După aceea terminalul2 va cere permisiunea de apel de la
GK cu mesajul ARQ. La care GK-ul răspunde cu
confirmarea de admitere ACF. Telefonul apelat începe să
sune și acest lucru este semnalat celeilalte părți cu mesajul
H.225.0 de alertare. Partea apelată ridică receptorul și
terminalul2 semnalează că apelul a fost acceptat prin
trimiterea mesajului H.225.0 Connect. Prin acest mesaj se
transmite și adresa canalui de control H.245.
Din acest moment părțile vor trebui să negocieze
parametrii pentru canalele audio, opțional și video. Pentru
aceste negocieri sînt folosite mesajele protocolul H.245.
Terminalul1 deschide un canal TCP la adresa H.245 care a
primit-o prin mesajul Connect. Terminalele pot începe
schimbul de mesaje H.245. Negocierea H.245 are trei părți:
 Decide care terminal va fi "master" și care "sclav".
Acest lucru este mai important pentru conferințe cu mulți
participanți, decît pentru un apel de două parți. Dar totuși
se efectuează și în acest caz.
 Schimbul de informații cu privire la setul de
capabități ale fiecărei părti. Fiecare terminal trebuie să știe
ce codec-uri audio și video acceptă cealaltă parte.
31
 Negocierea canalelor logice. Se decide cu privire la
parametrii canalui audio (opțional și video) - adică ce
codec-uri vor fi utilizate și care sînt adresele IP și porturile
pentru fluxurile RTP.
În cele din urmă, cele două terminale pot începe să
trimită fluxurile informaționale RTP și cei doi se vor auzi
unul pe altul. Rețineți că fiecare din cele două direcții pot fi
codificate cu diferite codecuri.
La terminarea apelului cînd una dintre părți pune
receptorul pe furcă se desfășoară următoarele evenimente:
1. Terminalul1 care a inițiat finalizarea apelului va opri
transmiterea fluxurilor RTP, va închide canalele logice și va
transmite pe canalul de control mesajul H.245
EndSessionCommand, ceea ce înseamnă că utilizatorul
dorește să elibereze conexiunea. De la terminalu2 se
așteptată mesajul de răspuns EndSessionCommand și
apoi canalul de control H.245 se închide.
2. În cazul în care canalul de semnalizare H.225.0 este
încă deschis, terminalul1 trimite mesajul ReleaseComplet.
3. Fiecare dintre cele două terminale informează GK-ul
despre finalizare apelului cu mesajul DRQ iar gatekeeperul
confirmă cu mesajul DCF.
Scopul acestui exemplu de conexiune a fost de a oferi
o privire de ansamblu. Pentru mai multe detalii se poate de
consultat standardul H.323 [2].
32
2. PROTOCOLUL H.248/MEGACO
2.1. Sumar
Protocolul de control a gateway-lui H.248/MEGACO

(MEdia GAteway COntrol) a fost elaborat separat de
Uniunea internațională a telecomunicațiilor ITU și de Grupul
operativ de inginerie a internetului (Internet Engineering
Task Force - IETF). Primele versiuni ale protocolului au fost
publicate în anul 2000 de ITU sub recomandarea H.248 iar
de IETF în standardul RFC 3015 numit Megaco. Ulterior în
cadrul ITU protocolul a evoluat spre versiunea a doua
H.248.1 publicată în 2002 apoi versiunea a trea din 2005.
Pe cînd IETF a publicat în 2003 prin standardul Mecago
RFC 3525 o dezvoltare a versiunii 1. După unirea a două
variante a protocolului ITU și IETF intr-un program comun
de dezvoltare RFC 3525 a fost declarat istoric. Toată
responsabilitatea pentru dezvoltarea de mai departe a
protocolului de control a GW-lui a fost preluată de ITU. În
prezent în vigoare este recomandarea H.248.1 versiunea 3
din martie 2013 [6]. Extensiile H.248.1 apar ca noi
recomandări, suplimentare care sînt numerotate H.248.XX.
La momentul scrierii acestui curs de prelegeri au fost
publicate recomandările numerotate pînă la XX=93, anume
H.248.93 din octombrie 2014.
Pentru a realiza o mai mare scalabilitate, în
recomandarea H.248.1 funcția de gateway H.323 se
descompune (în eng. decompose) în subcomponente
funcționale media gateway (MG) și media gateay controler
(MGC) (figura 2.1).
Acest lucru permite, de asemenea, ca gateway-urile să
fie compuse din componente de la mai mulți furnizori și să
fie distribuite pe diferite platforme fizice.
33
Rețea comutație pachete IP
MGC
H.248 H.248
MG1 RTP MGn
E1 E1
PSTN/ISDN PSTN/ISDN
Fig. 2.1 Descompunerea media gateway H.323
Recomandarea H.248.1 definește protocoalele utilizate

între elemente ale unui astfel gateway descompus fizic.
Relația componentelor protocolului MEGACO este de tip
stăpîn-sclav (eng. master-slave). Un MGC (master) poate
dirija unul sau mai multe MG-uri (slaves) pe cînd un MG
logic sau fizic se poate înregistra doar la un singur MGC.
2.2. Modelul de conexiune H.248
Înainte de a descrie procedurile protocolui și pentru a

înțelege acțiunile comenzilor H.248 este necesar a vedea
cum arată modelul intern al unui MG. Acest model MG este
o construcție logică și nu implică niciun fel de constrîngeri
asupra hardware sau firmware. Figura 2.2 prezintă
structura unui exemplu de model de conexiune H.248.
34
Terminație
Terminație Canal SCN
Flux RTP Terminație
Context Canal SCN
Terminație Terminație
Flux RTP Canal SCN

Context Context NULL
Terminație Terminație
Flux RTP Canal SCN

Context
Gateway media
Fig. 2.2 Exemplu de model de conexiune H.248.1
Modelul de conexiune al protocolului prezintă entitățile

logice din cadrul Media Gateway (MG) care sunt controlate
de către Media Gateway Controler (MGC). Principalele
abstracții utilizate în acest modelul de conexiune sînt
terminația și contextul.
Terminația inițiază sau oprește unul sau mai multe
fluxuri media. De exemplu, într-o conferință multimedia, în
35
care terminația poate fi multimedia, ea pornește sau
oprește mai multe fluxuri media.
Contextul este o asociere logică dintre cîteva terminații.
Există un tip special de context, numit contextul NULL, care
contine toate tipurile de terminații care nu sunt prezente în
orice alt context. De exemplu, într-un gateway de acces
descompus, toate liniile inactive (libere) sînt reprezentate
de terminații în contextul NULL.
Diagrama din figura 2.2 reprezintă cîteva exemple de
posibile contexte. Cutia asterisc reprezintă asocierea logică
a terminațiilor incluse în context.
2.2.1 Terminația
Terminațiile sînt de două tipuri, fizice și efemere.

Terminația fizică reprezintă o entitate fizică, de exemplu, un
canal TDM. Ea există atît timp cît este acest canal în GW.
Terminația efemeră reprezintă un flux RTP și există doar
pe durata sesiunii.
Terminația este descrisă de un număr de proprietăți
caracteristice care sînt grupate într-un set de descriptori.
Ea poate genera sau recepționa anumite semnale.
Terminațiile pot fi programate pentru a detecta evenimente
ale căror apariție poate declanșa acțiuni din partea MG sau
mesaje de notificare a MGC.
Protocolul H.248 poate fi folosit pentru a crea noi
terminale și modifica proprietățile celor existente. Aceste
modificări includ posibilitatea de a adăuga sau elimina
evenimente și/sau semnale.
Fiecare terminație are identificator unic
(TerminationID), atribuit de către MG în momentul creării ei.
De exemplu, pentru o terminație fizică în calitate de
identificator poate servi numărul fluxului digital E1 și
numărul slotului timp în acest flux. Dacă cererea trebuie
adresată la toate terminațiile atunci se folosește un
indentificator comun Root. Cu TerminationID se utilizează
36
și un mecanism de adresare în grup (wildcards): ALL și
CHOOSE. Primul este utilizat pentru a se adresa simultan
la mai multe terminale, al doilea - oferă gateway-lui dreptul
de selectare a terminației corespunzătoare.
2.2.2 Contextul
Contextul este o asociere între un număr de terminații

prin care se descrie topologia conexiunii. Numărul maxim
de terminații într-un context depinde de proprietățile MG.
Gateway-urile care oferă doar conectivitate punct-la-punct
permit cel mult două terminatii pe context, iar cele care
susțin conferințe multipunct permit trei sau mai multe
terminații pe context.
Atributele contextului sînt:
 Identrificatorul (ContextID).
 Descriptorul topologiei. Topologia contextului descrie
fluxurile informaționale între terminațiile lui, deci în interiorul
GW-lui. Contrar, proprietatea similară a unei terminații (de
exemplu, "SendOnly", "RecvOnly") descrie fluxurile
informaționale de ieșire/intrare la gateway.
 Indicatorul de prioritate. El indică GW-lui cu ce
prioritate trebuie să fie tratat contextul. De exemplu, la
restartarea gateway-lui, atunci cînd o mulțime de contexte
trebuie tratate simultan MGC poate utiliza indicatorul de
prioritate pentru a nivela traficul și controla succesiunea
pornirii contextelor. Prioritatea poate avea 16 nivele, în
creștere de la 0 pînă la 15.
 indicator pentru apelurile de urgență cu cea mai
înaltă prioritate.
Protocolul are comenzi pentru a crea contexte, a
adăuga sau a scote terminații din contextele existente,
precum și pentru a deplasa terminația dintr-un context în
altul. Contextul se șterge implicit atunci cînd se lichidează
ultima terminație rămasă.
37
2.3 Comenzile H.248
Protocolul H.248 prevede 8 comenzi pentru

manipularea contextelor și terminațiilor. Cele mai multe
comenzi sînt trimise de MGC pentru controlul MG. Exepție
fac comenzile Notify și ServiceChange: Notify este trimisă
de la Media Gateway la Media Gateway Controller, iar
ServiceChange poate fi trimisă de ambele entități.
Comenzile protocolului H.248 cu descrierea lor de
ansamblu:
1. Add. Comanda Add adaugă o terminație la
contextul indicat prin ContextID. Dacă în comandă nu se
specifică contextul atunci va fi creat un nou context. În
cazul cînd în loc de TerminationID se indică simbolul de
grup $, atunci se crează o nouă terminație efemeră care va
fi atribuită contextului.
2. Modify. Comanda Modify modifică proprietățile
terminației, evenimentele recepționate sau semnalele
trimise de terminație.
3. Subtract. Comanda Subtract elimină terminația din
context. În răspuns la această comandă MG poate să
transmită MGC date statistice despre participarea
terminației în context. Dacă comanda exlude ultima
terminație din context atunci se lichidează și contextul.
4. Move. Comanda Move deplasează terminația dintr-
ul context în altul. Ea nu se folosește pentru mutarea
terminației în contextul NULL sau scoaterea terminației din
acest context, deoarece aceste manipulări se efectuează
cu ajutorul comenzilor Add și Subtract.
5. AuditValue. Cu această comandă MGC cere
informații curente privind proprietățile terminației,
evenimentele recente sau semnalele transmise în canal,
precum și datele statistice acumulate la moment.
38
6. AuditCapability. Cu această comandă MGC solicită
de la MG informații privind toate valorile posibile pentru
proprietăți, evenimente și semnale ale terminației.
7. Notify. Comanda Notify permite MG-lui să
informeaze MGC de apariția unor evenimente în gateway.
8. ServiceChange. Comanda permite MG-ului să
informeze controlerul MGC că o terminație sau un grup de
terminații este pe cale să fie scos din serviciu sau tocmai va
fi întors în serviciu. ServiceChange este de asemenea
folosită de către MG ca să anunțe disponibilitatea sa de
înregistrare la MGC, precum și să notifice MGC de intenția
sau efectuarea restartării MG. Prin trimiterea acestea
comanzi MGC poate anunța MG despre handover
(transfer). MGC poate utiliza de asemenea ServiceChange
pentru a instrui MG să introducă sau să scoată din serviciu
o terminație sau un grup de terminații.
2.4 Descriptorii H.248
Parametrii unei comenzi sînt numiți descriptori.

Descriptorul se definește ca element sintactic al
protocolului care grupează proprietățile conexe. De
exemplu, proprietățile unui flux media din MG poate fi setat
de MGC prin includerea descriptorilor corespunzători în
comandă. Un descriptor constă dintr-un nume și o listă de
elemente. Unele elemente pot avea valori.
Așa dar parametrii comenzii sînt structurați într-un
număr de descriptori. În general, formatul text al unui
descriptor este:
DescriptorName=<someID>{parm=value,parm=value...}.
Mai jos se enumeră unii dintre acesti descriptori.
Mux. Descriptorul multeplexare Mux descrie tipul
purtătoarelor fluxurilor multimedia. Descriptorul include
următoarele tipuri de multiplexare: H.221, H.223, H.226,
V.76 și N × 64K. Sînt posibile extensii.
39
Media. Descriptorul Media specifică parametrii pentru
toate fluxurile media. Acești parametri sînt structurați în doi
descriptori: TerminationState Descriptor, care specifică
proprietățile unei terminații care nu sînt dependente de flux
și unul sau mai mulți descriptori Stream fiecare dintre care
descrie un singur flux media. În cadrul descriptorului
Stream există pînă la patru descriptori subsidiari:
LocalControl, Local, Remote și Statistics. Relația ierarhică
dintre acesti descriptori este astfel:
Media Descriptor
TerminationState Descriptor
Stream Descriptor
LocalControl Descriptor
Local Descriptor
Remote Descriptor
Statistics Descriptor
TerminationState. Descriptorul stare terminație

TerminationState conține proprietatea ServiceStates,
proprietatea EventBufferControl și posibil alte proprietăți
care nu sînt specifice fluxului media.
Proprietatea ServiceStates descrie starea generală a
terminației. O terminație poate fi în una din următoarele
stări: "Test", "OutOfService" sau "InService". Starea "Test"
indică faptul că terminația este testată, starea
"OutOfService" indică faptul că terminația nu poate fi
utilizată în trafic, starea "Inservice" indică faptul că o
terminație poate fi sau este utilizată în trafic normal. Starea
implicită este "InService".
Proprietatea EventBufferControl specifică dacă
evenimentele detectate sînt memorate sau procesate
imediat.
Stream. Descriptorul Stream specifică parametrii unui
singur flux bidirecțional.
40
LocalControl. Descriptorul LocalControl conține
proprietățile Mode, ReserveGroup și ReserveValue,
precum și cele care sînt specifice fluxului media.
Valorile permise pentru proprietatea Mode sînt: doar
trimite "SendOnly", doar recepționează "RecvOnly", trimite
și recepționează "SendRecv", inactiv "Inactive" și boclă
locală "loopback". Valorile "SendOnly", "RecvOnly" și
"loopback" sînt în raport cu exteriorul contextului. De
exemplu, dacă un flux este setat în modul = "SendOnly"
atunci terminația nu pasează media recepționate în context
și poate transmite informația doar entităților în afara
contextului. Valoarea implicită pentru proprietatea Mode
este inactiv "Inactive".
Proprieățile ReserveValue și ReserveGroup indică MG
ce resurse trebuie să rezerve cînd primește un descriptor
Local sau Remote. În cazul în care valoarea unei
proprietăți Reserve este "True" (adevărat) atunci MG
rezervă resurse pentru toate cazurile specificate în
descriptorii Local și Remote dacă le are disponibile la
moment. Dacă valoare este ”False” MG va rezerva un
singur grup media din fiecare descriptorilor Local și
Remote. Funcțiile ReserveValue și ReserveGroup sînt
analogice. Prima indică MG să rezerve resurse pentru un
singur set de proprietăți (de exemplu, un singur codec cu
atributele asociate acesteia), pe cînd cu a doua indică ca
MG trebuie să rezerve resursele pentru a sprijini un grup
sau mai multe grupuri fluxuri media.
Local și Remote. MGC utilizează descriptorii Local și
Remote pentru a indica MG să rezerve și să aloce resurse
pentru decodarea și codarea fluxurilor media la terminația
la care se aplică. Descriptorul Local se referă la
proprietățile fluxurilor media pe care MG le primește de la
entitatea distantă. Descriptorul Remote se referă la
proprietățile fluxurilor media pe care MG le trimite entității
distante.
41
Events. Descriptorul Events conține un RequestID și o
listă de evenimente pe care Media gateway trebuie să le
detecteze și despre care să raporteze. Sub eveniment se
înțelege, de exemplu, tonuri de disc sau de fax, ridicarea
sau punerea receptoriului pe furcă, etc. RequestID-ul este
folosit pentru a corela cererea cu notificările pe care
aceasta le-ar putea declanșa și el este omis în cazul în
care descriptorul Events este gol (adică, evenimente nu se
specifică).
Signals. Descriptorul Signals conține setul de semnale
pe care gateway-ul îl solicitată de la terminație. Aceste
semnale sînt de exemplu, tonuri, anunțuri sau semnale
legate de butonul de furcă (hookswitch). Semnalele mai
complexe pot include o secvență de astfel de semnale
simple.
Există trei tipuri de semnale:
• OnOff (OO) - semnalul durează pînă cînd este oprit,
de exemplu, de un descriptor Signals gol.
• TimeOut (TO) - semnalul durează pînă cînd o
perioadă specificată de timp expiră sau este oprit (ca mai
sus).
• Brief (BR) - semnalul este foarte scurt și se va opri de
la sine. În acest caz nu este nevoie de careava valoare de
timeout.
Audit. Descriptorul Audit specifică ce informații MGC
dorește să verifice. Descriptorul de audit precizează lista de
descriptori sau proprietăți individuale care urmează să fie
returnate de MG. Audit poate fi folosit în orice comandă
pentru a solicita de la MG trimiterea a careva descriptor cu
valorile curente referitor la evenimentele, semnalele,
statisticile și proprietăților sale. Printre discriptorii solicitați
pot fi: Mux, Event, Media, Signals, ObservedEvents,
Statistics și alții.
ServiceChange. Descriptorul ServiceChange se
include doar în comanda cu același nume și indică ce tip de
schimbări sau produs sau se vor produce în serviciu.
42
Descriptorul poate conține un șir de parametri după
necesitate. Parametrul Method indică, de exemplu, că
terminațiile specificate vor fi scoase din serviciu cu careva
reținere sau imediat. Parametrul Reason specifică cauza
schimbării în serviciu, parametrul Address determină
adresa pentru comunicațiile ulterioare, etc.
DigitMap. Descriptorul DigitMap descrie planul de
numerotare utilizat în rețea. DigitMap este un plan de
apelare rezident în Media gateway în corespundere cu care
se efectuează detectarea și raportarea cifrelor primite de
terminație. Planul de numerotare poate fi descărcat în MG
în prealabil prin acțiuni de management sau definit într-un
descriptor DigitMap inclus în oricare din comenzile standard
ale protocolului utilizate pentru manipularea terminației.
Colecția de cifre al planului DigitMap este protejată de trei
cronometre, anume, timer de pornire (T), timer scurt (S) și
timer lung (L).
1. Timerul de pornire (T) determină duratei de așteptare
a pornirii culegerii cifrelor adresei solicitate în corespundere
cu Digitmap. Cronometrul de pornire poate fi dezactivat (T
= 0), atunci MG va aștepta nelimitat venirea cifrelor.
2. Dacă în corespundere cu planul de apelare MG
determină că este nevoie de cel puțin încă o cifră, atunci el
va mai aștepta un timp egal cu durata determinată de
timerul lung (L) (de exemplu, 16 secunde).
3. În cazul în care șirul de cifre se potrivește unui model
din digitmap, dar este posibil să mai sosească alte cifre
care ar duce la un alt model din planul de apelare, atunci
MG nu raportează imediat numărul solicitat dar mai
așteaptă un timp egal cu valoarea cronometrului scurt (S) și
după acea decide care plan este vizat.
Pentru informații detaliate referitor la descriptorii
enumerați mai sus precum și despre alti descriptori ne
menționați aici se poate consulta recomandarea H.248.1[6].
43
2.5 Tranzacții H.248
Comenzile dintre Media Gateway Controller și Media

Gateway sînt grupate în tranzacții, fiecare dintre care este
identificată de un TransactionID. Tranzacția constă din una
sau mai multe acțiuni. O acțiune la rîndul său este compusă
dintr-o serie de comenzi al unui context (figura 2.3).
TRANZACȚIAx
Contextul1
(Acțiunea1) Comanda1 Comanda2
Comanda3 Comanda4
Contextul2
(Acțiunea2) Comanda1
Contextul3
(Acțiunea3) Comanda1 Comanda2
Comanda3
Fig.2.3 Tranzactii, acțiuni și comenzi
Comenzile în cadrul unei tranzacții se procesează

secvențial în ordinea în care ele apar în tranzacție. După
procesarea fiecărei cereri TransactionRequest se răspunde
prin TransactionReply. Răspunsul TransactionReply
44
include rezultatele procesării pentru toate comenzile din
cererea TransactionRequest corespunzătoare.
TransactionReply include valorile returnate pentru
comenzile care au fost executate cu succes și descriptorul
de eroare pentru comenzile care au eșuat.
Multiple tranzacții pot fi concatenate într-un mesaj.
Antetul mesajului include identitatea expeditorului.
Identificatorul mesajului (MID - Message Identifier) este un
nume prestabilit (de exemplu, adresa de domeniu, numele
de domeniu, numele dispozitivului) a entității care a
transmis mesajul. Dacă implicit atunci se recomandă
utilizarea numelui de domeniu.
Tranzacțiile dintr-un mesaj sînt tratate în mod
independent. Nu există nici o ordine prestabilită. Mesajul
este în esență doar un mecanism de transport.
2.6 Exemplu de setare a unui apel H.248
Exemplu de scenariu adus (figura 2.5) ilustrează

utilizarea elementelor protocolului H.248 pentru setarea
unui apel de la un GW rezidențial la altul printr-o rețea
bazată pe IP. Pentru simplitate în exemplu se presupune
că ambele gateway-uri rezidențiale implicate în apel sînt
controlate de același Media Gateway Controller (vezi
Apendixul I din [6]). Solicitantul User A este conectat la
RGW1 iar abonatul solicitat – la RGW2. Exemplu descrie
fazele unui apel de succes. Procedura poate fi divizată în
două procese: (i) stabilirea conexiunii media RTP și (ii)
eliberearea conexiunii date după finalizarea sesiunii media.
Pentru o mai bună claritate se aduc listingurile primilor
comenzi cu discifrarea detaliată.
45
RGW1 MGC RGW2
User A Service Change User B
Modify Service Change

Modify
A off-hook
Notify
Tonul disc Modify
Trimiterea
cifrelor Notify
Add
Modify Add
Revers
apel Apelare
B off-hook
Notify
Modify
Modify
RTP Media
AuditValue
AuditValueReply
B on-hook
Notify
A on-hook
Subtract
Subtract
Fig. 2.4 Scenariu de setare al unui apel H.248
În acest exemplu, adresele IP sînt: pentru RGW1 este

124.124.124.222, pentru RGW2 este 125.125.125.111, iar
46
pentru MGC este 123.123.123.4. Portul MEGACO este
numărul 55555 pentru toate cele trei entități.
1. RGW1 se înregistrează la MGC cu comanda
ServiceChange:
RGW1 to MGC:
MEGACO/1 [124.124.124.222]
Transaction = 9998 {
Context = - {
ServiceChange = ROOT {Services {
Method=Restart, Version=3,
ServiceChangeAddress=55555,
Profile=ResGW/1}
}}}
În calitate de identificator al terminației se folosește

ROOT, adică rădăcină, deoarece comanda nu se referă la
o anumită terminație dar la GW-ul intregral.
2. În răspuns MGC transmite Replay (pe diagramă nu

se prezintă). De fapt la fiecare comandă se trimite un
Reply, care pentru simlificare nu sînt prezentate pe
diagramă.
MGC to RGW1:
MEGACO/1 [123.123.123.4]:55555
Reply = 9998 {
Context = - {ServiceChange = ROOT {
Services {ServiceChangeAddress=55555}}}}
3. Cu comanda Modify MGC programează terminația

User A în contextul NULL. TerminationID este A4444,
streamID este 1, requestID în descriptorul Events este
2222. Identificatorul mesajului (MID) expeditorului este
adresa IP și portul [123.123.123.4]:55555. Proprietatea
Mode pentru flux este setat la inactiv. Notația "al"
47
semnifică ”linie analogică” a pachetului de supraveghere.
Se presupune că sînt prevazuți descriptorii Local și
Remote.
MGC to MG1:
MEGACO/3 [123.123.123.4]:55555
Transaction = 9999 {
Context = - {
Modify = A4444 {
Media { Stream = 1 {
LocalControl {
Mode = Inactive,
tdmc/gain=2, ; in dB,
tdmc/ec=on
},
}
},
Events = 2222 {al/of {strict=state}}
}
}
}
Un schimb similar se intampla dintre RGW2 și MGC,

rezultînd cu înregistrarea terminației A5555 ca fiind
inactivă.
Planul de apelare DigitMap poate fi încărcat în RGW
anterior. Atunci funcția gateway-ului ar fi să aștepte
ridicarea receptorului de pe furcă (off-hook), pornirea
tonului de disc și începerea colectării cifrelor DTMF. În
acest exemplu vom folosi DigitMap, care este trimis de
MGC după ce este detectată ridicarea receptorului.
Evenimentele desfășurate în continuare pot fi explicate
succint după cum urmează:
Utilizatorul User A ridică receptorul (off-hook). RGW1
detectează această schimbare și anunță MGC prin
comanda Notify. MGC prin comanda Modify indică
48
terminației să trimită tonul de disc apelantului și să aștepte
venirea cifrelor în conformitate cu planul de apelare prezen
în comandă. În continuare cifrele în măsura culegerii lor de
User A sînt acumulate de RGW1. Tonul de disc este oprit
după detectarea primei cifre. După primirea de terminația
A4444 a tuturor cifrelor la MGC se trimite un alt Notify.
Controlerul analizează cifrele și determină direcția de
plecare spre RGW2. Terminația fizică A4444 și terminația
efemeră se adaugă la un nou context în MG1 cu utilizarea
comenzilor Add.
Similar prin comenzi Add MGC va indica RGW2 să
includă terminația fizică A5555 și terminația efemeră (de
exemplu, cu ID-ul A5556) a fluxului RTP stabilit într-un nou
context. MGC stabilește de asemenea trimiterea apelului
pe A5555 pentru chemarea User B. În răspuns (Reply-urile
pe diagramă sînt omise) RGW2 trimite adresa IP și
numărul potrului rezervate pentru această conexiune. Cu
comanda Modify MGC trimite informațiile obținute spre
RGW1 indicînd și aplicarea semnalului revers apel pe
terminația utilizatorului A. Cele două gateway-uri sînt acum
conectate între ele. RGW2 așteaptă pînă ce User2 ridică
receptorul și trimite Notify la MGC.
MGC generează o tranzacție către RGW2 cu două
comenzi Modify, care aduc la schimbarea modului de
funcționare a ambelor terminații în sendrecv
(bidirecțional–trimite/recepționează) și oprirea semnalului
de apel. În mod similar controlorul trimite Modify la RGW1
pentru stoparea revers apelului și includerea modului de
funcțiolare a terminațiilor fizice și efemere în sendrecv.
Acum cei doi utilizatorii pot începe conversația (RTP
Media). Dacă pe parcurs se decide audierea careva
terminații se utilizează comanda AuditValue. În exemplu se
presupune că MGC verifică terminația RTP în RGW2.
Apelul poate fi terminat fie de către utilizatorul apelant
sau de cel apelat. Aici se presupune că primul a pus
receptorul (on-hook) utilizatorul chemat. Acest eveniment
49
este raportat de RGW2 la MGC prin comanda Notify. MGC
trimite acum la ambele gateway-uri comenzi Subtract, cîte
una pentru fiecare terminație. RGW1 precum și RGW2
elimină fiecare cele două terminații din context. Împreună
cu ultima terminație se lichidează și contextul.
Este posibil ca MGC să solicite includerea în răspuns
primite de la RGW-uri a statisticii.
În final controlorul stabilește ca fiecare gateway să fie
gata pentru a detecta următorul eveniment off-hook. Este
posibil ca terminației să revine în contextul NULL în mod
implicit.
BIBLIOGRAFIE
1. I. Nazaroi. Sisteme și rețele de comunicații digitale.
Partea1. Ciclu de prelegeri. –Chișinău: Editura ”Tehnica-
UTM”, 2014.
2. ITU-T Recommendation H.323 (12/2009) - Packet-
based multimedia communications systems
(http://www.itu.int), 2009.
3. ITU-T Recommendation H.225.0 (12/2009) - Call
signalling protocols and media stream packetization for
packet-based multimedia communication systems
(http://www.itu.int), 2009.
4. ITU-T Recommendation Q.931 (05/1998) - ISDN
user-network interface layer 3 specification for basic call
control (http://www.itu.int), 1998.
5. ITU-T Recommendation H.245 (05/2011) - Control
protocol for multimedia communication (http://www.itu.int),
2011.
6. ITU-T Recommendation H.248.1 (03/2013) -
Gateway control protocol: Version 3 (http://www.itu.int),
2013.
50
CUPRINS
Introducere...........................................................................3
1 Protocolul H.323..............................................................3
1.1 Sumar.......................................................................3
1.2 Terminalul H.323......................................................5
1.3 Gatway-ul H.323.......................................................7
1.4 Gatekeeper H.323....................................................9
1.5 Unitatea de control multipunct MCU.......................11
1.6 Stiva de protocoale.................................................12
1.6.1 Protocolul RAS...............................................13
1.6.2 Protocolul de semnalizare de apel H.225.0....14
1.6.3 Protocolul de control a canalelor logice
H.245..............................................................22
1.7 Exemplu setare apel cu implicarea GK................26
2 Protocolul H.248/MEGACO........................................30
2.1 Sumar...................................................................30
2.2 Modelul de conexiune h.248.................................31
2.2.1 Terminația..................................................33
2.2.2 Contextul....................................................34
2.3 Comenzile H.248..................................................35
2.4 Descriptorii H.248.................................................36
2.5 Tranzacții H.248...................................................41
2.6 Exemplu de setare a unui apel H.248..................43
Bibliografie.........................................................................47
51
CBLM
MPLS
E. Borcoci, UPB
2006
CBLM- MPLS-ADSL-2006-E.BORCOCI-UPB 2
2 COMUTAŢIA DE ETICHETE MULTIPROTOCOL (MPLS) 2
2.1 CONCEPTE DE BAZA PENTRU “MULTI-PROTOCOL LABEL SWITCHING” - MPLS 2
2.2 AVANTAJE ALE TEHNOLOGIEI MPLS 3
2.3 DEFINIŢII ŞI TERMINOLOGIE MPLS 4
2.4 ETAPELE DE FUNCŢIONARE ÎN RUTAREA IP ŞI ÎN MPLS 5
2.4.1 Rutarea convenţională (IP) 5
2.4.2 Rutarea bazată pe MPLS 6
2.4.2.1 Etapele de funcţionare ale MPLS 6
2.4.2.2 Comparaţie intre un ruter tradiţional şi un ruter MPLS 7
2.5 ELEMENTE DE BAZA ALE MPLS 8
2.5.1 Codificarea etichetelor 8
2.5.1.1 Formatul etichetei MPLS 8
2.5.1.2 Incapsularea MPLS 9
2.5.2 Detalierea fazelor de operare MPLS 12
2.5.2.1 Faza de control 12
2.5.2.2 Faza de dirijare (transfer al fluxurilor de pachete) 13
CBLM- MPLS-ADSL-2006-E.BORCOCI-UPB 1
1 COMUTAŢIA DE ETICHETE MULTIPROTOCOL (MPLS)
1.1 Concepte de baza pentru “Multi-Protocol Label Switching” - MPLS

- MPLS este o metoda de comutaţie rapidă de pachete la nivel trei
- folosită în reţele TCP/IP
- in principiu tehnologia MPLS poate însă conlucra cu orice protocol de nivel 3, de unde şi
numele de “multiprotocol”
- MPLS a fost dezvoltat pornind parţial de la ideile de baza din ATM ( eficienţa comutării de
etichete de tip ATM în comparaţie cu dirijarea tradiţională IP- bazată pe analiza antetului de
nivel trei al fiecarui pachet IP.
Rutarea IP tradiţională- funcţii principale:
- determinarea rutelor „routing”între diferite puncte ale reţelei (algoritm de căutare a
drumurilor de cost minim şi construirea tabelelor de dirijare -
- dirijarea ”forwarding” fiecărui pachet de intrare sosit la un port de intrare al unui ruter pe
una din interfeţele de ieşire (sau mai multe, prin multiplicare, în cazul unui protocol de nivel reţea
pentru comunicaţii de grup – „multicast”)
- pentru fiecare pachet în parte, printr-o operaţie de căutare
- comparând adresa de destinaţie (din antetul de nivel trei pachetului IP), cu
informaţiile conţinute în tabelul de dirijare pentru determinarea celei mai bune potriviri între
adresa de destinaţie şi înregistrările din tabel
- Rezultatul: identitatea portului de ieşire care va fi selectat
- IP „connectionless” ⇒ fiecare nou pachet este analizat în mod independent de cele
anterioare ( flexibilitate a IP – ex. modificarea rutelor în mod dinamic)
- dar căutarea - consumă timp şi putere de calcul pentru fiecare pachet în parte
MPLS :
- înlocuieşte dirijarea bazată pe căutare cu o comutaţie („swapping”) de etichete realizata
rapid (fără căutare)
- La intrarea într-un domeniu MPLS fluxurile de pachete sunt mai întâi clasificate în clase de
echivalenţă (d.p.d.v al dirijarii – „Forwarding Equivalence Classes” - FEC)
- Fiecărei FEC îi corespunde un identificator de lungime fixă numită etichetă MPLS
(„label”)
- Fiecare pachet aparţinând unei clase FECi este etichetat cu eticheta clasei respective, iar
eticheta se adaugă în faţa antetului IP
- Etichetele au valabilitate locală pe link-uri între nodurile comutatoare (alocarea etichetelor
pentru o anumită rută se va discuta ulterior)
- În fiecare nod MPLS (comutator) următor, dirijarea pachetului etichetat, se face apoi prin
comutaţie de etichete, pe baza unui tabel de comutaţie a etichetelor, conform relaţiei:
(port_intrare, etichetă_intrare) → (port_ieşire, etichetă_ieşire)
prin adresare indexată la tabelul de comutaţie
- La ieşirea din domeniul MPLS şi reintrarea într-un domeniu cu dirijare traditională IP,
etichetele sunt eliminate de către ruterul de ieşire, care dirijează în continuare pachetul prin
”forwarding” tradiţional.
Pentru:
- compatibilitate cu arhitecturile existente si
CBLM-MPLS-ADSL-2006- E.Borcoci-UPB 2
- considerente economice
- MPLS a fost definit ca un nou sub-nivel arhitectural intermediar între nivelul 2-3; se
păstrează implementările existente pentru nivelele DL şi N.
- Pentru a aloca etichete segmentelor (link-urilor) este nevoie de informaţii de rutare. În acest
sens, o caracteristică importantă a MPLS este că admite informaţii furnizate de orice tip de
protocol de rutare, de de unde şi numnele de „multiprotocol”.
Domeniu MPLS = o zona dintr-o reţea, inclusă de regulă într-un singur domeniu adiministrativ IP, în
care exista rutere comutatoare de etichete MPLS şi între care s-au distribuit într-un mod oarecare
etichete MPLS.
Figura 5-1 : (simplitate) un singur domeniu MPLS, inclus intr-un altul IP (în ultimul este valabil un
protocol de rutare IP şi dirijarea pachetelor se face în mod tradiţional)
Fiecărei FEC ⇔ cale cu comutaţie de etichete (LSP - „Label Switched Path”).
Pachetele unui flux care aparţin unui FEC vor fi dirijate pe calea asociată
În fiecare nod comutator : comutaţia de etichete (e1→ e2, e2→ e3)
Dirijare MPLS
Dirijare normala e2
(IP) Dirijare normala
e1 LSR LSR e3 (IP)
ER ER
Cale MPLS
(LSP)
LSR
Domeniu
MPLS
ER
Domeniu
IP
Figura 1-1 Dirijarea pachetelor în interiorul unui domeniu MPLS
ER – (“Edge Router”) -ruter de frontieră al domeniului MPLS

LSR – (“Label Switch Router”) - comutator de etichete/ruter intern domeniului MPLS
LSP - „Label Switched Path”)- cale cu comutaţie de etichete MPLS
1.2 Avantaje ale tehnologiei MPLS

MPLS : avantaje importante în special pentru reţele centrale (“core”) avansate:
• mai rapidă decât căutarea în tabele la nivel IP (“table look-up”), LSR sunt mai simple şi mai
rapide decât ruterele tradiţionale (se pot folosi eventual chiar comutatoarele hardware ATM).
• compatibilă cu orice nivel L2 sau L3 de ex. ATM şi respective. In ATM valoarea etichetei se
poate include în VPI/VCI. Comutatoarele ATM intermediare vor lucra la fel ca în comutaţia
ATM propriu-zisa.
• oferă flexibilitate prin aceea ca :
o lucrează la fel ca în rutarea de nivel 3, având în plus simplitatea dirijării asemănătoare
cu comutaţia de nivel 2. MPLS permite realizarea de ierarhii de rutare (mai multe
nivele de etichete) şi tehnici “tunel”.
o Poate colabora cu ruterele traditionale ( domeniile MPLS pot coopera cu domenii de
rutare tradiţionale ⇒ permite introducerea treptată a tehnologiei MPLS).
• facilitează creşterea performanţelor reţelei: suport necesar pentru inginerie de trafic (“Traffic
Engineering”- TE). În MPLS este posibil a defini explicit rutele dorite (similar cu rutarea de tip
sursa) - rezultate de exemplu din considerente de TE, (ignorând sau folosind numai parţial
informaţiile primite de la protocolul de rutare propriu-zis- RIP, OSPF, etc.).
• asigură suport suplimentar pentru controlul (QoS) MPLS fiind complementară cu tehnologii
QoS specifice din Internet (IntServ, Diffserv).
• permite realizarea de reţele virtuale private (VPN).
• se poate generaliza şi aplica şi în reţele optice (GMPLS)
• permite flexibilitate în clasificarea pachetelor (la intrarea în domeniul MPLS) în clase de
echivalentă – definite din punct de vedere al dirijarii (FEC). În MPLS se pot folosi în principiu
orice informaţii – de nivel L3 sau superior- pentru clasificarea pachetelor (prin contrast, la rutarea
tradiţională IP singura informaţie utilizabilă este cea din antetul de nivel 3).
• etichetarea este flexibilă. În particular ea poate fi dependentă de ruterul de intrare. Un acelaşi
pachet poate fi etichetat diferit (şi tratat în continuare în mod diferit) dacă soseşte pe unul sau
altul dintre două rutere de intrare din domenii diferite (acţiune imposibilă în rutarea IP)
• permite o mai bună definire a arhitecturii în sensul că separă planul de date (dirijare) în raport cu
planul de control, oferind flexibilitate prin utilizarea de diferite plane de control.
Care este preţul plătit pentru aceste avantaje?
În general : MPLS revine la modul de lucru Connection Oriented ⇒ moşteneşte în mod inerent şi
complexitatea acestuia precum şi un dinamism mai mic în comparatie cu IP:
• - funcţii şi protocoale suplimentare în planul arhitectural de control care să conlucreze cu cele de
rutare pentru distribuţia etichetelor între nodurile LSR.
• Căile MPLS trebuie construite în avans în raport cu transferul pachetelor de date
• Deteriorarea unei căi MPLS conduce la intreruperea transferului de date ceea ce face necesară
definirea de căi LSP principale şi de rezervă.
• Rutarea este mai puţin dinamică decât în IP.
1.3 Definiţii şi terminologie MPLS

• Domeniu MPLS („MPLS domain”) –- porţiune dintr-o reţea în care dirijarea pachetelor se face
prin MPLS şi care este inclus într-un singur sistem administrativ (AS) sau de rutare
• Flux de date („flow”) -– o instanţiere unică a secvenţei de pachete de date dintre două aplicaţii;
uzual, un flux se poate caracteriza la nivelul patru prin multipletul { ( adresa_port, adresa IP)src ,
( adresa_port, adresa IP)dst, protocol de transport }
• Clasa de echivalenţă din punct de vedere al dirijării (FEC – “Forwarding Equivalence
Class”) - un grup de pachete IP care sunt dirijate de-a lungul aceleiaşi rute (suferă aceeaşi tratare
din punct de vedere al dirijării)
• Etichetă MPLS (“MPLS Label”)
o identificator cu lungime fixă (32 biţi) amplasat înaintea antetului IP
o cu semnificaţie locală pe un link între două comutatoare MPLS
o care codifică un FEC
• Comutaţie de etichete (“label swap”) - operaţie de bază în MPLS, reprezentând modificarea
etichetei la traversarea unui comutator MPLS
• Nod (generic) MPLS („MPLS node”) – un nod ce rulează MPLS, adică :
o cunoaşte protocoalele de control MPLS pentru distribuţia etichetelor
o rulează unul sau mai multe tipuri de protocoale de rutare
o capabil să dirijeze pachete pe bază de etichetă MPLS (dar poate opţional dirija şi
pachete clasice IP)
• Nod MPLS de frontieră (“MPLS edge node”)- leagă un domeniu MPLS cu un domeniu non-
MPLS sau cu un alt domeniu MPLS. Pot fi de două tipuri : de intrare („ingress”) şi de ieşire
(„egress”)
• Ruter comutator de etichete (LSR - “Label Switched Router”) – nod MPLS de nivel 3 capabil să
comute etichete dar şi să dirijeze pachete folosind un mecanism tradiţional de nivel L3
• Cale cu comutaţie de etichete (LSP – “Label Switched Path”) – canal virtual ce traversează mai
multe LSR, pe un anumit nivel în ierarhia de etichete MPLS; pachetele ce aparţin unui FECi
urmeaza prin reţea aceeaşi LSP
• Stivă de etichete (“label stack”) – structura de date de tip stivă (LIFO – „Last Input First
Output”) folosită pentru atunci când se lucrează cu mai multe nivele de etichete în dirijarea
MPLS ierarhizată (domenii MPLS incluse unele în altele)
• Circuit virtual etichetat (LVC – “Labeled Virtual Circuit”) – conexiune virtuală “hop-by-hop”
stabilită la nivel ATM (daca MPLS lucreaza „peste” ATM), pentru a se realiza un LSP. Spre
deosebire de ATM traditional, conexiunea LVC nu este de tipul “capăt-la-capăt”)
• Protocol de distribuţie a etichetelor (LDP – “Label Distribution Protocol”) – protocol de
comunicare şi distribuţie a etichetelor şi a semnificaţiilor acestora între LSR (lucrează în
colaborare cu protocoalele de rutare: RIP, OSPF, BGP, IS-IS, EIGRP).
1.4 Etapele de funcţionare în rutarea IP şi în MPLS
1.4.1 Rutarea convenţională (IP)

În această secţiune se vor detalia etapele de lucru prezentate sumar în Secţiunea 5.1.
Determinarea/calcularea rutelor:
- realizată de către planul de control prin care se calculează (dinamic) rutele folosind un
protocol de schimb de mesaje între rutere (RIP, OSPF, BGP) folosind un algoritm de
determinare a drumurilor cu cost minim (algoritm de rutare)
- Cu ajutorul informaţiilor obtinute se construiesc tabele de dirijare în fiecare ruter.
Dirijarea pachetelor:
- realizată de către planul de date
- Fiecare ruter (“hop”) ia în mod independent de celelate, o decizie de îndrumare către un
“next hop”, bazându-se pe adresa destinaţie a pachetului
- Alegerea next-hop include 2 faze:
- gruparea pachetelor în clase de echivalenţă (FEC) şi realizarea corespondenţei
(„mapping”) : FEC/next-hop. - Din punct de vedere al dirijării, pachetele ce aparţin
aceluiaşi FEC sunt tratate identic, fiind dirijate pe aceeaşi rută spre ieşire. Doua pachete sunt
considerate că aparţin aceleiaşi FEC dacă tabelul de dirijare conţine un anumit prefix X, unde
X este - pentru ambele pachete - porţiunea de adresă “cea mai lungă” de potrivire cu adresa de
destinaţie a pachetului. Fiecare pachet în parte trebuie analizat pentru a i se atribui o clasă
FEC.
- dirijarea propriu-zisa
1.4.2 Rutarea bazată pe MPLS
Presupunem ca s-au alocat etichete între nodurile MPLS (protocol LDP- bazat pe informaţiile obţinute
de la RIP, BGP, etc.:
- alocarea unui pachet la o clasa FEC se face numai odată : la intrarea în domeniul MPLS
. Standardul MPLS nu impune restricţii privind clasificarea. Se pot folosi în principiu orice
informaţii, din antetul propriu-zis IP dar chiar şi unele provenind de la nivelele superioare (flexibilitate
a clasificarii MPLS).
- fiecare FEC la care există pachete asignate primeşte un antet cu 32 de biţi (eticheta propriu-zisa este
cu 20 biti – si codifica un FEC)
- pachetul este dirijat către next hop (NH) numai pe baza etichetei, indiferent de informaţia cu
ajutorul căreia s-a decis apartenenţa la un anumit FEC.
- decuplare a clasificării faţă de comutaţie ⇒ flexibilitate in clasificari + simplitate pentru operaţia
de dirijare şi comutaţie de etichete)
- un ruter intermediar : comutaţie de etichete – fara analiza de tip L3
1.4.2.1 Etapele de funcţionare ale MPLS

În această secţiune vom relua etapele principale de funcţionare ale MPLS.
1. Faza de Control
1.a Protocoalele de rutare interioare (RIP, OSPF, IS-IS, etc.) calculează rutele pentru toate
destinaţiile accesibile. (ex.: OSPF, fiecare nod (ruter) determină graful reţelei prin mesaje “link
state” de la vecini calculează drumurile cele mai scurte de la el către diferite destinaţii/reţele aplicând
un criteriu de cost minim) se completează tabelul de dirijare.
1.b Spaţiul total de dirijare se împarte în FEC-uri. (Pachetele care vor urma acelaşi drum vor
aparţine aceleiaşi FEC
-se face “legarea etichetelor” – “label binding”, prin care se atribuie câte o etichetă pentru
fiecare FEC. Label scope = un link între două rutere MPLS.
1.c LDP– distribuie etichetele între noduri, contribuind la alocarea în fiecare nod a unei etichete
pentru o anumită clasă FEC (“map labels to each FEC în every hop”). Astfel se stabilesc căile LSP
(unidirecţionale) prin domeniul MPLS.
2. Dirijarea pachetelor
Fie pachet IP sosit pe un port de intrare într-un ruter de frontiera MPLS.
2.a Se examinează ruta la nivel L3
- clasificarea pachetului pe baza potrivirii prefixului celui mai lung al destinaţiei şi pe baza
potrivirii exacte a altor câmpuri şi se gaseste FEC (*)
- se alocă o etichetă corespunzatoare clasei FEC alese
- se eticheteaza pachetul IP cu antet MPLS
- pachetul este dirijat pe baza acesteia prin comutaţie de etichete în fiecare nod.
(*) Observaţie :
- se examinează de regulă antetul de nivel L3
- pot fi considerare şi alte informaţii auxiliare ( ex. de QoS, TE etc.) Corespunzător acestor
informaţii ruterul de frontieră E-LSR poate decide alocarea clasei FEC şi a etichetei corespunzătoare
ce va fi aplicată antetului.
2.b Fiecare LSR comută etichetele (“label swapping”) folosind eticheta de intrare ca index în tabelul
de dirijare (analog - ATM). Pachetul este dirijat pe portul de ieşire spre nodul următor. Comutaţia
realizată este : (Port-în, L-in) -> (Port-out, L-out).
2.c Nodul de ieşire din domeniul MPLS elimină eticheta şi dirijează pachetul mai departe, în stil IP
(eventual spre un alt domeniu) pe baza analizei de antet L3.
- opţional PHP („Penultimate Hop Popping”): penultimul ruter din domeniul MPLS, după
determinarea portului de ieşire către ultimul nod MPLS, elimină deja eticheta deoarece ruterul de
ieşire, oricum nu o va mai folosi.
comuta etichete Tabel de

(se poate realiza PHB) comutare etichete
Tabel de
LSR LSR dirijare
ER Domeniu ER
MPLS
- receptioneaza pachet LSR
- analiza antet la nivel L3 -elimina eticheta
- eticheteaza pachet - analiza L3
- dirijeaza catre urmatorul hop dirijeaza pachet
ER
Calea LSP cu comutare de etichete

(identificata in ER)
Figura 1-2 Dirijarea pachetelor în domeniul MPLS, pe baza etichetelor
PHB –Per Hop Behaviour – comportament special al unui nod (hop) pentru asigurarea unor
caracteristici de calitate a serviciilor (Quality of Services – QoS)
1.4.2.2 Comparaţie intre un ruter tradiţional şi un ruter MPLS
Plan control C
“Routing Updates” Actualizare rute
Protocoale rutare actualiz. rute Protocol rutare IP
IP
Tabela rutare IP
Tabele rutare
IP Actualizare ptr Control de rutare
legarea etichetelor IP MPLS
Rutare IP
LIB
Label
info
Tabele de dirijare Base
(forwarding) Plan de date (U)
Forwarding Info Base
Procesare pachete (FIB)
Label Forwarding Info

Buffer Base (LFIB)
LC LC LC LC Tabela de dirijare
MPLS
Pachete Pachete
in out
Buffer
LC=line Card LC LC
LC LC
{
Pachete
Figura 1-3 a. Ruter traditional IP b. Ruter de frontiera - MPLS

LFIB – baza de date cu informatii:
- etichete de intrare
- etichete de iesire
- FEC asociate
1.5 Elemente de baza ale MPLS
1.5.1 Codificarea etichetelor
1.5.1.1 Formatul etichetei MPLS
IP-H TCP-H Date aplicatie Datgrama IP
MPLS-H IP-H TCP-H Date aplicatie Datgrama IP

etichetata
LABEL EXP S TTL Antet MPLS

20 Biti 3 1 8
32 biti
Figura 1-4 Codificarea antetului MPLS
TCP-H antet TCP

IP-H – antet IP
LABEL – eticheta MPLS propriu-zisa. Aceasta are semnificaţie locală pe un link între două LSR.
EXP - câmp experimental - uzual indica o clasa de serviciu ( ex. In DiffServ/MPLS - codifica
prioritaţi diferite ale pachetelor).
S - arată (dacă ia valoarea 1) că eticheta î este la sfârsitul unei stive LIFO de etichete (folosită pentru a
realiza o ierarahie de domenii MPLS incluse unele în altele).
TTL – “Time To Live” –-vezi IP (timpul de viaţă rămas al pachetului în reţea).
Utilizarea etichetelor în cazuri practice: etichetele se pot aplica (include) în adrese de nivel 2:
- în indicatorii VPI, VCI în cazul ATM
- în indicatorul DLCI ( “Data Link Connection Identifier”) în cazul “Frame Relay”.
Etichete cu valoare rezervată - RFC 3032, [ ].

0 - IPv4 Explicit Null : are sens doar dacă S=1, şi semnifică faptul că trebuie eliminat antetul MPLS
urmând ca rutarea mai departe să se facă pe principii IP.
1 - Router Alert : nu are sens dacă S=0, indicaţie pentru ruter: pop pentru eticheta curentă şi dirijare
după eticheta următoare din stivă.
2 - IPv6 Explicit Null : are aceeaşi semnificaţie ca pentru IPv4.
3 - folosită de LDP pentru cereri PHP.
4…15 sunt valori rezervate.
Un domeniu MPLS, poate inclus în alt domeniu MPLS.

- se va utiliza stiva de etichete
- permite o rutare ierarhizată (dirijarea pachetului într-un domeniu se face cf.etichetei din
vârful stivei).
Antet L2 Antet L3 Date Terminator

L2
Etichete MPLS
“Shim header”
Figura 1-5 Pachet cu stiva de etichete
1.5.1.2 Incapsularea MPLS

Incapsularea generică MPLS rezultă din amplasarea MPLS în stiva de protocoale: Antet L2, Antet
MPLS (“shim header”), Antet L3, etc., conform Figurii 5-5.
Antet L2 Antet MPLS Antet L3 Antete de Date Terminator

“Shim header” nivel L2
superior
Figura 1-6 Incapsularea generică MPLS
În Figura 5-6 : încapsulare generică MPLS pentru diverse cazuri L2: PPP, PPP peste SONET/SDH,
Ethernet, Frame Relay PVC, MPLS peste ATM PVC.
Terminoolgie: - încapsulare bazată pe cadre (“frame based”). Antetul L2 conţine informaţiile sale
uzuale. Eticheta MPLS nu este folosită la nivelul L2.
Tipuri de L2
Antet L2 Antet Antet L3 Date PPP , PPP over SONET/SDH Ethernet
MPLS Frame Relay PVC
Antet Antet Antet L3 Date MPLS over ATM- PVC

ATM MPLS Prima celula ATM
Antet Date Urmatoarele celule ATM
ATM
Figura 1-7 Exemple de încapsulare generică MPLS pentru diverse nivele L2
• Incapsularea MPLS/PPP
“Point-to-Point Protocol” (PPP)
- folosit pentru comunicaţii 1-la-1 (ex. pe legături seriale).
- În modelul OSI, PPP –este definit la nivelul L2.
- Are trei componente principale cu ajutorul cărora stabileşte o conexiune şi apoi trimite
pachete pe conexiunea creată.
- oferă o metodă de încapsulare pentru a se putea lucra cu diferite protocoale de nivel 3.
PPP conţine un sub-nivel inferior pentru stabilirea, configurarea şi testarea unei conexiuni
de nivel 2 („Link Control Protocol” - LCP) şi un subnivel superior – cu funcţii de
adaptare („Convergence sublayer”) denumit „Network Control Protocol NCP”, care
permite conlucrarea cu diferite protocoale de nivel 3. NCP include printre altele şi funcţii
relative la securitatea informaţiei.
- Incapsularea PPP este ~ HDLC, cu unele excepţii. Un câmp special numit „protocol”
indică tipul conţinutului informaţiei sau - echivalent - ce protocol superior se foloseste
peste legătura de date propriu-zisă: LCP(0x co21), NCP(0x 8021), IP(0x 0021), control -
MPLS-CP (0x8281 ), etc.
- În MPLS/PPP
- Se transmit pachete LCP pentru testarea şi configurarea legăturii
- Se transmit apoi pachete de tip MPLS Control Protocol (MPLS CP) – identificate
pentru a configura transmisia de pachete etichetate MPLS
- După ce în urma schimbului de mesaje MPLS CP legătura de date a ajuns în starea
“Open” se pot transmite pachete etichetate. MPLS CP foloseşte acelaşi mecanism de
schimbare de mesaje ca şi LCP cu următoarele excepţii:
După ce PPP a ajuns în faza de Network Control şi MPLS CP a atins starea “Open”, se pot transmite
pachete pe legătura de date, identificabile prin câmpul Protocol (0x0281 pentru MPLS 1-la-1 –
„unicast” şi respectiv 0x0283 pentru MPLS – comunicaţii de grup – „multicast”.
• Incapsularea MPLS/Ethernet
- un cadru Ethernet va încapsula un singur pachet etichetat: antetul MPLS urmeaza celui de nivel
2, inclusiv în cazul existenţei unor forme modificate ale acestuia din urma (de exemplu pentru IEEE
802.1q -VLAN). Pentru identificare se foloseşte câmpul Type din cadrul Ethernet (octeţii 13 şi 14) cu
valoarea 0x8847 pentru MPLS unicast şi 0x8848 pentru multicast. Cu aceste valori se face
identificarea unui pachet etichetat şi dacă se foloseşte încapsularea L2 de tip 802.3 LLC/SNAP, [ ].
• Incapsularea MPLS/ATM
a. Incapsularea generică
- presupune (Figura 5.7) utilizarea de ATM-PVC
- datagrama de nivel trei se segmentează în celule
- numai prima celulă contine eticheta MPLS, celelalte conţinând doar restul datagramei
- Transport tradiţional-ATM, (bazat pe VPI, VCI) - independent de eticheta MPLS, care nu
are vreun rol nici în selectarea circuitului virtual ATM şi nici în comutatia ATM
- Pentru a se putea efectua operaţii specifice MPLS intr-un ruter LSR, este necesară
reasamblarea datagramei din celule.
b. Incapsularea etichetei MPLS în VPI, VCI
- Metoda anterioara- redundantă
- Alternativa: VPI şi VCI transporta eticheta MPLS. Comutatoarele ATM care lucrează în
acest mod sunt denumite ATM-LSR.
- Terminologie: metoda de încapsulare ATM-MPLS. Comutatoarele LSR dispun de interfete
de celule de tip ATM. Aceste interfete sunt numite în RFC 3031, [ ], LC-ATM ( “Label Switched
Controlled” - ATM). Eticheta MPLS se include în eticheta ATM înlocuind semnificaţia tradiţionala a
acesteia, (figura 5-8). Soluţia permite folosirea interfeţelor şi comutatoarelor ATM în tehnologia
MPLS.
Particularităţi:
- eticheta din vârful stivei se include în VPI, VCI
- între ATM-LSR nu se mai face reasamblarea celulelor ATM
- comutaţia MPLS se efectuează acum ca o comutaţie ATM, pe baza VPI, VCI
- din punct de vedere arhitectural, planul U (“User”) este planul ATM clasic dar în planul
de control C se înlocuiesc protocoalele de semnalizare ATM (UNI, PNNI) cu protocoale
proprii lui MPLS: OSPF, LDP
- în timpul transferului pachetelor nu se foloseşte decrementarea valorii lui TTL, (deosebire
faţă de transportul IP al pachetelor)
- valorile rezervate de VCI ( vezi Capitolul ATM....) cuprinse între 0..31 nu se vor folosi ca
etichete MPLS
- în funcţie de modul de interconectare al comutatoarelor ATM- LSR (SVC, SVP) există
mai multe variante de încapsulare – subiect ce se va relua ulterior.
Antet ATM
GFC VPI VCI PTI CLP HEC Antet Date Prima celula
L3
Eticheta
MPLS
GFC VPI VCI PTI CLP HEC Antet Date Urmatoarele

L3 celule
Eticheta
MPLS
Figura 1-8 Includerea etichetei MPLS în VCI, VPI în cazul comutatoarelor ATM-LSR
1.5.2 Detalierea fazelor de operare MPLS
1.5.2.1 Faza de control

Reamintim etapele fazei de control:
1.a Calcularea rutelor de către protocoalele de rutare şi construcţia tabelelor de dirijare
1.b Divizarea spatiului total de dirijare în clase FEC şi atribuirea de etichete acestor clase (“label
binding”)
1.c LDP – distribuie etichetele între noduri, contribuind la alocarea în fiecare nod a unei etichete
pentru o anumită clasă FEC şi se stabilesc căile LSP.
Căile LSP sunt construite într-o manieră controlată explicit, cu urmatoarele variante:
- rutare explicită strictă (“strict explicit routing”) – caz în care toate nodurile prin care trece
LSP sunt precizate/fixate
- rutare explicită cu grade de libertate – caz în care numai un subset de noduri ale căii LSP
sunt fixate; celelalte pot fi în principiu oricare dintre cele diferite de subsetul de noduri
precizate explicit.
Figura 5-9: domeniu MPLS şi fazele de control.
Exemplu : stabilirea unei căi spre o maşină terminală având adresa (IPv.4) de destinaţie x.y.z.w,
conectată la o reţea locală având prefixul de adresă x.y.
Faţă de un nod LSRk, există (considerând sensul de transfer al datelor) noduri în aval (“downstream”)
şi noduri în amonte (“upstream”).
Standardul MPLS : etichetele sunt distribuite întotdeauna de către nodurile din aval faţă de un
nod dat.
Nodul amonte poate obţine de la cel din aval o etichetă, pentru o anumită clasă FEC, (pentru simplitate
pp. că această clasă FEC este asociată cu o anumită destinaţie din reţea), astfel:
- face o cerere de etichetă către nodul din aval (“solicited downstream mode”) –aflat pe
ruta către destinaţia dorită, sau
- primeşte o indicaţie de a folosi o anumită etichetă pentru o anumită FEC dar fără a solicita
el însusi aceasta (“unsolicited downstream mode”).
Figura 5-9 : exemplu pentru (“unsolicited downstream mode”)
Exemplu: LSR2 îi comunică (prin mesaj LDP) lui LSR1 să folosească eticheta L=9 pentru a putea
construi o cale LSP, catre destinaţia cu prefix de adresă x.y.
Semnificaţia mesajului: (“use label 9 for destination x.y”)
Dupa un lanţ de asfel de mesaje (in sens invers cu cel al datelor) se poate stabili o cale LSP catre
destinaţia x.y.
Propun eticheta
5 pentru dest.x.y
Propun eticheta 9
pentru dest. x.y Propun eticheta
LSR1
7 pentru dest. x.y
LSR2
Reţea
E-LSR x.y
LSR E-LSR
non Domeniu MPLS

MPLS LSR x.y.z.w
non
MPLS
E-LSR
Tabelă de dirijare în E-LSR Rute alese de IGP
Tabelă de comutaţie de etichete Alocare de etichete de tip
"downstream" nesolicitat
Label Switch Path
Figura 1-9 MPLS - faza de control
E-LSR – Edge Label Switched Router; IGP Interior Gateway Protocol
1.5.2.2 Faza de dirijare (transfer al fluxurilor de pachete)

Figura 5-10 :
-transferul unui flux de pachete etichetate pe o cale MPLS
către o reţea având adresa x.y (prefix de adresăă IPv.4)
S-a presupus că în urma fazei de control în fiecare LSR există tabelul de comutaţie care
conţine informaţiile de comutaţie de etichete.
Recepţionează pachetul
L3 "look up" Comutaţie de etichete
clasifică FEC (adresare indexată): IF0->IF2, 9-> 5
etichetează pachetul Reţea
dirijează către nodul următor XY
5
0 LSR
2 3 7
0 LSR
1 0 XYZ
9
1 2 3
3 E-LSR
LSR 1
E-LSR 2
0 2 LSR
Dirijare 1
E-LSR Domeniu MPLS
tradiţională
Tabela de comutare pentru I/F0 Penultimul LSR poate

etichetă prefix I/F etichetă elimina eticheta, căci ea nu
IN adresă OUT OUT va mai fi necesară în E-LSR
9 XY 2 5
Rută aleasă de IGP

Label Switch Path
Figura 1-10 Operare MPLS: dirijarea pachetelor
Lista de acronime
AAL ATM Adaptation Layer

ABR Available Bit Rate
AC Admission Control
ADSL Asymmetric Digital Subscriber Line
AN Access Network
ANG Access Network Gateway
AP Access Point
AR Access Router
AS Autonomous System
ATM Asynchronous Transfer Mode
BE Best Effort
BGP Border Gateway Protocol
BISDN Broadband Integrated Services Digital Network
BR Border Router
CBR Constraint-based Routing
CBR Constant Bit Rate
CBR Constant Bit Rate
CC Content Consumer
CDMA Code Division Multiple Access
CDV Cell Delay Variation
CER Cell Error Rate
CES Circuit Emulation Service
CL Connectionless
CLI Command Line Interface
CLP Cell Loss Priority
CLR Cell Loss Rate
CMR Cell Misinsertion Rate
CO Connection Oriented
CP Content Provider
CPAAL Common Part Convergence Sub-layer
CPCS Common Part Convergence Sublayer
CPE Customer Premises Equipment
CR Core Router
CS Convergence sublayer (adaptation)
DB Database
DI Digital Item
DiffServ Differentiated Services
DLCI Data Link Connection Identifier
DNS Domain Name Service
DS Differentiated Services (DiffServ), IETF Working Group
DSCP Differentiated Services Code Point
DSL Digital Subscriber Line
DSLAM Digital Subscriber Line Access Multiplexer
DVA Distance Vector Algorithm
DVB-S Digital Video Broadcast
DVB-T Digital Video Broadcast- Terrestrial
E2E End-to-End
EG Exterior(Border) Gateway
ER Edge Router
ES/H End System/Host
FDM Frequency Division Multiplexing
FDMA Frequency Division Multiple Access
FEC Forward Error Control
FEC Forwarding Equivalence Class
FIFO First-In First-Out (queue)
FR Frame Realay
GFC Generic Flow Control
GSM Global System for Mobile Communication
GW Gateway
HDSL High bit-rate Digital Subscriber Line
HEC Header Error Check
ICMP Internet Control Messages Protocol
IE Information Element
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IG Interior Gateway( Router)
IMA Inverse Multiplexing ATM
IMS Integrated Multimedia Subsystem
IntServ Integrated Services
IP Internet Protocol
IPC Inter Process Communication
IRTF Internet Research Task Force
IS Intermediate System
IS see IntServ
LAN Local Area Network
LANE LAN emulation
LB Leaky Bucket
LDP Label Distribution Protocol
LLC Logical Link Control
LSP Label Switched Path
LSR Label Switched Route
LVC Label Virtual Circuit
MAC Medium Access Control
MAN Metropolitan Area Network
MCTD Mean Cell Transfer Delay
MDT Mean down-time
MF Multi Field
MGW Media Gateway
MIB Management Information Base
MPEG Moving Picture Experts Group
MPLS Multiprotocol Label Switching
MPOA Multiprotocol over ATM
MSC Message Sequence Chart
NC Network Controller
NE Network Element
NGN Next Generation Network
NLRI Network Layer Reachability Information
NM Network Manager
NNI Network Network Interface
NP Network Provider
NPA Network Point of Attachment ( Physical Address)
NQoS Network QoS
nrt-VBR Non-real-time Variable Bit Rate
NSAP Network Service Access Point
NTP Network Time Protocol
OAM Operation and Maintenance
OFDM Orthogonal Frequency Division Multiplexing
OSI - RM Open System Interconnection - Reference Model
OSPF Open Shortest Path First
PCM Pulse Code Modulation
PDH Plesiochronous Digital Hierarchy
PDP Policy Decision Point
PDU Protocol Data Unit
PDV Packet Delay Variation
PHB Per Hop Behaviour
PHB Per Hop Behaviour
PHP Penultimate Hop Popping
PID Program Identifier
PIM Protocol Independent Multicast
PMD Physical Medium Dependent
PNNI Private Network-Network Interface
POTS Plain Old Telephone Service
PPP Point to Point Protocol
PQ Priority Queuing
PQoS Perceived QoS
PR Policy Repository
PRIO Priority
PSTN Public Switched Telephone Network
PT Payload Type
PTD Packet Transfer Delay
QC Quality of Service Class
QoS Quality of Services
RARP Reverse Address Resolution Protocol
RFC Request for Comments
RIP Routing Information Protocol
RM Resource Manager
RSVP Resource reservation protocol
rt -VBR Real-time Variable Bit Rate
RTCP Realtime Control Protocol
RTD Round Trip Delay
RTP Realtime Transport Protocol
RTT Round Trip Time
SAC Subscription Admission Control
SAP Service Access Point
SAR Segmentation/reassembling
SDH Synchronous Digital Hierarchy
SDR Service Discovery Repository
SDU Service Data Unit
SIP Session Initiation Protocol
SLA Service Level Agreement
SLS Service Level Specification
SM Service Manager
SMDS Switched Multimegabit Data Service
SMI Structure of Management Information
SMTP Simple Mail Transfer Protocol
SNDAP Subnetwork Dependent Network Access Protocol
SNDCP Subnetwork Dependent Convergence Protocol
SNICP Subnetwork Independent Convergence Protocol
SNMP Simple Network Management Protocol
SONET Synchronous Optical Network
SP Service Provider
SQL Structured Query Language
SS7 Signalling System No.7
SSCOP Service Specific Connection Oriented Protocol
SSCS Service Specific Convergence Sublayer
STP Signaling Transfer Point
SVC Signalling Virtual Channels
TBF Token Bucket Flow
TC Traffic Control
TCP Transmission Control Protocol
TDM Time Division Multiplexing
TDM Terminal Device Manager
TE Traffic Engineering
TE Traffic Engineering
TME Existing Subscriptions TM
TP Traffic Policing
TS Traffic Shaping
TSAP Transport Service Access Point
TSPEC Traffic Specification
TT Traffic Trunk
UBR Unspecified Bit Rate
UDP User Datagram Protocol
UNI User network Interface
UPC Usage Parameter Control
VBR Variable Bit Rate
VC Virtual Channel
VCC Virtual Channel Connection
VCI Virtual Channel Identifier
VoD Video on-demand
VoIP Voice over IP
VP Virtual Path
VPC Virtual Path Connection
VPI Virtual Path Identifier
VPN Virtual Private Network
WAN Wide Area Network
WDM Wavelength Division Multiplexing
SUBSISTEMUL MULTIMEDIA IP
CICLU DE PRELEGERI
Chişinău
2020
3
Facultatea Electronică şi Telecomunicaţii
Departamentul Telecomunicaţii și Sisteme electronice
SUBSISTEMUL MULTIMEDIA IP
CICLU DE PRELEGERI
Chişinău
2020
4
Prezenta lucrare se încadrează în tematica cursului
Sisteme și rețele de comunicații digitale (SRCD) și urmărește
tendințele actuale de dezvoltare a tehnologiilor de rețea. Se
presupune că cititorul este familiarizat cu protocolul SIP, care stă
la baza platformei IMS și cu protocolul H.248, necesar pentru
interacțiunea cu rețelele cu comutație de circuite existente. Ambele
protocoale au fost descrise de autor în lucrările editate anterior. Este
necesară și cunoașterea semnalizării SS7, în special a mesajelor
aplicație ISUP.
Ca parte a cursului Sisteme și rețele de comunicații digitale
lucrarea este destinată studenţilor UTM cu profilul Electronică şi
comunicaţii, specialităţile 0714.1 Tehnologii și sisteme de
telecomunicații, 0714.2 Rețele și software de telecomunicații,
0714.3 Comunicații radio și televiziune, 0710.1 Inginerie și
management în telecomunicații, cu forma de studii la zi şi cu
frecvenţă redusă.

Redactor: Eugenia Balan
2004, UTM, bd. Ştefan cel Mare şi Sfânt, 168
ISBN 978-9975-45-636-4 © U.T.M., 2020
5
INTRODUCERE
Ultimele două decenii au cunoscut o evoluție rapidă a

tehnologiilor de rețea, echipamentelor terminale și a serviciilor și
aplicațiilor multimedia.
Este în creștere penetrarea dispozitivelor mobile cea ce
accelerează convergența rețelelor de telecomunicații fixe și mobile.
Convergența înseamnă migrarea rețelelor separate de astăzi PSTN,
PLMN, core și IP către o rețea universală care acceptă orice
tehnologie de acces.
Sunt în creștere rețele de acces în bandă largă (xDSL, FTTx,
WLAN, cablu, etc.). Lansarea rețelelor de acces în bandă largă
reduce bariera de intrare pentru furnizorii de servicii VoIP,
permițându-le să ofere servicii de telefonie la un preț mai mic
clienților săi. Venitul mediu pentru traficul de voce pe utilizator este
în scădere, ca urmare, furnizorii de servicii implementează aplicații
de comunicare multimedia bazate pe IP alternative pentru a
compensa veniturile pierdute. În plus, a devenit o practică comună
a multor operatori asigurarea accesului de bandă largă la date
nelimitat în rețelele fixe și mobile la o taxă constantă.
Cu diversificarea rețelelor de acces, operatorii pot atrage
clienți existenți și noi cu un portofoliu de servicii de convergență
îmbunătățit folosind și o facturare unificată.
Dezvoltarea rețelelor de acces și integrarea lor cu
infrastructura de servicii are drept consecință atât economii OPEX,
cât și CAPEX. Iar accesul diversificat permite operatorilor să
introducă servicii quadruple-play end-to-end (voce, date, video/TV
și mobilitate) pentru clienții noi. Deci convergența înseamnă un nou
model de servicii personalizat care oferă multe avantaje tehnologice
operatorilor, vânzătorilor de produse și utilizatorilor finali.
La rândul sau evoluția tehnologică și dezvoltarea rețelelor a
popularizat Internetul în rândul utilizatorilor. Internetul a devenit
cea mai mare rețea de date publică bazată pe tehnologia All-IP.
6
Este în creștere cererea de comunicații multimedia și de
servicii Internet pe dispozitive mobile. Evoluția completă solicită o
migrare eficientă din punct de vedere al costurilor către o rețea All-
IP. Soluția este subsistemul multimedia IP (IMS) ca platformă
universală care permite accesul omniprezent la serviciile
multimedia de pe orice terminal, fie că este vorba de un telefon
mobil, telefon fix sau computer. Mai mult ca atât, accesul la IMS nu
depinde de tehnologie.
Conceptul subsistemului multimedia IP constă în integrarea
comunicațiilor vocale, mobile și fixe, cu tehnologiile Internet,
astfel aducând diversitatea și multitudinea serviciilor Internet
utilizatorilor rețelelor mobile și fixe. Furnizarea de servicii
integrate utilizatorilor este un motiv important în favoarea migrării
pe platforma IMS.
Subsistemul multimedia IP definește interfețele standard
care trebuie utilizate de dezvoltatorii de servicii. În acest fel,
operatorii pot profita de o puternică industrie creatoare de servicii
multi-furnizori, evitând dependența de un singur furnizor pentru a
obține servicii noi. Obiectivul IMS este nu numai să furnizeze noi
servicii, ci să furnizeze toate serviciile actuale și viitoare pe care le
oferă Internetul. O sesiune multimedia între doi utilizatori IMS,
între un utilizator IMS și un utilizator de pe Internet sau între doi
utilizatori de pe Internet este stabilită utilizând exact același
tehnologii și protocoale de Internet. Mai mult, interfețele pentru
dezvoltatorii de servicii de asemenea se bazează pe protocoale de
Internet. Acesta este motivul pentru care IMS îmbină cu adevărat
Internetul cu lumea celulară.
Însă rețelele celulare moderne oferă deja o gamă largă de
servicii, care includ unele dintre cele mai de succes servicii de
Internet. De fapt, orice utilizator celular poate accesa Internetul
utilizând o conexiune de date. Deci, pentru ce este nevoie de IMS?
Răspunsul este că în afară de integrarea diferitor servicii IMS-ul
asigură și parametrii de calitate QoS necesari pentru aceste servicii
precum și o facturare flexibilă a lor.
7
IMS nu impune niciun model de afaceri particular, dar
permite operatorilor să efectueze facturarea serviciilor în modul pe
care îl consideră mai adecvat. IMS-ul oferă informații despre
serviciul invocat de utilizator. Pe baza acestor informații,
operatorul decide dacă va utiliza o taxă fixă pentru acest serviciu, va
aplica o facturare tradițională bazată pe timp, orientată pe QoS sau
va efectua orice alt tip nou de taxare.
Subsistemul multimedia IP este o tehnologie care oferă o
arhitectură cu standarde deschise, independență de rețea și servicii
și un șir de avantaje printre care principalele sunt:
 Convergența rețelelor fixe, mobile, core și bazate IP.
 Dezvoltarea și introducerea rapidă de servicii și aplicații
multimedia noi.
 Asigurarea calității serviciilor (QoS).
 Aplicarea unei facturări precise și flexibile.
 Reducerea cheltuielilor operaționale.
Dar și multe alte avantaje pentru operatori, prestatori de
servicii și consumatori care vor fi evidențiate în cele ce urmează.
În prezenta lucrare sunt analizate conceptele de bază ale
subsistemului IP multimedia (capitolul 1) și explicate principalele
entități funcționale ale NGN IMS (capitolul 2). În capitolul 3
succint se examinează subsistemul de emulare a rețelei PSTN/ISDN
în IMS, numit PES. Pentru ilustrarea interacțiunii dintre elementele
funcționale ale IMS sunt aduse două exemple de proceduri, primul
exemplu, înregistrarea terminalului UE în IMS, iar al doilea,
stabilirea sesiunii de apel ai abonatului IMS cu abonatul rețelei
PSTN (capitolul 4).
Se presupune că cititorul este familiarizat cu protocolul
SIP, care stă la baza platformei IMS și cu protocolul H.248, necesar
pentru interacțiunea cu rețelele cu comutație de circuite existente.
Ambele protocoale au fost descrise de autor în lucrările editate
anterior [12,19]. Este necesară și cunoașterea semnalizării SS7, în
special a mesajelor aplicație ISUP.
8
1. CONCEPTELE DE BAZĂ ALE IMS
1.1. Definiția IMS
Subsistemul1 multimedia IP (IMS) este o arhitectură

standardizată a reţelei de generaţia următoare (NGN) care
furnizează servicii multimedia mobile şi fixe bazate pe protocolul
SIP. IMS este numit subsistem, deoarece există ca o parte a unei
rețele care are nevoie de alte componente, cum ar fi o rețeaua de
acces, ca să funcționeze ca un sistem de prestare a serviciilor
multimedia.
Subsistemul multimedia IP se conformă cu standardele RFC
ale Grupului operativ Internet IETF pentru asigurarea
independenței de tehnologia de acces și interoperabilității cu
terminalele prin fir ale Internetului. IMS utilizează controlul
semnalizărilor bazat pe protocolul SIP și acceptă înregistrarea
utilizatorului și a dispozitivului terminal independent de anumită
locație din rețea. Ca parte a înregistrării, IMS asigură autentificarea
și alte aranjamente de securitate.
Serviciile suportate de IMS pot include servicii de sesiune
multimedia și unele servicii fără sesiune, cum ar fi servicii de
prezență sau servicii de schimb de mesaje.
Deci aspectele fundamentale ale platformei IMS sunt:
 Transport bazat pe IP atât pentru servicii în timp real, cât și
pentru cele non-timp real.
 Introducerea unui model de control a sesiunilor multimedia
bazat pe protocolul SIP.
Organul principal, care este preocupat de dezvoltarea
standardelor IMS este Proiectul de parteneriat de generația a treia
3GPP (Third Generation Partnership Project). Acest parteneriat a
apărut ca un acord între organizaţiile internaţionale implicate în
elaborarea de standarde pentru rețelele de comunicații mobile 3G ca
dezvoltare a sistemului GSM. Mai târziu sarcina a fost extinsă și a
inclus elaborarea de standarde pentru servicii multimedia și voce
9
bazate pe IP în rețele de comunicații mobile cu evoluția către
rețelele de generația a patra (4G).
Astfel 3GPP a introdus subsistemul IMS ca un adaos la
rețelele bazate pe comutația de pachete - domeniu PS (figura 1.1) .
Gazdă
Altă rețea
IP/IMS
Domeniul PS
Unde: UTRAN este rețeaua de acces radio terestră UMTS,

SGSN este nodul de suport servicii GPRS, iar
GGSN este nodul de suport gateway GPRS.
Figura 1.1. Suplinirea domeniului PS cu platforma IMS
Subsistemul IMS cuprinde toate elementele retelei de baza

(Core Network) pentru furnizarea de servicii multimedia IP care
includ audio, video, text, chat, etc. sau o combinație a acestora livrat
peste domeniul PS [1]. De aici și denumirea mai nouă a
subsistemului IMS–multimedia IP rețea core IM CN (IP Multimedia
Core Network).
Inițial conceptual IMS a fost introdus de 3GPP în Release-ul
5, publicat în anul 2002, ca sistem standard de comunicare
multimedia (figura 1.2). După introducerea sa în Rel-5, 3GPP a
10
adăugat continuu funcții noi la IMS în Release-urile ulterioare. În
Release-ul 5 se menționează că IMS nu este o rețea sau un serviciu
în sine, ci o platformă care asigură noi servicii multimedia bazate pe
IP. IMS-ul este arhitectură standardizată independentă de acces,
care asigură interoperabilitatea cu serviciile tradiționale de telefonie
existente atât pentru utilizatorii fixi (de exemplu, PSTN, ISDN,
Internet) cât și pentru utilizatorii de telefonie mobilă (de exemplu,
GSM, CDMA, UMTS, LTE). Arhitectura IMS asigură calitatea
necesară a serviciilor, gestionarea sesiunilor, de exemplu,
înregistrarea, autorizarea, securitatea comunicațiilor, controlul
traficului, roaming-ul. În general, IMS formează nucleul rețelei IP.
R99 R4 R5 R6 R7 R8 R9 R10
2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011
HSPA
HSPA
HSPA
UMTS
LTE
LTE
Adv
UL
DL
EPC
Common
MMTel
IMS
IMS
Figura 1.2. Elaborările de bază 3GPP conform release-urilor
Release-ul 6 a introdus modificări de rutare și de

semnalizare, de exemplu, partajarea unei identități de utilizator
publică între mai multe dispozitive. În plus, au fost finalizate
interoperarea pentru voce dintre IMS și domeniul comutație de
circuite CS și accesul WLAN la IMS. S-au finalizat un șir
îmbunătățiri în ceea ce privește securitatea, politica și controlul
tarifelor și arhitectura generală.
Release-ul 7 introduce încă două tehnologii de acces
DOCSIS și xDSL și alte îmbunătățiri generale. Noile funcții
11
principale din Release 7 sunt: telefonie multimedia MMT, inclusiv
servicii suplimentare, SMS-uri prin orice acces IP, combinarea
apelurilor CS și a sesiunilor IMS, tranzitul IMS, sesiuni de urgență
IMS, identificarea serviciilor de comunicare în IMS și noul model
de autentificare pentru acces fix.
Telefonia multimedia MMT, după cum sugerează și numele,
este echivalentul telefoniei PSTN/ISDN/GSM în IMS bazată pe
rețelele de transport IP.
Release-ul 8 introduce o serie de caracteristici IMS noi, cum
ar fi serviciile centralizate IMS, continuitatea sesiunii multimedia,
(permite continuitatea fluxurilor multimedia atunci când este
schimbat accesul IP), integrarea IP-PBX în rețeaua IMS,
portabilitatea numărului și altele.
În următorii ani 3GPP a adăugat în Release-urile ulterioare
noi funcționalități la IMS.
Acum 3GPP este recunoscut de către diverse organisme
naționale de standardizare, inclusive Alianța pentru soluții pentru
industria telecomunicațiilor ATIS (Alliance for Telecommunications
Industry Solutions) și Institutul European de Standardizare în
Telecomunicații ETSI, în calitate de autoritatea de vârf la
elaborarea de specificatii IMS. Specificațiile tehnice (TS) 3GPP
definesc pe deplin subsistemul IMS. Ele pot include și trimiteri la
standarde de la alte organizații de standardizare. Aceste alte
standarde, apoi devin, în întregime sau în parte, parte integrantă a
specificației IMS.
1.2. Cerințele de nivel înalt pentru aplicațiile IMS
Viziunea IMS ca platformă comună pentru dezvoltarea și

furnizarea de servicii multimedia pentru un Internet mobil real se
bazează pe setul de cerințe prevăzute de 3GPP în TS 22.228 [1].
Acestă specificație definește cerințele de nivel înalt care trebuie să
fie sprijinite pentru aplicațiile multimedia IP prin intermediul IMS.
Aceste cerințe sunt:
12
 Indicatori de calitate QoS IMS negociabili atât la momentul
inițierii sesiuni, cât și în timpul desfășurării ei. Parametrii
negociați vor include tipul media, codic-urile și formatele de
codificare, lățimea de bandă, întârzierea, jitter-ul și rata
pachetelor pierdute.
 În cadrul fiecărei sesiuni posibil să se susțină mai multe
aplicații multimedia pentru a oferi eficient o experiență de
servicii IP coerentă și consistentă. Să se realizeze
identificarea aplicațiilor invocate de către abonat, alegerea
ordinii corespunzătoare a aplicațiilor și interacțiunea
aplicațiilor în timpul sesiunii. Furnizarea aplicațiilor
multimedia IP trebuie efectuată fără afectarea vieții private,
a securității sau a autentificării în comparație cu serviciile
similare în sistemele existente cu comutație de pachete și
cele cu comutație de circuite.
 Să se susțină principiul independenței de acces. De dorit ca
un operator să poată oferi servicii abonaților săi indiferent
de modul în care obține o conexiune IP (de exemplu, E-
UTRAN, UTRAN, GERAN, linii fixe, LAN, DOCSIS®,
WiMAX ™ și acces cdma2000®).
 Să fie acceptate aplicațiile Internet legate de sesiune,
dezvoltate în afara comunității 3GPP.
 Să fie limitată afișarea topologiei de rețea a operatorului.
 Să sprijine multiple terminale UE asociate cu un singur
abonament de servicii IMS. Să fie posibil ca câteva
terminale UE să aibă aceeași identitate de utilizator publică
sau identificarea unui UE cu diferite identități de utilizator
publice.
 Să asigure configurarea UE care include actualizarea
software-lui, configurarea serviciului și colectarea stării
operaționale.
 Trebuie să poată accesa informațiile despre locația
utilizatorului, indiferent dacă acesta este în roaming sau nu.
13
Conform politicilor operatorilor, aceste informații pot fi
furnizate aplicațiilor.
 Trebuie să suporte mecanisme de control a suprasarcinii
(overload) care să:
1) majoreze în mod automat debitul efectiv (adică cereri de
serviciu admise pe secundă) al resursei suprasolicitate;
2) mențină acest debit pe toată durata suprasarcinii,
indiferent de capacitatea resursei supraîncărcate sau a numărului de
surse cu suprasarcină;
3) fie configurabile de furnizor, astfel ca la procesarea
suprasarcinii timpul de răspuns al resurselor suprasolicitate să fie
mic ca clienții să nu abandoneze cererile de servicii.
Evident este necesar ca IMS să permită interconectarea cu
rețelele cu comutare de circuite, cum ar fi PSTN, ISDN, Internetul
sau rețelele celulare existente.
1.3. Identificarea utilizatorilor în IMS
Un utilizator de servicii multimedia IP poate fi asociat cu

diverse identități. Acest paragraf introduce diferiți identificatori care
sunt folosiți pentru:
 abonamentul utilizatorului (identitatea de utilizator privată);
 identificarea unui utilizator (identitatea de utilizator
publică);
 combinația identității de utilizator publică și a dispozitivului
utilizatorului (GRUU- Globally Routable User Agent URI);
 servicii (identitatea de serviciu publică);
 entitățile rețelei IMS.
În plus, este explicată relația dintre diferite identități ale
utilizatorului.
1.3.1. Identitatea de utilizator privată
14
Fiecare utilizator al subsistemului IM CN are una sau mai
multe identități de utilizator private care identifică abonamentul
utilizatorului. Identitatea privată este atribuită de operatorul rețelei
gazdă și este utilizată în scopuri de înregistrare, autorizare,
administrare și contabilitate.
Arhitectura IMS impune următoarele cerințe pentru
identitatea de utilizator privată [2,3]:
 Nu este utilizată pentru rutarea mesajelor SIP.
 Trebuie să fie inclusă în toate cererile de înregistrare
transmise de echipamentul utilizatorului (UE) rețelei gazdă.
 Va fi stocată în siguranță în ISIM, USIM sau în IMC (pentru
UE non-3GPP).
 Nu este posibil ca UE să modifice informațiile privind
identitatea de utilizator privată stocate în aplicația
ISIM/USIM sau IMC.
 Este identitate globală unică definită de operatorul de rețea
gazdă, care poate fi utilizată în cadrul rețelei de domiciliu
pentru a identifica abonamentul utilizatorului din
perspectiva rețelei.
 Identifică abonamentul, nu utilizatorul.
 Este alocată permanent abonamentului unui utilizator (nu
este o identitate dinamică) și este valabilă pe toată durata
abonării utilizatorului la rețeaua gazdă.
 Reieșind din politicile operatorului, poate fi prezentă în
înregistrările de taxare CDR.
 Este autentificată numai în timpul înregistrării utilizatorului.
Formatul identității de utilizator privată obținut din IMSI
(International Mobile Subscriber Identifier) este:
"<IMSI>@ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org".
De exemplu, dacă IMSI este 259010999999999 (MCC=259,
MNC =01), identitatea de utilizator privată ia forma
"259010999999999@ims.mnc001.mcc259.3gppnetwork.org".
Modulul ISIM (IM Subscriber Identity Module) al UE
este reconfigurat cu toți parametrii necesari pentru a iniția
15
înregistrarea în subsistemul IM CN. Acești parametri includ:
 identitatea de utilizator privată;
 una sau mai multe identități de utilizator publice; și
 numele de domeniu al rețelei gazdă utilizat pentru a adresa
cererea SIP REGISTER.
Prima identitate de utilizator publică din lista stocată în
ISIM este utilizată în cererile de înregistrare de urgență.
În funcție de operatorul rețelei, există diverse aranjamente în
UE pentru păstrarea acestor informații fie în ISIM, fie în USIM.
Dacă nici ISIM, nici USIM nu sunt prezenți, dar este prezent IMC,
parametrii se păstrează în cadrul IMC (IMS Credentials).
NOTĂ. IMC este un set de date de securitate și funcții
pentru acces IMS de către un terminal care nu acceptă nici o
tehnologie de acces 3GPP.
Atunci când nici ISIM, nici USIM, nici IMC nu sunt
prezente, identitatea de utilizator privată este disponibilă UE prin
alte mijloace. UE va genera o identitate de utilizator publică
temporară, o identitate de utilizator privată și un nume de domeniu
al rețelei de domiciliu pentru a adresa cererea SIP REGISTER,
conform 3GPP TS 23.003 [3].
Identitate de utilizator privată îndeplinește o funcție similară
în IMS, așa cum o face un IMSI în GSM. Identitatea de utilizator
privată nu trebuie să fie cunoscută de către utilizator și este stocată
pe un card inteligent în același mod în care IMSI este stocat într-un
SIM (Subscriber Identity Module). Abonatului i se atribuie o
identitate de utilizator privată de către operatorul de rețea gazdă.
Această identitate de utilizator privată este disponibilă pentru
aplicația SIP din UE.
Furnizorul serviciului IMS eliberează abonaților săi cartela
ISIM. Ea conține informații cu privire la nivelul de abonare al
utilizatorului, de autentificare, de securitate precum și identitatea de
utilizator privată IMS, păstrate de UICC (Universal Integrated
Circuit Card). UICC este un termen generic care definește
caracteristicile fizice ale cardului inteligent (cum ar fi numărul și
16
dispunerea pinilor, valorile tensiunii etc.). Interfața dintre UICC și
terminal este standardizată.
UICC poate conține mai multe aplicații logice, cum ar fi
modulul de identitate al abonatului SIM, modulul de identitate al
abonatului universal USIM și modulul de identitate multimedia IP
ISIM. În plus, UICC poate conține alte aplicații, cum ar fi agenda
telefonică. Figura 1.3 reprezintă un UICC care conține mai multe
aplicații.
UICC
SIM
USIM
ISIM
Figura 1.3. Modulele SIM, USIM și ISIM în UICC a

terminalelor IMS 3GPP
Fără un UICC prezent în terminal, utilizatorul poate efectua

doar apeluri de urgență. UICC permite utilizatorilor să-și mute cu
ușurință abonamentele (inclusiv agenda telefonică) de la un terminal
la altul. Utilizatorul scoate pur și simplu cartela inteligentă de pe un
terminal și o introduce într-un alt terminal.
1.3.2. Identitatea de utilizator publică
Conform TS 22.228 [2] fiecare utilizator al subsistemului

IM CN trebuie să aibă una sau mai multe identități de utilizator
publice. Identitatea de utilizator publică este folosită de orice abonat
pentru a solicita comunicări către alți utilizatori. Această identitate
se inscrie ca informație de contact pe cartela de vizită. Identitățile
de utilizator publice se alocă fiecărui abonat IMS de către
operatorul gazdă.
17
Arhitectura IMS impune următoarele cerințe pentru
identitatea de utilizator publică [2,3]:
 Identitatea utilizatorului publică va lua forma de URI SIP
sau de Tel URL.
 Cel puțin o identitate de utilizator publică va fi stocată în
siguranță în aplicația ISIM.
 Nu va fi posibil ca UE să modifice identitatea de utilizator
publică stocată în ISIM.
 identitate de utilizator publică va fi înregistrată înainte ca
identitatea să poată fi utilizată pentru a iniția sesiuni IMS.
 Va fi posibilă înregistrarea mai multor identități de utilizator
publice printr-o singură cerere de la UE.
 Rețeaua nu va autentifica identitățile de utilizator publice în
timpul înregistrării.
Forma canonică a unui SIP URI pentru o identitate de
utilizator publică trebuie să fie:
„sip:nume.utilizator@domeniu”.
De exemplu, sip:my.name@company.md.
Structura canonică a unui Tel URI pentru o identitate de
utilizator publică va lua forma "tel: + <CC> <NDC> <SN>"
(numărul maxim de cifre este 15), care reprezintă un număr E.164 și
va conține numărul internațional.
De exemplu, tel:+37362345678.
Identitățile de utilizator publice pot fi partajate de mai multe
UE. O anumită identitate de utilizator publică poate fi înregistrată
simultan la mai multe UE care utilizează diferite identități de
utilizator private și adrese de contact diferite.
1.3.3. Relația dintre identitățile de utilizator private și

publice
Operatorul de rețea gazdă este responsabil pentru atribuirea

identităților de utilizator private și a identităților de utilizatori
publice. Relația dintre un abonament IMS, identitatea de utilizator
18
privată și identitățile de utilizator publice este prezentată în figura
1.4. Unui abonament IMS i se atribuie o identitate de utilizator
privată, mai multe identități de utilizator publice și câteva profiluri
de servicii.
Profilul de servicii IMS este o colecție de servicii și date
referitoare la utilizator. Profilul de servicii IMS este definit și
menținut de serverul de abonat gazdă HSS (Home Subscriber
Server). Fiecare profil de serviciu este asociat cu una sau mai multe
identități de utilizator publice. Însă fiecare identitate de utilizator
publică este asociată doar cu un singur profil de serviciu.
Public
User Identity
Service
Profile
IMS Private Public

Subscription User Identity User Identity
Public Service
User Identity Profile
Figura 1.4. Relația dintre identitatea de utilizator privată și

identitățile de utilizator publice
Dacă unui abonament IMS îi este alocat nu una, dar câteva

identități de utilizator private atunci identitățile de utilizator publice
pot fi partajate. Prin urmare, o anumită identitate de utilizator
publică poate fi înregistrată simultan la mai multe UE care
utilizează diferite identități de utilizator private și adrese de contact
diferite.
În figura 1.5 este redată relația dintre identitatea comună de
utilizator publică cu identitățile de utilizator private și relația
rezultată cu profilurile de servicii și abonamentul IMS.
19
Datele de abonare arată ce identități de utilizator publice din
cadrul unui abonament sunt partajate și care nu.
Public User Service

Identity -1 Profile -1
Private User
Identity -1
IMS Public User

Subscription Identity -2
Service
Private User Profile -2
Identity -2
Public User
Identity -3
Figura 1.5. Relația identității de utilizator publică partajate

(Public-ID-2) și a identităților de utilizator private
1.3.4. Identificarea dispozitivului utilizatorului
În IMS identitatea de utilizator publică poate fi partajată

între un număr de dispozitive UE sub abonament unic. Aceasta
înseamnă că nu este posibil să se identifice un dispozitiv UE
specific atunci când mai multe dispozitive au fost înregistrate cu
aceeași identitate de utilizator publică. Pentru a ajunge la un anumit
dispozitiv UE trebuie utilizat un identificator specific numit GRUU
(Global Agent Routating User Agent URI). Un GRUU identifică o
combinație unică de identitate de utilizator publică și dispozitiv UE
(figura 1.6).
Există două tipuri de GRUU: GRUU publice (P GRUU) și
GRUU temporare (T GRUU). Publice sunt GRUU care includ
identitatea de utilizator publică și au o durată de viață lungă, atât cât
există perechea dispozitiv - identitate de utilizator publică. În
schimb, GRUU temporar este un identificator care are o durată de
viață limitată și este creat la fiecare cerere de înregistrare IMS.
20
Public User
Identity GRUU Set 1 UE
1
Instance ID1
GRUU Set 2
Public User
Identity
GRUU Set 3 UE
1
Instance ID2
Public User
GRUU Set 4
Identity
Figura 1.6. Relația dintre identitățile de utilizator

publice, GRUU și UE
Deci P GRUU și T GRUU sunt asociate cu identitățile de

utilizator publice. Ele sunt generate de IMS și repartizate către UE
împreună în timpul înregistrărilor sau reînregistrării în pereche, un P
GRUU și un T GRUU. Fiecare pereche P GRUU-T GRUU este
asociată cu o identitate de utilizator publică și un UE. În timpul
înregistrărilor ulterioare, UE îi va fi atribuit același P GRUU, dar va
fi generat și atribuit un nou T GRUU. După o reînregistrare, toate T
GRUU-urile anterioare generate în perioada înregistrării rămân
valabile.
Un Instance ID este un parametru de antet Contact din SIP
care identifică în mod unic agentul utilizator SIP UA în proces de
înregistrare. Când este disponibil un IMEI, Instance ID va lua forma
unei IMEI URN (a se vedea RFC 7254). Structura ID-ului va lua
forma "urn: gsma: imei: <imeival>" unde imeival va conține
valoarea IMEI-ului codificată. De exemplu,
urn:gsma:imei:90420156-025763-0
21
NOTĂ: La schimbarea cardului UICC ID-ul dispozitivului
UE nu se modifică.
Dacă IMEI nu este disponibil, Instance ID va lua forma unei
reprezentări șir a unui UUID (Universally Unique Identifier) ca
URN (RFC 4122). De exemplu,
urn: uuid: f81d4fae-7dec-11d0-a765-00a0c91e6bf6
1.3.5. Identitatea de serviciu publică
Odată cu introducerea funcțiilor standardizate de prezență,

mesagerie, conferințe și a serviciilor de grup în cadrul subsistemului
IM CN, apare necesitatea de identități de serviciu publice PSI
(Public Service Identities). Aceste identități sunt diferite de
identitățile de utilizator publice deoarece ele identifică servicii, care
sunt găzduite de serverele de aplicații AS. În special, PSI sunt
utilizate pentru identificarea grupurilor.
Identitatea de serviciu publică trebuie să fie sub forma de
SIP URI sau Tel URI. O identitate de serviciu publică determină un
serviciu sau o resursă specifică creată pentru un serviciu pe un
server de aplicație. Partea de domeniu este predefinită de către
operatorii de IMS, iar subsistemul IM CN oferă flexibilitatea de a
crea dinamic partea de utilizator a PSI. De exemplu, un serviciu de
tip chat poate folosi o identitate de serviciu publică (sip:
chatlist_X@example.com) la care utilizatorii stabilesc o sesiune
pentru a putea trimite și primi mesaje de la alți participanți la
sesiune.
Subsistemul IM CN asigură capacitatea utilizatorilor de a
crea, gestiona și utiliza identitățile de serviciu publice sub controlul
AS. Este posibilă crearea statică sau dinamică a identității de
serviciu publică.
IMS asigură capacitatea de a direcționa mesajele SIP
folosind identitatea de serviciu publică.
1.4. Arhitectura IMS stratificată
22
IMS are o arhitectură stratificată care separă
responsabilitățile între diferite funcții. În mod normal, sunt definite
trei planuri principale (figura 1.7):
1. Planul de transport media și de acces.
2. Planul control sesiune și semnalizare.
3. Planul aplicații și servicii.
Alteori sunt adăugate și alte straturi pentru a distinge, de
exemplu, orchestrarea serviciilor și stocarea datelor și management,
care sunt, de asemenea, independente de controlul sesiunii.
Planul de transport media și de acces funcționează ca punct
de intrare/ieșire pentru rețeaua core IMS și este format din routere și
comutatoare.
Planul control sesiune și semnalizare conține toate entitățile
IMS necesare pentru controlul sesiunilor multimedia IP. 3GPP a
ales protocolul de inițiere a sesiunii SIP pentru semnalizările între
terminal și entitățile IMS, precum și între componentele IMS.
Protocolul SIP este utilizat pentru stabilirea, modificarea și
eliberarea sesiunilor multimedia. În figura 1.7 sunt prezentate doar
principalele entități ale arhitecturii IMS. Nucleul arhitecturii IMS
este funcția de control a sesiunii de apel sau CSCF. Entitatea CSCF
gestionează sesiunile SIP și coordonează alte entități de rețea pentru
controlul sesiunii, serviciilor și alocarea resurselor. Ea este formată
din trei entități diferite: proxy-CSCF (P-CSCF), de interogare-CSCF
(I-CSCF) și de servire-CSCF (S-CSCF).
Planul aplicațiilor și serviciilor include serverele de aplicații
și media care prelucrează și stochează date și generează servicii
pentru abonați.
Arhitectura IMS este o colecție de funcții legate prin
interfețe standardizate. Aceasta înseamnă că 3GPP nu
standardizează careva noduri, ci entități funcționale.
Implementatorul este liber să combine două funcții într-un
singur nod sau să împartă o singură funcție în două sau mai multe
23
noduri. Majoritatea furnizorilor implementează mai multe funcții
într-un singur nod.
Figura 1.7. Arhitectura stratificată a IMS
24
Arhitectura completă pentru suportul aplicațiilor multimedia
IP compusă din terminale, rețele de acces IP CAN și elemente
funcționale specifice ale 3GPP IMS este descrisă în specificația
tehnică 3GPP 23.228 [2]. Ea descrie și interfețele către alte rețele
multimedia bazate pe IP și rețelele cu comutație de circuite CS
(Circuit Switched).
1.5. Arhitectura subsistemului NGN IMS
În cele ce urmează va fi descrisă platforma numită NGN

IMS elaborată de grupul TISPAN (Telecommunications and
Internet converged Services and Protocols for Advanced
Networking) din cadrul ETSI pentru extinderea conceptului IMS
asupra rețelelor fixe PSTN și ISDN.
NOTĂ. Comitetul tehnic TISPAN în 2012 a fost închis.
Menținerea standardelor NGN este acum responsabilitatea
comitetului tehnic NTECH (Network Technologies) din cadrul
ETSI.
Conform ETSI TS 123 517 [4] NGN IMS este subsistemul
media IP care suportă furnizarea de servicii multimedia bazate pe
SIP și servicii de simulare PSTN/ISDN către terminalele NGN.
Arhitectura generală TISPAN NGN ES 282 001 [5]
respectă modelul de referință ITU-T pentru rețelele de generație
următoare [6] și este structurată în două planuri: planul de serviciu
și planul de transport bazat pe IP (figura 1.8).
Deși entitățile funcționale NGN IMS sunt în esență identice
cu entitățile 3GPP IMS, ele pot prezenta unele variații minore în
comportament din cauza diferențelor din rețelele de acces și în
echipamentele utilizatorului. Cu toate acestea, arhitectura NGN
IMS definită în [4] rămâne compatibilă cu rețelele de acces IP-CAN
definite de 3GPP și poate furniza servicii echipamentelor
utilizatorilor conectate atât cu acces în bandă largă fixă (FBB), cât
și la 3GPP IP-CAN.
25
Applications
Other
User subsystems
PlanLayer
Service de serviciu profiles
Core IMS
Customer Premises Equipment
PSTN/ISDN
Ot her net works

Emulation
subsystem
Network Control transport

Attachment
Subsystem Resource and
Admission Control
Subsystem
Plan de
Transport transport
Layer
Transport processing
Transfer Functions functions
Figura 1.8. Arhitectura generală TISPAN NGN [5]
1.5.1. Planul de transport NGN IMS
Planul de transport cuprinde un sub-strat de control al

transportului deasupra funcțiilor de procesare a transportului în
rețelele de acces și core.
Sub-stratul de control al transportului este împărțit în
continuare în două subsisteme:
 Subsistemul de atașare la rețea (NASS);
 Subsistemul de control al resurselor și admisiei (RACS).
Funcțiile NASS sunt după cum urmează:
 Furnizarea dinamică de adrese IP și alți parametri de
configurare a terminalului.
26
 Aautentificarea la nivelul IP, anterior sau în timpul alocării
adreselor.
 Autorizarea accesului la rețea pe baza profilurilor de
utilizator.
 Accesarea rețelei pe baza profilurilor de utilizator.
 Gestionarea locației terminalului la nivelul IP.
Subsistemul RACS este responsabil de implementarea
elementelor de control al politicii, rezervarea resurselor și controlul
admiterii pentru traficul unicast sau multicast în rețelele de acces,
core și la sediul abonaților. De asemenea RACS acoperă aspecte
legate de stabilirea și modificarea politicilor de trafic, calitatea
serviciilor end to end și tarifarea la nivel de transport (pentru detalii
vezi ETSI ES 282 003 [7]).
Funcțiile de procesare a transportului în rețelele de acces
și core includ funcții elementare de bază care susțin redirecționarea
și rutarea pachetelor și un grup mai specific de funcții definite ca
entități funcționale. Acestea sunt:
 Funcția Media Gateway (MGF).
 Funcția Gateway de frontieră (BGF).
 Funcția de control al resurselor (RCEF).
 Funcție releu de acces (ARF).
 Funcția Gateway de semnalizare (SGF).
 Procesor de funcții de resurse multimedia (MRFP).
 Funcția de gestionare a accesului (AMF).
 Funcția de transport de bază (BTF).
Funcția Media Gateway (MGF) furnizează maparea și
transcodarea media între domeniul de transport IP și entitățile
rețelei cu comutare de circuite (trunchiuri, bucle). De asemenea,
poate efectua conferințe media și trimite tonuri și anunțuri.
Funcția Gatway de frontieră (BGF) oferă interfața dintre
două domenii de transport IP. Poate sta la frontiera dintre rețeaua de
acces și echipamentele clienților, între rețeaua de acces și rețeaua
core sau între două rețele core.
27
Funcția de control al resurselor (RCEF) este entitate de
procesare a transportului care suportă una sau mai multe dintre
următoarele funcții elementare:
 deschiderea și închiderea porților (adică filtrarea pachetelor
în funcție de „adresa IP/port”);
 marcarea pachetelor pentru traficul de ieșire;
 controlul traficului de intrare;
 alocarea resurselor pentru traficul în sus și în jos.
Funcția releu de acces (ARF) acționează ca un releu
(repeater) între echipamentul utilizatorului și subsistemul de atașare
rețea (NASS). Acesta primește solicitări de acces la rețea de la
echipamentul utilizatorului și le transmite către NASS. Înainte de a
trimite o solicitare, ARF poate introduce și informații de
configurare locale.
Funcția Gateway de semnalizare (SGF) realizează conversia
semnalizării (în ambele sensuri) la nivel de transport între
semnalizarea SS7 și semnalizarea pe IP.
Procesorul de funcții de resurse multimedia (MRFP) oferă
funcții specializate de procesare a resurselor, dincolo de cele
disponibile în MGW. Aceasta include resurse pentru susținerea
conferințelor multimedia, furnizarea de anunțuri multimedia,
implementarea capabilităților IVR și analiza conținutului media.
Funcția de gestionare a accesului (AMF) traduce solicitările
de acces la rețea emise de UE într-un format care poate fi înțeles de
NASS.
Funcția de transport de bază (BTF) conține două funcții
elementare de procesare a transportului: de expediere a traficului de
date și de control (de exemplu, să modifice comportamentul de
expediere existent). Elementele fizice de rețea (router-ul, bridge-ul
etc.) conțin de obicei un BTF și entități funcționale suplimentare,
de exemplu RCEF.
O rețea de acces cuprinde un segment de acces și un
segment de agregare (figura 1.9). Segmentul de acces (de asemenea
cunoscut sub numele de „segmentul ultimei mile”) se întinde de la
28
sediul clientului până la primul nod de rețea (cunoscut și sub
denumirea de „nodul de acces”). Segmentul de agregare cuprinde
elementele rețelei de transport care permit conectarea unuia sau mai
multor noduri de acces la o rețea de bază (numită Core) printr-un
router IP de frontieră (Edge).
Echipament
Rețea core
utilizator
Nod Elemente Nod IP de

de rețea
frontieră
acces transport
Acces Agregare
Figura 1.9. Segmente de acces și agregare
În configurațiile în care rețeaua de acces utilizează

tehnologia xDSL, segmentul de agregare se bazează pe ATM sau pe
Giga Ethernet. Nodul IP de frontieră este cunoscut sub numele de
Server de acces distant de bandă largă (BRAS) sau Gateway rețea
de bandă largă (BNG), iar nodul de acces este un DSLAM.
În configurațiile în care rețeaua de acces utilizează
tehnologia GPON, segmentul de agregare utilizează Giga Ethernet.
Nodul IP de frontieră este cunoscut sub numele de Gateway rețea de
bandă largă (BNG), iar funcțiile nodului de acces sunt distribuite
între Terminalul liniei optice (OLT) și Unitatea de rețea optică
(ONU)/Terminalul rețelei optice (ONT) [5].
1.5.2. Planul de serviciu NGN IMS
Planul de serviciu cuprinde următoarele componente:

 Subsistemul multimedia IP (Core IMS).
 Subsistemul de emulare a rețelei PSTN sau ISDN (PES).
29
 Alte subsisteme multimedia (de exemplu, subsistem dedicat
IPTV) și aplicații.
 Componente comune (utilizate de mai multe subsisteme),
cum ar fi cele necesare pentru accesarea aplicațiilor,
gestionarea profilului utilizatorului, asigurarea securității,
gestionarea funcțiilor de facturare, accesarea bazelor de date
de rutare (ENUM), etc.
Componenta de bază a IMS în arhitectura NGN (Core IMS)
acceptă furnizarea de servicii multimedia bazate pe SIP terminalelor
NGN. De asemenea, sprijină furnizarea de servicii de simulare
PSTN/ISDN. Figura 1.10 ilustrează poziția Core IMS în arhitectura
generală NGN.
Platforma IMS interacționjează cu următoarele componente:
 Echipamentul utilizatorilor.
 Subsistemul de control al resurselor și al admiterii RACS.
 Subsistemul de atașare la rețea NASS.
 Rețelele PSTN/ISDN.
 Subsistemul de emulare PSTN/ISDN.
 Alte subsisteme multimedia.
 Funcții de tarificare.
 Funcții de managament ai rețelei.
 Aplicații și alte elemente arhitecturale comune.
Mai detaliat subsistemul Core IMS este descris în capitolul 2.
Subsistemul de emulare PSTN/ISDN (PES) acceptă emularea
serviciilor PSTN/ISDN pentru terminalele vechi (moștenite)
conectate la NGN, prin gateway-uri rezidențiale RMGW sau
gateway-uri de acces AMGW (figura 1.11). Deci subsistemul de
emulare PSTN/ISDN gestionează interacțiunea dintre utilizatorii
interfeței PSTN și ISDN. Subsistemul de emulare se ocupă, de
asemenea, de interoperarea cu fragmentele de rețele PSTN și ISDN
rămase în exploatare.
30
Funcții Funcții
managament Aplicații/ tarificare
rețea elemente
comune
Echipament
utilizator
NASS RACS
Figura 1.10. TISPAN IMS și mediul său
Figura 1.11 arată tipurile de acces convenționale acceptate

de subsistemul de emulare PSTN/ISDN (PES):
 Telefoane analogice POTS prin Punctul de terminare a
rețelei naționale (NTP) (punctul de referință Z).
 Telefoane digitale ISDN cu rata de bază (punct de referință
S/T) prin intermediul unui echipament de terminare a rețelei
NTE furnizat la sediul clientului.
 Fragmente de rețele PSTN/ISDN prin mediagateway-uri de
trunk-uri T-MGW.
NOTĂ. Emularea PSTN/ISDN este definită în NGN ca:

Furnizarea de capabilități de serviciu și interfețe PSTN/ISDN
folosind adaptarea lor la infrastructură rețelelor bazate pe IP (ES
282 002 [8]).
31
POTS POTS
AMGW/ AMGW/
ISDN RMGW RMGW ISDN
Subsistemul de emulare
PSTN/ISDN (PES)
PSTN PSTN
T-MGW T-MGW ISDN
ISDN
Figira 1.11. Tipuri de acces convențional acceptate de

subsistemul de emulare PSTN/ISDN (PES)
Mai multe detalii despre funcționalitățile și arhitectura

subsistemului de emulare PSTN/ISDN pot fi găsite în capitolul 3.
Alte subsisteme media și aplicații: De exemplu, IP TV,
subsistem de streaming, subsistem de difuzare a conținutului etc.
Cei interesați de subiectul sistemului IPTV bazat pe NGN
IMS pot consulta, de exemplu, specificația tehnică ETSI TS 182
027 V3.5.1 [9] care determină structura și funcțiile subsistemului
de prestare a serviciilor de difuzare a programelor TV.
Componente comune ale arhitecturii NGN sunt acele entități
funcționale care pot fi accesate de mai multe subsisteme. Aceste
componente sunt necesare pentru accesarea aplicațiilor, pentru
tarificare, gestionare a profilului utilizatorului, gestionare a
securității, baze de date de rutare (de ex. ENUM) etc.
Ca exemple de componente comune pot fi numite:
 Funcția serverului profilului utilizatorului (UPSF);
 Funcția de localizare a abonamentului (SLF);
 Funcția serverului de aplicații (ASF);
 Funcția InterWorking (IWF).
Aceste entități funcționale comune vor fi expuse mai detaliat
în contextul unor exemple corespunzătoare.
32
2. PREZENTAREA GENERALĂ A NGN IMS
Arhitectura funcțională a rețelei de următoarea generație

NGN IMS oferă o imagine de ansamblu asupra entităților
funcționale IMS, punctelor de referință dintre ele și a
componentelor din afara IMS [4] (figura 2.1). Platforma IMS este o
colecție de entități funcționale care pot oferi împreună suport pentru
stratul de servicii al NGN [10]. Ea include elementele rețelei legate
de media și de semnalizare definite în ETSI TS 123 002 [11].
Componenta de bază a subsistemului multimedia IP a
arhitecturii NGN, numită Core IMS (nucleu sau de bază), suportă
furnizarea de servicii multimedia bazate pe SIP terminalelor NGN,
iclusiv prestarea de servicii de simulare PSTN/ISDN.
Rf/Ro
Ut Charging
AS
Sh
Functions
Dh
ISC/Ma
UPSF Rf/Ro Iw
Cx Dx SLF IWF
Ib
Network
Attachment Mw Mx
Subsystem I/S-CSCF Ic
Mx IBCF
« Core IMS » Mi Mk
Mr
BGCF
e2
Mw
Other IP Networks
Mj
Mx Mg
P-CSCF MGCF
MRFC Ie
Gq' Gq'
SGF
PSTN/ISDN
Mp Mn
Gm RACS RACS
MRFP T-MGF
C-BGF I-BGF
UE
Transport Processing Functions (Access and Core)
Figura 2.1. Prezentare generala NGN IMS
33
Entitățile legate de Core IMS sunt CSCF, MGCF, MRFC,
etc., astfel cum este definit în stadiul 2 al subsistemului IM ETSI TS
123 228 [2]. În cele ce urmează vor fi examinate fiecare dintre
entitățile funcționale ale subsitemului NGN IMS din figura 2.1.
2.1. Funcția de control a sesiunii de apeluri (CSCF)
Funcția de control a sesiunii de apeluri (CSCF) stabilește,

monitorizează, acceptă și eliberează sesiuni multimedia și
gestionează interacțiunea servicilor utilizatorului.
Există patru tipuri diferite de funcții de control a sesiunii de
apel (CSCF):
 Proxy-CSCF (P-CSCF),
 Servire-CSCF (S-CSCF),
 Interogare-CSCF (I-CSCF) și
 de Urgență- CSCF (E-CSCF).
Fiecare CSCF are propriile sarcini speciale. Comun la P-
CSCF, S-CSCF și I-CSCF este că toate participă la înregistrarea sau
reînregistrarea terminalelor în IMS și la stabilirea sesiunilor. Toate
aceste entități sunt în măsură să trimită date de taxare la o funcție de
taxare offline.
Entitățile P-CSCF și S-CSCF pot să elibereze sesiunea în
numele utilizatorului. De exemplu, atunci când S-CSCF detectează
o terminare de sesiune sau P-CSCF primește o notificare că un
purtător media este pierdut.
Funcțiile de control nominalizate se pot afla in diferite
noduri, dar prin colocarea lor gazda poate conține mai mult de o
entitate funcțională. Un exemplu tipic este cel în care S-CSCF, P-
CSCF, și l-CSCF sunt colocalizate. Colocația nu modifică
fundamental semnalizarea în rețea. Se aplică aceleași proceduri și
semnalizări, doar că mesajele IP parcurg o cale mai scurtă între
entitățile care se află în aceeași gazdă.
34
2.1.1. Funcția Proxy-CSCF
Proxy-CSCF este primul punct de contact pentru utilizatorii

din cadrul IMS (figura 2.2). Aceasta înseamnă că traficul de
semnalizare SIP se desfășoară între UE și P-CSCF. P-CSCF se
comportă ca un proxy SIP [12], adică acceptă cereri și servicii pe
care le furnizează intern sau le transmite mai departe. P-CSCF nu
modifică URI-ul cererii din mesajul SIP INVITE. El se comportă ca
un agent de utilizator UA, în anumite condiții poate încheia și iniția
în mod independent tranzacții SIP.
Figura 2.2. Poziția P-CSCF în rețeaua IMS
Există patru sarcini unice atribuite P-CSCF:

 compresia mesajelor SIP;
 asocierea de securitate IPSec;
 interacțiunea cu funcția politici și reguli de taxare (PCRF-
Policy and Charging Rules Function);
 detectarea apelului de urgență.
Deoarece SIP este un protocol de semnalizare bazat pe text
ce conține un număr mare de anteturi și parametrii antet, inclusiv
extensii și informații referitoare la securitate, dimensiunile
mesajelor sunt mai mari decât ale protocoalelor codate binar. Din
această cauză pentru accelerarea stabilirii sesiune 3GPP a decis să
35
se utilizeze compresia mesajelor SIP între UE și P-CSCF. Astfel
dacă UE a indicat că dorește să primească mesaje comprimate de
semnalizare P-CSCF comprimă aceste mesaje.
Principalele funcții îndeplinite de P-CSCF sunt [2]:
 Transmite cererea REGISTER SIP primită de la UE la un
punct de intrare determinat folosind numele de domeniu de
origine, astfel cum este prevăzut de UE.
 Redirecționează mesajele SIP primite de la UE către
serverul SIP (de exemplu, S-CSCF), al cărui nume P-CSCF
l-a primit ca urmare a procedurii de înregistrare.
 Asigură că mesajele SIP primite de la UE către serverul SIP
(de exemplu, S-CSCF) conțin informații corecte sau
actualizate cu privire la tipul rețelei de acces utilizate în
prezent de către UE.
 Asigură că mesajele SIP relevante conțin informațiile
corecte sau actualizate despre locația utilizatorului și fusul
orar furnizate de rețeaua de acces folosită în prezent de UE.
 Preia informații din subsistemul de atașare la rețea NASS
(de exemplu, locația fizică a echipamentului utilizatorului).
 Transmite cererea sau răspunsul SIP la UE.
 Detecta și tratează cererea de stabilire a sesiunii de urgență.
 Generează CDR (Charging Data Record sau Call Detail
Record) (vezi Nota mai jos).
 Menține o asociere de securitate IPSec între sine și fiecare
UE, astfel cum sunt definite în ETSI TS 133 203 [13].
 Efectuează compresia/decompresia mesajelor SIP.
 Autorizează resursele purtătoare și efectuează
managementul QoS (pentru detalii se poate consulta 3GPP
TS 23.203 și 3GPP TS 23.503).
 Detectează și manipulează cererea de inițiere sau de
încheiere a sesiunii MPS (Multimedia Priority Service).
Serviciul de prioritate multimedia MPS oferă utilizatorilor
acces la serviciile IMS într-o manieră prioritară.
36
 Interacționează cu RACS pentru marcajul de pachete,
alocarea resurselor și rezervarea lățimii de bandă pentru
traficul în sus (upstream) și în jos (downstream), etc.
NOTĂ. Înregistrarea datelor de taxare (CDR) este o
colecție de informații despre un eveniment care poate fi taxat (de
exemplu, timpul de stabilire a apelului, durata apelului, volumul de
date transferate, etc.) necesare pentru facturare și contabilitate.
Pentru fiecare abonat care urmează să fie taxat, pentru o partea a
unui eveniment taxabil sau integral, se generează un CDR separat.
Adică pentru un singur eveniment taxabil pot fi generate câteva
CDR (de exemplu, din cauza faptului că mai multe persoane
taxabile trebuie să fie facturate).
2.1.2. Funcția Interogare-CSCF
Funcția de interogare I-CSCF este punctul de contact cu

rețeaua operatorului pentru toate conexiunile destinate unui
utilizator local sau al unui utilizator de roaming situat în prezent în
zona de serviciu a operatorului de rețea (figura 2.3).
În rețea pot exista mai multe I-CSCF. Funcțiile îndeplinite
de I-CSCF sunt:
 Atribuirea unui S-CSCF la o cerere de înregistrare SIP a
utilizatorului.
 Rutarea cererii SIP primite de la o altă rețea spre S-CSCF
sau server de aplicații AS.
 Obținerea de la baza de date HSS a adresei S-CSCF.
 Traducerea adresei E.164 din URI-urile cererii SIP în
formatul telefon (format URI de IETF RFC 3966) înainte
de a interoga HSS despre locație.
 Transmiterea cererii sau răspunsului SIP la S-CSCF
determinată de etapa de mai sus.
 Generarea de CDR .
37
Figura 2.3. Interacțiunea I-CSCF cu alte unități funcționale
Reieșind din configurația locală, I-SCF poate îndeplini

funcții de rutare de tranzit. Dacă după interogarea HSS, I-CSCF
stabilește că destinația sesiunii nu se află în IMS, poate redirecționa
cererea sau transmite un răspuns de eșec către punctul de origine.
2.1.3. Funcția Servire-CSCF
Funcția Servire - CSCF efectuează controlul sesiunii în

numele UE. În cadrul rețelei unui operator posibil să existe câteva
S-CSCF care vor avea diferite funcționalități.
În timpul înregistrării UE sau sesiunii entitatea S-CSCF
efectuează următoarele funcții (figura 2.4):
 Ca Registrator - acceptă cereri de înregistrare și face
informațiile sale disponibile prin intermediul serverului de
locație (de exemplu, HSS sau UPSF).
38
Spre PSTN
altă rețea
sau domeniu
CS local
Figura 2.4. Interacțiunea S-CSCF cu alte entități

funcționale
 Ca Server proxy - acceptă cereri si le deservește pe intern

sau le transmite mai departe, eventual după traducere;
 Gestionează interacțiunea cu platformele de servicii SIP-AS
pentru asistența serviciilor.
 Furnizează punctului terminal informații legate de serviciu
(de exemplu, tonuri/anunțuri împreună cu alocarea de
resurse media suplimentare, date de facturare).
 Obține pentru UE de origine dintr-o bază de date adresa
terminalului solicitat după nume destinație (număr de
telefon sau SIP URI) atunci când cel solicitat este abonatul
altui operator și trimite cererea sau răspunsul SIP la
terminalul de intrare.
 Trimite solicitarea sau răspunsul SIP către un I-CSCF dacă
utilizatorul destinație este în aceiași rețea cu inițiatorul.
 Modifică solicitarea SIP pentru rutarea sesiunii de intrare
către domeniul CS dacă utilizatorul urmează să primească
sesiunea de intrare prin domeniul CS.
 Transmite mesajul SIP la un BGCF pentru rutarea
apelurilor către PSTN sau alt domeniu CS.
39
 Se asigură că terminalele de origine și destinație sunt
subscrise la serviciul de comunicare IMS solicitat.
 Se asigură că conținutul cererii sau răspunsului SIP (de
exemplu, valoarea inclusă în antetul Content-Type SIP,
descrieri tip media incluse în SDP) trimise sau primite de
către terminalele de origine sau de destinație se potrivește cu
serviciile de comunicare IMS determinate de abonamentele
acestor utilizatori.
 Transmite solicitarea sau răspunsul SIP către un P-CSCF al
rețelei de destinație.
 Ca Agent utilizator - poate independent iniția și termina
tranzacții SIP.
 generează CDR-uri .
Pe baza configurației locale, S-CSCF poate îndeplini funcții
de rutare de tranzit IMS.
2.1.4. Funcția de urgență E- CSCF
Funcția E-CSCF tratează anumite aspecte ale sesiunilor de

urgență cum ar fi rutarea cererilor de urgență către Centrul de
urgență sau Punctul de răspuns pentru siguranță publică PSAP
(Public Safety Answering Point) [14]. Rutarea se efectuează prin
BGCF, IBCF sau rețeaua IP multimedia pe baza informațiilor
despre locație și alte informații, cum ar fi tipul serviciului de
urgență din cerere. Serviciul E-CSCF îndeplinește principiile și
cerințele de urgență după cum urmează:
 Serviciile de urgență sunt independente de conectivitatea IP
(IP-CAN), trebuie să fie posibile prin cel puțin o rețea de
acces celular, un acces în bandă largă fixă, un acces nomad
și un acces WLAN la EPC sau acces non-3GPP la 5GC.
 Sunt acceptate orice tipuri de numere de urgență (URI SIP și
Telefon de urgență). URI-urile autorizate să rezolve
serviciile de urgență pot fi supuse reglementărilor locale în
rețeaua de deservire.
40
 Sistemul trebuie să acorde prioritate sesiunilor de urgență
față de celelalte sesiuni.
 Stabilirea sesiunii de urgență IMS trebuie să fie posibilă
pentru utilizatorii cu o identitate de utilizator public blocată.
 Important este că UE să poată detecta sesiunea de urgență
(analizând SIP-URI sau numărul format) și să anunțe despre
sesiunea de urgență rețeaua. Este acceptat și cazul când UE
nu poate detecta sesiunea de urgență.
 Serviciul de urgență nu este un serviciu cu abonament.
 Dacă o cerere de stabilire a sesiunii de urgență este trimisă
către un P-CSCF localizat în rețeaua de origine, rețeaua de
origine ar trebui să poată detecta că sesiunea este destinată
serviciului de urgență (indiferent dacă este indicat ca atare
sau nu) și să răspundă UE indicând că UE ar trebui să
inițieze o sesiune de urgență în rețeaua vizitată (de exemplu,
prin domeniul CS al rețelei vizitate).
 Centrele de urgență pot fi conectate la PSTN, domeniul CS,
domeniul PS sau orice altă rețea de pachete.
 Arhitectura va permite centrelor de urgență să solicite un
apel înapoi (call back) la o UE cu care centrele de urgență
au avut o sesiune de urgență.
 Rețeaua core IMS trebuie să dețină informații cu privire la
locația abonatului.
 Rețeaua va permite UE să obțină numere locale de urgență.
 UE trebuie să sprijine capacitatea de a obține numere locale
de urgență din rețea.
 Rețeaua împiedică trimiterea informațiilor utilizatorilor, cum
ar fi identificatorii publici și informațiile despre locație către
centrul de urgență, dacă restricția este solicitată în mod
explicit de către utilizator și reglementările locale impun
operatorului să ofere confidențialitate utilizatorului.
 E-CSCF este entitatea rețelei IMS, care trebuie să poată
prelua informații despre locația geografică de la LRF
(Lacation Retrieval Function) în cazul în care informațiile
41
despre locația geografică nu sunt disponibile și sunt
necesare.
 Dacă este necesar, E-CSCF trebuie să poată transmite
informațiile de locație către LRF pentru validarea
informațiilor despre locația geografică dacă informațiile
privind locația sunt incluse de UE.
Atunci când UE efectuează o înregistrare de urgență,
restricțiile și lipsa de roaming sunt ignorate. Setul de înregistrare
implicit al identificatorului de utilizator public utilizat pentru
înregistrările de urgență trebuie să conțină un URI TEL asociat.
Funcțiile efectuate de E-CSCF în timpul unei sesiuni de
urgență sunt:
 Recepționează cererea de stabilire a sesiunii de urgență de la
P-CSCF sau S-CSCF.
 Solicită de la LRF informații despre locația UE dacă aceste
date nu sunt incluse în cererea de urgență sau sunt necesare
informații suplimentare despre locație.
 Solicită LRF să valideze informațiile despre locație, dacă
sunt incluse de UE.
 Determină sau solicită de la LRF informațiile de rutare spre
central de urgență potrivit.
 Direcționează cererea de stabilire a sesiunii de urgență,
inclusiv anonimă, către o destinație apropiată.
 Pe baza politicii operatorului, E-CSCF poate direcționa
apelul IMS de urgență către ECS (Emergency Call Server)
pentru procesarea suplimentară a apelului.
 Generează CDR-urile.
Începând cu luna martie 2018 în Europa este desfășurat
serviciul de urgență eCall care este cerut de lege în mașinile noi.
eCall este un sistem standardizat și mandatat pentru o formă
specială de apeluri de urgență efectuate de vehicule, oferind
comunicații în timp real și un set integrat de date conexe [15].
42
Sistemul eCall folosește un modem în bandă pentru a
transfera setul minim de date (MSD -Minimum Set of Data) într-un
canal vocal GSM printr-un apel de urgență 112. Se estimează că
penetrarea 100% a sistemului va fi realizată până în 2035.
Operatorii din Europa au anunțat că vor elimina treptat
suportul rețelelor cu comutație de circuite GSM și UMTS în
următorul deceniu și îl vor înlocui cu infrastructuri 4G LTE și 5G.
Acest lucru va avea, de asemenea, un impact asupra apelului de
urgență 112. El va fi înlocuit cu un apel de urgență IMS prin rețele
cu comutație de pachete precum LTE și 5G (figura 2.5). Generația
viitoare eCall (NG eCall) va oferi mari avantaje în comparație cu
eCall, va fi construită pe LTE și 5G și va asigura transferul MSD
mult mai rapid și mai fiabil. Comunicările vocale nu vor fi
întrerupte în timpul transmisiei MSD. Va devine posibil transferul
de informații suplimentare, de exemplu, video de la camera de bord,
mesaje text, controlul prin telecomandă a funcțiilor mașinii
(sunetului claxonului, intermitentul farurilor, blocarea/deblocarea
ușilor, dezactivarea aprinderii etc.).
În cazul NG-eCall, cererea de stabilire a sesiunii de urgență
IMS poate fi invocată fie automat, fără implicarea utilizatorului, fie
manual, prin intermediul utilizatorului.
Pentru detalii referitor la serviciul de urgență în IMS inclusiv
elementele necesare pentru a sprijini serviciile date se poate
consulta specificația ETSI TS 123 167 [16].
43
Figura 2.5. Configurare de bază a funcționalității NG eCall
într-un sistem încorporat în vehicul IVS
2.2. Funcţia de control a gateway-ului de ieșire (BGCF)
Una din sarcinile S-CSCF la originarea unei sesiuni SIP,

este să determine rețeaua de destinație. Dacă după interogarea
44
ENUM nu se obține un SIP URI, atunci S-CSCF va iniția
"breakout“ (apel de ieșire). Motivul de breakout este că S-CSCF
poate ruta numai după SIP URI, nu numere de telefon. Apelul va fi
direcționat către o altă rețea care rutează pe numere de telefon, de
exemplu PSTN sau PLMN (figura 2.6).
Rețea gazdă Altă rețea
PSTN PSTN
Figura 2.6. Exemplu de apel spre o rețea PSTN
Pentru breakout, S-CSCF transmite SIP INVITE la BGCF

(Breakout Gateway Control Function).
În dependență de configurația locală, BGCF determină
următorul hop pentru rutarea mesajului SIP. Rutarea se bazează pe
informațiile primite în protocolul de semnalizare, informații
administrative sau prin acces la baza de date. Dacă destinația este o
rețea PSTN care se află în altă rețea, atunci BGCF determină
această rețea și transmite semnalizările SIP la un BGCF din rețeaua
selectată. Însă dacă destinația este un domeniu CS, dar în aceeași
rețea în care se află BGCF, atunci BGCF va selecta un MGCF care
va fi responsabil pentru interoperarea cu domeniul PSTN/CS.
45
În cazul când destinația este altă rețea IMS, atunci BGCF
transmite mesajul către un I-CSCF din acea rețea IMS.
În rețea pot fi mai multe BGCF. Fiecare BGCF poate
generarea CDR-uri.
2.3. Funcția de control interconectare la frontieră (IBCF)
Entitatea IBCF (Interconnection Border Control Function)

oferă funcții specifice la nivelul de aplicare a protocolului SIP/SDP
în scopul de a efectua interconectarea între două domenii ale
operatorului. Funcția IBCF acționează ca SIP proxy și este utilizată
pentru interconectarea între două rețele IMS (figura 2.7) sau o rețea
IMS cu rețea IP non-IMS. IBCF poate acționa atât ca punct de
intrare, cât și ca punct de ieșire pentru rețeaua subsistemului IM
CN.
Funcționalitățile IBCF includ comunicarea între aplicațiile
SIP IPv6 și SIP IPv4, ascunderea topologiei de rețea (numărului
exact de S-CSCF, capacităților S-CSCF sau capacității rețelei, etc),
controlul cu H.248 a gateway-lui de tranziție TrGW (Transition
Gateway), screening-ul informațiilor de semnalizare SIP, selectarea
modului de interconectare corespunzător, asigurarea
confidențialității și generarea datelor de facturare. IBCF include un
identificator inter-operator IOI ( Inter-Operator Identifier) în cereri
atunci când acționează ca punct de intrare pentru o rețea de tranzit și
în răspunsuri atunci când acționează ca punct de ieșire pentru o
rețea de tranzit. Identificatorul inter operator IOI este un
identificator unic la nivel global, care este utilizat pentru a transfera
identitățile și rolurile diferitelor rețele în cadrul unui apel.
46
Figura 2.7. Exemplu interconectare rețele IMS
Identificatorul IOI este utilizat pentru partajarea și corelarea

informațiilor de facturare generate în cadrul IMS între rețelele
operatorilor, furnizorii de servicii sau de conținut.
Atunci când rețelele participante la sesiune au diferite
profiluri SIP (de exemplu, între profilul SIP utilizat în IMS și
celelalte profiluri SIP sau protocolul H.323), entitatea IBCF
introduce funcția de interlucrare IWF (Interworking Function) în
calea de semnalizare (figura 2.8). În acest caz IWF acționează ca un
punct de intrare pentru rețeaua IMS. IWF și IBCF pot fi colocate
într-un singur nod fizic.
În cazul aplicării conceptului de control la frontieră în
rețeaua IMS, IBCF acționează ca un punct de intrare și punct de
ieșire pentru această rețea (în loc de I-CSCF). În acest caz, IBCF și
I-CSCF pot fi co-localizate într-un singur nod fizic.
47
Core IMS
Rețea H.323
H.323 network
Or
P-CSCF S-CSCF IBCF IWF sau altă rețea
Other non-IMS SIP
non-IMS
network SIP
Mw Mx Ib Iw
Frontiera dintre
domenii
Domains boundary
Figura 2.8. Interconectare rețea IMS cu rețea non-IMS
2.4. Funcția de control a gateway-ului media (MGCF)
Interconectarea dintre rețelele NGN IMS și PSTN/ISDN la

nivel de semnalizare este asigurată prin intermediul SGF (transport)
și MGCF (apel/control serviciu). Interconectarea la nivel fluxuri
media este asigurată de interfețele de trunchi de la T-MGF.
Funcția MGCF (Media Gateway Control Function) oferă
posibilitatea de a controla o funcție de trunking media gateway (T-
MGF) printr-o interfață standardizată. Un astfel de control include:
 Alocarea sau sustragerea resurselor media gateway-lui care
se referă la controlul conexiunilor canalelor media în T-
MGW, precum și modificarea utilizării acestor resurse.
 Comunicarea cu CSCF, BGCF și cu entitățile din rețeaua cu
comutarea de circuite.
 Stabilirea următorului hop în rutarea IP în funcție de
informațiile de semnalizare primite în cazul apelurilor din
rețelele convenționale.
 Realizarea conversiei între protocoalele ISUP și SIP precum
și interacțiunii dintre SIP și semnalizarea SS7 ce nu se referă
48
la apeluri (adică semnalizare bazată pe TCAP pentru servicii
suplimentare).
 Îndeplinirea funcției de tranzit pe baza configurației locale.
Această entitate funcțională este identică cu MGCF definită
în ETSI TS 123 002 [11], cu excepția faptului că, în plus, acceptă
interoperarea cu TCAP. Nodurile care implementează această
entitate funcțională în rețeaua NGN pot să difere după configurație
și resursele acceptate (de exemplu codic-uri) față de cele dintr-o
rețea 3GPP.
Punctul de referință Mg (figura 2.1) permite MGCF să
transmită semnalizarea sesiunii primite (de la PSTN) către CSCF în
scopul interoperarii cu rețelele PSTN. Protocolul folosit pentru
punctul de referință Mg este SIP.
Punctul de referință Mn permite T-MGF să interacționeze
H.248 cu MGCF pentru controlul resurselor.
T-MGF termină canalele purtătoare din rețeaua CS și
fluxurile media RTP din rețea IMS, susține conversia media și
procesarea traficului util, deține și gestionează resurse, cum ar fi
anulatoare de ecou, codec-uri, etc.
Punctul de referință Ie permite MGCF să facă schimb de
informații de semnalizare SS7 prin IP cu SGF, conform arhitecturii
SIGTRAN.
Funcția gateway-lui de semnalizare SGW este utilizată
pentru interconectarea rețelelor cu diferite tipuri de semnalizare.
SGW realizează conversia semnalizării SS7 din rețelele cu
comutație de circuite CS și semnalizării bazată pe IP utilizată în
rețelele IMS (adică între SS7 MTP și Sigtran SCTP/IP, figura 2.9).
SGW nu traduce mesajele planului aplicaților (de exemplu,
mesajele MAP, BICC, ISUP), dar interpretează nivelul purtător
SCCP sau SCTP pentru a asigura rutarea corectă a semnalizării.
49
Rețea Rețea
transport SGW transport
semnaliz semnaliz
are IP SCTP/IP MTP are SS7
Figura 2.9. Configurarea funcției gateway-lui de

semnalizare
Funcția gateway-lui de semnalizare poate fi implementată ca

o entitate de sine stătătoare sau în interiorul altei entități.
2.5. Funcția resurse multimedia (MRF)
Funcția resurse multimedia MRF (Multimedia Resource

Function) se divizează în două:
Funcția resurse multimedia controlor MRFC (Multimedia
Resource Function Controller) și Funcția resurse multimedia
procesor MRFP (Multimedia Resource Function Processor), care
oferă împreună mecanisme pentru servicii legate de media, cum ar
fi conferințe, anunțuri multimedia sau transcodarea.
Arhitectura privind funcția resurse multimedia este
prezentată în figura 2.10.
Controlorul MRFC comunică prin semnalizările SIP cu S-
CSCF și controlează procesorul MRFP prin protocolul H.248.
Sarcinile entității funcționale MRFC sunt următoarele:
 Controlul resurselor fluxului media din MRFP.
50
 Interpretarea informațiilor provenite de la un AS și S-CSCF
(de exemplu, identificatorul sesiunii) și controlul
corespunzător al MRFP.
 Generarea CDR-urilor.
AS
Cr
ISC
Mr′
Mr
S-CSCF MRFC
Mp
MRFP
Figura 2.10. Arhitectura MRF[2]
Sub controlul MRFC procesorul MRFP efectuează toate

manipulările necesare pentru susținerea conferințelor multimedia,
furnizarea de anunțuri multimedia, implementarea capabilităților
IVR și anume:
 Mixează fluxurile media de intrare (de exemplu, pentru mai
multe părți).
 Generează fluxuri media (pentru anunțuri multimedia).
 Prelucrează fluxurile media (de exemplu, transcodarea
audio, analiza media).
 Oferă resurse pentru a fi controlate de către MRFC.
Sarcinile serverului de aplicații AS în raport cu funcția
resurse media MRF constau, în particular, în rezervarea conferinței
51
și gestionarea informațiilor despre rezervare (de exemplu ora de
pornire, durata, lista participanților).
2.6. Componente comune ale platformei IMS
2.6.1. Funcția UPSF
Funcția serverului de profil utilizator UPSF (User Profile

Server Function) este responsabilă pentru păstrarea la nivel de
serviciu a informațiilor legate de utilizator:
 Privind identificarea, numerotarea și adresarea utilizatorului.
 Privind securitatea utilizatorilor.
 Despre locația utilizatorului.
 Despre profilul utilizatorului.
UPSF poate stoca informații despre profilul utilizatorului
legate de una sau mai multe subsisteme de control al serviciilor și
aplicațiilor. UPSF nu conține informații de profil legate de abonare
de conectivitate IP. Aceste informații sunt păstrate în subsistemul de
atașare la rețea (NASS). Cu toate acestea, acolo unde are sens în
contextul unui anumit model de afaceri, UPSF-ul poate fi colocat cu
funcția de bază de date a NASS.
Subsetul UPSF care găzduiește date referitoare la IMS este
echivalent cu subsetul entității HSS definit pentru 3GPP IMS de TS
123 002 [11], cu excepția funcționalității HLR/AUC.
2.6.2. Serverul HSS
Serverul date abonați HSS (Home Subscriber Server) ca

entitate a subsistemului 3GPP IMS este responsabil pentru deținerea
următoarelor informații legate de utilizator:
52
 Datelor privind identificarea, numerotarea și adresarea
utilizatorului;
 Informații de securitate, astfel ca datele de control a
accesului la rețea, de autentificare și autorizare;
 Înregistrarea utilizatorului și păstrarea datelor despre locația
lui la nivel de inter-sistem;
 Informații legate de profilul utilizatorului.
În subsistemul TISPAN NGN IMS serverul HSS din 3GPP
IMS este înlocuit cu o funcție similară UPSF care a fost descrisă
mai sus.
2.6.3. Funcția SLF
Funcția de localizare a abonamentelor SLF (Subscription

Locator Function) este o entitate funcțională care poate fi accesată
de subsistemele de control al serviciilor și funcțiile serverului de
aplicații ASL pentru a prelua identitatea UPSF-ului unde este
disponibil profilul nivelului de serviciu al unui anumit utilizator sau
serviciu public.
Această entitate funcțională este identică cu SLF-ul definit
în TS 123 002 [11]. Totuși un nod care implementează această
entitate funcțională într-o rețea NGN poate fi diferit de un nod de
rețea 3GPP în ceea ce privește formatele de identitate acceptate.
Funcția SLF este interogată de I-CSCF în timpul înregistrării
și stabilirii sesiunii pentru obținerea numelui UPSF/HSS care
conține datele abonatului. În plus, SLF este interogat de S-CSCF, în
timpul înregistrării, de AS sau serverul 3GPP AAA pentru a obține
numele UPSF/HSS care conține datele abonatului.
2.6.4. Funcția IWF
Funcția de interoperabilitate IWF (InterWorking Function)

realizează interacțiunea dintre protocoalele utilizate în subsistemele
53
de control servicii în cadrul TISPAN NGN și alte protocoale bazate
pe IP. De exemplu, între profilul SIP utilizat în IMS și alte profiluri
SIP sau protocolul H.323.
2.6.5. Funcția de taxare
Funcția de taxare (facturare) este o entitate din interiorul

domeniului rețelei core, subsistemului sau serviciului implicată în
contabilizare pentru acel domeniu, subsistem sau serviciu.
Arhitectura de taxare, principiile de taxare și datele de taxare pentru
subsistemul IM CN sunt descrise în ETSI TS 132 260 [17].
Taxarea este o funcție în cadrul rețelei de telecomunicații
prin care informațiile referitoare la un eveniment taxabil sunt
colectate, formatate, transferate și evaluate pentru a face posibilă
determinarea utilizării pentru care abonatul poate fi facturat (taxare
offline) sau soldul contului abonatului poate fi debitat (taxare
online).
Elementele funcționale ale IM CN oferă suport pentru
taxarea online și offline:
Taxarea offline este mecanismul de taxare în care
informațiile de taxare nu afectează, în timp real, serviciul prestat.
Taxarea online este mecanismul de taxare în care
informațiile de taxare pot afecta, în timp real, serviciul prestat și,
prin urmare, este necesară o interacțiune directă a mecanismului de
taxare cu controlul sesiunii/serviciului.
Arhitectura pentru taxarea offline a IMS-ului este prezentată
în figura 2.11.
54
Funcționalitatea de taxare offline se bazează pe entitățile de
rețea IMS care raportează informațiile contabile la recepția
mesajelor SIP sau ISUP (deoarece informațiile relevante de
facturare sunt incluse în aceste mesaje).
Această raportare se realizează prin trimiterea CDR-urilor de
la elementele rețelei IMS către Funcția de taxare a datelor CDF
(Charging Data Function) parte a Funcției de colectare a taxelor
CCF (Charging Collection Function). CCF este un sistem de taxare
offline care colectează și prelucrează informațiile de facturare
înainte de livrarea lor în domeniul de facturare BD (Billing
Domain). CDR-urile produse de CDF sunt transferate imediat la
Funcția gateway de taxare CGF (Charging Gateway Function).
CGF acționează ca un gateway de acces între rețeaua 3GPP

și BD și include următoarele funcții principale:
 Pre-procesarea CDR:
 validarea, consolidarea și (re)formatarea CDR-urilor;
 gestionarea erorilor CDR;
 stocarea CDR persistentă.
 Stocarea CDR-urilor pe fișiere separate pe baza criteriilor de

filtrare precum tipul, parametrii CDR, CDF-ul originar, etc.
 Gestionarea fișierelor CDR, de exemplu crearea, declanșarea

(deschiderii/închiderii) sau ștergerea fișierului.
 Transferul de fișiere CDR la BD.

Arhitectura de taxare online a IMS-ului este descrisă în
figura 2.12. Sistemul de taxare online OCS (Online Charging
System) este entitatea care efectuează controlul creditului abonatului
în timp real. Funcționalitatea sa include gestionarea tranzacțiilor,
evaluarea, corelația online și gestionarea conturilor/soldurilor
abonaților.
55
SIP-AS și MRFC sunt capabili să distingă dacă aplică
tarifarea offline sau online, adică dacă trimit informații de tarifare
către CDF sau către OCS. Decizia ce tarifare să folosească se
bazează pe informațiile (adresa CDF sau OCS) pe care AS/MRFC
le primește în mesajele SIP și configurația sistemului aleasă de
operator.
Billing Domain
Rf
Bi BGCF
Rf
MGCF
Rf
MRFC
Rf
SIP AS
CGF
Rf
Ga
P-CSCF
CDF Rf
I-CSCF
CCF Rf
S-CSCF
Rf
IBCF
Rf
E-CSCF
Rf
TRF
Rf
ATCF
Rf
IMS Transit
Functions
Unde: ATCF - Funcția de control al transferului de acces

TRF - Funcția de tranzit și roaming
Figura 2.11. Arhitectura de taxare offline IMS

56
TypeUnitOrDepartmentHere
TypeYourNameHere TypeDateHere
În cazurile în care sunt furnizate ambele adrese este posibilă

utilizarea ambelor sisteme de taxare concomitent.
Toate celelalte elemente de rețea IMS (S-CSCF, P-CSCF, I-
CSCF, BGCF, IBCF și MGCF) aplică taxarea offline prin interfața
Rf folosind adresa CDF primită prin mesajul SIP. S-CSCF acceptă
taxarea online dacă funcția Gateway IMS este integrată în S-CSCF.
Corelația de domeniu IMS se bazează pe identificatorul de
taxare IMS ICID (IMS Charging Identifier), distribuit între
elementele de rețea IMS implicate în aceeași sesiune. Cu ICID este
posibilă corelarea datelor de taxare sesiune generate în diferite
elemente IMS (de exemplu, x-CSCFs, ASs).
Billing Domain
Ro
OCS
MRFC
MGCF OCS
SIP-AS
BGCF
Ro
ISC Ro
S-
- CSCF IMS - GWF
Figura 2.12. Arhitectura de taxare online IMS
Elementele de rețea IMS mențin integritatea tuturor

informațiilor de tarifare, primite sau create, atunci când ele se trimit
către sistemele de taxare offline și online, indiferent de lungimea
valorii unui parametru anume. De exemplu, identificatorul de taxare
57
IMS ICID poate fi generat de un element de rețea IMS (de
exemplu, P-CSCF) și trimis către un alt element de rețea IMS (de
exemplu, S-CSCF). Ambele pot genera informații de taxare și
asigura menținerea integrității datelor, pentru a face posibilă
corelația bazată pe ICID.
2.6.6. Serverul de aplicații AS
Într-o rețea există în general mai multe servere de aplicații

AS (Application Server) fiecare fiind specializat în furnizarea
anumitor servicii. IMS definește trei tipuri diferite de servere de
aplicații care oferă servicii IP multimedia cu valoare adăugată.
Aceste servere sunt SIP AS, IM-SSF și OSA AS (figura 2.13).
SIP-AS OSA
IN SCF
AS
INAP OSA API
Sh
Si
(CAMEL only) OSA
IM-SSF Sh SCS
UPSF
ISC or Ma Dh
Cx Dx SLF
I/S-CSCF
IMS core
component
Transport Layer
Figura 2.13. Interconectarea serverilor de aplicații cu IMS core
58
AS-urile pot fi localizate în rețeaua de domiciliu sau într-o
rețea furnizor de servicii terță parte. Partea terță poate fi o rețea sau
un AS autonom. Interfața definită între S-CSCF și AS este
cunoscută sub numele de interfață ISC (IMS Service Control).
a) Serverul de aplicații SIP este AS-ul nativ în IMS. Noile
servicii dezvoltate exclusiv pentru IMS mai probabil să fie
implementate de către SIP AS. Serverul SIP AS gestionează și
interpretează mesajele SIP primate de la S-CSCF și transpune
logica serviciului utilizatorului final în secvențe de mesaje SIP, pe
care le trimite părților implicate, din nou prin S-CSCF.
b) Serverul de aplicații - arhitectura de servicii deschise OSA
AS (Open Service Architecture) implementează pentru abonații IMS
o bază de servicii existentă. Pentru a oferi acces la aceste servicii
IMS-ul are nevoie de gateway-ul OSA-SCS (Open Service Access -
- Service Capability Server). Așadar OSA-SCS oferă o interfață
externă pentru IMS către serverul OSA AS. OSA-SCS oferă, de
asemenea, interfața ISC către S-CSCF bazată pe SIP și poate utiliza
interfața Sh opțională către UPSF/HSS.
Pe baza OSA SCS operatorul poate utiliza caracteristici ale
capabilității de serviciu precum controlul apelurilor, statutul
utilizatorului, controlul sesiunii de date, capabilitățile terminalelor,
gestionarea contului, tarifarea și gestionarea politicilor pentru
serviciile dezvoltate. Cadrului OSA SCS poate fi utilizat ca
mecanism standard pentru furnizarea către IMS de AS terțe într-o
manieră sigură, deoarece OSA în sine conține funcții de acces ca
autentificarea, autorizarea, funcții de descoperire și înregistrare (S -
CSCF nu oferă funcții de autentificare și securitate pentru accesul
securizat direct al unei terțe părți la IMS).
c) Cel de-al treilea tip de server de aplicații este funcția de
comutare a serviciului IP multimedia IM-SSF (IP Multimedia
Service Switching Function ). Acesta oferă un gateway de acces
către rețelele de servicii moștenite care implementează serviciile
CAMEL (Customized Applications for Mobile Network Enhanced
59
Logic - Aplicații personalizate pentru logica îmbunătățită a rețelei
mobile), pe larg utilizate în rețelele GSM. IM-SSF acționează ca un
gateway de acces între serviciile bazate pe SIP și CAMEL,
permițând astfel serviciile CAMEL să fie invocate de la IMS.
În figura 2.13 se prezintă IM-SSF în contextul TISPAN IMS
[4]. Aici scopul IM-SSF este de a permite accesul la programele de
logică de servicii inteligente IN găzduite în SCP moștenite.
Funcționalitatea IM-SSF cuprinde emularea modelului de apel IN
în partea de sus a semnalizării SIP, a declanșării IN și a interoperarii
cu INAP. Serverul de aplicații IM-SSF identificat în TISPAN IMS
[4] diferă de cel identificat în 3GPP IMS [11]. Acesta din urmă
implementează modelul și protocoalele de apel CAMEL, în timp ce
primul implementează fie modelul și protocoalele de apel CAMEL,
fie funcțiile ETSI Core INAP sau ambele modele concomitent.
Punctul de referință Si este utilizat doar pentru serviciile CAMEL.
Punctul de referință S-CSCF către AS este utilizat pentru a
transmite cererile SIP, pe baza criteriilor de filtrare asociate
utilizatorului inițiator sau destinatar.
Punctul de referință I-CSCF către AS este utilizat pentru a
transmite cereri SIP destinate unei identități de serviciu public
găzduite de AS.
2.7. Funcția gateway-ului de frontieră (BGF)
Funcția gateway-ului de frontieră BGF (Border Gateway

Function) asigură interfața dintre două domenii de transport IP.
BGF se afla la frontiera dintre o rețeaua de acces și echipamentele
terminale ale clienților, între rețeaua de acces și rețeaua core sau
între două rețele core. Ea susține una sau mai multe dintre
următoarele funcții elementare:
 Contorizarea utilizării resurselor.
 Alocarea și traducerea adreselor IP și a numerelor de port
(NAPT).
60
 Interoperarea între rețelele IPv4 și IPv6 (NAPT-PT).
 De asistență în traversarea NAT găzduită.
 De transcodare.
Se identifică două tipuri principale de BGF (figura 2.14):
 Core BGF (C-BGF) care se află la frontiera dintre rețeaua de
acces și rețeaua core;
 BGF de interconectare (I-BGF) care se află la frontiera
dintre două rețele Core.
Rețea Core
Rețea de Alte funcții de Alte rețele
acces C-BGF procesare a I-BGF Core
transportului
Figura 2.14. Funcții gateway-ului de frontieră BGF
3. SUBSISTEMUL PES
3.1. Arhitectura PES
Subsistemul de emulare PSTN/ISDN bazat pe IMS (PES)

descris în acest capitol acceptă emularea serviciilor PSTN pentru
terminalele analogice și serviciilor ISDN pentru terminalele digitale
și PBX-uri. Aceste echipamente terminale pot fi conectat direct la
media gateway-uri rezidențiale (R-MGW) și de acces (A-MGW)
sau prin noduri de acces V5.
Figura 3.1 oferă o imagine de ansamblu asupra entităților
funcționale care alcătuiesc arhitectură subsistemului de emulare
PSTN/ISDN și arată relațiile lor cu celelalte componente ale
61
arhitecturii NGN [18].
Scopul subsistemului de emulare PSTN/ISDN este de a
permite utilizatorilor existenți în rețelele bazate pe tehnologia TDM
să primească aceleași servicii de la rețeua NGN pe care l-au primit
anterior de la PSTN sau ISDN.
Arhitectura funcțională prezentată în figura 3.1 este una
dintre opțiunile de structură posibile ale subsistemului de emulare
PES identificat în arhitectura generală TISPAN NGN (figura 1.8).
Această arhitectură funcțională utilizează aceeași arhitectură ca
IMS-ul definit în TS 123 517 [4] cu extensiile definite în prezentul
capitol.
Rf/Ro
Ut Aplication Charging
AS Emulation
PSDN/ISDN
Sh
Functions
Dh
ISC/Ma
UPSF Rf/Ro Iw
Cx Dx SLF IWF
Ib
Network
Attachment Mw
Subsystem
PES Mx
Ic
I/S-CSCF IBCF
Mx
« Core IMS » Mi Mk
AGCF Mr
BGCF
e2
Mw
Other IP Networks
Mj
Mx Mg
P-CSCF MGCF
MRFC Ie
P1
Gq' Gq'
SGF
PSTN/ISDN
Mp Mn
Gm RACS RACS
PSTN/ISDN
MRFP T-MGF
access C-BGF I-BGF
(A/R-MGW)
UE
Transport Processing Functions (Access and Core)
Figura 3.1. Arhitectură funcțională a subsistemului PES
Majoritatea entităților funcționale din subsistemul de

emulare PSTN/ISDN sunt identice sau derivate de la analogul lor
62
din NGN IMS [4], cu excepția Funcției de control acces gateway
(AGCF-Access Gateway Control Function) care controlează
gateway-urile rezidențiale și de acces. Pentru celelalte entități
funcționale, toate diferențele sunt notate în cele ce urmează. Un nod
fizic poate găzdui entități funcționale care susțin atât PES, cât și
NGN IMS, suportate de o schemă de adresare comună.
3.2. Prezentare generală a entităților funcționale ale PES
Funcția de control acces gateway (AGCF) este primul punct

de contact pentru gateway-urile rezidențial R-MGW și de acces A-
MGW. Această entitate este specifică subsistemului de emulare
PSTN/ISDN și îndeplinește următoarele funcții principale:
 Acționează ca un MGC pentru controlul funcțiilor gateway-
urilor media (R-MGF și A-MGF).
 Interacționează cu subsistemul de control al resurselor și al
admiterii (RACS).
 Interacționează cu subsistemul de atașare la rețea (NASS)
pentru a prelua informații despre profilul liniei.
 Efectuează interoperabilitatea semnalizării SIP cu
semnalizarea din PSTN/ISDN.
 Acționează ca agent utilizator SIP în relațiile cu entitățile
funcționale IMS SIP.
 Efectuează funcții atribuite în mod normal unui P-CSCF
pentru terminalele vechi conectate la gateway-ul media (de
exemplu, gestionează procedurile de înregistrare SIP,
creează identificatori de facturare).
În plus, AGCF furnizează modelele de tonuri adecvate celor
din rețelele PSTN, de exemplu, tonul de disc, tonul de apel.
Funcția P-CSCF are un comportament identic cu cel din
subsistemul NGN IMS TS 123 517 [4]. Cu toate acestea, P-CSCF
nu este utilizat în configurații în care un AGCF este necesar pentru
a controla gateway-urile rezidențiale sau de acces. În astfel de
63
cazuri, toate funcțiile furnizate în mod normal de P-CSCF vor fi
furnizate direct de AGCF.
Rolul MGCF în subsistemul PES este similar cu cel din
subsistemul NGN IMS [4]. Doar că procedurile de semnalizare
pentru interoperarea cu semnalizarea ISUP sunt ușor diferite
datorită prezenței informațiilor ISUP încapsulate în interiorul PES și
necesității de a asigura transparența deplină a ISDN în cazul
apelurilor ISDN care tranzitează prin PES.
Celelalte entități funcționale PES sunt identice celor din
NGN IMS.
Arhitectura de serviciu pentru subsistemele PES și TISPAN
IMS este aceeași (figura 2.13) și comportamentul generic al
funcțiilor serverilor de aplicație sunt identice. Cu toate acestea, în
funcție de tipul de servicii care se emulează, este posibil ca unele
servere de aplicații vor trebui să recepționeze și să citească
protocolul ISUP încapsulat în SIP. Deși unele servere de aplicații
pot fi dedicate furnizării de servicii specifice PES, arhitectura PES
nu restricționează tipul de aplicații care pot fi accesate de un
utilizator PES.
Pentru detalii consultați ES 282 002 [8] și TS 182 012 [18]
care definesc arhitecturi funcționale alternative pentru acest
subsistem.
4. EXEMPLE ÎNREGISTRARE ȘI CONEXIUNI ÎN IMS
4.1. Înregistrarea terminalului UE în IMS
În figura 4.1 este prezentată secvența de mesaje și proceduri

necesare pentru înregistrarea unui echipament terminal UE în
subsistemul multimedia IP. În cele ce urmează va fi descris detaliat
modul de interacțiune dintre entitățile IMS implicate în procesul de
înregistrare a UE.
64
Mesajele aduse în continuare nu prezintă cereri sau
răspunsuri complete a procesului de înregistrare a terminalului UE
în IMS, lipsesc unele anteturi și parametri. Aceste mesaje includ
doar informațiile necesare pentru explicarea procedurilor
desfășurate.
Terminalul abonatului UE trimite cererea de înregistrare
pentru a informa rețeaua că identitatea de utilizator publică
specificată (myname@mynetwork.com) este disponibilă la adresa IP
indicată în antetul Contact.
M1. UE→P-CSCF
REGISTER sip:hims.net SIP/2.0,
Via: SIP/2.0/UDP UE-IP;branch=0abab,
Route: sip:[P-CSCF-IP],
Max-Forwards: 20,
From: <sip:name@hims.net>;tag=abbb,
To: <sip:name@hims.net>,
Contact: <sip:[UE-IP]>;expires=90000,
Call-ID: ababab,
CSeq: 25 REGISTER,
Security-Client: port-s, port-c,
Authorization: Digest username =
name.private@hims.net,
Content-Length: 0
Echipamentul utilizatorului adaugă, de asemenea, un antet
Via pentru a înregistra că mesajul a traversat UE. Cererea
REGISTER include și numerele de porturi server și client. Rețineți
că mesajul însuși este trimis la portul SIP standard 5060.
Mesajul SIP REGISTER include și identitatea de utilizator
privată. Această identitate va fi folosită de S-CSCF și HSS pentru
identificarea utilizatorului.
65
UE P-CSCF I-CSCF S-CSCF HSS
M1. Register
M2. Register
Cerere autorizare utilizator
Răspuns autorizare utilizator
M3. Register
Cerere de autentificare
Răspuns de autentificare
M4. 401 Unauthorized

Stabilire IP sec.
M7. Register
M8. Register
Cerere autorizare utilizator
Răspuns autorizare utilizator
M9. Register
Cerere de atribuire server
Răspuns de atribuire server
Compară RES cu XRES

M10. 200 OK
M11. 200 OK
M12. 200 OK
Figura 4.1 Secvență de înregistrare a UE în IMS

66
P-CSCF primește mesajul REGISTER și folosește DNS
pentru a transpune domeniul hims.net în adresa IP a I-CSCF în
rețeaua gazdă.
P-CSCF adaugă un antet Via dar elimină antetul Route.
Mesajul REGISTER va fi rutat după adresa IP obținută din
răspunsul DNS. Indicatorul de protecție a integrității este setat pe
false pentru a indica că utilizatorul nu este autentificat.
M2. P-CSCF→I-CSCF
Via: SIP/2.0/UDP
pcscf1.vims.net;branch=0aab1,
Max-Forwards: 19,
Call-ID: ababab,
CSeq: 25 REGISTER,
Content-Length: 0,
name.private@hims.net integrity
protection:no
Selectarea S-CSCF. Entitatea de interogare I-CSCF solicită
de la registru HSS atribuirea unui S-CSCF.
După recepția răspunsului I-CSCF trimite cererea

REGISTER către S-CSCF respectiv.
M3. I-CSCF→S-CSCF
Via: SIP/2.0/UDP
icscf1.hims.net;branch=0aab2,
Via: SIP/2.0/UDP
67
pcscf1.vims.net;branch=0aab1,
Route: sip:scscf1.hims.net,
Max-Forwards: 18,
Call-ID: ababab,
CSeq: 25 REGISTER,
Content-Length: 0,
name.private@hims.net integrity
protection:no
La rândul său S-CSCF solicită autentificarea UE de la HSS.
În mesajul de răspuns ultimul trimite un număr aleatoriu (RAND),
jetonul de autentificare (AUTH), rezultatul așteptat (XRES), cheile
de cifrare (CK) și de integritate (IK).
La moment, utilizatorul nu este autentificat și cererea de
înregistrare este respinsă.
Terminalul este provocat să autentifice utilizatorul.
M4. S-CSCF→I-CSCF
401 Unauthorized
WWW-Authenticate: nonce=RAND-AUTN, ck,
ik,
Via: icscf1, pcscf1, ue-ip
Datele referitor la RAND, AUTN, CK și IK sunt trecute în
antetul WWW-Authenticate.
I-CSCF transmite mesajul către P-CSCF.
M5. I-CSCF→P-CSCF
401 Unauthorized
WWW-Authenticate: nonce=RAND-AUTN, ck,
ik,
Via: pcscf1, ue-ip
P-CSCF salvează cheile de cifrare și integritate. Aceste chei
vor fi necesare pentru crearea asocierii de securitate IPSec. P-CSCF
68
alocă numerele de port client (partea abonatului) și server. Aceste
numere de porturi vor fi incluse în mesajul 401 de neautorizare
trimis abonatului.
M6. P-CSCF→UE
401 Unauthorized
WWW-Authenticate: nonce=RAND-AUTN,
Security-Server: port-s, port-c
Valorile RAND și AUTN sunt trimise către abonat. Porturile
parte client și parte server sunt de asemenea incluse în mesaj.
Cheile CK și IK sunt eliminate din antet. Mesajul este trimis la UE
la portul SIP standard 5060.
În UE se verifică jetonul de autentificare (AUTN) și se
calculează valoarea RES care va fi transmisă rețelei IMS pentru
autentificarea utilizatorului.
Se stabilește asocierea de securitate IPSec pentru ambele
porturi, client și server și UE trimite din nou mesajul SIP
REGISTER către P-CSCF.
M7. UE→P-CSCF
REGISTER
Via: UE-IP;UE-Server-Port,
Route: pcscf1, pcscf-server-port,
Contact: UE-IP ue-server-port,
name.private@hims.net
response=RES
De data aceasta mesajul este protejat de IPSec și este adresat
numărului de port al serverului P-CSCF recepționat cu răspunsul
401 Unauthorized. Mesajul conține valoarea RES în antetul
Authorization (Autorizație).
M8. P-CSCF→I-CSCF
REGISTER
Via: pcscf1 UE-IP;UE-Server-Port,
name.private@hims.net response=RES
69
integrity
protection: yes,
RES
P-CSCF transmite cererea REGISTER la I-CSCF. De data
aceasta, antetul Authorization indică faptul că este activată
protecția integrității.
I-CSCF solicită atribuirea și primește de la HSS adresa unui
S-CSCF.
Mesajul SIP REGISTER este livrat în cele din urmă către S-
CSCF respectiv.
M9. I-CSCF→S-CSCF
REGISTER
Via: icscf1 pcscf1 UE-IP;UE-Server-Port,
name.private@hims.net response=RES
integrity
protection: yes,
RES
S-CSCF solicită și primește de la HSS informațiile legate de
abonat. Se compară valoarea RES recepționată de la UE cu valoarea
XRES. Dacă valorile RES și XRES s-au potrivit, S-CSCF răspunde
cu 200 OK.
M10. S-CSCF→I-CSCF
200 OK
Via: icscf1, pcscf1, UE-IP;UE-Server-Port
Mesajul de succes este transmis înapoi la P-CSCF.
M11. I-CSCF→P-CSCF
200 OK
Via: pcscf1, UE-IP;UE-Server-Port
M12. P-CSCF→UE
200 OK
Via: UE-IP;UE-Server-Port
Procedura de înregistrare a UE în IMS este acum finalizată.
70
4.2. Exemplu sesiune de apel IMS-PSTN
În acest exemplu ( figura 4.2, fragmentul 1 și 2) se analizează

procesul de stabilire a unei sesiuni de la un abonat IMS către o
terminație ISUP din PSTN. Apelul este rutat prin BGCF către
MGCF. Pentru această sesiune MGCF creează în IM-MGW un
context cu două terminații. Terminația efemeră se asociază cu un
flux RTP1, utilizat de entitatea subsistemului de rețea IMS Core, iar
terminația fizică corespunde unui canal TDM1, utilizat de partea de
rețea PSTN.
Mesajele aduse în continuare nu prezintă cereri sau
răspunsuri complete ale procesului de stabilire a sesiunii de apel
dintre terminalul UE din IMS cu un terminal din PSTN. În
secvențele prezentate lipsesc unele anteturi și parametri. Aceste
mesaje includ doar informațiile necesare pentru explicarea
procedurilor desfășurate.
Așa dar abonatul IMS inițiază un apel telefonic către un abonat
PSTN. Telefonul SIP al apelantului trimite cererea INVITE către
P-CSCF. În cerere se includ date despre codec-urile disponibile,
numărul de port RTP și adresa IP ale UE.
M1. UE → P-CSCF
INVITE
tel:<called phone number>,
caller@hims1.net,
caller supported coded list,
UE RTP Port, UE IP Address
Severul P-CSCF se asigură că cererea a fost primită prin
asociere de securitate IPSec, stabilită în timpul înregistrării UE al
abonatului. P-CSCF de origine transmite cererea INVITE la S-
CSCF pe adresa IP care a fost obținută în timpul înregistrării în
răspunsul 200 OK la cererea REGISTER.
71
P-CSCF S-CSCF BGCF MGCF IM-
UE MGW
1.INVITE
2.INVITE
3.100 Trying
4.INVITE
5.100 Trying
6.INVITE
7.Trying
8.Trying H.248
9.Add Req.
10.Add Repl.
11. 183 Session Progres
12.Add Req.
13.Add Repl.
14.ISUP IAM
15.PRAK
16.Mod Req.
17.Mod Repl.
18.200 OK (PRAK)
19.UPDATE
20. 200 OK (UPDATE)

21. ISUP COT
22.ISUP ACM
23.180 Ringing
RTP: Ring Back Tone Ring Back
24. PRACK
25. 200 OK (PRACK)
Figura 4.2. Secvență de stabilire a sesiunii IMS, frag. 1

72
M2. P-CSCF→S-CSCF
INVITE
caller@hims1.net,
caller supported coded list,
Record-Route:<Orig P-CSCF>
Serverul P-CSCF confirmă primirea cererii INVITE către
UE apelant.
M3. P-CSCF→UE
100 Trying
S-CSCF se adresează către serverul DNS pentru a traduce
tel:<called phone number> în SIP URI. Conversia de la
numărul de telefon PSTN către un SIP URI care este necesar pentru
rutare nu se reușește. Aceasta indică faptul că persoana solicitată
este abonat al rețelei cu comutație de circuite (CS). S-CSCF de
origine concluzionează că adresa de destinație se află într-o rețea
PSTN și transmite solicitarea către un BGCF local.
M4. S-CSCF→BGCF
INVITE
S-CSCF address,
<caller@hims1.net,
<caller supported coded list,
Record-Route:<Orig S-CSCF> <Orig P-CSCF>
În același timp S-CSCF confirmă primirea cererii INVITE
către P-CSCF.
M5. S-CSCF→P-CSCF
100 Trying
Pe baza unei analize suplimentare a adresei de destinație și a
configurației rețelei PSTN, entitatea de frontieră BGCF sau
selectează un MGCF local pentru a efectua terminarea, sau
transmite solicitarea către un BGCF într-o altă rețea. În cazul dat se
presupune că abonatul solicitat se află în PSTN locală. Ca rezultat
BGCF selectează un MGCF local și transmite cererea INVITE
către acesta.
73
M6. BGCF→MGCF
INVITE
S-CSCF address,
<caller@hims1.net,
<caller supported coded list,
Record-Route:<BGCF> <Orig S-CSCF>
<Orig P-CSCF>
La antetul Record-Route, nu se adaugă adresa MGCF
deoarece nu este nevoie ca ea să rămână pe calea de semnalizare
după stabilirea sesiunii. În același timp BGCF confirmă primirea
cererii INVITE către S-CSCF.
M7. BGCF→S-CSCF
100 Trying
La rândul său MGCF confirmă primirea cererii INVITE
către BGCF.
M8. MGCF→BGCF
100 Trying
MGCF selectează un IM-MGW pentru a rezerva canalul de
ieșire spre abonatul solicitat din PSTN.
Cu comanda Add a protocolului H.248 controler-ul MGCF
solicită de la gateway-ul IM-MGW crearea unui nou context.
M.9. MGCF→IM-MGW
H.248: Add Request
Context ID = ?,
Termination ID = ?,
UE Codec List,
UE RTP Port,
UE IP Address
În mesaj sunt specificate codec-urile acceptabile de UE,
adresa IP și numărul de port RTP.
IM-MGW stabilește „Lista codec-urilor comune”, incluzând
codec-urile care sunt acceptate de gateway în „Lista codec-urilor
UE” și rezervă resurse pentru conexiunea RTP. Conexiunea este
74
marcată ca unidirecțională, deoarece MGCF nu a specificat celălalt
capăt al acestei conexiuni.
Gateway-ul IM-MGW răspunde controler-ului MGCF cu un
Replay care include numărul contextului alocat, lista codec-urilor
comune, adresa IP locală și numărul portului RTP.
M10. IM-MGW→MGCF
H.248: Add Replay
Common Codecs List,
Selected local RTP Port,
Selected local IP address,
Context ID = C1,
Termination ID = RTP1
Printr-un răspuns 183 Session Progres MGCF returnează de-
a lungul căii de semnalizare datele despre capabilitățile fluxului
media ale destinației.
M11. MGCF→BGCF→S-CSCF→P-CSCF→UE
183 Session Progress
Common Codecs List,
IM-MGW RTP Port,
IM-MGW IP Address,
Record-Route: <MGCF>, <BGCF>,
<Orig S-CSCF>, <Orig P-CSCF>,
Contact: <MGCF>
În mesaj sunt incluse date referitoare la IM-MGW cum ar fi
„Lista de codec-uri comune”, adresa IP și numărul portului RTP.
În continuare, MGCF solicită de la IM-MGW alocarea unui
canal TDM către rețeaua PSTN și includerea terminației fizice
respective în contextul C1 care a fost deja configurat pentru
terminația efemeră a fluxului RTP.
M12. MGCF→IM-MGW
H.248: Add Request
Context ID = C1,
Termination ID = TDM1,
Request IM-MGW to reserve TDM circuit
75
Cererea Add a protocolului H.248 solicită de la IM-MGW
includerea canalului TDM în același Context ID=C1 unde se
află portul RTP-1, iar conexiunea respectivă se marchează ca fiind
bidirecțională.
IM-MGW răspunde către MGCF cu Replay care confirmă
alocarea terminației fizice TDM1.
M13. IM-MGW→MGCF
H.248: Add Replay
Context ID = C1,
Termination ID = TDM1
Mesajul de adresă inițială IAM (Initial Address Message),
care conține cifrele numărului de telefon apelat, este trimis de
MGCF către terminația PSTN. Informațiile despre canalul TDM-1
obținute de la IM-MGW sunt incluse în mesaj.
M14. MGCF→PSTN
ISUP IAM
tel:<called phone number>
UE selectează codecul indicat în răspunsul 183 Session
Progres și confirmă selecția codecului cu comanda PRACK către
MGCF.
M15. UE→P-CSCF→S-CSCF →MGCF
PRACK
Selected Codec
Terminalul UE inițiază activarea contextului PDP. Contextul
protocolului de date pachet PDP (Packet Data Protocol) oferă o
conexiune de pachete de date prin care UE și rețeaua pot schimba
pachete IP. După o activare a contextului PDP, UE poate trimite
pachete IP prin interfața aeriană. Contextul PDP trebuie activat
înainte de a trimite careva trafic. Activarea contextului PDP inițiată
de UE schimbă starea de gestionare a sesiunii în activă, primește
adresa IP și rezervă resursele radio.
Controler-ul MGCF cu comanda Modify a protocolului
H.248 actualizează contextul C1 în gatway-ul IM-MGW prin
indicarea tipului de codec selectat pentru sesiunea RTP.
M16. MGCF→IM-MGW
76
H.248: Modify Request
Context = C1,
Termination = RTP1,
Selected Codec
Gateway-ul trimite confirmare la comanda Modify printr-un
Replay.
M17. IM-MGW→MGCF
H.248: Modify Replay
Context = C1,
Termination = RTP1
Terminalul UE este anunțat despre codecul selectat prin
răspunsul 200 OK la comanda PRACK.
M18. MGCF →S-CSCF→P-CSCF→UE
200 OK (PRACK)
Selected Codec,
Selected UDP Port,
Selected IP Address
Deoarece activarea contextului PDP a apelantului sa încheiat,
starea sesiunii este activă, sunt rezervate resursele radio și primită
adresa IP, UE notifică partea solicitata despre aceste evenimente
prin comanda UPDATE.
M19. UE→P-CSCF→S-CSCF→MGCF
UPDATE
Partea apelată răspunde cu 200 OK.
M20. MGCF→S-CSCF→P-CSCF→UE
200 OK (UPDATE)
Prin canalul TDM selectat anterior, MGCF trimite un mesaj
de continuitate COT (Continuity Message) către rețeaua PSTN.
M21. MGCF→PSTN
ISUP COT
În rețeaua PSTN a fost alocat un canal către partea apelată.
Rețeaua PSTN trimite mesajul adresă completă ACM (Address
Complete Message) și informează MGCF că abonatul solicitat este
liber și este alertat.
M22. PSTN→MGCF
77
ISUP ACM
Cu mesajul 180 Ringing MGCF transmite către apelant
indicația de alertă a parții solicitate.
180 Ringing
Tonul de revers apel este transmis către abonatul apelant.
IM-MGW convertează tonul în flux RTP, iar UE îl convertește în
ton sonor transmis abonatului apelant.
Apelantul confirmă recepția mesajului 180 Ringing cu
mesajul PRACK transmis către MGCF.
PRACK
MGCF confirmă recepția mesajului PRACK cu răspunsul
200 OK.
200 OK (PRACK)
Când partea apelată răspunde, rețeaua PSTN terminantă
trimite mesajul de răspuns ANM (Answer Message) către MGCF.
M26. PSTN→MGCF
ISUP ANM
MGCF solicită de la PSTN o conexiune bidirecțională.
M27. MGCF→PSTN
Context ID = C1,
La care PSTN răspunde cu Replay de confirmare.
M28. PSTN→MGCF
Context ID = C1,
MGCF solicită activarea funcției de procesare vocală TDM.
M29. MGCF→PSTN
Context ID = C1,
78
P-CSCF S-CSCF BGCF MGCF IM-
UE MGW
26. ISUP ANM
H.248
27. Mod Req.
28. Mod Repl.
29. Mod Req.
30. Mod Repl.

31. 200 OK (INVITE)
32. ACK
RTP
Voice
33.BYE
34. 200 OK (BYE)

35.ISUP REL
36. Sub Req.
37. Sub Repl.
38. Sub Req.
39. Sub Repl.
40. ISUP RLC
Figura 4.2. Secvență de stabilire a sesiunii IMS, frag. 2

79
Se activează funcția de procesare vocală TDM și PSTN
răspunde MGCF cu Replay de modificare.
M30. PSTN→MGCF
Context ID = C1,
Răspunsul final, 200 OK, este trimis de MGCF pe calea de
semnalizare îndată ce abonatul a acceptat invitația la sesiune.
200 OK (INVITE)
Apelantul trimite confirmarea finală în mesajul ACK către
MGCF.
ACK
Calea vocală bidirecțională este acum stabilită. IM-MGW
convertește fluxurile RTP în voce canal TDM și vice versa, vocea
TDM în pachete RTP. Terminalul UE mapează traficul audio în
pachete RTP și invers, RTP în audio, în sens opus.
Primul închide telefonul abonatul inițiator și UE apelantă
trimite mesajul BYE către MGCF.
BYE
UE dezactivează contextul PDP media.
MGCF confirmă recepționarea mesajului BYE cu 200 OK
către apelant.
200 OK (BYE)
Prin trimiterea mesajului ISUP REL (Release Message)
entitatea MGCF inițiază eliberarea conexiunii în rețeaua PSTN.
M35. MGCF→PSTN
ISUP REL
MGCF solicită gatewui-ul IM-MGW să elibereze terminația
efemeră RTP1 și resursa respectivă.
M36. MGCF→IM-MGW
H.248:Subtract Request
80
Context ID = C1,
Gateway-ul IM-MGW confirmă lichidarea terminației RTP1
prin Replay.
M37. IM-MGW→MGCF
H.248: Subtract Replay
Context ID = C1,
În mod similar prin comanda M38 și răspunsul M39 MGCF
solicită, iar IM-MGW lichidează terminația fizică TDM1.
Rețeaua PSTN confirmă eliberarea apelului cu mesajul ISUP
RLC (Release Complete Message) transmis către MGCF.
M40. PSTN→MGCF
ISUP RLC
Cu acest mesaj se finalizează eliberarea completă a resurselor
din ambele părți, IMS și PSTN, care au fost implicate în această
sesiune.
BIBLIOGRAFIE
1. 3GPP TS 22.228 V17.0.0. "Service requirements for the

Internet Protocol (IP) Multimedia core network Subsystem (IMS)".
Stage 1, (Release 16). 2019.
2. ETSI TS 123 228 V15.4.0. "Digital cellular
telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; IP Multimedia
Subsystem (IMS); Stage 2". 2019.
3. 3GPP TS 23.003 V16.1.0. " Numbering, addressing and
identification ”. (Release 16). 2019.
4. ETSI TS 123 517 V8.0.0. "Telecommunications and Internet
converged Services and Protocols for Advanced Networking
(TISPAN); NGN Functional Architecture Release 1". 2007.
81
5. ETSI ES 282 001 V3.4.1. "Telecommunications and Internet
(TISPAN; Functional Architecture". 2009.
6. ITU-T Recommendation Y.2011. "General principles and
general reference model for next generation networks". 2004.
(TISPAN; Resource and Admission Control Sub-System (RACS):
Functional Architecture". 2009.
(TISPAN); PSTN/ISDN Emulation Sub-system (PES); Functional
architecture". 2006.
9. ETSI TS 182 027 V3.5.1. ” Telecommunications and
Internet converged Services and Protocols for Advanced
Networking (TISPAN); IPTV Architecture; IPTV functions
supported by the IMS subsystem”. 2011.
10. ITU-T Recommendation Y.2012. ”Functional requirements
and architecture of next generation networks”. 2010.
11. ETSI TS 123 002 V15.0.0. " Digital cellular
telecommunications system (Phase 2+) (GSM); Universal Mobile
Telecommunications System (UMTS); LTE; Network architecture”.
2018.
12. Nazaroi Ion. Sisteme și rețele de comunicații digitale. Partea
1. Ciclu de prelegeri. 64p. 2014.
Telecommunications System (UMTS); LTE; 3G security; Access
security for IP-based services”. 2016.
14. 3GPP TS 23.167 V16.1.0. ”IP Multimedia Subsystem
(IMS) emergency sessions.” Release 16. 2019.
15. IETF RFC 8147. Next-Generation Pan-European eCall.
2017.
82
16. ETSI TS 123 167 V15.6.0. "Universal Mobile
Telecommunications System (UMTS); LTE; IP Multimedia
Subsystem (IMS) emergency sessions”. 2020.
Telecommunications System (UMTS); LTE; Telecommunication
management; Charging management; IP Multimedia Subsystem
(IMS) charging”. 2019
18. ETSI TS 182 012 V2.1.4. "Telecommunications and Internet
(TISPAN); IMS-based PSTN/ISDN Emulation Sub-system (PES);
Functional architecture”. 2008.
19. Nazaroi Ion. Sisteme și rețele de comunicații digitale. Partea
2. Ciclu de prelegeri. 49p. 2015.
ACRONIME ȘI ABREVIERI
3GPP Third Generation Partnership Project

3GPP AAA 3GPP Authentication, Authorization, and Accounting
5GC 5G Core
5GS 5G System
ADSL Asymmetric Digital Subscriber Line
AGCF Access Gateway Control Function
AGF Access Gateway Function
A-MGF Access Media Gateway Function
AMGW Access Media Gateway
AN Access Node
API Application Program Interface
ALG Application Layer Gateway
AMF Access Management Function
ARF Access Relay Function
AS Application Server
ASF Application Server Function
ASL Application Server Layer
83
ATCF Access Transfer Control Function
ATIS Alliance for Telecommunications Industry Solutions
ATM Asynchronous Transfer Mode
AUC Authentication Centre
BD Billing Domain
BGW Border Gateway
BGCF Breakout Gateway Control Function
BGF Border Gateway Function
BICC Bearer-Independent Call Control
BICC Bearer Independent Call Control
BNG Broadband Network Gateway
BRAS Broadband Remote Access Server BS Bearer Service
BTF Basic Transport Function
CAMEL Customised Application Mobile Enhanced Logic
CAP Camel Application Part
CAPEX Capital Expenditure
CCF Charging Collection Function
CDMA Code Devision Multiple Access
CDF Charging Data Function
CDR Charging Data Record
CN Core Network
CS Circuit Switched
CSCF Call Session Control Function
CSE CAMEL Service Environment
DOCSIS® Data Over Cable Service Interface Specifications
DNS Domain Name System
DSLAM Digital Subscriber Line Access Multiplexer
xDSL x Digital Subscriber LineE-CSCF
E-CSCF Emergency - CSCF
ECS Emergency Call Server
ENUM E.164 Number Mapping
ETSI European Telecommunication Standardization
Institute
FBB Fixed Broadband
84
EPC Evolved Packet Core
E-UTRAN Evolved Universal Terrestrial Radio Access
Network
FTTx Fiber to the x
GERAN GSM EDGE Radio Access Network
GGSN Gateway GPRS Support Node
GNSS Global Navigation Satellite System
GPON Gigabit Passive Optical Network
GPRS General Packet Radio Service
GRUU Globally Routable User Agent URI
GSM Global System for Mobile Communications
GSMA Global System for Mobile Communications
Association
GUP Generic User Profile
HLR Home Location Register
HSS Home Subscriber ServerIAD Integrated Access
Device
IBCF Interconnection Border Control Function
I-CSCF Interrogating-CSCF
IETF Internet Engineering Task Force
IMEI International Mobile station Equipment Identity
IM IP Multimedia
IM CN IP Multimedia Core Network (în 3GPP)
IM-SSF IP Multimedia Service Switching Function
IMC IMS Credentials
IMS IP Multimedia Subsystem
IMS ALG IMS Application Level Gateway
IMS-GWF IMS Gateway Function
IMSI International Mobile Subscriber Identifier
IMS ICID IMS Charging Identifier
IM-MGW IP Multimedia - Media GateWay
IN Intelligent Network
IN-SCF Intelligent Network Switching Control Function
INAP IN Application Part
85
IOI Inter-Operator Identifier
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
IP-CAN IP-Connectivity Access Network
ISC IMS Service Control
ISDN Integrated Services Digital Network
ISIM IMS SIM
ISP Internet Service Provider
ISUP ISDN User Part
IVR Interactive Voice Response
IVS In-vehicle system
IWF Interworking Function
LRF Location Retrieval Function
LTE Long Term Evolution
MAP Mobile Application Part
MCC Mobile Country Code
MGCF Media Gateway Control Function
MGF Media Gateway Function
MMT Multimedia Telephony
MNC Mobile Network Code
MPS Multimedia Priority Service
MRB Media Resource Broker
MRFC Multimedia Resource Function Controller
MRFP Multimedia Resource Function Processor
MSD Minimum Set of Data
MTP Message Transfer Part
NAI Network Access Identifier
NAPT Network Address Port Translation
NAPT-PT Network Address Port Translator - Protocol
Translator
NAT Network Address Translation
NASS Network Attachment SubSystem
NGN Next Generation Network
86
NTE Network Terminating Equipment
NTECH Network Technologies
NTP Network Termination Point
OCS Online Charging System
OLT Optical Line Termination
ONT Optical Network Termination
ONU Optical Network Unit
OPEX Operational Expenditure
OSA Open Services Architecture
OSA-SCS Open Service Access-Service Capability Server
P-CSCF Proxy-CSCF
PCC Policy and Charging Control
PCEF Policy and Charging Enforcement Function
PCRF Policy and Charging Rules Function
PDF Policy Decision Function
PDN Packet Data Network
PDP Packet Data Protocol e.g., IP
PES PSTN/ISDN Emulation Subsystem
P-GRUU Public Globally Routable User Agent URI
PLMN Public Land Mobile Network
POTS Plain Old Telephone Service
PPP Point-to-Point Protocol
PS Packet Switched
PSAP Public Safety Answering Point
PSI Public Service Identity
PSTN Public Switched Telephone Network
QoS Quality of Service
RACS Resource and Admission Control Subsystem
RAB Radio Access Bearer
RCEF Resource Control Enforcement Function
RFC Request for Comments
RGW Residential Gateway
R-MGF Residential Media Gateway Function
RMGW Residential Media Gateway
87
SCCP Signalling Connection Control Part
SCP Service Control Point
SCTP Stream Control Transmission Protocol
SCS Service Capability Server
S-CSCF Serving-CSCF
SDP Session Description Protocol
SGF Signalling Gateway Function
SGW Signalling Gateway
SGSN Serving GPRS Support Node
SIGTRAN SIGnalling TRANsport
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SIP-AS SIP-Application Server
SLF Subscription Locator Function
SSF Service Switching Function
SS7 Signalling System 7
TCAP Transaction Capabilities Application Part
TDM Time Division Multiplexing
TGW Trunking GateWay
T-GRUU Temporary Globally Routable User Agent URI
THIG Topology Hiding Inter-network Gateway
TrGW Transition Gateway
TISPAN Telecommunications and Internet converged Services
and Protocols for Advanced Networking
T-MGF Trunking-Media Gateway Function
T-MGW Trunking-Media Gateway
TRF Transit and Roaming Function
UE User Equipment
UICC Universal Integrated Circuit Card
UMTS Universal Mobile Telecommunications System
UPSF User Profile Server Function
URI Uniform Resource Identifier
URL Universal Resource Locator
URN Uniform Resource Name
88
USIM UMTS SIM
UTRAN UMTS Terrestrial Radio Access Network
UUID Universally Unique Identifier
VGW Voice over IP GateWay
VoIP Voice over IP
WiMAX Worldwide Interoperability for Microwave Access
WLAN Wireless Local Area Network
CUPRINS
INTRODUCERE...........................................................................3
1. CONCEPTELE DE BAZĂ ALE IMS.................. ..................6
1.1 Definiția IMS.....................................................................6
1.2 Cerințele de nivel înalt pentru aplicațiile IMS ..................9
1.3 Identificarea utilizatorilor în IMS.....................................11
1.3.1 Identitatea de utilizator privată...........................11
1.3.2 Identitatea de utilizator publică..........................14
1.3.3 Relația dintre identitățile de utilizator private și
publice................................................................15
1.3.4 Identificarea dispozitivului utilizatorului ..........17
1.3.5 Identitatea de serviciu publică............................19
1.4. Arhitectura IMS stratificată............................................20
1.5. Arhitectura subsistemului NGN IMS..............................22
1.5.1. Planul de transport NGN IMS..............................23
1.5.2. Planul de serviciu NGN IMS................................26
2. PREZENTAREA GENERALĂ NGN IMS........................30
2.1 Funcția de control a sesiunii de apel (CSCF)................31
2.1.1 Funcția Proxy-CSCF..........................................32
2.1.2 Funcția Interogare-CSCF...................................34
2.1.3 Funcția Servire-CSCF…………………………35
2.1.4 Funcția CSCF-E de Urgență..............................37
2.2 Funcţia de control a gateway-ului de ieșire (BGCF).....41
2.3 Funcția de control interconectare la frontieră (IBCF)...43
2.4 Funcția de control a gateway-ului media (MGCF).......45
89
2.5 Funcția resurse multimedia (MRF)...............................47
2.6 Componentele comune ale platformei IMS..................49
2.6.1 Funcția UPSF....................................................49
2.6.2 Serverul HSS.....................................................49
2.6.3 Funcția SLF………..………………………….50
2.6.4 Funcția IWF…………………………………..50
2.6.5 Funcția de taxare...............................................51
2.6.6 Serverul de aplicații ........................................55
2.7 Funcția gateway-ului de frontieră (BGF)…………….57
3. SUBSISTEMUL PES...........................................................59
3.1 Arhitectura PES..............................................................59
3.2 Prezentare generală a entităților funcționale ale PES…60
4. EXEMPLE ÎNREGISTRARE ȘI CONEXIUNI ÎN IMS…..62
4.1. Înregistrarea terminalului UE în IMS.............................62
4.2. Exemplu sesiune de apel IMS-PSTN.............................68
BIBLIOGRAFIE.........................................................................79
ACRONIME ȘI ABREVIERI.....................................................81n....
90
REȚELE DEFINITE PRIN SOFTWARE
CICLU DE PRELEGERI
Chişinău
2019
3
Facultatea Electronică şi Telecomunicaţii
Departamentul Telecomunicaţii
REȚELE DEFINITE PRIN SOFTWARE
CICLU DE PRELEGERI
Chişinău
2019
4
Lucrarea de față este o continuare logică a tematicii cursului
Sisteme și rețele de comunicații digitale (SRCD) care include
tendințele actuale de dezvoltare a tehnologiilor de rețea. Cursul
de prelegeri este divizat în două compartimente. În primul
compartiment sunt descrise principiile generale și arhitectura
funcțională a Rețelei definite prin software (SDN) în
corespundere cu standardele Uniunii internaționale a
telecomunicațiilor (ITU).
În al doilea capitol se expune protocolul OpenFlow. Sunt
descrise componentele principale ale OpenFlow switch și modul
cum se procesează pachetele de date în cadrul acestui
comutator. În final sunt expuse mesajele și formatul de bază al
protocolului OpenFlow.
Obiectivul principal al acestei părți a cursului SRCD
constă în însușirea cunoștințelor de bază privind tehnologiile
viitoare și emergente în domeniul TIC.
Ca parte a cursului Sisteme și rețele de comunicații
digitale lucrarea este destinat studenţilor UTM cu profilul
Electronică şi comunicaţii, specialităţile 0714.1 Tehnologii și
sisteme de telecomunicații, 0714.2 Rețele și software de
telecomunicații, 0714.3 Comunicații radio și televiziune, 0710.1
Inginerie și management în telecomunicații, cu forma de studii la
zi şi cu frecvenţă redusă.
Redactor: E. Gheorghișteanu

U.T.M., 2004, bd. Ştefan cel Mare şi Sfânt, 168
© U.T.M., 2019
5
INTRODUCERE
Calea de evoluție a NGN către viitoarele rețele (FN) și

IMT-2020 este ghidată de posibilitățile tot mai mari de
integrare a tehnologiilor avansate de comunicații (de
exemplu SDN, NFV și CDN) cu tehnologii avansate ale
informației (de exemplu, cloud computing, tehnologii Web).
Pentru a susține această abordare, arhitectura NGN
definită în Recomandarea ITU-T Y.2012 este menținută și
actualizată de Grupurile de lucru ITU ținând cont de cele
mai recente tendințe din domeniu [1]. Evoluția arhitecturii
NGN, va include tehnologii inovatoare, în special, utilizarea
tehnologiilor SDN (software-defined networking) și
virtualizarea funcțiilor de rețea (NFV).
Creșterea numărului de servicii și aplicații, aduce la
cererea continuu de majorare a capacităților de transmisie
și de extindere a infrastructurii rețelelor. Rețelele de
telecomunicații de astăzi includ o mare varietate de
echipamente hardware. Diversitatea lor continue să
crească. Lansarea de noi servicii necesită deseori integrare
de echipamente complexe dedicate serviciului și o
proiectare costisitoare a procedurii. Lansarea noilor servicii
pe piață adesea necesită o perioadă lungă de timp. Pe de
altă parte, ciclul de viață ale echipamentelor devine tot mai
scurt pe măsura accelerării inovațiilor tehnologice și a
serviciilor.
Pe baza acestor caracteristici, Open Networking
Foundation (ONF) citează patru limitări generale ale
arhitecturilor de rețea tradiționale [2]:
Arhitectură statică și complexă. Pentru a răspunde
cerințelor servirii volumelor mari și fluctuante de trafic
multimedia cu diferite niveluri de QoS și de securitate,
tehnologia de rețea devine tot mai complexă și mai dificil de
gestionat. A crescut considerabil numărul de protocoale
utilizate în rețea, care deseori se adresează doar unei
porțiuni de cerințe de rețea. Dificilă devine adăugarea
6
nodurilor de rețea (routerelor, switchurilor). Personalul de
gestionare a rețelei trebuie să utilizeze instrumente de
gestionare la nivel de echipament pentru a modifica
parametrii de configurare ale switchurilor, routerelor,
firewall-urilor și așa mai departe. Actualizările includ
modificări ale listelor de control al accesului (ACL), setărilor
LAN virtuale, setărilor QoS în numeroase echipamente și
alte ajustări legate de protocol. Procedurile manuale trebuie
să fie utilizate pentru a configura echipamentele fiecărui
furnizor.
Politici inconsecvente. Pentru a pune în aplicare o
politică de securitate la nivel de rețea, personalul va fi
nevoit să facă schimbări de configurație la mii de
dispozitive. Într-o rețea mare, activarea a unei noi mașini
virtuale poate dura ore sau chiar zile pentru a reconfigura
ACL-urile în întreaga rețea.
Scalabilitate redusă. Cerințele față de rețele cresc
rapid, ca volum și ca varietate. Adăugarea de noduri de
rețea și majorarea capacității de transmisie implică
echipamente ale mai multor furnizori și este dificilă datorită
naturii complexe și statice a rețelei.
Dependența de furnizor. Operatorii de rețele și
prestatorii de servicii trebuie să implementeze rapid noi
capabilități și servicii ca răspuns la cerințele utilizatorilor.
Lipsa de interfețe deschise pentru funcțiile rețelei lasă
operatorii limitați de ciclurile relativ lente ale produselor
furnizorilor.
Astfel chiar și cu capacitatea sporită a sistemelor de
transmisie și cu performanțele mai mari ale elementelor de
rețea, arhitecturile tradiționale de rețea sunt din ce în ce
inadecvate în fața complexității, variabilității și volumului
ridicat al traficului impus.
7
1 REȚELE DEFINITE PRIN SOFTWARE
Rețelele definite prin software (SDN) au apărut ca o

paradigmă de rețea care poate elimina limitările
infrastructurilor de rețea actuale. Cum este conceput SDN
pentru a răspunde cerințelor de rețea în evoluție? Alianța
Open Data Center (ODCA) oferă o listă concisă a
cerințelor, care includ următoarele [3]:
Adaptabilitate. Rețelele trebuie să se adapteze și să
răspundă în mod dinamic la necesitățile aplicațiilor,
condițiile rețelei și a politicii de afaceri.
Automatizare. Schimbările de politici trebuie efectuate
automat, astfel încât munca manuală și erorile să poată fi
reduse.
Mentenabilitate. Introducerea de noi funcții și
capabilități (actualizări de software, corecții) trebuie să fie
cu întreruperi minime ale operațiunilor.
Managementul modelului. Software-ul de gestionare a
rețelei trebuie să permită gestionarea rețelei la un nivel de
model, mai degrabă decât să implementeze modificări
conceptuale prin reconfigurarea elementelor individuale ale
rețelei.
Mobilitate. Funcțiile de control trebuie să găzduiască
mobilitatea, inclusiv pentru dispozitivele utilizatorilor mobili
și serverele virtuale.
Securitate integrată. Aplicațiile de rețea trebuie să
integreze securitatea fără probleme ca serviciu de bază, în
loc ca soluție adăugată.
Scalarea la cerere. Implementările trebuie să aibă
capacitatea de a mări sau micșora rețelele și serviciile lor
pentru a sprijini solicitările apărute.
1.1 Definiția SDN
Rețelele de comunicații servesc diferite tipuri de trafic.

Varietatea aplicațiilor este în creștere continuă. Având
8
proprietăți stohastice diferite traficul cere și o abordare
diferențiată. Pentru a susține cerințe divergente
dependente de aplicație, este necesar ca rețelele să devină
mai controlabile și mai ușor de gestionat. Astfel orientare a
rețelelor pe servicii este în creștere.
Conceptul de rețea definită prin software se
caracterizează prin cinci trăsături fundamentale:
1) separarea funcțiilor,
2) centralizarea controlului,
3) simplificarea nodurilor de rețea,
4) automatizarea și virtualizarea rețelelor ,
5) utilizarea standardelor deschise.
Caracteristica fundamentală a SDN este separarea
funcțiilor de control de cele de rutare a fluxurilor de trafic.
Funcția de rutare include tabelele de expediere a
pachetelor, bazate pe adresa MAC, adresa IP, ID-ul VLAN,
etc. Pachetele care sosesc pot fi transmise spre un port de
ieșire, aruncate, consumate sau replicate. Un pachet poate
fi aruncat dacă memoria tamponului este depășită sau
datorită limitării ratei specifice QoS. În cazuri speciale
pachetul necesită prelucrare de către planul de control
(consumat) și retransmis planului resurselor. În cele din
urmă, un caz special de expediere se referă la multicast.
Atunci pachetul de intrare trebuie să fie replicat înainte de
expedierea copiilor sale diferitelor porturi de ieșire.
Astfel în SDN nodurile de rețea (routere, switchuri) sunt
simplificate și conțin doar funcțiile de comutație. Software-
ul complicat care rulează pe nod și controlează în mod
autonom sute de mii de linii este eliminat din dispozitiv și
plasat într-un controlor centralizat. Partea de control fiind
realizată pe nivel separat oferă șansa de introducere a unui
control centralizat logic și programabil al resurselor de
rețea prin intermediul interfețelor și protocoalelor
standardizate.
Resursele de rețea sunt abstractizate. Abstractizarea
oferă programatorului o vedere globală a rețelei și îl
9
eliberează de necesitatea cunoașterii rețelei compusă din
mai multe mașini. Apare posibilitatea de a virtualiza
rețeaua, de a decupla serviciul de rețea de rețeaua fizică
de bază. Deci, prin abstractizarea și programarea
resurselor de rețea, rețelele pot fi controlate într-o manieră
automată, ceea ce permite operații mai agile ale rețelelor.
O caracteristică a Open SDN este că interfețele sale
trebuie să rămână standard, bine documentate și nu de
proprietate (non-proprietary). Ca urmare, viteza cu care
tehnologia de rețea este dezvoltată este mult sporită,
deoarece o mulțime de persoane și organizații sunt
capabile să se aplice problemelor actuale ale rețelei.
Prezența acestor interfețe deschise încurajează, de
asemenea, proiectele „open source” legate de SDN. Pe
lângă facilitarea cercetării și experimentării, interfețele
deschise permit interoperabilitatea echipamentelor de la
diferiți furnizori. În mod normal, acest lucru generează un
mediu concurențial care reduce costurile consumatorilor de
echipamente de rețea. Această reducere a costurilor
echipamentelor de rețea a făcut parte din agenda SDN de
la înființarea acesteia.
Această abordare permite:
- controlul centralizat logic al rețelei, care reduce
numărul de puncte de control și de management;
- sprijinirea virtualizării rețelelor ca o caracteristică
importantă a arhitecturii rețelei;
- definirea, controlul și managementul resurselor de
rețea utilizând software;
- furnizarea serviciilor de rețea într-o manieră
deterministă, în conformitate cu comportamentul solicitat;
- personalizarea rețelei, care este necesară pentru
implementarea eficientă a rețelelor și operațiunilor.
Reieşind pe cele aduse mai sus Uniunea internaționala
a telecomunicațiilor (ITU) definește SDN astfel:
O rețea definită prin software (SDN) este un set de
tehnici care permite programarea, orchestrarea, controlul și
10
managementul direct al resurselor de rețea, care facilitează
proiectarea, livrarea și operarea serviciilor de rețea într-o
manieră dinamică și scalabilă [4].
1.2 Arhitectura SDN
Arhitectura SDN decuplează funcțiile de control a

rețelei de cele de rutare. Controlul rețelei devine direct
programabil iar infrastructura de bază abstractizată de la
aplicații și serviciile de rețea (figura 1.1).
Figura 1.1 Conceptul SDN
SDN mută controlul resurselor de rețea către un

element de rețea dedicat, numit controler SDN. Controlerul
asigură programarea, orchestrarea, controlul și
menajamentul resurselor de rețea prin software.
Resursele de rețea distribuite îndeplinesc funcțiile
rețelei, cum ar fi transportul și rutarea pachetelor de date.
Controlerul SDN utilizează o interfață standardizată
(interfața de control al resurselor) pentru gestionarea și
configurarea centralizată a resurselor rețelei.
11
Controlerul SDN oferă o vizualizare abstractă a
resurselor de rețea pentru aplicațiile SDN printr-o altă
interfață standardizată (interfața de control al aplicației).
Aplicația SDN poate personaliza și automatiza gestionarea
resurselor de rețea abstracte într-o manieră programabilă
prin intermediul acestei interfețe. Rețineți că controlerul
SDN poate furniza diferite tipuri de interfețe la aplicațiil e
SDN (mai mult abstracte sau orientate spre obiecte).
Rețeaua poate fi programată de aplicații care rulează
pe partea superioară a arhitecturii - nivelul aplicații SDN.
Arhitectura funcțională SDN stratificată este prezentată
în figura 1.2. Ea este formată din nivelul aplicațiilor SDN
(SDN-AL), nivelul de control SDN (SDN-CL) și nivelul
Figura 1.2 Structura stratificată SDN
resurselor SDN (SDN-RL). Funcțiile de management multe-

nivel (MMF) oferă capabilități de gestionare a
funcționalităților nivelurilor SDN enumerate mai sus. Ele
includ funcționalități pentru gestionarea defecțiunilor,
configurației, contabilității, performanței și securității
12
(abrevierea engleză FCAPS - fault, configuration,
accounting, performance and security). Exemple de astfel
de funcționalități sunt inventar ierea de echipamente,
actualizarea software-ului, izolarea defectelor, optimizarea
performanțelor, eficientizarea energetică și configurarea
inițială a resurselor de rețea, a controlerelor și a aplicațiilor
SDN. În mod specific, gestionarea autonomă, adică
adaptarea continuă la starea rețelei, poate fi realizată de
către nivelul de control SDN.
Arhitectura SDN descrisă trebuie să ia în considerare
factorii care sunt importanți în rețelele publice de mari
dimensiuni, spre exemplu, interacțiunea cu sistemul de
suport operațional (OSS-Operation Support System) /
sistemul de suport afaceri (BSS-Business Support System)
existent al operatorilor.
O prezentare de ansamblu a arhitecturii funcționale
SDN organizată pe nivelele este dată de figura 1.3. [5]
MMFO MMFA
Manage
Management relații externe
Orchestrare și Aplicații SDN

ment
Orchestrare și management multi-nivel
suport
nivel management SDN-AL
OSS aplicații AL
/BSS
MMFC ACI
Manage Orchestrare și Suport aplicații

ment suport
SDN-CL
nivel management Servicii nivel
control CL control
Abstractizare
resurse
MMFR RCI
Manage Suport Suport control RL
ment management
nivel RL SDN-RL
resurse Procesare Transport
date date
Figura 1.3 Arhitectură SDN funcțională

13
În continuare vor fi descrise funcționalitățile nivelurilor
aplicațiilor SDN (SDN-AL), de control SDN (SDN-CL) și
resurselor SDN (SDN-RL), precum și funcțiile de
management multe-nivel (MMF).
1.2.1 Nivelul aplicațiilor SDN (SDN-AL)
SDN-AL este alcătuit din componenta funcțională de

suport management și orchestrare a nivelului aplicațiilor
(AL-MSO) și componente funcționale aplicații SDN (figura
1.4).
MMFA
Orchestrare și Nivel
suport
management
Aplicație
... SDN ... Aplicație SDN aplicații
SDN
AL (SDN-AL)
ACI
Figura 1.4 Componente funcționale SDN-AL
Nivelul aplicațiilor interacționează cu cel de control prin

punctul de referință al interfeței de control al aplicației (ACI)
iar cu MMF prin punctul de referință MMFA.
Componenta funcțională AL-MSO orchestrează
aplicațiile SDN cu sprijinul MMF și include următoarele:
- gestionarea depozitului codurilor aplicațiilor SDN;
- gestionarea ciclului de viață al aplicațiilor SDN
(crearea, modificarea și ștergerea);
- monitorizarea performanței aplicațiilor SDN pentru a
satisface cerințele SLA;
- detectarea, izolarea și corectarea defecțiunilor
aplicațiilor SDN;
14
- securizarea (inclusiv autentificarea și gestionarea
identității) aplicațiilor SDN furnizate de operatorii de rețea.
Componenta funcțională AL-MSO oferă capabilități
pentru furnizarea resurselor care sunt utilizate pentru a rula
aplicațiile SDN, pe baza cererilor primite de la MMF.
Notă. Conform definiției ITU: Orchestrarea SDN este
un proces care supraveghează și direcționează un set de
activități și interacțiuni a rețelei definite prin software cu
scopul de a realiza anumite lucrări în mod automat [5].
Componenta funcțională a aplicației SDN
interacționează cu nivelul de control pentru ca ultimul să
adapteze automat comportamentul și proprietățile
resurselor de rețea. Pentru aceasta ea folosește
vizualizarea abstractizată a rețelei furnizate de SDN-CL
prin intermediul modelelor de date expuse prin punctul de
referință ACI. În funcție de cazurile de utilizare SDN (de
exemplu, centre de date, rețele mobile, rețele de acces)
interfețele ACI pot fi diferite.
Sub termenul "Aplicația SDN" se înțelege o aplicație
care controlează și gestionează resursele de rețea (de
exemplu, pentru rutare specifică aplicației) prin utilizarea
capabilităților furnizate prin punctul de referință ACI.
Componentă funcțională a aplicației SDN constă din
software-ul necesar pentru implementarea acestea.
1.2.2 Nivelul de control SDN (SDN-CL)
Nivelul de control, numit deseori Controlor, este

entitatea centrală a SDN. El controlează comportamentul
resurselor SDN-RL (transportul și procesarea datelor), în
urma solicitărilor primite de la aplicații și conform politicilor
MMF. SDN-CL operează cu resursele furnizate de nivelul
resurselor și expune o vedere abstractizată a acestora
pentru aplicații.
Componentele funcționale ale nivelului de control sunt
prezentate de figura 1.5.
15
MMFC ACI
Suport aplicații CL
Servicii CL
Orchestr- Servicii de bază Servicii specifice
are și
suport Nivelul
manage- Abstractizare resurse de
ment CL control
Repozitoriu Descoperire SDN
de topologie resurse (SDN-CL)
Alocare resurse Supraveghere
resurse
RCI
Figura 1.5 Componentele funcționale SDN-CL
SDN-CL interacționează cu nivelul resurselor utilizând

punctul de referință al interfeței de control al resurselor
(RCI) și cu funcțiile de management multe-nivel MMF
utilizând punctul de referință al nivelului de control MMFC.
Componenta funcțională de suport aplicații (CL-AS)
este utilizată de nivelul aplicațiilor pentru a accesa
informațiile de rețea și a solicita controlorul să efectueze
acțiuni solicitate de aplicație. Ea ascunde detalii despre
topologia rețelei subiacente (underlying), oferind o viziune
globală și abstractizată a acestei rețele. Informațiile de
rețea expuse pentru nivelul aplicațiilor sunt abstractizate în
formă de modele de date și informații. În cazul virtualizării
rețelei, componenta funcțională CL-AS poate expune un
16
subset de resurse de rețea sub controlul exclusiv al unui
controlor și unui nivel de aplicați externe.
Componenta funcțională a serviciilor CL furnizează un
set de funcții programabile de control și opțional de
management (dacă sunt delegate de MMF) care acoperă,
de exemplu, topologii de rețea fizică și virtuală,
configurarea elementelor de rețea și gestionarea expedierii
traficului. Ea include servicii de bază și servicii specifice (de
profil). Componenta serviciilor de bază legate cu funcții de
conectivitate este obligatorie în toate realizările SDN (de
exemplu, rețelele mobile, transport optic, mediul cloud sau
virtualizarea funcțiilor de rețea (NFV)). Ea include funcții
comune utilizate în toate implementările SDN, așa ca,
descoperirea și monitorizarea topologiei, monitorizarea
resurselor (nodurilor și linkurilor) sau calcularea, selectarea
și monitorizarea traseului conform unei solicitări,
actualizarea sincronă sau asincronă a regulilor de
expediere a datelor (programare flux). Serviciile
dependente de profil sunt legate de o anumită
implementare SDN sau combinare a mai multor astfel de
servicii, de exemplu, gestionarea mobilității pentru rețelele
mobile.
Componentă funcțională de abstractizare a resurselor
(CL-RA). Scopul principal al componentei CL-RA este de a
sprijini programabilitatea unificată a resurselor în SDN-RL.
Modelele de date și informații ale resurselor de rețea
furnizează o imagine abstractă și unificată asupra acestor
resurse către SDN-CL. Astfel ca dezvoltatorii de servicii sau
funcții de control să-și poată simplifica logica programelor
fără o cunoaștere detaliată a tehnologiilor din rețea.
Componenta funcțională CL-RA include, dar nu se
limitează la, următoarele elemente:
 De descoperire a resurselor independent de
tehnologie;
17
 Repozitoriu de topologie care păstrează
topologia curentă a rețelei fizice și virtuale (dacă
este creată);
 De alocare a resurselor abstractizate pentru
crearea rețelelor virtuale;
 De supraveghere a resurselor care
monitorizează defecțiunile și performanța
resurselor de pe nivelul SDN-RL.
Componenta funcțională de suport management și
orchestrare a nivelului de control (CL-MSO) oferă suportul
de management și orchestrare a componentelor funcționale
ale SDN-CL și a resurselor de rețea pe baza politicilor
oferite de MMF.
De asemenea, componenta funcțională CL-MSO:
 Obține informații de monitorizare pentru măsurarea
și înregistrarea indicatorilor-cheie de performanță (KPI) ai
fiecărui serviciu CL și cantitatea de resurse alocate unui
serviciu CL pe baza acestor indicatori de performanță;
 Ține evidența stării generale a resurselor alocate și
disponibile în SDN-CL. Comparația resurselor alocate în
SDN-CL cu indicatorii KPI ai serviciului CL poate ajuta la
identificarea blocajelor actuale sau potențiale;
 Oferă capabilități de operațiuni între diferite domenii
SDN, de exemplu, transmiterea identității și acreditărilor
corespunzătoare cu cererile adresate. Un domeniu SDN
este o colecție de entități SDN-RL sub o entitate SDN-CL;
 Anumite sarcini de management (dacă sunt delegate
de MMF) pot fi efectuate de către SDN-CL, în special
sarcini care sunt strâns legate de operațiunile de control și
pot fi optimizate în comun pentru utilizarea resurselor sau
pentru performanță.
În concluzie se accentuează că nivelul de control,
controlorul este creierul rețelei. El poate fi centralizat,
distribuit sau hibrid. În cazul centralizat, un controlor
gestionează toate resursele de rețea și păstrează o vedere
globală a întregii rețele. În timp ce nivelul de control
18
distribuit, utilizează mai multe controloare care sunt
distribuite pe întreaga rețea. Nivelul de control de tip hibrid
se bazează pe ambele concepte atât centralizat, cât și
distribuit.
Indiferent de tip controlul este logic centralizat.
Termenul ”logic” înseamnă că controlorul se comportă ca o
singură entitate, independent de posibila implementare în
formă distribuită.
Cele mai utilizate sisteme la nivelul de control SDN
sunt Open Network Operating System (ONOS) [8],
OpenDaylight (ODL) [9], Floodlight [10], OpenContrail, Ryu,
FlowVisor, BEACON, NOX și POX.
1.2.3 Nivelul resurselor SDN (SDN-RL)
Elementele rețelei fizice sau virtuale ale nivelului

resurselor realizează transportul și prelucrarea pachetelor
de date în conformitate cu deciziile controlorului.
Informațiile privind furnizarea de politici (inclusiv informațiile
despre configurația rețelei) care rezultă din deciziile luate
de SDN-CL, precum și informațiile privind resursele de
rețea sunt schimbate prin punctul de referință al RCI.
Informațiile de control sunt furnizate de SDN-CL către
SDN-RL (de exemplu, pentru configurarea unei resurse de
rețea). În sens opus SDN-RL transmite notificări
(nesolicitate) dacă este detectată o modificare a resurselor
de rețea. Comutatoarele SDN sunt noduri de rețea non-
inteligente care redirecționează fluxurile de date conform
regulilor instalate în ele de controlor. Cele mai comune
comutatoare SDN sunt switch-urile OpenFlow care
funcționează pe protocolul OpenFlow. Switch-ul OpenFlow
are tabele de fluxuri care oferă prevederi pentru
căutarea/potrivirea și apoi transmiterea pachetelor pe baza
regulilor/acțiunilor din tabelă. Descrierea mai detaliată a
protocolului OpenFlow este dată de capitolul 2.
19
Resursele de rețea includ entități virtuale sau fizice,
care susțin funcționalități de:
 expediere a datelor, cum ar fi comutatoare de
rețea cu reguli de expediere a datelor,
configurate de SDN-CL;
 calculare a rutelor, cum ar fi router-ele IP cu
capabilități de control al rutei distribuite,
personalizate de SDN-CL, ca parte a executării
dinamice a politicilor ingineriei traficului;
 procesare a datelor, cum ar fi module pentru
transcodarea media și compresie de date.
Componentele funcționale ale nivelului resurselor sunt
prezentate de figura 1.6.
RCI
Nivelul
Suport Suport control RL resurse
management SDN
RL (SDN-RL)
Procesare Transport
date date
MMFR
Figura 1.6 Componentele funcționale SDN-RL
Componenta funcțională suport control (RL-CS) oferă

modele de date sau de informații ale resurselor de rețea,
care sunt abstractizate în SDN-CL. Ea însăși poate realiza
abstractizarea resurselor în loc de SDN-CL, dacă
abstractizarea resurselor este susținută de tehnologia
utilizată.
Componenta funcțională RL-CS permite actualizarea
datelor de transport și de procesare. De exemplu, dacă se
adaugă un nou protocol sau un set nou de specificații de
20
interfață. Programabilitatea componentei funcționale RL-CS
este susținută de MMF.
Componenta funcțională transport date (RL-DT) oferă
funcționalități de expediere și de rutare a datelor.
Funcția de expediere a datelor gestionează fluxurile de
date primite pentru a le expedia pe căile de redirecționare a
datelor care au fost calculate și stabilite conform cerințelor
definite de aplicațiile SDN.
Controlul funcționalității de expediere a datelor este
asigurat de nivelul de control. Politica de rutare SDN-RL
poate fi configurată de SDN-CL conform cerințelor
aplicațiilor SDN.
Funcțiile de redirecționare a datelor și de rutare a
datelor sunt extensibile. De exemplu, extinderea
capabilităților de transport date pentru manipularea unui
nou format de cadru de date.
Componenta funcțională de procesare date (RL-DP)
furnizează funcționalități pentru examinarea și manipularea
datelor. Funcționalitățile de procesare a datelor permit
modificarea formatului sau a traficului util al pachetelor de
date și ajustarea expedierii pachetelor de date în
corespundere cu cerințele aplicațiilor SDN.
Funcționalitățile de procesare a datelor sunt
extensibile. Ca exemple pot servi extinderea capabilităților
existente de prelucrare a datelor prin încorporarea unor noi
tehnici de procesare a datelor, cum ar fi algoritmi noi de
codificare.
Componenta funcțională suport management (RL-MS)
asigură descrierea resurselor, nume furnizor, versiune
software și starea resurselor (de exemplu, încărcare CPU,
memorie RAM sau stocare utilizate). RL-MS poate include
și un agent de management care efectuează anumite
operațiuni de management locale, dacă ele sunt delegate
de către MMF.
Acest agent poate fi utilizat pentru descoperirea
resurselor dependente de tehnologie, pentru monitorizarea
21
locală programabilă a entității SND-RL (pentru a limita
volumul de date schimbate între nivelele SDN-CL și SDN-
RL) sau pentru efectuarea așa-numitului comportament
autonom [6].
Notă. O comportare autonomă (AB) este definită ca un
comportament sau acțiune declanșate de un element de
luare a deciziilor în încercarea de a realiza obiectivul
definit. Obiectivul este definit prin modul în care elementul
decizional gestionează o entitate gestionată aflată sub
controlul său (pentru detalii vezi [6]).
Componenta funcțională RL-MS oferă, de asemenea, o
gestionare a ciclului de viață al tuturor componentelor
software ale nivelului resurse, inclusiv componenta
funcțională suport control RL-CS.
1.2.4 Funcțiile de manage ment multe-nivel (MMF)
Funcțiile de management multe-nivel MMF gestionează

nivelurile SDN, adică al aplicațiilor SDN-AL, de control
SDN-CL și al resurselor SDN-RL. Interacțiunea cu aceste
nivele se efectuează folosind puncte de referință MMFA,
MMFC și MMFR.
Funcțiile MMF asigură:
1) interacțiunea cu sistemele de management ale
terților, pentru facturare, suport clienți, colectare de statistici
sau furnizarea de servicii dinamice (prin punctul de
referință MMF OSS / BSS (MMFO) din figura 1.7);
2) orchestrarea serviciilor MMF dinamic implementate
și reconfigurarea coordonată (orchestrată) a resurselor
SDN-RL;
3) inventarierea echipamentelor, izolarea defectelor,
optimizarea performanțelor, configurația inițială a nivelurilor
SDN-RL, SDN-CL și SDN-AL și securizarea comunicațiilor
(pe scurt funcțiile FCAPS – gestionarea defecțiunilor,
configurației, contabilității, performanței și securității);
22
4) managementul ciclului de viață a componentelor
software ale nivelurilor SDN;
5) eficientizare consumului de energie electrică al
resurselor virtuale și fizice utilizate pentru implementarea
tuturor nivelurilor, prin analiză și monitorizarea stării
resurselor;
6) managementul funcționalităților nivelurilor SDN.
După cum se arată în figura 1.7, MMF include
componentele funcționale: managementul nivelului de
resurse (RLM), managementul nivelului de control (CLM),
managementul nivelului aplicațiilor (ALM), orchestrarea și
managementul multe-nivel (MMO) și managementul
relațiilor externe (ERM). Liniile interne ale blocului MMF nu
reprezintă puncte de referință. Acestea arată pur și simplu
relațiile dintre componentele funcționale.
OSS/BSS
MMFO
Funcții management multi-nivel
(MMF)
Management
relații externe
(ERM)
Orchestrare
și Management MMFA Nivelul aplicațiilor SDN
management nivel aplicații (SDN-AL)
multi-nivel (ALM)
(MMO)
Management
nivel control MMFC Nivelul de control SDN
(CLM) (SDN-CL)
Management
nivel resurse MMFR Nivelul resurselor SDN
(RLM) (SDN-RL)
Figura 1.7 Structura internă și punctele de referință

MMF
23
MMF poate delega anumite operațiuni de management,
în special acelea care necesită un schimb intensiv de date
cu nivelul de control SDN-CL. Deseori se decide ca unele
acțiuni să fie efectuate direct de către SDN-CL (de exemplu
așa-numitele operațiuni de management autonom [6]).
Operațiunile delegate sunt efectuate de componentele
funcționale AL-MSO, CL-MSO și RL-MS.
În continuare sunt descrise mai detaliat componentele
funcționale ale MMF identificate mai sus (figura 1.7).
Componenta funcțională de management al nivelului
de resurse (RLM) este responsabilă de gestionarea
resurselor fizice și virtuale ale nivelului resurselor SDN-RL.
RLM realizează următoarele funcții:
1) măsoară și raportează datele privind utilizarea
resurselor (de exemplu, pentru scopuri de facturare);
2) solicită și primește indicații de management de la
MMO cu informațiile de rigoare pentru orchestrarea multe-
nivel specifică RLM;
3) autentifică, autorizează și detectează acțiunile
anormale asupra SDN-RL (opțional);
4) abstractizarea resurselor fizice și virtuale specifice
tehnologiei utilizate în informații generale independente de
tehnologie;
5) monitorizează și asigură performanța resurselor
fizice și virtuale ale SDN-RL pe baza indicatorilor de
calitate (KPI-urilor date), inclusiv gestionarea consumului
de energie al resurselor;
6) corelează relația dintre resursele virtuale și cele
fizice din SDN-RL;
7) detectează și analizează evenimentele anormale
care cauzează căderea resurselor virtuale și fizice și
generează politici de rezolvare a defecțiunilor;
8) stochează conținutul descoperit de resurse și
gestionează ciclului de viață al conținutului în repozitoriu;
24
9) colectează stările resurselor și a evenimentelor și le
analizează în scopul gestionării FCAPS;
10) descoperă și resetează (bootstrapping)
resursele fizice și virtuale în SDN-RL;
11) oferă un punct de referință MMFR care este
utilizat pentru solicitarea și primirea operațiilor de
gestionare și a informațiilor asociate din / către SDN-AL.
Componenta funcțională de management al nivelului
de control (CLM) gestionează resursele utilizate pentru
implementarea funcțiilor nivelului de control SDN-CL
(hardware, platforme software, linkuri care leagă planul de
control cu alte planuri). Asigură disponibilitatea și
scalabilitatea ridicată a managementului SDN-CL, precum
controlul traficului generat între entitățile SDN-CL și
entitățile SDN-RL sau SDN-AL.
Funcțiile CLM sunt după cum urmează:
1) solicitarea și primirea de la MMO a indicațiilor de
management al nivelului de control;
2) furnizarea de resurse de control la nivelul SDN-CL și
scalarea lor în funcție de cerere și disponibilitate;
3) definirea, stocarea și recuperarea politicilor (de
afaceri, tehnice, de securitate, confidențialitate și de
certificare) care se aplică serviciilor nivelului de control;
4) monitorizarea și asigurarea performanței resurselor
SDN-CL pe baza indicatorilor KPI;
5) autentificarea și autorizarea, dar și detectarea
atacurilor anormale față de SDN-CL (opțional);
6) detectarea evenimentelor anormale care cauzează
defecțiuni, analiza cauzelor defectării și recuperarea
efectivă a resurselor SDN-CL defecte;
7) stocarea conținutului descoperit și gestionarea
ciclului de viață al lui (creare, modificare, ștergere) în
repozitoriu;
8) colectarea stărilor și evenimentelor din resursele
SDN-CL și analiza lor pentru managementul performanței,
defecțiunilor și securității;
25
9) descoperirea și stocarea resurselor de control în
SDN-CL;
10) furnizează un punct de referință MMFC care
este utilizat pentru solicitarea și primirea operațiilor de
gestionare și a informațiilor asociate către / de la SDN-CL.
Componenta funcțională CLM poate furniza, de
asemenea, o gestionare energetică eficientă a resurselor
CL. Mecanismele utilizate de managementul resurselor RL
în domeniul energiei pot fi aplicate și în CL.
Componentă funcțională de management al nivelului
aplicațiilor (ALM) gestionează resursele SDN-AL.
Funcțiile CLM sunt după cum urmează:
1) oferă o interfață internă cu blocul de orchestrare și
management multe-nivel (MMO) pentru solicitarea și
primirea indicațiilor de management de la MMO specifice
nivelului aplicațiilor;
2) furnizarea de aplicații și resurse relevante SDN-AL;
3) măsurarea și raportarea datele privind utilizarea
resurselor SDN-AL pentru o facturare ulterioară. Datele
privind utilizarea resurselor pot fi măsurate pentru fiecare
aplicație SDN sau pentru fiecare client;
4) monitorizarea performanțelor aplicațiilor SDN pentru
a îndeplini cerințele SLA;
5) gestionarea securității aplicațiilor SDN terțe
(autentificare, autorizare);
6) detectarea, izolarea, recuperarea defecțiunilor
aplicației SDN;
7) stocarea conținuturilor descoperite și gestionarea
ciclului de viață al acestor conținuturi în repozitoriu
(crearea, modificarea și ștergerea aplicațiilor SDN);
8) colectarea evenimentelor și statutului resurselor
nivelului SDN-AL și analizarea acestora în scopul
gestionării defectelor, calității și securității;
9) descoperirea aplicațiilor aflate în execuție și a
componentelor funcționale utilizate în SDN-AL;
26
10) furnizează un punct de referință MMFA pentru
componenta funcțională AL-MSO care este utilizată pentru
solicitarea și primirea operațiilor de gestionare și a
informațiilor asociate către / de la SDN-AL.
Componenta funcțională de management al relațiilor
externe (ERM) gestionează colaborarea cu entități externe
de management. Componenta funcțională ERM joacă un
rol de interfață reprezentativă a managementului SDN față
de entitățile de management extern. Anume:
1) oferă un punct de referință MMFO către OSS / BSS
pentru solicitarea și primirea operațiilor de gestionare și a
informațiilor asociate la / de la OSS / BSS;
2) abstractizarea informațiilor de management SDN
pentru schimbul cu entitățile externe de management în
scopul de ascundere a informațiilor de gestiune inter-
domeniu;
3) gestionează cererile / răspunsurile cu entitățile
externe de management;
4) oferă schimburi externe de politică SDN între MMF și
entitățile de management extern, analize de date,
contabilitate. Asigură interacțiunea cu sisteme externe de
DevOps* pentru o dezvoltare eficientă a funcțiilor SDN;
5) oferă o interfață internă MMFO în scopul orchestrării
inter-domenii între SDN MMF și OSS / BSS.
*) DevOps este o cultură și o practică de inginerie
software care urmărește unificarea dezvoltării (Dev) și
operării (Ops) software-ului.
Componenta funcțională de orchestrare și
management multe-nivel (MMO) gestionează ciclului de
viață al aplicațiilor SDN și serviciilor de rețea și
orchestrează managementul multe-nivel al resurselor pe
întregul domeniu al operatorului SDN (de exemplu, mai
multe centre de date interconectate de o rețea de transport
WAN). MMO asigură orchestrarea furnizării și configurării
resurselor SDN-RL și coordonează operațiunile de
management între nivelurile SDN-AL, SDN-CL și SDN-RL,
27
în special relația dintre resursele virtualizate și cele fizice
ale nivelurilor SDN. De asemenea MMO interacționează cu
componentele funcționale ALM, CLM și RLM pentru
solicitarea și primirea operațiilor de management și a
informațiilor asociate pentru orchestrarea multe-nivel.
2 PROTOCOLUL OPENFLOW
Pentru a transforma conceptul de SDN în practică,

trebuie îndeplinite două cerințe:
1) Trebuie să existe o arhitectură logică comună în
toate comutatoarele, routerele și alte dispozitive de rețea
care să fie gestionate de un controler SDN.
2) Este necesar și un protocol standard, securizat între
controlerul SDN și dispozitivul de rețea.
În întâmpinarea acestor cerințe vine protocolul
OpenFlow. El este un standard deschis pentru un protocol
de comunicare între nivelul de control și nivelul resurselor
SDN. OpenFlow este și o specificație a structurii logice de
funcționare a dispozitivului de rețea.
Structura de nivel înalt pentru un switch SDN constă
din trei componente cheie - interfața cu controlorul, nivelul
de abstractizare și un sistem de procesare a pachetelor
(figura 2.1).
Interfața controlorului menține un canal securizat și
implementează protocol OpenFlow pentru comunicarea
între comutator și un controlor SDN. Această interfața
permite controlorului să controleze acțiunile efectuate de
comutator prin instalarea și actualizarea regulilor de
potrivire a pachetelor.
Nivelul de abstractizare se află între interfața
controlorului și sistemul de procesare a pachetelor. Acest
nivel oferă o vedere abstractă a sistemului de procesare a
pachetelor. El menține una sau mai multe tabele de fluxuri
pentru a stoca regulile de acțiune de potrivire a pachetelor
primite. Tabela de fluxuri conține o listă cu înregistrări de
28
flux fiecare fiind formată din câmpuri de potrivire și set de
instrucțiuni. Fiecare înregistrare de flux specifică regula
după care se identifică pachetul potrivit și acțiunile care ar
trebui efectuate la toate pachetele din flux.
Spre controlor
Protocolul OpenFlow
Interfață controlor
Tabelă de fluxuri
Nivel abstractizare
Sistem de procesare pachete
Figura 2.1 Structura generală a switch-ului

OpenFlow
Sistemul de procesare a pachetelor într-un comutator

SDN efectuează acțiunile de redirecționare și prelucrare a
pachetelor. El cuprinde un set de porturi de intrare, un set
de porturi de ieșire și o matrice de comutare pentru
interconectarea lor. Pentru fiecare pachet primit de la un
port de intrare, sistemul de procesare caută tabelele de
fluxuri din stratul de abstractizare pentru a identifica
înregistrarea fluxului potrivită acestui pachet. Instrucțiunile
stocate în înregistrarea fluxului specifică acțiunile pe care
sistemul de procesare ar trebui să le efectueze pe pachet.
Printre acțiunile tipice se numără transmiterea pachetului la
un port de ieșire sau către controlor, modificarea unei părți
a pachetului și abandonarea pachetului.
29
Planul resurselor SDN cuprinde elementele de rețea
care mai des sunt switch-uri SDN și îndeplinesc funcții de
procesare și redirecționare a pachetelor. Totuși în unele
cazuri ele efectuează mai multe funcții, cum ar fi firewall-ul,
controlul accesului și balansarea traficului.
Unele tehnologii tradiționale de comutare a pachetelor
(de exemplu, hardware-ul și software-ul pentru
implementarea matricei de comutare care transferă
pachetele de la porturile de intrare la porturile destinate de
ieșire, cu debit mare și întârziere scurtă) joacă încă un rol
crucial în comutatorul SDN, în mod special în sistemul lui
de procesare. Însă spre deosebire de comutatoarele
tradiționale care rulează protocoale de rutare pentru
expedierea pachetelor, în comutatoarele SDN funcțiile de
luare a deciziilor sunt eliminate și transferate către
controlor. Ca urmare, comutatorul SDN efectuează doar
procesarea pachetelor, respectând regulile impuse de
controlor.
Comutatoarele SDN pot fi realizate software sau
hardware. Primele utilizează software care rulează pe
servere convenționale cu CPU și sisteme de operare
standarde (de ex., Linux). Implementările bazate pe
hardware utilizează echipamente specializate, cum ar fi
memorii adresabile pentru conținut (CAM) și procesoare de
rețea. Implementările bazate pe software și hardware au
fiecare propriile lor avantaje și limitări. De acea au apărut
și comutatoare SDN combinate care sunt bazate pe
software și hardware pentru a exploata pe deplin avantajele
lor și pentru a-și depăși limitele respective. Astfel hardware
specializate sunt utilizate și în SDN pentru a realiza
comutarea de pachete de înaltă performanță.
30
2.1 Componentele principale ale OpenFlow Switch
Deși există protocoale alternative pentru interfața RCI,

OpenFlow este în prezent standardul de facto al interfeței
sudice pentru controlul comutatoarelor SDN și este
considerat unicul protocol general non-proprietar pentru
programarea comutatoarelor SDN. Ca urmare, în
continuare se expune nivelul resurselor SDN realizat pe
switch-urele OpenFlow și comunicarea acestora cu un
controlor OpenFlow.
Protocolul OpenFlow este definit în versiunile
specificației pentru comutatoarele OpenFlow, elaborate și
publicate de Open Networking Foundation (ONF) (tabelul
2.1).
Tabelul 2.1 Versiunile OpenFlow

Versiune Dată
OF 1.0 Decembrie 2009
OF 1.1 Februarie 2011
OF 1.2 Decembrie 2011
OF 1.3 Iunie 2012
OF 1.4 Octombrie 2013
Cele expuse mai departe se bazează pe specificația

OpenFlow Switch versiunea 1.5.1, ONF TS-025, publicată
la 26 martie 2015 [7]. Această specificație acoperă
componentele și funcțiile de bază ale comutatorului,
precum și protocolul OpenFlow de gestionare a switch-ului
OpenFlow de către controlorul distant.
Arhitectura unui switch generic OpenFlow este
prezentată în figura 2.2. Așa cum este definit în specificația
comutatorului OpenFlow [7], componenta principală a
comutatorului OpenFlow include:
 setul de porturi de intrare,
 setul de porturi de ieșire,
31
 conducta (pipeline) OpenFlow cu una sau mai
multe tabele de fluxuri,
 canal securizat TLS (Transport Layer Security)
pentru comunicarea cu unul sau mai multe
controloare OpenFlow (pentru o gestionare
partajată a comutatorului).
La fel ca în orice switch de pachete, funcția de bază a
unui comutator OpenFlow este de a prelua pachete de la
porturile de intrare și de a le transmite la porturile de ieșire
destinate.
Controlor Controlor
OpenFlow PDUs:
OpenFlow/TLS/TCP/IP OpenFlow Switch
Datapath
Canal Canal
OpenFlow OpenFlow Tabelă Tabelă
de grup de grup
Fluxuri pachete Canal de Control Fluxuri pachete
date: date: */IP
TCP/IP sau UDP/IP
Port
Port Tabelă Tabelă Tabelă
fluxuri fluxuri fluxuri
Port
... Port
Pipeline/Conductă
Figura 2.2 OpenFlow Switch
Porturile OpenFlow sunt interfețele de rețea pentru

trecerea pachetelor între procesarea OpenFlow și restul
rețelei. Comutatoarele OpenFlow se conectează logic între
ele prin porturile OpenFlow. OpenFlow definește trei tipuri
de porturi:
Portul fizic corespunde unei interfețe hardware a
comutatorului. De exemplu, pe un switch Ethernet, porturile
32
fizice se potrivesc cu interfețele Ethernet. În unele
implementări, comutatorul OpenFlow poate fi virtualizat. În
aceste cazuri, un port fizic OpenFlow poate reprezenta o
felie (slice) virtuală a interfeței hardware corespunzătoare a
comutatorului.
Portul logic nu corespunde direct unei interfețe
hardware a comutatorului. Porturile logice sunt abstracții de
nivel superior care pot fi definite în comutator folosind
metode non-OpenFlow (de exemplu, grupuri de agregare a
linkurilor, tuneluri, interfețe loopback). Diferența dintre
portul fizic și cel logic este că un pachet asociat unui port
logic poate avea un câmp de conductă suplimentar numit
Tunel-ID.
Portul rezervat specifică acțiuni de expediere
generice, cum ar fi trimiterea și primirea pachetelor de la
controlor, difuzarea (broadcasting) pachetelor sau
redicționare a pachetelor utilizând metode non-OpenFlow,
cum ar fi o procesare "normală" de comutație. Există mai
multe tipuri de porturi rezervate obligatorii: ALL,
CONTROLLER, TABLE, IN_PORT, ANY, UNSET, LOCAL.
De exemplu, portul CONTROLLER reprezintă canalul
OpenFlow utilizat pentru comunicarea dintre comutator și
controlor. Porturile rezervate NORMAL și FLOOD se
utilizează în mediile hibride și permit interacțiunea dintre
conducta OpenFlow și conducta hardware a comutatorului.
Comutatoarele OpenFlow-hibrid acceptă atât
funcționarea OpenFlow, cât și funcționarea normală a
comutării Ethernet. Deci un comutator-hibrid are jumătate
din porturile sale cu comutare tradițională, în timp ce
cealaltă jumătate este configurată pentru OpenFlow.
Jumătatea OpenFlow este gestionată de controler-ul
OpenFlow, iar cealaltă jumătate de către unitatea de
control locală a comutatorului. Trecerea traficului între
aceste conducte necesită utilizarea unui port rezervat
NORMAL sau FLOOD (figura 2.3).
33
Figura 2.3 Portul rezervat NORMAL într-un switch
hibrid
Caracteristica importantă a comutatorului SDN este

funcție de redirecționare simplă, fără software încorporat
pentru a lua decizii autonome. În cadrul fiecărui switch se
utilizează o serie de tabele pentru a gestiona fluxurile de
pachete. Pentru fiecare pachet primit, comutatorul
OpenFlow identifică mai întâi fluxul căruia îi aparține
pachetul și apoi execută instrucțiunile de procesare
specificate pentru acest flux. Dacă comutatorul nu găsește
reguli de potrivire pentru pachetul de date respectiv, atunci
aproximativ 200 de octeți de date sunt trimise la controlor,
care urmează să decidă ce acțiuni adecvate trebuie luate.
Controlorul modifică tabelele de fluxuri din comutator, astfel
încât atunci când pachete de date similare sosesc la
înregistrările comutatorului se utilizează regulile de potrivire
definite și datele sunt direcționate conform acțiunilor
corespunzătoare fără să trimită pachetul din nou la
controlor. Ca urmare, switch-uri și routere pot fi simplificate
datorită gestionării de către controlor logic centralizat, ce
sporește performanța și flexibilitatea rețelei.
Căutarea fluxului de potrivire a fiecărui pachet primit și
determinarea acțiunilor care ar trebui luate pentru pachet
34
reprezintă responsabilitatea principală a conductei
(pipeline) OpenFlow.
Funcțiile principale ale comutatorului OpenFlow sunt
următoarele:
Suport control. Interacționează cu nivelul de control
SDN pentru a sprijini programabilitatea prin intermediul
interfețelor de control al resurselor. Comutatorul comunică
cu controlerul și controlerul gestionează comutatorul prin
intermediul protocolului OpenFlow.
Expedierea datelor. Acceptă fluxurile de pachete
primite de la alte comutatoare sau sisteme terminale și le
redirecționează de-a lungul căilor de expediere calculate și
stabilite conform regulilor definite de aplicațiile SDN.
Aceste reguli de expediere utilizate de comutator sunt
incluse în tabelele de expediere care indică pentru anumite
categorii de pachete care ar fi următorul hop în rută. În plus
față de expedierea simplă a unui pachet, dispozitivul de
rețea poate modifica antetul pachetului înainte de
expediere sau să renunțe la pachet. Pachetele care sosesc
pot fi plasate într-o coadă de intrare, în așteptarea
procesării de către dispozitivul de rețea, iar pachetele
transmise sunt în general plasate într-o coadă de ieșire, în
așteptarea transmisiei.
Canalul OpenFlow realizează interfața care conectează
fiecare comutator la controlor. Prin această interfață,
controlorul OpenFlow configurează și gestionează
comutatorul, recepționează evenimentele de la comutator
și trimite pachetele din comutator. În mod tipic, un controlor
gestionează mai multe canale OpenFlow, fiecare la diferite
switch-uri. Un comutator OpenFlow poate suporta un canal
la un controlor sau câteva canale la diferite controloare
OpenFlow. În cazul câtorva controloare ele partajează
gestionarea comutatorului, mai des pentru creșterea
fiabilității rețelei. Un canal OpenFlow este de obicei criptat
folosind protocolul de securitate a stratului de transport
(TLS), dar poate rula direct pe TCP.
35
Specificația OpenFlow [7] definește trei tipuri de tabele
în arhitectura comutatoarelor logice:
 Tabelă de fluxuri (flow table);
 Tabelă de grup (group table);
 Tabelă de măsură (meter table).
Tabela de fluxuri compară (matches) pachetele
primite cu un anumit flux și specifică ce funcții vor fi
efectuate pe pachete. Pot exista mai multe tabele de fluxuri
care funcționează, înlănțuite, în conductă (pipeline), după
cum se explică ulterior.
În termeni generali, un flux este o secvență de pachete
care traversează o rețea și care conțin un set de valori
egale ale antetului. De exemplu, un flux ar putea consta din
toate pachetele cu aceleași adrese IP sursă și destinație
sau cu același identificator LAN (VLAN).
Tabela de fluxuri poate direcționa fluxul de pachete
către o tabelă de grup, care poate declanșa o varietate de
acțiuni.
Tabela de măsură (meter table) poate declanșa acțiuni
legate de performanța pe flux.
Mai jos se expune mai detaliat funcțiile fiecărui tip de
tabelă din cele trei menționate.
2.2 Tabela de fluxuri
Blocul de bază al arhitecturii comutatorului logic

OpenFlow este tabela de fluxuri (flow table). Fiecare pachet
care intră într-un comutator trece printr-una din mai multe
tabele de fluxuri. Fiecare tabelă de fluxuri constă dintr-un
număr de rânduri, numite înregistrări (flow entries),
alcătuite din șapte componente (figura 2.4 a), așa cum este
definit în lista care urmează.
36
Match Priority Counters Instructions Timeouts Cookie Flags
fields
a) Câmpurile de înregistrare ale tabelei de fluxuri
Ingr Egr Ethr Ethr Ethr IP IPv4 IPv4 IPv6 IPv6 TCP TCP UDP UDP
port port SA DA Type port SA DA SA Da Src Dest Src Dest
b) Câmpurile de comparare/potrivire ale tabelei de fluxuri
Figura 2.4 Formate de înregistrare ale tabelei de

fluxuri OpenFlow
 Match fields (Câmpuri de comparare/potrivire). Se

utilizează ca criteriu pentru a determina dacă un pachet
primit se potrivește cu această înregistrare.
 Priority (Prioritate). Prioritatea relativă a
înregistrărilor din tabele. Acesta este un câmp de 16 biți.
Valoarea zero corespunde celei mai mici priorități.
Înregistrarea cu prioritate mai mare în tabel va fi potrivită
înainte de cea cu o prioritate mai mică.
 Counters (Contoare). Specificația OpenFlow
definește o varietate de contoare. Contoarele sunt
menținute pentru fiecare tabelă de fluxuri, înregistrări de
fluxuri, port, rând, grup de coșuri, pentru a urmări
statisticile referitoare la fluxul care corespunde acestei
înregistrări. Contorul este actualizat când un pachet este
potrivit, selectat după anumit criteriu. Tabelul 2.1 enumeră
contoarele care trebuie să fie suportate obligatoriu de
comutatorul OpenFlow.
Tabelul 2.2 Contoarele OpenFlow obligatorii

Contor Utilizare Bit
Număr de referințe (înregistrări Pe tabelă de fluxuri 32
active)
Durata (secunde) Pe înregistrare 32
37
tabel
Pachete recepționate Pe port 64
Pachete transmise Pe port 64
Durata (secunde) Pe port 32
Pachete transmise Pe rând 64
Durata (secunde) Pe rând 32
Durata (secunde) Pe grup 32
Durata (secunde) Pe măsurare 32
Durata se referă la timpul în care înregistrarea fluxului,

portul, grupul, rândul sau măsurarea au fost instalate în
comutator și trebuie urmărite cu precizie de secundă.
 Instructions (Instrucțiuni). Pentru a fi executate
atunci când un pachet se potrivește cu această
înregistrare. Executarea instrucțiunilor poate avea drept
rezultat modificarea conținutului pachetului, actualizarea
setului de acțiuni asociat cu pachetul și ajustarea secvenței
de procesare înlănțuită în conductă (pipeline) pentru
pachet.
 Timeouts (Perioadele de expirare). Perioada
maximă de timp sau timpul de inactivitate înainte de
respingerea fluxului de către comutator. Fiecare
înregistrare de flux are un idle_timeout și un hard_timeout
asociate cu acesta. Un câmp hard_timeout mai mare ca 0
face ca înregistrarea fluxului să fie eliminată după numărul
de secunde dat, indiferent de câte pachete au fost potrivite.
Un câmp idle_timeout diferit de 0 secunde face ca
înregistrarea fluxului să fie eliminată dacă nu sa potrivit nici
un pachet în timpul dat.
 Cookie. Valoarea de date pe 64 biți, aleasă de
controlor. Poate fi utilizată de controlor pentru filtrarea
statisticilor, modificarea și ștergerea fluxului. La procesarea
pachetelor nu se utilizează.
 Flags (Steaguri). Modifică modul în care sunt
gestionate înregistrările de flux; de exemplu, fanionul
38
OFPFF_SEND_FLOW_REM declanșează fluxul de mesaje
eliminate pentru acea înregistrare de flux.
2.2.1 Câmpurile de potrivire ale tabelei de fluxuri
O înregistrare din tabela de fluxuri este identificată prin

câmpurile de potrivire și de prioritate. Câmpurile de
potrivire și de prioritate luate împreună identifică o
înregistrare unică a fluxului într-o anumită tabelă de fluxuri.
Un pachet se potrivește cu o înregistrare de flux dacă
toate câmpurile de potrivire ale înregistrării de flux
corespund antetului și câmpurilor conductei ale pachetului.
Înregistrarea fluxului cu valori ”wilcards” pentru toate
câmpurile (toate câmpurile sunt omise) cu prioritatea egală
cu 0 se numește înregistrare de flux lipsă-tabelă (table-
miss). Valoarea de tip ”wildcard” semnifică că este posibilă
orice valoare și se notează prin semnul de asterisc *.
Înregistrarea de flux lipsă-tabelă este ultima din tabelă. Ea
este ca un catch-all (prinde tot, capturează), iar acțiunile
care trebuie luate depind de modul în care este configurată
această înregistrare. Fiecare tabelă de fluxuri trebuie să
susțină o înregistrare lipsă-tabelă pentru a procesa
insuccesele tabelei.
Componenta câmpurilor de potrivire a unei înregistrări
din tabelă constă din următoarele câmpuri obligatorii (figura
2.4b):
 Port de intrare. Identificatorul portului switch-ului pe
care a sosit pachetul. Acesta poate fi un port fizic sau un
port virtual definit de switch. Obligatoriu în tabele de intrare.
 Port de ieșire. Identificatorul portului de ieșire din
setul de acțiuni. Obligatoriu la tabelele de ieșire.
 Adresele sursă și destinație Ethernet. Fiecare
înregistrare poate fi o adresă exactă, o valoare bitmascată
pentru care sunt verificați doar câțiva biți din adresă sau o
valoare de tip ”wildcard” (se potrivesc cu orice valoare).
39
 Tipul câmpului Ethernet. Indică tipul de încărcare
utilă a pachetului Ethernet.
 Port IP. IP versiunea a 4 sau a 6.
 Adrese IPv4 sau IPv6 sursă și de destinație.
Fiecare înregistrare poate fi o adresă exactă, o valoare
bitmascată, o valoare a unei măști de subrețea sau o
valoare de tip ”wildcard”.
 Porturile TCP sursă și destinație. Valoarea exactă
sau valoarea "wildcard".
 Porturile UDP sursă și destinație. Valoarea exactă
sau valoarea "wildcard".
Câmpurile de comparare menționate trebuie să fie
acceptate de orice comutator compatibil OpenFlow. Însă
pot fi și un șir de câmpuri acceptate ca opționale: porturile
sursă și destinație ale protocolului SCTP (Stream Control
Transmission Protocol); metadate (informații suplimentare
care pot fi transmise de la o tabelă la alta în timpul
procesării unui pachet); valoarea etichetei MPLS, clasa de
trafic și QoS; identificator VLAN și prioritate utilizator VLAN
(câmpurile din antetul unui LAN virtual IEEE 802.1Q, dacă
SDN suportă VLAN-uri); port fizic (utilizat pentru a desemna
portul fizic subiacent atunci când pachetul este recepționat
pe un port logic), etc.
Astfel, OpenFlow poate fi utilizat cu trafic de rețea care
implică o varietate de protocoale și servicii de rețea.
Rețineți că la nivelul MAC (de link), este acceptat numai
Ethernet. Prin urmare, OpenFlow, așa cum este definit în
prezent, nu poate controla traficul nivelului 2 pe rețelele
fără fir.
Acum se poate defini mai precis termenul de flux. Din
punctul de vedere al unui comutator individual, un flux este
o secvență de pachete care se potrivește cu o înregistrare
specifică într-o tabelă de fluxuri. Definiția este orientată pe
pachete, în sensul că aceasta este o funcție a valorilor
câmpurilor de antet ale pachetelor care constituie fluxul și
nu o funcție a căii pe care o urmăresc prin rețea. O
40
combinație de înregistrări de flux pe mai multe comutatoare
definește un flux legat de o anumită cale.
Folosind protocolul de comutare OpenFlow, controlorul
poate adăuga, actualiza și șterge înregistrările fluxului în
tabelele de fluxuri, atât reactiv (ca răspuns la pachete) cât
și proactiv.
Înregistrările fluxului sunt create reactiv atunci când
controlorul învață în mod dinamic locul dispozitivelor în
topologia rețelei și trebuie să actualizeze tabelele de fluxuri
ale acestor dispozitive pentru a construi conectivitatea
cap-la-cap. Deoarece comutatoarele OpenFlow doar
expediază traficul, toată logica de expediere trebuie mai
întâi să fie programată și apoi dictată de către controlor. De
exemplu, dacă o gazdă de pe comutatorul A solicită să
comunice cu o gazdă de pe comutatorul B, mesajul mai
întâi va fi trimis controlorului pentru a construi calea spre
această gazdă. Controlorul va consulta adresele MAC ale
switch-urilor și modul în care se conectează, programând
logica în tabelele de fluxuri ale fiecărui comutator. Mesajele
care vor urma vor fi trimise direct pe calea construită de
controlor.
Înregistrările de flux proactive sunt programate în
prealabil, înainte de sosirea traficului. Dacă este posibil ca
două dispozitive ale rețelei să comunice, controlorul poate
programa din timp înregistrări de flux corespunzătoare ca
puncte finale ale OpenFlow.
2.2.2 Componenta Instrucțiuni a tabelei de fluxuri
Componenta Instructions a înregistrării tabelei de

fluxuri constă dintr-un set de instrucțiuni care sunt
executate dacă pachetul se potrivește cu înregistrarea.
Înainte de a descrie tipurile de instrucțiuni, trebuie să
definim termenii acțiune și set de acțiuni.
Acțiune este expedierea pachetelor, modificarea
pachetelor și operațiile de procesare în tabelele de grup.
41
Un set de acțiuni este o listă de acțiuni asociate unui
pachet care sunt acumulate în timp ce pachetul este
procesat de fiecare tabelă și care sunt executate atunci
când pachetul iese din conducta de procesare.
Specificația OpenFlow include următoarele acțiuni:
 Output (Ieșire): Expedierea pachetului către portul
specificat. Portul ar putea fi un port de ieșire către un alt
switch sau portul către controler. În acest din urmă caz,
pachetul este încapsulat într-un mesaj către controlor.
 Set-Queue (setare coadă): Setează ID-ul de coadă
pentru pachet. Când pachetul este expediat către un port
utilizând acțiunea de ieșire, ID-ul de coadă determină ce
coadă atașată la acest port este utilizată pentru
programarea și expedierea pachetului. Modul de expediere
este dictat de disciplina cozii și este folosit pentru a oferi
suport parametrilor QoS de bază.
 Group (Grupa): Procesarea pachetul prin grupul
specificat.
 Push-Tag / Pop-Tag (Împinge-etichetă/ Trage-
etichetă): Push sau pop unui tag pentru pachetele VLAN
sau MPLS.
 Set-Field (setare câmp): acțiunea Set-Field este
identificată după tipul de câmp și modifică valoarea
câmpului respective din antetul pachetului.
 Change-TTL (schimbă TTL): Acțiunea ChangeTTL
modifică valorile TTL (time to live - timp pentru a trăi) din
IPv4, limita de hop-uri IPv6 sau TTL în antetul MPLS.
 Drop (cădere): Nu există acțiune explicită care să
reprezinte căderea. În schimb, pachetele ale căror seturi de
acțiuni nu au nici o acțiune Output trebui să fie aruncate.
Tipurile de instrucțiuni pot fi grupate în patru categorii:
 Direcționarea pachetului prin conductă (pipeline):
Instrucțiunea Goto-Table direcționează pachetul către o
tabelă dea lungul conductei. Instrucțiunea Meter
(măsurare) direcționează pachetul către un contor
specificat.
42
 Efectuarea acțiunii asupra pachetului: acțiunile pot fi
efectuate pe pachet atunci când sunt potrivite cu o
înregistrare de tabelă. Instrucțiunea Apply-Actions (aplicați-
acțiuni) aplică acțiunile specificate imediat, fără a schimba
setul de acțiuni asociat cu acest pachet. Această
instrucțiune poate fi utilizată pentru a modifica pachetul
dintre două tabele din conductă.
 Actualizarea setului de acțiuni: Instrucțiunea Write-
Actions îmbină acțiunile specificate în setul de acțiuni
curent pentru pachetul dat. Instrucțiunea Clear-actions
elimină toate acțiunile din setul de acțiuni.
 Actualizarea meta datelor: o valoare de metadate
poate fi asociată unui pachet. Este folosit pentru a
transporta informații de la o tabelă la următoarea.
Instrucțiunea Write-Metadata actualizează valoarea meta
datelor existentă sau creează o nouă valoare.
2.3 Tabela de grup
O tabelă de grup constă din înregistrări de grup.

Abilitatea unei înregistrări de flux a indica un grup permite
OpenFlow să prezinte metode suplimentare de
redirecționare (spre exemplu, cele selectate sau toate).
În cursul procesării în conductă, tabelă de fluxuri poate
direcționa un flux de pachete spre tabelul de grup. Tabela
de grup și acțiunile de grup permit OpenFlow să reprezinte
un set de porturi ca o singură entitate pentru expedierea
pachetelor. Pentru a reprezenta diferite abstracții de
expediere, cum ar fi multicasting-ul sau broadcasting-ul,
sunt furnizate diferite tipuri de grupuri.
Fiecare tabelă de grup constă dintr-un număr de
rânduri, numite înregistrări de grup, compuse din patru
componente (figura 2.5):
43
Group Group Counters Action
Identifier Type Buckets
Figura 2.5 Câmpurile de înregistrare ale tabelei de grup
 Group identifier ( identificator de grup). Număr întreg

de 32 biți care identifică în mod unic grupul de pe
comutatorul OpenFlow.
 Group type (tip de grup). Determină semantica
grupului.
 Counters (contoare). Se actualizează când
pachetele sunt procesate de grup.
 Action buckets (coșuri de acțiune). O listă ordonată
a coșurilor de acțiune, în care fiecare coș de acțiune
conține un set de acțiuni care trebuie executate și
parametrii asociați. Acțiunile dintr-un coș sunt întotdeauna
aplicate ca set de acțiuni.
Un coș conține de obicei acțiuni care modifică pachetul
și o acțiune de ieșire care expediază pachetul spre un port.
El poate include, de asemenea, o acțiune de grup care
invocă un alt grup dacă comutatorul acceptă înlănțuirea, în
acest caz procesarea pachetelor continuă în grupul invocat.
2.4 Tabela de măsurare
O tabela de măsurare constă din înregistrări de

măsură, care definesc măsurările pe flux. Măsurările pe
flux permit OpenFlow să implementeze limitările ratei, o
operație simplă QoS care limitează un set de fluxuri la o
lățime de bandă aleasă.
Măsurările pe flux pot, de asemenea, să permită
OpenFlow să implementeze operațiuni de politici QoS mai
complexe, cum ar fi contorizarea bazată pe DSCP
(Differentiated Services Code Point - cei șase biți mai
semnificativi ai câmpului DiffServ din IP), care poate
44
clasifica un set de pachete în mai multe categorii bazate pe
rata sa.
Meter Meter Bands Counters

Identifier
Figura 2.6 Câmpurile înregistrării ale tabelei de

măsurare
Fiecare înregistrare (figura 2.6) conține:

• identificator: un număr întreg de 32 de biți, care
identifică în mod unic contorul;
• benzile de măsurare: o listă neordonată de benzi de
măsurare, unde fiecare bandă de măsură specifică rata și
modul de procesare a pachetului;
• contoare: actualizate atunci când pachetele sunt
procesate de tabelă.
2.5 Procesarea pachetelor în conductă (pipeline)
Conducta OpenFlow a fiecărui comutator logic

OpenFlow conține una sau mai multe tabele de fluxuri,
fiecare din aceste tabele conțin multiple înregistrări de flux.
Procesarea în conducta OpenFlow definește modul în care
interacționează pachetele cu tabele de fluxuri. Un
comutator OpenFlow trebuie să aibă cel puțin o tabelă de
fluxuri de intrare, dar de regulă are mai multe tabele. Un
comutator OpenFlow cu o singură tabelă de fluxuri este
valabil, dar în acest caz procesarea în conductă este mult
simplificată. Tabelele de fluxuri dintr-o conductă OpenFlow
sunt numerotate pornind de la 0 în ordinea în care pot fi
traversate de pachete.
Procesarea în conductă se desfășoară în două etape,
procesarea de intrare și procesarea de ieșire (figura 2.7).
Separarea celor două etape este indicată de prima tabelă
45
de ieșire. Pentru fiecare pachet procesarea se începe cu
potrivirea antetului pachetului cu înregistrările de flux ale
tabelei 0. Alte tabele de fluxuri de intrare pot fi utilizate în
funcție de rezultatul de potrivire a tabelei precedente.
Dacă ca rezultat al procesării de intrare pachetul trebuie
transmis către un port de ieșire, comutatorul OpenFlow va
începe să efectueze procesarea de ieșire în contextul
acelui port de ieșire.
Pachet in
Procesare de intrare
Port Tabelă Tabelă Tabelă Executare Tabelă

intrare fluxuri fluxuri fluxuri
... set de
0 1 n
acțiuni grup
Procesare de ieșire
Tabelă Tabelă . ... Tabelă Executare Port

fluxuri fluxuri fluxuri set ieșire
e e+1 e+m acțiuni
Pachet out PPPP P Packet out
Figura 2.7 Fluxul de pachete prin conducta de

procesare
Procedura de potrivire și de executare a instrucțiunilor

într-o tabelă de fluxuri este ilustrată în figura 2.8. Dacă o
înregistrare de flux este potrivită, se execută setul de
instrucțiuni asociat acelei înregistrări. Executarea
instrucțiunilor poate transfera pachetul într-o altă tabelă de
fluxuri care are un număr mai mare de tabel (adică
prelucrarea conductei poate merge numai înainte și nu
46
înapoi). Fiecărui pachet i se asociază un set de acțiuni.
Acest set este gol în mod implicit pentru un pachet care
începe procesarea în conducta OpenFlow. În timpul
procesului, fiecare înregistrare de flux potrivită pachetulu i
poate modifica setul de acțiuni al pachetului utilizând
instrucțiunile Write Action sau Clear Action. Setul de acțiuni
este transmis între tabelele de fluxuri. Procesarea în
conductă se oprește când setul de instrucțiuni dintr-o
înregistrare de flux potrivită nu conține o instrucțiune Goto-
Table. Apoi acțiunile din setul de acțiuni al pachetului sunt
executate (pentru mai multe detalii vezi [7]).
Găsiți înregistrarea
Înregistrare flux TABELĂ de FLUXURI
flux cu cea mai înaltă
prioritate la potrivire Înregistrare flux
Aplică instrucțiunile
Potrivire
Înregistrare flux
•
•
•
Înregistrare flux
Înregistrare flux
lipsă-tabelă Clear-Action: Goto- Tabelă
Set de • set de acțiune gol Table de
acțiuni Write-Action: {table fluxuri
{set de acțiuni} -id}
• îmbinare în set de
acțiuni
Câmpuri
conductă Aplicare-acțiuni
{listă de acțiuni}:
- modifică pachetul, Executare
-actualizează câmpurile de set de
potrivire, acțiuni
Extrage
Pachet câmpurile -actualizează câmpurile
antetului c conductei,
• -dacă spre ieșire sau grup
→ clone de pachet.
Pachete de clone
Ieșire
Figura 2.8 Potrivirea și executarea instrucţiunilor în

tabela de fluxuri
47
Diagrama grafică care ilustrează procesarea pachetului
în conducta OpenFlow la transferul lui prin comutator este
prezintă de figura 2.9 [7].
În mod obișnuit sunt mai multe tabele de fluxuri.
Potrivirea începe de la prima tabelă și poate continua cu
următoarele tabele ale conductei. Pachetul trebuie să fie
întâi potrivit cu înregistrările tabelei cu numărul 0 în
ordinea descreșterii priorității lor. Pentru tabelul 0, valoarea
meta datelor și setul de acțiune este nul.
Procesarea continuă la fiecare tabelă după cum se
prezintă pe schemă (figura 2.9). Alte tabele de fluxuri de
intrare pot fi utilizate în funcție de rezultatul potrivirii
(match-ului) din tabelul 0. Dacă în rezultatul procesării de
intrare pachetul este transmis către un port de ieșire,
comutatorul OpenFlow va efectua procesarea de ieșire în
contextul acelui port de ieșire.
1. Dacă există o potrivire pentru una sau mai multe
înregistrări, alta decât înregistrarea de flux lipsă-tabelă,
rezultatul este definit ca fiind potrivit cu intrarea cu cea mai
mare prioritate. După cum sa menționat mai sus, prioritatea
este o componentă a unei înregistrări în tabel și este setată
prin OpenFlow (prioritatea este determinată de utilizator
sau de aplicație). Următorii pași pot fi apoi executați:
a. Se actualizează contoarele asociate cu această
înregistrare.
b. Se execută instrucțiunile asociate înregistrării.
Aceasta poate include actualizarea setului de acțiuni, valorii
meta datelor și efectuarea acțiunilor.
c. Pachetul este apoi trimis la următoarea tabelă de
fluxuri, la tabela de grup, la tabela de măsurare sau
direcționate spre un port de ieșire.
48
Intrare pachet
- set gol de acțiuni
- inițiere câmpuri pipeline
- start cu tabela de fluxuri 0
Actualizare contoare.
Executare set Da Executare set acțiuni:
instrucțiuni: -actualizarea
-actualizarea setului de anteturilor pachetului
Este acțiuni Goto -actualizarea
potrivire Da -actualizarea anteturilor tabela Nu câmpurilor potrivire
în tabela pachetului n? -actualizarea
n? -actualizarea câmpurilor câmpurilor pipeline
potrivire (conductă)
- actualizare câmpurilor
pipeline
Nu - dacă e necesar,
clonarea pachetului Acțiune Da
la ieșire grup?
Este
Da Nu
înregistrare
„table-
miss” ?
Nu Acțiune
Aruncare
ieșire?
pachet
Nu
Aruncare
pachet Da
Procesare intrare
Procesare ieșire
Start procesare ieșire

-stabilire set acțiuni Sunt
Da tabele
Nu
-trecere la prima tabelă ieșire
Ieșire?
Actualizare contoare.
Executare set Da
instrucțiuni: Executare set acțiuni:
-actualizarea setului de -actualizarea anteturilor
Este
Da acțiuni Goto Nu pachetului
potrivire
-actualizarea anteturilor tabela -actualizarea câmpurilor
în tabela
pachetului n? potrivire
n?
-actualizarea -actualizarea câmpurilor
câmpurilor potrivire pipeline (conductă)
Nu - actualizare câmpurilor
pipeline
- dacă e necesar,
clonarea pachetului Aruncare Acțiune
Este Nu
la ieșire pachet ieșire?
înregistrare
„table- Da
miss” ?
Da
Nu Packet out
Aruncare pachet
Figura 2.9 Diagrama grafică simplificată de procesare

a pachetelor în comutatorul OpenFlow
49
2. Dacă potrivirea este doar pe înregistrarea lipsă-
tabelă, care poate conține instrucțiuni, ca cu orice altă
înregistrare. În practică, înregistrarea lipsă-tabelă indică
una dintre cele trei acțiuni:
a. Pachetul se trimite către controlor. Acest lucru va
permite controlorului să definească un nou flux pentru
acesta și alte pachete similare sau să renunțe la pachet.
b. Pachete se redirecționează către altă tabelă de
fluxuri, următoarea în conductă.
c. Pachetul se aruncă.
3. Dacă nu există potrivire cu nici o înregistrare și nu
există înregistrarea lipsă-tabelă, pachetul este aruncat.
Procesarea în conducta de ieșire se desfășoară în
același mod ca și în cazul procesării de intrare, cu excepția
faptului că nu există o prelucrare în tabelă de grup la
capătul conductei de ieșire.
Pentru tabela finală în conductă, redirecționarea către o
altă tabelă de fluxuri nu este posibilă. Când pachetul este
în final direcționat către un port de ieșire, setul de acțiun i
acumulat este executat și pachetul este pus în așteptare
pentru ieșire.
2.6 Mesaje OpenFlow
Protocolul OpenFlow definește mesajele și formatele

lor folosite între controlor (nivelul de control) și dispozitivul
de rețea (nivelul resurselor). Protocolul OpenFlow acceptă
trei tipuri de mesaje: controler-to-switch, asincron și
simetric, fiecare cu multiple subtipuri.
2.6.1 Mesaje controler-to-switch
Mesajele de la controlor spre comutator sunt inițiate de

către controlor și utilizate pentru a gestiona direct sau
inspecta starea comutatorului. Aceste mesaje includ:
50
Features (Caracteristici) - controlorul solicită identitatea
și capacitățile de bază ale comutator ului. Această solicitare
are loc de regulă la inițierea canalului OpenFlow.
Configuration (Configurația) - setarea și interogarea
parametrilor de configurare din comutator.
Modify-State (Modică-Starea) - pentru a gestiona
starea comutatorului. A adăuga, șterge și modifica intrările
de flux / grup, a introduce / elimina coșurile de acțiuni în
tabelele OpenFlow și de a seta proprietățile porturilor.
Read-States (Citește starea) - pentru a colecta diverse
informații de la comutator, cum ar fi configurația curentă,
statisticile și capabilitățile lui.
Packet Out (Pachet transmis) - pentru a trimite
pachetele dintr-un port specificat al comutatorului. Mesajul
trebuie să conțină fie un pachet complet, fie un ID tampon
referitor la un pachet stocat în comutator. De asemenea,
mesajul trebuie să conțină o listă de acțiuni aplicabile în
ordinea în care sunt specificate (o listă goală de acțiuni
elimină pachetul).
Barrier (Barieră) - Solicitările / răspunsurile de barieră
sunt utilizate de controlor pentru a se asigura că au fost
îndeplinite subordonările mesajelor sau pentru a primi
notificări pentru operațiile finalizate.
Role-Request (Solicitare rol) - pentru a seta rolul
canalului OpenFlow sau a ID-ul său. Acest mesaj este
deosebit util atunci când comutatorul este conectat la
câteva controloare.
Asynchronous-Configuration (Configurarea
asincronă) - setarea unui filtru suplimentar pentru mesajele
asincrone pe care controlorul dorește să le primească pe
canalul OpenFlow. Se utilizează de regulă atunci când
comutatorul se conectează la mai mulți controlori și se
efectuează la stabilirea canalului OpenFlow.
51
2.6.2 Mesaje asincrone
Mesajele asincrone sunt inițiate de către comutator și

utilizat pentru a informa controlorul despre evenimentele
din rețea și schimbările de stare a comutatorului.
Principalele tipuri de mesaje asincrone sunt descrise mai
jos:
Packet-in: Transferul controlului pachetului către
controlor.
Flow-Removed (Flux eliminat): Informează controlorul
despre eliminarea unei înregistrări de flux dintr-o tabelă de
fluxuri. Mesajele Flow-Removed sunt trimise doar pentru
înregistrările de flux cu fanionul
OFPFF_SEND_FLOW_REM. Mesajul este generat ca
urmare a solicitării controlorului de ștergere a fluxului sau
la expirarea timpului rezervat pentru comutarea fluxului
(TTL), sau din alte motive.
Port-status (Stare-port): Informează controlorul despre
modificare pe un port. Comutatorul trimite mesajul de stare
port controlorului după schimbarea configurației sau
modificarea de stare a portului. De exemplu, modificată în
mod direct de utilizator sau la căderea linkului.
Role-status (Stare-rol): Informează controlorul despre
o schimbare a rolului său. Atunci când un nou controlor se
desemnează ca master (principal), comutatorul trebuie să
trimită mesaj de stare fostului controlor master.
Controller-Status (Stare-controler): Informează
controlorul despre modificarea stării unui canal OpenFlow.
Comutatorul trimite aceste mesaje tuturor controlorilor
atunci când starea canalului OpenFlow la oricare comutator
se schimbă. Acest lucru poate ajuta la procesarea erorii
dacă controlorii pierd capacitatea de a comunica între ei.
Flow-monitor (Monitor de flux): Informează controlorul
despre schimbări în tabela de fluxuri. Un controlor poate
defini un set de monitori pentru a urmări schimbările în
tabelele de fluxuri.
52
2.6.3 Mesaje simetrice
Mesajele simetrice sunt inițiate de comutator sau

controlor și sunt trimise fără solicitare. Tipurile de mesaje
simetrice utilizate sunt descrise mai jos:
Hello (Salut) - Mesajele de salut sunt schimbate între
comutator și controlor la pornirea conexiunii.
Echo (Ecou) - Mesajul de solicitare ecou poate fi
trimise de comutator sau de controlor și trebuie să se
finalizeze cu răspuns ecou. Este utilizat în principal pentru
a verifica viabilitatea unei conexiuni între controlor și
comutator și poate fi folosit pentru a măsura latența sau
lățimea de bandă.
Error (Eroare) - Mesajele de eroare sunt utilizate de
către comutator sau controlor pentru a anunța despre
careva probleme la cealaltă parte a conexiunii. Acestea
sunt utilizate mai des de către comutator pentru a indica o
defecțiune a unei solicitări inițiate de controlor.
Experimenter (Experimentator) - Mesajele
Experimenter oferă comutatoarelor un mod standard de
experimentare a funcționalităților suplimentare în spațiul de
tip OpenFlow.
2.7 Formatul de bază al protocolului OpenFlow
Miezul specificației switch OpenFlow este setul de

structuri utilizate pentru mesajele OpenFlow Switch
Protocol. Protocolul OpenFlow este implementat folosind
mesajele descrise mai sus și transmise prin canalul
OpenFlow. Fiecare tip de mesaj este descris de o structură
specifică, dar care începe cu un antet OpenFlow comun.
Structura mesajului poate include și alte structuri care pot fi
comune pentru mai multe tipuri de mesaje. Fiecare
structură definește ordinea în care informațiile sunt incluse
în mesaj și pot conține alte structuri, valori, enumerări sau
53
mascări binare (bitmasks). Toate mesajele OpenFlow sunt
trimise în format big-endian.
OpenFlow este un protocol simplu binar, prin urmare,
mesajele OpenFlow nevalide generate de implementările
OpenFlow vor genera mesaje având o lungime greșită sau
anumite câmpuri cu valori nevalide. Se recomandă
monitorizarea acestor condiții pentru a detecta
neconformitatea implementări.
Fiecare mesaj începe cu antetul OpenFlow [7]:
/* Header on all OpenFlow packets. */

struct ofp_header {
uint8_t version; /* OFP_VERSION. */
uint8_t type; /* One of the OFPT_ constants. */
uint16_t length; /* Length including this ofp_header. */
uint32_t xid; /* Transaction id associated with this packet.Replies use
the same id as was in the request to facilitate pairing. */
};
OFP_ASSERT(sizeof(struct ofp_header) == 8);
OFP VERSION - specifică versiunea protocolului de

comutare OpenFlow utilizat. Cel mai semnificativ bit din
câmpul de versiune este rezervat și trebuie să fie setat la 0.
Ceilalți 7 biți inferiori indică numărul de versiunii al
protocolului. Versiunea protocolului descrisă aici este 1.5.1
ce corespunde versiuni ofp 0x06.
Câmpul type (tipul) poate avea următoarele valori [7]:
enum ofp_type {
/* Immutable messages. */
OFPT_HELLO = 0, /* Symmetric message */
OFPT_ERROR = 1, /* Symmetric message */
OFPT_ECHO_REQUEST = 2, /* Symmetric message */
OFPT_ECHO_REPLY = 3, /* Symmetric message */
OFPT_EXPERIMENTER = 4, /* Symmetric message */
54
/* Switch configuration messages. */
OFPT_FEATURES_REQUEST = 5, /* Controller/switch message */
OFPT_FEATURES_REPLY = 6, /* Controller/switch message */
OFPT_GET_CONFIG_REQUEST = 7, /* Controller/switch message
*/
OFPT_GET_CONFIG_REPLY = 8, /* Controller/switch message */
OFPT_SET_CONFIG = 9, /* Controller/switch message */
/* Asynchronous messages. */
OFPT_PACKET_IN = 10, /* Async message */
OFPT_FLOW_REMOVED = 11, /* Async message */
OFPT_PORT_STATUS = 12, /* Async message */
/* Controller command messages. */

OFPT_PACKET_OUT = 13, /* Controller/switch message */
OFPT_FLOW_MOD = 14, /* Controller/switch message */
OFPT_GROUP_MOD = 15, /* Controller/switch message */
OFPT_PORT_MOD = 16, /* Controller/switch message */
OFPT_TABLE_MOD = 17, /* Controller/switch message */
/* Multipart messages. */
OFPT_MULTIPART_REQUEST = 18, /* Controller/switch message
*/
OFPT_MULTIPART_REPLY = 19, /* Controller/switch message */
/* Barrier messages. */
OFPT_BARRIER_REQUEST = 20, /* Controller/switch message */
OFPT_BARRIER_REPLY = 21, /* Controller/switch message */
/* Controller role change request messages. */

OFPT_ROLE_REQUEST = 24, /* Controller/switch message */
OFPT_ROLE_REPLY = 25, /* Controller/switch message */
/* Asynchronous message configuration. */

OFPT_GET_ASYNC_REQUEST = 26, /* Controller/switch
message */
55
OFPT_GET_ASYNC_REPLY = 27, /* Controller/switch message */
OFPT_SET_ASYNC = 28, /* Controller/switch message */
/* Meters and rate limiters configuration messages. */

OFPT_METER_MOD = 29, /* Controller/switch message */
/* Controller role change event messages. */

OFPT_ROLE_STATUS = 30, /* Async message */
/* Asynchronous messages. */
OFPT_TABLE_STATUS = 31, /* Async message */
/* Request forwarding by the switch. */

OFPT_REQUESTFORWARD = 32, /* Async message */
/* Bundle operations (multiple messages as a single operation). */

OFPT_BUNDLE_CONTROL = 33, /* Controller/switch message */
OFPT_BUNDLE_ADD_MESSAGE = 34, /* Controller/switch
message */
/* Controller Status async message. */

OFPT_CONTROLLER_STATUS = 35, /* Async message */
};
Câmpul length indică lungimea totală a mesajului

inclusiv și antetul, astfel nu se utilizeze nici un indiciu
suplimentar pentru a distinge cadrul.
Câmpul t xid determină identificatorul acestei tranzacții.
În capitolul 2 s-a încercat de a oferi cititorului o
înțelegere la nivel general al OpenFlow. Pentru cititorul
interesat de o înțelegere mai aprofundată a acestui
protocol, indiferent de interesul academic, nu există nici o
alternativă specificațiilor OpenFlow, în special cea citată în
acest capitol [7]. Aceste specificații sunt, totuși, foarte
detaliate și nu este ușor pentru un novice OpenFlow să le
urmeze. Credem că acest capitol va servi ca un excelent
56
punct de plecare și ghid pentru acel cititor care trebuie să
se aprofundă în specificațiile voluminoase care cuprind
versiunile OpenFlow.
Pentru aprofundarea și actualizarea cunoașterii mai
multor aspecte legate de SDN se recomandă consultarea
periodica a site-urilor [8,9,10].
BIBLIOGRAFIE
1. https://www.itu.int/en/ITU-T/studygroups/2017-
2020/13/Pages/q2.aspx.
2. Open Networking Foundation. Software-Defined
Networking: The New Norm for Networks. ONF White
Paper, April 13, 2012.
3. Open Data Center Alliance. Open Data Center
Alliance Master Usage Model:Software-Defined Networking
Rev. 2.0. White Paper. 2014.
4. Recommendation ITU-T Y.3300. Framework of
software-defined networking. 2014.
5. Recommendation ITU-T Y.3302. Functional
architecture of software-defined networking. 2017.
6. ETSI GS AFI 002 V1.1.. Autonomic network
engineering for the self-managing Future Internet (AFI);
Generic Autonomic Network Architecture. 2013.
7. ONF TS-025. OpenFlow Switch Specification,
Version 1.5.1. March 26, 2015.
https://www.opennetworking.org/images/stories/downloads/
sdn-resources/onf-specifications/openflow/openflow-switch-
v1.5.1.pdf.
8. Website: Open Networking Foundation,
http://opennetworking.org
9. Website: OpenDaylight,
https://www.opendaylight.org/
10. Website: Project Floodlight,
http://www.projectfloodlight.org/floodli ght/
57
CUPRINS
INTRODUCERE..................................................................3
1 REȚELE DEFINITE PRIN SOFTWARE
1.1 Definiția SDN...........................................................5
1.2 Arhitectura SDN........................................................5
1.2.1 Nivelul aplicațiilor SDN (SDN-AL)................8
1.2.2 Nivelul de control SDN (SDN-CL)..............12
1.2.3 Nivelul resurselor SDN (SDN-RL)..............16
1.2.4 Funcțiile de management multe-nivel .......19
2 PROTOCOLUL OPENFLOW...................................25
2.1 Componentele principale ale OpenFlow Switch..28
2.2 Tabela de fluxuri.................................................33
2.2.1 Câmpurile potrivire ale tabelei de fluxuri....36
2.2.2 Componenta Instrucțiuni a tabelei de flux..38
2.3 Tabela de grup...................................................40
2.4 Tabela de măsurare...........................................41
2.5 Procesarea pachetelor în conductă (pipeline).....42
2.6 Mesaje OpenFlow..............................................47
2.6.1 Mesajeontroler-to-switch...........................47
2.6.2 Mesaje asincrone.....................................49
2.6.3 Mesaje simetrice......................................50
2.7 Formatul de bază al protocolului OpenFlow.........50
BIBLIOGRAFIE..............................................................54
ACRONIME ȘI ABREVIERI............................................56
58
ACRONIME ȘI ABREVIERI
Acronimele și abrevierile sunt sortate după alfabet.
ACI Application Control Interface

ACL Access Control List
AL Application Layer
ALM Application Layer Management
AL-MSO Application Layer Management Support and
Orchestration
API Application Programming Interface
BSS Business Support System

CAM Content Addressable Memory
CDN Content Deliveri Network
CL Control Layer
CL-AS Control Layer Application Support
CL-MSO Control Layer Management Support and
Orchestration
CL-RA Control Layer Resource Abstraction
CLM Control Layer Management
DevOps Development Operations
DPID Datapath ID
DSCP Differentiated Services Code Point
ERM External Relationship Management
FCAPS Fault, Configuration, Accounting, Performance
and Security
FN Future Networks
IEEE Institute of Electrical and Electronics
Engineers
IMT-2020 International Mobile Telecommunications
59
ITU International Telecommunications Union
KPI Key Performance Indicator
LAN Local Area Network
MAC Media Access Control
MMF Multi-layer Management Functions
MMFA Multi-layer Management Functions Application
layer
MMFC Multi-layer Management Functions Control
layer
MMFO Multi-layer Management Functions OSS/BSS
MMFR Multi-layer Management Functions Resource
layer
MMO Multi-Layer Management Orchestration
MPLS Multiprotocol Label Switching
NFV Network Functions Virtualization
NGN Next Generation Networks
NOX Network Operative System
ODCA Open Data Center Aliance
ODL OpenDaylight
ONOS Open Network Operating System
ONF Open Networking Foundation
OSS Operations Support System
POX NOX in Python
QoS Quality of Service
RAM Random Access Memory
RCI Resource Control Interfaces
RL Resource Layer
RL-CS Resource Layer Control Support
RL-DP Resource Layer Data Processing
RL-DT Resource Layer Data Transport
RL-MS Resource Layer Management Support
RLM Resource Layer Management
SCTP Stream Control Transmission Protocol
SDN Software-Defined Networking
SDN-AL SDN Application Layer
SDN-CL SDN Control Layer
60
SDN-RL SDN Resource Layer
SLA Service Level Agreement
TCP Transmission Control Protocol
TLS Transport Layer Security
TTL Time-To-Live
UDP User Datagram Protocol
VLAN Virtual Local Area Network
WAN Wide Area Network
61

Carti Unite

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Carti Unite

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA TEHNICĂ A MOLDOVEI

SISTEME ȘI REȚELE DE COMUNICAȚII DIGITALE

Facultatea Inginerie și Management în

SISTEME ȘI REȚELE DE COMUNICAȚII DIGITALE

Autor: conf.univ., dr. Ion NAZAROI

Recenzent: conf.univ., dr. Nicolae BEJAN

Redactor: Elvira GHEORGHIȘTEANU

Bun de tipar Formatul 60x84 1/16

U.T.M., 2004, bd. Ştefan cel Mare şi Sfânt, 168

Dezvoltarea actuală a sistemelor și rețelelor de comunicaţii digitale,

1.1 Definiția NGN

Rețea de noua generație NGN (Next Generations Network) este un

1.2. Arhitectura NGN

Arhitectura NGN deseori se prezintă pe trei nivele funcționale:

Application Servers Servicii, control servicii

Softswitches Control rețea și

API - Application Programming Interface

Fig. 1.1. Arhitectura NGN.

Între aceste nivele se stabilesc interfețe standardizate, deschise.

Nivelul de transport și comutație include două subnivele: rețeaua

Fig. 1.2. Schema de structură a rețelei core și de acces

Fig. 1.3. Setul de terminale la edificiul abonatului.

Tehnologiile utilizate pentru asigurarea accesului de bandă largă sînt

Fig. 1.4. Schema de structură MGW

Controlul semnalizării de apel în NGN este efectuat de serverul de

1.2.3. Nivelul servicii, control servicii și aplicații

După cum sa menționat anterior în NGN funcțiile legate de servicii

1.3. Protocoale de semnalizare în NGN

Din figura 1.5 se poate observa și tipurile de protocoale de

La primul tip se referă protocolul de inițiere a sesiunii SIP și

2. PROTOCOLUL DE INIȚIERE A SESIUNII SIP

Protocolul de inițiere a sesiunii SIP (Session Initiation Protocol) a

2.1. Componentele funcționale ale rețelei SIP

O rețea bazată pe protocolul SIP include pînă la patru componente

2.2. Structura mesajelor SIP

Protocolul SIP este bazat pe text și utilizează setul de caractere ISO

Fig. 2.1. Mesajul SIP

 Linia-Răspuns este o linie de stare. Ea constă din versiunea

2.3. Cereri SIP

În specificația RFC 3261 sînt definite șase tipuri de cereri numite

BYE Încheie o sesiune. 3261

NOTIFY Informează un abonat cu 6665/06.2012

*) RFC 3261 a înlocuit specificația anterioară RFC 2543 din martie

2.4. Răspunsuri SIP

Linia de stare a răspunsului conține un cod (Status-Code) compus

Tabelul 2.2. Lista codurilor de răspunsuri SIP

Cod răspuns Descrierea textuală Referință

4xx Request Failure

5xx Server Failure

6xx Global Failures

*)Pentru răspunsurile la care specificația nu este indicată se

2.5. Anteturi SIP

Cîmpurile anteturilor SIP conțin informații detaliate despre cerere

field-name: field-value *(;parameter-name=parameter-value)

Tabelul 2.3 Anteturi SIP [RFC 3261]

Tabelul 2.4 Forma abreviată a anteturilor

2.6. Localizarea utilizatorilor după adresa SIP

Într-o rețea SIP destinația este determinată după identificatorul

2.7. Descrierea sesiunii în corpul mesajului

La inițierea sesiunilor VoIP, de teleconferință multimedia sau de

2.8. Exemplu de stabilire a unei sesiuni SIP

Fig. 2.2. Exemplu de stabilire a unei sesiuni SIP

M1 INVITE Alice -> atlanta.com proxy

INVITE sip:bob@biloxi.com SIP/2.0