CZ2006687A3 - Zpusob a zarízení pro adaptivní správu zpozdení vbezdrátovém komunikacním systému - Google Patents

Abstract

Prostredky jsou pro adaptivní správu zpozdení a zpusob je pro alokaci prostredku s ruznými pozadavky na kvalitu sluzby (QoS - Quality of Service). Plánovac dopredného toku (FL - forward link) pripravuje instance prenosu odbavením dat cekajících ve fronte podle trídy priority, jako je napríklad nejlepsí úsilí (BE - best effort) a urychlené smerování (EF - expedited forwarding). Datové bity z více front se vkládají do instance prenosu. Ke generování sady kandidátských instancí prenosu se pouzívají ruzné metriky a potom se vybere a vytvorí nová instance prenosu z této sady kandidátu.

Description

Tato patentová přihláška nárokuje prioritu z provizorní přihlášky č. 60/568 650 nazvané „Adaptive delay management (Adaptivní správa zpoždění) podané 5. května 2004 a postoupené nabyvateli této přihlášky a zde výslovně začleněné odkazem.

Tato patentová přihláška nárokuje prioritu z provizorní přihlášky č. 60/625 660 nazvané „Adaptive delay management (Adaptivní správa zpoždění) podané 4. listopadu 2004 a postoupené nabyvateli této přihlášky a zde výslovně začleněné odkazem.

Oblast techniky

Vynález se týká komunikací a podrobněji se týká plánování přenosů v bezdrátovém komunikačním systému použitím adaptivní správy zpoždění.

Dosavadní stav techniky

Bezdrátové komunikační systémy obsahují systémy pro zpracování komunikace, které používají technologii obvodově spínané nebo fixní alokace prostředků, a systémy zpracování komunikace používající technologii paketově spínané nebo dynamické alokace prostředků. Jak obvodové spínání tak paketové spínání lze použít ve vysokokapacitních sítích. V komunikačních systémech s obvodovým spínáním se vytvoří

89723 (0989723_CZ.doc) 16.12.2006

vyhrazená komunikační trasa mezi vysílačem a přijímačem; a síťové prostředky mezi vysílačem a přijímačem se před začátkem přenosu považují za statické, tudíž vytváří „obvod. Prostředky zůstávají vyhrazeny obvodu během celého přenosu a všechny zprávy se přenášejí po stejné trase. V paketově spínaných sítích se zpráva rozdělí na pakety, přičemž každý paket se může do cíle pohybovat po jiné trase. Po přijetí se pakety rekompilují, aby se získala původní zpráva. V paketově spínaném systému se pakety představující zprávy nebo fragmenty zpráv individuálně směrují mezi uzly. Pakety se po vhodné trase směrují do cíle. Jinými slovy ne všechny pakety přenášené mezi dvěma stejnými hostiteli se budou nezbytně přenášet po stejné trase, i kdyby byly tyto pakety součástí stejné zprávy.

V paketově spínaném systému nebo sdíleném paketovém datovém systému lze k emulaci obvodově spínané hlasové komunikace použít službu Voice over Internet Protokol (VoIP). VoIP je typicky aplikace nebo služba citlivá na zpoždění, a proto se používají mechanizmy Kvality služby (QoS), aby byly splněny požadavky na zpoždění doručení paketu. Jiné služby a druhy přenosů mají také různé požadavky na zpoždění nebo cíle k zajištění QoS. Navíc je potřeba zajistit adaptivní správu zpoždění pro plánování přenosů v komunikačním systému.

Podstata vynálezu

Provoz aplikací s neefektivní zpoždění.

komunikačního systému s různými QoS požadavky může Například VoIP aplikace Jeden způsob emuluje voice podporou služeb a být neoptimální a mají požadavky na zajištěním stejných

89723 (0989723_CZ.doc) 16.12.2006

požadavků na zpoždění pro více uživatelů nezávisle na zátěži a pokrytí. Takový přístup je pro alokaci prostředků pro zajištění stejného zpoždění neoptimální a vylučuje optimalizace, které by byly možné ke zvýšení kapacity systému. V jednom provedení lze kapacitu systému zvýšit zajištěním různých zpoždění pro různé uživatele, kde se prostředky alokují jako funkce zátěže a pokrytí.

Následující popis se týká plánovacího algoritmu pro přímý link (FL - forward link) systému podporujícího lxEV-DO traffic, tj. podporujícího IS-856 specifikaci. V jednom provedení využívá v jednom provedení plánovací algoritmus různých multi-user paketů a krátkých paketů, aby RA splnil požadavky kvality QoS různých aplikací při maximalizaci kapacity FL. Plánovací algoritmus poskytuje také mechanismus, který upřednostňuje různé aplikace. Takové upřednostňování může být založeno na typu aplikačního toku, specifických QoS požadavcích, nebo jiných charakteristikách toku. V jednom provedení se toky plánují pro přenos na základě senzitivity zpoždění aplikace. V jednom aspektu jsou toky diferencovány na základě citlivosti na zpoždění vyvážené citlivostí na propustnost. Zatímco následující popis posuzuje plánovací prostředky a způsoby jako implementované v kontextu Revize A specifikace lxEV-DO, plánovací prostředky a způsoby jsou dále použitelné v alternativních systémech, zvláště koncepty jsou použitelné v systémech, jejichž uživatelé jsou kompatibilní s danou podmnožinou subtypů, jak je definováno v IS-856 specifikaci, konkrétně ,,cdma2000 High Rate Packet Data Air Interface Specification,, 3GPP2 C.S0024 Ver. 4.0, říjen 2002.

V následujícím popisu se pojmy jako „Rev-A uživatel nebo „uživatel kompatibilní s Rev-A budou používat

89723 (0989723_CZ.doc) 16.12.2006 k označení přístupového terminálu (AT), který podporuje vrstvu kanálu přístupu k médiu (Medium Access Channel - MAC) a fyzickou vrstvu subtypů protokolu definovaných v IS-856, konkrétně „cdma2000 High Rate Packet Data Air Interface Specification, 3GPP2 C.S0024-A, Verze 1.0, March 2004. Konkrétně podporuje Rev-A uživatel urychlený MAC protokol kanálu přímého trafficu. Pojmy jako „Rel-0 uživatelé se používají k označení ATs podporujících subtypy protokolů MAC vrstvy a fyzické vrstvy definovaných v IS-856, ale které nepodporují novější subtypy definované v revizi A.

V bezdrátovém komunikačním systému, který využívá schématu kódového multiplexu (CDMA), přiřazuje jeden způsob plánování každé účastnické stanici všechny kódové kanály ve vyhrazených časových intervalech na bázi časového multiplexu. Aby se umožnila exkluzivní komunikace s účastníkem, implementuje centrální komunikační uzel, jako například základnová stanice, (Base Station - BS) , unikátní nosnou frekvenci nebo kód kanálu přiřazený účastníkovi. TDMA schémata lze implementovat také v pevných sítích používajících fyzické kontaktní reléové spínání nebo paketové spínání. CDMA systém lze navrhnout tak, aby podporoval jeden nebo více standardů jako například (1) „TIA/EIA/IS-95-B Mobile Station-Base Station Compatibility Standard for Dual-Mode Wideband Spread Spectrum Cellular System, na který se zde odkazuje jako na standard IS-95; (2) standard nabízený konsorciem „3rd Generation Partnership Project, na které se zde odkazuje jako 3GPP; a realizovaný v sadě dokumentů zahrnující dokumenty číslo: 3G TS 25.211, 3G TS 25.212, 3G TS 25.213 a 3G TS 25.214, 3G TS 25.302, na které se zde odkazuje jako na W-CDMA standard; (3) standard nabízený konsorciem „3rd Generation Partnership Project 2 zde označovaným jako 3GPP2 a TR-45.5, zde označovaný jako

89723 (0989723_CZ.doc) 16.12.2006

cdma2000 standard, dříve označovaný jako „IS-2000 MC, nebo (4) některý jiný standard bezdrátové komunikace.

CDMA systém umožňuje hlasovou a datovou komunikaci mezi uživateli prostřednictvím pozemního linku. V CDMA systému probíhá komunikace mezi uživateli prostřednictvím jedné nebo více základnových stanic. V bezdrátových komunikačních systémech se jako přímý link označuje kanál, kterým se šíří signály ze základnové stanice na účastnickou stanici a zpětný link označuje kanál, kterým se přenášejí signály z účastnické stanice na základnovou stanici. Přenosem dat na zpětném linku na základnovou stanici komunikuje první uživatel na první účastnické stanici s druhým uživatelem na druhé účastnické stanici. Základnová stanice přijímá data z první účastnické stanice a směruje tato data na základnovou stanici obsluhující druhou účastnickou stanici. V závislosti na vzdálenosti účastnických stanic mohou být obě obsluhovány jednou základnovou stanicí nebo více základnovými stanicemi. V každém případě vysílá základnová stanice obsluhující druhou účastnickou stanici data na přímý link. Místo komunikace s druhou účastnickou stanicí může účastnická stanice komunikovat také s terestrickým internetem prostřednictvím spojení s obsluhující základnovou stanicí. V bezdrátové komunikaci, jako například té splňující IS-95, se signály přímého a zpětného linku přenášejí v odlišných frekvenčních pásmech.

Přehled obrázků na výkresech

Vynález bude blíže vysvětlen prostřednictvím konkrétních příkladů provedení znázorněných na výkresech, na kterých představuje

89723 (0989723_CZ.doc) 16.12.2006

obr. 1A bezdrátový komunikační systém, obr. 1B bezdrátový komunikační systém s podporou vysokorychlostních datových přenosů, obr. 2 blokové schéma přístupové sítě (AN - Access

Network) bezdrátového komunikačního systému, obr. 3 vývojový diagram plánovacího algoritmu pro přenosy v bezdrátovém komunikačním systému, obr. 4 kategorizaci plánovačů datových paketů, obr. 5 zpětnovazební smyčku pro určení mohutnosti kanálu na základě přijatých požadavků na data od uživatele, obr. 6 chování plánovače za přítomnosti uživatelů s upřednostňovaným směrováním s jednoduchým typem přenosu, obr. 7 výpočet kondenzovaného zátěžového polynomu c(z) ze zátěžového polynomu p(z), obr. 8 plánovač podle jednoho provedení, obr. 9 část plánovače z obr. 8 podle jednoho provedení, obr. 10 plánovací algoritmus pro implementaci adaptivní správy zpoždění přenosů, obr. 11 část plánovacího algoritmu obr. 10 podle jednoho

89723 (0989723_CZ.doc) 16.12.2006

provedení, obr. 12 část plánovacího algoritmu obr. 10 podle jednoho provedení, obr. 13 část plánovacího algoritmu obr. 10 podle jednoho provedení.

Příklady provedení vynálezu

Obr. 1A slouží jako příklad komunikačního systému 100, který podporuje více uživatelů a je schopen implementovat alespoň některé aspekty tohoto vynálezu. K plánování přenosů v systému 100 lze použít kterýkoliv z mnoha algoritmů a způsobů. Systém 100 poskytuje komunikaci pro množství buněk 102A až 102G, z nichž každá je obsluhováná základnovou stanicí 1Q4A až 104G v tomto pořadí. V ukázkovém provedení mají některé základnové stanice 104 více přijímacích antén nebo mají pouze jednu přijímací anténu. Podobně některé základnové stanice 104 mají více vysílacích antén a jiné mají jedinou vysílací anténu. Nejsou zde žádná omezení na kombinaci vysílacích a přijímacích antén. Proto je pro základnovou stanici 104 možné, aby měla více vysílacích antén a jedinou přijímací anténu, nebo aby měla více přijímacích antén a jedinou vysílací anténu, nebo aby měla jednu nebo více jak vysílacích tak přijímacích antén.

Rostoucí poptávka po bezdrátových datových přenosech a rozšiřování služeb dostupných prostřednictvím bezdrátových komunikačních technologií vedly k rozvoji specifických

89723 (0989723_CZ.doc) 16.12.2006

- 8 datových služeb. Jednou z těchto služeb je vysoká rychlost přenosu „HDR - High data rate. Příklad služby HDR je navržen v „EIA/TIA-IS856 cdma2000 specifikaci vysokorychlostního paketového datového vzdušného rozhraní, označované jako „HDR specifikace. Služba HDR je obecně nástavbou hlasového komunikačního systému, která poskytuje účinný způsob přenosu datových paketů v bezdrátovém komunikačním systému. S rostoucím objemem přenášených dat a počtem přenosů se omezená šířka pásma pro radiové přenosy stane kritickým prostředkem.

Obr. 1B ukazuje referenční model architektury pro komunikační systém 120 s přístupovou sítí AN 122, která komunikuje s přístupovým terminálem AT 126 prostřednictvím vzduchového rozhraní 124. V jednom provedení je systém 10 systém s kódovým multiplexem CDMA s vysokorychlostním (HDR) nástavbovým systémem, který je specifikován ve standardu HDR. AN 122 komunikuje s AT 126, stejně jako s kterýmkoliv jiným AT v systému 120 (není zobrazeno) prostřednictvím vzduchového rozhraní 124. AN 122 obsahuje více sektorů, kde každý sektor poskytuje alespoň jeden kanál. Kanál je definován jako sada komunikačních línků pro přenosy mezi AN 122 a AT s daným přiřazením frekvencí. Kanál se skládá z přímého linku (FL) pro přenosy z AN 122 na AT 126 a zpětného linku (RL) pro přenosy z AT 126 na AN 122.

Pro datové přenosy přijímá AN 122 datové požadavky z AT 12 6. Datové požadavky specifikují rychlost, s jakou se mají data vysílat, délku vysílaného datového paketu a sektor, ze kterého se data mají vysílat. AT 126 určuje rychlost přenosu dat založenou na kvalitě kanálu mezi AN 122 a AT 126. V jednom provedení je kvalita kanálu dána poměrem nosné k interferenci, C/I. Alternativní provedení mohou

89723 (0989723_CZ.doc) 16.12.2006 • 9 • · * ·

9 99 99

- 9 používat jiné míry odpovídající kvalitě kanálu. AT 126 poskytuje požadavky na datové přenosy vysláním zprávy řízení rychlosti přenosu dat, DRC - Data Rate Control, specifickým kanálem, který se označuje jako DRC kanál. DRC zpráva obsahuje část rychlosti přenosu dat a sektorovou část. Část rychlosti přenosu dat indikuje požadovanou datovou rychlost, kterou má AN 122 vysílat data a sektor označuje sektor, ze kterého bude AN 122 data vysílat. Jak datová rychlost, tak informace o sektoru jsou typicky požadovány procesem přenosu dat. Část rychlosti přenosu dat se označuje jako DRC hodnota a sektorová část se označuje jako DRC obálka. DRC hodnota je zpráva vysílaná AN 122 prostřednictvím vzduchového rozhraní 124. V jednom provedení odpovídá každá DRC hodnota rychlosti přenosu dat v kbit/s s přiřazenou délkou paketu podle předem daného přiřazení DRC hodnoty. Přiřazení zahrnuje DRC hodnotu specifikující nulovou rychlost přenosu dat. V praxi nulová rychlost přenosu dat AN 122 sděluje, že AT 126 není schopen přijímat data. Například se jedná o situaci, kdy je kvalita kanálu pro AT 126 nedostatečná na to, aby přijímal data přesně.

Za provozu AT 126 souvisle monitoruje kvalitu kanálu, aby se vypočetla rychlost přenosu dat, kterou je AT 126 schopen přijmout další vyslaný datový paket. AT 126 potom vygeneruje odpovídající hodnotu DRC, tato DRC hodnota se přenese na AN 122, aby se vyžádal datový přenos. Všimněte si, že datové přenosy jsou typicky rozděleny do paketů. Čas vyžadovaný k přenosu paketu dat je funkcí použité rychlosti přenosu dat.

DRC signál poskytuje také informaci o tom, který kanál plánovač použije k určení okamžité rychlosti příjmu informace (nebo příjmu přenášených dat) pro každou ze

89723 (0989723_CZ.doc) 16.12.2006

vzdálených stanic přidruženou k jednotlivým frontám. Podle tohoto provedeni DRC signál vysílaný z kterékoliv vzdálené stanice indikuje, že vzdálená stanice je schopná přijímat data na kterékoliv z více efektivních rychlostí přenosu dat.

Jeden příklad komunikačního systému podporujícího HDR přenosy přizpůsobené pro plánování vysílání ve víceuživatelských systémech je zobrazen na obr. 2. Obr. 2 je detailně popsán níže, kde se konkrétně základnová stanice 820 a řadič 810 základnové stanice propojují s paketovým síťovým rozhraním 806. Řadič 810 základnové stanice obsahuje plánovač 812 kanálu pro implementaci plánovacího algoritmu pro přenosy v systému 800. Plánovač 812 kanálu určuje délku servisního intervalu, během kterého se data, která se mají přenášet na kteroukoliv konkrétní vzdálenou stanici založená na okamžité rychlosti příjmu dat touto vzdálenou stanicí (jak je udáno v posledním přijatém DRC signálu). Servisní interval nemusí být spojitý v čase, ale může se vyskytovat jednou za několik slotů. Podle jednoho provedení se první část paketu přenáší během prvního slotu v prvním čase a druhá část se přenáší o 4 sloty později. Po sobě jdoucí části paketu se tedy přenášejí ve více slotech s podobným rozprostřením na 4 sloty, t j . 4 sloty od sebe. Podle některého provedení určuje okamžitá rychlost příjmu dat Ri délky servisního intervalu Li spojenou s konkrétní datovou frontou.

Navíc, plánovač 812 kanálu vybere konkrétní datovou frontu pro přenos. Přiřazené množství dat, které se má přenést, se potom přijímá z datové fronty 830 a předává se kanálovému prvku 826 pro přenos na vzdálenou stanici spojenou s datovou frontou 830. Jak je popsáno níže, vybírá plánovač 812 kanálu frontu pro poskytnutí dat, která se

89723 (0989723_CZ.doc) 16.12.2006 • · • ·

- 11 přenášejí v následujícím servisním intervalu za použití informací obsahujících váhu přiřazenou k jednotlivým frontám. Váha přiřazená k přenášené frontě se potom aktualizuje.

Řadič 810 základnové stanice je propojen s paketovým síťovým rozhraním 806, veřejnou přepínanou telefonní sítí, veřejnou přepínanou telefonní sítí (PSTN), 808 a základnovými stanicemi v komunikačním systému (na obr. 3 je pro jednoduchost zobrazena pouze jedna základnová stanice 820). Řadič 810 základnové stanice koordinuje komunikaci mezi vzdálenými stanicemi v komunikačním systému a ostatními uživateli připojenými k paketovému síťovému rozhraní 806 a PSTN 808. PSTN 808 je propojen s uživateli prostřednictvím standardní telefonní sítě (není zobrazeno na obr. 3) .

Řadič 810 selektorů 816, základnové ačkoliv je stanice obsahuje mnoho na obr. 2 pro jednoduchost zobrazen pouze jeden z nich. Každý selektor 816 je určen k řízení komunikace mezi jednou nebo více základnovými stanicemi 820 a jednou vzdálenou stanicí (není zobrazeno) . Pokud není selektor 816 přiřazen k dané vzdálené stanici, je procesor 818 řízení hovoru informován o nutnosti pagingu vzdálené stanice. Procesor 818 řízení hovoru potom řídí základnovou stanici 820 tak, aby provedla paging na vzdálenou stanici.

Zdroj 802 dat obsahuje množství dat, která se mají přenášet na danou vzdálenou stanici. Zdroj 802 dat poskytuje data paketovému síťovému rozhraní 806. Paketové síťové rozhraní 806 přijímá data a směruje data na selektor 816. Selektor 816 potom přenáší data na každou základnovou

89723 (0989723_CZ.doc) 16.12.2006

stanici 820 při komunikaci s cílovou vzdálenou stanicí. V ukázkovém provedení udržuje každá základnová stanice 820 datovou frontu 830, ve které se ukládají data, která se mají přenášet na vzdálenou stanici.

Data se přenášejí v datových paketech z datové fronty 830 do kanálového prvku 826. V ukázkovém provedení na přímém linku „datový paket odkazuje na množství dat, které je maximálně 1024 bitů a množství dat, která se mají přenést na cílovou vzdálenou stanici v předem daném „časovém slotu (jako například «1,667 ms) . Pro každý datový paket vkládá kanálový prvek 826 nezbytná kontrolní pole. V ukázkovém provedení provádí kanálový prvek 826 cyklickou kontrolu redundance (Cyclic Redundancy Check - CRC), kóduje datové pakety a řídicí pole a vkládá sadu bitů uzavírajících kód. Datové pakety, řídicí pole, CRC paritní bity a bity uzavírající kód tvoří formátovaný paket. V ukázkovém provedení potom kanálový prvek 826 kóduje formátovaný paket a prokládá (nebo zaznamenává) symboly do zakódovaného paketu. V ukázkovém provedení se proložený paket překryje Walshovým kódem a rozšíří se krátkými PNI a PNQ kódy. Rozšířená data se poskytnou kvadraticky moduluje, filtruje

VF jednotce 828, která a zesiluje signál. Signál přímého linku se přenáší anténou vzduchem na přímý link.

Na vzdálené stanici je signál přímého linku přijat anténou a směrován na přijímač. Přijímač filtruje, zesiluje, kvadraticky demoduluje a kvantizuje signál. Digitalizovaný signál se přivede na demodulátor (DEMOD), kde se inverzně rozprostře krátkými PNI a PNQ kódy a odkryje Walshovou obálkou. Demodulovaná data se poskytnou dekodéru, který provádí inverzi funkcí zpracování signálu na základnové stanici 820, konkrétně de-interlaving, dekódování a CRC

89723 (0989723_CZ.doc) 16.12.2006 • · · · • ·

- 13 kontrolní funkce. Dekódovaná data se potom poskytnou přijímači dat.

Hardware, jak bylo ukázáno výše, podporuje různé rychlosti přenosu dat, zpráv, zvuku, videa a dalších komunikací přímým línkem. Rychlost dat vysílaných z datové fronty 830 se mění, aby se uzpůsobila změnám v intenzitě signálu a šumu prostředí na vzdálené stanici. Každá ze vzdálených stanic přednostně vysílá signál řízení rychlosti přenosu dat, Data Rate Control - DRC, přiřazený k základnové stanici 820, v každém časovém slotu. DRC signál poskytuje základnové stanici 820 informaci, která obsahuje identitu vzdálené stanice a rychlost, jakou vzdálená stanice přijímá data ze své přidružené datové fronty. Podle toho obvody na vzdálené stanici měří intenzitu signálu a odhadují šum prostředí na vzdálené stanici, aby se určila rychlost přenosu informace, která se má vyslat v DRC signálu.

DRC signál vyslaný každou vzdálenou stanicí se šíří kanálem zpětného linku a je přijímán základnovou stanicí 820 přijímací anténou připojenou k VF jednotce 828. V ukázkovém provedení se DRC informace demoduluje v kanálovém prvku 826 a poskytne se plánovači 812 kanálu, který se nachází v řadiči 810 základnové stanice, nebo v plánovači 832 kanálu, který se nachází v základnové stanici 820. V prvním ukázkovém provedení se plánovač 832 kanálu nachází v základnové stanici 820. V alternativním provedení se plánovač 812 kanálu nachází v řadiči 810 základnové stanice a spojuje selektory 816 s řadičem 810 základnové stanice.

Plánování přenosu v obvodově spínaném systému může zahrnovat proporcionálně rovný algoritmus, ve kterém je pro každého uživatele definována prioritní funkce. Příklad

89723 (0989723_CZ.doc) 16.12.2006

proporcionálně rovného algoritmu je uveden níže. Prioritní funkce může vzít v úvahu požadovanou datovou rychlost pro daného uživatele, typicky funkci kvality kanálu přímého linku k uživateli a propustnost pro uživatele. Kapacita je tedy vyvážena prvním obsloužením těch uživatelů, kteří mají vysoké požadované datové rychlosti ve srovnání s propustností.

Plánování přenosů v paketově spínaném systému vyvažuje podle jednoho provedení kapacitu uživatelským zpožděním. Toky aplikací se přenášejí jako datagramy, což jsou nezávislé, samonosné zprávy přenášené po síti. Doručení datagramu, čas doručení a jeho obsah nejsou obecně zaručeny. Datagramy přidružené k toku stejné aplikace lze ke stejnému uživateli přenášet po různých trasách. Datagramy se v přijímači znovu sestaví. Celkové zpoždění v paketově spínaném systému není fixní, a proto může plánovač využít tohoto rozdílu zpoždění a nastavit zpoždění pro různé uživatele různě, aby se zvýšila kapacita systému. Plánovač může například snížit zpoždění, se kterým se uživatelé setkávají při požadavku dat s nízkou hranicí zpoždění a nebo limity pro změnu zpoždění. Mezi takové aplikace patří mimo jiné VoIP, video atd. Přenosy mohou mít určitý stupeň služby (GoS) nebo QoS požadavků. VoIP komunikace například vyžaduje, aby přicházející pakety měly definovanou latenci nebo ji měli v přípustném rozsahu zpoždění. Proto není žádoucí upřednostňovat ty komunikace nebo aplikace, které mají požadavek na nižší latenci nebo jiné(jiných) GoS specifikace(i). Multimediální konference, streamování videa, prohlížení webu, přenosy Filé transfer protokolem mají své specifické GoS požadavky.

Aby se implementovalo schéma klasifikace priorit, je

89723 (0989723_CZ.doc) 16.12.2006

- 15 každému toku přiřazena prioritní funkce. V jednom provedení může být prioritní funkce (PF) pro paketově spínaný plánovač dána jako:

PF=f(zpoždění) kde f() je funkce a FP se potom určí na základě požadavků na zpoždění od daného uživatele nebo aplikace pro uživatele. PF se vypočte pro každý datagram ve frontě; různé PF se porovnají, aby se určily instance toku s vyšší prioritou. Paketově spínaná komunikace umožňuje do plánování začlenit adaptivní správu zpoždění, dokud není celkové zpoždění dané komunikace fixováno.

Všimněte si, že následující popis se týká cdma2000 sytému, který podporuje vysokorychlostní paketově datové služby (HRPD - high rate packet data), jak je popsáno v IS-856. Tento systém se používá jako příklad. Tento vynález je použitelný také v jiných systémech, ve který se uživatelé pro službu vybírají podle plánovacího algoritmu.

V HRPD systému může vzduchové rozhraní podporovat až 4 paralelní aplikační toky. První tok nese signálovou informaci a další tři lze použít k přenosu aplikací s různými QoS požadavky nebo jiných aplikací.

Následující slovníček je uveden pro jasné pochopení jednoho provedení, které je popsáno dále. Tento slovníček není vyčerpávající. Vynález není slovníčkem omezen, slovníček slouží spíše pro jeho jasnější pochopení s odkazem na jedno provedení komunikačního systému podporujícího adaptivní váhový plánovací algoritmus.

SLOVNÍČEK

Přístupová síť (AN - Access Network) - síťové vybavení

89723 (0989723_CZ.doc) 16.12.2006 • « • ·

• · poskytující datovou konektivitu mezi celulární sítí a paketově spínanou datovou sítí (typicky Internetem) a ATs. Přístupová síť v HRPD systému je ekvivalentní základnové stanici v celulárním komunikačním systému.

Přístupový terminál (AT - Access Terminál) - zařízení poskytující datovou konektivitu uživateli. AT v HRPD systému odpovídá mobilní stanici v celulárním komunikačním systému. AT může být připojen k výpočetnímu zařízení jako je například přenosný osobní počítač nebo může být v samonosném datovém zařízení jako je například Osobní digitální asistent (PDA).

Aplikační tok - vyhrazená přenosová trasa ze zdroje na AT v daném aplikačním toku. Každý aplikační tok je identifikován zdrojem, cílem, profilem trafficu a kvalitou profilu služby.

Aplikační proud - datová komunikace odpovídající aplikaci. Většina aplikačních toků má určenou kvalitu požadavků na službu.

Automatické opakování požadavku (Automatic Repeat Request - ARQ) - mechanismus, kterým vysílač inicializuje opakovaný přenos dat založený na výskytu nebo absenci události.

Průměrná rychlost přenosu dat - průměrná rychlost vstupních dat za čas pro daný aplikační tok.

Shlukování (σ) - míra shlukování nebo hustoty a časová souvislost paketů v aplikačním toku.

89723 (0989723_CZ.doc) 16.12.2006

• · · · · · • · · · · • · · · · · • · · · · ·· ·· ·· ··

- 17 Nejlepší úsilí (BE - best effort) - Aplikační toky, které přijímají vzduchem obecně poměrně velké objemy dat, ale podstata trafficu je taková, že lze tolerovat relativně velká zpoždění, ale míra ztráty dat by měla být extrémně malá.

Řízení rychlosti přenosu dat (DRC - data rate control) mechanismus, kterým AT přenáší požadovanou datovou rychlost na AN.

Deficitní bity (defbits) - množství bitů odpovídající deficitním paketům.

Hranice zpoždění - specifikovaný čas (hranice zpoždění) povolený pro přenos datového paketu z AN na AT.

Urychlené směrování (EF - expedited forwarding) aplikační toky mají typicky malá množství trafficu, který přichází z internetu do přístupové sítě, ovšem podstata trafficu je taková, že by datové pakety měly být doručeny během určité relativně malé hranice zpoždění s rozumnou ztrátou dat.

Přímý link (FL - forward link) - přenosový vzdušný link z AN na AT.

Paket hlavičky řádku (Head of Line - HOL) - první paket ve frontě.

Vysokorychlostní datový paket (HRPD - High Rate Packet Data) - datová služba přenášející paketovou datovou komunikaci vysokou rychlostí přenosu dat. Také označovaná jako vysoká rychlost přenosu dat (HDR - High Data Rate) a

89723 (0989723_CZ.doc) 16.12.2006

'·· ·· ··

- 18 specifikovaná ve standardu IS-856 nazvaném „cdma2000 High Rate Packet Data Air Interface Specification.

Neklid (jitter) - časová prodleva mezi přijatými po sobě jdoucími pakety.

Hranice neklidu - hranice neklidu pro daný aplikační tok.

Motion Pictures Experts Group (MPEG) - protokol pro přenos multimediálních materiálů.

Proporcionální Fair (PF) algoritmus - plánovací algoritmus, ve kterém se datová komunikace plánuje podle výběrového faktoru vypočteného pro každou AT jako poměr požadované rychlosti přenosu dat k propustnosti.

Kvalita služby (QoS - Quality of Service) - požadavky týkající se přenosu paketové datové komunikace, zahrnující mimo jiné zpoždění, požadovanou rychlost a neklid.

Zpětný link (RL) - přenosový vzdušný link z AT na AN.

Přenosová fronta - Přenosová fronta pro ukládání aplikačních toků pro danou BTS.

Mnoho bezdrátových komunikací využívá výhody Internet Protokolu (IP) , aby využily výhody různých Per Hop Behavior (PHB) a různých směrování pro zpracování paketových dat. Obecně je internet tvořen mnoha sítěmi, které jsou tvořeny různými technologiemi linkových vrstev, které při společné práci využívají IP. IP nabízí bezspojovou službu síťové vrstvy, která je předmětem ztráty paketů a zpoždění, které

89723 (0989723_CZ.doc) 16.12.2006

- 19 zvyšuje síťovou zátěž. Základní model IP doručování se označuje jako nejlepší úsilí (BE - Best Effort). Některé aplikace mohou například vyžadovat lepší služby, než jednoduchou BE službu. Například multimediální aplikace mohou specifikovat pevnou šířku pásma s krátkým zpožděním a malým neklidem. Jiným druhem priority je chování směrování odkazované jako zajištěné směrování (AF) , které garantuje úroveň propustnosti.

V QoS managementu existují různá hlediska. Některými činiteli QoS managementu jsou alokace šířky pásma a garantovaná šířka pásma ve sdílených médiích, známých také jako vysílací sítě, např. síť Ethernet nebo bezdrátová Lokální síť (LAN - Local Area Network). Existuje rostoucí poptávka po začlenění bezdrátových prostředků do laptopů a dalších výpočetních zařízení. Bezdrátové sítě jsou ovšem omezeny šířkou pásma a tudíž se zachování kapacity a optimalizace stávají kritickým faktorem.

Obr. 3 ukazuje způsob plánování, který upřednostňuje přenosy založené na stupni služby (GoS - Grade of Service) nebo QoS požadavcích. V AN se data pro přenos ukládají do paměťové jednotky, která je uzpůsobena k ukládání datových front odpovídajících příchozím aplikačním tokům. Fronta se ukládá pro každou instanci aplikačního toku. Podle tohoto vynálezu je aplikační tok rozdělen do dvou instancí, z nichž každá instance je datovým oktetem. Proto může aplikační tok mít, a často má, k sobě přiřazeno více front. Každá fronta má potom přiřazeny požadavky na vysílání a příjem definované v QoS a/nebo GoS prioritním typu. Prioritní typ může být založen například na požadavku na celkové zpoždění nebo některá jiná kvalitativní kritéria. Všimněte si, že dané vysílání může spadat do jednoho z mnoha GoS prioritních

89723 (0989723_CZ.doc) 16.12.2006

- 20 typů. Některé služby například umožňují individuální přenos paketů dat a jejich následné pospojování v přijímači, aniž by došlo ke ztrátě kontinuity, tj . BE prioritního typu. Naproti tomu aplikace navržené pro real-time funkce, jako je například VoIP, mají vysoký prioritní typ a označují se jako prioritní typ urychleného směrování (EF - Expedited Forwarding) . EF prioritní typ zahrnuje aplikace, které mají omezení na hranici zpoždění a proměnlivost zpoždění. V tomto příkladu upřednostňuje plánovač EF komunikaci. QoS nebo GoS prioritní typ může být také uváděn jako QoS třída. Navíc, každá fronta má spolu spojenou senzitivitu. Například EF aplikační tok je typicky citlivý na zpoždění, což znamená, že vysílání EF aplikačního toku má požadavky na zpoždění, které je třeba splnit. V mnoha případech, pokud nejsou požadavky na zpoždění splněny, se data zahodí a nevysílají. Naproti tomu, BE aplikační tok je typicky citlivý na propustnost, což znamená, že vysílání BE aplikačního toku má požadavky na propustnost cíle, ale nemá nezbytně striktní požadavky na EF aplikační tok.

Obr. 3 ukazuje způsob 200 plánování implementující adaptivní správu zpoždění podle jednoho provedení. V AN implementuje plánovač plánovací algoritmus, který poskytuje vysokou rychlost paketových datových přenosů pro více uživatelů. Plánovač kontroluje datovou frontu, aby určil GoS typ pro data. Pokud mají některá data v rozhodovacím kroku 202 daný GoS prioritní typ, tj . prioritní typ definující podrobnější požadavky než BE, pokračuje proces krokem 204, aby našel nej starší data nej vyššího prioritního typu ve frontě. Vyšší prioritní typ, jak se zde používá, označuje GoS prioritní typ definovaný striktnější specifikací. Jeden prioritní typ může například specifikovat hranici zpoždění, zatímco jiný může specifikovat hranici neklidu. V tomto

89723 (0989723_CZ.doc) 16.12.2006 ·· ··*·

- 21 případě se prioritní typ specifikující hranici zpoždění považuje za vyšší prioritu a tudíž se považuje za první.

Podle tohoto provedení plánovač nejprve na základě požadavků na zpoždění přiřadí bity do paketů pro vysílání. Jakmile jsou data s vysokou prioritou naplánována, lze k plánování zbývajících paketů použít jiný algoritmus.

Například pokud jsou data ve frontě, začne plánovač vytvářet pakety pro přenos za použití EF dat. EF data se vyberou na základě doby pobytu dat ve frontě, krok 204. V jednom provedení se k datům v okamžiku jejich vložení do fronty přiřadí časová známka. Plánovač najde EF data s nejstarší časovou známkou a vloží je do paketu jako první. Plánovač potom pokračuje ve vkládání EF dat do paketů podle jejich stáří ve frontě, krok 206. Jakmile byla všechna EF data vložena do paketů pro vysílání, použije plánovač jiný algoritmus pro zbytek dat. V tomto vynálezu použije plánovač proporcionální fair algoritmus na zbytek dat, kterým mohou být data nej lepšího úsilí (best effort) , krok 208. BE data se potom vloží do paketů podle proporcionálního fair algoritmu, krok 210.

Všimněte si, že podmínka kanálu zvyšuje požadavky uživatelů na vysoké datové rychlosti, což má za následek snižování hranice zpoždění. Proto, i když plánovač upřednostňuje EF data, může být hranice zpoždění funkcí podmínky kanálu.

Pro přenos BE dat vybere plánovač paket, aby maximalizoval propustnost. Propustnost se potom obecně vypočte jako:

89723 (0989723_CZ.doc) 16.12.2006

- 22 Propustnost = (bitů na paket)/(slotů na paket).

Podle jednoho provedení, PF může být dán jako:

PF = f(stáří paketu)*g(podmínka kanálu)*h(zátěž buňky), kde se při plánování vysílání uvažuje stáří paketu stejně jako podmínka kanálu a zátěž buňky. Takový výpočet lze použít pro plánování EF dat nebo BE dat.

Opět s odkazem na obr. 2, v jednom provedení plánovač 832 přijímá informace z datové fronty 830, které indikují množství dat, která jsou zařazena do fronty pro každou vzdálenou stanici, také nazývané velikost fronty. Plánovač 832 kanálu potom provede plánování založená na DRC informaci a velikosti fronty pro každou vzdálenou stanici obsluhovanou základnovou stanicí 820. Pokud je velikost fronty požadována pro plánovací algoritmus použitý v alternativním provedení, může plánovač 812 kanálu přijímat informaci o velikosti fronty ze selektoru 816.

V průběhu vysílání paketů k jednomu nebo více uživatelům vysílají uživatelé potvrzovací „ACK signál pokaždé, když je vyslán časový slot obsahující část vysílaného paketu. ACK signál vysílaný jednotlivými uživateli se přenáší kanálem zpětného linku a přijímá se základnovou stanicí 820 pomocí přijímací antény připojené k VF jednotce 828. V jednom ukázkovém provedení se ACK informace demoduluje do kanálových prvků 826 a poskytne plánovači 812 kanálu umístěném v řadiči 810 základnové stanice nebo plánovači 832 základnové stanice umístěném v základnové stanici 820. V prvním ukázkovém provedení se plánovač 832 kanálu nachází v základnové stanici 820. V alternativním provedení se plánovač 812 kanálu nachází v řadiči 810 základnové stanice a propojuje selektory 816 s řadičem 810 základnové stanice.

89723 (0989723_CZ.doc) 16.12.2006 ·· • · · • · • · • · • *· *· a· •a «··* • a · • · * • · ·

Provedení tohoto vynálezu jsou použitelná v jiných hardwarových architekturách, které mohou podporovat různé rychlosti přenosu. Tento vynález je možné snadno rozšířit, aby se pokryly různé rychlosti přenosu na zpětném linku. Například místo určení rychlosti příjmu dat základnovou stanicí 820 založeném na DRC signálu z účastnických stanic, měří základnová stanice 820 intenzitu signálu přijatého ze vzdálených stanic a odhaduje šum prostředí, aby se určila rychlost příjmu dat z účastnické stanice. Základnová stanice 820 potom vyšle každé přidružené účastnické stanici rychlost, kterou se mají přenášet data na zpětném linku ze vzdálené stanice. Základnová stanice 820 potom může plánovat přenosy na zpětném linku na základě různých rychlostí přenosu dat na zpětném linku podobným způsobem, který je zde popsán pro přímý link.

Výše popsané provedení základnové stanice 820 tedy vysílá vybrané nebo vybraným účastnickým stanicím s vyloučením ostatních účastnických stanic přidružených k základnové stanici 820 použitím schémat přístupu s kódovým dělením, CDMA. V kterémkoliv konkrétním čase základnová stanice 820 vysílá na vybranou nebo vybrané účastnické stanice za použití kódu, který je přiřazen přijímající základnové stanici(přijímajícím základnovým stanicím 820. Tento vynález je ovšem také aplikovatelný na jiné systémy využívající různé TDMA (časový multiplex) poskytnutí dat základnové stanici stanicím) 820, s vyloučením ostatních způsoby pro (základnovým základnových stanic 820, aby se vysílací prostředky alokovaly optimálně.

Plánovač přímém linku.

812 kanálu plánuje různé rychlosti přenosu na Plánovač 812 kanálu přijímá velikost fronty,

89723 (0989723_CZ.doc) 16.12.2006

která indikuje množství dat, která se mají přenášet na vzdálenou stanici, a zpráv ze vzdálených stanic. Plánovač 812 kanálu přednostně plánuje datové přenosy, aby se dosáhlo cíle systému tj . maximální datové propustnosti při dodržení omezení rovnosti.

Jak je ukázáno na obr. 1A, jsou účastnické stanice rozptýleny v komunikačním systému a mohou komunikovat se žádnou nebo s jednou základnovou stanicí na přímém linku.

V ukázkovém provedení koordinuje plánovač 812 kanálu přenosy dat přímým línkem v celém komunikačním systému.

Podle jednoho provedení je plánovač 812 kanálu obr. 2 implementován v počítačovém systému, který obsahuje procesor, Random Access Memory, RAM a programovou paměť pro ukládání instrukcí, které se mají provádět procesorem (není zobrazeno). Procesor, RAM a programová paměť mohou být vyhrazeny pro funkce plánovače 812 kanálu. V jiných provedeních mohou být procesor, RAM a programová paměť součástí sdíleného výpočetního prostředku pro provádění dodatečných funkcí na řadiči 810 základnové stanice.

V ukázkovém provedení se v systému 800 zobrazeném na obr. 2 použije obecný plánovač, který je podrobně popsán dále. Jeho moduly, které jsou použity v BSC 810 a BS 820 k implementaci prioritní funkce pro plánování datových přenosů, jsou popsány po uvedení vlastností obecného plánovače.

S rostoucími požadavky na bezdrátové datové aplikace podstatně vzrostla poptávka po velmi efektivních bezdrátových datových komunikačních systémech. IS-95 standard je schopen přenosu dat trafficu a hlasových dat přímým a zpětným línkem. Podle standardu IS-95 se data trafficu nebo hlasová data rozdělí do rámců kódového kanálu,

89723 (0989723_CZ.doc) 16.12.2006 které jsou 20 milisekund široké s rychlostí přenosu dat 14,4 Kbps. V IS-95 systému má každá účastnická stanice alokován alespoň jeden z omezeného množství ortogonálních kanálů přímého linku. Protože komunikace mezi základnovou stanicí a účastnickou stanicí pokračuje, zůstane kanál přímého linku přidělen účastnické stanici. Když se datové služby poskytují v IS-95 systému, zůstávají kanály přímého linku alokovány účastnické stanici i v době, kdy nejsou žádná data přímého linku, která by se měla poslat účastnické stanici.

Podstatný rozdíl mezi hlasovými službami a datovými službami je ve skutečnosti ten, že hlasové služby mají striktní a pevné požadavky na zpoždění. Typicky musí být celkové zpoždění pro hlasové rámce v jednom směru menší než 100 milisekund. V kontrastu s tím může být zpoždění dat proměnlivý parametr, který lze použít k optimalizaci propustnosti datového komunikačního systému.

Jiným podstatným rozdílem mezi hlasovými službami a datovými službami je to, že hlasové služby vyžadují pevně danou a stejnou úroveň služby (grade of Service - GoS) pro všechny uživatele. Typicky pro digitální systémy poskytující hlasové služby se tyto požadavky projevují jako fixní a stejná rychlost přenosu pro všechny uživatele a maximální tolerovatelná chybovost v hlasových rámcích. V kontrastu s tím pro datové služby může být GoS pro každého uživatele jiná a může být optimalizovaným parametrem, aby se zvýšila celková efektivita datového komunikačního systému. GoS datového komunikačního systému je typicky definována jako celkové zpoždění v průběhu předem daného množství dat, které se zde bude dále označovat jako datový paket.

89723 (0989723_CZ.doc) 16.12.2006 • · · · ·· · ······ • · · · · · · · · · · ·· ···· ·· · · · ·· ·

Ještě jiný podstatný rozdíl mezi hlasovými službami a datovými službami je ten, že hlasové služby vyžadují spolehlivý komunikační link, který je v ukázkovém CDMA komunikačním systému poskytnut měkkým předáním. Měkké předání vede k redundantním vysíláním ze dvou nebo více základnových stanic, aby se zvýšila spolehlivost. Tato zvýšená spolehlivost ovšem není vyžadována pro datové přenosy, protože chybně přijaté datové pakety lze přenést znovu. Pro datové služby může být proto vysílací výkon použitý k podpoře měkkého handoff efektivněji využit při přenosu dalších dat.

Zpoždění přenosu požadované k přenosu datového paketu a průměrné rychlosti přenosu jsou tedy dva atributy použité k definici kvality a efektivity datového komunikačního systému. Zpoždění přenosu nemusí mít stejný účinek v datovém komunikačním systému a hlasovém komunikačním systému, ale je měřítkem pro měření kvality datového komunikačního systému. Průměrná rychlost přenosu dat je měřítkem efektivity schopnosti přenosu dat v komunikačním systému. V technice tedy existuje potřeba po komunikačních systémech, které poskytnou zlepšenou datovou propustnost a zároveň poskytnou GoS, která je vhodná pro všechny typy služeb poskytované v bezdrátovém kanálu.

Potřeba obecného plánovače je založena na požadavcích a cílech datového přenosu v bezdrátovém komunikačním systému. Pro datové přenosy je propustnost definována pomocí zpoždění, která se vyskytují při přenosech paketů dat, raději než pomocí jednotlivých bitů nebo bytů. Datový paket, jako například Internet Protokol, IP datagram je nedělitelná jednotka, ve většině případů přijetí pouze části paketu neobsahuje pro uživatele dostatečnou informaci, aby jej mohl

89723 (0989723_CZ.doc) 16.12.2006

uživatel dekódovat a použít, takový paket je tedy pro uživatele bezcenný. Koncový uživatel přijme datový paket, provede cyklický test redundance (CRC) datového paketu a zpracuje data. Proto je pro uživatele nejdůležitější okamžik příchodu posledního bitu datového paketu a není pro něj důležité zpoždění jednotlivých bitů datového paketu. To umožňuje značnou flexibilitu v nastavení rychlostí přenosu dat pro jednotlivé uživatele v časových měřítcích menších, než je doba přenosu jednoho datového paketu. Navíc jsou ve spojení typu Transmission Control Protokol, TCP, přijatelné určité odchylky ve zpožděních datových paketů, dokud není tato odchylka tak nepředvídatelná, že způsobuje zbytečné opakované TCP přenosy.

Jinou vlastností bezdrátového kanálu je proměnlivost kanálu samotného. V systému typu HDR tato variabilita vede k proměnlivosti požadované rychlosti v průběhu času. Aby se maximalizovalo využití kanálu, je navržen plánovač tak, aby sloužil uživatelům s vysokou rychlostí přenosu dat, tj. uživatelům požadujícím vysokou rychlost přenosu dat. To občas znamená, že uživatelé nemusí být obslouženi v době, kdy jsou jejich požadované rychlosti přenosu nižší. Celková propustnost bude maximalizována, když plánovač delší dobu neslouží uživatelům s nízkou rychlostí přenosu dat. Ideálně toto ovšem plánovač vyvažuje požadavky na zpoždění paketů a odchylky zpoždění tak, aby byly relativně konzistentní, jak je vysvětleno výše.

Jiný aspekt se týká rovného přístupu k více uživatelům v systému. Aby se dosáhlo spravedlivého způsobu plánování, distribuuje plánovač ideálně celkovou propustnost mezi různé uživatele. Různé základny a rovnosti (nebo povolené nerovnosti) se používají různými systémy, aby se ovlivnily

89723 (0989723_CZ.doc) 16.12.2006 «· · * ·· · ······ • · · ···· ·· · ·· ··· ··· • · ···· ·· · · · ·· · požadavky a potřeby jednotlivých systémů. Koncept rovnosti je klíčovým konceptem v mnoha plánovacích algoritmech. Rovnost poskytuje různou míru flexibility v obsluhování různých uživatelů tudíž má dopad na celkovou propustnost v sektoru.

Podle jednoho provedení se způsob a zařízení pro plánování přenosů v komunikačním systému s použitím ve více třídách uživatelů zahrnuje obecný plánovač. Obecný plánovač vyhovuje různým prioritám plánování. Různé třídy uživatelů se specifickými požadavky na přenos jsou obsluhovány obecným plánovačem, který udržuje vysokou propustnost pro všechny uživatele.

V jednom provedení implementuje činnost obecného plánovače prioritní funkci míry podmínky kanálu a kritéria rovnosti, kde prioritní funkce je definována jako:

f (Ai(t),Ui(t)), kde Ai(t) je míra stavu kanálu a Ui(t) je míra rovnosti uživatelů. Funkce Ai(t) specifikuje vhodnost obsloužení uživatele i v čase t na základě aktuálního stavu kanálu. Funkce Ui(t) specifikuje vhodnost obsloužení uživatele i v čase t na základě historie služeb přijatých v minulosti. Prioritní funkce f() kombinuje dvě míry vhodnosti, Aj.(t) a Ui(t), aby se určila úroveň priority pro každého uživatele.

Podle jednoho provedení obsluhuje obecný plánovač uživatele s nejvyšší prioritní funkcí f (Ai (t),Ui (t) ) v dané třídě nebo typu uživatelů. V ukázkovém provedení se hodnota daná prioritní funkcí f (Ai (t) , U (t) ) s rostoucí funkcí Aj.(t) stavu kanálu zvyšuje a s rostoucí funkcí Ui(t) rovnosti snižuje. Funkce Ai(t) a Ui(t) se určí odpovídajícím způsobem. Navíc, prioritní funkce f () je funkcí alespoň jedné časové

89723 (0989723_CZ.doc) 16.12.2006

periody, během které se měří míra stavu kanálu a míra rovnosti uživatelů. V alternativním provedení může být prioritní funkce časově závislá pro každého uživatele. Pro jednoduchost může ovšem plánovač používat propojovací funkci společnou pro všechny uživatele a modifikovat míru rovnosti, aby odrazil požadavky uživatelů.

Obecná třída víceuživatelských plánovačů kategorizuje uživatele přijímající služby z AN do alespoň dvou širokých kategorií, BE a EF. Lze také implementovat další kategorie přenosů, jako například AF atd. BE a EF jsou takové, jak jsou definovány zde. Konkrétně BE (nej lepší úsilí - Best effort BE) aplikace mají obecně relativně velký objem dat, který se přijímá vzduchem, ale podstata trafficu je taková, že lze tolerovat relativně velká zpoždění, ale ztráty dat by měly být extrémně malé; aplikační toky očekávaného směrování (EF - expected forwarding) mají typicky malý objem trafficu, který přichází z internetu do přístupové sítě, ovšem podstata tohoto trafficu je taková, že se datové pakety mají doručit uživateli v určitém relativně malém rozmezí zpoždění s rozumnou mírou ztráty dat.

V paketovém datovém systému, jako například lxEV-DO, má plánovač flexibilitu umožnit různá zpoždění pro jednotlivé uživatele, aby se maximalizovala kapacita. Jako kapacita se zde označuje propustnost pro BE uživatele a počet obsloužených uživatelů s přijatelnou propustností v případě trafficu citlivého na zpoždění, jako například VoIP (EF uživatelé).

Obecně se v lxEV-DO se zvýšením hranice zpoždění pro uživatele zvýší využití FL, čímž se zvýší BE a EF kapacita systému. Toto zvýšení kapacity vychází z různých faktorů,

89723 (0989723_CZ.doc) 16.12.2006

které zahrnují, ale neomezují se na, vyšší efektivitu paketování a schopnost a schopnost využít lokálního stavu kanálu a zisku z různorodosti uživatelů.

V případě čistého BE trafficu je typický plánovač proporcionálně rovný (PF - proportional fair) plánovač. Tento plánovač je proporcionálně rovný v tom smyslu, že propustnost poskytnutá jednotlivým uživatelům je přibližně proporcionální ke geometrii uživatele, tj . průměrnému stavu kanálu. Proporcionálně rovný plánovač byl vybrán jako plánovač pro čistý BE traffic kvůli svému přínosu propustnosti k rovným kompromisům. Navíc, PF algoritmus byl navržen tak, aby poskytnutí zisku plánovač, jak se využil lokálních špiček kanálu při z různorodosti uživatelů. Takový PF zde používá, se bude označovat jako proporcionálně rovný plánovač propustnosti.

Všimněte si, že v případě čistého BE-trafficu, je zde další třída plánovačů: plánovač „stejné úrovně služby. Tento plánovač se snaží poskytnout stejnou propustnost všem uživatelům. Z tohoto důvodu určuje kapacitu systému nejslabší uživatel. Ačkoliv je plánovač stejné úrovně služby v některých aplikacích žádoucí, nevyužívají takové plánovače obvykle vzdušný link efektivně. Tyto plánovače se zde označují jako „plánovače stejné propustnosti.

Plánovače PF propustnosti a plánovače stejné propustnosti popsané výše jsou užitečné v kontextu čistého BE-trafficu. Pro EF-traffic citlivý na zpoždění nemusí být tyto plánovače efektivní, protože chybí mechanismus pro kontrolu zpoždění.

Následuj ící text představuje plánovací prostředky a

89723 (0989723_CZ.doc) 16.12.2006

způsoby citlivé na zpoždění, které mohou pracovat s oběma přístupy pro čistý BE-traffic, např. PF plánovač propustnosti a plánovač stejné propustnosti. V případě trafficu citlivého na zpoždění se „proporcionální versus „stejná rovnost nepoužívá jenom na propustnopst poskytnutou jednotlivým uživatelům, ale také na propustnost „zpoždění poskytnutou jednotlivým uživatelům. Propustnost zpoždění lze kvantifikovat pomocí průměrného zpoždění nebo váhy zpoždění atd. Všimněte si, že různá provedení mohou mít BE a EF plánování začleněny do společného způsobu při splnění požadavků na propustnost a citlivost na zpoždění.

V jednom provedení lze poskytnout přibližně stejné zpoždění všem uživatelům. Tento přístup je podobný stejné propustnosti a pro symetrii terminologie se označuje jako „plánovač se stejným zpožděním. Plánovač se stejným zpožděním se snaží poskytnout stejnou propustnost všem uživatelům, a proto lze kapacitu systému určit podle uživatelů s nej slabším pokrytím. Plánovače zpožděním se pokouší poskytnout stejnou zpoždění, jako například střední zpoždění nebo stejná váha zpoždění všem uživatelům a tudíž se kapacita systému určuje podobně pro uživatele s nej slabším pokrytím.

se stejným propustnost

V jiném provedení je propustnost zpoždění poskytnuta uživateli proporcionální průměrné geometrii uživatele. Tento přístup je podobný proporcionálně rovnému plánovači propustnosti a je označován jako „plánovač s proporcionálně rovným zpožděním. Plánovač s proporcionálně rovnou propustností se pokouší poskytnout propustnost jednotlivým uživatelům proporcionálně k jejich průměrné geometrii, čímž podstatně zvyšuje kapacitu systému ve srovnání s plánovačem s rovnou propustností. Podobně bude plánovač

89723 (0989723_CZ.doc) 16.12.2006

s proporcionálně rovným zpožděním poskytovat propustnost zpoždění jednotlivým uživatelům proporcionálně k průměrné geometrii uživatele, čímž se maximalizuje EF kapacita.

Na obr. 4 jsou zobrazeny čtyři kategorie plánování paketů. Každá kategorie je znázorněna s rovnováhou QoS uvažování. Konkrétně plánovač PF propustnosti vyvažuje řízení propustnosti s proporcionální rovností. Plánovač se stejnou propustností vyvažuje řízení propustnosti se stejnou rovností. Plánovač PF zpoždění vyvažuje řízení zpoždění s proporcionální rovností. Plánovač se stejným zpožděním vyvažuje řízení zpoždění se stejnou rovností.

Zatímco některé způsoby plánování jsou užitečné v obvodově spínaných systémech, jiné mohou být vhodnější pro paketové datové systémy, jako například lxEV-DO. Zde prezentované plánovací prostředky a způsoby proporcionálně rovného zpoždění mohou být výhodou paketově spínaných systémů nad obvodově spínanými systémy.

Navíc, aby se zvýšila kapacita systému, může plánovač s PF zpožděním zvyšovat zkušenost uživatelů. Například uživatelé v blízkosti BSs budou pravděpodobně přijímat lepší propustnost zpoždění než uživatelé dále od BSs. To je v kontrastu se zpožděním, které nezávisí na vzdálenosti k AN. Navíc pro uživatele s vysokou geometrií v blízkosti BS může být propustnost předvídatelná s vysokou úrovní spolehlivosti, zatímco pro plánovač se stejným zpožděním může být propustnost v závislosti na aktuální zátěži systému nepředvídatelná. Proto je pro plánovač žádoucí zajistit, aby kvalita služby rostla s nárůstem geometrie jednotlivých uživatelů.

89723 (0989723_CZ.doc) 16.12.2006

Plánovač, který slouží jak BE, tak EF uživatelům může využívat odpovídající kombinace proporcionálně rovné propustnosti a plánování zpoždění. Takový plánovač může být označován jako „plánovač s proporcionálně rovnou propustností/ zpožděním. Všimněte si, že v jednom provedení je plánování s proporcionálně rovnou propustností/ zpožděním implicitně založeno na relativních geometriích uživatelů obsloužených v jednom sektoru. To se odkazuje jako „rovnost uvnitř sektoru. Jiným problémem, který je třeba brát v úvahu při návrhu plánovače je rovnost uvnitř buňky, kterou lze popsat jako průměrnou úroveň služby, kterou lze kvantifikovat pomocí propustnosti poskytnuté BE uživatelům a průměrného zpoždění poskytnutého EF uživatelům atd., poskytnutého různými sektory uživatelům obsluhovaným těmito sektory.

Abychom pokračovali s proporcionálně rovnou s proporcionálně rovným v analogii mezi plánovačem propustností a plánovačem zpožděním, všimněte si, že propustnost poskytnutá jednotlivým BE uživatelům sektorem, který používá plánovač s proporcionálně rovnou propustností, s rostoucím počtem uživatelů obsloužených sektorem klesá. Rovnost uvnitř sektoru ovšem zůstává zachována. Podobně, propustnost zpoždění poskytnutá jednotlivým EF uživatelům, poskytnutá sektorem, který využívá proporcionálně rovný plánovač zpoždění, může vzrůst, jestliže vzroste počet uživatelů obsloužených sektorem.

Plánovač s proporcionálně rovnou propustností/ zpožděním využívá rozhodovací metriku v následující formě, aby rozhodl, kteří uživatelé mají být obsloužení při kterémkoliv plánovacím rozhodnutí:

RozhodovacíMetrika = f (StáříPaketu, StavKanálu,

89723 (0989723_CZ.doc) 16.12.2006

ZátěžSektoru) , kde StáříPaketu označuje rozdíl mezi aktuálním časem a odpovídající časovou známkou definovanou pro každý paket při čekání ve frontě základnové stanice, stav kanálu označuje kvalitu radiového linku mezi BS a AT a ZátěžSektoru označuje objem a profil celkového trafficu obsluhovaného sektorem v krátkém časovém intervalu v okolí aktuálního časového okamžiku. Funkce f () závisí na konkrétní implementaci plánovače. Rozhodovací metrika může také záviset na bitové metrice, paketové metrice, datagramové metrice nebo jakýchkoliv jiných prostředcích poskytujících plánovači způsob výběru instance přenosu.

Informace o stavu kanálu lze začlenit do plánovače různými způsoby. Například v plánovači s proporcionálně rovnou propustností se používá Řízení rychlosti přenosu dat/ průměrná propustnost, které dosahuje maxima při lokálních maximech kanálu. Jiný přístupem by bylo použít DRC/AvgDRC, ale při použití může upřednostňovat uživatele s velkými fluktuacemi kanálu. Jinou možností by mohlo být také použití zpětnovazební smyčky, pro indikaci jistého percentilu špiček kanálu. Jedna taková smyčka 300 je zobrazena na obr. 5.

Jedno provedení, jak je zobrazeno na obr. 5, je smyčka 300 navržená tak, aby určila přijatelnou kvalitu kanálu vzhledem k prahu. Vstup, IDRC je funkce nebo index DRC hodnoty, např. rostoucí funkce rychlosti spojená s DRC, kde IDRC roste tak, jak se zvyšuje požadovaná rychlost přenosu dat. IDRC se poskytne komparátoru 302 a filtru 306 s nekonečnou impulsní odezvou (IIR). V jednom příkladu se časová konstanta nastaví na ls, lze ovšem implementovat také alternativní časové konstanty. Filtrovaný výstup IIR filtru 306 se poskytne sumační jednotce 312, která poskytne

89723 (0989723_CZ.doc) 16.12.2006

prahovou hodnotu komparátoru 302. Komparátor 302 porovnává IDRC s prahem. Výsledek porovnání určuje, zda je kvalita kanálu přijatelná nebo ne. Systém určí cílový podíl času, kdy je kvalita kanálu přijatelná. V tomto vynálezu je cíl nastaven na 30 %. Cíl je proměnlivý a lze jej nastavit za provozu. Alternativní systémy mohou implementovat jiné cílové hodnoty nebo schémata. Výstupem komparátoru 302 je binární hodnota {1,0}, kde 1 indikuje přijatelnou kvalitu kanálu a 0 je nepřijatelná, tj. pod prahem.

Pokračujeme s obr. 5, výstup komparátoru 302 se poskytne IIR filtru 304, přičemž v tomto příkladu je časová konstanta nastavena na 0,5 s. Lze implementovat alternativní časové konstanty. Filtrovaný výstup z IIR filtru 304 se přivede na komparátor 310 pro porovnání se vstupní hodnotou, v tomto příkladu je vstupní hodnota 0,3. Pokud je výsledek porovnání nad uvedenou vstupní hodnotou, poskytne se signál up/dn akumulátoru 308, aby se zvýšil práh pro určení kvality kanálu. To indikuje, že indikátor kvality kanálu z komparátoru 302 je 1 ve více než 30 %. Pokud je jinak porovnání pod vstupní hodnotou, ukládá signál poskytnutý up/dn akumulátoru 308 zvýšení prahu. Výstup up/dn akumulátoru 308 je poskytnut sčítací jednotce 312. Sčítací jednotka 312 sčítá výstupy up/dn akumulátoru 308 a IIR filtru 306, kde vstup z IIR filtru 306 poskytuje obecné předpětí pro práh pro komparátor 302. Výsledek sčítání se poskytne komparátoru 302. Indikátor odhadu kanálu se vezme z výstupu komparátoru 302. Tímto způsobem udržuje plánovač indikátor odhadu kanálu nebo informaci o stavu kanálu, aby se identifikovalo procento dobrých časů, kdy je stav kanálu dobrý, tj. špiček kanálu.

ZátěžSektoru může být začleněna do plánovače měřením

89723 (0989723_CZ.doc) 16.12.2006

míry BE a EF toků. Nakonec aktuální rozhodovací metrika použitá plánovačem nemusí explicitně obsahovat měření StavuKanálu a ZátěžeSektoru. Požadovaná HraniceZpoždění na uživatele může být adaptivně vybrána měřením podílu EF uživatelů, kteří nemusí splňovat své hranice zpoždění pro určitý podíl přenesených IP paketů.

Parametr použitý některými plánovači se označuje jako „QoS index třídy toku, který definuje relativní prioritu pro tento tok. Existuje mnoho způsobů, kterými lze určit QoS třídy. V rámci dané QoS třídy mají různé toky velmi různé typy trafficu. QoS index třídy je indikátorem pro požadovanou úroveň priority tokem a není indikátorem statistického chování trafficu.

V jednom provedení je QoS index třídy nezáporná hodnota integer vybraná z plánovače, aby poskytla vyšší prioritu tokům s vyššími QoS indexy třídy. Zde QoS index třídy 0 odpovídá BE/AF tokům; kde BE toky jsou speciální případy AF toků, kde minimální požadovaná hodnota propustnosti je nastavena na nulu. QoS indexy třídy 1 a vyšší odpovídají EF tokům.

Všimněte si, že QoS třídy mají vyšší prioritu; ovšem BE data nebudou nezbytně plánována pro přenos po přenesení všech EF dat čekajících ve frontách. Jako příklad může plánovač plánovat víceuživatelský paket, aby přenášel množství EF bitů, které dosahují deadline. Ve stejné instanci přenosu může plánovač také obsahovat BE data od uživatelů kombatibilní s DRCs, tj. přenosové formáty a zároveň neobsahuje EF bity od uživatelů s nekompatibilními DRCs.

89723 (0989723_CZ.doc) 16.12.2006

QoS tok lze přibližně charakterizovat třemi parametry: (1) rozdělením velikostí IP datagramu, (2) rozdělením délek intervalů mezi příchody IP datagramů a (3) hranicemi zpoždění vztahujícími se k časové známce IP datagramu po které se obsah datagramu stane nepoužitelným.

Pro BE/AF toky je hranice zpoždění mnohem méně tvrdá, než pro EF toky, takže se nebude uvažovat pro BE/AF toky, kde AF znamená zajištěné přímé toky. Pro EF toky se stejnou hranicí zpoždění ale různým rozdělením velikostí IP datagramů a intervalů mezi jejich příchody, je plánovač navržen jako převážně lineární. Například daný tok se stejnou hranicí zpoždění a rozdělením velikostí paketů jako VoIP tok, ale mající poloviční rozdělení intervalů mezi příchody paketů, se bude chovat přibližně stejně jako dva VoIP toky. Podobně, tok se stejnou hranicí zpoždění a rozdělením intervalů mezi příchody paketů, ale dvojnásobným rozdělením velikostí datagramů, se bude vůči plánovači chovat přibližně stejně jako dva VoIP toky. Neceločíselné násobky velikostí paketů a časů mezi příchody lze snadno předvídat jako agregace základních „jednotkových typů toků.

Hranice zpoždění má ovšem podstatně jiný efekt na plánovač, než velikost datagramu a rozdělení intervalů mezi příchody datagramů. Plánovač zpracovává toky s nižšími hranicemi zpoždění s vyšší prioritou. V určitém smyslu je nastavení hranice toku na nižší hodnotu měkkou cestou jak zvýšit její QoS index třídy.

Jak bylo popsáno výše, plánování přenosů se týká řízení přístupu, kde řízení přístupu určuje, kdy je uživatel nebo tok přijat pro zpracování a plánování potom určí, kdy a jak se takové toky přenesou. Jinými slovy, kontrola přístupu

89723 (0989723_CZ.doc) 16.12.2006

A * » « ·· · · · · určuje, která data budou oprávněná pro zahrnutí do instance přenosu, a plánování potom určí konkrétní data, formáty a pořadí vysílacích instancí. Proto může činnost plánovače ovlivnit přístupová řídicí schémata použitá v daném systému.

Podle jednoho provedení se s rostoucí zátěží systému typicky BE/AF toky plánují tak, že každý je degradací ovlivněn přibližně stejně. Pro EF toky je ovšem degradace nevyrovnaná. Podrobněji, nižší QoS třídy se degradují jako první v pokusu o udržení správné funkce vyšších QoS tříd. V dané EF QoS třídě a při ignorování rozdílů v nastavení hranice zpoždění se uživatelé s nižšími geometriemi sníží, aby mohlo co nejvíce uživatelů přijímat požadovanou propustnost. Cílem tohoto přístupu je maximalizovat počet podporovaných EF uživatelů. Pro homogenní EF toky se EF uživatelé degradují nevyrovnaně od uživatelů s nejnižší geometrií k uživatelům s vyšší geometrií. Tento přístup má několik důsledků, které jsou ošetřeny mimo plánovač, podrobněji zpracováním řízení přístupu. Některé z těchto důsledků jsou vysvětleny v následujících příkladech.

Tato funkcionalita plánovače je zobrazena na obr. 6, ve kterém jsou toky zobrazeny v pořadí podle geometrie, která roste směrem doprava. S danou aktuální zátěží systému dává plánovač nižší prioritu uživatelům s nižší geometrií, aby maximalizoval množství QoS toků přijímajících požadovanou QoS. Úroveň uživatelů s nízkou geometrií se šíří doprava s rostoucím přetížením. Plánovač snižuje služby přijaté takovými uživateli tím, že jím dává nižší prioritu. Není ovšem zodpovědné zcela odejmout tok, který by byl typicky funkcí řízení přístupu a jiných bloků monitorování propustnosti.

89723 (0989723_CZ.doc) 16.12.2006 * 4 ·« • » • · • · • · ·· ·

»···

·· · · • · · t · · · • · · ··« ·· • · ··· 4

- 39 Uvažujme situaci, kdy všichni uživatelé máji jeden tok a stejnou QoS třídu, jako například VoIP tok, a uživatel s nejvyšší geometrií požádá o EF tok s velmi vysokou propustností. Plánovač může alokovat všechny FL sloty uživateli s nejvyšší geometrií, i když to znamená, že ostatní uživatelé nemohou mít žádné přenosy. Obecně je rozhodnutí připuštění toku provedeno zpracováním řízení přístupu, které uvažuje aktuální zátěž systému. Když řízení přístupu povolí tok, provede plánovač jakoukoliv základní funkcionalitu a alokuje všechny FL sloty tomuto uživateli. Všimněte si, že omezení uživatelů s nižší geometrií neznamená nezbytně, že plánovač maximalizuje počet EF uživatelů s přijatelnou příjmovou propustností. Plánovač může tento počet maximalizovat, pokud všichni uživatelé mají stejné QoS parametry a stejný typ trafficu (např. pouze VoIP).

Pokud uživatelé s nízkou geometrií, jejichž služba byla plánovačem omezena kvůli mírnému přetížení, požadují velmi nízkou propustnost (např. 1 byte za sekundu), nemusí plánovač přidělit tomuto uživateli požadovanou propustnost, i když by to neovlivnilo propustnost FL. Opět je zodpovědností řízení přístupu předvídat činnost plánovače vzhledem k uživateli s uvážením aktuální zátěže systému. V tomto případě může řízení přístupu přinutit plánovač poskytnout službu tomuto uživateli zvýšením jeho indexu QoS třídy.

Pro následující popis uvažujme homogenní EF traffic jako scénář, ve kterém jsou všichni uživatelé EF uživatelé se stejným modelem trafficu. Plánovač nejprve vytvoří seznam kandidátských instancí přenosu pro sadu jednouživatelských a víceuživatelských vysílacích formátů. Jednouživatelské

89723 (0989723_CZ.doc) 16.12.2006

formáty se plní bity z odpovídajících uživatelských front. Víceuživatelské formáty se plní bity z front uživatelů s kompatibilními DRCs.

Plánovač pak přiřadí paketovou metriku každé z kandidátských instancí a zvolí kandidátskou přenosovou instanci odpovídající největší paketové metrice. Paketová metrika může být „prostupnost polynomiální, kde operace porovnání je definována jako „lexikální porovnání poskytující dobře definovanou maximalizaci.

Uvažujme paketovou metriku pro speciální případ, kde všichni uživatelé jsou EF uživatelé a každý uživatel má jeden EF tok stejného typu, např. systém pouze-VoIP a víceuživatelský přenosový formát, kde pro vytvoření instance víceuživatelského přenosu pro tento formát se bity hromadí z front uživatelů s kompatibilními DRC. Mezi těmito uživateli se bity vyberou na základě časové známky odpovídajících IP datagramů na základě principu FIFO (firstin first-out). Hranice zpoždění se pro tento příklad předpokládají stejné. Mezi bity se stejnými časovými známkami proběhne výběr v pořadí IP paketů a mezi různými uživateli, výběr se provede tak, aby se minimalizoval počet uživatelů, kteří mají data v paketu.

Polynom užitečných dat instance přenosu může být dán jako:

p(x) = B_Dz'^D + BD-1Z’^D+1 + ... + Bi?/¹ + Bo kde B_n představuje počet bitů obsažený v kandidátské instanci přenosu způsobující zpoždění n slotů. Hodnota D může být rovná hranici zpoždění, protože bity lze vzít z fronty, když byly takové bity uloženy ve frontě po dobu překračující hranici zpoždění a tudíž způsobují více než D

89723 (0989723_CZ.doc) 16.12.2006

- 41 slotů zpoždění.

Polynom propustnosti se získá filtrací a převzorkováním zátěžového polynomu. Jedním způsobem je segmentace vektoru koeficientů zátěžového polynomu do N skupin a následné sečtení koeficientů v rámci každé skupiny, aby se získala kondenzovaná reprezentace zátěžového polynomu. Polynom propustnosti se potom získá vydělením kondenzovaného zátěžového polynomu předpokládaným počtem slotů pro kandidátskou instanci přenosu, která se má dekódovat všemi zájemci. Tato procedura je znázorněna na obr. 7, kde horní řada je zátěžový polynom p(x) a spodní řada c(x) je kondenzovanou reprezentací zátěžového polynomu. Proměnná x je index instance přenosu.

Polynom propustnosti je dán jako:

T (z) = c (z) /N_g kde N_g je „obecné rozpětí přicházející v úvahu pro přenosový formát a způsob jeho výpočtu je popsán níže. Výsledný polynom propustnosti se potom použije v paketové metrice při výběru kandidátské instance přenosu z množiny různých alternativ, z nichž každá se získá podobně.

Všimněte si, že shora popsaná paketová metrika navrhuje kompromis mezi prosazením zpoždění a propustností. Pokud se N-l zvolí rovno D, potom pokud c (x) = p(x), vynutí paketová metrika přenos bitů způsobujících největší zpoždění jako první. Dále se při výběru kandidátské instance přenosu zvolí bity způsobující nejbližší největší zpoždění. To je výsledkem „lexikálního porovnání používaného při porovnání paketových metrik (tj . polynomů propustnosti). Tímto způsobem začne porovnání identifikací nejvyššího řádu každého polynomu. Pokud je jeden polynom vyššího řádu, potom

89723 (0989723_CZ.doc) 16.12.2006

se polynom definuje jako větší polynom. Pokud mají oba stejný řád, pak se postupně porovnají koeficienty od nejvyššího řádu a jakmile je v jednom polynomu nalezen vyšší koeficient, pak se tento polynom definuje jako větší polynom.

Segmentace koeficientů p(x) pro získání c(x) implicitně ignoruje rozdíly ve způsobeném zpoždění odpovídající bitům v každém segmentu. Zato je nyní maximalizace propustnosti flexibilnější. Nejvyšší flexibility v maximalizaci propustnosti se dosáhne, pokud se všechny koeficienty p(x) zkombinují v jediném segmentu (např. c(x) nulového řádu).

V jednom příkladu dávají dva segmenty (např. c(x) prvního řádu) kompromis. Největší vliv má člen nejvyššího řádu. Pokud je zde vazba mezi různými kandidátskými instancemi, potom se zohledňují členy c(x). Proto není nezbytné segmentovat koeficienty p(x) do více než dvou segmentů. To vede k optimalizaci jednoho parametru, který budeme označovat a a nazveme jej „zlomek zpoždění. Celkově se dvěma segmenty c(x) = (hi2)z-l + (hi) , kde „hi2 a „hi jsou počty bitů v každém segmentu. Konkrétně hi2 je počet bitů obsažený v kandidátské instanci přenosu způsobující zpoždění více než α-krát větší než hranice zpoždění a „hi je počet bitů způsobujících menší zpoždění.

Pro případ uživatelů s veškerým EF trafficem, ale různými modely trafficu (např. různými hranicemi zpoždění), se argument modifikuje. Bity s menší hranicí zpoždění jsou částí hi2 segmentu dříve než bity s větší hranicí zpoždění. Přirozenou cestou jak toho dosáhnout je použití β-násobku zpoždění proti samotnému zpoždění při ukládání bitů do kandidátské instance přenosu a při určení, kdy se bity

89723 (0989723_CZ.doc) 16.12.2006 stanou částí hi2 převodu.

Obecně je β navrženo jako proporcionální k jedna lomeno hranice zpoždění. Výsledkem toho je, že EF bity s nižší hranicí zpoždění budou směřovat k nižší prioritě nad EF bity s vyšší hranicí zpoždění.

Obr. 8 ukazuje plánovač podle Plánovač 600 obsahuje jednotku 602 jednoho provedení, adaptivního řízení zpoždění připojenou k paměťové jednotce 604 uzpůsobenou pro ukládání udržování informací frontě.

Paměťová jednotka 604 ukládá také informace týkající se každé fronty, včetně zpoždění a/nebo výstupní senzitivity, prioritní třídy, jako například EF, BE atd a dalších informací, které mohou být uloženy do Data fronty informace.

plánovače, jako například QoS a informace uložené v paměťové jednotce 604 poskytnuté jednotce 608 výpočtu bitové metriky a jednotce 606 výpočtu bitové vyrovnávací metriky. Tyto jednotky generují bitovou metriku a bitovou vyrovnávací metriku. Vypočtená bitová metrika se poskytne jednotce 608 výpočtu bitové metriky, jednotce 616 výpočtu paketově metriky a jednotce 610 výběru fronty. Bitová vyrovnávací metrika a vybrané fronty se poskytnou generátoru 612 kandidátské instance přenosu. Paketová metrika z jednotky 616 výpočtu paketově metriky a sada kandidátských instancí přenosu generovaných generátorem 612 se poskytne jednotce 614 výběru instance přenosu.

Obr. 9 zobrazuje paměťovou jednotku 604 pro ukládání mnoha front s čekajícími daty. Data fronty se pro každý tok ukládají jako data fronty 620. Každá fronta 620 má odpovídající QoS třídu nebo prioritní třída 622 a indikátor 624 senzitivity.

89723 (0989723_CZ.doc) 16.12.2006

Obr. 10 je vývojový diagram ilustrující způsob plánování podle jednoho provedení. Způsob 500 nejprve v rozhodovacím kroku 502 určí, jestli je FL zaneprázdněn, tj. jestli je dostupný časový slot pro vysílání nového paketu. Jestliže je dostupný slot pro vysílání nového paketu, vygeneruje plánovač seznam kandidátských instancí přenosu na základě podmnožiny definovaných a odvozených formátů přenosu v kroku 504. Metrika paketů odpovídající každé kandidátské instanci přenosu se vypočte v kroku 506. V kroku 508 plánovač vybere instanci přenosu s nejvyšší hodnotou pro paketovou metriku. V kroku 510 se instance přenosu naformátuje pro přenos.

Obr. 11 ukazuje jedno provedení pro generování množiny kandidátských instancí přenosu a implementaci kroku 504 ve způsobu 500. V kroku 520 plánovač vypočte bitovou metriku pro každý záznam ve frontě. V kroku 522 plánovač vypočte bitovou vyrovnávací metriku pro každou frontu. Hodnoty bitové metriky se porovnají, aby se vybrala sada front pro instanci přenosu, krok 524. Bitová vyrovnávací metrika se použije k vygenerování kandidátských instancí přenosu za použití sady front, krok 526. Příklady způsobů a prostředků pro takové výpočty a porovnání jsou uvedeny dále.

Všimněte si, že se v jednom provedení kandidátská instance přenosu s jednouživatelským formátem vygeneruje pro každého uživatele, který má čekající data. Vysílací formát se nastaví do kanonického formátu, který odpovídá uživatelovu DRC. Pro uživatele, od kterých byla přijata NULL DRC se kandidátská instance přenosu vytvoří pouze pokud má uživatel čekající „EF data. Pro BE/AF uživatele se NULL DRC neobslouží, protože tito uživatelé udržují nízkou četnost

89723 (0989723_CZ.doc) 16.12.2006 • · zahazování ve vrstvě Radiového vrstvového protokolu (RLP Rádio Layer Protocol).

Kandidátská instance přenosu s víceuživatelským formátem se vygeneruje pro každý definovaný a odvozený „kanonický víceuživatelský formát. K povolení odvozených formátů v tomto stavu lze použít příznak.

Všimněte si, že sada kandidátských instancí přenosu vygenerovaná v kroku 506 je založena na „kanonických formátech. Krátké pakety tedy nejsou v tomto kroku obsaženy. Účelem je pomoci přemostit plánovač k uživatelům s vyšší geometrií a zabránit uživatelům s nízkou geometrií ve zneužívání krátkých paketů a tedy snižování propustnosti FL. Krátké pakety se používají v kroku maximalizace efektivity plnění (jak je zobrazeno na obr. 12), když má vybraná kandidátská instance přenosu zátěž, která se hodí do krátkého paketu.

Krok maximalizace efektivity plnění lze provést konzistentně s obr. 12. V tomto kroku může vybraná kandidátská instance přenosu projít změnou vysílacího formátu podle následujících pravidel.

(1) Pokud vybraná kandidátská instance přenosu obsahuje jednoduchá uživatelská data, potom je povoleno, aby znovu vybraný formát byl buď jednouživatelský formát kompatibilní s uživatelovým DRC nebo víceuživatelský formát.

(2) Jestliže vybraný kandidátský formát přenosu obsahuje data dvou nebo více uživatelů, potom může být znovu vybraný formát jiný víceuživatelský formát. V jednom případě se vybere nejmenší formát schopný nést tuto zátěž. Tato

89723 (0989723_CZ.doc) 16.12.2006

postkonverze se dále řídí příznaky, které mohou zabránit konverzi do některého z víceuživatelských formátů.

V jednom provedení krok 510 formátování instance přenosu dále obsahuje krok 530, kde plánovač maximalizuje efektivitu plnění instance přenosu, a krok 532, ve kterém plánovač provádí apriorní výpočet ACK, viz. obr. 12. Navíc může krok 530 zahrnovat způsob, jak je zobrazen na obr. 13. Instance přenosu se nejprve vyhodnotí (rozhodovací krok 540) , aby se určilo, jestli se použije jednouživatelský formát. Pokud se použije jednouživatelský formát, každý krok je dále vysvětlen podrobněji.

V jednom provedení plánovač určí maximální rozpětí odpovídající DRCs uživatelů, pro které vybraná instance přenosu ponese datové bity. Plánovač spočítá vyhrazený počet přenosových slotů. Pokud někteří uživatelé nemají dosud potvrzen správný příjem přenášené informace, tj. přenesenou ACK zprávu, a pokud jsou jakákoliv čekající data v kterékoliv frontě, ukončí AN přenos.

Alternativní provedení obsahuje specifické prostředky a způsoby pro dokončování způsobu 500 zobrazeného na obr. 10, zahrnujícího, ale neomezujícího se na bitové vyrovnání, aby se vytvořily všechny kandidátské instance přenosu a výpočet paketové metriky.

Výpočty paketové metriky se provádějí v kroku 508, zatímco bitové vyrovnání je součástí formátování instance přenosu v kroku 508. Obecně může být jednouživatelská instance přenosu vyrovnána bity z jednoho nebo více toků stejného uživatele. Víceuživatelské instance s definovaným formátem, jako je například definován v tabulce 1, lze

89723 (0989723_CZ.doc) 16.12.2006

vyrovnat bity od jednoho nebo více uživatelů, kde takoví uživatelé vyslali DRC kompatibilní s víceuživatelským formátem. Víceuživatelská instance s odvozeným formátem může být vyrovnána bity od jednoho nebo více uživatelů, jejichž přenesené DRCs jsou kompatibilní s víceuživatelským formátem a která splňují doplňkový požadavek „měkké kompatibility. DRC se považuje za měkce kompatibilní k odvozenému víceuživatelskému formátu, pokud očekávaný počet slotů k dekódování odpovídajícího „definovaného formátu je menší nebo roven rozsahu odvozeného formátu. Očekávaný počet slotů lze získat porovnáním poměru Signál-interference a Šum (SINR) požadovaného pro přijímaný DRC k SINR požadovanému k úspěšnému dekódování (např. za přítomnosti průměrného bílého gausovského šumu (Average White Gaussian Noise AWGN). Alternativně může být předpokládaný počet slotů určen porovnáním požadované rychlosti k efektivní rychlosti přenosu dat odvozeného formátu.

Následující popis předpokládá QoS třídy obsahující: i) BE/AF a jednu třídu EF. Způsob připouští také rozšíření na více EF tříd. Podle tohoto vynálezu je každému bitu čekajícímu ve frontě přiřazena bitová metrika, která je dána jako polynom tvaru:

bi(z) = [hi2]z~² + [hi]z^_1 + [lo] kde i je index bitu a pouze jeden ze tří koeficientů {hi2, hi, lo} může být nenulový. Všimněte si, že popis je dán na úrovni bitů, typicky všechny bity v IP datagramu mají stejnou metriku a výpočty paketové metriky nemusí nezbytně zahrnovat hromadění na bitové úrovni.

Nechť 8 je stávající zpoždění spojené s bitem z EF

89723 (0989723_CZ.doc) 16.12.2006 toku. Nastavme následující definice pro hi2 a hi:

hi2 = βδ + μ pokud δ > a HraniceZpoždění a

hi = βδ + μ pokud δ h a HraniceZpoždění kde β je parametr spojený s EF tokem a je inverzně sdružený s hranicí zpoždění, kde μ je velké číslo a a je pevně daný skalár, například 0,25 a je nezávislý na typu EF toku.

Pro BE/AF tok nastavme lo následovně:

0=1/[AvgThroughput-TrgtThroughput] kde AvgThroughput odpovídajícího uživatele a propustnost požadovaná pro je průměrná propustnost

TrgtThroughput je minimální tohoto uživatele.

uživatele je TrgtThroughput nastaven na nulu.

Pro BE

Paketová metrika (např, následovně:

polynom propustnosti) se potom získá

PaketováMetrika - NahromaděnáBitováMetrika / Ng kde Ng je generické rozpětí definované nebo odvozené kandidátské instance přenosu, které přichází v úvahu, a nahromaděná bitová metrika (NahromaděnáBitováMetrika) je součet bitových metrik odpovídající všem bitům obsaženým (nebo vyrovnaným) v kandidátské instanci. Hodnota Ng může být nastavena na jedna, v takovém případě bude paketová metrika rovna nahromaděné bitové metrice. V tomto případě bude plánovač raději než propustnost na instanci přenosu maximalizovat zátěž na instanci přenosu. To může mít jako

89723 (0989723_CZ.doc) 16.12.2006

nežádoucí efekt vytvoření DRC necitlivosti, což způsobí sníženou propustnost, kde taková degradace nemusí odpovídat chování popsanému na obr. 6. Jiný přístup je nastavit Ng na „pseudo-span, který lze nastavit na jedna pro 1 a 2 slotové vysokorychlostní pakety, na dva pro 4 slotové pakety atd, čímž se odlišují vysokorychlostní pakety na základě zátěže, zatímco nízkorychlostní formáty se odstaví nastavením Ng na velké hodnoty.

Následující vlastnosti poskytují přemostění uživatelů s vysokou geometrií k plánovači:

(1) Pokud je DRC kompatibilní s víceuživatelským formátem, je také kompatibilní se všemi víceuživatelskými formáty nižší nominální datové rychlosti a (2) Plánovač použije polynom „propustnosti jako výběrové zařízení.

Jeden návrh používá člen μ s vysokou hodnotou v definici hi a hi2 koeficientů pro bitovou metriku. Tyto bity se vyrovnají v pořadí podle hodnoty βδ, protože μ je pro všechny bity společné. Paketová metrika se vypočte jako by se odpovídající záznam bitové metriky změnil na jedna, což vede k tomu, že paketová metrika je úměrná polynomu propustnosti. To eliminuje efekt βδ pro výpočet paketové metriky v paketové metrice.

Všimněte si, že jak bylo popsáno výše, plánovač používá pevnou HraniciZpoždění pro všechny uživatele. Uživatelé s dobrým pokrytím typicky potřebují pouze zlomek HraniceZpoždění. S rostoucím počtem uživatelů začíná degradace nejprve u nejslabších uživatelů, zatímco uživatelé

89723 (0989723_CZ.doc) 16.12.2006 s vysokými geometriemi nemusí být zátěží silně ovlivněni.

Jedno provedení adaptivně nastavuje hranici zpoždění a příbuzné parametry (např. a) měřením podílu dobrých EF uživatelů. HraniceZpoždění použitá plánovačem může být iterativně zvýšena nebo snížena, aby se udržel podíl dobrých uživatelů na požadované úrovni. V jednom provedení je implementována jednoduchá smyčka prvního řádu se spodní hranicí pro HraniciZpoždění.

V plánovači popsaném výše použije způsob definující bitovou metriku pro BE/AF uživatele následující výpočet:

Bitová metrika = 1 / [AvgThroughput - TrgtThroughput].

Pro různé systémy, provozní cíle a návrhy lze implementovat jiné definice bitové metriky.

FL přenosové formáty kompatibilní s každým DRC indexem jsou také uvedeny v tabulce 1 pro dvě množiny subtypů protokolu definovaných ve specifikacích lxEV-DO Rel-0 a revizi A, včetně navržených změn v nedávných příspěvcích k Rev-A definujících kompatibilní víceuživatelské formáty pro DRC indexy 0x0, 0x1 a 0x2. Přenosové formáty, jak je uvedeno ve specifikaci Rev. A, jsou reprezentovány trojicí (VelikostPaketu, Rozpětí, DélkaHlavičky). „VelikostPaketu je počet bitů nosného přenosového formát zahrnující Cyklický redundantní kód (CRC) a patička. „Rozpětí je nominální počet slotů, které může vzít instance „DélkaHlavičky je celkový počet je uvedeno v revizi A lxEV-DO specifikaci, kanonické přenosové formáty pro každé DRC jsou zobrazeny tučně. Všimněte si, že Rel-0 definuje pouze (např. maximální! přenosu na přímém linku, hlavičkových čipů. Jak

89723 (0989723_CZ.doc) 16.12.2006

jednouživatelské přenosové formáty, zatímco určité subtypy v revizi A definují jak jednouživatelské, tak víceuživatelské formáty. Navíc, v revizi A lze pro každý DRC index definovat více přenosových formátů. AT se pokouší přijímat pakety pro každý z těchto formátů. Víceuživatelské formáty se rozlišují podle jejich unikátních MAC indexů, tj. hlavička každého víceuživatelského formátu používá odlišnou Walshovu obálku. Všechny jednouživatelské formáty používají MAC index přiřazený uživateli.

DRC index	Rychlost (Kbps)	RevO přenosový formát	RevA jednouživatelské přenosové formáty	RevA Víceuživatelské přenosové formáty
0x0	0,0	žádné	(128.16.1024) , (256.16.1024) , (512,16, 1024) , (1024.16.1024)	žádné
0x1	38,4	(1024,16,1024)	(128.16.1024) , (256.16.1024) , (512.16.1024) , (1024.16.1024)	žádné
0x2	76, 8	(1024,8,512)	(128.8.512) , (256.8.512) , (512.8.512) , (1024.8.512)	žádné
0x3	153, 6	(1024,4,256)	(128.4.256) , (256.4.256) , (512.4.256) , (1024.4.256)	(128.4.256) , (256, 4,256) , (512.4.256) , (1024.4.256)
0x4	307,2	(1024,2,128)	(128,2,128), (256.2.128) , (512.2.128) ,	(128.4.256) , (256.4.256) , (512.4.256) ,

89723 (0989723_CZ.doc) 16.12.2006

			(1024,2,128)	(1024,4,256)
0x5	307,2	(2048,4,128)	(512.4.128) , (1024.4.128) (2048.4.128)	(128.4.256) , (256, 4,256) , (512.4.256) , (1024.4.256) (2048,4,128)
0x6	614,4	(1024,1,64)	(128.1.64) (256.1.64) (512.1.64) (1024.1.64)	(128.4.256) , (256.4.256) , (512.4.256) , (1024.4.256)
0x7	614,4	(2048,2,64)	(512.2.64) , (1024.2.64) , (2048.2.64)	(128.4.256) , (256, 4,256) , (512.4.256) , (1024.4.256) (2048,4,128)
0x8	921,6	(3072,2,64)	(1024.2.64) , (3072.2.64)	(128.4.256) , (256, 4,256) , (512.4.256) , (1024.4.256) , (2048,4,128), (3072,2,64)
0x9	1228,8	(2048,1,64)	(512.1.64) , (1024.1.64) , (2048.1.64)	(128.4.256) , (256, 4,256) , (512.4.256) , (1024.4.256) , (2048,4,128)
ΟχΑ	1228,8	(4096,2,64)	(4096,2,64)	(128.4.256) , (256, 4,256) , (512.4.256) , (1024.4.256) , (2048,4,128), (3072.2.64) , (4096.2.64)

89723 (0989723_CZ.doc) 16.12.2006

OxB	1843,2	(3072,1,64)	(1024.1.64) , (3072.1.64)	(128.4.256) , (256, 4,256) , (512.4.256) , (1024.4.256) , (2048,4,128), (3072,2,64)
OxC	2457,6	(4096,1,64)	(4096,1,64)	(128.4.256) , (256, 4,256) , (512.4.256) , (1024.4.256) , (2048,4,128), (3072.2.64) , (4096.2.64)
OxD	1536,0	žádné	(5120,2,64)	(128, 4,256) , (256, 4,256) , (512.4.256) , (1024.4.256) , (2048,4,128), (3072.2.64) , (4096.2.64) , (5120.2.64)
OxE	3072,0	žádné	(5120,1,64)	(128, 4,256) , (256.4.256) , (512, 4,256) , (1024.4.256) , (2048,4,128), (3072.2.64) , (4096.2.64) , (5120.2.64)

Jako připomenutí se instance přenosu odkazuje na přenosový formát s konkrétní sadou bitů z jedné nebo více vybraných front, které se jí mají transportovat. Kandidátská

89723 (0989723_CZ.doc) 16.12.2006

(1024,4,256), (5120,2,64) se instance přenosu se odkazuje na instanci přenosu, která se má vyhodnotit plánovacím algoritmem pro možný přenos. Víceuživatelské přenosové formáty (2048,4,128), (3072,2,64), (4096,2,64) a označují jako kanonické víceuživatelské přenosové formáty. Víceuživatelské přenosové formáty (128,4,256), (256,4,256) a (512,4,256) se označují jako „nekanonické víceuživatelské formáty. Odvozené přenosové formáty se získají jednoduše nastavením rozpětí odpovídajícího definovaného formátu na menší hodnoty než nominální hodnota, pokud se mají získat z definovaných formátů předčasným ukončením. Celkově mohou být vysílací formáty a instance kanonické nebo nekanonické; jednouživatelské nebo víceuživatelské a definované nebo odvozené. Pojem „nominální počet slotů se používá k odkázání na maximální počet slotů pro definovaný přenosový formát a znovu definovaný maximální počet slotů pro odvozený přenosový formát.

Následující popis plánovacích prostředků a způsobů uvažuje oktetové plánování, ve kterém oktety čekající v různých frontách mohou být obslouženy v jakémkoliv množství (v jednotkách oktetů). Typicky se každý tok uloží jako alespoň jedna fronta dat. Proto má každá fronta specifické QoS požadavky, které jsou s ní spojeny. Data se ukládají v každé frontě ve formě oktetů. Plánování lze provést, kde se méně než plný oktet dat dá do instance přenosu nebo fyzické vrstvy paketu pro přenos na FL.

Všimněte si, že některé aplikace mohou vyžadovat plánování založené na rámcích, kde (zapouzdřené) datagramy toku se mají obsluhovat bez fragmentace v paketech fyzické vrstvy. Plánovací prostředky a způsoby založené na oktetech mohou být také rozšířeny na plánování založené na rámcích.

89723 (0989723_CZ.doc) 16.12.2006 ·· «· • · · · • · · ·* ···» ··

- 55 Povšimněte si také, že řízení přístupu těsně souvisí s plánováním, přičemž řízení přístupu slouží k připuštění/odmítnutí příchozích toků na základě aktuální zátěže systému a předvídáním, zda příchozí tok může být uspokojivě obsloužen (tj . jsou splněny QoS cíle) bez způsobení nepřijatelné degradace již povolených toků.

„Tok, jak se zde používá, označuje datový tok směrovaný k danému uživateli. Zdroj toku může být jedna nebo více uživatelských aplikací, zahrnujících mimo jiné, ale neomezujících se na stahování souborů (ftp), surfování po webu (http), online hry nebo VoIP. Tok může být také generován vlastním komunikačním systémem, jako signální toky, které slouží k udržení systému ve funkčním stavu při správném udržování uživatelské relace. Jiným příkladem datového toku je datový tok generovaný testovací aplikací, kde se datový tok používá k testování alespoň části komunikačního systému.

Jinými slovy, tok je tokem dat a je částí komunikace s alespoň jedním uživatelem. Existuje mnoho aplikačních toků, každý má specifické QoS požadavky a tolerance. Každý tok může mít různou sadu QoS požadavků, jako cílová propustnost a hranice zpoždění. Příklady takových požadavků jsou podrobněji popsány níže.

Uživatel může mít více současných toků s různými QoS požadavky. Každý tok může být generován buď jedinou aplikací, jako například pro VoIP, ftp, signalizace atd., nebo může být generován více aplikacemi, které jsou agregovány do jediného toku řadičem základnové stanice (BSC - Base station controller). Pokud BSC agreguje toky tímto

89723 (0989723_CZ.doc) 16.12.2006 • · · W ·· · 9 · ··» A ♦ · ♦ · ···· « « · • · · ··· · · · ·· *··· «· ··· «· * způsobem, může se agregovaný tok jevit plánovači jako jediný tok s dobře definovanými QoS požadavky. Plánovač nemusí být schopen rozlišit mezi daty generovanými různými aplikacemi, ale obsaženými v agregovaném toku. Jiný typ agregace, kterou lze provést plánovačem, je uveden níže.

Každý tok má alespoň jednu frontu uchovávající data pro první přenos (označovaný jako FTx) a může mít další fronty pro opakované přenosy, jako například protokol radiové vrstvy (Rádio Layer Protocol - RLP), frontu pro opakovaný přenos (RT - ReTransmission - RTx fronta pro tok x) a/nebo frontu pro opakovaný přenos MAC vrstvy (zpožděný požadavek na automatické opakování - ARQ - Automatic Repeat Request), nebo zpožděná ARQ (DARQ) fronta). V jednom provedení má každý oktet v každé frontě přesně stanovenou časovou známku, podle které může plánovač určit aktuální zpoždění způsobené oktetem. Časové známky jsou přiřazeny dávkám dat jako jsou například (zapouzdřené) datagramy, z čehož vyplývá, že každý oktet dávky dat má stejnou časovou známku. Jednotlivé datagramy mohou nést více rámců aplikační úrovně, které mohly být vygenerovány aplikací v různých časech. Předpokládá se, že časové známky aplikačního rámce nejsou plánovači známy. Tento předpoklad je oprávněný, protože kompletní datagram se má úspěšně přijmout uživatelem předtím, než může být kterýkoliv z rámců aplikace, které nese, parsován přijetím koncovou aplikací.

V návrhu plánovače podle jednoho provedení se uvažují tři hlavní QoS třídy. Nejlepší úsilí (BE - Best Effort) je definováno tak jako ve slovníčku a konkrétně označuje toky, které typicky mohou mít velká zpoždění, ale vyžadují nízkou četnost bitových chyb (BER - Bit Error Rate). Ačkoliv zde nejsou minimální požadavky na propustnost, objem přenášených

89723 (0989723_CZ.doc) 16.12.2006

dat může být velký. Příklady toků, které lze považovat za BE, zahrnují stahování souborů (ftp) a surfování po webu (http). Zajištěné směrování (AF - Assured Forwarding) označuje toky, které jsou obecně podobné BE tokům tolerujícím určitou úroveň zpoždění, ovšem AF toky se od BE toků liší tím, že AF toky mají typicky minimální průměrnou propustnost. Jedním příkladem aplikace klasifikované jako AF tok je videostream generovaný videokonferenční aplikací. Urychlené směrování (EF - expedited forwarding) označuje toky, které typicky, ale ne nezbytně, mají nízký požadavek na propustnost a mají striktní požadavky na zpoždění. Požadavek na spolehlivost nemusí být tak striktní jako u BE toků, může být přijatelné ztratit malý podíl dat aplikace, jako například 1 až 2 %. Příklady aplikací klasifikovaných jako EF toky zahrnují, ale neomezují se na VoIP a online hry.

Vzhledem k prostředkům a způsobům plánování je rozdíl mezi BE a AF toky požadavek minimální propustnosti, který je pro BE toky nulový. Jinak jsou tyto dvě QoS třídy podobné. Aby se dále odlišily konkrétní toky, uvažujme EF třídu, která může obsahovat množství různých typů aplikací. V EF třídě toků mohou být toky s různými prioritami. Například aplikace jako VoIP a hlasovou část videokonferenčních aplikací lze považovat za aplikace s vyšší prioritou než obrazová část videokonferenční aplikace. Online hry lze považovat za aplikace s nižší prioritou než mají jak zvukové, tak obrazové aplikace.

Navíc k tokům generovaným uživatelskými aplikacemi má systém podporující IS-856 vnitřně generované toky, jako například signální tok, který je požadován k udržení systému v provozu, a toky generované testovacími aplikacemi

89723 (0989723_CZ.doc) 16.12.2006 • · · · ·· · ······ ···· ···· ·· ·

používané k testování systému.

Typické QoS požadavky lze specifikovat v pojmech řady úvah popsaných proměnnými, zahrnujícími, ale neomezujícími se na hranici zpoždění, cílovou propustnost, spolehlivost, neklid atd.

Hranice zpoždění je identifikována proměnnou označenou jako „HraniceZpoždění, která je parametrem specifikovaným pro každý tok udávajícím maximální dobu, během které se má datagram úspěšně doručit uživateli. Hranice zpoždění se měří relativně k časové známce datagramu, který je v tomto provedení oktetem. Všimněte si, že se toto liší od hranice celkového zpoždění, které zahrnuje jiné celkové složky zpoždění než FL zpoždění. V jednom provedení, jakmile se dosáhne hranice zpoždění, se datagram odebere z fronty. Jinými slovy, pokud nelze datagram poslat ve specifikované hranici zpoždění, datagram se zahodí.

Cílová propustnost je identifikována proměnnou označovanou jako „CílováPropustnost, která je dalším specifikovaným QoS parametrem. Cílová propustnost označuje minimální průměrnou propustnost toku. Průměrování propustnosti lze definovat pomocí filtru s konečnou impulsní odezvou (IIR) prvního řádu s odpovídající časovou konstantou. V jednom provedení se časová konstanta nastaví na 1 ms.

Třetím QoS požadavkem může být spolehlivost. Typicky fyzická vrstva systému poskytuje 1% chybovost paketů (PER Packet Error Rate), která nemusí být dostatečná pro aplikace vyžadující výjimečně nízkou chybovost, jako například stahování souborů. Proto, aby se dále snížily ztráty při

89723 (0989723_CZ.doc) 16.12.2006 přenosu vzduchem, lze využít mechanismy pro opakovaný přenos. Typické mechanismy pro opakovaný přenos jsou RLP opakované přenosy a MAC vrstva opakovaných přenosů, jako například RTx a DARQ fronty. Aby se dále zvýšila spolehlivost, lze mimo jiné jako transportní vrstvu pro aplikaci použít protokol řízení přenosu (TCP - transmission control protocol) .

V jednom provedení je plánovač navržen tak, aby maximalizoval kapacitu systému při zajištění rovnosti mezi toky a splnění jistých priorit a QoS požadavků jednotlivých toků. Koncept kapacity a rovnosti závisí na QoS požadavcích jednotlivých toků. Pro BE toky lze kapacitu definovat jako celkovou BE propustnost přenesenou sektorem. Pro EF toky lze konkrétní typ kapacity definovat jako počet uživatelů, který lze podporovat při splnění jejich QoS požadavků. V jednom příkladu plánování EF toku systém definuje VoIP kapacitu tak, že počet VoIP uživatelů se vybere jako počet, který pokryje 95 % uživatelů, kteří úspěšně přijmou v průměru 98 % aplikačních datových rámců (nebo oktetů). V jednom příkladu je úspěšnost určena rámci přijatými v rámci specifikované hranice zpoždění a bez přenosových chyb. Lze použít alternativní kritéria úspěšnosti. Aby se dosáhlo rovnosti mezi toky, lze pro plánování BE toků použít kritéria proporcionální rovnosti (PF - proportional fairness) a k plánování EF toků prioritního kritéria. Tímto způsobem budou s rostoucí zátěží systému degradovány všechny BE toky stejně, tj. BE toky se degradují bez rozdílu.

Pro EF toky je žádoucí, aby měly s rostoucí zátěží systému nebo při výskytu přetížení nerovnou degradaci napříč uživateli. Jako první pocítí degradaci ty EF toky, které mají nejnižší prioritu. Mezi EF toky s podobnými QoS

89723 (0989723_CZ.doc) 16.12.2006

požadavky a stejnou úrovní priority ovlivní degradace nejprve toky uživatelů s nejhorším stavem kanálu. S tímto přístupem může s rostoucím přetížením systému splňovat QoS požadavky největší možný počet EF toků. Tento přístup obvykle vede k přibližně inverznímu vztahu mezi uživatelskými podmínkami kanálu a statistikou zpoždění jeho EF toků. Tato vlastnost se označuje jako „Rovnost zpoždění.

Přenosový formát je trojice ve formě (VelikostPaketu, Rozpětí, DélkaHlavičky) , která popisuje určité parametry FL paketu. Velikost paketu označuje zátěž fyzické vrstvy v bitech. Rozpětí označuje maximální počet slotů, který může paket tohoto formátu přenášet a délka hlavičky označuje trvání hlavičky v čipech.

V systému podporujícím IS-856 se použije přizpůsobení linku k určení rychlosti přenosu dat FL pro každého uživatele. Každý AT přenáší požadavek na data indikující maximální rychlost přenosu dat, kterou může AT přijímat data. Požadavek na data se označuje jako zpráva řízení rychlosti přenosu dat (DRC - Data Rate Control). Formát DRC zprávy používá různé DRC indexy, každý určuje přenosový formát. AT vysílá DRC zprávy na DRC kanálu. Pro každý platný DRC index, kromě NULL DRC v IS-856 Rel-0 je zde jeden nebo více jednouživatelských a nula nebo více víceuživatelských přenosových formátů, které lze obsloužit na FL, aby nesly data k uživateli. Tabulka 1 udává DRC indexy jak jsou definovány v IS-856. Dále tabulka l°obsahuje kompatibilní přenosové formáty pro každý DRC index.

V lxEV-DO Rev-A specifikaci se definuje jeden z kompatibilních jednouživatelských přenosových formátů jako kanonický formát pro DRC. Všimněte si, že DRC tak jak se zde

89723 (0989723_CZ.doc) 16.12.2006 • · • · · · · « používá, odpovídá specifickému formátu požadovanému AT a identifikovanému DRC indexem. Obecně, pokud AT úspěšně dekóduje paket přenesený použitím kanonického formátu odpovídajícího danému DRC, potom bude taková AT pravděpodobně úspěšně dekódovat paket přenesený v kterémkoliv kompatibilním nekanonickém jednouživatelském formátu a nebo kompatibilním víceuživatelském formátu. To je s výjimkou DRC indexů: 0x0; 0x1 a 0x2. Všimněte si, že i když některé víceuživatelské formáty kompatibilní s danou DRC mohou mít větší délky hlavičky ve srovnání s kanonickými formáty, nemusí tyto nezbytně vést k zisku ve zpracování dat.

Pro kterékoliv DRC s výjimkou všech formátů kompatibilních s DRC indexem 0x0 a víceuživatelskými formáty kompatibilními s DRC indexy 0x1 a 0x2, je velikost zátěže nekanonického formátu typicky menší nebo rovna zátěži kanonického formátu. Navíc rozpětí nekanonického formátu je typicky větší nebo rovno rozpětí kanonického formátu. Pokud je uživatel, od kterého byl přijat DRC index 0x0 (např. NULL požadavek na data), obsloužen libovolným formátem, pak zde není obecně záruka spolehlivého přijetí paketu. Pro DRC indexy 0x1 a 0x2 tedy kompatibilní víceuživatelské formáty nemusí zaručit dostatečně spolehlivý příjem, protože velikost zátěže a rozpětí těchto formátů nesplňuje tuto vlastnost.

V jednom provedení nemusí plánovač k obsloužení uživatelů, od kterých přijal DRC 0x0, 0x1 nebo 0x2 využít víceuživatelské pakety. Také obsloužení uživatelů, od kterých je přijat NULL DRC může být omezeno na určité podmínky. Tyto podmínky mohou být začleněny do systému.

89723 (0989723_CZ.doc) 16.12.2006 • · · ·

- 62 Pro víceuživatelské přenosové formáty, pokud je dané DRC kompatibilní s daným víceuživatelským formátem, je potom stejné DRC kompatibilní se všemi víceuživatelskými formáty nižších rychlostí přenosu dat.

„Instance přenosu označuje kombinaci přenosových formátů a identifikuje datové oktety, které mohou být přeneseny paketem tohoto formátu. Například sada MAC indexů pro uživatele, kterým paket přináší datové oktety a sadu ukazatelů do odpovídajících front označujících přesně oktety, které se mají přenést v paketu, může definovat formát přenosu.

Plánovač může generovat sadu hypotetických přenosových instancí a potom vybrat jednu z těchto instancí pro přenos na FL. Pojem, který se používá v tomto dokumentu k označení kterékoliv z těchto hypotetických přenosových instancí je „kandidátská instance přenosu.

V jednom provedení plánovače, které obsahuje adaptivní správu zpoždění, používá plánovač různé metriky, které zahrnují: 1) bitovou vyrovnávací metriku; 2) bitovou metriku a 3) paketovou metriku. Bitová metrika se používá k výběru front, které jsou vhodné pro začlenění do aktuální instance přenosu. Metriky vkládání bitu určují pořadí, ve kterém se bity nebo oktety, které čekají v různých frontách, začleňují do dané kandidátské instance přenosu. Jakmile se vytvoří kandidátská instance přenosu, vypočte se paketová metrika pro kandidátskou instanci přenosu. Paketová metrika se potom použije k výběru vítězné instance přenosu ze sady podobně vytvořených kandidátských instancí přenosu. Paketová metrika kandidátské instance přenosu se určí jednoduchým sečtením bitových metrik všech oktetů obsažených v kandidátské

89723 (0989723_CZ.doc) 16.12.2006 • · · ·

instanci přenosu a vydělením tohoto součtu rozpětím přenosového formátu kandidátské instance přenosu:

PaketováMetrika\k\ =--- V BitováMetrika\i\

Rozpeti\k] kde k představuje index na konkrétní kandidátskou instanci přenosu v sadě alternativ, Rozpětí[k] představuje rozpětí definované pro odpovídající přenosový formát, P[k] představuje sadu oktetů, které jsou obsaženy v kandidátské instanci přenosu a BitováMetrika[i] představuje bitovou metriku i-tého oktetu obsaženého v kandidátské instanci.

Paketovou metriku lze tudíž interpretovat jako odhad „okamžité propustnosti bitové metriky, pokud byly kandidátské instance přenosu skutečně obslouženy na FL.

Obecně, pokud je metrika vkládání bitů oktetu i větší, než metrika vkládání bitů jiného oktetu j, potom lze bitovou metriku oktetu i nastavit větší nebo rovnu bitové metrice oktetu j. V tomto případě mohou být oktety z různých front. Podobně, pokud bitová metrika oktetu i je větší než metrika jiného oktetu j, pak by měla být metrika vkládání bitů oktetu i nastavena větší nebo rovna metrice oktetu j, tj.:

BitováMetrika[i] > BitováMetrika[j] =>

MetrikaVkládáníBitu[i] > MetrikaVkládáníBitu[j]

MetrikaVkládáníBitu[i] > MetrikaVkládáníBitu[j] =>

BitováMetrika[i] > BitováMetrika[j]

Toto obecné pravidlo zajišťuje, že oktet uložený do stejné kandidátské instance přenosu přispívá k metrice

89723 (0989723_CZ.doc) 16.12.2006 paketu alespoň stejnou měrou jako jiný oktet, který byl uložen později.

Všechny zde popsané metriky, stejně jako alternativní metriky, mohou být reprezentovány v následující formě polynomu:

Metrika = [MCO]+[MCI]x+[MC2]x² + [MC3]x³ + [MC4]x⁴ + [MC5]x⁵ + [MC6]x⁶ + [MC7]x⁷ kde Metrika může být kterýmkoliv typem metriky a MCO,..., MC7 představují koeficienty metriky. Sečtení dvou metrik a násobení (dělení) metriky skalárem jsou definovány jako v polynomiální algebře, kde se při sčítání dvou metrik sečtou odpovídající koeficienty jejich dvou polynomů. Když se metrika násobí (nebo dělí) skalárem, každý z jejích koeficientů se násobí (nebo dělí) stejným skalárem. To umožňuje výpočet metriky paketů za použití bitové metriky vypočtené tak, jak je definovaná výše.

Operátory porovnání „>,>=,==,<=,< jsou definovány v lexikálním smyslu, tj . když se porovnávají dvě metriky, porovnají se nejprve koeficienty u členů nejvyššího řádu. Pokud jsou stejné, pak se porovnají koeficienty členů nejbližšího nižšího řádu atd. Dvě metriky jsou stejné, pokud jsou stejné všechny odpovídající koeficienty dvou polynomiálních reprezentací. Operace porovnání se používají pro porovnání metrik vkládání bitů, stejně jako pro porovnání metrik paketů.

Bitové metriky, Metriky vkládání bitů a metriky paketů

Pro bitové metriky a metriky vkládání paketů je v daný

89723 (0989723_CZ.doc) 16.12.2006

okamžik pouze jeden člen odpovídající polynomiální reprezentace nenulový. Řád nenulového členu je stejný pro bitovou metriku a metriku vkládání bitů daného oktetu. Řád tohoto nenulového členu, který se obvykle označuje odpovídajícím názvem koeficientu. MCO, ..., MC7 se nazývají prioritní stav metriky (vkládání) bitů (nebo odpovídajícího otketu). Definice operace porovnání ukazuje, že člen MCO odpovídá oktetům s nejnižší prioritou a člen MC7 odpovídá oktetům s nejvyšší prioritou. Stav priority metriky (vkládání) bitu pro oktet i je určen aktuálním zpožděním způsobeným oktetem, které je dáno jako:

AktuálníZpoždění[i]=AktuálníČas - ČasováZnámka[i] a použitím uspořádané množiny prahů známé jako „prahy priorit definované pro tok, kterému oktet přísluší. ČasováZnámka[i] je vhodně definovaná časová známka pro oktet

i. Každý interval definovaný prahem priority se namapuje na stav priority. Prahy priority a jejich mapování jimi definovaných intervalům na prioritní stavy může být pro každý tok specifikováno plánovačem odděleně. AktuálníZpoždění[i] oktetu se porovná s těmito uspořádanými množinami, aby se určil interval, do kterého spadá. To na oplátku definuje prioritní stav metriky (vkládání) bitů.

Výše uvedená operace používá M prioritních prahů a M+l prioritních stavů pro každý tok. Hodnota M je nastavena na 2 v provedení, které je softwarovou implementací plánovače. Pro každý tok jsou definovány dva prioritní prahy a tři prioritní stavy. Tyto prioritní prahy a prioritní stavy mohou v průběhu existence toku typicky zůstat nezměněny, ačkoliv se mohou za provozu změnit příslušným příkazem DSPdriveru.

89723 (0989723_CZ.doc) 16.12.2006

Pro toky trafficu citlivé na propustnost se bitová metrika nastaví na:

GoSFaktor Thrghpt2DelayConwFaktorBM

Λ. (J~~~—~~ ” ~~ max(r, AvgThroughput - TargetThroughpuť) a metrika vkládání bitů je nastavena na:

GoSFaktor Thrghpt2DelayConwFaktorBSM max(f, AvgThroughput - TargetThrougphuť)

Ty kde:

1. GoSFaktor je parametr toku, který se používá k zajištění různých úrovní služeb v tocích.

2. AvgThroughput je filtrovaná (průměrovaná) celková propustnost toku zahrnující FTx, RTx a DARQ fronty toku. Pro průměrování se použije filtr s nekonečnou impulsní odezvou (IIR) prvního řádu s časovou konstantou např. 600 slotů (1 sekunda).

3. TargetThrougut je parametr definovaný pro tok.

4. Thrghpt2DelayConvFaktorBM je parametr definovaný pro tok.

5. Thrghpt2DelayConvFaktorBSM je parametr definovaný pro tok.

6. ε představuje velmi malé kladné číslo.

89723 (0989723_CZ.doc) 16.12.2006

Pro metriku vkládání bitů toků citlivých na zpoždění se nastaví následující polynomiální koeficient prioritního stavu:

DS_Bsm = AccelerationFaktor*AktuálniZpoždění + AccelerationOffset kde AccelerationFactor je parametr definovaný pro tok. AccelerationFactor normalizuje HraniciZpoždění, která může být pro různé toky různá. Jak příklad uveďme dvě různé online hry. Kvůli odlišným vlastnostem těchto dvou aplikací mohou mít tyto aplikace různá nastavení HraniceZpoždění v plánovači, ovšem jedna hra nemá nezbytně vyšší prioritu než jiná aplikace. Pro plánovač může být žádoucí odbavit aplikace se stejnou prioritou. Předpokládejme, že první hra má hranici zpoždění 300 ms a druhá hra má 150 ms. Potom v kterémkoliv okamžiku nebudou existovat žádné oktety příslušející druhé hře starší, než 150 ms, protože je plánovač zahodí. Bez AkceleračníhoFaktoru by to vedlo k posílení priority oktetů první hry nad oktety druhé hry. Nastavením AkceleračníhoFaktoru každé aplikace nepřímo úměrně příslušnému nastavení HraniceZpoždění může plánovač tento nežádoucí efekt normalizovat.

AccelerationOffset je parametr definovaný pro tok. Hodnota AccelerationOffsetu může být hodnota nastavená na celočíselný násobek největší hodnoty, kterou může mít AccelerationFactor. Tato největší hodnota je nezávislá na tocích a může být určena softwarovou implementací. Jako příklad mezi dvěma toky, jedním s AccelerationOffsetem nastaveným na nulu a druhým s kladným AccelerationOffsetem budou oktety druhého toku obsaženy v kterékoliv kandidátské instanci přenosu před kterýmikoliv toky bývalého toku, za

89723 (0989723_CZ.doc) 16.12.2006

předpokladu, že oba toky jsou DRC kompatibilní s přenosovým formátem dané kandidátské instance.

Pro bitovou metriku je koeficient polynomu pro prioritní stav nastaven na konstantní hodnotu následujícím způsobem:

DS_Bm = DSBitMetricValue kde DSBitMetricValue je parametr definovaný pro tok, který se používá pro měkké seřazení podle priorit. Navíc když dvě aplikace mají přibližně stejnou prioritu, ale různé průměrné vstupní propustnosti (např. z Internetu do fronty), může být DSBitMetricValue pro každý tok nastavena inverzně vzhledem k typické propustnosti toku, tak aby se aplikaci s vyšší propustností zabránilo v úplném získání priority tím, že má více dat k efektivnímu plnění FL paketů.

Každý tok trafficu se klasifikuje do na propustnost citlivých tříd nebo tříd citlivých na zpoždění na základě parametru třídy toku. Potom se bitová metrika MCX (kde X je prvek {0,...,7}) definuje následovně:

MCX = <

TS_BM ,pokud jeTřídaToku CitliváNaVýkon DS_bm , pokud je TřídaToku CitliváNaZpoždění

Podobně je metrika vkládání bitů definována jako:

TS_BSM , pokud jeTřídaToku CitliváNaVýkon DS_bsm, pokud jeTřídaToku CitliváNaZpoždění

V jednom provedení je plánovač implementován alespoň částečně softwarově. Podle tohoto provedení jsou metriky

89723 (0989723_CZ.doc) 16.12.2006

vkládání bitů reprezentovány 16 bitovými hodnotami, které mohou být označeny jako [B15 ... BO] . Tři nejvýznamnější bity určují prioritní stav (např. „000 se mapuje na MCO a „111 se mapuje na MC7). Zbývajících 13 nejméně významných bitů uchovává vlastní hodnotu koeficientu. S touto reprezentací se operace porovnání dvou metrik vkládání bitů mohou provádět přímo mezi těmito 16-bitovými hodnotami.

Bitové metriky nejsou explicitně reprezentovány v softwarové implementaci, protože tyto informace lze odvodit od metriky vkládání bitů.

Metrika vkládání bitů kandidátské instance přenosu se vypočte použitím:

MetrikaPaketu\k\ = rozpětí [k]

BitováMetrika\i\ ieP[*] jak je popsáno výše. Všimněte si, že nejenom jeden výraz bitové metriky oktetu může být nenulový, ale obecně koeficienty výsledné paketové metriky mohou být nenulové.

Mnoho DRCs je kompatibilních s nekanonickými jednouživatelskými formáty s menšími zátěžemi, a tudíž není žádoucí převádět pro dosažení ARQ zesílení jednouživatelské kandidáty na víceuživatelské formáty.

Pokud je vítězná kandidátská instance přenosu v kroku výběru plánovače víceuživatelským formátem, jsou v tomto provedení podporovány pouze konverze (1024,4,256) formátu do kteréhokoliv ze tří formátů ({128,256, 512), 4,256) (tj . použije se formát s nejnižší rychlostí, který může přenášet vybraná data).

89723 (0989723_CZ.doc) 16.12.2006

Výše uvedený popis bitové metriky a metriky vkládání bitů uvažuje obecně případ, kde oktety v každé frontě jsou přiřazeny vlastní metrice. Metrika se potom vypočte v každém slotu znovu. Alternativní provedení snižují složitost takových výpočtů. Předpokládejme, že fronty jsou seřazeny podle časové známky, jedno provedení vypočte jednu metriku (vkládání) bitu pro daný tok na základě nejstarší časové známky mezi hlavičkami oktetů ve frontách toku. Tato metrika se potom může použít pro pakety, které momentálně čekají ve frontě. Takové zjednodušení předpokládá, že metrika je monotónně rostoucí funkce AktuálníhoZpoždění oktetu. Jinak je zde riziko, že oktet hlavičky fronty může zabránit obsloužení dalších oktetů. S tímto zjednodušením lze metriku vkládání bitů označovat také jako metriku toku.

Navíc, kterýkoliv oktet hlavičky fronty čekající v RTx frontě je pravděpodobně starší, než kterékoliv oktety hlavičky fronty čekající v FTx a DARQ frontách. Podobně, kterýkoliv oktet hlavičky fronty, který čeká v DARQ frontě je pravděpodobně starší než oktet hlavičky fronty čekající v FTx frontě. Z tohoto důvodu používá jedno provedení raději než hledání nej starší časové známky mezi těmito třemi frontami pevné pořadí RTx, DARW a potom FTx front, aby se nalezla první neprázdná fronta pro určení časové známky, která se použije při výpočtu metriky toku. Tyto fronty toku mohou být obslouženy také v pořadí RTx, DARQ a potom FTx.

Podle jednoho provedení se plánování tak, jak je zobrazeno na obr. 10 provede kdykoliv je dostupný nový FL pro přenos. Všimněte si, že specifické implementace mohou provádět některé výpočty v každém slotu, včetně nedostupných slotů. To je proto, že v čase, kdy přístupová síť zjistí, že

89723 (0989723_CZ.doc) 16.12.2006 »« *· ··

je volný FL pro nový přenos, nezbývá obvykle mnoho času k provedení výpočtů zahrnutých ve způsobu plánování, aby se určila instance přenosu.

Způsob plánování znázorněný na obr. 10 se skládá se čtyř základních kroků: 1) vygenerování sady kandidátských instancí přenosu; 2) výběru jednoho kandidáta z množiny; 3) maximalizace efektivity paketování; a 4) apriorní nebo PACK výpočet. Výpočet PACK určí pravděpodobnost, že AT úspěšně dekódoval paket.

Opět s odkazem v kroku 504 seznam

Kandidátská na obr. 10, kandidátských jednouživatelská plánovač přenosu. přenosu každému generuj e instancí instance s jednouživatelským formátem odpovídajícím dostupnému uživateli, kde dostupný uživatel aktuálně nemá z jakéhokoliv důvodu odepřeny služby subtypu protokolu. Navíc, přijaté DRC od uživatele musí být nenulové, jinak uživatel vyjedná protokol MAC vrstvy umožňující obsloužení jednoho nebo více přenosových formátů do nulového DRC. Pokud se kandidátská instance přenosu vytvoří pro uživatele, od kterého byla přijata NULL DRC, umožní se kandidátské instanci přenosu přenášet pouze data, která patří k toku s konečnou hranicí zpoždění a pouze z FTx fronty toku. Přenosový formát kandidátské instance přenosu je kanonický formát odpovídající uživatelskému DRC, jak je zobrazeno v tabulce 1.

Kandidátská víceuživatelská instance přenosu se vygeneruje pro každý z pěti víceuživatelských přenosových formátů: (1024,4,256),(2048,4,128),(3072,2,64),(4096,2,64) a (5120,2,64). Uživatelé, kteří požadovali rychlost 153,6 Kbps nebo vyšší, jsou obslouženi ve víceuživatelských formátech.

89723 (0989723_CZ.doc) 16.12.2006 ·· ·* »* · ♦ ♦ »··* ···· · · ·· · · · ·· · · · · · e · ·· f · · · · * · · » • · · ♦ · · · · · ·» ···· »· ··· ·· 9

Navíc, DRC uživatele musí být kompatibilní s formátem kandidátské instance přenosu. Navíc, víceuživatelská kandidátská instance přenosu bude splňovat jednu nebo obě následující podmínky, jinak bude z dalšího uvažování vyloučena; bude nést data dvou nebo více uživatelů a data alespoň jednoho uživatele, jehož DRC byla vymazána.

Kandidátská instance přenosu ve kterékoliv skupině se vygeneruje vyrovnáním bitů z jednoho nebo více toků, kde: 1) jednouživatelské formáty mohou být vyrovnány pouze bity ze stejných uživatelských toků; 2) víceuživatelské formáty mohou být vyrovnány bity z toků uživatelů s kompatibilními DRCs.

Vyrovnání bitů se provede v sestupném pořadí bitové vyrovnávací metriky. Jak bylo zmíněno výše, výpočetní nároky mohou vést k výpočtu jedné bitové vyrovnávací metriky na tok, která se potom použije pro aktuálně čekající oktety ve frontách toku. V tomto případě bitová vyrovnávací metrika pomáhá určit, které toky budou obslouženy jako první; neurčí ovšem, jak budou oktety daného toku obslouženy. To předpokládá, že se oktety čekající ve frontách toku objevují v pořadí podle časových známek a oktety toku jsou obsluhovány v pořadí, ve kterém se objevují ve frontách. To se používá pro FTx fronty, ale ne nezbytně pro RTx/DARQ fronty.

Jak bylo uvedeno výše, může mít každý tok více front, jedna fronta pro data přenášená poprvé (FTx) a další fronty pro opakované přenosy (RTx fronta pro RLP opakované přenosy a/nebo DARQ fronta pro opakované přenosy MAC vrstvy). Pokud má tok neprázdné RTx a/nebo DARQ fronty, vypočte se bitová vyrovnávací metrika pro tok na základě nej starší časové

89723 (0989723_CZ.doc) 16.12.2006

známky z neprázdných FTx/RTx/DARQ front.

Řazení front na základě časových známek lze aproximovat jako pevné pořadí RTx/DARQ/FTx front.

Všimněte si, že se neuvažuje generování kandidátských instancí přenosu, nekanonických jednouživatelských formátů a krátkých víceuživatelských formátů, které nesou méně než 1024 bitů. Tyto formáty se budou uvažovat v kroku maximalizace efektivity paketování. Tento způsob plánování hledá maximální snížení složitosti a snaží se do paketu vložit co nejvíce dat.

Aby se předešlo situaci, kdy uživatel má špatný stav kanálu ale velké množství dat k přenosu, získá relativní prioritu efektivním plněním krátkých paketů. Jiným přínosem neuvažování nekanonických a krátkých paketů v tomto stavu je mimo jiné zabránění jistým kvantizačním efektům, které mohou vzniknout v plánování na základě rámců.

Při vytváření víceuživatelských kandidátů je možné přijmout další požadavky, aby se zmírnily potenciální vedlejší účinky dále popsaného problému pokračování. Jedním takovým způsobem je zabránit obsloužení víceuživatelských paketů na stejném proložení s dříve započatými a ukončenými víceuživatelskými pakety pro určitý počet slotů (např. spočítaných na daném proložení) následujícím start prvního víceuživatelského paketu. Počet slotů lze nastavit na minimum rozpětí dvou víceuživatelských paketů nebo pokud možno rozpětí prvního víceuživatelského paketu. Tento přístup pomáhá umožnit uživatelům dostat rychle oprávnění k obsloužení v novém víceuživatelském paketu, čímž se zabrání dlouhé nezpůsobilosti.

89723 (0989723_CZ.doc) 16.12.2006

S odkazem na krok 508 po vytvoření seznamu jednouživatelských a víceuživatelských kandidátských instancí přenosu vybere plánovač jednoho z těchto kandidátů (za předpokladu, že výše vygenerovaný seznam obsahuje alespoň jednu kandidátskou instanci přenosu). To se provede vypočtením paketové metriky pro každého kandidáta v seznamu a vybráním kandidáta s největší paketovou metrikou jako vítězného kandidáta. Pokud se vyskytnou vazby, je vhodné upřednostňovat jednouživatelské formáty před víceuživatelskými formáty. Také je vhodné upřednostňovat vysokorychlostní víceuživatelské formáty před nízkorychlostními víceuživatelskými formáty.

V kroku 510 se znovu prošetří přenosový formát vítězné kandidátské instance přenosu a může se změnit, aby se maximalizovala jeho paketovací účinnost, aniž by se změnila sada datových oktetů, které má přenášet. Dokončení kroku 510 proto může zajistit ARQ zesílení.

Pokud je vítězná kandidátská instance přenosu jednouživatelský formát, pak se formát může konvertovat na nekanonický jednouživatelský formát s nejnižší rychlostí, který je kompatibilní s obsluhovanou DRC uživatele, která může nést vybrané datové oktety. Jiná provedení mohou také změnit formát jednouživatelské instance přenosu na víceuživatelský formát.

Mechanismus adaptivního řízení rychlosti přenosu v AT je náchylný k adaptaci jednouživatelských paketů. Mnoho DRC je kompatibilních s nekanonickými jednouživatelskými formáty s menšími zátěžemi, a proto není žádoucí převádět jednouživatelské kandidáty na víceuživatelské formáty, aby

89723 (0989723_CZ.doc) 16.12.2006

- 75 se dosáhlo ARQ zesílení.

Ačkoliv lze víceuživatelské formáty konvertovat na kterékoliv víceuživatelské formáty s nižší rychlostí přenosu (dokud stačí zátěž), je vhodné vyvarovat se obecně rozšířených koverzí formátu kvůli potenciálním nepříznivým účinkům níže popsaného problému pokračování.

S odkazem na obr. 12 může plánovač určit maximální počet slotů (tj. méně než nominální rozpětí vybrané instance přenosu) při jehož překročení nepřenese instanci přenosu i když nemusí detekovat ACKs od uživatelů obsloužených touto instancí přenosu. Protože je tento krok volitelný, lze jej vynechat, takže přístupová síť ukončí vysílání paketů poté, co detekuje ACK od uživatelů obsloužených v tomto paketu, nebo po přenesení plného rozpětí tohoto paketu.

Jedním způsobem implementace tohoto kroku je nastavit maximální počet slotů instance přenosu na:

MaxRozpětí=sa±n(RozpětíPlánTxFormátu,max_is0bslouienít_Jli_vatelé[DRCRozpětí[i] ) )

Kde RozpětíPlánTxFormátu je rozpětí plánováno přenosového formátu a DRCRozpětí[i] je rozpětí kanonického přenosového formátu odpovídající dekódovanému DRC od i-tého obslouženého uživatele v paketu.

Výše bylo popsáno několik parametrů využívaných plánovačem. Zde jsou prezentovány parametry poskytnuté plánovači na rozhraní DSP-driveru. Globální parametry se na tyto parametry, které se týkají všech toků, odkazují a parametry toků se na tyto parametry odkazují pro každý tok zvlášť:

89723 (0989723_CZ.doc) 16.12.2006

-ΙΟΙ. Globální parametry:

a. Časová konstanta toku filtru propustnosti (FlowTPutFilterTimeConstant) - definuje časovou konstantu IIR filtru prvního řádu používanou ke generování průměrné propustnosti, AvgThroughput, proměnné, která se uchovává pro každý tok. Tento filtr se iteruje v každém slotu. Vstupem do filtru je počet oktetů obsloužených z front daného toku v paketu, který začíná v tomto slotu. Filtr se aktualizuje nulovým vstupem ve slotech, ve kterých nezačíná přenos žádného nového paketu.

b. Thrghpt2DelayConvFactorBM - konverzní faktor metriky citlivé na propustnost na metriku citlivou na zpoždění pro výpočet bitové metriky.

c. Thrghpt2DelayConvFactorBSM - konverzní faktor metriky citlivé na propustnost na metriku citlivou na zpoždění pro výpočet bitové vyrovnávací metriky

d. FlowClass - popisuje zda je tok typ citlivý na propustnost nebo typ citlivý na zpoždění.

e. FlowEligibleForDRCErasureMapping - pro použití v DRC algoritmu mazání mapování.

f. ErasureMapDelayTreshold - pro použití v DRC algoritmu mazání mapování.

2. Parametry toku

a. UserID, FlowID - poskytují prostředky pro indexaci a

89723 (0989723_CZ.doc) 16.12.2006

- 77 určení vlastníka každého toku.

b. QoSMetricState, PriorityThold[2] - tyto parametry popisují prioritní stav bitové (vyrovnávací) metriky jako funkci aktuálního zpoždění. Prvky PriorityThold[] matice jsou struktury, které obsahují proměnné DelayThold a QoSMetricState. Když je aktuální zpoždění toku menší než PriorityThold[0].DelayThold, nastaví se prioritní stav na aktuální zpoždění větší než ale větší než

PriorityThold[1].DelayThold, pak se prioritní stav nastaví na PriorityThold[0].QoSMetricState. Pokud je aktuální zpoždění větší než PriorityThold[1].DelayThold, potom se prioritní stav nastaví na PriorityThold[1].QosMetricState. Proměnné QosMetricState nabývají hodnot {0,...,7} podle odpovídajících prioritních stavů {MCO,... MC7}.

QoSMetricState. Pokud je PriorityThold[0].DelayThold,

c. AccelerationFactor

d. AccelerationOffset

e. DelayBound - 0 představuje nekonečno (tj. nikdy nezahazuj oktet předtím, než jej obsloužíš): jinak představuje zpoždění vzhledem časové známce daného oktetu, po kterém se oktet vyhodí z fronty.

f. TargetThroughput - parametr používaný bitovou (vyrovnávací) metrikou toků citlivých na propustnost;

g. FlowAggregatelndex - toky s FlowAggregatelndexem nastaveným na 0 nejsou plánovačem agregovány. Jinak jsou toky se stejnou (nenulovou) hodnotou FlowAgreggatelndexu plánovačem agregovány. Rozsah FlowAgreggatelndexu je omezen

89723 (0989723_CZ.doc) 16.12.2006

• ·

na uživatele, tj . stejný index lze použít pro toky jiného uživatele, aniž by došlo k záměně.

g. IntraFlowPriority - přispívající toky v agregovaném toku (plánovačem) jsou obslouženy podle pořadí

IntraFlowPriority. u přispívajících toků se stejnou IntraFlowPriority se pořadí určí podle časové známky přispívajících toků.

i. GoSFactor - používá se k ohodnocení úrovní kvality služby mezi toky.

j . DSBitMetricValue - hodnota koeficientu bitové metriky v prioritních stavech MCX.

Všimněte si, že na inteface DSP-driveru nejsou toky specifikovány jako BE, AF, EF nebo jakýmkoliv jiným deskriptorem vyšší úrovně. Rozhraní DSP-driveru raději používá jednotný a nízkoúrovňový popis pro všechny toky. Na vyšší úrovni, jako je například BSC, se specifické vysokoúrovňové deskriptory toků, jako například QoS požadavky a BE/EF/AF kategorizace mapují na základní parametry definované v rozhraní DSP-driveru pro každý tok. Takové mapovací tabulky se generují pro možné typy toků dostatečnou simulací a testováním.

Následující příklady ilustrují použití různých parametrů. Pro BE toky lze použít následující parametry:

a. QoSMetricState = 0 (MCO)

b. PriorityThold[].QoSMetricState = {jakýkoliv, jakýkoliv}

c. PriorityThold[].DelayThold = {0,0} (nekočnečno)

d. DelayBound = 0 (Nekonečno)

89723 (0989723_CZ.doc) 16.12.2006

I

Ί9

e. TargetThroughput = 0.

f. FlowAggregatelndex = 1 (agreguj všechny BE toky uživatele)

g. Thrghpt2DelayConvFactorBM = 16.

h. Thrghpt2DelayConvFactorBSM = 128.

i. FlowClass = ThrputSensitive.

j. FlowEligibleForDRCErasureMapping = 0.

k. ErasureMapDelayTreshold = 0 {nekonečno}

Pro AF toky lze použít následující parametry:

a. QoSMetricState = 0 (MCO)

b. PriorityThold[].QoSMetricState = {jakýkoliv, j akýkoliv}

c. PriorityThold[].DelayThold = {0,0} (nekočnečno)

d. DelayBound = 0 (Nekonečno)

e. TargetThroughput = kladná hodnota.

f. FlowAggregatelndex = 0 (žádná agregace)

g. Thrghpt2DelayConvFactorBM = 16.

h. Thrghpt2DelayConvFactorBSM = 128.

i. FlowClass = ThrputSensitive.

j. FlowEligibleForDRCErasureMapping = 0.

k. ErasureMapDelayTreshold = 0 {nekonečno}

Pro EF toky lze použít následující parametry:

a. QoSMetricState = 0 (MCO)

b. PriorityThold[].QoSMetricState = {2,3}

c. PriorityThold[].DelayThold {0,25*DelayBound,0,5*DelayBound}

d. DelayBound = v závislosti na aplikaci

e. TargetThroughput = 0.

f. FlowAggregatelndex = 0 (žádná agregace)

g. Thrghpt2DelayConvFactorBM = 1.

h. Thrghpt2DelayConvFactorBSM = 1.

89723 (0989723_CZ.doc) 16.12.2006 • ·

- 80 i. FlowClass = DelaySensitive.

j. FlowEligibleForDRCErasureMapping = 1.

k. ErasureMapDelayTreshold = 0,25*DelayBound

Signální tok je poskytnut následovně:

a. QoSMetricState = 7 (MC7, nejvyšší priorita)

b. PriorityThold[].QoSMetricState = {7,7}

c. PriorityThold[].DelayThold = {0,0} (nekočnečno)

d. DelayBound = 0 (Nekonečno)

e. TargetThroughput = 0.

f. FlowAggregatelndex = 0 (žádná agregace)

g. Thrghpt2DelayConvFactorBM = 1.

h. Thrghpt2DelayConvFactorBSM = 1.

i. FlowClass = DelaySensitive.

j. FlowEligibleForDRCErasureMapping = 1.

k. ErasureMapDelayTreshold = 0,25*DelayBound

BE/AF toky mohou být upřednostňovány použitím vhodné kombinace následujících parametrů:

l. MCO,...,MC7 stavy umožňují striktní upřednostňování.

2. GoSFactor pro měkké upřednostňování

3. TargetThroughput typicky pro AF toky, které vyžadují nějakou minimální propustnost.

EF toky mohou být dále upřednostňovány použitím vhodné kombinace následujících parametrů:

1. MC0,...,MC7 stavy umožňují striktní upřednostňování.

2. AccelerationOffset umožňuje upřednostňování během bitového vyrovnávání mezi oktety stejného prioritního stavu, ale neovlivňuje přímo výsledný výběr paketu (protože tento druhý krok používá bitovou metriku k výpočtu paketové metriky, která nezávisí na AccelerationOffsetu). Když dva toky patřící ke stejnému uživateli nebo dvěma různým

89723 (0989723_CZ.doc) 16.12.2006

- 81 uživatelům soutěží o zařazení do stejné kandidátské instance přenosu, získá prioritu tok s větším AccelerationOffsetem.

3. DSBitMetricValue ovlivňuje bitové metriky, takže má i přímý účinek na paketovou metriku. Tento parametr lze také použít pro měkké upřednostňování. Nyní tento parametr není implementován.

Rozhraní DSP-Driveru poskytuje flexibilní způsob agregace toků v plánovači. Všimněte si, že agregace prováděné plánovačem jsou odlišné od agregací, které lze provádět BSC. Když BSC agreguje sadu toků, tyto agregáty se plánovači jeví jako jediný tok a plánovač pro tento tok přijme jedinou sadu parametrů. Plánovač nemůže přistupovat k přispívajícím tokům jednotlivě. Pokud agregace proběhne v plánovači, bude plánovač přispívající toky přirozeně znát.

Proměnná AvgThroughput zahrnuje celkovou propustnost agregátu. Určité parametry, jako například DelayBound, specifikované pro přispívající toky agregátu, jsou nastaveny na stejnou hodnotu na rozhraní DSP-driveru. Seznam proměnných, které se nastaví na stejnou hodnotu pro všechny přispívající toky je:

a. UserID

b. Aggregatelndex

c. QoSMetricState

d. PriorityThold[2]

e. AccelerationFactor

f. AccelerationOffset

g. DelayBound

h. TargetThroughput

i. GoSFactor

j. DSBitMetricValue

89723 (0989723_CZ.doc) 16.12.2006 • · ·* · ·

- 82 Parametr, který může být nastaven různě, je IntraFlowPriority a parametr, který musí být nastaven různě je FlowID.

V jednom provedení se agregovanému toku přiřadí jednobitová (vyrovnávací) metrika. Tato metrika je založena na nejstarší časové známce mezi přispívajícími toky agregovaného toku. Časová známka přispívajícího toku se vypočte na základě časových známek hlaviček fronty jeho FTx/RTx/DARQ front. Když se vybere tok pro bitové vyrovnání, ovšem pořadí, ve kterém se toky obsluhují se určí primárně parametry IntraFlowPriority přiřazenými ke každému z přispívajících toků a sekundárně podle časových známek přispívajících toků. Parametr IntraFlowPriority je nejčastěji zamýšlen pro BE toky.

Jak bylo popsáno výše, každý tok má FTx frontu a může mít RTx a/nebo DARQ fronty. V softwarové implementaci se pro každý tok vypočte jedna bitová vyrovnávací metrika. Tato metrika se aplikuje na oktety v FTx frontě stejně jako na oktety v RTx a DARQ frontách. Pokud se vybere tok, který se má obsloužit, obslouží se také jednotlivé fronty v určeném pořadí.

Jedno softwarové provedení poskytuje schopnost zvýšit prioritu toku, pokud jsou RTx a/nebo DARQ fronty neprázdné. To je doprovázeno jednoduchou modifikací hodnoty MetricTS dané v rovnici (3.3 - 2) jako:

Metric_TS GoSFactor * Retransmission Prior ityFactor max(f, AvgThroughput - TargetThroughpuť)

89723 (0989723_CZ.doc) 16.12.2006

RetransmissionPriorityFactor nabývá hodnoty 1, pokud je jak RTx, tak DARQ fronta prázdná. Jiné hodnoty nabývá, pokud je RTx fronta prázdná, ale DARQ fronta obsahuje data. A ještě jiné hodnoty nabývá, pokud je RTx fronta neprázdná.

V revizi A lxEV-DO specifikace určité subtypy protokolů definují nulové DRC kompatibilní se sadou jednouživatelských a víceuživatelských přenosových formátů. Také v Rel-0 specifikace jsou konfigurační atributy definovány pro určité subtypy protokolů, které umožňují přístupové síti obsluhovat uživatele, od kterého byla přijata nulová hodnota DRC s (1024,16,1024) jednouživatelským přenosovým formátem.

V obou případech může plánovač vytvořit kandidátskou instanci přenosu obsahující data pro uživatele, od kterého byla přijata hodnota NULL DRC. Ta se označuje jako NULL-toRate konverze. Plánovač klade na NULL-to-Rate konverze následující omezení:

a. Je povoleno obsluhovat toky s konečnou hranicí zpoždění

b. RTx/DARQ fronty nemohou být obslouženy.

Jiná, než tato omezení plánovač nerozlišuje, zda přijaté DRC od uživatele byla 0x0 (tj . NULL DRC) nebo 0x1 (tj . 38,4 Kbps), přičemž obě jsou definovány jako kompatibilní se stejnými přenosovými formáty v určitých subtypech protokolů v Rev-A. Pro definice konkrétních subtypů protokolu opět odkážeme na tabulku 1.

Když je od uživatele přijato NULL DRC, není záruka, že obsloužený paket bude uživatelem úspěšně dekódován. Budoucí zlepšení může skutečně zahrnovat monitorování, zda uživatelé, kteří poslali NULL DRC, a kteří potom byli

89723 (0989723_CZ.doc) 16.12.2006 • · • ·

- 84 obslouženi v paketu jsou skutečně rozumně úspěšní při dekódování. V závislosti na statistice úspěšnosti může být konverze pro tok vypnuta nebo zapnuta. Jedno provedení hodnotí kandidátské instance přenosu uživatele, kteří vyslali NULL DRC hůře, instance přenosu vytvořené pro uživatele, kteří vyslali DRC 0x1.

vytvořené pro než kandidátské

Lze provést určité rozumné aproximace v softwarové imlementaci, aby se usnadnilo vytvoření kandidátských víceuživatelských instancí, které obsahují data pro toky citlivé na propustnost.

Vzhledem k časování plánovače je časové plánování ve slotu rozděleno do dvou částí; první část je nekritický segment a druhá část je kritický segment. DRC hodnoty uživatelů jsou zpřístupněny v průběhu kritického segmentu. Ovšem kritický segment nemusí poskytovat dostatek cyklů procesoru k provedení výpočtů zahrnutých v plánovači v nejhorším případě zatížení. Proto jsou některé z těchto výpočtů prováděny v nekritickém segmentu. Protože DRC hodnoty některých uživatelů nemusí být v nekritickém segmentu známy, použije softwarová implementace k vytvoření kandidátských instancí přenosu a výběru vítězného kandidáta DRC hodnoty předchozího slotu. Je možné, že se DRC hodnoty některých uživatelů mohou změnit a že vítězný kandidát může přestat být v průběhu kritického segmentu platný. Aby se tento problém překonal, vybere se v nekritickém segmentu více než jeden silný kandidát. Když jsou v kritickém segmentu přijaty aktuální DRC hodnoty, vyhodnotí se omezená sada kandidátů znovu. Omezená sada kandidátů může obsahovat:

a. Malé množství (např. pět) jednouživatelských

89723 (0989723_CZ.doc) 16.12.2006 • · • ·

• · · · • · · • · · • · · • · · · · ·

- 85 kandidátů.

b. Jednoho víceuživatelského kandidáta (pokud byl nějaký vytvořen) s několika záložními uživateli, kteří mohou být v tomto kandidátovi obslouženi, pokud se některý z uživatelů obsloužených v kandidátovi stane nekompatibilním.

V lxEV-DO Rel. 0 AN neplánuje pakety na AT, když je DRC informace vymazána. Když AN obsluhuje více AT s aplikacemi, které nejsou citlivé na zpoždění, např. traffic s nejlepším úsilím, lze tolerovat relativně vysoké DRC rychlosti zpoždění (např. kvůli víceuživatelské diverzitě) bez ztráty kapacity systému. Když je DRC rychlost nepřiměřeně vysoká, nastaví AN DRC zámkový bit na nulu a AT potom může zvolit přehrání na jiný sektor nebo přepnutí do režimu s pevnou rychlostí. Ovšem způsob generování DRC zámkového bitu má zabudované zpoždění, které je alespoň částečně kvůli filtraci, aby se zabránilo nadbytečným přehráním. Proto se na zpětném linku mohou stále objevit relativně dlouhé délky DRC výmazů. Pro aplikace citlivé na zpoždění, např. EF traffic, mohou tyto výmazy vést k nepřijatelnému objemu výpadků služby. Algoritmus mapování DRC výmazu se snaží minimalizovat výpadky služby na FL.

Základní algoritmus je popsán dvěma kroky. První krok vysvětluje rozhodování při mapování DRC výmazu. Druhý krok popisuje změny na FL plánovači lxEV-DO revize A. Obr. 14 popisuje algoritmus mapování DRC výmazu, který běží na AN v každém časovém slotu pro každý AT, který je v režimu proměnné rychlosti. Pro každý AT běží algoritmus pro každý sektor buňky, který má aktivní frontu vytvořenou BSC pro tohoto uživatele. Pro jednoduchost je algoritmus popsán tak, že běží v intervalu každého slotu, ale parametry se

89723 (0989723_CZ.doc) 16.12.2006 • ·

aktualizují pouze jednou za interval délky DRC.

Hlavní výstup algoritmu je Erasure_Mapped_flag, který indikuje plánovači, že mapování DRC výmazu bylo provedeno a že lze provést omezené FL plánování na AT.

DRC_index_store se použije pro uložení posledního platného, tj. úspěšně dekódovaného DRC indexu. Eras_count se použije pro výpočet délky běhu DRC výmazů. Mapování DRC výmazu se provede pouze, pokud je délka běhu výmazu větší naž Max_Ers_Len. Tento práh zajišťuje, že se mapování DRC výmazu provede pouze když je pravděpodobnost výpadku služby relativně vysoká. Pakety mohou být ovšem plánovány AT když je odpovídající zpoždění FL paketu velké. Max_Ers_Len tedy nemůže být příliš vysoká. Pro EF toky, např. VoIP je rozumné nastavení Max_Ers_Len v rozsahu 0 až 16 slotů.

Jak je zobrazeno na obr. 14, způsob 700 nejprve v rozhodovacím kroku 702 otestuje, jestli je DRC vymazána. Pokud je DRC vymazána, zvýší se v kroku 704 Eras_Cnt. Eras_Cnt se potom v kroku 706 porovná s maximální hodnotou Max_Ers_Len. Pokud je Eras_Cnt větší než Max_Eras_Len, nastaví se Erasure_Mapped_flag na 1, jinak se Erasure_Mapped_flag vymaže, tj . nastaví se v kroku 712 na nulu. Pokud není DRC v rozhodovacím kroku 702 vymazána, nastaví se v kroku 708 Erasure_Mapped_flag na 0, Eras_Cnt se nastaví na 0 a DRC_Index_Store se nastaví na DRC_Index. Zpracování pokračuje krokem 712, ve kterém se Erasure_Mapped_flag nastaví na 0.

FL plánovače popsané výše lze modifikovat, aby pracovaly s algoritmem mapování DRC výmazu. Pro každý jednotlivý datový tok každé AT je tok vhodný pro omezené FL

89723 (0989723_CZ.doc) 16.12.2006 • ·

- 87 plánování, pokud:

(ErasureMappedFlag == 1 && FlowEligibleForDRCErasMapping == 1 &&

HeadofQueueDelay > ErasureMapDelayTreshold) kde FlowEligibleForDRCErasMapping je parametr, který indikuje vhodnost každého toku trafficu pro mapování DRC výmazu. Jako výchozí se předpokládá, že EF toky jsou vhodné pro mapování, zatímco BE a AF toky nejsou.

HeadofQueueDelay indikuje hodnotu „Current_Delay pro paket na začátku FL fronty (tj . nejstarší paket v FTx, RTx nebo DARQ frontě). ErasureMapDelayTreshold je minimální požadované zpoždění pro konkrétní tok pro mapování výmazu (má podobný efekt jako „PriorityThold[i].DelayHold. Pokud je tok vhodný pro omezené FL plánování, provedou se na FL plánovači následující úpravy:

a. Tok není vhodný jako kandidát pro jednouživatelskou instanci přenosu

b. Tok je vhodný pro víceuživatelskou instanci přenosu s vyžadovaným DRC indexem, DRC_index_mapped

DRC_index_mapped lze dymanicky měnit jako funkci délky výmazu. Toho lze dosáhnout použitím DRC_index_store a Eras_Count. Výchozí nastavení DRC_indexu lze namapovat na 0x3. Pro FL plánovač bude DRC index 0x3 odpovídat víceuživatelskému přenosovému formátu (1024,4,256), který lze případně převést do formátů ({128,256,512),4,256). Všechny tyto víceuživatelské formáty jsou kompatibilní se všemi DRC indexy, takže AT by měl být schopen dekódovat mapované DRC dokud má dostatečný SINR (nezávislý na aktuálně požadovaném DRC indexu). Alternativní algoritmy mohou být konzervativnější, což omezuje dostupné víceuživatelské

89723 (0989723_CZ.doc) 16.12.2006 • 9

- 88 9 9 · • 9 9 • 9 · « · « · · · • · ·· · přenosové formáty s rostoucím Eras_Count na nižší datové rychlosti.

Všimněte si, že volba DARQ může být pro VoIP zapnuta. Tak v případě, že AT nedekódovala přenesený víceuživatelský paket při prvním pokusu o přenos, poskytne DARQ možnost druhého pokusu o přenos a sníží zbytkovou chybovost paketů. Propustnost DARQ je ovšem svázána s propustností ACK kanálu, který nemusí být velmi spolehlivý, pokud je DRC ve výmazu. ACK/NAK rozhodovací práh může být optimalizován pro DARQ a může záviset na DRC indexu nebo stavu DRC mapování. Jiné provedení činí pokus o DARQ přenos kompatibilním s pouze nízkorychlostními víceuživatelskými formáty paketu, např. (512,4,1024) nebo (256,4,1024), v případě mapování DRC výmazu.

Alternativní provedení mohou poskytovat další kroky a prostředky pro zde prezentovaný plánovač. Například BE/AF toky budou typicky využívat prioritních stavů, které mají striktně nižší prioritu než prioritní stavy. To může vést k degradaci BE/AF propustnosti za přítomnosti EF uživatelů, kteří budou mít vysoce pravděpodobně vyšší prioritní stavy. BE/AF propustnost může být zesílena zvýšením priority BE/AF toků na vyšší stavy za určitých podmínek.

Podle jednoho provedení je AvgRequestedRate filtrovaná požadovaná rychlost uživatele, kde K uživatelů je v systému konfigurováno jako BE uživatelé. Pokud propustnost uživatele pro jeho BE toky, AvgThroughput splňuje:

AvgThroughput < —AvgRequestedRate ,

89723 (0989723_CZ.doc) 16.12.2006

Potom může být uživatelský stav priority pro jeho BE toky zvýšen na vyšší prioritní stavy. Hodnotu a lze vybrat v závislosti na EF zátěži systému, menší a pro vyšší zátěž. Navíc lze předepsat minimální požadovanou rychlost pro uživatele pro tuto podporu. Jsou možné i jiné způsoby zvýšení BE/AF kapacity.

Výše uvedený způsob také navrhuje, že prioritní stav bitové (vyrovnávací) metriky toku nemusí být jenom funkce zpoždění hlavičky fronty, ale může to být také funkce propustnosti toku.

Všimněte si, že ve stavech citlivých na zpoždění je bitová metrika striktně funkcí zpoždění a že nemá žádný mechanismus, kterým by mohla využít lokálních špiček kanálu uživatele. Zde lze hodnotu bitové vyrovnávací metriky ve stavech citlivých na zpoždění modifikovat:

MDS_ds = AccelerationFactor*[CurrentDelay + kCCI] + AccelerationOffset, kde indikátor stavu kanálu (CCI - channel condition indicator) nabývá hodnot z množiny {0,1} nebo intervalu [0,1], které mohou být generovány odděleně, takže když nabývají vyšších hodnot, indikují relativně dobrý stav kanálu ve srovnání s dlouhodobým stavem kanálu uživatele. Také κ je faktor konverze CCI-zpoždění. Udává, jak moc naroste zpoždění toku, když je stav kanálu uživatele relativně dobrý vzhledem k jeho vlastní statistice kanálu.

Jeden jednoduchý způsob, jak generovat CCI pro binární {0,1} případ je dán následovně. Nechť je Ratelndex celé číslo přiřazené k DRC hodnotám v pořadí rostoucí rychlosti, kde DRC hodnota není použita, protože neroste

89723 (0989723_CZ.doc) 16.12.2006 • ·

- 90 monotónně s rostoucí datovou rychlostí. Nechť je AvgRatelndex průměrný (filtrovaný) Ratelndex uživatele. Nechť CCITreshold je parametr jako například 1,2. Potom pokud Ratelndex > CCITreshold * AvgRatelndex, lze hodnotu CCI nastavit na jedničku. Jinak se nastaví na nulu. V tom případě bude CCI indikovat relativně dobrý stav kanálu, pokud je aktuální Ratelndex odpovídající přijímanému DRC 120% nebo vyšší než průměrná kvalita.

Nucené přerušení označuje stornování FL přenosu předtím, než jej dekódují cíloví uživatelé. Nucené přerušení lze použít, pokud se objeví vysoce prioritní data, zatímco všechna čtyři křížení na FL jsou obsazena relativně pomalými uživateli. Plánovací algoritmus nyní neposkytuje způsob nuceného přerušení přicházejících přenosů. Jedním z důvodů je, že i když jsou pečlivě sledované, mohou nekontrolovaná nucená přerušení vést ke ztrátám kapacity.

Zde použitý přístup předchází okolnostem, které mohou vyžadovat nucené přerušení. Jedním takovým stavem je, jak bylo zmíněno výše, když jsou všechna čtyři křížení obsazena pomalými uživateli. Lze použít jednoduchých způsobů, aby se tomuto předešlo. Jedním takovým způsobem je nepovolit větší než pevně daný počet simultánních přenosů formátů s 16slotovými a 8-slotovými rozpětími. Jako příklad lze toto číslo nastavit na 2 nebo 3.

Jedno provedení monitoruje propustnost dekódování uživatelů, kteří přenášejí NULL DRC a jsou obsloužení v paketu. V závislosti na změřeném PER v těchto NULL-to-rate případech je možné pro každého uživatele zapnout/vypnout NULL-to-rate konverze. Podobně je možné vypnout/zapnout omezení obsloužení RTx/DARQ front, stejně jako front toku

89723 (0989723_CZ.doc) 16.12.2006

s nekonečnou hranicí zpoždění v NULL-to-rate instancích, pokud souhrnná statistika indikuje, že přístupový terminál dostatečně spolehlivě dekóduje tyto pakety.

Koeficienty bitové a bitové vyrovnávací metriky pro toky citlivé na propustnost poskytují proporcionální rovnost pouze v BE systému (např. TargetThrouhgput = 0 a GoSFaktor = 1 pro všechny toky) s uživateli, kteří mají velká množství dat, která mohou přijímat. Tuto formu koeficientu metriky lze použít podobným způsobem v ostatních plánovačích. Pro tyto účely lze koeficienty metriky pro toky citlivé na propustnost vyjádřit jako:

Metric^ =-if (AvgThroughpuť)h(Avg Re questedRaíe) kde f(.) a h(.) jsou generické funkce a AvgRequestedRate je průměrná požadovaná rychlost uživatele. Nastavením f(x) = x a h(x) = x dává přibližně stejný GoS plánovače.

Zdokonalený MAC protokol kanálu přímého trafficu definovaný v revizi A lxEV-DO specifikaci dává omezení na obsluhování uživatelů v následujícím víceuživatelském paketu, jak je sumarizováno níže. Specifikace revize A určuje, že slot T se definuje jako pokračování dřívějšího slotu s, pokud jsou splněny následující podmínky:

c. Přístupový terminál je potenciální cíl paketu, jehož přenos začíná ve slotu s.

d. Slot t je ve stejném FL křížení jako slot s, tj. t-s = 0(mod 4).

89723 (0989723_CZ.doc) 16.12.2006 • ♦ 4 · • 4

- 92 e. s < t < s + 4N, kde N označuje rozpětí DRC indexu odpovídající DRC hodnotě, která je v průběhu slotu aktuální.

f. Před slotem t přístupová síť nepřijímala kladná potvrzení pro pakety, jejichž přenos začal ve slotu s.

Pokud je přístupový terminál potencionální cíl paketu přeneseného sektorem začínajícím ve slotu s, přístupová síť nepřenese nový paket ze stejného FL datového zdroje na přístupový terminál v kterémkoliv slotu t, který je pokračováním slotu s.

Výše uvedená omezení kladou podmínky na to, kteří uživatelé mohou být obslouženi víceuživatelským paketem. Jako příklad, pokud přístupová síť předá víceuživatelský paket sadě uživatelů, který potom dříve skončí, pak nemůže přístupová síť předat jakékoliv pakety (jednouživatelské nebo víceuživatelské) v průběhu pokračování paketu předaného uživatelům, kteří nebyli obslouženi v předchozím paketu, ale byli kompatibilní s jeho formátem. V jedné situaci předává přístupová síť 153,6 Kbps víceuživatelský paket a uživatelé s daty nesenými v tomto paketu jej dekódují v méně než 4 slotech. Pokud přístupová síť bezprostředně předá jiný

153,6 Kbps víceuživatelský paket na stejném křížení, pak uživatelé, kteří aktuálně požadovali 153,6 Kbps nebo jakoukoliv DRC s rozpětím 4 slotů, ale nebyli obslouženi v předchozím paketu, nebudou moci být obsloužení v novém přenosu. Proto mohou být v novém přenosu obsloužení pouze ti uživatelé, kteří požadovali DRCs s rozpětím menším než 4 sloty, tj. typicky uživatelé s lepším stavem kanálu. To ovšem ještě zvyšuje pravděpodobnost, že nový paket bude dekódován dříve. Tento řetěz může pokračovat, dokud se

89723 (0989723_CZ.doc) 16.12.2006 • ·

- 93 ·· · fronty uživatelů vyšší geometrie nevyprázdní. Mezitím nejsou obslouženi uživatelé s nižší geometrií, kteří požadují DRCs s rozpětím 4 slotů. Výsledkem by mohlo být přílišné zpoždění pro uživatele s nižší geometrií a možné malé zvětšení zpoždění pro uživatele s vyšší geometrií.

Všimněte si, že výše uvedená provedení, aspekty a příklady se týkají systémů podporujících vysokorychlostní datový protokol. Takový systém je prezentován pro jasnost a pochopení předložených myšlenek. Zde prezentovaný způsob a prostředky pro adaptivní správu zpoždění a plánování mohou implementovat i alternativní systémy.

Byl tedy popsán nový a vylepšený způsob a zařízení pro plánování přenosů v komunikačním systému. Odborníkům bude zřejmé, že data, instrukce, příkazy, informace, signály, bity, symboly a čipy, na které se ve výše uvedeném popisu odkazuje, jsou výhodně reprezentovány napětími, proudy, elektromagnetickými vlnami, magnetickými poli nebo částicemi, optickými poli nebo částicemi nebo jakoukoliv jejich kombinací. Odborníci dále uznají, že různé ilustrativní logické bloky, moduly, obvody a kroky algoritmu popsané ve spojení s provedeními implementovat jako elektronický software nebo kombinaci obojího, komponenty, bloky, moduly, obvody tohoto vynálezu lze hardware, počítačový

Různé ilustrativní a kroky byly obecně popsány ve smyslu jejich funkcionality. To, zda je tato funcionalita implementována jako hardware nebo software závisí na konkrétní aplikaci a omezeních návrhu kladených na celý systém. Odborníci za těchto okolností uznají záměnnost hardwaru a softwaru a jak nejlépe implementovat popsané funkcionality pro každou konkrétní aplikaci. Různé ilustrativní logické bloky, moduly, obvody a kroky

89723 (0989723_CZ.doc) 16.12.2006

*· »··♦

algoritmu, které jsou popsány ve spojení se zde uvedenými provedeními lze implementovat nebo provádět například pomocí digitálního signálového procesoru (DSP), aplikačně specifického integrovaného obvodu (ASIC), programovatelného hradlového pole (FPGA - field programmable gate array) nebo jiných programovatelných logických zařízení, diskrétních hradel nebo transistorové logiky, diskrétních hardwarových registrů a FIFO, procesoru komponent jako např. provádějícího sadu firmwarových instrukcí, konvenčního programovatelného softwarového procesoru nebo jakékoliv jejich kombinace j akéhokoliv modulu a navržené k provádění zde popsaných funkcí. Procesor může být výhodně mikroprocesor, ale alternativně může být procesor jakýkoliv konvenční procesor, řadič, mikrořadič, programovatelné logické zařízení, pole logických prvků nebo stavový stroj. Softwarový modul může být uložen v paměti RAM, flash, ROM, EPROM, EEPROM, registrech, na harddisku, na výměnném disku, CD-ROM nebo jakékoliv jiné v technice známé formě paměťového média. Ukázkový procesor je výhodně připojen k paměťovému médiu, aby z něj mohl číst a zapisovat na něj informace. Alternativně může být paměťové médium integrováno do procesoru. Procesor a paměťové médium se mohou nacházet v ASIC. ASIC se může nacházet v telefonu nebo jiném uživatelském terminálu. Alternativně se mohou procesor a paměťové médium nacházet v telefonu nebo jiném uživatelském terminálu. Procesor lze implementovat jako kombinaci DSP a mikroprocesoru, nebo dvou mikroprocesorů ve spojení s DSP jádrem atd.

89723 (0989723_CZ.doc) 16.12.2006 ·· • · · • · • · ·· ····

•· · · ··

Byla ukázána a popsána upřednostňovaná provedení tohoto vynálezu. Běžným odborníkům bude ovšem zřejmé, že lze provést řadu obměn, aniž bychom se odchýlili od rozsahu a podstaty tohoto vynálezu. Proto tento vynález nemá být nijak omezen kromě následujících nároků.

Claims (4)

1. Způsob plánování instancí přenosu v bezdrátovém komunikačním systému obsahující:

přijetí indikátorů stavu kanálu od množství mobilních uživatelů, kde indikátory stavu kanálu odpovídají komunikaci přímým línkem;

určení kritéria zpoždění pro množství mobilních uživatelů a určení plánu přenosů pro množství mobilních uživatelů, kde plán přenosů je funkce kritéria zpoždění.

2. Způsob plánování instancí přenosu v bezdrátovém komunikačním systému, obsahující:

vyhodnocení množství přenosových front pro identifikaci citlivosti na zpoždění a citlivosti na propustnost aplikačního toku přiřazeného každé přenosové frontě;

vygenerování sady kandidátských instancí přenosu z množství přenosových front;

výběr jedné kandidátské instance přenosu z této sady a přípravu vybrané kandidátské instance přenosu pro přenos.

3. Způsob podle nároku 2, kde vygenerování sady kandidátských instancí přenosu obsahuje:

vygenerování bitové metriky pro každou frontu a vygenerování bitové vyrovnávací metriky pro každou frontu.

4. Způsob podle nároku 3, kde výběr jedné kandidátské instance přenosu obsahuje:

09 89723 (0989723_CZ.doc) 16.12.2006 ·· • · ·· r * ···· ·· ·*·· • · · • · · • · · · • · · ·· · vygenerování paketové metriky jako funkce bitové metriky a porovnání paketových metrik pro jednotlivé kandidátské instance přenosu v sadě.