NO311910B1 - Applikasjonsmodularitet i telekommunikasjonssentraler - Google Patents

Description

OPPFINNELSENS BAKGRUNN

Oppfinnelsens område

Den foreliggende oppfinnelse vedrører telekommunikasjonssentraler og mer spesielt en programvarearkitektur som kan benyttes i forbindelse med et telekommunikasjonssvitsjesys-tem styrt av lagret program.

Teknikkens utvikling

På slutten av 1960-årene og tidlig i 1970-årene ble svitsjesystemer styrt av lagret program (SPC) konstruert primært rundt de funksjoner som var nødvendige for å utføre tjenester som relaterte seg til offentlige svitsjede tele-kommunikas jonsnettverk (PSTN) , dvs. vanlig gammeldags tele-fontjeneste (POTS). De SPC telekommunikasjonssvitsjesystemer som ble benyttet for å fremskaffe nevnte PSTN tjenester, ble i virkeligheten konstruert med en styrearkitektur som separerte delene i systemet i funksjonelle blokker, idet hver av disse utførte en separat funksjon ved komplet-teringen av et opprop. F.eks. foreligger det styreblokker i et trafikkstyre-undersystem hos programvaren som utfører digitalanalyse, ruteanalyse, oppkallingsovervåkning, signalering, osv. Hver programvareblokk utfører en viss styre-funksjon eller overvåkningsfunksjon innenfor den maskinvare som bidrar til abonnentsoppkallingsoppsettingen, overvåkning, nedtagning og fakturering.

I løpet av årene ble andre spesielle trekk tilføyet til nevnte POTS tjenester, f.eks. forkortet nummerslåing, opp-ropsavventning og lignende, noe som krevet tilleggelse av programvare til den kjernedel av SPC programvaren som be-tjente svitsjesenteret for å kunne yde disse spesielle tjenester .

Telekommunikasjonssvitsjesystemer styrt med lagret program har utviklet seg i løpet av årene til meget sofistikerte, spesielle høyhastighetsdatamaskiner som omfatter redundant-sentralprosessorer for pålitelighet og fjern-prosessorer for økt hastighet og effektivitet. Et godt eksempel på en slik sentral er SPC telekommunikasjonssvitsjeutstyret av den type som produseres av Telefonaktiebolaget LM ERICSSON og som betegnes som AXE-sentralen, idet en tidligere versjon av denne er omtalt i artikkelen av Mats Eklund, et al., med tittel "AXE 10 System Description", publisert i Ericsson Review, nr. 2, 1976, som herved innlemmes som referanse. Et annet eksempel på en slik SPC telekommunikasjonssentral er omtalt i US patentskrift 4.322.843 (H.J. Beuscher, et al.). Slike svitsjer eller sentraler omfatter vanligvis all den maskinvare som er nødvendig for å utføre en flerhet av forskjellige telekommunikasjonstjenester. F.eks. kan de benyttes som lokale PSTN sentraler, fjerndis-tanse-utenlandssentraler, private automatiske grensentraler (PABX), alle primært ved installasjon av en spesifikk SPC programvare for derved å tilrettelegge disse for de påkrevde spesielle funksjoner.

Etter hvert som telekommunikasjonstjenestene ble mer sofistikerte ettersom tiden gikk, ble det tatt i bruk nye anvendelser for telekommunikasjonssentraler, hvilket krevde ytterligere spesiell funksjonalitet hva angår programvare for styring av sentralen. F.eks. har utviklingen av cellulære radiotelefontjenester gjort det påkrevd at svitsjesentraler må tjene som mobile svitsjesentre (MSC) for styring av mel-lomkobling av forskjellige radiobasisstedstyrere (BSC) og for å tillate mobile abonnenter til å kunne passere fra celle til celle innen radionettverket. På lignende måte har også forekomsten av digitale nettverk med integrerte tjenester (ISDN) i kjølvannet av slike tjenester gjort det påkrevet med spesiell funksjonalitet innenfor svitsjesentra-lene for å kunne yte disse tjenester til abonnenter. Mens et antall av separate spesialiserte sentraler som gir forskjellige tjenester til deres respektive abonnenter kan kobles sammen i et kommunikasjonsnettverk, er dette meget kostbart, både hva angår redundant programvare som drift-og vedlikeholdspersonell med hensyn til å skaffe diskrete sentraler, eller svitsjer som er individuelt programmert med den funksjonalitet som er påkrevet for hver type av telekommunikasjonstjeneste som skal fremskaffes.

Én løsning på det å redusere utgiftene i forbindelse med et telekommunikasjonsnettverk går ut på å fremskaffe en flerhet av forskjellige funksjoner i den samme omkobler eller sentral. Dette innebærer tilføyelsen.av ytterligere programvareblokker i styremodulene av svitsjen, for således å fremskaffe den nødvendige funksjonalitet for at hver tjeneste skal kunne gjennomføres. Slik funksjonalitet kan re-latere seg til spesielle PSTN-forbundne tjenester, forret-ningsgrupper eller tjenester av typen "centrex" (PBAX), ISDN tjenester, MSC tjenester med mer. Problemet i forbindelse med en slik løsning innebærer at mens programvare-kostnadene kan spares ved bruk av samme omkobler for mul-tippelfunksjoner, vil programvaren, og spesielt den innbyrdes samkjøring av forskjellige programvareblokker med hverandre, ble ekstremt kompleks. F.eks. vil tilføyelsen av én ny funksjon på en uheldig måte påvirke eller til og med umuliggjøre utførelsen av en eksisterende funksjon på en totalt uventet måte. Som et resultat, vil en større del av programvare-utviklingskostnadene som man vil stå overfor med slike systemer som er i bruk i dag, være forbundet med det å kunne forutse med hvilken virkning den nye kode som tilføyes systemet, vil kunne ha på den eksisterende kode,

samt med testingen og feilfjerningen av det totale programvaresystem som reaksjon på den kontinuerlige tilføyelse av ny funksjonalitet. Utviklingen av slike "megasystemer" når det gjelder programvare har dramatisk økt kostnadene hva angår tilføyelsene av nye oppgraderinger og ny funksjonalitet til eksisterende tjenester, samtidig som det har økt

utviklingstiden for slik programvare til det punkt hvor nye funksjoner i virkeligheten er blitt gammeldags før de i re-aliteten kan implementeres i omkobleren. Dette er ikke ønskede resultater for telekommunikasjonsselskapene, deres

kunder, eller til syvende og sist for de tjenester som skal

ytes til abonnentene.

En annen løsning hva angår tilføyelsen av multippelfunksjo-ner til en telekommunikasjonssentral, går ut på å fremskaffe multippelprosessorer og dele ut programvaren for å spre denne over flere prosessorer. F.eks. er det ved noen systemer foreslått at én prosessor behandler visse funksjons-blokker av programvare, mens en annen prosessor utfører andre blokkfunksjoner, for derved å søke å redusere kompleksiteten av programvareoperasjonen innenfor hver prosessor. Mens multippelprosessorssystemer eventuelt kan omfatte noen fordeler, f. eks. økt ytelsesevne og oppringningsbaere-kapasitet, foreligger det tydelige ulemper med slike systemer. F.eks. foreligger det en kjede av funksjoner som er påkrevet for oppsetting av et opprop, og disse funksjoner blir spredt over multippelprosessorer, idet en feil i en prosessor kan avbryte hele oppropsoppsettingsprosessen. Dessuten vil dupliseringen av programvare, f.eks. bruken av multippelprosessorer, øke ikke bare kostnaden vedrørende programvaren, men også kostnaden vedrørende hjelpestøtte-og vedlikeholdsfunksjonene. Disse ulemper som er forbundet med multiprosessorsystemer, forekommer enten de mange prosessorer befinner seg i den samme omkobler og plassert på en felles buss, eller om de er plassert i separate omkoblere og er innbyrdes forbundet ved hjelp av et lokalt område-nettverk (LAN).

Enda et annet kjent forsøk for å oppnå multippelfunksjona-litet i forbindelse med en eneste telekommunikasjonssentral, går ut på rett og slett å laste inn multiple funksjo-nalitetsorienterte programvaresystemer i den samme omkobler og kompilere disse som én, hvilket f.eks. innebærer innlas-ting av et PABX programvaresystem direkte inn i en PSTN svitsj. En slik kombinasjon innbefatter minst én stor ulem-pe, idet det er påkrevet med fysiske linjekretser for å kunne utføre det innbyrdes samarbeid mellom PABX delen og den lokale PSTN del. I tillegg kan det forekomme andre konflikter mellom funksjonaliteten hos to forskjellige programvaresystemer, og visselig ingen kooperativ deling av separat aksesserte fellesressurser.

Således ville det være en stor fordel å organisere programvaren i en SPC telekommunikasjonssentral på en måte som

tillater multippelspesifikk telekommunikasjonsanvendelser å kunne utføres med optimal funksjonalitet i den samme omkobler. En slik arkitektur blir fremskaffet ved systemet iføl-ge den foreliggende oppfinnelse.

SAMMENFATNING AV OPPFINNELSEN

Under en første synsvinkel omfatter den foreliggende oppfinnelse et system for å styre en telekommunikasjonssvit-sjesentral styrt av et lagret program hvor systemet er en rekke telekommunikasjonsstyremoduler, idet enhver styremodul er innrettet til å implementere for en bestemt sluttbruker en telekommunikasjonstjeneste fra en gruppe telekommunikasjonstjenester inkludert trådbundne tjenester og celledelte tjenester, en rekke telekommunikasjonsressursmoduler, idet hver ressursmodul er innrettet til å implementere felles støttetjenester for å understøtte operasjoner av i det minste to av nevnte rekke av telekommunikasjonsstyremoduler, organer for å fremskaffe kommunikasjonslinker mellom hver av styremodulene, idet linkene er dannet i samsvar med nettverksprotokoller, og linkene er dannet for å utveksle informasjon uten at noen styremodul er klar over hvorvidt styremodulen som den kommuniserer med, befinner seg i samme sentral.

Under en andre synsvinkel omfatter den foreliggende oppfinnelse en fremgangsmåte for å tilveiebringe telekommunikasjonstjenester til en rekke brukere idet fremgangsmåten er: å koble nevnte brukere til en telekommunikasjonssvitsje-sentral styrt av et lagret program, å aksessere innen sentralen minst én applikasjonsmodul, idet hver applikasjonsmodul inneholder styreinstruksjoner og data for å tilveiebringe én av brukerne en telekommunikasjonstjeneste fra en gruppe telekommunikasjonstjenester inkludert trådbundne tjenester og celledelte tjenester, å aksessere minst én ressursmodul lagret i nevnte sentral, idet hver ressursmodul for kommunikasjon med hver av nevnte applikasjonsmoduler påkrevet for å implementere telekommunikasjonstjenesten, og å kommunisere styreinstruksjoner og data mellom applikasjonsmodul og hver ressursmodul ved bruk av linker for å tilveiebringe telekommunikasjonstjenesten til den ene av nevnte brukere.

Fordelaktige utførelsesformer av oppfinnelsen fremgår av de etterfølgende uselvstendige patentkrav.

KORT OMTALE AV TEGNINGSFIGURENE

For å kunne forstå den foreliggende oppfinnelse, og i relasjon til ytterligere hensikter og fordeler med oppfinnelsen, skal det nå vises til den følgende beskrivelse tatt i forbindelse med de vedføyde tegningsfigurer. Figur 1 er en illustrativ nedtegning av et tidligere kjent programvaresystem i en lokal telekommunikasjonssentral. Figur 2 er en illustrativ nedtegning av tidligere kjent programvare i en telekommunikasjonssentral som skaffer mul-tippelapplikasj onsfunksj onalitet. Figur 3 er en illustrativ nedtegning av programvare i en telekommunikasjonssentral med arkitekturen konfigurert i henhold til systemet ifølge den foreliggende oppfinnelse. Figur 4 er et diagram som anskueliggjør kostnaden relatert til konstruksjon av funksjonalitet inn i telekommunika-s j onsprogramvaresystemer. Figur 5 er et forklarende diagram over multippeldedikerte telekommunikasjonssentraler som er forbundet innbyrdes med hverandre i et nettverk. Figur 6 er et illustrativt diagram over måten på hvilken multippelapplikasjonsfunksjonalitet blir inkorporert i programvaresystemet ifølge den foreliggende oppfinnelse. Figur 7 er et blokkdiagram over det totale konsept som er innlemmet i programvaresystemet ifølge den foreliggende oppfinnelse. Figurene 8 og 9 er blokkdiagrammer som illustrerer kommunikasjon mellom to sentraler ved hjelp av nettverksprotokoll-signalering. Figur 10 er et blokkdiagram som anskueliggjør kommunikasjoner mellom applikasjonsmoduler via interne nettverksprotokoller i henhold til systemet ifølge den foreliggende oppfinnelse . Figur 11 er et blokkdiagram som anskueliggjør visse aspek-ter ved et telekommunikasjonsnettverk relatert til systemet ifølge den foreliggende oppfinnelse. Figur 12 er et blokkdiagram som anskueliggjør en tjeneste-aksessmodul slik denne brukes ved systemet ifølge den foreliggende oppfinnelse. Figur 13 er et blokkdiagram som anskueliggjør visse kommu-nikasjonsaspekter ved systemet ifølge den foreliggende oppfinnelse . Figur 14 er et blokkdiagram som anskueliggjør visse aspek-ter ved kommunikasjon mellom forskjellige sentraler relatert til systemet ifølge den foreliggende oppfinnelse. Figur 15 er et blokkdiagram som anskueliggjør kommunikasjon mellom forskjellige applikasjonsmoduler i det samme svitsj esystem som inkorporerer systemet ifølge den foreliggende oppfinnelse. Figur 16 er et blokkdiagram som anskueliggjør kommunikasjon mellom forskjellige applikasjonsmoduler i forskjellige svitsjesystemer som er innlemmet i systemet ifølge den foreliggende oppfinnelse. Figur 17 er et blokkdiagram som anskueliggjør den funksjonelle dekomposisjon av en aksessapplikasjonsmodul og en forbindelsesovervåkerressursmodul som benyttes i forbindelse med systemet ifølge den foreliggende oppfinnelse. Figur 18 er et blokkdiagram som anskueliggjør forholdet mellom linjefunksjoner i aksessapplikasjonsmoduler og forskjellige tjenesteapplikasjonsmoduler i systemet ifølge den foreliggende oppfinnelse. Figur 19 er et blokkdiagram over aksess- og tjenesteappli-kasj onsmoduler og støtteressursmoduler konstruert i henhold til systemet ifølge den foreliggende oppfinnelse. Figur 20 er et blokkdiagram over en eksisterende applikasjonsmodul og et par av nye applikasjonsmoduler sammen med ressursmoduler i et programvaresystem konstruert i henhold til den foreliggende oppfinnelse. Figur 21 er et blokkdiagram som anskueliggjør kommunikasjon mellom forskjellige aksess- og tjenesteapplikasjonsmoduler i systemet i henhold til den foreliggende oppfinnelse. Figur 22 er et blokkdiagram som anskueliggjør kommunikasjon mellom et par av applikasjonsmoduler via en transaksjons-ressursmodul i systemet ifølge den foreliggende oppfinnelse . Figur 23 er et blokkdiagram over en eksisterende applikasjonsmodul sammen med en flerhet av ytterligere tjeneste-og aksessapplikasjonsmoduler sammen med ressursmoduler i systemet ifølge den foreliggende oppfinnelse. Figur 24 er et blokkdiagram over en flerhet av maskinvare-og programvareelementer som anskueliggjør deres innbyrdes forhold i systemet ifølge den foreliggende oppfinnelse. Figur 25 er et blokkdiagram over applikasjonsmoduler og en forbindelsesovervåkerressursmodul i systemet ifølge den foreliggende oppfinnelse.

DETALJERT BESKRIVELSE

Generell oversikt

Som omtalt tidligere, har SPC telekommunikasjonssentraler

utviklet seg dramatisk i løpet av de siste flere tiår. Opp-rinnelig forelå det en begrenset grad av funksjonalitet inkorporert i hver sentral, og programvaren som implementerte denne funksjonalitet, var rettet primært på fremskaffelse

av lokal PSTN sentraltjeneste. Slik det fremgår av figur 1, er det her vist et lite hus 11 som en metafor som kjenne-tegner programvaresystemet ved en PSTN lokal sentral som er velkjent i henhold til teknikkens stilling. Denne programvare er tradisjonelt blitt organisert i funksjonsorienterte blokker, idet hver av blokkene er konstruert til å utføre en spesifikk funksjonell handling, samt å samvirke med de andre blokker for å på en effektiv måte yte de lokale offentlige telekommunikasjonssentraltjenester like overfor de til denne sentral tilknyttede abonnenter.

Etter som tiden gikk, ble det utviklet en flerhet av nye telekommunikasjonstjenester. Disse tjenester, f.eks. integrerte tjenester i digitale nettverk (ISDN) og offentlige landbaserte mobilnettverk (PLMN), krevet vesentlig forskjellig funksjonalitet i forhold til det som var inkorporert i den programvare som styrte den tradisjonelle PSTN sentral. Slik det metaforisk er anskueliggjort på figur 2, krevde tilføyelsen av ISDN funksjonaliteten 12 og PLMN funksjonaliteten 13 i tillegg til den tradisjonelle PSTN programvarefunksjonalitet 11, et tillegg av tallrike for-sterkninger, forankringer og programvarefikseringer 14, hvilket var nødvendig for å fremskaffe den nye funksjonalitet innenfor det eksisterende rammeverk av konvensjonell PSTN basert programvarearkitektur. Utviklingen av slik ny funksjonalitet og innlemmelsen av denne i det eksisterende strukturelle rammeverk, innebar en betydelig grad av utvik-lingstid og kostnad, så vel som innlemmelsen av tallrike forholdsregler og funksjoner for å kunne sikre at hele funksjonaliteten skulle arbeide harmonisk sammen i samme sentral. Dessuten er konstruksjonen av slike "megasystemer" av programvare i ferd med å nå det punkt hvor kompleksiteten er blitt så stor og utviklingstiden så lang at denne måte å gå frem på, ikke lenger representerer en levedyktig løsning hva angår behovet for ytterligere telekommunika-sjons f unks j oner.

Systemet ifølge den foreliggende oppfinnelse skaffer en arkitekturen nyskapning hva angår programvarestrukturer in-nefor eksisterende SPC telekommunikasjonssentralmaskiner og tillater samtidig utviklingen av individuelle applikasjonsmoduler for fremskaffelse av funksjonalitet for en spesiell telekommunikasjonsapplikasjon, og da i forbindelse med meget effektiv funksjonalitet. Slik det metaforisk er representert på figur 3, kan en PSTN applikasjonsmodul 15 kunne eksistere sammen med en ISDN applikasjonsmodul 16 samt en PLMN applikasjonsmodul 17, idet alle rommes i den samme maskinvare og den samme applikasjonsplattform 18. Veien 19 langs hvilken de alle kommuniserer og står i forbindelse med hverandre, blir dannet ved hjelp av en flerhet av ressursmoduler innenfor den programvare som muliggjør at de respektive applikasjonsmoduler kan kommunisere med og rela-tere seg til hverandre og med respektive ressursmoduler via nettverksprotokoller. Dette innebærer at programvaren i arktekturen ifølge den foreliggende oppfinnelse blir nettverksrelatert i hver sentral på en måte i likhet med den hvorved diskrete sentraler blir nettverksrelatert i forhold til hverandre, slik dette vil bli forklart i ytterligere detalj i det følgende.

På figur 4 er det vist et diagram som anskueliggjør aktuell kostnad for utvikling av suksessive versjoner av tidligere kjent programvare i forbindelse med en telekommunikasjonssentral. Slik det er vist, omfatter utviklingskostnader ved en utgave av en programvarepakke 21, en viss startkostnad 22, samt innbefatter en økende grad av arbeid etter som ytterligere funksjoner blir føyet til denne programvare. Til slutt vil kostnaden ved addering av ytterligere funksjoner bli så prohibitiv at en spesiell programvarepakke når sitt strukturelle skjæringspunkt 23 og krever en ny konstruksjon eller ny form. Produksjonskostnadene for den neste utgave av programvaren 24, omfatter en viss omkonstruksjonskost-nad, fortrinnsvis påløpt ved en kosteffektiv tid som ligger forut for skjæringspunktet for den første programvareutgave 21. Ettersom ytterligere funksjoner blir føyet til den neste utgave av programvaren 24, vil også denne nå et skjæringspunkt 26 og på nytt kreve en omkonstruksjon til en tredje utgave 27, osv. Slik det tydelig fremgår av figur 4, vil mengden av arbeid og således kostnadene relatert til tilføyelsen av ytterligere funksjoner til konvensjonelle telekommunikasjonsprogramvarepakker bli dyrere jo mer kompleks programvaren blir. Til slutt vil programvaren bli så kompleks at den ikke lenger kan kunne modifiseres, og den vil da kreve en full omkasting for å kunne forsette å utfø-re sine funksjoner. Systemet ifølge den foreliggende oppfinnelse skaffer en arkitektur som dramatisk forenkler den iboende nødvendighet av oppgradering av telekommunikasjons-programvare i forbindelse med tilføyelse av ny funksjonalitet, og vil således dramatisk redusere kostnadene ved slik kontinuerlig vekst og tilhørende ekspansjon av telekommuni-kas j onstjenester.

Figur 5 anskueliggjør et tradisjonelt telekommunikasjonsnettverk hvori objektene i nettverket utgjøres av sentraler. En lokal PSTN sentral 31 tjener sine lokale abonnenter og er forbundet via linjer 32 med en PSTN transittsentral 33, som på sin side er forbundet med en internasjonal PSTN passasjesentral 34. For illustrasjonens skyld er nevnte sentraler 31-34 plassert i et første land 35, samtidig som de er forbundet med sentraler i et andre land 36 ved hjelp av internasjonale sambandslinjer 37 forbundet med en internasjonal PSTN sentral 38. De ytterligere sentraler som be-tjenes av den internasjonale PSTN sentral 38, kan omfatte en nasjonale ISDN sentral 39 samt en nasjonal PSTN sentral 40, idet hver av disse omfatter en flerhet av abonnenter og er forbundet ved hjelp av sambandslinjer 41. Dessuten kan den nasjonale PSTN sentral 40 også være forbundet via en linje 41 med en flerhet av private PABX sentralnettverk 42 og 43 som yter tjenester til deres respektive abonnenter. Slik det fremgår av figuren, er sentraler i et slikt inter-nasjonalt nettverk koblet sammen ved hjelp av forskjellige nettverklinjer, samtidig som de kommuniserer med hverandre ved hjelp av nettverksprotokoller slik at de kan betjene sine respektive områder ved fremskaffelse av kommunikasjoner mellom sine respektive abonnenter og andre abonnenter i nettverket.

Under henvisning til figur 6 er det der vist en anskuelig-gjørelse av programvaresystemet ifølge den foreliggende oppfinnelse, hvori en eneste sentral 51 kan ses på som å omfatte en flerhet av separate logiske knutepunkter, og funksjonaliteten hos disse knutepunkter og de innbyrdes koblinger mellom dem er innlemmet i en eneste sentral 52 som inneholder programvaresystemet ifølge den foreliggende oppfinnelse. F.eks. kan et lokalt PSTN knutepunkt 53 kunne tilkobles et ISDN knutepunkt 54, idet begge disse er tilkoblet et knutepunkt 55 for privat forretningsgruppe, som på sin side er tilkoblet et annet knutepunkt 56 for privat forretningsgruppe. Det lokale PSTN knutepunkt 53 kommuniserer er med forretningsgruppeknutepunktet 55 via en mul-tifrekvenskode (MSC) protokoll, mens ISDN knutepunktet 54 kommuniserer med både det lokale PSTN knutepunkt 53 og det private forretningsgruppeknutepunkt 55 via CCITT telefonbrukerdel (TUP) protokollene 58 og 59. ISDN knutepunktet 54 kan kommunisere med andre ISDN knutepunkter via en integrert tjenestebrukerdel (ISUP) protokoll 61, og det private knutepunkt 56 kommuniserer med det private knutepunkt 55 via en digital privat nettverkssignaleringssystemsprotokoll (DPNSS) 62. Hver av de separate knutepunkter 53-56 omfatter telefonabonnenter 63, mens det private forretningsgruppeknutepunkt 56 og ISDN knutepunktet 54 også kan omfatte da-takommunikasjonsabonnenter 64. Den måte på hvilken hver av disse knutepunkter kommuniserer med andre knutepunkter via visse definerte protokoller, blir reflektert i programvare-arkitekturen hos den foreliggende oppfinnelse som i en eneste omkobler 52 omfatter funksjonaliteten hos det lokale PSTN knutepunkt 53 ved innlemmelse av en PSTN applikasjonsmodul 65. På lignende måte er funksjonaliteten hos ISDN knutepunktet 54 innlemmet i en ISDN applikasjonsmodul 66, mens funksjonaliteten hos det private forretningsgruppeknutepunkt 55 er innlemmet i en forretningsgruppeapplikasjonsmodul 67, idet hver av disse kan kommunisere med hverandre via en definert TUP protokoll 68 og med en flerhet av felles ressurser 69 via definerte grensesnitt 71. De felles ressurser 69 kan omfatte omkoblere, belastningsovervåkere (LOAS), annonseringsmaskiner (ASAM), meldingsoverføringsde-ler (MTP) og annet. Slik det fremgår av figur 6, vil innlemmelsen av funksjonaliteten i diskrete applikasjonsmoduler i den samme omkobler 52 innebære store fordeler hva angår forenkling av programvaren til spesifikke applikasjons-funksjoner. Ved systemet i henhold til den foreliggende oppfinnelse vil nettverksdrift innenfor programvaren bli utført på en lignende måte innenfor omkobleren 52 som utenfor sentralen.

På figur 7 er det vist et blokkdiagram over komponenter i programvaresystemet ifølge den foreliggende oppfinnelse 72, omfattende en flerhet av individuelle applikasjonsmoduler

73 som er innbyrdes forbundet og koblet både med hverandre og med en flerhet av ressursmoduler 74. Applikasjonsmodulene (AMer) 73 kommuniserer med hverandre og med ressursmodulene (RMer) ved hjelp av definerte protokoller 75 mellom

AMer 73 og definerte grensesnitt med RMer 74, som i virkeligheten fremskaffer reelle svitsjer og muliggjør innbyrdes operasjon og nettverksdrift av programvaren på en måte som tillater effektiv implementering av diskrete telekommunika-sjonsapplikasjonsorienterte blokker. Denne arkitektur innebærer store fordeler ved implementeringen av programvaren, idet det tillates individuell tilpasning av hver applikasjonsmodul til den individuelle funksjonalitet som har tilknytning til en spesiell telekommunikasjonsapplikasjon. F.eks. er den funksjonalitet av programvaren som er nødven-dig for å implementere en forretningsgruppekommunikasjons-applikasjon, vesentlig forskjellig fra det som er nødvendig å implementere i en ISDN applikasjon. Ved oppdeling av programvaren i applikasjonsorienterte moduler oppnår man frem-skaffelsen av diskrete telekommunikasjonsfunksjoner som er individuelt konfigurerte for spesielle applikasjoner uten behovet for at programvaren for én applikasjon samvirker med programvaren som er rettet på en fullstendig forskjellig applikasjonsfunksjonalitet, hvilket er tilfelle med de foreliggende programvarestrukturer i en enkeltstående tele-kommunikas j onssentral . Hver av applikasjonsmodulene kan på enkel måte kommunisere med hverandre og kan trekke fordel av ressursmodulene i programvaren, hvilket fremskaffer alle nødvendige innbyrdes operasjoner med omkoblermaskinvaren og visse funksjonelle tjenester som er tilgjengelige for de individuelle applikasjonsmoduler og er felles for flere enn én av applikasjonsmodulene. I virkeligheten omfatter hver applikasjonsmodul en reell omkobler eller en reell sentral som oppfatter den eier omkoblermaskinvaren og står fritt med hensyn til å utnytte denne programvare eksklusivt for sin egen distinkte applikasjonsorienterte funksjonalitet. Denne arkitektur tillater tilføyelsen av oppgraderinger til programvaren samt bestyrkning av funksjonaliteten for én applikasjonsmodul uten at det trengs å ta hensyn til virkningen av disse programvareendringer på andre applikasjonsmoduler. Fordi sentralen ikke lenger styres av en enkeltstående hoveddel av funksjonalitetsoppdelte blokker, så er det atskillig mindre sannsynlighet for at en modifika-sjon av en funksjonalitetsegenskap hos én applikasjon på negativ måte vil påvirke utøvelsen av denne funksjon ved en

annen applikasjon.

APPLIKAS JONSMODULNETTVERKS SPE SI FIKAS JON

Generelle prinsipper

Ved spesifisering av det øvre nivå eller tjenestenivået hos en hvilken som helst applikasjonsmodul, f.eks. det hos en forretningskommunikasjonsgruppe, blir tjenestene beskrevet slik de beskues fra utsiden av systemet. Nettverksnivået blir imidlertid rettet på tjenestene slik de beskues inne i selve applikasjonsmodulen. To hovedprinsipper som bør observeres, omfatter: 1. En tjeneste bør fremstå som den samme like overfor brukeren, uansett om de andre brukere som er involvert i tjenesten, befinner seg på det samme eller andre knutepunkter i nettverket, og 2. Brukeren må være i stand til å forflyttes fra et knutepunkt til et annet uten nødvendigheten av å endre brukerens nummer.

På nettverksnivået vil de tjenester som skal fremskaffet, bli vurdert i relasjon til de krav de setter til nettverket. Dessuten har nettverksnivået å gjøre med allokasjonen av funksjonalitet i nettverket, samt til oppgaver vedrøren-de sentralisert eller distribuert styring innenfor nettverket .

Generelt går det første trinn ut på å vurdere hvordan en telekommunikasjonsapplikasjon blir spesifisert, noe som kan innbefatte spesifikasjon relatert til en utvikling av et allerede spesifisert tjenestenettverk, f.eks. PSTN, eller som et separat tjenestenettverk, f.eks. ISDN, slik dette er spesifisert ved C.C.I.T.T. Det andre trinn går ut på å identifisere en referansemodell for tjenestenettverket, f.eks. knutepunkter med spesifiserte referansepunkter derimellom, f.eks. aksess og overføringsknutepunkter med spesifiserte protokoller som referansepunkter. Denne referansemodell for et tjenestenettverk vil danne basisen for struktureringen av systemet til AMer. I referansemodeller for knutepunkter blir felles funksjonalitet identifisert og vil danne basisen for struktureringen av systemet i RMer.

Nettverksmodellen

Generelt kan et nettverk betraktes som en flerhet av knutepunkter som er forbundet ved hjelp av linjer. I et telekom-munikas j onsnettverk omfatter knutepunktene telefonsentraler, abonnenter og annet periferiutstyr, f.eks. datamaskin-databaser. Tradisjonelt er styreknutepunktene i et nettverk konstruert til å utøve spesielle roller, f.eks. som lokale sentraler, overgangssentraler, mobile abonnentsentraler og lignende. Imidlertid blir flere og flere sentralknutepunk-ter pålagt å utføre mer enn én rolle på samme tid. Dette har ofte bevirket problemer hva angår konstruksjon på grunn av den innbyrdes påvirkning av de forskjellige krav til hver rolle. Dette er spesielt tilfelle med centrex forretningsgruppe-kommunikasjonsfunksjoner hvor det er et behov for å se en centrex gruppe som en separat PABX, som er isolert fra de offentlige svitsjefunksjoner hos systemet.

Det foreligger telekommunikasjonsadministrasjoner som spe-sifiserer forretningskommunikasjonstjenester som et separat tjenestenettverk. Referansemodellen for forretningskommuni-kasjoner omfatter aksessknutepunkter og tjenesteknutepunk-ter. Disse danner basisen for identifikasjonen av forretningsgruppen AM, den analoge aksess AM, samt den digitale aksess AM.

Dersom man betrakter de knutepunkter som det er ønsket å

implementere i et nettverk som logikkelementer i stedet for fysiske elementer, så kan dette fremskaffe en mer fleksibel løsning på problemene. Hver logikkelement kan betraktes som en komponent i en applikasjon ved hvilken forretningsgrup-

peapplikasjonsmodulen bare er ett eksempel. Andre eksempler omfatter PSTN knutepunktet, MSC knutepunktet, osv., og hver applikasjon understøtter en flerhet av allerede definerte grensesnitt, f.eks. MSC, C7, DASSI, DPNSS, R2, osv., idet hver av disse kan benyttes for innbyrdes kobling av forskjellige applikasjonsmoduler, både internt og eksternt innenfor den fysiske sentral. En slik logikknutepunktorien-tert struktur tillater definisjonen og utviklingen av applikas j onsmoduler atskilte fra hverandre ved bruk av definerte grensesnitt.

Det er blitt foreslått at grunnleggende kommunikasjonsegen-skaper skulle kunne utnyttes i en hvilken som helst applikasjon, men hver applikasjon har sine egne distinktive ny-anser og krav for hvert grunnleggende trekk, på grunn av egenskapen hos de kommunikasjonstjenester som skal ytes. F.eks. har samtalediversjonstrekket forskjellige spesifikke krav når det implementeres for PSTN tjenester, forretnings-gruppetjenester, mobiltjenester, samt ISDN tjenester. Dersom det bare forelå kun ett samtalediversjonstrekk innenfor systemet, ville det således bli påvirket av tilføyelsen av hver ny applikasjon til systemet.

I henhold til systemet ifølge den foreliggende oppfinnelse kan hver applikasjon konstrueres på den mest hensiktsmessi-ge måte med grunnleggende trekk tilpasset til denne spesielle applikasjon. Hver applikasjon ville bli representert som en funksjonell modular enhet som fritt kan kombineres i en sentral med et hvilket som helst antall av andre applikasjoner. I forbindelse med nettverksmodellen vil én utfø-relse av applikasjonsmodulen bli kalt et logikk-knutepunkt. Logikk-knutepunktene er alle sammenknyttet via linjer for dannelse av et logikknettverk.

Nettverksmodellen skaffer den mulighet at telekommunika-sjonsapplikasjonene kan dekomponeres funksjonelt for komplekse tjenester, nemlig til en flerhet av enkle applikasjonsmoduler. Hver modul kan konstrueres isolert fra de andre, og det foreligger intet behov hva angår bekymringer om innbyrdes påvirkning av andre moduler eller den interne operasjon av andre moduler. Når først forholdsreglene er blitt implementert i henhold til slike nettverksprinsipper, vil alle tjenester funksjonere likt uavhengig av hvorvidt de involverte abonnenter er plassert i det samme eller i separate knutepunkter, og nettverkstransparens hva angår tjenester vil således bli oppnådd.

Ved anvendelse av disse prinsipper i forbindelse med for-retningsgruppetjenester, som et eksempel på applikasjonsmodul, vil en abonnent ikke ønske å bli belemret med imple-menteringsproblemer. Implementering av nettverk ved hjelp av sentraler som er koblet sammen via linjer i stedet for ved hjelp av en eneste sentral, bør ikke tillate at den ytede tjeneste blir gradert. Når en samtale skal opprettes, vil systemet bli informert om den ønskede destinasjon av samtalene ved hjelp av en streng av digitale tegn betegnet som et katalognummer. Et katalognummer skal identifisere den ønskede bruker, og skal ikke har tilknytning til en spesiell post av brukerutstyr. Abonnenten definerer det nummerplan som skal benyttes innenfor forretningsgruppen, og allokeringen av interne katalognumre er fullstendig under brukerens styring. Imidlertid, for samtaler utenfor forretningsgruppen, må katalognummeret stemme overens med ytre avtale og/eller standarder, og nummerplanet må også tillate initiering av tjenester og fasiliteter ene og alene ved nummerslåing/tasting av digitale sifre uten uoverens-stemmelser .

Den generiske systemnivåarkitektur for hver applikasjonsmodul i en sentral som er anordnet i henhold til systemet

ifølge den foreliggende oppfinnelse, omfattende det eksempel som her er omtalt i forbindelse med forretningsgruppen, benytter den delte bruk av ressursmodulene. Aksessapplikasjonsmodulene eier linjeaksessmaskinvaren sammen med noe programvare som har tilknytning til grensesnittet. De har ingen kjennskap til eller forståelse av noen av de under-

støttede tjenester. Ressursmodulene skaffer generelle un-derstøttelsesfasiliteter for alle applikasjonsmoduler i sentralen. Transaksjonsovervåkerdressursmodulen skaffer felles fasiliteter til alle applikasjonsmoduler for å kunne assistere transporten av meldinger. Den etablerer linjer mellom programvarekomponenter i forskjellige applikasjonsmoduler. Forbindelsesressursmodulen eier omkoblermaskinvaren og andre gruppeorienterte ressurser, f.eks. tonemotta-kere, multiforbindelser og lignende, hvilket gjør det mulig for applikasjonsmodulene å bruke disse ressurser og løse eventuelle konflikter og behov for samme forbindelse eller ressurs. Andre ressursmoduler, f.eks. belastningsstøtte, operasjons- og vedlikeholdsstøtte, analysestøtte, tidsover-våkningsstøtte, og lignende, vil også bli benyttet ved as-sistanse for applikasjonsmodulene. Ressursmodulene ifølge det foreliggende system kan betraktes som et sett av verk-tøy, hvorved hver applikasjonsmodul selekterer og bruker det som er nødvendig fra verktøyboksen for dennes spesifikke telekommunikasjonsapplikasjon. Ressursmodulene blir aksessert via sine grensesnitt, som er fullstendig bakover-kompatible. Ressursmodulene skaffer en plattform for under-støttelse av telekommunikasjonsapplikasjonenes konstruksjon, dvs. applikasjonsmodulene. De forskjellige komponenter for begge applikasjonsmoduler og ressursmoduler blir implementert i programvareblokker.

Nettverkskommunikasj oner

Fordi tilveiebringelsen av en telekommunikasjonstjeneste nødvendigvis innbefatter mer enn en forholdsregel, er det nødvendig å ta i betraktning hvordan de forskjellige forholdsregler eller objekter kommuniserer med hverandre. Slik kommunikasjon utføres ved hjelp av protokoller. Det foreligger hovedsakelig tre typer av kommunikasjonsprotokoller i arkitekturen:

1. intranettverkskommunikasjonsprotokoller,

2. interne protokoller,

3. internettverkskommunikasjonsprotokoller.

Nevnte intraprotokoller innebærer kommunikasjon mellom in-telligente objekter som danner del av det samme nettverk.

Bruken av protokoll er nødvendig for understøttelse av alle tjenester som ytes av dettes nettverkstype. Den informasjon som skal bæres mellom applikasjonsmoduler, omfatter all den informasjon som skal bæres mellom separate knutepunkter i den samme nettverkstype. Således vil den protokoll som skal benyttes mellom applikasjonsmoduler, bli et supersett av den protokoll som er definert for bruk mellom knutepunkter, f.eks. vil de lavere nivåer følge anbefalingene ifølge Q900-seriene. Fordi det for nåværende ikke foreligger noen enighet om internasjonale standarder for nettverk med for-retningsgruppetjenester som standard, f.eks. den åpne U.K. DPNSS standard av informasjon, kan man benytte en strøm i like tilfeller.

Hensikten med de interne protokoller er å kommunisere mellom alle aktuelle objekter som er nødvendige for å kunne understøtte telefonitjenestene. Slike protokoller må være i stand til å formidle: 1. informasjonselementer av bare intern betydning, f.eks. tilkoblingsreferansepunkt, 2. informasjonselementer som er påkrevet for understøtt-else av en grunnleggende telefonitjeneste, og 3. omhylninger for informasjonselementer av betydning bare for spesielt sofistikerte signaleringssystemer.

Nevnte internettverkskommunikasjonsnettverksprotokoll omfatter standard digitale protokoller som benyttes ved tele-kommunikas j onssystemer . Dette innebærer f.eks. telefonbrukerdel (TUP), integrert tjenestebrukerdel (ISUP), nasjonal brukerdel (NUP), osv., og disse kan benyttes som de for nåværende blir benyttet mellom knutepunkter i et telekommuni-kas j onsnettverk som i dag omfatter separate omkoblere. En porttjenestemodul blir benyttet for hver type av applikasjonsmodul og kommuniserer med applikasjonsnettverket for de andre typer nettverk via transaksjonsunderstøttelse.

Programvaremodulkommunikasj on

En viktig side ved systemet ifølge den foreliggende oppfinnelse er tilveiebringelsen av effektiv kommunikasjon mellom de forskjellige programvaremoduler. Kommunikasjonen mellom applikasjonsmoduler er nettverksorientert, mens kommunikasjonen mellom applikasjonsmoduler og ressursmoduler er sys-temorientert. Nettverksorientert kommunikasjon fremstår i form av protokoller som er spesifisert og utgjør veldefi-nerte regler for styring av informasjonsoverføring mellom systemer, f.eks. telefonsentraler. Protokoller består av sekvenser av meldinger med spesifikke formater og innhold, f. eks. TUP, MFCR2, TCAP, osv. Figurene 8 og 9 anskueliggjør kommunikasjon mellom et par sentraler i henhold til CCITT signalsystemet nummer 9 telefonbrukerdel (TUP) signale-ringsprotokollen. Figur 9 viser at meldingsoverføringsdelen (MTP) svarer til tilnærmet lag 1-3, og at brukerdelen (UP) representerer de gjenværende lag 4-7. Eksempler på bruker-deler omfatter telefonibrukerdel (TUP), integrerte tjenester digitalt nettverk brukerdel (ISDN UP), osv. En protokoll som kan kommunisere med andre sentraler, blir dokumen-tert i form av en protokollbeskrivelse (PD) som omtaler alle lag 1-7, f.eks. MTP (ytterligere eksemplifisert i den gule og røde bok av C.C.I.T.T.), formatet av meldinger i brukerdelen, koding av informasjonsfelter, prosedyre, osv.

Slik det er omtalt ovenfor, vil en flerhet av eksisterende nettverksprotokoller kunne tilveiebringe kommunikasjoner mellom applikasjonsmoduler i henhold til systemet ifølge den foreliggende oppfinnelse. I det følgende er det angitt en liste som inneholder illustrative representative protokoller som kan benyttes ved spesielle utførelsesformer av det foreliggende system sammen med en referanse til nevnte C.C.I.T.T. dokumentasjon av samme, som herved innlemmes som referanse.

For å anskueliggjøre hvordan signalering blir utført i en sentral som er strukturert i henhold til applikasjonsmodul-aritetskonseptet, er det på figur 1 vist en samtale som finner sted via en slik sentral. Den protokoll som vedrører applikasjonsmodul til applikasjonsmodul, og som er vist i sentral B på figur 10, representerer en intern type av protokoll, dvs. en protokoll som bare blir benyttet for kommunikasjon mellom applikasjonsmoduler som er plassert i samme sentral. I stedet for å bruke meldingsoverføringsdelen

(MTP) som en ende-til-ende-bærer for lag 1-3, gjør applika-sjonsmodulprotokollen bruk av de tjenester som ytes av transaksjonsovervåkerressursmodulen som er innlemmet i systemet ifølge den foreliggende oppfinnelse. Protokollen ved-rørende applikasjonsmodul til applikasjonsmodul blir doku-mentert og tilveiebringer spesifikke formater av meldinger,

koding av informasjonsfelter, samt andre prosedyrer som er spesifikke hva angår den protokoll som dekker lagene 4-7. Innenfor disse protokoller kan det foreligge en flerhet av spesifikke og forskjellige protokoller vedrørende applikasjonsmodul til applikasjonsmodul.

Forskjellen mellom en "ekstern" protokollfunksjonell spesifikasjon, dvs. ISUP, og en "intern" protokollfunksjonell spesifikasjon, dvs. NUP, omfatter følgende: 1. En ekstern protokoll er påkrevet for å bære de data som vedrører de involverte fysiske ressurser, f.eks. PCM kanaler, og hvordan disse ressurser er knyttet til samtalene. Dette krever at operasjon og vedlikeholdsprosedyrer samt meldinger blir innlemmet for å kunne håndtere disse ressurser, f.eks. blokkering, osv. Dette er ikke tilfelle for interne protokoller fordi det her ikke benyttes noen fysiske ressurser, men bare logikk-kretser. 2. Lengden av meldinger, meldingsstrukturer og koding av informasjon kan være forskjellig hva angår interne og eksterne protokoller, fordi disse benytter forskjellige bærere for lagene 1-3, dvs. MTP tjenestene eller transak-sjons tj enestene.

3. Interne protokoller kan kreve ytterligere informasjon

vedrørende f.eks. sesjonsreferanser for belastende utgang, logikk-kretsreferanser, osv., som ikke er påkrevet innenfor en ekstern protokoll.

Noen av de felles elementer mellom ekstern og intern protokoll går ut på at begge bør være i stand til å tilfreds-stille følgende: 1. Begge bør håndtere "fiendtlige" omgivelser fordi ting av og til går galt og meldinger forsvinner og det derfor kreves tiltak for å verne mot denne mulighet. 2. Begge skal ikke reflektere den interne struktur av applikasjonsmodulene eller strukturen av den spesielle fab-rikkants maskinvare. 3. Ingen av disse bør anta en spesifikk bruker av protokollen, og 4. Begge bør være "komplett" med hensyn til å dekke alle lag 1-7. Kommunikasjonen applikasjonsmodul til ressursmodul blir strukturert i form av et systemgrensesnitt sett fra applikas jonsmodulens synsvinkel, hvilket innebærer at begge elementer i kommunikasjonen rommes innenfor den samme omgivel-se, dvs. innenfor et felles styresystem. Applikasjonsmodul-protokoller fremstår som make-til-make kommunikasjon, mens applikasjonsmodul til ressursmodul grensesnitt er klient til tjenesteformidlerorientert. Brukergrensesnittet vedrø-rende en ressursmodul kan omfatte PLEX signaler, og grensesnittet er beskrevet i en grensesnittspesifikasjon. En ressursmodul har et grensesnitt som er det samme for alle AMer/RMer som ikke tillater noen unike signaler å bli sendt fra en RM. For å kunne yte en tjeneste kan én RM kalle opp tjenestene hos andre RMer. Figur 10 viser et. eksempel på en applikasjonsmodul som benytter grensesnittet, og derfor tjenestene fra en transaksjonsovervåkerressursmodul. Føl-gende punkter bør observeres ved strukturering av opp-legg/oppbygning av ressursmodulgrensesnitt: a) geografisk fordeling er ikke en faktor som trenger å vurderes, fordi ressursmodulene bare kan aksesseres innenfor det samme system, b) forskjellige fabrikkanter av utstyr utgjør ikke en faktor som trenger å bli vurdert, fordi ressursmodulene

alle er omfattet i et eneste system,

c) forskjellige brukere er faktorer som man må ta hensyn til fordi ressursmoduler blir benyttet i forbindelse med forskjellige applikasjonsmoduler og yter forskjellige fysiske tjenester til disse applikasjonsmoduler, og d) det bør bibeholdes et klient/tjenesteyter-forhold mellom kommunikasjonen med ressursmodulene.

Ved dokumentering av de grensesnitt som skal benyttes i systemet ifølge den foreliggende oppfinnelse, kan slike grensesnitt spesifiseres ved hjelp av programvaresignaler som omfatter meldings- og kodeinformasjonen. Hver ressursmodul kan tilby en flerhet av forskjellige tjenester, idet det foreligger en flerhet av forskjellige grensesnitt. F.eks. kan de nåværende konstruksjonsregler i forbindelse med meldingsoverføringsdelene for konvensjonelle protokoller representere gode eksempler på slike applikasjonsmodul/ressursmodulgrensesnitt. Således kan slike grensesnitt spesifiseres samtidig med antallet av programvaresignaler som man trenger for å fremskaffe den tjeneste som tilbys av ressursmodulen. Et slikt grensesnitt kan innbefatte de nåværende konstruksjonsregler for bruken av meldingsoverfø-ringsdeltjenester innenfor det felles kanalsignaliseringun-dersystem (CCS) for AXE-10 SPC svitsjesystemet.

Aksesstruktur i applikasjonsmodulnettverk

Begrepet "aksess" blir her benyttet for de midler som en bruker har behov for å nå frem til brukertjenestene som det abonneres på i kommunikasjonssystemet. Den følgende beskrivelse vil identifisere disse midler i form av komponenter eller funksjonelle enheter idet det benyttes en objektori-entert vurdering. En slik vurdering understøtter rask utvikling av de påkrevde aksesser, idet det tillates en klar separasjon mellom teknologi og funksjonalitet, mellom aksess og brukertjenester, og mellom trafikkhåndtering og operasjoner og vedlikehold. De identifiserte komponenter definerer en aksessobjektstruktur som kan benyttes som en basis ved definisjon av aksessproduktstrukturen. I aksess-området for det foreliggende system forekommer det to ak-sessapplikas jonsmoduler, en analog aksessapplikasjonsmodul (AAM) samt en digital aksessapplikasjonsmodul (IAM). Ved strukturering av aksessen innenfor det foreliggende system må visse grunnleggende prinsipper følges: 1. Aksess og brukertjenester er separate og således vil ingen abonnentkjennskap, abonnentdata eller brukertjenester være del av aksessapplikasjonsmodulene. 2. Fysisk fordeling av aksessapplikasjonsmodulene mulig-gjøres ved hjelp av en nettverksprotokoll mellom aksessapp-likas j onsmodulene og tjenesteapplikasjonsmodulene . 3. Fysisk fordeling av omkoblere innenfor det samme svitsj esystem er skjult fra omkoblerbrukerne. Dette oppnår man ved å definere et kommunikasjonsgrensesnitt til en forbindelsesovervåkerressursmodul som styrer de forskjellige omkoblere i svitsjesystemet. 4. Funksjonalitet og teknologi er skilt fra hverandre. Dette innebærer teknologi, dvs. det lave lag (OSI lag 1-2) med tilhørende funksjonalitet er avhengig av høynivåfunk-sjonaliteten, f.eks. brukertjenester implementert i tele-kommunikas j onsnettverket , idet dette definerer lavlagprotokoller som ikke bærer høynivåkunnskap. Dette muliggjør fornyet bruk av teknologien i forbindelse med en flerhet av høynivåfunksj onalitet.

Slik det fremgår av figur 11, er det her vist at et tele-kommunikas j onsnettverk 200 omfatter en flerhet av fjerntliggende funksjonelle enheter for å kunne utføre sitt til-tenkte formål. For å kunne yte en telekommunikasjonstjeneste for en bruker, omfatter nettverket 200 en aksess-komponent 201, en brukertjenesteenhet (USE) 202 og en nett-verkstjenesteenhet (NSE) 203. Brukeren kan være representert enten som et menneskelig vesen, et anvendelsesprogram eller andre brukere som søker å gjøre bruk av brukertjenestene som det abonneres på i telekommunikasjonsnettverket 200. Aksessenheten 201 tilveiebringer de midler som er nød-vendige for brukeren for å nå de brukertjenester som det abonneres på. Brukertjenesteenheten 202 fremskaffer og ut-fører de tjenester for brukeren som det abonneres på, ved håndtering av tjenesteinteraksjoner, og belaster den enhet som har abonnert på tjenestene, og lignende. Nettverkstjenesteenheten 203 skaffer informasjonsoverførings-mulighet og tjenester, f.eks. fremskaffer den bæretjeneste og de muligheter som er beskrevet i CCITT sin anbefaling 1.210.

Slik det fremgår av figur 12, er det der vist hvordan tje-nesteaksess som tjenesteapplikasjonsmodulen 204 benytter seg av i systemet ifølge den foreliggende oppfinnelse, omfatter brukertjenesteenheten 202 samt nettverkstjenesteenheten 203. Tjenesteapplikasjonsmodulen 204 blir på sin side aksessert av brukeren via en aksessapplikasjonsmodul 201. Figur 13 anskueliggjør de forskjellige fysiske aksess-produkter på et svitsjenettverksnivå, og anskueliggjør at brukerne kan aksessere en svitsj 205 i et svitsjesystem 206 enten direkte via den sentralt lokaliserte abonnentsvitsj (SSS) 207 eller på avstand via en fjerntliggende abonnentsvitsj 208 og et transmisjonsnettverk 209. Figur 14 an-skueliggjør at en bruker kan aksessere et hvilket som helst antall av varianter av svitsjer 206a-206c i svitsjesystemet 206 via et transmisjonsnettverk 209 ved bruk av standard protokoller via et uavhengig aksessprodukt 210, f.eks. en aksessmultiplekskonsentrator (AMC). Et slikt produkt 210 er i seg selv et homogent svitsjesystem som kan tjene andre homogene svitsjesystemer med aksesstjenester på et svitsjenettverksnivå uavhengig av hvilket av de spesielle svitsjesystemer 206a-206c som blir aksessert.

En grunn for å ha en nettverksprotokoll for aksessapplikasjonsmodulene 204a og 204b, er at det vil muliggjøre fysisk distribusjon av terminalutstyr og linjer i svitsjenett-verket. På denne måte kan aksessapplikasjonsmodulen kartlegges ved et fysisk aksessprodukt i et annet svitsjesystem enn brukertjenesteenheten, slik dette er vist på figurene 15 og 16. På figur 15 omfatter et svitsjenettverk 201 et svitsjesystem 206 omfattende en analog aksessapplikasjonsmodul/digital aksessapplikasjonsmodul 226/227 som kommuniserer med brukertjenesteenheten 202 for en tjenesteapplikasjonsmodul 204 via en nettverksprotokoll 229. På figur 16 omfatter på lignende måte et svitsjenettverk 201 to svitsj esystemer 206a og 206b, idet en av disse omfatter den analoge aksessapplikasjonsmodul/digitale aksessapplikasjonsmodul 226/227, mens den andre omfatter brukertjenesteenheten 202 i tjenesteapplikasjonsmodulen 204. Ved dette forhold kommuniserer aksessmodulen 226/227 med brukertjenesteenheten i tjenesteapplikasjonsmodulen 204 ved hjelp av den samme nettverksprotokoll 229, og denne gang koblet via et transmisjonsnettverk 209 i stedet for direkte mellom selve applikasjonsmodulene. Begge svitsjesystemer 206a og 206b ville også innbefatte grensesnitt mot det mellomlig-gende transmisjonsnettverk 209 for å kunne implementere nettverksprotokollen 229 og kommunisere gjennom nevnte.

Det skal nå vises til figur 17, hvorpå det er vist en funksjonell dekomposisjon av nevnte analoge/digitale aksessapplikasjonsmodul, samt dekomposisjonene av linjeinngangen (LE) 231 og en tilkoblingsovervåker 145, hvilket anskue-liggjør nevntes tette relasjon til hverandre. Det fremgår av figuren at analog/digital aksessapplikasjonsmodulen

226/227 omfatter en linjeinngang (LE) 231 og en linjehånd-terer (LH) 232. Linjeinngangen 231 omfatter en hoveddistri-busjonsramme/automatisk krysskobling (MDF/ACC) 233, samt en linjeterminal (LT) 234 og en signaleringsterminal (ST) 235. En koblingsovervåkerressursmodul 145 f.eks., omfattende aksess til en tidssvitsj 156g, en fjerntliggende termi-nal/koblingsterminal 156h, en gruppesvitsj 156j og annen maskinvare 156k, skaffer tilkoblingstjenester til både lin-jeovervåkeren 232 og til tjenesteapplikasjonsmodulen 204. Linjeinngangen 231 skaffer det fysiske medium som forbinder systemlinjen 229 med den analoge aksessapplikasjonsmo-

dul/digitale aksessapplikasjonsmodul 226/227. Dette fysiske medium håndterer omformingen mellom de elektriske verdier på linje/systemlinje 229 og den interne representasjon (elektrisk/logikk) i selve svitsjesystemet. Det utfører også subtraksjon og understøttelse av signaleringsdelen i TE/RT grensesnitt. Det innebærer at det grovhåndterer lagene 1 og 2 i OSI protokollen for kommunikasjonen med nevnte TE/RT. Funksjonaliteten for linjeinngangen 231 blir implementert i nevnte MDF/ACC 233, LT 234 (som grovhåndterer OSI laget 1) samt ST 235 (som grovhåndterer OSI laget 2) . Linjehåndtereren 232 fremskaffer de midler som er påkrevet for linjeinngangen 231 til å nå brukertjenestene i brukertjenesteenheten 202 hos tjenesteapplikasjonsmodulen 204. Den koordinerer signalering- og linjehåndteringsaktiviteter, f.eks. selektering av linjer og linjekanaler, samt beordrer koblingsovervåkeren 145 til å sette opp signaleringsforbin-delser mellom linjeterminalene 234 og signaleringstermina-lene 235. Koblingsovervåkeren 145 håndterer den fysiske

forbindelse, dvs. banene, i svitsjesystemet og i forbindelse med den prosess som vedrører utførelsen av disse aktivi-teter, vil den håndtere de forskjellige svitsjekomponenter, f.eks. tidsvitsjen 156g, fjernterminal/koblingsterminalen

156h, gruppesvitsjen 156j og andre. I aksessapplikasjonsmodulen 226/227 er det definert lavlagprotokoller i relasjon til linjeinngangen 231 med hensyn til linjeterminaler 234

og signaleringsterminaler 235. I dette henseende er linjeinngangen 231 klart en kandidat som skal implementeres som en ressursmodul. I slike eksempelvise tilfeller vil mar-kedsvariasjoner kunne påvirke hovedsakelig linjehåndtereren 232. For koblingsovervåkeren bør lavlagprotokoller bli definert i forhold til de forskjellige brukte svitsjer, f.eks. i forhold til tidsvitsjen 156g og gruppesvitsjen 156j. Generelt vil teknologien, dvs. lavlaget OSI, lag 1-2, omfatte funksjonalitet som bør være uavhengig av høynivå-funksjonalitet, f.eks. brukertjenester som implementeres i telekommunikasjonsnettverket. Teknologi burde kunne separeres fra høynivå funksjonaliteten ved at man definerer lavlagprotokoller (LLP) som ikke bærer høynivåkunnskap. Disse

lavlagprotokoller kunne bare bli påvirket ved endringer i teknologi og på denne måte vil den samme teknologi kunne benyttes på nytt ved en flerhet av høynivåfunksjonaliteter. Lavnivåprotokoller 236 blir benyttet mellom linjeinngangen 231 og linjehåndtereren 236, samt mellom koblingsovervåkeren 245 og de respektive svitsjeelementer 156.

Slik det fremgår av figur 18, går en av hovedhensiktene ved linj ehåndtereren 232 i hver av de analoge aksessapplikasjonsmoduler 226 og de digitale aksessapplikasjonsmoduler 227 ut på å fremskaffe de midler for linjene 215a-215g og terminalutstyr 213a-213g som er nødvendige for å nå brukertjenestene i passende brukertjenesteenheter 202a-202d i de respektive tjenesteapplikasjonsmoduler 121-125. I prinsippet kan hver del av terminalutstyret 213a-213g kunne forbindes med forskjellige brukertjenesteenheter 202a-202d, hvilket innebærer at linjehåndtererne 232 må være i stand til å lese meldinger på en linje og terminalutstyr. Dessuten kan den påkrevde kanal i linjen kunne indikeres, hvilket innebærer at semantikken i nettverksprotokollene mellom aksessapplikasjonsmodulene 226 og 227 og brukertjenesteenhetene, linjen, terminalutstyret og kanalene i linjene, be-høves som nøkler, slik dette er vist på figur 18. Det blir opp til brukertjenesteenhetene 202a-202d å avslå brukertjenester som ikke understøttes av den nettverksprotokoll som gjelder for en spesifikk linje. F.eks. kan hver type av aksess kunne ha den eventuelle brukerkategori definert i bru-kert j enesteenhetene 202a-202d.

På figur 19 er det vist et blokkdiagram som anskueliggjør en arkitekturen oversikt over den måte på hvilken et eksempel på en tjenesteapplikasjonsmodul, f.eks. en tjeneste-gruppe (BG) applikasjonsmodul 123, har grensesnitt med andre applikasjonsmoduler og ressursmoduler i ressursmodulplattformen 104, for å kunne komplettere en samtale mellom to brukere i en forretningsgruppe. Innenfor forretningsgruppeapplikasjonsmodulen 123 vil hver samtale normalt innbefatte tre objekttilfeller for bruker eller linjetjenesteenhetstyper (USE eller TSE) 135 og 136, en for hver av de to sider av samtalen. Disse to tilfeller, 135 og 136, er linjeforbundet ved hjelp av nettverkstjenesteenheten (NSE) 137. Dessuten vil en flerhet av fasiliteter som tilveie-bringes av ressursmoduler og aksesser bli benyttet i forbindelse med grensesnitt like overfor forretningsgruppeapplikasjonsmodulen 123. F.eks. vil A delbrukeren 138 bli forbundet med BG modulen 123, enten ved en digital aksessapp-likas j onsmodul (IAM) 139 eller en analog aksessapplikasjonsmodul (AAM) 141, mens B delbrukeren 142 også vil bli forbundet med BG applikasjonsmodulen 123 ved hjelp av en digital aksessapplikasjonsmodul 143 eller en analog applikasjonsmodul 144. Hver av tjenesteenhetene 135-137 er forbundet med en flerhet av forskjellige ressursmoduler som er plassert inne i ressursmodulplattformen 104. F.eks. vil koblingsovervåkerressursmodulen 145, transaksjonsovervåkerressursmodulen 14 6 og andre støtteovervåkerressursmoduler 147 fremskaffe de nødvendige støttetjenester for bruker og nettverkstjenesteenhetene 135-137. På samme måte vil for-bindelses- og transaksjonsressursmodulene 145 og 146 ha grensesnitt med analoge aksessressursmoduler 148 og digitale aksessressursmoduler 149.

Innenfor forretningsgruppeapplikasjonsmodulen 123 vil bru-kert j enesteenhetene 135 eller 136 omfatte et brukermiddel

som kommuniserer med brukeren via aksessapplikasjonsmoduler 139-144, som styrer maskinvaregrensesnittene som er forbundet med brukerens telekommunikasjonsutstyr. Brukermiddelet for brukertjenesteenheten omfatter den logikk som tjener

til å fremskaffe brukerens tjenester. På lignende måte omfatter linjetjenesteenheten 135 eller 136 de logikkfunksjo-ner som tjener til styring av intranettverkslinjer. Den styrer linjene via forbindelseslinjeinnganger som styrer maskinvaregrensesnittene til disse forbindelseslinjer. De forskjellige linjeinnganger blir benyttet for å fremskaffe en flerhet av grensesnittrelaterte funksjoner.

Nettverkstjenesteenheten 137 er av objekttypen, som har til oppgave å forbinde, f.eks., to tilfeller av brukertjeneste-enhetstyper eller linjetjenesteenhetstyper i en enkel samtale. Den kan forbindes til en hvilken som helst av nevnte med den samme standard protokoll som rett og slett kan kartlegges inn i sentralprotokollen. De brukertjeneste-enhetsforhold som starter opp og tar ned en samtale, har samme grensesnitt mot nettverkstjenesteenheten (NSE) uavhengig av hvorvidt de befinner seg på den samme eller separate sentraler. Dette sikrer at tjenester vil komme til virkning via et nettverk som via en individuell sentral. Ressursmodulene 145-147 skaffer standard transaksjonsfunk-sjoner og forbindelsesovervåkningsfunksjoner. Transaksjonsovervåkerressursmodulen 146 er valgfri hva angår kommunikasjon mellom tjenesteenheter 135-137 og påkrevet mellom separate applikasjonsmoduler og mellom applikasjonsmoduler og aksesser 148-149.

Mens figur 9 anskueliggjør en samtale som finner sted mellom to brukere eller linjeforbindelser innenfor forretningsgruppeapplikasjonsmodulen, vil lignende enheter være nødvendige i forbindelser med samtaler som skal komplette-res mellom en forretningsgruppeapplikasjonsmodul og en annen forskjellig applikasjonsmodul, f. eks. PSTN applikasjonsmodulen 122. Ved en slik situasjon vil en ytterligere enhet som ikke spesielt er vist på figur 19 og omtalt som en porttjenesteenhet (GSE), være nødvendig, og denne ob-jekttype skaffer porter eller adganger til andre nettverks-typer. Dens primære gjøremål er knyttet til omforming fra den interne protokoll i applikasjonsmodulen til den protokoll som er nødvendig for aksess til andre applikasjonsty-per. Den ville også ha å gjøre med den innbyrdes operasjon og belastning som et resultat av denne interne kobling.

På figur 20 er det vist en ytterligere oversikt over sys-temarkitekturen ved den foreliggende oppfinnelse, omfattende en flerhet av applikasjonsmoduler 122-125, samt en flerhet av ressursmoduler 145-149. Applikasjonsmodulene 122-125 omfatter den spesifikke funksjonalitet ifølge anvendelsen, f.eks. brukertjenester, trafikkhåndtering og ruting. Fordi hver trafikkhåndteringsapplikasjonsmodul understøtter en enkel samtaleprotokoll, vil disse moduler kunne bæres mellom forskjellige markeder. F.eks. vil en applikasjonsmodul som er beregnet for en forretningsgruppe i ett land, kunne introduseres i en sentral i et hvilket som helst annet mar-ked uten behov for eventuelle ytterligere konstruksjonsan-strengelser. Slik modularitet tillater meget rask introduk-sjon av eksisterende anvendelser i ytterligere markeder, alt etter som disse er påkrevet. Ressursmodulene 145-149 skaffer de felles funksjoner for systemet, f.eks. samtale-signaleringsfordeling mellom applikasjonsmoduler, hvilket fremskaffes av transaksjonsovervåkeren 146, svitsjehåndte-ring og koordinering, hvilket fremskaffes ved koblingsovervåkeren 145, samt belastningsdataoppsamling og tilhørende utganger, hvilket fremskaffes ved belastningsovervåkeren 147. Dessuten skaffer ressursmodulene 145-149 verktøyer for felles rutinger, hvilket bidrar til konstruksjonen av applikas j onsmoduler . Egenskapen hos ressursmodulene 145-149 er slik at de skaffer en god basis for konstruksjonen av nett-verkstjenester sammen med reduksjonen av innbyrdes tjenes-tepåvirkninger. Abonnentlinjeinngangen 151, samt forbindelseslinjeinngangen 152 danner del av både koblingsovervåkerressursmodulen 145 og transaksjonsovervåkerressursmodulen

146, og skaffer mellomkoblingen eller grensesnittet mot den ytre verden, samt maskinvare- og linjeovervåkningsfunksjo-ner. De inneholder ikke noen applikasjoner som er spesifikke, enn si trafikkhåndteringsfunksjoner. Denne struktur

skaffer ikke bare en basis for reduksjon av kompleksiteten av applikasjonsmodulene og koordineringen av funksjonaliteten mellom dem, men skaffer også en god basis for innfø-ringen av nye systemkonsepter i programvaren.

Noe som også fremgår av figur 20, er at systemet ifølge oppfinnelsen tillater umiddelbar fornyet bruk av eksisterende applikasjonsmoduler, f.eks. en eksisterende PSTN applikasjon 122. F.eks. vil en nåværende PSTN funksjon som fremskaffer programvaresystem, f.eks. som APT 210 08 som benyttes i Ericsson AXE sentraler, kunne kombineres med nye applikasjonsmoduler 123 og 125. Nye systemløsninger er blitt påtenkt tidligere som å representere problemer med hensyn til funksjonsendring, forbedret gjenoppstart av håndtering og lignende, men introduksjonen av slike nye systemløsninger har vanligvis blitt tilbakevist, på grunn av behovet for omskrivning av hoveddelen av den eksisterende programvare i systemet for derved å kunne implementere samme. Med det foreliggende applikasjonsmodularitetskonsept kan nye applikasjoner ha slike fasiliteter allerede i ut-gangspunktet, uten behov for endring av eksisterende programvare. Introduksjonen av nye applikasjonsmoduler blir gjort mye lettere på grunn av oppsplittingen mellom de rene programvareapplikasjonsmoduler og maskinvaren på grunn av ressursmoduler. Dette skyldes det forhold at det oftest er maskinvaren på grunn av programvaren som bevirker de størs-te hindre mot introduksjonen av nye systemkonsepter.

Slik det er eksemplifisert på figur 20, kan nye applikasjonsmoduler 123 og 125 fremskaffe fullstendig nye løsning-er hva angår funksjonalitet parallelt med eksisterende løs-ninger, f.eks. PSTN applikasjonsmodulen 122. Dette vil i virkeligheten innebære at nye teknologier til stadighet kan introduseres uten behov for rekonstruksjon av tidligere

konstruerte applikasjonsmoduler. F.eks. kan en versjon av et forløp som har å gjøre med gjenoppstarting, kunne innlemmes i hver av de nye applikasjonsmoduler 123 og 125, nemlig slik at en feil som blir detektert innenfor disse moduler og som normalt ville kreve et fullstendig gjenopp-startingssystem, kunne isoleres til å utføre bare den sam-) tale eller kommando som den er relatert til. Dersom en slik utøvelse ikke er tilstrekkelig for å klarere feilen, så vil all programvaren i den ene spesielle applikasjonsmodul kunne gjenoppstartes, og bare dersom begge disse handlinger

feilet, ville det være påkrevet med et fullstendig gjenopp-5 startingssystem. Slik ny funksjonalitet kan nå innføres i hver individuell ny applikasjonsmodul, og virkningen av programvarefeil på sentralytelsen vil reduseres i betydelig

grad. På lignende måte vil nye applikasjonsmoduler, f.eks. BG modul 123 og ISDN modul 125, kunne konstrueres på en slik måte at det ikke foreligger behov for å distribuere eventuelle eksisterende samtale, enten denne er under ut-øvelse eller blir satt opp, mens det gjøres en funksjonsendring. Generelt vil ved tidspunktet for funksjonsendring, alle de samtaler som allerede er blitt initiert, kunne håndteres ved hjelp av den gamle applikasjonsmodulprogram-vare, og etterfølgende samtaler ved hjelp av den nye applikas j onsmodulprogramvare , og i virkeligheten vil begge applikasjonsmoduler kunne arbeide i parallell for en kortere

tidsperiode. Dessuten, idet maskinvaren er atskilt fra programvaren hos applikasjonsmodulene, er det mulig å detekte-re hvorvidt en innretning er blitt etterlatt uvirksom. Slike innretninger kan da frigjøres automatisk og applika-sjonsprogramvaren kan tilbakestilles under bruk av de for-løpsgjeninnstartingsprinsipper som er omtalt ovenfor.

På figur 21 er det vist et diagram som tilkjennegir den måte på hvilken transaksjonsressursmodulen 146 fremskaffer meldingsoverføringsdyktighet mellom respektive av tjeneste-modulene 122 og 123 samt aksessapplikasjonsmodulene 141 og 144. Transaksjonsressursmodulen 146 innbefatter de nødvend-ige protokoller 130 for å gjøre det mulig for forskjellige applikasjonsmoduler å kommunisere med hverandre.

På figur 22 er meldingsoverføringsevnen hos transaksjonsressursmodulen 146 anskueliggjort mer spesifikt gjennom sin rolle for å skaffe kommunikasjon mellom en første applikasjonsmodul 122 og en andre applikasjonsmodul 123. En funksjon for transaksjonsressursmodulen 146 går ut på å skjule den fysiske lokasjon og type av samvirkende applikasjonsmoduler fra hverandre. Fra en av de to applikasjonsmoduler 122 og 123 vil alle meldinger bli adressert under bruk av en transaksjonsreferanse 140 som blir oversatt ved hjelp av transaksjonsressursmodulen 146 til adressen for den samvirkende applikasjonsmodul, for hvilken kommunikasjonen er tiltenkt. Dersom de to samvirkende applikasjonsmoduler 122 og 123 er plassert i separate sentraler, så vil interapplikasjonsmodulmeldingene blir ført via forbind-elseslinjeinngangene til en fysisk signaleringskanal som forbinder de to sentraler med hverandre. I hvert tilfelle vil meldingssekvensene og meldingshåndteringen være like, uansett om de to applikasjonsmoduler 122 og 123 befinner seg i samme sentral eller ikke. Transaksjonsprotokollene omfatter fortrinnsvis en tolagsstruktur. Det nedre lag er en generisk sesjonsprotokoll som setter opp og kobler ned samtaler mellom applikasjonsmoduler som da blir brukt for å bære det øvre lag eller applikasjonsprotokoll, hvilket kan være analogt til undersignaleringen (SS), telefonbrukerde-len (TUP), integrert tjenestebrukerdel (ISUP), eller mobil applikasjonsdel (MAP) protokoller. Dette innebærer at inn-hentingen av opptegninger, f.eks. øyeblikkelig håndtering, og grunnleggende samtalehåndteringstilstander kan separeres fra hverandre. Generelt vil aksessapplikasjonsmoduler bli konstruert til å ha så liten funksjonell innflytelse på trafikkhåndtering som mulig. I prinsippet er de transparen-te og konverterer ganske enkelt det eksterne fysiske signa-leringsgrensesnitt til en intern form som er lettere å ma-nøvrere. Imidlertid tar de ikke vare på ytterligere vedlikeholdsfunksjoner og den tid det er påkrevet når fysiske grensesnitt blir benyttet. På figur 23 er det vist et blokkdiagram over en flerhet av tjenesteaksessapplikasjons-moduler 121-126, og aksessapplikasjonsmoduler 139-144, sammen med en flerhet av ressursapplikasjonsmoduler 145-147 og 150. Slik det fremgår av figuren, kan en eksisterende PSTN applikasjon 122 ganske enkelt kombineres med en nykonstru-ert applikasjonsmodul, f.eks. forretningsgruppemodulen 123. Funksjonelt talt skaffer tjenesteapplikasjonsmodulene 121-126 visse funksjoner som er konfigurert unikt i forhold til deres egne individuelle applikasjoner for hvilke de er fremskaffet. F.eks. vil deres funksjonalitet kunne innbefatte analyse av binære tall, ruting, og unike telekommunikasjonstjenester som er spesielt konfigurert for den spesielle telekommunikasjonsanvendelse som er konstruert for. Hver av aksessapplikasjonsmodulene 139-144 skaffer aksess funksjonelt i systemet og innbefatter slik funksjonalitet som f.eks. protokollanalyse, maskinvarevedlikehold, samt linjevedlikehold.

De ressursmoduler som er vist på figur 23, omfatter koblingsovervåkeren 145, transaksjonsovervåkeren 146, en be-lastningsressursovervåker 147, og en inn/ut (I/O) overvåker 150, som eksempler på ressursmoduler. Hver av disse ressursmoduler skaffer funksjoner som er felles til en eller flere applikasjonsmoduler, og som gjør det mulig for disse applikasjonsmoduler å fremskaffe telekommunikasjonsservice i henhold til den spesielle applikasjon som de er bygget for. F.eks. kan koblingsovervåkeren fremskaffe koblings-koordinasjon, samt grensesnitt med både gruppesvitsjen og abonnentsvitsjen, svitsjvedlikeholdsfunksjoner, samt multiforbindelser (MJS), så vel som nøkkelmottakere/kodemottakere/kodesendere (KR/CR/CS). I tillegg skaffer koblingsovervåkeren 145 aksess til annonseringsmaskiner, samt til tonegeneratorer og internettarbeidende enheter (IWUS). Slik det er omtalt tidligere, skaffer transaksjonsovervåkeren 146 grensesnitt mellom forskjellige applikasjonsmoduler og muliggjør kommunikasjon derimellom. Belastningsovervåkeren skaffer tjenester til applikasjonsmodulene som er forbundet med belastningen'av samtalene på en måte som har relasjon til felles belastningselementer til hver av applikasjonsmodulene. Dessuten vil I/O overvåkeren 150 gjøre inn/ut-funksjoner lettere både innenfor ressursmodulene og applikas jonsmodulene. Det skal forstås at ressursmodulene kan kalle opp den funksjonalitet som inneholdes i tjenesteapplikasjonsmodulene for å fremskaffe sine egne støttefunksjo-ner. F.eks. kan en annonseringsmaskin/ressursmodul fremskaffe sine tjenester ved oppkalling via en PSTN applikasjonsmodul for å nå den fysiske annonseringsmaskinvare som er plassert på et forskjellig sted i forhold til den sentral som styrer nevnte ressursmodul. Dette kan gjøre seg gjeldende for andre ressursmoduler og ressurser. På figur 24 er det vist et blokkdiagram som anskueliggjør den måte på hvilken koblingsovervåkerressursmodulen 145 virker for å skaffe aksess til alle svitsjefunksjoner i systemet. Det omfatter tjenesteapplikasjonsmoduler 122 og 123 og aksess-moduler 139 og 141, samt linjeinnganger 148 relatert til grensesnitt via logikksvitsjeobjekter 154a-154e i koblings-koordineringspartiet 155 av koblingsovervåkerressursmodulen 145. Disse logikksvitsjeobjekter koordinerer tilkoblingen med den aktuelle svitsjemaskinvare 156, omfattende tidsvitsjer (TS), gruppesvitsjer (GS), fjerntliggende ter-minaler (RT) samt sammenkoblingsterminaler (JT). Svitsjema-skinvaren 156 omfatter de standardenheter som nå foreligger innenfor SPC telekommunikasjonssvitsjene, som f.eks. omfatter nøkkelsettmottakere (KR) 156a, kodesendere (CS) 156b, kodemottakere (CR) 156c, digital multisammenkobling (DMJ) 156d, annonseringsmaskiner (ASAM) 156e samt internettarbeidende enheter (IWU) 156e, idet hver av disse eies av koblingsovervåkerressursmodulen 145, som er grensesnittkoblet med linjeinngangsmaskinvaren 153 og 154 i samarbeid med ak-sessapplikas j onsmodulen 139 og 141 for å skaffe funksjonell kommunikasjon. Det skal forstås at for å kunne tillate hver applikasjonsmodul å styre koblinger uten behov for koordi-neringer mellom samme, blir hver applikasjonsmodul meddelt sine egne logikksvitsjeobjekter 154a-154e for styring av samme. For å kunne oppnå en komplett kobling i den reelle omkobler, vil disse logikksvitsjeobjekter 154a-154e være sammenkoblet via sine innganger og utganger for derved å fremskaffe et bilde av den komplette talebane. Fra dette bilde kan den reelle, dvs. de fysiske innganger og utganger, kunne lokaliseres og disse blir da sammenkoblet under bruk av de normale abonnent- og gruppesvitsjeelementer som eies av koblingsovervåkerressursmodulen 145. Hvert logikksvitsj eobj ekt 154a-154e er konstruert for et spesifikt formål og vil således ha et dedikert grensesnitt, hvilket innebærer at dettes operasjoner blir optimalisert. For de fleste samtaler vil bare aksessapplikasjonsmodulene benytte logikksvitsj er for tilkobling og frakobling av kodemottakere og sendere. Applikasjonsmodulen som gir tjeneste vil bare bruke enkle koblingsobjekter som ikke utfører noen reelle funksjoner, men kan lett erstattes av mer komplekse koblingsobjekter, f.eks. for konferanse og overvåkning, dersom dette måtte være påkrevet.

På figur 25 er det vist en gruppe av applikasjonsmoduler 122-125, sammen med et antall av representative ressursmoduler som kan danne en utførelsesform for systemet ifølge den foreliggende oppfinnelse. F.eks. danner koblingsovervåkerressursmodulen 145 og transaksjonsovervåkerressursmodulen 146 del av ressursmodulgruppen ved fremskaffelse av de essensielle funksjoner relatert til kommunikasjon og kobling mellom og med applikasjonsmodulene 122-125. Abonnentlinjeinngangen 151 og forbindelseslinjeinngangen 152 har tilknytning til hver av koblingsressursmodulen 145 og transaksjonsressursmodulen 146. Dessuten er det vist en be-lastningsovervåkerressursmodul 147 som utfører belastnings-funksjoner som er felles for to eller flere av applikasjonsmodulene. En I/O overvåkerressursmodul 150 skaffer inn/ut-funksjoner mens en statistikkovervåkerressursmodul skaffer trafikkopptegning og andre statistiske målinger og overvåkningsfunksjoner. En applikasjonsmodulfunksjonskode-overvåker 158 skaffer funksjonskodeovervåkning, mens en forløpsovervåker 159 skaffer forløpsgjenstartfunksjoner som er nødvendig i en hvilken som helst applikasjonsmodul og i systemet som en helhet, om nødvendig. En operasjons- og vedlikeholdsovervåker 161 skaffer de tradisjonelle drifts-og vedlikeholdsfunksjoner. En abonnentdataovervåker 162 overvåker data som har tilknytning til de individuelle abonnenter som er felles med to eller flere applikasjonsmoduler, innbefattet en abonnentnummerovervåker 165 og en abonnenttjenesteovervåker 166. En tidsforløpsovervåker 163 skaffer tjenester som har tilknytning til overvåkningen av visse tidsorienterte funksjoner i systemet, mens en rute-overvåker 164 skaffer nettverksruteovervåkningsfunksjoner. Overvåkeren 167 representerer en flerhet av andre funksjoner, f.eks. sending/mottakelse av meldinger ved utnyttelse av spesielle typer av signalering, innlastningsovervåkning, samt overvåkning av utinformasjon, noe som kan inkorporeres i ressursmoduler alt etter som det er nødvendig for fremskaffelse av tjenestefunksjoner til to eller flere applikasjonsmoduler .

Slik det fremgår av beskrivelsen så langt, hva angår applikasjon av modularitetsarkitektur ifølge den foreliggende oppfinnelse, foreslår det foreliggende system en flerhet av fordeler og trekk som gjør effektiv vekst og fremtidige kommunikasjonstjenester mulig.

Det er således å mene at driften og konstruksjonen av den foreliggende oppfinnelse vil fremgå av beskrivelsen så langt. Selv om fremgangsmåten, apparatet og systemet vist og beskrevet er tilkjennegitt som foretrukket, så vil det være opplagt at forskjellige endringer og modifikasjoner kan tillegges oppfinnelsen uten at denne avviker fra ideen og omfanget av oppfinnelsen slik dette også er definert i de vedføyde patentkrav.

Claims (1)

1. System (72) for å styre en telekommunikasjonssvitsje-sentral (52) styrt av et lagret program, hvor systemet er karakterisert ved : en rekke telekommunikasjonsstyremoduler (73), idet enhver styremodul (73) er innrettet til å implementere for en bestemt sluttbruker (63, 64) en telekommunikasjonstjeneste fra en gruppe telekommunikasjonstjenester inkludert trådbundne tjenester og celledelte tjenester, en rekke telekommunikasjonsressursmoduler (74), idet hver ressursmodul (74) er innrettet til å implementere felles støttetjenester for å understøtte operasjoner av i det minste to av nevnte rekke av telekommunikasjonsstyremoduler (73) , organer (75) for å fremskaffe kommunikasjonslinker mellom hver av styremodulene (73), idet linkene er dannet i samsvar med nettverksprotokoller, og linkene er dannet for å utveksle informasjon uten at noen styremodul (73) er klar over hvorvidt styremodulen (73) som den kommuniserer med, befinner seg i samme sentral.

2. System ifølge krav 1, karakterisert ved at det ytterligere omfatter : organer (75) for å fremskaffe kommunikasjonslinker mellom hver av styremodulene (73) og ressursmodulene (74), idet linkene omfatter grensesnitt for utveksling av informasjon derimellom.

3. System ifølge krav 2, hvor systemet (72) for å styre nevnte sentral videre er karakterisert ved : organer for å fremskaffe kommunikasjonslinker mellom hver av ressursmodulene (74), idet linkene omfatter grensesnitt for utveksling av informasjon derimellom.

4. System ifølge krav 1, hvor rekken av ressursmoduler (74) i systemet (72) videre er karakterisert ved : en transaksjonsovervåker (146) for å muliggjøre kommunikasjon mellom respektive styremoduler (73), og en koblingsovervåker (145) for styring av selektert maskinvare i sentralen som reaksjon på instruksjoner fra styremodulene (73) .

5. System ifølge krav 4, hvor nettverksprotokoll kommuni-kas j onslinkene videre er karakterisert ved en brukerdel og en mel-dingsoverf øringsdel , og kommunikasjonen mellom telekommuni-kas j onsstyremodulene i den samme sentral som gjøres opera-tiv av transaksjonsovervåkeren (146), innbefatter nevnte meldingsoverføringsdel.

6. Fremgangsmåte for å tilveiebringe telekommunikasjonstjenester til en rekke brukere (63, 64), idet fremgangsmåten er karakterisert ved trinnene: å koble nevnte brukere til en telekommunikasjonssvitsje-sentral (52) styrt av et lagret program, å aksessere innen sentralen (52) minst én applikasjonsmodul (73), idet hver applikasjonsmodul (73) inneholder styreinstruksjoner og data for å tilveiebringe én av brukerne en telekommunikasjonstjeneste fra en gruppe telekommunikasjonstjenester inkludert trådbundne tjenester og celledelte tj enester, å aksessere minst én ressursmodul (74) lagret i nevnte sentral (52), idet hver ressursmodul (74) for kommunikasjon med hver av nevnte applikasjonsmoduler (73) påkrevet for å implementere telekommunikasjonstjenesten, og å kommunisere styreinstruksjoner og data mellom applikasjonsmodul (73) og hver ressursmodul (74) ved bruk av linker for å tilveiebringe telekommunikasjonstjenesten til den ene av nevnte brukere (63, 64) .

7. Fremgangsmåte ifølge krav 6 for å tilveiebringe slutt-brukertelekommunikasjonstjenester til en rekke brukere (63,

64) med forskjellige kommunikasjonsapplikasjoner blant dem, hvor nevnte kommunikasjonstrinn er karakterisert ved trinnene: å overføre informasjon mellom applikasjonsmoduler (73) plassert i telekommunikasjonssvitsjesentralen (52) med en første protokoll, og å overføre informasjon mellom applikasjonsmoduler (73) plassert i telekommunikasjonssvitsjesentralen (52) og applikasjonsmoduler (73) plassert utenfor telekommunikasjons-svitsj esentralen (52) med en andre protokoll, idet den andre protokoll identifiserer bestemte fysiske kretsforbindel-ser.