WO2006015550A1

WO2006015550A1 - A method for distributing the dialog number of the charging based on the packet data flow

Info

Publication number: WO2006015550A1
Application number: PCT/CN2005/001240
Authority: WO
Inventors: Xiaoqin Duan
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2004-08-11
Filing date: 2005-08-11
Publication date: 2006-02-16
Also published as: CN100542097C; CN1735021A

Abstract

A method for distributing the dialog number of the charging based on the packet data flow includes: the message sender distributing the dialog number; or the message receiver distributing the dialog number; or the message sender distributing the first part dialog number, the message receiver distributing the second part dialog number, the said first part of the dialog number and the said second part of the dialog number make up the whole dialog number. The said message sender is the TPF, the said message receiver is the CRF; or the said message sender is the TPF, the message receiver is the OCS, and so on. The massage sender and the message receiver use the distributed dialog number to identify the information interacted in one dialog between the message sender and the message receiver. This invention make the distributing entity of the dialog number clear, and can uniquely identify the dialog between the message receiver and the message sender by the dialog number so as to make the charging flow based on the packet data flow more completely.

Description

A dialog number allocation method based on packet data flow charging

Technical field

The present invention relates to the field of packet data charging, and more particularly to a method for assigning a session number based on packet data stream charging. Background of the invention

With the gradual wide application of packet data services, how to accurately and reasonably charge packet data services has become a common concern of operators.

FIG. 1 shows a packet data protocol context (PDP Context, Packet Data Protocol Context) activation, data transmission, deactivation flowchart, as shown in FIG. 1, in a general packet radio service (GPRS, General Packet Radio Service), activated The PDP Context, the data interaction with the external packet data network (PDN, Packet Data Network), and the process of deactivating the PDP Context include the following steps:

Step 101: The mobile terminal (MS) sends a PDP Context Request (Active PDP Context Request) to the Serving GPRS Support Node (SGSN), where the Activate PDP Context Request carries the network layer service access point identifier. (NSAPI, Network Layer Service Access Point Identifier), PDP type, Access Point Name (APN, Access Point Name), required Quality of Service (QoS) parameters, Transaction Identifier (TI), etc., where NSAPI is The SGSN and the Gateway GPRS Support Node (GGSN) are used as part of the Tunnel Identifier (TID) to identify the PDP Context. The PDP type includes the end-to-end protocol (PPP, Peer- Peer Protocol type, Internet Protocol (IP) type, etc.; APN can be provided by the MS to the SGSN, and the SGSN is addressed to the corresponding GGSN according to the APN, the GGSN root The MS may not provide the APN to the SGSN according to the APN. The SGSN may select the default APN according to the subscription information of the MS user. The QoS parameter is the quality requirement of the packet data service specified by the MS. ΉUsed by the MS to identify a PDP context

Step 102: After receiving the Activate PDP Context Request, the SGSN performs security check and encryption with the MS. This step is optional.

Step 103: The SGSN parses the address information of the GGSN according to the APN. If the SGSN can parse the address information of the GGSN according to the AP, the TEID is created for the PDP Context, and the TEID can be an International Mobile Subscriber Identity (IMSI) and an NSAPI. The SGSN sends a PDP Context Request to the GGSN. The PDP Context Request contains the PDP type, PDP address, APN, QoS parameters, TEID, and selection mode. The PDP address can be MS. The IP address is an optional parameter. The PDP Context creation request may not carry the PDP address. In this case, the GGSN may assign an IP address to the MS in the subsequent processing, or may assign an IP to the MS by the PDN that finally establishes a connection with the MS. Address; The selection mode refers to the APN selection mode, that is, whether the APN is selected by the MS or selected by the SGSN. If the SGSN cannot resolve the address information of the GGSN according to the APN, the SGSN rejects the PDP Context activation request initiated by the MS.

Step 104: After receiving the PDP Context creation request, the GGSN determines an external PDN according to the APN, then allocates a Charging ID, initiates charging, and negotiates QoS. If the GGSN can meet the quality of service requirements of the QoS parameter, the SGSN sends the SGSN to the SGSN. The PDP Context Create Response (Representation PDP Context Response), which carries the TEID, the PDP address, the Backbone Bearer protocol, the agreed QoS parameters, and the Charging ID. If the GGSN cannot meet the quality of service requirements of the QoS parameters, the GGSN rejects the PDP Context creation request initiated by the SGSN. The SGSN then rejects the PDP Context activation request initiated by the MS.

Step 105: After receiving the PDP Context creation response, the SGSN inserts NSAPI and GGSN address information for identifying the PDP Context in the PDP Context, and selects a radio priority according to the agreed QoS parameter, and then returns a PDP Context activation response to the MS (Activate PDP Context Accept), the PDP Context activation response carries information such as PDP type, PDP address, TI, agreed QoS parameters, wireless priority, PDP configuration options, and the like. And, the SGSN starts charging. Upon receiving the PDP Context activation response, the MS has established a direct route between the MS and the GGSN, and can perform packet data transmission.

Step 106: The MS performs packet data interaction through the SGSN, the GGSN, and the PDN. Step 107: After ending the packet data interaction, the MS sends a PDP Context Deactivation Request (Deactivate PDP Context Request) to the SGSN, where the PDP Context Deactivation Request carries a defect.

Step 108: After receiving the PDP Context deactivation request, the SGSN performs security check and encryption with the MS. This step is an optional step.

Step 109 to step. Ill: The SGSN sends a PDP Context Request to the GGSN, and the PDP Context delete request carries the TEID.

After receiving the PDP Context deletion request, the GGSN ends the charging of the MS, deletes the PDP Context corresponding to the TEID, and then sends a PDP Context Response (DDP) to the SGSN. The PDP Context delete response carries the TEID. After receiving the PDP Context deletion response, the SGSN ends the charging of the MS, deletes the PDP Context corresponding to the TEID, and then sends a PDP Context Deactivation Response (Deactivate PDP Context Response) to the MS. The PDP Context deactivation response carries the TI. . After receiving the PDP Context deactivation response, the MS deletes the PDP Context corresponding to ΤΙ.

As can be seen from the implementation process described in FIG. 1, in the current GPRS charging system, since the starting point of charging is set when the PDP Context is activated, the charging termination point is set in the POP Context. When deleting, it can only be charged according to the data traffic transmitted by the PDF Context, or according to the length of time the PDP Context is activated. However, in actual applications, after the MS interacts with the PDN, the MS can perform multiple services based on an activated PDP Context, that is, if the PDN can provide multiple services, such as email (email), Based on the WAP (Wireless Application Protocol) browsing service and the file transfer protocol (FTP) file transfer service, the MS can pass an activated PDP after establishing a transmission channel with the PDN. The Context carries various services that the PDN can provide. However, the operator is likely to adopt different charging methods for the charging modes of various services. For example, for the email receiving and dispatching service, the charging and receiving events can be triggered based on the email, and the WAP browsing service can be based on the flow accounting fee. For the file transfer service, the rate of the WAP browsing service and the rate of the file transfer service are different according to the flow rate. Thus, according to the existing GPRS charging system, the same PDP Context cannot be carried differently. The service performs differentiated billing.

For the above, the third Generation Partnership Project (3GPP, The 3rd Generation Partnership Project ) is currently discussing how to implement IP-based billing data streams (FBC, Flow Based Charging) ₀ for a packet data service, MS users When using this service, all IP data streams (IP Flow) transmitted and received may also be IP packets, which are collectively referred to as Service Data Flow, that is, the service data stream is multiple IP data. The set of flows is composed, so the charging based on the IP data stream can truly reflect the occupation of resources by a certain service data flow. IP data stream-based charging can be considered as filtering out IP data streams of different services carried in the same PDP Context through filters of similar filters, and then separately charging IP data streams filtered by different filters. In order to achieve separate billing for different business data streams. In this way, the granularity of the IP data-based charging is much smaller than the charging granularity based on a PDP Context. The granularity can be regarded as the size of the screening hole. The charging granularity based on a PDP Context is a PDP Context. The meshing granularity based on the IP data stream is an IP service data stream is a sieve hole, that is, a plurality of sieve holes are included for one PDP Context, and therefore, the charging and ratio based on the IP data stream is based on Compared to the charging of a PDP Context, IP data stream based charging can provide operators or service providers with more abundant charging means.

The 3GPP describes the system structure, functional requirements, and message interaction procedures of the FBC. The FBC system structure supporting online charging is shown in Figure 2A. The customized application based on mobile network enhanced logic (CAMEL, Customised Application for Mobile Network Enhanced Logic (SCP) Service Control Point (SCP) and Service Data Flow Based Credit Control Function (CCF) 202 constitute an online charging system (OCS, Online Charging System ) 206. The CCF 202 communicates with the Service Data Flow Based Charging Rule Function (CRF) 203 through the Ry interface, and the CRF 203 communicates with the Application Function Entity (AF) through the Rx interface. The CRF 203 communicates with the Traffic Plane Function (TPF) 205 through the Gx interface, and the CCF 202 communicates with the TPF 205 through the Gy interface.

The structure of the FBC system supporting offline charging is as shown in FIG. 2B. The CRF 203 communicates with the AF 204 through the Rx interface, the CRF 203 communicates with the TPF 205 through the Gx interface, and the TPF 205 communicates with the charging gateway function entity through the Gz interface (CGF, Charging). The Gateway Function 207 is interworking with a Charging Collection Function (CCF) 208.

The TPF 205 carries the IP data stream. When the bearer of the IP data stream is established, the TPF 205 sends a charging rule request to the CRF 203 through the Gx interface, where the charging rule request carries information related to the user and the MS, bearer characteristics, and Network related information, etc., wherein the information related to the user and the MS may be a mobile station international number (MSISDN), an international mobile subscriber identity (IMSI), etc., and the network related information may be a mobile network coding (MNC), a mobile country. Code (MCC) and so on. In addition, since the bearer is modified during the IP data stream transmission process, such as renegotiating the QoS parameters, when the QoS parameters of the same service are different, the charging rules may be different, such as the corresponding rate of the QoS parameter falling. Also fell. At this time, the TPF 205 may resend the charging rule request to the CRF 203 to request a new charging rule when the bearer is modified; the CRF 203 selects an appropriate charging rule according to the above input information provided by the TPF 205, and returns to the TPF 205. The selected charging rule includes charging mechanism, charging type, charging key, service data flow filter, and charging rule priority. The charging mechanism may be online charging or offline charging; the charging type may be charging based on the length of time or based on data traffic; the charging button is a parameter related to the charging rate, CRF 203 The billing rate may not be provided directly to the TPF 205, but only the billing rate related parameters are provided to the TPF 205; the service data filter is used to indicate which IP data streams the TPF 205 filters, and then the TPF 205 is based on the charging rules. The filtered IP data stream is charged. The service data filter may include an IP5 tuple. The IP5 tuple may include source/destination IP address, source/destination port number (Port Number), protocol identifier (Protocol ID), and the like. For example, CRF 203 indicates TPF 205 to source address. Filters the IP data stream of 10.0.0.1, the destination address is 10.0.0.2, the source/destination port number is 20, the protocol type is Transmission Control Protocol (TCP), and the filtered IP data stream is calculated according to the charging rule. fee.

The CRF 203 may provide a trigger event (Event Trigger) to the TPF 205 to request the TPF 205 to request a new charging rule from the CRF 205 when a specific event occurs, such as the CRF 203 requesting the TPF 205 to perform an event modification on some bearers. At the time, a new charging rule is requested from the CRF 203.

In addition to selecting an appropriate charging rule based on the input information provided by the TPF 205, the CRF 203 may also select an appropriate charging rule based on the input information of the AF 204 or the OCS 206, such as the AF 204 notifying the CRF 203 of the service currently used by the user. Type, CRF 203 selects the corresponding charging rule according to the type of service. The OCS 206 is composed of two functional entities, the SCP 201 and the CCF (Service Data Flow Based Credit Control Function) 202. The CCF (Service Data Flow Based Credit Control Function) 202 is a functional entity that performs credit control and is applied only to online charging. The system can be implemented by adding new functions to the existing OCS 206. In the online charging process, the CCF (Service Data Flow Based Credit Control Function) 202 manages and controls the user credit. When the user uses the service, the CCF (Service Data Flow Based Credit Control Function) 202 is in the user credit pool. The credit is authenticated, and the credit that the user can use is delivered to the TPF 205 through the Gy interface.

Corresponding to the GPRS network, the TPF 205 is a GGSN, the AF is a service gateway or a service server in the PDN, and the CRF 203 is a new logical entity. TPF 205 is the enforcement point of the charging rule, and CRF 203 is the control point of the charging rule. And different conversations are identified by the conversation number, that is, when the bearer is established, the TPF requests the charging rule from the CRF, and identifies the conversation established between the TPF and the CRF through the conversation number. In the process of subsequent bearer modification and bearer deletion, when the TPF needs to re-request the charging rule to the CRF, the TPF identifies the current charging rule request by the session number based on the correspondence between the previously established conversations; likewise, the CRF needs to take the initiative. When the charging rule is provided to the TPF, if the CRF receives the input information provided by the AF or the OCS for determining the charging rule, the CRF also needs to identify the correspondence between the currently provided charging rule and the previously established session by using the session number. .

The significance of establishing a dialogue between two entities is to establish a state machine between the two entities so that the two entities can directly use the data in the state machine for subsequent interactions without having to provide relevant information for each interaction. For example, when the bearer is established, the TPF needs to provide CRJF with related information such as user information, bearer attributes, and network information. After the TPF establishes a dialogue with the CRF, both the TPF and the CRF store the related information, which is followed by the TPF and the CRF. During the interaction process, such as bearer modification, bearer deletion, etc., the sender does not need to provide these to the receiver. Relevant information, but only provide the dialogue number to identify the corresponding dialogue.

Although the specification defines communication between CRF and TPF through dialogue, the specification does not indicate how the session number used to identify the conversation is allocated, resulting in the implementation uncertainty of the existing process. Summary of the invention

In view of the above, an object of the present invention is to provide a session number allocation method based on packet data stream charging, so that the implementation of each flow based on packet data stream charging is more complete.

In order to achieve the above object, the present invention provides a session number assignment method based on packet data stream charging, the method comprising the step A1: the message sender assigns a session number.

The step A1 further includes a step B1: the message sending direction message receiving party provides the assigned session number.

The sender of the message is a TPF.

The message receiver is CRF, and the step B1 is: The TPF provides the CRF with the assigned session number, and the session number is carried in the charging rule request.

The step B1 further includes: when the CRF provides a charging rule to the TPF, the session number is further provided to the TPF.

The message receiver is an OCS, and the step B1 is: The TPF provides the OCS with the assigned session number, and the session number is carried in the credit request.

The step B1 further includes: when the CRF returns the credit of the user to the TPF, the session number is further provided to the TPF.

The step B1 further includes: the message sender and the message receiver use the session number to identify information of interaction between the message sender and the message receiver in the session.

The present invention also provides a method for assigning a session number based on packet data stream charging, the method comprising the step A2: the message receiver assigns a session number. The step A2 further includes a step B2: the message receiving direction message sender provides the assigned session number.

The message recipient is CRF.

The message receiver is CRP, and the step B2 is: The CRF provides the assigned session number to the TPF, and the session number is carried in the message providing the charging rule.

The message recipient is OCS.

The sender of the message is a TPF, and the step B2 is: The OCS provides the assigned session number to the TPF, and the session number is carried in the message providing the user credit.

The step B2 further includes: the message sender and the message receiver use the session number to identify information of interaction between the message sender and the message receiver in the session.

The present invention also provides a method for assigning a conversation number based on packet data flow charging, the method comprising the following steps:

A3. The message sender allocates the first part of the conversation number;

B3. The message receiver allocates a second part of the conversation number, and the first part of the conversation number and the second part of the conversation number form a complete conversation number.

The step A3 further includes: the message sending direction message receiving party provides the allocated first part of the session number; the step B3 is: the message receiving party assigns the second part of the session number, and the allocated second part of the session number and the received first part The dialogue number constitutes the complete conversation number.

The step B3 further includes a step C3: the message receiving direction message sender provides a complete session number.

The message sender is a TPF, and the message receiver is a CRF. The step A3 is: The TPF provides the first part of the assigned session number to the CRF, and the first part of the session number is carried in the charging rule request.

The step C3 is: The CRF provides a complete dialog number to the TPF, and the complete session number is carried in the message providing the charging rule. The message sender is a TPF, and the message receiver is an OCS. The step A3 is: The TPF provides the first part of the assigned session number to the OCS, and the first part of the session number is carried in the credit request.

The step C3 is: The OCS provides a complete conversation number to the TPF, and the complete conversation number is carried in the message providing the user credit.

The step C3 further includes: the message sender and the message receiver use the session number to identify information of interaction between the message sender and the message receiver in the session.

According to the present invention, in the packet data stream based charging, the allocation entity of the session number is clarified, and the session between the message sender and the message receiver can be uniquely identified by the session number, so that the processes based on the packet data stream charging are performed. The implementation is more complete. Moreover, the present invention provides a plurality of methods for allocating dialog numbers, providing a flexible choice for practical applications. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows the PDP Context activation, data transmission, deactivation flowchart; Figure 2A shows the structure of the FBC system supporting online charging;

Figure 2B shows a block diagram of an FBC system supporting offline charging;

FIG. 3 is a schematic diagram showing a process of assigning a conversation number to a message sender;

Figure 4 is a schematic diagram showing the process of assigning a conversation number to a message receiver;

Figure 5 shows a schematic diagram of a process in which a message sender and a message receiver jointly allocate a session number;

Figure 6 shows a schematic diagram of an application example of a dialog number;

Fig. 7 shows a schematic diagram of another application example of the session number. Mode for carrying out the invention

In order to make the objects, technical solutions and advantages of the present invention more clear, the following The invention is further described in detail.

In the present invention, in the implementation process based on packet data stream charging, when the session is established, the message sender can be assigned a session number and then provided to the message receiver; the message receiver can also be assigned a session number and then provided to the message sender. During the subsequent interaction between the two parties, the message sender and the message receiver use the assigned session number to identify the information exchanged in a conversation between the two. The sender of the message described above refers to the party that originally sent the message. The sender of the message described above is TPF, the receiver of the message is CRF; or the receiver of the message is TPF, the receiver of the message is OCS, and so on.

To ensure the uniqueness of the assigned session number, the assigned session number may be a combination of the address information of the network entity to which the session number is assigned and the random number, and the address information of the assignor may be an IP address or a network entity in the SS7 network. Address information.

FIG. 3 shows a schematic diagram of a process in which a message sender allocates a session number. As shown in FIG. 3, the process of implementing a message number assigned by a message sender includes the following steps:

Step 301: The user equipment (UE) sends a Bearer Service Request (Set Bearer Service Request) to the TPF. In the GPRS network, the GGSN receives the Create PDP Context Request,

Step 302: After receiving the bearer setup request, the TPF allocates a session number for the current session, and then sends a charging rule request (Request Charging Rules) to the CRF, where the charging rule request carries the input information for the CRF to determine the charging rule. The assigned conversation number.

Step 303: After receiving the charging rule request, the CRF may further input information according to the charging rule request according to the input information provided by the AF, and if it is an online charging mode, may also input related information according to the OCS. , select the appropriate billing rules.

Step 304: After selecting an appropriate charging rule, the CRF returns a Provision Charging Rules to the TPF as a response to the charging rule request, where the provided charging rule may carry the selected charging rule. , charging rule operation indication and TPF in step 302 The assigned session number, by which the correspondence between the current charging rule response and the previous charging rule request is identified.

Step 305: After receiving the charging rule, the TPF indexes to the corresponding session according to the session number, and performs corresponding operations on the charging rule selected by the CRF according to the charging rule operation instruction. If the online charging mode is performed, the TPF continues to execute. Step 306 to step 308, if it is the offline charging mode, step 308 is directly executed.

Step 306: The TPF allocates a session number to the current session according to the online charging indication in the charging rule, and then sends a credit request (Credit Request) to the OCS to request the user's credit information from the OCS.

Step 307: After receiving the credit request, the OCS determines the credit of the user, and then returns a credit response (Credit Response) to the TPF. If the OCS determines the credit of the user, the credit response carries the credit and TPF of the user in step 306. The assigned session number; if the OCS does not determine the credit of the user, the credit response may carry an error reason value and a session number assigned by the TPF in step 306, by which the current credit response and the previous credit request are identified. Correspondence.

Step 308: The TPF returns an bearer setup response (Establish Bearer Service Accept) to the UE. If the TPF can establish a bearer according to the existing information, if the OCS returns the credit of the user, the bearer setup response is a bearer setup success response, and the TPF accepts the UE to initiate the response. The bearer setup request, and the subsequent bearer setup process is continued; if the TPF cannot establish a bearer according to the existing information, for example, the OCS does not return the credit of the user, the bearer setup response is a bearer setup failure response, and the TPF rejects the bearer setup request initiated by the UE. .

FIG. 4 shows a schematic diagram of a process in which a message receiver allocates a session number. As shown in FIG. 4, the process of implementing a message number assigned by a message recipient includes the following steps:

Step 401 is the same as step 301.

Step 402: After receiving the bearer modification request, the TPF sends a charging rule request to the CRF. The charging rule request carries input information for the CRF to determine the charging rule.

Step 403 is the same as step 303.

Step 404: After selecting an appropriate charging rule, the CRF allocates a session number to the current session, and returns a charging rule to the TPF. The charging rule may carry the selected charging rule, the charging rule operation instruction, and The assigned conversation number.

Step 405 is the same as step 305.

Step 406: The TPF sends a credit request to the OCS according to the online charging indication in the charging rule, and requests the credit of the user from the OCS.

Step 407: After receiving the credit request, the OCS determines the credit of the user, and assigns a conversation number to the current conversation, and then returns a credit response to the TPF. If the OCS determines the credit of the user, the credit response carries the credit and allocation of the user. The conversation number; if the OCS does not determine the credit of the user, the credit response may carry the error reason value and the assigned conversation number.

Step 408 is the same as step 308.

Due to network networking, the sender and receiver of the message may not belong to the same network. Therefore, the session number between the sender and the receiver needs to be globally unique, so that the session number assigned by different entities will not be repeated. Entities can be properly indexed to the corresponding conversation by the conversation number. Generally, the message sender and the receiver can allocate the session number by adding a randomly assigned sequence number to the address information identifying the own network entity, and the assigned session number is globally unique. However, since the content of the information used to identify the address of the network entity is relatively large, if the address information of the network entity that assigns the session number is used as part of the session number, the content of the session number will be excessive, and in each transmission The message carries the session number, which may over-occupy the resources of the messaging entity. Therefore, the message sender and the message receiver can share the session number together. For example, the message sender can uniquely identify the session in the assigned entity. The identification information is used as a part of the conversation number, and is filled in a fixed position of the complete conversation number. For example, when the complete conversation number is a parameter in the message, the sender of the message will be fixedly The part of the dialog number is filled in the first 3 digits of the complete dialog number parameter; for example, when the complete dialog number is two parameters in the message, the sender of the message fills in the part of the conversation with the message sender's conversation in the message. On the parameter, then the message recipient is provided with the part of the session number assigned by the message recipient. The message receiver will identify the identity information of the own entity that can uniquely identify the session as a partial session number, and fill in the fixed position of the complete session number, such as When the complete session number is a parameter in the message, the message receiver fixedly fills the allocated part of the session number in the last 3 digits of the complete session number parameter; for example, when the complete session number is two parameters in the message, The message receiver fills in the assigned part of the conversation number on the message receiver dialog number parameter in the message. The partial conversation number shared by the message sender and the message receiver constitutes a complete conversation number, which is used to pass between the message sender and the message receiver, and identifies a message between the sender of the message and the receiver of the message. The information that interacts in the conversation.

FIG. 5 shows a schematic diagram of a process in which a message sender and a message receiver jointly allocate a session number. As shown in FIG. 5, the implementation process of the message sender and the message receiver jointly assigning a session number includes the following steps:

Step 501 is the same as step 301.

Step 502: After receiving the bearer setup request, the TPF allocates a partial session number to the current session, and then sends a charging rule request to the CRF, where the charging rule request carries the input information for the CRF to determine the charging rule and the allocated partial session. number.

Step 503 is the same as step 303.

Step 504: After selecting an appropriate charging rule, the CRF allocates a partial session number to the current session, and forms a complete session number with the partial session number allocated by the TPF in step 502, and provides a charging rule to the TPF, and the charging rule is provided. The selected charging rule, the charging rule operation indication, and the complete conversation number jointly allocated by the TPF and the CRF may be carried in the middle.

Step 505 is the same as step 305.

Step 506: The TPF allocates a partial session number to the current session, and then sends a credit to the OCS. Request, request the user's credit information from the ocs.

Step 507: After receiving the credit request, the OCS determines the credit of the user, and allocates a partial conversation number for the current conversation, and forms a complete conversation number with the partial conversation number allocated by the TPF in step 306, and then returns a credit response to the TPF, if the OCS determines If the credit of the user is out, the credit response carries the credit of the user and the complete conversation number jointly allocated by the TPF and the OCS; if the OCS does not determine the credit of the user, the credit response may carry the error cause value and the TPF and the OCS. The complete dialogue number assigned together.

Step 508 is the same as step 308.

For the convenience of description, the manner in which the session number is assigned between the TPF and the OCS in each of the above figures is described as the same manner as the allocation of the session number between the TPF and the CRF. In practical applications, the session number is assigned between the TPF and the OCS. There is no relationship between the way of assigning the conversation number between the TPF and the CRF, and the same or different, and the specific dialog number assignment method can be arbitrarily selected.

FIG. 6 is a schematic diagram of an application example of a dialog number. As shown in FIG. 6, in this example, when a bearer modification is performed, a previously assigned session number may be applied to identify an interaction between a message sender and a message receiver in a session. The information is described as follows:

Step 601: The UE sends a Modify Bearer Service Request to the TPF. In the GPRS network, the GGSN receives the PDP Context Request (Update PDP Context Request).

Step 602: After receiving the bearer modification request, the TPF sends a charging rule request to the CRF, where the charging rule request carries the input information for the CRF to determine the charging rule and the previously assigned session number, to identify the current message and the previous message. The correspondence between established conversations.

Step 603 to step 604: After receiving the charging rule request, the CRF may, according to the input information carried in the charging rule request, select an appropriate charging rule according to the related input information provided by the AF, and then return the provisioning to the TPF. The fee rule, the provided charging rule may carry the selected charging rule, the charging rule operation instruction, and the corresponding session number. Step 605: After receiving the charging rule, the TPF indexes the corresponding session according to the session number, and performs corresponding operations on the charging rule selected by the CRF according to the charging rule operation instruction. If the online charging mode is performed, the TPF continues to execute. Step 606 to step 608, if it is the offline charging mode, step 608 is directly executed.

Step 606 to step 607: The TPF sends a credit control request (Credit Control Request) to the OCS according to the online charging indication in the charging rule, and requests the credit of the user to the OCS, where the credit control request carries the previously assigned session number. Used to identify the correspondence between the current message and the previously established conversation. After receiving the credit control request, the OCS determines the credit of the user, and then returns a credit control response (Credit Control Response) to the TPF. If the OCS determines the credit of the user, the credit control response carries the credit of the user and the corresponding conversation number. If the OCS does not determine the credit of the user, the credit control response may carry an error cause value and a corresponding conversation number.

Step 608: The TPF returns a Modify Bearer Service Accept to the UE. If the TPF can modify the bearer according to the existing information, for example, the OCS returns the credit of the user, the bearer modification response is a bearer modification success response, and the TPF accepts The bearer modification request initiated by the UE, and the subsequent bearer modification process is continued; if the TPF cannot modify the bearer according to the existing information, for example, the OCS does not return the credit of the user, the bearer modification response is a bearer modification failure response, and the TPF rejects the UE initiation. Bearer modification request.

FIG. 7 is a schematic diagram of another example application of a dialog number. As shown in FIG. 7, in this example, when a CRF actively sends a charging rule to a TPF, the previously assigned session number may be used to identify a message sender in a session. The information exchanged with the message receiver is as follows: Step 701: The CRF receives an internal or external Trigger Event and information related to the event, such as the AF sends a report to the CRF. The fee rule selects the event for entering information.

Step 702: The CRP selects an appropriate charging rule according to the obtained input information. These losses The incoming information may be the charging related input information provided by the AF. For example, the user uses a certain service provided by the AF, and the service has special requirements for charging, for example, the charging rate is different from the charging rate of other services, therefore, The AF provides charging input information related to the service to the CRF; and may also be charging related input information provided by the TPF.

Step 703: If the charging rule changes, the CRF sends a charging rule to the TPF, where the provided charging rule may carry the selected charging rule, the charging rule operation indication, and the previously assigned session number, to identify The correspondence between the current message and the previously established conversation.

Step 704: After receiving the charging rule, the TPF indexes the corresponding session according to the session number, and performs corresponding operations on the charging rule selected by the CRF according to the charging rule operation instruction. If the online charging mode is performed, the TPF continues to execute. Step 705 to step 706.

Step 705 to step 706: The TPF sends a credit request to the OCS according to the online charging indication in the charging rule, and requests the user's credit information to the OCS, where the credit request carries the previously assigned session number, which is used to identify the current message and The correspondence between previously established conversations. After receiving the credit request, the OCS determines the credit of the user, and then returns a credit response to the TPF. If the OCS determines the credit of the user, the credit response carries the credit of the user and the corresponding conversation number. If the OCS does not determine the credit of the user. The credit response may carry an error reason value and a corresponding conversation number.

In summary, the above description is only the preferred embodiment of the present invention and is not intended to limit the scope of the present invention.

Claims

Claim

A method for assigning a conversation number based on packet data stream charging, characterized in that the method comprises:

Al, the message sender assigns a conversation number.

2. The method according to claim 1, wherein the step A1 further comprises:

B1. The message sending direction provides the assigned session number to the message receiver.

The method according to claim 1 or 2, wherein the sender of the message is a TPF.

The method according to claim 3, wherein the message receiver is a CRF, and the step B1 is: the TPF provides an assigned session number to the CRF, and the session number is carried in the charging rule request.

The method according to claim 4, wherein the step B1 further comprises: when the CRF provides a charging rule to the TPF, further providing the session number to the TPF. .

The method according to claim 3, wherein the message receiver is an OCS, and the step B1 is: the TPF provides an assigned session number to the OCS, and the session number is carried in the credit request.

The method according to claim 6, wherein the step B1 further comprises: when the CRF returns the credit of the user to the TPF, further providing the conversation number to the TPF.

The method according to claim 2, wherein the step B1 further comprises: the message sender and the message receiver identify, by the session number, an interaction between the message sender and the message receiver in a session Information.

9. A method for assigning a conversation number based on packet data flow charging, characterized in that the method comprises:

A2. The message receiver assigns a conversation number.

The method according to claim 9, wherein after the step A2, the method further comprises:

B2. The message receiving direction provides the assigned session number to the sender of the message.

The method according to claim 9 or 10, wherein the message recipient is a CRF.

The method according to claim 11, wherein the message receiver is a CRF, and the step B2 is: the CRF provides an assigned session number to the TPF, and the session number carries a message that provides a charging rule. in.

The method according to claim 9 or 10, wherein the message recipient is ocs.

The method according to claim 13, wherein the sender of the message is a TPF, and the step B2 is: the OCS provides an assigned session number to the TPF, and the session number is carried in a message for providing user credit. .

The method according to claim 10, further comprising: after the step B2, the message sender and the message receiver identify, by using the session number, an interaction between the message sender and the message receiver in a session. Information.

16. A method for assigning a conversation number based on packet data flow charging, characterized in that the method comprises the following steps:

A3. The message sender allocates the first part of the conversation number;

17. The method of claim 16 wherein: The step A3 further includes: the message sending direction message receiving party provides the allocated first part of the session number;

The step B3 is: the message receiver allocates a second part of the session number, and the assigned second part of the session number and the received first part of the session number form a complete session number.

The method according to claim 17, wherein the step B3 further comprises:

C3. The message receiving direction provides the complete message number to the sender of the message.

The method according to claim 18, wherein the sender of the message is a TPF, and the receiver of the message is a CRF, and the step A3 is: the TPF provides the first part of the assigned session number to the CRF, The first part of the conversation number is carried in the charging rule request.

20. The method according to claim 19, wherein the step C3 is: the CRF provides a complete session number to the TPF, and the complete session number is carried in the message providing the charging rule.

The method according to claim 18, wherein the sender of the message is a TPF, and the receiver of the message is an OCS, and the step A3 is: the TPF provides the first part of the assigned session number to the OCS, The first part of the conversation number is carried in the credit request.

22. The method according to claim 21, wherein the step C3 is: The OCS provides a complete session number to the TPF, the complete session number being carried in a message providing user credit.

The method according to claim 18, wherein the step C3 further comprises: the message sender and the message receiver identify, by the session number, an interaction between the message sender and the message receiver in a session Information.