Application modularity in telecommunications exchanges
Abstract
A software architecture for use in program controlled telecommunications switching exchanges in which application modules are employed to provide services to users of a particular communications applications. Resource modules provide specific functional elements of communications services to the application modules by having access to and control over the exchange hardware. Network protocols provide communication between the application modules within the exchange and interfaces provide communications between the resource modules and between application modules and resource modules within the exchange.

Term
Term ended
Expired 25 February 2013, 13.6 years ago.
- Priority
- Filed
- Granted
- Expired
- Today
23 claims: 7 independent, 16 dependent
- 1Ohjelmistojärjestelmä tallennettujen ohjelmistojen avulla ohjatussa tietoliikennekytkentäkeskuksessa, joka sijaitsee tietoliikenneverkossa ja joka 5 keskus käsittää sekä laitteistoja että ohjelmistoja modulaarisen kytkentäorientoituneen digitaalisen tietoliikennejärjestelmän ohjaus- ja organisaatiorakenteen toteuttamiseksi päätelaitteiden kytkemiseksi toisiinsa verkon palvelualueella mainitun keskuksen loppukäyttäjäpalveluiden ohjaamiseksi, tunnettu siitä, että mainittu ohjelmistojärjestelmä käsittää:10 joukon keskukseen sijoitettuja sisäisiä tietoliikenteen ohjausmoduuleja, kunkin sisältäessä ohjelmistoa liitännäisten toimintojen joukon implementoimiseksi loppukäyttäjäpalveluiden, liikenteen käsittelyn ja veloitusvaatimusten suorittamiseksi, ja jotka toiminnot on konfiguroitu tuottamaan tietyn tyyppisen loppukäyttäjän vaatimat tietoliikennepalvelut 15 riippumatta muun tyyppisten loppukäyttäjien vaatimista toimintojen konfiguroinnista;joukon tietoliikenneresurssimoduuleita, kunkin resurssimoduulin sisältäessä ohjelmistoa mainittujen sisäisten ohjausmoduulien keskinäisen toiminnon koordinoimiseksi yhdelle tai useammalle mainitulle sisäiselle 20 ohjausmoduulille hyödyllisten yleisten tukipalveluiden implementoimiseksi;ja tietoliikennelinkit kullekin mainittujen sisäisten ohjausmoduulien väleille, mainittujen linkkien sisältäessä verkkoprotokollia informaation vaihtamiseksi, joka informaatio on välttämätöntä mainitun loppukäyttäjäpalvelun syöttämiseksi, liikenteen hallitsemiseksi ja veloitusvaatimusten täyttämiseksi, 25 jotka verkkoprotokollat on organisoitu OSI-viitemallin mukaisesti ja jotka ovat täydellisiä ja jotka kattavat kaikki OSI-viitemallin kerrokset.
- 2Tallennettujen ohjelmistojen avulla ohjatussa tietoliikennekytkentäkeskuksessa mainittua keskusta ohjaava patenttivaatimuksen 1 mukainen ohjelmistojärjestelmä, tunnettu siitä, että se edelleen käsittää:30 tietoliikennelinkit kullekin sisäiset ohjausmoduulien ja resurssimoduulien välille, mainittujen linkkien sisältäessä identtisen rajapinnan kunkin resurssimoduulin ja kaikkien ohjausmoduulien välillä informaation välittämiseksi mainittujen moduulien väleillä.
- 3Tallennettujen ohjelmistojen avulla ohjatussa tietoliikenne35 kytkentäkeskuksessa mainittua keskusta ohjaava patenttivaatimuksen 2 mukainen ohjelmistojärjestelmä, tunnettu siitä, että se edelleen käsittää:tietoliikennelinkit kullekin resurssimoduulien välille, mainittujen linkkien sisältäessä identtisen rajapinnan kunkin resurssimoduulin ja kaikkien muiden resurssimoduulien välillä informaation välittämiseksi mainittujen moduulien väleillä.
- 45 4. Tallennettujen ohjelmistojen avulla ohjatussa tietoliikennekytkentäkeskuksessa mainittua keskusta ohjaava patenttivaatimuksen 1 mukainen ohjelmistojärjestelmä, tunnettu siitä, että mainittu resurssimoduulien joukko käsittää:tapahtumaohjaimen tietoliikenteen muodostamiseksi vastaavien 10 mainittujen ohjausmoduulien väleillä verkkoprotokollan avulla, joka implementoi kolme ensimmäistä kerrosta OSI-viitemallissa;ja yhteysohjaimen, joka on kykenevä mallittamaan fyysisten resurssien joukkoa keskuksesta valitun laitteiston ohjaamiseksi vasteellisesti mainittujen ohjausmoduulien tuottamille ohjeille. 15 5. Tallennettujen ohjelmistojen avulla ohjatussa tietoliikennekytkentäkeskuksessa mainittua keskusta ohjaava patenttivaatimuksen 4 mukainen ohjelmistojärjestelmä, tunnettu siitä, että siinä mainitut verkkoprotokollatietoliikennelinkit on määritelty OSI-viitemallin mukaisesti ja että ne sisältävät käyttäjäosan, joka käsittää mainitun OSI-viitemallin kolme 20 ensimmäistä kerrosta ja sanomanvälitysosan, joka käsittää joukon kerroksia, jotka ovat mainitun OSI-viitemallin kerroksen 3 päällä ja samassa keskuksessa olevien mainittujen tietoliikenneohjausmoduulien väliset mainitun tapahtumamoduulin mahdollistamat tietoliikenteet sisältävät mainitun sanomanvälitysosan.
- 56. Ohjelmistojärjestelmä tallennettujen ohjelmistojen avulla ohjatun 25 tietoliikennekeskuksen loppukäyttäjäpalveluiden ohjaamiseksi, jossa keskuksessa on laitteisto- ja ohjelmistokomponentteja, jotka suorittavat tiettyjä toiminnallisia toimintoja digitaalisen tietoliikennejärjestelmän modulaarisen kytkentäorioituneen ohjauksen ja organisaatiorakenteen implementoimiseksi, ja jolla keskuksella on joukko käyttäjiä, jotka ovat kiinnittyneet päätelaitteen avulla 30 mainittuun keskukseen, tunnettu siitä, että mainittu ohjelmistojärjestelmä käsittää:joukon sovellusmoduuleja tietoliikennepalveluiden tuottamiseksi keskukseen kiinnittyneille käyttäjille, kunkin sovellusmoduulin sisältäessä ohjauskäskyt ja datan tietyn liittyvien loppukäyttäjäpalveluiden ryhmän 35 implementoimiseksi, liikenteen käsittelemiseksi ja yksittäisen tietoliikennesovelluksen veloitusominaisuuksien toteuttamiseksi;joukon resurssimoduuleja tietoliikennepalveluiden tiettyjen toiminnallisten elementtien tuottamiseksi kullekin mainitulle sovellusmoduulille, kullakin resurssimoduulilla ollessa pääsy ja ohjausvalta yhteen tai useampaan keskuksen iaitteistokomponenttiin, jotka vaaditaan sille annettujen 5 palveluelementtien implementoimiseksi vaadittavien spesifisten toiminnallisten toimintojen suorittamiseksi;ja välineet kunkin mainitun sovellusmoduulin ja kunkin toisen sovellusmoduulin ja kunkin resurssimoduulin välisen tietoliikenteen tuottamiseksi, tuottamaan kunkin sovellusmoduulin loppukäyttäjäpalvelu-,
- 610 sanomanvälitys- ja veloitusominaisuuksia mainituille loppukäyttäjille ilman minkään toisen sovellusmoduulin ohjauskäskyjen tai tiedon käyttöä, mainittujen tietoliikennevälineiden käsittäessä avointen järjestelmien yhteenliittämisen (OSI) viitemallin mukaisesti määritellyt, täydelliset ja kaikki mainitun mallin kerrokset kattavat verkkoprotokollat. 15 7. Patenttivaatimuksen 6 mukainen ohjelmistojärjestelmä tallennettujen ohjelmistojen avulla ohjatun tietoliikennekeskuksen ohjaamiseksi ohjelmistojärjestelmän ollessa tunnettu siitä, että mainitut välineet kunkin mainitun sovellusmoduulin ja kunkin toisen sovellusmoduulin välisen tietoliikenteen tuottamiseksi sisältävät verkkoprotokollia. 20 8. Patenttivaatimuksen 6 mukainen ohjelmistojärjestelmä tallennettujen ohjelmistojen avulla ohjatun tietoliikennekeskuksen ohjaamiseksi ohjelmistojärjestelmän ollessa tunnettu siitä, että mainitut välineet kunkin mainitun resurssimoduulin ja kunkin toisen resurssimoduulin ja kunkin mainitun sovellusmoduulein välisen tietoliikenteen tuottamiseksi sisältävät rajapintoja. 25 9. Patenttivaatimuksen 6 mukainen ohjelmistojärjestelmä tallennettujen ohjelmistojen avulla ohjatun tietoliikennekeskuksen ohjaamiseksi ohjelmistojärjestelmän ollessa tunnettu siitä, että mainitut sovellusmoduulit sisältävät:palvelusovellusmoduulin mainittujen sovellusspesifisten tietoliikenne30 palveluiden tuottamiseksi;ja päätelaitteilla varustetun liitäntäsovellusmoduulin, joka liittää käyttäjät palvelusovellusmoduuleihin, jotta käyttäjät voivat vastaanottaa mainitut palvelut. 10. Patenttivaatimuksen 6 mukainen ohjelmistojärjestelmä 35 tallennettujen ohjelmistojen avulla ohjatun tietoliikennekeskuksen ohjaamiseksi ohjelmistojärjestelmän ollessa tunnettu siitä, että mainitut resurssimoduulit sisältävät: tapahtumaohjainresurssimoduulin keskuksen laitteistojen ohjaamiseksi vasteellisesti mainittujen sovellusmoduulien käskyille, ja 5 yhteyshallintaresurssimoduulin keskuksen laitteiston ohjaamiseksi vasteena sovellusmoduulien ohjeille.
- 711. Patenttivaatimuksen 10 mukainen ohjelmistojärjestelmä tallennettujen ohjelmistojen avulla ohjatun tietoliikennekeskuksen ohjaamiseksi ohjelmistojärjestelmän ollessa tunnettu siitä, että mainittu väline kunkin 10 mainitun sovellusmoduulin ja kunkin toisen sovellusmoduulin välisen tietoliikenteen tuottamiseksi sisältää verkkoprotokollia, jotka käsittävät käyttäjäosan ja sanomanvälitysosan ja että mainitun tapahtumaresurssimoduulin mahdollistama mainittujen sovellusmoduulien välinen tietoliikenne sisältää mainitun sanomanvälitysosan. 15
- 812. Patenttivaatimuksen 6 mukainen ohjelmistojärjestelmä tallennettujen ohjelmistojen avulla ohjatun tietoliikennekeskuksen ohjaamiseksi ohjelmistojärjestelmän ollessa tunnettu siitä, että mainitut tietoliikenteen tuottavat välineet sisältävät:joukon verkkoprotokollia, jotka välittävät vastaavien 20 sovellusmoduulien välisiä sanomia siten, että kukin moduuli kommunikoi jokaisen toisen moduulin kanssa ilman mitään tietoa siitä, missä moduuli, jonka kanssa se kommunikoi, on.
- 913. Menetelmä tietoliikenneverkossa sijaitsevan, tietoliikenneverkon solmun muodostavan, tallennettujen ohjelmistojen avulla ohjatun 25 tietoliikennekeskuksen, joka käsittää laite- ja ohjelmistokomponentteja määrättyjen toimintojen suorittamiseksi, loppukäyttäjäpalveluja tuottavien ohjelmistojen strukturoimiseksi loppukäyttäjäpalvelujen tuottamiseksi joukolle käyttäjiä, joilla on käytössään monenlaisia tietoliikennesovelluksia, tunnettu siitä, että mainittu menetelmä käsittää seuraavat vaiheet:30 ohjelmistomoduulien tallentamisen mainittuun keskukseen, kunkin moduulin käsittäessä ohjauskäskyt ja tiedon kaikkien tietyn sovelluksen tyyppisten loppukäyttäjäpalveluiden, sanomanvälityksen ja veloitusvaatimusten tuottamiseksi, ja kunkin moduulin toimiessa ohjelmistosolmuna mainitussa keskuksessa verkon vaatimuksissa tapahtuneiden muutoksien siirtämiseksi 35 vastaaviksi muutoksiksi mainitun keskuksen ohjelmistosolmuihin;ja kunkin ohjelmistomoduulin käsittävien ohjauskäskyjen ja tietojen yhdistämisen kuhunkin keskuksen ulkopuoliseen verkon toiseen solmuun tiedon siirtämiseksi niiden välillä.
- 1014. Patenttivaatimuksen 13 mukainen menetelmä 5 tietoliikenneverkossa sijaitsevan, tietoliikenneverkon solmun muodostavan, tallennettujen ohjelmistojen avulla ohjatun tietoliikennekeskuksen, joka käsittää laite- ja ohjelmistokomponentteja määrättyjen toimintojen suorittamiseksi loppukäyttäjäpalveluja tuottavien ohjelmistojen strukturoimiseksi, tunnettu siitä, että mainittu ohjelmistomoduulien tallennusvaihe mainittuun keskukseen 10 sisältää:resurssimoduulien joukon tallentamisen, joista kukin resurssimoduuli on ohjelmoitu kommunikoimaan kunkin mainitun ohjelmistomoduulin kanssa ja joista kullakin resurssimoduulilla on pääsy ja ohjausvalta niihin keskuksen laitteistokomponentteihin, jotka ovat välttämättömiä määrättyjen palvelu15 elementtien implementoinnissa vaadittavien spesifisten toiminnallisten toimien suorittamisessa.
- 1115. Tietoliikennesolmu tietoliikennepalvelujen tuottamiseksi tietoliikenneverkossa, tunnettu siitä, että se käsittää joukon sovellusmoduuleja, joista yksi tai useampi toimii loogisena 20 tietoliikennesolmuna tietoliikennepalvelujen tuottamiseksi ja palvellakseen tietyn tyyppisenä erillisenä tietoliikennesolmuna, joka on yhdistetty tietoliikenneverkkoon;joukon resurssimoduuleja, joista kukin liittyy tiettyyn yhteen tai useampaan sovellusmoduuliin laitteisto- ja ohjelmistoresurssien tuen tuottamisek25 si loogisen tietoliikennesolmun tietoliikennepalvelujen implementoimiseksi;kuhunkin sovellusmoduuliin liittyvän tietoliikenneprotokollan tiedon siirtämiseksi sovellusmoduulien välillä, tietoliikenneprotokollan ollessa yhteensopiva niiden standardoitujen tietoliikenneprotokollien kanssa, jotka mainittu tietyn tyyppinen erillinen tietoliikennesolmu tunnistaa;ja 30 jossa sovellusmoduulijoukon ensimmäinen sovellusmoduuli on konfiguroitu siten, että se voi kommunikoida toisen sovellusmoduulin kanssa mainittua tietoliikenneprotokollaa käyttäen riippumatta siitä, sijaitseeko mainittu toinen sovellusmoduuli mainitussa tietoliikennesolmussa.
- 1216. Patenttivaatimuksen 15 mukainen tietoliikennesolmu, tun35 n e 11 u siitä, että sovellusmoduulijoukosta yksi sovellusmoduuli toimii loogisena solmuna yleisessä puhelinverkossa (PSTN).
- 1317. Patenttivaatimuksen 16 mukainen tietoliikennesolmu, tunnettu siitä, että mainittu tietoliikenneprotokolla käsittää ainakin yhden ISDN käyttäjäosaan (ISUP) perustuvista signaaleista ja tapahtumankäsittelyosaan (TCAP) perustuvista signaaleista.
- 1418. Patenttivaatimuksen 16 mukainen tietoliikennesolmu, tunnettu siitä, että looginen solmu käsittää paikalliskeskuksen.
- 1519. Patenttivaatimuksen 15 mukainen tietoliikennesolmu, tunnettu siitä, että yksi useammasta sovellusmoduulista toimii loogisena solmuna yleisessä matkaviestinverkossa (PLMN).
- 1620. Patenttivaatimuksen 19 mukainen tietoliikennesolmu, tunnettu siitä, että looginen solmu käsittää ainakin joko matkaviestinkeskuksen (MSC) tai kotirekisterin (HLR).
- 1721. Patenttivaatimuksen 19 mukainen tietoliikennesolmu, tunnettu siitä, että tietoliikenneprotokolla käsittää matkapuhelinosaan (MAP) perustuvat signaalit.
- 1822. Järjestelmä useiden tietoliikennepalvelujen tuottamiseksi, jotka tarjoaa yleensä joukko eri tietoliikennesolmuja yhden tietoliikennesolmun sisällä, tunnettu siitä, että järjestelmä käsittää:joukon sovellusmoduuleja, kunkin sovellusmoduulin käsittäessä kaikki yhden tai useamman mainitun tietoliikennepalvelun tuottamisessa tarvittavat ohjelmistosovellukset ja palvellessa tietyn tyyppisenä loogisena tietoliikennesolmuna;joukon laitteisto- ja ohjelmistoresursseja, joihin sovellusmoduuleilla on pääsy mainittujen useamman tietoliikennepalvelun implementoimiseksi;joukon resurssimoduuleja, joista kukin tarjoaa rajapinnan kunkin usean sovellusmoduulin ja yhden tai useamman laitteisto- ja ohjelmistoresurssin välillä, joita laitteisto- ja ohjelmistoresursseja tarvitaan kuhunkin sovellusmoduuliin liittyvien tietoliikennepalvelujen implementoinnissa;tietoliikennelinkin, joka on sovellusmoduulien käytettävissä ja joka hyödyntää yhtä tai useampaa resurssimoduulia siirtääkseen tietoa sovellusmoduulien välillä ja joka kykenee siirtämään tietoa, joka on muotoiltu loogisten tietoliikennesolmujen tunnistamien standarditietoliikennesignaaliprotokollien mukaisesti;ja jossa soveliusmoduulit on konfiguroitu siten, että tiedonsiirto, joka käyttää vähintään yhtä mainituista standarditietoliikennesignaaliprotokollista kahden sovellusmoduulin välillä, voidaan viedä loppuun riippumatta siitä, sijaitsevatko mainitut kaksi sovellusmoduulia mainitussa tietoliikenne-solmussa.
- 1923. Patenttivaatimuksen 22 mukainen järjestelmä, tunnettu siitä, että mainittu tietyn tyyppinen looginen tietoliikennesolmu käsittää langalli5 sen tietoliikennekeskuksen yleisessä puhelinverkossa (PSTN) ja jossa yksittäinen sovellusmoduuli tuottaa tietoliikennepalveluja liittyen langalliseen tietoliikennekeskukseen.
- 2024. Patenttivaatimuksen 22 mukainen järjestelmä, tunnettu siitä, että mainittu tietyn tyyppinen looginen tietoliikennesolmu käsittää matkapu10 helinkeskuksen (MSC) yleisessä matkaviestinverkossa (PLMN) ja jossa yksittäinen sovellusmoduuli tuottaa tietoliikennepalveluja liittyen matkapuhelinkeskukseen.
- 2125. Patenttivaatimuksen 22 mukainen järjestelmä, tunnettu siitä, että mainittu tietyn tyyppinen looginen tietoliikennesolmu käsittää digitaali15 sen monipalveluverkon (ISDN) keskuksen digitaalisessa monipalveluverkossa ja jossa yksittäinen sovellusmoduuli tuottaa tietoliikennepalveluja liittyen digitaalisen monipalveluverkon keskukseen.
- 2226. Tietoliikennekeskus useiden tietoliikennepalvelujen tuottamiseksi tietoliikennepalvelujen käyttäjille, tunnettu siitä, että se käsittää:20 ensimmäisen joukon sovellusmoduuleja, jotka on tallennettu tietoliikennekeskuksen ohjelmistoon, toimimaan ensimmäisenä loogisena tietoliikennesolmuna ja tuottamaan ensimmäiseen tietoliikennesolmuun liittyviä tietoliikennepalveluja;toisen joukon sovellusmoduuleja, jotka on tallennettu tietoliikenne25 keskuksen ohjelmistoon, toimimaan toisena loogisena tietoliikennesolmuna ja tuottamaan toiseen tietoliikennesolmuun liittyviä tietoliikennepalveluja;useita resurssimoduuleja, joista kukin liittyy tiettyyn yhteen tai useampaan sovellusmoduuliin ensimmäisen ja toisen joukon sovellusmoduuleista laitteisto- ja ohjelmistoresurssituen tuottamiseksi ensimmäiseen ja toiseen
- 2330 loogiseen tietoliikennesolmuun liittyvien tietoliikennepalvelujen implementoimiseksi;tietoliikenneprotokolla tiedon siirtämiseksi ensimmäisen joukon sovellusmoduulien ja toisen joukon sovellusmoduulien välillä, jossa tieto muotoillaan ja kuljetetaan ainakin yhden sellaisen standardin tietoliikennesignaalipro35 tokollan mukaisesti, jonka ensimmäinen ja toinen looginen tietoliikennesolmu tunnistavat;ja
Independent claims23
150 paragraphs, as filed
Modularity of applications in telecommunication centers
Background of the Invention
Field of the Invention
The invention relates to telecommunication centers and, in particular, to a software architecture for use in stored software controlled (SPC) telecommunication switching systems.
History of the art
In the late 1960s and early 1970s, software programmed (SPC) stored switching systems were mainly designed to provide the services of a public switched telecommunications network (PSTS), i.e. plain old telephone service (POTS). The SPC communication centers providing these PSTN services were almost all designed with a control architecture that separates the various parts of the system into functional blocks, each of which performs a separate function in call setup. For example, the software traffic control subsystem includes control blocks that perform number analysis, call control, signaling, and so on. Each software block performs a specific control or monitoring function to control and monitor the hardware involved in call setup, monitoring, call termination, and billing.
Over the years, special features such as speed dialing, call waiting, and others that required the addition of software to the core SPC software using the switch were added to the basic telephony services (POTS) to implement these special services.
Stored software controlled (SPC) communication centers have evolved over the years into very sophisticated, dedicated, high-speed computing computers that include duplicate central processing units (CPUs) for reliability and remote processors to increase speed and efficiency. One good example of such a switch (switch) is an SPC communications switching device of the type manufactured by Telefonaktiebolaget LM Ericsson, referred to as an AX switch, an earlier version of which is described by Mats Eklund et al. in the article entitled AX 10 System Description, published in Ericsson Rewiew No. 2, 1976, which is hereby incorporated by reference in this application. Another example of such an SPC telecommunications center is disclosed in U.S. Patent No. 4,322,843 to HJBeuscher, et al. Typically, such exchanges include all the equipment necessary to implement a variety of telecommunication services. For example, they can be used as local PSTNs, remote exchanges, private automatic branch exchange (PABX), each mainly by installing special SPC software to configure the exchange for the desired specific functions.
As telecommunication services became more and more sophisticated over the years, new applications were implemented in telecommunication centers, requiring additional special functions for the software controlling the switch (switch). For example, the growth of cellular services has required switching centers to function as mobile switching centers (MSCs), which control the interconnection of multiple BSC base site controllers and allow cellular subscribers to move from cell to cell in a cellular network area. Similarly, the emergence of integrated services digital network (ISDN) services has required special switching centers to provide the desired services to subscribers. When a plurality of specialized centers providing different services to their subscribers can be combined into a single telecommunications network, it is very expensive, due to both the duplicated hardware, the operation and the operating staff, to implement separate switches individually programmed for the functions required by each type of implemented telecommunication service.
One approach to reducing the cost of a telecommunications network is to provide multiple functions in one center. This implies the addition of additional software blocks to the control modules of the exchange to provide the required functionality to implement each service. Such features may include, for example, special public switched telephone services (PSTN), overage group or centerx (PABX) services, ISDN services, MSC services or others. The problem with such an approach is that when hardware costs are saved by using the same center for multiple functions, the interaction between the software and especially the different blocks of software becomes very complex at the same time. Conversely, adding a new function, for example109397, could completely unexpectedly damage or disable an existing function. As a result, much of the software development cost of such systems today is related to evaluating the impact of the newly added program code on existing program code, and to troubleshooting and testing of the entire software system in response to continuous new functionality. The development of such software mega-systems has increased the cost of new software versions and the addition of new functionalities to existing systems 10 and has extended the development time of such software to such an extent that new features are practically obsolete before they can actually be implemented in the center. Such a result is not a desirable outcome for telecommunications companies, their customers or end-users of services.
Another approach to adding additional functionality to a data center is to arrange additional processors and distribute the software so that it is widely distributed to multiple processors. For example, in some systems, it has been suggested that a particular function block be executed by a particular processor and another function block executed by another processor, respectively, in an attempt to reduce the complexity of the software running on each processor. While multiprocessor systems have some advantages such as improved performance and speech capacity, there are still some weaknesses to such systems. For example, when a chain of functions required for call setup and those functions are shared between multiple processors, an error in one processor may prevent the entire call setup process. In addition, duplication of hardware, such as the use of multiple processors, increases not only hardware costs but also additional support and maintenance costs. These disadvantages of multiprocessor systems occur whether multiple processors are located on the same bus in the same exchange or whether the processors are hosted on separate exchanges and connected via a local area network (LAN).
Still another prior art attempt to achieve multifunctionality in a single communication center is to simply download and translate several functionally oriented software systems into one and the same exchange, such as by downloading the PABX software system directly to a local PSTN exchange. Such interconnection involves at least one major disadvantage because it requires the physical line circuits to cooperate between the PABX part and the local PSTN part. In addition, there may be other conflicts between the two different software5 systems and they may not be able to share the separately available shared resource together.
Thus, it would be very advantageous to organize the software of the SPC telecommunications center in a manner that permits the execution of a plurality of specific telecommunication applications optimally in the same exchange. Such an architecture is provided by the system of the present invention.
Summary of the Invention
It is therefore an object of the invention to provide a method and apparatus implementing the method so that the above problem can be solved. The object of the invention is achieved by a method, a system, a communication node and a communication center, which are characterized by what is stated in the independent claims. Preferred embodiments of the invention are claimed in the dependent claims.
In one aspect of the invention, the system of the invention comprises discrete software blocks defined to include application-oriented functions that are associated together in a single exchange that serves different applications. The application modules are served by resource modules that provide both the necessary communication between the various application modules and the necessary hardware interaction to provide the corresponding communication functions.
One embodiment of the invention includes a software system for controlling a telecommunication switching center controlled by stored software, the software system including a plurality of telecommunication control modules. Each control module includes software for implementing a set of features configured to provide communication services for a particular application and to provide communication services to other applications independently of the feature configuration. The system further includes a plurality of communication resource modules, each resource module containing software for implementing general support services available to two or more control modules, as well as communication links between each control module. The links include network protocols for exchanging information without any control module knowing if it is the control module with which it communicates with the same exchange.
In a further embodiment of the invention, the resource modules include a transaction manager for enabling communication between each of said control modules and for controlling the connection manager hardware in response to instructions from the control module.
In a further embodiment of the invention, the invention includes a software system for controlling a communications center controlled by stored software, in which a plurality of application modules provide communications services to users attached to the center. Each application module contains control commands and data for implementing a particular telecommunication application to users. A plurality of resource modules provide certain functional elements of telecommunications services for each application module. Each resource module has access to, and power to control, each relevant hardware component of the exchange that is necessary to perform a particular functional action that is required to implement a particular service element. Data communication is provided between each application module and each other application module and each resource module to enable the communication service provided to users of each application module without the use of control commands or without the data contained in any other application module.
Furthermore, in a further embodiment of the invention, the invention includes a plurality of network protocols for structuring the flow of messages between application modules corresponding to the network protocols so that the application modules communicate with other application modules without knowing whether the module with which they are communicating.
Description of the drawings
In order to understand the invention, its objects and advantages, reference will be made to the following description, which shall be read in conjunction with the accompanying figures, in which:
Fig. 1 is an illustrative view of a prior art packet communication center;
Figure 2 is an illustrative illustration of prior art software in a multi-application communication center;
Fig. 3 is an illustrative illustration of a telecommunications center software configured according to the system architecture of the invention;
Fig. 4 is a graph illustrating the cost of functionality designed for software for telecommunications systems;
FIG. 5 is an illustrative diagram of a plurality of discrete telecommunication centers interconnected to form a network;
Figure 6 is an illustrative example of how many application functionalities have been incorporated into the software system of the invention;
Fig. 7 is a block diagram of a general concept included in a software system according to the invention;
Figures 8 and 9 are block diagrams illustrating communication between two exchanges by means of network protocol signaling;
FIG. 10 is a block diagram illustrating communications between application modules within the system of the invention via an internal network protocol;
FIG. 11 is a block diagram illustrating certain features of a communication network associated with the system of the invention;
Fig. 12 is a block diagram illustrating a service access module used in the system of the invention;
Figure 13 is a block diagram illustrating certain communication features of the system of the invention;
Fig. 14 is a block diagram illustrating certain features of communication between different exchanges associated with the system of the invention;
Fig. 15 is a block diagram illustrating communication between different application modules of the same switching system including the system of the invention;
Fig. 16 is a block diagram illustrating communication between different application modules of different switching systems incorporating the system of the invention;
Fig. 17 is a block diagram illustrating functional components of an access application module and a connection controller resource module for use in the system of the invention;
Fig. 18 is a block diagram illustrating the interrelationships of line functions between access applications and various service application modules in a system according to the invention; and FIG. 19 is a block diagram of access modules and service application modules constructed in accordance with the system of the invention, and supporting resource modules;
Fig. 20 is a block diagram of an existing application module in a software system constructed in accordance with the invention and a pair of new application modules together with resource modules;
Fig. 21 is a block diagram illustrating communication between different access and service application modules of the system of the invention;
FIG. 22 is a block diagram illustrating communication between two application modules in a system according to the invention through a transaction module;
Fig. 23 is a block diagram of an existing application module in the system of the invention, together with a plurality of additional service and access application modules and resource modules;
Fig. 24 is a block diagram of the hardware and software elements in the system of the invention illustrating the relationships between them; and FIG. 25 is a block diagram of the application modules and the connection management resource module in the system of the invention.
Detailed description
General description of the invention
As stated above, SPC telecommunication centers have evolved dramatically in recent decades. Initially, each exchange had a limited set of functionalities included, and the software implementing that functionality was mainly focused on implementing the services of the PSTNLocal Center. Referring to Figure 1, a small house is shown as a metaphor for depicting a well known prior art PSTN local exchange software subsystem. Such software is conventionally arranged in functionally oriented blocks, each designed to perform a particular functional function and interact with other blocks to efficiently generate s
local public switched telecommunications network services for subscribers connected to that exchange.
Over time, a number of new telecommunications services developed. These services, such as ISDN (Integrated Services Digital Network) and Public Land Mobile Network (PLMN), require substantially different functionality than what is included in a conventional PSTN. As depicted in Figure 2, adding ISDN functionality 12 and PLMN functionality 13 to standard PSTN software functionality 11 required a number of necessary supports, temporary supports, and software fixes 14 to bring new functionality into the standard PSTN-based software architecture. Developing such new functionalities and integrating them into an existing structural context will require a huge amount of development time and costs and will require compromises on multiple functions and functions to ensure that all functionalities work harmoniously in the same center. Furthermore, the design of such mega-systems is reaching a stage where the complexity of the matter has become so great and the development time so long that such an approach is not a viable solution to the need for additional communication functions.
The system of the invention provides a novel architectural approach to the software structures associated with existing SPC communication center hardware and allows the development of individual application modules to implement the functionalities required by a particular telecommunication application with very efficient functionalities. As illustrated in Figure 3, the PSTN application module 15 may be combined with the ISDN application module 16 and the PLMN application module 17 within the same hardware and on the same application platform. The path 19 through which all of these communicate and communicate with each other is comprised of a plurality of resource modules in the software that allow each application module to communicate with and communicate with each other and corresponding resource modules over a network protocol. This means that the software of the architecture according to the invention is networked with each exchange in the same way as the individual exchanges are networked with each other, as described in more detail below.
g
Referring to Figure 4, there is shown a graph illustrating the current development costs of successive versions of prior art software in telecommunication centers. As described, the development cost of one version of the software package 21 includes a certain start-up cost 22 and involves an increased workload as additional features are added to the software. Ultimately, the cost of adding additional functionality becomes so disproportionate that a particular software package reaches its structural breakpoint 23 and requires re-design. The production cost 24 of the new software version includes a certain redevelopment cost, preferably performed at a cost-effective time before the breakpoint of the first software version 21. When additional features are added to the next version 24 of the software, it also reaches a breakpoint 26 and also requires redesign to a third version 27 and so on. As can be seen in Figure 4, adding more functionality to a standard telecommunication software package becomes more laborious and expensive the more complex the software becomes. The software may become so complex that it is no longer modifiable and requires a complete redesign to continue to perform the functions it performs. The system of the invention provides an architecture that dramatically simplifies the inherent need for telecommunications software to renew software to add new functionality, and dramatically reduces the cost of such continuous growth and exponential growth in telecommunication services.
Figure 5 shows a conventional telecommunication network in which the network is made up of exchanges. The local PSTN exchange 31 serves local subscribers and is connected via gateways 32 to the transit PSTN exchange 33, which in turn is connected to the international gateway PSTN exchange 34. For illustrative purposes, these exchanges 31-34 are located in the first state 35 and are connected to centers in the second state 36 via the international PSTN exchange via international interconnectors 37. Other exchanges served by the International PSTN Center 38 may include a National ISDN Center 39 and a National PSTN Center 40, each of which includes a subscriber line, to which each of the International PSTN Center 38 is interconnected 41. In addition, the national PSTN exchange 40 may be connected to a plurality of private telephone exchange PABX networks 42 and 43 by means of interconnectors 41 serving its own subscribers. As shown, the centers of such an international network are interconnected through a plurality of network links, and these centers communicate with one another through network protocols so that they can serve their respective areas by providing communication facilities between their subscribers and other subscribers of the network.
Referring now to Figure 6, there is shown an illustrative representation of a software system according to the invention in which a single exchange 51 can be viewed as having a plurality of discrete logical nodes and the functionalities and interconnections of those nodes included in a single exchange For example, a local PSTN node 53 may be connected to an ISDN node 54, both of which are connected to a private business group 55, which in turn is connected to another corporate network node 56. The local PSTN node 53 communicates with the corporate network node 55 by means of a multi-frequency code protocol (MFC) 57, while the ISDN node 54 communicates with both the local PSTN node 53 and the corporate network node 55 using the CCITT telephone user part (TUP = 58) protocols. through. The ISDN node may communicate with other ISDN nodes by means of the ISDN User Part (ISUP) protocol 61, and the corporate network node 56 communicates with another corporate network node 55 by means of a digital private network signaling system (DPNSS) 62. Each individual node 53-56 includes telephone subscribers 63, while the corporate network node and the ISDN node may also include data communication subscribers 64. The manner in which each of these nodes communicates with other nodes via certain defined protocols is reflected in the software architecture of the present invention, which incorporates the functionality of a local PSTN node in a single switch 52 by including a PSTN application module 65. Similarly, ISDN node 54 functionality is incorporated into ISDN30 application module 66, while enterprise network node 55 functionality is incorporated into enterprise network application module 67, each of which modules may communicate with each other through a defined TUP protocol 68 and common resource set 69 interfaces. Shared resources may include switch fields, LOAS, ASAMs, message transfer part (MTP), and more. As shown in Figure 6, incorporating functionality into separate application modules of the same exchange 52 offers great advantages in simplifying software for a particular application function. In the system of the invention, the internal networking of the software is performed in the same way inside the exchange 52 as it does outside the exchange.
Referring to Figure 7, a block diagram of components of the software system of the invention 72 is shown, which system comprises a plurality of individual application modules 73 interconnected and a plurality of resource modules 74. Application Modules (AM) 73 communicate with each other and with Resource Modules (RM) through interfaces defined by Application Modules (AM) 73 and Resource Modules (RM) 74, which in effect create virtual switch fields and enable software interaction and networking to enable implementations. This architecture offers great advantages in software implementation by allowing each application module to be tailored to the individual functionality associated with a particular telecommunication application. For example, the functionality required for implementing a corporate network communication application is substantially different from that required for implementing an ISDN application. Dividing the software into application-oriented modules enables the provision of customized communication functions configured for a specific application without the need for one application's software to work with software designed for a completely different application, as is currently the case with software structures in a telecommunications center. Each of the application modules can easily communicate with one another and draw upon software resource modules that provide all the necessary interactions with the center hardware and certain functional services available to the individual application modules and common to more than one application module. As a result, each application module comprises a virtual switch field or virtual exchange that thinks it owns the switch field hardware and that the exchange is free to use that hardware for its own specific application-oriented functionality. Such an architecture allows new versions to be added to the software and extensions of the application module functionality without having to take into account the impact of those software changes on other application modules. Since the exchange is no longer controlled by a single entity formed by functionally distributed blocks, it is much less likely that modifying a feature of one application would mutually interfere with the function of a similar feature in another application.
Application module network specification
General principles
When specifying the top or service layer of any application module, such as a corporate network group, the services are described as they are seen from outside the system. However, the network layer is oriented to the services as they are visible inside the application module itself. Two basic principles that should be noted are:
1. The service should look identical to users regardless of whether other subscribers to the service are on the same node or different node on the network
2. The user must be able to move from one node to another without having to change their number.
The services provided in the network layer are evaluated according to the requirements they impose on the network. In addition, the network layer is involved in the allocation of functionalities in the network and in matters such as distributed or centralized network control.
Generally, the first step is to evaluate how the telecommunication application is specified, which step may include specifying a PSTN as a development or a separate service network, e.g.
As ISDN, as specified by CCITT. The second step is to identify the service network reference model, that is, to identify nodes that have specific reference points between each other, for example, access and relay nodes that have protocols defined by reference points. Such a service network reference model forms the basis for how the system is structured in AM. In node reference models, general functionality is identified and forms the basis for how the system is structured in RM.
network Model
Generally, a network can be seen as a set of nodes connected by links. In a telecommunications network, nodes are telephone exchanges, subscribers, or other peripherals, such as databases. Traditionally, network control nodes are designed to perform certain functions, such as local exchange, transit, mobile switching, and the like. However, more and more nodes want to be able to perform more than one task at a time. This has often caused design problems, as each task puts different requirements on node design. This is especially true in the communication functions of centrx corporate networks, where there is a need to see the cetrex group as a separate exchange (PABX) isolated from the general switching functions of the system.
There are telecommunication administrations that define corporate network services as a separate service network. The corporate network reference model consists of access nodes and service nodes. These form the basis for identification of a corporate network group AM, analog access AM, and digital access AM.
If we consider the nodes we want to implement in the network as logical elements rather than physical elements, this approach may provide a more flexible solution to the problems. Each logical element can be seen as an application, of which the corporate web application module is just one example. Other examples include PSTN, MSC, and so on, and each application supports a set of already defined interfaces, such as MFC, C7, DASS1, DPNSS, R2, and so on, each of which can be used to interconnect different application modules, and internally that externally within one physical center. Such a logical node-oriented structure allows application modules to be defined and developed separately from one another using defined interfaces.
It has been suggested that basic communication functions could be used in any application; however, each application has its own specific nuances and requirements for each basic function due to the nature of the communication services provided. For example, the call reverse function has various specific requirements when implemented for PSTN services, dedicated network services, mobile phone services, and ISDN services. Thus, if there was only one call-to-call feature 35 in the system, it would change every time a new application was added to the system.
In accordance with the system of the invention, each application can be designed in the best possible manner with the basic functions adapted to that particular application. Each application could be a functionally modular unit that can be freely combined in any one center with any number of other applications. For example, in a network model, an application module is called a logical node. All logical nodes are linked together to form a logical network.
The network model enables the communication applications of complex services to be functionally divided into many simple application10 modules. Ku each module can be designed apart from the others and there is no need to be concerned about the interactions with other modules or the internal operation of the other modules. When objects are implemented in accordance with these networking principles, all services operate identically regardless of whether the subscribers associated with the services are located on the same or other separate nodes and network transparency is then achieved.
When applying these principles as a typical application module for enterprise network services, the subscriber does not have to consider implementation problems. The implementation of networks by means of links through interconnected exchanges instead of a single exchange should not be allowed to degrade the quality of service provided. When a call is to be made, the system is informed of the desired call destinations by a numerical sequence referred to as a directory number. The directory number should identify the desired subscriber and not be associated with a particular part of the UE. The user defines the numbering plan used in the corporate web service, and the allocation of internal directory numbers is completely user-controlled. However, for calls outside the corporate network group, the directory number must conform to external convention and / or standards, and the numbering plan must further allow services and functions to be started only by dialing / dialing without any ambiguity.
The general system layer architecture for each exchange application module arranged according to the system of the invention, comprising the exemplary corporate network described above, comprises the shared use of resource modules. The interface application modules own a line interface hardware that includes software related to the interface. They have no knowledge or understanding of any of the supported services. Resource modules provide general support functions for all application modules in the center. The event control109397 resource module provides functions common to all application modules to assist in the transmission of messages. It provides links between software components in different application modules. The connection set-up module owns the switching hardware and other common resources, such as voice receivers, multi-connectors, and the like, which enables application modules to access those resources and eliminate any conflicts and requirements for the same connection or resource. Other resource modules, such as Charging Assistance, Operation and Maintenance Assistance, Analysis Assistance, Time Tracking Assistance, and the like, are also used to assist application modules. The resource modules of the system under consideration can be considered as a set of tools, from which each application module selects and uses what it needs to implement its own particular communication application at any given time. Resource modules can be accessed through their highly backward compatible interfaces. Resource modules provide a platform for the development of telecommunication15 applications, i.e. application modules. The various components of both the application modules and the resource modules are implemented as software blocks.
network Communications
Since the provision of a telecommunication service comprises more than one object, it is necessary to consider how the different objects communicate with each other. Such communication can be accomplished through protocols.
There are typically three types of protocols in architecture:
1. Intra-network communication protocols;
2. Internal protocols;
3. Communication protocols between networks.
Internal network protocols include communication between smart objects that make up the same network. The use of the protocol is required because all services provided by this type of network must be supported. The information transported between application modules contains all the information that must be transported between different nodes of the same network type. Therefore, the protocol used between application modules is a special set of protocols defined for inter-node use, for example, lower layers follow the recommendations of the Q900 series. As there are currently no internationally agreed standards for networking business enterprise services, such as the open English DPNSS information standard, flexibility can be used in these cases.
The purpose of internal protocols is to communicate between all objects needed to support telephone services. Such a protocol should be able to deliver:
1. information elements of internal importance only, for example a connection reference point;
2. the information elements needed to support the basic telephone service; and
3. shells for information elements that are relevant only to advanced signaling systems.
The inter-network communication network protocol comprises conventional digital protocols used in telecommunication systems. These, such as the Telephone User Part (TUP), the ISDN User Part (ISUP), the National User Part (NUP), and so on, can be used as they are used today between nodes in a telecommunications network consisting of discrete switches. For each type of application module, a transit service module is used that communicates with application networks of other network types via event support.
Software Module Communications
One important feature of the system according to the invention is the provision of efficient communication between different software modules. Communication between application modules is network oriented, while communication between application modules and resource modules is system oriented. Network-oriented communication takes the form of protocols, which are specific and well-defined rules for exchanging information between systems, such as telephone exchanges. Protocols are made up of message strings that are in a certain format and have a particular meaning, for example, TUP, MFCR2, TCAP, and so on. Figures 8 and 9 illustrate communication between two exchanges in accordance with the signaling protocol of the CCITT signaling system number 7 (common channel signaling). Figure 9 shows that the message transfer part (MTP) corresponds approximately to layers 1 to 3 and that the user part (UP) represents the remaining layers 4 to 7. Examples of user parts include a telephone user part (TUP), an ISDN user part ( ISDN UP), and so on. The protocol, which can communicate with other exchanges, is documented in the form of a protocol description (PD = protocol description) describing all layers 1-7, e.g., the MTP of the message transfer section (as shown in the CCITT yellow and red books), the user section. message format, information field coding, procedures, and so on.
As discussed above, many of the existing network protocols can provide communication between application modules according to the invention.
<td rowspan="2">system, protocols which may be collectively referred to herein incorporated herein.</td><td colspan="2">Below is a list of exemplary uses for various embodiments of the current system</td>
<td>CCITT documentation, which is</td><td>a reference to</td>
<td>Protocol</td><td>CCITT recommendation number</td><td></td>
<td>MFC-R2</td><td>Q.310-Q.490</td><td></td>
<td>TUP</td><td>Q.72X</td><td></td>
<td>ISUP</td><td>Q.76X</td><td></td>
<td>D-CHANNEL</td><td>Q.93X (FLOOR 2: Q.92X)</td><td></td>
<td>TCAP SCCP +</td><td>Q.771 - Q.795</td><td></td>
<td>CCITT No. 7</td><td>Starting with Q.700-Q.716</td><td></td>
<td>CCITT No. 6</td><td>Q.251 - Q.300</td><td></td>
<td colspan="2">To illustrate how signaling</td><td>is carried out</td>
in a switchboard structured according to the modularity concept of the applications, Figure 10 illustrates a call passing through such a switch. The application module to application module type protocol shown in switch B of Figure 10 is an internal type protocol, i.e. one used only for communication between application modules within the same switch. Rather than using the message transfer section (MTP) as an end-to-end mediator for layers 1-3, the application module protocol uses the services provided by the event management resource module embedded in the system of the invention. From application module to application module, the protocol is documented and provides specific message formats, information field coding, and other procedures specific to that layer 4 to 7 protocol. These protocols may include a number of specific and different application-to-application protocols.
The differences between an external protocol functional description, such as ISUP, and an internal protocol functional description, such as NIIP, include:
1. An external protocol is required to transport data about the physical resources involved, such as PCM channels, and how those resources relate to calls. This requires that operation and maintenance procedures, as well as messages, be included in order to control these resources, such as blocking and the like. The equivalent is not customary for internal protocols because they do not use physical resources, only logical circuits.
2. The length of the messages, the structure of the messages and the coding of the information may vary between the internal and external protocols because they use a different transport service for layers 1-3, i.e. MPT services or event services.
3. Internal protocols may require additional information regarding, for example, session references for charging, logical circuit references, and so forth that are not required by external protocols.
One element common to external and internal protocols is that both should be able to satisfy the following conditions:
1. Both must be able to deal with a hostile environment, as things can sometimes go wrong and messages may disappear, so timers are required to avoid this potential threat;
2. Neither should assume a specific user for the protocol; and
3. Both should be perfect in the sense that each covers all layers 1 to 7.
Communication from the application module to the resource module is structured in the form of a system interface viewed from the side of the application module, i.e., both communication elements are contained in the same environment, i.e. in the same control system. Application module protocols are peer-to-peer communication, while the interface between the application module and the resource module is client / server oriented. The user interface of the resource module may consist of PLEX signals and the interface is described in the interface specification. The resource module has an identical interface to all AM and RM modules, which interface does not allow any RM to transmit any specific signal. To perform the service, RM may use the services provided by other RMs. Figure 10 shows an example of an application module using the interface and therefore of the services provided by the event controller resource module. The following points should be taken into account when structuring the design and appearance of resource module interfaces:
(a) geographical distribution is not a factor to be taken into account as resource modules can only be called from within the same system;
(b) Different equipment manufacturers should not be taken into account as resource modules are all included in the same system;
(c) Different users are a factor to consider, as resource modules are used in different application modules and provide different physical services for those application modules; and (d) Communication between the resource modules should maintain the client / server relationship
When documenting the interfaces used in the system of the invention, the interfaces can be specified by software signals consisting of message and coding information. Each resource module can provide a number of different services that may have a number of different interfaces. For example, the current design rules for the messaging part of conventional protocols are good examples of such application module / resource module interfaces. Thus, such interfaces can be specified together with the software signals needed to perform the service provided by the resource module. One such interface may include valid design rules for the use of the messaging section services associated with the common channel signaling subsystem (CCS) of the AXE-10 SPC switching system.
Interface structure in application module networks
The term interface is next used to describe the means a user needs to access the user-specific services that he or she has subscribed to from a telecommunication system. In the following, these tools will be identified in the form of components or functional entities using an object-oriented approach. Such an approach supports the rapid development of the necessary interfaces by allowing a clear separation between technology and functionality, interface and user services, and traffic handling and use and maintenance. The identified components define the interface object structure that can be used as the basis for defining the structure of the interface product.
The interface area of this system has two interface application modules, the Analogue Interface Application Module (AAM) and the Digital Interface Application Module (IAM). When structuring the interface, this system follows certain basic principles:
1. The interface and the user services are separated and thus the subscriber information, data or services are not part of the interface application module.
2. The physical sharing of the interface application modules is enabled using a network protocol between the interface application modules and the service application modules.
3. The physical location of the switching fields 5 of the same switching system is hidden from the users of the switching field. This is achieved by defining a communication interface for the connection set up controller resource module that controls the various switch fields of the switching system.
4. Functionality and technology are separated. This means that the technology, i.e. the functionality of the lower layers (OSI layers 1-2), is distinct from the functionality of the higher layers, such as user services implemented in the telecommunications network, by defining lower layer protocols without high layer intelligence. This allows technology to be reused in a number of high-level functionalities.
Referring now to FIG. 11, it is shown that the communication network 200 includes a plurality of discrete functional units to accomplish the intended purposes of the network. In order to perform a telecommunication service to a user, the network 200 includes an interface component 201, a user service entity 202, and a network service entity NSE.
203. The user may be either a human, an application program, or some other user who wishes to access from a user service provided by the telecommunication network 200 for subscription. The interface 201 provides the means the user needs to obtain the services he has subscribed to. The user service entity 202 provides and implements services to users by transmitting service instructions, charging the entity that has ordered the services, and the like. The network service entity 203 provides information transmission capacity and services, for example, by providing the transmission service and transmission power as described in CCITT Recommendation 1.210.
Referring now to FIG. 12, it is shown how the service interface used by the service application module 204 in the system of the invention includes a user service entity 202 (USE) and a network service entity 203 (NSE). The user connects to the service application module 204 through the interface application module 201. FIG. 13 illustrates various physical interface products of a switch network layer and illustrates that users can connect to switch 205 in connection with a switching system either directly through a centrally located subscriber switch (207) or remotely through remote subscriber switch (208) and transmission network (209). FIG. 14 illustrates that a subscriber may subscribe to any number of versions of switches 206a through 206c in switching system 206 via transmission network 209 using standard protocols through an independent interface product 210, such as an interface multiplex concentrator (AMC). Such a product 210 is itself a homogeneous switching system, which can serve other homogeneous switching systems with connection services on a switching network layer, regardless of which switching system 206a 206c is connected.
One reason that the interface application modules 204a and 204b have a network protocol is that it allows physical sharing of terminals and lines in the switching network. In this way, the interface application module can be designed as a physical interface product in a switching system other than the user service entity shown in Figures 15 and 16. In FIG. 15, the switching network 201 includes a switching system 206 consisting of an analog / digital interface application module 226/227 communicating with the service application module 204 with the user service entity 202 via the network protocol 229. Similarly, in FIG. 16, the switching network 201 includes two switching systems 206a and 206b, one containing an analog / digital interface application module 226/227, and the other containing a user service entity 204 in the service application module 204. In this case, the interface module 226/227 communicates with the user service entity in the service application module 204 through the same network protocol 229, this time connected through the transmission network 209 instead of being directly an application module itself. Both the switching system 206a and 206b may also include interfaces to the intermediate transmission network 209 for implementing and communicating the network protocol 229.
Referring now to Figure 17, the functional division of the analog / digital interface application module and the distributions of the LE (line entrance) 231 and the connection controller 145 are shown, showing their close relationship. As shown, the analog / digital interface application module 226/227 includes a wire input (LE) 231 and a wire handler (LH = line handler) 232. The wiring input 231 comprises a main distribution frame / automatic cross connect (MDF) 233, as well as a LT (line terminal) 234 and a signaling terminal (ST) 235. The connection controller resource module 145, for example comprising access to a time switch 156g, a remote terminal / juncture terminal 156h, a group switch 156j, and other hardware 156k provide a line handler 232 and a service application module 204 from a connection service. Wire input 231 provides a physical device that connects system cable 229 to the analog / digital interface application module 226/227. This physical medium addresses the discussion between the electrical values on the wire / system wire 229 and the internal manifestations (electrical / logical) in the switching system itself. It also reduces and supports the signaling portion of the TE / RT interface. That is, it is estimated to handle layers 1 and 2 of the OSI protocol for communication with the TE / RT. The functionality of line input 231 is implemented in MDF / ACC 223, LT 234 (which handles OSI layer 1) and ST 235 (which handles OSI layer 2). The line handler 232 provides the means that the wire input 231 needs to access the user services in the user service entity 202 in the service application module 204. It coordinates signaling and line handling activities, such as line and line channel allocation, and further instructs the connection controller 145 to establish signaling connections between line terminals 234 and signaling terminals 235. The connection controller 145 handles the physical connection, i.e. the paths in the switching system, and, in performing these activities, handles various switching components, such as a time switch 156g, a remote / terminal terminal 156h, a group switch 156j and others. In the Interface Application Module 226/227, low-level protocols are defined by the wiring input relative to wiring terminals 234 and signaling terminals 235. In this way, the line input is clearly a candidate for implementation as a resource module. In such cases, for example, changes in the market may affect only the processor 232. As for the connection controller, the low level protocols should be defined for the different switches used, for example, the time switch 156g and the group switch 156j. In general, the technology, i.e., low-level OSI, layers 1-2, should be functionally independent of high-level functionalities such as user services implemented in the telecommunications network. The technology could be distinguished from high-level functionality by defining low-level protocols (LLPs) without high-level intelligence. These low-level protocols would only change if technology changed, and thus the same technology could be reused in several high-level functionalities. The lower level protocols 236 are used between the wiring input 109397 between the input 231 and the wire handler 236 and between the connection controller 145 and the respective switching elements 156.
Referring to Figure 18 below, one of the main functions of the wiring processor 232 in analog interface application modules 226 and digital interface application modules 227 each is to provide means for wires 215a 215g and terminal devices 213a to 213g in respective service application modules 121
125 to use the user services in the appropriate user service entities 202a to 202d. Basically, each part of the terminal 213a 213g can be connected to a different user service entity 202a to 202d, which means that line handlers 232 must be able to read messages based on the line and the terminal. In addition, the required on-line channel can be indicated, which means that the semantics of network protocols between user service entities and interface application modules 226 and 227 and the line, terminal, and line in the line are required as shown in FIG. which are not supported by the network protocol for a particular line. For example, each type of interface may have user service entities 202a
- 202d defined user categories.
Referring now to Figure 19, there is shown a block diagram showing an architectural overview of how an exemplary service application module, such as BG = business group application module 123, interfaces with other application modules and resource modules on the resource module platform 104 to construct. In the enterprise network service 25 application module 123, each call requires three bodies of user or transit service entity types (USE or TSE) 135 or 136, one at each end of the two calls. These two bodies 135 and 136 are linked by 137 bodies of the Web Service Object (NSE). In addition, a number of services provided by the resource modules and interfaces are used in the enterprise web service application module
123 interfaces. For example, the A-subscriber 138 is linked to the BG module 123 by either the Digital Connecting Application Module (IAM) 139 or the Analog Connecting Application Module (141), while the B-subscriber 142 is further linked to the BG Application Module 123 by the Digital Connecting Application Module 143 or Analog Linking Application Module 144. Each of the service entities 135-137 is connected to a plurality of different resource modules located on the resource module platform 104. For example, the connection controller resource module 145, the event management resource module
146 and other support management resource modules 147 provide the necessary support services to the user and network service entities 135-137. Similarly, the connection and event resource modules 145 and 146 connect via interfaces to analog interface resource modules 148 and digital interface resource modules 149.
In the corporate network service application module 123, the user service entity 135 or 136 includes a user agent that communicates with the user through the access application modules 139-144 which control the hardware interfaces linked to the user communication device. The user service entity user tool includes logic for providing user services. Similarly, the transit service entity 135 or 136 includes logical functions for controlling intra-network links. It directs the transit lines through the inputs of the transit lines that direct the hardware interfaces to those transit lines. Different line inputs are used to provide a variety of interface-related functions.
The network service entity 137 is an object type that exists to link, for example, two means of a user service entity or transit service entity in a simple call. It connects to either of them with the same standard protocol that simply fits in between the exchanges. The user service entity 20 tools that make and terminate a call have the same interface to the network service entity (NSE), whether they are in the same or separate centers. This ensures that the services operate in the same way throughout the network as in a single exchange. Resource modules 145-147 provide standard event and connection management functions. The event management resource resource module 146 is optional in traffic between service entities 135-137 and mandatory between separate application modules and between application modules and interfaces 148-149.
When FIG. 19 illustrates a call between two users or a transit line in a corporate network application module, similar entities are necessary to implement calls between the corporate network application module and another different application module, e.g., PSTN application module 122. In such a situation, an additional object, not specifically shown in Figure 19, called a gateway services entity (GSE) is required, and this type of object provides transit bridges to other types of networks. Its primary function is to interface with other application types for the protocol needed to convert the application module's internal protocol. It should also be responsible for the billing and collaboration generated by this connection.
Referring now to Figure 20, an additional general view of the system architecture of the invention, including a plurality of application modules, 122-125, and a plurality of resource modules, 145-149, is provided. Application modules 122-125 include application-specific functionality such as user services, traffic management, and routing. Because each traffic management application module supports a simple call protocol, these modules are interchangeable between different markets. For example, an application module designed to be a business network in one country can be deployed in the center in any other market without the need for any other design measures. Such modularity allows existing applications to be brought to the additional market very quickly when needed. Resource modules 145-149 provide basic system functions such as splitting call signaling to various application modules provided by event controller 146, switch control and management provided by connection controller 145, and collection and printing of debit information provided by debit controller 147. In addition, resource modules 145 - 149 provide design.
A feature of resource modules is that they provide a good basis for planning web services, together with reducing service interruptions. The subscriber line input 151 and the transit line input 152 form part of both the connection controller resource module 145 and the event management resource module 146 and provide interfaces to the outside world as well as hardware and line monitoring functions. They do not include any application-specific or traffic management features. This structure not only provides the basis for reducing the complexity of application modules and coordinating functionality between them, but also provides a good basis for new software system concepts.
As also shown in Figure 20, the system of the invention permits immediate reuse of existing application modules, such as the existing PSTN application 122. For example, an existing software system providing PSTN functionality, such as the APT 210 08 used by Ericsson's AX centers, can be combined with new application modules 123 and 125. New system solutions were previously thought to be solutions for functional changes, improved restarts, and the like, but the introduction of such new system solutions was opposed because they would have required the majority of existing system software to be rewritten in order for these new system solutions to be implemented. With the modularity concept of existing applications, new applications can have such functionality right from the start without the need to modify existing software. Deploying new application modules is much easier due to the sharing of pure software application modules and hardware-based resource modules. This is due to the fact that in most cases, it is hardware-only software that causes the greatest obstacles to the introduction of new system concepts.
As exemplified in Figure 20, new application modules 123 and 125 can provide entirely new solutions for functionality alongside existing solutions, such as the PSTN application module 122. As a result, new technologies can be deployed continuously without the need to redesign previously designed application modules. For example, a version of the forlopp reboot may be included in each of the new application modules 123 and 125 such that an error detected in these modules that would normally require a system-wide reboot can be isolated so that the error only affects the call or command to which it is associated. If such an action is not sufficient to resolve the error, then all software in that particular application module can be restarted, and only if both of these fail will require a system reboot.
Such new functionality can now be provided for each individual new application module and the impact of software bugs on the operation of the exchange is greatly reduced. Similarly, new application modules, such as BG module 123 and ISDN module 125, can be designed in such a way that no existing call is disturbed, whether the call is established or is only established when a function change is performed. Generally, at the time the function change is executed, all calls that have already been initialized (started) are handled by the old application module software and subsequent calls are processed by the new application module software and as a result, both application modules work for a short time in parallel. In addition, since the hardware is separated from the application module software, it is possible to detect if a device is left hanging.
Such devices can then be automatically released and the application software restarted using the forlopp restarting principles outlined above.
Reference will now be made to Figure 21, which is a diagram illustrating the manner in which the event resource module 146 provides a messaging feature between the respective service application modules 122 and 123 and the access application modules 141 and 144. The event resource module 146 includes the necessary protocols 130 to enable communication between different application modules.
Referring now to Figure 22, the message transfer feature of the event resource module 146 is illustrated in more detail, showing the role of the event resource module 146 in providing communications between the first application module 122 and the second application module 123. One function of an event resource module is to hide the physical location and type of application modules working together. All messages from each of the two application modules 122 and 123 are addressed using the event reference 140, which is translated by the event resource module 146 into the address of the interoperable application modules for which it is intended to communicate. If these two collaborative application modules
122 and 123 are located in separate exchanges, the messages between the application modules are transmitted through the inputs of the transit lines to the physical signaling channel which interconnects the two exchanges. In either case, the message queues and message processing are identical whether or not the two application modules 122 and 123 are in the same exchange. The event protocols preferably include a two-layer structure. The lower layer is a generic session layer that generates and unlocks calls between application modules, which calls are then used to carry a higher layer or application protocol, which may be analogous to a sub-signaling (SS = subsigning), telephone user section (TUP), ISDN30 user section (ISUP), or mobile. ) compared to. This means that the reservation of registry entries, ie event handling and basic call handling facilities, can be separated. In general, interface application modules are designed to have minimal operational impact on traffic management. In principle, they are transparent and simply translate the external physical signaling interface into an internal and more manageable form. However, they do not take care of the additional maintenance functions and the time required to use the physical interfaces. Referring now to Figure 23, there is shown a block diagram of a plurality of service access application modules 121-126 and access application modules 139-144, together with a plurality of resource application modules 145-147 and 150.
As described, an existing PSTN application 122 could easily be combined with newly designed application modules, such as a corporate network group module 123. Functionally speaking, the service application modules 121-126 provide certain functions that are uniquely configured for the individual applications for which they are implemented. For example, their functionality may include number analysis, routing, and unique communications services specifically configured for the specific communications application for which they are designed. Each of the interface application modules 139 to 144 provides interface functionality to the system and includes functionalities such as protocol analysis, hardware maintenance, and line maintenance.
The resource modules shown in Figure 23 include a connection controller 145, an event controller 146, a charge resource controller 147, and an input / output (I / O) controller 150 as examples of resource modules. Each of these resource modules provides functions that are common to one or more application modules and enable those application modules to provide communications services for the particular application for which they were designed. For example, a connection controller may provide communication coordination and interface with both group dial (switch) and subscriber dial (switch), switch maintenance functions, and multi junctures (MJS), as well as key / code receivers / code transmitters (KR / CR / CS). In addition, the connection controller 145 provides an interface for information devices as well as for voice generators and an internetworking unit (IWUS). As discussed above, the event controller 146 provides interfaces between different application modules and enables communication between them. The charging controller 147 provides services to those application modules that are associated with the charging of calls in a manner related to common charging elements in each application module. In addition, I / O controller 150 provides input / output functions in both resource and application modules. It is to be understood that resource modules may rely on the functionality contained in the service application modules to provide their own support functions for the resource modules. For example, the resource device109397 resource module may provide its service by calling out through the PSTN application module to access a physical data device hardware located in a location other than the control center for that resource module. This may apply to other resource modules and resources. Reference will now be made to Figure 24, which is a block diagram illustrating the manner in which the communication controller resource module 145 operates to provide access to all system switching functions. They refer to service application modules 122 and 123, and interface modules 139 and 141, and line inputs 148 through logical switching objects 154a to 154e within the communications control resource section 145 of the communication controller resource module 145.
These logical switching objects coordinate the connection together with the actual switching apparatus 156 including time switches (TS), group switches (GS), remote terminals (RT), and juncture terminals (JT). The switching devices 156 comprise standard units typical of existing SPC communication centers including, for example, key set receivers (KR) 156a, code transmitters (CS) 156b, code receivers (CR) 156c, digital multiplexers (DJM) 156d, communication devices (ASAM), internetworking unit) 156f, each of which owns a connection controller resource module 145, which forms an interface to the line input hardware 153 and 154 in one alignment relationship with the interface application modules
139 and 141 for functional communication. As can be seen, in order to allow each application module to control connections without the need for control between them, each application module is provided with its own logical switching object 145a-145e to control. In order to provide a complete connection at a real exchange, these logical switching objects 145a-145e are linked together through their inlet and outlet to produce a complete speech path image. From this image, the actual or physical inputs and outputs can be localized and then interconnected using standard subscriber and group switching elements 30 owned by the connection controller resource module 145. Each logical switching object 154a to 154e is designed for a specific purpose and thus each has a specific interface, which means that its functions are optimized. For most calls, only the interface application modules use logic switches to connect and disconnect code receivers and transmitters. The application generating application module uses only simple connection objects that do not perform any real function, but can simply be switched to more complex connection objects, such as conference or monitoring objects, if required.
Reference will now be made to Figure 24, which shows a plurality of application modules 122-125 together with a representative set of resource modules that may constitute an embodiment of the system of the invention. For example, the connection controller resource module 145 and the event controller resource module 146 form part of the resource module table by providing the necessary communication functions between and with the application modules 122-125. The subscriber line input 151 and the through line 10 access line input 152 are associated with each of the connection resource module 145 and the event resource module 146. In addition, a charging controller resource module 147 is provided which performs charging functions common to two or more application modules. The I / O controller resource module 150 provides input / output functions, while the statistical controller resource module 157 performs traffic logging and other statistical measurements and control functions. The application module action code controller 158 performs the action code control, while the forlopp controller (forlopp = pre-flow, forward run) 159 performs the necessary forlopp restart functions on any application module or system as a whole, if necessary. Operation and Maintenance Controller 161 provides routine operation maintenance functions. The subscriber information controller 162 manages the individual subscribers
·. associated information common to two or more application modules including a subscriber number controller 165 and a subscriber service controller 166. The time controller 163 provides certain time-oriented systems within the system; 25 route monitoring services, while the router 164 provides network route management functions. Controller 167 represents a number of other functions such as sending / receiving messages using certain types of signaling,<sup>:</sup> load management and output information management that could be used in resource modules essential to provide service functions for two or; 30 for more application modules.
: As can be seen from the above modular architecture of the applications of this invention, this system offers a number of advantages and <sup>:</sup> features that will enable future growth in telecommunication services.
; Thus, it is to be believed that the operation and structure of the present invention will be apparent from the foregoing description. When the method, apparatus and system shown and described have been described as representing a preferred embodiment, it will be apparent that many modifications and modifications may be made thereto without the risk that those modifications would be outside the spirit and scope of the invention claimed in the following claims.
12 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12
25 members in 15 offices
Priority claims6
| Document | Office | Kind | Date |
|---|---|---|---|
| 72316691 | United States of America | A | |
| 9200429 | Sweden | W | |
| 9200429 | – | – | – |
| 723166P | – | – | – |
| US19910723166 | – | – | – |
| WO1992SE00429 | – | – | – |
Members25
| Document | Office | Kind | |
|---|---|---|---|
| CA2087097A1 | Canada | A1 | |
| IE922076A1 | Ireland | A1 | |
| WO9300776A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2232892A | Australia | A | |
| NO930624D0 | Norway | D0 | |
| NO930624L | Norway | L | |
| FI930855A | Finland | A | |
| FI930855A0 | Finland | A0 | |
| FI930855A7 | Finland | A7 | |
| EP0546151A1 | European Patent Office (EPO) | A1 | |
| JPH06500912A | Japan | A | |
| MX9203507A | Mexico | A | |
| BR9205331A | Brazil | A | |
| AU657155B2 | Australia | B2 | |
| US5691973A | United States of America | A | |
| US5960004A | United States of America | A | |
| EP0546151B1 | European Patent Office (EPO) | B1 | |
| KR100256000B1 | Republic of Korea | B1 | |
| DE69230905D1 | Germany | D1 | |
| DE69230905T2 | Germany | T2 | |
| DK0546151T3 | Denmark | T3 | |
| GR3033530T3 | Greece | T3 | |
| CA2087097C | Canada | C | |
| NO311910B1 | Norway | B1 | |
| FI109397BThis record | Finland | B |
Numbers
- Publication, DOCDB
- 109397
- Publication, EPODOC
- FI109397B
- Application
- 930855
- Application, DOCDB
- 930855
- Application, EPODOC
- FI19930000855
Titles3
- English
- Application modularity communication centers
- Finnish
- Sovellusten modulariteetti tietoliikennekeskuksissa
- Swedish
- Tillämpningarnas modularitet i datakommunikationscentraler
Classification
- CPC, 24
- H04Q3/0058
- H04Q3/0029
- H04Q11/0407
- H04Q2213/1305
- H04Q2213/13072
- H04Q2213/1313
- H04Q2213/13176
- H04Q2213/13202
- H04Q2213/13204
- H04Q2213/13209
- H04Q2213/1322
- H04Q2213/13334
- H04Q2213/1334
- H04Q2213/13349
- H04Q2213/13383
- H04Q2213/13384
- H04Q2213/13389
- H04Q2213/13405
- H04Q2213/13502
- H04Q2213/13503
- H04Q2213/13504
- H04Q2213/13526
- H04Q2213/13527
- H04Q2213/13535
- IPC, 5
- H04M3 42
- H04Q
- H04Q3 00
- H04Q3 545
- H04Q11 04