FI108601B

FI108601B - QoS-kartoitustiedon välitys pakettiradioverkossa

Info

Publication number: FI108601B
Application number: FI991177A
Authority: FI
Inventors: Juha Kalliokulju; Matti Turunen; Mikko Puuskari; Jan Suumaeki; Tuija Hurtta; Tero Maekelae
Original assignee: Nokia Corp
Priority date: 1999-01-05
Filing date: 1999-05-24
Publication date: 2002-02-15
Also published as: ATE243901T1; FI991177L; US7167447B2; DE60003525T2; FI991177A0; CN1336061A; CN1263268C; DE60003525D1; US20060126547A1; US20020032800A1; EP1151586B1; ES2202041T3; WO2000041401A2; EP1151586A2; JP2002534923A; JP3625769B2; WO2000041401A3; CA2358194C; CA2358194A1; AU2112400A

Description

• ϋ 8 6 01

QoS-kartoitustiedon välitys pakettiradioverkossa Keksinnön tausta

Keksintö liittyy menetelmiin ja järjestelmiin palveluluokan (Quality of Service, QoS) ohjaamiseksi matkaviestinjärjestelmissä, jotka kykenevät siirtä-5 mään pakettidataa. Erityisesti keksintö liittyy datapakettien lähettämiseen QoS -kartoitustiedon perusteella ja QoS -kartoitustiedon kuljettamiseen tällaisen matkaviestinjärjestelmän eri solmujen välillä.

GPRS:n vaiheessa 2 ja UMTS-järjestelmää varten tarvitaan laajempaa QoS -tukea. Tähän tarkoitukseen verkon reunaelementeissä, kuten MS ja 10 GGSN, on ylläpidettävä QoS:ään liittyvää informaatiota.

Tällä hetkellä ei ole mahdollista muuntaa QoS-kartoituksen suorittamiseen ja muunnostoimintojen suorittamiseen tarvittavaa informaatiota ulkoisen verkon QoS-mekanismien ja matkaviestinverkkokohtaisten QoS-meka-nismien välillä. Tämä tarkoittaa, että matkaviestinverkon reunasolmut voivat 15 suorittaa vain hyvin staattisia QoS-muunnoksia. Eri QoS-arvojen tuottamiseksi eri sovelluksille (kuten tosiaikainen tai ei-tosiaikainen multimedia, tiedostojen siirto, sähköpostin taustasiirto jne.) matkaviestimessä (MS) ja GGSN-solmuissa tarvitaan välineitä yhdenmukaisen informaation ylläpitämiseksi.

GPRS/UMTS-verkkoihin ei tunneta ratkaisua tähän ongelmaan. In-20 ternetiä varten on olemassa mekanismeja, joita voidaan käyttää kuljettamaan QoS- tai vuokohtaista informaatiota. Kuitenkin tätä informaatiota tulkitaan jo-kaisessa solmussa päästä-päähän -siirtotiellä, eikä vain päätepisteissä (MS ja :·. GGSN).

Keksinnön lyhyt selostus 25 Keksinnön tavoitteena on siten tuottaa mekanismi dynaamisemman • · · ’ QoS:n tuottamiseksi eri sovelluksille. Tämä tavoite saavutetaan menetelmällä v ; ja laitteistolla, joille on tunnusomaista se, mitä sanotaan itsenäisissä patenttivaatimuksissa. Keksinnön edulliset suoritusmuodot ovat epäitsenäisten pa-·:·: tenttivaatimusten kohteena.

·"*: 30 Keksintö perustuu näkemykseen, että QoS-kartoitustietoa on siirret- . tävä GPRS/UMTS -verkon reunojen välillä. Toisin sanoen keksintö tuottaa me kanismin usean alasuuntaisen, erilaiset QoS-tarpeet omaavan IP-vuon (IPvuOl ... IPvuoJ kartoittamiseksi GPRS- tai UMTS-voihin. Viime mainitut vuot määräytyvät PDP-kontekstien (PDP1 ... PDPm) tai QoS-profiilien 35 (QoS1 ... QoSm) perusteella yhden, tarpeet täyttävän profiilin puitteissa. Pe- » · ! 2 108601 rusajatus on, että ainakin joillekin datavoille (esim. tosiaikaisille sovelluksille) reunasolmussa (ts. GGSN) suoritettava kartoitus perustuu suotimeen, joka on konfiguroitavissa (valitsemalla tai muokkaamalla) käyttäjältä/päätteeltä. Tällainen suodin voidaan toteuttaa joukkona ennalta määrättyjä parametreja ja/tai 5 ehtoja, joita käytetään identifioimaan paketteja tai datavoita. Tietyn suotimen matkaviestimelle tulisi käsittää ainakin kyseisen matkaviestimen IP-osoite. matkaviestimen IP osoite tunnetaan PDP-kontekstitietueesta, eikä sitä tarvitse lähettää suodinmäärittelyissä matkaviestimen ja GGSN:n välillä. (Joissakin erikoistapauksissa matkaviestimellä voi olla enemmän kuin yksi IP-osoite.) Li-10 säksi suodin voi käsittää mitä tahansa dataa, jota voidaan käyttää identifioimaan tiettyä palveluluokkaa vaativia datapaketteja, ja jotka sen vuoksi tulisi multipleksoida tietyille PDP-konteksteille, kuten lähdeosoite (Source Address), RSVP vuotunnus (Flow Identifier), porttinumero (esim. käytetty TCP- tai UDP porttinumero), ylemmän kerroksen protokolla (esim. UDP, RTP, jne.), palvelun 15 tyyppi (Type of Service, IPv4), yhteystyyppi (Connection Type, IPv6) ja/tai lii-kenneluokkakenttä (Traffic Class field, IPv6). Suodin voi käsittää myös IP-osoiteavaruuden antamaan yrityksen verkosta (ts. intranet) tuleville paketeille korkeamman palveluluokan kuin yleisestä Internetistä tuleville paketeille.

Keksinnön mukaista suodinta käytetään määrittelemään niiden IP-20 voiden ominaisuudet, jotka on kartoitettava kyseiseen GPRS- tai UMTS-vuohon. Pääte voi ohjata suodinta identifioimalla suodinparametrit informaatioelementtiin, joka voidaan sisällyttää esim. PDP-kontekstin aktivointi- tai . PDP-kontekstin muutossanomiin. Suodin voidaan myös määritellä/määritellä :'·.. uudelleen QoS-profiilin aktivoinnin tai muutoksen yhteydessä.

:··: 25 Keksinnön edullisen suoritusmuodon mukaan määritellään QoS- oletusluokka. Tähän QoS-oletusluokkaan kartoitetaan vuot, jotka eivät vastaa mitään määriteltyä suodinta.

Keksinnöllä ratkaistava ongelma on relevantti GPRS:n vaiheessa 2 ja sen jatkokehityksessä, kuten UMTS.

30 Erään suoritusmuodon mukaan profiilin/kontekstin QoS-informaatio '111» sisällytetään QoS-profiili-informaatioelementtiin, kuten GPRS:n vaiheessa 1. Kartoitus- ja suodatusinformaatio voidaan siirtää protokollan konfigurointi-•: · · vaihtoehtojen informaatioelementissä, toimittajakohtaisissa optioissa tai tähän ·...: tarkoitukseen esitellyssä ja omistetussa uudessa informaatioelementissä. Tä- 35 mä informaatio voi sisältää lähde- ja/tai kohde-IP-osoitteita, käytettyjä TCP- ja ·’ " UDP-porttinumeroita, ylemmän kerroksen protokollainformaatiota, mahdolli- i U 8 6 G1 3 sesti Secure Parameters Index (mikäli IPSEC on käytössä), differentia-ted-palvelun (differentiated services) parametrit ja RSVP-suotimien ja voiden määrityksiä tai muita paketeissa olevia tunnisteita tai parametreja.

! Kullekin PDP-osoitteelle voidaan pyytää erilaista palveluluokka- 5 (QoS-) profiili. Esimerkiksi jotkut PDP-osoitteet voivat liittyä sähköpostiin, joka voi sietää pitkähköjä vasteaikoja. Toiset sovellukset, eräänä esimerkkinä vuorovaikutteiset sovellukset, eivät siedä viiveitä ja vaativat hyvin suurta läpäisy-kykyä. Nämä erilaiset vaatimukset heijastuvat QoS-profiilissa. Jos QoS-vaatimus ylittää PLMN:n kyvyt, PLMN neuvottelee QoS-profiilin mahdollisim-10 man lähelle pyydettyä QoS-profiilia. Matkaviestin joko hyväksyy neuvotellun QoS-profiilin tai deaktivoi PDP-kontekstin.

Keksinnön eräänä etuna on, että pakettiradioverkon verkkoelementtien (kuten SGSN-solmujen ja tukiasemajärjestelmän) ei tarvitse tulkita kaikkia ulkoisen verkon (IP, X.25 jne.) QoS-mekanismeja. Sen sijaan kartoitus 15 voidaan konfiguroida matkaviestimen päässä ja tämä konfigurointi kuljetetaan pakettiradioverkon toiseen reunasolmuun (siis GGSN:ään). Kaikkien uusien QoS-mekanismien tukemiseksi ei siis tarvitse päivittää koko pakettiradioverk-koa.

Keksinnön mukainen mekanismi on hyvin yleispätevä. Toisin sa-20 noen se on sovellettavissa hyvin moninaisiin tilanteisiin ja konfiguraatiohin. Se sallii joustavan pääsyn GGSN:n tietokannassa olevaan suodininformaatioon sekä sen joustavan konfiguroinnin ja käytön. Keksinnön mukaisen suotimen i *·. käyttö on täysin tapaus- ja operaattorikohtaista. Matkaviestimen tilaajalle tar-jotaan välineet osoittamaan matkaviestin- ja kiinteän verkon rajalla olevalle 25 yhdyskäytäväsolmulle, kuinka eri sovelluksia, yhteyksiä, voita tai muita attri-buutteja tulisi käsitellä, ja mitä palveluluokkaa tulisi käyttää GPRS/UMTS-verkon puitteissa kyseisten pakettien kuljettamiseen. GGSN:n tulisi mieluiten

» t I

myös ylläpitää sovellus-, palveluluokka- ja vuokohtaista informaatiota.

* * Vielä eräs etu on, että QoS-profiilin tai PDP-kontekstin perustamis- 30 proseduurissa siirretty vuo/palveluluokkakohtainen määritys voi olla hyvin ’ ' joustava. Se voi sisältää lähde- ja kohde-IP-osoitteita, käytettyjä TCP- ja UDP- • · · porttinumerolta, ylemmän kerroksen protokollainformaatiota, mahdollisesti Se-cure Parameters Index (mikäli IPSEC on käytössä), differentioidun palvelun (differentiated services) parametrit ja RSVP-suotimien ja voiden määrityksiä, • » 35 joita kaikkia käytetään identifioimaan ulkoisia sovelluksia, käyttöjä ja voita, jot- » » ·' " ka tulisi kartoittaa tiettyihin sisäisiin QoS-luokkiin tai konteksteihin.

• t » I > * · · ] 4 1 ϋ 8 6 ϋ 1

Vaihtoehtoisesti informaatio voitaisiin konfiguroida staattisemmin, missä tapauksessa attribuuttien dynaaminen vaihtaminen ei ole mahdollista. Tässä tapauksessa operaattori konfiguroi staattiset olosuhteet ja ulkoisen QoS:n muuntamisen sisäiseksi QoS:ksi, perustuen esimerkiksi käytettyihin 5 TCP/UDP -porttinumeroihin. Vielä eräs mahdollisuus on olla lainkaan tuottamatta mitään QoS-kartoitustoimintoja ja päästä-päähän -palveluluokkaa.

Kuvioiden lyhyt selostus

Keksintöä selostetaan nyt lähemmin edullisten suoritusmuotojen yhteydessä, viitaten oheisiin piirroksiin, joista: 10 Kuvio 1 esittää tunnetun GPRS-verkon arkkitehtuuria;

Kuvio 2 esittää tunnettua GPRS-lähetystasoa;

Kuvio 3 esittää eri verkkoelementtien välistä vuorovaikutusta;

Kuvio 4 esittää GGSN-solmua, joka sisältää keksinnön mukaisen suotimen; 15 Kuvio 5 esittää keksinnön mukaisen suotimen käyttöä;

Kuviot 6 ja 7 esittävät suodininformaation kuljettamista vastaavasti kontekstin aktivointi- tai modifiointiproseduureissa; ja

Kuviot 8 ja 9 esittävät kaksi erilaista toteutusta suodininformaation konfiguroimiseksi erillisessä (dedikoidussa) sanomassa.

20 Keksinnön yksityiskohtainen selostus ·. Kuten kuvioissa 1 ja 2 näytetään, keksintöä voidaan soveltaa missä j. ( tahansa matkaviestinjärjestelmässä jolla on kyky siirtää pakettidataa.

‘ Tässä käytettyjen termien ‘pakettidataprotokolla’ (Packet Data Pro tocol, PDP) tai ‘PDP konteksti’ tulisi ymmärtää viittaavan yleisesti johonkin ti- ‘ ' 25 laan matkaviestimessä ja ainakin yhteen verkkoelementtiin tai toiminnallisuu- v ** teen, joka tila tuottaa matkaviestinverkon kautta datapaketin siirtotien eli tun- v * nelin, jolla on määrätty joukko parametreja. Tässä käytetyn termin ‘solmu’ tulisi ymmärtää viittaavan yleisesti johonkin verkkoelementtiin tai toiminnallisuuteen, •: * *: joka käsittelee PDP-kanavan kautta siirrettyjä datapaketteja.

·"·. 30 Keksintö on erityisesti sopivasti käytettävissä tuottamaan yleinen «» · • , pakettiradiopalvelu GPRS yleiseurooppalaisessa digitaalisessa matkaviestin- » »· * järjestelmässä GSM tai vastaavissa matkaviestinjärjestelmissä kuten ' ’ DCS1800 (tunnetaan myös nimellä GSM 1800) sekä PCS (Personal Commu- nication System). Seuraavassa keksinnön edullisia suoritusmuotoja seloste- | 35 taan liittyen GPRS-pakettiradioverkkoon, jonka muodostavat GPRS-palvelu ja * * ! 0 8 6 01 5 GSM-järjestelmä, rajoittamatta keksintöä tähän nimenomaiseen pakettiradio-järjestelmään.

Keksintö on yhtä hyvin sovellettavissa niin kutsuttuihin kolmannen sukupolven matkaviestinverkkoihin, kuten UMTS. Tässä tapauksessa GSM:n 5 radiorajapinta korvataan UMTS-radiorajapinnalla, kuten kuviossa 2 näytetään.

Kuvio 3 esittää eri verkkoelementtien välistä vuorovaikutusta. Näiden muutosten jälkeen differentioidun palvelun ja RSVP:n välinen parametrita-son kartoitus Internetissä ja GPRS:ssä voidaan toteuttaa esim. seuraavasti:

Internetin prioriteetti-informaatio kartoitetaan GPRS:n palveluetuoi-10 keudeksi (service precedence). Tosiaikaisuuden vaatimusta (on/ei) koskeva osoitus Internetissä kartoitetaan GPRS:ssä viiveluokaksi (delay class) ja/tai luotettavuusinformaatioksi (reliability information): tarvitaan ainakin kaksi vii-vetyyppiä, mutta on myös mahdollista kartoittaa liikennetyypit tarkemminkin useaan viiveluokkaan.

15 Luotettavuusinformaatiota voidaan käyttää osoittamaan kunkin so velluksen luotettavuusvaatimus yhtenä ainakin kahdesta luotettavuusluokasta. Luotettavaa lähetystä (uudelleenlähetyksiä, tarkistussummia ja/tai TCP) tarvittaessa datapaketteihin liittyvä profiili osoittaa luotettavuusluokkaa 1. Jos tarvitaan luotettavaa lähetystä radiorajapinnan yli, mutta UDP riittää GPRS:n 20 runkoverkossa, datapaketteihin liittyvä profiili osoittaa luotettavuusluokkaa 2. Vaatimuksista riippuen datapaketteihin liittyvä profiili voi osoittaa vaihtoehtoisesti luotettavuusluokkaa 3, 4 tai 5. Luotettavuusluokkia 4 ja 5 käytetään tosi-aikaiselle liikenteelle.

! ’ . Keksinnön eräs lisäpiirre voi olla matkaviestinverkossa käytettyjen 25 QoS -parametrien kartoitus pakettimatkaviestimen käyttäjäsovelluksessa tai ulkoisessa tietoliikennejärjestelmässä käytettyihin parametreihin, tai päinvas-: toin. Matkaviestin, joka tuntee sovelluksen vaatimukset, määrittää vastaavat * « *

QoS -profiiliarvot, perustaa uuden PDP-kontekstin näille paketeille ja osoittaa GGSN:lle, kuinka tähän kontekstiin kuuluvat paketit tunnistetaan. Seuraavassa 30 annetaan kaksi kartoitusesimerkkiä.

Esimerkki 1 (annetaan esimerkkinä siitä, kuinka matkaviestin voi ’ . päättää kontekstille valitsemansa GPRS-parametriarvot).

Simple Integrated Media Access (SIMA) on uusi yksinkertainen lähestymistapa, jonka on esittänyt Internet-draft -muodossa K. Kilkki, Nokia Tut-35 kimuskeskus, kesäkuussa 1997. Internet-draftit ovat IETF:n (Internet Engi- :**.· neering Task Force), sen alueiden ja työryhmien työdokumentteja. SIMA:a • » ! 08601 6 käytetään esimerkkinä Internetin QoS-kaaviosta, koska se kykenee tarjoa-! maan tasaisen palvelukonseptin erilaisiin tarpeisiin alkaen TCP/IP:tä käyttä vistä tiedostonsiirtosovelluksista ilman löysiä viive- ja paketinkadottamisvaati-muksia ja päättyen tosiaikaisiin sovelluksiin, joilla on hyvin ankarat laatu- ja 5 käytettävyysvaatimukset. SIMA-konseptin mukaan kunkin käyttäjän tulee määritellä vain kaksi asiaa ennen yhteyden muodostamista: nimellinen bittinopeus (nominal bit rate, NBR) sekä valinta tosiaikaisten tai ei-tosiaikaisten palveluluokkien välillä. NBR voi saada kahdeksa arvoa välillä 0 - 7. Parametrien kartoitus SIMA:sta GPRS:ään ja päinvastoin voi tapahtua esim. seuraavasti: 10 Tosiaikainen/ei-tosiaikainen bitti: tämän bitin osoittaessa tosiaikai suuden vaatimusta se kartoitetaan GPRS:n viiveluokkaan 1, muuten se kartoitetaan viiveluokkaan 4. Viiveluokkaa 3 voidaan kuitenkin käyttää ei-tosiaikaisiin palveluihin siinä tapauksessa, että on olemassa erityinen tapa osoittaa parhaan yrityksen (best-effort) liikenne, esim. tämän bitin ei tarvitse 15 olla aina läsnä, tai käytetään tarkempaa määrittelyä erottamaan tosiaikainen, ei-tosiaikainen ja parhaan yrityksen liikenne. Tosiaikaiselle liikenteelle voidaan osoittaa alhaisempi luotettavuusluokan arvo kuin ei-tosiaikaiselle liikenteelle GPRS:ssä. Luotettavuusluokkia 1, 2 ja 3 käytetään yleensä ei-tosiaikaiselle liikenteelle ja luokkia 3, 4, ja 5 tosiaikaiselle liikenteelle GPRS:ssä. Ei-20 tosiaikaiselle liikenteelle, mitä korkeampi on NBR, sitä alhaisempi luotetta-vuusluokka on sopiva lähetykselle.

:·, _NBR arvot__GPRS palveluetuoikeusarvo | ’..’I _6ja 7__1_ ! ..... _3, 4, ja 5__2_ = _0,1, ja 2__3_

• I I

· Parametreille voidaan valita eri nimiä, kuten prioriteetti tai nimellinen bittinopeus ja liikennetyyppi. QoS-profiilin tulee sisältää kaikki olemassaolevat ·:··· 25 parametrit (palveluetuoikeus, luotettavuusluokka, viiveluokka, keskimääräinen • bittinopeus ja huippubittinopeus). Vaihtoehtoisesti se voi sisältää vain joitakin parametreja, kuten keskimääräinen bittinopeus ja huippubittinopeus. QoS-profiili voi sisältää myös maksimaalisen purskekoon parametrin puskurin allo-' : kointiproseduurin helpottamiseksi.

30 QoS -ajoittaminen (scheduling) GPRS:n verkkoelementeissä (esim.

: SGSN ja GGSN) perustuu viiveluokkaan. Tämä voi vaatia ainakin kahta pus- j 1 O 8 6 ϋ 1 7 kuria: yksi tosiaikaisille paketeille (tämän puskurin tulisi olla paljon pienempi!) ja yksi ei-tosiaikaisille paketeille. Tosiaikainen liikenne tulisi aina lähettää en-! nen ei-tosiaikaista liikennettä. Palveluetuoikeus määrittää järjestyksen, jossa paketteja voidaan pudottaa verkon eston tapauksessa.

5 Esimerkki 2 (selostaa, kuinka valitaan QoS -arvot ja muodostetaan erityinen profiili tukemaan tiettyä differentioidun palvelun koodipistettä, tuottamaan oikeat QoS -profiiliarvot ja differentioidun palvelun koodipistearvo suodi-ninformaationa suotimen konfiguroimiseksi.) IP-PDU -yksiköiden otsakkeiden palvelutyyppi (Type of Service, 10 ToS) -oktetin kartoitus. IP-otsakkeen ToS-oktettia ei tällä hetkellä käytetä laajalti. Sen alkuperäinen tarkoitus oli sisältää liikennetyyppi-informaatiota ja määrittää, minkälaista palvelua paketin toimitukselta vaaditaan. Koska ToS-oktetti ei nykyään ole yleisessä käytössä, on mahdollista määritellä uudelleen tämän oktetin bitit keksinnön tarpeisiin. ToS-oktetin määritelmä esitetään RFC 15 791:ssä. ToS:n bitit 0-2 osoittavat etuoikeuden (preference), bitit 3 - 5 osoit tavat paketin vaatiman ToS:n (esim. pyydetyt viive-, välityskyky- ja luotetta-vuustasot), ja bitit 6 - 7 on varattu tulevaan käyttöön. RFC 1349 laajentaa ToS-kenttää yhdellä bitillä (joka on otettu tulevaan käyttöön varatuista biteistä). Neljää bittiä voidaan siis käyttää osoittamaan ToS:ää.

20 Etuoikeusbittien (ToS bitit 0 - 2) ja GPRS:n palveluetuoikeuden vä linen kartoitus voi olla seuraava: :·. bittiarvot (0-2) palveluetuoikeusarvo • < · ~ I I I ! —............ ...

111 ja 110 001 (korkein prioriteetti) ,,, (; _101, 100 ja 011__010 (normaali prioriteetti) 010, 001 ja 000__011 (matalin prioriteetti)

On kolme eri tapaa suorittaa kartoitus liikennetyyppi-informaation (siis ToS-oktetin ToS-kentän) ja GPRS:n viiveluokan välillä: ·:·; 25 Jos IP-otsakkeessa käytetään vain ToS-kentän bittiä 3 osoittamaan viivevaatimuksia: bitin 2 arvo 0 kartoitetaan GPRS:n viiveluokaksi 1 tai 2, ja bitin 2 arvo 1 kartoitetaan GPRS:n viiveluokaksi 4 (paras yritys).

Jos ToS:n koko ToS-kenttää käytetään osoittamaan viivevaatimuksia, eli tähän tarkoitukseen on käytettävissä 4 bittiä (bitit 3 - 6), eräs mahdolli-30 nen kartoitus voisi olla: bittiarvo 1000 kartoitetaan GPRS:n viiveluokaksi 1 (eli : ’ ; bittiarvoksi 000); bittiarvo 0100 kartoitetaan GPRS:n viiveluokaksi 2 (eli arvoksi i ! 0 8 6 G1 8 001), ToS-arvot 0010 ja 0001 GPRS:n viiveluokaksi 3 (eli arvoksi 010) ja ToS-arvot 0000 GPRS:n viiveluokaksi 4 (eli arvoksi 011).

Toinen tapa kartoittaa !P:n ToS bitit GPRS:n viiveluokiksi olisi: 11x viiveluokaksi 1, 10x viiveluokaksi 2, 01x viiveluokaksi 3, ja OOx viiveluokaksi 4.

5 Tässä tapauksessa x tarkoittaa, että ToS:lle voidaan käyttää yhtä tai useampaa lisäbittiä, mutta niillä ei ole vaikutusta GPRS:n viiveluokan valintaprosessiin. Jos GPRS:lle määritellään myöhemmin lisää viiveluokkia, kartoitus voisi ottaa huomioon myös nämä lisäbitit.

Tällä hetkellä IP:n ToS-kentässä on myös yksi bitti, joka määrittelee 10 halutun luotettavuustason. Jos tämä bitti on käytettävissä myös tulevaisuudessa, esimerkiksi jos valitaan ylläolevista vaihtoehdoista ensimmäinen, tämä bitti voisi kuljettaa luotettavuusinformaatiota ja se voitaisiin kartoittaa GPRS:n luotettavuusluokaksi seuraavasti: ToS-oktetissa olevan bitin 5 arvo 0 kartoitetaan luotettavuusluokaksi 000 (tilattu luotettavuusluokka) ja arvo 1 kartoitetaan 15 luotettavuusluokaksi 001 (joka määrittelee luotettavimman palvelun). Tämän bitin käyttö voi kuitenkin olla liian epämääräistä, koska GPRS määrittelee myös useita muitakin luotettavuustasoja, eikä tätä voida ilmaista käyttämällä vain yhtä bittiä.

Keksinnön edullisen suoritusmuodon mukaan määritellään QoS-20 luokan oletusarvo, ja ne datavuot, jotka eivät vastaa minkään suoti-men/suotimien kartoitusehtoja, kartoitetaan QoS-oletusluokkaan.

·. Yllä, esimerkissä 2 selostettua kartoitusta voidaan soveltaa lähes samalla tavalla IPv6:n yhteydessä. Sopivan kentän nimi on silloin liikenneluok-| . ka (Traffic Class) ToS:n sijasta.

| . 25 Kuvio 3 esittää GPRS-matkaviestimen ja GPRS:n verkkoelementti- ! ' en toimintaa sekä integrointia ulkoisten QoS-konseptien välillä, matkaviestin i , * ' * '·’ : tai päätelaitteen TE (esim. salkkutietokoneen) ohjelmisto kartoittaa ulkoiset v : QoS-vaatimukset GPRS:n QoS-mekanismeihin. TE voisi esimerkiksi toteuttaa

QoS-hallintatoimintoja sovellusrajapinnan (Application Programming Interface, :··: 30 API) kautta. Sovellustason ohjelmisto voi lisätä datapaketteihin, esim. itse IP- otsakkeeseen QoS-informaatiota tai profiilimerkin, tai se voi osoittaa oikean vuon, johon paketti kuuluu, käyttämällä jotakin muuta sopivaa välinettä. Se voi myös käyttää RSVP:tä kuljettamaan tarpeellista informaatiota sopivien kartoi-tuskerrosten kautta alemmille kerroksille. Vaihtoehtoisesti matkaviestimen oh-35 jelmisto voi päättää QoS-profiilin perustuen esim. käytettyihin lähde- ja kohde- ί '! O H 6 U 1 ! 9 IP-osoitteisiin tai lähde- ja kohdeporttinumeroihin tai johonkin muuhun matkaviestimelle konfiguroituun informaatioon.

Matkaviestimeltä lähtevän (Mobile Originated, MO) datan yhteydes- i ! sä matkaviestin ajoittaa datapaketit perustuen informaatioon, joka vastaan- 5 otetaan sovellukselta tai päätelaitteen protokollasarjalta. Matkaviestin ajoittaa MO-paketit niiden viiveluokan mukaisesti. SNDC-kerroksella matkaviestin valitsee sopivan LLC SAP-pisteen (Service Access Point), jonka SGSN osoittaa PDP-kontekstin aktivoinnin tai muutoksen yhteydessä.

Kuvio 4 esittää GGSN-solmua, joka käsittää keksinnön mukaisen 10 suotimen. GGSN vastaanottaa matkaviestimelle päättyviä datapaketteja useasta lähteestä, joista käytetään yhteistä nimitystä palvelun tuottaja SP (Service Provider). Kuviossa 4 esitetään kolme tyypillistä palvelun tuottajaa: Internet-palveluntuottaja ISP (Internet Service Provider) pääsyn tuottamiseksi Internetiin, yhtiön verkkopalvelin CNS (Company Network Server) pääsyn tuottami-15 seksi Internetin suljetuille alueille, joista käytetään yleisesti nimitystä intranet ja extranet; sekä sisällöntuottajia CP (Content Providers) pääsyn tuottamiseksi erilaisiin viihde-ja uutispalveluihin kuten tilausvideo jne.

GGSN käsittää ajoitin/muuntimen ST (scheduler/translator). Kuten sen nimestäkin voi päätellä, se ajoittaa pakettien lähetystä verkon kuormituk-20 sen, pakettien prioriteetin, saapumisajan jne. perusteella. ST:n ajoitusosa on ammattilaiselle pääosin tunnettu.

·. ST:n muunninosa käyttää hyväkseen keksinnön mukaista suodinta :·. Fl. Se kartoittaa datapaketteja IP-verkoista (11 - 12 kuviossa 1) pakettiradio- ! verkkoon (13 kuviossa 1). Keksintö tarjoaa ratkaisun tilanteeseen, jossa useat | . 25 sovellukset ja datavuot jakavat yhteisen IP-osoitteen, mutta vaativat erilaisia

QoS-arvoja.

Kuvio 5 esittää keksinnön mukaisen suotimen Fl käyttöä GGSN-

V ; solmussa. Vaiheessa 71 GGSN vastaanottaa tietylle matkaviestimelle MS

osoitetun datapaketin. GGSN lukee matkaviestimen IP-osoitteen vastaavasta ·:*: 30 protokollaotsakkeesta ja käyttää suodinta Fl määrittääkseen vastaavan PDP- kontekstin tai QoS-profiilin. Matkaviestimen IMSI voidaan määrittää pakettien >()t. kohde-IP-osoitteista. Vaiheessa 72 GGSN saa vastaavan tunnelitunnuksen TID (Tunnel Identifier). Seuraavaksi, vaiheessa 73 GGSN lähettää datapaketin ’ SGSN:n kautta matkaviestimelle sen nimenomaisen kontekstin kautta, joka j 1.. 35 liittyy tätä pakettia vastaavaan QoS:ään.

» » 10 1 U 8 6 0 1

Kuvio 6 näyttää, kuinka matkaviestin voi konfiguroida QoS-kartoitus- ja vuorovaikutustoimintoja keksinnön mukaisen kontekstinaktivointi-proseduurin avulla. Vaiheessa 6-1 matkaviestin lähettää SGSN:lle PDP-kontekstin aktivointipyynnön, johon kuuluu NSAPI, PDP-tyyppi, PDP-osoite, 5 pääsypisteen nimi, pyydetty QoS, suodinmäärittely ja PDP-konfigurointi-optioita. (Keksinnön ymmärtämisen kannalta tärkeitä parametreja ovat suodin-ja QoS-informaatio.) Matkaviestin voi käyttää PDP-osoitetta osoittamaan, vaatiiko se staattisen vai dynaamisen PDP-osoitteen käyttöä. Viime mainitussa tapauksessa matkaviestin jättää PDP-osoitteen tyhjäksi. Matkaviestin voi 10 käyttää pääsypisteen nimeä valitsemaan viitepiste (reference point) tiettyyn ulkoiseen verkkoon. Pääsypisteen nimi on looginen nimi, joka viittaa siihen ulkoiseen pakettidataverkkoon, johon tilaaja haluaa kytkeytyä. Pyydetty QoS osoittaa halutun QoS-profiilin. Suodinmäärittely osoittaa, mitkä ulkoiset datapaketit liittyvät tiettyyn PDP-kontekstiin. Tämän suotimen suodinehtojen 15 osoittamat paketit tulisi tulkita kuuluviksi tähän nimenomaiseen PDP-kontekstiin. PDP-konfigurointioptioita voidaan käyttää pyytämään valinnaisia PDP-parametreja GGSN:ltä (ks. GSM 09.60). PDP-konfigurointioptiot lähetetään läpinäkyvästi SGSN:n kautta.

Dynaamisen konfiguroinnin ja dynaamisten PDP-osoitteiden käyt-20 täminen aiheuttaa ongelman, kuinka varmistetaan, että kontekstin aktivointi vaikuttaa oikeaan GGSN:ään ja kuinka GGSN tietää, onko sen aktivoitava uu-·. si konteksti samalla IP-osoitteella vai eri osoitteella. Tälle ongelmalle voidaan :·. löytää kolme ratkaisua: . 1. Käytetään pääsypisteen nimeä, joka osoittaa tiettyä GGSN- , 25 solmua ja osoittaa, että tarvitaan toinen konteksti, ja käytetään samaa IP- osoitetta.

> t > ’ 2. Käytetään kontekstin aktivointipyyntöön osoitusta (esim. uutta v · informaatioelementtiä), joka osoittaa GGSN:lle (ja SGSN:lle), että tarvitaan toinen konteksti. Tällä kontekstilla on sama IP-osoite kuin edellisellä. Tässä "*: 30 tapauksessa SGSN valitsee saman GGSN:n kuin edelliselle tätä PDP-tyyppiä •' ’': olevalle kontekstille.

3. Lisätään kontekstille halutut PDP- ja IP-osoitteet kontekstin akti-vointipyyntösanomaan. Tämä PDP/IP -osoite voidaan antaa jollekin edelliselle I ‘ , t kontekstille, siis dynaaminen osoite. Tässä tapauksessa SGSN valitsee sen ; ·.. 35 GGSN:n, joka käsittelee juuri tätä osoitetta.

I 1086G1 11 I Vaiheessa 6-2 voidaan toteuttaa turvallisuustoimintoja, mutta ne ei- i vät ole relevantteja keksinnön ymmärtämisen kannalta.

| Vaiheessa 6-3 SGSN vahvistaa pyynnön 6-1. SGSN luo tunnelitun- ! nisteen TID pyydetylle PDP-kontekstille yhdistämällä MM-kontekstiin tallen- 5 netun IMSI:n matkaviestimeltä vastaanotettuun NSAPkin. SGSN voi rajoittaa pyydettyjä QoS-attribuutteja ottaen huomioon kykynsä, vallitsevan kuormituksen ja tilatun QoS-profiilin. Seuraavaksi, vaiheessa 6-3 SGSN lähettää GGSN:lle PDP-kontekstin luontipyynnön (Create PDP Context Request, johon kuuluu PDP-tyyppi, PDP-osoite, pääsypisteen nimi, neuvotellut QoS-profiilit, 10 haluttu suodin, TID ja konfigurointioptiot). GGSN voi myös rajoittaa pyydettyjä QoS-attribuutteja ottaen huomioon kykynsä ja vallitsevan kuormituksen. Jos matkaviestin pyytää dynaamista osoitetta, niin SGSN antaa GGSN:n allokoida dynaamisen osoitteen. SGSN voi rajoittaa pyydettyjä QoS-attribuutteja ottaen huomioon kykynsä, vallitsevan kuormituksen ja tilatun QoS-profiilin. SGSN lä-15 hettää asiaankuuluvalle GGSN:lle PDP-kontekstin luontipyynnön (PDP-tyyppi, PDP-osoite, pääsypisteen nimi, neuvoteltu QoS, suodinmääritys, TID, valinta-tila, konfigurointioptiot). Pääsypisteen nimen APN tulee olla valitun APN:n APN-verkkotunnus liitteessä A kuvatun proseduurin mukaisesti. PDP-osoitteen tulee olla tyhjä dynaamista osoitetta pyydettäessä. GGSN voi käyttää pääsy-20 pisteen nimeä ulkoisen verkon löytämiseksi. Valintatila (selection mode) osoittaa, oliko valittuna tilattu APN, matkaviestimen lähettämä ei-tilattu APN ·. vaiko SGSN:n valitsema ei-tilattu APN. Valintatila asetetaan liitteen A mukai sesti. GGSN voi käyttää valintatilaa päättäessään hyväksyykö vai hylkääkö se t . PDP-kontekstin aktivoinnin. Esimerkiksi jos APN vaatii tilausta, niin GGSN on . 25 konfiguroitu hyväksymään vain PDP-kontekstin aktivointi, joka vaatii tilattua APN:ää, kuten SGSN valintatilaa käyttäen osoittaa. GGSN luo uuden merkin- I t * ' nän PDP-kontekstitaulukkoonsa ja kehittää laskutustunnisteen. Tämä uusi • » · v : merkintä sallii GGSN:n reitittää PDP-pakettidatayksiköitä SGSN:n ja ulkoisen PDP-verkon välillä sekä aloittaa laskutuksen. GGSN voi edelleen rajoittaa ’: ‘ : 30 neuvoteltua QoS:ää ottaen huomioon kykynsä ja vallitsevan kuormituksen.

• “': GGSN:n tulee ylläpitää informaatiota QoS-kartoitusta varten ja lomittaa tulevia ‘ . datapaketteja ulkoisesta verkosta aktiivisiin PDP-konteksteihin GGSN:ssä määriteltyjen suodinehtojen mukaisesti. Lähtevien pakettien osalta tietty ulkoinen QoS voidaan liittää tietyn PDP-kontekstin paketteihin. GGSN palauttaa 35 sitten SGSN:lle PDP-kontekstin luontivasteen (Create PDP Context Response; TID, PDP-osoite, BB-protokolla, uudelleenjärjestys vaadittu, PDP konfiguroin- 12 H) 8 6 G1 tioptiot, neuvoteltu QoS, laskutustunnus, aihe). PDP-osoite sisällytetään, jos GGSN allokoi sen. BB-protokolla osoittaa, tuleeko SGSN:n ja GGSN:n välisellä runkoverkolla (backbone network) käyttää TCP:tä vai UDP:tä käyttäjän datan kuljettamiseen. Uudelleenjärjestys vaadittu osoittaa, tuleeko SGSN:n 5 järjestää uudelleen N-protokolladatayksiköt ennen niiden toimittamista matkaviestimelle. PDP-konfigurointioptiot sisältävät valinnaisia PDP-parametreja, joita GGSN voi välittää matkaviestimelle. Matkaviestin voi pyytää näitä valinnaisia PDP-parametreja PDP-kontekstin aktivointipyyntösanomassa, tai GGSN voi lähettää ne pyytämättä. PDP-konfigurointioptiot lähetetään läpinäkyvästi 10 SGSN:n kautta. PDP-kontekstin luontisanomat lähetetään GPRS-runkoverkon kautta. Jos SGSNJtä vastaanotettu neuvoteltu QoS on yhteensopimaton aktivoitavan PDP-kontekstin kanssa (esim. luotettavuusluokka on riittämätön tukemaan PDP-tyyppiä), niin GGSN hylkää PDP-kontekstin luontipyyntösano-man. GGSN:n operaattori voi konfiguroida yhteensopivat QoS-profiilit.

15 Vaiheessa 6-4 GGSN palauttaa SGSNJIe PDP-kontekstin luonti- vasteen (johon kuuluu TID, PDP-osoite, neuvotellut QoS-profiilit ja PDP-konfigurointioptiot). SGSN lisää PDP-kontekstiin NSAPI:n yhdessä GGSN:n osoitteen kanssa. Jos matkaviestin on pyytänyt dynaamista osoitetta, niin GGSNJtä vastaanotettu PDP-osoite lisätään PDP-kontekstiin. SGSN valitsee 20 radioprioriteetin neuvotellun QoS:n perusteella ja palauttaa matkaviestimelle PDP-kontekstin aktivointipyynnön hyväksymissanoman (PDP-tyyppi, PDP-t*.ti osoite, Tl, neuvoteltu QoS, radioprioriteetti, PDP-konfigurointioptiot). Nyt SGSN kykenee reitittämään PDP-protokolladatayksiköitä GGSN:n ja matka- * · · viestimen välillä, sekä aloittamaan laskuttamisen.

I*«| 7 • · . 25 Seuraavaksi, vaiheessa 6-5 SGSN valitsee radioprioriteettitason kunkin neuvotellun QoS-profiilin perusteella ja palauttaa matkaviestimelle • * · ‘•'8 PDP-kontekstin aktivoinnin hyväksynnän (johon kuuluu PDP-tyyppi, PDP-v : osoite, NSAPI, neuvotellut QoS-profiilit, radioprioriteettitaso ja SAPI kullekin

QoS-profiilille, suodin ja PDP-konfigurointioptiot). Nyt SGSN kykenee reitittä-'•”'i 30 mään PDP-pakettidatayksiköitä GGSN:n ja matkaviestimen välillä. SAPI

*”\· osoittaa, mikä QoS-profiili käyttää mitäkin SAPI:a.

,8. Kuvio 7 esittää kontekstin modifiointiproseduuria. Vaiheessa 7-1 matkaviestin lähettää SGSN:lle PDP-kontekstin modifiointipyynnön. Vaiheessa 7-3 SGSN lähettää GGSNJIe PDP-kontekstin päivityspyynnön. Kumpikin • 35 näistä pyynnöistä käsittää suotimen, modifioituine parametreineen. Suodin osoittaa, mitkä ulkoiset datapaketit kuuluvat tiettyyn PDP-kontekstiin. Suo- : '08601 13 elinehtojen osoittamat paketit tulisi tulkita kuuluviksi tähän nimenomaiseen PDP-kontekstiin, ja niille tulisi tarjota kontekstille neuvoteltu QoS. PDP-kontekstin päivityspyyntösanomaa käytetään lisäämään, muuttamaan tai peruuttamaan PDP-kontekstin QoS-profiili. Jos GGSN vastaanottaa SGSN:ltä 5 neuvotellun QoS:n, joka on yhteensopimaton modifioitavan PDP-kontekstin kanssa (esim. luotettavuusluokka on riittämätön tukemaan PDP-tyyppiä), GGSN hylkää pyynnön. GGSN:n operaattori konfiguroi yhteensopivat QoS-profiilit. GGSN voi jälleen rajoittaa pyydettyjä QoS-attribuutteja ottaen huomioon kykynsä ja vallitsevan kuormituksen. GGSN tallentaa neuvotellut QoS-10 arvot. GGSN tarkistaa QoS-kartoitusinformaation vastaamaan uutta suodin-! määritystä ja neuvoteltua QoS-profiilia (joka sisältyy pyyntösanomaan). Vai heissa 7-4 ja 7-5 matkaviestimelle palautetaan positiivinen kuittaus.

Sanomat 7-1 ... 7-5 tunnetaan GPRS:n vaiheesta 2. Keksinnön mukaisesti sanomia 7-1 ... 7-3 muutetaan kuljettamaan halutut suodinpara-15 metrit (ja sanomia 7-4 ja 7-5 muutetaan palauttamaan sopiva kuittaus).

Keksinnön vielä erään suoritusmuodon mukaan suodintoimintoa ensimmäisessä suunnassa (esim. alasuunnassa) voidaan muuttaa käyttämällä toiseen suuntaan (esim. yläsuuntaan) lähetettäviin paketteihin sisällytettävää informaatiota. Tämä suoritusmuoto ei vaadi mitään ylimääräistä signalointia. 20 Tämän esimerkinomaisen suoritusmuodon mukaan määritellään seuraavat lii-kenneluokat: (RT=tosiaikainen, NRT=ei-tosiaikainen): :·. Liikenne- Keskustelu (RT) Streaming (RT) Vuorovaikuttei- Tausta (NRT) ' . luokka nen(NRT) • taattu kapasiteetti · taattu kapasiteetti · paras yritys · paras yritys

· eiARQ · ARQ(MACtaso) · ARQ · ARQ

: T: · Puskurointia lisä- · vuorovaikutt. · sähköpostin, tään sovelluksessa www, Telnet kalenterita- • RT ohjaus- pahtumien kanava lataus taus- : _____talla ym.

’’Viive 100ms,200ms,400ms <1s 2 s ei sovellu

Bittivirhesuhde 103,10'4,10'5_105,10'6,107,10~8 < 1CT9_< 10~9_ . Max bittino- Taattu Taattu Ei taattu Ei taattu peus_____ ; ’ , Palveluetu- Korkea, keski-, matala Korkea, keski-, matala Korkea, keski-, Korkea, keski-, loikeus __[matala_matala_ ! 08601 14

Keskustelu- ja Streaming-luokat ovat tosiaikaisuuteen suuntautuvia liikenneluokkia, joille varataan resursseja. Vuorovaikutus- ja taustaluokat ovat parhaan yrityksen luokkia, joilla ei ole varattuja resursseja. Näille luokille voidaan käyttää GPRS:n tyylistä resurssinallokointia, eli matkaviestin lähettää ra-5 dioresurssipyyntöjä tarvittaessa.

Tosiaikaisille luokille, siis keskustelu ja streaming, yllä esitetty menetelmä on hyvin tehokas, toisin sanoen suodininformaation kuljettaminen PDP-kontekstioperaatioissa GGSN:lle siten, että GGSN voi kartoittaa tulevat tulevat IP-paketit oikeaan QoS-luokkaan. Kuitenkin vuorovaikutus- ja tausta-10 luokissa tästä aiheutuu paljon signalointia, mikä joissakin tilanteissa ei ehkä ole hyväksyttävissä. Esimerkki tällaisesta tilanteesta on kysely nimipalvelimelle DNS (Domain Name Server, ei näytetty), missä tapauksessa nettovuo voisi koostua vain kahdesta paketista.

Tässä esimerkissä vuorovaikutteinen luokka valitaan QoS-ole-15 tusluokaksi. Tämä tarkoittaa, että ellei ole informaatiota tulevan vuon QoS-vaatimuksista, tai vuoinformaatio ei vastaa mitään suodinehtoja, valitaan vuorovaikutteinen luokka. Lisäksi GGSN voi tunnistaa lennosta” taustaluokkaan kuuluvat vuot. Tämä tarkoittaa, että kun GGSN saa matkaviestimeltä paketin taustaluokassa, sen tulee huomata vuontunnusinformaatio ja muuttaa tausta-20 luokkaan kuuluvia suodinominaisuuksia, kartoittaakseen kyseistä vuota vastaavan alasuuntaisen vuon taustaluokkaan. Paketin tullessa alasuuntaan \ GGSN tarkistaa taustaluokkaan kuuluvan vuontunnusinformaation. Jos taus- :·. taluokkaan kuuluva vuonsuodininformaatio vastaa vastaanotetun IP-paketin » · · otsakeinformaatiota, niin paketti osoitetaan taustaluokkaan.

.25 Taustaluokkaan liittyvä vuoinformaatio voidaan käsitellä seuraavas- ti. Matkaviestimellä on tietoa voista, jotka tulisi kuljettaa taustaluokkaa käyttä- « · · ' en. Käyttäjä voi konfiguroida tämän voiden kartoituksen taustaluokkaan. Esi-; merkiksi käyttäjä voi konfiguroida tiedostosiirrot käyttämään taustaluokkaa käyttämällä sopivaa konfigurointisovellusta. Vaihtoehtoisesti tämä informaatio 30 voidaan saada esimerkiksi jostakin ulkoisesta QoS-informaatiosta (esim. Inter-netin QoS-informaatiosta). Toisin sanoen matkaviestimellä on suodinkriteerit taustaluokkaan kartoitettaville voille. Tämän suoritusmuodon olennainen piirre ! on, että matkaviestimellä on tietoa siitä, mitkä vuot tulisi osoittaa taustaluokkaan, ja se lähettää nämä paketit vastaavalle linkille. Kun GGSN saa paketteja f*.. 35 matkaviestimeltä, se tietää paketteihin liittyvän QoS-luokan. Kun GGSN saa paketin taustaluokasta, se tarkistaa, onko sillä jo merkintä tälle vuolle (ei- • a ; 'ϊ O 8 6 ϋ 1 I 15 ί j näytetyssä) listassa, joka sisältää vuoinfbrmaatiota kaikista taustaluokkaan kuuluvista voista. Ellei listassa ole tälle vuolle merkintää, GGSN muuttaa käytettyä alasuunnan voiden kartoittamiseen taustaluokkaan käytettyä suodinta niin, että se alasuunnan vuo, joka vastaa sitä yläsuunnan vuota, johon paketti 5 kuuluu, kartoitetaan taustaluokkaan. Tämä voidaan tehdä sisällyttämällä yläsuunnan paketin vuontunnusinformaatio siihen vuoinformaatiolistaan, josta alasuunnan paketit kartoitetaan taustaluokkaan. Näin taustaluokkaan kuuluvat vuot tunnistetaan GGSN:ssä lennossa”.

Kun GGSN saa paketin Internetistä tai jostakin muusta ulkoisesta 10 verkosta, se tarkistaa luokkiin keskustelu, Streaming ja tausta liittyvän suodin-informaation. Jos GGSN toteaa, että paketin ominaisuudet vastaavat relevantteja suodinehtoja, se välittää paketin vastaavaan QoS-luokkaan. Ellei kyseiselle vuolle ole merkintää, niin paketti välitetään vuorovaikutteiseen luokkaan, joka on oletusluokka.

15 Tämä suoritusmuoto alentaa ratkaisevasti signaloinnin tarvetta, koska vuorovaikutteinen luokka on useimmin käytetty QoS-luokka. On useita tapauksia, joissa IP-paketit eivät itse asiassa muodosta vuota, vaan sen sijaan on vain yksi ta muutama yläsuuntainen IP-paketti ja vasteena muutama ala-suuntainen paketti. Kysely nimipalvelimelle (DNS) on hyvä esimerkki tällai-20 sesta käytöksestä. PDP-kontekstin muutoksen signalointi näissä tapauksissa aiheuttaisi verrattain paljon signalointia, ja tämä voidaan välttää tätä suoritus-_ muotoa käyttämällä. Sen sijaan tarvitaan vain ensimmäinen PDP-kontekstin :·. aktivointi IP-osoitteen saamiseksi matkaviestimelle.

Kuvien 6 ja 7 esittämä lähestymistapa jättää jäljelle sen ongelman, . 25 että ei ehkä ole selvää, kuinka lisätään suodininformaatiota PDP-kontekstin

> · I M

suotimen lisäksi, tai kuinka muutetaan olemassaolevia suotimia ilman että en-' sin poistetaan kaikki olemassaolevat suotimet ja sitten lähetetään uudelleen v ' kaikki suodininformaatio, mukaanlukien muutokset. Toisin sanoen PDP- kontekstin aktivointi-ja modifiointiproseduurien käyttäminen aina johtaa siihen, ’:' ’: 30 että koko suodininformaatio sisällytetään sanomiin vaikka vain yhden paramet- 1 rin arvoa on muutettava. Uuden suotimen lisääminen vaatii kaikkien suotimien ' . lähettämistä samanaikaisesti. Tämän perusteella kuvioissa 8 ja 9 esitetään keksinnön edullinen suoritusmuoto, joka pyrkii ratkaisemaan tämän jään-, ' nösongelman.

: 35 Ehdotetaan, että suodininformaation konfiguroimiseksi tulisi olla ai- nakin yksi erillinen (dedikoitu) sanoma. Tässä yhteydessä ‘erillinen’ tarkoittaa, 1 0 8 6 01 16 että sanoma ei kuljeta PDP-kontekstitietoa. Tietyn PDP-kontekstin tietyn suotimen yksilöimiseksi tulisi määritellä suodinkahva (filter handle). Tämä suodin-kahva voi koostua tunnelitunnuksesta TID, joka osoittaa käyttäjän ja PDP-kontekstin, sekä suodinnumerosta FN. Viime mainittu voi olla sekvenssinume-5 ro, jonka matkaviestin valitsee suotimen luomisen yhteydessä. Yhteenvetona suotimia voidaan konfiguroida seuraavilla proseduureilla: 1. Yksi tai useampia suotimia voidaan luoda PDP-kontekstin akti-vointiproseduurin yhteydessä (ks. kuvio 6). Tässä tapauksessa PDP-kontekstin aktivointisanomaan sisällytetään yksi tai useampia suodininformaa-10 tioelementtejä, joista kukin yksilöidään erillisellä suodinnumerollaan (1, 2, 3 jne.) i 2. Suotimia voidaan modifioida PDP-kontekstin modifiointiproseduu- rin yhteydessä (ks. kuvio 7). Tässä tapauksessa yhden tai useamman suotimen yhtä tai useampaa suodinparametria voidaan modifioida lisäämällä PDP-15 kontekstin modifiointipyyntöön suodininformaatioelementtejä. Itsenäiset suotimet yksilöidään suodinnumerolla. Myös uusia suotimia voidaan luoda tätä proseduuria käyttämällä. Tässä tapauksessa modifiointipyyntösanomaan sisällytetään uusi suodininformaatioelementti (esim. uusi, aiemmin käyttämätön suodinnumero).

20 3. Uudet suodinoperaatiot: (yksi tai useampia erillisiä sanomia): suotimien konfiguroimiseksi ehdotetaan kolmea operaatiota: t‘.if 3.1. Suotimen luonti (Create filter): tämä sanoma kuljettaa TID-

:·, informaatiota sekä uuden suodinelementin ja uuden suodinnumeron. GGSN

* · luo uuden suotimen sanoman sisällön mukaisesti.

Mlt * * ; 25 3.2. Suotimen modifiointi (Modify filter): tämä sanoma kuljettaa TID- informaatiota sekä uuden suodinelementin, joka korvaa vanhan, sekä suodin- » * * numeron, joka yksilöi kyseisen korvattavan suotimen. GGSN korvaa osoitetun ’·' * suotimen suodinattribuutit uusilla.

3.3 Suotimen poisto (Delete filter): tämä informaatio kuljettaa TID-'!"i 30 informaatiota sekä poistettavan suotimen numeron. GGSN poistaa kyseisen suotimen.

J t 4

Tulisi huomata, että operaatiot 3.1 - 3.3 voidaan yhdistää käyttä-! mään vain yhtä tai kahta sanomatyyppiä, mutta voidaan määritellä myös kol me erilaista sanomaa (yksi kullekin operaatiolle). Määritellyt sanomat voivat • 35 olla GTP-sanomia, missä tapauksessa tulisi määritellä uusia GTP-sanomia (toisin sanoen uusia sanomanosoittimia GTP:ssä). Tässä tapauksessa TID- :08601 17 informaatio sisällytetään automaattisesti GTP-pakettiotsakkeisiin eikä sen tarvitse olla erillinen informaatioelementti sanomassa. Vaihtoehtoisesti matkaviestimen ja GGSN:n välillä voidaan määritellä uusi protokolla suodinoperaati-oita varten, missä tapauksessa SGSN tulisi olemaan täysin transparentti näille 5 sanomille.

Kuvio 8 esittää uusien suodinoperaatioiden 3.1 - 3.3 ensimmäisen toteutuksen. Vaiheessa 8-0 matkaviestimelle aktivoidaan PDP-konteksti. Tämän operaation yksityiskohdat on jo selostettu aiempien kuvioiden yhteydessä. Vaiheessa 8-1 matkaviestin lähettää Create Filter -sanoman SGSN:lle.

10 Tällä sanomalla on parametreinään tunnelitunnus TID (joka osoittaa PDP-kontekstin) ja suodinnumero FN (joka osoittaa tietyn suotimen PDP-kontekstista). Create Filter -sanoman tulee tietysti sisältää myös suotimen ominaisuudet. Vaiheessa 8-2 sanoma välitetään SGSN:ltä GGSN:lle. Vaiheet 8-3 ja 8-4 ovat vastaavia kuittauksia. Vaiheessa 8-5 matkaviestimelle tai mat- 15 kaviestimeltä lähetetään dataa. Vaiheet 8-6 ... 8-9 vastaavat vaiheita 8-1 ... 8-4, paitsi että viime mainituissa vaiheissa matkaviestin (tai suoritettava so-j vellus) muuttaa olemassaolevaa suodinta lähettämällä Modify Filter -sanoman. Vaiheissa 8-11 ... 8-14 suodin, jota ei enää tarvita, poistetaan lähettämällä Delete Filter -sanoma.

20 Kuviossa 8 näytetty toteutus perustuu olemassaoleviin protokolliin.

Matkaviestimen ja SGSN:n väliset sanomat voivat olla esim. istunnonhallinta-sanomia ja SGSN:n ja GGSN:n väliset sanomat voivat olla esim. GTP- ·. sanomia. Kuten nähdään, matkaviestimen ja GGSN:n välinen suotimen neu- j :·. votteleminen on tarpeettoman mutkikasta, koska matkaviestimen ja GGSN:n | *ii>: 25 välillä ei ole ennalta määrättyjä protokollia.

Selvyyden vuoksi sanomat 8-1, 8-6 ja 8-11 on näytetty kolmena erillisenä sanomana. Vaihtoehtoisesti kaikki nämä sanomat voisivat käyttää '·’/ vain yhtä sanomaa, esim. Configure Filter, joka sisältää parametrin, kuten ; 1=create, 2=modify, 3=delete.

30 Kuvio 9 näyttää vaihtoehtoisen toteutuksen, jossa matkaviestimen ja GGSN:n välillä on protokollakerros ja SGSN on transparentti solmu tulkit-' ’ *: sematta sanomia millään tavalla.

,6.; Kuvioissa 8 ja 9 näytetty suoritusmuoto eri toteutuksineen tuottavan hyvin joustavan kaavion, jossa itsenäisiä (esim. sovelluskohtaisia) suotimia 35 voidaan lisätä ja modifioida dynaamisesti käyttämällä erityisiä suodinoperaati-: oita. Erityistä suodinkahvaa käytetään yksilöimään itsenäisiä suotimia.

I n « a π 1 18

Selostus esittää vain keksinnön edullisia suoritusmuotoja. Keksintö ei kuitenkaan rajoitu niihin, vaan se voi vaihdella oheisten patenttivaatimusten puitteissa. Esimerkiksi ei ole välttämätöntä, että vastaanottava pääte on matkaviestin, vaan se voi olla mikä tahansa verkkoelementti. Samoin ei ole vält-5 tämätöntä, että matkaviestimelle päättyvät paketit lähtevät IP-verkosta. Sen sijaan keksintö on sovellettavissa esimerkiksi matkaviestimien välisessä puhelussa GGSN-solmun kautta. Tässä tapauksessa haara yhdeltä matkaviestimeltä GGSN:lle on ensimmäinen liikennealijärjestelmä ja haara GGSN:ltä toiselle matkaviestimelle on toinen liikennealijärjestelmä.

• · * • · · · » · · * # · • t ·

» I I

Claims

1. Menetelmä datapakettien (DP) lähettämiseksi ensimmäisestä lii-kennealijärjestelmästä (11, 12) ensimmäisen verkkoelementin (GGSN) kautta toiselle verkkoelementille (MS) toisessa liikennealijärjestelmässä (13), joka 5 menetelmä käsittää seuraavat vaiheet: - lähetetään datapaketteja (DP) ensimmäisessä joukossa datavoita mainitussa ensimmäisessä liikennealijärjestelmässä (11,12); ja - kartoitetaan mainittu ensimmäinen joukko datavoita toiseen joukkoon datavoita mainitussa toisessa liikennealijärjestelmässä (13); 10 tunnettu siitä, että: - muodostetaan ainakin yksi suodin (Fl) mainitun kartoituksen ohjaamiseksi; - liitetään mainittu ainakin yksi suodin (Fl) johonkin datavuohon toisessa joukossa; ja 15. kartoitetaan ainakin yksi datavuo mainitun suotimen (Fl) perus teella.

2. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että mainittu suodin (Fl) konfiguroidaan toiselta verkkoelementiltä (MS).

3. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, 20 että mainittu suodin (Fl) konfiguroidaan pakettidataprotokollan kontekstin aktivointi- tai modifiointisanomassa (6-1, 7-1).

4. Patenttivaatimuksen 4 mukainen menetelmä, tunnettu siitä, I että ainakin kaksi suodinta (Fl) konfiguroidaan yhdessä pakettidataprotokollan kontekstin aktivointi- tai modifiointisanomassa, ja kukin suodin yksilöidään eril-25 lisellä tunnisteella. ,,,,: 5. Patenttivaatimuksen 2 mukainen menetelmä, t u n n e tt u siitä, että mainittu ainakin yksi suodin (Fl) konfiguroidaan erillisessä sanomassa (8-’:!/ 1,8-6,8-11:9-1,9-4,9-7).

6. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, 30 että mainittu suodin (Fl) konfiguroidaan sanomassa, joka on transparentti ai- nakin joillekin ensimmäisen ja toisen verkkoelementin välisille solmuille (GGSN, MS).

7. Jonkin edellisen patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että ensimmäinen liikennealijärjestelmä on IP-verkko ja me- . 35 netelmässä allokoidaan yksi IP-osoite, jonka jakavat kaikki toisen joukon data- : ‘ · · vuot. * · ·

0 B 6 u 1 20

8. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että ensimmäinen liikennealijärjestelmä on IP-verkko ja menetelmässä allokoidaan erillinen IP-osoite kullekin toisen joukon datavuolle.

9. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, 5 tunnettu siitä, että ensimmäinen liikennealijärjestelmä on PDP-protokollaa käyttävä pakettiradioverkko, ja että mainittu konfigurointivaihe käsittää PDP-kontekstin aktivointisanoman (6-1, 6-3) tai PDP-kontekstin modifiointisanoman (7-1,7-3) lähettämisen.

10. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, 10 tunnettu siitä, että mainittu liittäminen perustuu toisen verkkoelementin (MS) osoitteeseen, edullisesti sen IP-osoitteeseen, ensimmäisessä liikennea-lijärjestelmässä (11, 12).

11. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että mainittu liittäminen perustuu toisen verkkoelementin 15 (MS) tunnisteeseen, edullisesti sen IMSI- tai tunnelitunnisteeseen, toisessa lii-kennealijärjestelmässä (13).

12. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, tunnettu siitä, että: - toteutetaan mainittu kartoitus suotimen (Fl) perusteella datavoille, 20 jotka kuljettavat tosiaikaista informaatiota; ja - muodostetaan oletusparametrit muiden datavoiden kartoittamiseksi.

13. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, .··, tunnettu siitä, että toisesta joukosta määritellään yksi datavuo oletusdata- ' . 25 vuoksi, johon kartoitetaan kaikki ensimmäisen joukon datavuot, jotka eivät vastaa mainittua ainakin yhtä suodinta (Fl).

14. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, • t · '·’ tunnettu siitä, että ainakin yksi datavoista on kaksisuuntainen, ja siihen * * * v ; kuuluu ensimmäinen suunta ensimmäisestä joukosta toiseen joukkoon ja toi-30 nen suunta, joka on käänteinen ensimmäiseen suuntaan nähden, ja että aina-:·*: kin yhtä suodinta (Fl) modifioidaan toiseen suuntaan lähetettyjen käyttäjän ·"*: datapakettien perusteella.

15. Patenttivaatimuksen 14 mukainen menetelmä, tunnettu ’ siitä, että datavoita kartoittava kauttakulkuelementti (GGSN): 35. vastaanottaa datapaketin toisessa suunnassa toisen joukon en- : ’ ·.. simmäisestä datavuosta; 21 ! 0 B 6 01 ! - välittää datapaketin ensimmäisen joukon toiseen datavuohon; ja - modifioi ainakin yhtä suodinta (Fl) toisen datavuon kartoittamiseksi ensimmäiseen datavuohon.

16. Jonkin edellisen patenttivaatimuksen mukainen menetelmä, 5 tunnettu siitä, että ainakin yksi ensimmäisen joukon datavuo tunneloidaan toisen joukon datavuon yli, ja että ainakin kahdella toisen joukon datavuolla on keskenään erilaiset palvelun laatuominaisuudet.

17. Ensimmäinen verkkoelementti, edullisesti Gateway GPRS Support Node (GGSN), datapakettien (DP) reitittämiseksi ensimmäisestä liikenne- 10 alijärjestelmästä (11, 12) toiseen verkkoelementtiin (MS) toisessa liikenneali-järjestelmässä (13); joka ensimmäinen verkkoelementti (GGSN) on sovitettu: - vastaanottamaan datapaketteja (DP) ensimmäisestä liikenneali- { järjestelmästä (11, 12) ensimmäisessä joukossa datavoita; ja 15. kartoittamaan ensimmäisen joukon datavoita toiseksi joukoksi da tavoita toisessa liikennealijärjestelmässä (13); tunnettu siitä, että ensimmäinen verkkoelementti (GGSN) on sovitettu: - muodostamaan ainakin yksi suodin (Fl) mainitun kartoituksen oh- 20 jäämiseksi; - liittämään mainittu ainakin yksi suodin (Fl) johonkin datavuohon toisessa joukossa; ja - kartoittamaan ainakin yksi datavuo mainitun suotimen (Fl) perus- :·. teella.

18. Digitaalinen signaali pakettidataprotokollakontekstin luomiseksi ,...; (6-1,6-3, 8-1,9-1) tai modifioimiseksi (7-1, 7-3, 8-6, 9-4) tukisolmussa (GGSN) ensimmäisen liikennealijärjestelmän (11, 12) liittämiseksi toiseen liikenneali- • ' » järjestelmään (13); t u n n e 11 u siitä, että mainittu signaali käsittää informaa-' tiota, joka ainakin osittain määrittelee suotimen (Fl) tukisolmun (GGSN) suo- 30 rittamaa datavoiden kartoittamista varten ensimmäisestä liikennealijärjestel-mästä (11, 12) toiseen liikennealijärjestelmään (13). < * » I » i I i > » 22 1 0 8 6 01