FI106507B - Tietosanoman käsittely tietoliikenneverkon verkkoelementissä - Google Patents

Description

106507

Tietosanoman käsittely tietoliikenneverkon verkkoelementissä

Keksinnön ala

Keksintö liittyy yleisesti tietosanomien käsittelyyn tietoliikennever-5 kon verkkoelementissä. Keksinnön eräs edullinen sovellusympäristö on älyverkon verkkoelementti, esim. SCP-verkkoelementti, mutta keksinnön mukaista ratkaisua voidaan soveltaa missä tahansa verkkoelementissä, jossa vastaanotetaan tietosanomia, joiden rakenne on etukäteen määritelty ja joissa on sisäkkäisiä tietorakenteita, joista osa on optionaalisia. Nämä tietosa-10 nomat voivat olla esim. yhteiskanavamerkinannossa käytettäviä sanomia. Jatkossa keksintöä kuvataan käyttäen esimerkkiympäristönä älyverkkoa.

Keksinnön tausta

Telekommunikaatioalan nopea kehitys on tehnyt mahdolliseksi sen, 15 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-20 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 25 käyttämällä hyväksi yleistä puhelun tilamallia BCSM (Basic Call State Model), joka kuvaa sitä olemassaolevaa toiminnallisuutta, jolla kahden käyttäjän välinen puhelu prosessoidaan. BCSM on korkean tason tila-automaatti-kuvaus niistä puhelinohjaustoiminnon (CCF, Call Control Function) toiminnoista, joita tarvitaan käyttäjien välisen yhteysreitin pystyttämiseen ja ylläpi-„ 30 toon. Tähän tilamalliin lisätään toiminnallisuutta palvelun kytkentätoiminnon SSF (Service Switching Function) avulla (vrt. olioiden CCF ja SSF osittainen päällekkäisyys kuviossa 1), jotta voidaan päättää, milloin on kutsuttava älyverkon palveluja (eli IN-palveluja). Kun näitä IN-palveluja on kutsuttu, huolehtii älyverkon palvelulogiikan sisältävä palvelun ohjaustoiminto SCF (Service 35 Control Function) palvelusidonnaisesta (puheluyrityksen) käsittelystä. Palvelun kytkentätoiminto SSF liittää siis puhelunohjaustoiminnon CCF (Call Cont- 2 106507 rol 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 voi myös lähettää pyyntöjä pal-5 veludatatoiminnolle SDF (Service Data Function), joka huolehtii pääsystä älyverkon palvelusidonnaisiin tietoihin ja verkkotietoihin. SCF voi näin ollen esim. pyytää SDF:ää hakemaan tiettyä palvelua koskevia tietoja tai päivittämään näitä tietoja.

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

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

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

106507 Tämän jälkeen se toimii yhdessä SSF/CCF:n, SRF:n ja SDF:n kanssa pyydetyn palvelun antamiseksi loppukäyttäjälle.

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

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

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

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

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

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

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

4 106507

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

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

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

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

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

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

20 SCP-verkkoelementtiin voi myös liittyä erillinen avustava SCP

(assisting SCP). Tällainen avustava SCP-verkkoelementti voi olla vaikkapa palvelun tarjoajalla, joka ylläpitää esim. tilaajakohtaista numeromuunnos- tai reitityslogiikkaa, joka tarjotaan verkko-operaattorin SCP-verkkoelementille täydentämään siellä olevia ohjaustietoja.

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

Esim. SSP:n ja SCP:n välillä käytetään INAP-sanomajoukkoa 30 (Intelligent Network Application Part). (Sanomajoukkoa kuvataan esim. standardissa ETSI IN CS1 INAP Part 1: Protocol Specification, Draft prETS 300 374-1, November 1993, josta kiinnostunut lukija löytää tarkemman kuvauksen.) Varsinaista protokollaa standardeissa ei ole määritelty, ainoastaan käytettävät sanomat, joista osaa käytetään toisessa siirtosuunnassa ja osaa 35 toisessa. Sanomiin on määritelty, paitsi kiinteitä ja optionaalisia parametrejä, myös ns. laajennusosaparametrejä. Eri palvelulogiikkaohjelmat saattavat siis 5 106507 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 palvelulogiikkaohjel-mat. Kukin palvelulogiikkaohjelma lähettää verkkoon INAP-sanomia ja vas-5 taanottaa verkosta INAP-sanomia.

Kaikkien näiden INAP-sanomien määrittely on suoritettu käyttäen ASN.1 -määrittelykieltä. ASN.1 (Abstract Syntax Notation 1) on tietoliikennealalla yleisesti käytetty kuvauskieli, jonka avulla määritellään ja koodataan tietorakenteita. Määrittely on regeneratiivinen, mikä tarkoittaa sitä, että minkä 10 tahansa tietorakenteen sisällä mikä tahansa tietoelementti voi olla rakenteeltaan yhtä monimutkainen kuin ylemmän tason tietorakenne.

Kun tällaisia tietosanomia vastaanotetaan esim. älyverkon SCP-verkkoelementtiin, päivitetään verkkoelementissä vain niitä parametrejä, joille vastaanotetussa sanomassa oli uudet arvot. Kun vastaanotetun sanoman 15 perusteella suoritetaan palvelun tarjontaan liittyvää prosessointia SCP-verkkoelementissä, joudutaan palveluohjelmassa tarkastamaan, mitkä vastaanotetun sanoman sanomamäärittelyyn sisältyvistä parametreistä olivat mukana varsinaisessa vastaanotetussa tietosanomassa (ja mitkä oli jätetty pois lähetyspäässä). Tämä tarkastus on nykyisellään varsin monimutkainen, 20 sillä tietyn parametrin mukanaolo sanomassa riippuu myös siitä, ovatko kyseistä parametriä ympäröivät (ulommat) tietorakenteet mukana sanomassa. Parametrin mukanaolon tarkastustapa on siten riippuvainen paitsi siitä, minkä tyyppinen rivi edeltää (eli on otsikkona) kyseistä parametriä vastaanotetun sanoman sanomamäärittelyssä, myös siitä, mikä on kyseisen sanoman ko-25 konaisrakenne siihen kohtaan asti, missä kyseisen parametrin paikka on sa-nomamäärittelyn mukaisesti. Yhden parametrin mukanaolon tarkastaminen voi siis sisältää useita peräkkäisiä tarkastuksia ja eri tyyppisten sanomien parametreillä on lisäksi erilaiset tarkastustavat sen mukaan, millainen kunkin sanomatyypin rakenne on. Tällaiseen monimutkaiseen tarkastustapaan on , < 30 jouduttu osittain myös siitä syystä, että parametreille ei voida määritellä min käänlaista “tyhjää” arvoa, joka osoittaisi suoraan, että tietty parametri ei ole mukana käsiteltävässä sanomassa.

Keksinnön yhteenveto 35 Keksinnön tarkoituksena on eliminoida edellä kuvattu epäkohta ja saada aikaan ratkaisu, jonka avulla verkkoelementtiin tulevien ja verkkoele- 6 106507 mentistä lähtevien tietosanomien tietosisällön käsittely saadaan entistä yksinkertaisemmaksi ja nopeammaksi.

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

5 Keksinnön ajatuksena on käyttää sanomamäärittelyn yksittäisiä komponentteja (jotka ovat ASN.1 -määrittelyssä tekstirivejä) kohti apupara-metrejä, joiden arvot osoittavat, onko kyseistä komponenttia vastaava parametri (tai tietorakenne) mukana sanomassa. Apuparametrien avulla saadaan syntymään täydellinen informaatio vastaanotetun tai lähetettävän sanoman 10 todellisesta sisällöstä. Tämä informaatio on lisäksi sellaista, että tieto tietyn parametrin mukanaolosta saadaan yhdellä vertailulla tarkastamalla kyseisen parametrin oman apuparametrin arvo.

Keksinnön mukaisen ratkaisun ansiosta tietosanomiin liittyvään prosessointiin saadaan merkittävä helpotus, koska parametrien mukanaolo 15 voidaan tarkastaa verkkoelementissä ilman, että tarkastusta suorittavan ohjelman sisälle täytyy rakentaa kullekin parametrille erikseen logiikka, jossa on huomioitu kyseisen sanomatyypin kokonaisrakenne mainitun parametrin si-jaintikohtaan asti.

20 Kuvioluettelo

Seuraavassa keksintöä ja sen edullisia suoritusmuotoja kuvataan tarkemmin viitaten oheisten kuvioiden 3...10 mukaisiin esimerkkeihin oheisissa piirustuksissa, joissa * 25 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, , 30 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, 35 kuvio 7 havainnollistaa yhden palveluohjelman toiminnallista rakennetta, kuvio 8 esittää esimerkkiä tietosanoman ASN.1-määrittelystä, 1C6507 kuvio 9 havainnollistaa sanoman tietosisällön lukuprosessia, kun verkkoelementtiin on vastaanotettu kuvion 8 mukaisesti määritelty sanoma, ja kuvio 10 havainnollistaa verkkoelementissä tietosanoman vastaanoton pe-5 rusteella suoritettavaa parametrien ja apuparametrien päivitystä.

Keksinnön yksityiskohtainen kuvaus

Verkon tilaajan aloittaessa puhelun tilaajan päätekeskus vastaanottaa ensin tiedon kutsuvan tilaajan halusta suorittaa puhelu. Tämä tieto voi 10 tulla keskukselle esim. standardin Q.931 mukaisena Setup-sanomana. Jos päätekeskus ei ole SSP-keskus, se voi reitittää kutsuyrityksen SSP-keskuk-seen.

Kun SSP-keskuksen puhelun ohjauksessa havaitaan, että kysymyksessä on tilaaja, joka tarvitsee älyverkon palveluja, liipaistaan ohjauksen 15 siirto älyverkkoon ja “jäädytetään” puheluyrityksen prosessointi. SSP-keskus lähettää tällöin SCP:!le lnitial_DP-viestin, joka on standardeissa määritelty SSF:n ja 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 20 ohjauksen siirto älyverkkoon). lnitial_DP on siis se viesti, joka aloittaa SSP:n ja SCP:n välisen dialogin, joka liittyy kunkin palvelun tarjoamiseen. Viestin informaatioelementeiksi SSP-keskus sisällyttää ainakin kutsuvan ja kutsutun numeron sekä palvelutunnisteen (Service Key).

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

Jos sama SCP-verkkoeiementti on yhdistetty useampaan kuin yhteen SSP-verkkoelementtiin, joissa käytetään INAP-sanomajoukon eri-ikäisiä versioita, on SCP:n vastaanottamien tietosanomien tietosisällön määrittely 35 erilainen riippuen siitä, minkä SSP:n kanssa SCP keskustelee. Tästä johtuen on sanomien jatkokäsittely vastaanottavasta ohjelmalohkosta eteenpäin käy- 106507 tännössä eriytettävä sen mukaan, mikä INAP-sanomajoukko on kysymyksessä. Vastaanottava ohjelmalohko SRP on sen sijaan riippumaton käytetystä INAP-sanomajoukosta.

Vastaanottava ohjelmalohko SRP vastaanottaa verkosta (SSF 5 olioilta) standardin mukaisia TC_BEGIN-sanomia. Ohjelmalohkon tehtävänä on tunnistaa TC_BEGIN-sanoman perusteella kyseessä oleva INAP-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 eri-10 laisten INAP-sanomajoukkojen lukumäärä.

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 15 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 sisältää enintään yhden INAP-sanoman. Kullakin komponenttiprimitiivillä on myös oma aliotsikkonsa. Nämä kaikki otsikko-osat tehdään, kun lähete-20 tään sanomia verkkoon ja ne poistetaan, kun vastaanotetaan sanomia verkosta.)

Kun verkkoelementtiin vastaanotetaan palveludialogin aloituspyyn-tö, joka tulee TC_BEGIN-primitiivinä (joka sisältää lnitial_DP-sanoman), luo-. . . daan vastaanottavasta ohjelmasta SRP uusi ilmentymä, joka hakee oikean 25 jakeluohjelmalohkon, luo siitä ilmentymän ko. palvelupyynnön käyttöön, ja välittää TCAP-sanoman ko. ilmentymälle. Tämän jälkeen vastaanottavan ohjelmalohkon ilmentymä häviää. Jakeluohjelmailmentymä vastaanottaa kaikki sen jälkeen SSP:ltä tulevat TCAP-sanomat. Oikean jakeluohjelman haku tapahtuu siten, että vastaanottava ohjelmalohko SRP lukee 30 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 sovelluskontekstitunnisteen AC (Application Context identifier) ja hakee näiden/tämän perusteella SRP-tason tietotaulusta SRP_DT sen jake-35 luohjelman nimen MDP_NAME, joka vastaa kysymyksessä olevaa INAP-sanomajoukkoa.

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

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 palvelulo-giikkaohjelmia SLP syöttäen niille niiden tarvitsemat tiedot. Palvelujen ja ali-10 palvelujen hallinta on siis pääohjelmalohkojen vastuulla (Palveluominaisuu-desta, josta käytetään kansainvälisissä standardeissa em. nimitystä “service feature”, käytetään tässä esityksessä myös nimitystä alipalvelu. Palveluomi-naisuus on (pienin) asiakkaalle tai tilaajalle näkyvä komponentti, josta hänen saamansa palvelu koostuu.) 15 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 jakeluohjelmalohko hakee tietotaulusta oikean rivin, jolta se löytää 20 sen pääohjelmalohkon tunnisteen (FMP_NAME), joka toimii vastaanottajana kyseisen Service Key -arvon tapauksessa. Tietotaulu on edullisesti yhteinen kaikille jakeluohjelmalohkoille MDPi. Löydettyään oikean pääohjelmalohkon jakelulohkoilmentymä luo siitä ilmentymän ko. palvelupyynnön käyttöön ja välittää INAP-sanoman ko. ilmentymälle.

25 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ääobjektiiuokkia varten. Näitä luokkia voivat olla esim. kutsuvien tilaajien luokka, kutsuttujen tilaajien luokka, osoitetiet (destination eli valitun numeron alkuosa), tiet (sub-30 destination 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, joiden yhteyteen voidaan verkkoelementissä, esim. älyverkon tapauk-35 sessa SSP-verkkoelementissä, liittää tieto, joka osoittaa yksittäisen kutsu-yrityksen kohdalla, onko ko. kutsuyritystä varten lähetettävä palvelupyyntö 10 106507 palveluja tarjoavalle verkkoelementille (joka on älyverkon tapauksessa SCP-verkkoelementti).

Kuten edellä mainittiin, kukin jakeluohjelmalohko käyttää hyväksi palvelupyyntösanomassa tullutta Service Key -parametriä vastaanottavan 5 pääohjelmalohkon määrittämiseksi. Tämä tarkoittaa sitä, että tiettyyn pää-objektiluokkaan (esim. A-tilaajiin) liittyviin palvelupyyntöihin SSP-keskus joutuu asettamaan Service Key -arvon, joka on erilainen kuin johonkin toiseen luokkaan kuuluviin objekteihin (esim. B-tilaajiin) liittyviin palvelupyyntöihin asetettu Service Key -arvo (vaikka olisi kysymyksessä samantyyppinen 10 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 (i=1,2,...n). Näitä tietotauluja kutsutaan jatkossa päätauluiksi. SCP-verkko-15 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ä tietotau-lussa FMP1_DT on siten yksi tietorivi kutakin A-tilaajaa Ai (i=1,2,...) kohti, B-tilaajiin liittyvän pääohjelman FMP2 käyttämässä tietotaulussa FMP2_DT yk-20 si 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, osoitetieobjekteihin liittyvän pääohjelman käyttämässä tietotaulussa yksi tietorivi kutakin käytössä olevaa osoitetietä kohti, jne.

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

Kutakin pääobjektiluokkaa kohti on edullisesti omat palveluohjelmansa. Jokaisesta ohjelmasta on lisäksi oma klooninsa jokaista INAP-sano-5 majoukkoa kohti (eli jokaista jakeluohjelmaa kohti). Kuviossa on palveluohjelmia 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-10 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 15 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ä mai-20 nitulla 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 mahdol-. listaa sen, että sama Service Key -arvo voi esim. kahdella eri A-tilaajalla ’ 25 merkitä erilaista suoritusjärjestystä.

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

FMP-ilmentymä lähettää siis lnitial_DP-sanoman sille palveluohjelmalle, 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 20 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. alipalvelutunnisteen arvon, jotka se saa pyyntösanomassa.

. Kuviossa 5 on esitetty esimerkki lähetettävän pyyntösanoman tieto- 25 rakenteesta. 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ä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).

*< 30 Lähettämällä kuittaussanomat jakeluohjelmailmentymälle voidaan vähentää pää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, 35 jotka pyydetään suorittamaan tässä pyyntösanomassa. Kenttä SK sisältää SSP-verkkoelementiltä tulleen Service Key -arvon. Tämän jälkeen tuleva 13 106507 kenttä NoOfSFs kertoo pyyntösanoman sisältämien alipalveluiden lukumäärän, ja ko. kenttää seuraavat kentät Fki (i=1,2,...) sisältävät kyseessä olevien alipalveluiden tunnisteet. Viimeisenä oleva kenttä AT sisältää kuvauksen siitä, miten palveludialogi tulee terminoida, jos alipalvelujen suoritus epäon-5 nistuu.

Palveluohjelmat ovat rakenteeltaan sellaisia, että ne koostuvat osista, joista kukin suorittaa tietyn alipalvelun. Tällöin kukin SLP suorittaa vain ne alipalvelut, joiden alipalvelutunnisteet tulevat pyyntösanomassa. Jos objektikohtaisella rivillä on aktiivisena useampi kuin yksi sellainen alipalvelu, 10 joka kuuluu sallittujen alipalvelujen joukkoon ja kaikkiin kyseisiin alipalvelui-hin liittyy sama SLP-tunniste, FMP voi lähettää nämä kaikki alipalvelutunnisteet yhdessä pyyntösanomassa (olettaen, että on muuten sallittua suorittaa kaikki kyseiset alipalvelut peräkkäin). Jos alipalveluissa on useamman eri SLP-ohjelman tunniste, lähettää FMP-ilmentymä pyyntösanomat kyseisille 15 SLP-ohjelmille siinä 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 20 REQREC. Kuittaussanomassa SLP-ilmentymä ilmaisee myös sen, mikä oli alipalvelun loppumistapa. Jos esim. alipalvelun suoritus epäonnistuu, voi seuraavaksi suoritettava alipalvelu olla erilainen verrattuna normaalitapaukseen, jossa alipalvelun suoritus onnistuu.

, Kuviossa 6 on havainnollistettu SLP-ilmentymän lähettämän kuit- 25 taussanoman INFOREC erästä mahdollista rakennetta. Ensimmäinen kenttä 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 kertoo, terminoiko SLP-ilmentymä itsensä kuittaussanoman lähettämisen jäl-• 30 keen vai ei. Kenttä LAST_REQ sisältää puolestaan saman tiedon, jonka lap

si on 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ösanoman viimeisen alipalvelun loppuun. Seuraava kenttä Fk sisältää 35 sen alipalvelun tunnisteen, johon kyseinen sanoma tulee kuittauksena. Kenttä CC sisältää juuri suoritetun alipalvelun loppukoodin. Kentässä ECC

106507 voidaan kertoa sellaisista lievemmistä virhetapahtumista, joista ei tarvitse lähettää erillistä virheilmoitusta. Kenttä EndDIg sisältää tiedon siitä, millä tavalla kyseinen SLP-ilmentymä haluaa isoisänsä päättävän kyseisen dialogin. Dialogilla voi olla erilaisia lopetustapoja esim. sen mukaan, halutaanko verk-5 koon lähettää sanoma tai jos sanoma lähetetään, mitä tietoelementtejä sisällytetään lähetettävään TC_END-primitiiviin.

Kuittaussanomassa voi lisäksi olla kenttä NFk, jossa voidaan ilmoittaa sen alipalvelun tunniste, joka tulisi suorittaa seuraavaksi.

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

Seuraavassa kuvataan yhden palvelulogiikkaohjelman SLPi periaatteellista rakennetta viitaten kuvioon 7. Kukin SLP muodostuu aloitustilara-kennusosasta (eli aloitustila-SIBistä) ISB (Initial State Block), yhdestä tai useammasta alipalvelumoduulista FM (Feature Module) ja lopetustilaraken-20 nusosasta (lopetustila-SIBistä) ESB (End State Block. SIBit (Service Independent Building Block) ovat niitä lohkoja, joista palvelun suunnittelijat kokoavat palveluominaisuuksia ja palveluja. SIB on pienin lohko, josta palveluja ja palveluominaisuuksia kootaan. Palvelu koostuu useista palveluominai-. suuksista ja palveluominaisuus puolestaan useista SIBeistä, joskin joissakin 25 tapauksessa palveluominaisuus voi muodostua vain yhdestä SIBistä.

Alipalvelumoduuleja on tyypillisesti useita rinnakkaisia, mutta aloi-tustilarakennusosa ja lopetustilarakennusosa ovat yhteisiä yhden palveluohjelman kaikille rinnakkaisille alipalvelumoduuleille. Näistä rakennusosaista käytetään termiä tilarakennusosa, toisaalta koska ne sisältävät viiveellisen * 30 tilan, jossa odotetaan vastetta ulkopuolelta ja toisaalta koska palveluohjel missa ei muualla ole näitä tällaisia viiveellisiä tiloja, joissa odotetaan jotakin tapahtumaa.

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

Aloitustilarakennusosassa tapahtuvan InitialDP-sanoman vastaanoton jälkeen palvelu etenee johonkin alipalvelumoduuiiin FM. Alipalvelun alussa on yleensä jokin toimintarakennusosa FB, jossa käsitellään aloitussa-20 nomassa ollutta tietoa.

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

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

Osa lähetettävistä sanomista on sellaisia, että niihin tulee aina 5 vastaussanoma normaalin (virheettömän) toiminnan yhteydessä ja vastausta on jäätävä odottamaan ennen palvelusuorituksen jatkamista. Tällaisia vastaussanomia kutsutaan jatkossa synkronisiksi vasteiksi. Osa lähetettävistä sanomista on puolestaan sellaisia, että palvelulogiikan suoritusta jatketaan ilman, että jäätäisiin odottamaan vastetta. Kun tällaiset vasteet tulevat ver-10 kosta 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 vastaussanomaa. Asynkronisia vasteita ovat myös mm. ver-15 kosta tulevat error-sanomat, jotka voivat tulla koska tahansa ja lisäksi sellaiset sisäiset sanomat, jotka voivat tulla koska tahansa, esim. sisäiset ter-minointisanomat. Jokaisessa odotustilarakennusosailmentymässä on kyky vastaanottaa odotuksen kuluessa mikä tahansa ennen synkronista vastetta (mahdollisesti) tuleva asynkroninen vaste.

20 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 vastaan-. ottamaan kaikki mahdolliset sanomat, jotka voivat tulla odotustilan aikana.

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

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

Kun alipalveluja ei ole enää suoritettavana, eikä ole tarpeen odot- 10 taa asynkronisia vasteita, prosessi siirtyy geneeriseen lopetustilaraken-nusosaan 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ä kaikille palveluille.

15 Edellä on kuvattu SCP-verkkoelementin edullista toteutustapaa tietosanomia lähettävien ja vastaanottavien palvelulogiikkaohjelmien kannalta. Tällaista verkkoelementtiä on kuvattu myös suomalaisissa patenttihakemuksissa 980238...980242, jotka ovat salaisia tämän hakemuksen jättöhetkellä. Seuraavassa kuvataan tarkemmin palveluohjelmien suorittamaa 20 sanomankäsittelyä keksinnön kannalta katsottuna.

Kuviossa 8 on havainnollistettu esimerkkinä, millainen palveluoh-jelmailmentymään vastaanotettavan tai palveluohjelmailmentymästä lähetettävän sanoman ASN.1-määrittely voi olla. Tässä esimerkkitapauksessa on . kysymyksessä osa INAP-sanomasta, jonka nimi on PlayAnnouncementArg.

* 25 Sanoman tyyppi tai lähetyssuunta ei kuitenkaan ole oleellinen, sillä ASN.1 -määrittely on samanlaista kaikkien sanomien osalta.

INAP-sanomien ASN.1-määrittelyt koostuvat tekstiriveistä, jotka voidaan jakaa kolmeen eri luokkaan siten, että: - ensimmäiseen luokkaan kuuluvat varsinaisten parametrien teksti- 30 rivit, - toiseen luokkaan kuuluvat sanomaan sulautettuja ASN.1-tietorakenteita osoittavat tekstirivit, ja - kolmanteen luokkaan kuuluvat tekstirivit, jotka eivät kuulu kumpaankaan edellä mainittuun luokkaan. Tämän luokan tekstirivejä nimitetään 35 jatkossa apuparametrien tekstiriveiksi.

18 10650/

Ensimmäiseen luokkaan kuuluvia rivejä, jotka sisältävät varsinaisen parametrin on kolmea eri tyyppiä seuraavasti.

I. Rivejä, joilla on pelkkä parametrin nimi. Näitä rivejä on kuviossa 8 merkitty rivin lopussa olevalla viitemerkillä A1.

5 2. Rivejä, joilla on parametrin nimen lisäksi lisämäärittely “OPT”, joka tarkoittaa sitä, että kyseinen parametri on optionaalinen (eli parametri joko on tai ei ole sanomassa). Näitä rivejä on kuviossa 8 merkitty rivin lopussa olevalla viitemerkillä A2.

3. Rivejä, joilla on parametrin nimen lisäksi merkintä “DEF”, joka 10 tarkoittaa sitä, että kyseinen parametri on optionaalinen siten, että jos parametri puuttuu sanomasta, käytetään parametrin oletusarvoa (default). Näitä rivejä ei ole kuvion 8 esimerkissä.

Toiseen luokkaan kuuluvia rivejä, jotka indikoivat sanomaan sulautettua ASN.1-tietorakennetta (parametrijoukkoa) on seuraavia tyyppejä 15 (tämä sulautettu tietorakenne on varustettu erillisellä nimellä): 4. “ANY DEFINED BY” 5. “STR DEFINED BY” 6. “STR DEFINED BY OPT” “ANY DEFINED BY” -tyyppinen rivi edeltää erillistä ASN.1-tieto-20 rakennetta (parametrijoukkoa), joka on valittu usean tietorakenne-ehdokkaan joukosta. “STR DEFINED BY” -tyyppinen rivi edeltää erillistä ASN.1-tietorakennetta, joka on merkkijonon muodossa (string type data format). Sama pätee kohdan 6 mukaiseen riviin, mutta tässä tapauksessa tietorakenteen . sisältyminen sanomaan on optionaalista (eli se joko on tai ei ole mukana sa- 25 nomassa). Kuvion 8 esimerkissä ei ole lainkaan toiseen luokkaan kuuluvia tekstirivejä.

Kolmanteen luokkaan kuuluvat tekstirivit ovat tyypiltään seuraavanlaisia: 7. “CHOICE” 30 8. “CHOICE OPT” 9. “SEQUENCE” 10. “SEQUENCE OPT” II. “SEQNOASN1” 12. “SEQNOASN1 OPT” 35 13. “SIZE(1...N) OF” 14. “SIZE(1...N) OF OPT”.

19 10650? “CHOICE’-tyyppinen rivi on sanomamäärittelyssä otsikkona yhden tai useamman erillisen tietorakenteen joukolle. Riviä vastaava tulevan sanoman tietokenttä sisältää luvun, joka kertoo, mikä sanomamäärittelyssä seu-raavina olevista tietorakenteista on mukana sanomassa. “CHOICE OPT 5 -tyyppisen rivin tapauksessa yksi tietorakenne on mukana tai kaikki on jätetty pois. “SEQUENCE”-tyyppistä riviä vastaava tietokenttä ei sisällä lukuarvoa, vaan se ainoastaan nimeää riviä seuraavan tietorakenteen, joka koostuu sarjasta tietorakenteita, jotka voivat olla mitä tahansa ASN.1-tietotyyppiä. “SEQUENCE OPT -tyyppisen rivin tapauksessa tämän sarjan sisällyttämi-10 nen sanomaan on optionaalista. “SEQNOASNT-tyyppinen rivi on otsikkona tietorakenteelle, joka koostuu sarjasta tietorakenteita, jotka eivät ole ASN.1-strukturoitua tietoa. Sama pätee “SEQNOASN1 OPT” -tyyppiselle riville, mutta tässä tapauksessa em. sarjan sisällyttäminen sanomaan on optionaalista. “SIZE(1...N)OF” -tyyppinen rivi edeltää sanomamäärittelyssä tietora-15 kennetta, joka käsittää jäljestetyn joukon tietorakenteita, jotka ovat samaa tietotyyppiä ja joita on vähintään yksi kappale ja enintään N kappaletta. “SIZE(1...N) OF OPT -tyyppisen rivin tapauksessa tämän järjestetyn joukon sisällyttäminen sanomaan on optionaalista. Sanomassa on rivin kohdalla luku, joka ilmoittaa, kuinka monta kertaa tietorakenne toistuu sanomassa.

20 Kolmanteen luokkaan kuuluvia tekstirivejä on kuviossa 8 merkitty rivin lopussa olevalla C-kirjaimella.

INAP-sanomien ASN.1-määrittelyistä voidaan siis löytää 14 eri tyyppistä tekstiriviä. Apuparametrien tekstirivejä (luokka 3) ja sulautettujen . ASN.1-tietorakenteiden tekstirivejä (luokka 2) voidaan pitää eräänlaisina ot- 25 sikkoriveinä, jotka muodostavat todellisten parametrien välissä olevia rivejä, joista jokainen kertoo jotakin sitä seuraavista parametreistä tai tietorakenteista (esim. ovatko ko. parametrit tai tietorakenteet mukana sanomassa vai eivät).

Kuten edellä esitetystä ilmenee, yksittäinen parametri tai paramet-30 rijoukko voi puuttua sanomasta vaikka ko. parametri tai parametrijoukko ei olisikaan optionaalinen, jos sen sijaan ulompi tietorakenne on optionaalinen. Parametrien tai tietorakenteiden mukanaolo sanomassa riippuu siis siitä, ovatko ympäröivät tietorakenteet mukana sanomassa.

SCP-verkkoelementin palvelulogiikkaohjelmat käyttävät parametri-35 joukkoja, joita on yksi kutakin INAP-sanomatyyppiä kohti. Yhteen sanoma-tyyppiin liittyvä joukko sisältää yhden parametrin kutakin sellaista tekstiriviä 20 106507 kohti, joka sisältää varsinaisen parametrin ko. sanomatyypin ASN.1-määrittelyssä (eli yhden parametrin kutakin luokkaan 1 kuuluvaa tekstiriviä kohti). Kun INAP-sanoma vastaanotetaan, päivitetään ne parametrit, jotka sisältyivät sanomaan.

5 Keksinnön mukaisesti SCP-verkkoelementissä käytetään em. pa rametrien lisäksi dedikoitua apuparametrijoukkoa jokaista INAP-sanomaa kohti. Kukin joukko sisältää edullisesti apuparametrin jokaista ko. sanoman ASN.1-määrittelyssä esiintyvää tekstiriviä kohti. Tässä esityksessä käytetään apuparametreille nimiä f_OCshortname, missä OC on kyseisen INAP-sano-10 man tyypin ilmaiseva koodi (Operation Code) ja shortname on kyseisen sanoman tekstirivillä esiintyvä lyhyt nimi. Kaikkien apuparametrien erottamiseksi toisistaan voidaan käyttää myös ko. tekstiriviin liittyvää lyhentämätöntä ni-meä (long name). Kunkin sanoman sanomamäärittelyn tekstiriville (josta käytetään myös nimitystä attribuutti) on määrittelyvaiheessa annettu sekä 15 lyhyt että pitkä nimi. Pitkässä nimessä on monta osaa, jolloin osien lukumäärä osoittaa, millä sisäisellä tasolla ko. tekstirivi sijaitsee sanoman sisällä (vrt. kuvion 8 sisennykset, joissa samalla tasolla olevia rivejä on merkitty keskenään samanlaisilla ympyröillä, jotka ovat joka toisella tasolla valkoisia ja joka toisella tasolla mustia). Esim. kuvion 8 ensimmäiseen riviin liittyy lyhyt nimi 20 PlaAAinfTS sekä pitkä nimi PlayAnnouncementArg.informationToSend ja toiseen riviin lyhyt nimi PlaAAinfTSinb sekä pitkä nimi PlayAnnouncemen-tArg.informationToSend.<inbandinfo>. Parametreistä käytetään vastaavasti nimiä i_OCshortname ja o_OCshortname, missä alkukirjain i viittaa tulevaan . sanomaan ja alkukirjain o lähtevään sanomaan.

25 Kun verkosta tulee SCP-verkkoelementtiin jokin edellä kuvatulla tavalla määritelty INAP-sanoma, siirtää sanomanesikäsittelyrakennusosa MB (vrt. kuvio 7) sanomassa tulleen tiedon palveluohjelmailmentymien käyttöön ja päivittää apuparametreille arvot, jotka osoittavat, oliko kyseistä tekstiriviä vastaava parametri tai tietorakenne mukana sanomassa. Ennen kuin sano-• 30 massa tullut tieto siirretään palveluohjelmien käyttöön, sanomankäsittelyra- kennusosan alussa initialisoidaan ko. sanoman ASN.1-määrittelyn jokaista tekstiriviä vastaava apuparametri tiettyyn initialisointiarvoon, esim. nollaan. Vastaavasti sanomanlähetysrakennusosan lopussa initialisoidaan lähetetyn sanoman ASN.1-määrittelyn jokaista tekstiriviä vastaava apuparametri.

35 Kuviossa 9 on havainnollistettu sanoman luvun yhteydessä suori tettavaa apuparametrien päivitystä eräässä kuvion 8 mukaisen sanoman ta- 21 106507 pauksessa. Kuvioon on ympyröidyillä numeroilla merkitty ne esimerkkiarvot, jotka lukuprosessin yhteydessä annetaan apuparametreille. Ympyröitä yhdistävät nuolet kuvaavat luku- ja päivitysprosessin etenemistä eli “hyppy-logiikkaa”. Sanomanesikäsittelyrakennusosa MB lukee INAP-sanoman si-5 sältöä puskurista sanomamäärittelyn mukaisessa järjestyksessä, koska tiedot ovat sanomassa tässä järjestyksessä. Sanomamäärittelyn tekstirivejä vastaavat tiedot ovat siis sanomassa samassa järjestyksessä kuin sanoma-määrittelyssäkin ja sanomassa on tieto siitä, mitä tekstirivejä vastaavat osat ovat mukana sanomassa. Hyppylogiikka etenee rivi riviltä, mutta hypäten nii-10 den rivien yli, joihin liittyvät tiedot eivät ole mukana sanomassa. Jokaisen rivin kohdalla johon hyppylogiikka osuu päivitetään riviä vastaava apupara-metri, mutta varsinainen parametri päivitetään näistä “osutuista” riveistä vain luokkaan 1 kuuluvien rivien kohdalla.

Kuten edellä mainittiin, sanomanesikäsittelyrakennusosa initialisoi 15 kaikki apuparametrit arvoon nolla ennen kuin tuleva sanoma luetaan puskurista. Kun sanoman sisältö luetaan, päivitetään tämä initialisointiarvo niitä rivejä vastaavilta apuparametreiltä, joiden kohdalle hyppylogiikka osuu. Näiden apuparametrien osalta initialisointiarvo päivittyy yleensä johonkin nollaa suurempaan kokonaislukuun (joskin se voi päivittyä myös uudelleen arvoon 20 nolla).

Apuparametreille annettavat arvot ovat useimpien tekstirivien kohdalla samoja kuin sanomasta luettu arvo, esim. optionaalisen rivin kohdalla arvo (nolla tai yksi), joka osoittaa, onko ko. tekstiriviä vastaava sanomanosa mukana sanomassa. Samoin CHOICE- ja SEQUENCE- ja SIZE(1...N)OF-25 tyyppisten rivien tapauksessa voidaan apuparametrille antaa sama kokonaislukuako, joka saatiin sanomassa. Sen sijaan esim. niiden rivien kohdalla, joilla pelkkä parametri ilman OPT- tai DEF-lisämäärettä, käytetään apuparametrille pelkästään arvoa nolla tai yksi, joka osoittaa, onko ko. parametri tai tietorakenne mukana sanomassa. Periaatteessa kunkin apuparametrin koh-30 dalla voidaan käyttää mitä tahansa arvoa, joka poikkeaa initialisointiarvosta ja joka osoittaa yksikäsitteisesti, että vastaava parametri tai tietorakenne on mukana sanomassa. Näin ollen apumuuttujan arvoon kohdistuvalla vertailulla saadaan selville, onko ko. parametrillä tuore arvo (oliko se mukana vastaanotetussa sanomassa), vaikka tämän tyyppistä tekstiriviä ympäröisikin 35 monitasoinen (optionaalinen) tietorakenne. Jos vertailussa havaitaan, että apuparametrillä on edelleen initialisointiarvonsa, indikoi se sitä, että paramet- 22 106507 ri tai tietorakenne puuttui sanomasta, esim. siitä syystä, että ympäröivä tietorakenne on jätetty pois sanoman lähetyspäässä.

Kuviossa 9 on esitetty esimerkki, jossa kahta ensimmäistä riviä vastaaville apuparametreille päivitetään arvo yksi 0’otka ovat samoja kuin sa-5 nomassa tulleet arvot) ja seuraavaa riviä vastaavalle apuparametrille arvo neljä (sama kuin sanomassa tullut arvo). Tämän jälkeen lukulogiikka hyppää neljänteen tietorakenteeseen (SEQUENCE-tyyppinen rivi), jota vastaava apuparametri saa tässä esimerkkitapauksessa arvon yksi. Seuraavan CHOICE-tyyppisen rivin kohdalla hypätään siihen tietorakenteeseen, joka on 10 mukana sanomassa. Tämä tietorakenne on toinen viidestä samalla tasolla olevasta rakenteesta, joten myös kolmen viimeisen ko. tasolla olevan rivin yli hypätään, jolloin päästään riville (numOfRepet), joka on tasolla, jolle kuviossa ylhäältä päin lukien toinen rivi (SEQUENCE) on otsikkona. Logiikka hyppää myös neljän viimeisen kuviossa olevan rivin yli ja jättää niitä vastaavat 15 apuparametrit päivittämättä, koska kuvion viimeinen SEQUENCE-tyyppinen rivi ja kuviossa viimeisenä oleva rivi (displaylnfo) ovat samalla tasolla kuin kuviossa ylhäältä päin lukien toinen rivi (SEQUENCE) ja koska niitä otsikoivaa CHOICE-riviä vastasi arvo yksi (mikä tarkoitti sitä, että ko. tasolla olevista tietorakenteista vain ensimmäinen on mukana sanomassa).

20 Kuviossa 10 on havainnollistettu palvelulogiikkaohjelman suoritta maa tietosanoman käsittelyä. Esimerkissä oletetaan, että tulevan sanoman sanomapuskuriin BFi talletetaan tuleva sanoma (jonka operaatiokoodi OC=xy) ja jonka ASN.1-sanomamäärittelyssä on tekstirivit A, B, C, D, jne.

. Lisäksi esimerkissä on oletettu, että vastaanotetussa sanomassa on sano- « 25 mamäärittelyn rivejä A, C, D, F, jne. vastaavat tietokentät (eli ainakin B ja E puuttuvat välistä).

Aluksi sanomanesikäsittelyrakennusosa MB initialisoi ko. sanoma-tyyppiä vastaavan apuparametrilistan AP_xy kaikki apuparametrit arvoon nolla. Tämän jälkeen sanomanesikäsittelyrakennusosa lukee muistista sa-• 30 nomapuskurin BFi aloitusosoitteen ja alkaa lukea puskurin sisältöä (nuolen R

osoittamassa) järjestyksessä aloitusosoitteesta lähtien. Rivin A kohdalla sanomanesikäsittelyrakennusosa päivittää sitä vastaavan apuparametrin (f_xyA) ja tallettaa kyseistä sanomaa vastaavassa parametrilistassa P_xy kyseistä riviä vastaavalle parametrille (i_xyA) sanomassa tulleen arvon. Pa-35 rametrilistan parametrit ovat eri tietotyyppejä riippuen siitä, minkä tyyppinen ko. parametri on (integer, BCD, jne.). Sen jälkeen päivityslogiikka hyppää ri- 23 10650'/ vin B yli ja päivittää riviä C vastaavan apuparametrin (f_xyC) sekä tallettaa kyseistä riviä vastaavalle parametrille (i_xyC) sanomassa tulleen arvon. Tällä tavoin luku etenee kohti sanomapuskurin loppua. Vain ne apuparametrit, jotka liittyvät sellaisiin tekstiriveihin, joita vastaava osa on mukana sanomassa, 5 päivitetään uuteen arvoon.

Kun palvelulogiikkaohjelmassa myöhemmin tullaan esim. toiminta-rakennusosaan FB, jossa käsitellään sanomassa ollutta tietoa, on ko. rakennusosassa tarkastettava, onko tietty parametri ollut mukana (viimeksi tulleessa) sanomassa. Esim. jos on tarkastettava, onko sanomamäärittelyn 10 tekstiriviä C vastaava osa ollut mukana sanomassa, suoritetaan toimintara-kennusosan FB sisällä yksinkertainen testi (viitenumero 100), jossa testataan, onko ko. riviä vastaava apuparametri f_xyC suurempi kuin nolla. Mikäli näin on, parametri (i_xyC) on käytettävissä. Muussa tapauksessa tiedetään, että kyseinen parametri ei ole ollut mukana sanomassa.

15 Edellä on kuvattu apuparametrien käyttöä lähinnä sanoman vas- taanottosuunnassa. Lähetyssuunnassa sanomanlähetysrakennusosat TB lukevat lähetettävää sanomatyyppiä vastaavaa apuparametrilistaa ja kirjoittavat lähtevän sanoman sanomapuskuriin BFo ko. sanoman parametrilis-tasta ne tiedot, joita vastaavien apuparametrien arvot poikkeavat initialisoin-20 tiarvostaan. Ennen tätä on palvelulogiikkaohjelman aiemmissa rakennusosissa (esim. toimintarakennusosissa FB) annettu apuparametreille arvot, jotka osoittavat sanomanlähetysrakennusosalle, mitkä parametrit ovat mukana sanomassa. Sanomanlähetysrakennusosassa joudutaan siis suoritta-. maan edellä kuvatun kaltainen vertailu, jossa tarkastetaan, onko apupara- 25 metrillä initialisointiarvonsa vai jokin siitä poikkeava arvo. Vain ne parametrit, joilla on initialisointiarvosta poikkeava arvo otetaan mukaan lähetettävään sanomaan. Vertailun looginen muoto riippuu vain siitä, minkä tyyppinen on se rivi, joka edustaa sitä tietoa, joka ollaan kirjoittamassa lähetettävän sanoman puskuriin. Vertailu ei sen sijaan riipu lainkaan sanoman muusta, ym-30 päröivästä rakenteesta.

Verkkoelementti voidaan myös toteuttaa "riisuttuna” niin, että sanomamäärittelyn joitakin rivejä vastaavia osia ei toteuteta lainkaan. Tällöin sanomanesikäsittelyrakennusosaan sisältyvä dekoodausrutiini, jonka tehtävänä on täyttää tulevan sanoman sanomapuskuri, ei tunnista kyseisiä rivejä 35 vastaavia sanomanosia, jolloin ne jäävät tallettamatta sanomapuskuriin, vaikka ne tulisivatkin sanomassa. Tässä tapauksessa voidaan kyseisiä teks- 106507 tirivejä vastaavat apuparametrit initialisoida johonkin negatiiviseen arvoon, esim. arvoon -1, joka osoittaa, että ko. verkkoelementti ei tunnista lainkaan vastaavia parametrejä tai tietorakenteita. Kun ei-toteutettuakin riviä vastaa apuparametri, jolla on dedikoitu arvonsa, on logiikan ohjaus yksinkertaista 5 näiden rivien kohdalla ja samoja rakennusosia voidaan käyttää verkkoelementeissä riippumatta siitä, onko niissä ei-toteutettuja rivejä. Tällä tavoin voidaan lisäksi kätevästi määritellä rajoitusprofiili, joka osoittaa, minkälaista INAP-sanomajoukon osajoukkoa verkkoelementti käyttää vaihtaessaan sanomia tietyn toisen verkkoelementin kanssa. Näitä rajoitettuja sanomia voi-10 daan käyttää esim. SCP-verkkoelementin ja alussa mainitun avustavan SCP-verkkoelementin (assisting SCP) välisellä yhteydellä. Tällaista toimintoa, jolla INAP-sanomien sisältöä rajoitetaan parametrikohtaisesti kutsutaan englanninkielisellä nimellä INAP-screening.

Vaikka keksintöä on edellä selostettu viitaten oheisten piirustusten 15 mukaisiin esimerkkeihin, on selvää, ettei keksintö ole rajoittunut siihen, vaan sitä voidaan muunnella edellä ja oheisissa patenttivaatimuksissa esitetyn keksinnöllisen ajatuksen puitteissa. Ajatusta voi käyttää myös siten, että vain osalle tekstirivejä muodostetaan dedikoitu apuparametri, joskin tarkastusten helpottamiseksi on edullisinta, että apuparametri on sanomamäärittelyn jo-20 kaista tekstiriviä kohti. Keksinnön sovellusympäristö ei myöskään ole sidottu älyverkkoon, vaan sitä voidaan käyttää missä tahansa ympäristössä, jossa tilanne on vastaavanlainen eli vastaanotetaan monitasoisen rakenteen omaavia sanomia ja on tarkastettava, mitkä tiedot sisältyvät sanomaan.

. Käytetty määrittelykieli voi myös olla erilainen toisessa sovellusympäristössä.

Claims (12)

106507

1. Menetelmä tietosanoman käsittelemiseksi tietoliikenneverkon verkkoelementissä, jonka menetelmän mukaisesti - tietoliikenneverkossa lähetetään verkkoelementille sanomia, joi-5 den rakenne on määritelty tietyn kuvauskielen avulla, jolloin yksittäisen sa-nomatyypin sanomamäärittelyssä on useita peräkkäisiä komponentteja, kuten tekstirivejä, tunnettu siitä, että yksittäisen sanomatyypin sanomamäärittelyn yksittäiseen kompo- 10 nenttiin on sidottu apuparametri (f_xyA...f_xyF), jolla ylläpidetään verkkoelementissä arvoa, joka osoittaa, onko kyseistä komponenttia vastaava sano-manosa mukana käsiteltävässä sanomassa.

2. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että jokaista verkkoelementistä verkkoon lähetettävää ja jokaista verkosta 15 verkkoelementtiin vastaanotettavaa sanomatyyppiä kohti on oma apupara-metrijoukkonsa (AP_xy).

3. Patenttivaatimuksen 1 tai 2 mukainen menetelmä, tunnettu siitä, että yksittäisen sanomatyypin sanomamäärittelyn jokaista komponenttia kohti on oma apuparametrinsä.

4. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että apuparametreille käytetään kokonaislukuarvoja.

5. Patenttivaatimuksen 4 mukainen menetelmä, tunnettu siitä, että ennen lähetettävän tai vastaanotettavan sanoman käsittelyä ko. sanomatyypin apuparametrit initialisoidaan initialisointiarvoihinsa.

6. Patenttivaatimuksen 5 mukainen menetelmä, tunnettu siitä, että joihinkin komponentteihin liittyvien sanomanosien käsittely jätetään verkkoelementissä kokonaan toteuttamatta, jolloin kyseisiä komponentteja vastaavat apuparametrit initialisoidaan initialisointiarvoon, joka poikkeaa niiden apuparametrien initialisointiarvoista, joita vastaavia rivejä vastaavien sa-: — 30 nomanosien käsittely on toteutettu.

7. Patenttivaatimuksen 6 mukainen menetelmä, tunnettu siitä, että apuparametrien arvojen avulla muodostetaan verkkoelementtiin rajoi-tusprofiiii, joka osoittaa, minkälainen sanomajoukon osajoukko on käytössä ko. verkkoelementin ja tietyn toisen verkkoelementin välisessä sanoman 35 vaihdossa. 26 106507

8. Patenttivaatimuksen 1 mukainen menetelmä älyverkon SCP-verkkoelementissä, tunnettu siitä, että apuparametrien arvoja ylläpidetään verkkoelementin sisältämien palvelulogiikkaohjelmien (SLP) avulla, ja että palvelulogiikkaohjelmat sisältävät kutakin vastaanotettavaa sanoma- 5 tyyppiä kohti geneerisen sanomanesikäsittelyrakennusosan (MB), joka siirtää sanomassa tulleet tiedot palveluohjelmien käyttöön ja päivittää apuparametrien arvoja.

9. Patenttivaatimuksen 5 mukainen menetelmä älyverkon SCP-verkkoelementissä, tunnettu siitä, että apuparametrien arvoja ylläpide- 10 tään verkkoelementin sisältämissä palvelulogiikkaohjelmissa (SLP), jotka sisältävät kutakin lähetettävää sanomatyyppiä kohti geneerisen sanomanlä-hetysrakennusosan (TB), joka muodostaa lähetettävän sanoman kirjoittamalla sanomaan vain ne tiedot, joita vastaavien apuparametrien arvot poikkeavat initialisointiarvostaan.

10. Verkkoelementtijärjestely tietoliikenneverkossa, joka käsittää useita verkkoelementtejä ja jossa lähetetään verkkoelementiltä toiselle sanomia, joiden rakenne on määritelty tietyn kuvauskielen avulla, jolloin yksittäisen sanomatyypin määrittelyssä on useita peräkkäisiä komponentteja, kuten tekstirivejä, joka verkkoelementtijärjestely käsittää 20 - elimet verkossa välitettävien sanomien lähettämiseksi ja vastaan ottamiseksi, ja - elimet sanoman sisältämien tietojen tallettamiseksi verkkoelementtiin, , tunnettu siitä, että 25 verkkoelementtiin on talletettu käytetyn kuvauskielen komponent teihin liittyviä apuparametrejä, ja että järjestely käsittää elimet (SLP, MB, TB) apuparametrien ylläpitämiseksi siten, että niiden arvot osoittavat, onko yksittäistä komponenttia vastaava sanomanosa mukana käsiteltävässä sanomassa. ' 30 11. Patenttivaatimuksen 10 mukainen verkkoelementtijärjestely, tunnettu siitä, että verkkoelementtiin on talletettu apuparametrijoukko (AP_xy) jokaista verkkoelementistä verkkoon lähetettävää ja jokaista verkosta verkkoelementtiin vastaanotettavaa sanomatyyppiä kohti.

12. Patenttivaatimuksen 10 mukainen verkkoelementtijärjestely, 35 tunnettu siitä, että yksittäiseen apuparametrijoukkoon on talletettu apu-parametri sanomamäärittelyn jokaista komponenttia kohti. 27 106507