WO2009155990A1 - Advice of charge service - Google Patents

Advice of charge service Download PDF

Info

Publication number
WO2009155990A1
WO2009155990A1 PCT/EP2008/058285 EP2008058285W WO2009155990A1 WO 2009155990 A1 WO2009155990 A1 WO 2009155990A1 EP 2008058285 W EP2008058285 W EP 2008058285W WO 2009155990 A1 WO2009155990 A1 WO 2009155990A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
charging function
attribute value
application server
value pair
Prior art date
Application number
PCT/EP2008/058285
Other languages
French (fr)
Inventor
Martin Farthofer
Thomas Hickethier
Original Assignee
Nokia Siemens Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Siemens Networks Oy filed Critical Nokia Siemens Networks Oy
Priority to PCT/EP2008/058285 priority Critical patent/WO2009155990A1/en
Publication of WO2009155990A1 publication Critical patent/WO2009155990A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • 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/1414—Indication of costs in real-time
    • 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/57—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP for integrated multimedia messaging subsystem [IMS]
    • 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/65—Off-line charging system
    • 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/83—Notification 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/83—Notification aspects
    • H04M15/835—Time or frequency of notifications, e.g. Advice of Charge [AoC]
    • 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/83—Notification aspects
    • H04M15/835—Time or frequency of notifications, e.g. Advice of Charge [AoC]
    • H04M15/8351—Time or frequency of notifications, e.g. Advice of Charge [AoC] before establishing a communication
    • 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/83—Notification aspects
    • H04M15/84—Types of notifications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/20—Technology dependant metering
    • H04M2215/208—IMS, i.e. Integrated Multimedia messaging Subsystem
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/81—Notifying aspects, e.g. notifications or displays to the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/81—Notifying aspects, e.g. notifications or displays to the user
    • H04M2215/8104—Time or frequency of notification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/81—Notifying aspects, e.g. notifications or displays to the user
    • H04M2215/8104—Time or frequency of notification
    • H04M2215/8108—Time or frequency of notification before establishing a communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/81—Notifying aspects, e.g. notifications or displays to the user
    • H04M2215/8129—Type of notification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/81—Notifying aspects, e.g. notifications or displays to the user
    • H04M2215/815—Notification when a specific condition, service or event is met
    • H04M2215/8154—Determined tariff
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/82—Advice-of-Charge [AOC], i.e. notify subscriber of charges/cumulative charge; meter at the substation

Definitions

  • the invention relates to a method, a subscriber database, a control function, an application server, a charging function and a computer program product for providing an advice of charge service to offline charged users .
  • IP Internet Protocol
  • IMS Internet Protocol Multimedia Subsystem
  • 3GPP 3 rd Generation Partnership Project
  • SIP Session Initiation Protocol
  • IETF Internet Engineering Task Force
  • SIP is an application- layer control protocol for creating, modifying, and terminating sessions with one or more participants. These sessions may include Internet multimedia conferences, Internet telephone calls, and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.
  • An Advice of Charge (AoC) supplementary service used in communication systems announces the tariff/rate/cost of the requested service e.g. a phone call to the user, either the expected rate before connecting the call, during the call the cumulated costs, or after the call the total costs.
  • the AoC allows the user to terminate the service before costs emerge to the user. This service is required by many regulators for cost transparency reasons.
  • the AoC service is offered, for example as announcements for premium rate services "This call costs you 2 Euro a minute."
  • PSTN public switched telephone network
  • PLMN public land mobile network
  • VoIP voice over internet protocol
  • the AoC service is requested by many operators in tenders for both user comfort and to fulfill expected regulatory issues.
  • the object of the invention is to provide a solution for offering AoC in the IMS also for offline charged users .
  • the present invention overcomes the above problem by providing a method comprising storing charging function address in a subscriber database and providing charging function address to a first network element from the subscriber database. According to an aspect of the invention the method further comprises receiving a user specific request from the first network element. Examples of further refinements of the invention as defined under the above aspect are described in the dependent claims 2 to 20.
  • the invention further provides a method comprising receiving a request from an application server at a charging function and providing an answer to the application server from the charging function.
  • the method further comprises obtaining advice of charge related information from a billing domain.
  • the invention further provides a subscriber database comprising storing means for storing charging function address, receiving means for receiving a request associated with a user and providing means for providing charging function address in response to the request. Examples of further refinements of the invention as defined under the above aspect are described in the dependent claims.
  • the invention further provides a control function comprising requesting means for requesting charging function address from a subscriber database and receiving means for receiving charging function address from the subscriber database.
  • the control function further comprises sending means for sending charging function address to an application server. Examples of further refinements of the invention as defined under the above aspect are described in the dependent claims 66 to 74.
  • the invention further provides an application server comprising receiving means for receiving charging function address.
  • the application server further comprises requesting means adopted to request charging function address from a subscriber database or from a control function. Examples of further refinements of the invention as defined under the above aspect are described in the dependent claims 76 to 93.
  • the invention further provides a charging function comprising receiving means for receiving a request for advice of charge related information from an application server, obtaining means for obtaining advice of charge related information from a billing domain and providing means for providing advice of charge related information to the application server.
  • the invention further provides a computer program product comprising code means adapted to produce the steps of any one of methods described above when loaded into the memory of a computer.
  • the present invention has the advantage that the AoC service can be provided to offline charged users of a communication network, for example offline charged users in IMS.
  • the present invention has a further advantage that the AoC service can be provided to offline charged users of a communication network without a need to contact online charging system. Therefore this invention provides a solution also in networks that do not have online charging system at all.
  • FIG 1 illustrates IMS AoC charging architecture as currently specified in 3GPP.
  • Figure 2 illustrates IMS AoC charging architecture according to embodiments of the invention
  • Figure 3 explains internal structures of the relevant network elements according to embodiments of the invention .
  • FIGS 4, 5 and 6 show methods according to embodiments of the invention.
  • Call Session Control Functions implement a session control function in SIP layer.
  • the CSCF can act as Proxy CSCF (P-CSCF), Serving CSCF (S-CSCF) or Interrogating CSCF (I-CSCF) .
  • P-CSCF Proxy CSCF
  • S-CSCF Serving CSCF
  • I-CSCF Interrogating CSCF
  • the P-CSCF is the first contact point for the User Equipment (UE) within the IMS; the S-CSCF actually handles the session states in the network; the I-CSCF is mainly the contact point within an operator's network for all IMS connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operator's service area.
  • the functions performed by the I-CSCF are, for example, assigning an S-CSCF to a user performing SIP registration and routing SIP requests received from another network towards the S-CSCF.
  • the S-CSCF performs the session control services for the UE. It maintains a session state as needed by the network operator for support of the services and may be acting as registrar, i.e. it accepts registration requests and makes its information available through the location server.
  • the S-CSCF is the central point to users that are hosted by this S-CSCF.
  • the S-CSCF provides services to registered and unregistered users when it is assigned to these users. This assignment is stored in the Home Subscriber Server (HSS) .
  • HSS Home Subscriber Server
  • the HSS is the master database for a given user. It is the entity containing the subscription-related information to support the network entities actually handling calls/sessions. As an example, the HSS provides support to the call control servers (CSCFs) in order to complete the routing/roaming procedures by solving authentication, authorisation, naming/addressing resolution, location dependencies, etc.
  • CSCFs call control servers
  • SIP-AS SIP application servers
  • the HSS is responsible for holding the following user related information:
  • Network access control information for authentication and authorisation such as password information
  • the HSS supports the user registration, and stores inter-system location information, etc.
  • Cx reference point or Cx interface is an interface between a CSCF and a HSS, supporting the transfer of data between them.
  • the Cx reference point is based on the diameter protocol with 3GPP standard diameter applications.
  • Sh interface is a corresponding interface between the HSS and an application server (AS) .
  • Diameter is an authentication, authorisation, and accounting (AAA) protocol defined by the IETF and used for network access services, such as dial-up and mobile IP.
  • An Application Server is offering value added IP multimedia (IM) services to users of the IMS network and resides either in the IMS user's home network or in a third party location.
  • the third party could be a network or simply a stand-alone AS.
  • the AS may host and execute various services and can influence and impact a SIP session on behalf of the services.
  • the IP multimedia Subsystem Service Control Interface (ISC) interface is between the S-CSCF and the service platforms (i.e. ASs).
  • the ISC interface offers extended services to subscribers.
  • ASs that are connected to the IMS are controlled via ISC interface.
  • the protocol used on the ISC interface is the SIP.
  • Examples of an AS include e.g. AoC AS or AoC function and IMS-gateway function (IMS-GWF) .
  • An HSS can communicate with an application server over Sh interface.
  • the Sh interface enables data handling procedures, for example, download of data from the HSS to an AS, or update of data in the HSS.
  • An AS can subscribe to receive notifications from the HSS of changes in data.
  • the HSS can notify an AS of changes in data for which the AS previously had subscribed.
  • Diameter protocol can be used in Sh interface .
  • next level server or function is not directly behind the ISC or reachable via SIP but reachable via another protocol from special functions or registered application servers, defined via initial filter criteria (iFC) a user profile.
  • next level functions are an online charging system (OCS) that is reachable via diameter credit control application CCA (Ro) from the IMS-GWF and a charging collection function (CCF) that is reachable via diameter accounting (Rf) from the internal charging data function .
  • OCS online charging system
  • Ro diameter credit control application CCA
  • CCF charging collection function
  • Charging is a function within the telecommunications network and the associated charging elements whereby information related to a chargeable event is collected, formatted, transferred and evaluated in order to make it possible to determine usage for which the charged party may be billed (offline charging) or the subscribers account balance may be debited (online charging) .
  • An online charging also known as credit-based charging, is used for prepaid services, or real-time credit control of postpaid services. It is a charging mechanism where charging information can affect, in real-time, the service rendered and therefore a direct interaction of the charging mechanism with session/service control is required.
  • Online charging is provided by an online charging system (OCS) .
  • OCS online charging system
  • Offline charging is applied to users who pay for their services periodically (e.g., at the end of the month).
  • An offline charging is a charging mechanism where charging information does not affect, in real-time, the service rendered.
  • a tariff is a set of parameters defining the network utilization charges for the use of a particular bearer, session and/or service.
  • Offline charging is provided by a billing domain (BD) .
  • BD billing domain
  • An Advice of Charge (AoC) supplementary service used in communication systems announces the tariff/rate/cost of the requested service e.g. a phone call to the user, either the expected rate before connecting the call, during the call the cumulated costs, or after the call the total costs.
  • the AoC allows the user to terminate the service before costs emerge to the user.
  • AOC-S Charging information at communication set-up time
  • the AOC-S service enables a user to receive information about the charging rates at communication set-up time and also to receive further information during the communication if there is a change of charging rates.
  • Charging information during the communication (AOC-D)
  • the AOC-D service enables a user to receive information on the recorded charges for a communication during the active phase of the communication .
  • Charging information at the end of the communication (AOC-E)
  • the AOC-E service enables a user to receive information on the recorded charges for a communication when the communication is terminated.
  • the IMS charging architecture as shown in Fig. 1 comprises a billing domain, a charging collection function (CCF) involved with offline charging including a charging gateway function (CGF) and a charging data function (CDF) , a used equipment UE, a Proxy call session control function (P-CSCF) , a serving call session control function (S-CSCF) , an IMS-GWF, online charging system (OCS) , an AoC function, and an interconnect border control function (IBCF) .
  • the architecture further comprises a home subscriber server (HSS) , which is not shown in the figure.
  • HSS home subscriber server
  • the HSS stores filter criteria, in particular initial filter criteria (iFC) set for the users or UEs assigned to the respective HSS.
  • the filter criteria determine the services that will be provided to each user.
  • the HSS is accessible by the S-CSCF via Cx interface and by an AS, such as AoC function, via Sh interface .
  • the figure 2. shows an IMS AoC charging architecture according to embodiments of the invention.
  • a charging function preferably an offline charging advice of charge function (OAF) is provided.
  • OAF is a new interface partner for the advice of charge function (ACF) for offline charged IMS users. It can be defined within the Billing system and accessible via a special SIP-AS, namely ACF.
  • the task of the OAF is to provide specific information, which can be used to build the AoC Information, e.g. tariff, cost or rate information.
  • the OAF may provide an interface to the user/subscriber database in the billing domain to determine which tariff the user has subscribed, but also to a rating function of the billing domain to determine the costs of the requested IMS service.
  • the OAF may process the received information and to reply to request of the ACF.
  • a charging function address preferably an OAF address
  • the charging function address can be stored in a subscriber database, such as an AAA server or a HSS, and the application server, such as AoC function or AoC AS, can retrieve the charging function address to request AoC Information.
  • the address can be retrieved by the application server directly from the subscriber database via Sh interface or by a control function, such as S-CSCF, via Cx interface and further sent to the application server.
  • the AAA server is a server that handles user requests for access to computer resources and provides authentication, authorisation, and accounting services.
  • the AAA server can interact with network access and gateway servers and with databases and directories that contain user information. Devices and applications typically communicate with an AAA server by using the remote authentication dial-in user service (RADIUS) .
  • RADIUS remote authentication dial-in user service
  • a method in which charging function address is stored in a subscriber server, such as HSS, and provided to a network element, such as a S-CSCF, or an application server, such as AoC AS or AoC function.
  • the charging function address may comprise an offline charging AoC function (OAF) address.
  • the OAF address may comprise a diameter uniform resource identifier (Diameter-URI) or diameter identifier (Diameter-Id).
  • the charging function address may be provided via Cx query together with the initial filter criteria (iFC) and user profile to the control function. Further, the charging function address may be provided via the Sh interface, if requested by a particular SIP-AS, like the AoC AS or AoC function.
  • P-charging-vector is a SIP private header which is used to share the charging correlation information among different IP multimedia subsystem (IMS) network elements and between the IMS and the access network.
  • P-charging-vector consists of the IMS charging identifier, inter-operator identifier, and access network charging information.
  • the charging function address can be provided from the control function to the application server in the P-Charging-Vector header .
  • the charging function address may be assigned to a subscriber within its HSS user profile.
  • the access to charging specific HSS subscriber data entries may be done using the Cx interface while subscriber registration in the control function, namely S-CSCF, but also by a SIP-AS using the Sh interface.
  • the Sh interface may be enhanced accordingly to be able to carry the OAF address.
  • the charging function address may be downloaded to the S-CSCF from the HSS via Cx query when the subscriber registers at the IMS.
  • a new AVP can be used.
  • the address can be sent within SIP signalling messages via ISC interface from the S-CSCF to an AS while 3 rd party registration and while SIP service execution (e.g. via SIPiINVITE or SIPIMESSAGE) .
  • the address may be sent within a charging related attribute value pair (AVP) to e.g. the SIP application servers that are involved into SIP service processing.
  • the address may be provided to an AS directly from the HSS via Sh interface.
  • a method in which AoC related information is provided in a communication system.
  • the advice of charge related information may comprise cost information, tariff information or rate information.
  • the AoC related information is requested by an application server, such as AoC AS or AoC function, and provided by a charging function, such as OAF, over diameter based interface.
  • the charging function may obtain the AoC related information from a billing domain.
  • the AoC related information may be requested in a credit control request (CCR) message as defined in IETF RFC 4006. Further, the AoC related information may be requested in a credit control event request (CCRe) message.
  • CCR credit control request
  • CCRe credit control event request
  • the AoC related information may be provided in a credit control answer (CCA) message as defined in IETF RFC 4006. Further, the AoC related information may be provided in a credit control event answer (CCAe) message.
  • CCA credit control answer
  • CCAe credit control event answer
  • the diameter credit control request and credit control answer messages are defined in IETF RFC 4006 as follows.
  • the requesting of the tariff-, rate and cost-information can be performed with the Credit Control Event Request (CCRe) message.
  • CCRe Credit Control Event Request
  • the CCRe may be filled out in the following way:
  • the CC-Request-Type AVP can be set to EVENT_REQUEST.
  • the Requested-Action AVP can be set to PRICE_ENQUIRY.
  • the Destination-Realm AVP and the Destination-Host AVP can be filled with the OAF address, as received from the HSS
  • the Service-Information AVP can be included according to the 3GPP TS 32.260 and TS 32.299 for providing information about an IMS service.
  • the OAF can provide this information to the rating function in the BD for determining the costs of the IMS service.
  • the OAF may provide to cost-, rate and tariff information to the ACF by using the CCAe message.
  • the CCRe message is described in the 3GPP TS 32.299.
  • the cost-, tariff- and rate information can be provided in the Cost-Information AVP that is defined in the IETF RFC 4006.
  • Cost-Information :: ⁇ AVP Header: 423 >
  • the ACF may use the received information for providing the AoC-information to the IMS user.
  • the CCRe can be filled in the following way:
  • the CC-Request-Type AVP can be set to EVENT_REQUEST.
  • the Requested-Action AVP can be set to TARIFF_ENQUIRY.
  • the Destination-Realm AVP and the Destination-Host AVP can be filled with the OAF address, as received from the HSS
  • the OAF may provide the tariff information from the user database in the billing domain if such a CCRe is received from the ACF.
  • a new AVP can be defined, as the following example, or an existing AVP can be enhanced, like the cost-information AVP.
  • Tariff-Information :: ⁇ AVP Header: xxx
  • the Current-Tariff AVP can be used to provide information about the current tariff, such as price per time, time unit, price information, currency information, price per event and event unit.
  • Next- Tariff-Switch AVP can be used to inform the ACF when the next tariff switch will happen.
  • Next-Tariff AVP can include the same set of information as the current-tariff AVP, such as price per time, time unit, price information, currency information, price per event and event unit, but includes the tariff information which shall be applied after the tariff switch .
  • the CCRe can be filled in the following way :
  • the CC-Request-Type AVP can be set to EVENT_REQUEST.
  • the Requested-Action AVP can be set to RATE_ENQUIRY.
  • the Destination-Realm AVP and the Destination-Host AVP can be filled with the OAF address, as received from the HSS
  • the OAF may provide the rate information from the billing domain if such a CCRe is received from the ACF.
  • a new AVP can be defined or an existing AVP can be enhanced, like the cost- information AVP.
  • the following trigger points can be used to contact the OAF:
  • Session release (when the SIP BYE is received) ; the information received in this step may be used for AoC-S
  • FIG. 3 shows an internal structure of a subscriber database 100, such as AAA server or HSS, according to an embodiment of the invention.
  • the subscriber database can comprise a receiving unit 101 configured to receive a request associated with a user, and a providing unit 105 to provide charging function address to a network element, which units may be configured to receive the request and send the charging function address via Cx interface or Sh interface of the IMS, for example to/from an CSCF 200 or to/from application server 300, such as advice of charge application server or advice of charge function.
  • the charging function address can comprise an offline charging advice of charge function (OAF) address, diameter-URI or diameter-Id.
  • the subscriber database 100 can also have a storing unit 103 for storing charging function address.
  • Providing the charging function address by the providing unit 105 can comprise providing the charging function address as part of a user profile download operation.
  • FIG. 3 also shows an internal structure of a control function 200, such as S-CSCF, according to an embodiment of the invention.
  • the control function can comprise a receiving unit 201 configured to receive charging function address from a subscriber database 100 such as HSS or AAA server.
  • the receiving unit 201 can receive the charging function address via Cx interface of the IMS, and can be received as part of a user profile download operation.
  • the unit 201 can also be configured to receive a request from an application server 300, such as AoC AS or AoC function.
  • the control function can have a requesting unit 205 configured to request charging function address from the subscriber database 100.
  • the requesting unit 205 can request the charging function address via Cx interface of the IMS, and can be requested as part of a user profile download operation.
  • the control function 200 can have a sending unit 203 configured to send charging function address to a second network element, such as application server (AS) 300.
  • the application server 300 can be a SIP AS such as AoC AS or AoC function.
  • the sending unit 203 can be configured to send the charging function address in SIP signaling messages.
  • the charging function address is sent in a P-Charging -Vector header.
  • the charging function address can comprise an offline charging advice of charge function (OAF) address, diameter-URI or diameter-Id.
  • the control function 200 can also comprise a storing unit 207 configured to store charging function address together with user profile information and initial filter criteria (iFC) .
  • FIG. 3 also shows an internal structure of an application server 300, such as SIP AS, for example AoC AS or AoC function, according to an embodiment of the invention.
  • the application server can comprise a receiving unit 301.
  • the receiving unit 301 can receive the charging function address via Sh interface of the IMS from a subscriber database 100, such as HSS or AAA server.
  • the receiving unit can be configured to receive the charging function address in SIP signaling messages from a control function 200, such as S-CSCF, via ISC interface.
  • the charging function address is received in a P-Charging -Vector header.
  • the charging function address can comprise an offline charging advice of charge function (OAF) address, diameter-URI or diameter-Id.
  • OAF offline charging advice of charge function
  • the AS can also comprise a requesting unit 303 configured to request charging function address from a subscriber database 100 or from a control function 200.
  • the requesting and receiving units can be further adopted to request and receive AoC related information, such as cost information, tariff information or rate information from the charging function 400.
  • the application server 300 can be adopted to communicate with the charging function 400 via diameter based interface and to request and receive at least one of cost information, tariff information or rate information in credit control request (CCR) or credit control event request (CCRe) and credit control answer (CCA) or credit control event answer (CCAe) messages.
  • FIG 3 also shows an internal structure of a charging function 400, such as offline charging AoC function (OAF) , according to an embodiment of the invention.
  • the charging function can comprise a receiving unit 401 configured to receiving a request for AoC related information from an application server 300, such as AoC AS or AoC function.
  • the AoC related information comprises at least one of cost information, tariff information and rate information.
  • the charging function 400 can comprise obtaining unit 403 for obtaining AoC related information from the billing domain, and a providing unit 405 for providing AoC related information to the application server 300.
  • the charging function 400 can be adopted to communicate with the application server 300 via diameter based interface.
  • the charging function 400 can receive the request for AoC related information from the application server 300 in a credit control request (CCR) or a credit control event request (CCRe) message and provide AoC related information to the application server 300 in a credit control answer (CCA) or a credit control event answer (CCAe) message.
  • CCR credit control request
  • CCRe credit control event request
  • CCA credit control answer
  • CCAe credit control event answer
  • a subscriber database, a control function, an application server and a charging function may be physically implemented in a switch, router, server or other hardware platform or electronic equipment which can support data transmission and processing tasks, or can be implemented as a component of other existing device .
  • FIG. 4 presents a method of providing charging function address, such as OAF address, in a communication system according to an embodiment of the invention.
  • the method includes storing 1001 charging function address in a subscriber database such as HSS or AAA server, receiving 1002 a user specific request from a network element such as CSCF, in particular S- CSCF or AS, in particular AoC AS or AoC function, and providing 1003 charging function address from a subscriber database to the network element.
  • Stroring charging function address can comprise for example pre-configuring the address by an operator or service provider who is controlling the HSS, or downloading the address from a further server.
  • Figure 5 presents another method of providing charging function address in a communication system according to an embodiment of the invention.
  • the method includes storing 1001 charging function address in a subscriber database such as HSS or AAA server, receiving 1002 a user specific request from a first network element such as a control function, in particular a S-CSCF, providing 1003 charging function address from a subscriber database to the first network element, and sending 1004 charging function address to a second network element such as AS, in particular AoC AS or AoC function, from the first network element.
  • Stroring charging function address can comprise for example pre-configuring the address by an operator or service provider who is controlling the HSS, or downloading the address from a further server.
  • Figure 6 presents a method of providing AoC related information in a communication system according to an embodiment of the invention.
  • the method includes receiving 2001 a request for AoC related information from an application server, such as AoC AS or AoC function, obtaining 2002 AoC related information from a billing domain, and providing 2003 AoC related information to the application server.
  • AoC related information may include for example rate information, tariff information and cost information.
  • the invention is not limited to the IMS, but can also be applied in other type of networks providing AoC and having similar type of subscriber entity as in the IMS.
  • the invention is applicable also to fixed networks and fixed mobile convergence (FMC) networks, as well as next generation networks (NGN) Therefore, the HSS/AAA, the AoC AS, the IMS-GWF and S- CSCF are only used here as examples of possible network elements.
  • Functions of a subscriber database, a control function and an application server described above may be implemented by code means, as software, and loaded into memory of a computer.

Abstract

Advice of charge service A method in a communication system is provided, comprising receiving a request from an application server at a charging function, obtaining advice of charge related information from a billing domain and providing an answer to the application server from the charging function.

Description

Descript ion
Tit le
Advice of charge service
Technical field of the invention
The invention relates to a method, a subscriber database, a control function, an application server, a charging function and a computer program product for providing an advice of charge service to offline charged users .
Background of the invention
Within the IP (Internet Protocol) Multimedia Subsystem (IMS) as defined by 3rd Generation Partnership Project (3GPP) Session Initiation Protocol (SIP) defined by Internet Engineering Task Force (IETF) is used for controlling communication. SIP is an application- layer control protocol for creating, modifying, and terminating sessions with one or more participants. These sessions may include Internet multimedia conferences, Internet telephone calls, and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.
An Advice of Charge (AoC) supplementary service used in communication systems announces the tariff/rate/cost of the requested service e.g. a phone call to the user, either the expected rate before connecting the call, during the call the cumulated costs, or after the call the total costs. The AoC allows the user to terminate the service before costs emerge to the user. This service is required by many regulators for cost transparency reasons.
Currently, in many public switched telephone network (PSTN) and public land mobile network (PLMN) telephony networks the AoC service is offered, for example as announcements for premium rate services "This call costs you 2 Euro a minute...". In the future the regulators can request the AoC service also for voice over internet protocol (VoIP) phone calls either, e.g. calls switched via the IMS or other IMS services. At the time being, the AoC service is requested by many operators in tenders for both user comfort and to fulfill expected regulatory issues.
Currently, in the 3GPP standardisation body the standardisation of the AoC service is ongoing and will be specified in TS 32.280. However, the current 3GPP specifications do not describe and there is no existing solution on how the AoC service can be offered to offline charged IMS users.
Therefore, the object of the invention is to provide a solution for offering AoC in the IMS also for offline charged users .
Summary of the invention The present invention overcomes the above problem by providing a method comprising storing charging function address in a subscriber database and providing charging function address to a first network element from the subscriber database. According to an aspect of the invention the method further comprises receiving a user specific request from the first network element. Examples of further refinements of the invention as defined under the above aspect are described in the dependent claims 2 to 20.
According to an aspect of the invention, the invention further provides a method comprising receiving a request from an application server at a charging function and providing an answer to the application server from the charging function. According to another aspect of the invention the method further comprises obtaining advice of charge related information from a billing domain. Examples of further refinements of the invention as defined under the above aspect are described in the dependent claims 23
According to an aspect of the invention, the invention further provides a subscriber database comprising storing means for storing charging function address, receiving means for receiving a request associated with a user and providing means for providing charging function address in response to the request. Examples of further refinements of the invention as defined under the above aspect are described in the dependent claims According to an aspect of the invention, the invention further provides a control function comprising requesting means for requesting charging function address from a subscriber database and receiving means for receiving charging function address from the subscriber database. According to another aspect of the invention the control function further comprises sending means for sending charging function address to an application server. Examples of further refinements of the invention as defined under the above aspect are described in the dependent claims 66 to 74.
According to an aspect of the invention, the invention further provides an application server comprising receiving means for receiving charging function address. According to another aspect of the invention the application server further comprises requesting means adopted to request charging function address from a subscriber database or from a control function. Examples of further refinements of the invention as defined under the above aspect are described in the dependent claims 76 to 93.
According to an aspect of the invention, the invention further provides a charging function comprising receiving means for receiving a request for advice of charge related information from an application server, obtaining means for obtaining advice of charge related information from a billing domain and providing means for providing advice of charge related information to the application server. Examples of further refinements of the invention as defined under the above aspect are described in the dependent claims 95 to 102.
According to an aspect of the invention, the invention further provides a computer program product comprising code means adapted to produce the steps of any one of methods described above when loaded into the memory of a computer.
The present invention has the advantage that the AoC service can be provided to offline charged users of a communication network, for example offline charged users in IMS. The present invention has a further advantage that the AoC service can be provided to offline charged users of a communication network without a need to contact online charging system. Therefore this invention provides a solution also in networks that do not have online charging system at all.
Brief description of drawings :
Embodiments of the present invention are described herein below with reference to the accompanying drawings, wherein:
Figure 1 illustrates IMS AoC charging architecture as currently specified in 3GPP.
Figure 2 illustrates IMS AoC charging architecture according to embodiments of the invention Figure 3 explains internal structures of the relevant network elements according to embodiments of the invention .
Figures 4, 5 and 6 show methods according to embodiments of the invention.
Detailed description of the invention
Different type of network entities and functions exist in the IMS network. Call Session Control Functions (CSCF) implement a session control function in SIP layer. The CSCF can act as Proxy CSCF (P-CSCF), Serving CSCF (S-CSCF) or Interrogating CSCF (I-CSCF) . The P-CSCF is the first contact point for the User Equipment (UE) within the IMS; the S-CSCF actually handles the session states in the network; the I-CSCF is mainly the contact point within an operator's network for all IMS connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operator's service area.
The functions performed by the I-CSCF are, for example, assigning an S-CSCF to a user performing SIP registration and routing SIP requests received from another network towards the S-CSCF. The S-CSCF performs the session control services for the UE. It maintains a session state as needed by the network operator for support of the services and may be acting as registrar, i.e. it accepts registration requests and makes its information available through the location server. The S-CSCF is the central point to users that are hosted by this S-CSCF. The S-CSCF provides services to registered and unregistered users when it is assigned to these users. This assignment is stored in the Home Subscriber Server (HSS) .
The HSS is the master database for a given user. It is the entity containing the subscription-related information to support the network entities actually handling calls/sessions. As an example, the HSS provides support to the call control servers (CSCFs) in order to complete the routing/roaming procedures by solving authentication, authorisation, naming/addressing resolution, location dependencies, etc. For IMS a certain service is typically assigned to a subscriber by a filter criteria within its HSS data set, this filter criteria forces a serving CSCF of a certain subscriber to route SIP messages that belongs to this subscriber and service via a SIP application servers (SIP-AS) that matches to this filter criteria.
The HSS is responsible for holding the following user related information:
- User Identification, Numbering and addressing information
- User Security information: Network access control information for authentication and authorisation, such as password information
User Location information at inter-system level: the HSS supports the user registration, and stores inter-system location information, etc.
- User profile information. Cx reference point or Cx interface is an interface between a CSCF and a HSS, supporting the transfer of data between them. The Cx reference point is based on the diameter protocol with 3GPP standard diameter applications. Sh interface is a corresponding interface between the HSS and an application server (AS) . Diameter is an authentication, authorisation, and accounting (AAA) protocol defined by the IETF and used for network access services, such as dial-up and mobile IP.
An Application Server (AS) is offering value added IP multimedia (IM) services to users of the IMS network and resides either in the IMS user's home network or in a third party location. The third party could be a network or simply a stand-alone AS. The AS may host and execute various services and can influence and impact a SIP session on behalf of the services. The IP multimedia Subsystem Service Control Interface (ISC) interface is between the S-CSCF and the service platforms (i.e. ASs). The ISC interface offers extended services to subscribers. ASs that are connected to the IMS are controlled via ISC interface. The protocol used on the ISC interface is the SIP. Examples of an AS include e.g. AoC AS or AoC function and IMS-gateway function (IMS-GWF) .
An HSS can communicate with an application server over Sh interface. The Sh interface enables data handling procedures, for example, download of data from the HSS to an AS, or update of data in the HSS. An AS can subscribe to receive notifications from the HSS of changes in data. The HSS can notify an AS of changes in data for which the AS previously had subscribed. Diameter protocol can be used in Sh interface .
A next level server or function is not directly behind the ISC or reachable via SIP but reachable via another protocol from special functions or registered application servers, defined via initial filter criteria (iFC) a user profile. Examples of next level functions are an online charging system (OCS) that is reachable via diameter credit control application CCA (Ro) from the IMS-GWF and a charging collection function (CCF) that is reachable via diameter accounting (Rf) from the internal charging data function .
Charging is a function within the telecommunications network and the associated charging elements whereby information related to a chargeable event is collected, formatted, transferred and evaluated in order to make it possible to determine usage for which the charged party may be billed (offline charging) or the subscribers account balance may be debited (online charging) .
An online charging also known as credit-based charging, is used for prepaid services, or real-time credit control of postpaid services. It is a charging mechanism where charging information can affect, in real-time, the service rendered and therefore a direct interaction of the charging mechanism with session/service control is required. Online charging is provided by an online charging system (OCS) . Offline charging is applied to users who pay for their services periodically (e.g., at the end of the month). An offline charging is a charging mechanism where charging information does not affect, in real-time, the service rendered. A tariff is a set of parameters defining the network utilization charges for the use of a particular bearer, session and/or service. Offline charging is provided by a billing domain (BD) .
An Advice of Charge (AoC) supplementary service used in communication systems announces the tariff/rate/cost of the requested service e.g. a phone call to the user, either the expected rate before connecting the call, during the call the cumulated costs, or after the call the total costs. The AoC allows the user to terminate the service before costs emerge to the user.
Three AOC services exist: a) Charging information at communication set-up time (AOC-S)
The AOC-S service enables a user to receive information about the charging rates at communication set-up time and also to receive further information during the communication if there is a change of charging rates. b) Charging information during the communication (AOC-D)
The AOC-D service enables a user to receive information on the recorded charges for a communication during the active phase of the communication . c) Charging information at the end of the communication (AOC-E)
The AOC-E service enables a user to receive information on the recorded charges for a communication when the communication is terminated.
An AoC architecture for the IMS is shown in figure 1. The IMS charging architecture as shown in Fig. 1 comprises a billing domain, a charging collection function (CCF) involved with offline charging including a charging gateway function (CGF) and a charging data function (CDF) , a used equipment UE, a Proxy call session control function (P-CSCF) , a serving call session control function (S-CSCF) , an IMS-GWF, online charging system (OCS) , an AoC function, and an interconnect border control function (IBCF) . The architecture further comprises a home subscriber server (HSS) , which is not shown in the figure. The HSS stores filter criteria, in particular initial filter criteria (iFC) set for the users or UEs assigned to the respective HSS. The filter criteria determine the services that will be provided to each user. The HSS is accessible by the S-CSCF via Cx interface and by an AS, such as AoC function, via Sh interface .
PREFERRED EMBODIMENTS
Preferred embodiments of the present invention will be described herein below with reference to the accompanying drawings . The figure 2. shows an IMS AoC charging architecture according to embodiments of the invention. A charging function, preferably an offline charging advice of charge function (OAF) is provided. The OAF is a new interface partner for the advice of charge function (ACF) for offline charged IMS users. It can be defined within the Billing system and accessible via a special SIP-AS, namely ACF. The task of the OAF is to provide specific information, which can be used to build the AoC Information, e.g. tariff, cost or rate information. For this purpose the OAF may provide an interface to the user/subscriber database in the billing domain to determine which tariff the user has subscribed, but also to a rating function of the billing domain to determine the costs of the requested IMS service. The OAF may process the received information and to reply to request of the ACF.
According to embodiments of the invention, a charging function address, preferably an OAF address, is defined. The charging function address can be stored in a subscriber database, such as an AAA server or a HSS, and the application server, such as AoC function or AoC AS, can retrieve the charging function address to request AoC Information. The address can be retrieved by the application server directly from the subscriber database via Sh interface or by a control function, such as S-CSCF, via Cx interface and further sent to the application server. The AAA server is a server that handles user requests for access to computer resources and provides authentication, authorisation, and accounting services. The AAA server can interact with network access and gateway servers and with databases and directories that contain user information. Devices and applications typically communicate with an AAA server by using the remote authentication dial-in user service (RADIUS) .
According to first embodiment of the invention, a method is provided in which charging function address is stored in a subscriber server, such as HSS, and provided to a network element, such as a S-CSCF, or an application server, such as AoC AS or AoC function. The charging function address may comprise an offline charging AoC function (OAF) address. The OAF address may comprise a diameter uniform resource identifier (Diameter-URI) or diameter identifier (Diameter-Id).
The charging function address may be provided via Cx query together with the initial filter criteria (iFC) and user profile to the control function. Further, the charging function address may be provided via the Sh interface, if requested by a particular SIP-AS, like the AoC AS or AoC function.
P-charging-vector is a SIP private header which is used to share the charging correlation information among different IP multimedia subsystem (IMS) network elements and between the IMS and the access network. P-charging-vector consists of the IMS charging identifier, inter-operator identifier, and access network charging information. The charging function address can be provided from the control function to the application server in the P-Charging-Vector header . The charging function address may be assigned to a subscriber within its HSS user profile. The access to charging specific HSS subscriber data entries may be done using the Cx interface while subscriber registration in the control function, namely S-CSCF, but also by a SIP-AS using the Sh interface. The Sh interface may be enhanced accordingly to be able to carry the OAF address.
In one aspect of the invention the charging function address may be downloaded to the S-CSCF from the HSS via Cx query when the subscriber registers at the IMS. For this purpose a new AVP can be used. According to another aspect of the invention, the address can be sent within SIP signalling messages via ISC interface from the S-CSCF to an AS while 3rd party registration and while SIP service execution (e.g. via SIPiINVITE or SIPIMESSAGE) . The address may be sent within a charging related attribute value pair (AVP) to e.g. the SIP application servers that are involved into SIP service processing. According to a further aspect of the invention, the address may be provided to an AS directly from the HSS via Sh interface.
According to another embodiment of the invention, a method is provided in which AoC related information is provided in a communication system. The advice of charge related information may comprise cost information, tariff information or rate information. According to an aspect of the invention, the AoC related information is requested by an application server, such as AoC AS or AoC function, and provided by a charging function, such as OAF, over diameter based interface. The charging function may obtain the AoC related information from a billing domain. The AoC related information may be requested in a credit control request (CCR) message as defined in IETF RFC 4006. Further, the AoC related information may be requested in a credit control event request (CCRe) message. The AoC related information may be provided in a credit control answer (CCA) message as defined in IETF RFC 4006. Further, the AoC related information may be provided in a credit control event answer (CCAe) message. The diameter credit control request and credit control answer messages are defined in IETF RFC 4006 as follows.
<CCR> ::= < Diameter Header: 272, REQ, PXY > < Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Service-Context-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ Destination-Host ]
[ User-Name ]
[ CC Sub Scooion Id ]
[ Acct Multi Scooion Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
* [ Subscription-Id ]
[ Service Identifier 1
Termination—Cauoc [ RcquGOtcd Service Unit ]
[ Requested-Action ]
* [ Uocd Service Unit 1
Multiple—Serviced—Indicator—]- Multiple Serviced Credit Control
-*-f:—Service—Parameter—Inf< [ CC Correlation Id ] [ User-Equipment-Info ]
* Proxy-Info ] * [ Route-Record ]
[ Service-Information ] * [ AVP 1
<CCA> ::= < Diameter Header: 272, PXY >
< Session-Id >
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
{ Auth-Applicαtion-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ CC-Session-Fαilover 1
Multiple Serviced Credit Control
[ Cost-Informαtion] -E—Low Balance—Indication—]- -E—Remaining Balance—]- [ Credit-Control-Failure-Handling ] [ Direct-Debiting-Failure-Handling ]
*[ Redirect-Host] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ Failed-AVP ]
[ Service-Information ] * [ AVP ]
According to an aspect of the invention, the requesting of the tariff-, rate and cost-information can be performed with the Credit Control Event Request (CCRe) message. The CCRe may be filled out in the following way:
• The CC-Request-Type AVP can be set to EVENT_REQUEST.
• The Requested-Action AVP can be set to PRICE_ENQUIRY.
• The Destination-Realm AVP and the Destination-Host AVP can be filled with the OAF address, as received from the HSS
The Service-Information AVP can be included according to the 3GPP TS 32.260 and TS 32.299 for providing information about an IMS service. The OAF can provide this information to the rating function in the BD for determining the costs of the IMS service.
The OAF may provide to cost-, rate and tariff information to the ACF by using the CCAe message. The CCRe message is described in the 3GPP TS 32.299. The cost-, tariff- and rate information can be provided in the Cost-Information AVP that is defined in the IETF RFC 4006.
Cost-Information ::= < AVP Header: 423 >
{ Unit-Value }
{ Currency-Code }
[ Cost-Unit ]
The ACF may use the received information for providing the AoC-information to the IMS user.
If the ACF wants to know the user's tariff only, then the CCRe can be filled in the following way:
• The CC-Request-Type AVP can be set to EVENT_REQUEST.
• The Requested-Action AVP can be set to TARIFF_ENQUIRY..
• The Destination-Realm AVP and the Destination-Host AVP can be filled with the OAF address, as received from the HSS
The OAF may provide the tariff information from the user database in the billing domain if such a CCRe is received from the ACF. For this purpose a new AVP can be defined, as the following example, or an existing AVP can be enhanced, like the cost-information AVP. Tariff-Information ::= < AVP Header: xxx
[ Current-Tariff ] [ Next-Tariff-Switch ] [ Next-Tariff ] * [ AVP ]
The Current-Tariff AVP can be used to provide information about the current tariff, such as price per time, time unit, price information, currency information, price per event and event unit. Next- Tariff-Switch AVP can be used to inform the ACF when the next tariff switch will happen. Next-Tariff AVP can include the same set of information as the current-tariff AVP, such as price per time, time unit, price information, currency information, price per event and event unit, but includes the tariff information which shall be applied after the tariff switch .
If the ACF wants to know the user's rating information only, then the CCRe can be filled in the following way :
• The CC-Request-Type AVP can be set to EVENT_REQUEST.
• The Requested-Action AVP can be set to RATE_ENQUIRY..
• The Destination-Realm AVP and the Destination-Host AVP can be filled with the OAF address, as received from the HSS The OAF may provide the rate information from the billing domain if such a CCRe is received from the ACF. For this purpose a new AVP can be defined or an existing AVP can be enhanced, like the cost- information AVP.
The following trigger points can be used to contact the OAF:
• During the SIP session establishment (when the SIP INVITE is received) ; the information received in this step may be used for AoC-S
• Media change during the ongoing SIP session (when the SIP Re-INVITE is received) ; the information received in this step may be used for AoC-D
• Tariff Switch (no SIP based trigger point) ; the information received in this step may be used for AoC- D
• Information for AoC-D (SIP INFO)
• Session release (when the SIP BYE is received) ; the information received in this step may be used for AoC-S
Figure 3 shows an internal structure of a subscriber database 100, such as AAA server or HSS, according to an embodiment of the invention. The subscriber database can comprise a receiving unit 101 configured to receive a request associated with a user, and a providing unit 105 to provide charging function address to a network element, which units may be configured to receive the request and send the charging function address via Cx interface or Sh interface of the IMS, for example to/from an CSCF 200 or to/from application server 300, such as advice of charge application server or advice of charge function. The charging function address can comprise an offline charging advice of charge function (OAF) address, diameter-URI or diameter-Id. The subscriber database 100 can also have a storing unit 103 for storing charging function address. Providing the charging function address by the providing unit 105 can comprise providing the charging function address as part of a user profile download operation.
Figure 3 also shows an internal structure of a control function 200, such as S-CSCF, according to an embodiment of the invention. The control function can comprise a receiving unit 201 configured to receive charging function address from a subscriber database 100 such as HSS or AAA server. The receiving unit 201 can receive the charging function address via Cx interface of the IMS, and can be received as part of a user profile download operation. The unit 201 can also be configured to receive a request from an application server 300, such as AoC AS or AoC function. The control function can have a requesting unit 205 configured to request charging function address from the subscriber database 100. The requesting unit 205 can request the charging function address via Cx interface of the IMS, and can be requested as part of a user profile download operation. The control function 200 can have a sending unit 203 configured to send charging function address to a second network element, such as application server (AS) 300. According to an aspect of the invention, the application server 300 can be a SIP AS such as AoC AS or AoC function. The sending unit 203 can be configured to send the charging function address in SIP signaling messages. In one embodiment of the invention, the charging function address is sent in a P-Charging -Vector header. The charging function address can comprise an offline charging advice of charge function (OAF) address, diameter-URI or diameter-Id. The control function 200 can also comprise a storing unit 207 configured to store charging function address together with user profile information and initial filter criteria (iFC) .
Figure 3 also shows an internal structure of an application server 300, such as SIP AS, for example AoC AS or AoC function, according to an embodiment of the invention. The application server can comprise a receiving unit 301. The receiving unit 301 can receive the charging function address via Sh interface of the IMS from a subscriber database 100, such as HSS or AAA server. According to an aspect of the invention, the receiving unit can be configured to receive the charging function address in SIP signaling messages from a control function 200, such as S-CSCF, via ISC interface. In one embodiment of the invention, the charging function address is received in a P-Charging -Vector header. The charging function address can comprise an offline charging advice of charge function (OAF) address, diameter-URI or diameter-Id. The AS can also comprise a requesting unit 303 configured to request charging function address from a subscriber database 100 or from a control function 200. In one aspect of the invention, the requesting and receiving units can be further adopted to request and receive AoC related information, such as cost information, tariff information or rate information from the charging function 400. The application server 300 can be adopted to communicate with the charging function 400 via diameter based interface and to request and receive at least one of cost information, tariff information or rate information in credit control request (CCR) or credit control event request (CCRe) and credit control answer (CCA) or credit control event answer (CCAe) messages.
Figure 3 also shows an internal structure of a charging function 400, such as offline charging AoC function (OAF) , according to an embodiment of the invention. The charging function can comprise a receiving unit 401 configured to receiving a request for AoC related information from an application server 300, such as AoC AS or AoC function. The AoC related information comprises at least one of cost information, tariff information and rate information. The charging function 400 can comprise obtaining unit 403 for obtaining AoC related information from the billing domain, and a providing unit 405 for providing AoC related information to the application server 300. The charging function 400 can be adopted to communicate with the application server 300 via diameter based interface. The charging function 400 can receive the request for AoC related information from the application server 300 in a credit control request (CCR) or a credit control event request (CCRe) message and provide AoC related information to the application server 300 in a credit control answer (CCA) or a credit control event answer (CCAe) message.
All units described above may be implemented for example using microprocessors and/or other electrical components and/or by software.
A subscriber database, a control function, an application server and a charging function may be physically implemented in a switch, router, server or other hardware platform or electronic equipment which can support data transmission and processing tasks, or can be implemented as a component of other existing device .
Figure 4 presents a method of providing charging function address, such as OAF address, in a communication system according to an embodiment of the invention. The method includes storing 1001 charging function address in a subscriber database such as HSS or AAA server, receiving 1002 a user specific request from a network element such as CSCF, in particular S- CSCF or AS, in particular AoC AS or AoC function, and providing 1003 charging function address from a subscriber database to the network element. Stroring charging function address can comprise for example pre-configuring the address by an operator or service provider who is controlling the HSS, or downloading the address from a further server.
Figure 5 presents another method of providing charging function address in a communication system according to an embodiment of the invention. The method includes storing 1001 charging function address in a subscriber database such as HSS or AAA server, receiving 1002 a user specific request from a first network element such as a control function, in particular a S-CSCF, providing 1003 charging function address from a subscriber database to the first network element, and sending 1004 charging function address to a second network element such as AS, in particular AoC AS or AoC function, from the first network element. Stroring charging function address can comprise for example pre-configuring the address by an operator or service provider who is controlling the HSS, or downloading the address from a further server.
Figure 6 presents a method of providing AoC related information in a communication system according to an embodiment of the invention. The method includes receiving 2001 a request for AoC related information from an application server, such as AoC AS or AoC function, obtaining 2002 AoC related information from a billing domain, and providing 2003 AoC related information to the application server. AoC related information may include for example rate information, tariff information and cost information.
The invention is not limited to the IMS, but can also be applied in other type of networks providing AoC and having similar type of subscriber entity as in the IMS. In particular the invention is applicable also to fixed networks and fixed mobile convergence (FMC) networks, as well as next generation networks (NGN) Therefore, the HSS/AAA, the AoC AS, the IMS-GWF and S- CSCF are only used here as examples of possible network elements. Functions of a subscriber database, a control function and an application server described above may be implemented by code means, as software, and loaded into memory of a computer.

Claims

Claims
1. A method of providing charging function address in a communication system, comprising: storing (1001) charging function address in a subscriber database (100), and providing (1003) charging function address to a first network element from the subscriber database (100) .
2. The method of claim 1 further comprising receiving (1002) a user specific request from the first network element.
3. The method of claim 1 or 2, wherein the storing (1001) comprises storing charging function address as a part of user profile in a subscriber database (100), and the providing (1003) comprises providing charging function address as a part of user profile information.
4. The method of any of preceding claims, wherein the providing (1003) comprises providing the charging function address as an attribute value pair .
5. The method of any of preceding claims, wherein the providing (1003) comprises providing the charging function address via Cx interface of an internet protocol multimedia subsystem.
6. The method of any of preceding claims, wherein the providing (1003) comprises providing the charging function address as part of a user profile download operation.
7. The method of any of preceding claims, wherein the providing (1003) comprises providing the charging function address while user registration in an internet protocol multimedia subsystem.
8. The method of any of preceding claims, further comprising sending (1004) charging function address from the first network element to a second network element.
9. The method of any of claims 1 to 8, wherein the first network element comprises a call state control function (200) in an internet protocol multimedia subsystem.
10. The method of the claim 8 or 9, wherein the second network element comprises an application server
(300) .
11. The method of any of preceding claims, wherein the providing (1003) comprises providing the charging function address via Sh interface of an internet protocol multimedia subsystem.
12. The method of any of preceding claims, wherein the first network element comprises an application server (300) .
13. The method of any of preceding claims, wherein the application server (300) comprises an advice of charge application server or an advice of charge function .
14. The method of any of preceding claims, wherein the charging function address is sent in a header of a session initiation protocol message.
15. The method of any of preceding claims, wherein the charging function address is sent in a P-Charging- Vector header.
16. The method of any preceding claims, wherein the subscriber database (100) comprises a home subscriber server of an internet protocol multimedia subsystem or an authentication, authorisation, and accounting server.
17. The method of any of preceding claims, wherein the charging function address comprises an advice of charge function address.
18. The method of any of preceding claims, wherein the charging function address comprises an offline charging advice of charge function address.
19. The method according to any of preceding claims, wherein the charging function (400) comprises a part of a billing domain.
20. The method according to any of preceding claims, wherein the charging function address comprises a Diameter-URI or a Diameter-Id.
21. A method of providing advice of charge related information in a communication system, comprising: receiving (2001) a request from an application server (300) at a charging function (400) providing (2003) an answer to the application server (300) from the charging function (400).
22. The method of claim 21 further comprising obtaining (2002) advice of charge related information from a billing domain.
23. The method of claim 21 or 22, wherein the advice of charge related information comprises at least one of cost information, tariff information or rate information .
24. The method of any of claims 21 to 23, wherein the application server (300) comprises an advice of charge application server or an advice of charge function .
25. The method of of any of claims 21 to 24, wherein the charging function (400) comprises an offline advice of charge charging function.
26. The method of any of claims 21 to 25, wherein the application server (300) is adopted to communicate with the charging function (400) via diameter based interface .
27. The method of any of claims 21 to 26, wherein the request comprises a credit control request message.
28. The method of any of claims 21 to 27, wherein the request comprises a diameter credit control request message according to RFC 4006.
29. The method of any of claims 21 to 28 wherein the request comprises a credit control event request message .
30. The method of any of claims 21 to 29 wherein the request message includes attribute value pairs.
31. The method of any of claims 21 to 30, wherein the attribute value pairs comprise at least one of a CC-Request-Type attribute value pair, a Requested - Action attribute value pair, a Destination-Realm attribute value pair, a Destination-Host attribute value pair, and a Service-Information attribute value pair.
32. The method of claim 31, wherein the CC-Request- Type attribute value pair is set to EVENT_REQUEST .
33. The method of claim 31, wherein the Requested - Action attribute value pair is set to PRICE_ENQUIRY, TARIFF_ENQUIRY or RATE_ENQUIRY .
34. The method of claim 31, wherein at least one of the Destination-Realm and Destination-Host attribute value pair is filled with a charging function address.
35. The method of claim 34, wherein the charging function address comprises an advice of charge function address.
36. The method of claim 34 or 35, wherein the charging function address comprises an offline charging advice of charge function address.
37. The method according to any of any of claims 21 to 36, wherein the charging function (400) comprises a part of a billing domain.
38. The method according to any of claims 34 to 37, wherein the charging function address comprises a Diameter-URI or a Diameter-Id.
39. The method of claim 31, wherein the Service- Information attribute value pair is included in the request for providing information about internet protocol multimedia subsystem service.
40. The method of any of claims 21 to 39, wherein the answer comprises a credit control answer message.
41. The method of any of claims 21 to 40, wherein the answer comprises a diameter credit control answer message according to RFC 4006.
42. The method of any of claims 21 to 41, wherein the answer comprises a credit control event answer message .
43. The method of any of claims 21 to 42, wherein the answer message includes attribute value pairs.
44. The method of claim 43, wherein the attribute value pairs comprise at least one of a Cost- Information attribute value pair, a Tariff- Information attribute value pair, and a Rate- Information attribute value pair.
45. The method of claim 44, wherein the Cost- Information attribute value pair comprises at least one of cost information, tariff information and rate information.
46. The method of claim 44, wherein the Cost- Information attribute value pair comprises a Cost- Information attribute value pair as defined in IETF RFC 4006.
47. The method of claim 44, wherein the Tariff- Information attribute value pair comprises tariff information .
48. The method of claim 44 or 47, wherein the Tariff- Information attribute value pair comprises at least one of a Current-Tariff attribute value pair, a Next-Tariff-Switch attribute value pair, and a Next-Tariff attribute value pair.
49. The method of claim 48, wherein the Current-Tariff attribute value pair comprises information about current tariff applied for a user.
50. The method of claim 48 or 49, wherein the Current- Tariff attribute value pair comprises at least one of price per time, time unit, price information, currency information, price per event, and event unit .
51. The method of claim 48, wherein the Next-Tariff- Switch attribute value pair comprises information about when next tariff switch will happen.
52. The method of claim 48, wherein the Next-Tariff attribute value pair comprises information about when current tariff applied for a user.
53. The method of claim 48 or 52, wherein the Next- Tariff attribute value pair comprises at least one of price per time, time unit, price information, currency information, price per event, and event unit .
54. The method of claim 44, wherein the Rate- Information attribute value pair comprises rate information .
55. The method of any of claims 21 to 54, wherein the sending is triggered by at least one of SIP session establishment, media change during ongoing SIP session, tariff switch, SIP information message, and SIP session release.
56. A subscriber database (100) in a communication system, comprising: storing means (103) for storing charging function address, receiving means (101) for receiving a request associated with a user, providing means (105) for providing charging function address in response to the request.
57. The subscriber database (100) of claim 56, wherein the subscriber database comprises a home subscriber server of an internet protocol multimedia subsystem or an authentication, authorisation, and accounting server .
58. The subscriber database (100) of claim 56 or 57, wherein the receiving means (101) and the providing means (105) are configured to receive the request and provide the charging function address via Cx interface of an internet protocol multimedia subsystem.
59. The subscriber database (100) of any of claims 56 to 58, wherein the receiving means (101) and the providing means (105) are configured to receive the request and provide the charging function address via Sh interface of an internet protocol multimedia subsystem.
60. The subscriber database (100) of any of claims 56 to 59, wherein the providing the charging function address comprises providing charging function address as part of a user profile download operation .
61. The subscriber database (100) of any of claims 56 to 60, wherein the charging function address comprises an advice of charge function address.
62. The subscriber database (100) of any of claims 56 to 61, wherein the charging function address comprises an offline charging advice of charge function address.
63. The subscriber database (100) of any of claims 56 to 62, wherein the charging function (400) comprises a part of a billing domain.
64. The subscriber database according to any of claims 56 to 63, wherein the charging function address comprises a Diameter-URI or a Diameter-Id.
65. A control function (200) in a communication system, comprising requesting means (205) for requesting charging function address from a subscriber database (100), and receiving means (201) for receiving charging function address from the subscriber database
(100) .
66. The control function (200) of claim 65, wherein the control function comprises a call state control function in an internet protocol multimedia subsystem.
67. The control function (200) of claim 65 or 66, wherein the requesting means (205) and the receiving means (201) are configured to request and receive the charging function address via Cx interface of an internet protocol multimedia subsystem.
68. The control function (200) of any of claims 65 to
67, wherein the receiving charging function address comprises receiving charging function address as part of a user profile download operation.
69. The control function (200) of any of claims 65 to
68, further comprising sending means (203) for sending charging function address to an application server (300).
70. The control function (200) of claim 69, wherein the application server (300) comprises an advice of charge application server or an advice of charge function .
71. The control function (200) of any of claims 65 to
70, wherein the charging function address comprises an advice of charge function address.
72. The control function (200) of any of claims 65 to
71, wherein the charging function address comprises an offline charging advice of charge function address .
73. The control function (200) of any of claims 65 to
72, wherein the charging function (400) comprises a part of a billing domain.
74. The control function (200) of any of claims 65 to 73, wherein the charging function address comprises a Diameter-URI or a Diameter-Id.
75. An application server (300) in a communication communication system, comprising receiving means (301) for receiving charging function address.
76. The application server (300) of claim 75, wherein the receiving means (301) comprise receiving means adopted to receive charging function address from a control function (200).
77. The application server (300) of claim 75 or 76, wherein the receiving means (301) comprise receiving means adopted to receive charging function address in a header of a session initiation protocol message.
78. The application server (300) of any of claims 75 to 77, wherein the receiving means (301) comprise receiving means adopted to receive charging function address in a P-Charging-Vector header.
79. The application server (300) of any of claims 75 to 78, further comprising requesting means (303) adopted to request charging function address from a subscriber database (100) or from a control function (200).
80. The application server (300) of claim 79, wherein the requesting means (303) and the receiving means (301) are configured to request and receive the charging function address via Sh interface of an internet protocol multimedia subsystem.
81. The application server (300) of any of claims 75 to 80, wherein the application server (300) comprises a session initiation protocol application server .
82. The application server (300) of any of claims 75 to 81, wherein the application server (300) comprises an advice of charge application server or an advice of charge function.
83. The application server (300) of any of claims 75 to 82, wherein the charging function address comprises an advice of charge function address.
84. The application server (300) of any of claims 75 to 83, wherein the charging function address comprises an offline charging advice of charge function address.
85. The application server (300) of any of claims 75 to 84, wherein the charging function (400) comprises a part of a billing domain.
86. The application server (300) of any of claims 75 to 85, wherein the charging function address comprises a Diameter-URI or a Diameter-Id.
87. The application server (300) of any of claims 75 to 86, wherein the requesting means (303) and receiving means (301) are further configured to request and receive at least one of cost information, tariff information or rate information from the charging function (400) .
88. The application server (300) of any of claims 75 to 87, wherein the application server (300) is adopted to communicate with the charging function (400) via diameter based interface.
89. The application server (300) of any of claims 75 to 88, wherein the requesting means (303) and the receiving means (301) are further configured to request and receive at least one of cost information, tariff information or rate information in credit control request and credit control answer messages .
90. The application server (300) of claim 89, wherein the credit control request and the credit control answer messages include attribute value pairs.
91. The application server (300) of claim 90, wherein the attribute value pairs included in credit control request message comprise at least one of a CC-Request-Type attribute value pair, a Requested - Action attribute value pair, a Destination-Realm attribute value pair, a Destination-Host attribute value pair, and a Service-Information attribute value pair.
92. The application server (300) of claim 90, wherein the attribute value pairs included in credit control answer message comprise at least one of a a Cost-Information attribute value pair, a Tariff- Information attribute value pair, and a Rate- Information attribute value pair.
93. The application server (300) of any of claims 75 to 92, wherein the application server (300) is adopted to request at least one of cost information, tariff information or rate information from the charging function when triggered by at least one of SIP session establishment, media change during ongoing SIP session, tariff switch, SIP information message, and SIP session release.
94. A charging function (400) in a communication system, comprising: receiving means (401) for receiving a request for advice of charge related information from an application server (300), obtaining means (403) for obtaining advice of charge related information from a billing domain, and providing means (405) for providing advice of charge related information to the application server (300) .
95. The charging function (400) of claim 94, wherein the application server (300) comprises an advice of charge application server or an advice of charge function .
96. The charging function (400) of claim 94 or 95, wherein the advice of charge related information comprise at least one of cost information, tariff information and rate information.
97. The charging function (400) of any of claims 94 to
96, wherein the charging function (400) is adopted to communicate with the application server (300) via diameter based interface.
98. The charging function (400) of any of claims 94 to
97, wherein the receiving means (401) and the providing means (405) are further configured to receive and provide at least one of cost information, tariff information or rate information in credit control request and credit control answer messages .
99. The charging function (400) of claim 98, wherein the credit control request and the credit control answer messages include attribute value pairs.
100. The charging function (400) of any claim 99, wherein the attribute value pairs included in credit control request message comprise at least one of a CC-Request-Type attribute value pair, a Requested -Action attribute value pair, a Destination-Realm attribute value pair, a Destination-Host attribute value pair, and a Service-Information attribute value pair.
101. The charging function (400) of claim 99, wherein the attribute value pairs included in credit control answer message comprise at least one of a a Cost-Information attribute value pair, a Tariff- Information attribute value pair, and a Rate- Information attribute value pair.
102. The charging function (400) of any of claims 94 to 101, wherein the obtaining means (403) are adopted to obtain AoC related information, such as cost information, tariff information and rate information, from the billing domain.
103. A computer program product comprising code means adapted to produce the steps of any one of claims 1 to 20 or 21 to 55 when loaded into the memory of a computer .
PCT/EP2008/058285 2008-06-27 2008-06-27 Advice of charge service WO2009155990A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/058285 WO2009155990A1 (en) 2008-06-27 2008-06-27 Advice of charge service

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/058285 WO2009155990A1 (en) 2008-06-27 2008-06-27 Advice of charge service

Publications (1)

Publication Number Publication Date
WO2009155990A1 true WO2009155990A1 (en) 2009-12-30

Family

ID=40651703

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2008/058285 WO2009155990A1 (en) 2008-06-27 2008-06-27 Advice of charge service

Country Status (1)

Country Link
WO (1) WO2009155990A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100184403A1 (en) * 2009-01-21 2010-07-22 Yigang Cai ADVICE OF CHARGING (AoC) SERVICES IN IMS NETWORKS

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007002421A1 (en) * 2005-06-24 2007-01-04 Lucent Technologies Inc. Ims gateway systems and methods that validate routing to online charging systems

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007002421A1 (en) * 2005-06-24 2007-01-04 Lucent Technologies Inc. Ims gateway systems and methods that validate routing to online charging systems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
G. CAMARILLO, M A. GARCIA-MARTIN: "The 3G IP Multimedia Subsystem (IMS)", 2004, JOHN WILEY AND SONS, LTD, WEST-SUSSEX, ENGLAND, UK, XP002530160, 87156 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100184403A1 (en) * 2009-01-21 2010-07-22 Yigang Cai ADVICE OF CHARGING (AoC) SERVICES IN IMS NETWORKS
US8620262B2 (en) * 2009-01-21 2013-12-31 Alcatel Lucent Advice of charging (AoC) services in IMS networks

Similar Documents

Publication Publication Date Title
EP2274871B1 (en) System, method, and network elements for providing service information such as advice of charge information in a communication network
KR101101015B1 (en) Third party charging for sip sessions
WO2005053327A1 (en) Telecommunications network
JP5734419B2 (en) Service delivery condition change management
JP5583782B2 (en) Method and apparatus for use in a communication network
EP2446581B1 (en) Charging method and apparatus for use in an ip multimedia subsystem
US10158764B2 (en) Methods and apparatus for allocating service costs in a telecommunications network
EP2795837B1 (en) Charging decisions in an ip multimedia subsystem
WO2014135428A1 (en) Multiple tariff switches management
US9185540B2 (en) Method and apparatus for use in a communications network
WO2013064192A1 (en) Method of communication between ims nodes
US7860748B2 (en) Charging in a communication system
EP3107240B1 (en) Dynamic third party charging
WO2010000631A2 (en) Providing charging related information in a communication system
WO2009155990A1 (en) Advice of charge service
WO2009155995A1 (en) Methods, apparatuses, system, computer program product and data structure for call charge indication (aoc)
Chen et al. Design and implementation of an extensible online charging architecture for the open IMS playground
EP3203714A1 (en) Multiple account information for advice of charge
EP3116208A1 (en) Multiple destinations information for advice of charge
Ozianyi et al. Design and implementation of scalable IMS charging systems
WO2009124959A2 (en) Advice of charge service

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08774449

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08774449

Country of ref document: EP

Kind code of ref document: A1