CN1722870A - A method for identifying different cluster groups - Google Patents

Abstract

The invention discloses a method for identifying different cluster groups, and the method further includes: A. The maintenance terminal initiates a dynamic reorganization cluster group request to the cluster service server; One or more mobile service switching centers in the group call area, the mobile service switching center judges whether the group identification and group call type in the stored trunk group information are the same as the group identification and group call type carried in the request, if yes, Execute step C; otherwise, execute step D; C. The mobile service center judges whether the group call area carried by the request overlaps with the stored group group call area with the group identifier and group call type carried by the request, if yes , the cluster service server does not execute the request; otherwise, execute step D; D. The cluster service server executes the request, and stores the requested dynamic reorganization cluster group information.

Description

A way to identify distinct cluster groups

technical field

The invention relates to the identification technology of different cluster groups, in particular to a method for identifying different cluster groups.

Background technique

Trunk Communication (Trunk Communication or Trunk Radio), which means to gather some various types of user terminals (MS) together to form a system that effectively utilizes the same trunk line or bus wireless channel, and conduct multi-purpose, command and dispatch as the main body. High-efficiency dedicated wireless communication system. Compared with dedicated wireless communication systems such as walkie-talkies with decentralized operation and low resource utilization, the trunking communication system, like a centerless system, allocates dynamic channels to multi-terminal sharing and makes full use of limited wireless channel resources as design ideas. On this basis, a common platform is built, so that various types of terminals can share rich special functions and new ways of adding value to various services.

The trunking communication system uses the group call reference and the trunking group type to identify a trunking group, wherein the trunking group type identifies the group calling type of the trunking group, that is, the group calling type of the trunking group is Voice Group Call Service (VGCS) Also Voice Broadcasting Service (VBS). The group call reference uniquely identifies a cluster group, and the group call reference is composed of a group identifier (ID) and a group call area, where: the group ID identifies the MS in the cluster group, and all the MSs in the cluster group have this set The group ID of the group definition. The cluster group stores its group ID in the Home Location Register (HLR) and the MS's Subscriber Identity Module (SIM) card, and is used to determine the cluster group the MS is in during authentication. An MS can sign up to 50 cluster groups at most. The group call area is defined when the group call type of the trunk group is VGCS, where the trunk group can make a group call. Only MSs in this area and members of the trunk group can perform the group call service.

Since the group ID is used to identify the cluster group to which the MS belongs, different cluster groups have different group IDs. However, the resource of the group ID number is very limited. For example, if the group ID number is set to 3 digits, only one thousand different cluster groups can be identified; if the group ID number is set to 5 digits, only ten cluster groups can be identified. Thousands of different cluster groups. This is far from enough for the cluster communication system in the entire communication network.

If different cluster groups use repeated group IDs, the shortage of group ID number resources can be solved. However, since different cluster groups use repeated group IDs and MSs subscribe to different cluster groups are identified by group IDs, a MS may have multiple duplicate group IDs when subscribing to different cluster groups. At present, there is no solution on the network side and the air interface to solve the problem that the MS can subscribe to different cluster groups with the repeated group ID. Therefore, when the MS accesses the cluster group through the repeated group ID, it cannot be sure that the access has Which cluster group for the group ID.

Therefore, how to solve the problem that the MS subscribes to different cluster groups with repeated group IDs on the network side and the air interface becomes an urgent problem to be solved.

Contents of the invention

In view of this, the main purpose of the present invention is to provide a method for identifying different cluster groups, which can solve the problem of MS signing different cluster groups with repeated group IDs on the network side and air interface, so as to realize the use of different cluster groups Duplicate group ID to identify.

According to above-mentioned purpose, technical scheme of the present invention is achieved like this:

A method for identifying different cluster groups, the mobile service switching center pre-stores the cluster group information under its jurisdiction, the method also includes:

A. The maintenance terminal initiates a dynamic reorganization trunk group request to the trunking service server, and the request carries the group identifier, group call type and group call area of the dynamic reorganization trunk group;

B. The trunking service server forwards the request to one or more mobile service switching centers that govern the group call area carried by the request, and the mobile service switching center judges whether the group identifier and the group call type in the stored trunk group information are consistent with The group identifier carried in the request is the same as the group call type, if yes, go to step C; otherwise, go to step D;

C. The mobile service center judges whether the group call area carried by the request overlaps with the stored trunk group call area with the group identifier and group call type carried by the request. If yes, the mobile service switching center sends a message to the trunk service server The request fails to respond, and the cluster service server does not execute the request; otherwise, execute step D;

D. The mobile service switching center sends a successful response to the request to the cluster service server, and the cluster service server executes the request and stores the requested dynamic reconfiguration cluster group information.

The dynamic cluster group reorganization request described in step A is to create a cluster group or modify an already created cluster group.

The one or more mobile service switching centers governing the group call area carried by the request in step B are: one anchor mobile service switching center and one or more relay mobile service switching centers;

In step D, after the successful response of sending the request, the method is further: the trunking service server judges whether the requests sent by all anchor mobile service switching centers and relay mobile service switching centers that govern the group call area carried by the request are successfully received In response, if yes, the cluster service server executes the request, and stores the requested dynamically reorganized cluster group information; otherwise, the cluster service server does not execute the request.

When the cluster communication system is superimposed with a virtual private network,

Before step B, the method further includes: the trunking service server determines the virtual private network that governs the group call area carried by the request, and checks whether the group identifier and group call type of the existing trunking group in the virtual private network stored by itself are consistent with The group identifier and group call type carried in the request are repeated, if yes, the trunking service server does not execute the request; otherwise, step B is executed.

The process of storing the requested dynamic reorganization cluster group information described in step D is:

The dynamic reconfiguration group information is stored in the database of the cluster service server, and the dynamic reconfiguration cluster information is stored in the mobile switching service center to which it belongs.

When the maintenance terminal wants to increase the user terminal in the dynamic reorganization cluster group, the method further includes:

Set the cluster group list that the user terminal has joined in the database of the cluster service server, and set the group identification repeated subscription counting process table, each record in the table is used to store the user terminal's repeated subscription to different clusters with the same group identification Group signing information;

E. The maintenance terminal initiates a request to the trunking service server to add a user terminal in the dynamically reorganized trunking group, the request carrying the user terminal number, number type, and the group identifier and group call type that the user terminal wants to join the trunking group;

F. The trunking service server judges whether the group identifier and group call type carried in the request are the same as the group identifier and group call type of the trunking group in the trunking group list that the user terminal has joined, if yes, execute step G , otherwise, the cluster service server will process it according to the normal dynamic contract process;

G. The cluster service server judges whether there is a record that the user terminal has signed a contract in the process table for setting the group identifier repeated subscription count, and if so, adds 1 to the number of repetitions of the record; otherwise, creates a group identifier repeated subscription count for the user Process table records, and set the number of repetitions of this record to 1.

When the maintenance terminal wants to delete the user terminal in the dynamic reorganization cluster group, the method further includes:

In the database of the cluster service server, a group identifier repeated subscription counting flow table is set, and each record in the table is used to store the subscription information of the user terminal repeatedly signing different cluster groups with the same group identifier;

E1. The maintenance terminal initiates a request to the trunking service server to delete the user terminal in the dynamically reorganized trunking group, the request carrying the user terminal number, number type, and the group identifier and group call type of the trunking group to be deleted by the user terminal;

F1. The cluster service server judges whether there is a record of the user terminal’s contract in the process table for setting group identifier repeated signing counts. If there is, subtract 1 from the number of repetitions of this record, and go to step G1; otherwise, the cluster service server proceeds as normal Dynamic contract process for processing;

G1. The cluster service server judges whether the number of repetitions of the record is 0 after the number of repetitions is reduced by 1. If yes, delete the record and reply that the maintenance terminal executes the request successfully; otherwise, directly responds that the maintenance terminal executes the request successfully.

The subscription information stored in each record in the table includes: user terminal user number, number type, and group identifier, group call type and repetition times that the user terminal joins.

The process for the cluster service server to determine whether there is a record of the user terminal’s subscription in the flow table for setting the group identifier repeated subscription counting process is as follows: judging whether the user terminal user number, number type, and user terminal number in each record of the group identifier repeated subscription counting flow table The group identifier and group call type that the terminal joins are compared with the user terminal user number and number type carried in the request, and the group identifier and group call type that the user terminal joins.

As can be seen from the above scheme, the method provided by the present invention makes the group call areas and VPNs of different cluster groups with the same group ID different, and sets the group ID repeated subscription count flow table record in the cluster service server database with multiple Subscription information of MSs with the same group ID, therefore, the method provided by the present invention solves the problem of MS signing up for different cluster groups with repeated group IDs on the network side and air interface, thereby realizing that different cluster groups use repeated group IDs to identify .

Description of drawings

FIG. 1 is a schematic diagram of the present invention using repeated group IDs to identify different cluster groups with group call areas.

FIG. 2 is a flowchart of a method for creating or modifying a cluster group by a maintenance terminal according to the present invention.

Fig. 3 is a flow chart of realizing that no repeated group ID is used under a VPN.

FIG. 4 is a flow chart of the present invention when an MS subscribes to a cluster group with a repeated group ID.

FIG. 5 is a flow chart of deleting MSs in cluster groups with duplicate group IDs according to the present invention.

Detailed ways

In order to make the object, technical solution and advantages of the present invention more clear, the present invention will be further described in detail by citing the following embodiments and referring to the accompanying drawings.

In order to solve the problem that MS subscribes to different cluster groups with repeated group IDs on the network side and the air interface, the invention improves different links in the cluster network.

First of all, the group call areas of different cluster groups identified by repeated group IDs must not overlap. In this way, when an MS subscribes to multiple different cluster groups with duplicate group IDs, the group call area can be used to distinguish the group call area to be joined. Which is the cluster group with that duplicate group ID. Of course, before judging whether the group call areas of different cluster groups with duplicate group IDs have overlapping parts, it should also be judged whether the group call types of different cluster groups with duplicate group IDs are the same, and if they are the same, then judge the group call Whether there are overlapping parts in the area, if not, no need to judge again.

Fig. 1 is the schematic diagram that the present invention uses repeated group IDs to identify different cluster groups respectively having group call areas, as shown in the figure:

The group call area of trunk group a includes cell1, eell2, and cell3, and the group call area of trunk group b includes cell4 and cell5. The group call areas of these two trunk groups do not overlap. Trunk group a and trunk group b Both can use duplicate group ID517.

Fig. 2 is the flow chart of the method for creating or modifying the cluster group by the maintenance terminal of the present invention. The maintenance terminal is a terminal that can dynamically reorganize the cluster group by logging into the cluster service server. The present invention pre-sets the cluster group and The information of the cluster group, the information of the cluster group includes the group call area, group ID and group call type, and its specific steps are:

Step 200, when the maintenance terminal creates or modifies a trunking group, it sends a request to the trunking service server to create or modify a trunking group, and the request carries the group ID of the trunking group to be created or modified, the group call type and the trunking group The area to be called;

Step 201, the service server that receives the request determines the anchor mobile service switching center (AnchorMSC) that governs the group call area according to the group call area that the request carries, and forwards the request to the AnchorMSC;

Step 202, AnchorMSC compares the group ID and group call type of the cluster group carried by the request with the group ID and group call type of the existing cluster group of the AnchorMSC, if repeated, perform step 204; otherwise, perform step 203;

Step 203, AnchorMSC replies the request success message to the service server, and proceeds to step 214;

Step 204, the AnchorMSC compares the group call area of the trunk group with the same group ID as the group group carried in the request with the group call area carried in the request, and judges whether the two have an intersection, and if so, executes step 205; Otherwise, execute step 206;

Step 205, AnchorMSC returns the request failure message to the cluster service server, and proceeds to step 214;

Step 206, AnchorMSC replies the request success message to the service server, and proceeds to step 207;

Step 207, the trunking service server judges whether the area to be called by the trunking group carried by the request has a relay MSC (RelayMSC), whether the trunking group crosses MSCs, if it crosses MSCs, it has a RelayMSC, and if so, execute Step 208; Otherwise, execute step 214;

Step 208, the cluster service server submits the request to each RelayMSC of the cluster group;

Step 209, each RelayMSC compares the group ID and group call type of the trunk group carried by the request with the group ID and group call type of the existing trunk group of the RelayMSC, if repeated, execute step 211; otherwise, execute step 210 ;

Step 210, the RelayMSC replies the request success message to the service server, and proceeds to step 214;

Step 211, the RelayMSC compares the group call area of the trunk group that has the same group ID as the trunk group carried in the request with the group call area carried in the request, and determines whether the two have an intersection, and if so, executes step 212 ; Otherwise, execute step 213;

Step 212, the RelayMSC returns the request failure message to the cluster service server, and proceeds to step 214;

Step 213, the RelayMSC replies the request success message to the service server, and proceeds to step 214;

Step 214, the trunking service server judges whether it has received the request success message returned by all the RelayMSCs and AnchorMSCs in charge of the trunking group to be called in the area carried by the request, if yes, execute step 215; otherwise, execute step 216;

Step 215, the trunking service server executes the request, records and stores the trunking group information of the trunking group to be created or modified, namely the trunking group ID, group call area and group call type, and stores it in the database, and sends the request to the maintenance terminal execution success message;

Step 216, sending the request failure message to the maintenance terminal.

Secondly, if the wireless communication system is also superimposed with a VPN, different cluster groups under one VPN cannot use repeated group IDs, and different cluster groups under different VPNs can use the same group ID. Of course, before judging whether the group call areas of different cluster groups with duplicate group IDs belong to a VPN, it should also be judged whether the group call types of different cluster groups with duplicate group IDs are the same, and if they are the same, then judge the group call area. Whether the area belongs to a VPN, if not, no further judgment is required.

Fig. 3 is the flow chart that realizes not to use repeated group ID under a VPN, and its specific steps are:

Step 300, when the maintenance terminal creates or modifies a trunking group, it sends a request to the trunking service server to create or modify a trunking group, and the request carries the group ID of the trunking group to be created or modified, the group call type and the trunking group The area to be called;

Step 301, the service server receiving the request determines the VPN that governs the group call area according to the area to be called by the cluster group carried in the request, and checks the group ID and ID of the cluster group in the VPN stored by itself. Whether the group call type is repeated with the group ID and group call type carried in the request, if yes, execute step 302; otherwise, execute step 303;

Step 302, the service server sends the request failure message to the maintenance terminal;

Step 303, the business server executes the request, records and stores the cluster group information of the cluster group created or modified, namely the cluster group ID, group call area and group call type, and stores them in the database of the cluster service server, and reports to the maintenance The terminal sends the request execution success message.

When the present invention creates or modifies the cluster group information of the cluster group, the cluster group information of the cluster group to be created or modified must be recorded and stored in the database of the cluster service server, and the group ID repeated signing count is established in the database The process table is specially used to deal with the repeated use of the group ID when the cluster group is established or modified. A record in the group ID repeated signing counting process table is shown in Table 1:

field name Field description type of data length (bytes) keywords Allow empty UserNumer User number char 16 1 NumerType Number type 0-IMSI1-MSISDN2-PSTN byte 1 2 GrpID group ID int 4 3 GrpType  Group call type 145-VGCS146-VBS byte 1 4 Counter Number of repetitions (a user can join up to 50 groups, that is, up to 49 repetitions) byte 1

Table I

Table 1 records the group call subscription information of one MS that repeatedly subscribes to different trunk groups with the same group ID. The trunk group call subscription information of the MS includes: MS user number, user number type, international mobile Subscriber Identity (IMSI), Mobile Subscriber Integrated Services Digital Network (ISDN) Number (MSISDN) and Public Switched Telephone Network (PSTN) Number, Group Call Type and Repeat Times. An MS may have multiple records, which are used to record the group call subscription information of different cluster groups with the same group ID that have repeatedly subscribed to different groups.

Table 1 in the database stores multiple trunk group call subscription information records of several MSs.

Fig. 4 is the flow chart when the MS of the present invention subscribes to a cluster group with a repeated group ID, and its specific steps are:

Step 400, the maintenance terminal initiates a request for adding an MS in the trunking group to the trunking service server, and the request carries the MS user number to be added, the type of the MS number, the group ID of the trunking group, and the group call type of the trunking group;

Step 401, the trunking service server judges whether the MS has repeatedly subscribed to different trunking groups with the same group ID and group call type according to the MS's pre-stored subscription trunking group list in the trunking service server and the information carried in the request, If not, execute step 402; otherwise, execute step 403;

The trunking service server pre-stores each MS's subscription trunking group list, which includes subscription information such as the trunking group ID, group call type, and group call area that the MS subscribes to;

Step 402, process according to the dynamic signing process of the prior art, and turn to step 406;

Step 403, the trunking service server judges whether there is a record of the MS's repeated subscription group ID in all the group ID repeated subscription count flow table records stored in advance by the MS, and if so, proceeds to step 404; otherwise, proceeds to step 405;

The basis for judging is to repeat the MS user number and number type in each record of the group ID subscription counting process table, as well as the group ID that the MS joins, the group call type, and the MS user number, number type, and MS to join in the request. The group ID and group call type are compared one by one.

Step 404, add 1 to the number of repetitions in the corresponding group ID repeated subscription count flow table record stored in advance by the MS, and turn to step 406;

Step 405: Create a group ID repeated subscription counting flow record for the MS in the group ID repeated subscription counting flow table stored in advance by the MS, set the number of repetitions to 1, and proceed to step 406;

Step 406, the maintenance terminal responds with a dynamic subscription success message of the maintenance terminal.

What Fig. 5 shows is the flow chart of the present invention when the cluster group with duplicate group ID deletes MS, and its specific steps are:

Step 500, the maintenance terminal sends a request to the trunking service server to delete the MS in the trunking group, the request carries the MS user number to be deleted, the MS number type, the group call area of the trunking group, the group ID of the trunking group and The group call type of the group;

Step 501: After receiving the message that the MS has signed up for the cluster group, the trunking service server judges whether there are duplicate subscription records in all group ID duplicate subscription count flow table records stored in advance by the MS, and if so, execute step 502; otherwise, Execute step 505;

The basis for judging is to repeat the MS user number and number type in each record of the group ID subscription counting flow table, as well as the group ID that the MS joins, the group call type, and the MS user number, number type, and MS to join in the request. The group ID and group call type are compared one by one.

Step 502, the cluster service server subtracts 1 from the number of repetitions in the record of the repeated subscription counting flow table of the corresponding group ID stored in advance by the MS, and judges whether the number of repetitions is equal to 0 after the number of repetitions is reduced by 1, and if so, executes step 503; otherwise, executes step 504;

Step 503, the cluster service server deletes the record, and proceeds to step 504;

Step 504, the cluster service server sends a response of successfully executing the request to the maintenance terminal;

Step 505, perform processing according to the dynamic unsubscription process in the prior art.

Through the method provided by the present invention, it can be realized that when different cluster groups reuse the same group ID, the existing technology can still be used to realize the process of MS joining the subscribed cluster group with duplicate group ID, and can distinguish Different cluster groups for the group ID. The implementation method is as follows: MS initiates a request to join the trunking group to the trunking service server, and the request carries the group ID to join the trunking group and the area to which the MS currently belongs; the trunking service server first determines that the MS wants to To join multiple cluster groups with the group ID, query the records about the MS in the pre-stored group ID repeated subscription count flow table to determine the multiple cluster groups with the group ID, and then carry the MS current The area to which the MS belongs is compared with the group call areas of multiple trunk groups with the group ID, and it is determined that the trunk group whose group call area includes the area to which the MS currently belongs is the trunk group to be joined by the MS, and the MS is allowed to join.

Since the present invention realizes the use of repeated group IDs to identify different cluster groups, it saves the number resources of cluster services; because the group ID repeated subscription counting flow table provided by the present invention can shield MSs from repeatedly requesting subscriptions with the same group ID on the air interface For different cluster groups, it only needs to sign up to different cluster groups with the same group ID once, and save the subscription information in the group ID repeated subscription counting flow table, which saves the air interface resources of the cluster communication system.

The above descriptions are only preferred embodiments of the present invention, and are not intended to limit the present invention. Any modifications, equivalent replacements and improvements made within the spirit and principles of the present invention should be included in the scope of the present invention. within the scope of protection.

Claims (9)

1. A method for identifying different cluster groups, characterized in that the mobile service switching center pre-stores the cluster group information under its jurisdiction, and the method also includes: A. The maintenance terminal initiates a dynamic reorganization trunk group request to the trunking service server, and the request carries the group identifier, group call type and group call area of the dynamic reorganization trunk group; B. The trunking service server forwards the request to one or more mobile service switching centers that govern the group call area carried by the request, and the mobile service switching center judges whether the group identifier and the group call type in the stored trunk group information are consistent with The group identifier carried in the request is the same as the group call type, if yes, go to step C; otherwise, go to step D; C. The mobile service center judges whether the group call area carried by the request overlaps with the stored trunk group call area with the group identifier and group call type carried by the request. If yes, the mobile service switching center sends a message to the trunk service server The request fails to respond, and the cluster service server does not execute the request; otherwise, execute step D; D. The mobile service switching center sends a successful response to the request to the cluster service server, and the cluster service server executes the request and stores the requested dynamic reconfiguration cluster group information. 2. The method according to claim 1, wherein the request for dynamic reorganization of the cluster group in step A is to create a cluster group or modify an already created cluster group. 3. The method according to claim 1, characterized in that in step B, one or more mobile service switching centers governing the group call area carried by the request are: an anchor mobile service switching center and one or more The trunking mobile services switching center; In step D, after the successful response of sending the request, the method is further: the trunking service server judges whether the requests sent by all anchor mobile service switching centers and relay mobile service switching centers that govern the group call area carried by the request are successfully received In response, if yes, the cluster service server executes the request, and stores the requested dynamically reorganized cluster group information; otherwise, the cluster service server does not execute the request. 4. The method according to claim 1, characterized in that when the cluster communication system is superimposed with a virtual private network, Before step B, the method further includes: the trunking service server determines the virtual private network that governs the group call area carried by the request, and checks whether the group identifier and group call type of the existing trunking group in the virtual private network stored by itself are consistent with The group identifier and group call type carried in the request are repeated, if yes, the trunking service server does not execute the request; otherwise, step B is executed. 5. The method according to claim 1, characterized in that the process of storing the requested dynamic reorganization cluster group information in step D is as follows: The dynamic reconfiguration group information is stored in the database of the cluster service server, and the dynamic reconfiguration cluster information is stored in the mobile switching service center to which it belongs. 6. The method according to claim 1, wherein when the maintenance terminal wants to add user terminals in the dynamic reorganization cluster group, the method further comprises: Set the cluster group list that the user terminal has joined in the database of the cluster service server, and set the group identification repeated subscription counting process table, each record in the table is used to store the user terminal's repeated subscription to different clusters with the same group identification Group signing information; E. The maintenance terminal initiates a request to the trunking service server to add a user terminal in the dynamically reorganized trunking group, the request carrying the user terminal number, number type, and the group identifier and group call type that the user terminal wants to join the trunking group; F. The trunking service server judges whether the group identifier and group call type carried in the request are the same as the group identifier and group call type of the trunking group in the trunking group list that the user terminal has joined, if yes, execute step G , otherwise, the cluster service server will process it according to the normal dynamic contract process; G. The cluster service server judges whether there is a record that the user terminal has signed a contract in the process table for setting the group identifier repeated subscription count, and if so, adds 1 to the number of repetitions of the record; otherwise, creates a group identifier repeated subscription count for the user Process table records, and set the number of repetitions of this record to 1. 7. The method according to claim 1, wherein when the maintenance terminal wants to delete the user terminal in the dynamic reorganization cluster group, the method further comprises: In the database of the cluster service server, a group identifier repeated subscription counting flow table is set, and each record in the table is used to store the subscription information of the user terminal repeatedly signing different cluster groups with the same group identifier; E1. The maintenance terminal initiates a request to the trunking service server to delete the user terminal in the dynamically reorganized trunking group, the request carrying the user terminal number, number type, and the group identifier and group call type of the trunking group to be deleted by the user terminal; F1. The cluster service server judges whether there is a record of the user terminal’s contract in the process table for setting group identifier repeated signing counts. If there is, subtract 1 from the number of repetitions of this record, and go to step G1; otherwise, the cluster service server proceeds as normal Dynamic contract process for processing; G1. The cluster service server judges whether the number of repetitions of the record is 0 after the number of repetitions is reduced by 1. If yes, delete the record and reply that the maintenance terminal executes the request successfully; otherwise, directly responds that the maintenance terminal executes the request successfully. 8. The method according to claim 6 or 7, characterized in that, the subscription information stored in each record in the table includes: user terminal user number, number type, group identifier that the user terminal joins, group call type and the number of repetitions. 9. The method according to claim 8, wherein the process for the trunking service server to determine whether there is a record of the user terminal's subscription in the flow table for setting the repeated subscription counting of the group identifier is as follows: judging whether the group identifier repeated subscription counting flow table The user number and number type of the user terminal in each record, as well as the group identifier and group call type that the user terminal joins, are compared with the user terminal user number, number type, and group identifier and group call type that the user terminal joins in the request. Compare them one by one.

Images