+

WO1999009733A1 - Ameliorations relatives a des systemes de telecommunications - Google Patents

Ameliorations relatives a des systemes de telecommunications Download PDF

Info

Publication number
WO1999009733A1
WO1999009733A1 PCT/SE1998/001370 SE9801370W WO9909733A1 WO 1999009733 A1 WO1999009733 A1 WO 1999009733A1 SE 9801370 W SE9801370 W SE 9801370W WO 9909733 A1 WO9909733 A1 WO 9909733A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
sdr
sdrs
price
telecommunications
Prior art date
Application number
PCT/SE1998/001370
Other languages
English (en)
Inventor
Lars-Erik Wedin
Magnus Johansson
Göran LINDQVIST
Original Assignee
Telia Ab (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telia Ab (Publ) filed Critical Telia Ab (Publ)
Priority to EEP200000084A priority Critical patent/EE200000084A/xx
Priority to EP98934084A priority patent/EP1013067A1/fr
Publication of WO1999009733A1 publication Critical patent/WO1999009733A1/fr
Priority to NO20000643A priority patent/NO20000643L/no

Links

Classifications

    • 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/44—Augmented, consolidated or itemized billing statement or bill presentation
    • 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
    • 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/41—Billing record details, i.e. parameters, identifiers, structure of call data record [CDR]
    • 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/49—Connection to several service providers
    • 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/67—Transmitting arrangements for sending billing related information
    • 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/68—Payment of value-added services
    • 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
    • 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/90—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP using Intelligent Networks [IN] or Advanced Intelligent Networks [AIN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/0104—Augmented, consolidated or itemised billing statement, e.g. additional billing information, bill presentation, layout, format, e-mail, fax, printout, itemised bill per service or per account, cumulative billing, consolidated billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/0152—General billing plans, rate plans, e.g. charge rates, numbering plans, rate centers, customer accounts
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/016—Billing using Intelligent Networks [IN] or Advanced Intelligent Networks [AIN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/0164—Billing record, e.g. Call Data Record [CDR], Toll Ticket[TT], Automatic Message Accounting [AMA], Call Line Identifier [CLI], details, i.e. parameters, identifiers, structure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/0168—On line or real-time flexible customization or negotiation according to wishes of subscriber
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/0196—Payment of value-added services, mainly when their charges are added on the telephone bill, e.g. payment of non-telecom services, e-commerce, on-line banking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/46—Connection to several service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/48—Sending information over a non-traffic network channel or another connection than the one actually used, e.g. signalling, D-channel, data and voice

Definitions

  • the present invention relates to billing systems for use with telecommunications systems, especially telecommunications systems adapted to provide infocom, telecommunications system incorporating such billing system, and methods of costing infocom usage in telecommunications systems and billing for such usage.
  • telecommunications systems employ billing chains based on national number plans and conventional base telephony, where charges are determined by the geographical distance over which a call is transmitted and the time for which a call is connected.
  • the ability to base telecommunications charges on usage of IN-based services is limited by the fact that substantial parts of the p ⁇ cmg information generated by these systems is stripped out. This occurs during the normalisation which takes place because the billing chain uses a call record with a fixed length and fixed structure Information that is service-related does not appear in the call record.
  • the fixed length format runs counter to the requirements for renewal and supplementation which is imposed, by modern information services, on the billing chain.
  • service based charging i? b?s° ⁇ 1 or. "fixc ⁇ ", or . ,c solution is provided.
  • existing billing systems are based on a collection system which gathers TT records from Ax stations and IN nodes with a periodicity of once per hour to once per day
  • the TT records are normalised to a call record with a fixed length which is base-priced.
  • the call records are delivered to the system wnich is to place them with the correct invoicing system This takes another day It is only after two days that the invoicing systems can start processing the information in the call records
  • billing information which reflects the customer's organisational structure so that he can be invoiced as required.
  • customer information should be fed in via a central system which 0 distributes information to the administrative systems and service producing elements used to produce the service It is important, however, that the customer himself should have the opportunity to interact with his own services, i e via the Internet Customer cata should, therefore, be handled by a central customer care system which j - provides a unified input of customer data to a single place in a telecommunication's production apparatus,
  • the billing system of the present invention creates the opportunity to generate new types of price list for the provision of telecommunications services This in turn makes it possible to develop entirely new services with entirely new service structures
  • the price plans used today can be superseded by price lists in the flexible billing concept of the present invention
  • the service provides information, on what the customer has done, to a SDR (Service Detail Record),
  • a billing system handler or SDR subscription service, receives a SDR and sends it to a service pricing scheduler;
  • the service pricing scheduler picks out a Service Usage Module, described later in this specification, in the SDR and, depending on the customer ID specified in the respective module, associates the mo ⁇ e with a price list to which the customer has agreed
  • the Service Pricing Module is coupled with the Service Usage Module and returned to the pricing scheduler;
  • the pricing scheduler associates all Service Usage Modules with their Service Pricing Modules and returns the priced SDR to the billing system handler;
  • the billing system handler sends priced SDRs to a SDR archive, or store, for intermediate storage until a post-processing system, e.g. an invoicing system, collects it.
  • a post-processing system e.g. an invoicing system
  • the pricing scheduler is service-unique. One pricing scheduler may price each individual SDR per se, whereas another may assemble a number of SDRs, for one session, before calculating the price. This entirely depends on the way in which the service produces SDRs and how the service is priced.
  • Some pricing schedulers may assemble, in themselves, a number of SDRs, before sending the information to the price list system.
  • a defined basic price list forms the basis of all price lists in the service. It specifies no prices, but represents a skeleton on the basis of which all other price lists are based.
  • Each marketing company has its own price lists. These are of the following types:
  • the base price list contains the basic underlying price list for the service within a specific market.
  • the base price list is independent of the customer and the time when the service is used.
  • the base price list may be the price list to which the vast bulk of customers are connected. There is only one base price list.
  • the customer group price list is a type of price list containing a special pricing for a specific customer group.
  • the number of customer group price lists depends on the customer groups defined. Customer grouping is a way of offering, the vast bulk of customers, customer-unique pricing without being overwhelmed by a mass of different price lists.
  • the customer-unique price list is a type of price list produced for a specific customer. This price list is thus the actual customer adaptation. It is available for important customers, or customers who, for some reason, cannot be linked to any customer group.
  • a complex p ⁇ ce list system assembles all SDRs relating to one session before it calculates a mass of prices.
  • the customer is involved in all pricing cases. This does not mean that a user is always involved, since services may act autonomously.
  • the costs c* one session can be shared by different customers.
  • the A- and B-sides have c ⁇ ' erent access forms.
  • A accesses a service and, via this service, communicates with "B”, e g calls from GSM to VCC, which, in a queuing system, makes an onward connection to the PSTN
  • A accesses a service, e.g. listens to his mobile answering system via the
  • the service communicates with "B", e g. provides an output from a Multifax service
  • the service performs a function not involving any communication, e g holds uncollected faxes for an extended storage period
  • the service communicates with another service, e g. VCC uses the tele answering service.
  • the present invention can readily cope with all these pricing cases, and is sufficiently flexible to cope with many other p ⁇ cing cases as well
  • a telecommunications billing system for use with a telecommunications system comp ⁇ sing:
  • said telecommunications system being adapted to provide infocom services to customers and said billing system being adapted to provide flexible pricing and billing for usage of infocom services
  • said billing system includes handler means for receiving SDRs generated by said service producing elements and transmitting said SDRs to a service pricing scheduler means in that said SDRs include Service Usage Modules, in that said service pricing scheduler means is adapted to associate a Service Usage Module with a p ⁇ ce list appropnate thereto, and in that pricing means are provided for calculating a price associated with a Service Usage Module and inserting said price in a Service
  • said pricing scheduler means may be adapted to return a priced SDR to said handler means
  • Said handler means may be adapted to transmit p ⁇ ced SDRs to a SDR archive means adapted to store said priced SDRs until they are transmitted to a post-processing system
  • a service use session may generate one, or more SDRs
  • Service Pricing Modules may be added to SDRs, only after an SDR has been priced
  • Each SDR may be a collection of tagged data items describing a service use session
  • An SDR's size and content may vary in accordance with an infocom service to which it relates
  • Tagged data items in an SDR may be encoded using the BER for ASN 1
  • a particular set of related tagged data items in an SDR may be grouped into one of the following four types of service module:
  • Service Header Module which contains tagged data items associated with a SDR as a whole
  • Network Service Module which contains tagged data items related to consumption of network capacity by a particular service use session
  • Service Usage Module which contains tagged data items relating to service usage
  • a Service Pricing Module which contains tagged data items relating to pricing of an infocom service.
  • An SDR may contain:
  • Service Usage Modules one, or more, Service Usage Modules.
  • An SDR may contain a session identifier and a sequence number to enable a post-processing system to recover a chronological order in which SDRs were produced during a service use case.
  • An SDR may contain at least the following tagged data items:
  • an SDR may contain one, or more of the following tagged data items:
  • Relationships between service modules within an SDR may be governed by data items referred to as NSM/SUM correlators and SUM/SPM correlators, and these data items may have unique values within an SDR.
  • Said billing system may include one, or more, price lists, and said pricing system may be adapted to implement price list definitions, identify price lists to which an SDR relates and thereby produce priced SDRs.
  • Said pricing scheduler means may include said pricing system and may be adapted to receive SDRs, analyse SDRs and identify price lists appropriate to an SDR 09733
  • Said pricing scheduler means may be service independent, and anything which is service, customer, or market unique, may be incorporated in price lists.
  • Each infocom service may have a unique pricing scheduler means associated therewith.
  • Said pricing scheduler means may be adapted to assemble a plurality of
  • Said pricing scheduler means may be adapted to price individual SDRs.
  • Customers may be handled, for pricing purposes, as individual customers, or as members of a customer group.
  • All price lists may be based on a basic price list.
  • Price lists may be of one of the following types:
  • Price lists may be either lists of prices, or algorithms/functions for calculating prices.
  • SDRs may be generated independently of any action performed by a customer.
  • Costs for a service use session may be shared between different customers. /09733
  • Said billing system may include fault handling means adapted to process faulty SDRs
  • Said billing system may be adapted to operate with infocom services having plural functions
  • Said information services network may be an IN having a data server
  • Means may be provided to label an SDR as erroneous, if a p ⁇ ce list relating to an SDR cannot be identified
  • a telecommunications system comprising an information services network containing a plurality of service producing elements, and a communication services network containing a plurality of service switching elements, a signalling network and a transport network, said telecommunications network being adapted to provide infocom services to customers, a method of pricing usage of infocom services in a flexible manner, characterised by the steps of
  • Priced SDRs may be returned to a handler means
  • Priced SDRs may be transmitted to a SDR archive means and stored therein until collecie oy a post processing system 9733
  • Said post processing system may be an invoicing system
  • a service use session may generate one. or more SDRs
  • Service Pricing Modules may be added to SDRs, only after an SDR has been priced.
  • Each SDR may be a collection of tagged data items describing a service use session.
  • An SDR's size and content may vary in accordance with an infocom service to which it relates.
  • Tagged data items in an SDR may be encoded according to the BER for ASN.1.
  • Related tagged data items in an SDR may be grouped into service modules.
  • a particular set of related tagged data items in an SDR may be grouped into one of the following four types of service module:
  • Service Header Module which contains tagged data items associated with SDR as a whole
  • Network Service Module which contains tagged data items related to consumption of network capacity by a particular service use session
  • Service Usage Module which contains tagged data items relating to service usage
  • An SDR may contain:
  • Service Usage Modules one, or more, Service Usage Modules.
  • An SDR may contain a session identifier and a sequence number to enable a post-processing systems to recover a chronological order in which SDRs were produced during a service usage case.
  • An SDR may contain at least the following tagged data items:
  • an SDR may contain one, or more, of the following tagged data items
  • An SDR may include data items referred to as NSM/SUM correlators and SUM/SPM correlators which govern relationships between service modules in the SDR, and the values of these data items may be unique within an SDR.
  • Said billing system may include one, or more, price lists, and said billing system may be adapted to implement price list definitions, identify price lists to which an SDR relates and thereby produce priced SDRs.
  • a pricing scheduler means may be adapted to receive SDRs, analyse SDRs and identify price lists appropriate to an SDR.
  • a plurality of SDRs may be assembled before pricing.
  • All price lists may be based on a basic price list.
  • Price lists may be one of the following types:
  • Price lists may be either lists of prices, or algorithms/functions for calculating prices.
  • a telecommunications system characterised in that said telecommunications system includes a billing system, as described in any preceding paragraph, or in that said telecommunicatio ⁇ s system is adapted to price telecommunications sen/ice and network usage using a method as described in any preceding.
  • Said post-processing system may be an invoice system.
  • SDRs may be moved from service producing element, to pricing scheduler means, to an invoicing system.
  • SDRs may be used for any of the following functions:
  • Post-processing systems requiring access to information contained in SDRs, may subscribe to said handler means.
  • Said system may have a single invoice printing function.
  • Said pricing scheduler means may handle pricing of traffic rates and service events, and pricing related to periodical charges, subscription charges and discounts may be handled by post processing systems.
  • Each post-processing system subscribes to SDRs from one, or more infocom services, and/or to selected data items from within an SDR. /09733
  • Post-processing systems may collect SDRs, at predetermined intervals from a SDR archive, and/or post-processing systems may be alerted when SDRs are available for collection in a SDR archive
  • At least some infocom service producing elements may issue SDRs as a request for pricing information, which SDRs are passed to pricing scheduler means, priced and returned to said service producing elements.
  • SDRs without a subscribing post-processing entity may be discarded while SDRs having a subscribing post-processing entity may be retained for a pe ⁇ od of time in a SDR archive.
  • Figure 1 illustrates, in schematic form, an overview of a flexible billing system according to the present invention.
  • Figure 2 illustrates, in schematic form, the architecture of a flexible billing system, according to the present invention.
  • Figure 3 illustrates, in schematic form, tpp development cf ⁇ - ⁇ rvice employing the flexible billing system of the present invention.
  • Figure 4 illustrates the relationship between price lists in the present invention.
  • Figure 5 illustrates the basic structure of tagged data items.
  • Figure 6 illustrates the service module structure of an SDR
  • Figure 7 illustrates the structure within tre service usage module of Figure 6
  • Figure 8 illustrates the structure within the service module of Figure 6.
  • Figure 9 illustrates the relationship between service modules in an SDR.
  • Figure 10 illustrates that a service use session may include events within a single service, or within several services co-operating in sequence, or parallel.
  • Figure 11 illustrates how the number of SDRs produced by a service use session depends on the type of service, or co-operating services.
  • Figure 12 illustrates how a service usage module may contain one, or several related service events.
  • FIG. 13 illustrates why certain information must be communicated between SPEs.
  • Figure 14 illustrates, in schematic form, a service pricing system
  • Figure 15 illustrates in schematic form the way in which a subscription service offers SDR information as a common resource to the post- processing systems.
  • Figure 16 illustrates the billing chain within, and outside, a telecommunications operators organisation.
  • Figure 17 illustrate the way in which consolidated billing permits a full range of services to be billed together on a single bill.
  • Figure 18 illustrates the ways in which SDR information may be accessed in a variety of forms
  • Figure 19 illustrates the use of SDRs, and the information contained therein, for calculating the cost of service provision, signalling and communication.
  • the core functions of the flexible billing system of the present invention are:
  • the billing chain of the present invention realises a process, comprising several stages.
  • the present invention solves, inter alia, the problems associated with pricing and debiting. However, more is required of a billing system - SDRs must be collected, and invoices must be produced.
  • the flexible billing system of the present invention incorporates a number of useful functions, e g pricing scheduler and SDR fault handler This is illustrated in Figure 1
  • a register of service usage Within the overall service production module, there is located a register of service usage, a module for compiling pricing information and a module for creating SDRs These units feed out data to the billing system, as shown in Figure 1
  • data may be fed out from the register of service usage to a module for defining price lists located in a service development element Data from the module which compiles pricing information is fed to a module which identifies price lists, again located in the service development element Data is also fed from the service development element to the billing system, as shown in Figure 1, which contains units for p ⁇ cing service usage, analysing pricing information and collecting SDRs
  • the service and p ⁇ cing scheduler are interlinked through the price list and SDRs
  • the price list defines what is to be priced and what it costs
  • the SDR refers to what can be priced in each individual case
  • an SDR informs the pricing scheduler what can be priced for service usage
  • the price list gives the pricing scheduler the data it needs about the service so that it can correctly price an SDR
  • the system architecture used to implement the billing system is shown in Figure 2
  • the IN-service is supplied to a client, possibly via a data server 1
  • the client is linked, directly or indirectly with the billing system which contains a pricing scheduler and p ⁇ ce list systems as shown
  • the billing system sends priced SDRs on to other sub-systems in the telecommunications system, such as the subsystems labelled MPS FAKT and CAMS via a data server 2
  • three fundamental process are implemented by the system, namely price list definition;
  • SDRs are moved from within a service production sub-system, i.e. a service producing element of the network, through the pricing scheduler in the billing system, to the invoicing train.
  • the SDR has an information field which satisfies needs throughout the chain.
  • Operation of the billing system is not affected by the way in which SDRs enter the database. Neither is it affected by where and how SDRs are created. The only requirement is that SDRs end up in the database. The client collects all
  • SDRs to be priced. This is important, since there are SDRs which do not contain pricing information.
  • the responsibility for the billing system starts with the client.
  • the SDR comprises the interface between service and pricing scheduler.
  • the pricing scheduler receives and analyses each individual SDR. The analysis results in a defined price list, if everything operates correctly.
  • the price list system reads the SDR and Dicks out the correct price, r r prices. Some manipulation may be needed to come up with the correct price for a given customer.
  • an SDR When an SDR has been priced, it is sent to the MPS. It may be sent alone, or, together with other SDRs, in one file.
  • the MPS only needs to collect the SDRs with FTP. It is necessary to store the SDRs until the MPS has collected them.
  • a service will have a number of functions, which can be individually priced, using the billing system of the present invention.
  • the precise charging regime is determined by the service.
  • the billing system of the present invention does not impose any limitations on the charging possibilities.
  • the price list defines what can be priced in the service. If something is to be to be priced, an SDR must also be generated.
  • the SDR defines the basis for pricing. If an SDR is to be generated, the content must be defined.
  • the price list for the individual customer is defined.
  • Unique customer agreements may entail unique price lists.
  • Individual customer-service provider contracts may mean that a customer has his own pricing
  • the pricing scheduler is a universal function within the billing system, i e it is completely tra n sparent to the service Everything that is service-unique, customer-unique c market-unique must be included in the price list. 9733
  • New price lists can be entered during system operation. This covers both newly created services as well as supplemented existing services and modified price lists. The pricing scheduler must be able to find the correct price list despite changes during operation.
  • a price list should be changed at predetermined times.
  • the old price list can be written over.
  • a price list must have a validity schedule.
  • An SDR contains information which identifies the correct price list.
  • an SDR may contain:
  • a general p ⁇ ce list i e. one that is market-matched, or customised, is identified by the parameters
  • the pricing process is illustrated in Figure 4.
  • the SDR contains tags for the number of services used during a session.
  • the price lists may largely consist of a conventional list with prices running up and down, or it may have functions for analysis and calculation to enable the correct price to be arrived at.
  • the price list system sets the price, and the pricing scheduler is thereby satisfied. In conjunction with pricing, the price list system marks the SDR as priced.
  • Priced SDRs must be marked as already priced. It may happen that an SDR cannot be priced. The SDR must be appropriately marked as follows:
  • the SDR consists of a general part and a number of tags.
  • the general part identifies the customer, and the tags report on services and access forms.
  • An SDR must have space for information needed for:
  • marking priced SDRs (signing i e the price list which has set the price), and
  • SDR contains a substantial amount of information, which is needed to identify the correct p ⁇ ce list. SDRs are loaded with customer information and contain all the data needed.
  • the traditional telephony network can be regarded as being divided r.to an Information Services Network containing interacting Service Producing Elements and a Communication Services Network containing Service Switching ⁇ 'ements
  • the latter consist of a signalling network and a transport network
  • the signalling network carries commands to the Service Switching Eleme-ts for example, to establish a connection between two 33
  • This network then conveys the information that is to be exchanged between these two locations such as voice, text, picture, or data
  • infocom services Services created by this combination of information and communication are called infocom services
  • the Communication Services Network issues call detail records providing information about the geographical distance between the two locations being connected and for how long this connection has lasted This information is not sufficient for infocom service providers, hence, the Information Services Network issues service detail records (SDR)
  • SDR service detail records
  • the purpose of the SDR is to provide the information necessary to properly bill the usage and production of infocom services
  • the SDR may also provide information to support service management, quality assurance activities and production of statistics and reports about the service usage
  • a user i e an individual, may take part in the generation of an SDR
  • An SDR may be created as a consequence of
  • the present invention is primarily 733
  • a Service Detail Record is a collection of tagged data items describing an infocom service use session
  • the basic structure of a tagged data item is illustrated in Figure 5
  • the size and contents of the SDR may vary according to the infocom services used and the way in which it has been used it must be possible to append new data items to the SDR as, and when, new infocom services having different requirements emerge To accomplish this, the SDR data structure must be flexible and expandable, hence the concept of using tagged data items
  • tagged data items have three basic components a tag identifier, a length indicator and the actual data value
  • the tag identifier desc ⁇ Des how the associated data value is to be interpreted
  • the length indicator gives tne length of the data value, in terms of a number of octets, without the length of the tag identifier and the length indicator itself For example, if the tag identifier says 'p ⁇ ce to pay' the associated data value will be interpreted as a sum of money Because the data value may contain other tagged data items nested structures are created, somewhat like a set of Chinese boxes
  • Tagged data items are positioned in sequence, one after another, with no spaces inserted between them and no spaces reserved for unused fields
  • a tagged data item is recognized by the tag identifier value associated with it and may appear in any output from a Service Producing Element, hence additional tagged data items may be appended to it, e g by the Service Pricing System
  • Tagged data items are encoded according to the Basic Encoding Rules
  • An infocom ser ce provider may take responsibility for assigning tag identifiers to the various data items in the SDR 733
  • the Service Header Module contains data items associated with the SDR as a whole There is always one such module in the SDR
  • the Network Service Module contains data items associated with the service's consumption of network capacity There may be one, or several, network service modules in the SDR Within the module, information about several network hops may be recorded
  • the Service Usage Module contains data items associated with the usage of an infocom service
  • the structure of a service usage module is shown in Figure 7 There may be one, or several, such modules in the SDR It contains data items that are present in all service usage modules and data items specific to a particular service
  • the Service P ⁇ cing Module contains data items associated with the pricing of an infocom service There may be one, or several, such modules in the SDR
  • the structure of a service module is shown in mor p n m ⁇ > F-g rc 8
  • Each service module has its own set of module specific tags, i e tags unique wrthm the context of that service module
  • the data items Service Module Identifier and Revision State are mandatory in all service modules When these data items are combined with the module specific tags, the data items within that service module become globally unique, i e unique even outside the context of that service module.
  • a third data item, the Service Feature Code is required
  • An ASN 1 -encoder/decoder may be implemented as a state machine executing the BER and having access to look-up tables containing tag identifier values for different service modules The decoding of an SDR begins with the state machine obtaining the Service Module Identifier and Revision State Having 733
  • the SDR contains, when output from a Service Producing Element, a service header module (SHM), one, or several, network service modules (NSM), and one, or several, service usage modules (SUM), When the Service Pricing System has produced the price information, the SDR also contains a service pricing module,
  • SHM service header module
  • NSM network service modules
  • SUM service usage modules
  • SPM related to each service usage module, SUM.
  • a service pricing module is always related to a service usage module.
  • One, or several SUM/SPM-pairs may be related to a network service module forming an NSM/SUM/SPM-triplet. Deciding the service module structure is part of designing an infocom service.
  • the relationship between the service modules within an SDR is governed by two optional data elements, the NSM/SUM-Correlator and the SUM/SPM- Correlator No correlators are needed if the SDR contains only one service module of each type If it contain several n p fwork cory-ce modules, an NSiV ⁇ /SUfvi- Correlator must be shared between the network service module and the-one, or several, related service usage modules Network service module-wise, there is a one-to-one, or one-to-many, relationship between these types of modules
  • a service pn ⁇ g module and a service usage module share a SUM/SPM- Correlator There is a one-to-one relationship between these types of modules.
  • the series of values of the two correlator types must be unique within the SDR
  • the usage c ' an infocom service is called a service use session It begins at a given date arc time has a limited duration and eventually ends at another date, sometimes, aid time, always Dur.rg a service use session, one, or a number, of service events take place
  • Seve'al infocom services may co-operate, either in sequence, or parallel, in time, to provide a more refined service
  • a service use session may contain events from several infocom services, see Figure 10
  • a service use session may generate a single SDR - containing all service events within a single service, or within several cooperating services It may also result in several related SDR's, each containing events within a single service, or an SDR for each service event, see Figure 11
  • the Virtual Call Centre service produces one SDR containing all events, one, or several, in a service use session, whilst the Broad Band service generates one SDR for each event taking place
  • a service use session results in one, or several, SDR's is irrelevant to the Service P ⁇ cing System which handles each SDR as an individual entity
  • the SDR contain two optional data elements, a Session Identifier and a Sequence Number to enable a post-processing system to recover the chronological order in which several related SDR's were produced during a service use session
  • a service usage module Such a module is specific to an infocom service and may contain a single service event, or a chronological sequence of related service events see Figure 12
  • the Service Pricing System appends the data items Basic Price and Individual P ⁇ ce to the service pricing module These data items may contain the p ⁇ ce for an individual service event, or the total amount for all service events in the related service usage module
  • Customer data for an individual customer, may be allocated to his home location SPE Tne service logic of an infocom services may execute on a dedicated SPE or be cistriDuted amongst several cooperating SPE's
  • Infocom services may be offered by several marketing companies with differences in pricing, terms of payment, billing, etc Hence, it must be possible to p ⁇ ce the provisioning and usage of infocom services according to price tables unique to each marketing company It must also be possible to give the service providers and users individual rates, either in terms of absolute rates, or a basic rate, with varying discounts and bonuses applied later on
  • the service pricing system is illustrated in Figure 14, which shows the interaction between the pricing scheduler, customer control data, service specific pricing logic and market/customer specific price tables in the production of p ⁇ ced SDRs, indicated by SSDR in Figure 14, from unpriced SDRs
  • Some services require rate, or p ⁇ ce, information on demand, more, or less, in real time, in different languages and in different currencies before, du ⁇ ng and immediately after tne service has been used It must be possible for the service provider to change the rates and prices of an infocom service instantaneously This applies regardless of who is nrnvidmg tho ⁇ eP / . C * 0 vvhcm, the provider ay be a telecommunications network operator, or a customer , of the telecommunications network operator
  • the Service P ⁇ cing System handles the pricing of traffic rates and service events Pe ⁇ odical charges, such as subscription charges, various discounts and bonuses must be calculated by the post-processing systems
  • a Service P'oducing Element delivers SDRs to a Subscription Service with an intermediate storage capability, the SDR-Archive, see Figure 15 Due to the gross amount of ⁇ r-ormat ⁇ on being produced the SDRs are only retaine ⁇ m this archive for a mitec period of time
  • the post-processing systems may subscribe to SDRs from seve'al infocom services or selected data items within SDRs from - 33 - a particular infocom service, for example, only those data items associated with billing. SDRs having no subscribers are discarded immediately upon reception by the Subscription Service.
  • the SDRs are purged from the archive when all subscribers have collected the information to which they subscribe.
  • Some infocom services may issue an SDR as a request for price, or rate, information.
  • SDR is also sent to the Subscription Service and collected by the Service Pricing System.
  • Price, or rate has been calculated and appended to the SDR it is returned to the Subscription Service and eventually fetched by the Service Producing Element that issued the request.
  • the information in the SDR-Archive is a common resource available to the post-processing systems.
  • the information is provided through the Subscription Service and may be used for different purposes. Some examples are set out below.
  • the information in the SDR may be utilized to produce accounting information and enable a service producing company to verify invoices from domestic, as well as foreign, network providers. This information may be distributed amongst the various infocom services to keep track on the amount of network capacity an infocom service has consumed. It may be broken down further to show the network capacity a single service use session has consumed.
  • Figure 16 illustrates the distribution of revenues, in a billing chain, both inside, and outside, a telecommunications organisation. 733
  • a service producing company may calculate the production cost to be printed on the invoice to marketing companies for providing them with infocom services
  • the production cost is the sum of the network cost and the service producing company's refinement cost and profit margin, which may vary from one marketing company to another. In the same way the service producing company may bill customers to the marketing companies simply by adding marketing expenses and profit margins to the service production cost.
  • a customer may be either a user, or a provider, of infocom services.
  • the service provider may be paid by cheque via the postal system, or by electronic money transfer.
  • Consolidated billing may reduce billing costs when multiple services are offered. It allows a full range of services to be billed together on a single bill. Bills cost money to produce in terms of hardware, software, paper and postage Each bill will, hopefully, result in a payment which needs processing and it may generate customer enquiries - yet more cost.
  • Cost - supermarkets are perceived to be less expensive than sma.'er specialised stores 9733
  • Figure 17 illustrates the operation of a consolidated billing system and, in particular, the way in which consolidated billing permits a full range of services to be billed on a single bill Infocom services may have their own dedicated billing systems subscribing to data elements containing information, such as price, currency and VAT, about that service. This speeds up the introduction of new services, or additions of new features, because only that particular service's billing system needs to be modified. The rest of the service production environment stays intact.
  • account service information is transferred to the invoice p ⁇ ntmg machine common to all services.
  • This machine applies volume discounts and bonuses comp ⁇ smg the full range of services a customer subscribes to and prints a single bill/invoice.
  • Figure 18 shows the way in which information contained in SDRs may be used for the production and delivery of management reports and statistics It may be used to gam knowledge of how the service production environment ⁇ functioning, ho ⁇ ' th° infocom r.crvicc-s are used, wii i revenues they generate and customer behaviour. It may, of course, . also be offered to customers in the form of reports.
  • the information in SDRs may be used to produce service specific revenue reports, sales reports, marketing reports and customer behaviour reports to the service provider, the marketing companies and their customers.
  • the product manager can switch on his, or her, personal computer on arrival at the office in the morning and get fresn information about the revenues his, or her, product has generated up to the previous day This information may be analysed and trigger development of new services, service features, or refinement of existing services
  • Orde ⁇ ng may be carried out by electronic mail, facsimile, phone, Internet, or snail mail, either as a one time delivery, or as a subscription
  • the information content may be tailored in a variety of ways to suit a particular customer's needs, e g by type of information, the infocom service to which it relates, customer, company, and/or the time interval in which it was, or will be, produced
  • Delivery may be earned out by e-mail, facsimile, phone, Internet, electronic data interchange (EDI), or snail mail, containing CD-ROM, or paper
  • EDI electronic data interchange
  • the information delivered may be in a final state, or prepared for further refinement by the customer In the latter case, the information may be contained in a Microsoft
  • SDRs may be generated for quality assurance purposes For example, prior to marketing a new service feature it is important to verify that it has been correctly p ⁇ ced and that the invoice looks all ⁇ ght However, it is equally important not to put this invoice in an envelope and mail it
  • SDR's may be generated for service management purposes, for example, to obtain an early indication of suspected fraud attempts, churning, abnormal traffic loads, failure rates, or technical errors
  • the invoices from the network providers may cover the total amount of network capacity consumed by various infocom services
  • the SDR must provide sufficient information to enable the service provider to calculate the amount of capacity a specific infocom service has consumed
  • SDRs and data items included therein will now be described It will be noted that some data items are mandatory while others are optional SDRs, as has already been exDlained ar p generated a s 2 ccrccqLcr.cc of a user interacting with an infocom service
  • the mam purpose of the SDR is to bill the user for the usage SDRs generated as a consequence of service management, quality assurance activities, or other activities are not desc ⁇ bed herein
  • Service Module Identifier - Identifies the service header module [MANDATOR ⁇ Revision State - The version of the ASN 1 data type defining the service header module. A module in a given version must not be altered. [MANDATORY].
  • SDR Type - Identifies the type of SDR. The specific values are:
  • Session Identifier May be used to identify several SDRs associated with a session If SDRs within a session are produced by different Service Producing Elements, the Session Identifier must be communicated between the Service Producing Elements so it has the same value in all SDRs. [OPTIONAL]
  • Sequence Number May be used to indicate the sequence, within a session, in which several related SDRs have been produced
  • the Sequence Number may be useful when a service use session results in several SDRs being output, or if a service use session extends over a long time pe ⁇ od as is the case with leased lines If SDRs, within a session, are produced by different Service Producing Elements, the Sequence Number must be communicated between the Service Producing Elements so it forms an unbroken sequence [OPTIONAL]
  • SDR Identifier - Uniquely identifies an SDR that has been produced by a particular Service Producing Element. This identifier may be used to distinguish between duplicates.
  • the SDR Identifier may be represented as a 32 bit integer, incremented once for each SDR being produced. This gives a sequence of 4,294,967,295 unique identifiers before the sequence is repeated. [MANDATORY]
  • Time Of Origin Specifies the time of day when the SDR was produced.
  • the Responsibility Trace May be used by a system taking part in service production to indicate that it has taken responsibility for the SDR, hence it may contain a sequence of system identifiers and time stamps
  • the Responsibility Trace may be used as follows - when a Service Producing Element delivers the SDR tn the Serv'ce Dr 'c ⁇ ng System e d the latt r r.a . secured it, the Service Pricing System may indicate this by appending a responsibility tag and the Service Producing Element may purge the SDR from its storage [MANDATORY]
  • Action Indicator Indicates what kind of action the Service Pricing System is requested to perform. The specific values are:
  • the S3R shall be priced and forwarded to a post-processing syste--
  • the S3 is a request for price, or rate, information and shall be returned to the Service Producing Element, the SDR is for quality assurance and shall not be priced;
  • Data items in the Network Service Module are appended by the Services Producing Element. Data items, mandatory, or optional, may appear more than once within the module, as indicated. The following data items belong to this module.
  • NSM/SUM Correlator If the SDR contains more than one network service module, each module must have an identifier value that is unique within the SDR. This same value shall be present in all, one, or many, service usage modules associated with this network service module. [OPTIONAL]
  • the following set of data items may appear several times within the module. If they do, the whole set is repeated as an unbroken sequence.
  • Network Provider - Identifies the network provider having put his network to the services disposal.
  • Type Of Network The type of network having been used, for example, a signalling network, IP-network, or a voice channel. [MANDATORY]
  • Chargeable Duration - Specifies the time period for which a charge has to be calculated.
  • the following data items may be present in the static part of the TT- information produced by a telecommunications operator's VPN-service.
  • the following data items may be gathered from a CDR Message.
  • EOS Fault Code
  • Rate Period Identifier 1 Rate Period Identifier 2 -
  • a service usage module is specific to an infocom service in the sense that it contains data items present in all service usage modules and data items related to a particular i ⁇ fcccm service.
  • User Identifier - Identifies the infocom service user
  • the user may be identical to the provider, as is the case when a service provider changes the rates, or updates information. If an SDR contains both a User Identifier and a Calling Number, or A-subsc ⁇ ber Number, the User Identifier overrides them all. [OPTIONAL]
  • Charged Participant - May be used to indicate that someone other than the User, Calling Number, or A-Subscriber Number, is to be charged
  • One example is an ordinary collect call.
  • Dialled Number The dialled number used for the call connection, i e dialled digits to the infocom service. [MANDATORY]
  • NSM/SUM Correlator If the SDR contains more than one network service module, each such module must have an identifier value that is unique within the SDR. This same value shall be present in this (and all other) service usage modules associated with the network service module
  • Dialled Number The Call Centre access number, i e the number dialled by the calling party to reach the service [MANDATORY]
  • Customer Control Code - values for this data item may be defined in a future version of the VCC service
  • Event Code The specific values are.
  • Time For Start Of Charging-1 - Specifies the time of day at which the calling party was put in a queue.
  • Chargeable Duration- 1 - Specifies the time period the calling party has spent queuing [OPTIONAL]
  • Time For Start Of Charg ⁇ ng-2 - Specifies the time of day at which the calling party reached a destination number.
  • Terminating Line Identity TLID
  • OPTIONAL Terminating Line Identity
  • Dialled Number The dialled number used for the call connection, i.e. dialled digits to the VPN service.
  • Event Trace Each time an event is executed in call handling, the specific value for that event is added. An event that is executed several times will appear several times with its value.
  • the specific values are:
  • Company Identifier - An identifier assigned to the subsc ⁇ bing company This is the Company Identifier of the calling party, except in the case of GVNS and Call Centre Access, when it is the Company Identifier of the called party [OPTIONAL]
  • Telia VPN service tre data item Authorisation Code contains the A-number to be charged l e the rc-e number of the calling party (The calling party enters his public phone ⁇ ur-ee- as authorisation code )
  • the data item Public Number A- subscriber contains the A-number to be used for price calculation, i.e the number of the phone outside the VPN that has been used to make the remote access call
  • Data items specific to the Signalled Asynchronous Transfer Mode Service Usage Module are appended by the Services Producing Element.
  • Data items. mandatory, or optional, may appear several times within the module, as indicated
  • Terminating Number - (format: E164 string). [MANDATORY]
  • Chargeable Duration - Specifies the time period for which charge has to be calculated.
  • Session Identifier - May be used by the Service Pricing System and a post- processing system to recognize several events taking place du ⁇ ng a session. [MANDATORY]
  • Type Of Event - Identifies the type having caused the output of this SDR, e.g. log in, log off, or change of home page on the web [MANDATORY]
  • Event Parameters - A set of parameters associated with the event e g http protocol, video conference, address of home page, type of information, or TCP /
  • Session Identifier may be used to associate events to a particular session This is contrary to the VCC service where associated events are output
  • SUM/SPM Correlator If the SDR contains more than one service usage module, each such module must have an identifier value that is unique within the SDR. This same value shall be present in the network service module associated with the service usage module. [OPTIONAL]
  • Service Pricing Identifier - Identifies the Service Pricing System which calculated the price for the associated service usage module, or provided the requested price, or rate information.
  • a service usage module may contain several events.
  • the price for each event may either be added up to a total amount, or presented as individual amounts. If the latter is the case, the following data items shall be repeated as an unbroken sequence within the module. The order within that sequence shall correspond to the sequence of events in the associated service usage module as indicated by the SUM/SPM Correlator.
  • Price Type - Indicates if the Price Information has been calculated on a per call basis, per function, per time-slice, or a combination of these [MANDATORY]
  • Bill Information Indicates to a post-processing system what to print on the bill. What is actually printed may depend on the service, the provider and the user.
  • Status Indicator Indicates if the SDR has been p ⁇ ced, or the reason why it cannot be priced. The specific values are:
  • ASN.1 Abstract Syntax Notation One - is a syntax specifying how data types and their associated values shall be represented. Any other modern common programming language may serve the same purpose, e.g. Ada, or C. ASN.1 was developed in the early eighties and is nowadays defined in the CCITT recommendation X.208 and the ISO-standard 8824 as belonging to the presentation layer of the
  • BER Basic Encoding Rules are a set of rules specifying how the ASN 1 data types and their associated values shall be encoded to a transfer syntax i e a se ⁇ u n ⁇ of oct ⁇ ?tr
  • transfer code The binary representation of these sequences of octets is called transfer code and is independent of the programming language and operational system being used.
  • the transfer code is used when the data types and their associated values are being exchanged between open systems, i.e systems conforming to the OSI-model BER is defined in the CCITT-recommendation X.209 and the ISO-standard 8825
  • CAMS Customer Account Management System - in the present invention CAVS produces invoices for transmission to customers
  • CAMS creates pe ⁇ odic invoices for monthly, or quarteriy delivery, periodic charges may be priced in CAMS which can also produce one-time 33
  • CDR Call Detail Record is a data structure describing how a connectivity network has been used, e g. in terms of connection time and the geographical distance between the points of connection This information however, is not sufficient to bill infocom services
  • CSN Connectivity Services Network -
  • the CSN provides three kinds of services:
  • a signalling service e.g. to connect users of infocom services
  • a transport service to convey voice, text, picture and data between users of infocom services
  • this service may include other forms of outputs from intelligent peripherals
  • FAKT a known and existing invoice system used in the billing chain for creating basic invoice data on priced posts
  • Infocom services are produced in the Information Services Network consisting mainly of service data points (SDP), service control points (SCP) and intelligent peripherals (IP)
  • SDP service data points
  • SCP service control points
  • IP intelligent peripherals
  • the connectivity network provides the infra structure to the services
  • ISN Information Services Network makes use of the Connectivity Services Network to provide infocom services 9733
  • MPS When a customers makes a telephone call over the fixed network, one, or several, callposts, e.g. TT-posts are created. Files with TT- posts are gathered together by an IS-TT system. The callposts are then sent to MPS for validation.
  • callposts e.g. TT-posts are created.
  • Files with TT- posts are gathered together by an IS-TT system.
  • the callposts are then sent to MPS for validation.
  • NSM Network Service Module
  • SDR Service Detail Record - SDR is a data structure describing how an infocom service has been used. Such a use case may involve only one service, or a sequence of cooperating services ASN.1 and BER are applied to specify and encode/decode this data structure
  • the information may be retrieved by post-processing systems, e.g. to produce bills, statistics and reports
  • the information resides fo r di ff e r ent periede off time on different types of storage media with varying capacity and access times.
  • Pricing information may be present in the SDR when it enters the SDR- Archive, or applied later on, by the post-processing Systems
  • SPE Service Producing Element - A SPE is part of the Information
  • the SPE may issue an SDR each time a sen ce event takes place, or wait until a service use session has been completed.
  • infocom service 733 The behaviour depends on the particular infocom service 733
  • SPS Service Pricing System.
  • the SPS provides rating and pricing information, on demand and in real-time, to infocom services. It also performs pricing of SDR's when output from the Service Producing Element.
  • the Service Pricing System contains price and rate tables for various infocom services, marketing companies and customers. It also has the logic necessary to calculate the correct price for a service use session consisting of one, or many, cooperating services, provided by any marketing company to any customer; this includes applying the appropriate currency, VAT, together with various discounts and bonuses.
  • TC Transfer Code is the binary value of the octet string produced when BER is applied to an ASN.1 data type. Transfer syntax is another name for transfer code.
  • VCC Virtual Call Centre
  • VPN Virtual Private Network
  • a customer may be the user and/or the provider of an infocom service.
  • Price An amount of money independent of time. The price is calculated as the product of a given rate and the chargeable time duration.
  • Rate An amount of money as a function of time.
  • SDR An ASN.1 data type describing a specific service use session.
  • Service Usage A service use session triggered by a human being, or an infocom service.
  • Service Usage Module An ASN.1 data type describing one, or several, service events.
  • Service use session May consist of one, or several, service events taking place within a single infocom service, or several interacting infocom services.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Meter Arrangements (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un système de facturation permettant de générer de nouveaux types de listes de prix pour la fourniture de services de télécommunications et de développer des services entièrement nouveaux aux structures entièrement nouvelles. Le système comprend un moyen destiné à recevoir un descriptif détaillé de service (SDR) - Service Detail Record -, à envoyer ce SDR à un ordonnanceur de tarification de service dans lequel le module d'utilisation du service contenu dans le SDR est associé à une liste de prix pour laquelle le client a donné son accord. Le prix est renvoyé avec le module de tarification du service associé au module d'utilisation du service.
PCT/SE1998/001370 1997-08-14 1998-07-13 Ameliorations relatives a des systemes de telecommunications WO1999009733A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EEP200000084A EE200000084A (et) 1997-08-14 1998-07-13 Sidesüsteemide või nendega seotud täiustused
EP98934084A EP1013067A1 (fr) 1997-08-14 1998-07-13 Ameliorations relatives a des systemes de telecommunications
NO20000643A NO20000643L (no) 1997-08-14 2000-02-09 Telekommunikasjonssystem

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE9702937-5 1997-08-14
SE9702937A SE512479C2 (sv) 1997-08-14 1997-08-14 Förbättringar hos, eller i samband med, telekommunikationssystem

Publications (1)

Publication Number Publication Date
WO1999009733A1 true WO1999009733A1 (fr) 1999-02-25

Family

ID=20407930

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE1998/001370 WO1999009733A1 (fr) 1997-08-14 1998-07-13 Ameliorations relatives a des systemes de telecommunications

Country Status (5)

Country Link
EP (1) EP1013067A1 (fr)
EE (1) EE200000084A (fr)
NO (1) NO20000643L (fr)
SE (1) SE512479C2 (fr)
WO (1) WO1999009733A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000007128A1 (fr) * 1998-07-29 2000-02-10 American Management Systems, Incorporated Systeme de facturation et de service client convergent et modulaire
WO2001043397A2 (fr) * 1999-12-13 2001-06-14 Sherkin Communications Systems Limited Communication de donnees
WO2002003336A2 (fr) * 2000-07-06 2002-01-10 Telefonaktiebolaget Lm Ericsson (Publ) Systeme et procede de verification automatique d'un systeme de facturation
DE10160957A1 (de) * 2001-12-12 2003-07-10 Viag Interkom Gmbh & Co Verfahren und Vorrichtung zur Änderung der Tarife von Telefondienstleistungen
WO2003077527A1 (fr) * 2002-03-08 2003-09-18 Telecom Italia S.P.A. Procede et systeme de decodage d'enregistrements de donnees de facturation dans des reseaux de telephonie mobile
WO2009076813A1 (fr) * 2007-12-13 2009-06-25 Huawei Technologies Co., Ltd. Procédé et dispositif permettant de décoder un enregistrement de facturation

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995024093A1 (fr) * 1994-03-02 1995-09-08 British Telecommunications Public Limited Company Procede de tarification d'un systeme de telecommunications
WO1996003000A1 (fr) * 1994-07-14 1996-02-01 British Telecommunications Public Limited Company Tarification souple d'appels telephoniques
WO1997005734A1 (fr) * 1995-07-27 1997-02-13 British Telecommunications Public Limited Company Facturation de communications
WO1997023084A1 (fr) * 1995-12-19 1997-06-26 Philips Electronics N.V. Dispositif de prestations de services dans un reseau de telecommunications, destine a fournir des services a valeur ajoutee

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995024093A1 (fr) * 1994-03-02 1995-09-08 British Telecommunications Public Limited Company Procede de tarification d'un systeme de telecommunications
WO1996003000A1 (fr) * 1994-07-14 1996-02-01 British Telecommunications Public Limited Company Tarification souple d'appels telephoniques
WO1997005734A1 (fr) * 1995-07-27 1997-02-13 British Telecommunications Public Limited Company Facturation de communications
WO1997023084A1 (fr) * 1995-12-19 1997-06-26 Philips Electronics N.V. Dispositif de prestations de services dans un reseau de telecommunications, destine a fournir des services a valeur ajoutee

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000007128A1 (fr) * 1998-07-29 2000-02-10 American Management Systems, Incorporated Systeme de facturation et de service client convergent et modulaire
WO2001043397A2 (fr) * 1999-12-13 2001-06-14 Sherkin Communications Systems Limited Communication de donnees
WO2001043397A3 (fr) * 1999-12-13 2002-01-03 Sherkin Comm Systems Ltd Communication de donnees
WO2002003336A2 (fr) * 2000-07-06 2002-01-10 Telefonaktiebolaget Lm Ericsson (Publ) Systeme et procede de verification automatique d'un systeme de facturation
WO2002003336A3 (fr) * 2000-07-06 2002-06-20 Ericsson Telefon Ab L M Systeme et procede de verification automatique d'un systeme de facturation
DE10160957A1 (de) * 2001-12-12 2003-07-10 Viag Interkom Gmbh & Co Verfahren und Vorrichtung zur Änderung der Tarife von Telefondienstleistungen
DE10160957B4 (de) * 2001-12-12 2006-12-21 Viag Interkom Gmbh & Co. Verfahren und Vorrichtung zur Änderung der Tarife von Telefondienstleistungen
WO2003077527A1 (fr) * 2002-03-08 2003-09-18 Telecom Italia S.P.A. Procede et systeme de decodage d'enregistrements de donnees de facturation dans des reseaux de telephonie mobile
US7451311B2 (en) 2002-03-08 2008-11-11 Telecom Italia S.P.A. Method and system for decoding charging data records in mobile telephone networks
WO2009076813A1 (fr) * 2007-12-13 2009-06-25 Huawei Technologies Co., Ltd. Procédé et dispositif permettant de décoder un enregistrement de facturation

Also Published As

Publication number Publication date
SE9702937D0 (sv) 1997-08-14
NO20000643L (no) 2000-04-12
NO20000643D0 (no) 2000-02-09
SE9702937L (sv) 1999-02-15
EE200000084A (et) 2000-10-16
SE512479C2 (sv) 2000-03-20
EP1013067A1 (fr) 2000-06-28

Similar Documents

Publication Publication Date Title
US5333184A (en) Call message recording for telephone systems
US6449588B1 (en) Customer-driven QOS in hybrid communication system
US6556659B1 (en) Service level management in a hybrid network architecture
US6704303B1 (en) IP/telephony user interface for a hybrid communication system
EP0491497B1 (fr) Méthode et appareil pour la facturation d'appels de communication valorisés
US6442547B1 (en) System, method and article of manufacture for information service management in a hybrid communication system
US6707812B1 (en) System, method and article of manufacture for element management in a hybrid communication system
US6542593B1 (en) Rules database server in a hybrid communication system architecture
CA2227914C (fr) Facturation de communications
US6426948B1 (en) Video conferencing fault management in a hybrid network
US6195697B1 (en) System, method and article of manufacture for providing a customer interface in a hybrid network
US6081518A (en) System, method and article of manufacture for cross-location registration in a communication system architecture
US5524142A (en) Method and apparatus for the billing of value-added communication calls
US6868147B2 (en) System and method for creating a billing record with a called party's name
USRE41488E1 (en) Methods and systems for using the public switched telephone network to conduct a transaction between customer accounts
FI106152B (fi) Menetelmä tietoverkosta ostettavien palvelujen ja tuotteiden laskuttamiseksi
WO2000074325A1 (fr) Systeme et procede de gestion proactive de l'efficacite dans un systeme de communication hybride
WO1999009733A1 (fr) Ameliorations relatives a des systemes de telecommunications
US20020126811A1 (en) Method for setting up and charging for a telecommunications link
WO2000070859A2 (fr) Envoi de messages de facturation dans un reseau telephonique
KR20010056753A (ko) 패킷망 및 프레임릴레이망의 요금구조에 따른 수익율시뮬레이션 방법
WO2000074337A2 (fr) Systeme, procede et article manufacture destines a un serveur de base de donnees de regles dans une architecture de systeme de communication hybride
Ryan et al. A Rating Bureau Service for Next Generation IP Services
Sridhar Intelligent Network (IN) Services
Apfelbeck A role based modelling approach for the information infrastructure

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): EE LT LV NO

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 1998934084

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1998934084

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1998934084

Country of ref document: EP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载