FI111493B - Kontekstitunnisteen määrittäminen otsikkokenttien kompressoinnissa - Google Patents

Description

111493 <

Kontekstitunnisteen määrittäminen otsikkokenttien kompressoinnissa

Keksinnön tausta

Keksintö liittyy kontekstitunnisteen määrittämiseen datapakettien 5 otsikkokenttien kompressoinnissa.

Viime vuosina tapahtunut IP-teknologian (Internet Protocol) nopea kehitys on laajentanut erilaisten IP-pohjaisten sovellusten käyttömahdollisuuksia myös perinteisen Internet-tiedonsiirron ulkopuolelle. Erityisesti IP-pohjaiset puhelinsovellukset ovat kehittyneet nopeasti, minkä seurauksena 10 yhä laajeneva osa puheluiden siirtotiestä myös perinteisissä langallisissa puhelinverkoissa (PSTN/ISDN, Public Switched Telephone Network/lntegrated Services Digital Network) sekä matkaviestinverkoissa (PLMN, Public Land Mobile Network) voidaan periaatteessa toteuttaa IP-teknologiaa hyödyntäen.

Varsinkin matkaviestinverkoissa IP-teknologian nähdään tarjoavan 15 paljon etuja, sillä matkaviestinverkkojen perinteisten puhepalveluiden, jotka voitaisiin hoitaa erilaisten IP-puhesovellusten avulla, lisäksi matkaviestinverkoissa tullaan tarjoamaan yhä enemmän erilaisia datapalveluita, kuten Internetin selaamista, sähköpostipalvelulta, pelejä ym., jotka on tyypillisesti edullisinta toteuttaa pakettivälitteisinä IP-pohjaisina palveluina. Näin matkaviestin-20 järjestelmien protokolliin sovitettavat IP-kerrokset voisivat palvella sekä au-dio/videopalveluita että erilaisia datapalveluita.

Matkaviestinverkoissa on erityisen tärkeää käyttää rajalliset radio-resurssit hyväksi mahdollisimman tehokkaasti. Tämä taas vaikeuttaa IP-protokollien hyväksikäyttöä radiorajapinnalla, koska IP-pohjaisissa protokollis-25 sa erilaisten otsikkokenttien osuus siirrettävästä datasta on hyvin suuri, jolloin vastaavasti hyötykuorman osuus jää pieneksi. Lisäksi radiorajapinnan bittivirhesuhde (BER, Bit Error Rate) ja uplink- ja downlink-suunnan yhteenlaskettu viive (RTT, Round-Trip Time) voivat huonoissa olosuhteissa kasvaa suuriksi, mikä aiheuttaa ongelmia useimmille tunnetuille otsikkokenttien kompressoin-·· 30 timenetelmille. Tämän vuoksi on syntynyt tarve kehittää erilaisiin \P- protokolliin sopiva otsikkokenttien kompressointimenetelmä, joka olisi erityisesti sopiva radiorajapinnan yli tapahtuvaan tiedonsiirtoon: tehokas otsikkokenttien pakkaus, jota kuitenkin pystytään käyttämään olosuhteissa, joissa bittivirhesuhteet ja viiveet kasvavat suuriksi.

35 Tähän tarkoitukseen on viime aikoina standardoitu IETF:ssä (Internet Engineering Task Force) otsikkokenttien kompressointimenetelmää, 2 111493 joka tunnetaan nimellä ROHC (Robust Header Compression). Eräs ROHC.n kehittelyn taustalla olevia ajatuksia on, että datapakettien välityksessä käytettävien lukuisten IP-otsikkokenttien välillä on runsaasti redundanssia paitsi datapakettien sisällä, niin myös niiden välillä. Toisin sanoen, suuri osa otsik-5 kokenttien informaatioista ei muutu lainkaan datapakettien välityksen aikana, jolloin se on helppo rekonstruoida, vaikkei sitä lähetetä lainkaan. Ainoastaan pieni osa otsikkokentistä on sellaisia, joiden käsittämän informaation suhteen on oltava tarkkana kompressoinnissa. Edelleen ROHC käsittää useita kom-pressointitasoja, jolloin kompressoinnin tehokkuus kasvaa aina siirryttäessä 10 ylemmälle tasolle. ROHC pyrkii aina käyttämään tehokkainta mahdollista kompressointia, kuitenkin niin, että ennen siirtymistä seuraavalle tasolla varmistetaan aina kulloisenkin tason riittävä toiminnan varmuus. Lisäksi eräs ROHC:Ile tyypillinen ominaisuus on se, että jättää useita kompressointimene-telmän käytössä olennaisia seikkoja alemman linkkikerroksen hoidettavaksi.

15 Eräs tällainen alemman linkkikerroksen kautta neuvoteltava asia lähettäjän ja vastaanottajan, eli ns. kompressorin ja dekompressorin, välillä on tietyllä radiolinkillä käytettävän ns. kontekstitunnisteen (CID, Context Identifier) pituuden määrittäminen. Kontekstitunnistetta CID käytetään erottamaan samalla radiolinkillä välitettävät useat pakettidatavuot toisistaan. Konteksti-20 tunnisteen CID pituudeksi voidaan määrittää 0, 1 tai 2 tavua (0, 8 tai 16 bittiä), jolloin arvoa nolla käytetään silloin, kun linkillä on vain yksi datavuo. CID:n pituus neuvotellaan siis ennen kompressoinnin aloittamista välitettävälle datalle ja neuvoteltua kontekstitunnisteen CID pituutta käytetään sen jälkeen sekä uplink- että downlink-suuntaan.

25 Eräänä ongelmana yllä kuvatussa järjestelyssä on kontekstitunnis teen CID pituuden joustamattomuus. Kun CID:n pituus on neuvoteltu ennen kompressoinnin aloittamista, voidaan sen arvoa muuttaa vain neuvottelemalla se uudestaan kompressorin ja dekompressorin välillä, jolloin kompressointi joudutaan keskeyttämään. Lisäksi ongelmana on se, että käytettäessä yhtä 30 päätelaiteyhteyttä (radio bearer) joudutaan käyttämään samaa CID-pituutta ·· sekä uplink- että downlink-suuntaan. Kuitenkin esimerkiksi matkaviestinjärjes telmissä edullinen CID-pituus uplink-suunnassa on tyypillisesti huomattavasti lyhyempi kuin downlink-suunnassa. Jos tunnetun tekniikan mukaisessa ratkaisussa CID-pituus määritellään päätelaiteyhteydelle downlink-suunnan tarpeen 35 mukaan, käytetään uplink-suunnan radioresursseja silloin epäoptimaalisesti.

Jos taas CID-pituus määritellään vain uplink-suunta huomioiden, aiheutuu 3 111493 downlink-suunnan dekompressoinnissa ongelmia, koska tarvittava CID-pituus on suurempi kuin neuvoteltu CID-pituus.

Keksinnön lyhyt selostus

Keksinnön tavoitteena on siten kehittää menetelmä ja menetelmän 5 toteuttava laitteisto siten, että yllä mainitut ongelmat saadaan ratkaistua. Keksinnön tavoitteet saavutetaan menetelmällä ja järjestelmällä, joille on tunnusomaista se, mitä sanotaan itsenäisissä patenttivaatimuksissa. Keksinnön edulliset suoritusmuodot ovat epäitsenäisten patenttivaatimusten kohteena.

Keksintö perustuu siihen, että kun havaitaan tarve määritellä data-10 pakettivuolle kontekstitunnisteen pituus, tyypillisesti uudelleenmäärittelynä, tämä määrittely liitetään seuraavaan lähetettävään datapakettiin, edullisesti sen kontekstitunnistekenttään, jossa yhdellä tai usealla bitillä määritetään uusi kontekstitunnisteen pituus. Keksinnön erään edullisen suoritusmuodon mukaisesti tämä määrittely liitetään jokaiseen lähetettävään datapakettiin, jolloin 15 kontekstitunnisteen pituus tarkistetaan jokaisesta datapaketista. Keksinnön erään toisen edullisen suoritusmuodon mukaisesti tämä määrittely liitetään vain ensimmäiseen lähetettävään datapakettiin, minkä jälkeen datapakettivuol-la käytetään tätä kontekstitunnisteen pituutta siihen asti, kunnes se taas määritellään uudelleen vastaavalla tavalla.

20 Keksinnön mukaisen menetelmän ja järjestelmän etuna on, että kontekstitunnisteen pituus voidaan määrittää erisuuriksi uplink- ja downlink-suuntaan, minkä ansiosta tiedonsiirtoresurssien käyttöä voidaan tehostaa. Edelleen keksinnön mukaisen menettelyn etuna on, että vältetään kompres-:'· soinnin ja dekompressoinnin pysäyttäminen ja kontekstitunnisteen pituuden 25 uudelleen neuvotteleminen joka kerta, kun kontekstitunnisteen pituus tarvitsee muuttaa. Vielä keksinnön etuna on, että se mahdollistaa myös eri konteksti-tunnisteen pituuden omaavien datapakettien multipleksaamisen samalle tiedonsiirtoyhteydelle.

Kuvioiden lyhyt selostus 30 Keksintöä selostetaan nyt lähemmin edullisten suoritusmuotojen yhteydessä, viitaten oheisiin piirroksiin, joista: kuvio 1 esittää lohkokaaviona siirtymiä ROHC:n eri kompressointi-tasojen välillä; kuvio 2 esittää lohkokaaviona siirtymiä ROHC:n eri toimintamoodi- 35 en välillä; 4 111493 kuvio 3 esittää lohkokaaviona tunnetun tekniikan mukaisen ROHC:n aiheuttamaa ongelmatilannetta myötä- ja paluukanavien eri suurilla kontekstitunnistekentän pituuksilla; ja kuvio 4 esittää keksinnön erään edullisen suoritusmuodon mukai-5 sen kontekstitunnistekentän käsittävää datapakettia.

Keksinnön yksityiskohtainen selostus

Seuraavassa kuvataan kyseessä olevan otsikkokenttien kompres-sointimenetelmän ROHC toteutusta keksinnön kannalta olennaisin osin. Kyseisen kompressointimenetelmän tarkemman kuvauksen osalta viitataan vielä 10 keskeneräiseen Internet-draftiin ’’Robust Header Compression (ROHC)”, versio 02, 18.9.2000.

Eri kompressointimenetelmissä sekä kompressorille että dekom-pressorille määritellään tyypillisesti konteksti, joka on tila, jota kompressori käyttää lähetettävän otsikkokentän kompressointiin ja dekompressori vas-15 taanotetun otsikkokentän dekompressointiin. Tyypillisesti konteksti käsittää kompressoimattoman version edellisestä otsikkokentästä, joka on lähetetty (kompressori) tai vastaanotettu (dekompressori) tiedonsiirtoyhteyden yli. Lisäksi konteksti voi käsittää datapakettivuota identifioivia erilaisia tietoja, kuten datapakettien jaksonumeroita tai aikaleimoja. Täten konteksti käsittää tyypilli-20 sesti sekä staattista informaatiota, joka pysyy samana koko datapakettivuolle, että dynaamista informaatiota, joka muuttuu datapakettivuon aikana, mutta usein jonkin määritettävän kuvion mukaisesti.

ROHC:ssa käytetään kolmea kompressointitasoa siten, että kompressointi alkaa alimmalta tasolta ja vähitellen siirrytään ylemmälle tasolle.

25 Perusperiaatteena on, että kompressointi suoritetaan aina korkeimmalla mahdollisella tasolla kuitenkin niin, että kompressorilla on riittävä varmuus siitä, että dekompressorilla on riittävästi informaatiota dekompressoinnin suorittamiseen kyseisellä tasolla. Eri kompressointitasojen väliseen siirtymiseen vaikuttavia tekijöitä ovat peräkkäisten otsikkokenttien vaihtelu, dekompressorilta ”· 30 saatavat positiiviset ja negatiiviset kuittaukset sekä kuittausten puuttuessa määrättyjen jaksollisten laskureiden umpeutuminen. Ylemmältä kompressointi-tasolta voidaan vastaavasti tarvittaessa siirtyä alemmalle tasolle.

IP (Internet Protocol), UDP (User Datagram protocol) ja RTP (Real-Time Protocol) protokollien yhteydessä ROHC:n käyttämät kompressointitasot 35 ovat aloitus/päivitystaso (IR, Initiation/Refresh), ensimmäinen taso (FO, First Order) ja toinen taso (SO, Second Order), joiden välisiä siirtymisiä kuvataan 5 111493 kuvion 1 mukaisella kaaviolla. IR-tasoa käytetään kontekstin luomiseen de-kompressorille tai virhetilanteesta toipumiseen. Kompressori siirtyy IR-tasolle aloitettaessa otsikkokenttien kompressointi, dekompressorin esittämästä pyynnöstä tai päivitysajastimen umpeutuessa. IR-tasolla kompressori lähettää 5 IR-otsikkokenttiä kompressoimattomassa muodossa. Kompressori pyrkii siirtymään ylemmälle tasolle, kun dekompressorin vastaanottamasta päivitysin-formaatiosta saadaan varmuus.

FO-tasoa käytetään datapakettivuon otsikkokentissä olevien epäsäännöllisyyksien informoimiseen vastaanottajalle. IR-tason jälkeen kompres-10 sori toimii FO-tasolla tilanteessa, jossa otsikkokentät eivät muodosta yhtenäistä kuviota (ts. peräkkäiset otsikkokentät muuttuvat satunnaisesti siten, että muutoksia ei voida ennakoida) tai kompressori ei voi olla varma, onko dekom-pressori vastaanottanut otsikkokenttien yhtenäisen kuvion määrittelevät parametrit. Tämä on tyypillinen tilanne esimerkiksi välitettäessä puhetta. FO-15 tasolla kompressori lähettää kompressoituja FO-otsikkokenttiä. Kompressori pyrkii taas siirtymään ylemmälle tasolle, kun otsikkokentät muodostavat yhtenäisen kuvion ja saadaan varmuus siitä, että dekompressori on vastaanottanut yhtenäisen kuvion parametrit. FO-tason datapaketit käsittävät tyypillisesti kontekstin päivitystietoa, jolloin onnistunut dekompressointi edellyttää myös 20 peräkkäisten FO-otsikkokenttien onnistunutta välittämistä. Täten dekompres-sointiprosessin onnistuminen on sensitiivinen kadonneille tai vahingoittuneille FO-tason paketeille.

SO-tasolla kompressointi on optimaalista. Otsikkokentät muodostavat yhtenäisen kuvion, joita kompressori kuvaa kompressoiduilla SO-25 otsikkokentillä, jotka käytännössä ovat datapakettien jaksonumeroita. Dekom-pressorille välitetään tieto otsikkokenttien yhtenäisen kuvion määrittelevistä parametreista, joiden parametrien ja vastaanotetun jaksonumeron perusteella dekompressori pystyy ekstrapoloimaan alkuperäiset otsikkokentät. Koska SO-tasolla lähetetyt datapaketit ovat käytännössä riippumattomia toisistaan, on 30 myös dekompressoinnin virheherkkyys alhainen. Kun otsikkokentät eivät enää muodosta yhtenäistä kuviota, kompressori siirtyy takaisin FO-tasolle.

Myös dekompressoinnille on määritetty kolme eri tasoa, jotka ovat sidoksissa dekompressorin kontekstimääritykseen. Dekompressori aloittaa toimintansa aina alimmalta tasolta, jolloin kontekstia ei ole vielä määritetty (No 35 Context). Tällöin dekompressori ei ole vielä dekompressoinut ainuttakaan datapakettia. Kun dekompressori on dekompressoinut ensimmäisen datapa- 6 111493 ketin, joka käsittää staattisen että dynaamisen konteksti-informaation, voi de-kompressori siirtyä suoraan keskimmäisen tason (Static Context) yli aina ylimmälle tasolle (Full Context). Ylimmällä tasolla tapahtuvien useiden virhetilanteiden seurauksena dekompressori siirtyy keskimmäiselle tasolle, mutta 5 tyypillisesti jo yksikin onnistuneesti dekompressoitu datapaketti palauttaa de-kompressorin ylimmälle tasolle.

Eri kompressointitasojen lisäksi ROHC:een on määritetty kolme eri toimintamoodia: yksisuuntainen moodi (U-moodi), kaksisuuntainen optimistinen moodi (O-moodi) ja kaksisuuntainen luotettava moodi (R-moodi), jotka 10 esitetään kuvion 2 mukaisessa kaaviossa. Kuvion 2 mukaisesti jokainen edellä kuvatuista kompressointitasoista (IR, FO, SO) toimii jokaisessa moodissa, mutta kukin moodi toimii kullakin tasolla omalla tavallaan ja tekee myös päätökset siirtymisistä tasojen välillä omalla tavallaan. Toimintamoodin valinta kuhunkin kompressointitilanteeseen riippuu käytettävän tiedonsiirtoyhteyden 15 parametreista, kuten paluukanavan käyttömahdollisuudesta, virhetodennäköi-syyksistä ja -jakaumista, otsikkokenttien koon vaihtelun vaikutuksista ym.

Yksisuuntaisessa moodissa datapaketteja lähetetään vain kompressorilta dekompressorille, joten ROHC:n U-moodi on käyttökelpoinen tilanteissa, joissa paluukanavan käyttö ei ole mahdollista tai suotavaa. U-20 moodissa siirtymät eri kompressointitasojen välillä suoritetaan määrättyjen jaksollisten laskureiden umpeutumisen seurauksena tai otsikkokenttäkuvioi-den vaihtelun perusteella. Koska paluukanavaa ei ole käytössä, on kompressointi U-moodissa tehottomampaa ja datapakettien katoaminen siirtotiellä todennäköisempää kuin kummassakaan kaksisuuntaisessa moodissa. ROHC:n 25 käyttäminen aloitetaan aina U-moodissa ja siirtyminen jompaan kumpaan kaksisuuntaiseen moodiin voi tapahtua sitten, kun ainakin yksi paketti on vastaanotettu dekompressorissa, johon vasteena dekompressori ilmaisee moodinvaihdon olevan tarpeen.

Kaksisuuntainen optimistinen moodi on vastaavanlainen yksisuun-30 täisen moodin kanssa muuten, mutta O-moodissa käytetään paluukanavaa virhetilanteiden korjaamiseen ja huomattavien kontekstipäivitysten kuivaamiseen dekompressorilta kompressorille. Jaksollisia päivityksiä ei tehdä 0-moodissa. O-moodi sopii edullisesti yhteyksille, joilla tarvitaan optimaalinen kompressointitehokkuus vähäisellä paluukanavaliikenteellä. O-moodi tarjoaa 35 kohtuullisen luotettavan datapakettien siirron, jossa kompressorin ja dekom-pressorin välinen synkronointi pystytään tyypillisesti säilyttämään hyvin ja da- 7 111493 tapaketteja katoaa harvoin, silloinkin tyypillisesti merkityksettömiä määriä. Erittäin suurilla virhesuhteilla datapakettien katoamisia siirtotiellä voi kuitenkin tapahtua.

Kaksisuuntainen luotettava moodi poikkeaa edellä mainituista moo-5 deista selvästi. R-moodissa käytetään paluukanavaa kaikkien kontekstipäivi-tysten kuittaamiseen, myös jaksonumeropäivitysten kuittaamiseen. Täten R-moodissa datapaketit voidaan siirtää lähes täysin luotettavasti kompressorin ja dekompressorin välillä. Otsikkokenttien kompressointi ei voi aiheuttaa datapakettien katoamista R-moodissa. R-moodin haittapuolena on hiukan edellä 10 mainittuja moodeja suurempi otsikkokentän koko joissakin tapauksissa sekä huomattavasti lisääntyvä paluukanavallenne.

ROHC:n kolme toimintamoodia ja kolme kompressointitasoa muodostavat erilaisia operointitilanteita otsikkokenttien kompressoinnille, joissa kussakin tilanteessa pitää määritellä kompressorin ja dekompressorin toiminta 15 sekä pakettien välitys näiden välillä. ROHC:ssä käytetään erilaisia paketteja eri operointitilanteiden mukaisiin tarkoituksiin. Tällä hetkellä ROHC:een on määritelty kuusi erilaista datapakettityyppiä, joista neljää käytetään lähetykseen kompressorilta dekompressorille ja kahta paluukanavadatapaketteina dekompressorilta kompressorille. Käytettävien datapakettityyppien määrä 20 saattaa muuttua tulevaisuudessa, mutta kaikille datapakettityypeille on ominaista se, että jokaisen datapaketin alkuun liitetään kulloinkin käytettävän kontekstin määrittelevä kontekstitunniste CID ennen paketin lähettämistä siirtotielle.

Kontekstitunnisteen CID pituus neuvotellaan jokaiselle datapaketti-25 vuolle erikseen kompressorin ja dekompressorin kesken. ROHC-määritysten mukaisesti kulloinkin käytettävän alemman protokollakerroksen (linkkikerroksen) tulee tarjota mekanismi otsikkokenttien kompressoinnissa käytettävien parametrien, siis mm. kontekstitunnisteen pituuden, neuvottelemiseksi. Parametrit neuvotellaan ennen kompressoinnin aloittamista ja tässä 30 yhteydessä datapakettivuon kontekstitunnisteen pituudeksi voidaan tunnetun , Ί* tekniikan mukaisesti määrittää 0, 8 tai 16 bittiä. Yhdellä loogisella tiedonsiirto- kanavalla voidaan välittää samanaikaisesti useaa datapakettivuota, joiden kontekstit identifioidaan ja erotetaan toisistaan kontekstitunnisteen CID avulla. Jos kanavalla välitetään vain yhtä datapakettivuota, mikä on tyypillistä esi-35 merkiksi erilaisissa VolP-sovelluksissa (Voice over IP), saa kontekstitunnisteen CID pituus arvon 0. Välitettäessä useaa datapakettivuota samalla kana- 8 111493 valla määritetään kullekin datapaketti vuolle käytettävästä sovelluksesta, tiedonsiirtoprotokollasta ja kanavaolosuhteista riippuen kontekstitunnisteen pituudeksi joko 8 tai 16 bittiä.

Edellä kuvatuissa kaksisuuntaisissa toimintamoodeissa (O-moodi, 5 R-moodi) neuvoteltua kontekstitunnisteen CID pituutta käytetään myös paluukanavalla. Kuitenkin esimerkiksi matkaviestinjärjestelmissä paluukanavalla (downlink) olisi usein edullista käyttää suurempaa konteksitunnisteen pituutta kuin myötäkanavalla (uplink), koska erityisesti pakettidatapalveluiden käytössä downlink-suuntaan siirretään huomattavasti enemmän dataa kuin uplink-10 suuntaan. Tällöin käytettäessä ROHC:n mukaista otsikkokenttien kompressointia joudutaan kontekstitunnisteen pituus mitoittamaan tyypillisesti paluukanavan tarpeen mukaan, jolloin myötäkanavaa kompressorilta dekompres-sorille hyödynnetään tehottomasti.

Kuvion 3 mukaisella lohkokaaviolla kuvataan ongelmaa, joka syn-15 tyisi silloin, jos nykyisessä ROHC-menettelyssä pyrittäisiin määrittämään myötäkanavalle 8-bittinen kontekstitunniste ja paluukanavalle taas 16-bittinen kontekstitunniste. Esimerkiksi matkaviestinjärjestelmien yhteydessä uplink- ja downlink-suunnan kanavilla on omat kompressori-dekompressoriparit siten, että esimerkiksi päätelaitteessa on kompressori C1, jota uplink-suunnalla ver-20 kon puolella vastaa dekompressori D1. Vastaavasti downlink-suuntaan verkon puolella on kompressori C2, jota vastaa päätelaitteessa dekompressori D2. Täten kompressori C1 lähettää 8-bittisen kontekstitunnisteen käsittäviä datapaketteja (300) uplink-kanavalla dekompressori Ile D1. Jossakin vaiheessa, esimerkiksi vaihdettaessa kompressointitasoa, verkon dekompressori D1 lä-: ' 25 hettää kuittauksen päätelaitteelle downlink-kanavalla, joka kuittaus tapahtuu siirtämällä datapaketti kompressorille C2 (302), joka liittää kuittaukseen 8-bittisen kontekstitunnisteen, koska molemmilla kanavilla on nykyisten ROHC-määritysten mukaisesti käytettävä samaa kontekstitunnisteen pituutta. Kompressori C2 liittää tämän kuittauspaketin downlink-kanavalla siirrettävään 30 päätelaitteelle siirrettävään datavuohon (304). Dekompressori D2 tutkii maini-'! tun kuittauspaketin, mutta koska dekompressori odottaisi 16-bittisellä kon- tekstitunnisteella varustettuja datapaketteja, se tulkitsisi 8-bittistä konteksti-tunnistekenttää seuraavan datapaketin otsikkokentän ensimmäisen tavun myös osaksi kontekstitunnistekenttää CID, jolloin syntyy virhetilanne joko 35 mainitun kuittauspaketin tulkinnassa tai sen dekompressoinnissa.

Edellä kuvattu ongelma voitaisiin periaatteessa välttää tunnetun 111493 g tekniikan mukaisella menettelyllä siten, että keskeytetään kompressointi joka kerta, kun dekompressorilta tulee kuittaus paluukanavalla, ja neuvoteltaisiin aina tällöin myötäkanavan kontekstitunnisteen pituus uudelleen. Tämä kuitenkin hidastaisi datavuon siirtoa niin pahoin, että käytännössä ROHC:n hyö-5 dyntäminen tulisi useissa sovelluksissa mahdottomaksi. Käytännössä ongelma pyrittäisiin ratkaisemaan keskeyttämällä kompressointi ja neuvottelemalla molempiin suuntiin 16-bittinen kontekstitunnistekenttä, joka johtaisi taas tie-donsiirtoresurssien epäoptimaaliseen hyödyntämiseen.

Nyt keksinnön mukaisesti edellä kuvatut ongelmat voidaan kuiten-10 kin välttää menettelyllä, jossa määritetään kontekstitunnisteen pituus datapaketin käsittämässä kontekstitunnistekentässä vasteena sille, että konteksti-tunnisteen pituus tulee muuttaa. Tämä voidaan edullisesti tehdä varaamalla kontekstitunnistekentästä yksi tai useampia bittejä ilmaisemaan datapaketin käsittämän kontekstitunnisteen pituus, joiden bittien perään varsinainen kon-15 tekstitunniste voidaan edullisesti liittää. Kontekstitunnisteen pituus voidaan siis määrittää edullisesti jokaisessa datapaketissa erikseen, jolloin datapaket-tivuon jokainen datapaketti, erityisesti niiden kontekstitunnistekenttä, käsittää pituuden määrittelevän informaation. Tällä menettelyllä, jossa jokaiseen datapakettiin, edullisesti niiden kontekstitunnistekentän ensimmäisiin bitteihin, liite-20 tään kontekstitunnisteen pituuden määrittelevä informaatio, varmistetaan uuden kontekstitunnisteen välittyminen vastaanottajalle. Vaihtoehtoisesti kontekstitunnisteen pituus voidaan myös määrittää edellä kuvatulla siten, että vain ensimmäinen välitettävä datapaketti kontekstitunnisteen pituuden uudelleenmäärittelyn jälkeen käsittää mainitun pituuden määrittelevän informaation, 25 mutta tämä ei ole yhtä luotettava tapa välittää uusi kontekstitunnisteen pituus dekompressorille.

Kontekstitunnisteen pituuden määrittämistä havainnollistetaan kuvion 4 mukaisella taulukolla, jossa on esimerkinomaisesti kuvattu keksinnön mukaisen kontekstitunnistekenttärakenteen käsittävä datapaketti. Datapaketin 30 alkuun on ROHC:n mukaisesti liitetty ensimmäiseksi tavuksi kontekstitunniste-, ·· kenttä (CID), jota seuraa datapaketin otsikkoinformaatiokenttä (PHI, Packet

Header Information) ja edelleen datapaketin hyötykuorman (Payload). Kontekstitunnistekenttä käsittää kuitenkin olennaisesti jokaisessa datapaketissa myös kentän, jossa määritetään kyseisen datapaketin kontekstitunnisteen pi-35 tuus (CIDJen). Kuvion 4 mukaisessa esimerkissä pituuden määrittelevän kentän pituus on kaksi bittiä, mutta se voi edullisesti vaihdella 1 - 8 bittiin.

10 111493

Kontekstitunnisteen pituuden ilmoittavan kentän informaation mukaisesti määräytyy siten kontekstitunnisteen pituus kyseessä olevalle datapaketille, jolloin seuraavan datapaketin käsittämä pituusinformaatio määrittää kontekstitunnisteen pituuden taas uudestaan kyseessä olevalle datapaketille. Itse konteksti-5 tunniste (CID) voi käsittää useita tavuja, myös tarvittaessa enemmän kuin kaksi.

Näin keksinnön mukaisella menettelyllä voidaan määrittää kontekstitunnisteen pituus erisuuriksi myötä- ja paluukanaville, minkä ansiosta tiedonsiirtoresurssien käyttöä voidaan tehostaa. Edelleen keksinnön mukaisel-10 la menettelyllä vältetään kompressoinnin ja dekompressoinnin pysäyttäminen ja kontekstitunnisteen pituuden uudelleen neuvotteleminen joka kerta, kun kontekstitunnisteen pituus tarvitsee muuttaa. Keksinnön mukainen menettely mahdollistaa myös eri kontekstitunnisteen pituuden omaavien datapakettien multipleksaamisen samalle tiedonsiirtoyhteydelle.

15 Edellä kuvattua menettelyä voidaan edullisesti soveltaa esimerkiksi ns. kolmannen sukupolven matkaviestinjärjestelmissä, joista käytetään ainakin nimityksiä UMTS (Universal Mobile Telecommunication System) ja IMT-2000 (International Mobile Telephone System), sekä myös ns. toisen sukupolven matkaviestinjärjestelmien jatkokehityshankkeissa, kuten GERAN:ssa (GSM 20 Edge Radio Access Network). Esimerkiksi UMTS-järjestelmän pakettidatapal-velussa eräs päätelaiteyhteyden määrittelevistä parametreista on päätelaitteen käyttämä datapakettien otsikkokenttien kompressointimenetelmä. Otsikkokenttien kompressointi lähetettäville datapaketeille ja dekompressointi vastaanotettaville datapaketeille suoritetaan UMTS-järjestelmässä pakettidatapro-: ‘ 25 tokollaan kuuluvalla konvergenssiprotokollakerroksella PDCP (Packet Data

Convergence Protocol). PDCP-kerroksen tehtäviin kuuluu mm. kanavatehok-kuuden parantamiseen liittyvät toiminnot, jotka perustuvat tyypillisesti erilaisiin optimointimenetelmiin, kuten datapakettien otsikkokenttien kompressointial-goritmien hyväksikäyttöön. Koska nykyisin UMTS:iin suunnitellut verkkotason 30 protokollat ovat IP-protokollia, ovat käytettävät kompressioalgoritmitkin IETF:n *; (Internet Engineering Task Force) standardoimia algoritmeja. Täten ROHC- kompressiomenetelmä sopii erityisen hyvin käytettäväksi juuri UMTS-järjestelmässä. Päätelaitteen PDCP-kerros tukee tyypillisesti useita otsikkokenttien kompressointimenetelmiä, jotta yhteydenmuodostus mahdollisimman 35 moneen verkkokerroksen protokollatyyppiin olisi mahdollista.

11 111493

Erityisesti UMTS-järjestelmän pakettidatapalvelussa käytettävissä sovelluksissa uplink- ja downlink-suuntaan siirrettävät datamäärät poikkeavat tyypillisesti huomattavasti toisistaan siten, että downlink-suuntaan siirretään huomattavasti enemmän dataa kuin uplink-suuntaan. Täten keksinnön mukai-5 sella järjestelyllä, jossa kontekstitunnisteen pituus voidaan määrittää downlink-suuntaan suuremmaksi kuin uplink-suuntaan, tehostetaan radiore-surssien käyttöä UMTS-järjestelmässä.

Alan ammattilaiselle on ilmeistä, että tekniikan kehittyessä keksinnön perusajatus voidaan toteuttaa monin eri tavoin. Keksintö ja sen suoritus-10 muodot eivät siten rajoitu yllä kuvattuihin esimerkkeihin vaan ne voivat vaihdella patenttivaatimusten puitteissa.

* 4

Claims (10)

111493

1. Menetelmä kontekstitunnisteen määrittämiseksi datapakettien otsikkokenttien kompressoinnissa, jossa menetelmässä määritetään datapa-kettivuon kompressorille ja dekompressorille konteksti, jolla ohjataan mainittu- 5 jen kompressorin ja dekompressorin toimintaa, identifioidaan mainittu konteksti datapakettiin liitettävällä kontekstitunnisteella ja määritetään mainitun kontekstitunnisteen pituus kompressorin ja dekompressorin välisellä tiedonsiirrolla, tunnettu siitä, että määritetään mainitun kontekstitunnisteen pituus lähetettävän data- 10 paketin kontekstitunnisteessa.

2. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että mainittu kontekstitunniste käsittää ainakin yhden bitin käsittävän kentän kontekstitunnisteen pituuden määrittämiseksi.

3. Patenttivaatimuksen 1 tai 2 mukainen menetelmä, tunnettu siitä, että määritetään mainitun kontekstitunnisteen pituus jokaisessa lähetettävässä datapaketin kontekstitunnisteessa.

4. Patenttivaatimuksen 1 tai 2 mukainen menetelmä, tunnettu 20 siitä, että määritetään mainitun kontekstitunnisteen pituus vain ensimmäiseksi lähetettävän datapaketin kontekstitunnisteessa.

5. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että 25 määritetään kompressorilta dekompressorille siirrettävälle datapa- kettivuon kontekstitunnisteelle eri suuri pituus kuin dekompressorilta kompressorille siirrettävälle datapakettivuon kontekstitunnisteelle.

6. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että v 30 suoritetaan mainittu otsikkokenttien kompressointi ROHC- i määrittelyn mukaisesti.

7. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että suoritetaan mainittu otsikkokenttien kompressointi matkaviestinjär- 35 jestelmän, kuten UMTS-järjestelmän, radiorajapinnalla. 11149.3

8. Kompressointijärjestelmä datapakettien otsikkokenttien kompres-soimiseksi, joka järjestelmä käsittää kompressorin lähetettävän datapaketti-vuon kompressoimiseksi ja dekompressorin vastaanotettavan datapakettivuon dekompressoimiseksi, joille datapakettivuon kompressorille ja dekompressoril- 5 le on järjestetty määritettäväksi konteksti, jolla ohjataan mainittujen kompressorin ja dekompressorin toimintaa, mainittu konteksti on järjestetty identifioitavaksi datapakettiin liitettävällä kontekstitunnisteella ja mainitun kontekstitun-nisteen pituus on järjestetty määritettäväksi kompressorin ja dekompressorin välisellä tiedonsiirrolla, tunnettu siitä, että 10 mainitun kontekstitunnisteen pituus on järjestetty määritettäväksi lähetettävän datapaketin kontekstitunnisteessa.

9. Patenttivaatimuksen 8 mukainen järjestelmä, tunnettu siitä, että mainittu kontekstitunniste käsittää ainakin yhden bitin käsittävän 15 kentän kontekstitunnisteen pituuden määrittämiseksi.

10. Patenttivaatimuksen 8 tai 9 mukainen järjestelmä, tunnettu siitä, että mainitun kontekstitunnisteen pituus on järjestetty määritettäväksi jokaisen lähetettävän datapaketin kontekstitunnisteessa. 1 « 111493