Arhitecturi de Servicii Electronice Furnizate Prin Intermediul Retelelor de Comunicatii Mobile – Aplicatii Client

Arhitecturi de servicii electronice furnizate prin intermediul rețelelor de comunicații mobile – aplicații client

Cuprins:

Capitolul 1

Introducere

Capitolul 2

2.1.servicii Web

2.2 Arhitecturi de servicii Web

2.3 Arhitectura de tipc RPC

2.4 Descriere a protocoalelor corespunzătoare Stivei RPC

2.5 Modelul Client-Server-suport al serviciilor web

2.6 Platforme de dezvoltare pentru aplicațiile dispozitivelor mobile

Capitolul 3

Retele Mobile 3G

3.1 UMTS – Universal Mobile Telecommunications System

3.2 Modelul conceptual

3.3 Modelul structural

3.4 Arhitectura de Management al Resurselor

3.5 Arhitectura orientată pe calitatea serviciilor

3.6 Caracteristicile d acces radio ale sistemului UMTS

3.7 Arhitectura protocoalelor pe interfața radio a sistemului 3G

3.7 Arhitectura protocoalelor pe interfața radio a sistemului 3G

3.8 Comunicațiil mobile 4G

Capitolul 4

Kit-urile de dezvoltare software

4.1.Application Programming Interface(API)

4.2. kit-urile de dezvoltare PHP si PHPMyAdmin

4.3. Simulatorul NetBeans 7.1

4.4. Conectarea la Baza de date MySql

4.5. Xampp

Capitolul 5

Dezvoltarea aplicației client-server

5.1. Server:

5.2.Client:

Capitolul 6

Concluzii

Bibliografie:

Anexa 1 Codul sursa al aplicatiei

Capitolul 1

Introducere

Dezvoltarea continuă a rețelelor de comunicații și implicit a terminalelor mobile a dus la apariția de noi aplicații pentru satisfacerea nevoii tot mai mare de a transmite informații, nu doar prin voce ci și prin interconectarea sistemelor de comunicații (în principal Internetul).

Telefoanelele au fost transformate în minicalculatoare, la care transmisia de voce pare a fi doar un caz particular al transmisiei de date. Vorbim deja despre terminale multimedia care sunt capabile de transmiterea și recepționarea mesajelor text, a imaginilor, animațiilor, filmelor, totul în timp real, prin protocoale specific rețelelor de comunicații fixe (TCP/IP).

Sistemele de operare ale telefoanelor de ultimă generație au evoluat și printre ele s-a evidențiat sistemul Android, care are acum, conform statisticilor, o cotă de piață de peste 40%.

Deși nu este nouă, tehnologia J2ME este răspândită în mai bine de un miliard de dispozitive mobile, orice aplicație destinată acestor utilizatori având o probabilitate foarte mare de folosire.

Mai mult, există unelte ușor de găsit și folosit ce pot transforma o aplicație J2ME în una compatibilă pentru sistemul de operare Android, aceeași aplicație putând ‖ataca‖ cele două tehnologii foarte răspândite, simultan.

În acest proiect este prezentat, în primul capitol, sistemul de comunicații mobile 3G, arhitectura și principalele sale caracteristici, precum și axele viitoare de dezvoltare din acest domeniu. Următorul capitol conține informații despre noțiunea de serviciu web și arhitecturile principale de astfel de servicii. În Capitolul 3 sunt prezentate principalele unelte necesare construirii unei aplicații dar și uneltele folosite în dezvoltarea propriilor aplicații client-server.

Prima aplicație client oferă utilizatorilor accesul la servcii GIS, de geocodare, orientare-navigare precum și trimiterea către un server a unor date privind locații de interes.

Cea de-a doua aplicație poate fi folosită pentru crearea de hărți de acoperire 3G, furnizând către un server informații de interes privind locația geografică, Id-ul celulei, nivelul de semnal, statusul rețelei, precum și coordonatele geografice și amprenta de timp.

Prima aplicație se adresează platformelor mobile ce suportă tehnologia J2ME, a doua aplicație rulând optim pe o platformă mobilă Nokia ce suportă de asemenea aceași tehnologie.

Aplicațiile server sunt scrise în Php și rulează pe platforma open source XAMPP. Scopul lor este acela de a se interfața cu aplicațiile client mai sus amintite, creând astfel posibile noi servicii web.

Capitolul 2

2.1.Servicii Web

Un serviciu web este un serviciu pus la dispoziție utilizatorilor pe Internet.

Multitudinea de protocoale și standarde disponibile începând de la sfârșitul secolului trecut în sfera Internetului au dat posibilitatea comunicării între aplicații pe sisteme aflate la distanțe mari, cu acces la Internet. Astfel, există sisteme ce oferă servicii de informare și procesare a informațiilor care în general sunt independente de platforma hardware. Accesul la acestea se face prin servicii web. Exemple clasice de servicii web de informare sunt aflarea cursului de bursă momentan al unei acțiuni anume sau aflarea condițiilor climaterice într-un anumit punct de pe glob. Serviciile de prelucrare de informații pornesc de la cele mai banale, cum ar fi execuția de operații aritmetice asupra unor numere, și până la servicii complexe cum ar fi serviciile de autentificare.

Definiții :

● Un serviciu web este o componentă software descrisă print-un modul WSDL (Web Services Description Language) care oferă posibilitatea să fie accesată folosind protocoale de rețea standard de genul SOAP (Simple Object Access Protocol) și HTTP.

● Un serviciu web este un software care se pune la dipoziție pe Internet și care folosește un sistem de mesaje standardizat bazat pe XML. Pentru a găsi serviciul dorit și interfața publică a acestuia trebuie să existe mecanisme simple.

● Un serviciu web este o colecție de protocoale și standarde folosite pentru schimbul de date între aplicații sau sisteme. Aplicațiile software scrise în limbaje de programare diferite și care rulează pe diverse platforme pot folosi serviciile web pentru a face schimb de date pe

rețea (Internet), într-o manieră oarecum asemănătoare comunicării între procesele de pe un singur calculator. Interoperabilitatea se datorează folosirii unor standarde publice adecvate.

Figura 2.1 Serviciu web – viziune integrată [24]

Proprietăți serviciu web:

● Este independent de platforma hardware.

● Interoperabilitate – se datorează folosirii unor standarde publice adecvate.

● Este posibilă comunicarea între aplicații pe sisteme aflate la distanțe mari (cu acces la

Internet).

2.2. Arhitecturi de servicii web

În ultima vreme ideea de serviciu web a luat o amploare în rândul siturilor web, care oferă din ce în ce mai multe protocoale pentru trimiterea diverselor date către diferite tipuri și categorii de utilizatori. Simplitatea tehnologiilor folosite pentru web ( de exemplu protocolul HTTP, standardul de nume URI si protocolul XML) a dus la construirea unor altfel de servicii, arhitecturile serviciilor web împărțindu-se în două mari categorii [19]:

– arhitectura de tip RPC ( Remote Procedure Call – Big Web Services – orientate pe servicii)

– arhitectura de tip REST (REpresentational State Transfer – orientate pe resurse)

Arhitectura de tip RPC permite trimiterea și primirea mesajului într-un înveliș. Acest înveliș poate fi de mai multe tipuri : SOAP, XML-RPC și chiar HTTP. Din cauza acestui înveliș, acest stil de serviciu web este unul complex.

Arhitectura de tip REST este foarte asemănătoare cu arhitectura Web-ului.

Termenul World Wide Web, abreviat WWW, numit scurt și Web, care în engleză înseamnă „rețea mondială‖, este un sistem de documente și informații de tip hipertext legate ele între ele care pot fi accesate prin rețeaua mondială de Internet. Documentele, care rezidează în diferite locații pe diverse calculatoare server, pot fi regăsite cu ajutorul unui identificator univoc numit URI [22].

La baza funcționării webului stau 3 standarde, și anume:

● (HTTP) – Hypertext Transfer Protocol, prin care serverul web și browserul clientului comunică între ele;

● (HTML) – Hypertext Markup Language, standard de definire și prezentare a paginilor web.

● (URI) – Uniform Resource Identifier, sistem universal de identificare a resurselor din web, folosit pentru a identifica și regăsi paginile web;

Următoarele standarde sunt definite mai târziu:

● Cascading Style Sheets (CSS)

● JavaScript

● Hypertext Transfer Protocol Secure – HTTPS.

World Wide Web Consortium (cunoscut și sub denumirea de W3C), dezvoltă standardele HTML și CSS; alte standarde provin de la Internet Engineering Task Force (IETF), ECMA sau producători ca Sun Microsystems.

Programul de navigare (browserul) cheamă pagina folosindu-se de URI și HTTP, o interpretează conform formatării paginii (hipertext) și o prezintă utilizatorului pe un monitor. Unul dintre principiile webului este modelul client-server, browserul fiind aplicația client, iar serverul HTTP (serverul web) fiind aplicația server.

Pentru a putea interpreta și reda informațiile sub forma hipertextului, browserul apelează la standardul de limbaj HTML, definit încă de la începtul dezvoltării webului.

În perioada 2004-2005 webul a cunoscut un salt calitativ cu privință la aplicațiile de mare răspândire pe glob, care e cunoscut sub numele simbolic Web 2.0.

2.3. Arhitectura de tip RPC

Remote Procedure Call (Apelul Procedurilor la Distanță) este o tehnologie de comunicație inter-procese care permite unui program de pe un computer să genereze o subrutină sau unei proceduri să se execute într-un alt spațiu de adresă (de regula pe un alt computer sau pe o rețea partajată) fără ca programatorul să codeze explicit detaliile acestei interacțiuni la distanță. Practic, programatorul scrie, în principiu, același cod indiferent că subrutina este locală sau la distanță față de programul executant.

RPC este cea mai generală arhitectură de servicii web. De multe ori aceasta și protocolul SOAP este confundat cu noțiunea de serviciu web.

O arhitectură a serviciului web poate fi analizată din două puncte de vedere:

a) Din punct de vedere al rolurilor în cadrul serviciului web

Acest tip de serviciu web necesită mai multe componente de bază pentru a putea fi realizat:

● furnizorul de servicii (Service Provider): reprezintă un nod în Internet care asigură printr-o interfață accesul la un serviciu software care execută un anumit set de operații.

● consumatorul de Servicii (Service Requester): reprezintă un nod în rețea care se leagă la furnizorul de servicii, și folosește funcționalitatea oferită de acesta, construind soluția de afacere.

● registru de servicii (Service Broker) – reprezintă un software care gazduiește servicii publicate, acestea putând fi furnizate la cererea solicitantului. Registrul implementează descoperirea de servicii si funcții prin care solicitantul poate cere un anumit serviciu.

Figura 2.2 Rolurile din cadrul unui serviciu de tip RPC și interacțiunea dintre acestea [19]

Arhitectura orientată spre servicii Web de tip RPC trebuie să implementeze trei operații care definesc contractele dintre rolurile principale (furnizor, solicitant, registru):

● publicare: înregistrarea (sau promovarea) serviciului de către furnizorul serviciului în registrul de servicii;

● descoperire: operație complementară operației de conectare, deoarece serviciile publicate trebuie regăsite. Solicitantul descoperă serviciul în registrul servicii conform unor criterii de căutare specificate de solicitant. Criteriile de căutare pot fi, de exemplu, tipul serviciului, caracteristicile furnizorului, caracteristicile de calitate a serviciului etc.;

● conectare: conectează furnizorul de servicii cu solicitantul de servicii într-o relație de tip client-server.

b) O altă modalitate de a examina arhitectura serviciilor web se realizează prin studierea stivei de protocoale a serviciului. Stiva este în continuă dezvoltare dar în prezent conține patru niveluri:

● nivelul de descoperire a serviciului : acest nivel este responsabil de centralizarea serviciilor într-un registru comun și furnizează funcționalități de publicare a serviciului. Descoperirea serviciului se realizează prin : Universal Description, Discovery and Integration (UDDI).

● nivelul de descriere a serviciului : este responsabil cu descrierea interfeței publice a serviciului.

Desperații care definesc contractele dintre rolurile principale (furnizor, solicitant, registru):

● publicare: înregistrarea (sau promovarea) serviciului de către furnizorul serviciului în registrul de servicii;

● descoperire: operație complementară operației de conectare, deoarece serviciile publicate trebuie regăsite. Solicitantul descoperă serviciul în registrul servicii conform unor criterii de căutare specificate de solicitant. Criteriile de căutare pot fi, de exemplu, tipul serviciului, caracteristicile furnizorului, caracteristicile de calitate a serviciului etc.;

● conectare: conectează furnizorul de servicii cu solicitantul de servicii într-o relație de tip client-server.

b) O altă modalitate de a examina arhitectura serviciilor web se realizează prin studierea stivei de protocoale a serviciului. Stiva este în continuă dezvoltare dar în prezent conține patru niveluri:

● nivelul de descoperire a serviciului : acest nivel este responsabil de centralizarea serviciilor într-un registru comun și furnizează funcționalități de publicare a serviciului. Descoperirea serviciului se realizează prin : Universal Description, Discovery and Integration (UDDI).

● nivelul de descriere a serviciului : este responsabil cu descrierea interfeței publice a serviciului.

Descrierea serviciului este realizată prin Web Service Description Language (WSDL).

● nivelul de mesaje XML: acest nivel este responsabil de codarea mesajelor într-un format XML astfel încat mesajele să poată fi înțelese la celălalt capăt. Acest nivel este descris de protocoalele XML-RPC și SOAP.

● nivelul transport al serviciului : nivelul este responsabil de transportul mesajului dintre consumator și furnizor. În prezent acest nivel conține protocoale precum HTTP, SMTP (Simple Mail Transfer Protocol), FTP, BEEP (Blocks Extensible Exchange Protocol), etc.

Tabelul 1. Stiva serviciului web – RPC

2.4. Descriere a protocoalelor corespunzătoare Stivei RPC

HTTP

HTTP (Hypertext Transfer Protocol) este metoda cea mai des utilizată pentru accesarea informațiilor în Internet care sunt păstrate pe servere World Wide Web (WWW). Protocolul HTTP este un protocol de tip text, fiind protocolul "implicit" al WWW. Adică, dacă un URL nu conține partea de protocol, aceasta se consideră ca fiind http. HTTP presupune că pe calculatorul destinație rulează un program care înțelege protocolul. Fișierul trimis la destinație poate fi un document HTML (abreviație de la HyperText Markup Language), un fișier grafic, de sunet, animație sau video, de asemenea un program executabil pe server-ul respectiv sau și un editor de text. După clasificarea după modelul de referință OSI, protocolul HTTP este un protocol de nivel aplicație. Realizarea și evoluția sa este coordonată de către World Wide Web Consortium (W3C).

Modul de funcționare

HTTP oferă o tehnică de comunicare prin care paginile web se pot transmite de la un computer aflat la distanță spre propriul computer. Dacă se apelează un link sau o adresă de web cum ar fi http://www.example.com, atunci se cere calculatorului host să afișeze o pagină web (index.html sau altele). În prima fază numele (adresa) www.example.com este convertit de protocolul DNS într-o adresă IP. Urmează transferul prin protocolul TCP pe portul standard 80 al serverului HTTP, ca răspuns la cererea HTTP-GET. Informații suplimentare ca de ex. indicații pentru browser, limba dorită ș.a. se pot adăuga în header-ul (antetul) pachetului HTTP. În urma cererii HTTP-GET urmează din partea serverului răspunsul cu datele cerute, ca de ex.: pagini în (X)HTML, cu fișiere atașate ca imagini, fișiere de stil (CSS), scripturi (Javascript), dar pot fi și pagini generate dinamic (SSI, JSP, PHP și ASP.NET). Dacă dintr-un anumit motiv informațiile nu pot fi transmise, atunci serverul trimite înapoi un mesaj de eroare. Modul exact de desfășurare a acestei acțiuni (cerere și răspuns) este stabilit în specificațiile HTTP.

Transferul argumentelor

Deseori utilizatorul dorește să transmită informații speciale la website. Aici HTTP pune la dispozitie două posibilități:

● Transferul datelor în combinație cu o cerere pentru o resursă (HTTP-metoda "GET")

● Transferul datelor în combinație cu o cerere specială (HTTP-metoda "POST")

Datele transferate vin deseori %-codate. La metoda GET se utilizează partea de cerere Uniform Resource Identifiers (URI) cu simbolul ?. Această metodă se utilizează pentru a transfera o listă de parametri, pe care partea opusă trebuie să o ia în considerare la prelucrarea cererii.

Deseori această listă cuprinde perechi de valori separate prin semnul &, care sunt alcătuite din numele parametrului, semnul = și valoarea parametrului. Rareori se mai utilizează și semnul ; pentru separarea înregistrărilor listei.

Exemplu: la pagina de start dela Wikipedia.ro utilizatorul introduce în câmpul de căutare termenul "pisici", alege categoria "articole" și apasă butonul de căutare.

Atunci browserul trimite următoarea cerere la server:

GET /wiki/special:Search?search=pisici&go=articol HTTP/1.1 Host: ro.wikipedia.org …

Serverului Wikipedia îi sunt transmise două perechi de valori: Argument Valoare search pisici go articol

Perechile de valori se transmit sub forma:

Argument1=valoare1&Argument2=valoare2

iar cu ? se atașează pagina. Astfel serverul află că utilizatorul dorește să vadă articole despre pisici. Serverul prelucrează cererea, dar nu trimite un fișier ci redirectează browserul cu un Location-Header spre pagina dorită:

HTTP/1.0 302 Moved Temporarily Date: Fri, 13 Jan 2008 15:12:44 GMT Location: http://ro.wikipedia.org/wiki/echipamente … Browserul execută indicația și, pe baza noilor informații, emite o nouă cerere: GET /wiki/pisici HTTP/1.1 Host: ro.wikipedia.org … Serverul răspunde și oferă pagina cu articole despre echipamente:

HTTP/1.0 200 OK Date: Fri, 13 Jan 2008 15:12:48 GMT Last-Modified: Tue, 10 Jan 2008 11:18:20 GMT Content-Language: ro Content-Encoding: gzip Content-Type: text/html; charset=utf-8

.‹……..´ZKs.¹.>Û¿.ž-[¶KÃ!õ²ÌÇlô²¬¬ìuVò*ÉÖ– 3.r`Î+.F‖xÊ!ÿ ×.ý.ö´7ý―ü’t.ó"9ÔʛĮ.A.ÐÝ

Partea de date este mai lungă și de necitit din cauza compresiei gzip.

În cazul unei cereri POST variabilele nu se află în URI, ci în partea body:

POST /wiki/special:Search HTTP/1.1 Host: ro.wikipedia.org Content-Type: application/x-www-form-urlencoded Content-Length: 24

search=echipamente&go=articol

Serverul răspunde astfel : HTTP/1.0 302 Moved Temporarily Date: Fri, 13 Jan 2008 15:32:43 GMT Location: http://ro.wikipedia.org/wiki/echipamente.

Versiuni:

1. HTTP/0.9 – prima versiune realizată de Tim Berners-Lee și echipa sa. Această versiune este foarte simplă, dar cu numeroase neajunsuri, fiind repede înlocuită de alte versiuni;

2. HTTP/1.0 – versiune introdusă în 1996 prin RFC1945, a adus numeroase îmbunătățiri;

3. HTTP/1.1 – versiune de îmbunătățire și reparare a neajunsurilor versiunilor anterioare.

În prezent se utilizează două versiuni ale protocolului, HTTP/1.0 și HTTP/1.1. La versiunea HTTP/1.0 se stabilește o nouă conexiune TCP înaintea cererii, iar după transmiterea răspunsului conexiunea trebuie închisă. Astfel dacă un document HTML cuprinde 10 imagini, vor fi necesare 11 conexiuni TCP, pentru ca pagina să fie afișată complet (în browser). La versiunea 1.1 se pot emite mai multe cereri și răspunsuri pe aceeași conexiune TCP. Astfel pentru documentul HTML cu 10 imagini este necesară doar o singură conexiune TCP, astfel se scurtează semnificativ durata totală de încărcare a paginii. La aceasta se adaugă și faptul că versiunea 1.1 poate relua și continua transferuri întrerupte.

La HTTP se pierd informațiile cererilor vechi (deci este un protocol fără reținerea stării). Prin utilizarea de cooki-uri în header, se pot realiza însă aplicații care pot utiliza informații de stare (opțiunile utilizatorului din sesiunea actuală, coș de cumpărături ș.a.). Chiar și o recunoaștere a utilizatorului este astfel posibilă. În mod normal se pot citi informațiile transmise care parcurg rețeaua pe computere și rutere. Prin HTTPS transferul se poate și cripta.

Versiunea cea mai recentă se poate utiliza în chat-uri prin utilizarea MIME-tip-ului multipart/replace, care reînnoiește complet conținutul ferestrei browser-ului. Noua versiune permite pe lângă preluarea datelor, și transmiterea lor la server. Cu ajutorul metodei "PUT" web-designerii pot să-și publice paginile web pe webserver prin WebDAV, iar prin metoda "DELETE" ei pot chiar și șterge pagini de pe server.

De asemenea, HTTP/1.1 mai oferă metoda "TRACE" prin care se poate urmări calea spre webserver, și verifica dacă datele au fost corect transferate. Astfel se poate urmări calea prin diferite proxi-uri spre webserver, echivalent cu un traceroute la nivel aplicație.

Metode

Metodele disponibile sunt :

1. GET: este cea mai folosită metodă, fiind utilizată atunci când serverului i se cere o resursă.

2. HEAD: se comportă exact ca metoda GET, dar serverul returnează doar antetul resursei, ceea ce permite clientului să inspecteze antetul resursei, fără a fi nevoit să obțină și corpul resursei.

3. PUT: metoda este folosită pentru a depune documente pe server, fiind inversul metodei GET.

4. POST: a fost proiectată pentru a trimite date de intrare către server.

5. DELETE: este opusul metodei PUT.

6. TRACE: este o metodă folosită de obicei pentru diagnosticare, putând da mai multe informații despre traseul urmat de legătura HTTP, fiecare server proxy adăugându-și semnătura în antetul Via.

7. OPTIONS: este folosită pentru identificarea capacităților serverului Web, înainte de a face o cerere.

8. CONNECT: este o metodă folosită în general de serverele intermediare.

SOAP

SOAP este un protocol bazat pe XML ce realizează schimbul de informații între calculatoare, într-un mediu descentralizat, distribuit. Acronimul SOAP a derivate inițial din Simple Object Access Protocol, iar apoi din Service Oriented Architecture Protocol. Denumirea inițială a fost abandonată începând cu versiunea 1.2 când s-a considerat ca fiind derutantă.

Protocolul este alcătuit din trei componente:

● Un înveliș ce definește conținutul unui mesaj și cum se procesează acesta;

● Set de reguli pentru codificarea instanțelor definite de aplicație (tipuri de date definite);

● O convenție pentru reprezentarea apelurilor și răspunsurilor procedurilor apelate la distanță;

SOAP este independent de platformă, reprezentând astfel o cale de comunicație între diferite sisteme de operare.

Mesajele SOAP sunt codificate în documente XML (sunt documente XML), și sunt alcătuite din:

● SOAP envelope – obligatoriu

● SOAP header – opțional

● SOAP body – obligatoriu

Mesaj de tip SOAP

POST /InStock HTTP/1.1

Host: www.example.org

Content-Type: application/soap+xml; charset=utf-8

Content-Length: 299

SOAPAction: "http://www.w3.org/2003/05/soap-envelope"

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">

<soap:Header>

</soap:Header>

<soap:Body>

<m:GetStockPrice xmlns:m="http://www.example.org/stock">

<m:StockName>IBM</m:StockName>

</m:GetStockPrice>

</soap:Body>

</soap:Envelope>

2.5. Modelul Client-Server – suport al serviciilor web

Modelul client-server este o structură de aplicație distribuită în care sarcinile și volumul de muncă sunt împărțite între furnizorii de resurse sau servicii, numiți server, și solicitanții de servicii, numiți clienți. Adeseori clienții și serverele comunică printr-o rețea de calculatoare, dar pot fi și în același sistem.

Caracteristica client-server descrie relația programelor ce cooperează într-o aplicație. Componenta server furnizează un serviciu, unuia sau mai multor clienți care inițiază cereri pentru astfel de servicii. Funcții precum schimbul de emaluri, acces web sau acces la baze de date sunt realizate pe modelul client-server.Modelul client-server a devenit o idee centrală în dezvoltarea rețelelor de calculatoare.

Figura 2.3 Modelul Client-Server

Modelul client-server a devenit o idee centrală în dezvoltarea rețelelor de calculatoare și a Internetului devenind suportul principal pentru serviciile web

Avantaje

În cele mai multe cazuri, o arhitectură de tip client-server asigură rolurile și responsabilitățile unui sistem de calcul să fie împărțite la câteva calculatoare independente care se cunosc unele cu altele doar prin intermediul unei rețelei. Aceasta produce un avantaj adițional arhitecturii: o mai mare ușurință a mentenanței. De exemplu este posibilă înlocuirea, repararea, upgradarea sau chiar mutarea unui server în timp ce clienții săi rămân neafectați de această schimbare.

Datele sunt stocate pe servere, care au, în general, o mai bună securitate decât majoritatea clienților. Serverele pot controla mai bine accesul și resursele, garantând accesul doar acelor clienți care au permisiunea potrivită pentru a accesa și modifica date.

Deoarece stocarea datelor este centralizată, updateurile de date sunt mai ușor de administrat în comparație cu o arhitectură P2P. La P2P updateurile de date trebuie distribuite și aplicate fiecărui peer din rețea, consumând timp și crescând riscul de erori, deoarece pot fi mii sau milioane de peers.Multe tehnologii client-server mature sunt deja disponibile, fiind create să asigure securitatea, simplitatea interfeței utilizatorului și ușurința utilizării.

Sistemul funcționează cu o multitudine de clienți diferiți, având capabilități diferite.

Dezavantaje

Dacă numărul de cereri simultane către un server crește, acesta poate deveni supraîncărcat, fiind în contrast cu arhitectura P2P unde lărgimea de bandă este distribuită în toate nodurile rețelei. Arhitectura client-server nu are robustețea unei rețele bune P2P. La sistemul client-server, o cădere critică a serverului duce la neîndeplinirea cererilor. La rețelele P2P, resursele sunt de obicei distribuite la mai multe noduri. Chiar dacă un nod se defectează și abandonează încărcarea unui fișier, nodurile rămase au în continuare datele necesare pentru terminarea uploadului.

2.6.Platforme de dezvoltare pentru aplicatiile dispozitivelor mobile

J2ME și.NET Compact Framework(CF) sunt platforme pentru dezvoltarea de aplicații destinate clienților din dispozitive mobile inteligente, ambele fiind noi tehnologii critice pentru comerțul avansat prin dispozitivele mobile.

În comparație cu tehnologiile de tip micro-browser precum WAP și WMP sau cele enumerate mai sus, clienții inteligenți(dispozitivele mobile inteligente) ofera suport pentru interfețe mai bogate cu utilizatorul, creșterea importanței extensiilor dispozitivelor(GPS sau scannere pentru coduri de bare), suportând în același timp scheme de securitate și de integrare mai flexibile.De asemenea, clienții inteligenți reduc traficul din rețea și îmbunătațesc stabilitatea tranzacționala prin faptul că suportă spațiu de stocare mai ridicat la nivel de dispozitiv.Din punct de vedere al dezvoltatorilor de aplicații, J2ME si .NET cresc productivitatea creării de aplicații, siguranța aplicației și securitatea codului mobil.

Creat special pentru „mobile computing”, .NET CF este o versiune simplificată a Microsoft, .NET Framework, .NET CF Commons Language Rutine(CLR) execută aplicații. .NET de tip byte code, asemanător Java, iar .NET CF conține un subset al bibliotecilor .NET standard, biblioteci necesare dezvoltării aplicațiilor mobile. .NET CF poate fi rulat pe dispozitivele mobile care suporta Windows CE/PocketPC.

J2ME conține o cofiguarție și un profil standardizat, creat pentru a oferi cel mai bun compromis între portabilitate si performanță, din punct de vedere al dispozitivelor mobile.Fiecare combinație validă de configurații(care suporta API-urile de baza ale Java) și profile(construite deasupra configurațiilor, pentru a suporta facilități specifice dispozitivelor mobile, precum accesul la rețea și interfața cu utilizatorul) are ca țintă un tip specific de dispozitive:

►profilele create peste Connected Device Configuration(CDC) au ca tinta dispozitivele de tip hi-end.Aceste dispozitive au capacitati hardware similare celor necesare pentru .NET CF.CDC cuprinde o masina virtuala Java 2 standard, astfel incat poate fi utilizat byte code-ul standard al Java 2 Platform, Standard Edition(J2SE).

►profilele create peste Connected Limited Devices Configuration(CLCD) au ca tinta PDA-urile low-end si telefoanele celulare mici(cu volum mic) si utilizeaza o mica masina virtuala care nu este compatibila cu J2SE sau CDC.Tabelul de mai jos face o comparatie intre cele 3 tipuri de platforme de dezvoltare generice metionate:

Tabelul 2: Comparatie intre .NET si J2ME[]

.NET suporta numai un singur sistem de operare si anume Windows.Se poate argumenta si faptul ca .NET este multi-platforma intr-un anumit grad din cauza CLR:sisteme de operare Windows CE si PocketPC ruleaza pe mai mult de 200 de tipuri de dispozitive diferite, iar byte-code-ul este portabil direct (doar) intre aceste dispozitive.

Cu toate acestea, dispozitivele Windows ocupa doar un mic procent din piata totala de dispozitive mobile.Pe telefoanele mobile partea cea mai mare a pietei este detinuta de platformele Motorola iDEN, Nokia Symbian OS si Qualcomm Brew, existandde asemenea platforme specifice diversilor producatori.Pe PDA-urile low-end, jucatorul cel mai important din piata este Palm OS; pe dispozitivele de tip embedded sau telematic sunt utilizate sisteme de operare in timp real precum QNX Software Systems sau Win River VxWorks.Chiar si pe piata PDA-urilor hi-end, unde Windows are cea mai mare cota de piata, au aparut dispozitivele bazate pe Symbian OS sau diferite tipuri de Linux.

Pentru dezvoltatorii de aplicatii mobile, esential este ca aplicatiile produse sa se execute pe cat mai multe platforme, cu un minimum de efort.Aici Java are mai multe avantaje asupra .NET CF, multe din platformele mobile enumereate mai sus avand suport incorporat pentru Java.Totusi, „write once, run anyware” este o sintagma adevarata mai mult din punct de vedere teoretic, destul de multe extensii standard J2ME, suportand facilitati care nu sunt disponibile pe toate platformele(de exemplu SMS-Short Message Service sau redare multimedia).De asemenea, producatorii de dipozitive tinda sa adauge valoare solutiilor lor prin oferirea de pachete de extensii J2ME proprietare.

Astefel, desi .NET CF nu este orientat in mof specific catre o piata de tip consumer, suporta desenarea direct pe canvas, double buffering sau remaparea butoanelor dispozitivului prin intermediul bibliotecilor Windows Forms.Prin intermediul API-urilor native Windows Media Player de pe Pocket PC, aplicatiile .NET ofera suport pentru redare de continut mutimedia.

Platformele J2ME au in comparatie cu .NET suport larg catre aplicatiile orientate catre consumatori, platforma fiind capabila sa ofere atat acces la jocuri cat si la redarea continutului multimedia.

Datorita lipsei accesului direct la hardware, nici .NET si nici J2ME nu sunt capabile pentru aplicatiile video de inalta performanta, suportul pentru aplicatiile consumator ramanand la ceea ce se poate observa la momentul actual pe piata.Nu acelasi lucru se poate spune despre aplicatiile mobile destinate intreprinderilor, ambele platforme oferind, prin intermediul producatorilor suport pentru dezvoltarea si intretinerea acestor tipuri de aplicatii.

Pentru a beneficia pe deplin de capacitatile off-line, existenta unei baze de date la nivelul dispozitivului mobil este esentiala. .NET suporta un subset substantial al ADO.NET, in timp ce Java ofera JDBC(Java DataBase Connectivity).Cu toate ca bazele de date izolate sunt destul de utile, la nivelul organizatiilor trebuie sa existe suport pentru sincronozarea si consolidarea cu bazele de date mari, utilizate in aplicatiile curente.La ora actuala nu exista un API standard pentru sincronizare pentru nici una din platformele discutate, fiecare producator de baze de date mobile sincronizad baza de date din dipozitivul mobil cu cea de la nivel de intreprindere prin propriile solutii.

In ceea ce priveste utilizarea serviciilor web, cheia integrarii aplicatiilor la nivel de organizatie, Microsoft are un avans considerabil in adoptarea acestora, fiind una din firmele mari care au adoptat de timpuriu aceasta tehnologie, promovand-o in toate aplicatiile sale recente.Consumarea(accesul) serviciilor web in .NET nu presupune nici un cod aditional, aceste servicii putand fi tratate ca si obiecte locale, din punct de vedere al programarilor.Pentru J2ME, suportul pentru SOAP nu este inca standardizat, existand totusi biblioteci care se pot utiliza pentru construirea clientilor SOAP mobili.De asemenea toate mediile de dezvlotare recente suporta utilizarea serviciilor web in J2ME prin intermediul lui kSOAP sau a serverelor de aplicatii wireless proprietare(Oracle cu 9i Wireless Aplication Server, de exemplu).

SOAP, inițial definită ca Simple Object Access Protocol, este o specificație protocolului pentru schimbul de informații structurate prin punerea în aplicare a Web Services în rețele de calculatoare. Ea se bazează pe Extensible Markup Language (XML) pentru formatul mesajului său, și de obicei se bazeaza pe alte protocoale Layer de aplicare, Remote Procedure Call mai ales de la distanță (RPC) și Hypertext Transfer Protocol (HTTP), pentru negociere și transport a mesajului. SOAP poate forma stratul de temelie a unei stive de protocoale de servicii web, oferind un cadru de bază de mesaje pe care serviciile web pot fi construite. Acest protocol bazat pe XML, se compune din trei părți: un plic(anvelopa), care definește ceea ce este în mesaj și modul de procesare, un set de reguli de codificare pentru exprimarea -tipurilor de date definite, și o convenție pentru apeluri de proceduri care reprezintă răspunsuri..

Din punct de vedere al managementul dispozitivelor,acesta este cea mai costisitoare parte pentru solutiile mobile de intreprindere de astazi.Asigurarea faptului ca utilizatorii potriviti obtin softul potrivit si ca softul este actualizat este deosebit de important pentru organizatiile care asigura accesul la resursele interne prin clienti mobili.Pentru aplicatiile mobile cu acces general, purtatorii retelelor wireless trebuie sa construiasca „gradini” pentru a proteja clientii si sursele de venit.Astfel, aplicatiile .NETsunt instalate prin intermediul ActiveSync sau „over the ait-OTA” prin intermediul Pocket PC Internet explorer, neexistand vre-un standard de control al clientului de catre back-end dupa instalare.De partea J2ME, plicatiile pot fi gestionate de pe back-end de-a lungul intregului ciclu de viata al produsului.

Concluzia etse ca atat .NET cat si J2ME sunt excelente platforme pentru dezvoltarea clientilor inteligenti in vederea utilizarii acestora in aplicatii la nivel de intreprindere sau pentru comert electronic mobil.Platforma .NET este orientata mai mult spre aplicatii de intreprindere cu interfata bogata cu utilizatorul, in timp ce J2ME suporta un design modular si este portabila pe o varietate de dispozitive, platforma oferind un suport balansat intre aplicatii de intreprindere si aplicatii orientate catre consumatori/utilizatori obisnuiti.

Capitolul 3

Retele Mobile 3G

3.1 UMTS – Universal Mobile Telecommunications System

Sistemul de comunicații mobile 3G – UMTS

UMTS (Universal Mobile Telecommunications System) sau 3G (a treia generație de comunicații mobile) este un sistem ce satisfice cerințele de globalizare ale comunicațiilor mobile, compatibil atât cu generațiile anterioare GSM (2G) dar și cu dezvoltările ulterioare 4G. UMTS face posibilă combinarea vocii, transmisiilor de date și video, permițând astfel servicii multimedia și end-to-end de bandă largă.

În figura 1.1 este prezentat un scurt istoric al generațiilor de comunicații mobile.

3.1.Sistemul 3G – UMTS

UMTS (Universal Mobile Telecommunications System) sau 3G (a treia generație de comunicații mobile) este un sistem ce satisfice cerințele de globalizare ale comunicațiilor mobile, compatibil atât cu generațiile anterioare GSM (2G) dar și cu dezvoltările ulterioare 4G. UMTS face posibilă combinarea vocii, transmisiilor de date și video, permițând astfel servicii multimedia și end-to-end de bandă largă.

În figura 3.2 este prezentat un scurt istoric al generațiilor de comunicații mobile.

Figura 3.1 Generații celulare[3]

Termenul global de 3G are diferite denumiri regionale:

● în Europa UMTS sub egida ETSI.

● în SUA și Japonia IMT-2000 sub egida ITU.

● în SUA CDMA 2000, este de asemenea o parte a sistemului celular 3G evoluat din IS-95.

Pentru a aduce ordine în politica confuză de denumire a sistemului 3G, 3GPP (3G Partnership Project) a luat o decizie ca denumirea oficială a acestuia este Sistemul 3GPP. Acest nume a fost folosit în standardele editate, astfel prima versiune a rețelei UMTS (după cerințele Europene) a fost numită oficial 3GPP System Release 99. Cu toate acestea denumirile de UMTS și IMT 2000 sunt încă foarte folosite.

Organizația 3GPP se vrea ca o umbrelă cu scopul de a forma standarde luând în considerare cerințele și presiunile politice, comerciale și industriale ale organismelor regionale de standardizare:

● ETSI (European Telecommunication Standard Institute)/Europa.

● ARIB (Association of Radio Industries and Business)/Japonia.

● CWTS (China Wireless Telecommunication Standard group)/China.

● T1 (Standardisation Committee T1—Telecommunications)/SUA.

● TTA (Telecommunication Technology Association)/Korea.

● TTC (Telecommunications Technology Committee)/Japonia.

Având în vedere această cerință dificilă o nouă organizație numită OHG (Operator

Harmonisation Group), independentă, a fost creată imediat după 3GPP.

Pentru a se asigura că punctul de vedere al Americii este luat în considerare a fost fondată organizația 3GPP Number 2 (3GPP2) ale cărei standarde se bazează pe dezvoltarea tehnologiei radio IS-95.

Cu toate acestea atât 3GPP, OHG și 3GPP2 au ca scop principal crearea unui sistem radio

celular global cu acces la servicii de bandă largă.

Cerințele principale pentru sistemul 3G sunt:

1. Sistemul trebuie să fie complet specificat (cum ar fi GSM) și interfețele majore ar trebui să

fiestandardizate și deschise. Specificațiile generate ar trebui să fie valide la nivel mondial.

2. Sistemul trebuie să aducă un plus de valoare pentru GSM în toate aspectele. Cu toate acestea, la început sistemul trebuie să fie compatibil cel puțin cu GSM și ISDN.

3. Multimedia și toate componentele sale trebuie să fie suportată în întregul sistem.

4. Accesul radio 3G trebuie să ofere o capacitate de bandă largă, care să fie destul de generică

pentru a deveni disponibilă la nivel global.

5. Accesul la servicii pentru utilizatorii finali trebuie să fie independent de tehnologia de acces radio și să nu fie limitat de infrastructura rețelei.

Sistemul 3G se mapează pe convergența comunicațiilor de date (Internet) și comunicațiile tradiționale din lumea telecom (comutație de circuite).

La început UMTS a moștenit multe elemente și principii de funcționare din GSM și cea mai considerabilă dezvoltare o reprezintă componenta de acces radio de bandă largă la rețea. Implementarea se face prin metoda de acces WCDMA. WCDMA este o variantă de CDMA , în care semnalul care urmează să fie transmis este „răsfirat‖ ca frecvență pe o lățime de bandă mai mare, devenind mai puțin sensibil la interferențe. Deși WCDMA diferă mult de CDMA, WCDMA folosește același nucleu de rețea (Core Network) ca și GSM 2G, rețea răspândită în întreaga lume, permițând o funcționalitate duală, în paralel cu funcționalitatea GSM/EDGE și a altor metode din cadrul UMTS. Codurile utilizate de către WCDMA nu se pot afecta reciproc. Codurile utilizate sunt, din punct de vedere matematic, ortogonale pentru fiecare utilizator (un cod este ortogonal în cazul în care produsul scalar a două semnale este zero). În acest fel receptorul poate decoda semnalul compus provenit concomitent de la mai multe stații de emisie – refăcând astfel semnalele individulale inițiale.Ideea principală din spatele 3G este existența unei arhitecturi universale capabilă să furnizeze serviciile electronice actuale și viitoare. Infrastructura trebuie proiectată astfel încât evoluțiile tehnologice să pot fi adaptate la rețea fără a prejudicia serviciile existente folosind arhitectura de rețea curentă. Separarea tehnologiilor de acces, de transport, de servicii și aplicațiile utilizatorilor face acest lucru posibil.

Structura unei rețele 3G poate fi abordată din perspectiva mai multor modele arhitecturale [6]:

● Modelul conceptual.

● Modelul structural.

● Arhitectura de Management al resurselor.

● Modelul orientat pe calitatea serviciilor furnizate.

3.2 Modelul conceptual

Conform acestui model arhitectura întregii rețele poate fi împărțită în subsisteme pe baza naturii traficului, structura protocoalelor și elementele fizice. Din punct de vedere al naturii traficului acesta este împărțit în doua mari domenii comutația de pachete (PS) și comutația de circuite (CS). Aici domeniu se referă la cel mai înalt nivel de grupare al entităților fizice și definirea interfețelor interdomenii. După structura protocoalelor avem două straturi: acces și non-acces. Aici strat se referă la modul de grupare al protocoalelor legat de un aspect al serviciilor oferite de unul sau mai multe domenii. Stratul acces conține protocoalele care se ocupă de comunicația dintre UE (User Equipment) și rețeaua de acces (radio). Stratul non-acces conține protocoale care se ocupă de comunicația dintre UE și nucleul (core-ul) rețelei (domeniile CS/PS).

Figura 3.2 Arhitectura UMTS – Modelul Conceptual[4]

3.3 Modelul Structural

În figura 3.3 este ilustrat acest model. Baza rețelei se bazează pe tehnologia GSM. UE reprezintă terminalul mobil în sistemul 3G și este alcătuit din ME (Mobile Equipment) și USIM (UMTS Service Identity Module) .UTRAN (UMTS Terrestrial Radio Access Network) este alcătuit subsisteme radio (RNS) și reprezintă componenta de acces radio la rețea (RAN). Un RNS conține cel puțin un Node B (corespondentul BS – stației de bază din GSM. Asigură transmisia și recepția semnalelor în una sau mai multe celule) și elementul de control RNC (Radio Network Controller). RNS-urile sunt conectate între ele prin interfața Iur. UE se conectează la UTRAN prin intermediul interfeței standard Uu.

Cealaltă componentă RAN este GERAN (GSM EDGE Radio Access Network). Acesta este specificat în 3GPP R99 , 3GPP R4 și 3GPP R5. Comunicația dintre GERAN și UTRAN este asigurată prin intermediul interfeței Iur-g. Tot prin intermediul aceleiași interfețe se asigura comunicația dintre BSS-uri. Comunicația dintre UE și MS (GSM) pe de o parte și BTS (componentă GERAN alături de BSS) se face prin intermediul interfeței Um.

Diferența dintre interfețele Iur și Iur-g este aceea că prin intermediul Iur se transportă atât și date cât semnalizări pe când prin intermediul Iur-g se transportă doar semnalizări.

● Core-ul rețelei (CN) cuprinde toate elementele de rețea ce asigură controlul abonaților și comutarea (CS/PS) – Accesul dintre RAN și CN este asigurat de interfața standard Iu

Când Iur este implementată în sistem, un UE se poate conecta la mai multe RNC-uri, fiecare având un anumit rol în conexiunea radio. Aceste roluri sunt de Serving RNC (SRNC), Drifting RNC (DRNC) și Controlling RNC (CRNC). CRNC are controlul general al resurselor logice de la punctele sale de acces UTRAN, fiind în principal BS sau Node B. SRNC este responsabil de conexiunea UE la UTRAN. Există un SRNC pentru fiecare conexiune radio a unui UE la UTRAN. Este responsabil și de menținerea legăturii Iu cu CN. Rolul DRNC este acela de a controla resursele radio dintre UTRAN și UE, când acesta din urmă are nevoie de a folosi celulele controlate de alt RNC.

Figura 3.3 Arhitectura UMTS – Modelul Structural[16]

CN este împărțită logic în domeniile CS și PS. În plus, se folosește un set de baze de date (―Registre‖) pentru păstrarea informațiilor necesare sistemului. Mai jos sunt descrise diferitele entități din domenii.

● Elementele Core Network – Domeniul comutației de circuite(CS)

Mobile Switching Center/Gateway Mobile Switching Center (MSC/GMSC)

Componenta centrală a domeniului CS în CN este MSC. MSC este un comutator care execută toate funcțiile de comutare și semnalizare pentru stațiile mobile existente în aria de responsabilitate a MSC. Principala diferență dintre un MSC și o centrală telefonică dintr-o rețea fixă este aceea că MSC trebuie să ia în considerare impactul alocării resurselor radio și natura mobilă a abonaților, ceea ce înseamnă că execută proceduri ca:

• Proceduri necesare pentru înregistrarea localizării

• Proceduri necesare pentru handover

● Server-ul Media Gateway/Mobile Switching Center (MGW/MSC)

Pentru a permite o arhitecură de rețea CS cu transport independent (și astfel să se poată implementa rețelele bazate pe all-IP), MSC este împărțit în MGW pentru transportul datelor de utilizator și MSC server pentru semnalizări. MSC server cuprinde în esență părțile de Call Control (CC) și controlul mobiltății dintr-un MSC. Această divizare în MGW și MSC server conduce, de asemenea, într-un mediu mai independent pentru crearea de servicii. Noile componente CAMEL beneficiază de pe urma acestui concept când controlul serviciului este independent de comutatorul propriu-zis.

MGW reprezintă punctul terminal de transport PSTN/PLMN și interfațează UTRAN cu CN prin Iu. MGW poate fi punctul final pentru canalele de transport dintr-o rețea cu comutație de circuite și stream-urile media dintr-o rețea cu pachete (ex. RTP (Real-time Transport Protocol) transferă într-o rețea IP).

● Signaling Gateway (SGW)

SGW convertește semnalizările (în ambele sensuri) la nivelul transport între transportul semnalizărilor bazat pe SS7 și transportul semnalizărilor bazat pe IP (ex. între Sigtran SCTP/IP și SS7 MTP). SGW nu interpretează mesajele la nivel aplicație (ex. MAP, CAP, BICC, ISUP), dar trebuie să interpreteze nivelul SCCP (Signaling Connection Control Part) sau SCTP (Stream Control Transmission Protocol) pentru a asigura o rutare corectă a semnalizărilor. SGW este necesar pentru a obține o rețea UMTS all-IP.

Funcția gateway pentru semnalizări poate fi implementată ca o entitate de sine stătătoare sau în altă entitate.

● Elementele Core Network (CN) – Domeniul comutației de pachete (PS)

Serving GPRS Support Node (SGSN)

SGSN acționează ca un comutator de pachete și ruter în domeniul PS al CN. SGSN controlează accesul MS la rețea și rutează pachetele către BSC/RNC adecvate. El realizează funcțiile Mobility Management (MM) similar cu MSC-ul în domeniul CS al CN cum ar fi înregistrarea localizării, actualizarea ariei de rutare Routing Area Updates (RAUs) și paging-ul.

SGSN execută, de asemenea, funcțiile de securitate cum ar fi autentificarea și ciphering-ul

(dintre MS/UE și SGSN).

● Gateway GPRS Support Node (GGSN)

GGSN acționează ca un ruter de pachete în domeniul PS al CN și este o poartă între rutarea pachetelor IP mobile ale rețelei GPRS/UMTS și rutarea fixă IP din Internet. El transferă pachete între rețelele multimedia IP și SGSN-ul corespunzător, care servește MS/UE la momentul respectiv.

Dacă MS schimbă SGSN-ul pe durata modului ready, GGSN este folosit ca buffer pentru pachetele de date. GGSN stochează datele abonatului pentru MS/UE active și realizează funcțiile de securitate ca firewall și screening.

● Elementele Core Network (CN) – Registrele Home Location Register (HLR)

HLR este un element independent al rețelei nucleu, existând până la Rel-4 inclusiv. În Rel-5, HLR este înlocuit de HSS (Home Subscriber Server), care este superior HLR-ului. HLR conține toate informațiile administrative ale fiecărui abonat înscris într-o anumită rețea, informații despre serviciile permise și locația curentă a mobilului. Locația mobilului este tipic în forma adresei de semnalizare a Visitor Location Register (VLR) asociat cu MS. În mod logic, există un HLR pe rețea,dar el poate fi implementat ca o bază de date distribuită.

HLR funcționează ca:

• Suport pentru entitățile din domeniul PS cum ar fi SGSN și GGSN. Este necesar să permită

accesul abonatului la serviciile domeniului PS.

• Suport pentru entitățile domeniului CS cum ar fi MSC/MSC server și GMSC/GMSC server. Este necesar pentru a permite accesul abonatului la serviciile domeniului CS și să asigure roaming-ul cu rețelele GSM/UMTS în domeniul CS

● Home Subscriber Server (HSS)

În UMTS Rel-5, HSS înlocuiește HLR. HSS este un HLR îmbunătățit (este un superset al HLR) și conține toate funcțiile acestuia plus altele suplimentare pentru a permite funcționalitatea IM (IP Multimedia) a IMS (IP Multimedia Subsystem).

HSS este o entitate comună domeniilor PS și CS, reprezentând baza de date master pentru un utilizator dat și conținând informații referitoare la abonament care să permiă componentelor rețelei să opereze cu apeluri/sesiuni, de exemplu să ajute serverele de control a convorbirii să efectueze procedurile de rutare/roaming prin rezolvarea autentificării, autorizării rezoluției de nume/adresă și dependența de locație.

O rețea UMTS poate conține unul sau mai multe HSS-uri, depinzând de numărul de

utilizatori mobili, de capacitatea echipamentului și de organizarea rețelei.

HSS constă din următoarele funcționalități:

• Funcționalitatea IM pentru a furniza sprijin funcțiilor de control ale IMS cum ar fi Call State Control Function (CSCF). Este necesară pentru a permite accesul abonatului la serviciile IM ale subsistemului CN.

• Subsetul funcționalității HLR cerut de domeniul PS

• Subsetul funcționalității HLR cerut de domeniul CS, dacă el este destinat să permită accesul abonatului la domeniul CS sau să sprijine roaming-ul la rețelele GSM/UMTS pe domeniul CS .

HSS conține următoarele informații referitoare la utilizator:

• Identificarea utilizatorului, informații de numerotare și adresare.

• Informații despre securitatea utilizatorului.

– Informații despre accesul la rețea pentru autentificare și autorizare.

• Informații despre locația utilizatorului la nivel inter-sistem.

– HSS asigură înregistrarea utilizatorului și stochează informațiile de locație inter-sistem, etc.

• Informații despre profilul utilizatorului.

● Visitor Location Register (VLR)

VLR conține informații administrative selectate din HLR, necesare pentru controlul convorbirii și pregătirea serviciilor la care există abonament, pentru fiecare mobil localizat curent într-o Location Area (LA) controlată de VLR. De fiecare dată când un mobil realizează roaming într-o nouă LA, VLR ce acoperă acea LA informează HLR despre noua locație a abonatului. HLR informează la rândul lui VLR despre serviciile la care abonatul are acces. VLR controlează de asemenea alocarea TMSI (Temporary Mobile Subscriber Identity).

HLR și VLR, împreună cu MSC, asigură rutarea convorbirilor și posibilitățile de roaming ale rețelei. În cele mai multe implementări, VLR este integrat cu MSC, și începând cu UMTS Rel-4 el este parte a MSC server.

● IP Multimedia Subsystem (IMS)

IMS cuprinde toate elementele CN pentru asigurarea serviciilor multimedia. Serviciile IM sunt bazate pe o capacitate de control a sesiunii definită de Internet Engineering Task Force (IETF). Serviciile IM, împreună cu capabilitățile multimedia, utilizează domeniul PS – cu posibilitatea de includere a unui set echivalent de servicii la subsetul relevant de servicii CS.

IMS permite operatorilor PLMN să ofere abonaților servicii multimedia bazate și construite pe aplicațiile, serviciile și protocoalele Internet.

3GPP nu are intenția să standardizeze astfel de servicii în IMS. Intenția este să se dezvolte toate aceste servicii de către operatorii PLMN și terți, incluzându-le în spațiul Internet, utilizând mecanismele furnizate de Internet și de IMS. IMS asigură convergența și permite accesul la voce, date, mesaje de date și tehnologii bazate pe web pentru utilizatorul mobil, combinând creșterea internetului cu creșterea comunicațiilor mobile.

Elementele funcționale specifice ale IMS sunt descrise mai jos.

• CSCF care are 3 roluri:

– Proxy-CSCF (P-CSCF) este primul punct de contact al echipamentului mobil cu IMS. Policy

Control Function (PCF) este o entitate logică a P-CSCF.

– Interrogating-CSCF (I-CSCF) este punctul de contact cu rețeaua unui operator pentru toate

conexiunile IMS destinate unui utilizator al acestui operator particular de rețea.

– Serving-CSCF (S-CSCF) realizează serviciile de control a sesiunii pentru echipamentul mobil.

• Media Gateway Control Function (MGCF) realizează conversia de protocol dintre ISUP (ISDN User Part) și protocoalele de control a convorbirii din IMS (ex. conversia ISUP/SIP (Session Initiation Protocol)).

• Multi Resource Function (MRF) realizează convorbirea multiparty și funcțiile de conferință

multimedia.

• IP Multimedia Media Gateway (IM-MGW) încheie canalele de transport dintr-o rețea cu comutație de circuite și stream-urile media dintr-o rețea cu pachete. IM-MGW poate asigura conversia media, controlul capabilităților de transport și prelucrarea sarcinii utile (ex. codec, anularea ecoului, punte de conferință).

3.4 Arhitectura de Management al Resurselor

Se bazează pe o împărțire a funcționalităților dintre domeniile principale ale rețelei și a elementelor de rețea. Acestea sunt:

● Managementul Comunicațiilor (CM).

● Managementul Mobilității (MM).

● Managementul Resurselor Radio (RRM).

Figura 3.4 Arhitectura UMTS – Managementul și controlul taskurilor[24]

CM acoperă toate funcționalitățile și procedurile legate de managementul conexiunilor user- ului: procesarea și controlul apelurilor în CS, controlul sesiunilor în PS precum și procesarea și controlul serviciilor suplementare și SMS.

MM acoperă toate funcțiile și procedurile necesare pentru mobilitate și securitate.

Majoritatea procedurilor au loc în CN dar și în UTRAN pentru PS.

RRM este o colecție de algoritmi și proceduri folosite în UTRAN pentru managementul resurselor radio: controlul puterii, handover, încărcarea sistemului și controlul înscrierii în sistem.

Toate aceste task-uri de management trebuie susținute de comunicația între domeniile și elemnentele rețelei. Comunicația se referă la strângerea de informații și raportarea statusului entităților distante precum și transmiterea acestora de comenzi pentru executarea deciziilor privind task-urile manageriale. Așadar fiecare astfel de task are asociat un set de sarcini de control precum:

● Controlul Comnucicațiilor (COMC): mecanisme de controlul apelurilor și sesiunilor.

● Controlul Mobilității (MOBC): mecanisme ce țin de securitate și updatarea locației.

● Controlul Resurselor Radio (RRC): protocoale de control privind stabilirea și menținerea

link-urilor dintre UE și UTRAN.

3.5 Arhitectura orientată pe calitatea serviciilor

Sistemul 3G este o infrastructură ce oferă facilități, banda necesară și calitate pentru

utilizatorii finali și aplicațiile acestora: QoS.

Figura 3.5 Arhitectura UMTS QoS [6]

MT este partea UE care încheie transmisiile radio din și înspre rețea și adaptează capabilitățile terminalului la transmisia radio.

În UTRAN purtătoarea de acces radio suferă mai multe modificări în funcție de timp și mobilitatea UE, ceea ce stabilește provocări diferite pentru QoS. În cazul CN serviciile de transport au un QoS constant, deoarece conexiunile fizice din backbone sunt stabile.

Serviciile retelei sunt considerate ca fiind de la sursa la destinatie (end – to – end), insemnand practic de la un echipament terminal la un alt echipament terminal. Un serviciu sursa – destinatie poate avea o anumita calitate a serviciului (QoS) ce este furnizata utilizatorului unui serviciu de retea. Utilizatorul decide insa daca este satisfacut de calitatea oferita sau nu. Practic QoS reprezinta un set de cerinte ce trebuie satisfacut astfel incat aplicatia sa poate fi livrata clientului atat la un nivel cantitativ, cat si la unul calitativ. Calitatea serviciilor in UMTS este data de asa numitul QoS Bearer Service si include aspecte ca si controlul semnalizarii, probabilitatea pachetelor pierdute, banda de frecventa garantata, controlul traficului si functionalitatea de management a calitatii serviciilor.

Cele patru modele arhitecturale sunt independente față de tehnologia de acces radio sau

tehnologia echipamentelor din CN.

3.6 Caracteristicile de acces radio ale sistemului UMTS

Accesul multiplu pe interfața radio se poate face în două moduri:

– DS-CDMA de bandă largă cu duplex frecvențial, WCDMA (FDD).

– DS-CDMA de bandă largă cu duplex temporal, WCDMA (TDD).

Sistemul european UMTS, în varianta pentru rețele terestre, utilizează pentru interfața radio WCDMA, benzile de frecvență:

– 1920-1980 MHz pentru downlink.

– 2110-2170 MHz pentru uplink.

Pentru interfața radio WCDMA în modul TDD s-au alocat benzile frecvență:

– 1900-1920 MHz pentru downlink;

– 2170-2200 MHz pentru uplink.

Banda unui canal radio modulat QPSK este de 5 MHz , durata cadrului de 10 ms, numărul de sloturi temporare este 15, debitul chip de 3,84 Mcps sunt aceleași atât pentru modul FDD cât și pentru modul TDD. Diferă factorul de împrăștiere DL (Down Link)/UL (Up Link) de 512:4/256:4 la FDD respective 16:1/16:1 la TDD și rata de simbol pe purtătoare 7,5/15kbps si 240/240 kbps respectiv pentru modul FDD si modul TDD. Numărul de canale radio în bandă este de 12 la modul FDD si de 4 la modul TDD.

Figura 3.6 Sloturile de pe o purtătoare [5]

Distanța dintre două purtătoare este mare de 4,2 – 5 MHz (cu un rastru de 200 kHz) pentru ca să nu se producă interferențe între canale. Canalele de transport, implementate pe canalele radio, sunt expandate spectral cu coduri de canalizare (spreading) și marcate cu coduri de împrăștiere – amestecare (scrambling) pentru a permite identificarea UE sau a BS, în funcție de sensul transmisiei.

Canale de comunicație

Interfața radio utilizează trei tipuri de canale:

● canale logice (de trafic și de control),

● canale de transport (comune și dedicate),

● canale fizice (comune și dedicate).

Canalele logice sunt definite prin tipul de informații care se transfer prin interfața radio (date de utilizator, semnalizări pentru controlul funcționării UE, informații de sistem sau de control general, etc.).

Nivelul MAC asigură servicii de transfer de date pe canale logice. În funcție de serviciul asigurat canalele logice pot fi canale de trafic TCH (pentru informații din planul de utilizator) și canale de control CCH (pentru informații din planul de control). Spre exemplu când un terminal mobil (UE) trebuie să efectueze orice schimb de informații cu rețeaua, trebuie mai întâi să stabilească o legătură de semnalizare cu UTRAN. UE va transmite o cerere de acces pe un canal de control comun (CCCH), iar legătura de semnalizare se va desfăsura pe un canal de control dedicat (DCCH). Canalele logice de trafic asigură servicii, care sunt clasificate după calitatea impusă (QoS) în patru clase: Conversational, Streaming, Interactive si Background.

Canale logice de trafic sunt:

DTCH (Dedicated Traffic Channel) – canal bidirectional punct la punct dedicat unui UE pentru transferul datelor utilizator (fax, Web browsing).

CTCH (Common Traffic Channel) – canal unidirecțional punct la multipunct, folosit pe DL (down link) pentru transferul unor informații de utilizator dedicate tuturor mobilelor sau numai unui grup precizat.

Canale logice de control sunt:

CCCH (Common Control Channel) – folosit de terminalele UE pentru a stabili o conexiune de

început RRC cu rețeaua.

DCCH (Dedicated Control Channel) -canal bidirecțional punct la punct pentru transferul de informații de control dedicate între rețea și un anumit UE.

BCCH (Broadcast Control Channel) – pentru a difuza informații de contol tuturor mobilelelor. PCCH (Paging Control Channel) – pentru a localiza un mobil.

Canalele de transport au rolul de vehiculare datelor, la debite variabile, între nivelele sistemului. Canalele de transport sunt definite prin modul în care se face transferul de date precum si prin caracteristicile fluxului de date (codarea, debitul, întârzierea de transfer necesară, etc.).

Un singur tip de canal de transport este dedicat DCH (Dedicated Channel), restul BCH, FACH, PCH, RACH, CPCH si DSCH sunt canale comune.

Canalele comune au nume diferite în funcție de destinația datelor și în funcție de sensul comunicației (uplink sau downlink).

Canalele fizice sunt definite prin frecvență a purtătoarei, fază a purtătoarei (numai pe

uplink), cod, putere, cadru temporal, etc.

Un cadru radio (radio frame) conține 15 intervale temporale. Lungimea unui cadru corespunde duratei a 3840 chips. Intervalul temporal (slot) este o unitate compusă din câmpuri, ce conțin biți de informație. Un interval temporal corespunde duratei a 2650 chips. Resursa fizică de bază o reprezintă planul cod-frecvență. Pentru uplink există două canale fizice dedicate, din care unul pentru date, DPDCH (Dedicated Physical Data Channel) și unul pentru control, DPCCH (Dedicated Physical Control Channel). Canalele DPDCH și DPCCH sunt multiplexate în cuadratură pe durata fiecărui cadru.

Pentru downlink există un singur tip decanal fizic dedicat DPCH (Dedicated Phisical

Channel).

Există 3 canale comune pe uplink și 10 pe downlink diferențiate în funcție de informația vehiculată.

Rate de transfer în rețeaua 3G

În condiții de mobilitate mare: 144 Kbps (mediu rural, viteză > 120 Km/h).

În condiții de mobilitate moderată: 384 Kbps (mediu urban, viteză < 120 Km/h).

În condiții de mobilitate limitată: 2Mbps (mediu indoor sau outdoor cu acoperire foarte bună, viteză < 10 Km/h).

În varianta cu High Speed Downlink Packet Access, HSDPA, poate atinge 7,2 Mbit/s. (Pentru comparație, sistemele 2G de tip GSM ating maximum 55 kbit/s, iar în varianta cu "Enhanced Data Rates for GSM Evolution", prescurtat EDGE, cel mult 220 kbit/s).

3.7 Arhitectura protocoalelor pe interfața radio a sistemului 3G

Figura 3.7 Arhitectura Protocoalelor pe interfața radio[6]

Nivelul fizic

Nivelul 1 (sau L1) se bazează pe tehnologia WCDMA. El interfațează cu subnivelul de

control al accesului la mediu MAC (Medium Access Control) din nivelul 2 și nivelul de control al resurselor radio RRC (Radio Resource Control) din nivelul 3. De asemenea, oferă pentru MAC diferite canale de transport, iar MAC oferă diferite canale logice pentru RRC. Nivelul fizic este controlat de RRC.

Nivelul legătura de date

Nivelul 2 (sau L2) asigură servicii și funcționalități ca MAC, RLC, protocolul de

convergență a datelor în pachete PDCP (Packet Data Convergence Protocol) și controlul modurilor broadcast/multicast BMC (broadcast/multicast control). De observat că PDCP și BMC există numai în planul informațiilor de utilizator.

Nivelul rețea

În planul de control, nivelul 3 este partiționat în mai multe subnivele, din care subnivelul cel

mai de jos este RRC. Aceasta asigură interfața cu nivelul 2 și se termină în UTRAN.

Nivelul 3 (rețea sau L3) asigură funcții pentru:

● managementul resurselor radio RRM (Radio Resource Management);

● controlul resurselor radio RRC;

● managementul mobilității MM (Mobility Management);

● managementul conexiunilor CM (Connection Management);

● controlul legăturii logice LLC (Logical Link Control).

Nivelul aplicatie: este nivelul la care sunt stocate aplicațiile accesibile utilizatorului. În majoritatea cazurilor aplicațiile sunt încorporate în terminalele mobile și în serverele de aplicații dedicate 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.).

Operatorii se pot diferenția unii față de alții pe baza pachetelor de servicii unice pe care le oferă abonaților la acest nivel. În plus, operatorii pot apela la firme specializate pentru dezvoltarea, rularea, sau depanarea acestor aplicații, ceea ce duce la un număr foarte mare de aplicații posibile oferite abonaților rețelei. Nivelul aplicație este conectat la nivelul controlului de rețea prin intermediul unor API-uri (Application Program Interface).

Nivelul control de rețea: acest nivel include toate funcțiile necesare asigurării unor servicii de calitate superioară pe diferite tipuri de rețele. Diferitele tipuri rețele pot fi privite ca și un set de domenii, fiecare dintre acestea având în componență servere de control care controlează fiecare tip de rețea în parte. Serverele de control administrează apelurile și sesiunile de comunicație între utilizatori, asigură serviciile de securitate, sau îndeplinesc alte funcții similare cu acestea. Aceste domenii pot fi deținute de un singur operator sau de operatori individuali pentru fiecare domeniu sau grup de domenii. Nivelul control de rețea conține și serverul HSS care are un rol foarte important, devenind o entitate multidomeniu. Acesta poate administra autorizări, autentificări și poate administra locații din toate domeniile prezente în rețeaua respectivă. Legatura între nivelul control de rețea și nivelul conectivitate este realizat cu ajutorul protocoalelor GCP (Gateway Control Protocol).

Nivelul conectivitate: la acest nivel vorbim despre un mecanism de transport capabil de transportul oricărui tip de informație prin intermediul conexiunilor vocale, de date sau ale fluxurilor multimedia. Arhitectura acestui nivel încorporează rutere sau comutatoare care direcționează traficul, precum și echipamente care colectează date și informații privind facturarea serviciului și asigură garanții cu privire la asigurarea unei bune calități a serviciului.

3.8. Comunicații mobile 4G

Dezvoltarea comunicațiilor mobile continuă, fiind susținută de previziunile de evoluție ale comunicațiilor mobile ca și de relația dintre diferiții „ actori” ai noilor sisteme. Integrarea dintre sistemele de radiocomunicații mobile și sistemele fixe de radiodifuziune, DxB, reprezintă una dintre principalele preocupări ale în domeniu.

O conlucrare „de succes trebuie să ofere tuturor părților posibilitatea de a-și spori veniturile. Totuși, aceasta nu este simplu, dacă se pune problema între un operator fix și unul mobil. Este pusă problema cooperării între 3G, eventual 4G și sistemele de radiodifuziune.

Sistemele mobile oferă un canal de legătură cu rețeaua de radiodifuziune iar informațiile oferite de aceasta pot fi de interes general sau de interes de grup pentru utilizatorii ce evoluează în zona de acoperire a celor două rețele [2].

Figura 3.8 Evoluția numărului de utilizatori ai telefoniei și ai Internetului[1]

Figura 3.9.Actorii unui sistem complex de comunicații[1]

Evident că prima întrebare ce se pune în mod firesc este de ce se trece la dezvoltarea unei noi generații de sisteme de comunicații, 4G, înainte de introducerea pe scară largă, în exploatare, a sistemelor 3G. Pentru 4G se pot da mai multe definiții, dintre care cea mai simplă este cea de viitoare generație de rețele radio ce va completa și înlocui, în viitor, rețelele 3G. La începutul anului

2003, 4G reprezintă în principal o inițiativă la nivel academic și de cercetare/dezvoltare ca și un cadru de discuții pentru evoluții viitoare, cu scopul eliminării problemelor semnalate în dezvoltarea

3G.

În favoarea dezvoltării 4G există o serie de argumente :

● Performanțele 3G pot să nu fie suficiente pentru a satisface necesitățile unor aplicații viitoare de înaltă performanță ca multimedia, video cu prezentare de mișcare, teleconferințe de calitate. Pentru acestea este necesară sporirea capacităților 3G cu un ordin de mărime.

● În momentul de față, pentru 3G există standarde multiple și, cu tot efortul de compatibilizarea a acestora, există dificultăți reale în asigurarea unui roaming global și a interoperabilității precum și a portabilității serviciului.

● 3G se bazează pe conceptul de arie extinsă. În prezent sunt însă necesare rețele hibride capabile să folosească atât LAN radio cât și rețele celulare.

● Sunt necesare lărgimi mai mari de bandă iar cercetările au arătat că în structura 3G, nu pot fi implementate unele scheme de modulație mai eficiente decât cele folosite.

● Se dovedește ca necesară existența unor rețele cu transmisie de pachete, capabile să folosească al deplina capacitate protocoalele Internet, cu convergența realizată între capacitățile de voce și de date.

Rețelele de comunicație mobilă 2G, mai ales sub forma 2+, reprezintă o evoluție importantă în concepția modernă a rețelelor de comunicații. Pentru rețelele de comunicație de generațiile 2+, 3 și 4 se pun câteva probleme esențiale, ce marchează dezvoltarea acestora și impun direcții de dezvoltare mai ales în sfera serviciilor. Astfel se urmăresc o serie de obiective majore cum sunt:

● Convergența / integrarea / conlucrarea tuturor rețelelor fixe și mobile, existente sau viitoare, fixe sau mobile (cu legătură prin cablu sau radio), incluzând radiodifuziunea. Baza convergenței va fi formată de tehnologiile IP.

● Ușurința de a selecta și folosi serviciile selectate. Aceasta va determina ofertanții de servicii la realizarea unor tehnologii de aplicație prietenoase și simplu de folosit, cu conținut adecvat tipului de utilizatori și zonei geografice în care se desfășoară serviciile.

● Realizarea de terminale universale și cu un cost cât mai scăzut, ceea ce conduce la

necesitatea unor tehnologii de reconfigurare.

Tabelul 3.Principalele performanțele 3G și 4G prezentate comparativ[4],[5]

Figura 3.10 Stratificarea ierarhică pentru rețelele de comunicații mobile 4G[1]

Criteriile de selecție de către utilizatori a rețelelor prin care să realizeze legătura de comunicație trebuie să aibă în vedere:

● Tipul de serviciu, caracterizat prin viteza de transmisie a datelor și calitatea necesară a serviciului;

● Resursele disponibile în zona de acces radio;

● Contextul în care se află situat utilizatorul, definit de elemente ca gradul de mobilitate, preferințele personale ale utilizatorului, locul și momentul realizării legăturii.

Transferul legăturii de comunicație între sisteme celulare de mare acoperire și rețelele radio LAN, de acces local, se poate realiza în diferite condiții și cu diferite cerințe. În acest sens este necesar ca la realizarea transferului:

● Să se selecteze între transferul în cadrul aceluiași strat ierarhic și transferul între

straturi ierarhice;

● Să se ia în considerare tipul de serviciu realizat și dacă serviciul se realizează în timp

real sau în timp non-real;

● Să se analizeze flexibilitatea ce poate fi realizată în ceea ce privește calitatea

serviciului pentru utilizatorul mobil;

● Să se ia în considerare transferul „ pe neobservate” , atunci când acesta este necesar;

● Să se realizeze o unificare, între protocoalele folosite de diferite rețele pentru autentificare, securizare și taxare, simplificând accesul la aplicații, din toate locațiile, în condițiile unei calități acceptabile a serviciului în orice moment.

Asigurarea condițiilor de dezvoltare și de funcționare a noilor sisteme de comunicații cu integrarea rețelelor și a serviciilor se poate realiza doar prin:

● Rezolvarea problemelor de standardizare, în special la interfața radio și la interfețele de interconectare între rețele.

● Stabilirea unor modele de afaceri;

● Stabilirea unor profiluri de preferință ale utilizatorilor;

● Elaborarea și precizarea mecanismelor și a criteriilor de transfer între sisteme;

● Elaborarea unor mecanisme pentru descărcarea softului;

● Stabilirea de metode pentru alocarea flexibilă a spectrului și de împărțire al acestuia între operatori;

● Noile sisteme vor trebui să permită preluarea unor tehnologii în curs de dezvoltare sau ce vor apărea în viitor.

E-UTRAN

Arhitectura rețelei LTE la nivel înalt este format din următoarele trei componente principale:

The User Equipment (UE).

The Evolved UMTS Terrestrial Radio Access Network (E-UTRAN).

The Evolved Packet Core (EPC).

The evolved packet core comunică cu rețele de pachete de date din lume, din afara, cum ar fi internetul, rețelele corporative private, sau subsistemul multimedia IP. Interfețele dintre diferitele părți ale sistemului sunt notate Uu, S1 și SGI așa cum se arată mai jos:

Fig 3.11 Architectura LTE[21]

Echipamentul mobil (UE)

Arhitectura internă a echipamentului de utilizator pentru LTE este identic cu cel utilizat de către UMTS și GSM, care este de fapt un Mobile Equipment (ME). Echipamentul mobil format din următoarele module importante:

Mobile Termination (MT): se ocupă de toate funcțiile de comunicare.

Terminal Equipment (TE): delimiteaza data streams.

Universal Integrated Circuit Card (UICC): acest lucru este, de asemenea, cunoscut sub numele de cartela SIM pentru echipamente LTE. Se rulează o aplicație cunoscut ca subscriber identity module universal (USIM).

Un USIM stochează date specifice de utilizator foarte similare pe cartela SIM 3G. Acest lucru ține informații despre numărul de telefon, identitatea rețeaua de domiciliu a utilizatorului și cheile de securitate, etc.

E-UTRAN (The access network)

Arhitectura evolved UMTS Terrestrial Radio Network Access (E-UTRAN) este ilustrata mai jos.

Fig 3.12: lte_e_utran[21]

E-UTRAN se ocupă de comunicațiile radio între telefonul mobil și evolved packet core(miezul de pachete evoluat) și are doar o componentă, numita eNodeB sau eNB. Fiecare eNB este o stație de bază care controlează unitățile mobile pe una sau mai multe celule. Stația de bază care comunică cu un telefon mobil este cunoscut sub numele de serving eNB.

LTE mobil comunică cu doar o stație de bază și o celulă la un moment dat și sunt urmăresc două funcții principale susținute de eNB:

EBN trimite și primește transmisiile radio pentru toate telefoanele mobile care folosesc analogice și funcțiile de procesare a semnalului analogic și digital din interfața aer LTE.

ENB controlează funcționarea la nivel scăzut la toate telefoanele sale mobile, trimițându-le mesaje, cum ar fi comenzi de predare-primire de semnalizare.

Fiecare EBN se conectează cu EPC prin intermediul interfeței S1 și poate fi, de asemenea, conectate la stațiile de bază din apropiere prin interfața X2, care este folosit în principal pentru semnalizare și packet forwarding in timpul handover-ului.

O home eNB (HeNB) este o stație de bază, care a fost cumpărata de către un utilizator pentru a oferi o acoperire femtocell în casă. O home eNB aparține unui grup de abonat închis (CSG) și pot fi accesate numai de telefoane mobile cu un SIM care face parte, de asemenea, la grupul de abonat închis.

The Evolved Packet Core (EPC) (The core network)

Acest articol se uită la Evolved Packet Core (EPC), rețeaua de bază a sistemului de LTE, oferind o imagine de ansamblu asupra arhitecturii rețelei de bază, descrie unele dintre elementele sale cheie.

EPC este cea mai recenta evolutie a arhitecturii de bază de rețea 3GPP.

În GSM, arhitectura se bazează pe circuit de comutare (CS). Acest lucru înseamnă că circuitele sunt stabilite între chemarea și zisele partide în întreaga rețea de telecomunicații (radio, rețea de bază a operatorului de telefonie mobilă, rețeaua fixă​​). Acest mod de comutare de circuit poate fi privită ca o evoluție a "două cutii și un șir de caractere". În GSM, toate serviciile sunt transportate pe comutarea de circuite de telefonie în principal, dar de mesaje scurte (SMS) și unele date este, de asemenea, văzut.

EPC a fost introdus pentru prima dată de către 3GPP în versiunea 8 a standardului.Sa decis să aibă o "arhitectură plată". Ideea este să se ocupe de sarcina utilă (traficul de date) în mod eficient de performanță și cost. Câteva noduri de rețea sunt implicați în manipularea de conversie de trafic și este evitată conversia de protocol.

De asemenea, sa decis să se separe datele utilizatorului (de asemenea, cunoscut sub numele de planul de utilizator) și semnalizarea (de asemenea, cunoscut sub numele de planul de control) pentru a face scalarea independentă.

Arhitectura Evolved Packet Core (EPC) a fost ilustrata mai jos. Există câteva elemente care nu au fost prezentate în diagrama pentru a o pastra cat mai simplă. Aceste componente sunt ca sistemul de cutremur și tsunami de avertizare (ETWS), Echipament de identitate Registrul (IER) și control al politicii și de încărcare Regulamentul Function (PCRF).

Fig 3.13: lte_epc[22]

Mai jos este o scurtă descriere a fiecărei componente prezentata în arhitectura de mai sus:

(HSS) Home Subscriber Server a fost reportat de la UMTS și GSM și este o bază de date centrală care conține informații despre toți abonații operatorului de rețea.

Packet Data Network (PDN) Gateway (P-GW), comunică cu lumea exterioară de exemplu rețele de pachete de date PDN, folosind interfata SGI. Fiecare rețea de pachete de date este identificat de un nume de punct de acces (APN).Gateway-ul PDN are același rol ca și nodul de sprijin GPRS (GGSN) și de servire nodul suport GPRS (SGSN) cu UMTS și GSM.

Gateway-ul de servire (S-GW), acționează ca un router, și transmite date între stația de bază și poarta de acces PDN.

Entitatea de management al mobilității (MME) controlează funcționarea mobilului la nivel înalt prin intermediul mesajelor și Home Subscriber Server (HSS) de semnalizare.

Policy Control and Charging Rules Function (PCRF) este o componentă care nu este prezentată în diagrama de mai sus, dar este responsabil pentru controlul politicilor de luare a deciziilor, precum și pentru controlul funcționalitățile de taxare bazate pe flux, în funcția de impunere de Control Policy (PCEF), care se află în P-GW.

Interfața dintre serving și gateway-urile PDN este cunoscut sub numele de S5/S8. Acest lucru are două implementări ușor diferite, și anume S5 dacă cele două dispozitive sunt în aceeași rețea, și S8 dacă acestea sunt în rețele diferite.

►HSS

Practic, HSS (pentru Home Subscriber Server) este o bază de date care conține informații legate de utilizator și legate de abonat. Acesta oferă, de asemenea, funcții de sprijin în gestionarea mobilității, de apel și de configurare sesiune, autentificarea utilizatorilor și autorizare de acces.
Ea se bazează pe pre-3GPP Release 4 – Home Location Register (HLR) și Centrul de autentificare (AuC).

►Serving GW

Gateway-urile (Servirea GW și PDN GW), a face cu avionul de utilizator. Ei transporta traficul de date IP între echipamente de utilizator (UE) și rețelele externe.

Serving GW este punctul de interconectare între-partea de radio și EPC. După cum indică și numele, această poartă servește UE de rutare pachetelor IP de intrare și de ieșire.Acesta este punctul de ancorare pentru mobilitatea intra-LTE (de exemplu, în caz de transfer între eNodeB) și între LTE și alte 3GPP accesează.
Acesta este conectat în mod logic la alte gateway-ul, PDN GW.

►PDN GW

PDN GW este punctul de interconectare între EPC și rețelele IP externe. Aceste rețele sunt numite PDN (Packet Data Network), de unde și numele. La PDN GW rute pachetele de la și de la PDN-uri.PDN GW efectuează, de 3GPP precizează aceste gateway-uri în mod independent, dar, în practică, ele pot fi combinate într-o singură "cutie" de către furnizorii de rețele.

►MME
MME (Entitate pentru Managementul de mobilitate ) se ocupă cu planul de control. Se ocupa de semnalizare legate de mobilitate și de securitate pentru acces la e-UTRAN.MME este responsabil pentru urmărirea și paginare de UE în inactiv-mode. Acesta este punctul terminal al non-Access Stratum(NAS)

Concluzia este că UMTS, care reprezintă sistemul de telecomunicații mobile

al viitorului apropiat pentru Europa, a fost dezvoltat la nivelul țărilor din Comunitatea

Europeană, în strânsă legătură tehnică cu sistemele dezvoltate de industriașii japonezi.

Împreună cu celelalte sisteme din 3G, poate asigura legături de comunicații la nivel mondial și o gamă largă de servicii, operațional cu începere din 2002 și cu o mare dezvoltare în peritada anilor 2005 . 2010.

Capitolul 4

Kit-urile de dezvoltare software

4.1.Application Programming Interface (API)

O interfață API este un set de funcții, structuri de date, clase de obiecte și/sau

protocoale accesibile din librării, sau oferite de serviciile sistemului de operare, pentru a

suporta crearea aplicațiilor.Un program care oferă funcționalitatea descrisă de interfața API este implementarea interfeței API. Interfața API în sine este abstractă, în sensul că specifică instanța dar nu se implică în detalii de implementare.

Un API poate fi dependent de un limbaj, dar și independent, adică poate fi folosit din mai multe limbaje de programare. Standardul POSIX (Portable Operating System Interface for Unix) definește un API care permite scrierea unor game mari de funcții de bază în așa fel încât să fie compatibile cu mai multe sisteme de operare. Câteva API-uri populare includ: ASPI pentru interfaŃa SCSI, DirectX pentrun Microsoft Windows, OpenGL cross-platform 3D, Carbon si Cocoa pentru Macintosh, etc.

Câteva principii de bază în proiectarea unui API: [24] să facă un singur lucru, dar să-l

facă bine – funcționalitatea să fie ușor de explicat. Să fie cât se poate de mic, dar să-și

satisfacă cerințele – poți să adăugi mai târziu, dar e mai greu să scoți. Implementarea nu ar trebui să influențeze API-ul. Un aspect important și un scop important al fiecărui API este să ascundă informațiile irelevante, clasele și membrii ar trebui să fie privați, cât posibil. Numele membrilor publici să fie sugestive, dar API-ul să aibă o documentație detaliată. În general să fie usor de învățat, usor de folosit chiar si fără documentație, greu de folosit incorect.

În cazul nostru se folosește “google/maps/api” care este un Api de la google fiind « free » pentru toti utilizatorii.

4.2.Kit-urile de dezvoltare PHP si PHPMyAdmin

PHP este prescurtarea de la Hypertext PreProcessor.Sper deosebire de paginile de HTML care puteau fi verificate si pe calculatorul local paginile PHP nu pot fi verificate decat daca sunt gazduite pe un server web care are instalat PHP.

Cand accesam o pagina HTML serverul care o gazduieste trimite pagina HTML catre browser spre afisare.In cazul unei pagini PHP serverul citeste codul HTML, il interpreteaza si genereaza dinamic pagina HTML care este trimisa browser-ului spre afisare.Acesta este motivul pentru care utilizatorii folosesc PHP pentru construirea unor pagini cu continut dinamic.

Fisierele PHP au extensia php. Puteti scrie astfel de fisiere cu Notepad sau cel mai indicat cu un editor specializat, de exemplu Crimson Editor, care va indica si numarul liniilor, lucru util la depanarea scriputrilorVerificati ca nu aveti extensiile ascunse (My Computer->Tools->Folder Options->View->debifati Hide extensions for known file types).Pentru a putea crea fisiere de tip php dati clic dreapta New->Text Document, apoi il redenumiti nume.php.

Cand PHP-ul parcurge un fisier de fapt citeste textul pana cand intalneste una din etichetele speciale care-i spun sa inceapa sa interpreteze textul ca pe cod PHP. Se executa codul pana cand este intalnita eticheta de inchidere. Apoi se citeste din nou textul mai departe.Acesta este motivul pentru care se poate adauga cod PHP in interiorul HTML-ului.

PHPMyAdmin este cea mai populara interfata de administrare a bazelor de date MySQL.

Se instaleaza OmniHTTP deoarece acesta are deja inclus PHP, un limbaj de programare care comunica cu bazele de date MySQL si in care a fost scris PHPMyAdmin.

4.3. Simulatorului NetBeans 7.1

NetBeans IDE este un kit gratuit care poate fi folosit pentru a crea aplicații Java si JavaFX. Acesta ofera de asemenea suport pentru multe dintre celelalte limbaje acceptate de JVM (de exemplu, Ruby, Javascript, PHP, etc.)
NetBeans este, de asemenea, cunoscut ca fiind o platforma care simplifică dezvoltarea de aplicații desktop prin furnizarea de API-uri care se ocupa de sarcinile de obicei necesare.

Fig4.1.:Prima etapa pentru a creea un nou proiect

În această secțiune, veti crea un nou proiect Java pentru o aplicație care urmează a fi dezvoltată în acest proiect de licență.

1. Din meniul principal, selectați File> New Project și apoi faceți următoarele în New Project Wizard:

a) Sub Categories, selectați JavaME.

b) Sub Projects, selectati MobileApplication

c) Click Next.

Fig4.2: A doua etapa afiseaza alegerea proiectului dorit

2. In campul Project Name completati  MobileAplication3

3. Pentru campul Project Location, click Browse, si navigați la orice director de pe computer.Click Open si completati MyPrj.

4. Debifati optiunile Set as Main Project si Create Main Class.

5. Click Finish. O casuta de progres apare. Cand proiectul JavaPrj (in cazul nostru se numeste Mobile Aplication 3) este creat, acesta apare in fereastra Projects.

Fig4.3: Finalizarea etapelor proiectului

 In figura de mai jos de mai jos este afisat modul cu se ruleaza proiectul:

1. În  fereastra  Projects faceți click dreapta pe nodul MobileAplication3 si alegeti  Build din meniul de  pop-up.

2. În  fereastra  Projects faceți click dreapta pe nodul MobileAplication3 si alegeti  Run File din meniul de  pop-up.

IDE-ul execută aplicatia si afiseaza urmatoarele iesiri in fereastra de iesire:

Fig4.4: Rularea proiectului

4.4 Conectarea cu Baza de Date MySQL

NetBeans IDE include suport built-in pentru Oracle Database. Puteți stabili cu ușurință o conexiune din interiorul IDE și începe să lucreze cu baza de date. Acest tutorial demonstrează cum se utilizează o instalare locală a Oracle Database 10g Express Edition (Oracle Database XE), o bază de date ușor, care este liber de a dezvolta, implementa, și distribui.

Acest document arată cum să configurați o conexiune la o instalare locală a Oracle Database XE de la NetBeans IDE, utilizați cod PHP built-in editor SQL pentru a gestiona datele bazei de date, și cum pentru a permite extinderea OCI 8 PHP pentru a scrie IDE care se conectează la o bază de date Oracle.

În tabelul de mai jos sunt prezentate resursele software pentru a stabili o conexiune NetBeans cu Baza de date MySql.

Tabelul 3 Resurse Software[15]

În acest exercițiu, veți testa și de a crea o nouă conexiune la baza de date.

Start Oracle database.

Deschideți Services window (Window > Services or Ctrl-5). în Services window, right-click Databases node și alegeți New Connection.

Fig 4.5. Noua conexiune la baza de date[15]

3. În New Connection wizard, selectați Oracle Thin in Driver dropdown list.

4. Click Add si cautati ojdbc6.jar pe care il veți downloada și Click Next.

5. În Customize Connection panel, introduceți următoarele valori și click Next.

Tabelul 4.Lista de valori [15]

6. Click Test Connection pentru a confirma IDE este pregătita să se conecteze la database. Click Next.

7. Click Finish.

Dacă încercarea are succes, mesajul "Conexiunea a reușit" este afișat.

Fig 4.6 Conexiune realizata cu success[15]

4.5.XAMPP

XAMPP este un pachet de programe free software, open source și cross-platform web server, care constă în Apache HTTP Server, MySQL database și interpretoare pentru scripturile scrise în limbajele de programare PHP și Perl.

Fig 4.7 XAMPP

Numele XAMPP este un acronim pentru:

● X (de la "cross", care înseamnă cross-platform)

● Apache HTTP Server

● MySQL

● PHP

● Perl

Instalarea XAMPP se face fără a fi nevoie de modificarea configurării componentelor instalate. XAMPP este actualizat cu regularitate pentru toate componentele: Apache/MySQL/PHP și Perl. Pot fi instalate și alte componente cum ar fi OpenSSL și phpMyAdmin.

Instalarea XAMPP ia mult mai puțin timp decât instalarea fiecărei componente în parte. Pot exista mai multe instanțe de XAMPP pe un singur computer, și fiecare instanță poate fi copiată pe alt computer.

În mod oficial, designerii XAMPP au avut intenția de a îl utiliza numai ca utilitar de dezvoltare, pentru a permite programatorilor web să își testeze munca pe calculatoarele proprii, fără a avea nevoie de acces la Internet. Pentru a face posibil acest lucru, multe caracteristici de securitate importante sunt dezactivate în mod implicit. Cu toate acestea XAMPP este uneori utilizat pentru a servi pagini web în World Wide Web.

XAMPP asigură suport pentru crearea și manipularea bazelor de date în MySQL și SQLite între utilizatori.

Odată ce XAMPP este instalat, adresa de localhost a serverului XAMPP este tratată ca pe un server la distanță.Proiectele ce se doresc a fi testate terbuie să se afle în folderul htdocs din xampp, pentru a fi rulate de serverul Apache.

Capitolul 5

Dezvoltarea aplicație client-server

Pentru testarea corespunzătoare a aplicațiilor client, a fost necesar crearea unor aplicații server cu scop de testare.

Aplicația server, proprie, a fost dezvoltata pentru interfațarea cu aplicația client ,utilizand acelasi mediu de programare NetBeans 7.1.

5.1. Server

Metode de implementare a bazelor de date:

Bazele de date sunt folosite pentru stocarea informatiilor in vederea furnizarii ulterioare in functie de solicitarea primita.

MySQL este un sistem de baze de date functional independant.

În PHP există funcții pentru toate operațiile executate asupra bazelor de date MySQL.

Administrarea MySQL

Administrarea MySQL se poate face din linie de comanda sau folosind browser-ul și accesând aplicația numită PHPMyAdmin scrisă in PHP.

Cele mai uzuale operații cu baze de date sunt:

Comanda Semnificație

CREATE creaza o baza de date sau un tabel

DROP șterge o baza de date sau un tabel

INSERT adaugă înregistrări într-un tabel

DELETE șterge înregistrări dintr-un tabel

UPDATE updatează înregistrările într-un tabel

SELECT selectează un tabel

ALTER alterarea unui tabel

În MySQL spațiul alocat pe discul serverului este în funcție de tipui de date.Câteva din tipurile de date folosite in bazele de date MySQL sunt:

Tip Semnificație

Int() număr întreg 32 biți

Bigint() număr întreg 64 biți

Tinyint() număr întreg(-128 la 127 sau 0 la 225) 8 biți

Mediumint() număr întreg 24 biți

Smallint() număr întreg 16 biți

Char() secțiune cu lungime

XAMPP asigură suport pentru crearea și manipularea bazelor de date în MySQL și SQLite între utilizatori.

Odată ce XAMPP este instalat, adresa de localhost a serverului XAMPP este tratată ca pe un server la distanță.

Proiectele ce se doresc a fi testate terbuie să se afle în folderul htdocs din xampp, pentru a fi rulate de serverul Apache.

PHP este un limbaj de programare ce ruleaza server, proiectat special pentru WEB.Intr-o pagina HTML puteti ingloba cod PHP care va fi executat la fiecare vizitare a paginii.

Codul dumneavoastra PHP este interpretat pe serverul WEB si genereaza un cod HTML care va fi vazut deUilizator (clientului (browserului) fiindu-i transmis numai cod interpretat ca si HTML).

PHP este un produs Open Source, cu acces la codul sursa. Il puteti folosi, modifica si redistribui, toate acesteain mod gratuit.

MySql ste un sistem de gestiune a bazelor de date, foarte rapid si robust.O baza de date va permite sa stocati, sa cautati, sa sortati si sa va regasiti datele in mod eficient.Serverul MySQL controleaza accesul la datele dumneavoastra pentru a garanta ca mai multi utilizatori potlucra simultan cu acestea.

MySQL este un server multi-user (mai multi utilizatori) si multi-thread (mai multe fire de executie).Utilizeaza SQL (StructuredQueryLanguage), limbajul standard de interogare a bazelor de date din intreagalume.

Legătura dintre PHP si MySql

Fig 5.1 Legatura dintre PHP si MySql

Creearea Bazei de date(server propriu) si populare cu tabele.Se acceseaza meniul Baze de date dupa care se introduce numele bazei de date.

Fig5.1.: Crearea bazei de date

Fig5.2:Afisarea Bazei de date si creearea tabelelor

Fig5.3 Tabele din baza de date

5.2.Client:

În acest proiect aplicația foloseste ca tehnologie J2ME care esre orientată către clienți, fiind înglobată în dispozitivele de piață.

J2ME este structurată pe profiluri, cofigurații si interfețe programabile

Fig 5.4.Arhitectura J2ME

Specificațiile J2ME sunt referite adeseori sub forma numărului corespunzător JSR, experții care contribuie la standardizarea lor fiind firme ca Sun, Nokia, Motorolla, Ericsson, Fujitsu, Siemens, Samsung, Vodafone, France Telecom, Orange, etc.

Un MIDlet este o aplicație care utilizează Mobile Information Device Profile (MIDP) din Connected Limited Device Configuration (CLDC).

MIDP – reprezintă un standard al Platformei Java 2 pentru a putea utiliza aplicații Java pe dispozitive precum telefoane mobile, PDA-uri, etc.

CLDC – este o specificație pentru aplicații JavaME ce descrie setul bibliotecilor de bază și caracteristicile mașinii virtuale Java care trebuie să fie prezente în dispozitiv pentru o punere în aplicare pentru mediul JavaME (Java Micro Edition).

Fig 5.5 CLDC si MIDP-2.0 in NetBeans 7.1

Cele două oferă împreună cerințele de bază, necesare pentru funcționarea aplicațiilor pentru terminale mobile, precum și o serie de API-uri Java.

Din punct de vedere structural, MIDlet-ul este un set de clase concepute pentru a fi rulate și controlate de soft-ul de management (sau sistem de operare – S.O. – se ocupă de gestionarea și coordonarea activităților echipamentului hardware) încorporat în dispozitiv. Acesta trebuie să conțină o clasă care extinde clasa javax.microedition.midlet.MIDlet.

Metodele din această clasă permit soft-ului de management cereri de a crea, începe propriu-zis, să pună pauză și să distrugă aplicația. Astfel MIDlet-urile sunt gestionate de către soft-ul de management încorporat în dispozitiv, deoarece o aplicație care rulează poate fi întreruptă în orice moment de evenimente din afară, cum ar fi apelurile primite.

Există trei stări posibile în ciclul de viață al unui MIDlet:

● pauză – MIDlet-ul a fost construit și este inactiv.( apelată când MIDlet-ul este pus în pauză

public void pauseApp() { })

● activ – MIDlet-ul este activ(apelată când MIDlet-ul este creat sau repornit

public void startApp() { })

● distrus – MIDlet-ul a fost terminat și este gata pentru recuperarea de către garbage collector (Java). (public void destroyApp(boolean unconditional) { })

Logarea se realizeaza pe baza unui „user” si o ”parola” care se vor defini de catre fiecare client care doreste sa utilizeze aplicatia.

Fig 5.6 Creeare unui user si parole petru autentificare.

public class HelloMIDlet extends MIDlet implements CommandListener {

private Display display;

MIDlet midlet;

private Alert alHelp;

Displayable next = null;

private Command exitCommand = new Command("Exit", Command.EXIT, 1);

private Command viewCommand = new Command("View", Command.OK, 1);

private Command backCommand = new Command("Back", Command.OK, 1);

private Command goCommand = new Command("Login", Command.OK, 1);

private Form mainForm;

private Form loginForm;

private TextField fldUser = new TextField("Username:", "a", 50, TextField.ANY);

private TextField fldPass = new TextField("Password:", "a", 50, TextField.PASSWORD);

Folosind serviciile web oferite de Google (GRATUITE), precum și resurse proprii am creat un sistem de navigare si afișarea pe hartă a echipamantelor din Rețeaua H3G Italia.Dupa rularea aplicatie pe emulator se face click pe „Menu” si va apărea lista cu informatiile pe care dorim sa le accesăm.

Fig 5.7 Afișare Echipamente

Afișare inv ofera utilizatorului/field accesul la informații legate de Serial Number si Part Number al unei componente HW care necesita a fi schimbată.

Fig 5.8 Afișare detalii despre componentele HW

Fig 5.9 Afișarea celulelor

Vizualizarea\navigarea a unei hărți se face folosind geocodarea (Google Geocoding API, Google Maps Static API) .

După autentificare utilizatorul accesează o nouă interfață grafică unde trebuie să introducă informațiile de localizare pe care dorește să le vadă pe hartă prin inserarea datelor Oras si Strada si apoi accesarea butonului View.

Fig 5.10 Accesarea informatiilor dorite

Geocodarea este procesul prin care poziția unui obiect definit indirect (prin adresă poștală, prin denumirea unității administrative sau a unei denumiri cunoscute – human readable) este transformată în coordonate geografice, care astfel se poate localiza pe hartă.

Fig 5.11 Rezultatul returnat

Din punct de vedere tehnic se urmărește folosirea comunicației și schimbul de informații client-server via http, precum și gestionarea resurselor de procesare propii dispozitivului mobil.

Location API pt. J2ME permite interogarea dispozitivului GPS pentru obținerea de informații specifice de la acesta : latitudine, longitudine,etc.

Google Maps Static API, Google Geocoding API reprezintă servicii cartografice publice, gratuite: vizualizare hărți respectiv geocodare.

$op = $_REQUEST["op"];

$param = $_REQUEST["param"];

switch ($op)

{

case "geocode" : $address = urlencode($param);

$loc = geocoder::getLocation($address);

echo $loc['lat'] . "," . $loc['lng'];

break;

Fig 5.12 Rezultate Finale rulării aplicație

Capitolul 6

Concluzii

Aplicațiile sunt utile dispozitivelor mobile cu acces limitat la rețea și capacitate de procesare redusă. Oferă utilizatorilor diverse instrumente care pot să-i ajute în diferite situații din viața de zi cu zi. Uneltele folosite în dezvoltarea aplicațiilor sunt free software, nefiind necesară licențierea acestora.

Instalarea aplicațiilor pe un dispozitiv hardware se efectuează într-un mod facil, în majoritatea cazurilor fiind de ajuns doar instalarea arhivei .jar. Folosind unelte accesibile și ușor de utilizat arhiva .jar poate fi convertită în .apk, acceași aplicație având posibilitatea de a fi instalată pe telefoane mobile cu sistemul de operare Android.

În cadrul testării aplicațiilor a fost folosită în diverse scenarii comunicația și schimbul de informații client-server prin intermediul protocolul Http.

Arhitectura serviciilor web folosite și create este de tip REST: resursele, diverse fișiere, sunt stocate pe mai multe servere, sunt identificate prin URL, iar interfața comună este protocolul HTTP.

Aplicațiile dezvoltate integrează mai multe servicii, hărți, direcții de navigare, oferirea de date cu caracter informativ, într-o singură aplicație. Astfel se reduce timpul de căutare, rezultatul obținut fiind disponibil imediat.

Bibliografie:

[1] Ștefan .Victor Nicolaescu: .Sisteme de comunicații mobile celulare GSM., Editura

AGIR, București, 1999

[2] Ștefan-Victor Nicolaescu: .Rețele 3G . Europa., Ed. AGIR, 2003

[3] Ramjee Prasad, Werner Mohr, Walter Kornhäuser: .Third Generation Mobile

Communication Systems., Editura Artech House, , , 1999

[4] Forumul UMTS, Rapoartele 1 . 20

[5] ITU-R M 816-1: .Framework for Services Supported on International Mobile

Telecommunications-2000 (IMT-2000)., 1997

[6] ITU-R Recomandarea M 1035: .Framework for the radio interface (s) and radio subsystem

functionality for international mobile telecommunications . 2000 (IMT-2000).

[7] Aldo Bolle, Hyperaccess . Status and plans, Erricsson, jan 12-15 HA/N-WEST Joint

Session

[8] "TINA, A Cooperative Solution for a Competitive World", Prentice Hall , 1999

[9] Mampaey, "TINA for Services and Advanced Signaling and Control in Next-Generation Networks", IEEE Communications Magazine, October 2000, Vol. 38, No. 10

[10] Mampaey, A. Couturier, "Using TINA Concepts for IN Evolution", IEEE Communications Magazine, June 2000, Vol. 34, No. 6

[11] C. Abarca, P. Farley, J. Forslow, J. C. Garcia, T. Hamada, P. F. Hansen, S. Hogg, H. Kamata, L. Kristiansen, C. A. Licciardi, H. Mulder, E. Utsunomiya, M. Yates, "TINA Service Architecture", Version 5.0, June 1997, http://www.tinac.com

[12] J. Bloch, How to Design a Good API and Why it Matters, noiembrie 2006

[13] WCDMA W11 RAN Operation LZU 1087886 R2A Ericsson AB 2011

[14] wwww.ericssonacademy.ro Ericsson Academy

[15] https://netbeans.org/kb/docs/ide/oracle-db.html

[16] http://www.3gpp.org/specifications

[17] http://www.3gpp.org/ftp/Information

[18] http://www.3gpp.org/ftp/Specs/html

[19] http://en.wikipedia.org/wiki/Web_service,

[20] http://www.3gpp.org/ftp/Specs/html defines the architecture enhancements for non-3GPP accesses.

[21]https://www.google.ro/url?sa=t&rct=j&q=&esrc=s&source=web&cd=13&cad=rja&uact=8&ved=0CFsQFjAM&url=http%3A%2F%2Fwww.3gpp.org%2Ftechnologies%2Fkeywords-acronyms%2F100-the-evolved-packet-core&ei=GwqnU_-aFKHa0QWHrIGwBA&usg=AFQjCNGvV0kVWBS1S-GoIO2DhWLgaybdmg

[22] http://www.tutorialspoint.com/lte/lte_network_architecture.htm

[23] http://www.danielbuca.ro/online-related/proiectare-de-aplicatii-online-arhitectura-orientata-pe-servicii-web-1-85.html

[24] E. Marza, Radiocomunicaii mobile, EOU, Timișoara, 2001

Anexa 1 Codul Sursa al aplicatiei

import java.io.IOException;

import javax.microedition.lcdui.*;

import javax.microedition.midlet.MIDlet;

public class HelloMIDlet extends MIDlet implements CommandListener {

private Display display;

MIDlet midlet;

private Alert alHelp;

Displayable next = null;

private Command exitCommand = new Command("Exit", Command.EXIT, 1);

private Command viewCommand = new Command("View", Command.OK, 1);

private Command backCommand = new Command("Back", Command.OK, 1);

private Command goCommand = new Command("Login", Command.OK, 1);

private Form mainForm;

private Form loginForm;

private TextField fldUser = new TextField("Username:", "a", 50, TextField.ANY);

private TextField fldPass = new TextField("Password:", "a", 50, TextField.PASSWORD);

private TextField tf1 = new TextField("Strada", "Dinicu Golescu", 50, TextField.ANY);

private TextField tf2 = new TextField("Oras", "Bucuresti", 50, TextField.ANY);

private String st1, st2;

public static String defaultURL = "http://localhost/mob/index.php";

public HelloMIDlet() {

display = Display.getDisplay(this);

midlet = this;

}

public void startApp() {

loginForm = new Form("Login");

loginForm.append(fldUser);

loginForm.append(fldPass);

loginForm.addCommand(goCommand);

loginForm.setCommandListener(this);

mainForm = new Form("Addresa");

mainForm.append(tf1);

mainForm.append(tf2);

mainForm.addCommand(viewCommand);

mainForm.addCommand(exitCommand);

mainForm.setCommandListener(this);

display.setCurrent(loginForm);

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

public int getScreenHeight() {

return display.getCurrent().getHeight();

}

public int getScreenWidth() {

return display.getCurrent().getWidth();

}

public void commandAction(Command c, Displayable s) {

if (c == viewCommand) {

st1 = tf1.getString();

st1 = utils.replaceAll(st1, " ", "%2B");

st2 = tf2.getString();

st2 = utils.replaceAll(st2, " ", "%2B");

String address = st2 + "," + st1;

String AdressData = st1 + "|" + st2;

String coord = "";

try {

coord = utils.doHttpRequest("geocode", address);

} catch (IOException e) {

coord = "";

}

if (coord.length() > 10) {

next = new loadCMarker(midlet, mainForm, coord, AdressData);

display.setCurrent(next);

} else {

alHelp = new Alert("Info", "Eroare Geocodare Adresa!", null, AlertType.ERROR);

display.setCurrent(alHelp);

}

} else if (c == backCommand) {

display.setCurrent(mainForm);

} else if (c == goCommand) {

//request de intoarcere user si pass din la baza de data

String cx = "";

try {

cx = utils.doHttpRequest("auth", fldUser.getString() + "|" + fldPass.getString());

} catch (IOException e) {

cx = "";

}

if ("ok".equals(cx)) {

display.setCurrent(mainForm);

} else {

fldUser.setString("");

fldPass.setString("");

alHelp = new Alert("Info", "Eroare Autentificare !", null, AlertType.WARNING);

display.setCurrent(alHelp);

}

} else {

destroyApp(false);

notifyDestroyed();

}

}

}

Anexa 2

/*

* To change this template, choose Tools | Templates

* and open the template in the editor.

*/

package hello;

import com.jappit.midmaps.googlemaps.*;

import java.io.IOException;

import javax.microedition.lcdui.*;

import javax.microedition.midlet.MIDlet;

import java.util.Vector;

import org.json.me.*;

/**

*

*

*/

public class loadCMarker extends Canvas implements GoogleStaticMapHandler, CommandListener {

GoogleMaps gMaps = null;

GoogleStaticMap map = null;

Displayable testListScreen;

MIDlet midlet;

ImageItem mapItem;

String AdressData = "";

private TextBox textBox;

Command zoomInCommand, zoomOutCommand, back, exit;

private Command loadCommand = new Command("Load", Command.OK, 1);

private Command RBSCommand = new Command("Afisare NodeB", Command.OK, 1);

private Command RNCCommand = new Command("Afisare RNC", Command.OK, 1);

private Command CELCommand = new Command("Afisare Cell", Command.OK, 1);

private Command INVCommand = new Command("Afisare INV", Command.OK, 1);

private Command exitInv = new Command("Exit", Command.BACK, 1);

static String API_KEY = "";

public loadCMarker(MIDlet m, Displayable testListScreen, String coord_str, String AdressData) {

//super("Map View");

double lat;

double lng;

this.midlet = m;

this.AdressData = AdressData;

this.testListScreen = testListScreen;

Vector data = new Vector();

//this.addCommand(loadCommand);

this.addCommand(RBSCommand);

this.addCommand(RNCCommand);

this.addCommand(INVCommand);

this.addCommand(CELCommand);

this.addCommand(back = new Command("Back", Command.BACK, 1));

this.addCommand(zoomInCommand = new Command("Zoom in", Command.OK, 1));

this.addCommand(zoomOutCommand = new Command("Zoom out", Command.OK, 2));

String[] coords = utils.Split(coord_str, ",");

lat = Double.parseDouble(coords[0]);

lng = Double.parseDouble(coords[1]);

GoogleMapsCoordinates coord = new GoogleMapsCoordinates(lat, lng);

setCommandListener(this);

mapItem = new ImageItem("Loading map…", null, Item.LAYOUT_TOP, "Sample map");

//this.append(mapItem);

gMaps = new GoogleMaps();

map = gMaps.createMap(getWidth(), getHeight(), GoogleStaticMap.FORMAT_PNG);

map.setHandler(this);

map.setCenter(coord);

map.setZoom(15);

GoogleMapsMarker redMarker = new GoogleMapsMarker(coord);

redMarker.setColor(GoogleStaticMap.COLOR_RED);

redMarker.setSize(GoogleMapsMarker.SIZE_MID);

map.addMarker(redMarker);

map.update();

}

public void GoogleStaticMapUpdateError(GoogleStaticMap map, int errorCode, String errorMessage) {

System.out.println("map error: " + errorCode + ", " + errorMessage);

}

public void addMarker(String coord_str, String color) {

String[] coords = utils.Split(coord_str, ",");

double lat = Double.parseDouble(coords[0]);

double lng = Double.parseDouble(coords[1]);

GoogleMapsCoordinates coord = new GoogleMapsCoordinates(lat, lng);

GoogleMapsMarker redMarker = new GoogleMapsMarker(coord);

redMarker.setColor(color);

redMarker.setSize(GoogleMapsMarker.SIZE_MID);

map.addMarker(redMarker);

}

public void drawMarkersFromJson(String cx, String element){

boolean result = false;

String color = GoogleStaticMap.COLOR_RED;

if("RBSCommand".equals(element)){

color = GoogleStaticMap.COLOR_BLUE;

} else if ("RNCCommand".equals(element)){

color = GoogleStaticMap.COLOR_GREEN;

} else {

color = GoogleStaticMap.COLOR_RED;

}

try {

JSONObject jobj = new JSONObject(cx);

result = true;

JSONArray coordList = jobj.getJSONArray("list");

if (coordList != null) {

for (int n = 0; n < coordList.length(); n++) {

JSONObject entry = coordList.getJSONObject(n);

String coord_str = entry.getString("coord");

addMarker(coord_str,color);

}

} else {

System.out.println("Err Json Parse!");

}

map.update();

} catch (JSONException ex) {

result = false;

}

}

public void GoogleStaticMapUpdated(GoogleStaticMap map) {

System.out.println("map ok");

mapItem.setImage(map.getImage());

mapItem.setLabel("");

repaint();

}

protected void paint(Graphics g) {

map.draw(g, 0, 0, Graphics.TOP | Graphics.LEFT);

}

protected void keyPressed(int key) {

int gameAction = getGameAction(key);

if (gameAction == Canvas.UP || gameAction == Canvas.RIGHT || gameAction == Canvas.DOWN || gameAction == Canvas.LEFT) {

map.move(gameAction);

}

}

public void commandAction(Command c, Displayable d) {

if (c == zoomInCommand) {

map.zoomIn();

} else if (c == zoomOutCommand) {

map.zoomOut();

}

if (c == back) {

Display.getDisplay(midlet).setCurrent(testListScreen);

}

if (c == loadCommand) {

String cx = "";

try {

cx = utils.doHttpRequest("geocode", "Nordului, Bucuresti");

} catch (IOException e) {

cx = "";

}

}

if (c == RBSCommand) {

String cx = "";

String param = AdressData;

try {

cx = utils.doHttpRequest("RBSCommand", param);

} catch (IOException e) {

cx = "";

}

drawMarkersFromJson(cx,"RBSCommand");

}

if (c == RNCCommand) {

String cx = "";

String param = AdressData;

try {

cx = utils.doHttpRequest("RNCCommand", param);

} catch (IOException e) {

cx = "";

}

drawMarkersFromJson(cx,"RNCCommand");

}

if (c == CELCommand){

String cx = "";

String param = AdressData;

try {

cx = utils.doHttpRequest("CELCommand", param);

} catch (IOException e) {

cx = "";

}

textBox = new TextBox("Celule", cx, 1500, TextField.ANY);

textBox.addCommand(exitInv);

textBox.setCommandListener(this);

Display.getDisplay(midlet).setCurrent(textBox);

}

if (c == INVCommand) {

String cx = "";

String param = AdressData;

try {

cx = utils.doHttpRequest("INVCommand", param);

} catch (IOException e) {

cx = "";

}

textBox = new TextBox("Inventar", cx, 1500, TextField.ANY);

textBox.addCommand(exitInv);

textBox.setCommandListener(this);

Display.getDisplay(midlet).setCurrent(textBox);

}

if (c == exitInv) {

Display.getDisplay(midlet).setCurrent(this);

}

}

}

Anexa 3

/*

* To change this template, choose Tools | Templates

* and open the template in the editor.

*/

package hello;

import java.io.IOException;

import java.io.InputStream;

import java.io.OutputStream;

import java.util.Vector;

import javax.microedition.io.Connector;

import javax.microedition.io.HttpConnection;

/**

*

*/

public class utils {

public static String replaceAll(String text, String searchString, String replacementString) {

StringBuffer sBuffer = new StringBuffer();

int pos = 0;

int EOF = – 1;

while ((pos = text.indexOf(searchString)) != EOF) {

sBuffer.append(text.substring(0, pos)).append(replacementString);

text = text.substring(pos + searchString.length());

}

sBuffer.append(text);

return sBuffer.toString();

}

public static String searchlat(String text, String searchString) {

int pos = 0;

int EOF = – 1;

int end = 0;

end = text.indexOf("</lat>");

if ((pos = text.indexOf(searchString)) != EOF) {

text = text.substring(pos + searchString.length() + 1, end);

}

StringBuffer result = new StringBuffer();

result.append(text);

return result.toString();

}

public static String searchlng(String text, String searchString) {

int pos = 0;

int EOF = – 1;

int end = 0;

end = text.indexOf("</lng>");

if ((pos = text.indexOf(searchString)) != EOF) {

text = text.substring(pos + searchString.length() + 1, end);

}

StringBuffer result = new StringBuffer();

result.append(text);

return result.toString();

}

public static String[] Split(String splitStr, String delimiter) {

StringBuffer token = new StringBuffer();

Vector tokens = new Vector();

// split

char[] chars = splitStr.toCharArray();

for (int i = 0; i < chars.length; i++) {

if (delimiter.indexOf(chars[i]) != -1) {

// we bumbed into a delimiter

if (token.length() > 0) {

tokens.addElement(token.toString());

token.setLength(0);

}

} else {

token.append(chars[i]);

}

}

// don't forget the "tail"…

if (token.length() > 0) {

tokens.addElement(token.toString());

}

// convert the vector into an array

String[] splitArray = new String[tokens.size()];

for (int i = 0; i < splitArray.length; i++) {

splitArray[i] = (String) tokens.elementAt(i);

}

return splitArray;

}

static public String urlEncode(String sUrl) {

StringBuffer urlOK = new StringBuffer();

for (int i = 0; i < sUrl.length(); i++) {

char ch = sUrl.charAt(i);

switch (ch) {

case '<':

urlOK.append("%3C");

break;

case '>':

urlOK.append("%3E");

break;

case '/':

urlOK.append("%2F");

break;

case ' ':

urlOK.append("%20");

break;

case ':':

urlOK.append("%3A");

break;

case '-':

urlOK.append("%2D");

break;

default:

urlOK.append(ch);

break;

}

}

return urlOK.toString();

}

static public String doHttpRequest(String op, String var) throws IOException {

HttpConnection httpConn = null;

String url = HelloMIDlet.defaultURL + "?op=" + op + "&param=" + urlEncode(var);

String response = "";

InputStream is = null;

OutputStream os = null;

System.out.println(url);

try {

// Open an HTTP Connection object

httpConn = (HttpConnection) Connector.open(url);

// Setup HTTP Request

httpConn.setRequestMethod(HttpConnection.GET);

httpConn.setRequestProperty("User-Agent",

"Profile/MIDP-1.0 Confirguration/CLDC-1.0");

// This function retrieves the information of this connection

getConnectionInformation(httpConn);

int respCode = httpConn.getResponseCode();

if (respCode == httpConn.HTTP_OK) {

StringBuffer sb = new StringBuffer();

os = httpConn.openOutputStream();

is = httpConn.openDataInputStream();

int chr;

while ((chr = is.read()) != -1) {

sb.append((char) chr);

}

System.out.println(op + " " + sb.toString());

response = sb.toString();

} else {

// System.out.println("Error in opening HTTP Connection. Error#" + respCode);

}

} finally {

if (is != null) {

is.close();

}

if (os != null) {

os.close();

}

if (httpConn != null) {

httpConn.close();

}

}

return response;

}

static void getConnectionInformation(HttpConnection hc) {

}

}

Anexa 4-Troubleshooting

In imaginea de mai jos este prezentat sistmul de monitorizare in timp real al alarmelor retelei H3G Ericsson Italia.

Fig1.Alarm List Viewer(ALV)[WCDMA W11 RAN Operation LZU 1087886 R2A]

In interfata CEX(Common Explorer) avem posibiliata de a vedea stare unei statii mobile si a celulelor. Putem efectua investigatii asupra statiilor(nodeb/bts) si la cerere putem bloca/debloca celule, restarta nodeb-ul,etc.

Fig.2 Cautarea NodeB-ului[WCDMA W11 RAN Operation LZU 1087886 R2A]

Fig.3. Cautarea si afisarea caii in toolul N&SIS[WCDMA W11 RAN Operation LZU 1087886 R2A]

In figura 4 este afisat MiniLink Craft sau SoEM este un tool prin care se pot configura si monitoriza radio link-uri.

Fig.4 Parametri gasiti cu tool-ul SoEM[WCDMA W11 RAN Operation LZU 1087886 R2A]

Figura 5 este prezentat Logbook SMC care este o baza de date unde sunt stocate informatii despre nume, locatie si alte informatii despre un nodeB.

Fig.5 Cautarea Informatiilor dorite WCDMA W11 RAN Operation LZU 1087886 R2A]

Figura 6 prezinta modul de gestionare al alarmelor cu ajutorul tool-ului OMAR si trimiterea lor catre inginerul de teren(FSA) pentru a fi rezolvata.

Fig 6 Crearea Troubkleticket-ului in OMAR WCDMA W11 RAN Operation LZU 1087886 R2A]

Figura 7 ne arata cum ajunge problema gestionata de NOC si forma in care o primeste inginerul de teren.

Fig.7 Trimiterea TT-ului in WFM catre FSA. WCDMA W11 RAN Operation LZU 1087886 R2A]

Bibliografie:

[1] Ștefan .Victor Nicolaescu: .Sisteme de comunicații mobile celulare GSM., Editura

AGIR, București, 1999

[2] Ștefan-Victor Nicolaescu: .Rețele 3G . Europa., Ed. AGIR, 2003

[3] Ramjee Prasad, Werner Mohr, Walter Kornhäuser: .Third Generation Mobile

Communication Systems., Editura Artech House, , , 1999

[4] Forumul UMTS, Rapoartele 1 . 20

[5] ITU-R M 816-1: .Framework for Services Supported on International Mobile

Telecommunications-2000 (IMT-2000)., 1997

[6] ITU-R Recomandarea M 1035: .Framework for the radio interface (s) and radio subsystem

functionality for international mobile telecommunications . 2000 (IMT-2000).

[7] Aldo Bolle, Hyperaccess . Status and plans, Erricsson, jan 12-15 HA/N-WEST Joint

Session

[8] "TINA, A Cooperative Solution for a Competitive World", Prentice Hall , 1999

[9] Mampaey, "TINA for Services and Advanced Signaling and Control in Next-Generation Networks", IEEE Communications Magazine, October 2000, Vol. 38, No. 10

[10] Mampaey, A. Couturier, "Using TINA Concepts for IN Evolution", IEEE Communications Magazine, June 2000, Vol. 34, No. 6

[11] C. Abarca, P. Farley, J. Forslow, J. C. Garcia, T. Hamada, P. F. Hansen, S. Hogg, H. Kamata, L. Kristiansen, C. A. Licciardi, H. Mulder, E. Utsunomiya, M. Yates, "TINA Service Architecture", Version 5.0, June 1997, http://www.tinac.com

[12] J. Bloch, How to Design a Good API and Why it Matters, noiembrie 2006

[13] WCDMA W11 RAN Operation LZU 1087886 R2A Ericsson AB 2011

[14] wwww.ericssonacademy.ro Ericsson Academy

[15] https://netbeans.org/kb/docs/ide/oracle-db.html

[16] http://www.3gpp.org/specifications

[17] http://www.3gpp.org/ftp/Information

[18] http://www.3gpp.org/ftp/Specs/html

[19] http://en.wikipedia.org/wiki/Web_service,

[20] http://www.3gpp.org/ftp/Specs/html defines the architecture enhancements for non-3GPP accesses.

[21]https://www.google.ro/url?sa=t&rct=j&q=&esrc=s&source=web&cd=13&cad=rja&uact=8&ved=0CFsQFjAM&url=http%3A%2F%2Fwww.3gpp.org%2Ftechnologies%2Fkeywords-acronyms%2F100-the-evolved-packet-core&ei=GwqnU_-aFKHa0QWHrIGwBA&usg=AFQjCNGvV0kVWBS1S-GoIO2DhWLgaybdmg

[22] http://www.tutorialspoint.com/lte/lte_network_architecture.htm

[23] http://www.danielbuca.ro/online-related/proiectare-de-aplicatii-online-arhitectura-orientata-pe-servicii-web-1-85.html

[24] E. Marza, Radiocomunicaii mobile, EOU, Timișoara, 2001

Anexa 1 Codul Sursa al aplicatiei

import java.io.IOException;

import javax.microedition.lcdui.*;

import javax.microedition.midlet.MIDlet;

public class HelloMIDlet extends MIDlet implements CommandListener {

private Display display;

MIDlet midlet;

private Alert alHelp;

Displayable next = null;

private Command exitCommand = new Command("Exit", Command.EXIT, 1);

private Command viewCommand = new Command("View", Command.OK, 1);

private Command backCommand = new Command("Back", Command.OK, 1);

private Command goCommand = new Command("Login", Command.OK, 1);

private Form mainForm;

private Form loginForm;

private TextField fldUser = new TextField("Username:", "a", 50, TextField.ANY);

private TextField fldPass = new TextField("Password:", "a", 50, TextField.PASSWORD);

private TextField tf1 = new TextField("Strada", "Dinicu Golescu", 50, TextField.ANY);

private TextField tf2 = new TextField("Oras", "Bucuresti", 50, TextField.ANY);

private String st1, st2;

public static String defaultURL = "http://localhost/mob/index.php";

public HelloMIDlet() {

display = Display.getDisplay(this);

midlet = this;

}

public void startApp() {

loginForm = new Form("Login");

loginForm.append(fldUser);

loginForm.append(fldPass);

loginForm.addCommand(goCommand);

loginForm.setCommandListener(this);

mainForm = new Form("Addresa");

mainForm.append(tf1);

mainForm.append(tf2);

mainForm.addCommand(viewCommand);

mainForm.addCommand(exitCommand);

mainForm.setCommandListener(this);

display.setCurrent(loginForm);

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

public int getScreenHeight() {

return display.getCurrent().getHeight();

}

public int getScreenWidth() {

return display.getCurrent().getWidth();

}

public void commandAction(Command c, Displayable s) {

if (c == viewCommand) {

st1 = tf1.getString();

st1 = utils.replaceAll(st1, " ", "%2B");

st2 = tf2.getString();

st2 = utils.replaceAll(st2, " ", "%2B");

String address = st2 + "," + st1;

String AdressData = st1 + "|" + st2;

String coord = "";

try {

coord = utils.doHttpRequest("geocode", address);

} catch (IOException e) {

coord = "";

}

if (coord.length() > 10) {

next = new loadCMarker(midlet, mainForm, coord, AdressData);

display.setCurrent(next);

} else {

alHelp = new Alert("Info", "Eroare Geocodare Adresa!", null, AlertType.ERROR);

display.setCurrent(alHelp);

}

} else if (c == backCommand) {

display.setCurrent(mainForm);

} else if (c == goCommand) {

//request de intoarcere user si pass din la baza de data

String cx = "";

try {

cx = utils.doHttpRequest("auth", fldUser.getString() + "|" + fldPass.getString());

} catch (IOException e) {

cx = "";

}

if ("ok".equals(cx)) {

display.setCurrent(mainForm);

} else {

fldUser.setString("");

fldPass.setString("");

alHelp = new Alert("Info", "Eroare Autentificare !", null, AlertType.WARNING);

display.setCurrent(alHelp);

}

} else {

destroyApp(false);

notifyDestroyed();

}

}

}

Anexa 2

/*

* To change this template, choose Tools | Templates

* and open the template in the editor.

*/

package hello;

import com.jappit.midmaps.googlemaps.*;

import java.io.IOException;

import javax.microedition.lcdui.*;

import javax.microedition.midlet.MIDlet;

import java.util.Vector;

import org.json.me.*;

/**

*

*

*/

public class loadCMarker extends Canvas implements GoogleStaticMapHandler, CommandListener {

GoogleMaps gMaps = null;

GoogleStaticMap map = null;

Displayable testListScreen;

MIDlet midlet;

ImageItem mapItem;

String AdressData = "";

private TextBox textBox;

Command zoomInCommand, zoomOutCommand, back, exit;

private Command loadCommand = new Command("Load", Command.OK, 1);

private Command RBSCommand = new Command("Afisare NodeB", Command.OK, 1);

private Command RNCCommand = new Command("Afisare RNC", Command.OK, 1);

private Command CELCommand = new Command("Afisare Cell", Command.OK, 1);

private Command INVCommand = new Command("Afisare INV", Command.OK, 1);

private Command exitInv = new Command("Exit", Command.BACK, 1);

static String API_KEY = "";

public loadCMarker(MIDlet m, Displayable testListScreen, String coord_str, String AdressData) {

//super("Map View");

double lat;

double lng;

this.midlet = m;

this.AdressData = AdressData;

this.testListScreen = testListScreen;

Vector data = new Vector();

//this.addCommand(loadCommand);

this.addCommand(RBSCommand);

this.addCommand(RNCCommand);

this.addCommand(INVCommand);

this.addCommand(CELCommand);

this.addCommand(back = new Command("Back", Command.BACK, 1));

this.addCommand(zoomInCommand = new Command("Zoom in", Command.OK, 1));

this.addCommand(zoomOutCommand = new Command("Zoom out", Command.OK, 2));

String[] coords = utils.Split(coord_str, ",");

lat = Double.parseDouble(coords[0]);

lng = Double.parseDouble(coords[1]);

GoogleMapsCoordinates coord = new GoogleMapsCoordinates(lat, lng);

setCommandListener(this);

mapItem = new ImageItem("Loading map…", null, Item.LAYOUT_TOP, "Sample map");

//this.append(mapItem);

gMaps = new GoogleMaps();

map = gMaps.createMap(getWidth(), getHeight(), GoogleStaticMap.FORMAT_PNG);

map.setHandler(this);

map.setCenter(coord);

map.setZoom(15);

GoogleMapsMarker redMarker = new GoogleMapsMarker(coord);

redMarker.setColor(GoogleStaticMap.COLOR_RED);

redMarker.setSize(GoogleMapsMarker.SIZE_MID);

map.addMarker(redMarker);

map.update();

}

public void GoogleStaticMapUpdateError(GoogleStaticMap map, int errorCode, String errorMessage) {

System.out.println("map error: " + errorCode + ", " + errorMessage);

}

public void addMarker(String coord_str, String color) {

String[] coords = utils.Split(coord_str, ",");

double lat = Double.parseDouble(coords[0]);

double lng = Double.parseDouble(coords[1]);

GoogleMapsCoordinates coord = new GoogleMapsCoordinates(lat, lng);

GoogleMapsMarker redMarker = new GoogleMapsMarker(coord);

redMarker.setColor(color);

redMarker.setSize(GoogleMapsMarker.SIZE_MID);

map.addMarker(redMarker);

}

public void drawMarkersFromJson(String cx, String element){

boolean result = false;

String color = GoogleStaticMap.COLOR_RED;

if("RBSCommand".equals(element)){

color = GoogleStaticMap.COLOR_BLUE;

} else if ("RNCCommand".equals(element)){

color = GoogleStaticMap.COLOR_GREEN;

} else {

color = GoogleStaticMap.COLOR_RED;

}

try {

JSONObject jobj = new JSONObject(cx);

result = true;

JSONArray coordList = jobj.getJSONArray("list");

if (coordList != null) {

for (int n = 0; n < coordList.length(); n++) {

JSONObject entry = coordList.getJSONObject(n);

String coord_str = entry.getString("coord");

addMarker(coord_str,color);

}

} else {

System.out.println("Err Json Parse!");

}

map.update();

} catch (JSONException ex) {

result = false;

}

}

public void GoogleStaticMapUpdated(GoogleStaticMap map) {

System.out.println("map ok");

mapItem.setImage(map.getImage());

mapItem.setLabel("");

repaint();

}

protected void paint(Graphics g) {

map.draw(g, 0, 0, Graphics.TOP | Graphics.LEFT);

}

protected void keyPressed(int key) {

int gameAction = getGameAction(key);

if (gameAction == Canvas.UP || gameAction == Canvas.RIGHT || gameAction == Canvas.DOWN || gameAction == Canvas.LEFT) {

map.move(gameAction);

}

}

public void commandAction(Command c, Displayable d) {

if (c == zoomInCommand) {

map.zoomIn();

} else if (c == zoomOutCommand) {

map.zoomOut();

}

if (c == back) {

Display.getDisplay(midlet).setCurrent(testListScreen);

}

if (c == loadCommand) {

String cx = "";

try {

cx = utils.doHttpRequest("geocode", "Nordului, Bucuresti");

} catch (IOException e) {

cx = "";

}

}

if (c == RBSCommand) {

String cx = "";

String param = AdressData;

try {

cx = utils.doHttpRequest("RBSCommand", param);

} catch (IOException e) {

cx = "";

}

drawMarkersFromJson(cx,"RBSCommand");

}

if (c == RNCCommand) {

String cx = "";

String param = AdressData;

try {

cx = utils.doHttpRequest("RNCCommand", param);

} catch (IOException e) {

cx = "";

}

drawMarkersFromJson(cx,"RNCCommand");

}

if (c == CELCommand){

String cx = "";

String param = AdressData;

try {

cx = utils.doHttpRequest("CELCommand", param);

} catch (IOException e) {

cx = "";

}

textBox = new TextBox("Celule", cx, 1500, TextField.ANY);

textBox.addCommand(exitInv);

textBox.setCommandListener(this);

Display.getDisplay(midlet).setCurrent(textBox);

}

if (c == INVCommand) {

String cx = "";

String param = AdressData;

try {

cx = utils.doHttpRequest("INVCommand", param);

} catch (IOException e) {

cx = "";

}

textBox = new TextBox("Inventar", cx, 1500, TextField.ANY);

textBox.addCommand(exitInv);

textBox.setCommandListener(this);

Display.getDisplay(midlet).setCurrent(textBox);

}

if (c == exitInv) {

Display.getDisplay(midlet).setCurrent(this);

}

}

}

Anexa 3

/*

* To change this template, choose Tools | Templates

* and open the template in the editor.

*/

package hello;

import java.io.IOException;

import java.io.InputStream;

import java.io.OutputStream;

import java.util.Vector;

import javax.microedition.io.Connector;

import javax.microedition.io.HttpConnection;

/**

*

*/

public class utils {

public static String replaceAll(String text, String searchString, String replacementString) {

StringBuffer sBuffer = new StringBuffer();

int pos = 0;

int EOF = – 1;

while ((pos = text.indexOf(searchString)) != EOF) {

sBuffer.append(text.substring(0, pos)).append(replacementString);

text = text.substring(pos + searchString.length());

}

sBuffer.append(text);

return sBuffer.toString();

}

public static String searchlat(String text, String searchString) {

int pos = 0;

int EOF = – 1;

int end = 0;

end = text.indexOf("</lat>");

if ((pos = text.indexOf(searchString)) != EOF) {

text = text.substring(pos + searchString.length() + 1, end);

}

StringBuffer result = new StringBuffer();

result.append(text);

return result.toString();

}

public static String searchlng(String text, String searchString) {

int pos = 0;

int EOF = – 1;

int end = 0;

end = text.indexOf("</lng>");

if ((pos = text.indexOf(searchString)) != EOF) {

text = text.substring(pos + searchString.length() + 1, end);

}

StringBuffer result = new StringBuffer();

result.append(text);

return result.toString();

}

public static String[] Split(String splitStr, String delimiter) {

StringBuffer token = new StringBuffer();

Vector tokens = new Vector();

// split

char[] chars = splitStr.toCharArray();

for (int i = 0; i < chars.length; i++) {

if (delimiter.indexOf(chars[i]) != -1) {

// we bumbed into a delimiter

if (token.length() > 0) {

tokens.addElement(token.toString());

token.setLength(0);

}

} else {

token.append(chars[i]);

}

}

// don't forget the "tail"…

if (token.length() > 0) {

tokens.addElement(token.toString());

}

// convert the vector into an array

String[] splitArray = new String[tokens.size()];

for (int i = 0; i < splitArray.length; i++) {

splitArray[i] = (String) tokens.elementAt(i);

}

return splitArray;

}

static public String urlEncode(String sUrl) {

StringBuffer urlOK = new StringBuffer();

for (int i = 0; i < sUrl.length(); i++) {

char ch = sUrl.charAt(i);

switch (ch) {

case '<':

urlOK.append("%3C");

break;

case '>':

urlOK.append("%3E");

break;

case '/':

urlOK.append("%2F");

break;

case ' ':

urlOK.append("%20");

break;

case ':':

urlOK.append("%3A");

break;

case '-':

urlOK.append("%2D");

break;

default:

urlOK.append(ch);

break;

}

}

return urlOK.toString();

}

static public String doHttpRequest(String op, String var) throws IOException {

HttpConnection httpConn = null;

String url = HelloMIDlet.defaultURL + "?op=" + op + "&param=" + urlEncode(var);

String response = "";

InputStream is = null;

OutputStream os = null;

System.out.println(url);

try {

// Open an HTTP Connection object

httpConn = (HttpConnection) Connector.open(url);

// Setup HTTP Request

httpConn.setRequestMethod(HttpConnection.GET);

httpConn.setRequestProperty("User-Agent",

"Profile/MIDP-1.0 Confirguration/CLDC-1.0");

// This function retrieves the information of this connection

getConnectionInformation(httpConn);

int respCode = httpConn.getResponseCode();

if (respCode == httpConn.HTTP_OK) {

StringBuffer sb = new StringBuffer();

os = httpConn.openOutputStream();

is = httpConn.openDataInputStream();

int chr;

while ((chr = is.read()) != -1) {

sb.append((char) chr);

}

System.out.println(op + " " + sb.toString());

response = sb.toString();

} else {

// System.out.println("Error in opening HTTP Connection. Error#" + respCode);

}

} finally {

if (is != null) {

is.close();

}

if (os != null) {

os.close();

}

if (httpConn != null) {

httpConn.close();

}

}

return response;

}

static void getConnectionInformation(HttpConnection hc) {

}

}

Anexa 4-Troubleshooting

In imaginea de mai jos este prezentat sistmul de monitorizare in timp real al alarmelor retelei H3G Ericsson Italia.

Fig1.Alarm List Viewer(ALV)[WCDMA W11 RAN Operation LZU 1087886 R2A]

In interfata CEX(Common Explorer) avem posibiliata de a vedea stare unei statii mobile si a celulelor. Putem efectua investigatii asupra statiilor(nodeb/bts) si la cerere putem bloca/debloca celule, restarta nodeb-ul,etc.

Fig.2 Cautarea NodeB-ului[WCDMA W11 RAN Operation LZU 1087886 R2A]

Fig.3. Cautarea si afisarea caii in toolul N&SIS[WCDMA W11 RAN Operation LZU 1087886 R2A]

In figura 4 este afisat MiniLink Craft sau SoEM este un tool prin care se pot configura si monitoriza radio link-uri.

Fig.4 Parametri gasiti cu tool-ul SoEM[WCDMA W11 RAN Operation LZU 1087886 R2A]

Figura 5 este prezentat Logbook SMC care este o baza de date unde sunt stocate informatii despre nume, locatie si alte informatii despre un nodeB.

Fig.5 Cautarea Informatiilor dorite WCDMA W11 RAN Operation LZU 1087886 R2A]

Figura 6 prezinta modul de gestionare al alarmelor cu ajutorul tool-ului OMAR si trimiterea lor catre inginerul de teren(FSA) pentru a fi rezolvata.

Fig 6 Crearea Troubkleticket-ului in OMAR WCDMA W11 RAN Operation LZU 1087886 R2A]

Figura 7 ne arata cum ajunge problema gestionata de NOC si forma in care o primeste inginerul de teren.

Fig.7 Trimiterea TT-ului in WFM catre FSA. WCDMA W11 RAN Operation LZU 1087886 R2A]