WO2011153871A1

WO2011153871A1 - Method and system for implementing packet prepayment

Info

Publication number: WO2011153871A1
Application number: PCT/CN2011/073054
Authority: WO
Inventors: 范璟玮
Original assignee: 中兴通讯股份有限公司
Priority date: 2010-06-10
Filing date: 2011-04-20
Publication date: 2011-12-15
Also published as: CN101860634A

Abstract

The invention provides a method and system for implementing the packet prepayment, which is applied in a code division multiple access system. The method includes: a prepayment client sends an access request message which carries the position information of a terminal to a prepayment server; and the prepayment server distributes the prepayment information corresponding to the position information to the corresponding prepayment users after receiving the access request message. The method and the system for implementing packet prepayment can distribute the prepayment information, such as quota and the like, to the prepayment users according to the current positions of the users, and can adopt different charging strategies for the users accessing in different places.

Description

Method and system for realizing group prepayment

Technical field

The present invention relates to the field of communications, and in particular to a method and system for implementing packet prepaid.

Background technique

Each network element in the Code Division Multiple Access (CDMA) 2000 packet prepaid system has implemented the functions described in the protocol "X.S0011-006-E-vl.O-091116", that is, in this system, PDSN (Packet) Data Service Node, Packet Data Service Node, or HA (Home Agent, Home Agent), as PPC (Prepaid Client), AAA (Authentication, Authorization, and Accounting, Authentication, Authorization, Accounting Server) PPS (Prepaid Server) cooperates to provide users with Packet Prepaid Service based on traffic or duration. among them:

The packet prepaid service refers to: the network user pays the fee first, the operator maintains the user's account information, the user enjoys a packet data service according to the account balance, and the prepaid user (Prepaid User) first pays the service provider , then enjoy the network users of CDMA packet services.

The PPS is responsible for maintaining the user's quota usage, and interacting with the prepaid client (PPC) to complete the authentication and accounting of the prepaid user. The PPS is also responsible for the Service Control Point (SCP). ) Request the amount and perform rate conversion.

The PPC is responsible for requesting the PPS to authorize the user's prepaid service, and to track and process the user's quota usage in real time.

Figure 1 is a flow chart of prepaid charging when the access and location of a SIP (Session Initiation Protocol) user is changed when the PDSN is used as a PPC in the existing prepaid packet data service system. When the terminal location changes and is refreshed, The PDSN saves only the air interface information of the terminal, and does not perform special processing. As shown in Figure 1, the following steps are included:

S101: The terminal (MS) initiates a packet service request to access the PDSN, and the PDSN has a pre-paid capability function, and constructs an authentication access request according to the local configuration, and the PPAC in the text (PrePaid Accounting) Capability, prepaid capability, etc., PPAC is an attribute in the Remote Authentication Dial In User Service (Radius), which is used to inform the home AAA (HAAA) / PPS to send the message. Yuan has the ability to prepay.

5102. The PDSN sends an authentication request packet of the Radius access request (Access Request) of the terminal to the HAAA/PPS, and carries information such as PPAC supported by the PDSN.

After receiving the authentication request packet of the PDSN, the HAAA/PPS verifies the identity of the terminal, checks the validity of the terminal account, and checks the profile information of the terminal.

When the identity of the terminal is legal, the HAAA/PPS allocates appropriate prepaid types, quotas, and thresholds to the terminal, and responds to the Radius Access Successful Response (Access-Accept) message, carrying the PPAC, PPAQ (PrePaid Accounting Quota, prepaid quota), etc. Attributes. In the Radius Access-Accept, the PPAQ includes the user's quota and threshold. In the Radius Access-Request reported by the PPC to the HAAA/PPS, the PPAQ includes the quota information that the user has used.

5104. The PDSN receives the authentication response message of the Radius Access Accept access response of the HAAA/PPS, and starts to transmit data for the terminal.

5105. The terminal location moves, triggering the process of terminal refreshing, sending an Al1 refresh request to the PDSN, carrying a new BSID (Base Station Identity), and the PDSN saves the terminal air interface information.

5106. The PDSN finds that the threshold arrives during the process of transmitting data for the terminal.

The PPAQ attribute carried in the Radius Access-Accept authentication response packet of the HAAA/PPS contains the user quota and threshold information. According to different types of prepaid user quotas and thresholds, there are two types: quotas and thresholds for prepaid users, and quotas and thresholds for prepaid users. For example, if the duration of the PPAQ delivered by the HAAA/PPS is 60 seconds and the duration is 30 seconds, the PDSN will find the arrival time threshold after 30 seconds of user access, and then go to the HAAA/PPS update. Quotas, in order to apply quotas in advance before the allocated quotas are used up, then HAAA/PPS will issue new time quotas and thresholds.

S 107. The PDSN constructs a quota update request message of the Radius Access-Request access request, and carries the PPAQ, the current BSID of the terminal, and Update-Reason=3 (update reason: threshold arrival), and updates the quota to the HAAA/PPS. After receiving the quota update request packet of the PDSN, the S108 and the HAAA/PPS determine Update-Reason=3, settle the quota that the terminal has already used, and allocate a quota for the user. A quota update response message in response to a Radius Access-Accept access response, carrying attributes such as PPAQ.

5109. After receiving the quota update response message, the PDSN updates the quota and continues to provide the data transmission service for the terminal.

5110. The terminal initiates a refresh process for some reason, carries the same BSID as the last time or does not carry the BSID, and the PDSN saves the air interface information after receiving the refresh request of the terminal, returns to step S106, and cycles back and forth until the terminal goes offline or The quota is exhausted.

Figure 2 shows the PMIP (Proxy) when HA is used as a PPC in the existing prepaid packet data service system.

Mobile IP, Proxy Mobile IP) Prepaid billing flow chart when the user's access and location change. When the terminal location changes, the PDSN only saves the terminal air interface information, as shown in Figure 2, including the following steps:

S201: The user initiates a packet service request, and carries air interface information such as a BSID, and the PDSN authenticates the user through the HAAA server after receiving the request.

S202. After identifying the user, the PDSN identifies that the user is a PMIP user, and initiates a mobile IP registration request (MIP-RRQ) message to the HA.

5203. After receiving the MIP-RRQ packet, the HA decodes the request, and initiates a Radius Access Request access request to the HAAA, and carries the PPAC and other information supported by the HA.

After receiving the authentication request message of the HA, the HAAA/PPS authenticates the identity of the terminal, checks the validity of the terminal account, and checks the profile information of the terminal.

When the identity of the terminal is legal, HAAA/PPS allocates appropriate prepaid types, quotas, and thresholds to the terminal, and responds to the Radius Access-Accept access success response packet, carrying attributes such as PPAC and PPAQ.

5205. The HA receives the HAAA/PPS access success message, returns a successful MIP-RRP registration response message to the PDSN, and starts transmitting data for the terminal.

5206. The PDSN saves the air interface information because the terminal location moves to trigger the terminal refresh process.

S207. The HA finds that the user threshold arrives during data transmission. 5208. The HA constructs a Radius Access-Request quota update request packet, and carries the PPAQ and Update-Reason=3 to update the quota to the HAAA/PPS.

After receiving the quota update request packet of the HA, the HAAA/PPS judges Update-Reason=3 to settle the quota that the terminal has already used, and allocates a quota for the user. Respond to the Radius Access-Accept quota update response message, carrying attributes such as PPAQ. Then, the process returns to step S205 until the user terminal goes offline or the quota is exhausted.

With the development of prepaid services, the number of prepaid subscribers has increased, and users who have access to different locations have adopted different charging strategies to become a concern of the operation. However, the services provided by the CDMA2000 packet prepaid system can only capture different charging policies according to different users or different time periods, and cannot meet the actual operational requirements.

Summary of the invention

The technical problem to be solved by the present invention is to provide a method and system for implementing packet pre-payment, so as to realize pre-paid information such as allocating quotas for prepaid users according to the current location of the user.

In order to solve the above technical problem, the present invention provides a method for implementing packet pre-payment, which is applied to a code division multiple access system, and includes:

The prepaid client sends an access request message to the prepaid server, and carries the location information of the terminal;

After receiving the access request message, the prepaid server allocates prepaid information corresponding to the location information to the corresponding prepaid user.

Preferably, the method may have the following features: After the prepaid user is assigned the prepaid information corresponding to the location information, the method further includes:

And if the pre-paid client determines that the location information of the terminal changes, sending, to the pre-paid server, a first quota update request packet, where the pre-paid user has used the quota information and the new location information;

After receiving the first quota update request message, the prepaid server performs settlement on the quota currently used by the prepaid user according to the quota information used by the prepaid user, and according to the new location information. The rate is within the allowable range of the prepaid user's distribution balance Amount.

Preferably, the method may further have the following features: after the prepaid information is allocated to the corresponding prepaid user, the method further includes:

The prepaid client sends a second quota update request message to the prepaid server, and carries the quota information, the location information of the terminal, and the update reason of the prepaid user;

After the second pre-paid server receives the second quota update request message, if it is determined that the update reason is a quota update that is not caused by the terminal location change, then the pre-paid user has used the quota information pair. After the quota used by the prepaid user is settled, the prepaid user is allocated a quota within the allowable range of the balance according to the rate corresponding to the saved location information.

And if the pre-paid client determines that the pre-paid user has reached the allocated quota, sending a third quota update request message to the pre-paid server, carrying the update reason for the arrival of the quota; After the third quota update request message, the prepaid user is released.

Preferably, the foregoing method may further have the following features: the prepaid information includes: a prepaid type, a quota, and a threshold corresponding to the location information.

In order to solve the above problems, the present invention also provides a system for implementing packet prepaid, including a prepaid client and a prepaid server, wherein:

The prepaid client is configured to send an access request message to the prepaid server, and carry location information of the terminal;

The prepaid server is configured to allocate prepaid information corresponding to the location information to the corresponding prepaid user after receiving the access request message.

Preferably, the above system can have the following features:

The prepaid client is further configured to: if it is determined that the location information of the terminal changes, send a first quota update request message to the prepaid server, and carry the quota information and the new used by the prepaid user. location information; The prepaid server is further configured to: after receiving the first quota update request message, perform settlement on a quota currently used by the prepaid user according to the quota information used by the prepaid user, and according to the The rate corresponding to the new location information is the quota within the allowable range of the prepaid user's allocated balance.

Preferably, the above system may also have the following features:

The prepaid client is further configured to send a second quota update request message to the prepaid server, carrying the quota information used by the prepaid user, location information of the terminal, and an update reason; the prepaid server, And after receiving the second quota update request message, if it is determined that the update reason is a quota update that is not caused by a terminal location change, then the prepaid user has used the quota information to After the quota currently used by the prepaid user is settled, the prepaid user is allocated a quota within the allowable range of the balance according to the rate corresponding to the saved location information.

Preferably, the above system may also have the following features:

The prepaid client is further configured to: if it is determined that the prepaid user has reached the allocated quota, send a third quota update request message to the prepaid server, and carry the update reason for the arrival of the quota;

The prepaid server is further configured to release the prepaid user after receiving the third quota update request message.

Preferably, the above system may also have the following features:

The prepaid server is an authentication, authorization, and accounting (AAA) server, and the prepaid client is a packet data serving node or a home agent.

The present invention provides a method and a system for implementing packet pre-payment, which can realize pre-paid information such as quotas allocated to pre-paid users according to the current location of the user, and can obtain different charging policies for users accessing different places.

BRIEF abstract

The drawings described herein are provided to provide a further understanding of the invention and constitute a part of the application The illustrative embodiments of the present invention and the description thereof are intended to explain the present invention and are not intended to limit the invention. In the drawing:

1 is a flow chart of prepaid charging when a SIP user accesses and changes a location when a PDSN is used as a PPC in an existing prepaid packet data service system;

2 is a flow chart of prepaid charging when a PMIP user accesses and changes a location when the HA is a PPC in the existing prepaid packet data service system;

3 is a schematic diagram of a system for implementing packet prepaid according to the present invention;

4 is a flow chart of a method for implementing packet prepaid according to the present invention;

5 is a schematic diagram of a structure of an existing prepaid packet data service system;

6 is a flow chart of an embodiment of a method for implementing packet prepaid according to the present invention;

7 is a flow chart of another embodiment of a method of implementing packet prepaid according to the present invention.

Preferred embodiment of the invention

The technical solution of the present invention will be described in more detail below with reference to the accompanying drawings and embodiments.

3 is a schematic diagram of a system for implementing packet prepaid according to the present invention. As shown in FIG. 3, the system for implementing packet prepaid according to the present invention includes: a prepaid client 31 and a prepaid server 32, wherein a prepaid client, Set to send an access request message to the prepaid server, and carry the location information of the terminal;

a prepaid server, configured to: after receiving the access request message, assign a prepaid information corresponding to the location information to the corresponding prepaid user, where the prepaid information may include: The corresponding prepaid type, quota, and threshold, the threshold is generally less than the quota value.

Thus, the system for implementing packet pre-payment of the present invention can realize pre-paid information for pre-paid users according to the current location of the user terminal.

Further, when the mobile terminal initiates a refresh request, the prepaid client may further be configured to determine whether the location information of the terminal changes, and if it is determined that the location information of the terminal changes, The prepaid server sends a first quota update request message, and carries the quota information and the new location information used by the prepaid user; The prepaid server may be further configured to: after receiving the first quota update request message, perform settlement on a quota currently used by the prepaid user according to the quota information used by the prepaid user, and according to the The rate corresponding to the new location information is a quota within the allowable range of the prepaid user's allocated balance, and the corresponding threshold may also be allocated together.

Further, when the terminal initiates the refresh request for any reason, the prepaid client may carry the quota information and the terminal of the prepaid user in the second quota update request message sent to the prepaid server. Location information and reason for the update;

The prepaid server may be further configured to: after receiving the second quota update request message, if it is determined that the update reason is a quota update that is not caused by a terminal location change, then the prepaid user has been After the quota information is used to settle the quota currently used by the prepaid user, the quota corresponding to the saved location information is allocated to the prepaid user, and the corresponding threshold may be allocated together.

When the prepaid client determines that the prepaid user has reached the allocated quota, sends a third quota update request message to the prepaid server, and carries the update reason for the arrival of the quota;

The system for implementing packet prepaid according to the present invention is applicable to a CDMA packet prepaid system. In the system, the prepaid client may be a packet data serving node (PDSN) or a home agent (HA), the prepaid The fee server can be an AAA server for authenticating the terminal.

In order to implement terminal location based prepaid charging, each network element in the CDMA2000 packet prepaid system of the present invention has the following functions:

If the PDSN is used as a prepaid client, the PDSN is responsible for the application of the terminal quota and monitors the usage of the quota. In order to implement the pre-paid method based on the location of the terminal, the PDSN must have at least the following functions:

When the pre-paid user accesses, the PDSN must carry the BSID of the terminal in the authentication request message of the Radius Access Request access request, so that the PPS/SCP allocates the initial quota to the user.

When the prepaid user refreshes, the PDSN must be able to determine whether the BSID of the terminal has changed. If a change occurs, the PDSN reports the usage quota of the user to the PPS/SCP through the HAAA, and carries the new BSID of the user to apply for a new quota.

When the pre-paid user releases, if the PDSN determines that the BSID changes, the PDSN may carry the latest BSID in the last Radius Access-Request access request message and the Radius Access-Accept access response message, or may carry the old BSID. BSID.

Radius Access-Request and Radius Access-Accept are classified into authentication request message and authentication response message, or quota update request message and quota update response according to one field. The Radius Access-Request 4 message when the user accesses is the authentication request message, and the Radius Access-Accept message is the authentication response message; the Radius Access-Request when the user updates the quota due to the threshold/quota arrival or location change The message is a quota update message, and the Radius Access-Accept 4 message is a quota update response message.

When the prepaid user threshold arrives and the BSID changes simultaneously, the PDSN must carry the new BSID and carry an Update-Reason value of 200 (update reason: user quota update due to user location change).

When the prepaid subscriber quota arrives and the BSID changes simultaneously, the PDSN must carry a value of 4

(Quota Reached, Quota Reached) Update-Reason (Update Reason: Quota Arrival), can carry a new BSID, or carry an old BSID. The user needs to be released when the quota arrives, that is, HAAA/PPS is no longer required to allocate quotas for the terminal, so Update-Reason 4 is used.

When the pre-paid user's TITSU (Time Interval after Tariff Switch Update) arrives at the same time as the BSID change, the PDSN must carry an Update-Reason with a value of 200. (Update reason: due to user location The user quota update caused by the change) must carry the new BSID. For example, 21 points is the rate switching point, that is, the rates before and after 21 points are different. If TITSU is 5 minutes, then at 21:05, the quota used will be used. If the terminal position is also moved at 21:05, At this time, the reason for updating the PD on the PDSN is: User quota update due to user location change.

If the HA acts as a prepaid client, it is responsible for the application of user quotas and monitors the usage of quotas. In order to implement the pre-paid method based on the terminal location, the HA must have at least the following functions: When the pre-paid user accesses, the HA must carry the BSID of the terminal in the Radius Access Request message, so that the PPS/SCP allocates the initial quota to the user.

When the prepaid user refreshes, the HA must be able to determine whether the BSID of the terminal has changed. If a change occurs, the HA reports the user usage quota to the PPS/SCP through the HAAA, and carries the new BSID of the user to apply for a new one. quota.

When the prepaid user releases, if the HA determines that the BSID changes, the HA may carry the latest BSID in the last Online message, and may also carry the old BSID.

When the prepaid user threshold arrival and the BSID change are triggered at the same time, the HA must carry the new BSID and carry an Update-Reason with a value of 200 (update reason: user quota update due to user location change).

When the prepaid subscriber quota arrives and the BSID changes, the HA must carry the Update-Reason with a value of 4 (Quota Reached), which can carry the new BSID or carry the old BSID.

When the TITSU of the prepaid subscriber arrives at the same time as the BSID change, the HA must carry an Update-Reason with a value of 200 (update reason: user quota update due to user location change), and must carry a new BSID.

In order to implement the pre-paid function based on the user's location when the HA is a prepaid client, the PDSN connected to the HA must support the NVSE (Normal Vendor/) that encodes the vendor type ( VendorType) = 3 (indicating that the NVSE carries the BSID attribute). Organization Specific Extension, which is used to carry the BSID, the relative HA must support decoding of the extension and can identify whether the user's BSID has changed.

Functional requirements for Prepaid Server (PPS) and Service Control Node (SCP):

The PPS is responsible for requesting the pre-paid user account status from the SCP, applying for a fund quota, and maintaining the user quota usage status. PPS is a logical entity that is responsible for rate conversion and maintaining user quota status. It can reside in AAA, reside in SCP, or be a separate physical entity. When PPS and HAAA are separated, their interfaces follow the extended RADIUS protocol.

In order to implement location-based prepaid methods, PPS must implement at least the following functions: When receiving a Radius Access Request message, the PPS can allocate the initial quota to the user according to the local configuration. If the BSID cannot be resolved or the packet does not carry the BSID, the PPS can be localized. The policy assigns the user the default initial quota or denies the user access. If the resolved BSID does not match in the local configuration, the PPS can assign the user the default initial quota or deny the user access according to the local policy.

When receiving a quota update request carrying Update-Reason=200 (update reason: user quota update due to user location change), if PPS can parse the BSID carried in the text, the current user is used first. The BSID resolves the quota that the user has already used, and then allocates a quota to the user according to the carried BSID and the local configuration. If the BSID cannot be resolved or the packet does not carry the BSID, the PPS first uses the current user's BSID for the user. The quota is settled, and then the user quota update request is rejected. If the resolved BSID does not match in the local configuration, the PPS first uses the current user's BSID to settle the quota that the user has used, and then can allocate the user according to the local policy. The default quota or the request to reject the user quota update. When receiving a Radius Online Request message with Update-Reason not 200, the PPS must ignore the BSID carried in the packet and use the BSID of the current user for the user. Quotas are settled and quotas are allocated.

4 is a flow chart of a method for implementing packet prepaid according to the present invention. As shown in FIG. 4, the method of the present invention includes the following steps:

S10. The prepaid client sends an access request message to the prepaid server, and carries the location information of the terminal.

S20. After receiving the access request message, the prepaid server allocates prepaid information to the terminal according to the location information.

Further, when the terminal location moves, the method further includes:

S30. If the location information of the terminal is changed, the prepaid client sends a quota update request message to the prepaid server, and the terminal uses the quota information and the new location information.

S40. After receiving the quota update request packet, the prepaid server performs settlement on the quota currently used by the terminal according to the terminal usage quota information, and uses the new location information as the end. The quota is allocated.

Embodiments of the present invention will be described in detail below.

5 is a schematic diagram of the structure of an existing prepaid packet data service system. This figure only illustrates the core network elements in the prepaid packet data service system structure, including: PDSN, HA, FAAA/HAAA, PPC, and PPS.

To support prepaid packet data services, PDSN and/or HA should support Prepaid Client (PPC) functionality. The prepaid client PPC can reside on the PDSN or reside in the HA depending on the access method.

The Home AAA Server (HAAA), Prepaid Server (PPS), and Service Control Point (SCP) are located on the subscriber's home network. The PPC communicates with the home AAA, PPS/SCP through the RADIUS protocol; the RADIUS protocol is used between the AAA server and the prepaid server. The Proxy AAA Server (FAAA) transparently transmits prepaid VSAs (attributes) sent or received by the Home AAA Server.

The PPS can be an independent physical entity, or it can be located in HAAA or SCP, and exists as a functional entity of HAAA or SCP. The account information of the prepaid user is stored in the SCP, and the PPC interacts with the PPS/SCP through the prepaid access and end messages of the user, and performs authentication and fee management of the user prepaid service.

The present invention extends the standard of "X.S0011-006-D-vl.0-060301", so all network elements in the default prepaid packet data service system structure follow and have fulfilled the requirements in the standard. The present invention only describes the functional requirements of the extension part for the prepaid packet data service system and each network element, as follows: If the PPC resides in the PDSN, the PDSN must be able to identify the user location information (for example,

BSID) changes, and communicates with HAAA, PPS/SCP through RADIUS protocol, and transmits BSID to change this information.

If the PPC resides in the HA, the PDSN in the system must be able to recognize the change of the user's location information (for example, BSID), and carry the BSID information to the HA through MIP signaling, and then pass the RADIUS protocol with the HAAA and PPS by the HA. /SCP communication, passing the BSID to change this information.

The PPS/SCP can provide different quotas based on the BSID in the original quota allocation strategy.

The new BSID-based prepaid billing method does not affect the original prepaid packet data service system. Existing strategies have an impact.

6 is a flowchart of an embodiment of a method for implementing packet pre-payment according to the present invention. In this embodiment, a PDSN is used as a PPC, and mainly describes a prepaid charging flow chart based on a user location when a SIP user accesses and a location changes. As shown in Figure 6, the following steps are included:

S301. The terminal (MS) initiates a packet service request, and accesses the PDSN. The PDSN first saves the BSID information of the MS, and then constructs a PPAC and other attributes in the authentication access request message according to the local configuration.

The PDSN has the functions of prepaid capacity and prepaid billing based on user location.

S302. The PDSN initiates an authentication access request of the MS to the HAAA/PPS, and carries information such as the PPAC supported by the PDSN and the BSID of the MS.

After receiving the authentication request packet of the PDSN, the HAAA/PPS authenticates the MS. For example, the identity of the MS is verified, the validity of the MS account is verified, and the profile information of the terminal is checked.

When the MS identity is legal, the HAAA/PPS allocates the appropriate prepaid type, quota, and threshold according to the BSID of the MS, and saves the BSID of the MS, and then responds to the PDSN with a Radius Access-Accept packet carrying the attributes such as PPAC and PPAQ.

5304. The PDSN receives the authentication response packet with successful access to the HAAA/PPS, and starts to transmit data for the MS.

S305. The terminal location moves, triggering a process of refreshing the terminal, and the terminal sends a refresh request to the PDSN to carry the new BSID.

5306. When receiving the refresh request of the terminal, the PDSN finds that the BSID of the terminal has changed, and immediately constructs a Radius Access-Request quota update request packet, carrying the PPAQ, the new BSID, and the Update-Reason=200 (update reason: due to the user location Change the resulting user quota update) to the HAAA/PPS update quota.

After receiving the quota update message sent by the PDSN, the HAAA/PPS first determines that this is a quota update triggered by the BSID change according to Update-Reason=200 (update reason: user quota update due to user location change), and then According to the saved BSID to the terminal currently The quota used is settled, and the quota and threshold are allocated to the terminal according to the new BSID, and the BSID is saved. Respond to Radius Access-Accept packets, carrying attributes such as PPAQ.

HAAA/PPS allocates quotas according to user balances and rates. For example, the rate corresponding to BSID A is 1 yuan/second on HAAA/PPS, and the rate corresponding to BSID B is 2 yuan/second. If the user balance is 100 yuan, the quota issued by HAAA/PPS for BSID A can only be 100 seconds, and the quota issued for BSID B can only be 50 seconds.

S308. The PDSN receives the Radius Access-Accept quota update response packet of the HAAA/PPS, updates the user quota, and finds that the threshold arrives during the process of transmitting data for the terminal.

5309. The PDSN constructs the Radius Access-Request quota update request packet carrying the PPAQ, the current BSID of the terminal, and Update-Reason=3, and updates the quota to the HAAA/PPS.

After receiving the quota update request packet of the PDSN, the HAAA/PPS judges Update-Reason=3, ignores the BSID carried in the packet, and settles the quota that the terminal has already used, and uses the currently saved BSID as the user. Allocating quotas, responding to the PDSN with a Radius Access-Accept quota update response message, carrying attributes such as PPAQ.

After receiving the Radius Access-Accept response message, the S311 and the PDSN update the quota to continue to provide the data transmission service for the terminal.

S312: The terminal initiates a refresh process for some reason, carries the same BSID as the last time or does not carry the BSID. When receiving the refresh request of the terminal, the PDSN determines that the BSID has not changed, and does not perform the process of quota update.

Then, it can be returned to step S305 or S310, and the loop is repeated until the user terminal goes offline or the quota is exhausted.

FIG. 7 is a flowchart of another embodiment of a method for implementing packet pre-payment according to the present invention. In this embodiment, HA is used as a PPC, and mainly describes a prepaid charging flow chart based on user location when accessing and changing a PMIP user is changed. As shown in Figure 7, the following steps are included:

5401. The user initiates a packet service request, and carries air interface information such as a BSID. After receiving the access request, the PDSN authenticates the user through the AAA server.

5402. After authenticating, the PDSN identifies that the user is a PMIP user and initiates to the HA. The MIP-RRQ registers the request message, and carries the NVSE of VendorType=3 in the MIP-RRQ message, and sends the BSID of the user parsed in the Al1 message from the MS to the PDSN.

After receiving the MIP-RRQ packet, the S403 and the HA decode the MBID and save the BSID and initiate an authentication request to the HAAA, and carry information such as the PPAC supported by the HA and the BSID of the user.

After receiving the authentication request message of the HA, the S404 and the HAAA/PPS authenticate the identity of the terminal, verify the validity of the terminal account, and check the profile information of the terminal.

When the identity of the terminal is legal, HAAA/PPS allocates the appropriate prepaid type, quota and threshold according to the BSID of the terminal and saves the BSID of the terminal. Respond to the Radius Access-Accept message, carrying attributes such as PPAC and PPAQ.

S405: The HA receives the authentication response packet of the successful access of the HAAA/PPS, returns the MIP-RRP to register the successful response message, and starts to transmit data for the terminal.

S406: The terminal refreshing process is triggered by the terminal location movement, and the PDSN sends a MIP-RRQ refresh request message to the HA immediately after the terminal BSID is changed, and carries the new BSID.

S407. The HA receives the MIP-RRQ refresh request packet sent by the PDSN, and decodes the BSID of the user, and the locally saved value (that is, the BSID carried in the MIP-RRQ packet received by the HA when the user accesses the user). For comparison, if it is determined that the BSID of the terminal has changed, the Radius Access-Request message is immediately constructed to carry the PPAQ, the new BSID, and the Update-Reason=200 (update reason: the user quota update due to the user location change) to the HAAA/PPS. Update the quota and return the MIP-RRP to the PDSN.

After receiving the quota update message sent by the HA, the S408 and the HAAA/PPS firstly

Update-Reason=200 (Update reason: User quota update due to user location change) It is judged that this is a quota update triggered by BSID change, and then the quota currently used by the terminal is settled according to the saved BSID, and then according to the new BSID. Allocate quotas and thresholds for the terminal, save the BSID, respond to the Radius Access-Accept message, and carry attributes such as PPAQ.

S409: The HA receives the authentication response packet with the HAAA/PPS quota update successfully, updates the user quota, and returns the MIP-RRP refresh response message to continue transmitting data for the terminal.

S410. The HA finds that the user threshold arrives during data transmission.

S411 and HA construct a Radius Access-Request packet carrying the PPAQ and the current BSID of the terminal. And Update-Reason=3, update quota to HAAA/PPS.

S412, HAAA/PPS, after receiving the quota update request packet of the HA, judges Update-Reason=3, ignores the BSID carried in the packet, and resolves the quota already used by the terminal, and allocates the user according to the currently saved BSID. The quota and threshold are used to respond to the Radius Access-Accept message to the HA, carrying attributes such as PPAQ.

Other processing methods are the same, looping back and forth until the user terminal goes offline or the quota is exhausted.

One of ordinary skill in the art will appreciate that all or a portion of the steps above may be accomplished by a program to instruct the associated hardware, such as a read-only memory, a magnetic disk, or an optical disk. Alternatively, all or part of the steps of the above embodiments may also be implemented using one or more integrated circuits. The invention is not limited to any specific form of combination of hardware and software.

The above is only a preferred embodiment of the present invention, and of course, the present invention may be embodied in various other embodiments without departing from the spirit and scope of the invention. Corresponding changes and modifications are intended to be included within the scope of the appended claims.

Industrial Applicability The present invention provides a method and system for implementing packet pre-payment, which can allocate pre-paid information such as quotas to pre-paid users according to the current location of the user, and can obtain different charging policies for users accessing different places.

Claims

Claim

A method for implementing packet pre-payment, which is applied to a code division multiple access system, comprising: a prepaid client sending an access request message to a prepaid server, and carrying location information of the terminal;

2. The method of claim 1 wherein:

After the prepaid information is allocated to the corresponding prepaid user, the method further includes:

And if the pre-paid client determines that the location information of the terminal changes, sending a first quota update request packet to the pre-paid server, and carrying the quota information and the new location information used by the pre-paid user; After the prepaid server receives the first quota update request message, the prepaid user has used the quota information to settle the quota currently used by the prepaid user, and according to the new location information, The rate is a quota within the allowable range of the prepaid user's assigned balance.

3. The method of claim 1 wherein:

4. The method of claim 1 wherein:

After the prepaid information corresponding to the location information is allocated to the corresponding prepaid user, The method further includes:

5. The method of any of claims 1-4, wherein:

The prepaid information includes: a prepaid type, a quota, and a threshold corresponding to the location information.

6. A system for implementing packet prepaid, including a prepaid client and a prepaid server, wherein:

7. The system of claim 6 wherein:

The prepaid client is further configured to: if it is determined that the location information of the terminal changes, send a first quota update request message to the prepaid server, and carry the quota information and the new used by the prepaid user. location information;

The prepaid server is further configured to: after receiving the first quota update request message, perform settlement on a quota currently used by the prepaid user according to the quota information used by the prepaid user, and according to the The rate corresponding to the new location information is the quota within the allowable range of the prepaid user's allocated balance.

8. The system of claim 6 wherein:

The prepaid client is further configured to send a second quota update request message to the prepaid server, carrying the quota information used by the prepaid user, location information of the terminal, and an update reason; the prepaid server, And after receiving the second quota update request message, if it is determined that the update reason is a quota update that is not caused by a terminal location change, then the prepaid user has used the quota information to After the quota used by the prepaid user is settled, the root The rate corresponding to the saved location information is the quota within the allowable range of the prepaid user's allocated balance.

9. The system of claim 6 wherein:

10. The system of any of claims 6-9, wherein: