FI110981B - Datakorjausjärjestelmä viestintäliikenneverkkoa varten - Google Patents

Description

110981

A- S

DATAKORJAUSJÄRJESTELMÄ VIESTINTALIIKENNEVERKKOA VARTEN

Esillä oleva keksintö liittyy datan korjausjärjestel-, maan, jota käytetään datan keräämisessä ja käsittelyssä moniverkkoisessa viestintäliikenteessä. v 5 Kun viestintätapahtumat, esimerkiksi puhelinsoitot tai datasiirrot, tapahtuvat yhden verkon sisällä, on tunnettua kirjata ja käsitellä dataa, joka liittyy noihin viestintäta-pahtumiin. Tavallisesti yleisessä kytkentäisessä puhelinverkossa (PSTN) kerätään dataa puhelun kestosta, ja sitä 10 käsitellään suhteessa ainakin vuorokauden aikaan ja puhelun tyyppiin, jotta verkko-operaattori voi synnyttää erittely-kohdan laskuun, joka osoitetaan tilaajalle, joka aloitti puhelun.

Viime vuosina PSTN:iä varten olevat datajärjestelmät 15 ovat välttämättä tulleet kasvavasti monimutkaisiksi, kun tilaajien saatavilla olevien palvelujen ja puhelutyyppien valikoima on suuresti kasvanut. Esimerkiksi 0800-numeroiden tullessa käyttöön ei enää laskutetakaan soittoa aloittanutta tilaajaa. Monia muita monimutkaisia palveluja on jo kokeilun 20 alla ja saatavissa PSTN:issä, kuten esimerkiksi puhelunsiirto (call forwarding), jossa ensimmäisen tilaajan aloittama puhelu valittuun numeroon siirretään automaattisesti verkon toimesta eri numeroon kustannuseron tullessa veloitetuksi vastaanottavalta tilaajalta.

·, 25 Toinen viestintäliikenneverkkojen aspekti, joka on huomattavan muutoksen alaisena, on olemassa olevien verkko-operaattoreiden runsaus. Ennen PSTNriä ylläpitivät pääasiassa valtiolliset organisaatiot osana kansallista infrastruktuuria. Nykyään ja lisääntyvässä määrin PSTN:ien yksityistä-30 minen ja rajoittavien monopolien löystyminen tarkoittaa sitä, että tilaajien saatavilla on paljon enemmän verkko-operaattoreita, ja näiden verkko-operaattoreiden on käytännön syistä saatava aikaan verkkojen välinen yhteys. Tämä tarkoittaa sitä, että verkko-operaattoreiden on otettava 35 huomioon ei ainoastaan omissa verkoissaan tai itsenäisten mutta samanlaisten viestintäliikenneharjoittajien (admini-: strations) yhteen kytketyissä verkoissa, joita on rajoitettu 2 110981 määrä, esiin tulevat viestintätapahtumat, vaan myös viestin-tätapahtumat, jotka tulevat esiin teoreettisesti hyvin suuressa määrässä erityyppisiä kilpailevia verkkoja, jotka tarjoavat tilaajille laajan valikoiman palveluja.

5 Tämän takia on lisääntyvässä määrin tärkeää, että kerätään ja käsitellään dataa, joka liittyy viestintätapah-tumiin, jotka tulevat esiin operaattorin verkon ulkopuolella mutta jotka päättyvät operaattorin verkkoon tai yksinkertaisesti kulkevat operaattorin verkon poikki.

10 Kun soitot kulkevat useamman kuin yhden operaattorin verkon läpi, nousevat esiin operaattorien väliset hinta- ja laskutussopimukset toisten puhelujen kuljettamisesta. Tällaiset järjestelyt voivat vaihdella yksinkertaisesta "Lähettäjä Pitää Kaiken"-järjestelystä (Sender Keeps All, 15 SKA) monimutkaisiin hinnoittelukaavoihin.

Tietoliikenteessä on ollut vakiintuneena käytäntönä erillisten verkko-operaattorien ja viestintäliikenneharjoit-tajien välillä se, että soittodatan kerää viestintäliikenne-harjoittaja, joka vastaa verkosta, jossa soitto tulee esiin.

20 Jos tämä soitto päättyy toiseen verkkoon, niin viestintälii kennehar joittaja, joka liittyy toiseen verkkoon, luottaa ensimmäisestä verkosta vastuussa olevan viestintäliikennehar joittajan keräämään dataan esimerkiksi laskut tami s tarkoituksissa (accounting purposes). Tietoliikenneympäristö 25 kuitenkin muuttuu nopeasti, poliittisesti, kuten myös teknisesti. Kasvavan kilpailun kynnyksellä on kasvavassa määrin houkuttavaa verkkojen viestintäliikenneharjoittajille monitoroida ei ainoastaan liikennettä, joka tulee esiin heidän omissa verkoissaan, vaan myös liikennettä, joka tulee 30 esiin muualla, mutta joka kulkee läpi tai päättyy heidän omassa verkossaan. Jos verkko, jossa liikenne tulee esiin, kuuluu kilpailevalle operaattorille tai viestintäliikennehar joittajalle, on haluttavaa, että vähintään olisi mahdollista tarkistaa kilpailevan operaattorin laskutukset 35 (accounts).

Tunnetuissa järjestelyissä datakeräyspisteet puheluja : PSTNrssä koskien ovat olleet verkon paikalliskeskuksissa, 110981 j 3 koska paikalliskeskus poimii liikenteen, kun se tulee esiin.

Tämä järjestely ei kuitenkaan pysty huolehtimaan (provide , for) datakeräämisestä suhteessa verkkojen väliseen liiken teeseen. Vaikka olisikin datakeräyspisteitä, jotka keräisi-, 5 vät dataa verkkoon tulevista puheluista, niin tällaisen datan käsittelyyn mille tahansa yksityiskohtaisuuden tasolle liittyvä logistiikka on masentavaa. Esimerkiksi on arvioitu, että Britanniassa British Telecommunications plc:n (BT) operoimaan PSTNrään sisääntulevien puhelujen määrä muilta 10 verkkojen viestintäliikennehar joitta jilta, mukaan lukien Isle of Man ja Cellnet-soluverkko, oli yhteenlaskettuna 15.4 miljoonaa puhelua päivässä kahtenatoista kuukautena maaliskuuhun 1992. Tämän luvun odotetaan kasvavan luokkaan 27 miljoonaa puhelua per päivä vuodessa maaliskuuhun 1995.

15 Ottaen huomioon kaikki puhelu tapahtumat, mukaan lukien ne, jotka tapahtuvat BT:n PSTNrn sisällä, on vuodelle 1995 ennustettu 60 miljoonaa puhelutapahtumaa päivässä.

Asiaan liittyvästä hyvin suuresta datamäärästä huolimatta on tätä keksintöä tehtäessä havaittu mahdolliseksi 20 suunnitella prosessi datan, joka liittyy suureen tietoliikenneverkkoon, brittiläiseen PSTN:ään, tuleviin puheluihin, keräämiseksi ja käsittelemiseksi, missä prosessi voi tuottaa riittävän yksityiskohtaisen ulostulon, jotta asiaan liittyvän verkon viestintäliikennehar joitta jän sallitaan synnyttää . 25 laskutusinformaatiota, joka voidaan ei ainoastaan osoittaa ulkopuolisille verkkoviestiliikenneharjoittajille asianmukaisesti ja joka myös tukee eriteltyä laskutusta (itemised billing). Tämä tarkoittaa, että laskutusinformaatio voidaan hajottaa riittävän yksityiskohtaisesti, jotta jopa identifi-30 oidaan yksittäiset puhelut, niin pitkään kuin ne täyttävät ennalta valitut kriteerit, eritellyn laskutuksen tapaan, joka tällä hetkellä on käytettävissä kansallisessa laskutusjärjestelmässä brittiläistä PSTN:ää varten British Telecommunications plc:stä.

35 Esillä olevan keksinnön ensimmäisen aspektin mukaisesti saadaan aikaan prosessi kerätä ja käsitellä dataa, joka ; koskee viestintätapahtumia ensimmäisessä tietoliikennever- 4 110981 kossa, missä verkko sisältää vähintään yhden yhteyspisteen, joko suorasti tai epäsuorasti, toiseen tietoliikenneverkkoon, jonka yhteyspisteen keinoin mainitussa toisessa verkossa esiin tuleva viestintätapahtuma voidaan siirtää 5 mainittuun ensimmäiseen verkkoon, ja viestintätapahtuma voi joko kulkea mainitun ensimmäisen verkon poikki tai päättyä mainittuun ensimmäiseen verkkoon, prosessin sisältäessä askeleet: i) datan kerääminen datasaantipisteessä mainitussa 10 yhteyspisteessä mainitun datan koskiessa viestintätapahtu- maa, joka tulee esiin mainitussa toisessa verkossa, ja sisältäessä reitti-informaatiota ja vähintään yhden parametriini t tauksen, esimerkiksi keston, suhteessa mainittuun viestintätapahtumaan; 15 ii) mainitun datan siirtäminen datakäsittelyjärjestelmään; ja iii) mainitun datan käsittely.

Keräämällä dataa ensimmäisen ja toisen verkon välisessä yhteyspisteessä tulee ensimmäiseen verkkoon liittyvälle 20 viestintäliikennehar joittajalle mahdolliseksi saada ensi käden tietoa ensimmäiseen verkkoon sisään tulevista viestin-tätapahtumista, ja täten potentiaalisesti tarkistaa muiden verkko-operaattoreiden ja viestintäliikenneharjoittajien tuottama data.

25 Esillä olevan keksinnön toisen aspektin mukaisesti on saatu aikaan datakäsittelyjärjestely datan, joka on kerätty PSTN:ssä yhteyspisteessä toisen verkon kanssa, käsittelemiseksi, järjestelyn sisältäessä: i) datasisäänmenon datan, joka koskee viestintätapahtumia 30 tietoliikenneverkosta, syöttämiseksi, mainitun datan sisältäessä vähintään yhden monista luokkaominaisuuksista (sort characteristics); ii) varmistuselimet datasisäänmenossa vastaanotetun datan eheyden (integrity) ja riittävyyden tarkastamiseksi; 35 iii) data-analysaattorin varmistuselimien hylkäämän datan analysoimiseksi ja korjatun tai oletuksellisen (default) datan alistamiseksi varmistuselimille; 110981 5 iv) hinnoitteluelimet varmistetun datan, jonka varmis-tuselimet ovat antaneet ulostulonaan, hinnoittelemiseksi < päivitettävän referenssi-informaation mukaisesti; ja v) ulostuloelimet, jotta annetaan ulostulona hinnoiteltu, ' 5 varmistettu data hinnoitteluelimiltä muistipaikkoihin kunkin muistipaikan ollessa omistettu datalle, joka liittyy (relevant) yhteen tai useampaan mainituista luokkaominai-suuksista.

Edullisesti hinnoitteluelimet voivat myös tehdä datan 10 kelvolliseksi (validate data) ja antaa ulostulona virheelliseksi todetun (errored) datan data-analysaattorille, joka voi olla edellä mainittu data-analysaattori tai eri analysaattori, jotta data, joka on turmeltunut, voidaan mahdollisesti muotoilla uudelleen tai korjata muulla tavoin 15 ja siten viedä uudelleen järjestelmään kelvollisena viestin-tätapahtuman tietueena.

Voi olla myös (tai vaihtoehtoisesti) niin, että tätä pidemmälle menevää data-analyysin askelta käytetään analysoimaan dataa suhteessa eri tyyppiseen virheeseen.

20 Esimerkiksi data-analyysi, joka suoritetaan virheellisenä pidetylle datalle, jonka varmistuselimet ovat paikallistaneet, voisi tulla todetuksi virheelliseksi pääasiallisesti formaatin ja reitti-informaation suhteen, kun taas hinnoit-teluelimistä tuleva virheellisenä pidetty data voisi tulla 25 todetuksi virheelliseksi pääasiassa hinnoitteluinformaation suhteen.

Prosessien ja datakäsittely järjestely jen, kuten sellaisten, joita kuvattiin edellä esillä olevan keksinnön ensimmäisenä ja toisena aspektina, tärkeänä osana on niissä 30 käytetty data-analysaattori.

Esillä olevan keksinnön kolmannen aspektin mukaisesti • 4 saadaan aikaan data-analysaattori käytettäväksi tietoliikenneverkossa, joka verkko on kytketty yhteen tai useampaan muuhun verkkoon, data-analysaattoriin kuuluessa sisäänmeno 35 dataa, joka on kerätty suhteessa mainittuun verkkoon, varten, mainitun datan ollessa tullut mainittuun verkkoon 1 liittyvien kelvolliseksi tekevien elimien (validating means) 6 110981 hylkäämäksi, elimet datassa esiin tulevan epäkelpoisuuden tyypin arvioimiseksi, ja elimet datan käsittelemiseksi sen mukaisesti, mainittuihin elimiin datan käsittelemiseksi kuuluessa elimet käyttää oletusarvoja (means for applying 5 default values), elimet käyttää korjattuja arvoja, ja elimet liittää (append) data tiedostoihin väliaikaisessa datavarastossa, kuhunkin tiedostoon ollessa liitetty dataa, joka tuo näkyviin tunnusomaisen virhemallin, järjestelyn ollessa sellainen, että kaikki data, joka on liitetty yhteen 10 tiedostoon väliaikaisessa datavarastossa, voidaan korjata samalla tavalla, esimerkiksi päivittämällä referenssi-informaatiota suhteessa mainittuun virhemalliin.

Luokkaominaisuudet tulevat tyypillisesti olemaan sellaisia, että muistipaikat kukin sisältävät dataa, joka on 15 merkityksellistä viestintätapahtumille, jotka tulevat olemaan laskutettavia (billable) yhteiselle laskutusentitee-tille, joka esimerkiksi tulee esiin yhteisessä vastaavassa tietoliikenneverkossa.

Luokkaominaisuuksia voidaan käyttää edellä kuvatun 20 datakäsittelyjärjestelyn missä tahansa lukuisassa vaiheessa. Kuitenkin esimerkiksi PSTN:ssä esiin tulevan virheellisenä pidetyn datan luonne tekee suotavaksi saada aikaan luokitte-luelimet (sorting means) kohdan iii), data-analysaattori, joka liittyy varmistuselimiin, ja kohdan iv) hinnoittelueli-25 met, väliin. Näin ollen hinnoitteluelimet kohdistavat toimintansa jo luokiteltuun dataan. Jos luokkaominaisuudet liittyvät eri entiteetteihin, joita laskutetaan suhteessa datan esittämiin viestintätapahtumiin, niin silloin tällä järjestelyllä voi olla myös etuna, että hinnoitteluelimiä 30 voidaan mahdollisesti yksinkertaistaa käytettäessä yksittäi-siin entiteetteihin kuuluvia rajoitteita.

Voidaan huomata, että verkko kuten BT PSTN sisältää sekä paikallisia että kaukokeskuksia ja se tarjoaa ei pelkästään keskusten välistä puhelusiirtoa vaan myös 35 paikallispuhelujakelua loppukäyttäjälle. Tämä tarkoittaa, että datakeräämisen ja käsittelyn, joita tarvitaan tukemaan laskutusta tai laskutuksen varmistamista, on oltava riittä- 110981 7 vän monimutkainen käsitelläkseen erittäin laajaa muuttujien valikoimaa. Tämä on vastakkaista tilanteelle, jossa verkko * tarjoaa vain kaukokeskusten välistä siirtoa tai ainoastaan paikallispuhelujakelua.

' 5 Seuraavaksi kuvataan esillä olevan keksinnön suoritus muodon mukaista järjestelmää pelkästään esimerkin avulla viitaten mukana seuraaviin piirustuksiin, joista: kuva 1 esittää kaaviomaisesti datan, joka sisältää 10 puheluinformaatiota, jotta tuetaan tietoliikenneverkkoon sisään tulevia puhelutapahtumia varten olevaa laskutusjärjestelmää, keräämistä ja käsittelyä varten olevan järjestelmän arkkitehtuuria; kuvat 2, 3 ja 4 esittävät kuvassa 1 esitetyn järjestel-15 män yleisnäkymävuokaavioita; kuva 5 esittää kuvan 1 järjestelmää varten olevan laitteisto- ja tietoliikennekaavion; kuva 6 esittää ohjelmistoarkkitehtuuria käytettäväksi nauhatallennusaseman (streamer) ja data-analysaattorin 20 välissä kuvan 1 mukaisessa järjestelmässä; kuva 7 esittää laitteiston, joka saa aikaan yritysjär-jestelmän käytettäväksi kuvan 1 järjestelmässä, arkkitehtuuria; kuva 8 esittää kaaviokuvaa eräjärjestelmäkäsittelyark-25 kitehtuurista (batch array processing architecture) käytettäväksi kuvan 7 yritysjärjestelmässä; kuvat 9 ja 10 esittävät keskustiedostoa (exchange file) ja Advanced Protocol Data Unit (APDU) -formaattia yhteydessä datan kiertokyselyyn keskuksista käytettäviksi kuvan 1 30 järjestelmässä; kuvat 11-21 esittävät vuokaavioita, joita käytetään kuvan 1 mukaisen järjestelmän nauhatallennusasemassa ja data-analysaattorissa; kuva 22 esittää kuvan 1 järjestelmän elementtien 35 välisiä prosessivuorovaikutuksia; kuvat 23 - 30 tuovat esille entiteetin elämänhisto-riakaaviot (entity life history diagrams), jotka esittävät 8 110981 tilaa, jossa tietue (record) kussakin entiteetissä voi olla, ja mitä muita tiloja voidaan milläkin toimenpiteellä saavuttaa tuosta tilasta; kuvat 31 ja 32 esittävät esityslistan tilaa ja malli-5 verkkoa (pattern net), jotka seuraavat datapopulaatiota ja säännön sytytystä (firing of a rule) asiantuntijajärjestelmässä, käytettäväksi kuvan 1 järjestelmässä; kuvat 33 ja 34 esittävät objektihierarkioita sääntökan-tajär jestelmää ja tapauskantajär jestelmää varten vastaavassa 10 järjestyksessä, joita käytetään kuvan 1 mukaisen järjestelmän data-analysaattorissa; kuva 35 esittää suunnitteluperiaatteet, jotka liittyvät kuvan 1 mukaisen järjestelmän data-analysaattoria varten olevan asiantuntijajärjestelmä/ORACLE-liitynnän rakentami-15 seen; kuva 36 esittää yritysjärjestelmän datamallia käytettäväksi kuvan 1 mukaisessa järjestelmässä; kuvat 37 - 43 esittävät vuokaaviota, jotka kuuluvat data-analysaattorin, jota käytetään kuvan 1 järjestelmässä, 20 toimintaan; kuva 44 esittää kuvan 1 mukaisessa järjestelmässä käytettävää öatavirtausta painotuksen ollessa datassa, joka on merkityksellistä (relevant) yritysjärjestelmälle.

25 Seuraavan kuvauksen joissakin kohdissa ja joissakin piirustuksien kohdissa on voitu silloin tällöin käyttää termejä "INCA" ja "IDA". Nämä tulevat sanoista Inter-Network Call Accounting (verkkojen välinen puhelulaskutus), koko järjestelmän kuvaus, ja sanoista INCA Data Analyser.

30 Jälkimmäinen on viittaus data-analysaattoriin 7, johon sisältyy asiantuntijajärjestelmä ja joka on liitännässä nauhatallennusaseman 6 kanssa.

35 110981 9

Jatkossa seuraava kuvaus on esitetty seuraavalla „ tavalla:

1 . KUVA 1 : ARKKITEHTUURIN LOHKOKUVA

5 2. KUVAT 2,3 JA 4: VUOKAAVIOT PROSESSIN YLEISKATSAUSTA

VARTEN

i) yhdistämispiste (Point of Interconnect) ja DDC

ii) nauhatallennusasema iii) yritysjärjestelmä (tai laatikko)

10 3. KUVAT 1 JA 5-8: LAITTEISTO-, TIETOLIIKENNE- JA OHJEL

MISTOARKKITEHTUURIT

i) POI ja DDC

ii) nauhatallennusasema ja data-analysaattori iii) yritysjärjestelmä 15 iv) asiakaslaatikot

4. KUVAT 9 JA 10: PUHELUTIETUEET JA DATAFORMAATIT

i) puhelutietueet ii) Datarakenteiden kuvaus (mapping) keskusdataan

5. KUVAT 11-19, JA 22-30: YKSITYISKOHTAISEMMAT VUOKAAVIOT 20 NAUHATALLENNUSASEMA- JA DATA-ANALYSAATTORIPROSESSEJA VARTEN

i) Nauhatallennusasema: DDC kiertokysely

ii) Nauhatallennusasema: TIEDOSTOPROSESSI

iii) Nauhatallennusasema: DDC poistaminen (deletion) iv) Data-analysaattori: Prosessi 25 v) Entiteetin elämänhistoriat 6. KUVAT 31-35: ASIANTUNTIJAJÄRJESTELMÄ i) yleiskatsaus ii) Sääntökantayleissäännöt (Rule Base Generic Rules) iii) tapauskanta (Case Base) 30 iv) Oracle-liityntä

7. KUVAT 20,21 JA 37-43: ASIANTUNTIJAJÄRJESTELMÄN KÄYTTÖ DATA-ANALYSAATTORIN TOIMESTA

8. KUVAT 36 JA 44: YRITYS JÄRJESTELMÄ, DATA-ANALYYSI JA

HINNOITTELU JA LASKUTUS

35 9. JÄLJITYSKETJU (AUDIT TRAIL) 110981 10

1 . KUVA 1: ARKKITEHTUURIN LOHKOKAAVIO

Viitaten kuvaan 1 on saatu aikaan järjestelmä, jotta kerätään dataa ensimmäisessä verkossa 1 , esimerkiksi BT 5 PSTN:ssä, datan liittyessä puhelutapahtumiin, jotka tulevat esiin tai tulevat sisään toisesta verkosta 2. Data kerätään yhdistämispisteessä (POI) 3, jonka saa aikaan mainitun ensimmäisen verkon 1 keskus, ja tuodaan yhteen PSTN:ssä olevasta noin kymmenestä aluedatakerääjästä (DDC = District 10 Data Collector) 5. Nämä sisältävät dataa, joka sisältää reitti-informaation jokaista puhelua varten, täten sallien esimerkiksi puhelun tarkoitetun päämäärän identifioinnin, kuljettajan, jolta puhelu on tulossa sisään, erittelydatan siten, että jokaista puhelua voidaan käsitellä tapahtumana, 15 ja (edullisesti) kutsuvan tilaajan identiteetin (calling line identity), jotta puhelut, jotka olivat vain läpikulkevia soittoja toisessa verkossa 2, voidaan myös laskuttaa tarkasti suhteessa verkkoon, jossa ne tulivat esiin.

Jokainen aluedatakerääjä (DDC) 5 tulee kiertokysellyksi 20 nauhatallennusaseman 6 toimesta, joka laajentaa ja tekee kelvolliseksi puheludatan sekä tiedosto- että puhelu-tietuetasolla, pääasiallisesti vasten reititysreferenssimal-lia (Routing Reference Model). (Vaikka BT PSTN:n aluedatake-rääjät 5 poimivat asiaan liittyvän datan, niiden tehtävä 25 voidaan samanarvoisesti saada aikaan laskutusjärjestelmän muilla komponentti järjestelmillä, kuten sellaisella, joka tunnetaan verkkovälitysprosessorina (network mediation processor)). Data, jonka nauhatallennusasema 6 havaitsee epäkelvoksi, käännetään data-analysaattorille 7, jossa 30 käytetään tietämyspohjaista järjestelmää arvioimaan epäkel-poisuutta ja, mikäli mahdollista, muokkaamaan uudelleen dataa yritettäessä ratkaista ongelmaa. Tämä on tärkeä järjestelmän komponentti, koska epäkelpo data yleisesti menetetään laskutettavana syötteenä. Samaan aikaan kelvolli-35 seksi tehty data virtautetaan (is streamed) nauhatallen- nusasemaan toiseen verkkoon 2, josta asiaan liittyvä puhelu vastaanotettiin, liittyvän operaattorin mukaisesti, ja 110981 11 annetaan kulkea yritys järjestelmään 8.

Nauhatallennusasema 6 saa aikaan seuraavat toiminnot: * Kiertokysyy (poll) jokaiselta DDC:ltä 5 tiedostoja, jotka odottavat esillä olevan keksinnön datajärjestelmän ' 5 suorittamaa käsittelyä.

* Tekee kelvolliseksi tiedoston ja sen puhelutietueet vasten reititysreferenssimallia.

* Laajentaa puhelutiedostot ja osoittaa (allocate) oikealle tietoliikenneverkko-operaattorille.

10 * Hylkää epäkelvon datan IDA:lie 7.

* Kopioi IDA:sta 7 vastaanotetun raakatiedoston raaka-tietuevarmistusliityntähakemistoon (Raw Record Backup Interface directory).

* Poistaa tiedoston DDC:stä 5, kun data on varmistettu 15 liityntähakemistoon.

* Saa käyttäjälle aikaan käyttäjäliittymän mennä sisään reititysreferenssimallidataan.

* Saa aikaan täydellisen jäi jitysketjun nauhatallen-nusaseman läpi.

20 * Varustaa käyttäjän mahdollisuudella monitoroida virtautusoperaation (streaming operation) toimintaa ja datan eheyttä.

Data-analysaattori 7 saa aikaan seuraavat toiminnot: 25 * Kiertokysyy liityntähakemistosta tiedostoja, jotka • I · sisältävät yhden tai useamman virheen.

* Pitää virheelliset puhelutietueet pidätysalueella (suspense area), jos ne ovat kelvollisia puhelutietueita mutta eivät vastaa reititysreferenssimallia.

30 * Saa aikaan käyttäjäliitynnän siten, että käyttäjät voivat uudelleen virtauttaa (re stream) datan sen jälkeen, kun reititysreferenssimalli on päivitetty.

* Käyttää oletuspuhelutietuearvoja (default call record values) kentissä, jotka ovat virheellisiä sääntöjen määri- 35 tyksen mukaisesti.

* Virtauttaa minkä tahansa oikeellisen datan, jota ei jo ole virtautettu johtuen virhekynnysten tulemisesta ylite- 1 2 110981 .

tyiksi.

* Virtauttaa minkä tahansa korjatun datan.

* Saa aikaan täydellisen jäijitysketjun IDA:n 7 läpi puhelutietuetasolla.

5 Yritysjärjestelmällä 8 on myös nykyisin tärkeä rooli, koska juuri yritysjärjestelmä tuo (imports) tekijät, joita ei johdeta pelkästään puheluparametreista vaan myös yhdistettyjen verkkojen 1,2 operaattorien välisestä suhteesta. Vaikutus, joka puhelulla tulee olemaan laskutusmenettelyssä, 10 määritetään osittain sellaisten tekijöiden kuin asiaan kuuluvien operaattorien välisen "palvelutasosopimuksen" toimesta. Nämä tekijät tuodaan kuvaan mukaan yritysjärjestelmässä 8 viittauksella lukuisiin informaatiolähteisiin, joihin voi kuulua hakutaulukot (look-up tables) ja/tai 15 kansallinen laskutustietokanta (NCDB, National Charging Data Base) 9. Erityisesti ottamalla huomioon jälkimmäinen, laskutus otetaan tässä esimerkiksi aikariippuvista laskutushinnoista.

Ulostulo yritysjärjestelmästä 8 on täten lopulta 20 laskutusjärjestelmässä käytettävää informaatiota, joka esittää raakapuheludataa, joka on kerätty yhteyspisteessä 3 ja jota on käsitelty suhteessa asiaan kuuluviin parametreihin, kuten operaattori-ominaisiin ja aikariippuviin parametreihin, joiden tulisi olla voimassa. Tämä ulostulo saadaan 25 aikaan asiakasjärjestelmään 10, joka antaa käyttäjäpääsyn henkilökohtaisen tietokoneen avulla.

2. KUVAT 2,3 JA 4: PROSESSIYLEISKUVAUS

Viitaten kuviin 2, 3 ja 4 vuokaavioita voidaan käyttää 30 antamaan prosessiyleiskuvaus edellä olevasta toiminnassa ·. vasteena puhelutapahtumalle.

2 (i) YHDISTÄMISPISTE JA DDC

Kuva 2 esittää prosessiaskeleet, jotka POI-keskus 3 ja DDC 5 suorittavat vasteena sisään tulevalle puhelulle.

35 Kaikki nämä askeleet ovat tunnettuja keskuksen 3 ja DDC:n 5 ollessa modifioimattomia esillä olevan keksinnön tarkoituksiin .

1 3 110981

Viitaten kuvaan 2 asiaankuuluvaan verkkoon 1 tuleva tai siitä lähtevä puhelu synnyttää askeleessa 200 puhelutietueen POI-keskuksessa 3. Askeleessa 210 keskus 3 antaa jokaiselle puhelutapahtumalle "Tiedoston LuontiNumeron" järjestyksessä v 5 0 — 9999. Askeleessa 220 keskus 3 ryhmittää puhelutietueet edistyneisiin protokolladatayksiköihin (APDU, Advanced Protocol Data Units), ja ryhmittää APDU:t tiedostoihin.

Askeleessa 230 DDC 5 kiertokysyy keskukselta 3 kaikkea puhelutietuedataa APDU-formaatissa. Askeleessa 235 DDC 5 10 lisää ohjausdatan otsikko-APDU:n ja jälkiosa-APDU:n muodossa. DDC 5 myös antaa askeleessa 240 jokaiselle tiedostolle tiedostosekvenssinumeron alueelta 0 - 999999, ja antaa askeleessa 245 jokaiselle APDU:lie APDU-sekvenssinumeron alueelta 0 - 16353 APDU:iden ollessa binaariformaatissa.

15 Askeleessa 250 DDC 5 sijoittaa tiedostot hakemistorakentee-seen, josta nauhatallennusasema 6 voi poimia ne kierto-kysymällä. Samaan aikaan askeleessa 260 tiedostosta tehdään merkintä (entry) luettelotiedostoon, jonka nimi on DIRINDEX.

Tämä luettelotiedosto sisältää listan kaikista tiedostoista, 20 jotka ovat saatavilla nauhatallennusaseman 6 kiertokyseltä-väksi.

2 (ii) NAUHATALLENNUSASEMA

Viitaten kuvaan 3 askeleessa 300 nauhatallennusasema 6 25 kiertokyselee DDC-hakemistorakenteen jaksollisesta syöttäen puhelutietueet luku/kirjoitusmuistiin (RAM), jokaisen tiedoston ollessa ladattu 1 megatavuun. Tähän kiertokysely-prosessiin sisältyy viimeisimmän DIRINDEX-tiedoston kopioin-tiaskel. Askeleessa 310, joka käytännössä voi olla osa 30 askeleen 300 DDC-kiertokyselyprosessia, data muunnetaan binaarista ASCII-formaattiin (American Standard Code for Information Interchange).

Askeleessa 320 nauhatallennusasema 6 suorittaa puhelu-tietueiden kelvolliseksi tekemisen (validation). Jos puhelu-35 tietue on epätäydellinen tai virheellinen siten, ettei sitä voida varmistaa, niin sen sijaan, että edettäisiin seuraa-viin käsittelyaskeliin nauhatallennusasemassa 6 ja lopulta 110981 14 laskutusprosessiin, se suunnataan liityntähakemistoon (askel 330) pidemmälle menevää analyysiä varten data-analysaattorissa 7.

Kelvollinen data sen sijaan etenee askeleessa 340 5 tunnistusprosessiin, missä puhelutietueessa olevaa dataa käytetään osoittamaan, mistä toisesta verkosta puhelu oli peräisin, tai mistä se tuli BT PSTNrään, tai joissakin tapauksissa mihin puhelu oli tarkoitettu päättymään. Koodi, joka esittää asiaankuuluvaa verkko-operaattoria laskutusta 10 varten, lisätään puhelutietueeseen, ja sitten tiedostot hajoitetaan ja rakennetaan uudelleen askeleessa 350 tuon koodin mukaisesti. Täten puhelutietueet tässä pisteessä voidaan luokitella verkko-operaattorin tai jonkun muun asiaan kuuluvan entiteetin mukaan, joka ainakin ensi kädessä 15 on vastuussa noiden puhelujen kustannuksesta.

Askeleissa 360 ja 370 nauhatallennusasema 6 sitten antaa ulostulona uudelleen rakennetut tiedostot yritysjär-jestelmälle 8 ja poistaa tiedostodatan DDC:llä 5 olevasta FTAM-tiedostovarastosta.

20 Katsotaanpa data-analysaattoria 7, jolla on tärkeä tehtävä suoritettavanaan, sillä dataa, jota ei voida tehdä kelvolliseksi, ei voida laskuttaa. Askeleessa 380 data-analysaattori 7 kiertokysyy liityntähakemistolta nauhatal-lennusaseman 6 askeleessa 330 syöttämiä virheelliseksi 25 havaittuja tiedostoja. Tämän jälkeen data-analysaattorilla 7 on kolme eri mahdollisuutta laittaa virheelliseksi todettu data takaisin järjestelmään.

Askeleessa 382 se pyrkii korjaamaan datan. Mikäli se pystyy siihen, korjattu data palautetaan liityntähakemis-30 toon, josta nauhatallennusasema 6 voi poimia sen. Askeleessa : 384 data-analysaattori 7 pyrkii käyttämään oletusarvoja (default values) korjauskelvottomaan dataan. Joitain dataelementtejä ei voida "paikata" tällä tavoin, koska esimerkiksi se vaikuttaisi jäijitysketjuun. Viimeiseksi 35 askeleessa 386 data-analysaattori 7 tarkastaa, onko datan ja reititysreferenssimallin (RRM) välillä yksinkertaisesti epäsovitus (mismatch). Jälkimmäinen on tietokanta, joka 110981 15 antaa reititysinformaation, ja sitä käytetään DDCrssä 5 tunnistamaan esimerkiksi puhelun määränpää. RRM:n kopioita pidetään tietoliikenneverkossa eri paikoissa, ja jos yksi kopio päivitetään vanhentuneesta tai virheellisesti, tämä 5 voi tuoda esiin epäsovituksen datassa. Mikäli asia on näin, data-analysaattori 7 syöttää nuo puhelutietueet pidätystie-dostoon (askel 388), mikä sallii niiden laittamisen takaisin nauha tai lennusaseman 6 prosessiin sen jälkeen, kun RRM on tarkastettu.

10 Jos data-analysaattori 7 ei pysty käsittelemään dataa millään edellä olevista tavoista, se syöttää sen askeleessa 390 "kuoppaan" (sump). Tämä tarkoittaa, että data on efektiivisesti menetetty, eikä sitä tulla koskaan laskuttamaan. Tästä huolimatta se voi olla käyttökelpoista analyy-15 sissä siten, että järjestelmään voidaan tehdä muutoksia ja korjauksia pitkällä aikavälillä.

2 (iii ) YRITYSJÄRJESTELMÄ

Viitaten kuvaan 4 data, tiedostotasolla, joka on tehty 20 kelvolliseksi ja käsitelty nauhatallennusaseman 6 toimesta, syötetään yritys järjestelmään 8, missä ensimmäinen askel, askel 400, on tiedostosekvenssinumeron kelvolliseksi tekeminen. Yritys järjestelmä 8 käsittelee tiedostot tiedos-tosekvenssinumerojärjestyksessä, mutta nauhatallennusasema , 25 6 on käsitellyt dataa rinnakkaisesti eri keskuksista 3. Jos tiedostosekvenssinumero on väärä, yritysjärjestelmä tekee tiedoston epäkelvoksi ja lopettaa sen käsittelyn (askel 410).

Jos tiedostosekvenssinumero on hyväksyttävä, yritysjär-30 jestelmä 8 siirtyy askeleeseen 420 puhelutietueen tekemisek-* si kelvolliseksi, tällä kertaa ei pääasiallisesti RRM:n ehdoin, kuten nauhatallennusasemassa 6, vaan painottaen enemmän dataa, joka on liittyy laskutettavaan entiteettiin, ja suhdetta, joka vallitsee laskutettavan entiteetin ja 35 ensimmäisen verkon 1 operaattorin, esimerkiksi BT:n, välillä. Laskutettava entiteetti ja BT ovat tulleet päätymään palvelutasosopimukseen (SLA, Service Level Agreement) 16 11C 9 81 ja puhelutietue saattaisi osoittaa puhelutyyppiä, joka ei ole tuon laskutettavan entiteetin, joka on voimassa olevan SLA:n alainen, saatavilla. Yritysjärjestelmä poimii tämän epäkelpoisuutena ja askeleessa 430 yrittää korjata virheel-5 lista puhelutietuetta. Jos puhelutietue voidaan korjata, se lähetetään tallennettavaksi (to be bulked) askeleessa 440 ja syötetään uudelleen yritys järjestelmään 8. Jos sitä ei voida korjata, se varastoidaan askeleessa 450 analysointia varten.

Kelvolliset puhelutietueet sillä aikaa siirretään 10 eteenpäin yritys järjestelmän hinnoittelukoneelle, askel 460, jossa yksittäiset puhelutietueet hinnoitellaan NCDB:n 9, asiaankuuluvan laskutettavan entiteetin ja BT: n välisen SLA:n ja minkä tahansa muun asiaan kuuluvan informaation mukaisesti. Hinnoitellut puhelutietueet voidaan sitten 15 ladata yhteenvetotietokantaan, askel 470, asiaan kuuluvan laskutettavan entiteetin veloittamiseksi, ja puhelutietueet tulostetaan optiselle levylle (askel 480) säilyttämistä varten.

Asiakaslaatikot 10 vastaanottavat toisesta järjestel-20 mästä poimitun informaation (downloaded information) yhteenvetotietokannasta viikottain. Jokainen asiakaslaatikko 10 on omistettu yhdelle laskutettavalle entiteetille ja sitä voidaan käyttää myös pääsynä optisen levyn varastoon ainoastaan sen "omien" puhelutietueiden saavuttamiseksi.

25

3. KUVAT 1,5,6,7 JA 8: LAITTEISTO-, TIETOLIIKENNE- JA

OHJELMISTOARKKITEHTUURIT

3 (i) YHDISTÄMISPISTE 3 JA DDC 5

Keskukset 3 ja DDC:t 5 ovat tunnettua tyyppiä, ja niitä 30 ei kuvata tässä yksityiskohtaisesti. Ne toimivat lyhyesti kerrottuna seuraavalla tavalla.

Viitaten kuviin 1 ja 2, mikä tahansa puhelu joka tulee sisään tai lähtee brittiläisestä PSTNrstä, jota operoi British Telecommunications plc (BT), kulkee nykyisin läpi 35 digitaalisen puhelinkeskuksen, joka on yhdistämispisteenä (POI) 3. Kaikki tällaiset keskukset, jotka liittyvät esillä olevan keksinnön datajärjestelmään, ovat tällä hetkellä [ 17 110981 Järjestelmä X puhelinkeskuksia tyyppejä digitaalinen risteyskytkentäyksikkö (DJSU, Digital Junction Switching . Unit), digitaalinen paikalliskeskus (DLE, Digital Local

Excahange) tai digitaalinen pääkytkentäyksikkö (DMSU, 5 Digital Main Switching Unit).

Jokainen puhelinsoitto, joka tulee sisään tai lähtee BT:n verkosta 1, kuten kuvan 2 askeleessa 200 on esitetty, synnyttää puhelutietueen POI-keskuksessa 3 formaatissa, joka tunnetaan British Telecom puhelutietuetyyppinä 6. DDC:t 5 1 0 kiertokyselevät päivittäin Järjestelmän X POI-keskuksilta 3 kaikkea APDU-formaatissa olevaa puhelutietuedataa. Kiertokysely tapahtuu käyttäen File Transfer Access and Management-protokollaa (FTAM) suurnopeuksisten BT-datalinkkien poikki. DDC:t 5 toimivat puhtaasti P0I:ista tulevien 15 puhelutietuetiedostojen kerääjinä: DDC:ssä ei tapahdu puhelutietueiden käsittelyä. DDC:eitä ei ole omistettu puhelutietuekiertokyselyyn, vaan ne suorittavat lukuisia muita datakeräys-, käsittely- ja eteenpäinsiirtotehtäviä.

Jotta nauhatallennusasemajär jestelmä 6 saisi pääsyn 20 FTAM-tiedostovarastoon DDC:ssä 5, on välttämätöntä saada aikaan identifioiminen. Tämä tehdään osoittamalla (allocating) nauhatallennusasemalle 6 asiaan kuuluvana päätejärjestelmänä verkkosolmuidentiteetti (NNI, Network Nodal Identity). NNI:tä käytetään sitten käyttäjänimenä, jotta saadaan 25 pääsy FTAM-tiedostovarastoon, tunnussanan ohella.

3 (ii) NAUHATALLENNUSASEMA 6 JA DATA-ANALYSAATTORI 7

Viitaten kuvaan 5, laitteisto- ja tietoliikennekaavio nauhatallennusasemaa 6 ja data-analysaattoria 7 varten voi 30 olla seuraava. (On ymmärrettävä, että kuvan 5 tietoliikennearkkitehtuuri esittää vain yhtä mistä tahansa tietoliikennearkkitehtuurien määrästä, jotka voivat olla sopivia erilaisissa ympäristöissä.) Nauhatallennusasemalla 6 on "kuuma-valmius"-nauhatallennusasemalaatikkovarmistus (SSB, 35 "hot-standby" Streamer Box Backup) 6a, joka alkaa toimimaan heti kun päänauhatallennusasemajärjestelmässä 6 ilmaantuu virhe, ja molemmat saadaan aikaan Hewlett-Packard HP857S- 1 8 110981 minitietokoneilla, jotka ajavat UNIX-käyttöjärjestelmää. Nauhatallennusasema 6 ja SSB 6a voivat olla kytketyt paikallisverkkoihin (LAN:eihin) 515.

Nauhatallennusaseman 6 (tai kuuma-valmiuden 6a) 5 kiertokyselemä raakadata DDCreistä 5 (ei esitetty kuvassa 5) varmuustalletetaan käyttämällä optisen levyn tallennusjärjestelmää (ei esitetty). Data kiertokysellään käyttämällä FTAM:aa (File Transfer, Access and Management, tiedoston siirto, saanti ja hallinta) BT:n Megastream-suurnopeusdata-10 linkeissä ja moniprotokollareititysverkossa (MPRN, Multiprotocol Routing Network) 510. MPRN 510 on 0SI:n (Open System Inteconnection) mukainen. Nauhatallennusaseman 6 ja data-analysaattorin 7 välissä on suoria viestintälinkkejä 515, ja "Ethernet"-silta 505 antaa nauhatallennusasemalle 6 15 ja data-analysaattorille 7 pääsyn vähintään yhteen laaja-alueverkkoon (WAN, Wide Area Network) 510, esimerkiksi siihen, jota BT käyttää PSTN:ää varten. WAN 510 puolestaan antaa pääsyn yritysjärjestelmään 8 ja asiakaslaatikoihin 10, jotka on sijoitettu primaariseen BT PSTN-verkon hallinto- ja 20 datakeskukseen. Tämä tarkoittaa, että verkon hallinta- ja datakeskus voi syöttää ja tulostaa dataa esimerkiksi analyysia varten ja syöttää lähtö- ja päivitetyt reititysre-ferenssidatat.

Viitaten kuvaan 6 data-analysaattori 7 voidaan saada • 25 aikaan Hewlett-Packard HP9000:een. Nauhatallennusasemaa 6 ja data-analysaattoria 7 varten oleva ohjelmisto käyttää hyväkseen seuraavia teknologioita: * IEF eräkäsittelyjä (Batch Processes) varten * ART/IM asiantuntijajärjestelmäkykenevyyksiä (Expert 30 System Capabilities) varten : * HP/UX versio 9.0 * Yritysobjektit PC-asiakkaana raportteja varten (Bu siness Objects as a PC client for reports) * Oracle-versio 6 35 - SQLFORMS 3 SQL*Report Writer 1.1 PL/SQL-versio 1.0 110981 19

PRO*C

SQL*NET TCP/IP versio 1.2

Kaikki nämä ovat tunnettuja ja yleisesti saatavilla. Esimerkiksi "IEF" on "Information Engineering Facility", 5 tietokoneavusteinen systeemityö-ohjelmisto(CASE-ohjelmisto)

James Martin Associates:lta, ohjelmistosuunnittelutyökalu, joka tuottaa ajettavaa koodia. Data-analysaattoriprosessit ajavat (run) fyysisesti data-analysaattorin 7 alustalla (platform) ja käyttävät SQL*NET:iä kytkeytymään Oracle-10 tietokantaan 60 nauhatallennusaseman 6 alustalla. SQL*NET TCP/lP:tä (Transport Control Protocol/Internet Protocol) voidaan käyttää nauhatallennusasema/data-analysaattoriyri-tysobjektiOracle-käyttäjien 65 toimesta, jotta päästään Oracle-tietokantaan 60, joka on sijoitettuna nauhatallen-15 nusasemalla 6, MPRN-verkon 510 kautta, tai sopivan TCP/IP-kannattajaverkon kautta (TCP/IP bearer network).

Nauhatallennusasema 6 ja data-analysaattori 7 jakavat tietokantalaitteet 60, ja käyttäjät voivat vaatia pääsyä esimerkiksi tarkastamaan tai päivittämään referenssidataa, 20 jota nauhatallennusasema 6 käyttää kelvolliseksi tekemisessä. Tietokantalaitteet 60 muun muassa ylläpitävät ohjausta, mitkä DDC:eistä 5 tulleista tiedostoista on käsitelty, ja sisältävät version reitityreferenssimallista.

PR0*C-koodi synnytetään IEF:n toimesta IEF-koodiksi 61 25 ja ulkoisiksi toimintalohkoiksi (EAB, External Action Block) 62, kuten kuvassa 6 on esitetty. Nauhatallennusasema/data-analysaattoriohjelmistokirjasto 63 on yhdistelmä (set of) "C"- ja PRO*C-moduuleita, joita voidaan kutsua EAB:iden 62 sisältä tai ART-IM:stä (Automated Reasoning Tool for 30 Information Management, automatisoitu päättelytyökalu : informaation hallintaa varten) 64. ART-IM on sovelluskohtai- nen, asiantuntijajärjestelmä, sovelluskehitysohjelmisto.

ART-IM-kehitys suoritetaan "studiossa", Motif-liitynnässä asiantuntijajärjestelmään. Kun asiantuntijajärjestelmä on 35 yksikkötarkastettu "studiossa", se levitetään (is deployed) synnyttämällä "C"-moduulit "studion" sisältä. Täten esimerkiksi prosessit voidaan luoda tuottamalla IEF-koodi 61 OS/2- 110981 20 työasemalla ja linkittämällä koodi EAB:iden 62, nauhatallen-nusasema/data-analysaattoriohjelmistokir jaston 63 ja ART—IM-koodikirjaston 64 kanssa levitysalustalla (deployment platform).

5 3 (iii ) YRITYSJÄRJESTELMÄ 8

Viitaten kuviin 7 ja 8, yrityslaatikkoon (tai järjestelmään) 8 sisältyy Hewlett-Packard-mini tietokone 70 "Emerald 890/400", joka ajaa UNlX-käyttöjärjestelmää, ORACLE-relaatiotietokantahallinta järjestelmää (RDMS, 10 relational database management system) ja "räätälöityä" sovellusta (custom application), joka on kirjoitettu käyttäen James Martin Associates' in IEF CASE-ohjelmistoa.

Yrityslaatikon 8 sisällä kaikki puhelutietueet hinnoitellaan monimutkaisten hinnoittelu- ja laskutusreferenssi-15 taulukoiden mukaisesti, ja ORACLE-yhteenve to taulukoi ta inkrementoidaan. Referenssi taulukot tarjoavat keskuksen asetusdatan (set-up data), reititysreferenssidatan, lasku-tussopimukset, hinnoittelu- ja laskutusdatan ja eri poik-keusluokat. Hinnoittelu- ja laskutusreferenssitaulukot 20 johdetaan BT: n kansallisesta laskutustietokannasta (NCDB) ja operaattorien välisistä tukkukauppahinnoittelusopimuksista.

Jotta autetaan minitietokonetta asiaan liittyvien käsittelytehtävien suuressa määrässä, Hewlett-Packardin Unix-työasemia 80, esim. 735:siä, on liitetty apuprosesso-·, 25 reiksi, jotka pyytävät käsittely tehtäviä. Minitietokoneeseen 70 voidaan tällaisia työasemia kytkeä käytännöllisesti katsoen rajaton määrä, jotta kasvatetaan puhelutietueiden määrää, jotka yrityslaatikko voi käsitellä, mutta kohtuullinen minimi BT PSTNrää varten voisi tällä hetkellä olla 30 kaksitoista. Kuten edellä todettiin, voi olla, että esillä olevan keksinnön datajärjestelmää vaaditaan käsittelemään 60 miljoonaa puhelutietuetta päivässä vuoteen 1995. Järjestely luottaa Hewlett-Packardin tuotteeseen, joka tunnetaan nimellä "Task Broker" (tehtävävälittäjä) 81 , esillä olevan 35 keksinnön datajärjestelmän ollessa asetettu ajamaan eräryh-mässä (being set up to run on batch array). Tämän tekemiseksi tapauskohtaiset (custom) parametrit on syötettävä Task 110981 21

Brokeriin, ja asiaankuuluva joukko näitä parametreja on lueteltu alla: i) Globaalit parametriasetukset (jotka ovat valinnaiset) - ketkä asiakkaat voivat päästä palvelimeen 5 - mitkä koneet voivat kaukaisesti (remotely) hallita (administer) Task Brokeria - mitä verkkomaskia käytetään - pienin ja suurin sallittu käyttäjäidentiteetti (UID,user identity) 10 - kirjaamisen laajuus (logging verbosity) - rinnakkaisesti käsiteltävien tehtäväalistusten (task submittals) suurin määrä - lista koneista, joihin asiakkaan tulisi ottaa yhteyttä palvelujen vuoksi.

15 ii) Asiakasparametriasetukset (jotka ovat valinnaiset) - lista jokaista palvelua varten, palvelimet, joihin asiakkaan tulisi ottaa yhteyttä palvelua varten.

iii) Luokkaparametriasetukset - jokaisen palvelun on oltava luokassa; aseta luokka 20 kaikille palvelutyypeille, jotka kukin kone tarjoaa.

iv) Palvelumääritykset (jokaista palvelua varten seuraavat kohdat tävtvv määrittää) - luokka 25 - affiniteetti - argumentit

Huomio, affiniteetti on numero välillä 0-1000, joka osoittaa, kuinka hyvin solmu pystyy tarjoamaan palvelua.

Task Broker on jonotusjärjestelmä, joka ohjaa, mitkä 30 työasemat pyytävät ja käsittelevät tiedostoja. Task Brokerin : käyttämiseksi yritys järjestelmän 8 kanssa on olemassa kolme ohjelmaa ja konfiguraatiotiedosto. Konfiguraatiotiedosto asettaa parametrit, jotka Task Broker vaatii toimiakseen yritys järjestelmäympäristössä sisältäen, minkä työasemien 35 kanssa se voi kommunikoida, mitä ohjelmia kutsua käsittelemään tiedostoa, ja kuinka priorisoida. Edellä esitetyt parametrit ovat konfiguraatiotiedostoparametreja.

110981 22

Kolme ohjausohjelmaa toimivat (lyhyesti esitettynä) seuraavasti. Kun tiedosto tulee yritysjärjestelmän 8 Emerald-minitietokoneeseen, pääohjelma "run_cp.sh" lähettää sen käsiteltäväksi Task Brokerin kautta ja käynnistää (kicks 5 of f) monitorointioh jelman "cleanup_cp. sh" minitietokoneessa.

Task Broker osoittaa tiedoston työasemalle, joka käsittelee tiedoston kolmannen ohjelman "cp.sh" mukaisesti. Mikäli asiat sujuvat hyvin, tiedosto palaa minitietokoneeseen, jossa "cleanup_cp.sh" osoittaa sen oikeisiin asiakasjärjes-10 telmän 10 hakemistoihin. "Cleanup_cp.sh" myös monitoroi työasemia. Jos työaseman suorittamassa käsittelyssä on ylipitkä viive, se sammuttaa Task Brokerin tuon työaseman kohdalla, koska siellä on selvästi ongelma. Lopuksi, "cleanup_cp.sh" myös ohjaa tallennusta ja tapahtumakirjaus-15 ta.

Lopulta, samoin kuin tuloste asiakasjärjestelmään 10 niin myös hinnoitellut puhelutietueet yrityslaatikosta 8 talletetaan optisiin levyasemiin 71, jotta yksittäiset hinnoitellut puhelutietueet voidaan palauttaa esiin ja 20 analysoida tulevaisuudessa.

3. (iv) ASIAKASJÄRJESTELMÄ (TAI LAATIKOT) 10

Yhdistettävien puhelujen (interconnect calls) yhteenve-to-ORACLE-tietokantataulukot poimitaan (are downloaded) ; 25 viikottain yrityslaatikosta 8 asiakaslaatikoihin 10.

Jokainen asiakaslaatikko (CLB,Client Box) 10 on Hewlett-Packardin UNIX-työasema, ja käsittelee ainoastaan yhteenve-totietokantataulukoita ja puhelutietueita, jotka synnytettiin BT:n ja toisen operaattorin, esimerkiksi Manx Tele-30 corn'in, välisen yksittäisen yhdistämissopimuksen alaisina. Asiakaslaatikko 10 ajaa ORACLE RDMSrää ja Business Objects-ohjelmistoa. Jokaisesta asiakaslaatikosta 10 saatava informaatio ei ainoastaan salli BT:n laskuttaa toista verkko-operaattoria heidän BT:n verkon käyttönsä suhteen, 35 vaan myös tarkastaa toiselta verkko-operaattorilta BTthen sisään tulevat laskut. Jokainen asiakaslaatikko 10 voi myös kysyä optisilta levyiltä 41, mutta vain puhelutietueita, 110981 23 jotka ovat asiakaslaatikkoon 10 liittyvän yhdistämissopimuk-sen alaisia. Asiakaslaatikolle ei ole mahdollista kysyä yrityslaatikolta 8 suoraan omia puhelutietueitaan, puhumattakaan niistä, jotka liittyvät muihin sopimuksiin BT:n ja 5 toisten operaattorien välillä. Henkilökohtaiset tietokoneet on kytketty asiakaslaatikkoon 10, jotta sallitaan yhteenve-totaulukoiden analyysi.

4. KUVAT 9 JA 10: PUHELUTIETUEET JA DATAFORMAATIT 10 4 (i) PUHELUTIETUEET

British Telecom Tyypin 6 puhelutietueet synnytetään asiakkaiden laskutuksen pääasiallista tarkoitusta varten. Puhelutietueiden tulisi sisältää riittävästi tietoa puhelun hinnoittelemiseksi tarkasti; pohjautuen päivämäärään, 15 aikaan, kestoon, kuljettavaan matkaan ja muihin tekijöihin. Jokainen Tyypin 6 puhelutietue voi sisältää seuraavat: * laskutustietueen pituus; * tietueen käyttö; * tietueen tyyppi; 20 * puhelutyyppi ja puheluefektiivisyys * lopetussyy (clearing cause) * aikaepäjatkuvuuslippu (vaihda GMT:hen/GMT:stä BST:stä/BST:hen); * kutsuvan tilaajan identiteetti (CLI, Calling Line 25 Identity); * reittiryhmätyyppi; * näytteistyskategoria; * reittiryhmä; * solmupistekoodi (NPC, Nodal Point Code): ainutkertainen 30 tunniste tietueen tuottavaa POI-keskusta varten; ; * linkityskenttä (käytetään, kun puhelu levittyy (straddles) useampaan kuin yhteen aikaveloituskaistaan (time-charge band); * soittavan osapuolen kategoria (yritys, asunto, maksupu- 35 helin); * veloituskaista; * valmiin osoitteen päiväys ja aika; 110981 24 * vastauksen päiväys ja aika; * soittavan osapuolen lopetuksen päiväys ja aika; * soitetun osapuolen lopetuksen päiväys ja aika; * kutsutun numeron kenttä.

5 Puhelutietueet sieppaa puhelulaskutusalijärjestelmän (CAS, Call Accounting Sub-system) tulojako ja laskutus (RAA, Renevue Apportionment and Accounting) -väline (facility), joka on kaikissa Järjestelmä X-keskuksissa. Kuten edellä on todettu, askeleessa 220 puhelutietueet ryhmitetään yhteen 10 APDUrihin, ja APDU:t edelleen ryhmitetään tiedostoon jokaisen tiedoston koon noustessa 1 megatavuun asti. Mikään tässä ryhmitysprosessissa Järjestelmä X-POI-keskuksessa ei tuhoa mitään yksittäisten puhelutietueiden osia. Kaikki puhelutietueet ovat yksinkertaisessa binaariformaatissa.

15 Viitaten kuvaan 9, jokainen keskustiedosto 40 sisältää joukon APDUrita 51, jotka ovat pituudeltaan vaihtelevia. Jokainen APDU 51 sisältää joukon laskutustietueita, joiden pituudet myös vaihtelevat. Seuraavat kohdat ovat kuitenkin kiinnitettyjä: 20 * Keskustiedoston maksimikoko 1 megatavua * APDUrn maksimikoko 512 tavua * Laskutustietueen maksimikoko 70 tavua.

DDC:n otsikko- ja jälkiosa-APDU:t ovat identtiset lukuunottamatta APDU-tyyppiä, joka on 241 otsikko-APDU:lie 25 ja 245 jälkiosa-APDU:lie.

Seuraava informaatio on saatavana otsikko- ja jälkiosa-APDU: ssa: APDU-pituus.......... Otsikko/jälkiosa-APDU: n pituus APDU-tyyppi.......... 241 otsikolle, 245 jälkiosalle 30 Ainutkertainen tiedosto- : tunniste............. Katso alla DIRINDEX:iä koskeva kohta

Kohde NNI............ INCA-nauhatallennusaseman NNI

Sovellusryhmä........ INCA-datan = 14 sovellusryhmä 35 Oton nauhan/vaihtolevyn sekvenssinumero...... nauhan/vaihtolevyn sekvenssinumero . Lähtötiedoston sekvens- 110981 25 sinumero............. DDC-sekvenssinumero

Aikaleima (timestamp) DDC vastaanotti datan.. Päiväys ja Aika data vastaanotettu DDC:n toimesta 5 Osatiedosto-osoitin. . Osoittaa, onko tiedosto osatiedosto Poikkeusosoittimet... Osoittaa, mikä voisi olla vialla tiedostossa

Lukulukema.......... ilmoittaa, kuinka monta kertaa tämä tiedosto on luettu 10 Tiedostokoko........ tämän tiedoston koko tavuissa

Valitsemattomien APDU:iden lukema.... Väärän APDU-tyypin APDU:iden määrä

Valittu APDU-tyyppi.. INCA-datatyypin APDU-tyyppi APDU-lukema......... APDU:iden määrä tässä tiedostossa 15 Ensimmäinen sekvenssi- numero.............. Aloittava APDU-sekvenssinumero

Viimeinen sekvenssi- .

numero.............. Lopettava APDU-sekvenssinumero 20 Lukulukema esittää kuinka monta kertaa tämä tiedosto on tullut kiertokyselyksi DDC:stä nauhatallennusaseman 6 toimesta. Osatiedosto-osoitin osoittaa, vastaanotettiinko koko tiedosto DDC:n 5 toimesta onnistuneesti, vai puuttuiko tiedoston osia.

25 Poikkeusosoittimet ovat kaksi yksitavuista bittimaski- kenttää, jotka osoittavat mitkä tahansa virheet, jotka DDC 5 havaitsi ja jotka liittyvät tähän siirtoon.

Kaikkia edellä olevia kenttiä varten olevat kelvolliset arvot tulevat tehdyiksi kelvollisiksi tietokoneavusteisen 30 systeemityön (CASE) sovellusohjelmistossa, jota kuvataan alla viitaten "YRITYSJÄRJESTELMÄÄN (TAI LAATIKKOON)" 8.

Viitaten kuvaan 10, lyhyt kuvaus APDU-rakenteesta 51 sisältää APDU-otsikon 52, todelliset kyseessä olevat laskutustietueet 53 ja APDU-jälkiosan 54.

35 Laskutustietueiden 53 formaatti on standardityyppiä, ja "C"-rakenne voidaan suunnitella kuvaamaan (map) tarkoin : tuohon formaattiin.

110981 26

Kun data on kiertokyselty keskuksista 3 DDC:hen 5, osa datasta, joka on jokaisen data-APDU:n alussa, poistetaan DDC:n 5 toimesta. Tämä data edustaa DDC:tä 5 ja keskusta 3, eikä se ole merkityksellistä datana, joka syötetään loppukä-5 sittelyjärjestelmään.

Kun tiedosto kopioidaan asianmukaiseen hakemistoon DDC: n 5 toimesta siten, että se on tehty käytettäväksi nauhatallennusasemalle 6 kopioida käyttäen FTAM:aa, siitä tehdään merkintä luettelotiedostoon, jonka nimi on DIRINDEX.

10 DlRlNDEX-tiedostomerkintä kuljettaa seuraavaa dataa: i) aktiviteettimarkkeri (1 tavu), joka voi osoittaa a) ei-aktiivista merkintää b) tiedosto saatavilla siirtoa varten c) tiedostoa käytetään parhaillaan (esim. FTAM— 15 siirrossa) d) tiedosto siirretty onnistuneesti (ei vielä poistettu) ii) INCA-tiedostonimiformaatti iii) lähtöreititys, joka voi esittää 20 a) tiedosto saatavilla FTAM:aa varten b) vain magneettinauha iv) ainutkertainen tiedostotunniste sisältäen yksityiskohtia kuten luontiaika ja asiaan kuuluva keskus-NNI.

25 v) tiedostokoko tavuissa vi) APDU:iden määrä tiedostossa.

Katsotaan kohtaa ii), INCA-tiedostonimiformaattia, joka sisältää: vii) nauha tai lennusasema-NNI: n 30 viii) keskuksen NNI:n ja klusterinumeron ix) INCA-datan sovellusryhmä t x) keskustiedoston DDC-tiedostosekvenssi-numero.

35 4 (ii) DATARAKENTEIDEN KUVAUS KESKUSDATAAN

Nauhatallennusasema 6 kuvaa datan datarakenteisiin, joita käytetään yrityslaatikon 8 mallissa, käyttäen seuraa- 110981 27 via periaatteita: * On oletettu, että APDU-pituuskentät ja laskutus-tietuepituuskentät ovat oikeellisia. Jos ne eivät ole, kelvolliseksi tekeminen epäonnistuu joko APDU-tasolla tai 5 laskutustietuetasolla, ja tiedosto virtautetaan (will be streamed) data-analysaattoriin 7.

* Ottodata aluksi selataan (scanned), jotta löydetään otsikko-APDU 52. Tämä tunnistetaan APDU-tyypistä 241 (Hex F1 ). Valittu APDU-tyyppikenttä sitten tarkastetaan yhdessä 10 ainutkertaisen tiedostotunnisteen kanssa, jotta vahvistetaan, että tämä on todellakin otsikko-APDU 52.

* Sen jälkeen kun otsikko-APDU 52 on löydetty ja otsikko-APDU—datarakenne on kuvattu, oletetaan, että kaikki APDU:t tiedostossa noudattavat yhden sanan tietuepituuden, jota 15 seuraa APDU, formaattia, esimerkiksi /header_apdu/rl/apdu/rl/apdu. . . /RL/APDU/RL/TRAILER_APDU missä RL on tietuepituus (Record Length).

* Jos tiedoston rakenne poikkeaa tästä standardista, niin tiedosto virtautetaan data-analysaattoriin 7 jatkoanalyysiä 20 varten. Tämä virhetila havaitaan sen APDU:n, joka välittömästi seuraa poikkeamaa, kelvolliseksi tekemisessä.

* Jokaisessa APDU:ssa on oletettu, että rakenne seuraa kuvassa 6 esitettyä rakennetta. Jälleen mikä hyvänsä poikkeama tästä rakenteesta aiheuttaa sen, että koko . 25 datarakenteen kuvaus tulee väärin järjestetyksi (mis aligned), ja johtaa tiedoston hylkäämiseen ja virtauttami-seen data-analysaattoriin 7.

* On oletettu, ettei jälkiosa-APDU:n 54 jälkeen ole mitään dataa. Mikä tahansa data, joka tulee esiin jälkiosa- 30 APDU:n jälkeen, menetetään.

5. KUVAT 11-19 JA 22-30: NAUHATALLENNUSASEMA- JA DATA-ANALYSAATTORIPROSESSIT

5 (i) NAUHATALLENNUSASEMA: DDC-KIERTOKYSELYPROSESSI

35 Kun DDC:t 5 vastaanottavat tiedostot, ne tehdään kelvollisiksi (käyttäen tarkistussummausta) ja tiedoston alkuun ja loppuun lisätään hieman ylimääräistä informaatiota 110981 28 APDU-otsikkoon ja -jälkiosaan 52,54, kuten edellä on todettu viitaten kuvaan 2. Sitten nämä tiedostot tehdään saataviksi nauhatallennusaseman 6 suorittamaa kiertokyselyä varten sijoittamalla ne nauhatallennusaseman 6 käyttämäksi tulevaan 5 hakemistorakenteeseen ja päivittämällä DIRINDEX-tiedosto.

Tämä DIRINDEX-tiedosto sisältää listan kaikista tiedostoista, jotka ovat saatavilla nauhatallennusaseman 6 kiertoky-seltäviksi, ja nauhatallennusasema 6 käyttää tätä listaa varmistaakseen, että se on kiertokysellyt kaikki uudet 10 tiedostot.

Viitaten kuvaan 11, nauhatallennusasema 6 valmistautuu kiertokyselemään monet DDC:t 5 menemällä "virtauta kaikki DDC:t"—prosessiin ("Stream all DDCs" process). Askeleessa 700 nauhatallennusaseman 6 "virtauta kaikki DDC:t"-prosessi 15 liipaistaan esimerkiksi määrättynä ajanhetkenä. Askeleessa 710 se ajaa tarkastuksen, että nauhatallennusasema 6 on käytettävissä vastaanottamaan tiedostoja DDC:eistä 5. Jos nauhatallennusasema 6 on käytettävissä, se menee sykliin, askeleet 720, 730 ja 740, jossa se ajaa läpi DDCreiden 5 20 listan ja luo "DCC-prosessin" jokaista kiertokyseltävää DDC:tä 5 varten. Listan lopussa tämä prosessi loppuu (askel 750) .

Jokaista DDCrtä 5 varten nauhatallennusasema 6 ajaa nyt "DCC-prosessin". Viitaten kuvaan 12, askelissa 800, 805 DCC-25 prosessi alkaa tarkastamalla, onko joko tuohon prosessiin liittyvä DCC 5 tai nauhatallennusasema 6 sammutettuna, ja tarkastaa askeleessa 810, kuuluuko DDC-kiertokysely asiaan.

On tiettyjä aikoja, joina DDC:eitä 5 ei voida kiertokysellä, ja askel 815 ajaa tarkastuksen, onko ei-kiertokyselyä-ikkuna 30 voimassa. Jos ei ole, askel 820 etsii vapaata prosessiväliä : tiedostojen käsittelemiseksi. Mikäli kaikki nämä tarkastuk set läpäistään, nauhatallennusasema 6 menee sisään (accesses) DDC-DIRINDEX:iin, askel 825, ja käynnistää prosessilis— tan, askel 830, ja tiedostolistan, askel 835, jotka varmis-35 tavat, että nauhatallennusasema 6 käyttää kaikkia asiaan kuuluvia prosesseja jokaiseen DDC:stä 5 vastaanotettuun , keskustiedostoon. Askeleessa 840, 845 ja 850 nauhatallen- 110981 29 nusasema 6 ajaa läpi tiedostojen DDC—DIRINDEX:stä luoden oman käsiteltävien keskustiedostojen lokin (log), ja saa aikaan tiedostonkäsittelykapasiteetin, askeleet 855 ja 860, käsitelläkseen tiedostolistassa olevat tiedostot. Kun kaikki 5 keskustiedostot DDC-DIRINDEX:stä ovat saaneet käsittelyka-pasiteetin varatuksi, "DDC-prosessi" päivittää tietueensa, koska seuraava kiertokysely on tapahtuva, askel 865, ja menee takaisin uneen, askel 870.

DDC-prosessi tietenkin pysäytetään, askel 875, mikäli 10 joko DDC 5 tai nauhatallennusasema 6 on sammunut, ja se pysyy uni-moodissa, askel 870, aina kun kiertokysely ei ole asiaan kuuluva, kun DDC on ei-kiertokyselyä-ikkunassa tai käsittelykapasiteettia ei ole käytettävissä. tyypillinen tapahtumasvkli ddc-kiertokvselvarkkitehtuurissa 15 Otaksutaan seuraavaa DDC_POLLING_MPH =17 ... Tämä on minuutit yli tunnin kiertokyselyyn DDC_P0LLING__INT__HRS = 1 ... Tämä on kuinka kauan on odo tettava seuraavaan kiertoky-20 selyyn tunneissa DDC_DELAY_IN_DELETE = 12 ... kuinka kauan odotetaan sen jälkeen, kun tiedosto on merkitty poistettavaksi, ennen kuin todellinen pois- 25 tamispyyntö tapahtuu.

Järjestelmä on käynnistetty kello 23: 30 edellisenä päivänä. Aikataulu 00: 17 DDC-prosessi herää, kopioi DIRINDEX-tiedoston päälle ja luo prosessit virtauttaa dataa nauhatal-30 lennusasemaan 6.

00: 30 DDC-prosessi lopettaa prosessien luomisen tiedos tojen virtauttamiseksi, koska joko maksimimäärä prosesseja on luotu TAI kaikki käytettävissä olevat tiedostot on annettu tiedostoprosesseille 35 tiedoston poimintaan (to download).

Herätysaika lasketaan 00: 30 + DDC_POLLING_INT_HRS ja aseta minuutit 110981 30 DDC_POLLING_MPH:hon.

=> Seuraava kiertokyselyaika = 00:30 + 1: 00 = 1: 30 (aseta MPH) = 1 : 17

Laske sekuntien määrä olla unessa = 5 TO_SECONDS (01: 17 - CURRENT_TIME)

Ole unessa (seconds_to_sleep) .. .Tiedostoprosessit saavat valmiiksi datan virtautuksen 01: 17 DDC-prosessi herää...

10

5 (ii) NAUHATALLENNUSASEMA: TIEDOSTOPROSESSI

viitaten kuvaan 13, tiedostoprosessin, joka luotiin DDC-prosessin aikana askeleessa 855, toiminta on seuraavanlainen. Tiedostoprosessi työskentelee tiedostolistasta, joka 15 on vastaanotettu DDC-prosessista, askel 1302. Ajaen läpi tiedostolistan, askel 1303, jokaista listattua keskustiedos-toa varten tiedostoprosessi lukee keskustiedostolokin, askel 1305, tekee kelvollisiksi puhelutietueet, askel 1306, kopioi tiedoston raakatietuevarmistukseen, askel 1307, käytettäväk-20 si, jos esimerkiksi nauhatallennusasema 6 putoaa pois toiminnasta myöhemmin, suuntaa tiedoston data-analysaattorille 7, jos kelvolliseksi tekeminen epäonnistuu, askel 1310, tai virtauttaa tiedoston yrityslaatikkoon 8, askel 1312.

25 Tiedostoprosessi pysähtyy, askel 1313, jos DDC 5 tai nauhatallennusasema 6 sammutetaan, askel 1314, tai jos tiedostot ovat vakavasti vääristyneet, askel 1311, esimerkiksi siksi, että tietoliikenne DDC:n 5 kanssa on epäonnistunut. Keskustiedostoloki monitoroi, minkä vaiheen keskus-30 tiedosto on saavuttanut suhteessa nauhatallennusasemaan 6, * ja kantaa (carry) tilaa (status) jokaiselle tiedostolle, tilan ollessa valittu vaihtoehdoista aktiivinen, käsitelty ja poistettu, missä "aktiivinen" osoittaa, että nauhatallennusasema 6 käsittelee sitä, "käsitelty" osoittaa, että se on 35 käsitelty nauhatallennusaseman 6 toimesta, ja "poistettu" tarkoittaa, että se on poistettu DDC:stä 5 nauhatallen-, nusaseman 6 toimesta.

110981 31

Viitaten kuvaan 14, askelta 1306, jossa puhelutietueet tehdään kelvollisiksi, voidaan laajentaa seuraavasti. Tässä pisteessä, askeleet 1401 ja 1402, keskustiedosto kopioidaan DDC:stä 5 ja tiedosto-otsikko ja ensimmäinen APDU-otsikko 52 5 tehdään kelvollisiksi, askeleet 1403, 1405. Jos jompi kumpi epäonnistuu, luodaan tiedostovirheloki, askel 1412. Jos molemmat ovat hyväksyttäviä, puhelutietueista jokainen tehdään kelvolliseksi, askeleet 1407, 1408, ja jos joku epäonnistuu, luodaan puhelutietuevirheloki askeleessa 1409.

10 Kelvolliseksi tekeminen toistetaan jokaista APDUrta 51 varten. Näyttääpä kelvolliseksi tekeminen sitten sitä, että kaikki on oikein, tai että virheitä on merkitty, niin joka tapauksessa jäijitysketju päivitetään 1413 ja tiedosto-prosessi siirtyy askeleeseen 1307, kuten edellä on kuvattu.

15 Viitaten kuvaan 15, tiedostot, jotka on tehty kelvolli siksi tiedostoprosessin aikana, ovat nyt valmiita menemään yrityslaatikkoon 8. Tässä vaiheessa tiedostorakenteet hajotetaan osiin siten, että yksittäiset puhelutietueet 53 voidaan luokitella sen laskutettavan entiteetin, jolle ne 20 ovat merkityksellisiä, mukaan. Puhelutietueet 53 kirjoitetaan nyt fyysisiin tiedostoihin, askel 1503, eri laskutettavia entiteettejä varten.

5 ( iii ) DDC-TIEDOSTON POISTAMISPROSESSI . 25 Kun datatiedosto on onnistuneesti poimittu (downloaded) ‘ DDC:stä 5 nauhatallennusasemaan 6, ja data on laajennettu ja virtautettu asianmukaiseen yrityslaatikkoon 8, datatiedosto täytyy poistaa DDC:n FTAM-tiedostovarastosta. Nauhatallen-nusasema 6 poistaa tiedoston käyttäen FTAM-poistopyyntöä 30 tietyn tuntimäärän jälkeen siitä, kun tiedosto on varmistettu joko yrityslaatikkoon 8 (tai paikalliseen yrityslaatikkoa 8 varten olevaan varastoon, jos linkki yrityslaatikkoon 8 on pudonnut toiminnasta). Tarkka aika, joka on datan varmistuksen ja tiedostojen poistamisen välillä, voidaan asettaa DDC-35 kohtaisesti (per DCC basis).

110981 32

5 (iv) DATA-ANALYSAATTORI: PROSESSI

Viitaten kuvaan 16, puhelutietueiden kelvolliseksi tekemisen askel tiedostoprosessissa, askel 1 306 kuvassa 13, synnyttää tiedostovirhelokin, askel 1412, ja puhelu-5 tietuevirhelokin, askel 1409. Data-analysaattori 7 ajaa kahta prosessia, "DA-PROSESSIA" ja "PIDÄTYSTIEDOSTO-PROSES-SIA" (SUSPENSE FILE PROCESS), jotka käynnistetään HP9000:n käynnistyssekvenssin aikana.

DA-PROSESSI monitoroi jatkuvasti, onko dataa, jonka 10 nauhatallennusasema 6 on lähettänyt, saatavilla data-analysaattorin 7 käsiteltäväksi. Tämä data tulee aina olemaan olemassa aluksi alkuperäisenä keskustiedostona riippumatta siitä, sisälsikö data yksittäisiä puhelutietuei-ta, joita ei voi virtauttaa, vai oliko vika tiedostotasolla.

15 Niin kauan kuin data-analysaattoria 7 ei ole liputettu sammutetuksi, askel 1602, DA-PROSESSI poimii ensimmäiseksi aikaisimman tiedostovirhelokin käsiteltäväksi, askel 1603, ja tarkastaa, onko vika tiedosto/APDU- vai puhelu-tietuetasolla, askel 1604.

20 Viitaten kuviin 16, 17 ja 20, jos vika oli puhelu- tietuetasolla, DA-PROSESSI poimii seuraavan tiedostoa koskevan puhelutietuevirhelokin, askel 1702, ja lähettää asiaan kuuluvan puhelutietueen ART IM-sääntökantaan korjattavaksi, askel 2000. Jos vika oli tiedostotasolla, koko . 25 keskustiedosto on tullut nauhatallennusaseman 6 hylkäämäksi.

* ·· Tässä tapauksessa koko tiedosto ladataan muistiin, askel 1606, ja tiedosto-otsikko ja APDU:t 51 lähetetään ART IM:iin korjattavaksi, askel 1607.

Data-analysaattorin 7 tekemällä analyysillä on useita 30 seurauksia. Korjattava data lähetetään ART IM:iin korjatta-. vaksi ja myöhemmin voidaan tehdä kelvolliseksi ja virtauttaa yrityslaatikkoon 8. Jos asiaan liittyy reititysvirhe, data voidaan laittaa pidätykseen (suspense) tapauksessa, jossa reititysinformaation tietueessa on ongelma jossakin päin 35 järjestelmää esimerkiksi siksi, että se tarvitsee päivitystä. Loppujen lopuksi voi olla mahdollista tehdä data kelvolliseksi, kun reititysinformaatio on korjattu. Jos koko 110981 33 tiedosto on ei-luettava, se on ehkä lähetettävä, edelleen binaariformaatissa, binaaritiedostoroskavarastoon (Binary File Dump). Jos data, esimerkiksi tiedosto, on ART IM:n määrittämänä korjauskelvoton, ja virhe ei liity reititykseen 5 pidätyksen oikeuttamiseksi, se voidaan arkistoida. Dataa ei koskaan laskuteta, mutta sitä voidaan käyttää analyysissä, jotta tunnistetaan pitkän aikavälin tai merkittävät ongelmat, jotka itsessään voidaan korjata ja siten välttää laskutettavien kohtien menettäminen tulevaisuudessa.

10 Palaten kuvaan 16, käytettyään ART IM: aa ajamaan tarkastukset askeleissa 1605 ja 1607 pää-DA-PROSESSI seuraavaksi luokittelee tiedostot, jotka on palautettu ART IM:sta korjauskelvottornina. Jos niitä ei voida edes lukea, askel 1608, ne johdetaan binaaritiedostoroskavarastoon. Nämä 15 tiedostot voidaan mahdollisesti lukea, koska ne voivat olla heksadesimaali-, oktaali- tai ASCII-formaatissa ja niitä voidaan käyttää myöhemmin analyysiin. Vaihtoehtoisesti tiedostot voivat olla luettavia data-analysaattorin toimesta, mutta ne on silti luokiteltu "korjauskelvottomiksi" ART 20 IM:n toimesta. Nämä ladataan, askeleessa 1609, "kuoppa"-tietokantaan, missä jälleen ne eivät koskaan tuota laskutettavaa dataa, mutta niitä voidaan kysellä ja analysoida.

Jos tiedosto on lähetetty ART IM:iin ja se oli korjattavissa, ART IM palauttaa jokaisen puhelutietueen peräkkäi-25 sesti kelvolliseksi tekemistä varten, askeleet 1610 ja 1611. Tämän jälkeen DA-PROSESSI tekee nämä puhelutietueet kelvollisiksi tarkastamalla ensin, onko reititysvikaa, askel 1612, ja luomalla puhelutietuevirhelokin, askel 1615, tapauksessa, että puhelutietuevirhe on olemassa. Nämä poimitaan ja 30 ajetaan uudelleen ART IM:n läpi, askeleet 1603-1605 ja 1701 — 1703. Jos puhelutietue on hyväksyttävä, se virtautetaan yrityslaatikkoon 8 askelien 1616-1618 kautta.

Nyt viitataan kuvaan 18, missä on ollut puhelu-tietuereititysvika, joka on havaittu askeleessa 1612, 1704 35 tai 1907 (katso alla), ja missä puhelutietueet kategorioidaan ja pidätetään. Tämä tarkoittaa, että vika analysoidaan siinä laajuudessa, että se voidaan sovittaa olemassa olevaan 34 110981 reititysvirhemalliin, askel 1802, ja sitten puhelutietue lisätään olemassa olevan mallin tiedostoon, joka sisältää kaikki puhelutietueet, joissa ilmenee sama reititysvirhemal-li, askel 1803. Näitä mallitiedostoja pidetään pidätyksessä, 5 ja pääasialliselle BT PSTN-verkkohallinnolle ja datakeskuk-selle tehdään ilmoitus. Erillinen prosessi, PIDÄTYSTIEDOS-TOPROSESSI, sitten käsittelee nämä tiedostot.

PIDÄTYSTIEDOSTOPROSESSI on data-analysaattorin tärkeä aspekti, koska se ottaa virheelliseksi todettujen tiedosto-10 jen, jotka voidaan mahdollisesti korjata, kategorian ulos datakäsittelyn "päävirrasta". Nämä tiedostot ovat saattaneet tulla poimituksi virheellisiksi vain siksi, että reititysda-taa jossakin päin järjestelmää ei ole päivitetty. Ne ovat mahdollisesti laskutettavia. PIDÄTYSTIEDOSTO-PROSESSIN 15 avulla pääasiallisella verkkohallinnolla ja datakeskuksella on mahdollisuus päivittää reititysdata järjestelmässä ja yhä saada kiinni tiedostot, joita pidettiin aikaisemmin virheellisinä. Lisäksi, kun liitetään puhelutietueet olemassa olevan mallin tiedostoon, erityistä reittimallia varten 20 olevat "reittimallipidätystiedosto"-tiedostot voidaan valita kelvolliseksi tekemisen uudelleen yrittämiseksi yksinkertaisesti ajamalla valittu reittimallipidätystiedosto.

Viitaten kuvaan 19, niin kauan kuin prosessia ei ole sammutettu, askel 1902, PIDÄTYSTIEDOSTOPROSESSI aloittaa .. 25 paikallistamalla aikaisimman reititysmallin, joka on korjattu esimerkiksi verkkohallinnon ja datakeskuksen toimesta, askel 1903. Sitten se poimii seuraavan pidätetyn tiedoston, joka sisältää tuon reititysmallin, askel 1904, ja yrittää tehdä puhelutietueet kelvollisiksi, askeleet 1905 ja 30 1906. Puhelutietueessa voi tietenkin olla useampi kuin yksi reititysvirhe. Mikäli näin on, PIDÄTYSTIEDOSTOPROSESSI palaa kuvan 18 askeleeseen 1801 ja luo reititysvirhemerkinnän reititysvirhemallitiedostoon täten pidättäen uudelleen puhelutietueen. Toisaalta jos muita reititysvikoja ei ole, 35 PIDÄTYSTIEDOSTOPROSESSI yrittää virtauttaa puhelutietueen yrityslaatikkoon 8 palaamalla kuvan 15 askeleeseen 1501. PROSESSI ajaa läpi kaikki pidätetyssä tiedostossa olevat 110981 35 puhelutietueet tällä tavalla, askel 1910, ja kaikki tiedostot, jotka on pidätetty liittyen tuohon erityiseen reitti-malliin, askel 1911.

Viitataan kuvaan 22, joka esittää prosessivuorovaiku-5 tuksia nauhatallennusasemajärjestelmän 6, yrityslaatikon 8 ja data-analysaattorin 7 välillä. Nauhatallennusaseman 6 pääprosessialuetta on se, jota nimitetään nimellä "TIEDOSTO-PROSESSI". Tämä tekee kaikki kelvolliseksi tekemiset ja sisäiset operaatiot tiedostolle. Data-analysaattorialueella 10 on "IDA TIEDOSTOPROSESSI", joka syöttää dataa asiantuntijajärjestelmään. Tärkeästi tämä prosessi liipaisee reittimal-lipidätystiedoston ja "PIDÄTYSTIEDOSTOPROSESSI" : n liittämällä datan reittimallipidätystiedostoon. Tämä välttää datan jälkeenjäämisen (backlog of data) suuren keräytymisen, koska 15 PIDÄTYSTIEDOSTOPROSESSI toimii pää-IDA TIEDOSTOPROSESSIN ulkopuolella. Toinen kiinnostava alue on "KUOPPATIETOKANTA", joka vastaanottaa ulostuloa "KUOPPALATAAJASTA". Vaikka KUOPPATIETOKANNASSA olevaa dataa ei voida tehdä oikeellisek-si, sitä voidaan kysyä ja analysoida siten, että IDA 20 TIEDOSTOPROSESSISSA olevia sääntöjä voidaan mahdollisesti muuttaa siten, että myöhäisempi data voidaan virtauttaa uudelleen.

Kuvassa 22 prosessit on esitetty ympyröinä, yrityslaa-tikko 8 laatikkona, datatiedostot, lokit ja vastaavat on 25 esitetty avopäätyisten samansuuntaisten viivojen välissä, ja arkistoitu data on esitetty tavanomaisilla tietokantoja tarkoittavilla symboleilla.

Prosessi- ja varastoidun datan vuorovaikutukset, jotka on merkitty kirjaimin (a):sta (y):hyn kuvassa 22, voidaan 30 listata seuraavasti nuolenpäiden osoittaessa asiaan kuuluvat siirtosuunnat: (a) NNI ja käsiteltävien, siirrettävien tiedostonimien lista (b) Keskustiedostoloki, STATUS = A, luotu 35 (c) DIRINDEX-tiedostoon menty sisään (accessed) (d) FTAM-keskustiedosto kopioitu (e) FTAM-keskustiedosto poistettu 36 110981 (f) Keskustiedostot, joissa STATUS = P, luettu (g) STATUS asetettu D:ksi, jos keskustiedostot poistettu onnistuneesti (kohdassa (e) edellä) h) keskustiedostoloki luettu, missä STATUS = A 5 i) keskustiedostolokidata päivitetty. STATUS asetettu P:ksi j) tiedosto on virheessä, joten tiedostovirheloki luodaan k) puhelutietue on virheessä, joten puhelutietuevirheloki luodaan 10 1) tiedosto kopioidaan data-analysaattorihakemistoon, jos tiedosto on virheessä m) tiedostovirheloki luettu n) puhelutietuevirheloki luettu o) raaka(binaari)datatiedosto etsitty (looked up) 15 p) data liitetty reittimallipidätystiedostoon tätä reitti-mallia varten q) merkintä tehty reittivirhemalliin r) ART/IM luonut lähimmät vastaavuudet (matches) s) ART/IM on tunnistanut, ettei tätä dataa voi korjata.

20 Data sijoitetaan KUOPPAAN jatkoanalyysiä tai poistoa varten t) käyttäjä on tunnistanut, ettei ongelmaa voi korjata. Tiedosto sijoitetaan kuoppaan jatkoanalyysiä tai poistoa varten 25 u) kun tiedostorakenne käsittämätön, tiedosto heitetään ; binaaritiedostoroskavarastoihin v) virtautettu tiedosto luotu w) PIDATYSTIEDOSTOPROSESSI käynnistetään reittivirhemal-lilla olevalla tilalla, joka on asetettu tilaan valmis.

. 30 Jos ongelmat jatkuvat, niin Lukemakenttä päivitetään ja tila asetetaan PIDÄTETTY-tilaan x) lähimmät vastaavuudet päivitetään, jos valittu ratkaisu ei onnistu korjaamaan ongelmaa y) virtautettu tiedosto luotu

5 (v) ENTITEETIN ELÄMÄNHISTORIAT

Viitaten kuviin 23-30, entiteetin elämänhistoriakaaviot 35 110981 37 voivat esittää tiloja (statuses), joissa tietue tuon entiteetin sisällä voi olla, ja mitä muita tiloja milläkin toiminnolla voidaan saavuttaa tuosta tilasta. Jokaisessa näistä kuvista tilat on yksinkertaisesti identifioitu 5 viitenumerolla 2300, ja tilojen määritelmät on annettu alla.

Kuva 23: tiedostovirheloki; VALMIS - tiedosto on valmis virtautettavaksi data- analysaattorin 7 toimesta.

10 PIDÄTYS - joko koko tiedosto tai vähintään yksi pu- helutietue tiedostossa on lähetetty pidä-tysalueelle BIN - data-analysaattori 7 ei pysty lukemaan tie dostoa, ja se on lähetetty bin-alueelle.

15 KUOPPA - koko tiedosto on lähetetty kuoppa-alueelle.

SUORITETTU - data-analysaattori 7 on virtauttanut tiedoston ja mitkä hyvänsä tiedoston puhelutietueet pidätysalueella on onnistuneesti virtautettu uudelleen tai arkistoitu.

20

Kuva 24: Puhelutietuevirheloki; VALMIS - puhelutietue on valmis virtautettavaksi data- analysaattorin 7 toimesta.

PIDÄTYS - puhelutietue on lähetetty pidätysalueelle.

25 KUOPPA - puhelutietue on lähetetty kuoppa-alueelle.

ARKISTOITU - puhelutietue on lähetetty jätealueelle (eli arkistoitu).

SUORITETTU - data-analysaattori 7 on virtauttanut puhelu-tietueen onnistuneesti.

30 KELV_VIKA - ART—IM:n ja IEF:n kelvolliseksi tekevien pro seduurien välillä on eroavaisuuksia.

• · *

Kuva 25: reittivirhemalli; VALITSEMATON - ART-IM:n luoma ja odottaa data-analysaattori- 35 käyttäjältä analyysiä, tai virtautettu uudel leen analyysin jälkeen mutta epäonnistunut.

KÄYNNISSÄ OLEVA - data-analysaattorikäyttäjän valitsema 110981 38 analyysiä varten VALMIS - data-analysaattorikäyttäjä suorittanut ana lyysin ja on valmis virtautettavaksi uudelleen.

5 SULJETTU - onnistuneesti virtautettu uudelleen tai arkistoitu.

Kuva 26: Lähimmät vastaavuudet; VALITSEMATON (TAI NOLLA) - ART-IM:n tuottama.

10 VALITTU - data-analysaattorikäyttä jän valitsema analyysiä varten.

Kuva 27: Kuoppatiedostoloki; KUOPPA - tiedosto on valmis KUOPPA_PROSESSIA varten 15 KÄSITTELEE - tiedosto on valmis data-analysaattorikäyt tä jän tutkittavaksi.

ARKISTOITU - tiedosto on arkistoitu.

Kuva 28: tiedostoreittivirhelinkki; 20 PIDÄTETTY - tiedosto on pidätysalueella.

SUORITETTU - tiedosto on onnistuneesti virtautettu uudelleen pidätysalueelta.

Kuva 29: keskustiedostoloki; * 25 A(KTIIVINEN) - nauhatallennusasema käsittelee keskustiedos- toa.

K(ASITELTY) - nauhatallennusasema on käsitellyt keskustie-doston.

P(OISTETTU) - nauhatallennusasema on poistanut keskustie-30 doston.

Kuva 30: aluedatakerääjä; (Kaikki tilat muutetaan nauhatallennusaseman 6 käyttäjien toimesta SQL1Forms:n kautta.) 35 P(REBIS) - DDC on prebis (prebis).

E(LOSSA) - DDC on elossa.

L(OPETETTU) - DDC on lopetettu.

110981 39

Viitaten kuvaan 6, voidaan nähdä, että nauhatallen-nusaseman 6/data-analysaattorin 7 ohjelmistoarkkitehtuuriin sisältyy IEF ulkoiset toimintalohkot (EAB: t) 62. EAB:eita 62 käytetään siellä, missä ei ole sopivaa tai mahdollista 5 toimia (implement) IEF:n sisällä. Esimerkiksi seuraavat toiminnot voidaan suorittaa EAB teiden 62 keinoin: * "Lisää puhelutietue pidätykseen" Tämä moduuli luo uuden merkinnän puhelutietueesta 10 linkitetyssä listassa, joka sisältää keskustiedoston puhelutietueet, jotka tullaan lähettämään pidätystiedostoon.

* "Lisää puhelutietue arkistoon"

Luo arkistohakemistoon uuden merkinnän puhelutietueesta 15 linkitetyssä listassa, joka sisältää keskustiedoston puhelutietueet, jotka on korjattu, mutta joita ei voida virtauttaa uudelleen. ' 1 "Lisää verkko-operaattoritietue" 20 Tarkistaa, onko tämä uusi verkko-operaattori ja mikäli on, niin luo uuden merkinnän "verkko__operaattori_rakenne" -listaan. Mikäli se on jo käytetty verkko-operaattorinimi, se lisää linkitetyn listamerkinnän tuon verkko-operaattorin puhelutietueiden linkitettyyn listaan. Siellä missä puhelu-’ 25 tietue on korjattu, se päivittää "puhelu_tietue_virhe_lokin" "verkko—operaattoritietue"-identiteetin ja virtautetun puhelutietuesekvenssinumeron kanssa.

* "Puhelutietue IDA-sääntöihin"

Ohjaa yksittäisen puhelutietueen data-analysaattorin 30 ART-lM-sääntökantaan. Puhelutietue tunnistetaan APDU-sekvenssinumerolla ja puhelutietuesekvenssinumerolla, jotka IEF on päästänyt sisään (passed in). Muistiin ladatusta datarakenteesta sitten etsitään puhelutietuetta ja omistavaa APDU:ta ja keskustiedosto-otsikkodataa. Tämä data syötetään 35 sitten sääntökantaan ja tehdään kelvolliseksi. Mistä tahansa virheistä, jotka löydetään, jokainen synnyttää puhelu-tie tuesääntölokirivimerkinnän .Puhelut ie tuevirheloki tietueen 110981 40 tila tulee myös päivitetyksi sääntökannan toimesta.

* "Tee"

Tekee kaikki tämänhetkiset tietokantamuutokset.

* "Luo DDC-prosessi" 5 Luo DDC-prosessin esiintymisen, joka on vastuussa erityisen DDC:n kiertokyselemisestä. Se luo/avaa fifo:n (tiedosto sisään/tiedosto ulos, file in/file out) lapsi-prosessiin ja kirjoittaa fifo:oon DDC_NNI:n arvon.

* "Luo tiedostoprosessi" 10 Luo prosessin, joka suorittaa tiedostonimien ryhmään (array) siirrettyjen tiedostonimien virtautustehtävän.

* "Poista tiedosto DDCrstä"

Poistaa tiedoston käyttäen FTAM-protokollaa DDCrllä olevalta levyltä.

15 * "Poista data-analysaattoritiedosto"

Poistaa tiedoston nauhatallennusasema/data-analysaatto-rihakemistosta.

* "Poista pidätystiedosto"

Poistaa tiedoston pidätystiedostohakemistosta.

20 * "Tiedosto bin:iin"

Siirtää tiedoston, jota ei voida lukea ART-IM-sääntö-kantaan, binaaritiedostoroskavarastoon.

* "Tiedosto data-analysaattorisääntöihin"

Siirtää koko tiedoston data-analysaattorin ART—IM-25 sääntökantaan ja käynnistää sääntökannan. Sääntökannan käynnistämiseen kuuluu vanhan datan poistaminen, oletus-(default) ja reititysreferenssidatan valitseminen ja tietokannan miehittäminen tällä datalla. Tämän jälkeen data-analysaattoribinaaritiedosto ladataan datarakenteeseen 30 muistissa. Sitten tämä data syötetään sääntökantaan ja tehdään kelvolliseksi. Mikä tahansa virhe, joka havaitaan, synnyttää asiaankuuluvan sääntölokirivimerkinnän. Puhelu-tietuevirhelokit luodaan sääntökannan toimesta, missä se on asiaankuuluvaa, yhdessä reittivirhemallin, lähimpien 35 vastaavuuksien ja tiedostoreittivirhelinkkitietueiden kanssa. Kun on tehty kelvolliseksi, sääntökanta palauttaa kelvolliseksitekemistilan IEF:lle ja pitää sisäiset datansa 41 110981 - myöhempää esille saattamista varten.

* "Tiedosto kuoppaan"

Siirtää tiedoston, jota ei voida korjata ART—IM— sääntökannan toimesta, kuoppaan.

5 * "FTAM HLKOPIO"

Kopioi käyttäen FTAM-protokollaa DDC-tiedostonimen DDC— FTAM—osoitteesta käyttäen DDC-käyttäjänimeä, DDC-tunnussanaa ja DDC-lukemaa nauhatallennusasemalle 6. Nauhatallen-nusaseman 6 käyttäjänimi, tunnussana, lukema ja FTAM-osoite 10 voidaan tarvittaessa oletusarvoistaa (defaulted) NOLLAAN. Tätä rutiinia ei kutsuta suoraan IEFrstä, ja siten se ei palauta IEF-tyylistä tilaa.

* "Hae DDC-prosessiparametrit"

Luo tai avaa fifo:n nauhatallennusasema/TMP-hakemistos-15 sa, joka nimetään "DDC_process_fifo < PID >":ksi. Se lukee DDC NNI:n arvot fifosta datan ollessa tullut pannuksi sisään fifoon "create_file_process"-rutiinin toimesta.

* "Hae tiedostoprosessiparametrit"

Luo tai avaa fifo:n nauhatallennusasema/TMP-hakemistos-20 sa, joka nimetään "file_process_fifo_< PID >":ksi. Se lukee edellä olevien muuttujien arvot fifosta datan ollessa tullut pannuksi sisään fifoon "create_file_process"-rutiinin toimesta.

* "Hae keskustiedosto" « 25 Kopioi tiedoston käyttäen FTAM-protokollaa DDC:llä olevasta levystä suoraan nauhatallennusasemalla 6 olevaan levyyn. Sitten tiedosto luetaan nauhatallennusasemalla olevaan muistiin ja sitten se nimetään uudelleen raaka-tietuevarmuushakemistoon, josta se arkistoidaan. Tämä 30 moduuli kutsuu "map_data_structure_to_file":a (ku-• vaa_data_rakenne_tiedostoon), jotta asetetaan alkuosoittimet (initial pointers) ensimmäiseen laskutettavaan tietueeseen, ensimmäiseen APDUihun ja otsikko- ja jälkiosa-APDU:hun.

* "Hae ei-kelvollisten data-analysaattori-APDU: iden määrä" 35 Palauttaa ei-kelvollisten APDU:iden, jotka uudelleenkä- sittelevät puhelutietueita, jotka eivät ole läpäisseet nauhatallennusasemankelvolliseksitekemisprosessia, lukeman.

110981 42 * "Kuvaa data-analysaattoritiedosto"

Lukee tiedoston muistiin myöhempää käsittelyä varten.

* "Prosessi aktiivinen"

Toteaa, onko tietty PID aktiivinen ja palauttaa lipun 5 sen mukaisesti.

* "Lue keskustiedosto-otsikko" Käyttää osoittimia otsikko- ja jälkiosa-APDUrhun palauttamaan rakenteessa kaikki kentät otsikosta ja APDU-tyypin jälkiosasta.

10 * "Lue data-analysaattorikeskustiedosto-otsikko" Käyttää osoittimia otsikko- ja jälkiosa-APDU:hun palauttamaan rakenteessa kaikki kentät tiedoston, joka on lähetetty data-analysaattoriin, otsikosta ja APDU-tyypin jälkiosasta.

15 * "Lue ensimmäinen DIRINDEX-tiedosto"

Kopioi käyttäen FTAM-protokollaa DlRINDEX-tiedoston DDC:stä väliaikaiseen varastoon ja avaa tiedoston ja palauttaa ensimmäisen tietueen soittajalle.

* "Lue seuraava APDU" 20 Palauttaa APDU-rakenteen, johon nykyinen APDU-osoitin osoittaa, ja asettaa nykyisen APDU-osoittimen seuraavaan APDUrhun. Lisäksi asettaa nykyisen laskutustietueosoittimen ensimmäiseen laskutustietueeseen palautetussa APDU:ssa ja kopioi ja tavupäinvastaiskääntää (byte reverses) datan ! 25 nykyiseen APDU-ryhmään (APDU-array).

* "Lue seuraavat DIRINDEX-tietueet"

Lukee seuraavan tietueen DDC:llä olevasta DIRINDEX-tiedostosta.

* "Lue seuraava data-analysaattoritietue" 30 Palauttaa seuraavan laskutettavan tietueulostulon ART- IM-sääntökannasta. Onnistuneesti käsitellyt tietueet « ilmestyvät ensin, joita seuraavat ne, jotka vaativat lähettämistä pidätystiedostoon.

* "Lue seuraava pidätystietue" 35 Palauttaa seuraavan laskutustietueulostulon pidätystie- dostosta.

* "Lue seuraava tietue" 110981 43

Palauttaa laskutustietueen, johon nykyinen laskutus-tietueosoitin tällä hetkellä osoittaa, ja asettaa osoittiraen seuraavaan laskutustietueeseen, mikäli tämä tietue ei ole viimeinen nykyisessä APDU:ssa. (Tämä määritetään käyttäen 5 APDU-pituutta ja laskutustietueen minimipituutta.) * "Uudelleennimeä verkko-operaattoritiedostot"

Nimeää uudelleen mitkä hyvänsä verkko-operaattoritiedostot, jotka on kirjoitettu väliaikaiseen hakemistoon toiminnallisessa hakemistossa, joka on valmis käsiteltäväksi 10 yrityslaatikon 8 toimesta.

* "Nuku"

Nukkuu määritellyn sekuntimäärän.

* "Virtauta tiedosto"

Purkaa (dumps) muistissa olevan tiedoston data-ana-15 lysaattoriin, joka on valmis data-analysaattoriprosessiin.

* "Virtauta tiedoston verkko-operaattori" Käyttää osoitinta ensimmäiseen verkko-operaattoriin päästäkseen kaikkiin tuota operaattoria varten oleviin kelvollisiksi tehtyihin, laajennettuihin tietueisiin. Sitten 20 se yrittää kirjoittaa tietueet linkitetystä listasta nfs_temporary-hakemistoon. Mikäli onnistuu, tiedosto nimetään uudelleen nfs_directory :yyn. Jos tiedostoa ei voida avata uudelleen nfs temporary-hakemistossa, tiedosto avataan paikallisessa tilapäishakemistossa, ja onnistuneen kirjoi-: 25 tuksen tapahtuessa tiedosto nimetään uudelleen paikallisha- kemistoon.

* "Virtauta tiedosto RRB:hen"

Purkaa muistissa olevan tiedoston raakatietuevarmuusha-kemistoon (Raw Record Backup directory).

30 * "Kirjoita konsoliin"

Kirjoittaa viestin verkkohallintatyöasemaan.

* "Kirjoita pidätystiedostoon"

Kirjoittaa tietueet keskustiedoston pidätettyjen puhelutietueiden linkitetystä listasta pidätyshakemistoon.

35 * "Kirjoita arkistotiedostoon"

Kirjoittaa tietueet keskustiedoston arkistopuhelutietu-eiden linkitetystä listasta arkistohakemistoon.

110981 44

6. KUVAT 31-35: ASIANTUNTIJAJÄRJESTELMÄ ART—IM 6 (i) YLEISKATSAUS

Asiantuntijajärjestelmä käyttää ART-IM-tietämyskantai-sen asiantuntijajärjestelmätyökalusarjän, jonka on toimitta-5 nut Inference Corporation, suomia keinoja. Se on tietä-mys/sääntökantaohjelmointijärjestelmä, joka sallii joustavan päätöksentekomallin ja siten todellisen maailman mallintamisen tietämyshierarkian sisällä, sekä saa aikaan heuristi-semman menetelmän ongelman ratkaisua varten. Työkalusarja 10 sisältää ART-IM-kielen sekä integroidun editorin, interaktiivisen kehitysympäristön, työkalut loppukäyttäjäliityntö-jen kehittämiseksi, menetelmän kehitettyjen sovellusten ajonaikaisten versioiden levittämiseksi (deploying) ja välineen (facility) tulkita ulkoista dataa älykkäästi.

15 Data-analysaattorissa 7 asiantuntijajärjestelmä on jaettu kahdeksi alijärjestelmäksi, sääntökannaksi ja tapauskannaksi. Yleensä tapauskantaa käytetään käsittelemään reititykseen pohjautuvia virheitä, ja sääntökantaa käytetään oletusarvoistamista (defaulting) ja laskettavia virheitä 20 varten. Molemmat käyttävät ART-IM:n toiminnallisuutta.

Sääntökanta käyttää ART-im:n toimintokieliä, jotka sisältävät säännön, toiminnon ja menetelmät. Jokainen virhe määritetään mallin (schema) sisällä, ja näiden mallien tapauksia (instances) käytetään datarakenteisiin. Kaikki 1 ' 25 mallit datan sisäisen (in-data) objektihierarkian sisällä miehitetään (are populated) IEF/ART-lM-liitännän kautta käyttäen ART-IM:n "DEF-EXTERNAL_FUN"-välinettä.

ART-IM:n käyttämä ohjelmavirtausohjauksen mekanismi on hyvin erilainen peräkkäisestä lause-lauseelta-virtauksesta, 30 jollainen tavallisesti on löydettävissä ohjelmointikielistä. Viitaten kuviin 31 ja 32, asiantuntijajärjestelmä pitää kaiken sisäisen datansa, se on mallit (schemata) ja tosiasiat, malliverkossa 3100. Tätä esittää kuva 31 joukolla kuvioituja ympyröitä, joista jokainen esittää palaa sisäi-35 sestä datasta (mallia tai tosiasiaa). Tämä data voidaan asettaa * lataamalla ART-IM-testitapaustiedosto (tavallisesti 110981 45 tehdään kehitys-/yksikkötestauksen yhteydessä).

* miehittämällä ulkoisesta lähteestä (esim. Oracle tai IEF; tavallisempi tuotanto-/järjestelmätestausympäristössä).

* synnyttämällä ART-IM-säännöistä (käytetään hyvin joustava-5 na "työvarastona", esim. virhemallin luominen kelvolliseksi tekemisen testauksen epäonnistumisen jälkeen).

Kun asettaminen on tehty, dataa verrataan suoraan säännöissä määritettyihin ehtoihin. Sääntö muistuttaa perinteisemmän ohjelmointikielen JOS< ehdot > NIIN < 10 toiminta > -rakennetta. Jos säännön ehdot vastaavat täsmällisesti datatapahtumaa (instance of data), aktivointi luodaan asiaan liittyvässä asialistassa 3105. Kaikki tapahtumat tarkastetaan kaikkia sääntöjä vasten. Suorituksen kannalta malliverkkoa ja sääntöehtoja hallitaan tehokkaalla 15 malli-sovitusalgoritmilla ART-IM:n ajonaikaisessa järjestelmässä.

Syklin arviointiosan lopussa kaikki sääntöaktivoinnit asetetaan järjestykseen asialistapinoon. Ensimmäinen sääntöaktivointi pinossa sytytetään. Aktivointien ilmesty-20 mis järjestys on oletettu satunnaiseksi, ellei tärkeyttä ., (salience), eli sääntöjen prioriteettia, ole asetettu kehittäjän toimesta.

Viitaten kuvaan 32, sen jälkeen kun asialistalla 3105 ylimpänä ollut sääntöaktivointi on sytytetty, säännön ·* 25 toiminta on itse asiassa muuttanut dataa malliverkossa, mikä .. # vuorostaan muuttaa sitä, mikä ilmenee asialistapinossa, joka seuraa seuraavaa arviointisykliä.

Voidaan huomata, että datatapahtumaa, joka aiheuttaa alkusytytyksen (ympyröity tapahtuma 3110), ei arvioida 30 uudelleen, jolloin vältetään jatkuva silmukointi, vaikkakin jos data datatapahtumassa muuttuu, ja uusi malli sopii yhteen sääntöehdon kanssa, niin sääntöaktivointi luodaan.

ART—IM—ajo loppuu, kun: * ei löydetä yhteen sopivia (mathcing) ehtoja ja malleja.

35 * kaikki yhteensopivat ehdot ja mallit ovat jo sytyttäneet säännöt.

Edellä olevasta voidaan tehdä yhteenveto seuraavasti: 110981 46 1) sääntöaktivoinnit synnyttävät yhteensopivat datamallit sääntöehtojen kanssa 2) säännöt voivat, oletuksena, syttyä missä tahansa järjestyksessä, vaikkakin prioriteetteja voidaan asettaa 5 3) kaikki data arvioidaan rinnakkaisesti 4) uudelleenarviointi tapahtuu joka kerran, kun sääntö on syttynyt.

5) sama sääntö voi syttyä monta kertaa ajon aikana riippuen yhteensopivien datatapahtumien määrästä 10 6) sääntöehdot ovat sensitiivisiä muutoksille malliverkos- sa.

7) ART-IM pysähtyy, jos yhteensopivia sääntöehtoja tai malliverkkodataa ei löydetä, tai jos kaikki yhteensopineet aktivoinnit ovat jo syttyneet.

15 Viitaten kuvaan 33, sääntökanta järjestelmä pohjautuu objektihierarkiaan, kuten on esitetty. Objekteista 3300 jokainen on määritetty ART-malleissa, ja yhdistävät linjat objektien 3300 välillä kuvaavat perintöä (inheritance) yllä olevasta objektista.

20 Keskustiedosto, APDU ja puhelutietue sisältävät rakoja (slots) jokaista datakohtaa varten niiden rakenteessa. Jokaisella raolla on vastaava rako asiaankuuluvassa ole-tusobjektissa, jotta ilmoitetaan, onko resultantilla oletusarvo, laskettava arvo, vai onko se ei-modifioitava - 25 kenttä. Sääntökanta käyttää oletus järjestelmää tarkastamaan, minkä muotoinen virhekorjauksen on oltava, jos sallittu.

Edellä oleva kattaa datamallit. Liittyen virhemallei-hin, jokaisen mahdollisen data-analysaattorivirheen yksityiskohdat on kuvattu asiaankuuluvassa mallissa. Jokainen 30 virhekuvaus ja sen tapaukset (instances) sisältää raon jokaista seuraava varten:

Objekti, johon virhe liittyy, se on keskustiedosto. Virhekuvaus.

Vaikutuksen alainen (affected) rako.

35 Spesifinen dataobjekti virhetapausta varten.

Korjausarvon nimi.

Virheen lähde.

110981 ί 47

Resultanttikorjausarvo.

Sääntösijainti sytytysjärjestyksessä.

Raon arvo ennenkuin mitään korjausta on sovellettu.

5 6 (ii) SÄÄNTÖKANTAYLEISSÄÄNNÖT

Sääntökannan toiminnallista virtausta ohjataan joukolla yleissääntöjä, jotka suorittavat seuraavat toiminnot: * jokaista virheliipaisun tapahtumista varten tuon virheen korjausmetodi sytytetään, jotta synnytetään kor- 10 jausarvo, ja sen sytytysjärjestys osoitetaan (allocated).

* korjattavaa virhettä, jossa on vain yksi vaikutuksen alainen rako, varten vaikutuksen alainen rako päivitetään synnytetyn korjausarvon kanssa, ja muutoksen aikaleima (time stamp) talletetaan virhetapauksen (instance of error) 15 kanssa.

* jokaista virhetapausta, jossa korjauskuvaus ilmoittaa virhetyypin pidätettävänä, varten vaikutuksen alainen datakohta siirretään pidätystiedostoon, ja siirron aikaleima talletetaan virhetapauksen kanssa.

20 * jokaista virhetapausta, jossa korjauskuvaus ilmoittaa virhetyypin kuopattavana, varten vaikutuksen alainen datakohta siirretään kuoppaan, ja tiedoston kuoppautuksen aikaleima talletetaan virhetapauksen kanssa.

* tiedostorakennesääntölokiin luodaan tietue jokaista 25 APDU:n tai keskustiedoston korjausta varten.

* puhelutietuevirhelokiin luodaan Oracle-tietue jokaista puhelutietueen korjausta varten asiaankuuluvan virheinfor-maation kanssa.

30 korjattavat virheet : 1 ) Oletusarvoja voidaan osoittaa seuraaviin kenttiin: APDU-tyyppi ja jälkiosa laskutetun puhelun osoitin kutsutun osapuolen lopetus (clear) 35 PBX-suffiksi tietuekäyttö tietuetyyppi 110981 48 DDC-aikaleima otsikko-APDU-tyyppi datasiirron luokka formaattiversionumero 5 solmuaikaleima osatiedosto-osoitin taulukkokoko jälkiosa-APDU-tyyppi kutsutun osapuolen lopetus 10 sove11us ryhmä 2) seuraavat virheet ovat laskettavia: APDU-pituus; APDU:n pituus.

APDU-lukema; APDU-sekvenssin pituus.

Loppu-APDU-sekvenssinumero; lähtösekvenssinumero plus 15 kelvollisten APDU:iden määrä.

Lähtö-APDU-sekvenssinumero; saadaan keskustiedostossa olevan ensimmäisen APDUrn sekvenssinumerosta.

Valittu numerolukema; valitun (dialled) numerojonon pituus.

20 Edellä oleviin liittyen on virhepoikkeuksia kuten sellaisia, joissa APDUrn tarkistussummaus osoittaa virhettä.

Tämän tyyppiset virheet kuopataan välittömästi sääntökannassa. Jotkut virheet liittyen APDU-sekvenssiin aiheutuvat siitä, että sekvenssinumeroiden koko arvoaluetta sekvensoi-’ 25 daan uudelleen "1”:stä, ja asiaan liittyviä keskustiedostoja päivitetään. Voi olla, että valitun numerojonon viimeinen numero on kirjain väliltä A-F. Korjausarvo tässä on valittu numerojono miinus viimeinen numero. ei-koriattavat virheet 30 Ei-korjättävän virheen tapahtuessa virheellinen datakohta, eli puhelutietue, johdetaan kuoppaan, kuten edellä on kuvattu, ja asiaankuuluva virheloki päivitetään. Alueet, joita ei voida korjata ja jotka siten synnyttävät ei-korjättäviä virheitä, ovat seuraavat: 35 osoitevarausaikaleima (address seizure time stamp) osoitteen täydentämisen aikaleima joko osoite- tai vastausaikaleima i 49 110981 kutsuvan osapuolen lopetusaikaleima kutsuvan linjan hakemistonumero varausaikaleima valittu numerojono (paitsi kun viimeinen numero on 5 välillä A-F).

6 (iii ) TAPAUSKANTAJÄRJESTELMÄ

Reititysreferenssitapauskanta on reititysmallien tapauskanta (se on TUN, reittiryhmä, reittinumero, NNI, 10 solmupistekoodi) plus muu referenssidata, esimerkiksi laskutettavan verkko-operaattorin nimi, ja Elossa olevan (Live) ja Lopetetun (Ceased) Solmun aikaleimat. Tapauskanta-referenssidata miehitetään reititysreferenssimalleista (Routing Reference schemata), jotka puolestaan miehitetään 15 datasta, jota säilytetään datamallin (katso kuva 36) nauhatallennusasemareferenssidatasubjektialueella 3600.

Viitaten kuvaan 34 voidaan nähdä, että tapauskantajär-jestelmän objektihierarkia on samankaltainen kuin sääntökanta järjestelmän, joka on esitetty kuvassa 33, johon on 20 lisätty kolme objektiluokkaa 3400; "ehdotetut ratkaisut", "mahdolliset ratkaisut" ja "reititysreferenssi". Voidaan huomata, että "ehdotetut ratkaisut" ja "mahdolliset ratkaisut" luodaan vain reititysreferenssivirheen tunnistamisen jälkeen, ja ne sisältävät pääasiassa osoittimet muuhun · 25 dataan, joka on virheellinen sisääntuleva puhelutietue ja reititysreferenssimalli, jotka läheisimmin on sovitettu yhteen. "Reititysreferenssi"-mallit luodaan Oracle-tietokan-nassa olevasta reititysreferenssidatasta.

Liittyen reititystapauskantaan, ja käynnistykseen, 30 reititystapauskanta miehitetään ajon alussa reitityskuvaus- malleista. Jokaista reitityskuvausmallia varten luodaan yksi »k . .

tapaus. Reititystapauskanta asetetaan seuraavien parametrien kanssa.

* Enintään kolme yhteensopivuutta.

35 * Mitkä tahansa yhteensopivuudet, jotka ovat nollatoden- näköisyyden kynnysarvon alapuolella, jätetään huomiotta, jotta karsitaan pois erittäin epätodennäköiset yhteensopi- 110981 50 vuudet.

* Vain seuraavia rakoja tapauskannassa käytetään mallin yhteensovittamisessa; TUN (se on Telephony Unit Number, puhelinliikenneyksik-5 könumero), reittiryhmä, solmupistekoodi, reittinumero, NNI, ja suunta * Seuraavat jätetään huomioimatta mallin yhteensovitta-mistarkoituksessa;

Elossa olevan solmun aikaleima 10 Lopetetun solmun aikaleima

Telekommunikaatioverkko-operaattorin rooli ja nimi * Suuntaa kohdellaan hieman eri tavalla yhteensovitustar-koituksessa. Se on kaikkein vähiten merkitsevä yhteensovitustako, ja sille on annettu kiinteä 5 %:n painotuskatto 15 kokonaispainotuksesta. Muiden rakojen painot jaetaan tasaisesti kokonaispainotuksen jäljelle jääneen 95 %:n välillä.

Mallin yhteensovitus yhdessä muiden tapauskantatoimin-tojen kuten alustusparametrien asettamisen kanssa saavute-20 taan lähettämällä tapauskantaan viestejä. Mallin yhteensovitus tehdään kahdessa askeleessa, jotka ovat sisääntulevan puhelutietuemallin lähettäminen tapauskantaan, joka palauttaa löydettyjen yhteensopivuuksien määrän, ja palauta— yhteensopiva-tilanne-viestin lähettäminen, joka määrittää 25 yhteensopivuuden läheisyyden jokaista palautettua tapausta varten yhdessä palautettuun tapaukseen liittyvän reitistys-referenssimallin avaimen kanssa.

Tapauskantaa käytetään puhelumalliin liittyvän virhe-koodin kelvolliseksi tekemiseen solmupistekoodin tai 30 reittiryhmää ei löydetty-, epäkelvon reittinumeron, tai epäkelvon suunnan tapauksissa seuraavalla tavalla: * yrittää löytää täsmällisen yhteensopivuuden jokaisen sisääntulevan puhelutietueen ja reititysreferenssitapauskan-nassa olevan tapauksen välillä. Jos täsmällinen yhteensopi- 35 vuus on olemassa, puhelutietueella on kelvollinen reititys-malli, eikä pidemmälle menevää kelvolliseksi tekemistä ylläolevaan virheeseen liittyen vaadita.

110981 51 * jos täsmällistä yhteensopivuutta ei löydy, luodaan virhemalli, joka laukaisee sääntökantayleissäännöt, kuten yllä, jotka panevat toimeen (apply) korjausmetodin.

* Tämä nimenomainen korjausmetodi luo yhden ehdotettu-5 ratkaisu-mallin, joka sisältää (katso kuva 34): i) kolmeen saakka määrältään nousevia mahdollinen-ratkai-su-malleja, joista kukin sisältää osoittimen asiaan liittyvään reititysreferenssimalliin. Mahdollinen-ratkaisu-malli sisältää myös yhteensopivussijainnin (se on lähin, seuraa- 10 vaksi lähin jne.) ja prosentti-mitan yhteensopivuuden läheisyydestä, ja ii) osoittimen virheelliseen sisääntulevaan puhelutietuee-seen.

On huomattava, että kor jausmetodi poikkeaa tavallisesta 15 korjausmetodista, jonka herättää virhemallitapahtuman tuottaminen, koska se koostuu toiminnasta (reititysepäsopi-vuus, joka selittää (assert) ehdotettu-ratkaisu-mal li tapahtuman ja tosiasiat, jotka sisältävät avaimet reititysreferenssimalliin) ja toisesta säännöstä (luo-lähimmät-yhteenso-20 pivuudet, joka käynnistyy (trigger) reititysepäsopivuuden luomien tosiasioiden synnyttämisen hetkellä, ja synnyttää yhden mahdollinen-ratkaisu-mallin tapauksen jokaista löydettyä tapauskantayhteensopivuutta varten.

Kun käsitellään solmuaikaleiman kelvolliseksi tekemis-25 tä, tapauskantaa käytetään seuraavasti: * yrittämään löytää täsmällinen yhteensovitus jokaisen sisääntulevan puhelutietuemallin ja reititysreferenssimallin välillä. Jos täsmällinen yhteensovitus on olemassa, niin sääntö tarkastaa sitten, onko yhteensopivassa sisääntulevas- 30 sa puhelutietuemallissa ja reititysreferenssimallissa aikaleimaristiriitaisuuksia (se on varausaikaleiman pitäisi langeta solmun elossaolo- ja lopetusajan väliin). Jos ristiriitaa ei ole, tähän virheeseen liittyvää jatkokäsittelyä ei tapahdu.

35 * jos aikaleimaristiriita löydetään, luodaan virhemalli, joka laukaisee sääntökantayleissäännöt, kuten edellä, jotka panevat toimeen (apply) korjausmetodin.

110981 52 * Tämä nimenomainen korjausmetodi luo yhden ehdotettu-ratkaisu-mallin, joka sisältää (katso kuva 34): - yhdet mahdolliset-ratkaisu-mallit, joista kukin sisältävää osoittimen asiaan liittyvään reititysreferenssi- 5 malliin. Mahdollinen-ratkaisu-malli sisältää myös yhteenso-vitussijainnin (se on lähin, seuraavaksi lähin jne.) ja prosentti-mitan yhteensopivuuden läheisyydestä.

— osoittimen virheelliseen sisääntulevaan puhelu-tietuemalliin.

10 On huomattava, että kor jausmetodi jälleen poikkeaa tavallisesta korjausmetodista, jonka herättää virhemallitapahtuman tuottaminen, koska se koostuu toiminnasta (solmu-aikaleima-ristiriitaisuus - joka selittää ehdotettu-ratkai-su-mallitapahtuman ja tosiasiat, jotka sisältävät avaimet 15 reititysreferenssimalliin) ja toisesta säännöstä (luo_sol-mu_aika_ristiriidat, joka käynnistyy (trigger) reiti- tysepäsopivuuden luomien tosiasioiden synnyttämisen hetkellä, ja synnyttää yhden mahdollinen-ratkaisu-mallin tapauksen).

20 6 (iv) ART-IM JA ORACLE-LIITYNTÄ

Viitaten kuvaan 35, tarvitaan suora pääsy ART—IM:sta ORACLE-tietokantaan, jotta voidaan käyttää täysin hyväksi ART-IM-sääntökannan "rinnakkaisia" kelvolliseksiteke-r 25 misominaisuuksia. On olemassa neljä pääliittymää: * Reititysreferenssidatan 3500 miehitys * Oletusdatan 3505 miehitys * korjausdatan (fix data) ulostulo jäijitysketjun 3510 muodostamiseksi 30 * reititysvirhemallien ulostulo edeltäjänä pidätysdatakä- sittelylle 3515.

Katsottaessa reititysreferenssidatan miehitystä tähän liityntään 3500 liittyy sisäisen ART-IM-mallin ja tapauskan-nan virkistäminen datasta, joka on fyysisesti ORACLE- 35 taulukoissa pidetyssä reititysreferenssimallissa: * virkistäminen laukaistaan ART-IM-ajon alustusvaiheen aikana.

53 110981 ! i * olemassa olevat sisäiset ART-IM-reititysreferenssimal- lit puhdistetaan yhdessä niiden tapauskantamerkintÖjen kanssa.

* data VALITAAN ORACLE-taulukoista ProC-ohjelmasta 5 (EAB_INITIALISE_IDA_RULEBASE), jota käytetään osana kahta ulkoista toimintalohkoa (f ile_to_ida_rules ja call_re-cord_to_ida_rules).

* Sisäiset ART-IM-mallit miehitetään ProC-ohjelman toimesta 10 * Reititysreferenssitapauskanta vuorostaan miehitetään sisäisestä reititysreferenssimallista toiminnon (inca_i-da_initialise_casebase) toimesta osana tapauskannan alustus-prosessia.

Katsottaessa oletusdatan miehitystä: 15 * virkistäminen laukaistaan ART-IM-ajon alustusvaiheen aikana.

* olemassa olevat sisäiset ART-IM-oletusmallit (df-puhelutietue, df-APDU jne.) puhdistetaan yhdessä niiden tapauskantamerkintÖjen kanssa.

20 * data VALITAAN ORACLE-taulukoista ProC-ohjelmasta (EAB_INITIALISE_IDA_RULEBASE), jota käytetään osana kahta ulkoista toimintalohkoa (file_to_ida_rules ja call_re-cord_to_ida_rules).

* Sisäiset ART-IM-mallit miehitetään ProC-ohjelman 25 toimesta.

Katsottaessa virhe- ja korjausdatan luomista, jos virheitä, jotka liittyvät dataan, joka voidaan korjata, havaitaan sisääntulevan datan kelvolliseksitekemisen aikana, niin sääntökannan käyttämien korjauksien jäijitysketjua 30 täytyy ylläpitää: , * jokaista virheellistä tiedostorakennetta varten luodaan

1 l I

rivimerkintä FILE_ERROR_LOG-taulukkoon. Tämä tehdään nauhatallennusasemaprosessin toimesta.

* jokaista virheellistä puhelutietuetta varten luodaan 35 rivimerkintä CALL_RECORD_ERROR_LOG: iin. Tämän voi tehdä nauhatallennusasemaprosessi tai ART—IM.

* jokaista tiedostorakennetasolla havaittua virhettä ja • 1 · rr · · 54 110981 käytettyä korjausta varten luodaan rivimerkintä FILE_STRUCTURE_RULE_LOG: iin ORACLE-tietokannassa. Tämä on paras tehdä sääntökannan toimesta, joka käyttää yleissääntöä, joka liipaistaan, kun koko tiedostotason virhehavain-5 nointi ja kaikki korjaukset on suoritettu. Säännön pitäisi syttyä kerran jokaista havaittua virhettä/käytettyä korjausta varten, ja kun sytytetty, niin herättää käyttäjän määrittelemän proseduurikutsun sql_exec_limited, joka tekee tarvittavan sisäänpanon (insertion).

10 * jokaista tiedostorakennetasolla havaittua virhettä ja käytettyä korjausta varten luodaan rivimerkintä CALL_RECORD_RULE_LOG:iin ORACLE-tietokannassa. Tämä on paras tehdä sääntökannan toimesta, joka käyttää yleissääntöä, joka liipaistaan, kun koko puhelutietuetason virhehavainnointi ja 15 kaikki korjaukset on suoritettu. Jälleen säännön pitäisi syttyä kerran jokaista havaittua virhettä/käytettyä korjausta varten, ja kun sytytetty, niin herättää käyttäjän määrittelemän proseduurikutsun sql_exec_immed, joka tekee tarvittavan sisäänpanon (insertion).

20 * ART-IM-säännöt miehittävät sisäänpannut arvot sisäisissä malleissa olevista raoista.

Katsottaessa reititysvirhemallien luomista ja lähimmät yhteensopivuudet-dataa, jos virheitä, jotka liittyvät dataan, joka on pidätetty, havaitaan sisääntulevan datan , 25 kelvolliseksitekemisen aikana, niin sisääntulevan puhelu- tietuevirhemallin tietue (pohjautuu TUN:ään, NNI:hin, reittiryhmänumeroon, reittiryhmään, suuntaan) yhdessä kolmen lähimmän yhteensopivuuden (pohjautuen reititysreferenssimal-lissa oleviin sisääntulevaa virheellistä puhelutietuetta 30 lähimpinä oleviin malleihin) täytyy tallettaa ORACLE- ·: tietokantaan myöhempää pidätystiedostokäsittelyä varten.

Mallit talletetaan sen jälkeen kun kaikki kelvolliseksitekemisen käsittelyt/korjauskäsittelyt on suoritettu. Yksityiskohtaisemmin: 35 * jokaista synnytettyä virhettä, joka on pidätystiedosto- virhe (ja olettaen, että samaan puhelutietueeseen ei ole synnytetty ei-korjättäviä virheitä - nämä korjauskelvottomat 110981 55 puhelutietueet karsitaan pois käyttämällä move_to_sump-yleissääntöä) varten sytytetään yleissääntö. Sääntö yrittää valita virheellisen mallin tietokannasta, ja jos virheellinen malli on olemassa: 5 i) testaa mitä tahansa merkintää FILE_ROUTE_ERROR_LINK:ssä asiaankuuluvien mallikeskustiedoston ja vieraiden avainten kanssa.

ii) jos merkintä on olemassa, jatkotoimia ei vaadita.

iii) jos merkintää ei ole olemassa, niin sitten sisäänpanee 10 r i vimerkinnän FI LE_ROUTE_ERROR_L INK: i in.

Jos virheellistä mallia ei ole olemassa: iv) sisäänpanee rivimerkinnän ROUTE_ERROR_PATTERN-tauluk-koon, jonka on miehittänyt virhemallidata sisääntulevista puhelutietueista.

15 v) sisäänpanee rivimerkinnän FILE_ROUTE_ERROR_LINK: iin.

vi) sisäänpanee määrältään aina kolmeen asti nousevaa rivimerkintää CLOSEST_MATCHES-taulukkoon, jonka miehittää reititysreferenssimallit, joiden havaittiin edellisestä tapauskantakäsittelystä olevan lähimpinä virheellistä 20 reittimallia.

* käyttäjän määrittelemää proseduuria käytetään välittämään SQL-komento ORACLE:lie.

* ART-IM-säännöt miehittävät sisäänpannut arvot sisäisissä malleissa olevista raoista.

25

KUVAT 20,21 JA 37-43: DATA-ANALYSAATTORIN 7 SUORITTAMA

ASIANTUNTIJAJÄRJESTELMÄN KÄYTTÖ

Vuokaavioissa, joihin alla viitataan, on huomattava, että niissä käytetään hieman erilaista formaattia verrattuna 30 tämän määrittelyn aikaisempiin vuokaavioihin. Toisin sanoen toimintokutsuja merkitään laatikoilla, joissa on kaksinkertaiset vertikaalilinjat, yksinkertaiset lauseet merkitään laatikoilla, joissa on yksinkertaiset vertikaalilinjat, ja kyllä/ei-päätökset merkitään yksinkertaisella timantilla.

35 ART-IM-asiantuntijajärjestelmän käyttö data-analysaat torin 7 toimesta voidaan esittää vuokaavioin. Viitaten kuviin 16, 17 ja 20, kun on määritetty, että puhelu- ' 56 110981 tietuetasolla on vika, askel 1605, ja seuraava puhelu-tietuevirheloki on valittu tiedostosta, askel 1702, niin asiaankuuluvat puhelutietueet lähetetään asiantuntijajärjestelmään, askel 2000. Asiantuntijajärjestelmä paikallistaa 5 oikean APDU:n, askeleet 2005,2010, ja virheelliseksi todetun puhelutietueen, askeleet 2015,2020.

Sitten asiantuntijajärjestelmä tarkastaa, onko puhelu-tietue oikealla tavalla eritelty (askel 2025), tässä esimerkissä Järjestemä X-erittelyn mukaisesti, ja jos se ei 10 ole, ohjaa puhelutietueen kuoppaan asettamalla IEF-tilan "KUOPAKSI", askel 2030, samalla päivittäen puhelutietuevir-helokin, askel 2035. Jos puhelutietue on asianmukaisesti eritelty, se "pannaan läpi" asiantuntijajärjestelmän, askeleet 2040,2045,2050, ja tulokset arvioidaan data-15 analysaattorin 7 toimesta askeleessa 1704 ja siitä eteenpäin.

Viitaten kuviin 16 ja 21, on voitu päättää, että tiedosto- tai APDU-tasolla on vika, askel 1604. Tässä tapauksessa tiedosto ladataan muistiin, ja tiedosto-otsikko 20 ja APDU:t lähetetään asiantuntijajärjestelmään, askel 2100. Asiantuntijatietokanta kutsutaan esiin, askel 2105, ja APDU-mallit edellisestä ajosta poistetaan, askel 2110. Ensimmäisellä testiajolla virkistetään reititysreferenssimallin asiantuntijajärjestelmäversio, askel 2115, mikä voi välittö-, 25 mästi johtaa ilmeisen virheen korjaamiseen. Jos ei, niin oletusdata asiantuntijajärjestelmää varten virkistetään, askel 2120, tapauksessa, jossa esimerkiksi oletusdata virhettä varten, josta ollaan kiinnostuneita, on aikaisemmin puuttunut. Jos jompi kumpi näistä onnistuu, data-analysaat-30 toriprosessi tekee itsensä uudelleen voimassaolevaksi ,: (reasserts itself), kuva 16, ja tulokset asiantuntijajärjes- telmän virkistysaskelista sallivat tiedoston mennä omien puhelutietueidensa kelvolliseksitekemiseen, askel 1611. Jos kumpikaan ei onnistu, puhelutietueet itsessään täytyy tehdä 35 kelvollisiksi yksittäisesti. Tämä kuvataan alla.

Viitaten kuvaan 37, kuvan 21 toimintalaatikko 2125, "kuvaa otsikko- ja APDU-malli", laajenee sisältämään 110981 57 asiantuntijajärjestelmä ART—IM:n lataamisen (askeleet 3700-3725, 3735) ja ajamisen (askeleet 3730,3740,3745,3750) suhteessa puhelutietueisiin virheellisiksi todetuista tiedostoista, joita ei voitu onnistuneesti käsitellä 5 reititysreferenssimallin ja oletusdatan virkistämisten

jälkeen. Tämä lataamisprosessi sisältää datan, joka ei ole saatavilla ART-tietokannassa, hakemisen ("vieraat avaimet") esimerkiksi data nauhatallennusasemasta 6 askeleessa 3715, jotta sallitaan asiantuntijajärjestelmän sisäänpääsy 10 tiedostoihin. Analysoituaan jokaisen puhelutietueen ART

toimittaa (supply) tilan (askel 3755), joka voi osoittaa, että puhelutietue on korjattu, tai että se pitäisi pidättää tai kuopata. Data-analysaattoriprosessi (IEF) pitää lukua kuopattavaksi tulevista puhelutietueista, askel 3760, ja 15 asettaa ART-IM:ssä lipun, askel 3765, joka liipaisee puhdistamisen ART-IM:n toimesta, askel 3770, jotta poistetaan jokainen puhelutietue ja asiaankuuluvat mallit, jotta yksinkertaisesti vältetään näiden keräytyminen.

Viitaten kuviin 38-43, asiantunti ja jär jestelmätiedos-20 tosääntöjen käyttöä voidaan myös esittää vuokaavioin, ja seuraavat esimerkit esitetään vuokaavioiden ollessa itsessään selittäviä: i) Kuva 38; ART-tiedostosäännöt (keskustiedosto-otsikko) Tätä voidaan soveltaa -25 jälkiosa-APDU:hun formaattiversionumeroon tiedostotyyppiin solmuaikaleimaan DDC/NMP—aikaleimaan (NMP tarkoittaa Network Mediation 30 Processor, verkkovälitysprosessori) datasiirron luokkaan solmuklusteri-identiteettiin nauhatallennusasema-NNI:hin käyttöryhmään 35 osatiedosto-osoittimeen tiedoston tavukokoon taulukkokokoon 58 110981 valitun APDU:n tyyppiin ii) kuva 39; APDU:n ensimmäisen sekvenssi numeron sääntö iii) kuva 40; APDU:n viimeisen sekvenssinumeron sääntö iv) kuva 41; APDU-sekvenssinumerolukemasääntö 5 v) kuva 42; ART APDU-säännöt tätä voidaan soveltaa - uudelleenlähetysosoittimeen linkityskenttään vi) kuva 43; ART puhelutietuesäännöt 10 Tätä voidaan soveltaa - tietuekäyttöön laskutetun puhelun osoittimeen lopetussyyhyn (clearing cause) PBX-suffiksiin 15 CLI-klusterin identiteettiin verkkopiiriin (network circuit) verkkokaistaan piiri-identiteettiin piirinumeroveloituskaistaan (circuit number charge 20 band) puhelunäytteistysmenetelmään näytteistysmoodiin lukeman uudelleen asetuksen (reset) osoittimeen N:n arvoon (missä N liittyy lukemaan, joka on tehty : 25 sillä aikaa, kun ajetaan esimerkiksi puhelutietueiden testierää) kutsuttu osapuoli lopettanut-aikaleimaan.

8. KUVAT 36 JA 44: YRITYS JÄRJESTELMÄ 30 Viitaten kuvaan 4, ulostulo nauhatallennusasemasta 6 yritysjärjestelmään 8 sisältää puhelutietueet, jotka on luokiteltu laskutettavan entiteetin mukaan ja jotka on tehty kelvollisiksi edellä kuvattuun tapaan käyttäen data-analysaattoria, johon sisältyy ART-IM-asiantuntijajärjestelmä.

35 Yritys järjestelmän 8 päätehtävä on hinnoitella puhelu- tietueet ja tulostaa hinnoitellut tietueet siten, että ne voidaan laskuttaa asiakkailta. Sillä on kuitenkin myös 110981 59 kelvolliseksitekemistehtävä, kuten edellä on mainittu, painopisteen ollessa datassa, joka liittyy laskutettavaan entiteettiin ja suhteeseen laskutettavan entiteetin ja ensimmäisen verkon 1 operaattorin välillä. Yritys järjestelmä 5 8 siten sisällyttää tai pääsee sisään (access) yritysjärjes- telmädata-analysaattoriin, johon seuraavassa viitataan nimellä "cIDA".

cIDA-sovellutus voi sijaita data-analysaattorin 7, joka tekee kelvolliseksi dataa nauhatallennusasemasta 6, kuvattu 10 edellä, rinnalla. Kuvassa 4 olevat virheellisten puhelu-tietueiden korjausaskel 430, korjattujen puhelutietueiden tallennusaskel 440 ja korjauskelvottomien puhelutietueiden tutkimisaskel 450 voidaan kaikki suorittaa cIDA-sovellutuk-sen keinoin.

15 Mielenkiintoisesti on havaittu, että virheiden pääosa, luokkaa 90 % virheistä, jotka yritysjärjestelmä 8 poimii, liittyy aukikoodauspoikkeamiin (decode anomalies), jotka pääasiassa liittyvät "aikalinjoihin" kuten "123" ja "hätäpalveluihin" (999) meneviin puheluihin. Pääosa virheiden 20 jäljelle jääneestä osasta voidaan katsoa aiheutuvan refe-renssidatassa olevista ristiriitaisuuksista. Siten voi olla kaksi pääaspektia data-analysaattorin, jota käytetään yritysjärjestelmän 8 kanssa, rakentamiseen näiden ollessa tiedostojen, jotka aiheuttavat pääosan virheistä, aukikoo- • 25 dauspoikkeamista, käsitteleminen, ja sitten infrastruktuu- »· · rin, joka pystyy korjauksen jälkeen kuvaamaan tiedostot takaisin yritys järjestelmään 8, aikaansaaminen.

Käsittelyn yleiskuvaus 30 Sopiva järjestely voisi olla seuraava. Virhe- ja • varoitustiedostot lähetetään yrityslaatikosta 8 cIDA:aan, missä ne ladataan määrättyihin hakemistoihin, yksi per operaattori. Yksittäinen tiedosto voi pitää sisällään monia tietueita tai ei yhtään tietuetta. Edullisesti cIDA saa 35 aikaan rinnakkaisen käsittelykeinon, joka ajaa samanaikaisesti, kaikkia operaattoreita varten manuaalisen ohitusmah-dollisuuden kera. Lokia ylläpidetään, jotta ohjataan 110981 60 tiedostojen sekvenssiä sisään cIDAiaan ja ulos cIDArsta.

Kun virhetiedosto on valittu käsiteltäväksi, cIDA valitsee jokaisen tietueen vuorollaan olettaen, että tiedosto ei ole tyhjä, ja arvioi virheen yhteen kahdesta 5 kategoriasta: korjattaviin ja korjauskelvottomiin. Korjaus-kelvottomat virheet kirjoitetaan taulukkoon ja niistä raportoidaan, ja ne voidaan myöhemmin poistaa tietokannasta arkistoitaviksi. Jos tietuetta on pidetty korjattavana, se voidaan korjata automaattisesti käyttämällä sääntöjä, tai se 10 voi vaatia manuaalista väliintuloa, ennenkuin se voidaan korjata.

Virhetyypistä riippumatta jokainen tietue pistetään ORACLE-tie tokan ta taulukkoon kaikkien yksityiskohtien kanssa, jotka päästetään yrityslaatikosta 8, ja lippu asetetaan 15 osoittamaan "tilaa". Tila voidaan edellä olevan mukaisesti valita seuraavista: pidätys korjauskelvoton säännöt 20 Käyttäjillä, jotka käyttävät Business Objects-ajoa säännöllisin väliajoin, on kyky tutkia kaikkia tietueita, joita sillä hetkellä pidetään, ja tilaosoitusta, joka heille on annettu. Jäijityslokia voidaan pitää asiaankuuluvan jakson ajan, kuten yhden kuukauden ajan kaikkia "veloitusnu-25 merojono"-korjauksia varten.

Saatetaan huomata, että automaattisten sääntöjen käyttö voidaan havaita tarpeettomaksi. Korjaamalla virheet, jotka aiheutuvat aukikoodauspoikkeamista, se on 90 % tämänhetkisistä virheistä, virhemäärän on havaittu vähenevän 0.01 30 %:iin. Täten esiin tulevien virheiden yksinkertaisuus tarkoittaa sitä, että järjestelmä, joka käyttää hyväkseen automaattisia sääntöjä, olisi turhan monimutkainen.

Kuvasta 44 voidaan nähdä esillä olevan keksinnön datakeräys- ja käsittelyjärjestelmän ympärillä olevat 35 datavirtausreitit. Tässä kuvassa datavarastot kuten tiedostot ja taulukot on esitetty horisontaalisesti ojentuvilla suorakulmioilla, joissa on vertikaaliset pisteviivat, ja 110981 ί 61 prosessit on kuvattu isommilla lohkoilla, joihin suorakulmiot sisältyvät. Entiteetit, jotka ovat ulkoisia koko järjestelmälle, kuten NCDB 9, on esitetty "nelikoveroilla" (lozenges).

5 Kuten edellä on kuvattu, raakapuheludata syötetään nauhatallennnusasemaan, joka muuntaa raakapuheludatan, tekee kelvollisiksi ja käsittelee puhelutietueet liittäen mukaan (involving) data-analysaattorin niin pitkälle kuin on tarpeen, ja tulostaa kelvolliseksi tehdyt, eritellyt 10 puhelutietueet yrityslaatikkoon. Yrityslaatikko ensiksi suorittaa operaattorille ominaisen kelvolliseksi tekemisen, ja toiseksi kokoaa yhteen (aggregates) eritellyt puhelu-tietueet. Tässä vaiheessa puhelutietueet hinnoitellaan käyttämällä laskutusinformaatiota esimerkiksi kansallisesta 15 laskutustietokannasta (NCDB) 9 ja tulostetaan yhteenvedetys-sä muodossa, jotta tuotetaan laskuraportti asiaankuuluvaa asiakasjärjestelmää 10 varten. Muihin tulostuksiin kuuluvat laajennetut puhelutietueet, jotka on varastoitu optiselle levylle 71 , ja yhteenvedetyt puhelutietueet hallintorapor-20 tointijärjestelmää 4400 varten.

Kuvasta 44 voidaan nähdä, että on olemassa myös ulostulo data-analysaattorista jäijitysjärjestelmään "CARDVU" 4405. Vaikka esillä olevan keksinnön suoritusmuodot voivat tuottaa erittäin yksityiskohtaista informaatiota 25 jäijitystarkoituksiin, jäljitysjärjestelmä itsessään ei ole osa keksintöä, eikä sitä kuvata tässä kuin otsikkoa "9. JÄLJITYSKETJU" seuraavilla kommenteilla.

Viitaten kuvaan 36, yritys järjestelmän 8 datamalli esittää selvästi datalähteet, joita yritysjärjestelmä 8 30 käyttää hinnoittelussa ja laskutuksessa. Suurin osa datasta, * "C&P"-referenssidatasta, johdetaan NCDB:sta 9. Kuitenkin on olemassa rajoitteita, joita asettaa laskutussopimus 4500 laskutettavan entiteetin ja verkon 1 operaattorin välillä.

Monet asiat voidaan käsitellä verkkohallintakeskuksesta, ja 35 kuvan 36 datamalli tarjoaa asiaan kuuluvan näkyvyyden siihen "tietoliikenneverkko-operaattorin rooli"-laatikon 4505 avulla.

110981 62

Seuraavia kuvassa 36 käytettyjä alkukirjainmerkintöjä voidaan laajentaa seuraavasti: CBM Veloituskaistamatriisi (Charge Band Matrix) CB Veloituskaista (Charge Band) 5 NN Verkkosolmu (Network Node) KCH Kingston Communications, Hull (verkon, joka on yhdistetty BT PSTNrään, operaattori UK:ssa) TE Telecomm Eirann (kuten edellä) NCIF National Charging Information Package (liityntä 10 NCDBrssä olevaan dataan).

Hinnoittelu- ja veloituskoneet, jotka noudattavat sen tyyppisiä rajoitteita, joita esillä olevan keksinnön järjestelmä tarjoaa, ovat tunnettuja, ja sen vuoksi määrittelyku-vausta veloitus- ja hinnoittelukoneesta ei tässä anneta.

15 Todellakin, vaikka kuvan 36 datamalli esittää kaikki asiaan kuuluvat entiteetit, ei kaikkia suhteita ole esitetty, sillä esitys tulisi liian monimutkaiseksi. Kaiken kaikkiaan kuitenkin on pidettävä mielessä, että kaikki puhelutietueet, joita yritysjärjestelmä 8 käsittelee, ovat valmiiksi 20 luokiteltu laskutettavan entiteetin mukaan. Tätä datan aspektia täytyy selvästikin ylläpitää, jotta asiaan liittyvät raportit voidaan osoittaa oikeille asiakasjärjestelmille 10. Tämä voidaan tehdä, kuten edellä on osoitettu, esimerkiksi ylläpitämällä osoitettuja hakemistoja laskutettavia 25 entiteettejä varten.

9. JÄLJITYSKETJU

Järjestely, jollainen on kuvattu edellä, voi saada aikaan kehittyneen jäljitysketjun. Data keskuksesta yhdistä-30 mispisteessä tulee tiedostossa, ja se pakataan APDU:ihin. Nauhatallennusasemajärjestelmä 6 kiertokysyy datan DDC:eistä 5 käyttäen FTAM-protokollaa datan ollessa binaarisena puhelutietueissa. Nauhatallennusasema järjestelmä 6 tekee datan kelvolliseksi vasten tietokantaa, joka sisältää 35 referenssidataa, reititysreferenssimallin, ja määrittää, mitä toista verkko-operaattoria pitäisi laskuttaa. Nauhatallennusasema järjestelmä 6 kirjoittaa täyden puhelutietueen 110981 63 ASCII-muodossa lisäten operaattori- ja keskusinformaation.

Jäijitysketju tulee esiin seuraavasti. Keskuksessa puhelutapahtumat numeroidaan tiedostosynnytysnumerolla (File Generation Number), joka saa arvoja 0-9999. DDC 5 lisäksi 5 lisää sekvenssinumeron, joka saa arvoja 0-999999, tiedosto-tasolla. Tiedoston sisällä APDU:t on myös sekvensoitu APDU-sekvenssinumerolla, joka saa arvoja 0-16353 ja on binaarinen.

Tämä tarkoittaa sitä, että on talletettu tietue 10 tiedostossa olevien tietueiden määrästä, APDU-lähtö- ja -loppunumeroista, ja APDU:iden määrästä.

Koska sekvenssinumero on lisätty jokaiseen numeroon keskuksessa, voidaan varmistaa, että yrityslaatikko 8 vastaanottaa numerot sekvenssissä, vaikka niitä ei välttä-15 mättä käsitellä järjestyksessä. Nauhatallennusasemajärjes-telmä 6 tosiasiassa käsittelee rinnakkain eri keskuksista samaan aikaan.

Data-analysaattorissa, jossa käytetään "malliverkkoa", jonka avulla data "sytyttää" säännön, jos se ei sovi 20 kelvolliseen sisältöön, analysaattori voi paikata datakohdat vain siellä, missä asiaan liittyvä datakohta ei vaikuta hintaan tai jäijitysket juun. Paikata tässä yhteydessä tarkoittaa asettamista standardiarvoon. Täten data-analysaattori ei voi muuttaa puhelutietuesekvenssinumeroa, 25 koska se identifioi puhelutietueen. Jos puhelutietuesekvens- • « l sinumeroa muutettaisiin, ei jäi jitysketjua olisi.

Edellä kuvattu järjestelmä on, kuten on mainittu, vain yksi tietty keksinnön suoritusmuoto. Se liittyy PSTNrään ja, kuten on kuvattu, käsittelee puhelutietueita ääniviestintä-30 järjestelmässä. Lisäksi asiaan liittyvien puhelutietueiden tietty muoto, Järjestelmä X-tyyppi 6, liittyvät ainoastaan yhteen keskustyyppiin, jota voidaan käyttää yhdistämispis-teessä (POI) verkkojen välillä.

Monia muutoksia voitaisiin tehdä ilman, että poiketaan 35 esillä olevan keksinnön hengestä. Yksinkertainen laajennus keksinnön käyttöön on se, että yhtä hyvin kuin käytetään puhelutietuedataa synnyttämään laskutusinformaatiota, 64 110981 voidaan myös poimia ja käsitellä liikenneanalyysi-informaa-tiota. Esimerkiksi puhelut, jotka eivät saavuta kohdettaan, "kelvottomat", voidaan laskea keskuksen toimesta POI:ssa, ja "kasaan pantu" ("bulked") tulos syötetään datakäsittelyjär-5 jestelmään.

Joka tapauksessa merkittävämpiin muutoksiin voisi kuulua järjestelmän käyttö jossain muussa tietoliikenteessä kuin ääni viestinnässä jopa poissulkien ääniviestinnän, ja kuten edellä on jo mainittu, ei selvästikään ole välttämä-10 töntä, että asiaan liittyisi PSTN, vaikka keksinnön suoritusmuotojen hyöty on selkeän merkittävä PSTN:n kanssa jo pelkästään asiaan liittyvien tietuemäärien ja lähteiden monimutkaisuuksien valossa.

15 20 25 30 35

Claims (8)

110981 65

1. Data-analysaattori käytettäväksi tietoliikenneverkossa, joka verkko on kytketty yhteen tai useampaan muuhun verkkoon, tunnettu siitä, että data-analysaattori 5 sisältää sisäänoton dataa, joka on kerätty suhteessa mainittuun verkkoon, varten, mainitun datan ollessa tullut mainittuun verkkoon liittyvien kelvolliseksi tekevien elimien hylkäämiksi, elimet datassa esiin tulevan epäkelpoi-suuden tyypin arvioimiseksi, ja elimet datan käsittelemisek-10 si sen mukaisesti, mainittuihin elimiin datan käsittelemiseksi kuuluessa elimet soveltaa oletusarvoja, elimet soveltaa korjattuja arvoja, ja elimet liittää data tiedostoihin väliaikaisessa datavarastossa.

2. Patenttivaatimuksen 1 mukainen data-analysaattori, 15 tunnettu siitä, että mainittuihin elimiin datan käsittelemiseksi edelleen sisältyy elimet datan lähettämiseksi kuoppaan myöhempää hallintoanalyysiä varten.

3. Kumman tahansa edellä olevan patenttivaatimuksen mukainen data-analysaattori, tunnettu siitä, 20 että elimet datan käsittelemiseksi valitsevat tavan, jolla dataa käsitellään, sen syyn, jonka takia se on tullut epäkelvoksi, perusteella.

4. Minkä tahansa edellä olevan patenttivaatimuksen mukainen data-analysaattori, tunnettu siitä, 25 että jokainen tiedostoista, joihin dataa voidaan liittää, liittyy vastaavaan virhemalliin, ja kaikki data, joka on liitetty tiedostoon, voidaan korjata samalla tavalla, esimerkiksi päivittämällä määrätty referenssidata, joka liittyy epäkelpoisuuteen.

5. Minkä tahansa edellä olevan patenttivaatimuksen mukainen data-analysaattori, tunnettu siitä, että se on varustettu toisella sisäänotolla, jotta vastaanotetaan dataa, jonka kelpoiseksi tekevät elimet, jotka liittyvät hinnoittelu- ja laskutuselimiin, ovat hylänneet 35 virheellisen datan, joka liittyy hinnoitteluun ja laskutukseen, perusteella.

6. Minkä tahansa patenttivaatimuksen 1-4 mukainen data- 110981 66 analysaattori, tunnettu siitä, että analysaattori sisältää toisen sisäänoton dataa, jonka kelpoiseksi tekevät elimet ovat hylänneet aukikoodauspoikkeamien perusteella, varten.

7. Minkä tahansa edellä olevan patenttivaatimuksen mukainen data-analysaattori, tunnettu siitä, että se sisältää asiantuntijajärjestelmän, joka sisältää sääntökannan ja tapauskannan.

8. Minkä tahansa edellä olevan patenttivaatimuksen 10 mukainen data-analysaattori, tunnettu siitä, että se on kahdessa osassa siten, että on saatu aikaan osa, johon sisältyy asiantuntijajärjestelmä datan analysoimiseksi, joka data on voinut tulla epäkelvoksi mistä tahansa valikoimasta syitä mukaanlukien virheellinen reititysdata, 15 ja että on saatu aikaan osa datan analysoimiseksi, joka data on voinut tulla epäkelvoksi vähintään yhdestä syystä, joka ei kuulu valikoimaan syitä, missä toinen näistä kahdesta osasta vastaanottaa dataa, joka on luokiteltu asiaan liittyvän laskutettavan entiteetin mukaan, kun taas ensim-20 mäinen osa vastaanottaa dataa, jota ei ole tällä tavalla luokiteltu. i i » 110981 (57) Tiivistelmä Verkkojen välinen puhelulaskutusjärjestelmä käytettäväksi tietoliikenneverkossa, kuten yleisessä kytkentäisessä puhelinverkossa (1) Britanniassa, sallii puhelutietueiden luokittelun puhelujen suhteen laskutettavan verkko-operaattorin mukaan, ennen kuin ne hinnoitellaan ja laskutetaan. Data-analysaattori (7), johon sisältyy asiantuntijajärjestelmä, on saatu aikaan puhelutietueita, joita ei voida tehdä kelvollisiksi, varten. Data-analysaattori (7) voi käyttää oletusdataa tai korjattua dataa, tai voi tulostaa epäkelvon datan pidätysprosessiin, joka odottaa päivitettyä referenssi-informaatiota. Kor jauskelvoton data tulostetaan kuoppaan hallinnollisia tarkoituksia varten. Hinnoittelu- ja laskutuskone käsittelee dataa, joka on jo luokiteltu laskutettavan entiteetin mukaan, ja siihen sisältyy pidemmälle menevät analyysielimet datan, joka on epäkelpoa hinnoitteluun ja laskutukseen liittyvän informaation vuoksi, käsittelyyn. Kuvio 1 110981 λ, n 1 (57) Sammandrag Ett samtalsfaktureringssystem mellan nät för användning i ett kommunika-tionsnät, säsom i ett allmänt kopplat telefonnät (1) i Britannien, möjlig-gör en klassifiering av samtalsdata-posterna relativt samtal enligt en fakturerad nätoperator, före de prissättes och faktureras. En data-analysator (7) med ett expertsystem ästadkoinmits för de samtalsdatapos-ter, som inte kan göras giltiga. Da-ta-analysatorn (7) kan använda ut-gängsdata eller korrigerad data, el-ler kan mata ut olämplig data tili en stopprocess, som motser en uppdaterad referensinformation. Data, som inte kan korrigeras, mätäs ut i en sump för administrativa ändamäl. En pris-sättnings- och faktureringsmaskin behandlar data, som redan klassi-fierats enligt entiteten, som skall faktureras, och den omfattar ana-lysorgan med längre perspektiv för behandling av data, som är olämplig pä grund av informationen angäende prissättningen och faktureringen. Figur 1 r