FI104668B - Liittymäpalvelun toteuttaminen - Google Patents

Liittymäpalvelun toteuttaminen Download PDF

Info

Publication number
FI104668B
FI104668B FI981031A FI981031A FI104668B FI 104668 B FI104668 B FI 104668B FI 981031 A FI981031 A FI 981031A FI 981031 A FI981031 A FI 981031A FI 104668 B FI104668 B FI 104668B
Authority
FI
Finland
Prior art keywords
billing
terminal
service
network
access
Prior art date
Application number
FI981031A
Other languages
English (en)
Swedish (sv)
Other versions
FI981031A0 (fi
FI981031A (fi
Inventor
Philip Ginzboorg
Pekka Laitinen
Jan-Erik Ekberg
Tom Soederlund
Patrik Flykt
Antti Yli-Jaeaeski
Original Assignee
Nokia Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FI972980A external-priority patent/FI104667B/fi
Publication of FI981031A0 publication Critical patent/FI981031A0/fi
Priority to FI981031A priority Critical patent/FI104668B/fi
Application filed by Nokia Networks Oy filed Critical Nokia Networks Oy
Priority to AU84433/98A priority patent/AU741703B2/en
Priority to PCT/FI1998/000590 priority patent/WO1999007108A2/en
Priority to CN98808149.0A priority patent/CN1267414A/zh
Priority to EP98935049A priority patent/EP1005737A2/en
Priority to JP2000505712A priority patent/JP2001512926A/ja
Publication of FI981031A publication Critical patent/FI981031A/fi
Priority to NO20000170A priority patent/NO20000170L/no
Publication of FI104668B publication Critical patent/FI104668B/fi
Application granted granted Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/141—Indication of costs
    • H04L12/1414—Indication of costs in real-time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1403—Architecture for metering, charging or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/141—Indication of costs
    • H04L12/1421—Indication of expected costs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1425—Charging, metering or billing arrangements for data wireline or wireless communications involving dedicated fields in the data packet for billing purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1428—Invoice generation, e.g. customization, lay-out, database processing, algorithms for calculating the bill or formatting invoices as WWW pages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H04L12/1464—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network using a card, such as credit card, prepay card or SIM
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H04L12/1471—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network splitting of costs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1453—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network
    • H04L12/1482—Methods or systems for payment or settlement of the charges for data transmission involving significant interaction with the data transmission network involving use of telephony infrastructure for billing for the transport of data, e.g. call detail record [CDR] or intelligent network infrastructure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1485—Tariff-related aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2801—Broadband local area networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854—Wide area networks, e.g. public data networks
    • H04L12/2856—Access arrangements, e.g. Internet access
    • H04L12/2869—Operational details of access network equipments
    • H04L12/287—Remote access server, e.g. BRAS
    • H04L12/2874—Processing of data for distribution to the subscribers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/09—Third party charged communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/80—Rating or billing plans; Tariff determination aspects
    • H04M15/8033—Rating or billing plans; Tariff determination aspects location-dependent, e.g. business or home
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/22—Bandwidth or usage-sensitve billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/66—Third party billing, i.e. third party can also be the predetermined telephone line of the caller if he is calling from another telephone set
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/74—Rating aspects, e.g. rating parameters or tariff determination apects
    • H04M2215/7435—Location dependent, e.g. Bussiness or home

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Meter Arrangements (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Description

1 104668
Liittymäpalvelun toteuttaminen
Keksinnön ala
Keksintö liittyy yleisesti liittymäpalvelun toteuttamiseen tietoliikenne-5 järjestelmässä, erityisesti liittymäpalvelun (access service) yhteydessä toteutettavaan laskutukseen. Liittymäpalvelulla tarkoitetaan tässä yhteydessä palvelua, jolla verkon käyttäjälle, esim. puhelinverkon tilaajalle tai lähiverkon käyttäjälle annetaan pääsy palveluja tarjoavaan verkkoon, esim. Internet-verkkoon, tai sellaiseen osaan verkkoa, josta palveluja tarjotaan.
10
Keksinnön tausta
Optinen kuitu on itsestään selvä valinta runkoverkon siirtomediaksi, koska runkoyhteyksillä on yleensä tarvetta suureen siirtokapasiteettiin, käytetyt siirtoetäisyydet ovat pitkiä, ja kaapeleille löytyy usein valmiita reittejä. Tilaaja-15 yhteyksilläkin (paikalliskeskuksen ja tilaajan välinen linja) tilanne on nopeasti muuttumassa, koska erilaiset multimedialla toteutetut palvelut, jotka vaativat suurta siirtonopeutta, tulevat olemaan arkipäivää myös yksityisen kuluttajan kannalta.
Tulevaisuuden laajakaistaisia palveluja tarjoavan verkon rakennus-20 kustannuksiin ei kuitenkaan ole odotettavissa merkittäviä säästöjä, koska kustannukset syntyvät pääasiassa kaapelin asennuskustannuksista. Optista kuitua haluttaisiin kuitenkin rakentaa myös tilaajaverkon puolelle mahdollisimman paljon, koska on selvästi nähtävissä, että sitä tarvitaan tulevaisuudessa.
, Tilaajaverkon uusimisen kustannukset ovat kuitenkin erittäin suuret, ja ajalli- 25 sestikin puhutaan tässä yhteydessä vuosikymmenistä. Suuret kustannukset ovatkin pahin este kuidun leviämiselle tilaajaverkon puolelle.
Edellä mainituista syistä johtuen on ryhdytty entistä tehokkaammin selvittämään tavanomaisen tilaajajohdon (metalliparikaapelin) hyödyntämistä nopeaan datasiirtoon, toisin sanoen nopeuksille, jotka ovat selvästi ISDN-' . 30 perusliittymän nopeuden (144 kbit/s) yläpuolella. Nykyiset ADSL (Asym metrical Digital Subscriber Line) ja HDSL (High bit rate Digital Subscriber Line) -tekniikat tarjoavatkin uusia mahdollisuuksia nopean datan ja videon siirtämiseksi puhelinverkon parikaapelia pitkin tilaajien päätelaitteille.
ADSL-siirtoyhteys on epäsymmetrinen siten, että siirtonopeus ver-35 kosta tilaajalle päin on huomattavasti suurempi kuin tilaajalta verkkoon päin. ADSL-tekniikka on tarkoitettu pääasiassa erilaisille tilauspalveluille (ns. "on 2 104668 demancf-palvelut). Käytännössä on ADSL-siirtoyhteyden nopeus verkosta tilaajalle päin luokkaa 2-6 Mbit/s ja tilaajalta verkkoon päin luokkaa 16 - 640 kbit/s (pelkkä ohjauskanava).
HDSL-siirtotekniikka koskee 2 Mbit/s-tasoisen digitaalisen signaalin 5 siirtämistä metalliparikaapelissa. HDSL edustaa symmetristä tekniikkaa, toisin sanoen siirtonopeus on sama kumpaankin suuntaan. Yksittäinen HDSL-lähe-tinvastaanotinjärjestelmä käsittää kaiunpoistotekniikkaa käyttävät lähetinvas-taanottimet, jotka ovat yhteydessä toisiinsa parikaapelin muodostaman kaksisuuntaisen siirtotien kautta. HDSL-siirtojärjestelmässä voi tällaisia yksittäisiä 10 lähetinvastaanotinjärjestelmiä olla yksi, kaksi tai kolme rinnakkaista, jolloin kahden tai kolmen rinnakkaisen parin tapauksessa kullakin rinnakkaisella siirtoyhteydellä käytettävä nopeus on 2 Mbit/s alinopeus; 784 kbit/s kolmen rinnakkaisen parin tapauksessa ja 1168 kbit/s kahden rinnakkaisen parin tapauksessa. Kansainvälisissä suosituksissa määritellään, kuinka HDSL-järjes-15 telmässä siirretään 2 Mbit/s-tasoisia signaaleja, kuten esim. SDH-verkon VC- 12-signaaleja tai CCITT:n suositusten G.703/G.704 mukaisia 2048 kbit/s signaaleja.
Koska edellä mainituilla ratkaisuilla päästään vain nopeuksille, jotka ovat luokkaa 1-6 Mbit/s, on tilaajajohdon parikaapeliin haettu myös tekniik-20 kaa, joka mahdollistaisi ATM-tasoiset nopeudet (10-55 Mbit/s). Kansainvälinen standardointijärjestö ETSI (European Telecommunications Standards Institute) onkin tekemässä spesifikaatiota VDSL-laitteista (Very high data rate Digital Subscriber Line), joilla tällaiset nopeudet mahdollistetaan. VDSL-tekniikalla voidaan toteuttaa sekä symmetrisiä että asymmetrisiä yhteyksiä.
25 Edellä mainittuja teknologioita, joilla siirretään nopeaa dataa parikaa pelin kautta kutsutaan yhteisellä lyhenteellä xDSL. Vaikka siis vielä ei olekaan mahdollista tarjota loppukäyttäjille laajakaistaisia palveluja optisen kuidun avulla, näiden tekniikoiden avulla nykyiset puhelinoperaattorit pystyvät tarjoamaan kyseisiä palveluja olemassa olevien tilaajajohtojen kautta. Koska ADSL 30 näyttää tällä hetkellä lupaavimmalta tekniikalta laajakaistaistaisten palvelujen : . . toteuttamiseksi, käytetään sitä esimerkkinä siitä liittymätekniikasta, jonka avulla palvelut tarjotaan.
ADSL Forum on määritellyt yleisen xDSL-yhteyksiä koskevan verkkomallin, jota on havainnollistettu kuviossa 1. Laite, joka kytkeytyy tilaajajoh-35 dolle tilaajan päässä on nimeltään ATU-R (ADSL Transmission Unit - Remote) ja laite, joka kytkeytyy tilaajajohdolle verkon päässä (esim. paikalliskeskuksessa) on nimeltään ATU-C (ADSL Transmission Unit - Central). Näitä laitteita 3 104668 kutsutaan myös ADSL-modeemeiksi (tai ADSL-lähetinvastaanottimiksi; ADSL-transceiver) ja ne muodostavat väliinsä ADSL-linkin. ADSL-yhteyden nopea data yhdistetään tilaajajohdolle niin, että tilaaja voi edelleen käyttää vanhoja kapeakaistaisia POTS/ISDN-palveluja, mutta sen lisäksi hänellä on käytettä-5 vissään nopea datayhteys. Nämä kapea- ja laajakaistaiset palvelut erotetaan toisistaan suodattimena PS (POTS-splitter), joka suorittaa ADSL-signaalien ja kapeakaistaisten signaalien taajuuserottelun.
Loppukäyttäjän luona olevat päätelaitteet TE voivat olla useaa eri tyyppiä, esim. kaapeli-TV-verkon päätteitä TE1, henkilökohtaisia tietokoneita 10 TE2 tai ISDN-puhelimia TE3. Jokaista päätelaitetta kohti on palvelumoduuli SMi (i=1...3), joka suorittaa päätesovitukseen liittyvät funktiot. Tällaisia palve-lumoduuleja voivat käytännössä olla esim. ns. Set Top Boxit, PC-rajapinnat tai lähiverkkoreitittimet. Tilaajan tiloissa oleva jakeluverkko PDN (Premises Distribution Network) yhdistää ATU-R:n palvelumoduuleihin.
15 ADSL-linkin verkon puoleisessa päässä liittymäsolmu AN (Access
Node) muodostaa kapeakaistaisen ja laajakaistaisen datan keskityspisteen, jossa keskitetään erilaisista palvelujärjestelmistä erilaisten verkkojen kautta tuleva liikenne. Liittymäsolmu sijaitsee esim. puhelinverkon keskuksessa.
Kuviossa 1 on viitemerkillä A merkitty yksityisen verkon osuutta, 20 viitemerkillä B julkisen verkon osuutta ja viitemerkillä C tilaajan tiloissa olevaa verkkoa (puhelimet ovat luonnollisesti tilaajan luona).
Edellä kuvatun kaltaisessa verkossa on ongelmana se, kuinka loppukäyttäjää laskutetaan liittymäpalvelusta (eli tilaajajohdon käytöstä) hänen käyttäessään palvelujärjestelmien tarjoamia palveluja, esim. Intemet-palveluja. 25 Laskutuksen halutaan pohjautuvan aikaan tai siirrettyyn datamäärään tai molempiin. Ongelma johtuu ensinnäkin siitä, että verkko voi olla tyypiltään yhteydetön. Toisin sanoen, tällöin verkossa ei ole yhteyden muodostus- ja purkusanomia (kuten SETUP ja RELEASE), joten laskutusta ei voida suorittaa nykyisen puhelinverkon tapaan yhteyksien muodostamis- ja purkutapahtumiin 30 perustuen. Toiseksi, xDSL-modeemien valmistajat eivät ole varustaneet lait-: teitään siten, että niiden avulla olisi aikaan tai siirrettyyn datamäärään perustu va laskutus mahdollinen. Modeemeista ei siis saada ulos sitä tietoa, joka tarvittaisiin laskutusta varten.
Huomattakoon vielä, että jos päätelaite on ISDN-päätelaite tai ATM-35 päätelaite, jokainen istunto alkaa SETUP-sanomalla ja päättyy RELEASE-sanomalla, jolloin aikaan perustuva laskutus voidaan toteuttaa tavanomaisella tavalla. Em. ongelma koskee siis sellaisia verkkoja, joissa verkko on yhteyde- 4 104668 tön päätelaitteen ja liittymäsolmun välillä, tai ainakin päätelaitteen TE ja jakeluverkon PDN välisen linkin osalta. On nimittäin mahdollista toteuttaa päätelaitteen ja liittymäsolmun välinen siirtotie esim. siten, että liittymäsolmun ja ATU-R:n välinen osuus on yhteydellinen (esim. ATM-pohjainen) ja ATU-R:n ja 5 päätelaitteen välinen osuus yhteydetön (esim. Ethemet-linkki).
Myös sellaisissa yhteydettömissä järjestelmissä, joissa tuetaan päätelaitteen liikkuvuutta on ongelmana se, kuinka loppukäyttäjää laskutetaan liittymäpalvelusta. Päätelaitteen liikkuvuutta tukevat protokollat (esim. mobile IP, IP=lntemet Protocol)) eivät nimittäin mahdollista sitä, että verkon käyttäjiä 10 voitaisiin rajoittaa tietyn kriteerin perusteella, esim. sen perusteella, ketkä ovat maksavia asiakkaita.
Em. ongelmaan liittyy erityisesti kiinteiden päätelaitteiden tapauksessa tilanne, jossa useat eri asiakkaat käyttävät samaa tilaajajohtoa, jolloin asiakkaita ei pystytä erottamaan tilaajajohdon mukaan. Tällainen tilanne on 15 esimerkiksi silloin, kun yleisölle tarjotaan pääsy laajakaistapalveluihin sijoittamalla päätelaite julkisiin tiloihin, esim. kirjastoon tai ostoskeskukseen. Sama ongelma liittyy myös tilanteeseen, jossa esim. kotoa halutaan tehdä etätyötä kytkeytymällä ainoastaan oman työantajan lähiverkkoon. Tällöinkään ei pystytä havaitsemaan, että kyseisen yhteysistunnon laskutus pitäisi päätelaitteen 20 käyttäjän sijasta osoittaa työnantajalle. Järjestelmässä ei siis pystytä erottamaan, milloin henkilö käyttää yhteyttä ns. business-käyttäjänä (jonka laskut maksaa työnantaja) ja milloin yksityisenä käyttäjänä (joka maksaa laskunsa itse).
Jatkossa käytetään termiä “käyttäjä”, kun viitataan siihen henkilöön, * 25 joka käyttää päätelaitetta ja termiä “tilaaja”, kun viitataan siihen organisaatioon tai henkilöön, joka maksaa palvelun käytöstä. Käyttäjä voi olla myös tilaaja.
Keksinnön yhteenveto
Keksinnön tarkoituksena on päästä eroon edellä kuvatuista epäkoh-. 30 dista ja saada aikaan ratkaisu, jonka avulla liittymäpalvelu voidaan toteuttaa : yhteydettömässä verkossa mahdollisimman yksinkertaista laitteistoa käyttäen niin, että palveluun voidaan yhdistää luotettava ja monipuolisesti toimiva laskutus. Tarkoituksena on myöskin saada aikaan ratkaisu, joka sopii sekä päätelaitteen liikkuvuutta tukeviin verkkoihin että myös tilanteisiin, joissa lasku on 35 lähetettävä muualle kuin tilaajajohdon määräämään osoitteeseen tai muualle kuin päätelaitteen verkko-osoitteen määräämälle tilaajalle.
Nämä päämäärät saavutetaan ratkaisulla, joka on määritelty itsenäi- 5 104668 sissä patenttivaatimuksissa.
Keksinnön ajatuksena on ensinnäkin indikoida aloitussanoman avulla kertaluonteisen palveluistunnon alku käyttäjän ottaessa yhteyden verkkoon. Aloitussanoman generoiva olio voi muuttua sen mukaan, millainen järjestelmä 5 on kysymyksessä, ja aloitussanoma voidaan lähettää monin eri tavoin niille elimille, jotka hoitavat laskutusta. Lisäksi ajatuksena on generoida päätelaitteelta verkkoon päin, esim. tasaisin välein, kyseisellä aloitussanomalla aloitettuun palveluistuntoon liittyviä laskutussanomia, jotka varustetaan tilaajakohtai-sella digitaalisella allekirjoituksella ja sallia (tai estää) käyttäjän pääsy verkkoon 10 sen mukaan, generoiko päätelaite näitä laskutustietueita hyväksyttävällä tavalla.
Tällä tavoin mahdollistetaan mm. verkon käyttäjien rajaus vain maksaviin käyttäjiin ja saman lähdeosoitteen käyttäjien erottaminen laskutuksen kannalta toisistaan. Jos useat käyttäjät käyttävät samaa tilaajajohtoa, pääte-15 laite ilmoittaa sitä kulloinkin käyttävään käyttäjään liittyvän tilaajan identiteetin allekirjoitusten tarkistamiseksi oikean tilaajan tiedoilla.
Järjestelmä on periaatteeltaan sellainen, että kaikki tietoturvallisuuden kannalta oleelliset osatekijät voidaan helposti toteuttaa: tiedon aitouden toteaminen (authentication), tiedon eheys (integrity), tiedon kiistämättömyys 20 (siirtotapahtuman osapuolella ei jälkeen päin ole mahdollisuutta kieltää osallistumistaan, non-repudiation) ja yksityisyyden säilyttäminen (salakuuntelua ei voi tulkita saamaansa dataa).
- - Järjestelmän eräs merkittävä lisäetu on se, että se voi samalla suorit taa laskutusta myös niistä palveluista, joita asiakas käyttää sen jälkeen, kun on 25 päässyt palveluja tarjoavaan verkkoon, esim. Internetiin. Asiakas voi pääte-laitteensa näytöltä nähdä samanaikaisesti sekä itse yhteyttä että käytettyjä palveluja koskevat laskutustiedot ja saada kaikki laskutustiedot eriteltyinä samassa jaksottaisessa (esim. kuukausittaisessa) laskussaan.
Järjestelmä pystyy myös hyödyntämään (esim. puhelinverkossa) jo • « 30 olemassa olevia laskutusjärjestelmiä, eikä vaadi tältä osin uusia ratkaisuja tai investointeja.
Kuvioluettelo
Seuraavassa keksintöä ja sen edullisia toteutustapoja kuvataan tar-35 kemmin viitaten kuvioihin 2...15 oheisten piirustusten mukaisissa esi- 6 104668 merkeissä, joissa kuvio 1 havainnollistaa ADSL Forumin määrittelemää yleistä verkko- mallia, kuvio 2 esittää erästä verkkoympäristöä, jossa keksinnön mukaista 5 menetelmää voidaan käyttää, kuviot 3a ja 3b esittävät keksinnön mukaista järjestelmää kuvion 2 mukaisessa verkkoympäristössä, kuviot 3c ja 3d esittävät vaihtoehtoja kuvioiden 3a ja 3b järjestelmille, kuvio 4 esittää tilaajapäätteen näytölle avautuvaa valintaikkunaa, 10 kuvio 5 havainnollistaa järjestelmän eri komponenttien välistä sano- manvaihtoa, kuvio 6 havainnollistaa tarkemmin liittymäpalvelimen ja reitittimen välistä toimintaa, kuvio 7a havainnollistaa päätelaitteen pääikkunaa, 15 kuvio 7b esittää asiakkaalle lähetettävää laskua, kuvio 7c havainnollistaa käyttäjälle syntyvää velkaa, kun kaikki maksut eivät saavu laskutuspalvelimelle, kuvio 7d esittää käyttäjälle syntyvää velkaa, kun laskutuspalvelimen ja päätelaitteen kellot käyvät eri tahdissa, 20 kuvio 8 havainnollistaa laskutustietueen rakennetta ja sisältöä, kuvio 9a esittää päätelaitteen rakennetta toiminnallisena lohkokaaviona, kuvio 9b tarkemmin 9a CDR-generaattorin rakennetta, kuvio 10 havainnollistaa laskutuspalvelimen rakennetta toiminnallise-25 na lohkokaaviona, kuvio 11 havainnollistaa liittymäpalvelimen rakennetta toiminnallisena lohkokaaviona, kuvio 12 havainnollistaa järjestelmän erääseen edulliseen lisäpiirtee-• seen liittyvää sanomanvaihtoa, 30 kuvio 13 havainnollistaa järjestelmän eri komponenttien välistä sano manvaihtoa, kun verkossa on käytössä mobile IP -protokolla, jolla mahdollistetaan IP-tason liikkuvuus, kuvio 14 havainnollistaa järjestelmän eri komponenttien välistä sanomanvaihtoa, kun verkossa on käytössä IPv6-protokolla, ja 35 kuvio 15 esittää erästä sellaista keksinnön mukaista järjestelmää, 7 104668 jossa tuetaan IP-tason liikkuvuutta.
Keksinnön yksityiskohtainen kuvaus
Seuraavassa keksinnön toimintaympäristöä kuvataan tarkemmin 5 viitaten kuvion 2 mukaiseen esimerkkiin, jossa kuvion 1 mukainen yleinen verkkomalli on toteutettu yksinkertaistettuna. Verkossa oletetaan olevan Inter-net-palveluja tarjoava operaattori ISP, jota kutsutaan tässä yhteydessä liittymäpalvelun (access service) tarjoajaksi. Tässä esimerkissä on esitetty vain yksi päätelaite, joka on tyypillisesti henkilökohtainen tietokone PC, joka on 10 varustettu verkkokortilla (esim. Ethernet-kortilla) ja kytketty lähiverkkokaapelin LC1 (esim. 10BaseT) kautta ADSL-modeemille A1, joka on puolestaan kytketty tavanomaisen tilaajajohdon SL kautta liittymäpalvelun tarjoajan tiloissa olevalle ADSL-modeemille A2. Tilaajajohtoina toimivat parikaapelit päättyvät puhelinoperaattorin keskukseen, joten maksimietäisyyden saavuttamiseksi 15 modeemin A2 on oltava keskuksessa.
Tässä tapauksessa oletetaan siis, että Internet-palveluja tarjoava operaattori on samalla puhelinoperaattori. POTS-suodatin mahdollistaa kuitenkin tilanteen, jossa puhelinoperaattori tarjoaa vain puhelinpalveluja ja vuokraa yhteyden toiselle palvelun tarjoajalle laajakaistaisten palvelujen taijoami-20 seksi. Tulevaisuudessa saattaa kilpailulainsäädäntö jopa pakottaa puhelinoperaattorit tällaiseen toimintaan, jos ne eivät itse tarjoa laajakaistapalveluja.
Kuvion 2 verkossa on siis loppukäyttäjän tiloissa oleva verkko PDN redusoitu päätelaitteen ja liittymäpalvelun tarjoajan väliseksi point-to-point-yhteydeksi. Modeemi A2 on kytketty lähiverkkokaapelin LC2 (esim. 10BaseT) 25 kautta palvelun tarjoajan LAN-kytkimelle SW, joka kytkee eri tilaajayhteydet liittymäpalvelun tarjoajan verkkoon APN, joka on kytketty yhdyskäytävänä toimivan reitittimen R1 kautta Internet-verkkoon. Liittymäverkon (access network) osuutta on kuviossa 2 merkitty viitemerkillä N1 ja palveluja taijoavaa ' ; ; ulkoista verkkoa viitemerkillä N2. Liittymäverkon voidaan myös ajatella olevan 30 verkon se osa, joka tarjoaa päätelaitteille liittymän verkon palveluja tarjoavaan osaan (joten myös reitittimen R1 voidaan ajatella olevan osa liittymäverkkoa).
Tässä esimerkissä siirretään siis ADSL-yhteyden yli Ethernet-kehyksiä ja modeemipari toimii siltana tilaajan LAN-segmenttien ja liittymäpalvelun tarjoajan LAN-segmenttien välissä. Käytännössä LAN-kytkin voi olla 35 malliltaan esim. Centillion 100, valmistaja Bay Network, USA tai Catalyst 3000, 8 104668 valmistaja Cisco Systems, USA.
Kuviossa 3a on havainnollistettu, kuinka keksinnön mukaista menetelmää sovelletaan kuvion 2 mukaisessa verkkoympäristössä. Loppukäyttäjän päätelaitteessa (joka on henkilökohtainen tietokone) on älykortin lukija CR ja 5 jokaisella asiakkaalla on oma älykorttinsa, jonka avulla asiakas (tilaaja) tunnistetaan. Päätelaitteessa on lisäksi ohjelmakirjasto, joka kommunikoi älykortin kanssa ja ohjelmisto, joka generoi yhteyden aikana tietyin välein (esim. minuutin välein) digitaalisella allekirjoituksella varustetun laskutustietueen ja lähettää sen verkkoon.
10 Liittymäpalvelun tarjoajan verkkoon APN on kytketty laskutuspalvelu WD, joka tarkastaa ja kerää päätelaitteiden generoimia laskutustietueita. Verkossa voi olla useita erillisiä laskutuspalvelua, mutta kullakin päätelaitteella on kuitenkin sille dedikoitu laskutuspalvelu. Laskutuspalvelulleen liittyy muisti MS (esim. magneettinauha), johon talletetaan kaikki ne laskutustietueet, 15 jotka laskutuspalvelu on hyväksynyt. Tietyin väliajoin siirretään kertyneet laskutustietueet laskutusjärjestelmään BS, joka on edullisesti yleisessä puhelinverkossa PSTN jo olemassa oleva laskutusjärjestelmä tai esim. olemassa olevan kaltainen laskutusjärjestelmä, joka on sijoitettu laajakaistaverkkoon. Kuviossa yleisellä tasolla esitetty verkko NW1, jonka kautta laskutuspalvelu on 20 kytketty laskutusjärjestelmään, voi siis olla yleinen puhelinverkko tai esim. jokin paketti- tai dataverkko. Intemet-palvelun laskuttamiseen tarkoitettujen järjestelmien yleistyessä on mahdollista käyttää myös tällaisia (Internetiin sijoitettuja) laskutusjärjestelmiä. Tätä vaihtoehtoa on kuviossa esitetty katkoviivalla. Las- « kutuspalvelin voi olla myös suoraan kytketty laskutusjärjestelmään. Ennen 25 laskutusjärjestelmään siirtoa laskutustietueet voidaan varastoida väliaikaisesti välivarastona toimivaan massamuistiin MS1, jonka merkitystä kuvataan jäljempänä.
Lisäksi liittymäpalvelun tarjoajan verkkoon on kytketty liittymäpalvelin SL, jonka tehtävänä on avata ja sulkea Intemet-yhteydet ohjaamalla reititin-30 tä/keskitintä R1, joka toimii palveluja tarjoavan verkon ja liittymäverkon (access network) yhdistävänä elimenä.
Järjestelmän edullisessa toteutustavassa siihen kuuluu myös sinänsä tunnettu DHCP-serveri (Dynamic Host Configuration Protocol) IP-osoitteiden allokoimiseksi dynaamisesti päätelaitteille. Dynaamisessa osoitteiden allokoin-35 nissa osoite palaa takaisin allokoitavien osoitteiden joukkoon, kun yhteys on 9 104668 katkaistu tai kun tietty ennalta määrätty osoitteen “vuokra-aika" on kulunut umpeen. (DHCP on kuvattu RFC:ssä R. Droms :Dynamic Host Configuration Protocol, RFC-1541, October 27, 1993.)
Laskutus- ja liittymäpalvelimet ovat edullisesti liittymäpalvelun tarjo-5 ajan tiloissa, eikä niiden tarvitse sijaita fyysisesti erillään, vaan ne voidaan integroida samaan koneeseen. Erityisesti laskutuspalvelu voi myös sijaita Internet-verkon puolella, varsinkin, jos laskutuspalvelimen omistaa erillinen organisaatio, joka tarjoaa laskutuspalveluja usealle eri liittymäpalvelun tarjoajalle. Loogisessa mielessä laskutuspalvelimen sijoituspaikalla ei ole merki-10 tystä, mutta käytännössä sijoituspaikan valintaan vaikuttavat mm. seuraavat tekijät. Ensinnäkin laskutuspalvelimen on edullista olla yleisen puhelinverkon yhteydessä tai lähellä sitä, jotta laskutuspalvelimella olisi mahdollisimman helppo pääsy puhelinverkossa jo olemassa olevaan laskutusjärjestelmään. Tehokkuuden kannalta on lisäksi oleellista, että päätelaitteen ja laskutuspalve-15 limen välinen yhteys on mahdollisimman nopea ja viive on hyvin hallittavissa (mikä ei ainakaan nykyään toteudu, jos laskutuspalvelu on esim. syvemmällä Intemet-verkossa). Koska järjestelmän tarkoituksena on lisäksi tarjota paikallista palvelua (maantieteellisesti rajatulla alueella) siten, että asiakkaille lähetetään esim. kuukausittain palvelulasku, ei ole mielekästä, että laskutuspalvelu 20 sijaitsisi kaukana asiakkaistaan.
Kuvioissa 2 ja 3a on POTS-suodatin (vrt. kuvio 1) jätetty esittämättä, koska POTS-suodatin voidaan myös integroida ATUun.
Kuviossa 3b on esitetty vaihtoehtoinen järjestelmä, joka vastaa muuten kuvion 3a järjestelmää, mutta liittymäpalvelun tarjoajan verkon APN ja 25 kytkimen SW välissä on reititin R2, joka on tässä tapauksessa se reititin, jota liittymäpalvelin ohjaa. Liittymän ohjauspiste (access control point) voi siten olla kumman tahansa reitittimen kohdalla. Reititin R2 reitittää päätelaitteilta tulevan liikenteen joko liittymäpalvelun tarjoajan verkossa oleville palvelimille tai reitit-timelle R1. On myös mahdollista, että liittymän ohjauspiste on molempien 30 reitittimien kohdalla. Tällainen tilanne voi olla esim. silloin, kun osa palveluista on liittymäverkossa ja osa muualla.
Kuvioissa 3c ja 3d on esitetty kaksi muuta vaihtoehtoista verkkoa. Kuvion 3c tapauksessa useita eri liittymäpalvelun tarjoajia on kytketty yhteiseen reitittimeen R1, joka on kytketty erillisen liittymäverkon ACN kautta sille 35 reitittimelle, jota liittymäpalvelin ohjaa. Kuvion 3d tapauksessa liittymäpalvelun 10 104668 tarjoajilla on omat reitittimensä (ei esitetty), joten niiden verkot on kytketty suoraan liittymäverkkoon.
Keksinnön erään edullisen toteutustavan mukaisesti sekä liittymäpal-velimen ja liittymän ohjauspisteen että liittymäpalvelimen ja laskutuspaivelimen 5 väliset siirtoyhteydet ovat varmennettuja siten, että tiedon yksityisyyden säilyttäminen on turvattu. Tämä voidaan toteuttaa joko fyysisesti käyttämällä ko. osien välillä dedikoitua siirtomediaa, johon muilla ei ole pääsyä (kaksipisteyhteydet) tai käyttämällä ko. osien välillä salauksella varustettua siirtokanavaa. Varmennettujen siirtoyhteyksien avulla estetään järjestelmän 10 tahallinen väärinkäyttö.
Seuraavassa kuvataan tarkemmin keksinnön mukaisen järjestelmän toimintaa viitaten kuvioihin 4-6. Selityksessä oletetaan järjestelmän olevan kuvion 3a mukainen.
Laskutus voi alkaa, kun käyttäjä työntää älykorttinsa päätelaitteeseen 15 kytkettyyn lukijaan. Tämän seurauksena päätelaitteella oleva ohjelma avaa päätelaitteen näytöllä ikkunan, jota kutsutaan valintaikkunaksi. Kuviossa 4 on havainnollistettu esimerkkiä valintaikkunasta. Ikkunan drop-down-listasta käyttäjä voi valita tarvitsemansa yhteyden tyypin. Yhteydet voidaan jakaa eri tyyppeihin esim. siten, että täydellisen Internet-liittymän lisäksi on muun tyyp-20 pisiä liittymiä, esim. jatkuva yhteys sähköpostipalvelimeen, jolloin käyttäjä saa tiedon tulleista sähköpostiviesteistä reaaliajassa. Viimemainittu palvelu voi olla huomattavasti halvempaa (esim. 5 mk/vrk) kuin täydellinen Intemet-liittymä. Tällaisia rajoitettuja yhteyksiä voi olla myös muualle kuin sähköpostipalvelimeen, esim. työpaikan lähiverkon palvelimelle. Valikosta käyttäjä voi lisäksi 25 valita vaikkapa haluamansa operaattorin tai valita salatun ja ei-salatun yhteyden välillä.
Valintaikkunan drop-down-listasta valittavissa olevat palvelut voidaan tallettaa päätelaitteelle tai älykortille, joten valintaikkuna voidaan avata ennen kuin päätelaite ottaa yhteyttä verkkoon. Vaihtoehtoisesti päätelaite voi ensin 30 hakea automaattisesti liittymäpalvelimelta, laskutuspalvelulta tai verkon muulta palvelimelta uusimman palveluluettelon heti sen jälkeen, kun käyttäjä on työntänyt älykorttinsa lukijalaitteeseen. Tämä vaihtoehto merkitsee hieman suurempaa viivettä, mutta toisaalta käyttäjällä on aina valittavanaan uusimmat palvelut ja lisäksi hän saa tietoonsa viimeisimmät hinnat. Valintaikkunan sisäl-35 tämät palveluvaihtoehdot voidaan myös päivittää automaattisesti yhteyden 11 104668 aikana, jolloin päätelaitteella (tai älykortilla) on aina tallessa ne palvelut, jotka olivat tarjolla viimeisimmän yhteysistunnon aikana.
Älykortille on talletettu tilaajan profiilitiedot, jotka ovat tässä esimerkkitapauksessa tilaajan nimi (esim. ascii-muodossa), tilaajan tunnistenumero, 5 tilaajan julkinen ja salainen avain sekä tilaajan laskun saldo. Julkinen avain on sekä luettavissa että käytettävissä kortilla. Salainen avain on sen sijaan ainoastaan käytettävissä (sitä ei pystytä lukemaan kortilta). Käytettävyys tarkoittaa sitä, että ko. avaimella voidaan tehdä ja tarkastaa digitaalinen allekirjoitus, eli salata ja purkaa tietoja. Laskun saldo on se summa, jonka kyseinen tilaaja on 10 maksanut (tämä summa voidaan nollata milloin tahansa, joten se ei ole sama kuin oikean laskun loppusaldo eli se toimii vain referenssinä päätelaitteen käyttäjälle. Lisäksi älykortille voidaan tallettaa esim. laskutuspalvelimen julkinen avain, jotta voidaan varmistaa, että viestit todellakin tulevat laskutuspalve-limelta.
15 Tilaajan tiedot, kuten nimi, tunniste ja salainen avain voidaan tallettaa älykortin sijasta myös päätelaitteen muistiin (esim. tietokoneen kovalevylle tai disketille), mikäli tietoturvan heikkeneminen hyväksytään.
Kuviossa 5 on havainnollistettu järjestelmän eri komponenttien välistä kommunikointia. Kun käyttäjä klikkaa valintaikkunan kytke-painiketta, pääte-20 laitteen ohjelmisto lähettää palvelupyyntösanoman lnit_Service liittymäpalveli-melie SL (kuvio 5). Palvelupyyntösanoma sisältää ainakin päätelaitteen sen hetkisen IP-osoitteen (ClientAddr) ja em. valikosta valitun palvelun tyypin (Type). Liittymäpalvelin tarkastaa sanoman ja lähettää edelleen sanoman START laskutuspalvelimelle WD. START-sanoma käsittää käyttäjän sen 25 hetkisen IP-osoitteen (ClientAddr), sen osoitteen, jolle halutaan tieto siinä vaiheessa, kun käyttäjä lopettaa maksamisen (ServerAddr), palvelun tunnisteen (Serviceld), liittymäpalvelimen tunnisteen (Serverld) ja (väliaikaisen) tunnisteen (Connld), jonka avulla tunnistetaan palvelimien välisellä yhteydellä : eri sanomatyypit (START sekä sanomat OK ja CANCEL, joita kuvataan jäi- 30 jempänä). Sanomia lnit_Service ja START kutsutaan tässä yhteydessä aloi-tussanomiksi, joilla indikoidaan kertaluonteisen liittymäpalveluistunnon alkaminen liittymäpalvelimelle ja laskutuspalvelimelle.
Laskutuspalvelu WD muodostaa vastaanottamiensa tietojen perusteella tietyn tyyppisen laskutustietueen (CDR, Charging Data Record), joka 35 sisältää liittymäistuntoa koskevat sopimustiedot, mm. ko. istunnolle annetun 12 104668 sopimusnumeron, joka identifioi tämän liittymäpalveluistunnon. Tämän lasku-tustietueen rakenne ilmenee jäljempänä olevasta kuvauksesta, joka koskee kaikkien laskutustietueiden rakennetta. Tämän aloittavan laskutustietueen (sopimus-CDR) laskutuspalvelu lähettää päätelaitteelle (nuoli A, kuvio 5).
5 Päätelaite palauttaa sopimusta koskevan laskutustietueen takaisin laskutus-palvelimelle, kuitenkin varustettuna digitaalisella allekirjoituksella (kuvio 5, nuoli B). Digitaalisella allekirjoituksella tarkoitetaan tunnettua avainpariin perustuvaa salausalgoritmia, jossa salaus suoritetaan salaisella avaimella, jolloin kuka tahansa voi purkaa viestin julkisella avaimella. Tällä tavoin ei siis saavuteta 10 viestin luottamuksellisuutta, mutta voidaan olla varmoja, että viesti on tullut oikeasta lähteestä. Lähettäjä ei siis voi kieltää lähettäneensä viestiä. Digitaalisessa allekirjoituksessa ei yleensä salata koko viestiä, vaan ainoastaan viestistä muodostettu “tiiviste” (digest), joka on eräänlainen tarkistussumma. Tämä "tiiviste” on kuitenkin salausteknisesti erittäin vahva, eikä ulkopuolinen pysty 15 luomaan viestiä, joka tuottaisi samanlaisen identtisen “tiivisteen”. Lähettäjän salaisen avaimen avulla salataan “tiiviste” ja aikaleima, jolloin näistä muodostuu digitaalinen allekirjoitus. Allekirjoituksen toteuttamisessa on monia erilaisia, tunnettuja vaihtoehtoja. Koska keksintö ei kuitenkaan liity allekirjoitukseen, ei sen toteuttamista kuvata tässä yhteydessä tarkemmin. Kiinnostunut lukija 20 löytää tarkempaa tietoa monista alaa kuvaavista teoksista. (Esim. Schneier, Applied Cryptography, ISBN 0-471-11709-9, Wiley & Sons, 1996.) Päätelaite voi suorittaa sopimus-CDR:n allekirjoituksen (sopimuksen hyväksymisen) automaattisesti, kuten edellä kuvattiin, tai päätelaite voi, saatuaan sopimus-CDR:n laskutuspalvelimelta, aukaista näytölleen esim. erillisen 25 sopimusikkunan, jossa kysytään vielä käyttäjän hyväksymistä liittymäpalvelu-sopimukselle. Kun käyttäjä klikkaa ikkunan hyväksymispainiketta, päätelaite lähettää allekirjoitetun sopimus-CDR:n laskutuspalvelimelle.
Vastaanotettuaan allekirjoituksella varustetun sopimus-CDR:n laskutuspalvelu WD suorittaa sinänsä tunnetulla tavalla allekirjoituksen tarkastuk-30 sen todentaakseen CDR:n oikeellisuuden. Tätä varten laskutuspalvelu hakee tilaajatietokannastaan ko. asiakkaan julkisen avaimen (nuoli C).
Oikean julkisen avaimen löytyminen voidaan hoitaa monella eri tavalla. Ensinnäkin, päätelaite voi, saadessaan sopimus-CDR:n allekirjoitusta varten, hakea asiakkaan (tilaajan) nimen ja tunnistenumeron älykortilta ja liittää 35 ko. tiedot allekirjoitettuun sopimus-CDR:ään, jonka se lähettää laskutuspalve- 13 104668 limelle. Laskutuspalvelin käyttää tunnistenumeroa hakiessaan oikean julkisen avaimen tilaajatietokannastaan. Toinen vaihtoehto on, että laskutuspalvelin identifioi asiakkaan henkilöllisyyden ja oikeuden käyttää järjestelmää ennen sopimus-CDR:n muodostamista. Kun laskutuspalvelin vastaanottaa liittymä-5 palvelimelta START-sanoman, se lähettää autentikointipyynnön (ei esitetty kuviossa) START-sanoman sisältämään IP-osoitteeseen. Päätelaite sisällyttää vastaukseensa asiakkaan tunnistenumeron lisäksi mahdollisesti muuta asiakaskohtaista tietoa, varustaa vastauksen allekirjoituksella ja lähettää allekirjoitetun vastauksen laskutuspalvelulle. Tämän vaihtoehdon etuna on, että 10 laskutuspalvelin tietää asiakkaan identiteetin ennen sopimuksen muodostamista, jolloin on mahdollista muodostaa asiakaskohtaisesta räätälöityjä sopimuksia (esim. eri hinnat eri asiakkaille). Varjopuolena on luonnollisestikin kahden ylimääräisen sanoman tarve, mikä hidastaa yhteyden muodostamista. Kolmas vaihtoehto on, että päätelaite sisällyttää asiakkaan tunnistenumeron jo 15 lnit_Service-sanomaan ja liittymäpalvelin välittää tunnistenumeron edelleen laskutuspalvelulle START-sanomassa. Tässä toteutustavassa tietää siis sekä laskutuspalvelin että liittymäpalvelin asiakkaan tunnistenumeron. Tämä voi olla epäkohta, mikäli laskutuspalvelin ja liittymäpalvelin kuuluvat eri organisaatioille. Tämä mahdollinen epäkohta voidaan “korjata” seuraavasti. Asiak-20 kaan tunniste koostuu kahdesta osasta. Ensimmäinen osa identifioi asiakkaan alkuperän (eli asiakkaan oman laskutuspalvelimen). Tätä osaa käytetään START-sanoman reitittämiseen kyseiselle omalle laskutuspalvelimelle. Toinen osa on salattu asiakkaan oman laskutuspalvelimen julkisella avaimella, joten * sitä liittymäpalvelin ei tunnista. Asiakkaan tunniste voidaan myös tehdä näyt-25 tämään erilaiselta jokaisella palvelukerralla, esim. liittämällä se yhteen vakio-pituisen merkkijonon kanssa, joka muuttuu jokaisella palvelukerralla erilaiseksi, esim. kellonajan mukaan. (Asiakkaan tunniste koostuu siis aluekoodista ja allekirjoituksesta. Aluekoodia tarvitaan, jos ADSL-liittymien käyttäjillä on sopimuksia eri (useiden) laskutuspalvelun tarjoajien kanssa.) 30 Hyväksymänsä sopimus-CDR:n laskutuspalvelin tallettaa laskutus- tietokantaansa (nuoli D) tietyksi ajaksi siltä varalta, että asiakkaalla on myöhemmin huomautettavaa ko. palvelusta. Tämän jälkeen laskutuspalvelin pyytää liittymäpalvelinta luovuttamaan asiakkaalle pääsyn verkkoon (nuoli E) lähettämällä liittymäpalvelimelle sanoman OK, joka sisältää em. tunnisteen 35 (Connld), jolla tunnistetaan yhteyden sanomat ja palveluistunnolle annetun 14 104668 sopimusnumeron (Contractld). Liittymäpalvelin ohjaa puolestaan reititintä R1 sallimaan asiakkaan pääsyn (Internet-)verkkoon. Tätä prosessia on kuvattu kuviossa 5 nuolella F ja sitä kuvataan tarkemmin jäljempänä kuvion 6 yhteydessä.
5 Tämän jälkeen käyttäjällä on pääsy verkkoon. Tätä vaihetta, jolloin käyttäjä käyttää verkon tarjoamia palveluja, kuvataan tarkemmin jäljempänä.
Mikäli laskutuspalvelu ei hyväksy laskutustietuetta (esim. allekirjoitus on väärä), se lähettää sanoman OK sijasta sanoman CANCEL, joka sisältää samat kentät kuin sanoma OK, joskaan sopimusnumeroa ei tässä vaiheessa 10 tarvita, koska käyttäjälle ei anneta pääsyä verkkoon.
Kun yhteys puretaan käyttäjän lopetettua yhteyden käytön, lähetetään myös samanlainen CANCEL-sanoma (nuoli G), mutta koska yhteys tässä tapauksessa purkautuu normaalisti, on myös sanoman sisältämää sopimus-numeroa käytettävä. CANCEL-sanomat ovat siis rakenteeltaan samanlaisia, 15 mutta niitä käytetään eri tavalla riippuen siitä, missä vaiheessa yhteyttä ne tulevat. Liittymäpalvelin voi sulkea yhteyden myös jostakin muusta syystä, esim. kuormitussyistä (esim. tilanteessa, jossa tärkeimmille yhteyksille on varattava kapasiteettia voidaan vähemmän tärkeitä joutua sulkemaan), tai laskutuspalvelu voi pyytää liittymäpalvelinta sulkemaan yhteyden jostakin 20 muusta syystä, esim. kuormitussyistä tai tilanteessa, jossa laskutustietueita ei vastaanoteta hyväksyttävällä tavalla.
Päätelaitteen lähettämä aloitussanoma on mahdollista lähettää myös suoraan laskutuspalvelulle. Lähettämällä aloitussanoma päätelaitteelta ensin liittymäpalvelimelle, voidaan laskutuspalvelinrajapinta kuitenkin toteuttaa 25 kaikille palvelun tarjoajille samanlaisena, joten laskutuspalvelu pystyy hoitamaan liittymäpalvelimen lisäksi myös muiden palvelun tarjoajien laskutusta. Mikäli reititin on ominaisuuksiltaan sellainen, että se pystyisi havaitsemaan tietystä lähdeosoitteesta alkavan liikenteen ja ilmoittamaan siitä liittymäpalvelimelle, ei päätelaitteen lähettämää aloitussanomaa tarvittaisi lainkaan 30 (aloitussanoma tulisi siis reitittimeltä).
Kuviossa 6 on havainnollistettu tarkemmin liittymäpalvelimen ja reitittimen välistä kommunikointia yhteyden avausvaiheessa (kuvio 5, nuoli F). Tässä esimerkkitapauksessa oletetaan, että liittymäpalvelimen ja reitittimen välinen yhteys on tunnettu Telnet-yhteys, koska SNMP-protokollan (Simple 35 Network Management Protocol) avulla ei toistaiseksi ole mahdollista päivittää 15 104668 ko. reitittimen yhteyslistoja.
Liittymäpalvelin SL ohjaa reitittimen R1 sitä rajapintaa, jonka kautta käyttäjällä on yhteys Internetiin. Reitittimeen on talletettu liittymälista AL, joka voi käsittää kuvion 6 mukaisesti esim. viisi saraketta siten, että ensimmäinen 5 kertoo niiden päätelaitteiden IP-lähdeosoitteet (ClientAddr), jotka pääsevät ko. rajapinnasta ulos Internetiin, toinen sarake kertoo em. yhteystunnisteen (Connld), kolmas sarake sopimusnumeron (Contractld), neljäs sarake sisään-tulleiden pakettien lukumäärän ja viides sarake lähteneiden pakettien lukumäärän. Rajapinnan kumpaakin siirtosuuntaa varten voi olla samanlainen lista. 10 Kun liittymäpalvelin SL on vastaanottanut laskutuspalvelulta sano man OK, se lähettää reitittimelle ensin komennon, jolla tyhjennetään liittymä-lista. Tätä komentoa on merkitty viitemerkillä CLEAR_AC. Tämän jälkeen liittymäpalvelin lähettää komennon, joka sallii Internet-protokollan kaikkien ohjausviestien läpimenon (PERMITJCMP). Mikäli laskutuspalvelu ja/tai liitty-15 mäpalvelin ovat reitittimen R1 Internetin puolella, liittymäpalvelin lähettää sen jälkeen komennot, jotka mahdollistavat kaikki yhteydet laskutuspalvelimeen ja/tai liittymäpalvelimeen (PERMIT_WD ja/tai PERMIT_SL). Lopuksi liittymä-palvelin lähettää komennon, joka sallii tietyn päätelaitteen pääsyn rajapinnan läpi. Näitä komentoja lähetetään yksi jokaista käynnissä olevaa yhteyttä kohti 20 (PERMIT_ADDR1...PERMIT_ADDRN). Komentojen seurauksena reititin päivittää liittymälistan. Jokaisen uuden yhteyden kohdalla suoritetaan samanlainen päivitys. Toisin sanoen, ensin tyhjennetään koko lista ja sen jälkeen lista kirjoitetaan uudelleen, jolloin samalla lisätään uusi päätelaite listalle.
m
Liittymälistan päivitystä varten laskutuspalvelu lähettää niiden pääte-25 laitteiden osoitteet, jotka ko. hetkellä maksavat pääsystä palveluja tarjoavaan verkkoon, tai ainakin muutostiedot edelliseen liittymälistaan nähden.
Kun käyttäjä lopettaa yhteyden käytön, laskutuspalvelu lähettää liittymäpalvelimelle CANCEL-sanoman (kuvio 5, nuoli G). Tämän seurauksena ' liittymäpalvelin päivittää liittymälistan edellä kuvatulla tavalla niin, että kyseinen < 30 käyttäjä poistetaan päivityksen yhteydessä listalta. Tätä prosessia on merkitty nuolella H kuviossa 5.
Jos yhteyksiä muodostuu ja niitä puretaan nopeassa tahdissa siten, että listan ylläpito on edellä kuvatulla tavalla liian hidasta, reititin voi tallettaa useita päivitystapahtumia ja ottaa kaikki päivitystapahtumat kerralla mukaan 35 uudelle liittymälistalle.
16 104668 Käytännössä edellä kuvattua prosessia voidaan käyttää esim. CIS-COn reititinmallissa 7000, joka on varustettu esim. IOS 11.2-käyttöjärjestelmällä. Kuten edellä jo viitattiin, reitittimiin on jatkossa todennäköisesti tulossa ominaisuuksia, joiden avulla liittymälista voidaan päivittää 5 tehokkaammin, jolloin muutokset pystytään tekemään vain niihin kohtiin, joissa niitä tarvitaan.
Kun yhteys on saatu avattua, päätelaitteelta voidaan käyttää Internetin tarjoamia palveluja. Pitääkseen yhteyden auki päätelaite generoi tasaisin väliajoin laskutustietueita, lähettää ne älykortille digitaalista allekirjoitusta 10 varten ja lähettää allekirjoitetun laskutustietueen edelleen tilaajajohdon kautta laskutuspalvelulle, joka tallettaa hyväksytyt laskutustietueet laskutustieto-kantaansa.
Kun käyttäjällä on pääsy reitittimen R1 kautta Internet-verkon palveluihin, hän voi palveluselaintaan käyttämällä (joka voi olla esim. jokin tunnettu 15 WWW-selain) etsiä sopivia palveluja Internetistä ja solmia muita sopimuksia kyseisten palvelun tarjoajien kanssa. Löytäessään sopivan palvelun, kuten tilausvideopalvelun, asiakas valitsee ko. palvelun esim. klikkaamalla ko. vaihtoehtoa.
Kun asiakas on suorittanut valintansa, palvelun tarjoajan palvelin 20 lähettää laskutuspalvelulle WD ko. elokuvan identifioivan palvelutunnisteen sekä kyseistä tilaajaa vastaavan tunnisteen, jonka se saa selville esim. asiakkaan selainohjelmalta vastaanottamiensa sanomien lähdeosoitteen (esim. TCP-yhteyden socket-osoite) perusteella.
Tämän jälkeen laskutuspalvelu WD käynnistää prosessin, joka hoitaa 25 kyseisen palvelun käyttöä. Aluksi laskutuspalvelu hakee palvelutietokannaltaan kyseistä palvelua vastaavat parametrit ja lähettää päätelaitteelle sopimus-CDR:n, joka sisältää ko. palveluistunnon aikana käytettävät laskutusparametrit sekä sopimusnumeron. Saatuaan tällaisen palvelun aloittavan laskutustietueen päätelaitteella oleva ohjelma avaa päätelaitteen näytöllä ikkunan, jota 30 kutsutaan jatkossa sopimusikkunaksi. Ikkunassa on esitetty laskutuspalveli-melta vastaanotettujen tietojen perusteella perustiedot eri osapuolista sekä ko. palvelusta. Lisäksi ikkunassa esitetään sopimusnumero, joka identifioi tämän yhden palveluistunnon. Tämä sopimus kattaa siis vain tietyn palvelun, esim. yhden elokuvan seuraamisen ja se on liittymäpalveluun nähden täysin erillinen 35 palvelu. Liittymäpalvelun laskutuksen rinnalla suoritetaan siis samanaikaisesti 17 104668 laskutusta muista palveluista. Tämä laskutus voi tapahtua esim. palvelun sisällön perusteella.
Päätelaitteen pääikkunassa (kuvio 7a) esitetään kaikki kullakin hetkellä käynnissä olevat sopimukset. Koska Intemet-palveluista suoritettava, 5 palvelun sisältöön perustuva laskutus ei kuulu varsinaiseen keksinnölliseen ajatukseen, ei sitä kuvata tässä yhteydessä tarkemmin. Tätä laskutusta on kuvattu tarkemmin hakijan aikaisemmassa Fl-patenttihakemuksessa 964524 (salainen esillä olevan hakemuksen jättöhetkellä).
Laskutuspalvelu tarkistaa jokaisen laskutustietueen alkuperän käyt-10 täen ko. asiakkaan (tilaajan) julkista avainta sekä tallettaa hyväksymänsä laskutustietueet laskutustietokantaansa. Jokainen päätelaitteelta laskutuspal-velimelle lähetettävä CDR edustaa yhteyslaskutusta tietyltä aikaväliltä ja sisältää sopimusnumeron, jonka avulla eri palvelut erotetaan toisistaan. Koska järjestelmän eri käyttäjät eivät voi samanaikaisesti käyttää samaa päätelaitetta, 15 pysyvät samasta lähdeosoitteesta tulevien laskutustietueiden allekirjoitukset samoina yhden liittymäistunnon aikana. Kaikki tällaiset tietueet kootaan yhteen tilaaja- ja sopimusnumerokohtaisesti. Kunkin palvelun (esim. liittymäpalvelun) osalta kokonaislaskutus saadaan selville laskemalla yhteen laskutettavat määrät kaikista laskutustietueista, jotka liittyvät samaan sopimusnumeroon.
20 Laskutuspalvelimen laskutustietokannasta CDR:t siirretään ajoittain laskutusjärjestelmään BS (kuvio 3), jossa niistä muodostetaan sinänsä tunnetulla tavalla laskuja, jotka toimitetaan asiakkaalle. Yksi lasku sisältää listan ja veloitukset kaikista niistä palveluista, joita asiakas on käyttänyt laskutusjakson (esim. kuukauden) aikana. Lasku voidaan toimittaa paperikopiona postitse tai 25 se voidaan toimittaa päätelaitteelle elektronisessa muodossa. Kuviossa 7b on havainnollistettu erästä asiakkaalle lähetettävää laskua. Lasku sisältää tilaajatiedot ja sekä listan laskutusjakson aikana käytetyistä palveluista. Kustakin palvelusta voidaan laskussa esittää esim. palvelun tyyppi, palvelun tarjoaja, ' sopimusnumero, jolla palvelu vastaanotettiin, palvelun aloitusaika ja kesto - « 30 sekä hinta.
Koska laskutusjärjestelmän toiminta on sinänsä tunnettua, ei sitä kuvata tässä yhteydessä tarkemmin.
Järjestelmässä käytettyjä laskutustietueita (laskutussanomia) voi olla esim. yhdeksää eri tyyppiä (0...8) seuraavasti: 35 0. Sopimus: Tämä on aloittava laskutustietue (nuoli A, kuvio 5), jonka 10 104668 18 laskutuspalvelin lähettää (allekirjoittamattomana) asiakkaalle ja jonka päätelaite palauttaa allekirjoitettuna laskutuspalvelulle, mikäli asiakas hyväksyy sopimuksen.
1. Maksu: Tätä tyyppiä olevat laskutustietueita lähetetään asiakkaan 5 päätelaitteelta allekirjoitettuina sopimusistunnon aikana laskutuspalvelulle, joka tarkistaa ne.
2. Loppu: Tämän tyyppinen CDR vastaa muuten tyyppiä 1, mutta se sisältää lisäinformaationa sen, että se on viimeinen CDR, jonka päätelaite lähettää kulumassa olevan sopimusistunnon aikana. Kun käyttäjä lopettaa itse 10 palvelun painamalla Lopeta-painiketta, lähetetään ensin tyyppiä 1 oleva CDR ja sen jälkeen tyyppiä 6 oleva CDR. Tällä tavoin laskutuspalvelin pystyy erottamaan käyttäjän suorittaman lopetuksen palvelun normaalista loppumisesta (kuten elokuvan loppumisesta). Tämän tyyppistä tietuetta voidaan käyttää myös kertatyyppiseen laskutukseen.
15 3. Pulssi: Tämän tyyppinen CDR lähetetään laskutuspalvelimelta päätelaitteelle. Tarkoituksena on ilmoittaa päätelaitteelle, että sen tulisi lähettää uusi CDR, mikäli palvelua aiotaan jatkaa. Mikäli päätelaite ei lähetä kelvollista CDR:ää tietyn ajan kuluessa, laskutuspalvelin lähettää keskeytyssano-man palvelun tarjoajan palvelimelle.
20 4. Puuttuva järjestysnumero: Lähetetään laskutuspalvelimelta pääte laitteelle (jatkuvan laskutussopimuksen aikana) ilmoittamaan, että tietyn järjestysnumeron omaava CDR ei ole saapunut laskutuspalvelimelle tai saapunut CDR oli kelvoton. Tällöin päätelaitteellä on tilaisuus suorittaa uudelleenlähetys tilanteen korjaamiseksi. Kumpikaan osapuoli ei kuitenkaan välttämättä tarvitse 25 tällaista funktionaalisuutta. Mikäli päätelaite ei vastaa tällaiseen CDR:ään, paras vaihtoehto on, että laskutusjärjestelmällä ei ole oikeutta laskuttaa menetetyn CDR:n osuutta.
5. Modifioitu sopimus: Tämän tyyppinen CDR lähetetään laskutuspal-| velimelta asiakkaalle ja se vastaa muuten tyypin 0 laskutustietuetta, mutta 30 sopimusnumero ei ole uusi, vaan sama kuin sillä hetkellä käytettävällä lyhytaikaisella sopimuksella. Tämä laskutustietue lähetetään keskellä palveluistuntoa merkiksi siitä, että laskutusparametrit ovat muuttuneet. Päätelaite voi esim. hyväksyä uuden sopimuksen automaattisesti, mikäli hinta on laskenut, muussa tapauksessa voidaan edellyttää asiakkaan suorittamaa hyväksyntää.
35 6. Keskeytys: Tämän tyyppinen CDR voidaan lähettää kummassa 1β 104668 suunnassa tahansa indikoimaan sitä, että sopimus lopetetaan. Lähettäjä suorittaa CDR:n allekirjoituksen.
7. Digitaalinen raha: Laskutusjärjestelmää on mahdollista hyödyntää niinkin, että tiettyyn maksuun liittyvä CDR (tyyppi 1 tai 2) sisältää maksun 5 digitaalisena rahana. Laskutuspalvelu ei kuitenkaan siirrä digitaalista rahaa laskutusjärjestelmään, vaan siirtää ne suoraan esim. pankin palvelimelle (aina kerättyään tietyn, suhteellisen pienen summan digitaalista rahaa) tai muun organisaation ylläpitämälle verkon palvelimelle, joka suorittaa veloituksen suoraan asiakkaan tililtä. Digitaalista rahaa voidaan käyttää keskitetyn lasku-10 tusjärjestelmän BS ohella tavanomaisen elektronisen kaupankäynnin tapaan tai vaihtoehtoisena toteutustapana keskitetyn laskutusjärjestelmän sijasta.
8. Laskutuksen tahdistus: Lähetetään laskutuspalvelulta päätelaitteelle (jatkuvan laskutussopimuksen aikana) ilmoittamaan, että maksu-CDR:t eivät kata jatkuvan sopimuksen minuuttitaksaa (esim. päätelaitteen kello käy 15 liian hitaasti). Tahdistus-CDR:n mukana tulee tieto siitä, kuinka paljon pitää maksaa lisää, jotta sopimus pysyisi käynnissä.
Kuviossa 5 on havainnollistettu laskutusta yhden palvelun osalta. Kunkin sanoman tyyppi on merkitty sanomaa merkitsevän nuolen yläpuolelle. Kuviossa on esitetty tapaus, jossa laskutuspalvelu havaitsee kerran palvelun 20 aikana, että tietty laskutustietue puuttui välistä.
Riippuen siitä, suoritetaanko päätelaitteessa samanaikaisesti paljon muita prosesseja, voi kahden peräkkäisen, tyyppiä 1 olevan CDR:n välinen . aika vaihdella. Mikäli kuormitus päätelaitteessa kasvaa suureksi ja CDR:n generointi myöhästyy nimellisarvostaan, on CDR:n sisältämä veloitus vastaa-25 vasti suurempi.
Käytännössä jatkuvaan laskutukseen liittyy kaksi aikaan liittyvää ongelmaa. Ensiksikin, vian tai virheen seurauksena saatetaan yksi tai useampi maksu-CDR menettää. Toiseksi, päätelaitteen kello saattaa käydä hitaammin * ' kuin laskutuspalvelimen kello. Näiden ongelmien eliminoimiseksi määritellään 30 kaksi kynnysarvoa (A ja B). Ensimmäinen kynnysarvo (A) on suurin velka, joka käyttäjällä voi olla laskutuspalvelulle vielä maksamattomana olevan käytön seurauksena. Toinen kynnysarvo (B) on maksun jälkeisen velan suurin sallittu arvo. Kumpaankin raja-arvoon liittyy oma ajastinarvonsa (TA ja TB).
Kuvioissa 7c ja 7d on havainnollistettu em. ongelmien ratkaisua. Aika-35 akseli t kuvaa laskutuspalvelimen aikaa ja aika-akseli t1 päätelaitteen aikaa.
20 104668
Kuvioissa aika on esitetty sekunteina. Pystyakselilla kuvion yläosassa on kuvattu käyttäjän velkaa laskutuspalvelulle, kun taas kuvion alaosassa on esitetty laskutuspalvelimen ja päätelaitteen lähettämiä laskutustietueita. Kuvioissa on oletettu, että verkon viive on mitätön. Kuviossa 7c kellot käyvät yhtä 5 nopeasti, mutta kuviossa 7d päätelaitteen kello käy hitaammin kuin laskutus-palvelimen kello. Hetkellä t1=0 päätelaite lähettää allekirjoitetun sopimuksen (CDR-0) laskutuspalvelulle. Laskutuspalvelu vastaanottaa sopimuksen hetkellä t=0. Käyttäjän velka D(t) alkaa kasvaa tästä hetkestä lukien. Kun maksuja ei tule, velka kasvaa lineaarisesti ajan suhteen. Velan kasvunopeus 10 (rahayksikköä aikayksikköä kohti) on määritelty sopimuksessa. Kun laskutus-palvelin vastaanottaa maksu-CDR:n (CDR-1), velka pienenee ko. CDR:n ilmoittaman määrän verran.
Sopimuksen vastaanottamisen jälkeen laskutuspalvelu laskee pe-riodisesti (esim. kerran sekunnissa) velan arvon. Jos D(t) > A, laskutuspalvelu 15 lähettää päätelaitteelle tyyppiä 4 olevan CDR:n. Jos laskutuspalvelu ei vastaanota puuttuvaa maksua ajan TA kuluessa, se purkaa sopimuksen. Kuviossa 7c on esitetty tilanne, jossa hetkellä t1=120 lähetetty maksu-CDR (CDR-1) ei saavu perille. Tämän takia velka ylittää kynnysarvon A ennen seuraavaa säännöllistä maksua. Laskutuspalvelu lähettää päätelaitteelle tyyppiä 4 olevan 20 CDR:n ja päätelaite lähettää vasteena maksu-CDR:n uudelleen. Voidaan lisäksi määritellä suurin aika, jonka laskutuspalvelu voi olla ilman maksu-CDR:iä. Jos tämä aika kuluu umpeen, laskutuspalvelu lähettää tyyppiä 4 . olevan CDR:n.
Laskutuspalvelu tarkistaa velan määrän ainakin jokaisen säännön-25 mukaisen maksun jälkeen. Mikäli päätelaitteen kello käy hitaammin kuin laskutuspalvelimen kello, kuten on esitetty kuviossa 7d, kasvaa maksun jälkeisen velan määrä maksu maksulta. Kun maksun jälkeisen velan määrä ylittää kynnysarvon B, laskutuspalvelu lähettää päätelaitteelle tyyppiä 8 (tahdistus) olevan CDR:n, joka sisältää tiedon halutun maksun suuruudesta. Päätelaite 30 lähettää vasteena allekirjoitetun tahdistus-CDR:n. Mikäli laskutuspalvelu ei vastaanota puuttuvaa maksua ajan TB kuluessa, se purkaa sopimuksen.
Kaikki järjestelmässä tarvittava laskutusinformaatio siirretään proto-kollasanomien (eli laskutustietueiden) peräkkäisissä kentissä. Kuviossa 8 on esitetty laskutustietueissa käytettävät kentät: 35 TYYPPI: Kertoo CDR:n tyypin eli mikä yllä kuvatuista kahdeksasta 21 104668 laskutustietueesta on kysymyksessä.
PITUUS: Pituuskenttä kertoo CDR:n kokonaispituuden tavuina, mukaan lukien tyyppi- ja pituuskentät.
SOPIMUSNUMERO: Tämä kenttä sisältää laskutuspalvelujen anta-5 man kokonaisluvun, joka on sama kaikille CDR-tietueille, jotka liittyvät samaan laskutusistuntoon.
JÄRJESTYSNUMERO: Kokonaisluku, joka kertoo CDR:ien keskinäisen generointijärjestyksen saman laskutusistunnon aikana. Päätelaite antaa takaisin palauttamalleen sopimus-CDR:lle (tyyppi 0) numeron nolla, minkä 10 jälkeen se kasvattaa numeroa yhdellä jokaista CDR:ää kohti. Tämä kenttä on määrittelemätön CDR-tyypeissä 3, 5, 6 ja 7 ja tyypissä 4 se indikoi puuttuvan CDR.n järjestysnumeroa.
PALVELUTUNNISTE: Tämän kentän sisältö kertoo, mistä palvelusta laskutetaan. Kenttässä oleva parametri saa arvon laskutuspalvelun tarjoajan ja 15 (multimedia)palvelun tarjoajan välisen sopimuksen seurauksena.
PALVELUTYYPPI: Tämä kentän sisältämä parametri luokittelee palvelut karkeasti eri luokkiin tilastollisia tarkoituksia varten, esim. WWW-sivut, tilausvideo, tiedostonsiirto, jne.
ALOITUSAIKA: Kentässä oleva parametri osoittaa kulumassa olevaa 20 aikaa CDR-tyypeissä 0 ja 5 sekä 3, 4 ja 6 sekä laskutusjakson aloitusaikaa tyypeissä 1 ja 2.
LOPETUSAIKA: Kentän parametri määrittelee laskutusistunnon päättymisen tyyppiä 1 ja 2 olevissa CDR:issä. Tyyppiä 0 ja 5 olevissa CDR:issä kentän parametri määrittää, kuinka usein laskutuspalvelu odottaa 25 maksu-CDR:ää. Muun tyyppisissä CDR:issä tätä parametriä ei ole määritelty.
TUNNISTEET: Tämän kentän parametri kertoo asiakkaan, laskutus-palvelimen ja palvelimen tunnisteet. Tunnisteet voivat olla kokonaislukuja tai verkko-osoitteita, mutta niiden täytyy olla uniikkeja laskutusjärjestelmän sisällä.
MAKSUTAPA: Kentän sisältämän parametri on määritelty tyyppiä 0, 30 5, 1 ja 2 oleviin CDR:iin. Maksutavat voidaan luokitella esim. seuraavasti.
ilmainen, kertaveloitus (yhdellä CDR:llä), periodinen tai ulkoa laukaistava, eli esim. päätelaitteen toinen prosessi voi suorittaa laukaisun. Esim. päätelaitteen videotoistimen ohjelma voi laukaista CDR:n generoinnin vaikkapa minuutin välein, jos viimeisen kuluneen minuutin aikana on vastaanotettu kelvollista 35 videosignaalia. Jäljempänä kuvataan myös toteutusta, jossa laskutuspalvelu 22 104668 laukaisee CDR:n generoinnin maksutapakentän parametrin avulla.
RAHAMÄÄRÄ: Tämä kenttä kertoo asiakkaalle syntyneen velan (joko koko istuntoa kohden tai kahden CDR:n väliseltä ajalta).
LIIKENNEDATA: Kenttä sisältää päätelaitteessa olevalta ulkoiselta 5 sovellukselta päätelaitteelle lähetettävää informaatiota, joka lähetetään edelleen verkkoon.
ALLEKIRJOITUS: Tämä kenttä sisältää asiakkaan digitaalisen allekirjoituksen, jota käytetään CDR:n oikeellisuuden todentamiseen.
Oheisessa liitteessä 1, joka sisällytetään tähän hakemukseen on 10 kuvattu tarkemmin CDR.ien rakenne käyttäen ASN.1-notaatiota (Abstract Syntax Notation 1), joka on tietoliikennealalla yleisesti käytetty kuvauskieli, jonka avulla kuvataan tietorakenteita. Liitteessä on kuvattu myös em. sanomien lnit_Service, START, OK ja CANCEL rakenne.
Laskutustietueet ja em. sanomat voidaan lähettää esim. IP-pakettien 15 datakentässä, jossa voi olla yksi tai useampi laskutustietue.
Laskutus toimii oikein, kun verkkoon pääsy ja maksut ovat synkronissa toisiinsa nähden, eli jos niillä asiakkailla, jotka maksavat on pääsy palveluja tarjoavaan verkkoon ja niillä, jotka eivät maksa ei ole pääsyä. Esim. jonkin vian seurauksena saattaa kuitenkin tilanne joskus muuttua sellaiseksi, että reititin 20 estää maksavien asiakkaiden pääsyn palveluja taijoavaan verkkoon tai sallii sellaisten asiakkaiden pääsyn, jotka eivät maksa (lähetä maksu-CDR:iä). Tällaisen tilanteen korjaamiseksi liittymäpalvelin suorittaa kiertokyselyä reititti------ meitä ja laskutuspalvelulta. Reitittimeltä liittymäpalvelin saa liittymälistan ja laskutuspalvelulta niiden asiakkaiden IP-osoitteet, jotka maksavat ko. het-25 kellä verkkoon pääsystä. Jos maksavan asiakkaan osoite ei ole liittymälistalla, liittymäpalvelin lisää osoitteen listalle. Jos liittymälistalla oleva osoite ei ole laskutuspalvelimen maksavien asiakkaiden joukossa, liittymäpalvelin poistaa osoitteen listalta. Kiertokyselyväli voidaan tehdä säädettäväksi siten, että ‘ liittymäpalvelun tarjoaja voi asettaa haluamansa välin.
» 30 Kuviossa 9a on esitetty päätelaitteen CT rakennetta toiminnallisena lohkokaaviona. Keksinnön kannalta laitteen ytimen muodostaa CDR-generaattori CG, joka synnyttää laskutustietueita. CDR-generaattoriin liittyy turvakirjasto SLI, jonka muistissa on asiakkaan henkilökohtainen salausavain ja joka hoitaa laskutustietueiden allekirjoitusta. CDR-generaattori synnyttää 35 CDR:t ja lähettää ne turvakirjastoon, jossa suoritetaan niiden allekirjoitus 23 104668 käyttäen asiakkaan henkilökohtaista salausavainta. Turvakiijasto palauttaa allekirjoitetut CDR:t takaisin CDR-generaattorille, joka lähettää ne edelleen laskutuspalvelimelle WD.
Mikäli sovellus tai ympäristö on sellainen, että päätelaitteen ja lasku-5 tuspalvelimen välillä on välitettävä salattuja sanomia, turvakiijasto toteuttaa salauksen, allekirjoituksen ja allekirjoituksen tarkastamisen.
Turvakiijasto voidaan toteuttaa joko laitteistopohjaisena tai ohjelmistopohjaisena. Laitteistopohjainen ratkaisu on kuitenkin turvallisempi. Turvakir-jasto tai sen osa voidaan näin ollen toteuttaa edellä kuvatulla tavalla esim. 10 älykortille, joka sisältää mm. asiakaskohtaisen salausavaimen.
Lisäksi päätelaitteeseen kuuluu elimet palvelun vastaanottamiseksi. Nämä voivat muodostua esim. palvelutoistimesta VP, joka voi olla esim. vi-deotoistin, joka toistaa verkosta vastaanottamansa videosignaalin ja joka voi lisäksi antaa CDR-generaattorille laskutustietueiden generointikäskyt. Palve-15 luselain SB, palvelutöistä VP ja CDR-generaattori ovat yhteydessä verkkoon päätteen tietoliikennekirjaston CL kautta. Viimemainittu muodostaa sen protokollapinon, jonka mukaan päätelaite kulloinkin toimii. Tämä protokollapino voi olla esim. TCP/IP-pino, joka voi olla esim. Microsoft Winsock -ohjelma.
Päätelaitteen aloituslogiikkayksikkö SUL hoitaa aloitussanoman 20 lähettämisen liittymäpalvelimelle, kun käyttäjä työntää älykortin lukijaan.
Päätelaitteessa voi myös olla veloituslaskuri BC, jotta asiakas voi tarkistaa laskutuspalvelun tarjoajalta saamansa laskun oikeellisuuden omalta laitteeltaan. Lisäksi päätelaitteessa voi olla erilaisia elimiä tulevan informaatiovirran palvelutason (QoS) valvomiseksi, esim. videotoistin voi antaa lähteelle 25 käskyn lopettaa informaation siirto, kun palvelun laatu laskee alle tietyn rajan.
Kuvio 9b esittää tarkemmin CDR-generaattorin toiminnallista lohko-kaaviota. Sopimuslogiikkayksikkö CLU1 hoitaa laskutustietueiden muodostusta konfigurointitietokannan CDB sisältämien tietojen perusteella. Se sisältää logiikan, joka siirtää vastaanottamansa sopimustiedot graafiselle käyttöliitty-30 mälle GUI ja muodostaa edellä kuvatun kaltaisia laskutustietueita. Tämä logiikka sisältää ajastinelimet TM, jotka määräävät kahden peräkkäisen CDR:n välisen ajan. Sopimuslogiikkayksikkö CLU1 on yhteydessä tietoliikennekirjas-toon ja verkkoon ulkoisen ohjausrajapinnan ECI kautta sekä palvelutoistimeen sisäisen ohjausrajapinnan ICI kautta. Ulkoinen ohjausrajapinta suorittaa 35 muunnoksen sisäisen ja ulkoisen CDR-formaatin välillä. Sisäinen ohjausraja- 24 104668 pinta hoitaa puolestaan sanomanvaihtoa palvelutoistimen ja sopimuslogiik-kayksikön välillä suorittaen tarvittaessa muunnoksen palvelutoistimen käyttämän sanomaformaatin ja laitteen sisäisen sanomaformaatin välillä. Sisäisen ohjausrajapinnan ja palvelutoistimen välinen yhteys (rajapinta A3) voidaan 5 toteuttaa esim. tietoliikennekirjaston kautta (TCP-socket). Konfigurointitieto-kantaan CDB talletetaan tiedot käyttäjän tekemistä asetuksista (user preferences) ja se voi myös eri palveluihin (esim. elokuviin) liittyvää informaatiota, joka esitetään asiakkaalle vastaanotetun palvelutunnisteen perusteella. Tämä tietokanta voidaan toteuttaa esim. Microsoft Access tai Borland Paradox -10 ohjelmalla. Konfigurointitietokantaa hallitaan hallintayksikön MM kautta. Hal-lintayksikkö, konfigurointitietokanta ja sopimuslogiikkayksikkö ovat kaikki yhteydessä laitteen graafiseen käyttöliittymään GUI, jonka toteutuksessa voidaan käyttää esim. JAVA-appletteja tai esim. Microsoft Visual Basic -ohjelmointityökalua. Osa konfigurointitietokannasta voi olla verkossa.
15 Mikäli palvelutoistin on tarkoitettu esim. tilausvideopalveluun, se voidaan toteuttaa esim. henkilökohtaisen tietokoneen ja tilausvideopalveluun tarkoitetun ohjelman avulla. Eräs tällainen ohjelma on StreamWorks, valmistaja Xing Technology Inc., USA.
Hallintayksikkö ja sopimuslogiikkayksikkö ovat rajapinnan A1 kautta 20 yhteydessä turvakirjastoon. Turvakirjasto ja rajapinta A1 voidaan toteuttaa esim. Setec Oy:n SETCOS 3.1 -älykortin (ja älykortin lukijan) avulla tai jollain muulla vastaavalla tuotteella, joka perustuu kansainvälisiin älykorttistandardei-hin. (Kansainvälinen standardointijärjestö ISO on määritellyt sarjan älykortteja koskevia standardeja seuraavasti: ISO 7816-1 (fyysiset dimensiot), ISO 7816-25 2 (kontaktien sijainti), ISO 7816-3 (siirtoprotokollat) ja ISO 7816-4 (komento- ja tiedostorakenteet).) Käyttäjällä voi olla useita erilaisia älykortteja, joilla kullakin avautuu tietyn tyyppinen yhteys. Yhdellä kortilla voidaan esim. avata täydellinen Inter-net-yhteys ja toisella kortilla (jossa tilaajana on työnantaja) esim. vain yhteys 30 työpaikan lähiverkkoon.
Kuviossa 10 on havainnollistettu laskutuspalvelun WD rakennetta yleisen tason lohkokaavion avulla. Laitteen ytimen muodostaa sopimuslogiikkayksikkö CLU2, jolla on käytettävissään palvelutietokanta SED, tilaajatieto-kanta SUD ja laskutustietokanta BD. Palvelutietokanta käsittää tiedot eri pal-35 velun tuottajien palveluista ja niiden laskutusparametreista. Laskutuspaivelin 25 104668 voi myös muuttaa itsenäisesti laskutusparametrejä, esim. vuorokauden ajan mukaan. Tilaajatietokanta käsittää laskutuspalvelua hoitavan operaattorin asiakastiedot (mm. kunkin asiakkaan julkisen avaimen). Laskutustietokantaan talletetaan päätelaitteiltä vastaanotetut laskutustietueet. Sopimuslogiikkayksik-5 köön liittyy salauslohko CM, joka hoitaa laskutustietueiden allekirjoituksen tarkistuksen. Tämä lohko vastaa päätelaitteen lohkoa SL. Sopimuslogiikkayk-sikkö vastaanottaa päätelaitteiden allekirjoittamia laskutustietueita päätelaitteiltä ja siirtää ne salauslohkon tarkistettavaksi. Hyväksytyt laskutustietueet sopimuslogiikkayksikkö tallettaa laskutustietokantaan. Sopimuslogiikkayksikkö 10 on yhteydessä verkkoon tietoiiikennekirjastonsa CL’ kautta, joka muodostaa sen protokollapinon, jonka mukaan yhteys kulloinkin rakennetaan.
Käytännössä edellä kuvatut toiminnallisuudet omaavat sopimuslogiik-kayksiköt voidaan toteuttaa esim. jonkin kansainväliseen SDL-standardiin (System Description Language) perustuvan työkalun avulla, esim. Telelogic 15 AB:n SDT-työkalun avulla.
Laskutuspalvelun tietokannat voivat olla edellä (kuvio 3) esitetyssä muistissa MS, joka on laskutuspalvelimen yhteydessä. Tämän lisäksi voidaan laskutustietueet tallettaa erilliseen massamuistiin MS1 (kuvio 3), joka on verkossa laskutuspalvelimen ja laskutusjärjestelmän välissä ja joka on organisoitu 20 siten, että laskutusjärjestelmän on helppo käsitellä siellä olevaa informaatiota. Tällaisella erillisellä tietokannalla voidaan palvelun tarjoajille järjestää mahdollisuus tehdä tietokantaan erilaisia kyselyjä palveluiden kehittämiseksi. Palvelun tuottaja tai asiakas voi esim. kysellä tietyn palvelun aikaansaamaa laskutusta keskellä laskutusjaksoa (esim. sähköpostin avulla).
25 Kuviossa 11 on havainnollistettu liittymäpalvelimen SL rakennetta toiminnallisena lohkokaaviona. Ulkopuolisia yhteyksiä varten palvelimessa on rajapintayksikkö IU, joka käsittää reitittimen rajapintayksikön RIU, laskutuspalvelimen rajapintayksikön WIU ja päätelaitteen rajapintayksikön TIU. Viimemainittu vastaanottaa päätelaitteelta em. aloitussanoman lnit_Service ja aloittaa 30 ko. asiakasta koskevan laskutusistunnon. Reitittimen rajapintayksikkö valvoo reitittimen liittymälistaa ja laskutuspalvelimen rajapintayksikkö hoitaa kommunikoinnin laskutuspalvelimen kanssa. Kytkentälogiikka CLO on yksinkertainen tilakone, joka yhdistää eri rajapintayksiköt toisiinsa. Kytkentälogiikka pitää myös yllä listaa kaikista auki olevista yhteyksistä sekä kahta jonoa, joista 35 toisesta on suljettavana olevat yhteydet ja toisessa avattavana olevat yhtey- 26 104668 det.
Reitittimen ohjausyksikkö RCU, joka sisältää reitittimen käskyjoukon, ohjaa reititintä suorittaen edellä kuvattua liittymälistan ylläpitoa.
Synkronointiyksikkö SU hoitaa edellä kuvattua maksujen ja liittymäoi-5 keuksien synkronointia vertaamalla tietyin aikavälein reitittimen auki olevien yhteyksien listaa ja maksavien asiakkaiden osoitteita, jotka saadaan laskutus-palvelimelta. Havaitut ristiriitaisuudet korjataan, joten laskutuksessa ei pääse syntymään mainittua aikaväliä pidempää virhettä.
Reititinyhteyden valvontayksikkö RCC valvoo liittymäpalvelimen ja 10 reitittimen välistä yhteyttä. Koska esimerkissä oletetaan, että reitittimen ja liittymäpalvelimen välinen yhteys on Telnet-yhteys, reititin katkaisee yhteyden, jos se on liian kauan käyttämättömänä. Reitittimen valvontayksikön tehtävänä on avata yhteys, jos reititin pääsee katkaisemaan sen esim. em. syystä tai muista yhteydellä olevista häiriöistä johtuen.
15 Määrän (volume) valvontayksikkö VCU ja sen käyttämä laskutustieto- kanta BD2 ovat liittymäpalvelimessa ainakin siinä tapauksessa, että laskutusta halutaan suorittaa myös siirrettyyn datamäärään perustuen. Tässä tapauksessa valvontayksikkö lukee reitittimen rajapintayksikön kautta reitittimen liittymä-listalta halutut pakettimäärät ja tallettaa tiedot laskutustietokantaan BD2 siten, 20 että kutakin sopimusnumeroa kohti talletetaan pakettien lukumäärät ja se IP-osoite, jota päätelaite on käyttänyt yhteydellä. Liittymäpalvelimen laskutustie-tokannan tiedot yhdistetään laskutusvaiheessa laskutuspalvelimen laskutus-.... tietokannan tietoihin sopimusnumeroiden perusteella, jolloin myös siirretty datamäärä pystytään huomioimaan laskussa.
25 Edellä kuvatussa toteutustavassa ei vielä sellaisenaan saada tilaajan allekirjoitusta pakettimääriä koskevaan tietoon, joten käyttäjä joutuisi tässä suhteessa luottamaan siihen, että järjestelmän laskemat pakettimäärät ovat oikeita. Kaikessa muissa tapauksissa päätelaite pystyy sen sijaan itse tarkistamaan, että laskutus tapahtuu oikein. Tämän ongelman ratkaisemiseksi 30 noudatetaan seuraavaa kaksivaiheista menettelyä. Ensinnäkin, liittymäpalvelin ilmoittaa päätelaitteelle, milloin laskutettava määrä on kasvanut tietyllä arvolla (esim. 50 Mb). Tällä tavoin päätelaite voi seurata liittymäpalvelimen suorittamaa määrälaskentaa ja verrata sitä omaansa. Toiseksi, liittymäpalvelin lähettää jokaisen määrään liittyvän CDR:n laskutuspalvelulle, joka välittää sen 35 edelleen allekirjoitettavaksi päätelaitteelle. Proseduuri on samanlainen kuin 27 104668 edellä kuvattu sopimuksen allekirjoitus; se antaa päätelaitteen käyttäjälle mahdollisuuden valvoa laskutusta ja tekee maksujen kiistämisen vaikeaksi. Tätä menettelyä havainnollistetaan seuraavassa tarkemmin viitaten kuvioon 12, joka esittää eri osien välistä kommunikointia.
5 Aluksi luodaan erillinen “määräsopimus" edellä kuvatulla tavalla ulkoisesti laukaistavana sopimuksena (nuolet 121-124). Liittymäpalvelin lukee reitittimeltä halutut pakettimäärät ja tallettaa tiedot laskutustietokantaan BD2. Kun pakettimäärä saavuttaa jonkin ennalta määrätyn rajan, liittymäpalvelin lähettää tyyppiä 3 (pulssi) olevan allekirjoitetun CDR:n laskutuspalvelulle 10 (nuoli 126). Tätä ennen liittymäpalvelin lähettää kuitenkin päätelaitteen liiken-nedataporttiin sanoman VM, joka sisältää tiedon siirretystä datamäärästä (jota on merkitty termillä “liikennedata”). Tällä tavoin tieto määrästä saadaan seu-raavaan allekirjoitettavaan CDR:ään ja käyttäjälle, tai ainakin päätelaitteelle, annetaan mahdollisuus tarkistaa määrä ennen CDR:n allekirjoitusta.
15 Laskutuspalvelu huomaa, vastaanottaessaan tyyppiä 3 olevan CDR:n liittymäpalvelimelta, että sopimus on ulkoisesti laukaistava sopimus, jolloin se lähettää kyseisen CDR.n edelleen päätelaitteelle (nuoli 127). Jos käyttäjä tai päätelaite hyväksyy määrän, se muodostaa maksu_CDR:n, siirtää vastaanottamansa datamäärätiedon tämän maksu-CDR:n liikennedata-20 kenttään ja lähettää ko. maksu-CDR:n laskutuspalvelulle (nuoli 128). Laskutuspalvelu välittää CDR:n tai sen sisältämät tiedot edelleen liittymäpalveli-melle (nuoli 129), joka tarkistaa ainakin liikennedata-kentän sisältämät tiedot. Tarkistuksen perusteella liittymäpalvelin joko katkaisee palvelun tai antaa sen jatkua. Tässä tapauksessa palvelu siis todennäköisesti koostuu yhdistelmä-25 palvelusta, johon kuuluvat sekä aikaan että määrään perustuvat sopimukset.
Päätelaitteen kannalta edellä kuvattu määrään perustuva laskutus tapahtuu seuraavasti. Laskutuspalvelun lähettämän uuden sopimuksen (nuoli 122) maksutapaparametrilla on arvo, joka osoittaa ulkoa laukaistavaa * maksua. Kun maksu tarvitaan, päätelaite vastaanottaa tyyppiä 3 olevan 30 CDR:n, joka sisältää tiedon tarvittavan maksun määrästä. Tällöin- päätelaite joko automaattisesti hyväksyy maksun tai tiedot esitetään päätelaitteen näytöllä käyttäjälle, joka voi päättää, hyväksyykö hän maksun. Jos hyväksyminen suoritetaan, päätelaite muuttaa CDR:n tyypin ykköseksi (maksu-CDR), suorittaa CDR:n allekirjoituksen ja lähettää sen laskutuspalvelulle (nuoli 128).
35 Maksusuorituksen voi laukaista myös jokin muu ulkopuolinen olio, 28 104668 esim. laskutuspalvelu, joka lähettää päätelaitteelle komennon, joka osoittaa, että maksusuoritus tarvitaan. Tällainen komento lähetetään liikennedataa vastaavaan socket-osoitteeseen. Komentosanomassa on tieto paitsi itse komennosta (“suorita maksu”), myös sopimusnumerosta. Tämän jälkeen 5 päätelaite suorittaa maksun. Tässä tapauksessa komento ilmoittaa pelkästään, että maksua edellytetään. Maksun määrä on sen sijaan määritelty sopimuksessa.
Edellä kuvatulla tavalla määrään perustuva laskutus voidaan toteuttaa siten, että päätelaite tai käyttäjä on koko ajan tietoinen syntyvän laskun suu-10 ruudesta. Jokainen maksu hyväksytään, joten maksujen kiistäminen on vaike aa. Sanomia on lähetettävä vain silloin, kun maksuja tarvitaan, joten jos päätelaitteelle (päätelaitteelta) ei ole liikennettä, ei myöskään synny tyhjiä tai tarpeettomia laskutussanomia. Koska toteutus on tehty sovellustasolla, ei määrään perustuva laskutus ole riippuvainen tietystä teknologiasta, vaan 15 palvelun tarjoajan ja päätelaitteen välissä voi olla useita “laskuttajia”, jotka laskuttavat samanaikaisesti määrään perustuen.
Vaikka edellä on käytetty esimerkkinä ADSL-ympäristöä, on selvää, että keksinnön mukainen menetelmä tarjoaa samat edut missä tahansa yhteydettömässä verkossa, jossa tarjotaan liittymäpalveluja siten, että on tarve 20 erottaa tietyn verkko-osoitteen kulloinenkin käyttäjä tai jossa käyttäjä ei välttämättä ole se palvelun tilaaja, joka maksaa palvelusta. Päätelaite voi liittyä palveluja tarjoavaan verkkoon myös langattomasti. Tulevaisuudessa saattavat ----- liittymätavat vaihdella huomattavastikin.
Edellä on lisäksi viitattu tilanteisiin, joissa asiakkaan verkko-osoite (IP-25 osoite) voi vaihdella eri palveluistunnoissa, mutta pysyy samana yhden palve-luistunnon aikana. Keksinnön mukaista menetelmää voidaan kuitenkin soveltaa myös tilaajien liikkuessa paikasta toiseen. Tähän voidaan käyttää esim. Mobile IP -protokollaa, joka on olemassa olevan IP:n versio, joka tukee pää-*. telaitteen liikkuvuutta. (Mobile IP: periaatetta kuvataan esim. artikkelissa Upkar 30 Varshney, Supporting Mobility with Wireless ATM, Internet Watch, January 1997.)
Mobile IP perustuu siihen, että kullakin liikkuvalla tietokoneella tai solmulla (mobile host, mobile node) on sille osoitettu agentti (“kotiagentti”, home agent), joka välittää paketit liikkuvan tietokoneen sen hetkiseen sijainti-35 paikkaan. Kun liikkuva tietokone liikkuu aliverkosta toiseen, se rekisteröityy 29 104668 kyseistä aliverkkoa palvelevalle agentille (“vierailuagentti”, foreign agent). Viimemainittu suorittaa tarkistuksia liikkuvan tietokoneen kotiagentin kanssa, rekisteröi liikkuvan tietokoneen ja lähettää sille rekisteröinti-informaation. Liikkuvalle tietokoneelle osoitetut paketit lähetetään liikkuvan tietokoneen 5 alkuperäiseen sijaintipaikkaan (kotiagentille), josta ne välitetään edelleen sen hetkiselle vierailuagentille, joka lähettää ne edelleen liikkuvalle tietokoneelle.
Sovellettaessa edellä kuvattua periaatetta keksinnön mukaiseen järjestelmään voidaan toimia esim. siten, että jokaisella käyttäjällä on sille osoitettu (koti)laskutuspalvelin, joka pitää huolta käyttäjän julkisista avaimista 10 ja joka toimii kotiagenttina. Eri aliverkkoja palvelevat liittymäpalvelimet (eli vierailuagentit) kertovat paikalliselle laskutuspalvelulle laskutuksen aloittamisesta. Tämä laskutuspalvelu hakee julkiset avaimet käyttäjän kotilaskutuspal-velimelta ja ryhtyy hoitamaan laskutusta. Oleellista on, että tilaajan julkinen avain voidaan siirtää turvallisesti tilaajan lähellä olevalle laskutuspalvelimelle, 15 jotta ko. laskutuspalvelu voisi tarkistaa laskutustietueet. (Mikäli siirtoa ei voida tehdä turvallisesti, on mahdollista, että kolmas osapuoli voi muuttaa avainta sen siirron aikana ja näin ollen synnyttää kuluja alkuperäisen tilaajan laskuun.) Tilaajan julkinen avain voidaan siirtää esim. laskutuspalveiimen lähellä olevaan tietokantaan, johon laskutuspalvelimella on pääsy. Tilaajaa lähinnä oleva 20 laskutuspalvelu voi hoitaa laskutusta käyttäen tilaajan oman laskutuspalveli-men tunnistetta. Kerätyt CDR.t lähetetään tilaajan omalle laskutuspalvelimelle sen jälkeen, kun palveluistunto on päättynyt.
Kuviossa 13 on kuvattu eri komponenttien välistä kommunikointia mobile IP -yhteyksien tapauksessa. Kuviossa on koti- ja vierailuagentit esitetty 25 fyysisesti erillisinä koneina, mutta kuten edellä mainittiin, liittymäpalvelin voi toimia myös vierailuagenttina ja kotilaskutuspalvelin kotiagenttina. Mobile IP -protokollan mukaisesti vierailuagentti FA lähettää omaan aliverkkoonsa jatkuvasti broadcast-sanomia, joita kutsutaan nimellä “agent advertisement” ja joita on kuviossa merkitty viitemerkillä AA. Kun päätelaite kytkeytyy kyseiseen 30 aliverkkoon, se vastaanottaa näitä sanomia ja päättelee niiden perusteella, onko se omassa kotiverkossaan vai jossakin muussa verkossa. Jos päätelaite huomaa, että se on kotiverkossaan, se toimii ilman liikkuvuuteen liittyviä palveluja (mobility services). Muussa tapauksessa päätelaite saa c/o-osoitteen (care-of address) ko. vieraaseen verkkoon. Tämä osoite on siis verkon sen 35 pisteen osoite, johon päätelaite on väliaikaisesti kytkeytyneenä. Tämä osoite 30 104668 muodostaa samalla ko. päätelaitteelle johtavan tunnelin (tunnel) päätepisteen (termination point). Päätelaite saa osoitteen tyypillisesti em. broadcast-sanomista, joita vierailuagentti lähettää. Tämän jälkeen päätelaite lähettää omalle kotiagentilleen rekisteröintipyyntösanoman RR (Registration Request) 5 vierailuagentin FA kautta. Sanoma sisältää mm. sen c/o-osoitteen, jonka päätelaite on juuri saanut. Vastaanottamansa pyyntösanoman perusteella kotiagentti päivittää kyseisen päätelaitteen sijaintitiedon tietokantaansa ja lähettää päätelaitteelle vierailuagentin kautta rekisteröintivastauksen (Registration Reply) R_Reply. Vastaussanomassa on kaikki tarpeelliset tiedot 10 siitä, miten (millä ehdoilla) kotiagentti on hyväksynyt rekisteröintipyynnön. Kaikki edellä kuvatut, päätelaitteen, vierailuagentin ja kotiagentin väliset sanomat ovat normaaleja mobile IP -protokollan mukaisia sanomia.
Tämän jälkeen vierailuagentti FA lähettää em. aloitussanoman eli laskutuksen palvelupyyntösanoman lnit_Service liittymäpalvelimelle SL. Tämä 15 sanoma vastaa kuviossa 5 esitettyä, päätelaitteen lähettämää palvelupyyntö-sanomaa, joka indikoi kertaluonteisen palveluistunnon alkamista. Sanoma sisältää mm. kyseisen päätelaitteen c/o-osoitteen. Tämän jälkeen toiminta on samanlainen kuin edellä kuvion 5 yhteydessä, lukuunottamatta laskutuksen lopetusta ja kuittaussanomaa ACK, joihin viitataan jäljempänä. Seuraavaksi 20 liittymäpalvelin tarkastaa siis vastaanottamansa sanoman ja lähettää edelleen aloitussanoman START laskutuspalvelimelle WD. Tämän jälkeen seuraa laskutuspalvelun ja päätelaitteen välinen sopimusneuvottelu, jonka seurauk-sena käyttäjälle annetaan normaalitapauksessa pääsy verkkoon.
Laskutuksen lopettaminen poikkeaa kuvion 5 kiinteiden päätelaittei-25 den tapauksesta sikäli, että lopettamisen voi mobile IP -tapauksessa suorittaa joko vierailuagentti tai laskutuspalvelu, riippuen siitä, kumpi ensimmäisenä huomaa muutoksen. Jos vierailuagentti huomaa, että käyttäjä on poistunut verkosta, se lähettää liittymäpalvelimelle lopetussanoman CANCEL(1). Liitty-*. mäpalvelin välittää ko. sanoman edelleen laskutuspalvelimelle sekä sulkee 30 reitittimen ko. yhteyden osalta. Vierailuagentti huomaa käyttäjän poistumisen automaattisesti, koska mobile IP -protokollan mukaan päätelaitteen on lähetettävä säännöllisin väliajoin sanomia, jotka osoittavat päätelaitteen olevan edelleen paikalla ko. aliverkossa. Nämä alive-sanomat on tarkoitettu vain vierailuagentin käyttöön, eikä vierailuagentti välitä niitä eteenpäin. Mikäli taas 35 laskutuspalvelu huomaa ensimmäisenä, että käyttäjä on lopettanut istunnon, 31 104668 se lähettää liittymäpalvelimelle lopetussanoman CANCEL(2), jonka seurauksena yhteys poistetaan reitittimeltä. Muussa suhteessa yhteyden sulkemisessa on samanlaiset vaihtoehdot kuin edellä on esitetty.
. Mobile IP -tapauksessa käyttäjä tai päätelaite ei siis lähetä aloitussa- 5 nomaa (kuten kuvion 5 tapauksessa esitettiin), vaan vierailuagentin toimintaa on muutettu siten, että se käynnistää laskutuksen siinä yhteydessä, kun sen palvelemaan aliverkkoon kytkeytynyt päätelaite rekisteröityy kotiagentilleen vierailuagentin kautta.
Vierailuagentti ylläpitää lisäksi erityistä laskutuksen käynnistysajas-10 tinta, joka mittaa aikaa siitä, kun palvelupyyntösanoma lähetettiin liittymäpalve-limelle. Mikäli se ei vastaanota sanomaa ACK ennen kuin ajastin laukeaa, se yrittää laskutuksen käynnistystä uudelleen lähettämällä uuden palvelupyyntö-sanoman liittymäpalvelimelle. Tätä prosessia päätelaite suorittaa kaikille alueellaan oleville päätelaitteille, joilla ei ole käynnissä olevaa laskutusta.
15 Edellä kuvatulla tavalla liittymäpalvelun tarjoaja pystyy luotettavasti rajoittamaan käyttäjät esim. vain niihin käyttäjiin, joita voidaan laskuttaa verkon käytöstä, siitä huolimatta, että mobile IP protokollana ei tarjoakaan tällaista mahdollisuutta.
Huomattakoon vielä, että vierailuagentti ei ole ehdottoman välttämä-20 tön mobile IP -verkossa. Jos vierailuagenttia ei käytetä, verkossa on edelleen DHCP-palvelin tai jokin muu mekanismi, joka jakaa väliaikaisia osoitteita. Tässä tapauksessa, jos päätelaite haluaa käyttää liikkuvuuteen liittyviä palveluja, sen on aloitettava yhteys samalla tavalla kuin kuvion 5 tapauksessa esitettiin. Jos päätelaitteelle päätetään antaa liittymäpalvelua, se rekisteröi 25 itsensä kotiagentillaan edellä kuvatun normaalin rekisteröintimenettelyn mukaisesti.
Edellä kuvattiin liittymäpalvelun toteutusta mobile IP -yhteyksien tapauksessa. Jos käytetty reititysprotokolla on IPv6, jossa ei ole erityistä vie-' v railuagenttia, on liittymäpalvelu aloitettava hieman eri tavalla.
30 Kun IPv6-päätelaite kytkeytyy uuteen verkkoon, oletusarvoinen me nettely on sellainen, että päätelaite odottaa reitittimen lähettämää adver-tisement-sanomaa. Tällainen sanoma voi antaa päätelaitteelle oikeuden generoida oman osoitteen tai se voi vaatia päätelaitetta käyttämään DHCP-palvelinta väliaikaisen osoitteen saamiseksi. Kun päätelaite on saanut tämän 35 väliaikaisen osoitteen, se lähettää päivityssanomia (binding updates), joilla 32 104668 päivitetään verkon reitittimillä olevia tietoja, jotka koskevat päätelaitteen (kiinteää) kotiosoitetta ja siihen liittyvää väliaikaista osoitetta. Nämä päivityssa-nomat lähetetään kaikille solmuille, joiden kanssa päätelaite kommunikoi, erityisesti päätelaitteen omalle kotiagentille. Päivityssanomien perusteella ko.
5 solmut päivittävät reititystietojaan niin, että ne voivat välittää ko. päätelaitteelle tarkoitetut paketit suoraan päätelaitteen väliaikaiseen osoitteeseen.
Kuviossa 14 on havainnollistettu yksinkertaistettuna eri komponenttien välistä sanomanvaihtoa, kun reititysprotokolla on IPv6. Tässä tapauksessa voidaan toimia esim. niin, että reitittimet edellyttävät verkkoon kytkeytyvien 10 uusien käyttäjien (päätelaitteiden) rekisteröityvän paikalliselle DHCP-palvelimelle DHCP_S. Päätelaite lähettää DHCP-palvelimelle rekisteröinti-pyynnön (REQUEST) vasteena vastaanottamaansa advertisement-sanomaan. Kun DHCP-palvelin on antanut päätelaitteelle väliaikaisen osoitteen (sanoma ACK), DHCP-palvelin käynnistää laskutuksen lähettämällä liittymäpalvelimelle 15 SL em. aloitussanoman lnit_Service. DHCP-palvelin ottaa siis tässä tapauksessa, laskutus- ja liittymäpalvelimien kannalta katsottuna, saman roolin kuin mobile IP -verkon vierailuagentti. Toisin sanoen, lähettämällä em. aloitussanoman se informoi liittymäpalvelinta uusista verkkoon kytkeytyvistä päätelaitteista. Muuten protokolla on samanlainen kuin edellä esitetyssä mobile IP -20 tapauksessa.
Yhdyskäytäväreititin R1 on tässä tapauksessa konfiguroitava oletusarvoisesti niin, että kaikilla verkkoon kytkeytyvillä päätelaitteilla on pääsy liittymä- ja laskutuspalveluille.
Kun päätelaite siirtyy aliverkosta toiseen (eli liittymäpalvelimelta toi-25 selle), voidaan solmia uusi sopimus, neuvotella sama sopimus uudestaan tai jatkaa samaa sopimusta, riippuen siitä, kuinka olosuhteet vaihtuvat siirtymän (hand-off tai handover) seurauksena. Esim. vaihdettaessa samalla myös operaattoria voidaan aina neuvotella uusi sopimus. Jos ei vaihdeta operaatto-’ ria, mutta uudessa aliverkossa palvelun laatu poikkeaa oleellisesti aikaisem- « 30 masta, voidaan sama sopimus neuvotella uusilla ehdoilla. Sen osapuolen, joka päättää handover-tapahtumasta tulisi myös päättää lopetetaanko vanha sopimus vai jatketaanko sitä. Toisaalta käyttäjällä tulee aina olla mahdollisuus tietää, missä verkossa hän on ja millä ehdoilla hän vastaanottaa palvelua.
Kuvioiden 13 ja 14 mukaiset verkkoympäristöt vastaavat muuten 35 kuvioiden 3a...3d esimerkkejä, mutta LAN-kytkimen tilalla on langaton (tai 33 104668 langallinen) liittymäverkko, ATU-C:n tilalla on yhteinen liittymäpiste, esim. älykäs solmupiste (intelligent hub), tms., ja ATU-R:n tilalla on päätelaitteen liitäntä(kortti). Lisäksi DHCP-palvelimen tilalla on vierailuagentti, jos kysymyksessä on mobile IP -verkko. Kuviossa 15 on havainnollistettu viime mainitun 5 kaltaista verkkoympäristöä kuvion 3a mukaista esimerkkiä käyttäen. Kuviossa on esitetty vierailuagentti erillisenä koneena, vaikka vierailuagentti voidaankin sijoittaa liittymäpalvelimeen. Kuten kuviosta myös havaitaan, liittymäpisteen paikallinen laskutuspalvelu on tyypillisesti eri palvelin kuin ko. liittymäpisteen kautta verkkoon kytkeytyvän käyttäjän kotilaskutuspalvelin, joka voi olla kyt-10 keytyneenä esim. Internetiin tai puhelinverkkoon.
Vaikka keksintöä on edellä selostettu viitaten oheisten piirustusten mukaisiin esimerkkeihin, on selvää, ettei keksintö ole rajoittunut siihen, vaan sitä voidaan muunnella oheisissa patenttivaatimuksissa esitetyn keksinnöllisen ajatuksen puitteissa. Seuraavassa kuvataan lyhyesti erilaisia variaatiomahdol-15 lisuuksia.
On esimerkiksi mahdollista, että päätelaite ei lähetä laskutuspalveli-melle varsinaisia laskutustietueita, vaan muita (laskutukseen liittyviä) sanomia, joiden perusteella laskutuspalvelu osaa itse generoida laskutustietueet. Päätelaite voi esim. lähettää ns. keep-alive-sanomia niin kauan kuin palvelua 20 kestää, minkä jälkeen laskutuspalvelu voi esim. generoida vain yhden lasku-tustietueen, jossa palvelun kestoaika vastaa viimeisimmän keep-alive-sanoman ja sopimuksen hyväksymishetken välistä aikaa. On myös mahdol-lista, erityisesti järjestelmissä, jotka tukevat päätelaitteen liikkuvuutta, että jokin toinen verkkoelementti tai -olio (esim. liittymäpalvelin tai vierailuagentti) ottaa 25 päätelaitteen roolin laskutustietueen/-tietueiden generoijana. Tällaisella elementillä tai oliolla on oltava käyttäjän luottamus. Päätelaitteen roolin ottaminen voi tapahtua esim. siten, että päätelaite maksaa kertakorvauksena tietyn summan ko. elementille tai oliolle, joka generoi sen jälkeen laskutustietueita/-• tietueen ja/tai ylläpitää yhteyttä saamansa maksun mukaisesti ja mahdollisesti 30 pyytää tarvittaessa lisäsuorituksia päätelaitteelta. Jos päätelaitetta edustava olio generoi laskutustietueen omalla allekirjoituksellaan, on laskutuspalvelimen tiedettävä, ketä ko. olio kulloinkin edustaa.
Palveluja tarjoavan verkon ja liittymäverkon (access network) yhdistävänä elimenä voidaan myös käyttää mitä tahansa kyseiseen tarkoitukseen 35 sopivaa laitetta, joka pystyy selektiivisesti päästämään liikennettä lävitseen, 34 104668 esim. pakettisuodatinta tai palomuuria. Aloitussanomana voi myös toimia jokin muussa tarkoituksessa lähetetty sanoma, joka samalla indikoi uuden palve-luistunnon alkamisen.
• · » <

Claims (39)

1. Menetelmä liittymäpalvelun toteuttamiseksi tietoliikenneverkossa, joka käsittää liittymäverkon (N1), joka on ainakin osaksi yhteydetön, palveluja tarjoavan verkon (N2) ja käyttäjien käytössä olevia päätelaitteita (TE1...TE3,
2. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, että laskutussanomia lähetetään päätelaitteelta ja laskutussanomat varustetaan tilaajakohtaisella digitaalisella allekirjoituksella.
3. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, 25 että päätelaitteelle annetaan pääsy palveluja taijoavaan verkkoon, mikäli mainittuja laskutussanomia vastaanotetaan ennalta määrätyn tahdin mukaisesti ja sanomien sisältämät allekirjoitukset todetaan oikeiksi.
4. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, että päätelaitteelta lähetetään lisäksi tiedot päätelaitteen kulloiseenkin käyttä- 30 jään liittyvästä tilaajasta, jolloin mainittujen tietojen avulla tarkistetaan allekirjoitusten oikeellisuus ja kohdistetaan päätelaitteelta vastaanotetut laskutussanomat kyseisen tilaajan laskutukseen.
5. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, että verkossa käytetään ainakin yhtä erillistä laskutuspalvelua (WD) siten, 35 että kullakin päätelaitteella on sille osoitettu laskutuspalvelu, joka vastaanottaa 36 104668 päätelaitteiden generoimia laskutussanomia.
5 PC), jotka on kytketty liittymäverkkoon, jonka menetelmän mukaisesti - liittymäpalvelu tarjotaan kytkemällä käyttäjän päätelaite liittymäverkon ja palveluja tarjoavan verkon yhdistävien rajapintaelimien (R1) kautta palveluja tarjoavaan verkkoon, ja - vastineeksi liittymäpalvelusta generoidaan ainakin yksi laskutus-10 tietue, joka välitetään laskutuselimille (BS) liittymäpalvelun tilaajan laskuttamiseksi liittymäpalvelusta, tunnettu siitä, että tietoliikenneverkossa - indikoidaan kertaluonteisen liittymäpalveluistunnon alku synnyttämällä laskutusta varten aloitussanoma käyttäjän ottaessa päätelaitteen kautta 15 yhteyden liittymäverkkoon, - generoidaan digitaalisella allekirjoituksella varustettuja laskutussa-nomia, jotka liittyvät mainittuun liittymäpalveluistuntoon, - tarkistetaan generoidut allekirjoitukset, ja - annetaan päätelaitteelle pääsy palveluja tarjoavaan verkkoon, mikäli 20 mainittuja sanomia generoidaan hyväksyttävällä tavalla.
6. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, että kun päätelaitteella on pääsy palveluja tarjoavaan verkkoon, päätelaitteella generoidaan tietyin välein tilaajakohtaisella digitaalisella allekirjoituksella 5 varustettuja laskutustietueita, joista kukin edustaa laskutusta tietyltä yhteys-ajalta.
7. Patenttivaatimuksen 5 mukainen menetelmä, tunnettu siitä, että aloitussanomassa välitetään laskutuspalvelimelle ainakin kyseisen päätelaitteen sen hetkinen osoitetieto.
8. Patenttivaatimuksen 7 mukainen menetelmä, tunnettu siitä, että aloitussanoma välitetään päätelaitteelta erillisen liittymäpalvelimen (SL) kautta laskutuspalvelimelle.
9. Patenttivaatimuksen 8 mukainen menetelmä, tunnettu siitä, että vasteena saamalleen aloitussanomalle laskutuspalvelu lähettää pääte- 15 laitteelle sopimussanoman, joka ilmoittaa, että käyttäjän tulee solmia liittymä-palvelua koskeva sopimus.
10. Patenttivaatimuksen 9 mukainen menetelmä, tunnettu siitä, että päätelaite palauttaa sopimussanoman tilaajakohtaisella digitaalisella allekirjoituksella varustettuna, laskutuspalvelu tarkistaa allekirjoituksen ja 20 havaitessaan allekirjoituksen oikeaksi aloittaa prosessin päätelaitteen yhdistämiseksi rajapintaelimien (R1) kautta palveluja tarjoavaan verkkoon.
11. Patenttivaatimuksen 4 mukainen menetelmä, tunnettu siitä, . . että tieto päätelaitetta käyttävään käyttäjään liittyvästä tilaajasta välitetään aloitussanomassa.
12. Patenttivaatimuksen 10 mukainen menetelmä, tunnettu siitä, että tieto päätelaitetta käyttävään käyttäjään liittyvästä tilaajasta välitetään laskutuspalvelimelle allekirjoitetussa sopimussanomassa.
13. Patenttivaatimuksen 7 mukainen menetelmä, tunnettu siitä, että vasteena saamalleen aloitussanomalle laskutuspalvelu kysyy päätelait- 30 teelta tilaajan identifioivia tietoja.
14. Patenttivaatimuksen 10 mukainen menetelmä, tunnettu siitä, että laskutuspalvelu käynnistää prosessin antamalla yhdistämiskäskyn liitty-mäpalvelimelle (SL), jonka avulla ohjataan rajapintaelimiä (R1).
15. Patenttivaatimuksen 14 mukainen menetelmä, tunnettu siitä, 35 että rajapintaeliminä käytetään reititintä, ja liittymäpalvelin ylläpitää reitittimen 37 104668 liittymälistaa, joka sisältää niiden päätelaitteiden osoitteet, joilla on pääsy reitittimen kautta palveluja tarjoavaan verkkoon.
16. Patenttivaatimuksen 2 mukainen menetelmä, tunnettu siitä, että päätelaitteelta generoidaan laskutustietueita liittymäpalvelun lisäksi pal- 5 velukohtaisesti kustakin sellaisesta palvelusta, jota käytetään palveluja tarjoavasta verkosta.
17. Patenttivaatimuksen 5 mukainen menetelmä, tunnettu siitä, että laskutussanomien sisältämää laskutusinformaatiota lähetetään laskutus-palvelimelta erilliseen laskutusjärjestelmään (BS) tilaajakohtaisten laskujen 10 muodostamista varten.
18. Patenttivaatimuksen 17 mukainen menetelmä, tunnettu siitä, että laskutusinformaatiota lähetetään yleisen puhelinverkon laskutusjärjestelmään.
19. Patenttivaatimuksen 15 mukainen menetelmä, tunnettu siitä, 15 että liittymäpalvelin vertaa ennalta määrätyin välein laskutuspalvelimella olevien maksavien päätelaitteiden listaa ja reitittimellä olevien maksavien päätelaitteiden listaa ja kytkee tai katkaisee päätelaitteiden yhteyksiä palveluja tarjoavaan verkkoon, jos reitittimen lista ei vastaa laskutuspalvelimen listaa.
20. Patenttivaatimuksen 1 mukainen menetelmä, tunnettu siitä, 20 että rajapintaelimien ja päätelaitteen välisestä yhteydestä ainakin osa toteutetaan langallisena ADSL-yhteytenä.
21. Patenttivaatimuksen 8 mukainen menetelmä, tunnettu siitä, että päätelaitteen ja liittymäverkon välinen yhteys toteutetaan langattomana.
22. Patenttivaatimuksen 1 mukainen menetelmä verkossa, jossa 25 käytetään reititysprotokollana mobile IP -protokollaa, jolloin päätelaitteen kytkeytyessä liittymäverkkoon se saa tilapäisen osoitteen, jonka se rekisteröi lähettämällä kotiagentilleen rekisteröintisanoman liittymäverkon vierailuagentin kautta, tunnettu siitä, että mainittu aloitussanoma synnytetään liittymäver- kon vierailuagentissa vasteena rekisteröinnille.
23. Patenttivaatimuksen 14 mukainen menetelmä verkossa, jossa käytetään reititysprotokollana mobile IP -protokollaa, jolloin päätelaitteen kytkeytyessä liittymäverkkoon se saa tilapäisen osoitteen, jonka se rekisteröi lähettämällä kotiagentilleen rekisteröintisanoman liittymäverkon vierailuagentin kautta, tunnettu siitä, että mainittu aloitussanoma synnytetään liittymäver-35 kon vierailuagentissa vasteena rekisteröinnille, ja että laskutuspalvelimet 38 104668 toimivat mobile IP -protokollan mukaisina kotiagentteina ja liittymäpalvelimet eri aliverkkoja palvelevina vierailuagentteina, joiden avulla ilmoitetaan kunkin päätelaitteen omalle laskutuspalvelulle, missä aliverkossa kyseinen päätelaite kulloinkin on.
24. Patenttivaatimuksen 1 mukainen menetelmä verkossa, jossa on käytössä IPv6-reititysprotokolla, tunnettu siitä, että verkossa käytetään ainakin yhtä tilapäisiä osoitteita allokoivaa palvelinta (DHCP_S) siten, että - päätelaitteen kytkeytyessä liittymäverkkoon se rekisteröityy osoitteita allokoivalle palvelimelle, ja 10. mainittu aloitussanoma synnytetään osoitteita allokoivalla palveli mella vasteena rekisteröinnille.
25. Patenttivaatimuksen 6 mukainen menetelmä, tunnettu siitä, että kun päätelaitteella on pääsy palveluja tarjoavaan verkkoon, päätelaitteelle lähetetään maksupyyntösanoma aina, kun palvelun aikana siirretty datamäärä 15 on saavuttanut ennalta määrätyn rajan.
26. Patenttivaatimuksen 25 mukainen menetelmä, tunnettu siitä, että päätelaitteelle lähetetään tieto maksupyyntösanomaa vastaavasta datamäärästä tai maksupyyntösanomaa vastaavan maksun suuruudesta.
27. Patenttivaatimuksen 5 mukainen menetelmä, tunnettu siitä, 20 että laskutuspalvelu määrittää päätelaitteelta vastaanottamansa, maksua indikoivan laskutussanoman jälkeen käyttäjän sen hetkisen velan, ja mikäli velka vielä kyseisen maksun jälkeen ylittää tietyn ennalta määrätyn rajan (B), laskutuspalvelu lähettää päätelaitteelle sanoman, joka ilmoittaa, että päätelaitteelta edellytetään lisämaksua.
28. Patenttivaatimuksen 14 mukainen menetelmä, tunnettu siitä, että päätelaitteen ja palveluja tarjoavan verkon välisen yhteyden sulkeminen aloitetaan laskutuspalvelimelta vasteena ennalta määrättyihin tapahtumiin, joihin kuuluvat ainakin tapahtumat, joissa (i) laskutuspalvelu ei vastaanota laskutussanomia hyväksyttävällä tavalla ja (ii) laskutuspalvelu vastaanottaa 30 erillisen lopetussanoman päätelaitteelta.
29. Patenttivaatimuksen 28 mukainen menetelmä, tunnettu siitä, että liittymäpalvelimelle annetaan lisäksi valtuudet sulkea itsenäisesti päätelaitteen ja palveluja tarjoavan verkon välinen yhteys vasteena ennalta määrättyihin tilanteisiin. 35 39 104668
30. Järjestelmä liittymäpalvelun toteuttamiseksi tietoliikenneverkossa, joka käsittää liittymäverkon (N1), joka on ainakin osaksi yhteydetön, palveluja tarjoavan verkon (N2) ja käyttäjien käytössä olevia päätelaitteita, jotka on kytketty liittymäverkon kautta palveluja tarjoavaan verkkoon, joka järjestelmä 5 käsittää - kytkentäelimet (SL) käyttäjän päätelaitteen kytkemiseksi liittymäverkon ja palveluja tarjoavan verkon yhdistävän rajapintaelimien (R1) kautta palveluja tarjoavaan verkkoon, ja - laskutustietueiden generointielimet, joiden avulla synnytetään las-10 kutustietueita (CDR) vasteena käyttäjän kytkemiselle palveluja tarjoavaan verkkoon, tunnettu siitä,että - järjestelmässä on palvelun käynnistyselimet liittymäpalveluistunnon aloituksen indikoivan aloitussanoman synnyttämiseksi laskutusta varten silloin, 15 kun käyttäjä ottaa päätelaitteen kautta yhteyden liittymäverkkoon, - järjestelmässä on allekirjoituselimillä (SLI) varustetut laskutus-sanomien generointielimet (CG) digitaalisen allekirjoituksen lisäämiseksi generoituun laskutussanomaan, - järjestelmässä on tarkistuselimet (WD) generoitujen laskutus- 20 sanomien tarkistamiseksi, ja - kytkentäelimet (SL) ovat vasteellisia tarkistuselimille (WD) päätelaitteen kytkemiseksi palveluja tarjoavaan verkkoon silloin, kun laskutussanomia . , generoidaan hyväksyttävällä tavalla.
31. Patenttivaatimuksen 30 mukainen järjestelmä, tunnettu siitä, 25 että laskutussanomien generointielimet ovat päätelaitteissa.
32. Patenttivaatimuksen 30 mukainen järjestelmä, tunnettu siitä, että se käsittää lisäksi identifiointielimet (CR) päätelaitetta kulloinkin käyttävään käyttäjään liittyvän tilaajan identifioimiseksi.
33. Patenttivaatimuksen 31 mukainen järjestelmä, tunnettu siitä, 30 että identifiointielimet (CR) ovat päätelaitteiden yhteydessä.
34. Patenttivaatimuksen 30 mukainen järjestelmä, tunnettu siitä, että tarkistuselimet käsittävät ainakin yhden erillisen laskutuspalvelun (WD), jolle useat päätelaitteet lähettävät laskutussanomia.
35. Patenttivaatimuksen 30 mukainen järjestelmä, tunnettu siitä, 35 että kytkentäelimet käsittävät verkossa olevan erillisen palvelimen (SL), joka 40 104668 ohjaa rajapintaelimenä toimivaa reititintä (R1) laskutuspalvelimen lähettämien sanomien mukaisesti.
35 104668
36. Patenttivaatimuksen 34 mukainen järjestelmä, tunnettu siitä, että identifiointielimet käsittävät päätelaitteeseen kytketyn älykortin lukijan (CR) 5 ja käyttäjän käytössä olevan älykortin, jolle on talletettu ainakin käyttäjään liittyvän tilaajan tunniste.
37. Patenttivaatimuksen 30 mukainen järjestelmä, jossa välitetään IP-paketteja,tunnettu siitä,että - järjestelmässä on käytössä IP-tason liikkumista tukeva reititysproto-10 kolia, jonka mukaisesti päätelaite suorittaa rekisteröitymisen kytkeytyessään liittymäverkkoon, ja - palvelun käynnistyselimet ovat vasteellisia rekisteröitymiselle, jolloin aloitussanoma generoidaan vasteena suoritetulle rekisteröitymiselle.
38. Patenttivaatimuksen 37 mukainen järjestelmä, jossa reititysproto-15 kolia on mobile IP, jolloin järjestelmässä on ainakin yksi kotiagentti ja ainakin yksi vierailuagentti, tunnettu siitä, että palvelun käynnistyselimet on sijoitettu järjestelmän vierailuagenttiin.
39. Patenttivaatimuksen 37 mukainen järjestelmä, jossa reititysprotokolla on IPv6, tunnettu siitä, että järjestelmässä on ainakin yksi osoitteita 20 allokoiva palvelin (DHCP_S), jolle päätelaitteet rekisteröityvät, ja että palvelun käynnistyselimet on sijoitettu mainitulle palvelimelle. • · • · 41 104668
FI981031A 1997-07-14 1998-05-08 Liittymäpalvelun toteuttaminen FI104668B (fi)

Priority Applications (7)

Application Number Priority Date Filing Date Title
FI981031A FI104668B (fi) 1997-07-14 1998-05-08 Liittymäpalvelun toteuttaminen
AU84433/98A AU741703B2 (en) 1997-07-14 1998-07-14 Implementation of access service
JP2000505712A JP2001512926A (ja) 1997-07-14 1998-07-14 アクセスサービスの遂行
PCT/FI1998/000590 WO1999007108A2 (en) 1997-07-14 1998-07-14 Implementation of access service
CN98808149.0A CN1267414A (zh) 1997-07-14 1998-07-14 接入业务的实现
EP98935049A EP1005737A2 (en) 1997-07-14 1998-07-14 Implementation of access service
NO20000170A NO20000170L (no) 1997-07-14 2000-01-13 Implementering av aksesstjeneste

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
FI972980A FI104667B (fi) 1997-07-14 1997-07-14 Liittymäpalvelun toteuttaminen
FI972980 1997-07-14
FI981031 1998-05-08
FI981031A FI104668B (fi) 1997-07-14 1998-05-08 Liittymäpalvelun toteuttaminen

Publications (3)

Publication Number Publication Date
FI981031A0 FI981031A0 (fi) 1998-05-08
FI981031A FI981031A (fi) 1999-01-15
FI104668B true FI104668B (fi) 2000-04-14

Family

ID=26160423

Family Applications (1)

Application Number Title Priority Date Filing Date
FI981031A FI104668B (fi) 1997-07-14 1998-05-08 Liittymäpalvelun toteuttaminen

Country Status (7)

Country Link
EP (1) EP1005737A2 (fi)
JP (1) JP2001512926A (fi)
CN (1) CN1267414A (fi)
AU (1) AU741703B2 (fi)
FI (1) FI104668B (fi)
NO (1) NO20000170L (fi)
WO (1) WO1999007108A2 (fi)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5895471A (en) 1997-07-11 1999-04-20 Unwired Planet, Inc. Providing a directory of frequently used hyperlinks on a remote server
US6065120A (en) 1997-12-09 2000-05-16 Phone.Com, Inc. Method and system for self-provisioning a rendezvous to ensure secure access to information in a database from multiple devices
FI106420B (fi) 1998-10-19 2001-01-31 Nokia Networks Oy Palvelun ohjaus tietoliikenneverkossa
US7167860B1 (en) 1999-03-25 2007-01-23 Nortel Networks Limited Fault tolerance for network accounting architecture
CA2302000A1 (en) * 1999-03-25 2000-09-25 Nortel Networks Corporation Distributed aggregation
US7243143B1 (en) 1999-03-25 2007-07-10 Nortel Networks Limited Flow probe connectivity determination
DE19941461A1 (de) 1999-08-31 2001-03-08 Deutsche Telekom Mobil Verfahren zur präventiven und/oder aktuellen Anzeige von Übertragungskosten bei der Datenübertragung von Internet- und Onlinedaten
DE19944906B4 (de) * 1999-09-10 2004-03-18 Siemens Ag Verfahren zum Überwachen eines durch mindestens zwei gebührenrelevante Einflußgrößen bestimmten Verbindungslimits eines Teilnehmers in einem intelligenten Netz
EP1089519A3 (en) * 1999-09-29 2002-08-21 Phone.Com Inc. Method and system for integrating wireless and Internet infrastructures to facilitate higher usage of services by users
JP3734661B2 (ja) * 2000-01-31 2006-01-11 三菱電機株式会社 ネットワークによるデジタルコンテンツ配信システム
HK1023695A2 (en) * 2000-02-19 2000-08-11 Nice Talent Ltd Service sign on
WO2001082549A2 (de) * 2000-04-20 2001-11-01 Ip-Control Gmbh I. Gr. Verfahren und vorrichtung zur dynamischen zugriffskontrolle von internetdiensten
DE10022934A1 (de) * 2000-05-11 2001-11-22 Olaf Scharmann Verfahren zum Abrechnen von kostenpflichtigen Diensten im Internet
WO2001086907A2 (de) * 2000-05-12 2001-11-15 Geiger, Stefan Telekommunikationssystem zum internetzugang mit protokoll zu seinem betrieb
GB0028113D0 (en) * 2000-05-15 2001-01-03 Band X Ltd Communication system and method
FI110899B (fi) * 2000-06-21 2003-04-15 Sonera Oyj Menetelmä ja järjestelmä tiedonvälitykseen
WO2002003657A2 (en) * 2000-06-30 2002-01-10 Hughes Electronics Corporation Apparatus and method for facilitating residential broadband communications
US7002952B2 (en) * 2001-05-25 2006-02-21 Sprint Communications Company L.P. Usage-based billing for voice over packet communications
JP2004533190A (ja) * 2001-06-08 2004-10-28 フォースパス インコーポレイテッド 双方向で開始する無線デバイスとのデータ通信のための方法およびシステム
DE10244463B4 (de) * 2002-09-24 2004-11-18 Siemens Ag Verfahren zum Abrechnen einer kostenpflichtigen Nutzung von durch einen Dienstanbieter angebotenen Diensten
CN100433774C (zh) * 2003-05-21 2008-11-12 华为技术有限公司 一种话单数据的预处理方法及装置
WO2005086484A1 (de) 2004-03-09 2005-09-15 Siemens Aktiengesellschaft Vorrichtung und verfahren zur vergebührung von über ein pakentnetz geführten verbindungen
WO2006010382A1 (en) * 2004-07-30 2006-02-02 Telecom Italia S.P.A. Method and system for controlling operation of a communication network, related network and computer program product therefor
US8005457B2 (en) * 2005-09-02 2011-08-23 Adrian Jones Method and system for verifying network resource usage records
CN101047515B (zh) * 2006-03-31 2010-10-27 华为技术有限公司 一种应用业务的计费关联方法及系统
CN1925530B (zh) * 2006-09-06 2011-01-05 华为技术有限公司 记录话单的系统及方法
WO2008122649A2 (en) * 2007-04-10 2008-10-16 Apertio Limited Improved timing device and method
US8477612B2 (en) 2008-04-03 2013-07-02 Ntt Docomo, Inc. Data relay device and data relay method
CN104954327B (zh) * 2014-03-27 2019-02-22 东华软件股份公司 用于终端连接控制的服务器及方法、终端及方法、和系统
US11729588B1 (en) 2021-09-30 2023-08-15 T-Mobile Usa, Inc. Stateless charging and message handling
CN116629864B (zh) * 2023-04-27 2024-04-16 北京熠智科技有限公司 一种隐私计算场景下api服务收费方法、平台及存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2020574C (en) * 1989-07-08 1995-05-23 Morihiro Katsurada Communication charge manageable digital communication unit and a method of managing communication charge
EP0693836A1 (en) * 1994-06-10 1996-01-24 Sun Microsystems, Inc. Method and apparatus for a key-management scheme for internet protocols.
US5621728A (en) * 1994-09-12 1997-04-15 Bell Atlantic Network Services, Inc. Level 1 gateway controlling broadband communications for video dial tone networks
US6141652A (en) * 1995-10-10 2000-10-31 British Telecommunications Public Limited Company Operating apparatus

Also Published As

Publication number Publication date
FI981031A0 (fi) 1998-05-08
AU8443398A (en) 1999-02-22
FI981031A (fi) 1999-01-15
WO1999007108A3 (en) 1999-04-29
NO20000170L (no) 2000-03-13
JP2001512926A (ja) 2001-08-28
WO1999007108A2 (en) 1999-02-11
EP1005737A2 (en) 2000-06-07
NO20000170D0 (no) 2000-01-13
CN1267414A (zh) 2000-09-20
AU741703B2 (en) 2001-12-06

Similar Documents

Publication Publication Date Title
FI104668B (fi) Liittymäpalvelun toteuttaminen
FI104667B (fi) Liittymäpalvelun toteuttaminen
FI113224B (fi) Laskutuksen toteuttaminen tietoliikennejärjestelmässä
CN100521608C (zh) 按连接付费系统和基于按连接付费建立连接的方法
CN102124455B (zh) 向网络中的分组流提供服务
CN101069402B (zh) 透明地验证访问web服务的移动用户的方法和系统
EP1728379B1 (en) Method and apparatus to provide charging for ad-hoc service provisioning between trusted parties and between untrusted parties
US20040073651A1 (en) Secure system and method for providing a robust radius accounting server
CN1333551C (zh) 网络统计信息服务系统及因特网接入服务器
US20030035409A1 (en) Method and apparatus for providing service selection, redirection and managing of subscriber access to multiple WAP (Wireless Application Protecol) geteways simultaneously
US8621582B2 (en) Authentication system
US20050111641A1 (en) Telecommunications network having number portability
EP1452050A1 (en) A method for providing service based on service quality and an accounting method in a mobile communication system
EP2289002A1 (en) Carrier-grade peer-to-peer (p2p) network, system and method
JP3570501B2 (ja) ネットワークシステム及びパケットデータ伝送方法
US7336941B1 (en) System and method for unified accounting for wireless communication networks
WO2003092317A1 (en) Method and network system for charging a roaming network subscriber
WO2000042791A1 (en) Wirelesss network and methods to be used therein
EP1281269A2 (en) Method of charging for resource usage in a gprs network
EP1490999B1 (en) Method and system for construction and communication of data on network access and service transactions in a telecommunication network
KR20020039974A (ko) 지능망 시스템의 과금 방법
EP1320236A1 (en) Access control for network services for authenticating a user via separate link
JP2004517525A (ja) ネットワークにおけるサービスおよびリソースについてのフレキシブルな課金方法
EP1551150B1 (en) A method for determining whether a transaction is completed correctly, a network node and a data transmission network for carrying out the method
KR19980050165A (ko) 대용량 통신처리 시스템의 인터넷 과금 처리방법