(12) Oversettelse av europeisk patentskrift

Transkript

1 (12) Oversettelse av europeisk patentskrift (11) NO/EP B1 (19) NO NORGE (1) Int Cl. H04L 1/16 (06.01) H04L 1/18 (06.01) 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 () Prioritet , US, P (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 LM Ericsson (publ), Stockholm, Sverige (72) Oppfinner SÅGFORS, Mats, Jungfrusvängen 33 G 12, FI Kyrkslätt, Finland TORSNER, Johan, Skogstorpsvägen 2 C9, FI-024 Masaby, Finland (74) Fullmektig Tandbergs Patentkontor AS, Postboks 170 Vika, 0118 OSLO, Norge (4) Benevnelse Fremgangsmåter og anordning for prosessering av feilkontrollmedlinger i et trådløst kommunikasjonssystem (6) Anførte publikasjoner EP-A EP-A US-A WO-A1-07/ WO-A1-08/ "3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Medium Access Control (MAC) protocol specification (Release 1999)", 3GPP STANDARD; 3GPP TS 2.321, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 60, ROUTE DES LUCIOLES ; F SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. V3.16.0, 1 September 03 ( ), XP , '3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Radio Link Control (RLC) protocol specification (Release 6)' 3GPP TS V6..0, [Online] June 07, Retrieved from the Internet: <URL: o/2322.htm>

2 1 Beskrivelse TEKNISK OMRÅDE [0001] Foreliggende oppfinnelse vedrører generelt trådløse kommunikasjonssystemer, og vedrører mer spesielt prosessering av feilkontrollmeldinger i et trådløst system som fordeler (skedulerer) linkressurser. 1 2 BAKGRUNN [0002] 3GPP (Third-Generation Partnership Project) har startet et program for å utvikle spesifikasjoner for avanserte trådløse kommunikasjonssystemer, i et initiativ kjent som "Long Term Evolution", eller LTE. I standardiseringsdiskusjoner har en blitt enige om at LTE-systemer skal anvende en ARQ-(Automatic Repeat request )-mekanisme i RCL-(Radio Link Control)-protokollen. Den spesifiserte ARQ-protokollen er en selektiv gjentagelsesprotokoll (anvendt i "RLC Acknowledged Mode") som gjør det mulig å sende statusrapporter fra en mottakernode til en sendernode og gjør det mulig for en sendernode å spørre mottakernoden om en status. Som reaksjon på mottak av en statusrapport kan sendernoden sende eventuelle tapte data på nytt eller iverksette andre passende tiltak. Som reaksjon på en spørring (poll) sender en mottaker normalt en statusrapport. Utsending av en statusrapport kan imidlertid under visse omstendigheter ikke være tillatt. For eksempel kan en status deaktivert-timer, startet ved utsending av en foregående statusrapport, hindre utsending av nye statusrapporter under en tidsperiode. [0003] Utviklerne i 3GPP har også blitt enige om å spesifisere et sett av poll- og statusutløsere, i tillegg til timere som regulerer en nodes respons til enten en poll eller en statusrapport. Eksempler på utløsere og timere som det nylig har blitt enighet om å innlemme i standardene innenfor 3GPP LTE inkluderer: automatisk statusrapportering dersom det oppdages en manglende protokolldataenhet (PDU - Protocol Data Unit); automatisk polling som reaksjon på utsending av den siste PDU-en i et sendebuffer, slik at sendernoden gis en garanti for at et sett av data er fullt mottatt; en status deaktivert-timer for å hindre at en node sender ut statusrapporter for ofte, siden for hyppige statusrapporter kan resultere i unødvendig gjensending; og

3 1 2 2 en gjensend poll-timer, for å sikre at en ubesvart poll, som kan være tapt, blir sendt på nytt. [0004] Naturligvis vil trolig også ytterligere utløsere og timere bli tatt inn i LTE. Det kan forventes at protokollen RLC ARQ for LTE til syvende og sist vil ha mange likheter med RLC-protokollen Wideband-CDMA (W-CDMA) spesifisert i 3GPP TS I tillegg til kvittert modus (Acknowledged Mode) vil RLC-protokollen for LTE også innbefatte en ukvittert modus og en transparent modus. [000] I et tradisjonelt RLC ARQ-skjema blir timere og statusrapporter for RLC opprettet som reaksjon på bestemte utløsere. Dersom for eksempel en mottakernode mottar en poll og ingen status deaktivert-tidmåler kjører, genererer mottakernoden umiddelbart en statusrapport som representerer gjeldende mottakerstatus. En typisk statusrapport kan inkludere en identifikator for en siste mottatt protokolldataenhet (PDU) og/eller en negativ kvittering for én eller flere PDU-er som ikke ble mottatt korrekt. Statusrapporten blir så tilbudt til mediaksess-(mac--media Access Control)- laget for overføring til sendernoden. (Fagmannen vil vite at enhver trådløs kommunikasjonsnode typisk vil innbefatte en sender og en mottaker. Videre kan et ARQ-skjema bli implementert i begge retninger. For formålet med denne beskrivelsen skal betegnelsen "sendernode" generelt henvise til den noden som sender ut én eller flere data-pdu-er, i kvittert modus, til en "mottakernode." I 3GPP-terminologi blir kvittert modus-data sendt av "sendersiden av en RLC-entitet med kvittert modus"; PDU-ene blir sendt til "peer-entiteten", eller "mottakersiden", av en RLC-entitet med kvittert modus. Gitt denne bruken kan en mottakernode sende en status-pdu til sendernoden. Likeledes kan en sendernode motta en status-pdu.) [0006] I systemer som anvender en status deaktivert-timer vil mottakernoden typisk starte status deaktivert-timeren i det øyeblikk statusrapporten blir sendt fra RLC-laget til MAC-laget. Etter dette tillates ingen ytterligere statusrapporter sendt ut før timeren har utløpt, selv om én eller flere nye utløsere for en statusrapport skulle inntreffe i mellomtiden. Slike utløsere kan være en ytterligere poll mottatt fra sendernoden, deteksjon av en manglende PDU eller liknende. Tidsperioden med statusforbud sikrer således at en påfølgende statusrapport blir forsinket i hvert fall med tidsperioden spesifisert av status deaktivert-timeren.

4 1 3 [0007] I LTE-systemer er opplinjen (for overføring fra mobil stasjon til basestasjon) en fordelt ressurs, hvor fordelingen styres av en tjenerbasestasjon (kalt en "evolved Node B", eller enodeb, i LTE). Som følge av dette vil ikke en mobil stasjon nødvendigvis ha umiddelbar tilgang til overføringsressurser på et gitt tidspunkt. Dersom MAC-laget i en mobil stasjon mottar en statusrapport fra RLC-laget på et tidspunkt ingen opplinjeressurser er satt av, må den mobile stasjonen først be om disse ressursene før den kan sende statusrapporten til enodeb-basestasjonen. Siden fordelingen styres av enodeb-tjeneren, kan det forekomme at tildelingen av opplinjeressurser blir betydelig forsinket. For eksempel kan flerbrukerfordeling medføre en tregere allokering av ressurser, eller en innledende skeduleringsforespørsel kan komme bort under overføring. Som følge av dette kan overføringen av statusrapporten forsinkes i en slik grad at mottakertilstanden som beskrives av statusrapporten kan være utdatert allerede før den blir sendt ut. [0008] US06/ vedrører en gjensendingsmekanisme, og omtaler statusrapporter og status deaktivert-timere. Dette patentskriftet beskriver at en statusrapport ikke vil bli sendt før dette tillates av en deaktiveringsfunksjon, f.eks. en timer. 2 OPPSUMMERING [0009] Det vil her bli vist fremgangsmåter og anordninger for prosessering av feilkontrollmeldinger, så som ARQ-kontrollmeldinger i RLC. Et eksempel på en fremgangsmåte omfatter å signalisere en mediumaksesskontroller (MAC) om at linkressurser er nødvendig for å sende data, motta en angivelse fra MAC-kontrolleren om at linkressurser for å sende dataene er satt av, og generere feilkontrollmeldingen etter mottak av angivelsen, basert på en gjeldende feilkontrollstatus. Feilkontrollmeldingen blir så videresendt til MAC-kontrolleren for overføring. Siden genereringen av en feilkontrollmelding utsettes til ressurser for overføring av denne er satt av, unngår en å legge i kø og overføre foreldede kontrollmeldinger. [00] I et annet aspekt ved oppfinnelsen kan MAC-kontrolleren varsle radiolinkkontrolleren (RLC) når utsending av en RLC ARQ-kontrollmelding enten er begynt eller kvittert for. Som reaksjon på varslingen kan RLC-kontrolleren starte eller

5 4 omstarte en feilkontroll-timer. Timeren kan for eksempel omfatte en poll-timer eller en status deaktivert-timer. 1 KORT BESKRIVELSE AV TEGNINGENE [0011] Figur 1 er en forenklet betraktning av et kommunikasjonssystem ifølge en utførelsesform av oppfinnelsen. Figur 2 illustrerer flere kommunikasjonsprotokollag som kan bli anvendt i systemet i figur 1. Figur 3 illustrerer innvirkningen av forsinket fordeling på dannelse av en ARQstatusrapport. Figur 4 illustrerer innvirkningen av forsinket fordeling på en ARQ poll-timer. Figur illustrerer timing for generering av en ARQ-statusrapport ifølge én utførelsesform av oppfinnelsen. Figur 6 illustrerer prosessering i tilknytning til en poll-timer ifølge én utførelsesform av oppfinnelsen. Figur 7 er et logisk flytdiagram som illustrerer et eksempel på en fremgangsmåte for prosessering av feilkontrollmeldinger. Figur 8 er et blokkdiagram av en trådløs anordning i samsvar med én eller flere utførelsesformer av foreliggende oppfinnelse. 2 DETALJERT BESKRIVELSE [0012] Figur 1 viser en forenklet betraktning av et kommunikasjonssystem, som innbefatter en sendernode 1 og en mottakernode 1. Som angitt over omfatter sendernoden 1 og mottakernoden 1 begge en komplett transceiver; betegnelsene "sender" og "mottaker" blir anvendt for å beskrive bestemte endepunkter i en dataoverføring med kvittering. Sendernoden 1 sender således én eller flere dataenheter, som kan omfatte protokolldataenheter (PDU-er), til mottakernoden 1, og kan også sende én eller flere feilkontrollmeldinger, så som en poll-forespørsel. (Som vil bli beskrevet nedenfor kan en feilkontrollmelding, så som en poll, være innlemmet i samme protokolldataenhet som trafikkdata.) Mottakernoden 1 kan i sin tur sende én

6 1 2 eller flere feilkontrollmeldinger, så som en statusrapport eller en forespørsel om gjensending av en PDU som ikke ble mottatt korrekt. [0013] I noen utførelsesformer av foreliggende oppfinnelse kan sendernoden 1 omfatte en LTE-type enodeb og mottakernoden 1 kan omfatte en LTE-kompatibel mobil stasjon. I dette tilfellet blir dataenhetene vist i figur 1 sendt, av enodeb-tjeneren, på nedlinjen, mens én eller flere feilkontrollmeldinger blir sendt på opplinjen. Imidlertid vil fagmannen forstå et ARQ-skjema også kan bli implementert i motsatt retning for å detektere feil i levering av PDU-er over opplinjen. I dette tilfellet er rollene som sender- og mottakernode reversert mellom enodeb-tjeneren og den mobile stasjonen. [0014] Selv om den hittil ukjent teknikken som vises her er beskrevet med støtte i et LTE-system, er ikke foreliggende oppfinnelse begrenset til et slikt system. Fagmannen, ved lesning av den følgende beskrivelsen og betraktning av de vedlagte figurene, vil forstå at teknikken som beskrives her kan bli anvendt i en rekke forskjellige trådløse systemer, og spesielt i systemer som dynamisk fordeler overføringsressurser på opplinjen, nedlinjen eller begge. [001] Hver av kommunikasjonsnodene i figur 1 er innrettet for å jobbe i henhold til en spesifisert kommunikasjonsprotokoll, så som LTE-protokollene spesifisert av 3GPP. Flere protokollag er illustrert i figur 2; disse protokollagene kan være implementert i hver av kommunikasjonsnodene ved hjelp av analog og digital maskinvare, programmerbare prosessorer forsynt med passende programvare, eller en kombinasjon. Spesielt kan sendernoden 1, som kan være en LTE-bevisst mobil stasjon, anvende protokollagene i protokollstakken 2 for å kommunisere med motsvarende protokollag i protokollstakken 2 hos mottakernoden 1, f.eks. en LTE-type enodeb. [0016] Hver av protokollstakkene 2 og 2 innbefatter et fysisk lag, et datalinklag og et nettverkslag. Datalinklaget er delt inn i to lag, et radiolinkkontroll-(rlc)-lag og et mediumaksesskontroll-(mac)-lag. I dette utførelseseksempelet er nettverkslaget delt inn i en kontrollplanprotokoll (RRC) og en brukerplanprotokoll (IP). [0017] I et LTE-system anvender det fysiske lag OFDMA-(Orthogonal Frequency Division Multi Access)-teknologi for nedlinjen, og den nært beslektede SC-FD-MA

7 1 2 6 (Single-Carrier Frequency Division Multiple Access) for opplinjen. Generelt sørger det fysiske lag for dataoverføring over luftgrensesnittet (radiogrensesnittet), og inkluderer funksjoner som multipleksing og demultipleksing av transportkanaler, avbildning av transportkanaler til fysiske kanaler, modulering og demodulering av fysiske kanaler, koding og dekoding for forover feilkorreksjon, frekvens- og tidssynkronisering, styring av sendereffekt, radiofrekvensprosessering og liknende. [0018] Mediumaksesskontroll-(MAC)-laget sørger generelt for ukvittert overføring av nyttedataenheter (SDU-er) mellom likestilte MAC-entiteter. MAC-funksjoner kan inkludere valg av et passende transportformat for hver transportkanal avhengig av datahastighet, håndteringsprioriteter mellom datastrømmer for forskjellige brukere (i en basestasjon som støtter flere brukere), fordeling av kontrollmeldinger, multipleksing og demultipleksing av høyere lags PDU-er, etc. I et LTE-system blir fordelingen av ressurser også utført av MAC-laget. Spesielt kan et MAC-lag for en mobil stasjon be om opplinjeressurser, som blir allokert mellom mobile stasjoner av det motsvarende MAC-laget i enodeb-tjeneren. [0019] RLC-laget utfører forskjellige funksjoner, herunder opprettelse, frigjøring og oppretthold av en RLC-forbindelse, oppdeling og gjensammensetting av høyere lags PDU-er med variabel lengde til eller fra mindre RLC PDU-er, sammenkjeding, feilkorreksjon ved gjensending (ARQ), sekvensiert levering av høyere lags PDU-er, duplikatdeteksjon, flytkontroll og andre funksjoner. [00] RRC-protokollen sørger for kontrollsignalering over radiogrensesnittet, f.eks. kontrollsignalisering i tilknytning til radioaksessbærere, rapportering av målinger og signalisering ved overlevering. Brukerplandelen av nettverkslaget inkluderer de tradisjonelle funksjonene som blir utført av lag 3-protokollene, så som den velkjente IP-protokollen (Internet Protocol). [0021] RLC-(Radio Link Control)-protokollaget i protokollstakkene 2 og 2 inkluderer en ARQ-(Automatic Repeat request)-mekanisme. RLC-laget i en sendernode 1 mottar brukerdata, segmenterer dem og omgjør dem til RLC-PDU-er. I noen utførelsesformer kan en sendt RLC-PDU inneholde et felt som angir om den sendte meldingen er en data-pdu eller en kontroll-pdu. Et annet felt kan svare til et poll-felt, som kan inneholde en bit som angir at sendernoden 1 ønsker en

8 1 2 7 statusrapport fra mottakernoden. RLC-PDU-en kan videre omfatte et "sekvensnummerfelt" som angir sekvensnummeret til en data-pdu; dette sekvensnummeret kan bli tellet opp for hver nye data-pdu. Endelig inneholder et datafelt segmenter av informasjon om høyere-nivå data. Et "lengdeindikator"-felt og et "utvidelse"-felt kan også være innlemmet i en RLC-PDU. [0022] Som reaksjon på en PDU der poll-biten P er satt til "1", kan mottakernodens RLC-lag generere en statusrapport som angir hvilke RLC-PDU-er som har blitt korrekt mottatt. Positive eller negative kvitteringer, eller en kombinasjon av begge, kan bli anvendt. I LTE inkluderer en statusrapport-pdu et felt ACK-SN (Acknowledgement Sequence Number) som angir den laveste sekvensen blant PDU-ene som hverken har blitt mottatt eller detektert som tapt av mottakernoden. Statusrapport-PDU-en kan videre inkludere ett eller flere NACK_SN-(Negative Acknowledgement Sequence Number)-felter som identifiserer PDU-er detektert som tapt av mottakernoden. Når en sendernode 1 mottar en statusrapport-pdu, slår den således fast at alle PDU-er opp til, men ikke inkludert, PDU-en svarende til ACK_SN-feltet har blitt mottatt, bortsett fra PDU-ene identifisert av det ene eller de flere NACK_SN-feltene. [0023] Som nevnt kort over kan dynamisk fordeling av ressurser i noen systemer forårsake forsinkelser mellom genereringen av feilkontrollmeldinger, så som poll- PDU-ene eller statusrapport-pdu-ene omtalt her, og den faktiske overføringen av disse meldingene. I systemer hvor overføringsressurser hele tiden er tilgjengelig, så som i 3GPPs W-CDMA-systemer, blir typisk en RLC-kontrollmelding (f.eks. statusrapport- PDU eller poll-pdu) sendt umiddelbart etter at den er generert, sett bort i fra en kort prosesseringsforsinkelse. Når en statusrapport blir sendt, for eksempel, viser den et i alminnelighet nøyaktig "øyeblikksbilde" av mottakerens tilstand. I LTE, derimot, er opplinjen strengt fordelt og den mobile stasjonen har typisk ikke uavbrutt tilgang til slike ressurser. Dersom den mobile stasjonen ikke er avsatt ressurser, må MAC-laget i den mobile stasjonen først be om opplinjeressurser før den kan sende statusrapport- PDU-en. Den resulterende forsinkelsen kan gjøre at statusrapporten er foreldet før den faktisk blir sendt til enodeb-tjeneren. [0024] Dette problemet er illustrert i figur 3, hvor hendelser ved en enodeb-tjener er illustrert langs den øvre horisontale linjen og hendelser ved en mobil terminal er

9 1 2 8 illustrert langs den nedre horisontale linjen. Hendelsesflyten i figur 3 begynner med overføring av en poll-forespørsel fra enodeb-tjeneren til den mobile stasjonen, som vist på venstre side i figuren. I et tradisjonelt system, som angitt over, genererer den mobile terminalen umiddelbart (bortsett fra for prosesseringsforsinkelser) en statusrapport. I et LTE-system, som angitt over, kan denne statusrapporten angi at én eller flere PDU-er (eller deler av disse) sendt i kvittert modus er mistet, eller ikke prosessert korrekt. [002] Etter at RLC-laget har generert statusrapporten, blir statusrapporten sendt til MAC-laget for levering til enodeb-tjeneren. I den viste hendelsesflyten er imidlertid ressurser ikke umiddelbart tilgjengelig for å sende data over opplinjen. MAC-laget ber derfor om opplinjeressurser fra enodeb-tjeneren ved å sende en skeduleringsforespørsel. Som angitt over kan tildelingen av opplinjeressurser være beheftet med betydelige forsinkelser. Disse forsinkelsene kan oppstå rett og slett fordi enodeb-tjeneren betjener mange mobile stasjoner, eller fordi enodeb-tjeneren på det aktuelle tidspunkt allokerer ressurser til forespørseler med høyere prioritet. I noen tilfeller kan forsinkelser oppstå eller bli større som følge av at ressursforespørselen ikke blir korrekt mottatt av enodeb-tjeneren, slik at forespørselen må gjentas. [0026] Under alle omstendigheter blir tildelingen av opplinjeressurser i hendelsesflyten vist i figur 3 til slutt mottatt av den mobile terminalen, men etter en betydelig skeduleringsforsinkelse. Denne forsinkelsesperioden er illustrert i figur 3 sett fra et RLC-perspektiv, dvs. fra det øyeblikk feilkontrollmeldingen (statusrapporten) blir videresendt av RLC-kontrolleren til MAC-kontrolleren til det tidspunkt MACkontrolleren mottar tildelingen av opplinjeressurser. I dette tidsrommet blir flere ytterligere RLC-PDU-er, nemlig PDU 1 og PDU 2, mottatt av den mobile terminalen. Når statusrapporten blir sendt til enodeb-tjeneren, som illustrert på høyre side i figuren, er statusrapporten derfor allerede foreldet. Siden statusrapporten ikke gjenspeiler mottaket av PDU 1 og PDU 2, har enodeb-tjeneren blitt gitt unøyaktig informasjon når det gjelder gjeldende status for mottakeren i den mobile stasjonen. Dette vil kunne resultere i at PDU 1 og PDU 2 blir sendt på nytt, noe som er bortkasting av nedlinjeressurser og potensielt kan føre til ytterligere forsinkelser i køede data.

10 1 2 9 [0027] Skeduleringsforsinkelser kan også forårsake problemer med virkemåten til timere i tilknytning til feilkontrollprosesser. Dersom for eksempel en RLC-timer som styrer utsendingen av statusrapporter, så som status deaktivert-timeren, blir startet når PDU-en som inneholder statusrapporten blir tilbudt til MAC-laget, kan det forekomme at timeren utløper for tidlig. I verste fall kan RLC-laget tilby flere RLC-statusrapporter til MAC-laget, som alle blir lagt i kø for utsending. Dersom disse statusrapportene inneholder en negativ kvittering for de samme RLC-PDU-ene, kan de samme PDU-ene bli sendt på nytt flere ganger av den likestilte RLC-entiteten. [0028] Et tilsvarende problem kan oppstå for timere som styrer polling. Dersom en poll-timer blir startet når PDU-en som inneholder poll-dataene blir tilbudt til MAClaget, vil poll-timeren kunne utløpe for tidlig som følge av forsinkelse i overføringen av PDU-enheten som inneholder poll-dataene. Dette kan føre til at unødvendige poll blir lagt i kø og sendt til mottakeren. Dette er illustrert i hendelsesflyten i figur 4. Som i figur 3 er hendelser ved en enodeb-tjener illustrert langs den øvre horisontale linjen, mens hendelser ved den mobile terminalen er vist langs den nedre linjen. På venstre side av figuren blir en poll-kontrollmelding, Poll 1, generert av enodeb-tjeneren på RLC-laget. Poll-kontrollmeldingen blir umiddelbart videresendt til MAC-laget for overføring til den mobile terminalen, og en poll-timer, som etablerer en minimumsforsinkelse før en ny poll-forespørsel kan bli generert, blir startet. Meldingen Poll 1 blir imidlertid ikke faktisk sendt til den mobile terminalen før etter en betydelig forsinkelse, som kan være en følge av skeduleringsforsinkelser ut fra en duplisert overføringskø. [0029] I noen tilfeller kan forsinkelsen i utsendingen av poll-forespørselen vare til etter at poll-timeren utløper, som vist i figur 4. Når poll-timeren utløper, genererer RLClaget, som ikke er klar over at den foregående poll-meldingen ikke ble sendt, en andre poll-forespørsel, Poll 2. Denne andre poll-forespørselen blir sendt videre til MAClaget, og poll-timeren startes på nytt. [00] Til slutt blir den første poll-forespørselen (Poll 1) sendt til den mobile stasjonen. I det illustrerte scenariet er ikke forsinkelsene på opplinjen store, så en statusrapport blir returnert etter kort tid. Kort etterpå blir den andre poll-forespørselen (Poll 2) sendt ut av enodeb-tjeneren og mottatt av den mobile terminalen. Selv om en status

11 1 2 deaktivert-timer kan hindre generering og utsending av en ny statusrapport av den mobile terminalen, er den andre poll-forespørselen åpenbart unødvendig og bortkastede systemressurser. [0031] Figurene 3 og 4 illustrerer kun noen få av de tidsstyringsproblemene knyttet til RLC-feilkontroll som vil kunne oppstå som følge av forsinkelser i fordeling og køleggelse i et trådløst system med avsatte ressurser. Et annet problem er at statusrapporter eller poll-forespørseler kan bli forsinket fordi data med høyere prioritet data allerede er lagt i kø. Betrakt en mobil terminal (en mottakernode med hensyn til nedlinjen, en sendernode med hensyn til opplinjen) med flere bærere, eller "logiske kanaler", med forskjellig prioritet. Anta at den mobile terminalen har data i senderbufferet for bæreren med høyest prioritet og at den mobile terminalen mottar ressurstildelinger fra enodeb-tjeneren som ikke etterlater noen båndbredde for overføring av PDU-er for bærere med lavere prioritet. Anta videre at det utløses en trigger for å sende en statusrapport eller en poll-forespørsel på en bærer med lavere prioritet. Siden den mobile terminalen mangler ressurser for å sende denne PDU-en, kan statusrapporten eller poll-forespørselen bli betydelig forsinket. Som i scenariene beskrevet over kan statusrapporten i noen tilfeller bli utdatert før den blir sendt. I ekstreme tilfeller kan flere statusrapporter eller poll-forespørseler bli lagt i kø før ressurser til bæreren med lavere prioritet er tilgjengelig, noe som resulterer i unødvendige gjensendinger. [0032] En løsning på flere av de ovennevnte problemer er å modifisere de tradisjonelle ARQ-prosessene beskrevet over på en slik måte at innholdet i en feilkontrollmelding (f.eks. en RLC-PDU som inneholder ARQ-kontrollinformasjon) kun blir generert når MAC-laget kan tilby ressurser for å sende RLC PDU-en. I noen utførelsesformer kan dette oppnås ved å tilveiebringe et ytterligere eller et modifisert grensesnitt mellom RLC-laget og MAC-laget. Dette ytterligere grensesnittet kan gjøre det mulig for RLClaget å be MAC-laget om å sende en RLC-PDU som inneholder kontrollinformasjon. I tillegg gjør dette ytterligere grensesnittet det mulig for MAC-laget å varsle RLC-laget når linkressurser er tilgjengelig for å sende en RLC-PDU som inneholder kontrollinformasjon. På denne måten kan RLC-laget utsette den faktiske genereringen av kontrollinformasjonen til ressursene er tilgjengelig, slik at den feilkontrollmeldingen

12 som til syvende og sist blir levert inneholder oppdatert informasjon om RLC-lagets tilstand. [0033] Over dette grensesnittet kan RLC-laget i en kommuniserende node (f.eks. en mobil stasjon) først rapportere et behov til MAC-laget for å sende en RLC-ARQkontrollmelding, så som en statusrapport. Når MAC-laget varsler til RLC-laget at de nødvendig ressursene er (eller snart vil bli) tilgjengelige, oppretter RLC-laget da den relevante kontrollinformasjonen (f.eks. informasjon for statusrapporten), pakker kontrollinformasjonen inn i en RLC-PDU, og sender RLC-PDU-en til MAC-laget for utsending til den fjerne noden. Utførelsesformer av oppfinnelsen dekker tilfellene hvor RLC-PDU-en inneholder enten en RLC-statusrapport eller en poll, og kan bli anvendt på samme måte for andre feilkontrollmeldinger. [0034] Figur viser et hendelsesflytdiagram, tilsvarende de i figurene 3 og 4, som illustrerer virkemåten til et system ifølge noen utførelsesformer av oppfinnelsen. Som i figur 3 blir en poll-forespørsel sendt ut av enodeb-tjeneren og mottatt av den mobile terminalen, på venstre side i figuren. Som reaksjon på denne triggeren fastslår RLClaget i den mobile terminalen at opplinjeressurser vil være nødvendig for å sende ut en feilkontrollmelding, i dette tilfellet en statusrapport. RLC-laget signaliserer derfor MAC-laget om at opplinjeressurser er nødvendig, som angitt i figur. MAC-laget svarer med å be om opplinjeressurser fra ressursfordeleren, dersom ressurser ikke allerede er avsatt. [003] Fagmannen vil forstå at signaleringen fra RLC-laget til MAC-laget om at opplinjeressurser er nødvendig kan, men ikke spesifikt trenger å angi at disse ressursene er nødvendig for overføring av en feilkontrollmelding. I noen utførelsesformer kan signalet således kun angi at en RLC-PDU skal sendes ut, og at opplinjeressurser må bli satt av dersom slike ikke allerede er tilgjengelig. I andre utførelsesformer kan det være nyttig om signaleringen spesifikt angir at ressursene er nødvendige for en kontrollmelding. [0036] Under alle omstendigheter kan den faktiske tildelingen av ressurser skje etter en betydelig forsinkelse, som illustrert i figur. Under denne forsinkelsen blir flere RLC- PDU-er i kvittert modus, PDU 3 og PDU 4, mottatt ved den mobile terminalen under skedueringsforsinkelsen. I dette scenariet har imidlertid statusrapporten enda ikke blitt

13 generert, og er ikke lagt i kø i MAC-laget i påvente av utsending. I stedet, som illustrert i figur, venter RLC-laget med å generere dataene for statusrapporten til etter at MAClaget har informert RLC-laget om at forespørselen om opplinjeressurser har blitt innvilget (dvs. at opplinjeressurser er tilgjengelig). Statusrapporten inneholder således oppdaterte data (herunder status for PDU 3 og PDU 4) når den blir videresendt til MAC-laget og overført til enodeb-tjeneren. Selv om det fortsatt kan forekomme forsinkelser i forbindelse med prosessering og køleggelse, er disse forsinkelsene minimale sammenliknet med situasjonen illustrert i figur 3. [0037] Noen utførelsesformer av foreliggende oppfinnelse anvender tilsvarende metoder for å starte og restarte timere for feilkontrollprosessering, så som poll-timeren og status deaktivert-timeren i RLC ARQ omtalt over. I disse utførelsesformene kan aktivering av en feilkontroll-timer bli utløst av en melding fra MAC-laget (til RLClaget) om at en RLC-PDU som inneholder feilkontrollinformasjon har blitt sendt, eller er i ferd med å bli sendt, til den fjerne noden. [0038] Et eksempel på virkemåte for én slik utførelsesform er illustrert i figur 6. I denne hendelsesflyten, som i hendelsesflyten illustrert i figur 4, blir poll-forespørselen utløst i enodeb-tjeneren. RLC-PDU-en som inneholder poll-forespørselen blir videresendt til MAC-laget for overføring til den mobile terminalen. I dette tilfellet blir imidlertid poll-timeren ikke startet umiddelbart. I stedet blir poll-timeren startet etter at MAC-laget har informert RLC-laget om at poll-forespørselen har blitt sendt. Som illustrert i figur 6 kan dette skje etter en betydelig skedulerings-/køleggingsforsinkelse. Siden start av poll-timeren ble utsatt til det tidspunktet eller nær det tidspunktet pollforespørselen faktisk ble sendt, vil ikke timeren utløpe før mottak av statusrapporten fra den mobile terminalen. På den måten unngås unødvendig gjensending av pollforespørselen. [0039] I noen utførelsesformer kan MAC-laget være innrettet for å varsle RLC-laget om at utsending av PDU-en som inneholder RLC ARQ-kontrollinformasjonen har begynt, eller er i ferd med å begynne. I andre utførelsesformer kan MAC-laget i stedet varsle RLC-laget om at utsendingen av PDU-en som inneholder RLC ARQkontrollinformasjonen har blitt kvittert for på MAC HARQ-laget. Fagmannen vil forstå

14 at teknikken beskrevet over med hensyn til en poll-timer også kan bli anvendt for andre feilkontroll-timere, så som en status deaktivert-timer. [0040] Figur 7 er et logisk flytdiagram som illustrerer et eksempel på en fremgangsmåte for prosessering av feilkontrollmeldinger som kan bli utført av én eller flere av RLC- og MAC-kontrollerene omtalt over. I den illustrerte fremgangsmåten blir den hittil ukjente teknikken som vises her anvendt både for generering av en feilkontrollmelding og for aktivering av en feilkontroll-timer. Fagmannen vil naturligvis forstå at mange utførelsesformer av oppfinnelsen vil anvende denne teknikken på begge feilkontrollprosesser, og at noen kan anvende teknikken på den ene prosessen eller den andre, men ikke begge. [0041] Uansett begynner fremgangsmåteeksempelet i figur 7 i trinn 7 med signalisering, til MAC-kontrolleren i en kommunikasjonsnode, av at linkressurser er nødvendig for overføring av en feilkontrollmelding. Som angitt over kan dette utløses av en hvilken som helst av flere mulige hendelser. For eksempel vil mottak av en pollforespørsel ved en mottakernode i alminnelighet utløse en statusrapportprosess. I dette tilfellet er signaliseringen om linkressurser i trinn 7 for ressurser til å sende statusrapporten. En annen mulig utløsende hendelse er at en feilkontroll-timer utløper. For eksempel kan utløp av en poll-timer utløse en ny poll-forespørsel, i hvilket tilfelle signaliseringen i trinn 7 kan være for å be om ressurser for å utløse den nye pollforespørselen. [0042] Under alle omstendigheter blir i trinn 7 en angivelse mottatt fra MACkontrolleren om at linkressurser er tilgjengelig. Som beskrevet utførlig over kan dette skje nesten umiddelbart etter forespørselen om ressurser, eller kan skje etter en betydelig skeduleringsforsinkelse. Uansett blir en feilkontrollmelding generert i trinn 7, som reaksjon på angivelsen om at linkressurser er tilgjengelig. På den måten blir innholdet til feilkontrollmeldingen generert basert på en gjeldende status, og "foreldes" ikke av en skeduleringsforsinkelse. I trinn 740 blir feilkontrollmeldingen videresendt til MAC-kontrolleren for overføring. Siden meldingsgenereringen i trinn 7 og videresendingen av meldingen i trinn 740 ble utsatt til etter angivelsen om at ressurser er tilgjengelig, minimeres overføringsforsinkelser etter videresending til MACkontrolleren.

15 [0043] I trinn 70 blir en varsling mottatt fra MAC-kontrolleren om at utsending av feilkontrollmeldingen har begynt, eller er ferdig. Som reaksjon på denne varslingen blir en passende feilkontroll-timer, så som en poll-timer eller en status deaktivert-timer, aktivert, som vist i trinn 760. [0044] RLC- og MAC-operasjonene beskrevet her kan bli implementert henholdsvis av en RLC-kontroller og en MAC-kontroller, som henholdvis implementerer RLC- og MAC-laget i protokollstakkene 2 og 2 omtalt tidligere. Fagmannen vil forstå at disse operasjonene kan implementeres ved å modifisere tradisjonelle RLC-kontrollere og MAC-kontrollere, som, som angitt over, kan være realisert av én eller flere programmerbare prosessorer, maskinvarekretser eller en kombinasjon av dette. [004] Videre kan fremgangsmåtene beskrevet her bli utført i den ene eller begge ender av en trådløs forbindelse, så som de mobile LTE-terminalene eller enodeb-tjenerene omtalt over. Figur 8 illustrerer de generelle trekkene ved en trådløs kommunikasjonsanordning i samsvar med én eller flere utførelsesformer av oppfinnelsen; den illustrerte trådløse anordningen 800 kan omfatte, i forskjellige utførelsesformer, en mobil terminal (for eksempel en mobiltelefon, trådløs personlig digital assistent, trådløs personlig datamaskin, "maskin-til-maskin"-anordning etc.), en basestasjon, en gjentaker, eller en annen node som terminerer en trådløs forbindelse. [0046] Den trådløse anordningen 800 i figur 8 inkluderer en radiotransceiver 8 i stand til å kommunisere over én eller flere radiolinker med en fjern transceiver, via en antenne 81. I noen utførelsesformer er radiotransceiveren 8 innrettet for å motta og sende ut signaler formatert i henhold til en standard, så som en hvilken som helst av de trådløse standardene fra 3GPP. Spesielt kan radiotransceiveren 8 være innrettet for å sende ut og/eller motta OFDMA- og SC-FDMA-signaler i henhold til LTEstandardene. [0047] Den trådløse anordningen 800 inkluderer videre en mediumaksesskontrollfunksjon 8, en radiolinkkontroll-funksjon 8 og annen prosessering 840. De generelle oppgavene til MAC- og RLC-funksjonene er beskrevet over; disse funksjonene kan være implementert i en hvilken som helst av en rekke mulige kombinasjoner av analog og digital maskinvare og programmerbare prosessorer forsynt med programvare. Fagmannen vil forstå at disse funksjonene, så vel som andre

16 1 2 1 funksjoner nødvendig for drift av den trådløse anordningen 800, kan være implementert ved hjelp av én eller flere programmerbare prosessorer. I mange utførelsesformer er MAC- 8 og RLC-funksjonene 8 implementert som en protokollstakk, så som protokollstakken 2 i figur 2, implementert på én enkelt mikroprosessor eller en applikasjonsspesifikk integrert krets forsynt med programvare for å utføre de forskjellige RLC- og MAC-funksjonene beskrevet her. [0048] Spesielt kan RLC-kontrolleren 8 være realisert på en mikroprosessor programmert med programvare som definerer et RLC-lag, hvor RLC-laget er innrettet for å signalisere til en mediumaksesskontroller at linkressurser er nødvendig for å sende data, motta en angivelse fra mediumaksesskontrolleren om at linkressurser for å sende dataene er satt av og, som reaksjon på angivelsen, generere en feilkontrollmelding basert på en gjeldende feilkontrollstatus for RLC-laget. Feilkontrollmeldingen kan omfatte, men er ikke begrenset til, en poll-forespørsel eller en statusrapport. I noen utførelsesformer kan RLC-laget videre være innrettet for å motta en varsling om at utsending av feilkontrollmeldingen har begynt og for å starte en feilkontroll-timer som reaksjon på varslingen. Feilkontroll-timeren kan omfatte, men er ikke begrenset til, en poll-timer eller en status deaktivert-timer. [0049] Tilsvarende kan hele eller en del av MAC-kontrolleren 8 være realisert på den samme mikroprosessoren, eller på én eller flere andre mikroprosessorer, programmert med programvare som definerer et MAC-lag. MAC-laget er innrettet for å motta et signal fra RLC-laget som angir at linkressurser er nødvendig for å sende data, og for å be om linkressurser etter behov. MAC-laget er videre innrettet for å informere RLC-laget når den mottar en tildeling av ressurser. I noen utførelser er MAC-laget videre også innrettet for å informere RLC-laget når en feilkontrollmelding (levert til MAC-laget av RLC-laget) har blitt sendt eller, i noen utførelsesformer, når utsending av feilkontrollmeldingen er umiddelbart forestående. [000] Idéene i foreliggende oppfinnelse kan selvfølgelig realiseres på andre måter enn de spesifikt angitt her uten å fjerne seg fra de grunnleggende trekkene ved oppfinnelsen. De viste utførelsesformene skal i alle henseende betraktes som en illustrasjon og ikke som en begrensning, og alle endringer som faller innenfor rammen til de vedføyde kravene er ment å omfattes av disse.

17 16 P a t e n t k r a v 1. Fremgangsmåte for behandling av timere for feilkontrollprosessering i et trådløst kommunikasjonssystem, k a r a k t e r i s e r t v e d at fremgangsmåten omfatter det å: signalisere (7) til en mediumaksesskontroller at linkressurser er nødvendig for å sende data; motta (7) en angivelse fra mediumaksesskontrolleren om at linkressurser for å sende dataene er tilgjengelig; som reaksjon på angivelsen, generere (7) en feilkontrollmelding basert på en gjeldende feilkontrollstatus, sende (740) feilkontrollmeldingen til mediumaksesskontrolleren for utsending og starte (760) en feilkontroll-timer, og hindre at en ytterligere feilkontrollmelding blir generert før feilkontroll-timeren utløper Fremgangsmåte ifølge krav 1, k a r a k t e r i s e r t v e d at feilkontrolltimeren er én av en gjensend poll-timer og en status deaktivert-timer. 3. Fremgangsmåte ifølge de foregående krav 1 eller 2, k a r a k t e r i s e r t v e d at feilkontrollmeldingen omfatter en ARQ (Automatic Repeat request) statusrapportmelding Fremgangsmåte ifølge de foregående krav 1 eller 2, k a r a k t e r i s e r t v e d at feilkontrollmeldingen omfatter en gjensendingsforespørsel.. Fremgangsmåte ifølge de foregående krav 1 eller 2, k a r a k t e r i s e r t v e d at feilkontrollmeldingen omfatter en ARQ poll-melding. 6. Fremgangsmåte ifølge de foregående krav 1 eller 2, k a r a k t e r i s e r t v e d at fremgangsmåten videre omfatter det å: motta (70) en varsling om at utsending av feilkontrollmeldingen har begynt.

18 17 7. Fremgangsmåte ifølge de foregående krav 1 eller 2, k a r a k t e r i s e r t v e d at fremgangsmåten videre omfatter det å: motta (70) en varsling fra mediumaksesskontrolleren om at feilkontrollmeldingen har blitt kvittert for Trådløs kommunikasjonsanordning (800) for behandling av timere for feilkontrollprosessering, omfattende en radiotransceiver (8), en mediumaksesskontroller (8) og en radiolink-kontroller (8), k a r a k t e r i s e r t v e d at radiolink-kontrolleren (8) er innrettet for å: signalisere til mediumaksesskontrolleren (8) at linkressurser er nødvendig for å sende data; motta en angivelse fra mediumaksesskontrolleren (8) om at linkressurser for å sende dataene er tilgjengelig; som reaksjon på angivelsen, generere en feilkontrollmelding basert på en gjeldende feilkontrollstatus, sende feilkontrollmeldingen til mediumaksesskontrolleren (8) for utsending og starte en feilkontroll-timer, og hindre at en ytterligere feilkontrollmelding blir generert før feilkontroll-timeren utløper. 9. Trådløs kommunikasjonsanordning (800) ifølge krav 8, k a r a k t e r i s e r t v e d at feilkontroll-timeren er én av en gjensend poll-timer og en status deaktivert-timer. 2. Trådløs kommunikasjonsanordning (800) ifølge de foregående krav 8 eller 9, k a r a k t e r i s e r t v e d at feilkontrollmeldingen omfatter en ARQ (Automatic Repeat request) statusrapportmelding. 11. Trådløs kommunikasjonsanordning (800) ifølge de foregående krav 8 eller 9, k a r a k t e r i s e r t v e d at feilkontrollmeldingen omfatter en gjensendingsforespørsel.

19 12. Trådløs kommunikasjonsanordning (800) ifølge de foregående krav 8 eller 9, 18 k a r a k t e r i s e r t v e d at feilkontrollmeldingen omfatter en ARQ poll-melding. 13. Trådløs kommunikasjonsanordning (800) ifølge de foregående krav 8 eller 9, k a r a k t e r i s e r t v e d at fremgangsmåten videre omfatter det å: motta en varsling om at utsending av feilkontrollmeldingen har begynt. 14. Trådløs kommunikasjonsanordning (800) ifølge de foregående krav 8 eller 9, k a r a k t e r i s e r t v e d at fremgangsmåten videre omfatter det å: motta, fra mediumaksesskontrolleren (8), en varsling om at feilkontrollmeldingen har blitt kvittert for.

20

21

22

23

24