WO2007076646A1 - Procede de prepaiement dans un systeme numerique en grappe - Google Patents

Procede de prepaiement dans un systeme numerique en grappe Download PDF

Info

Publication number
WO2007076646A1
WO2007076646A1 PCT/CN2006/000919 CN2006000919W WO2007076646A1 WO 2007076646 A1 WO2007076646 A1 WO 2007076646A1 CN 2006000919 W CN2006000919 W CN 2006000919W WO 2007076646 A1 WO2007076646 A1 WO 2007076646A1
Authority
WO
WIPO (PCT)
Prior art keywords
prepaid
quota
account
server
client
Prior art date
Application number
PCT/CN2006/000919
Other languages
English (en)
Chinese (zh)
Inventor
Yunbin Chen
Zhaosen Geng
Yunfei Ma
Original Assignee
Zte Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zte Corporation filed Critical Zte Corporation
Publication of WO2007076646A1 publication Critical patent/WO2007076646A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP

Definitions

  • 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.
  • 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.
  • 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.
  • 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.
  • the method includes the following steps:
  • 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;
  • 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;
  • 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;
  • 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.
  • the above method may further have the following features:
  • the interaction with the prepaid server is completed by the following steps:
  • 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;
  • step (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);
  • the prepaid client sends an application quota message to the prepaid server to apply for a quota for the unactivated group prepaid account;
  • step (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.
  • the above method may further have the following features:
  • the method is further divided into the following steps:
  • the prepaid client monitors the status and quota usage of all paged terminals.
  • the account has been used according to the quotas used by all terminals using the account;
  • step (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;
  • 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;
  • 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;
  • 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).
  • the foregoing method may further have the following features:
  • 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.
  • the above method may further have the following features:
  • 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;
  • the prepaid client 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;
  • step (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).
  • 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:
  • 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
  • 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;
  • 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;
  • 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).
  • the above method may also have the following features:
  • the quota is in units of call duration, call traffic, or number of calls.
  • 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.
  • the foregoing method may further have the following feature: the prepaid client to the prepaid
  • the message carries the quota currently used by the group or the user prepaid account
  • the prepaid server records the message and records the used usage of the prepaid account
  • 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.
  • 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.
  • the foregoing method may further have the following features:
  • the prepaid server further determines whether the prepaid client residing on the scheduling server supports the prepaid account to be used for the call.
  • 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.
  • 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.
  • the foregoing method may further have the following features:
  • 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.
  • 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.
  • the foregoing method may further have the following features:
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • FIG. 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).
  • BSS Base Station Subsystem
  • the above-mentioned residency is a logical residency.
  • 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.
  • the prepaid client 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.
  • 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.
  • 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;
  • a trunking call which may be a group call or a private call
  • 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.
  • 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;
  • 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.
  • the account used quota is calculated by accumulating the quotas used by all the terminals using the account;
  • the terminal may access immediately, late access or never access the call.
  • the terminal that does not have the access call also includes monitoring the status of the call paging the terminal.
  • 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.
  • 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.
  • 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.
  • the segmentation allocation method can reduce the loss caused by the packet loss.
  • 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.
  • 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.
  • 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.
  • 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.
  • the accounting information may not be included in the authorization message. This situation should be considered as carrying the default charging mode information.
  • 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.
  • billing is based on the duration of a single terminal, the amount of traffic, or the number of calls.
  • 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.
  • a trunking call which may be a group call or a private call
  • 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
  • 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;
  • 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.
  • the prepaid server can perform the first quota allocation while the authentication returns to the prepaid account.
  • 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.
  • 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.
  • This embodiment is an implementation method for implementing pre-payment by group on a digital trunking system.
  • 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.
  • the scheduling server only controls to the base station subsystem during paging, and real-time monitoring of the terminal is difficult.
  • 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 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.
  • the quota usage the scheduling server has the capability
  • 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.
  • 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.
  • 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.
  • 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.
  • the prepaid client 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.
  • prepaid clients residing on different dispatch servers may support all billing methods.
  • the above three processes are based on this condition.
  • the terminal using the account cannot be allowed to conduct services.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the prepaid server that resides on the authentication server needs to be authenticated.
  • 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.
  • a charging method is agreed for each prepaid account.
  • 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.
  • 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.

Abstract

L'invention concerne un procédé de prépaiement dans un système numérique en grappe, qui est mis en oeuvre comme suit: un terminal émetteur effectue un appel de grappe; le PDS demande l'autorisation d'un serveur d'autorité; le serveur de prépaiement résidant dans le serveur d'autorité détermine un compte de prépaiement; le terminal utilise le compte et le mode d'imputation des frais en fonction des données de prépaiement associées à cet appel, attribue un quota à ces comptes inactifs et en informe le terminal client de prépaiement; le terminal client de prépaiement demande au serveur d'expédition d'envoyer un radiomessage au terminal utilisant le compte de prépaiement et détenant uniquement un quota utilisable; le terminal client de prépaiement surveille l'état du terminal destinataire du radiomessage et les conditions d'utilisation du quota et, si le compte ne présente pas un solde pouvant être débité ou si le terminal exploitant ce compte abandonne cet appel, demande au serveur de prépaiement l'arrêt du prélèvement des frais sur ce compte; le serveur de prépaiement enregistre le montant du quota et récupère le quota inutilisé, ce qui met fin à la procédure. L'imputation des frais peut être fondée sur la durée, le débit ou le nombre d'appels, et une fonction de prépaiement peut être mise en oeuvre sur la base d'un groupe ou d'un abonné.
PCT/CN2006/000919 2005-12-31 2006-05-09 Procede de prepaiement dans un systeme numerique en grappe WO2007076646A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2005101356692A CN1992763B (zh) 2005-12-31 2005-12-31 一种数字集群系统实现预付费的方法
CN200510135669.2 2005-12-31

Publications (1)

Publication Number Publication Date
WO2007076646A1 true WO2007076646A1 (fr) 2007-07-12

Family

ID=38214693

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2006/000919 WO2007076646A1 (fr) 2005-12-31 2006-05-09 Procede de prepaiement dans un systeme numerique en grappe

Country Status (2)

Country Link
CN (1) CN1992763B (fr)
WO (1) WO2007076646A1 (fr)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100568991C (zh) * 2007-09-12 2009-12-09 中兴通讯股份有限公司 一种数字集群系统中对预付费用户进行寻呼控制的方法
CN101141712B (zh) * 2007-10-10 2011-01-05 中兴通讯股份有限公司 一种数字集群呼叫中预付费欠费用户的释放方法及其装置
CN101159927B (zh) * 2007-11-08 2010-06-16 中兴通讯股份有限公司 一种集群通信中的计费方法
CN101540986B (zh) * 2009-04-16 2011-10-26 中兴通讯股份有限公司 一种预付费业务的计费方法及系统
CN101616392B (zh) * 2009-06-26 2012-04-18 中兴通讯股份有限公司 一种增值业务提供系统和方法
CN101635906B (zh) * 2009-08-27 2012-05-23 中兴通讯股份有限公司 灵活振铃群组智能业务的触发方法与装置
CN102868982B (zh) * 2012-10-08 2015-05-13 上海帜讯信息技术有限公司 面向移动终端的信息转发和企业获取交互信息的方法
CN103929316B (zh) * 2013-01-11 2017-10-31 阿尔卡特朗讯 一种分配通信配额的方法及相应的在线计费系统
CN111194066B (zh) * 2020-01-10 2022-02-11 中国联合网络通信集团有限公司 一种基站联盟方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1418021A (zh) * 2001-10-30 2003-05-14 深圳市中兴通讯股份有限公司 一种移动通信系统及其实现集群业务的方法
WO2004071011A1 (fr) * 2003-02-10 2004-08-19 Telefonaktiebolaget Lm Ericsson (Publ) Pre-initialisation d'une provision de quota prepaye dans des reseaux mobiles 3g
CN1585519A (zh) * 2004-06-04 2005-02-23 中兴通讯股份有限公司 数字集群系统计费信息收集及计费方法
CN1635726A (zh) * 2003-12-29 2005-07-06 华为技术有限公司 Cdma20001x分组预付费业务实现方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1283073C (zh) * 2003-08-15 2006-11-01 华为技术有限公司 一种实现预付费用户进行虚拟专用网业务的方法
CN100372425C (zh) * 2003-12-04 2008-02-27 华为技术有限公司 一种实现集群业务组呼漫游的方法
CN100407618C (zh) * 2004-03-05 2008-07-30 中兴通讯股份有限公司 一种集群业务鉴权接口及集群业务鉴权实现方法
CN100396110C (zh) * 2004-05-21 2008-06-18 华为技术有限公司 闭合用户群业务计费实现方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1418021A (zh) * 2001-10-30 2003-05-14 深圳市中兴通讯股份有限公司 一种移动通信系统及其实现集群业务的方法
WO2004071011A1 (fr) * 2003-02-10 2004-08-19 Telefonaktiebolaget Lm Ericsson (Publ) Pre-initialisation d'une provision de quota prepaye dans des reseaux mobiles 3g
CN1635726A (zh) * 2003-12-29 2005-07-06 华为技术有限公司 Cdma20001x分组预付费业务实现方法
CN1585519A (zh) * 2004-06-04 2005-02-23 中兴通讯股份有限公司 数字集群系统计费信息收集及计费方法

Also Published As

Publication number Publication date
CN1992763B (zh) 2010-12-01
CN1992763A (zh) 2007-07-04

Similar Documents

Publication Publication Date Title
WO2007076646A1 (fr) Procede de prepaiement dans un systeme numerique en grappe
EP1871084A1 (fr) Procédé et système pour facturation à un tiers
EP1936863B1 (fr) Procede de selection/commutation de mode de facturation et dispositif associe
TW390086B (en) Method for handling parallel transactions on telephone pre-paid accounts
WO2009100669A1 (fr) Procédé de facturation, dispositif de commande, dispositif de facturation et système de facturation
WO2006015542A1 (fr) Procede de reduction de la charge d'un tpf
JP2004517526A (ja) 通信システムにおける課金
CN102144372A (zh) Ims网络中的联机计费关联
EP3001601B1 (fr) Procédé de commande de crédit, entité à fonction d'application de politique et de facturation, et système de facturation en ligne
WO2010063176A1 (fr) Procédé de facturation d'appel fondé sur un système de facturation en ligne et système de communication
WO2006050669A1 (fr) Procede de chargement en fonction d'un flux de paquets de donnees
WO2010118668A1 (fr) Procede de facturation et systeme pour service prepaye
WO2006102836A1 (fr) Procede d’implementation d’un compte partage prepaye
WO2005083933A1 (fr) Procede et systemes de mise en oeuvre de prepaiement de services de donnees dans un reseau cdma
CN108401231B (zh) 一种计费方法、装置和系统
WO2012062076A1 (fr) Procédé et système de facturation de service de prépaiement pour un réseau privé virtuel intégré (ivpn)
WO2013160761A1 (fr) Procédé et appareil permettant de traiter une demande de facturation
CN100521720C (zh) 一种基于流量/时长和业务质量的分组预付费业务实现方法
WO2007079624A1 (fr) Procede de mise en oeuvre de prepaye dans des groupes pour systeme en grappe numerique
WO2009155837A1 (fr) Procédé de traitement de service à flux multiples, passerelle de réseau de service d'accès et serveur de comptabilité
CN109547956B (zh) 一种多业务并发处理方法
KR101006275B1 (ko) 선불 계정 세분화를 이용한 선불 서비스 제공 방법 및 시스템
WO2015109753A1 (fr) Procédé et dispositif de changement de système de facturation
WO2010069184A1 (fr) Procédé et système pour effectuer la facturation dans un service de réponse vocale inactive (ivr)
WO2010051771A1 (fr) Procédé, dispositif et système pour garantir un service de commande et de commutation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06741814

Country of ref document: EP

Kind code of ref document: A1