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

Zpusob a zarízení pro adaptivní správu zpozdení vbezdrátovém komunikacním systému Download PDF

Info

Publication number
CZ2006687A3
CZ2006687A3 CZ20060687A CZ2006687A CZ2006687A3 CZ 2006687 A3 CZ2006687 A3 CZ 2006687A3 CZ 20060687 A CZ20060687 A CZ 20060687A CZ 2006687 A CZ2006687 A CZ 2006687A CZ 2006687 A3 CZ2006687 A3 CZ 2006687A3
Authority
CZ
Czechia
Prior art keywords
data
user
delay
scheduler
packet
Prior art date
Application number
CZ20060687A
Other languages
English (en)
Inventor
J. Black@Peter
Gurelli@Mehmed
Yavuz@Mehmed
Bhushan@Naga
Original Assignee
Qualcomm Incorporated
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Incorporated filed Critical Qualcomm Incorporated
Publication of CZ2006687A3 publication Critical patent/CZ2006687A3/cs

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0002—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0015—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
    • H04L1/0017—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy where the mode-switching is based on Quality of Service requirement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0015—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
    • H04L1/0017—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy where the mode-switching is based on Quality of Service requirement
    • H04L1/0018—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy where the mode-switching is based on Quality of Service requirement based on latency requirement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/20—Arrangements for detecting or preventing errors in the information received using signal quality detector
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0231—Traffic management, e.g. flow control or congestion control based on communication conditions
    • H04W28/0236—Traffic management, e.g. flow control or congestion control based on communication conditions radio quality, e.g. interference, losses or delay
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
    • H04W72/543—Allocation or scheduling criteria for wireless resources based on quality criteria based on requested quality, e.g. QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/56—Allocation or scheduling criteria for wireless resources based on priority criteria
    • H04W72/566—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient
    • H04W72/569—Allocation or scheduling criteria for wireless resources based on priority criteria of the information or information source or recipient of the traffic information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H04W8/20—Transfer of user or subscriber data

Landscapes

  • Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

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

ZPÛSOB A ZARÎZENÎ PRO ADAPTIVNI SPRAVU ZPOZDËNI V BEZDRÂTOVÉM KOMUNIKACNÎM SYSTÉMU
Tato patentovâ pfihlâska nârokuje prioritu z provizorni pfihlâsky c. 60/568 650 nazvané ,,Adaptive delay management (Adaptivni sprâva zpozdëni) podané 5. kvëtna 2004 a postoupené nabyvateli této pfihlâsky a zde vÿslovnë zaclenëné odkazem.
Tato patentovâ pfihlâska nârokuje prioritu z provizorni pfihlâsky c. 60/625 660 nazvané ,,Adaptive delay management (Adaptivni sprâva zpozdëni) podané 4. listopadu 2004 a postoupené nabyvateli této pfihlâsky a zde vÿslovnë zaclenëné odkazem.
Oblast techniky
Vynâlez se tÿkâ komunikaci a podrobnëji se tÿkâ plânovâni pfenosû v bezdrâtovém komunikacnim systému pouzitim adaptivni sprâvy zpozdëni.
Dosavadni stav techniky
Bezdrâtové komunikacni systémy obsahuji systémy pro zpracovâni komunikace, které pouzivaji technologii obvodovë spinané nebo fixni alokace prostfedkû, a systémy zpracovâni komunikace pouzivajici technologii paketovë spinané nebo dynamické alokace prostfedkû. Jak obvodové spinâni tak paketové spinâni Ize pouzit ve vysokokapacitnich sitich. V komunikacnich systémech s obvodovÿm spinânim se vytvofi
89723 (0989723_CZ.doc) 16.12.2006 vyhrazenâ komunikacni trasa mezi vysilacem a prijimacem, a sitové prostfedky mezi vysilacem a pfijimacem se pred zacâtkem pfenosu povazuji za statické, tudiz vytvâfi ,,obvod . Prostfedky zûstâvaji vyhrazeny obvodu bëhem celého pfenosu a vsechny zpravy se pfenâseji po stejné trase. V paketovë spinanÿch sitich se zprâva rozdëli na pakety, pficemz kazdÿ paket se mûze do elle pohybovat po jiné trase. Po pfijeti se pakety rekompiluji, aby se ziskala pûvodni zprâva. V paketovë spinaném systému se pakety pfedstavujici zpravy nebo fragmenty zprâv individualnë smëruji mezi uzly. Pakety se po vhodné trase smëruji do cile. Jinÿmi slovy ne vsechny pakety pfenâsené mezi dvëma stejnÿmi hostiteli se budou nezbytnë pfenâset po stejné trase, i kdyby byly tyto pakety soucâsti stejné zpravy.
V paketovë spinaném systému nebo sdileném paketovém datovém systému Ize k emulaci obvodovë spinané hlasové komunikace pouzit sluzbu Voice over Internet Protokol (VoIP). VoIP je typicky aplikace nebo sluzba citlivâ na zpozdëni, a proto se pouzivaji mechanizmy Kvality sluzby (QoS), aby byly splnëny pozadavky na zpozdëni doruceni paketu. Jiné sluzby a druhy pfenosû maji také rûzné pozadavky na zpozdëni nebo cile k zajistëni QoS. Navic je potfeba zajistit adaptivni sprâvu zpozdëni pro plânovâni prenosû v komunikacnim systému.
Podstata vynâlezu
Provoz komunikacniho systému s podporou sluzeb a aplikaci s rûznÿmi QoS pozadavky mûze bÿt neoptimâlni a neefektivni. Napfiklad VoIP aplikace maji pozadavky na zpozdëni. Jeden zpûsob emuluje voice zajistënim stejnÿch
89723 (0989723_CZ.doc) 16.12.2006 pozadavkû na zpozdëni pro vice uzivatelû nezâvisle na zâtëzi a pokryti. Takovÿ pristup je pro alokaci prostfedkû pro zajistëni stejného zpozdëni neoptimâlni a vylucuje optimalizace, které by byly mozné ke zvÿseni kapacity systému. V jednom provedeni Ize kapacitu systému zvÿsit zajistënim rûznÿch zpozdëni pro rûzné uzivatele, kde se prostredky alokuji jako funkce zâtëze a pokryti.
Nâsledujici popis se tÿkâ plânovaciho algoritmu pro primÿ link (FL - forward link) systému podporujiciho IxEV-DO traffic, tj. podporujiciho IS-856 specifikaci. V jednom provedeni vyuzivâ v jednom provedeni plânovaci algoritmus rûznÿch multi-user paketû a krâtkÿch paketu, aby RA splnil pozadavky kvality QoS rûznÿch aplikaci pri maximalizaci kapacity FL. Plânovaci algoritmus poskytuje také mechanismus, kterÿ uprednostnuje rûzné aplikace. Takové uprednostnovâni mûze bÿt zalozeno na typu aplikacniho toku, specifickÿch QoS pozadavcich, nebo jinÿch charakteristikâch toku. V jednom provedeni se toky plânuji pro prenos na zâkladë senzitivity zpozdëni aplikace. V jednom aspektu jsou toky diferencovâny na zâkladë citlivosti na zpozdëni vyvâzené citlivosti na propustnost. Zatimco nâsledujici popis posuzuje plânovaci prostredky a zpûsoby jako implementované v kontextu Revize A specifikace IxEV-DO, plânovaci prostredky a zpûsoby jsou dâle pouzitelné v alternativnich systémech, zvlâstë koncepty jsou pouzitelné v systémech, jejichz uzivatelé jsou kompatibilni s danou podmnozinou 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, fijen 2002.
V nâsledujicim popisu se pojmy jako „Rev-A uzivatel nebo „uzivatel kompatibilni s Rev-A budou pouzivat
89723 (0989723_CZ.doc) 16.12.2006 k oznaceni pristupového terminait! (AT), kterÿ podporuje vrstvu kanâlu pfistupu 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 uzivatel urychlenÿ MAC protokol kanâlu primého trafficu. Pojmy jako „Rel-0 uzivatelé se pouzivaji k oznaceni ATs podporujicich subtypy protokolu MAC vrstvy a fyzické vrstvy definovanÿch v IS-856, ale které nepodporuji novëjsi subtypy definované v revizi A.
V bezdrâtovém komunikacnim systému, kterÿ vyuzivâ schématu kôdového multiplexu (CDMA), prifazuje jeden zpûsob plânovâni kazdé ucastnické stanici vsechny kôdové kanâly ve vyhrazenÿch casovÿch intervalech na bâzi casového multiplexu. Aby se umoznila exkluzivni komunikace s ucastnikem, implementuje centrâlni komunikacni uzel, jako napfiklad zâkladnovâ stanice, (Base Station - BS) , unikâtni nosnou frekvenci nebo kôd kanâlu prifazenÿ ùcastnikovi. TDMA schémata Ize implementovat také v pevnÿch sitich pouzivajicich fyzické kontaktni reléové spinâni nebo paketové spinâni. CDMA systém Ize navrhnout tak, aby podporoval jeden nebo vice standardù jako napriklad (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 nabizenÿ konsorciem „3rd Generation Partnership Project, na které se zde odkazuje jako 3GPP; a realizovanÿ v sadë dokumentû zahrnujici dokumenty cislo: 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 nabizenÿ konsorciem „3rd Generation Partnership Project 2 zde oznacovanÿm jako 3GPP2 a TR-45.5, zde oznacovanÿ jako
89723 (0989723_CZ.doc) 16.12.2006 cdma2000 standard, drive oznacovanÿ jako „13-2000 MC, nebo (4) nëkterÿ jinÿ standard bezdrâtové komunikace.
CDMA systém umoznuje hlasovou a datovou komunikaci mezi uzivateli prostfednictvim pozemniho linku. V CDMA systému probihâ komunikace mezi uzivateli prostrednictvim jedné nebo vice zâkladnovÿch stanic. V bezdrâtovÿch komunikacnich systémech se jako pfimy link oznacuje kanâl, kterÿm se siri signâly ze zâkladnové stanice na ucastnickou stanici a zpëtnÿ link oznacuje kanâl, kterÿm se prenâseji signâly z ùcastnické stanice na zâkladnovou stanici. Pfenosem dat na zpëtném linku na zâkladnovou stanici komunikuje prvni uzivatel na prvni ucastnické stanici s druhyrn uzivatelem na druhé ùcastnické stanici. Zâkladnovâ stanice prijimâ data z prvni ucastnické stanice a smëruje tato data na zâkladnovou stanici obsluhujici druhou ucastnickou stanici. V zâvislosti na vzdâlenosti ucastnickÿch stanic mohou bÿt obë obsluhovâny jednou zâkladnovou stanici nebo vice zâkladnovÿmi stanicemi. V kazdém pripadë vysilâ zâkladnovâ stanice obsluhujici druhou ucastnickou stanici data na pfimÿ link. Misto komunikace s druhou ucastnickou stanici mûze ùcastnickâ stanice komunikovat také s terestrickÿm internetem prostrednictvim spojeni s obsluhujici zâkladnovou stanici. V bezdrâtové komunikaci, jako napriklad té splhujici IS—95, se signâly primého a zpëtného linku prenâseji v odlisnÿch frekvencnich pâsmech.
Prehled obrâzkû na vykresech
Vynâlez bude blize vysvëtlen prostrednictvim konkrétnich prikladû provedeni znâzornënÿch na vykresech, na kterÿch predstavuje
89723 (0989723_CZ.doc) 16.12.2006
obr. 1Ά bezdrâtovÿ komunikacnî systém,
obr. IB bezdrâtovÿ komunikacnî systém s podporou vysokorychlostnich datovÿch prenosù,
obr. 2 blokové schéma pristupové site (AN - Access Network) bezdrâtového komunikacniho systému,
obr. 3 vÿvojovÿ diagram plânovaciho algoritmu pro pfenosy v bezdrâtovém komunikacnîm systému,
obr. 4 kategorizaci plânovacù datovÿch paketû,
obr. 5 zpëtnovazebni smycku pro urceni mohutnosti kanâlu na zâkladë prijatÿch pozadavkù na data od uzivatele,
obr. 6 chovâni plânovace za pritomnosti uzivatelû s uprednostnovanÿm smërovânim s jednoduchÿm typem prenosù,
obr. 7 vÿpocet kondenzovaného zâtëzového polynomu c(z) ze zâtëzového polynomu p(z),
obr. 8 plânovac podle jednoho provedeni,
obr. 9 cast plânovace z obr. 8 podle jednoho provedeni,
obr. 10 plânovaci algoritmus pro implementaci adaptivni sprâvy zpozdëni prenosù,
obr. 11 cast plânovaciho algoritmu obr. 10 podle jednoho
89723 (0989723_CZ.doc) 16.12.2006 provedeni, obr. 12 cast plânovaciho algoritmu obr. 10 podle jednoho provedeni, obr. 13 cast plânovaciho algoritmu obr. 10 podle jednoho provedeni.
Priklady provedeni vynâlezu
Obr. IA slouzi jako priklad komunikacniho systému 100, kterÿ podporuje vice uzivatelû a je schopen implementovat alespoh nëkteré aspekty tohoto vynâlezu. K plânovâni pfenosû v systému 100 Ize pouzit kterÿkoliv z mnoha algoritmu a zpûsobû. Systém 100 poskytuje komunikaci pro mnozstvi bunëk 102A az 102G, z nichz kazdâ je obsluhovânâ zâkladnovou stanici 104A az 104G v tomto poradi. V ukâzkovém provedeni maji nëkteré zâkladnové stanice 104 vice prijimacich antén nebo maji pouze jednu prijimaci anténu. Podobnë nëkteré zâkladnové stanice 104 maji vice vysilacich antén a jiné maji jedinou vysilaci anténu. Nejsou zde zâdnâ omezeni na kombinaci vysilacich a prijimacich antén. Proto je pro zâkladnovou stanici 104 mozné, aby mêla vice vysilacich antén a jedinou prijimaci anténu, nebo aby mêla vice prijimacich antén a jedinou vysilaci anténu, nebo aby mêla jednu nebo vice jak vysilacich tak prijimacich antén.
Rostouci poptâvka po bezdrâtovÿch datovÿch prenosech a rozsirovâni sluzeb dostupnÿch prostrednictvim bezdrâtovÿch komunikacnich technologii vedly k rozvoji specifickÿch
89723 (0989723_CZ.doc) 16.12.2006 datovÿch sluzeb. Jednou z tëchto sluzeb je vysokâ rychlost pfenosu ,,HDR — High data rate. Pfiklad sluzby HDR je navrzen v „EIA/TIA—IS856 cdma2000 specifikaci vysokorychlostniho paketového datového vzdusného rozhrani , oznacované jako „HDR specifikace. Sluzba HDR je obecnë nâstavbou hlasového komunikacniho systému, kterâ poskytuje ùcinnÿ zpûsob pfenosu datovÿch paketû v bezdrâtovém komunikacnim systému. S rostoucim objemem pfenâsenÿch dat a poctem pfenosu se omezenâ sifka pâsma pro radiové pfenosy stane kritickÿm prostfedkem.
Obr. IB ukazuje referencni model architektury pro komunikacni systém 120 s pfistupovou siti AN 122, kterâ komunikuje s pfistupovÿin terminâlem AT 126 prostrednictvim vzduchového rozhrani 124. V jednom provedeni je systém 10 systém s kôdovÿm multiplexem CDMA s vysokorychlostnim (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 (neni zobrazeno) prostrednictvim vzduchového rozhrani 124. AN 122 obsahuje vice sektorû, kde kazdÿ sektor poskytuje alespon jeden kanâl. Kanâl je definovân jako sada komunikacnich linkû pro pfenosy mezi AN 122 a AT s danÿm pfifazenim frekvenci. Kanâl se sklâdâ z pfimého linku (FL) pro pfenosy z AN 122 na AT 126 a zpëtného linku (RL) pro pfenosy z AT 126 na AN 122.
Pro datové pfenosy prijimâ AN 122 datové pozadavky z AT 12 6. Datové pozadavky specifikuji rychlost, s jakou se maji data vysilat, délku vysilaného datového paketu a sektor, ze kterého se data maji vysilat. AT 126 urcuje rychlost pfenosu dat zalozenou na kvalitë kanâlu mezi AN 122 a AT 126. V jednom provedeni je kvalita kanâlu dâna pomërem nosné k interferenci, C/I. Alternativni provedeni mohou
89723 (0989723_CZ.doc) 16.12.2006 pouzivat jiné miry odpovidajici kvalitë kanâlu. AT 126 poskytuje pozadavky na datové pfenosy vyslânim zprâvy fizeni rychlosti prenosu dat, DRC - Data Rate Control, specifickÿm kanâlem, kterÿ se oznacuje jako DRC kanâl. DRC zprâva obsahuje cast rychlosti prenosu dat a sektorovou cast. Cast rychlosti prenosu dat indikuje pozadovanou datovou rychlost, kterou ma AN 122 vysilat data a sektor oznacuje sektor, ze kterého bude AN 122 data vysilat. Jak datovâ rychlost, tak informace o sektoru jsou typicky pozadovâny procesem prenosu dat. Cast rychlosti prenosu dat se oznacuje jako DRC hodnota a sektorovâ cast se oznacuje jako DRC obâlka. DRC hodnota je zprâva vysilanâ AN 122 prostfednictvim vzduchového rozhrani 124. V jednom provedeni odpovida kazdâ DRC hodnota rychlosti prenosu dat v kbit/s s prifazenou délkou paketu podle predem daného pfifazeni DRC hodnoty. Prifazeni zahrnuje DRC hodnotu specifikujici nulovou rychlost prenosu dat. V praxi nulovâ rychlost prenosu dat AN 122 sdëluje, ze AT 126 neni schopen pfijimat data. Napriklad se jednâ o situaci, kdy je kvalita kanâlu pro AT 126 nedostatecnâ na to, aby pfijimal data pfesnë.
Za provozu AT 126 souvisle monitoruje kvalitu kanâlu, aby se vypocetla rychlost prenosu dat, kterou je AT 126 schopen pfijmout dalsi vyslanÿ datovÿ paket. AT 126 potom vygeneruje odpovidajici hodnotu DRC, tato DRC hodnota se prenese na AN 122, aby se vyzâdal datovÿ pfenos. Vsimnëte si, ze datové pfenosy jsou typicky rozdëleny do paketu. Cas vyzadovanÿ k prenosu paketu dat je funkci pouzité rychlosti prenosu dat.
DRC signâl poskytuje také informaci o tom, kterÿ kanâl plânovac pouzije k urceni okamzité rychlosti pfijmu informace (nebo pfijmu pfenâsenÿch dat) pro kazdou ze
89723 (0989723_CZ.doc) 16.12.2006 vzdâlenÿch stanic pfidruzenou k jednotlivÿm frontâm. Podle tohoto provedeni DRC signal vysilanÿ z kterékoliv vzdâlené stanice indikuje, ze vzdâlenâ stanice je schopnâ pfijimat data na kterékoliv z vice efektivnich rychlosti pfenosu dat.
Jeden priklad komunikacniho systému podporujiciho HDR prenosy prizpûsobené pro plânovâni vysilâni ve viceuzivatelskÿch systémech je zobrazen na obr. 2. Obr. 2 je detailnë popsân nize, kde se konkrétnë zâkladnovâ stanice 820 a radie 810 zâkladnové stanice propojuji s paketovÿm sitovÿm rozhranim 806. Radie 810 zâkladnové stanice obsahuje plânovac 812 kanâlu pro implementaci plânovaciho algoritmu pro prenosy v systému 800. Plânovac 812 kanâlu urcuje délku servisniho intervalu, bëhem kterého se data, kterâ se maji prenâset na kteroukoliv konkrétni vzdâlenou stanici zalozenâ na okamzité rychlosti pfijmu dat touto vzdâlenou stanici (jak je udâno v poslednim prijatém DRC signâlu). Servisni interval nemusi bÿt spojitÿ v case, ale muze se vyskytovat jednou za nëkolik slotù. Podle jednoho provedeni se prvni câst paketu prenâsi bëhem prvniho slotu v prvnim case a druhâ câst se prenâsi o 4 sloty pozdëji. Po sobë jdouci câsti paketu se tedy prenâseji ve vice slotech s podobnÿm rozprostrenim na 4 sloty, tj . 4 sloty od sebe. Podle nëkterého provedeni urcuje okamzitâ rychlost prijmu dat Ri délky servisniho intervalu Li spojenou s konkrétni datovou frontou.
Navic, plânovac 812 kanâlu vybere konkrétni datovou frontu pro pfenos. Prirazené mnozstvi dat, které se mâ pfenést, se potom pfijimâ z datové fronty 830 a predâvâ se kanâlovému prvku 826 pro prenos na vzdâlenou stanici spojenou s datovou frontou 830. Jak je popsâno nize, vybirâ plânovac 812 kanâlu frontu pro poskytnuti dat, kterâ se
89723 (0989723_CZ.doc) 16.12.2006 pfenâseji v nâsledujicim servisnim intervalu za pouziti informaci obsahujicich vâhu pfifazenou k jednotlivÿm frontâm. Vâha pfifazenâ k pfenâsené frontë se potom aktualizuje.
Radie 810 zâkladnové stanice je propojen s paketovÿm sit’ovÿm. rozhranim 806, vefejnou pfepinanou telefonni siti, vefejnou prepinanou telefonni siti (PSTN), 808 a zâkladnovÿmi stanicemi v komunikacnim systému (na obr. 3 je pro jednoduchost zobrazena pouze jedna zâkladnovâ stanice 820). Radie 810 zâkladnové stanice koordinuje komunikaci mezi vzdâlenÿmi stanicemi v komunikacnim systému a ostatnimi uzivateli pfipojenÿmi k paketovému sit’ovému rozhrani 806 a PSTN 808. PSTN 808 je propojen s uzivateli prostfednictvim standardni telefonni site (neni zobrazeno na obr. 3).
Radie 810 zâkladnové stanice obsahuje mnoho selektorû 816, ackoliv je na obr. 2 pro jednoduchost zobrazen pouze jeden z nich. Kazdÿ selektor 816 je urcen k fizeni komunikace mezi jednou nebo vice zâkladnovÿmi stanicemi 820 a jednou vzdâlenou stanici (neni zobrazeno). Pokud neni selektor 816 pfifazen k dané vzdâlené stanici, je procesor 818 fizeni hovoru informovân o nutnosti pagingu vzdâlené stanice. Procesor 818 fizeni hovoru potom fidi zâkladnovou stanici 820 tak, aby provedla paging na vzdâlenou stanici.
Zdroj 802 dat obsahuje mnozstvi dat, kterâ se maji pfenâset na danou vzdâlenou stanici. Zdroj 802 dat poskytuje data paketovému sitovému rozhrani 806. Paketové sitové rozhrani 806 pfijimâ data a smëruje data na selektor 816. Selektor 816 potom pfenâsi data na kazdou zâkladnovou
89723 (0989723_CZ.doc) 16.12.2006 stanici 820 pri komunikaci s cilovou vzdâlenou stanici. V ukâzkovém provedeni udrzuje kazdâ zâkladnovâ stanice 820 datovou frontu 830, ve které se uklâdaji data, kterâ se maji prenâset na vzdâlenou stanici.
Data se prenâseji v datovÿch paketech z datové fronty 830 do kanâlového prvku 826. V ukâzkovém provedeni na primém linku „datovÿ paket odkazuje na mnozstvi dat, které je maximâlnë 1024 bitû a mnozstvi dat, kterâ se maji prenést na cilovou vzdâlenou stanici v predem daném „casovém slotu (jako napriklad «1,667 ms). Pro kazdÿ datovÿ paket vklâdâ kanâlovÿ prvek 826 nezbytnâ kontrolni pole. V ukâzkovém provedeni provâdi kanâlovÿ prvek 826 cyklickou kontrolu redundance (Cyclic Redundancy Check - CRC), kôduje datové pakety a fidici pole a vklâdâ sadu bitû uzavirajicich kôd. Datové pakety, fidici pole, CRC paritni bity a bity uzavirajici kôd tvofi formâtovanÿ paket. V ukâzkovém provedeni 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 provedeni se prolozenÿ paket prekryje Walshovÿm kôdem a rozsifi se krâtkÿmi PNI a PNQ kôdy. Rozsirenâ data se poskytnou VF jednotce 828, kterâ kvadraticky moduluje, filtruje a zesiluje signâl. Signâl primého linku se prenâsi anténou vzduchem na primÿ link.
Na vzdâlené stanici je signâl primého linku prijat anténou a smërovân na prijimac. Prijimac filtruje, zesiluje, kvadraticky demoduluje a kvantizuje signâl. Digitalizovanÿ signâl se privede na demodulâtor (DEMOD), kde se inverznë rozprostfe krâtkÿmi PNI a PNQ kôdy a odkryje Walshovou obâlkou. Demodulovanâ data se poskytnou dekodéru, kterÿ provâdi inverzi funkci zpracovâni signâlu na zâkladnové stanici 820, konkrétnë de-interlaving, dekôdovâni a CRC
89723 (0989723_CZ.doc) 16.12.2006 kontrolni funkce.
Dekôdovanâ data se potom poskytnou prijimaci dat.
Hardware, jak bylo ukâzâno vÿse, podporuje rûzné rychlosti pfenosu dat, zprâv, zvuku, videa a dalsich komunikaci pfimÿm linkem. Rychlost dat vysilanÿch z datové fronty 830 se mënî, aby se uzpûsobila zmënâm v intenzitë signâlu a sumu prostfedi na vzdâlené stanici. Kazdâ ze vzdâlenÿch stanic prednostnë vysilâ signal rizeni rychlosti pfenosu dat, Data Rate Control - DRC, pfirazenÿ k zâkladnové stanici 820, v kazdém casovém slotu. DRC signal poskytuje zâkladnové stanici 820 informaci, kterâ obsahuje identitu vzdâlené stanice a rychlost, jakou vzdâlenâ stanice pfijimâ data ze své pfidruzené datové fronty. Podle toho obvody na vzdâlené stanici mëfi intenzitu signâlu a odhaduji sum prostfedi na vzdâlené stanici, aby se urcila rychlost pfenosu informace, kterâ se mâ vyslat v DRC signâlu.
DRC signâl vyslanÿ kazdou vzdâlenou stanici se sifi kanâlem zpëtného linku a je pfijimân zâkladnovou stanici 820 pfijimaci anténou pripojenou k VF jednotce 828. V ukâzkovém provedeni se DRC informace demoduluje v kanâlovém prvku 826 a poskytne se plânovaci 812 kanâlu, kterÿ se nachâzi v fadici 810 zâkladnové stanice, nebo v plânovaci 832 kanâlu, kterÿ se nachâzi v zâkladnové stanici 820. V prvnim ukâzkovém provedeni se plânovac 832 kanâlu nachâzi v zâkladnové stanici 820. V alternativnim provedeni se plânovac 812 kanâlu nachâzi v fadici 810 zâkladnové stanice a spojuje selektory 816 s fadicem 810 zâkladnové stanice.
Plânovâni pfenosu v obvodovë spinaném systému mùze zahrnovat proporcionâlnë rovnÿ algoritmus, ve kterém je pro kazdého uzivatele definovâna prioritni funkce. Priklad
89723 (0989723_CZ.doc) 16.12.2006 proporcionâlnë rovného algoritmu je uveden nize. Prioritni funkce mûze vzit v ûvahu pozadovanou datovou rychlost pro daného uzivatele, typicky funkci kvality kanâlu primého linku k uzivateli a propustnost pro uzivatele. Kapacita je tedy vyvâzena prvnim obslouzenim tëch uzivatelû, kteri maji vysoké pozadované datové rychlosti ve srovnâni s propustnosti.
Plânovâni prenosû v paketovë spinaném systému vyvazuje podle jednoho provedeni kapacitu uzivatelskÿm zpozdënim. Toky aplikaci se pfenâseji jako datagramy, coz jsou nezâvislé, samonosné zprâvy prenâsené po siti. Doruceni datagramu, cas doruceni a jeho obsah nejsou obecnë zaruceny. Datagramy pridruzené k toku stejné aplikace Ize ke stejnému uzivateli pfenâset po rûznÿch trasâch. Datagramy se v prijimaci znovu sestavi. Celkové zpozdëni v paketovë spinaném systému neni fixni, a proto mûze plânovac vyuzit tohoto rozdilu zpozdëni a nastavit zpozdëni pro rûzné uzivatele rûznë, aby se zvÿsila kapacita systému. Plânovac mûze napriklad snizit zpozdëni, se kterÿm se uzivatelé setkâvaji pri pozadavku dat s nizkou hranici zpozdëni a nebo limity pro zmënu zpozdëni. Mezi takové aplikace patri mimo jiné VoIP, video atd. Prenosy mohou mit urcitÿ stupen sluzby (GoS) nebo QoS pozadavku. VoIP komunikace napriklad vyzaduje, aby pfichâzejici pakety mëly definovanou latenci nebo ji mëli v pripustném rozsahu zpozdëni. Proto neni zâdouci uprednostnovat ty komunikace nebo aplikace, které maji pozadavek na nizsi latenci nebo jiné(jinÿch) GoS specifikace(i). Multimediâlni konference, streamovâni videa, prohlizeni webu, prenosy File transfer protokolem maji své specifické GoS pozadavky.
Aby se implementovalo schéma klasifikace priorit, je
89723 (0989723_CZ.doc) 16.12.2006 kazdému toku pfifazena prioritnî funkce. V jednom provedeni mûze bÿt prioritni funkce (PF) pro paketovë spinanÿ plânovac dâna jako:
PF=f(zpozdëni) kde f() je funkce a FP se potom urci na zâkladë pozadavkû na zpozdëni od daného uzivatele nebo aplikace pro uzivatele. PF se vypocte pro kazdÿ datagram ve frontë; rûzné PF se porovnaji, aby se urcily instance toku s vyssi prioritou. Paketovë spinanâ komunikace umoznuje do plânovâni zaclenit adaptivni sprâvu zpozdëni, dokud neni celkové zpozdëni dané komunikace fixovâno.
Vsimnëte si, ze nâsledujici popis se tÿkâ cdma2000 sytému, kterÿ podporuje vysokorychlostni paketové datové sluzby (HRPD - high rate packet data), jak je popsâno v IS-856. Tento systém se pouzivâ jako priklad. Tento vynâlez je pouzitelnÿ také v jinÿch systémech, ve kterÿ se uzivatelé pro sluzbu vybiraji podle plânovaciho algoritmu.
V HRPD systému mûze vzduchové rozhrani podporovat az 4 paralelni aplikacni toky. Prvni tok nese signâlovou informaci a dalsi tri Ize pouzit k prenosu aplikaci s rûznÿmi QoS pozadavky nebo jinÿch aplikaci.
Nâsledujici slovnicek je uveden pro jasné pochopeni jednoho provedeni, které je popsâno dâle. Tento slovnicek neni vycerpâvajici. Vynâlez neni slovnickem omezen, slovnicek slouzi spise pro jeho jasnëjsi pochopeni s odkazem na jedno provedeni komunikacniho systému podporujiciho adaptivni vâhovÿ plânovaci algoritmus.
SLOVNICEK
Pfistupovâ sit (AN - Access Network) - sit’ové vybaveni
89723 (0989723_CZ.doc) 16.12.2006 poskytujici datovou konektivitu mezi celulârni siti a paketovë spinanou datovou siti (typicky Internetem) a ATs. Pfistupovâ sit v HRPD systému je ekvivalentni zâkladnové stanici v celulârnim komunikacnim systému.
Pfistupovÿ terminal (AT - Access Terminal) - zafizeni poskytujici datovou konektivitu uzivateli. AT v HRPD systému odpovidâ mobilni stanici v celulârnim komunikacnim systému. AT mûze bÿt pfipojen k vypocetnimu zafizeni jako je napriklad pfenosnÿ osobni pocitac nebo mûze bÿt v samonosném datovém zafizeni jako je napfiklad Osobni digitâlni asistent (PDA).
Aplikacni tok - vyhrazenâ pfenosovâ trasa ze zdroje na AT v daném aplikacnim toku. Kazdÿ aplikacni tok je identifikovân zdrojem, cilem, profilem trafficu a kvalitou profilu sluzby.
Aplikacni proud - datovâ komunikace odpovidajici aplikaci. Vëtsina aplikacnich toku ma urcenou kvalitu pozadavku na sluzbu.
Automatické opakovâni pozadavku (Automatic Repeat Request - ARQ) - mechanismus, kteryrn vysilac inicializuje opakovanÿ pfenos dat zalozenÿ na vÿskytu nebo absenci udalosti.
Prùmërnâ rychlost pfenosu dat - prûmërnâ rychlost vstupnich dat za cas pro danÿ aplikacni tok.
Shlukovâni (σ) - mira shlukovâni nebo hustoty a casovâ souvislost paketû v aplikacnim toku.
89723 (0989723_CZ.doc) 16.12.2006
Nejlepsi ùsili (BE - best effort) - Aplikacni toky, které pfijimaji vzduchem obecnë pomërnë velké objemy dat, ale podstata trafficu je takovâ, ze Ize tolerovat relativnë velkâ zpozdëni, ale mira ztrâty dat by mêla bÿt extrémnë malâ.
Rizeni rychlosti prenosù dat (DRC - data rate control) mechanismus, kterÿm AT pfenâsi pozadovanou datovou rychlost na AN.
Deficitni bity (defbits) - mnozstvi bitû odpovidajici deficitnim paketûm.
Hranice zpozdëni - specifikovanÿ cas (hranice zpozdëni) povolenÿ pro prenos datového paketu z AN na AT.
Urychlené smërovâni (EF - expedited forwarding) aplikacni toky maji typicky malâ mnozstvi trafficu, kterÿ pfichâzi z internetu do pristupové sitë, ovsem podstata trafficu je takovâ, ze by datové pakety mëly bÿt doruceny bëhem urcité relativnë malé hranice zpozdëni s rozumnou ztrâtou dat.
Pfimÿ link (FL - forward link) - prenosovÿ vzdusnÿ link z AN na AT.
Paket hlavicky râdku (Head of Line - HOL) - prvni paket ve frontë.
Vysokorychlostni datovÿ paket (HRPD - High Rate Packet Data) - datovâ sluzba pfenasejici paketovou datovou komunikaci vysokou rychlosti pfenosu dat. Také oznacovanâ jako vysokâ rychlost prenosù dat (HDR - High Data Rate) a
89723 (0989723_CZ.doc) 16.12.2006 specifikovanâ ve standardu IS-856 nazvaném „cdma2000 High Rate Packet Data Air Interface Specification.
Neklid (jitter) - casovâ prodleva mezi pfijatymi po sobë jdoucimi pakety.
Hranice neklidu - hranice neklidu pro danÿ aplikacni tok.
Motion Pictures Experts Group (MPEG) - protokol pro pfenos multimediâlnich materiâlû.
Proporcionalni Fair (PF) algoritmus - plânovaci algoritmus, ve kterém se datovâ komunikace plânuje podle vÿbërového faktoru vypocteného pro kazdou AT jako pomër pozadované rychlosti prenosu dat k propustnosti.
Kvalita sluzby (QoS - Quality of Service) - pozadavky tÿkajici se prenosu paketové datové komunikace, zahrnujici mimo jiné zpozdëni, pozadovanou rychlost a neklid.
Zpëtnÿ link (RL) - pfenosovÿ vzdusnÿ link z AT na AN.
Pfenosova fronta - Pfenosova fronta pro ukladâni aplikacnich toku pro danou BTS.
Mnoho bezdrâtovÿch komunikaci vyuzivâ vÿhody Internet Protokolu (IP), aby vyuzily vÿhody rûznÿch Per Hop Behavior (PHB) a rûznÿch smërovâni pro zpracovâni paketovÿch dat. Obecnë je internet tvofen mnoha sitëmi, které jsou tvofeny rûznÿmi technologiemi linkovÿch vrstev, které pfi spolecné prâci vyuzivaji IP. IP nabizi bezspojovou sluzbu sitové vrstvy, kterâ je pfedmëtem ztrâty paketû a zpozdëni, které
89723 (0989723_CZ.doc) 16.12.2006 zvysuje sit’ovou zâtëz. Zâkladni model IP dorucovâni se oznacuje jako nejlepsi ûsili (BE - Best Effort). Nëkteré aplikace mohou napriklad vyzadovat lepsi sluzby, nez jednoduchou BE sluzbu. Napriklad multimediâlni aplikace mohou specifikovat pevnou sifku pâsma s krâtkÿm zpozdënim a malÿm neklidem. Jinym druhem priority je chovâni smërovâni odkazované jako zajistëné smërovâni (AF), které garantuje ùroveh propustnosti.
V QoS managementu existuji rùznâ hlediska. Nëkterÿmi ciniteli QoS managementu jsou alokace sifky pâsma a garantovanâ sirka pâsma ve sdilenÿch médiich, znâmÿch také jako vysilaci sitë, napf. sit Ethernet nebo bezdrâtovâ Lokâlni sit (LAN - Local Area Network). Existuje rostouci poptâvka po zaclenëni bezdrâtovÿch prostfedkû do laptopû a dalsich vÿpocetnich zarizeni. Bezdrâtové sitë jsou ovsem omezeny sirkou pâsma a tudiz se zachovâni kapacity a optimalizace stâvaji kritickÿm faktorem.
Obr. 3 ukazuje zpûsob plânovâni, kterÿ uprednosthuje prenosy zalozené na stupni sluzby (GoS - Grade of service) nebo QoS pozadavcich. V AN se data pro prenos uklâdaji do pamëtové jednotky, kterâ je uzpûsobena k uklâdâni datovÿch front odpovidajicich prichozim aplikacnim tokûm. Fronta se uklâdâ pro kazdou instanci aplikacniho toku. Podle tohoto vynâlezu je aplikacni tok rozdëlen do dvou instanci, z nichz kazdâ instance je datovÿm oktetem. Proto mûze aplikacni tok mit, a casto mâ, k sobë prirazeno vice front. Kazdâ fronta mâ potom pfirazeny pozadavky na vysilâni a prijem definované v QoS a/nebo GoS prioritnim typu. Prioritni typ mûze bÿt zalozen napriklad na pozadavku na celkové zpozdëni nebo nëkterâ jinâ kvalitativni kritéria. Vsimnëte si, ze dané vysilâni mûze spadat do jednoho z mnoha GoS prioritnich
89723 (0989723_CZ.doc) 16.12.2006 typù. Nëkteré sluzby napriklad umoznuji individuâlni prenos paketû dat a jejich nâsledné pospojovâni v prijimaci, aniz by doslo ke ztrâtë kontinuity, tj . BE prioritniho typu. Naproti tomu aplikace navrzené pro real-time funkce, jako je napriklad VoIP, maji vysokÿ prioritni typ a oznacuji se jako prioritni typ urychleného smërovâni (EF - Expedited Forwarding) . EF prioritni typ zahrnuje aplikace, které maji omezeni na hranici zpozdëni a promënlivost zpozdëni. V tomto pfikladu upfednostnuje plânovac EF komunikaci. QoS nebo GoS prioritni typ mûze bÿt také uvâdën jako QoS tfida. Navic, kazdâ fronta ma spolu spojenou senzitivitu. Napriklad EF aplikacni tok je typicky citlivÿ na zpozdëni, coz znamenâ, ze vysilâni EF aplikacniho toku ma pozadavky na zpozdëni, které je tfeba splnit. V mnoha pfipadech, pokud nejsou pozadavky na zpozdëni splnëny, se data zahodi a nevysilaji. Naproti tomu, BE aplikacni tok je typicky citlivÿ na propustnost, coz znamenâ, ze vysilâni BE aplikacniho toku mâ pozadavky na propustnost elle, ale nemâ nezbytnë striktni pozadavky na EF aplikacni tok.
Obr. 3 ukazuje zpûsob 200 plânovâni implementujici adaptivni sprâvu zpozdëni podle jednoho provedeni. V AN implementuje plânovac plânovaci algoritmus, kterÿ poskytuje vysokou rychlost paketovÿch datovÿch pfenosû pro vice uzivatelû. Plânovac kontroluje datovou frontu, aby ureil GoS typ pro data. Pokud maji nëkterâ data v rozhodovacim kroku 202 danÿ GoS prioritni typ, t j . prioritni typ definujici podrobnëjsi pozadavky nez BE, pokracuje procès krokem 204, aby nasel nejstarsi data nejvyssiho prioritniho typu ve frontë. Vyssi prioritni typ, jak se zde pouzivâ, oznacuje GoS prioritni typ definovanÿ striktnéjsi specifikaci. Jeden prioritni typ mûze napriklad specifikovat hranici zpozdëni, zatimeo jinÿ mûze specifikovat hranici neklidu. V tomto
89723 (0989723_CZ.doc) 16.12.2006 pripadë se prioritni typ specifikujici hranici zpozdëni povazuje za vyssi prioritu a tudiz se povazuje za prvni.
Podle tohoto provedeni plânovac nejprve na zâkladë pozadavkù na zpozdëni priradi bity do paketù pro vysilâni. Jakmile jsou data s vysokou prioritou naplânovâna, Ize k plânovâni zbÿvajicich paketù pouzit jinÿ algoritmus.
Napriklad pokud jsou data ve frontë, zacne plânovac vytvâret pakety pro prenos za pouziti EF dat. EF data se vyberou na zâkladë doby pobytu dat ve frontë, krok 204. V jednom provedeni se k datùm v okamziku jejich vlozeni do fronty priradi casovâ znâmka. Plânovac najde EF data s nejstarsi casovou znâmkou a vlozi je do paketù jako prvni. Plânovac potom pokracuje ve vklâdâni EF dat do paketù podle jejich stâri ve frontë, krok 206. Jakmile byla vsechna EF data vlozena do paketù pro vysilâni, pouzije plânovac jinÿ algoritmus pro zbytek dat. V tomto vynâlezu pouzije plânovac proporcionâlni fair algoritmus na zbytek dat, kterÿm mohou bÿt data nejlepsiho ùsili (best effort), krok 208. BE data se potom vlozi do paketù podle proporcionâlniho fair algoritmu, krok 210.
Vsimnëte si, ze podminka kanâlu zvysuje pozadavky uzivatelû na vysoké datové rychlosti, coz mâ za nâsledek snizovâni hranice zpozdëni. Proto, i kdyz plânovac uprednostnuje EF data, mûze bÿt hranice zpozdëni funkci podminky kanâlu.
Pro prenos BE dat vybere plânovac paket, aby maximalizoval propustnost. Propustnost se potom obecnë vypocte jako:
89723 (0989723_CZ.doc) 16.12.2006
Propustnost = (bitû na paket)/(slotû na paket).
Podle jednoho provedeni, PF mùze bÿt dan jako:
PF = f(stâfi paketu)*g(podminka kanâlu)*h(zâtëz bunky), kde se pfi plânovâni vysilâni uvazuje stâri paketu stejnë jako podminka kanâlu a zâtëz bunky. Takovÿ vÿpocet Ize pouzit pro plânovâni EF dat nebo BE dat.
Opët s odkazem na obr. 2, v jednom provedeni plânovac 832 prijimâ informace z datové fronty 830, které indikuji mnozstvi dat, kterâ jsou zarazena do fronty pro kazdou vzdâlenou stanici, také nazÿvané velikost fronty. Plânovac 832 kanâlu potom provede plânovâni zalozenâ na DRC informaci a velikosti fronty pro kazdou vzdâlenou stanici obsluhovanou zâkladnovou stanici 820. Pokud je velikost fronty pozadovâna pro plânovaci algoritmus pouzitÿ v alternativnim provedeni, mùze plânovac 812 kanâlu pfijimat informaci o velikosti fronty ze selektoru 816.
V prûbëhu vysilâni paketù k jednomu nebo vice uzivatelûm vysilaji uzivatelé potvrzovaci „ACK signâl pokazdé, kdyz je vyslân casovÿ slot obsahujici câst vysilaného paketu. ACK signâl vysilanÿ jednotlivÿmi uzivateli se pfenâsi kanâlem zpëtného linku a prijimâ se zâkladnovou stanici 820 pomoci prijimaci antény pripojené k VF jednotce 828. V jednom ukâzkovém provedeni se ACK informace demoduluje do kanâlovÿch prvkû 826 a poskytne plânovaci 812 kanâlu umistëném v radici 810 zâkladnové stanice nebo plânovaci 832 zâkladnové stanice umistëném v zâkladnové stanici 820. V prvnim ukâzkovém provedeni se plânovac 832 kanâlu nachâzi v zâkladnové stanici 820. V alternativnim provedeni se plânovac 812 kanâlu nachâzi v radici 810 zâkladnové stanice a propojuje selektory 816 s radicem 810 zâkladnové stanice.
89723 (0989723_CZ.doc) 16.12.2006
Provedeni tohoto vynâlezu jsou pouzitelnâ v jinÿch hardwarovÿch architekturâch, které mohou podporovat rûzné rychlosti prenosu. Tento vynâlez je mozné snadno rozsirit, aby se pokryly rûzné rychlosti prenosu na zpëtném linku. Napriklad misto urceni rychlosti prijmu dat zâkladnovou stanici 820 zalozeném na DRC signâlu z ûcastnickÿch stanic, mëfi zâkladnovâ stanice 820 intenzitu signâlu pfijatého ze vzdâlenÿch stanic a odhaduje sum prostfedi, aby se urcila rychlost prijmu dat z ûcastnické stanice. Zâkladnovâ stanice 820 potom vysle kazdé pridruzené ûcastnické stanici rychlost, kterou se maji prenâset data na zpëtném linku ze vzdâlené stanice. Zâkladnovâ stanice 820 potom mûze plânovat prenosy na zpëtném linku na zâkladë rûznÿch rychlosti prenosu dat na zpëtném linku podobnÿm zpûsobem, kterÿ je zde popsân pro primÿ link.
Vÿse popsané provedeni zâkladnové stanice 820 tedy vysilâ vybrané nebo vybranÿm ûcastnickÿm stanicim s vyloucenim ostatnich ûcastnickÿch stanic pridruzenÿch k zâkladnové stanici 820 pouzitim schémat pristupu s kôdovÿm dëlenim, CDMA. V kterémkoliv konkrétnim case zâkladnovâ stanice 820 vysilâ na vybranou nebo vybrané ûcastnické stanice za pouziti kôdu, kterÿ je prirazen prijimajici zâkladnové stanici(prijimajicim zâkladnovÿm stanicim 820. Tento vynâlez je ovsem také aplikovatelnÿ na jiné systémy vyuzivajici rûzné TDMA (casovÿ multiplex) zpûsoby pro poskytnuti dat zâkladnové stanici (zâkladnovÿm stanicim) 820, s vyloucenim ostatnich zâkladnovÿch stanic 820, aby se vysilaci prostredky alokovaly optimâlnë.
Plânovac 812 kanâlu plânuje rûzné rychlosti prenosu na primém linku. Plânovac 812 kanâlu prijimâ velikost fronty,
89723 (0989723_CZ.doc) 16.12.2006 kterâ indikuje mnozstvi dat, kterâ se maji prenâset na vzdâlenou stanici, a zprâv ze vzdâlenÿch stanic. Plânovac 812 kanâlu pfednostnë plânuje datové pfenosy, aby se dosâhlo elle systému tj . maximâlni datové propustnosti pfi dodrzeni omezeni rovnosti.
Jak je ukâzâno na obr. IA, jsou ùcastnické stanice rozptÿleny v komunikacnim systému a mohou komunikovat se zâdnou nebo s jednou zâkladnovou stanici na pfimém linku. V ukâzkovém provedeni koordinuje plânovac 812 kanâlu pfenosy dat primÿm linkem v celém komunikacnim systému.
Podle jednoho provedeni je plânovac 812 kanâlu obr. 2 implementovân v pocitacovém systému, kterÿ obsahuje procesor, Random Access Memory, RAM a programovou pamët pro uklâdâni instrukci, které se maji provâdët procesorem (neni zobrazeno). Procesor, RAM a programovâ pamët mohou bÿt vyhrazeny pro funkce plânovace 812 kanâlu. V jinÿch provedenich mohou bÿt procesor, RAM a programovâ pamët soucâsti sdileného vÿpocetniho prostfedku pro provâdëni dodatecnÿch funkci na radici 810 zâkladnové stanice. V ukâzkovém provedeni se v systému 800 zobrazeném na obr. 2 pouzije obecnÿ plânovac, kterÿ je podrobnë popsân dâle. Jeho moduly, které jsou pouzity v ESC 810 a BS 820 k implementaci prioritni funkce pro plânovâni datovÿch prenosû, jsou popsâny po uvedeni vlastnosti obecného plânovace.
S rostoucimi pozadavky na bezdrâtové datové aplikace podstatnë vzrostla poptâvka po velmi efektivnich bezdrâtovÿch datovÿch komunikacnich systémech. IS-95 standard je schopen prenosu dat trafficu a hlasovÿch dat primÿm a zpëtnÿm linkem. Podle standardu IS-95 se data trafficu nebo hlasovâ data rozdëli do râmcù kôdového kanâlu,
89723 (0989723_CZ.doc) 16.12.2006 které jsou 20 milisekund siroké s rychlosti prenosu dat 14,4 Kbps. V IS-95 systému mâ kazdâ ûcastnickâ stanice alokovân alespon jeden z omezeného mnozstvi ortogonâlnich kanâlû primého linku. Protoze komunikace mezi zâkladnovou stanici a ûcastnickou stanici pokracuje, zûstane kanâl primého linku pridëlen ûcastnické stanici. Kdyz se datové sluzby poskytuji v IS-95 systému, zûstâvaji kanaly primého linku alokovâny ûcastnické stanici i v dobè, kdy nejsou zâdnâ data primého linku, kterâ by se mêla poslat ûcastnické stanici.
Podstatnÿ rozdil mezi hlasovÿmi sluzbami a datovÿmi sluzbami je ve skutecnosti ten, ze hlasové sluzby maji striktni a pevné pozadavky na zpozdëni. Typicky musi bÿt celkové zpozdëni pro hlasové râmce v jednom smëru mensi nez 100 milisekund. V kontrastu s tim mûze bÿt zpozdëni dat promënlivÿ parametr, kterÿ Ize pouzit k optimalizaci propustnosti datového komunikacniho systému.
Jinÿm podstatnÿm rozdilem mezi hlasovÿmi sluzbami a datovÿmi sluzbami je to, ze hlasové sluzby vyzaduji pevnë danou a stejnou ûroven sluzby (grade of service - GoS) pro vsechny uzivatele. Typicky pro digitâlni systémy poskytujici hlasové sluzby se tyto pozadavky projevuji jako fixni a stejnâ rychlost prenosu pro vsechny uzivatele a maximâlni tolerovatelnâ chybovost v hlasovÿch râmcich. V kontrastu s tim pro datové sluzby mûze bÿt GoS pro kazdého uzivatele jinâ a mûze bÿt optimalizovanÿm paramétrera, aby se zvÿsila celkovâ efektivita datového komunikacniho systému. GoS datového komunikacniho systému je typicky definovâna jako celkové zpozdëni v prûbëhu predem daného mnozstvi dat, které se zde bude dâle oznacovat jako datovÿ paket.
89723 (0989723_CZ.doc) 16.12.2006
Jestë j inÿ podstatnÿ rozdil mezi hlasovÿmi sluzbami a datovÿmi sluzbami je ten, ze hlasové sluzby vyzaduji spolehlivÿ komunikacni link, kterÿ je v ukâzkovém CDMA komunikacnim systému poskytnut mëkkÿm pfedânim. Mëkké pfedani vede k redundantnim vysilânim ze dvou nebo vice zâkladnovÿch stanic, aby se zvÿsila spolehlivost. Tato zvÿsenâ spolehlivost ovsem neni vyzadovâna pro datové pfenosy, protoze chybnë pfijaté datové pakety Ize pfenést znovu. Pro datové sluzby mûze bÿt proto vysilaci vÿkon pouzitÿ k podpofe mëkkého handoff efektivnëji vyuzit pfi pfenosu dalsich dat.
Zpozdëni prenosu pozadované k prenosu datového paketu a prûmërné rychlosti prenosu jsou tedy dva atributy pouzité k definici kvality a efektivity datového komunikacniho systému. Zpozdëni prenosu nemusi mit stejnÿ ùcinek v datovém komunikacnim systému a hlasovém komunikacnim systému, ale je mëfitkem pro mëfeni kvality datového komunikacniho systému. Prûmërnâ rychlost prenosu dat je mëritkem efektivity schopnosti prenosu dat v komunikacnim systému. V technice tedy existuje potfeba po komunikacnich systémech, které poskytnou zlepsenou datovou propustnost a zâroven poskytnou GoS, kterâ je vhodnâ pro vsechny typy sluzeb poskytované v bezdrâtovém kanâlu.
Potfeba obecného plânovace je zalozena na pozadavcich a cilech datového pfenosu v bezdrâtovém komunikacnim systému. Pro datové pfenosy je propustnost definovâna pomoci zpozdëni, kterâ se vyskytuji pfi pfenosech paketù dat, radëji nez pomoci jednotlivÿch bitû nebo bytû. Datovÿ paket, jako napfiklad Internet Protokol, IP datagram je nedëlitelnâ jednotka, ve vëtsinë pfipadû pfijeti pouze câsti paketu neobsahuje pro uzivatele dostatecnou informaci, aby jej mohl
89723 (0989723_CZ.doc) 16.12.2006 uzivatel dekôdovat a pouzit, takovÿ paket je tedy pro uzivatele bezcennÿ. Koncovÿ uzivatel prijme datovÿ paket, provede cyklickÿ test redundance (CRC) datového paketu a zpracuje data. Proto je pro uzivatele nejdûlezitëjsi okamzik prichodu posledniho bitu datového paketu a neni pro nëj dûlezité zpozdëni jednotlivÿch bitû datového paketu. To umozhuje znacnou flexibilitu v nastaveni rychlosti prenosu dat pro jednotlivé uzivatele v casovÿch mëritcich mensich, nez je doba prenosu jednoho datového paketu. Navic jsou ve spojeni typu Transmission Control Protokol, TCP, prijatelné urcité odchylky ve zpozdënich datovÿch paketu, dokud neni tato odchylka tak nepfedvidatelnâ, ze zpûsobuje zbytecné opakované TCP pfenosy.
Jinou vlastnosti bezdrâtového kanâlu je promënlivost kanâlu samotného. V systému typu HDR tato variabilita vede k promënlivosti pozadované rychlosti v prûbëhu casu. Aby se maximalizovalo vyuziti kanâlu, je navrzen plânovac tak, aby slouzil uzivatelûm s vysokou rychlosti prenosu dat, tj. uzivatelûm pozadujicim vysokou rychlost prenosu dat. To obcas znamenâ, ze uzivatelé nemusi bÿt obslouzeni v dobë, kdy jsou jejich pozadované rychlosti prenosu nizsi. Celkovâ propustnost bude maximalizovâna, kdyz plânovac delsi dobu neslouzi uzivatelûm s nizkou rychlosti prenosu dat. Ideâlnë toto ovsem plânovac vyvazuje pozadavky na zpozdëni paketu a odchylky zpozdëni tak, aby byly relativnë konzistentni, jak je vysvëtleno vÿse.
Jinÿ aspekt se tÿkâ rovného pfistupu k vice uzivatelûm v systému. Aby se dosâhlo spravedlivého zpûsobu plânovâni, distribuuje plânovac ideâlnë celkovou propustnost mezi rûzné uzivatele. Rûzné zâkladny a rovnosti (nebo povolené nerovnosti) se pouzivaji rûznÿmi systémy, aby se ovlivnily
89723 (0989723_CZ.doc) 16.12.2006 pozadavky a potreby jednotlivÿch systémû. Koncept rovnosti je klicovÿm konceptem v mnoha plânovacich algoritmech. Rovnost poskytuje rûznou miru flexibility v obsluhovâni rûznÿch uzivatelû tudiz ma dopad na celkovou propustnost v sektoru.
Podle jednoho provedeni se zpûsob a zafizeni pro plânovâni prenosû v komunikacnim systému s pouzitim ve vice tfidâch uzivatelû zahrnuje obecnÿ plânovac. Obecnÿ plânovac vyhovuje rûznÿm prioritâm plânovâni. Rûzné tfidy uzivatelû se specifickÿmi pozadavky na prenos jsou obsluhovâny obecnÿm plânovacem, kterÿ udrzuje vysokou propustnost pro vsechny uzivatele.
V jednom provedeni implementuje cinnost obecného plânovace prioritni funkci miry podminky kanâlu a kritéria rovnosti, kde prioritni funkce je definovâna jako:
f(Ai(t),Ui(t)), kde Ai(t) je mira stavu kanâlu a Ui(t) je mira rovnosti uzivatelû. Funkce Ai(t) specifikuje vhodnost obslouzeni uzivatele i v case t na zâkladë aktuâlniho stavu kanâlu. Funkce Ui(t) specifikuje vhodnost obslouzeni uzivatele i v case t na zâkladë historié sluzeb prijatÿch v minulosti. Prioritni funkce f() kombinuje dvë miry vhodnosti, Ai(t) a Ui(t), aby se urcila ûroveh priority pro kazdého uzivatele.
Podle jednoho provedeni obsluhuje obecnÿ plânovac uzivatele s nejvyssi prioritni funkci f (Ai(t) , Ui (t) ) v dané tfidë nebo typu uzivatelû. V ukâzkovém provedeni se hodnota danâ prioritni funkci f (Ai(t) , U(t)) s rostouci funkci Ai(t) stavu kanâlu zvysuje a s rostouci funkci Ui(t) rovnosti snizuje. Funkce Ai(t) a Ui(t) se urci odpovidajicim zpûsobem. Navic, prioritni funkce f() je funkci alespon jedné casové
89723 (0989723_CZ.doc) 16.12.2006 periody, bëhem které se mëri mira stavu kanâlu a mira rovnosti uzivatelû. V alternativnim provedeni mûze bÿt prioritni funkce casovë zâvislâ pro kazdého uzivatele. Pro jednoduchost mûze ovsem plânovac pouzivat propojovaci funkci spolecnou pro vsechny uzivatele a modifikovat miru rovnosti, aby odrazil pozadavky uzivatelû.
Obecnâ trida viceuzivatelskÿch plânovacû kategorizuje uzivatele prijimajici sluzby z AN do alespon dvou sirokÿch kategorii, BE a EF. Lze také implementovat dalsi kategorie prenosû, jako napriklad AF atd. BE a EF jsou takové, jak jsou definovâny zde. Konkrétnë BE (nejlepsi ûsili - Best effort BE) aplikace maji obecnë relativnë velkÿ objem dat, kterÿ se prijimâ vzduchem, ale podstata trafficu je takovâ, ze lze tolerovat relativnë velkâ zpozdëni, ale ztrâty dat by mëly bÿt extrémnë malé; aplikacni toky ocekâvaného smërovâni (EF - expected forwarding) maji typicky malÿ objem trafficu, kterÿ pfichâzi z internetu do pristupové sitë, ovsem podstata tohoto trafficu je takovâ, ze se datové pakety maji dorucit uzivateli v urcitém relativnë malém rozmezi zpozdëni s rozumnou mirou ztrâty dat.
V paketovém datovém systému, jako napriklad IxEV-DO, mâ plânovac flexibilitu umoznit rûznâ zpozdëni pro jednotlivé uzivatele, aby se maximalizovala kapacita. Jako kapacita se zde oznacuje propustnost pro BE uzivatele a pocet obslouzenÿch uzivatelû s pfijatelnou propustnosti v pripadë trafficu citlivého na zpozdëni, jako napriklad VoIP (EF uzivatelé).
Obecnë se v IxEV-DO se zvÿsenim hranice zpozdëni pro uzivatele zvÿsi vyuziti FL, cimz se zvÿsi BE a EF kapacita systému. Toto zvÿseni kapacity vychâzi z rûznÿch faktorû,
89723 (0989723_CZ.doc) 16.12.2006 které zahrnuji, ale neomezuji se na, vyssi efektivitu paketovâni a schopnost a schopnost vyuzit lokâlniho stavu kanâlu a zisku z rùznorodosti uzivatelù.
V pripadë cistého BE trafficu je typickÿ plânovac proporcionâlnë rovnÿ (PF - proportional fair) plânovac. Tento plânovac je proporcionâlnë rovnÿ v torn smyslu, ze propustnost poskytnutâ jednotlivÿm uzivatelûm je pribliznë proporcionâlni ke geometrii uzivatele, tj . prûmërnému stavu kanâlu. Proporcionâlnë rovnÿ plânovac byl vybrân jako plânovac pro cistÿ BE traffic kvùli svému pfinosu propustnosti k rovnÿm kompromisûm. Navic, PF algoritmus byl navrzen tak, aby vyuzil lokâlnich spicek kanâlu pfi poskytnuti zisku z rùznorodosti uzivatelù. Takovÿ PF plânovac, jak se zde pouzivâ, se bude oznacovat jako „proporcionâlnë rovnÿ plânovac propustnosti.
Vsimnëte si, ze v pripadë cistého BE-trafficu, je zde dalsi trida plânovacû: plânovac „stejné ùrovnë sluzby. Tento plânovac se snazi poskytnout stejnou propustnost vsem uzivatelûm. Z tohoto dûvodu urcuje kapacitu systému nejslabsi uzivatel. Ackoliv je plânovac stejné ûrovnë sluzby v nëkterÿch aplikacich zâdouci, nevyuzivaji takové plânovace obvykle vzdusnÿ link efektivnë. Tyto plânovace se zde oznacuji jako „plânovace stejné propustnosti.
Plânovace PF propustnosti a plânovace stejné propustnosti popsané vÿse jsou uzitecné v kontextu cistého BE-trafficu. Pro EF-traffic citlivÿ na zpozdëni nemusi bÿt tyto plânovace efektivni, protoze chybi mechanismus pro kontrolu zpozdëni.
Nâsledujici text predstavuje plânovaci prostredky a
89723 (0989723_CZ.doc) 16.12.2006 zpûsoby citlivé na zpozdënî, které mohou pracovat s obëma pristupy pro cistÿ BE-traffic, napr. PF plânovac propustnosti a plânovac stejné propustnosti. V pfipadë trafficu citlivého na zpozdënî se „proporcionâlni versus ,,stejnâ rovnost nepouzivâ jenom na propustnopst poskytnutou jednotlivÿm uzivatelûm, ale také na propustnost „zpozdëni poskytnutou jednotlivÿm uzivatelûm. Propustnost zpozdënî Ize kvantifikovat pomocî prûmërného zpozdënî nebo vâhy zpozdënî atd. Vsimnëte si, ze rûznâ provedeni mohou mit BE a EF plânovâni zaclenëny do spolecného zpûsobu pri splnëni pozadavkû na propustnost a citlivost na zpozdënî.
V jednom provedeni Ize poskytnout pfibliznë stejné zpozdënî vsem uzivatelûm. Tento pristup je podobnÿ stejné propustnosti a pro symetrii terminologie se oznacuje jako „plânovac se stejnÿm zpozdënim. Plânovac se stejnÿm zpozdënim se snazi poskytnout stejnou propustnost vsem uzivatelûm, a proto Ize kapacitu systému urcit podle uzivatelû s nejslabsim pokrytim. Plânovace se stejnÿm zpozdënim se pokousi poskytnout stejnou propustnost zpozdënî, jako napriklad stredni zpozdënî nebo stejnâ vâha zpozdënî vsem uzivatelûm a tudiz se kapacita systému urcuje podobnë pro uzivatele s nejslabsim pokrytim.
V jiném provedeni je propustnost zpozdënî poskytnuta uzivateli proporcionâlni prûmërné geometrii uzivatele. Tento pristup je podobnÿ proporcionâlnë rovnému plânovac! propustnosti a je oznacovân jako „plânovac s proporcionâlnë rovnÿm zpozdënim. Plânovac s proporcionâlnë rovnou propustnosti se pokousi poskytnout propustnost jednotlivÿm uzivatelûm proporcionâlnë k jejich prûmërné geometrii, cimz podstatnë zvysuje kapacitu systému ve srovnâni s plânovacem s rovnou propustnosti. Podobnë bude plânovac
89723 (0989723_CZ.doc) 16.12.2006 s proporcionâlnë rovnÿm zpozdënim poskytovat propustnost zpozdëni jednotlivÿm uzivatelûm proporcionâlnë k prùmërné geometrii uzivatele, cimz se maximalizuje EF kapacita.
Na obr. 4 jsou zobrazeny ctyri kategorie plânovâni paketu. Kazdâ kategorie je znâzornëna s rovnovâhou QoS uvazovâni. Konkrétnë plânovac PF propustnosti vyvazuje rizeni propustnosti s proporcionâlni rovnosti. Plânovac se stejnou propustnosti vyvazuje rizeni propustnosti se stejnou rovnosti. Plânovac PF zpozdëni vyvazuje rizeni zpozdëni s proporcionâlni rovnosti. Plânovac se stejnÿm zpozdënim vyvazuje rizeni zpozdëni se stejnou rovnosti.
Zatimco nëkteré zpûsoby plânovâni jsou uzitecné v obvodovë spinanÿch systémech, jiné mohou bÿt vhodnëjsi pro paketové datové systémy, jako napfiklad lxEV-DO. Zde prezentované plânovaci prostfedky a zpûsoby proporcionâlnë rovného zpozdëni mohou bÿt vÿhodou paketovë spinanÿch systémû nad obvodovë spinanÿmi systémy.
Navic, aby se zvÿsila kapacita systému, mûze plânovac s PF zpozdënim zvysovat zkusenost uzivatelû. Napfiklad uzivatelé v blizkosti BSs budou pravdëpodobnë prijimat lepsi propustnost zpozdëni nez uzivatelé dâle od BSs. To je v kontrastu se zpozdënim, které nezâvisi na vzdâlenosti k AN. Navic pro uzivatele s vysokou geometrii v blizkosti BS mûze bÿt propustnost predvidatelnâ s vysokou ûrovni spolehlivosti, zatimco pro plânovac se stejnÿm zpozdënim mûze bÿt propustnost v zâvislosti na aktuâlni zâtëzi systému nepredvidatelnâ. Proto je pro plânovac zâdouci zajistit, aby kvalita sluzby rostla s nârûstem geometrie jednotlivÿch uzivatelû.
89723 (0989723_CZ.doc) 16.12.2006
Plânovac, kterÿ slouzi jak BE, tak EF uzivatelûm mûze vyuzivat odpovidajicî kombinace proporcionâlnë rovné propustnosti a plânovâni zpozdëni. Takovÿ plânovac mûze bÿt oznacovân jako „plânovac s proporcionâlnë rovnou propustnosti/ zpozdënim. Vsimnëte si, ze v jednom provedeni je plânovâni s proporcionâlnë rovnou propustnosti/ zpozdënim implicitnë zalozeno na relativnich geometriich uzivatelû obslouzenÿch v jednom sektoru. To se odkazuje jako „rovnost uvnitf sektoru. Jinÿm problémem, kterÿ je tfeba brât v ûvahu pri nâvrhu plânovace je rovnost uvnitr buûky, kterou Ize popsat jako prûmërnou ûroven sluzby, kterou Ize kvantifikovat pomoci propustnosti poskytnuté BE uzivatelûm a prûmërného zpozdëni poskytnutého EF uzivatelûm atd., poskytnutého rûznÿmi sektory uzivatelûm obsluhovanÿm tëmito sektory.
Abychom pokracovali v analogii mezi plânovacem s proporcionâlnë rovnou propustnosti a plânovacem s proporcionâlnë rovnÿm zpozdënim, vsimnëte si, ze propustnost poskytnutâ jednotlivÿm BE uzivatelûm sektorem, kterÿ pouzivâ plânovac s proporcionâlnë rovnou propustnosti, s rostoucim poctem uzivatelû obslouzenÿch sektorem klesâ. Rovnost uvnitr sektoru ovsem zùstâvâ zachovâna. Podobnë, propustnost zpozdëni poskytnutâ jednotlivÿm EF uzivatelûm, poskytnutâ sektorem, kterÿ vyuzivâ proporcionâlnë rovnÿ plânovac zpozdëni, mûze vzrûst, jestlize vzroste pocet uzivatelû obslouzenÿch sektorem.
Plânovac s proporcionâlnë rovnou propustnosti/ zpozdënim vyuzivâ rozhodovaci metriku v nâsledujici formé, aby rozhodl, kteri uzivatelé maji bÿt obslouzeni pri kterémkoliv plânovacim rozhodnuti:
RozhodovaciMetrika = f (StâriPaketu, StavKanâlu,
89723 (0989723_CZ.doc) 16.12.2006
ZâtëzSektoru) , kde StâfiPaketu oznacuje rozdil mezi aktuâlnim casem a odpovidajici casovou znâmkou definovanou pro kazdÿ paket pri cekâni ve frontë zâkladnové stanice, stav kanâlu oznacuje kvalitu radiového linku mezi BS a AT a ZâtëzSektoru oznacuje objem a profil celkového trafficu obsluhovaného sektorem v krâtkém casovém intervalu v okoli aktuâlniho casového okamziku. Funkce f() zâvisi na konkrétni implementaci plânovace. Rozhodovaci metrika mûze také zâviset na bitové metrice, paketové metrice, datagramové metrice nebo jakÿchkoliv jinÿch prostfedcich poskytujicich plânovaci zpûsob vÿbëru instance pfenosu.
Informace o stavu kanâlu Ize zaclenit do plânovace rûznÿmi zpùsoby. Napfiklad v plânovaci s proporcionâlnë rovnou propustnosti se pouzivâ Rizeni rychlosti prenosu dat/ prûmërnâ propustnost, které dosahuje maxima pri lokâlnich maximech kanâlu. Jinÿ pfistupem by bylo pouzit DRC/AvgDRC, ale pri pouziti mûze upfednostnovat uzivatele s velkÿmi fluktuacemi kanâlu. Jinou moznosti by mohlo bÿt také pouziti zpëtnovazebni smycky, pro indikaci jistého percentilu spicek kanâlu. Jedna takovâ smycka 300 je zobrazena na obr. 5.
Jedno provedeni, jak je zobrazeno na obr. 5, je smycka 300 navrzenâ tak, aby urcila pfijatelnou kvalitu kanâlu vzhledem k prahu. Vstup, IDRC je funkce nebo index DRC hodnoty, napf. rostouci funkce rychlosti spojenâ s DRC, kde IDRC roste tak, jak se zvysuje pozadovanâ rychlost pfenosu dat. IDRC se poskytne komparâtoru 302 a filtru 306 s nekonecnou impulsni odezvou (HR). V jednom pfikladu se casovâ konstanta nastavi na 1s, Ize ovsem implementovat také alternativni casové konstanty. Filtrovanÿ vÿstup IIR filtru 306 se poskytne sumacni 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âni urcuje, zda je kvalita kanâlu pfijatelnâ nebo ne. Systém urci cilovÿ podil casu, kdy je kvalita kanâlu pfijatelnâ. V tomto vynâlezu je cil nastaven na 30 %. Cil je promënlivÿ a Ize jej nastavit za provozu. Alternativni systémy mohou implementovat jiné cilové hodnoty nebo schémata. Vÿstupem komparâtoru 302 je binârni hodnota {1,0}, kde 1 indikuje pfijatelnou kvalitu kanâlu a 0 je nepfijatelnâ, tj. pod prahem.
Pokracujeme s obr. 5, vÿstup komparâtoru 302 se poskytne IIR filtru 304, pficemz v tomto pfikladu je casovâ konstanta nastavena na 0,5 s. Lze implementovat alternativni casové konstanty. Filtrovanÿ vÿstup z IIR filtru 304 se pfivede na komparâtor 310 pro porovnâni se vstupni hodnotou, v tomto pfikladu je vstupni hodnota 0,3. Pokud je vÿsledek porovnâni nad uvedenou vstupni hodnotou, poskytne se signâl up/dn akumulâtoru 308, aby se zvÿsil prâh pro urceni kvality kanâlu. To indikuje, ze indikâtor kvality kanâlu z komparâtoru 302 je 1 ve vice nez 30 %. Pokud je jinak porovnâni pod vstupni hodnotou, uklâdâ signâl poskytnutÿ up/dn akumulâtoru 308 zvÿseni prahu. Vÿstup up/dn akumulâtoru 308 je poskytnut scitaci jednotce 312. Scitaci jednotka 312 scitâ vÿstupy up/dn akumulâtoru 308 a IIR filtru 306, kde vstup z IIR filtru 306 poskytuje obecné pfedpëti pro prâh pro komparâtor 302. Vÿsledek scitâni se poskytne komparâtoru 302. Indikâtor odhadu kanâlu se vezme z vÿstupu komparâtoru 302. Timto zpùsobem udrzuje plânovac indikâtor odhadu kanâlu nebo informaci o stavu kanâlu, aby se identifikovalo procento dobrÿch casù, kdy je stav kanâlu dobrÿ, tj. spicek kanâlu.
ZâtëzSektoru mûze bÿt zaclenëna do plânovace mëfenim
89723 (0989723_CZ.doc) 16.12.2006 miry BE a EF tokû. Nakonec aktuâlni rozhodovaci metrika pouzitâ plânovacem nemusi explicitnë obsahovat mëfeni StavuKanâlu a ZâtëzeSektoru. Pozadovanâ HraniceZpozdëni na uzivatele mûze bÿt adaptivnë vybrâna mëfenim podilu EF uzivatelù, ktefi nemusi splnovat své hranice zpozdëni pro urcitÿ podil pfenesenÿch IP paketù.
Parametr pouzitÿ nëkterÿmi plânovaci se oznacuje jako „QoS index tfidy toku, kterÿ definuje relativni prioritu pro tento tok. Existuje mnoho zpûsobû, kterÿmi Ize urcit QoS tfidy. V râmci dané QoS tfidy maji rûzné toky velmi rûzné typy trafficu. QoS index tfidy je indikâtorem pro pozadovanou ùroven priority tokem a neni indikâtorem statistického chovâni trafficu.
V jednom provedeni je QoS index tfidy nezâpornâ hodnota integer vybranâ z plânovace, aby poskytla vyssi prioritu tokùm s vyssimi QoS indexy tfidy. Zde QoS index tfidy 0 odpovidâ BE/AF tokùm; kde BE toky jsou speciâlni pfipady AF tokû, kde minimâlni pozadovanâ hodnota propustnosti je nastavena na nulu. QoS indexy tfidy 1 a vyssi odpovidaji EF tokùm.
Vsimnëte si, ze QoS tfidy maji vyssi prioritu; ovsem BE data nebudou nezbytnë plânovâna pro pfenos po preneseni vsech EF dat cekajicich ve frontâch. Jako pfiklad mûze plânovac plânovat viceuzivatelskÿ paket, aby pfenâsel mnozstvi EF bitù, které dosahuji deadline. Ve stejné instanci pfenosu mûze plânovac také obsahovat BE data od uzivatelù kombatibilni s DRCs, tj. pfenosové formâty a zâroven neobsahuje EF bity od uzivatelù s nekompatibilnimi DRCs.
89723 (0989723_CZ.doc) 16.12.2006
QoS tok Ize pfibliznë charakterizovat tfemi parametry: (1) rozdëlenim velikosti IP datagramu, (2) rozdëlenim délek intervalu mezi pfichody IP datagramu a (3) hranicemi zpozdëni vztahujicimi se k casové znâmce IP datagramu po které se obsah datagramu stane nepouzitelnÿm.
Pro BE/AF toky je hranice zpozdëni mnohem ménë tvrdâ, nez pro EF toky, takze se nebude uvazovat pro BE/AF toky, kde AF znamenâ zajistëné primé toky. Pro EF toky se stejnou hranici zpozdëni ale rûznÿm rozdëlenim velikosti IP datagramu a intervalù mezi jejich pfichody, je plânovac navrzen jako pfevâznë lineârni. Napfiklad danÿ tok se stejnou hranici zpozdëni a rozdëlenim velikosti paketu jako VoIP tok, ale majici polovicni rozdëleni intervalù mezi pfichody paketu, se bude chovat pfibliznë stejnë jako dva VoIP toky. Podobnë, tok se stejnou hranici zpozdëni a rozdëlenim intervalù mezi pfichody paketù, ale dvojnâsobnÿm rozdëlenim velikosti datagramù, se bude vûci plânovaci chovat pfibliznë stejnë jako dva VoIP toky. Necelociselné nâsobky velikosti paketù a casû mezi pfichody Ize snadno pfedvidat jako agregace zâkladnich „jednotkovÿch typû tokû.
Hranice zpozdëni mâ ovsem podstatnë jinÿ efekt na plânovac, nez velikost datagramu a rozdëleni intervalù mezi pfichody datagramù. Plânovac zpracovâvâ toky s nizsimi hranicemi zpozdëni s vyssi prioritou. V urcitém smyslu je nastaveni hranice toku na nizsi hodnotu mëkkou cestou jak zvÿsit jeji QoS index tfidy.
Jak bylo popsâno vÿse, plânovâni pfenosù se tÿkâ fizeni pfistupu, kde fizeni pfistupu urcuje, kdy je uzivatel nebo tok pfijat pro zpracovâni a plânovâni potom urci, kdy a jak se takové toky pfenesou. Jinÿmi slovy, kontrola pfistupu
89723 (0989723_CZ.doc) 16.12.2006 urcuje, kterâ data budou oprâvnënâ pro zahrnuti do instance pfenosu, a plânovâni potom urci konkrétni data, formâty a poradi vysilacich instanci. Proto mûze cinnost plânovace ovlivnit pfistupovâ fidici schémata pouzitâ v daném systému.
Podle jednoho provedeni se s rostouci zâtëzi systému typicky BE/AF toky plânuji tak, ze kazdÿ je degradaci ovlivnën pribliznë stejnë. Pro EF toky je ovsem degradace nevyrovnanâ. Podrobnëji, nizsi QoS tfidy se degraduji jako prvni v pokusu o udrzeni sprâvné funkce vyssich QoS tfid. V dané EF QoS tfidë a pfi ignorovâni rozdilû v nastaveni hranice zpozdëni se uzivatelé s nizsimi geometriemi snizi, aby mohlo co nejvice uzivatelû pfijimat pozadovanou propustnost. Cilem tohoto pfistupu je maximalizovat pocet podporovanÿch EF uzivatelû. Pro homogenni EF toky se EF uzivatelé degraduji nevyrovnanë od uzivatelû s nejnizsi geometrii k uzivatelûm s vyssi geometrii. Tento pfistup mâ nëkolik dûsledkû, které jsou osetfeny mimo plânovac, podrobnëji zpracovânim rizeni pfistupu. Nëkteré z tëchto dûsledkû jsou vysvëtleny v nâsledujicich pfikladech.
Tato funkcionalita plânovace je zobrazena na obr. 6, ve kterém jsou toky zobrazeny v pofadi podle geometrie, kterâ roste smërem doprava. S danou aktuâlni zâtëzi systému dâvâ plânovac nizsi prioritu uzivatelûm s nizsi geometrii, aby maximalizoval mnozstvi QoS tokû pfijimajicich pozadovanou QoS. Ùroven uzivatelû s nizkou geometrii se sifi doprava s rostoucim pfetizenim. Plânovac snizuje sluzby pfijaté takovÿmi uzivateli tim, ze jim dâvâ nizsi prioritu. Neni ovsem zodpovëdné zcela odejmout tok, kterÿ by byl typicky funkci rizeni pfistupu a jinÿch blokû monitorovâni propustnosti.
89723 (0989723_CZ.doc) 16.12.2006
Uvazujme situaci, kdy vsichni uzivatelé maji jeden tok a stejnou QoS tfidu, jako napfiklad VoIP tok, a uzivatel s nejvyssi geometrii pozâdâ o EF tok s velmi vysokou propustnosti. Plânovac mùze alokovat vsechny FL sloty uzivateli s nejvyssi geometrii, i kdyz to znamena, ze ostatni uzivatelé nemohou mit zâdné pfenosy. Obecnë je rozhodnuti pfipustëni toku provedeno zpracovânim fizeni pfistupu, které uvazuje aktuâlni zâtëz systému. Kdyz fizeni pfistupu povoli tok, provede plânovac jakoukoliv zâkladni funkcionalitu a alokuje vsechny FL sloty tomuto uzivateli. Vsimnëte si, ze omezeni uzivatelù s nizsi geometrii neznamenâ nezbytnë, ze plânovac maximalizuje pocet EF uzivatelù s prijatelnou pfijmovou propustnosti. Plânovac mùze tento pocet maximalizovat, pokud vsichni uzivatelé maji stejné QoS parametry a stejnÿ typ trafficu (napf. pouze VoIP).
Pokud uzivatelé s nizkou geometrii, jejichz sluzba byla plânovacem omezena kvùli mirnému pfetizeni, pozaduji velmi nizkou propustnost (napf. 1 byte za sekundu), nemusi plânovac pfidëlit tomuto uzivateli pozadovanou propustnost, i kdyz by to neovlivnilo propustnost FL. Opët je zodpovëdnosti fizeni pfistupu pfedvidat cinnost plânovace vzhledem k uzivateli s uvâzenim aktuâlni zâtëze systému. V tomto pfipadë mùze fizeni pfistupu pfinutit plânovac poskytnout sluzbu tomuto uzivateli zvÿsenim jeho indexu QoS tfidy.
Pro nâsledujici popis uvazujme homogenni EF traffic jako scénâf, ve kterém jsou vsichni uzivatelé EF uzivatelé se stejnÿm modelem trafficu. Plânovac nejprve vytvofi seznam kandidâtskÿch instanci pfenosu pro sadu jednouzivatelskÿch a viceuzivatelskÿch vysilacich formâtù. Jednouzivatelské
89723 (0989723_CZ.doc) 16.12.2006 formâty se plni bity z odpovidajicich uzivatelskÿch front. Viceuzivatelské formâty se plni bity z front uzivatelû s kompatibilnimi DRCs.
Plânovac pak pfiradi paketovou metriku kazdé z kandidâtskÿch instanci a zvoli kandidâtskou pfenosovou instanci odpovidajici nejvëtsi paketové metrice. Paketovâ metrika mûze bÿt „prostupnost polynomiâlni, kde operace porovnâni je definovâna jako „lexikâlni porovnâni poskytujici dobfe definovanou maximalizaci.
Uvazujme paketovou metriku pro speciâlni pfipad, kde vsichni uzivatelé jsou EF uzivatelé a kazdÿ uzivatel ma jeden EF tok stejného typu, napf. systém pouze-VoIP a viceuzivatelskÿ pfenosovÿ formât, kde pro vytvofeni instance viceuzivatelského pfenosu pro tento formât se bity hromadi z front uzivatelû s kompatibilnimi DRC. Mezi tëmito uzivateli se bity vyberou na zâkladë casové znâmky odpovidajicich IP datagramû na zâkladë principu FIFO (firstin first-out). Hranice zpozdëni se pro tento pfiklad pfedpoklâdaji stejné. Mezi bity se stejnÿmi casovÿmi znâmkami probëhne vÿbër v pofadi IP paketû a mezi rûznÿmi uzivateli, vÿbër se provede tak, aby se minimalizoval pocet uzivatelû, ktefi maji data v paketû.
Polynom uzitecnÿch dat instance pfenosu mûze bÿt dân jako:
p(x) = Bdz'd + Bd-iZ~d+1 + ... + Biz-1 + Bo kde Bn pfedstavuje pocet bitû obsazenÿ v kandidâtské instanci pfenosu zpûsobujici zpozdëni n slotû. Hodnota D mûze bÿt rovnâ hranici zpozdëni, protoze bity Ize vzit z fronty, kdyz byly takové bity ulozeny ve frontë po dobu pfekracujici hranici zpozdëni a tudiz zpûsobuji vice nez D
89723 (0989723_CZ.doc) 16.12.2006 slotû zpozdëni.
Polynom propustnosti se ziskâ filtraci a pfevzorkovânim zâtëzového polynomu. Jednim zpùsobem je segmentace vektoru koeficientù zâtëzového polynomu do N skupin a nâsledné secteni koeficientù v râmci kazdé skupiny, aby se ziskala kondenzovanâ reprezentace zâtëzového polynomu. Polynom propustnosti se potom ziskâ vydëlenim kondenzovaného zâtëzového polynomu pfedpoklâdanÿm poctem slotû pro kandidâtskou instanci prenosû, kterâ se mâ dekôdovat vsemi zâjemci. Tato procedura je znâzornëna na obr. 7, kde horni fada je zâtëzovÿ polynom p(x) a spodni fada c(x) je kondenzovanou reprezentaci zâtëzového polynomu. Promënnâ x je index instance pfenosu.
Polynom propustnosti je dân jako:
T (z) = c (z) /Ng kde Ng je „obecné rozpëti pfichâzejici v ûvahu pro pfenosovÿ formât a zpûsob jeho vÿpoctu je popsân nize. Vÿslednÿ polynom propustnosti se potom pouzije v paketové metrice pfi vÿbëru kandidâtské instance pfenosu z mnoziny rûznÿch alternativ, z nichz kazdâ se ziskâ podobnë.
Vsimnëte si, ze shora popsanâ paketovâ metrika navrhuje kompromis mezi prosazenim zpozdëni a propustnosti. Pokud se N-l zvoli rovno D, potom pokud c (x) = p(x), vynuti paketovâ metrika pfenos bitû zpûsobujicich nejvëtsi zpozdëni jako prvni. Dâle se pfi vÿbëru kandidâtské instance pfenosu zvoli bity zpûsobujici nejblizsi nejvëtsi zpozdëni. To je vÿsledkem „lexikâlniho porovnâni pouzivaného pfi porovnâni paketovÿch metrik (tj . polynomû propustnosti). Timto zpùsobem zacne porovnâni identifikaci nejvyssiho fâdu kazdého polynomu. Pokud je jeden polynom vyssiho fâdu, potom
89723 (0989723_CZ.doc) 16.12.2006 se polynom definuje jako vëtsi polynom. Pokud maji oba stejnÿ fâd, pak se postupnë porovnaji koeficienty od nejvyssiho râdu a jakmile je v jednom polynomu nalezen vyssi koeficient, pak se tento polynom definuje jako vëtsi polynom.
Segmentace koeficientû p(x) pro ziskâni c(x) implicitnë ignoruje rozdily ve zpûsobeném zpozdëni odpovidajici bitùm v kazdém segmentu. Zato je nyni maximalizace propustnosti flexibilnëjsi . Nejvyssi flexibility v maximalizaci propustnosti se dosâhne, pokud se vsechny koeficienty p(x) zkombinuji v jediném segmentu (napf. c(x) nulového râdu).
V jednom pfikladu dâvaji dva segmenty (napr. c(x) prvniho râdu) kompromis. Nejvëtsi vliv mâ clen nejvyssiho râdu. Pokud je zde vazba mezi rûznÿmi kandidâtskÿmi instancemi, potom se zohlednuji cleny c(x). Proto neni nezbytné segmentovat koeficienty p(x) do vice nez dvou segmentu. To vede k optimalizaci jednoho parametru, kterÿ budeme oznacovat a a nazveme jej ,,zlomek zpozdëni. Celkovë se dvëma segmenty c(x) = (hi2)z-l + (hi), kde „hi2 a „hi jsou pocty bitû v kazdém segmentu. Konkrétnë hi2 je pocet bitû obsazenÿ v kandidâtské instanci pfenosu zpûsobujici zpozdëni vice nez α-krât vëtsi nez hranice zpozdëni a „hi je pocet bitû zpûsobujicich mensi zpozdëni.
Pro pfipad uzivatelû s veskerÿm EF trafficem, ale rûznÿmi modely trafficu (napr. rûznÿmi hranicemi zpozdëni), se argument modifikuje. Bity s mensi hranici zpozdëni jsou câsti hi2 segmentu drive nez bity s vëtsi hranici zpozdëni. Pfirozenou cestou jak toho dosâhnout je pouziti β-nâsobku zpozdëni proti samotnému zpozdëni pfi uklâdâni bitû do kandidâtské instance pfenosu a pfi urceni, kdy se bity
89723 (0989723_CZ.doc) 16.12.2006 stanou cast! hi2 pfevodu.
Obecnë je β navrzeno jako proporcionâlni k jedna lomeno hranice zpozdëni. Vÿsledkem toho je, ze EF bity s nizsi hranici zpozdëni budou smëfovat k nizsi priorité nad EF bity s vyssi hranici zpozdëni.
Obr. 8 ukazuje plânovac podle jednoho provedeni. Plânovac 600 obsahuje jednotku 602 adaptivniho rizeni zpozdëni pfipojenou k pamëtové jednotce 604 uzpùsobenou pro uklâdâni a udrzovâni informaci o frontë. Pamëtovâ jednotka 604 uklâdâ také informace tÿkajici se kazdé fronty, vcetnë zpozdëni a/nebo vÿstupni senzitivity, prioritni tridy, jako napriklad EF, BE atd a dalsich informaci, které mohou bÿt ulozeny do plânovace, jako napriklad QoS informace. Data fronty a informace ulozené v pamëtové jednotce 604 poskytnuté jednotce 608 vÿpoctu bitové metriky a jednotce 606 vÿpoctu bitové vyrovnâvaci metriky. Tyto jednotky generuji bitovou metriku a bitovou vyrovnâvaci metriku. Vypoctenâ bitovâ metrika se poskytne jednotce 608 vÿpoctu bitové metriky, jednotce 616 vÿpoctu paketové metriky a jednotce 610 vÿbëru fronty. Bitovâ vyrovnâvaci metrika a vybrané fronty se poskytnou generâtoru 612 kandidâtské instance prenosu. Paketovâ metrika z jednotky 616 vÿpoctu paketové metriky a sada kandidâtskÿch instanci prenosu generovanÿch generâtorem 612 se poskytne jednotce 614 vÿbëru instance prenosu.
Obr. 9 zobrazuje pamëtovou jednotku 604 pro uklâdâni mnoha front s cekajicimi daty. Data fronty se pro kazdÿ tok uklâdaji jako data fronty 620. Kazdâ fronta 620 mâ odpovidajici QoS tfidu nebo prioritni trida 622 a indikâtor 624 senzitivity.
89723 (0989723_CZ.doc) 16.12.2006
Obr. 10 je vÿvojovÿ diagram ilustrujici zpûsob plânovâni podle jednoho provedeni. Zpûsob 500 nejprve v rozhodovacim kroku 502 urci, jestli je FL zaneprâzdnën, tj . jestli je dostupnÿ casovÿ slot pro vysilâni nového paketu. Jestlize je dostupnÿ slot pro vysilâni nového paketu, vygeneruje plânovac seznam kandidâtskÿch instanci pfenosu na zâkladë podmnoziny definovanÿch a odvozenÿch formâtû pfenosu v kroku 504. Metrika paketû odpovidajici kazdé kandidâtské instanci pfenosu se vypocte v kroku 506. V kroku 508 plânovac vybere instanci pfenosu s nejvyssi hodnotou pro paketovou metriku. V kroku 510 se instance pfenosu naformâtuje pro pfenos.
Obr. 11 ukazuje jedno provedeni pro generovâni mnoziny kandidâtskÿch instanci pfenosu a implementaci kroku 504 ve zpûsobu 500. V kroku 520 plânovac vypocte bitovou metriku pro kazdÿ zâznam ve frontë. V kroku 522 plânovac vypocte bitovou vyrovnâvaci metriku pro kazdou frontu. Hodnoty bitové metriky se porovnaji, aby se vybrala sada front pro instanci pfenosu, krok 524. Bitovâ vyrovnâvaci metrika se pouzije k vygenerovâni kandidâtskÿch instanci pfenosu za pouziti sady front, krok 526. Pfiklady zpûsobû a prostfedkû pro takové vÿpocty a porovnâni jsou uvedeny dâle.
Vsimnëte si, ze se v jednom provedeni kandidâtskâ instance pfenosu s jednouzivatelskÿm formâtem vygeneruje pro kazdého uzivatele, kterÿ mâ cekajici data. Vysilaci formât se nastavi do kanonického formâtu, kterÿ odpovida uzivatelovu DRC. Pro uzivatele, od kterÿch byla pfijata NULL DRC se kandidâtskâ instance pfenosu vytvofi pouze pokud mâ uzivatel cekajici „EF data. Pro BE/AF uzivatele se NULL DRC neobslouzi, protoze tito uzivatelé udrzuji nizkou cetnost
89723 (0989723_CZ.doc) 16.12.2006 zahazovâni ve vrstvë Radiového vrstvového protokolu (RLP
Radio Layer Protocol).
Kandidâtskâ instance prenosu s viceuzivatelskÿm formâtem se vygeneruje pro kazdÿ definovanÿ a odvozenÿ „kanonickÿ viceuzivatelskÿ formât. K povoleni odvozenÿch formâtû v tomto stavu Ize pouzit pfiznak.
Vsimnëte si, ze sada kandidâtskÿch instanci prenosu vygenerovanâ v kroku 506 je zalozena na „kanonickÿch formâtech. Krâtké pakety tedy nejsou v tomto kroku obsazeny. Ùcelem je pomoci premostit plânovac k uzivatelûm s vyssi geometrii a zabrânit uzivatelûm s nizkou geometrii ve zneuzivâni krâtkÿch paketû a tedy snizovâni propustnosti FL. Krâtké pakety se pouzivaji v kroku maximalizace efektivity plnëni (jak je zobrazeno na obr. 12), kdyz mâ vybranâ kandidâtskâ instance prenosu zâtëz, kterâ se hodi do krâtkého paketu.
Krok maximalizace efektivity plnëni Ize provést konzistentnë s obr. 12. V tomto kroku mûze vybranâ kandidâtskâ instance prenosu projit zmënou vysilaciho formâtu podle nâsledujicich pravidel.
(1) Pokud vybranâ kandidâtskâ instance prenosu obsahuje jednoduchâ uzivatelskâ data, potom je povoleno, aby znovu vybranÿ formât byl bud’ jednouzivatelskÿ formât kompatibilni s uzivatelovÿm DRC nebo viceuzivatelskÿ formât.
(2) Jestlize vybranÿ kandidâtskÿ formât prenosu obsahuje data dvou nebo vice uzivatelû, potom mûze bÿt znovu vybranÿ formât jinÿ viceuzivatelskÿ formât. V jednom pripadë se vybere nejmensi formât schopnÿ nést tuto zâtëz. Tato
89723 (0989723_CZ.doc) 16.12.2006 postkonverze se dale fidi pfiznaky, které mohou zabrânit konverzi do nëkterého z viceuzivatelskÿch formâtû.
V jednom provedeni krok 510 formâtovâni instance prenosu dale obsahuje krok 530, kde plânovac maximalizuje efektivitu plnëni instance prenosu, a krok 532, ve kterém plânovac provâdi apriorni vÿpocet ACK, viz. obr. 12. Navic mûze krok 530 zahrnovat zpùsob, jak je zobrazen na obr. 13. Instance prenosu se nejprve vyhodnoti (rozhodovaci krok 540), aby se urcilo, jestli se pouzije jednouzivatelskÿ formât. Pokud se pouzije jednouzivatelskÿ formât, kazdÿ krok je dâle vysvëtlen podrobnëji.
V jednom provedeni plânovac urci maximâlni rozpëti odpovidajici DRCs uzivatelû, pro které vybranâ instance prenosu ponese datové bity. Plânovac spocita vyhrazenÿ pocet pfenosovÿch slotû. Pokud nëkteri uzivatelé nemaji dosud potvrzen sprâvnÿ prijem pfenâsené informace, tj. prenesenou ACK zprâvu, a pokud jsou jakâkoliv cekajici data v kterékoliv frontë, ukonci AN prenos.
Alternativni provedeni obsahuje specifické prostredky a zpûsoby pro dokoncovâni zpûsobu 500 zobrazeného na obr. 10, zahrnujiciho, ale neomezujiciho se na bitové vyrovnâni, aby se vytvofily vsechny kandidâtské instance prenosu a vÿpocet paketové metriky.
Vÿpocty paketové metriky se provâdëji v kroku 508, zatimco bitové vyrovnâni je soucâsti formâtovâni instance prenosu v kroku 508. Obecnë mûze bÿt jednouzivatelskâ instance prenosu vyrovnâna bity z jednoho nebo vice tokû stejného uzivatele. Viceuzivatelské instance s definovanÿm formâtem, jako je napriklad definovân v tabuice 1, Ize
89723 (0989723_CZ.doc) 16.12.2006 vyrovnat bity od jednoho nebo vice uzivatelû, kde takovi uzivatelé vyslali DRC kompatibilni s viceuzivatelskÿm formatera. Viceuzivatelskâ instance s odvozenÿm formatera mûze bÿt vyrovnâna bity od jednoho nebo vice uzivatelû, jejichz pfenesené DRCs jsou kompatibilni s viceuzivatelskÿm formatera a kterâ splnuji doplhkovÿ pozadavek ,,mëkké kompatibility. DRC se povazuje za mëkce kompatibilni k odvozenému viceuzivatelskému formâtu, pokud ocekâvanÿ pocet slotû k dekôdovâni odpovidajiciho „definovaného formâtu je mensi nebo roven rozsahu odvozeného formâtu. Ocekâvanÿ pocet slotû Ize ziskat porovnânim pomëru Signâl-interference a Sum (SINR) pozadovaného pro pfijimanÿ DRC k SINR pozadovanému k ûspësnému dekôdovâni (napf. za pritomnosti prûmërného bilého gausovského sumu (Average White Gaussian Noise AWGN). Alternativnë mûze bÿt predpoklâdanÿ pocet slotû urcen porovnânim pozadované rychlosti k efektivni rychlosti prenosu dat odvozeného formâtu.
Nâsledujici popis predpoklâdâ QoS tfidy obsahujici: i) BE/AF a jednu tfidu EF. Zpûsob pfipousti také rozsireni na vice EF trid. Podle tohoto vynâlezu je kazdému bitu cekajicimu ve frontë prirazena bitovâ metrika, kterâ je dâna jako polynom tvaru:
bi(z) = [hi2]z~2 + [hi] z-1 + [lo] kde i je index bitu a pouze jeden ze tri koeficientû {hi2, hi, lo} mûze bÿt nenulovÿ. Vsimnëte si, ze popis je dân na ûrovni bitû, typicky vsechny bity v IP datagramu maji stejnou metriku a vÿpocty paketové metriky nemusi nezbytnë zahrnovat hromadëni na bitové ûrovni.
Necht δ je stâvajici zpozdëni spojené s bitem z EF
89723 (0989723_CZ.doc) 16.12.2006 toku. Nastavme nâsledujici definice pro hi2 a hi:
hi2 = βδ + μ pokud δ > a HraniceZpozdëni a hi = βδ + μ pokud δ a HraniceZpozdëni kde β je parametr spojenÿ s EF tokem a je inverznë sdruzenÿ s hranici zpozdëni, kde μ je velké cislo a a je pevnë danÿ skalâr, napfiklad 0,25 a je nezâvislÿ na typu EF toku.
Pro BE/AF tok nastavme lo nâsledovnë:
lo=l/[AvgThroughput-TrgtThroughput] kde AvgThroughput je prûmërnâ propustnost odpovidajiciho uzivatele a TrgtThroughput je minimâlni propustnost pozadovanâ pro tohoto uzivatele. Pro BE uzivatele je TrgtThroughput nastaven na nulu. Paketovâ metrika (napf. polynom propustnosti) se potom ziskâ nâsledovnë:
PaketovâMetrika = NahromadënâBitovâMetrika / Ng kde Ng je generické rozpëti definované nebo odvozené kandidâtské instance prenosu, které pfichâzi v ûvahu, a nahromadënâ bitovâ metrika (NahromadënâBitovâMetrika) je soucet bitovÿch metrik odpovidajici vsem bitûm obsazenÿm (nebo vyrovnanÿm) v kandidâtské instanci. Hodnota Ng mûze bÿt nastavena na jedna, v takovém pfipadë bude paketovâ metrika rovna nahromadëné bitové metrice. V tomto pfipadë bude plânovac radëji nez propustnost na instanci prenosu maximalizovat zâtëz na instanci pfenosu. To mûze mit jako
89723 (0989723_CZ.doc) 16.12.2006 nezâdouci efekt vytvofeni DRC necitlivosti, coz zpûsobi snizenou propustnost, kde takovâ degradace nemusi odpovidat chovâni popsanému na obr. 6. Jinÿ pfistup je nastavit Ng na „pseudo-span, kterÿ Ize nastavit na jedna pro 1 a 2 slotové vysokorychlostni pakety, na dva pro 4 slotové pakety atd, cimz se odlisuji vysokorychlostni pakety na zâkladë zâtëze, zatimco nizkorychlostni formâty se odstavi nastavenim Ng na velké hodnoty.
Nâsledujici vlastnosti poskytuji pfemostëni uzivatelù s vysokou geometrii k plânovaci:
(1) Pokud je DRC kompatibilni s viceuzivatelskÿm formâtem, je také kompatibilni se vsemi viceuzivatelskÿmi formâty nizsi nominâlni datové rychlosti a (2) Plânovac pouzije polynom „propustnosti jako vÿbërové zafizeni.
Jeden nâvrh pouzivâ clen μ s vysokou hodnotou v definici hi a hi2 koeficientu pro bitovou metriku. Tyto bity se vyrovnaji v poradi podle hodnoty βδ, protoze μ je pro vsechny bity spolecné. Paketovâ metrika se vypocte jako by se odpovidajici zâznam bitové metriky zmënil na jedna, coz vede k tomu, ze paketovâ metrika je ùmërnâ polynomu propustnosti. To eliminuje efekt βδ pro vÿpocet paketové metriky v paketové metrice.
Vsimnëte si, ze jak bylo popsâno vÿse, plânovac pouzivâ pevnou HraniciZpozdëni pro vsechny uzivatele. Uzivatelé s dobrÿm pokrytim typicky potfebuji pouze zlomek HraniceZpozdëni. S rostoucim poctem uzivatelù zacinâ degradace nejprve u nejslabsich uzivatelù, zatimco uzivatelé
89723 (0989723_CZ.doc) 16.12.2006 s vysokÿmi geometriemi nemusi bÿt zâtëzi silnë ovlivnëni.
Jedno provedeni adaptivnë nastavuje hranici zpozdëni a pfibuzné parametry (napf. a) mëfenim podilu dobrÿch EF uzivatelù. HraniceZpozdëni pouzitâ plânovacem mùze bÿt iterativnë zvÿsena nebo snizena, aby se udrzel podil dobrÿch uzivatelù na pozadované ùrovni. V jednom provedeni je implementovâna jednoduchâ smycka prvniho fâdu se spodni hranici pro HraniciZpozdëni.
V plânovaci popsaném vÿse pouzije zpûsob definujici bitovou metriku pro BE/AF uzivatele nâsledujici vÿpocet:
Bitovâ metrika = 1 / [AvgThroughput - TrgtThroughput].
Pro rùzné systémy, provozni cile a nâvrhy Ize implementovat jiné definice bitové metriky.
FL pfenosové formâty kompatibilni s kazdÿm DRC indexera jsou také uvedeny v tabuice 1 pro dvë mnoziny subtypû protokolu definovanÿch ve specifikacich IxEV-DO Rel-0 a revizi A, vcetnë navrzenÿch zmën v nedâvnÿch pfispëvcich k Rev-A definujicich kompatibilni viceuzivatelské formâty pro DRC indexy 0x0, 0x1 a 0x2. Prenosové formâty, jak je uvedeno ve specifikaci Rev. A, jsou reprezentovâny trojici (VelikostPaketu, Rozpëti, DélkaHlavicky). „VelikostPaketu je pocet bitù nosného pfenosového formât zahrnujici Cyklickÿ redundantni kôd (CRC) a paticka. „Rozpëti je nominâlni (napf. maximâlni) pocet slotû, které mùze vzit instance pfenosu na pfimém linku. „DélkaHlavicky je celkovÿ pocet hlavickovÿch cipû. Jak je uvedeno v revizi A IxEV-DO specifikaci, kanonické pfenosové formâty pro kazdé DRC jsou zobrazeny tucnë. Vsimnëte si, ze Rel-0 definuje pouze
89723 (0989723_CZ.doc) 16.12.2006 jednouzivatelské prenosové formâty, zatimco urcité subtypy v revizi A definujî jak jednouzivatelské, tak viceuzivatelské formâty. Navic, v revizi A Ize pro kazdÿ DRC index definovat vice pfenosovÿch formâtû. AT se pokousi prijimat pakety pro kazdÿ z tëchto formâtû. Viceuzivatelské formâty se rozlisuji podle jejich unikâtnich MAC indexù, tj. hlavicka kazdého viceuzivatelského formâtû pouzivâ odlisnou Walshovu obâlku. Vsechny jednouzivatelské formâty pouzivaji MAC index pfifazenÿ uzivateli.
DRC index Rychlost (Kbps) RevO pfenosovÿ formât RevA jednouzivatelské prenosové formâty RevA Viceuzivatelské prenosové formâty
0x0 0,0 zâdné (128,16,1024), (256,16,1024), (512,16,1024), (1024,16,1024) zâdné
0x1 38,4 (1024,16,1024) (128,16,1024), (256,16,1024), (512,16,1024), (1024,16,1024) zâdné
0x2 76, 8 (1024,8,512) (128,8,512), (256,8,512), (512,8,512), (1024,8,512) zâ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)
OxA 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 zâ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 zâ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 pfipomenuti se instance pfenosu odkazuje na pfenosovÿ format s konkrétni sadou bitû z jedné nebo vice vybranÿch front, které se ji maji transportovat. Kandidâtskâ
89723 (0989723_CZ.doc) 16.12.2006
- 54 instance pfenosu se odkazuje na instanci prenosu, kterâ se mâ vyhodnotit plânovacim algoritmem pro moznÿ prenos. Viceuzivatelské prenosové formâty (1024,4,256), (2048,4,128), (3072,2,64), (4096,2,64) a (5120,2,64) se oznacuji jako kanonické viceuzivatelské prenosové formâty. Viceuzivatelské prenosové formâty (128,4,256), (256,4,256) a (512,4,256) se oznacuji jako „nekanonické viceuzivatelské formâty. Odvozené prenosové formâty se ziskaji jednoduse nastavenim rozpëti odpovidajiciho definovaného formâtu na mens! hodnoty nez nominâlni hodnota, pokud se maji ziskat z definovanÿch formâtu pfedcasnÿm ukoncenim. Celkovë mohou bÿt vysilaci formâty a instance kanonické nebo nekanonické; jednouzivatelské nebo viceuzivatelské a definované nebo odvozené. Pojem ,,nominâlni pocet slotù se pouzivâ k odkâzâni na maximâlni pocet slotù pro definovanÿ pfenosovÿ formât a znovu definovanÿ maximâlni pocet slotù pro odvozenÿ pfenosovÿ formât.
Nâsledujici popis plânovacich prostfedkû a zpûsobù uvazuje oktetové plânovâni, ve kterém oktety cekajici v rûznÿch frontâch mohou bÿt obslouzeny v jakémkoliv mnozstvi (v jednotkâch oktetû). Typicky se kazdÿ tok ulozi jako alespon jedna fronta dat. Proto mâ kazdâ fronta specifické QoS pozadavky, které jsou s ni spojeny. Data se uklâdaji v kazdé frontë ve formé oktetù. Plânovâni Ize provést, kde se ménë nez plnÿ oktet dat dâ do instance pfenosu nebo fyzické vrstvy paketu pro pfenos na FL.
Vsimnëte si, ze nëkteré aplikace mohou vyzadovat plânovâni zalozené na râmcich, kde (zapouzdfené) datagramy toku se maji obsluhovat bez fragmentace v paketech fyzické vrstvy. Plânovaci prostfedky a zpùsoby zalozené na oktetech mohou bÿt také rozsifeny na plânovâni zalozené na râmcich.
89723 (0989723_CZ.doc) 16.12.2006
Povsimnëte si také, ze rizeni pristupu tësnë souvisi s plânovânim, pricemz rizeni pristupu slouzi k pripustëni/odmitnuti pfichozich tokû na zâkladë aktuâlni zâtëze systému a predvidânim, zda prichozi tok mûze bÿt uspokojivë obslouzen (tj . jsou splnëny QoS elle) bez zpûsobeni nepfijatelné degradace jiz povolenÿch tokû.
„Tok, jak se zde pouzivâ, oznacuje datovÿ tok smërovanÿ k danému uzivateli. Zdroj toku mûze bÿt jedna nebo vice uzivatelskÿch aplikaci, zahrnujicich mimo jiné, ale neomezujicich se na stahovâni souborû (ftp), surfovâni po webu (http), online hry nebo VoIP. Tok mûze bÿt také generovân vlastnim komunikacnim systémem, jako signâlni toky, které slouzi k udrzeni systému ve funkenim stavu pri sprâvném udrzovâni uzivatelské relace. Jinÿm pfikladem datového toku je datovÿ tok generovanÿ testovaci aplikaci, kde se datovÿ tok pouzivâ k testovâni alespon câsti komunikacniho systému.
Jinÿmi slovy, tok je tokem dat a je câsti komunikace s alespon jednim uzivatelem. Existuje mnoho aplikacnich tokû, kazdÿ mâ specifické QoS pozadavky a tolerance. Kazdÿ tok mûze mit rûznou sadu QoS pozadavkû, jako cilovâ propustnost a hranice zpozdëni. Priklady takovÿch pozadavkû jsou podrobnëji popsâny nize.
Uzivatel mûze mit vice soucasnÿch tokû s rûznÿmi QoS pozadavky. Kazdÿ tok mûze bÿt generovân bud’ jedinou aplikaci, jako napfiklad pro VoIP, ftp, signalizace atd., nebo mûze bÿt generovân vice aplikacemi, které jsou agregovâny do jediného toku fadicem zâkladnové stanice (ESC - Base station controller). Pokud BSC agreguje toky timto
89723 (0989723_CZ.doc) 16.12.2006
- 56 zpûsobem, mùze se agregovanÿ tok jevit plânovaci jako jedinÿ tok s dobfe definovanÿmi QoS pozadavky. Plânovac nemusi bÿt schopen rozlisit mezi daty generovanÿmi rùznÿmi aplikacemi, ale obsazenÿmi v agregovaném toku. Jinÿ typ agregace, kterou Ize provést plânovacem, je uveden nize.
Kazdÿ tok mâ alespon jednu frontu uchovâvajicî data pro prvnî pfenos (oznacovanÿ jako FTx) a mùze mit dalsi fronty pro opakované pfenosy, jako napfiklad protokol radiové vrstvy (Radio Layer Protocol - RLP), frontu pro opakovanÿ pfenos (RT - ReTransmission - RTx fronta pro tok x) a/nebo frontu pro opakovanÿ pfenos MAC vrstvy (zpozdënÿ pozadavek na automatické opakovâni - ARQ - Automatic Repeat Request) , nebo zpozdënâ ARQ (DARQ) fronta). V jednom provedeni mâ kazdÿ oktet v kazdé frontë pfesnë stanovenou casovou znâmku, podle které mùze plânovac urcit aktuâlni zpozdëni zpùsobené oktetem. Casové znâmky jsou pfifazeny dâvkâm dat jako jsou napfiklad (zapouzdfené) datagramy, z cehoz vyplÿvâ, ze kazdÿ oktet dâvky dat mâ stejnou casovou znâmku. Jednotlivé datagramy mohou nést vice râmcû aplikacni ùrovnë, které mohly bÿt vygenerovâny aplikaci v rûznÿch casech. Pfedpoklâdâ se, ze casové znâmky aplikacniho râmce nejsou plânovaci znâmy. Tento pfedpoklad je oprâvnënÿ, protoze kompletni datagram se mâ ûspësnë pfijmout uzivatelem pfedtim, nez mùze bÿt kterÿkoliv z râmcû aplikace, které nese, parsovân pfijetim koncovou aplikaci.
V nâvrhu plânovace podle jednoho provedeni se uvazuji tfi hlavni QoS tfidy. Nejlepsi ûsili (BE - Best Effort) je definovâno tak jako ve slovnicku a konkrétnë oznacuje toky, které typicky mohou mit velkâ zpozdëni, ale vyzaduji nizkou cetnost bitovÿch chyb (BER - Bit Error Rate). Ackoliv zde nejsou minimâlni pozadavky na propustnost, objem pfenâsenÿch
89723 (0989723_CZ.doc) 16.12.2006 dat mûze bÿt velkÿ. Pfiklady tokû, které Ize povazovat za BE, zahrnuji stahovâni souborû (ftp) a surfovâni po webu (http). Zajistëné smërovâni (AF - Assured Forwarding) oznacuje toky, které jsou obecnë podobné BE tokûm tolerujicim urcitou ûroven zpozdëni, ovsem AF toky se od BE tokù lis! tim, ze AF toky maji typicky minimâlni prùmërnou propustnost. Jednim pfikladem aplikace klasifikované jako AF tok je videostream generovanÿ videokonferencni aplikaci. Urychlené smërovâni (EF - expedited forwarding) oznacuje toky, které typicky, ale ne nezbytnë, maji nizkÿ pozadavek na propustnost a maji striktni pozadavky na zpozdëni. Pozadavek na spolehlivost nemusi bÿt tak striktni jako u BE tokû, mûze bÿt pfijatelné ztratit malÿ podil dat aplikace, jako napfiklad 1 az 2 %. Pfiklady aplikaci klasifikovanÿch jako EF toky zahrnuji, ale neomezuji se na VoIP a online hry.
Vzhledem k prostfedkûm a zpûsobùm plânovâni je rozdil mezi BE a AF toky pozadavek minimâlni propustnosti, kterÿ je pro BE toky nulovÿ. Jinak jsou tyto dvë QoS tfidy podobné. Aby se dâle odlisily konkrétni toky, uvazujme EF tfidu, kterâ mûze obsahovat mnozstvi rûznÿch typû aplikaci. V EF tfidë tokû mohou bÿt toky s rûznÿmi prioritami. Napfiklad aplikace jako VoIP a hlasovou cast videokonferencnich aplikaci Ize povazovat za aplikace s vyssi prioritou nez obrazovâ cast videokonferencni aplikace. Online hry Ize povazovat za aplikace s nizsi prioritou nez maji jak zvukové, tak obrazové aplikace.
Navic k tokûm generovanÿm uzivatelskÿmi aplikacemi mâ systém podporujici IS-856 vnitfnë generované toky, jako napfiklad signâlni tok, kterÿ je pozadovân k udrzeni systému v provozu, a toky generované testovacimi aplikacemi
89723 (0989723_CZ.doc) 16.12.2006 pouzivané k testovâni systému.
Typické QoS pozadavky Ize specifikovat v pojmech fady uvah popsanÿch promënnÿmi, zahrnujicimi, ale neomezujicimi se na hranici zpozdëni, cilovou propustnost, spolehlivost, neklid atd.
Hranice zpozdëni je identifikovâna promënnou oznacenou jako „HraniceZpozdëni, kterâ je parametrem specifikovanÿm pro kazdÿ tok udâvajicim maximâlni dobu, bëhem které se mâ datagram uspësnë dorucit uzivateli. Hranice zpozdëni se mëfi relativnë k casové znâmce datagramu, kterÿ je v tomto provedeni oktetem. Vsimnëte si, ze se toto lisi od hranice celkového zpozdëni, které zahrnuje jiné celkové slozky zpozdëni nez FL zpozdëni. V jednom provedeni, jakmile se dosâhne hranice zpozdëni, se datagram odebere z fronty. Jinÿmi slovy, pokud nelze datagram poslat ve specifikované hranici zpozdëni, datagram se zahodi.
Cilovâ propustnost je identifikovâna promënnou oznacovanou jako „CilovâPropustnost, kterâ je dalsim specifikovanÿm QoS parametrem. Cilovâ propustnost oznacuje minimâlni prûmërnou propustnost toku. Prûmërovâni propustnosti Ize definovat pomoci filtru s konecnou impulsni odezvou (IIR) prvniho fâdu s odpovidajici casovou konstantou. V jednom provedeni se casovâ konstanta nastavi na 1 ms.
Tfetim QoS pozadavkem mûze bÿt spolehlivost. Typicky fyzickâ vrstva systému poskytuje 1% chybovost paketû (PER Packet Error Rate), kterâ nemusi bÿt dostatecnâ pro aplikace vyzadujici vÿjimecnë nizkou chybovost, jako napriklad stahovâni souborû. Proto, aby se dâle snizily ztrâty pfi
89723 (0989723_CZ.doc) 16.12.2006 prenosu vzduchem, Ize vyuzit mechanismy pro opakovanÿ pfenos. Typické mechanismy pro opakovanÿ pfenos jsou RLP opakované pfenosy a MAC vrstva opakovanÿch prenosu, jako napfiklad RTx a DARQ fronty. Aby se dale zvÿsila spolehlivost, Ize mimo jiné jako transportni vrstvu pro aplikaci pouzit protokol fizeni pfenosu (TCP - transmission control protocol).
V jednom provedeni je plânovac navrzen tak, aby maximalizoval kapacitu systému pfi zajistëni rovnosti mezi toky a splnëni jistÿch priorit a QoS pozadavkû jednotlivÿch toku. Koncept kapacity a rovnosti zâvisi na QoS pozadavcich jednotlivÿch toku. Pro BE toky Ize kapacitu definovat jako celkovou BE propustnost pfenesenou sektorem. Pro EF toky Ize konkrétni typ kapacity definovat jako pocet uzivatelù, kterÿ Ize podporovat pfi splnëni jejich QoS pozadavkû. V jednom pfikladu plânovâni EF toku systém definuje VoIP kapacitu tak, ze pocet VoIP uzivatelù se vybere jako pocet, kterÿ pokryje 95 % uzivatelù, ktefi ùspësnë pfijmou v prùmëru 98 % aplikacnich datovÿch râmcû (nebo oktetû). V jednom pfikladu je ùspësnost urcena râmci pfijatÿmi v râmci specifikované hranice zpozdëni a bez pfenosovÿch chyb. Lze pouzit alternativni kritéria ùspësnosti. Aby se dosâhlo rovnosti mezi toky, lze pro plânovâni BE tokù pouzit kritéria proporcionâlni rovnosti (PF - proportional fairness) a k plânovâni EF tokù prioritniho kritéria. Timto zpùsobem budou s rostouci zâtëzi systému degradovâny vsechny BE toky stejnë, tj. BE toky se degraduji bez rozdilu.
Pro EF toky je zâdouci, aby mëly s rostouci zâtëzi systému nebo pfi vÿskytu pfetizeni nerovnou degradaci napfic uzivateli. Jako prvni pociti degradaci ty EF toky, které maji nejnizsi prioritu. Mezi EF toky s podobnÿmi QoS
89723 (0989723_CZ.doc) 16.12.2006 pozadavky a stejnou ûrovni priority ovlivni degradace nejprve toky uzivatelû s nejhorsim stavem kanâlu. S timto pfistupem mûze s rostoucim pretizenim systému splnovat QoS pozadavky nejvëtsi moznÿ pocet EF tokû. Tento pfistup obvykle vede k pribliznë inverznimu vztahu mezi uzivatelskÿmi podminkami kanâlu a statistikou zpozdëni jeho EF tokû. Tato vlastnost se oznacuje jako ,,Rovnost zpozdëni.
Pfenosovÿ formât je trojice ve formé (VelikostPaketu, Rozpëti, DélkaHlavicky), kterâ popisuje urcité parametry FL paketu. Velikost paketu oznacuje zâtëz fyzické vrstvy v bitech. Rozpëti oznacuje maximâlni pocet slotû, kterÿ mûze paket tohoto formâtu pfenâset a délka hlavicky oznacuje trvâni hlavicky v cipech.
V systému podporujicim IS-856 se pouzije pfizpûsobeni linku k urceni rychlosti pfenosu dat FL pro kazdého uzivatele. Kazdÿ AT pfenâsi pozadavek na data indikujici maximâlni rychlost pfenosu dat, kterou mûze AT pfijimat data. Pozadavek na data se oznacuje jako zprâva fizeni rychlosti pfenosu dat (DRC - Data Rate Control) . Formât DRC zprâvy pouzivâ rûzné DRC indexy, kazdÿ urcuje pfenosovÿ format. AT vysilâ DRC zprâvy na DRC kanâlu. Pro kazdÿ platnÿ DRC index, kromë NULL DRC v IS-856 Rel-0 je zde jeden nebo vice jednouzivatelskÿch a nula nebo vice viceuzivatelskÿch pfenosovÿch formâtû, které Ize obslouzit na FL, aby nesly data k uzivateli. Tabulka 1 udâvâ DRC indexy jak jsou definovâny v IS-856. Dâle tabulka l°obsahuje kompatibilni pfenosové formâty pro kazdÿ DRC index.
V IxEV-DO Rev-A specifikaci se definuje jeden z kompatibilnich jednouzivatelskÿch pfenosovÿch formâtû jako kanonickÿ formât pro DRC. Vsimnëte si, ze DRC tak jak se zde
89723 (0989723_CZ.doc) 16.12.2006 pouzivâ, odpovida specifickému formâtu pozadovanému AT a identifikovanému DRC indexem. Obecnë, pokud AT ûspësnë dekôduje paket pfenesenÿ pouzitim kanonického formâtu odpovidajiciho danému DRC, potom bude takovâ AT pravdëpodobnë ûspësnë dekôdovat paket prenesenÿ v kterémkoliv kompatibilnim nekanonickém jednouzivatelském formâtu a nebo kompatibilnim viceuzivatelském formâtu. To je s vÿjimkou DRC indexû: 0x0; 0x1 a 0x2. Vsimnëte si, ze i kdyz nëkteré viceuzivatelské formâty kompatibilni s danou DRC mohou mit vëtsi délky hlavicky ve srovnâni s kanonickÿmi formâty, nemusi tyto nezbytnë vést k zisku ve zpracovâni dat.
Pro kterékoliv DRC s vÿjimkou vsech formâtu kompatibilnich s DRC indexem 0x0 a viceuzivatelskÿmi formâty kompatibilnimi s DRC indexy 0x1 a 0x2, je velikost zâtëze nekanonického formâtu typicky mensi nebo rovna zâtëzi kanonického formâtu. Navic rozpëti nekanonického formâtu je typicky vëtsi nebo rovno rozpëti kanonického formâtu. Pokud je uzivatel, od kterého byl pfijat DRC index 0x0 (napf. NULL pozadavek na data), obslouzen libovolnÿm formâtem, pak zde neni obecnë zâruka spolehlivého pfijeti paketû. Pro DRC indexy 0x1 a 0x2 tedy kompatibilni viceuzivatelské formâty nemusi zarucit dostatecnë spolehlivÿ pfijem, protoze velikost zâtëze a rozpëti tëchto formâtu nesplhuje tuto vlastnost.
V jednom provedeni nemusi plânovac k obslouzen! uzivatelû, od kterÿch pfijal DRC 0x0, 0x1 nebo 0x2 vyuzit viceuzivatelské pakety. Také obslouzen! uzivatelû, od kterÿch je pfijat NULL DRC mûze bÿt omezeno na urcité podminky. Tyto podminky mohou bÿt zaclenëny do systému.
89723 (0989723_CZ.doc) 16.12.2006
Pro viceuzivatelské pfenosové formâty, pokud je dané DRC kompatibilni s danÿm viceuzivatelskÿm formâtem, je potom stejné DRC kompatibilni se vsemi viceuzivatelskÿmi formâty nizsich rychlosti pfenosu dat.
«Instance pfenosu oznacuje kombinaci pfenosovÿch formâtù a identifikuje datové oktety, které mohou bÿt pfeneseny paketem tohoto formâtu. Napfiklad sada MAC indexû pro uzivatele, kterÿm paket pfinâsi datové oktety a sadu ukazatelû do odpovidajicich front oznacujicich presnë oktety, které se maji pfenést v paketu, mûze definovat formât pfenosu.
Plânovac mûze generovat sadu hypotetickÿch pfenosovÿch instanci a potom vybrat jednu z tëchto instanci pro pfenos na FL. Pojem, kterÿ se pouzivâ v tomto dokumentu k oznaceni kterékoliv z tëchto hypotetickÿch pfenosovÿch instanci je „kandidâtskâ instance pfenosu.
V jednom provedeni plânovace, které obsahuje adaptivni sprâvu zpozdëni, pouzivâ plânovac rûzné metriky, které zahrnuji: 1) bitovou vyrovnâvaci metriku; 2) bitovou metriku a 3) paketovou metriku. Bitovâ metrika se pouzivâ k vÿbëru front, které jsou vhodné pro zaclenëni do aktuâlni instance pfenosu. Metriky vklâdâni bitu urcuji pofadi, ve kterém se bity nebo oktety, které cekaji v rûznÿch frontâch, zaclenuji do dané kandidâtské instance pfenosu. Jakmile se vytvofi kandidâtskâ instance pfenosu, vypocte se paketovâ metrika pro kandidâtskou instanci pfenosu. Paketovâ metrika se potom pouzije k vÿbëru vitëzné instance pfenosu ze sady podobnë vytvofenÿch kandidâtskÿch instanci pfenosu. Paketovâ metrika kandidâtské instance pfenosu se urci jednoduchÿm sectenim bitovÿch metrik vsech oktetû obsazenÿch v kandidâtské
89723 (0989723_CZ.doc) 16.12.2006 instanci prenosu a vydëlenim tohoto souctu rozpëtim pfenosového formâtu kandidâtské instance prenosu:
PaketovàMetrika[k] =
--------- V BitovàMetrika[i] Rozpeti[k] ieP[k] kde k predstavuje index na konkrétni kandidâtskou instanci prenosu v sadë alternativ, Rozpëti[k] predstavuje rozpëti definované pro odpovidajici pfenosovÿ formât, P[k] predstavuje sadu oktetû, které jsou obsazeny v kandidâtské instanci prenosu a BitovâMetrika[i] predstavuje bitovou metriku i-tého oktetu obsazeného v kandidâtské instanci.
Paketovou metriku Ize tudiz interpretovat jako odhad „okamzité propustnosti bitové metriky, pokud byly kandidâtské instance prenosu skutecnë obslouzeny na FL.
Obecnë, pokud je metrika vklâdâni bitû oktetu i vëtsi, nez metrika vklâdâni bitû jiného oktetu j, potom Ize bitovou metriku oktetu i nastavit vëtsi nebo rovnu bitové metrice oktetu j. V tomto pfipadë mohou bÿt oktety z rûznÿch front. Podobnë, pokud bitovâ metrika oktetu i je vëtsi nez metrika jiného oktetu j, pak by mêla bÿt metrika vklâdâni bitû oktetu i nastavena vëtsi nebo rovna metrice oktetu j, tj.:
BitovâMetrika[i]
BitovâMetrika[j]
MetrikaVklâdâniBitu[i] k MetrikaVklâdâniBitu[j]
MetrikaVklâdâniBitu[i]
MetrikaVklâdâniBitu[j]
BitovâMetrika[i] k BitovâMetrika[j]
Toto obecné pravidlo zajist’uje, ze oktet ulozenÿ do stejné kandidâtské instance prenosu pfispivâ k metrice
89723 (0989723_CZ.doc) 16.12.2006 paketu alespon stejnou mërou jako jinÿ oktet, kterÿ byl ulozen pozdëji.
Vsechny zde popsané metriky, stejnë jako alternativni metriky, mohou bÿt reprezentovâny v nâsledujici forme polynomu:
Metrika = [MCO]+[MCI]x+[MC2]x2 + [MC3]x3 + [MC4]x4 +
[MC5]x5 + [MC6]x6 + [MC7]x7 kde Metrika mûze bÿt kterÿmkoliv typem metriky a MCO,..., MC7 predstavuji koeficienty metriky. Secteni dvou metrik a nâsobeni (dëleni) metriky skalârem jsou definovâny jako v polynomiâlni algèbre, kde se pri scitâni dvou metrik sectou odpovidajici koeficienty jejich dvou polynomû. Kdyz se metrika nâsobi (nebo dëli) skalârem, kazdÿ z jejich koeficientû se nâsobi (nebo dëli) stejnÿm skalârem. To umozhuje vÿpocet metriky paketû za pouziti bitové metriky vypoctené tak, jak je definovanâ vÿse.
Operâtory porovnâni „>,>=,==,<=,< jsou definovâny v lexikâlnim smyslu, t j . kdyz se porovnâvaji dvë metriky, porovnaji se nejprve koeficienty u clenù nejvyssiho râdu. Pokud jsou stejné, pak se porovnaji koeficienty clenù nejblizsiho nizsiho râdu atd. Dvë metriky jsou stejné, pokud jsou stejné vsechny odpovidajici koeficienty dvou polynomiâlnich reprezentaci. Operace porovnâni se pouzivaji pro porovnâni metrik vklâdâni bitû, stejnë jako pro porovnâni metrik paketû.
Bitové metriky, Metriky vklâdâni bitû a metriky paketû
Pro bitové metriky a metriky vklâdâni paketû je v danÿ
89723 (0989723_CZ.doc) 16.12.2006 okamzik pouze jeden clen odpovidajici polynomiâlni reprezentace nenulovÿ. Râd nenulového clenu je stejnÿ pro bitovou metriku a metriku vklâdâni bitù daného oktetu. Râd tohoto nenulového clenu, kterÿ se obvykle oznacuje odpovidajicim nâzvem koeficientu. MCO, ..., MC7 se nazÿvaji prioritni stav metriky (vklâdâni) bitù (nebo odpovidajiciho otketu). Definice operace porovnâni ukazuje, ze clen MCO odpovidâ oktetûm s nejnizsi prioritou a clen MC7 odpovidâ oktetûm s nejvyssi prioritou. Stav priority metriky (vklâdâni) bitu pro oktet i je urcen aktuâlnim zpozdënim zpûsobenÿm oktetem, které je dâno jako:
AktuâlnîZpozdënî[i]=AktuâlnîCas - CasovâZnâmka[i] a pouzitim usporâdané mnoziny prahû znâmé jako „prahy priorit definované pro tok, kterému oktet prislusi. CasovâZnâmka[i] je vhodnë definovanâ casovâ znâmka pro oktet i. Kazdÿ interval definovanÿ prahem priority se namapuje na stav priority. Prahy priority a jejich mapovâni jimi definovanÿch intervalûm na prioritni stavy mûze bÿt pro kazdÿ tok specifikovâno plânovacem oddëlenë. AktuâlnîZpozdënî[i] oktetu se porovnâ s tëmito uspofâdanÿmi mnozinami, aby se urcil interval, do kterého spadâ. To na oplâtku definuje prioritni stav metriky (vklâdâni) bitù.
Vÿse uvedenâ operace pouzivâ M prioritnich prahû a M+l prioritnich stavû pro kazdÿ tok. Hodnota M je nastavena na 2 v provedeni, které je softwarovou implementaci plânovace. Pro kazdÿ tok jsou definovâny dva prioritni prahy a tri prioritni stavy. Tyto prioritni prahy a prioritni stavy mohou v prûbëhu existence toku typicky zûstat nezmënëny, ackoliv se mohou za provozu zmënit pfislusnÿm pfikazem DSPdriveru.
89723 (0989723_CZ.doc) 16.12.2006
Pro toky trafficu citlivé na propustnost se bitova metrika nastavi na:
GoSFaktor Thrghpt'TDelayConwFaktorBM max(r, AvgThroughput - TargetThroughput) a metrika vkladâni bitû je nastavena na:
_ GoSFaktor ThrghptlDelayConwFaktorBSM Λ. kJ max(i, AvgThroughput - TargetThrougphut) kde :
1. GoSFaktor je parametr toku, kterÿ se pouzivâ k zajistëni rûznÿch ûrovni sluzeb v tocich.
2. AvgThroughput je filtrovanâ (prûmërovanâ) celkovâ propustnost toku zahrnujici FTx, RTx a DARQ fronty toku. Pro prûmërovâni se pouzije filtr s nekonecnou impulsni odezvou (HR) prvniho râdu s casovou konstantou napf. 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. ε pfedstavuje velmi malé kladné cislo.
89723 (0989723_CZ.doc) 16.12.2006
- 67 Pro metriku vklâdâni bitû tokû citlivÿch na zpozdëni se nastavi nâsledujici polynomiâlni koeficient prioritniho stavu:
DSbsm = AccelerationFaktor*AktuàlnîZpozdëni +
Accelerationoffset kde AccelerationFactor je parametr definovanÿ pro tok. AccelerationFactor normalizuje HraniciZpozdëni, kterâ mûze bÿt pro rûzné toky rûznâ. Jak pfiklad uved’me dvë rûzné online hry. Kvûli odlisnÿm vlastnostem tëchto dvou aplikaci mohou mit tyto aplikace rûznâ nastaveni HraniceZpozdëni v plânovaci, ovsem jedna hra nemâ nezbytnë vyssi prioritu nez jinâ aplikace. Pro plânovac mûze bÿt zâdouci odbavit aplikace se stejnou prioritou. Pfedpoklâdejme, ze prvni hra mâ hranici zpozdëni 300 ms a druhâ hra mâ 150 ms. Potom v kterémkoliv okamziku nebudou existovat zâdné oktety pfislusejici druhé hfe starsi, nez 150 ms, protoze je plânovac zahodi. Bez AkceleracnihoFaktoru by to vedlo k posileni priority oktetû prvni hry nad oktety druhé hry. Nastavenim AkceleracnihoFaktoru kazdé aplikace nepfimo ûmërnë pfislusnému nastaveni HraniceZpozdëni mûze plânovac tento nezâdouci efekt normalizovat.
Accelerationoffset je parametr definovanÿ pro tok. Hodnota AccelerationOffsetu mûze bÿt hodnota nastavenâ na celociselnÿ nâsobek nejvëtsi hodnoty, kterou mûze mit AccelerationFactor. Tato nejvëtsi hodnota je nezâvislâ na tocich a mûze bÿt urcena softwarovou implementaci. Jako pfiklad mezi dvëma toky, jednim s AccelerationOffsetem nastavenÿm na nulu a druhÿm s kladnÿm AccelerationOffsetem budou oktety druhého toku obsazenÿ v kterékoliv kandidâtské instanci pfenosu pfed kterÿmikoliv toky bÿvalého toku, za
89723 (0989723_CZ.doc) 16.12.2006 predpokladu, ze oba toky jsou DRC kompatibilni s prenosovÿm formâtem dané kandidâtské instance.
Pro bitovou metriku je koeficient polynomu pro prioritni stav nastaven na konstantni hodnotu nâsledujicim zpûsobem:
DSbm = DSBitMetricValue kde DSBitMetricValue je parametr definovanÿ pro tok, kterÿ se pouzivâ pro mëkké sefazeni podle priorit. Navic kdyz dvë aplikace maji pfibliznë stejnou prioritu, ale rùzné prûmërné vstupni propustnosti (napf. z Internetu do fronty), mûze bÿt DSBitMetricValue pro kazdÿ tok nastavena inverznë vzhledem k typické propustnosti toku, tak aby se aplikaci s vyssi propustnosti zabrânilo v ûplném ziskâni priority tim, ze ma vice dat k efektivnimu plnëni FL paketû.
Kazdÿ tok trafficu se klasifikuje do na propustnost citlivÿch trid nebo tfid citlivÿch na zpozdënî na zâkladë parametru tfidy toku. Potom se bitovâ metrika MCX (kde X je prvek {0,...,7}) definuje nâsledovnë:
MCX = <
TSBM,
DSBM ’ pokud je TridaToku CitlivdNaVykon pokud je TridaToku CitlivâNaZpozdéni
Podobnë je metrika vklâdâni bitû definovâna jako:
MCXTSBSM ,pokud je TridaToku CitlivdNaVykon DSBSM, pokud je TridaToku CitlivâNaZpozdéni
N jednom provedeni je plânovac implementovân alespon câstecnë softwarovë. Podle tohoto provedeni jsou metriky
89723 (0989723_CZ.doc) 16.12.2006 vklâdâni bitù reprezentovâny 16 bitovÿmi hodnotami, které mohou bÿt oznaceny jako [B15 ... BO] . Tri nejvÿznamnëjsi bity urcuji prioritni stav (napr. „000 se mapuje na MCO a „111 se mapuje na MC7). Zbÿvajicich 13 nejménë vÿznamnÿch bitù uchovâvâ vlastni hodnotu koeficientu. S touto reprezentaci se operace porovnâni dvou metrik vklâdâni bitù mohou provâdët primo mezi tëmito 16-bitovÿmi hodnotami.
Bitové metriky nejsou explicitnë reprezentovâny v softwarové implementaci, protoze tyto informace Ize odvodit od metriky vklâdâni bitù.
Metrika vklâdâni bitù kandidâtské instance pfenosu se vypocte pouzitim:
MetrikaPaketu[k\ = rozpéti[k]
BitovàMetrika\i\ ,ep[*] jak je popsâno vÿse. Vsimnëte si, ze nejenom jeden vÿraz bitové metriky oktetu mùze bÿt nenulovÿ, ale obecnë koeficienty vÿsledné paketové metriky mohou bÿt nenulové.
Mnoho DRCs je kompatibilnich s nekanonickÿmi jednouzivatelskÿmi formâty s mensimi zâtëzemi, a tudiz neni zâdouci prevâdët pro dosazeni ARQ zesileni jednouzivatelské kandidâty na viceuzivatelské formâty.
Pokud je vitëznâ kandidâtskâ instance pfenosu v kroku vÿbëru plânovace viceuzivatelskÿm formâtem, jsou v tomto provedeni podporovâny pouze konverze (1024,4,256) formâtû do kteréhokoliv ze tfi formâtû ({128,256, 512), 4,256) (tj . pouzije se formât s nejnizsi rychlosti, kterÿ mùze pfenâset vybranâ data) .
89723 (0989723_CZ.doc) 16.12.2006
- 70 Vÿse uvedenÿ popis bitové metriky a metriky vklâdâni bitù uvazuje obecnë pripad, kde oktety v kazdé frontë jsou prirazeny vlastni metrice. Metrika se potom vypocte v kazdém slotu znovu. Altemativni provedeni snizuji slozitost takovÿch vÿpoctû. Pfedpoklâdejme, ze fronty jsou serazeny podle casové znâmky, jedno provedeni vypocte jednu metriku (vklâdâni) bitu pro danÿ tok na zâkladë nejstarsi casové znâmky mezi hlavickami oktetû ve frontâch toku. Tato metrika se potom mûze pouzit pro pakety, které momentâlnë cekaji ve frontë. Takové zjednoduseni predpoklâdâ, ze metrika je monotônnë rostouci funkce AktuâlnihoZpozdëni oktetu. Jinak je zde riziko, ze oktet hlavicky fronty mûze zabrânit obslouzeni dalsich oktetû. S timto zjednodusenim Ize metriku vklâdâni bitû oznacovat také jako metriku toku.
Navic, kterÿkoliv oktet hlavicky fronty cekajici v RTx frontë je pravdëpodobnë starsi, nez kterékoliv oktety hlavicky fronty cekajici v FTx a DARQ frontâch. Podobnë, kterÿkoliv oktet hlavicky fronty, kterÿ cekâ v DARQ frontë je pravdëpodobnë starsi nez oktet hlavicky fronty cekajici v FTx frontë. Z tohoto dûvodu pouzivâ jedno provedeni radëji nez hledâni nejstarsi casové znâmky mezi tëmito tfemi frontami pevné pofadi RTx, DARW a potom FTx front, aby se nalezla prvni neprâzdnâ fronta pro urceni casové znâmky, kterâ se pouzije pri vÿpoctu metriky toku. Tyto fronty toku mohou bÿt obslouzeny také v pofadi RTx, DARQ a potom FTx.
Podle jednoho provedeni se plânovâni tak, jak je zobrazeno na obr. 10 provede kdykoliv je dostupnÿ novÿ FL pro pfenos. Vsimnëte si, ze specifické implementace mohou provâdët nëkteré vÿpocty v kazdém slotu, vcetnë nedostupnÿch slotû. To je proto, ze v case, kdy pristupovâ sit zjisti, ze
89723 (0989723_CZ.doc) 16.12.2006
- 71 je volnÿ FL pro novÿ pfenos, nezbÿvâ obvykle mnoho casu k provedeni vÿpoctû zahrnutÿch ve zpûsobu plânovâni, aby se urcila instance pfenosu.
Zpûsob plânovâni znâzornënÿ na obr. 10 se sklâdâ se ctyf zâkladnich krokù: 1) vygenerovâni sady kandidâtskÿch instanci pfenosu; 2) vÿbëru jednoho kandidâta z mnoziny; 3) maximalizace efektivity paketovâni; a 4) apriorni nebo PACK vÿpocet. Vÿpocet PACK urci pravdëpodobnost, ze AT ùspësnë dekôdoval paket.
Opët s odkazem na obr. 10, generuje plânovac v kroku 504 seznam kandidâtskÿch instanci pfenosu. Kandidâtskâ jednouzivatelskâ instance pfenosu s jednouzivatelskÿm formâtem odpovidajicim kazdému dostupnému uzivateli, kde dostupnÿ uzivatel aktuâlnë nemâ z jakéhokoliv dùvodu odepreny sluzby subtypu protokolu. Navic, pfijaté DRC od uzivatele musi bÿt nenulové, jinak uzivatel vyjednâ protokol MAC vrstvy umozhujici obslouzeni jednoho nebo vice pfenosovÿch formâtù do nulového DRC. Pokud se kandidâtskâ instance pfenosu vytvofi pro uzivatele, od kterého byla pfijata NULL DRC, umozni se kandidâtské instanci pfenosu pfenâset pouze data, kterâ patfi k toku s konecnou hranici zpozdëni a pouze z FTx fronty toku. Pfenosovÿ formât kandidâtské instance pfenosu je kanonickÿ formât odpovidajici uzivatelskému DRC, jak je zobrazeno v tabuice 1.
Kandidâtskâ viceuzivatelskâ instance pfenosu se vygeneruje pro kazdÿ z pëti viceuzivatelskÿch pfenosovÿch formâtù: (1024,4,256),(2048,4,128),(3072,2,64),(4096,2,64) a (5120,2,64). Uzivatelé, ktefi pozadovali rychlost 153,6 Kbps nebo vyssi, jsou obslouzeni ve viceuzivatelskÿch formâtech.
89723 (0989723_CZ.doc) 16.12.2006
Navic, DRC uzivatele musi bÿt kompatibilni s formâtem kandidâtské instance prenosu. Navic, viceuzivatelskâ kandidâtskâ instance prenosu bude splhovat jednu nebo obë nâsledujici podminky, jinak bude z dalsiho uvazovâni vyloucena; bude nést data dvou nebo vice uzivatelù a data alespon jednoho uzivatele, jehoz DRC byla vymazâna.
Kandidâtskâ instance prenosu ve kterékoliv skupinë se vygeneruje vyrovnânim bitû z jednoho nebo vice tokù, kde: 1) jednouzivatelské formâty mohou bÿt vyrovnâny pouze bity ze stejnÿch uzivatelskÿch tokù; 2) viceuzivatelské formâty mohou bÿt vyrovnâny bity z tokù uzivatelù s kompatibilnimi DRCs.
Vyrovnâni bitû se provede v sestupném pofadi bitové vyrovnâvaci metriky. Jak bylo zminëno vÿse, vÿpocetni nâroky mohou vést k vÿpoctu jedné bitové vyrovnâvaci metriky na tok, kterâ se potom pouzije pro aktuâlnë cekajici oktety ve frontâch toku. V tomto pfipadë bitovâ vyrovnâvaci metrika pomâhâ urcit, které toky budou obslouzeny jako prvni; neurci ovsem, jak budou oktety daného toku obslouzeny. To pfedpoklâdâ, ze se oktety cekajici ve frontâch toku objevuji v poradi podle casovÿch znâmek a oktety toku jsou obsluhovâny v poradi, ve kterém se objevuji ve frontâch. To se pouzivâ pro FTx fronty, ale ne nezbytnë pro RTx/DARQ fronty.
Jak bylo uvedeno vÿse, mûze mit kazdÿ tok vice front, jedna fronta pro data pfenâsenâ poprvé (FTx) a dalsi fronty pro opakované pfenosy (RTx fronta pro RLP opakované pfenosy a/nebo DARQ fronta pro opakované pfenosy MAC vrstvy). Pokud mâ tok neprâzdné RTx a/nebo DARQ fronty, vypocte se bitovâ vyrovnâvaci metrika pro tok na zâkladë nejstarsi casové
89723 (0989723_CZ.doc) 16.12.2006 znâmky z neprâzdnÿch FTx/RTx/DARQ front.
Razeni front na zâkladë casovÿch znâmek Ize aproximovat jako pevné pofadi RTx/DARQ/FTx front.
Vsimnëte si, ze se neuvazuje generovâni kandidâtskÿch instanci pfenosu, nekanonickÿch jednouzivatelskÿch formâtu a krâtkÿch viceuzivatelskÿch formâtu, které nesou ménë nez 1024 bitû. Tyto formâty se budou uvazovat v kroku maximalizace efektivity paketovâni. Tento zpûsob plânovâni hledâ maximâlni snizeni slozitosti a snazi se do paketu vlozit co nejvice dat.
Aby se pfedeslo situaci, kdy uzivatel mâ spatnÿ stav kanâlu ale velké mnozstvi dat k pfenosu, ziskâ relativni prioritu efektivnim plnënim krâtkÿch paketù. Jinÿm pfinosem neuvazovâni nekanonickÿch a krâtkÿch paketù v tomto stavu je mimo jiné zabrânëni jistÿm kvantizacnim efektùm, které mohou vzniknout v plânovâni na zâkladë râmcù.
Pfi vytvâfeni viceuzivatelskÿch kandidâtû je mozné pfijmout dalsi pozadavky, aby se zmirnily potenciâlni vedlejsi ùcinky dâle popsaného problému pokracovâni. Jednim takovÿm zpûsobem je zabrânit obslouzeni viceuzivatelskÿch paketù na stejném prolozeni s drive zapocatÿmi a ukoncenÿmi viceuzivatelskÿmi pakety pro urcitÿ pocet slotù (napf. spocitanÿch na daném prolozeni) nâsledujicim start prvniho viceuzivatelského paketu. Pocet slotù Ize nastavit na minimum rozpëti dvou viceuzivatelskÿch paketù nebo pokud mozno rozpëti prvniho viceuzivatelského paketu. Tento pfistup pomâhâ umoznit uzivatelùm dostat rychle oprâvnëni k obslouzeni v novém viceuzivatelském paketu, cimz se zabrâni dlouhé nezpûsobilosti.
89723 (0989723_CZ.doc) 16.12.2006
S odkazem na krok 508 po vytvofeni seznamu jednouzivatelskÿch a viceuzivatelskÿch kandidâtskÿch instanci pfenosu vybere plânovac jednoho z tëchto kandidâtû (za pfedpokladu, ze vÿse vygenerovanÿ seznam obsahuje alespon jednu kandidâtskou instanci pfenosu). To se provede vypoctenim paketové metriky pro kazdého kandidâta v seznamu a vybrânim kandidâta s nejvëtsi paketovou metrikou jako vitëzného kandidâta. Pokud se vyskytnou vazby, je vhodné upfednostnovat jednouzivatelské formâty pfed viceuzivatelskÿmi formâty. Také je vhodné upfednostnovat vysokorychlostni viceuzivatelské formâty pfed nizkorychlostnimi viceuzivatelskÿmi formâty.
V kroku 510 se znovu prosetfi pfenosovÿ formât vitëzné kandidâtské instance pfenosu a mûze se zmënit, aby se maximalizovala jeho paketovaci ûcinnost, aniz by se zmënila sada datovÿch oktetû, které mâ pfenâset. Dokonceni kroku 510 proto mûze zajistit ARQ zesileni.
Pokud je vitëznâ kandidâtskâ instance pfenosu jednouzivatelskÿ formât, pak se formât mûze konvertovat na nekanonickÿ jednouzivatelskÿ formât s nejnizsi rychlosti, kterÿ je kompatibilni s obsluhovanou DRC uzivatele, kterâ mûze nést vybrané datové oktety. Jinâ provedeni mohou také zmënit formât jednouzivatelské instance pfenosu na viceuzivatelskÿ formât.
Mechanismus adaptivniho fizeni rychlosti pfenosu v AT je nâchylnÿ k adaptaci jednouzivatelskÿch paketù. Mnoho DRC je kompatibilnich s nekanonickÿmi jednouzivatelskÿmi formâty s mensimi zâtëzemi, a proto neni zâdouci pfevâdët jednouzivatelské kandidâty na viceuzivatelské formâty, aby
89723 (0989723_CZ.doc) 16.12.2006 se dosâhlo ARQ zesileni.
Ackoliv lze viceuzivatelské formâty konvertovat na kterékoliv viceuzivatelské formâty s nizsi rychlosti prenosu (dokud staci zâtëz), je vhodné vyvarovat se obecnë rozsifenÿch koverzi formâtu kvûli potenciâlnim nepfiznivÿm ùcinkûm nize popsaného problému pokracovâni.
S odkazem na obr. 12 mùze plânovac urcit maximâlni pocet slotû (tj. ménë nez nominâlni rozpëti vybrané instance prenosu) pfi jehoz pfekroceni nepfenese instanci pfenosu i kdyz nemusi detekovat ACKs od uzivatelù obslouzenÿch touto instanci prenosu. Protoze je tento krok volitelnÿ, lze jej vynechat, takze pfistupovâ sit ukonci vysilâni paketû poté, co detekuje ACK od uzivatelù obslouzenÿch v tomto paketu, nebo po pfeneseni plného rozpëti tohoto paketu.
Jednim zpùsobem implementace tohoto kroku je nastavit maximâlni pocet slotû instance pfenosu na:
MaxRozpëti=min (RozpëtiPlânTxFormâtu ,maxieObslouSenluiivatelé (DRCRozpëti [i] ) )
Kde RozpëtiPlânTxFormâtu je rozpëti plânovâno pfenosového formâtu a DRCRozpëti[i] je rozpëti kanonického pfenosového formâtu odpovidajici dekôdovanému DRC od i-tého obslouzeného uzivatele v paketu.
Vÿse bylo popsâno nëkolik parametrû vyuzivanÿch plânovacem. Zde jsou prezentovâny parametry poskytnuté plânovaci na rozhrani DSP-driveru. Globâlni parametry se na tyto parametry, které se tÿkaji vsech tokù, odkazuji a parametry tokù se na tyto parametry odkazuji pro kazdÿ tok zvlâst’ :
89723 (0989723_CZ.doc) 16.12.2006
1. Globâlni parametry:
a. Casovâ konstanta toku filtru propustnosti (FlowTPutFilterTimeConstant) - definuje casovou konstantu IIR filtru prvniho râdu pouzivanou ke generovân! prûmërné propustnosti, AvgThroughput, promënné, kterâ se uchovâvâ pro kazdÿ tok. Tento filtr se iteruje v kazdém slotu. Vstupem do filtru je pocet oktetù obslouzenÿch z front daného toku v paketù, kterÿ zacinâ v tomto slotu. Filtr se aktualizuje nulovÿm vstupem ve slotech, ve kterÿch nezacinâ prenos zâdného nového paketù.
b. Thrghpt2DelayConvFactorBM - konverzni faktor metriky citlivé na propustnost na metriku citlivou na zpozdëni pro vÿpocet bitové metriky.
c. Thrghpt2DelayConvFactorBSM - konverzni faktor metriky citlivé na propustnost na metriku citlivou na zpozdëni pro vÿpocet bitové vyrovnâvaci metriky
d. FlowClass - popisuje zda je tok typ citlivÿ na propustnost nebo typ citlivÿ na zpozdëni.
e. FlowEligibleForDRCErasureMapping - pro pouziti v DRC algoritmu mazâni mapovâni.
f. ErasureMapDelayTreshold - pro pouziti v DRC algoritmu mazâni mapovâni.
2. Parametry toku
a. UserID, FlowID - poskytuji prostfedky pro indexaci a
89723 (0989723_CZ.doc) 16.12.2006
- 77 urceni vlastnika kazdého toku.
b. QoSMetricState, PriorityThold[2] - tyto parametry popisuji prioritni stav bitové (vyrovnâvaci) metriky jako funkci aktuâlniho zpozdëni. Prvky PriorityThold[] matice jsou struktury, které obsahuji promënné DelayThold a QoSMetricState. Kdyz je aktuâlni zpozdëni toku mens! nez PriorityThold[0].DelayThold, nastavi se prioritni stav na QoSMetricState. Pokud je aktuâlni zpozdëni vëtsi nez PriorityThold[0].DelayThold, ale vëtsi nez PriorityThold[1].DelayThold, pak se prioritni stav nastavi na PriorityThold[0].QoSMetricState. Pokud je aktuâlni zpozdëni vëtsi nez PriorityThold[1].DelayThold, potom se prioritni stav nastavi na PriorityThold[1].QoSMetricState. Promënné QoSMetricState nabÿvaji hodnot {0,...,7} podle odpovidajicich prioritnich stavu {MCO,... MC7}.
c. AccelerationFactor
d. Accelerationoffset
e. DelayBound - 0 pfedstavuje nekonecno (tj. nikdy nezahazuj oktet pfedtim, nez jej obslouzis): jinak pfedstavuje zpozdëni vzhledem casové znâmce daného oktetu, po kterém se oktet vyhodi z fronty.
f. TargetThroughput - parametr pouzivanÿ bitovou (vyrovnâvaci) metrikou tokù citlivÿch na propustnost;
g. FlowAggregatelndex - toky s FlowAggregatelndexem nastavenÿm na 0 nejsou plânovacem agregovâny. Jinak jsou toky se stejnou (nenulovou) hodnotou FlowAgreggatelndexu plânovacem agregovâny. Rozsah FlowAgreggatelndexu je omezen
89723 (0989723_CZ.doc) 16.12.2006
- 78 na uzivatele, tj . stejnÿ index Ize pouzit pro toky jiného uzivatele, aniz by doslo k zâmënë.
g. IntraFlowPriority - pfispivajici toky v agregovaném toku (plânovacem) jsou obslouzeny podle poradi IntraFlowPriority. u prispivajicich toku se stejnou IntraFlowPriority se poradi urci podle casové znâmky prispivajicich toku.
i. GoSFactor - pouzivâ se k ohodnoceni ùrovni kvality sluzby mezi toky.
j . DSBitMetricValue - hodnota koeficientu bitové metriky v prioritnich stavech MCX.
Vsimnëte si, ze na inteface DSP-driveru nejsou toky specif ikovâny jako BE, AF, EF nebo jakÿmkoliv jinÿm deskriptorem vyssi ûrovnë. Rozhrani DSP-driveru radëji pouzivâ jednotnÿ a nizkoûrovnovÿ popis pro vsechny toky. Na vyssi ùrovni, jako je napriklad BSC, se specifické vysokoûrovnové deskriptory tokù, jako napriklad QoS pozadavky a BE/EF/AF kategorizace mapuji na zâkladni parametry definované v rozhrani DSP-driveru pro kazdÿ tok. Takové mapovaci tabulky se generuji pro mozné typy toku dostatecnou simulaci a testovânim.
Nâsledujici pfiklady ilustruji pouziti rûznÿch parametrû. Pro BE toky Ize pouzit nâsledujici parametry:
a. QoSMetricState = 0 (MCO)
b. PriorityThold[].QoSMetricState = {jakÿkoliv, jakÿkoliv}
c. PriorityThold[].DelayThold = {0,0} (nekocnecno)
d. DelayBound = 0 (Nekonecno)
89723 (0989723_CZ.doc) 16.12.2006
e. TargetThroughput = 0.
f. FlowAggregatelndex = 1 (agreguj vsechny BE toky uzivatele)
g. Thrghpt2DelayConvFactorBM = 16.
h. Thrghpt2DelayConvFactorBSM = 128.
i. FlowClass = ThrputSensitive.
j. FlowEligibleForDRCErasureMapping = 0.
k. ErasureMapDelayTreshold = 0 {nekonecno}
Pro AF toky Ize pouzit nâsledujici parametry:
a. QoSMetricState = 0 (MCO)
b. PriorityThold[].QoSMetricState = {jakÿkoliv, j akykoliv}
c. PriorityThold[].DelayThold = {0,0} (nekocnecno)
d. DelayBound = 0 (Nekonecno)
e. TargetThroughput = kladnâ hodnota.
f. FlowAggregatelndex = 0 (zâdnâ agregace)
g. Thrghpt2DelayConvFactorBM = 16.
h. Thrghpt2DelayConvFactorBSM = 128.
i. FlowClass = ThrputSensitive.
j. FlowEligibleForDRCErasureMapping = 0.
k. ErasureMapDelayTreshold = 0 {nekonecno}
Pro EF toky Ize pouzit nâsledujici 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 (zâdnâ agregace)
g. Thrghpt2DelayConvFactorBM = 1.
h. Thrghpt2DelayConvFactorBSM = 1.
89723 (0989723_CZ.doc) 16.12.2006
i. FlowClass = DelaySensitive.
j. FlowEligibleForDRCErasureMapping = 1.
k. ErasureMapDelayTreshold = 0,25*DelayBound
Signâlni tok je poskytnut nâsledovnë:
a. QoSMetricState = 7 (MC7, nejvyssi priorita)
b. PriorityThold[].QoSMetricState = {7,7}
c. PriorityThold[].DelayThold = {0,0} (nekocnecno)
d. DelayBound = 0 (Nekonecno)
e. TargetThroughput = 0.
f. FlowAggregatelndex = 0 (zâ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 upfednostnovâny pouzitim vhodné kombinace nâsledujicich parametrù:
1. MC0,...,MC7 stavy umozhuji striktni uprednostnovâni.
2. GoSFactor pro mëkké uprednostnovâni
3. TargetThroughput typicky pro AF toky, které vyzaduji nëjakou minimâlni propustnost.
EF toky mohou bÿt dâle upfednostnovâny pouzitim vhodné kombinace nâsleduj icich parametria:
1. MC0,...,MC7 stavy umozhuji striktni upfednosthovâni.
2. Accelerationoffset umozhuje upfednosthovâni bëhem bitového vyrovnâvâni mezi oktety stejného prioritniho stavu, ale neovlivhuje pfimo vÿslednÿ vÿbër paketu (protoze tento druhÿ krok pouzivâ bitovou metriku k vÿpoctu paketové metriky, kterâ nezâvisi na AccelerationOffsetu). Kdyz dva toky patfici ke stejnému uzivateli nebo dvëma rùznÿm
89723 (0989723_CZ.doc) 16.12.2006 uzivatelûm soutëzi o zafazeni do stejné kandidâtské instance pfenosu, ziskâ prioritu tok s vëtsim AccelerationOffsetem.
3. DSBitMetricValue ovlivnuje bitové metriky, takze ma i pfimÿ ûcinek na paketovou metriku. Tento parametr Ize také pouzit pro mëkké upfednostnovâni. Nyni tento parametr neni implementovân.
Rozhrani DSP-Driveru poskytuje flexibilni zpûsob agregace tokû v plânovaci. Vsimnëte si, ze agregace provâdëné plânovacem jsou odlisné od agregaci, které Ize provâdët BSC. Kdyz BSC agreguje sadu tokû, tyto agregâty se plânovaci jevi jako jedinÿ tok a plânovac pro tento tok pfijme jedinou sadu parametrû. Plânovac nemûze pfistupovat k pfispivajicim tokûm jednotlivë. Pokud agregace probëhne v plânovaci, bude plânovac pfispivajici toky pfirozenë znât.
Promënnâ AvgThroughput zahrnuje celkovou propustnost agregâtu. Urcité parametry, jako napfiklad DelayBound, specifikované pro pfispivajici toky agregâtu, jsou nastaveny na stejnou hodnotu na rozhrani DSP-driveru. Seznam promënnÿch, které se nastavi na stejnou hodnotu pro vsechny pfispivajici toky je:
a. UserID
b. Aggregateindex c. QoSMetricState d. PriorityThold[2] e. AccelerationFactor f. Accelerationoffset g. DelayBound
h. TargetThroughput i. GoSFactor
j. DSBitMetricValue
89723 (0989723_CZ.doc) 16.12.2006
Parametr, kterÿ mûze bÿt nastaven rûznë, je IntraFlowPriority a parametr, kterÿ musi bÿt nastaven rûznë je FlowID.
V jednom provedeni se agregovanému toku pfifadi jednobitovâ (vyrovnâvaci) metrika. Tato metrika je zalozena na nejstarsi casové znâmce mezi pfispivajicimi toky agregovaného toku. Casovâ znâmka prispivajiciho toku se vypocte na zâkladë casovÿch znâmek hlavicek fronty jeho FTx/RTx/DARQ front. Kdyz se vybere tok pro bitové vyrovnâni, ovsem pofadi, ve kterém se toky obsluhuji se urci primârnë parametry IntraFlowPriority pfifazenÿmi ke kazdému z pfispivajicich tokû a sekundârnë podle casovÿch znâmek pfispivajicich tokû. Parametr IntraFlowPriority je nejcastëji zamÿslen pro BE toky.
Jak bylo popsâno vÿse, kazdÿ tok mâ FTx frontu a mûze mit RTx a/nebo DARQ fronty. V softwarové implementaci se pro kazdÿ tok vypocte jedna bitovâ vyrovnâvaci 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â obslouzit, obslouzi se také jednotlivé fronty v urceném pofadi.
Jedno softwarové provedeni poskytuje schopnost zvÿsit prioritu toku, pokud jsou RTx a/nebo DARQ fronty neprâzdné. To je doprovâzeno jednoduchou modifikaci hodnoty MetricTS dané v rovnici (3.3 - 2) jako:
,, . GoSFactor * Retransmission Prior ityFactor
Metric^ =--------------------------------------max(f, AvgThroughput - TargetThroughput)
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 jestë jiné hodnoty nabÿvâ, pokud je RTx fronta neprâzdnâ.
V revizi A lxEV-DO specifikace urcité subtypy protokolu definuji nulové DRC kompatibilni se sadou jednouzivatelskÿch a viceuzivatelskÿch pfenosovÿch formâtu. Také v Rel-0 specifikace jsou konfiguracni atributy definovâny pro urcité subtypy protokolu, které umoznuji pfistupové siti obsluhovat uzivatele, od kterého byla pfijata nulovâ hodnota DRC s (1024,16,1024) jednouzivatelskÿm pfenosovÿm formâtem.
V obou pfipadech mûze plânovac vytvofit kandidâtskou instanci pfenosu obsahujici data pro uzivatele, od kterého byla prijata hodnota NULL DRC. Ta se oznacuje jako NULL-toRate konverze. Plânovac klade na NULL-to-Rate konverze nâsledujici omezeni:
a. Je povoleno obsluhovat toky s konecnou hranici zpozdëni
b. RTx/DARQ fronty nemohou bÿt obslouzeny.
Jinâ, nez tato omezeni plânovac nerozlisuje, zda pfijaté DRC od uzivatele byla 0x0 (tj . NULL DRC) nebo 0x1 (tj . 38,4 Kbps), pficemz obë jsou definovâny jako kompatibilni se stejnÿmi pfenosovÿmi formâty v urcitÿch subtypech protokolû v Rev-A. Pro definice konkrétnich subtypû protokolu opët odkâzeme na tabulku 1.
Kdyz je od uzivatele pfijato NULL DRC, neni zâruka, ze obslouzenÿ paket bude uzivatelem ûspësnë dekôdovân. Budouci zlepseni mûze skutecnë zahrnovat monitorovâni, zda uzivatelé, ktefi poslali NULL DRC, a kteri potom byli
89723 (0989723_CZ.doc) 16.12.2006 obslouzeni v paketu jsou skutecnë rozumnë ûspësni pfi dekôdovâni. V zâvislosti na statistice ûspësnosti mûze bÿt konverze pro tok vypnuta nebo zapnuta. Jedno provedeni hodnoti kandidâtské instance prenosu vytvofené pro uzivatele, ktefi vyslali NULL DRC hûfe, nez kandidâtské instance prenosu vytvofené pro uzivatele, ktefi vyslali DRC 0x1.
Lze provést urcité rozumné aproximace v softwarové imlementaci, aby se usnadnilo vytvofeni kandidâtskÿch viceuzivatelskÿch instanci, které obsahuji data pro toky citlivé na propustnost.
Vzhledem k casovâni plânovace je casové plânovâni ve slotu rozdëleno do dvou câsti; prvni câst je nekritickÿ segment a druhâ câst je kritickÿ segment. DRC hodnoty uzivatelû jsou zpfistupnëny v prûbëhu kritického segmentu. Ovsem kritickÿ segment nemusi poskytovat dostatek cyklû procesoru k provedeni vÿpoctû zahrnutÿch v plânovaci v nejhorsim pfipadë zatizeni. Proto jsou nëkteré z tëchto vÿpoctû provâdëny v nekritickém segmentu. Protoze DRC hodnoty nëkterÿch uzivatelû nemusi bÿt v nekritickém segmentu znâmy, pouzije softwarovâ implementace k vytvofeni kandidâtskÿch instanci pfenosu a vÿbëru vitëzného kandidâta DRC hodnoty pfedchoziho slotu. Je mozné, ze se DRC hodnoty nëkterÿch uzivatelû mohou zmënit a ze vitëznÿ kandidât mûze pfestât bÿt v prûbëhu kritického segmentu platnÿ. Aby se tento problém pfekonal, vybere se v nekritickém segmentu vice nez jeden silnÿ kandidât. Kdyz jsou v kritickém segmentu pfijaty aktuâlni DRC hodnoty, vyhodnoti se omezenâ sada kandidâtù znovu. Omezenâ sada kandidâtù mûze obsahovat:
a. Malé mnozstvi (napf. pët) jednouzivatelskÿch
89723 (0989723_CZ.doc) 16.12.2006 kandidâtù.
b. Jednoho viceuzivatelského kandidâta (pokud byl nëjakÿ vytvofen) s nëkolika zâloznimi uzivateli, ktefi mohou bÿt v tomto kandidâtovi obslouzeni, pokud se nëkterÿ z uzivatelù obslouzenÿch v kandidâtovi stane nekompatibilnim.
V lxEV-DO Rel. 0 AN neplânuje pakety na AT, kdyz je DRC informace vymazâna. Kdyz AN obsluhuje vice AT s aplikacemi, které nejsou citlivé na zpozdëni, napf. traffic s nejlepsim ùsilim, Ize tolerovat relativnë vysoké DRC rychlosti zpozdëni (napf. kvûli viceuzivatelské diverzitë) bez ztrâty kapacity systému. Kdyz je DRC rychlost nepfimëfenë vysokâ, nastavi AN DRC zâmkovÿ bit na nulu a AT potom mûze zvolit pfehrâni na jinÿ sektor nebo pfepnuti do rezimu s pevnou rychlosti. Ovsem zpûsob generovâni DRC zâmkového bitu mâ zabudované zpozdëni, které je alespon câstecnë kvûli filtraci, aby se zabrânilo nadbytecnÿm pfehrânim. Proto se na zpëtném linku mohou stâle objevit relativnë dlouhé délky DRC vÿmazû. Pro aplikace citlivé na zpozdëni, napf. EF traffic, mohou tyto vÿmazy vést k nepfijatelnému objemu vÿpadkû sluzby. Algoritmus mapovâni DRC vÿmazu se snazi minimalizovat vÿpadky sluzby na FL.
Zâkladni algoritmus je popsân dvëma kroky. Prvni krok vysvëtluje rozhodovâni pfi mapovâni DRC vÿmazu. Druhÿ krok popisuje zmëny na FL plânovaci lxEV-DO revize A. Obr. 14 popisuje algoritmus mapovâni DRC vÿmazu, kterÿ bëzi na AN v kazdém casovém slotu pro kazdÿ AT, kterÿ je v rezimu promënné rychlosti. Pro kazdÿ AT bëzi algoritmus pro kazdÿ sektor bunky, kterÿ mâ aktivni frontu vytvofenou BSC pro tohoto uzivatele. Pro jednoduchost je algoritmus popsân tak, ze bëzi v intervalu kazdého slotu, ale parametry se
89723 (0989723_CZ.doc) 16.12.2006 aktualizuji pouze jednou za interval délky DRC.
Hlavni vÿstup algoritmu je Erasure_Mapped flag, kterÿ indikuje plânovaci, ze mapovâni DRC vÿmazu bylo provedeno a ze Ize provést omezené FL plânovâni na AT.
DRC_index_store se pouzije pro ulozeni posledniho platného, tj. uspësnë dekôdovaného DRC indexu. Eras_count se pouzije pro vÿpocet délky bëhu DRC vÿmazu. Mapovâni DRC vÿmazu se provede pouze, pokud je délka bëhu vÿmazu vëtsi naz Max_Ers_Len. Tento prâh zajistuje, ze se mapovâni DRC vÿmazu provede pouze kdyz je pravdëpodobnost vÿpadku sluzby relativnë vysokâ. Pakety mohou bÿt ovsem plânovâny AT kdyz je odpovidajici zpozdëni FL paketu velké. Max_Ers_Len tedy nemùze bÿt prilis vysokâ. Pro EF toky, napf. VoIP je rozumné nastaveni Max_Ers_Len v rozsahu 0 az 16 slotû.
Jak je zobrazeno na obr. 14, zpûsob 700 nejprve v rozhodovacim kroku 702 otestuje, jestli je DRC vymazâna. Pokud je DRC vymazâna, zvÿsi se v kroku 704 Eras Cnt. Eras_Cnt se potom v kroku 706 porovnâ s maximâlni hodnotou Max_Ers_Len. Pokud je Eras_Cnt vëtsi nez Max_Eras_Len, nastavi se Erasure_Mapped_flag na 1, jinak se Erasure_Mapped_flag vymaze, t j . nastavi se v kroku 712 na nulu. Pokud neni DRC v rozhodovacim kroku 702 vymazâna, nastavi se v kroku 708 Erasure_Mapped_flag na 0, Eras Cnt se nastavi na 0 a DRC_Index_Store se nastavi na DRC_Index. Zpracovâni pokracuje krokem 712, ve kterém se Erasure_Mapped_flag nastavi na 0.
FL plânovace popsané vÿse Ize modifikovat, aby pracovaly s algoritmem mapovâni DRC vÿmazu. Pro kazdÿ jednotlivÿ datovÿ tok kazdé AT je tok vhodnÿ pro omezené FL
89723 (0989723_CZ.doc) 16.12.2006 plânovâni, pokud:
(ErasureMappedFlag == 1 && FlowEligibleForDRCErasMapping == 1 &&
HeadofQueueDelay > ErasureMapDelayTreshold) kde FlowEligibleForDRCErasMapping je parametr, kterÿ indikuje vhodnost kazdého toku trafficu pro mapovâni DRC vÿmazu. Jako vÿchozi se pfedpoklâdâ, ze EF toky jsou vhodné pro mapovâni, zatimco BE a AF toky nejsou.
HeadofQueueDelay indikuje hodnotu „Current_Delay pro paket na zacâtku FL fronty (tj . nejstarsi paket v FTx, RTx nebo DARQ frontë). ErasureMapDelayTreshold je minimâlni pozadované zpozdëni pro konkrétni tok pro mapovâni vÿmazu (mâ podobnÿ efekt jako „PriorityThold[i].DelayHold. Pokud je tok vhodnÿ pro omezené FL plânovâni, provedou se na FL plânovaci nâsledujici ùpravy:
a. Tok neni vhodnÿ jako kandidât pro jednouzivatelskou instanci pfenosu
b. Tok je vhodnÿ pro viceuzivatelskou instanci pfenosu s vyzadovanÿm DRC indexera, DRC_index mapped
DRC_index_mapped Ize dymanicky mënit jako funkci délky vÿmazu. Toho Ize dosâhnout pouzitim DRC index store a Eras_C°unt. Vÿchozi nastaveni DRC_indexu Ize namapovat na 0x3. Pro FL plânovac bude DRC index 0x3 odpovidat viceuzivatelskému pfenosovému formâtù (1024,4,256), kterÿ Ize pfipadnë pfevést do formâtù ({128,256,512),4,256). Vsechny tyto viceuzivatelské formâty jsou kompatibilni se vsemi DRC indexy, takze AT by mël bÿt schopen dekôdovat mapované DRC dokud mâ dostatecnÿ SINR (nezâvislÿ na aktuâlnë pozadovaném DRC indexu). Alternativni algoritmy mohou bÿt konzervativnëjsi, coz omezuje dostupné viceuzivatelské
89723 (0989723_CZ.doc) 16.12.2006 pfenosové formâty s rostoucim Eras_Count na nizsi datové rychlosti.
Vsimnëte si, ze volba DARQ mûze bÿt pro VoIP zapnuta. Tak v pfipadë, ze AT nedekôdovala pfeneseny viceuzivatelskÿ paket pfi prvnim pokusu o pfenos, poskytne DARQ moznost druhého pokusu o pfenos a snizi zbytkovou chybovost paketû. Propustnost DARQ je ovsem svâzâna s propustnosti ACK kanâlu, kterÿ nemusi bÿt velmi spolehlivÿ, pokud je DRC ve vÿmazu. ACK/NAK rozhodovaci prâh mûze bÿt optimalizovân pro DARQ a mûze zâviset na DRC indexu nebo stavu DRC mapovani. Jiné provedeni cini pokus o DARQ pfenos kompatibilnim s pouze nizkorychlostnimi viceuzivatelskÿmi formâty paketu, napf. (512,4,1024) nebo (256,4,1024), v pfipadë mapovani DRC vÿmazu.
Alternativni provedeni mohou poskytovat dalsi kroky a prostfedky pro zde prezentovanÿ plânovac. Napfiklad BE/AF toky budou typicky vyuzivat prioritnich stavû, které maji striktnë nizsi prioritu nez prioritni stavy. To mûze vést k degradaci BE/AF propustnosti za pfitomnosti EF uzivatelû, ktefi budou mit vysoce pravdëpodobnë vyssi prioritni stavy. BE/AF propustnost mûze bÿt zesilena zvÿsenim priority BE/AF tokû na vyssi stavy za urcitÿch podminek.
Podle jednoho provedeni je AvgRequestedRate filtrovanâ pozadovanâ rychlost uzivatele, kde K uzivatelû je v systému konfigurovâno jako BE uzivatelé. Pokud propustnost uzivatele pro jeho BE toky, AvgThroughput splhuje:
AvgThroughput < — AvgRequestedRate ,
89723 (0989723_CZ.doc) 16.12.2006
Potom mûze bÿt uzivatelskÿ stav priority pro jeho BE toky zvÿsen na vyssi prioritni stavy. Hodnotu a Ize vybrat v zâvislosti na EF zâtëzi systému, mens! oc pro vyssi zâtëz. Navic Ize pfedepsat minimâlni pozadovanou rychlost pro uzivatele pro tuto podporu. Jsou mozné i jiné zpûsoby zvÿseni BE/AF kapacity.
Vÿse uvedenÿ zpûsob také navrhuje, ze prioritni stav bitové (vyrovnâvaci) metriky toku nemusi bÿt jenom funkce zpozdëni hlavicky fronty, ale mûze to bÿt také funkce propustnosti toku.
Vsimnëte si, ze ve stavech citlivÿch na zpozdëni je bitovâ metrika striktnë funkci zpozdëni a ze nemâ zâdnÿ mechanismus, kterÿm by mohla vyuzit lokâlnich spicek kanâlu uzivatele. Zde Ize hodnotu bitové vyrovnâvaci metriky ve stavech citlivÿch na zpozdëni modifikovat:
MDSds = AccelerationFactor*[CurrentDelay + kCCI] + Accelerationoffset, kde indikâtor stavu kanâlu (CCI - channel condition indicator) nabÿvâ hodnot z mnoziny {0,1} nebo intervalu [0,1], které mohou bÿt generovâny oddëlenë, takze kdyz nabÿvaji vyssich hodnot, indikuji relativnë dobrÿ stav kanâlu ve srovnâni s dlouhodobÿm stavem kanâlu uzivatele. Také k je faktor konverze CCI —zpozdëni. Udâvâ, jak moc naroste zpozdëni toku, kdyz je stav kanâlu uzivatele relativnë dobrÿ vzhledem k jeho vlastni statistice kanâlu.
Jeden jednoduchÿ zpûsob, jak generovat CCI pro binârni {0,1} pripad je dân nâsledovnë. Necht je Rateindex celé cislo pfifazené k DRC hodnotâm v pofadi rostouci rychlosti, kde DRC hodnota neni pouzita, protoze neroste
89723 (0989723_CZ.doc) 16.12.2006 monotônnë s rostouci datovou rychlosti. Necht’ je AvgRatelndex prùmërnÿ (filtrovanÿ) Rateindex uzivatele. Necht CCITreshold je parametr jako napriklad 1,2. Potom pokud Rateindex > CCITreshold * AvgRatelndex, Ize hodnotu CCI nastavit na jednicku. Jinak se nastavi na nulu. V torn pripadë bude CCI indikovat relativnë dobrÿ stav kanâlu, pokud je aktuâlni Rateindex odpovidajici prijimanému DRC 120% nebo vyssi nez prùmërnâ kvalita.
Nucené preruseni oznacuje stornovâni FL pfenosu pfedtim, nez jej dekôduji cilovi uzivatelé. Nucené preruseni Ize pouzit, pokud se objevi vysoce prioritni data, zatimco vsechna ctyri krizeni na FL jsou obsazena relativnë pomalÿmi uzivateli. Plânovac! algoritmus nyni neposkytuje zpùsob nuceného preruseni pfichâzejicich prenosù. Jednim z dùvodù je, ze i kdyz jsou peclivë sledované, mohou nekontrolovanâ nucenâ preruseni vést ke ztrâtâm kapacity.
Zde pouzitÿ pristup predchâzi okolnostem, které mohou vyzadovat nucené preruseni. Jednim takovÿm stavem je, jak bylo zminëno vÿse, kdyz jsou vsechna ctyri krizeni obsazena pomalÿmi uzivateli. Lze pouzit jednoduchÿch zpùsobù, aby se tomuto pfedeslo. Jednim takovÿm zpùsobem je nepovolit vëtsi nez pevnë danÿ pocet simultânnich prenosù formâtù s 16slotovÿmi a 8-slotovÿmi rozpëtimi. Jako priklad lze toto cislo nastavit na 2 nebo 3.
Jedno provedeni monitoruje propustnost dekôdovâni uzivatelù, ktefi pfenâseji NULL DRC a jsou obslouzeni v paketù. V zâvislosti na zmëfeném PER v tëchto NULL-to-rate pripadech je mozné pro kazdého uzivatele zapnout/vypnout NULL-to-rate konverze. Podobnë je mozné vypnout/zapnout omezeni obslouzeni RTx/DARQ front, stejnë jako front toku
89723 (0989723_CZ.doc) 16.12.2006 s nekonecnou hranici zpozdëni v NULL-to-rate instancich, pokud souhrnnâ statistika indikuje, ze pristupovÿ terminal dostatecnë spolehlivë dekôduje tyto pakety.
Koeficienty bitové a bitové vyrovnâvaci metriky pro toky citlivé na propustnost poskytuji proporcionâlni rovnost pouze v BE systému (napf. TargetThrouhgput = 0 a GoSFaktor = 1 pro vsechny toky) s uzivateli, kteri maji velkâ mnozstvi dat, kterâ mohou pfijimat. Tuto formu koeficientu metriky Ize pouzit podobnÿm zpùsobem v ostatnich plânovacich. Pro tyto ucely Ize koeficienty metriky pro toky citlivé na propustnost vyjâdrit jako:
1/ , · 1
MetricTS =-------------------—-_______________ f (AvgThroughput)h(Avg Re questedRate) kde f(.) a h(.) jsou generické funkce a AvgRequestedRate je prûmërnâ pozadovanâ rychlost uzivatele. Nastavenim f(x) = x a h(x) = x dâvâ pfibliznë stejnÿ GoS plânovace.
Zdokonalenÿ MAC protokol kanâlu primého trafficu definovanÿ v revizi A IxEV-DO specifikaci dâvâ omezeni na obsluhovâni uzivatelû v nâsledujicim viceuzivatelském paketu, jak je sumarizovâno nize. Specifikace revize A urcuje, ze slot T se definuje jako pokracovâni drivëjsiho slotu s, pokud jsou splnëny nâsledujici podminky:
c. Pristupovÿ terminâl je potenciâlni cil paketu, jehoz prenos zacinâ ve slotu s.
d. Slot t je ve stejném FL kfizeni jako slot s, tj. t-s = 0(mod 4).
89723 (0989723_CZ.doc) 16.12.2006
e. s < t < s + 4N, kde N oznacuje rozpëti DRC indexu odpovidajici DRC hodnotë, kterâ je v prûbëhu slotu aktuâlni.
f. Pied slotem t pristupovâ sit neprijimala kladnâ potvrzeni pro pakety, jejichz prenos zacal ve slotu s.
Pokud je pristupovÿ terminal potencionâlni cil paketu preneseného sektorem zacinajicim ve slotu s, pristupovâ sit neprenese novÿ paket ze stejného FL datového zdroje na pristupovÿ terminâl v kterémkoliv slotu t, kterÿ je pokracovânim slotu s.
Vÿse uvedenâ omezeni kladou podminky na to, kteri uzivatelé mohou bÿt obslouzeni viceuzivatelskÿm paketem. Jako priklad, pokud pristupovâ sit predâ viceuzivatelskÿ paket sadë uzivatelû, kterÿ potom drive skonci, pak nemûze pristupovâ sit predat jakékoliv pakety (jednouzivatelské nebo viceuzivatelské) v prûbëhu pokracovâni paketu pfedaného uzivatelûm, kteri nebyli obslouzeni v pfedchozim paketu, ale byli kompatibilni s jeho formâtem. V jedné situaci pfedâvâ pristupovâ sit 153,6 Kbps viceuzivatelskÿ paket a uzivatelé s daty nesenÿmi v tomto paketu jej dekôduji v ménë nez 4 slotech. Pokud pristupovâ sit bezprostfednë predâ jinÿ 153,6 Kbps viceuzivatelskÿ paket na stejném kfizeni, pak uzivatelé, kteri aktuâlnë pozadovali 153,6 Kbps nebo jakoukoliv DRC s rozpëtim 4 slotû, ale nebyli obslouzeni v pfedchozim paketu, nebudou moci bÿt obslouzeni v novém prenosu. Proto mohou bÿt v novém prenosu obslouzeni pouze ti uzivatelé, kteri pozadovali DRCs s rozpëtim mensim nez 4 sloty, tj . typicky uzivatelé s lepsim stavem kanâlu. To ovsem jestë zvysuje pravdëpodobnost, ze novÿ paket bude dekôdovân drive. Tento retëz mûze pokracovat, dokud se
89723 (0989723_CZ.doc) 16.12.2006 fronty uzivatelù vyssi geometrie nevyprâzdni. Mezitim nejsou obslouzeni uzivatelé s nizsi geometrii, ktefi pozaduji DRCs s rozpëtim 4 slotù. Vÿsledkem by mohlo bÿt prilisné zpozdëni pro uzivatele s nizsi geometrii a mozné malé zvëtseni zpozdëni pro uzivatele s vyssi geometrii.
Vsimnëte si, ze vÿse uvedenâ provedeni, aspekty a priklady se tÿkaji systémù podporujicich vysokorychlostni datovÿ protokol. Takovÿ systém je prezentovân pro jasnost a pochopeni predlozenÿch myslenek. Zde prezentovanÿ zpùsob a prostfedky pro adaptivni sprâvu zpozdëni a plânovâni mohou implementovat i alternativni systémy.
Byl tedy popsân novÿ a vylepsenÿ zpûsob a zafizeni pro plânovâni pfenosû v komunikacnim systému. Odbornikûm bude zrejmé, ze data, instrukce, prikazy, informace, signâly, bity, symboly a cipy, na které se ve vÿse uvedeném popisu odkazuje, jsou vÿhodnë reprezentovâny napëtimi, proudy, elektromagnetickÿmi vlnami, magnetickÿmi poli nebo câsticemi, optickÿmi poli nebo câsticemi nebo jakoukoliv jejich kombinaci. Odbornici dâle uznaji, ze rùzné ilustrativni logické bloky, moduly, obvody a kroky algoritmu popsané ve spojeni s provedenimi tohoto vynâlezu Ize implementovat jako elektronickÿ hardware, pocitacovÿ software nebo kombinaci obojiho. Rùzné ilustrativni komponenty, bloky, moduly, obvody a kroky byly obecnë popsâny ve smyslu jejich funkcionality. To, zda je tato funcionalita implementovâna jako hardware nebo software zâvisi na konkrétni aplikaci a omezenich nâvrhu kladenÿch na celÿ systém. Odbornici za tëchto okolnosti uznaji zâmënnost hardwaru a softwaru a jak nejlépe implementovat popsané funkcionality pro kazdou konkrétni aplikaci. Rùzné ilustrativni logické bloky, moduly, obvody a kroky
89723 (0989723_CZ.doc) 16.12.2006 algoritmu, které jsou popsâny ve spojeni se zde uvedenÿmi provedenimi Ize implementovat nebo provâdët napfiklad pomoci digitâlniho signâlového procesoru (DSP), aplikacnë specifického integrovaného obvodu (ASIC), programovatelného hradlového pole (FPGA - field programmable gate array) nebo jinÿch programovatelnÿch logickÿch zafizeni, diskrétnich hradel nebo transistorové logiky, diskrétnich hardwarovÿch komponent jako napf. registrù a FIFO, procesoru provâdëjiciho sadu firmwarovÿch instrukci, jakéhokoliv konvencniho programovatelného softwarového modulu a procesoru nebo jakékoliv jejich kombinace navrzené k provâdëni zde popsanÿch funkci. Procesor mùze bÿt vÿhodnë mikroprocesor, ale alternativnë mùze bÿt procesor jakÿkoliv konvencni procesor, fadic, mikrofadic, programovatelné logické zafizeni, pole logickÿch prvkû nebo stavovÿ stroj. Softwarovÿ modul mùze bÿt ulozen 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ët’ového média. Ukâzkovÿ procesor je vÿhodnë pfipojen k pamëtovému médiu, aby z nëj mohl cist a zapisovat na nëj informace. Alternativnë mùze bÿt pamët’ové médium integrovâno do procesoru. Procesor a pamëtové médium se mohou nachazet v ASIC. ASIC se mùze nachazet v telefonu nebo jiném uzivatelském terminâlu. Alternativnë se mohou procesor a pamëtové médium nachazet v telefonu nebo jiném uzivatelském terminâlu. Procesor Ize implementovat jako kombinaci DSP a mikroprocesoru, nebo dvou mikroprocesorù ve spojeni s DSP jâdrem atd.
89723 (0989723_CZ.doc) 16.12.2006
Byla ukâzâna a popsâna upfednostnovana provedeni tohoto vynâlezu. Bëznÿm odbornikûm bude ovsem zrejmé, ze Ize provést fadu obmën, aniz bychom se odchÿlili od rozsahu a podstaty tohoto vynâlezu. Proto tento vynâlez nemâ bÿt nijak omezen kromë nâsledujicich nârokû.

Claims (4)

  1. PATENTOVÉ NÂROKY
    1. Zpùsob plânovâni instanci pfenosu v bezdrâtovém komunikacnim systému obsahujici:
    prijeti indikâtorù stavu kanâlu od mnozstvi mobilnich uzivatelû, kde indikâtory stavu kanâlu odpovidaji komunikaci pfimÿm linkem;
    urceni kritéria zpozdëni pro mnozstvi mobilnich uzivatelû a urceni plânu pfenosû pro mnozstvi mobilnich uzivatelû, kde plân pfenosû je funkce kritéria zpozdëni.
  2. 2. Zpùsob plânovâni instanci pfenosu v bezdrâtovém komunikacnim systému, obsahujici:
    vyhodnoceni mnozstvi pfenosovÿch front pro identifikaci citlivosti na zpozdëni a citlivosti na propustnost aplikacniho toku pfifazeného kazdé pfenosové frontë;
    vygenerovâni sady kandidâtskÿch instanci pfenosu z mnozstvi pfenosovÿch front;
    vÿbër jedné kandidâtské instance pfenosu z této sady a pfipravu vybrané kandidâtské instance pfenosu pro pfenos.
  3. 3. Zpùsob podle nâroku 2, kde vygenerovâni sady kandidâtskÿch instanci pfenosu obsahuje:
    vygenerovâni bitové metriky pro kazdou frontu a vygenerovâni bitové vyrovnâvaci metriky pro kazdou frontu.
  4. 4. Zpùsob podle nâroku 3, kde vÿbër jedné kandidâtské instance pfenosu obsahuje:
    09 89723 (0989723_CZ.doc) 16.12.2006 vygenerovâni paketovë metriky jako funkce bitové metriky a porovnâni paketovÿch metrik pro jednotlivé kandidâtské instance pfenosu v sadë.
CZ20060687A 2004-05-05 2005-05-05 Zpusob a zarízení pro adaptivní správu zpozdení vbezdrátovém komunikacním systému CZ2006687A3 (cs)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US56865004P 2004-05-05 2004-05-05
US62566004P 2004-11-04 2004-11-04

Publications (1)

Publication Number Publication Date
CZ2006687A3 true CZ2006687A3 (cs) 2007-03-28

Family

ID=34969054

Family Applications (1)

Application Number Title Priority Date Filing Date
CZ20060687A CZ2006687A3 (cs) 2004-05-05 2005-05-05 Zpusob a zarízení pro adaptivní správu zpozdení vbezdrátovém komunikacním systému

Country Status (16)

Country Link
US (1) US8472322B2 (cs)
EP (1) EP1745611A1 (cs)
JP (2) JP4509177B2 (cs)
KR (2) KR100896399B1 (cs)
AU (1) AU2005241986A1 (cs)
BR (1) BRPI0509447A (cs)
CA (1) CA2564983A1 (cs)
CZ (1) CZ2006687A3 (cs)
EC (1) ECSP067059A (cs)
IL (1) IL178972A0 (cs)
MX (1) MXPA06012747A (cs)
NO (1) NO20065561L (cs)
RU (1) RU2354061C2 (cs)
TR (1) TR200700129T2 (cs)
TW (1) TW200616386A (cs)
WO (1) WO2005109792A1 (cs)

Families Citing this family (126)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9661519B2 (en) 2003-02-24 2017-05-23 Qualcomm Incorporated Efficient reporting of information in a wireless communication system
US9544860B2 (en) 2003-02-24 2017-01-10 Qualcomm Incorporated Pilot signals for use in multi-sector cells
US7218948B2 (en) 2003-02-24 2007-05-15 Qualcomm Incorporated Method of transmitting pilot tones in a multi-sector cell, including null pilot tones, for generating channel quality indicators
US8811348B2 (en) 2003-02-24 2014-08-19 Qualcomm Incorporated Methods and apparatus for generating, communicating, and/or using information relating to self-noise
US7843925B2 (en) * 2004-01-20 2010-11-30 Nortel Networks Limited Ethernet differentiated services architecture
JP4301970B2 (ja) * 2004-02-23 2009-07-22 株式会社エヌ・ティ・ティ・ドコモ パケット送信制御装置及びパケット送信制御方法
US8331377B2 (en) * 2004-05-05 2012-12-11 Qualcomm Incorporated Distributed forward link schedulers for multi-carrier communication systems
CZ2006687A3 (cs) 2004-05-05 2007-03-28 Qualcomm Incorporated Zpusob a zarízení pro adaptivní správu zpozdení vbezdrátovém komunikacním systému
KR100660054B1 (ko) * 2004-09-01 2006-12-20 한국전자통신연구원 서비스 지연 시간 및 채널 상태를 이용한 하향링크 패킷스케쥴링 방법
US8478283B2 (en) * 2004-09-29 2013-07-02 Apple Inc. Method and system for capacity and coverage enhancement in wireless networks with relays
US7715341B2 (en) * 2005-01-28 2010-05-11 Nortel Networks Limited Optimized scheduling method for delay-sensitive traffic on high speed shared packet data channels
US7924772B2 (en) * 2005-02-10 2011-04-12 Nokia Corporation Method and apparatus to support multi-user packets in a wireless communication system
US8184655B2 (en) * 2005-04-21 2012-05-22 Interdigital Technology Corporation Wireless communication method and WLAN for signaling deferral management messages
US8732325B2 (en) * 2005-05-10 2014-05-20 St-Ericsson Sa System and method for transmitting data
US8503299B2 (en) * 2005-05-12 2013-08-06 Apple, Inc. Method and system for packet scheduling
US8838115B2 (en) * 2005-07-20 2014-09-16 Qualcomm Incorporated Method and apparatus for expanded data rate control indices in a wireless communication system
US7864777B1 (en) 2005-09-30 2011-01-04 Nortel Networks Limited Transmission format selection for optimizing transmission of delay sensitive traffic
US7609671B1 (en) * 2005-09-30 2009-10-27 Nortel Networks Limited Multi-user scheduling for optimizing transmission of delay sensitive traffic
WO2007043815A1 (en) * 2005-10-12 2007-04-19 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving data in a code division multiple access system
US8694042B2 (en) 2005-10-14 2014-04-08 Qualcomm Incorporated Method and apparatus for determining a base station's transmission power budget
US9191840B2 (en) 2005-10-14 2015-11-17 Qualcomm Incorporated Methods and apparatus for determining, communicating and using information which can be used for interference control
JP2007150713A (ja) * 2005-11-28 2007-06-14 Kddi Corp 無線スケジューリング装置、無線スケジューリング方法及び無線装置
US8514771B2 (en) 2005-12-22 2013-08-20 Qualcomm Incorporated Methods and apparatus for communicating and/or using transmission power information
US9137072B2 (en) 2005-12-22 2015-09-15 Qualcomm Incorporated Methods and apparatus for communicating control information
US9338767B2 (en) 2005-12-22 2016-05-10 Qualcomm Incorporated Methods and apparatus of implementing and/or using a dedicated control channel
US8437251B2 (en) 2005-12-22 2013-05-07 Qualcomm Incorporated Methods and apparatus for communicating transmission backlog information
US9572179B2 (en) 2005-12-22 2017-02-14 Qualcomm Incorporated Methods and apparatus for communicating transmission backlog information
US20070149132A1 (en) 2005-12-22 2007-06-28 Junyl Li Methods and apparatus related to selecting control channel reporting formats
US20070249287A1 (en) * 2005-12-22 2007-10-25 Arnab Das Methods and apparatus for selecting between a plurality of dictionaries
US9473265B2 (en) 2005-12-22 2016-10-18 Qualcomm Incorporated Methods and apparatus for communicating information utilizing a plurality of dictionaries
US9148795B2 (en) 2005-12-22 2015-09-29 Qualcomm Incorporated Methods and apparatus for flexible reporting of control information
US9451491B2 (en) 2005-12-22 2016-09-20 Qualcomm Incorporated Methods and apparatus relating to generating and transmitting initial and additional control information report sets in a wireless system
US9125093B2 (en) 2005-12-22 2015-09-01 Qualcomm Incorporated Methods and apparatus related to custom control channel reporting formats
US9125092B2 (en) 2005-12-22 2015-09-01 Qualcomm Incorporated Methods and apparatus for reporting and/or using control information
US9119220B2 (en) 2005-12-22 2015-08-25 Qualcomm Incorporated Methods and apparatus for communicating backlog related information
JP4714599B2 (ja) * 2006-02-27 2011-06-29 京セラ株式会社 基地局装置及び通信制御方法
US7464313B2 (en) * 2006-03-09 2008-12-09 Motorola, Inc. Hybrid approach for data transmission using a combination of single-user and multi-user packets
US20070243882A1 (en) 2006-04-12 2007-10-18 Qualcomm Incorporated Method and apparatus for locating a wireless local area network associated with a wireless wide area network
US9049096B2 (en) * 2006-06-19 2015-06-02 Qualcomm Incorporated Data routing via lower layers in a communication system
CN101485131B (zh) 2006-06-30 2013-09-25 高通股份有限公司 一种用于减少ad-hoc无线通信网络中的干扰的装置、系统和方法
US8311002B2 (en) * 2006-09-19 2012-11-13 Telefonaktiebolaget L M Ericsson (Publ) Scheduling of users on a shared radio resource using a combination of link quality and traffic information
US8379578B2 (en) * 2006-12-01 2013-02-19 Qualcomm Incorporated Control signal transmission for wireless communication systems
US9131486B2 (en) 2006-12-01 2015-09-08 Qualcomm Incorporated Control signal transmission for wireless communication systems
US9113362B2 (en) * 2006-12-12 2015-08-18 At&T Mobility Ii Llc Method and apparatus to separate coverage limited and co-channel limited interferences
CN101175064B (zh) * 2006-12-18 2012-01-11 中兴通讯股份有限公司 基于服务质量的前向链路调度方法
KR100946893B1 (ko) 2007-01-03 2010-03-09 삼성전자주식회사 이동 통신 시스템에서 순방향 패킷 스케줄링 방법 및 그장치
WO2009004655A1 (en) 2007-07-02 2009-01-08 Telecom Italia S.P.A. Application data flow management in an ip network
US8149715B1 (en) 2007-07-17 2012-04-03 Marvell International Ltd. Mesh network operations
EP2023683B1 (en) * 2007-08-09 2011-05-18 Nokia Siemens Networks Oy Mobile communication terminal, communication station, communication network, and communication method
US8369782B1 (en) 2007-08-13 2013-02-05 Marvell International Ltd. Bluetooth wideband scan mode
US8553561B1 (en) 2007-08-22 2013-10-08 Marvell International Ltd. Quality of service for mesh networks
WO2009028102A1 (ja) * 2007-08-31 2009-03-05 Fujitsu Limited メッセージ交換方法、無線通信システム、無線端末装置、および無線基地局装置
US8503465B2 (en) * 2007-09-17 2013-08-06 Qualcomm Incorporated Priority scheduling and admission control in a communication network
US8688129B2 (en) * 2007-09-17 2014-04-01 Qualcomm Incorporated Grade of service (GoS) differentiation in a wireless communication network
US8577305B1 (en) 2007-09-21 2013-11-05 Marvell International Ltd. Circuits and methods for generating oscillating signals
US8194556B2 (en) * 2007-12-10 2012-06-05 Motorola Mobility, Inc. Latency-aware adaptive bandwidth request mechanism for real-time communication in WiMAX
US8588705B1 (en) 2007-12-11 2013-11-19 Marvell International Ltd. System and method of determining Power over Ethernet impairment
US8670419B2 (en) * 2008-02-01 2014-03-11 Qualcomm Incorporated Methods and apparatus for intra-user quality of service uplink scheduling
EP2281403B1 (en) * 2008-05-27 2016-10-26 Qualcomm Incorporated(1/3) Setting up a communication session within a wireless communications system
CN102067689B (zh) 2008-06-16 2016-11-09 马维尔国际贸易有限公司 近程无线通信
US8310967B1 (en) 2008-06-19 2012-11-13 Marvell International Ltd. Infrastructure and ad-hoc node device
US8600324B1 (en) 2008-06-27 2013-12-03 Marvell International Ltd Circuit and method for adjusting a digitally controlled oscillator
JP5191826B2 (ja) 2008-07-04 2013-05-08 パナソニック株式会社 ストリーム通信装置、ストリーム通信方法及びストリーム通信システム
US8472968B1 (en) 2008-08-11 2013-06-25 Marvell International Ltd. Location-based detection of interference in cellular communications systems
CN101686431B (zh) * 2008-09-22 2012-07-18 中兴通讯股份有限公司 同步处理方法和装置
US9288764B1 (en) 2008-12-31 2016-03-15 Marvell International Ltd. Discovery-phase power conservation
US8472427B1 (en) 2009-04-06 2013-06-25 Marvell International Ltd. Packet exchange arbitration for coexisting radios
US8665724B2 (en) 2009-06-12 2014-03-04 Cygnus Broadband, Inc. Systems and methods for prioritizing and scheduling packets in a communication network
US9065779B2 (en) 2009-06-12 2015-06-23 Wi-Lan Labs, Inc. Systems and methods for prioritizing and scheduling packets in a communication network
EP3661304A1 (en) * 2009-06-19 2020-06-03 Mitsubishi Electric Corporation Mobile communication system
CN101932045B (zh) * 2009-06-24 2014-11-05 中兴通讯股份有限公司 载波聚合中测量结果的上报方法及用户设备
US8625440B2 (en) * 2009-07-31 2014-01-07 Alcatel Lucent System and method for controlling parameters for applications serviced in a best effort communication link
BR112012003117A2 (pt) * 2009-08-12 2016-02-23 Nortel Networks Ltd fornecimento de uma resposta de negação que especifica um tempo de atraso
US9066369B1 (en) 2009-09-16 2015-06-23 Marvell International Ltd. Coexisting radio communication
US8340034B1 (en) 2009-11-11 2012-12-25 Marvell International Ltd. Bluetooth and wireless LAN arbitration
CN102076093B (zh) * 2009-11-24 2014-09-10 中兴通讯股份有限公司 下行业务接纳控制方法及装置
US9603085B2 (en) 2010-02-16 2017-03-21 Qualcomm Incorporated Methods and apparatus providing intelligent radio selection for legacy and non-legacy applications
TW201136276A (en) * 2010-04-08 2011-10-16 Gemtek Technology Co Ltd Wireless packet relay apparatus and wireless set-top box
KR101729926B1 (ko) 2010-04-28 2017-04-25 삼성전자주식회사 순차적 리스폰스 프로토콜을 이용한 데이터 통신 방법 및 상기 방법이 적용된 단말
US9350616B1 (en) * 2010-05-11 2016-05-24 Trend Micro Inc. Bandwidth prediction using a past available bandwidth value and a slope calculated from past available bandwidth values
US8767771B1 (en) 2010-05-11 2014-07-01 Marvell International Ltd. Wakeup beacons for mesh networks
KR101468767B1 (ko) * 2010-06-08 2014-12-08 한국전자통신연구원 다중 캐리어 무선 통신 시스템에서의 송수신 방법 및 장치
US8953444B2 (en) * 2010-06-25 2015-02-10 Qualcomm Incorporated Load balancing
JP5776128B2 (ja) 2010-10-20 2015-09-09 マーベル ワールド トレード リミテッド 関連付け前の発見
KR101163750B1 (ko) * 2010-10-21 2012-07-10 광주과학기술원 다수 플로우의 쓰루풋 공평성을 관리하는 플로우 제어 노드, 송신 노드, 플로우 제어 방법 및 전송률 제어 방법
WO2012121751A1 (en) * 2011-03-07 2012-09-13 Intel Corporation Grouped machine-to-machine communications
US8750278B1 (en) 2011-05-26 2014-06-10 Marvell International Ltd. Method and apparatus for off-channel device invitation
US8983557B1 (en) 2011-06-30 2015-03-17 Marvell International Ltd. Reducing power consumption of a multi-antenna transceiver
EP2549819B1 (en) * 2011-07-22 2014-10-01 MIMOON GmbH Method and apparatus for self-optimized scheduling
US9125216B1 (en) 2011-09-28 2015-09-01 Marvell International Ltd. Method and apparatus for avoiding interference among multiple radios
US9036517B2 (en) 2012-01-09 2015-05-19 Marvell World Trade Ltd. Methods and apparatus for establishing a tunneled direct link setup (TDLS) session between devices in a wireless network
US9215708B2 (en) 2012-02-07 2015-12-15 Marvell World Trade Ltd. Method and apparatus for multi-network communication
US9609676B1 (en) 2012-03-30 2017-03-28 Marvell International Ltd. Efficient transition from discovery to link establishment
US8953482B2 (en) * 2012-05-11 2015-02-10 Intel Corporation Methods and apparatuses to improve on-time throughput for integrated multi-rat heterogeneous networks
US9450649B2 (en) 2012-07-02 2016-09-20 Marvell World Trade Ltd. Shaping near-field transmission signals
JP2016527838A (ja) * 2013-08-06 2016-09-08 ソニー株式会社 インフラ機器、無線通信ネットワークおよび方法
WO2015109515A1 (en) * 2014-01-24 2015-07-30 Nokia Solutions And Networks Oy Inter-operability test indication for uplink-downlink configuration combinations for primary cell and secondary cell for wireless networks using carrier aggregation
JP2016010088A (ja) * 2014-06-26 2016-01-18 株式会社日立製作所 ネットワーク制御装置
US20170078887A1 (en) 2015-09-15 2017-03-16 Qualcomm Incorporated Systems and methods for reuse of wireless communication resources in neighboring communication networks
US10200967B2 (en) 2017-01-06 2019-02-05 Qualcomm Incorporated Systems and methods for limiting a message size for a positioning protocol
CN108419275B (zh) 2017-02-10 2022-01-14 华为技术有限公司 一种数据传输方法、通信设备、终端和基站
US10455445B2 (en) * 2017-06-22 2019-10-22 Rosemount Aerospace Inc. Performance optimization for avionic wireless sensor networks
CN108462549B (zh) * 2017-11-22 2019-07-09 上海欣诺通信技术股份有限公司 保护组叠加倒换方法、控制装置及光通信设备
US10805047B2 (en) * 2018-02-27 2020-10-13 Intel Corporation System, method and apparatus for QoS support and retransmission
EP3605914A1 (en) * 2018-07-31 2020-02-05 INTEL Corporation System, method and apparatus for qos retransmission for mg.fast
US10659112B1 (en) 2018-11-05 2020-05-19 XCOM Labs, Inc. User equipment assisted multiple-input multiple-output downlink configuration
US10756860B2 (en) 2018-11-05 2020-08-25 XCOM Labs, Inc. Distributed multiple-input multiple-output downlink configuration
US10432272B1 (en) 2018-11-05 2019-10-01 XCOM Labs, Inc. Variable multiple-input multiple-output downlink user equipment
US10812216B2 (en) 2018-11-05 2020-10-20 XCOM Labs, Inc. Cooperative multiple-input multiple-output downlink scheduling
KR20210087089A (ko) 2018-11-27 2021-07-09 엑스콤 랩스 인코퍼레이티드 넌-코히어런트 협력 다중 입출력 통신
US11063645B2 (en) 2018-12-18 2021-07-13 XCOM Labs, Inc. Methods of wirelessly communicating with a group of devices
US10756795B2 (en) 2018-12-18 2020-08-25 XCOM Labs, Inc. User equipment with cellular link and peer-to-peer link
US10904359B2 (en) * 2018-12-26 2021-01-26 Facebook, Inc. Systems and methods for smart scheduling of outbound data requests
US11330649B2 (en) 2019-01-25 2022-05-10 XCOM Labs, Inc. Methods and systems of multi-link peer-to-peer communications
US10756767B1 (en) 2019-02-05 2020-08-25 XCOM Labs, Inc. User equipment for wirelessly communicating cellular signal with another user equipment
CN113647070B (zh) * 2019-03-12 2025-03-25 弗劳恩霍夫应用研究促进协会 发送器和接收器、串行器和解串器以及用于发送和接收、串行化和解串化的方法
US10686502B1 (en) 2019-04-29 2020-06-16 XCOM Labs, Inc. Downlink user equipment selection
US10735057B1 (en) 2019-04-29 2020-08-04 XCOM Labs, Inc. Uplink user equipment selection
US11411778B2 (en) 2019-07-12 2022-08-09 XCOM Labs, Inc. Time-division duplex multiple input multiple output calibration
CN114080816B (zh) 2019-07-17 2025-03-14 杜比国际公司 用于内容传递的时延管理
US11411779B2 (en) 2020-03-31 2022-08-09 XCOM Labs, Inc. Reference signal channel estimation
US12068953B2 (en) 2020-04-15 2024-08-20 Virewirx, Inc. Wireless network multipoint association and diversity
EP4012683B1 (en) * 2020-12-14 2026-01-28 Rohde & Schwarz GmbH & Co. KG Air traffic management system, use of air traffic management system and method of establishing an ip-based air traffic management system
WO2022241436A1 (en) 2021-05-14 2022-11-17 XCOM Labs, Inc. Scrambling identifiers for wireless communication systems
RU2763290C1 (ru) * 2021-07-02 2021-12-28 Федеральное государственное бюджетное образовательное учреждение высшего образования «Юго-Западный государственный университет» Способ определения корректности передачи информационных пакетов
US20240146399A1 (en) * 2022-09-19 2024-05-02 Apple Inc. Device-Driven Communication Handover

Family Cites Families (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5278828A (en) 1992-06-04 1994-01-11 Bell Communications Research, Inc. Method and system for managing queued cells
US5859835A (en) 1996-04-15 1999-01-12 The Regents Of The University Of California Traffic scheduling system and method for packet-switched networks
JP3351678B2 (ja) * 1996-05-07 2002-12-03 株式会社東芝 ネットワーク対応コンタクト装置
US6031832A (en) * 1996-11-27 2000-02-29 Telefonaktiebolaget L M Ericsson (Publ) Method and apparatus for improving performance of a packet communications system
US6335922B1 (en) * 1997-02-11 2002-01-01 Qualcomm Incorporated Method and apparatus for forward link rate scheduling
US5999931A (en) 1997-10-17 1999-12-07 Lucent Technologies Inc. Concurrency control protocols for management of replicated data items in a distributed database system
US6205150B1 (en) 1998-05-28 2001-03-20 3Com Corporation Method of scheduling higher and lower priority data packets
US6658021B1 (en) 1998-06-19 2003-12-02 Juniper Networks, Inc. Method and system for encapsulating/decapsulating data on a per channel basis in hardware
GB2341059A (en) * 1998-08-28 2000-03-01 Nokia Oy Ab Internet protocol flow detection
US6381647B1 (en) 1998-09-28 2002-04-30 Raytheon Company Method and system for scheduling network communication
US6338078B1 (en) 1998-12-17 2002-01-08 International Business Machines Corporation System and method for sequencing packets for multiprocessor parallelization in a computer network system
US7406098B2 (en) * 1999-01-13 2008-07-29 Qualcomm Incorporated Resource allocation in a communication system supporting application flows having quality of service requirements
JP2000204575A (ja) 1999-01-19 2000-07-25 Sumitomo Rubber Ind Ltd ゴムガスケット
US6820128B1 (en) * 1999-11-04 2004-11-16 Nortel Networks Limited Method and apparatus of processing packets having varying priorities by adjusting their drop functions according to a predefined fairness relationship
US6996069B2 (en) 2000-02-22 2006-02-07 Qualcomm, Incorporated Method and apparatus for controlling transmit power of multiple channels in a CDMA communication system
US6590890B1 (en) * 2000-03-03 2003-07-08 Lucent Technologies Inc. Method of packet scheduling, with improved delay performance, for wireless networks
US6493331B1 (en) 2000-03-30 2002-12-10 Qualcomm Incorporated Method and apparatus for controlling transmissions of a communications systems
WO2001082543A2 (en) 2000-04-22 2001-11-01 Atheros Communications, Inc. Multi-carrier communication systems employing variable ofdm-symbol rates and number of carriers
US6937561B2 (en) * 2000-06-02 2005-08-30 Agere Systems Inc. Method and apparatus for guaranteeing data transfer rates and enforcing conformance with traffic profiles in a packet network
US6990113B1 (en) 2000-09-08 2006-01-24 Mitsubishi Electric Research Labs., Inc. Adaptive-weighted packet scheduler for supporting premium service in a communications network
US20020040381A1 (en) 2000-10-03 2002-04-04 Steiger Dianne L. Automatic load distribution for multiple digital signal processing system
US7000026B2 (en) * 2000-12-22 2006-02-14 Nortel Networks Limited Multi-channel sharing in a high-capacity network
US20020085567A1 (en) 2000-12-28 2002-07-04 Maple Optical Systems, Inc. Metro switch and method for transporting data configured according to multiple different formats
US6901046B2 (en) * 2001-04-03 2005-05-31 Nokia Corporation Method and apparatus for scheduling and modulation and coding selection for supporting quality of service in transmissions on forward shared radio channels
US6807426B2 (en) * 2001-04-12 2004-10-19 Qualcomm Incorporated Method and apparatus for scheduling transmissions in a communication system
US7239636B2 (en) 2001-07-23 2007-07-03 Broadcom Corporation Multiple virtual channels for use in network devices
US7027392B2 (en) * 2001-08-14 2006-04-11 Qualcomm, Incorporated Method and apparatus for scheduling packet data transmissions in a wireless communication system
US7280473B2 (en) * 2001-08-30 2007-10-09 Nortel Networks Limited Data streaming method and apparatus using adaptive transmission scheduling
US6788687B2 (en) * 2001-10-30 2004-09-07 Qualcomm Incorporated Method and apparatus for scheduling packet data transmissions in a wireless communication system
US7453801B2 (en) * 2001-11-08 2008-11-18 Qualcomm Incorporated Admission control and resource allocation in a communication system supporting application flows having quality of service requirements
US7103350B2 (en) 2001-11-16 2006-09-05 Nortel Networks Limited Scheduler with fairness control and quality of service support
US7110421B2 (en) * 2001-11-28 2006-09-19 Sony Corporation System and method for transmitting information over multiple channels
EP1317110B1 (en) 2001-11-30 2003-07-16 Alcatel IP platform for advanced multipoint access systems
JP3828431B2 (ja) 2002-01-31 2006-10-04 株式会社エヌ・ティ・ティ・ドコモ 基地局、制御装置、通信システム及び通信方法
US7110411B2 (en) * 2002-03-25 2006-09-19 Erlang Technology, Inc. Method and apparatus for WFQ scheduling using a plurality of scheduling queues to provide fairness, high scalability, and low computation complexity
US7746779B2 (en) * 2002-06-03 2010-06-29 Alcatel-Lucent Usa Inc. Method and apparatus for scheduling users to allocate data transmissions in communications systems
US7917648B2 (en) 2002-06-27 2011-03-29 Nokia Corporation Self-adaptive scheduling method and network element
US7164919B2 (en) * 2002-07-01 2007-01-16 Qualcomm Incorporated Scheduling of data transmission for terminals with variable scheduling delays
CA2398755A1 (en) 2002-08-19 2004-02-19 Faisal Shad Scheduler for a shared channel
AU2003291502A1 (en) 2002-11-08 2004-06-03 Lyndale Trading Company Limited Adaptive broadband platforms and methods of operation
EP1566026B1 (en) 2002-11-27 2010-01-13 RGB Networks, Inc. Apparatus and method for dynamic channel mapping and optimized scheduling of data packets
TWI333353B (en) 2003-01-21 2010-11-11 Panasonic Corp System and method for communications with reservation of network resources, and terminal therefore
WO2004068770A2 (en) 2003-01-24 2004-08-12 Houston Associates Inc. Multi-level expedited forwarding per hop behavior
US7330433B2 (en) * 2003-02-28 2008-02-12 Mitsubishi Electric Research Laboratories, Inc. Dynamic resource control for high-speed downlink packet access wireless channels
US7283814B2 (en) * 2003-07-31 2007-10-16 Lucent Technologies Inc. Method and apparatus for scheduling transmissions in wireless data networks
US7457241B2 (en) 2004-02-05 2008-11-25 International Business Machines Corporation Structure for scheduler pipeline design for hierarchical link sharing
US20050207441A1 (en) * 2004-03-22 2005-09-22 Onggosanusi Eko N Packet transmission scheduling in a multi-carrier communications system
US8331377B2 (en) * 2004-05-05 2012-12-11 Qualcomm Incorporated Distributed forward link schedulers for multi-carrier communication systems
CZ2006687A3 (cs) 2004-05-05 2007-03-28 Qualcomm Incorporated Zpusob a zarízení pro adaptivní správu zpozdení vbezdrátovém komunikacním systému

Also Published As

Publication number Publication date
KR100871736B1 (ko) 2008-12-05
MXPA06012747A (es) 2007-02-19
ECSP067059A (es) 2007-01-26
US20050281278A1 (en) 2005-12-22
KR20080040796A (ko) 2008-05-08
JP4971411B2 (ja) 2012-07-11
JP2007536827A (ja) 2007-12-13
CA2564983A1 (en) 2005-11-17
TR200700129T2 (tr) 2007-03-21
JP2010114913A (ja) 2010-05-20
BRPI0509447A (pt) 2007-09-04
NO20065561L (no) 2007-02-02
KR20070010194A (ko) 2007-01-22
WO2005109792A1 (en) 2005-11-17
AU2005241986A1 (en) 2005-11-17
RU2354061C2 (ru) 2009-04-27
US8472322B2 (en) 2013-06-25
KR100896399B1 (ko) 2009-05-08
JP4509177B2 (ja) 2010-07-21
EP1745611A1 (en) 2007-01-24
IL178972A0 (en) 2007-03-08
RU2006142853A (ru) 2008-06-10
TW200616386A (en) 2006-05-16

Similar Documents

Publication Publication Date Title
JP4971411B2 (ja) 無線通信システムにおける適応型遅延管理のための方法及び装置
EP1989844B1 (en) Distributed forward link schedulers for multi-carrier communication systems
US8121115B2 (en) Compressed delay packet transmission scheduling
AU2004213980B2 (en) Method and apparatus for controlling data rate of a reverse link in a communication system
HUP0201961A2 (en) Scheduling and admission control of pocket data traffic
BRPI0722339B1 (pt) Método para programar serviços de transmissão, programador, dispositivo de comunicação, e, meio de armazenamento legível por computador
CN101346971A (zh) 用于解决数据分组业务拥塞的方法和设备
WO2004084509A2 (en) Admission control and resource allocation in a communication system supporting quality of service
CN1981493B (zh) 在无线通信系统中进行自适应延迟管理的方法和装置
Braga et al. Packet scheduling for VoIP over HSDPA in mixed traffic scenarios
HK1103885A (en) Method and apparatus for adaptive delay management in a wireless communication system