WO2007051424A1

WO2007051424A1 - A method for monitoring the minus flow and a charging system

Info

Publication number: WO2007051424A1
Application number: PCT/CN2006/002960
Authority: WO
Inventors: Jiaxing Xiao
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2005-11-03
Filing date: 2006-11-03
Publication date: 2007-05-10
Also published as: CN101160814B; CN1960263A; CN100488102C; CN101160814A

Abstract

A method for monitoring the minus flow includes that the function entity for monitoring the minus flow in WiMAX system generates the minus flow information including the total flow; the said minus flow information is wrote into the usage data record of the user, and is reported to the AAA server by the charging information; the AAA server acquires the said minus flow information from the charging information. Also, there are a minus flow detecting device and a WiMAX charging system.

Description

Method for monitoring negative traffic and billing system

Technical field

The present invention relates to the field of communications, and in particular, to a method for monitoring negative traffic and a charging system. Background technique

The network structure of Worldwide Interoperability for Microwave Access (WiMAX) is shown in Figure 1. It is mainly composed of client (MSS/SS), access service network (ASN) and connection. The service network (CSN) consists of three parts.

The ASN includes a base station (BS) and an access service network gateway (ASN GW); the connection service network (CSN) includes a logical entity such as a prepaid server (PPS), an authentication, authorization, and accounting server (AAA Server). Logical entities are connected through interfaces R1 through R6. The specific locations of each interface are shown in Figure 1.

The charging framework in the WiMAX network is shown in Figure 2. The main network elements are MSS/SS, AAA Proxy/Client, Visited AAA Server, and Home AAA Server. , Prepaid Server (PPS), Hot-lining Device (HLD), Hot-lining Application (HLA), etc.

In this paper, the AAA client and the AAA proxy (AAA Proxy) refer to a combination of the control plane and the bearer service layer. The control layer faces the negative traffic information and can carry the service level module from the internal interface. Obtain. In addition, if the part of the control plane is separated from the part of the bearer service plane, that is, if there is a specific control plane entity and a specific bearer layer entity, the entity at the control plane acquires from the bearer layer entity through the interface between them. Negative traffic information.

The MSS/SS is a fixed or mobile user terminal, which mainly acts as a user in charging; the AAA client collects all charging information and sends it to the AAA proxy; the AAA proxy is an optional intermediate device, mainly After the received accounting information is processed, an accounting packet is generated and forwarded to the remote end. AAA server; the visited AAA server is a local AAA server, which is a functional entity for transmitting accounting messages during roaming; the home AAA server is an AAA server where the user originally registered or the user's original attribution, and the user has signed the contract. Information, and is responsible for billing users; PPS mainly deals with online charging of prepaid users, stores the user's bills, and performs real-time deductions for users after the user goes online; HLD and HLA entities are implemented in billing. The entity of the hot line (Hot-lining). The main idea of Hot-lining is to provide a WiMAX operation that effectively solves problems for users who do not have access to packet data services. Since the user has no right to use the data packet service after the user has a problem, for example, if the prepaid user balance is insufficient, the wireless operator will notify the user that the user is already in the hotlining state. If the problem is successfully resolved, the user's data packet service is returned to the normal state. The HLD is an execution device, which is used to notify the user that the device is in the hot-lining state. In addition, the HLA performs some processing on the application layer, that is, provides information for notifying the user, and can provide services such as online recharge by the user.

The negative traffic in the billing is in the communication network based on the flow meter, the network side is abnormal due to the abnormal situation of the user, such as the user's terminal equipment crashes, or shuts down, or restarts or switches to a new network, etc., there is no complete transmission. The traffic generated by the user and the original entire packet that the network side has billed for. From this explanation, it can be seen that the negative traffic is an abnormal traffic, that is, in the process of transmitting data to the user in the network, the client has an abnormality, and the network side does not completely transmit the data required by the user to the user; Due to the existence of caching technology, some data stored in the cache area has passed the core network and has been charged, but not sent to the user, which causes the user's bill to exceed this part of the cost.

In the standard flow metering fee of the WiMAX network, there is no technical solution for separately handling the negative traffic, and only the user bears the charging fee generated by the negative traffic, thus inevitably generating multi-billing and repeated charging for the user. In the case of how to deal with negative traffic, it is an urgent problem for the business. Summary of the invention

The invention provides a method for monitoring negative traffic and a charging system to solve the existing WiMA network Negative traffic cannot be handled separately in the charging of the network, and there is a problem that the charging is inaccurate.

The invention provides the following technical solutions:

A method of monitoring negative traffic includes the following steps:

A functional entity that monitors negative traffic in a WiMAX system generates negative traffic information;

Transmitting the negative traffic information into a usage data record (Usage Data Record), and reporting the charging message to the charging server;

The accounting server acquires the negative traffic information from the charging message.

A negative flow detecting device includes:

a module for receiving data and forwarding the data to a user;

Means for generating negative traffic information when it is detected that the billed data packet is not completely sent to the user, or when it is detected that the data packet has been repeatedly billed;

A module for reporting the negative traffic information.

A billing client/agent device, including:

a module for receiving a message containing negative traffic information;

a module for parsing the negative flow information;

Means for writing the parsed negative traffic information into the user usage data record to generate a charging message;

A module for reporting a charging message containing the user usage data record.

A billing server, comprising:

a module for receiving a charging message containing negative traffic information;

a module for parsing the charging message and extracting negative traffic information therefrom;

A module for performing charging processing on the negative traffic information.

A WiMAX billing system, including:

a functional entity for generating negative traffic information and reporting when it detects that the packet that has been charged is not completely sent to the user, or detects that the data packet has been repeatedly charged; A billing server for obtaining and processing the negative traffic information from the charging message.

The beneficial effects of the present invention are as follows:

1. When the original network charging architecture is stable, only one attribute is added to the RADIUS (Remote Authentication Dial In User Service) message to indicate the negative traffic. The AAA server can separately handle the negative traffic. The method is simple, flexible and effective.

2. Meet the requirement that the negative traffic can be deducted from the user's bill, which ensures the accuracy and rationality of the billing, thus increasing the user's trust in the network operator. DRAWINGS

1 is a schematic structural diagram of an existing WiMAX network;

2 is a schematic structural diagram of a charging system in an existing WiMAX network;

FIG. 3 is a flowchart of processing negative traffic in a normal case according to Embodiment 1 of the present invention; FIG. 4 and FIG. 5 are flowcharts showing negative traffic flow in a case of processing handover according to Embodiment 1 of the present invention; FIG. 6 is a flowchart of Embodiment 1 of the present invention; FIG. 7 is a flowchart of a negative traffic flow in the case of processing handover according to Embodiment 2 of the present invention; FIG. 9 is a schematic structural diagram of a charging client according to an embodiment of the present invention; ;

FIG. 10 is a schematic structural diagram of a charging proxy according to an embodiment of the present invention;

FIG. 11 is a schematic structural diagram of an AAA server according to an embodiment of the present invention. detailed description

The charging client (accounting client) and the charging proxy (accounting proxy) in the present invention are a comprehensive entity including related functional modules of the control plane and the bearer service layer, and the functional modules of the control plane can be accessed through the internal interface. The function module carrying the service level acquires negative traffic information. If the functional module part of the control plane is separated from the functional module part of the bearer service level, that is, if there is a specific control plane entity and a specific bearer layer entity, its control plane entity Negative traffic information is obtained from entities at the bearer level through interfaces between each other.

In the charging part of the WiMAX network, the charging proxy (accounting proxy) sends a downlink data packet to the charging client (accounting client) through the interface of the access service network, and any accounting agent transmits the downlink data packet to the user terminal. Unsent packets cause incorrect billing, and the billing agent (accounting proxy) cannot rebate these charges. At this point, negative traffic is generated. This scenario is called a negative traffic problem that occurs under normal conditions.

In addition, any data buffered in the accounting client (accounting client) releases the air interface data link and sends the buffered data to another charging proxy (accounting proxy) or billing in the event of interface switching. When the client (accounting for the client), it may cause repeated charging, because the data will be charged again at the charging processing point, and a negative traffic problem occurs. This scenario is called the negative traffic problem in the user switching process. Unlike the previous scenario, the system will re-process the data that is not sent to the user and then send it to the user, but only the user's data is second. Sub-billing, which is essentially a problem of negative traffic, is only for the initial, unsent data anomalies.

Aiming at the negative traffic problem in the existing WiMA network according to the flow rate, that is, the data sent from the network side to the user is caused by the user's terminal device crashing, or shutting down, or restarting or switching to a new network. The existing network disconnects the connection, so that the user does not receive the complete data packet that has been charged by the network. In the present invention, the negative traffic information is generated and reported to the functional entity that monitors the negative traffic, such as the AAA client. The billing server, such as the AAA server, obtains the negative traffic bill after the negative traffic information is obtained by the billing server for the operator to handle flexibly. Of course, the bill can be directly rebate or proportionally rebate.

To carry negative traffic information, you can add a device specification attribute (VSA attribute) to the RADIUS (Remote Authentication Dial In User Service) protocol. The specific attribute parameters are as follows: VSA Type Maximum Format Field Access-Access Accounting Accounting Accounting Payload Request Accept Start Stop nterim-Upd Length ate (in octets)

ASN 26/x1 4 integer ASN— 0 0 0 0-1 0-1

Unsent Unsent one

Downlink Downlink

Volume - Volume: In the table, "ASN Unsent Downlink Volume" is the name of the added attribute value. It is used to identify the size of the data that is not sent to the user. The type is "26" in the RADIUS protocol. The value of the word attribute is the first in a subclass. One parameter is "XI", the parameter has 32 bits, which is 4 bytes long, and its value is a decimal integer whose maximum value is 4294967296; this attribute belongs to the "ASNJJnsent_Downlink_Volume" field; "0" means This message is unlikely to appear. "0-1" means it may or may not appear in this message," means that it must appear in this message. The device specification attribute appears in the intermediate charging message and the stop charging message. And it is optional in the middle or stop billing request message.

The following describes the accounting client as the AAA client, the accounting proxy as the AAA proxy, and the accounting server as the AAA server.

Embodiment 1

In this embodiment, the functional entity that monitors the negative traffic is an AAA client, and the AAA client is on the base station BS that accesses the service network ASN. In addition, an AAA proxy (AAA PROXY) exists on the ASN GW as an example for description.

In order to avoid incorrect charging on the AAA Proxy (AAA Proxy), the AAA Proxy notifies the AAA client based on the radio access bearer (AAA Client) to record the negative traffic value, and the AAA Client (AAA Client) outputs the AAA Proxy to the AAA Proxy. The negative traffic report (AAA Proxy) will occur when the radio access bearer is released. The AAA Proxy (AAA Proxy) should not send such data traffic messages to the AAA Client (AAA Client) under any circumstances. If so, the performance of the AAA Proxy (AAA Proxy) and AAA Client (AAA Client) will be generated. Negative flow The volume message is only sent by the AAA client to the AAA proxy). When the AAA proxy (AAA Proxy) receives the negative traffic report released by the AAA client based on the radio access bearer, it writes the size of the negative traffic to the user usage data record UDR (UDR). And send it to the AAA server (AAA Server) through the charging message. The AAA server (AAA Server) should generate a separate negative traffic bill for the user after receiving the negative traffic message sent from the AAA proxy (AAAProxy), so that it can be provided to the operator for processing.

The AAA proxy (AAA Proxy) reports the negative traffic information to the AAA server (AAA). The AAA proxy sends the traffic information to the AAA server. Server ), then the AAA server will generate a separate negative traffic bill for the user. The processing flow is shown in Figure 3:

Step 300: The user goes online through the normal authentication process.

Step 301: Send a data flow from the core network to an AAA proxy (AAA Proxy) on the base station. Step 302: Send a data packet from the AAA proxy (AAA Proxy) to the AAA client (AAA Client) on the base station.

Step 303: The AAA proxy (AAA Proxy) sends a RADIUS real-time update charging request message including the process charging information to the AAA server (AAA Server X).

Step 304: After processing the charging information, the AAA server (AAA Server) sends a RADIUS accounting response to the AAA proxy (AAA Proxy).

Step 305: For some reasons, such as the user's terminal device crashes, or shuts down, or restarts or switches to a new network, the AAA client (AAA Client) finds that the data sent by the user is not received, and the negative occurs at this time. Traffic message (ASN Unsent Downlink Volume message J, and includes the size of the negative traffic.

Step 306: The AAA client writes the negative traffic information into the user usage data record (UDR), and sends a message (ASN Unsent Downlink Volume message) containing the negative traffic information to the AAA proxy (AAA). Proxy), and notify it of negative The traffic flow has been triggered.

Step 307: The AAA Proxy (AAA Proxy) forwards the intermediate or stop charging request message including the user data record (UDR) to the AAA server (AAA Server).

Step 308: After receiving the RADIUS intermediate or end accounting packet with the negative traffic information, the AAA server records the data as a separate accounting bill for the operator to flexibly process.

The negative traffic problem generated in the user switching process can be caused by R6 interface movement or R3/R interface movement.

For the R6 interface to move, the negative traffic flow is triggered by the AAA client when the AAA client is transmitting data to the user equipment through the radio access bearer layer. The process of processing negative traffic on the R6 interface is as shown in Figure 4: Step 400: The user goes online through the normal authentication process.

Step 401: The R6 interface moves due to the movement of the user terminal, and the switching process of the R6 interface movement is triggered. In the handover process of the R6 interface mobile, if there is no data sent to the user in the buffer area of the original AAA client (AAA Client), the user has disconnected the original wireless access bearer layer, resulting in A negative traffic is generated, and a corresponding negative traffic message (ASN Unsent Downlink Volume message) is generated on the original AAA client (AAA Client).

Step 402: The original AAA client sends an ASN Unsent Downlink Volume message to the AAA proxy (AAA Proxy) to notify that the negative traffic flow has been triggered.

Step 403: The serving AAA proxy (AAA Proxy) writes the negative traffic information into the user usage data record (UDR), and sends an intermediate or stop charging request message including the user usage data record (UDR) to the AAA server (AAA Server). ).

After receiving the RADIUS intermediate (real-time) or ending accounting packet with negative traffic information, the AAA server (AAA Server) records it as a separate accounting bill for the operator to handle flexibly.

Step 404: The AAA server returns an accounting response message to the AAA proxy. In the above process, whether or not there is an AAA proxy does not affect the specific implementation. That is, when there is no AAA proxy, the AAA client reports the user data record (UDR) to the AAA server.

In the case of R3/R4 mobility, the flow of negative traffic is triggered by the AAA proxy (AAA Proxy) switch when the AAA client (AAA Client) is sending data to the user through the radio access bearer layer. The processing of the negative traffic flow in the case of the R3/R4 interface movement is as shown in FIG. 5: Step 500: The user goes online through the normal authentication process.

Step 501: The R3/R4 interface moves due to the movement of the mobile user terminal, triggering a handover process of the R3/R4 interface movement. In the process of the R3/R4 interface mobility switching process, the user equipment has disconnected the original radio access bearer in the case that the original AAA client (AAA Client) buffer area still has data that is not sent to the user equipment. The connection of the layers leads to the generation of negative flow. A negative traffic message (ASN Unsent Downlink Volume message) is generated on the original AAA client (AAA Client).

Step 502: The original AAA client sends an ASN Unsent Downlink Volume message to the serving AAA proxy (AAA Proxy) to notify that the negative traffic flow has been triggered.

Step 503: The serving AAA proxy (AAA Proxy) writes the negative traffic information into the user usage data record (UDR), and sends a charging message including the user usage data record (UDR) to the AAA server (AAA Server).

After receiving the RADIUS intermediate or end accounting packet with negative traffic information, the AAA server (AAA Server) records it as a separate accounting bill for the operator to handle flexibly.

Step 504: The AAA server returns an accounting response message to the serving AAA proxy.

Correspondingly, the charging system of the WiMAX network in this embodiment is as shown in FIG. 2, and includes: an AAA client, an AAA proxy (not shown), and an AAA server, where:

The AAA client is configured to generate a negative traffic message and report it to the AAA proxy when it detects that the packet that has been charged is not completely sent to the user, or detects that the data packet has been repeatedly charged. The AAA proxy is configured to: when receiving the negative traffic message, write the negative traffic information to the user usage data record and upload the message to the AAA server by using an intermediate or stop charging request message.

The AAA server is configured to obtain and process a negative traffic message from an intermediate or stop charging request message. Embodiment 2

In this embodiment, the functional entity that monitors the negative traffic is used as the negative traffic detection reporting point in the base station of the ASN, and the AAA client is used as an example on the gateway GW of the ASN.

In order to avoid unreasonable accounting on the authentication, authorization and accounting client/proxy (AAA Client/Proxy), the authentication, authorization and accounting client/proxy (AAA Client/Proxy) will always inform based on wireless access. The negative traffic detection reporting point of the bearer records the negative traffic value of a user. The negative traffic report reported by the negative traffic detection report to the authentication, authorization, and accounting client/proxy (AAA Client/Proxy) occurs only when the radio access bearer is released. The authentication, authorization, and accounting client/proxy (AAA Client/Proxy) should not send such data traffic messages to the negative traffic detection reporting point under any circumstances, but can send a negative traffic reporting message. When the authentication, authorization, and accounting client/proxy (AAA Client/Proxy) receives a negative traffic report from the negative traffic detection reporting point based on the radio access bearer release, it writes the negative traffic size to the user usage data record ( UDR) is sent to the authentication, authorization, and accounting server (AAA Server). The authentication, authorization, and accounting server (AAA Server) should generate a separate negative traffic bill for the user after receiving a negative traffic message from the authentication, authorization, and accounting client/proxy (AAA Client/Proxy). In order to provide it to the operator to handle it.

For the negative traffic triggered by the radio access bearer after the mobile user terminal is receiving the user data, the authentication, authorization, and accounting client/proxy (AAA Client/Proxy) will report the negative traffic information reported by the negative traffic detection reporting point. The authentication, authorization, and accounting server (AAA Server) is sent, and then the accounting server (AAA Server) generates a separate negative traffic bill for the user. The negative traffic processing flow in this scenario is shown in Figure 6:

600, the user goes online through the complete normal authentication process.

601. Authentication, authorization, and accounting client/proxy from the core network to the gateway GW (AAA) Client/Proxy) sends data.

602. The authentication, authorization, and accounting client/proxy (AAA Client/Proxy) sends a data packet to the negative traffic detection reporting point in the base station.

603. The authentication, authorization, and accounting client/proxy (AAA Client/Proxy) sends a RADIUS real-time update charging request message including the flow rate information to the authentication, authorization, and accounting server.

(AAA Server).

604. After processing the charging information, the authentication, authorization, and accounting server (AAA Server) sends a RADIUS accounting response to the authentication, authorization, and accounting client/proxy (AAA Client/Proxy).

605. For some reasons, such as the user's terminal device crashes, or shuts down, it may restart or switch to a new network. The negative traffic detection reporting point determines the transmitted data through the user terminal without feedback success response message. After the user does not receive it, it generates a negative traffic message (ASN Unsent Downlink Volume message) and includes the size of the negative traffic.

606. The negative traffic detection reporting point sends an ASN Unsent Downlink Volume message to the authentication, authorization, and accounting client/proxy (AAA Client/Proxy), and notifies that the negative traffic flow has been triggered.

607. The authentication, authorization, and accounting client/proxy (AAA Client/Proxy) writes negative traffic into the user usage data record (UDR) and sends a message containing the user usage data record (UDR) to the authentication, authorization, and accounting. Fee server (AAA Server).

608. After receiving the RADIUS real-time or end-accounting message with negative traffic information, the authentication, authorization, and accounting server (AAA Server) records it as a separate accounting bill for the operator to handle flexibly.

For the R6 interface mobile situation, the negative traffic flow is triggered when the negative traffic detection reporting point is transmitting data to the user through the radio access bearer layer, and the negative traffic detection reporting point is switched, which is negative for the R6 interface mobile situation. The flow processing process is shown in Figure 7:

700, the user goes online through the complete normal process. 701. The movement of the R6 interface is triggered by the movement of the mobile user terminal, and the switching process of the R6 interface movement is triggered. In the process of the R6 interface mobile switching process, when there is data in the buffer area on the service negative traffic detection reporting point that has not been sent to the user, the user has disconnected the original wireless access bearer layer. , resulting in the generation of negative traffic. A negative traffic message (ASN Unsent Downlink Volume message) is generated at the service negative traffic detection reporting point.

702. The service negative traffic detection reporting point sends the generated ASN Unsent Downlink Volume message to the authentication, authorization, and accounting client/agent (AAA Client Proxy) to notify that the negative traffic process has been triggered.

703. The authentication, authorization, and accounting client/proxy (AAA Client/Proxy) writes negative traffic to the user usage data record (UDR) and sends a message containing the user usage data record (UDR) to the authentication, authorization, and accounting. Fee server (AAA Server).

704. After receiving the RADIUS intermediate charging message or the ending charging message with negative traffic information, the authentication, authorization, and accounting server (AAA Server) records it as a separate accounting bill for the operator to be flexible. Processing, then responding to the Service Authentication, Authorization, and Accounting Client/Proxy (AAA Client/Proxy) intermediate or terminating the charging response message.

In the case of R3 mobility, the negative traffic flow is triggered when the negative traffic detection reporting point is transmitting data to the user through the radio access bearer layer for authentication, authorization, and accounting client/proxy (AAA Client/Proxy) switching. of. The negative traffic processing flow for the R3 interface movement is as shown in Figure 8:

800, the user goes online through the complete normal authentication process.

801. The movement of the R3 R4 interface is triggered by the movement of the mobile user terminal, and the switching process of the R3 interface movement is triggered. In the process of the R6 interface mobile switching process, when there is data in the buffer area on the service negative traffic detection reporting point that has not been sent to the user, the user has disconnected the original wireless access bearer layer. , resulting in the generation of negative traffic. A negative traffic message is generated on the service negative traffic detection reporting point (ASN Unsent Downlink Volume message λ 802. The service negative traffic detection reporting point sends the generated ASN Unsent Downlink Volume message to the service authentication, authorization, and accounting client/proxy (AAA Client/Proxy) to notify that the negative traffic flow has been triggered.

803. The service authentication, authorization, and accounting client/proxy (AAA Client/Proxy) writes the negative traffic to the user in the usage data record (UDR), and sends a charging message containing the negative traffic information to the authentication, authorization, and accounting. Fee server (AAA Server).

804. After receiving the RADIUS intermediate charging message or the ending charging message with negative traffic information, the AAA, the authentication, authorization, and accounting server (AAA Server) records it as a separate accounting bill for the operator to be flexible. Processing, 'Subsequently responding to service authentication, authorization and accounting client/proxy (AAA Client/Proxy) intermediate or terminating charging response messages.

Although the above description is made by taking the negative traffic information generated by the AAA client on the base station in Embodiment 1 or the negative traffic detection reporting point on the base station in Embodiment 2 as an example, the implementation of the present invention is not limited thereto. The general model is implemented in a WiMAX network with a special functional entity. The downlink data is transmitted to the user equipment through the functional entity. After receiving the acknowledgement message, the user equipment receives the acknowledgement message within the specified time. Mode accounting, if the confirmation message is not received within the specified time, it indicates that negative traffic is generated. At this time, the corresponding negative traffic information is generated on the functional entity, and then the negative traffic information is written into the user to use the data record. The fee message is reported to the AAA server for processing. In addition, the functional entity may also actively check whether the data is sent or not, and if it is not sent, generate corresponding negative traffic information. Of course, the functional entity can use both methods to monitor negative traffic. The processing of the negative traffic information is the same as the above, and will not be described again.

As shown in FIG. 9, a negative flow detecting device of the present invention includes: a data receiving and forwarding module 900, a negative flow detecting module 901, and a negative flow information reporting module 902. The data receiving and forwarding module 900 receives the data sent to the user, and forwards the data to the user. The negative traffic detecting module 901 detects that the charged data packet is not completely sent to the user, or detects that the data packet has been repeatedly counted. Time-consuming, generating negative traffic information and saving; negative traffic information reporting module 902 will save the negative traffic information Its gjij AAA agent.

Referring to FIG. 10, a charging client/proxy device in the present invention includes: a receiving module 1000, a parsing module 1010, a charging message generating module 1020, and a sending module 1030. The receiving module 1000 receives the data sent by the network side to the user, and receives the message containing the negative traffic information reported by the negative traffic detecting device (such as the foregoing AAA client); the parsing module 1010 is configured to parse the negative traffic information in the message; The charging information generating module 1020 writes the negative traffic information into the user usage data record to generate a charging message; the sending module 1030 forwards the user data to the traffic detecting device, and reports to the AAA server the data record including the user usage data. Billing message.

Referring to FIG. 11, a charging server device (such as the foregoing AAA server) in this embodiment includes: a receiving module 1100, a negative traffic information parsing module 1110, and a negative traffic processing module 1120. The receiving module 1100 receives the charging message including the negative traffic information; the negative traffic processing module 1120 parses the charging message, and extracts the negative traffic information therefrom; the negative traffic processing module 1120 performs the charging processing on the negative traffic information, such as The negative flow information generates a separate negative flow bill, or the fee corresponding to the negative flow is deducted from the billing.

It is apparent that those skilled in the art can make various modifications and variations to the invention without departing from the spirit and scope of the invention. Therefore, it is intended that the present invention cover the modifications and variations of the invention as claimed.

Claims

Rights request

A method for monitoring negative traffic, characterized in that it comprises the following steps:

Transmitting the negative traffic information into the user usage data record, and reporting the charging message to the charging server;

2. The method of claim 1 wherein the negative flow information comprises at least a magnitude of negative flow.

3. The method according to claim 1, wherein the function entity detects that the charged data packet is not completely sent to the user, or detects that the data packet has been repeatedly charged, generating negative traffic information. .

The method according to claim 1, wherein the functional entity generates negative traffic information when there is a duplicate packet charging in the reference point 3 or reference point 6 handover process.

The method according to any one of claims 1 to 4, characterized in that the functional entity monitoring the negative traffic is set in the base station of the access service network.

6. The method of claim 5, wherein the functional entity is an authentication, authorization, and accounting AAA client.

The method of claim 6, wherein the AAA client reports a negative traffic message to the AAA proxy when the discovery of the wireless access bearer is released.

8. The method according to claim 5, wherein the functional entity monitoring the negative traffic reports the negative traffic information to the AAA client/proxy in the gateway, and the AAA client/proxy writes the negative traffic information. The user uses the data record and reports it to the billing server.

9. The method of claim 1 wherein the billing server generates a separate negative flow bill based on the negative flow information.

10. The method of claim 1 wherein: increasing in the RADIUS protocol The device specification attribute carries negative traffic information.

The method according to claim 10, wherein the device specification attribute comprises: a device specification attribute name, a type, a maximum load length, a format, and/or a domain, and the device specification attribute is only in the middle meter. The fee message and the stop billing message appear as optional items.

12. A negative flow detecting device, comprising:

a module for receiving data and forwarding the data to a user;

Means for generating negative traffic information when the data packet for detecting the 巳 billing is not completely sent to the user, or when it is detected that the data packet has been repeatedly billed;

A module for reporting the negative traffic information.

13. A billing client/proxy device, comprising:

a module for receiving a message containing negative traffic information;

a module for parsing the negative flow information;

Means for writing the parsed negative traffic information into the user usage data record to generate a charging cancellation message;

14. A billing server, comprising:

a module for receiving a charging message for packet negative traffic information;

15. A WiMAX billing system, comprising:

A functional entity for generating negative traffic information and reporting when it is detected that the billed data packet is not completely sent to the user, or when it is detected that the data packet has been repeatedly charged;

A billing server for obtaining and processing the negative traffic information from the charging message.

The WiMAX charging system according to claim 15, wherein the functional entity is an independent entity dedicated to monitoring negative traffic, and data sent to the user equipment is transferred by the entity. hair.

The WiMAX charging system according to claim 15, wherein the function entity is an AAA client set in the base station; and the AAA client detects that the billed data packet is not completely sent. Negative traffic information is generated to the user, or when it is detected that the data packet has been repeatedly charged.

The WiMAX charging system according to claim 17, wherein the negative traffic information is carried by adding a device specification attribute in a RADIUS protocol.

19. The WiMAX billing system according to any one of claims 15 to 18, wherein the billing server generates a separate negative flow bill based on the negative flow information.