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:
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.
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
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.
Joonis 4. HLRi ja MSC algatatud USSD sessioonide info liikumise diagrammid
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 reiim, 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