lyhennelmä - tkkbhca busy hour call attempts puheluyritysten lukumäärä kiiretunnin aikana cgi...
TRANSCRIPT
I
Lyhennelmä
Tekijä:
Työn nimi:
.
Päivämäärä:
Antti Paju
Tilaajanumeron siirrettävyys yhdistetyssä piiri- ja pakettikytkentäisessä
verkossa
3.12.2002 Sivumäärä: 86
Osasto:
Professuuri:
Sähkö- ja tietoliikennetekniikan osasto
S-38 Tietoverkkotekniikka
Työn valvoja:
Työn ohjaaja:
Prof. Raimo Kantola
DI Nicklas Beijar
Tilaajanumeron siirrettävyys on monissa maissa Suomi mukaan lukien varsin ajankohtainen
aihe. Suomessa Viestintävirasto on määrännyt, että GSM-numerot tulee olla siirrettäviä
operaattorilta toiselle 1.7.2003 lähtien. IP-pohjaisen televiestinnän yleistyessä tulee myös
tarpeelliseksi siirtää tilaajia televerkosta IP-verkkoon siten, että asiakas voi säilyttää vanhan
numeronsa. Tilaajalle teknologinen muutos ei ole motivaatio vaihtaa numeroa. Numeron
siirrettävyys edistää kilpailua telemarkkinoilla. Sen ansiosta myös asiakastyytyväisyys paranee.
Jos tilaaja muuttaa, hänen ei tarvitse vaihtaa puhelinnumeroa. Yritysasiakkaille voi aiheutua
merkittävästi esimerkiksi mainontaan liittyviä kuluja, jos puhelinnumerot muuttuvat. Numeron
siirrettävyydestä hyötyvät siis sekä yritys- että yksityisasiakkaat.
Nykyisin numeron siirrettävyys kiinteässä televerkossa on toteutettu IN-tekniikalla (Intelligent
Network). Tekniikassa on monia puutteita, joita tässä diplomityössä esitettävä ratkaisu pyrkii
korjaamaan esittämällä uuden ratkaisun, johon edelleen sisältyy kuitenkin IN-tekniikkaa jollakin
tavalla. Numeron siirrettävyyttä käsitellään palveluna, joka toteutetaan standardeilla
rajapinnoilla ja määrittelyillä. Tavoitteena on, että puhelu ohjataan suoraan siihen verkkoon,
jonka asiakkaana kutsuttu tilaaja on, eli ei siis minkään aiemmin tilaajaa palvelleen verkon
kautta. Numeron siirrettävyys vaatii muunnospalvelun, jossa looginen tilaajanumero kuvataan
topologiasidonnaiseen reititysosoitteeseen. Verkkojen yhteistoiminta edellyttää sellaista loogista
osoitteistusta, jota kaikki verkon päätelaitteet tukevat. Dominoivia ovat E.164-numerot johtuen
televerkon rajoitteista.
Toteutuksessa tiedonhallinta perustuu relaatiotietokantoihin, jotka tarjoavat tehokkaita
hakurakenteita sekä välineitä viite-eheyden automaattiseen ylläpitoon. Pääsyrajapintana
käytetään ODBC-rajapintaa (Open DataBase Connectivity). Sen avulla ratkaisusta voidaan tehdä
siirrettävä moniin kaupallisiin ja ei-kaupallisiin SQL-tietokantoihin. Tuloksena saadaan täysin
puheluita välittävän verkon teknologiasta riippumaton ratkaisu, jonka skaalautuvuus on
ylivertainen verrattuna aiemmin esiteltyihin numeron siirrettävyyden tiedonhallintaratkaisuihin.
Avainsanat: NP, SQL, ODBC, DNS, SIP, ISUP, IN, TRIP, BGP
II
Abstract
Author:
Name of thesis:
.
Date:
Antti Paju
Number Portability in Interconnected Circuit and Packet Switched
Networks
3.12.2002 Number of pages: 86
Faculty:
Professorship:
Department of Electrical and Communications Engineering
S-38 Networking Technology
Supervisor:
Instructor:
Prof. Raimo Kantola
Nicklas Beijar M.Sc. (Tech)
Number portability is quite a topical issue in several countries including Finland. In Finland the
communications regulatory authority (FICORA) has ordered the GSM numbers to be portable
from an operator to another from 1st of July 2003 onwards. As VoIP (Voice over IP) is getting
more common, a need arises to port subscribers from the SCN to the IP network so that a ported-
out subscriber can still keep his/her number. For a customer, the technological transition is not
any reason to change his/her telephone number. Number portability enhances competition in the
telecom markets and improves customer satisfaction. When a subscriber moves, his/her number
does not have to be changed. Changing the telephone number can cause e.g. significant
advertising costs to business customers. So, number portability is very useful for both business
and residential customers.
Nowadays, number portability is managed with IN technology (Intelligent Network). IN based
number portability has several drawbacks This thesis tries to fix them by introducing a new
solution, which still uses the existing IN technology some way. The management of number
portability is treated as an application, which is created using standard interfaces and definitions.
This thesis rejects the approach of routing the call into the donor’s network first. The aim is, that
the call is routed directly into the network where the called party is located. Number portability
requires a number translation service, which resolves the logical directory number into a routing
number, or to be more specific, into a routing address. Interoperability requires common
numbering between the SCN and IP networks. Due to the structure of PSTN, E.164 numbering is
used in both SCN and IP networks.
The solution utilizes relational databases for efficient database management. They provide very
scalable data structures and tools for automatic data integrity management. ODBC (Open
Database Connectivity) is selected as the access interface to relational databases. ODBC makes
the solution portable to many commercial and non-commercial SQL databases. As a result, we
get a service, which is independent on the carrier network, and the scalability of which knocks
previous database management solutions of number portability into a cocked hat.
Key words: NP, SQL, ODBC, DNS, SIP, ISUP, IN, TRIP, BGP
III
Alkulause
Tämä diplomityö on tehty Teknillisen korkeakoulun Tietoverkkolaboratorion IMELIO-projektissa.
Projektia rahoittivat TEKES, Nokia sekä Elisa Communications.
Haluan kiittää erityisesti työn valvoja professori Raimo Kantolaa sekä työn ohjaaja DI Nicklas
Beijaria. Heidän antamansa tuki ja ohjaus on ollut erittäin arvokasta koko projektin ajan. Kiitos
kuuluu myös Kimmo Pitkäniemelle, joka auttoi testiympäristön kokoamisessa sekä TkL Marko
Luomalle, jolta sain kriittistä tutkimukseen liittyvää palautetta projektin aikana. Haluan ilmaista
kiitokseni Teknillisen korkeakoulun Tietoverkkolaboratorion koko henkilökunnalle, joka muodosti
kannustavan työyhteisön.
Kolmas joulukuuta vuonna 2002 Espoossa
Antti Paju
IV
Sisällysluettelo
1 JOHDANTO..............................................................................................................................1
2 TYÖN TAUSTAT.....................................................................................................................4
2.1 NUMERON SIIRRETTÄVYYDELLE VAADITTAVA TEKNOLOGIA ............................................4
2.1.1 Piirikytkentäisessä verkossa .......................................................................................4
2.1.2 Internetissä .................................................................................................................4
2.2 SCN/IPTEKNOLOGIARAJAPINTA........................................................................................5
2.3 YHDYSKÄYTÄVÄN SIJAINTI ................................................................................................6
2.3.1 Ongelma......................................................................................................................6
2.3.2 Ratkaisut .....................................................................................................................6
2.4 TRIP....................................................................................................................................7
2.4.1 TRIP vs. BGP..............................................................................................................7
2.4.2 TRIP SCN/IP yhdyskäytävän sijaintiongelman ratkaisijana ......................................8
2.4.3 TRIP-tietokannat.........................................................................................................9
2.4.4 Päätösprosessi ..........................................................................................................10
2.4.5 TRIP:n heikkoudet ....................................................................................................11
2.5 AIEMMAT AIHEESEEN LIITTYVÄT TUTKIMUKSET .............................................................12
2.5.1 TRIP/CTRIP arkkitehtuuri........................................................................................12
2.5.2 iBGP .........................................................................................................................13
2.6 TRIP/CTRIP-RATKAISUN HEIKKOUDET ...........................................................................14
2.6.1 Aggregointi vaikeutuu...............................................................................................14
2.6.2 Tietokantojen kasvu ..................................................................................................16
2.6.3 Synkronointi ..............................................................................................................16
2.7 PÄÄMÄÄRÄT .....................................................................................................................16
3 RELAATIOTIETOKANNAT ...............................................................................................18
3.1 RELAATIOTIETOKANTOJEN RAKENNE...............................................................................18
3.2 TIEDON HAKU ...................................................................................................................19
3.2.1 Indeksointi.................................................................................................................19
3.2.2 Kyselyn käsittely .......................................................................................................20
3.2.3 Proseduurihaut .........................................................................................................22
3.2.4 Kyselyjen tallettaminen välimuistiin.........................................................................23
3.2.5 Datavälimuisti...........................................................................................................23
3.2.6 Redundanssi..............................................................................................................24
3.3 RELAATIOMALLI ...............................................................................................................25
3.3.1 Relaation määritelmä ...............................................................................................25
3.3.2 Tietokantarelaation matemaattinen määritelmä.......................................................26
4 ODBC – OPEN DATABASE CONNECTIVITY.................................................................28
V
4.1 MIKSI?...............................................................................................................................28
4.2 ODBC-RAJAPINTA ............................................................................................................29
4.2.1 ODBC-standardi .......................................................................................................29
4.2.2 ODBC:n komponentit................................................................................................30
4.3 ODBCKÄYTÄNNÖSSÄ ......................................................................................................32
4.3.1 ODBC-esimerkki .......................................................................................................32
4.3.2 ODBCINI-tiedosto ....................................................................................................33
4.3.3 JDBC – Java DataBase Connectivity........................................................................33
5 OSOITTEISTUS JA NIMEÄMINEN...................................................................................35
5.1 INTERNETIN NIMIPALVELU ................................................................................................35
5.2 ENUM...............................................................................................................................37
5.3 NUMERON SIIRRETTÄVYYS NYKYISIN...............................................................................38
5.4 NUMERON SIIRRETTÄVYYSGSM-VERKOSSA...................................................................39
6 NUMERON SIIRRETTÄVYYDEN TAVOITEARKKITEHTUURI ...............................40
6.1 KOMPONENTIT..................................................................................................................40
6.1.1 Arkkitehtuuri .............................................................................................................40
6.1.2 Monistetut päivitystietokannat ..................................................................................41
6.1.3 Luotettavuus..............................................................................................................42
6.2 TIETOKANNAT ...................................................................................................................42
6.2.1 Päivitystietokannat....................................................................................................42
6.2.2 Numerotietokannat....................................................................................................43
6.2.3 Vaihtelevan mittaiset numerot...................................................................................44
6.3 PUHELUN MUODOSTUS......................................................................................................45
6.3.1 Reititysosoitteen haku................................................................................................45
6.3.2 Luettelonumeroiden aggregoinnin vaikutus..............................................................46
6.3.3 Vaadittu transaktionopeus ja tietokantakyselyjen kuorman jako..............................47
6.3.4 Numerotietokantojen päivitys....................................................................................48
6.4 NUMERON SIIRRETTÄVYYSSCN/IPTEKNOLOGIARAJAPINNAN YLI .................................49
6.4.1 Numerointi ................................................................................................................49
6.4.2 Reititys.......................................................................................................................49
6.4.3 Puhelun muodostus ...................................................................................................50
7 TIETOKANTOJEN TOTEUTUS .........................................................................................52
7.1 TIETOKANTASUUNNITTELU...............................................................................................52
7.1.1 Mallinnus ..................................................................................................................52
7.1.2 Toteutus.....................................................................................................................52
7.2 KÄYTETYT OHJELMISTOT..................................................................................................53
7.2.1 Relaatiotietokannat vs. hakemistot............................................................................53
7.2.2 MySQL ......................................................................................................................54
7.2.3 Replikointi .................................................................................................................54
VI
7.3 NUMEROTIETOKANTA.......................................................................................................56
7.3.1 Sanallinen kuvaus .....................................................................................................56
7.3.2 Relaatiomalli.............................................................................................................56
7.3.3 Toteutus.....................................................................................................................57
7.3.4 Hakuoperaatio pisimmän osuman mukaan (peräkkäislähetys) ................................58
7.3.5 Hakuoperaatio pisimmän osuman mukaan (kertalähetys)........................................61
7.4 PÄIVITYSTIETOKANNAT ....................................................................................................64
7.4.1 Sanallinen kuvaus .....................................................................................................64
7.4.2 Relaatiomalli.............................................................................................................64
7.4.3 Toteutus.....................................................................................................................65
7.4.4 Numeropalvelimien päivitys .....................................................................................67
7.4.5 Päivitysten validointi ................................................................................................69
7.4.6 Numerotietokannan ja päivitystietokannan synkronointi .........................................71
8 RATKAISUN ARVIOINTI ...................................................................................................73
8.1 RATKAISUN TOIMIVUUS ....................................................................................................73
8.1.1 Relaatiotietokantojen suorituskyky...........................................................................73
8.1.2 ODBC-ohjelmistot ....................................................................................................74
8.1.3 Päivitysliikenteen volyymi.........................................................................................74
8.2 JÄRJESTELMÄN KÄYTTÖÖNOTTO......................................................................................75
8.2.1 Tietokantojen alustaminen........................................................................................75
8.2.2 Käyttöesimerkki ........................................................................................................76
8.2.3 Päivitysoperaatioiden laukaisu.................................................................................78
8.2.4 Operaattori/regulaattori-rajapinnan SQL-kyselyt....................................................79
8.3 SKAALAUTUVUUS .............................................................................................................79
8.3.1 Oletukset ...................................................................................................................79
8.3.2 Laskelmat..................................................................................................................80
9 JOHTOPÄÄTÖKSET............................................................................................................83
9.1 TEKNOLOGIA.....................................................................................................................83
9.2 NUMERON SIIRRETTÄVYYS TULEVAISUUDESSA...............................................................85
VII
Kuvien luettelo
Kuva 1.1. Tilaajan siirtyminen televerkossa .......................................................................................2
Kuva 2.1. TRIP-tietokannat ..............................................................................................................10
Kuva 2.2 TRIP/CTRIP-arkkitehtuuri [14] ........................................................................................12
Kuva 2.3 Täysin kytketty ratkaisu vs. reitityspeili...........................................................................13
Kuva 2.4 Puhelinverkko....................................................................................................................15
Kuva 3.1. Relaatiotietokannan rakenne ............................................................................................18
Kuva 3.2. MySQL: n suorituskyky ...................................................................................................19
Kuva 3.3. MySQL Insert...................................................................................................................21
Kuva 3.4. Toisteisuuden poistaminen ...............................................................................................24
Kuva 4.1 MySQL vs. PostgreSQL....................................................................................................28
Kuva 4.2. ODBC-viitemalli ..............................................................................................................31
Kuva 5.1. Hierakkinen DNS-kysely..................................................................................................35
Kuva 5.2. IN arkkitehtuuri ................................................................................................................38
Kuva 5.3. Numeron siirrettävyys GSM-verkossa .............................................................................39
Kuva 6.1. Tavoitearkitehtuurin komponentit ....................................................................................40
Kuva 6.2. Inkrementaalinen tietokantojen päivitys...........................................................................41
Kuva 6.3. Numerotietokannat ...........................................................................................................43
Kuva 6.4. Puhelun muodostus...........................................................................................................45
Kuva 6.5. Hajautettu numerotietokanta ............................................................................................47
Kuva 6.6. Esimerkki puhelun muodostuksesta .................................................................................51
Kuva 7.1 Esimerkki MySQL:n binäärilogi .......................................................................................55
Kuva 7.2. Numerotietokannan elementit ..........................................................................................56
Kuva 7.3. Numerotietokannan kuvaus ..............................................................................................57
Kuva 7.4. Esimerkkitietokanta..........................................................................................................59
Kuva 7.5. Reititystiedon haku (peräkkäislähetys).............................................................................60
Kuva 7.6. Reititystiedon haku (kertalähetys)....................................................................................62
Kuva 7.7. Päivitystietokantaan liittyvät elementit ............................................................................64
Kuva 7.8. Reititysnumeron levitys (PNAC) .....................................................................................66
Kuva 7.9. Reititysnumeron levityksen uudelleenyritys (PNAC) ......................................................67
Kuva 7.10. Numerotietokannan päivitys (NA) .................................................................................68
Kuva 7.11. Siirtymiseen liittyvät transaktiot.....................................................................................70
Kuva 8.1. Järjestelmän alustus..........................................................................................................77
VIII
Lyhenneluettelo
ANSI American National Standardization Instute
Yhdysvalloissa toimiva voittoa tuottamaton standardointijärjestö
API Application Programming Interface
Ohjelmointikielen sovellusrajapinta ulkoisiin järjestelmiin
AS Autonomous System
Internetin reititysalue, jossa sovelletaan yhtenäistä politiikkaa
AVCC Advertisement Validity Checking Client
Siirtymistiedon tarkistin
BCNF Boyce-Codd Normal Form
Eräs tavoitetila poistettaessa toisteisuutta tietokannasta
BGP Border Gateway Protocol
Nykyisin de facto-standardi Internetin ulkoisessa reitityksessä
BHCA Busy Hour Call Attempts
Puheluyritysten lukumäärä kiiretunnin aikana
CGI Common Gateway Interface
Rajapinta HTTP-palvelimen ja ulkoisten järjestelmien väliseen tiedonsiirtoon
CIDR Classless InterDomain Routing
Osoitejärjestys, jossa IP-osoitteiden jako vain A-, B-, ja C-luokkiin poistetaan
CLI Call Level Interface
Rajapinta sovellusohjelmista tietokantajärjestelmiin
CPS Call Processing Server
Puhelunmuodostuspalvelin Internetissä
CSA Cache State Advertisement
SCSP:ssä lähetettävä tietuemainos
CTRIP Circuit Telephony Routing Information Protocol
BGP:n mukainen protokolla, joka mainostaa IP-verkon kohteita televerkkoon
DNS Domain Name Service
Internetin nimipalvelu
DSN Data Source Name
ODBC:ssä käytetty nimi tietojärjestelmien identifiointiin
E.164 ITU-T:n suositus SCN-puhelinnumeroiden esittämiseen
ENUM E.164 Number Mapping
Palvelu, jolla E.164-puhelinnumerot muunnetaan IP-osoitteiksi
ER Entity Relationship
Malli, jossa tiedonhallintajärjestelmä esitetään yksilöjoukkoina
IX
GMSC Gateway Mobile Switching Center
Puhelinkeskus, joka yhdistää PSTN/ISDN-verkon GSM-verkkoon
GPL General Public License
Ohjelmistojen vapaa lisenssi
GSM Global System for Mobile communications
Digitaalinen piirikytkentäinen matkapuhelinverkko
H.323 ITU-T:n suositus IP-puhelujen signalointiin
HA Home Agent
Kotiagentti MobileIP:ssä
HLR Home Location Register
GSM-verkon kotirekisteri
HTTP Hypertext Transfer Protocol
Tekstipohjainen protokolla tiedostojen siirtoon Internetissä
IAM Initial Address Message
ISUP-puhelunmuodostuksessa ensimmäisenä lähetettävä sanoma
iBGP interior Border Gateway Protocol
BGP:n käyttämä synkronointiprotokolla
IEC International Engineering Consortium
Voittoa tuottamaton standardointijärjestö informaatioteollisuuden tarpeisiin
IN Intelligent Network
Älyverkko
INAP Intelligent Networks Application Part
Älyverkon sovellusosa YKM:ssä
IP Internet Protocol
Keskeisin Internetin verkkokerroksen protokolla
ISAM Indexed Sequential Access Method
Eräs B+-puuhun perustuva tiedonhakuproseduuri
ISDN Integrated Services Digital Network
Piirikykentäinen digitaalinen monipalveluverkko
ISO International Standardization Organization
Maailmanlaajuinen standardointijärjestö
ISUP ISDN User Part
ISDN:ssä puhelinkeskusten välisen merkinannon YKM-protokolla
ITAD Internet Telephony Administrative Domain
IP-puheverkossa reititysalue, jossa sovelletaan yhtenäistä politiikkaa
JDBC Java DataBase Connectivity
Sovellusrajapinta, joka tarjoaa javasovelluksille pääsyn tietokantoihin
X
LDAP Lightweight Directory Access Protocol
Kevyt Internetin hakemistopalvelu
LE Local Exchange
PSTN/ISDN-verkon paikalliskeskus
LS Location Server
Tilaajien sijaintipalvelin IP-puheverkossa
MAP Mobile Application Part
GSM:n sovellusosa YKM:ssä
MD5 Message Digest 5
Salausmenetelmä, joka perustuu monimutkaisen algoritmin laskentaan
MSRN Mobile Subscriber Roaming Number
GSM-verkon reititysnumero
NA Numbering Agent
Numerontiagentti
NP Number Portability
Tilaajanumeron siirrettävyys
NS Name Server
Internetin nimipalvelujärjestelmän nimipalvelin
ODBC Open DataBase Connectivity
Sovellusrajapinta ohjelmointikielissä tietokantajärjestelmiin
ODL Object Description Language
Oliopohjainen mallinnusmenetelmä
ORDBMS Object Relational DataBase Management System
Oliorelaatiotietokannan hallintajärjestelmä
OSPF Open Shortest Path First
Linkkien tilaan perustuva Internetin sisäinen reititysprotokolla
PHP Hypertext Preprocessor
Ohjelmointikieli, joka tarjoaa rajapinnan moniin tietokantajärjestelmiin
PNAC Ported Number Advertising Client
Siirtymistiedon levittäjä
PNDB Ported Number Database
Siirtymistietokanta
PSTN Public Switched Telephone Network
Piirikykentäinen analoginenpuhelinverkko
RF Route reFlector
iBGP:n reitityspeili
XI
RIS Routing Information Server
Reititystietopalvelin
RTP Realtime Transport Protocol
Internetin reaaliaikapalveluissa käytettävä sanomien kuljetusprotokolla
RTSP RealTime Streaming Protocol
Multimediapalvelujen ohjausprotokolla Internetissä
SCN Switched Circuit Network
Yleisnimitys piirikytkentäisille verkoille
SCP Service Control Point
Älyverkon palvelunohjauspiste
SCSP Service Cache Synchronisation Protocol
OSPF:n levitysmekanismiin perustuva synkronointiprotokolla
SDF Service Data Function
Älyverkon tietokanta
SDP Service Data Point
Älyverkon tietokantojen hallintapiste
SIP Session Initiation Protocol
IETF:n standardi multimediaistuntojen muodostamiseen Internetissä
SMS Service Management System
Aäyverkon palvelun hallitsija
SMS Short Messaging Service
GSM-verkon lyhytsanomapalvelu
SQL Structured Query Language
Standardoitu tietokannan kyselyissä ja hallinassa käytettävä kieli
SSL Secure Socket Layer
Julkiseen ja yksityiseen avaimeen perustuva salausmenetelmä
TAD Telephony Administrative Domain
Autonominen alue piirikykentäisessä verkossa
TCP Transmission Control Protocol
Yhteydellinen Internetin kuljetuskerroksen protokolla
TE Transit Exchange
Puhelinverkon kauttakulkukeskus
TPM Transactions Per Minute
Tiedonhallintajärjestelmän transaktion hallintakyky (lkm minuutissa)
TRIB Telephony Routing Information Base
TRIP:n reititystietokanta
XII
TRIP Telephony Routing Information Protocol
BGP:n mukainen protokolla, jossa televerkon kohteita mainostetaan Internetiin
TTL Time To Live
Ilmaisee DNS:ssä kuinka kauan mainostettu tietue on voimassa
UDB Update Database
Päivitystietokanta
UML Unified Modelling Language
Kieliriippumaton mallinnusmenetelmä ohjelmistokehityksessä
URI Unified Resource Identifier
Median lähde/kohdetunniste Internetin multimediapalveluissa
VLR Visitor Location Register
GSM-verko vierailurekisteri
VSAM Virtual Sequential Access Method
Eräs B+-puuhun perustuva tiedonhakuproseduuri
YKM Yhteiskanavamerkinanto eli SS7 (Signalling System number 7)
1
1 Johdanto
Tässä diplomityössä tutkitaan puhelinnumeron siirrettävyyttä. Pääpaino on ennen kaikkea
numerotietokantojen hallinnassa mukaan lukien päivitysprosessit tilaajan tai tilaajajoukon
siirtyessä. Tämä diplomityö ei ole puhdas ohjelmointityö eikä toisaalta pelkkä akateeminen
pohdiskelu, jossa pääpaino olisi kirjallisuustutkimuksessa, vaan sijoittuu jonnekin näiden
välimaastoon. Näkökulma aiheeseen on hyvin käytännön läheinen. Luvussa 7 puututaan tarkemmin
itse toteutukseen. Sen tarkoitus on tuottaa lukijalle laajempi ymmärrys tutkimusaiheesta ja toisaalta
perustella ratkaisuja, joihin olen päätynyt osoittamalla, että ohjelmistoarkkitehtuuri on todella
mahdollista toteuttaa. Käytetyt tutkimusmenetelmät työssä ovat hyvin moninaiset:
tutkimusaiheeseen liittyviin aiempiin tutkimuksiin tutustuminen, testiohjelmien implementointi
sekä testiympäristön suunnittelu ja kokoaminen.
Numeron siirrettävyys edistää kilpailua telemarkkinoilla. Markkinoille pyrkiville uusille
operaattoreille numeron siirrettävyys takaa paremmat mahdollisuudet menestyä, koska asiakkaiden
hankkiminen helpottuu. Näin käy tietysti markkinoilla ennestään toimivien operaattoreiden
kustannuksella. Asiakkaille numeron siirrettävyys takaa aiempaa joustavamman telepalvelun, koska
numeroa ei tarvitse vaihtaa paikkakunnalta muuton yhteydessä tai muusta syystä palvelun tarjoajaa
vaihdettaessa. Toisaalta numeron siirrettävyyden edellyttämä tilaajakohtaisen reititystiedon säilytys
tarjoaa mahdollisuudet muidenkin palvelujen kehittämiseen etenkin IP-pohjaisen televiestinnän
yleistyessä. Suomessa numeron siirrettävyys tulee toimia GSM-verkkojen välillä 1.7.2003 [1].
Kiinteiden televerkkojen välillä siirrettävyys toimii jo nykyisin mutta on hinnoiteltu siten, että
palvelua ei juurikaan käytetä. IP-verkon ja televerkon välisestä puhelinnumeroiden siirrettävyydestä
mitään ennakkopäätöstä tai aikataulua ei ainakaan Suomessa ole tehty. Teknologiasta toiseen
siirtymiset onkin tämän diplomityön keskeisimpiä pohdinnan kohteita.
Numeron siirrettävyys tarkoittaa sitä, että tilaajan ei tarvitse vaihtaa puhelinnumeroa, kun hänen
verkkoliityntäpiste vaihtuu – esimerkiksi muuton yhteydessä. Vanha puhelinnumero tulee pystyä
säilyttämään myös silloin, kun tilaaja siirtyy toisen palveluntarjoajan asiakkaaksi
siirrettävyysalueen sisällä. Työssä koottava palvelu voidaan toteuttaa perinteisessä
piirikytkentäisessä televerkossa (SCN) sekä puheluita välittävissä IP-verkoissa eli Internetissä.
Myös siirtymiset teknologiasta toiseen tulee siis olla mahdollisia.
2
6
4
5
21
3
234
365
187
6
4
5
21
3
365
234
NP
187
234?
1
6
4
5
21
3
234
365
187
6
4
5
21
3
234
365
187
6
4
5
21
3
365
234
NP
187
234?
1
Kuva 1.1. Tilaajan siirtyminen televerkossa
Piirikytkentäisessä puhelinverkossa (PSTN/ISDN) numeron siirrettävyys rikkoo tilaajanumeroiden
sidoksen verkon topologiaan [2]. Edellä [Kuva 1.1] esitetään yksinkertaistettu esimerkki, mistä
topologiasidonnaisuudessa on kysymys. Alunperin kaikki numerolla 2 alkavat tilaajanumerot ovat
samaan puhelinkeskukseen kytketyillä tilaajilla. Näin jokainen keskus puhelua muodostettaessa
osaa ohjata puhelun kohti keskusta 2. Vastaavasti puhelut numerolla 1 alkaville tilaajille ohjataan
kohti keskusta 1. Tilaajan 234 siirtyessä keskukseen 1 puhelut kyseiselle tilaajalle tuleekin ohjata
keskukseen 1 puhelinkeskuksen 2 asemesta, jonka tilaajanumeron ensimmäinen merkki osoittaisi.
Mikäli siis kaikki numerot ovat siirrettäviä tulee joka kerta puhelua muodostettaessa hakea
reititysnumero tietokannasta (NP). Reititysnumero on se osoite, jolla tilaajan verkkoliitäntä voidaan
lokalisoida. Puhelinverkossa reititysnumero on sen tilaajan numeron etuliite, joka alun perin oli
kyseisessä verkkoliitännässä. Koska myös tilaaja 187 voi siirtyä, on myös hänelle soitettaessa
haettava reititysnumero tietokannasta. Ilman reititysnumeron hakua ei voida tietää, missä tilaajan
verkkoliitäntä sijaitsee. Reititystiedon levitykseen ja hakuun liittyy monia käytännön ongelmia,
joita tässä diplomityössä selvitetään ja ratkaistaan.
Internetissä tilanne on hieman toinen, koska siellä päätelaitteiden osoittamiseen käytetään jo
ennestään loogisia osoitteita, jotka tulee muuntaa reititysosoitteiksi (DNS-nimi -> IP-osoite [3]).
Televerkoissa suoritettava numeromuunnos on helppo ymmärtää, jos tuntee Internetin
aluenimijärjestelmän. GSM-verkossa puolestaan puhelinnumeron ensimmäisten merkkien
perusteella tiedetään, miltä palvelimelta (HLR) kysytään B-tilaajaan liittyvää reititystietoa eli
tilaajan sijaintia. HLR pyytää reititysnumeron (MSRN) siltä palvelimelta (VLR), jonka
sijaintialueella tilaaja on. Näin ollen myös GSM-numerot ovat topologiasidonnaisia. Sidonnaisuus
on kuitenkin tietyssä mielessä löyhempi kuin kiinteässä verkossa, koska GSM-numerot ovat
kyseisen reititystietokyselyn ansiosta luonnostaan (mobiiliverkko) siirrettäviä saman operaattorin
verkon sisällä. Vaikka näiden verkkojen (PSTN/ISDN, GSM, IP) reititys eroaakin toisistaan
merkittävästi, numeron siirrettävyys voidaan toteuttaa hyvin yhtenevästi: PSTN-tilaajalle haetaan
3
verkon topologiaan perustuva reititysnumero, GSM-tilaajalle haetaan HLR:n reititysosoite ja VoIP-
tilaajille haetaan joko aluenimi, IP-osoite tai mahdollisesti jokin yhdyskäytävän osoite. Riippumatta
verkkotyypistä haetaan aina tilaajanumeron perusteella reititystietoa.
Tässä työssä esitettävässä ratkaisussa erotetaan reititys numeron siirrettävyydestä. Reititysosoitteet
liittyvät toki läheisesti numeron siirrettävyyteen, koska numeromuunnos tulee suorittaa
luettelonumerosta reititysosoitteeseen. Numeropalvelun tietokantojen sisältöjä ei kuitenkaan
muodosteta reititysprotokollilla, vaan kokonaan reitityksestä erillään toimivilla
tietokantasovelluksilla. Mikä tahansa yhteisen formaatin (E.164) mukainen tilaajanumero voidaan
siirtää minne tahansa. Tällöin tilaaja käytännössä omistaa numeronsa. Siirrettävyysalueella
toimivalle regulaattorille jää tehtävä valvoa, että kaikki osapuolet toimivat sopimusten mukaisesti.
Verkkojen yhteensovittaminen vaatii kuitenkin myös reitityksen sovittamista.
Työ rakentuu seuraavasti: Luvussa 2 tarkastellaan yleisellä tasolla numeron siirrettävyydelle
vaadittavaa numeromuunnosta. Siinä tarkastellaan myös reititystä sekä aiempaa numeron
siirrettävyyden toteuttavaa ratkaisua, joka yhdistää numeron siirrettävyyden ja reitityksen.
Toteutuksessa käytetään SQL-tietokantoja, joihin käytetään ODBC:tä (Open DataBase
Connectivity) pääsyrajapintana. Näitä käydään läpi luvuissa 3 ja 4. Luku 5 tutkii osoitteistusta ja
nimeämistä eri tietoliikenneverkoissa. Huomiota saavat etenkin Internetin nimipalvelu (DNS) sekä
ENUM (E.164 Number Mapping), jossa Internetin nimipalvelua käytetään hyväksi myös televerkon
numeromuunnoksissa. Lyhyesti esitellään myös se, miten numeron siirrettävyys on toteutettu
nykyisin monissa maissa. Luvussa 6 kootaan kokonaan uusi tavoitearkkitehtuuri, joka täyttää kaikki
numeron siirrettävyyden asettamat vaatimukset. Luvussa 7 esitetään vastaava implementaatio.
Luvussa 8 arvioidaan tuloksia mittaustulosten ja esimerkkilaskelmien avulla. Keskeisimmät
päätelmät sekä katsaus tulevaisuuteen kootaan lukuun 9.
4
2 Työn taustat
Tässä luvussa käsitellään numeron siirrettävyyteen liittyviä ongelmia ja muutoksia, joita se
aiheuttaa puhelujen reititykseen. Tarkastelen rinnakkain numeron siirrettävyyttä piirikytkentäisessä
verkossa sekä Internetissä. Tavoitteena on arkkitehtuuri, joka mahdollistaa siirtymiset myös näiden
välillä. Näin ollen numeroinnin yhteensovittaminen on eräs keskeisimmistä seikoista tämän työn
kannalta. IP/SCN-yhdyskäytävän sijainti muodostuu myös ongelmaksi, mikäli IP-puheluista tulee
tasavertainen vaihtoehto piirikytkentäiselle verkolle. TRIP-protokolla on yksi vaihtoehto
sijaintiongelman ratkaisuun. TRIP:iä [4] käsitellään lähinnä valmiiksi kehitettynä työkaluna. Tässä
luvussa esitellään myös numeron siirrettävyyteen liittyviä aiempia tutkimuksia. Lopuksi vielä
kootaan yhteen päämäärät, joihin tämän diplomityön ratkaisu pyrkii.
2.1 Numeron siirrettävyydelle vaadittava teknologia
2.1.1 Piirikytkentäisessä verkossa
Numeron siirrettävyys monimutkaistaa reititysprosessia sekä televerkoissa että Internetissä. Vaikka
eri verkkojen reititys onkin aivan erilainen, numeron siirrettävyyttä varten tarvitaan kumpaankin
melko samanlainen numeropalvelu. Tilaajanumero ei enää toimi reititysnumerona, koska se ei ole
enää sidottu verkon topologiaan. Televerkoissakin numerointi siis muuttuu loogiseksi, joten
kullekin tilaajanumerolle tai ryhmälle tulee asettaa reititysnumero, jotta puhelunohjauksen voisi
palauttaa seuraamaan televerkoille ominaista topologiaan perustuvaa hierarkkista reititystä [5].
Artikkelissa [2] määritellään mitä informaatiota tarvitaan numeron siirrettävyyttä varten.
Reititysosoite on tärkein attribuutti, joka tarvitaan tilaajanumeroille. Näin ollen puhelukohtaisesti
suoritetaan ratkaisuprosessi tilaajanumerosta reititysnumeroon tai yleisemmin tilaajanumerosta
reititysosoitteeseen.
2.1.2 Internetissä
Internetissä puolestaan on jo valmiina eräänlainen numeropalvelu [Kappale 5]. Nimipalvelun
aluenimiet ovat loogisia. Aina käytettäessä aluenimiin perustuvia osoitteita (esimerkiksi E-mail,
www) joudutaan vastaavanlainen numeromuunnos suorittamaan. Aluenimillä ei IP-paketteja
pystytä välittämään, koska reitittimet ymmärtävät vain IP-osoitteita. Yksinkertaisin ratkaisu VoIP-
palveluissa numeron siirrettävyydelle onkin nimipalvelun päivittäminen tilaajan siirtyessä, mikäli
osoitteistus perustuu aluenimiin (SIP). Näin periaatteessa jokaisen Internet-päätelaitteen osoite olisi
siirrettävä. Palvelu on kuitenkin toteutettu hierarkkisilla tietokannoilla, jotka eivät välttämättä ole
kaikkein sopivimpia numerotietokantoina. Se ei myös ainakaan sellaisenaan ratkaise ongelmaa,
miten tilaajien osoittaminen voidaan yhtenäistää televerkkojen ja IP-verkkojen välillä.
Siirrettävyyden ongelma ei siis juurikaan poikkea piirikytkentäisestä verkosta: Kun tilaaja siirtyy,
IP-osoite, jolla hänet voidaan saavuttaa, muuttuu. Käytännössä tilaajaa palvelevan
signalointipalvelimen (CPS) osoite muuttuu, mutta koska normaalisti jokaisella julkisen verkon
5
liitännällä täytyy olla ainutkertainen IP-osoite, myös se muuttuu. Tavallisesti IP-puheluja ei
muodosteta suoraan päätelaitteiden välille, vaan signalointipalvelimen kautta, vaikka periaatteessa
julkisessa Internetissä kaksi päätelaitetta pystyvät kommunikoimaan itsenäisesti, mikäli ne tietävät
toistensa IP-osoitteet. Sen sijaan puhelut IP- ja televerkon välillä eivät onnistu näin.
Ratkaisuprosesseja varten on oltava tietokannat, josta reititysosoite haetaan käyttämällä
tilaajanumeroa tai sen etuliitettä avaimena. Reititysosoite on jokin ITU-T:n suosituksen E.164
mukainen osoite (numero) tai IP-osoite riippuen siitä, onko B-tilaaja televerkossa vai IP-verkossa.
Tässä työssä ei puututa siihen, onko käytössä IP-protokollan versio 4 vai 6 [6,7]. Vaikka kyseiset
versiot ovatkin käytännössä kuin kaksi täysin eri protokollaa, eivät esittämäni ratkaisuperiaatteet
juurikaan muuttuisi, jos siirryttäisiin version 6 käyttöön.
2.2 SCN/IP teknologiarajapinta
Mikäli tilaajanumerot ovat siirrettäviä SCN/IP teknologiarajapinnan yli, täytyy verkossa noudattaa
yhteistä numerointia. Rajoittavana tekijänä on televerkon päätelaitteiden rajoitteet: Esimerkiksi
SIP-järjestelmien ymmärtämiäuser@domainformaatin mukaisia osoitteita [5] ei pysty PSTN-
päätelaitteella näppäilemään. Kyseisiä merkkejä ei yksinkertaisesti ole tavallisissa PSTN-verkon
lankapuhelimissa. Lisäksi kyseessä voisi olla liian suuri muutos kansanryhmille, jotka ovat
tottuneet käyttämään puhelinta numeroilla. Mahdollisesti suurin osa kiinteän piirikytkentäisen
puhelinverkon tilaajista joutuisi vaihtamaan päätelaitetta, jos numeroilla osoittamisesta
luovuttaisiin.
Numeroilla osoittaminen aiheuttaa puolestaan IP-verkossa sen, että jokaisella IP-verkon tilaajalla
täytyy olla myös E.164 formaatin mukainen osoite. Näitä puolestaan on muutettava teknologiasta
riippuen joko E.164-reititysosoitteiksi tai IP-osoitteiksi. Soitettaessa televerkon puolelta IP-verkon
päätelaitteeseen, joudutaan aluksi antamaan E.164 formaatin mukainen reititysnumero, koska SCN-
verkko ei osaa käsitellä IP-osoitteita. Toisaalta myös IP-verkossa voidaan soittaa toiseen IP-
päätelaitteeseen käyttämällä E.164-numeroa. Televerkosta lähtevä puhelu IP-verkkoon päätyvään
puheluun väylöitetään televerkossa SCN/IP-yhdyskäytävään asti. Yhdyskäytävässä
puhelunmuodostukseen annetaan mahdollisesti uusi reititysosoite (IP-osoite), jolla
puhelunmuodostus jatkuu B-tilaajaa palvelevaan signalointipalvelimeen (SIP [8], H.323), minkä
jälkeen lopulta puhetta kuljettavien RTP-sanomien virtaa voidaan alkaa välittää lähteen
(yhdyskäytävä) ja kohteen välillä. Myös GSM-verkon HLR/VLR-järjestelmiä osoitetaan E.164-
formaatin mukaisilla osoitteilla. Näin myös GSM-verkko saadaan varsin mutkattomasti kytkettyä
numeron siirrettävyyteen. GSM-verkontilaajan siirtyessä häntä palveleva HLR muuttuu.
IP-verkossa käytetään perinteisiä reititysprotokollia (BGP [9], OSPF[10]) eli paketit välitetään
kuten Internetissä tavallisesti. SCN/IP yhdyskäytävä jakaantuu ainakin loogisesti
mediayhdyskäytävään ja signalointiyhdyskäytävään. Karkeasti mediayhdyskäytävän (engl. media
gateway) tehtävä on muuntaa jatkuva televerkon bittivirta IP-paketeiksi reititettäväksi Internetissä
ja vastaavasti pakettimuotoinen data bittivirraksi siirrettäväksi televerkossa.
Signalointiyhdyskäytävää (engl. signalling gateway) tarvitaan etenkin puhelujen muodostuksessa.
6
Esimerkiksi tyypillinen ISDN-verkon merkinanto ISUP muutetaan SIP-sanomiksi (tai H.323).
Numeron siirrettävyyden kannalta erityisesti signalointiyhdyskäytävän toimintaa on tarkasteltava.
Normaali Internet-reititys puolestaan huolehtii siitä, että IP-puhelujen RTP-sanomat välitetään
mediayhdyskäytävän prosessoitaviksi ja edelleen lähetettäviksi, ja toisaalta televerkkojen
perinteisesti staattinen hierarkkinen reititys huolehti bittivirran reitityksestä piirikytkentäisessä
verkossa.
2.3 Yhdyskäytävän sijainti
2.3.1 Ongelma
Jos IP-verkon käyttö yleistyy puhelujen välityksessä, tulee ongelmaksi sopivan IP/SCN-
yhdyskäytävän etsiminen IP-verkosta televerkkoon päätyvillä puheluilla. Yhdyskäytävien
kapasiteetti voi vaihdella pienistä – vain yhtä tai kahta puhelua samanaikaisesti tukevista – suuriin –
jopa tuhansia samanaikaisia puheluja tukeviin laitteistoihin. Periaatteessa jokaisen yhdyskäytävän
kautta voidaan saavuttaa kaikki mahdolliset televerkon päätelaitteet. Useinkaan näin ei haluta asian
olevan, vaan tietyn yhdyskäytävän omistaja haluaa dedikoida sen käyttöä palvelemaan vain tiettyjä
tilaajia. Toisaalta yhdyskäytävän käytöstä halutaan myös laskuttaa, joten informaation levitys
yhdyskäytävien saatavuudesta tulee olla vahvasti palveluntarjoajien sisäisiin menettelytapoihin
perustuvaa samalla tavoin kuin nykyisessä Internet-reitityksessä ulkoisella protokollalla voidaan
verkon toimintaa manipuloida.
Yhdyskäytävä on instanssi, jolla täytyy olla sekä E.164- että IP-osoite. Internetissä on
monenkokoisia autonomisia alueita ja siirrettävyysalueilla voisi toimia myös erillisiä
kauttakulkuoperaattoreita, jotka tarjoavat siis välityspalvelua IP-verkosta piirikytkentäiseen
verkkoon päätyvissä puheluissa. Tilaajaoperaattori voisi näin ollen toimia tukematta itse lainkaan
IP/SCN-teknologiarajapintaa. Televerkon tilaajalle voidaan määrittää melko staattisesti
yhdyskäytävä IP-verkkoon päätyville puheluille. Palvelun tarjoaja voi siis määrittää (staattisesti),
että kaikki tietyn tilaajaryhmän puhelut välitetään Internetiin saman yhdyskäytävän kautta. Mikäli
yhdyskäytävää ei ole, voidaan palvelu ostaa joltakin toiselta operaattorilta, joka tarjoaa
kauttakulkupalvelua IP-verkkoon. Eräs IP-puheluja puoltava tekijä on se, että puheen siirtäminen
Internetissä olisi halvempaa kuin piirikytkentäisessä verkossa [8], joten IP-verkkoon päätyvä
puhelu voi olla palveluntarjoajan kannalta edullisinta siirtää mahdollisimman nopeasti televerkosta
Internetiin. Tämä on seikka, joka puoltaa staattista yhdyskäytävän valintaa, samoin kuin se, että
tällöin ei IP-verkon tilaajista tarvitsisi levittää lainkaan reititystietoa televerkon puolelle –
ainoastaan tieto siitä, että tilaaja on IP-verkossa. Toisaalta usein palvelunlaatu on sitä huonompi
mitä kauemmin puhe kulkee Internetissä.
2.3.2 Ratkaisut
Internetin puolella on kolme erilaista ratkaisua yhdyskäytävän sijaintiongelman ratkaisuun:
7
1. TRIP [Kappale 2.4]
2. Mainostetaan eksplisiittisesti jokaiselle tilaajalle tai tilaajaryhmälle sopivaa (sopivia)
yhdyskäytävää saman numeropalvelun välityksellä, jolla tilaajanumerot ratkaistaan
reititysnumeroksi.
3. Jätetään yhdyskäytävän löytäminen kokonaisuudessaan IP-verkossa A-tilaajan tai A-tilaajan
operaattorin vastuulle.
Ainakaan ensimmäisenä ja viimeisenä mainitut eivät ole toisiaan poissulkevia. Jokaisen
palveluntarjoajan ei tarvitse olla mukana TRIP-sanomien välityksessä. Tällaisella operaattorilla voi
olla omat dedikoidut yhdyskäytävät, jotka tarjoavat vain palvelua omille asiakkailleen. Näin ollen
soitettaessa IP-verkosta televerkkoon valittaisiin aina sama yhdyskäytävä riippumatta B-tilaajan
sijainnista. Usein kuitenkin voi olla halvempaa välittää puhelua mahdollisimman kauan
Internetissä, joten kyseinen ratkaisu ei välttämättä tarjoaisi A-tilaajan operaattorin kannalta
optimaalista reititystä. Toisessa vaihtoehdoista yhdyskäytäväinformaation voisi välittää samalla
numerotietojen kanssa, eli jokaiselle tilaajanumerolle tai etuliitteelle määritetään sekä reititysosoite,
että yhdyskäytävä. Tällöin yhdyskäytävän sijaintiongelma jäisi kokonaisuudessaan B-tilaajan
vastuulle.
Luvussa 6 esitettävä arkkitehtuuri tarjoaa mahdollisuuden määrittää myös televerkossa
reititysnumerokohtaisesti sopiva (sopivat) signalointiyhdyskäytävä(t): Mikäli havaitaan jossakin
vaiheessa ratkaisuprosessia [Kuva 6.4, Kuva 6.5], että haettava B-tilaaja on IP-verkossa, suoritetaan
uusi haku toisesta taulusta. Tällöin käytetään reititysnumeroa avaimena, jolla haetaan B-tilaajaa
palvelevan signalointiyhdyskäytävän E.164 osoite tai tarvittaessa lisäinformaatio, mistä sopiva
yhdyskäytävä löydetään. Taulujen tiedot voidaan levittää päivitystietokantojen avulla [Kappale
6.2.1]. Tällöin jäisi A-tilaajan operaattorin päätettäväksi käytetäänkö B-tilaajan operaattorin
mainostamaa yhdyskäytävää vai jotakin muuta tiedossa olevaa yhdyskäytävää. Menettelyllä
voidaan myös antaa jokaiselle tilaajalle mahdollisuus erikseen ostaa palvelu IP-verkkoon hänen
puhelunsa välittävältä operaattorilta. Kuitenkaan operaattorit eivät välttämättä ole halukkaita
levittämään kaikkialle tarkkaa tietoa reititysnumeroon liittyvästä yhdyskäytävästä, jolloin tarvitaan
jokin TRIP:n [Kappale 2.4] kaltainen mekanismi.
2.4 TRIP
2.4.1 TRIP vs. BGP
TRIP:n (Telephony Routing over IP) [4] toiminta on helpompi ymmärtää, jos tuntee Internet-
reitityksessä käytettävän BGP:n (Border Gateway Protocol) [9]. TRIP:n funktionaalisuus on siis
koottu BGP:tä mukaillen. Protokollien tilakoneet ovat yhtenevät. Protokollien tehtävä on levittää
saavutettavuustietoa verkkoon kytketyistä päätelaitteista. Erona näiden välillä on se, että BGP
levittää tietoa saavutettavista IP-osoitteista, kun taas TRIP levittää tietoa saavutettavissa olevista
puhelinnumeroista (E.164). Kummatkin toimivat Internetissä. Tiedon levitys perustuu
8
polkuvektoriin, jolla ilmaistaan polku kohteeseen ja estetään reitityssilmukoiden syntyminen. BGP-
reititin ohjaa IP-osoitteen etuliitteen perusteella sisään tulleen paketin oikeaan ulosmenoporttiin,
jotta haluttu päätelaite voidaan lopulta saavuttaa. TRIP-palvelin puolestaan tarjoaa sen
yhdyskäytävän IP-osoitteen, jonka kautta haluttu televerkon päätelaite voidaan saavuttaa. BGP:n
kohdalla kysymys on siirtokaistan sisäpuolisesta (engl. in-band) tiedonvälityksestä, kun taas TRIP-
informaatio on siirtokaistan ulkopuolista (engl. out-of-band). Kumpikin käyttää tiedonsiirrossa
luotettavaa kuljetuskerroksen protokollaa [9]. Mainostetuille reiteille ei lähetetä virkistyssanomia.
BGP-reitittimen päätehtävä on ohjata IP-paketteja sisääntulosta ulosmenoporttiin kun taas TRIP-
palvelin toimii ainoastaan tietopalvelimena, josta haetaan reititystietoa IP-verkosta televerkkoon
päätyvissä puheluissa.
Naapuruussuhteita ylläpidetään KEEPALIVE-sanomilla. Mikäli naapurilta ei tule viestiä tietyn ajan
kuluessa (engl. dead interval), tulkitaan yhteys naapuriin katkenneeksi. Tällöin kyseisen naapurin
mainostamat tiedot tulkitaan vanhentuneiksi. Menetetyn naapurin saavutettavuustietueet poistetaan
kaikista paikallisista tauluista, joissa niitä on. Sen jälkeen lähetetään niiden mukaiset päivitysviestit,
joissa kerrotaan että kyseiseen naapuriin ei enää täältä kautta pääse (engl. route withdrawal). Tällä
tavoin BGP mukautuu verkon topologian muutoksiin. Sekä TRIP että BGP erottavat tietokantojen
synkronoinnin omalla alueella ja naapurialueiden kanssa. Riittävän redundanssin ja yhtenäisen
reitityksen aikaansaamiseksi kaikki alueen tietokannat saatetaan identtisiksi. Eri alueilla sisäinen
synkronointi voi toimia eri tavoilla, mutta ulkoinen tiedonlevitys tulee olla yhtenäistä.
2.4.2 TRIP SCN/IP yhdyskäytävän sijaintiongelman ratkaisijana
Internet-puheluihin liittyvät seuraavat funktiot, joissa E.164 puhelinnumero tulee muuntaa IP-
osoitteeksi:
1. Oikean yhdyskäytävän IP-osoitteen etsiminen, jos on annettu (IP-verkossa) E.164 formaatin
mukainen puhelinnumero, joka osoittaa tilaajaa televerkossa.
2. Oikean tilaajan IP-osoitteen etsiminen, jos on annettu (IP-verkossa) E.164 formaatin
mukainen puhelinnumero, joka osoittaa tilaajaa IP-verkossa.
3. IP-päätelaitteen osoitteen etsiminen, jos on annettu televerkon tilaaja, jolla on päätelaite myös
IP-verkossa.
TRIP:n (Telephony Routing over IP) [11] tehtävä on ratkaista ensiksi mainittu ongelma eli juuri
yhdyskäytävän sijainti televerkkoon päätyviä puheluja varten. Toinen ongelma liittyy numeron
siirrettävyyteen IP-verkossa, eikä ole TRIP:n tehtävä. Viimeisenä mainittua tarvitaan palveluissa,
joissa esimerkiksi tilaajan PC:lle lähetetään viesti hänen puhelimen soidessa televerkossa. TRIP-
tietueeseen liittyy olennaisimpina televerkon numeroavaruuden osa, joka voidaan saavuttaa
yhdyskäytävän kautta sekä kyseisen yhdyskäytävän IP-osoite. Myös reitti tietuetta prosessoivasta
sijaintipalvelimesta (LS) yhdyskäytävään ilmaistaan TRIP:llä. Saavutettavuustietoja mahdollisesti
aggregoidaan ja lähetetään kaikille naapureille. Naapureihin ylläpidetään pysyvää TCP-yhteyttä,
9
joka pidetään siis voimassa määrävälein lähetettävillä sanomilla (KEEPALIVE). Polkuvektorin
avulla voidaan estää reitityssilmukoiden syntyminen vastaavasti kuin BGP:ssä [9].
TRIP-ratkaisu on kompromissi ja laajennus verrattuna sivulla 7 esitettyihin vaihtoehtoihin 2 ja 3,
jotka ovat keskenään poissulkevia, sillä konfliktoivat politiikat saattavat aiheuttaa sen, että tietyissä
tapauksissa puhelu ei onnistu lainkaan. TRIP tarjoaa siis keinot sekä A-tilaajalle, että B-tilaajalle
(operaattoreille) mahdollisuuden vaikuttaa siihen, mitä yhdyskäytävää käytetään.
2.4.3 TRIP-tietokannat
Olennaisena osana TRIP:iin liittyy reititystietokanta. TRIP-tietokanta (TRIB) jakautuu
funktionaalisesti neljään osaan [4]:
Adj-TRIBs-In
Adj-TRIBs-In jakaantuu edelleen kahteen osaan: ulkoiseen ja sisäiseen tietokantaan. Ulkoiset reitit
ovat naapurialueilta saatuja reittejä ja sisäiset reitit ovat oman alueen sisältä mainostettuja reittejä.
TRIP-palvelimessa on siis jokaista oman alueen palvelinta sekä jokaista kytkettyä naapurialueiden
palvelinta varten erilliset taulut, joita hallitaan täysin toisistaan riippumatta. Siis myös oman alueen
palvelimille, jotka eivät ole suorassa naapuruussuhteessa, on taulu TRIP-tietokannassa. On täysin
mahdollista, että samaa tilaajaa tai etuliitettä varten tietokannassa on montakin mahdollista reittiä
Adj-TRIBs-In-tietokannassa. Adj-TRIBs-In muodostaa TRIP-palvelimen tietosisällön raskaimman
osan, koska mitään reittejä ei suodateta pois, vaan kaikki lisätään tietokantaan. Tauluihin ei
kohdistu suoranaisesti minkäänlaisia reititystietokyselyjä. Sisäinen Adj-TRIBs-In-tietokanta
annetaan syötteenä lopulliseen päätösprosessiin.
Ext-TRIB
Ext-TRIB-taulu sisältää paikallisen politiikan mukaisesti kullekin etuliitteelle valitun parhaan
mahdollisen reitin ottaen huomioon ainoastaan ulkoisten kytkettyjen naapuripalvelinten
mainostamat reitit sekä paikalliset reitit. Paikalliset reitit ovat reittejä, joiden juuri on oma alue. Ne
on joko konfiguroitu manuaalisesti palvelimeen tai saatu jollain muulla (sisäisellä)
reititysprotokollalla. Jokaisella TRIP-palvelimella on vain yksi Ext-TRIB-taulu, joka sisältää
kullekin etuliitteelle vain yhden reitin. Tauluihin ei normaalisti kohdistu reititystietokyselyjä. Ext-
TRIB annetaan myös syötteenä lopulliseen päätösprosessiin, jossa määräytyvät Loc-TRIB- sekä
Adj-TRIBs-Out- tietokantojen sisällöt.
Loc-TRIB:
Etsittäessä sopivaa yhdyskäytävää televerkkoon päätyvälle puhelulle varsinaiset reititystietokyselyt
kohdistuvat Loc-TRIB-tauluun, joka saadaan soveltamalla päätösprosessi paikallisen politiikan
mukaisesti kaikkeen saatavissa olevaan reititysinformaatioon eli ottamalla huomioon Ext-TRIB-
10
taulun reitit sekä kaikki Adj-TRIB-In-taulut, jotka sisältävät oman alueen palvelimien mainostamat
reitit.
Adj-TRIBs-Out
Adj-TRIB-Out-taulut sisältävät reitit, jotka on valittu mainostettavaksi ulkoisille naapureille.
Tauluja on korkeintaan yhtä monta kuin on ulkoisia naapureita. Menettely mahdollistaa siis sen,
että jokaiselle ulkoiselle naapurille levitetään erilaista reititysinformaatiota.
2.4.4 Päätösprosessi
Loc-TRIB- sekä Adj-TRIB-Out-taulut saadaan ajamalla TRIP:n päätösprosessi (engl. decision
process). Hieman toisesta näkökulmasta tarkasteltuna TRIP-palvelin jakaantuu prosessoituun ja
prosessoimattomaan tietoon [Kuva 2.1]. Prosessoimaton tieto sisältää tietueryhmiä, jotka eivät ole
keskenään riippuvuussuhteessa. Sen sijaan prosessoiduissa tietueissa yhden tietueen sisällön
muutos voi aiheuttaa toisen tietueen muutoksen.
DecisionProcess
Local Routes
Ext-TRIB
Adj-TRIBs-In(External)
Adj-TRIBs-In(Internal)
Loc-TRIB
Adj-TRIBs-Out
DecisionProcess
DecisionProcess
Local Routes
Ext-TRIB
Adj-TRIBs-In(External)
Adj-TRIBs-In(Internal)
Loc-TRIB
Adj-TRIBs-Out
DecisionProcess
Kuva 2.1. TRIP-tietokannat
Mikäli alueen TRIP-palvelimet soveltavat yhtenevää politiikkaa, sisäisten Adj-TRIB-In- taulujen
synkronointi johtaa lopulta myös alueen Loc-TRIB-tietokantojen konvergoitumiseen. Dokumentin
[4] mukaan Adj-TRIBs-In (sisäinen) tietokantojen synkronointiin käytetään SCSP:n [12]
levitysprotokollaa TCP:n päällä. Käyttäjän kannalta oleellisinta on riittävä redundanssi Loc-TRIB-
taulujen osalta: Kapasiteetin tulee riittää ruuhkaisimmankin kiiretunnin kyselyihin, ja toisaalta
palvelimien vikaantuessa tulee olla riittävä määrä varapalvelimia käytössä. Kaikki muu onkin
käytön kannalta pelkkää ylijäämää (engl. overhead).
On monenlaisia tilanteita, joissa päätösprosessi joudutaan ajamaan. Normaalein tapaus lienee uuden
reittimainoksen vastaanottaminen naapurilta. Se voi tulla siis joko naapurialueelta tai
naapuripalvelimelta oman alueen sisällä. Ulkoiselta naapurilta tullut päivitys vaatii
perusteellisempaa prosessointia. Päätösprosessi etenee vaiheittain:
11
1. Preferenssiarvon laskenta
Jokaiselle ulkoisen alueen naapurin mainostamalle reitille lasketaan preferenssiarvo alueen
sisäisen politiikan määrittelemällä tavalla, joka ilmaisee kuinka ”sopivia” kyseiset reitit ovat.
Vaiheen aikana käsiteltävä taulu lukitaan päivityksiltä. Laskenta on jokaiselle reitille
itsenäinen prosessi eikä preferenssiä tarvitse laskea muille kuin lisätyille tai muuttuneille
reiteille. Mikäli siis päivityssanomassa on vain poistettavia reittejä, ei vaihetta tarvitse
suorittaa lainkaan. Omalta alueelta lähtöisin olevissa reiteissä preferenssi on laskettu
valmiiksi, koska politiikka alueen sisällä on sama.
2. Parhaiden reittien valinta
Valitaan kaikista mahdollisista reiteistä paras kuhunkin kohteeseen ja päivitetään Loc-TRIB-
taulu. Vaihe jakaantuu siis kahteen osaan: Ext-TRIB-taulun kokoaminen ulkoisista ja
paikallisista reiteistä ja Loc-TRIB-taulun kokoaminen Ext-TRIB-taulun sekä oman alueen
palvelimien mainostamista reiteistä. Mikäli Ext-TRIB:iin tai Adj-TRIBs-In:iin tulee
muutoksia on myös Loc-TRIB käytävä läpi, jotta numerotiedot pysyisivät ajan tasalla.
Läheskään aina Loc-TRIB:iin ei tule muutoksia. Päivityssanomassa olevat muutokset voivat
koskea reittejä, joita ei ole valittu korkeimman prioriteetin reiteiksi. Mikäli Loc-TRIB:stä
poistetaan jokin reitti, täytyy uutta reittiä etsiä kaikista Adj-TRIB-In-tauluista sekä Ext-
TRIB:stä, koska jokaisessa näissä saattaa olla uusi korkeimman preferenssin reitti.
3. Mainostettavien reittien valinta
Päätösprosessin viimeisessä vaiheessa päivitetään taulut, jotka sisältävät ulkoisille
naapureille mainostettavaksi valitut reitit. Tämä on useimmiten raskain vaihe, sillä
sovellettava politiikka tiedon ulkoisen levityksen ja esimerkiksi aggregoinnin suhteen voi
olla varsin kompleksinen.
2.4.5 TRIP:n heikkoudet
Päätösprosessi on selvästi melko raskas operaatio, joten TRIP ei ole sopiva ratkaisu palveluihin,
joissa tapahtuu säännöllisesti usein muutoksia. Etenkin massiiviset reittien poistot yhteyden
katketessa palvelimien välillä ovat raskaita prosessoida, koska vaikutus voi ulottua kaikkiin
prosessoituihin tauluihin. Ongelma on havaittu jo BGP:ssä, ja sitä varten protokollaan onkin
kehitetty oskilloinnin esto [13]. TRIP soveltuukin parhaiten topologiaan perustuvan numerotiedon
levitykseen aivan kuten BGP Internetissä. Puhelinverkon topologiassahan tapahtuu muutoksia
hyvin harvoin. Internetissä viime aikoina on tapahtunut paljon topologiamuutoksia, mutta ne
johtuvat verkon laajentumisesta eivätkä esimerkiksi osoitteiden siirtymisistä. Hyvin normaalia on,
että tiettyä etuliitettä varten voi olla useita reittejä, joten kokonaisuudessaan TRIP-tietokannan koko
voi olla esimerkiksi kymmenkertainen Loc-TRIB taulun kokoon verrattuna.
12
Pysyvän TCP-yhteyden ylläpitäminen saavutettavuustietojen validiteetin takeeksi on paljon
tehokkaampaa BGP:ssä kuin TRIP:ssä, koska BGP:ssä reititystiedon siirto on siirtokaistan sisäistä1.
Mikäli KEEPALIVE-sanomia ei saada vaaditun ajan sisällä, voidaan päätellä että linkillä on jotain
vikaa tai reititin on vikaantunut. Se puolestaan merkitsee sitä, että kyseistä linkkiä ei voi käyttää IP-
pakettien siirtoon. Näin ollen naapurin mainostamat reitit pitääkin poistaa tietokannasta. TRIP:n
kohdalla tilanne on toinen, koska välityslaitteiden (yhdyskäytävät, reitittimet) ja niitä yhdistävien
linkkien toiminta ei ole sidottu palvelimien lähettämiin KEEPALIVE-sanomiin: Yhteydellä olevat
välityslaitteet saattavat olla vikaantuneita, vaikka KEEPALIVE-sanomia tulisi aivan normaalisti.
Toisaalta KEEPALIVE:n hävitessä palvelimen mainostamat etuliitteet ovat todennäköisesti täysin
saavutettavissa.
2.5 Aiemmat aiheeseen liittyvät tutkimukset
2.5.1 TRIP/CTRIP arkkitehtuuri
Eräs mahdollinen ratkaisu reititysinformaation levitykseen esitetään diplomityössä [5]. Siinä
keskeisessä asemassa ovat TRIP- ja CTRIP-protokollat. Malli on otettu Internetin
reititysprotokollista – etenkin BGP-protokollasta [9]. TRIP ja CTRIP levittävät luettelonumeroiden
saavutettavuustietoa kuten BGP levittää IP-osoitteiden saavutettavuustietoa. CTRIP olisi TRIP:iä
vastaava protokolla piirikytkentäisen verkon puolella.
Kuva 2.2 TRIP/CTRIP-arkkitehtuuri [14]
1Tämä ei aina pidä paikkansa, koska myös BGP-reitittimien välinen yhteys voi olla ainoastaan looginen,
jolloin protokollan viestit saattavat kulkea eri reittiä kuin hyötyliikenne.
13
Kuva 2.2 kattaa TRIP/CTRIP-arkkitehtuurin. TRIP hoitaisi siis yhdyskäytävän sijaintiongelman
ohella myös numeron siirrettävyyden. Sillä levitettäisiin siis loogisia numeroita, eli
tilaajanumeroita, jotka eivät ole sidottu verkon topologiaan. Tämä edellyttää protokollaan joitakin
muutoksia, jotka esitetään diplomityössä [5]. Verkko ajatellaan koostuvan joukosta autonomisia
alueita (TAD, ITAD). Numerointi-informaatio sijoitetaan erillisiin palvelimiin (TRIP- ja CTRIP-
palvelimet), joita jokaisella autonomisella alueella on useita. Alueen sisällä täytyy eri palvelimien
tiedot olla yhtenäisiä. Arkkitehtuurissa sisäisestä synkronoinnista huolehtii dokumentin [4]
mukaisesti SCSP:n [12] levitysprotokollasta johdettu mekanismi.
TRIP-informaation synkronoinnissa autonomisten alueiden välillä sekä alueiden sisällä käytettäisiin
luotettavaa kuljetuskerroksen protokollaa (TCP). Virkistyssanomia mainostetuille tietueille ei
lähetetä. Autonomisten alueiden reunapalvelimien funktionaalisuus vastaa BGP-4:n reitittimien
toimintaa. Jokainen alue harjoittaa valitsemaansa politiikkaa TRIP/CTRIP:n puitteissa
reititysinformaation levityksessä naapureilleen. Numerointiyhdyskäytävä (Numbering Gateway)
toimisi ikään kuin tulkkina välissä, kun reititysinformaatiota levitetään teknologiarajapinnan yli
(SCN/IP, IP/SCN) [5]. Tulkki tarvitaan, koska TRIP:n tiedot eivät täysin vastaa CTRIP:n tietoja,
joskin ne ovat keskenään hyvin analogiset.
2.5.2 iBGP
Alunperin työn lähtökohta oli toteuttaa aiempaa tehokkaampi synkronointimenetelmä käytettäväksi
autonomisten alueiden sisällä. Kuten todettua, TRIP/CTRIP:n toiminta mukailee BGP-4.ää. Se
sisältää protokollan (iBGP – interior Border Gateway Protocol) [13] reititystietokantojen
synkronointia varten. Näin ollen herääkin kysymys, miksei myös TRIP käyttäisi sisäiseen
synkronointiin vastaavanlaista mekanismia. iBGP:tä käytetään BGP-reitittimien
reititystietokantojen synkronointiin Internetissä autonomisten alueiden (AS) sisällä. Sitä käyttävät
autonomisen alueen reunareitittimet. Protokollan lähtökohtana on täysin kytketty rakenne, jossa
kaikki reunareitittimet on kytketty toisiinsa [Kuva 2.3]. Täysin kytketty rakenne ei välttämättä
skaalaudu, mikäli reitittimiä on paljon ja toisaalta siirtokaistaa kuluu turhaan päivitysliikenteen
välityksessä. Kuvassa ei ole yksinkertaisuuden vuoksi esitettynä muuta kuin reunareitittimet.
Rakenne voidaan purkaa tähtirakenteeksi reitityspeilin avulla [15]. Silmukoiden syntyminen ei ole
kummassakaan tapauksessa mahdollista. Päivitykset suoritetaan inkrementaalisesti.
AS AS
RF
ASAS AS
RF
AS
RF
Kuva 2.3 Täysin kytketty ratkaisu vs. reitityspeili
14
Reitityspeilin ongelma on luonnollisesti keskitettyjen ratkaisujen luotettavuus, koska yhden laitteen
vikaantuessa reittimainoksia ei voi levittää ollenkaan. Kuitenkin myös sisäiseen verkkoon saadaan
muodostettua mielivaltainen topologia käyttämällä reititysliittoumia [13]. Silloin alue jaetaan
sisäisiin autonomisiin alueisiin, joiden tunnukset (AS numerot) valitaan privaatista
numeroavaruudesta. Syntyneiden alueiden sisällä voidaan käyttää täysin kytkettyä topologiaa tai
reitityspeiliä jne. Tällöin yhden reitityspeilin vikaantuessa osa verkosta toimii normaalisti. On
huomattava, että kytkennällä tässä yhteydessä tarkoitetaan TCP-tason yhteyttä eli ei sitä, että
reitittimien tarvitsisi olla fyysisesti kytketty suoraan toisiinsa. Reititystiedon kuljetusprotokollana
käytetään joka tapauksessa TCP:tä. TRIP:n oma synkronointimekanismi [4] on tosin vielä
mukautuvampi erilaisiin topologioihin, sillä mitään peilejä ei tarvita.
2.6 TRIP/CTRIP-ratkaisun heikkoudet
2.6.1 Aggregointi vaikeutuu
Suunniteltaessa numeron siirrettävyyttä peruslähtökohta on, että ratkaisun tulee skaalautua jopa 50
miljoonaa tilaajaa kattaviin numeron siirrettävyysalueisiin. Numeron siirrettävyyttä valtioiden
rajojen yli en ole ehdottamassa, mutta esimerkiksi Yhdysvalloissa voi muodostua hyvinkin suuria
alueita. Internetissä reititysprotokollien skaalautuvuus perustuu koosteiseen reititystietojen
levittämiseen eli aggregointiin: Jokaisessa reitittimessä ei ole tarkkaa tietuetta jokaiselle
päätelaitteelle eikä edes jokaiselle aliverkolle, vaan joukko osoitteita aggregoidaan yhdeksi
tietueeksi. Internetin runkoreitittimissä oli 22.11.2002 enimmillään noin 140000 reittiä1 [18].
Esimerkiksi osoitteet 130.233.0.0/24, 130.233.0.2 ja 130.233.0.3/24 voidaan aggregoida yhdeksi
osoitteeksi 130.233.0.0/22 edellyttäen, että CIDR-osoitearitmetiikka [17] on käytössä.
Kun kyse on verkon topologiaan perustuvista luettelonumeroista, puhelinverkossa voidaan
numeroita aggregoida samalla tavalla kuin Internetissä: Esimerkiksi 09766233, 09766236 ja
09766237 voidaan aggregoida tietueeksi 0976623. Useimmiten aggregointi on puhelinverkossa
vieläpä huomattavasti tehokkaampaa kuin Internetissä, koska reittien määrä (puhelinkeskusten
määrä) on pienempi kuin Internetin reittien (reitittimien) määrä. Mutta miten aggregointi onnistuu,
kun tilaajanumerointi ei ole sidottu verkon topologiaan? Tarkastellaan esimerkkinä [Kuva 2.4]
yksinkertaista puhelinverkkoa (ISDN), jossa on kolme tilaajaoperaattoria A, B ja C. A toimii myös
kauttakulkuoperaattorina (engl. transit telecom operator).
1 AS Numero 1221:n (Telstra) runkoreitittimissä oli 138311 reittiä.
15
LE
C
A
BLE
TE
94516661
94516662
94516663
94516664
94516665
94516666
94516667
94513441
94513442
94513443
94513444
94513445
94513446
94513447
TE
94513?
LE
C
A
BLE
TE
94516661
94516662
94516663
94516664
94516665
94516666
94516667
94516661
94516662
94516663
94516664
94516665
94516666
94516667
94513441
94513442
94513443
94513444
94513445
94513446
94513447
94513441
94513442
94513443
94513444
94513445
94513446
94513447
TE
94513?
Kuva 2.4 Puhelinverkko
Taulujen mukaisesti etuliite 94513 kuuluu alun perin operaattorille B ja etuliite 94516 kuuluu
alunperin operaattorille C. Kun operaattorin A verkosta soitetaan puhelu numeroon, joka alkaa
etuliitteellä 94516, osataan puhelu ohjata heti operaattorille C, koska missään muualla ei ole
kyseisen etuliitteen tilaajia. Kun edellä esitetyssä tapauksessa [Kuva 2.4] tilaaja 94513441 siirtyy
operaattorille C, täytyy A:n keskuksessa odottaa A-tilaajalta kaikki numerot ennen kuin puhelu
voidaan ohjata operaattorille C, koska aiemminhan tilaaja kuului operaattorille B. Operaattori A siis
joutuu myös muuttamaan reititystään, vaikka se ei millään tavalla liity tässä tapauksessa tilaajan
siirtymiseen. Kaikkiin 94513-alkuisiin numeroihin soitettaessa mistä tahansa joudutaan siis
analysoimaan kaikki numerot ennen kuin reitityspäätös voidaan tehdä. Ilman tietokantakyselyjä
tilannetta voidaan verrata siihen, että Internetissä verkon 130.233.0.0/16 liitäntä siirtyisi verkkoon
130.234.0.0/16 säilyttäen vanhan IP-osoitteensa, mikä ei tietenkään onnistu, koska verkon
skaalautuvuus perustuu aggregointiin. Runkoverkon reititin ei osaisi välittää paketteja osoitteiden
perusteella oikeaan porttiin. Internet-reitityksessä jokainen operaattori voi itse määritellä
aggregointipolitiikkansa, koska IP-osoitteet eivät ole siirrettäviä. Näin ollen BGP-analogia ei koko
laajuudessaan toimi, koska sen skaalautuvuus perustuu aggregointiin.
Tilaajien vapaa siirtyminen operaattorilta toiselle aiheuttaa siis sen, että siirtymisistä on lähetettävä
tieto verkon reunoille eli jokaiselle tilaajaoperaattorille. Mikäli edellä kuvatussa tilanteessa C ei
mainostaisi täydellistä luettelonumeroa, A luulisi, että C:n alueella on myös kaikki muut
mainostetun etuliitteen tilaajat. Tilaajan saavutettavuus voidaan varmistaa vain, jos siirtynyttä
tilaajaa mainostetaan täydellisellä luettelonumerolla. Jos tilaaja 94513444 siirtyy operaattorin C
alueelle, on myös sitä mainostettava täydellisellä luettelonumerolla. Aggregointi onnistuu
ainoastaan silloin, kun kaikki 9451344X-tilaajat ovat siirtyneet samalle alueelle. Tällaista
järjestelmää palvelee parhaiten monistettu numerotietokanta, josta reititystietoa haetaan
puhelukohtaisesti. Tilaajan antamaan numeroon ei oikeastaan soiteta ollenkaan, vaan sitä käytetään
ainoastaan tietokanta-avaimen muodostamiseen. Reititysnumero on se numero (tai sen numeron
16
etuliite), johon A-tilaaja soittaisi, mikäli B-tilaaja ei ole siirtynyt. Sen sijaan VoIP-päätelaitteiden
numerot ovat aina loogisia ellei suoraan käytetä B-tilaajan IP-osoitetta.
2.6.2 Tietokantojen kasvu
Aggregoinnin soveltaminen siis vaikeutuu, ja siirtyneille tilaajille se onnistuu vain
poikkeustapauksissa, joten väistämättä numerotietokantojen koko kasvaa. Ottaen vielä huomioon
suuri prosessointiylijäämä TRIP:ssä, tietokannat voivat kasvaa erittäin vaikeasti hallittaviksi.
Pahimmassa tapauksessa joudutaan jokaista päätelaitetta mainostamaan omalla tietueella, ja näin
ollen saattaa tietueiden kokonaismäärä nousta kymmeniin miljooniin. Diplomityön [5] mukaan
TRIP-tietueen koko on vähintään 39 tavua. Ottaen huomioon melko merkittävän toisteisuuden, voi
tietokantojen koko nousta vaikeammin hallittavaksi. TRIP:ssä jokainen palvelin suorittaa
itsenäisesti taulujen prosessoinnin päivitystilanteissa. Käytännössä tällöin alueiden sisäiset
palvelimet ovat jatkuvasti epäyhtenäiset, mikäli palvelimia on monta, sillä 50 miljoonan tilaajan
keskuudessa tapahtuu lukumääräisesti paljon siirtymisiä. Yhden GB:n suuruisen tietokannan
levittäminen on hyvin raskasta, mutta keskitettynä sellainen on vielä helposti hallittavissa.
2.6.3 Synkronointi
TRIP:n ongelma on myös alkusynkronointi, mikäli sitä käytetään numeron siirrettävyyden
toteutukseen. Tietokannat ovat suurempia kuin Internet-reitityksessä, jossa siis käytetään BGB:tä.
Alkusynkronointi on näin ollen hitaampaa. Verkon kapasiteettia kuluu paljon alkusynkronoinnin
aikana ja palvelimien tila on huono operaation aikana. Laskennalliseen tehokkuuteen perustuvien
skaalautuvuusongelmien merkitys on tosin nykyisin pienentynyt, koska tietokoneiden laskentateho
on merkittävästi kasvanut. Esimerkiksi 1 GB:n tietokannan monistaminen kuormittaa myös verkkoa
aika tavalla, sillä siirtonopeudella 10 Mbit/s jo pelkän datan siirtämiseen kuluu aikaa yli 13
minuuttia. Se on nopeus, jolla täytyy jo ainakin olettaa selvittävän, koska muuten arkkitehtuurista
tulee kallis perustaa ja ylläpitää. Hallintaliikenteelle pitää olla aina riittävästi kaistaa verkossa,
mutta ainakin Internetissä hallintaliikenne (esimerkiksi reititysprotokollat) kilpailee samasta
siirtokapasiteetista asiakkaiden lähettämän liikenteen kanssa, ja näin ollen hallintaliikenne vähentää
asiakkaiden saamaa kaistaa verkossa.
2.7 Päämäärät
Luultavasti missä tahansa ratkaisussa numeron siirrettävyys aiheuttaa sen, että joudutaan
hallitsemaan lopulta miljoonien tietueiden numerotietokantoja. TRIP/CTRIP:ssä herättää ihmetystä
ennen kaikkea se, miksi levittää tietoa siirtyneistä numeroista monimutkaisten ns. ”välikäsiä”
sisältävien protokollien avulla, kun kerran siirtynyttä tilaaja on joka tapauksessa mainostettava
täydellisellä luettelonumerolla kaikille. Loogisesti keskitetty tietokanta tukee parhaiten tällaista
palvelua. Luotettavuuden lisäämiseksi ja palvelukapasiteetin nostamiseksi tietokanta on
monistettava useisiin paikkoihin. TRIP:n arvo on ennen kaikkea yhdyskäytävän sijaintiongelman
ratkaisussa. Luettelonumeroihin ei sisälly mitään politiikkatietoa, mikäli ne ovat siirrettäviä. Sen
17
sijaan reititysnumeroihin sisältyy politiikkatietoa: Ilmaisevathan ne sen, minkä operaattorin asiakas
on kyseessä. Näin ollen siis TRIP:llä kannattaa mainostaa ainoastaan topologiasidonnaisia
numeroita. IP/SCN-yhdyskäytävän sijaintiongelma koskee ennen kaikkea reititysnumeroita, eli kun
on annettu televerkon tilaajalle topologiaan perustuva reititysnumero, valitaan sen perusteella
sopiva yhdyskäytävä. Yhdyskäytävän sijaintiongelma on ilmeinen ja TRIP:lle on selvästi tarve
ainakin mikäli IP-pohjaisesta televiestinnästä tulee tasavertainen vaihtoehto piirikytkentäisille
kiinteän verkon liittymille tai piirikytkentäisille mobiiliverkoille, mutta numeron siirrettävyys
kannattaa toteuttaa TRIP:stä erillisillä tietokannoilla. Näin TRIP:iä käytetään juuri kuten
dokumentissa [4] esitetään. Reititys siis erotetaan numeron siirrettävyydestä. Topologiaan
perustuvia numeroita voidaan tehokkaasti aggregoida, joten skaalautuvuusongelmaa TRIP:n kanssa
ei tule. Myös alueen sisäinen TRIP-tietokantojen synkronointi toteutetaan em. dokumentin
mukaisesti. Diplomityössä [5] esitetyn ratkaisun mukaisesti numerotiedon levittämiseen käytetään
Internetiä, vaikka lopullinen ratkaisu [Luku 7] ei otakaan kantaa mihinkään verkkokerroksen
asioihin. Ratkaisun tulee olla skaalautuva ja tehokas sekä luotettava. Numeropalvelun tulee toimia
jokaista puhelua muodostettaessa ja antaa aina oikean reititystieto. Myöhemmin luvussa 8 todetaan,
että kyseessä on periaatteessa varsin yksinkertainen tiedonhallintaongelma. Sopivia standardeja on
ennestään numerotiedon levitykseen [Luku 4], mutta jonkinlainen yleisesti hyväksytty standardi tai
sopimus on määriteltävä koskien erityisesti päivitystietueen lähettämisessä tarvittavia SQL-kyselyjä
[Kappale 8.2.4]. Tästä eteenpäin näkökulma aiheeseen on hyvin sovelluslähtöinen. Numeron
siirrettävyyttä käsitellään ennemminkin kehitettävänä palveluna kuin jonakin geneerisenä
protokollana. Ohjelmistoissa noudatetaan standardeja rajapintoja.
Sekä reititysalueiden sisäisessä että ulkoisessa tiedonvälityksessä käytetään luotettavaa
kuljetuskerroksen protokollaa. Koska kyse on Internetistä, käytetään TCP:tä [18]. Virkistyssanomia
ei numerotietoihin normaalisti lähetetä, vaikka sellainen onkin mahdollista esittämäni ratkaisun
puitteissa. Numerotietojen tallennuksessa tulee käyttää luotettavia järjestelmiä. Edelleen pidetään
kiinni tavoitteista, että televerkon tilaaja voi siirtyä IP-verkkoon ja päinvastoin. Numeropalvelun
korkea käytettävyys edellyttää tietokantojen monistamista. Levypohjaisetkin järjestelmät voivat
vikaantua. Mikään tekninen järjestelmä ei ole täysin luotettava, joten levypohjaisenkin järjestelmän
korruptoituminen on mahdollista. Näin ollen täytyy olla aina menetelmä, jolla korruptoituneen
tietokannan tila voidaan palauttaa toimivaksi.
18
3 Relaatiotietokannat
Tässä luvussa esitetään lyhyesti relaatiotietokantojen viitteellinen rakenne ja joitakin keskeisiä
tietokantasuunnittelussa huomioon otettavia näkökohtia ja tehokkuutta. Esimerkkitietokantana
käytetään MySQL:ää [19].
3.1 Relaatiotietokantojen rakenne
Tietokantapalvelin koostuu fyysisen tietokannan lisäksi kolmesta funktionaalisesta osasta [20].
Kuvassa 3.1 esitetty rakenne on yksinkertaistettu. Esimerkiksi autentikointi jätetään huomioimatta.
KyselynkäsittelijäKyselynkäsittelijä
DB
MuistinhallitsijaMuistinhallitsija
Transaktionhallitsija
Transaktionhallitsija
Kyselyt
KyselynkäsittelijäKyselynkäsittelijä
DB
MuistinhallitsijaMuistinhallitsija
Transaktionhallitsija
Transaktionhallitsija
Kyselyt
Kuva 3.1. Relaatiotietokannan rakenne
Muistinhallitsija huolehtii tiedontallennuksesta levylle ja tiedonsiirrosta levyltä keskusmuistiin.
Kyselynkäsittelijä tutkii vastaanotetun kyselyn ja ratkaisee sen perusteella suoritettavat luku- ja
kirjoitusoperaatiot. Vaiheeseen saattaa sisältyä myös kyselyn optimoija, joka järjestää operaatiot
siten, että transaktio tapahtuu mahdollisimman tehokkaasti. Kyselyt vastaanotetaan usein
tekstimuodossa, mutta kehittyneemmät järjestelmät tukevat myös binäärisiä kyselyjä. Transaktion
hallitsijan tehtävänä on erityisesti huolehtia siitä, että tietokannan viite-eheys (engl. referential
integrity) säilyy. Täytyy myös huomioida, että samanaikaisesti järjestelmässä saattaa olla useita
käyttäjiä. Tavallisesti relaatiotietokannat toteutetaan asiakas/palvelin-arkkitehtuuriksi, jossa siis
asiakas lähettää kyselyjä palvelimelle, ja palvelin suorittaa siihen liittyvät operaatiot. Mahdollisesti
palvelin lähettää myös dataa asiakkaalle (SQL SELECT). Kyselyt ovat SQL-kielisiä lauseita.
19
3.2 Tiedon haku
3.2.1 Indeksointi
Varsinainen data sijoitetaan pysyväismuistin tiedostoihin. Eri ohjelmistovalmistajien ratkaisut
eroavat merkittävästi sen suhteen, miten tiedostoja sijoitellaan. Tarkastellaankin tässä vain
yleisimpiä periaatteita käyttäen MySQL:ää esimerkkitietokantana. Jokaisella attribuutilla on oma
paikkansa muistissa. Relaation määrittelyssä attribuuteille annetaan yksikäsitteiset tietotyypit, jotka
määräävät sen, kuinka paljon muistia kukin tietue vaatii. Esimerkiksi kokonaisluku käyttää
tavallisesti neljä tavua. Tiedostoon tietueet sijoitetaan sekventiaalisesti. Näin ollen ilman
indeksointia haut ovat hitaita. MySQL:ssä [19] on useita eri taulutyypejä. Normaalisti (ISAM-
taulut) itse datalle, indeksoinnille sekä taulun määrittelyille on omat tiedostonsa1, joten yhteensä
taulua kohden luodaan siis ainakin kolme tiedostoa. Avaimille luodaan aina indeksointi. Käyttäjä
voi luoda indeksoinnin myös muille attribuuteille. Indeksoinnissa käytetään nykyisin tavallisesti B+
puuta [21] (ISAM/VSAM). Käyrät kuvassa 3.2 kuvaavat indeksoinnin vaikutusta (S=Sun Solaris,
L=Debian Linux, W=Windows 2000).
Kuva 3.2. MySQL: n suorituskyky
1 MySQL:ssä indeksitiedostolla on ekstensio .MYI, tauluilla .MYD ja taulun määrittelyillä .frm.
20
Tulokset perustuvat omiin mittauksiin sekä Solaris- Windows- että Linux-käyttöjärjestelmissä.
Ilman indeksointia hakuaika kasvaa likimain lineaarisesti, kun taas haut käyttämällä indeksoitua
avainta tapahtuvat käytännössä vakioajassa. Kuvaajan lukuarvot kertovat palvelimen
maksimisuorituskyvystä, kun testit suoritettiin yhdellä asiakkaalla paikallisesti. Lukuarvot on saatu
mittaamalla seuraavaan kyselyyn kuluva aika:
SELECT * FROM $table WHERE col1=$key
Lukuarvoissa on mitattu kyselyn muodostamisesta (asiakas) datan vastaanottamiseen (asiakas)
kuluva aika. Verkon viivettä ei siis huomioida, koska operaatio suoritetaan paikallisesti. Kyseessä
on siis mahdollisimman yksinkertainen kysely. Arvioitaessa tiedonhallintajärjestelmien
skaalautuvuutta kokonaisuudessaan on myös verkon viive otettava huomioon. Kuvaajat eivät kerro
mitään siitä, kuinka palvelimet kestävät kuormitusta. Jokainen haku on suoritettu siten, että taulut
ovat välimuistissa, eli levyllä ei tarvitse käydä. Itse mittaustulokset eivät kovinkaan paljon ainakaan
käytännössä riipu siitä, mitä SQL:n perusoperaatioista (INSERT, UPDATE, SELECT, DELETE)
käytetään, koska kaikissa joudutaan suorittamaan (mukaellen) yllä esitetyssä kyselyssä tapahtuva
hakuprosessi. Tosin INSERT-operaatiossa ei tarvitse, mikäli attribuuttia col1 ei ole määritelty
avaimeksi.
Parempia tuloksia saatiin MySQL-palvelimella, jota ajetaan AMD Athlon (800 MHz) prosessorilla
Windows 2000- ja Debian Linux-käyttöjärjestelmässä. Sunin1 Blade 100 (Ultra Sparc 500 MHz) ei
osoittautunut yhtä tehokkaaksi. Tässä tapauksessa CPU-nopeus on ratkaisevampi ominaisuus kuin
32/64-bittisyys. Sun Bladella suoritetut haut ovat yllättävänkin hitaita, jos vertaa Debian Linuxilla
saatuihin tuloksiin. Nopeat vasteajat ovat varmin tae järjestelmän skaalautuvuudesta mutta eivät siis
suoraan kerro, kuinka järjestelmä kestää kuormitusta. Kuormitustestienkään tulokset eivät
välttämättä ole aukottomia, koska pullonkaulat saattavat syntyä muualle kuin itse järjestelmään –
esimerkiksi verkkoon. MySQL pystyy suorittamaan useita hakuja samanaikaisesti. Kuvaan 3.2
viitataan useasti työn loppuosassa, joka käsittelee toteutusta luvuissa 6 ja 7 sekä skaalautuvuutta
luvussa 8.
3.2.2 Kyselyn käsittely
Eräs perinteisten relaatiotietokantojen heikkous on kyselyn käsittelyyn kuluva aika. Edellä esitetyn
testin [Kuva 3.2] perusteella ei voi voida kovinkaan tarkasti arvioida itse hakurakenteen
tehokkuutta. Indeksoinnin vaikutus tosin näkyy erittäin selkeästi. Todellisuudessa haku on paljon
nopeampi kuin mitä tulos 0.8 ms (alin kuvaaja) esittää. Tekstimuotoisen kyselyn käsittely vie itse
asiassa suurimman osan ajasta. Jokaiselle kyselylle on suoritettava toistuvat
kyselynkäsittelyprosessit, vaikka useimmiten tiettyyn palvelimeen kohdistuvat haut ovat hyvin
samankaltaisia – jopa täysin samoja. Erityisesti muutaman asiakkaan ympäristöissä kuten www-
1 http://www.sun.com/desktop/sunblade100/
21
palvelimissa, SQL-kieliset kyselyt on upotettu jollakin tavalla (esim. PHP, CGI) HTML-koodiin.
Normaali Internetin käyttäjä ei tavallisesti lähetä SQL-kyselyjä palvelimelle, vaan Internet-
sisällöntuottaja on määrittänyt tietyt joka transaktiossa toistuvat SQL-kyselyt, joilla tietokantaa
käsitellään. Käyttäjä saattaa tosin HTTP-protokollan metodeilla (GET, POST) lähettää kyselyn
attribuuteille arvot. Suositulla www-sivulla saattaa olla kymmeniä tuhansia asiakkaita päivässä,
mistä johtuen samoja tai ainakin samankaltaisia kyselyjä suoritetaan palvelimella suuria määriä.
Kyselyn parsiminen aina uudestaan ja uudestaan tuhlaa prosessointitehoa. Toisaalta myös
kuittausten käsittely ja odottelu hidastaa sarjassa lähetettäviä kyselyjä, koska kyseessä on
asiakas/palvelin-arkkitehtuuri.
Varsinaiseen tiedonhakuun kuluvaa aikaa voidaan paremmin arvioida hieman pidempien kyselyjen
avulla. Määritellään taulun attribuutit (col1 int primary key, col2 int). Ensisijaisavaimen (engl.
primary key) eheysrajoite aiheuttaa sen, että lisättäessä uusi tietue tulee etsiä avainta aivan kuten
SELECT-operaatiossa, jotta viite-eheyden säilyminen voidaan varmistaa. Mikäli avain löytyy, tulee
uusi tietue hylätä. Kokeillaan seuraavaa kyselyä:
INSERT INTO $table VALUES (1,1),(2,2),…,($n,$n)
Vaihtoehtoisesti voisi jokaisen monikon lisätä erikseen, jolloin kyselynkäsittelyprosessin joutuisi
ajamaan uudelleen jokaiselle monikolle. Tarkastellaan yhden monikon lisäämiseen vaadittavaa
aikaa muuttujan n eri arvoilla:
Kuva 3.3. MySQL Insert
22
Havaitaan [Kuva 3.3], että muuttujan n arvoilla välillä 500...4000 saavutetaan maksiminopeus.
Esimerkiksi arvolla n=1024 saadaan kyselyyn kuluvaksi ajaksi kokonaisuudessaan 12.2ms ja yhden
alkion lisääminen veisi tällöin (kuvaaja) noin 12µs. Jopa tämäkin tulos on liian pessimistinen,
koska yli 1000 alkiota sisältävän tekstimuotoisen kyselyn (noin 10kB) läpikäyminen vie varmasti
aikaa. Etu transaktion nopeudessa saavutetaan kuitenkin siksi, että kyselyjä on ainoastaan yksi.
Tämäkin antaa silti jo melko suuren hakunopeuden – 5 miljoonaa riviä minuutissa. Testi on
suoritettu Windows 2000:ssa. Kyselynkäsittely muuttuu suuremmilla arvoilla siinä määrin
raskaaksi, että alkion lisääminen alkaa hidastua. Transaktionopeus (tpm-arvo [22]) tulee laskea aina
kyselyjen lukumäärän perusteella. Sen selvittäminen vaatii ehdottomasti hajautetun testiympäristön,
koska asiakkaita tarvitaan useita. Kun asiakkaita on paljon, alkaa palvelimen
prosessointikapasiteettia kulua paljon yhteyksien ylläpitoon, ja haut hidastuvat. Kyselyjä generoiva
asiakas voi yhtä hyvin olla transaktiokykyä rajoittava tekijä kuin palvelinkin. Kokonaisuudessaan
transaktioon kuluva aika koostuu asiakkaan puoleisesta prosessointiajasta, palvelimen
kyselynkäsittelystä ja hakuajasta sekä verkon aiheuttamasta viiveestä.
3.2.3 Proseduurihaut
Proseduurihauissa (engl. stored procedures) ei kyselyjä tarvitse kääntää enää suoritusvaiheessa.
Kysely käännetään proseduurin määrittelyn yhteydessä binääriseksi. Haettaessa tietoa tai
käsiteltäessä muuten tietokantaa kutsutaankin proseduuria eikä lähetetä tekstimuotoista kyselyä.
Esimerkiksi haettaessa taulusta käyttäjän määrittelemästä taulusta käyttäjän määrittelemällä
avaimella voidaan luoda proseduuri [23]:
CREATE PROCEDURE GET_DATA @TABLE, @F_KEY WITH ENCRYPTION AS SELECT *
FROM @TABLE WHERE COL1=@KEY
Haettaessa data lähetetään palvelimelle ainoastaan proseduurin nimi (GET_DATA) sekä
parametrit(taulun nimi + avain). Palvelin kutsuu proseduuria annetuilla parametreilla. Tällä
säästetään siinä, että kyselyä (SELECT * FROM TABLE WHERE COL1=$KEY) ei tarvitse parsia,
vaan voidaan siirtyä suoraan suoritusvaiheeseen. Edellä esitetty kysely on niin yksinkertainen, ettei
sen kehittäminen proseduuriksi tarjoa kovin suurta hyötyä, mutta jonkin verran kuitenkin [Taulukko
3 sivulla 73]. Monimutkaisemmat kyselyt sen sijaan kannattaa aina kehittää proseduuriksi, koska
tällöin saadaan huomattavasti tehokkaampia hakuja. Nykyaikaisessa tietokantasuunnittelussa tulisi
aina pyrkiä proseduurihakuihin jopa yksittäisissä kyselyissä, mikäli se ylipäätään on mahdollista.
Vapaan lähdekoodin tietokannat (MySQL, PostgreSQL, mSQL) eivät tue proseduurihakuja.
Esimerkiksi Microsoft SQL:n [23] Sybase Transact-SQL-kieli sekä Oraclen PL/SQL
mahdollistavat proseduurien luomisen. Edellä esitetty kysely on proseduurina noin 30-40%
nopeampia kuin normaalisti kyselynkäsittelijän kautta suoritettuna (Microsoft SQL Server).
23
3.2.4 Kyselyjen tallettaminen välimuistiin
Kyselyvälimuistilla (engl. query cache) voidaan osittain paikata proseduurihakujen puutetta. Ne
sopivat erityisesti ympäristöihin, jossa tietokantapalvelin käsittelee runsaasti täsmälleen samoja
kyselyjä ja tietokannan sisältö on melko staattinen. Kyselyn täytyy olla täsmälleen sama, kuin
aikaisemmin suoritettu, jotta välimuisti toimisi. Jos lähetetty kysely löytyy välimuistista, ei sitä
tarvitse parsia eikä kutsua edes mitään proseduuria, kuten proseduurihauissa. Kyselyn tuottama
tulos luetaan suoraan välimuistista. Parhaimmillaan tekniikka tarjoaa vielä paremman
suorituskyvyn kuin proseduurihaut. Mikäli vanha kyselyn tuottama data muuttuu, täytyy kysely
ehdottomasti poistaa välimuistista, jotta ei olisi mahdollista tarjoilla vanhentunutta tietoa. Suurin
ongelma on nimenomaan se, että kyselyjen tarvitsee olla täysin identtisiä. Esimerkkinä tarkastellaan
seuraavia kyselyjä:
SELECT * FROM TABLE WHERE KEY=773
SELECT * FROM TABLE WHERE KEY=772
Kummatkin tarvitsisivat oman tietueen välimuistiin. Tekstimuotoisena esitetyn kaltainen lause vie
noin 30 tavua + data. 100000 vastaavanlaista kyselyä veisi jo 3MB+data eli muistia kuluu paljon.
Esimerkiksi MySQL mahdollistaa kyselyvälimuistin käytön.
Sekä proseduurihauilla että kyselyvälimuistilla on haittansa, mutta niillä voidaan joissakin
tapauksissa merkittävästi parantaa tiedonhallintajärjestelmän suorituskykyä. Proseduurihaut
aiheuttavat merkittävästi ylijäämää tietokantoihin. Tietokannan alustaminen on paljon raskaampaa,
mikäli se tukee proseduraalisia kyselyjä. Ohjelmistoista tulee paljon raskaampia, koska siihen
täytyy sisällyttää kääntäjä (engl. compiler), joka kääntää monipuolisen SQL-kielen mukaiset
kyselyt binääriseksi. Myös kyselyvälimuisti hieman hidastaa hakuja tapauksissa, jossa kyselyä
etsitään välimuistista, mutta sitä ei kuitenkaan löydy. Toisaalta päivitystilanteissa joudutaan
suorittamaan myös välimuistin prosessointia, jotta sen kautta ei tarjottaisi vanhentunutta tietoa.
Prosessointi siis tulee raskaammaksi, joten kyselyvälimuisti sopii erityisesti mahdollisimman
staattisiin tietokantoihin, joihin kohdistuu paljon samanlaisia kyselyjä.
3.2.5 Datavälimuisti
Kyselyvälimuistilla tarkoitetaan aivan eri asiaa kuin varsinaista datavälimuistia. Suurehkoilla
tietokannoilla toimittaessa tehokkaasti datavälimuistin käyttö on välttämätöntä. Tällöin haut
kohdistuvat muistiin (RAM) eivätkä levylle. Datavälimuisti jakautuu indeksivälimuistiin ja
tauluvälimuistiin. Usein etenkin moniattribuuttinen indeksointi vie jopa enemmän muistia kuin itse
data. Jos indeksoinnille ei riitä muistia, tapahtuu erittäin radikaali hakujen hidastuminen. Ainakaan
käytännössä haut eivät hidastu merkittävästi, kun koko tietokanta on muistissa [Kuva 3.2], ja
käytetään indeksejä. Vastaavasti taulujen lukumäärän kasvattaminen ei sekään hidasta hakuja
edellyttäen, että muistia on tarpeeksi.
24
3.2.6 Redundanssi
Käsiteltäessä tietokantoihin liittyvää redundanssia tulee erottaa varmennukseen liittyvä redundanssi
sekä tiedon toisteisuuteen liittyvä redundanssi. Ensin mainittuun normaalisti pyritään, eli
tavoitellaan parempaa luotettavuutta tai skaalautuvuutta monistamalla tietokanta eri paikkoihin.
Tiedon toisteisuudesta sen sijaan pyritään tavallisesti pääsemään eroon osittamalla tietokantaa
ainakin jossain määrin, koska tietokannan koon kasvaessa sen hallinnointi vaikeutuu ja usein myös
haut hidastuvat. Kummassakin tapauksessa puhutaan usein redundanssista. Relaatiotietokannat
tarjoavat oivia välineitä toisteisuuden poistamiseen. Normaalimuotojen teorian (BCNF) [21]
mukaisesti redundanssi voidaan poistaa systemaattisesti, mutta usein jo ”terveellä järjellä”
ajattelemalla voidaan tietokantaa osittaa järkevästi.
88119451
D_NUMBER945129451394514945179451
OPERATORNetCOM
PhoneCOM
GATEWAY94512400
NULLNetCOM 94512400
PhoneCOM NULLLocalCOM NULL
88119451
D_NUMBER945129451394514945179451
R_NUMBER94518811
OPERATORLocalCOMPhoneCOM
NetCOM
GATEWAYNULLNULL
94512400
R_NUMBERS
R_NUMBERS
R_INFO
88119451
D_NUMBER945129451394514945179451
OPERATORNetCOM
PhoneCOM
GATEWAY94512400
NULLNetCOM 94512400
PhoneCOM NULLLocalCOM NULL
88119451
D_NUMBER945129451394514945179451
OPERATORNetCOM
PhoneCOM
GATEWAY94512400
NULLNetCOM 94512400
PhoneCOM NULLLocalCOM NULL
88119451
D_NUMBER945129451394514945179451
88119451
D_NUMBER945129451394514945179451
R_NUMBER94518811
OPERATORLocalCOMPhoneCOM
NetCOM
GATEWAYNULLNULL
94512400
R_NUMBER94518811
OPERATORLocalCOMPhoneCOM
NetCOM
GATEWAYNULLNULL
94512400
R_NUMBERS
R_NUMBERS
R_INFO
Kuva 3.4. Toisteisuuden poistaminen
Esimerkissä [Kuva 3.4] reititystietueen määrittävät reititysosoite, operaattori, sekä mahdollisesti
SCN/IP yhdyskäytävä. Useilla tilaajanumeroilla (etuliitteillä) on samat tiedot em. attribuuttien
osalta. Näin ollen on muistia haaskaavaa sijoittaa kaikki tiedot samaan relaatioon. Osituksessa usein
joudutaan asettamaan relaatioihin jokin keinotekoinen avain, mutta tässä tapauksessa reititysosoite
riittää erottamaan tietueet toisistaan. Edellä esitetyn osituksen jälkeenkään se ei ole välttämättä
vielä valmis vaan ositusta voisi jatkaa lisää. Attribuutit, joiden arvoihin jää toisteisuutta, kannattaa
määritellä mahdollisimman tehokkaasti esimerkiksi kokonaisluvuiksi. Esimerkiksi reititysosoitteille
25
saattaisi hyvinkin riittää lukualue 0...65535, jolloin sen voisi määrittää kahden tavun
etumerkittömäksi kokonaisluvuksi (smallint unsigned). Tämä edellyttäisi jonkin keinotekoisen
attribuutin (esimerkiksi R_NUMBER_ID) käyttöönottamista. Merkkijonojen käyttö on muistia
haaskaavaa. Osituksessa haut usein monimutkaistuvat. Esimerkiksi haettaessa numerolle 9451
yhdyskäytävää:
SELECT GATEWAY FROM R_NUMBERS WHERE D_NUMBER=9451 ÿÿÿÿ
SELECT GATEWAY FROM R_INFO WHERE R_NUMBER=SELECT R_NUMBER FROM
R_NUMBERS WHERE D_NUMBER=9451 tai vaihtoehtoisesti
SELECT R_INFO.GATEWAY AS GATEWAY FROM R_NUMBERS, R_INFO WHERE
R_NUMBERS.R_NUMBER=R_INFO.R_NUMBER AND R_NUMBERS.D_NUMBER=9451
3.3 Relaatiomalli
3.3.1 Relaation määritelmä
Relaatiomalli [21] perustuu matemaattisten relaatioiden teoriaan [esim. 24], mutta sen
ymmärtämiseksi riittää muutama peruskonsepti. Käytännössä relaatiomalli koostuu kolmesta osa-
alueesta:
a) Tiedon rakenne (engl. data structure)
Tieto esitetään kaksiulotteisina taulukkoina– riveinä ja sarakkeina [esim. Kuva 3.4].
b) Tiedon käsittely (engl. data manipulation)
Tiedon hallinnassa ja manipuloinnissa käytetään standardoitua SQL-kieltä.
c) Viite-eheys (engl. data integrity)
Tiedonhallintajärjestelmä vastaa ainakin osittain itse tietokannan viite-eheyden
säilyttämisestä.
Ensimmäiset relaatiotietokannat kehittivät IBM (System R) ja Kalifornia yliopisto (Ingres) jo 1970-
luvulla, mutta niiden toiminta oli erittäin rajoittunut tietokoneiden alhaisen laskentatehon vuoksi.
Ensimmäiset kaupalliset järjestelmät tulivat markkinoille 1980-luvun alussa.
Relaatiot ovat siis kaksiulotteisia taulukoita, mutta kaikki kaksiulotteiset taulukot eivät suinkaan ole
relaatioita. Seuraavat kuusi aksioomaa tulee olla voimassa, jotta taulukko olisi relaatio:
1. Nimeämisen yksikäsitteisyys
Jokaiselle relaatiolla on tietokannassa yksikäsitteinen nimi.
26
2. Tiedon yksikäsitteisyys
Jokaisen tietueen jokaisella attribuutilla on yksikäsitteinen arvo tai määrittelemätön arvo.
Tietueen attribuutilla ei voi olla samanaikaisesti useampaa arvoa.
3. Tietueiden yksikäsitteisyys
Jokainen rivi relaatiossa on uniikki, eli kahta samaa tietuetta ei voi olla. Tosin yksittäisen
attribuutin arvo avainta lukuun ottamatta voi olla sama useammallakin rivillä.
4. Attribuuttien yksikäsitteisyys
Jokaisella attribuutilla on yksikäsitteinen nimi.
5. Attribuuttien järjestyksen merkityksettömyys
Attribuuttien järjestyksellä ei ole merkitystä, eli sarakkeiden paikkoja voisi vaihtaa ilman,
että relaation tietosisältö muuttuisi ja hakutulokset muuttuisivat.
6. Rivien järjestyksen merkityksettömyys
Rivien järjestyksellä ei ole merkitystä, eli rivejä voisi vaihdella keskenään ilman, että
tietosisältö muuttuisi ja hakutulokset muuttuisivat.
3.3.2 Tietokantarelaation matemaattinen määritelmä
Olkoon lähtöjoukko A ja joukot B0, B1,…,Bn muita joukkoja. Tällöin tietokantarelaatio R on
tavallisesti kuvaus:
R: A → B0×B1×…×Bn
Huomattakoon, että seuraavat ehdot eivät välttämättä ole voimassa:
(1) A ∩ Bi = ∅, 0 ≤ i ≤ n
(2) Bi ∩ Bj = ∅, 0 ≤ i, j ≤ n ja i ≠ j
Koska A on joukko, se ei sisällä kahta samaa alkiota. Sen sijaan tulos B⊆ B0×B1×…×Bn on
monijoukko (engl. bag) ja saattaa näin ollen sisältää samoja alkioita. Nimitetään joukkoa A
relaation R avainjoukoksi. Monikkoja A×B0×B1×…×Bn kutsutaan relaation tietueiksi tai riveiksi.
Relaatiossa on yhtä monta tietuetta kuin on avaimia. Tässä avain koostuu siis ainoastaan yhdestä
attribuutista. Todellisuudessa avaimen voi muodostaa useampi attribuutti. Esimerkiksi
puhelinluettelossa nimi ei kaikissa tapauksissa toimi avaimena, koska samannimisiä ihmisiä voi olla
useita. Siksi tarvitaan jokin muu avain, jolla ihminen voidaan yksikäsitteisesti tunnistaa.
Puhelinluettelon tapauksessa esimerkiksi nimi ja kotiosoite yhdessä toimii jo paremmin avaimena:
On melko epätodennäköistä, että samassa osoitteessa asuu kaksi saman nimistä ihmistä.
Puhelinluettelo on klassinen esimerkki relaatiosta (tietokannasta):
27
A1 = nimet, A2 = osoitteet, B0 = puhelinnumerot ja R = puhelinluettelo. Tällöin puhelinluettelo R on
kuvaus:
R: A1×A2 → B0.
28
4 ODBC – Open DataBase Connectivity
ODBC on standardoitu pääsyrajapinta relaatiotietokantoihin. Tässä luvussa tutustutaan ODBC:n
viitteelliseen arkkitehtuuriin ja siihen, minkälaisiin tiedonhallintajärjestelmiin se on saatavilla.
Tutustutaan myös yksinkertaisen esimerkkiohjelman avulla käytännössä, mitä hyötyä ODBC:n
käytöstä on.
4.1 Miksi?
Olkoon jossakin SQL-tietokannassa relaatio (taulukko) ”tilaaja_numerot”, jonka attribuutit ovat
puh_numero (avain), reititysosoite ja verkkotyyppi. Tarkastellaan esimerkkinä yksinkertaista SQL-
kyselyä:
INSERT INTO tilaaja_numerot VALUES (”094512466”,”09451”,”SCN”)
Kysely on sekä MySQL- että PostgreSQL-syntaksin mukainen [19, 25], eli toimii siis molemmissa
järjestelmissä. Oletetaan, että esitetty monikko halutaan lisätä kahteen tietokantaan, joista toinen on
toteutettu MySQL:llä ja toinen PostgreSQL:llä. Ongelma liittyy yhteyden muodostukseen
asiakkaan ja palvelimen välillä eli siihen, miten kyselyn voi lähettää palvelimelle ja toisaalta siihen,
miten kysely käsitellään palvelimella [Kuva 4.1].
DB
DB
PostgreSQLServer
PostgreSQLServer
MySQLServerMySQLServer
PostgreSQLClient
PostgreSQLClient
MySQLClientMySQLClient
X
DB
DB
PostgreSQLServer
PostgreSQLServer
MySQLServerMySQLServer
PostgreSQLClient
PostgreSQLClient
MySQLClientMySQLClient
X
Kuva 4.1 MySQL vs. PostgreSQL
MySQL-asiakas (Client) ei pysty kommunikoimaan PostgreSQL-palvelimen (Server) kanssa.
Vastaavasti PostgreSQL-asiakas ei pysty kommunikoimaan MySQL-palvelimen kanssa. Eri
ohjelmistotuottajien ratkaisut eivät siis ole keskenään yhteensopivia. Tilanne on varsin valitettava,
koska itse kysely on sekä MySQL- että PostgreSQL-yhteensopiva, eli kysely suorittaa
kummassakin järjestelmässä juuri halutun operaation – lisää uuden rivin (monikon) relaatioon.
29
Usein myös itse kieliopit eri ohjelmistojen välillä eroavat toisistaan, mutta toiminnallisuus on
yhdenmukaista. Tosin esimerkiksi MySQL on toiminnallisuudeltaan suppeampi kuin PostgreSQL.
ODBC soveltuu esitetyn yhteensopimattomuusongelman ratkaisuun, mutta erityisesti sovellusten
(ohjelmien) siirrettävyys eri tiedonhallintajärjestelmiin on ODBC:n pääasiallinen toteutustarkoitus.
4.2 ODBC-rajapinta
4.2.1 ODBC-standardi
ODBC-standardi perustuu Opengroupin1 X/Open SQL-CLI määrittelyihin (SQL Call-Level
Inteface) [21], joka määrittelee standardin tavan ohjelmointikieliin kommunikoida SQL-pohjaisten
tiedonhallintajärjestelmien kanssa. Alunperin Microsoft alkoi kehittää yhtenäistä sovellusrajapintaa
tietokantajärjestelmiin, jotta Microsoftin Windows-käyttöjärjestelmät soveltuisivat paremmin
tietokantasovelluksiin. Ohjelmistovalmistajista riippumaton standardi kuitenkin saatiin, ja nykyisin
ODBC on saatavilla kaikkiin tavallisimpiin UNIX-pohjaisiin järjestelmiin. ODBC tarjoaa
käyttäjälle standardin sovellustason rajapinnan SQL-pohjaisiin tietokantajärjestelmiin siten, että
loppukäyttäjän ei tarvitse välittää siitä, miten tietokanta on implementoitu eikä edes siitä, missä
tietokanta fyysisesti sijaitsee. Näin ollen ODBC:n avulla voidaan koota universaali tietokanta-
asiakas (engl. database client), jolla pääsee käsiksi mihin tahansa ennalta määriteltyyn
tiedonhallintajärjestelmään. Käytännössä se merkitsee sitä, että yhteen järjestelmään ohjelmoitu
ODBC-rajapintaa käyttävä sovellusohjelma voidaan siirtää mihin tahansa muuhun järjestelmään
riippumatta siitä, mikä järjestelmä on kyseessä edellyttäen, että ODBC on konfiguroitu tukemaan
sitä. ODBC tuki löytyy kaikkiin tavallisimpiin relaatiotietokantoihin: Oracle2, Microsoft SQL
Server, Microsoft Access[23], MySQL[19], PostgreSQL[25], mSQL3 jne. Microsoftin
ohjelmistoihin on erittäin laaja ODBC-tuki. Jopa Excel-taulukkolaskentaohjelmaa voidaan käyttää
ODBC-tietokantana.
ODBC on kieliriippumaton rajapinta eli ODBC-API on saatavilla moniin ohjelmointikieliin. Tässä
luvussa käytetään PHP:n [26] APIa esimerkkisovelluksissa, mutta numeron siirrettävyyteen
tarvittavat sovellukset [Kappale 6.1.1] on toteutettu C-kielellä. ODBC:n käyttö ei aiheuta mitään
muutoksia palvelimen puolella, eli palvelin ei tiedä kutsutaanko sitä suoraan omalla asiakkaalla vai
ODBC-rajapinnan kautta. Tämä on varsin suotuisa ominaisuus järjestelmien skaalautuvuuden
kannalta, sillä palvelimen toiminta ei hidastu. Toisaalta se tekee standardista löyhemmän, koska
jokaista palvelinta käyttävä asiakas täytyy sovittaa jokaisen palvelimen kanssa.
1 http://www.opengroup.org/
2 http://www.oracle.com
3 http://www.hughes.com.au/
30
4.2.2 ODBC:n komponentit
ODBC:n peruskomponentit ovat [19,21]:
• Sovellus (Application)
• Ajurit (Drivers)
• Ajurin hallitsija (Driver Manager)
• Konfigurointitiedosto (Config File)
Seuraavassa esitellään kunkin komponentin tehtävät.
Sovellus
Olkoon suoritettavana jokin operaatio, joka edellyttää tietokannan päivitystä. Operaation
(esimerkiksi tilaajan siirtyminen televerkossa toiselle reititysalueelle) osana saattaa olla vaikkapa
kappaleessa 4.1 esitetty esimerkkikysely, joten transaktion tulee tapahtua automaattisesti ilman
käyttäjän tekemää manuaalista tietokannan päivitystä. Kokonaisuudessaan operaatioon saattaa
sisältyä useampiakin transaktioita. Tällöin tarvitaan sovellus, joka käyttää ODBC-rajapintaa
yhteyden muodostukseen, kommunikointiin ja yhteyden sulkemiseen kummankin palvelimen
kanssa. Sovellus kutsuu ODBC-API:n tarjoamia funktioita. Kommunikointivaiheessa lähetetään
kyselyjä palvelimelle. Se voi sisältää myös esimerkiksi kyselytuloksen vastaanottamisen (SQL
SELECT). Tarvittaessa voidaan käyttää myös COMMIT/ROLLBACK-protokollaa [21] samalla
tavalla kuin ilman ODBC-rajapintaa kommunikoitaessa.
Ajurit
ODBC-ajuri on kaikkein keskeisin ODBC-arkkitehtuurin komponentti. Jokainen tietokannan
hallintajärjestelmä, joka tukee ODBC:tä, tarvitsee ODBC-ajurin piilottamaan järjestelmälle
spesifiset ominaisuudet. Se muuntaa standardit SQL-kyselyt järjestelmän ymmärtämään muotoon,
mikäli tämä on tarpeellista. Tarvittaessa se palauttaa myös kyselytuloksia sovellusohjelman
prosessoitaviksi. Useinkaan itse kyselyihin ei tarvitse tehdä muutoksia. Kaikkein olennaisinta on
yhteyden muodostaminen määrätylle tietokantapalvelimelle ja luotettavan kommunikoinnin
toteutus palvelimen kanssa. Siksi ajuri sisältää usein myös tarvittavat asiakaskirjastot (engl. client
libraries). Kaikkien ajureiden täytyy ymmärtää samaa kieltä, jotta sama sovellusohjelma voisi
toimia eri järjestelmissä.
Ajurin hallitsija
Ajurin hallitsija on kirjasto, joka hallinnoi kommunikointia sovelluksen ja ajureiden välillä. Se
prosessoi ODBC-API:n funktiokutsuja. Koska ajureita normaalisti on useita, tarvitaan hallitsija,
joka dynaamisesti lataa oikean ajurin ODBC-yhteyden muodostuksessa käytettävän funktion DSN-
parametrin perusteella. Oikea ajuri siis valitaan ajon aikana, ja samanaikaisesti voi olla käytössä
31
useita ajureita. Sovellusohjelmoijan ei tarvitse tietää mitään ajureista eikä ajurin hallitsijasta.
Ainoastaan DSN-parametri tulee asettaa oikein.
Konfigurointitiedosto
Konfigurointitiedostossa kuvataan jokainen tiedonhallintajärjestelmä, jonka kanssa halutaan
kommunikoida. Konfigurointitiedosto on nimeltään .odbc.ini. Sun Solariksessa (bash) tiedosto
löytyy esimerkiksi käyttäjän määrittelemän ympäristömuuttujan ODBCINI avulla. Vaihtoehtoinen
tapa on kirjoittaa tiedosto .odbc.ini käyttäjän kotihakemistoon. Windows NT/2000-
käyttöjärjestelmissä useimmiten määritellään tiedosto .odbc.ini hakemistoon C:\Winnt\. Tiedosto
on samansisältöinen riippumatta järjestelmästä. Tietokannat identifioidaan DSN:llä (Data Source
Name). Jokaiselle DSN:lle määritetään ajuri, joka näkyy hakemistopolkuna johonkin jaettuun
kirjastoon (.so UNIX-järjestelmissä, .dll Windowsissa). Kutsuttaessa tiettyä DSN:ää ajurin hallitsija
muodostaa yhteyden DSN:n määrittämään palvelimeen ja palauttaa kursorin sovellusohjelman
käyttöön. Kursorin välityksellä voidaan lähettää kyselyjä palvelimelle. Ajurin lisäksi määritellään
yhteysparametrit ja tietokannan nimi, jotta kaikki kyseiseen tiedonhallintajärjestelmään liittyvät
spesifiset ominaisuudet saadaan piilotettua.
Edellä esitettyä arkkitehtuuria kuvaa seuraava viitemalli:
DB1
SOVELLUSSOVELLUS
AJURI 1AJURI 1 AJURI 2AJURI 2 AJURI NAJURI N
..........
ODBC.INIODBC.INI
AJURIN HALLITSIJAAJURIN HALLITSIJA
DB2 DBN
DSN1
DSN1
DB1
SOVELLUSSOVELLUS
AJURI 1AJURI 1 AJURI 2AJURI 2 AJURI NAJURI N
..........
ODBC.INIODBC.INI
AJURIN HALLITSIJAAJURIN HALLITSIJA
DB2 DBN
DSN1
DSN1
Kuva 4.2. ODBC-viitemalli
Sovellusohjelmasta ajurin hallitsija saa siis DSN-identifikaation, jonka perusteella se käy
lataamassa oikean ajurin, jolla muodostetaan kursori sovellusohjelman käyttöön [Kuva 4.2].
32
ODBCINI-tiedosto sisältää myös DSN- kohtaiset yhteysparametrit. Parametrit voivat hieman
vaihdella eri tiedonhallintajärjestelmien välillä. Useimmiten tarvitaan ainakin käyttäjätunnus,
salasana ja IP-osoite tai aluenimi (DNS [3]) [27], koska nykyisin transaktiot suoritetaan useimmiten
Internetin välityksellä.
4.3 ODBC käytännössä
Tässä kappaleessa esitetään yksinkertaisten esimerkkiohjelmien avulla, miten ODBC toimii.
Esimerkkiohjelmat on toteutettu PHP:lla [26], joka on erinomaisen käyttökelpoinen kieli
käytettäväksi erityisesti tietokantasovelluksissa, erityisesti Internetin sisällöntuotannossa.
4.3.1 ODBC-esimerkki
Palataan esimerkkiin [Luku 4.1], jossa on kaksi erilaista tietokantaa, ja sen ohella esitettyyn SQL-
kyselyyn. Ilman ODBC:tä päivityksen tekeminen molempiin vaatii kaksi erillistä sovellusohjelmaa.
MySQL:n [19] sovellusohjelma:
<?php
#Connect to the MySQL Server$link=mysql_connect("pc108.tct.hut.fi","antti","superuser") or die ("Couldn't connect!");
#Execute the MySQL commandmysql_db_query("tilaaja_numerot","insert into DNUMBERS values(’094512466’,’09451’,’SCN’)”,$link);
#Disconnect the MySQL Servermysql_close($link);
?>
PostgreSQL:n [25] sovellusohjelma:
<?php
#Connect to the PostgreSQL Server$link=pg_connect("host=pc107.tct.hut.fi dbname=tilaaja_numerot username=antti password=superuser")or die ("Couldn't connect!");
#Execute the PostgreSQL commandpg_exec($link,"insert into DNUMBERS values(’094512466’,’09451’,’SCN’)");
#Disconnect the PostgreSQL Serverpg_close($link);
?>
Esitetyt skriptit ovat täysin toimivia. Ne ovat keskenään hyvin analogisia, mutta jokainen funktio
on eri niminen ja esimerkiksi yhteysparametrit syötetään aivan eri tavalla: MySQL vaatii kolme
parametria ja PostgreSQL:ssä kaikki kirjoitetaan yhteen merkkijonoon. Seuraavassa esitetään
ODBC-versio:
<?php
#Connect to the ODBC data source$link=odbc_connect("PC107PGSQL","antti","superuser") or die ("Couldn't connect!");
#Execute the SQL commandodbc_exec($link,"insert into DNUMBERS values(’094512466’,’09451’,’SCN’)");
33
#Disconnect the data sourceodbc_close($link);
?>
Yhteyttä muodostettaessa ensimmäisenä parametrina annetaan DSN. Myös käyttäjätunnus ja
salasana annetaan tässä ohjelmassa, vaikka ne löytyisivät myös ODBC.INI tiedostosta, mutta
tietoturvallisuuden vuoksi annetaan ne myös tähän funktioon. Voihan olla, että kaikilla käyttäjillä ei
ole oikeutta päästä tietokantoihin. Näin saadaan varmistettua, että sovellusohjelmoijalla on
tarvittavat privilegiot. Mikäli kaikkiin tarvittaviin tietokantoihin päästään samoilla tunnuksilla,
tarvitsee ainoastaan muuttaa DSN:ää vaihdettaessa tietokantaa eli yhteyden muodostavan funktion
ensimmäistä parametria.
4.3.2 ODBCINI-tiedosto
Seuraavassa esitetään vielä esimerkin avulla standardoitu ODBC.INI tiedoston rakenne [27]:
[ODBC Data Sources]PC107PGSQL=PostgreSQL on pc107PC108MySQL=MySQL on pc108
[PC107PGSQL]Driver=/usr/local/postgresql/lib/libpsqlodbc.soDescription=PostgreSQL DSNDatabase=tilaaja_numerotServername=pc107.tct.hut.fiPort=5432Username=anttiPassword="superuser"
[PC108MySQL]Driver=/usr/local/mysql/lib/libmyodbc3.soDescription=MySQL ODBC 3.51 DSNSERVER=pc108.tct.hut.fiPORT=3306USER=anttiPassword="superuser"Database=tilaaja_numerot
[ODBC]InstallDir=/usr/local/iODBC/lib
Tiedosto koostuu kolmesta osasta: DSN luettelo, DSN kuvaukset ja ODBC. Luettelossa luetellaan
kaikki tietokannat. DSN-kuvauksissa määritellään DSN:ien ajurit sekä yhteysparametrit. ODBC-
osaa ei muuteta. Se sisältää hakemistopolun ajurin hallitsijaan. Ohjelmistoille määritellään
valmistajakohtaiset parametrit. Kuten huomataan, eroavaisuuksia on. Mikäli halutaan ohjelmassa
päivittää PC107:n PostgreSQL:n sijasta PC108:n MySQL, vaihdetaan function odbc_connect
ensimmäisen parametrin paikalle ”PC108MySQL”.
4.3.3 JDBC – Java DataBase Connectivity
JDBC (Java DataBase Connectivity) [21] on ODBC:n kaltainen toimittajariippumaton rajapinta,
jolla javasovellukset voivat kommunikoida SQL-pohjaisten tiedonhallintajärjestelmien kanssa. Se
perustuu myös Opengroupin SQL-CLI-määrittelyyn [28]. Melko moniin relaatiotietokantoihin on
34
nykyisin myös JDBC-tuki (esim. MySQL, Oracle, Sybase). JDBC voi käyttää myös ODBC-
tietokantoja erityisten JDBC-ODBC-siltojen avulla (engl. JDBC-ODBC Bridge Driver), jolloin
tarvitaan myös ODBC-ajurin hallitsija. JDBC vaatii siis aina Javan toimiakseen. JDBC
mahdollistaa ODBC:tä helpommin tilanteen, jossa asiakasjärjestelmässä ei ole ajuria jokaista
tiedonhallintajärjestelmää varten, jonka kanssa tarvitsee kommunikoida. Sopiva ajuri voidaan
nimittäin ladata applet-ohjelmana verkosta.
35
5 Osoitteistus ja nimeäminen
Tässä luvussa selvitetään osoitteistusta ja nimeämistä tietoverkoissa. Pohditaan ennen kaikkea sitä,
miten ne vaikuttavat yhteyden muodostukseen ja kohteen paikannukseen.
5.1 Internetin nimipalvelu
Internetissä vastaanottajaa osoitetaan aluenimillä (DNS [3]), jotka periaatteessa ovat siirrettäviä.
Tosin DNS-järjestelmän kehittämiselle on aikoinaan ollut aivan toinen motiivi kuin aluenimien
siirrettävyys. Nimittäin palvelimien osoittaminen pelkästään IP-osoitteilla olisi käyttäjälle varsin
epämukavaa. Esimerkiksi pc107.tct.hut.fi on mukavampi kuin 130.233.154.107. Molemmat
osoittavat samaa palvelinta, mutta numerosarja on paljon vaikeammin muistettavissa. IP-osoitteet
sen sijaan eivät ole siirrettäviä: Mikäli päätelaite siirretään aliverkosta toiseen, sen IP-osoite
muuttuu. Sen sijaan saman aliverkon sisällä voidaan mahdollisesti säilyttää sama IP-osoite. IP-
osoitteiden siirrettävyys merkitsisi liian raskaita muutoksia reitittimien reititystauluihin.
MobileIP:ssä [29] voidaan kolmioreitityksen avulla antaa tilaajalle mahdollisuus säilyttää IP-
osoitteensa, vaikka hän siirtyisikin toiseen verkkoon, mutta siinä kyseessä onkin mobiilitekniikka.
Tilaajalle paketit välittävä verkko (reititin) vaihtuu MobileIP:ssä, jos hän siirtyy toiselle
reititysalueelle.
Kuvassa 5.1 suoritetaan sarja DNS-kyselyjä, jotka selvittävät alhaalla hierarkiassa sijaitsevan
Internet-päätelaitteen IP-osoitteen.
root
tct
hut
fi
NS1
NS1
NS
NS
1 23
4
5
NS3
NS2
tut NS
NS2
lut NS
root
tct
hut
fi
NS1
NS1
NS
NS
1 23
4
5
NS3
NS2
tut NS
NS2
lut NS
Kuva 5.1. Hierakkinen DNS-kysely
36
DNS on hierarkkinen palvelinjärjestelmä, jonka ylimmällä tasolla ovat juurinimipalvelimet, joita on
maailmassa 13 kpl [3]. Ne tietävät kaikkien kansallisten nimipalvelimien IP-osoitteet. Kun
nimipalvelin käynnistetään (tyhjä välimuisti), se kysyy pyydettäessä aluenimeen liittyvää
reititystietoa eli IP-osoitetta yhdeltä juurinimipalvelimista. Asiakas kysyy paikalliselta
nimipalvelimelta nimeä pc107.tct.hut.fi vastaavaa IP-osoitetta. Koska välimuisti on tyhjä,
paikallinen nimipalvelin ei tiedä IP-osoitetta. Niinpä kysytään yhdeltä juuripalvelimelta.
Juuripalvelin palauttaa listan .fi-alueen nimipalvelimien IP-osoitteista. Asiakkaan nimipalvelin
tekee kyselyn yhdelle näistä, mutta .fi-alueenkaan palvelin ei tiedä nimeä pc107.tct.hut.fi vastaavaa
IP-osoitetta. Palvelin kuitenkin palauttaa listan .hut.fi-alueen nimipalvelimista. Senkään
verkkoalueen nimipalvelin ei tiedä vastausta mutta palauttaa listan alueen .tct.hut.fi
nimipalvelimien IP-osoitteista. Näin oikea palvelin on löytynyt. Kysely kohdistetaan useimmiten
ensisijaiseen nimipalvelimeen. Se palauttaa lopulta osoitteen 130.233.154.107, minkä jälkeen vasta
varsinainen lähetys voi alkaa.
Normaalisti edellä kuvattua pitkää kyselyprosessia ei tarvitse suorittaa, sillä osoitteet löytyvät
nimipalvelimien käteismuisteista. Tietueilla on elinikä (TTL), jonka umpeuduttua tietue poistetaan.
Tavallinen TTL-arvo on esimerkiksi 86400 sekuntia eli yksi vuorokausi. Näin ollen esitetty
mekanismi on äärimmäisen skaalautuva. Näin on pakko olla, sillä kyselyjä tulee erittäin suuri
määrä. Jokainen sähköpostinlähetys vaatii DNS-kyselyn. Vielä suuremman kuorman aiheuttaa
www-sivujen selaaminen. Hyvin lyhyessä ajassa saattaa käyttäjä aiheuttaa kymmeniä tai jopa satoja
DNS-kyselyjä. Keskitetty palvelinjärjestelmä ei välttämättä toimisi. Useimmiten jokaisella piirillä
on ainakin yksi toissijainen nimipalvelin. Nimipalvelutietueita tarjoavien palvelinten tietokannat
täytyy synkronoida. Hajautetun arkkitehtuurin etu on se, että yksittäinen nimipalvelin ei normaalisti
ylikuormitu. Tietueiden määrä ei yksittäisessä palvelimessa kasva hallitsemattoman suureksi
hierarkkisen hajautuksen ansiosta.
DNS:n tietokanta-arkkitehtuuri siis mahdollistaa sen, että IP-osoitteen muuttuessa aluenimi voidaan
säilyttää. Hajautetulla arkkitehtuurilla on kuitenkin haittansa koskien aluenimien siirrettävyyttä.
Ajatellaan tilannetta [Kuva 5.1], jossa pc107.tct.hut.fi siirtyy toiselle reititysalueelle – siis eri
verkkoon. Tällöin verkkoalueen .tct.hut.fi on mainostettava siirtynyttä palvelinta uudella IP-
osoitteella. Tämä ei välttämättä ole sen intressi, koska vain omaan verkkoon kytketyistä
päätelaitteista ollaan ensi sijassa kiinnostuneita. Jos siis tilaaja siirtyy esimerkiksi verkkoalueen
.lut.fi reititysalueelle, nimipalvelukyselyt kohdistuvat silti alueen .tct.hut.fi nimipalvelimelle. Sen
sijaan koko alueen siirtyminen toiselle reititysalueelle ei aiheuta mitään ongelmia. Käytännön
sovellus on esimerkiksi se, että yritys jolle on allokoitu C-luokan verkko, vaihtaa Internet-
palveluntarjoajaa. Tällöinhän IP-osoitteet muuttuvat. Aluenimi voidaan säilyttää entisellään, ja
asiakkaiden ei tarvitse ottaa huomioon reititysalueen muutosta, koska sama URL käy edelleen.
Toisaalta DNS:n avulla toteutetut siirtymiset ovat melko hitaita, koska nimipalvelimen
välimuisteissa saattaa vanha tieto säilyä pitkäänkin. Keskitetty ratkaisu olisi pelkästään
siirrettävyyttä ajatellen paljon yksinkertaisempi toteuttaa.
37
DNS ei sellaisenaan ole ratkaisu numeron siirrettävyyteen liittyvään numerotiedon levitykseen. Se
on kuitenkin toiminnaltaan erittäin analoginen sen kanssa, miten puhelinnumeron siirrettävyys
vaikuttaa puhelun muodostukseen ottamatta kantaa siihen, toimitaanko televerkossa vai IP-
verkossa. Päätelaitteiden aluenimien voidaan ajatella vastaavan puhelinverkon luettelonumeroita.
Muunnos täytyy suorittaa luettelonumerosta reititysosoitteeseen aivan kuten DNS muuntaa
aluenimen IP-osoitteeksi. Puhelinverkon tapauksessa luettelonumeroa vastaa joko E.164 formaatin
mukainen reititysnumero tai IP-osoite, mikäli B-tilaaja on IP-verkon puolella.
5.2 ENUM
Aluenimeä .e164.arpa käytetään esitettäessä E.164 formaatin mukaiset osoitteet DNS-
järjestelmässä. Tällöin nimipalvelimia voidaan käyttää numeromuunnospalvelimina puhelua
muodostettaessa [30]. Esimerkiksi numero +358 9 4512466 voidaan esittää DNS-muodossa:
+358 9 4512466→→→→ 6.6.4.2.1.5.4.9.8.5.3.e164.arpa
Numeroiden järjestys siis käännetään. Alueen .e164.arpa nimipalvelimissa on tieto kansallisten
regulaattoreiden palvelimista. Toisin kuin Internetin aluenimille nimipalvelin analysoi tavallisesti
useamman kuin yhden osan URI:sta (Unified Resource Identifier). Tässä tapauksessa .e164.arpa
piirin nimipalvelin joutuu tutkimaan numerot (järjestyksessä) 3, 5 ja 8 ennen kuin avain on selvillä.
Kysely voi palauttaa esimerkiksi seuraavan tietueen:
$ORIGIN 6.6.4.2.1.5.4.9.8.5.3.e164.arpa.
IN NAPTR 10 10 “u” “tel+E2U” “!^.*$!tel:+358503582379!” .
Tällä tavoin voidaan numeromuunnos toteuttaa. Tässä tapauksessa alunperin lankapuhelimen
numero ratkaistaan GSM-numeroksi. Kysely voi palauttaa myös useampia tietueita. Preferenssien
avulla voidaan osoittaa näiden keskinäinen järjestys. Tällöin yhteyttä muodostettaessa voidaan
esimerkiksi ensiksi yrittää soittaa lankapuhelimeen. Jos B-tilaaja ei vastaa, soitetaan vaikkapa
kännykkään. Kyselyn suorittavasta sovellusohjelmasta riippuu, mitä saaduilla tiedoilla tehdään. Jo
nykyisin ENUM:ia käytetään IP-verkossa E.164 formaatin mukaisten puhelinnumeroiden
esittämisessä. ENUM tarjoaisi näin erittäin helpon tavan numeron siirrettävyyden toteutukselle
ainakin IP-verkossa. Sen käyttöön liittyy kuitenkin samat ongelmat kuin DNS-
palvelinjärjestelmässä. Hierarkkinen järjestelmä olisi kyllä äärimmäisen skaalautuva, mutta
ongelma on, että tilaajan siirtyessä reititystietoa kysyttäisiin vanhalta palveluntarjoajalta. Tämä ei
liiketoiminnallisessa mielessä ole kovin järkevää, koska asiakkaansa menettänyt operaattori ei
varmaankaan ole kiinnostunut palvelemaan siirtynyttä tilaajaa. Toisaalta nollasummapolitiikan
näkökulmasta voisi ajatella, että operaattori palvellessaan siirtyneitä tilaajia hyötyy itse saman
verran, koska muut operaattorit palvelevat sen verkkoon siirtyneitä tilaajia. Ongelma kuitenkin on
edelleen, että kuinka hyvin operaattori palvelee menetettyjä tilaajia. Tilaajaa palvelevalle
operaattorille voi aiheutua ongelmia siitä, että aiemmin samaa tilaajaa palvelleen operaattorin
palvelimessa on häiriöitä. Päivitysten hitaus voisi myös olla ongelmallista, koska välimuisteissa
38
saattaa vanha reititystieto pysyä pitkäänkin. Tosin jos numerotiedon ylläpidosta pystytään
laskuttamaan, operaattorit saattavat jopa pyrkiä ratkaisuun, jossa reititysnumero haetaan alun perin
B-tilaajaa palvelleelta palvelun tarjoajalta.
Mikäli ei haluta, että vanha operaattori on vastuussa siirtyneen tilaajan reititysinformaatiosta,
päädytään aina loogisesti keskitettyyn tai monistettuun palvelinarkkitehtuuriin. Jokaisessa
palvelimessa tulee olla jonkinlainen informaatio kaikista luettelonumeroista siirrettävyysalueella.
Sitä käytetään avaimena varsinaiseen reititystietoon. Itse reititystieto tiettyyn luettelonumeroon
liittyen saattaa kuitenkin vaihdella suurestikin reititysalueiden välillä. Jos kaikki numerot ovat
siirrettäviä, ilman tietokantahakua ei ole mahdollista tietää, mihin puhelu tulisi reitittää.
5.3 Numeron siirrettävyys nykyisin
Nykyisin numeron siirrettävyys Euroopassa ja Yhdysvalloissa on toteutettu älyverkoilla (IN) [2].
Kyseessä on keskitetty ratkaisu. Numerotiedot sijaitsevat esimerkiksi regulaattorin tietokannoissa,
joihin kyselyt suoritetaan riippumatta siitä kuka soittaa ja mihin [Kuva 5.2]. IN:n tarjoamat palvelut
ovat varsin rajoittuneita. Keskitetyn ratkaisun etuna on yksinkertaisuus, mutta IN:ssä numeron
siirrettävyyteen liittyvät tietokantojen päivitykset täytyy tehdä manuaalisesti.
NP database
SSF
SCF
SDF
SMS
SSF
SCF
SDF
SMS
NP database
SSF
SCF
SDF
SMS
SSF
SCF
SDF
SMS
Kuva 5.2. IN arkkitehtuuri
Normaalisti kysely suoritetaan siis paikalliseen SDF:ään (Service Data Function). SMS (Service
Management System) huolehtii regulaattorin tietokannan ja paikallisen SDF:n synkronoinnista.
Regulaattorin tietokantaan lähetetään tieto tilaajan siirtymisestä. Operaattorit tallettavat paikalliseen
SDF:ään siirtyneiden tilaajien luettelonumeroiden ja reititysnumeroiden välisen relaation. Luvussa
39
6 esitettävässä ratkaisussa on joitakin kuvan 5.2 arkkitehtuurin piirteitä, mutta tiedon levitys
tapahtuu automaattisesti.
5.4 Numeron siirrettävyys GSM-verkossa
GSM-verkossa vaaditaan vastaavanlainen tietokantahaku puhelukohtaisesti. Tietokannasta ei
kuitenkaan haeta GSM-tilaajan reititysosoitetta vaan tilaajaa palvelevan HLR:n reititysosoite, joka
on sekin E.164 formaatin mukainen [31]. Kyseinen HLR tietää VLR:n tarkkuudella, missä tilaaja
on. HLR kysely tehdään joka tapauksessa aina GSM-verkkoon päätyville puheluille. Nykyisin
puhelinkeskukset pystyvät GSM-numerosta päättelemään, miltä HLR:ltä reititystietoa kysytään.
Näin ollen numeron siirrettävyys aiheuttaa sen, että tarvitsee hakea tietokannasta B-tilaajaa
palvelevan HLR:n osoite, koska sitä ei enää tilaajanumerosta pystytä selvittämään. Kuvassa 5.1
soitetaan PSTN:stä GSM-verkkoon.
PSTNPSTN
GSMGSM
GMSC HLR
NDB
VLR
BSCPSTNPSTN
GSMGSM
GMSC HLR
NDB
VLR
BSC
Kuva 5.3. Numeron siirrettävyys GSM-verkossa
HLR pyytää reititysnumeron siltä VLR:ltä, jonka alueella kutsuttu tilaaja sijaitsee ja palauttaa
saadun reititysnumeron (E.164) puhelun muodostusprosessiin. GSM-verkon toiminta on hyvin
analoginen MobileIP:n kanssa sillä erotuksella, että bittivirtaa GSM-verkossa ei lähetetä
päätelaitteelle minkään välipisteen kautta (MobileIP:n HA). Kolmioreititystä ei siis GSM-verkossa
sovelleta. B-tilaajan sijainti määräytyy kuitenkin lähes yhdenmukaisella tavalla.
40
6 Numeron siirrettävyyden tavoitearkkitehtuuri
Tässä luvussa kuvataan yksityiskohtaisesti numeron siirrettävyyden tavoitearkkitehtuuri. Esittämäni
ratkaisun perusominaisuudet ovat numeron siirrettävyys piirikytkentäisessä verkossa (PSTN/ISDN,
GSM), IP-verkossa sekä siirtymiset näiden välillä. Käsitellään aluksi arkkitehtuuriin kuuluvien
komponenttien merkitystä. Sen jälkeen luvussa 7 esitetään vastaava toteutus.
6.1 Komponentit
6.1.1 Arkkitehtuuri
Kuvassa 6.1 esitetään kaikki tarvittavat komponentit sekä niiden englanninkieliset ja
suomenkieliset nimet.
Regulator
NDB
Service Provider X
AVCC
UDB
PNDB
PNAC
NA
RIS AVCC Advertisement Validity Checking Client
PNDB Ported Number Database
UDB Update Database
PNAC Ported Number Advertising Client
RIS Routing Information Server
NA Numbering Agent
NDB Numbering Database
AVCC Siirtymistiedon tarkistin
PNDB Siirtymistietokanta
UDB Päivitystietokanta
PNAC Siirtymistiedon levittäjä
RIS Reititystietopalvelin
NA Numerointiagentti
NDB Numerotietokanta
Regulator
NDB
Service Provider X
AVCC
UDB
PNDB
PNAC
NA
RIS AVCC Advertisement Validity Checking Client
PNDB Ported Number Database
UDB Update Database
PNAC Ported Number Advertising Client
RIS Routing Information Server
NA Numbering Agent
NDB Numbering Database
AVCC Siirtymistiedon tarkistin
PNDB Siirtymistietokanta
UDB Päivitystietokanta
PNAC Siirtymistiedon levittäjä
RIS Reititystietopalvelin
NA Numerointiagentti
NDB Numerotietokanta
AVCC Siirtymistiedon tarkistin
PNDB Siirtymistietokanta
UDB Päivitystietokanta
PNAC Siirtymistiedon levittäjä
RIS Reititystietopalvelin
NA Numerointiagentti
NDB Numerotietokanta
Kuva 6.1. Tavoitearkitehtuurin komponentit
Siirrettävyysalueella on joitakin päivitystietokantoja (UDB), joihin kaikkiin lisätään tietue tilaajan
siirtyessä. Kaikki päivitystietokannat toimivat toisistaan riippumatta, jolloin siis yhden tietokannan
vikaantuessa muut toimivat normaalisti. Siirtymistietokanta (PNDB) on esiaskel
päivitystietokantaan. Palveluntarjoajan verkossa toimiva siirtymistiedon levittäjä (PNAC) lähettää
tiedon tilaajan siirtymisestä siirtymistietokantaan. PNAC:n tehtävä on myös vahvistaa toisen
palveluntarjoajan asiakkaaksi siirtymiset omalta alueelta. Regulaattorin siirtymistiedon tarkistin
(AVCC) tarkistaa päivitystietueiden validiteetin. AVCC siirtää siirtymisinformaation
päivitystietokantaan (UDB), mikäli validointitarkistus osoittaa, että tietue voidaan vahvistaa.
Numerointiagentti (NA) palvelee yhtä tai useampaa numerotietokantaa (NDB). NA lukee
siirtymiset päivitystietokannasta ja päivittää saamansa informaation perusteella numerotietokannan.
41
Reititystietopalvelin (RIS) on puhelunmuodostuksessa palveleva tietokanta-asiakas, joka suorittaa
yhden tai useampia hakuja puhelua muodostettaessa. Se onkin työllistetyin elementti esitetyssä
arkkitehtuurissa. AVCC:n toiminnot voidaan toteuttaa myös tietokannan sisällä laukaisimilla tai
globaaleilla eheysrajoittimilla, jos tiedonhallintajärjestelmä tukee niitä. Kuvan 6.1 komponenteilla
voidaan numeron siirrettävyys toteuttaa kokonaisuudessaan siirrettävyysalueella. Palveluntarjoajan
alueen komponenteilla operaattori pystyy mainostamaan alueelleen siirtynyttä tilaajaa,
vahvistamaan alueelta siirtymiset sekä tarjoamaan tarvittavan reititystiedon puhelun
muodostukseen. Regulaattori voi tarvita myös NDB:n ja NA:n, jotta kaikki validointitarkistukselta
vaadittavat ominaisuudet voidaan toteuttaa.
6.1.2 Monistetut päivitystietokannat
Vastuu lähetyksen onnistumisesta jätetään kokonaisuudessaan sille siirtymistiedon levittäjälle
(PNAC), joka päivitystä alun perin yritti. Poistunutta tilaajaa ei tavallisesti mainosteta erikseen,
vaan siitä ilmoitetaan vahvistamalla uuden palveluntarjoajan lähettämä päivitystietue. Ratkaisussa
toteutetaan monistettu arkkitehtuuri. Se ei kuitenkaan tarkoita sitä, että jokaisella
numeropalvelimella olisi täsmälleen fyysisesti samanlainen tietokanta vaan sitä, että jokaisella
numeropalvelimella tai palvelinryhmällä on samanlainen tietosisältö. Ratkaisu perustuu
relaatiotietokantoihin. Relaatiotietokantoja käsitellään standardin ODBC-rajapinnan kautta.
Epäonnistunutta päivitystä yritetään lähettää uudestaan. Kuvan 6.2 mukaisesti päivitysten
toimittamisessa noudatetaan kaikilta kaikille periaatetta. Lähtökohta on, että jokaisella
siirrettävyysalueella toimii jokin riippumaton yhtiö tai regulaattori, joka huolehtii
päivityspalvelimien hallinnasta ja ylläpidosta. Jokainen siirrettävyysalueella toimiva operaattori
liittyy jonkin tai joidenkin päivityspalvelimen asiakkaaksi.
Service Provider X
PNDB PNDB
PNDB
PNDB
PNDB
Regulator
Service Provider X
PNDB PNDB
PNDB
PNDB
PNDB
Regulator
Kuva 6.2. Inkrementaalinen tietokantojen päivitys
Palveluntarjoajan PNAC ei pidä palvelimiin pysyvää yhteyttä vaan muodostaa yhteyden kuhunkin
palvelimeen aina tarvittaessa.
42
6.1.3 Luotettavuus
Eräs keskeisimmistä palvelinjärjestelmän tavoitteista on luotettavuus. Esitetyssä arkkitehtuurissa
päivityksen lähettäjä on vastuussa siitä, että päivitys menee perille. Mikäli yhteyden muodostus
palvelimeen ei onnistu tai PNAC ei muusta syystä pysty päivitystä suorittamaan, se yrittää
uudestaan. Sovelletaan eksponentiaalisesti kasvavaa väliaikaa päivitysyritysten suorittamisen välillä
tiettyyn rajaan asti (esimerkiksi kolme tuntia). Tällöin siis aina epäonnistuneen päivitysyrityksen
jälkeen PNAC kaksinkertaistaa väliajan uudelleenyritysten välillä. Rajan tultua täyteen väliaikaa ei
enää kasvateta. Mitään toissijaisia päivityspalvelimia ei PNAC:n näkökulmasta tarvita, koska
riittävä redundanssi saadaan aikaan asettamalla useita palvelimia [Kuva 6.2]. Inkrementaalisten
päivitysten etu on se, että kaikki palvelimet voivat toimia toisistaan riippumatta. Ne eivät siis olla
missään keskinäisessä riippuvuussuhteessa. Kehittyneet tiedonhallintajärjestelmät sisältävät
useimmiten jonkin synkronointiprotokollan, mutta niiden ongelma on raskas prosessointi ja se, että
palvelimet eivät olisi toisistaan riippumattomia. SCSP [32] on esimerkki synkronointiprotokollasta.
SCSP:n synkronointi perustuu siihen, että tarvittaessa verrataan palvelimien tietosisältöjä toisiinsa,
ja tarvittaessa kopioidaan tietokanta palvelimelta toiselle. On selvää, että tällainen ei toimi tarpeeksi
tehokkaasti suurilla tietokannoilla. Vastuun jättäminen päivityksestä tilaajaa mainostavalle
operaattorille edellyttää sovellustason kuittauksia. TCP [18] varmistaa, että data menee perille,
mutta ei tarjoa sellaisenaan takeita päivityksen onnistumisesta kokonaisuudessaan. Tässä mielessä
relaatiotietokannat ovat optimaalinen ratkaisu.
On huomattava, että kyseisille päivityspalvelimille [Kuva 6.2] lähetetään vain tiedot siirtymisistä.
Niihin ei siis kohdistu varsinaisia puhelunmuodostusvaiheen reititystietokyselyjä.
Päivityspalvelimen tiedoista sen sijaan muodostetaan numeropalvelimien tietosisältö. Kyseessä
ovat siis eri tietokannat.
6.2 Tietokannat
6.2.1 Päivitystietokannat
Tilaajan siirtyessä sen reititysosoite muuttuu. Tärkein tieto siis, joka päivityspalvelimelle
lähetetään, on tilaajanumeron ohella siihen liittyvä reititysnumero (osoite). Jokainen päivitys
identifioidaan tilaajanumerolla (tai etuliitteellä), reititysosoitteella sekä aikaleimalla, joka on
välttämätön, jotta tietyissä ongelmatilanteissa olisi mahdollista selvittää, mikä on uusin
reititysnumero tilaajalle. Viimeiseksi tullut korvaa aina kaikki aiemmin tulleet. Päivitystietokantoja
tyhjennetään jatkuvasti, jotta ne eivät kasvaisi liian suuriksi. Voidaan määritellä, että esimerkiksi
kaikki yli viikon vanhat tietueet hävitetään. Luotettavuussyistä voi olla kuitenkin perusteltua
säilyttää pidemmältä ajalta päivityshistoria. Siirtymisistä lähetetään tieto siis kaikkiin alueen
päivityspalvelimiin. Siirtymisten informaatio menee päivitystietokantaan (UDB)
siirtymistietokannan (PNDB) kautta, jotta mahdolliset vihamieliset osapuolet eivät pääsisi
korruptoimaan numerotietokantoja [Kappale 7.4.5].
43
6.2.2 Numerotietokannat
Todellisuudessa etenkin IP-verkon puolella saattaa olla siirrettävyysalueella jopa satoja
autonomisia alueita. Mikäli jokin autonominen alue (AS - esimerkiksi yritysverkko) on puhtaasti
asiakassuhteessa [13], se voi kohdistaa reititysnumerokyselyt ylemmän tason palveluntarjoajan
palvelimeen.
ServiceProvider B
NDB
ServiceProvider A
NDB
ServiceProvider C
NDB
AS F AS GAS DAS E
AS H
Regulator
UDB
AS = Autonomous System – autonominen alue
ServiceProvider B
NDB
ServiceProvider A
NDB
ServiceProvider C
NDB
AS F AS GAS DAS E
AS H
Regulator
UDB
ServiceProvider B
NDB
ServiceProvider A
NDB
ServiceProvider C
NDB
AS F AS GAS DAS E
AS H
Regulator
UDB
AS = Autonomous System – autonominen alue
Kuva 6.3. Numerotietokannat
Kuvan 3 asiakkuussuhteiden ei välttämättä tarvitse mukailla reititystason asiakkuussuhteita.
Kuvassa on yksinkertaisuuden vuoksi esitetty regulaattorilla ainoastaan yksi päivityspalvelin
(UDB). Palveluntarjoajat päivittävät numeropalvelimien sisältöä regulaattorin päivityspalvelimeen
saapuneiden muutostietueiden perusteella. Kaikki operaattorit ovat asiakkaita jollekin tai joillekin
päivityspalvelimille. Tilaajien siirtyessä lähetetään tieto jokaiselle päivityspalvelimelle. NA lukee
säännöllisesti UDB-tietokantaa, jolloin tieto siirtymisestä saadaan levitettyä verkon reunoille.
Tilaajaa palveleva puhelinkeskus tai merkinantopalvelinhan (esimerkiksi SIP-proxy IP-verkossa)
reititystietoa tarvitsee puhelua muodostettaessa. Kaikki autonomiset alueet eivät siis tarvitse
lainkaan omaa numeropalvelinta. Tällöin reititystietokysely kohdistetaan asiakassuhteessa olevaa
aluetta palvelevan operaattorin numeropalvelimeen. Esitetty arkkitehtuuri ei aseta mitään
rajoituksia sille, miten numeropalvelimien tietueet muodostetaan. Näin ollen operaattoreille jää
melko vapaat kädet suunnitella reititystietokyselyjä varten tarvittavat tietokannat. Ainoastaan
siirtymistietojen lähetys täytyy olla yhtenäistä.
44
6.2.3 Vaihtelevan mittaiset numerot
Tietokannan suunnittelua vaikeuttaa jonkin verran vaihteleva tilaajanumeron pituus.
Puhelinnumeroiden etuliitteille voidaan erottaa taulukot. Useimmat luettelonumerot ovat Suomessa
7-10 merkin pituisia mukaan lukien teleliikennealueen tunnus (esim. 9, 5, 19) tai mobiiliverkkojen
operaattoritunnus (esim. 40, 50, 41). Nolla alusta voidaan jättää huomioimatta. Jotkin
erikoisnumerot saattavat olla jopa pidempiä ja toisaalta esimerkiksi vaihteiden numerot voivat olla
vain 3-4 merkin mittaisia + teleliikennealueen tunnus. Numeroavaruuden käyttöaste ensimmäisten
numeroiden osalta on varsin korkea, koska asiakkaan kannalta on aina mukavampi, mitä lyhempi
hänen numeronsa on. Numeroiden epätasainen jakautuminen aiheuttaa sen, että tauluista tulee eri
kokoisia. Ratkaisusta tulee hieman mutkikkaampi, jos taulut jaetaan vaihtelevan mittaisille
etuliitteille, mutta tällöin saadaan suunnilleen yhtä suuria tauluja ja tietokannan suunnittelulle jää
enemmän vapautta. Oli rakenne mikä tahansa, tietokantahaut täytyy olla tehokkaita.
Vaihtelevan mittainen numeron pituus monimutkaistaa tietokantakyselyjä. Tällöin on PSTN:n
puhelun muodostuksessa käytännössä toimittava niin, että järjestelmä odottaa lisää numeroja niin
kauan kunnes reititysosoite on yksikäsitteisesti saatu. PSTN-verkossahan ei B-tilaajan numeroa
voida useinkaan lähettää kokonaisuudessaan (engl. en bloc sending) vaan ainoastaan merkki
kerrallaan (engl. overlap sending)1. Sen sijaan ISDN- ja GSM-verkoissa sekä IP-puheluissa voidaan
B-tilaajan numero lähettää kokonaisuudessaan. GSM-puhelimellahan ei edes pysty lähettämään
numeroita yksi kerrallaan. Tähän on varsin luonnollinen syy: GSM-verkkoon päätyvissä puheluissa
on alun alkaenkin tarvittu reititystiedon haku, koska tilaajan sijainti voi muuttua. Tietokantahaun
suorittaminen olisi huomattavasti vaikeampaa, jos B-tilaajan numero lähetettäisi merkki kerrallaan.
Ongelmaa ei ole, jos käytetään kiinteän mittaisia tilaajanumeroita. Varsinaiseen väylöitykseen usein
riittää muutama ensimmäinen merkki tilaajanumerosta [31]. Jotta järjestelmä voisi jäädä
odottamaan lisää numeroita, täytyy jokaisen saadun numeron jälkeen tehdä uusi tietokantakysely.
Muutenhan ei tiedettäisi tarvitaanko lisää numeroja vai ei. Numeropalvelimen tai
palvelinjärjestelmän tulee siis kestää melkoisen suuri kuormitus. Mikäli puhelinkeskuksen BHCA:n
(Busy Hour Call Attempts)2 maksimi on esimerkiksi yksi miljoona, täytyy sitä palvelevan
numeropalvelimen hallita jopa 10 miljoonaa transaktiota tunnissa johtuen juuri siitä, että puhelua
kohti joudutaan tekemään mahdollisesti useita kyselyjä.
1 Tästä eteenpäin käytetään termejä kertalähetys (en bloc sending) ja peräkkäislähetys (overlap sending)
2 BHCA = puheluyritysten lukumäärä kiireisimmän tunnin aikana
45
6.3 Puhelun muodostus
6.3.1 Reititysosoitteen haku
Puhelun muodostuksessa oletetaan, että jokainen numero on siirrettävä. Näin ollen kyselyt
suoritetaan jokaiselle puhelulle. Kun reititystietopalvelin (RIS) käynnistetään, se lataa muistiin
kuvauksen tietokannan rakenteesta. Tämä mahdollistaa sen, että tiedetään monenko saadun
numeron jälkeen ensimmäinen kysely täytyy suorittaa. Puhelinkeskuksesta tulee saada merkkejä
RIS:n käyttöön, jotta se pysyisi muodostamaan tietokantakyselyjä. Tässä diplomityössä ei tutkita,
kuinka kommunikointi asiakkaan ja puhelinkeskuksen välillä tapahtuu. RIS on joko integroitu
keskukseen tai jokin etäjärjestelmä (SDP). Sen täytyy joka tapauksessa olla reaaliaikaympäristössä
ja pystyä tukemaan tuhansia puhelunmuodostusprosesseja samanaikaisesti. Kuvassa 6.4 esitetään
puhelunmuodostus soitettaessa numeroon 4512466. Yksinkertaisuuden vuoksi teleliikennealueen
tunnusta ei tässä huomioida. Välttämättä ei kyselyjä tarvitse tehdä niin monta kuin kuvassa
esitetään, sillä tietokantahauista voidaan pidättäytyä, kunnes on vastaanotettu pienimmän
mahdollisen tilaajanumeron pituuden osoittama määrä numeroita.
NDBRISRIS
.
...
GET_DB_STR
(4)
(5)
(1)
QUERY(45,”1”)
RESPONSE
RESPONSE (NULL)
(6)
QUERY(45,”12466”)
RESPONSE(451)
RNUMBER(451)
IAM(4512466)
SETUP
INFO (4)
INFO (5)
INFO (1)
INFO (6)
.
.
NDBRISRIS
.
...
GET_DB_STR
(4)
(5)
(1)
QUERY(45,”1”)
RESPONSE
RESPONSE (NULL)
(6)
QUERY(45,”12466”)
RESPONSE(451)
RNUMBER(451)
IAM(4512466)
SETUP
INFO (4)
INFO (5)
INFO (1)
INFO (6)
.
.
Kuva 6.4. Puhelun muodostus
Harmaalla pohjalla oleva osa on implementoitu tässä diplomityössä. Ensimmäinen kysely
(GET_DB_STR) ei liity yksittäisen puhelun muodostamiseen. Siinä ladataan RIS:n muistiin
myöhemmin esitettävällä tavalla [Kappale 7.3.3] tietokannan rakenne. Rakennekuvauksen
46
perusteella päätetään käyttäjän lähetettyä numerot 4 ja 5, että tietokantahakua ei tarvitse suorittaa ja
odotetaan lisää numeroja. Kolmannen merkin jälkeen suoritetaan kysely tauluun ”45”, josta haetaan
avaimella ”1”. Kysely ei tässä tapauksessa tuota yksikäsitteistä tulosta, joten tarvitaan edelleen lisää
merkkejä. Tässä tapauksessa tarvitaan B-tilaajan numeron kaikki merkit, ennen kuin yksikäsitteinen
reititysnumero saadaan. Se palautetaan puhelinkeskukseen numeroanalyysiä varten.
Numeroanalyysin jälkeen siirrytään normaaliin puhelunmuodostusmerkinantoon – esimerkiksi
ISUP:iin. Reititysnumeron 451 perusteella IAM (Initial Address Message) osataan lähettää B-
tilaajaa palvelevaan puhelinkeskukseen. Edellä kuvattu pätee tapauksiin, jossa A-tilaaja käyttää
peräkkäislähetystä. Mikäli B-tilaajan käyttää kertalähetystä, proseduuri muuttuu hieman. Tällöin ei
tarvitse tehdä tavallisesti niin monta tietokantakyselyä. Puhelua muodostavasta reititysalueesta
riippuu, ylläpidetäänkö omaa numerotietokantaa vai suoritetaanko kyselyt jonkin isäntäoperaattorin
palvelimeen. Analogia DNS-järjestelmän [Luku 5.1] kanssa rikkoutuu, koska reititysosoite haetaan
aina lähimmältä numeropalvelimelta. Kyseessä ei siis ole DNS:n kaltainen hierarkkinen
palvelinjärjestelmä.
6.3.2 Luettelonumeroiden aggregoinnin vaikutus
Luettelonumeroiden aggregoinnilla saavutetaan se, että operaattorin ei tarvitse levittää tarkkaa
tietoa tilaajista verkkoon. Etenkin tilaajien tarkka lukumäärä voidaan pitää salassa. Tiedonhallinnan
kannalta aggregoinnin vaikutus on kaksijakoinen: Toisaalta se pienentää tietokantojen kokoa, mutta
toisaalta monimutkaistaa merkittävästi tietokantahakuja sekä päivityksiä. Se myös aiheuttaa
merkittävästi ylimääräistä operointia verkossa esimerkiksi soitettaessa numeroon joka ei ole
käytössä. Mikäli olisi tarkasti tiedossa jokainen tilaaja, jo reititystietokyselyn jälkeen tiedettäisiin
onko annettua B-tilaajaa olemassa. Mikäli numerot 451, 452, 454 aggregoidaan yhdeksi tietueeksi
”45”, soitettaessa numeroon 453 luullaan, että kyseinen tilaaja on olemassa. Numeron siirrettävyys
kuitenkin aiheuttaa sen, että aggregoinnin teho pienenee, koska yksittäisiä siirtymisiä on
mainostettava tarkalla luettelonumerolla. Sen sijaan tilaajaryhmien siirtymisissä voidaan
aggregointia edelleen käyttää ainakin joissakin tapauksissa.
Aggregoituja tietueita etsitään tietokannasta pisimmän osuman periaatteella (engl. longest match).
Esimerkissä [Kuva 6.4] haetaan taulusta 45 ehdoilla ”1”, ”12”, ”124”, ”1246” kunnes haku ehdolla
”12466” tuottaa yksikäsitteisen tuloksen. Aggregointi siis vähentää hakujen lukumäärää puhelun
muodostuksessa, mikäli A-tilaaja käyttää peräkkäislähetystä. Esimerkissä kaikki etuliitteen 45
luettelonumerot on sijoitettu samaan taulukkoon. Mikäli etuliitteelle 451 olisi oma taulukko,
tarvitsisi hakuja suorittaa edelleen yksi vähemmän, koska vasta neljän saadun merkin jälkeen
suoritettaisiin ensimmäinen haku.
Sen sijaan kertalähetyksen kannalta aggregointi lisää hakujen lukumäärää. Oletetaan, että etuliitteen
4512 numeroilla on kaikilla sama reititysosoite. Numeroon 4512466 soitettaessa haetaan avaimilla
”12466”, ”1246”, ”124” ja lopulta avaimella ”12”, joka tuottaa tuloksen. Haku on siis aloitettu
pisimmästä päästä. Toinen vaihtoehto olisi aloittaa haku lyhimmästä päästä eli avaimella ”1” kuten
alunperinkin, mutta usein kuitenkin hakuja tulee vähemmän, mikä lähdetään tarkimmasta
47
mahdollisesta numerosta. Ilman aggregointia yksi haku riittäisi. Jo nyt nähdään, että toteutuksessa
käytettävältä tietokanratkaisulta vaaditaan nopeita vasteaikoja yksinkertaisissa kyselyissä.
Monimutkaisten kyselyjen tehokas hallinta ei ole niin ratkaisevaa.
6.3.3 Vaadittu transaktionopeus ja tietokantakyselyjen kuorman jako
Esitetty arkkitehtuuri on erittäin mukautuva kuormituksen jakoon palvelimien välillä. RIS:llä [Kuva
6.4] voi olla samanaikaisesti yhteys useampaan numeropalvelimeen. Voidaan esimerkiksi sijoittaa
taulut kahteen eri palvelimeen, joihin kyselyjen kuorma jakautuu suhteellisen tasaisesti. Tällöin
voidaan esimerkiksi A-tilaajan lähettämän ensimmäisen tai muutaman ensimmäisen merkin jälkeen
valita numeropalvelin, josta reititystietoa haetaan. Seuraavassa esimerkissä [Kuva 6.5] soitetaan
numeroon 094512466. Ensimmäisen keskukselta saadun merkin jälkeen valitaan oikean
numeropalvelin (DB1). DB1 sisältää kaikki etuliitteen 9 luettelonumerot, eli numerot joiden
ensimmäinen merkki on 9. Näin ollen 9:llä alkavat luettelonumerot eivät aiheuta ollenkaan
kuormitusta toiseen palvelimeen (DB2).
NDB2
RISRIS
.
...
GET_DB_STR
(9)
(4)
(5)
QUERY(945,”1”)
RESPONSE
RESPONSE(NULL)
(6)
QUERY(945,”12466”)
RESPONSE(9451)
RNUMBER(9451)
IAM(94512466)
INFO(9)
NDB1
GET_DB_STR
RESPONSE
(1)
INFO(4)
INFO(5)
INFO(1)
INFO(6)
SETUP
.
.
NDB2
RISRIS
.
...
GET_DB_STR
(9)
(4)
(5)
QUERY(945,”1”)
RESPONSE
RESPONSE(NULL)
(6)
QUERY(945,”12466”)
RESPONSE(9451)
RNUMBER(9451)
IAM(94512466)
INFO(9)
NDB1
GET_DB_STR
RESPONSE
(1)
INFO(4)
INFO(5)
INFO(1)
INFO(6)
SETUP
.
.
Kuva 6.5. Hajautettu numerotietokanta
48
Ensimmäisen merkin lähetyksen jälkeen prosessi jatkuu kuten aiemmin esitettiin [Kuva 6.4]. Ainoa
haitta on, että RIS joutuu ylläpitämään useampia TCP-yhteyksiä. Näin hajauttamalla voidaan
merkittävästi vähentää yksittäiseen palvelimeen kohdistuvaa kuormaa. Valitusta toteutustekniikasta
riippuu, kuinka hajautettu arkkitehtuuri vaaditaan. Vaadittu transaktionopeus on miljoonan
BHCA:n liikennevolyymillä korkeintaan noin 10 miljoonaa yksinkertaista kyselyä tunnissa, joka ei
ole moderneille järjestelmille ja laitteistoille mitenkään ongelmallinen [22]. Kuvan 3.2 [sivu 19]
perusteella haut eivät ainakaan merkittävästi hidastu taulun koon kasvaessa. Alle 1 ms:n
absoluuttiset hakuajat takaavat hyvin skaalautuvan tiedonhallintajärjestelmän. Järkevillä
ohjelmistovalinnoilla voidaan järjestelmien hankinnasta ja ylläpidosta aiheutuvia kustannuksia
merkittävästi pienentää. Transaktiokyvyllä on aina hintansa.
6.3.4 Numerotietokantojen päivitys
Puhelun muodostuksessa palvelevan reititystietopalvelimen (RIS) kannalta numerotietokannat ovat
siis vain staattisia hakemistoja, joista haetaan reititysinformaatio. Verkossa on erilliset asiakkaat
(NA), jotka suorittavat hakuja päivitystietokantoihin ja päivittävät kyseisen tiedon perusteella
numeropalvelimet. NA:n täytyy siis ymmärtää sekä päivityspalvelimien että numeropalvelimien
tietosisältöjä. Tämä ominaisuus tekee niistä loogisesti ikään kuin yhdyskäytävän erilaisten
tiedonhallintajärjestelmien välillä. Tämä siis mahdollistaa sen, että eri operaattorit voivat käyttää
täysin erilaisia järjestelmiä numeropalvelimissa. Reititystietokyselyt kohdistuvat aina omiin
numeropalvelimiin, jolloin siis ei haittaa, vaikka muualta siihen ei pääse käsiksi. Sen sijaan
päivityspalvelimet on tehtävä yhdenmukaiseksi. NA:lla tulee olla kyky kommunikoida kumpaankin
suuntaan. Mikäli käytetään ODBC-rajapintaa [Luku 4] numeropalvelimiin ja päivityspalvelimiin,
NA saadaan sovitettua standardirajapinnan kautta kumpaankin palvelimeen.
Päivitystietokannassa (UDB) on siirtyneen tilaajan tilaajanumero ja reititysnumero.
Yksinkertaisimmin numerotietokannan päivitys voidaan hoitaa siten, että aluksi etsitään
luettelonumeroa vastaavaa tietuetta. Jos sellainen löytyy, päivitetään reititysnumeroksi uusi
reititysnumero. Jos ei löydy, lisätään uusi tietue. Ongelmana on kuitenkin aggregoidut tietueet.
Tietokannassa voivat olla esimerkiksi etuliitteet 4561, 4562,...,4568 sekä 456. Lisättäessä tietue
4569 jää 456 turhaksi, koska jokainen etuliitteen 456 jälkeinen neljän merkin mittainen etuliite on
käytössä. Jollain tavalla on siis huolehdittava, ettei turhia tietueita jää kasvattamaan tietokannan
kokoa. Päivitysten aiheuttama kuorma numeropalvelimiin on varsin vähäinen. Mikäli vuodessa
tapahtuu esimerkiksi 5 miljoonaa siirtymistä, joudutaan keskimäärin tunnin aikana tekemään noin
570 päivitystä. Toki päivityksen yhteydessäkin voidaan joutua tekemään useampia hakuja, mutta
hakujen lukumäärä harvoin nousee niin suureksi, että reititystiedon haku hidastuisi. Viisi miljoonaa
siirtymistä vuodessa on jo erittäin paljon. Päivitykset eivät kuitenkaan jakaudu tasaisesti, vaan
viikonloppuisin ja yöaikaan tapahtuu varmasti vähemmän siirtymisiä kuin päiväsaikaan, jolloin
täytyy varautua jopa tuhansiin siirtymisiin tunnin aikana.
49
6.4 Numeron siirrettävyys SCN/IP teknologiarajapinnan yli
6.4.1 Numerointi
Mikäli verkossa on yhteinen numerointi IP-verkon ja televerkon puhelimille, eivät päivitys- tai
numerotietokannat eroa millään tavalla sen mukaan, kumpaa verkkoa ne palvelevat. Reititysosoite
vain on erilainen riippuen siitä, kummalla puolella B-tilaaja on. Päivityksiä tukevatkin näin ollen
parhaiten tekstimuotoiset attribuuttien määrittelyt, koska reititysosoitteen arvon täytyy voida olla
joko IP-osoite tai E.164 reititysnumero. Tekstimuotoiset tietueet ovat tosin hieman muistia
haaskaavia, koska pääasiassa ne sisältävät numeroita. Puhelinnumerot saattavat sisältää joitakin
erikoismerkkejä (esimerkiksi #, * ja +) ja tekstimuotoinen IP-osoite pisteitä. Tekstimuotoista dataa
on kuitenkin helppo käsitellä. Puhelinnumeron esitys binäärisenä aiheuttaisi ongelmia
muodostettaessa pisimmän osuman mukaisia tietokantahakuja. Joku numerotietokannan etuliite
saattaa myös alkaa nollalla, mikä on varsin ongelmallista, jos käytetään kokonaislukuja. Useat
Internetin sovellustason protokollat (HTTP, SIP, RTSP) [8] ovat tekstipohjaisia.
6.4.2 Reititys
IP-osoitetta ei voida käyttää väylöityksessä televerkossa, mutta mikään ei silti estä mainostamasta
IP-osoitteita myös sinne. Jo osoitus siitä, että tilaajan reititysnumero on IP-osoite tietämättä
välttämättä kyseistä IP-osoitetta, antaa paljon informaatiota. Tällöin tiedetään, että puhelu täytyy
välittää yhdyskäytävälle. Miten sopiva yhdyskäytävä sitten löytyy, on aivan eri asia. Jos
jonkinlaista valintaa täytyy suorittaa, B-tilaajan IP-osoitetta voidaan käyttää avaimena. Näin ollen
on hyvinkin perusteltua levittää tietoa IP-osoitteista reititysnumerona myös televerkkoon. Mikäli
CTRIP:iä [5] käytetään, tulee sillä mainostaa nimenomaan yhdyskäytävän kautta saavutettavissa
olevia IP-osoitteita. Tämän mallin mukaisesti CTRIP konvergoituu melkein puhtaaksi BGP:ksi [9].
BGP:tä voisi käyttää sellaisenaan, mikäli sillä voisi mainostaa E.164-formaatin mukaista osoitetta
saavutettavana instanssina IP-osoitteen sijaan. Tällöinhän on käytössä kaikki, mitä verkkojen
yhteistoiminta ja numeron siirrettävyys vaatii: Siirrettävyyttä varten on numeropalvelu, jossa
E.164-formaatin mukainen luettelonumero muunnetaan reititysosoitteeksi. Jos havaitaan
soitettaessa IP-verkosta, että reititysnumero on E.164-formaatin mukainen, haetaan TRIP:n
muodostamasta tietokannasta sopiva IP/SCN-yhdyskäytävä käyttämällä saatua reititysnumeroa
avaimena. Jos havaitaan soitettaessa televerkosta, että reititysnumero on IP-osoite, haetaan
CTRIP:n muodostamasta tietokannasta sopiva SCN/IP-yhdyskäytävä käyttämällä saatua
reititysnumeroa avaimena. Mikäli teknologiarajapintaa ei tarvitse ylittää, ei yhdyskäytävähakua
luonnollisesti tarvita lainkaan. Tällöin kaikki TRIP:iin ja CTRIP:iin liittyvät
skaalautuvuusongelmat olisi ratkaistu. TRIP levittäisi saavutettavuustietoa yhdyskäytävien kautta
saavutettavista E.164 reititysnumeroista ja CTRIP yhdyskäytävien kautta saavutettavista IP-
osoitteista. Aggregointi näille onnistuu BGP:n tavoin. Nähtäväksi jää, tarvitaanko ylipäätänsä
CTRIP:iä tai edes TRIP:iä, vai valitaanko tarvittaessa sopiva yhdyskäytävä staattisesti. Karkeasti
ottaenhan tavoite on vain päästä IP-verkosta televerkkoon ja televerkosta IP-verkkoon. Ainakin
TRIP:n ja CTRIP:n kaltaiselle protokollalle tulee jättää optio.
50
Numeron siirrettävyys TRIP:llä [4] aiheuttaisi paljon turhaa prosessointia. Kuten jo todettiin,
tilaaja- tai tilaajaryhmäkohtaiset reititysosoitteet tulee joka tapauksessa olla saatavilla verkon
reunoilla, kun puhelua muodostetaan. Miksi levittää sitä monen solmun kautta soveltaen
politiikkoja, jos se kerran joka tapauksessa tulee levittää kaikkien saataville? Keskitetty
arkkitehtuuri palvelee paljon paremmin sellaista palvelua. Arkkitehtuurissa TRIP on siis
käytännössä melko staattinen hakemistopalvelu, josta haetaan yhdyskäytävän osoite IP-verkosta
televerkkoon päätyville puheluille. Staattinen se on siksi, että käytännössä päivityksiä tulee harvoin,
koska mainostetaan televerkon topologiaan perustuvia luettelonumeroita, jotka toimivat siis
reititysnumeroina jatkettaessa puhelun reititystä yhdyskäytävästä eteenpäin. TRIP-palvelimet
(Location Server) toimivat BGP:n tavoin mainostaen etäisyyttä kuhunkin yhdyskäytävään ja
numeroita, jotka kyseisen yhdyskäytävän kautta voidaan saavuttaa. Eräs hyvin merkittävä ero
BGP:n ja TRIP:n välillä on kuitenkin se, että TRIP on sovellustason reititysprotokolla, kun taas
BGP toimii verkkokerroksella. Normaalisti TRIP-informaatioon tulee muutoksia silloin, kun
verkkoon kytketään uusia yhdyskäytäviä tai yhdyskäytävän vaikutuksessa olevien operaattoreiden
keskinäiset suhteet muuttuvat. Toisaalta jonkin palvelimen vikaantuessa joudutaan TRIP:n
reititystauluja laskemaan uudelleen. TRIP:iä tarvitaan siis silloin, kun IP-verkosta soitetaan
televerkkoon päätyvä puhelu. Haettaessa TRIP-tietokannasta E.164-avaimella saadaan sopiva
yhdyskäytävä tai joukko sopivia yhdyskäytäviä, joista valitaan yksi sisäisen politiikan mukaisesti.
TRIP-tietokanta voi olla samalla tai eri palvelimella numeropalvelimen kanssa.
6.4.3 Puhelun muodostus
Kuvassa 6.6 esitetään esimerkkitapaus, jossa muodostetaan puhelu televerkosta IP-verkkoon. On
oletettu, että televerkossa käytetään DSS1-signalointia pääsyverkossa ja ISUP-signalointia
keskusten välillä. IP-verkossa käytetään SIP-signalointia [8]. Numerointiyhdyskäytävä-nimi
(NGW) on lainattu diplomityöstä [5]. Se on jossain määrin harhaanjohtava, koska mallissa TRIP ja
CTRIP eivät kommunikoi. NGW on siis oikeastaan edellisen kappaleen TRIP/CTRIP-
rekonstruktion myötä vain TRIP-asiakas ja CTRIP-asiakas. NGW toimii saavutettavuustietojen
lähtöpisteenä. TRIP-asiakas mainostaa televerkosta IP-verkkoon puhelinnumeroiden etuliitteitä,
jotka osoittavat mitä reititysosoitteita on saavutettavissa NGW:n edustaman SGW/MGW:n (IP-
osoite) kautta milläkin etäisyydellä. CTRIP-asiakas mainostaa siis esimerkiksi BGP:llä
muodostettua IP-osoitteiden saavutettavuustietoa edustamansa SGW/MGW:n (E.164 numero)
kautta. Toistettakoon edelleen, että numeron siirrettävyys ei vaikuta TRIP:n eikä CTRIP:n tietoihin.
Yksinkertaisuuden vuoksi regulaattori ja päivityspalvelin (UDB) on jätetty kuvasta pois. UDB ei
suoranaisesti liity puhelun muodostukseen.
Mikäli kaikki B-tilaajan numeron merkit joudutaan analysoimaan reititysnumerokyselyä varten,
ISUP:n SAM-viestiä (Subsequent Address Message) ei enää tarvita edes muodostettaessa puhelu
peräkkäislähetyksellä.
51
Kuva 6.6. Esimerkki puhelun muodostuksesta
52
7 Tietokantojen toteutus
Tässä luvussa esitetään numerotietokantojen [Kappale 6.2.2] sekä päivitystietokantojen [Kappale
6.2.1] toteutus. Ratkaisu pohjautuu SQL-tietokantoihin. SQL-tietokannat voidaan suunnitella
käytettävästä tietokantaohjelmistoista riippumattomasti. Eri valmistajien relaatiotietokantojen
tehokkuus vaihtelee kuitenkin merkittävästi [Taulukko 3 sivulla 73]. Relaatiotietokantojen
tehokkuutta arvioitaessa tulee sitä analysoida nimenomaan lopullisen sovelluksen näkökulmasta.
Toinen voi olla tietyissä tapauksissa tehokkaampi kuin toinen, mutta vaihdettaessa sovellusta
tilanne saattaa muuttua. Edellisessä luvussa todettiin, että tarvitaan nopeita yksinkertaisia hakuja.
7.1 Tietokantasuunnittelu
7.1.1 Mallinnus
Tietokantasuunnittelu on monivaiheinen ja systemaattinen prosessi [21]. Se sisältää paljon
muutakin kuin SQL-kyselyjen kirjoittamisen. Aluksi tehdään normaalisti kattava sanallinen kuvaus
järjestelmän toiminnasta: Mitä palvelua järjestelmä tukee ja mitä tietoa tarvitaan palvelun
aikaansaamiseksi? Vielä siinä vaiheessa ei puututa mihinkään tiedon rakennetta koskeviin
seikkoihin. Seuraava vaihe on tietokannan mallintaminen abstraktilla tasolla. Tätä varten on
useampia vaihtoehtoja. Perinteisesti on käytetty ER-mallia, joka on UML:n sukuinen
mallinnusmenetelmä erityisesti tietokantasuunnittelua varten. Nykyisin erityisesti ORDBMS-
tietokantojen mallintamisessa käytetään ODL-kuvausta, joka on siis kieliriippumaton oliopohjainen
mallinnusmenetelmä. Se soveltuu silti myös perinteisten relaatiotietokantojen mallinnukseen. Tässä
vaiheessa määritetään yksilöjoukot (ER) tai luokat (ODL) sekä niiden väliset suhteet ja attribuutit.
Myös ensisijaisavaimen eheysrajoitteet esitetään jo tällä abstraktiotasolla.
ER- tai ODL-kaaviot muutetaan seuraavassa vaiheessa relaatiomallin [Kappale 3.3] mukaiseksi.
Muunnokselle on erittäin selkeät säännöt [20, 21], jonka mukaan toimittaessa saadaan relaatiot
muodostettua oikein. Tällöin usein tietokantaan syntyy tarpeetonta toisteisuutta [Kappale 3.2.6],
jonka poistaminen on eräs keskeisimmistä käytännön tietokantasuunnittelun toimenpiteistä.
Järjestelmän tehokkuus saattaa olla niin keskeinen tekijä, että jonkin verran toisteisuutta kannattaa
hyväksyä tietokannassa. Relaatiomallissa esitetään kaikki relaatioiden nimet, attribuutit,
ensisijaisavaimet sekä viiteavaimet (engl. foreign key), mutta esimerkiksi attribuuttien tyypitys ei
kuulu tähän vaiheeseen erityisesti siitä syystä, että relaatiomalli säilyisi mahdollisimman
siirrettävänä. Voihan olla, että kaikki tietokantajärjestelmät eivät tue samoja tietotyyppejä.
7.1.2 Toteutus
Viimeisessä eli toteutusvaiheessa luodaan tietokanta relaatiomallin pohjalta SQL-kieltä käyttäen
(CREATE TABLE). Mikäli lähdetään liikkeelle tilanteesta, jossa koko infrastruktuuri kootaan
aivan tyhjästä, joudutaan tekemään myös valinta eri käyttöympäristöjen välillä. Varmennuksen
tulee olla sopusoinnussa sen kanssa, kuinka kriittisestä datasta on kysymys. Kriittisissä palveluissa
53
tietokanta hajautetaan fyysisesti eri palvelimiin siten, että yhden palvelimen vikaantuminen ei
aiheuta ainakaan koko palvelun estymistä. Yhä tärkeämpää on myös tietoturvallisuudesta
huolehtiminen. Usein kuitenkin ainakin fyysinen infrastruktuuri on jo valmiina, joten valinta
joudutaan tekemään ainoastaan ohjelmistojen välillä. Kaupallisille ohjelmistoille on nykyisin
vaihtoehtoja vapaan lähdekoodin tietokantaohjelmistoissa. Valinta riippuu tietenkin siitä, mitä
ollaan tekemässä. Kaupalliset ohjelmistot ovat toiminnoiltaan laajempia ja mukautuvampia, mutta
yksinkertaisemmissa palveluissa riittävät SQL:n perustoiminnot, jolloin vapaan lähdekoodin
tietokannat voivat olla paras vaihtoehto.
Relaatioita muodostettaessa attribuutit tyypitetään ja avainrajoitteet muodostetaan relaatiomallin
mukaan. Myös muut eheysrajoitteet (esimerkiksi laukaisimet) muodostetaan toteutusvaiheessa.
Kaikille rajoitteille ei ole standardoitua mallia ER-kaavioissa eikä edes relaatiomallissa.
Toteutusvaiheessa kirjoitetaan SQL-kyselyt, joilla tietokantahaut suoritetaan ja tietokantaa
päivitetään. Kyselyt suoritetaan jonkin rajapinnan (API) kautta. Suosituin tällainen API on juuri
ODBC, joka on saatavilla useisiin ohjelmointikieliin. Lähes poikkeuksetta tietokantakyselyissä
tarvitaan käyttäjän määrittelemät arvot attribuuteille, joten sovellusohjelmissa on oltava logiikka,
jolla SQL-kyselyjä voidaan luoda dynaamisesti. Hallintatoimenpiteitä varten ohjelmistoissa on
usein jokin interaktiivinen terminaali, jolla tietokantaa voi käsitellä syöttämällä manuaalisesti SQL-
kyselyjä.
ER-kaavion muodostaminen on välttämätöntä mutkikkaissa palveluissa, jotta yksilöiden väliset
suhteet näkyisivät mahdollisimman selkeästi ja toisaalta koko järjestelmä pysyisi helposti
ymmärrettävänä. Jos yksilöjoukkoja ja suhteita on paljon, kaavion osia voidaan yhdistää
korkeammalle abstraktiotasolle. Korkeimmalla abstraktiotasolla tulee olla aina riittävän vähän
yksilöjoukkoja ja suhteita, jotta järjestelmä olisi helposti ymmärrettävässä muodossa. Usein
korkeimmalla abstraktiotasolla tulee koko järjestelmän kuvauksen mahtua selkeästi yhdellä A4-
paperiarkille, jotta varmasti kaavio pysyisi ymmärrettävänä. Tässä diplomityössä kuitenkin
tietokannat ovat kokonaisuudessaan niin yksinkertaisia, että sanallisesta kuvauksesta hypätään
suoraan relaatiomalliin eli ER-kaavioita tai ODL-kuvauksia ei esitetä.
7.2 Käytetyt ohjelmistot
7.2.1 Relaatiotietokannat vs. hakemistot
Relaatiotietokantojen ja hakemistojen suurin ero on se, että hakemistot ovat luonteeltaan paljon
staattisempia. LDAP:n [33, 34] kaltaisten hakemistojen päivitykset ovat hitaita ja vaativat raskasta
prosessointia. Tiedon tallennusrakenne on hakemistoissa usein paljon monimutkaisempi kuin
relaatiotietokannoissa. Hakemistot ovat usein hajautettuja hierarkkisia järjestelmiä, joilla
saavutetaan erittäin skaalautuvia hakurakenteita. Relaatiotietokannat ovat paljon geneerisempiä.
Niissä datan prosessointiin käytetään standardoitua SQL-kieltä. Useinkaan ainakaan vapaan
lähdekoodin ohjelmistot eivät ole täysin standardin [35] mukaisia, vaan valmistajakohtaisesti
kehiteltyjä murteita. Joihinkin sisältyy erittäin laaja joukko myös epästandardeja laajennuksia ja
54
useimpiin (esim. MySQL) sisältyy laaja joukko mahdollisuuksia tietoturvan toteuttamiseksi, joita ei
ANSI:n SQL-standardi [35] määrittele. Yksinkertaisimmissa on vain tietyt perusfunktiot (mSQL).
Ne eivät kata standardia kokonaisuudessaan.
Relaatiotietokantojen päivittäminen lähettämällä SQL-kielisiä kyselyjä on paljon kevyempi
operaatio kuin hakemistojen päivittäminen. Numero- ja päivitystietokannat vaativat jonkin verran
myös päivityksiä, joten relaatiotietokannat ovat myös tässä mielessä sopivampia kuin hakemistot.
Relaatiotietokannat tarjoavat myös paremmat välineet tietokantojen viite-eheyden säilyttämiseen.
Valitettavasti vain eri ohjelmistovalmistajien tuotteen eivät ole keskenään yhteensopivia. Näin ollen
arkkitehtuurissa joudutaan joko spesifioimaan tuote, jota toteutuksessa käytetään tai määrittämään
jokin standardoitu rajapinta, jonka päälle numeron siirrettävyyteen liittyvät tietokantaoperaatiot
ohjelmoidaan (ODBC/JDBC).
7.2.2 MySQL
Tätä diplomityötä varten olen testannut erityisesti MySQL:n [19] tehokkuutta. MySQL on
ruotsalainen yritys, jolta on saatavilla laadukas tietokantaohjelmisto ilmaiseksi ainakin yliopistojen
ja muiden tutkimuslaitosten käyttöön (GPL-lisenssi). Se on siis vapaasti modifioitavissa ja
saatavilla moniin eri käyttöympäristöihin (Windows NT/2000, Sun Solaris, Linux).
Suorituskyvyltään se tuntuu olevan ylivertainen ainakin muihin julkisen lähdekoodin
tietokantajärjestelmiin verrattuna [Taulukko 3 sivulla 73]. Kaupallisiin tuotteisiin verrattuna
MySQL on paljon suppeampi, mutta tehokkuus yksinkertaisten kyselyjen käsittelyssä onkin nyt
ratkaisevampaa. Proseduraaliset haut [Kappale 3.2.3] eivät ole mahdollisia, mutta yksinkertaisissa
kyselyissä ei niistä saatava etu olekaan kovin suuri. MySQL on myös osoittautunut käytössä erittäin
stabiiliksi. Tuotekehityksessä pääpaino on tehokkuudessa. Uusiin ohjelmistoversioihin otetaan vain
sellaisia laajennuksia, jotka eivät laske tehokkuutta [19]. Moniin kaupallisiin ohjelmistoihin
verrattuna MySQL tarjoaa myös vähemmän eheysrajoitteita, joten viite-eheyden säilyttäminen jää
enemmän sovellusohjelmoijan vastuulle. Eheysrajoittimien käyttö (esim. globaalit rajoitteet) voi
olla merkittävästi etenkin päivityksiä hidastavaa.
7.2.3 Replikointi
Useimmat tiedonhallintajärjestelmät MySQL mukaan lukien sisältävät jonkinlaisen replikoinnin.
MySQL:ssä palvelu perustuu binäärilogiin, jonka avulla tietokannat synkronoituvat [19].
55
79 INSERT(:::)
151 UPDATE(...)
233 UPDATE(...)
277 INSERT(...)
299 LOAD DATA(...)
393 DELETE(...)
412 CREATE TABLE(...)
477 OPTIMIZE(...)
OFFSET OPERATION
79 INSERT(:::)
151 UPDATE(...)
233 UPDATE(...)
277 INSERT(...)
299 LOAD DATA(...)
393 DELETE(...)
412 CREATE TABLE(...)
477 OPTIMIZE(...)
OFFSET OPERATION
Kuva 7.1 Esimerkki MySQL:n binäärilogi
Binäärilogi [Kuva 7.1] sisältää osoittimen (OFFSET) kohtaan, jonka jälkeiset päivitykset tulee ottaa
huomioon synkronoinnissa. Mestaripalvelin (engl. master) ylläpitää binäärilogia, josta orjat (engl.
slave) hakevat päivitykset. Kun alkusynkronointi (LOAD DATA FROM MASTER) on suoritettu,
kaikki mestaripalvelimeen kohdistuvat päivitykset menevät orjille käytännössä reaaliajassa.
Menetelmä on siinä mielessä hyvä, että joskus menneisyydessä vallinneen tietokannan tilan avulla
(varmuuskopio) voidaan osoitinta käyttämällä tietokannan tila palauttaa ajan tasalle, edellyttäen
ettei logia ole tyhjennetty. Suurista tietokannoista ei pysty varmuuskopioita ottamaan kovin useasti.
Kun logi tyhjennetään, tulee jokaisen orjan tallentaa kuvaus tietokannastaan, joka voidaan palauttaa
vikaantumistilanteessa, ja tietokanta saadaan tämän jälkeen ajan tasalle lukemalla vain uusi logi.
Koko tietokantaa ei tarvitse näin ollen monistaa. Menetelmällä voidaan rakentaa puumainen
palvelinarkkitehtuuri, jossa jotkin palvelimet voivat olla sekä mestareita että orjia. Ongelma on
kuitenkin se, että samalla hetkellä orjalla ei voi olla kuin yksi mestari. Toki sitä voidaan muuttaa
(CHANGE MASTER TO). Suurin heikkous on se, että toistaiseksi palvelimet eivät suorita mitään
mestarin valintaprosessia vaan se konfiguroidaan staattisesti, joten mestarin vikaantuessa mikään
päivitys ei onnistu. Menetelmä on kuitenkin erittäin käyttökelpoinen varatietokantojen ylläpidossa
sekä tietokantahakujen kuorman jaossa.
56
7.3 Numerotietokanta
Regulator
NDB
Service Provider X
AVCC
UDB
PNDB
PNAC
NA
RIS AVCC Advertisement Validity Checking Client
PNDB Ported Number Database
UDB Update Database
PNAC Ported Number Advertising Client
RIS Routing Information Server
NA Numbering Agent
NDB Numbering Database
AVCC Siirtymistiedon tarkistin
PNDB Siirtymistietokanta
UDB Päivitystietokanta
PNAC Siirtymistiedon levittäjä
RIS Reititystietopalvelin
NA Numerointiagentti
NDB Numerotietokanta
Regulator
NDB
Service Provider X
AVCC
UDB
PNDB
PNAC
NA
RIS AVCC Advertisement Validity Checking Client
PNDB Ported Number Database
UDB Update Database
PNAC Ported Number Advertising Client
RIS Routing Information Server
NA Numbering Agent
NDB Numbering Database
AVCC Advertisement Validity Checking Client
PNDB Ported Number Database
UDB Update Database
PNAC Ported Number Advertising Client
RIS Routing Information Server
NA Numbering Agent
NDB Numbering Database
AVCC Siirtymistiedon tarkistin
PNDB Siirtymistietokanta
UDB Päivitystietokanta
PNAC Siirtymistiedon levittäjä
RIS Reititystietopalvelin
NA Numerointiagentti
NDB Numerotietokanta
AVCC Siirtymistiedon tarkistin
PNDB Siirtymistietokanta
UDB Päivitystietokanta
PNAC Siirtymistiedon levittäjä
RIS Reititystietopalvelin
NA Numerointiagentti
NDB Numerotietokanta
Kuva 7.2. Numerotietokannan elementit
7.3.1 Sanallinen kuvaus
Numerotietokannan tehtävänä on tuottaa reititysosoitteen hakupalvelu, joka palvelee
puhelunmuodostuksessa sekä piirikytkentäistä verkkoa että IP-verkkoa. Jokainen tilaaja ei ole
tietokannassa edustettuna täydellisellä luettelonumerolla, vaan kokonaista tilaajajoukkoa edustaa
jokin tilaajanumeron etuliite. Analogisen puhelinverkon tilaajat eivät pysty lähettämään B-tilaajan
numeroa yhdessä kokonaisena, vaan ainoastaan merkki kerrallaan. Näin ollen järjestelmän tulee
pystyä analysoimaan numeroita merkki kerrallaan, ja vastaanottamaan puhelukohtaisesti niin monta
merkkiä, että yksikäsitteinen reititysosoite saadaan. Vaadittu palvelulogiikka ohjelmoidaan
tiedonhallintajärjestelmän asiakaskirjastoa hyväksi käyttäen RIS:iin siten, että NDB suorittaa vain
yksittäisiä suhteellisen yksinkertaisia hakuja. Tietokanta on kaiken kaikkiaan hyvin yksinkertainen:
Luettelonumero tai luettelonumeron etuliite kuvautuu reititysosoitteeksi.
7.3.2 Relaatiomalli
Jokaisella luettelonumerolla tai sen etuliitteellä on yksikäsitteinen reititysosoite, joten kaikessa
yksinkertaisuudessaan relaatiomallin mukainen kuvaus on seuraava:
Subscribers(D_NUMBER, R_DATA_ID )
R_Data(R_DATA_ID, R_NUMBER)
Jatkuva viiva osoittaa, että attribuutti D_NUMBER toimii ensisijaisavaimena. Katkonainen viiva
attribuutin R_DATA_ID alla osoittaa sen olevan viiteavain. Tässä tapauksessa se on viiteavain
relaatioon R_Data, jossa kyseinen attribuutti on merkitty ensisijaisavaimeksi. Varsinainen
57
reititystieto on kyseisen relaation attribuutti R_NUMBER, joka on siis haettu reititysosoite. Jako on
tehty kahdeksi relaatioksi toisteisuuden välttämiseksi. Reititysosoitteita on paljon vähemmän kuin
luettelonumeroita, joten toisteisuuden välttämiseksi otetaan käyttöön uusi attribuutti R_DATA_ID,
joka voidaan toteutusvaiheessa määrittää esimerkiksi kahden tavun etumerkittömäksi
kokonaisluvuksi. Se vie täten muistia vain kaksi tavua, kun esimerkiksi IP-osoite (IPv4) veisi
tekstimuotoisena 7-15 tavua. On muistinkäytön kannalta edullisempaa, että usein toistuvia arvoja
saava attribuutti määritellään mahdollisimman vähän muistia vieväksi. Itse relaatiomallihan jättää
siis attribuuttien tyypityksen avoimeksi. R_NUMBER määritetään myös ainakin relaatiomallissa
viiteavaimeksi, koska reititysnumeron perusteella saatetaan hakea vielä yhdyskäytävä ja
mahdollisesti reitti. Kyseisen relaation tietosisältö voidaan siis koota esimerkiksi TRIP-
protokollalla.
7.3.3 Toteutus
Aivan edellä kuvatun yksinkertainen tietokannasta ei kuitenkaan tule. Tietokantaan kohdistuu
erittäin suuri määrä hakuja sekä jonkin verran päivityksiä. Ei ole kaikkein tehokkain ratkaisu
sijoittaa dataa kokonaisuudessaan (lähes) samaan relaatioon. Etenkään tiedon hajauttaminen
fyysisesti eri palvelimille on ongelmallisempaa, mikäli luodaan luettelonumeroille vain yksi
relaatio. Tässä tapauksessa hajauttaminen on hyvin helppoa, koska luettelonumerot eivät ole
keskinäisessä suhteessa. Tässä ratkaisussa hajautetaan tietokanta siten, että eri etuliitteiden
perusteella jaetaan luettelonumerot eri tauluihin, eli käyttäjän lähettämien ensimmäisten merkkien
perusteella määritetään relaatio, josta reititystietoa haetaan. Tällöin sovellusohjelmilla (RIS, NA)
tulee olla käytössään kuvaus siitä, mitä etuliitteitä (tauluja) tietokannassa on. Kun on saatu
riittävästi merkkejä, voidaan määrittää taulu, johon haut kohdistetaan. Tietokannan kuvaus
muodostetaan hakemalla listaus kaikista numerotietokannan relaatioista. Jokaisesta nimestä
skannataan kokonaisluku, joka ilmaisee siis etuliitteen. Kuvausta varten RIS:n muistissa on taulu,
jonka koko on yhtä suuri kuin suurin taulujen nimistä skannattu arvo. Jokaisen löydetyn etuliitteen
osoittamalle paikalle merkitään, että kyseinen relaatio löytyy tietokannasta. Muille paikoille
merkitään, että indeksin osoittamaa etuliitettä ei ole. Puhelua muodostettaessa toimitaan kuten
kappaleessa 6.3.1 esitettiin [Kuva 6.4]. Seuraavassa on esimerkkinä kuvaus yksinkertaisesta
tietokannasta, jossa on relaatiot etuliitteille 3, 4, 6, 7, 8, 9, 10, 12, 13, 15, 16.
0 0 0 1 1 0 1 1 1 0 1 11 1 0 1 10 0 0 1 1 0 1 1 1 0 1 11 1 0 1 1
Kuva 7.3. Numerotietokannan kuvaus
Edellä esitetyn esimerkin mukaisesti soitettaessa numeroon 3774561 haetaan reititystietoa
relaatiosta 3. Soitettaessa numeroon 167726 haetaan relaatiosta 16. Soitettaessa numeroon
2XXXXX se todetaan numeroksi, joka ei ole käytössä. Lopulliset relaatiot näyttävät seuraavilta:
Subscribers3(D_NUMBER, R_DATA_ID )
Subscribers4(D_NUMBER, R_DATA_ID )
58
.
.
Subscribers16(D_NUMBER, R_DATA_ID )
R_Data(R_DATA_ID, R_NUMBER)
Sellainen rajoitus etuliitteiden jaolle joudutaan asettamaan, että etuliitteen pituus täytyy olla
pienempi kuin lyhin mahdollinen luettelonumeron pituus. Eli jos luettelonumeron minimipituus on
neljä merkkiä, ei etuliitteen pituus voi olla kolmea merkkiä suurempi.
7.3.4 Hakuoperaatio pisimmän osuman mukaan (peräkkäislähetys)
SQL-kyselyt, jolla reititystietoa haetaan soitettaessa numeroon 3774561 pisimmän osuman
periaatteella [Kuva 7.5] näyttävät seuraavilta. Oletetaan, että yksikäsitteinen reititysnumero löytyy
viiden merkin jälkeen1:
SELECT R_DATA_ID FROM Subscribers3 WHERE D_NUMBER LIKE ‘7_%’ LIMIT 1
SELECT R_DATA_ID FROM Subscribers3 WHERE D_NUMBER LIKE ‘77_%’ LIMIT 1
SELECT R_DATA_ID FROM Subscribers3 WHERE D_NUMBER LIKE ‘774_%’ LIMIT 1
SELECT R_DATA_ID FROM Subscribers3 WHERE D_NUMBER LIKE ‘7745_%’ LIMIT 1
SQL tarjoaisi varmasti useampia mahdollisuuksia suorittaa kyseiset haut. LIMIT 1 tarkoittaa sitä,
että haetaan maksimissaan yksi rivi. Yllä olevien hakujen tarkoitus on ainoastaan ilmaista onko jo
saatu tarpeeksi merkkejä avainta varten. Mikäli kysely palauttaa yhden rivin, todetaan että tarvitaan
lisää merkkejä ja uusi haku, koska rivi merkitsee, että saatu etuliite ei ollut yksikäsitteinen. Mikäli
kysely palauttaa nolla riviä, etuliite todetaan yksikäsitteiseksi, eikä lisää merkkejä enää odoteta.
Nolla riviä tuloksessa merkitsee, että yksikäsitteinen viiteavain reititystietoon löytyy eksplisiittisellä
haulla. Jokaisen yllä esitetyn kyselyn kohdalla täytyy suorittaa myös eksplisiittisiä hakuja:
SELECT R_DATA_ID FROM Subscribers3 WHERE D_NUMBER = ‘7’
SELECT R_DATA_ID FROM Subscribers3 WHERE D_NUMBER = ‘77’
SELECT R_DATA_ID FROM Subscribers3 WHERE D_NUMBER = ‘774’
SELECT R_DATA_ID FROM Subscribers3 WHERE D_NUMBER = ‘7745’
1 Algoritmi ottaa huomioon, että yksikään kokonainen luettelonumero ei voi olla toisen etuliite, vaikka
luettelonumerot voivatkin olla eri mittaisia.
59
Haluttu reititystieto saadaan kaikissa tilanteissa eksplisiittisellä haulla pisimmän osuman
periaatteella tuloksesta, jonka antaa mahdollisimman pitkä numerojono. On huomattava, että
hakuehto ‘7745_%’ hyväksyy kaikki numerot, joiden etuliitteenä on 77451, 77452,…, 77459 mutta
ei numeroa 7745. Ainakin yksi etuliitteillä 7741, 7742…, 7749 alkavista avaimista löytyy, koska
hakuehto ’774_%’ palauttaa ainakin yhden rivin. Sen perusteella ei kuitenkaan vielä voida tietää,
onko pisin osuva etuliite löytynyt. Koska ehdolla ’7745_%’ ei löydy tietuetta, hakua ei tarvitse enää
tarkentaa.
Peräkkäislähetyksessä siis A-tilaajalta odotetaan lisää merkkejä niin kauan kunnes yksikäsitteinen
hakuavain on saatu muodostettua. Hakuja ei käytännössä tarvita näin paljon, koska hauista voidaan
pidättäytyä niin kauan kunnes on saatu lyhintä mahdollista numeron pituutta vastaava määrä
merkkejä. Tarkastellaan vielä kolmen erilaisen esimerkin valossa, miten reititystiedon haku etenee.
Tarkastellaan yksinkertaisuuden vuoksi vain yhtä relaatiota, joka on etuliitteille 945. Se koostuu
seuraavista tietueista:
Kuva 7.4. Esimerkkitietokanta
Käsitellään erikseen tapaukset, joissa soitetaan numeroihin 9417664, 9458002, 9458005, 9459996.
Kuvassa 7.5 esitetään proseduuri, joka suorittaa reititysnumeron haun, kun B-tilaajan numero
saadaan peräkkäislähetyksellä. Operaatio ’GET DIGIT’ on rajapinta RIS:stä ulos, eli sen kautta
otetaan vastaan A-tilaajan lähettämiä merkkejä ulkoisilta järjestelmiltä mitä ne sitten ovatkaan
(SCP, SDP, SIP-proxy, LS etc.).
60
LEN(P)+LEN(K)< MIN(NUMLEN)
GET DIGIT
APPEND TO KEY
NO
IDLE
SELECT TABLE
GET DIGIT
APPEND TO PREFIX
TABLE SELECTED
YES
NO
REQUEST
PREFIXFOUND
LEN(P) =MAX(PLEN)
QUERY
EXECUTE QUERIES
KEY FOUND RDATA_ID=RESULT
END REACHEDGET DIGIT
APPEND TO KEY
NO
YES
NO
RDATA_ID =NULL
YES
NOT FOUNDFOUND
NO YES
YES
NO
YES
LEN(P)+LEN(K)< MIN(NUMLEN)
GET DIGIT
APPEND TO KEY
NO
IDLE
SELECT TABLE
GET DIGIT
APPEND TO PREFIX
TABLE SELECTED
YES
NO
REQUEST
PREFIXFOUND
LEN(P) =MAX(PLEN)
QUERY
EXECUTE QUERIES
KEY FOUND RDATA_ID=RESULT
END REACHEDGET DIGIT
APPEND TO KEY
NO
YES
NO
RDATA_ID =NULL
YES
NOT FOUNDFOUND
NO YES
YES
NO
YES
Kuva 7.5. Reititystiedon haku (peräkkäislähetys)
RIS päivittää muuttujien PREFIX, KEY sekä RDATA_ID arvoja sen perusteella kuinka monta
merkkiä se on vastaanottanut. Taulukkoon 1 on merkitty myös tilasiirtymät. Määritellään etuliitteen
(taulun nimestä) maksimipituudeksi kolme merkkiä sekä luettelonumeron (luettelonumeron etuliite)
minimipituudeksi neljä merkkiä.
61
Merkki Lähtötila Siirtymätila Prefix Key Rdata_id9417664
NULL IDLE SELECT TABLE NULL NULL NULL9 SELECT TABLE SELECT TABLE "9" NULL NULL4 SELECT TABLE SELECT TABLE "94" NULL NULL1 SELECT TABLE NOT FOUND "941" NULL NULL9458002
NULL IDLE SELECT TABLE NULL NULL NULL9 SELECT TABLE SELECT TABLE "9" NULL NULL4 SELECT TABLE SELECT TABLE "94" NULL NULL5 SELECT TABLE TABLE SELECTED "945" NULL NULL8 TABLE SELECTED QUERY "945" "8" 99280 QUERY QUERY "945" "80" 99280 QUERY QUERY "945" "800" 99282 QUERY FOUND "945" "8002" 98839458005
NULL IDLE SELECT TABLE NULL NULL NULL9 SELECT TABLE SELECT TABLE "9" NULL NULL4 SELECT TABLE SELECT TABLE "94" NULL NULL5 SELECT TABLE TABLE SELECTED "945" NULL NULL8 TABLE SELECTED QUERY "945" "8" 99280 QUERY QUERY "945" "80" 99280 QUERY QUERY "945" "800" 99285 QUERY FOUND "945" "8005" 99289459996
NULL IDLE SELECT TABLE NULL NULL NULL9 SELECT TABLE SELECT TABLE "9" NULL NULL4 SELECT TABLE SELECT TABLE "94" NULL NULL5 SELECT TABLE TABLE SELECTED "945" NULL NULL9 TABLE SELECTED QUERY "945" "9" NULL9 QUERY QUERY "945" "99" NULL9 QUERY QUERY "945" "999" NULL6 QUERY NOT FOUND "945" "9996" NULL
Taulukko 1. Reititystiedonhaku (peräkkäislähetys)
7.3.5 Hakuoperaatio pisimmän osuman mukaan (kertalähetys)
Kun B-tilaajan numero saadaan yhdessä sanomassa [Kuva 7.6] ei A-tilaajalta tarvitse odottaa lisää
merkkejä, koska kaikki tarvittava informaatio on yhdessä viestissä. Tällöin on tutkittava sekä
numeron alkua että loppua. Alusta tarvitaan merkkejä, jotta haku voitaisiin kohdistaa oikeaan
tauluun. Pisimmän osuman haku tehdään tässä tapauksessa lähtien pisimmästä kohti lyhempiä
numeroita. Tarvitaan ainoastaan eksplisiittisiä hakuja, joten kysely palauttaa aina maksimissaan
yhden rivin:
SELECT R_DATA_ID FROM Subscribers3 WHERE D_NUMBER = ‘774561’
SELECT R_DATA_ID FROM Subscribers3 WHERE D_NUMBER = ‘77456’
SELECT R_DATA_ID FROM Subscribers3 WHERE D_NUMBER = ‘7745’
Tässä tapauksessa riittää kolme hakua.
62
IDLE
SELECT TABLE
SCAN DIGIT
APPEND TO PREFIX
QUERY
YES
NO
NO
REQUEST
EXECUTE QUERY
SHORTEN KEY
YES
NO
FOUND
RDATA_ID=RESULT
LEN(P)+LEN(K)< MIN(NUMLEN)
PREFIXFOUND
LEN(P) =MAX(PLEN)
NO
RESULT
NOT FOUND
YES
YES
IDLE
SELECT TABLE
SCAN DIGIT
APPEND TO PREFIX
QUERY
YES
NO
NO
REQUEST
EXECUTE QUERY
SHORTEN KEY
YES
NO
FOUND
RDATA_ID=RESULT
LEN(P)+LEN(K)< MIN(NUMLEN)
PREFIXFOUND
LEN(P) =MAX(PLEN)
NO
RESULT
NOT FOUND
YES
YES
Kuva 7.6. Reititystiedon haku (kertalähetys)
Tilasiirtymiä ja numeron käsittelyä voidaan tässäkin tapauksessa tarkastella taulukon [Taulukko 2]
avulla:
63
Merkki Lähtötila Siirtymätila Prefix Key Rdata_id9417664
NULL IDLE SELECT TABLE NULL "9417664" NULL9417664 SELECT TABLE SELECT TABLE "9" "417664" NULL
SELECT TABLE SELECT TABLE "94" "17664" NULLSELECT TABLE NOT FOUND "941" "7664" NULL
9458002
NULL IDLE SELECT TABLE NULL "9458002" NULL9458002 SELECT TABLE SELECT TABLE "9" "458002" NULL
SELECT TABLE SELECT TABLE "94" "58002" NULLSELECT TABLE QUERY "945" "8002" NULLQUERY FOUND "945" "8002" 9883
9458005
NULL IDLE SELECT TABLE NULL "9458005" NULL9458005 SELECT TABLE SELECT TABLE "9" "458005" NULL
SELECT TABLE SELECT TABLE "94" "58005" NULLSELECT TABLE QUERY "945" "8005" NULLQUERY QUERY "945" "800" NULLQUERY QUERY "945" "80" NULLQUERY FOUND "945" "8" 9928
9459996
NULL IDLE SELECT TABLE NULL "9459996 NULL9459996 SELECT TABLE SELECT TABLE "9" "459996" NULL
SELECT TABLE SELECT TABLE "94" "59996" NULLSELECT TABLE QUERY "945" "9996 NULLQUERY QUERY "945" "999" NULLQUERY QUERY "945" "99" NULLQUERY QUERY "945" "9" NULLQUERY NOT FOUND "945" NULL NULL
Taulukko 2. Reititystiedon haku (kertalähetys)
64
7.4 Päivitystietokannat
AVCC Advertisement Validity Checking Client
PNDB Ported Number Database
UDB Update Database
PNAC Ported Number Advertising Client
RIS Routing Information Server
NA Numbering Agent
NDB Numbering Database
Regulator
NDB
Service Provider X
AVCC
UDB
PNDB
PNAC
NA
RIS
AVCC Siirtymistiedon tarkistin
PNDB Siirtymistietokanta
UDB Päivitystietokanta
PNAC Siirtymistiedon levittäjä
RIS Reititystietopalvelin
NA Numerointiagentti
NDB Numerotietokanta
AVCC Advertisement Validity Checking Client
PNDB Ported Number Database
UDB Update Database
PNAC Ported Number Advertising Client
RIS Routing Information Server
NA Numbering Agent
NDB Numbering Database
AVCC Advertisement Validity Checking Client
PNDB Ported Number Database
UDB Update Database
PNAC Ported Number Advertising Client
RIS Routing Information Server
NA Numbering Agent
NDB Numbering Database
Regulator
NDB
Service Provider X
AVCC
UDB
PNDB
PNAC
NA
RIS
AVCC Siirtymistiedon tarkistin
PNDB Siirtymistietokanta
UDB Päivitystietokanta
PNAC Siirtymistiedon levittäjä
RIS Reititystietopalvelin
NA Numerointiagentti
NDB Numerotietokanta
Regulator
NDB
Service Provider X
AVCC
UDB
PNDB
PNAC
NA
RIS
AVCC Siirtymistiedon tarkistin
PNDB Siirtymistietokanta
UDB Päivitystietokanta
PNAC Siirtymistiedon levittäjä
RIS Reititystietopalvelin
NA Numerointiagentti
NDB Numerotietokanta
AVCC Siirtymistiedon tarkistin
PNDB Siirtymistietokanta
UDB Päivitystietokanta
PNAC Siirtymistiedon levittäjä
RIS Reititystietopalvelin
NA Numerointiagentti
NDB Numerotietokanta
Kuva 7.7. Päivitystietokantaan liittyvät elementit
7.4.1 Sanallinen kuvaus
Kuvassa 7.7 on vahvennettu päivityspalvelimen transaktioihin liittyvät elementit.
Päivitystietokantoihin lähetetään tieto tilaajan siirtymisestä. Välttämättömiä attribuutteja ovat
tietysti tilaajanumero sekä reititysnumero. Ilmoitetaan siis tilaaja, joka on siirtynyt ja hänen uusi
reititysnumero. Päivitystietokanta on luonteeltaan paljon dynaamisempi kuin numerotietokanta.
Sinne ei kohdistu lainkaan SQL-päivityksiä (SQL UPDATE) – ainoastaan lisäyksiä ja poistoja.
Päivitystietokannat toimivat myös luotettavuuden takeena, koska niiden avulla voidaan
korruptoitunut numerotietokanta palauttaa toimivaksi, koska päivityshistoria on saatavilla
päivitystietokannasta. Tämä tietysti edellyttää, että numerotietokannasta on riittävän uusi
varmuuskopio saatavilla. Jokaiselle päivitykselle on annettava aikaleima, koska sama tilaaja saattaa
siirtyä useamman kerran aikavälillä, jossa edellinen päivitys on vielä kannassa. Päivitystietokantaa
tyhjennetään jatkuvasti, koska jo luettuja päivityksiä ei periaatteessa tarvita. Varmennussyistä
kannattaa esimerkiksi viimeisen viikon tai kuukauden päivitykset pitää kannassa. Vanhemmatkin
päivitykset ylläpidon kannattaa silti säilyttää jollakin tavalla esimerkiksi pakattuna
tekstitiedostoihin, koska joskus jotain tapahtumaa voidaan joutua selvittämään pitkänkin ajan takaa.
Jos päivitysten hauissa ja numerotietokannoissa ei ole häiriöitä, ei vanhoilla päivitystietueilla ole
mitään tehtävää sen jälkeen, kun kaikki numerointiagentit ovat lukeneet tietueet.
7.4.2 Relaatiomalli
Ainakin teoriassa päivitystietokannassa (UDB) tarvitaan ainoastaan yksi relaatio:
moved_numbers(D_NUMBER, R_NUMBER, U_TIME , S_TIME)
65
Käytännössä päivitystietokantaa voidaan hajauttaa samalla periaatteella kuin numerotietokanta,
mutta yksinkertaisuuden säilyttämiseksi käsitellään tietokantaa tässä yhtenä relaationa. Kolme
attribuuttia on alleviivattu jatkuvalla viivalla, joten ne kaikki yhdessä muodostavat avaimen:
Tilaajanumero, reititysnumero tai nämä yhdessä eivät toimi avaimena, koska sama tilaaja voi siirtyä
useita kertoja – myös takaisin alkuperäiseen verkkoon (engl. donor network). Jokainen
tilaajanumeron, reititysnumeron ja päivitysaikaleiman yhdistelmä on ainutkertainen, joten ne
yhdessä toimivat avaimena. S_TIME-attribuutti on normaalisti sama kuin U_TIME. U_TIME
kuvaa aikaa, jolloin tilaajan siirtyminen suoritetaan ja S_TIME kuvaa aikaa, jolloin päivitys
saadaan onnistuneesti tehtyä. U_TIME:n generoi asiakas (PNAC) ja S_TIME:n palvelin (PNDB).
Mikäli joudutaan turvautumaan uudelleenyrityksiin kyseiset attribuutit eroavat toisistaan. Jako tulee
tehdä esimerkiksi tällä tavalla, koska ainakin teoriassa on mahdollista, että tilaaja siirtyy uudelleen
sinä aikana, kun edellistä päivitystä ei ole saatu perille joka palvelimeen. Numerotietokannan
uusimmat päivitykset haetaan aina S_TIME:n perusteella. Useimmiten reititysnumero vaihtuu vain
esimerkiksi tilaajan muuton yhteydessä, tai tilaajan vaihtaessa palveluntarjoajaa tai operaattoria.
Luultavasti lopullisessa toteutuksessa relaatioon otetaan joitakin lisäattribuutteja – esimerkiksi
tietoa transaktioon liittyvistä osapuolista, mutta teknisessä mielessä riittävät esitetyt neljä
attribuuttia. Attribuuttien nimet kannattaa jättää avoimeksi eli niitä ei kannata kovakoodata
sovellusohjelmaan. Ohjelman käyttäjä voi tällöin itse konfiguroida sen tietokannan kanssa
yhteensopivaksi.
PNDB:ssä tarvitaan joitakin lisäattribuutteja osoittamaan uudelleen lähetystä ja siirtymisen
vahvistusta. Jokaiselle operaattorille luodaan seuraava relaatio:
moved_numbers(D_NUMBER, R_NUMBER, U_TIME , CONFIRM,RETRY)
Avainrajoite on sama kuin edellä esitetyssä. Joissakin ongelmatilanteissa on välttämätöntä tietää,
onko kyseessä uudelleen lähetyksellä tietokantaan saapunut tietue [Kappale 8.2.2]. S_TIME-
attribuuttia ei tarvita.
7.4.3 Toteutus
Päivitystietokantojen toteutus on myös paljon yksinkertaisempi kuin numerotietokantojen.
Aikaleima voidaan generoida päivitystä suorittavien asiakaskoneiden prosessorien kellosta
sekunteina Unixin epookista (1. Tammikuuta 1970 klo 00:00:00) lähtien neljän tavun
etumerkittömänä kokonaislukuna. Näin ollen kaikkien alueen sekä numeropalvelimien että
päivityspalvelimien kellojen tulee olla kohtuullisella tarkkuudella synkronoituja. Muutamien
sekuntien eroavaisuus ei ole vakavaa. Tietyn asteista tarkkuutta tarvitaan kuitenkin tilanteissa,
joissa jostain syystä tehdään lyhyen ajan sisällä useampi samaa tilaajaa koskeva päivitys. Toinen
mahdollisuus on erillisen kellopalvelimen käyttö, josta kaikki asiakaskoneet hakisivat aikaleiman
päivitystilanteissa. Kellojen synkronointia ei tällöin tarvittaisi, koska kellopalvelin tarjoaa kaikille
asiakkaille saman prosessorin kellosta aikaleiman paketin siirtoviiveen tarkkuudella. Tämä hieman
66
vaikeuttaisi päivitysoperaatioita. Päivitykset tapahtuvat inkrementaalisesti lähettämällä tavallisesti
seuraava kysely kaikkiin alueen palvelimiin:
INSERT INTO COMX (D_NUMBER, R_NUMBER, U_TIME, RETRY) VALUES ($dnum, $rnum,
$cur_time, 0)
EMPTY LIST
UPDATE
UPDATE NEXT
LIST DATA SOURCES
OK
SAVE UPDATE
IDLE
UPDATE
YES
NO
YES
NO
NO
OK
ERROR
YES
EMPTY LIST
UPDATE
UPDATE NEXT
LIST DATA SOURCES
OK
SAVE UPDATE
IDLE
UPDATE
YES
NO
YES
NO
NO
OK
ERROR
YES
Kuva 7.8. Reititysnumeron levitys (PNAC)
Toisinaan päivitykset saattavat myös epäonnistua esimerkiksi verkossa olevan vian tai palvelimen
vikaantumisen vuoksi. Epäonnistuneet päivitykset on talletettava esimerkiksi erilliseen SQL-
tietokannan tauluun tai jonnekin muualle, mistä ne voidaan hakea uudelleenyrityksiä varten. Kuva
7.9 selventää tilannetta. Tällöin S_TIME asetetaan tietueen saavuttua palvelimeen
uudelleenyrityksen ajankohdaksi ja U_TIME ajaksi, jolloin päivitystä ensimmäisen kerran
yritettiin. PNAC soveltaa eksponentiaalisesti kasvavaa väliaikaa päivitysyritysten välillä tiettyyn
rajaan asti, jonka jälkeen väliaikaa ei enää kasvateta. PNAC lähettää päivityksen siis joka
tapauksessa riippumatta siitä, onko se vanhentunut vai ei.
INSERT INTO COMX (D_NUMBER, R_NUMBER, U_TIME, RETRY) VALUES ($dnum, $rnum,
$u_time, 1)
67
EMPTY LIST
IDLE
FIND UPDATES FORNEXT DATA SOURCE
LIST DATA SOURCES
EMPTY
GET NEXT
YES
NO
YES
NO
TIMER
UPDATE
YES
NO
YES
OK
REMOVE FROMLIST
OK ERRORNO
EMPTY LIST
IDLE
FIND UPDATES FORNEXT DATA SOURCE
LIST DATA SOURCES
EMPTY
GET NEXT
YES
NO
YES
NO
TIMER
UPDATE
YES
NO
YES
OK
REMOVE FROMLIST
OK ERRORNO
Kuva 7.9. Reititysnumeron levityksen uudelleenyritys (PNAC)
7.4.4 Numeropalvelimien päivitys
Operaattoreiden numeron siirrettävyyttä palvelevat agentit (NA) suorittavat siis määrävälein
päivityspalvelimiin (UDB) kohdistuvia SQL-tietokantahakuja, jotka valitsevat kaikki uusimmat
päivitykset tietokannasta:
SELECT D_NUMBER, R_NUMBER, MAX(U_TIME), S_TIME FROM moved_numbers WHERE
S_TIME > $timestamp GROUP BY D_NUMBER ORDER BY ASC S_TIME
68
TIMESTAMP =CURRENT
EMPTY LIST
GET TIME
UPDATE NEXT
GET TIMESTAMP
OK
TIMESTAMP =LAST.S_TIME
IDLE
TIMER
YES
NO
YES
NO
GET UPDATESS_TIME >TIMESTAMP
SAVE TIMESTAMP
EMPTY LIST
UPDATE
YES
NO
TIMESTAMP =CURRENT
EMPTY LIST
GET TIME
UPDATE NEXT
GET TIMESTAMP
OK
TIMESTAMP =LAST.S_TIME
IDLE
TIMER
YES
NO
YES
NO
GET UPDATESS_TIME >TIMESTAMP
SAVE TIMESTAMP
EMPTY LIST
UPDATE
YES
NO
Kuva 7.10. Numerotietokannan päivitys (NA)
Edellä oleva SQL-kysely hakee tilaajanumerokohtaisesti (tai tilaajanumeron etuliite) suurimman
aikaleiman mukaisen päivityksen tutkien ainoastaan kaikki viimeisen haun jälkeiset päivitykset.
Käytännössä muuttuja ’timestamp’ on viimeisen haun aikaleima vähennettynä kellon
epätarkkuudella mikäli NA käyttää eri UDB:tä kuin edellisessä haussa eli siitä vähennetään ehkä
muutamia sekunteja. Menettely aiheuttaa sen, että yksittäiset numerotietokannan päivitykset
suoritetaan kahteen kertaan, mutta se ei haittaa, koska taulujen tietosisältöhän ei tästä muutu
numerotietokannassa. Korjausta ei tarvita mikäli käytetään samaa UDB:ta kuin edellisessä haussa,
koska S_TIME on aina generoitu palvelimen prosessorin kellosta.
Numerotietokannan päivitys [Kuva 7.10 – UPDATE NEXT] ei useinkaan onnistu normaalilla SQL-
päivitysoperaatiolla (UPDATE). Voihan olla, että mainostetulle siirtyneelle tilaajalle ei ole tietuetta
tietokannasta. Näin ollen ensiksi on tarkistettava löytyykö tietuetta.
69
Taulun valinta on suoritettava kappaleessa 7.3.3 esitetyllä tavalla. Tällöin loppuosaa numerosta
käytetään avaimena. Jos tietue löytyy, muutetaan vanha reititysnumero uudeksi. Mikäli ei löydy,
pelkkä lisääminen ei riitä, koska tietokannassa saattaa olla aggregoituja tietueita. Esimerkkinä
tilaajanumeron etuliitteen ”1451” lisääminen:
INSERT INTO Subscribers1 (D_NUMBER, R_NUMBER) VALUES (‘451’, ‘$new’)
Reititysnumeron mainostaminen esimerkiksi etuliitteellä ’1451’ merkitsee sitä, että etuliitteet
’1451%’ saavat kaikki saman reititysnumeron. Näin ollen tietueen lisäämisen jälkeen tulee poistaa
kaikki muut tietueet, joihin kyseinen etuliite sisältyy:
DELETE FROM Subscribers1 WHERE D_NUMBER LIKE ‘451_%’
Kuva 7.10 on siis karkeasti yksinkertaistus, mutta sen tarkoitus ei olekaan esittää, kuinka SQL-
kyselyt muodostetaan. ’UPDATE NEXT’-operaatio kattaa siis sekä taulun valinnan että päivityksen
ja tarvittaessa myös vanhentuneiden numerotietojen poiston.
7.4.5 Päivitysten validointi
Edellä esitetyissä päivitysoperaatioissa on tehty se olettamus, että kaikki osapuolet ovat ns.
uskottuja osapuolia eli oletetaan, että ne eivät ole toisilleen vihamielisiä vaan toimivat yhtenäisten
tavoitteiden puolesta. Näin yksinkertainenhan tilanne ei kuitenkaan ole, koska tilaajan siirtyessä
aiemmin häntä palvellut operaattori menettää maksavan asiakkaan ja uusi operaattori saa
vastaavasti uuden asiakkaan. Muistetaan, että usein siirtymisen syy saattaa olla myös se, että
asiakas ei ole tyytyväinen saamaansa palveluun. Huonoa palvelua voi olla esimerkiksi se, että liian
usein hänen puhelunsa eivät onnistu. Puhelut eivät onnistu ainakaan silloin, kun B-tilaajan
reititysosoitetta ei saada oikein. Mikäli jokaisella olisi oikeus kirjoittaa päivitystietokantaan
suoraan, saattaisi jokin vihamielinen päivitysyritys johtaa lopulta numerotietokantojen
korruptoitumiseen pahasti. Jonkin lyhyen etuliitteen (esimerkiksi 94519) lähettäminen jollakin
väärällä reititysnumerolla (esimerkiksi 8883) ilmaisee, että kaikkien 94519-alkuisten
puhelinnumeroiden reititystieto on 8883. Tällöinhän sellaisille tilaajille, joiden reititysnumero ei ole
8883 kyseisen etuliitteen 94519 sisällä, puhelut eivät koskaan mene oikeaan osoitteeseen. Toisaalta
tällainen aggregointi tulee myös sallia, koska niillä pystytään tietyissä tapauksissa piilottamaan
tilaajien tarkka lukumäärä ja ennen kaikkea pienentämään tietokantojen kokoa. Täytyy siis olla
keino, jolla tällaisten vihamielisten päivitysten aiheuttama numerotietokantojen korruptoituminen
voidaan estää. Jokin vihamielinen päivitys tai vaikka toimintavirhe voisi siis tuoda UDB:hen juuri
edellä esitetyn kaltaisia vääriä päivitystietueita, ellei minkäänlaista validointimekanismia käytetä.
On oltava järjestelmä, jossa tilaajan uusi operaattori ja aiemmin häntä palvellut operaattori sopivat
tilaajan siirtymisestä. Täysin itsenäisesti mikään operaattori ei voi mainostaa, että tietty tilaaja tai
tilaajaryhmä on siirtynyt sen asiakkaaksi. Siirtyminen edellyttää jonkinlaista vahvistusta aiemmin
siirtynyttä tilaajaa palvelleelta operaattorilta. Uusi reititystieto ei siis tule voimaan ennen
vahvistusta. Kehittyneimmät SQL-tiedonhallintajärjestelmät tukevat monen tyyppistä autentikointia
70
ja salausmekanismeja. Esimerkiksi MySQL tarjoaa hyvin moninaiset mahdollisuudet rajata pääsyä
tietokantoihin1.
Com1
UPDATEDATABASE
Service ProviderCom1
Service ProviderCom2
NUMBERINGDATABASE
Regulator
12
3
4
5
6
d_number ”7747”r_number ”Com1”
d_number ”7747”r_number ”Com2”
INSERT INTO Com1 (d_number,r_number) VALUES (”7747, ”Com2)
UPDATE Com1 SET confirm=1WHERE d_number=”7747”
Com1
UPDATEDATABASE
Service ProviderCom1
Service ProviderCom2
NUMBERINGDATABASE
Regulator
12
3
4
5
6
d_number ”7747”r_number ”Com1”
d_number ”7747”r_number ”Com2”
INSERT INTO Com1 (d_number,r_number) VALUES (”7747, ”Com2)
UPDATE Com1 SET confirm=1WHERE d_number=”7747”
Kuva 7.11. Siirtymiseen liittyvät transaktiot
Siirrettävyystietokannassa (PNDB) on jokaiselle siirrettävyysalueella toimivalle palveluntarjoajalle
oma relaationsa (tässä tapauksessa Com1) kyseisen palveluntarjoajan alueelta pois siirtyneitä
tilaajia varten [Kuva 7.11]. Kuva on siirrettävien attribuuttien osalta yksinkertaistettu. Tilaaja 7747
siirtyy operaattorilta Com1 operaattorin Com2 asiakkaaksi säilyttäen siis vanhan tilaajanumeronsa.
Jokaisella palveluntarjoajalla on mahdollisuus lisätä siirtymisiä kaikkien muiden tauluihin
regulaattorin tietokannassa. Tässä tapauksessa Com2 siis mainostaa, että tilaaja on siirtynyt pois
operaattorilta Com1 lisäämällä tietueen (”7747”, ”Com2”) tauluun Com1. Ainoastaan Com1:llä on
oikeus vahvistaa siirtyminen, koska taulu sisältää vain Com1:ltä siirtyneitä tilaajia. Kullakin
operaattorilla on vahvistusoikeus ainoastaan sille kuuluvaan tauluun. SQL:n pääsynhallinnan
funktioilla voidaan tämä toiminnallisuus toteuttaa. Jätetään yksinkertaisuuden vuoksi kappaleessa
7.4.1 esitetyt aikaleimat huomioimatta. Operaattorilla Com2 on tauluun Com1 ainoastaan
lisäysoikeus koskien attribuutteja d_number ja r_number. Attribuutin confirm arvona on
oletusarvoisesti 0, joten se asettuu väkisinkin arvoksi 0, koska ainoastaan operaattorilla Com1 on
oikeus kirjoittaa kyseiseen kenttään. Operaattorilla Com2 ei siis ole mitään mahdollisuutta asettaa
kyseistä kenttää arvoon 1. Vaiheen 1 jälkeen taulu Com1 näyttää seuraavalta:
1 http://mysql.eunet.fi/doc/en/GRANT.html
71
Vaiheen 2 jälkeen se muuttuu seuraavaksi:
Periaatteessa riittäisi sekin, että ainoastaan tilaajaa aiemmin palvellut operaattori lähettäisi tiedon
siirtymisestä, mutta Com2 ei välttämättä halua luovuttaa kaikkea transaktiossa tarvittavaa tietoa
suoraan Com1:lle. Nyt lähetetty vahvistus on ainoastaan vahvistus, että tilaaja 7747 ei ole enää
Com1:llä.
Vasta vaiheen 2 jälkeen AVCC voi siirtää tiedon siirtymisestä päivitystietokantaan (vaiheet 3 ja 4),
sekä edelleen tietyllä viiveellä NA voi siirtää tiedon numerotietokantoihin (vaiheet 5 ja 6). Millä
sitten varmistetaan, että ainoastaan Com1 pääsee vahvistamaan Com1:stä tapahtuvia siirtymisiä?
Toteutus poikkeaa eri tiedonhallintajärjestelmien välillä, mutta sovellusohjelmoijanhan ei tarvitse
tästä välittää, koska hänen tarvitsee vain antaa käyttäjätunnus ja salasana DSN-parametrin lisäksi.
Esimerkiksi MySQL:llä voidaan edellä esitetyssä esimerkissä [Kuva 7.11] tarvittaville transaktioille
antaa oikeudet seuraavasti: Com2:lle annetaan lisäysoikeus tauluun Com2 kenttiin r_number ja
d_number:
GRANT INSERT (r_number, d_number) ON Com1 TO [email protected] by ’password’
Com1 tarvitsee päivitysoikeudet kyseiseen relaation:
GRANT INSERT, UPDATE (confirm) ON Com1 TO [email protected] by ’password’
Kyseisten komentojen jälkeen siis Com2 pystyy ainoastaan lisäämään puuttumatta kenttään
confirm. Com1 pystyy lisäämään ja päivittämään kenttää confirm, mutta ei esimerkiksi poistamaan
tietueita kyseisestä taulusta. Tietoturvan takaamiseksi voidaan käyttää esimerkiksi MD5:ttä [36] ja
SSL:ää [37]. Validointimenettely on optionaalinen, sillä palvelu tulee olla toteutettavissa myös
siten, että joltakin reititysalueelta mainostetaan siirtyneen tilaajan uutta reititysosoitetta suoraan
päivitystietokantaan eli ei operaattorikohtaisia tauluja varten luodun siirrettävyystietokannan kautta.
Tällainen tulee kysymykseen, jos esimerkiksi numeron siirrettävyys toteutetaan vain yhden
operaattorin sisällä. AVCC:n toinen tärkeä tehtävä on estää myöhässä tulleiden päivitysten pääsy
päivitystietokantaan. Funktio toimii siten, että etsitään UDB:stä PNDB:n tietuetta vastaavaa riviä.
Jos sellainen löytyy, verrataan niitä U_TIME:n perusteella, ja jätetään uudempi voimaan. Päivitystä
ei hyväksytä silloinkaan, jos se on vanhempi kuin se aika, jonka jälkeen tietue automaattisesti
poistuu UDB:sta. Validointimenettelyssä myös AVCC:n täytyy tarkistaa, että päivitystä vastaavan
tilaajan vanha palveluntarjoaja on juuri se, jonka taulusta päivitys luettiin.
7.4.6 Numerotietokannan ja päivitystietokannan synkronointi
Numerotietokantojen luotettavuus perustuu UDB:n aikaleimojen käyttöön ja säännöllisesti
otettaviin varmuuskopioihin. UDB:ssa on siis tallennettu tuorein päivityshistoria. Mikäli NDB
korruptoituu, otetaan varmuuskopio käyttöön ja ladataan UDB:sta päivitykset sen hetken jälkeen,
kun varmuuskopiointi kyseisen version osalta aloitettiin. Toimitaan siis aikaleimojen perusteella.
72
Synkronointi on tehokasta, koska vain pieni osa tietokannasta joudutaan käsittelemään. Jos
oletetaan, että varmuuskopio otetaan kerran vuorokaudessa, päivityksiä tulee synkronoinnissa
käsiteltäväksi keskimäärin noin 13700, mikäli 50 miljoonasta tilaajasta siirtyy 10% vuodessa.
Linux Debianissa MySQL:llä suoritetuissa testeissä NDB synkronoitui 15-20 sekunnissa kyseisellä
tietuemäärällä. Tosin täytyy ottaa huomioon, että siirrettävä tietomäärä on jo sen verran suuri, että
esimerkiksi verkkoyhteyden laatu vaikuttaa synkronoitumisaikaan. Testit suoritettiin lähiverkossa.
Melko pienikin ruuhkaisuus verkossa aiheuttaa tunnetusti sen, että TCP:n läpäisy vähenee
merkittävästi [38].
73
8 Ratkaisun arviointi
8.1 Ratkaisun toimivuus
8.1.1 Relaatiotietokantojen suorituskyky
Eri järjestelmiä testattaessa on suoritettu yksinkertaisesta SQL-taulusta1 hakuja, päivityksiä,
lisäyksiä sekä poistoja. Kyselyjä on kokeiltu eri kokoisista tauluista. Taulun koolla [Kuva 3.2
sivulla 19] ei kuitenkaan ole juuri minkäänlaista merkitystä. Kaikki haut on suoritettu paikallisella
asiakkaalla paikalliselta palvelimelta. Tulokset esitetään taulukossa 3. Testauksessa on käytetty
hyväksi PHP-ohjelmointikieltä [26]. Se tarjoaa rajapinnan kaikkiin testattuihin tietokantoihin
[Taulukko 3]. Toinen vaihtoehto olisi käyttää ODBC-rajapintaa minkä tahansa ohjelmointikielen
avulla. Debian Linux-käyttöjärjestelmässä MySQL on testattu myös ODBC:llä C-kielellä
ohjelmoiduilla testiohjelmilla, ja tulokset eivät juurikaan poikkea esitetyistä. PHP-kieltä
käytettäessä on kompensoitava ajanmittauksen vaikutus tuloksiin, koska PHP:lla ajanmittaukseen
kuluva aika on lähellä samaa suuruusluokkaa lyhimpien hakuaikojen kanssa..
Käyttöjär-jestelmä
CPU DBMS ka. hakuaika(ms) SELECT
ka. hakuaika(ms) UPDATE
ka. hakuaika(ms) INSERT
ka. hakuaika(ms) DELETE
Sun Blade100
UltraSPARC-IIe500 MHz
MySQL4.0.2
1.3 1.2 1.1 1.2
DebianLinux
AMD Athlon 800MHz
MySQL4.0.2
0.4 0.3 0.3 0.3
Windows2000Professional
AMD Athlon 800MHz
MySQL4.0.2
0.7 0.6 0.5 0.4
Sun Blade100
UltraSPARC-IIe500 MHz
PostgreSQL7.1.2
30 17 4 4
Sun Blade100
UltraSPARC-IIe500 MHz
mSQL 3.1 100 0.6
Windows2000Professional
AMD Athlon 800MHz
MicrosoftSQL Server7.0
0.4 0.4 0.7 1.0
Taulukko 3. Eri tiedonhallintajärjestelmien transaktionopeus
Microsoft SQL palvelimelle saadussa arvossa (0.4 ms) on käytetty proseduurihakua. Merkille
pantavaa on erittäin suuri ero Sun Blade 100:lle ja Debian Linux:lle saaduissa tuloksissa. Reilusti
alle 1 ms:n hakuajat ovat varmasti riittävän pieniä. Lyhyt vasteaika hakuihin on varmin tae
järjestelmän skaalautuvuudesta. Hakuaika 0.4 ms merkitsee, että sama asiakas pystyy suorittamaan
samalla palvelimella yhdeksän miljoonaa hakua tunnissa paikallisesti. Tällainen testi on
käytännössä hyvin helppo toteuttaa:
1 test1(col1 varchar(33) primary key, col2 varchar(33))
74
i=0;start_time=clock;
while(i<1000000){query=create_query(i);execute(query);i++;
}
end_time=clock;total_time=end_time – start_time;
Yllä olevan pseudokoodin mukaisesti suoritetaan miljoona kyselyä ja mitataan operaatioon kuluva
aika. MySQL:llä osoittautui, että tällöin asiakkaan käytössä on 40 ja palvelimen 60 prosenttia
CPU:n kapasiteetista. MySQL:ssä hakuoperaatio on kuitenkin säikeistetty (engl. multithreaded),
mikä merkitsee sitä, että palvelin pystyy suorittamaan useita hakuja samanaikaisesti. Järjestelmän
transaktiokyvyn testaamiseksi tarvitaankin testiympäristö, jossa useampi asiakas käyttää
samanaikaisesti samaa yksittäistä palvelinta. Lopulliseen NP-testiympäristöön valitsin edellä
esitetyn [Taulukko 3] mukaisesti tehokkaimman eli MySQL:n. Toisaalta MySQL on vapaasti
jaettava ohjelmisto, joten sen käyttö on yksinkertaisempaa ja teknisesti mielenkiintoisempaa, koska
lähdekoodia voi editoida. On huomattava, että testauksessa käytettiin erittäin realistista laitteistoa.
800 MHz:n CPU on nopea, mutta nykyisin jopa erityisesti palvelinkäyttöön kehitettyjen
laitteistojen prosessorit ovat nopeampiakin. Kaiken lisäksi käytettiin ainoastaan yhden prosessorin
laitteistoja. Säikeistetyt proseduurit voivat käyttää useaa prosessoria, mikä ei nopeuta välttämättä
yksittäisiä hakuja, mutta voi moninkertaistaa transaktionhallintakyvyn.
8.1.2 ODBC-ohjelmistot
Tietokantahakuja suorittavat asiakasohjelmistot suorittavat niin paljon laskentaa varsinaisten
tietokantahakujen lisäksi, että ne on syytä ohjelmoida tehokkuutta silmällä pitäen C:llä. Vapaasti
levitettävän lähdekoodin ohjelmistoista löytyi kaksi vaihtoehtoista ODBC:n ajurin hallitsijaa
[Kappale 4.3]. Testiympäristöön valitsin Openlink iODBC:n1 ajurin hallitsijaksi. Toinen saatavilla
oleva olisi ollut Easysoft unixODBC2, mutta se osoittautui melko huonosto toimivaksi
ongelmatilanteissa Linux-järjestelmässä. ODBC-rajapinta osoittautui hyvin toimivaksi MySQL- ja
PostgreSQL-järjestelmissä. MySQL:ään on saatavilla MyODBC-ajuri, ja PostgreSQL-lähdekoodin
sisältyy järjestelmään sopiva ODBC-ajuri. Sama sovellusohjelma todellakin toimii kummassakin
järjestelmässä.
8.1.3 Päivitysliikenteen volyymi
Pyrittäessä tehokkaaseen ratkaisuun päivitysliikenteen volyymin tulee olla pieni verrattuna
varsinaiseen hyötyliikenteeseen. Tilaajan siirtyessä päivitysliikenne riippuu lineaarisesti
1 http://www.iodbc.org/
2 http://www.odbc.org/
75
päivityspalvelinten lukumäärästä: Tieto siirtymisestä lähetetään kaikkiin päivityspalvelimiin ja
vastaavasti vahvistus [Kappale 7.4.5] tulee tehdä jokaiseen palvelimeen ennen kuin siirtyminen
astuu voimaan. Toisaalta päivitysliikenne riippuu lineaarisesti siirrettävyysalueen tilaajien
lukumäärästä: Mitä suurempi määrä tilaajia sitä suurempi määrä siirtymisiä, jos oletetaan, että jokin
tietty osuus tilaajista siirtyy jollakin aikavälillä. Päivitysliikenteen vaatima siirtokapasiteetti riippuu
tietysti myös päivityssanomien koosta.
Tarkan päivityksessä siirrettävän tavumäärän laskeminen on erittäin hankala tehtävä, joka
edellyttäisi MySQL:n lähdekoodin melko perinpohjaista tutkimista. Jonkinlainen karkea arvio siitä
voidaan kuitenkin tehdä. Tulee myös huomioida, että TCP/IP-otsikointi vie 40 tavua [38], ja että
TCP:n SYN-mekanismi vaatii yhteensä 2 kehystä ilman hyötykuormaa. Sen sijaan FIN voidaan
sisällyttää viimeiseen kehykseen, jolla hyötykuormaa lähetetään. Varsinainen SQL-kysely vie noin
100 tavua. Palvelin kuitenkin lähettää myös asiakkaalle, koska sovellustason kuittaukset
edellyttävät jonkinlaista informaatiota esimerkiksi siitä onko asiakkaalla oikeus suorittaa lähetetty
kysely, tai onko se edes kieliopiltaan oikein. Ennen lähetystä on myös muodostettava sovellustason
yhteys palvelimeen, mikä on myös kuitattava. Voidaan arvioida, että yhteensä hyötykuorman
kuljetukseen otsikkoineen lähetetään 1000 tavua ja SYN-toiminnolle 100 tavua. Näin yhteensä siis
karkeasti arvioiden saadaan 1100 tavua kahteen kertaan, koska vahvistettaessa siirtyminen
suoritetaan samanlainen operaatio. Oletetaan vielä, että tilaajia on 50 miljoonaa, joista 10% siirtyy
vuosittain. Jos päivityspalvelimia on kymmenen, saadaan keskimääräiseksi siirtonopeudeksi 28
kbps, joka jakaantuu ympäri verkkoa, eli ei siis tietylle linkille. Vuosittain jouduttaisiin lähettämään
yhteensä 11GB. Joskus tietueita voidaan kuitenkin yhdistää yhdeksi SQL-kyselyksi eli lähettää
samalla kertaa tieto useamman tilaajan siirtymisestä. Tämä jonkin verran vielä vähentää
päivitysliikennettä. Kaiken kaikkiaan kyseessä on verkon kannalta melko mitätön hallintaliikenne.
Ylläpito ei vaadi siis verkolta paljon kapasiteettia eikä edes suurta luotettavuutta, koska
uudelleenlähetys toteutetaan arkkitehtuurissa sekä TCP-tasolla että sovellustasolla tarvittaessa.
8.2 Järjestelmän käyttöönotto
8.2.1 Tietokantojen alustaminen
Mitä siirrettävyysalueella tarvitsee tehdä, jotta palvelu saadaan toimimaan? Ensiksi täytyy valita
tietokantajärjestelmä, jota käytetään numerotiedon tallennuksessa ja levityksessä. Edellä olen
esittänyt, että vapaasti saatavilla ohjelmistoilla saadaan aikaan varmasti skaalautuva järjestelmä.
Voidaan siis valita joko vapaan lähdekoodin ohjelmisto tai jokin kaupallinen ohjelmisto. MySQL
osoittautui Linux-käyttöjärjestelmässä kaikkein tehokkaimmaksi. ODBC tarjoaa siis
mahdollisuuden käyttää myös heterogeenista tietokantaympäristöä, mutta tällöin jokaisella
päivitysasiakkaalla (PNAC) tulisi olla ODBC-ajuri jokaiseen erilaiseen järjestelmään. On myös
määritettävä kuinka tieto sijoitetaan eri puolille verkkoa: Huolehtiiko jokin erillinen yhtiö tai
regulaattori päivitystietokannoista vai levitetäänkö tieto tilaajan siirtymisestä suoraan
operaattoreille. Ensiksi mainittu on hallinnollisesti yksinkertaisempi ratkaisu. Ennen kuin
numerotiedot lisätään, tulee tietokannat alustaa. Tässä vaiheessa tulee oleelliseksi, miten
76
numeroavaruus jaetaan tauluihin. Tehtävä on sitä oleellisempi mitä suuremmasta
siirrettävyysalueesta on kysymys tilaajien lukumäärällä mitattuna. Kuvaus numeroavaruuden
jakamisesta annetaan konfigurointitietona tietokantaa alustettaessa. PNDB:hen tulee puolestaan
luoda siirtymätaulut jokaista operaattoria varten. UDB sisältää varsinaisen päivitystaulun, johon on
kirjoitusoikeudet vain regulaattorilla tai sillä taholla, joka päivityspalvelimia hallitsee. Muita
konfiguroitavia numerotietokantojen parametreja ovat taulujen (relaatioiden) nimet. Pääosa
konfiguroinnista tapahtuu asiakasohjelmistoihin (PNAC, NA, RIS). Niihin täytyy asettaa DSN, jota
asiakas palvelee sekä DSN, josta päivitykset luetaan sekä kaikkien DSN:t, joihin lähetetään tieto
mainostettaessa tilaajan siirtymistä.
8.2.2 Käyttöesimerkki
Tarkastellaan esimerkkinä siirrettävyysaluetta, jossa on 5 palveluntarjoajaa, yksi regulaattori sekä
10 miljoonaa tilaajaa. Com1:llä ja Com2:lla on 3 miljoonaa tilaajaa, Com3:lla on 2 miljoonaa
tilaajaa sekä Com4:llä ja Com5:llä miljoona tilaajaa. Regulaattori on katsonut tarpeelliseksi
ylläpitää kolmea päivityspalvelinta. Com1 ja Com2 käyttävät numeroavaruuden jakoon kahta
ensimmäistä merkkiä tilaajanumerosta, Com3 ainoastaan ensimmäistä merkkiä ja Com4 sekä Com5
sijoittavat kaikki tilaajanumerot (etuliitteet) samaan tauluun numerotietokannassa. Regulaattori
muodostaa yhden siirtymätaulun jokaiselle operaattorille sekä yhden päivitystaulun kuhunkin
päivitystietokantaan. Jokainen operaattori tarvitsee vähintään yhden PNAC:n, joka mainostaa
kaikille regulaattorin päivityspalvelimille uutta reititysnumeroa tilaajalle hänen siirtyessä. Sama
asiakas käy määrävälein lukemassa päivityspalvelimelta regulaattorin vahvistamat siirtymiset ja
päivittää sen mukaisesti numerotietokannan eli toimii samalla numerointiagenttina. Regulaattorin
AVCC lukee päivitykset siirrettävyystauluista (COM1…COM5) päivitystauluun (NP_TABLE).
77
Regulator
NP1
NP2NP3
Com2
NDB
Com3NDBCom4
Com5
NDB
NUMBERS
NUMBERS2
:
NUMBERS9
NUMBERS1NDB
NUMBERS
NUMBERS12
:
NUMBERS99
Com1
NDB
NUMBERS12
:
NUMBERS99
NUMBERS11
NUMBERS11COM3
COM4
COM2
COM1
NP_TABLE
COM5
COM3
COM4
COM2
COM1
NP_TABLE
COM3
COM4
COM2
COM1
NP_TABLE
COM5
COM5
H_DSN=Com1PNP_DSN=NP3SNP_DSN=NP2
H_DSN=Com2PNP_DSN=NP2SNP_DSN=NP3
{NP1,NP2,NP3}
{NP1,NP2,NP3}
H_DSN=Com3PNP_DSN=NP2SNP_DSN=NP1
{NP1,NP2,NP3}
H_DSN=Com5PNP_DSN=NP1SNP_DSN=NP2
{NP1,NP2,NP3}
H_DSN=Com4PNP_DSN=NP1SNP_DSN=NP2
{NP1,NP2,NP3}
Regulator
NP1
NP2NP3
Com2
NDB
Com3NDBCom4
Com5
NDB
NUMBERS
NUMBERS2
:
NUMBERS9
NUMBERS1NDB
NUMBERS
NUMBERS12
:
NUMBERS99
Com1
NDB
NUMBERS12
:
NUMBERS99
NUMBERS11
NUMBERS11COM3
COM4
COM2
COM1
NP_TABLE
COM5
COM3
COM4
COM2
COM1
NP_TABLE
COM3
COM4
COM2
COM1
NP_TABLE
COM5
COM5
H_DSN=Com1PNP_DSN=NP3SNP_DSN=NP2
H_DSN=Com2PNP_DSN=NP2SNP_DSN=NP3
{NP1,NP2,NP3}
{NP1,NP2,NP3}
H_DSN=Com3PNP_DSN=NP2SNP_DSN=NP1
{NP1,NP2,NP3}
H_DSN=Com5PNP_DSN=NP1SNP_DSN=NP2
{NP1,NP2,NP3}
H_DSN=Com4PNP_DSN=NP1SNP_DSN=NP2
{NP1,NP2,NP3}
Kuva 8.1. Järjestelmän alustus
Relaatio NP_TABLE vastaa kappaleessa 7.4.2 esitettyä relaatiota moved_numbers. Jokainen
operaattori määrittele asiakasparametrit, joita ovat ainakin palveltavan numeropalvelimen DSN
(NDB_DSN), primäärin (PNP_DSN) ja sekundaarin (SNP_DSN) päivityspalvelimen DSN sekä
lista kaikista regulaattorin palvelimista, joihin tieto siirtymisestä lähetetään. Numerointiagentit
käyvät siis määrävälein hakemassa uusimmat siirtymiset regulaattorilta siltä palvelimelta, jota
PNP_DSN-parametri osoittaa. Vikatilanteessa tietoa haetaan toissijaiselta palvelimelta.
Operaattorin numerotietokanta on koko ajan synkronoitu automaattisesti jokaisen regulaattorin
palvelimen kanssa, koska ne kaikki pyrkivät samansisältöiseksi inkrementaalisten päivitysten sekä
mahdollisten uudelleenlähetysten ansiosta. Väliaikaisesti tila saattaa vaihdella juuri
epäonnistuneiden päivitysten sekä operointiviiveen vuoksi.
Kun tietokannat on konfiguroitu, täytyy regulaattorin päivityspalvelimiin saada data, ennen kuin
palvelu voidaan käynnistää. Palvelun käynnistysvaiheessa lisätään lyhyitä numeroita
päivitystietokantoihin. Tietueiden reititysnumeroksi annetaan jokin E.164 numero (tai IP-osoite,
mikäli kyseessä on Internet-puhelinliikennettä välittävä operaattori), jolla puhelu reitittyy oikean
operaattorin verkkoon. Operaattorilla 5 voi olla käytössä numeroavaruudesta kaikki numerolla 2
alkavat numerot. Näin siis alun perin millään muulla operaattorilla ei ole tilaajia, joiden
puhelinnumero alkaa 2:lla. Päivitystietokantoja alustettaessa operaattoria 5 varten tarvitsee lisätä
siirrettävyystauluun (NP_TABLE) periaatteessa vain yksi tietue jokaista sen alueella olevaa
puhelinkeskusta (tai CPS:ää) kohden. Olkoon operaattorilla 5 kolme puhelinkeskusta, joiden
reititysnumerot ovat 243, 267 ja 288. Näin ollen tietueet (”243”, ”243”), (”267”, ”267”) ja (”288”,
”288”) lisätään kaikkiin regulaattorin päivitystietokantoihin. Aikaleimat jätetään tässä
78
huomioimatta [Kappale 7.4.2]. Operaattoreiden 4 ja 5 NA-asiakkaiden [Kuva 8.1] luettua
päivitykset regulaattorin tietokannasta ne lisäävät paikallisiin numerotietokantoihin tauluihin
NUMBERS samat tietueet. Operaattori 3 lisää tauluun NUMBERS2 tietueet (”43”,”243”),
(”67”,”267”) ja (”88”,”288”). Operaattorit 2 ja 1 puolestaan lisäävät tauluihin NUMBERS24
tietueen (”3”,”243”), tauluihin NUMBERS26 tietueen (”7”,”267”) ja tauluihin NUMBERS28
tietueen (”2”,”288”). Käytännössä käytetään kuitenkin useampia numeroita puhelinkeskusta kohti.
Vastaavalla tavalla määritetään kaikkien muidenkin operaattoreiden reititysnumerot. Jos tilaaja
24377662 siirtyy operaattorin 4 alueelle, operaattorin 4 PNAC lähettää päivitystietueen
(”24377662”,”466”), jokaiseen regulaattorin tietokantaan tauluun COM5 olettaen, että siirtyvä
tilaaja siirtyy reititysalueelle 466. Operaattorin 5 vahvistettua pois siirtyminen regulaattorin AVCC
siirtää päivityksen taulusta COM5 päivitystauluun, josta edelleen operaattoreiden asiakkaat käyvät
sen aikanaan lukemassa. Huomattakoon, että alkusynkronoinnissa numerotietokantaan lisätty tietue
(”243”,”243”) on edelleen voimassa. Haut tehdään noudattaen pisimmän osuman periaatetta, joten
avain ”24377662” antaa lopulta oikean reititysosoitteen 466.
8.2.3 Päivitysoperaatioiden laukaisu
Määrävälein tehtävä haku voidaan määritellä esimerkiksi käyttöjärjestelmän crontab-toiminnolla
UNIX-pohjaisissa järjestelmissä. Sopiva hakujen väliaika voi olla minuutista kymmeneen
minuuttiin. Päivitysoperaatio voidaan laukaista monella eri tavalla – joko ylläpitäjän tai asiakkaan
toimesta. Asiakkaan laukaisemiin päivityksiin täytyy liittyä kuitenkin jonkinlainen autentikointi.
Internetissä voidaan käyttää esimerkiksi jotakin HTTP-pohjaista rajapintaa [39] laukaisemaan
päivitysoperaatio. GSM-verkossa voidaan käyttää puolestaan SMS-palvelua käynnistämään uuden
reititystiedon lähetys, mikäli asiakkaalle halutaan antaa mahdollisuus itse mahdollisuus informoida
siirtymisestä.
Päivityspalvelimien tietosisältöä puhdistetaan koko ajan. Normaalisti siirrettävyystaulun tietueella
ei enää tee mitään sen jälkeen, kun jokainen asiakasoperaattori on lukenut sen ja päivittänyt oman
tietokantansa. Luotettavuuden takaamiseksi kannattaa kuitenkin pitää siirtymiset taulussa riittävän
kauan – esimerkiksi viikon tai kuukauden. Näin numerotietokanta voi korjata korruptoituneen
tietosisällön regulaattorin tietokantojen avulla, mikäli riittävän uusi varmuuskopio on saatavilla.
Mikäli kaikki NDB- ja UDB-palvelimet sekä NA:t palvelimet toimivat moitteettomasti, ei tietueita
tarvitse pitää tauluissa ainakaan tuntia kauemmin. Päivityspalvelin puolestaan toipuu vikatilanteista
ilman minkäänlaisia toimenpiteitä, koska sen sisältö voidaan koska tahansa tuhota. Tämän jälkeen
se alkaa ottaa uusia päivityksiä vastaan operaattoreiden PNAC-asiakkailta, ja tietyn ajan kuluttua se
on valmis palvelemaan operaattoreita. Kuten todettua, useimmiten riittäisi pitää tietueita kannassa
korkeintaan tunnin ajan. Tosin juuri uudelleen käynnistettyä UDB:ta ei voida käyttää NDB:n
uudelleensynkronoinnissa, koska päivityshistoria on tuhottu. Minkäänlaista replikointia muiden
palvelimien kanssa ei siis tarvita. UDB:n uudelleen käynnistyksessä ei voida siirtää PNDB:stä
UDB:hen niitä uudelleen lähetettyjä tietueita, jotka ovat ajalta ennen uudelleen käynnistystä, koska
niiden ajankohtaisuudesta ei voida olla varma. Korruptoituneen UDB:n asiakkaat vaihtavat UDB:tä.
Toipunut UDB jää uudeksi toissijaiseksi palvelimeksi.
79
8.2.4 Operaattori/regulaattori-rajapinnan SQL-kyselyt
Operaattorin ja regulaattorin välille määritellään siis ODBC pääsyrajapinnaksi. Sen lisäksi tarvitaan
neljä jo aiemmin esiteltyä standardia SQL-kyselyä:
INSERT INTO COMX (D_NUMBER, R_NUMBER, U_TIME, RETRY) VALUES (’$dnum’, ‘$rnum’,
$cur_time, 0)
INSERT INTO COMX (D_NUMBER, R_NUMBER, U_TIME, RETRY) VALUES (’$dnum’, ‘$rnum’,
$u_time, 1)
SELECT D_NUMBER, R_NUMBER, MAX(U_TIME), S_TIME FROM moved_numbers WHERE
S_TIME > $timestamp GROUP BY D_NUMBER ORDER BY ASC S_TIME
UPDATE COMX SET CONFIRM=1 WHERE D_NUMBER=’$dnum’
Kaksi ylintä liittyvät päivitystietueiden levitykseen (PNAC -> PNDB). Seuraava liittyy
päivitystietojen hakuun (NA -> UDB) ja alin siirtymisen vahvistamiseen (PNAC -> PNDB). Edellä
esitetty onkin oikeastaan kaikki, mitä tarvitsee standardoida monien osapuolten ympäristössä. Toki
jos ajatellaan numerotietokantoja ja päivitystietokantoja kaupallisina ohjelmistoina, tulee myös
numerotiedon hakuun liittyvät SQL-kyselyt määritellä, mutta edellä esitetty riittää
siirrettävyystiedon levitykseen.
8.3 Skaalautuvuus
8.3.1 Oletukset
Taulukossa 3 [sivu 73] esitetyt MySQL:n hakuaikojen numeroarvot toteutuvat, jos koko tietokanta
pidetään palvelinkoneen muistissa (RAM). Levyltä hakeminen on huomattavasti hitaampaa. 50
miljoonan tilaajan siirrettävyysalueella tulee varautua noin 1 GB:n suuruiseen tietokantaan. Jos
indeksoinnin oletetaan vievän saman verran muistia kuin data, vaaditaan että tietokantapalvelimen
käytössä tulee olla 2 GB muistia. Tällöin on realistista tehdä oletus kuvan 3.2 [sivu 19] perusteella,
että haut eivät hidastu taulun koon kasvaessa eivätkä taulujen lukumäärän kasvaessa. Taulukon 3
[sivu 73] perusteella arvioidaan, että yksi haku kestää 400µs. Jotta ei oltaisi liian optimistisia,
oletetaan, että 400µs kuluu kokonaisuudessaan palvelimella. Reititystiedon haku suoritetaan
ainoastaan yhden kerran puhelua kohti, ja jokaisessa puhelussa B-tilaajan numero saadaan
peräkkäislähetyksellä käyttäen DTMF-merkkejä (Discrete Tone Multi Frequency) siten, että
näppäilyjen väliaika on kesimäärin 0.5 s.
Palvelimeen kohdistuvaan kuormaan vaikuttavat erityisesti verkossa kutsujen saapumisintensiteetti
(λ). Puhelinkeskuksen kuormitukseen vaikuttaa myös puhelujen pitoaika. CPS:n (Call Processing
Server) osalta puhelun pitoajan vaikutus kuormitukseen on vähäisempi, jos media ei kulje CPS:n
kautta. Esimerkiksi SIP-siganalointia (Session Initiation Protocol) käytettäessä [8] CPS (SIP-proxy)
ei välitä mediaa. Oletetaan kuitenkin, että jokainen tilaaja aiheuttaa kiiretunnin aikana
80
liikenneintensiteetin (a) 0.03 erlang [40], ja että keskimääräinen puhelun pitoaika (h) on 3
minuuttia. Numerotietokannan päivitykset aiheuttavat liikennettä myös jonkin verran. Arvioidaan
karkeasti kuten aiemminkin tässä työssä, että 10 prosenttia tilaajista siirtyy vuosittain. Vuorokauden
siirtymisistä neljäsosa sattuu kiiretunnille. Oletetaan vielä, että tilaajanumeron pituus vaihtelee
välillä 6-10 numeroa, jolloin RIS joutuu lähettämään NDB:lle keskimäärin 6 SQL-kyselyä, jos
keskimääräinen tilaajanumeron pituus on 9 numeroa [Kappale 7.3.4]. NA puolestaan lähettää
NDB:lle keskimäärin 3 SQL-kyselyä yhtä päivitysoperaatiota kohden.
8.3.2 Laskelmat
Seuraavissa laskelmissa tarkastellaan erityisesti RIS:n ja NDB:n skaalautuvuutta. PNDB:n ja
UDB:n skaalautuvuus on aivan ilmeistä, koska kyselyjä niihin kohdistuu vuosittain vain joitakin
miljoonia. Sen sijaan NDB:hen saattaa kohdistua miljoonia kyselyjä tunnissa. Kiiretunnille saadaan
kyselyjä NA:lta:
h
kyselyä10300
vuosi
vrk365
vuosi
päivitystä105
päivitys
kyselyä3
h
vrk1/4N
6
NA ≈⋅⋅
⋅=
Tilaajakohtaisen liikenneintensiteetin 0.03 erlang ja keskimääräisen puhelun pitoajan 3 minuuttia
avulla voidaan laskea tilaajakohtainen kutsuintensiteetti [40]:
tunnissa
puhelua0.6
1/603
0.03a/hÿÿha =
⋅==ÿ=
Saapuvien kutsujen intensiteetti saadaan jakamalla edellinen tulos kahdella1, joten jokainen tilaaja
aiheuttaa kiiretunnin aikana NDB:hen kutsuintensiteetin 0.3 puhelua tunnissa. Tämä vastaa BHCA-
arvoa 15 miljoonaa. Kiiretunnille saadaan kyselyjä RIS:ltä:
ävyysalueh/siirrett
kyselyä109
yysaluesiirrettäv
tilaajaa1050
puhelu
kyselyä6
tilaaja
puhelua0.3N 6
RIS7⋅=⋅⋅⋅=
Kyselyjä joudutaan suorittamaan paljon. NA:n aiheuttama kuorma on siis varsin mitätön verrattuna
RIS:n aiheuttamaan kuormaan. NA:n aiheuttama kuorma ei pienene palvelimia lisättäessä, jos
NDB:n sisältöä ei hajauteta eri palvelimiin, koska päivitys suoritetaan UDB:n tietojen perusteella
jokaiseen siirrettävyysalueen palvelimeen. Sen sijaan RIS:ien aiheuttama kuorma pienenee
merkittävästi, jos palvelimien lukumäärää lisätään. Lasketaan kuinka monta sarjallista kyselyä
NDB pystyy suorittamaan tunnissa:
1 Pätee ainoastaan likimääräisesti, koska kiiretunnin aikana on todennäköisempää, että B-tilaaja on varattu,
jolloin A-tilaaja yrittää hetken kuluttua uudestaan aiheuttaen lisää kuormaa palvelimeen.
81
kyselyä/h109.0ly0.4ms/kyse
h3600000ms/C 6
NDB ⋅≈=
Kapasiteetti tukee edellisen kappaleen oletuksilla 1500000 BHCA:n puheluliikennettä. Näin
voidaan laskea tarvittavien palvelimien (NDB) lukumäärä:
1010.001...kyselyä/h109.0
yä/h10300kyselkyselyä/h109
C
NNlkm
6
7
NDB
RISNANDB ≈=
⋅+⋅=+=
Luku on melko pieni ottaen huomioon pessimistiset alkuoletukset. Ensinnäkin tietokantapalvelimen
hakuajat on saatu ajamalla palvelinta PC:ssä, jollaisen saa kaupasta nykyisin korkeintaan parilla
tuhannella eurolla. Tosin muutama ylimääräinen muistikampa täytyy asentaa1. Jokaista puhelua ei
todellisuudessa muodosteta peräkkäislähetyksellä. Esimerkiksi GSM-verkossa peräkkäislähetys ei
ole edes mahdollinen. Ainakaan MySQL ei suorita kyselyjä sarjallisesti, vaan useita hakuja
suoritetaan samanaikaisesti. Varsinaista kuormitustestiä, jossa palvelimen kuormitusta mitattaisiin
useilla asiakkailla samanaikaisesti, ei tähän diplomityöhän sisälly. Oletettu 400µs edustaa pahinta
tapausta. Tosin LIKE-predikaatin sisältävät kyselyt [esim. sivulla 58] ovat hieman hitaampia kuin
taulukon 3 osoittama 0.4 ms sivulla 73. Säikeistettyjen proseduurien etu tulee esiin etenkin monen
CPU:n palvelinlaitteistoilla. Käytännössä kuitenkin edellä laskettu 1500000 BHCA vastaa erittäin
suurta liikennettä. Liikenneintensiteetillä 0.03 erlang/tilaaja ja keskimääräisellä puhelun pitoajalla 3
minuuttia tämä vastaa noin 5 miljoonan tilaajan puhelinkeskusta (tai CPS:ää). Tällaisia tiettävästi ei
ole missään käytössä. Realistisesti voidaan olettaa, että yksi NDB puhelinkeskusta tai CPS:ää
kohden riittää.
NDB:n skaalautuvustarkastelun myötä numeron siirrettävyyteen liittyvä tiedonhallintaongelma on
ratkaistu, koska tilallisista elementeistä (tietokantapalvelimista) NDB:hen kohdistuu suurin kuorma.
Käytännössä suurin osa hakuihin liittyvästä prosessoinnista tapahtuu RIS:ssä. RIS joutuu ajamaan
mahdollisesti tuhansia samanaikaisia prosesseja. Peräkkäislähetys on erittäin kuormittavaa, koska
hakuprosessi kestää tavallisesti useita sekunteja, sillä näppäilyjen välillä voi olla jopa sekuntien
taukoja. Pahin tilanne RIS:n kannalta on se, että merkit lähetettäisiin puhelimella, joka toimii
kiekkopyörittimellä. Tällöin B-tilaajan numeron lähettäminen saattaisi kestää kymmeniä sekunteja.
Suurin osa PSTN-päätelaitteistakin kuitenkin tukee peräkkäislähetystä DTMF-merkeillä. RIS ei
säilytä tilatietoa puhelinnumeroista hakuprosessin elinikää kauemmin. Mikäli RIS kaatuu, puhelu
estyy2, ja tilaaja voi yrittää myöhemmin uudestaan. RIS:n muistin tyhjeneminen aiheuttaa estoa
vain vikaantumishetkellä ja siihen asti, kunnes RIS on käynnistynyt uudelleen. Reititystietojen
integriteettiin RIS:n vikaantumisella ei ole vaikutusta.
1 Edellyttää, että emolevy tukee riittävän lisämuistin asentamista.
2 Puhelu estyy, mikäli tilaajaa palvelevaa RIS:ää ei ole kahdennettu.
82
Edellä esitettyihin laskelmiin ja oletuksiin perustuen voidaan arvioida prosessien lukumäärää
RIS:issä kiiretunnin aikana. Keskimääräinen hakuprosessin elinikä:
4.0silähetysväl
s0.5
puhelu
iälähetysväl8tPS/RIS =⋅=
Keskimääräinen prosessien lukumäärä kiiretunnin aikana:
16700tilaajaa1050tilaaja/h
puhelua0.3
s
h
3600
1
puhelu
s4.0lkm 6
PS/RIS ≈⋅⋅⋅⋅=
Saatu tulos kuvaa sitä, kuinka montaa hakuprosessia ajetaan keskimäärin samanaikaisesti koko
siirrettävyysalueella kiiretunnin aikana. Liikennevolyymiltaan miljoonan BHCA:n
puhelinkeskukseen arvo olisi hieman yli tuhat. Prosessointikapasiteettia siis tarvitaan. Mikäli
käytettäisiin ainoastaan kertalähetystä, tulos pienenisi erittäin ratkaisevasti, koska yksittäinen haku
kestäisi vain 400µs. Samanaikaisia prosesseja syntyy, jos merkkejä joudutaan odottelemaan A-
tilaajalta. Tässä diplomityössä RIS:stä on ohjelmoitu ainoastaan se puoli, joka lähettää kyselyjä
NDB:lle. Työ ei puutu siihen, miten tilaajan lähettämät numerot saadaan RIS:lle [funktio ”GET
DIGIT” kuvassa 7.5 sivulla 60]. SIP-puhelun muodostukseen kyseinen funktio olisi helpommin
toteutettavissa kuin televerkkoon johtuen erityisesti avoimista standardeista ja protokollista
ohjelmistokehityksessä.
83
9 Johtopäätökset
9.1 Teknologia
Standardien ja protokollien merkitystä ei tietoliikennetekniikassa voi väheksyä. Numeron
siirrettävyys on kuitenkin palvelu, jossa monet tekijät puoltavat tässä diplomityössä esitettyä
sovellustason ratkaisua. Eli jokaista bittiä tai tavua ei tarvitse määritellä jossakin standardissa, jotta
järjestelmä olisi toimiva, koska käytetään valmista standardia sovellusta, joka piilottaa bittitason
asiat. Tietoa operaattoreiden välillä lähetetään tekstimuotoisena. Osapuolten lukumäärä on melko
pieni. Voidaan melko realistisesti olettaa, että siirrettävyysalueella toimivien palveluntarjoajien
lukumäärä on korkeintaan joitakin kymmeniä. Tilaajien siirtymisestä aiheutuvat päivitykset eivät
tarvitse olla globaalisti saatavilla, vaan ainoastaan siirrettävyysalueen sisällä. Toisaalta jollakin
siirrettävyysalueella toimiva järjestelmä tulee olla siirrettävissä toiselle siirrettävyysalueelle, mikäli
ajatellaan siirrettävyyttä tukevaa järjestelmää kaupallisena ohjelmistona.
Tässä diplomityössä on osoitettu, että luotettava ja tehokas tiedonhallintajärjestelmä numeron
siirrettävyyttä varten saadaan aikaiseksi melko pienillä kustannuksilla. Esitetyt ratkaisut on testattu
ympäristöissä, jotka sisältävät lähes yksinomaan julkisen lähdekoodin ohjelmistoja. Järjestelmä
toimii tarpeeksi tehokkaasti laitteilla, jotka eivät ole kaikkein uusinta uutuutta. Eli mitään 32:n
CPU:n palvelinlaitteistoja ei tarvita tietokantapalvelimille. Ohjelmistojen lisäksi tarvitaan joitakin
työasemia ajamaan palvelimia ja asiakasohjelmistoja [Kuva 8.1 sivulla 77]. Työ ei kuitenkaan ole
puuttunut siihen, mitä muutoksia vaaditaan PSTN/ISDN-puhelinkeskuksiin tai niiden kanssa
toimiviin IN-elementteihin, jotta palvelu voitaisiin toteuttaa. Puhelun muodostukseen tulee ainakin
muutoksia. Jokaiselle puhelulle tulee tehdä numeromuunnos, jonka jälkeen suoritetaan perinteinen
numeroanalyysi. Nykyinen IN-teknologia pystyy tukemaan palvelua, mutta siihen on mahdollisesti
tehtävä joitakin päivityksiä, mikä tietysti maksaa.
Skaalautuvuudessa esitetty ratkaisu on aivan ylivertainen TRIP/CTRIP-ratkaisuun [5] nähden.
Internetissä nykyiset 140000 reittiä runkoverkossa ovat jo siinä määrin liikaa, että BGP ei täysin
toteuta sitä tehtävää, jota varten protokolla on alun perin tehty. Mukautuminen topologian
muutoksiin on hidastunut, koska vasteaikoja (hold time) topologiamuutoksiin on pidennetty.
Yhdenkin runkoverkon linkin vikaantuminen saattaa aiheuttaa todella massiivisen ketjureaktion,
jonka aikana verkon toiminnallinen tila on huono. Reitittimien kapasiteettia kuluu paljon
reititystaulujen uudelleen laskemiseen. TRIP/CTRIP:ssä numeron siirrettävyys sidotaan
reititykseen, jolloin tilaajan siirtyessä mahdollisesti kaikkien palvelimien tietosisältö muuttuu.
Tietosisällön muutos tapahtuu kappaleessa 2.4.4 esitetyn päätösprosessin tuloksena. Näin ollen
tilaajan siirtyminen vastaisi TRIP:llä sitä, että BGP:llä poistettaisiin jostakin reitti ja lisättäisiin
jonnekin reitti. Operaation seuraus vastaa sitä BGP:n ketjureaktiomaista toimintaa, jossa
reititystaulujen uudelleen laskenta pitää suorittaa mahdollisesti jokaisessa reitittimessä, ja sen
mukaisesti mainostaa naapureille uusia reittejä. Jokainen ketjureaktio saattaa aiheuttaa suuren
määrän uusia ketjureaktioita. Jos Internetissä 140000 tietueella prosessointi on raskasta, miten
84
vaikeaa prosessointi olisi toimittaessa niillä mahdollisesti kymmeniä miljoonia tietueita sisältävillä
tietokannoilla, joita syntyisi 50 miljoonan tilaajan siirrettävyysalueella? Tämän diplomityön
ratkaisussa mitään ketjureaktioita ei synny, koska tilaajan siirtyminen ei muuta verkon loogista
topologiaa, sillä numeron siirrettävyys on irrallaan reitityksestä. Vikatilanteista toipuminen
tapahtuu monistettujen UDB-tietokantojen avulla sekä paikallisella NDB:n varmuuskopioinnilla.
Vikatilanteesta toipuminen tehokkaasti ei edellytä edes kovin korkeatasoista verkkoyhteyttä, koska
synkronoinnissa siirrettävän tiedon määrä on vähäinen. Päivitystietueiden levitys regulaattorin
kautta on perusteltua, koska tieto tilaajan uudesta reititysnumerosta on joka tapauksessa levitettävä
kaikkialle.
TRIP/CTRIP-tutkimus [5] ei esitä ratkaisua skaalautuvuusongelmaan eikä esitä toteutusta sille,
miten reititystieto haetaan palvelimelta. Tässä diplomityössä on otettu huomioon molemmat.
Reititystiedon haussa käytetään hyväksi relaatiotietokantojen tehokkaita hakurakenteita
sellaisenaan. Ohjelmistokehityksessä säästetään paljon resursseja, koska tehokkaita tietorakenteita
ei tarvitse kehittää. Asiakasohjelmistojen tarvitsee ainoastaan generoida SQL-kyselyjä. Voidaan siis
käyttää hyväksi niitä mittavia tuloksia, joihin tietorakenteiden ja erityisesti relaatiotietokantojen
tutkimuksessa ja tuotekehityksessä ollaan päästy. Tällöin selvitään periaatteessa hyvinkin
yksinkertaisilla ja kevyillä ratkaisuilla numeron siirrettävyyden vaatimissa ohjelmistoissa. TRIP:lle
ja CTRIP:lle voi jäädä silti tärkeä rooli televerkon ja IP-verkon välisessä yhteistoiminnassa. TRIP
ja CTRIP tarjoavat mahdollisuuden operaattorin politiikan mukaisen optimaalisen yhdyskäytävän
valintaan televerkon ja IP-verkon rajan ylittäville puheluille. Nähtäväksi jää, kuinka nopeasti
verkkojen konvergenssi etenee vai eteneekö lainkaan. Näin ollen jää myös nähtäväksi, tarvitaanko
TRIP:iä tai CTRIP:iä lainkaan. Tämän diplomityön ratkaisu on riippumaton verkkoteknologiasta ja
jättää TRIP:lle ja CTRIP:lle option etsittäessä sopivaa yhdyskäytävää.
ENUM:in (E.164 Number Mapping) [30] käyttöä toteutettaessa numeron siirrettävyys IP-verkon ja
televerkon välillä on myös esitetty. ENUM:ssa on monia yhtäläisyyksiä tämän diplomityön
ratkaisun kanssa. Se erottaa myös numeron siirrettävyyden reitityksestä. Tiedon tallennuksen
rakenne sen sijaan ENUM:ssa on aivan erilainen, koska käytetään hajautettua hierarkkista
rakennetta. ENUM:in etu on se, että yksittäinen palvelin on vastuussa vain osasta numeroavaruutta.
Haittana tästä on hitaat vasteajat tietueiden muutoksiin, koska hajautuksen etu saadaan aikaan
välimuisteilla. Vastuu siirtyneestä tilaajasta jää tilaajan alkuperäiselle operaattorille. Tietueiden
elinikä välimuistissa määrää, kuinka nopeasti haut tuottavat päivitettyä tietoa. Lyhyet eliniän
määrittelyt vievät pois hajautuksesta saatava etua, ja luotettavuus saattaa heiketä. Monistettu
arkkitehtuuri on hajautettua luotettavampi. Etäälle hajautetut tietokannat lisäävät myös liikennettä
verkossa. Luotettavuuteen vaikuttavat sekä palvelimien että verkon linkkien vikaantumisen
todennäköisyydet. ENUM toisi mukanaan Internetin nimipalvelun ongelmat televerkonkin
numeropalveluun. Nykyisin Internetin nimipalvelu on erittäin altis etenkin
palvelunestohyökkäyksille (engl. denial of service attack).
85
9.2 Numeron siirrettävyys tulevaisuudessa
Suomessa regulaattorin päätöksen mukaisesti [1] numeron siirrettävyyspuhelinverkossa toteutetaan
kolmessa vaiheessa. 1.7.2003 siirrettävyyden on toimittava siten, että GSM-puhelu ohjataan aluksi
alun perin tilaajaa palvelleeseen verkkoon, josta se ohjataan edelleen siihen verkkoon, johon tilaaja
on siirtynyt. 1.1.2004 pitää GSM-puhelut pystyä välittämään suoraan siihen verkkoon, johon tilaaja
on siirtynyt. Aikataulu on siis erittäin tiukka. Vielä toisessa vaiheessa kiinteän verkon siirtyneille
tilaajille kohdistuvat puhelut voidaan ohjata alkuperäisen operaattorin kautta. Kolmannessa
vaiheessa, jonka aikataulusta ei ole vielä tätä diplomityötä kirjoitettaessa tarkkaa tietoa, kaikki
puhelut välitetään suoraan siihen verkkoon, jossa tilaaja kullakin hetkellä on. Internet-puheluista ei
vielä mitään päätöstä ole tehty.
Numeron siirrettävyyttä arvatenkin haluavat eniten uudet telemarkkinoille pyrkivät operaattorit,
koska tällöin asiakkaiden olisi helpompi vaihtaa liittymää. Vastaavasti merkittävän markkina-
aseman saavuttaneille suurille operaattoreille numeron siirrettävyys merkitsee hyvin ilmeisesti
tilaajien menetyksiä. Puhelujen hintakilpailu varmasti kovenee, koska ensimmäinen keino uusille
operaattoreille saada uusia asiakkaita on tarjota puheluja kilpailijoita halvemmalla. Siirrettävyys
sinällään ei kuitenkaan ole syy vaihtaa palveluntarjoajaa vaan se, että joko hinnoitteluun tai
palveluihin ei olla tyytyväisiä. On kuitenkin selvää, että kovin suuriin investointeihin normaali
liikeyritys ei lähde, jos niillä pyritään toimiin, jotka johtavat asiakkaiden menetyksiin!
Toinen merkittävä markkinapoliittinen ongelma liittyy puhelujen hinnoitteluun. Nykyisinhän tilaaja
pystyy ainakin perinpohjaisen tutkiskelun jälkeen tekemänsä palvelusopimuksen ja puhelinnumeron
perusteella päättelemään, paljonko puhelu kyseiseen numeroon maksaa. Jos siirrettävyys
toteutetaan, ei numerosta enää näe, minkä operaattorin tilaajalle ollaan soittamassa. Näin ollen ei
voida tietää kuinka paljon puhelu maksaa, ellei hinnoittelua yhtenäistetä. Ongelma liittyy siis
kuluttajansuojaan. Mahdollisesti puhelujen hinnoittelua on siis yhtenäistettävä tai muutettava
veloituskäytäntöä siten, että myös B-tilaaja maksaa osan puhelusta. Kolmas keino olisi jonkin
nauhoitteen avulla ilmoittaa jokaista puhelua muodostettaessa A-tilaajalle paljonko puhelu maksaa.
Kun numeromuunnos on tehty, tiedetään missä B-tilaaja on ja sen perusteella paljonko puhelu
maksaa. Eri asia on jälleen se, kuinka helposti kyseinen palvelu olisi toteutettavissa. Ainakin GSM-
verkossa on jo nykyisin nauhoiteviestit käytössä ainakin tilanteessa, jossa soitetaan
matkapuhelimeen, johon ei saa yhteyttä.
Suomessa ainakin ensimmäistä vaihetta silmällä pitäen tämä diplomityö on myöhässä, koska
numeron siirrettävyyteen liittyvät päätökset on siltä osin tehty, ja verkkojen päivitys numeron
siirrettävyyttä tukeviksi on käynnissä. Ratkaisun edut tulevatkin esiin paremmin tulevaisuuden
tietoverkoissa, jossa IP-pohjaisella televiestinnällä on merkittävä asema. Riippumattomuus
verkkoteknologiasta tekee ratkaisusta mukautuvan. Toteutettu prototyyppi tukee numeron
siirrettävyyttä mistä tahansa teknologiasta mihin tahansa teknologiaan. Siirrettävyys
verkkoteknologiasta toiseen edellyttää kuitenkin loogisen numeroinnin yhtenäistämistä. E.164:n
mukaiset numerot ovat yksinkertaisia ja tarjoavat laajan numeroavaruuden. Ainakin teoriassa
86
tilaajalle voidaan antaa mikä tahansa käytössä olevaan numeroavaruuteen kuuluva luettelonumero,
joka ei ole minkään muun numeron etuliite. Ratkaisu on siis erityisesti tulevaisuuden tietoverkkoja
varten sekä sellaisia maita varten, joissa numeron siirrettävyydestä ei ole tehty vielä päätöksiä.
87
Lähdeviitteet
1. Viestintävirasto (FICORA): Ennakkopäätös matkaviestinverkkojen numeron siirrettävyydestä.
Nro. 172/520/02 Pvm. 20.3.2002.
2. R. Kantola, J. Requena, N. Beijar: Interoperable routing for IN and IP Telephony. Computer
Networks, 2001. Vol. 35, 597-609
3. M. Peuhkuri: Luentokalvot kurssilla S-38.192 Verkkopalvelujen tuotanto: Luento 2: Domain
Name System. Teknillinen korkeakoulu, Tietoverkkolaboratorio 2002. Saatavilla
http://www.tct.hut.fi/opetus/s38192/k2002/slides/handout-09security.pdf. Sisältö tarkistettu
2.12.2002.
4. J. Rosenberg, H. Salama, M. Squire: RFC 3219 Telephony Routing over IP, IETF Proposed
Standard. Saatavillaftp://ftp.isi.edu/in-notes/rfc3219.txt.
5. N. Beijar: Diplomityö: Distribution of Numbering Information in Interconnected Circuit and
Packet Switched Networks. Teknillinen korkeakoulu, Tietoverkkolaboratorio 2002
6. J. Postel:RFC 791:Internet Protocol, IETF Standard. Saatavillaftp://ftp.isi.edu/in-
notes/rfc791.txt.
7. S. Deering, R. Hinden:RFC 1883, Internet Protocol version 6, IETF Proposed Standard.
Saatavillaftp://ftp.isi.edu/in-notes/rfc1883.txt.
8. H. Schulzrinne. Graduate course “Internet Multimedia”. Oulu, Kesäkuu 2002, Luentomonisteet.
9. Y. Rekhter, P. Gross:RFC 1771: Border Gateway Protocol version 4, IETF Standard. Saatavilla
ftp://ftp.isi.edu/in-notes/rfc1771.txt.
10. J. Moy: RFC 2328: Open Shortest Path First version 2, IETF Standard. Saatavilla
ftp://ftp.isi.edu/in-notes/rfc2328.txt.
11. J. Rosenberg, H. Schulzrinne: RFC 2871: A Framework for Telephony Routing over IP, IETF
Informational Document. Saatavillaftp://ftp.isi.edu/in-notes/rfc2871.txt.
12. J. Luciani, G. Armitage, J. Halpern, N. Doraswamy:RFC 2334 Service Cache Synchronisation
Protocol, IETF Proposed Standard. Saatavillaftp://ftp.isi.edu/in-notes/rfc2334.txt.
13. M. Luoma: Luentokalvot kurssilla S-38.192 Verkkopalvelujen tuotanto: Luento 9: Peering.
Teknillinen korkeakoulu, Tietoverkkolaboratorio 2002. Saatavilla
http://www.tct.hut.fi/opetus/s38192/k2002/slides/09peering.pdf. Sisältö tarkistettu 2.12.2002.
88
14. R. Kantola, J. Requena, N. Beijar: A Common Numbering Infrastructure for IN and IP
Telephony, IN2000. Saatavillahttp://www.tct.hut.fi/tutkimus/ipana/paperit/. Sisältö tarkistettu
2.12.2002.
15. T. Bates, R. Chandra, E. Chen: RFC 2796 Route Reflection – An Alternative to Full Mesh
IBGP, IETF Poposed Standard. Saatavillaftp://ftp.isi.edu/in-notes/rfc2796.txt.
16. Telstra Corporation & Geoff Huston: Internet BGP Table, saatavilla:http://bgp.potaroo.net/.
Sisältö tarkistettu 2.12.2002.
17. V. Fuller, T. Li, J. Yu, K. Varadhan: RFC 1519: Classless Interdomain Routing, an Address
Assignment and Aggregation Strategy, IETF Proposed Standard. Saatavillaftp://ftp.isi.edu/in-
notes/rfc1519.txt.
18. T. Socolofsky, C. Kale: RFC 1180 A TCP/IP Tutorial, IETF Informational Document.
Saatavillaftp://ftp.isi.edu/in-notes/rfc1180.txt.
19. MySQL Interactive Documentation:http://www.mysql.com, KPNQwest Finland Oy:n peili
http://mysql.kpnqwest.fi. Sisältö tarkistettu 2.12.2002.
20. J. Puustjärvi: Luentokalvot kurssilla T-76.143 Tiedonhallintajärjestelmät. Teknillinen
korkeakoulu, syksy 2001.
21. J. Hoffer, M. Prescott, F. McFadden: Modern Database Management, sixth edition, Prentice
Hall 2002. ISBN 0-13-042355-6.
22. Transaction Processing Performance Council (TPC) Home Page:http://www.tpc.org/. Sisältö
tarkistettu 2.12.2002.
23. Microsoft Universal Data Access websites: Saatavillahttp://www.microsoft.com/data/.
Microsoft Home Pagehttp://www.microsoft.com. Sisältö tarkistettu 2.12.2002.
24. E. F. Codd: A Relational Model of Data for Large Relational Databases. Communications of
the ACM 13. June 1970.
25. PostgreSQL Global Development Group: PostgreSQL Home Pagehttp://www.postgresql.org.
Sisältö tarkistettu 2.12.2002.
26. PHP (Hypertext Preprocessor) Home Page:http://www.php.net. Sisältö tarkistettu 2.12.2002.
27. MyODBC Reference Manual for Version 3.51:http://www.mysql.com/products/myodbc/,
KPNQwest Finland Oy:n peilihttp://mysql.eunet.fi/products/myodbc/manual_toc.html.
28. The X/Open SQL Call Level Interface, X/Open Company LTD, Online, 1995
Saatavilla http://www.rdg.opengroup.org/public/tech/datam/cli.htm. Sisältö tarkistettu
2.12.2002.
89
29. C. Perkins: RFC 3344: IP Mobility Support for IPv4, IETF Proposed Standard. Saatavilla
ftp://ftp.rfc-editor.org/in-notes/rfc3344.txt.
30. P. Faltström: RFC 2916: E.164 number and DNS, IETF Proposed Standard. Saatavilla
ftp://ftp.isi.edu/in-notes/rfc2916.txt.
31. R. Kantola: S-38.118 Teletekniikan perusteet, luentomonisteet syksy 2000, TKK,
Tietoverkkolaboratorio. http://www.tct.hut.fi/opetus/s38118/s00/oppimateriaali.shtml. Sisältö
tarkistettu 2.12.2002.
32. J. Costa Requena, "An Implementation of the Server Cache Synchronization Protocol”, M.Sc
thesis, Laboratory of Telecommunications Technology, Helsinki University of Technology,
1999.
33. Open LDAP Foundation Home Page:http://www.openldap.org/. Sisältö tarkistettu 2.12.2002.
34. M. Wahl, T. Howes, S. Kille: RFC 2251 Lightweight Directory Access Protocol (v3). IETF
Proposed Standard. Saatavillaftp://ftp.isi.edu/in-notes/rfc2251.txt.
35. ANSI SQL 92 (SQL-2) määrittely. Saatavillahttp://www.netaktive.com/biblio/sql/. Sisältö
tarkistettu 2.12.2002.
36. R. Rivest: RFC 1321: The MD5 Message-Digest Algorithm, IETF Informational Document.
Saatavillaftp://ftp.isi.edu/in-notes/rfc1321.txt.
37. Netscape SSL 3.0 Specification. Saatavillahttp://wp.netscape.com/eng/ssl3/. Sisältö tarkistettu
2.12.2002.
38. J. Postel. RFC 793: Transmission Control Protocol, IETF Standard: Saatavilla
ftp://ftp.isi.edu/in-notes/rfc793.txt.
39. R. Fielding, J. Gettys, J. Mogul, H. Frystuk, P. Leach, T. Berners-Lee, RFC 2068: HyperText
Transfer Protocol –HTTP/1.1, IETF Proposed Standard. Saatavillaftp://ftp.isi.edu/in-
notes/rfc2068.txt.
40. S. Aalto: Luentomonisteet kurssilla S-38.145: Liikenneteorian perusteet, Teknillinen
korkeakoulu, Tietoverkkolaboratorio. Kevät 2002. Saatavilla
http://www.tct.hut.fi/opetus/s38145/k02/luennot/luento01.pdf. Sisältä tarkistettu 2.12.2002.