CZ384699A3

CZ384699A3 - Způsob a systém pro zabránění selhání služby v telekomunikační síti

Info

Publication number: CZ384699A3
Application number: CZ19993846A
Authority: CZ
Inventors: Robert Khello; Leslie Graf; Rune Boman; Pieter Veenstra
Original assignee: Koninklijke Kpn N. V.
Priority date: 1997-04-30
Filing date: 1998-04-17
Publication date: 2000-09-13
Also published as: EP0979573B1; AU746123B2; BR9809337A; WO1998049819A1; US6611584B1; EE04449B1; EP0979573A1; EE9900513A; NO995309L; NO328936B1; CN1254466A; CZ297956B6; AU7458498A; SE512270C2; NO995309D0; SE9701642L; SE9701642D0; CN1149821C

Description

Oblast techniky

Předkládaný vynález se týká způsobu a systému pro 5 použití v telekomunikační síti, ve kterém účastník, spojený s odchozím uzlem místní ústředny, požadoval aktivaci doplňkové služby umístěné v aplikaci uvedeného odchozího uzlu.

Doplňková služba využívá část transakční způsobilosti aplikace TCAP a odpovídající prvek abstraktní služby ASE pro vytvoření dvoubodového dialogu transakční způsobilosti TC s odpovídajícím doplňkovým zařízením v aplikaci cílového uzlu místní ústředny, ke kterému je adresovaný vzdálený účastník připojen. TC dialog transakční způsobilosti ukončuje žádost o interferenční telekomunikační službu umístěnou v aplikaci 15 mezilehlého uzlu.

Dosavadní stav techniky

Je používána telekomunikační síť, 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 25 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,

5Q 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é • · • 0

0 • « 00 00 je adresováno přeloženým číslem. V závislosti na požadované aplikaci může být překlad čisla opakován, dokud volání není ukončeno směrem k uživateli, to jest účastníkovi, v konečné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ůsobilostí 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 signalízač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í • · • · · fc·· fc • ·· · · fc· · • · ·« · · fcfc 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.

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ě 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žiti tak zvané funkce přenositelnosti čísla, přičemž SCCP GT informace adresy způsobí ukončení dialogu v uzlu, který nemá jakékoliv znalostí 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 konečnými entitami a může trvat dlouhou časovou periodu. Tak například služba dokončení volání s obsazeným účastníkem

5 (CCBS) vytváří dialog mezi výchozími a konečný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 konečnými entitami ve stejné vrstvě, je potřebné

2q předávat výsledné TC dialogy v mezilehlých interferujících entitách. Tak každý interferující mezilehlý uzel, to jest • to β to to · to ζ «tototo · ·· «to to* 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é interferují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árodni ú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í 5 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

4*·

4

4*4 centralizovány v síti uvnitř SCP (obslužný řídící bod) fyzické 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 INAP, 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 s interferenční 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.

Podstata 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 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ě.

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

9 999 9999

9 999 9 9 9 9 9 ·

9 9999 9999 ··· * ·· ·· ·· ·· 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 místní ústředny a cílovým uzlem 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 bud' jako nové operace uvnitř INAP nebo jako další doplňková služba na bázi TCAP, která mé vlastní sadu ASE datových prvků.

Předkládaným vynálezem je tedy způsob a systém v telekomunikační síti pro umožnění síťovému operátorovi zabránit v selhání činnosti služby, když dochází k interakci mezi doplňkovou službou na bázi dvoubodové TCAP a • ftft · ft · • ft ftft ft ftft « • ftft * • ftft « ftft ftft interferující telekomunikační službou. Přesněji se jedná o případ, ve kterém účastník spojený s výchozím uzlem místní ústředny požadoval aktivaci doplňkové služby, kterou je doplňková služba na bázi TCAP, umístěné v aplikací uvedeného výchozího uzlu. Doplňková služba využívá část transakční způsobilosti aplikace TCAP a odpovídající prvek abstraktní služby ASE pro vytvoření dvoubodového TC dialogu transakční způsobilosti, který má transakční ID, s odpovídající doplňkovou službou v aplikaci cílového uzlu místní ústředny, se kterou je spojen adresovaný vzdálený účastník. TC dialog ukončuje požadavek na telekomunikační službu, kterou je uvedená interferující služba, umístěnou v aplikaci mezilehlého uzlu.

Předkládaný vynález zahrnuje prostředky a kroky pro vytvoření přenosové linky mezi příchozím TC dialogem a odchozím TC dialogem v mezilehlém uzlu pro vytvoření řetězce dvoubodových TC dialogů mezi výchozím uzlem místní ústředny a cílovým uzlem místní ústředny. Je použita způsobilost transparentního přenosu, která je nezávislá na využití o η doplňkových služeb ASE na bázi TCAP v mezilehlých uzlech. Zpracováni a pokračování zřetězených dialogů je odlišováno na bázi účinku interakce způsobené uvedenou interferující telekomunikační službou.

Transparentní přenosová způsobilost komunikuje s doplňkovými službami ASE na bázi TCAP a uvedený účinek interakce mezi uvedeným příchozím TC dialogem, uvedenou interferující telekomunikační službou a uvedeným odchozím TC dialogem.

Služba ASE je začleněna v nové TC přenášené ASE, která je realizována buď jako nové operace uvnitř části • · • · φ Φ fe φ • · · * · * • · φ « φ φ φ ·» φβ «φ inteligentní síťové aplikace ΙΝΑΡ nebo jako další doplňková služba na bázi TCAP, která má vlastní sadu ASE datových prvků.

Kroky a prostředky jsou zajištěny pro provádění v mezilehlém uzlu, po příjmu žádosti příchozího dialogu, týkající se doplňkové služby na bázi TCAP, která má přidělené podsystémové Číslo SN, a založeny na analýze identity požadované doplňkové služby na bázi TCAP, jak je identifikována prostřednictvím specifického objektového identifikátoru OID doplňkové služby, adresové informace volajícího a volaného účastníka, vysílané společně s žádostí, a množstvím podstatných vzájemně navazujících opatření.

První z těchto opatření zahrnuje spouštění transparentní přenosové způsobilosti v případě, že buď není 15 rozpoznáno OID mezilehlým uzlem nebo adresová informace volaného účastníka neadresuje účastníka připojeného k mezilehlému uzlu.

Druhé opatření inicializuje proceduru TC přenosové 2o linky zahrnující uchování ID přijatého TC dialogu a vyslání žádosti o množství překladů prostřednictvím komunikace adresové informace volaného a volajícího účastníka a doplňkové služby ASE přijatého TC dialogu do interferující telekomunikační služby.

Třetí opatření zahrnuje analýzu přijaté žádosti a určení interferující telekomunikační službou nové adresové informace volaného účastníka a účinku interakce s doplňkovou službou na bázi TCAP, jak je identifikována přijatým OID.

Ve čtvrtém opatření zahrnuje procedura TC přenosové linky vytvoření odchozího TC dialogu na bázi přijaté adresové

9 9 9 9 9 • 9 9 9 « 9 9» *

99 9 9 ·· 9

49 99 99 ·♦· 9 informace volaného účastníka a doplňkové služby ASE z interferující telekomunikační služby. Je vytvořeno přiřazení mezi ID příchozího a odchozího TC dialogu na bázi přijaté indikace pro zpracování pokračování TC dialogu.

Pro krok odlišení zpracování a pokračování zřetězených dialogů, je zajištěna indikace prostřednictvím interferující telekomunikační služby o tom, zda by způsobilost TC přenosové linky měla použít řídící funkci jednoho přiřazení SAFC pro vytvoření jednoduchého a jednoho přiřazení mezi příchozím a odchozím TC dialogem, nebo řídící funkci vícenásobného přiřazení pro vytvoření vícenásobného přiřazení s použitím dvou SAFC mezi příchozím a odchozím TC dialogem.

Použití SACF přiřazení je indikováno, když doplňková služba ASE na bázi TCAP, použitá v odchozím TC dialogu, je shodná s doplňkovou službou ASE na bázi TCAP, přijatou příchozím TC dialogem. Použití MACF přiřazení je indikováno, když doplňková služba A.SE na bá2í TCAF, použitá v odchozím TC dialogu, není shodná s doplňkovou službou ASE na bázi TCAP, přijatou příchozím TC dialogem.

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.l 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ž

2Q 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é aplikaci 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 podsystemoveho čí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 ΑΞΕ.

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 interferují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 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 mezí 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 specifikovány pasivní režim přiřazení a aktivní režim přiřazení, jak bude podrobněji popsáno níže.

* «fcfcfc • · · fc · · fc · · · « • v fcfc ·· • · ··· • fc

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í 1 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, zda je 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,

0 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 OLE 102/202, cílovou místní ústřednu TLE 25

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 30 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í línky 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živazele 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.

» - 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

OLE 102/202 respektive TLE 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ř OLE 102/202; 130/230 a 132/232 uvnitř mezilehlého uzlu 106/206; a 124/224 a 128/228 uvnitř TLE ··· · • © · · © « © · • ♦ © ♦ ♦ · © · « • © · © © © © ·© ©· ·· «©

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, například 102/202, 102/204 nebo 106/206, může rovněž vyhovovat inteligentní síťové architektuře zahrnující obslužný přepojovací bod (SSP) a obslužný řídící bod (SCP), jak je popsáno v ITU-T doporučeních, série Q.1200. Možná úprava takové architektury na OLE 102/202 nebo TLE 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).

V OLE 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 102/202 a 104/204 na stejné úrovní. 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 SACE 114/214, TCAP 12/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 »4 · · » * » • 4 · · · 4 4 4 « 4» 4 « 44 4 • 4 44 «4 44 • 4 • » ♦ ·· ·

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, zda je požadován pasivní nebo aktivní režim TC přenosové linky. Komunikace mezí 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.

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 φφφ φ * V · w » w φ φφφ φ φ φ « φ φ • φφφφ φφφφ φ φφ φφ φφ ®· 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 TLE 104/204 a pro získání dvoubodového přiřazení s OLE 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 OID (objektový identifikátor), SSN a čísla volaného účastníka z aplikace pro zřetězení aplikace s TLE 104/204 prostřednictvím vyslání žádosti, to jest základní funkce TC-BEGIN, skrz SACF 114/214,

TCAP 112/212, SCCP 110/210 a MTP 108/208. Tato žádost je příslušně-vyslána do TLE 104/204 na fyzické lince 140/240.

V TLE 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 OLE 102/202 a TLE 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 OLE 102/202 a TLE 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řazeni 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.

a · 0 0 » » w » « » 000 » 0 0 0 0 0 « 0 0000 0000

0»· 0 00 ·· *· ··

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á
:	:		:

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áni 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 • 44 · 4 4

4 4 4 «

44 44

444 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á rozhodně 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í	SCCP
OID	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 ΑΞΕ. 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 OLE 102 je předána do adresované služby ΑΞΕ 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.

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 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á • * to to toto 1 • toto· to to· i • to «· toto ·· 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 operací 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 • · » » > » » • « 0 · 0 ······ • · 0 0 0 0 0 0 0 0

000 0 »0 00 00 00 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 ¹⁰ OLE 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řen nový 15

TC-BEGIN buď z ASE přijaté v INAP operací v kroku 402 nebo z ASE 124 přijaté od výchozí uzlové OLE 102. SCCP GT adresy jsou překládány (kompilovány) z přijaté SCCP volané adresy, srovnej obr. 8. V kroku 420 je TC-BEGIN vyslán do cílové vzdálené entity, to jest do TLE 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 25 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 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.

9

9 9 • 9 • · ·

Φ

99 99 99

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 TC-P-ABORT, do výchozí vzdálené entity, to jest do OLE 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řen 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án do cílové vzdálené entity, to jest TLE 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 202 respektive 204.

5

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 ftft * ftft ft • · · « ftft · ftft ftft • ft • ft ft «

ftft 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 22Q 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 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.

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 318, 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

9 9 ·· «

9 9 9 · » • ·· ·· · · ·· operace žádosti o přenos (srovnej obr. 8) a příznak stavu dotazu jev kroku 708 nastaven na pravdivý (TRUE).

V obou případech proces pokračuje, bud’ z kroku 702 nebo z kroku 708, krokem 710, ve kterém je proveden pokus o 5 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 a je 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 baleny do operace odezva přenosu.

2g Pokud je odpověď v kroku 716 ne, pak v kroku 724 je vhodná INAP 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ází 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)}

-- typy operací

RelayRequest ::= Operation

Parameter Sequence { sccpCalledAddress sccpCallingAddress

Service Gbjectld adresa, adresa doplňková, objektový identifikátor služby - doplňkový, 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 {

AsePackage single Association implicitně bcoleova TRUE,

	triggeringRequested		implicitně booleova EALSE
	sccpCalledAddress		adresa,
	sccpCallingAddress	[1]	adresa doplňková,
5	Service Objectld	[2]	objektový identifikátor služby - doplňkový,
	AsePackage	[3]	blok ASE - doplňkový, .. . }
10			— 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 2Q (1..maxlengthofaddressfield)) — adresa je kódována podle popisu v ITU-T doporučení Q.713

ServiceObjectld ::= OBJECT IDENTIFIER

AsePackage CHARACTER STRING (SIZE (1..maxlengthofasedata))

-- End of Relay-Protocol·.

Operace RelayRequest přenáší službu ASE vyslanou z

OLE 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 v OLE 120/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 TLE 104/204 . Booleovy proměnné singleAssocíation 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 v OLE 106/206.

Claims

PATENTOVÉ NÁROKY

1. Způsob v telekomunikační síti, ve které účastník připojený k výchozímu uzlu místní ústředny požadoval aktivaci doplňkové služby umístěné v 5 aplikaci uvedeného výchozího uzlu, přičemž uvedená doplňková služba využívá část transakční způsobilosti aplikace TCAP a odpovídající prvek abstraktní služby ASE pro vytvoření dvoubodového TC dialogu transakční způsobilosti, mající ID transakce, s odpovídající doplňkovou službou v aplikaci

10 . .

cílového uzlu místní ústředny, se kterým je spojen adresovaný vzdálený účastník, přičemž uvedený TC dialog ukončuje žádost o interferují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é TCAP a uvedenou interferující telekomunikační službou, vyznačující se tím, že zahrnuje následující kroky:

a) vytvoření přenosové linky mezi příchozím TC dialogem a odchozím TC dialogem v mezilehlém uzlu pro vytvoření řetězce dvoubodových TC dialogů mezi výchozím uzlem místní ústředny a cílovým uzlem 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 ASE na bázi TCAP v mezilehlých uzlech,

b) odlišení zpracování a okračování zřetězených dialogů na bázi účinku interakce, způsobeného uvedenou interferující telekomunikační službou.

• fc * • fc «fcfcfc fc fcfcfc fcfc · fc fcfcfc· fcfcfc· • fcfc fcfc fcfc fcfc
2. Způsob podle nároku 1, vyznačující se tím, že uvedená funkce transparentního přenosu komunikuje doplňkovou službu ASE na bázi TCAP a uvedený účinek interakce mezi uvedeným příchozím TC dialogem, uvedenou interferující telekomunikační

5 službou a uvedeným odchozím TC dialogem.
3. Způsob podle nároku 2, vyznačující se tím, že zahrnuje začlenění služby ASE do nové ASE TC přenosu, která je realizována buď jako nové operace v části inteligentní síťové aplikace INAP nebo jako další doplňková služba na bázi TCAP na vlastí sadě prvků ASE dat.
4. Způsob podle nároku 1, vyznačující se tím, že zahrnuje provedení v mezilehlém uzlu, v odezvě na přijetí žádosti příchozího TC dialogu, týkající se doplňkové služby na bázi TCAP, která má přidělené podsystémové číslo SSN, a na základě analýzy identity požadované doplňkové služby na bázi TCAP, jak byla identifikována specifickým objektovým identifikátorem OID 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 OID není rozpoznáno 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 TC přenosové linky, která zahrnuje uchování přijatého ID TC dialogu 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 ASE přijatého TC dialogu do interferující telekomunikační služby, iii) analýzu přijaté žádosti a určení interferující telekomunikační službou nové adresové informace volaného

4 · 4 • 4 4 · 4 4 » 4 4 4 4 4 >

» 4 4 4 4 4 4

44 «· 4· « účastníka a účinku interakce s doplňkovou službou na bázi TCAP, jak byla identifikována prostřednictvím přijatého OID, iv) provedení procedury TC přenosové linky, které zahrnuje vytvoření odchozího TC dialogu na bázi přijaté adresové informace volaného účastníka a doplňkové služby ASE z interferující telekomunikační služby, a vytvoření přiřazení mezi ID příchozího a odchozího TC dialogu na bázi přijaté indikace pro zpracování pokračování TC dialogu.
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 interferující telekomunikační služby o tom, zda funkce TC přenosové linky má použít řídící funkci jednoho přiřazení SACF pro vytvoření jednoduchého a jednoho přiřazení mezi příchozím a odchozím TC dialogem, nebo řídící funkci vícenásobného přiřazení MACF pro vytvoření vícenásobného přiřazení s použitím dvou SACF mezi příchozím a odchozím TC dialogem.
6. Způsob podle nároku 5, vyznačující se tím, že zahrnuje rozhodnutí o použití SACF přiřazení, když doplňková služba ASE na bázi TCAP, použitá v odchozím dialogu, je shodná s doplňkovou službou ASE na bázi TCAP, přijatou příchozím TC dialogem, a rozhodnutí o použití MACF přiřazení, když doplňková služba ASE na bázi TCAP, použitá v odchozím dialogu, není shodná s doplňkovou službou ASE na bázi TCAP, přijatou příchozím TC dialogem.

• · » · φ φφφφ • · · φ » a · · φ · φ • φ · · 1 φ φφφφ

32 * ........
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 ADLE a první SACF, která přijímá TC dialog a přenáší jej do uvedeného ADLE pro další zpracování.
8. Způsob podle nároku 7, vyznačující se tím, že zahrnuje vytvoření uvedené nové TC přenosové linky prostřednictvím ADLE entity s uspořádaným uvedeným prvním SACF pro vytvoření nového přiřazení žádostí o asistenci druhého SACF přes MACF.
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 ADLE:

uchování ID příchozí transakce a adres globálního titulku GT řídící čisti signalizačního spojení SCCP, 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 TC přenosovou signalizaci, a pokud podporuje balení příchozího bloku SCCP GT adres, OID a ASE 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 ADLE, 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 ADLE.
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ů:

* 0 · * 0 0 0 0

0 »00 « · » 0 0 ·

0 0·»» 000· • 00 identifikování adresované aplikace služby, provedení požadované akce nebo interakce a vytvoření nové SCCP GT adresy, vyslání vhodné nové operace pod současným protokolem.
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 SCCP GT adres, OID a ASE, identifikace aplikace adresované služby, provedení požadované akce nebo interakce a vytvoření nové SCCP GT adresy, vyslání operace odezvy přenosu do ADLE, přičemž této operaci v případě vícenásobného přiřazení .předchází vytvoření nové ASE, indikace příslušného OID a jejich balení do operace odezvy přenosu před vysláním.
12. Způsob podle nároku 10, vyznačující se tím, že zahrnuje provedení v ADLE, v odezvě na přijetí v ADLE operace pod současným protokolem, kroků:

vytvoření ID odchozí transakce, uchování ID odchozí transakce a SCCP GT adres, vytvoření nového TC-BEGIN z ASE přijaté v operaci, přeložení SCCP GT adres, vyslání TC-BEGIN do cílové vzdálené entity.
13. Způsob podle nároku 11, vyznačující se tím, že zahrnuje provedení v ADLE, v odezvě na přijetí v ADLE odezvy přenosu z aplikace, a v případě jednoho přiřazení, kroků:

rozbalení přijatého bloku SCCP GT adres, OID a ASE z operace odezvy přenosu, vytvoření ID odchozí transakce, • * *

I · · 1 ·· ·· uchování ID odchozí transakce a SCCP GT adres, vytvoření nového TC-BEGIN z přijaté ASE, přeložení SCCP GT adres, vyslání TC-BEGIN do cílové vzdálené entity.
14. Způsob podle nároku 11, vyznačující se tím, že zahrnuje provedení v ADLE, v odezvě na přijetí v ADLE odezvy přenosu z aplikace, a v případě vícenásobného přiřazení, kroků:

vytvoření linky k nové ASE přes MACF, uchování MACF linky a SCCP GT adres, vytvoření nového TC-BEGIN z přijaté ASE a přeložení

SCCP GT adres, vyslání TC-BEGIN do cílové vzdálené entity.
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 pro pokračování vytvořené TC přenosové linky, dokud není ukončena transakce TC dialogu mezi výchozí a cílovou entitou, a v odezvě na přijetí v ADLE jakékoliv základní TC funkce s SSN=doplňková služba, až na TC-BEGIN, a v případě, že ID transakce v ADLE neexistuje, kroku:

ukončení TC dialogu a vyslání zprávy do adresované ASE, jak byla identifikována prostřednictvím OID.
16. Způsob podle kteréhokoliv z nároků 9 až 14, vyznačující se tím, že zahrnuje provedení, v mezilehlém uzlu pro pokračování vytvořené TC přenosové linky, dokud není ukončena transakce TC dialogu mezi výchozí a cílovou entitou, a v odezvě na přijetí v ADLE jakékoliv základní TC funkce s SSN=doplňková služba, až na TC-BEGIN, a v případě, že ID transakce v ADLE existuje, TC přenos bude vyslán přes MACF a spuštění služby bylo vyžadováno, kroků:

Λ « *

« 9 • 9 9 9 9 9 vyslání příchozí ASE do aplikace pro vytvoření nové

ASE, přijetí nové ASE z aplikace, přeložení TC operace s ID transakcí přenosu a adresou, vyslání TC operace přenosu do výchozí nebo cílové vzdálené entity.
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 pro pokračování vytvořené TC přenosové linky, dokud není ukončena transakce TC dialogu mezi výchozí a cílovou entitou, a v odezvě na přijetí v ADLE jakékoliv základní TC funkce s SSN=doplňková služba, až na TC-BEGIN, a v případě, že ID transakce v ADLE existuje, TC přenos bude vyslán přes MACF a spuštění služby nebylo vyžadováno, kroků:

přeložení TC operace s ID transakcí přenosu a adresou, vyslání TC operace přenosu do výchozí nebo cílové vzdálené entity.
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 pro pokračování vytvořené TC přenosové linky, dokud není ukončena transakce TC dialogu mezi výchozí a cílovou entitou, a v odezvě na přijetí v ADLE jakékoliv základní TC funkce s SSN=doplňková služba, až na TC-BEGIN, a v případě, že ID transakce v ADLE existuje, ale TC přenos nebude vyslán přes MACE, kroků:

přeložení TC operace s ID transakcí přenosu a adresou, vyslání TC operace přenosu do výchozí nebo cílové vzdálené entity.

• · · · 444¼

4 ♦ lil 191919

1 1 1119 lili ··· · ·· *4 ·· ·
19. Systém v telekomunikační síti, ve které účastník připojený k výchozímu uzlu 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á

5 služba využívá část transakční způsobilosti aplikace TCAP a odpovídající prvek abstraktní služby ASE pro vytvoření dvoubodového TC dialogu transakční způsobilosti, mající ID transakce, s odpovídající doplňkovou službou v aplikaci cílového uzlu místní ústředny, se kterým je spojen adresovaný

10 vzdálený účastník, přičemž uvedený TC dialog ukončuje žádost o interferují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

15 službou na bázi dvoubodové TCAP a uvedenou interferující telekomunikační službou, vyznačující se tím, že zahrnuje:

a) prostředek pro vytvoření přenosové linky mezi příchozím TC dialogem a odchozím TC dialogem v mezilehlém
20 uzlu pro vytvoření řetězce dvoubodových TC dialogů mezi výchozím uzlem místní ústředny a cílovým uzleni 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 ASE na bázi TCAP v mezilehlých uzlech,

25 b) prostředek pro odlišení zpracování a okračování zřetězených dialogů na bázi účinku interakce, způsobeného uvedenou interferující telekomunikační službou.

Φ Φ · · · « * · • ΦΦ φ ·♦ * Φ * Φ I • * · φ φ φ • * φφφφ ·· ·· φφ

20. Systém podle nároku 19, vyznačující se tím, že uvedená funkce transparentního přenosu komunikuje doplňkovou službu ASE na bázi TCAP a uvedený účinek interakce mezi uvedeným příchozím TC dialogem, uvedenou interferující telekomunikační

5 službou a uvedeným odchozím TC dialogem.
21. Systém podle nároku 20, vyznačující se tím, že zahrnuje prostředek pro začlenění služby ASE do nové ASE TC přenosu, která je realizována buď jako nové operace v části inteligentní síťové aplikace INAP nebo jako další doplňková služba na bázi TCAP na vlasti sadě prvku ASE dat.
22. Systém podle nároku 19, vyznačující se tím, že zahrnuje v mezilehlém uzlu, v odezvě na přijetí žádosti příchozího TC dialogu, týkající se doplňkové služby na bázi j_5 TCAP, která má přidělené podsystémové číslo SSN, a na základě analýzy identity požadované doplňkové služby na bázi TCAP, jak byla identifikována specifickým objektovým identifikátorem OID doplňkové služby, a adresové informace volajícího a volaného účastníka, která byla vyslána společně

20 se žádostí:

i) prostředek pro spuštění funkce transparentního přenosu v případě buď, že OID není rozpoznáno mezilehlým uzlem, nebo, že adresová informace volaného účastníka neadresuje účastníka připojeného k mezilehlému uzlu,

25 ii) prostředek pro iniciování procedury TC přenosové linky, která zahrnuje uchování přijatého ID TC dialogu a vyslání žádostí o překlad čísla prostřednictvím komunikace adresové informace volaného a volajícího účastníka a doplňkové služby ASE přijatého TC dialogu do interferující

30 telekomunikační služby, iii) prostředek pro analýzu přijaté žádosti a určení b

« * • · * · • » interferující telekomunikační službou nové adresové informace volaného účastníka a účinku interakce s doplňkovou službou na bázi TCAP, jak byla identifikována prostřednictvím přijatého OID, ív) prostředek pro provedení procedury TC přenosové linky, které zahrnuje vytvoření odchozího TC dialogu na bázi přijaté adresové informace volaného účastníka a doplňkové služby ASE z interferující telekomunikační služby, a vytvoření přiřazení mezi ID příchozího a odchozího TC dialogu na bázi přijaté indikace pro zpracování pokračování TC dialogu.
23. Systém podle nároku 19, vyznačující se tím, že zahrnuje prostředek pro zajištění, pro krok odlišení zpracování a pokračování zřetězených dialogů, indikace prostřednictvím interferující telekomunikační služby o tom, zda funkce TC přenosové linky má použít řídící funkci jednoho přiřazení SACE pro vytvoření jednoduchého a jednoho přiřazení mezi příchozím a odchozím TC dialogem, nebo řídící funkci vícenásobného přiřazení MACF pro vytvoření vícenásobného přiřazení s použitím dvou SACF mezi příchozím a odchozím TC dialogem.
24. Systém podle nároku 23, vyznačující se tím, že zahrnuje prostředek pro rozhodnutí o použití SACF přiřazení, když doplňková služba ASE na bázi TCAP, použitá v odchozím dialogu, je shodná s doplňkovou službou ASE na bázi TCAP, přijatou příchozím TC dialogem, a pro rozhodnutí o použití MACF přiřazení, když doplňková služba ASE na bázi TCAP, použitá v odchozím dialogu, není shodná s doplňkovou službou ASE na bázi TCAP, přijatou příchozím TC dialogem.

• ·* · • * 9 · · · fc • · · · · · t · fr • · · · 9 9 9 ·

99 99 99 ··
25. Systém podle kteréhokoliv z nároků 22 až 24, vyznačující se tím, že zahrnuje prostředek pro provedení kroků i) a ii) logickou entitou rozložení aplikace ADLE a první SACE, která přijímá TC dialog a přenáší jej do uvedeného ADLE pro další zpracování.
26. Systém podle nároku 25, vyznačující se tím, že zahrnuje prostředek pro vytvoření uvedené nové TC přenosové linky prostřednictvím ADLE entity s uspořádaným uvedeným prvním SACE pro vytvoření nového přiřazení žádostí o asistenci druhého SACF přes MACF.
27. Systém podle nároku 25 nebo 26, vyznačující se tím, že zahrnuje v ADLE:

prostředek pro uchování ID příchozí transakce a adres globálního titulku GT řídící čisti signalizačního spojení SCCP, prostředek pro vytvoření zprávy identifikující adresovanou službu a původce žádosti, prostředek pro zjištění, zda současný protokol, použitý pro komunikaci, podporuje TC přenosovou signalizaci, a pokud podporuje prostředek pro balení příchozího bloku SCCP GT adres, OXD a ASE 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 ADLE, pokud nepodporuje prostředek pro 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 ADLE.

♦ ·· · • · · · * t » fc • · · · · » »· « • · · · ···* · ·· ·· ©·
28. Systém podle nároku 27, vyznačující se tím, že zahrnuje v aplikaci, v odezvě na přijetí operace pod současným protokolem:

prostředek pro identifikování adresované aplikace 5 služby, prostředek pro provedení požadované akce nebo interakce a vytvoření nové SCCP GT adresy, prostředek pro vyslání vhodné nové operace pod současným protokolem.
29. Systém podle nároku 27, vyznačující se tím, že zahrnuje v aplikaci, v odezvě na přijetí operace žádosti o přenos:

prostředek pro rozbalení bloku SCCP GT adres, OID a

ASE, prostředek pro identifikaci aplikace adresované služby, 5 prostředek pro provedeni požadované akce nebo interakce a vytvoření nové SCCP GT adresy, prostředek pro vyslání operace odezvy přenosu do ADLE, přičemž této operaci v případě vícenásobného přiřazení předchází vytvoření nové ASE, indikace příslušného OID a jejich balení do operace odezvy přenosu před vysláním.
30. Systém podle nároku 28, vyznačující se tím, že zahrnuje v ADLE, v odezvě na přijetí v ADLE operace pod současným protokolem:

prostředek pro vytvoření ID odchozí transakce, prostředek pro uchování ID odchozí transakce a SCCP GT adres, prostředek pro vytvoření nového TC-BEGIN z ASE přijaté v operaci, prostředek pro přeložení SCCP GT adres, »»» • »·· «·*♦·· • · · · · · · · »

9 · 99 ·· 99 prostředek pro vyslání TC-BEGIN do cílové vzdálené entity.
31. Systém podle nároku 29, vyznačující se tím, že zahrnuje v ADLE, v odezvě na přijetí v ADLE odezvy přenosu z aplikace, a v případě jednoho přiřazení:

prostředek pro rozbalení přijatého bloku SCCP GT adres, OID a ASE z operace odezvy přenosu, prostředek pro vytvoření ID odchozí transakce, prostředek pro uchování ID odchozí transakce a SCCP GT adres, prostředek pro vytvoření nového TC-BEGIN z přijaté ASE, prostředek pro přeložení SCCP GT adres, prostředek pro vyslání TC-BEGIN do cílové vzdálené entity.
32. Systém podle nároku 29, vyznačující se tím, že zahrnuje v ADLE, v odezvě na přijetí v ADLE odezvy přenosu z aplikace, a v případě vícenásobného přiřazení:

prostředek pro vytvoření linky k nové ASE přes MACF,

20 prostředek pro uchování MACF linky a SCCP GT adres, prostředek pro vytvoření nového TC-BEGIN z přijaté ASE a přeložení SCCP GT adres, prostředek pro vyslání TC-BEGIN do cílové vzdálené entity.
33. Systém podle kteréhokoliv z nároků 27 až 32, vyznačující se tím, že zahrnuje, v mezilehlém uzlu pro pokračování vytvořené TC přenosové linky, dokud není ukončena transakce TC dialogu mezi výchozí a cílovou entitou, a v odezvě na přijetí v ADLE jakékoliv základní TC funkce s SSN=doplňková služba, až na TC-BEGIN, a v případě, že ID • to to to * • · to to to * • · to·#· *·· · v* to to · to ·<

• *· transakce v ADLE neexistuje:

prostředek pro ukončení TC dialogu a vyslání zprávy do adresované ASE, jak byla identifikována prostřednictvím OID.
34. Systém podle kteréhokoliv z nároků 27 až 32, vyznačující se tím, ze zahrnuje, v mezilehlém uzlu pro pokračování vytvořené TC přenosové línky, dokud není ukončena transakce TC dialogu mezi výchozí a cílovou entitou, a v odezvě na přijetí v ADLE jakékoliv základní TC funkce s SSN=doplňková služba, až na TC-BEGIN, a v případě, že ID transakce v ADLE existuje, TC přenos bude vyslán pres MACE a spuštění služby bylo vyžadováno:

prostředek pro vyslání příchozí ASE do aplikace pro vytvoření nové ASE, prostředek pro přijetí nové ASE z aplikace, prostředek pro přeloženi TC operace s ID transakcí přenosu a adresou, prostředek pro vyslání TC operace přenosu do výchozí nebo cílové vzdálené entity.

2Q
35. Systém podle kteréhokoliv z nároků 27 až 32, vyznačující se tím, že zahrnuje, v mezilehlém uzlu pro pokračování vytvořené TC přenosové linky, dokud není ukončena transakce TC dialogu mezi výchozí a cílovou entitou, a v odezvě na přijetí v ADLE jakékoliv základní TC funkce s SSN=doplňková služba, až na TC-BEGIN, a v případě, že ID transakce v ADLE existuje, TC přenos bude vyslán přes MACF a spuštění služby nebylo vyžadováno:

prostředek pro přeložení TC operace s ID transakcí přenosu a adresou, prostředek pro vyslání TC operace přenosu do výchozí nebo cílové vzdálené entity.

• * » · · « * « «

4 ·« 4 4444 • 4 4 ·44 44 4 4 44 4 4 44 4

44 »4 44 44
36. Systém podle kteréhokoliv z nároků 27 až 32, vyznačující se tím, že zahrnuje, v mezilehlém uzlu pro pokračování vytvořené TC přenosové linky, dokud není ukončena transakce TC dialogu mezi výchozí a cílovou entitou, a v

5 odezvě na přijetí v ADLE jakékoliv základní TC funkce s

SSN=doplňková služba, až na TC-BEGIN, a v případě, že ID transakce v ADLE existuje, ale TC přenos nebude vyslán přes MACF:

prostředek pro přeložení TC operace s ID transakcí 10 přenosu a adresou, prostředek pro vyslání TC operace přenosu do výchozí nebo cílové vzdálené entity.

Zastupuje :