NO337783B1 - Dataoverføringsplanlegging ved mediumstilgangskontroll (MAC) lag i et mobilt nettverk. - Google Patents

Description

OPPFINNELSENS OMRÅDE

Denne oppfinnelse gjelder generelt prosedyrer som brukes av MAC-lag for å planlegge datatransmisjon. Nærmere bestemt gjelder oppfinnelsen fremgangsmåte og algoritme for dataoverføring i UMTS-nettverk.

BAKGRUNN

I et tredjegenerasjons partnerskapsprosjekt for universelt mobilt telekommunikasjons-system (3GPP UMTS) er MAC-laget i brukerutstyret (UE) samt i radionettverksregula-toren ansvarlig for å planlegge dataoverføring henholdsvis i opplink- og nedlinkret-ningen. Transportkanaler danner grensesnitt mellom MAC-laget og det fysiske lag. I det fysiske lag er et sett av transportkanaler kombinert til å danne en kodet sammensatt transportkanal (CCTrCH).

IUS2003112786 er det vist en metode og system for å muliggjøre effektiv reduksjon av TFCer i TFCSen for å oppnå ønsket forsendelse, mens man fortsatt er innenfor ønsket effekt og data krav.

Et transportformat-kombinasjonssett (TFCS) er definert for hvert CCTrCH. Hver transportformatkombinasjon (TFC) fastlegger et transportformat (TF) for hver transportkanal for CCTrCH. TF fastlegger datahastigheten for en transportkanal ved innstilling av overføringstidsintervaller (TTI) (i ms), størrelsen av transportblokken (TB) (i bit-enheter) og størrelsen av transportblokksettet (TBS) (angitt i antall blokker).

En TB er således den basisenhet som utveksles mellom MAC og de fysiske lag. En TBS er definert som et sett av TB-enheter, som da utveksles mellom det fysiske lag og MAC-laget på samme tid og ved bruk av samme transportkanal. TTI er definert som ensidige ankomsttider for TBS-enheter. En TTI er lik den periodisitet hvorved en TBS overføres fra MAC til det fysiske lag og derpå av det fysiske lag inn på radiogrensesnit-tet.

MAC får data fra radiolenke-reguleringslaget (RLC). Grensesnittet mellom MAC-laget og RLC-laget dannes av logiske kanaler, eller radiobærere (RB). Hver transportkanal kan fremføre mer enn én RB. RLC opprettholder en buffer for hver RB, og hver buffer inneholder et sett av RLC-tjeningsdataenheter (SDU-enheter). Visse RLC-konfigurasjo-ner (men ikke alle) muliggjør segmentoppdeling av SDU-enhetene i protokolldataenhe- ter (PDU-enheter), og visse tillater kjedesammenføyning av SDU-enheter for å bygge opp PDU-enheter og visse tillater bruk av utfyllende PDU-enheter. I MAC-laget kan en MAC-topptekst legges til PDU for å danne en TB.

MAC-laget velger PDU-størrelser for en gitt TTI og anmoder om uttak av disse PDU-enheter fra RLC-laget. RLC segmentoppdeler og/eller kjedesammenføyer SDU-enhetene for å kunne tilfredsstille en MAC-ordre. MAC bygger så opp TB-enhetene, sender disse TB-enheter til det fysiske lag for å videresendes trådløst inn i den neste TTI.

For å kunne utføre TFC-valget er det på UE-siden visse standardfordringer som må føl-ges av UE. Disse fordringer er da sammenfattet nedenfor.

Det vil være ønskelig å frembringe en fremgangsmåte for TFC-valg, hvor det ikke vil være nødvendig for MAC å måtte bestemme den effekt som behøves av hver TFC i hver tidsluke.

SAMMENFATNING

Denne oppfinnelse gjelder en fremgangsmåte og en algoritme for TFC-valg, hvor da behovet for MAC til å bestemme den effekt som behøves av hver TFC-enhet i hver tidsluke er fjernet. Den følgende beskrivelse angir da MAC-prosedyren for å planlegge datatransmisjon på en slik måte at oppdelingen kan omfatte valg av en TFC-enhet som skal brukes, samt valg av RB-enheter for å betjenes.

Både UE- og betjenings-RNC- (S-RNC) sidene av en universell mobil telekommunika-sjonstjeneste (UMTS) og et tidsdelt dupleksnettverk (TDD) vil bli omtalt. Spesielt de strategier for TFC-valg og beslektede algoritmer vil bli omtalt.

Før valg av en TFC, må et sett av gyldige TFC-enheter fastlegges. Et sett vil da bli betegnet som kandidatsettet. Samtlige TFC-enheter i kandidatsettet må generelt tilfredsstille de følgende seks (6) regler, nemlig 1) må tilhøre TFCS, 2) må ikke inneholde flere bit-enheter enn det antall som kan overføres i en TTI, 3) må respektere TTI-kompatibiliteten (hvilket vil si at TF for en TrCH ikke kan forandres i midten av vedkommende TTI i TrCH), 4) må ikke være i blokkert tilstand, slik det vil bli definert nedenfor, 5) må være kompatibel med RLC-konfigurasjonen, og 6) må ikke kreve at RLC kan frembringe utfylling av PDU-enhetene. Hvis samtlige TFC-enheter i TFCS krever utfylling av PDU-enhetene kan denne siste fordring ignoreres. Foreliggende oppfinnelse gir løs-ninger i sammenheng med de tre (3) sistnevnte fordringer.

Blokkeringskriteriet er definert på følgende måte:

Når det gjelder en enkelt CCTrCH eller flere CCTRCH-enheter med gjensidig ekskluderende tidsluketildelinger, vil UE anse blokkeringskriteriet som oppfylt for en gitt TFC i en CCTrCH hvis innenfor tre (3) påfølgende puljer den anslåtte UE-overføringseffekt er større enn den maksimale UE-sendereffekt for minst én tidsluke som har sammenheng med CCTrCH i hver pulje.

I det tilfelle flere CCTrCH-enheter ikke har gjensidig ekskluderende tidsluketildelinger, forholder det seg slik at hvis for en gitt CCTrCH innenfor tre (3) påfølgende puljer den anslåtte UE-overføringseffekt større enn den maksimale UE-sendereffekt for minst én tidsluke i sammenheng med CCTrCH i hver pulje, så vil UE anse blokkeringskriteriet for en gitt TFC for å være oppfylt hvis bruk av denne TFC vil bringe den estimerte UE-sendereffekt til fortsatt å være større enn den maksimale UE-sendereffekt i minst én tidsluke som har sammenheng med vedkommende CCTrCH.

Med hensyn til avblokkeringskriteriet, må UE ikke anse avblokkeringskriteriet for en gitt TFC (som er blitt blokkert) å være oppfylt inntil bruken av denne TFC ikke vil med-føre at den anslåtte UE-sendereffekt vil bli større enn den maksimale UE-sendereffekt for alle opplink- (UL) tidsluker som har sammenheng med vedkommende TFC for minst tre (3) påfølgende puljer. Antallet påfølgende puljer kan være større enn eller mindre enn tre (3) uten at man derved avviker fra oppfinnelsens omfangsramme. Antallet påfølgende puljer kan for eksempel være så få som to (2) eller eventuelt fire (4) eller mer, hvor da tre (3) påfølgende puljer er foretrukket. Dette vil også være tilfelle for alle påfølgende kriterier for ikke-gj ensidige utelukkende tidslukearrangementer for UE-enheter og S-RNC-enheter.

MAC er oppdelt i MAC-c og MAC-d. MAC-c er da ansvarlig for felles kanaler, mens MAC-d er ansvarlig for tilegnede kanaler. På UE-siden, vil det være en enkelt TFC-enhet definert for den felles kanal, og TFC-valgt vil således ikke finne sted i UE MAC-c. På det RNC-siden finner TFC-valg sted i MAC-c og MAC-d.

RLC-konfigurasjonen spiller en viktig rolle ved TFC-valg. Alt etter den datamengde som er tilgjengelig for overføring, kan det hende at visse TFC-enheter i TFCS ikke vil passe sammen med RLC-konfigurasjonen.

Utfyllingskompatibiliteten (den som behøves for utfylling av PDU-enhetene) utgjør en

RLC-konfigurasjonssak. For å undersøke utfyllingskompatibiliteten må man undersøke om en TFC-enhet krever utfylling av PDU-enheter fra en transportkanal som bare frem-fører logiske kanalenheter som ikke kan frembringe utfylling av PDU-enhetene, (hvilket vil si logiske kanaler i RLC-TM (transparent modus)). Hvis dette forholder seg slik, så vil TFC ikke være kompatibel med vedkommende RLC-konfigurasjon og betraktes da som ugyldig.

Bemerk at det også finnes andre fordringer i sammenheng med RLC-konfigurasjonen. Imidlertid blir disse fordringer utprøvet under selve TFC-valgprosedyren. På grunn av at TFC-valgprosedyren maksimerer gjennomgangen for høyprioritetsdata, så vil TFC-valgprosedyren bli utført i en rekkefølge i samsvar med logisk kanalprioritet, og ikke per transportkanal. Hvis således fordringen til utfyllingskompatibilitet ikke skulle være tilfredsstilt, så må hele prosedyren gjentas (da uten valgt TFC) for det formål å frembringe en gyldig TFC. Dette er da grunnen til at utfyllingskompatibiliteten undersøkes før TFC-valget finner sted, slik at TFC-kandidatsettet derved reduseres.

Undersøkelsen for utfylling av PDU-kompatibilitet må fortrinnsvis utføres for hver enkelt TFC, og da basert på bufferopptattheten for de logiske kanaler som er tilordnet vedkommende transportkanal og den TF for denne transportkanal. Undersøkelsen med hensyn til utfyllende PDU- kompatibilitet blir utført bare i logiske kanaler som er konfigurert for transparent modus (RLC-TM).

TF bestemmer antallet TB-enheter og den TB-størrelse som behøves. Det første trinn går da ut på å bestemme hvor mange PDU-enheter som kan genereres av samtlige logiske kanaler innenfor vedkommende transportkanal. Denne bestemmelse må ta i betraktning TB-størrelsen og hvis segmentoppdeling er tillatt eller ikke i hver logisk kanal, og omfatter det følgende prosesstrinn:

a. Hvis segmentoppdeling er tillatt i den logiske kanal, så beregn n:

hvor n = SDU- størrelse / TB- størrelse,

og undersøk om n er et helt tall (hvilket da innebærer at antallet PDU-enheter multiplisert med PDU-størrelsen vil være lik SDU-størrelsen). i. hvis svaret er ja, så vil antallet PDU-enheter for vedkommende logisk kanal være lik n. ii. hvis svaret er nei, så vil antallet PDU-enheter for vedkommende logisk kanal være lik null.

b. Hvis segmentering er tillatt, undersøk om SDU-størrelsen er lik TB-størrelsen.

i. hvis svaret er ja, så vil antallet PDU-enheter for vedkommende logisk kanal være lik det totale antall SDU-enheter i denne logiske kanal og som er tilgjengelig for overføring. ii. hvis svaret er nei, så vil antallet PDU-enheter for denne logiske kanal være lik null.

Antallet PDU-enheter for denne transportkanal bestemmes da ved å summere antallet PDU-enheter for hver logisk kanal som er avbildet på denne transportkanal.

TFC kan være understøttet ut ifra utfylling av PDU-enhetene, hvis antallet PDU-enheter for vedkommende transportkanal er større eller lik antallet TB-enheter i TF. Tanken om et minimalt TFC-sett foreslått i normaltilfellene og brukt i samsvar med denne oppfinnelse vil bli forklart senere. Det minimale TFC-sett er da det sett som tillater overføring av én TB for transportkanalen med høyest prioritet og som har data for å sendes ut. Det minimale TFC-sett inkluderer alle TFC-enheter som har "kompatibel TF av minimums-størrelse" for en viss transportkanal og tomme TF-enheter for alle øvrige transportkanaler, hvor da denne "kompatible TF av minste størrelse" da er definert som: For erkjennelsesmodus - RLC (AM-RLC) logiske kanaler er "kompatibel TF med mini-mumsstørrelse" den TF som har en TB med "RLC-størrelse" og som da er lik størrelsen av RLC PDU.

For ikke-segmenterte logiske kanaler i transparent modus (TM-RLC) vil "kompatibel TF av minimumsstørrelse" være den TF som har en transportblokk med "RLC-størrelse" som er lik den betraktede RLC SDU-størrelse.

For TM-RLC i segmentert modus vil den "kompatible TF med minste størrelse" være den TF som er slik at antallet transportblokker multiplisert med "RLC-størrelsen" er lik den betraktede RLC SDU-størrelse.

For ikke-erkjent modus (UM-RLC) vil den "kompatible TF med minimumsstørrelse" være den TF som har én enkelt transportblokk (av hvilken som helst størrelse da det ikke foreligger noen restriksjoner på PDU-størrelsen for UM). Hvis det foreligger mer enn én TF-enhet med én enkelt transportblokk definert, så vil den "kompatible TF med minimumsstørrelse" være den som har minste transportblokkstørrelse.

I henhold til foreliggende oppfinnelse vil hver gang den maksimale sendereffekt er nådd inn en tidsluke, det fysiske lag sende en anmerkning om dette sammen med tidsluke-nummeret til MAC-laget om at den maksimale effekt er blitt oppnådd.

Hver gang MAC mottar en slik erkjennelse fra det fysiske lag om at den maksimale sendereffekt er oppnådd i tidsluken, så vil MAC fastlegge hvilken av CCTrCH-enhetene som har allokerte koder i den tidsluke som oppnår maksimal effekt, og markerer da slike CCTrCH-enheter som slike som har nådd maksimal effekt. Når en CCTrCH når maksimal effekt, så vil MAC undersøke om den bør eller ikke bør være gjenstand for "nedtrinn".

Trinn ned: Hver gang en CCTrCH når maksimal sendereffekt under tre (3) påføl-gende puljer, så vil MAC begrense kandidat TFC-settet til minimum TFC-settet i den neste felles TTI-grensesone (felles TTI for alle transportkanaler i CCTrCH).

Etter "nedtrinn" for MAC, vil den betrakte gjenvinningskriteriet for "opptrinn".

For trinn opp etter hver driftspulje for en CCTrCH ved minste TFC-sett, vil MAC forutsi den effekt som behøves ved fullt TFC-sett for vedkommende CCTrCH i den neste pulje. Hvis den forutsagte sendereffekt i alle tidsluker for CCTrCH er mindre enn den maksimalt tillatte UE-sendereffekt under tre (3) påfølgende puljer, så kan det fullstendige TFC-sett inkluderes i TFC-kandidatsettet. Ellers vil TFC-settet med minst verdi bli brukt.

Dette innebærer da at MAC enten vil tillate det fullstendige sett (med hensyn til effekt) eller også minimumssettet. Dette utgjør da en lavkostnadsløsning som unngår behovet for MAC til å bestemme den effekt som behøves av hver TFC i hver tidsluke.

Med hensyn til effektforutsigelse, så vil det for det formål å undersøke om det fullstendige sett kan understøttes tilstrekkelig å utprøve om den TFC som krever maksimal sendereffekt kan understøttes. På grunn av hastighetstilpasning og punktfjerning som anvendes i TDD-systemet, vil den TFC som krever maksimal sendereffekt kunne være forskjellig for hver tidsluke (hvilket vil si at hver tidsluke har i sammenheng med seg en TFC som krever maksimal sendereffekt). En løsning på dette problem går da ut på MAC skal kjenne den prosedyre som brukes av det fysiske lag for å kunne "fylle opp" tidsluker og koder. Den effekt som behøves for hver tidsluke vil avhenge av den TFC som brukes, da den utsendte effekt er en funksjon av beta- (/3) faktorer og antallet koder som brukes av TFC i vedkommende tidsluke, og hver TFC kan da ha en forskjellig betafaktor og en forskjellig datahastighet (og således forskjellig antall koder som brukes).

Det foreslås da her en løsning hvor MAC forutsier en utsendt effekt i hver tidsluke for CCTrCH ved å betrakte det foreliggende scenario i det verste tilfelle, nemlig ved å anta at alle de tildelte koder er blitt brukt i vedkommende tidsluke (samtlige koder selv om de skriver seg fra forskjellige CCTrCH-enheter) og at den høyeste betafaktor blant samtlige TFC-enheter i TFCS er blitt brukt.

Hvis det foreligger koder fra forskjellige CCTrCH-enheter i tidsluken, så vil forskjellige betafaktorer bli brukt for hver kode (hver kode vil da bruke den høyeste betafaktor for den tilordnede CCTrCH).

Den ovenfor angitte teknikk sørger for en lavkostløsning som da unngår behovet for at MAC må bestemme hvilken TFC som krever den høyeste effekt i hver tidsluke.

Med hensyn til utfyllingen av PDU-enhetene, slik som angitt ovenfor, behøver fordringene til utfyllingen av disse PDU-enheter bare å følges hvis ingen TFC-enheter er tilgjengelige blant de TFC-enheter som ikke krever noen utfylling av PDU-enheter. Hvis det finnes TFC-enheter tilgjengelig i TFC-kandidatsettet og som ikke krever utfylling av PDU-enheter, så bør med andre ord én av disse velges i stedet for å velge TFC som krever utfylling. Det bør bemerkes at for samtlige TFC-enheter som krever utfylling, vil PDU-enheter fra logiske kanaler ikke være i stand til å utføre utfylling av PDU (hvilket da gjelder RLC-TM-logiske kanaler) bli eliminert fra TFC-kandidatsettet, når RLC-konfigurasjonsfordringene blir utprøvd med hensyn på utfyllingskompatibilitet. I TFC-enheter som krever utfylling av PDU og befinner seg i TFC-kandidatsettet, vil da kreve utfylling av PDU-enheter fra logiske kanaler som kan utføre slik utfylling. Enten utfylling kreves eller ikke for PDU-enheter for en gitt TFC, blir da avhengig av RLC-bufferopptattheten (mengden av data som behøver å sendes). For det formål å bringe et sett med bare TFC-enheter som ikke krever utfylling av PDU, må alle TFC-enheter ut-prøves ved hver TTI. Dette er imidlertid en kostnadskrevende løsning.

Det foreslås da her å fastlegge om det finnes TFC-enheter som ikke krever utfylling av PDU-enheter under utførelse av TFC-velgeralgoritmen, slik det vil bli angitt nedenfor. Alle TFC-enheter som tilfredsstiller de fem fordringer som er angitt ovenfor vil således være en del av TFC-kandidatsettet, og den fordring som gjelder utfylling av PDU-enheten vil da være oppfylt, til enhver tid det er mulig ved hver TFC-valggjentagelse.

En valgt TFC må velges ut fra kandidatsettet og må da tilfredsstille de følgende kriterier (og da i den rekkefølge de er angitt): a) ingen annen TFC-enhet tillater overføring av data med høyere prioritet enn den valgte TFC-enhet, b) ingen annen TFC-enhet tillater overføring mer data fra de nærmeste lavere prioritetskanaler, og c) ingen annen TFC-enhet har lavere bit-hastighet enn den valgte TFC-enhet.

KORT BESKRIVELSE AV TEGNINGENE

Figurene la til og med ld omfatter et flytskjema for MAC-c TFC-utvalgt algoritmeimplementering,

figur 1 viser den måte hvorpå figurene IA til og med ID er anordnet for å danne flyt-skjemaet,

figurene 2A til og med 2D omfatter et flytskjema for MAC-d TFC-utvalgt algoritmeimplementering, og

figur 2 viser den måte hvorpå figurene 2A til og med 2D er anordnet for å danne flyt-skjemaet.

Figur 3 er et flytskjema for en RNC MAC-d SDU-størrelse av valgt prosedyre.

DETALJERT BESKRIVELSE AV FORETRUKNE UTFØRELSER

I beskrivelsen av de følgende utførelseseksempler har hver logisk kanal en tilordnet MLP (MAC Logical Channel Priority). MLP bestemmer prioriteten for den logiske kanal. De regler som vil bli beskrevet i den følgende paragraf er da basert på MLP-enheter: Det første viktige punkt er da at denne algoritmen gjentas per logisk kanals prioritet (forsøker å betjene de logiske kanaler som har høyst prioritet først), i motsetning til tj ening per transportkanal.

En løsning ved utførelse av TFC-valg er å bestemme hvor stor datamengde for hver prioritet hver TFC kan fremføre (med start med den høyeste prioritet), og derpå valg av én basert på fordringene (maksimalisering av gjennomgangen av data med høyere prioritet). Dette krever imidlertid at man går gjennom samtlige TFC-enheter i kandidatsettet.

En løsning som foreslås her er å identifisere den mengde data med høyeste prioritet som hver TFC kan fremføre, og derpå eliminere de som gir lavere gjennomgang fra vedkommende kandidatsett. Ved neste gjennomgang (for data med nest høyest prioritet) blir da bare det nye sett tatt i betraktning.

Det er imidlertid fremdeles behov for å tilfredsstille de "kandidatsetf-fordringer som er risset opp ovenfor angående utfyllende PDU-enheter. Ved eliminering av TFC-enheter fra settet før fullførelse av prosedyren i sin helhet, kan det hende at den endelige valgte TFC kan kreve oppfylling av PDU-enheter, og at prosedyren som helhet vil kreve å bli gjentatt uten den gitte TFC, inntil det finnes en TFC som ikke krever utfylling (og hvis ingen slik TFC blir funnet, vil den første valgte TFC bli brukt).

En løsning som foreslås her er å sikre at minst én TFC som ikke krever utfylling får bli på kandidatsettet. Slik som omtalt tidligere, kan det forekomme at visse kandidatsett ikke har noen slik TFC, og i et slikt tilfelle behøver ikke de ovenfor angitte "kandidatsetf-fordringer å bli tilfredsstilt.

Etter hver fjerning av TFC-enheter som ikke maksimaliserer gjennomgangen fra kandidatsettet, vil således kandidatsettet ikke inneholde minst én TFC som er "fylt opp"

(hvilket vil si at samtlige transportblokker blir brukt), så vil en TFC-enhet som ikke

krever utfylling av PDU-enheter (men faktisk ikke maksimalisere gjennomgangen) bli lagt til tilbake på kandidatsettet (merk at utfyllingskravet er sterkere enn gjennomgangs-kravet). Hvis det er mange TFC-enheter som vil kunne legges til kandidatsettet, vil da den som maksimaliserer gjennomgangen av datamengden med høyest prioritet bli valgt. Hvis mer enn én TFC som ikke krever utfylling har den samme gjennomgang for data med høyeste prioritet, så vil den TFC som maksimaliserer gjennomgangen for datamengden med nest høyest prioritet bli valgt. Denne regel vil da bli anvendt gjentatte ganger for samtlige prioritetsnivåer.

Det følgende er et eksempel på en iverksetting av MAC-d TFC-valgprosedyren.

Det følgende blir brukt i algoritmen nedenfor:

SDU-enheter fra logiske kanaler med prioritet p betraktes da som data med prioriteten p.

TFC-kandidatsettet vil da bli henvist til under betegnelsen TFCCan.

Bare logiske kanaler som har bufferomfang større enn null vil bli betraktet med henblikk på TFC-valg.

Algoritmen bør kjøres hvis vedkommende TFC-sett har gyldige TFC-enheter (TFC-enheter med datahastighet større enn null).

Den følgende algoritme (vist i figur 2) blir utført for MAC-d TFC-valget:

Etter å ha utført prosesstrinnene Sl til og med S3 for å utlede kandidatsettene (trinn Sl utføres bare ved UE-enheter), fortsetter rutinen på følgende måte:

S4: Initialiser p = 1.

S5: Undersøk om det forekommer minst én TFC med minst én TB tilgjengelig i TFC_Can (TFC-kandidatsettet).

a. Hvis ja, S5a, gå til trinn S6.

b. Hvis nei, S5b, gå til trinn S25 (alle TFC-enheter fylt, velg én).

S6: Velg en av de første TFC-enheter med minst én TB tilgjengelig fra TFC_Can (TFC-kandidatsettet).

S7: Undersøk hvis det finnes en logisk kanal med slik prioritet p at:

denne logiske kanal har tilgjengelige PDU-enheter som skal sendes ut, denne logiske kanal ikke blokkert for vedkommende TFC, og en transportkanal som er tilordnet denne logiske kanal har tilgjengelige TV-enheter.

a. Hvis ja, S7a, for å gå til S9 og velge vedkommende logiske kanal. Hvis det finnes mer enn én slik logisk kanal, velges én av disse vilkårlig. Gå så

til trinn S10.

b. Hvis nei, S7b, gå da til trinn Sl6 (ingen flere data med prioritet p).

S10: Undersøk om det foreligger en restriksjon angående PDU-størrelser for den valgte logiske kanal.

a. Hvis ja, S1 Oa, gå da til trinn S11 og undersøk om TB-størrelsen av transportkanalen er av samme omfang som PDU-størrelsen pluss MAC-overskriften.

i. Hvis ja, Sila:

1. Gå til S13 og velg PDU-enhet fra denne logiske kanal for å fylle opp så mange tilgjengelige TB-enheter som mulig i denne transportkanal.

2. Oppdater logisk kanalinformasjon på følgende måte:

a. Denne logiske kanal er blokkert for dette TFC-valg (logisk kanal allerede betjent). 3. Gå til Sl4, oppdatert TB-informasjon på følgende måte: a. Den brukte TB-enhet er ikke lenger tilgjengelig for dette TFC-valg.

4. Gå til trinn Sl4.

ii. Hvis nei, Sl lb,

1. Gå til S 8 hvor den logiske kanal betraktes som blokkert for denne TFC (PDU-enheter passer ikke sammen med

TFC).

2. Returner så til trinn S7.

b. Hvis nei, Sl Ob,

i. gå til S12 og fyll opp så mange TB-enheter som mulig i denne transportkanalen med bit-enheter fra denne logiske kanal.

ii. ved Sl4, oppdatert TB-informasjonen på følgende måte:

1. de brukte TB-enheter er ikke lenger tilgjengelige fra dette TFC-valg. iii. Denne logiske kanal betraktes som blokkert for dette TFC-valg (logisk kanal allerede betjent).

iv. Gå til trinn Sl5.

Ved Sl5, undersøk om alle TB-enheter i denne TFC er fylt.

a. Hvis ja, S15a, gå til trinn S16 (ikke mer plass i denne TFC).

b. Hvis nei, S15b, returner til trinn S7.

Ved Sl6, beregn den totale optimale gjennomgang for prioritetsdata p for denne TFC, og da på følgende måte: La Num Bits ( p, i, j) angi antall bit-enheter i prioritetsdata p som kan overføres til DCH /' ved bruk av TFC j (hvilket vil si TB-størrelsen ganger antallet TB-enheter som sendes ut, inkludert eventuelle RLC og/eller MAC-topptekst som er tilgjengelig og/eller utfyllings-bit-enheter).

Den normaliserte gjennomgang for DCH /' blir da beregnet som:

hvor TTI- lengde( i, j) er TTI-lengden av TF for en TrCH /' gitt TFC j.

Den totale optimale gjennomgang av prioritetsdata p for vedkommende CCTrCH er da summen av hver DCH-enhets normaliserte gjennomgang for disse prioritetsdata.

Ved Sl7, undersøk om det finnes flere TFC-enheter i TFCCan

a. Hvis ja, S17a, velg den neste TFC og gå tilbake til trinn S7.

b. Hvis nei, S17b, (hvis alle TFC-enheter er blitt undersøkt), gå til trinn S18.

Ved Sl8, er det blant samtlige TFC-enheter i TFC Can, minst én TFC, for eksempel TFC k, som gir den høyeste "totale optimale gjennomgang" for prioritet p, slik som:

Ta bort (hvilket vil si "gi avkall på") samtlige TFC-enheter som gir mindre gjennomgang enn denne ene TFC k fra TFC Can. Gå så til trinn Sl9.

Ved Sl9, undersøk om det finnes minst én TFC i TFC Can som har samtlige TB-enheter fylt.

a. Hvis ikke dette er tilfelle, S19a, gå til S20 og undersøk om det finnes minst én TFC som ikke tilhører TFC Can som har samtlige TB-enheter fylt.

i. hvis ja, S20a:

1. Gå til S21 og opprett et sett med alle de TFC-enheter som kalles TFC_NoPad (TFC-enheter som ikke krever utfylling). 2. Blant alle de TFC-enheter i TFC NoPad, velg den TFC-enhet som gir høyest "total optimal gjennomgang" for p prioritetsdata.

3. Legg til denne TFC-enhet til TFC_Can (kandidatsett).

ii. hvis nei, S20b, fortsett til trinn S22.

b. Hvis ja, S19b, fortsett til trinn S22 (det finnes allerede én TFC i TFC Can som ikke krever utfylling).

Ved S22, undersøk om alle TFC-enheter i TFC_Can er alle blitt TB-fylt.

a. Hvis ja, S22a, gå til trinn S25 (TFC-valg er utført).

b. Hvis nei, S22b, gå til trinn S23.

Ved S23, oppdatert p=p + 1.

Ved S24, undersøk omp < 8

a. Hvis ja, S24a, returner til trinn S5.

b. Hvis nei, S24b, gå til trinn S25 (etter at alle prioriteter er undersøkt, vil det velges én TFC).

Ved S25, undersøk om det finnes minst én TFC-enhet i TFC Can som ikke krever utfylling av PDU-enheter.

a. Hvis ja, S25a, gå til trinn S26.

b. Hvis nei, S25b, gå til trinn S27.

Ved S26, velg den TFC-enhet fra TFC Can som ikke krever utfylling. Hvis det finnes mer enn én TFC tilgjengelig som ikke krever utfylling, så velg blant disse en TFC som gir den minste datahastighet.

Ved S27, velg den TFC-enhet fra TFC Can som gir den minste datahastighet. Hvis det finnes mer enn én TFC tilgjengelig med samme datahastighet, velg da ut én tilfeldig. Fyll ut de uutfylte PDU-enheter i TFC med utfylte PDU-enheter fra RLC.

På RNC-siden, blir TFC-valget i MAC-laget utført både blant MAC-c- og MAC-d-enheter. MAC-c befinner seg i den regulerende RNC (C-RNC) og det er én MAC-c per celle, men MAC-d befinner seg i S-RNC og det finnes én MAC-d for hver UE.

For det formål å overføre data mellom S-RNC og C-RNC brukes strømningsregulering i fremover-tilgangskanalen (FACH). Strømningsregulering gjør det mulig for MAC-c (C-RNC) å regulere antallet SDU-enheter (kreditter) som hver MAC-d (S-RNC) kan sende ut for en tilordnet prioritet (FACH-prioritetsindikator). MAC-d velger en SDU-størrelse for hver prioritet, og sender vedkommende data til MAC-c. MAC-c bufirer disse data før de overføres.

Hvis kreditter = 0 (for eksempel på grunn av forstoppelse i C-RNC), vil S-RNC umid-delbart stoppe overføringen av SDU-enheter i MAC-c. Hvis kreditter = "ubegrenset", antyder dette at SRNC vil kunne overføre et ubegrenset antall av MAC-s SDU-enheter.

De følgende avsnitt beskriver TFC-utvalgsalgoritmen for MAC-c i RNC (figur 1) og SDU-størrelsesvalgalgoritmen for felles transportkanaler i RNC for MAC-d. TFC-velgeralgoritmen for RNC i MAC-d er av lignende art som den som gjelder for UE i MAC-d, med den unntagelse at på RNC-siden vil det ikke være noen begrensning når det gjelder effekt, og denne vil således ikke bli omtalt her. Den prosedyre som er omtalt i tidligere avsnitt gjelder MAC-d på både UE-siden og RNC-siden.

MAC-spesifikasjonen spesifiserer ikke noen fordringer for TFC-utvelgelsen på RNC. For at UE skal kunne dekode vedkommende data korrekt vil det imidlertid være visse fordringer som må følges. Disse fordringer er da sammenfattet nedenfor.

Før utvelgelse av en TFC-enhet for tilfellet MAC-c, må settet av gyldige TFC-enheter bli opprettet. Dette sett vil da bli henvist til som "kandidatsettet". Alle TFC-enheter i kandidatsettet må da:

1. tilhøre TFCS,

2. respektere TTI-kompatibiliteten - transportformatet (TF) for en TrCH kan ikke forandre i midten av TTI for vedkommende TrCH, og 3. være kompatibel eller samordnet med RLC-konfigurasjonen.

Den valgte TFC må velges ut fra kandidatsettet og må tilfredsstille de følgende kriterier i den rekkefølge som de er angitt nedenfor: 1. Ingen annen TFC tillater overføring av flere data med høyeste prioritet enn den valgte TFC. 2. Ingen annen TFC tillater overføring av flere data fra de logiske kanaler med den siste lavere prioritet. Dette kriterium anvendes periodisk gjentatte ganger for de gjenværende prioritetsnivåer.

3. Ingen annen TFC har en lavere bit-hastighet enn den valgte TFC.

4. Må respektere "først inn først ut" innenfor hver prioritet for de data som mottas fra MAC-d.

For prosedyren i forbindelse med MAC-c, blir de data som mottas fra MAC-d bufret i MAC-c. Dette kan gjøres ved enten å ha én kø per UE, eller én eneste kø for samtlige UE-enheter, eller eventuelt én kø for hver prioritet. Det foreslås å ha én kø per prioritet, og ved å gjøre dette vil det da bli lettere å bibeholde reguleringsopplegget med først inn først ut. Den første tilnærmelse vil kreve at bufferen tidsstemples for å kunne bibeholde denne reguleringsordning, mens den andre tilnærmelse vil kreve koordinering av priori-tetene.

For blokkeringsformål vil MAC-c kunne planlegge data på hvilken som helst av de FACH-enheter som er avbildet på de kodede sammensatte kanaler. Hvis data fra en logisk kanal blir sendt på en transportkanal med TTI av lengde "t", så vil data fra samme logiske kanal ikke sendes ut på andre transportkanaler, under den tidsvarighet som til-svarer "t", da dette kan føre til problemer i forbindelse med manglende rekkefølge i mottagersiden RLC (hvilket vil si UE-siden).

For en CCCH (felles reguleringskanal) kan dette problem løses ved å blokkere kanalen for overføring under en tidsvarighet som er lik TTI for den siste overførende transportkanal (hvilket vil si at data fra denne logiske kanal ikke vil bli sendt ut under vedkommende TTI).

For bufrede data (data mottatt fra MAC-d) kan dette problem løses ved å blokkere data med en gitt prioritet. Denne utførelse vil imidlertid lede til underutnyttelse av et systems tilganger, da en større datamengde vil bli blokkert selv om dette ikke vil være nødven-dig, og vil da føre til forsinkelse når det gjelder overføring av data fra andre UE-enheter med samme prioritet. For å unngå dette, vil data med en viss prioritet fra en UE bli blokkert under en tidsperiode på "t", hvis data fra denne UE og med denne prioritet blir sendt ut på en transportkanal med TTI-perioden "t". Dette øker da den datamengde som kan sendes ut fra samtlige UE-enheter og vil da også løse problemet med manglende rekkefølge.

Med hensyn til utfylling, kan MAC-c forlange utfylling av PDU-enheter bare fra RLC-enheten i CCCH. Hvis CCCH er blokkert og hvis utfylling av PDU-enheter er påkrevet, vil MAC-c bare forlange utfylling av PDU-enheter fra RLC.

Det følgende angir et utførelseseksempel for en implementering av utvelgelsesprosedyren i forbindelse med RLC i MAC-c TFC.

I denne MAC-c-algoritme, vil algoritmen være slik at:

En buffer med overførte PDU-enheter bli henvist til som "logisk kanal". TFC-kandidatsettet vil bli betegnet som TFC Can

Bare logiske kanaler som har buffer-opptatthet større enn null vil kunne

tas i betraktning for TFC-utvelgelsen

Denne algoritme bør kjøres bare hvis TFC-settet har gyldige TFC-enheter

(TFC-enheter med datahastighet større enn null)

Under henvisning til figurene IA til og med ID, vil de følgende prosesstrinn bli utført i forbindelse med utvelgelsesalgoritme for MAC-c TFC:

Sl: Initialiser p = 1

S2. Undersøk om det finnes minst én TFC-enhet med minst én TB tilgjengelig i TFC Can (TFC-kandidatsettet).

a. Hvis ja, S2a, gå til trinn S3.

b. Hvis nei, S2b, gå til trinn S26 (samtlige TFC-enheter fylt, vil velge én av disse).

S3: Velg den første TFC-enhet med minst én TB tilgjengelig fra TFC_Can (TFC-kandidatsettet).

S4: Undersøk om det finnes en logisk kanal med prioritet p slik at: den logiske kanal har tilgjengelig PDU-enheter for å sendes ut, hvis den valgte logiske kanal er en CCCH, så er den logiske kanal ikke blokkert for de valgte TFC-enheter. Den valgte logiske kanal består av overførte PDU-enheter, undersøk da om det finnes minst én PDU som ikke er blokkert for den valgte TFC, og om den valgte logiske kanal ikke er blokkert for denne TFC,

a. Hvis svaret er ja, S4a, gå da til S5 og velg denne logiske kanal. Hvis det finnes mer enn én slik logisk kanal, velg da én av disse tilfeldig. Gå til trinn S6. b. Hvis nei, S4b, gå da til S17 (ingen flere data med prioritet p).

S6: Undersøk om det foreligger en begrensning med hensyn til PDU-størrelser for den valgte kanal.

a. Hvis svaret er ja, S6a, gå da til S7 og undersøk om det finnes en TB som er tilgjengelig og er av samme størrelse som PDU-størrelsen pluss MAC-topptekst.

i. Hvis ja, S7a, gå da til S8 og:

1. Velg den transportkanal som har TB-størrelse. Hvis mer enn én er tilgjengelig, velg da en transportkanal som gir maksi-

malt tilgjengelig datahastighet, slik som følger:

MAX {(antall tilgjengelige TB-enheter)/TTI-størrelse}; og 2. Velg PDU-enheter som ikke er blokkert fra denne logiske

kanal for å fylle opp så mange tilgjengelige TB-enheter som mulig i transportkanalen. PDU-utvelgelsen må respektere FIFO, blokkerte PDU-enheter må utelukkes.

3. Oppdater bufferinformasjon på følgende måte:

a. PDU-enheter er ikke tilgjengelige for denne TFC utvelgelse, gå da tilbake til Sil og:

Oppdatert TB-informasjon på følgende måte:

a. De brukte TB-enheter er ikke lenger tilgjengelig for denne TFC-utvelgelse.

Gå så til trinn Sl4.

ii. Hvis nei, S7b, gå til S9 for å utføre:

1. Den logiske kanal anses som blokkert for denne TFC (da

PDU-enhetene ikke passer sammen med TFC).

2. Returner så til trinn S4.

b. Hvis nei, S6b, gå til Sl0 og:

i. Velg en transportkanal som gir en maksimal tilgjengelig datahastighet, slik som følger: MAX {(antallet tilgjengelige TB-enheter<*>TB-størrelse)/TTI-størrelse}. ii. Fyll opp så mange TB-enheter som mulig i denne transportkanal med bit-enheter fra denne logiske kanal.

iii. Oppdater bufferinformasjon slik som følger:

1. bit-enheter som er brukt er ikke tilgjengelig lenger for denne TFC-utvelgelse og bør ikke telles opp i bufferinnholdet. iv. Gå så til trinn Sil for å oppdatere TB-informasjon på følgende måte: 1. Brukte TB-enheter er ikke lenger tilgj engelig for denne TFC-utvelgelse.

v. Gå så til trinn S12.

2. Hvis den valgte logiske kanal er en CCCH, Sl2a, gå til

S14og:

Betrakt CCCH som å være blokkert for denne TFC under denne TFC-utvelgelse (under de neste trinn av TFC-utvelgelsen for denne TTI).

3. Hvis den valgte logiske kanal ikke er en CCCH, Sl2b, gå

da til S13 for å fastlegge:

Hvis den valgte logiske kanal består av overførte PDU-enheter, Sl3a, gå da til Sl5, for å fastlegge:

- samtlige av de øvrige PDU-enheter som:

- befinner seg i samme buffer (hvilket vil si er av samme prioritet) og - har samme UE ID som UE ID for de valgte PDU-enheter vil da bli betraktet som blokkert for denne TFC (under denne TFC-enhets neste trinn for TFC-utvelgelsen i forbindelse med denne TTI). 5. Hvis den valgte logiske kanal ikke utgjøres av overførte PDU-enheter, Sl3b, gå da direkte til Sl6.

Ved Sl6, undersøk om samtlige TB-enheter i denne TFC er fylt.

a. Hvis ja, Sl 6a, gå da til trinn S17 (ikke mer plass i denne TFC).

b. Hvis nei, Sl6b, returner til trinn S4.

Ved Sl7, beregn den totale optimale gjennomgang for data med prioritet p for denne TFC, og da på følgende måte: La Num_ Bits( p, i, j) angi antallet bit-enheter i data med prioritet p og som kan overføres på FACH /' ved bruk av TFC j (hvilket vil si TB-størrelsen ganger antallet TB-enheter som sendes, inkluderende enhver RLC og/eller MAC-topptekst som er gyldig og/eller utfyllingsbit-enheter).

Den normaliserte gjennomgang for FACH /' blir da beregnet som:

hvor TTI- lengden( i, j) er TTI-lengden av TF for TrCH /' i den gitte TFC j.

Den totale optimale gjennomgang for data med prioritet p i CCTrCH (S-CCPCH) er da summen av hver FACH-enhets normaliserte gjennomgang for disse prioritetsdata.

Ved Sl8, undersøk om det finnes flere TFC-enheter i TFC Can.

a. Hvis svaret er ja, Sl 8a, velg den neste TFC og returner til trinn S4.

b. Hvis nei, S18b, (alle TFC-enheter er blitt utprøvet), gå til trinn S19.

Ved Sl9, er det blant alle TFC-enheter i TFC Can minst én TFC, for eksempel TFC k, som gir den høyeste "totale optimale gjennomgang" for prioritet p, slik som da:

Avvis alle TFC-enheter som gir mindre gjennomgang enn den valgte TFC k fra TFCCan.

Ved S20, undersøk om det finnes minst én TFC i TFC Can som har samtlige TB-enheter fylt (vil ikke kreve utfylling).

a. Hvis dette ikke er tilfelle, S20a, gå til S21 og undersøk om det finnes i det minst én TFC som ikke tilhører TFC Can og som har alle TB-enheter fylt.

i. Hvis svaret er ja, S21a, gå da til S22 for å:

1. opprette et sett med alle de TFC-enheter som angis ved

TFCNoPad (TFC-enheter som ikke krever utfylling),

2. blant samtlige TFC-enheter i TFC NoPad, velg den TFC-enhet som gir den høyeste "totale optimale gjennomgang" for data med prioritet p, og

3. legg til vedkommende TFC-enhet til TFC Can.

ii. Hvis ikke dette er tilfelle, S21 b, fortsett til trinn S23.

b. Hvis svaret er ja, S20b, fortsett til trinn S23 (det finnes allerede én TFC-enhet i

TFC Can som ikke krever utfylling).

Ved S23, undersøkt samtlige TFC-enheter i TFC_Can som har samtlige TB-enheter fylt.

a. Hvis ja, S23a, gå til trinn S26 (TFC-utvelgelsen er gjort).

b. Hvis svaret er nei, S23b, gå til trinn S24.

Ved S24, oppdatert p = p+1, gå så til S25 for å undersøke om p<=8.

a. Hvis svaret er ja, S25a, returnert til trinn S2.

b. Hvis svaret er nei, S25b, gå til trinn S26 (alle prioriteter er undersøkt, velg en TFC).

Ved S26, undersøk om det finnes minst én TFC i TFC Can som ikke krever utfylling av PDU-enheter.

a. Hvis svaret er ja, S26a, gå til trinn S27.

b. Hvis svaret er nei, S26b, gå til trinn S28.

Ved S27, velg den TFC fra TFC Can som ikke krever utfylling. Hvis det foreligger mer enn én slik TFC som er tilgjengelig og som ikke krever utfylling, velg da blant disse den TFC-enhet som gir den minste datahastighet.

Ved S28, velg den TFC-enhet fra TFC Can som gir den minste datahastighet. Hvis det er mer enn én TFC tilgjengelig med samme antall bit-enheter, velg da én av disse tilfeldig. Fyll ut de ufylte PDU-enheter i denne TFC med utfyllende PDU-enheter fra RLC

(CCCH).

Etter enten S27 eller S28, gå til S29.

Ved S29, og i det tilfelle CCCH brukes i denne TFC, anse da CCCH å være blokkert for samtlige TFC-enheter under en tidsperiode som er lik TTI for den valgte transportkanal.

Ved S30, og for hver logisk kanal med overførte PDU-enheter (hvilket vil si for hver buffer med en spesifikk prioritet) og som er brukt i den valgte TFC-enhet, vil hver PDU som befinner seg i denne buffer og som har UE ID lik vedkommende UE ID for en PDU som er valgt for denne TFC bli betraktet som blokkert for samtlige TFC-enheter for en tidsperiode som er lik vedkommende TTI for den valgte transportkanal for denne logiske kanal.

Figur 1, som viser et flytskjema for den valgte algoritmeimplementering for MAC-c TFC, omfatter flere prosesstrinn enn algoritmen i figur 2.

MAC-d kan være konfigurert med et sett av tillatte SDU-størrelser (de tillatte størrelser er avhengig av TFCS for S-CCPCH (sekundær felles reguleringskanal)) for hver felles transportkanal-prioritetsindikator (FACH-prioritet). En FACH-flytreguleringspulje blir brukt av C-RNC for å regulere brukerdatastrømmen. Denne kan være generert som res-pons på en FACH-kapasitetsforespørsel eller ved et hvilket som helst annet tidspunkt. FACH-strømningsreguleringspuljen skal da inneholde antallet kreditter for S-RNC MAC-d enheten tillates å overføre.

For hver logisk kanal, foreligger det en tilordnet FACH-prioritet. MAC-d velger en SDU-størrelse (innefra det konfigurerte sett) for hver logisk kanal, og da i avhengighet av den logiske kanals bufferopptatthet (BO) antallet tilgjengelige kreditter for vedkommende FACH-prioritet. MAC-c SDU-enheter av samme størrelse og med samme FACH-prioritet kan være oversendt innenfor samme FACH-datapulje.

SDU-størrelsesvalget for en logisk kanal avhenger av den tilsvarende RLC-konfigurasjon, den logiske kanals BO, samt antallet tilgjengelige kreditter for denne FACH-prioritet.

For en gitt BO kan det finnes et varierende antall kreditter som behøves for hver SDU-størrelse. Hvis antallet påkrevede kreditter multipliseres med SDU-størrelsen ikke nøy-aktig er tilpasset BO, så vil den kreve en viss administrering (RLC-utfylling). En SDU-størrelse som nedsetter denne administrering til et minimum blir da valgt for det formål å gjøre gjennomgangen størst mulig. Dette kan imidlertid kreve valg av en størrelse som medfører et økt antall kreditter. Det bør imidlertid bemerkes at jo større antall kreditter som forespørres, jo flere ganger vil MAC-toppteksten bli lagt til, hvilket vil føre til større administrering.

Da det ikke finnes noen ligning i lukket form for å bestemme hvilket valgalternativ som er det beste (nemlig minimalisering av RLC-utfyllingsadministrasjonen eller minimalisering av antallet kreditter for en gitt BO-verdi), vil den sistnevnte mulighet (minimalisering av antallet kreditter som brukes for en gitt BO) bli valgt på grunn av at ved valg av en størrelse som krever et mindre antall kreditter, vil flere kreditter bli tilgjengelig for fremtidig bruk, hvilket viser seg å være ytterst nyttig i et fullstendig belastet system. Også i det tilfelle BO er meget stor sammenlignet med SDU-størrelsene, så vil denne løsning minimalisere både administreringen og antallet kreditter.

I det følgende er et eksempel på en implementering av utvelgelsesprosedyren for størrel-sen av RNC MAC-d SDU.

For det formål å sende SDU-enheter til MAC-c, vil MAC-d følge den etterfølgende prosedyre (se Figur 3):

S1: Velg den høyeste prioritet (hvilket vil si den høyeste MLP)

S2: Velg en logisk kanal med denne prioritet. I det tilfelle det foreligger flere enn én

logisk kanal med vedkommende prioritet, velg én av disse tilfeldig.

S3: Basert på bufferinnholdet av den logiske kanal, velg den SDU-størrelse som skal brukes for denne logiske kanal på følgende måte: Basert på antallet "kreditter" som er tilgjengelig i MAC-d, bestem den mengde informasjons-bit-enheter som kan overføres ved bruk av hver PDU-størrelse (ikke innbefattet utfyllings-bit-enheter). For hver PDU-størrelse er da mengden av informasjons-bit-enheter gitt ved:

MIN (BO, kreditter x PDU-størrelse).

Velg den PDU-størrelse som gir den største mengde informasjons-bit-enheter. Hvis mer enn én PDU-størrelse gir den samme maksimale mengde informasjons-bit-enheter, velg da den PDU-størrelse som gir minste antall kreditter som er påkrevet for å sende denne minste maksimale mengde av informasjons-bit-enheter. Hvis mer enn én PDU-størrelse gir det samme minimale antall kreditter, velg da den minste PDU-størrelse.

S4: Velg de SDU-enheter som skal sendes ut fra denne logiske kanal. Mange SDU-enheter kan sendes ut, men bare én eneste SDU-størrelse er tillatt for denne logiske kanal. De tillatte kreditter må respekteres ved valg av antallet SDU-enheter som skal sendes.

S5: Undersøk om det finnes flere logiske kanaler med samme prioritet og om det fremdeles er tilgjengelige kreditter for vedkommende prioritet.

Hvis svaret er ja, S5a, returnert til S2.

Hvis snaret er nei, S5b, gå til S6.

Ved S6, bygg en "lur" FACH-datapulje for hver SDU-størrelse (og da for en gitt prioritet). Bemerk at SDU-størrelsen er den samme for enhver gitt logisk kanal, men kan være forskjellig for forskjellige logiske kanaler med samme prioritet. Hvis det således er n logiske kanaler med vedkommende prioritet vil det være minst én (1) og høyst n FACH-datapuljer (nemlig én for hver størrelse). Det bør også bemerkes at rekkefølgen for SDU-enhetene for hver logisk kanal må opprettholdes inne i vedkommende datapulje.

Ved S7, undersøk om det finnes flere logiske kanaler tilgjengelig.

Hvis svaret er ja, S7a, gå da til S8 for å velge den nest høyeste prioritet som er tilgjengelig og gå så tilbake til S2.

Hvis svaret er nei, S7b, så er prosedyren avsluttet.

I de tidligere avsnitt, er den informasjon som behøves for å utføre TFC-utvelgelsen blitt beskrevet. For vekselvirkning mellom MAC og RLC, behøves både logisk kanalmodus-basert konfigurasjonsinformasjon (statisk) og bufret datainformasjon (dynamisk).

Ut ifra MAC-protokollspesifikasjonen (3GPP TS 25.321) og RLC-protokollspesifikasjonen (3GPP TS 25.322) forsyner RLC og MAC med bufferutfylling (BO), som da utgjør den totale datamengde som er bufret i RLC-enheten. Da imidlertid MAC behøver mer informasjon fra RLC for å kunne utføre TFC-utvelgelsen, angir RLC-protokollspesifikasjonen (3GPP TS 25.322) også at RLC behøver å forsyne MAC med "RLC-enhetsinfo". RLC-protokollspesifikasjonen (3GPP TS 25.322) spesifiserer ikke hva vedkommende "RLC-enhetsinfo" må inneholde.

I dette avsnitt vil innholdet "RLC-enhetsinfo" bli beskrevet. Da denne informasjon brukes til å "avgrense" utvelgelsen av TFC, tegnes denne informasjon som TFC-avgrensningsvariable.

Disse TFC-avgrensningsvariable gir informasjon om de PDU-enheter og/eller SDU-enheter som er bufret i den RLC som er tilgjengelig for overføring i den neste TTI.

For ikke-erkjente og gjennomsiktige modi, spesifiserer MAC PDU-størrelsen ut ifra foreliggende TTI-basis. RLC kan derfor ikke frembringe PDU-enheter forut for TTI, og bare informasjon basert på de bufrete SDU-enheter kan frembringes av RLC forut for overføringen. For en kvitteringsmodus er PDU-størrelsen fastlagt, og informasjon basert på de bufrete PDU-enheter kan derfor frembringes av RLC.

Det bør bemerkes at de foreliggende TFC-avgrensningsvariable kan inneholde selve RLC-modus. Da imidlertid frembringelse av RLC-modus krever at MAC må gjøre anta- geiser om de RLC-bufrede datas særtrekk basert på den foreliggende RLC-modus, så vil i stedet vedkommende datasærtrekk selv bli frembragt.

Da TFC-utvelgelsen avhenger av den datamengde som er tilgjengelig for overføring innenfor en gitt TTI, så vil de foreliggende TFC-avgrensningsvariable omfatte SDU/PDU-størrelse og antallet SDU/PDU-enheter som er bufret i RLC.

Alt etter RLC-modus og også for det formål å unngå dataoverføringskonflikter, vil bare noen av de data som er bufret i RLC være tilgjengelig for overføring.

For samtlige RLC-modi må størrelsene og UE Id-typene for samtlige av de PDU-enheter som overføres til MAC innenfor én TTI være den samme. Den informasjon som rap-porteres til MAC må garantere at TFC er valgt ut slik at disse to restriksjoner ikke over-skrides. Bare informasjon angående SDU-enheter og PDU-enheter som er av samme størrelse og UE Id-type er da angitt. Da data må overføres i den rekkefølge de er blitt mottatt, så vil RLC bare rapportere antallet av påfølgende SDU/PDU-enheter i RLC-overføringsbufferen (start fra den eldste SDU/PDU) og som er av samme størrelse og er av samme UE Id-type.

For transparent modus og segmentert konfigurering, bare én slik SDU-enhet kan overfø-res per TTI, og RLC vil derfor rapportere at bare én SDU er tilgjengelig for overføring.

For kvitteringsmodus, og i avhengighet av RLC-konfigurasjonen, vil en logisk kanal kunne fremføre RLC-SDU-data (mottatt fra det øvre lag) og/eller RLC jevnbyrdige re-guleringsdata. Mengden av tilgjengelige PDU-data for en kvitteringsmodus i logisk kanal er derfor avgrenset av den type RLC-data den kan understøtte. For kvitteringsmodus i logiske kanaler som understøtter overføring av RLC SDU-enheter (mottatt fra det øvre lag), er mengden av tilgjengelige PDU-data også begrenset av størrelsen av de logiske kanalers RLC-overføringsvindu. Det bør bemerkes at størrelsen av RLC-overfø-ringsvinduet er statistisk konfigurert i RLC.

For TFC-valg, behøver MAC å kjenne til hvor meget av TB som tas opp av MAC-toppteksten. Da TB-topptekststørrelsen avhenger av UE Id-typen, så vil de TFC-begrens-ningsvariable også inneholde vedkommende UE Id-type. Det bør bemerkes at MAC-protokollspesifikasjonen (3GPP TS 25.321) angir at UE Id-typen er angitt av RLC til MAC for hver dataoverføring.

Da TFC inneholder informasjon angående antallet PDU-enheter som MAC må forlange fra RLC når MAC behøver å vite om de SDU-enheter som er bufret i RLC kan oppdeles i segmenter eller ikke dette er tilfelle. De TFC-avgrensningsvariable inkluderer derfor en segmenteringsindikator. Bemerk at denne indikator blir statisk konfigurert i RLC.

Som nevnt i de tidligere avsnitt, må utfyllingsinformasjon være kjent av MAC for at denne skal være i stand til å utføre TFC-utvelgelse. Da utfylling bare er understøttet i disse RLC-modi (bare i UM- og AM-modi) er PDU-utfyllingsindikator også inkludert i TFC-avgrensningsvariable.

Det som er angitt ovenfor er en beskrivelse av en fremgangsmåte og eksempler på algoritme for prosedyrer som brukes av MAC-laget for TFC-utvelgelse med det formål å planlegge dataoverføring. Den 3GPP UMTS som er angitt ovenfor i sammenheng med oppfinnelsen er da bare gitt som et eksempel, og oppfinnelsen kan modifiseres til å betjene andre beslektede standarder og dataoverføringsmodi. Alle slike modifiseringer er angitt for å ligge innenfor omfangsrammen for foreliggende oppfinnelse.

Blokkerings- og avblokkeringsteknikker som er beskrevet ovenfor vil være ytterst for-delaktige for bruk i et trådløst nettverk som utnytter tidsdelt dupleks (TDD) for sine kommuniseringer. De ovenfor angitte teknikker kan imidlertid også anvendes i et frek-vensdelnettverk av duplekstype (FDD).

Alle øvrige aspekter ved oppfinnelsen kan anvendes i sammenheng med samtlige drifts-modi for UMTS.

Claims (30)

1. Fremgangsmåte for å planlegge dataoverføring i et trådløst kommunikasjonsnettverk og som eliminerer et behov for å bestemme effektfordringer for hver transportformatkombinasjon (TFC) i hver tidsluke, hvor dette nettverk omfatter minst et fysisk lag og et mediumstilgangskontrollag (MAC),karakterisert vedat fremgangsmåten omfatter: angitte fysiske lag, overvåkning av overført effekt i en tidsluke, og utsendelse av en bekreftelse til MAC-laget om at maksimal effekt er blitt oppnådd, og da sammen med vedkommende tidslukes nummer, hvor da det angitte MAC-lag er innrettet for: å bestemme hvilke kodede sammensatte overføringskanaler (CCTrCH-enheter) har fått tildelt koder i vedkommende tidsluker hvor maksimal effekt er oppnådd, markering av slike CCTrCH-enheter om at de har nådd maksimal effekt, og begrensning av en kandidat- eller transportformatkombinasjon (TFC) innstilt til en minimal TFC innenfor en nærmest påfølgende felles transittidsintervallbegrensning (TTI).

2. Fremgangsmåte som angitt i krav 1,karakterisert vedat begrensningstrinnet videre omfatter: detektering at den maksimale overføringseffekt har funnet sted innenfor et gitt antall påfølgende puljer før begrensning av det angitte TFC-kandidatsett.

3. Fremgangsmåte som angitt i krav 2,karakterisert vedat antallet påfølgende puljer fortrinnsvis er tre (3).

4. Fremgangsmåte som angitt i krav 1,karakterisert vedat den videre omfatter: det angitte MAC-lag, forutbestemmelse av en effekt som behøves av det fulle TFC-sett for en CCTrCH og som vil være påkrevet i den neste pulje og som vil gjelde for hver driftspulje for en CCTrCH i det minimale TFC-sett, sammenligning av den forutbestemte overføringseffekt i samtlige tidsluker for vedkommende CCTrCH, og inkludering av det fullstendige TFC-sett i TFC-kandidatsettet når den forutsagte overføringseffekt i samtlige tidsluker for CCTrCH er mindre enn den maksimalt tillatte UE-overføringseffekt.

5. Fremgangsmåte som angitt i krav 4,karakterisert vedat sammenligningstrinnet omfatter utførelse av dette sammenligningstrinn for et gitt antall påfølgende puljer for det formål å inkludere det fullstendige TFC-sett i TFC-kandidatsettet.

6. Fremgangsmåte som angitt i krav 5,karakterisert vedat det gitte antall påfølgende puljer er tre (3).

7. Fremgangsmåte som angitt i krav 1,karakterisert vedat forutbestemmelse av overføringseffekten i hver tidsluke omfatter betraktning av et verste tilfellescenario ved å anta at samtlige tildelte koder er blitt brukt i vedkommende tidsluke, selv om de skriver seg fra forskjellige CCTrCH-enheter.

8. Fremgangsmåte som angitt i krav 7,karakterisert vedat en betafaktor som brukes for hver kode er den høyeste betafaktor for vedkommende CCTrCH blant samtlige TFC-enheter i det TFC-sett som brukes.

9. Fremgangsmåte som angitt i krav 1,karakterisert veden TFC velges fra kandidatsettet på en slik måte at: ingen annen TFC tillater overføring av høyere prioritetsdata i en valgt TFC, ingen annen TFC tillater overføring av flere data fra den nærmeste av kanalene med lavere prioritet, og ingen annen TFC har en lavere bit-hastighet enn den valgte TFC.

10. Fremgangsmåte som angitt i krav 1,karakterisert vedat det angitte MAC-lag utgjøres av en MAC-dedikert kanal av type MAC-d.

11. Fremgangsmåte som angitt i krav 1,karakterisert vedat tilførselstrinnet videre omfatter: tilførsel av det fullstendige TFC-sett bare i det tilfelle dette fullstendig TFC-sett kan understøttes.

12. Fremgangsmåte som angitt i krav 1,karakterisert vedat det angitte nettverk utnytter en tidsdelt dupleksteknikk (TDD) for kommunikasjon.

13. Fremgangsmåte for planlegging av dataoverføring i et trådløst kommunikasjonsnettverk, slik at behovet for å bestemme utfordringer for transportformatkommunikasjon (TFC) i hver tidsluke elimineres, hvor dette nettverk inkluderer minst et fysisk lag og et mediumstilgangskontrollag (MAC),karakterisert vedat fremgangsmåten omfatter: angitte fysiske lag, overvåkning av overført effekt i en tidsluke, og utsendelse av en angivelse til MAC-laget om at maksimal effekt er blitt oppnådd, og da sammen med vedkommende tidslukes nummer, og det angitte MAC-lag velger ut en TFC fra enten et fullstendig TFC-sett eller et minimalt TFC-sett basert på en effektangivelse fra det fysiske lag.

14. Fremgangsmåte som angitt i krav 13,karakterisertv e d at MAC-laget utgjøres av en MAC-tildelt kanal av type MAC-d.

15. Apparat for planlegging av dataoverføring i et trådløst kommunikasjonsnettverk hvor behovet for å bestemme effektfordringer er eliminert, og dette nettverk minst et fysisk lag og et mediumstilgangskontrollag (MAC),karakterisertv e d at apparatet omfatter: det angitte fysiske lag som da er utstyrt med: midler for å overvåke overført effekt i en tidsluke, og midler for å sende ut en anvisning til MAC-laget om at den maksimale effekt er blitt oppnådd, og da sammen med nummeret på vedkommende tidsluke, idet MAC-laget omfatter: midler for å bestemme hvilke kodede sammensatte overføringskanaler (CCTrCH-enheter) har fått tildelt koder i en tidsluke som har oppnådd maksimal effekt, midler for å markere slike CCTrCH-enheter som har nådd denne maksimale effekt, og midler for å avgrense et kandidat- eller transportformatkombinasjonssett (TFC) til et minimalt TFC-sett innenfor et nærmest påfølgende transittidsintervallavgrensning (TTI).

16. Apparat som angitt i krav 15,karakterisert vedat midlene for begrensning videre omfatter: midler for å detektere at den maksimale overføringseffekt har funnet sted for et gitt antall påfølgende puljer, og midler som reagerer på de angitte detekteringsmidler for derved å begrense det angitte TFC-kandidatsett.

17. Apparat som angitt i krav 16,karakterisert vedat midlene for å detektere antallet påfølgende puljer fastlegger at maksimal overført effekt har funnet sted i tre påfølgende puljer (3).

18. Apparat som angitt i krav 15,karakterisert vedat det angitte MAC-lag er en MAC-tilordnet kanal type MAC-d.

19. Apparat som angitt i krav 15,karakterisert vedat det angitte nettverk utnytter en tidsdelt dupleksteknikk (TDD) for kommunikasjoner.

20. Apparat som angitt i krav 15,karakterisert vedat det videre omfatter: det angitte MAC-lag som da inneholder: midler for å forutsi den effekt som behøves for et fullstendig TFC-sett for en CCTrCH i den neste pulje og som reagerer på hver driftspulje for en CCTrCH for det minimale TFC-sett, midler for å sammenligne den forut fastlagte effekt i samtlige tidsluker for CCTrCH, og midler for å inkludere det fullstendig TFC-sett i TFC-kandidatsettet når den forutsagte overførte effekt i samtlige tidsluker for CCTrCH er mindre enn den maksimalt tillatte overførte effekt for et brukerutstyr (UE).

21. Apparat som angitt i krav 20,karakterisert vedat sammenligningsmidlene omfatter midler for å utføre sammenligningstrinnet for et gitt antall påfølgende puljer for det formål å inkludere det fullstendige TFC-sett i TFC-kandidatsettet.

22. Apparat som angitt i krav 21,karakterisert vedat midlene for å inkludere omfatter det fullstendige TFC-sett i TFC-kandidatsettet og som reagerer på at de angitte sammenligningsmidler detekterer at den forutsagte overførings-effekt er mindre enn den maksimalt tillatte effekt i tre (3) påfølgende puljer.

23. Apparat som angitt i krav 15,karakterisert vedat midlene for å forutsi overført effekt i hver tidsluke omfatter: midler for å ta i betraktning et verste tilfellescenario ved å anta at samtlige koder er blitt brukt i vedkommende tidsluke, selv om de skriver seg fra forskjellige CCTrCH-enheter.

24. Apparat som angitt i krav 23,karakterisert vedat en betafaktor som brukes for hver kode utgjøres av en høyeste betafaktor for CCTrCH blant samtlige TFC-enheter i det TFC-sett som blir brukt.

25. Apparat som angitt i krav 15,karakterisert vedat det videre omfatter: midler for å velge ut en TFC fra TFC-kandidatsettet ved anvendelse av de kriterier at: ingen annen TFC tillater overføring av data med høyere prioritet enn en valgt TFC, ingen annen TFC tillater overføring av flere data fra kanaler med den nærmeste lavere prioritet, og ingen annen TFC har en lavere bit-hastighet enn den valgte TFC.

26. Apparat som angitt i krav 15,karakterisert vedatfor-syningsmidlene videre omfatter: midler for å tilføre det fullstendige TFC-sett bare i det tilfelle dette fullstendige TFC-sett kan understøttes.

27. Apparat for planlegging av dataoverføring i et trådløst kommunikasjonsnettverk og som da eliminerer behov for å bestemme effektfordringer for hver transportformatkombinasjon (TFC) i hver tidsluke,karakterisert vedat nett-verket omfatter: minst et fysisk lag og et mediumstilgangskontrollag (MAC), hvor det angitte fysiske lag omfatter: midler for å overvåke overført effekt i en tidsluke, og midler for å sende ut en angivelse til MAC-laget om at maksimal effekt er blitt nådd, og da sammen med vedkommende tidslukes nummer, hvor MAC-laget da omfatter: midler for å frembringe enten et fullstendig TFC-sett eller et minste TFC-sett basert på en effektangivelse fra det fysiske lag.

28. Fremgangsmåte som angitt i krav 13,karakterisertv e d at fremgangsmåten omfatter: for vedkommende MAC: innstilling av et minimalt TFC-sett ved å forutsi, etter hver driftspulje for en kodet sammensatt transportkanal (CCTrCH), en effekt som behøves for et fullstendig TFC-sett for vedkommende CCTrCH i den neste pulje, og som da inkluderer det fullstendige TFC-sett i et TFC-kandidatsett når den forutsagte overføringseffekt er mindre enn den maksimalt tillatte overføringseffekt for brukerutstyr (UE) under tre (3) påfølgende puljer.

29. Fremgangsmåte som angitt i krav 28,karakterisertv e d at det angitte MAC-lag utgjøres av en MAC-tildelt kanal av type MAC-d.

30. Fremgangsmåte som angitt i krav 28,karakterisertv e d at det minimale TFC-sett utnyttes av den angitte MAC når den angitte forutsagte overføringseffekt ikke er mindre enn den angitte maksimalt tillate UE-effekt for de angitte tre (3) innbyrdes påfølgende puljer.