Mechanizmus na vyžiadanie opravy bod po bode pre systémy schopné prenosu z bodu do viacerých bodov

Číslo patentu: E 4405

Dátum: 27.07.2005

Autori: Walsh Rod, Vedantham Ramakrishna, Leon David, Curcio Igor

Je ešte 14 strán.

Pozerať všetko strany alebo stiahnuť PDF súbor.

Text

Pozerať všetko

0001 Tento vynález sa týka použitia spôsobu systému vysielača sieťového prvku prijímača a softvéru na systém schopný prenosu z bodu do viacerých bodov.0002 Pri službách z bodu do viacerých bodov (taktiež označovaných ako služby jedného mnohým) cez také systémy, ak je výberové vysielanie pomocou internetového protokolu (IP multicast), dátové vysielanie pomocou internetového protokolu (IP datacast) a služby multimediálneho všeobecného / výberového vysielania (Multimedia Broadcast / Multicast Services - MBMS), je doručenie súborov,ako napriklad sťahovanie multimediálnych súborov, dôležitou službou.0003 Avšak mnohé vlastnosti doručovania súborov cez protokoly z bodu do bodu, ako napriklad protokolu na prenos súborov (File Transfer Protocol - FTP) aprotokolu na prenos hypertextu(Hypertext Transfer Protocol - HTTP) sú pre scenáre z bodu do viacerých bodov problematické. Konkrétne spoľahlivé doručenie súborov, t.j. garantovanie doručenia súborov pomocou podobných potvrdzovacich (acknowledgement - ACK) protokolov zbodu do bodu ako je protokol riadenia prenosu (Transport Control Protocol - TCP) nieje uskutočniteľné.0004 Medzinárodná prihláška patentu W 0 03/105353 uvádza systém pre prenos správ do viacerých uzlov určenia, vktorých správa zo zdrojového uzla je adresovaná na výberovú všeobecnú vysielaciu adresu a záhlavie správy obsahuje viacero adries uzlov určenia. Uzly určenia,ktoré úspešne prijmú prenos, vypočitajú časový interval v ktorom majú vyslat potvrdzovaciu správu na základe polohy svojej adresy v záhlaví správy. Zdrojový uzol potom môže zabezpečiť opätovné vysielanie do uzlov určenia, ktoré úspešne neprijali prenos komunikácie buď ako výberového vysielania (multicast) - všeobecného vysielania (broadcast) alebo vysielania pre jednu stanicu(unicast) v závislosti od prijatých potvrdzovacich správ, 0005 Pracovná skupina Spoľahlivý prenos výberového vysielania (Reliable Multicast Transport(RMT) Working Group) Riadiacej skupiny internetu (Internet Engineering Task Force - lETF) je v súčasnosti v procese štandardizácie dvoch kategórií prenosových protokolov výberového vysielania odolných proti chybám. Vprvej kategórii sa spoľahlivosť realizuje použitím (proaktivnej) doprednej korekcie chýb (samoopravný kód) (FonNard Error Correction - FEC), t.j. vyslanim určitého množstva redundantných dát, ktoré môžu pomôcť prijimaču rekonštruovať chybné dáta vdruhej kategórii sa spoľahlivosť realizuje použitím spätnej väzby s prijimačom.0006 Asynclnrônne vrstvené kódovanie (Asynchronous Layered Coding - ALC) je protokolová inštalácia, ktorá patrí do prvej kategórie, pričom spoľahlivý výberový vysielací protokol orientovaný na NACK (NACK-Oriented Reliable Multicast - NORM) patrí do druhej kategórie. Prístupové siete, na ktorých tieto protokoly možno používať, zahŕňajú, avšak nie sú obmedzené na bezdrôtové siete sviacnásobným prístupom, ako je univerzálny mobilný telekomunikačný systém (Universal Mobile Telecommunications System - UMTS) zahŕňajúci globálny systém pre mobilnú komunikačnú evolučnú vysokofrekvenčnú prístupovú sieť (Global System for Mobile Communications Evolution Radio Access Network - GERAN) a UMTS terestriálnu vysokofrekvenčnú prístupovú sieť (UMTS Terrestrial Radio Access Network - UTRAN), bezdrôtové miestne siete (Wireless Local Area Networks - WLAN), siete všeobecného vysielania digitálneho videa - pozemné (Digital Video Broadcasting - Terrestrial - DVB-T) asiete všeobecného vysielania digitálneho videa - satelitné0007 Stručne, protokol ALC je proaktívna schéma založená na FEC, ktorá umožňuje prijímačom rekonštruovať znetvorené pakety alebo pakety, ktoré neprijali. Protokol ALC využíva dekódovanie F EC na viacerých kanáloch, čo umožňuje vysielatelovi vysielať dáta pri viacnásobných rýchlostiach(kanáloch) pravdepodobne heterogénnym prijímačom. Okrem toho protokol ALC využíva kontrolný mechanizmus zahltenia, aby udržiaval rozne rýchlosti na rôznych kanáloch.0008 Protokol ALC je masívne rozširovateľný vzhľadom na počet používateľov, pretože sa nevyžaduje indikácia vzostupu. Preto akékoľvek množstvo dodatočných prijímačov exaktne nekladie zvýšenú požiadavku na systém. Avšak protokol ALC nie je 100 spoľahlivý, pretože nie je zaručený príjem a tým sa vo všeobecnosti nepopisuje ako necitíivý na malé zmeny parametrov.0009 NORM naopak špecifikuje využívanie správ negatívneho potvrdzovania (Negative Acknowledgement - NACK), aby indikoval ktoré dátové pakety, o ktorých sa predpokladá, že dôjdu do prijímača, prijímač vôbec neprijal alebo ich prijal nesprávne. lnými slovami, prijímače využívajú správy NACK, aby indikovali stratu alebo poškodenie prenášaných dátových paketov do vysielača. Podobne prijímač, ktorý stratil niektoré dátové pakety z prenosu dát, môže do vysielača (alebo do opravárskeho servera) vyslať správu NACK, požadujúcu aby vysielač (alebo opravársky server) znovu vyslal chýbajúci dátový blok alebo bloky. Protokol NORM taktiež voliteľne dovoľuje používat FEC kódovanie úrovne dátových paketov kvôli proaktivnym robustným prenosom.0010 Správy NACK nie sú všeobecne špecifické pre NORM, avšak možno ich taktiež používať v spojení s inými protokolmi alebo systémami, napríklad so systémami ktoré podporujú relácie, ktoré riadi protokol doručovanie súborov cez jednosmerný prenos (File Delivery Over Unidirectional Transport - FLUTE).0011 FLUTE je prenosový protokol jedného mnohým, ktorý stavia na stavebných blokoch FEC aALC. Je určený pre doručovanie súborov z vysielača (vysielačov) do prijímača (prijímačov) cez jednosmerné systémy. Má špecializácie, ktoré ho robia vhodným pre bezdrôtové systému z bodu do viacerých bodov. Detaily protokolu FLUTE sú detailnejšie preberané v publikácii s názvom FLUTE File Delivery over Unidirectional Transport (Internetový návrh) pripravenej vyššie uvedenou pracovnou skupinou RMT Riadiacej skupiny internetu (IETF).0012 Používanie FLUTE napriklad špecifikuje Projekt partnerstva tretej generácie (Third Generation Partnership Project - 3 GPP) pre načítavanie súborov v reláciách systému MBMS. V takýchto reláciách FLUTE sa dopredná korekcia chýb (FEC) môže alebo nemusí používať. V každom prípade nie o všetkých prijímačoch v relácii možno predpokladať, že ked skončí relácia, príjmu celý súbor. Ohľadne toho 3 GPP je proces definovania opravárskych relácií z bodu do bodu, pričom prijímačom sa dovoľuje indikovat požiadavky na opätovné prenosy dátových paketov do vysielača alebo opravárskeho serveru cez správu NACK, aby boli schopné zrekonštruovať nahraný obsah.0013 Keď sa správy NACK používajú v spojení s reláciami FLUTE (alebo v iných reláciách využívajúcich protokol transportnej vrstvy, hlavne nasmerovaného na odporu prenosu z bodu do viacerých bodov) je identifikácia dátových paketov chýbajúcich v prijímačoch dôležitým problémom. Používanie protokolov určených pre prenos z bodu do bodu, ako je TCP a ich spôsoby potvrdzovania, nie sú tu nevyhnutne uskutočnitelné.0014 V relácii FLUTE transportné objekty, napríklad multimediálne súbory alebo ich časti, sa identifikujú transportným identifikátorom (Transport Identiñer - TOl) a prenášajú sa z vysielača do množstva prijímačov v rámci transportnej relácie, ktorú označuje identifikátor transportnej relácie(Transport Session identifier - TSl). Prenos uvedených transpoitných objektov sa v skutočnosti vykonáva prenosom dátových paketov FLUTE, pričom dátové plakety FLUTE obsahujú ako záťaž(payload) surové alebo zakódované časti uvedeného transportného objektu, izv. kódovacie symboly. Uvedené dátové pakety FLUTE ďalej obsahujú TSI a TOI, ako aj identifikátor záťaže (payload) FEC,ktorý bude vysvetlený nižšie.0015 Rôzne schémy FEC špecifikované pracovnou skupinou RMT sa zakladajú na štruktúre zdrojových blokov a kódovaclch symbolov. Takéto schémy FEC sú popísané v publikácii Požiadavka na pripomienky (Request for Comments - RFC) č. 3452 Fon/vard Error Correction Building Block(Stavebný blok doprednej korekcie chýb) a v publikácii RFC č. 3695 Compact Forward Error Correction (FEC) Schemes (Kompaktné schémy doprednej korekcie chýb). Každý kódovací symbol môže identifikovať jeho číslo zdrojového bloku (Source Block Number - SBN) a jeho identifikátor kódovacieho symbolu (Encoding Symbol ID - ESI). Všetky tieto schémy FEC predpokladajú, že v rámci každého transpoitného objektu sa SBN postupne zvyšuje o jedna a že v rámci zdrojového bloku sa ESI zvyšuje o jedna pre každý kódovací symbol ktorý sa prenáša. Ako SBN, tak ESI sú obsiahnuté v identifikátore záťaže FEC, ktorý je obsiahnutý v dátovom pakete FLUTE.0016 V týchto schémach FEC, identifikáciu dátových paketov FLUTE, ktoré v prijimači neboli vôbec prijaté alebo neboli prijaté správne, možno uskutočniť pomocou ich SBN a ESI, ktoré sú obsiahnuté v identifikátore záťaže FEC (FEC Payload ID) dátových paketov FLUTE. Tieto parametre možno potom indikovať späť ako NACK do vysielača, aby sa zariadil opátovný prenos týchto identifikovaných dátových paketov.0017 Avšak publikácia Jednoduché schémy doprednej korekcie chýb (FEC) (internetový navrh) od M. Lubyho zavádza schémy FEC, ktoré využívajú jednoduchší identifikátor záťaže FEC a možno ich použiť na doručenie objektov bez používania explicitnej štruktúry zdrojového bloku. Tieto schémy F EC môžu napriklad využívat bezrýchlostné (rateless) kódy, ako sú kódy Lubyho transformácie (LT) alebo Raptor.0018 Dekódovač LT (pozrite M. Luby LT-codes v zborníku sympózia ACM o základoch počítačovej vedy (ACM Symposium on Foundations of Computer Science (FOCS), 2002) vysiela prúd zakódovaných bitov, ktoré sú roztrúsenými náhodnými lineárnymi kombináciami dátových bitov. Prijímač sníma zašumené verzie zakódovaných bitov a využíva BP dekodér (belief propagation decoder - dekodér šírenia viery), aby sa pokúsil zistit dátové bity. Počet zašumených zakódovaných bitov n, vyžadovaný na úspešné odkodovanie, závisí od kvality a typu kanála. Kódy LT, navrhnuté pomocou distribúcie robustného solitérneho stupňa môžu dosiahnuť spôsobilosť na každom binárnom vymazávacom kanáli (binary erasure channel - BEC). lnými slovami, R k/n možno urobit ľubovoľne blizku ku (1-p) pre každú pravdepodobnosť vymazania p.0019 Kľúčovou myšlienkou kódovanie Raptor (pozri A. Shokrollahi Raptor codes, Digital Fountain, lnc., Tech. Rep. DF 2003-06-001, jún 2003) je uvoľniť podmienku, že treba regenerovať všetky vstupné symboly. Ak kód LT potrebuje regenerovať len konštantnú časť svojich vstupných symbolov, tak, jeho dekódovaci graf potrebuje mať iba hrany O(k), čo počíta s lineárnym časovým kódovaním. Všetky vstupné symboly možno stále regenerovať konkatenáciou (retazením) tradičného mazacieho korekčného kódu pomocou kódu LT. Vložené symboly n sa potom získajú kódovaním vstupných symbolov k pomocou mazacieho korekčného blokového kódu (k, n), schopného regenerovať všetky vstupné symboly z pevnej časti vložených symbolov. Vložené symboly n sa potom kódujú pomocou kódu LT, ktorý môže regenerovať zo svojich vstupných symbolov požadovanú časť vložených symbolov.0020 identifikátor záťaže FEC, navrhovaný pre tieto schémy FEC, pozostáva zo 4-bytového klúča,z ktorého sa vygeneruje dekódovaci graf. SBN nie je zahrnuté v tomto identifikátore záťaže FEC a v tomto pripade sa o ESI myslí, že nesie taký identifikátor ako je uvedený 4-bytový kľúč.0021 Navyše kľúče náhodne generuje kódovaci FEC. Čiže prijímač nemôže byť schopný identifikovať chýbajúce dátové pakety z kľúčov iných dátových paketov, ktoré prijal v tejto relácii, V dôsledku toho identifikácia chýbajúcich dátových paketov FLUTE pomocou ich súvisiacich SBN a ESI V týchto schémach FEC neplatí.0022 Americký patent číslo US 6,212,240 sa týka spôsobu prenosu dát medzi komunikačnými zariadeniam. Prvé komunikačné zariadenie vysiela uživateľské dáta, rozdelené na množstvo dátových blokov pri prvej modulačnej rýchlosti (napr. 64-QAM) Prvé komunikačné zariadenie potom prijíma potvrdenie z druhého komunikačného zariadenia, indikujúce množstvo dátových blokov, ktoré neboli prijaté a porovnáva toto množstvo s prahom. Keď je množstvo menšie než prah, dátové bloky ktoré neboli prijaté sa opätovne vyšlú druhou, zvyčajne nižšou modulačnou rýchlosťou (napr. 16 QAM). Ináč sa znovu vyšlú prvou modulačnou rýchlosťou. Tu, pretože prvá modulačná rýchlosť si vyžaduje menšiu šíku pásma než druhá modulačná rýchlosť, aby preniesla ekvivalentné množstvo dát, sa znížením modulaćnej rýchlosti len ked sa má znovu posielat množstvo dátových blokov menšie než prah, sa dosiahne efektívne prideľovanie vysoko frekvenčnej šírky pásma pre prenosy a opätovné prenosy užívateľských dát.ZHRNUTIE VY NÁLEZU 0023 Vzhladom na vyššie uvedené problémy existuje potreba vylepšeného spôsobu a súvisiacich zariadení na indikovanie informácií o oprave v systéme schopnom prenosu z bodu do viacerých0024 Navrhuje sa spôsob prenosu dátových paketov, ako je špecifikovaný nárokom 1.0025 Uvedený systém môže predstavovať akýkoľvek bezdrôtový alebo drôtový systém, pričom dátové pakety sa vysielajú z najmenej jedného vysielača do jedného alebo viacerých prijímačov. Uvedené vysielanie môže byť bud všeobecne vysielaný prenos, v ktorom uvedený vysielač adresuje všetky prijímače, alebo selektívne vysielaný prenos, v ktorom uvedený vysielač adresuje len podskupinu všetkých prijímačov. Uvedený systém možno napríklad nasadiť v kontexte UMTS, LAN,WLAN, DVB-T alebo DVB-S, a môže byt určený na rozširovanie takého obsahu, ak napríklad multimediálnych súborov do množstva prijímačov. Uvedený prenos uvedeného jedného alebo viacerých dátových paketov možno vykonávať na jednosmerných alebo dvojsmerných prenosových linkách.0026 Uvedené prenášane dátové pakety možno napríklad vzťahov na obsah, ktorý sa má prenášať do uvedených prijímačov. Tento obsah môže byt segmentovaný a spracovávaný, aby umožnil prenos do uvedených prijímačov, pričom uvedené dátové pakety treba rozumiet ako výsledok tejto segmentácie a spracovania. Napríklad uvedené dátové pakety môžu byť dátové pakety FLUTE,ktorých záťaž (payload) sa zlska kódovanim FEC transportného objektu napr. multimediálneho súboru. V tomto prípade uvedená záťaž uvedeného dátového paketu FLUTE môžu byt napríklad kódovacie symboly alebo kódovacie pakety.0027 Najmenej v jednom prijímači, ktorý je označený ako špecifický prijímač, sa vyžaduje príjem opravárskych dátových paketov, čo môže byt z množstva dôvodov ako napríklad nesprávny príjem alebo strata prenášaných dátových paketov. Uvedený špecifický prijímač si môže uvedomiť požiadavku prijímať opravárske dátové pakety počas uvedeného prenosu dátových paketov, alebo potom čo skončil prenos dátových paketov.0028 Uvedené opravárske dátové pakety môžu byt napríklad jednoduché kópie prenesených dátových paketov, ktoré neprijal uvedený špecifický prijímač. Rovnako sa môžu líšiť vzhľadom ako na kódovanie, tak na skutočný obsah. Napríklad ak sa používa bezrýchíostné kódovanie FEC,možno použiť rozličné kľúče pri generovaní opravárskych dátových paketov. Opravárske dátové pakety takto slúžia účelu poskytnutia tohto množstva informácií uvedenému špecifickemu prijlmaču,ktoré vyžaduje uvedený špecifický prijímač.0029 Aby sa zopol prenos opravárskych dátových paketov z uvedeného opravárskeho serveru,uvedený špecifický prijímač indikuje informácie o opravárskych dátach do uvedeného opravárskeho serveru. Toto sa môže uskutočňovať v prenose z bodu do bodu. Opravársky server je takto aktivovaný, aby generoval príslušné opravárske dátové pakety a aby ich prenášal do špecifického prijímača. Tento prenos môže byť napríklad prenosom z bodu do bodu.0030 Podla tohto vynáíezu sa navrhuje, že tieto opravárske informácie zahŕňajú informácie,vzťahujúce sa na počet prenesených dátových paketov, ktoré boli správne prijaté v uvedenom špecifickom prijlmači. Tu pojem správne prijaté sa rozumie takým spôsobom, že prijímač je schopný využiť informácie obsiahnuté v uvedenom prijatom dátovom pakete pre dalšie spracovanie a dátový paket nemusí vyradiť. O tomto možno napríklad rozhodnúť na základe kontrolnej sumy obsiahnutej v dátovom pakete. Zdôvodnenie tohto navrhuje, že pri určitých kódovacích technológiách FEC, ktoré možno využiť na generovanie uvedených dátových paketov z dátového objektu, ktorý sa má skutočne prenáša v prenose bodu do viacerých bodov medzi uvedeným vysielačom a uvedeným jedným alebo viacerými prijímačmi, príjem minimálneho počtu dátových paketov stačí, aby sa umožnilo prijlmaču rekonštruovať samotný uvedený dátový objekt. Napríklad ak je dátový objekt zakódovaný do N dátových paketov, v prijímači možno vyžadovať len LN dátových paketov, aby bol schopný rekonštruovať uvedený dátový objekt. Tu sa ďalej nemusí vyžadovať, aby sa prijalo L špecifických dátových paketov, ale aby sa prijalo len L rozličných dátových paketov z N dátových paketov. Čiže aby sa umožnilo opravárskemu serveru Vygenerovať opravárske dátové pakety, stačia informácie kolko dátových paketov bolo spravne prijatých na uvedenom špecíñckom prijímači spolu s ďalšími štrukturáínymi informáciami, súvísiacimi s dekódovacou technológiou FEC, 0031 Na rozdiel od súčasnej techniky, exaktná identifikácia dátových paketov, ktorú vyžaduje uvedený špecifický prijímač, napríklad vzhladom na SBN a ESI súvisiace s určitým transportným objektov a určitou transportnou reláciou sa už nemusí indikovať späť do uvedeného opravárskeho serveru, čo ohromne znižuje indikačnú réžiu (overhead), s ktorou sa stretávame V opravárskych reláciách.

MPK / Značky

MPK: H04L 1/16

Značky: viacerých, opravy, schopné, bodov, systémy, vyžiadanie, mechanizmus, přenosu

Odkaz

<a href="http://skpatents.com/22-e4405-mechanizmus-na-vyziadanie-opravy-bod-po-bode-pre-systemy-schopne-prenosu-z-bodu-do-viacerych-bodov.html" rel="bookmark" title="Databáza patentov Slovenska">Mechanizmus na vyžiadanie opravy bod po bode pre systémy schopné prenosu z bodu do viacerých bodov</a>

Podobne patenty