FI108325B - Palvelujen tarjoaminen tietoliikenneverkossa - Google Patents

Description

1 108325

Palvelujen tarjoaminen tietoliikenneverkossa

Keksinnön ala

Keksintö liittyy yleisesti palvelujen tarjoamiseen tietoliikenneverkos-5 sa, 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-toiminto (Call Control Agent Function). IN-palveluihin pääsy toteutetaan olemassaole-. . viin digitaalisiin keskuksiin tehtävillä lisäyksillä. Tämä tehdään käyttämällä hy- 20 väksi yleistä puhelun tilamallia BCSM (Basic Call State Model), joka kuvaa sitä · olemassaolevaa toiminnallisuutta, jolla kahden käyttäjän välinen puhelu pro- '« ' sessoidaan. BCSM on korkean tason tila-automaattlkuvaus niistä puhelinoh- jaustoiminnon (CCF, Call Control Function) toiminnoista, joita tarvitaan käyttäjien välisen yhteysreitin pystyttämiseen ja ylläpitoon. Tähän tilamalliin lisätään :Y 25 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 Control Function) palvelusidonnaisesta • · !.! 30 (puheluyrityksen) käsittelystä. Palvelun kytkentätoiminto SSF liittää siis puhe- . lunohjaustoiminnon CCF (Call Control Function) palvelun ohjaustoimintoon ·.’ SCF (Service Control Function) ja sallii palvelun ohjaustoiminnon SCF ohjata

Y‘ puhelunohjausta CCF. SCF voi esim. pyytää, että SSF/CCF suorittaa määrätty tyjä puhelu- tai yhteystoimintoja, esim. laskutus- tai reititystoimenpiteitä. SCF

35 voi myös lähettää pyyntöjä palveludatatoiminnolle SDF (Service Data Function), joka huolehtii pääsystä älyverkon palvelusidonnaisiin tietoihin ja verkko- 2 108325 tietoihin. 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 SRF (Specialized Resources Function), joka tarjoaa sellaisia erikoiskeinoja, 5 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ää $RF:ää antamaan ääni-viestejä loppukäyttäjille.

10 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 SMFiään ja SCEF mahdollistaa älyverkon palvelujen määrittelyn, kehityksen, 15 testauksen ja syötön SMF:n kautta SCF.IIe. 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 osapuolen antaman palvelupyynnön, joka muodostuu tyypillisesti kuulokkeen nos-: 20 tosta ja/tai tietystä kutsuvan osapuolen valitsemasta numerosarjasta. CCAF

, välittää palvelupyynnön edelleen CCF/SSF:lle prosessointia varten. Puhelun- ' · ' ohjaustoiminnolla CCF ei ole palvelutietoja, mutta se on ohjelmoitu tunnista- :. maan palvelupyyntöjen tarve. CCF keskeyttää puhelunmuodostuksen hetkeksi ja ilmoittaa palvelun kytkentätoiminnolle SSF tiedon puhelun tilasta. SSF:n teh-i V 25 tä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-palvelupyynnön ja lähettää pyynnön SCF.IIe yhdessä palvelupyynnön tilaa koskevan informaation ,·.· kanssa. SCF vastaanottaa pyynnön ja dekoodaa sen. Tämän jälkeen se toimii » · *.! 30 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ä ku- vatut toiminnalliset oliot sijoittuvat verkon fyysisiin olioihin. Älyverkon fyysistä : v' arkkitehtuuria on havainnollistettu kuviossa 2, jossa fyysiset oliot (physical enti- 35 ties) on kuvattu suorakaiteina tai ympyröinä ja toiminnalliset oliot ovaaleina.

*** Merkinantoyhteyksiä on kuvattu katkoviivoilla ja varsinaista hyötyliikennettä 3 108325 (transport), joka on esim. puhetta, yhtenäisillä viivoilla. Optionaalisia toiminnallisia olioita on merkitty katkoviivalla. Kuviossa esitetty signalointiverkko on signalointijärjestelmän numero 7 mukainen verkko (SS7, Signalling System Number 7 on tunnettu signalointijärjestelmä, jota kuvataan CClTT.n (nykyisin 5 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äpisteeseen SSP (Service Switching Point) tai verkkoliittymäpisteeseen NAP (Net-10 work 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 palve-lunvalintatoiminnot.

15 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.

Palvelun ohjauspiste SCP (Service Control Point) sisältää ne palve-: 20 lulogiikkaohjelmat (SLP, Service Logic Program), joita käytetään tuottamaan :t · älyverkon palveluja. Palvelulogiikkaohjelmista käytetään jatkossa myös lyhy- • t ' ’ empää nimitystä palveluohjelma.

Palveludatapiste SDP (Service Data Point) on tietokanta, joka sisäl- :, tää asiakkaan ja verkon dataa, jota SCP:n palveluohjelmat käyttävät tuottaak- :V 25 seen yksilöityjä palveluja. SCP voi käyttää SDP:n palveluja suoraan merkin anto- tai dataverkon välityksellä.

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

.·.· Palvelun kytkentä- ja ohjauspiste SSCP (Service Switching and • u !.* 30 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ä- : v* viin kuuluu tietokannan (SDP) hallinta, verkon valvonta ja testaus sekä verkko- • \.! 35 tietojen keräys. Se voi kytkeytyä kaikkiin muihin fyysisiin olioihin.

4 108325

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 yh-10 den tai useamman SSP:n kanssa.

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

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

Älyverkkopohjaisia palveluja tulisi pystyä tarjoamaan kiinteiden verkkojen tai matkaviestinverkkojen tilaajille tavalla, joka mahdollistaa yksilöllisen palvelun tarjoamisen siten, että jokaiselle yksittäiselle tilaajalle voidaan antaa 20 tietty tilaajakohtainen yhdistelmä palvelupiirteitä. Kuten edellä esitettiin, palve-: lun tarjoaminen käynnistyy siten, että SSF lähettää SCFMIe standardin mukai sen IN-palveiupyynnön. Palvelupyyntö voidaan lähettää tietyissä vaiheissa pu-helunmuodostusta. SSF:n lähettämää palvelupyyntöä varten on kansainväli-‘:'; sissä standardeissa määritelty kuitenkin vain yksi tunniste, jonka avulla haluttu .· .·. 25 palvelulogiikka voidaan valita SCF:ssä. Tätä tunnistetta kutsutaan nimellä Ser vice Key.

Yleisesti tunnettu tekniikka yksilöllisten palvelujen aikaansaamiseksi on sellainen, että Service Key -arvon avulla valitaan SCF:ssä lopullinen pal-velulogiikkaohjelma (SLP), jolloin useampi arvo voi osoittaa samaan palvelulo-30 giikkaohjelmaan tai kutakin käytettyä Service Key -arvoa kohti voi olla dedi-koitu palvelulogiikkaohjelma. Kun palveluja halutaan lisätä, olemassa olevasta palveluohjelmasta tehdään uusi versio, jonka sisään on koodattu lisää palve-. ··. luominaisuuksia. Uusi versio indikoidaan uudella Service Key -arvolla. Palve- luominaisuudesta, josta käytetään kansainvälisissä standardeissa englannin-: ·' 35 kielistä nimitystä service feature, käytetään tässä esityksessä nimitystä alipal- velu.

5 108325 Tällaisen ratkaisun epäkohtana on se, että palvelujen ja niiden sisältämien piirteiden lisääntyessä palveluohjelmat tulevat hyvin monimutkaisiksi ja niiden määrä kasvaa. Kun tällaisia laajoja ohjelmia, joista on lisäksi erilaisia versioita, joudutaan sijoittamaan verkon useisiin verkkoelementteihin, tulee 5 myös verkon ylläpito monimutkaiseksi.

Keksinnön yhteenveto

Keksinnön tarkoituksena on tuoda parannus edellä kuvattuun tilanteeseen ja saada aikaan ratkaisu, jonka avulla uusien palvelujen lisäys ja ver-10 kon tarjoamien palvelujen ylläpito on mahdollisimman yksinkertaista ja jousta vaa.

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

Keksinnön ajatuksena on käyttää alipalvelut identifioivia tunnisteita ja 15 muodostaa palveluohjelmat alipalvelukohtaisista moduuleista siten, että tietyn alipalvelutunnisteen avulla suoritetaan ko. tunnistetta vastaava osa palveluohjelmasta ja koko palvelu tarjotaan ketjuttamalla halutut alipalvelumoduulit alipalvelutunnisteiden avulla peräkkäin. SCP-verkkoelementtiin talletetaan kunkin alipalvelun yhteyteen tieto siitä, mikä palveluohjelma kykenee suorittamaan 20 kyseisen alipalvelun ja palvelupyyntösanomassa tulevan palvelutunnisteen avulla määritetään haluttujen alipalvelujen joukko, jolloin palvelu voidaan tar-:.' ; jota suorittamalla tietyssä peräkkäisjärjestyksessä kyseisiä alipalveluja vastaa- :' ’ ’: vat osat yhdestä tai useammasta palveluohjelmasta.

Keksinnön mukaisen ratkaisun ansiosta alipalvelujen vaatima ohjel-25 makoodi voidaan sijoitella hyvin vapaasti yhteen tai useampaan palvelulogiik-kaohjelmaan. Yksi palvelulogiikkaohjelma sisältää edullisesti useamman alipalvelun suorittamiseen tarvittavan koodin, joskin se voi sisältää vain yhden alipalvelun vaatiman koodin. Joitakin Service Key -arvoja vastaavat palvelut . . voidaan sijoittaa tiettyyn SCP-verkkoelementtiin ja joitakin muita arvoja vas- .‘5; 30 taavat palvelut johonkin toiseen SCP-verkkoelementtiin. Jakamalla palvelun alipalvelut vaikkapa kahden eri SCP-verkkoelementin kesken ei kumpaankaan . ·. - verkkoelementtiin tarvitse sijoittaa verkon resurssien tai suorituskyvyn kannalta tarpeettoman laajaa palvelulogiikkaohjelmaa. Näin ollen minkään SCP-.. Y verkkoelementin ei tarvitse sisältää kaikkia mahdollisia palveluja tai alipalvelu- : 35 ja, vaikka ne ovatkin kaikkien tilaajien käytettävissä.

6 108325

Keksinnön mukainen ratkaisu mahdollistaa myös verkon ylläpidon kannalta yksinkertaisen tavan tarjota sellaisia uusia palveluja, jotka koostuvat tilaajakohtaisista alipalveluyhdistelmistä.

5 Kuvioluettelo

Seuraavassa keksintöä ja sen edullisia suoritusmuotoja kuvataan tarkemmin viitaten oheisten kuvioiden 3...12 mukaisiin esimerkkeihin oheisissa piirustuksissa, joissa 10 kuvio 1 havainnollistaa älyverkon toiminnallista arkkitehtuuria, kuvio 2 havainnollistaa älyverkon fyysistä arkkitehtuuria, kuvio 3 havainnollistaa keksinnön mukaisen SCP-verkkoelementin toiminnallista arkkitehtuuria, kun tarkastellaan palvelulogiikkaohjelmiston kannalta oleellisia osia, 15 kuvio 4 havainnollistaa objektikohtaisen tietorivin sisältöä, kuvio 5 esittää palveluohjelmailmentymälle lähetettävän pyyntösanoman rakennetta, kuvio 6 esittää palveluohjelmailmentymän lähettämän kuittaussanoman rakennetta, 20 kuvio 7 havainnollistaa yhden palveluohjelman toiminnallista rakennetta, : \ kuvio 8 havainnollistaa palveluohjelman sanomanlähetysrakennusosaa (eli sanomanlähetys-SIBiä), kuvio 9 havainnollistaa palveluohjelman odotustilarakennusosaa, kuvio 10 havainnollistaa kunkin alipalvelun lopussa olevaa pysähdystilaraken-25 nusosaa, kuvio 11 havainnollistaa keksinnön erään edullisen toteutustavan mukaista alipalvelumoduulia, ja kuvio 12 esittää keksinnön erään edullisen toteutustavan mukaista pysähdys-tilarakennusosaa.

V!:' 30

Keksinnön yksityiskohtainen kuvaus

Verkon tilaajan aloittaessa puhelun tilaajan päätekeskus vastaanot-.“· taa ensin tiedon kutsuvan tilaajan halusta suorittaa puhelu. Tämä tieto voi tulla , ·/ keskukselle esim. standardin Q.931 mukaisena Setup-sanomana. Jos pääte- ' 35 keskus ei ole SSP-keskus, se voi reitittää kutsuyrityksen SSP-keskukseen.

7 108325

Kun SSP-keskuksen puhelun ohjauksessa havaitaan, että kysymyksessä 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 I n itiä l_D P-viesti n, joka on standardeissa määritelty SSF:n ja 5 SCP:n välinen viesti, jonka SSF generoi havaitessaan puhelumallin 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 informaatio-10 elementeiksi SSP-keskus sisällyttää ainakin kutsuvan ja kutsutun 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 15 1993, josta kiinnostunut lukija löytää tarkemman kuvauksen.) Varsinaista pro tokollaa standardeissa ei ole määritelty, ainoastaan käytettävät sanomat. Sanomiin on määritelty, paitsi optionaalisia parametrejä, myös ns. laajen-nusosaparametrejä. Varsinkin viimemainitut ovat sellaisia, joille eri operaattorit haluavat omia tietosisältömäärittelyjään. Tästä johtuen SCP-verkkoelemen-20 tissä täytyy olla paljon erilaisia palvelulogiikkaohjelmia (SLP) 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 palvelulogiikkaoh-. . 25 jelma lähettää verkkoon INAP-sanomia ja vastaanottaa verkosta INAP-sano- mia.

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

Jos sama SCP-verkkoelementti on yhdistetty useampaan kuin yh-i ’·· 35 teen SSP-verkkoelementtiin, joissa käytetään INAP-sanomajoukon eri-ikäisiä :...· versioita, on SCP:n vastaanottamien tietosanomien tietosisällön määrittely 8 108325 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 kysymyksessä. Oleellista on siis myös se, että vastaanottava ohjelmalohko SRP on riip-5 pumaton 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-sanoma-joukkoversio ja välittää komponenttiprimitiivien sisältämät INAP-sanomat edel-10 leen 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 seuraavaila tasolla verkkoelementin arkkitehtuurissa ovat siis ohjelmalohkot MDPi (i=1,...,j), joita on yksi kutakin 15 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 yhdestä tai useammasta komponenttiprimitiivistä. Kukin komponenttiprimitiivi voi 20 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.)

Kun verkkoelementtiin vastaanotetaan palveludialogin aloituspyyntö, joka tulee TC_BEGIN-primitiivinä (joka sisältää lnitial_DP-sanoman), luodaan 25 vastaanottavasta ohjelmasta SRP uusi ilmentymä, joka hakee oikean jake-luohjelmalohkon, 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 kaikki sen jäl- . . keen SSP:ltä tulevat TCAP-sanomat. Oikean jakeluohjelman haku tapahtuu • · 30 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ä olevan sovelluskonteksti- tunnisteen AC (Application Context identifier) ja hakee näiden/tämän perus-: · 35 teella SRP-tason tietotaulusta SRP_DT sen jakeluohjelman nimen ' · ·.' MDP_NAME, joka vastaa kysymyksessä olevaa INAP-sanomajoukkoa.

9 108325 SCP-keskuksen arkkitehtuurissa on siis jokaista INAP-sanomajouk-koa 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.

5 Verkkoelementin toiminnallisessa hierarkiassa jakeluohjelmien jäl keen seuraavalla hierarkiatasolla ovat pääohjelmalohkot. Näitä pääohjelma-lohkoja on merkitty viitemerkillä FMPi (Feature Manager Program). Pääohjelmalohkot muodostavat ne prosessit, jotka ohjaavat varsinaisia palvelulogiikka-ohjelmia SLP syöttäen niille niiden tarvitsemat tiedot. Palvelujen ja alipalvelu-10 jen hallinta on siis pääohjelmalohkojen vastuulla.

Sanomanjakeluohjelmat jakavat kunkin palvelupyynnön oikealle 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 15 jakeluohjelmalohko hakee tietotaulusta oikean rivin, jolta se löytää sen pää-ohjelmalohkon tunnisteen (FMP_NAME), joka toimii vastaanottajana kyseisen Service Key -arvon tapauksessa. Tietotaulu on edullisesti yhteinen kaikille ja-keluohjelmalohkoille MDPi. Löydettyään oikean pääohjelmalohkon jakeluloh-koilmentymä luo siitä ilmentymän ko. palvelupyynnön käyttöön ja välittää 20 INAP-sanoman ko. ilmentymälle.

Koska palvelulogiikkatarpeet ovat erilaiset eri objektityypeille, SCP-verkkoelementti on edullista toteuttaa niin, että siinä on erilliset pääohjelmalohkot SSP-keskusten sisältämiä, loogisesti erillisiä pääobjektiluokkiä varten. Näitä luokkia voivat olla esim. kutsuvien tilaajien luokka, kutsuttujen tilaajien .y 25 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 verkkoon he kuuluvat (esim. kiinteään verkkoon vai matkaviestinverkkoon). Objekteilla tarkoitetaan tässä yhteydessä siis sellaisia verkkoon liittyviä olioita, *·*· 30 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 tarjoavalle verkkoelementille (joka on älyverkon tapauksessa SCP-verkkoele-'·'· mentti).

: · 35 Kuten edellä mainittiin, kukin jakeluohjelmalohko käyttää hyväksi :. v palvelupyyntösanomassa tullutta Service Key -parametriä vastaanottavan pää- 10 1 08325 ohjelmalohkon määrittämiseksi. Tämä tarkoittaa sitä, että tiettyyn pääobjekti-luokkaan (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 Servi-5 ce Key -arvo (vaikka olisi kysymyksessä samantyyppinen palvelu). Tiettyä pääohjelmalohkoa voi vastata hyvin monta erilaista Service 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 10 (i=1,2,...n). Näitä tietotauluja kutsutaan jatkossa päätauluiksi. SCP-verkko- elementissä on siis oma päätaulu kutakin pääohjelmalohkoa varten. Kussakin päätaulussa on yksi tietorivi kutakin ko. luokkaan kuuluvaa objektia varten. Esim. A-tilaajiin liittyvän pääohjelmalohkon FMP1 käyttämässä tietotaulussa FMP1_DT on siten yksi tietorivi kutakin A-tilaajaa Ai (i=1,2,...) kohti, B-tilaajiin 15 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ääohjelman käyttämässä tietotaulussa yksi tietorivi kutakin käytössä olevaa tietä kohti, osoite-tieobjekteihin liittyvän pääohjelman käyttämässä tietotaulussa yksi tietorivi kutakin käytössä olevaa osoitetietä kohti, jne.

20 Päätaulujen kullekin tietoriville on kuvion 4 esittämällä tavalla talle tettu tietoa, joka määrittelee, minkälainen alipalvelukokoelma kyseisellä objek-.; tiliä on aktivoituna. Kunkin rivin R alkuun on hakuavaimeksi talletettu objekti tunniste OI. Pääohjelmalohko hakee tietotaulustaan oikean rivin INAP-sano-man sisältämän objektitunnisteen arvon perusteella. Rivillä on peräkkäisiä ali- .·.· 25 tietueita SR, yksi kutakin alipalvelua kohti. Jokaisen alitietueen alussa on ali- • · palvelutunnisteen Fki (i=1,2,...) sisältävä kenttä FK, joka kertoo, mistä alipal-velusta on kysymys. Tämän jälkeen alitietueessa voi olla esim. statuskenttä ST, joka sisältää tiedon siitä, onko kyseinen alipalvelu aktiivinen vai passiivinen, ja prioriteettikenttä PR, joka sisältää prioriteettinumeron. Nämä alitietuei-30 den prioriteettinumerot kertovat alipalvelujen keskinäisen suoritusjärjestyksen.

• ·«

Kussakin alitietueessa on lisäksi ainakin kenttä SLP, joka sisältää sen palve- • · lulogiikkaohjelman tunnisteen, joka suorittaa kyseisen alipalvelun. Palvelulo-giikkaohjelmat muodostavat verkkoelementin alimman hierarkiatason.

Kutakin pääobjektiluokkaa kohti on edullisesti omat palveluohjel-: · 35 mansa. Jokaisesta ohjelmasta on lisäksi oma klooninsa jokaista INAP-sano- :. . majoukkoa kohti (eli jokaista jakeluohjelmaa kohti). Kuviossa on palveluohjel- 11 1 08325 mia merkitty viitemerkillä SLPxy-z, missä x ilmaisee sen pääobjektiluokan, jolle ohjelma kuuluu, y ilmaisee sen INAP-sanomajoukon, jolle ohjelma kuuluu ja z ilmaisee ohjelman järjestysnumeron pääobjektiluokan sisällä.

Verkkoelementin hierarkian mukaisesti kutsutaan yhden palvelu-5 pyyntödialogin alimman tason ilmentymää (SLPi) lapseksi, seuraavan tason 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 10 operaatio, jolla kutsuvaa tilaajaa pyydetään valitsemaan lisää numeroita (“prompt and collect user information”), tai conne.ct-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ä maini-15 tulla tavalla lisäämällä alitietueisiin kenttä PR prioriteettinumeroa varten, 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 ::, 20 suoritusjärjestystä.

i ', Pääohjelmalohkoja varten on lisäksi yksi tai useampi erillinen tieto- : ‘ : taulu, jossa on tietorivi kullekin sellaiselle Service Key -arvolle, joka on käytös sä usean eri pääohjelmalohkon alueella. Kuvion esimerkissä on yksi tietotaulu 11« ;·. FMP_DT1, joka on yhteinen kaikille pääohjelmalohkoille (kaikki pääohjelma-

I I

.·.· 25 lohkot lukevat ko. tietotaulua). Tietotaulun kunkin tietorivin alussa on avaimena • ·

Service Key -arvo SK. Kullakin rivillä on tiedot niistä alipalveluista 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 30 järjestys voi suoraan kertoa alipalveluiden keskinäisen järjestyksen. Pääohjel- • · · malohko lukee tästä tietotaulusta rivin, joka 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 lu- ‘kee dedikoidusta tietotaulustaan FMPiJDT (i=1,2,...) rivin, joka vastaa kyseisen : *. 35 objektin (esim. A-tilaajan) tunnistetta. Riviltä pääohjelmalohko saa selville sen » > · . palvelulogiikkaohjelman SLPi (i=1,2,...) tunnisteen, joka pitää käynnistää.

12 1 08 325

Luokkakohtaisen taulun FMPi_DT (esim. A-tilaajien taulun) riviltä pääohjelma-lohko 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.

5 Tässä vaiheessa palvelupyynnön suoritusta ovat siis selvillä objektiin 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.

10 FMP-ilmentymä lähettää siis lnitial_DP-sanoman sille palveluohjel malle, 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-formaatti), 15 jossa sen informaatiosisältö ei ole riittävä. Palvelulogiikkaohjelma tarvitsee näin ollen INAP-sanomaan sisältyvien tietojen lisäksi muita tietoja, esim. ali-palvelutunnisteen 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-20 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ä-: 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ä-

III

: hettämällä kuittaussanomat jakeluohjelmailmentymälle voidaan vähentää pää- ,y 25 ohjelmalohkojen kuormitusta, koska MDP-instassi hoitaa joka tapauksessa 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-verkko- • « *·|· 30 elementiltä tulleen Service Key -arvon. Tämän jälkeen tuleva kenttä NoOfSFs J.* 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 tun-.’· nisteet. Viimeisenä oleva kenttä AT sisältää kuvauksen siitä, miten palvelu- ' dialogi tulee terminoida, jos alipalvelujen suoritus epäonnistuu, i * · 35 Palveluohjelmat ovat rakenteeltaan sellaisia, että ne koostuvat osis- ta, joista kukin suorittaa tietyn alipalvelun. Tällöin kukin SLP suorittaa vain ne 13 1 08325 alipalvelut, joiden alipalvelutunnisteet tulevat pyyntösanomassa. Jos objekti-kohtaisella rivillä on aktiivisena useampi kuin yksi sellainen alipalvelu, joka kuuluu sallittujen alipalvelujen joukkoon ja kaikkiin kyseisiin alipalveluihin liittyy sama SLP-tunniste, FMP voi lähettää nämä kaikki alipalvelutunnisteet yhdessä 5 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-ilmentymä pyyntösanomat kyseisille SLP-ohjelmille siinä järjestyksessä, jonka objektikohtaisen rivin alitietueet ilmoittavat. Voidaan myös toimia niin, että yhdessä pyyntösanomassa lähetetään vain yhden aii-10 palvelun 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 alipalvelun loppumistapa. Jos esim. alipalvelun suoritus epäonnistuu, voi seu-15 raavaksi 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ä SLPJD2 kertoo lähettävän SLP-ilmentymän tunnisteen. Seuraava kenttä 20 WAIT sisältää mm. tiedon siitä, odotetaanko verkosta vastinetta ennen kuin : .v palvelua voidaan jatkaa. Kenttä FLAG_D sisältää Boolen muuttujan, joka ker- : '. · too, 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. tiedon).

:y; 25 Seuraavana tuleva kenttä LASTJNFO sisältää puolestaan Boolen muuttujan, ;y. joka indikoi, onko SLP-ilmentymä suorittanut viimeksi saamansa pyyntösano- man 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 voidaan kertoa sellai-30 sista lievemmistä virhetapahtumista, joista ei tarvitse lähettää erillistä virheil-•V moitusta. Kenttä EndDIg sisältää tiedon siitä, millä tavalla kyseinen SLP-ilmen- ·.·’ tymä haluaa isoisänsä päättävän kyseisen dialogin. Dialogilla voi olla erilaisia .1. : lopetustapoja esim. sen mukaan, halutaanko verkkoon lähettää sanoma tai jos .··. sanoma lähetetään, mitä tietoelementtejä sisällytetään lähetettävään 35 TC_END-primitiiviin.

14 1 08325

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ä.

5 Koska verkkoelementin sisäinen sanomanvaihto ei liity varsinaiseen 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 kuittaus-sanomilla hoidetaan alipalvelujen suoritusta ja ketjutusta ja kuittaussanoman 10 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 palvelulogiikkaohjelma koostuu palveluriippumattomista rakennusosista SIB (Service Independent Building 15 Block). SIBit ovat niitä lohkoja, joista palvelun suunnittelijat kokoavat palve-luominaisuuksia ja palveluja. Toisin sanoen, SIBit ovat pienimpiä lohkoja, joista palveluja ja palveluominaisuuksia kootaan. Palvelu koostuu useista palve-luominaisuuksista ja palveluominaisuus puolestaan useista SIBeistä, joskin joissakin tapauksessa palveluominaisuus voi muodostua vain yhdestä SIBistä. 20 Kukin SLP muodostuu erillisestä aloitustilarakennusosasta (eli aloi- v.: tustila-SIBistä) ISB (Initial State Block), yhdestä tai useammasta alipalvelumo- • '.· duulista FM (Feature Module) ja erillisestä lopetustilarakennusosasta (lopetus- tila-SIBistä) ESB (End State Block). Alipalvelumoduuleja on tyypillisesti useita rinnakkaisia, mutta aloitustilarakennusosa ja lopetustilarakennusosa ovat yh-;y; 25 teisiä yhden palveluohjelman kaikille rinnakkaisille alipalvelumoduuleille. Näis- .·.·. tä rakennusosaista käytetään termiä tilarakennusosa, toisaalta koska ne si sältävät viiveellisen tilan, jossa odotetaan vastetta ulkopuolelta ja toisaalta koska palveluohjelmissa ei muualla ole näitä tällaisia viiveellisiä tiloja, joissa odotetaan jotakin tapahtumaa.

30 Kukin SLP alkaa geneerisellä aloitustilarakennusosalla ISB, jonka ·*·* tehtävänä on vastaanottaa verkosta tuleva palveludialogin aloitussanoma ja ohjata palvelun suoritus oikean alipalvelun alkuun. Lähettävä pääohjelmalohko ;'y lähettää pyyntösanoman REQREC (joka sisältää edellä kuvatun mukaisesti .···. mm. yhden tai useamman alipalvelutunnisteen Fk) ja siihen liittyvän varsinai- '*·’· 35 sen (verkosta tulleen) INAP-sanoman perätysten. Tämän takia aloitusraken- ·' nusosassa on viiveelleen tila DS, jossa SLP-ilmentymä odottaa pyyntösano- 15 1 08325 man 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. Aloitustilara-kennusosassa suoritetaan lisäksi erilaisia initialisointitehtäviä, jotka ovat sa-5 moja kaikille palveluohjelmille. Viiveellisen tilan DS alla tarvitaan 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 terminointisanoma, jolla palvelun suoritus lopetetaan esim. jonkin virheen seurauksena. Verkkoele-10 mentti voi myös vastaanottaa palvelun suorituksen aikana verkosta kyseiseen palveludialogiin liittyvän error-sanoman, jonka seurauksena palvelu on lopetettava. Edellä mainituissa poikkeustilanteissa siirrytään suoraan lopetustilara-kennusosaan ESB.

Aloitustilarakennusosassa tapahtuvan InitialDP-sanoman vastaan-15 oton jälkeen palvelu etenee johonkin alipalvelumoduuliin FM. Alipalvelun alussa on yleensä jokin toimintarakennusosa FB, jossa käsitellään aloitussano-massa ollutta tietoa.

Palvelulogiikan toteutuksessa käytetään omaa sanomanlähetysra-kennusosaa (sanomanlähetys-SIBiä) jokaista sellaista eri tyyppistä sanomaa 20 kohti, joka lähetetään palveluohjelmasta verkkoon. Yleensä alipalvelun alussa olevaa toimintarakennusosaa seuraa yksi tai useampi tällainen sanomanlähe-tysrakennusosa. Sanomanlähetysrakennusosia edeltävän toimintarakennus-:' .; osan tarkoituksena on puolestaan saattaa valmiiksi ne tiedot, jotka asetetaan . "': sanomien tietokenttiin sanomanlähetysrakennusosissa.

. y. 25 Mikäli jokin sanomanlähetysrakennusosista on sellainen, että kysei- seen sanomatyyppiin odotetaan tiettyä vastetta, joka tulee kyseiseen sano- • I · maan aina virheettömän toiminnan yhteydessä, lisätään sanomanlähetysra- kennusosan perään geneerinen odotustilarakennusosa HSB (Hait State

Block), jossa palvelulogiikka odottaa palvelulogiikan haluamaa vastetta 30 (kyseisen tyyppistä INAP-sanomaa) verkosta. Geneerisyydellä tarkoitetaan v.‘ sitä, että se koodi, jolla rakennusosa on toteutettu on samanlainen riippumatta • · · siitä, missä kohdassa palveluohjelmaa tai missä palveluohjelmassa rakennus-.·. : osa sijaitsee. Ainoastaan rakennusosalle sisäänmenotietona annettava muut- tuja, joka kertoo sen sanoman tyypin, jota odotetaan, on rakennusosakohtai-35 nen, koska se riippuu siitä, minkä tyyppinen sanoma on edellä lähetetty verk-: V koon.

16 1 08325

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 5 on puolestaan sellaisia, että palvelulogiikan suoritusta jatketaan ilman, 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 10 lähetettävistä sanomista on puolestaan sellaisia, että niihin ei 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 terminointisanomat. Jokaisessa odotustilarakennusosailmentymässä on kyky vastaanottaa odotuksen kulues-15 sa mikä tahansa ennen synkronista vastetta (mahdollisesti) tuleva asynkroninen vaste.

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

20 Odotustilarakennusosan jokainen ilmentymä pystyy siis vastaanot tamaan kaikki mahdolliset sanomat, jotka voivat tulla odotustilan aikana. Tä-: män johdosta palvelulogiikan on haarauduttava odotustilarakennusosan lo- pussa sen mukaan, minkä tyyppinen sanoma odotustilassa vastaanotettiin.

:"'. Tämän johdosta on mahdollista käyttää jokaisessa tällaisessa vastaanottohaa- :Y* 25 rassa geneerisiä sanoman esikäsittelyrakennusosaa MB, joka sisältää toimin- ;y not, jotka siirtävät sanomassa tulleen tiedon palveluohjelman käyttöön. Toisin sanoen, esikäsittelyrakennusosassa siirretään sanomassa tulleiden parametrien arvot niitä vastaaville muuttujille. Tällaisia esikäsittelyrakennusösia on yksi kutakin sanomatyyppiä kohti.

30 Kunkin alipalvelumoduulin FM lopussa on lisäksi aina erillinen py- sähdystilarakennusosa SSB (Stop State Block), joka merkitsee tietyn alipalve-lun loppumista ennen seuraavan alipalvelun aloitusta tai ennen SLP-ilmen-tymän terminointia. Pysähdystilarakennusosasta lähetetään kuittaussanoma .· INFOREC alipalvelun suorittamisesta. Kuittaussanoman sisältämän loppukoo- .. V 35 din Te (joka on kentässä CC) perusteella pääohjelmalohko voi esim. määrittää : · seuraavan alipalvelumoduulin ja lähettää pysähdystilarakennusosalle seuraa- 17 1 08325 van pyyntösanoman REQREC, joka sisältää seuraavaksi suoritettavien alipal-velujen tunnisteet Fk (yksi tai useampi tunniste). Pysähdystilarakennusosan lopussa haarautumismuuttujana on siis (uusi) alipalvelutunniste. Pysähdystila-rakennusosa toimii siis palvelulogiikan kannalta kytkimenä, joka kytkee palve-5 lun jatkumaan oikeasta alipalvelumoduulista.

Kun alipalveluja ei ole enää suoritettavana, eikä ole tarpeen odottaa asynkronisia vasteita, prosessi siirtyy geneeriseen lopetustilarakennusosaan ESB, jossa voidaan lähettää sopivia loppusanomia verkkoon ja suorittaa mm. erilaisten laskurien talletusoperaatioita sekä terminoida SLP-ilmentymä. ιοί 0 petustilarakennusosaan kuuluvat ne lopetustoimenpiteet, jotka 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 onnistuneesti 15 tai alipalvelun suorittaminen epäonnistunut. Jos alipalvelu on esim. 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-20 osan TB rakennetta. Sanomanlähetysrakennusosassa annetaan aluksi arvo v 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 . y 25 (vaihe 82). Kun sanoma on lähetetty, asetetaan odotettavia vasteita indikoiville .·.· kontrollimuuttujille oikeat arvot (vaihe 83). Viesti voi olla tyypiltään esim. puhe- • · lun laskutuksessa käytettävä ApplyCharging, jonka tunnuskoodinumero on 35. Tähän viestiin odotetaan SSP:ltä ApplyChargingReport-viestiä, jonka tunnuskoodi on 36. Tällöin vaiheessa 83 asetetaan odotettavan sanoman tyyppiä in-30 dikoivan muuttujan arvoksi 36. Sanomanlähetysrakennusosia on yksi jokaista verkkoon lähetettävää sanomatyyppiä kohti eli käytännössä n. 15, joka on * · · (standardeissa määriteltyjen) SCF:ltä SSF:lle lähetettävien sanomatyyppien lukumäärä.

» · .·· Kuviossa 9 on havainnollistettu odotustilarakennusosan HSB toimin- ·’· 35 nallisuutta. Oleellista rakennusosan kannalta on em. seikkojen lisäksi se, että : siihen voidaan sisällyttää sellaisia toimintoja, jotka ovat varsinaisen (eli tilaajan 18 1 08325 tarvitseman) palvelulogiikan kannalta epäoleellisia. Näitä toimintoja ovat niiden tietosanomien lähetys ja vastaanotto, jotka eivät ole verkkosanomia (INAP-sanomia), vaan verkkoelementin sisäisiä sanomia, joilla hoidetaan esim. SCP-verkkoelementin sisällä suoritettavat aikavalvonnat (time-out) tai kuittaukset.

5 Odotustilarakennusosassa on siis yksi tai useampi sisäisen sanoman lähetys-lohko 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). Viiveelli-sen tilan alla on lisäksi, kuten aikaisemminkin, ainakin haarat, joissa käsitel-10 lään (a) aikavalvontasanoma, joka indikoi, että viiveellisessä tilassa on odotettu liian kauan ja (b) verkkoelementin sisäinen terminointisanoma, jolla palvelun suoritus lopetetaan esim. jonkin virheen seurauksena. Mikäli vastaanotetaan sisäinen aikavalvonta- tai terminointisanoma tai esim. verkosta tuleva error-sanoma, siirrytään suoraan lopetustilarakennusosaan ESB. Odotustilara-15 kennusosan lopussa haarautumismuuttujana on siis vastaanotetun sanoman tyyppi.

Parametrin PWAIT arvo voidaan yhtä hyvin antaa myös odotustilarakennusosassa.

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

; Y 25 Mikäli alipalveluja ei enää ole jäljellä (CTR=0), lähetetään kuittaus- • ♦ .*.· sanoma INFOREC (vaihe 103) ja siirrytään viiveelliseen tilaan DS odottamaan tulotapahtumaa.

Vaiheessa 104 lähetettävä kuittaussanoma (kenttä Fk) kertoo pääohjelmalle, että palveluohjelmalla on vielä alipalveluja suoritettavanaan, jolloin 30 pääohjelma ei lähetä palveluohjelmalle vastaussanomaa. Vastaavasti vai- * · '·'· heessa 103 lähetettävä kuittaussanoma kertoo, että palveluohjelmalla ei ole « * « ·.* enää alipalveluja suoritettavanaan.

« «

Mikäli alipalveluja on vielä suoritettavana, tulotapahtumana on (sisäinen) sanoma, joka kertoo, että vaiheessa 102 asetettu ajastin on lauennut. # ·’· 35 Tällöin siirrytään seuraavan alipalvelutunnisteen ilmoittaman alipalvelun al- : · kuun.

19 1 08325

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 5 mahdollisten aikavalvonta-ja terminointisanomien käsittelyyn.

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.

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

15 Yhden tai useamman seuraavana suoritettavan alipalvelun löytämi seksi pääohjelmatasolla on käytössä myös toinen tietotaulu FMP_DT2 (kuvio 4), joka on yhteinen tietylle joukolle pääohjelmalohkoja. Tämä tietotaulu osoittaa alipalvelujen keskinäisen vuorovaikutuksen. Tietotaulussa ovat alipalvelu-tunniste Fk ja loppukoodi Te ensisijaisina hakuavaimina. Jokaista alipalve-' 20 lu/loppukoodi -paria kohti taulukossa on mahdolliset alipalvelut. Toisin sanoen, taulukosta löytyy aina se joukko alipalveluja, jotka on mahdollista suorittaa seuraavana, kun suoritettu alipalvelu ja sen loppukoodi ovat tiedossa. Kun taulukosta on löydetty niiden alipalvelujen joukko, jotka voivat seurata juuri suoritettua alipalvelua, valitaan näiden alipalvelujen joukosta seuraavaksi suo-. ; 25 otettavaksi alipalveluksi se, jolla on objektikohtaisella tietorivillä (tai tietotaulus- *·* * sa FMP_DT1) korkein prioriteetti. Kun tämä alipalvelu on suoritettu, saadaan kuittaussanomassa jälleen loppukoodi, jolloin sen ja alipalvelutunnisteen avulla löydetään taas uusi alipalvelujoukko, josta valitaan seuraavaksi suoritettava alipalvelu objektikohtaisten tietojen perusteella.

30 Lähetettävien sanomien lukumäärän minimoimiseksi on edullista :*·’ toimia siten, että yhdessä pyyntösanomassa voidaan lähettää useampia ali- : 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ärjestyksessä i'- 35 tarkastaakseen, että seuraava alipalvelu on sallittu edellisen alipalvelun kaikilla :loppukoodeilla. Jos sen sijaan seuraavan alipalvelun sallittavuus riippuu edelli- 20 1 0 8 3 2 5 sen loppukoodista, on pääohjelman suoritettava edellä kuvatut tarkastus- ja valintatoimenpiteet ja lähetettävä niiden jälkeen uusi pyyntösanoma.

Loppukoodin perusteella tietotaulusta voi myös löytyä ainoastaan sellaisia alipalveluja (yksi tai useampi), joita ei ole objektikohtaisella rivillä. Tä-5 mä tapahtuu poikkeustilanteissa, kun loppukoodi osoittaa, että alipalvelun suoritus ei ole onnistunut normaalilla tavalla. Käytännössä voi esim. connect-ali-palvelu 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ä va-10 littua 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ä odotustila-15 rakennusosia, neljäs lukumäärä sanoman esikäsittelyrakennusosia sekä py-sähdystilarakennusosa. Sanomanlähetys-, odotustila- ja esikäsittelyrakennus-osien 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 lopetustilarakennus-'; 20 osaan, 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 25 esim. jos SSP-keskuksesta tulee sellainen aloitussanoma, että SCP-verkko-·* ‘ 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 30 varten voidaan määritellä erillinen apurakennusosien ryhmä. Apurakennusosat :*·* ovat siis sellaisia rakennusosia, jotka sisältävät vain hyvin pieniä toimintoja, .· : esim. yksittäisen tiedon perusteella tapahtuvia haarautumisia palvelulogiikas- • / sa. Tällainen haarautuminen voidaan toteuttaa yhdellä haarautumiskäskyllä, '··· jolloin ko. haarautumiskäskyn sisältävä rakennusosa on apurakennusosa.

: ·'; 35 Jäljempänä kuvataan eräs tähän ryhmää kuuluva palveluriippumaton raken- ; ‘ . nusosa, jonka avulla suoritetaan esim. virhetilanteessa hyppy suoraan alipal- 21 1 08325 velumoduulin 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.

Toimintarakennusosia voi käytännössä olla useita kymmeniä eri 5 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.

Keksinnön mukaisten tilarakennusosien avulla muodostetaan palve-10 luriippumattomat rakennusosat aloitussanoman vastaanottoa varten (aloitus-tilarakennusosa), verkosta tulevien synkronisten vasteiden vastaanottoa varten (odotustilarakennusosa), alipalvelujen ketjutusta varten (pysähdystilara-kennusosa) ja palvelun niitä lopetustoimenpiteitä varten, jotka ovat samoja riippumatta siitä, mikä palvelulogiikkaohjelma on kysymyksessä (lopetustila-15 rakennusosa). Saman tyyppiset tilarakennusosat ovat samanlaisia kaikissa palveluohjelmissa. Myös palvelun päättävää lopetustilarakennusosaa kutsutaan tilarakennusosaksi, koska ko. rakennusosassa on lähetettävä purkamis-sanomia verkkoon ja odotettava (viiveellisessä tilassa) loppuvastetta verkosta (Calllnformation Report, joka on sellainen sanoma, joka on pystyttävä otta-20 maan vastaan senkin jälkeen, kun verkkoon on lähetetty purkusanoma). Lo-petustilarakennusosassa suoritetaan lopetustoimenpiteet myös siinä tapauksessa, että alipalvelumoduulin keskeltä hypätään suoraan lopetusraken-nusosaan päättämään palvelu.

Kaikkien mahdollisten verkkosanomien vastaanotto sisältyy aloitus-f; 25 tilarakennusosaan, odotustilarakennusosaan, pysähdystilarakennusosaan ja ’ 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ää tilarakennusosaa luff 30 kuunottamatta viiveellisiä tiloja ei ole muualla, joten muihin palveluriippumat- f f torniin 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 palvelut : 35 ovat kuitenkin luonteeltaan sellaisia, että tämä ei ole mahdollista, vaan kahden ·/'; peräkkäisen alipalvelun välissä on odotettava ennen kuin palvelun suoritta- 22 1 0 8 3 2 5 mistä 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 odottamaan jotakin tapahtumaa, esim. sitä, että kutsuva tilaaja valitsisi lisää numeroita. Myös sen 5 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.

Tällaisen “joutoajan" kuluttaminen on edullista toteuttaa palvelulogiikassa omana alipalvelunaan, jotta se voitaisiin toteuttaa palvelusta riippumat-10 tomana rakennusosana. Keksinnön edullisen toteutustavan mukaisesti onkin jokaisessa palveluohjelmassa muiden alipalvelumoduulien lisäksi erityinen ali-palvelumoduuli tällaisen “joutoajan” kuluttamista varten. Tätä alipalvelumoduu-lia kutsutaan tyhjäkäyntimoduuliksi.

Tyhjäkäyntimoduulin alussa on sellainen ilmentymä odotustilaraken-15 nusosasta HSB, jossa tapahtuu asynkronisten vasteiden vastaanotto sellaisessa odotustilassa, jossa mitään tiettyä vastetta ei ole määritelty synkroniseksi vasteeksi (kuten muissa alipalvelumoduuleissa olevissa odotustilaraken-nusosissa), vaan parametrillä, joka ilmaisee, mikä on odotetun sanoman tyyppi, on arvo nolla. Huomattakoon vielä, että asynkronisia vasteita on voitava 20 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.

Tyhjäkäyntimoduulissa on siis valmius ottaa vastaan kaikki mahdolliset verkosta tulevat asynkroniset vasteet ja sen lisäksi sisäiset asynkroniset . ; 25 vasteet, kuten ajastimien laukeamiset. Odotustilarakennusosasta palvelulogii kan on haarauduttava sen mukaan, mikä asynkroninen vaste saapuu. Asynkronisten vasteiden käsittely voitaisiin suorittaa tyhjäkäyntimoduulin sisällä, mutta on kuitenkin edullisempaa suorittaa käsittely tyhjäkäyntimoduulin ulkopuolella erillisissä alipalvelumoduuleissa, joita on edullisesti yksi kutakin mah-v. 30 dollista asynkronista vastetta varten. Käsittely kannattaa tehdä tyhjäkäyntimo- :T duulin ulkopuolella, koska asynkronisten vasteiden käsittely ei välttämättä ole . '' samanlainen kaikissa palveluohjelmissa.

Keksinnön edullisessa lisätoteutustavassa onkin erityisiä poikkeus-rakennusosia, joiden avulla voidaan suorittaa hyppy alipalvelumoduulin lop-: ·* 35 puun ja sieltä edelleen halutun alipalvelumoduulin alkuun, jossa käsitellään saapunut asynkroninen vaste ja jonka lopusta voidaan tarvittaessa palata jäi- 23 1 0 8 3 2 5 leen tyhjäkäyntimoduulin alkuun. Kutakin mahdollista asynkronista vastetta varten on oma poikkeusrakennusosailmentymänsä. Poikkeusrakennusosien käytön etuna on se, että niiden avulla saadaan tyhjäkäyntimoduulin IFM koodi identtiseksi kaikissa palveluohjelmissa.

5 Kuviossa 11 on havainnollistettu poikkeusrakennusosilla EB varus tetun tyhjäkäyntimoduulin IFM rakennetta. Odotustilarakennusosasta HSB’, jossa voidaan vastaanottaa kaikki mahdolliset asynkroniset vasteet, haaraudutaan sanoman esikäsittelyrakennusosan MB jälkeen omaan poikkeusraken-nusosailmentymään EB sen mukaan, mikä asynkroninen vaste on vastaan-10 otettu. 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 alipalvelumoduulin lopussa olevan pysähdystilarakennusosan SSB alkuun. Parametri iERR indikoi, onko palvelulogiikka kulkenut poikkeusrakennusosan kautta ja minkälainen poikke-15 ustilanne on kysymyksessä. Parametri NextFk ilmoittaa puolestaan seuraa-vaksi toivotun alipalvelun tunnisteen.

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

Palveluohjelman tekijä antaa jokaiselle ilmentymälle, jossa poikkeus-rakennusosa on, parametrinä sen tiedon, minkä alipalvelun alkuun on seuraa-vaksi siirryttävä.

; : 25 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 12 on havainnollistettu tällaista pysähdystilarakennusosaa, joka on muuten sa-:Y 30 manlainen kuin kuviossa 10 esitetty pysähdystilarakennusosa, mutta raken- nusosan alkuun on lisätty vaiheet 98, 99 ja 100 ja pyyntösanoman vastaan-' oton jälkeen on lisätty vaiheet 105a ja 106. Rakennusosan alussa testataan ensin (vaihe 98), tullaanko pysähdystilarakennusosaan jostakin poikkeusra-kennusosasta. Tämä voidaan tehdä niin, että parametrillä iERR on muuten • ‘ ' 35 arvo nolla, mutta poikkeustilarakennusosassa se saa jonkin nollaa suuremman arvon. Esimerkiksi arvolla yksi voidaan osoittaa, että on saatu jokin sellainen 24 1 08325 asynkroninen vaste, joka vaatii käsittelyä omassa alipalvelumoduulissaan ja arvolla kaksi, että on saatu sellainen asynkroninen vaste (esim. terminointisa-noma), joka vaatii palvelun keskeyttämistä (siirtymistä lopetustilarakennus-osaan). Vaiheessa 98 testataan näin ollen, onko parametrin iERR arvo pie-5 nempi 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ä 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 10 edellä annettu arvo yksi, siirrytään vaiheeseen 100, jossa asetetaan kuittaus-sanoman kenttään NFk parametrin NextFk arvoja siirrytään vaiheeseen 103, jossa lähetetään kuittaussanoma. 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 15 (NextFk) suorituksen seuraavana alipalveluna, se lähettää pyyntösanoman REQREC, joka sisältää kyseisen alipalvelutunnisteen.

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 20 105a), sisältääkö se alipalvelutunnisteita. Jos näitä ei ole, tarkastetaan, onko vielä asynkronisia vasteita saapumatta verkosta (vaihe 106). Jos näin on, siirrytään tyhjäkäyntimoduuliin odottamaan. Jos vasteita ei ole enää “roikkumassa”, siirrytään lopetustilarakennusosaan.

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

Seuraavaksi suoritettavaa alipalvelua ei tarvitse välttämättä määri-30 teliä kuittaussanomassa; jos esim. annetaan parametrille iERR arvo 2, palvelu-:T logiikka etenee suoraan lopetustilarakennusosaan. Tällaisia arvoja käytetää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 luo-:35 kitella seuraaviin luokkiin sen mukaan, miten eri toiminnat on jaettu niiden kes-: * “: ken: 25 1 0 8 3 2 5 - tilarakennusosat ISB, HSB, SSB ja ESB, - sanomien sanomanlähetysrakennusosat TB, - vastaanotettavien sanomien esikäsittelyrakennusosat MB, - toimintorakennusosat FB, ja 5 - apu-ja erikoisrakennusosat.

Toteuttamalla palvelut edellä kuvatulla tavalla ketjutettuina alipalve-lumoduuleina voidaan sekä alipalveluja että tilaajakohtaisia alipalveluyhdistel-miä lisätä joustavasti muuttamatta jo olemassa olevia palvelulogiikkaohjelmia.

Vaikka keksintöä on edellä selostettu viitaten oheisten piirustusten 10 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 riippumatta siitä, tehdäänkö objektikohtaisia palveluja tai ' onko palvelulogiikka sama tietylle ryhmälle tai jopa kaikille objekteille (tilaajille).

15 Eri pääobjektiluokat voivat myös sijaita eri verkkoelementeissä, vaikka edellä onkin esitetty kaikkien sijaitsevan samassa verkkoelementissä. On myös mahdollista, että objektikohtaisella tietoriville talletetaan vain aktiivisena olevat ali-palvelut. Palveluohjelmia voi myös olla eri tyyppisissä verkkoelementeissä, esim. sellaisissa, jotka eivät suoraan vastaanota palvelupyyntöjä.

• * • · » · « · ♦ ♦ * ♦ • · ♦ ♦ ♦ • ♦ • ·

Claims (15)

26 1 0 8 3 2 5

1. Menetelmä palvelujen tarjoamiseksi tietoliikenneverkossa, erityisesti älyverkossa, jonka menetelmän mukaisesti - verkon ainakin yhteen verkkoelementtiin talletetaan palveluohjelmia 5 (SLP), - palvelu tarjotaan käynnistämällä haluttu palveluohjelma palveluja tarjoavassa verkkoelementissä, ja - kukin palvelu muodostetaan joukosta alipalveluja, jotka asetetaan kyseistä palvelua vastaavaan järjestykseen, 10 tunnettu siitä, että - palveluja tarjoavaan verkkoelementtiin talletetaan tunnisteet (Fk) käytössä oleville alipalveluille ja lisäksi tieto siitä, mikä palveluohjelma (SLP) kykenee suorittamaan kunkin alipalvelun, - ainakin osa palveluohjelmista toteutetaan siten, että mainitun tun-15 nisteen avulla määritetään palveluohjelmasta se osa, joka toteuttaa vastaavan alipalvelun, jolloin yhdessä palveluohjelmassa voi olla useampaa kuin yhtä ali-palvelua vastaavat osat, joista kukin on identifioitavissa mainitun tunnisteen avulla, ja - palvelu tarjotaan suorittamalla mainitussa järjestyksessä alipalvelu- ::: 20 tunnisteita vastaavat osat ainakin yhdestä palveluohjelmasta.

2. Patenttivaatimuksen 1 mukainen menetelmä objektikohtaisten pal- •V ·: velujen tarjoamiseksi, tunnettu siitä, että palveluja tarjoavaan verkkoele- menttiin talletetaan objektikohtaisesti tiedot objektiin liittyvien alipalvelujen tun-:V: nisteista, jolloin tarjottavat palvelut koostuvat objektikohtaisista alipalveluket- :T: 25 juista.

3. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, että kutakin alipalvelua vastaavan osan loppuun on muodostettu erillinen py- m :*·*: sähdystilarakennusosa (SSB), joka on samanlainen kaikissa palveluohjelmissa ja joka haaroittaa palvelun toteutuksen seuraavana vuorossa olevan alipalve- • · · 30 lun tunnisteen perusteella kyseistä alipalvelua vastaavan osan (FM) alkuun.

':' 4. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, että verkkoelementtiin talletetaan lisäksi tieto kuhunkin palveluun liittyvistä sal-lituista alipalveluista, jolloin mainittu joukko alipalvelutunnisteita määritetään valitsemalla objektiin liittyvistä alipalveluista ne, jotka kuuluvat sallittujen alipal- 27 1 0 8 3 2 5 velujen joukkoon.

5. Patenttivaatimuksen 4 mukainen menetelmä, tunnettu siitä, että palveluja tarjoavaan verkkoelementtiin talletetaan lisäksi tieto siitä, mitkä objektiin liittyvistä alipalveluista ovat kulloinkin aktiivisia, jolloin mainittu joukko 5 alipalveiutunnisteita määritetään valitsemalla objektiin liittyvistä aktiivisista alipalveluista ne, jotka kuuluvat sallittujen alipalveiujen joukkoon.

6. Patenttivaatimuksen 5 mukainen menetelmä, tunnettu siitä, että tiedot talletetaan tietotauluun (FMPi_DT), joka käsittää objektikohtaisia tietorivejä (R), joille on talletettu objektiin liittyvien alipalveluiden tunnisteet ja 10 tunnistekohtaisesti (a) tieto siitä, onko alipalvelu aktiivinen vai passiivinen ja (b) sen palveluohjelman tunniste, joka liittyy tunnisteeseen.

7. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että ainakin osa palveluohjelmista toteutetaan siten, että ne toteuttavat ainakin kaksi alipalvelua, jolloin useaan eri alipalvelutunnisteeseen liitetään saman 15 palveluohjelman tunniste.

8. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, että objektin alipalvelutunnisteisiin liitetään myös tunnisteet, jotka ilmoittavat objektin alipalveiujen keskinäisen suoritusjärjestyksen.

9. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, < I •'.v 20 että palveluja tarjoavaan verkkoelementtiin on talletettu objektikohtaiset tiedot • useille eri tyyppisille objektiluokille.

: ·.: 10. Patenttivaatimuksen 9 mukainen menetelmä, tunnettu siitä, että ainakin kutsuville ja kutsutuille tilaajille käytetään omia objektiluokkiaan.

11. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, • * 25 että palveluohjelman yksi alipalvelua vastaava osa toteutetaan erityisenä tyh-jäkäyntimoduulina (IFM), joka sisältää odotustilan, johon palvelulogiikan suori-tus siirretään väliaikaisesti odottamaan. • · ·

12. Patenttivaatimuksen 11 mukainen menetelmä, tunnettu siitä, I I I että tyhjäkäyntimoduuliin toteutetaan oleellisesti kaikkien sellaisten sanomien • · · *;!;* 30 vastaanotto, jotka voivat tulla mainitun odotustilan aikana.

13. Patenttivaatimuksen 12 mukainen menetelmä, tunnettu siitä, että sanomien vastaanoton yhteydessä käytetään erityistä poikkeusrakennus-osaa (EB), jonka kussakin ilmentymässä (a) annetaan arvo parametrille, joka ilmoittaa seuraavaksi suoritettavan alipalvelun tunnisteen ja (b) siirrytään sen 28 1 0 8 3 2 5 jälkeen suoraan pysähdystilarakennusosan (SSB) alkuun.

14. Patenttivaatimuksen 12 mukainen menetelmä, tunnettu siitä, että kutakin tyhjäkäyntimoduulissa (IFM) vastaanotettavaa sanomaa kohti on oma poikkeusrakennusosailmentymänsä.

15. Patenttivaatimuksen 12 mukainen menetelmä, tunnettu siitä, että ainakin osalle vastaanotettavista sanomista on oma alipalvelunsa, jossa kyseisen sanoman käsittely tapahtuu. • · · • · · • · t • « « I « • · • t · • · · • · ·«« • · · • · · • « · • · · • · « IM • · · • I I 29 1 0 8 3 2 5