FI104668B - Implementation of the subscription service - Google Patents

Abstract

The invention relates to the implementation of access service in a telecommunications network comprising an access network, a network providing services, and user-operated terminals (TE1... TE3, PC) connected to the access network. The access service is provided by connecting the user terminal to the network providing the services through interface elements that connect the access network to the network providing the services, and in response to the access service at least one charging record is generated for transmission to the billing means (BS) for billing the access service subscriber for the access service provided. To ensure that reliable and versatile billing can be incorporated into the system in a connectionless network, the start-up of a single access service session is indicated by generating a start-up message for charging purposes at the moment when the user connects to the access network through the terminal, charging records with a digital signature associated with the said access service session are generated and the generated signatures verified. The terminal is given access to the network providing the services, if the said messages are generated in an acceptable manner. The object generating the start-up messages can be modified according to the type of network involved.

Description

1 104668

Implementation of the subscription service

Field of the Invention

The invention relates generally to the implementation of an access service in a telecommunications system, in particular to billing in connection with an access service. In this context, an access service is a service that provides a network user, e.g., a subscriber to a telephone network or a user of a local area network, with access to a service providing network, such as an Internet network, or a part of the network from which services are provided.

10

Background of the Invention

Optical fiber is a natural choice for backbone transmission media because backbone connections typically require high throughput, long transmission distances used, and there are often ready routes for cables. Even with subscriber-15 connections (the local-to-subscriber line), the situation is rapidly changing, as various multimedia services requiring high data rates will also be commonplace for the private consumer.

However, no significant savings can be expected on the construction costs of the future broadband network, as these costs are mainly due to cable installation costs. However, it would be desirable to build as much optical fiber as possible on the local area side as it is clearly visible that it will be needed in the future.

However, the cost of renewing a local area network is very high, and in terms of time, we are talking about decades. The high cost is the worst barrier to fiber penetration in the local area.

For the reasons mentioned above, the utilization of a conventional subscriber line (metal twisted-pair cable) for high-speed data transmission, i.e. for speeds that are clearly ISDN-', has been increasingly investigated. 30 basic speeds (144 kbit / s). Indeed, current ADSL (Asym metric Digital Subscriber Line) and HDSL (High Bit Rate Digital Subscriber Line) technologies offer new opportunities for high-speed data and video transmission over paired telephone networks to subscriber terminals.

The ADSL transmission connection is asymmetric in that the transmission rate from ver-35 to the subscriber is significantly higher than from the subscriber to the network. ADSL technology is mainly intended for various subscription services (so-called "2 104668 demancf services"). In practice, the ADSL transmission rate from the network to the subscriber is in the order of 2-6 Mbit / s and from the subscriber to the network in the range of 16-640 kbit / s ).

HDSL transmission technology involves the transmission of a 2 Mbit / s digital signal 5 on a metal pair cable. HDSL represents symmetric technology, that is, the transmission rate is the same in both directions. A single HDSL transceiver system comprises transceivers using echo cancellation technology that communicate with each other through a bidirectional two-way transmission. In the HDSL transmission system, such single transceiver systems 10 may be one, two or three in parallel, whereby in the case of two or three parallel pairs, each of the parallel transmission links will have a speed of 2 Mbit / s; 784 kbit / s for three parallel pairs and 1168 kbit / s for two parallel pairs. International recommendations define how to transmit 2 Mbit / s signals in the HDSL system, such as VC-12 signals from the SDH network or 2048 kbit / s signals according to CCITT recommendations G.703 / G.704.

Because the above solutions only provide speeds of the order of 1-6 Mbit / s, technology has also been sought for a subscriber line dual cable that would allow ATM speeds (10-55 Mbit / s). Indeed, the European Telecommunications Standards Institute (ETSI) is working on a specification for Very High Data Rate Digital Subscriber Line (VDSL) devices that enable such speeds. VDSL technology can provide both symmetric and asymmetric connections.

25 The aforementioned technologies for transferring high-speed data through the game are commonly known as xDSL. Thus, while it is not yet possible to provide broadband services to end users through optical fiber, these technologies allow existing telephone operators to provide such services through existing subscriber lines. As ADSL 30 currently looks like the most promising technology for broadband services:. . implementation, it is used as an example of the access technology by which the services are provided.

The ADSL Forum has defined a general network model for xDSL connections, illustrated in Figure 1. A device that connects to a subscriber line at a subscriber end is called an ATU-R (ADSL Transmission Unit - Remote) and a device that connects to a subscriber line at a network end (e.g. in a local exchange) is called ATU-C (ADSL Transmission Unit - Central). These devices 3,104,668 are also called ADSL modems (or ADSL transceivers) and form an ADSL link between them. High-speed data from an ADSL connection is connected to the subscriber line so that the subscriber can still use legacy narrowband POTS / ISDN services, but in addition has a high-speed data connection. These narrowband and wideband services are separated by a filter PS (POTS-Splitter) which performs frequency separation of ADSL signals and narrowband signals.

The end-user terminals TE may be of several types, e.g., cable TV network terminals TE1, personal computers 10 TE2 or ISDN telephones TE3. For each terminal there is a service module SMi (i = 1 ... 3) which performs the functions related to the terminal matching. In practice, such service modules can be e.g. Set Top Boxes, PC Interfaces or LAN Routers. The subscriber premises distribution network PDN (Premises Distribution Network) connects the ATU-R to the service modules.

15 At the network end of the ADSL link, the access node AN (Access

Node) provides a focal point for narrowband and broadband data, which concentrates traffic from different service systems over different networks. The access node is located, for example, in the center of a telephone network.

In Figure 1, reference symbol A denotes the share of the private network, reference symbol B denotes the share of the public network and reference symbol C denotes the subscriber network (telephones are of course with the subscriber).

The problem with a network like the one described above is how the end-user is charged for the subscription service (i.e., the use of the local loop) when using services provided by service systems, such as the Internet. 25 Billing is to be based on time or amount of data transferred, or both. The problem is, firstly, that the network may be offline. In other words, there are no connection set-up and release messages (such as SETUP and RELEASE) in the network, so that billing cannot be performed, as is the case with the current telephone network, based on call set-up and release events. Second, manufacturers of xDSL modems have not equipped their devices to enable billing based on time or amount of data transmitted. Thus, the modems do not provide the information needed for billing.

It should also be noted that if the terminal is an ISDN terminal or an ATM-35 terminal, each session begins with a SETUP message and ends with a RELEASE message, whereby time-based billing can be implemented in a conventional manner. Em. thus, the problem concerns networks in which the network is disconnected between the terminal and the access node, or at least with respect to the link between the terminal TE and the distribution network PDN. Namely, it is possible to implement the transmission path between the terminal and the access node, e.g., such that the portion between the access node and the ATU-R is interconnected (e.g., ATM-based) and the portion between the ATU-R and 5 terminals is unconnected (e.g. ).

Also in offline systems that support terminal mobility, the issue of how the end-user is charged for the subscription service is a problem. Namely, the protocols supporting the mobility of the terminal device (e.g. mobile IP, IP = Internet Protocol) do not allow the users of the network 10 to be restricted on the basis of a certain criterion, e.g., who are the paying customers.

Em. the problem is, in particular in the case of fixed terminals, the situation where several different customers use the same local loop, whereby the customers cannot be differentiated according to the local loop. This is the case, for example, where the public is provided with access to broadband services by placing a terminal in a public space, such as a library or shopping mall. The same problem also applies to situations where you want to work from home, for example, by connecting only to the home network of your employer. Again, it is not possible to detect that billing for this connection session should be addressed to the employer instead of to the terminal 20 user. Thus, the system cannot distinguish when a person uses a so-called connection. as a business user (whose bills are paid by the employer) and when as a private user (who pays the bills themselves).

In the future, the term "user" will be used to refer to the person * 25 who uses the terminal and the term "subscriber" to refer to the organization or person paying for the use of the service. The user may also be a subscriber.

Summary of the Invention

The object of the invention is to overcome the drawbacks described above. 30 and provide a solution that enables the subscription service to be implemented: on a wireless network, using the simplest hardware possible, allowing the service to be connected to reliable and well-functioning billing. It is also intended to provide a solution that is suitable both for networks supporting the mobility of the terminal and also for situations where the invoice 35 must be sent to an address other than the address specified by the subscriber line or to the subscriber.

These objects are achieved by the solution defined in the independent claims.

The idea of the invention is, firstly, to indicate, by means of a start message, the start of a one-time service session when a user accesses the network. The generating object of the start message may change according to the type of system 5 involved, and the start message may be sent in many different ways to the bodies that handle billing. Further, the idea is to generate billing messages related to a service session initiated by the originating message from the terminal to the network, e.g., at regular intervals, provided with a subscriber-specific digital signature and to allow (or block) user access to the network 10, depending on whether the terminal generates these billing records.

In this way, e.g. limiting network users to paying users only, and separating users from the same source address for billing purposes. If multiple users are using the same subscriber line, the terminal-15 device informs the subscriber identity associated with each user using it to verify signatures with the correct subscriber information.

The system is designed in such a way that all the elements relevant to data security can be easily implemented: authentication, Integrity, non-repudiation of the data 20 (the transferee will not be denied participation, non-repudiation) and privacy ( eavesdropping cannot be interpreted as data received).

... A significant additional benefit of the system is that it can also bill for services that the customer uses after having accessed the service provider's network, such as the Internet. At the same time, the customer can view the billing information for the connection itself and the services used on the screen of his terminal device and have all the billing information broken down into the same periodic (eg monthly) bill.

The system is also able to utilize (for example over the telephone network) • 30 existing billing systems and does not require new solutions or investments in this respect.

List of figures

In the following, the invention and preferred embodiments thereof will be described in more detail with reference to Figures 2 ... 15 in the preamble of the accompanying drawings, in which Figure 1 illustrates a generic network model defined by the ADSL Forum, Figure 2 illustrates a network environment Figures 3a and 3b illustrate a system according to the invention in the network environment of Fig. 2, Figures 3c and 3d illustrate alternatives to the systems of Figures 3a and 3b, Fig. 4 illustrates a dialog for a subscriber terminal, Fig. 5 illustrates message exchange between different system components. Figure 7a illustrates the main window of the terminal, Figure 7b illustrates the invoice to be sent to the customer, Figure 7c illustrates the debt incurred by the user when not all payments are received. Figure 7d illustrates the debt incurred by the user when the billing server and terminal clocks run at different rates; Figure 8 illustrates the structure and content of the billing record; Figure 25 illustrates a structure of an access server as a functional block diagram; Figure 12 illustrates a message exchange related to a preferred additional feature of the system; Figure 13 illustrates a message exchange between different components of the system when using a mobile IP protocol in the network. level mobility, Figure 14 illustrates message exchange between different system components when using IPv6 protocol in a network, and Figure 35 illustrates one such embodiment of the invention. 7 104668 which supports IP-level mobility.

Detailed Description of the Invention

In the following, the operating environment of the invention will be described in more detail with reference to the example of Figure 2, in which the general network model of Figure 1 is implemented in a simplified manner. The ISP, which is referred to herein as the access service provider, is assumed to be the operator of the Internet. This example illustrates only one terminal device, typically a personal computer PC, which is 10 equipped with a network card (e.g. Ethernet card) and connected via a LAN cable LC1 (e.g. 10BaseT) to an ADSL modem A1 which is connected via a conventional subscriber line SL. for the ADSL modem A2 on the premises of the access service provider. The subscriber line pairing cables terminate at the telephone operator exchange, so for maximum distance 15 modem A2 must be present at the exchange.

In this case, it is therefore assumed that the operator providing the Internet services is also a telephone operator. However, the POTS filter allows a telephone operator to provide only telephone services and to lease the connection to another service provider for the purpose of broadband services. In the future, competition law may even force telephone operators to do so if they do not themselves provide broadband services.

Thus, the network PDN in the network of Figure 2 is reduced to a point-to-point connection between the terminal and the access service provider. Modem A2 is connected via LAN cable LC2 (e.g., 10BaseT) 25 to the service provider's LAN switch SW, which connects the various subscriber connections to the access service provider's network APN, which is connected via gateway router R1 to the Internet. The portion of the access network in Figure 2 is denoted by the reference symbol N1 and the services or services'; ; external network with reference N2. The access network can also be thought of as that part of the network 30 that provides the terminals with access to the service part of the network (so that the router R1 can also be thought of as part of the access network).

Thus, in this example, Ethernet frames are transferred over an ADSL connection and the modem pair acts as a bridge between the subscriber LAN segments and the access service provider LAN segments. In practice, the LAN switch may have 35 designs, e.g., Centillion 100 manufactured by Bay Network, USA or Catalyst 3000, 8 104668 manufactured by Cisco Systems, USA.

Figure 3a illustrates how the method of the invention is applied in the network environment of Figure 2. The end user terminal (which is a personal computer) has a smart card reader CR and 5 each customer has its own smart card which identifies the customer (subscriber). The terminal also includes a Program Library that communicates with the smart card and software that generates a digital signature-based billing record at certain intervals (e.g., every minute) and sends it to the network.

10 The billing service WD is connected to the APN's APN network, which checks and collects billing records generated by the terminals. There may be several separate billing services in the network, but each terminal has a dedicated billing service. A billing service (MS) is associated with its billing service, in which all billing records 15 accepted by the billing service are stored. At certain intervals, the accumulated billing records are transferred to the billing system BS, which is preferably an existing billing system in the public switched telephone network PSTN or e.g. an existing billing system located in a broadband network. The network NW1 shown in the figure at a general level, through which the billing service 20 is connected to the billing system, may thus be a public telephone network or e.g. a packet or data network. As Internet billing systems become more widespread, it is also possible to use such (Internet-based) billing systems. This alternative is shown in the figure by a dashed line. The billing server may also be directly connected to the billing system. Prior to migration to the billing system, billing records may be temporarily stored in a temporary storage mass storage MS1, the significance of which will be described below.

In addition, a subscriber server SL is connected to the access service provider's network, which serves to open and close the Internet connections by controlling the router 30 / hub R1, which acts as a connecting link between the service provider network and the access network.

In a preferred embodiment of the system, it also includes a Dynamic Host Configuration Protocol (DHCP) server known per se for dynamically allocating IP addresses to terminals. In dynamic address allocation-35, the address returns to the number of addresses to be allocated when the connection is 9 104668 disconnected or when a predetermined "lease time" of the address has expired. (DHCP is described in R. R. Droms: Dynamic Host Configuration Protocol, RFC-1541, October 27, 1993.)

The billing and subscription servers are preferably in the premises of the subscription service provider and do not need to be physically separate but can be integrated into the same machine. In particular, a billing service can also be located on the Internet side, especially if the billing server is owned by a separate organization that provides billing services to several different access service providers. Logically, the location of the billing server is not meaningful, but in practice, the choice of location is influenced by e.g. The following factors. First, it is advantageous for the billing server to be connected to or close to the public telephone network in order to provide the billing server with easy access to an existing billing system in the telephone network. In addition, for efficiency, it is essential that the connection between the terminal and the billing service is as fast as possible and that the latency is manageable (which is not the case today if the billing service is deeper on the Internet, for example). Furthermore, since the system is intended to provide a local service (in a geographically limited area) by sending customers a service invoice, for example, on a monthly basis, it does not make sense for the billing service 20 to be far from their customers.

In Figs. 2 and 3a, the POTS filter (cf. Fig. 1) is not shown because the POTS filter can also be integrated into the ATU.

Figure 3b illustrates an alternative system similar to that of Figure 3a but with a router R2 between the APN of the access service provider network and the switch SW, in this case the router controlled by the access server. The access control point can thus be located at either of the two routers. Router R2 routes traffic from terminals to either the servers in the network of the access service provider or to router R1. It is also possible that the access control point is at both routers. This may be the case, for example, when some services are in the access network and some are elsewhere.

Figures 3c and 3d show two other alternative networks. In the case of Figure 3c, a plurality of different access service providers are connected to a common router R1 which is connected via a separate access network ACN to the 35 routers controlled by the access server. In the case of Figure 3d, the providers of the access service 10 104668 have their own routers (not shown), so their networks are directly connected to the access network.

According to an advantageous embodiment of the invention, the transmission links between the access server and the access control point and the access server and the billing interface 5 are secured in such a way that the privacy of the information is safeguarded. This can be accomplished either physically using the present invention. dedicated transmission media that is not accessible to others (point-to-point connections), transmission channels with encryption between the parts. Certified transmission links prevent deliberate misuse of system 10.

The operation of the system of the invention will now be described in more detail with reference to Figures 4-6. The description assumes that the system is in accordance with Figure 3a.

Billing can begin when the user inserts his smart card into a reader connected to the terminal 15. As a result, the program on the terminal opens a window on the terminal screen called a dialog. Figure 4 illustrates an example of a dialog box. From the drop-down list of the window, the user can select the type of connection they need. Connections can be divided into different types, for example, so that in addition to a complete Internet connection, there are other types of connections, such as a continuous connection to an email server, whereby the user is informed of incoming email messages in real time. The latter service can be considerably cheaper (eg 5 mpk a day) than a full Internet connection. Such limited connections can also be made to a location other than the mail server, such as the workstation's LAN server. From the menu, the user can also select, for example, the operator of his choice or choose between an encrypted and a non-encrypted connection.

The services available from the drop-down list in the dialog box can be stored on the terminal or on the smart card, so the dialog can be opened before the terminal connects to the network. Alternatively, the terminal 30 may automatically retrieve from the access server, billing service, or other server in the network the latest service list as soon as the user inserts his smart card into the reader device. This option entails a slightly longer delay, but on the other hand, the user always has the latest services to choose from and the latest prices are available. The service options included in the dialog can also be automatically updated during connection 11 104668, so that the terminal (or smart card) always stores the services that were available during the last connection session.

The smart card contains the subscriber profile information, which in this example is the subscriber's name (e.g. in ascii format), the subscriber's identification number, the 5 subscriber's public and secret keys, and the subscriber's invoice balance. The public key is both readable and available on the card. Instead, the secret key is only available (cannot be read from the card). Usability refers to the fact that the application in question. the key can be used to make and verify a digital signature, ie to encrypt and decrypt data. The invoice balance is the amount paid by the subscriber 10 (this amount can be zeroed at any time so it is not the same as the final balance of the correct invoice, ie it serves only as a reference for the user of the terminal. that the messages really come from the billing service.

15 Subscriber information such as name, identifier and secret key may be stored in the terminal's memory (eg, computer hard disk or floppy disk) instead of the smart card if security is compromised.

Figure 5 illustrates communication between different components of the system. When the user clicks the connect button in the dialog, the terminal-20 device software sends a service request message to lnit_Service Interface Server-Melie SL (Figure 5). The service request message includes at least the current IP address of the terminal (ClientAddr) and the type of service selected from the above menu (Type). The access server checks the message and forwards the START message to the billing server WD. The START message comprises the 25 current IP addresses (ClientAddr) of the user, the address to be accessed at the time the user stops paying (ServerAddr), the service identifier (Serviceld), the access server identifier (Serverld) and the (temporary) identifier (Connld). ) which identifies the connection between the servers: different message types (START and OK and CANCEL messages, described below). The lnit_Service and START messages are referred to herein as start messages indicating the start of a one-time subscription service session for the subscription server and the billing server.

The billing service WD generates, on the basis of the information it receives, a certain type of billing record (CDR, Charging Data Record) which contains the contract information relating to the subscription session, e.g. co. session number 12 104668, which identifies this subscription service session. The structure of this billing record is shown in the following description which applies to the structure of all billing records. This initiating billing record (contract CDR) is sent by the billing service to the terminal (arrow A, Figure 5).

5 The terminal returns the contract billing record back to the billing server, however, with a digital signature (Figure 5, arrow B). Digital signature refers to a known key-pair encryption algorithm where the encryption is performed with a secret key, whereby anyone can decrypt the message with a public key. In this way, the confidentiality of the 10 messages is not achieved, but one can be sure that the message has come from the correct source. Therefore, the sender cannot deny sending the message. A digital signature usually does not encrypt the entire message, but only a digest of the message, which is a kind of checksum. However, this "hash" is very strong in encryption technology and the outsider is unable to create a message that would produce a similar identical "hash". The sender's secret key encrypts the "hash" and the timestamp to form a digital signature. However, since the invention is not related to the signature, its implementation will not be described in more detail herein.An interested reader 20 will find more detailed information in many artworks in the field (e.g. ) The terminal may automatically sign (accept) the contract CDR as described above, or upon receiving the contract CDR from the billing server, it may open, for example, a separate 25 contract window asking for the user's acceptance of the subscription service agreement. visit If the user clicks the window accept button, the terminal sends the signed contract CDR to the billing server.

Upon receipt of the signed contract CDR, the billing service WD performs a signature check in a manner known per se to verify that the CDR is correct. For this purpose, the billing service retrieves the subscriber database from its subscriber database. client's public key (arrow C).

Finding the right public key can be done in many different ways. First, the terminal may, upon receipt of the contract CDR for signature, retrieve the customer's (subscriber's) name and identification number from the smart card and attach the 35 CO. information to the signed contract CDR which it sends to the billing service 13 104668 lime. The billing server uses the identification number to retrieve the correct public key from its subscriber database. Alternatively, the billing server identifies the customer's identity and the right to use the system prior to forming the contract CDR. When the billing server receives the START message from the interface server 5, it sends an authentication request (not shown) to the IP address contained in the START message. In addition to the customer identification number, the terminal may include other customer-specific information in its response, sign the response, and send the signed response to the billing service. The advantage of this option is that the billing server 10 knows the customer's identity before entering into a contract, which allows for customized contracts (e.g. different prices for different customers). The downside is, of course, the need for two extra messages, which slows down the connection. A third option is that the terminal already includes the customer identification number in the 15 lnit_Service message and the access server forwards the identification number to the billing service in the START message. Thus, in this embodiment, both the billing server and the subscription server know the customer ID number. This can be a disadvantage if the billing server and the subscription server belong to different organizations. This possible disadvantage can be "corrected" as follows. The customer-20 identifier consists of two parts. The first part identifies the customer's origin (that is, the customer's own billing server). This section is used to route the START message to that particular billing server. The other part is encrypted with the public key of the client's own billing server, so it * is not recognized by the access server. The customer identifier can also be made to appear different each time the service is performed, e.g., by associating it with a constant length string that changes each time the service is provided, e.g., by the time of day. (The customer identifier consists of the area code and the signature. The area code is required if ADSL users have contracts with different (multiple) billing service providers.) 30 The approved contract CDR billing server stores its billing database (arrow D) for a period of time in case the customer will have comments later. service. The billing server then requests the access server to grant the client access to the network (arrow E) by sending an OK message containing the aforementioned identifier 35 (Connld) to the access server identifying the connection messages and the contract number 14 104668 assigned to the service session. The access server in turn controls the router R1 to allow the client to access the (Internet) network. This process is illustrated in Figure 5 by arrow F and will be described in more detail below with reference to Figure 6.

5 The user will then have access to the network. This step of using the services provided by the network is described in more detail below.

If the billing service does not accept the billing record (e.g., the signature is incorrect), it sends a CANCEL message instead of OK, which contains the same fields as the OK message, although the contract number is not required in step 10 because the user is denied network access.

When the connection is disconnected after the user terminates the connection, a similar CANCEL message (arrow G) is also sent, but since the connection is normally disconnected, the contract number in the message must also be used. Thus, CANCEL messages are of similar structure 15, but are used differently depending on the stage at which they are communicated. The access server may also close the connection for other reasons, e.g., for load reasons (e.g., when capacity needs to be reserved for critical connections, or the billing service may request the connection server to close the connection for any other reason, e.g., load reasons, or is not received in an acceptable manner.

It is also possible to send the start message sent by the terminal directly to the billing service. However, by sending the start message from the terminal to the access server first, the billing server interface can be implemented in the same way for all service providers, so that the billing service can handle billing for other service providers in addition to the access server. If the router has the capability to detect traffic originating from a particular source address and notify the access server, the start message sent by the terminal would not be needed at all (i.e. the start message would be from the router).

Figure 6 illustrates in more detail the communication between the access server and the router during the connection opening step (Figure 5, arrow F). In this example case, it is assumed that the connection between the access server and the router is a well-known Telnet connection, because the Simple 35 Network Management Protocol (SNMP) does not currently allow updating of the 10 104668 in question. router connection lists.

The interface server SL controls the interface of router R1 through which the user has access to the Internet. A router list AL is stored in the router, which may comprise, for example, five columns according to FIG. 6, such that the first 5 indicates the IP source addresses (ClientAddr) of the terminals accessing the respective terminal. from the interface to the Internet, the second column gives the aforementioned connection identifier (Connld), the third column the contract number, the fourth column the number of incoming packets and the fifth column the number of outgoing packets. There may be a similar list for each direction of transmission of the interface. 10 When the subscription server SL receives the OK message from the billing service, it first sends a command to the router to clear the subscription list. This command is marked with the CLEAR_AC reference character. The interface server then sends a command that allows all Internet Protocol control messages to pass (PERMITJCMP). If the billing service and / or the access server are on the Internet side of router R1, the access server then sends commands that allow all connections to the billing server and / or access server (PERMIT_WD and / or PERMIT_SL). Finally, the interface server sends a command that allows a particular terminal to pass through the interface. These commands are sent one per 20 ongoing connections (PERMIT_ADDR1 ... PERMIT_ADDRN). As a result, the router updates the subscription list. A similar update is performed for each new connection. In other words, the entire list is first cleared and then the list is rewritten, while a new terminal is added to the list.

m

For the purpose of updating the subscription list, the billing service sends the addresses of the terminal-25 devices that are in the system. are currently paying for access to the service provider's network, or at least a change from the previous subscription list.

When the user terminates the connection, the billing service sends a CANCEL message to the subscription server (Figure 5, arrow G). As a result, the subscription server updates the subscription list as described above so that the <30 user is removed from the list at the time of the upgrade. This process is indicated by arrow H in Figure 5.

If connections are made and disconnected at a fast rate, the maintenance of the list being too slow, as described above, the router can store multiple update events and include all the update events at one time in 35 new subscription lists.

16 104668 In practice, the above process can be used, for example, on a CIS-CO router model 7000 equipped with, for example, IOS 11.2. As mentioned above, routers are likely to come with features that can be used to update the subscriber list 5 more efficiently so that changes can only be made where they are needed.

Once the connection is established, the services provided by the terminal can be accessed through the Internet. To keep the connection open, the terminal periodically generates billing records, sends them to the smart card for digital signature 10, and forwards the signed billing record via a subscriber line to a billing service which stores the approved billing records in its billing data base.

When a user has access to Internet services through router R1, he / she can use his / her service code (which may be, for example, any known 15 web browsers) to search for suitable services on the Internet and to enter into other agreements with such service providers. When finding a suitable service, such as a video-on-demand service, the customer selects the appropriate service. service, e.g. options.

Once the customer has made their choice, the service provider's server 20 sends the billing service WD to the billing service. a service identifier identifying the movie and an identifier corresponding to the subscriber in question, which it obtains, for example, from the source address of the messages it receives from the client's browser program (e.g. the socket address of the TCP connection).

The billing service WD then initiates a process that manages the use of the 25 services in question. Initially, the billing service retrieves from its service database the parameters corresponding to the service in question and sends to the terminal a contract CDR that contains the corresponding CDR. the billing parameters used during the service session and the contract number. Upon receipt of such a billing record initiating a service, the program on the terminal opens a window on the terminal display, hereinafter referred to as a contract window. Based on the information received from the billing server, the window displays basic information about the various parties and the information in question. service. In addition, the window displays a contract number that identifies this single service session. This agreement therefore only covers a specific service, such as watching a single movie, and is a completely separate service from the subscription service 35. Thus, along with billing for the subscription service, 17,104,668 billing services for other services are performed simultaneously. This billing can be done based on the content of the service, for example.

The terminal window of the terminal (Figure 7a) shows all the contracts that are currently running. Since billing for content based on the content of the Internet service is not an inventive idea, it is not described in more detail here. This billing is described in more detail in Applicant's earlier Fl patent application 964524 (secret at the time of filing the present application).

The billing service verifies the origin of each billing record using the relevant bill. the public key of the customer (subscriber) and store the accepted billing records in its billing database. Each CDR sent from the terminal to the billing server represents a connection billing over a specific time interval and includes a contract number by which the different services are distinguished. Because different users of the system cannot use the same terminal at the same time, the signatures of the billing records from the same source address remain the same during one access session. All such records are aggregated by subscriber and contract number. For each service (eg subscription service), total billing is determined by summing the billable amounts from all billing records associated with the same contract number.

From the billing database of the billing server, the CDRs are periodically transferred to the billing system BS (FIG. 3), whereby invoices are generated in a manner known per se and delivered to the customer. One invoice contains a list and charges for all services used by the customer during the billing period (eg, month). The invoice may be delivered in paper copy by mail or it may be delivered to the terminal in electronic form. Figure 7b illustrates an invoice to be sent to a customer. The invoice contains subscriber information and a list of services used during the billing period. Invoices for each service may include, for example, the type of service, the service provider, the contract number at which the service was received, the time and duration of the service - 30 and the price.

As the operation of the billing system is known per se, it will not be described in detail herein.

There are, for example, nine different types (0 ... 8) of billing records (billing messages) used in the system, as follows: 35 0. Agreement: This is an initial billing record (arrow A, Figure 5) that 10 104668 18 billing server sends (unsigned) to which the terminal returns to the billing service, if signed, if the customer accepts the agreement.

1. Payment: Billing records of this type are sent from the client's terminal 5 during a contract session to the billing service for review.

2. End: This type of CDR is otherwise equivalent to Type 1, but with the additional information that it is the last CDR sent by the terminal during an expiring contract session. When the user self-terminates 10 services by pressing the End button, a Type 1 CDR is sent first, followed by a Type 6 CDR. In this way, the billing server is able to distinguish user termination from normal service termination (such as movie ending). This type of record can also be used for one-time billing.

15 3. Pulse: This type of CDR is sent from the billing server to the terminal. The purpose is to inform the terminal that it should send a new CDR if the service is to be continued. If the terminal does not send a valid CDR within a certain time, the billing server sends an interrupt message to the service provider's server.

20 4. Missing Serial Number: Sending from the billing server to the terminal (during the ongoing billing agreement) to notify that the CDR with a particular serial number has not arrived at the billing server or the incoming CDR was invalid. The terminal then has the opportunity to retransmit to correct the situation. However, neither party may need 25 such functionality. If the terminal does not respond to such a CDR, the best option is that the billing system is not entitled to charge for the lost portion of the CDR.

5. Modified Agreement: This type of CDR is sent to the billing service from brother to customer and is otherwise equivalent to a Type 0 billing record, but the 30 contract number is not new, but the same as the current short term contract. This billing record is sent in the middle of a service session to indicate that the billing parameters have changed. The terminal may, for example, automatically accept a new contract if the price has fallen; otherwise, a customer approval may be required.

35 6. Suspension: This type of CDR may be sent in either direction 1β 104668 to indicate that the contract will be terminated. The CDR is signed by the sender.

7. Digital Money: It is possible to take advantage of the billing system so that the CDR (Type 1 or 2) associated with a particular payment includes a payment in 5 digital money. However, the billing service does not transfer digital money to the billing system, but transfers it directly to, for example, a bank server (always collecting a certain, relatively small amount of digital money) or a network server maintained by another organization that directly debits the customer's account. Digital money can be used in addition to the centralized billing system BS, as in conventional e-commerce or as an alternative implementation instead of the centralized billing system.

8. Billing synchronization: Sending from the billing service to the terminal (during the ongoing billing agreement) to inform that the payment CDRs do not cover the per-minute rate of the ongoing agreement (eg, the terminal clock is too slow). The pacing CDR comes with information on how much more you need to pay to keep your contract running.

Figure 5 illustrates billing for one service. Each message type is indicated by the message above the mean of the arrow. The figure shows a case where a billing service once detects during service 20 that a particular billing record was missing.

Depending on whether a number of other processes are simultaneously performed on the terminal, there may be between two consecutive Type 1 CDRs. time to vary. If the load on the terminal increases and the CDR generation is delayed at its nominal value, the charge contained in the CDR is correspondingly higher.

In practice, there are two time-related issues with ongoing billing. First, as a result of a failure or error, one or more payment CDRs may be lost. Second, the terminal clock may run slower * 'than the billing server clock. To eliminate these problems, two thresholds (A and B) are defined. The first threshold (A) is the maximum debt that a user may have as a result of outstanding usage for a billing service. The second threshold (B) is the maximum value of the debt after payment. Each threshold has its own timer value (TA and TB).

Figures 7c and 7d illustrate the solution of the above problems. The time-35 axis t represents the billing server time and the time axis t1 represents the terminal time.

20 104668

In the figures, time is shown in seconds. The vertical axis at the top of the chart depicts the user's debt to the billing service, while the bottom of the chart shows the billing records sent by the billing server and the terminal. The figures assume that the network delay is negligible. In Figure 7c, the clocks run just as fast, but in Figure 7d the clock of the terminal runs slower than that of the billing server. At time t1 = 0, the terminal sends the signed contract (CDR-0) to the billing service. The billing service receives the contract at time t = 0. The user debt D (t) starts to increase from this point on. When there are no payments, the debt increases linearly over time. The debt growth rate of 10 (monetary units per time unit) is specified in the contract. When the billing server receives the payment CDR (CDR-1), the debt decreases. As indicated by the CDR.

Upon receipt of the agreement, the billing service periodically (e.g., once per second) calculates the value of the debt. If D (t)> A, the billing service 15 sends a type 4 CDR to the terminal. If the billing service does not receive the missing payment within the TA, it will terminate the contract. Figure 7c illustrates a situation in which a payment CDR (CDR-1) transmitted at t1 = 120 does not arrive. As a result, the debt exceeds the threshold A before the next regular payment. The billing service sends a type 4 CDR to the terminal 4 and the terminal transmits the payment CDR in response. Additionally, the maximum time that a billing service can be without a payment CDR can be specified. If this time expires, the billing service will send type 4. CDR.

The billing service checks the amount of debt at least after each payment under Rule-25. If the terminal clock runs slower than the billing server clock, as shown in FIG. 7d, the amount of post-payment debt will increase from payment to payment. When the amount of post-payment debt exceeds threshold B, the billing service sends to the terminal a type 8 (synchronization) CDR containing information on the amount of payment desired. The terminal 30 transmits a signed synchronization CDR in response. If the billing service does not receive the missing payment within the TB period, it will terminate the contract.

All billing information required by the system is transmitted in successive fields of protocols (i.e., billing records). Figure 8 shows the fields used for billing records: 35 TYPE: Indicates the type of CDR, which is one of the eight 21,104,668 billing records described above.

LENGTH: The length field indicates the total length of the CDR in bytes, including the type and length fields.

CONTRACT NUMBER: This field contains the billing service provider's integer, which is the same for all CDR records associated with the same billing session.

ORDER NUMBER: An integer that indicates the order in which CDRs are generated in the same billing session. The terminal returns the contract CDR (type 0) returned by the number zero, after which it increments the number by one for each CDR. This field is undefined in CDR Types 3, 5, 6 and 7 and in Type 4 it indicates the serial number of the missing CDR.

SERVICE ID: The content of this field tells you which service is being billed. The parameter in the field gets the value as a result of an agreement between the billing service provider and 15 (multimedia) service provider.

SERVICE TYPE: This parameter contained in this field roughly classifies services into different categories for statistical purposes, e.g., web pages, video on demand, file transfer, etc.

START-UP TIME: The parameter in the field indicates the elapsed 20 time for CDR types 0 and 5 and 3, 4 and 6 and the billing cycle start time for types 1 and 2.

END TIME: The field parameter specifies the end of the billing session for type 1 and 2 CDRs. For CDRs of type 0 and 5, the field parameter specifies how often the billing service waits for 25 payment CDRs. Other types of CDRs do not specify this parameter.

IDENTIFICATION: The parameter in this field identifies the customer, billing server, and server identifiers. Tags can be integers or web addresses, but must be unique within the billing system.

PAYMENT METHOD: The parameter contained in the field is defined for CDRs of type 0, 30 5, 1 and 2. Payment methods can be classified, for example, as follows.

free, one-time charging (with one CDR), periodic or externally triggered, e.g., another process of the terminal may perform the trigger. For example, a terminal video player program may trigger CDR generation, e.g., every minute, if a valid 35 video signals have been received in the last minute. Also described below is an implementation in which the billing service 22 104668 triggers the generation of a CDR using a payment method field parameter.

CURRENCY: This field shows the amount of debt the client has incurred (either per session or between two CDRs).

TRAFFIC DATA: This field contains information to be sent from the external application on the terminal to the terminal, which is forwarded to the network.

SIGNATURE: This field contains the customer digital signature used to authenticate the CDR.

The attached appendix 1, which is included in this application, describes in more detail the structure of CDRs using ASN.1 (Abstract Syntax Notation 1), a commonly used description language in the telecommunications industry for describing data structures. The structure of the above mentioned lnit_Service, START, OK and CANCEL messages is also described in the appendix.

The billing records and the aforementioned messages may be sent, for example, in a data field of IP packets 15, which may have one or more billing records.

Billing works properly when network access and charges are in sync with each other, that is, if the paying customers have access to the service provider's network and the non-paying ones have no access. However, for example, as a result of a malfunction, the situation may sometimes become such that the router 20 prevents paying customers from accessing the service or a non-paying network or allowing non-paying customers (send payment CDRs). To remedy this situation, the subscription server polled ------ us and the billing service. The router obtains from the router the subscription list and from the billing service the IP addresses of the clients who pay for the subscription. het-25 who has network access. If the paying customer's address is not on the subscription list, the subscription server adds the address to the list. If the address in the subscription list is not among the billing server's paying customers, the subscription server will remove the address from the list. The polling interval can be made adjustable so that the subscriber service provider can set the interval he wants.

Fig. 9a shows the structure of the terminal CT as a functional block diagram. For the purposes of the invention, the core of the device is a CDR generator CG, which generates billing records. The CDR generator includes a security library, SLI, which stores the customer's personal encryption key and manages the signing of billing records. The CDR generator generates 35 CDRs and sends them to a security library where they are signed 23 104668 using the client's private encryption key. The security repository returns the signed CDRs back to the CDR generator, which forwards them to the billing server WD.

If the application or environment requires encrypted messages to be transmitted between the terminal and the billing server, the security library will perform encryption, signature and signature verification.

The security library can be implemented either hardware-based or software-based. However, a hardware-based solution is safer. Thus, the security library or part thereof can be implemented in the manner described above for e.g. a smart card containing e.g. client-specific encryption key.

In addition, the terminal includes means for receiving the service. These may consist, e.g., of a service replicator VP, which may be e.g. a video reproducer, which reproduces the video signal received from the network and may also give the CDR generator instructions for generating billing records. The service server SB, service VP and CDR generator are connected to the network through the terminal communications library CL. The latter forms the protocol stack under which the terminal operates at any given time. This protocol stack can be e.g. TCP / IP stack, which can be e.g. Microsoft Winsock.

The terminal start logic unit SUL handles sending the start message 20 to the access server when the user inserts the smart card into the reader.

The terminal may also have a billing counter BC so that the customer can check the correctness of the invoice he has received from the billing service provider from his own device. In addition, the terminal may have different means for monitoring the level of service (QoS) of the incoming information stream, e.g., the video player may instruct the source 25 to stop the information transfer when the quality of service falls below a certain threshold.

Figure 9b shows in more detail the functional block diagram of the CDR generator. The contract logic unit CLU1 manages the generation of billing records based on the information contained in the configuration database CDB. It contains logic that transfers the contract information it receives to the graphical user interface GUI and generates billing records such as those described above. This logic includes timer elements TM which determine the time between two successive CDRs. The contract logic unit CLU1 communicates with the communications library and the network via the external control interface ECI and the service repeater via the internal control interface ICI. The external control interface performs 35 conversions between the internal and external CDR formats. The internal control interface 24 104668 in turn handles the message exchange between the service repeater and the contract logic unit, performing, if necessary, conversion between the message format used by the service repeater and the internal message format of the device. The connection between the internal control interface and the service repeater (interface A3) can be implemented, for example, through a communication library (TCP socket). The configuration information database CDB stores information about user preferences and may also include information related to various services (e.g., movies), which is presented to the client based on the service identifier received. This database can be implemented with eg Microsoft Access or Borland Paradox -10. The configuration database is managed through the management unit MM. The Hal fonts, the configuration database and the contract logic unit are all connected to the graphical user interface GUI, which can be implemented using JAVA applets or Microsoft Visual Basic programming tool. Some of the configuration database may be online.

15 If the service repeater is intended for eg video-on-demand, it may be implemented, for example, with a personal computer and a program for video-on-demand. One such program is StreamWorks, manufactured by Xing Technology Inc., USA.

The management unit and the contract logic unit 20 are connected to the security library via interface A1. The security library and interface A1 can be implemented, for example, with Setec Oy's SETCOS 3.1 smart card (and smart card reader) or other similar product based on international smart card standards. (ISO 7816-1 (physical dimensions), ISO 7816-25 2 (contact location), ISO 7816-3 (transfer protocols) and ISO 7816-4 (command and file structures) are defined by the International Organization for Standardization ISO standards for smart cards). ) The user can have several different smart cards, each of which opens a certain type of connection. For example, one card can be used to open a full Internet connection and another card (where the subscriber is an employer) can only connect to a 30 workplace LAN.

Figure 10 illustrates the structure of the billing service WD by means of a generic block diagram. The core of the device is formed by the contract logic unit CLU2, which has a service database SED, a subscriber database SUD and a billing database BD. The service database contains information about the services of various service providers and their billing parameters. Billing buttons 25 104668 can also independently change billing parameters, e.g., according to the time of day. The subscriber database contains the customer information of the billing service operator (including the public key of each customer). The billing database stores the billing records received from the terminals. The contract logic unit-5 has an encryption block CM that handles the verification of the billing records signature. This block corresponds to the terminal SL of the terminal. The contract logic unit receives the billing records signed by the terminals from the terminals and transmits them to the encryption block for verification. Accepted billing records The contract logic unit stores them in the billing database. The contract logic unit 10 is connected to the network through its communication library CL ', which forms the protocol stack under which the connection is being established.

In practice, the contract logic units having the functionalities described above can be implemented, for example, by means of a tool based on an international SDL (System Description Language) standard, e.g., the SDT tool of Telelogic 15 AB.

The billing service databases may be located in the memory MS associated with the billing server shown above (Figure 3). In addition, the billing records may be stored in a separate mass storage MS1 (Figure 3), which is networked between the billing server and the billing system and is organized so that the billing system can easily process the information therein. Such a separate database can provide service providers with the opportunity to make various queries to the database to develop services. For example, a service provider or customer may request billing for a particular service in the middle of a billing cycle (e.g., via email).

Figure 11 illustrates the structure of an access server SL as a functional block diagram. For external connections, the server has an interface unit IU comprising a router interface unit RIU, a billing server interface unit WIU and a terminal interface unit TIU. The latter receives the aforementioned start-up message lnit_Service from the terminal and starts 30 messages. customer billing session. The router interface unit monitors the router interface list and the billing server interface unit handles communication with the billing server. The switching logic CLO is a simple state machine that connects different interface units to each other. The switching logic also maintains a list of all open connections, as well as two queues, 35 of which are closed connections and the other is open connections 26 104668.

The router control unit RCU, which contains the router set of commands, controls the router while performing the interface list maintenance described above.

The synchronization unit SU handles the above described synchronization of charges and access rights by comparing at intervals the list of open connections on the router and the addresses of the paying customers obtained from the billing server. The discrepancies found will be corrected so that no billing error will occur for longer than the specified time period.

The router connection monitoring unit RCC monitors the connection between the access server and 10 routers. Since the example assumes that the connection between the router and the access server is a Telnet connection, the router will disconnect the connection if it has been idle for too long. It is the task of the router monitoring unit to open the connection if the router is able to disconnect it due to, for example, the above reason or other connection problems.

The volume control unit VCU and the billing database BD2 used by it are at the interface server, at least if billing is also desired based on the amount of data transferred. In this case, the monitoring unit reads through the router interface unit the desired packet numbers from the router interface list and stores the data in the billing database BD2 20, storing for each contract number the packet numbers and the IP address used by the terminal. In the billing step, the billing database data of the subscription server is combined with the billing server billing database data based on the contract numbers, so that the amount of data transferred can also be taken into account in the billing.

25 The embodiment described above does not yet obtain the subscriber's signature on packet data, so the user would have to rely in this regard on the correct packet counts calculated by the system. In all other cases, however, the terminal itself can verify that the billing is being made correctly. To solve this problem 30, the following two-step procedure is followed. First, the access server notifies the terminal when the billable amount has increased by a certain value (e.g., 50 Mb). In this way, the terminal can monitor the volume calculation performed by the access server and compare it with its own. Second, the access server transmits each volume-related CDR to the billing service, which forwards it to the terminal for further signature. The procedure is similar to the 27 104668 contract signature described above; it allows the terminal user to control billing and makes it difficult to dispute charges. This procedure is illustrated in more detail below with reference to Figure 12, which illustrates communication between different parts.

5 Initially, a separate "quantity contract" is created as an externally triggered contract (arrows 121-124) as described above. The access server reads the desired packet numbers from the router and stores the data in billing database BD2. When the packet number reaches a predetermined limit n billing service 10 (arrow 126) Prior to this, however, the access server transmits a message VM containing information about the amount of data transferred (denoted by "traffic data") to the terminal's traffic data port, thereby providing the amount to the next CDR and user, or at least the terminal, being given the opportunity to check the amount before signing the CDR.

15 Upon receipt of the Type 3 CDR from the access server, the billing service notices that the contract is an externally triggered contract, whereby it forwards that CDR to the terminal (arrow 127). If the user or terminal accepts the amount, it generates a payment_CDR, transmits the amount of data it receives to the traffic data-20 field of this payment CDR, and sends the data. to the payment CDR billing service (arrow 128). The billing service forwards the CDR or the information contained therein to the access server (arrow 129), which at least checks the information contained in the traffic data field. Based on the review, the access server will either discontinue or allow the service to continue. Thus, in this case, the service is likely to consist of a combination of 25 services which include both time and quantity contracts.

From the point of view of the terminal, the amount based billing described above proceeds as follows. The payment method parameter of the new agreement (arrow 122) sent by the billing service has a value that indicates the externally triggered * payment. When a payment is required, the terminal receives a Type 3 CDR containing information on the amount of payment required. In this case, the terminal either automatically accepts the payment or the information is displayed on the terminal screen to the user who can decide whether to accept the payment. If accepted, the terminal will change the CDR type to number one (pay-CDR), sign the CDR and send it to the billing service (arrow 128).

35 A payment can also be triggered by another external object, 28 104668 e.g. a billing service that sends a command to the terminal indicating that a payment is required. Such a command is sent to the socket address corresponding to the traffic data. The command message contains information not only about the command itself ("make a payment") but also the contract number. Thereafter, the terminal 5 makes a payment. In this case, the command merely states that payment is required. Instead, the amount of the payment is specified in the contract.

As described above, volume-based billing can be implemented such that the terminal or user is always aware of the magnitude of the resulting invoice. Every payment is accepted, so it is difficult to dispute the payment aa. Messages only need to be sent when charges are needed, so if there is no traffic to the terminal (terminal), no empty or unnecessary billing messages will be generated either. Because implementation is done at the application level, volume based billing is not technology-dependent, but there may be several "billers" between 15 service providers and the terminal who simultaneously bill on a volume basis.

While the ADSL environment has been used as an example above, it is clear that the method of the invention provides the same advantages in any offline network that provides access services with the need to distinguish a particular user from a particular network address or where the user is not necessarily a subscriber. who pays for the service. The terminal may also connect wirelessly to the network providing the services. In the future ----- connection methods may vary considerably.

In addition, the foregoing refers to situations where a client's network address (IP-25 address) may vary from one service session to another but remains the same during a single service session. However, the method of the invention can also be applied when subscribers move from place to place. For example, you can use the Mobile IP protocol, which is a version of an existing IP that supports the main *. telecommunications equipment mobility. (The principle of Mobile IP is described in, for example, Upkar 30 Varshney, Supporting Mobility with Wireless ATM, Internet Watch, January 1997.)

Mobile IP is based on the fact that each mobile host or mobile node has a designated agent ("home agent") that forwards the packets to the current location of the mobile computer at 35 locations. When a mobile computer moves from one subnet to another, it registers with 29 104668 agents ("foreign agent") serving that subnet. The latter performs checks with the mobile computer's home agent, registers the mobile computer, and sends registration information to it. The packets addressed to the mobile computer are sent to the original location (home agent) of the mobile computer 5, from where they are forwarded to the current visiting agent, who forwards them to the mobile computer.

Applying the above principle to a system according to the invention, it is possible, for example, to operate such that each user has a dedicated (home) billing server that takes care of the user's public keys 10 and acts as a home agent. The access servers serving different subnets (ie, the visiting agents) tell the local billing service when the billing starts. This billing service retrieves the public keys from the user's home billing server and starts billing. It is essential that the subscriber's public key can be safely transferred to a billing server near the subscriber in order to enable the relevant public key. the billing service could check the billing records. (If the transfer cannot be done safely, it is possible that the key may be changed by a third party during the migration and thus incur costs to the original subscriber.) The subscriber's public key may be transferred to, e.g. The billing service 20 closest to the subscriber can handle billing using the subscriber's billing server identifier. The collected CDRs are sent to the subscriber's own billing server after the service session has ended.

Figure 13 illustrates communication between different components in the case of mobile IP connections. In the figure, the home and visit agents are shown as physically separate machines, but as mentioned above, the access server can also act as a visit agent and the home billing server home agent. In accordance with the Mobile IP protocol, the visiting agent FA continuously transmits broadcast messages to its own subnet called "agent advertisement" and designated AA in the figure. When the terminal connects to the subnet 30 in question, it receives these messages and determines based on whether it is in its own home network or another network. If the terminal discovers that it is in its home network, it will operate without mobility services. Otherwise, the terminal receives a care-of address. to a foreign network. This address is thus the address of the 35 points of the network to which the terminal is temporarily connected. This address 30 104668 forms the same address. termination point of the tunnel (tunnel) leading to the terminal. Typically, the terminal receives the address from the aforementioned broadcast messages sent by the visiting agent. The terminal then sends a registration request message RR (Registration Request) to its home agent 5 via the visiting agent FA. The message includes e.g. the c / o address that the terminal has just received. Based on the request message it has received, the home agent updates the location information of the terminal in question to its database and sends a Registration Reply R_Reply to the terminal via the visiting agent. The reply message contains all the necessary information 10 about the conditions under which the home agent has accepted the registration request. All of the above-described messages between the terminal, the roaming agent and the home agent are normal messages according to the mobile IP protocol.

Thereafter, the visiting agent FA sends the aforementioned start message or billing service request message to the lnit_Service interface server SL. This message corresponds to the service request message sent by the terminal, as shown in Figure 5, indicating the start of a one-time service session. The message includes e.g. the c / o address of that terminal. Thereafter, the operation is similar to that described above with respect to Figure 5, except for the termination of billing and the acknowledgment message ACK, which are referred to below. Next, the access server 20 then checks the received message and forwards the START message to the billing server WD. This is followed by a contract negotiation between the billing service and the terminal, which normally results in the user being given access to the network.

The termination of billing differs from the case of the fixed terminals of Figure 5 in that in the case of mobile IP, the termination can be performed by either the visiting agent or the billing service, whichever is the first to notice the change. If the visiting agent discovers that the user has left the network, it sends a termination message to CANCEL (1). Related *. the server is relayed by the server. message to the billing server and shuts down 30 routers. connection. The roaming agent automatically detects the user leaving because the mobile IP protocol requires the terminal to send messages at regular intervals indicating that the terminal is still present. subnet. These alive messages are for the use of the visiting agent only and are not forwarded by the visiting agent. If, on the other hand, the billing service 35 first notices that the user has terminated the session, 31 104668 it sends a termination message CANCEL (2) to the access server, which results in the connection being disconnected from the router. Otherwise, there are similar options for closing the connection as described above.

. Thus, in the case of Mobile IP, the user or terminal does not send the opening message (as shown in the case of Figure 5), but the behavior of the visiting agent is changed to initiate billing when the terminal connected to its serving subnet registers to its home agent through the visiting agent.

The visit agent also maintains a special billing start-up time of 10 which measures the time since the service request message was sent to the access server. If it does not receive the ACK message before the timer is triggered, it will attempt to restart billing by sending a new service request message to the access server. The terminal performs this process for all terminals in its area that do not have ongoing billing.

15 As described above, the subscriber service provider is able to reliably restrict users, for example, only to those who may be charged for network use, even though such an option is not provided as a mobile IP protocol.

It should also be noted that the visiting agent is not absolutely necessary in a 20 IP mobile IP network. If the visiting agent is not used, there is still a DHCP server on the network or some other mechanism that provides temporary addresses. In this case, if the terminal wants to use the mobility-related services, it must initiate the connection in the same way as shown in the case of Figure 5. If it is decided to provide an access service to a terminal, it registers 25 with its home agent following the normal registration procedure described above.

The implementation of the subscription service in the case of mobile IP connections was described above. If the routing protocol used is IPv6, which does not have a specific export agent, the access service must be started slightly differently.

When the IPv6 terminal connects to the new network, the default procedure is that the terminal waits for the adver tisement message sent by the router. Such a message may give the terminal the right to generate its own address or it may require the terminal to use the DHCP server to obtain a temporary address. Once the terminal has received these 35 temporary addresses, it sends binding updates 32 3264668 updating information on the routers of the network concerning the (fixed) home address of the terminal and the associated temporary address. These update messages are sent to all nodes with which the terminal communicates, especially to the terminal's own home agent. Based on the update messages,

The 5 nodes update their routing information so that they can transmit the routing information. packets for the terminal directly to the temporary address of the terminal.

Figure 14 illustrates, in simplified form, the message exchange between different components when the routing protocol is IPv6. In this case, for example, the routers may require new users (terminals) connected to the network to register with the DHCP_S local DHCP server. The terminal sends a request for registration (REQUEST) to the DHCP server in response to the advertisement message it receives. After the DHCP server has provided the terminal with a temporary address (ACK message), the DHCP server initiates billing by sending to the subscriber server 15 SL the abovementioned start message lnit_Service. Thus, in this case, the DHCP server, in terms of billing and access servers, takes on the same role as the roaming agent on the mobile IP network. In other words, by sending the aforementioned start-up message, it informs the access server of new terminals connected to the network. Otherwise, the protocol is similar to the mobile IP-20 case described above.

In this case, the gateway router R1 must be configured by default so that all network-connected terminals have access to the subscription and billing services.

When a terminal moves from one subnet to another (i.e., from an access server to another), a new contract can be made, renegotiated, or renewed, depending on how the circumstances change as a result of a handoff or handover. For example, when changing operator, a new contract can always be negotiated. If the operator is not switched but the quality of service in the new subnet differs substantially from the previous one, the same contract may be negotiated under new terms. The party deciding on the handover event should also decide whether to terminate or extend the old contract. On the other hand, the user should always be able to know what network he is on and under what conditions he is receiving the service.

The network environments of Figures 13 and 14 are otherwise similar to the examples of Figures 3a ... 3d, but the LAN switch is replaced by a wireless (or 33 104668 wired) access network, the ATU-C has a common access point, e.g., an Intelligent hub. , etc., and the ATU-R is replaced by a terminal (card). In addition, the DHCP server is replaced by a visiting agent for mobile IP networks. Figure 15 illustrates a network environment similar to the latter 5 using the example of Figure 3a. The figure shows the visiting agent as a separate host, although the visiting agent may be hosted on the access server. As can also be seen from the figure, the local billing service for the access point is typically a different server from the one in question. a home billing server for a user connected to the network via an access point, which may be connected to, for example, the Internet or a telephone network.

While the invention has been described above with reference to the examples in the accompanying drawings, it is clear that the invention is not limited thereto but can be modified within the scope of the inventive idea set forth in the appended claims. The following is a brief description of the various variations of the variation option-15.

For example, it is possible that the terminal does not send the actual billing records to the billing server, but other (billing related) messages that the billing service can generate itself. The terminal may, for example, send so-called. keep-alive messages for as long as the service 20 lasts, after which the billing service may e.g. generate only one billing record in which the service duration corresponds to the time between the last keep-alive message and the moment of acceptance of the contract. It is also possible, particularly in systems that support terminal mobility, that another network element or entity (e.g., an access server or a visiting agent) takes on the role of the terminal as a generator of billing record (s). Such an element or object must have the confidence of the user. The role of the terminal may be taken, for example, in such a way that the terminal pays a lump sum for the given amount. element or entity which then generates billing records / records and / or maintains a connection according to the payment received and possibly requests additional payments from the terminal if necessary. If the entity representing the terminal generates a billing record with its own signature, the billing server must know which one. the object in each case represents.

Any suitable device 35 capable of selectively allowing traffic to pass through, such as a packet filter or a firewall, may also be used as the connecting link between the service network and the access network. The start message may also be a message sent for another purpose, which at the same time indicates the start of a new service slide.

• · »<

Claims (39)

1. Method for implementing an access service in a telecommunication network with access network (N1), which is at least partially unconnected, service-providing network (N2) and terminals (TE1 ... TE3, PC) used by users and which are connected on the access network, according to which method - the access service is provided by connecting the user's terminal to the service-providing network via interface means (R1) connecting the access network and the service-providing network, and - in response to the access service, at least one billing mail is conveyed to the invoice agent ( ) for billing the subscriber of the access service for the access service, characterized by the telecommunication network - is indicated by the initiation of a single-access access service session by generating an invoice initiation message where the user contacts the access network via the terminal, - generated Signature-provided billing messages relating to said access service session, - the generated signatures are checked, and - the terminal is granted access to the service-providing network in case the said messages are acceptable generated. 2. A method according to claim 1, characterized in that invoice messages are sent from the terminal and the invoice messages are provided with a subscriber-specific digital signature. « 3. A method according to claim 2, characterized in that the terminal is granted access to the service-providing network if said messages are received at a predetermined rate and the signatures contained in the messages are found to be correct. 4. A method according to claim 2, characterized in that from the terminal additional information is sent about the subscriber behind the user of the terminal at the respective time, whereby the accuracy of the signatures is checked by means of said information and the invoice messages received from the terminal are allocated to the invoicing of the subscriber in question. The method of claim 2, characterized in that the network uses at least one separate billing server (WD) such that each terminal * 35 has one for the designated billing server receiving the billing message that the terminals generate. 6. A method according to claim 2, characterized in that when the terminal has access to the service-providing network, it is generated at predetermined intervals by means of the terminal billing records with a subscriber-specific digital signature, each of which represents the billing for a certain connection time. 7. The method of claim 5, characterized in that the initiation message is conveyed to the billing server at least the applicable network address for the terminal in question. 10 8. A method according to claim 7, characterized in that the initiation message is transmitted from the terminal via a separate access server (SL) to the billing server. 9. The method of claim 8, characterized by response to the initialization message received by the billing server, it sends a contract message to the terminal stating that the user must enter into an access service agreement. The method according to claim 9, characterized in that the terminal reverts to the contract message provided with a subscriber-specific digital signature, the billing server checks the signature and upon finding that the signature is correct initiates the process of connecting the terminal via the interface means (R1) to the service-providing network. . 11. A method according to claim 4, characterized by the information about the subscriber behind the user that the terminal has formed in the initialization message. 25 12. A method according to claim 10, characterized by the information about the subscriber behind the user that the terminal has conveyed to the billing server in a signed contract message. The method of claim 7, characterized by response in response to the initialization message received by the billing server, it asks the terminal for information to identify the subscriber. 14. The method of claim 10, characterized in that the billing server initiates the process by providing a switching instruction to the access server (SL) with which the interface means (R1) are controlled. 15. A method according to claim 14, characterized in that, as an interface means, a router is used and the access server maintains the access list of the router, which contains the network addresses of the terminals which have access to the service network via the router. 16. A method according to claim 2, characterized in that on the terminal, billing records are generated at the side of the access service as well as service-specific for each service used in the service-providing network. 17. The method of claim 5, characterized by the billing information contained in the billing messages being sent from the billing server to a separate billing system (BS) to form subscriber-specific invoices. 18. The method of claim 17, characterized by billing information being sent to the public telephone network billing system. 19. A method according to claim 15, characterized in that the access server compares with predetermined intervals the list of paying terminals in the billing server and the list of paying terminals in the routing and switches or disconnects the terminals' connections to the service-providing network about the list in the router does not match the list in the billing server. 20. The method of claim 1, characterized in that at least a portion of the connection between the interface means and the terminal is realized in the form of a tree-bound ADSL connection. 21. A method according to claim 8, characterized in that the connection between the interface means and the terminal is realized as treeless. The method of the network of claim 1, which uses mobile IP protocols as routing protocols, wherein, when the terminal is connected to the access network, it receives a temporary address which it registers by sending its home agent a registration message via the access network's visitor agent, characterized by said initiation message. is generated in the access network's visitor agent in response to the registration. 30 The method of the network according to claim 14, which uses mobile IP protocols as routing protocols, wherein the terminal, when connected to the access network, receives a temporary address which it registers by sending its home agent a registration message via the access network visitor agent, characterized in that said initiation message is generated. in the access network visitor agent in response to the registration, and the billing servers 44 104668 act as home agents according to the mobile IP protocol and the access servers as visitor agents serving different subnets, by means of which each terminal's own billing server is informed in which subnet in question is located at respective time. 5 The method of the network according to claim 1, which uses IPv6 routing protocol, characterized in that the network uses at least one server (DHCP_S) that allocates temporary addresses in such a way that - when the terminal is connected to the access network it is registered in the server which allocates addresses, and 10. said initiation message is generated in the server that allocates addresses in response to the registration. 25. A method according to claim 6, characterized in that when the terminal has access to the service-providing network, a message with the payment request is sent to the server whenever the amount of data transmitted during the service has reached a predetermined limit. 26. A method according to claim 25, characterized in that information is sent to the terminal about the amount of data corresponding to the message with the payment request or about the size of the payment corresponding to the message with the payment request. 20 The method according to claim 5, characterized in that the billing server, after receiving from the terminal an invoice message indicating payment, determines the user's debt at the time, and if the debt still exceeds a certain predetermined limit (B) after the payment in question. the billing server sends a message to the terminal indicating that additional payment is required by the terminal. The method of claim 14, characterized in that the disconnection of the connection between the terminal and the service-providing network is initiated from the billing server in response to predetermined transactions, which at least include transactions in which (i) the billing server 30 does not accept billing messages acceptably and (ii) the billing server receives a separate disconnection message from the terminal. 29. A method according to claim 28, characterized in that the access server is further given the power to independently disconnect the connection between the terminal and the service-providing network in response to predetermined situations. 45 104668 30. Systems for implementing access service in a telecommunications network with access networks (N1), which are at least partially non-connection, service provisioning networks (N2) and terminals (TE1 ... TE3, PC) used by users and which are connected on the access network, which system comprises 5. switching means (SL) for connecting the user's terminal to the service-providing network via interface means (R1) connecting the access network and the service-providing network, and - means for generating billing records for generating billing records (CDR) in response to the user being connected to the service-providing network, characterized in that - in the system there are startup means for a service for generating an initiation message indicating the initiation of an access service session for the billing, when the user contacts the access network via the terminal, 15. the system contains signatory means (SLI) (CG) for generating billing messages for adding a digital signature in the generated billing message, - the system has control means (WD) for checking the billing messages generated, 20. the switching means (SL) respond to the control means (WD) for connection of the terminal towards the service-providing network when billing messages are generated acceptable. 31. A system according to claim 30, characterized in that the means for generating billing messages are located in the terminals. The system of claim 30, characterized in that it further comprises identification means (CR) for identifying the subscriber behind the user having the terminal at the respective time. 33. System according to claim 31, characterized in that the identification means (CR) are connected to the terminals. 34. The system of claim 30, characterized in that the control means comprise at least one separate billing server (WD) to which several terminals transmit billing messages. System according to claim 30, characterized in that the switching means comprise a separate server (SL) in the network which controls the router (R1) v 35 which acts as an interface means in accordance with messages sent by the billing server. The system of claim 34, characterized by the identification means comprising a smart card reader (CR) connected to the terminal and a smart card used by the user and on which at least one identifier is registered for the subscriber behind the user. 37. The system of claim 30, wherein IP packets are mediated, characterized in that - the system uses a routing protocol that supports IP-level mobility, according to which the terminal is registered when it connects to the access network, and - the service start-up body responds to the registration, whereby the initiation message is generated in response to a completed registration. The system of claim 37, wherein the routing protocol is mobile IP, wherein the system has at least one home agent and at least one visitor agent, characterized in that the service startup means is placed in the system's visitor agent. The system according to claim 37, wherein the routing protocol is IPv6, characterized in that the system has at least one server (DHCP_S) that allocates addresses in which the terminals are registered and that the startup means 20 of the service are located in said server. 104668 LIITE 1 1 - The CDR structure - In the initial version the encoding is byte-oriented - without tag and length fields. ENUMERATED is encoded - as one octet if nothing else is specified, INTEGER - is encoded as an octet string (length 2, 4 or 8 depending on the maximum size) in MSB first format. CDR_cdrType :: = ENUMERATED {contract (0), - initial CDR, WD -> Client payment (1), - normal payment CDR final (2), - as above, client stops pulse (3), - indication of new payment missing_seq (4), - CDR with seq.num. lost mod_contract (5), - contr. renegotiation abortion (6), - end connection, no money inc. E_cash (7) - e_cash carrier CDR, type B} - Types 0..6 are overloaded onto a CDRtypeA, type 7 uses - a CDRtypeB CDR_network :: = ENUMERATED {unknown (0), TCP / IP (1), •. ISDN (2)} «CDR_serviceTypeType :: = ENUMERATED {unknown (0),} 104668 LIITE I 2 CDR_timeType :: = hundrethOfSec OCTET STRING (SIZE (1)), seconds OCTET STRING (SIZE (1)), minutes OCTET STRING ( SIZE (1)), hours OCTET STRING (SIZE (1)), days OCTET STRING (SIZE (1)), yearjo OCTET STRING (SIZE (1)), year_hi OCTET STRING (SIZE (1))} CDRJdentifierType :: = SEQUENCE {type ENUMERATED {system_assigned (0), E164_addr (1), ...} data OCTET STRING (SIZE (16))} CDR_paymentMethodType :: = ENUMERATED {free (0), - no charge one_time (1), ~ agreement valid for one payment periodic (2), - time-based wd_req (3), - payment triggered by a WD msg ext_trig (4) - paym. trigger. by an external, client. Appi. } CDR_currencyType :: = ENUMERATED {. majorType ENUMERATED {bill (O), E_cash (1)), currency ENUMERATED {FiM (0), USD (1), ...}} - encoded in one octet so that majorType occupies the most significant bit and currency bits 0 -6 104668 LIITE 1 3 CDR_moneyAmountType :: = SEQUENCE {currency CDR_currencyType, value INTEGER (O..MAX_WORD) - in case E_cash is used, the value defines the - sequence number of the E_cash carrier CDR CDR_signatureType :: = SEQUENCE {present ENUMERATED {absent (O), present (1)}, type ENUMERATED {RSA-with-MD5 (0), DES-with-MD5 (1)}, signature OCTET STRING SIZE (64)} CDRformatA :: = SEQUENCE {type CDR_cdrType, length INTEGER (O..MAX_S_WORD), contractNo INTEGER (O..MAX_D_WORD), sequenceNr INTEGER (O..MAX_WORD), service INTEGER (O..MAX_D_WORD), serviceType CDR_serviceTypeType, startTime CDT_TimeType, startTime CDR_timeType watchdogld CDRJdentifierType, serverld CDRJdentifierType, payMethod CDR_paymentMethodType, moneyAm CDR_moneyAmountType, •. trafficData OCTET STRING (SIZE (8)) signature CDR_signatureType} CDRformatB :: = SEQUENCE {type CDR_cdrType, 104668 LIITE 1 4 length INTEGER (O..MAX_S_WORD), contractNr INTEGER (OMAX_WORD), sequenceNr INTEGW (0..MA ), e_cash OCTET_STRING (SIZE (0..200))} Start :: = SEQUENCE {MessageType OCTET_STRING (SIZE (1)) DEFAULT (1) MessageLen INTEGER (O.MAX_LEN), ClientAddr NWAddr, ServerAddr NWAddr, Serverld CDRJdentifierType, Service INTEGER (O..MAX_D_WORD), Connld INTEGER (O..MAX_WORD)} OK :: = SEQUENCE {MessageType OCTET_STRING (SIZE (1)) DEFAULTS) MessageLEN INTEGER (O..MAX_LEN), Contractld INTEGER (OMAX_D_WORD) ), Connld INTEGER (O.MAX_WORD)} Cancel :: = SEQUENCE {MessageType OCTET_STRING (SIZE (1)) DEFAULT (3) MessageLEN INTEGER (O.MAX_LEN), Contractld INTEGER (O.MAX_D_WORD), Connld INTEGER ( OMAX_WORD)}