WO2007076646A1

WO2007076646A1 - A method for realizing prepayment of digital cluster system

Info

Publication number: WO2007076646A1
Application number: PCT/CN2006/000919
Authority: WO
Inventors: Yunbin Chen; Zhaosen Geng; Yunfei Ma
Original assignee: Zte Corporation
Priority date: 2005-12-31
Filing date: 2006-05-09
Publication date: 2007-07-12
Also published as: CN1992763B; CN1992763A

Abstract

A method for realizing prepayment of digital cluster system, it includes: an originating terminal make a cluster call, PDS request for authority server autority; the preapyment server residend in the authority server determines prepayment account, the terminal used the account and the charging mode according to the prepayment information associated with this call, and assigns the quota to these inactive accounts, then informs the prepayment client terminal; the prepayment client terminal informs the dispatch server to paging the terminal that use prepayment account with usable quota only; the prepayment client terminal monitors the state of terminal paged and the usage condition of the quota, while there are no balance to use in the account or the terminal using the account quits this call, then informs the finish of the charging of the account to said preapyment server; said preapyment server records the amount of the quota and recoveries the quota unused, ends. The present invention can mak a charge according to time, flow and number of calls, and implement preapyment function based on group and subscriber.

Description

Method for realizing prepayment of digital trunking system

Technical field

The present invention relates to a digital trunking system, and more particularly to a method of implementing a prepaid payment by a digital trunking system.

Background technique

The traditional digital trunking system is mostly applied to the private network. The cluster service provided has the limitation of service scope and service population. At the same time, due to the separate network construction and overlapping with the public network construction, the resource waste is serious. A more realistic solution to the above shortcomings is to integrate the cluster service into the public network system, and gradually evolve from the original private network to the virtual private network, thereby reducing the network construction cost and expanding the scope of use.

The current trunking communication system has gradually realized a digital trunking system using a virtual private network, but it has not been synchronized in the charging field. The pre-payment method of the communication system is basically for the group billing, and the pre-payment method is relatively simple, and most of them adopt the method of monthly subscription according to the group. The digital trunking system based on the public network system not only provides cluster services for the group, but also allows cluster services to be used for different group users and non-group individual users, so that the digital trunking system based on the public network system serves a wider population. It is required that the digital trunking system can provide reasonable prepaid methods to meet different levels of user needs, including pre-payment by group, group and user, and consider the length of time, traffic or number of calls when charging. Unfortunately, at present, there is no corresponding norm and standard for the implementation of pre-paid for cluster systems, and there is no literature on the solution to the above problems.

Summary of the invention

The technical problem to be solved by the present invention is to provide a digital trunking system for implementing prepaid payment, which can be charged according to duration, traffic, and number of calls, and implement prepaid functions by group and by user.

In order to solve the above technical problem, the present invention provides a method for implementing prepaid payment in a digital trunking system, in which a prepaid client resides in a scheduling server, and a pre-reservation server resides in the authentication server. For a paid server, the method includes the following steps:

(a) the originating terminal initiates a trunking call, and the dispatching server sends an authentication request message to the authentication server, and the authentication server authenticates the calling terminal and the called group;

(b) the prepaid server residing on the authentication server determines, according to the prepaid information of the related user of the call, information about the prepaid account, the terminal using the account, and the charging method involved in the charging, Pre-paid client interactions residing on the scheduling server, notifying the determined information to the pre-paid client, and allocating quotas for the inactivated accounts;

(c) the prepaid client only pages the terminal using the prepaid account with the available quota according to the obtained prepaid account and its quota condition;

(d) the prepaid client monitors the status of the paged terminal and the usage of the quota, and charges the prepaid account, and if the prepaid account has no balance available before use, the terminal using the account exits the call. , perform the next step, otherwise execute the next step when there is no balance available for the prepaid account;

(e) the prepaid client notifies the prepaid server that the prepaid account ends the billing, and carries the total quota used by the account; the prepaid server records the quota total and reclaims the unused quota. The prepaid client clears the information of the account and ends.

Further, the above method may further have the following features: In the step (b), when the prepaid account involved is a group prepaid account, the interaction with the prepaid server is completed by the following steps:

(bl) the prepaid server determines each group prepaid account involved in charging, a terminal that uses the account, and a charging method, and sends the information to the prepaid client along with the authorization message;

(b2) the prepaid client determines whether the group prepaid account in the authorization message is activated, and if activated, notifies the scheduling server to page the terminal using the accounts, and then performs step (d) to prepay the unactivated group Fee account, perform step (b3);

(b3) the prepaid client sends an application quota message to the prepaid server to apply for a quota for the unactivated group prepaid account;

(b4) after receiving the quota request, the prepaid server allocates a quota for the group prepaid account segment with the balance, and returns the quota message to the prepaid client, and the balance is not allocated. The account returns information without balance allocation, and step (c) is performed.

Further, the above method may further have the following features: In the step (d), when charging the group prepaid account, the method is further divided into the following steps:

(dl) The prepaid client monitors the status and quota usage of all paged terminals. When charging a group prepaid account, the account has been used according to the quotas used by all terminals using the account;

(d2) If all the terminals using the account exit the call before the current allocation quota of the group prepaid account is used, perform step (e), otherwise, when the used quota reaches the threshold of the current allocation quota, The prepaid client sends an application quota request to the prepaid server again;

(d3) after receiving the quota request, the prepaid server allocates a new quota to the prepaid client when the account has a balance allocation, and returns to the prepaid client through the allocation quota message, when the account has no balance allocation , carrying the information of no balance allocation in the returned allocation quota message;

(d4) after receiving the message of allocating quota, the prepaid client determines whether a new quota is allocated for the group prepaid account, and if yes, modifying the current allocation quota of the account, returning to step (dl), if not Assign a new quota to the account and proceed to the next step;

(d5) The prepaid client monitors the terminal using the group's prepaid account to use the remaining quota, and then stops the cluster services of these terminals, and performs step (e).

Further, the foregoing method may further have the following features: In the step (b), when the prepaid account involved is a user prepaid account, the interaction with the prepaid server is completed by the following steps: the prepaid The server determines the user prepaid account involved in the charging and its corresponding terminal, the charging method, allocates a quota for each user prepaid account, and the account without the balance allocation does not have the identifier of the balance allocation, and then returns the prepaid information to the The prepaid client.

Further, the above method may further have the following features: In the step (b), when the prepaid account involved is a user prepaid account, the interaction with the prepaid server is completed by the following steps -

() the prepaid server determines each user's prepaid account involved in charging, using the account Terminal and charging method, the information is sent to the prepaid client along with an authorization message;

(b2) after receiving the authorization message, the prepaid client sends an application quota message to the prepaid server, and the user prepaid account included in the message;

(b3) after receiving the application quota message, the prepaid server allocates a quota for the user prepaid account with the balance that can be allocated, returns the quota message to the prepaid client, and returns the account without the balance that can be allocated. There is no balance assigned information, then go to step (c).

Further, the foregoing method may further have the following features: in the step (b)′, the prepaid server adopts a segment allocation method when allocating quotas for the user prepaid account, and in the step (d), prepaying the user When the fee account is charged, it is further divided into the following steps:

(dl) The prepaid client monitors the status and quota usage of all the paging terminals. If the terminal using the account exits the call port L| before the current allocation quota of the user prepaid account is used, the execution step (e) And sending an application quota request to the prepaid server when the used quota reaches the threshold of the current allocated quota;

(d2) after receiving the quota request, the prepaid server determines whether the user prepaid account has an assignable balance, and if so, assigns a new quota to the prepaid client, if If not, the information about the balance allocation is carried in the allocation quota message;

(d3) after receiving the allocation quota message, the prepaid client determines whether a new quota is allocated for the user prepaid account, and if yes, modifying the current allocation quota of the account, returning to step (dl), if not The account is assigned a new quota and the next step is performed;

(d4) The prepaid client monitors the terminal using the user's prepaid account to use the remaining quota, and then stops the cluster service of the terminal, and performs step (e).

Further, the above method may also have the following features: The quota is in units of call duration, call traffic, or number of calls.

Further, the foregoing method may further have the following feature: when the prepaid account has no balance for distribution, the prepaid server allocates the quota allocated for the account to the quota allocated in the previous allocation in the allocation quota message, Set it to zero when it is allocated.

Further, the foregoing method may further have the following feature: the prepaid client to the prepaid When the fee server applies for the quota again, the message carries the quota currently used by the group or the user prepaid account, and the prepaid server records the message and records the used usage of the prepaid account, and the foregoing method may further The utility model has the following features: when the prepaid server allocates quotas for the group or user prepaid accounts again and has a balance for distribution, the allocated quota is the last allocated quota plus the total amount of the newly allocated quota.

Further, the foregoing method may further have the following feature: the threshold for the current allocation quota is specified by the prepaid server according to the allocation quota each time the quota is allocated, and returns to the prepaid together with the allocation quota. Or the quota threshold is calculated by the prepaid client according to the current allocation quota.

Further, the foregoing method may further have the following features: In the step (b), the prepaid server further determines whether the prepaid client residing on the scheduling server supports the prepaid account to be used for the call. In the charging mode, the prepaid account that does not support its charging mode is not notified to the prepaid client or is not assigned a quota.

Further, the foregoing method may further have the following features: the prepaid server is configured to learn the charging mode information supported by the prepaid client by: reporting, by the prepaid client in the system, the supported accounting The fee mode or report to the prepaid server when the charging mode changes, to achieve synchronous update; or, in the step (a), the scheduling server will support the prepaid client hosted thereon The charging method is reported to the prepaid server residing on the authentication server along with the authentication message.

Further, the foregoing method may further have the following features: In the step (b), when a prepaid account can adopt multiple charging methods, the prepaid customer residing on the scheduling server where the terminal of the account is used in combination The charging mode supported by the terminal selects a charging mode supported by both.

Further, the above method may further have the following features: the digital trunking system has a roaming function, and in the step (b), the prepaid server sends the prepaid account involved in the charging to the current location of the terminal using the account. All dispatch servers, prepaid passengers residing on each dispatch server The client independently completes the charging of the received prepaid account.

Further, the foregoing method may further have the following features: In the step (b), when the user has multiple prepaid accounts at the same time, the prepaid server selects one of the prepaid accounts according to the preset policy, and then presses the The billing process of the prepaid account is processed.

It can be seen from the above that the method of the present invention can meet the requirement that the trunking service can be prepaid and charged according to the duration, the traffic, and the number of calls. At the same time, the prepaid charging function is implemented according to the group and the user, and the prepaid charging method is implemented in the segmental allocation of the accumulated quota. The prepaid system, at the same time, enables the system to allow multiple prepaid clients to simultaneously use one prepaid account in use, which can minimize the charging error.

BRIEF abstract

1 is a schematic diagram of a relationship between a billing entity of a prepaid service of a digital trunking system according to the present invention; FIG. 2 is a schematic diagram of message interaction according to a prepaid bill of the present invention;

FIG. 3 is a flow chart of message interaction in the group prepayment process of the present invention. BEST MODE FOR CARRYING OUT THE INVENTION

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

1 is a schematic diagram of an entity directly related to prepaid in a digital trunking system of the present invention, with a prepaid server 12 connected to one or more prepaid clients 11 via an IP network 10. The prepaid client usually resides on the dispatch server of the digital trunking system. The prepaid server usually resides on the authentication server of the cluster scheduling system and is responsible for managing the user's prepaid information, such as the user's prepaid account and billing method. Wait. The Dispatch Server (PDS) communicates with the terminal through the Base Station Subsystem (BSS). It should be noted that the above-mentioned residency is a logical residency. On a physical entity, the prepaid server and the authentication server, the prepaid client, and the dispatch server are usually unified, but the possibility of separation is not excluded. When using the current SCP to manage prepaid information, its processing part and the SCP need to communicate with each other using the interface.

When the prepaid client is billing, it can be based on the duration of the call, the traffic flow, or the number of calls. Billing. The prepaid method of the present invention includes prepaid by group, prepaid by group and prepaid by user. Group calls can be prepaid by group, prepaid by group and prepaid by user. The private call service can choose to pre-pay by group and pre-pay by user. The charging object according to the group and pre-paid by the user is the terminal, and the charging for the group is only the accumulation of the charging including the terminal; the pre-payment by the group is different, the charging object is the group call, the group call The calculation of the duration, flow or number of times, the number of terminals can be considered in the billing, but the billing is not performed separately for each terminal.

The three prepaid modes are described below in three embodiments.

First embodiment: Prepaid by group

This embodiment is a method for implementing pre-payment by group on a digital trunking system. Prepaid by group means that calls made by members of the group will be deducted from the group's prepaid account. The feature is that the users involved in each call may belong to different groups, and users in the same group may initiate or join the call separately. Therefore, when a group member initiates a call or is paged, the corresponding group prepaid account may have been activated on the dispatch server.

The flow of the method in this embodiment will be described below. Referring to the message interaction in FIG. 2, the following steps are included:

Step 110: The calling terminal initiates a trunking call, which may be a group call or a private call, and the originating message is sent to the scheduling server by using the base station subsystem;

Step 120: The scheduling server sends an authentication request message to the authentication server, where the authentication server authenticates the calling terminal and the called group, and if the authentication fails, the subsequent steps are not performed;

Step 130: The prepaid server residing on the authentication server determines, according to the prepaid information of the related users (referring to the calling party and all the called parties) of the call, the prepaid accounts of the groups involved in the charging, and the terminals and accounts of the used accounts. The information such as the fee method is sent to the dispatching server by the authorization message replied with the authentication, and then forwarded to the resident prepaid client;

Step 140: After receiving the authorization message, the prepaid client determines whether the group prepaid account is activated. If activated, notifies the scheduling server to page the terminal that uses the accounts, and performs step 180 to prepay the inactive group. Fee account, go to step 150;

Step 150: The prepaid client sends an application quota message to the prepaid server, which is inactive. Group prepaid account application quota;

Step 160: After receiving the quota request, the prepaid server allocates a quota (in terms of duration, traffic, or number of calls) and a quota threshold for the group prepaid account, and allocates zero quota to the account without the balance allocation, and then allocates the quota. The message is returned to the prepaid client;

Step 170: After the prepaid client receives the quota allocated for each group prepaid account, if there is an available quota, the scheduling server is notified to the terminal that uses the account to initiate paging. If no quota is available, the terminal that uses the account is not used. Initiate paging;

After the call is established, the following charging process is performed for each group prepaid account to which the terminal that initiated the paging belongs - step 180, the prepaid client monitors the status and quota usage of all the paged terminals, and prepays for a group. When the account is billed, the account used quota is calculated by accumulating the quotas used by all the terminals using the account;

After paging the terminal, the terminal may access immediately, late access or never access the call. When the client monitors the status of the terminal, the terminal that does not have the access call also includes monitoring the status of the call paging the terminal. When the call to page the terminal ends, the terminal is deemed to have quit the call.

Step 190: If all the terminals using the account exit the call before the quota used by the group prepaid account reaches the current quota threshold, go to step 240. Otherwise, when the used quota reaches the current quota threshold, perform the next step. ;

Step 200: The prepaid client sends an application quota request message to the prepaid server, where the message carries the quota currently used by the group prepaid account;

Step 210: After receiving the quota request, the prepaid server records the quota used by the group prepaid account, and allocates the quota and the quota threshold to the account again, and returns the information to the prepaid client by assigning the quota message. If the account has a balance allocation, the allocated quota is the total amount of the last allocated quota and the newly allocated quota, and the quota threshold is also recalculated according to the total quota. If there is no balance, the last allocated quota and quota threshold are returned;

Step 220: After receiving the allocation quota message, the prepaid client determines whether a new quota is allocated for the group prepaid account, and if yes, changes the current allocation quota and the quota threshold of the account, Returning to step 180, if no new quota is allocated, perform the next step;

Step 230, the prepaid client monitors the terminal using the group prepaid account to use the remaining quota, and then stops the cluster service of the terminals;

Step 240: The prepaid client sends a prepaid end request message to the prepaid server, and carries the total amount of quota currently used by the group prepaid account;

Step 250: The prepaid server records the total quota used by the group prepaid account for the billing, recovers the allocated but unused quota, returns the ending prepaid response message to the prepaid client, and the prepaid client clears the prepaid The information of the account ends.

In the above process, the quota uses the duration, traffic, or number of calls in the account charging mode as the unit, which can facilitate the prepaid client to calculate the quota. Moreover, the quota of this embodiment is allocated in segments, because for a group prepaid account, it is not appropriate to allocate the full amount for the terminal of a certain call. Moreover, since the packet message between the prepaid server and the prepaid client may be lost, the segmentation allocation method can reduce the loss caused by the packet loss. As for the quota allocated for each time, it may be a fixed value, or may be adjusted according to the number of terminals, which is not limited by the present invention.

The prepaid client carries the used quota each time the quota is applied, and the prepaid server records the quota used by the group prepaid account, which can also reduce the loss caused by the packet loss.

When the charging method of duration and traffic is adopted, the quota threshold mentioned in the process can be set to a proportional value of the quota, such as 70%~90%, and the prepaid client applies again in time when the used quota reaches the threshold. Quotas, thus avoiding the interruption of calls caused by insufficient quotas. However, in other embodiments, the threshold does not have to be specified and transmitted by the prepaid server to the scheduling server. The scheduling server may use a ratio of the current allocation quota, or subtract the current allocation quota by a fixed value to obtain the current The quota threshold is also ok. However, it is better to set it up in the prepaid server.

When the number of calls is used, the quota for each allocation can be set to 1, and the quota limit is not set or set to 1, and when the terminal has used the quota, it is not necessary to monitor the duration and traffic of the terminal. Set the used quota to 1 when you exit the call. As for other charging methods, it is also possible to calculate the number of times of speaking during the call, such as the user said during a call. The count is 3, which counts the number of times the terminal acquires the right to call when billing.

If a charging mode is adopted in the system, the accounting information may not be included in the authorization message. This situation should be considered as carrying the default charging mode information.

In the above process, when the prepaid server finds that the group prepaid account has no balance to be allocated, it is assigned a zero quota or a previously allocated quota and quota threshold, but in another embodiment, other indications that there is no balance allocation may also be used. Information, such as setting a flag.

Second embodiment: prepaid by user

This embodiment is a method for implementing prepaid by user on a digital trunking system. The pre-paid by user feature is that the user's prepaid account is used by the user alone, and the user's prepaid account is activated when the user joins the call. During billing, billing is based on the duration of a single terminal, the amount of traffic, or the number of calls.

The flow of the method of this embodiment will be described below, including the following steps:

Step 310: The calling terminal initiates a trunking call, which may be a group call or a private call, and the start message is sent to the scheduling server by using the base station subsystem.

Step 320: The scheduling server sends an authentication request message to the authentication server, where the authentication server authenticates the calling terminal and the called group.

Step 330: The prepaid server residing on the authentication server determines, according to the prepaid information of the related user of the call, the prepaid account, the corresponding terminal, the charging mode, and the like involved in the charging, and prepays for each user. Fee account allocation quota (time, traffic or number of calls) and quota threshold, accounts without balance allocation are assigned zero quota, and these prepaid information is returned to the prepaid client residing on the dispatch server through the authorization message or the allocation quota message. ;

Step 340: After receiving the allocation quota message, the prepaid client informs the scheduling server to initiate paging for the terminal that uses the account, and notifies the scheduling server not to find the account that has the available quota. Call the terminal that uses these accounts;

After the call is established, the following charging process is performed for each user prepaid account corresponding to the paged terminal - Step 350: The prepaid client monitors the status of the paged terminal and the quota usage. If the terminal using the account exits the call before the account has reached the current quota threshold, step 400 is performed, otherwise When the quota is used to reach the current quota threshold, the next step is performed;

Step 360: The prepaid client sends an application quota request message to the prepaid server, where the message carries the quota currently used by the prepaid account of the user;

Step 370: After receiving the quota request, the prepaid server records the quota used by the user prepaid account, and allocates the quota and quota threshold for the account again, and returns the quota message to the prepaid client, if the account still has For the balance allocation, the allocated quota is the total amount of the last allocated quota and the newly allocated quota, and the quota threshold is also recalculated according to the total quota. If there is no balance, the quota and quota thresholds that were last allocated are returned;

Step 380: After receiving the allocation quota message, the prepaid client determines whether a new quota is allocated for the user prepaid account. If yes, the current allocation quota and the quota threshold of the account are modified, and the process returns to step 350. Otherwise, the step is performed. 390;

Step 390: The prepaid client monitors the terminal using the user prepaid account to use the remaining quota, and then stops the cluster service of the terminal;

Step 400: The prepaid client sends a prepaid end request message to the prepaid server, and carries the total amount of quota currently used by the user prepaid account;

Step 410: The prepaid server records the total quota used by the user for the prepaid account, reclaims the allocated but unused quota, returns the ending prepaid response message to the prepaid client, and the prepaid client clears the user prepaid account. The information ends.

As can be seen from the above process, since the account is activated when the call is initiated for the user prepaid account, the prepaid server can perform the first quota allocation while the authentication returns to the prepaid account. . Of course, it is also possible to apply the first quota to the prepaid server for the user prepaid account after receiving the prepaid account by the dispatching server in the manner of the first embodiment.

When assigning quotas for user prepaid accounts and group prepaid accounts, it is not excluded in another implementation. In the example, the possibility of full allocation is made. If all the available balances (if any) of the account are allocated when the quota is allocated in step 330, there is no need to calculate the quota threshold, and after step 340, prepay for each user. The account performs the following billing process:

Step 350', the prepaid client monitors the status of the paged terminal and the quota usage. If the terminal exits the call before the quota of the account used by the terminal is used, the next step is performed, otherwise, when the quota is used up, , then perform the next step;

Step 360 ′, the prepaid client sends a prepaid end request message to the prepaid server, and carries the total amount of quota currently used by the user prepaid account;

Step 370', the prepaid server records the total quota used by the user for the prepaid account, and recycles the allocated but unused quota (if any), and returns the ending prepaid response message to the prepaid client, the prepaid client. Clear the information of the user's prepaid account and end.

In general, if the terminal exits the call before the account has no balance available (including the balance has been used up or not enough), the prepayment is terminated and the quota is returned, otherwise the prepayment is terminated when the account has no balance available. This is the same for both segment allocation and primary allocation.

Third Embodiment: Prepaid by group

This embodiment is an implementation method for implementing pre-payment by group on a digital trunking system. In this method, only the duration or traffic of the group call is calculated when charging the group prepaid account, and is no longer accumulated for each terminal. This is especially applicable to the current conventional digital trunking system, because the system has the advantages of large capacity and rapid access, but the scheduling server only controls to the base station subsystem during paging, and real-time monitoring of the terminal is difficult. When billing in this manner, there is no case where the user's prepaid account is already activated on the dispatch server when the group call is initiated.

In addition, it should be noted that the group pre-payment proposed by the present invention charges the group pre-paid account when the group call occurs, and does not mean that the terminal in the group must be called when the call occurs. The deduction of the group prepaid account, the latter is actually the prepayment according to the group.

The following describes the process of the method in this embodiment. Referring to FIG. 3, the method includes the following steps: Step 510: The calling terminal initiates a group call, and the start message is sent to the scheduling server by using the base station subsystem. Step 520: The scheduling server sends an authentication request message to the authentication server, where the authentication server authenticates the calling terminal and the called group.

Step 530: The prepaid server residing on the authentication server determines the group prepaid account to be used by the group call and the charging mode of the account, allocates a quota and a quota threshold for the account, and assigns zero if there is no balance allocation. Quota, returning the prepaid information to the prepaid client residing on the dispatch server through the authorization message or the allocation quota message;

Step 540: After receiving the allocation quota message, the prepaid client determines whether the group prepaid account has an available quota. If yes, the notification scheduling server initiates paging for the group terminal, and step 550 is performed; if no quota is available, Reject the group call and end;

Step 550: After the group call is established, the prepaid client monitors the status of the group call and the quota usage (the scheduling server has the capability), if the group pre-paid account has used the quota before reaching its current quota threshold. If the call has expired, go to step 600. Otherwise, if the used quota reaches the current quota threshold, go to the next step.

Step 560: The prepaid client sends an application quota request message to the prepaid server, where the message carries the quota currently used by the group prepaid account;

Step 570: After receiving the quota request, the prepaid server records the quota used by the group prepaid account, and allocates the quota and quota threshold to the account again, and returns the quota message to the prepaid client, if the account is still If there is a balance allocation, the allocated quota is the total amount of the last allocated quota and the newly allocated quota, and the quota threshold is also recalculated according to the total quota. If there is no balance, the last allocated quota and quota threshold are returned;

Step 580: After receiving the allocation quota message, the prepaid client determines whether a new quota is allocated for the group prepaid account, and if yes, changes the current allocation quota and the quota threshold of the account, and returns to step 550. Otherwise, the execution is performed. Next step;

Step 590, the prepaid client monitors the group call to stop the group call after using the remaining quota; Step 600, the prepaid client sends a prepaid end request message to the prepaid server, and the prepaid account carrying the group is currently used. Total quota;

Step 610: The prepaid server records the total quota used by the group prepaid account, and recycles the allocated but unused quota, and returns the ending prepaid response message to the prepaid client. The payment client clears the information of the group prepaid account and ends.

Pre-payment by group can also adopt another implementation manner, that is, the situation of each terminal can be considered in charging, for example, considering the number of terminals to join, in this case, the above process does not need to be modified, but only in step 550. There are different ways to calculate the usage of quotas for group calls.

When pre-payment by group, the possibility of full allocation is not excluded, and the flow is similar to the process of full-user pre-payment according to the second embodiment, that is, all the balances are allocated for the first time. The quota threshold is not calculated. When the prepaid client is charging, it monitors the status of the group call and the quota usage. If the call is exited before the quota is used, the prepaid end request is sent to the prepaid server and returned to the used one. Quota, otherwise send a prepaid end request to the prepaid server when the quota is used. Subsequent processing is the same.

The processes of the above three embodiments can also be modified and modified under different network conditions or under different prepaid strategies. E.g:

1) In a digital trunking system, prepaid clients residing on different dispatch servers may support all billing methods. The above three processes are based on this condition. When some prepaid clients do not support the charging method used by the prepaid account, the terminal using the account cannot be allowed to conduct services. When considering this factor, in steps 130, 330, and 530 of the above three processes, it is necessary to increase whether the prepaid client residing on the scheduling server supports the account to be used for the call, that is, the group prepaid account, the user prepaid. Fee accounts and group prepaid accounts. For accounts that do not support their billing methods, they are no longer sent to the dispatch server or are not assigned quotas. In this way, the dispatch server will not page the terminals that use these accounts.

As for how the prepaid server obtains the charging mode information supported by the prepaid client, it can be updated by each client timing or when the information changes to the home prepaid server. Alternatively, in steps 120, 320, and 520, the scheduling server supports the charging mode supported by the prepaid client on the server along with the authentication message to the prepaid server where the authentication server resides.

2) In a digital trunking system with roaming function, the dispatching server where the calling terminal is located and It is not necessarily the scheduling server to which the group belongs. In this case, the authentication process may be different from the above three embodiments, one of which is initiated by the calling server and the scheduling server to which the group belongs. The authentication of the calling terminal and the called terminal, the scheduling home register resides in the authentication server, and the scheduling server where the group or the terminal is currently located can be known.

In this way, for the prepaid or prepaid group prepaid process, the user corresponding to the calling terminal or the group prepaid account and its corresponding terminal, the charging method can be returned when the calling server is authenticated, and the home server is authenticated. Then return the user or group prepaid account related to the called terminal and its corresponding terminal, charging method. When the called terminal roams to other cooperative scheduling servers, the home scheduling server sends the related account information of the terminal to the scheduling server where the terminal is located. The work of specific account distribution may also be different when the authentication process is different. In short, it is necessary to send the prepaid account involved in the billing to all the dispatch servers where the terminal using the account is currently located. In the case of prepaid by the group, the same prepaid account may be sent to different prepaid clients, and then The prepaid client residing on each scheduling server independently monitors the status and quota usage of the terminal, independently interacts with the prepaid server, completes the quota application and allocation, and ends the prepaid charging process, the method and the above implementation. The examples are the same.

For the group prepaid process, the group prepaid account can be sent to the originating dispatch server or the group-owned dispatch server or other servers participating in the group call, and these scheduling servers can all have group call status and The quota usage is monitored to complete the billing of the group prepaid account.

3) If the digital trunking system needs to support three charging modes at the same time, if it is possible for a certain terminal to correspond to multiple prepaid accounts, then the prepaid server that resides on the authentication server needs to be authenticated. According to the prepaid information of the call related user, first determine which account the user wants to use, which can be selected according to the priority order of the system configuration. After different prepaid accounts are determined, the subsequent processing of each type of account can adopt the manners of the above three embodiments and the manner of changing the same, however, in order to make the process as consistent as possible, prepaid accounts and group prepayments for users The billing process of the fee account is preferably unified to be the same as the group prepaid account. The account is first allocated in the authorization message, and then the first quota is applied by the prepaid client, and the quota is allocated by segmentation.

4) In the above embodiment, a charging method is agreed for each prepaid account. But the invention The policy for the prepaid server to select the charging mode is not limited to this. If the prepaid account can adopt multiple charging methods, it can be combined with the charging mode supported by the prepaid client to select a charging method supported by both. . Avoid talking when the prepaid client does not support it.

Industrial applicability

The method of the invention can be applied to a digital trunking system, and can provide a reasonable prepaid method for a wide range of service groups of the cluster system to meet different levels of user needs, and can minimize the charging error.

Claims

Claim

A method for implementing prepaid payment in a digital trunking system, wherein a prepaid client resides in a scheduling server of the system, and a prepaid server resides in the authentication server, the method comprising the following steps:

(b) the prepaid server residing on the authentication server determines, according to the prepaid information of the related user of the call, information about the prepaid account involved in charging, the terminal using the account, and the charging mode, Pre-paid client interactions residing on the scheduling server, notifying the determined information to the pre-paid client, and allocating quotas for the inactivated accounts;

(d) the prepaid client monitors the status and quota usage of the paged terminal, and charges the prepaid account, and if the prepaid account has no balance available before use, the terminal using the account exits the call. , perform the next step, otherwise execute the next step when there is no balance available for the prepaid account;

2. The method according to claim 1, wherein in the step (b), when the prepaid account involved is a group prepaid account, the interaction with the prepaid server is completed by the following steps -

(b2) the prepaid client determines whether the group prepaid account in the authorization message is activated, if activated, notifies the scheduling server to page the terminal using the accounts, and then performs step (d) to prepay the unactivated group Fee account, perform step (b3);

(b3) the prepaid client sends an application quota message to the prepaid server, Activated group prepaid account application quota;

(b4) after receiving the quota request, the prepaid server allocates a quota for the group prepaid account segment with the balance, returns the quota message to the prepaid client, and returns the account without the balance to the balance without the balance allocation. Information, perform step (c).

3. The method according to claim 2, wherein in the step (d), when charging the group prepaid account, the method further comprises the following steps:

(d3) after receiving the quota request, the prepaid server allocates a new quota to the account when there is a balance allocation, and returns to the prepaid client through the allocation quota message, when the account has no balance allocation , carrying the information of no balance allocation in the returned allocation quota message;

4. The method according to claim 1, wherein in the step (b), when the prepaid account involved is a user prepaid account, the interaction with the prepaid server is completed by the following steps: The prepaid server determines the user prepaid account involved in the charging and its corresponding terminal, the charging method, allocates a quota for each user prepaid account, and the account without the balance allocation does not have the identifier of the balance allocation, and then these prepaid Information is returned to the prepaid client.

The method according to claim 1, wherein in the step (b), when the prepaid account involved is a user prepaid account, the prepaid service is completed by the following steps: Interaction:

(1) the prepaid server determines a prepaid account of each user involved in the charging, a terminal that uses the account, and a charging mode, and sends the information to the prepaid client along with the authorization message;

The method according to claim 1, wherein in the step (b), the prepaid fee server uses a segment allocation method when allocating quotas for the user prepaid account, and the step is

In (d), when charging a user's prepaid account, it is further divided into the following steps:

7. The method according to claim 1, wherein the quota is in units of call duration, call traffic, or number of calls.

The method according to any one of claims 1 to 6, wherein the prepaid server allocates a quota for the account in the allocation quota message when the prepaid account has no balance for distribution. Set to the quota at the time of the last allocation, and set it to zero on the first allocation.

The method according to claim 3 or 6, wherein, when the prepaid client applies for a quota again to the prepaid server, the message carries the quota currently used by the group or the user prepaid account. And the prepaid server records the quota used by the prepaid account after receiving the message.

The method according to claim 3 or 6, wherein, when the prepaid server allocates quotas for the group or user prepaid accounts again and has a balance for distribution, the allocated quota is the last allocated quota plus The total amount of the newly allocated quota.

The method according to claim 3 or 6, wherein the threshold for the current allocation quota is specified by the prepaid server according to the allocation quota each time the quota is allocated, and the allocation quota is included Returning to the prepaid client together; or, the quota threshold is calculated by the prepaid client according to the current allocation quota.

The method according to claim 1, wherein in the step (b), the prepaid server further determines whether the prepaid client residing on the scheduling server supports the call to be used. The prepaid account is not notified to the prepaid client or is not assigned a quota for the prepaid account that does not support its billing method.

The method according to claim 12, wherein the prepaid server knows the charging mode information supported by the prepaid client by: periodically reporting by the prepaid client in the system The supported charging method is reported to the prepaid server when the charging mode changes, and the synchronous update is implemented; or, in the step (a), the prepaid service to be camped on by the scheduling server The charging mode supported by the client is reported to the prepaid server residing on the authentication server along with the authentication message.

The method according to claim 12, wherein, in the step (b), when a prepaid account can adopt multiple charging modes, the terminal that is used in combination with the account resides on the scheduling server. The charging method supported by the prepaid client selects a charging method supported by both.

The method according to claim 1, wherein the digital trunking system has a roaming function, and in the step (b), the prepaid server sends the prepaid account involved in the charging to the terminal using the account. Currently, all the scheduling servers, the prepaid clients residing on each scheduling server independently complete the charging of the received prepaid accounts.

The method according to claim 1, wherein in the step (b), when the user has multiple prepaid accounts at the same time, the prepaid server selects one of the prepaid accounts according to a preset policy. Then, according to the charging process of the prepaid account.