WO2011157077A1 - 基于业务嵌套计费的业务关联方法、装置和系统 - Google Patents

基于业务嵌套计费的业务关联方法、装置和系统 Download PDF

Info

Publication number
WO2011157077A1
WO2011157077A1 PCT/CN2011/072905 CN2011072905W WO2011157077A1 WO 2011157077 A1 WO2011157077 A1 WO 2011157077A1 CN 2011072905 W CN2011072905 W CN 2011072905W WO 2011157077 A1 WO2011157077 A1 WO 2011157077A1
Authority
WO
WIPO (PCT)
Prior art keywords
charging
service
identifier
request message
platform
Prior art date
Application number
PCT/CN2011/072905
Other languages
English (en)
French (fr)
Inventor
顿太永
Original Assignee
华为技术有限公司
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 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2011157077A1 publication Critical patent/WO2011157077A1/zh
Priority to US13/714,282 priority Critical patent/US9203977B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/82—Criteria or parameters used for performing billing operations
    • 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/1425—Charging, metering or billing arrangements for data wireline or wireless communications involving dedicated fields in the data packet for billing purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1428—Invoice generation, e.g. customization, lay-out, database processing, algorithms for calculating the bill or formatting invoices as WWW pages
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/41—Billing record details, i.e. parameters, identifiers, structure of call data record [CDR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/62—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP based on trigger specification

Definitions

  • the present invention relates to the field of network communication technologies, and specifically relates to a service nested charging technology. Background technique
  • the current telecom integrated operators provide a growing variety of services for users.
  • the telecom integrated operator allows users to sign multiple services at the same time, such as allowing users to sign up for the multi-machine service and VPN service at the same time.
  • the number one multi-machine service that is, the plurality of communication terminals, is externally embodied as a number, and the user can use the plurality of communication terminals to flexibly implement the call.
  • the VPN service means that the user can dial the group short number to implement the group call.
  • a service nesting is generated, that is, a communication performed by a user using a communication terminal may trigger multiple services at the same time, for example, the communication terminal 1 and the communication terminal 2 sign a multi-machine service.
  • the external terminal is embodied as the number of the communication terminal 1, and the communication terminal 2 signs the VPN service.
  • Existing billing party It is not flexible enough to meet the various billing requirements for business nesting. Summary of the invention
  • the service association method, device and system based on service nested charging provided by the embodiments of the present invention can associate multiple services nested with each other to improve the flexibility of the service nested charging mode.
  • the method for service association based on service nested charging includes: acquiring a request message that is sent by a service platform and carrying key service information;
  • the charging identifier processing including: searching for the service record information that matches the key service information in the stored service record information, and if there is matching service record information, obtaining the matched service Recording the charging identifier in the information, if there is no matching service record information, assigning a charging identifier; the charging identifier is used by the charging platform to perform associated charging for multiple services having the same charging identifier;
  • the service-related charging method based on the service nesting includes: the charging platform receives the message sent by the service association device, and stores the charging identifier and the charging data of the service in the message in the charging. In the storage unit;
  • the service association device based on service nested charging includes: an obtaining module, which acquires a request message that carries a key service information and is sent by a service platform; a charging identifier processing module, configured to store the service record information And searching for the service record information that matches the key service information, and if there is matching service record information, obtaining the charging identifier in the matched service record information, and if there is no matching service record information, assigning the charging identifier, The charging identifier is used by the charging platform to perform association charging for multiple services having the same charging identifier.
  • the first sending module is configured to send the charging identifier and the request cancellation to the receiving end of the request message. Information carried in the interest.
  • a receiving module configured to receive a message sent by the service association device, and store the charging identifier and the charging data of the service in the message in the charging storage unit;
  • a service configuration rule module configured to determine a service configuration rule of multiple services having the same charging identifier in the charging storage unit
  • the associated charging module is configured to perform association charging on multiple services having the same charging identifier according to the rate corresponding to the service configuration rule and the charging data.
  • the service association system based on service nested charging includes: a service association engine connected to the service platform;
  • a service platform configured to send a request message carrying key service information
  • the service association engine is configured to obtain the request message sent by the service platform, and search for the service record information that matches the key service information in the stored service record information, and if there is matching service record information, obtain a matching service record.
  • the charging identifier in the information if there is no matching service record information, the charging identifier is allocated, and the charging identifier and the information carried in the request message are sent to the receiving end of the request message, where the charging identifier is used.
  • the charging platform performs associated charging for multiple services having the same charging identifier.
  • the description of the foregoing technical solution shows that the key service information carried in the request message is matched in the stored service record information, and the charging identifier is obtained from the matched service record information, or is allocated when there is no matching service record information.
  • the charging identifier enables multiple services that are nested to each other to have the same charging identifier. In this manner, the charging platform can determine multiple associated services that are nested according to the charging identifier, so that the charging platform can associate the services.
  • the flexible use of the cost corresponding to the service configuration rules for billing can ultimately improve the flexibility of the business nested billing method.
  • FIG. 1 is a flowchart of a service association method based on service nested charging according to Embodiment 1 of the present invention
  • FIG. 2 is a flowchart of a service-related charging method based on service nesting according to Embodiment 2 of the present invention
  • Example 3 of the network applicable environment
  • FIG. 3B is a flowchart of a service association method in a service triggering process according to Embodiment 3 of the present invention
  • FIG. 3C is a flowchart of a service association method in a service termination process according to Embodiment 3 of the present invention
  • FIG. 5 is a schematic diagram of a charging platform of a fifth embodiment of the present invention.
  • FIG. 6 is a schematic diagram of a service association system based on service nested charging according to Embodiment 6 of the present invention.
  • DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The embodiments described are a part of the embodiments of the invention, and not all of the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.
  • Embodiment 1 A service association method based on service nested charging. The flow of the method is shown in Figure 1.
  • S100 Obtain a request message that is sent by a service platform and carries key service information.
  • the existing charging request message carries the key service information. Therefore, the current charging request message can be used as the request message.
  • the request message may be other than the charging request message.
  • Other messages such as messages carrying key service information newly added to the present embodiment, and the like.
  • the request message is used as an example. However, the request message may also be other forms of the message. This embodiment does not limit the specific expression of the request message.
  • the current service platform needs to send an accounting request message to the charging platform during the service implementation process, and the executor of the S100 can intercept the charging request message sent by the service platform to the charging platform, that is, the service platform is online.
  • the charging request message sent by the charging service is transferred to the charging platform through the execution entity of S100.
  • the online charging service here may be a session type service for online charging or an event type service for online charging. Session-based services for online charging, such as call services or Internet traffic services. Event-based services such as short message service or multimedia message service.
  • the above online charging service can also be divided into a prepaid online charging service and a real-time crediting post-paid online charging service. That is to say, for the online charging service, the charging request message acquired by the executor of the S100 may be the charging request message of the prepaid online charging service, or may be the calculation of the postpaid online charging service of the real-time signaling. Fee request message.
  • the charging request message sent by the service platform to the charging platform may include: an accounting start request message and an accounting end request message.
  • the charging request message may further include: Billing intermediate request message.
  • the charging request message sent by the service platform to the charging platform may include: a charging event request message.
  • the current service platform does not need to send an accounting request message to the charging platform in the service implementation process, but only generates a bill when the service ends.
  • the service platform needs to be modified to enable the service platform.
  • the charging request message is sent to the execution body of S100.
  • the above offline charging service is usually a post-paid offline charging service of non-real-time credit control. That is to say, for the offline charging service, the charging request message acquired by the executor of the S100 is usually a charging request message of the post-paid offline charging service.
  • the singularity of the S100 is not required to be sent to the charging platform, and the charging request message is used for the charging identifier corresponding to the service platform request service. .
  • the charging request message in S100 may be a Credit Control Request (CCR) message, or may be a charging request message based on other protocols, such as a charging request message based on an operator's private protocol, etc.;
  • CCR Credit Control Request
  • the specific protocol used to limit the charging request message is not limited.
  • the executor of the S100 can identify the online charging service and the offline charging service according to the information carried in the charging request message, such as extending the field of the existing charging request message, so that the executor of the S100 can carry according to the field.
  • the information is identified by the online charging service and the offline charging service. This embodiment does not limit the specific implementation manner of identifying the online charging service and the offline charging service.
  • the charging identifier processing includes: searching for the service record information that matches the key service information carried in the request message in the stored service record information, and if there is matching service record information, obtaining the charging identifier in the matched service record information. If there is no matching transaction record information, the charging identifier is assigned.
  • the received charging request message is the first charging request message of the service, such as an accounting start request message (the charging start request message, such as a CCR message carrying Initial (initial) information, etc.
  • the fuzzy matching is performed according to the service attribute information carried in the first charging request message, and when there is the fuzzy matching service record information, the charging identifier in the matched service record information is obtained.
  • the charging identifier is assigned.
  • the executor of the S110 shall ensure that the charging identifier assigned to the online charging service is globally unique within a predetermined long period (eg, seven days).
  • the foregoing service attribute information is used to describe the service, and the content specifically included in the service attribute information may be set according to the service type of the triggering charging request message.
  • the service information information carried in the charging start request message may include: a current charging user terminal number, a calling number, a called number, and a call start time.
  • the service attribute information includes: the current charging user terminal number, the calling number, the called number, and the call start time
  • a specific example of the module matching is: if the current charging user terminal carried in the charging request message The number, the calling number, and the called number are the same as the current charging user terminal number, the calling number, and the called number in the stored service record information, and the call start time and the stored service record information in the charging request message
  • the call start time differs by a predetermined time interval (for example, 1 second), and it is determined that there is fuzzy matching transaction record information.
  • the received charging request message is not the first charging request message of the service, for example, the charging request message is a charging intermediate request message or an accounting end request message (accounting end request message)
  • the CCR message carrying the Termination information, etc. may be searched for the obtained charging identifier in the stored service record information according to the service identification information carried in the received charging request message.
  • the foregoing service identification information is used to uniquely identify a service that occurs by the user.
  • the content specifically included in the service identification information may be set according to the service type of the triggering charging request message, and a specific example: if the charging request message is a charging request triggered by a calling service (such as a prepaid calling service or a postpaid calling service)
  • the service identifier information carried in the foregoing charging intermediate request message or the charging end request message may be a session identifier. This embodiment does not limit the specific manifestation of the service identifier.
  • the service attribute information carried in the charging request message may be fuzzyly matched in the stored service record information, and the fuzzy information is present.
  • the service record information is matched, the charging identifier in the fuzzy matching service record information is obtained, and when there is no fuzzy matching service record information, the charging identifier is allocated.
  • the executive body of the S 110 should ensure that the charging identifier assigned to the 10,000-line charging service is globally unique within a predetermined long period.
  • the content specifically included in the service attribute information carried in the charging request message of the offline charging service may also be set according to the service type of the triggering charging request message.
  • the specific content included in the service record information stored in this embodiment is related to the service attribute information and/or the service identification information.
  • the stored service record information may specifically include a current subscription user terminal number, a calling number, a called number, a call start time, service identification information, and a charging identifier.
  • the stored service record information may not include the service identification information; for the event type service (such as a prepaid event type service or a postpaid event type service), the foregoing stored service record information is The service identification information may not be included, and the above call start time should be the specific service occurrence time.
  • This embodiment does not limit the content specifically included in the service attribute information, the service identification information, and the service record information.
  • the storage process of the foregoing service record information includes: an executive body of the S110 After receiving the first charging request message (such as the charging start request message) of the service sent by the service platform to the charging platform, and assigning the charging identifier, sending the charging start request message carrying the charging identifier to the charging platform.
  • the charging platform processes the received charging start request message, and returns a charging response message (such as a credit control response message, etc.) carrying the charging identifier to the service platform, and the execution entity of the S110 intercepts the meter sent by the charging platform.
  • the fee response message if the charging response message is a charging success response message, the executor of the S110 stores the service attribute information carried in the charging identifier and the charging start request message in the service record information.
  • the executor of the S110 may strip the charging identifier from the charging response message and send the charging identifier to the service platform.
  • the charging response message of the charging identifier is stripped to avoid the transformation of the service platform.
  • the executor of the S110 may also receive the charging platform after receiving the charging platform. After the charging successful charging response message returned by the request message, the charging identifier and the service attribute information carried in the charging start request message are stored in the service record information.
  • the foregoing process of storing the service record information includes: after receiving the charging request message (such as the charging start request message) of the service sent by the service platform, and performing the charging identifier, the executor of the S110
  • the allocated charging identifier and the service attribute information carried in the charging request message are stored in the service record information.
  • the service platform may send the charging request message only once.
  • the charging identifier is used by the charging platform to perform association charging for multiple services having the same charging identifier.
  • the receiving end of the request message is a charging platform.
  • the executor of the S120 sends an accounting request message carrying the charging identifier to the charging platform.
  • the receiving end of the request message is a service platform.
  • the executor of the S120 directly sends a charging response message carrying the charging identifier to the service platform.
  • the execution entity of the first embodiment can be set in the charging platform.
  • the executor is also set up independently of the billing platform, that is, between the service platform and the billing platform.
  • the foregoing embodiment 1 obtains the charging identifier from the matched service record information by matching the key service information carried in the request message in the stored service record information, or assigns the charging identifier when there is no matching service record information.
  • the plurality of services that are nested in the same manner can have the same charging identifier.
  • the charging platform can determine multiple associated services that are nested according to the charging identifier, so that the charging platform can flexibly adopt the service for the associated service. The cost corresponding to the configuration rule is charged, and finally the flexibility of the nested charging mode is improved.
  • the second embodiment of the present invention may be a charging platform, and the charging platform may be an online charging platform or an offline charging platform.
  • the process of this method is shown in Figure 2.
  • the S200 receives the message sent by the service association device, and stores the charging identifier and the charging data of the service carried in the message in the charging storage unit.
  • the message that is included in the online charging platform and includes the charging identifier and the charging data may be sent by the executor of the first embodiment, and the charging identifier and the charging data may be carried in the charging.
  • the online charging platform obtains the charging identifier and the charging data from the received charging request message.
  • the message that the offline charging platform receives the charging identifier and the charging data may be sent by the service platform, and the charging identifier and the charging data are carried in the bill, that is, the offline meter
  • the fee platform obtains the charging identifier and the charging data from the received bill.
  • the charging platform may determine a service configuration rule for multiple service selections having the same charging identifier according to the pre-stored service configuration rule.
  • Service configuration rules such as VPN services are associated with the number one multi-machine service. This embodiment does not limit the content specifically included in the pre-stored service configuration rule.
  • S220 Perform association charging on multiple services with the same charging identifier according to the rate and charging data corresponding to the service configuration rule, for example, charging the VPN service according to the preferential rate of the VPN service, according to the preferential service of the No. 1 multi-machine service. The rate is charged for the number one multi-machine service.
  • the charging platform may determine the rate corresponding to the service configuration rule of the multiple services having the same charging identifier according to the correspondence between the pre-stored service configuration rule and the rate. This embodiment does not limit the pre-stored service configuration rules and fees. The specific relationship of the rate correspondence and the specific implementation process of the billing platform for association billing according to the rate.
  • the charging platform can use the flexible charging method to charge the associated service, thereby improving the flexibility of the service nesting.
  • the charging identifiers that can be received by the charging platform in the foregoing Embodiment 2, and the multiple services that are nested in each other have the same charging identifier. Therefore, the charging platform can determine that the charging identifiers are nested according to the charging identifiers.
  • the associated service enables the billing platform to charge the associated service with the cost corresponding to the service configuration rule, and finally improves the flexibility of the service nested charging mode.
  • Embodiment 3 A service association method based on service nesting for a prepaid online charging service. The present embodiment will be described below with reference to Figs. 3A, 3B and 3C.
  • the switching center is the core network switching device.
  • the Service Switch Point (SSP) is the device that triggers the intelligent service.
  • the one-way AS (O) (the originating application server) is the No. 1 multi-service platform, iVPN ( O) (Virtual Private Network, start-end integrated virtual private network) is a VPN service platform, and Online Charging System (OCS) is a charging platform.
  • iVPN Virtual Private Network, start-end integrated virtual private network
  • OCS Online Charging System
  • the service association engine in this embodiment (that is, the service-based service association device in the following embodiment 4) is located between the service platform and the OCS, and the service association engine should ensure the Charging Identifier assigned to the service. CID) globally uniquely does not conflict within a predetermined long period, and the service association engine can identify the nested-based interrelated industry according to the information carried in the received request message. And ensure that the CIDs of multiple services based on nested interconnections are the same.
  • the prepaid user is set to sign the multi-machine service (ie, the one-number service) and the VPN service at the same time, and the multi-machine service, that is, the plurality of communication terminals, is externally embodied as a number, and the user can use the plurality of communication terminals to be flexible.
  • the VPN service means that the user can dial the group short number to implement the group call.
  • the VPN service platform sends a CCR message carrying an Initial, that is, a charging start request message, according to a Diameter Credit Control (DCC) protocol specification with the OCS, and the charging start request message can be used for the authentication pre- stay.
  • DCC Diameter Credit Control
  • the service association engine intercepts the CCR message carrying the Initial sent by the service platform to the OCS, and locally locates the service attribute information such as the current charging user terminal number, the calling number, the called number, and the call start time carried in the CCR message.
  • the fuzzy matching is performed in the stored service record information, and the fuzzy matching is allowed to be within 1 second, and the matching result may indicate whether the service has an associated service. If there is fuzzy matching service record information, the fuzzy matching service is obtained. Obtain the CID in the record information. If there is no fuzzy matching transaction record information, assign a new globally unique CID to the service. In S3, the business association engine assigns a new globally unique CID to the service since no associated service has occurred.
  • the service association engine carries the CID in the CCR message and sends the CCR message to the OCS.
  • the OCS searches for the locally stored charging information according to the CID in the CCR message.
  • the locally stored charging information includes CID and charging data, and the charging data may include service attribute information.
  • the result of this search of OCS can indicate whether the service is the first service of the user or the associated service associated with the first service. If the matching charging information is found, the current service is the associated service associated with the first service. If no matching charging information is found, the current service is the first service of the user. In S5, since no related service has occurred, the OCS determines that the current service is a user. The first business. The OCS determines the billing rate for the first service, and performs billing processing according to the billing rate, such as billing inverse processing.
  • the CID in the CCR message and the charging data in the CCR message are stored in the charging information, and the Credit Control Answer (CCA) carrying the CID is returned to the service platform. Message.
  • the service association After the service association receives the CCA message, and analyzes the result code in the CCA message as the charging success, the current business key information carried in the CID and the charging start request message is stored in the service record information, and the service correlation engine is used.
  • the CID information is stripped from the CCA message, and the CCA message stripped of the CID is sent to the VPN service platform.
  • the service association engine stores business key information such as SessionID, current billing user terminal number, calling number, called number, and call start time.
  • the VPN service platform instructs the SSP to perform call connection, and performs subsequent service monitoring processes according to the allocated duration information carried in the CCA message.
  • the SSP triggers the intelligent service to the multi-machine service platform again through the multi-service trigger mechanism.
  • the first multi-service service platform sends a CCR message carrying an Initial, that is, a charging start request message, according to a DCC protocol specification with the OCS, where the charging request message can be used for authentication reservation.
  • the service association engine intercepts the CCR message sent by the No. 1 multi-service service platform to the OCS.
  • the service association engine performs fuzzy matching on the locally stored service record information according to the service attribute information in the service key information such as the current charging user terminal number, the calling number, the called number, and the call start time carried in the CCR message. Matches such as allowing the call start time to differ by 1 second, etc. Since the associated service occurs, in S11, the service association engine is fuzzyly matched successfully, and the CID is obtained from the fuzzy matching service record information.
  • the service association engine carries the CID obtained by the fuzzy matching in the CCR message and sends the CID to the OCS.
  • the OCS searches for the locally stored charging information according to the CID in the CCR message.
  • the search result may indicate whether the current service is the first service of the user or the associated service associated with the first service. If the matching charging information is found, the current service is the associated service associated with the first service. If no matching charging information is found, the current service is the first service of the user. By The first service has already occurred in this embodiment. Therefore, in S13, the OCS determines that the current service is the associated service of the user.
  • the OCS determines a service configuration rule for the associated service, determines a charging rate according to the service configuration rule, and performs charging processing according to the charging rate, such as charging back calculation processing.
  • the CID and the current service key information in the CCR message are stored in the charging information, and the CCA message carrying the CID is returned to the service platform.
  • the service association information After receiving the CCA message, the service association information stores the current service key information carried in the CID and the CCR message in the service record information, and the service association extracts the CID information from the CCA message, and sends the CID information to the number one.
  • the multi-service service platform sends a CCA message stripped of the CID.
  • the business association engine stores business key information such as SessionID, current billing user terminal number, calling number, called number, and call start time.
  • the first multi-service service platform instructs the SSP to perform call connection, and performs a subsequent service monitoring process according to the allocated duration information carried in the CCA message.
  • Figure 3C shows the flow of the service association between the service association engine and the No. 1 multi-service service platform, the VPN service platform, and the OCS to implement the service association method of the No. 1 multi-machine service and the VPN service.
  • the S17 and the SSP send the intelligent signaling of the end of the service to the VPN service platform.
  • the VPN service platform sends a CCR message carrying the Termination, that is, the charging end request message, according to the DCC protocol specification with the OCS.
  • the service association engine intercepts the CCR message carrying the Termination sent by the VPN service platform to the OCS, and searches the locally stored service record information according to the session ID carried in the CCR message, and obtains the CID corresponding to the service according to the search result.
  • the service association engine carries the found CID in the CCR message, and sends a CCR message carrying the CID to the OCS.
  • the OCS searches for the locally stored charging information according to the CID carried in the CCR. If the number of the services that are related to each other is more than one, the OCS determines the multi-service configuration rule corresponding to the service, and according to the multi-service. Configure the corresponding rate and the billing data of the current VPN service.
  • the secondary VPN service is subject to preferential pricing deduction.
  • the OCS After successful deduction, the OCS returns a CCA message carrying the CID to the VPN service platform.
  • the service association engine intercepts the CCA message, and the service association engine strips the CID information from the CCA message, and sends a CC A message stripped of the CID to the VPN service platform.
  • the VPN service platform After receiving the CCA message, the VPN service platform normally ends the VPN call process.
  • the SSP sends the intelligent signaling of the end of the service to the multi-machine service platform.
  • the multi-service service platform No. 1 sends a CCR message carrying the Termination, that is, a charging end request message, according to the D C C protocol specification with the 0 C S.
  • the service association engine intercepts the CCR message carrying the Termination sent to the OCS by the multi-service service platform, and searches for the locally stored service record information according to the SessionID carried in the CCR message, and obtains the corresponding service according to the search result. CID.
  • the service association engine carries the found CID in the CCR message, and sends a CCR message carrying the CID to the OCS.
  • the OCS searches for the locally stored charging information according to the CID carried in the CCR. If the number of the related services is more than one, the multi-service configuration rule corresponding to the service is determined according to the multi-service. The corresponding rate specified by the configuration and the billing data of the No. 1 multi-machine will be used to deduct the preferential price for the No. 1 multi-machine.
  • the OCS After successful bidding, the OCS returns a CCA message carrying the CID to the multi-machine service platform.
  • the service association engine intercepts the CCA message, and the service association engine strips the CID information from the CCA message, and sends the CCA message stripped of the CID to the multi-machine service platform.
  • the first multi-service service platform After receiving the CCA message, the first multi-service service platform normally ends the current multi-machine call procedure.
  • the third embodiment needs to be specifically described.
  • the third embodiment is to trigger the VPN service first, and then trigger the first-number multi-machine service as an example.
  • the triggering sequence and the ending sequence of the two intelligent services may also be interchanged.
  • Embodiments do not limit the triggering order and ending order of multiple services that are associated with each other.
  • industry The service association engine may save the transaction record information for a predetermined period of time before deleting the transaction record information, and may not delete the service record information corresponding to the service immediately after the end of a service.
  • Embodiment 4 Service association device based on service nesting.
  • the device can be set in the billing platform or can be set independently of the billing platform.
  • the structure of the device is shown in Figure 4.
  • the apparatus in FIG. 4 includes: an acquisition module 400, a billing identifier processing module 420, and a first sending module 430.
  • the device may further include at least one of the storage module 410, the first storage control module 440, the second storage control module 450, and the second sending module 460.
  • the obtaining module 400 is configured to obtain a request message that is sent by the service platform and carries key service information.
  • the request message obtained by the obtaining module 400 may be an existing charging request message.
  • the request message acquired by the obtaining module 400 may also be a message other than the charging request message, as newly added for the embodiment. Carry messages with key business information, etc.
  • the current service platform needs to send an accounting request message to the charging platform during the service implementation process, and the obtaining module 400 can intercept the charging request message sent by the service platform to the charging platform, that is, the service platform is for online counting.
  • the charging request message sent by the fee service is transferred to the charging platform by the device in this embodiment.
  • the charging request message obtained by the obtaining module 400 may be a charging request message of a prepaid online charging service, or may be a charging request message of a real-time credited post-paid online charging service.
  • the type of the service that is specifically included in the online charging service, the content of the key service information, and the message specifically included in the charging request message are as described in the first embodiment, and will not be described in detail herein.
  • the current service platform does not need to send an accounting request message to the charging platform in the service implementation process, but only generates a bill when the service ends.
  • the service platform needs to be modified to enable the service platform.
  • the charging request message is sent, so that the obtaining module 400 can obtain the charging request message sent by the service platform.
  • the charging request message obtained by the obtaining module 400 may be a CCR message, or may be a charging request message based on other protocols, such as a charging request message based on an operator's private protocol, etc.
  • the specific protocol used by the billing request message may be a CCR message, or may be a charging request message based on other protocols, such as a charging request message based on an operator's private protocol, etc. The specific protocol used by the billing request message.
  • the obtaining module 400 can identify the online meter according to the information carried in the received charging request message.
  • the fee-based service and the offline charging service such as the field of the existing charging request message, may be used by the obtaining module 400 to identify the online charging service and the offline charging service according to the information carried in the field.
  • This embodiment does not limit the specific implementation manner in which the obtaining module 400 identifies the online charging service and the offline charging service.
  • the storage module 410 is configured to store service record information.
  • the specific content included in the service record information stored in the storage module 410 is related to the service attribute information and/or the service identification information.
  • the service record information stored in the storage module 410 may specifically include a current charging user terminal number, a calling number, a called number, a call start time, service identification information, and a charging identifier.
  • the service record information stored in the storage module 410 may not include the service identification information; for the event type service, the service record information stored in the storage module 410 may not include the service identification information, and
  • the call start time should be the time when the specific service occurs.
  • This embodiment does not limit the content specifically included in the service attribute information, the service identification information, and the service record information stored in the storage module 410.
  • the billing identifier processing module 420 is configured to search, in the stored service record information (such as the service record information stored in the storage module 410), the service record information that matches the key service information in the request message acquired by the obtaining module 400, if If there is matching service record information, the charging identifier in the matched service record information is obtained. If there is no matching service record information, the charging identifier is allocated.
  • the stored service record information such as the service record information stored in the storage module 410
  • the billing identifier processing module 420 includes at least one of a first processing sub-module 421, a second processing sub-module 422, and a third processing sub-module 423.
  • the first processing sub-module 421 may be based on the first charging request message.
  • the service attribute information carried in the service is fuzzy matched in the stored service record information (such as the service record information stored in the storage module 410).
  • the first processing sub-module 421 obtains the matched service record.
  • the charging identifier in the information when there is no fuzzy matching service record information, the first processing sub-module 421 allocates the charging identifier.
  • the first processing sub-module 421 should ensure that the charging identifier allocated for the online charging service is globally unique within a predetermined long period.
  • the service attribute information is used to describe the service, and the service attribute information specifically includes the content as described above. The description in the first example will not be described in detail herein.
  • the second processing sub-module 422 can search for the obtained charging identifier in the stored service record information (such as the service record information stored in the storage module 410) according to the service identification information carried in the charging request message received by the obtaining module 400.
  • the foregoing service identification information is used to uniquely identify a service that occurs by the user.
  • the content specifically included in the service identification information is as described in the first embodiment, and will not be described in detail herein.
  • the third processing sub-module 423 may perform fuzzy matching in the stored service record information according to the service attribute information carried in the charging request message. When the service record information is matched, the third processing sub-module 423 obtains the charging identifier in the matched service record information. When there is no matching service record information, the third processing sub-module 423 allocates the charging identifier. Similarly, the third processing sub-module 423 should ensure that the charging identifier assigned to the offline accounting service is globally unique within a predetermined long period. In addition, the content specifically included in the service attribute information carried in the charging request message of the offline charging service may also be set according to the service type of the triggering charging request message.
  • the first sending module 430 is configured to send, to the receiving end of the request message, the charging identifier and the information carried in the request message, where the charging identifier is used by the charging platform to perform association charging for multiple services having the same charging identifier.
  • the first sending module 430 may specifically include at least one of the first sending submodule 431 and the second sending submodule 432.
  • the first sending submodule 431 sends a charging request message carrying the charging identifier to the charging platform.
  • the second sending sub-module 432 can directly send the charging response message carrying the charging identifier to the service platform. Specifically, for the offline charging service, the second sending submodule 432 does not send the charging request message to the charging platform.
  • the first storage control module 440 is configured to: for the online charging service, the device shown in FIG. 4 receives the charging successful charging response message returned by the charging platform for the first charging request message of the online charging service (eg, After the credit control response message, etc., the billing identifier processing module 420 or the billing identifier processing module 420 searches the obtained billing identifier and the service key information carried in the billing request message in the service record information of the storage module 410. in.
  • the second storage control module 450 is configured to allocate, for the offline charging service, the charging identifier processing module 420 after the obtaining module 400 receives the charging request message (such as the charging start request message) sent by the service platform.
  • the fee identification processing module 420 searches for the service key information carried in the obtained charging identifier and the charging request message in the service record information of the storage module 410.
  • the second sending module 460 is configured to: for the online charging service, after the device shown in FIG. 4 receives the charging response message returned by the charging platform, strip the charging identifier from the charging response message, and send the charging identifier to the service platform.
  • the charging response message of the charging identifier is stripped.
  • the charging identifier processing module 420 in the foregoing fourth embodiment matches the key service information carried in the request message in the stored service record information, obtains the charging identifier from the matched service record information, or does not exist in the matching service.
  • the charging identifier is allocated, so that multiple services that are nested in each other can have the same charging identifier.
  • the charging platform can determine multiple associated services that are nested according to the charging identifier, thereby charging the platform.
  • the associated service can be flexibly charged according to the cost corresponding to the service configuration rule, and finally the flexibility of the service nested charging mode can be improved.
  • Embodiment 5 Billing platform.
  • the billing platform can be an online billing platform (such as OCS, etc.) or an offline billing platform.
  • the structure of the billing platform is as shown in Fig. 5.
  • the charging platform in FIG. 5 includes: a receiving module 500, a service configuration rule module 510, and an associated charging module 520.
  • the receiving module 500 is configured to receive the message sent by the service association device, and store the charging identifier and the charging data of the service carried in the message in the charging storage unit.
  • the charging identifier and the charging data received by the receiving module 500 may be sent by the executor of the first embodiment, and the charging identifier and the charging data may be carried in the charging request message.
  • the receiving module 500 can obtain the charging identifier and the charging data from the received charging request message.
  • the charging identifier and the charging data received by the receiving module 500 may be sent by the service platform, and the charging identifier and the charging data are carried in the bill, that is, the receiving module 500 can receive the The billing identifier and billing data are obtained in the bill.
  • the service configuration rule module 510 is configured to determine a service configuration rule corresponding to multiple services having the same charging identifier in the charging storage unit. If there are multiple services with the same charging identifier, it means that the multiple services are services that are related to each other due to business nesting.
  • the service configuration rule module 510 can determine a service configuration rule for a plurality of service selections having the same charging identifier according to the pre-stored service configuration rules.
  • the associated charging module 520 is configured to perform association charging for multiple services having the same charging identifier according to the rate corresponding to the service configuration rule determined by the service configuration rule module 510 and the charging data received by the receiving module 500.
  • the associated charging module 520 can store the corresponding relationship between the service configuration rule and the rate, and the associated charging module 520 can determine the rate according to the corresponding relationship. This embodiment does not limit the associated charging module 520 to determine the specific rate. And the specific implementation process of actual billing according to the specific rate.
  • the receiving module 500 in the foregoing embodiment 5 can receive the charging identifier and the charging data.
  • the service configuration rule module 510 can determine, according to the charging identifier, that the multiple services that are nested in each other have the same charging identifier.
  • the plurality of associated services that are nested with each other, and the service configuration rules corresponding to the multiple associated services are determined, so that the associated charging module 520 can charge the corresponding service with the corresponding cost of the service configuration rule, and finally improve the service insertion.
  • Embodiment 6 is a business association system based on business nesting.
  • the structure of the system is shown in Figure 6.
  • the system in FIG. 6 includes: a service correlation engine 610.
  • the service correlation engine 610 is connected to the service platform 600.
  • the system may further include: at least one of an online charging platform 620 and an offline charging platform 630.
  • only one service platform 600 is shown in FIG. 6, in the actual network, there may be multiple service platforms 600 connected to the service association engine 610.
  • the service platform 600 is configured to send a request message carrying key service information.
  • the request message sent by the service platform 600 may be an existing charging request message, of course, the service is flat.
  • the request message sent by the station 600 may also be a message other than the charging request message, such as a newly added message carrying key service information for the embodiment.
  • the existing service platform 600 may not be modified, that is, the service association engine 610 intercepts the service platform 600 and sends an accounting request message to the online charging platform 620.
  • the service platform 600 sends the charging request message to the online charging platform 620, which may be a charging request message of the prepaid online charging service, or may be a charging request message of the real-time crediting post-paid online charging service.
  • the information of the service type, the content of the key service information, and the message specifically included in the charging request message are as described in the first embodiment, and will not be described in detail herein.
  • the service platform 600 For the offline charging service, the service platform 600 needs to be modified to send an accounting request message, so that the service association engine 610 can receive the charging request message sent by the service platform 600. In addition, the service platform 600 can receive the charging response message returned by the service association engine 610 for the charging request message, where the charging response message carries the charging identifier.
  • the bill should include the billing identifier corresponding to the offline billing service.
  • the charging request message sent by the service platform 600 may be a CCR message, or may be a charging request message based on other protocols, such as a charging request message based on an operator's private protocol.
  • the embodiment does not limit the sending by the service platform 600.
  • the service association engine 610 is configured to obtain a request message sent by the service platform 600, and search for the service record information that matches the key service information in the request message in the stored service record information. If there is matching service record information, the service association is performed. The engine 610 obtains the charging identifier in the matched service record information. If there is no matching service record information, the service association engine 610 allocates the charging identifier, and the service association engine 610 sends the charging identifier and the request message to the receiving end of the request message. The information carried in the charging identifier is used by the charging platform to perform association charging for multiple services having the same charging identifier. The receiving end of the request message may be the online charging platform 620 or the service platform 600.
  • the service association engine 610 sends an accounting request message carrying the charging identifier to the online charging platform 620.
  • the service association engine 610 can directly send the charging response message carrying the charging identifier to the service platform 600.
  • Special instructions for offline billing services Yes, the service correlation engine 610 does not send a charging request message to the offline charging platform 630.
  • the specific content included in the service record information stored in the service association engine 610 is related to the service attribute information and/or the service identification information.
  • the service record information stored in the service association engine 610 may specifically include a current charging user terminal number, a calling number, a called number, a call start time, service identification information, and a charging identifier.
  • the service record information stored in the service association engine 610 may not include the service identification information.
  • the service record information stored in the service association engine 610 may not include the service.
  • Identification information, and the call start time should be the specific business occurrence time. This embodiment does not limit the content specifically included in the service attribute information, the service identification information, and the service record information stored in the service association engine 610.
  • the service association engine 610 may be configured according to the first charging request message.
  • the carried service attribute information is fuzzyly matched in the stored service record information.
  • the service association engine 610 obtains the charging identifier in the matched service record information, when there is no matching service record information.
  • the service association engine 610 allocates a charging identifier.
  • the service association engine 610 shall ensure that the charging identifier assigned to the online charging service is globally unique within a predetermined long period.
  • the service attribute information is used to describe the service, and the content of the service attribute information is as described in the first embodiment, and will not be described in detail herein.
  • the service association engine 610 can search for the obtained charging identifier in the stored service record information according to the service identification information carried in the received charging request message.
  • the foregoing service identification information is used to uniquely identify a service that occurs by the user.
  • the content specifically included in the service identification information is as described in the first embodiment, and will not be described in detail herein.
  • the service association engine 610 may perform fuzzy matching in the stored service record information according to the service attribute information carried in the charging request message.
  • the business association engine 610 obtains The charging identifier in the matched service record information, when there is no matching service record information, the service association engine 610 allocates the charging identifier.
  • the service association engine 610 should ensure that the charging identifier assigned to the offline charging service is globally unique within a predetermined long period.
  • the content specifically included in the service attribute information carried in the charging request message of the offline charging service may also be set according to the service type of the triggering charging request message.
  • the service association engine 610 After receiving the charging successful charging response message (such as a credit control response message, etc.) returned by the online charging platform 620 for the first charging request message of the online charging service, the service association engine 610 will The service key information carried in the charging identifier and the charging request message that is allocated or searched for the first accounting request message is stored in the service record information. In addition, after receiving the charging response message returned by the charging platform, the service association engine 610 strips the charging identifier from the charging response message, and sends a charging response message stripped of the charging identifier to the service platform 600.
  • the charging successful charging response message such as a credit control response message, etc.
  • the service association engine 610 allocates or searches for the charging identifier and the meter for the charging request message.
  • the business key information carried in the fee request message is stored in the service record information.
  • the online charging platform 620 is configured to receive the message sent by the service association engine 610, store the charging identifier and the charging data carried in the message in the charging storage unit, and determine that the charging unit has the same charging identifier. For the service configuration rule of the service, the online charging platform 620 performs association charging for multiple services having the same charging identifier according to the rate corresponding to the service configuration rule and the received charging data.
  • the offline charging platform 630 is configured to receive a bill containing the billing identifier and the billing data sent by the service platform 600, and determine a service configuration rule of the plurality of bills having the same billing identifier, according to the service configuration rule. The rate and the received charging data are associated and charged for a plurality of services having the same charging identifier.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Telephonic Communication Services (AREA)

Description

基于业务嵌套计费的业务关联方法、 装置和系统 本申请要求于 2010 年 06 月 13 日提交中国专利局、 申请号为 201010204847.3、 发明名称为 "基于业务嵌套计费的业务关联方法、 装置和系 统" 的中国专利申请的优先权， 其全部内容通过引用结合在本申请中。 技术领域
本发明涉及网络通讯技术领域， 具体涉及业务嵌套计费技术。 背景技术
目前的电信综合运营商为用户提供的业务种类日渐丰富。 电信综合运营商 允许用户同时签约多种业务， 如允许用户同时签约一号多机业务和 VPN业务。 一号多机业务即多个通信终端对外体现为一个号码， 用户可以使用这多个通信 终端灵活的实现呼叫。 VPN业务即用户可以拨打集团短号实现集团呼叫。
在用户同时签约了多种业务的情况下， 会产生业务嵌套， 即用户利用通信 终端进行的一次通信可能会同时触发多种业务， 如通信终端 1和通信终端 2签约 了一号多机业务且对外体现为通信终端 1的号码， 通信终端 2签约了 VPN业务， 用户在利用通信终端 2拨打集团短号时， 首先触发一号多机业务， 然后， 又触 发 VPN业务， 一号多机业务将主叫号码修改为通信终端 1的号码， VPN业务将 被叫的集团短号翻译为集团的长号进行呼叫接续。
在实现本发明的过程中， 发明人发现： 不同业务对应的业务平台不同， 由 于业务平台并不能够获知业务嵌套， 因此， 每个业务平台都会在业务实现过程 中发起独立的计费请求流程。 由于计费平台并不能够获知业务嵌套， 因此， 计 费平台会针对每个计费请求流程分别执行独立的计费流程。 这样， 当用户的一 次通信触发多种业务时， 计费平台会对被触发的多种业务分别进行计费， 从而 使一次通信的计费结果为对多种业务分别进行计费的总和。 现有的这种计费方 式不灵活， 不能满足业务嵌套的多种计费需求。 发明内容
本发明实施方式提供的基于业务嵌套计费的业务关联方法、 装置和系统， 可将相互嵌套的多个业务关联起来， 以提高业务嵌套的计费方式的灵活性。
本发明实施方式提供的基于业务嵌套计费的业务关联方法， 包括： 获取业务平台发送的携带有关键业务信息的请求消息；
根据所述请求消息进行计费标识处理得到计费标识， 包括： 在存储的业务 记录信息中查找与所述关键业务信息匹配的业务记录信息， 如果存在匹配的业 务记录信息， 则获取匹配的业务记录信息中的计费标识， 如果不存在匹配的业 务记录信息， 则分配计费标识； 所述计费标识用于计费平台对具有相同计费标 识的多个业务进行关联计费；
向所述请求消息的接收端发送计费标识和所述请求消息中携带的信息。 本发明实施方式提供的基于业务嵌套的业务关联计费方法， 包括： 计费平台接收业务关联装置发送来的消息， 将所述消息中的业务的计费标 识和计费数据存储于计费存储单元中；
确定所述计费存储单元中具有相同计费标识的多个业务的业务配置规则； 根据所述业务配置规则对应的费率和所述计费数据对具有相同计费标识 的多个业务进行关联计费。
本发明实施方式提供的基于业务嵌套计费的业务关联装置， 包括： 获取模块， 获取业务平台发送的携带有关键业务信息的请求消息； 计费标识处理模块， 用于在存储的业务记录信息中查找与所述关键业务信 息匹配的业务记录信息， 如果存在匹配的业务记录信息， 则获取匹配的业务记 录信息中的计费标识， 如果不存在匹配的业务记录信息， 则分配计费标识， 所 述计费标识用于计费平台对具有相同计费标识的多个业务进行关联计费； 第一发送模块， 用于向所述请求消息的接收端发送计费标识和所述请求消 息中携带的信息。
本发明实施方式提供的计费平台， 包括：
接收模块， 用于接收业务关联装置发送来的消息， 将所述消息中的业务的 计费标识和计费数据存储于计费存储单元中；
业务配置规则模块， 用于确定所述计费存储单元中具有相同计费标识的多 个业务的业务配置规则；
关联计费模块， 用于根据所述业务配置规则对应的费率和所述计费数据对 具有相同计费标识的多个业务进行关联计费。
本发明实施方式提供的基于业务嵌套计费的业务关联系统， 包括： 与业务 平台连接的业务关联引擎；
业务平台， 用于发送携带有关键业务信息的请求消息；
业务关联引擎， 用于获取业务平台发送的所述请求消息， 在存储的业务记 录信息中查找与所述关键业务信息匹配的业务记录信息， 如果存在匹配的业务 记录信息， 则获取匹配的业务记录信息中的计费标识， 如果不存在匹配的业务 记录信息， 则分配计费标识， 向所述请求消息的接收端发送计费标识和所述请 求消息中携带的信息， 所述计费标识用于计费平台对具有相同计费标识的多个 业务进行关联计费。
通过上述技术方案的描述可知， 通过将请求消息中携带的关键业务信息在 存储的业务记录信息中匹配， 从匹配的业务记录信息中获得计费标识， 或者在 不存在匹配的业务记录信息时分配计费标识， 使相互嵌套的多个业务可以拥有 相同的计费标识； 这样， 计费平台可以根据该计费标识确定出相互嵌套的多个 关联业务， 从而计费平台可以对关联业务灵活的采用业务配置规则对应的费用 进行计费， 最终能够提高业务嵌套的计费方式的灵活性。 附图说明 为了更清楚地说明本发明实施例或现有技术中的技术方案， 下面将对实施 例或现有技术描述中所需要使用的附图作简单地介绍， 显而易见地， 下面描述 中的附图仅仅是本发明的一些实施例， 对于本领域普通技术人员来讲， 在不付 出创造性劳动的前提下， 还可以根据这些附图获得其他的附图。
图 1是本发明实施例一的基于业务嵌套计费的业务关联方法流程图； 图 2是本发明实施例二的基于业务嵌套的业务关联计费方法流程图； 图 3A是本发明实施例三的网络适用环境示意图；
图 3B是本发明实施例三的业务触发过程中的业务关联方法流程图； 图 3C是本发明实施例三的业务结束过程中的业务关联方法流程图； 图 4是本发明实施例四的基于业务嵌套计费的业务关联装置示意图； 图 5是本发明实施例五的计费平台示意图；
图 6是本发明实施例六的基于业务嵌套计费的业务关联系统示意图。 具体实施方式 述的实施例是本发明一部分实施例， 而不是全部的实施例。 基于本发明中的实 施例， 本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实 施例， 都属于本发明保护的范围。
实施例一、 基于业务嵌套计费的业务关联方法。 该方法的流程如附图 1所 示。
图 1中， S100、 获取业务平台发送的携带有关键业务信息的请求消息。 由于现有的计费请求消息中携带有关键业务信息， 因此， 本实施例可以利 用现有的计费请求消息作为上述请求消息， 当然， 上述请求消息也可以为除计 费请求消息之外的其它消息， 如针对本实施例而新增加的携带有关键业务信息 的消息等。 虽然下面主要以计费请求消息为请求消息为例对各实施例进行了详 细说明， 但是， 毋庸置疑的， 请求消息也可以为其它形式的消息， 本实施例不 限制请求消息的具体表现形式。 针对在线计费业务， 目前的业务平台需要在业务实现过程中向计费平台发 送计费请求消息， S100的执行主体可以截获业务平台向计费平台发送的计费请 求消息， 即业务平台针对在线计费业务发送的计费请求消息通过 S100的执行主 体中转至计费平台。 这里的在线计费业务可以为在线计费的会话型业务， 也可 以为在线计费的事件型业务。 在线计费的会话型业务如呼叫业务或者上网流量 业务等。 在线计费的事件型业务如短消息业务或者多媒体消息业务等。 上述在 线计费业务还可以被划分为预付费在线计费业务和实时信控的后付费在线计 费业务。 也就是说， 针对在线计费业务， S100的执行主体获取到的计费请求消 息可以是预付费在线计费业务的计费请求消息， 也可以是实时信控的后付费在 线计费业务的计费请求消息。
对于在线计费的会话型业务来说， 业务平台发送至计费平台的计费请求消 息可以包括： 计费开始请求消息和计费结束请求消息， 可选的， 计费请求消息 还可以包括： 计费中间请求消息。
对于在线计费的事件型业务来说， 业务平台发送至计费平台的计费请求消 息可以包括： 计费事件请求消息。
针对离线计费业务， 目前的业务平台不需要在业务实现过程中向计费平台 发送计费请求消息， 而只在业务结束时生成话单， 本实施例需要对业务平台进 行改造， 使业务平台向 S100的执行主体发送计费请求消息。 上述离线计费业务 通常为非实时信控的后付费离线计费业务。也就是说，针对离线计费业务， S100 的执行主体获取到的计费请求消息通常是后付费离线计费业务的计费请求消 息。 针对离线计费业务需要特别说明的是， S100的执行主体可以不将业务平台 发送来的计费请求消息发送至计费平台， 该计费请求消息主要用于业务平台请 求业务对应的计费标识。
S 100中的计费请求消息具体可以是 Credit Control Request (信用控制请求， CCR )消息， 也可以是基于其它协议的计费请求消息， 如基于运营商私有协议 的计费请求消息等； 本实施例不限制计费请求消息所采用的具体协议， 也不限 制触发业务平台发送计费请求消息的业务的具体类型等。 另外， S100的执行主 体可以根据计费请求消息中携带的信息识别出在线计费业务和离线计费业务， 如扩展现有的计费请求消息的字段， 使 S100的执行主体可以根据该字段携带的 信息进行在线计费业务和离线计费业务的识别。 本实施例不限制识别在线计费 业务和离线计费业务的具体实现方式。
S110、 计费标识处理。 该计费标识处理包括： 在存储的业务记录信息中查 找与请求消息中携带的关键业务信息匹配的业务记录信息， 如果存在匹配的业 务记录信息， 则获取匹配的业务记录信息中的计费标识， 如果不存在匹配的业 务记录信息， 则分配计费标识。
针对在线计费业务来说， 如果接收到的计费请求消息为该业务的首次计费 请求消息， 如计费开始请求消息（计费开始请求消息如携带有 Initial (初始）信 息的 CCR消息等） ， 则可以根据首次计费请求消息中携带的业务属性信息在存 储的业务记录信息中进行模糊匹配， 在存在模糊匹配的业务记录信息时， 获取 匹配的业务记录信息中的计费标识， 在不存在模糊匹配的业务记录信息时， 分 配计费标识。 S110的执行主体应保证为本次在线计费业务分配的计费标识在预 定长周期（如七天） 内全局唯一。 上述业务属性信息用于描述业务， 业务属性 信息具体包括的内容可以根据触发计费请求消息的业务种类来设置， 一个具体 的例子：如果计费请求消息为呼叫业务（如预付费呼叫业务或后付费呼叫业务） 触发的计费请求消息， 则上述计费开始请求消息中携带的业务属性信息可以包 括： 当前计费用户终端号码、 主叫号码、 被叫号码和呼叫开始时间等。
在业务属性信息包括： 当前计费用户终端号码、 主叫号码、 被叫号码和呼 叫开始时间的情况下， 模块匹配的一个具体的例子为： 如果计费请求消息中携 带的当前计费用户终端号码、 主叫号码和被叫号码与存储的业务记录信息中的 当前计费用户终端号码、 主叫号码和被叫号码相同， 且计费请求消息中的呼叫 开始时间与存储的业务记录信息中的呼叫开始时间相差预定时间间隔 （如 1 秒） ， 则确定存在模糊匹配的业务记录信息。 针对在线计费业务来说， 如果接收到的计费请求消息不为该业务的首次计 费请求消息， 如计费请求消息为计费中间请求消息或者计费结束请求消息（计 费结束请求消息如携带有 Termination (终结）信息的 CCR消息等） ， 则可以根 据接收到的计费请求消息中携带的业务标识信息在存储的业务记录信息中查 找获得计费标识。 上述业务标识信息用于唯一标识用户发生的一次业务。 业务 标识信息具体包括的内容可以根据触发计费请求消息的业务种类来设置， 一个 具体的例子： 如果计费请求消息为呼叫业务（如预付费呼叫业务或后付费呼叫 业务）触发的计费请求消息， 则上述计费中间请求消息或者计费结束请求消息 中携带的业务标识信息可以为会话标识。 本实施例不限制业务标识的具体表现 形式。
针对离线计费业务来说， 如果接收到计费请求消息 （如计费开始请求消 息） ， 则可以根据计费请求消息中携带的业务属性信息在存储的业务记录信息 中模糊匹配， 在存在模糊匹配的业务记录信息时， 获取模糊匹配的业务记录信 息中的计费标识， 在不存在模糊匹配的业务记录信息时， 分配计费标识。 同样 的， S 110的执行主体应保证为本次萬线计费业务分配的计费标识在预定长周期 内全局唯一。 另外， 离线计费业务的计费请求消息中携带的业务属性信息具体 包括的内容同样可以根据触发计费请求消息的业务种类来设置。
本实施例中存储的业务记录信息包括的具体内容与业务属性信息和 /或业 务标识信息相关。 一个具体的例子： 存储的业务记录信息具体可以包括当前计 费用户终端号码、 主叫号码、 被叫号码、 呼叫开始时间、 业务标识信息和计费 标识等。 明显的， 对于离线计费呼叫业务， 上述存储的业务记录信息中可以不 包括业务标识信息； 对于事件型业务（如预付费事件型业务或者后付费事件型 业务） ， 上述存储的业务记录信息中可以不包括业务标识信息， 且上述呼叫开 始时间应该为具体业务发生时间。 本实施例不限制业务属性信息、 业务标识信 息和业务记录信息具体包括的内容。
针对在线计费业务， 上述业务记录信息的存储过程包括： S110的执行主体 在接收到业务平台向计费平台发送的业务的首次计费请求消息（如计费开始请 求消息）且分配了计费标识后， 向计费平台发送携带有计费标识的计费开始请 求消息， 计费平台对接收到计费开始请求消息进行处理， 并向业务平台返回携 带有计费标识的计费应答消息（如信用控制应答消息等） ， S110的执行主体截 获计费平台发送的计费应答消息， 如果计费应答消息为计费成功的计费应答消 息， 则 S110的执行主体将计费标识和计费开始请求消息中携带的业务属性信息 存储到业务记录信息中。 需要说明的是， 在 S110的执行主体接收到计费平台返 回的针对计费请求消息的计费应答消息后， S110的执行主体可以从计费应答消 息中剥离计费标识， 并向业务平台发送剥离了计费标识的计费应答消息， 以避 免业务平台的改造。 另外， 如果 S110的执行主体在接收到业务平台发送的业务 的首次计费请求消息且从业务记录信息中获得了计费标识， 则 S110的执行主体 也可以在接收到计费平台对该计费请求消息返回的计费成功的计费应答消息 后， 将计费标识和该计费开始请求消息中携带的业务属性信息存储到业务记录 信息中。
针对离线计费业务， 上述业务记录信息的存储过程包括： S110的执行主体 在接收到业务平台发送的业务的计费请求消息（如计费开始请求消息）且分配 了计费标识后， 将该分配的计费标识和该计费请求消息中携带的业务属性信息 存储到业务记录信息中。 需要说明的是， 针对一个离线计费业务， 业务平台可 以只发送一次计费请求消息。
S120、 向请求消息的接收端发送计费标识和请求消息中携带的信息。 这里 的计费标识用于计费平台对具有相同计费标识的多个业务进行关联计费。
针对在线计费业务， 请求消息的接收端为计费平台， 如 S120的执行主体向 计费平台发送携带有计费标识的计费请求消息。
针对离线计费业务， 请求消息的接收端为业务平台， 如 S120的执行主体直 接向业务平台发送携带有计费标识的计费应答消息。
针对实施例一需要说明的是， 实施例一的执行主体可以设置于计费平台 中， 即与计费平台合设； 该执行主体也可以独立于计费平台设置， 即设置于业 务平台和计费平台之间。
上述实施例一通过将请求消息中携带的关键业务信息在存储的业务记录 信息中匹配， 从匹配的业务记录信息中获得计费标识， 或者在不存在匹配的业 务记录信息时分配计费标识， 使相互嵌套的多个业务可以拥有相同的计费标 识； 这样， 计费平台可以根据该计费标识确定出相互嵌套的多个关联业务， 从 而计费平台可以对关联业务灵活的采用业务配置规则对应的费用进行计费， 最 终能够提高业务嵌套的计费方式的灵活性。
实施例二、 基于业务嵌套的业务关联计费方法， 本实施例的执行主体可以 为计费平台， 该计费平台可以为在线计费平台， 也可以为离线计费平台。 该方 法的流程如附图 2所示。
图 2中， S200、 接收业务关联装置发送来的消息， 将消息中携带的业务的 计费标识和计费数据存储于计费存储单元中。
针对在线计费平台来说， 在线计费平台接收到的包含有计费标识和计费数 据的消息可以是实施例一的执行主体发送的， 且计费标识和计费数据可以携带 在计费请求消息中， 即在线计费平台从接收到的计费请求消息中获取计费标识 和计费数据。
针对离线计费平台来说， 离线计费平台接收到的包含有计费标识和计费数 据的消息可以是业务平台发送的， 且计费标识和计费数据携带在话单中， 即离 线计费平台从接收到的话单中获取计费标识和计费数据。
S210、 确定计费存储单元中具有相同计费标识的多个业务的业务配置规 则。
如果有多个业务具有相同的计费标识， 则说明这多个业务为由于业务嵌套 而相互关联的业务。 计费平台可以根据预先存储的业务配置规则为具有相同计 费标识的多个业务选择确定出业务配置规则。 业务配置规则如 VPN业务与一号 多机业务相关联。 本实施例不限制预先存储的业务配置规则具体包括的内容。 S220、 根据业务配置规则对应的费率和计费数据对具有相同计费标识的多 个业务进行关联计费， 如按照 VPN业务优惠费率对 VPN业务进行计费， 按照一 号多机业务优惠费率对一号多机业务进行计费等。 计费平台可根据预先存储的 业务配置规则和费率的对应关系确定出具有相同计费标识的多个业务的业务 配置规则对应的费率， 本实施例不限制预先存储的业务配置规则和费率的对应 关系具体包括的内容、 以及计费平台根据费率进行关联计费的具体实现过程。
由于业务配置规则对应的费率是针对相互关联的业务设置的， 因此， 计费 平台可以对关联业务采用灵活的计费方式进行计费， 从而提高了业务嵌套的计 费方式灵活性。
由于上述实施例二中计费平台可以接收到的计费标识， 且相互嵌套的多个 业务拥有相同的计费标识； 因此， 计费平台可以根据该计费标识确定出相互嵌 套的多个关联业务， 从而计费平台可以对关联业务灵活的采用业务配置规则对 应的费用进行计费， 最终提高了业务嵌套的计费方式的灵活性。
实施例三、 针对预付费在线计费业务， 基于业务嵌套的业务关联方法。 下 面结合附图 3A、 附图 3B和附图 3C对本实施例进行说明。
图 3 A中， Mobile Switching Centre/Gateway Mobile Switching Center (移动 交换中心 /网关移动交换中心， MSC/GMSC ) 、 MSC(O) (始呼端移动交换中心） 和 MSC(T) (终呼端移动交换中心） 为核心网交换设备， Service Switch Point (业务交换点， SSP )为触发智能业务的设备， 一号通 AS(O) (始呼端应用服务 器）为一号多机业务平台， iVPN(O) ( Virtual Private Network， 始呼端综合虚拟 专用网络）为 VPN业务平台， Online Charging System (在线计费系统， OCS ) 为计费平台。
本实施例中的业务关联引擎（即下述实施例四中的基于业务嵌套的业务关 联装置）位于业务平台与 OCS之间，业务关联引擎应保证为业务分配的 Charging Identifier (计费标识， CID )在预定长周期内全局唯一不沖突， 且业务关联引 擎能够根据接收到的请求消息中携带的信息识别出基于嵌套的相互关联的业 务， 并保证基于嵌套的相互关联的多个业务的 CID相同。
设定预付费用户同时签约了一号多机业务（即一号通业务）和 VPN业务， 一号多机业务即多个通信终端对外体现为一个号码， 用户可以使用这多个通信 终端灵活的实现呼叫。 VPN业务即用户可以拨打集团短号实现集团呼叫。
用户发起呼叫， 业务关联引擎与一号多机业务平台、 VPN业务平台和 OCS 之间进行消息交互以实现一号多机业务（即一号通业务）和 VPN业务的业务关 联方法的流程如附图 3B所示：
图 3B中， Sl、 用户发起呼叫， SSP触发智能业务到 VPN业务平台。
52、 VPN业务平台根据与 OCS之间的 Diameter Credit Control ( Diameter信 用控制， DCC )协议规范发送携带有 Initial的 CCR消息， 即计费开始请求消息， 该计费开始请求消息可以用于鉴权预留。
53、业务关联引擎拦截业务平台发送给 OCS的携带有 Initial的 CCR消息， 并 根据 CCR消息中携带的当前计费用户终端号码、 主叫号码、 被叫号码和呼叫开 始时间等业务属性信息在本地存储的业务记录信息中进行模糊匹配， 模糊匹配 如允许呼叫开始时间相差 1秒内等， 匹配结果可以表示出该业务是否有关联业 务， 如果存在模糊匹配的业务记录信息， 则从模糊匹配的业务记录信息中获取 CID, 如果不存在模糊匹配的业务记录信息， 则为该业务分配一个新的全局唯 一的 CID。 在 S3中， 由于还没有关联业务发生， 因此， 业务关联引擎为该业务 分配了一个新的全局唯一的 CID。
54、 业务关联引擎将 CID携带在 CCR消息中， 并向 OCS发送该 CCR消息。
55、 OCS根据 CCR消息中的 CID在本地存储的计费信息中查找， 本地存储 的计费信息包括 CID和计费数据， 计费数据可以包括业务属性信息。 OCS的本 次查找结果可以表示出本次业务是用户的首次业务还是与首次业务相关联的 关联业务。 如果查找到匹配的计费信息， 则说明本次业务是与首次业务相关联 的关联业务， 如果没有查找到匹配的计费信息， 则说明本次业务是用户的首次 业务。 在 S5中， 由于还没有关联业务发生， 因此， OCS判断出本次业务为用户 的首次业务。 OCS为首次业务确定计费费率，并根据该计费费率进行计费处理， 如计费反算处理等。
56、 OCS鉴权预留通过后， 将 CCR消息中的 CID和 CCR消息中的计费数据 存储到计费信息中， 并向业务平台返回携带有 CID的 Credit Control Answer (信 用控制应答， CCA ) 消息。
57、 业务关联引拏接收到 CCA消息后， 分析 CCA消息中的结果码为计费成 功， 则将 CID和计费开始请求消息中携带的当前业务关键信息存储到业务记录 信息中， 业务关联引擎从 CCA消息中剥离 CID信息， 并向 VPN业务平台发送剥 离了 CID的 CCA消息。 业务关联引擎存储业务关键信息如 SessionID、 当前计费 用户终端号码、 主叫号码、 被叫号码和呼叫开始时间等。
58、 VPN业务平台指示 SSP进行呼叫接续， 并根据 CCA消息中携带的分配 时长信息进行后继的业务监控流程。
59、 SSP通过多业务触发机制再次触发智能业务到一号多机业务平台。
510、 一号多机业务平台根据与 OCS之间的 DCC协议规范发送携带有 Initial 的 CCR消息， 即计费开始请求消息， 该计费请求消息可以用于鉴权预留。
511、 业务关联引擎拦截一号多机业务平台向 OCS发送的 CCR消息。 业务 关联引擎根据 CCR消息中携带的当前计费用户终端号码、 主叫号码、 被叫号码 和呼叫开始时间等业务关键信息中的业务属性信息在本地存储的业务记录信 息中进行模糊匹配， 该模糊匹配如允许呼叫开始时间相差 1秒内等。 由于已经 有关联业务发生， 因此， 在 S11中， 业务关联引擎模糊匹配成功， 从模糊匹配 的业务记录信息中获取 CID。
512、业务关联引擎将模糊匹配获得的 CID携带在 CCR消息中，向 OCS发送。
513、 OCS根据 CCR消息中的 CID在本地存储的计费信息中查找， 该查找结 果可以表示出本次业务是用户的首次业务还是与首次业务相关联的关联业务。 如果查找到匹配的计费信息， 则说明本次业务是与首次业务相关联的关联业 务， 如果没有查找到匹配的计费信息， 则说明本次业务是用户的首次业务。 由 于本实施例中已经有首次业务发生， 因此， 在 S13中， OCS判断出本次业务为 用户的关联业务。 OCS为关联业务确定业务配置规则， 根据该业务配置规则确 定计费费率， 并根据该计费费率进行计费处理， 如计费反算处理等。
514、 OCS鉴权预留通过后， 将 CCR消息中的 CID和当前业务关键信息存储 到计费信息中， 并向业务平台返回携带有 CID的 CCA消息。
515、 业务关联引拏接收到 CCA消息后， 将查找到的 CID和 CCR消息中携带 的当前业务关键信息存储到业务记录信息中， 业务关联引拏从 CCA消息中剥离 CID信息， 并向一号多机业务平台发送剥离了 CID的 CCA消息。 业务关联引擎 存储的业务关键信息如 SessionID、 当前计费用户终端号码、 主叫号码、 被叫号 码和呼叫开始时间等。
516、 一号多机业务平台指示 SSP进行呼叫接续， 并根据 CCA消息中携带的 分配时长信息进行后继的业务监控流程。
用户结束呼叫， 业务关联引擎与一号多机业务平台、 VPN业务平台和 OCS 之间进行消息交互以实现一号多机业务和 VPN业务的业务关联方法的流程如 附图 3C所示：
图 3C中， S17、 SSP向 VPN业务平台发送业务结束的智能信令。
S18、 VPN业务平台根据与 OCS之间的 DCC协议规范发送携带有 Termination的 CCR消息， 即计费结束请求消息。
519、 业务关联引擎拦截 VPN业务平台发送给 OCS的携带有 Termination的 CCR消息， 并根据 CCR消息中携带的 SessionID在本地存储的业务记录信息中查 找， 根据查找结果可以获得该业务对应的 CID。
520、 业务关联引擎将查找到的 CID携带在 CCR消息中， 并向 OCS发送携带 有 CID的 CCR消息。
521、 OCS根据 CCR中携带的 CID在本地存储的计费信息中查找， 如果查找 确定相互关联的业务的数量多于一个， 则确定相互关联的业务对应的多业务配 置规则， 并根据该多业务配置规定对应的费率和本次 VPN业务的计费数据对本 次 VPN业务进行优惠批价扣费。
522、 OCS在批价扣费成功后，向 VPN业务平台返回携带有 CID的 CCA消息。
523、业务关联引擎截获该 CCA消息， 业务关联引擎从 CCA消息中剥离 CID 信息， 并向 VPN业务平台发送剥离了 CID的 CC A消息。
524、 VPN业务平台接收到 CCA消息后， 正常结束本次 VPN呼叫流程。
525、 SSP向一号多机业务平台发送业务结束的智能信令。
S 26、 一号多机业务平台根据与 0 C S之间的 D C C协议规范发送携带有 Termination的 CCR消息， 即计费结束请求消息。
527、业务关联引擎拦截一号多机业务平台发送给 OCS的携带有 Termination 的 CCR消息， 并根据 CCR消息中携带的 SessionID在本地存储的业务记录信息中 查找， 根据查找结果可以获得该业务对应的 CID。
528、 业务关联引擎将查找到的 CID携带在 CCR消息中， 并向 OCS发送携带 有 CID的 CCR消息。
529、 OCS根据 CCR中携带的 CID在本地存储的计费信息中查找， 如果查找 确定相互关联的业务的数量多于一个， 则确定相互关联的业务对应的多业务配 置规则， 并根据该多业务配置规定对应的费率和本次一号多机的计费数据对本 次一号多机进行优惠批价扣费。
530、 OCS在批价扣费成功后， 向一号多机业务平台返回携带有 CID的 CCA 消息。
531、业务关联引擎截获该 CCA消息， 业务关联引擎从 CCA消息中剥离 CID 信息， 并向一号多机业务平台发送剥离了 CID的 CCA消息。
532、 一号多机业务平台接收到 CCA消息后， 正常结束本次一号多机呼叫 流程。
针对实施例三需要特别说明的是， 实施例三是以先触发 VPN业务， 再触发 一号多机业务为例进行说明的， 这两个智能业务的触发顺序和结束顺序也可以 互换， 本实施例不限制相互关联的多个业务的触发顺序和结束顺序。 另外， 业 务关联引擎可以将业务记录信息保存预定长时间之后再进行删除处理， 而不能 在一个业务结束后立即删除该业务对应的业务记录信息。
实施例四、基于业务嵌套的业务关联装置。该装置可以设置于计费平台中， 也可以独立于计费平台设置。 该装置的结构如附图 4所示。
图 4中的装置包括： 获取模块 400、 计费标识处理模块 420和第一发送模块 430。 可选的， 该装置还可以包括存储模块 410、 第一存储控制模块 440、 第二 存储控制模块 450和第二发送模块 460中的至少一个。
获取模块 400， 获取业务平台发送的携带有关键业务信息的请求消息。 获 取模块 400获取到的请求消息可以为现有的计费请求消息， 当然， 获取模块 400 获取到的请求消息也可以为除计费请求消息之外的其它消息， 如针对本实施例 而新增加的携带有关键业务信息的消息等。
针对在线计费业务， 目前的业务平台需要在业务实现过程中向计费平台发 送计费请求消息， 获取模块 400可以截获业务平台向计费平台发送的计费请求 消息， 即业务平台针对在线计费业务发送的计费请求消息通过本实施例中的装 置中转至计费平台。 获取模块 400获取到的计费请求消息可以是预付费在线计 费业务的计费请求消息， 也可以是实时信控的后付费在线计费业务的计费请求 消息。 在线计费业务具体包括的业务类型、 关键业务信息包括的内容、 以及计 费请求消息具体包括的消息等如上述实施例一的描述， 在此不再详细说明。
针对离线计费业务， 目前的业务平台不需要在业务实现过程中向计费平台 发送计费请求消息， 而只在业务结束时生成话单， 本实施例需要对业务平台进 行改造， 使业务平台发送计费请求消息， 这样， 获取模块 400可以获取到业务 平台发送的计费请求消息。
获取模块 400获取的计费请求消息具体可以是 CCR消息， 也可以是基于其 它协议的计费请求消息， 如基于运营商私有协议的计费请求消息等； 本实施例 不限制获取模块 400获取到的计费请求消息所采用的具体协议。
获取模块 400可以根据接收到的计费请求消息中携带的信息识别出在线计 费业务和离线计费业务， 如扩展现有的计费请求消息的字段， 获取模块 400可 以根据该字段携带的信息进行在线计费业务和离线计费业务的识别。 本实施例 不限制获取模块 400识别在线计费业务和离线计费业务的具体实现方式。
存储模块 410， 用于存储业务记录信息。 存储模块 410中存储的业务记录信 息包括的具体内容与业务属性信息和 /或业务标识信息相关。 一个具体的例子： 存储模块 410中存储的业务记录信息具体可以包括当前计费用户终端号码、 主 叫号码、 被叫号码、 呼叫开始时间、 业务标识信息和计费标识等。 明显的， 对 于离线计费呼叫业务， 存储模块 410中存储的业务记录信息中可以不包括业务 标识信息； 对于事件型业务， 存储模块 410中存储的业务记录信息中可以不包 括业务标识信息， 且呼叫开始时间应该为具体业务发生时间。 本实施例不限制 存储模块 410中存储的业务属性信息、 业务标识信息和业务记录信息具体包括 的内容。
计费标识处理模块 420， 用于在存储的业务记录信息中 （如存储模块 410存 储的业务记录信息中） 查找与获取模块 400获取到的请求消息中的关键业务信 息匹配的业务记录信息， 如果存在匹配的业务记录信息， 则获取匹配的业务记 录信息中的计费标识， 如果不存在匹配的业务记录信息， 则分配计费标识。
计费标识处理模块 420包括第一处理子模块 421、 第二处理子模块 422和第 三处理子模块 423中的至少一个。
针对在线计费业务来说， 如果获取模块 400接收到的计费请求消息为该业 务的首次计费请求消息， 如计费开始请求消息， 则第一处理子模块 421可以根 据首次计费请求消息中携带的业务属性信息在存储的业务记录信息中 （如存储 模块 410存储的业务记录信息中）进行模糊匹配， 在存在模糊匹配的业务记录 信息时， 第一处理子模块 421获取匹配的业务记录信息中的计费标识， 在不存 在模糊匹配的业务记录信息时， 第一处理子模块 421分配计费标识。 第一处理 子模块 421应保证为本次在线计费业务分配的计费标识在预定长周期内全局唯 一。 上述业务属性信息用于描述业务， 业务属性信息具体包括的内容如上述实 施例一中的描述， 在此不再详细说明。
针对在线计费业务来说， 如果获取模块 400接收到的计费请求消息不为该 业务的首次计费请求消息， 如计费请求消息为计费中间请求消息或者计费结束 请求消息， 则第二处理子模块 422可以根据获取模块 400接收到的计费请求消息 中携带的业务标识信息在存储的业务记录信息中 （如存储模块 410存储的业务 记录信息中）查找获得计费标识。 上述业务标识信息用于唯一标识用户发生的 一次业务。 业务标识信息具体包括的内容如上述实施例一中的描述， 在此不再 详细说明。
针对离线计费业务来说， 如果获取模块 400接收到计费请求消息， 则第三 处理子模块 423可以根据计费请求消息中携带的业务属性信息在存储的业务记 录信息中模糊匹配， 在存在匹配的业务记录信息时， 第三处理子模块 423获取 匹配的业务记录信息中的计费标识， 在不存在匹配的业务记录信息时， 第三处 理子模块 423分配计费标识。 同样的， 第三处理子模块 423应保证为本次离线计 费业务分配的计费标识在预定长周期内全局唯一。 另外， 离线计费业务的计费 请求消息中携带的业务属性信息具体包括的内容同样可以根据触发计费请求 消息的业务种类来设置。
第一发送模块 430， 用于向请求消息的接收端发送计费标识和请求消息中 携带的信息， 该计费标识用于计费平台对具有相同计费标识的多个业务进行关 联计费。
第一发送模块 430具体可以包括第一发送子模块 431和第二发送子模块 432 中的至少一个。
针对在线计费业务， 第一发送子模块 431向计费平台发送携带有计费标识 的计费请求消息。
针对离线计费业务， 第二发送子模块 432可以直接向业务平台发送携带有 计费标识的计费应答消息。 针对离线计费业务需要特别说明的是， 第二发送子 模块 432不将计费请求消息发送至计费平台。 第一存储控制模块 440， 用于针对在线计费业务， 在图 4示出的装置接收到 计费平台针对在线计费业务的首次计费请求消息返回的计费成功的计费应答 消息 （如信用控制应答消息等）后， 将计费标识处理模块 420分配的或计费标 识处理模块 420查找获取的计费标识和计费请求消息中携带的业务关键信息存 储在存储模块 410的业务记录信息中。
第二存储控制模块 450， 用于针对离线计费业务， 在获取模块 400接收到业 务平台发送的计费请求消息（如计费开始请求消息）后， 将计费标识处理模块 420分配的或计费标识处理模块 420查找获取的计费标识和计费请求消息中携 带的业务关键信息存储在存储模块 410的业务记录信息中。
第二发送模块 460， 用于针对在线计费业务， 在图 4所示的装置接收到计费 平台返回的计费应答消息后， 从计费应答消息中剥离计费标识， 并向业务平台 发送剥离了计费标识的计费应答消息。
上述实施例四中的计费标识处理模块 420通过将请求消息中携带的关键业 务信息在存储的业务记录信息中匹配， 从匹配的业务记录信息中获得计费标 识， 或者在不存在匹配的业务记录信息时分配计费标识， 使相互嵌套的多个业 务可以拥有相同的计费标识； 这样， 计费平台可以根据该计费标识确定出相互 嵌套的多个关联业务， 从而计费平台可以对关联业务灵活的采用业务配置规则 对应的费用进行计费， 最终能够提高业务嵌套的计费方式的灵活性。
实施例五、 计费平台。 该计费平台可以为在线计费平台 （如 OCS等） ， 也 可以为离线计费平台。 该计费平台的结构如附图 5所示。
图 5中的计费平台包括： 接收模块 500、 业务配置规则模块 510和关联计费 模块 520。
接收模块 500， 用于接收业务关联装置发送来的消息， 将消息中携带的业 务的计费标识和计费数据存储于计费存储单元中。
针对在线计费平台来说， 接收模块 500接收到的计费标识和计费数据可以 是实施例一的执行主体发送的， 且计费标识和计费数据可携带在计费请求消息 中， 即接收模块 500可从接收到的计费请求消息中获取到计费标识和计费数据。 针对离线计费平台来说， 接收模块 500接收到的计费标识和计费数据可以 是业务平台发送的， 且计费标识和计费数据携带在话单中， 即接收模块 500可 以从接收到的话单中获取到计费标识和计费数据。
业务配置规则模块 510， 用于确定计费存储单元中具有相同计费标识的多 个业务对应的业务配置规则。 如果有多个业务具有相同的计费标识， 则表示这 多个业务为由于业务嵌套而相互关联的业务。 业务配置规则模块 510可以根据 预先存储的业务配置规则为具有相同计费标识的多个业务选择确定出业务配 置规则。
关联计费模块 520， 用于根据业务配置规则模块 510确定出的业务配置规则 对应的费率和接收模块 500接收到的计费数据对具有相同计费标识的多个业务 进行关联计费。 关联计费模块 520中可以存储有业务配置规则与费率的对应关 系， 关联计费模块 520可以根据该对应关系确定出费率， 本实施例不限制关联 计费模块 520确定出具体费率、 以及根据具体费率实际计费的具体实现过程。
上述实施例五中的接收模块 500可以接收到计费标识和计费数据， 由于相 互嵌套的多个业务拥有相同的计费标识， 因此， 业务配置规则模块 510可以根 据该计费标识确定出相互嵌套的多个关联业务， 并确定出多个关联业务对应的 业务配置规则， 从而关联计费模块 520可以对关联业务灵活的采用业务配置规 则对应的费用进行计费， 最终提高了业务嵌套的计费方式的灵活性。
实施例六、 基于业务嵌套的业务关联系统。 该系统的结构如附图 6所示。 图 6中的系统包括： 业务关联引擎 610。 该业务关联引擎 610与业务平台 600 连接。 可选的， 该系统还可以包括： 在线计费平台 620和离线计费平台 630中的 至少一个。 图 6中虽然只示出了一个业务平台 600， 但是， 在实际的网络中， 与 业务关联引擎 610连接的业务平台 600可以为多个。
业务平台 600， 用于发送携带有关键业务信息的请求消息。
业务平台 600发送的请求消息可以为现有的计费请求消息， 当然， 业务平 台 600发送的请求消息也可以为除计费请求消息之外的其它消息， 如针对本实 施例而新增加的携带有关键业务信息的消息等。
针对在线计费业务， 现有的业务平台 600可以不进行改造， 即业务关联引 擎 610截获业务平台 600向在线计费平台 620发送计费请求消息。 业务平台 600向 在线计费平台 620发送计费请求消息可以是预付费在线计费业务的计费请求消 息， 也可以是实时信控的后付费在线计费业务的计费请求消息。 在线计费业务 具体包括的业务类型、 关键业务信息包括的内容、 以及计费请求消息具体包括 的消息等如上述实施例一的描述， 在此不再详细说明。
针对离线计费业务， 业务平台 600需要进行改造， 以发送计费请求消息， 从而业务关联引擎 610可以接收到业务平台 600发送的计费请求消息。 另外， 业 务平台 600可以接收到业务关联引擎 610针对该计费请求消息返回的计费应答 消息， 该计费应答消息中携带有计费标识。 业务平台 600在为离线计费业务生 成话单时， 应使该话单中包括离线计费业务对应的计费标识。
业务平台 600发送的计费请求消息具体可以是 CCR消息， 也可以是基于其 它协议的计费请求消息， 如基于运营商私有协议的计费请求消息等； 本实施例 不限制业务平台 600发送的计费请求消息所采用的具体协议。
业务关联引擎 610， 用于获取业务平台 600发送的请求消息， 并在存储的业 务记录信息中查找与请求消息中的关键业务信息匹配的业务记录信息， 如果存 在匹配的业务记录信息， 则业务关联引擎 610获取匹配的业务记录信息中的计 费标识， 如果不存在匹配的业务记录信息， 则业务关联引擎 610分配计费标识， 业务关联引擎 610向请求消息的接收端发送计费标识和请求消息中携带的信 息， 这里的计费标识用于计费平台对具有相同计费标识的多个业务进行关联计 费。 上述请求消息的接收端可以为在线计费平台 620， 也可以为业务平台 600。 针对在线计费业务， 业务关联引擎 610向在线计费平台 620发送携带有计费标识 的计费请求消息。 针对离线计费业务， 业务关联引擎 610可以直接向业务平台 600发送携带有计费标识的计费应答消息。 针对离线计费业务需要特别说明的 是， 业务关联引擎 610不将计费请求消息发送至离线计费平台 630。
业务关联引擎 610中存储的业务记录信息包括的具体内容与业务属性信息 和 /或业务标识信息相关。 一个具体的例子： 业务关联引擎 610中存储的业务记 录信息具体可以包括当前计费用户终端号码、 主叫号码、 被叫号码、 呼叫开始 时间、 业务标识信息和计费标识等。 明显的， 对于离线计费业务， 业务关联引 擎 610中存储的业务记录信息中可以不包括业务标识信息； 对于在线计费事件 型业务， 业务关联引擎 610中存储的业务记录信息中可以不包括业务标识信息， 且呼叫开始时间应该为具体业务发生时间。 本实施例不限制业务关联引擎 610 中存储的业务属性信息、 业务标识信息和业务记录信息具体包括的内容。
针对在线计费业务来说， 如果业务关联引擎 610接收到的计费请求消息为 该业务的首次计费请求消息， 如计费开始请求消息， 则业务关联引擎 610可以 根据首次计费请求消息中携带的业务属性信息在存储的业务记录信息中进行 模糊匹配， 在存在匹配的业务记录信息时， 业务关联引擎 610获取匹配的业务 记录信息中的计费标识， 在不存在匹配的业务记录信息时， 业务关联引擎 610 分配计费标识。 业务关联引擎 610应保证为本次在线计费业务分配的计费标识 在预定长周期内全局唯一。 上述业务属性信息用于描述业务， 业务属性信息具 体包括的内容如上述实施例一中的描述， 在此不再详细说明。
针对在线计费业务来说， 如果业务关联引擎 610接收到的计费请求消息不 为该业务的首次计费请求消息， 如计费请求消息为计费中间请求消息或者计费 结束请求消息， 则业务关联引擎 610可以根据接收到的计费请求消息中携带的 业务标识信息在存储的业务记录信息中查找获得计费标识。 上述业务标识信息 用于唯一标识用户发生的一次业务。 业务标识信息具体包括的内容如上述实施 例一中的描述， 在此不再详细说明。
针对离线计费业务来说， 如果业务关联引擎 610接收到计费请求消息， 则 业务关联引擎 610可以根据计费请求消息中携带的业务属性信息在存储的业务 记录信息中模糊匹配， 在存在匹配的业务记录信息时， 业务关联引擎 610获取 匹配的业务记录信息中的计费标识， 在不存在匹配的业务记录信息时， 业务关 联引擎 610分配计费标识。 同样的， 业务关联引擎 610应保证为本次离线计费业 务分配的计费标识在预定长周期内全局唯一。 另外， 离线计费业务的计费请求 消息中携带的业务属性信息具体包括的内容同样可以根据触发计费请求消息 的业务种类来设置。
针对在线计费业务， 业务关联引擎 610在接收到在线计费平台 620针对在线 计费业务的首次计费请求消息返回的计费成功的计费应答消息（如信用控制应 答消息等）后， 将针对该首次计费请求消息分配的或查找获取的计费标识和计 费请求消息中携带的业务关键信息存储在业务记录信息中。 另外， 业务关联引 擎 610在接收到计费平台返回的计费应答消息后， 从计费应答消息中剥离计费 标识， 并向业务平台 600发送剥离了计费标识的计费应答消息。
针对离线计费业务， 业务关联引擎 610在接收到业务平台 600发送的计费请 求消息（如计费开始请求消息）后， 将针对该计费请求消息分配的或查找获取 的计费标识和计费请求消息中携带的业务关键信息存储在业务记录信息中。
在线计费平台 620， 用于接收业务关联引擎 610发送的消息， 将消息中携带 的计费标识和计费数据存储于计费存储单元中， 确定计费存储单元中具有相同 计费标识的多个业务的业务配置规则， 在线计费平台 620根据该业务配置规则 对应的费率和接收到的计费数据对具有相同计费标识的多个业务进行关联计 费。
离线计费平台 630， 用于接收业务平台 600发送来的包含有计费标识和计费 数据的话单， 确定具有相同计费标识的多个话单的业务配置规则， 根据该业务 配置规则对应的费率和接收到的计费数据对具有相同计费标识的多个业务进 行关联计费。
业务关联引擎 610、 在线计费平台 620和离线计费平台 630的具体结构如上 述实施例的描述， 在此不再重复说明。
通过以上的实施方式的描述， 本领域的技术人员可以清楚地了解到本发明 可借助软件加必需的硬件平台的方式来实现， 当然也可以全部通过硬件来实 施， 但很多情况下前者是更佳的实施方式。 基于这样的理解， 本发明的技术方 案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来， 所述 的软件产品在可以用于执行上述的方法流程。 该计算机软件产品可以存储在存 储介质中， 如 ROM/RAM、 磁碟、 光盘等， 包括若干指令用以使得一台计算机 设备（可以是个人计算机， 服务器， 或者网络设备等）执行本发明各个实施例 或者实施例的某些部分所述的方法。
虽然通过实施例描绘了本发明， 本领域普通技术人员知道， 本发明有许多 变形和变化而不脱离本发明的精神， 本发明的申请文件的权利要求包括这些变 形和变化。

Claims

权利要求书
1、 一种基于业务嵌套计费的业务关联方法， 其特征在于， 包括： 获取业务平台发送的携带有关键业务信息的请求消息；
根据所述请求消息进行计费标识处理得到计费标识， 包括： 在存储的业务 记录信息中查找与所述关键业务信息匹配的业务记录信息， 如果存在匹配的业 务记录信息， 则获取匹配的业务记录信息中的计费标识， 如果不存在匹配的业 务记录信息， 则分配计费标识； 所述计费标识用于计费平台对具有相同计费标 识的多个业务进行关联计费；
向所述请求消息的接收端发送计费标识和所述请求消息中携带的信息。
2、 如权利要求 1 所述的方法， 其特征在于， 该方法基于在线计费业务， 所述请求消息为计费请求消息， 所述计费标识处理包括：
如果所述计费请求消息为在线计费业务的首次计费请求消息， 则根据计费 请求消息中携带的业务属性信息在存储的业务记录信息中模糊匹配， 在存在模 糊匹配的业务记录信息时， 获取模糊匹配的业务记录信息中的计费标识， 在不 存在模糊匹配的业务记录信息时， 分配计费标识。
3、 如权利要求 2所述的方法， 其特征在于：
该方法基于呼叫业务， 所述业务属性信息包括： 当前计费用户终端号码、 主叫号码、 被叫号码和呼叫开始时间， 所述模块匹配包括： 计费请求消息中携 带的当前计费用户终端号码、 主叫号码和被叫号码与所述存储的业务记录信息 中的当前计费用户终端号码、 主叫号码和被叫号码相同， 且所述计费请求消息 中的呼叫开始时间与所述存储的业务记录信息中的呼叫开始时间相差预定时 间间隔；
或者， 所述业务标识信息包括： 会话标识。
4、 如权利要求 1 所述的方法， 其特征在于， 该方法基于离线计费业务， 所述请求消息为计费请求消息， 所述计费标识处理包括： 根据计费请求消息中携带的业务属性信息在存储的业务记录信息中模糊 匹配， 在存在模糊匹配的业务记录信息时， 获取模糊匹配的业务记录信息中的 计费标识， 在不存在模糊匹配的业务记录信息时， 分配计费标识。
5、 如权利要求 1所述的方法， 其特征在于：
该方法基于在线计费业务， 所述业务记录信息为： 接收到计费平台基于在 线计费业务的首次计费请求消息返回的计费成功的计费应答消息后， 根据所述 分配或获取的计费标识和所述计费请求消息中携带的业务关键信息存储的业 务记录信息； 或者
该方法基于离线计费业务， 所述业务记录信息为： 接收到业务平台发送的 计费请求消息后， 根据所述分配或获取的计费标识和所述计费请求消息中携带 的业务关键信息存储的业务记录信息。
6、 如权利要求 1至 5中任一权利要求所述的方法， 其特征在于， 所述向 所述请求消息的接收端发送计费标识和所述请求消息中携带的信息包括： 该方法基于在线计费业务， 向计费平台发送携带有计费标识的计费请求消 息； 或
该方法基于离线计费业务， 向业务平台发送携带有计费标识的计费应答消 息。
7、 如权利要求 1至 5中任一权利要求所述的方法， 其特征在于， 基于在 线计费业务， 所述方法还包括：
在接收计费平台返回的计费应答消息后， 从所述计费应答消息中剥离计费 标识， 并向业务平台发送剥离了计费标识的计费应答消息。
8、 一种基于业务嵌套的业务关联计费方法， 其特征在于， 包括： 计费平台接收业务关联装置发送来的消息， 将所述消息中的业务的计费标 识和计费数据存储于计费存储单元中；
确定所述计费存储单元中具有相同计费标识的多个业务的业务配置规则； 根据所述业务配置规则对应的费率和所述计费数据对具有相同计费标识 的多个业务进行关联计费。
9、 一种基于业务嵌套计费的业务关联装置， 其特征在于， 包括： 获取模块， 获取业务平台发送的携带有关键业务信息的请求消息； 计费标识处理模块， 用于在存储的业务记录信息中查找与所述关键业务信 息匹配的业务记录信息， 如果存在匹配的业务记录信息， 则获取匹配的业务记 录信息中的计费标识， 如果不存在匹配的业务记录信息， 则分配计费标识， 所 述计费标识用于计费平台对具有相同计费标识的多个业务进行关联计费； 第一发送模块， 用于向所述请求消息的接收端发送计费标识和所述请求消 息中携带的信息。
10、 如权利要求 9所述的装置， 其特征在于， 所述请求消息为计费请求消 息， 所述计费标识处理模块包括：
第一处理子模块， 用于基于在线计费业务， 在所述计费请求消息为在线计 费业务的首次计费请求消息时， 根据计费请求消息中携带的业务属性信息在存 储的业务记录信息中模糊匹配， 在存在模糊匹配的业务记录信息时， 获取匹配 的业务记录信息中的计费标识， 在不存在模糊匹配的业务记录信息时， 分配计 费标识。
11、 如权利要求 9所述的装置， 其特征在于， 所述请求消息为计费请求消 息， 所述计费标识处理模块包括：
第三处理子模块， 用于基于离线计费业务， 根据计费请求消息中携带的业 务属性信息在存储的业务记录信息中模糊匹配， 在存在模糊匹配的业务记录信 息时， 获取模糊匹配的业务记录信息中的计费标识， 在不存在模糊匹配的业务 记录信息时， 分配计费标识。
12、 如权利要求 9所述的装置， 其特征在于， 所述装置还包括： 第一存储控制模块， 用于基于在线计费业务， 在所述装置接收到计费平台 基于在线计费业务的首次计费请求消息返回的计费成功的计费应答消息后， 将 所述分配或获取的计费标识和计费请求消息中携带的业务关键信息存储在所 述业务记录信息中； 和 /或者
第二存储控制模块， 用于基于离线计费业务， 在所述装置接收到业务平台 发送的计费请求消息后， 将所述分配或获取的计费标识和所述计费请求消息中 携带的业务关键信息存储在所述业务记录信息中。
13、 如权利要求 9至 12中任一权利要求所述的装置， 其特征在于， 所述 第一发送模块包括：
第一发送子模块， 用于基于在线计费业务， 向计费平台发送携带有计费标 识的计费请求消息；
第二发送子模块， 用于基于离线计费业务， 向业务平台发送携带有计费标 识的计费应答消息。
14、 如权利要求 9至 12中任一权利要求所述的装置， 其特征在于， 所述 装置还包括：
第二发送模块， 用于基于在线计费业务， 在所述装置接收到计费平台返回 的计费应答消息后， 从所述计费应答消息中剥离计费标识， 并向业务平台发送 剥离了计费标识的计费应答消息。
15、 一种计费平台， 其特征在于， 包括：
接收模块， 用于接收业务关联装置发送来的消息， 将所述消息中的业务的 计费标识和计费数据存储于计费存储单元中；
业务配置规则模块， 用于确定所述计费存储单元中具有相同计费标识的多 个业务的业务配置规则；
关联计费模块， 用于根据所述业务配置规则对应的费率和所述计费数据对 具有相同计费标识的多个业务进行关联计费。
16、一种基于业务嵌套计费的业务关联系统， 其特征在于， 所述系统包括： 与业务平台连接的业务关联引擎；
业务平台， 用于发送携带有关键业务信息的请求消息；
业务关联引擎， 用于获取业务平台发送的所述请求消息， 在存储的业务记 录信息中查找与所述关键业务信息匹配的业务记录信息， 如果存在匹配的业务 记录信息， 则获取匹配的业务记录信息中的计费标识， 如果不存在匹配的业务 记录信息， 则分配计费标识， 向所述请求消息的接收端发送计费标识和所述请 求消息中携带的信息， 所述计费标识用于计费平台对具有相同计费标识的多个 业务进行关联计费。
17、 如权利要求 16所述的系统， 其特征在于， 所述系统还包括： 在线计费平台， 用于接收业务关联引擎发送来的消息， 将所述消息中的计 费标识和计费数据存储于计费存储单元中， 确定所述计费存储单元中具有相同 计费标识的多个业务的业务配置规则， 根据所述业务配置规则对应的费率和所 述计费数据对具有相同计费标识的多个业务进行关联计费； 和 /或
离线计费平台， 用于接收业务平台发送来的包含有计费标识和计费数据的 话单， 确定具有相同计费标识的多个话单的业务配置规则， 根据所述业务配置 规则对应的费率和所述计费数据对具有相同计费标识的多个业务进行关联计 费； 所述话单为所述业务平台生成的话单。
PCT/CN2011/072905 2010-06-13 2011-04-18 基于业务嵌套计费的业务关联方法、装置和系统 WO2011157077A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/714,282 US9203977B2 (en) 2010-06-13 2012-12-13 Method, apparatus and system for service association based on service nesting charging

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010204847.3A CN102142966B (zh) 2010-06-13 2010-06-13 基于业务嵌套计费的业务关联方法、装置和系统
CN201010204847.3 2010-06-13

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/714,282 Continuation US9203977B2 (en) 2010-06-13 2012-12-13 Method, apparatus and system for service association based on service nesting charging

Publications (1)

Publication Number Publication Date
WO2011157077A1 true WO2011157077A1 (zh) 2011-12-22

Family

ID=44410212

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/072905 WO2011157077A1 (zh) 2010-06-13 2011-04-18 基于业务嵌套计费的业务关联方法、装置和系统

Country Status (3)

Country Link
US (1) US9203977B2 (zh)
CN (1) CN102142966B (zh)
WO (1) WO2011157077A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103118347B (zh) * 2011-11-16 2015-11-18 中国移动通信集团上海有限公司 一种终端间短号码呼叫的方法、系统和查询设备
CN102546671B (zh) * 2012-03-08 2015-09-09 北京思特奇信息技术股份有限公司 一种基于dcc直径信控协议的消息传输方法
CN103269479B (zh) * 2013-05-07 2016-03-30 华为技术有限公司 一种话单处理方法、装置和系统
CN105338506B (zh) * 2014-07-23 2019-05-28 华为技术有限公司 计费方法和设备、接入设备、服务质量控制方法和设备
CN106909997A (zh) * 2015-12-22 2017-06-30 阿里巴巴集团控股有限公司 一种业务处理方法和装置
CN112905945B (zh) * 2019-11-19 2023-08-15 中移物联网有限公司 计费方法、装置及可读存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101489206A (zh) * 2009-02-26 2009-07-22 东方通信股份有限公司 一种解决一机多号副号做虚拟网被叫问题的方法和平台
CN101540807A (zh) * 2009-03-17 2009-09-23 中国移动通信集团浙江有限公司 一种基于ims网络实现移固融合家庭业务的系统及方法
CN101645781A (zh) * 2008-08-06 2010-02-10 华为技术有限公司 一种ip多媒体子系统网络计费设备、方法和系统

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6639978B2 (en) * 2001-12-17 2003-10-28 Evercom Systems, Inc. Method for determining an entity responsible for billing a called party
CN1905462B (zh) * 2005-07-27 2010-04-07 华为技术有限公司 一种应用业务的计费关联方法及系统
CN101047515B (zh) * 2006-03-31 2010-10-27 华为技术有限公司 一种应用业务的计费关联方法及系统
US8116728B2 (en) * 2008-04-22 2012-02-14 Alcatel Lucent Charging in LTE/EPC communication networks
CN101582778B (zh) * 2008-07-18 2011-11-30 中兴通讯股份有限公司 用于ip多媒体子系统的离线计费方法和系统
CN101841798B (zh) * 2009-03-20 2014-01-01 中兴通讯股份有限公司 计费标识的关联方法和装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101645781A (zh) * 2008-08-06 2010-02-10 华为技术有限公司 一种ip多媒体子系统网络计费设备、方法和系统
CN101489206A (zh) * 2009-02-26 2009-07-22 东方通信股份有限公司 一种解决一机多号副号做虚拟网被叫问题的方法和平台
CN101540807A (zh) * 2009-03-17 2009-09-23 中国移动通信集团浙江有限公司 一种基于ims网络实现移固融合家庭业务的系统及方法

Also Published As

Publication number Publication date
US20130101103A1 (en) 2013-04-25
US9203977B2 (en) 2015-12-01
CN102142966B (zh) 2014-05-07
CN102142966A (zh) 2011-08-03

Similar Documents

Publication Publication Date Title
KR101160377B1 (ko) 가입자에 대한 통합식 선불 과금 및 후불 과금 제공 통신 네트워크, 방법 및 통신 네트워크의 과금 선택 시스템
CN101009691B (zh) Ims网络和老式网络的汇聚服务控制系统和方法
EP1695565B1 (en) Number portability
CN103348627B (zh) 与ip多媒体子系统中的在线收费相关的方法和设备
WO2011157077A1 (zh) 基于业务嵌套计费的业务关联方法、装置和系统
KR20110042102A (ko) Ｉｍｓ 네트워크들에서의 온라인 과금 상관
WO2010063176A1 (zh) 基于在线计费系统的呼叫计费方法及通信系统
WO2020119325A1 (zh) 计费处理方法及装置、存储介质和电子装置
JP2004507983A (ja) 通信システムの課金
EP1876808B1 (en) A method and system for enabling charging of non-charging controlled services
US7120419B2 (en) Generating one or more triggered operations to prepaid service node based on connection with intelligent peripheral component
KR100509936B1 (ko) 이동통신망에서 멀티미디어 데이터의 선불형 지능망서비스 제공 시스템 및 방법
WO2008046330A1 (fr) Procédé, système et commutateur pour corrélation de tickets d'appel
WO2011015154A1 (zh) 释放资源的方法、装置和系统
CN109547956B (zh) 一种多业务并发处理方法
CN101448235B (zh) 一种交互式语音应答业务中实现计费的方法和系统
WO2011003255A1 (zh) 一种基于ocs的被叫付费业务实现方法和系统
WO2009082977A1 (fr) Procédé de réalisation d'un appel extérieur lors d'un échange téléphonique de groupe, dispositif de contrôle d'un service et système d'échange téléphonique de groupe
WO2009046641A1 (fr) Procédé et système de traitement d'opération de service concernant des données utilisateur de prépaiement
CN100508463C (zh) 一种实现智能业务的方法、系统及装置
WO2007062545A1 (fr) Procede pour l'acces du terminal d'appelant a un systeme de service prepaye
CN100493125C (zh) 一种cdma预付费业务中设置呼叫详细记录的方法
WO2012159319A1 (zh) 固话仿真的方法、平台及通信系统
WO2011026348A1 (zh) 一种实现灵活周期内限额消费业务的方法和装置
KR100493735B1 (ko) Ｗｃｄｍａ ｕｍｔｓ 이동전화망의 지능망 서비스에서의비정상 호 처리방법

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: 11795043

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: 11795043

Country of ref document: EP

Kind code of ref document: A1