Menüü
· Viimane number
· A&A konverentsi slaidid
· Küberturve
· Tudengitelt
· E-õpe
· Videomaterjalid
· Avalikud loengud
· Ilmunud numbrid
· Magistrirubriik
· Teemad
· Otsi
· Tellimine
· Küsitlused
· Soovita meid
· Tagasiside
· Top 10
· Statistika
· Toimetuskolleegium

Logi sisse
Kasutajanimi

Parool

Registreeri kasutajaks
Unustasid parooli?

Mobiilsed sisuteenused ja USSD tehnoloogiad
Postitatud: Friday, October 15 @ 17:47:49 EEST by Toomas Ruuben

Side

SIDE 3-04

1. SISSEJUHATUS 

Käesolev artikkel, kus käsitleme põhjalikumalt just USSDga (Unstructured Supplementary Service Data) seotud temaatikat, on jätkuks artiklile „Mobiilsed sisuteenused ja GSM-tehnoloogiad“. Nagu juba mainitud, võiks USSD eestikeelne vaste kõlada “mittestruktureeritud andmetega lisateenused“ ning olla kasutusel nii infoteenuste pakkumisel kui ka telemaatikaseadmete juhtimisel. Võimalikeks kasutusvaldkondadeks on infomenüüd, koduvalvesüsteemid, tõkkepuude ja kõikvõimalike muude seadmete distantsjuhtimine jne. USSD tehnoloogia abil on võimalik koostada menüüpõhiseid teenuseid, kuid samas ei pea kasutatav telefon sisaldama lehitsejat (WAP, STK), mis tähendab, et võime menüüpõhised teenused tuua ka kõige lihtsamatesse telefonidesse. 

2. ÜLEVAADE USSD-TEHNOLOOGIAST 

2.1. PÕHILISED OMADUSED 

USSD-tehnoloogiat on kirjeldatud GSM-standardi dokumentides GSM 02.90 ja GSM 03.90. See on GSM infrastruktuuri osa ja oli esmaselt mõeldud GSM lisateenuste juhtimiseks (kõnede suunamised jne). Alles tänapäeval on seda hakatud kasutama erinevate lisateenuste pakkumiseks (info, telemaatika jne). Küllap on lugeja juba märganud operaatorite infovoldikutes kombinatsiooni *100# või midagi analoogilist. Suureks eeliseks on asjaolu, et puudub igasugune vajadus telefoni spetsiaalseks seadistamiseks ning teenused on kohe kasutatavad. Muidugi ei kehti see täiturmehhanisme juhtivate kontrollerite kohta. USSD töötab praktiliselt kõikides olemasolevates GSM-telefonides. 

USSD on loomult sessioonipõhine ja võimaldab kiiret andmevahetust terminali (mobiiltelefon) ja rakenduse vahel. See annab hea võimaluse interaktiivsete teenuste loomiseks. Raadioühendus hoitakse  avatud,  kuni  selle  vabastab  rakendus,  klient või  ületatakse etteantud ajalised piirid (timeout). 

Informatsiooni edastamiseks (nimetatakse ka USSD stringideks) kasutatakse signaliseerimiskanalit (SS7) ja seega ei koorma see kõnekanaleid. USSD sessiooni võib algatada võrk või abonent. Kui infoteenuste korral algatab USSD sessiooni harilikult abonent, siis telemaatikateenuste korral nimelt rakendus (antakse näiteks käsk täiturmehhanismile). Muidugi on kasutusel ka vastupidised juhud. USSD-l ülesehitatud sisuteenused võivad olla (ja tavaliselt ongi) menüüpõhised, kuid samas on võimalus siseneda soovitud menüüvalikusse ka otse, sisestades etteantud USSD stringi. Kuna USSD-põhistes menüüdes jääb navigeerimine mugavuselt alla WAPile ja STK-le, on eelmainitu hea omadus. USSD-põhiste päringute vastussõnumid (ka menüüd) tulevad otse telefoni ekraanile. Neid ei salvestata telefoni ega SIM-kaardi mällu, kuigi on olemas ka erandeid. Kuna USSD päringud suunatakse alati telefoni kasutaja koduregistrisse (HLR), siis on USSD-l baseeruvaid teenuseid võimalik kasutada nn roaming-võrgus. 

2.2. PUUDUSED 

Muidugi on USSD-l ka puudusi. Üheks on navigeerimise kohmakus. USSD-l ei ole lehitsejat (browser). Menüü valikuks ei liiguta mitte kursoriga linkidel (nagu WAPis), vaid klaviatuurilt tuleb sisestada menüüvaliku järjekorranumber ning siis see ära saata. Teiseks oluliseks puuduseks on krüptimisvõimaluse puudumine. Seega pole võimalik luua kõrget turvalisust nõudvaid sisuteenuseid. Samuti pole USSD-d võimalik kasutada kõne algatamiseks kliendi telefonilt ning ka vastuste või menüüde maht on piiratud (125/182 märki). 

2.3. TÖÖPÕHIMÕTE 

USSD-l baseeruvate teenuste loomisel on keskseks üksuseks USSD-lüüs (USSD Gateway), mis suunab läbi GSM-võrgu saabunud USSD päringud teenusepakkuja serverisse. Vastused USSD päringutele võivad olla edastatud läbi sama USSD-lüüsi või ka muul moel (MMS, SMS). USSD-lüüsi ja teenusepakkuja serveri vaheliseks infovahetuseks on paljudel juhtudel kasutusel protokollid CIMD2 ja SMPP. On olemas ka süsteeme, kus lihtsuse mõttes kasutatakse XML-vormingut. Arhitektuur oleks järgmine: 

Frame2.GIF

Joonis 1. USSD-l baseeruvate teenuste lihtsustatud tehniline arhitektuur

Vaatleme, kuidas näevad välja mobiiltelefoni ja võrgu (rakenduse) algatatud USSD sessioonid. 


Mobiiltelefoni algatatud USSD sessioon 


1. Klient sisestab oma mobiiltelefoni klaviatuurilt USSD stringi (käsu) stiilis *XXX#, kusjuures XXX on teenuse number. Teenuste numbrite vahemik on üldiselt kindlaks määratud (100 149). 

2. Olles pakutava teenusega tuttav, võib klient sisestada ka *XXX*Y*Z#, kusjuures Y ja Z määravad teenuse alammenüüd või mingid muud parameetrid. 

3. USSD päringuga saadetakse kaasa telefonis kasutatava tähestiku ja keele tunnused, mida HLR kontrollib. Kui HLR ei tunnista vastavat tähestikku, saadetakse tagasi veateade. 

4. Kui mobiiltelefon tuvastab, et kasutaja sooritatud toiming on USSD päring, võtab telefon ühenduse keskjaamaga, edastab USSD stringi ja jääb ootama vastust.  

5. Vastuse ootamise ajal võib toimuda ka võrgu poolt saadetud USSD päringu või kinnitusteate töötlemine. Pärast vahepäringu töötluse lõppu võib telefon ootamist jätkata. 

6. Mobiiltelefon ei saa algatada kahte paralleelset USSD sessiooni. 

7. USSD päringu töötlemine võib toimuda järgmistes võrgu komponentides: MSC (mobiilkeskjaam), VLR (külaliste register) ja HLR (koduregister).  


  • MSC. Kui HPLMN teenuskood eksisteerib, saadab MSC päringu muutmatul kujul edasi külaliste registrile. Vastasel korral töötleb MSC päringut ise. Edastamine VLRile toimub ka siis, kui MSC ei suuda tuvastada tähestikku. Kui üks osapooltest (MS või VLR) katkestab ühenduse, katkestab MSC automaatselt teise poole. Kui edastus külaliste registrile ebaõnnestub, saadetakse mobiiltelefonile veateade. 
  • VLR. Kui HPLMN teenuskood eksisteerib ja kasutaja ei viibi koduvõrgus, saadab VLR päringu muutmatul kujul edasi koduregistrile (HLR). Kui HPLMN teenuskood puudub või kasutaja on oma koduvõrgus, töötleb VLR päringut ise. Edastamine HLRile toimub ka siis, kui VLR ei suuda tuvastada kasutatavat tähestikku. Kui üks osapooltest (MSC või HLR) katkestab ühenduse, katkestab VLR automaatselt teise poole. Kui edastus koduregistrile ebaõnnestub, saadetakse mobiiltelefonile veateade. 
  • HLR töötleb päringut alati (edasisuunamist ei toimu). Kui HLR ei suuda tuvastada tähestikku, saadetakse kliendi telefonile veateade. 


8. USSD päringu töötlemiseks (iga eespool nimetatud komponendi juures) vajatakse konkreetset rakendust, mis peab tagama sessioonihalduse (algatamine-lõpetamine, lisapäringud kliendile ja andmebaasidesse) kliendiga. 

Joonisel 2 on toodud info kulgemise diagramm telefoni algatatud päringu (request) korral kui edaspidist informatsiooni kliendilt ei vajata. USSD päringu vastus (response) võib olla ka negatiivne ehk veateade. Joonisel 3 on toodud info kulgemise diagrammi näide telefoni algatatud päringu korral, kui vajatakse edaspidist informatsiooni. Sellisel juhul vastatakse päringule omakorda päringuga. Tüüpiliseks näiteks on valikmenüü edastamine kliendile. 

Märkusena niipalju, et konkreetne USSD teenusloogika ei asetse nimetatud võrgukomponentides. 

Frame5.GIF

OR1: HPLMN service code: Y/N 

OR2: HPLMN service code AND HPLMN: Y/N: Y/N 

Joonis 2. Info kulgemise diagramm telefoni algatatud päringu korral, kui edaspidist informatsiooni kliendilt ei vajata

Frame6.GIF

Joonis 3. Info kulgemise diagrammi näide telefoni algatatud päringu korral, kui vajatakse edaspidist informatsiooni

Võrgu algatatud USSD sessiooni 

1. Kõik eespool nimetatud võrgukomponendid võivad algatada USSD sessiooni/päringu telefoni (MS) suunal. 

2. Kui HLR juures olev rakendus soovib saata USSD päringu telefoni suunal, võtab HLR ühendust VLRiga (kuhu kasutaja on hetkel registreeritud), edastab päringu ning jääb ootama vastust. HLR vastutab seejuures ühenduse säilimise eest. Näiteks kui ta saab VLRilt vastuse USSD päringule ning edasist informatsiooni ei vaja, katkestab ta ühenduse. Samas aga kliendipoolse ühenduse katkestamise korral informeerib ta sellest rakendust. 

3. Teised komponendid (VLR ja MSC) toimivad üldjoontes samamoodi, kui need sisaldavad USSD rakendust. 

4. Nii VLR kui ka MSC võivad toimida kui USSD päringute vahendajad (kui USSD sessiooni algatajaks on HLR või VLR). 

5. Mobiiltelefon võib põhimõtteliselt igal ajal võtta vastu USSD päringu, välja arvatud juhul, kui hetkel on käimas sessioon mõne teise USSD rakendusega või toimub väljahelistamine. 

6. Kui mobiiltelefon ei toeta etteantud tähestikku, informeerib ta sellest võrku. 

7. Võrgupoolsel USSD sessiooni algatamisel kuvatakse telefoni ekraanile rakenduse saadetud tekst või menüü. Menüü korral oodatakse harilikult kliendipoolset valikut, lihtteksti korral katkestatakse koos saabunud teatega ka ühendus. 

Joonisel 4 on toodud HLRi ja MSC algatatud USSD sessioonide info liikumise diagrammid ning joonisel 5 on HLRi algatatud menüütaolise USSD sessiooni info liikumise diagrammid. 

Frame9.GIF

Joonis 4. HLRi ja MSC algatatud USSD sessioonide info liikumise diagrammid

Frame11.GIF

Joonis 5. HLR-i algatatud menüütaolise USSD sessiooni info liikumise diagrammid

3. CIMD2 PROTOKOLL JA SELLE USSD LAIENDUS 

CIMD2 on avatud protokoll, mis on ette nähtud sidepidamiseks välise rakenduse (PC) ja sõnumikeskuse vahel. Ta on täielikult kirjeldatud eraldi dokumentatsioonis Cimd Interface Specification (NOKIA). Nagu mainitud, saab teda kasutada nii SMSi- kui ka USSD-põhiste teenuste loomiseks. 

CIMD2 baseerub pakettide saatmisel ja vastuvõtmisel. Paketi struktuur on üldjoontes järgmine. 


        PÄIS            PARAMEETRID        LÕPP 

    <STX>ZZ:NNN<TAB> ... PPP: Parameetri väärtus <TAB> ... CC<ETX> 

Siinjuures: 

  • <STX>    Paketi algus 
  • <ETX>    Paketi lõpp 
  • ZZ           Operatsiooni kood 
  • NNN       Paketi number. Suuna eristamiseks kasutatakse paaris- ja paarituid pakette 
  • <TAB>    Eraldaja 
  • PPP        Parameetri number (nt telefoninumber, saadetav tekst jne) 
  • CC          Kontrollsumma. Arvutatakse baitide liitmise teel < STX>-st kuni <ETX>-2               baiti, lõigates ära MSB. Saadud tulemus esitatakse kahe ASCII sümbolina HEX-formaadis 

Iga saadetud või vastuvõetud pakett kinnitatakse vastuspaketiga (ACK). Vastuspaketi sisu võib olla positiivne või negatiivne ning rakendus peab oskama sellega arvestada.  

Pärast ühenduse loomist TCP/IP tasemel algab teadete edastamine/vastuvõtmine autoriseerimisega (ZZ väärtused vastavalt 01 ja vastusena 51), mille alusel määratakse ka konkreetne kasutaja profiil. Ühenduse variante on kolm: 

  • ainult teadete (SMS, USSD) saatmiseks (Send Only) 
  • saatmiseks ja vastuvõtmiseks (Receiving) 
  • info hankimine vastavalt päringutele (nn skaneeriv režiim, Querying). 

Kasutatavad operatsioonid on järgmised: 

 

SMSC 

USSD Center 

Type Operation (ZZ) 

Send Only 

Querying 

Receiving 

Send Only 

Receiving 

Login 

Logout 

Submit 

Enq.message status 

Delivery request 

Cancel 

Deliver message 

Deliver status report 

Set parametres 

Get parametres 

Alive 

+ Toetatud 

–  Ei ole toetatud 

* Toetatud, kuid üldjuhul pole kasutatav 

Nendest olulisemad ja sagedamini kasutatavad on järgnevad: 

  • Login/Logout – algatatakse rakenduse poolt. Kasutatakse autoriseerimiseks lühisõnumi- või USSD-keskuses. Logout pole harilikult otseselt nõutav, kuid korrektsuse mõttes oleks soovitav enne ühenduse katkestamist kasutada; 
  • Submit – algatatakse rakenduse poolt. Kasutatakse lühisõnumi või USSD stringi edastamiseks lühisõnumi- või USSD-keskusele. Oluline on siinjuures märkida, et positiivse vastuse saamine Submit-operatsioonile ei tähenda seda, et teade adressaadini jõudis. Selle jaoks on eraldi kinnitusteated. Submit-operatsiooniga pannakse sõnum tegelikult vastava keskuse sisemisse järjekorda ning tema toimetamisega adressaadini tegeleb keskus juba iseseisvalt (sh kordussaatmised ebaõnnestumiste korral); 
  • Deliver message – algatatakse lühisõnumi- või USSD-keskuse poolt. Selle operatsiooniga toimetatakse sõnum adressaadini. Teenuste serveri seisukohalt on need siis telefonidelt saabunud sõnumid; 
  • Deliver status report – algatatakse lühisõnumi- või USSD-keskuse poolt. Submit-operatsiooni teatud parameetrite abil saab tellida kinnitusteate sõnumi reaalse jõudmise kohta telefonile. Võimalik on ette anda ka tingimused, mispuhul kinnitusteade saadetakse ja mispuhul mitte. Põhiliselt kasutatakse signaalina sõnumi jõudmise kohta adressaadi telefonile, kuid võib olla kasutusel ka juhuks, kui sõnum aegub lühisõnumi- või USSD-keskuses; 
  • Alive – võib olla algatatud nii keskuse kui ka rakenduse poolt. Kasutatakse lühisõnumi- või USSD-keskuse ja rakenduse vahelise kanali kontrolliks ja ka ülalhoidmiseks. Praktikas on esinenud probleeme (eriti WAN-võrkude korral), kus side katkeb või katkestatakse, kuid üks või teine osapool ei saa sellest teada. See omakorda põhjustab probleeme sõnumite edastamisel. Alive-operatsioonide kasutamine vähendab oluliselt selliste situatsioonide tekkimise võimalust. 

Harvemini kasutatavad on 

  • Enq. message status võimaldab saada informatsiooni Submit-operatsiooniga edastatud sõnumi kohta 
  • Cancel  võimaldab tühistada/eemaldada Submit-operatsiooniga edastatud sõnumi. See operatsioon on kasutatav vaid siis, kui sõnum on veel adressaadini toimetamata. Kasutatakse viitega edastuste korral 
  • Delivery request nõue sõnumite toimetamiseks adressaadini (skaneeriv süsteem) 
  • Set parameters, Get parameters parameetrite edastamiseks ja vastuvõtmiseks lühisõnumi- või USSD-keskusest. 

Nagu tabelist näha, on kasutatavate operatsioonide arv USSD korral mõnevõrra väiksem. 

Operatsioonide teatud parameetrid sõltuvad sellest, kas tegu on USSD või SMS edastusega. 

Tulenevalt asjaolust, et USSD pole Store and Forward-tüüpi edastus, pole USSD korral võimalik kasutada näiteks 

  • sõnumite kehtivusaja (SMSC-s) määranguid (Validity period)  
  • sõnumite viitega edastust (ei absoluutset ega ka suhtelist) 
  • keskusesse saadetud (Submitted), kuid mitte veel edastatud (Delivered) sõnumite tühistamist (Cancel) 
  • sõnumi prioriteedi määranguid 
  • jne. 

Samas, USSD-spetsiifilised ja SMSi korral on mittekasutatavad 

  • transpordi tüüp (SMS, USSD) 
  • USSD teate tüüp: 
  • 1 – USSD Process Request 
  • 2 – USSD Request 
  • 3 – USSD Notify 
  • 4 – USSD ACK 
  • 5 – USSD Release 
  • 6 – USSD Process Request ACK 
  • USSD dialoogi ID 
  • USSD dialoogi ajaline limiit (Timeout) 
  • USSD faas (Phase) (faas 1, 2 või tundmatu) 
  • teenuse kood. 

Olulisemad parameetrid on veel 

  • teate saaja telefoninumber (Destination address) 
  • teate saatja telefoninumber (Originating address, pole kohustuslik) 
  • User Data (parameeter PPP=033). Selle kaudu edastatakse ka USSD stringid, mida rakendus peab töötlema. 

Selle osa lõpetuseks veel üks näide CIMD-protokolli kasutamise kohta. 

SMSi saatmine: 

<STX>03:003<TAB>021:1234567890<TAB>050:167<TAB>033:Tere hommikust! <TAB><CS><ETX> 

ACK: 

<STX>53:003<TAB>021:1234567890<TAB>060:971111131245<TAB><CS><ETX> 

03– Submit-operatsioon.  

021 – Saaja aadress (telefoninumber) 

050 – Sõnumi kehtivusaeg SMSCs. Arv 167 konverteeritakse SMSC reaalseks ajaühikuks 

033 – Edastatav tekst 

53 – Submit-vastus. 

060 – Ajatempel (millal käsk SMSC poolt vastu võeti) “yymmddhhmmss”. 

4. TEENUSTE LOOMINE, KASUTADES USSD-TEHNOLOOGIAT 

USSD-tehnoloogial põhinevad teenused võivad olla operaatoripõhised või kolmandate osapoolte omad. Esmasteks tingimusteks sisuteenuste loomisel on muidugi turunduslikud aspektid. Kui nendega on kõik korras, siis tehnilise poole pealt on vajalikud eeltingimused: 

  • operaatoripoolne teenusnumbri reserveerimine 
  • loodav teenus võib olla ka olemasoleva teenuse (infomenüü) osa 
  • USSD-keskuse konfigureerimine (teenusnumbri seostamine kanaliga, kasutaja profiil jne) 
  • USSD-keskuse ja teenust pakkuva serveri vahelise kanali (lingi) tekitamine 
  • turvaküsimused (eriti kui teenust pakkuv arvuti ei asu operaatori sisevõrgus). 

Kui eespool nimetatud tingimused on täidetud, sõltub edaspidine sellest, millist protokolli (SMPP, CIMD2) konkreetne USSD-keskus toetab. Loodav teenus peab oskama vastavat protokolli kasutada. Kuna nende protokollide käsitlemine pole just kõige lihtsam ülesanne, siis võib operaator välja pakkuda ka mingi lihtsama, näiteks XMLil põhineva liidese (sisuliselt CIMD2/SMPP à XML konverter), mis töötab üle HTTP. 

Teenusloogika USSD korral võib välja näha järgmine: 

1. Teenusprogrammi saabub USSD päring. 

2. Teenusprogramm analüüsib USSD stringi (parameeter 033 CIMD2 korral) ja vastavalt teenusloogikale saadab vastuse. Näiteks:  

  • tüübina 2 („USSD Request“, menüü edastamiseks)  
  • tüübina 3 („USSD Notify“, lõpliku vastuse edastamiseks). 

Vastavad tüüpide tähendused võivad sõltuvalt operaatori platvormist varieeruda. Teenuste loomisel tuleks selles osas operaatoriga konsulteerida. 

Menüü USSD aknas on lihtne ning näeb üldjoontes välja järgmine: 

1. Valik_1 

2. Valik_2 

3. Valik_3 

………… 

Kui klient soovib siseneda menüüs „Valik_2“-te, peab ta valima klaviatuurilt numbri ’2’ ning vajutama „helistamise“ (roheline) klahvile. Konkreetne käitumismudel sõltub siiski kasutatavast telefonist. „Valik_2“ alt võib avaneda omakorda alammenüü. Kliendi asukoha kohta võimalikus USSD menüüde struktuuris saab arvestust pidada vaid rakendus. Seega jääb sessioonihaldus kui selline teenusprogrammi kanda.  

Kui teenusprogramm peab ühte otsa pidi sidet USSD-keskusega, siis teistpidi harilikult andmebaasiga või ka teiste seadmetega nagu SMSC, arveldussüsteemid jne. 

Teenuste maksustamiseks on mitu võimalust. Harilikult maksab klient sisu eest, mitte päringu enda eest. Maksustamine võib toimuda 

  • kasutades protokollide (CIMD2 SMPP) selleks otstarbeks ette nähtud välju (tariifiklass) 
  • kui teenusprogrammil on eraldi liides operaatori arveldussüsteemi 
  • kui on kasutusel näiteks XMLi-laadne liides USSD-keskuse ja teenusprogrammi vahel, võib maksustamisinfo olla liidetud XMLi koosseisu. 

5. KOKKUVÕTE 

USSD-l põhinevaid teenuseid on nüüdseks loodud juba mitu. Reaalselt eksisteerivad erinevate mobiilsideoperaatorite infomenüüd, koduvalvesüsteemid, mobiilne parkimine jne. Hetkel on küllalt raske prognoosida, kui laialdaselt tavakliendid USSD-d kasutama hakkavad. Alternatiive on palju ja peale on tulemas 3G. Statistika näitab, et infoteenuste tarbimisel on liidripositsioonile tõusnud WAP. Temale järgnevad SMS, USSD ja STK. WAPi edule on kindlasti kaasa aidanud WAPi toetavate telefonide laialdane levik ning käsitlemise lihtsustumine (näiteks WAP-seadete automaatne laadimine). STK levikut piirab hetkel kindlasti see, et olemasolevad kliendid peavad oma SIM-kaardid välja vahetama. Kui võrrelda omavahel sisuteenuste tarbimist üle SMSi ja USSD, siis peab mainima, et USSD on ikkagi mugavam. Pole vaja sisestada pikki võtme- ja märksõnu ning neid meeles pidada. Võib siiski oletada, et USSD põhiliseks kasutusvaldkonnaks jääb seadmete distantsjuhtimine ning muu taoline. Infoteenuste valdkonnas on WAP väga tugevaks konkurendiks. 

Lõpetuseks sooviksin tänada Tallinna Tehnikaülikooli teadurit Aimur Rajat, kes oli artikli koostamisel nõu ja jõuga abiks. 

6. KIRJANDUS 

1. CIMD interface specification (Nokia Artuse SMS Center Release SC5B CD2) Nokia networks OY. 

2. Short Message Peer to Peer Protocol Specification v3.4. SMPP Developers Forum. Issue 1.2 

3. Digital cellular telecommunications system (Phase 2); Unstructured Supplementary Service Data (USSD)-Stage 1. GSM 02.90 version 4.1.1. ETSI. 

4. Digital cellular telecommunications system (Phase 2); Unstructured Supplementary Service Data (USSD)-Stage 2. GSM 03.90. ETSI. 

7. LÜHENDITE LOETELU (inglise keeles) 

ACK        Response message (acknowledgement) 

CIMD2        Computer Interface to Message Distribution 

ETSI        European Telecommunications Standards Institute 

GSM        Global System for Mobile Communications 

HLR        Home Location Register 

HPLMN        Home Public Land Mobile Network 

HTTP        Hypertext Transmission Protocol 

MMS        Multimedia Messaging Service 

MS        Mobile Station 

MSC        Mobile Switching Centre 

PC        Personal Computer 

PLMN        Public Land Mobile Network 

SIM        Subscriber Identity Module 

SMPP        Short Message Peer to Peer Protocol 

SMS        Short Message Service 

SMSC        Short Message Service Centre 

SS7        Signalling System Number 7 

STK        SIM ToolKit 

USSD        Unstructured Supplementary Service Data 

VLR        Visitor Location Register 

WAN        Wide Area Network 

WAP        Wireless Application Protocol 

XML        eXtensible Markup Language 


Toomas Ruuben
TTÜ raadio- ja sidetehnika instituudi doktorant 


 
Seotud lingid
· Veel Side


Kõige populaarsem artikkel kategoorias Side:
ATM-tehnoloogia ja selle kasutamine


Artikli reiting
Keskmine tulemus: 0
Hääled: 0

Oleks tore kui sa annaksid sellele artiklile oma hinnangu:

Super!
Väga hea
Hea
Keskmine
Halb





All logos and trademarks in the site are property of their respective owner(s). Comments are property of their posters, all the rest © 2003 by A&A
A&A elektrooniline väljaanne on valminud IT Kolledži toetusel.
Sait kasutab PHP-Nuke mootorit © 2002. Kõik õigused reserveeritud. PHP-Nuke on GNU/GPL litsensiga tasuta levitatav tarkvara.
Lehe loomiseks kulus: 0.137 sekundit