(12) Oversettelse av europeisk patentskrift

Transkript

1 (12) Oversettelse av europeisk patentskrift (11) NO/EP B1 (19) NO NORGE (51) Int Cl. H04W 72/12 ( ) H04L 12/805 ( ) Patentstyret (21) Oversettelse publisert (80) Dato for Den Europeiske Patentmyndighets publisering av det meddelte patentet (86) Europeisk søknadsnr (86) Europeisk innleveringsdag (87) Den europeiske søknadens Publiseringsdato (30) Prioritet , SE, (84) Utpekte stater AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR (73) Innehaver Telefonaktiebolaget L M Ericsson (publ),, Stockholm, SE-Sverige (72) Oppfinner Nádas, Szilveszter, Zoltan u. 28. fsz. 2, 1192 Budapest, HU-Ungarn Larmo, Anna, Leirikaari 26 A 2, FI Espoo, FI-Finland Lundh, Peter, Eksätravägen 218, SE Skärholmen, SE-Sverige Widegren, Ina, Heleneborgsgatan 25C, 1tr, SE Stockholm, SE-Sverige Liao, Min, 2 7K, NO. 19 building, NO.3, Jiangtai, Beijing, CN-Kina (74) Fullmektig Bryn Aarflot AS, Postboks 449 Sentrum, 0104 OSLO, Norge (54) Benevnelse Fleksibel lengde for en pakkedataenhet for radiolinkkontroll (56) Anførte publikasjoner EP-A WO-A1-2006/ ERICSSON ET AL: "Support of higher bitrates and Flexible RLC PDU size on HS-DSCH and introduction of FSN/DRT Reset", 3GPP DRAFT; R , 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG3, no. Kobe, Japan; , 24 May 2007 ( ), XP , [retrieved on ]

2 1 Fleksibel lengde for en pakkedataenhet for radiolinkkontroll TEKNISK OMRÅDE Utførelsesformer i overensstemmelse med foreliggende oppfinnelse vedrører generelt trådløse kommunikasjonssystemer, og mer spesifikt dataflytkontroll i et mobilt kommunikasjonssystem. BAKGRUNN WCDMA-(Wideband Code Division Multiple Access)-radioaksessnett (WRAN) introduserte høyhastighets pakkeaksess for nedlinjen (HSDPA - High Speed Downlink Packet Access) i 3GPP Release 5 og høyhastighets pakkeaksess på opplinjen (HSUPA - High Speed Uplink Packet Access)/Utvidet Opplinje (EUL - Enhanced UpLink) i 3GPP Release 6. Høyhastighets pakkeaksess (HSPA - High Speed Packet Access) er fellesbetegnelsen for både HSDPA og EUL. 3GPP-spesifikasjoner fra Release 4 til Release 6 anvender noen få faste mediumaksesskontroll-d (MAC-d) pakkedataenhet- (PDU)-lengder for HSPA. Begrensningen av radiolinkkontroll-(rlc)-overføringsvinduer til 2047 PDU'er sammen med den nokså lange tur/retur-tiden (fra den betjenende radionettverkskontrolleren til brukerenheter og tilbake), gir en begrenset topp-bitrate i cellulære systemer. Innføringen av MIMO (Multiple Input Multiple Output) og/eller 64 QAM (Quadrature Amplitude Modulation) kan resultere i topp-bitrater så høye som 42 megabit per sekund (Mbps). Lengre MAC-d PDU-lengder er nødvendig for høyere topp-bitrate med HSDPA (antatt at RLC-vindusstørrelsen på 2047 opprettholdes). Bruk av MAC-d PDU'er som er for lange medfører begrenset dekning så lenge bare et heltall MAC-d PDU'er blir skedulert over luftgrensesnittet innenfor ett overføringstidsintervall (TTI), dvs. at én MAC-d PDU er den minste enheten av data som kan bli overført i ett TTI. Kvittert modus (AM - Acknowledged Mode) i RLC tilveiebringer en struktur for bruk av fleksible PDU-lengder. I RLC AM (3GPP TS , protokollspesifikasjon for RLC), for eksempel, er det definert en fleksibel PDU-lengdestruktur. Det er mulighet for å konfigurere flere RLC PDU-lengder, men header-felter kan begrense antallet som kan anvendes i praksis. For eksempel er det i dag mulig å anvende maksimalt 8 forskjellige MAC-d PDU-lengder over HS-DSCH, hvor en MAC-d-protokolldataenhet inkluderer en RLC-protokolldataenhet og eventuelt en MAC-d-header. En helt ny PDU-lengdestruktur er derfor nødvendig for optimal ytelse. Dagens løsning for kapasitetsallokering i høyhastighets delte nedlinjekanaler (HS- DSCH - High Speed Downlink Shared CHannel) og definisjonen av HS-DSCH-datarammen (HS-DSCH DATA FRAME) er ikke effektiv for løsningen for fleksibel RLC (eller fleksibel

3 2 PDU-lengdestruktur). Bitraten for HS-DSCH-datarammer kan ikke styres på en god måte ved anvendelse av dagens kontrollrammeformat for kapasitetsallokering i HS-DSCH. Dagens kontrollrammeformat spesifiserer at et gitt antall PDU'er (HS-DSCH Credits) med en gitt maksimal lengde (Maximum MAC-d PDU Length) kan bli sendt i et gitt intervall (HS-DSCH Interval). Forutsatt en fast MAC-d PDU-lengde er det enkelt å oversette dette formatet til oktetter innenfor et intervall, eller til en bitrate. Med innføringen av fleksibel RLC kan imidlertid hver enkelt MAC-d PDU ha forskjellig lengde. En PDU på én oktett opptar således en hel kreditt, akkurat som en PDU på 1500 oktetter, og styring av det tillatte antall oktetter per intervall, eller den tillatte bitraten, blir vanskelig. Den innledende kapasiteten ved HS-DSCH-dataoverføring blir tildelt av basestasjonen via den innledende HS-DSCH-kapasitetsallokeringen under radiolinkoppsettsoperasjonen, radiolinkomkonfigureringsoperasjonen eller radiolinktilleggingsoperasjonen. Under disse operasjonene spesifiserer den innledende HS-DSCH-kapasitetsallokeringen, som blir sendt fra basestasjonen til den styrende radionettverkskontrolleren, den maksimale MAC-d PDU-lengden (Maximum MAC-d PDU Size) og antallet MAC-d PDU'er (HS-DSCH Initial Window Size). Dagens tolkning av denne innledende HS-DSCHkapasitetsallokeringen blir anvendt for faste MAC-d PDU-lengder og er åpenbart ikke egnet for fleksibel RLC. Dagens HS-DSCH-datarammeformat (HS-DSCH DATA FRAME) støtter ikke forskjellige MAC-d PDU-lengder. Utsending av MAC-d PDU'er av forskjellig lengde kan derfor bli veldig ineffektivt (f.eks. kan administrasjonskostnaden i transportnettverket bli veldig høy), siden en ny dataramme er nødvendig for hver PDU med forskjellig lengde. I dagens format blir dessuten en 4-bits reserveutvidelse innsatt foran hver MAC-d PDU i datarammen, noe som øker administrasjonen betydelig for oktett-oppstilte PDU'er; som er vanlig. Dagens format er ikke i stand til å håndtere fleksibel RLC (hvor f.eks. en MAC-d PDU inneholdende en 1500 oktetter lang IP-(Internet Protocol)-pakke skal sendes). Samtidig antar dagens MAC-d PDU-lengde-indikator bitgranularitet, som ikke er nødvendig dersom MAC-d PDU'er blir oktett-oppstilt med fjerning av MAC-dmultipleksing. Videre, med fjerningen av MAC-d-multipleksing, dersom HS-DSCH DATA FRAME ikke støtter en form for logisk kanalavbildning, kan antallet transportnettverksforbindelser som kreves av noen radiobærere øke betydelig (f.eks., i stedet for én forbindelse, kan fire forbindelser være nødvendig for en signaleringsradiobærer (SRB - Signaling Radio Bearer)). WO 2006/ A1 viser en fremgangsmåte for å utløse gjenforhandling av en sesjon når en aksessterminal (AT) beveger seg fra ett aksessnett (kilde-aksessnett) til et annet aksessnett (mål-aksessnett) som har forskjellig evne i et høyhastighets pakkedatasystem. Fremgangsmåten innebærer at kilde-aksessnettet sender sesjonsinformasjon

4 3 sammen med ikke-default protokolltyper som aksessterminalen støtter og at målaksessnettet sjekker om den er i stand til å støtte protokolltyper som er mer avanserte enn de som er i bruk for å innlede sesjonsgjenforhandling dersom den er i stand til å støtte de mer avanserte protokolltypene. På den måten lettes overføringen av informasjonen til mål-aksessnoden under sesjonsoverføring når terminalen beveger seg fra kilde-aksessnoden til mål-aksessnoden. OPPSUMMERING Det er et formål med oppfinnelsen å unngå i det minste noen av de ovennevnte ulemper og å tilveiebringe forbedret dataflytkontroll for kommunikasjonssystemer. Formålet oppnås med en fremgangsmåte ifølge det selvstendige krav 1 og med en anordning ifølge det selvstendige krav 5. Uselvstendige krav definerer foretrukne utførelsesformer av fremgangsmåten og anordningen. Utførelsesformer som beskrives her tilveiebringer et nytt HS-DSCH rammeprotokollformat (omtalt i det følgende som "HS-DSCH rammeprotokolltype 2-formatet") som kan muliggjøre overføring av PDU'er med forskjellige lengder. I én utførelsesform tilveiebringer HS-DSCH rammeprotokolltype 2-formatet et nytt HS-DSCH rammeprotokolltype 2 kapasitetsallokering-(capacity ALLOCATION)-kontrollrammeformat som spesifiserer MAC-d PDU-kreditter i oktetter (i motsetning til en kombinasjon av et antall PDU'er av en gitt maksimal lengde). HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen støtter også større MAC-d PDU-lengder ved å tillate gjenbruk av ubrukte kreditter. I tillegg til et nytt kapasitetsallokering-kontrollrammeformat tilveiebringer HS- DSCH rammeprotokolltype 2-formatet et nytt HS-DSCH rammeprotokolltype 2-dataramme-(DATA FRAME)-format. HS-DSCH rammeprotokolltype 2-datarammen kan tillate flere enn én PDU-lengde i samme dataramme. Videre kan HS-DSCH rammeprotokolltype 2-datarammeformatet, i én utførelsesform, muliggjøre overføring av flere PDU'er tilknyttet forskjellige logiske kanaler i samme dataramme. Det nye HS-DSCH rammeprotokolltype 2-rammeformatet kan tilveiebringe: en maksimal MAC-d PDU-lengde på ~1500 oktetter og oktettgranularitet i MACd PDU-lengde støttes på en effektiv måte; mulighet til å ta hensyn til begrensningen av den maksimale overføringsenheten i det anvendte transportnettverket; mulighet til å støtte fleksible MAC-d PDU-lengder; mulighet til å støtte høyere HSPA Evolution-bitrater (f.eks. opptil ~42 megabit per sekund (Mbps));

5 4 liten administrasjon på transportnettverkslaget (dataramme-header og kontrollrammelengde); og ett enkelt dataramme- og kontrollrammeformat, som tilrettelegger for enklere utvidelse i fremtiden. KORT BESKRIVELSE AV TEGNINGENE Figur 1 er et diagram av et eksempel på et nettverk der systemer og fremgangsmåter som beskrives her kan realiseres; Figur 2 er et eksempel på et diagram av en basestasjon i figur 1; Figur 3 er et eksempel på et diagram av et datamaskinlesbart medium som kan være tilknyttet basestasjonen i figur 1; Figur 4 er et eksempel på et diagram av en radionettverkskontroller i figur 1; Figur 5 er et flytdiagram av et eksempel på en prosess for overføring av en dataramme ifølge et eksempel på utførelse; Figur 6 er et eksempel på et diagram av en HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollramme ifølge et eksempel på utførelse; Figurene 7A-7D er eksempler på diagrammer av deler av HS-DSCH rammeprotokolltype 2-datarammer ifølge eksempler på utførelser; Figur 8 er et flytdiagram av et eksempel på en prosess for å avgjøre om en node er i stand til å støtte HS-DSCH rammeprotokolltype 2-formatet; og Figur 9 er et eksempel på et flytdiagram ifølge et eksempel på utførelse. DETALJERT BESKRIVELSE Den detaljerte beskrivelsen som følger henviser til de vedlagte tegningene. De samme henvisningstall i forskjellige tegninger kan identifisere de samme eller tilsvarende elementer. Den detaljerte beskrivelsen som følger begrenser ikke oppfinnelsen. Utførelsesformer som beskrives her tilveiebringer en HS-DSCH rammeprotokoll (omtalt som "HS-DSCH rammeprotokolltype 2") som muliggjør overføring av PDU'er med forskjellige lengder. Figur 1 er et diagram av et eksempel på et nettverk 100 der systemer og fremgangsmåter som beskrives her kan realiseres. Nettverket 100 kan inkludere en gruppe av brukerenheter (UE'er) til 110-L (omtalt kollektivt, og i noen tilfeller individuelt, som "brukerenhet(er) 110"), et radioaksessnett (RAN) 120 og et kjernenettverk (CN) 130. Fire brukerenheter 110, ett radioaksessnett 120 og ett kjernenettverk 130 er illustrert for enkelhets skyld. I praksis kan det være flere eller færre brukerenheter, radioaksessnett og/eller kjernenettverk.

6 5 Brukerenheter 110 kan innbefatte én eller flere anordninger i stand til å sende/motta tale og/eller data til/fra radioaksessnettet 120. I én utførelsesform kan en brukerenhet 110 for eksempel inkludere en trådløs telefon, en personlig digital assistent (PDA), en bærbar PC etc. Radioaksessnettet 120 kan innbefatte én eller flere anordninger for å overføre tale og/eller data til brukerenheter 110 og kjernenettverket 130. Som illustrert kan radioaksessnettet 120 innbefatte en gruppe av basestasjoner (BS'er) til 122-M (omtalt kollektivt som "basestasjoner 122" og i noen tilfeller enkeltvis som "basestasjon 122") og en gruppe av radionettverkskontrollere (RNC'er) til 124-N (omtalt kollektivt som "radionettverkskontrollere 124" og i noen tilfeller enkeltvis som "radioaksesskontroller 124"). Fire basestasjoner 122 og to radionettverkskontrollere 124 er vist i figur 1 for å forenkle. I praksis kan det være flere eller færre basestasjoner og/eller radionettverkskontrollere. Basestasjoner 122 (også omtalt som "node B'er") kan inkludere én eller flere anordninger som mottar tale og/eller data fra radionettverkskontrollere 124 og sender denne talen og/eller disse dataene til brukerenheter 110 via et luftgrensesnitt. Basestasjoner 122 kan også innbefatte én eller flere anordninger som mottar tale og/eller data fra brukerenheter 110 over et luftgrensesnitt og sender denne talen og/eller disse dataene til radionettverkskontrollere 124 eller andre brukerenheter 110. Radionettverkskontrollerne 124 kan inkludere én eller flere anordninger som styrer og administrerer basestasjoner 122. Radionettverkskontrollerne 124 kan også innbefatte anordninger som utfører brukerdatabehandling for å styre bruken av tjenester i radionettverket. Radionettverkskontrollerne 124 kan sende/motta tale og data til/fra basestasjoner 122, andre radionettverkskontrollere 124 og/eller kjernenettverket 130. En radionettverkskontroller 124 kan tjene som en styrende radionettverkskontroller (CRNC), en driftsradionettverkskontroller (DRNC) eller en betjenende radionettverkskontroller (SRNC). En CRNC har ansvar for å styre ressursene til en basestasjon 122. En SRNC, derimot, betjener en bestemt brukerenhet 110 og administrerer forbindelsene mot denne brukerenheten 110. Likeså fyller DRNC'en en tilsvarende rolle som SRNC'en (f.eks. kan den rute trafikk mellom en SRNC og en bestemt brukerenhet 110). Som illustrert i figur 1 kan en radionettverkskontroller 124 stå i forbindelse med en basestasjon 122 via et Iub-grensesnitt og med en annen radionettverkskontroller 124 via et Iur-grensesnitt. Kjernenettverket 130 kan inkludere én eller flere anordninger som sender/mottar tale og/eller data til et kretssvitsjet og/eller pakkesvitsjet nettverk. I én utførelsesform kan kjernenettverket 130 inkludere, for eksempel, et mobilt svitsjesenter (MSC - Mobile Switching Center), en GMSC (Gateway MSC), en MGW (Media Gateway), en betjenende

7 6 GPRS-(General Packet Radio Service)-støttenode (SGSN), en gateway GPRS-støttenode (GGSN) og/eller andre anordninger. I noen utførelsesformer kan én eller flere komponenter i nettverket 100 utføre én eller flere av oppgavene beskrevet som utført av én eller flere andre komponenter i nettverket 100. Figur 2 er et eksempel på et diagram av en basestasjon i samsvar med et eksempel på utførelse. Basestasjonene til 122-M kan være tilsvarende utformet. Som vist i figur 2 kan basestasjon innbefatte antenner 210, transceivere (TX/RX) 220, et prosesseringssystem 230 og et Iub-grensesnitt (I/F) 240. Basestasjonen kan innbefatte ytterligere og/eller andre komponenter enn de illustrert i figur 2. Antennene 210 kan inkludere én eller flere retningsantenner og/eller isotrope antenner. Transceiverene 220 kan være tilknyttet antennene 210 og innbefatte transceiverkretser for å sende og/eller motta symbolsekvenser i et nettverk, så som nettverket 110, via antenner 210. Prosesseringssystemet 230 kan styre driften av basestasjonen Prosesseringssystemet 230 kan også behandle informasjon mottatt via transceiverene 220 og Iub-grensesnittet 240. Prosesseringssystemet 230 kan videre måle forbindelsers kvalitet og styrke og bestemme rammefeilraten (FER), og sende denne informasjonen til radionettverkskontrolleren Som illustrert kan prosesseringssystemet 230 innbefatte en prosesseringsenhet 232, en gruppe av prioritetskøer 234 og en logisk kanalidentifikator-(id)-til-prioritetskø-avbilder 236. Det vil forstås at prosesseringssystemet 230 kan innbefatte ytterligere og/eller andre komponenter enn de illustrert i figur 2. Prosesseringsenheten 232 kan behandle informasjon mottatt via transceiverene 220 og Iub-grensesnittet 240. Behandlingen kan inkludere, for eksempel, datakonvertering, forover feilkorreksjon (FEC), hastighetstilpasning, WCDMA-(Wideband Code Division MultiPLE Access)-spredning/despredning og QPSK-(Quadrature Phase Shift Keying)-modulering, etc. I tillegg kan prosesseringsenheten 232 generere kontrollmeldinger og/eller datameldinger (f.eks. HS-DSCH-datarammer) og bevirke til at disse kontrollmeldingene og/eller datameldingene blir sendt via transceiverene 220 og/eller Iub-grensesnittet 240. Prosesseringsenheten 232 kan også behandle kontrollmeldinger og/eller datameldinger mottatt fra transceiverene 220 og/eller Iub-grensesnittet 240. Prioritetskøene 234 kan lagre informasjon (f.eks. i form av PDU'er) som skal sendes til og/eller som har blitt mottatt fra brukerenheter 110. I én utførelsesform kan hver brukerenhet 110 tilknyttet basestasjonen være tilknyttet én eller flere prioritetskøer fra prioritetskøene 234. En prioritetskø kan for eksempel bli initialisert for en brukerenhet 110 når en MAC-d-flyt blir opprettet for denne brukerenheten 110.

8 7 Logisk kanalidentifikator-til-prioritetskø-avbilderen 236 kan avbilde mottatte logiske kanalidentifikatorer til prioritetskøidentifikatorer. I én utførelsesform kan en HS- DSCH rammeprotokolltype 2-dataramme assosiere én eller flere logiske kanalidentifikatorer med én eller flere PDU'er lagret i datarammen. Basestasjonen kan anvende de logiske kanalidentifikatorene for å identifisere de rette prioritetskøene fra prioritetskøene 234 for lagring av PDU'ene. Iub-grensesnittet 240 kan innbefatte ett eller flere linjekort som lar basestasjonen sende data til og motta data fra radionettverkskontrolleren I noen utførelsesformer kan én eller flere komponenter i basestasjonen utføre oppgavene beskrevet som utført av én eller flere andre komponenter i basestasjonen Figur 3 er et eksempel på et diagram av et datamaskinlesbart medium 300 som kan være tilknyttet en basestasjon, så som basestasjon Selv om ett datamaskinlesbart medium er beskrevet nedenfor, vil det forstås at det datamaskinlesbare mediet 300 kan inkludere flere datamaskinlesbare medier lagret lokalt på basestasjonen 122-1, eller lagret på ett eller flere forskjellige og muligens fjerne steder. Som illustrert kan det datamaskinlesbare mediet 300 opprettholde en gruppe av oppføringer i de følgende eksemplifiserte feltene: et logisk kanalidentifikator-felt 310 og et prioritetskøidentifikator-felt 320. Det datamaskinlesbare mediet 300 kan opprettholde ytterligere eller annen informasjon enn den illustrert i figur 3. Logisk kanalidentifikator-feltet 310 kan lagre en sekvens av tegn som identifiserer en logisk kanal til hvilken brukerenheter, så som brukerenheten 110-1, er tilknyttet. I én utførelsesform kan tegnsekvensen være unik for den spesifikke basestasjonen. Prioritetskøidentifikator-feltet 320 kan lagre en sekvens av tegn som identifiserer en prioritetskø fra prioritetskøene 234. I én utførelsesform kan hver prioritetskø fra prioritetskøene 234 ha en tilhørende unik sekvens av tegn som tjener som en identifikator for denne prioritetskøen. Via det datamaskinlesbare mediet 300 kan basestasjonen således identifisere en prioritetskø basert på en mottatt logisk kanalidentifikator. Figur 4 er et eksempel på et diagram av en radionettverkskontroller i samsvar med et eksempel på utførelse. Radionettverkskontrolleren kan være tilsvarende utformet. Som vist i figur 4 kan radionettverkskontrolleren innbefatte et prosesseringssystem 410, et Iub-grensesnitt 420, et Iur-grensesnitt 430 og/eller andre grensesnitt 440. Radionettverkskontrolleren kan innbefatte ytterligere og/eller andre komponenter enn komponentene illustrert i figur 4. Prosesseringssystemet 410 kan styre driften av radionettverkskontrolleren Som illustrert kan prosesseringssystemet 410 innbefatte en prosesseringsenhet 412 som

9 8 tar seg av protokollutvekslinger mellom Iub-grensesnittet 420, Iur-grensesnittet 430 og andre grensesnitt 440. I tillegg kan prosesseringsenheten 412 generere kontrollmeldinger og/eller datameldinger og sende disse kontrollmeldingene og/eller datameldingene via grensesnittene Prosesseringsenheten 412 kan også behandle kontrollmeldinger og/eller datameldinger mottatt fra grensesnittene Iub-grensesnittet 420 kan innbefatte ett eller flere linjekort som lar radionettverkskontrolleren sende kontrollmeldinger og/eller datameldinger til og motta kontrollmeldinger og/eller datameldinger fra basestasjonen Iur-grensesnittet 430 kan innbefatte ett eller flere linjekort som lar radionettverkskontrolleren sende kontrollmeldinger og/eller datameldinger til og motta kontrollmeldinger og/eller datameldinger fra en annen radionettverkskontroller, så som radionettverkskontrolleren De andre grensesnittene 440 kan inkludere grensesnitt mot andre anordninger og/eller nettverk. For eksempel kan de andre grensesnittene 440 inkludere et Iucs-grensesnitt, som er et kjernenettverksgrensesnitt mot et kretssvitsjet talenettverk, og et Iupsgrensesnitt, som er et kjernenettverksgrensesnitt mot et pakkesvitsjet datanettverk. I noen utførelsesformer kan én eller flere komponenter i radionettverkskontrolleren utføre oppgavene beskrevet som utført av én eller flere andre komponenter i radionettverkskontrolleren Figur 5 er et flytdiagram av et eksempel på en fremgangsmåte for å sende en dataramme i samsvar med et eksempel på utførelse. I én utførelsesform kan deler av fremgangsmåten illustrert i figur 5 bli utført av en basestasjon, så som basestasjon 122-1, og en del av fremgangsmåten kan bli utført av en radionettverkskontroller, så som radionettverkskontroller I en annen utførelsesform kan noe av eller hele fremgangsmåteeksempelet som beskrives nedenfor bli utført av en annen anordning eller kombinasjon av anordninger. Fremgangsmåten kan begynne med at basestasjon genererer en HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollramme (trinn 505). I én utførelsesform kan basestasjon generere HSDSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen som reaksjon på en HS-DSCH kapasitetsforespørsel fra radionettverkskontroller eller på et hvilket som helst annet tidspunkt. Blant annet kan HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen spesifisere MAC-d PDU kreditter i oktetter, heller enn ved et antall PDU'er. Figur 6 er et eksempel på et diagram av en HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollramme 600 i samsvar med et eksempel på utførelse. Som illustrert kan HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen 600 inkludere et belastningsstatus-informasjonselement (Congestion Status) 610, et felles transportkanalprioritetsindikator-informasjonselement (CmCH-PI) 620, et antall

10 9 kreditter-informasjonselement (MAC-d PDU Credits) 630, et intervall-informasjonselement (HS-DSCH Interval) 640, et gjentagelsesperiode-informasjonselement (HS- DSCH Repetition Period) 650 og et reserveutvidelse-informasjonselement (Spare Extension) 660. I andre utførelsesformer kan HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen 600 opprettholde ytterligere eller andre informasjonselementer enn informasjonselementene illustrert i figur 6. Informasjonselementet Congestion Status 610 kan inkludere informasjon som angir om en overbelastningssituasjon er detektert. Informasjonselementet CmCH-PI 620 kan inkludere informasjon som angir den relative prioriteten til datarammene som skal overføres fra radionettverkskontroller Informasjonselementet MAC-d PDU Credits 630 kan inkludere informasjon som angir antallet MAC-d PDU-oktetter som en radionettverkskontroller kan sende under ett HS-DSCH-intervall tildelt av HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen 600. I én utførelsesform kan verdien til informasjonselementet MAC-d PDU Credits variere, f.eks. fra 0 til , hvor "0" kan representere stans overføring og " " kan representere ubegrenset overføring. Feltlengden til informasjonselementet MAC-d PDU Credits kan være 24 bit. I en alternativ utførelsesform kan informasjonselementet MAC-d PDU Credits 630 være 20 bit, og tre av de resterende fire bitene kan bli brukt som reservebiter og én bit kan bli anvendt for å angi om ubrukte kreditt-oktetter kan bli gjenbrukt av radionettverkskontrolleren i det neste intervallet eller ikke. Informasjonselementet HS-DSCH Interval 640 kan lagre informasjon som representerer et tidsintervall under hvilket HS-DSCH-kredittene tildelt i HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen 600 kan bli anvendt. Informasjonselementet HS-DSCH Repetition Period 650 kan lagre informasjon som representerer antallet etterfølgende intervaller som HS-DSCH-kredittene i HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen 600 kan bli anvendt. Informasjonselementet reserveutvidelse 660 kan reservere plass til fremtidige informasjonselementer som kan bli lagt til i HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen 600. Ifølge ett eksempel på utførelse blir således et nytt informasjonselement "MAC-d PDU Credits" 630 innført i en HS-DSCH kapasitetsallokering-kontrollramme, som erstatter det gamle "HS-DSCH Credits"-feltet. Med informasjonselementet MAC-d PDU Credits 630, som har oktettgranularitet (ikke antall PDU'er), kan det oppstå tilfeller der ved enden av et HS-DSCH-intervall, én eller flere oktetter ikke kan bli anvendt for å sende MAC-d PDU'er (f.eks. fordi mengden gjenværende oktetter er mindre enn lengden til den ventende MAC-d PDU). Dersom informasjonselementet HS-DSCH Repetition Period 650 angir at repetisjonsperioden er større enn 1 eller er null, kan "MAC-d PDU Credits"

11 10 bli tildelt til transportnettverkflyten i hvert HS-DSCH-intervall. I dette tilfellet kan radionettverkskontrolleren gjenbruke disse brukte kredittene i begynnelsen av det neste HS- DSCH-intervallet. Tilbake til figur 5 kan basestasjon overføre HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen (f.eks. HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen 600) til radionettverkskontroller (trinn 510). For eksempel kan basestasjon overføre HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen til radionettverkskontroller via Iub-grensesnittet 240. Radionettverkskontroller kan motta HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen (trinn 515). For eksempel kan radionettverkskontroller motta HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen via Iub-grensesnittet 420. Som reaksjon på mottak av HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen kan radionettverkskontroller generere en HS-DSCH rammeprotokolltype 2-dataramme (trinn 520). Blant annet kan HS-DSCH rammeprotokolltype 2-datarammen lagre blokker av PDU'er med samme lengde, hvor PDU'ene i én blokk kan ha forskjellig lengde fra PDU'er i en annen blokk. Figur 7A er et eksempel på et diagram av en HS-DSCH rammeprotokolltype 2- dataramme 700 i samsvar med et eksempel på utførelse. Som illustrert kan HS-DSCH rammeprotokolltype 2-datarammen 700 inkludere en header 701 og nyttedata 715. Headeren 701 kan inkludere et syklisk redundans-kontrollsum-informasjonselement (CRC) 702, et rammetype-informasjonselement (FT) 703, et rammesekvensnummerinformasjonselement 704, et felles transportkanalprioritetsindikator-informasjonselement (CmCH-PI) 705, et informasjonselement Flush 706, et logisk kanalidentifikator-informasjonselement 707, et brukerbufferstørrelse-informasjonselement 708, et totalt antall PDU-blokker-informasjonselement 709 og et antall (#) PDU-blokkbeskrivelse-informasjonselementer 710 (f.eks. hvor hver blokk er tilknyttet et MAC-d PDU-lengde i blokkinformasjonselement 711 og et antall PDU'er (#PDU'er) i blokk-informasjonselement 712). I andre utførelsesformer kan headeren 701 inkludere ytterligere og/eller andre informasjonselementer enn de vist i figur 7A. Header-nformasjonselementet CRC 702 kan lagre en CRC beregnet på headeren 701 i datarammen 700. Informasjonselementet FT 703 kan lagre informasjon som angir om rammen 700 er en dataramme eller en kontrollramme. rammesekvensnummerinformasjonselementet 704 kan lagre en verdi som representerer rammesekvensnummeret til datarammen 700 i en MAC-d-flyt. Felles transportkanalprioritetsindikatorinformasjonselementet 705 kan inkludere informasjon som angir den relative prioriteten til datarammen 700. Informasjonselementet Flush 706 kan lagre informasjon som angir om DRNC'en skal eller ikke skal fjerne alle MAC-d PDU'ene fra den tilhørende prioritets-

12 11 køen som er mottatt før datarammen 700 på samme transportbærer. Logisk kanalidentifikator-informasjonselementet 707 kan lagre informasjon som identifiserer en logisk kanalinstans når flere logiske kanaler bæres på samme transportnettverksflyt. I én utførelsesform kan logisk kanalidentifikator-informasjonselementet 707 lagre, for eksempel, en verdi mellom 0 og 15, hvor verdiene 0 til 14 kan identifisere logiske kanaler 1-15 og verdien 15 kan være reservert for fremtidig bruk. Feltlengden til logisk kanalidentifikator-informasjonselementet 707 kan være fire bit i ett utførelseseksempel. Brukerbufferstørrelse-informasjonselementet 708 kan lagre informasjon som representerer bufferstørrelsen (f.eks. mengden data i bufferet) i oktetter for et gitt felles transportkanalprioritetsindikator-nivå. Totalt antall PDU-blokker-informasjonselementet 709 kan lagre informasjon som representerer det totale antallet PDU-blokker i datarammen 700. En PDU-blokk kan være definert som én eller flere PDU'er av samme lengde. Hver PDU-blokk kan beskrives av lengden til PDU'er og antallet PDU'er i blokken. I tilfeller hvor levering i rekkefølge er ønskelig, kan flere enn én blokk med PDU'er av samme lengde bli innlemmet i datarammen 700. Dersom for eksempel den maksimale PDU-lengden er betydelig mindre enn en full IP pakke, kan IP-pakken bli delt inn i mange PDU'er i sekvens, hver med samme maksimale PDU-lengde. I én utførelsesform kan en PDU-blokk støtte PDU-lengder som er like lange som en IP-pakke (f.eks oktetter). Totalt antall PDU-blokker-informasjonselementet 709 kan lagre, for eksempel, en verdi mellom 0 og 31, hvor verdien "0" kan representere en ugyldig verdi. Feltlengden til totalt antall PDU-blokker-informasjonselementet 709 kan være fem bit i ett utførelseseksempel. Som angitt over kan hver PDU-blokk i datarammen 700 være tilknyttet PDUblokkbeskrivelse-informasjonselementer 710. PDU-blokkbeskrivelse-informasjonselementer 710 kan inkludere et MAC-d PDU-lengde i blokk-informasjonselement 711 og et antall (#) PDU'er i blokk-informasjonselement 712. MAC-d PDU-lengde i blokkinformasjonselementet 711 kan lagre informasjon som representerer lengden til hver MAC-d PDU i den aktuelle blokken. Lengden kan være oppgitt i oktetter. I én utførelsesform kan MAC-d PDU-lengde i blokk-informasjonselementet 711 lagre, for eksempel, en verdi mellom 0 og 2047, hvor verdien "0" kan representere en ugyldig verdi. Feltlengden til MACd PDU-lengde i blokk-informasjonselementet 711 kan være elleve bit i ett utførelseseksempel. Antall PDU'er i blokk-informasjonselementet 712 kan lagre informasjon som representerer et antall MAC-d PDU'er i den aktuelle blokken. I én utførelsesform kan antall PDU'er i blokk-informasjonselementet 712 lagre, for eksempel, en verdi mellom 0 og 31, hvor verdien "0" kan representere en ugyldig verdi. Feltlengden til antall PDU'er i blokk-informasjonselementet 712 kan være fem bit i ett utførelseseksempel.

13 12 Nyttedataene 715 kan inkludere én eller flere blokker av PDU'er 716, et nye informasjonselement-(ie)-flagg-informasjonselement 717, et forsinkelsesreferansetidinformasjonselement (DRT) 718, et reserveutvidelse-informasjonselement 719 og et nyttedata-crc-informasjonselement 720. I andre utførelsesformer kan nyttedataene 715 inkludere ytterligere og/eller andre informasjonselementer enn de vist i figur 7A. Rekkefølgen til PDU-blokker 716 i nyttedataene 715 kan følge en samsvarende rekkefølge til PDU-blokkbeskrivelse-informasjonselementene i headeren 701. I eksempelet illustrert i figur 7A inkluderer headeren 701 beskrivelser for PDU-blokker 1 til n. Nyttedataene 715 kan således inkludere n PDU-blokker, ordnet fra 1 til n. Som angitt over kan hver PDU-blokk inneholde én eller flere PDU'er av samme lengde. Imidlertid kan lengden til PDU'er i én blokk være forskjellig fra lengden til PDU'er i en annen blokk i nyttedataene 715. Nye informasjonselement-flagg-informasjonselementet 717 kan lagre informasjon (f.eks. ett eller flere flagg) dersom minst ett nytt informasjonselement er inneholdt i datarammen 700. Hvert flagg kan angi hvilke nye informasjonselementer som forefinnes etter nye informasjonselement-flagg-informasjonselementet 717. Forsinkelsesreferansetid-informasjonselementet 718 kan lagre informasjon som anvendes for dynamiske forsinkelsesmålinger. Reserveutvidelse-informasjonselementet 719 kan være reservere plass til fremtidige informasjonselementer som kan bli lagt til i datarammen 700. Nyttedata-CRC-informasjonselementet 720 kan lagre en CRC-verdi beregnet på nyttedataene 715 i datarammen 700. Som et alternativ til utførelseseksempelet illustrert i figur 7A kan MAC-d PDUlengde i blokk-informasjonselementet bli økt med én bit for å kunne å støtte 4-bits granularitet for MAC-d PDU-lengde. Denne alternative utførelsesformen kan støtte eldre brukerenheter med MAC-d-multipleksing aktivert. Dersom fjerningen av MAC-d-multipleksing ikke aksepteres i et radioaksessnett, kan lengden til MAC-d PDU-lengde i blokkinformasjonselementet bli økt for å uttrykke lengden i 4-bits enheter og logisk kanalidentifikator-informasjonselementet kan bli fjernet. I noen tilfeller (f.eks. når en dataramme inneholder små PDU'er med forskjellig lengde), kan et 1-bits informasjonselement "Mer informasjon" innlemmes i PDU-blokkbeskrivelse-informasjonselementer 710 i headeren 701. Et eksempel på et diagram av alternative PDU-beskrivelse-informasjonselementer 725 for denne alternative utførelsesformen er vist i figur 7B. Som illustrert er MAC-d PDU-lengde i blokk-informasjonselementet og antallet (#) PDU'er i blokk-informasjonselementet fra datarammen 700 supplementert med et "Mer informasjon"-informasjonselement (MI) 726, som kan lagre informasjon vedrørende PDU'ene i blokken. I én utførelsesform, dersom "mer Informasjon"-informasjonselementet 726 lagrer en verdi lik 0, kan det tilknyttede MAC-d PDU-

14 13 lengde i blokk-informasjonselementet være syv bit langt og antallet PDU'er i den aktuelle blokken kan være 1. Dersom derimot "Mer informasjon"-informasjonselementet 726 lagrer en verdi lik 1, kan fire bit i den neste oktetten også angi lengde (13 bit totalt) og de andre fire bit'ene kan angi antallet PDU'er. Figur 7C viser et eksempel på et alternativt diagram av en HS-DSCH rammeprotokolltype 2-dataramme 730 i samsvar med et eksempel på utførelse. I denne utførelsesformen er PDU-beskrivelse-informasjonselementene 710 (dvs. MAC-d PDU-lengde i blokk-informasjonselementet 711 og antall PDU'er i blokk-informasjonselementet 712) for hver blokk fordelt i nyttedataene 715, i stedet for i headeren 701 (som i datarammen 700). Som illustrert kan PDU-beskrivelse-informasjonselementet 710 for en gitt blokk være plassert rett før PDU'er 716 for denne blokken. I en annen utførelsesform kan en lengdeindikator (f.eks. en 12-bits indikator) for hver MAC-d PDU være innlemmet i headeren eller nyttedataene i en HS-DSCH rammeprotokolltype 2-dataramme. Et eksempel på en HS-DSCH rammeprotokolltype 2-dataramme 735 med lengdeindikatorer i en headerandel 740 er illustrert i figur 7D. Som vist kan headeren 740 i HS-DSCH rammeprotokolltype 2-datarammen 735 inneholde et syklisk redundans-kontrollsum-informasjonselement (Header CRC) 702, et rammetypeinformasjonselement (FT) 703, et rammesekvensummer-informasjonselement 704, et felles transportkanalprioritetsindikator-informasjonselement (CmCH-PI) 705, et informasjonselement Flush 706, et logisk kanalidentifikator-informasjonselement 707, et brukerbufferstørrelse-informasjonselement 708, et totalt antall PDU'er-informasjonselement 741 og et antall MAC-d PDU-lengdeindikator-informasjonselementer 742 (f.eks. ett for hver PDU i datarammen 735). I andre utførelsesformer kan headeren 740 inkludere ytterligere og/eller andre informasjonselementer enn informasjonselementene vist i figur 7D. Header CRC-informasjonselementet 702, rammetype-informasjonselementet 703, rammesekvensnummer-informasjonselementet 704, felles transportkanalprioritetsindikator-informasjonselementet 705, Flush-informasjonselementet 706, logisk kanalidentifikator-informasjonselementet 707 og brukerbufferstørrelse-informasjonselementet 708 kan inneholde informasjon tilsvarende den beskrevet over i forbindelse med figur 7A. Totalt antall PDU'er-informasjonselementet 741 kan lagre informasjon som representerer et antall (eller en mengde) PDU'er i datarammen 735. Hvert MAC-d PDU-lengdeindikatorinformasjonselement 742 kan lagre informasjon som representerer lengden (f.eks. i oktetter) til den tilhørende PDU'en i nyttedataene 745. Dersom for eksempel PDU #1 har en lengde på 8 oktetter, kan MAC-d PDU-lengdeindikator-informasjonselementet for PDU #1 lagre en verdi som angir 8 oktetter.

15 14 Nyttedataene 745 kan inkludere én eller flere PDU'er 746, et nye informasjonselementer-(ie)-flagg-informasjonselement 717, et forsinkelsesreferansetid-informasjonselement (DRT) 718, et reserveutvidelse-informasjonselement 719 og et nyttedata CRCinformasjonselement 720. I andre utførelsesformer kan nyttedataene 745 inkludere ytterligere og/eller forskjellige informasjonselementer enn de vist i figur 7D. I nyttedataene 745 kan hver PDU bli plassert i sin opprinnelige rekkefølge for å unngå omordning. PDU'enes rekkefølge kan svare til rekkefølgen til MAC-d PDU-lengdeindikatorene 742 i headeren 740. Nye Informasjonselementer-flagg-informasjonselementet 717, forsinkelsesseferansetid-informasjonselementet 718, reserveutvidelseinformasjonselementet 719 og nyttedata CRC-informasjonselementet 720 kan inneholde informasjon tilsvarende den beskrevet over i forbindelse med figur 7A. I noen utførelsesformer kan den logiske kanalidentifikatoren være den samme for en hel HS-DSCH rammeprotokolltype 2-dataramme, så som datarammen 700 i figur 7A. I andre utførelsesformer kan en gitt HS-DSCH rammeprotokolltype 2-dataramme ha flere enn én tilhørende logisk kanalidentifikator. Figur 7E er et diagram som illustrerer et eksempel på en HS-DSCH rammeprotokolltype 2-dataramme 750 som har flere enn én tilhørende logisk kanalidentifikator. Som vist kan headeren 755 i HS-DSCH rammeprotokolltype 2-datarammen 750 inkludere et syklisk redundans-kontrollsum-informasjonselement (Header CRC 702), et rammetype-informasjonselement (FT) 703, et rammesekvensnummer-informasjonselement 704, et felles transportkanalprioritetsindikator-informasjonselement (CmCH-PI) 705, et informasjonselement Flush 706, et brukerbufferstørrelse-informasjonselement 708, et totalt antall PDU-blokker-informasjonselement 709 og et antall MAC-d PDU-beskrivelse-informasjonselementer 751 (f.eks. ett for hver PDU i datarammen 750), hvor MAC-d PDU-beskrivelse-informasjonselementer 751 for en gitt PDU inkluderer et logisk kanalidentifikator for PDU-informasjonselement 752 og et MAC-d PDU-lengdeindikator-informasjonselement 753. I andre utførelsesformer kan headeren 755 inkludere ytterligere og/eller andre informasjonselementer enn de vist i figur 7E. Header CRC-informasjonselementet 702, rammetype-informasjonselementet 703, rammesekvensnummer-informasjonselementet 704, felles transportkanalprioritetsindikator-informasjonselementet 705, Flush-informasjonselementet 706, brukerbufferstørrelse-informasjonselementet 708 og totalt antall PDU-blokker-informasjonselementet 709 kan inneholde informasjon tilsvarende den beskrevet over i forbindelse med figur 7A. Informasjonselementet logisk kanalidentifikator for PDU 752 kan lagre informasjon som identifiserer en instans av en logisk kanal for PDU'en. I én utførelsesform kan logisk kanalidentifikator-informasjonselementet 752 lagre, for eksempel, en verdi mellom 0 og 15, hvor verdiene 0 til 14 kan identifisere logiske kanaler 1-15 og

16 15 verdien "15" kan være reservert for fremtidig bruk. Feltlengden til logisk kanalidentifikator-informasjonselementet 752 kan være fire bit i ett utførelseseksempel. MACd PDU-lengdeindikator-informasjonselementet 753 for en PDU kan lagre informasjon som representerer lengden (f.eks. i oktetter) til den motsvarende PDU'en i nyttedataene 760. Dersom for eksempel PDU #1 har en lengde på 8 oktetter, kan MAC-d PDU-lengdeindikator-informasjonselementet 753 for PDU #1 lagre en verdi som angir 8 oktetter. Nyttedataene 760 kan inkludere én eller flere PDU'er 761, et nye informasjonselementer-(ie)-flagg-informasjonselement 717, et forsinkelsesseferansetid-informasjonselement (DRT) 718, et reserveutvidelse-informasjonselement 719 og et nyttedata CRCinformasjonselement 720. I andre utførelsesformer kan nyttedataene 760 inkludere ytterligere og/eller andre informasjonselementer enn de vist i figur 7E. I nyttedataene 760 kan hver PDU bli plassert i sin opprinnelige rekkefølge for å unngå omordning. Rekkefølgen til PDU'ene 716 kan svare til rekkefølgen til MAC-d PDUlengdeindikatorene 753 i headeren 755. Nye informasjonselementer-flagg-informasjonselementet 717, forsinkelsesseferansetid-informasjonselementet 718, reserveutvidelseinformasjonselementet 719 og nyttedata CRC-informasjonselementet 720 kan inneholde informasjon tilsvarende den beskrevet over i forbindelse med figur 7A. Tilbake til figur 5 kan radionettverkskontroller overføre HS-DSCH rammeprotokolltype 2-datarammen (f.eks. dataramme 700, 730, 735 eller 750) til basestasjon (trinn 525). For eksempel kan radionettverkskontroller sende HS-DSCH rammeprotokolltype 2-datarammen til basestasjon via Iub-grensesnittet 420. Basestasjon kan motta HS-DSCH rammeprotokolltype 2-datarammen fra radionettverkskontroller (trinn 530). For eksempel kan basestasjon motta HS-DSCH rammeprotokolltype 2-datarammen via Iub 240. Basestasjon kan analysere HS-DSCH rammeprotokolltype 2-datarammen for å trekke ut den eller de logiske kanalidentifikatoren(e) fra HS-DSCH rammeprotokolltype 2-datarammen (f.eks. fra logisk kanalidentifikator-informasjonselementet 707 i headeren 701 i HS-DSCH rammeprotokolltype 2-datarammen 700) og avbilde den eller de uttrukkede logiske kanalidentifikatoren(e) til én eller flere prioritetskø-identifikatorer (trinn 535). For eksempel kan basestasjon 122-1, for eksempel via logisk kanalidentifikator-til-prioritetskø-avbilderen 236, anvende en uttrukket logisk kanalidentifikator for å slå opp (f.eks. via det datamaskinlesbare mediet 300) en identifikator for en prioritetskø fra prioritetskøene 234 for PDU'ene i datarammen. Dersom HS-DSCH rammeprotokolltype 2-datarammen inkluderer flere logiske kanalidentifikatorer (f.eks. datarammen 750 i figur 7E), kan basestasjon utføre flere oppslagsoperasjoner for å identifisere prioritetskøer for PDU'ene tilknyttet de logiske kanalidentifikatorene.

17 16 I kjent teknikk opprettholder HSDPA-(High Speed Downlink Packet Access)-basestasjon et antall prioritetskøer. En instans av en prioritetskø blir initialisert når en MAC-dflyt opprettes via Node B applikasjonsdel-(nbap)-meldinger. Videre kan én prioritetskø betjene flere logiske kanaler (eller radiobærere). Kjent teknikk inkluderer ikke signalering til basestasjonen for å støtte en avbildning av prioritetskø til den logiske kanalen (eller radiobæreren) som anvender HSDPA-radiolinken/radiobæreren for transport av brukerdata. Konsekvensen av dette er at prioritetskøidentifikatoren blir transportert sammen med den logiske kanalen for hver PDU til brukerenheten slik at brukerenheten er i stand til å fastslå 1) til hvilken logiske kanal en PDU tilhører; og 2) hvilken prioritetskø som ble anvendt for skedulering og omordning. Dette fører til unødvendig stor administrasjonskostnad over radiogrensesnittet. I sterk kontrast til dette, i utførelsesformer som beskrives her, kan radionettverkskontrolleren sende kontrollmeldinger til basestasjonen som tilveiebringer en avbildning mellom den logiske kanalen og prioritetskøen. Denne avbildningen er allerede innlemmet i kjent teknikk når det gjelder signalering mellom den styrende radionettverkskontrolleren/den betjenende radionettverkskontrolleren (CRNC/SRNC) og brukerenhetene. Ved at den samme avbildningen blir signalisert til basestasjonen, trenger kun identifisering av den logiske kanalen legges til i hver PDU som sendes til brukerenhetene fra basestasjonen. Brukerenhetene kan da være i stand til å bestemme den korrekte prioritetskøidentifikatoren fra den logiske kanalidentifikatoren. På den måten kan administrasjonskostnaden i radiogrensesnittet reduseres. Tabell 1 viser eksempler på administrasjonskostnadsverdier i tilknytning til et gammelt HS-DSCH datarammeformat (dvs. HS-DSCH rammeprotokolltype 1-datarammen) og et nytt HS-DSCH-datarammeformat (dvs. HS-DSCH rammeprotokolltype 2- datarammen i samsvar med utførelseseksemplene som beskrives her). Eksemplene antar at forsinkelsesseferansetid-informasjonselementet ikke forefinnes i datarammene. Som illustrert sparer det nye HS-DSCH datarammeformatet betydelig administrasjon i alle tilfeller (bortsett fra det hvor én enkelt PDU med 10 oktetter blir sendt - i dette tilfellet vil administrasjonskostnaden være lik). Tabell 1 Eksempeltilfelle 10 PDU'er med lengde 42 oktetter (tilfellet med en eldre UE) Overhead - gammelt format 19 oktetter (7 header, 2 CRC, 10 reserve+fylling) Overhead - nytt format 10 oktetter (6 header, 1*2 blokkheader, 2 CRC)

18 17 2 PDU'er med 500 oktetter 1 PDU med 400 oktetter 21 oktetter (2*7 header, 2*2 CRC, 3 reserve+fylling 12 oktetter (6 header, 2*2 blokk-header, 2 CRC) - sendt i to rammer) 1 PDU med 10 oktetter 10 oktetter (7 header, 2 CRC, 1 reserve+fylling) 10 oktetter (6 header, 1*2 blokk-header, 2 CRC) 1 PDU med 1500 oktetter Ikke støttet 10 oktetter (6 header, 1*2 blokk-header, 2 CRC) Når prioritetskøen(e) er identifisert, kan basestasjonen lagre PDU'ene fra HS-DSCH rammeprotokolltype 2-datarammen inn i den eller de passende prioritetskøen(e) i prioritetskøene 234 for senere overføring til en brukerenhet 110 (trinn 540). Tilbake til trinn 525, når radionettverkskontroller sender HS-DSCH rammeprotokolltype 2-datarammen, kan radionettverkskontroller avgjøre om ubrukte kreditter er igjen fra HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen (trinn 545). Som angitt over angir informasjonselementet MAC-d PDU Credits i HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen antallet MAC-d PDU-oktetter som en radionettverkskontroller tillates å sende under ett HS-DSCHintervall tildelt i HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen (f.eks. i informasjonselementet MAC-d PDU Credits 630). Dersom kapasitetsallokeringkontrollrammen er gyldig i flere enn ett interval, kan radionettverkskontrolleren gjenbruke kreditter som ikke ble benyttet innenfor et bestemt intervall i det neste intervallet. Dersom radionettverkskontroller slår fast at ubrukte kreditter er igjen fra HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen (trinn JA), kan radionettverkskontroller benytte de ubrukte kredittene i det neste intervallet (trinn 550). I én utførelsesform kan radionettverkskontrolleren benytte de ubrukte kredittene kun i det neste intervallet (og ikke intervaller etter det neste intervallet). Muligheten til å bruke kreditter som ikke ble brukt i et foregående intervall i det neste intervallet sørger for en stabil bitrate. Dersom derimot radiolinkkontrolleren slår fast at ingen ubrukte kreditter er igjen fra HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollrammen (trinn NEI), kan prosessen avsluttes. For eksempel kan prosessen returnere til trinn 515 der radionettverkskontrolleren mottar en annen HS-DSCH rammeprotokolltype 2 kapasitetsallokering-kontrollramme. Figur 8 er et flytdiagram av et eksempel på en fremgangsmåte for å avgjøre om en node er i stand til å støtte HSDSCH rammeprotokolltype 2-formatet ifølge et eksempel på utførelse. I én utførelsesform kan deler av fremgangsmåten illustrert i figur 8 bli utført av en basestasjon, så som basestasjonen 122-1, og en del av fremgangsmåten kan bli utført av en radionettverkskontroller, så som radionettverkskontrolleren I en

19 18 annen utførelsesform kan noe av eller hele fremgangsmåteeksempelet som beskrives nedenfor bli utført av en annen anordning eller kombinasjon av anordninger. For eksempel kan fremgangsmåten som beskrives nedenfor bli utført av en første og en andre radionettverkskontroller. Fremgangsmåteeksempelet begynner med at radionettverkskontroller genererer en kontrollmelding som identifiserer HS-DSCH-rammeprotokolltypen som støttes (trinn 805). I én utførelsesform inkluderer kontrollmeldingen, for eksempel, en melding RADIO LINK SETUP REQUEST, en melding RADIO LINK ADDITION REQUEST, en melding RADIO LINK RECONFIGURATION REQUEST, en melding RADIO LINK RECONFI- GURATION PREPARATION REQUEST, en melding PHYSICAL SHARED CHANNEL RECONFI- GURATION REQUEST og/eller en annen type kontrollmelding. I én utførelsesform inkluderer kontrollmeldingen et rammeprotokolltypestøtte-informasjonselement (HS-DSCH Framing Protocol Type Support) i informasjonselementet HS-DSCH Frequency Division Duplex (FDD) Information. Et eksempel på koding av HS-DSCH Framing Protocol Type Support-informasjonselementet er gitt i tabell 2. Som illustrert lagrer HS-DSCH Framing Protocol Support-informasjonselementet, i ett eksempel på utførelse, en 8-bits boolsk liste. Boolske lister av andre størrelser er mulig. HS-DSCH Framing Protocol Supportinformasjonselementet angir hvilke HS-DSCH-rammeprotokolltyper som støttes. Flere enn én rammeprotokolltype kan være støttet. Fra høyre mot venstre i den boolske liste angir hver posisjon en HS-DSCH rammeprotokolltype 1 til 8. I én utførelsesform angir verdien "0" at typen ikke er støttet og verdien "1" angir at typen er støttet. For eksempel angir en boolsk liste med verdien " " at både type 1 og type 2 rammeprotokollformat er støttet. Tabell 2 IE/gruppenavn Tilstedeværelse Range IE Type og referanse HS-DSCH Framing Protocol Type Support BOOLSK LISTE (STØRRELSE(8)) Radionettverkskontroller sender kontrollmeldingen til basestasjonen (trinn 810). For eksempel kan radionettverkskontroller sende kontrollmeldingen via Iub-grensesnittet 420. Basestasjon mottar kontrollmeldingen (trinn 815). For eksempel mottar basestasjon kontrollmeldingen via Iub-grensesnittet 240. Ved mottak av kontrollmeldingen (som inkluderer HS-DSCH-rammeprotokolltype-informasjonselementet), velger basestasjon en HS-DSCH-rammeprotokolltype (trinn 820). Basestasjon gjør valget basert på et antall faktorer. For eksempel, i én utførelsesform, velger basestasjon HS-DSCH rammeprotokolltype 2 når basestasjon 122-1

20 19 er kompatibel med dette rammeprotokollformatet. Ellers kan basestasjon velge HS-DSCH rammeprotokolltype 1. Basestasjon genererer en responsmelding som identifiserer den valgte HS- DSCH-rammeprotokolltypen (trinn 825). I én utførelsesform inkluderer responsmeldingen, for eksempel, en melding RADIO LINK SETUP RESPONSE, en melding RADIO LINK ADDITION RESPONSE, en melding RADIO LINK RECONFIGURATION RESPONSE, en melding RADIO LINK RECONFIGURATION PREPARATION RESPONSE, en melding PHYSICAL SHARED CHANNEL RECONFIGURATION RESPONSE og/eller en annen type responsmelding. Typen responsmelding som genereres kan være basert på kontrollmeldingen mottatt fra radionettverkskontroller I én utførelsesform inkluderer responsmeldingen et rammeprotokolltype valgt-informasjonselement (HS-DSCH Framing Type Selected) i informasjonselementet HS-DSCH Frequency Division Duplex (FDD) Information Response. Eksempler på koding av HS-DSCH Framing Type Selectedinformasjonselementet er vist i tabell 3. Som illustrert lagrer HS-DSCH Framing Type Selected-informasjonselementet, i ett eksempel på utførelse, et heltall (f.eks. fra 1 til 8) som representerer protokolltypenummeret. HS-DSCH Framing Type Selected-informasjonselementet angir HS-DSCH-rammeprotokolltypen som skal anvendes. For eksempel angir en verdi lik "1" at HS-DSCH rammeprotokolltype 1 er valgt og en verdi lik "2" angir at HS-DSCH rammeprotokolltype 2 er valgt. Tabell 3 IE/Gruppenavn Tilstedeværelse Range IE type og referanse HS-DSCH Framing Protocol Type Selected HELTALL (1...8) I én utførelsesform innlemmer basestasjonen et initiell kapasitetsallokeringinformasjonselement (HS-DSCH Initial Capacity Allocation) i responsmeldingen. HS-DSCH Initial Capacity Allocation-informasjonselementet gir flytkontrollinformasjon for hver skeduleringsprioritetsklasse for HS-DSCH-rammeprotokollen over Iub-grensesnittet. HS- DSCH Initial Capacity Allocation-informasjonselementet inkluderer et skeduleringsindikator-informasjonselement (Scheduling Indicator) (som lagrer informasjon som representerer den relative prioriteten til HS-DSCH-datarammen), et maksimal MAC-d PDU-størrelse-informasjonselement (Maximum MAC-d PDU Size) (som lagrer informasjon som representerer lengden (f.eks. i bit) til MAC-d PDU'en), og et initiell vindusstørrelseinformasjonselement (HS-DSCH Initial Window Size) (som lagrer informasjon som representerer den innledende antallet MAC-d PDU'er som kan overføres av radionett-