FI108495B - Palvelujen tarjoaminen tietoliikenneverkossa - Google Patents

Description

1 108495

Palvelujen tarjoaminen tietoliikenneverkossa %

Keksinnön ala , Keksintö liittyy yleisesti palvelujen tarjoamiseen tietoliikennever- 5 kossa, erityisesti älyverkossa. Palvelu voi olla mikä tahansa verkossa tuotettu palvelu, joka tuotetaan verkon käyttäjää tai muuta objektia varten.

Keksinnön tausta

Telekommunikaatioalan nopea kehitys on tehnyt mahdolliseksi sen, 10 että operaattorit voivat tarjota käyttäjille monia eri tyyppisiä palveluja. Kehittyneitä palveluja tarjoavaa verkkoarkkitehtuuria kutsutaan älyverkoksi, josta käytetään yleisesti lyhennettä IN (Intelligent Network).

Älyverkon toiminnallista arkkitehtuuria on esitetty kuviossa 1, jossa verkon toiminnalliset oliot (functional entities) on esitetty ovaaleina. Seuraa-15 vassa tätä arkkitehtuuria kuvataan lyhyesti, koska keksintöä kuvataan jatkossa viitaten älyverkkoympäristöön.

Loppukäyttäjän (tilaajan) pääsystä verkkoon huolehtii CCAF-toi-minto (Call Control Agent Function). IN-palveluihin pääsy toteutetaan olemassaoleviin digitaalisiin keskuksiin tehtävillä lisäyksillä. Tämä tehdään 20 käyttämällä hyväksi yleistä puhelun tilamallia BCSM (Basic Call State Model), joka kuvaa sitä olemassaolevaa toiminnallisuutta, jolla kahden käyttäjän välinen puhelu prosessoidaan. BCSM on korkean tason tila-automaatti-kuvaus niistä puhelinohjaustoiminnon (CCF, Call Control Function)’ toiminnoista, joita tarvitaan käyttäjien välisen yhteysreitin pystyttämiseen ja ylläpi-. 25 toon. Tähän tilamalliin lisätään toiminnallisuutta palvelun kytkentätoiminnon SSF (Service Switching Function) avulla (vrt. olioiden CCF ja SSF osittainen päällekkäisyys kuviossa 1), jotta voidaan päättää, milloin on kutsuttava älyverkon palveluja (eli IN-palveluja). Kun näitä IN-palveluja on kutsuttu, huolehtii älyverkon palvelulogiikan sisältävä palvelun ohjaustoiminto SCF (Service 30 Control Function) palvelusidonnaisesta (puheluyrityksen) käsittelystä. Palvelun kytkentätoiminto SSF liittää siis puhelunohjaustoiminnon CCF (Call Control Function) palvelun ohjaustoimintoon SCF (Service Control Function) ja sallii palvelun ohjaustoiminnon SCF ohjata puhelunohjausta CCF. SCF voi esim. pyytää, että SSF/CCF suorittaa määrättyjä puhelu- tai yhteystoimintoja, 35 esim. laskutus- tai reititystoimenpiteitä. SCF voi myös lähettää pyyntöjä pal-veludatatoiminnolle SDF (Service Data Function), joka huolehtii pääsystä 2 108495 älyverkon palvelusidonnaisiin tietoihin ja verkkotietoihin. SCF voi näin ollen esim. pyytää SDF:ää hakemaan tiettyä palvelua koskevia tietoja tai päivittämään näitä tietoja.

Edellä esitettyjä toimintoja täydentää vielä erikoisresurssitoiminto 5 SRF (Specialized Resources Function), joka tarjoaa sellaisia erikoiskeinoja, joita vaaditaan joidenkin älyverkon tarjoamien palvelujen toteuttamiseksi. Esimerkkejä tällaisista ovat protokollamuunnokset, puheentunnistus, ääni-ilmoitukset, jne. SCF voi esim. pyytää SSF/CCF-toimintoja luomaan ensin yhteyden loppukäyttäjien ja SRF:n välillä ja sen jälkeen pyytää SRF:ää an-10 tamaan ääniviestejä loppukäyttäjille.

Muita älyverkon toiminnallisia olioita ovat erilaiset hallintaan liittyvät toiminnot, joita ovat SCEF (Service Creation Environment Function), SMF (Service Management Function) ja SMAF (Service Management Access Function). SMF käsittää mm. palvelujen hallinnan, SMAF tarjoaa liitynnän 15 SMF:ään ja SCEF mahdollistaa älyverkon palvelujen määrittelyn, kehityksen, testauksen ja syötön SMF:n kautta SCF:lle. Koska nämä toiminnot liittyvät ainoastaan verkon operaattorin toimintaan, ei niitä ole esitetty kuviossa 1.

Seuraavassa kuvataan vielä lyhyesti kuviossa 1 esitettyjen toiminnallisten olioiden roolia IN-palvelujen kannalta. CCAF vastaanottaa kutsuvan 20 osapuolen antaman palvelupyynnön, joka muodostuu tyypillisesti kuulokkeen nostosta ja/tai tietystä kutsuvan osapuolen valitsemasta numerosarjasta. CCAF välittää palvelupyynnön edelleen CCF/SSF:lle prosessointia varten. Puhelunohjaustoiminnolla CCF ei ole palvelutietoja, mutta se on ohjelmoitu . . tunnistamaan palvelupyyntöjen tarve. CCF keskeyttää puhelunmuodostuk- '· 25 sen hetkeksi ja ilmoittaa palvelun kytkentätoiminnolle SSF tiedon puhelun ti lasta. SSF:n tehtävänä on, käyttäen ennalta määrättyjä kriteerejä, tulkita palvelupyyntö ja näin ollen määrittää, onko kysymyksessä älyverkon palveluihin liittyvä palvelupyyntö. Mikäli näin on, SSF muodostaa standardoidun IN-pal-velupyynnön ja lähettää pyynnön SCF:lle yhdessä palvelupyynnön tilaa kos-30 kevan informaation kanssa. SCF vastaanottaa pyynnön ja dekoodaa sen. Tämän jälkeen se toimii yhdessä SSF/CCF:n, SRF:n ja SDF:n kanssa pyydetyn palvelun antamiseksi loppukäyttäjälle.

Älyverkon fyysisen tason arkkitehtuuri kuvaa sitä, kuinka edellä kuvatut toiminnalliset oliot sijoittuvat verkon fyysisiin olioihin. Älyverkon fyysistä 35 arkkitehtuuria on havainnollistettu kuviossa 2, jossa fyysiset oliot (physical entities) on kuvattu suorakaiteina tai ympyröinä ja toiminnalliset oliot ovaalei- 3 108495 na. Merkinantoyhteyksiä on kuvattu katkoviivoilla ja varsinaista hyötyliiken-nettä (transport), joka on esim. puhetta, yhtenäisillä viivoilla. Optionaalisia toiminnallisia olioita on merkitty katkoviivalla. Kuviossa esitetty signalointi-verkko on signalointijärjestelmän numero 7 mukainen verkko (SS7, Signal-5 ling System Number 7 on tunnettu signalointijärjestelmä, jota kuvataan C-CITT:n (nykyisin ITU-T) sinisessä kirjassa Specifications of Signalling System No. 7, Melbourne 1988).

Tilaajalaitteet SE (Subscriber Equipment), joita voivat olla esim. puhelin, tietokone tai telefax, kytkeytyvät joko suoraan palvelun kytkentäpis-10 teeseen SSP (Service Switching Point) tai verkkoliittymäpisteeseen NAP (Network Access Point).

Palvelun kytkentäpiste SSP tarjoaa käyttäjälle pääsyn verkkoon ja hoitaa kaikki tarvittavat valintatoiminnot. SSP pystyy myös havaitsemaan älyverkon palvelupyynnöt. Toiminnallisesti SSP sisältää puhelunhallinta- ja pal-15 velunvalintatoiminnot.

Verkkoliittymäpiste NAP on puhelunohjaustoiminteen CCF sisältävä perinteinen puhelinkeskus, esim. hakijan DX 220 -keskus, joka osaa erottaa älyverkon palveluja tarvitsevat puhelut perinteisistä puheluista ja reitittää älyverkon puheluja tarvitsevat puhelut asiaankuuluvalle SSPille.

20 Palvelun ohjauspiste SCP (Service Control Point) sisältää ne pal- velulogiikkaohjelmat (SLP, Service Logic Program), joita käytetään tuottamaan älyverkon palveluja. Palvelulogiikkaohjelmista käytetään jatkossa myös lyhyempää nimitystä palveluohjelma.

. . Palveludatapiste SDP (Service Data Point) on tietokanta, joka si- 25 sältää asiakkaan ja verkon dataa, jota SCP:n palveluohjelmat käyttävät tuottaakseen yksilöityjä palveluja. SCP voi käyttää SDP:n palveluja suoraan merkinanto- tai dataverkon välityksellä.

Älykäs oheislaite IP (Intelligent Peripheral) tarjoaa erityistoimintoja, kuten tiedonantoja sekä ääni- ja monivalintatunnistusta.

30 Palvelun kytkentä- ja ohjauspiste SSCP (Service Switching and

Control Point) koostuu SCP:stä ja SSP:stä yhdessä verkkoelementissä (eli jos kuviossa esitetyssä SSP-verkkoelementissä on sekä SCF- että SSF-oliot, on kysymyksessä SSCP).

Palvelun hallintapisteen SMP (Service Management System) tehtä-35 viin kuuluu tietokannan (SDP) hallinta, verkon valvonta ja testaus sekä verkkotietojen keräys. Se voi kytkeytyä kaikkiin muihin fyysisiin olioihin.

4 108495

Palvelun luontiympäristön pistettä SCEP (Service Creation Environment Point) käytetään älyverkon palvelujen määrittelyyn, kehittelyyn ja testaukseen ja syöttämään palvelut SMP:lle.

Palvelun liitännäisohjain AD (Adjunct) vastaa toiminnallisesti palv-5 elun ohjauspistettä SCP, mutta se on kytketty suoraan SSP:hen nopealla datayhteydellä (esim. ISDN 30B+D-liittymä), eikä yhteiskanavamerkinantoverkon SS No.7 kautta.

Palveluverkkoelementti SN (Service Node) voi ohjata älyverkon palveluja ja suorittaa tiedonsiirtoa käyttäjien kanssa. Se kommunikoi suoraan 10 yhden tai useamman SSP:n kanssa.

SMAP (Service Management Access Point) on fyysinen olio, joka tarjoaa tietyille käyttäjille yhteyden SMPrhen.

Edellä on lyhyesti kuvattu älyverkkoa taustaksi keksinnön mukaisen menetelmän kuvaukselle. Kiinnostunut lukija voi saada tarkemman käsi-15 tyksen älyverkosta esim. ITU-T:n suosituksista Q.121X tai Bellcoren AIN-suosituksista.

Älyverkkopohjaisia palveluja tulisi pystyä tarjoamaan kiinteiden verkkojen tai matkaviestinverkkojen tilaajille tavalla, joka mahdollistaa yksilöllisen palvelun tarjoamisen siten, että jokaiselle yksittäiselle tilaajalle voi-20 daan mahdollisimman helposti antaa tietty tilaajakohtainen yhdistelmä pal-veluominaisuuksia. Kaikki asiakkaille tai tilaajille tarjottavat palvelut koostuvat yhdestä tai useammasta palveluominaisuudesta (Service Feature, SF). Pal-veluominaisuus on (pienin) asiakkaalle tai tilaajalle näkyvä komponentti, . . josta hänen saamansa palvelu koostuu. Palveluominaisuudesta, josta käy- 25 tetään kansainvälisissä standardeissa em. nimitystä “service feature”, käytetään tässä esityksessä nimitystä alipalvelu.

Palvelujen suunnittelijoiden kannalta älyverkko on jaettu palvelu-riippumattomiin rakennusosiin (Service Independent Building Block), joista käytetään lyhennettä SIB. SIBit ovat niitä lohkoja, joista palvelun suunnitteli-30 jät kokoavat palveluominaisuuksia ja palveluja. Toisin sanoen, SIB on pienin ? lohko, josta palveluja ja palveluominaisuuksia kootaan. Palvelu koostuu useista palveluominaisuuksista ja palveluominaisuus puolestaan useista SIBeistä, joskin joissakin tapauksessa palveluominaisuus voi muodostua vain yhdestä SIBistä.

35 Kansainvälisissä standardeissa on määritelty niitä palveluriippu- mattomia lohkoja, joista palvelujen tulee koostua. Kun tilanne on lisäksi ollut 5 108495 sellainen, että verkko-operaattorit ovat mahdollisimman nopeasti halunneet uusia palveluja omiin verkkoihinsa, on ajateltu, että tästä tehtävästä selvitään parhaiten, kun varsinaiset palvelulogiikkaohjelmat toteutetaan moduuleina, jotka noudattavat standardeissa määriteltyä lohkojakoa. Näin ollen on pal-5 veluohjelmia ryhdytty toteuttamaan toiminnallisina lohkoina (moduuleina), jotka vastaavat mahdollisimman hyvin standardeissa määriteltyjä SIBejä.

Tällainen ratkaisu on kuitenkin osoittautunut vaikeaksi, koska lohkojen sisään joudutaan toteuttamaan myös paljon sellaista toiminnallisuutta, joka ei suoraan liity pelkkään tilaajan tarvitsemaan palvelulogiikkaan, vaan 10 joka palvelee verkkoelementin sisäistä toimintaa. Verkosta tulevien INAP-sanomien lisäksi joudutaan käyttämään muita, verkkoelementin sisäisiä sanomia, joilla siirretään sellaista tietoa, jotka eivät sisälly INAP-sanomiin, esim. verkkoelementin tietotaulujen parametrejä. Lisäksi palvelulogiikkaoh-jelmien ja verkkoelementin alustaohjelmiston välillä on voitava vaihtaa mm. 15 virhe- ja kuittaussanomia.

Nykytilanteessa on siten hankalaa luoda uusia räätälöityjä palveluja. Vaikeus korostuu entisestään, jos palveluja tarvitaan nopeasti esim. väliaikaiseen käyttöön.

20 Keksinnön yhteenveto

Keksinnön tarkoituksena on eliminoida edellä kuvattu epäkohta ja saada aikaan ratkaisu, jonka avulla palvelujen toteutus saadaan entistä yksinkertaisemmaksi ja nopeammaksi.

Tämä päämäärä saavutetaan keksinnön mukaisella menetelmällä, 25 joka on määritelty itsenäisessä patenttivaatimuksessa.

Keksinnön ajatuksena on käyttää kutakin eri tyyppistä, verkkoon lähetettävää sanomaa kohti omaa dedikoitua sanomanlähetys-SIBiä ja aina, kun lähetettävä sanoma on sellainen, että on odotettava siihen kuuluvaa vastetta ennen palvelulogiikan jatkamista, käytetään geneerisiä odotustila-30 SIBiä, joka vastaanottaa mainitun vasteen. Ajatuksena on siis jakaa verkon • * perustoimintoja uudella tavalla rakennusosiksi (SIBeiksi) ja lisäksi käyttää näitä rakennusosia siten, että tietyn tyyppisen sanoman lähettävää raken- * nusosaa seuraa aina tietyn tyyppinen rakennusosa (geneerinen odotustilara-kennusosa), jossa odotetaan kyseisen tyyppistä sanomaa verkosta.

35 Keksinnön mukaisen ratkaisun ansiosta palvelujen toteutukseen saadaan erittäin merkittävä helpotus, koska tilaajan tai asiakkaan tarvitsema 6 108495 palvelulogiikka pystytään selkeästi erottamaan verkkoelementin sisäisestä logiikasta ja tekemään verkkoelementin sisäinen logiikka läpinäkyväksi palvelun toteuttajan kannalta. Tämä johtuu siitä, että eri tyyppisten rakennusosien sisään ei enää tarvitse sijoittaa kaikkien mahdollisten vasteiden vaati-5 maa vastaanottologiikkaa silloin, kun rakennusosan sisällä jäädään odottamaan jotakin tiettyä verkosta tulevaa sanomaa.

Keksinnön mukaisen ratkaisun etuna on myös se, että operaattorit pystyvät helposti luomaan erilaisia palveluja esim. väliaikaiseen testikäyttöön palvelujen testaamiseksi esim. ennen kuin niille aletaan luoda hallintajärjes-10 telmää.

Kuvioluettelo

Seuraavassa keksintöä ja sen edullisia suoritusmuotoja kuvataan tarkemmin viitaten oheisten kuvioiden 3...13h mukaisiin esimerkkeihin ohei-15 sissa piirustuksissa, joissa kuvio 1 havainnollistaa älyverkon toiminnallista arkkitehtuuria, kuvio 2 havainnollistaa älyverkon fyysistä arkkitehtuuria, kuvio 3 havainnollistaa keksinnön mukaisen SCP-verkkoelementin toimin-20 nallista arkkitehtuuria, kun tarkastellaan palvelulogiikkaohjelmiston kannalta oleellisia osia, kuvio 4 havainnollistaa objektikohtaisen tietorivin sisältöä, kuvio 5 esittää palveluohjelmailmentymälle lähetettävän pyyntösänoman rakennetta, • 25 kuvio 6 esittää palveluohjelmailmentymän lähettämän kuittaussanoman ra kennetta, kuvio 7 havainnollistaa yhden palveluohjelman toiminnallista rakennetta, kuvio 8 havainnollistaa palveluohjelman sanomanlähetysrakemiusosaa (eli sanomanlähetys-SIBiä), 30 kuvio 9 havainnollistaa palveluohjelman odotustilarakennusosaa, kuvio 10 havainnollistaa kunkin alipalvelun lopussa olevaa pysähdystilara-kennusosaa, kuvioH havainnollistaa keksinnön erään edullisen toteutustavan mukaista alipalvelumoduulia, 35 kuvio 12 esittää keksinnön erään edullisen toteutustavan mukaista pysäh-dystilarakennusosaa, ja 7 108495 kuviot 13a...13h havainnollistavat keksinnön mukaisia rakennusosia graafisesti.

Keksinnön yksityiskohtainen kuvaus 5 Verkon tilaajan aloittaessa puhelun tilaajan päätekeskus vastaan ottaa ensin tiedon kutsuvan tilaajan halusta suorittaa puhelu. Tämä tieto voi tulla keskukselle esim. standardin Q.931 mukaisena Setup-sanomana. Jos päätekeskus ei ole SSP-keskus, se voi reitittää kutsuyrityksen SSP-keskuk-seen.

10 Kun SSP-keskuksen puhelun ohjauksessa havaitaan, että kysy myksessä on tilaaja, joka tarvitsee älyverkon palveluja, Hipaistaan ohjauksen siirto älyverkkoon ja “jäädytetään” puheluyrityksen prosessointi. SSP-keskus lähettää tällöin SCP:lle lnitial_DP-viestin, joka on standardeissa määritelty SSF:n ja SCP:n välinen viesti, jonka SSF generoi havaitessaan puhelumallin 15 missä tahansa ilmaisupisteessä palvelupyynnön tarpeelliseksi (ilmaisupiste, detection point, on puhelun tilamallissa sellainen kohta, josta voi tapahtua ohjauksen siirto älyverkkoon). lnitial_DP on siis se viesti, joka aloittaa SSP:n ja SCP:n välisen dialogin, joka liittyy kunkin palvelun tarjoamiseen. Viestin informaatioelementeiksi SSP-keskus sisällyttää ainakin kutsuvan ja kutsutun 20 numeron sekä palvelutunnisteen (Service Key).

SSP:n ja SCP:n välillä käytetään INAP-sanomajoukkoa (Intelligent Network Application Part). (Sanomajoukkoa kuvataan esim. standardissa ETSI IN CS1 INAP Part 1: Protocol Specification, Draft prETS 300 374-1, . . November 1993, josta kiinnostunut lukija löytää tarkemman kuvauksen.) • 25 Varsinaista protokollaa standardeissa ei ole määritelty, ainoastaan käytettä vät sanomat. Sanomiin on määritelty, paitsi optionaalisia parametrejä, myös ns. laajennusosaparametrejä. Varsinkin viimemainitut ovat sellaisia, joille eri operaattorit haluavat omia tietosisältömäärittelyjään. Tästä johtuen SCP-verkkoelementissä täytyy olla paljon erilaisia palvelulogiikkaohjelmia (SLP) 30 eri palvelujen toteuttamiseksi. Eri palvelulogiikkaohjelmat saattavat siis käyttää saman INAP-sanomajoukon sanomia, mutta eri järjestyksessä ja erilaisilla parametriarvoilla. Varsinaista protokollatasoa SSP:n ja SCP:n välisessä kommunikoinnissa edustavat siis nämä erilaiset palvelulogiikkaohjelmat. Kukin palvelulogiikkaohjelma lähettää verkkoon INAP-sanomia ja vas-35 taanottaa verkosta INAP-sanomia.

8 108495

Kuviossa 3 on havainnollistettu keksinnön mukaisen SCP-verkko-elementin toiminnallista arkkitehtuuria palveluohjelmien kannalta katsottuna. Verkkoelementtiin tulevat palvelupyynnöt tulevat yhteiskanavamerkinantopi-non CCSS kautta vastaanottavalle ohjelmalohkolle SRP (SS7 Receiver 5 Program). Tällaisia vastaanottavia ohjelmalohkoja on yksi jokaista SCP-verkkoelementin yhteiskanavamerkinantopinoa kohti. Kuvion esimerkissä on yksinkertaisuuden vuoksi esitetty vain yksi pino ja yksi vastaanottava ohjel-malohko.

Jos sama SCP-verkkoelementti on yhdistetty useampaan kuin yh-10 teen SSP-verkkoelementtiin, joissa käytetään INAP-sanomajoukon eri-ikäisiä versioita, on SCP:n vastaanottamien tietosanomien tietosisällön määrittely erilainen riippuen siitä, minkä SSP:n kanssa SCP keskustelee. Tästä johtuen on sanomien jatkokäsittely vastaanottavasta ohjelmalohkosta eteenpäin käytännössä eriytettävä sen mukaan, mikä INAP-sanomajoukko on kysymyk-15 sessä. Oleellista on siis myös se, että vastaanottava ohjelmalohko SRP on riippumaton käytetystä INAP-sanomajoukoista.

Vastaanottava ohjelmalohko SRP vastaanottaa verkosta (SSF olioilta) standardin mukaisia TC_BEGIN-sanomia. Ohjelmalohkon tehtävänä on tunnistaa TC_BEGIN-sanoman perusteella kyseessä oleva INAP-sano-20 majoukkoversio ja välittää komponenttiprimitiivien sisältämät INAP-sanomat edelleen kyseistä sanomajoukkoa vastaavalle sanomanjakeluohjelmalohkolle MDPi (Message Distributor Program), missä i=1,2,...j ja j on käytettyjen erilaisten INAP-sanomajoukkojen lukumäärä.

Vastaanottavaa ohjelmalohkoa seuraavalla tasolla verkkoelementin '? 25 arkkitehtuurissa ovat siis ohjelmalohkot MDPi (i=1,...,j), joita on yksi kutakin käytössä olevaa INAP-sanomajoukkoa kohti. Jokainen jakeluohjelma MDPi vastaanottaa verkosta TCAP-sanomia ja lähettää eteenpäin INAP-sanomia sekä ottaa vastaan palvelulogiikkaohjelmilta tulevia INAP-sanomia ja lähettää verkkoon päin TCAP-sanomia. (TCAP-sanoma koostuu otsikko-osasta ja 30 yhdestä tai useammasta komponenttiprimitiivistä. Kukin komponenttiprimitiivi : voi sisältää enintään yhden INAP-sanoman. Kullakin komponenttiprimitiivillä on myös oma aliotsikkonsa. Nämä kaikki otsikko-osat tehdään, kun lähetetään sanomia verkkoon ja ne poistetaan, kun vastaanotetaan sanomia verkosta.) 35 Kun verkkoelementtiin vastaanotetaan palveludialogin aloituspyyn- tö, joka tulee TC_BEGIN-primitiivinä (joka sisältää lnitial_DP-sanoman), luo- 9 108495 daan vastaanottavasta ohjelmasta SRP uusi ilmentymä, joka hakee oikean jakeluohjelmalohkon, luo siitä ilmentymän ko. palvelupyynnön käyttöön, ja välittää TCAP-sanoman ko. ilmentymälle. Tämän jälkeen vastaanottavan ohjelmalohkon ilmentymä häviää. Jakeluohjelmailmentymä vastaanottaa 5 kaikki sen jälkeen SSP:ltä tulevat TCAP-sanomat. Oikean jakeluohjelman haku tapahtuu siten, että vastaanottava ohjelmalohko SRP lukee TC_BEGIN-sanoman otsikosta joko lähettävän SSP-verkkoelementin tunnisteen (SPC, Signalling Point Code tai GT, Global Title) ja lisäksi alijärjestelmän tunnisteen SSN (Subsystem Number) tai vaihtoehtoisesti kyseessä 10 olevan sovelluskontekstitunnisteen AC (Application Context identifier) ja hakee näiden/tämän perusteella SRP-tason tietotaulusta SRP_DT sen jakeluohjelman nimen MDP_NAME, joka vastaa kysymyksessä olevaa INAP-sanomajoukkoa.

SCP-keskuksen arkkitehtuurissa on siis jokaista INAP-sanoma-15 joukkoa kohti oma ohjelmalohkonsa MDPi, jonka tehtävänä on dekoodata vastaanotetut sanomat (ainakin lnitial_DP-sanoma, joka sisältää Service Key -parametrin) ja jakaa sanomat niiden oikeille vastaanottajille.

Verkkoelementin toiminnallisessa hierarkiassa jakeluohjelmien jälkeen seuraavalla hierarkiatasolla ovat pääohjelmalohkot. Näitä pääohjelma-20 lohkoja on merkitty viitemerkillä FMPi (Feature Manager Program). Pääohjelmalohkot muodostavat ne prosessit, jotka ohjaavat varsinaisia palvelulo-giikkaohjelmia SLP syöttäen niille niiden tarvitsemat tiedot. Palvelujen ja ali-palvelujen hallinta on siis pääohjelmalohkojen vastuulla.

Sanomanjakeluohjelmat jakavat kunkin palvelupyynnön oikealle »·· 25 pääohjelmalohkolle. Tämän mahdollistamiseksi jakeluohjelmia varten on oma tietotaulunsa MDP_DT, jossa kunkin tietorivin alussa on hakuavaimena Service Key -arvo SK. InitialDP-sanomassa tulleen Service Key -arvon perusteella jakeluohjelmalohko hakee tietotaulusta oikean rivin, joitä se löytää sen pääohjelmalohkon tunnisteen (FMP_NAME), joka toimii vastaanottajana 30 kyseisen Service Key -arvon tapauksessa. Tietotaulu on edullisesti yhteinen ' ' ‘ kaikille jakeluohjelmalohkoille MDPi. Löydettyään oikean pääohjelmalohkon jakelulohkoilmentymä luo siitä ilmentymän ko. palvelupyynnön käyttöön ja välittää INAP-sanoman ko. ilmentymälle.

Koska palvelulogiikkatarpeet ovat erilaiset eri objektityypeille, SCP-35 verkkoelementti on edullista toteuttaa niin, että siinä on erilliset pääohjelma-lohkot SSP-keskusten sisältämiä, loogisesti erillisiä pääobjektiluokkia varten.

10 1 08495 Näitä luokkia voivat olla esim. kutsuvien tilaajien luokka, kutsuttujen tilaajien luokka, osoitetiet (destination eli valitun numeron alkuosa), tiet (subdestination eli valittu numero kokonaisuudessaan), suunnat (routes), väylät (circuit groups), jne. Lisäksi tilaajat voivat olla eri luokissa sen mukaan, mihin verk-5 koon he kuuluvat (esim. kiinteään verkkoon vai matkaviestinverkkoon). Objekteilla tarkoitetaan tässä yhteydessä siis sellaisia verkkoon liittyviä olioita, joiden yhteyteen voidaan verkkoelementissä, esim. älyverkon tapauksessa SSP-verkkoelementissä, liittää tieto, joka osoittaa yksittäisen kutsuyrityksen kohdalla, onko ko. kutsuyritystä varten lähetettävä palvelupyyntö palveluja 10 tarjoavalle verkkoelementille (joka on älyverkon tapauksessa SCP-verkko-elementti).

Kuten edellä mainittiin, kukin jakeluohjelmalohko käyttää hyväksi palvelupyyntösanomassa tullutta Service Key -parametriä vastaanottavan pääohjelmalohkon määrittämiseksi. Tämä tarkoittaa sitä, että tiettyyn pää-15 objektiluokkaan (esim. A-tilaajiin) liittyviin palvelupyyntöihin SSP-keskus joutuu asettamaan Service Key -arvon, joka on erilainen kuin johonkin toiseen luokkaan kuuluviin objekteihin (esim. B-tilaajiin) liittyviin palvelupyyntöihin asetettu Service Key -arvo (vaikka olisi kysymyksessä samantyyppinen palvelu). Tiettyä pääohjelmalohkoa voi vastata hyvin monta erilaista Service 20 Key -arvoa, mutta kahteen eri pääohjelmaan liittyvät Service Key -arvojoukot eivät saa mennä päällekkäin.

Kutakin pääobjektiluokkaa kohti on oma tietotaulunsa FMPi_DT (i=1,2,...n). Näitä tietotauluja kutsutaan jatkossa päätauluiksi. SCP:verkko-r elementissä on siis oma päätaulu kutakin pääohjelmalohkoa varten. Kussa- 25 kin päätaulussa on yksi tietorivi kutakin ko. luokkaan kuuluvaa objektia varten. Esim. A-tilaajiin liittyvän pääohjelmalohkon FMP1 käyttämässä tietotau-lussa FMP1_DT on siten yksi tietorivi kutakin A-tilaajaa Ai (i=1,2,...) kohti, B-tilaajiin liittyvän pääohjelman FMP2 käyttämässä tietotaulussa FMP2_DT yksi tietorivi kutakin B-tilaajaa Bi (i=1,2,...) kohti, tieobjekteihin liittyvän pääoh-30 jelman käyttämässä tietotaulussa yksi tietorivi kutakin käytössä olevaa tietä • ·' kohti, osoitetieobjekteihin liittyvän pääohjelman käyttämässä tietotaulussa yksi tietorivi kutakin käytössä olevaa osoitetietä kohti, jne.

Päätaulujen kullekin tietoriville on kuvion 4 esittämällä tavalla talletettu tietoa, joka määrittelee, minkälainen alipalvelukokoelma kyseisellä 35 objektilla on aktivoituna. Kunkin rivin R alkuun on hakuavaimeksi talletettu objektitunniste OI. Pääohjelmalohko hakee tietotaulustaan oikean rivin INAP- 11 1 08495 sanoman sisältämän objektitunnisteen arvon perusteella. Rivillä on peräkkäisiä alitietueita SR, yksi kutakin alipalvelua kohti. Jokaisen alitietueen alussa on alipalvelutunnisteen Fki (i=1,2,...) sisältävä kenttä FK, joka kertoo, mistä alipalvelusta on kysymys. Tämän jälkeen alitietueessa voi olla esim. status-5 kenttä ST, joka sisältää tiedon siitä, onko kyseinen alipalvelu aktiivinen vai passiivinen, ja prioriteettikenttä PR, joka sisältää prioriteettinumeron. Nämä alitietueiden prioriteettinumerot kertovat alipalvelujen keskinäisen suoritusjärjestyksen. Kussakin alitietueessa on lisäksi ainakin kenttä SLR, joka sisältää sen palvelulogiikkaohjelman tunnisteen, joka suorittaa kyseisen alipal-10 velun. Palvelulogiikkaohjelmat muodostavat verkkoelementin alimman hierarkiatason.

Kutakin pääobjektiluokkaa kohti on edullisesti omat palveluohjelmansa. Jokaisesta ohjelmasta on lisäksi oma klooninsa jokaista INAP-sano-majoukkoa kohti (eli jokaista jakeluohjelmaa kohti). Kuviossa on palveluoh-15 jelmia merkitty viitemerkillä SLPxy-z, missä x ilmaisee sen pääobjektiiuokan, jolle ohjelma kuuluu, y ilmaisee sen INAP-sanomajoukon, jolle ohjelma kuuluu ja z ilmaisee ohjelman järjestysnumeron pääobjektiiuokan sisällä.

Verkkoelementin hierarkian mukaisesti kutsutaan yhden palvelu-pyyntödialogin alimman tason ilmentymää (SLPi) lapseksi, seuraavan tason 20 ilmentymää (FMPi) isäksi ja sitä seuraavan tason ilmentymää (MDPi) isoisäksi. Vanhempi ilmentymä synnyttää aina nuoremman ilmentymän.

Käytännössä voi palvelulogiikkaohjelman toteuttama yksi alipalvelu olla esim. äänitiedotuksen esittäminen tilaajalle (“play an announcement”) tai . .. operaatio, jolla kutsuvaa tilaajaa pyydetään valitsemaan lisää numeroita 25 (“prompt and collect user information”), tai connect-operaatio (SSP-keskuk-seen lähetetään CONNECT-sanoma, jolla SSP-keskusta pyydetään kytkemään puhelu tiettyyn osoitteeseen).

Alipalvelujen suoritusjärjestys voidaan ilmoittaa esim. edellä mainitulla tavalla lisäämällä alitietueisiin kenttä PR prioriteettinumeroa varten, 30 jolloin ko. numerot kertovat alipalveluiden keskinäisen suoritusjärjestyksen.

• ·

Oikean suoritusjärjestyksen aikaansaamiseksi on muitakin vaihtoehtoja, kuten jäljempänä havaitaan. Tämä tapa on kuitenkin yksinkertainen ja mahdollistaa sen, että sama Service Key -arvo voi esim. kahdella eri A-tilaajalla merkitä erilaista suoritusjärjestystä.

35 Pääohjelmalohkoja varten on lisäksi yksi tai useampi erillinen tie- totaulu, jossa on tietorivi kullekin sellaiselle Service Key -arvolle, joka on 12 1 08495 käytössä usean eri pääohjelmalohkon alueella. Kuvion esimerkissä on yksi tietotaulu FMPJDT1, joka on yhteinen kaikille pääohjelmalohkoille (kaikki pääohjelmalohkot lukevat ko. tietotaulua). Tietotaulun kunkin tietorivin alussa on avaimena Service Key -arvo SK. Kullakin rivillä on tiedot niistä alipalve-5 luista Fki (i=1,2...), jotka liittyvät kyseiseen Service Key -arvoon, eli palveluista, jotka ovat sallittuja alipalveluja ko. Service Key -arvon tapauksessa. Lisäksi rivillä voi olla tieto siitä, missä järjestyksessä nämä alipalvelut suoritetaan, tai alipalvelutunnisteiden järjestys voi suoraan kertoa alipalveluiden keskinäisen järjestyksen. Pääohjelmalohko lukee tästä tietotaulusta rivin, jo-10 ka vastaa vastaanotettua Service Key -arvoa, jolloin se saa selville niiden alipalvelujen joukon, jotka ovat kyseisen arvon tapauksessa sallittuja alipalveluja. Tämän jälkeen pääohjelmalohko lukee dedikoidusta tietotaulustaan FMPi_DT (i=1,2,...) rivin, joka vastaa kyseisen objektin (esim. A-tilaajan) tunnistetta. Riviltä pääohjelmalohko saa selville sen palvelulogiikkaohjelman 15 SLPi (i=1,2,...) tunnisteen, joka pitää käynnistää. Luokkakohtaisen taulun FMPi_DT (esim. A-tilaajien taulun) riviltä pääohjelmalohko ottaa huomioon vain ne alipalvelut, jotka liittyvät ko. Service Key -arvoon (eli ne jotka kuuluvat edellä haettuun sallittuun joukkoon), ja näistäkin lopullisesti vain ne, jotka on merkitty ko. objektin kohdalla aktiivisiksi.

20 Tässä vaiheessa palvelupyynnön suoritusta ovat siis selvillä objek tiin liittyvät alipalvelut ja niiden keskinäinen suoritusjärjestys. Tämän jälkeen pääohjelmalohko synnyttää ensimmäisenä vuorossa olevaa alipalvelua vastaavasta palvelulogiikkaohjelmasta ilmentymän ja pyytää sitä aloittamaan , palvelun toteuttamisen.

25 FMP-ilmentymä lähettää siis lnitial_DP-sanoman sille palveluoh jelmalle, jonka prioriteetti oli korkein ja jonka tunnisteen pääohjelmalohko luki objektikohtaisen rivin ko. alitietueesta. Ensin ko. SLP-ilmentymälle lähetetään kuitenkin erillinen pyyntösanoma REQREC, koska lnitial_DP-sanoma on lähetettävä omassa standardin mukaisessa formaatissaan (ASN.1-30 formaatti), jossa sen informaatiosisältö ei ole riittävä. Palvelulogiikkaohjelma tarvitsee näin ollen INAP-sanomaan sisältyvien tietojen lisäksi muita tietoja, esim. alipalveiutunnisteen arvon, jotka se saa pyyntösanomassa.

Kuviossa 5 on esitetty esimerkki lähetettävän pyyntösanoman tietorakenteesta. Pyyntösanomassa on ensimmäisenä kenttä FMPJD1, joka si-35 sältää lähettävän FMP-ilmentymän tunnisteen. Tämän jälkeen on kenttä *../ RPJD, joka sisältää sen ohjelmalohkon tunnisteen, jolle SLP:n halutaan lä- 13 1 08495 hettävän tähän dialogiin liittyvät sanomansa. Nämä kuittaussanomat voidaan lähettää sekä FMP-ilmentymälle (isälle) että MDP-ilmentymälle (isoisälle). Lähettämällä kuittaussanomat jakeluohjelmailmentymälle voidaan vähentää pääohjelmalohkojen kuormitusta, koska MDP-instassi hoitaa joka tapaukses-5 sa verkkoon lähtevien sanomien lähetyksen. Seuraava kenttä LAST_REQ sisältää Boolen muuttujan, joka ilmaisee, onko SLP-ilmentymälle tulossa vielä uusi pyyntösanoman sen jälkeen, kun se on suorittanut ne alipalvelut, jotka pyydetään suorittamaan tässä pyyntösanomassa. Kenttä SK sisältää SSP-verkkoelementiltä tulleen Service Key -arvon. Tämän jälkeen tuleva 10 kenttä NoOfSFs kertoo pyyntösanoman sisältämien alipalveluiden lukumäärän, ja ko. kenttää seuraavat kentät Fki (i=1,2,...) sisältävät kyseessä olevien alipalveluiden tunnisteet. Viimeisenä oleva kenttä AT sisältää kuvauksen siitä, miten palveludialogi tulee terminoida, jos alipalvelujen suoritus epäonnistuu.

15 Palveluohjelmat ovat rakenteeltaan sellaisia, että ne koostuvat osista, joista kukin suorittaa tietyn alipalvelun. Tällöin kukin SLP suorittaa vain ne alipalvelut, joiden alipalvelutunnisteet tulevat pyyntösanomassa. Jos objektikohtaisella rivillä on aktiivisena useampi kuin yksi sellainen alipalvelu, joka kuuluu sallittujen alipalvelujen joukkoon ja kaikkiin kyseisiin alipalvelui-20 hin liittyy sama SLP-tunniste, FMP voi lähettää nämä kaikki alipalvelutunnisteet yhdessä pyyntösanomassa (olettaen, että on muuten sallittua suorittaa kaikki kyseiset alipalvelut peräkkäin). Jos alipalveluissa on useamman eri SLP-ohjelman tunniste, lähettää FMP-iimentymä pyyntösanomat kyseisille . -tt. SLP-ohjelmille siinä järjestyksessä, jonka objektikohtaisen rivin alitietueet il- · 25 moittavat. Voidaan myös toimia niin, että yhdessä pyyntösanomassa lähe tetään vain yhden alipalvelun tunniste.

Suoritettuaan alipalvelun SLP lähettää kuittaussanoman INFOREC

niille elementeille (isä ja/tai isoisä), jotka ilmoitetaan pyyntösanomassa REQREC. Kuittaussanomassa SLP-ilmentymä ilmaisee myös sen, mikä oli . . 30 alipalvelun loppumistapa. Jos esim. alipalvelun suoritus epäonnistuu, voi · seuraavaksi suoritettava alipalvelu olla erilainen verrattuna normaalitapaukseen, jossa alipalvelun suoritus onnistuu.

Kuviossa 6 on havainnollistettu SLP-ilmentymän lähettämän kuittaussanoman INFOREC erästä mahdollista rakennetta. Ensimmäinen kenttä 35 SLPJD2 kertoo lähettävän SLP-ilmentymän tunnisteen. Seuraava kenttä v.' WAIT sisältää mm. tiedon siitä, odotetaanko verkosta vastinetta ennen kuin 14 108495 palvelua voidaan jatkaa. Kenttä FLAG_D sisältää Boolen muuttujan, joka kertoo, terminoiko SLP-ilmentymä itsensä kuittaussanoman lähettämisen jälkeen vai ei. Kenttä LAST_REQ sisältää puolestaan saman tiedon, jonka lapsi on viimeksi saanut isältä kyseisessä kentässä (jolloin myös isoisä saa ko.

5 tiedon). Seuraavana tuleva kenttä LASTJNFO sisältää puolestaan Boolen muuttujan, joka indikoi, onko SLP-ilmentymä suorittanut viimeksi saamansa pyyntösanoman viimeisen alipalvelun loppuun. Seuraava kenttä Fk sisältää sen alipalvelun tunnisteen, johon kyseinen sanoma tulee kuittauksena. Kenttä CC sisältää juuri suoritetun alipalvelun loppukoodin. Kentässä ECC 10 voidaan kertoa sellaisista lievemmistä virhetapahtumista, joista ei tarvitse lähettää erillistä virheilmoitusta. Kenttä EndDIg sisältää tiedon siitä, millä tavalla kyseinen SLP-ilmentymä haluaa isoisänsä päättävän kyseisen dialogin. Dialogilla voi olla erilaisia lopetustapoja esim. sen mukaan, halutaanko verkkoon lähettää sanoma tai jos sanoma lähetetään, mitä tietoelementtejä si-15 säilytetään lähetettävään TC_END-primitiiviin.

Keksinnön edullisessa toteutustavassa kuittaussanomassa on lisäksi kenttä NFk, jossa voidaan ilmoittaa sen alipalvelun tunniste, joka tulisi suorittaa seuraavaksi. Tämä kenttä ja sen käyttö liittyy keksinnön erääseen edulliseen toteutustapaan, jota kuvataan jäljempänä.

20 Koska verkkoelementin sisäinen sanomanvaihto ei liity varsinai seen keksintöön, ei sitä kuvata tässä yhteydessä tarkemmin. Oleellista keksinnön kannalta on, että palveluohjelmailmentymät saavat sekä sisäisiä sanomia että verkosta tulevia sanomia (INAP-sanomia) ja että (sisäisillä) pyyntö- ja kuittaussanomilla hoidetaan alipalvelujen suoritusta ja ketjutusta ja 25 kuittaussanoman avulla voidaan lisäksi kertoa, miten alipalvelun suoritus onnistui ja mahdollisesti myös mikä alipalvelu halutaan suorittaa seuraavaksi.

Seuraavassa kuvataan yhden palvelulogiikkaohjelman SLPi periaatteellista rakennetta viitaten kuvioon 7. Kukin SLP muodostuu äloitustilara-kennusosasta (eli aloitustila-SIBistä) ISB (Initial State Block), yhdestä tai 30 useammasta alipalvelumoduulista FM (Feature Module) ja lopetustilaraken- • ·« nusosasta (lopetustila-SIBistä) ESB (End State Block). Alipalvelumoduuleja on tyypillisesti useita rinnakkaisia, mutta aloitustilarakennusosa ja lopetustila-rakennusosa ovat yhteisiä yhden palveluohjelman kaikille rinnakkaisille ali-palvelumoduuleille. Näistä rakennusosaista käytetään termiä tilaraken-35 nusosa, toisaalta koska ne sisältävät viiveellisen tilan, jossa odotetaan vas- • * *· <.

15 1 08495 tetta ulkopuolelta ja toisaalta koska palveluohjelmissa ei muualla ole näitä tällaisia viiveellisiä tiloja, joissa odotetaan jotakin tapahtumaa.

Kukin SLP alkaa geneerisellä aloitustilarakennusosalla ISB, jonka tehtävänä on vastaanottaa verkosta tuleva palveludialogin aloitussanoma ja 5 ohjata palvelun suoritus oikean alipalvelun alkuun. Lähettävä pääohjelma-lohko lähettää pyyntösanoman REQREC (joka sisältää edellä kuvatun mukaisesti mm. yhden tai useamman alipalvelutunnisteen Fk) ja siihen liittyvän varsinaisen (verkosta tulleen) INAP-sanoman perätysten. Tämän takia aloi-tusrakennusosassa on viiveellinen tila DS, jossa SLP-ilmentymä odottaa 10 pyyntösanoman jälkeen siihen liittyvää lnitial_DP-sanomaa. Kun lnitial_DP-sanoma saapuu, haarautuu ohjelman suoritus johonkin alipalvelumoduuliin FM sen mukaan, mikä on ensimmäisenä suoritettavan alipalvelun tunniste. Aloitustilarakennusosassa suoritetaan lisäksi erilaisia initialisointitehtäviä, jotka ovat samoja kaikille palveluohjelmille. Viiveellisen tilan DS alla tarvitaan 15 palvelulogiikassa lisäksi ainakin haara, jossa käsitellään mahdollisesti vastaanotettava aikavalvontasanoma, joka indikoi, että INAP-sanomaa on odotettu liian kauan ja haara, jossa käsitellään verkkoelementin sisäinen ter-minointisanoma, jolla palvelun suoritus lopetetaan esim. jonkin virheen seurauksena. Verkkoelementti voi myös vastaanottaa palvelun suorituksen ai-20 kana verkosta kyseiseen palveludialogiin liittyvän error-sanoman, jonka seurauksena palvelu on lopetettava. Edellä mainituissa poikkeustilanteissa siirrytään suoraan lopetustilarakennusosaan ESB.

Aloitustilarakennusosassa tapahtuvan InitialDP-sanoman vastaan-; oton jälkeen palvelu etenee johonkin alipalvelumoduuliin FM. Alipalvelun ··· 25 alussa on yleensä jokin toimintarakennusosa FB, jossa käsitellään aloitussa- nomassa ollutta tietoa.

Palvelulogiikan toteutuksessa käytetään omaa sanomanlähetysra-kennusosaa (sanomanlähetys-SIBiä) jokaista sellaista eri tyyppistä sanomaa kohti, joka lähetetään palveluohjelmasta verkkoon. Yleensä alipalvelun alus-30 sa olevaa toimintarakennusosaa seuraa yksi tai useampi tällainen sano- • ♦ manlähetysrakennusosa. Sanomanlähetysrakennusosia edeltävän toiminta-rakennusosan tarkoituksena on puolestaan saattaa valmiiksi ne tiedot, jotka asetetaan sanomien tietokenttiin sanomanlähetysrakennusosissa.

Mikäli jokin sanomanlähetysrakennusosista on sellainen, että ky-35 seiseen sanomatyyppiin odotetaan tiettyä vastetta, joka tulee kyseiseen sa-' nomaan aina virheettömän toiminnan yhteydessä, lisätään sanomanlähetys- 16 1 08495 rakennusosan perään geneerinen odotustilarakennusosa HSB (Hait State Block), jossa palvelulogiikka odottaa palvelulogiikan haluamaa vastetta (kyseisen tyyppistä INAP-sanomaa) verkosta. Geneerisyydellä tarkoitetaan sitä, että se koodi, jolla rakennusosa on toteutettu on samanlainen riippu-5 matta siitä, missä kohdassa palveluohjelmaa tai missä palveluohjelmassa rakennusosa sijaitsee. Ainoastaan rakennusosalle sisäänmenotietona annettava muuttuja, joka kertoo sen sanoman tyypin, jota odotetaan, on raken-nusosakohtainen, koska se riippuu siitä, minkä tyyppinen sanoma on edellä lähetetty verkkoon.

10 Osa lähetettävistä sanomista on sellaisia, että niihin tulee aina vastaussanoma normaalin (virheettömän) toiminnan yhteydessä ja vastausta on jäätävä odottamaan ennen palvelusuorituksen jatkamista. Tällaisia vastaussanomia kutsutaan jatkossa synkronisiksi vasteiksi. Osa lähetettävistä sanomista on puolestaan sellaisia, että palvelulogiikan suoritusta jatketaan il-15 man, että jäätäisiin odottamaan vastetta. Kun tällaiset vasteet tulevat verkosta SCP-verkkoelementtiin, palveluohjelma ottaa ne vastaan missä tahansa sopivassa viiveellisessä tilassa, vaikka se ei olekaan jäänyt odottamaan määrättyyn odotustilaan. Näitä vastaussanomia kutsutaan asynkronisiksi vasteiksi. Osa lähetettävistä sanomista on puolestaan sellaisia, että niihin ei 20 tule lainkaan vastaussanomaa. Asynkronisia vasteita ovat myös mm. verkosta tulevat error-sanomat, jotka voivat tulla koska tahansa ja lisäksi sellaiset sisäiset sanomat, jotka voivat tulla koska tahansa, esim. sisäiset ter-minointisanomat. Jokaisessa odotustilarakennusosailmentymässä ön kyky vastaanottaa odotuksen kuluessa mikä tahansa ennen synkronista vastetta 25 (mahdollisesti) tuleva asynkroninen vaste.

Kukin alipalvelumoduuli FM voi sisältää yhden tai useamman odo-tustiiarakennusosan (ja kussakin odotustilarakennusosassa voi olla yksi vii-veellinen tila, jossa odotetaan vastetta).

Odotustilarakennusosan jokainen ilmentymä pystyy siis vastaan-30 ottamaan kaikki mahdolliset sanomat, jotka voivat tulla odotustilan aikana.

• · Tämän johdosta palvelulogiikan on haarauduttava odotustilarakennusosan lopussa sen mukaan, minkä tyyppinen sanoma odotustilassa vastaanotettiin. Tämän johdosta on mahdollista käyttää jokaisessa tällaisessa vastaanotto-haarassa geneerisiä sanoman esikäsittelyrakennusosaa MB, joka sisältää 35 toiminnot, jotka siirtävät sanomassa tulleen tiedon palveluohjelman käyttöön. Toisin sanoen, esikäsittelyrakennusosassa siirretään sanomassa tulleiden 17 1 08495 parametrien arvot niitä vastaaville muuttujille. Tällaisia esikäsittelyraken-nusosia on yksi kutakin sanomatyyppiä kohti.

Kunkin alipalvelumoduulin FM lopussa on lisäksi aina erillinen py-sähdystilarakennusosa SSB (Stop State Block), joka merkitsee tietyn alipal-5 velun loppumista ennen seuraavan alipalvelun aloitusta tai ennen SLP-ilmentymän terminointia. Pysähdystilarakennusosasta lähetetään kuittaussanoma INFOREC alipalvelun suorittamisesta. Kuittaussanoman sisältämän loppukoodin Te (joka on kentässä CC) perusteella pääohjelmalohko voi esim. määrittää seuraavan alipalvelumoduulin ja lähettää pysähdystilaraken-10 nusosalle seuraavan pyyntösanoman REQREC, joka sisältää seuraavaksi suoritettavien alipalvelujen tunnisteet Fk (yksi tai useampi tunniste). Pysäh-dystilarakennusosan lopussa haarautumismuuttujana on siis (uusi) alipalve-lutunniste. Pysähdystilarakennusosa toimii siis palvelulogiikan kannalta kytkimenä, joka kytkee palvelun jatkumaan oikeasta alipalvelumoduulista.

15 Kun alipalveluja ei ole enää suoritettavana, eikä ole tarpeen odot taa asynkronisia vasteita, prosessi siirtyy geneeriseen lopetustilarakennus-osaan ESB, jossa voidaan lähettää sopivia loppusanomia verkkoon ja suorittaa mm. erilaisten laskurien talletusoperaatioita sekä terminoida SLP-ilmentymä. Lopetustilarakennusosaan kuuluvat ne lopetustoimenpiteet, jotka 20 ovat yhteisiä kaikille palveluille.

Erilaisten käytettävissä olevien loppukoodien määrä riippuu yleensä siitä, mikä alipalvelu on kysymyksessä. Yksinkertaisimmassa tapauksessa loppukoodeja voi olla vain kaksi kappaletta: alipalvelu suoritettu onnis-f tuneesti tai alipalvelun suorittaminen epäonnistunut. Jos alipalvelu on esim.

··. 25 kytkentä (connect), loppukoodeilla voidaan ilmaista esim. seuraavat neljä eri tapahtumaa: kutsuttu tilaaja vapaa, kutsuttu tilaaja varattu, kutsuttu tilaaja ei vastaa ja yhteyden muodostus epäonnistunut.

Kuviossa 8 on havainnollistettu yhden sanomanlähetysrakennus-osan TB rakennetta. Sanomanlähetysrakennusosassa annetaan aluksi arvo 30 parametrille PWAIT, jolla ilmoitetaan, odotetaanko lähetettyyn sanomaan synkronista vastetta (vaihe 80). Tämä parametri saa esim. arvon yksi, jos synkronista vastetta odotetaan ja arvon nolla muutoin. Tämän jälkeen asetetaan arvot lähtevän sanoman tietokenttiin (vaihe 81) ja sanoma lähetetään (vaihe 82). Kun sanoma on lähetetty, asetetaan odotettavia vasteita indikoi-35 ville kontrollimuuttujille oikeat arvot (vaihe 83). Viesti voi olla tyypiltään esim. puhelun laskutuksessa käytettävä ApplyCharging, jonka tunnuskoodinumero is 1 08495 on 35. Tähän viestiin odotetaan SSP:ltä ApplyChargingReport-viestiä, jonka tunnuskoodi on 36. Tällöin vaiheessa 83 asetetaan odotettavan sanoman tyyppiä indikoivan muuttujan arvoksi 36. Sanomanlähetysrakennusosia on yksi jokaista verkkoon lähetettävää sanomatyyppiä kohti eli käytännössä n.

5 15, joka on (standardeissa määriteltyjen) SCF:ltä SSF:lle lähetettävien sano- matyyppien lukumäärä.

Kuviossa 9 on havainnollistettu odotustilarakennusosan HSB toiminnallisuutta. Oleellista rakennusosan kannalta on em. seikkojen lisäksi se, että siihen voidaan sisällyttää sellaisia toimintoja, jotka ovat varsinaisen (eli 10 tilaajan tarvitseman) palvelulogiikan kannalta epäoleellisia. Näitä toimintoja ovat niiden tietosanomien lähetys ja vastaanotto, jotka eivät ole verkkosa-nomia (INAP-sanomia), vaan verkkoelementin sisäisiä sanomia, joilla hoidetaan esim. SCP-verkkoelementin sisällä suoritettavat aikavalvonnat (timeout) tai kuittaukset. Odotustilarakennusosassa on siis yksi tai useampi sisäi-15 sen sanoman lähetyslohko IMT, josta lähetetään verkkoelementin sisäinen sanoma ja ainakin yksi viiveellinen tila DS, jossa odotetaan synkronista vastetta (eli tiettyä INAP-sanomaa) (ja jota kutsutaan tämän takia synkroniseksi odotustilaksi). Viiveellisen tilan alla on lisäksi, kuten aikaisemminkin, ainakin haarat, joissa käsitellään (a) aikavalvontasanoma, joka indikoi, että viiveelli-20 sessä tilassa on odotettu liian kauan ja (b) verkkoelementin sisäinen ter-minointisanoma, jolla palvelun suoritus lopetetaan esim. jonkin virheen seurauksena. Mikäli vastaanotetaan sisäinen aikavalvonta- tai terminointisano-ma tai esim. verkosta tuleva error-sanoma, siirrytään suoraan lopetöstilara-kennusosaan ESB. Odotustilarakennusosan lopussa haarautumismuuttujana ··. 25 on siis vastaanotetun sanoman tyyppi.

Parametrin PWAIT arvo voidaan yhtä hyvin antaa myös odotustila-rakennusosassa.

Kuviossa 10 on havainnollistettu kunkin alipalvelumoduulin lopussa olevaa pysähdystilarakennusosaa SSB. Rakennusosan alussa (vaihe 101) 30 testataan, onko aiipalveluja vielä jäljellä eli onko alipalvelulaskurin CTR arvo • · · ' suurempi kuin nolla. Mikäli näin on, asetetaan ajastin, joka mittaa tiettyä ly hyttä aikaa (vaihe 102), lähetetään kuittaussanoma INFOREC (vaihe 104) ja siirrytään viiveelliseen tilaan DS odottamaan tulotapahtumaa.

Mikäli aiipalveluja ei enää ole jäljellä (CTR=0), lähetetään kuittaus-35 sanoma INFOREC (vaihe 103) ja siirrytään viiveelliseen tilaan DS odotta-'...· maan tulotapahtumaa.

19 1 08495

Vaiheessa 104 lähetettävä kuittaussanoma (kenttä Fk) kertoo pääohjelmalle, että palveluohjelmalla on vielä alipalveluja suoritettavanaan, jolloin pääohjelma ei lähetä palveluohjelmalle vastaussanomaa. Vastaavasti vaiheessa 103 lähetettävä kuittaussanoma kertoo, että palveluohjelmalla ei 5 ole enää alipalveluja suoritettavanaan.

Mikäli alipalveluja on vielä suoritettavana, tulotapahtumana on (sisäinen) sanoma, joka kertoo, että vaiheessa 102 asetettu ajastin on lauennut. Tällöin siirrytään seuraavan alipalvelutunnisteen ilmoittaman alipal-velun alkuun.

10 Jos pääohjelmalohkolta saadaan viiveellisessä tilassa uusi pyyntö- sanoma REQREC, päivitetään alipalvelulaskuria (vaihe 105), minkä jälkeen siirrytään suorittamaan uuden pyyntösanoman ilmoittamia alipalveluja. Kuten aikaisemminkin, viiveellisen tilan alla on lisäksi haarat, jotka on tarkoitettu mahdollisten aikavalvonta- ja terminointisanomien käsittelyyn.

15 Jos kaikkien alipalvelujen tunnisteet lähetetään jo ensimmäisessä pyyntösanomassa, pääohjelma lähettää vaiheesta 103 saamansa kuittauksen jälkeen terminointisanoman, jonka seurauksena palvelulogiikan suoritus siirtyy lopetustilarakennusosaan.

Mikäli kaikkien alipalvelujen tunnisteita ei lähetetä kerralla, vaan 20 esim. vain yksi tunniste pyyntösanomaa kohti, ja palvelussa on vielä alipalveluja suorittamatta, lähetetään vaiheen 103 kuittauksen jälkeen uusi pyyn-tösanoma, joka sisältää seuraavaksi suoritettavien alipalvelujen tunnisteet (yksi tai useampi).

Yhden tai useamman seuraavana suoritettavan alipalvelun löytä-·· 25 miseksi pääohjelmatasolla on käytössä myös toinen tietotaulu FMP_DT2 (kuvio 4), joka on yhteinen tietylle joukolle pääohjelmalohkoja. Tämä tieto-taulu osoittaa alipalvelujen keskinäisen vuorovaikutuksen. Tietotaulussa ovat alipalvelutunniste Fk ja loppukoodi Te ensisijaisina hakuavaiminä. Jokaista alipalvelu/loppukoodi -paria kohti taulukossa on mahdolliset alipalvelut. Toi-30 sin sanoen, taulukosta löytyy aina se joukko alipalveluja, jotka on mahdollista

»•I

! suorittaa seuraavana, kun suoritettu alipalvelu ja sen loppukoodi ovat tiedos sa. Kun taulukosta on löydetty niiden alipalvelujen joukko, jotka voivat seurata juuri suoritettua alipalvelua, valitaan näiden alipalvelujen joukosta seuraavaksi suoritettavaksi alipalveluksi se, jolla on objektikohtaisella tietorivillä 35 (tai tietotaulussa FMP_DT1) korkein prioriteetti. Kun tämä alipalvelu on suo-...· ritettu, saadaan kuittaussanomassa jälleen loppukoodi, jolloin sen ja alipal- 20 1 0 8 4 9 5 velutunnisteen avulla löydetään taas uusi alipaivelujoukko, josta valitaan seuraavaksi suoritettava alipalvelu objektikohtaisten tietojen perusteella.

Lähetettävien sanomien lukumäärän minimoimiseksi on edullista toimia siten, että yhdessä pyyntösanomassa voidaan lähettää useampia ali-5 palvelutunnisteita aina silloin, kun tiedetään, että kyseiset alipalvelut sopivat peräkkäin riippumatta siitä, mikä on niiden loppukoodi. Tällöin pääohjelma joutuu käymään läpi vielä suorittamattomat alipalvelut prioriteettijärjestykses-sä tarkastaakseen, että seuraava alipalvelu on sallittu edellisen alipalvelun kaikilla loppukoodeilla. Jos sen sijaan seuraavan alipalvelun sallittavuus riip-10 puu edellisen loppukoodista, on pääohjelman suoritettava edellä kuvatut tarkastus- ja valintatoimenpiteet ja lähetettävä niiden jälkeen uusi pyyntösano-ma.

Loppukoodin perusteella tietotaulusta voi myös löytyä ainoastaan sellaisia alipalveluja (yksi tai useampi), joita ei ole objektikohtaisella rivillä. 15 Tämä tapahtuu poikkeustilanteissa, kun loppukoodi osoittaa, että alipalvelun suoritus ei ole onnistunut normaalilla tavalla. Käytännössä voi esim. connect-alipalvelu seurata normaalitilanteessa, mutta jos esim. kutsuva tilaaja ei antanut tarpeeksi numeroita, voidaan suorittaa alipalvelu, jolla kutsuvaa tilaajaa pyydetään valitsemaan lisää numeroita tai jos loppukoodi osoittaa esim. että 20 valittua numeroa ei löydy, voidaan jatkaa äänitiedotus-alipalvelulla.

Yleisesti ottaen voidaan todeta, että alipalvelu (palveluominaisuus) toteutetaan peräkkäisillä rakennusosilla, joihin kuuluu aloitustilarakennusosa (vain 1. alipalvelun osalta), ensimmäinen lukumäärä toimintarakennusosia, . . toinen lukumäärä sanomanlähetysrakennusosia, kolmas lukumäärä odotus- * < • ' 25 tilarakennusosia, neljäs lukumäärä sanoman esikäsittelyrakennusosia sekä pysähdystilarakennusosa. Sanomanlähetys-, odotustila- ja esikäsittelyraken-nusosien lukumäärä voi olla myös nolla. Lopetustilarakennusosasta ESB ei enää voida palata samaan tai uuteen palveluominaisuuteen. Palvelu ei kuitenkaan välttämättä pääty, kun ensimmäisen kerran siirrytään lopetustilara-... 30 kennusosaan, sillä FMP pystyy synnyttämään uuden ilmentymän uudesta tai samasta SLP:stä, mikäli se on tarpeellista palvelun saattamiseksi loppuun.

Yksinkertaisimmassa tapauksessa alipalvelumoduulissa (eli alipal-velussa) on yksi toimintarakennusosa, yksi sanomanlähetysrakennusosa ja pysähdystilarakennusosa (ei odotustilarakennusosaa). Tällainen on tilanne 35 esim. jos SSP-keskuksesta tulee sellainen aloitussanoma, että SCP-verkko- • « 21 1 08495 elementin täytyy ainoastaan lähettää verkkoon CONNECT-tyyppinen sanoma (johon ei odoteta synkronista vastetta).

Edellä kuvattujen rakennusosien lisäksi palveluohjelmat voivat sisältää korkeintaan pieniä apu- tai erikoistoimintoja. Tällaisia aputoimintoja 5 varten voidaan määritellä erillinen apurakennusosien ryhmä. Apuraken-nusosat ovat siis sellaisia rakennusosia, jotka sisältävät vain hyvin pieniä toimintoja, esim. yksittäisen tiedon perusteella tapahtuvia haarautumisia palvelulogiikassa. Tällainen haarautuminen voidaan toteuttaa yhdellä haarau-tumiskäskyllä, jolloin ko. haarautumiskäskyn sisältävä rakennusosa on apu- 10 rakennusosa. Jäljempänä kuvataan eräs tähän ryhmää kuuluva palveluriip-pumaton rakennusosa, jonka avulla suoritetaan esim. virhetilanteessa hyppy suoraan alipalvelumoduulin loppuun. Tähän ryhmään voi myös kuulua esim. sellainen SIB, jolla verrataan tunnistetta (identifier) referenssiarvoon. Tällainen SIB on määritelty myös kansainvälisissä standardeissa.

15 Toimintarakennusosia voi käytännössä olla useita kymmeniä eri tyyppisiä, mutta ne ovat kuitenkin sellaisia, että niistä ei lähetetä sanomia verkkoon eikä vastaanoteta sanomia verkosta (kuten ei myöskään sisäisiä sanomia). Toimintarakennusosa voi olla esim. sellainen, joka lukee tietoa tietokannasta.

20 Keksinnön mukaisten tilarakennusosien avulla muodostetaan pal- veluriippumattomat rakennusosat aloitussanoman vastaanottoa varten (aloi-tustilarakennusosa), verkosta tulevien synkronisten vasteiden vastaanottoa varten (odotustilarakennusosa), alipalvelujen ketjutusta varten (pysähdystila-rakennusosa) ja palvelun niitä lopetustoimenpiteitä varten, jotka ovat samoja • ‘ 25 riippumatta siitä, mikä palvelulogiikkaohjelma on kysymyksessä (lopetustila- rakennusosa). Saman tyyppiset tilarakennusosat ovat samanlaisia kaikissa palveluohjelmissa. Myös palvelun päättävää lopetustilarakennusosaa kutsutaan tilarakennusosaksi, koska ko. rakennusosassa on lähetettävä purka-missanomia verkkoon ja odotettava (viiveellisessä tilassa) loppuvastetta ver- 30 kosta (Calllnformation Report, joka on sellainen sanoma, joka on pystyttävä ottamaan vastaan senkin jälkeen, kun verkkoon on lähetetty purkusanoma). Lopetustilarakennusosassa suoritetaan lopetustoimenpiteet myös siinä tapauksessa, että alipalvelumoduulin keskeltä hypätään suoraan lopetusraken-nusosaan päättämään palvelu.

35 Kaikkien mahdollisten verkkosanomien vastaanotto sisältyy aloitus- . tilarakennusosaan, odotustilarakennusosaan, pysähdystilarakennusosaan ja • 22 1 0 8 495 lopetustilarakennusosaan. Tarkemmin sanottuna, aloitussanoman vastaanotto sisältyy aloitustilarakennusosaan ja kaikkien muiden verkkosanomien vastaanotto muihin tilarakennusosiin. Synkronisten vasteiden vastaanotto sisältyy vain odotustilarakennusosaan. Edellä mainittuja neljää tilaraken-5 nusosaa lukuunottamatta viiveellisiä tiloja ei ole muualla, joten muihin palve-luriippumattomiin rakennusosiin ei tarvitse toteuttaa viiveellisiä tiloja eikä niihin liittyvää vastaanottologiikkaa.

Edellä on kuvattu palvelujen toteutusta siinä tapauksessa, että kaikki alipalvelut voidaan suorittaa ajallisesti välittömästi peräkkäin. Jotkut 10 palvelut ovat kuitenkin luonteeltaan sellaisia, että tämä ei ole mahdollista, vaan kahden peräkkäisen alipalvelun välissä on odotettava ennen kuin palvelun suorittamista voidaan jatkaa. Palvelu voi olla tällaista esim. sellaisille kutsuville tilaajille, jotka ovat tiliasiakkaita, jolloin puhelun kestäessä joudutaan välillä tarkistamaan tilin saldoa. Palvelun kuluessa voidaan myös joutua 15 odottamaan jotakin tapahtumaa, esim. sitä, että kutsuva tilaaja valitsisi lisää numeroita. Myös sen jälkeen, kun kaikki alipalvelut on suoritettu, voidaan SLP-ilmentymää joutua pitämään elossa sen takia, että on vielä odotettava jotakin asynkronista vastetta verkosta, esim. tietoa siitä, että kutsuva tilaaja on sulkenut puhelimen.

20 Tällaisen “joutoajan" kuluttaminen on edullista toteuttaa palvelulo giikassa omana alipalvelunaan, jotta se voitaisiin toteuttaa palvelusta riippumattomana rakennusosana. Keksinnön edullisen toteutustavan mukaisesti onkin jokaisessa palveluohjelmassa muiden alipalvelumoduulien lisäksi eri-. . tyinen alipalvelumoduuli tällaisen “joutoajan” kuluttamista varten. Tätä alipal- 25 velumoduulia kutsutaan tyhjäkäyntimoduuliksi.

Tyhjäkäyntimoduulin alussa on sellainen ilmentymä odotustilara-kennusosasta HSB, jossa tapahtuu asynkronisten vasteiden vastaanotto sellaisessa odotustilassa, jossa mitään tiettyä vastetta ei ole määritelty synkroniseksi vasteeksi (kuten muissa alipalvelumoduuleissa olevissa odotustila-30 rakennusosissa), vaan parametrillä, joka ilmaisee, mikä on odotetun sano-“ man tyyppi, on arvo nolla. Huomattakoon vielä, että asynkronisia vasteita on voitava ottaa vastaan odotustilarakennusosan kussakin ilmentymässä, koska odotustila saattaa olla niin pitkä, että sen kuluessa voi tulla asynkroninen vaste, esim. sellainen, joka osoittaa kutsuvan tilaajan lopettaneen puhelun.

35 Tyhjäkäyntimoduulissa on siis valmius ottaa vastaan kaikki mah- ; dolliset verkosta tulevat asynkroniset vasteet ja sen lisäksi sisäiset asynkro- « c , 23 1 0 8 4 9 5 niset vasteet, kuten ajastimien laukeamiset. Odotustilarakennusosasta palvelulogiikan on haarauduttava sen mukaan, mikä asynkroninen vaste saapuu. Asynkronisten vasteiden käsittely voitaisiin suorittaa tyhjäkäyntimoduu-lin sisällä, mutta on kuitenkin edullisempaa suorittaa käsittely tyhjäkäyntimo-5 duulin ulkopuolella erillisissä alipalvelumoduuleissa, joita on edullisesti yksi kutakin mahdollista asynkronista vastetta varten. Käsittely kannattaa tehdä tyhjäkäyntimoduulin ulkopuolella, koska asynkronisten vasteiden käsittely ei välttämättä ole samanlainen kaikissa palveluohjelmissa.

Keksinnön edullisessa lisätoteutustavassa onkin erityisiä poikkeus-10 rakennusosia, joiden avulla voidaan suorittaa hyppy alipalvelumoduulin loppuun ja sieltä edelleen halutun alipalvelumoduulin alkuun, jossa käsitellään saapunut asynkroninen vaste ja jonka lopusta voidaan tarvittaessa palata jälleen tyhjäkäyntimoduulin alkuun. Kutakin mahdollista asynkronista vastetta varten on oma poikkeusrakennusosailmentymänsä. Poikkeusrakennusosien 15 käytön etuna on se, että niiden avulla saadaan tyhjäkäyntimoduulin IFM koodi identtiseksi kaikissa palveluohjelmissa.

Kuviossa 11 on havainnollistettu poikkeusrakennusosilla EB varustetun tyhjäkäyntimoduulin IFM rakennetta. Odotustilarakennusosasta HSB’, jossa voidaan vastaanottaa kaikki mahdolliset asynkroniset vasteet, 20 haaraudutaan sanoman esikäsittelyrakennusosan MB jälkeen omaan poik-keusrakennusosailmentymään EB sen mukaan, mikä asynkroninen vaste on vastaanotettu. Kuten kuviossa on esitetty yhden poikkeusrakennusosan osalta, kussakin poikkeusrakennusosan ilmentymässä annetaan ensin arvot . . parametreille iERR ja NextFk ja hypätään sen jälkeen suoraan alipalvelumo- • < 25 duulin lopussa olevan pysähdystilarakennusosan SSB alkuun. Parametri iERR indikoi, onko palvelulogiikka kulkenut poikkeusrakennusosan kautta ja minkälainen poikkeustilanne on kysymyksessä. Parametri NextFk ilmoittaa puolestaan seuraavaksi toivotun alipalvelun tunnisteen.

Poikkeusrakennusosaa voidaan käyttää tyhjäkäyntimoduulin lisäksi ... 30 muissakin alipalvelumoduuleissa, jos palvelulogiikassa on haarauduttava poikkeustilanteeseen, esim. error-sanoman tullessa. Poikkeusrakennusosan avulla hoidetaan poikkeuskäsittely niin, että suoritetaan hyppy alipalvelumoduulin loppuun ja sieltä määrätyn alipalvelumoduulin alkuun.

Palveluohjelman tekijä antaa jokaiselle ilmentymälle, jossa poikke-35 usrakennusosa on, parametrinä sen tiedon, minkä alipalvelun alkuun on seu-. raavaksi siirryttävä.

24 1 08495

Jos käytetään edellä kuvatun kaltaisia poikkeusrakennusosia, py-sähdystilarakennusosaan SSB on lisätty testi, jossa testataan, tullaanko py-sähdystilarakennusosaan suoraan jostakin poikkeusrakennusosan ilmentymästä ja jos tullaan, millainen poikkeustilanne on kysymyksessä. Kuviossa 5 12 on havainnollistettu tällaista pysähdystilarakennusosaa, joka on muuten samanlainen kuin kuviossa 10 esitetty pysähdystilarakennusosa, mutta rakennusosan alkuun on lisätty vaiheet 98, 99 ja 100 ja pyyntösanoman vastaanoton jälkeen on lisätty vaiheet 105a ja 106. Rakennusosan alussa testataan ensin (vaihe 98), tullaanko pysähdystilarakennusosaan jostakin poik-10 keusrakennusosasta. Tämä voidaan tehdä niin, että parametrillä iERR on muuten arvo nolla, mutta poikkeustilarakennusosassa se saa jonkin nollaa suuremman arvon. Esimerkiksi arvolla yksi voidaan osoittaa, että on saatu jokin sellainen asynkroninen vaste, joka vaatii käsittelyä omassa alipalvelu-moduulissaan ja arvolla kaksi, että on saatu sellainen asynkroninen vaste 15 (esim. terminointisanoma), joka vaatii palvelun keskeyttämistä (siirtymistä lopetustilarakennusosaan). Vaiheessa 98 testataan näin ollen, onko parametrin iERR arvo pienempi tai yhtä suuri kuin nolla. Jos näin on (eli pysähdystilarakennusosaan ei ole tultu suoraan poikkeusrakennusosan ilmentymästä), alipalvelun suoritus etenee edellä kuvatulla tavalla. Jos parametrillä 20 on jokin nollaa suurempi arvo, siirrytään vaiheeseen 99, jossa testataan, onko parametrillä arvo, joka on pienempi tai yhtä suuri kuin yksi (eli onko arvo tasan yksi). Jos parametrille on edellä annettu arvo yksi, siirrytään vaiheeseen 100, jossa asetetaan kuittaussanoman kenttään NFk parametrin NextFk arvo ja siirrytään vaiheeseen 103, jossa lähetetään kuittaussanoma. 25 Jos parametrille iERR on annettu jokin ykköstä suurempi arvo, siirrytään suoraan lopetustilarakennusosaan ESB.

Jos pääohjelmalohko sallii kuittaussanoman sisältämän alipalvelun (NextFk) suorituksen seuraavana alipalveluna, se lähettää pyyntösanoman REQREC, joka sisältää kyseisen alipalvelutunnisteen.

30 Tilanteessa, jossa kaikki alipalvelut on suoritettu, pääohjelmalohko voi myös lähettää terminointisanoman sijasta pyyntösanoman, jossa ei ole yhtään alipalvelutunnistetta. Pyyntösanomasta tarkastetaan tällöin (vaihe 105a), sisältääkö se alipalvelutunnisteita. Jos näitä ei ole, tarkastetaan, onko vielä asynkronisia vasteita saapumatta verkosta (vaihe 106). Jos näin on, 35 siirrytään tyhjäkäyntimoduuliin odottamaan. Jos vasteita ei ole enää : ; “roikkumassa”, siirrytään lopetustilarakennusosaan.

25 108495

Palvelu lopetetaan (siirrytään lopetustilarakennusosaan) siis silloin, kun pysähdystilarakennusosassa ollaan tilanteessa, jossa (a) pääohjelma-lohko lähettää terminointisanoman tai (b) ei ole enää jäljellä alipalveluja eikä myöskään roikkuvia asynkronisia vasteita tai (c) jos saadaan sisäinen aika-5 valvontasanoma, joka kertoo, että viiveellisessä tilassa on odotettu liian kauan.

Seuraavaksi suoritettavaa alipalvelua ei tarvitse välttämättä määritellä kuittaussanomassa; jos esim. annetaan parametrille iERR arvo 2, palvelulogiikka etenee suoraan lopetustilarakennusosaan. Tällaisia arvoja käy-10 tetään tilanteissa, joissa odotustilarakennusosassa HSB’ saatu asynkroninen vaste on sellainen, että palvelun suoritus on lopetettava välittömästi.

Kukin palveluohjelma muodostetaan siis SIBeistä, jotka voidaan luokitella seuraaviin luokkiin sen mukaan, miten eri toiminnat on jaettu niiden kesken: 15 - tilarakennusosat ISB, HSB, SSB ja ESB, - sanomien sanomanlähetysrakennusosat TB, - vastaanotettavien sanomien esikäsittelyrakennusosat MB, - toimintorakennusosat FB, ja - apu-ja erikoisrakennusosat.

20 Kuvioissa 13a...13h on esitetty näitä rakennusosia yleisellä tasolla graafisesti samalla tavalla kuin rakennusosia kuvataan graafisesti kansainvälisissä standardeissa.

Kullakin SIBillä on tietyt sisäänmeno- ja ulostuloparametrit, jotka kuuluvat kolmeen luokkaan, joista käytetään lyhenteitä CID, SSD ja SID. 25 CID-parametrit (Call Instance Data) ovat dynaamisia parametrejä, jotka vaihtuvat puheluilmentymästä toiseen. SSD-parametrit (Service Support Data), jotka ovat niitä parametrejä, jotka ovat alipalvelukohtaisia. SID-parametrit (Service Instance Data) ovat puolestaan palvelun tilaajan profiiliin liittyviä parametrejä. Sisäänmeno- ja ulostuloparametrit on kuvattu raken-30 nusosan yläpuolella olevilla nuolilla. Tässä suhteessa mikään keksinnön mukainen rakennusosa ei poikkea standardien esittämästä yleisen tason SIB-kuvauksesta, vaan kaikkien rakennusosien sisäänmeno- ja ulostuloparametrit voivat kuulua yhteen tai useampaan edellä mainituista luokista.

Kullakin SIBillä on lisäksi yksi looginen aloituskohta ja n kappaletta 35 loogisia lopetuskohtia. Aloituskohtaa vastaavaa loogista sisäänmenovuota : esitetään rakennusosan vasemmalla puolella olevalla nuolella ja loogisia lo- 26 1 08495 petuskohtia vastaavia loogisia ulostulovoita oikealla puolella olevilla nuolilla. Tilarakennusosien osalta lopetuskohdat on kuvattu edellä, kuitenkin sillä poikkeuksella, että jokaisessa rakennusosassa (myös muissa kuin tilaraken-nusosissa) on edellä kuvattujen lopetuskohtien lisäksi yksi error-lopetus-5 kohta, joka edustaa rakennusosan sisällä tapahtunutta virhettä. Esim. odo-tustiiarakennusosassa HSB (kuvio 13b) on näin ollen lopetuskohdat, jotka vastaavat mainittua sisäistä virhettä, aikavalvontasanomaa, terminointisa-nomaa ja kutakin INAP-sanomatyyppiä. Sanomanlähetysrakennusosissa TB (kuvio 13e) ja esikäsittelyrakennusosissa MB (kuvio 13f) loogisten lopetus-10 kohtien lukumäärä n on kaksi (onnistunut suoritus ja epäonnistunut suoritus, joka vastaa em. error-lopetuskohtaa). Verkosta tulevan INAP-virhesanoman esikäsittelyrakennusosa muodostaa kuitenkin poikkeuksen muista esikäsit-telyrakennusosista siinä mielessä, että siinä on oma lopetuskohtansa kutakin virhetyyppiä kohti. Toimintorakennusosissa FB (kuvio 13g) sekä apu- ja eri-15 koisrakennusosissa (kuvion 13h) on yleisesti ottaen n kappaletta lopetus-kohtia.

Kukin SIB voi lisäksi vastaanottaa ja lähettää dataa toiselta palveluprosessilta. Tätä prosessien (SLP-ohjelmien) välistä kommunikointia (interprocess communication) kuvataan rakennusosan alapuolella olevilla nuolilla. 20 Tällaisen nuolen vastakkaisessa päässä oleva piste voi olla joko POI (point of initiation), POS (point of synchronization) tai POR (point of return). POI edustaa SIB-ketjujen loogista alkua, POS synkronointia ja POR SIB-ketjujen loogista terminointia. Keksinnön mukaisesti toteutetuissa palveluissa tämä kommunikointi on toteutettu kokonaisuudessaan tilarakennusosiin. Aloitusti- • 25 larakennusosa ISB (kuvio 13a) on itsessään POI, eikä rakennusosasta ole muunlaista prosessien välistä kommunikointia, odotustilarakennusosasta HSB (kuvio 13b) voi lähteä ja siihen voi tulla vain POS-nuoli, koska odotustilan sisällä on viiveelleen tila, jossa odotetaan vastetta ulkopuolelta, eikä sillä ole muuta prosessien välistä kommunikointia. Pysähdystilarakennusosasta 30 SSB (kuvio 13c) voi tulla ja mennä vain POS-nuoli, koska ko. rakennusosan sisällä voidaan pysähtyä odottamaan FMP:n suorittamia toimenpiteitä (nuolia on kuitenkin vain yksi, koska rakennusosasta lähetetään yksi kuittaussanoma ja siihen vastaanotetaan yksi pyyntösanoma). Lopetustilarakennusosasta ESB (kuvio 13d) on yksi lähtevä POR-nuoli, joka kuvaa palvelun päättymistä. 35 Lopetustilarakennusosasta voi lisäksi lähteä ja sinne voi mennä yksi tai use- • 27 1 0 8 4 9 5 ampi POS-nuoli, koska lopetustilarakennusosassa lähetetään purkamissa-nomia verkkoon ja odotetaan loppuvastetta verkosta.

Käytännössä uusia palveluohjelmia voidaan kehittää sinänsä tunnetulla tavalla käyttäen hyväksi korkean tason työkalua, jossa edellä kuvatun 5 kaltaisia palveluriippumattomia rakennusosia, jotka näkyvät ikoneina, yhdistetään graafisesti työaseman ruudulla.

Edellä on kuvattu keksinnön edullista toteutustapaa. On kuitenkin mahdollista toteuttaa palveluohjelmat myös niin, että ei käytetä alipalvelu-tunnisteita vastaavia moduuleja tai samanlaisia aloitus- ja pysäytystila-10 SIBejä, jotka muodostavat alipalvelutunnisteen perusteella toimivat kytkimet, jotka kytkevät logiikan suorituksen haluttuun moduuliin. Edellä kuvatun kaltaisten tila-SIBien avulla pystytään kuitenkin entistä paremmin saavuttamaan keksinnöt päämäärät.

Vaikka keksintöä on edellä selostettu viitaten oheisten piirustusten 15 mukaisiin esimerkkeihin, on selvää, ettei keksintö ole rajoittunut siihen, vaan sitä voidaan muunnella edellä ja oheisissa patenttivaatimuksissa esitetyn keksinnöllisen ajatuksen puitteissa. Keksinnön mukaista palvelujen toteutusta voidaan esim. soveltaa palvelujen toteuttamiseen riippumatta siitä, tehdäänkö tilaajakohtaisia palveluja tai onko palvelulogiikka sama tietylle ryh-20 mälle tilaajia tai jopa kaikille tilaajille. Kaikkia lähetys- ja vastaanottotoimintoja ei välttämättä tarvitse sijoittaa edellä kuvatulla tavalla keksinnön mukaisiin tilarakennusosiin joskin tällöin menetetään osa keksinnön eduista, koska osa toiminnoista on sijoitettava perinteisellä tavalla. Se verkkoelementin si-r säinen logiikka, joka toteutetaan odotustilarakennusosan sisään voi myös 25 vaihdella monin tavoin. Itse logiikka on sinänsä tunnettua, mutta toiminnallisten kokonaisuuksien sijoitus on (SIBien kannalta) aikaisemmasta poikkeava. Palveluohjelmia voi myös olla eri tyyppisissä verkkoelementeissä, esim. sellaisissa, jotka eivät suoraan vastaanota palvelupyyntöjä.

• •« ί :·:

Claims (15)

28 1 08 495

1. Menetelmä palvelun tarjoamiseksi tietoliikenneverkossa, erityisesti älyverkossa, jonka menetelmän mukaisesti - verkon ainakin yhteen verkkoelementtiin talletetaan palveluohjel-5 mia (SLP), ja - palvelu tarjotaan käynnistämällä halutun palvelulogiikan toteuttava palveluohjelma, tunnettu siitä, että verkkoelementin palveluohjelmat toteutetaan jakamalla toimintoja palveluriippumattomiin rakennusosiin (SIB, Service

2. Patenttivaatimuksen 1 mukainen menetelmä palvelujen tarjoa miseksi, tunnettu siitä, että odotustilarakennusosan (HSB) sisään toteutetaan lisäksi ainakin verkkoelementin sisäistä sanomanvaihtoa.

3. Patenttivaatimuksen 1 mukainen menetelmä palvelujen tarjoamiseksi, tunnettu siitä, että kaikkia eri sanomatyyppejä varten muodos- 25 tetaan oma dedikoitu sanomanlähetysrakennusosansa.

4. Patenttivaatimuksen 1 mukainen menetelmä palvelujen tarjoamiseksi, tunnettu siitä, että lisäksi käytetään erillistä aloitustilaraken-nusosaa (ISB) vastaanottamaan verkosta tuleva palvelun aloitussänoma.

5. Patenttivaatimuksen 4 mukainen menetelmä palvelujen tarjoa- 30 miseksi, tunnettu siitä, että lisäksi käytetään erillistä lopetustilaraken- nusosaa (ESB) lähettämään sellaiset palvelun purkuun liittyvät sanomat, jotka ovat riippumattomia siitä, mikä palvelu on kysymyksessä.

6. Patenttivaatimuksen 5 mukainen menetelmä palvelujen tarjoamiseksi, tunnettu siitä, että palveluohjelma toteutetaan siten, että siinä on 35 ainakin kaksi eri alipalvelun toteuttavaa rinnakkaista osaa (FM), joilla on yh- • 29 1 0 8 4 9 5 teinen aloitustilarakennusosa (ISB) ja yhteinen lopetustilarakennusosa (ESB).

7. Patenttivaatimuksen 6 mukainen menetelmä palvelujen tarjoamiseksi, tunnettu siitä, että jokaisen rinnakkaisen osan loppuun toteu- 5 tetaan erillinen pysähdystilarakennusosa (SSB) kytkemään logiikan suoritus seuraavan rinnakkaisen osan alkuun tai lopetustilarakennusosaan.

8. Patenttivaatimuksen 7 mukainen menetelmä palvelujen tarjoamiseksi, tunnettu siitä, että odotustilarakennusosan (HSB) sisään toteutetaan kaikkien mahdollisten odotustilan aikana verkosta vastaanotettavi- 10 en sanomatyyppien vastaanotto.

9. Patenttivaatimuksen 7 mukainen menetelmä palvelujen tarjoamiseksi, tunnettu siitä, että palvelujen kaikki sellaiset tilat, joissa odotetaan vastetta ulkopuolelta toteutetaan aloitustila-, odotustila-, pysähdystila- ja lopetustilarakennusosien sisään.

10. Patenttivaatimuksen 7 mukainen menetelmä palvelujen tarjoa miseksi, tunnettu siitä, että kussakin palveluohjelmassa on yksi rinnakkainen osa sellainen, että sen alussa on odotustilarakennusosa (HSB), jolloin palvelun suoritus voidaan siirtää väliaikaisesti odottamaan tähän osaan.

10 Independent Building Block) siten, että - kutakin palveluohjelmasta verkkoon päin lähetettävää yksittäistä sanomatyyppiä varten muodostetaan oma dedikoitu sanomanlähetysraken-nusosa (TB) ja sanomanlähetysrakennusosien avulla toteutetaan eri tyyppisten sanomien lähetykset verkkoon, ja 15. lähetyslohkon jälkeen palvelulogiikassa käytetään odotustilan (DS) sisältävää odotustilarakennusosaa (HSB) vastaanottamaan verkosta tuleva sanoma aina silloin, kun sanomanlähetysrakennusosan lähettämän sanoman tyyppi on sellainen, että siihen tulee virheettömän toiminnan tapauksessa tietyn tyyppinen vastaussanoma.

11. Patenttivaatimuksen 6 mukainen menetelmä palvelujen tarjoa- 20 miseksi, tunnettu siitä, että rinnakkaisissa osissa käytetään lisäksi erityistä poikkeusrakennusosaa suorittamaan hyppy sen rinnakkaisen osan lopussa olevan pysähdystilarakennusosan alkuun, jossa kyseinen poikkeusra-kennusosa on.

12. Patenttivaatimuksen 11 mukainen menetelmä palvelujen tar- 25 joamiseksi, tunnettu siitä, että poikkeusrakennusosassa annetaan myös tieto seuraavaksi suoritettavasta alipalvelusta.

13. Patenttivaatimuksen 10 mukainen menetelmä palvelujen tarjoamiseksi, tunnettu siitä, että alipalveluja toteuttavissa osissa käytetään lisäksi erillisiä sanoman esikäsittelyrakennusosia (MB) siirtämään vas- 30 taanotetussa sanomassa tullut informaatio palveluohjelman käyttöön.

14. Patenttivaatimuksen 13 mukainen menetelmä palvelujen tarjoamiseksi, tunnettu siitä, että odotustilarakennusosan jälkeen käytetään sanoman esikäsittelyrakennusosia siirtämään ainakin osassa mahdollisista sanomista tullut informaatio palveluohjelman käyttöön. • • V I ·. 30 1 0 8 4 9 5

15. Patenttivaatimuksen 11 mukainen menetelmä palvelujen tarjoamiseksi, tunnettu siitä, että mainittu yksi alipalvelun toteuttava osa on sellainen, että odotustilarakennusosan jälkeen käytetään sanoman esikäsit-telyrakennusosia jokaisessa mahdollisessa sanomassa tulevan informaation 5 tallettamiseen. f # r • ' • V '. 31 1 08495