Classifications

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

Definitions

• the invention is related in general to the implementation of access service in a telecommunications system, in particular to the implementation of charging in connection with access service.
• 'access service' refers to a service which gives the user of a network, such as the subscriber of a telephone network or a LAN user, access to the network that provides services, for example the Internet, or to a section of the network by which the services are being provided.
• Optical fiber is a natural choice for the transmission medium for a trunk network because trunk connections usually require a high transmission capacity, the transmission distances are long and existing routes for cables are often available. With subscriber connections (the line between the local exchange and the subscriber), the situation is also rapidly changing because various multimedia services that require a high transmission rate will soon be commonplace for private consumers as well. However, no major savings are foreseeable in the construction costs of networks providing broadband services in the future because the costs are mostly due to cable installation. On the one hand, it is desirable that as much optical fiber as possible would also be laid in subscriber networks, as it will obviously be needed in the future. On the other hand, the cost of refurbishing the subscriber network is extremely high, and such modernisation will take decades. Consequently, high costs constitute the main obstacle to a more widespread use of optical fiber in subscriber networks.
• the present ADSL (Asymmetrical Digital Subscriber Line) and HDSL (High bit rate Digital Subscriber Line) technologies offer new prospects for high-speed data and video transmission via the telephone line to subscriber terminals.
• the ADSL transmission connection is asymmetric in that the transmission rate from the network to the subscriber is significantly higher than that from the subscriber to the network. Accordingly, the ADSL technology is mainly intended for various subscriber services ("on-demand" services).
• the speed of an ADSL transmission from the network to the subscriber is in the order of 2 to 6 Mbit/s and from the subscriber to the network in the order of 16 to 640 kbit/s (the control channel only).
• the HDSL transmission technology is used for the transmission of 2 Mbit/s digital signals in a twisted pair cable.
• the HDSL technology is symmetrical in the sense that the transmission speeds are identical in both directions.
• a single HDSL transceiver system comprises transceivers that make use of the echo cancellation technology and are inter-connected by a two-way transmission path consisting of a twisted pair cable.
• a HDSL transmission system may include one, two or three such transceiver systems in parallel; for two or three parallel pairs, the speed of each parallel transmission connection is less than 2 Mbit s, being 784 kbit/s for three parallel pairs and 1168 kbit/s for two parallel pairs.
• International recommendations define how the signals at the 2 Mbit/s level, such as the VC-12 signals used in the SDH network or the 2048 kbit/s signals compatible with the CCITT G.703/G.704 recommendations, are transmitted in a HDSL system.
• ADSL appears to be the most promising technology for the implementation of broadband services and, therefore, it is used as an example of the connection technology for the provision of these services.
• the ADSL Forum has defined a general network model for xDSL connections, which is illustrated in Figure 1.
• ATU-R ADSL Transmission Unit - Remote
• ATU-C ADSL Transmission Unit - Central
• ADSL modems or ADSL transceivers
• the terminals TE located at the end user may be of various types, such as cable TV terminals TE1 , personal computers TE2, or ISDN telephones TE3.
• service modules include the so-called Set-Top Boxes, PC interfaces, or LAN routers.
• the distribution network PDN (Premises Distribution Network) in the subscriber's premises connects the ATU-R to the service modules.
• the access node AN forms a concentration point for narrowband and broadband data, where the traffic from the various service systems carried via various networks converges.
• the access node may be at the central exchange of the telephone network
• the letter A in Figure 1 represents the private section of the network, B the public section network, and C the network within the subscriber's premises (the telephones naturally being inside).
• the problem with a network of the type described above is how to charge the end user for access (i.e. for the use of the subscriber line) to the services offered by the service systems, such as Internet services.
• charging should be based on time or the volume of transmitted data, or on both.
• the problem is caused by the fact that the network can be of the connectionless type.
• the network does not feature messages for establishing and releasing a connection (such as SETUP and RELEASE), and so the charging cannot be carried out in the same way as in the conventional telephone network, where it is based on connection set-up and release events.
• the manufacturers of xDSL modems have not included features in their devices that would allow charging based on time or the volume of data transmitted. As a result, it is not possible to query the modems for the data required for charging.
• the terminal is an ISDN or ATM terminal
• each session starts with a SETUP message and finishes with a RELEASE message, in which case time-based charging can be implemented using the conventional method.
• the problem discussed above affects networks where the network section between the terminal and the access node, or at least the link between the terminal TE and the delivery network PDN, is connectionless. More specifically, it is possible to construct the transmission path between the terminal and the access node in such a way that the section between the access node and ATU-R is of the connection- oriented type (such as ATM-based) and the section between the ATU-R and the terminal of the connectionless type (such as an Ethernet link).
• the problem is further complicated by a situation where several customers use the same subscriber line, which makes it impossible to distinguish between users according to the line involved.
• a situation arises, for example, when the public is offered access to broadband services by placing the terminal in public premises, such as a library or shopping centre.
• the same problem arises when employees wish to work from home by establishing a connection only with the LAN of the employer. In this case, it is not possible to determine that the invoice for the session should be addressed to the employer instead of the user. More precisely, the system is unable to differentiate between when a user is setting up a connection as a business user (whose bills are paid by the employer) and when as a private user (who pays his or her own bills).
• the term "user” will be used to refer to the individual who uses the terminal, and the term “subscriber” to refer to the organisation or individual who pays for the use of the service.
• a user can also be a subscriber. Summary of the invention
• the purpose of the invention is to eliminate the drawbacks described above and to provide a solution which can be used to implement an access service in a connectionless network using as simple equipment as possible to ensure that a reliable and flexible charging function can be incorporated into the system.
• Another objective of the invention is to provide a solution that is suitable for use both in networks that support terminal mobility and in situations when the bill is to be sent to an address other than that determined by the subscriber line or the subscriber identified by the terminal network address.
• the idea of the invention is to use a start message to indicate the beginning of a single session when the user accesses the network.
• the entity that generates the start message may vary according to the system involved, and the start message can be transmitted in various ways to the elements that handle billing.
• the idea is to generate, in the network, verifiable charging messages which relate to the service session initiated by said start message and which are furnished with subscriber- specific digital signatures, for example, and to allow (or disallow) access to the network depending on whether the terminal generates such charging records correctly.
• the terminal indicates the identity of the subscriber associated with the current user for verification of the signature against the data of the correct subscriber.
• the system is, in principle, such that all factors essential to data security can be easily implemented: authentication, data integrity, non- repudiation (a party to the data transmission cannot afterwards deny participation in the transaction) and privacy (an eavesdropper is unable to decipher any captured data).
• a significant additional advantage of the system is that it can simultaneously carry out charging for the services used by the customer after he or she has gained access to the network providing the services, such as the Internet.
• the customer can simultaneously see the charging data for the connection itself as well as the services used and receive all charging data fully itemised in one periodic (e.g. monthly) bill.
• the system is also capable of using charging systems that already exist (e.g. in the telephone network), and will thus not require new solutions or investments in this respect.
• Figure 1 illustrates the general network model defined by the ADSL Forum
• Figure 2 shows a network environment in which the method suggested by the invention can be used
• Figures 3a and 3b show a system in accordance with the invention in operation in the network environment illustrated in Figure 2;
• Figures 3c and 3d show alternatives to the systems shown in Figures 3a and 3b;
• Figure 4 shows the dialog box that appears on the terminal display;
• Figure 5 illustrates message exchange between the various system components
• Figure 6 illustrates, in more detail, the operations that take place between the access server and router
• Figure 7a shows the main window of the terminal display
• Figure 7b shows the bill to be sent to the customer
• Figure 7c shows the debt incurred by the user when all the required payments are not received by the charging server
• Figure 7d shows the debt incurred by the user when the clocks of the charging server and terminal are out of synchronisation
• Figure 8 shows the structure and contents of the charging record
• Figure 9a shows the structure of the terminal in the form of a functional block diagram
• Figure 9b provides a more detailed description of the structure of the CDR generator
• Figure 10 shows the structure of the charging server in the form of a functional block diagram
• Figure 11 shows the structure of the access server in the form of a functional block diagram
• Figure 12 illustrates message exchange associated with one preferred additional feature of the system
• Figure 13 illustrates message exchange between various system components when the network uses the mobile IP protocol that permits IP level mobility
• Figure 14 illustrates message exchange between various system components when the network uses the IPv6 protocol
• Figure 15 shows one system in accordance with the invention that supports IP level mobility.
• the network is assumed to include an operator ISP that provides Internet services and is, for the purposes hereof, called the access service provider.
• This example only shows one terminal which is typically a personal computer PC featuring a network interface (such as an Ethernet card) and connected via the LAN cable LC1 (for example, 10BaseT) to the ADSL modem A1 which is in turn connected via an ordinary subscriber line SL to the ADSL modem A2 located in the premises of the access service provider.
• the modem A2 must be located at the exchange premises in order to ensure maximum distance.
• the operator offering the Internet services also serves as a teleoperator.
• the POTS splitter makes it possible for the teleoperator to provide only telephone services and to rent the connection to another service provider for the provision of broadband services. Future antitrust legislation may even compel teleoperators to adopt this policy unless they themselves offer broadband services.
• the network PDN located in the end-user premises is reduced to a point-to-point connection between the terminal and the access service provider.
• the modem A2 is connected by the LAN cable LC2 (such as 10BaseT) to the LAN switch SW of the service provider.
• This switch connects the various subscriber connections to the access service provider network APN, which is connected to the Internet via the router R1 serving as a gateway.
• the access network section of the system is denoted in Figure 2 by the symbol N1 and the external network providing the services by the symbol N2.
• the access network can also be regarded as that part of the network that connects the terminals to the part of the network that provides the services (thus, the router R1 may also be assumed to be part of the access network).
• Ethernet frames are transmitted across an ADSL connection while the modem pair serves as a bridge between the LAN segment of the subscriber and the LAN segment of the access service provider.
• the LAN switch may, for example, be the Centillion 100, manufactured by Bay Network, USA, or the Catalyst 3000, manufactured by Cisco Systems, USA.
• Figure 3a illustrates how the method in accordance with the invention is applied in the network environment shown in Figure 2.
• the end- user terminal (a personal computer) includes a smart card reader CR, and each customer is issued with a personal smart card by which the customer (subscriber) is identified.
• the terminal contains a program library to communicate with the smart card, as well as software that generates, at pre- defined intervals (such as once a minute) while the connection is on, a charging record complete with the user's digital signature and sends it to the network.
• a charging server WD that verifies and collects the charging records generated by the terminals is connected to the network APN of the access service provider.
• the network may include several different charging servers, but there is, however, a dedicated charging server for each terminal.
• the charging server features the memory MS, such as a magnetic tape, which is used for storing all charging records accepted by the charging server.
• the accumulated charging records are transferred periodically to the billing system BS which is preferably an existing billing system in the public switched telephone network PSTN or, for example, a system similar to the existing billing system but located in a broadband network.
• the network NW1 which is shown in general outline in the figure and through which the charging server is connected to the billing system, can thus consist of the public telephone network or a packet or data network.
• this type of billing system (located in the Internet) may also be employed for these purposes. This alternative is denoted by the dashed line in the figure.
• the charging server may also be directly connected to the billing system. Before their transfer to the billing system, the charging records can be temporarily saved in the mass memory device MS1 , which serves as an intermediate storage facility and whose purpose is described later.
• an access server SL is connected to the network of the access service provider.
• the task of the access server SL is to open and close Internet connections by controlling the router/concentrator R1 , which functions as the connecting component between the access network and the network that provides the services.
• the system includes a known DHCP server (Dynamic Host Configuration Protocol) for dynamic allocation of IP addresses to terminals.
• DHCP server Dynamic Host Configuration Protocol
• dynamic address allocation the address is returned to the pool of addresses to be allocated once the connection is terminated or a pre-determined "rental period" of the address expires.
• a description of DHCP is provided in Dynamic Host Configuration Protocol, RFC-1541 , October 27, 1993, by R. Droms.
• the charging and access servers are preferably located in the premises of the access service provider, and they need not be physically separate but can be integrated into the same unit.
• the charging server in particular, can be located on the Internet side of the system, especially if the charging server is owned by a separate organisation which offers billing services to several access service providers.
• the location of the charging server is of little importance, but in practice the selection of the location is influenced by factors such as the following.
• the POTS splitter is omitted in Figures 2 and 3a (cf. Figure 1) because the splitter can also be integrated with the ATU.
• FIG 3b shows an alternative system which is otherwise similar to the system in Figure 3a except that between the access service provider network APN and the switch SW there is the router R2 which, in this case, is the router that is controlled by the access server.
• the access control point can thus be located at either router.
• the router R2 routes the traffic from the terminals either to the servers located in the access service provider network or to the router R1. It is also possible to have access control points at both routers. Such a situation may arise, for example, when some of the services are located in the access network and the rest elsewhere.
• Figures 3c and 3d show two other alternative networks.
• several individual access service providers are connected to the shared router R1 , which is connected via a separate access network ACN to the router controlled by the access server.
• the access service providers have their own routers (not shown), and so their networks are directly connected to the access network.
• the transmission paths between both the access server and the access control point and between the access server and the charging server are secured to ensure the privacy of the transmitted data. This can be accomplished either physically by using a dedicated transfer medium inaccessible to others between the elements involved (point-to-point connections) or by using an encrypted transmission channel between the elements. Secure transmission connections prevent unauthorised use of the system.
• Charging can start when the user inserts his or her smart card into the card reader that is connected to the terminal.
• the program residing in the terminal opens a window on the terminal display.
• This window is called a dialog box.
• Figure 4 shows an example of the dialog box.
• the connections can be divided into different types, for example, by having system feature connections separate from the full-featured Internet connection, such as a permanent connection to the E-mail server, which notifies the user of new E-mail messages on a real-time basis.
• the latter service may be significantly cheaper (say FIM 5/day) than a full-featured Internet connection.
• This type of limited connection can also be created to servers other than the E-mail server, such as the workplace LAN server.
• the user may also use the menu to select the preferred operator or choose an encrypted and a non-encrypted connection.
• the services that can be selected from the drop-down list of the dialog box can be saved in the terminal or the smart card to make it possible to open the dialog box before the terminal creates a connection to the network.
• the terminal can first automatically retrieve the most recent service list from the access server, charging server, or another network server, as soon as the user inserts the smart card into the reader. This means a slightly longer delay but then the user can always make a selection among the latest services and also receive information on the current rates.
• the service options offered by the dialog box can also be updated automatically during the connection, ensuring that the terminal (or the smart card) always contains a record of the services available during the last access session.
• the smart card contains a record of the user profile data, which, in this example, is the user name (in ASCII format), user identifier number, the user's public and private keys, and the balance of the user's bill.
• the public key can be both readable and available for use.
• the private key is only available for use (it cannot be read from the card).
• Availability for use means that the key involved can be used to create and check a digital signature, i.e. encrypt and decrypt data.
• the balance of the bill is the amount paid by the subscriber involved (this sum can be zeroed at any time, and so it is not the same as the final amount of the actual bill, meaning that it only serves as a reference to the user of the terminal).
• the smart card can be used to save the public key of the charging server to ensure that the messages really come from the charging server.
• Subscriber data such as name, identifier, and private key can be stored in the terminal memory (on the computer hard disk or diskette) instead of on the smart card, provided that a lower level of data security is acceptable.
• Figure 5 illustrates communication between the various components of the system.
• the terminal software sends the service request message lnit_Service to the access server SL ( Figure 5).
• the service request message includes at least the current IP address of the terminal (ClientAddr) and the service type (Type) selected from the dialog box menu.
• the access server verifies the message and transmits the start message START to the charging server WD.
• the start message includes the current IP address of the user (ClientAddr), the address to be notified when the user stops paying (ServerAddr), the service identifier (Serviceld), access server identifier (Serverld), and the (temporary) identifier (Connld) which is used for identifying the various message types travelling between the servers (START and the messages OK and CANCEL, which are discussed later).
• Messages lnit_Service and START are in this context called start messages which are used to indicate the beginning of a single access service session to the access server and to the charging server.
• the charging server WD On the basis of the information received, the charging server WD generates a charging record (CDR, Charging Data Record) of a certain type that contains the contract data related to the access session, including the contract ID that identifies the active access session.
• CDR Charging Data Record
• the structure of this charging record is illustrated in a later description that applies to all charging records.
• the charging server sends this starting charging record (contract CDR) to the terminal (arrow A, Figure 5).
• the terminal returns the charging record associated with the contract to the charging server, complete with the digital signature ( Figure 5, arrow B).
• the digital signature refers to a known encryption algorithm based on a pair of keys where encryption is carried out using the private key, allowing anyone to decrypt the message using the public key.
• the terminal can effect the signing of the contract CDR (accept the contract) automatically as described above, or the terminal can, after having received the contract CDR from the charging server, open it for view on the display in a separate contract window that once more requests the user to confirm the acceptance of the access service contract.
• the terminal transmits the signed contract CDR to the charging server.
• the charging server WD After having received the signed contract CDR, the charging server WD verifies the signature by a known method in order to authenticate the CDR. To do so, the charging server retrieves from its subscriber database the public key for the customer involved (arrow C). There are several way of locating the correct public key. First, the terminal can, upon receipt of the contract CDR for signing, retrieve the customer's (subscriber's) name and identifier from the smart card and add this data to the signed contract CDR which is then sent to the charging server. The charging server uses the identifier number to retrieve the correct public key from its subscriber database. Another alternative is to have the charging server check the customer identity and access right to the system before the contract CDR is formed.
• the charging server When the charging server receives the START message from the access server, it sends an authentication request (not shown in the figure) to the IP address contained in the START message.
• the terminal may insert in the reply, in addition to the customer identifier number, other customer-specific information, then adds the signature to the reply and sends the signed reply to the charging server.
• the advantage offered by this alternative is that the charging server knows the identity of the user before the contract is formed, making it is possible to create customer-specific tailored contracts (e.g. offering different rates for different customers).
• the downside is, naturally, the need for two extra messages, which slows down the setting up of the connection.
• a third alternative is a system where the terminal inserts the customer identifier number into the lnit_Service message before the access server forwards the identifier to the charging server in the START message.
• the customer identifier number is known to both the charging server and the access server.
• the customer identifier is formed from two components. The first component identifies the origin of the customer (i.e. the customer's dedicated charging server). This component is used for routing the START message to the charging server involved. The second component is encrypted using the public key of the customer's dedicated charging server, meaning that it is not recognised by the access server.
• the customer identifier can also be made to look different for each instance of service, for example by attaching it to a character string of standard length that changes for each instance of service, for example as a function of time.
• the customer identifier consists of the area code and signature. The area code is necessary if the ADSL connection users have contracts with different (several) charging service providers.
• the charging server saves the accepted contract CDR in its charging database (arrow D) for some time in case the customer makes a complaint about the service at a later date.
• the charging server requests the access server to give the customer access to the network (arrow E) by sending to the access server an OK message, which includes the said identifier (Connld) used for identifying the messages specific to that connection, as well as the contract identifier (Contractid) assigned to the service session.
• the access server induces the router R1 to allow the customer to access the (Internet) network. This process is indicated by arrow F in Figure 5 and is described in more detail in connection with Figure 6.
• the charging server If the charging server does not accept the charging record (for example, if the signature is incorrect), it will send, instead of the OK message, the message CANCEL which includes the same fields as the OK message, although no contract identifier is needed at this point because the user is not given access to the network.
• the connection is terminated when the user finishes using it, a similar CANCEL message is sent (arrow G), but because disconnection is, at this point, carried out normally, the contract identifier included in the message must also be used.
• the CANCEL messages are identical in terms of structure but used differently in terms of function, depending on the point of time at which they are received.
• the access server may disconnect the user for other reasons as well, for example in the event of over-loading (if additional capacity must be reserved for vital connections, less important connections may have to be terminated), or the charging server may request the access server to close down the connection for other reasons, e.g. in the case of overloading or in a situation, where charging records cannot be received as specified.
• the start message from the terminal can also be transmitted directly to the charging server.
• the charging server interface can be configured identically for all service providers, making it possible for the charging server to handle billing for other service providers in addition to the access server. If the router were capable of detecting traffic initiating from a specific source address and notifying the access server thereof, no start message would be needed (as the start message would originate from the router).
• Figure 6 illustrates in more detail the communication taking place between the access server and the router during the opening phase of the connection ( Figure 5, arrow F).
• the connection between the access server and router is a known Telnet connection because the SNMP protocol (Simple Network Management Protocol) cannot yet be used for updating the access lists of the router involved.
• SNMP protocol Simple Network Management Protocol
• the access server SL controls the router R1 interface through which the user gains access to the Internet.
• the access list AL is stored in the router. As shown in Figure 6, this list can include five columns, the first column showing the IP addresses (ClientAddr) of the terminals that can use the interface involved to access the Internet, the second column showing the above-mentioned connection identifier (Connld), the third column the contract identifier (Contractid), the fourth column the number of incoming packets, and the fifth column the number of outgoing packets.
• ClientAddr IP addresses
• Contractid contract identifier
• a similar list may exist for both transmission directions of the interface.
• the access server SL When the access server SL has received the OK message from the charging server, it first sends the router a command that clears the access list. This command is indicated by CLEAR_AC. Next, the access server sends a command that allows all Internet protocol control messages to pass through (PERMITJCMP). If the charging server and/or the access server are on the Internet side of the router R1 , the access server then sends the commands necessary to enable all connections to the charging server and/or access server (PERMIT_WD and/or PERMIT_SL). Finally, the access server transmits a command that permits access through the interface for a specific terminal. One such command is sent for each ongoing connection (PERMIT_ADDR1...PERMIT_ADDRN). In response to the commands, the router updates the access list. A similar update is carried out for each new connection. In other words, the entire list is first cleared and then rewritten with the new terminal added to the list.
• PERMITJCMP Internet protocol control messages
• the charging server sends the addresses of the terminals that are currently paying for access to the network providing the services, or at least the data on any changes relative to the previous access list.
• the charging server sends a CANCEL message to the access server ( Figure 5, arrow G).
• the access server updates the access list as described above so that the user involved is removed from the list during the update. This process is indicated by the arrow H in Figure 5.
• the router can save several updating events and include them all in the new access list in one go.
• the process described above can be employed, for example, with the CISCO router model 7000 featuring, for example, the IOS 11.2 operating system.
• future routers will probably include features that allow more efficient updating of the access list by making changes to the items only where necessary.
• the terminal can be used to make use of the services provided by the Internet. To maintain the connection open, the terminal generates charging records at regular intervals, sends them to the smart card for the digital signature and then sends the signed charging record to the charging server, which saves the accepted charging records in its charging database.
• the user can use his/her service browser (such as a known web browser) to locate suitable services on the Internet and to conclude additional contracts with the providers of such services.
• his/her service browser such as a known web browser
• the customer finds a suitable service, such as a Video-on-Demand service, he/she selects the service, for example by clicking the appropriate option.
• the server of the service provider sends to the charging server WD the service identifier that identifies the film concerned as well as the identifier for the customer involved, which the server can determine, for example, on the basis of the source address of the messages received from the customer's browser program (such as the socket address of the TCP connection).
• the charging server WD starts the process that operates the service involved.
• the charging server retrieves from the service database the parameters corresponding to the service concerned, and sends to the terminal the contract CDR, which contains the charging parameters to be used during the service session involved as well as the contract identifier.
• the terminal program opens a window on the terminal display. This window will be referred to as the contract window below.
• the window displays the basic data on the various parties and the service involved. Additionally, the window displays the contract identifier that identifies this particular service session. Consequently, this contract only concerns an individual service, such as the viewing of the selected film, being a service that is completely external to the access service.
• the system carries out charging not only for the access service but also for other services simultaneously. Such charging may depend, for example, on the contents of the service provided.
• the charging server verifies the origin of each charging record by using the public key of the customer (subscriber) involved, and saves the accepted charging records in the charging database.
• Each CDR to be sent from the terminal to the charging server represents a charge for access time over a certain time interval and includes a contract identifier, which is used to separate the services from one another. Because only one system user can use a specific terminal at any one time, the signatures of the charging records that are received from the source address remain unchanged during any single access session. All records of this type are accumulated specifically for each individual subscriber and contract identifier. To determine total billing for each type of service (such as access service), the system adds up the charged amounts in all the charging records related to that particular contract identifier.
• the CDRs are periodically transferred to the billing system BS ( Figure 3), where they are processed into bills using a known method and sent to the customers.
• Each bill contains a list of services and charges for all of the services used by the customer during the billing period (such as one month).
• the bill can be delivered as a hardcopy by post, or in an electronic form to the terminal.
• Figure 7b shows a bill sent to the customer.
• the bill contains the subscriber data as well as a list of the services used during the billing period. For each individual service, the bill can specify, for example, the service type, service provider, contract identifier used for receiving the service, start time and duration of the service, and the price.
• the system may make use of a total of nine (0 through
• Contract This is the initial charging record (arrow A, Figure 5) that the charging server sends (unsigned) to the customer and that the terminal returns to the charging server complete with the signature, provided that the customer accepts the contract.
• Payment This type of charging record is sent, complete with a signature, during a service session from the customer's terminal to the charging server, which verifies it.
• This CDR is similar to type 1 except that it includes a statement indicating that it is the last CDR that the terminal is going to send during the current service session.
• the terminal When the user terminates the service him/herself by pressing the Quit button, the terminal first sends a CDR of type 1 and after that a CDR of type 6. In this way, the charging server can distinguish a user-initiated termination from a normal termination of the service (such as the end of the film). This type of record can also be used for one-time charging.
• Pulse This type of CDR is sent from the charging server to the terminal. Its purpose is to tell 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 during a specified period of time, the charging server sends an abort message to the server of the service provider.
• Missing sequence number This record is sent by the charging server to the terminal (during a valid continuous billing contract) to notify that a CDR with a certain sequence number has not been received by the charging server or that the CDR received was not valid. In such a case, the terminal can send the CDR again to remedy the situation. However, this type of functionality is not necessary for either party. If the terminal does not respond to this type of CDR, the best option is to ensure that the billing system will have no right to charge for the portion of the missing CDR. 5.
• Modified contract This type of CDR sent by the charging server to the customer is similar to the type 0 charging records except the contract identifier supplied in the message is not new but the same as the number of the short-term contract currently in use. This charging record is sent during a service session to indicate that the charging parameters have changed. The terminal can, for example, accept the new contract automatically, if the price has been lowered; otherwise, specific acceptance by the customer may be required.
• CDR This type of CDR can be sent in either direction to indicate that the contract is to be terminated.
• the CDR is signed by the sender.
• Digital cash Another way of making use of the billing system is to have a CDR (type 1 or 2) related to a certain payment include payment in digital cash. However, the charging server does not transfer the digital cash to the billing system. Instead, the digital cash is transferred (whenever a specific and relatively small amount of digital cash has accumulated) directly to the server of a bank or a network server of some other organisation, which then debits the customer's account directly. Digital cash can be used along with the centralised billing system BS in the same way as in electronic commerce, or as an alternative to centralised billing.
• Synchronisation of charging This record is sent by the charging server to the terminal (during a valid continuous charging contract) to indicate that the payment CDRs do not cover the per-minute rates of the continuous contract (when, for example, the terminal clock is running too slowly).
• the synchronisation CDR indicates how much the customer should pay to maintain the contract operative.
• Figure 5 illustrates the charging procedure for a single service.
• the category of each message is indicated above the arrow symbolising the message.
• the figure illustrates a situation where the charging server detects once during the service that a certain charging record is missing.
• the interval between two consecutive type 1 CDRs can vary. If the load that the terminal is subjected to increases very much and CDR generation is delayed relative to rated performance, the charge included in the CDR is, correspondingly, greater.
• the first threshold value (A) is the maximum outstanding debt that the user can owe to the charging server as a result of use that remains unpaid.
• the second threshold (B) is the maximum value of outstanding debt following payment. Both limit values are linked to independent timer values (T A and T B ).
• Figures 7c and 7d illustrate a solution to the said problems.
• the time axis t represents the time of the charging server and the time axis t1 the time of the terminal. In the figures, the time is expressed in seconds.
• the vertical axis at the top of the figure shows the user debt to the charging server while the lower section shows the charging records sent by the charging server and the terminal. For the purposes of this example, network delay is assumed to be negligible.
• the clocks run at the same speed, but in Figure 7d the terminal clock is slower than that of the charging server.
• the terminal sends the signed contract (CDR-0) to the charging server.
• the user debt D(t) begins to increase as of this moment. As no payments are received, the debt increases linearly as a function of time. The rate of increase of the debt (money units per time unit) is defined in the contract.
• CDR-1 the debt is reduced by the amount stated in the CDR involved.
• the charging server calculates the balance of the debt periodically (for example, once a second). If D(t) > A, the charging server sends a type 4 CDR to the terminal. If the charging server does not receive the outstanding payment within the time T A , it terminates the contract.
• the charging server sends a type 4 CDR to the terminal and the terminal re-sends the payment CDR in response. It is also possible to define a maximum period of time that the charging server can operate without receiving a payment CDR. If this time limit is exceeded, the charging server sends a type 4 CDR.
• the charging server checks the amount of debt following each regular payment, if not more frequently. If the terminal clock runs at a slower speed than the charging server clock, as shown in Figure 7d, the balance of the outstanding debt after the payment increases payment by payment. When the amount of outstanding debt after the payment exceeds the threshold value B, the charging server sends, to the terminal, a type 8 CDR (synchronisation), which contains information concerning the amount of the desired payment. In response, the terminal transmits a signed synchronisation CDR. If the charging server does not receive the outstanding payment within the time T B , it terminates the contract.
• a type 8 CDR synchronisation
• TYPE Indicates the type of the CDR, i.e. which of the eight above- mentioned charging records is involved.
• LENGTH This field indicates the total length of the CDR in bytes, including the type and length fields.
• CONTRACT NUMBER This field includes an integer given by the charging server. The number is identical for all the CDRs that relate to the same charging session.
• SEQUENCE NUMBER An integer that indicates the order of generation of the CDRs during one charging session.
• the terminal assigns the number 0 to the first contract CDR (type 0) it returns, after which the number is increased in increments of one. This field is not defined for CDR types 3, 5, 6 and 7, and in type 4 it indicates the sequence number of a missing CDR.
• SERVICE IDENTIFIER The contents of this field indicate the service for which the customer is being charged. The value of the parameter in this field is based on a contract between the billing service provider and the (multimedia) service provider.
• SERVICE TYPE The parameter in this field is used for a rough classification of the services for statistical purposes, such as web sites, Video- on-Demand, file transfers, etc.
• STARTING TIME The parameter in this field shows the current time for CDR types 0 and 5 and also 3, 4 and 6, and the start time for the charging period for types 1 and 2.
• ENDING TIME The parameter in this field defines the ending of the charging session for CDR types 1 and 2. With CDRs of types 0 and 5, the field parameter specifies how often the charging server expects to receive a payment CDR. This parameter is not defined for other types of CDRs.
• IDENTIFIERS The parameter in this field indicates the customer, charging server and server identifiers. The identifiers can be integers or network addresses, but they must be unique within the billing system.
• the parameter in this field is defined for CDR types 0, 5, 1 and 2.
• the methods of payment may be classified as follows: free, one-time charge (one CDR), periodic or externally triggered, i.e. another process in the terminal may trigger it.
• a terminal video player program can trigger CDR generation once a minute, if an acceptable video signal has been received during the preceding minute.
• a system in which the charging server triggers CDR generation using the parameter in the method of payment field is described later.
• AMOUNT OF MONEY This field indicates the debt incurred by the customer (either for the entire session or for a period of time between two CDRs).
• TRAFFIC DATA This field contains information transmitted from an external application on the terminal to the terminal and forwarded to the network.
• SIGNATURE This field contains the customer's digital signature, which is used for the authentication of the CDR.
• Appendix 1 provides a more detailed description of the structure of the CDR using the Abstract Syntax Notation 1 (ASN.1), which is a common description language for data structures used in the telecommunications field.
• ASN.1 Abstract Syntax Notation 1
• Charging records and the said messages can be sent, for example, in the data field of IP packets, which may contain one or more charging records.
• Charging operates correctly when the network access and payments are in synchronisation with one another, i.e. when the paying customers have access to the network providing the services and the non- paying customers do not.
• a fault may lead to a situation where the router denies paying customers access to the network providing the services or allows access for non-paying customers (who do not send payment CDRs).
• the access server polls the router and the charging server. From the router, the access server obtains the access list and from the charging server the IP addresses of the customers who are paying for access to the network at that particular moment. If the address of a paying customer is not included in the access list, the access server adds the address to the list. If an address included in the access list is not included in the list of paying customers in the charging server, the access server removes the address from the list.
• the system can be configured to allow the service provider to set the desired polling interval.
• FIG 9a illustrates the operation of the terminal (CT) by means of a functional block diagram.
• the CDR generator CG Connected to the CDR generator is the security library SLI, whose memory contains the customer's private encryption key and which executes the signing of the charging records.
• the CDR generator creates the CDRs and transmits them to the security library where they are signed using the customer's private encryption key.
• the security library returns the signed CDRs to the CDR generator, which forwards them to the charging server WD.
• the security library executes the encryption, signing and signature verification.
• the security library can be a hardware-based or a software-based solution. However, the hardware-based solution offers better security. Thus, the security library, or part of it, can be construed as described above using a smart card that contains, for example, the private encryption key of the customer.
• the terminal contains elements for receiving the service. These can include, for example, a service player VP, which can be a video player reproducing the video signal received from the network and may also give the CDR generator commands to generate charging records.
• the service browser SB, the service player VP, and the CDR generator are connected to the network via the terminal's communications library CL.
• the CL puts together the protocol stack according to which the terminal operates. This protocol stack may, for example, consist of a TCP/IP stack, such as Microsoft's Winsock.
• the start-up logic unit SUL of the terminal initiates the sending of the start message to the access server when the user inserts the smart card in the reader.
• the terminal can also incorporate a charge counter BC that the customer can use to check the accuracy of the bill sent by the service provider.
• the terminal can include various components for monitoring the quality of service (QoS) of the information flow received. For example, a video player can give the source the command to stop transmitting information when the quality of service falls below a certain level.
• QoS quality of service
• FIG. 9b shows the functional block diagram of the CDR generator in greater detail.
• the contract logic unit CLU1 handles the generation of charging records based on the information stored in the configuration database CDB. It contains the logic that transfers the received contract information to the graphical user interface GUI and generates the type of charging records described above. This logic includes timing components TM that define the time elapsed between two consecutive CDRs.
• the contract logic unit CLU1 is connected to the communications library and the network via an external control interface ECI, and to the service player via an internal control interface ICI.
• the external control interface carries out the conversion between the internal and external CDR formats.
• the internal control interface handles message transfer between the service player and the contract logic unit and performs the necessary conversions between the message format used by the service player and the internal message format of the equipment.
• the connection between the internal control interface and the service player (interface A3) can, for example, be realised using a communications library (TCP socket).
• the configuration database CDB is used for saving the settings made by the user (user preferences), and it can also be used for storing information on various services (such as films) displayed to the customer in response to the service identification received.
• This database can, for example, be created with Microsoft Access or Borland Paradox.
• the configuration database is controlled via the management unit MM.
• the management unit, the configuration database and the contract logic unit are all connected to the graphical user interface (GUI) of the device, which can, for example, be implemented using Java applets or the Microsoft Visual Basic programming tool. Part of the configuration database can be located in the network.
• GUI graphical user interface
• the service player is designed, for example, for Video-on- Demand, it can, for example, be implemented using a personal computer and a program designed for Video-on-Demand services.
• One such program is StreamWorks offered by Xing Technology Inc., USA.
• the management unit and the contract logic unit are linked to the security library via the A1 interface.
• the security library and the A1 interface can be implemented, for example, using the SETCOS 3.1 smart card (and smart card reader) from Setec Oy or some equivalent product based on the international smart card standards.
• the international standardisation organisation ISO has defined a series of smart card specifications as follows: ISO 7816-1 (physical dimensions), ISO 7816-2 (location of contacts), ISO 7816-3 (transmission protocols) and ISO 7816-4 (command and file structures).
• ISO 7816-1 physical dimensions
• ISO 7816-2 location of contacts
• ISO 7816-3 transmission protocols
• ISO 7816-4 command and file structures
• a user may have several different smart cards, each of which opens a certain type of connection.
• One card can, for example, be used for setting up a fully featured Internet connection while another card (whose subscriber is the employer) may only be used for accessing the LAN at the workplace.
• FIG 10 illustrates the structure of the charging server WD by means of a general block diagram.
• the core of the equipment consists of the contract logic unit CLU2 that has access to the service database SED, the subscriber database SUD, and the charging database BD.
• the service database contains information about the services offered by the various service providers and the parameters for charging for the use of the services.
• the charging server can also change the charging parameters independently, for example according to the time of the day.
• the subscriber database contains the customer data for the operator that manages the charging server (including the public key of each customer).
• the charging records received from the terminals are saved in the charging database.
• An encryption block CM is associated with the contract logic unit to verify the charging record signatures. This block corresponds to the SL block of the terminal.
• the contract logic unit receives from the terminals charging records signed by the terminals and forwards them to the encryption block for verification.
• the contract logic unit saves the accepted charging records in the charging database.
• the contract logic unit is connected to the network through the communications library CL that forms the protocol stack defining the connection to be set up.
• contract logic units complete with the functions described above can, for example, be implemented using tools based on the international System Description Language (SDL) standard, such as the SDT tool from Telelogic AB.
• SDL System Description Language
• the databases of the charging server can reside in the memory MS described above ( Figure 3) and are located in connection with the charging server.
• the charging records can be saved in a separate mass memory MS1 ( Figure 3) which is located between the charging server and the billing system in the network and which is organised in such a way that the billing system can easily handle the information stored in it.
• MS1 Figure 3
• Figure 11 illustrates the structure of the access server SL by means of a functional block diagram.
• the server features an interface unit IU, which comprises the router interface unit RIU, the charging server interface unit WIU, and the terminal interface unit TIU.
• the TIU receives the aforementioned starting message lnit_Service from the terminal and initiates the billing session for the customer involved.
• the router interface unit monitors the router access list while the charging server interface unit handles communications with the charging server.
• the connection logic CLO is a simple state machine that links the various interface units.
• the connection logic also maintains a list of all open connections and two queues, one of which contains the connections to be terminated and the other the connections which are to be set up.
• the router control unit RCU which includes the router command set, controls the router by handling the maintenance of the aforementioned access list.
• the synchronisation unit SU carries out synchronisation of the said payments and access rights by comparing, at certain intervals, the router's list of open connections with the addresses of paying customers obtained from the charging server. Any conflicts are corrected, ensuring that no error in charging persists longer than the said interval.
• the router connection control unit RCC monitors the connection between the access service and the router. As it is assumed for the purposes of the example that the connection between the router and the access server is a Telnet connection, the router breaks the connection if it remains inactive for too long a time. The task of the router control unit is to activate the connection if the router happens to break it, for example, for the above reason or because of other interferences in the connection.
• the volume monitoring unit VCU and the charging database BD2 used by it are included in the access server, at least if charging is to be based on the volume of transferred data.
• the control unit uses the router access list to check the packet counts through the router interface unit and saves the data in the charging database BD2, ensuring that the number of packets and the IP addresses used by the terminal for the connection are stored for each individual contract identifier.
• the data in the access server charging database are combined with the data in the charging server charging database according to contract identifier. This makes it possible to take account of the volume of transferred data in the bill.
• the embodiment described above does not, as such, provide the addition of the subscriber signature to the packet count data, meaning that the user would have to take the packet counts determined by the system on trust.
• the terminal can verify that charging is carried out correctly.
• a two-phase procedure is adopted.
• the access server notifies the terminal when the volume to be charged has been increased by a certain value (for example by 50 Mb). In this way, the terminal can monitor the volume count performed by the access server and compare it against its own records.
• the access server sends each volume-related CDR to the charging server, which forwards it to the terminal for a signature.
• the procedure is similar to the signing of the contract described above; it offers the terminal user an opportunity to monitor charging and makes it difficult to repudiate bills. This method is explained below in more detail with reference to Figure 12, which illustrates the communication between different elements.
• the system creates a separate "volume agreement" in the form of a contract that is triggered externally (arrows 121 to 124).
• the access server reads the desired packet counts from the router and saves the data in the charging database BD2.
• the access server sends a signed CDR of type 3 (pulse) to the charging server (arrow 126).
• the access server sends to the terminal traffic data port a message VM, which contains information on the volume of transferred data (indicated by the term "traffic data").
• the volume information will be included in the next CDR to be signed, and the user, or at least the terminal, will have the opportunity to verify the volume before the CDR is signed.
• the charging server When receiving a type 3 CDR from the access server, the charging server identifies the contract as an externally triggered contract and forwards the CDR involved to the terminal (arrow 127). If the user or the terminal accepts the volume count, the terminal generates a payment CDR, inserts the received data volume information in the traffic data field of this payment CDR, and sends the payment CDR to the charging server (arrow 128). The charging server forwards the CDR, or the data contained in it, to the access server (arrow 129) that verifies at least the data contained in the traffic data field. Depending on the outcome of such verification, the access server either terminates the service or allows it to continue. In this case, the service provided probably consists of a combined service that includes both a time- based and a volume-based contract.
• the charging server sends a new contract (arrow 122) whose method of payment parameter contains a value indicating an externally triggered payment.
• the terminal receives a type 3 CDR that indicates the amount of the payment required.
• the terminal either automatically accepts the payment or the data are shown on the terminal display to allow the user to decide whether to accept the payment transaction. If the payment is accepted, the terminal changes the CDR type to 1 (payment CDR), signs the CDR, and sends it to the charging server (arrow 128).
• a payment transaction can also be triggered by some other external object, such as the charging server sending the terminal a command indicating that payment should be effected.
• This type of command is transmitted to the socket address that corresponds to the traffic data.
• the command message also includes the contract identifier information. After this, the terminal makes the payment. In this case, the command only states that a payment is required. The actual amount of payment is defined by the contract.
• Volume-based charging can be carried out in such a way that the terminal or the user is constantly aware of the size of the bill being incurred. As every payment must be accepted, repudiation of charges is extremely difficult. Messages are only sent when payments are required, so if there is no traffic to or from the terminal, no blank or superfluous charging messages are generated either. Because this feature is implemented on the application level, volume-based charging is not restricted to any specific technology, and there can be several "chargers" between the service provider and the terminal simultaneously charging for services on a volume basis.
• connectionless network providing access services where it is necessary to identify each individual user of a certain network address, or where the user is not necessarily the service subscriber who pays for the service.
• the terminal can also be connected to a network providing services through a wireless connection. Future types of connection may vary considerably.
• IP address user network address
• the method according to the invention can also be applied in situations where subscribers move from one location to another.
• use can be made of the Mobile IP protocol, which is a version of the existing IP that supports terminal mobility. (The principle of the Mobile IP is explained, for example, in the article Supporting Mobility with Wireless ATM, by Upkar Varshney, published in Internet Watch, January 1997.)
• Mobile IP is based on a system where each mobile host or mobile node has an assigned agent (“home agent”) that forwards the packets to the current location of the mobile host.
• home agent agent
• the foreign agent carries out a number of checks with the home agent of the mobile host, registers the mobile host and sends the registration information to it.
• the packets addressed to the mobile host are transmitted to the original location of the mobile host (the home agent) from where they are forwarded to the current foreign agent, which, in turn, forwards them to the mobile host.
• each user can have a dedicated (home) charging server that manages the user's public keys and serves as the home agent.
• the access servers i.e. the foreign agents
• the charging server involved retrieves the public keys from the user's home charging server and takes over the charging function.
• What is essential is that the subscriber's public key can be securely transferred to a charging server close to the subscriber to make it possible for the charging server to verify the charging records. (If such transfer cannot be securely carried out, a third party may be able to modify the key during transfer and thus generate expenses that will be included in the bill of the original subscriber).
• the subscriber's public key can be transferred to a database that is close and accessible to the charging server.
• the closest charging server can handle charging using the identifier of the subscriber's dedicated charging server.
• the CDRs accumulated during the session will be transmitted to the subscriber's dedicated charging server when the service session is terminated.
• the home and foreign agents are shown as physically separate elements, but as previously indicated, the access server can also serve as the foreign agent while the home charging server can serve as the home agent.
• the foreign agent FA continuously transmits, to its own subnetwork, broadcast messages known as "agent advertisements" and indicated in the diagram by the letters AA.
• the terminal When the terminal connects to the said subnetwork, it will receive these messages and deduce from them whether it is connected to its own home network or some other network. If the terminal detects that it is connected to its home network, it will operate without any mobility services. Otherwise, the terminal will be given a care-of address for the foreign network.
• This address is the address of the point in the network to which the terminal is temporarily connected. At the same time, this address constitutes the termination point of the tunnel leading to the terminal involved.
• the terminal receives the address from the previously mentioned broadcast messages that the foreign agent keeps sending.
• the terminal sends the registration request RR to its home agent via the foreign agent FA.
• the request includes, among other things, the care-of address just assigned to the terminal.
• the home agent updates, in its database, the location data for the terminal involved and sends the registration reply R_Reply to the terminal through the foreign agent.
• the reply message contains all the necessary information on how (on what terms) the home agent has accepted the registration request. All the messages between the terminal, foreign agent and home agent described above are standard mobile IP messages.
• the foreign agent FA sends the above-mentioned start message, i.e. the charging service request lnit_Service to the access server SL.
• This message is equivalent to the service request message shown in Figure 5, indicating the beginning of a single service session.
• the message includes, among other things, the care-of address of the terminal involved.
• the system operates as shown in Figure 5, except for termination of charging and the acknowledgement message ACK, which will be discussed later.
• the access server checks the message received and forwards the start message START to the charging server WD. This is followed by contract negotiations between the charging server and the terminal, the usual outcome of which is that the user is given access to the network. Termination of charging differs from that of fixed terminals shown in
• the termination can, in a mobile IP environment, be effected either by the foreign agent or the charging server, depending on which of the elements first detects the change. If the foreign agent detects that that the user has exited the network, it will send the end message CANCEL(1) to the access server. The access server forwards the said message to the charging server and closes down the router for the connection involved. The foreign agent will automatically detect the user exit because the mobile IP requires regular messages from the terminal to indicate its continued presence in the subnetwork. These "alive" messages are intended only for the home agent, which does not forward them. However, if it is the charging server that detects the user exit first, it will send the access server the end message CANCEL(2), which removes the connection from the router. In all other respects, the termination of the connection includes the same options as described above.
• the user or the terminal does not, then, send the start message (as shown in Figure 5); instead, the operation of the foreign agent is modified to allow it to initiate charging when the terminal connected to the subnetwork that it serves registers with its dedicated home agent through the foreign agent.
• the foreign agent maintains a special charging initiation timer that starts when the service request message is transmitted to the access server. If no ACK message is received before the timer expires, the foreign agent attempts to re-start charging by sending a new service request to the access server. This is a process that the foreign agent performs for all the terminals in its area with no on-going charging.
• the access service provider can reliably restrict the users to those who can be charged access to the network although the mobile IP, as such, does not offer such a feature.
• a foreign agent is not absolutely necessary for a mobile IP network. If no foreign agent is used, the network will still include a DHCP server or other mechanism for assignment of temporary addresses. If, in such a situation, the terminal is to use mobility services, it must register with its home agent. Then, the DHCP server or home agent may serve as the access server, depending on the network configuration.
• the foregoing description relates to the access service for mobile IP connections. If the routing protocol is IPv6, which has no special foreign agent, the access service must be initiated somewhat differently.
• the default procedure is that the terminal waits for an advertisement message from the router. This message may give the terminal permission to generate its own address or obligate the terminal to use the DCHP server for a temporary address.
• the terminal After receiving the said temporary address, the terminal sends binding updates that are used to update the data on network routers relating to the (fixed) home address of the terminal and the associated temporary address. These binding updates are transmitted to all the nodes that the terminal communicates with, in particular to the dedicated home agent of the terminal. Using these binding updates, the nodes update their routing data to be able to forward the packets intended for the terminal involved directly to its temporary address.
• Figure 14 provides a simplified description of the message exchange between the various components when the routing protocol is IPv6.
• the routers may require that the new users (terminals) connecting to the network register with the local DHCP server DHCP_S.
• the terminal sends the DHCP server the registration request (REQUEST) in response to the advertisement message it received.
• the DHCP server After assigning a temporary address (message ACK) to the terminal, the DHCP server initiates charging by sending the start message lnit_Service to the access server SL. From the point of view of the charging and access servers, the DHCP server thus assumes the same role as the foreign agent in a mobile IP network. More precisely, by sending the said start message, it informs the access server of the new terminals that are being connected to the network.
• the protocol is similar to the above-described mobile IP case (in which the network includes a foreign agent).
• the default configuration for the gateway router R1 must allow all terminals connecting to the network to access the access and charging servers.
• a terminal moves from one subnetwork to another (i.e. from one access server to another), it is possible to negotiate a new contract, renegotiate the existing contract or renew the same contract depending on how the conditions will change as a result of handover. For example, if the operator also changes at the same time, a new contract can always be negotiated. If the operator remains unchanged but the quality of service provided by the new network is markedly different from that provided by the previous network, the existing contract can be revised by renegotiating the terms. The party making the decision on the handover event should also decide whether the existing contract is terminated or renewed. At any rate, the user has a right to know which network he or she has accessed and on what terms the service is provided.
• the network environments illustrated in Figures 13 and 14 are similar to the examples given in Figures 3a through 3d, except that the LAN switch is replaced by a wireless (or wired) access network, ATU-C is replaced by a joint access point, such as an intelligent hub or similar, and ATU-R is replaced by the terminal interface (card).
• the DHCP server is replaced by a foreign agent, if the network involved is a mobile IP network.
• Figure 15 illustrates the latter network environment using the example given in Figure 3a.
• the foreign agent is shown as a separate unit, although it can be incorporated in the access server.
• the local charging server of the access point is typically separate from the dedicated charging server of the user accessing the network through the said access point, while the said dedicated charging server could be connected to the Internet or the telephone network.
• the terminal need not send the actual charge but some other (charge-related) messages to the charging server, which the charging server can then use for generating the charging records by itself.
• the terminal can send so-called keep-alive messages for the duration of the service, after which the charging server may only generate one charging record, where the duration of the service is equal to the time that has elapsed from the last keep-alive message to the moment when the contract was accepted.
• some other network element or entity such as the access server or foreign agent assumes the role of the terminal as the generator of the charging record(s). Such an element or entity must enjoy the user's full confidence.
• Charging records can also be generated by the interface elements that provide access for the terminals to the network providing the services. For example, this type of situation may arise when a known General Packet Radio Service (GPRS) terminal has access to an IP network through a GPRS network via the network element between the said networks (which in this case is the Gateway GPRS Support Node).
• GPRS General Packet Radio Service
• the charging records are verifiable.
• the charging messages could include electronic cash. If electronic cash is used, no verification of the subscriber is carried out; instead, verification will be limited to checking the structural integrity of the charging messages and cashing in of the electronic payment received from the user, which will typically be carried out by means of a special server, such as a bank's server.
• the element linking the network providing the services and the access network could also consist of any suitable device that is capable of passing traffic selectively, such as a packet filter or a firewall.
• some other message sent for another purpose can also serve as the start message indicating the beginning of a new service session.
• 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 abort (6), -- end connection, no money inc.
• Types 0..6 are overloaded onto a CDRtypeA
• type 7 uses - a CDRtypeB
• CDR imeType :: 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)), yearjii 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. trigg. by an extern, client, appl. ⁇
• CDR_currencyType :: ENUMERATED ⁇ majorType ENUMERATED ⁇ bill(0), E_cash(1) ⁇ , currency ENUMERATED ⁇ FiM (0), USD(1), ... ⁇
• CDRjnoneyAmountType SEQUENCE ⁇ currency CDR_currencyType, value INTEGER(0..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), contractNr INTEGER (O..MAX_D_WORD), sequenceNr INTEGER (O..MAX_WORD), serviceld INTEGER (O..MAX_D_WORD), serviceType CDR_serviceTypeType, startTime CDR imeType, endTime CDR_timeType, clientld CDRjdentifierType, watchdogld CDRjdentifierType, serverld CDRjdentifierType, payMethod CDRj aymentMethodType, moneyAm CDRjnoneyAmountType, trafficData OCTET STRING (SIZE(8)) signature CDRjsignatureType
• CDRformatB SEQUENCE ⁇ type CDR_cdrType, length INTEGER (O..MAX_S_WORD), contractNr INTEGER (O..MAX_WORD), sequenceNr INTEGER (O..MAX_WORD), e_cash OCTET _STRING(SIZE(0..200))

Landscapes

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

Applications Claiming Priority (5)

Publications (1)

Family

ID=26160423

Family Applications (1)

Country Status (7)

Cited By (1)

Families Citing this family (30)

Family Cites Families (4)

• 1998
  • 1998-05-08 FI FI981031A patent/FI104668B/sv active
  • 1998-07-14 EP EP98935049A patent/EP1005737A2/en not_active Withdrawn
  • 1998-07-14 JP JP2000505712A patent/JP2001512926A/ja active Pending
  • 1998-07-14 CN CN98808149.0A patent/CN1267414A/zh active Pending
  • 1998-07-14 WO PCT/FI1998/000590 patent/WO1999007108A2/en not_active Application Discontinuation
  • 1998-07-14 AU AU84433/98A patent/AU741703B2/en not_active Ceased
• 2000
  • 2000-01-13 NO NO20000170A patent/NO20000170L/no unknown

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events