WO2019001574A1 - Procédé et appareil d'émission de ticket d'appel et support de stockage - Google Patents

Procédé et appareil d'émission de ticket d'appel et support de stockage Download PDF

Info

Publication number
WO2019001574A1
WO2019001574A1 PCT/CN2018/093756 CN2018093756W WO2019001574A1 WO 2019001574 A1 WO2019001574 A1 WO 2019001574A1 CN 2018093756 W CN2018093756 W CN 2018093756W WO 2019001574 A1 WO2019001574 A1 WO 2019001574A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
response message
charging
message
packet
Prior art date
Application number
PCT/CN2018/093756
Other languages
English (en)
Chinese (zh)
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 WO2019001574A1 publication Critical patent/WO2019001574A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/141—Indication of costs
    • 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

Definitions

  • the present disclosure relates to the field of communications technologies, and, for example, to a bill output method, apparatus, and storage medium.
  • the billing system is one of the important functional components of 3GPP, and is an important guarantee for operators to achieve revenue.
  • the embodiment of the present application provides a bill output method, apparatus, and storage medium to solve at least the problem of repeated billing due to repeated output of bills.
  • a bill output method including: after determining that a first Charging Gateway Function (CGF) is restored from an abnormal state to a normal state, to a first charging gateway function.
  • the CGF sends a first request message, where the first request message is used to request the first CGF to confirm whether predetermined charging information for charging is received; when the first CGF is received, based on the first
  • the second CGF is configured to output a bill corresponding to the predetermined billing information according to the first response message, where the first response message is used to indicate that the first CGF is not Receiving the predetermined charging information, the second CGF has received the predetermined charging information.
  • a bill output method including: receiving a first request message sent by a Charging Data Function (CDF); determining not according to the first request message Receiving, by the CDF, a first response message, where the predetermined charging information for charging is received, wherein the first response message is used by the CDF to indicate a second CGF output and the predetermined charging information Corresponding bills, the second CGF has received the predetermined billing information.
  • CDF Charging Data Function
  • a bill output device including: a sending module, configured to: after determining that the first billing gateway function CGF returns from the abnormal state to the normal state, to the first charging gateway The function CGF sends a first request message, where the first request message is used to request the first CGF to confirm whether the predetermined charging information for charging is received; the first receiving module is configured to receive the first The CGF is based on the first response message returned by the first request message, where the first response message is used to indicate that the first CGF has not received the predetermined charging information; the first indication module is configured to be When the first receiving module receives the first response message that is returned by the first charging gateway function based on the first request message, the first response message indicates that the second CGF output corresponds to the predetermined charging information. a bill, wherein the second CGF has received the predetermined billing information.
  • a bill output device including: a receiving module, configured to receive a first request message sent by a billing data function CDF; and a first return module configured to The first request message determines that the first charging message is returned to the CDF if the predetermined charging information for charging is not received, wherein the first response message is used by the CDF to indicate the second CGF output and The bill corresponding to the predetermined billing information, the second CGF has received the predetermined billing information.
  • a storage medium comprising a stored program, wherein the program is executed to perform the method of any of the above.
  • a processor for running a program wherein the program is executed to perform the method of any of the above.
  • the first CGF may return a response message specifically for indicating that the first CGF has not received the predetermined charging information, so that the receiving condition of the predetermined charging information of the first CGF may be clarified, thereby avoiding repeated output of the bill. Therefore, the problem of repeated charging due to repeated output of bills can be solved, thereby achieving the effect of avoiding repeated input of bills and improving user experience.
  • FIG. 1 is a schematic diagram of a charging function entity in a 3GPP network
  • FIG. 2 is a schematic diagram of a CDR transmission process in the 3GPP 32.295 standard
  • GTP general packet radio service tunneling protocol
  • FIG. 4 is a flowchart of a method for outputting a bill according to an embodiment of the present application
  • FIG. 5 is a flowchart of another method for outputting a bill according to an embodiment of the present application.
  • FIG. 6 is a schematic diagram of a network architecture for transmitting a bill according to an embodiment of the present application.
  • FIG. 7 is a schematic flowchart of redirecting anti-weight using "cause field indication method" according to an embodiment of the present application.
  • FIG. 8 is a schematic flowchart of redirecting anti-weight using the “packet type labeling method” according to an implementation of the present application.
  • FIG. 9 is a schematic flowchart of redirecting anti-weight using the “message label method” according to an implementation of the present application.
  • FIG. 11 is a structural block diagram of a bill output device according to an embodiment of the present application.
  • FIG. 12 is a structural block diagram of another CDR output device according to an embodiment of the present application.
  • the primary functions of the billing system are as follows.
  • the Charging Trigger Function (CTF) is embedded in the 3GPP core network element.
  • the main function of the charging is to collect the accounting information according to the monitored usage of the network resources and to charge the offline.
  • the Offline Charging Reference Point (OCRP), the Rf interface is sent to the Charging Data Function (CDF).
  • the main function of the CDF is to receive an Accounting Request message (ACR) sent by the CTF, construct a Charging Data Record (CDR), and send the CDR to the Charging Gateway Function through the Ga interface.
  • CGF Accounting Request message
  • the main function of the CGF is to store and manage the CDRs received from the CDF and send the CDR files to the Billing Domain (BD) through the Bx interface.
  • BD Billing Domain
  • the Ga interface is used to transfer bills between CDF and CGF. This interface is commonly used in billing systems.
  • the Ga interface is applied in a Packet Switch (PS)/Evolved Packet Core Internet (EPC), and the PS/EPC network element (the combination of the CTF and the CDF) is passed between the CGF and the CGF.
  • PS Packet Switch
  • EPC Evolved Packet Core Internet
  • the standard interface transmits billing data.
  • the Ga interface is implemented by the General Packet Radio Service Tunneling Protocol (GTP) stack.
  • GTP General Packet Radio Service Tunneling Protocol
  • the principle of the protocol stack can be found in the 3GPP 32.295 standard document. In the 3GPP 32.295 standard, the GTP protocol defines CDR transmission and redirection functions, as well as fault detection recovery and prevention of re-single functions.
  • the CDR transmission process includes the following steps. 201.
  • the CDF sends a GTP request message to the CGF, where the message includes multiple CDRs (ie, Sending a Data Record Transfer Request to the CGF: Send Data Record Packet).
  • the CGF saves the CDR, that is, multiple CDRs store the CDRs in a secure manner.
  • the CGF replies to the CDF with a response message, wherein the cause Cause field fill request receives "Request Accepted", indicating that the request message has been received, that is, returns a data record transmission response.
  • Data Record Transfer the request has received Request Accepted.
  • the CDF deletes the CDR in the cache, that is, deletes the successfully sent CDR Succesfully sent CDRs from the CDR cache to the CDF buffers.
  • the GTP protocol provides a redirection function, that is, when the CDF fails to send the CDR to the first CGF (CGF1), the CDR can be retransmitted to the second CGF (CGF2) according to the configuration, and the CDR is re-transmitted according to the configuration.
  • CDF CGF1
  • CGF2 CGF2
  • CGF2 CGF2
  • the 3GPP 32.295 standard also proposes a weight prevention mechanism.
  • FIG. 3 is a schematic diagram of a GTP protocol anti-gravity mechanism in the 3GPP 32.295 standard.
  • the GTP protocol anti-gravity mechanism includes the following steps. 301.
  • the CDF sends a data packet to the high priority CGF1 (assuming the packet stream number is N1), that is, sends a data record packet Send Data Record Packet. 302a), CGF1 does not respond to CDF response No response to CDF for a period of time, which may be due to network interruption, CGF1 abnormality, etc. 302b) If CGF1 receives and processes the data record data packet, CGF1 records the serial number N1. 303.
  • the CDF Because the CDF does not receive the response message, the CDF sends a "suspicious duplicate packet" to the secondary priority CGF2. Send the Suspicious Repeat Packet Send Data Record Packet: pot.dupl. 304. After receiving the "suspicious duplicate packet", the CGF2 replies with a response message, that is, Request Accepted, and the reason "Cause field” in the message "Request Accepted” indicates that the request has been received. 305. After the CGF1 resumes working, send a node survival request “Node Alive Request” message to the CDF. 306. The CDF replies to the node survival response "Node Alive Response" message to the CGF1. 307.
  • the CDF knows that after the CGF1 resumes its work, it sends a suspicious duplicate packet to the CGF1 (the serial number is N1), that is, Send Data Record Packet: pot.dupl.empty, and the data content is empty, indicating that the packet is a confirmation request for the suspicious duplicate packet. .
  • CGF1 receives a confirmation request for the suspicious duplicate packet and determines whether the serial number N1 has been received. 308a) If the serial number is not received, CGF1 replies with a response message to the CDF, and the cause in the message is filled in "Request Accepted", indicating that the request has been received.
  • CGF1 replies with a response message to the CDF, in which the cause of the Cause field is filled with the suspicious duplicate packet that has been received "Request related to possibly duplicated packet already fulfilled" indicating that the suspected duplicate packet of the serial number has been received.
  • the CDF receives the response message of the CGF1, and if the Cause field is "Request Accepted", sends a request for releasing the suspicious duplicate packet to the CGF2, that is, the Release Data Record Packet, and the CGF2 outputs the CDR.
  • the 3GPP solves the problem of heavy orders in the redirection scenario through the above mechanism.
  • This mechanism can solve most of the redirected scenarios, but there are still problems in some scenarios.
  • the normal data packet that may be sent in step 301 is temporarily not processed, and the CDR and the reply response are processed after step 307, which is indistinguishable from the response of the suspicious duplicate packet of step 308a) because The cause of these two response messages is the same as the Cause field and the packet sequence number.
  • the CDF will continue to perform according to 309a), that is, the CDR is also output in CGF2. This causes the packet to output the CDR on both CGF1 and CGF2, resulting in a heavy order.
  • the CGF1 After the CDF sends the data record packet to the CGF1, the CGF1 does not construct the CDR due to busyness, etc., but caches the data record packet. Subsequent chain scission, CDF redirects send suspicious duplicate packets to CGF2. After the link is restored, the CDF sends a suspicious duplicate null request to the CGF1. At this time, the CGF1 responds to the CDF after processing the data record packet.
  • CDF After the CDF sends the data record packet to the CGF1, the CGF1 does not construct the CDR due to busyness, etc., but caches the data record packet. Subsequent retransmission timeouts, CDF redirects send suspicious duplicate packets to CGF2. The subsequent CDF detects that the CGF1 link is normal, and sends a suspicious repeated null packet request to CGF1. At this time, CGF1 responds to the CDF after processing the data record data packet.
  • the CGF1 finds that the resource is insufficient, and sends a redirect request to the CDF. After receiving the redirect request, the CDF sends the suspicious duplicate packet to the CGF2; the subsequent CGF1 finds the resource recovery and gives the CDF a reply. The node survival response message, the CDF sends a suspicious duplicate empty packet request to the CGF1, and the CGF1 responds to the CDF after processing the data record data packet.
  • the reason for the heavy order when redirecting is that the content of the data record transmission request and the response message of the suspicious duplicate packet request are the same, that is, the reason field is “Request Accepted” and the serial number is the same, and the CDF cannot The data record transmission request and the response message of the suspicious duplicate packet request are distinguished, resulting in a false positive.
  • FIG. 4 is a flowchart of a method for outputting a bill according to an embodiment of the present application. As shown in FIG. 4, the flow includes the following steps:
  • Step S402 after determining that the first charging gateway function CGF is restored from the abnormal state to the normal state, sending a first request message to the first charging gateway function CGF, where the first request message is used to request the first CGF to confirm whether Received predetermined billing information for billing.
  • Step S404 when receiving the first response message returned by the first CGF based on the first request message, instructing the second CGF to output a bill corresponding to the predetermined charging information according to the first response message, where the first response The message is used to indicate that the first CGF has not received the predetermined charging information, and the second CGF has received the predetermined charging information.
  • the CDF can be performed to perform the above operation.
  • the first CGF may return a response message specifically for indicating that the first CGF has not received the predetermined charging information, so that the receiving condition of the predetermined charging information of the first CGF may be clarified, thereby avoiding repetition of the bill.
  • the output therefore, can solve the problem of repeated charging due to repeated output of bills, thereby achieving the effect of avoiding repeated input of bills and improving user experience.
  • the method further includes at least one of: when receiving the second response message returned by the first CGF based on the first request message. And instructing, by the second response message, that the second CGF cancels outputting the bill corresponding to the predetermined billing information, where the second response message is used to indicate that the first CGF has received the predetermined billing information; when the first bill is received
  • the third response message is returned by the charging gateway function, the second charging gateway is instructed to cancel the output of the bill corresponding to the predetermined charging information according to the third response message, where the third response message is The first charging gateway function is based on a response of the received data packet.
  • the basis for the first CGF to return the second response message may be that the first CGF has received the predetermined charging information.
  • the first CGF will output the CDR, and the other CGFs do not need to repeatedly output the same message. single.
  • the Cause field of the third response message is 128 Request Accepted. That is, the reason field of the third response message is the first indication value and the request receives Request Accepted.
  • the third response message may use an existing response message to simplify the operation.
  • the cause field of the first response message includes one of the following: a second flag value and a susceptive duplicate packet acceptance (ie, 178 Request related to possibly duplicated packets Accepted); the first flag value and the request to receive (ie, And a type field of the data packet, wherein the type field of the data packet is used to indicate that the request for the current response is a request for a suspicious duplicate packet, and the data packet carries predetermined charging information;
  • the value and the request are received (ie, 128 Request accepted) and carry the first tag, where the first request message carries the first tag; the first tag value and the request to receive (ie, 128 Request accepted) and carry the first timestamp,
  • the first request message carries the first timestamp.
  • the first indication value is 128.
  • the second indicator value is 178.
  • a Cause field of the first response message is 128 Request accepted and carries a first label
  • a Cause field of the third response message is 128 Request accepted and carries a second The label
  • the Cause field of the second response message is 252: Request related to possibly duplicated packet already fulfilled and carries the first label.
  • the first label is different from the second label, and is carried when the predetermined charging information is sent to the first CGF.
  • the label is the second label;
  • the Cause field of the first response message is 128 Request accepted and carries the first timestamp
  • the Cause field of the third response message is 128 Request accepted and carries the second timestamp
  • the reason of the second response message ( The Cause) field is 252 Request related to possibly duplicated packet already fulfilled and carries the first timestamp, the first timestamp and the second timestamp are different, and the timestamp carried when the predetermined charging information is sent to the first CGF is the second time stamp. That is, in an embodiment, the Cause field of the first response message is a first identifier value and the request is received and the first label is carried; the Cause field of the second response message is a third identifier value and a suspicious repetition.
  • the packet has received the first label; the Cause field of the third response message is the first identifier value and the request receives the Request accepted and carries the second label;
  • the first label and the second label may be different, and the label carried when the data packet is sent to the first charging gateway function is the second label.
  • the Cause field of the first response message is the first indication value and the request receiving Request accepted and carries a first timestamp; and the Cause field of the second response message is a third indication value.
  • the suspicious duplicate packet has received the request related to possibly duplicated packet already fulfilled and carries the first timestamp;
  • the Cause field of the third response message is the first indication value and the request receives the Request accepted and carries the first The second timestamp; and the first timestamp and the second timestamp may be different, and the timestamp carried when the data packet is sent to the first charging gateway function is the second timestamp.
  • the first indication value is 128 and the third indication value is 252.
  • FIG. 5 is a flowchart of another method for outputting CDRs according to an embodiment of the present application. As shown in FIG. 5, the process includes the following steps:
  • Step S502 receiving a first request message sent by the charging data function CDF;
  • Step S504 in the case that it is determined that the predetermined charging information for charging is not received according to the first request message, returning a first response message to the CDF, where the first response message is used by the CDF to indicate the second CGF output.
  • the bill corresponding to the predetermined billing information, the second CGF has received the predetermined billing information.
  • the first CGF may be performed to perform the above operation.
  • the first CGF may return a response message specifically for indicating that the first CGF has not received the predetermined charging information, so that the receiving condition of the predetermined charging information of the first CGF may be clarified, thereby avoiding repetition of the bill.
  • the output therefore, can solve the problem of repeated billing due to repeated output of bills, thereby achieving the effect of avoiding repeated input of bills and providing user experience.
  • the method further includes at least one of: returning a second response message to the CDF if it is determined that the predetermined charging information has been received according to the first request message, wherein The second response message is used by the CDF to instruct the second CGF to cancel outputting the bill corresponding to the predetermined billing information; and when determining that the data packet has been received before the first billing gateway function is abnormal, the billing is performed.
  • the data function returns a third response message, wherein the third response message is used by the charging data function to instruct the second charging gateway function to cancel outputting a bill corresponding to the predetermined charging information.
  • the basis for the first CGF to return the second response message may be that the first CGF has received the predetermined charging information. In this case, the first CGF will output the CDR, and the other CGFs do not need to repeatedly output the same message. single.
  • the Cause field of the third response message is 128 Request Accepted. That is, the reason field of the third response message is the first indication value and the request receives Request Accepted.
  • the third response message may use an existing response message to simplify the operation.
  • the cause field of the first response message includes one of the following: a second flag value and a susceptive duplicate packet acceptance (ie, 178 Request related to possibly duplicated packets Accepted); the first flag value and the request to receive (ie, And a type field of the data packet, wherein the type field of the data packet is used to indicate that the request for the current response is a request for a suspicious duplicate packet, and the data packet carries the predetermined charging information.
  • a first identifier and a request to receive ie, 128 Request accepted
  • the first request message carries the first label
  • the first indication value and the request to receive ie, 128 Request accepted
  • carrying a first timestamp wherein the first request message carries the first timestamp.
  • the first indication value is 128.
  • the second indicator value is 178.
  • a Cause field of the first response message is 128 Request accepted and carries a first label
  • a Cause field of the third response message is 128.
  • the second response message is a Cause field that is 252 Request related to possibly duplicated packet already fulfilled and carries the first label, where the first label is different from the second label,
  • the label carried by the CDF when the predetermined charging information is sent is the second label;
  • the reason field of the first response message is 128 Request accepted and carries a first timestamp
  • the Cause field of the third response message is 128 Request accepted and carries a second timestamp
  • the second response message The Cause field is 252 Request related to possibly duplicated packet already fulfilled and carries the first timestamp
  • the first timestamp is different from the second timestamp
  • the CDF sends the predetermined charging information
  • the timestamp carried in is the second timestamp.
  • the Cause field of the first response message is a first identifier value and the request is received and the first label is carried; the Cause field of the second response message is a third identifier value and a suspicious repetition.
  • the packet has received the first label; the Cause field of the third response message is the first identifier value and the request receives the Request accepted and carries the second label;
  • the first label and the second label may be different, and the label carried when the data packet is sent to the first charging gateway function is the second label.
  • the Cause field of the first response message is the first indication value and the request receiving Request accepted and carries a first timestamp; and the Cause field of the second response message is a third indication value.
  • the suspicious duplicate packet has received the request related to possibly duplicated packet already fulfilled and carries the first timestamp;
  • the Cause field of the third response message is the first indication value and the request receives the Request accepted and carries the first The second timestamp; and the first timestamp and the second timestamp may be different, and the timestamp carried when the data packet is sent to the first charging gateway function is the second timestamp.
  • the first indication value is 128 and the third indication value is 252.
  • a method for improving the accuracy of charging transmission during GTP redirection is provided.
  • the CDF sends a suspicious duplicate empty packet (ie, has been sent).
  • the first CGF finds that the node has not received the packet, it responds with a response to the suspicious duplicate empty packet that is different from the normal packet response, and the CDF receives the response.
  • the second CGF of the above notification is redirected to release the packet.
  • Embodiment 1 mainly describes the present application from the CDF side.
  • Embodiment 2 mainly describes the present application from the first CGF side, and the following improves the accurate charging transmission proposed in the embodiment of the present application. Sexual methods are explained.
  • the CDF normally sends a data packet request, and the CGF1 (corresponding to the first CGF mentioned above) replies with a response (Cause is 128 Request Accepted);
  • the CDF sends a suspicious duplicate packet to CGF2 (corresponding to the second CGF mentioned above);
  • CGF1 determines whether the packet sequence number has been received
  • the packet sequence number is not received, a response is sent to the CDF, and the message carries an indication that the sequence number packet is not received (corresponding to the first response message described above).
  • the CDF receives the response message from CGF1.
  • the request for canceling the suspicious duplicate packet is sent to the CGF2 (ie, the CGF2 is instructed to cancel the output of the CDR corresponding to the predetermined charging information), and the CGF2 deletes the suspicious duplicate packet in the cache after receiving the request, and does not output the message. single;
  • the message If the message carries the indication that the sequence number data packet is not received, send a request for releasing the suspicious duplicate packet to the CGF2 (ie, instruct the second CGF to output the CDR corresponding to the predetermined charging information), and the CGF2 outputs the CDR after receiving the request. . (This process is different from existing standards)
  • the CGF2 sends a request to cancel the suspicious duplicate packet, and the CGF2 deletes the suspicious duplicate packet in the cache after receiving the request, and does not output. Bills.
  • FIG. 6 is a schematic diagram of a network architecture for transmitting bills.
  • FIG. 6 is a simple redirection network configuration example.
  • the networking and redirection configuration in the actual application may be more complicated than that shown in FIG. 6. Therefore, the scenario used in this application is not limited to this architecture, and may be applied to the redirection networking.
  • the present application is described with four examples, but is not limited thereto.
  • This implementation method uses the value of the defined cause to indicate that the CGF has not received the request for a suspicious duplicate packet, such as adding "178 Request related to possibly duplicated packets Accepted", and the original "128" Request accepted” to distinguish.
  • FIG. 7 is a schematic flowchart of redirecting anti-weight using the Cause function provided by the present application, which includes the following processing steps:
  • the CDF sends a normal data packet (ie, Send Data Record Packet) to the CGF1.
  • a normal data packet ie, Send Data Record Packet
  • the CDF triggers the redirection, and sends the suspicious duplicate packet to the CGF2 (ie, the Send possible duplicated Data Record Packet).
  • the CDF receives the response message of the CGF1, and includes the following three situations:
  • CGF2 receives the request to cancel the bill, and deletes the suspicious duplicate packet in the cache (ie, delete CDR);
  • CGF2 receives the request to release the CDR and outputs the CDR (ie, send CDR).
  • S701 and S702 there may be other Session Initiation Protocol (SIP) signaling interaction processes (such as CDF retransmission packets, CGF1 redirection, etc.), which are omitted for simplicity.
  • SIP Session Initiation Protocol
  • S703 and S704 there may be other SIP signaling interaction procedures (such as CGF1 Node Alive message, CDF sending ECHO detection message, etc.), which are omitted for simplification.
  • SIP signaling interaction procedures such as CGF1 Node Alive message, CDF sending ECHO detection message, etc.
  • the second indication value in the 178 is only an example of the second indication value.
  • 128 is only an example of the first indication value, the actual value may not be limited thereto.
  • the first indicator value, the second indicator value, and the third indicator value are all different.
  • the request to send a cancel call to CGF2 in S707a) and S707b) may not be performed, but one of them is executed.
  • Packet type notation the content of the reason field of this method response is unchanged, but the information element (IE) field is used to indicate the request for the suspicious duplicate packet.
  • This IE field can be redefined, or a Private Extension field can be used to carry packet type information, and the new IE field is more versatile. This way is forward compatible.
  • FIG. 8 is a schematic flowchart of redirecting anti-weight using the “packet type labeling method” provided by the present application, including the following processing steps:
  • the CDF sends a normal data packet (ie, a Send Data Record Packet) to the CGF1.
  • a normal data packet ie, a Send Data Record Packet
  • CDF triggers redirection, and sends a suspicious duplicate packet to CGF2 (ie, Send possible duplicated Data Record Packet);
  • CGF1 may reply to the response of the normal data packet in S01, and the Cause is "128 Request accepted", and does not carry the data packet type field;
  • the CDF receives the response message, including the following three cases:
  • the CDF sends a request to cancel the CDR to the CGF2 (ie, Cancel Data Record Packet);
  • the CDF sends a request to release the CDR (ie, Release Data Record Packet) to the CGF2.
  • CGF2 receives the request to cancel the CDR, deletes the suspicious duplicate packet in the cache (ie, delete CDR); S808b) CGF2 receives the request to release the CDR, and outputs the CDR (ie, send CDR).
  • SIP signaling interaction processes such as CDF retransmission packets, CGF1 transmission redirection, etc.
  • S801 and S802 which are omitted for simplicity.
  • S803 and S804 there may be other SIP signaling interaction procedures (such as CGF1 sending Node Alive messages, CDF sending ECHO detection messages, etc.), which are omitted for simplification.
  • the third flag value in the 252 is only an example of the third flag value.
  • 128 is only an example of the first flag value, the actual value may not be limited thereto.
  • the first indicator value, the second indicator value, and the third indicator value are all different.
  • FIG. 9 is a schematic flowchart of a process performed by using a message label method according to the present application, including the following processing steps:
  • the CDF sends a normal data packet (ie, a Send Data Record Packet) to the CGF1, and carries a message label, such as a label 1 (tag1).
  • a normal data packet ie, a Send Data Record Packet
  • tag1 a message label
  • the CDF triggers the redirection, sends a suspicious duplicate packet to the CGF2 (ie, Send possible duplicated Data Record Packet), and carries a new message tag, such as tag 2 (tag2).
  • CGF2 ie, Send possible duplicated Data Record Packet
  • tag 2 tag 2
  • S903 The CGF2 caches the suspicious duplicate packet, and the response is sent to the CDF.
  • the Cause is "128 Request accepted” and carries the message tag tag2.
  • CGF1 may reply to the response of the normal data packet in S01, and the Cause is "128 Request accepted", carrying the message tag tag1;
  • S907 The CDF receives the response message and determines whether the message tag and the request match.
  • the CDF sends a request to cancel the CDR to CGF2 (ie, Cancel Data Record Packet).
  • the CDF sends a request to release the CDR (ie, Release Data Record Packet) to the CGF2.
  • CGF2 receives the request to cancel the bill and deletes the suspicious duplicate packet in the cache.
  • CGF2 receives the request to release the bill and outputs the bill.
  • SIP signaling interaction processes such as CDF retransmission packets, CGF1 transmission redirection, etc.
  • S903 and S904 there may be other SIP signaling interaction procedures (such as CGF1 sending Node Alive messages, CDF sending ECHO detection messages, etc.), which are omitted for simplicity.
  • SIP signaling interaction procedures such as CGF1 sending Node Alive messages, CDF sending ECHO detection messages, etc.
  • the label 1, the label 2, and the label 3 are different.
  • the third flag value in the 252 is only an example of the third flag value.
  • 128 is only an example of the first flag value, the actual value may not be limited thereto.
  • the first indicator value, the second indicator value, and the third indicator value are all different.
  • Timestamp method the content of the reason field returned by this method is unchanged.
  • the GTP sends a new request message, it carries the timestamp of the sent message, and the response message carries the timestamp, so that the requesting party CDF can be sent according to the time. Poke to determine the validity of the response.
  • This approach can strictly correspond to requests and responses, but network latency or packet loss can have an impact on processing performance.
  • FIG. 10 is a schematic flowchart of redirecting anti-weight using the “time stamp method” provided by the present application, including the following processing steps:
  • the CDF sends a normal data packet (ie, a Send Data Record Packet) to the CGF1, and carries a timestamp, such as a timestamp timestamp1;
  • a normal data packet ie, a Send Data Record Packet
  • a timestamp such as a timestamp timestamp1
  • the CDF triggers the redirection, sends a suspicious duplicate packet to the CGF2 (ie, Send possible duplicated Data Record Packet), and carries a new message label, such as a timestamp timestamp2;
  • CGF2 caches a suspicious duplicate packet, responds to the CDF, and the cause is "128 Request accepted", carrying the message label timestamp timestamp2;
  • CGF1 may reply to the response of the normal data packet in S01, and the Cause is "128 Request accepted", carrying the message label timestamp timestamp1;
  • CGF1 After receiving the suspicious duplicate empty packet, CGF1 determines whether the suspicious duplicate packet has been received, including the following two situations:
  • the CDF receives the response message, and determines whether the message label and the request match, if not,
  • CGF2 receives the request to cancel the bill and deletes the suspicious duplicate packet in the cache.
  • CGF2 receives the request to release the bill and outputs the bill.
  • S1001 and S1002 there may be other SIP signaling interaction procedures (such as CDF retransmission packet, CGF1 transmission redirection, etc.), which are omitted for simplification.
  • SIP signaling interaction procedures such as CDF retransmission packet, CGF1 transmission redirection, etc.
  • time precision may be milliseconds or subtle or nanoseconds.
  • the third flag value in the 252 is only an example of the third flag value.
  • 128 is only an example of the first flag value, the actual value may not be limited thereto.
  • the first indicator value, the second indicator value, and the third indicator value are all different.
  • the accuracy of charging information transmission between CDF and CGF can be guaranteed when redirection occurs.
  • the generation of heavy orders in the charging transmission can be avoided, thereby improving the accuracy of charging.
  • the method according to the foregoing embodiment can be implemented by means of software plus a general hardware platform, and of course, can also be through hardware, but in many cases, the former is better.
  • Implementation Based on such understanding, the technical solution of the present application can be embodied in the form of a software product stored in a storage medium (such as Read-Only Memory (ROM), Random Access Memory (Random Access Memory).
  • the RAM, the disk, and the optical disk include a plurality of instructions for causing a terminal device (which may be a mobile phone, a computer, a server, or a network device, etc.) to perform the method described in each embodiment of the present application.
  • a bill output device is also provided, which is used to implement the above embodiment, and will not be described again.
  • the term “module” can implement a combination of software and hardware for a predetermined function.
  • the devices described in the following embodiments are preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.
  • FIG. 11 is a structural block diagram of a bill output device according to an embodiment of the present application.
  • the device can be applied to a CDF.
  • the device includes a sending module 112, a first receiving module 114, and a first indicating module. 116, the device is described below:
  • the sending module 112 is configured to send a first request message to the first charging gateway function CGF after determining that the first charging gateway function CGF returns from the abnormal state to the normal state, where the first request message is used to request the first
  • the CGF confirms whether the predetermined charging information for charging is received
  • the first receiving module 114 is connected to the sending module 112, and is configured to receive the first response message returned by the first CGF based on the first request message, where The first response message is used to indicate that the first CGF has not received the predetermined charging information
  • the first indication module 116 is connected to the first receiving module 114, and is configured to receive the first meter when the first receiving module 114 receives
  • the second CGF outputs a CDR corresponding to the predetermined charging information according to the first response message, where the second CGF has received the predetermined charging information.
  • the apparatus further includes: a second receiving module, configured to receive, after sending the first request message to the first CGF, a second response message that is returned by the first CGF based on the first request message, where the second The response message is used to indicate that the first CGF has received the predetermined charging information, and the second indication module is configured to: when the second receiving module receives the first charging gateway function, returning based on the first request message When the second response message is sent, the second CGF is instructed to cancel the output of the bill corresponding to the predetermined charging information according to the second response message;
  • the second receiving module is further configured to receive a third response message returned by the first charging gateway function, where the third response message is a response of the first charging gateway function based on the received data packet
  • the second indication module is further configured to: when the second receiving module receives the third response message returned by the first charging gateway function, indicating the second charging gateway according to the third response message; The function cancels outputting a bill corresponding to the predetermined billing information.
  • the Cause field of the third response message is 128 Request Accepted. That is, the reason field of the third response message is the first indication value and the request receives Request Accepted.
  • the Cause field of the first response message includes one of the following: 178 Request related to possibly duplicated packets Accepted; 128 Request accepted and carries a type field of the data packet, wherein the type field of the data packet is used for The request indicating the current response is a request for a suspicious duplicate packet; 128 Request accepted and carrying the first label, wherein the first request message carries the first label; 128 Request accepted and carries the first timestamp, wherein the first request message is Carry the first timestamp.
  • the first indication value is 128.
  • the second indicator value is 178.
  • the method includes at least one of the following: the Cause field of the first response message is 128 Request accepted and carries the first label, and the Cause field of the third response message is 128 Request accepted and carries the second label, the second response message.
  • the first field is different from the second label.
  • the first label is different from the second label.
  • the label carried when the predetermined charging information is sent to the first CGF is the second label.
  • the Cause field of the message is 128 Request accepted and carries the first timestamp
  • the Cause field of the third response message is 128 Request accepted and carries the second timestamp
  • the Cause field of the second response message is 252 Request related to possibly duplicated packet already fulfilled
  • carrying the first timestamp, the first timestamp and the second timestamp are different, and the timestamp carried when the predetermined charging information is sent to the first CGF is the second timestamp.
  • the first indication value is 128 and the third indication value is 252.
  • FIG. 12 is a structural block diagram of another CDR output device according to an embodiment of the present application.
  • the device may be applied to a first CGF.
  • the device includes a fourth receiving module 122 and a first return module 124.
  • the device is described below:
  • the third receiving module 122 is configured to receive the first request message from the charging data function CDF; the first returning module 124 is connected to the third receiving module 122, and is configured to determine that the unreceived is used according to the first request message.
  • the first response message is returned to the CDF, wherein the first response message is used by the CDF to instruct the second CGF to output a bill corresponding to the predetermined billing information, and the second CGF has received Schedule billing information.
  • the apparatus further includes: a second returning module configured to, after receiving the first request message from the CDF, return to the CDF if it is determined that the predetermined charging information has been received according to the first request message a second response message, wherein the second response message is used by the CDF to instruct the second CGF to cancel outputting the CDR corresponding to the predetermined charging information; or
  • the second returning module is further configured to return a third response message to the charging data function when it is determined that the data packet has been received before the first charging gateway function is abnormal, wherein the third response message is used by the third response message
  • the charging data function instructs the second charging gateway function to cancel outputting a bill corresponding to the predetermined charging information.
  • the Cause field of the third response message is 128 Request Accepted. That is, the reason field of the third response message is the first indication value and the request receives Request Accepted.
  • the reason field of the foregoing first response message includes one of the following: 178 Request related to possibly duplicated packets Accepted; 128 Request accepted and carrying a type field of the data packet, wherein the type field of the data packet is used for The request indicating the current response is a request for a suspicious duplicate packet; 128 Request accepted and carrying the first label, wherein the first request message carries the first label; 128 Request accepted and carries the first timestamp, wherein the first request message is Carry the first timestamp.
  • the method includes at least one of the following: the Cause field of the first response message is 128 Request accepted and carries the first label, and the Cause field of the third response message is 128 Request accepted and carries the second label, the second response message.
  • the first field is different from the first label.
  • the first label is different from the second label.
  • the label carried by the CDF when the predetermined charging information is sent is the second label.
  • the first response message is Cause.
  • the 128 request accepts the field and carries the first timestamp.
  • the Cause field of the third response message is 128 Request accepted and carries the second timestamp.
  • the Cause field of the second response message is 252 Request related to possibly duplicated packet already fulfilled and carries the first A timestamp, the first timestamp and the second timestamp are different, and the timestamp carried by the CDF when sending the predetermined charging information is the second timestamp.
  • each of the foregoing modules may be implemented by software or hardware.
  • the foregoing may be implemented by, but not limited to, the foregoing modules are all located in the same processor; or one or more of the foregoing The modules are located in different processors in any combination.
  • Embodiments of the present application also provide a storage medium including a stored program, wherein the above program executes the above method when executed.
  • the foregoing storage medium may include, but is not limited to, a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.
  • ROM read-only memory
  • RAM random access memory
  • mobile hard disk a magnetic disk
  • optical disk a variety of media that can store program code.
  • Embodiments of the present application also provide a processor for running a program, wherein the program executes the method described above while it is running.
  • Each of the modules or steps of the present application described above may be implemented by a general-purpose computing device, which may be centralized on a single computing device or distributed over a network of multiple computing devices, in one embodiment, They may be implemented by program code executable by a computing device, such that they may be stored in a storage device for execution by a computing device, and the steps shown or described may be performed in an order different than that herein, or Each of the one or more integrated circuit modules is fabricated, or a plurality of the modules or steps are fabricated into a single integrated circuit module.
  • the application is not limited to any particular combination of hardware and software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé et un appareil d'émission de ticket d'appel et un support de stockage. Le procédé comprend les étapes suivantes : après avoir déterminé qu'une première fonction de passerelle de facturation (CGF) repasse d'un état anormal à un état normal, envoyer un premier message de demande à la première CGF, le premier message de demande étant utilisé pour demander à la première CGF de confirmer si des informations de facturation prédéterminées pour la facturation sont reçues; et lorsqu'un premier message de réponse renvoyé par la première CGF sur la base du premier message de demande est reçu, ordonner à une seconde CGF d'émettre un ticket d'appel correspondant aux informations de facturation prédéterminées selon le premier message de réponse, le premier message de réponse étant utilisé pour indiquer que la première CGF n'a pas reçu les informations de facturation prédéterminées, et la seconde CGF a reçu les informations de facturation prédéterminées. L'invention concerne également un appareil d'émission de ticket d'appel et un support d'informations.
PCT/CN2018/093756 2017-06-30 2018-06-29 Procédé et appareil d'émission de ticket d'appel et support de stockage WO2019001574A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710524162.9 2017-06-30
CN201710524162.9A CN108289296A (zh) 2017-06-30 2017-06-30 话单输出方法、装置及存储介质

Publications (1)

Publication Number Publication Date
WO2019001574A1 true WO2019001574A1 (fr) 2019-01-03

Family

ID=62831444

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/093756 WO2019001574A1 (fr) 2017-06-30 2018-06-29 Procédé et appareil d'émission de ticket d'appel et support de stockage

Country Status (2)

Country Link
CN (1) CN108289296A (fr)
WO (1) WO2019001574A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1395384A (zh) * 2001-07-06 2003-02-05 华为技术有限公司 移动通讯系统中计费网关多重重定向实现方法及其装置
CN101127611A (zh) * 2007-09-19 2008-02-20 中兴通讯股份有限公司 Ims网元计费信息综合方法和系统及计费方法和系统
CN103067184A (zh) * 2012-11-26 2013-04-24 大唐移动通信设备有限公司 离线计费的异常处理方法及系统
CN103078748A (zh) * 2013-01-11 2013-05-01 华为技术有限公司 计费系统中的双机切换方法及相关设备、系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101635653B (zh) * 2009-08-31 2012-04-18 杭州华三通信技术有限公司 一种实时性能管理方法和装置
CN103108295B (zh) * 2011-11-11 2017-10-27 中兴通讯股份有限公司 一种话单包的处理方法和系统
US9438748B2 (en) * 2014-09-26 2016-09-06 Alcatel Lucent CDF tracking for offline charging

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1395384A (zh) * 2001-07-06 2003-02-05 华为技术有限公司 移动通讯系统中计费网关多重重定向实现方法及其装置
CN101127611A (zh) * 2007-09-19 2008-02-20 中兴通讯股份有限公司 Ims网元计费信息综合方法和系统及计费方法和系统
CN103067184A (zh) * 2012-11-26 2013-04-24 大唐移动通信设备有限公司 离线计费的异常处理方法及系统
CN103078748A (zh) * 2013-01-11 2013-05-01 华为技术有限公司 计费系统中的双机切换方法及相关设备、系统

Also Published As

Publication number Publication date
CN108289296A (zh) 2018-07-17

Similar Documents

Publication Publication Date Title
US8270943B2 (en) Method and apparatus for reliable transmission of charging detail records
KR102167613B1 (ko) 메시지 푸시 방법 및 장치
US20120221445A1 (en) Method and apparatus for detecting duplicate accounting records in distributed network
US8976676B2 (en) Adaptive signaling for network performance measurement, access, and control
CN109996201B (zh) 一种网络访问方法及网络设备
WO2013067975A1 (fr) Procédé et système pour le traitement d'un paquet d'enregistrement de données
WO2012075934A1 (fr) Procédé de détection de boucle de message, appareil d'agent de routage et système de mise en réseau
CN103036885A (zh) Sip服务器过载保护系统及方法
US20140200041A1 (en) Evaluation of overall performance of interactive application service
CN109792645B (zh) 在边缘云中维护up会话状态信息的方法和装置
WO2019001574A1 (fr) Procédé et appareil d'émission de ticket d'appel et support de stockage
WO2011150688A1 (fr) Procédé et système de facturation pour un service prépayé
CN115617611A (zh) 信令流程图的生成方法、装置、电子设备和存储介质
WO2017203328A1 (fr) Procédé pour fournir des informations de position relatives à une interception légale dans un réseau ims
CN109428817B (zh) 业务链处理方法、相关网元和系统
CN106685697B (zh) 一种异常边际消息数据恢复处理的方法及系统
WO2019001569A1 (fr) Procédé de transfert de ticket d'appel, dispositif de communication et support de stockage lisible par ordinateur
WO2021259026A1 (fr) Entité de fonction de notification de facturation, entité de fonction de facturation, procédé et appareil de traitement d'enregistrements détaillés d'appel, et support de stockage
US11765278B2 (en) Replay agent for delivering charging event messages from a message broker in a mobile telecommunications network
CN112995260A (zh) 一种会话消息交互方法、装置及计算机可读存储介质
CN113923040B (zh) 流量劫持点检测方法、装置、电子设备及存储介质
US8964576B2 (en) System and method of reporting in-service performance statistics in layered networks
CN112866045A (zh) 一种链路状态检测方法、组播设备及链路状态检测系统
CN118317259A (zh) 一种云短信发送方法、装置、设备及存储介质
CN115278938A (zh) 5g基站的本地数据监听方法、装置、设备及存储介质

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

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

Country of ref document: EP

Kind code of ref document: A1

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 28/05/2020)