Method for discriminating requests in a grouping of groups in a 3GPP MCS network

Abstract

One aspect of the invention relates to a method (1) for discriminating, by a first receiving client entity (C2), requests in a communication network according to the 3GPP MCS "3rd Generation Partnership Program Mission-Critical System" standard, wherein the requests received by the receiving client entity (C2) comprise a first mission-critical service request from the non-controller server (NC2) of the second communication group (G2) and a second mission-critical service request from the non-controller server (NC3) of the third communication group (G3), each received request comprising at least one group membership information of the requesting non-controller server. Figure to be published with the abstract: Figure 2

Description

Title of the invention: Method for discriminating requests in a group of groups in a 3GPP MCS network. TECHNICAL FIELD OF THE INVENTION

[0001] The technical field of the invention is that of telecommunications.

[0002] The present invention relates to a method of discriminating requests in a grouping of groups in a network according to the 3GPP MCS standard and in particular of a plurality of requests to the same user device belonging to several groups included in the same grouping of groups. TECHNOLOGICAL BACKGROUND OF THE INVENTION

[0003] PMR radio communication standards (according to the Anglo-Saxon designation "Professional Mobile Radio") TETRAPOL®, TETRA®, or P25® enable the implementation of secure professional networks. These narrowband networks are national or local networks: they are implemented, for example, within an organization such as a company, or within a country, for example, for communications involving firefighters, law enforcement, the military, etc.

[0004] These networks are evolving towards supporting broadband exchanges. The 3GPP standard governing "GSM" type mobile networks, known in English as "Global System for Mobile Communications," particularly in their third, fourth, and fifth generations, respectively called "3G," "4G," and "5G," and subsequent generations, and more specifically in deployments using mission-critical services defined by 3GPP, known as "MCS," allows for these secure broadband exchanges. A 3G, 4G, or 5G network implements 3G / 4G / 5G terminal equipment (called UE, from the English "User Equipment"), a 3G / 4G / 5G radio access network (RAN, from the English "Radio Access Network"), and a core network (3G / 4G / 5G).Broadband MCS service deployments are of course not limited to 3G / 4G / 5G mobile networks but also include deployments in fixed and mobile IP (Internet Protocol) networks, for example WLANs (Wide Local Area Networks).

[0005] The term "communication network according to the 3GPP MCS standard" means a communication network compatible with the 3GPP MCS standard and more particularly with the current version of 3GPP, which is version 17, with previous versions from version 13 and with subsequent versions incorporating all the features of the invention.

[0006] Such a network is, for example, shown in [Fig. 1]. This network comprises several clients C1 and C2, each connected to a participating server, PI and P2 respectively (for "Participating" according to the 3GPP MCS terminology). The participating servers PI and P2 can communicate with other servers in the network. In [Fig. 1], the participating servers PI and P2 each communicate with at least one non-controlling server (for "Non-Controlling" according to the 3GPP MCS terminology). The participating server PI communicates with the non-controlling server NCI, and the participating server P2 communicates with the non-controlling server NC2 and with the non-controlling server NC3. Each non-controlling server, NCI through NC3, communicates with the same controlling server C (for "Controlling" according to the 3GPP MCS terminology). Participating servers PI and P2, controller C and non-controller NCI to NC3 are “MCX servers” type servers as defined in the 3GPP MCS.

[0007] The network shown in [Fig. 1] comprises several communication groups G1 to G3, with groups G1 and G2 each comprising a client C1 and C2, respectively, and a participating server PI and P2, respectively. Each communication group G1 to G3 comprises a non-controller server NCI to NC3, respectively. The client C2 belongs to both communication group G2 and communication group G3. The communication groups G1 to G3 are grouped into a communication group GA. The participating servers PI and P2 are responsible for managing the clients of the communication group to which they belong. The participating server PI and P2 manage clients C1 and C2, respectively. The controller server C manages the communication group GA.The Non-Controller servers NCI to NC3 can be viewed as sub-servers of the communication group aggregation and are responsible for managing one or more of the "constituent" groups G1 to G3 of the GA communication group aggregation.

[0008] When the "participant," "controller," and "non-controller" functions are implemented by independent servers, they are referred to as "participant server," "controller server," and "non-controller server," respectively. When they are all implemented by the same server or distributed across several servers, they are referred to as "participant function," "controller function," and "non-controller function." The terms "function" and "server" may then be used interchangeably in the remainder of this description and depend solely on the chosen implementation. The term "server" will be used primarily, although this does not preclude the same physical device from implementing one or more of the "participant," "controller," and / or "non-controller" functions.

[0009] In the 3GPP MCS standard, the following communication services are defined: • MCPTT, from the English "Mission Critical Push To Talk" (which translates to "Pushing to Talk in Mission Critical" in French), which allows for voice communications, • MCVideo, which allows for video communications, • MCData, which comprises three sub-services: • SDS, from the English "Short Data Service" for "Short Data Service" in French and • FD, short for "File Distribution" in French, • IPCon from the English “IP Connectivity” for “Connectivité IP” in French.

[0010] Hereafter, "MCX server" will refer to a network server configured to implement any 3GPP MCS communication service, i.e. MCPTT, MCData or MCVideo.

[0011] Each client C1 and C2 is a user device, also called a user equipment (UE) or client entity, and is, for example, a smartphone, a tablet, a laptop, or any other device, for example, a 4G / 5G dongle, enabling communication within a network. A user device comprises at least one memory and at least one processor, the memory containing instructions which, when executed by the processor, cause the user equipment to perform the actions assigned to it in the remainder of the description. Preferably, user devices include a display module.Similarly, the various MCX C, PI, P2 and NCI to NC3 servers are devices comprising at least one memory and at least one processor, the memory containing instructions which, when executed by the processor, cause the server to implement the actions assigned to it in the rest of the description. The servers and user devices are interconnected and form at least one network such as the one shown in [Fig. 1], this network implementing wired, wireless, or any combination of these communications.

[0012] Client C2 belongs to communication group G2 and communication group G3. Within group G2 and group G3, it is managed by participating server P2. Thus, when a communication is destined for group G2, participating server P2 informs client C2 of the communication, and when a communication is destined for group G3, participating server P2 informs client C2 of the communication. A problem arises when a client belonging to a group in group GA attempts to communicate within group GA. Such a problem is illustrated in [Fig. 2].

[0013] The problem arises when a request issued by a client in the grouping is destined for the same grouping. In the example in [Fig. 1], the client Cl issues a request to the grouping, for example, a communication request. According to the 3GPP MCS standard, this request is first transmitted to the participating server that manages the client Cl within its communication group Gl, i.e., the participating server PI, and then to its non-controlling server NCI. The non-controlling server NCI then forwards the request to the controlling server C, which is responsible for transmitting it to each other communication group belonging to the communication grouping GA, i.e., to groups G2 and G3.

[0014] Such a request, in the 3GPP MCS standard, is of the "SIP" type, SIP being a Session Initiation Protocol. A SIP request, also called a "SIP REQUEST", can be an invitation of the "SIP INVITE" type, defined by RFC 3261, or a message of the "SIP MESSAGE" type.

[0015] The SIP REQUEST 1 is a request to establish a session in the GA grouping. As part of the 3GPP MCS standard, this message includes a field <mcx-request-uri>indicating the recipient group of the communication, i.e. the global regrouping group (“regroup”) GA in the example of [Fig.2].

[0016] The SIP REQUEST 1 request also includes a field <calling-group-id>indicating which communication group within the global group GA the client Cl belongs to. The group Gl of the client Cl within the global group GA is called the "constituent," so called because it is one of the three "constituent" groups of the global group GA.

[0017] Finally, the query includes a field <calling-user-id>including the identifier of the client Cl who initiated the request.

[0018] When this request reaches the controller server C of the global group GA, the controller server C dispatches this request to the non-controller servers of each other group constituting the global group GA, that is, to NC2 and NC3, as shown in [Fig. 2]. The request is therefore duplicated for each group; the controller server C sends a SIP REQUEST 2 to the non-controller server NC2 and a SIP REQUEST 3 to the non-controller server NC3. Each request indicates, in the field <mcx-request-uri>, the recipient group of the communication, i.e., group G2 for SIP REQUEST 2 and group G3 for SIP REQUEST 3, and in the field <calling-group-id>, the communication group to which the controller server C belongs, i.e. the GA group.

[0019] The non-controlling server NC2 receives the SIP REQUEST 2 and the non-controlling server NC3 receives the SIP REQUEST 3. Each non-controlling server will The server then forwards this request to the participating servers in their respective groups. The participating server P2 will therefore receive SIP REQUEST requests 4 and 5, respectively, from the non-controlling server NC2 and the non-controlling server NC3. It will then forward the request to the clients it manages, including client C2, which belongs to groups G2 and G3. Thus, the participating server P2 will forward SIP REQUEST requests 6 and 7 to client C2, as SIP REQUEST 6 and SIP REQUEST 7 are identical. Client C2 therefore has no way of knowing whether each of the SIP REQUEST requests 6 and 7 originates from the non-controlling server NC2 or the non-controlling server NC3.However, the C2 client may have different roles in the different G2 and G3 groups of which it is a member, for example a "dispatcher" role or team leader role, implying different priorities, which may, for example, allow it or not to preempt the right to speak from other users of the group with a lower priority, or even use different functional aliases in the different groups, which may give additional identifying information to other users participating in the grouping.

[0020] The C2 client receiving each request, even if it can know from the grouping structure that it will receive several similar requests, cannot choose under which of the constituent groups it will process the request, and therefore can not possibly choose its role, its priority or its functional alias in the grouping.

[0021] Furthermore, in the protocol, the C2 client is obligated to respond to each received request. Therefore, there is a risk that the C2 client will accept each of the different requests, which can lead to the establishment of multiple identical media sessions, for example voice or video, which could impact the overall performance of the network.

[0022] There is then a need to solve the problems presented above. Summary of the invention

[0023] The invention offers a solution to the problems mentioned above, by allowing a client entity receiving a multitude of identical requests to discriminate between the requests received.

[0024] One aspect of the invention relates to a method for discriminating, by a first recipient client entity, requests in a communication network according to the 3GPP MCS "3rd Generation Partnership Program Mission-Critical System" standard, the communication network comprising at least: • a global communication group encompassing a plurality of communication groups, • at least one issuing client entity affiliated with a first communication group out of the plurality of communication groups, • the recipient client entity, affiliated with at least a second and a third communication group out of the plurality of communication groups, • a controller server responsible for managing the overall communication group, • at least one participating server managing each client entity, • for each communication group within the plurality of communication groups: • at least one non-controller server in the global communication group responsible for managing the communication group,

[0025] the process comprising at least the steps of: • transmission, by the sending entity, via the participating server managing the sending entity and the non-controlling server of the first group, to the controlling server, of a critical mission service request within the global group, • determination, by the controlling server, of the communication groups included in the overall communication group, • transmission of the critical mission service request, by the controller server, to the non-controller server of each communication group determined to be included in the global communication group, • determination, by each non-controlling server, of the client entities receiving the critical mission service request, • transmission of the critical mission service request, by each non-controller server, to each determined recipient client entity, via the participating server managing the determined recipient client entity, • receipt of at least one first critical mission service request from the non-controller server of the second communication group and a second critical mission service request from the non-controller server of the third communication group, by the first recipient client entity, each received request including at least one group membership information of the non-controller server issuing the request, • acceptance, by the first recipient client entity, of a request from among the first and second requests based on the group membership information of the non-controller server issuing the request.

[0026] Thanks to the invention, a client entity receiving identical requests from several communication groups to which it belongs can discriminate between these requests and accept only one, solving the problems of the prior art. Thus, it is possible for a client entity to choose the role it will have in a communication by knowing the communication group under which it receives each request and by choosing the request that suits it, and therefore the communication group from which it will accept the service request in the global communication group.

[0027] In addition to the characteristics mentioned in the preceding paragraph, the method according to one aspect of the invention may have one or more additional characteristics from among the following, considered individually or in all technically possible combinations: • The process includes a step of adding, to the request, the group membership information of the non-controlling server issuing the request, • The step of adding the group membership information of the non-controlling server issuing the request to the request is implemented by the non-controlling server before the step of transmitting the request by the non-controlling server. • The process includes a step of rejecting the unaccepted request from among the first and second requests based on the group membership information of the non-controlling server issuing the request, • Rejection includes sending a rejection request from the first recipient client entity to the non-controlling server that issued the rejected critical mission service request. • The acceptance of the request is based on a configuration of the recipient client entity.

[0028] Another aspect of the invention relates to a communication network according to the 3GPP MCS "3rd Generation Partnership Program Mission-Critical System" standard, the communication network comprising at least: • a global communication group encompassing a plurality of communication groups, • at least one issuing client entity affiliated with a first communication group out of the plurality of communication groups, • at least one recipient client entity, affiliated with at least a second and a third communication group out of the plurality of communication groups, • a controller server responsible for managing the overall communication group, • at least one participating server managing each client entity affiliated with the communication group, • for each communication group within the plurality of communication groups: • at least one non-controller server in the global communication group responsible for managing the communication group,

[0029] the communication network being configured to implement the method according to the invention.

[0030] In one embodiment, the network is a third-generation “3G”, fourth-generation “4G” or fifth-generation “5G” network, in which the first user device is a user equipment “UE”, the first network comprising at least one core network and at least one radio access network “RAN”.

[0031] Another aspect of the invention relates to a computer program product comprising instructions which lead the network according to the invention to execute the steps of the method according to the invention.

[0032] Another aspect of the invention relates to a computer-readable medium on which the computer program according to the invention is recorded.

[0033] The invention and its various applications will be better understood by reading the following description and examining the accompanying figures. BRIEF DESCRIPTION OF THE FIGURES

[0034] The figures are presented for illustrative purposes only and are in no way limiting of the invention. • Fig. 1 shows a schematic representation of a state-of-the-art communication network in which the problem arises. • Figure 2 shows a schematic representation of a process in the state the art of requesting critical mission service in a global communications group. • Figure 3 shows a schematic representation of a process according to the invention. • Figure 4 shows a schematic representation of a modified process according to the invention of critical mission service request in a global communication group. DETAILED DESCRIPTION

[0035] The figures are presented for illustrative purposes only and are in no way limiting of the invention.

[0036] Unless otherwise specified, the same element appearing on different figures presents a unique reference.

[0037] Figure 3 shows a schematic representation of a query discrimination method according to the invention.

[0038] The method 1 according to the invention is implemented by a communication network according to the 3GPP MCS standard. To illustrate the implementation of the method according The invention, the communication network according to the 3GPP MCS standard of [Fig. 1], already presented in the prior art of this application, will be used. Thus, method 1 according to the invention can be implemented by the network of [Fig. 1]. In such a case, the client entity issuing a mission-critical service request is client entity, or client, C1. The receiving client entity is client entity, or client, C2.

[0039] In method 1 according to the invention, discrimination is possible by the recipient client entity C2 thanks to information added to each request to the recipient client entity C2.

[0040] The method 1 according to the invention comprises a first step 11 of transmission, by the sending client entity Cl, via the participating server PI of the first group G1 and via the non-controlling server NCI, to the controlling server C, of ​​a mission-critical service request within the global group GA. Such a request is identical to the prior art SIP REQUEST 1.

[0041] In a step 12 of the process 1 according to the invention, the controller server C determines the groups constituting the global group GA, i.e. the groups G1 to G3. For this, the controller server C has knowledge of the groups constituting the global group GA, for example because it stores a grouping configuration file.

[0042] The controller server C then forwards, in a step 13, each SIP REQUEST 2 and SIP REQUEST 3 request respectively to the communication groups G2 and G3. "Forwarding to a communication group" means forwarding to the non-controller server of the communication group included in the global group.

[0043] Each non-controller server belonging to a group determined in step 12 then receives a request from the controller server C. Thus, the non-controller server NC2 receives a SIP REQUEST 2 request and the non-controller server NC3 receives a SIP REQUEST 3 request.

[0044] In step 14, each non-controller server determines the client entities that are the recipients of the critical mission service request. Since a non-controller server is tasked with managing the group, it is aware of the group's client entities, for example, because it stores a file listing the client entities and their roles within the group, and therefore can determine whether these client entities are the recipients of the critical mission service request.

[0045] The constituent group information added to the request is added to the request by each non-controlling server at step 15. Indeed, it is aware of the constituent group it manages, through the field <mcx-request-uri>received from C, and will forward the request in step 16. In step 15, the non-controlling server adds the constituent group information to which it belongs to the request. Thus, the constituent group information G2 is added to the SIP REQUEST 4 request by the server The non-controlling NC2 server, which belongs to group G2, is preferably included in an "associated-group-id" header field. Similarly, the group information constituting G3 is added to the SIP REQUEST 5 request by the non-controlling NC3 server, which belongs to group G3.

[0046] The process is also represented as a data exchange in [Fig. 4]. SIP REQUESTS 41, 51, 61 and 71 in [Fig. 4] all include the group membership information of the non-controlling server issuing the request in the header field. <associated-group-id>The non-controller server that sends the request is the non-controller server that will forward the request received from the controller server C to the participating server managing the destination client C2 in step 16. The group membership of the non-controller server is the group it manages. For example, for the non-controller server NC2, the group membership information of the non-controller server that sends the request indicates group G2.

[0047] In an optional variant in which at least one non-controller server manages several communication groups, the non-controller server managing several communication groups performs a request filtering step (Fl). Indeed, a non-controller server managing several communication groups will receive several identical requests destined for the communication groups it manages. To perform this filtering (Fl), the non-controller server understands or retrieves a configuration file or configuration data, indicating at least one filtering rule. This filtering rule may, for example, depend on parameters of the different communication groups managed by the non-controller server, and / or depend on the user profile of the destination entity (C2), in order, for example, to make the filtering dependent on a future role of the destination entity (C2) within the service advertised by the requests.For example, filtering can allow the selection of a request corresponding to a communication group in which the receiving client entity has a more important role than in another communication group among the communication groups managed by the non-controlling server. Thus, the non-controlling server managing multiple communication groups will only forward one request for one communication group among those it manages.

[0048] In step 16, the request is transmitted by each non-controlling server NC2 and NC3 to the participating servers managing the client entities determined in step 14. At this transmission step 16, each request already includes the constituent group information under which the receiving client entity receives the request, that is, the constituent group information to which the non-controlling server sending the request in step 16 belongs. Each participating server receiving the request transmits it to each client entity it manages. In an optional variant Compatible with the previous filtering variant, the participating server receiving the request performs an F2 filter on the requests it receives, retaining only one. To perform this F2 filter, the participating server understands or retrieves a configuration file or configuration data specifying at least one filtering rule. This filtering rule can specify that only the first request for a given service should be forwarded to the receiving client entity C2. Alternatively, the filtering rule can depend on the added communication group membership information and be implemented on all requests received for the same service, for example, within a predefined time interval.This filtering rule can then, for example, depend on parameters of the different communication groups, and / or depend on the user profile of the recipient entity C2, in order, for instance, to make the filtering dependent on a future role of the recipient entity C2 within the service advertised by the requests. For example, the filtering can allow the selection of a request corresponding to a communication group in which the sending client entity has a more important role than in another communication group among the communication groups included in the requests received for the same service. Thus, the participating server P2 will only forward one request for that communication group among the requests received for the same service.The participating server can then reject the filtered requests by sending a rejection message to the non-controlling server that sent the request. The rejection reason is the same as the reason the receiving client entity C2 would use, in order to avoid the risk of canceling the communication. In this variant, where the participating server performs filtering F2, the receiving client entity C2 does not perform any filtering.

[0049] The constituent group information added to the request is copied by the participating server P2 into the request that it then transmits to the receiving client entity C2. Thus, the constituent group information G2 is added to SIP REQUEST 61 by the participating server P2, preferably in an "associated-group-id" header field. Similarly, the constituent group information G3 is added to SIP REQUEST 71 by the participating server P2, preferably in an "associated-group-id" header field.

[0050] Each recipient client entity determined in step 14 therefore receives at least one critical mission service request in step 17. At least one recipient client entity, for example recipient client entity C2, receives two critical mission service requests, for example a first critical mission service request SIP REQUEST 61 from the participating server P2 originating from the non-controlling server NC2 of the second communication group G2 and a second critical mission service request SIP REQUEST 71 from the participating server P2 originating from the non-controlling server NC3 of the third communication group G3. Each request Received SIP REQUEST 61 and SIP REQUEST 71 includes the group membership information of the non-controller server issuing the request, i.e., group G2 to which the non-controller server NC2 belongs for SIP REQUEST 6 and group G3 for the non-controller server NC3 for SIP REQUEST 7.

[0051] When client entity C2 receives a first request, recipient client entity C2 can be configured to begin a waiting period for other identical requests containing the constituent group information of the non-controller server that issued the request. Such a waiting period is, for example, 10 seconds. If recipient client entity C2 receives another request within this waiting period, recipient client entity C2 must, at the end of the waiting period, choose which of the identical requests received during the waiting period to accept and which to reject.Alternatively, after receiving the first request, the receiving client entity C2 can determine, based on a GA grouping configuration file it stores and the group membership information of the requesting non-controller server, which other requests it will receive because it knows which groups it belongs to and which groups are included in the GA grouping. The receiving client entity C2 can then choose which requests to accept or reject the first request and each subsequent request upon receipt. In the variant where the participating server P2 performs filtering F2, the receiving client entity C2 does not perform the filtering described here.

[0052] The invention therefore further comprises at least one step 18 of acceptance, by the receiving client entity C2, of a request from among the requests received, based on the group membership information of the non-controlling server that issued the request. To this end, the receiving client entity C2 is configured to make a choice automatically, for example, based on a client entity configuration, or to make a choice manually, for example, by presenting a user, via an alert displayed on a screen of the receiving client entity C2, with the received requests so that the user can choose which request to accept. The choice can be made automatically based on at least one role of the receiving client entity C2 in each group identified by the group membership information of the non-controlling server that issued the request for each received request, or, for example, based on a preferred group among these identified groups.In the variant where the participating server P2 performs the filtering F2, the receiving client entity C2 does not then perform the request choice described here.

[0053] The process 1 includes an optional step 19 of rejecting requests not accepted in step 18, in order to inform the non-controlling server via the participating server The server forwards the rejected request to the receiving client entity C2, indicating that the request is rejected. The request rejection information includes a reason for rejection, for example, "request accepted on behalf of another constituent group." This reason prevents the non-controlling server from reporting to the controlling server C that the receiving client entity C2 rejected the request, and from the controlling server C canceling the call when the mission-critical service is a call. Indeed, in a call with mandatory participation, if one of the participants rejects the request, the call may be canceled. By informing the non-controlling server of the rejection for a new reason—that is, by informing it that the request is rejected but that another request has been accepted for the same service—the service will not be canceled, because the non-controlling server can consider that the user's participation in the transaction is still assured.In the variant where the participating server P2 performs the filtering F2, the receiving client entity C2 does not then perform the request rejection described here.

[0054] Thus, the method according to the invention prevents a client entity from accepting multiple identical requests and therefore from creating multiple identical parallel communications. When the service is an MCData service, the invention can be used to send only one acknowledgment after the recipient client entity receives multiple identical "delivery" or "read" messages.

Claims

1. Claims Method (1) of discrimination, by a first recipient client entity (C2), of requests in a communication network according to the 3GPP MCS “3rd Generation Partnership Program Mission-Critical System” standard, the communication network comprising at least: - a global communication group (GA) bringing together a plurality of communication groups (Gl, G2, G3), - at least one transmitting client entity (Cl) affiliated with a first communication group (Gl) of the plurality of communication groups (Gl, G2, G3), - the recipient client entity (C2), affiliated at least to a second (G2) and a third (G3) communication groups of the plurality of communication groups (G1, G2, G3), - a controller server (C) in charge of managing the global communication group (GA), - at least one participating server (PI, P2) managing each client entity, - for each communication group of the plurality of communication groups (G1, G2, G3): • at least one non-controller server (NCI, NC2, NC3) of the global communication group (GA) in charge of managing the communication group (Gl, G2, G3), the method comprising at least the steps of: - transmission (11), by the transmitting entity (Cl), via the participating server (PI) managing the transmitting entity and the non-controlling server (NCI) of the first group (Gl), to the controller server (C), of a request for critical mission service within the global group (GA), - determination (12), by the controller server (C), of the communication groups included in the global communication group (GA), - transmission (13) of the critical mission service request, by the controller server (C), to the non-

2.

3.

4. controller of each communication group determined as included in the global communication group (GA), - determination (14), by each non-controlling server, of the client entities receiving the mission-critical service request, - transmission (16) of the mission critical service request, by each non-controlling server, to each determined recipient client entity (14), via the participating server managing the determined recipient client entity, - reception (17) of at least a first mission critical service request originating from the non-controlling server of the second communication group and a second mission critical service request originating from the non-controlling server of the third communication group, by the first recipient client entity (C2), each received request comprising at least one piece of information on the group belonging to the non-controlling server issuing the request, - acceptance (18), by the first recipient client entity (C2), of a request from among the first and second requests based on the membership group information of the non-controlling server sending the request. Method (1) according to the preceding claim comprising a step of adding (15), to the request, the information on the group belonging to the non-controlling server issuing the request. Method (1) according to the preceding claim in which the step of adding (15) to the request the information of the group belonging to the non-controlling server sending the request is implemented by the non-controlling server before the step of transmitting (15) the request by the non-controlling server. Method (1) according to one of the preceding claims comprising a step of rejecting (19) the unaccepted request among the first and second requests as a function of the group membership information of the non-controlling server sending the request.

5. Method (1) according to the preceding claim in which the rejection comprises sending a rejection request, from the first recipient client entity (C2) to the non-controller server sending the rejected critical mission service request.

6. Method (1) according to one of the preceding claims in which the acceptance of the request is carried out on the basis of a configuration of the recipient client entity (C2).

7. Communication network according to the 3GPP MCS “3rd Generation Partnership Program Mission-Critical System” standard, the communication network comprising at least: - a global communication group (GA) grouping together a plurality of communication groups (Gl, G2, G3), - at least one sending client entity (Cl) affiliated with a first communication group (Gl) of the plurality of communication groups (Gl, G2, G3), - at least one receiving client entity (C2), affiliated at least with a second (G2) and a third (G3) communication group of the plurality of communication groups (Gl, G2, G3), - a controller server (C) in charge of managing the global communication group (GA), - at least one participating server (PI, P2) managing each client entity affiliated with the communication group (Gl, G2, G3), - for each communication group of the plurality of communication groups (Gl, G2,G3): • at least one non-controller server (NCI, NC2, NC3) of the global communication group (GA) in charge of managing the communication group (G1, G2, G3), the communication network being configured to implement the method (1) according to any one of the preceding claims.,

8. Network according to the preceding claim, characterized in that it is a third generation “3G”, fourth generation “4G” or fifth generation “5G” network, in which the first user device is a user equipment “UE”, the first 17 network comprising at least one core network and at least one radio access network “RAN”.

9. A computer program product comprising instructions which cause the network according to claim 8 to execute the steps of the method according to one of claims 1 to 6.

10. A computer-readable medium on which the computer program according to claim 9 is recorded.

Images