NO329036B1

NO329036B1 - Proving av trafikk- og hjelpekanaler i et tradlost datakommunikasjonssystem

Info

Publication number: NO329036B1
Application number: NO20042911A
Authority: NO
Inventors: Paul E Bender; Rajesh K Pankaj; Bibhu Mohanty; Rajeev Krishnamurthi
Original assignee: Qualcomm Inc
Priority date: 2001-12-10
Filing date: 2004-07-09
Publication date: 2010-08-02
Also published as: EP1452048B1; TW200304292A; US8780735B2; RU2310999C2; ATE468721T1; TWI263419B; IL162374A0; KR20040061027A; BRPI0214831B1; UA82317C2; US20110317565A1; KR100970354B1; NO20042911L; US8089888B2; WO2003051076A1; ES2343569T3; JP2005512473A; JP2012039630A; DE60236451D1; CA2469707C

Abstract

Teknikker for å prøve ytelsen av terminaler og aksesspunkter foreslås her, for CDMA-datasystemer, særskilt i henhold til standarden cdma2000. Et rammeverk med protokoller og meldinger tilveiebringes for å kunne håndtere systematisk ytelsesprøving av terminaler og for å sikre grensesnittforenlighet. Rammeverket innbefatter en protokoll (FTAP) for å prøve foroverkanaler og en protokoll (RTAP) for å prøve returkanaler. Teknikker foreslås også for (1) å prøve forskjellige typer kanaler, så som trafikkanaler og hjelpekanaler, (2) å prøve gruppetransmisjon, (3) å kunne håndtere vedvarende prøving, dvs. prøving som foregår på tvers av oppkoplinger og fråkoplinger, (4) å tvinge bestemte oppsettinger gjennom for visse hjelpekanaler, slik at kanalene fellhyppighet kan bestemmes, og (5) å samle inn, loggføre og rapportere forskjellige statistiske verdier som kan brukes til å utlede ytelses verdier så som totalytelse per tidsenhet og pakkefeilhyppighet.

Description

Oppfinnelsens bakgrunn

Teknisk område

Denne oppfinnelse gjelder datakommunikasjon, nærmere bestemt teknikker for prøving av forskjellige kanaltyper i et trådløst datakommunikasjonssystem, særlig et som arbeider i henhold til standarden cdma2000.

Underlaget for oppfinnelsen

Trådløse datakommunikasjonssystemer så som kodedelte multippelaksess-systemer (CDMA), tidsdelte tilsvarende systemer (TDMA), frekvensdelte slike systemer (FDMA) og andre brukes i utstrakt grad for å tilveiebringe forskjellig type informa-sjonsoverføring, så som digital tale, generelle data etc. For slike systemer er det meget ønskelig å få utnyttet de tilgjengelige ressurser maksimalt, og med ressurser menes her den tilgjengelige båndbredde og sendereffekten, og dette innebærer typisk sending av så store mengder data som mulig til så mange brukere som mulig innenfor en så kort tidsperiode som mulig, det som er praktisk mulig innenfor den aktuelle kommunika-sjonssignalvei eller -link og dennes aktuelle situasjon.

For å oppnå dette kan de mottakerstasjoner eller terminaler som inngår i systemet ha behov for undersøkelse eller evaluering både på fabrikken og/eller i felten. Som en del av en fremstillingsprosess kan slike terminaler gjennomgå utstrakt prøving for å sikre at de samsvarer med bestemte minstekriterier for ytelsen, også kalt spesifikasjonene. I felten kan ytelsen av terminalene gjerne kjennetegnes og brukes for å stille en diagnose for høyfrekvensdekningen (RF) og eventuelle ytelsesproblemer i det trådløse kommunika-sjonssystem.

I en konvensjonell teknikk for å karakterisere en terminals ytelse sendes et kjent datamønster som for eksempel kan genereres av en generator for et tilnærmet tilfeldig nummer, ofte benevnt kvasistøy- eller PN-generator, sendes fra et aksesspunkt, som kan være en basestasjon, til terminalen. Mønsteret kan sendes tilbake til aksesspunktet, og en slik tilbakeført teknikk for prøving kan være enkel å utføre, men gir naturligvis begrensede prøvemuligheter.

En rekke nye systemer innenfor CDMA-kommunikasjon vil kunne håndtere fleksibel drift, for eksempel kan data sendes i sekvenser eller grupper til terminalene, forskjellige typer data kan sendes via forskjellige typer kanaler, dataoverføringshastigheten kan tillates å variere fra ramme til ramme med informasjon, i en bestemt kanal, behandlingen av de aktuelle data kan også variere, for eksempel fra ramme til ramme og/eller fra kanal til kanal, etc. Den konvensjonelle tilbakeføringsprøveteknikk brukes typisk til å prøve om en enkelt trafikkanal er tilstrekkelig god eller ikke, basert på nærmere bestemte prøveparametere, og denne teknikk er ikke alltid tilgjengelig for prøving i henhold til forskjellige aspekter av et CDMA-system av senere generasjon.

Videre kan forskjellige utstyrsleverandører gi støtte og/eller bruke forskjellige grensesnittmodeller for prøving av slike terminaler, og som et resultat av dette er det lett å forstå at utstyr fra en bestemt fabrikant ikke alltid kan prøves på riktig måte mot eller i kombinasjon med utstyr fra en annen fabrikant, nettopp på grunn av at grensesnittene ikke passer sammen.

Fra den kjente teknikk skal det vises til WO 02/52568 vedrørende fremgangsmåte og apparat for å teste trådløse kommunikasjonskanaler.

På denne bakgrunn anses det å være et behov innenfor teknikken for å få kontrollert ytelsen av terminaler og aksesspunkter i CDMA-systemer.

Kort gjennomgåelse av oppfinnelsen

I følge oppfinnelsen, løses de overnevnte problemer ved en fremgangsmåte angitt i krav 1 og som har de karakteristiske trekk som angitt i den kjennetegnende del av kravet; et dataprogram angitt i krav 5 og som har de karakteristiske trekk som angitt i den kjennetegnende del av kravet; en fremgangsmåte angitt i krav 26 og som har de karakteristiske trekk som angitt i den kjennetegnende del av kravet; et apparat angitt i krav 34 og som har de karakteristiske trekk som angitt i den kjennetegnende del av kravet; et apparat angitt i krav 36 og som har de karakteristiske trekk som angitt i den kjennetegnende del av kravet; og et dataprogram angitt i krav 38 og som har de karakteristiske trekk som angitt i den kjennetegnende del av kravet.

Forskjellige aspekter av denne oppfinnelse gir teknikker for prøving av ytelsen av terminaler og aksesspunkter i CDMA-systemer, og et rammeverk med protokoller og meldinger brukes da til å gi underlag for ytelsesprøving av slike terminaler. Rammeverket sikrer samsvar mellom de enkelte grensesnitt, og i enn særlig utførelse omfatter dette rammeverk en bestemt type protokoll, nemlig protokollen FTAP (foroverprøvean-vendelsesprotokoll) for prøving av foroverkanalene, og en tilsvarende protokoll RTAP for returkanalprøving. Protokollen FTAP vil kunne håndtere utprøving av forovertrafikk-kanalen (FTC) i en kommunikasjonsoppsetting og samling, logging og rapportering av forskjellige statistisk oppnådde parametere som kan brukes til å bestemme ytelsen. Likeledes kan protokollen RTAP håndtere prøving av returtrafikkanalen RTC og innhenting av tilsvarende parametere.

Det er utviklet teknikker for å utføre forskjellige typer prøver for forskjellige typer kanaler, så som trafikkanaler så vel som hjelpekanaler eller overordnede kanaler for styring og kontroll, og slik teknikk vil også kunne håndtere prøving av transmisjon hvor data overføres i grupper ("bursts"). Teknikk for innsamling, logging og rapportering av forskjellige parametere hører med, og de innsamlede parametere kan deretter brukes til å utlede forskjellige metriske verdier for ytelsen, så som trafikkmengde per tidsenhet, pakkefeilhyppighet (PER), etc.

Man har også slik teknikk for å sørge for "persistens" under prøvingen, det vil si at prøvingen kan utføres kontinuerlig over oppkopling og fråkopling og med de aktuelle variable for lagring av statistisk informasjon tilbakestilt bare som følge av instruksjon. Man har også teknikker for å tvinge frem innstillingene i bestemte hjelpekanaler, for eksempel slik at feilhyppigheten i slike kanaler kan bestemmes.

Forskjellige aspekter av oppfinnelsen og utførelsesformer for å utføre slik prøving i henhold til oppfinnelsen skal nå gjennomgås i nærmere detalj.

De teknikker som er beskrevet her kan brukes for forskjellige anvendelser, så som minsteytelsesprøving av terminaler på systematisk måte, for eksempel i fabrikken eller i et laboratorium, og måling av ytelsen i foroverkanalen og returkanalen, herunder i feltomgivelser. Teknikkene kan brukes for forskjellige kommunikasjonssystemer for trådløs dataoverføring, for eksempel i cdma2000, IS-95 og W-CDMA, idet alle disse kommer inn under CDMA-begrepet.

Oppfinnelsen sørger videre for fremgangsmåter, apparater, dvs. terminaler og aksesspunkter og andre elementer hvor ny teknikk inngår, og hvor oppfinnelsens enkelte aspekter, utførelsesformer og trekk er med, slik det er beskrevet i nærmere detalj nedenfor.

Kort gjennomgåelse av tegningene

De enkelte trekk ved oppfinnelsen, dens natur og fordeler vil fremgå bedre av den detaljbeskrivelse som er satt opp nedenfor når denne ses i sammenheng med tegningene hvor samme henvisningstall angir tilsvarende element på eventuelt flere figurer, og hvor: Fig. 1 viser et skjema over et trådløst datakommunikasjonssystem, fig. 2A og 2B viser blokkskjemaer over en utførelse av et aksesspunkt henholdsvis en terminal, begge for implementering av forskjellige aspekter og utførelsesformer av oppfinnelsen, fig. 3 viser et diagram for et transmisjonsskjema som brukes for høyhastighets overføring av pakkedata i henhold til standarden cdma2000, fig. 4 viser et skjema over en utførelse for en totalprosess for prøving av en forovertrafikkanal, fig. 5 viser et flytskjema over en særskilt utførelse for en parameterprøveprosess med protokollen FTAP, fig. 6 viser et skjema over en utførelse av en prosess for å hente ut statistisk informasjon fra terminalen, fig. 7 viser et skjema over en utførelse for en total prosess for prøving av en returtraifkkanal, og fig. 8 viser et flytskjema over en særskilt utførelse av en prøveparameterkonifgurasjonsprosess hvor protokollen RTAP brukes.

Detaljbeskrivelse av oppfinnelsen

Fig. 1 viser et skjema over et trådløst datakommunikasjonssystem 100 hvor forskjellige aspekter og utførelsesformer av denne oppfinnelse kan implementeres. Systemet

100 gir kommunikasjon for flere dekningsområder (i USA også kalt celler), og hvert slikt dekningsområde blir betjent av et tilhørende aksesspunkt 10 som kan være en basestasjon, et sender/mottakersystem (BTS) i en slik basestasjon eller et knutepunkt (en node) B. Forskjellige terminaler 106 er spredt utover i systemet med dekningsområdene, og en slik terminal kan også kalles en aksessterminal, en fjernterminal eller en fjerntliggende slik terminal, en mobil stasjon, en mobiltelefon eller rett og slett brukerutstyr (UE).

I en bestemt utførelse av oppfinnelsen kan hver terminal 106 kommunisere med et bestemt aksesspunkt 104 via den såkalte foroverlink ved et gitt tidspunkt. Videre kan hver terminal kommunisere med et eller flere aksesspunkter via den såkalte returlink, i avhengighet av om terminalen er i såkalt myk overlevering eller omruting ("soft handoff') eller ikke. Foroverlinken (også kalt nedlinken) gjelder som konvensjonelt brukt sendinger fra aksesspunktet eller basestasjonen til terminalen eller mobiltelefonen, mens returlinken (også kalt opplinken) gjelder sendingene fra terminalen til aksesspunktet.

På fig. 1 viser en heltrukket strek med pil en brukerspesifikk datatransmisjon (rett og slett kalt data) fra et aksesspunkt til en terminal. En stiplet strek med pil indikerer at terminalen mottar en pilot, egentlig et pilotsignal, og annen type signalering, men ikke noen brukerspesifikke data fra aksesspunktet. Som vist på fig. 1 sender aksesspunktet 104a data til terminalen 106a via foroverlinken, aksesspunktet 104b sender data til terminalen 106b, aksesspunktet 104c sender data til terminalen 106c osv. Returlinkkommuni-kasjonen er for enkelthets skyld ikke vist på fig. 1 i det hele tatt.

Systemet 100 kan være utformet for å kunne håndtere en eller flere CDMA-standarder, så som cdma2000, IS-95, W-CDMA og andre, og disse CDMA-standarder er allerede velkjent innenfor teknikken og tas her med som referanselitteratur. Enkelte CDMA-systemer av den nyere generasjon, så som cdma2000 lxEV-systemer vil kunne sende data i grupper og ved varierende dataoverføringshastighet, i den utstrekning dette kan håndteres av kommunikasjonslinken. De prøveteknikker som her skal beskrives kan være i stand til mer effektivt å karakterisere kommunikasjonslinken for disse systemer.

Fig. 2 viser et blokkskjema over en utførelse av et aksesspunkt 104 som kan håndtere forskjellige aspekter og utførelsesformer av oppfinnelsen. For enkelhets skyld viser figuren prosesseringen i aksesspunktet for kommunikasjon med en enkelt terminal. Via foroverlinken går trafikkdata fra en senderdatakilde 210 og prøvedata fra en buffer 212 til en multipleksenhet 214 som sørger for valg av data og overføring av trafikkdata til en dataprosessor 216 på sendersiden når det arbeides i normal modus, og overfører både trafikk- og prøvedata når det arbeides i en prøvemodus. Dataprosessoren 216 mottar og behandler, dvs. formaterer, innfeller og koder de mottatte data som deretter behandles videre, dvs. dekking og spredning i en modulator 218. Den behandling som foregår og som er nevnt ovenfor kan være forskjellig for hver type kanal. De modulerte data går til en (RF-)senderenhet 222 og blir ytterligere behandlet, dvs. omvandlet til et eller flere analoge signaler, forsterket, filtrert og kvadraturmodulert for å komme frem til et foroverlinksignal som på sin side rutes via en dupleksenhet 224 for deretter å bli sendt ut via den viste antenne 226 til terminalene. Den viste styreenhet 220 holder kontroll over den totale prøving via signaleringsmeldinger som sendes via multipleksenheten 214.

Fig. 2B viser et blokkskjema over en utførelse av terminalen 106, idet denne også kan håndtere forskjellige aspekter og utførelsesformer av oppfinnelsen. Foroverlinksignaler fra aksesspunktet mottas i en antenne 252, rutes gjennom en dupleksenhet 254 og går til en (RF-)mottakerenhet 256 som utfører viderebehandling av de mottatte signaler, så som filtrering, forsterkning, nedtransponering og digitalisering, slik at det frembringes digitale avtastingsverdier eller sampler. En demodulator 258 mottar og behandler disse sampler for å komme frem til gjenopprettede symboler, idet behandlingen omfatter trinn for blant annet samling, avdekking og demodulasjon. Demodulatoren 258 kan implementere en såkalt rake- eller flerveissignalmottaker som kan behandle flere signalversjoner av det mottatte signal for å komme frem til de gjenopprettede symboler. En mottakerdataprosessor 260 dekoder de gjenopprettede symboler, kontrollerer de mottatte pakker og tilveiebringer dekodede trafikkdata via en demultipleksenhet 262, til en databruker 264 og dekodede prøvedata til en styreenhet 270. Denne styreenhet holder kontroll over den totale prøving via signaleringsmeldinger som sendes via en multipleksenhet 284.

I returlinken mottar multipleksenheten 284 statistisk fremkomne data for foroverlinkprøvingen fra styreenheten 270, tilbakeføringsdata (beskrevet nedenfor) fra en buffer 278, prøvedata for prøving av returlinken fra en buffer 280 og trafikkdata fra en senderdatakilde 282.1 avhengighet av hvilken driftsmodus terminalen 106 og de bestemte prøver som utføres er tilknyttet, gir multipleksenheten 284 riktig kombinasjon for forskjellige typer data til en senderdataprosessor 286, og der behandles disse data, så som ved formatering, innfelling og koding, hvoretter en viderebehandling foregår, så som en dekking og spredning i en modulator 288, hvoretter det foregår en ny behandling, så som ved omvandling til et analogt signal, forsterkning, filtrering og kvadraturmodulasjon i en senderenhet 290 slik at det fremkommer et returlinksignal som deretter rutes gjennom dupleksenheten 254 og sendes ut via den viste antenne 252 til et eller flere aksesspunkter 104.

Fig. 2A viser hvordan returlinksignalet mottas via antennen 226, rutes gjennom dupleksenheten 224 og går til en mottakerenhet 228. Returlinksignalet behandles, så som nedtransponeres, filtreres og forsterkes i denne enhet 228, og signalet blir etter behandlingen viderebehandlet i en demodulator 232 og en RX-dataprosessor 234 på komplementær måte i forhold til det som ble utført i modulatoren 288 og TX-dataprosessoren 286, slik at de utsendte data blir gjenetablerte. Trafikkdata i returlinken går via en demultipleksenhet 236 til en RX-dataforbruker 238, og den statistiske informasjon, tilbakekoplingen og prøvedata går deretter til en styreenhet 220 for evaluering.

Forskjellige aspekter av denne oppfinnelse gir teknikker for å prøve hvordan ytelsen er i terminaler og aksesspunkter i CDMA-systemer. Således kan det settes opp et rammeverk med protokoller og meldinger for å støtte slik ytelsesprøving av terminalen, og dette rammeverk sikrer samsvar mellom de enkelte grensesnitt, for eksempel grensesnitt fra forskjellige leverandører og forhandlere, og i et annet aspekt har man fått teknikk for å utføre forskjellige typer prøver for forskjellige typer kanaler, så som trafikkanaler så vel som hjelpekanaler eller overordnede styrekanaler. Prøver for datatransmisjon som kommer i grupper kan også håndteres. Videre kan teknikk for oppsamling, logging og rapportering av forskjellige statistiske resultater og parametere tilveiebringes, og disse parametere kan deretter brukes til å utlede forskjellige størrelser for ytelsen, så som trafikkmengden per tidsenhet, pakkefeilhyppigheten (PER) etc. Videre har man fått teknikk for å kunne ivareta persistensen i prøvingen, det vil si den kontinuerlige utprøving av forbindelser og fråkoplinger, med de variable som brukes til å lagre statistisk informasjon tilbakestilt bare ifølge instruksjon. I et annet aspekt har man fått teknikk for å tvinge frem settingene av visse hjelpekanaler, slik at for eksempel feilhyppigheten i disse kanaler kan bestemmes. Videre skal forskjellige uttrykk for oppfinnelsen og utførelsesformer av denne gjennomgås i nærmere detalj nedenfor, og for enkelthets skyld vil de forskjellige aspekter av oppfinnelsen særskilt beskrives for den gjengse standard cdma2000 og knyttet til et grensesnitt over luft for høyhastighets pakkedatatransmisjon, idet denne standard gjerne kalles cdma2000 HAI.

Fig. 3 viser således et diagram over et skjema over foroverlinktransmisjonen som brukes for slik høyhastighets pakkedatatransmisjon i henhold til cdma2000. Hvert aksesspunkt sender pakkedata til terminalene som er valgt til å motta disse data fra aksesspunktene, ut fra signalstyrken. En terminal av gangen mottar signalene på tidsdelt multipleksbehandlet måte. Et aksesspunkt sender således pakkedata til en terminal nær eller ved den maksimale sendereffekt, hvis sendingen i det hele tatt foregår. Når som helst en terminal ønsker en datatransmisjon sender den en pakkedataforespørsel i form av en melding for dataratekontroll (DRC) til et valgt aksesspunkt, og så måler terminalen signalkvaliteten av de foroverlinksignaler eller pilotsignaler som kommer tilbake fra flere aksesspunkter, slik at den kan bestemme det aksesspunkt som gir best signalkvalitet på mottakersiden, idet dette aksesspunkt da blir det valgte. Deretter identifiserer terminalen den høyeste hastighet som kan håndteres i den best mottatte link og sender en DRC-verdi som indikerer denne hastighet (eller datarate). DRC-verdien sendes via en separat DRC-kanal og dirigeres til det valgte aksesspunkt via bruken av et DRC-dekke som er tilordnet dette aksesspunkt. Det valgte aksesspunkt (eller den betjenende sektor) setter opp en plan for datatransmisjonen til terminalen via forovertraifkkanalen og i samsvar med den planleggingspolitikk som kan ta hensyn til forskjellige faktorer, så som DRC-verdien som ble mottatt, hvor stor datamengde som ligger i kø etc. Basert på tilstanden av den mottatte datatransmisjon vil deretter terminalen sende bekreftelser (ACK) eller eventuelt negative slike bekreftelser (NACK) via en bekreftelseskanal (NACK-kanal) til det valgte aksesspunkt. Detaljer av slik høyhastighets pakkedatatransmisjon som er underlagt en plan for cdma2000 er allerede beskrevet i 3GPP2 C.S0024 med tittel "cdma2000 High rate packet data air interface specification", heretter kalt HAI-dokumentet, og dette dokument er tilgjengelig for enhver og kan derfor brukes som referansemateriale her.

De teknikker som er beskrevet her kan brukes for prøving av forskjellige typer kanaler. For cdma2000 HAI omfatter disse kanaler forovertrafikkanalen FTC, DRC-kanalen, ACK-kanalen, returtrafikkanalen RTC og eventuelt andre. FTC brukes for datatransmisjon fra aksesspunktet til terminalen, som allerede nevnt, og RTC brukes i motsatt retning. DRC-kanalen brukes til å sende informasjon som gjelder den maksimale overføringshastighet som skal brukes i forovertraifkkanalen FTC, og ACK-kanalen brukes til å sende bekreftelsessiffer (bit) for mottatte pakker.

Teknikken som her er beskrevet kan også brukes for forskjellige anvendelser, og en slik er prøving av terminaler i systematisk rekkefølge, for eksempel i en fabrikk eller i et laboratorium. Den minste ytelse for terminaler i henhold til cdma2000 HAI er allerede beskrevet i TIA/EIA/IS-866 med tittel "The recommended minimum performance standards for cdma2000 high rate packet data terminal", og den tilsvarende minsteytelse for aksesspunktene beskrevet i TIA/EIA/IS-864 med tittel "The recommended minimum performance standards for cdma2000 high rate packet data access network", og begge disse oppsett er tilgjengelige slik at de kan tas med som referansemateriale her. En annen anvendelse er målingen av en bestemt nøkkel som gir en ytelsesverdi både i forover- og returlinken, for eksempel også i feltomgivelser, slik som trafikkmassen per tidsenhet og pakkefeilhyppigheten (PER).

I et bestemt aspekt av oppfinnelsen har man kommet frem til et rammeverk som brukes for å muliggjøre av forskjellige elementer i et CDMA-system, for eksempel i systemet cdma2000 HAI, og dette rammeverk vil her kalles prøveanvendelsesprotokollen (TAP) og omfatter en anvendelsesprotokoll for foroverkanalprøving (FTAP) og en tilsvarende protokoll RTAP for prøving av returkanalen.

I en bestemt utførelse har man FTAP slik at denne protokoll (1) gir prosedyrer og meldinger for styring av forovertraifkkanalen FTC og konfigurasjon av returkanaler som er tilordnet denne FTC, (2) spesifiserer genereringen og transmisjonen av prøve- og tilbakekoplingspakker som sendes via både FTC og RTC for å få prøvd FTC, og (3) gir prosedyrer for oppsamling, logging og rapportering av bestemte statistiske verdier slik de observeres i terminalen. Færre, ytterligere og/eller andre muligheter kan også ivaretas av protokollen FTAP, og dette vil likeledes ligge innenfor oppfinnelsens ramme.

I en bestemt utførelse gir RTAP (1) prosedyrer og meldinger for styring, kontroll og konfigurering av RTC , og (2) spesifiserer genereringen av prøvepakker som sendes via RTC for prøving av denne kanal. Færre, ytterligere og/eller andre muligheter kan også ivaretas av RTAP, og dette vil også være innenfor oppfinnelsens ramme.

Protokollen TAP genererer og formidler prøvepakker til det strømningslag som ligger i senderretningen og mottar og prosesserer prøvepakker fra dette strømningslag i mottakerretningen. Transmisjonsenheten i protokollen FTAP er en FTAP-pakke, og den tilsvarende transmisjonsenhet i RTAP er en RTAP-pakke. Pakkestørrelsene for disse protokoller bestemmes av de lavere lag og dette skjer under forhandling i løpet av sesjonskonfigurasjonen. Hver enkelt FTAP- eller RTAP-pakke innbefattes i nyttelasten i strømningslaget.

Protokollene FTAP og RTAP bruker begge signaleringsmeldinger for kontroll og styring og konfigurasjon av terminalen og aksessnettet for å utføre prøver i kanalene FTC og RTC. Begge protokoller bruker den type signaleringsanvendelse som er beskrevet i det allerede nevnte HAI-dokument, til å sende meldinger.

Protokollen TAP er registrert for å motta bestemte indikasjoner fra de øvrige lag, hvilke brukes til å lukke en prøvesesjon eller endre tilstanden av den terminal som er under prøving. I en bestemt utførelse mottas følgende indikasjoner av protokollene FTAP og RTAP eller en av dem, som vist i klamme til høyre for indikasjonen:

- Oppkoplet tilstand. Forbindelse lukket [ mottatt av FTAP og RTAP],

- Rute oppdatert. Ledig HO [ mottatt av FTAP],

- Rute oppdatert. Forbindelse tapt [ mottatt av FTAP og RTAP], og

- Ledig tilstand. Forbindelse åpnet [ mottatt av FTAP og RTAP].

Protokollen TAP returnerer også følgende indikasjon til de høyere signaleringslag:

- Tilbakekoplet synkronisering tapt [ returnert av FTAP], og

- RTAP- synkronisering tapt [ returnert av FTAP].

Protokollen FTAP for prøving av foroverkanalen

Protokollen FTAP sørger for prosedyrer og meldinger som skal brukes til å konfigurere, kontrollere, styre og utføre forskjellige prøver i foroverkanalene, innbefattet trafikkanalen FTC. Prosedyrene for FTAP kan grupperes i følgende kategorier: -FTAP-prøveparameterkonfigurasjon - innbefattet prosedyrer og meldinger for å kontrollere og styre FTAP-prøvekonfigurasjonene i terminalen og aksessnettet; -FTAP-prøvepakketransmisjon og -mottaking - innbefattet prosedyrer for generering av FTAP-prøvepakker i aksessnettet for transmisjon via FTC og for behandling av mottatte pakker i terminalen; -FTAP-tilbakekoplingspakketransmisjon og -mottaking - innbefattet prosedyrer for sending og mottaking av FTAP-tilbakekoplingspakker via kanalen RTC; -ACK-kanaltransmisjon - innbefattet prosedyrer for sending av konfigurerte eller fastverdibestemte ACK-kanalsiffer via ACK-kanalen; -DRC-kanaltransmisjon - innbefattet prosedyrer for sending av konfigurerte eller faste DRC-verdier og/eller bruk av en fast DRC-dekking i DRC-kanalen; og -FTAP-statistikksamling og -gjeninnhenting - innbefattet prosedyrer og meldinger for samling av statistisk material i terminalen og for å hente dem frem igjen i aksessnettet.

Prosedyrene og fremgangsmåtene skal beskrives i nærmere detalj nedenfor. Færre, ytterligere og/eller forskjellige prosedyrer og meldinger kan også tilveiebringes for FTAP, og dette vil også være innenfor oppfinnelsens ramme.

Protokollen FTAP kan håndtere prøvingen av forskjellige typer foroverkanaler, og de spesielle kanaler som skal prøves kan velges individuelt, mens de valgte kanaler kan prøves samtidig. I en bestemt utførelse vil protokollen FTAP kunne håndtere prøving av kanalen FTC, forover-MAC-kanaler, DRC-kanalen og ACK-kanalen. Tabell 1 nedenfor har satt opp forskjellige modi som kan håndteres av protokollen FTAP. Færre, ytterligere og/eller forskjellige modi kan også håndteres, og dette vil også være innenfor oppfinnelsens ramme.

FTAP kan altså håndtere innsamling av bestemte statistiske verdier i aksessnettet, og disse verdier kan brukes til å bestemme forskjellige ytelsesverdier, så som for eksempel trafikkmassen per tidsenhet i foroverlinken, pakkefeilhyppigheten i trafikk-kanalen, pakkefeilhyppigheten i kontrollkanalen, sektorkapasiteten (også en ytelsesverdi) og annet. Tabell 2 nedenfor lister opp de statistiske verdier som kan innsamles og opprettholdes i aksessnettet, dvs. verdier for hver enkelt sektor, når tilbakekoplingsmodusen brukes.

Protokollen FTAP kan håndtere innsamlingen av visse slike statistiske verdier i terminalen, og disse verdier kan hentes frem av aksessnettet. Tabell 3 lister opp de statistiske verdier som kan hentes inn og opprettholdes av terminalen.

I henhold til cdma2000 HAI karakteriseres en pilot for hver enkelt sektor av en spesifikk kvasistøyforskyvning (PN-offset) og en CDMA-kanal, og en aktivsettpilot (ASP) er piloten eller pilotsignalet fra den sektor hvis kontrollkanal den aktuelle terminal overvåker i øyeblikket. Når terminalen er i ledig tilstand overvåker den kontrollkanalen fra betjeningssektoren. Endringer i aktivsettpiloten ved ledig tilstand kan kalles IdleASPChange og brukes til å samle inn statistiske verdier for hvor raskt endringene av aktivsettpiloten skjer, og tilsvarende kan et uttrykk FirstSyncCCPkt brukes for å samle inn statistiske verdier for antallet CC MAC lagpakkene i synkrone kapsler og som mottas vellykket i terminalen.

Når terminalen er i oppkoplet tilstand kan den motta pakker fra betjenende sektorer, og en betjenende sektor er den sektor som DRC-meldingen sendes til eller som det pekes på. Når en DRC-melding ompekes fra en sektor til en annen utfører DRC-dekkingen overganger via en såkalt nulldekking. Som et eksempel på dette vil DRC-dekkingen endres fra sektordekking A via nulldekkingen og til sektordekking B, idet A ikke er lik B, og dette regnes da som en enkelt endring i betjeningssektoren. Hvis nå DRC-dekkingen endres fra sektordekking A via nulldekkingen og tilbake til samme sektordekking A regnes dette som null endring i betjeningssektoren. Uttrykket ConnectedSSChange brukes til oppsamling av statistiske verdier for den endringstakt betjeningssektoren fremviser.

Tilstandene ledig (Idle) og oppkoplet (Connected) er terminaldriftstilstander i den luftlinkhåndteringsprotokoll som er beskrevet i HAI-dokumentet nevnt ovenfor.

Fig. 4 viser et skjema over en totalprosess for prøving av trafikkanalen FTC, i samsvar med en utførelse av oppfinnelsen. Prosessen kan brukes til å bestemme forskjellige ytelsesverdier, så som for eksempel brukerytelsen i foroverlinken, pakkefeilhyppigheten i kanalen FTC, samme feilhyppighet i kontrollkanalen, ytelsen i foroverlinksektoren og annet.

Innledningsvis setter aksessnettet opp en forbindelse med en terminal på normal måte, dersom det altså ikke er noen aktuell oppkopling mellom dem, og dette gjøres i trinn 412 i prosessen 400. Oppkoplingsoppsettet for cdma2000 HAI kan utføres som beskrevet i dette dokument. Aksessnettet sender deretter en melding som kan kalles FTAP!' ar- ameter- Assignment og gjelder tildeling av parameter i henhold til protokollen, til terminalen for å konfigurere protokollen FTAP, i trinn 414. Denne konfigurering for FTAP-prøving er beskrevet nedenfor, og i en bestemt utførelse klargjøres da for en tilbakekoplingsmodus som standardmodus. Terminalen utfører den nødvendige konfigurasjon og svarer deretter overfor aksessnettet med meldingen FTPParameter-Complete for å indikere at terminalen er klar for den konfigurerte prøve, i trinn 416.

Aksessnettet og terminalen utveksler deretter FTAP-prøvepakker og FTAP-tilbakekoplingspakker, idet dette beskrives i nærmere detalj nedenfor, i trinn 418. Ethvert antall slike pakker kan utveksles, og de statistiske resultater som skal samles inn av aksessnettet og/eller terminalen kan bestemmes av prøvekonfigurasjonen.

Etter innsamling av tilstrekkelig statistisk materiale stanser aksessnettet sendingen av FTAP-prøvepakker og frigir forbindelsen, i trinn 420. Dette trinn kan hoppes over, for eksempel dersom aksessnettet går videre med å utføre enkelte andre prøver eller funksjoner. Aksessnettet kan bruke resultatene fra innsamlingen av statistikk til beregning av pakkefeilhyppigheten og den gjennomsnittlige ytelse, som beskrevet nedenfor. Forskjellige detaljer for prosessen 400 er også beskrevet nedenfor.

I en bestemt utførelse aktiveres protokollen FTAP ved å binde prøveanvendelsen til en av tre tilgjengelige strømmer. Protokollkonfigurasjonen kan startes av aksesspunktet eller av terminalen, og i en bestemt utførelse er det bare en oppstarting av protokollen FTAP i hver terminal.

FTAP-prøveparameterkonfigurasjon

Aksessnettet eller terminalen kan aktivere protokollen FTAP for å prøve foroverkanalene. Ved denne aktivering utfører terminalen en oppstartingsprosedyre som tar ned flaggene for tilbakekoplingsmodusen, for modusen ACK Channel Bit Fixed, modusen for DRC Fixed og modusen for DRC Cover Fixed.

Fig. 5 viser et flytskjema over en bestemt utførelse av en prosess 500 for en slik prøveparameterkonfigurasjon. Prosessen dekker trinnene 414 og 416 på fig. 4. For å starte opp eller endre prøvekonfigurasjonen sender aksessnettet meldingen FTAPParameterAssignment som innbefatter en bestemt verdi for et TransactionlD-felt og videre kan innbefatte en eller flere attributtregistreringer for FTAP-modusflagg som opprettholdes ved hjelp av terminalen, i trinn 512. Via attributtregistreringene i meldingen kan aksessnettet holde styring over de prøver som skal utføres.

Ved mottaking av denne melding fra aksessnettet utfører terminalen oppstartingsprosedyren som er beskrevet ovenfor, i trinn 514 og setter deretter FTAP-modusflaggene basert på attributter, dersom det finnes noen slike, innbefattet i den mottatte melding, i trinn 516. Særskilt kan den mottatte melding innbefatte en attributt LoopBackMode, en attributt ACKChBitFixedMode, en attributt DRCFixedMode og/eller en attributt DRCCoverFixedMode.

Attributten LoopBackMode, som gjelder tilbakekopling er lagt inn i meldingen FTAPParameterAssignment dersom terminalen anmodes om å sende pakker med FTAP

Loop Back via returtrafikkanalen RTC. Attributten ACKChannelBitFixedMode innbefattes dersom ACK-kanalsifrene skal overføres av terminalen i hver enkelt tidsluke og skal settes ved en bestemt fast verdi. Attributten DRCFixedMode er innbefattet i den DRC som sendes av terminalen og som skal settes til en fast bestemt verdi. Endelig innbefattes attributten DRCCoverFixedMode dersom en bestemt fast DRC-dekking skal brukes av terminalen for DRC-transmisjon.

Om den mottatte melding omfatter attributten LoopBackMode for tilbakekopling klareres i terminalen en oppsetting av modusflagget for tilbakekoplingen, verdien lagres i et LoopBackPersistence-felt for attributten, Loop Back-bufferen klareres, og LBPktOverflowBit tilbakestilles til null. Omfatter den mottatte melding en attributt ACKChannelBitFixedMode vil terminalen sette opp ACK Channel Bit Fixed mode-flagget og lagre verdien i attributten felt ACKChannelBit. Dersom den mottatte melding innbefatter attributten DRCFixedMode settes flagget DRC Fixed mode, og verdien lagres i et DRCValue-felt for denne attributt. Endelig er det slik at dersom den mottatte melding innbefatter attributter DRCCoverFixedMode vil terminalen sette opp flagget DRC Cover Fixed mode og lagre verdien i et DRCCover-felt i attributten.

Ved avslutningen av de prøvekonfigurasjoner som er spesifisert i meldingen FTAPParameterAssignment og innenfor Tn-APConfig (dvs. to) sekunder etter mottakingen av meldingen sender terminalen en melding FTAPParameterComplete sammen med transaksjonsidentifikasjonsfeltet som er satt til samme verdi som det som ble mottatt i tilsvarende felt i den først nevnte melding, i trinn 518. Transaksjonsfeltet brukes til å identifisere den spesifikke transaksjon som refereres til i meldingen.

Ved mottaking av komplettmeldingen fra terminalen utfører aksessnettet en prosedyre som gjelder prøvestatistikk og startparametere, og denne prosedyre setter følgende størrelser til null: FTAPTestPktSent, FTAPTestPktRecd, FTAPMACPktRecd, FTAPLBPktSent, FTAPLBPktRecd, FTAPPhysPktSlots og FTAPTestTime, idet disse størrelser er variable som opprettholdes for hver sektor, idet dette utføres i trinn 520. Aksessnettet setter videre en 14 b variabel V(STest) til null, og denne variabel brukes til å følge sekvensnummeret for FTAP-prøvepakkene. Konfigurasjonsprosessen avsluttes deretter.

Terminalen tilbakestiller sine FTAP-modusflagg ved avslutningen av prøvingen. I en bestemt utførelse og dersom protokollen mottar en av følgende indikasjoner: ConnectedState. ConnectionClosed eller RouteUpdate. ConnectionLost fra forbindelses-laget, vil en av disse indikere at en forbindelse er avsluttet, og deretter frakople terminalen flaggene for de tre modi ACK Channel Bit Fixed, DRC Fixed og DRC Cover Fixed. Terminalen tar videre ned tilbakekoplingsmodusflagget dersom det tidligere var satt opp, og dersom verdien av LoopBackPersistence-feltet i LoopBack-modusattributten i den siste FTAPParameterAssignment- meldmgQn var "00".

Tabell 4 viser de enkelte felt for meldingen FTAPParameterAssignment, i samsvar med en særskilt utførelse:

Tabell 5 viser de enkelte felt for attributtregistreringene som kan innbefattes i meldingen, slik det er gitt i en bestemt utførelse. Første spalte i tabellen identifiserer fire forskjellige attributtregistreringer som kan innbefattes i denne melding, og hver registrering har tre felt, nemlig lengde, attributtidentifikasjon og et datafelt som er attributtavhengig. Disse tre felt er vist i andre til fjerde spalte. Lengdefeltet gir lengden av attributtregistreringen, mål i oktetter og utelukkende lengdefeltet selv. I en bestemt ut-førelse er lengden av hvert attributtregistreringsfelt 8 b, og lengden av hver attributtregistrering er 24 b.

I en bestemt utførelse sendes meldingen FTAPParameterAssignment i kontrollkanalen (CC) og forovertraifkkanalen (FTC), adressert til terminalen (unikastingsadressering) med signaleringslagprotokollen (SLP) satt til "pålitelig" og transmisjonsprioriteten satt til 40.

Tabell 6 setter opp feltene for FTAPParameterComplete- meldmgen i samsvar med en særlig utførelse.

I en bestemt utførelse sendes komplettmeldingen via returkanalen RTC og adressert til aksessnettet som unikastingsadressering som ovenfor, med SLP satt til pålitelig som ovenfor og transmisjonsprioriteten likeledes satt til 40.

FTAP-prøvepakketransmisjon og -mottaking

Etter at konfigurasjonsprosessen er avsluttet for foroverprotokollen og mens terminalen er i oppkoplet tilstand overvåker den kanalen FTC for å motta FTAP-prøvepakker. I en bestemt utførelse genereres disse pakker av et prøveprogram på normal måte, dvs. tilsvarende en trafikkdatapakke, men hver FTAP-prøvepakke innbefatter bare de fastlagte felt og ingen andre data. Disse pakker genereres ved en tilstrekkelig hastighet til å sikre at de alltid vil være tilgjengelige for transmisjon (sending) via forovertraifkkanalen FTC. Disse pakker kan lagres i bufferen 212 på fig. 2A.

Aksessnettet omfatter et 14 b sekvensnummer i hver slik sendt prøvepakke, og dette nummer brukes for identifikasjon av pakkene. Nummeret opprettholdes via en variabel V(STest) av aksessnettet og inkrementeres med én etter sending av en slik pakke. Tabell 7 nedenfor setter opp feltene for en FTAP-prøvepakke i samsvar med en særskilt utførelse av oppfinnelsen.

Aksessnettet ender FTAP-prøvepakkene via forovertrafikkanalen i samsvar med et sett regler, og i en bestemt utførelse tildeler dette aksessnett en bestemt sendeprioritet, for eksempel 55 til FTAP-prøvepakkene, hvoretter nettet bruker den mekanisme som er kalt Forced Single Encapsulation (FSE) i HAI-dokumentet for videre oppfølging. Terminalen mottar og behandler prøvepakkene som sendes ut via denne kanal FTC, og siden disse pakker ble generert på normal måte i aksesspunktet kan de behandles på likeledes normal måte i terminalen, akkurat som andre trafikkdatapakker, dvs. at de kan demoduleres, dekodes og kontrolleres for innholdet, om de ble mottatt korrekt eller feilaktig.

Sending og mottaking av FTAP-tilbakekoplingspakker

Brukes tilbakekoplingsmodusen genererer terminalen og sender FTAP-tilbakekoplingspakkene via returtrafikkanalen RTC, til aksessnettet. Forover- og returlinken for standarden cdma2000 HAI er imidlertid ikke symmetriske, dvs. at foroverlinken kan håndtere en høyere overføringshastighet enn returlinken, og sistnevnte hastighet kan videre være begrenset helt ned til 9,6 kb/s i det verste tilfelle. Den relevante informasjon for foroverlinksendingene trekkes ut og sløyfes tilbake til aksessnettet via tilbakekoplingspakkene.

I en bestemt utførelse genereres en FTAP-tilbakekoplingspakke for hvert bestemt tidsintervall, dvs. for hvert 16-lukes intervall, tilordnet CDMA-systemtiden, idet dette kalles observasjonsintervallet. I en bestemt utførelse sendes disse pakker for å formidle informasjon om de tilsvarende pakker som mottas via forovertrafikkanalen, og innholdet i hver slik pakke er basert på og deskriptiv for de tilsvarende pakker som mottas i løpet av observasjonsintervallet. I en bestemt utførelse omfatter hver slik tilbakekoplingspakke en registrering for hver slik pakke som blir mottatt korrekt i terminalen i løpet av det tilhørende observasjonsintervall, og hver registrering innbefatter forskjellig informasjon for de tilhørende prøvepakker, så som for eksempel den betjeningssektor som pakken ble mottatt fra, sekvensnummeret og lengden av pakken etc. Informasjonen i hver registrering som er innlagt i FTAP-tilbakekoplingspakkene brukes av aksessnettet til å utlede forskjellige ytelsesverdier for foroverlinken, så som trafikktettheten per tidsenhet, pakkefeilhyppigheten og annet, som beskrevet nedenfor.

Tabell 8 setter opp de enkelte felt for en slik tilbakekoplingspakke, i en særskilt utførelse:

FTAP-tilbakekoplingspakkene genereres i samsvar med et sett regler, og en ut-førelse av disse skal gjennomgås her. For hver slik generert pakke settes feltet FwdSysTime til CDMA-systemtiden, i rammer mod 32768 som angitt i tabellen og tilsvarende starten, dvs. den nulte luke i det 16-lukes observasjonsintervall. CDMA-systemtiden brukes effektivt som et sekvensnummer for pakken. Registreringstellefeltet settes til antallet prøvepakker som mottas via det tilordnede observasjonsintervall, og hver registrering i pakken innbefatter forskjellig type informasjon, slik det er satt opp i tabell 8, for en tilsvarende prøvepakke som mottas i løpet av den bestemte observasjonstid. Registreringene for FTAP-prøvepakkene innbefattes i stigende rekkefølge for SEQ-feltverdiene i de mottatte FTAP-prøvepakkene. En tilbakekoplingspakke genereres selv om ikke noen prøvepakke er mottatt i løpet av det 16-lukes observasjonsintervall.

De genererte FTAP-tilbakekoplingspakkene legges i kø for sending via returtrafikkanalen RTC, og terminalen gir buffertjeneste, dvs. bufferen 278 på fig. 2B får et bestemt antall på 8 eller flere slike pakker. Overløpssifferet indikerer at dersom en slik pakke er tapt i løpet av overføringen og på grunn av overløp i bufferen i terminalen blir satt til 1 dersom dette finner sted. Når overløpssifferet er satt til 1 indikeres med dette at ikke samtlige tapte tilbakekoplingspakker ble mistet på grunn av sletting i returtrafikkanalen.

Tilbakekoplingspakkene sendes i samsvar med et sett regler, og som nevnt skal en slik regel gjennomgås her. Pakkene tildeles en bestemt transmisjonsprioritet, for eksempel sifferet 55, og terminalen sender de køoppstilte tilbakekoplingspakker i oppkoplet tilstand. Dersom terminalen mottar en indikasjon ConnectedState. ConnectionClosed for en forbindelsesavslutning eller en indikasjon RouteUpdate. ConnectionLost for en tapt forbindelse gjør den ikke noe forsøk på å etablere en forbindelse for sendingen av noen som helst tilbakekoplingspakker som kan ha blitt stående igjen i køen.

Aksessnettet mottar og behandler tilbakekoplingspakkene på normal måte akkurat som andre trafikkdatapakker og trekker videre ut og lagrer den informasjon som er lagt inn i pakkene.

I en bestemt utførelse opprettholder aksessnettet to variable, V(RTest) og V(RLb) for å holde kontroll med de mottatte prøvepakker som ble mottatt i aksessterminalen og de tilbakekoplingspakker som ble mottatt i aksessnettet. Den sistnevnte størrelse er en 15 b variabel som representerer sekvensnummeret for den neste tilbakekoplingspakke som forventes mottatt i aksessnettet, mens den første størrelse er en 14 b variabel som representerer sekvensnummeret for den siste prøvepakke som ble vellykket mottatt i terminalen. Disse størrelser settes opp av aksessnettet ved mottakingen av den første tilbakekoplingspakke etter mottakingen av en melding FTAPParameterComplete som indikerer vellykket konfigurasjon av tilbakekoplingsmodusen. For oppstartingen settes V(Rlb) til feltet FwdSysTime for den første tilbakekoplingspakke, mens V(RTest) settes til feltet FwdSeq for den første prøvepakkeregistrering i den første tilbakekoplingspakke.

I en bestemt utførelse behandler aksessnettet hver mottatt tilbakekoplingspakke basert på følgende prosedyre og ved bruk av verdien av feltet FwdSysTime i den mottatte pakke:

Siden tilbakekoplingspakken forventes å bli sendt av terminalen for hvert eneste 16-lukes observasjonsintervall, dvs. for hver ramme kan FwdSysTime som er innlagt i hver tilbakekoplingspakke brukes som sekvensnummeret for pakke. For hver mottatt slik pakke kan antallet tilbakekoplingspakker som sendes av terminalen etter den siste mottatte slike tilbakekoplingspakke, bestemmes ut fira sekvensnummeret for den aktuelt mottatte pakke, FwdSysTime, og sekvensnummeret for den forventede pakke, V(RLB). Sekvensnummeret for den neste tilbakekoplingspakke som forventes mottatt oppnås ved å inkrementere sekvensnummeret for den aktuelt mottatte pakke, med 1. I en bestemt ut-førelse behandler aksessnettet videre sekvensielt registreringene i hver mottatt FTAP-tilbakekoplingspakke og basert på følgende prosedyre. Først bestemmes den tjenestesektor som sender prøvepakken til terminalen, basert på feltene TCAMsgSeqlncluded, TCAMsgSeq og DRCCover innbefattet i pakke. De statistisk oppnådde variable som opprettholdes for denne tjenestesektor oppdateres på følgende måte:

I en bestemt utførelse utføres de enkelte arbeidstrinn og sammenlikninger på sekvensnumrene i den fortegnsfrie aritmetiske verdi modulo 2S, hvor S angir antallet siffer som brukes til representasjon av sekvensnummeret. For et sekvensnummer på x betraktes tallene i området [x+1, x+2<s>"'-l] å være større enn x, mens tallene i området [x-1, x-2<s>"'] betraktes å være mindre enn x.

DRC-kanaltransmisjon

Dersom modusen DRC Fixed etableres sender terminalen DRC-verdien som er spesifisert av attributten for denne modus i meldingen for tildeling FTAPParameterAssignment. Hvis videre modusen DRC Cover Fixed etableres bruker terminalen den DRC-dekking som er spesifisert i denne modusens attributt i meldingen. Ellers sender terminalen DRC på vanlig måte.

ACK-kanaltransmisjon

Dersom modusen ACK Channel Bit Fixed er etablert sender terminalen sifferverdien for ACK-kanalen, slik den er spesifisert i attributten til denne modus i meldingen FTAPParameterAssignment, via ACK-kanalen i samtlige luker. I en bestemt ut-førelse behandler terminalen videre de mottatte FTAP-prøvepakkene i samsvar med den spesifiserte sifferverdi for ACK-kanalen.

Hvis sifferverdien for denne kanal er spesifisert som 0 mottar terminalen pakker via FTC som om de hadde en varighet på en enkelt tidsluke. Terminalen stanser mottakingen av en pakke etter en slik tidsluke, selv om pakken likevel ikke er dekodet vellykket i løpet av en enkelt luke og selv om pakken altså har en lengde som overstiger en slik.

Er imidlertid sifferverdien spesifisert som 1 mottar terminalen pakker via denne kanal FTC som om de hadde fullengdes varighet. Terminalen fortsetter med å motta pakken inntil dens totale lengde (regnet i tidsluker) har løpt ut, selv om pakken rakk å bli dekodet på vellykket måte før den avsatte tid ble avsluttet.

I begge tilfeller, altså om sifferverdien er 0 eller 1 fortsetter terminalen å generere og sende tilbakekoplingspakker, dersom tilbakekoplingsmodusen er drift.

Terminalstatistikksamling og -innhenting

I et bestemt aspekt av oppfinnelsen går prosedyrer og fremgangsmåter ut på å lette innsamlingen, loggingen og rapporteringen av statistisk informasjon i terminalen. Når protokollen startes opp utfører terminalen en oppstartingsprosedyre for FTAP-statistikk, og denne prosedyre setter følgende variable til null: IdleASPChange, IdleTime, ConnectedSSChange, ConnectedTime, FirstSyncCCPkt og CCTime, idet disse variable er opprettholdt av terminalen.

Fig. 6 viser et skjema over en prosess for innhenting av statistisk informasjon fra en terminal, i samsvar med en bestemt utførelse av oppfinnelsen. Prosessen 600 kan utføres når som helst i løpet av en prøveperiode.

Innledningsvis sender aksessnettet en melding FTAPStatsClearRequest for å dirigere terminalen til å rydde opp i de statistiske resultater som er oppsamlet tidligere, i trinn 612. Ved mottaking av meldingen utfører terminalen oppstartingsprosedyren, renser de variable som opprettholdes for de aktuelle statistiske resultater og svarer med meldingen FTAPStatsClearResponse i trinn 614. Aksessnettet kan tilbakestille de variable i terminalen når som helst ved å sende den førstnevnte melding. Mottakingen av den andre melding fra terminalen, idet denne melding inneholder samme transaksjonsidentifikasjonsverdi som i den første melding, indikerer at de statistiske variable i terminalen er ført ut eller fjernet ("cleared").

Prøvingen utføres deretter basert på den FTAP-prøvekonfigurasjon som er beskrevet ovenfor. Etter utløpet av en tilstrekkelig tid kan nettet sende en FTAPStatsGetRequest- melding for å hente ut de statistiske verdier som er oppsamlet i terminalen, i trinn 616. Ved mottaking av meldingen svarer terminalen med en FTAPStatsGetResponse- melding som inneholder samme transaksjonsidentifikasjonsverdi som den i forespørselsmeldingen FTAPStatsGetRequest og de etterspurte statistiske verdier, i trinn 618. Som vist på fig. 6 inneholder tidsperioden mellom responsmeldingen og forespørselsmeldingen prøvevarigheten som de statistiske resultater skal innsamles i, av terminalen.

I et bestemt aspekt av oppfinnelsen kan statistiske resultater samles inn for hver enkelt terminaldriftstilstand, så som ledig tilstand (idle) og oppkoplet tilstand (connected). I en bestemt utførelse og når håndteringsprotokollen for luftlinken er i en bestemt tilstand, for eksempel en av de to tilstander som er nevnt i forrige setning, klareres innsamlingen av statistiske resultater for denne tilstand, og innsamlingen for samtlige andre tilstander sperres. I en bestemt utførelse og når den ledige tilstand er klarert for statistiske resultater ved innsamling inkrementeres IdleASPChange når en indikasjon RouteUpdate. IdleHO mottas, og IdleTime inkrementeres for hver enkelt tidsluke. I motsatt tilfelle, når det er oppkoplingstilstanden som er klarert for innsamling av statistiske resultater inkrementeres ConnectedSSChange når det foreligger en endring i betjeningssektoren og ConnectedTime inkrementeres for hver tidsluke.

I en bestemt utførelse klareres den statistiske innsamling for kontrollkanalen når denne kanal er i ledig eller oppkoplet tilstand. Når innsamlingen er klarert for kontrollkanalen inkrementeres FirstSyncCCPkt når den første CC MAC Layer-pakke i en synkron kapsel mottas vellykket i terminalen og CCTime inkrementeres ved starten av hver kontrollkanalsyklus.

Tabell 9 setter opp feltene for de fire meldinger som brukes for statistisk innhenting, i samsvar med en særlig utførelse. Hver melding innbefatter et mel-dingsidentifikasjonsfelt som brukes til å identifisere meldingstypen, og et transak-sjonsidentifikasjonsfelt som brukes til å identifisere transaksjonen. Meldingene FTAPStatsClearRequest og FTAPStatsGetResponse omfatter videre en eller flere registreringer for attributt-ID, med hver registrering av denne type for attributtene IdleASPStats, ConnectedSSStats eller FirstSyncCCPktStats (beskrevet nedenfor). Meldingen FTAPStatsGetResponse omfatter videre en eller flere AttributeRecord-registreringer, og hver slik registrering er en enkel registrering for de tre attributtene IdleASPStats, ConnectedSSStats eller FirstSyncCCPktStats beskrevet i tabell 10-12. Feltene MessagelD, TransactionID og AttributelD er hvert 8 b i lengde, og hver registrering AttributeRecord har en lengde som er beskrevet nedenfor.

Tabell 10 viser feltene for attributtregistreringen IdleASPStats, eventuelt inkludert i meldingen FTAPStatsGetResponse. Denne attributtregistrering gir de statistiske resultater for endringer i den aktive sektors pilot, som innsamlet i terminalen.

Tabell 11 viser feltene for attributtregistreringen ConnectedSSStats, som også kan være innbefattet i meldingen FTAPStatsGetResponse. Denne attributtregistrering gir de statistiske resultater for endringer i betjeningssektorer, som innsamlet av terminalen.

Tabell 12 lister opp feltene for attributtregistreringen FirstSyncCCPktStats, og denne registrering kan også kan være innbefattet i meldingen FTAPStatsGetResponse. Attributtregistreringen gir de statistiske resultater for den første synkrone CC-pakke, som innhentet av terminalen.

Tabell 13 setter opp kanalene som brukes for sending av de fire meldinger, nemlig adressemodusen, SLP-transmisjonsskjemaet og transmisjonsprioriteten.

Foroverlinkytelsen kan bestemmes ut fra de statistiske resultater som samles inn i terminalen og rapporteres tilbake til aksessnettet. Enkelte av ytelsesberegningene er beskrevet nedenfor.

Forholdet 5/3 i likningene ovenfor tilsvarer 1,667 millisekunder for hver tidsluke i cdma2000. Andre foretrukne verdier kan også utledes basert på annen statistikk og kan logges inn i aksessnettet, for eksempel kan de DRC-verdier som mottas fra terminalene logges inn for å bestemme høyytelsen for DRC-symbolene i DRC-kanalen.

Det vises til fig. 2B hvor en terminal 106 og RX-dataprosessoren 260 kan arbeide for å behandle FTAP-prøvepakkene og formidle disse via multipleksenheten 262 til styreenheten 270. Sistnevnte identifiserer da og trekker forskjellig type informasjon fra hver enkelt prøvepakke, dvs. betjeningssektoren, betjeningsnummeret og lengden av pakken, og deretter danner den tilbakekoplingspakker med den relevante informasjon, akkurat som beskrevet ovenfor. Disse frembrakte pakker kan lagres i tilbakekoplings-bufferen 278, og ved et passende tidspunkt kan de hentes ut fra denne, rutes via multipleksenheten 284 og behandles av TX-dataprosessoren 286 for transmisjon via returkanalen RTC.

Fig. 2A viser hvordan tilbakekoplingspakkene blir behandlet i dataprosessoren 234 i aksesspunktet 104 og ført til styreenheten 220 som deretter utfører identifikasjon og trekker ut forskjellig type informasjon fra hver av dem, dvs. betjeningssektoren, sekvensnummeret og lengden av hver dekket prøvepakke. Styreenheten 220 oppdaterer videre de variable som er opprettholdt for hver betjeningssektor, basert på den informasjon som er trukket ut av tilbakekoplingspakkene, som beskrevet ovenfor. Styreenheten 220 kan videre arbeide for å utføre de beregninger som er beskrevet ovenfor, for forskjellige ytelsesverdier for foroverlinken, og andre slike verdier kan utledes basert på andre statistiske resultater som kan være logget inn i aksessterminalen. Som et eksempel kan de mottatte prøvepakker etter innlogging bestemmes, og likeledes kan sannsynligheten for en tapt pakke logges inn, sannsynlighet for falsk alarm, osv.

PrøveanvendelsesprotokoII (RTAP) for returkanalen

En slik protokoll RTAP gir de nødvendige prosedyrer og fremgangsmåter som trengs for konfigurering, kontroll, styring og utførelse av forskjellige prøver i returkanalene, innbefattet returtrafikkanalen RTC. Prosedyrene for protokollen RTAP kan grupperes i følgende kategorier: -Prøveparameterkonfigurasjon - innbefatter prosedyrer og meldinger for styring av prøvekonfigurasjonene i terminalen og aksessnettet, og -Pakketransmisjon og mottaking av prøvepakker i henhold til RTAP - innbefattet prosedyrer for å generere slike prøvepakker og tilsvarende utfyllingspakker i terminalen, sending av de frembrakte pakker ved nærmere bestemte overføringshastigheter via returtrafikkanalen, og behandling av de mottatte pakker i aksessnettet.

Prosedyrene og meldingene er beskrevet i nærmere detalj nedenfor. Færre, ytterligere og/eller forskjellige prosedyrer og meldinger kan også fremskaffes for RTAP, og dette vil også være innenfor oppfinnelsens ramme.

RTAP kan håndtere prøvingen av kanalen RTC ved forskjellig overføringshastig-het, og tabell 14 nedenfor setter opp de enkelte modi som kan håndteres av denne kanal.

RTAP kan håndtere samling av bestemte statistiske verdier i aksessnettet, og disse verdier kan brukes til å bestemme forskjellige ytelsesverdier, så som totaltrafikk per tidsenhet og pakkefeilhyppighet (PER).

Tabell 15 nedenfor setter opp de statistiske verdier som kan samles inn og opprettholdes i aksessnettet.

Fig. 7 viser et skjema over en totalprosess 700 for prøving av returtraifkkanalen RTC, i samsvar med en bestemt utførelse av oppfinnelsen. Prosessen kan bruke forskjellige prøver, så som for eksempel ytelsen i returkanalen, pakkefeilhyppigheten, etc.

Innledningsvis setter aksessnettet opp en forbindelse med terminalen på normal måte, dersom det ikke er noen pågående forbindelse mellom dem, i trinn 712. Aksessnettet sender deretter meldingen RTAPParameterAssignment til terminalen for å konfigurere protokollen RTAP, i trinn 714. Meldingen innbefatter en attributt RTAPTestPktEnable for registrering for å klarere sendingen av prøvepakkene fra aksessterminalen. Denne terminal utfører den nødvendige konfigurasjon og svarer deretter til aksessnettet med en melding RTPParameterComplete for å indikere at den er klar for konfigurasjonsprøvene, i trinn 716.

Deretter sender terminalen RTAP-prøvepakker til aksessnettet, i trinn 718. Antallet pakker kan være vilkårlig, og den statistiske informasjon som skal samles inn i aksessnettet og/eller terminalen kan bestemmes ved prøvekonfigurasjonen.

Etter innsamling av tilstrekkelig mengde statistisk materiale frigir aksessnettet forbindelsen i trinn 720, men dette trinn kan utelates dersom for eksempel aksessnettet utfører enkelte prøver eller funksjoner. Nettet kan bruke de statistiske resultater etter samlingen til å beregne pakkefeilhyppigheten og totalytelsen, som beskrevet nedenfor. Forskjellige detaljer for prosessen 700 er likeledes beskrevet nedenfor.

RTAP-prøveparameterkonfigurasjon

Aksessnettet eller terminalen kan aktivere protokollen RTAP for å prøve returkanalene. Ved slik aktivering utfører terminalen en startprosedyre for RTAP-konfigurasjonen, og denne prosedyre tar ned flaggene for RTAP-prøvepakkemodusen og modusen for konfigurert overføringshastighet.

Fig. 8 viser et flytskjema over en særskilt utførelse av en slik parameterkonfigurasjonsprosess 800. Prosessen dekker trinnene 714 og 716 på fig. 7. For å sette i gang eller endre prøvekonfigurasjonen sender aksessnettet en melding RTAPParameterAssignment som omfatter en bestemt verdi for transaksjonsidentifikasjonsfeltet og videre kan innbefatte en eller flere attributtregistreringer for RTAP-modusflaggene som opprettholdes av terminalen, i trinn 812. Via attributtregistreringene i meldingen kan aksessnettet styre de prøver som skal utføres.

Ved mottakingen av denne melding fra aksessnettet utfører terminalen startprosedyren som er beskrevet ovenfor, i trinn 814. Terminalen utfører deretter en slik oppstartingsprosedyre i trinn 816. I en bestemt utførelse setter denne prosedyre en 12 b variabel Vi(SRev) til null, idet denne variabel brukes til å følge sekvensnummeret for de prøvepakker som sendes ved en bestemt overføringshastighet som tilsvarer Ratelndex i (vist i tabell 18) for samtlige mulige returkanalhastigheter, dvs. for alle mulige verdier av i.

Terminalen setter også sine RTAP-modusflagg basert på attributtene, dersom det er noen slike, nemlig de som eventuelt da er innlagt i den mottatte melding, i trinn 818. Spesielt kan den mottatte melding omfatte en attributt RTAPTestPktEnable og/eller en attributt PacketRateMode. Den første attributt innbefattes dersom terminalen skal starte sendingen av pakkene via kanalen RTC, mens den andre innbefattes dersom kanalover-føringshastigheten skal konfigureres.

Hvis den mottatte melding innbefatter den sistnevnte attributt klareres prøve-pakkemodusen, verdien av feltet RTAPTestPktPersistence i attributten lagres, pakkebufferen, dvs. bufferen 280 på fig. 2B tømmes, og en TestPktOverflowBit settes til null. Hvis så den mottatte melding omfatter attributten PacketRateMode klareres modus Configured Packet Rate og verdiene av MinRate og MaxRate-feltene i attributten blir lagret.

Ved avslutningen av prøvekonfigurasjonene som er spesifisert i meldingen RTAPParameterAssignment og innenfor TRTAPConflg (dvs. to) sekunder etter mottakingen av meldingen sender terminalen en melding RTAPParameterComplete med transaksjonsidentifikasjonsfeltet satt til samme verdi som den verdi som ble mottatt i den tilsvarende melding, og dette gjøres i trinn 820.

Ved mottaking av denne melding fra terminalen utfører aksessnettet en prøvesta-tistikk og en startparameterprosedyre, som tilbakestiller RTAPTestPktSent[i], RTAPTestPktRecd[i] og RTAPTestTime opp til null, idet dette betyr tilbakestilling for alle mulige verdier av i, i trinn 822.

Terminalen tilbakestiller også sine RTAP-modusflagg ved avslutningen av utprøvingen med protokollen RTAP. I en bestemt utførelse og hvis protokollen mottar en ConnectedState. ConnectionClosed eller en indikasjon RouteUpdate. ConnectionLost fra det øvre signaleringslag sperres modusen Configured Packet Rate og RTAP-prøve-pakkemodusen sperres også dersom den tidligere var klarert og dersom verdien av feltet RTAPTestPktPersistence i attributten RTAPTestPktEnable i den sist mottatte melding RTAPParameterAssignment var 00.

Tabell 16 setter opp feltene for sendingen RTAPParameterAssignment i samsvar med en bestemt utførelse.

Tabell 13 setter opp de forskjellige felt for attributtregistreringene som kan innbefattes i meldingen RTAPParameterAssignment, i samsvar med en bestemt utførelse. Første spalte i tabell 17 fastlegger de to forskjellige attributtregistreringer som kan innbefattes i denne melding. Attributtregistreringen RTAPTestPktEnable innbefatter tre felt - lengde, attributtidenfikasjon og persistens for RTAPTestPkt. Attributtregistreringen inneholder fire felt - lengde, attributtidentifikasjon, minstetakt og maksimaltakt. Lengdefeltet gir lengden av attributtregistreringen, i oktetter, unntatt selve lengdefeltet, idet dette er to oktetter langt. Følgelig blir lengden av RTAPTestPktEnable-attributtregistreringen 6 oktetter eller 24 b, og lengden av denne attributtregistrering pluss lengdefeltet selv blir åtte oktetter eller 32 b.

Tabell 18 setter opp kartleggingen eller omvandlingen av Ratelndex-verdiene i forhold til taktene eller overføringshastighetene i returtraifkkanalen.

I en bestemt utførelse sendes meldingen RTAPParameterAssignment via kontrollkanalen og kanalen FTC, adressert til terminalen og med SLP satt til pålitelig og transmisjonsprioriteten satt til 40.

Tabell 19 setter opp de enkelte felt for meldingen RTAPParameterComplete i samsvar med en bestemt utførelse.

I en bestemt utførelse sendes meldingen RTAPParameterComplete via returtrafikkanalen og adressert til aksessnettet (unicast-adressering) med SLP satt til pålitelig og transmisjonsprioriteten satt til 40.

Sending og mottaking av RTAP-pakker

Hvis modus for prøvepakkene er satt opp genererer terminalen disse prøvepakker og sender dem via returtrafikkanalen til aksessnettet. I en bestemt utførelse genereres pakken for hvert bestemt tidsintervall, dvs. hvert 16-lukes intervall og i synkronisme med CDMA-systemtiden, og i en annen utførelse omfatter pakkene informasjon som dekker de fysisklagpakker for RTC, som sendes opp til, men ikke innbefattet dette tidspunkt for genereringen.

Tabell 20 setter opp feltene for en RTAP-prøvepakke i samsvar med en bestemt utførelse.

Siden det forventes at en RTAP-prøvepakke sendes fra terminalen for hver enkelt ramme vil RevSysTime som ligger i hver slik pakke kunne brukes som sekvensnummer for pakken.

Hvis modusen for konfigurert pakkerate er etablert sender terminalen en RTAP-utfyllingspakke med variabel lengde og den lengde eller størrelse som er nødvendig for å fylle opp returtrafikkanalpakken som inneholder RTAP-prøvepakken, ved den valgte hastighet. Tabell 21 nedenfor setter opp feltene for en slik utfyllingspakke for FTAP, i samsvar med en bestemt utførelse.

De genererte RTAP-prøvepakker legges i kø for sending via returtraifkkanalen, og terminalen sørger for bufferbehandling, dvs. i bufferen 280 på fig. 2B, for et bestemt antall på åtte eller mer, slike RTAP-prøvepakker. Sifferet RTAPTestPktOverflowBit indikerer om enkelte av pakkene er tap på grunn av bufferoverløp og settes til 1 dersom dette er tilfelle.

RTAP-prøvepakkene sendes i samsvar med et sett regler, og en bestemt utførelse gjennomgår disse nedenfor. Prøvepakkene tildeles en bestemt transmisjonsprioritet som kan være 5, og RTAP-utfyllingspakkene, dersom det er noen slike tildeles også en annen transmisjonsprioritet, for eksempel 255. Terminalen sender de køoppsatte RTAP-prøve-pakkene og utfyllingspakkene, dersom det er noen, i Connected State, dvs. tilstanden for oppkopling.

I en bestemt utførelse sendes prøvepakkene ved en hastighet eller en rate som bestemmes ut fra et nærmere bestemt valgskjema, og dersom modus Configured Packet Rate er satt opp velger terminalen en RTC-takt eller -hastighet som er i samsvar med et sett regler, og en utførelse av disse regler skal gjennomgås her. Ellers velger terminalen en hastighet i samsvar med den MAC-protokoll for returtraifkkanalen og som er beskrevet i det allerede nevnte HAI-dokument.

Tabell 22 setter opp de enkelte variable som opprettholdes av terminalen for valg av hastighet for RTAP-prøvepakkene.

For den første prøvepakke setter terminalen TargetRate, dvs. den ønskede over-føringshastighet til MinRate og setter videre den valgte hastighet til den minste av disse størrelser TargetRate og MACMaxRate. For hver etterfølgende prøvepakke velger terminalen hastigheten for pakken ut fra følgende prosedyre:

Prosedyren ovenfor går i syklus gjennom alle de aktuelle overføringshastigheter eller rater, opp til og begrenset av den MaxRate som er spesifisert i meldingen RTAPParameterAssignment og den MACMaxRate som er tillatt i henhold til MAC-protokollen. Dersom terminalen sender en RTC-pakke som inneholder en prøvepakke ved en hastighet med Ratelndex i inkrementeres det tilhørende sekvensnummer for den sendte prøvepakke ved å inkrementere den variable V(j(SRev).

Hvis terminalen mottar en ConnectedState. ConnectionClosed eller en indikasjon RouteUpdate. ConnectionLost søker den ikke å etablere noen forbindelse for sending av noen prøvepakker som har blitt holdt tilbake i køen.

I en bestemt utførelse opprettholder aksessnettet flere variable, V(RRTap) og X[i] for å holde kontroll med RTAP-prøvepakkene. Den første av disse størrelser er en 8 b variabel som tilsvarer sekvensnummeret for den neste prøvepakke som forventes mottatt i aksessnettet, mens X[i] er et array eller en gruppe med 12 b variable, og hver av disse variable tilsvarer sekvensnummeret for den neste prøvepakke som forventes å ligge i en fysisklagpakke for returtrafikkanalen og sendt ved en hastighet som tilsvarer Ratelndex i. Disse variable settes opp av aksessnettet ved mottaking av den første prøvepakke etter mottakingen av meldingen RTAPParameterComplete. For oppsettingen settes uttrykket V(Rrtap) til RevSysTime-feltet i RTAP-prøvepakken, mens X[i] settes til Seq_i-feltet for den første slike prøvepakke, for samtlige mulige verdier av i.

I en bestemt utførelse prosesserer aksessnettet for hver enkelt prøvepakke som mottas ved en hastighet som tilsvarer Ratelndex k, den mottatte pakke og basert på følgende prosedyre og bruk av verdien av RevSysTime-feltet i den mottatte pakke:

I en bestemt utførelse prosesserer aksessnettet videre feltene i den mottatte RTAP-prøvepakke ved bruk av verdiene i Seq_k-feltene for samtlige mulige verdier av k, på følgende måte:

I en bestemt utførelse utføres driftstrinnene og sammenlikningene av sekvensnummer i modulo 2S aritmetikk uten fortegn, hvor S angir antallet siffer som brukes for å representere sekvensnummeret.

Returlinkytelsen kan bestemmes ut fra den innsamlede statistikk. Enkelte av ytelsesberegningene er beskrevet nedenfor. I det følgende gir PhysLayerPktSize[i] antallet siffer i en fysisklagpakke ved en overføringshastighet som tilsvarer Ratelndex i.

I

Det refereres nå igjen til fig. 2B, i terminal 106 kan da styreenheten 270 arbeide for å generere RTAP-prøvepakkene, idet disse kan ligge lagret i bufferen 280. Ved det riktige tidspunkt hentes disse pakker ut fra bufferen, rutes gjennom multipleksenheten 284 og behandles i TX-dataprosessoren 286 for sending via returtrafikkanalen. Styreenheten 270 kan videre gi en overføringshastighetskontroll til modulatoren 288 for de valgte has-tigheter eller rater for prøvepakkene.

Det vises nå til fig. 2A for et aksesspunkt 104 hvor RTAP-prøvepakkene blir behandlet i RX-dataprosessoren 234 og overført til styreenheten 220 som deretter identifiserer informasjonen fra hver prøvepakke og trekker ut forskjellig type slik informasjon fra den, for eksempel hastigheten og sekvensnummeret for hver mottatt prøve-pakke og sekvensnumrene for de siste sendte pakker for samtlige aktuelle overføringshas-tigheter. Styreenheten 220 oppdaterer videre de variable som opprettholdes for hastig-hetene og basert på informasjonen som trekkes ut fra de mottatte prøvepakker, som beskrevet ovenfor. Styreenheten 220 kan videre arbeide slik at den utfører de beregninger som er beskrevet ovenfor for forskjellige returlinkytelsesverdier.

Beskrivelsen ovenfor representerer en bestemt implementering av teknikken ifølge oppfinnelsen. Færre, ytterligere og/eller forskjellige prøver kan også utføres, og færre, ytterligere og/eller andre statistiske resultater kan innsamles. Videre kan færre, ytterligere og/eller forskjellige prosedyrer og meldinger tilveiebringes, og hver melding kan innbefatte færre, ytterligere og/eller forskjellige felter enn de som er beskrevet ovenfor. Således vil forskjellige variasjoner av de spesifikke implementeringer som er beskrevet ovenfor kunne tenkes og vil kunne ligge innenfor oppfinnelsens ramme, gitt av patentkravene.

For å gjøre beskrivelsen her klarer har forskjellige aspekter og utførelsesformer av oppfinnelsen blitt utdypet for høyhastighets pakkedataoverføring i henhold til standarden cdma2000. Teknikkene kan imidlertid også bruks for andre kommunikasjonssystemer, for eksempel i W-CDMA. Forskjellige forskjeller vil imidlertid foreligge mellom cdma2000 HAI og dette system, og de teknikker som her er beskrevet kan da måtte modifiseres for bruken, for eksempel for å ta hensyn til forskjellen i signalpro-sessering.

Fagfolk vil innse at de enkelte data, instruksjoner, kommandoer, informasjons-grupper, signaler, sifre, symboler og chips som her er omtalt i beskrivelsen fortrinnsvis kan representeres ved spenninger, strømmer, elektromagnetiske bølger, magnetiske felter eller partikler, optiske felter eller partikler eller en kombinasjon av disse.

Fagfolk vil videre innse at de forskjellige illustrative logiske blokker, moduler, kretser og algoritmetrinn som her er beskrevet i forbindelse med de utførelser som er valgt, kan implementeres som elektronisk maskinvare, datamaskinprogramvare eller kombinasjoner. De forskjellige illustrative komponenter, blokker, moduler, kretser og trinn er her beskrevet generelt når det gjelder funksjonsdyktighet. Enten denne implementeres som maskinvare eller programvare vil være avhengig av den bestemte anvendelse og konstruksjonsbegrensninger for det totale system. Fagfolk vil innse at maskinvare og programvare vil kunne gå om hverandre ved slike forhold og hvordan den beskrevne funksjonsdyktighet best kan implementeres for hver særskilt anvendelse.

Som eksempler kan de enkelte illustrative logiske blokker, moduler, kretser og algoritmetrinn som er beskrevet i forbindelse med de utførelser som er tatt frem her, implementeres eller utføres ved hjelp av en digital signalprosessor (DSP), en anvendelsesspesifikk integrert krets (ASIC), en feltprogrammerbar portgruppe, også benevnt et array (FPGA) eller en annen programmerbar logisk krets, diskret portkrets eller transistorlogikksammenstilling, diskrete maskinvarekomponenter så som for eksempel registre og FIFO-kretser, en prosessor som utfører et sett fastvareinstruksjoner, enhver konvensjonell programmerbar mykvaremodul og en prosessor eller en kombinasjon av dette og innrettet for å kunne utføre de funksjoner som er beskrevet her. Prosessoren kan fordelaktig være en mikroprosessor, men i et alternativ kan den være enhver konvensjonell prosessor, styreenhet, mikrokrets eller tilstandsmaskin. Mykvaremodulene kan ligge i et lager (f.eks. lagrene 222 og 272 på fig. 2A og 2B) og utført av en prosessor (så som styreenhetene 220 og 270 på fig. 2A og 2B). Lageret kan være av typen RAM, et flashlager, et lager av typen ROM, et lager av typen EPROM, et lager av typen EEPROM, registre, platelagre, en uttakbar diskett eller annen lagringsplate, en CD-ROM, eller en annen form for lagringsmedium kjent innenfor teknikken. Prosessoren kan ligge i en ASIC (ikke vist). En slik ASIC kan ligge i en telefon (ikke vist). I et alternativ kan prosessoren ligge i en telefon. Prosessoren kan implementeres som en kombinasjon av DSP og en mikroprosessor eller som to mikroprosessorer i forbindelse med en DSP-kjerne etc.

Overskrifter er her tatt med for referanse og for å lette lokaliseringen av bestemte seksjoner. Overskriftene er imidlertid ikke ment å begrense oppfinnelsens konsept, og dette konsept kan også ha anvendbarhet i andre seksjoner i hele beskrivelsen.

Beskrivelsen ovenfor av de foretrukne utførelser er lagt opp for å muliggjøre at enhver person som er noe bevandret innenfor faget kan bruke eller lage oppfinnelsen. De enkelte modifikasjoner til de utførelser som er vist vil være åpenbare for fagfolk, og hovedprinsippene kan også brukes i andre utførelser uten bruk av oppfinnerisk virksomhet. Således er ikke den foreliggende oppfinnelse ment å være begrenset til de utførelsesformer som er vist her, men skal innrømmes videst mulig omfang i samsvar med de prinsipper og de nye trekk som her er demonstrert, i den utstrekning dette inngår i de patentkrav som er satt opp nedenfor.

Claims

1. Fremgangsmåte (400, 500) for prøving av flere kanaler tilordnet en foroverlink i et trådløst datakommunikasjonssystem (100), karakterisert ved: mottaking av en første melding som omfatter prøveoppsetting for en eller flere kanaler, herunder trafikkanaler og hjelpekanaler eller en kombinasjon av slike (414, 512), konfigurering av den ene eller flere kanaler basert på prøveoppsettingen i den første melding (514), mottaking av prøvepakker via en forovertrafikkanal (418), sending av tilbakekoplingspakker via en returtrafikkanal (418), idet hver tilbakekoplingspakke dekker null eller flere prøvepakker og omfatter en overføringskilde og et sekvensnummer for hver dekkede prøvepakke, og sending av signaleringsdata via trafikkanalen eller en eller flere hjelpekanaler.

2. Fremgangsmåte (400, 500) ifølge krav 1, karakterisert ved at hver eneste tilbakekoplingspakke omfatter data som beskriver en eller flere prøvepakker.

3. Fremgangsmåte (400, 500) ifølge krav 1, karakterisert ved at det trådløse datakommunikasjonssystem (100) er et CDMA-system.

4. Fremgangsmåte ifølge krav 3, karakterisert ved at CDMA-systemet er et som kan arbeide etter standarden cdma2000 HAI.

5. Dataprogram omfattende flere prosessorutførbare instruksjoner innkodet på et prosessormedium som kommunikativt er koplet til en digitalsignalprosessinnretning (DSPD) for tolkning av digital informasjon, karakterisert ved at når instruksjonene utføres på DSPD så utfører programmet trinnene i krav 1.

6. Fremgangsmåte (400, 500) ifølge krav 1, karakterisert ved at mottak av prøvepakkene (418) omfatter mottak av en første datatransmisjon omfattende flere prøve-pakker, og idet overføring av tilbakekoplingspakker (418) omfatter overføring i en andre datatransmisjon av flere tilbakekoplingspakker, idet disse tilbakekoplingspakker innbefatter parameterverdiene som er deskriptive for prøvepakkene.

7. Fremgangsmåte (400, 500) ifølge krav 6, karakterisert ved at én tilbakekoplingspakke er dannet for hvert bestemt tidsintervall.

8. Fremgangsmåte (400, 500) ifølge krav 6, karakterisert ved at hver tilbakekoplingspakke dekker null eller flere prøvepakker.

9. Fremgangsmåte (400, 500) ifølge krav 8, karakterisert ved at hver tilbakekoplingspakke omfatter et første felt som indikerer en bestemt protokoll som pakken hører til.

10. Fremgangsmåte (400, 500) ifølge krav 8, karakterisert ved at hver tilbakekoplingspakke omfatter et andre felt som indikerer en bestemt pakketype for tilbakekoplingspakken.

11. Fremgangsmåte (400, 500) ifølge krav 8, karakterisert ved at hver tilbakekoplingspakke omfatter et tredje felt som indikerer starten på et bestemt tidsintervall som dekkes av pakken.

12. Fremgangsmåte (400, 500) ifølge krav 8, karakterisert ved at hver tilbakekoplingspakke omfatter et fjerde felt som indikerer om eventuelle pakker ble mistet på grunn av bufferoverløp.

13. Fremgangsmåte (400, 500) ifølge krav 8, karakterisert ved at hver tilbakekoplingspakke omfatter et femte felt som indikerer et bestemt antall registreringer som er lagt inn i pakken, idet en av disse registreringer innbefattes for hver prøvepakke som dekkes av pakken.

14. Fremgangsmåte (400, 500) ifølge krav 8, karakterisert ved at hver tilbakekoplingspakke omfatter en registrering for hver prøvepakke som dekkes av den, idet hver registrering omfatter et sett felt for et sett parameterverdier som er identifisert for den tilsvarende dekkede prøvepakke.

15. Fremgangsmåte (400, 500) ifølge krav 14, karakterisert ved at hver registrering innbefatter et første felt som indikerer om registreringen innbefatter et sekvensnummer for en signaleringsmelding eller ikke, brukt for tildeling av den første kanal.

16. Fremgangsmåte (400, 500) ifølge krav 15, karakterisert ved at hver registrering innbefatter et andre felt som indikerer sekvensnummeret for signaleringsmel-dingen.

17. Fremgangsmåte (400, 500) ifølge krav 14, karakterisert ved at hver registrering innbefatter et tredje felt som indikerer en transmisjonskilde for prøvepakken som dekkes av registreringen.

18. Fremgangsmåte (400, 500) ifølge krav 14, karakterisert ved at hver registrering innbefatter et fjerde felt som indikerer en tidsperiode som prøvepakken som er dekket av registreringen ble mottatt.

19. Fremgangsmåte ifølge krav 14, karakterisert ved at hver registrering innbefatter et femte felt som indikerer et antall media aksesskontrol (MAC)- pakker som mottas i en fysisklagpakke som inneholdes i den prøvepakke som er dekket av registreringen.

20. Fremgangsmåte (400, 500) ifølge krav 14, karakterisert ved at hver registrering innbefatter et sjette felt som indikerer om et sekvensnummer for den dekkede prøvepakke er innbefattet i registreringen eller ikke.

21. Fremgangsmåte (400, 500) ifølge krav 20, karakterisert ved at hver registrering innbefatter et syvende felt som indikerer et sekvensnummer for den dekkede prøve-pakke.

22. Fremgangsmåte (400, 500) ifølge krav 6, karakterisert ved at hver tilbakekoplingspakke omfatter en parameterverdi som indikerer utelatelse av en eller flere prøve-pakker.

23. Fremgangsmåte (400, 500) ifølge krav 6, karakterisert ved at hver prøve-pakke innbefatter et første felt som indikerer en spesiell protokoll som prøvepakken hører til.

24. Fremgangsmåte (400, 500) ifølge krav 6, karakterisert ved at hver prøve-pakke innbefatter et andre felt som indikerer en spesiell pakketype for prøvepakken.

25. Fremgangsmåte (400, 500) ifølge krav 6, karakterisert ved at hver prøve-pakke innbefatter et tredje felt som indikerer sekvensnummeret for prøvepakken.

26. Fremgangsmåte (400, 500) for prøving av en eller flere kanaler i et trådløst datakommunikasjonssystem (100), karakterisert ved: sending av flere prøvepakker via en forovertrafikkanal (418), mottaking av flere tilbakekoplingspakker via en returtrafikkanal (418), idet hver av disse pakker dekker null til flere prøvepakker og innbefatter en transmisjonskilde og et sekvensnummer for hver dekket prøvepakke, og oppdatering av flere variable for flere transmisjonskilder, basert på transmisjonskilden og sekvensnummeret for hver prøvepakke som dekkes av de mottatte tilbakekoplingspakker.

27. Fremgangsmåte (400, 500) ifølge krav 1 for prøving av foroverlinkforbin-delser for bestemte konfigurasjoner av en eller flere hjelpekanaler i det trådløse datakommunikasjonssystem (100), karakterisert ved: idet den første melding innbefatter prøveoppsettinger for en eller flere hjelpekanaler, og idet konfigureringen (514) omfatter konfigurering av hver hjelpekanal basert på de prøveoppsettinger som gjelder denne kanal, og idet sendingen (418) omfatter sending av hver konfigurert hjelpekanal i samsvar med de anvendbare prøveoppsettinger.

28. Fremgangsmåte (400, 500) ifølge krav 27, karakterisert ved at hver prøveoppsetting er tilveiebrakt via en respektiv registrering i den første melding.

29. Fremgangsmåte (400, 500) ifølge krav 27, karakterisert ved at hjelpekanalen eller -kanalene brukes for signalering.

30. Fremgangsmåte (400, 500) ifølge krav 27, karakterisert ved at den første melding omfatter en første prøveoppsetting for en bestemt sifferverdi som skal overføres via en bekrefltelseskanal (ACK).

31. Fremgangsmåte (400, 500) ifølge krav 27, karakterisert ved at den første melding innbefatter en andre prøveoppsetting for en bestemt verdi som skal sendes via en kanal for regulering av dataoverføringshastighet (DRC).

32. Fremgangsmåte (400, 500) ifølge krav 27, karakterisert ved at den første melding omfatter en tredje prøveoppsetting for et bestemt dekke som skal brukes for DRC-kanalen.

33. Fremgangsmåte (400, 500) ifølge krav 27, karakterisert ved at den første melding omfatter en fjerde prøveoppsetting som indikerer vedlikeholdet av en prøvemodus i tilfelle en avslutning av en forbindelse eller en tapt forbindelse.

34. Apparat (106) tilhørende et trådløst datakommunikasjonssystem (100), karakterisert ved: midler (252, 254, 256, 258, 260) for mottaking av flere prøvepakker via en forovertrafikkanal, midler (270) for identifikasjon av en transmisjonskilde og et sekvensnummer for hver mottatt prøvepakke, midler (270) for forming av flere tilbakekoplingspakker for de mottatte prøve-pakker, idet hver tilbakekoplingspakke dekker null eller flere registreringer og innbefatter transmisjonskilden og sekvensnummeret for hver dekket prøvepakke, og midler (286) for prosessering av tilbakekoplingspakkene for sending via en returtrafikkanal.

35. Apparat ifølge krav 34, idet apparatet er en terminal tilhørende det trådløse datakommunikasjonssystem (100), karakterisert ved: midlene (252, 254, 256, 258, 260) for mottak omfatter en mottakerdataprosessor (260) for å motta prøvepakkene via en forovertrafikkanal, midlene (270) for forming omfatter en styreenhet (270) for å identifisere sendekilden og sekvensnummeret for hver mottatte prøvepakke og forme flere tilbakekoplingspakker for de mottatte prøvepakker, og midlene (286) for prosessing omfatter en senderdataprosessor (286) for å prosessere tilbakekoplingspakkene for sending via en returtrafikkanal.

36. Apparat (104) i et trådløst datakommunikasjonssystem (100), karakterisert ved: midler (216) for å prosessere flere prøvepakker for sending via en forovertrafikkanal, midler (234) for å prosessere flere tilbakekoplingspakker som mottas via en returtrafikkanal, idet hver slik pakke dekker fra null til flere prøvepakker og innbefatter en transmisjonskilde og et sekvensnummer for hver dekket prøvepakke, og midler (220) for å oppdatere flere variable for flere transmisjonskilder og basert på transmisjonskilden og sekvensnummeret for hver prøvepakke som er dekket av de mottatte tilbakekoplingspakker.

37. Apparat (104) ifølge krav 36 idet apparatet er et aksesspunkt tilhørende det trådløse datakommunikasjonssystem (100), karakterisert ved: midlene (216) for prosessering av prøvepakker omfatter en senderdataprosessor (216) for å prosessere prøvepakkene for sending via forovertraifkkanalen, midlene (234) for prosessering av tilbakekoplingspakker omfatter en mottakerdataprosessor (234) for å prosessere tilbakekoplingspakkene som mottas via returtrafikkanalen, og midlene (220) for oppdatering omfatter en styreenhet (220) for oppdatering av variablene for flere transmisjonskilder og basert på transmisjonskilden og sekvensnummeret for hver prøvepakke som er dekket av de mottatte tilbakekoplingspakker.

38. Dataprogram omfattende flere prosessorutførbare instruksjoner innkodet på et prosessorlesbart medium og lager som kommunikativt er koplet til en digitalsignalprosessinnretning (DSPD) for tolkning av digital informasjon for: sending av flere prøvepakker via en forovertrafikkanal, mottaking av flere tilbakekoplingspakker via en returtraifkkanal, idet hver av disse pakker dekker null til flere prøvepakker og innbefatter en transmisjonskilde og et sekvensnummer for hver dekket prøvepakke, og oppdatering av flere variable for flere transmisjonskilder, basert på transmisjonskilden og sekvensnummeret for hver prøvepakke som dekkes av de mottatte tilbakekoplingspakker.