FI108496B - Palvelujen tarjoaminen tietoliikenneverkossa - Google Patents

Description

108496

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 olemassaoleviin 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-automaattikuvaus niistä puhelinoh- jaustoiminnon (CCF, Call Control Function) toiminnoista, joita tarvitaan käyttä-: jien välisen yhteysreitin pystyttämiseen ja ylläpitoon. Tähän tilamaihin lisätään 25 toiminnallisuutta palvelun kytkentätoiminnon SSF (Service Switching Function) * · * .y. 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

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

* :* 35 voi myös lähettää pyyntöjä palveludatatoiminnolle SDF (Service Data Func tion), joka huolehtii pääsystä älyverkon palvelusidonnaisiin tietoihin ja verkko- 2 108496 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ää SRF:ää 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 SMF:ään ja SCEF mahdollistaa älyverkon palvelujen määrittelyn, kehityksen, 15 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 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. Puhelunohjaustoiminnolla CCF ei ole palvelutietoja, mutta se on ohjelmoitu tunnistamaan palvelupyyntöjen tarve. CCF keskeyttää puhelunmuodostuksen hetkeksi , ja ilmoittaa palvelun kytkentätoiminnolle SSF tiedon puhelun tilasta. SSF:n teh- :'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ä palvelu- /·:*. pyyntö. Mikäli näin on, SSF muodostaa standardoidun IN-palvelupyynnön ja • · · lähettää pyynnön SCF:lle 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ä 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 108496 (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 CCITT: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 SSP:l!e.

Palvelun ohjauspiste SCP (Service Control Point) sisältää ne palve-20 lulogiikkaohjelmat (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 sisäl- i tää asiakkaan ja verkon dataa, jota SCP:n palveluohjelmat käyttävät tuottaak- : 25 seen yksilöityjä palveluja. SCP voi käyttää SDP:n palveluja suoraan mer- • · ♦ kinanto- 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 30 Control Point) koostuu SCPistä 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äviin kuuluu tietokannan (SDP) hallinta, verkon valvonta ja testaus sekä verkko-: * 35 tietojen keräys. Se voi kytkeytyä kaikkiin muihin fyysisiin olioihin.

4 108496

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

Kuten edellä esitettiin, palvelun tarjoaminen käynnistyy siten, että SSF lähettää SCF:lle standardin mukaisen IN-palvelupyynnön. Palvelupyyntö voidaan lähettää tietyissä vaiheissa puhelunmuodostusta. SSF:n lähettämää 20 palvelupyyntöä varten on kansainvälisissä standardeissa määritelty kuitenkin vain yksi tunniste, jonka avulla haluttu palvelulogiikka voidaan valita SCF:ssä.

·.' · Tätä tunnistetta kutsutaan nimellä Service Key.

:· Yleisesti tunnettu tekniikka yksilöllisten palvelujen aikaansaamiseksi on sellainen, että Service Key -arvon avulla valitaan SCF:ssä lopullinen pal-25 velulogiikkaohjelma (SLP), jolloin useampi arvo voi osoittaa samaan palvelulo-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- 30 luominaisuudesta, josta käytetään kansainvälisissä standardeissa englannin-* kielistä nimitystä service feature, käytetään tässä esityksessä nimitystä alipal- velu.

Verkon tilaajien ja palvelujen määrien kasvaessa tullaan väistämättä tilanteeseen, jossa yksittäisen verkkoelementin suorituskyky alkaa muuttua : ·/ 35 riittämättömäksi. Käytännössä verkkoelementin, esim. SCP-verkkoelementin ·' suorituskyvyn rajat tulevat ensimmäisenä vastaan tietokantakapasiteetin ja 5 108496 kutsunkäsittelykapasiteetin osalta. Tietokantakapasiteetin kasvuun vaikuttaa erityisesti tilaajamäärien ja tilaajakohtaisten palvelujen kasvu ja kutsunkäsitte-lykapasiteettiin palvelujen ja niiden käytön lisääntyminen.

Älyverkon funktionaalinen arkkitehtuuri onkin toteutettava käytän-5 nössä siten, että palveluihin liittyvästä tilaajakohtaisesta datasta ja palvelulogiikasta on muodostettava datamoduuleja, jotta olisi mahdollista jakaa tilaajatie-tokanta ja palvelulogiikkaohjelmisto tarvittaessa tämän moduulijaon mukaisesti eri verkkoelementteihin.

Kun esim. yksittäisen SCP-verkkoelementin sisältämä tietokanta ja 10 palvelulogiikkaohjelmisto on jaettava usealle eri verkkoelementille, voitaisiin toimia suoraviivaisesti siten, että verkkoon lisätään uusia SCP-verkkoelement-tejä. Tällöin jouduttaisiin SSP-keskuksissa ryhmittelemään tilaajat jonkin kriteerin, esim. tuloväylän mukaan ryhmiin, jolloin kutsuvan tilaajan tilaajaryhmän perusteella tiedettäisiin, mihin SCP-verkkoelementtiin palvelupyyntö on lähe-15 tettävä kyseisen tilaajan osalta. Tällainen ratkaisu ei kuitenkaan ole suotava, koska verkkoon tarvittaisiin tällöin uusia solmuja, joilla on kaikilla oltava kyky kommunikoida verkon SSP-keskusten kanssa. SSP-keskusten ja SCP-verkko-elementtien käyttämä SS7-merkinantojärjestelmä perustuu jo sangen vanhaan perusratkaisuun ja alkaa käydä hitaaksi. SS7-protokollapinon hankkiminen jo-20 kaiseen uuteen verkkoelementtiin on myös kallis ratkaisu. SSP-keskuksessa olevassa liipaisutiedostossa (trigger data record) on normaalisti tieto siitä SCP-, l verkkoelementistä, johon palvelupyyntö tulee lähettää. Tämän tiedon käyttö tilaajan datamoduulin identifioimiseen tarkoittaa myös sitä, että kyseiseen -,: SCP-keskukseen voidaan sijoittaa vain yksi moduuli tilaajaryhmää kohti.

25 Yhden yhdistetyn SCP/SDP-verkkoelementin rakentaminen verkon • · · kapasiteetin kasvattamiseksi ei myöskään ole suotava ratkaisu, koska se ai- • · · /·:*·. heuttaa vaikeuksia muun verkon ylläpidossa. Tämä johtuu siitä, että yksi • · · SCP/SDP-verkkoelementti on normaalisti kytketty hyvin suureen osaan muuta verkkoa, ei siis pelkästään naapuriverkkoelementteihin, jolloin esim. INAP- « · * '·’·/ 30 protokollan eri versioiden päivitys muualla verkossa aiheuttaa hankaluuksia, v * Edellä mainituista syistä johtuen olisikin edullisinta kasvattaa verkon :*·.* suorituskykyä ja kapasiteettia siten, että em. datamoduuleja talletetaan SDP- tyyppiseen verkkoelementtiin, johon SCP-verkkoelementti voi olla yhteydessä esim. nopean datayhteyden avulla. Tällöin tulee kuitenkin ongelmaksi se, : 35 kuinka SCP-verkkoelementissä pystytään palvelupyynnön tullessa löytämään :. - * tarvittava objektikohtainen data ja palvelulogiikka.

6 108496

Keksinnön yhteenveto

Keksinnön tarkoituksena on tuoda ratkaisu edellä kuvattuun tilanteeseen ja saada aikaan ratkaisu, joka mahdollistaa verkon kapasiteetin kasvat-5 tamisen mahdollisimman joustavasti, tehokkaasti ja yksinkertaisesti.

Tämä päämäärä saavutetaan keksinnön mukaisella ratkaisulla, joka on määritelty itsenäisissä patenttivaatimuksissa.

Keksinnön ajatuksena on käyttää palvelupyyntösanoman sisältämän palvelutunnisteen (Service Key) arvoja identifioimaan ainakin se verkkoele-10 mentti, jossa sijaitsee se moduuli, johon palvelupyyntöön liittyvän objektin palvelutiedot on talletettu.

Keksinnön mukaista ratkaisua käyttämällä pystytään koko verkon kannalta katsottuna hyvin yksinkertaisella tavalla identifioimaan yksittäiseen palvelupyyntöön liittyvän objektin (esim. tilaajan) tietojen sijaintipaikka. Keksin-15 non mukainen palvelutunnisteen käyttö mahdollistaa ensinnäkin sen, että palvelupyynnön vastaanottava SCP pystyy löytämään sen verkkoelementin, jossa objektikohtaiset palvelutiedot sijaitsevat. Keksinnön edullisessa toteutustavassa SCP pystyy lisäksi hyvin yksinkertaisesti identifioimaan kyseisen tietomo-duulin riippumatta siitä, onko kyseinen moduuli juuri siinä samassa SCP-20 verkkoelementissä vai jossain toisessa verkkoelementissä.

Kun palvelutunnisteen arvoja käytetään edellä kuvatulla tavalla iden-: tifioimaan datamoduuleja ja kun tietty joukko datamoduuleja muodostaa yhden ·* objektiluokan, on siitä seurauksena, että palvelutunnisteen tietty arvöjoukko i i identifioi myös objektiluokan ja sen palvelut. Kullakin objektiluokalla on siis pal- 25 velutunnisteen tietty atvojoukko, joilla indikoidaan kaikki kyseisen objektiluokan palvelut.

• · • · · • · ·

Kuvioluettelo . . Seuraavassa keksintöä ja sen edullisia suoritusmuotoja kuvataan • · · 30 tarkemmin viitaten oheisten kuvioiden 3a... 12 mukaisiin esimerkkeihin oheisis- * sa piirustuksissa, joissa • · e * · kuvio 1 havainnollistaa älyverkon toiminnallista arkkitehtuuria, kuvio 2 havainnollistaa älyverkon fyysistä arkkitehtuuria, \ ·’ 35 kuvio 3a havainnollistaa SSP-keskuksen pääobjektiluokkakohtaisen tietotau- ‘ lun sisältöä, 7 108496 kuvio 3b havainnollistaa keksinnön mukaisten SCP- ja SDP-verkkoelement-tien toiminnallista arkkitehtuuria, kun tarkastellaan palvelulogiikka-ohjelmiston kannalta oleellisia osia, kuvio 4 havainnollistaa objektikohtaisen tietorivin sisältöä SCP- ja SDP-5 verkkoelementeissä, kuvio 5 esittää palveluohjelmailmentymälle lähetettävän pyyntösanoman rakennetta, kuvio 6 esittää palveluohjelmailmentymän lähettämän kuittaussanoman rakennetta, 10 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ähdystilara-15 kennusosaa, 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.

20

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- 1 *. 25 keskus ei ole SSP-keskus, se voi reitittää kutsuyrityksen SSP-keskukseen.

• · ·

Kun SSP-keskuksen puhelun ohjauksessa havaitaan, että kysymyk-/.·/·. sessä on tilaaja, joka tarvitsee älyverkon palveluja, Hipaistaan ohjauksen siirto I < · ’ älyverkkoon ja “jäädytetään” puheluyrityksen prosessointi. SSP-keskuksessa

on kullakin loogisesti erillisellä pääobjektiluokalla oma tietotaulunsa DT_SSP

• « * *·*·/ 30 (kuvio 3a), jossa on objektikohtaisia rivejä. Kunkin rivin R alkuun on hakua- : vaimeksi talletettu objektitunniste OI. Tämän lisäksi rivillä on ainakin kenttä, johon on talletettu sen SCP-verkkoelementin osoite (SCP_ADDRESS), johon palvelupyyntö on lähetettävä sekä kenttä, joka sisältää palvelutunnisteen (Service Key) arvon SK.

* ·' 35 SSP-keskus lähettää tällöin SCPille Initial_DP-viestin, joka on stan- ; dardeissa määritelty SSF:n ja SCP:n välinen viesti, jonka SSF generoi havai- 8 108496 tessaan 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 tar-5 joamiseen. Viestin informaatioelementeiksi 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 10 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-15 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-20 jelma lähettää verkkoon INAP-sanomia ja vastaanottaa verkosta INAP-sano-mia.

' j Kuviossa 3b on havainnollistettu keksinnön mukaisten SCP-ja SDP- verkkoelementtien toiminnallista arkkitehtuuria palveluohjelmien kannalta kat- : soituna. SCP-verkkoelementtiin tulevat palvelupyynnöt tulevat yhteiskanava- ; 25 merkinantopinon 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 oh- . . jelmalohko.

• · · *;*·/ 30 Jos sama SCP-verkkoelementti on yhdistetty useampaan kuin yh- • * · *·* * 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äy- : ;* 35 tännössä eriytettävä sen mukaan, mikä INAP-sanomajoukko on kysymykses- ♦ 9 108496 sä. 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ä 5 on tunnistaa TC_BEGIN-sanoman perusteella kyseessä oleva lNAP-sano-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ä.

10 Vastaanottavaa ohjelmalohkoa seuraavalla tasolla verkkoelementin 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ää 15 verkkoon päin TCAP-sanomia. (TCAP-sanoma koostuu otsikko-osasta ja 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.) 20 Kun verkkoelementtiin vastaanotetaan palveludialogin aloituspyyntö, joka tulee TC_BEGIN-primitiivinä (joka sisältää lnitial_DP-sanoman), luodaan vastaanottavasta ohjelmasta SRP uusi ilmentymä, joka hakee oikean jake- luohjelmalohkon, luo siitä ilmentymän ko. palvelupyynnön käyttöön, jä välittää . \j TCAP-sanoman ko. ilmentymälle. Tämän jälkeen vastaanottavan ohjelmaloh- . 25 kon ilmentymä häviää. Jakeluohjelmailmentymä vastaanottaa kaikki sen jäl- ,v, keen 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

v·* 30 (Subsystem Number) tai vaihtoehtoisesti kyseessä olevan sovelluskonteksti- · · · v : tunnisteen AC (Application Context identifier) ja hakee näiden/tämän perus- teella SRP-tason tietotaulusta SRP_DT sen jakeluohjelman nimen , \ MDP_NAME, joka vastaa kysymyksessä olevaa INAP-sanomajoukkoa.

SCP-verkkoelementin arkkitehtuurissa on siis jokaista INAP-sano-: V 35 majoukkoa kohti oma ohjelmalohkonsa MDPi, jonka tehtävänä on dekoodata e * 10 108496 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-5 lohkoja on merkitty viitemerkillä FMPi (Feature Manager Program) (i=1,2,...). Pääohjelmalohkot muodostavat ne prosessit, jotka ohjaavat varsinaisia palve-lulogiikkaohjelmia SLP syöttäen niille niiden tarvitsemat tiedot. Palvelujen ja alipalvelujen hallinta on siis pääohjelmalohkojen vastuulla.

Sanomanjakeluohjelmat jakavat kunkin palvelupyynnön oikealle 10 pääohjelmalohkolle. Tämän mahdollistamiseksi SCP-verkkoelementissä on jakeluohjelmia varten oma tietotauiunsa MDP_DT, jossa kunkin tietorivin alussa on hakuavaimena Service Key -arvo SK. InitialDP-sanomassa tulleen Service Key -arvon perusteella jakeluohjelmalohko hakee tietotaulusta oikean rivin. Tälle riville on talletettu sen verkkoelementin osoite NE_A, jossa kyseiseen 15 Service Key -arvoon liittyvä datamoduuli on, kyseisen datamoduulin tunniste MODJD ja sen pääohjelmalohkon tunniste (FMP_NAME), joka toimii vastaanottajana kyseisen Service Key -arvon tapauksessa. Tietotaulu on edullisesti yhteinen kaikille jakeluohjelmalohkoille MDPi.

Jakeluohjelmalohko vertaa tietotaulusta löytämäänsä verkkoele-20 menttiosoitetta SCP-verkkoelementin omaan osoitteeseen. Mikäli jakeluohjelmalohko havaitsee vertailun perusteella, että datamoduuli sijaitsee samassa SCP-verkkoelementissä, se luo kyseisestä pääohjelmalohkosta ilmentymän ko. palvelupyynnön käyttöön sekä lähettää ko. ilmentymälle erillisen aloitussa-noman, joka indikoi tullutta palvelupyyntöä. Tämän jälkeen se välittää vielä « « .··. 25 palvelupyyntöön liittyvän INAP-sanoman (InitialDP) ko. ilmentymälle.

·♦ ·

Mikäli jakeluohjelmalohko havaitsee vertailun perusteella, että data-moduuli sijaitseekin toisessa verkkoelementissä, esim. SDP-verkkoelemen- • · · tissä SDP1, se lähettää mainitun aloitussanoman verkon kautta kyseiselle , . verkkoelementille käyttäen sitä protokollaa, joka on käytössä kyseisten verk- • · · *·]·* 30 koelementtien välillä (esim. X.500). Erillinen aloitussanoma tarvitaan, koska v : SDP-verkkoelementti ei ole kykenevä “kylmiltään” reagoimaan tulevaan Ini- tialDP-sanomaan samalla tavalla kuin SCP-verkkoelementti kykenee reagoi-maan siihen (koska SCP:n ja SDP:n välillä käytetään toista protokollaa kuin SSP:n ja SCP:n välillä, kuten edellä mainittiin). Aloitussanoman perusteella ‘ 35 luodaan toisessa verkkoelementissä ilmentymä kyseisestä pääohjelmaloh- . : kosta ja se asetetaan ko. palvelupyynnön käyttöön.

11 1 08496

Koska palvelulogiikkatarpeet ovat erilaiset eri objektityypeille, SCP-verkkoelementti on edullista toteuttaa niin, että siinä on erilliset pääohjelma-lohkot SSP-keskusten sisältämiä, loogisesti erillisiä pääobjektiluokkia varten. Näitä luokkia voivat olla esim. kutsuvien tilaajien luokka, kutsuttujen tilaajien 5 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. Kutsuvat ja kutsutut tilaajat voidaan jakaa esim. sen mukaan, ovatko ne kiinteän verkon vai matkaviestinverkon (kutsuvia tai kutsuttu-10 ja) tilaajia. 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 kut-suyrityksen kohdalla, onko ko. kutsuyritystä varten lähetettävä palvelupyyntö palveluja tarjoavalle verkkoelementille (joka on älyverkon tapauksessa SCP-15 verkkoelementti).

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ääob-jektiluokkaan (esim. A-tilaajiin) liittyviin palvelupyyntöihin SSP-keskus joutuu 20 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). Tiet-:: tyä pääohjelmalohkoa voi vastata hyvin monta erilaista Service Key' -arvoa, ; mutta kahteen eri pääohjelmaan liittyvät Service Key -arvojoukot eivät saa i.'·: 25 mennä päällekkäin.

Palvelutunnisteen tietty arvojoukko kuvautuu siis tietyn pääobjekti-luokan palveluiksi, esim. niin, että ensimmäinen arvojoukko kuvautuu kutsuvi- • · en tilaajien palveluiksi, toinen arvojoukko kutsuttujen tilaajien palveluiksi, jne.

Tämä on myös suora seuraus siitä, että moduulit ovat objektiluokkakohtaisia ja #v. 30 kukin moduuli identifioidaan tietyllä Service Key -arvojoukolla. Saman objekti- « · · '.λ luokan moduuleja vastaavat palvelutunnistearvot on edullista valita peräkkäi- **! * siksi arvoiksi, jolloin objektiluokan palvelut identifioituvat palvelutunnisteen I * tiettynä arvoalueena.

/"/ Kutakin pääobjektiluokkaa kohti on oma tietotaulunsa FMPi_DT

35 (i=1,2,...n). Näitä tietotauluja kutsutaan jatkossa päätauluiksi. SCP-verkko- \/# elementissä on siis oma päätaulu kutakin pääohjelmalohkoa varten. Kussakin 12 1 08496 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 liittyvän pääohjelman FMP2 käyttämässä tietotaulussa FMP2_DT yksi tietorivi 5 kutakin B-tilaajaa kohti, tieobjekteihin liittyvän pääohjelman käyttämässä tieto-taulussa 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.

Kuviossa on esitetty vain A-tilaajien tietotaulu, joka on tässä esi-10 merkkitapauksessa jaettu kahteen eri moduuliin, joita on merkitty viitemerkeillä FMP1_DT1 ja FMP1_DT2. Näistä ensimmäinen sijaitsee SCP-verkkoelemen-tissä SCP1 ja jälkimmäinen SDP-verkkoelementissä SDP1.

Päätaulumoduulien kullekin tietoriville on kuvion 4 esittämällä tavalla talletettu tietoa, joka määrittelee, minkälainen alipalvelukokoelma kyseisellä 15 objektilla on aktivoituna. Kunkin rivin R alkuun on hakuavaimeksi talletettu objektitunniste OI. Pääohjelmalohko hakee tietotaulustaan oikean rivin INAP-sa-noman 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ä alipal-20 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-"· den prioriteettinumerot kertovat alipalvelujen keskinäisen suoritusjärjestyksen.

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

Kutakin pääobjektiluokkaa kohti on edullisesti omat palveluohjel- · mansa. Jokaisesta ohjelmasta on lisäksi oma klooninsa jokaista (NAP-sano-majoukkoa kohti (eli jokaista jakeluohjelmaa kohti). Kuviossa on palveluohjel-30 mia merkitty viitemerkillä SLPxy-z, missä x ilmaisee sen pääobjektiluokan, jolle • · · I.*.# 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- pyyntödialogin alimman tason ilmentymää (SLPi) lapseksi, seuraavan tason . v. 35 ilmentymää (FMPi) isäksi ja sitä seuraavan tason ilmentymää (MDPi) isoisäksi.

Vanhempi ilmentymä synnyttää aina nuoremman ilmentymän. Isoisä voi olla 108496 13 eri verkkoelementissä kuin isä ja lapsi, jotka ovat keskenään samassa verkkoelementissä.

Käytännössä voi palvelulogiikkaohjelman toteuttama yksi alipalvelu olla esim. äänitiedotuksen esittäminen tilaajalle (“play an announcement”) tai 5 operaatio, jolla kutsuvaa tilaajaa pyydetään valitsemaan lisää numeroita (“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ä maini-10 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 15 suoritusjärjestystä.

Pääohjelmalohkoja varten on verkkoelementissä lisäksi yksi tai useampi erillinen tietotaulu, jossa on tietorivi kullekin sellaiselle Service Key -arvolle, joka on käytössä usean eri pääohjelmalohkon alueella. Kuvion esimerkissä on yksi tietotaulu FMPJDT1, joka on yhteinen kaikille pääohjelma-20 lohkoille (kaikki pääohjelmalohkot 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 tapauk- : sessa. Lisäksi rivillä voi olla tieto siitä, missä järjestyksessä nämä alipalvelut :/·· 25 suoritetaan, tai alipalvelutunnisteiden järjestys voi suoraan kertoa alipalvelui- den keskinäisen järjestyksen. Pääohjelmalohko 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 lukee dedikoidusta tietotaulustaan tai 30 tietotaulumoduulistaan (jos taulu on jaettu useaan moduuliin) rivin, joka vastaa kyseisen objektin (esim. A-tilaajan) tunnistetta. Riviltä pääohjelmalohko saa • ♦ · selville sen palvelulogiikkaohjelman SLPi (i=1,2,...) tunnisteen, joka pitää käynnistää. Luokkakohtaisen taulun tai moduulin (esim. A-tilaajien taulun tai moduulin) riviltä pääohjelmalohko ottaa huomioon vain ne alipalvelut, jotka liit-, 35 tyvät ko. Service Key -arvoon (eli ne jotka kuuluvat edellä haettuun sallittuun 14 1 08496 joukkoon), ja näistäkin lopullisesti vain ne, jotka on merkitty ko. objektin kohdalla aktiivisiksi.

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ää-5 ohjelmalohko synnyttää ensimmäisenä vuorossa olevaa alipalvelua vastaavasta palvelulogiikkaohjelmasta ilmentymän ja pyytää sitä aloittamaan palvelun toteuttamisen.

FMP-ilmentymä lähettää siis lnitial_DP-sanoman sille palveluohjelmalle, jonka prioriteetti oli korkein ja jonka tunnisteen pääohjelmalohko luki 10 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), jossa sen informaatiosisältö ei ole riittävä. Palvelulogiikkaohjelma tarvitsee näin ollen INAP-sanomaan sisältyvien tietojen lisäksi muita tietoja, esim. ali-15 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 sisä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ä-20 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). Viimemainitulle menevät sanomat lähetetään SCP-verkkoelementille, jos palve-:· "· lupyyntöön liittyvän objektin moduuli sijaitsee SDP-verkkoelementissa. Lähet- ,. Y tämällä kuittaussanomat jakeluohjelmailmentymälle voidaan SCP-verkko- « · ’·.*·: 25 elementin sisällä vähentää pääohjelmalohkojen kuormitusta, koska MDP- ilmentymä hoitaa joka tapauksessa verkkoon lähtevien sanomien lähetyksen. Seuraava kenttä l_AST_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ösanomas- ... 30 sa. Kenttä SK sisältää SSP-verkkoelementiltä tulleen Service Key -arvon. Tä- • · · män jälkeen tuleva kenttä NoOfSFs kertoo pyyntösanoman sisältämien alipal- • · veluiden 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 patveludialogi tulee terminoida, jos alipalvelujen suori- ..V 35 tus epäonnistuu.

108496 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 objekti-kohtaisella rivillä on aktiivisena useampi kuin yksi sellainen alipalvelu, joka 5 kuuluu sallittujen alipalvelujen joukkoon ja kaikkiin kyseisiin alipalveluihin 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-ilmentymä pyyntösanomat kyseisille SLP-ohjelmille siinä 10 järjestyksessä, jonka objektikohtaisen rivin alitietueet ilmoittavat. Voidaan myös toimia niin, että yhdessä pyyntösanomassa lähetetään vain yhden alipalvelun tunniste.

Suoritettuaan alipalvelun SLP lähettää kuittaussanoman INFOREC

niille elementeille (isä ja/tai isoisä), jotka ilmoitetaan pyyntösanomassa 15 REQREC. Kuittaussanomassa SLP-ilmentymä ilmaisee myös sen, mikä oli alipalvelun loppumistapa. Jos esim. alipalvelun suoritus epäonnistuu, voi seu- raavaksi suoritettava alipalvelu olla erilainen verrattuna normaalitapaukseen, jossa alipalvelun suoritus onnistuu. Jos datamoduuli on SDP-verkkoele- mentissä, kuittaussanoma menee SCP-verkkoelementille. Verkkoon menevät 20 ja verkosta tulevat sanomat kulkevat isoisän (SCP:n) kautta riippumatta siitä, onko isoisä samassa vai eri verkkoelementissä kuin ne palvelulogiikkaohjel- . . mat, jotka tarjoavat palvelun.

* * * · ' "· Kuviossa 6 on havainnollistettu SLP-ilmentymän lähettämän kuit- ··: taussanoman INFOREC erästä mahdollista rakennetta. Ensimmäinen kenttä 25 SLPJD2 kertoo lähettävän SLP-ilmentymän tunnisteen. Seuraava kenttä * « · WAIT sisältää mm. tiedon siitä, odotetaanko verkosta vastinetta ennen kuin 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 30 viimeksi saanut isältä kyseisessä kentässä (jolloin myös isoisä saa ko. tiedon).

• ♦ *

Seuraavana tuleva kenttä LASTJNFO sisältää puolestaan Boolen muuttujan, * · · joka indikoi, onko SLP-ilmentymä suorittanut viimeksi saamansa pyyntösano- « · man viimeisen alipalvelun loppuun. Seuraava kenttä Fk sisältää sen alipalve-V lun tunnisteen, johon kyseinen sanoma tulee kuittauksena. Kenttä CC sisältää 35 juuri suoritetun alipalvelun loppukoodin. Kentässä ECC voidaan kertoa sellai-sista lievemmistä virhetapahtumista, joista ei tarvitse lähettää erillistä virheil- 108496 16 moitusta. 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ä sisällytetään lähetettä-5 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ä.

10 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 15 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 20 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ä. V·· 25 Kukin SLP muodostuu erillisestä aloitustilarakennusosasta (eli aloi- tustila-SIBistä) ISB (Initial State Block), yhdestä tai useammasta alipalvelumo-duulista FM (Feature Module) ja erillisestä lopetustilarakennusosasta (lopetustila-SIBistä) ESB (End State Block). Alipalvelumoduuleja on tyypillisesti useita rinnakkaisia, mutta aloitustilarakennusosa ja lopetustilarakennusosa 30 ovat yhteisiä yhden palveluohjelman kaikille rinnakkaisille alipalvelumoduuleil- I · » le. Näistä rakennusosaista käytetään termiä tilarakennusosa, toisaalta koska ne sisä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.

35 Kukin SLP alkaa geneerisellä aloitustilarakennusosalla ISB, jonka v:t tehtävänä on vastaanottaa verkosta tuleva palveludialogin aloitussanoma ja 108496 17 ohjata palvelun suoritus oikean alipalvelun alkuun. Lähettävä pääohjelmalohko 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 aloitusraken-5 nusosassa on viiveelleen tila DS, jossa SLP-ilmentymä odottaa 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. Aloitustilara-kennusosassa suoritetaan lisäksi erilaisia initialisointitehtäviä, jotka ovat sa-10 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 (tai SCP:n ja SDP:n välinen) terminointisanoma, jolla palvelun suoritus lopetetaan esim. jonkin virheen 15 seurauksena. Verkkoelementti 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 lopetustilarakennusosaan ESB.

Aloitustilarakennusosassa tapahtuvan InitialDP-sanoman vastaan-20 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 ·.’·: 25 kohti, joka lähetetään palveluohjelmasta verkkoon. Yleensä alipalvelun alussa olevaa toimintarakennusosaa seuraa yksi tai useampi tällainen sanomanlähe- :Y: tysrakennusosa. Sanomanlähetysrakennusosia edeltävän toimintarakennus- • · osan tarkoituksena on puolestaan saattaa valmiiksi ne tiedot, jotka asetetaan sanomien tietokenttiin sanomanlähetysrakennusosissa.

30 Mikäli jokin sanomanlähetysrakennusosista on sellainen, että kysei- • · · seen sanomatyyppiin odotetaan tiettyä vastetta, joka tulee kyseiseen sanomaan 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 (ky- ·’·. 35 seisen tyyppistä INAP-sanomaa) verkosta. Geneerisyydellä tarkoitetaan sitä, että se koodi, jolla rakennusosa on toteutettu on samanlainen riippumatta siitä, * · 108496 18 missä kohdassa palveluohjelmaa tai missä palveluohjelmassa rakennusosa sijaitsee. Ainoastaan rakennusosalle sisäänmenotietona annettava muuttuja, joka kertoo sen sanoman tyypin, jota odotetaan, on rakennusosakohtainen, koska se riippuu siitä, minkä tyyppinen sanoma on edellä lähetetty verkkoon.

5 Osa lähetettävistä sanomista on sellaisia, että niihin tulee aina vas taussanoma 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 ilman, että 10 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 tule lainkaan 15 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 kuluessa mikä tahansa ennen synkronista vastetta (mahdollisesti) tuleva asynkroni-20 nen vaste.

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

Odotustilarakennusosan jokainen ilmentymä pystyy siis vastaanot-:/· 25 tamaan kaikki mahdolliset sanomat, jotka voivat tulla odotustilan aikana. Tä- rnä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 vastäanottohaa- rassa geneeristä sanoman esikäsittelyrakennusosaa MB, joka sisältää toimin- ..... 30 not, jotka siirtävät sanomassa tulleen tiedon palveluohjelman käyttöön. Toisin • · · M. sanoen, esikäsittelyrakennusosassa siirretään sanomassa tulleiden parametri- *4 * en arvot niitä vastaaville muuttujille. Tällaisia esikäsittelyrakennusosia on yksi kutakin sanomatyyppiä kohti.

Kunkin alipalvelumoduulin FM lopussa on lisäksi aina erillinen py-;*·. 35 sähdystilarakennusosa SSB (Stop State Block), joka merkitsee tietyn alipalve- lun loppumista ennen seuraavan alipalvelun aloitusta tai ennen SLP- • * 108496 19 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ähdystilarakennus-5 osalle seuraavan pyyntösanoman REQREC, joka sisältää seuraavaksi suoritettavien alipalvelujen tunnisteet Fk (yksi tai useampi tunniste). Pysähdystila-rakennusosan lopussa haarautumismuuttujana on siis (uusi) alipalvelutunniste. Pysähdystilarakennusosa toimii siis palvelulogiikan kannalta kytkimenä, joka kytkee palvelun jatkumaan oikeasta alipalvelumoduulista.

10 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ä. Lopetustilarakennusosaan kuuluvat ne lopetustoimenpiteet, jotka ovat yhteisiä 15 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 tai alipalvelun suorittaminen epäonnistunut. Jos alipalvelu on esim. kytkentä 20 (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 25 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 asete- • · taan arvot lähtevän sanoman tietokenttiin (vaihe 81) ja sanoma lähetetään (vaihe 82). Kun sanoma on lähetetty, asetetaan odotettavia vasteita indikoiville ...·. 30 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 tunnus-v : koodi on 36. Tällöin vaiheessa 83 asetetaan odotettavan sanoman tyyppiä in- : dikoivan muuttujan arvoksi 36. Sanomanlähetysrakennusosia on yksi jokaista ; \ 35 verkkoon lähetettävää sanomatyyppiä kohti eli käytännössä n. 15, joka on 108496 20 (standardeissa määriteltyjen) SCF:ltä SSF:lle lähetettävien sanomatyyppien lukumäärä.

Kuviossa 9 on havainnollistettu odotustilarakennusosan HSB toiminnallisuutta. Oleellista rakennusosan kannalta on em. seikkojen lisäksi se, että 5 siihen voidaan sisällyttää sellaisia toimintoja, jotka ovat varsinaisen (eli tilaajan 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. 10 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-15 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-20 kennusosan lopussa haarautumismuuttujana on siis vastaanotetun sanoman tyyppi.

Parametrin PWAIT arvo voidaan yhtä hyvin antaa myös odotustilara-kennusosassa.

: Kuviossa 10 on havainnollistettu kunkin alipalvelumoduulin lopussa V·: 25 olevaa pysähdystilarakennusosaa SSB. Rakennusosan alussa (vaihe 101) :***: testataan, onko alipalveluja vielä jäljellä eli onko alipalvelulaskurin CTR arvo : V: 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 siirry tään viiveelliseen tilaan DS odottamaan tulotapahtumaa.

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

• · V·: Vaiheessa 104 lähetettävä kuittaussanoma (kenttä Fk) kertoo pää- :* /- ohjelmalle, että palveluohjelmalla on vielä alipalveluja suoritettavanaan, jolloin 35 pääohjelma ei lähetä palveluohjelmalle vastaussanomaa. Vastaavasti vai- 108496 21 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 lauen-5 nut. Tällöin siirrytään seuraavan alipalvelutunnisteen ilmoittaman alipalvelun alkuun.

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 10 aikaisemminkin, viiveellisen tilan alla on lisäksi haarat, jotka on tarkoitettu 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 15 lopetustilarakennusosaan.

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 20 useampi).

Yhden tai useamman seuraavana suoritettavan alipalvelun löytämiseksi pääohjelmatasolla on käytössä myös toinen tietotaulu FMP_DT2 (kuvio ' 4), joka on yhteinen tietylle joukolle pääohjelmalohkoja. Tämä tietotaulu osoit- Γ taa alipalvelujen keskinäisen vuorovaikutuksen. Tietotaulussa ovat alipalvelu- :.*·· 25 tunniste Fk ja loppukoodi Te ensisijaisina hakuavaimina. Jokaista alipalve- : 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 30 suoritettua alipalvelua, valitaan näiden alipalvelujen joukosta seuraavaksi suo- • « * ritettavaksi alipalveluksi se, jolla on objektikohtaiseila 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 35 alipalvelu objektikohtaisten tietojen perusteella.

108496 22 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 5 joutuu käymään läpi vielä suorittamattomat alipalvelut prioriteettijärjestyksessä tarkastaakseen, että seuraava alipalvelu on sallittu edellisen alipalvelun kaikilla loppukoodeilla. Jos sen sijaan seuraavan alipalvelun sallittavuus riippuu edellisen loppukoodista, on pääohjelman suoritettava edellä kuvatut tarkastus- ja valintatoimenpiteet ja lähetettävä niiden jälkeen uusi pyyntösanoma.

10 Loppukoodin perusteella tietotaulusta voi myös löytyä ainoastaan sellaisia alipalveluja (yksi tai useampi), joita ei ole objektikohtaisella rivillä. 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 anta-15 nut tarpeeksi numeroita, voidaan suorittaa alipalvelu, jolla kutsuvaa tilaajaa pyydetään valitsemaan lisää numeroita tai jos loppukoodi osoittaa esim. että valittua numeroa ei löydy, voidaan jatkaa äänitiedotus-alipalvelulla.

Yleisesti ottaen voidaan todeta, että alipalvelu (palveluominaisuus) toteutetaan peräkkäisillä rakennusosilla, joihin kuuluu aloitustilarakennusosa 20 (vain 1. alipalvelun osalta), ensimmäinen lukumäärä toimintarakennusosia, toinen lukumäärä sanomanlähetysrakennusosia, kolmas lukumäärä odotustila-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ää :.*·· 25 voida palata samaan tai uuteen palveluominaisuuteen. Palvelu ei kuitenkaan välttämättä pääty, kun ensimmäisen kerran siirrytään lopetustilarakennus-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-30 velussa) on yksi toimintarakennusosa, yksi sanomanlähetysrakennusosa ja * * · 1/. pysähdystilarakennusosa (ei odotustilarakennusosaa). Tällainen on tilanne • · · *\ * esim. jos SSP-keskuksesta tulee sellainen aloitussanoma, että SCP-verkko- • * _ V·· elementin täytyy ainoastaan lähettää verkkoon CONNECT-tyyppinen sanoma */ : Gohon ei odoteta synkronista vastetta).

35 Edellä kuvattujen rakennusosien lisäksi palveluohjelmat voivat si- ‘.sältää korkeintaan pieniä apu- tai erikoistoimintoja. Tällaisia aputoimintoja 108496 23 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 palvelulogiikassa. Tällainen haarautuminen voidaan toteuttaa yhdellä haarautumiskäskyllä, 5 jolloin ko. haarautumiskäskyn sisältävä rakennusosa on apurakennusosa. Jäljempänä kuvataan eräs tähän ryhmää kuuluva palveluriippumaton rakennusosa, jonka avulla suoritetaan esim. virhetilanteessa hyppy suoraan alipal-velumoduulin loppuun. Tähän ryhmään voi myös kuulua esim. sellainen SIB, jolla verrataan tunnistetta (identifier) referenssiarvoon. Tällainen SIB on mää-10 ritelty myös kansainvälisissä standardeissa.

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

Keksinnön mukaisten tilarakennusosien avulla muodostetaan palve-luriippumattomat rakennusosat aloitussanoman vastaanottoa varten (aloitus-tilarakennusosa), verkosta tulevien synkronisten vasteiden vastaanottoa varten (odotustilarakennusosa), alipalvelujen ketjutusta varten (pysähdystila-20 rakennusosa) ja palvelun niitä lopetustoimenpiteitä varten, jotka ovat samoja riippumatta siitä, mikä palvelulogiikkaohjelma on kysymyksessä (lopetustila-rakennusosa). Saman tyyppiset tilarakennusosat ovat samanlaisia kaikissa " ’·: palveluohjelmissa. Myös palvelun päättävää lopetustilarakennusosaä kutsu- -/ taan tilarakennusosaksi, koska ko. rakennusosassa on lähetettävä purkamis- 25 sanomia verkkoon ja odotettava (viiveellisessä tilassa) loppuvastetta verkosta (Calllnformation Report, joka on sellainen sanoma, joka on pystyttävä otta-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 lopetusrakennus-30 osaan päättämään palvelu.

*:!; Kaikkien mahdollisten verkkosanomien vastaanotto sisältyy aloitus- » · · *·' * tilarakennusosaan, odotustilarakennusosaan, pysähdystilarakennusosaan ja iopetustilarakennusosaan. Tarkemmin sanottuna, aloitussanoman vastaanotto : sisältyy aloitustilarakennusosaan ja kaikkien muiden verkkosanomien vas- 35 taanotto muihin tilarakennusosiin. Synkronisten vasteiden vastaanotto sisältyy vain odotustilarakennusosaan. Edellä mainittuja neljää tilarakennusosaa lu- 108496 24 kuunottamatta viiveellisiä tiloja ei ole muualla, joten muihin palveluriippumat-tomiin rakennusosiin ei tarvitse toteuttaa viiveellisiä tiloja eikä niihin liittyvää vastaanottologiikkaa.

Edellä on kuvattu palvelujen toteutusta siinä tapauksessa, että kaikki 5 alipalvelut voidaan suorittaa ajallisesti välittömästi peräkkäin. Jotkut 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ä tarkista-10 maan tilin saldoa. Palvelun kuluessa voidaan myös joutua 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.

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

Tyhjäkäyntimoduulin alussa on sellainen ilmentymä odotustilaraken-nusosasta HSB, jossa tapahtuu asynkronisten vasteiden vastaanotto sellai-“ sessa odotustilassa, jossa mitään tiettyä vastetta ei ole määritelty synkroni- seksi vasteeksi (kuten muissa alipalvelumoduuleissa olevissa odotustilaraken-:.*·· 25 nusosissa), vaan parametrillä, joka ilmaisee, mikä on odotetun sanoman tyyp- pi, on arvo nolla. Huomattakoon vielä, että asynkronisia vasteita on voitava ottaa vastaan odotustilarakennusosan kussakin ilmentymässä, koska odotus- * · tila saattaa olla niin pitkä, että sen kuluessa voi tulla asynkroninen vaste, esim. sellainen, joka osoittaa kutsuvan tilaajan lopettaneen puhelun.

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

Keksinnön edullisessa lisätoteutustavassa onkin erityisiä poikkeus-5 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 10 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, haarau-15 dutaan sanoman esikäsittelyrakennusosan MB jälkeen omaan poikkeusraken-nusosailmentymää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 alipalvelumoduulin lopussa 20 olevan pysähdystilarakennusosan SSB alkuun. Parametri iERR indikoi, onko palvelulogiikka kulkenut poikkeusrakennusosan kautta ja minkälainen poikkeustilanne on kysymyksessä. Parametri NextFk ilmoittaa puolestaan seuraa- a · :.*: vaksi toivotun alipalvelun tunnisteen.

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

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

• · · ’·' ’ 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 ilmenty-35 mästä ja jos tullaan, millainen poikkeustilanne on kysymyksessä. Kuviossa 12 \ on havainnollistettu tällaista pysähdystilarakennusosaa, joka on muuten sa- 1 0 8 4 96 26 maalainen 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 poikkeusra-5 kennusosasta. 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 alipalvelumoduulissaan ja arvolla kaksi, että on saatu sellainen asynkroninen vaste (esim. terminointisa-10 noma), joka vaatii palvelun keskeyttämistä (siirtymistä lopetustilaraken-nusosaan). 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ä on jokin nollaa suurempi arvo, 15 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 kuittaus-sanoman kenttään NFk parametrin NextFk arvo ja siirrytään vaiheeseen 103, jossa lähetetään kuittaussanoma. Jos parametrille iERR on annettu jokin yk-20 kö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.

Tilanteessa, jossa kaikki alipalvelut on suoritettu, pääohjelmalohko 25 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, siirrytään tyhjäkäyntimoduuliin odottamaan. Jos vasteita ei ole enää “roikku-30 massa", siirrytään lopetustilarakennusosaan.

M Palvelu lopetetaan (siirrytään lopetustilarakennusosaan) siis silloin, • · · *\ * 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-35 vontasanoma, joka kertoo, että viiveellisessä tilassa on odotettu liian kauan.

108496 27

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äytetään tilanteissa, joissa odotustilarakennusosassa HSB’ saatu asynkroninen vaste 5 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: - tilarakennusosat ISB, HSB, SSB ja ESB, 10 - sanomien sanomanlähetysrakennusosat TB, - vastaanotettavien sanomien esikäsittelyrakennusosat MB, - toimintorakennusosat FB, ja - apu-ja erikoisrakennusosat.

Käyttämällä keksinnön mukaista identifiointitapaa voidaan helposti 15 identifioida niiden objektityyppien datamoduulit, joihin liittyy liipaisutiedostoja kiinteän verkon SSP-keskuksissa ja matkaviestinverkon kotirekistereissä (HLR, Home Location Register). Tällä tavoin löydetään nopeasti ne objekti- kohtaiset tiedot, jotka tarvitaan palvelun tarjoamiseksi yksittäiselle kutsuyrityk- selle, esim. matkaviestinverkon kutsuvan tilaajan tiedot, kun on kysymyksessä 20 matkaviestinverkosta lähtevä puhelu.

Huomattakoon vielä, että edellä kuvatun toteutustavan mukaisesti SDP-verkkoelementtiin ei ole siirretty pelkästään tietokantamoduulia, vaan * ” myös moduulia vastaavan objektiluokan palveluohjelmat sekä palveluohjelmia Γ ohjaavat prosessit. Tällä tavoin voidaan vähentää verkon kautta kulkevien sa- 25 nomien määrää. Keksinnön mukaista perusperiaatetta voidaan kuitenkin käyttää, vaikka SDP-verkkoelementtiin sijoitettaisiin pelkästään tietokantamo- :Y: duuli tai tietokantamoduuli ja palveluohjelmat.

• ·

Vaikka keksintöä on edellä selostettu viitaten oheisten piirustusten « mukaisiin esimerkkeihin, on selvää, ettei keksintö ole rajoittunut siihen, vaan tV> 30 sitä voidaan muunnella edellä ja oheisissa patenttivaatimuksissa esitetyn kek- I.*. sinnöllisen ajatuksen puitteissa. Eri pääobjektiluokat voivat myös sijaita eri • · · verkkoelementeissä, vaikka edellä onkin esitetty kaikkien sijaitsevan samassa :/· verkkoelementissä. Palveluohjelmat voidaan myös toteuttaa perinteisellä ra- : kenteella, joskin edellä esitetyn kaltainen toteutustapa on edullinen, koska se \ 35 osaltaan auttaa yksinkertaistamaan palvelujen tuottamista ja lisäämään pal- ‘ ‘ velujen toteutuksen joustavuutta. Keksinnön mukaista ratkaisua voidaan myös 108496 28 soveltaa palvelujen toteuttamiseen riippumatta siitä, tehdäänkö tilaajakohtaisia palveluja tai onko palvelulogiikka sama tietylle ryhmälle tilaajia tai jopa kaikille tilaajille. Palvelupyyntöjä lähettävä verkkoelementti voi myös olla sama verkkoelementti kuin palvelupyyntöjä vastaanottava verkkoelementti.

i « I

• · ♦ • fr t · fr • · • · • fr* fr · • fr fr • fr fr • fr • e fr • fr fr • fr fr • • fr • fr fr • fr fr • fr • fr fr fr fr fr • * fr • * · β < 4 j «

Claims (11)

1. 29 1 08496
2. 1. Menetelmä objektikohtaisen palvelun tarjoamiseksi tietoliikenneverkossa, joka käsittää (a) ainakin yhden verkkoelementin (SSP), joka on sovitettu lähettämään palvelutunnisteen (Service Key) sisältäviä palvelupyyntöjä ja 5 jossa voidaan identifioida eri luokkiin kuuluvia objekteja ja (b) ainakin yhden verkkoelementin (SCP1), joka on sovitettu vastaanottamaan palvelupyyntöjä, jonka menetelmän mukaisesti - verkon ainakin yhteen palvelupyyntöjä vastaanottavaan verkkoelementtiin talletetaan palveluohjelmia (SLP), 10. tiettyyn objektiluokkaan kuuluvien objektien palvelutietoja talletetaan useaan datamoduuliin (FMP1_DT1, FMP1_DT2) ja datamoduulit sijoitetaan ainakin yhteen verkkoelementtiin, ja - palvelu tarjotaan käynnistämällä palveluohjelmia sisältävässä verkkoelementissä ainakin yksi palveluohjelma, jonka valitsemisessa käytetään 15 kriteerinä ainakin palvelupyynnön sisältämää palvelutunnistetta, tunnettu siitä, että - palvelutunnisteen arvoa käytetään palvelupyynnön vastaanottavassa verkkoelementissä (SCP1) identifioimaan se datamoduuli, johon objektin palvelutiedot on talletettu sekä se verkkoelementti (SDP1), johon mainittu data- 20 moduuli on talletettu, ja :,' ; - palveluohjelmia sisältävässä verkkoelementissä käytetään palvelu- tunnisteen arvoa edelleen yhdessä datamoduulin sisältämien objektikohtaisten :' palvelutietojen kanssa määrittämään objektikohtainen palvelu.
3. 2. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, • · · :Y: 25 että palvelupyyntöjä vastaanottavassa verkkoelementissä ylläpidetään tieto- • · taulua (MDP_DT), johon on talletettu kutakin käytössä olevaa palvelutunnis-tearvoa kohti sen verkkoelementin osoite (NE_A), jossa palvelupyyntöön liitty-vän objektin datamoduuli sijaitsee sekä lisäksi sen datamoduulin tunniste (MODJD), johon kyseisen objektin palvelutiedot on talletettu.
4. 3. Patenttivaatimuksen 1 mukainen menetelmä palvelujen tarjoami- ';'; seksi älyverkossa, tunnettu siitä, että saman objektiluokan datamoduu- ‘ <; · leista talletetaan osa SCP-verkkoelementtiin ja osa SDP-verkkoelementtiin. : i : 4. Patenttivaatimuksen 1 mukainen menetelmä palvelujen tarjoami- : ‘ ‘ ‘: seksi älyverkossa, tunnettu siitä, että SDP-verkkoelementtiin talletetaan
5. 1 G8 4 96 myös moduulia vastaavan objektiluokan palveluohjelmat sekä palveluohjelmia ohjaavat prosessit (FMP).
6. 5. Patenttivaatimuksen 1 mukainen menetelmä palvelujen tarjoamiseksi älyverkossa, tunnettu siitä, että samaan SCP-verkkoelementtiin tal- 5 letetaan useita saman objektiluokan datamoduuleja.
7. 6. Patenttivaatimuksen 4 mukainen menetelmä palvelujen tarjoamiseksi älyverkossa, tunnettu siitä, että samaan SDP-verkkoelementtiin talletetaan useisiin eri objektiluokkiin kuuluvia datamoduuleja.
8. 7. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, 10 että samaan objektiluokkaan kuuluvat datamoduulit identifioidaan keskenään peräkkäisillä palvelutunnistearvoilla.
9. 8. Tietoliikenneverkko, joka käsittää - ainakin yhden verkkoelementin (SSP), joka on sovitettu lähettämään palvelutunnisteen (Service Key) sisältäviä palvelupyyntöjä ja jossa voidaan 15 identifioida eri luokkiin kuuluvia objekteja, - ainakin yhden verkkoelementin (SCP1), joka on sovitettu vastaanottamaan palvelupyyntöjä ja johon on talletettu palveluohjelmia (SLP), ja - ainakin yhden objektiluokan osalta useita erillisiä datamoduuleja (FMP1_DT1, FMP1_DT2), joihin kyseisen luokan objektien palvelutietoja on 20 talletettu, jotka datamoduulit on sijoitettu ainakin yhteen verkkoelementtiin, tunnettu siitä, että - palvelupyyntöjä vastaanottavassa verkkoelementissä (SCP1) on identifiointielimet (MDP, MDP_DT), jotka tunnistavat vastaanotetun palvelu- pyynnön sisältämän palvelutunnisteen arvon perusteella sen datamoduulin, :Y: 25 johon objektin palvelutiedot on talletettu sekä sen verkkoelementin (SDP1), • · johon mainittu datamoduuli on talletettu, ja - palveluohjelmia sisältävässä verkkoelementissä on palvelun määri-tyselimet objektikohtaisen palvelun määrittämiseksi palvelutunnisteen arvon ja « datamoduulin sisältämien objektikohtaisten palvelutietojen perusteella. *· 30 9. Patenttivaatimuksen 8 mukainen tietoliikenneverkko, tunnettu siitä, että ainakin yhden objektiluokan datamoduuleja on talletettu sekä palve-lupyyntöjä vastaanottavaan verkkoelementtiin että sellaiseen toiseen Verkinkoelementtiin, joka on verkon kautta suoraan yhteydessä palvelupyyntöjä vastaanottavaan verkkoelementtiin ja joka ei suoraan vastaanota palvelu- 108496 pyyntöjä niitä lähettäviltä verkkoelementeiltä.
10. 10. Patenttivaatimuksen 9 mukainen tietoliikenneverkko, tunnettu siitä, että mainittu toinen verkkoelementti on älyverkon SDP-verkkoelementti ja että siihen on talletettu datamoduulin lisäksi kyseisen objektiluokan tarvit- 5 semat palveluohjelmat (SLP).
11. 11. Patenttivaatimuksen 10 mukainen tietoliikenneverkko, tunnettu siitä, että mainittuun toiseen verkkoelementtiin on talletettu lisäksi palveluohjelmia ohjaavia prosesseja (FMP), jotka kommunikoivat verkon kautta palvelupyynnön vastaanottaneen SCP-verkkoelementin kanssa. 10 • · · • · • · • · · * · Mt • · · • · · 108496