CZ297956B6 - Zpusob v telekomunikacní síti pro umoznení operátorovi síte zabránit selhání provozu sluzby - Google Patents

Zpusob v telekomunikacní síti pro umoznení operátorovi síte zabránit selhání provozu sluzby Download PDF

Info

Publication number
CZ297956B6
CZ297956B6 CZ0384699A CZ384699A CZ297956B6 CZ 297956 B6 CZ297956 B6 CZ 297956B6 CZ 0384699 A CZ0384699 A CZ 0384699A CZ 384699 A CZ384699 A CZ 384699A CZ 297956 B6 CZ297956 B6 CZ 297956B6
Authority
CZ
Czechia
Prior art keywords
service
transaction
application
capability
abstract
Prior art date
Application number
CZ0384699A
Other languages
English (en)
Other versions
CZ384699A3 (cs
Inventor
Khello@Robert
Graf@Leslie
Boman@Rune
Veenstra@Pieter
Original Assignee
Koninklijke Kpn N. V.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninklijke Kpn N. V. filed Critical Koninklijke Kpn N. V.
Publication of CZ384699A3 publication Critical patent/CZ384699A3/cs
Publication of CZ297956B6 publication Critical patent/CZ297956B6/cs

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M3/00Automatic or semi-automatic exchanges
    • H04M3/42Systems providing special services or facilities to subscribers
    • H04M3/4228Systems providing special services or facilities to subscribers in networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)
  • Exchange Systems With Centralized Control (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Je popsán zpusob v telekomunikacní síti, ve kteréúcastník pripojený k výchozímu uzlu výchozí místní ústredny (102, 202) pozadoval aktivaci doplnkovésluzby umístené v aplikaci uvedeného výchozího uzlu. Uvedená doplnková sluzba vyuzívá cást transakcní zpusobilosti aplikace a odpovídající prvek abstraktní sluzby pro vytvorení dvoubodového dialogu transakcní zpusobilosti, mající identitu transakce,s odpovídající doplnkovou sluzbou v aplikaci cílového uzlu cílové místní ústredny (104, 204), se kterým je spojen adresovaný vzdálený úcastník. Uvedený dialog transakcní zpusobilosti ukoncuje zádost o soubezne probíhající telekomunikacní sluzbu umístenou v aplikaci mezilehlého uzlu (106, 206), pro umoznení operátorovi síte zabránit selhání provozusluzby, kdyz dochází k interakci mezi uvedenou doplnkovou sluzbou na bázi dvoubodové cásti transakcní zpusobilosti aplikace a uvedenou soubezne probíhající telekomunikacní sluzbou. Tento zpusob zahrnuje následující kroky: Vytvorení prenosové linky mezi príchozím dialogem transakcní zpusobilosti a odchozím dialogem transakcní zpusobilosti v mezilehlém uzlu (106, 206) pro vytvorení retezce dvoubodových dialogu transakcní zpusobilosti mezi výchozímuzlem výchozí místní ústredny (102, 202) a cílovým uzlem cílové místní ústredny (104, 204). Pouzitífunkce transparentního prenosu je nezávislé na pouzití doplnkových sluzeb prvku abstraktních sluzebna bázi cásti transakcní zpusobilosti v mezilehlých uzlech (106, 206). Odlisení zpracování a pokracování zretezených dialogu na bázi úcinku interakce, zpusobené uvedenou soubezne probíhající telekomunikacní sluzbou.

Description

Oblast techniky
Předkládaný vynález se týká způsobu v telekomunikační síti, ve které účastník připojený k výchozímu uzlu výchozí místní ústředny požadoval aktivaci doplňkové služby umístěné v aplikaci uvedeného výchozího uzlu, přičemž uvedená doplňková služba využívá část transakční způsobilosti aplikace a odpovídající prvek abstraktní služby pro vytvoření dvoubodového dialogu transakční způsobilosti, mající identitu transakce, s odpovídající doplňkovou službou v aplikaci cílového uzlu cílové místní ústředny, se kterým je spojen adresovaný vzdálený účastník, přičemž uvedený dialog transakční způsobilosti ukončuje žádost o souběžně probíhající telekomunikační službu umístěnou v aplikaci mezilehlého uzlu, pro umožnění operátorovi sítě zabránit selhání provozu služby, když dochází k interakci mezi uvedenou doplňkovou službou na bázi dvoubodové části transakční způsobilosti aplikace a uvedenou souběžně probíhající telekomunikační službou.
Dosavadní stav techniky
Je používána telekomunikační, kterou je možné považovat za sestávající z hierarchie o třech úrovních, to znamená místní úroveň zahrnující lokální či místní ústředny a uzly, tranzitní úroveň zahrnující tranzitní ústředny a uzly, a ústřednová úroveň zahrnující mezinárodní ústředny a uzly.
Množství telekomunikačních služeb, například služeb „volného telefonu (zelené linky)“ a „směrovací funkce“, je realizováno v uzlech umístěných nad místní úrovní, například v tranzitní úrovni. Pro tato specifická volání přijatá adresová informace, například volené číslo, vždy identifikuje službu, která je umístěna v mezilehlém uzlu. Tyto služby, realizované nad místní úrovní, provádějí množství překladů a volání je potom přesměrováno směrem k cílovému místu, které je adresováno přeloženým číslem. V závislosti na požadované aplikaci může být překlad čísla opakován, dokud volání není ukončeno směrem k uživateli, to jest účastníkovi, v cílovém síťovém celku.
Přídavně telekomunikační služba „přenositelnosti čísla“, která zajišťuje, že uživatel si udrží svoji číselnou identitu při změně operátora nebo geografické polohy, vyžaduje modifikaci směrovací informace pro ukončování volání směrem k adresovaným uživatelům. Pro tato volání přijatá adresová informace, například volané číslo, vždy identifikuje místní ústřednu, ke které byl uživatel připojen před jeho novým účastnickým profilem, jako je například nová geografická poloha.
Funkce „část transakční způsobilosti aplikace“ TCAP, rovněž označovaná pouze jako „transakční způsobilost“ TC, je komponent SS č. 7 použitý pro paketovou informaci od uživatele strukturovaným způsobem a vytváří dvoubodový dialog se vzdáleným uživatelem. Detailní specifikace pro provozní procedury, kódování a formátování TCAP a TC dialogů jsou popsány v doporučeních ITU-T Q.771 až Q.775.
TCAP dialogy jsou směrovány v síti prostřednictvím spodní signalizační vrstvy označované SCCP (část signalizačního spojovacího řízení). SCCP je komponent v SS č. 7 použitý pro řízení zpráv vysílaných přes síť; když zpráva je adresována do ústředny nemající přímé spojení s vysílací ústřednou. SCCP je standardizována v ITUT-T doporučeních Q.711 až Q.716. SCCP směrování využívá vždy jednoho ze dvou adresovacích mechanismů, označovaných jako GT adresování respektive SPC adresování. GT adresování využívá analýzu přijatého volání a volaného účastníka adresuje pro určení linky k následující směrovací entitě, zatímco SPC adresování využívá předem specifikovaných signalizačních identit dálkových vedení pro adresování následující linky k příští směrovací entitě. Pro služby obvyklý postup pro vytvoření TC dialogu začíná SCCP GT adresovací žádostí. Detailní popis provozních procedur, kódování a formátování SCCP způsobilosti může být nalezen v ITU-T doporučeních Q.711 až Q.714.
- 1 CZ 297956 B6
Množství telekomunikačních služeb na bázi TCAP již bylo realizováno na místní úrovni síťové hierarchie a provozováno s použitím informace volaného čísla jako adresování s globálním záhlavím. V případě, že SCCP GT adresa, použitá ve spojení se službou na bázi TCAP, identifikuje síťovou službu (například volný telefon), nebo adresuje uživatele, který změnil svoji geografickou polohu bez změny jeho telefonního čísla, prostřednictvím použití tak zvané „funkce přenositelnosti čísla“, pak SCCP GT informace adresy způsobí ukončení dialogu v uzlu, který nemá jakékoliv znalosti o poloze adresovaného uživatele a následně požadovaný dvoubodový TC dialog selže.
Mělo by být uvedeno, že provoz těchto služeb je obvykle realizován prostřednictvím vytvoření dvoubodového signalizačního vztahu nevztaženého na volání mezi výchozími a cílovými entitami a může trvat dlouhou časovou periodu. Tak například služba „dokončení volání s obsazeným účastníkem“ (CCBS) vytváří dialog mezi výchozími a cílovými místními ústřednami na maximálně 45 minut.
Aby byl umožněn provoz služby na bázi TC mezi výchozími a cílovými entitami ve stejné vrstvě, je potřebné předávat výsledné TC dialogy v mezilehlých zasahujících entitách. Tak každý zasahující mezilehlý uzel, to jest místní, tranzitní nebo mezinárodní ústředna, provádí předávací funkci mezi příchozím a odchozím TC dialogem. Dvoubodová propojitelnost může být dosažena prostřednictvím řetězce vyvolaných předávacích funkcí v každé zasahující mezilehlé ústředně.
Švédský patent 504,405 popisuje předávací postup pro přiřazení TC dialogů, aby se vyřešila interakce mezi službami CCBS a směrovací funkcí služby globální virtuální sítě GVNS. Interakce mezi těmito dvěmi službami vyžaduje novou službu CCBS-GVNS ASE, která k CCBS specifickým ASE operacím připojuje přídavné parametry a informační prvky použité pro lokalizaci adresovaného uživatele. Předávání je dosaženo realizací dvou „abstraktních obslužných prvků“ ASE pro služby CCBS, které jsou rovněž označovány jako CCBS-ASE entity a CCBS GVNS ASE, v tranzitní nebo mezinárodní ústředně, a specifické, neodhalené logiky, která realizuje přiřazení. Tento postup znamená, že pro každou novou službu na bázi TC je nutné zavést rovněž tuto službu v tomto mezilehlém bodu a zkonstruovat logiku pro provádění potřebného přiřazení.
Navíc interakce vznikající mezi službami na bázi TCAP a jinými službami, které jsou adresovány SCCP GT adresami, například přenositelnost čísla, nemusí vždy vyžadovat modifikaci služby ASE. Je tedy nutné podporovat předávání prostřednictvím množství překladů SCCP GT adres a předávání, kde jsou potřebné modifikace ASE.
Uvnitř inteligentní síťové architektury, specifikované v řadách doporučení ITU-T 1200, je mechanismus vytvoření volání zpracován prostřednictvím SSP (obslužný přepojovací bod) fyzických entit, zatímco služby jsou centralizovány v síti uvnitř SCP (obslužný řídicí bod) fýzické entity. SSP je uzel v síti, ve kterém mohou služby obdržet podporu z vnější databáze umístěné v SCP. Komunikace mezi SSP a SCP je prováděna přes ΓΝΑΡ, což je protokol na bázi TCAP.
Pro vyřešení interakce mezi službami na bázi TCAP a jinými službami umístěnými v SCO je nutné pravidelně komunikovat služby ASE na bázi TCAP, které končí v SSP se souběžně probíhající službou umístěnou v SCP, aniž by bylo závazné rozvinout všechny služby ASE na bázi TCAP ve všech SSP.
Množství standardizovaných doplňkových služeb (například CCBS) pracuje v telekomunikační síti prostřednictvím využití TCAP dvoubodové signalizační způsobilosti, to jest přímého vztahu mezi výchozími a cílovými entitami volání. Tyto služby vytvářejí TC dialog prostřednictvím využití síťových adres, které, v určitých případech, mohou identifikovat službu (například interakci s GVNS) nebo nesprávnou geografickou polohu vzdáleného uživatele (například přenositelnost čísla). Následně dvoubodová činnost služby na bázi TCAP selže buď v důsledku nevybavenosti službou SE, nebo v důsledku absence adresovaného uživatele v adresované entitě.
- 2 CZ 297956 B6
Je tedy prvním cílem předkládaného vynálezu navrhnout způsob a systém, který umožní síťovému operátorovi zabránit selháním podstatného množství činnosti služeb, když doplňkové služby na bázi dvoubodové TCAP, realizované v entitách na stejné úrovni, to jest místních ústřednách, interagují s jinými telekomunikačními službami realizovanými v mezilehlém uzlu, to jest v místních nebo tranzitních nebo mezinárodních ústřednách v důsledku nepřímého adresování vzdáleného uživatele.
Druhým cílem předkládaného vynálezu je navrhnout obecně použitelný způsob, který umožňuje vytvoření přenosové linky mezi příchozím TC dialogem a odchozím TC dialogem v mezilehlém uzlu, s výsledným řetězcem dvoubodových TC dialogů mezi výchozím uzlem výchozí místní ústředny a cílovým uzlem cílové místní ústředny.
Třetím cílem předkládaného vynálezu je nabídnout operátorovi transparentní přenosovou způsobilost bez nutnosti využívat v mezilehlých uzlech služeb ASE na bázi TCAP, a poskytnout způsobilost pro odlišení zpracování a pokračování zřetězených dialogů na bázi provozu účastných telekomunikačních služeb.
Čtvrtým cílem předkládaného vynálezu je navrhnout způsob pro komunikaci podstatných datových prvků mezi fyzickými entitami, to jest SSP a SCP, mezilehlého uzlu na bázi inteligentní síťové architektury pro vyřešení uvedené interakce bez použití služeb ASE na bázi TCAP ve všech SSP uzlech sítě. Tento komunikační způsob s sebou nese umožnění začlenění služby ASE v nové TC přenášené ASE, což je realizováno buď jako nové operace uvnitř INAP, nebo jako další doplňková služba na bázi TCAP, která má vlastní sadu ASE datových prvků.
Podstata vynálezu
Podle předkládaného vynálezu je tedy navržen způsob v telekomunikační síti, ve které účastník připojený k výchozímu uzlu výchozí místní ústředny požadoval aktivaci doplňkové služby umístěné v aplikaci uvedeného výchozího uzlu, přičemž uvedená doplňková služba využívá část transakční způsobilosti aplikace a odpovídající prvek abstraktní služby pro vytvoření dvoubodového dialogu transakční způsobilosti, mající identitu transakce, s odpovídající doplňkovou službou v aplikaci cílového uzlu cílové místní ústředny, se kterým je spojen adresovaný vzdálený účastník, přičemž uvedený dialog transakční způsobilosti ukončuje žádost o souběžně probíhající telekomunikační službu umístěnou v aplikaci mezilehlého uzlu, pro umožnění operátorovi sítě zabránit selhání provozu služby, když dochází k interakci mezi uvedenou doplňkovou službou na bázi dvoubodové části transakční způsobilosti aplikace a uvedenou souběžně probíhající telekomunikační službou, přičemž podstata vynálezu spočívá v tom, že zahrnuje následující kroky:
a) vytvoření přenosové linky mezi příchozím dialogem transakční způsobilosti a odchozím dialogem transakční způsobilosti v mezilehlém uzlu pro vytvoření řetězce dvoubodových dialogů transakční způsobilosti mezi výchozím uzlem výchozí místní ústředny a cílovým uzlem cílové místní ústředny, přičemž použití funkce transparentního přenosu je nezávislé na použití doplňkových služeb prvků abstraktních služeb na bázi části transakční způsobilosti v mezilehlých uzlech,
b) odlišení zpracování a pokračování zřetězených dialogů na bázi účinku interakce, způsobené uvedenou souběžně probíhající telekomunikační službou.
Výhodně uvedená funkce transparentního přenosu sděluje doplňkovou službu prvku abstraktní služby na bázi části transakční způsobilosti aplikace a uvedený účinek interakce mezi uvedeným příchozím dialogem transakční způsobilosti, uvedenou souběžně probíhající telekomunikační službou a uvedeným odchozím dialogem transakční způsobilosti.
- 3 CZ 297956 B6
Způsob podle vynálezu výhodně zahrnuje začlenění služby prvku abstraktní služby do nového prvku abstraktní služby přenosu transakční způsobilosti, který je realizován buď jako nové operace v části inteligentní síťové aplikace nebo jako další doplňková služba na bázi části transakční způsobilosti aplikace na vlastní sadě datových elementů prvku abstraktní služby.
Způsob podle vynálezu výhodně zahrnuje provedení v mezilehlém uzlu, v odezvě na přijetí žádosti příchozího dialogu transakční způsobilosti, týkající se doplňkové služby na bázi části transakční způsobilosti aplikace, která má přidělené podsystémové číslo, a na základě analýzy identity požadované doplňkové služby na bázi části transakční způsobilosti aplikace, jak byla identifikována specifickým objektovým identifikátorem doplňkové služby, a adresové informace volajícího a volaného účastníka, která byla vyslána společně se žádostí, následujících kroků:
i) spuštění funkce transparentního přenosu v případě buď, že objektový identifikátor není rozpoznán mezilehlým uzlem, nebo, že adresová informace volaného účastníka neadresuje účastníka připojeného k mezilehlému uzlu, ii) iniciování procedury transakční způsobilosti přenosové linky, která zahrnuje uchování přijaté identity dialogu transakční způsobilosti a vyslání žádosti o překlad čísla prostřednictvím komunikace adresové informace volaného a volajícího účastníka a doplňkové služby prvku abstraktní služby přijatého dialogu transakční způsobilosti do souběžně probíhající telekomunikační služby, iii) analýzu přijaté žádosti a určení souběžně probíhající telekomunikační službou nové adresové informace volaného účastníka a účinku interakce s doplňkovou službou na bázi části transakční způsobilosti aplikace, jak byla identifikována prostřednictvím přijatého objektového identifikátoru, iv) provedení procedury transakční způsobilosti přenosové linky, které zahrnuje vytvoření odchozího dialogu transakční způsobilosti na bázi přijaté adresové informace volaného účastníka a doplňkové služby prvku abstraktní služby ze souběžně probíhající telekomunikační služby, a vytvoření přiřazení mezi identitou příchozího a odchozího dialogu transakční způsobilosti na bázi přijaté indikace pro zpracování pokračování dialogu transakční způsobilosti.
Způsob podle vynálezu výhodně zahrnuje zajištění, pro krok odlišení zpracování a pokračování zřetězených dialogů, indikace prostřednictvím souběžně probíhající telekomunikační služby o tom, zda funkce transakční způsobilosti přenosové linky má použít řídicí funkci jednoho přiřazení pro vytvoření jednoduchého a jednoho přiřazení mezi příchozím a odchozím dialogem transakční způsobilosti, nebo řídicí funkci vícenásobného přiřazení pro vytvoření vícenásobného přiřazení s použitím dvou řídicích funkcí jednoho přiřazení mezi příchozím a odchozím dialogem transakční způsobilosti.
Způsob podle vynálezu výhodně zahrnuje rozhodnutí o použití řídicí funkce jednoho přiřazení, když doplňková služba prvku abstraktní služby na bázi části transakční způsobilosti aplikace, použitá v odchozím dialogu, je shodná s doplňkovou službou prvku abstraktní služby na bázi části transakční způsobilosti aplikace, přijatou příchozím dialogem transakční způsobilosti, a rozhodnutí o použití řídicí funkce vícenásobného přiřazení, když doplňková služba prvku abstraktní služby na bázi části transakční způsobilosti aplikace, použitá v odchozím dialogu, není shodná s doplňkovou službou prvku abstraktní služby na bázi části transakční způsobilosti aplikace, přijatou příchozím dialogem transakční způsobilosti.
Způsob vynálezu výhodně zahrnuje provedení kroků i) a ii) logickou entitou rozložení aplikace a první řídicí funkcí jednoho přiřazení, která přijímá dialog transakční způsobilosti a přenáší jej do uvedené logické entity rozložení aplikace pro další zpracování.
Způsob podle vynálezu výhodně zahrnuje vytvoření uvedené nové transakční způsobilosti přenosové linky prostřednictvím logické entity rozložení aplikace s uspořádanou uvedenou první řídicí
- 4 CZ 297956 B6 funkcí jednoho přiřazení pro vytvoření nového přiřazení žádostí o asistenci druhé řídicí funkce jednoho přiřazení přes řídicí funkci vícenásobného přiřazení.
Způsob podle vynálezu výhodně zahrnuje provedení v kroku ii) dalších kroků v logické entitě rozložení aplikace:
uchování identity příchozí transakce a adres globálního titulku řídicí části signalizačního spojení, vytvoření zprávy identifikující adresovanou službu a původce žádosti, zjištění, zda současný protokol, použitý pro komunikaci, podporuje přenosovou signalizaci transakční způsobilosti, a pokud podporuje začlenění příchozího bloku adres globálního titulku řídicí části signalizačního spojení, objektového identifikátoru a prvku abstraktní služby do operace žádosti o přenos a vyslání této operace do aplikace v mezilehlém uzlu, aby v něm byla zpracována pro vytvoření vhodné odezvy přenosu do logické entity rozložení aplikace, pokud nepodporuje vyslání vhodné operace pod současným protokolem do aplikace v mezilehlém uzlu, která v něm bude zpracována tak, aby vrátila novou vhodnou operaci pod současným protokolem do logické entity rozložení aplikace.
Způsob podle vynálezu výhodně zahrnuje provedení v aplikaci, v odezvě na přijetí operace pod současným protokolem, kroků:
identifikování adresované aplikace služby, provedení požadované akce nebo interakce a vytvoření nové adresy globálního titulku řídicí části signalizačního spojení, vyslání uvedené vhodné nové operace pod současným protokolem.
Způsob podle vynálezu výhodně zahrnuje provádění v aplikaci, v odezvě na přijetí operace žádosti o přenos, kroků:
rozbalení bloku adres globálního titulku řídicí části signalizačního spojení, objektového identifikátoru a prvku abstraktní služby, identifikace aplikace adresované služby, provedení požadované akce nebo interakce a vytvoření nové adresy globálního titulku řídicí části signalizačního spojení, vyslání operace odezvy přenosu do logické entity rozložení aplikace, přičemž této operaci v případě vícenásobného přiřazení předchází vytvoření nového prvku abstraktní služby, indikace příslušného objektového identifikátoru ajejích začlenění do operace odezvy přenosu před vysláním.
Způsob podle vynálezu výhodně zahrnuje provedení v logické entitě rozložení aplikace, v odezvě na přijetí v logické entitě rozložení aplikace operace pod současným protokolem, kroků: vytvoření identity odchozí transakce, uchování identity odchozí transakce a adres globálního titulku řídicí části signalizačního spojení, vytvoření nové TC-BEGIN z prvku abstraktní služby přijatého v operaci, přeložení adres globálního titulku řídicí části signalizačního spojení, vyslání TC-BEGIN do cílové vzdálené entity.
Způsob podle vynálezu výhodně zahrnuje provedení v logické entitě rozložení aplikace, v odezvě na přijetí v logické entitě rozložení aplikace odezvy přenosu z aplikace, a v případě jednoho přiřazení, kroků:
rozbalení přijatého bloku adres globálního titulku řídicí části signalizačního spojení, objektového identifikátoru a prvku abstraktní služby z operace odezvy přenosu,
- 5 CZ 297956 B6 vytvoření identity odchozí transakce, uchování identity odchozí transakce a adres globálního titulku řídicí části signalizačního spojení, vytvoření nové TC-BEGIN z přijatého prvku abstraktní služby, přeložení adres globálního titulku řídicí části signalizačního spojení, vyslání TC-BEGIN do cílové vzdálené entity.
Způsob podle vynálezu výhodně zahrnuje provedení v logické entitě rozložení aplikace, v odezvě na přijetí v logické entitě rozložení aplikace odezvy přenosu z aplikace, a v případě vícenásobného přiřazení, kroků:
vytvoření linky k novému prvku abstraktní služby přes řídicí funkci vícenásobného přiřazení, uchování řídicí funkce vícenásobného přiřazení linky a adres globálního titulku řídicí části signalizačního spojení, vytvoření nové TC-BEGIN z přijatého prvku abstraktní služby a přeložení adres globálního titulku řídicí části signalizačního spojení, vyslání TC-BEGIN do cílové vzdálené entity.
Způsob podle vynálezu výhodně zahrnuje provedení, v mezilehlém uzlu pro pokračování vytvořené transakční způsobilosti přenosové linky dokud není ukončena transakce dialogu transakční způsobilosti mezi výchozí a cílovou entitou, a v odezvě na přijetí v logické entitě rozložení aplikace jakékoliv základní funkce transakční způsobilosti s podsystémovým číslem SSN= „doplňková služba“, až na TC-BEGIN, a v případě, že identita transakce v logické entitě rozložení aplikace neexistuje, kroku:
ukončení dialogu transakční způsobilosti a vyslání zprávy do adresovaného prvku abstraktní služby, jak byl identifikován prostřednictvím objektového identifikátoru.
Způsob podle vynálezu výhodně zahrnuje provedení, v mezilehlém uzlu pro pokračování vytvořené transakční způsobilosti přenosové linky, dokud není ukončena transakce dialogu transakční způsobilosti mezi výchozí a cílovou entitou, a v odezvě na přijetí v logické entitě rozložení aplikace jakékoliv základní funkce transakční způsobilosti s podsystémovým číslem SSN= „doplňková služba“, až na TC-BEGIN, a v případě, že identita transakce v logické entitě rozložení aplikace existuje, přenos transakční způsobilosti bude vyslán přes řídicí funkci vícenásobného přiřazení a spuštění služby bylo vyžadováno, kroků:
vyslání příchozího prvku abstraktní služby do aplikace pro vytvoření nového prvku abstraktní služby, přijetí nového prvku abstraktní služby z aplikace, přeložení operace transakční způsobilosti s identitou transakce přenosu a adresou, vyslání operace transakční způsobilosti přenosu do výchozí nebo cílové vzdálené entity.
Způsob podle vynálezu výhodně zahrnuje provedení, v mezilehlém uzlu pro pokračování vytvořené transakční způsobilosti přenosové linky, dokud není ukončena transakce dialogu transakční způsobilosti mezi výchozí a cílovou entitou, a v odezvě na přijetí v logické entitě rozložení aplikace jakékoliv základní funkce transakční způsobilosti s podsystémovým číslem SSN= „doplňková služba“, až na TC-BEGIN, a v případě, že identita transakce v logické entitě rozložení aplikace existuje, přenos transakční způsobilosti bude vyslán přes řídicí funkci vícenásobného přiřazení a spuštění služby nebylo vyžadováno, kroků:
přeložení operace transakční způsobilosti s identitou transakce přenosu a adresou, vyslání operace transakční způsobilosti přenosu do výchozí nebo cílové vzdálené entity.
- 6 CZ 297956 B6
Způsob podle vynálezu výhodně zahrnuje provedení, v mezilehlém uzlu pro pokračování vytvořené transakční způsobilosti přenosové linky, dokud není ukončena transakce dialogu transakční způsobilosti mezi výchozí a cílovou entitou, a v odezvě na přijetí v logické entitě rozložení aplikace jakékoliv základní funkce transakční způsobilosti s podsystémovým číslem SSN= „doplňková služba“, až na TC-BEGIN, a v případě, že identita transakce v logické entitě rozložení aplikace existuje, ale přenos transakční způsobilosti nebude vyslán přes řídicí funkci vícenásobného přiřazení, kroků:
přeložení operace transakční způsobilosti s identitou transakce přenosu a adresou, vyslání operace transakční způsobilosti přenosu do výchozí nebo cílové vzdálené entity.
Předkládaný vynález bude v následujícím popisu poněkud podrobněji popsán prostřednictvím jeho příkladných provedení ve spojení s odkazy na připojené výkresy.
Přehled obrázků na výkresech
Obr. 1 znázorňuje síťovou architekturu ilustrující standardní typ modelování pasivního TC přenosového mechanismu v mezilehlém uzlu pro zajištění dvoubodového vztahu mezi ASE ve výchozí místní ústředně a odpovídající ASE v cílové místní ústředně;
Obr. 2 znázorňuje podobnou síťovou, architekturu jako na obr. 1 pro ilustraci standardního typu modelování aktivního TC přenosového mechanismu v mezilehlém uzlu pro zajištění dvoubodového vztahu mezi ASE ve výchozí místní ústředně a odpovídající ASE v cílové místní ústředně;
Obr. 3, obr. 4 a obr. 5 jsou vývojové diagramy ilustrující akce prováděné v mezilehlém uzlu podle obr. 1 nebo obr. 2 po spuštění doplňkové služby na bázi TCAP a vytvoření pasivního nebo aktivního TC přenosového přiřazení mezi příchozím a odchozím dialogem;
Obr. 6 je vývojový diagram ilustrující akce prováděné v mezilehlém uzlu pro pokračování vytvořené TC přenosové linky podle obr. 3 až obr. 5, dokud nejsou ukončeny transakce TC dialogů mezi výchozími a cílovými entitami;
Obr. 7 je vývojový diagram ilustrující akce prováděné aplikací v mezilehlém uzlu při využití vytvoření TC přenosové linky podle obr. 3 až obr. 6.
Příklady provedení vynálezu
Množství standardizovaných doplňkových služeb (například CCBS) pracuje v telekomunikační síti prostřednictvím využití TCAP dvoubodové signalizační způsobilosti, to jest přímého vztahu mezi službou ASE ve výchozím a cílovým uzlem, se kterými jsou spojeni účastníci.
Služby na bázi TCAP vytvářejí TCAP dvoubodový TC dialog prostřednictvím použití SCCP směrovacího mechanismu, to jest SCCP GT adresy volaného účastníka a podsystémového čísla SSN, které je prvkem SCCP adresování použitého pro identifikaci aplikace. Je třeba si všimnout, že pro doplňkové služby byla ITU-T přidělena pro SSN hodnota osmibitové slabiky „0000 1011“. Navíc je rozlišení mezi různými doplňkovými službami dále prováděno prostřednictvím objektového identifikátoru, který je specifickou hodnotou použitou pro adresování vhodné služby ASE.
V případě, že informace voleného B-čísla, která je použita jako SCCP GT adresa volaného účastníka, se týká síťové služby, například GVNS směrovací adresy, nebo nesprávného geografického umístění vzdáleného uživatele, například přenositelnosti čísla, pak dvoubodová operace služby na bázi TCAP selže. Pro úspěšné vytvoření dvoubodového vztahu mezi entitami na stejné úrovni v zasahujícím uzlu, ve kterém je služba realizována, je tedy nutné uspořádat TC přenosovou linku mezi příchozím TC dialogem a novým odchozím TC dialogem adresujícím vzdáleného
- 7 CZ 297956 B6 uživatele. Takový uzel se stává mezilehlým uzlem ve dvoubodovém vztahu mezi výchozím a cílovým uzlem.
Navíc na základě té skutečnosti, že se interakce mezi službami na bázi TCAP a jinými síťovými službami liší, například CCBS a GVNS nebo CCBS a přenositelnost čísla, může se rovněž lišit způsobilost TC přenosové linky a tudíž byly S specifikovány pasivní režim přiřazení a aktivní režim přiřazení, jak bude podrobněji popsáno níže.
Na obr. 1 a obr. 2 je znázorněno modelování síťové architektury, zahrnující blokové entity začleněné ve vytváření dvoubodových dialogů přes funkci TC přenosové linky. Popisovaná modelovací technika je prováděna podle běžného popisu uvedeného v doporučeních ITU-T, například ITU-T Q.1218, pro ilustraci vztahu mezi různými blokovými entitami. Přesněji doporučení ITU-T Q.1218 definuje prvky protokolu INAP CS1 (část inteligentní síťové aplikace), které jsou požadovány pro podpory nastavení způsobilosti inteligentní sítě.
Ačkoliv jsou jinak shodné, liší se obr. 1 a obr. 2 tím, že obr. 1 je realizován pro ilustraci vytvoření funkce pasivní TC přenosové linky, rovněž označované jako pasivní režim, zatímco obr. 2 je realizován pro ilustraci vytvoření funkce aktivní TC přenosové linky, rovněž označované jako aktivní režim. V závislosti na tom, zdaje použitelný pasivní nebo aktivní režim, to jest obr. 1 nebo obr. 2, linky definující určité z blokových entit v příslušném obrázku jsou uvedeny čárkovaně pro indikaci, že entita existuje v uzlu, ale není začleněna ve dvoubodovém vztahu mezi entitami na stejné úrovni.
Ilustrativní prezentace TC přenosové linky na obr. 1 a obr. 2 znázorňuje síťovou architekturu zahrnující výchozí místní ústřednu 102/202, cílovou místní ústřednu 104/204 a mezilehlý uzel 106/206. Výše a rovněž v popisu dále vztahový značka začínající číslicí 1 indikuje, že příslušný blok přísluší do uspořádání podle obr. 1, zatímco vztahová značka začínající číslicí 2 indikuje, že příslušný blok přísluší do uspořádání podle obr. 2. Každý z uzlů zahrnuje společnou sadu blokových entit, které jsou použity při vytváření TC dialogů. Blokové entity této společné sady jsou následující:
- část přenosu zpráv, označovaná jako MTP a vztahovou značkou označena blokem jako MTP 108/208, je použita pro přenos zpráv mezi uzly v síti, když je použito SS č. 7. MPT je definována v ITU-T doporučeních Q.701 až Q.705.
- část signalizačního spojovacího řízení, označovaná jako SCCP a vztahovou značkou označena blokem jako SCCP 110/210. Tato SCCP je komponent v SS č. 7, který je použit pro řízení zpráv vysílaných přes síť, když je zpráva adresována do ústředny nemající přímé spojení s vysílací ústřednou. SCCP směrování využívá jednoho ze dvou adresovacích mechanismů, označovaných jako GT adresování respektive SPC adresování. GT adresování využívá analýzu přijatých adres volajícího a volaného účastníka pro určení linky k následující směrovací entitě, zatímco SPC adresování využívá předem specifikovaných dálkových signalizačních identit pro adresování následující linky k příští směrovací entitě. Pro služby je normální způsob pro vytvoření TC dialogu započat žádostí o SCCP GT adresování. Detailní popis provozních procedur, kódování a formátování SCCP způsobilosti lze nalézt v ITU-T doporučeních Q.711 až Q.716.
- část transakční způsobilosti aplikace, označovaná jako TCAP a vztahovou značku označena blokem jako TCAP 112/212. Tato funkce, rovněž označovaná pouze jako „transakční způsobilost, TC“, je komponent SS č. 7, použitý pro paketovou informaci od uživatele strukturovaným způsobem a vytváří dvoubodový dialog se vzdáleným uživatelem. Detailní specifikace pro provozní procedury, kódování a formátování TCAP a TC dialogů jsou popsány v ITU-T doporučeních Q.771 ažQ.775. TCAP dialogy jsou směrovány v síti prostřednictvím spodní signalizační vrstvy, kterou je SCCP 110/210 popisovaná výše.
- funkce řízení jednoho přiřazení, označovaná jako SACF a označená vztahovou značkou blokem SACF 114/214, je použita pro vytvoření jednoduchého a jednoho přiřazení mezi příchozí stranou a odchozí stranou dialogu.
- 8 CZ 297956 B6
- funkce řízení vícenásobného přiřazení, označovaná jako MACF a označená vztahovou značkou blokem MACF 116/216, je použita když mají být přiřazeny dohromady dvě SACF.
- logická entita rozložení aplikace, označovaná jako ADLE a označené vztahovou značkou blokem ADLE 136/236, má za úkol ukončit příchozí TC dialog, spustit přenos TC dialogu, pokud je to žádoucí, a realizovat TC přenosovou linku, kdykoliv je to potřebné. Funkce ADLE bude podrobněji popsána níže.
- každý z těchto bloků 102/202, 104/204 a 106/206 má rovněž aplikaci 118/218, 120/220 respektive 122/222. Tato aplikace obsahuje sadu síťových služeb, které jsou použitelné pro tuto specifickou síťovou entitu. Služby aplikace 118/218 tedy nemusí být shodné se službami aplikace 120/220 nebo službami aplikace 122/222. Například může služba CCBS existovat v aplikacích 118/218 a 122/222 místních ústředen 102/202 respektive 106/206, zatímco služba GVNS existuje v aplikaci 120/220 tranzitní nebo mezinárodní ústředny mezilehlého uzlu 106/206.
Jsou zde navíc různé služby ASE, viz 124/224 a 126/226 uvnitř výchozí místní ústředny 102/202; 130/230 a 132/232 uvnitř mezilehlého uzlu 106/206; a 124/224 a 128/228 uvnitř cílové místní ústředny 104/204. Přesněji každá služba ASE odpovídá službě uvnitř aplikaci tohoto příslušného uzlu a je použita pro komunikaci vysílání mezi službou v entitách na stejné úrovni. Pro účely dalšího výkladu, uvedeného níže, může být například ASE 124/224 považována za službu CCBS ASE.
Modelování uzlové entity může rovněž vyhovovat inteligentní síťové architektuře zahrnující obslužný přepojovací bod (SSP) a obslužný řídicí bod (SCP), jakje popsáno v ITU-T doporučeních, série Q.1200. Možná úprava takové architektury na výchozí místní ústředně 102/202 nebo cílové místní ústředně 104/204 nebo mezilehlém uzlu 106/206 není znázorněna na obr. 1 a obr. 2. Pokud ale tato architektura platí, pak komunikace mezi SSP a SCP je dosažena prostřednictvím specifické služby ASE 134/234, která označuje protokol části inteligentní síťové aplikace (INAP).
Ve výchozí místní ústředně 102/202 účastník, připojený k tomuto uzlu, požaduje aktivaci služby, například CCBS, umístěné v entitě označené jako blok aplikace 118/218, která dále využívá svoji odpovídající službu ASE, například 124/224 (CCBS ASE), pro vytvoření vztahu s odpovídající službou pro dosažení dvoubodového TC dialogu mezi dvěma entitami, představovanými například ústřednami 102/202 a 104/204, na stejné úrovni. Služba ASE 124/224 vytváří TC dialog prostřednictvím indikace jejího objektového identifikátoru a podsystémového čísla přiděleného pro doplňkové služby, to jest SSN = „0000 1011“, a prostřednictvím vyslání žádosti, to jest základní funkce TC-BEGIN, dále skrz SACF 114/214, TCAP 112/212, SCCP 110/210 a MTP 108/208. Žádost o TC dialog je směrována prostřednictvím SCCP a MTP v síti s použitím volaného B-čísla jako SCCP GT adresová informace, která lokalizuje vzdálenou entitu, například mezilehlý uzel 106/206. Vyžádaný TC dialog je směrován do vzdálené entity na fyzické cestě 138/238.
V mezilehlém uzlu 106/206 je příchozí TC dialog na fyzické cestě 138/238 vyslán k vhodné ASE přes MTP 108/208, SCCP 110/210, TCAP 112/212 a SACF 114/214. SCCP 110/210 identifikuje příjemce TC dialogu prostřednictvím SSN uváděného výše, což na obr. 1 a obr. 2 odpovídá ukončení TC dialogu v ADLE 136/236. Funkcí ADLE 136/236 je detekovat a realizovat, pokud je to nezbytné, TC přenosovou linku mezi příchozím dialogem a odchozím dialogem. Když je zjištěno, že pro tento TC dialog má být aplikována TC přenosová linka, vysílá ADLE 136/236 žádost do aplikace 120/220, která dále realizuje potřebné akce a upozorní ADLE 136/236, zdaje požadován pasivní nebo aktivní režim TC přenosové linky. Komunikace mezi ADLE 136/236 a aplikací 120/220 může být realizována, například, prostřednictvím protokolu specifikovaného na obr. 8. Operace zde uvedené mohou být rovněž přídavně aplikovány jako zlepšení existujících protokolů. Například mohou být tyto operace začleněny do rozsahu budoucího protokolu, například INAP CS3 podle ITU-T doporučení Q.1238.
- 9 CZ 297956 B6
Pasivní režim přiřazení, to jest jak je ilustrováno na obr. 1, je TC přenosová linka, která využívá stejnou příchozí službu ASE, to jest datovým prvkům mohou být přiděleny nové hodnoty, ale na odchozím TC dialogu bude platit stejná sada datových prvků.
Aktivní režim přiřazení, to jest jak je ilustrováno na obr. 2, je TC přenosová linka realizovaná přes MACF 216, která propojuje dvě SACF 214 a využívá další službu ASE 232, tak například příchozí služba ASE může být modifikována přidáním nových parametrů a datových prvků na odchozí TC dialog. Pro aktivní režim TC přenosové linky je potřebné realizovat alespoň dvě TC přenosové linky ve dvou mezilehlých uzlech, aby se obnovila původní příchozí služba ASE pro ukončení v cílové místní ústředně 104/204 a pro získání dvoubodového přiřazení s výchozí místní ústřednou 102/202. Tento řetězec není znázorněn na žádném z obrázků.
V mezilehlém uzlu 106/206 vytváří ADLE 136/236 odchozí TC dialog prostřednictvím O1D (objektový identifikátor), SSN a čísla volaného účastníka z aplikace pro zřetězení aplikace s cílovou místní ústřednou 104/204 prostřednictvím vyslání žádosti, to jest základní funkce TCBEGIN, skrz SACF 114/214, TCAP 112/212, SCCP 110/210 a MTP 108/208. Tato žádost je příslušně vyslána do cílové místní ústředny 104/204 na fyzické lince 140/240.
V cílové místní ústředně 104/204 je příchozí TC dialog na fyzické cestě 140/240 vyslán do vhodné služby ASE přes MTP 108/208, SCCP 110/210, TCAP 112/212, a SACF 114/214. Přijatá hodnota SSN a hodnota objektového identifikátoru pro specifickou službu indikují, že TC dialog je adresován do služby ASE 124/224, například CCBS ASE, která dále vysílá žádost do přidružené služby, například CCBS, uvnitř aplikace 122/222.
Tak je dvoubodové přiřazení služby mezi výchozí místní ústřednou 102/202, a cílovou místní ústřednou 104/204, vytvořeno přes mechanismus TC přenosové linky v mezilehlém uzlu 106/206. Pokračování dialogu na TC přenosové lince mezi výchozí místní ústřednou 102/202 a cílovou místní ústřednou 104/204 bude procházet mezilehlý uzel 106/206 buď transparentně, nebo přes aplikaci 120/220, v závislosti na použitelném režimu TC přenosu, to jest pasivní režim, aktivní režim, nebo režim bez spouštění.
Přiřazení mezi příchozím TC dialogem a TC odchozím dialogem je uchováváno v mezilehlém uzlu 106, dokud není toto dvoubodové přiřazení ukončeno. Spojení je identifikováno prostřednictvím příchozích a odchozích dat, jako je ID transakce a SCCP adresy, jak je znázorněno v Tabulce 1 níže.
Tabulka 1
ID příchozí transakce (nebo MACF linky) ID odchozí transakce (nebo MACF linky) žádost o spuštění příchozí SCCP adresa odchozí SCCP adresa
ID ID ano/ne volaj ící, volaná volaj ící, volaná
ID ID ano/ne volaj ící, volaná volající, volaná
: í
·
- 10CZ 297956 B6
ID transakce je identita vytvořená TCAP, která identifikuje TC dialog, který je vytvářen. Sloupce žádosti o spuštění v tabulce 1 je specifická indikace sdružená s aktivním režimem TC přenosové linky a je použita službou pro indikaci jejího zájmu při dohlížení na pokračování TC dialogu. Pokud spuštění není požadováno, pak datové prvky TC dialogu budou mapovány z příchozí strany na odchozí stranu vytvářené TC přenosové linky v mezilehlém uzlu 106/206.
Obr. 3, obr. 4 a obr. 5 jsou vývojové diagramy ilustrující akce prováděné v mezilehlém uzlu podle obr. 1 nebo obr. 2 po spuštění doplňkové služby na bázi TCAP a vytvoření pasivního nebo aktivního přiřazení TC přenosu mezi příchozím a odchozím dialogem. Při popisu těchto akcí v popisu níže budou rovněž tam, kde to bude použitelné, činěny odkazy na TC přenosový protokol specifikovaný na obr. 8.
Obr. 3 ilustruje kroky prováděné ADLE 136/236 mezi přijetím TC dialogu a vysláním vhodného výsledku těchto kroků do aplikace.
Po přijetí funkce TC-BEGIN mající SNN = „0000 1011“ je žádost ukončena v ADLE, která rozhodne zda funkce TC přenosové linky bude či nebude vyvolána. Toto rozhodnutí je založeno na kritériích ilustrovaných v Tabulce 2 níže.
Tabulka 2
Globální OID SCCP volaná adresa Akce
Ano OK Bez přenosu
Ano NOK Přenos
Ne OK Přenos
Ne NOK Přenos
Přičemž v Tabulce 2:
OK = přijatá SCCP volaná adresa ukazuje na definovaného uživatele uvnitř uzlu 304.
NOK = přijatá SCCP volaná adresa ukazuje na uživatele, majícího indikaci přenositelnosti čísla nebo na identifikátor služby, a podobně.
Na obr. 3 blok 302 indikuje přijetí TC-BEGIN v ADLE. V kroku 304 ADLE analyzuje, zda může být rozpoznán globální objektový identifikátor OID pro službu ASE. Pokud ano, pokračuje se dalším krokem 306 pro zjištění, zda existuje GT volaná adresa. Pokud ano, je TC dialog ukončen v kroku 308 a TC žádost pocházející z výchozí místní ústředny 102 je předána do adresované služby ASE identifikované prostřednictvím OID jako rozpoznaná v kroku 304. Tato situace odpovídá řádku 1 v tabulce 2, což znamená, že funkce TC přenosu nebude vyvolána.
Pokud globální OID nemůže být rozpoznán v kroku 304, bez ohledu na to, zda GT volaná adresa existuje či nikoliv, pak, jak odpovídá řádkům 3 a 4 v tabulce 2, funkce TC přenosu bude vyvolána. Totéž bude platit pro případ, ve kterém v kroku 306 nemůže být nalezena adresovaná GT volaná adresa, jak odpovídá řádku 2 v tabulce 2.
Další krok 309 prováděný ADLE 136 bude nyní uchování příchozího ID transakce a SCCP GT adres. Dalším krokem 310 prováděným ADLE 136 je vytvoření zprávy uvádějící aplikační adresu = „SCCP GT adresa volaného účastníka“, identifikující adresovanou službu, a odesílatele = „ADLE-ID“, identifikujícího původce žádosti.
- 11 CZ 297956 B6
V kroku 312 ADLE 136 rozhodne o tom, zda je podporována TC přenosová signalizace. Rozhodnutí v tomto ohledu závisí na protokolu použitém pro komunikaci.
V případě, že ADLE a aplikace v mezilehlém uzlu jsou s umístěny ve stejné entitě, pak je komunikace prováděna prostřednictvím vnitřního komunikačního schématu, který není předmětem tohoto popisu. Pokud ale mezilehlý uzel odpovídá inteligentní síťové architektuře nebo pokud adresovaná služba, například služba překladu čísla, je umístěna v jiné entitě, pak komunikace mezi ADLE a síťovou službou uvnitř aplikace probíhá s použitím jednoho z následujících dvou typů protokolu.
1. Existující protokol, například nastavení 1 způsobilosti INAP (CS1), jak je popsáno v ITU-T doporučeních Q.1210 až Q.1219. Vzhledem ke skutečnosti, že takový existující protokol nemá způsobilost transportu datových prvků TC přenosové linky, bude způsob podle obr. 8 vždy implikovat, že výsledné dvoubodové přiřazení je pasivním režimem TC přenosové linky, což znamená způsobilost modifikace SCCP GT adresové informace.
2. Zlepšený protokol, například nastavení 3 způsobilosti INAP (CS3) nebo ADLE ASE na bázi TCAP podle obr. 8, nebo jakýkoliv jiný vhodný protokol na bázi TCAP.
Pokud v kroku 312 je výsledek ano, to jest komunikace je založena na protokolu typu 2, pak ADLE 136 balí příchozí blok SCCP GT adres, OID a ASE do operace žádosti o přenos v kroku 314 a vysílá tuto operaci do aplikace 120 v kroku 316, srovnej protokol podle obr. 8.
Pokud v kroku 312 je výsledek ne, to jest komunikace je založena na protokolu typu 1, pak ADLE 136 vysílá vhodnou INAP operaci do aplikace 120 v kroku 318.
Na obr. 4 jsou znázorněny kroky prováděné ADLE 136 po přijetí požadované INAP operace nebo odezvy na přenos z aplikace 120, jak je naznačeno bloky nebo kroky 402 a 404.
V případě, že byla přijata odezva na přenos, pak v kroku 406 je rozbalen přijatý blok SCCP adres, OID a ASE z operace odezvy na přenos, srovnej protokol podle obr. 8. V kroku 408 je zjišťováno, zda se jedná o jednoduché, jedno přiřazení. Pokud ne, procedura pokračuje podle popisu uvedeného později ve spojení s odkazy na obr. 5.
Pokud je v kroku 408 výsledkem ano, pak v kroku 410 je zjišťováno, zda se OID z kroku 406, pokud bylo přijato, liší od OID z kroku 316 v ukončeném dialogu. Pokud ano, pak se jedná o chybu a v kroku 412 je vyslána chybová zpráva, například „Chyba, vyšli TC-P-ABORT“, nebo jakoukoliv základní chybovou funkci, do výchozí vzdálené entity, to jest do výchozí místní ústředny 102.
Pokud je výsledkem v kroku 410 ne, pak procedura pokračuje krokem 414, ve kterém je provedeno vytvoření ID odchozí transakce. V kroku 416 jsou uloženy ID odchozí transakce a SCCP GT adresy. V kroku 418 je vytvořena nová TC-BEGIN buď z ASE přijaté v INAP operaci v kroku 402, nebo z ASE 124 přijaté od uzlové výchozí místní ústředny 102. SCCP GT adresy jsou překládány (kompilovány) z přijaté SCCP volané adresy, srovnej obr. 8. V kroku 420 je TCBEGIN vyslána do cílové vzdálené entity, to jest do cílové místní ústředny 104.
Obr. 5 je vývojový diagram ilustrující proceduru následující po rozhodnutí provedeném v kroku 408 podle obr. 4, totiž že odezva identifikuje vícenásobné přiřazení.
V kroku 502 je provedena kontrola pro ověření, zda požadované spouštění pokračuje. Pokud ano je v kroku 504 uchován sledovací indikátor v TC přenosové tabulce 1. Pokud je výsledkem v kroku 502 ne, pak proces pokračuje přímo v tomto případě do kroku 506, který následuje
- 12CZ 297956 B6 rovněž po kroku 504. V kroku 506 je ověřeno, zda existuje OID přijatý v odezvě na přenos podle kroku 404 na obr. 4.
V případě, že přijatý OID neexistuje, pak mezilehlý uzel nepodporuje požadovanou službu ASE a procedura končí v kroku 508, ve kterém je vyslána chybová zpráva, například „Chyba, vyšli TCP-ABORT“, do výchozí vzdálené entity, to jest do výchozí místní ústředny 102. Pokud je výsledek v kroku 506 ano, pak procedura pokračuje následovně.
V kroku 510 je vytvořena linka k nové službě ASE identifikované prostřednictvím OID a přijaté z aplikace 120 v kroku 406 přes MACF.
V kroku 512 jsou potom uloženy MACF linka a SCCP GT adresy.
V kroku 514 je vytvořena nová TC-BEGIN z přijaté služby ASE a jsou přeloženy (kompilovány) SCCP GT adresy.
V kroku 516 je TC-BEGIN vyslána do cílové vzdálené entity, to jest cílové místní ústředny 104.
Obr. 6 ilustruje akce prováděné v mezilehlém uzlu 206 pro pokračování vytvořené TC přenosové linky podle obr. 3 až obr. 5, dokud TC dialogové transakce mezi výchozími a cílovými entitami nejsou ukončeny.
Blok nebo krok 602 realizuje přijetí v ADLE 240 jakékoliv TC základní funkce s SSN = „doplňková služba“, až na TC-BEGIN z výchozí nebo cílové vzdálené entity, jako jsou ústředny 202 respektive 204.
V kroku 604 je ověřováno, zda ID transakce existuje v ADLE. Pokud ne, pak v kroku 606 je TC dialog ukončen a do adresované ASE, jak byla identifikována prostřednictvím OID, je vyslána zpráva. Pokud je výsledek kroku 604 ano, pak v kroku 608 je zjišťováno, zda TC přenos bude vysílán přes MACF 216 podle uchované informace v tabulce 1.
Pokud je výsledkem kroku 608 ano, pak je v kroku 610 zjišťováno, zda bylo požadováno spuštění služby. Pokud ano, pak je vyslána příchozí ASE do aplikace 220 v kroku 612. V kroku 614 je ASE přijímána z aplikace 220.
V kroku 616 je proveden překlad (kompilace) TC operace s ID přenosové transakce a adresou obsaženou v tabulce 1 pro TC přenos. V kroku 618 je tato přenosová TC operace vyslána do výchozí nebo cílové vzdálené entity, jako jsou ústředny 202 respektive 204.
Pokud je výsledkem buď kroku 608 nebo kroku 610 ne, pak v obou případech proces pokračuje přímo do kroku 616.
Obr. 7 ilustruje akce prováděné aplikací 120/220 v mezilehlém uzlu 106/206 mezi přijetím buď INAP operace vyslané v kroku 318 nebo operace vyslané v kroku 316 na obr. 3 a vyslání příslušné odezvy přijaté v kroku 402 respektive 404 podle obr. 4, nebo mezi přijetím ASE vyslané v kroku 612 na obr. 6 a vysláním ASE v příslušné odezvě přijaté v kroku 614 podle obr. 6. Je využito vytvoření TC přenosové linky podle kroku 312 na obr. 3 respektive podle kroku 608 na obr. 6.
Příznak stavu dotazu je definován jako Stav dotazu = nepravdivý (FALŠE) v kroku 701. INAP operace, vyslaná v kroku 3J_8, je přijata v kroku 702 a operace žádosti o přenos, vyslaná buď v kroku 316 nebo v kroku 612, je přijata v kroku 704. Pro posledně uvedený případ proces pokračuje krokem 706, ve kterém je rozbalen přijatý blok SCCP GT adres, OID a ASE z operace žádosti o přenos (srovnej obr. 8) a příznak stavu dotazu jev kroku 708 nastaven na pravdivý (TRUE).
- 13CZ 297956 B6
V obou případech proces pokračuje, bud’ z kroku 702, nebo z kroku 708, krokem 710, ve kterém je proveden pokus o identifikaci aplikace adresované služby. V kroku 712 je zjišťováno, zda aplikace služby je identifikována. Pokud není, pak došlo k chybě a v kroku 713 se proces vrací do ADLE. Pokud ano, pak je v kroku 714 provedena požadovaná akce nebo interakce aje vytvořena nová SCCP GT adresa.
V kroku 716 je ověřen stav TRUE příznaku stavu dotazu. Pokud je odpověď v kroku 716 ano, pak je v kroku 718 zjišťováno, zda se jedná o jednoduché jedno přiřazení. Pokud se jedná o tento případ, pak proces pokračuje do kroku 720, ve kterém je do ADLE vyslána odezva přenosu, které má být v ADLE přijata v kroku 404 nebo v kroku 616. Pokud je odpověď v kroku 718 ne, pak předchází kroku 720 krok 722, ve kterém je vytvořena nová ASE, je indikován příslušný OID a tyto komponenty jsou začleněny do operace odezva přenosu.
Pokud je odpověď v kroku 716 ne, pak v kroku 724 je vhodná ΓΝΑΡ operace vyslána do ADLE 136, která zde má být přijata v kroku 402.
Níže je ilustrován příklad ASE operace na bázi TCAP, vytvořený ve formě protokolu TC přenosu, použitého prostřednictvím ADLE pro komunikaci s aplikací 120/220 služby. Tyto operace by mohly být rovněž podporovány jinými protokoly, například budoucím INAP CS3 protokolem.
Definice Explicitních Příznaků :: =
BEGIN
Imports Operation,
Error
From TCAPMessages (ITU-T doporučení Q.773 modul A(0)} — ÚPY operací
RelayRequest: : = Operation
Parameter Sequence { sccpCalledAddress adresa, sccpCallingAddress [1] adresa doplňková,
Service Objectld [2] objektový identifikátor služby - doplňkový,
AsePackage [3] blok ASE - doplňkový,...} — IF ServiceObjectld vynechán, THEN — aplikace předpokládá překlad adres — požadavek na přenos (RelayRequest).
— End of RelayRequest Operation definiton. (konec definice operace RelayRequest)
RelayResponse : : = Operation
Parameter Sequence { single Association triggeringRequested sccpCalledAddress implicitně booleova TRUE, implicitně booleova FALŠE adresa, sccpCallingAddress [1] adresa doplňková,
Service Objectld [2] objektový identifikátor služby - doplňkový,
-14CZ 297956 B6
AsePackage [3] blok ASE - doplňkový,...} — singleAssociation označuje SACF nebo MACF indikátor — IF FALŠE, THEN — serviceObjectld se stává povinným prvkem.
— End of RelayResponse Operation definiton. (konec definice operace RelayResponse) — definice konstant a typu dat
Address : : = OCTECT STRING (SIZE (L.maxiengthofaddressfield)) — adresa je kódována podle popisu v ITU-T doporučení Q.713
ServiceObjectld : : = OBJECTIDENTIFIER
AsePackage : := CHARACTER STRING (SIZE (L.maxiengthofasedata)) — End of Relay-Protocol.
Operace RelayRequest přenáší službu ASE vyslanou z výchozí místní ústředny 102/202 do mezilehlého uzlu 106/206. Parametry sccpCalledAddress a sccpCallingAddress nesou přijatou SCCP adresovací informaci, to jest SCCP GT adresy volaného a volajícího účastníka, parametr serviceObjectld nese objektový identifikátor služby, definovaný prostřednictvím vyslané ASE, a parametr asePackage nese začleněné prvky ASE dat, jak jsou přijímána z vyslané ASE, například služby ASE 124 ve výchozí místní ústředně 102/202.
Operace RelayResponse přenáší službu ASE, která je vyslána mezilehlým uzlem 106/206 do následujícího uzlu, například cílové místní ústředny 104/204. Booleovy proměnné singleAssociation a triggeringRequested indikují pro ADLE 136/236 zpracování odchozího TC dialogu. Parametry sccpCalledAddress a sccpCallingAddress nesou vyslanou SCCP adresovací informaci, to jest SCCP GT adresy volaného a volajícího účastníka, parametr serviceObjectld nese objektový identifikátor služby, identifikující vyslanou službu ASE v případě přiřazení MACF, a parametr asePackage nese začleněné prvky ASE dat, která jsou vysílána do následujícího uzlu ve vyslané ASE, například službě ASE 132 ve výchozí místní ústředně 106/206.

Claims (18)

  1. PATENTOVÉ NÁROKY
    1. Způsob v telekomunikační síti, ve které účastník připojený k výchozímu uzlu výchozí místní ústředny (102, 202) požadoval aktivaci doplňkové služby umístěné v aplikaci uvedeného výchozího uzlu, přičemž uvedená doplňková služba využívá část transakční způsobilosti aplikace a odpovídající prvek abstraktní služby pro vytvoření dvoubodového dialogu transakční způsobilosti, mající identitu transakce, s odpovídající doplňkovou službou v aplikaci cílového uzlu cílové místní ústředny (104, 204), se kterým je spojen adresovaný vzdálený účastník, přičemž uvedený dialog transakční způsobilosti ukončuje žádost o souběžně probíhající telekomunikační službu umístěnou v aplikaci mezilehlého uzlu (106, 206), pro umožnění operátorovi sítě zabránit selhání provozu služby, když dochází k interakci mezi uvedenou doplňkovou službou na bázi dvoubodové části transakční způsobilosti aplikace a uvedenou souběžně probíhající telekomunikační službou, vyznačující se t í m , že zahrnuje následující kroky:
    - 15CZ 297956 B6
    a) vytvoření přenosové linky mezi příchozím dialogem transakční způsobilosti a odchozím dialogem transakční způsobilosti v mezilehlém uzlu (106, 206) pro vytvoření řetězce dvoubodových dialogů transakční způsobilosti mezi výchozím uzlem výchozí místní ústředny (102, 202) a cílovým uzlem cílové místní ústředny (104, 204), přičemž použití funkce transparentního přenosu je nezávislé na použití doplňkových služeb prvků abstraktních služeb na bázi části transakční způsobilosti v mezilehlých uzlech (106, 206),
    b) odlišení zpracování a pokračování zřetězených dialogů na bázi účinku interakce, způsobené uvedenou souběžně probíhající telekomunikační službou.
  2. 2. Způsob podle nároku 1, vyznačující se tím, že uvedená funkce transparentního přenosu sděluje doplňkovou službu prvku abstraktní služby na bázi části transakční způsobilosti aplikace a uvedený účinek interakce mezi uvedeným příchozím dialogem transakční způsobilosti uvedenou souběžně probíhající telekomunikační službou a uvedeným odchozím dialogem transakční způsobilosti.
  3. 3. Způsob podle nároku 2, vyznačující se tím, že zahrnuje začlenění služby prvku abstraktní služby do nového prvku abstraktní služby přenosu transakční způsobilosti, který je realizován buď jako nové operace v části inteligentní síťové aplikace, nebo jako další doplňková služba na bázi části transakční způsobilosti aplikace na vlastní sadě datových elementů prvku abstraktní služby.
  4. 4. Způsob podle nároku 1, vyznačující se tím, že zahrnuje provedení v mezilehlém uzlu (106, 206), v odezvě na přijetí žádosti příchozího dialogu transakční způsobilosti, týkající se doplňkové služby na bázi části transakční způsobilosti aplikace, která má přidělené podsystémové číslo, a na základě analýzy identity požadované doplňkové služby na bázi části transakční způsobilosti aplikace, jak byla identifikována specifickým objektovým identifikátorem doplňkové služby, a adresové informace volajícího a volaného účastníka, která byla vyslána společně se žádostí, následujících kroků:
    i) spuštění funkce transparentního přenosu v případě buď, že objektový identifikátor není rozpoznán mezilehlým uzlem, nebo, že adresová informace volaného účastníka neadresuje účastníka připojeného k mezilehlému uzlu (106, 206), ii) iniciování procedury transakční způsobilosti přenosové linky, která zahrnuje uchování přijaté identity dialogu transakční způsobilosti a vyslání žádosti o překlad čísla prostřednictvím komunikace adresové informace volaného a volajícího účastníka a doplňkové služby prvku abstraktní služby přijatého dialogu transakční způsobilosti do souběžně probíhající telekomunikační služby, iii) analýzu přijaté žádosti a určení souběžně probíhající telekomunikační službou nové adresové informace volaného účastníka a účinku interakce s doplňkovou službou na bázi části transakční způsobilosti aplikace, jak byla identifikována prostřednictvím přijatého objektového identifikátoru, iv) provedení proceduiy transakční způsobilosti přenosové linky, které zahrnuje vytvoření odchozího dialogu transakční způsobilosti na bázi přijaté adresové informace volaného účastníka a doplňkové služby prvku abstraktní služby ze souběžně probíhající telekomunikační služby, a vytvoření přiřazení mezi identitou příchozího a odchozího dialogu transakční způsobilosti na bázi přijaté indikace pro zpracování pokračování dialogu transakční způsobilosti.
  5. 5. Způsob podle nároku 1, vyznačující se tím, že zahrnuje zajištění, pro krok odlišení zpracování a pokračování zřetězených dialogů, indikace prostřednictvím souběžně probíhající telekomunikační služby o tom, zda funkce transakční způsobilosti přenosové linky má použít řídicí funkci jednoho přiřazení pro vytvoření jednoduchého a jednoho přiřazení mezi příchozím a odchozím dialogem transakční způsobilosti, nebo
    -16CZ 297956 B6 řídicí funkci vícenásobného přiřazení pro vytvoření vícenásobného přiřazení s použitím dvou řídicích funkcí jednoho přiřazení mezi příchozím a odchozím dialogem transakční způsobilosti.
  6. 6. Způsob podle nároku 5, vyznačující se tím, že zahrnuje rozhodnutí o použití řídicí funkce jednoho přiřazení, když doplňková služba prvku abstraktní služby na bázi části transakční způsobilosti aplikace, použitá v odchozím dialogu, je shodná s doplňkovou službou prvku abstraktní služby na bázi části transakční způsobilosti aplikace, přijatou příchozím dialogem transakční způsobilosti, a rozhodnutí o použití řídicí funkce vícenásobného přiřazení, když doplňková služba prvku abstraktní služby na bázi části transakční způsobilosti aplikace, použitá v odchozím dialogu, není shodná s doplňkovou službou prvku abstraktní služby na bázi části transakční způsobilosti aplikace, přijatou příchozím dialogem transakční způsobilosti.
  7. 7. Způsob podle nároku 4, vyznačující se tím, že zahrnuje provedení kroků i) a ii) logickou entitou rozložení aplikace a první řídicí funkcí jednoho přiřazení, která přijímá dialog transakční způsobilosti a přenáší jej do uvedené logické entity rozložení aplikace pro další zpracování.
  8. 8. Způsob podle nároku 7, vyznačující se tím, že zahrnuje vytvoření uvedené nové transakční způsobilosti přenosové linky prostřednictvím logické entity rozložení aplikace s uspořádanou uvedenou první řídicí funkcí jednoho přiřazení pro vytvoření nového přiřazení žádostí o asistenci druhé řídicí funkce jednoho přiřazení přes řídicí funkci vícenásobného přiřazení.
  9. 9. Způsob podle nároku 7 nebo 8, vyznačující se tím, že zahrnuje provedení v kroku ii) dalších kroků v logické entitě rozložení aplikace:
    uchování identity příchozí transakce a adres globálního titulku řídicí části signalizačního spojení, vytvoření zprávy identifikující adresovanou službu a původce žádosti, zjištění, zda současný protokol, použitý pro komunikaci, podporuje přenosovou signalizaci transakční způsobilosti, a pokud podporuje začlenění příchozího bloku adres globálního titulku řídicí části signalizačního spojení, objektového identifikátoru a prvku abstraktní služby do operace žádosti o přenos a vyslání této operace do aplikace v mezilehlém uzlu, aby v něm byla zpracována pro vytvoření vhodné odezvy přenosu do logické entity rozložení aplikace, pokud nepodporuje vyslání vhodné operace pod současným protokolem do aplikace v mezilehlém uzlu, která v něm bude zpracována tak, aby vrátila novou vhodnou operaci pod současným protokolem do logické entity rozložení aplikace.
  10. 10. Způsob podle nároku 9, vyznačující se tím, že zahrnuje provedení v aplikaci, v odezvě na přijetí operace pod současným protokolem, kroků:
    identifikování adresované aplikace služby, provedení požadované akce nebo interakce a vytvoření nové adresy globálního titulku řídicí části signalizačního spojení, vyslání uvedené vhodné nové operace pod současným protokolem.
  11. 11. Způsob podle nároku 9, vyznačující se tím, že zahrnuje provádění v aplikaci, v odezvě na přijetí operace žádosti o přenos, kroků:
    rozbalení bloku adres globálního titulku řídicí části signalizačního spojení, objektového identifikátoru a prvku abstraktní služby,
    - 17CZ 297956 B6 identifikace aplikace adresované služby, provedení požadované akce nebo interakce a vytvoření nové adresy globálního titulku řídicí části signalizačního spojení, vyslání operace odezvy přenosu do logické entity rozložení aplikace, přičemž této operaci v případě vícenásobného přiřazení předchází vytvoření nového prvku abstraktní služby, indikace příslušného objektového identifikátoru a jejich začlenění do operace odezvy přenosu před vysláním.
  12. 12. Způsob podle nároku 10, vyznačující se tím, že zahrnuje provedení v logické entitě rozložení aplikace, v odezvě na přijetí v logické entitě rozložení aplikace operace pod současným protokolem, kroků:
    vytvoření identity odchozí transakce, uchování identity odchozí transakce a adres globálního titulku řídicí části signalizačního spojení, vytvoření nové TC-BEGIN z prvku abstraktní služby přijatého v operaci, přeložení adres globálního titulku řídicí části signalizačního spojení, vyslání TC-BEGIN do cílové vzdálené entity.
  13. 13. Způsob podle nároku 11, vyznačující se tím, že zahrnuje provedení v logické entitě rozložení aplikace, v odezvě na přijetí v logické entitě rozložení aplikace odezvy přenosu z aplikace, a v případě jednoho přiřazení, kroků:
    rozbalení přijatého bloku adres globálního titulku řídicí části signalizačního spojení, objektového identifikátoru a prvku abstraktní služby z operace odezvy přenosu, vytvoření identity odchozí transakce, uchování identity odchozí transakce a adres globálního titulku řídicí části signalizačního spojení, vytvoření nové TC-BEGIN z přijatého prvku abstraktní služby, přeložení adres globálního titulku řídicí části signalizačního spojení, vyslání TC-BEGIN do cílové vzdálené entity.
  14. 14. Způsob podle nároku 11, vyznačující se tím, že zahrnuje provedení v logické entitě rozložení aplikace, v odezvě na přijetí v logické entitě rozložení aplikace odezvy přenosu z aplikace, a v případě vícenásobného přiřazení, kroků:
    vytvoření linky k novému prvku abstraktní služby přes řídicí funkci vícenásobného přiřazení, uchování řídicí funkce vícenásobného přiřazení linky a adres globálního titulku řídicí části signalizačního spojení, vytvoření nové TC-BEGIN z přijatého prvku abstraktní služby a přeložení adres globálního titulku řídicí části signalizačního spojení, vyslání TC-BEGIN do cílové vzdálené entity.
  15. 15. Způsob podle kteréhokoliv z nároků 9 až 14, vyznačující se tím, že zahrnuje provedení, v mezilehlém uzlu (106, 206) pro pokračování vytvořené transakční způsobilosti přenosové linky, dokud není ukončena transakce dialogu transakční způsobilosti mezi výchozí a cílovou entitou, a v odezvě na přijetí v logické entitě rozložení aplikace jakékoliv základní funkce transakční způsobilosti s podsystémovým číslem SSN= „doplňková služba“, až na TCBEGIN, a v případě, že identita transakce v logické entitě rozložení aplikace neexistuje, kroku:
    ukončení dialogu transakční způsobilosti a vyslání zprávy do adresovaného prvku abstraktní služby, jak byl identifikován prostřednictvím objektového identifikátoru.
  16. 16. Způsob podle kteréhokoliv z nároků 9až 14, vyznačující se tím, že zahrnuje provedení, v mezilehlém uzlu (106, 206) pro pokračování vytvořené transakční způsobilosti
    -18CZ 297956 B6 přenosové linky, dokud není ukončena transakce dialogu transakční způsobilosti mezi výchozí a cílovou entitou, a v odezvě na přijetí v logické entitě rozložení aplikace jakékoliv základní funkce transakční způsobilosti s podsystémovým číslem SSN= „doplňková služba“, až na TCBEGIN, a v případě, že identita transakce v logické entitě rozložení aplikace existuje, přenos transakční způsobilosti bude vyslán přes řídicí funkci vícenásobného přiřazení a spuštění služby bylo vyžadováno, kroků:
    vyslání příchozího prvku abstraktní služby do aplikace pro vytvoření nového prvku abstraktní služby, přijetí nového prvku abstraktní služby z aplikace, přeložení operace transakční způsobilosti s identitou transakce přenosu a adresou, vyslání operace transakční způsobilosti přenosu do výchozí nebo cílové vzdálené entity.
  17. 17. Způsob podle kteréhokoliv z nároků 9 až 14, vyznačující se tím, že zahrnuje provedení, v mezilehlém uzlu (106, 206) pro pokračování vytvořené transakční způsobilosti přenosové linky, dokud není ukončena transakce dialogu transakční způsobilosti mezi výchozí a cílovou entitou, a v odezvě na přijetí v logické entitě rozložení aplikace jakékoliv základní funkce transakční způsobilosti s podsystémovým číslem SSN= „doplňková služba“, až na TCBEGIN, a v případě, že identita transakce v logické entitě rozložení aplikace existuje, přenos transakční způsobilosti bude vyslán přes řídicí funkci vícenásobného přiřazení a spuštění služby nebylo vyžadováno, kroků:
    přeložení operace transakční způsobilosti s identitou transakce přenosu a adresou, vyslání operace transakční způsobilosti přenosu do výchozí nebo cílové vzdálené entity.
  18. 18. Způsob podle kteréhokoliv z nároků 9 až 14, vyznačující se tím, že zahrnuje provedení, v mezilehlém uzlu (106, 206) pro pokračování vytvořené transakční způsobilosti přenosové linky, dokud není ukončena transakce dialogu transakční způsobilosti mezi výchozí a cílovou entitou, a v odezvě na přijetí v logické entitě rozložení aplikace jakékoliv základní funkce transakční způsobilosti s podsystémovým číslem SSN= „doplňková služba“, až na TCBEGIN, a v případě, že identita transakce v logické entitě rozložení aplikace existuje, ale přenos transakční způsobilosti nebude vyslán přes řídicí funkci vícenásobného přiřazení, kroků: přeložení operace transakční způsobilosti s identitou transakce přenosu a adresou, vyslání operace transakční způsobilosti přenosu do výchozí nebo cílové vzdálené entity.
CZ0384699A 1997-04-30 1998-04-17 Zpusob v telekomunikacní síti pro umoznení operátorovi síte zabránit selhání provozu sluzby CZ297956B6 (cs)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
SE9701642A SE512270C2 (sv) 1997-04-30 1997-04-30 Sätt och system för användning i ett telekommunikationsnät

Publications (2)

Publication Number Publication Date
CZ384699A3 CZ384699A3 (cs) 2000-09-13
CZ297956B6 true CZ297956B6 (cs) 2007-05-09

Family

ID=20406797

Family Applications (1)

Application Number Title Priority Date Filing Date
CZ0384699A CZ297956B6 (cs) 1997-04-30 1998-04-17 Zpusob v telekomunikacní síti pro umoznení operátorovi síte zabránit selhání provozu sluzby

Country Status (10)

Country Link
US (1) US6611584B1 (cs)
EP (1) EP0979573B1 (cs)
CN (1) CN1149821C (cs)
AU (1) AU746123B2 (cs)
BR (1) BR9809337A (cs)
CZ (1) CZ297956B6 (cs)
EE (1) EE04449B1 (cs)
NO (1) NO328936B1 (cs)
SE (1) SE512270C2 (cs)
WO (1) WO1998049819A1 (cs)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0991283A1 (de) * 1998-10-01 2000-04-05 Siemens Aktiengesellschaft Verfahren zur Behandlung von In-Calls bei IN-Dienstrufnummernportabilität
CN1174640C (zh) * 1999-02-25 2004-11-03 瑞士西门子有限公司 涉及到号码翻译的电信业务的方法
DE10028715B4 (de) * 2000-06-08 2005-08-11 Siemens Ag Verfahren zur Kommunikation zwischen Kommunikationsnetzen
US7554974B2 (en) * 2004-03-09 2009-06-30 Tekelec Systems and methods of performing stateful signaling transactions in a distributed processing environment
US7856094B2 (en) * 2005-03-21 2010-12-21 Tekelec Methods, systems, and computer program products for providing telecommunications services between a session initiation protocol (SIP) network and a signaling system 7 (SS7) network
US7760708B2 (en) 2005-07-08 2010-07-20 Tekelec Methods, systems, and computer program products for triggering SIP nodes to include SS7 routing information in response messages including information requested by SS7 nodes
US7623421B2 (en) * 2005-12-20 2009-11-24 Mediatek Inc. Data search system for searching a data sync pattern in optical disc and method thereof
US8050253B2 (en) * 2006-01-09 2011-11-01 Tekelec Methods, systems, and computer program products for decentralized processing of signaling messages in a multi-application processing environment
EP1874065B1 (en) * 2006-06-30 2010-12-29 Hewlett-Packard Development Company, L.P. Signalling system and method
CN101616027B (zh) * 2006-10-10 2012-07-04 华为技术有限公司 业务创建、执行、映射系统及方法
CN100536479C (zh) * 2006-10-10 2009-09-02 华为技术有限公司 业务创建系统及方法
US8059667B2 (en) * 2007-01-31 2011-11-15 Tekelec Methods, systems, and computer program products for applying multiple communications services to a call
EP2143230A1 (en) * 2007-04-20 2010-01-13 Tekelec Methods, systems, and computer program products for providing fault-tolerant service interaction and mediation function in a communications network
US9712341B2 (en) 2009-01-16 2017-07-18 Tekelec, Inc. Methods, systems, and computer readable media for providing E.164 number mapping (ENUM) translation at a bearer independent call control (BICC) and/or session intiation protocol (SIP) router
CN101867565A (zh) * 2010-04-13 2010-10-20 中兴通讯股份有限公司 一种移动宽带设备的通用驱动方法及驱动器
US11716772B1 (en) 2021-09-24 2023-08-01 T-Mobile Usa, Inc. Rapid prototyping of an internet of things device, such as a device for communicating with a wireless cellular network
US11729588B1 (en) 2021-09-30 2023-08-15 T-Mobile Usa, Inc. Stateless charging and message handling

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1994002993A1 (en) * 1992-07-17 1994-02-03 Massachusetts Institute Of Technology Recovered energy logic circuits
US5701301A (en) * 1993-06-28 1997-12-23 Bellsouth Corporation Mediation of open advanced intelligent network in SS7 protocol open access environment
CZ286163B6 (cs) * 1998-02-20 2000-01-12 Marek Ing. Hájek Způsob přenosu dat mezi prvním účastníkem a druhým účastníkem a/nebo Internetem a zařízení k provádění tohoto způsobu

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5572579A (en) * 1995-04-06 1996-11-05 Bell Communications Research, Inc. System and method for providing portable telephone number service
SE502733C2 (sv) * 1993-06-11 1995-12-18 Ellemtel Utvecklings Ab Sätt att undvika ej önskvärd interferens mellan tjänster i ett telekommunikationssystem
US5430719A (en) * 1993-06-28 1995-07-04 Bellsouth Corporation Mediation of open advanced intelligent network interface by shared execution environment
SE504405C2 (sv) 1995-11-10 1997-02-03 Telia Ab Förbättringar av eller avseende telekommunikationstjänster
CA2165856C (en) * 1995-12-21 2001-09-18 R. William Carkner Number portability with database query

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1994002993A1 (en) * 1992-07-17 1994-02-03 Massachusetts Institute Of Technology Recovered energy logic circuits
US5701301A (en) * 1993-06-28 1997-12-23 Bellsouth Corporation Mediation of open advanced intelligent network in SS7 protocol open access environment
CZ286163B6 (cs) * 1998-02-20 2000-01-12 Marek Ing. Hájek Způsob přenosu dat mezi prvním účastníkem a druhým účastníkem a/nebo Internetem a zařízení k provádění tohoto způsobu

Also Published As

Publication number Publication date
SE512270C2 (sv) 2000-02-21
NO328936B1 (no) 2010-06-21
EE9900513A (et) 2000-06-15
CZ384699A3 (cs) 2000-09-13
WO1998049819A1 (en) 1998-11-05
SE9701642L (sv) 1998-10-31
EP0979573A1 (en) 2000-02-16
CN1254466A (zh) 2000-05-24
CN1149821C (zh) 2004-05-12
AU746123B2 (en) 2002-04-18
NO995309L (no) 1999-12-30
EE04449B1 (et) 2005-02-15
BR9809337A (pt) 2000-07-04
NO995309D0 (no) 1999-10-29
AU7458498A (en) 1998-11-24
US6611584B1 (en) 2003-08-26
SE9701642D0 (sv) 1997-04-30
EP0979573B1 (en) 2015-10-14

Similar Documents

Publication Publication Date Title
US5732130A (en) System and method of providing enhanced subscriber services in a multi-node telecommunications network
US4924500A (en) Carrier independent network services
JP2801490B2 (ja) 交換機ネットワーク
EP0932984B1 (en) Telecommunications network with relocateability of subscriber number
US5850434A (en) Telecommunications network
JP3249249B2 (ja) 呼出設定法とデータ・ベース・システム
US6038309A (en) Apparatus and method for externally controlling processing of a service call
USH1921H (en) Generic wireless telecommunications system
USH1837H (en) Generic telecommunications system and associated call processing architecture
CZ297956B6 (cs) Zpusob v telekomunikacní síti pro umoznení operátorovi síte zabránit selhání provozu sluzby
US6560326B1 (en) Service brokering system for intelligent telecommunications network
US6792100B2 (en) Method and apparatus for sharing point codes in a network
US6002756A (en) Method and system for implementing intelligent telecommunication services utilizing self-sustaining, fault-tolerant object oriented architecture
US6717940B1 (en) Message transfer part level three alias point codes
US20010053218A1 (en) Transaction bridging/forwarding in signaling system of telecommunications network
US5917901A (en) Telecommunications system
US20030228012A1 (en) Method and apparatus for efficient use of voice trunks for accessing a service resource in the PSTN
KR100455878B1 (ko) 어플리케이션층데이터를포함하는신호를통신하는시스템및신호접속제어부분파라미터를변환하는시스템
US6826274B1 (en) Exchange control method
US20030161461A1 (en) Identifying communication channels between nodes
US20030147418A1 (en) Multiple dialogues on connection-oriented TCAP transaction
MXPA97003045A (en) System and method for providing improved subscriber services in a multine telecommunication network
MXPA98009609A (en) A system to convert an itinerary address within a telecommunication network
JP2001285483A (ja) インテリジェントネットワークシステム、及びその制御方法

Legal Events

Date Code Title Description
PD00 Pending as of 2000-06-30 in czech republic
MK4A Patent expired

Effective date: 20180417