CN117981375A

CN117981375A - Method and system for controlling ad hoc group communications using security context for mission-critical services

Info

Publication number: CN117981375A
Application number: CN202280063571.2A
Authority: CN
Inventors: A·拉马莫尔蒂; R·拉金德兰; K·G·卡帕莱; B·J·帕坦
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2021-09-21
Filing date: 2022-09-21
Publication date: 2024-05-03

Abstract

The present disclosure relates to a 5th generation (5G) and/or 6th generation (6G) communication system for supporting higher data transmission rates. Embodiments herein disclose a method for controlling self-organizing group communication using a security context for a mission-critical (MCX) service. The method includes sending a self-organizing group communication request message to an MC service server by a first MC service client device 100 to establish a self-organizing group communication with a second MC service client device. The MC service server determines whether the self-organizing group communication is supported and successfully authorized based on the received self-organizing group communication request. In addition, the method includes receiving a self-organizing group communication request return message from the MC service server when the self-organizing group communication is supported and successfully authorized. In addition, the method includes generating a security context for a second MC service client device for self-organizing group communication, and using the generated security context to establish a self-organizing group communication with the second MC service client device.

Description

Method and system for controlling ad hoc group communication using security context for mission critical services

Technical Field

The present disclosure relates to Mission Critical services, and more particularly, to a method and system for controlling ad-hoc group communication ad-hoc group communications (ad-hoc group communication) using a security context for a Mission Critical (MCX) service.

Background

The fifth generation (5G) mobile communication technology defines a wide frequency band that enables high transmission rates and new services, and can be implemented not only in a "sub-6 GHz" frequency band such as 3.5GHz, but also in a "higher than 6GHz" frequency band (including 28GHz and 39 GHz) called millimeter waves. In addition, it has been considered to implement a 6G mobile communication technology (referred to as transcendental 5G system) in a terahertz frequency band (e.g., 95GHz to 3THz frequency band) to achieve a transmission rate fifty times faster than the 5G mobile communication technology and an ultra-low latency of one tenth of the 5G mobile communication technology.

At the beginning of the development of 5G Mobile communication technology, in order to support services and meet performance requirements related to enhanced Mobile BroadBand (eMBB), ultra-reliable low latency communication (Ultra Reliable Low Latency Communication, URLLC) and large-scale machine type communication (mMTC), standardization has been conducted with respect to the following various technologies: beamforming and massive multiple-input multiple-output (MIMO) to mitigate radio path loss in millimeter waves and increase radio wave transmission distance, a support parameter set (e.g., operating multiple subcarrier spacing) for dynamic operation to efficiently utilize millimeter wave resources and slot formats, initial access techniques for supporting multi-beam transmission and broadband, definition and operation of BandWidth parts (BWP), new channel coding methods such as Low density parity check (Low DENSITY PARITY CHECK, LDPC) codes for mass data transmission and polarization codes for highly reliable transmission of control information, L2 preprocessing, and network slicing for providing a dedicated network dedicated to a specific service.

Currently, in view of services to be supported by the 5G mobile communication technology, discussions are being made about improvement and performance enhancement of the initial 5G mobile communication technology, and there have been physical layer standardization with respect to various technologies such as: vehicle-to-everything (V2X) for assisting driving determination of an autonomous Vehicle and for enhancing user convenience based on information sent by the Vehicle about the position and status of the Vehicle, a new radio unlicensed (New Radio Unlicensed, NR-U) aimed at system operation complying with various regulatory-related requirements in an unlicensed band, NR UE saving power, a non-terrestrial network (NTN) for providing coverage and located UE-satellite direct communication in an area where communication with the terrestrial network is unavailable.

Further, standardization in air interface architecture/protocols has been done with respect to various technologies such as: industrial internet of things (IIoT) for supporting new services through interworking and convergence with other industries, integrated Access and Backhaul (IAB) for providing nodes for network service area extension by supporting wireless backhaul links and access links in an integrated manner, mobility enhancements including conditional handover and dual active protocol stack (Dual Active Protocol Stack, DAPS) handover, and two-step random access (two-step RACH for NR) for simplifying random access procedures. Standardization in system architecture/services is also underway with respect to various technologies: a 5G baseline architecture (e.g., service-based architecture or service-based interface) for combining network function virtualization (Network Functions Virtualization, NFV) and Software Defined Network (SDN) technologies and Mobile Edge Computing (MEC) for receiving services based on UE location.

As 5G mobile communication systems are commercialized, connection devices, which have been exponentially increased, will be connected to communication networks. It is expected, therefore, that enhanced functionality and performance of 5G mobile communication systems and integrated operation of connected devices will be necessary. For this reason, new studies related to the following technologies are planned: augmented Reality (eXtended Reality, XR) for efficiently supporting augmented Reality (Augmented Reality, AR), virtual Reality (VR), mixed Reality (MR), etc., 5G performance enhancement and complexity reduction by utilizing artificial intelligence (ARTIFICIAL INTELLIGENCE, AI) and machine learning (MACHINE LEARNING, ML), AI service support, metaspace service support, and drone communication.

Further, such development of the 5G mobile communication system will provide a basis for developing not only new waveforms for providing coverage in the terahertz band of the 6G mobile communication technology, multi-antenna transmission technologies such as Full dimension MIMO (FD-MIMO), array antennas and massive antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-Dimensional spatial multiplexing technology using orbital angular momentum (Orbital Angular Momentum, OAM) and reconfigurable intelligent surfaces (Reconfigurable Intelligent Surface, RIS), but also development of Full duplex technology for improving frequency efficiency of the 6G mobile communication technology and improving system network, AI-based communication technology for realizing system optimization by utilizing satellites and Artificial Intelligence (AI) and internalizing end-to-end AI support functions from a design stage, and next generation distributed computing technology for realizing services exceeding complexity level of UE operation capability limit by utilizing ultra-high performance communication and computing resources.

Disclosure of Invention

The present disclosure addresses at least the above-described problems and/or disadvantages and provides at least the advantages described below.

Accordingly, embodiments herein disclose a method for controlling ad hoc group communications using a security context for a Mission Critical (MCX) service. The method includes sending, by a first MC service client device, an ad hoc group communication request message to an MC service server to establish an ad hoc group communication with a second MC service client device. The MC service server determines whether ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request. Further, the method includes receiving, by the first MC service client device, an ad hoc group communication request return message from the MC service server when the ad hoc group communication is supported and successfully authorized. Further, the method includes generating, by the first MC service client device, a security context for the second MC service client device for ad hoc group communication. Further, the method includes establishing, by the first MC service client device, ad hoc group communication with the second MC service client device using the generated security context.

In an embodiment, the ad hoc group communication request message includes: a list of invited second MC service client devices, encryption support information, a list of block-sharing participants (blocks SHARING PARTICIPANT) associated with the second MC service client devices, an MC service group Identification (ID), MC service client media parameters, an indication of an implicit floor request (implicit floor request), a functional alias (functional alias), location information, an emergency indicator (EMERGENCY INDICATOR), and an impending danger indicator (IMMINENT PERIL indicator).

In an embodiment, the ad hoc group communication request return message includes an MC service group Identification (ID) and authorization result information (e.g., success, failure, etc.).

In an embodiment, the security context includes an Ad-hoc group communication key (Ad-hoc Group Communication Key, AGCK) and an Ad-hoc group communication key identifier (Ad-hoc Group Communication KEY IDENTIFIER, AGCK-ID).

In an embodiment, wherein establishing, by the first MC service client device, ad hoc communication with the second MC service client device using the generated security context comprises transmitting, by the first MC service client device to the MC service server, the generated security context of the second MC service client device, wherein the generated security context is transmitted by the ad hoc communication security material request. Further, the method includes receiving, by the first MC service client device, an ad hoc group communication response from the MC service server to establish an ad hoc group communication with the second MC service client device using the generated security context.

In an embodiment, wherein transmitting, by the first MC service client device, the generated security context of the second MC service client device to the MC service server comprises encrypting, by the first MC service client device, the generated security context to a unique identifier (Unique identifier, UID) associated with the second MC service client device; encapsulating, by the first MC service client device, the encrypted security context for the second MC service client device; and sending, by the first MC service client device, the security context of the encapsulated second MC service client device to the MC service server.

In an embodiment, the method includes determining, by the MC service server, whether ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request. Further, the method includes accepting the ad hoc group communication request and verifying the list of invited second MC service client devices based on the configured restrictions in response to determining that ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request. Further, the method includes rejecting the ad hoc communication request in response to determining that the ad hoc communication is not supported by the MC service server and is not successfully authorized based on the received ad hoc communication request.

In an embodiment, a method includes sending, by an MC service server, an ad hoc group communication request message to a second MC service client device along with a generated security context to notify about the ad hoc group communication, wherein the MC service server removes a list of block sharing participants associated with the second MC service client device and a list of MC service group Identifications (IDs) of the second MC service client device that need to be validated. Further, the method includes receiving, by the MC service server, an ad hoc group communication response from the second MC service client device when the second MC service client device accepts the ad hoc group communication request message, wherein the ad hoc group communication response includes a functional alias of the responding second MC service client device. Further, the method includes determining, by the MC service server, whether the received ad hoc group communication response is received within a configured time. Further, the method includes discarding the ad hoc group communication responsive to determining that the received ad hoc group communication response was not received within a configured time. Further, the method includes, in response to determining that the received ad hoc communication response is received within the configured time, transmitting the received ad hoc communication response to the first MC service client device to establish the ad hoc communication with the second MC service client device using the generated security context.

The ad hoc group communication includes one or more preconditions, the MC service server authorizing the first MC service client device and the authorized first MC service client device inviting the second MC service client device to establish the ad hoc group communication, the second MC service client device being invited for ad hoc group communication within the limitations of the non-preconfigured method, the ad hoc group communication supporting end-to-end encryption, and the authorized first MC service client device having a security context for the second MC service client device for the ad hoc group communication.

Accordingly, embodiments herein disclose a method for controlling ad-hoc (ad-hoc) group communication using a security context for an MCX service. The method includes detecting, by the MC service server, an ongoing ad hoc group communication between a first MC service client device and a second MC service client device. Further, the method includes receiving, by the MC service server, a modify ad hoc group call participant request message from the first MC service client device, wherein the modify ad hoc group call participant request message includes modification information (e.g., add, remove, rejoin, etc.). Further, the method includes determining, by the MC service server, whether the first MC service client device is authorized to modify the participant list of the detected ongoing ad hoc group communication (or whether the first MC service client device or any other MC service client device participating in the ad hoc group communication is authorized to modify the participant list may be an entry in the corresponding user profile configuration data of the MC service client). Further, the method includes modifying, by the MC service server, the participant list by performing an action based on the received modification information. Further, the method includes notifying, by the MC service server, the first MC service client device and/or the second MC service client device of the modified participant list of the second MC service client device.

In an embodiment, the modification information indicates that the second MC service client device is removed from the detected ongoing ad hoc group communication and/or that a new MC service client device is added to the detected ongoing ad hoc group communication.

In an embodiment, wherein modifying, by the MC service server, the participant list based on the received modification information includes sending, by the MC service server, an ad hoc group communication leave request to the second MC service client device based on the modification information to remove the second MC service client device from the detected ongoing ad hoc group communication. Further, the method includes receiving, by the MC service server, an ad hoc group call departure response from the modified second MC service client device. Further, the method includes removing, by the MC service server, the modified second MC service client device from the detected ongoing ad hoc communication upon receipt of the ad hoc group call departure response.

In an embodiment, wherein modifying, by the MC service server, the participant list based on the received modification information includes sending, by the MC service server, an ad hoc group call communication request to the new MC service client device based on the modification information to add the new MC service client device to the detected ongoing ad hoc group communication, wherein the ad hoc group call communication request includes a security context of the new MC service client device, an ad hoc group identification of the detected ongoing ad hoc group communication, and a session identification. Further, the method includes receiving, by the MC service server, an ad hoc group communication response from the new MC service client device. Further, the method includes adding, by the MC service server, a new MC service client device to the detected ongoing ad hoc group communication.

In an embodiment, wherein the actions include rejoining, by the MC service server, the first MC service client device into the detected ongoing ad hoc group communication; re-joining, by the MC service server, the second MC service client device to the detected ongoing ad hoc group communication; and releasing the detected ongoing ad hoc group communication by the MC service server.

Accordingly, embodiments herein provide a first MC service client device for controlling ad hoc group communications using a security context for an MCX service. The first MC service client device includes an ad hoc group controller coupled with a processor and a memory. The ad hoc group controller sends an ad hoc group communication request message to the MC service server to establish an ad hoc group communication with the second MC service client device, wherein the MC service server determines whether the ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request. Further, when the ad hoc group communication is supported and successfully authorized, the ad hoc group controller receives an ad hoc group communication request return message from the MC service server. In addition, the ad hoc group controller generates a security context for the second MC service client device for ad hoc group communication. In addition, the ad hoc group controller uses the generated security context to establish ad hoc group communication with the second MC service client device.

Accordingly, embodiments herein provide an MC service server for controlling ad hoc group communications using a security context for an MCX service. The MC service server includes an ad hoc group controller coupled to the processor and the memory. An ad hoc group controller receives an ad hoc group communication request message from a first MC service client device to establish an ad hoc group communication with a second MC service client device. Further, the ad hoc group controller determines whether ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request. Further, in response to determining that ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request, the ad hoc group controller accepts the ad hoc group communication request and verifies the list of invited second MC service client devices based on the configured restrictions. Further, the ad hoc controller denies the ad hoc communication request in response to determining that the ad hoc communication is not supported by the MC service server and is not successfully authorized based on the received ad hoc communication request. In addition, the ad hoc group controller receives a security context for the second MC service client device for ad hoc group communication.

Accordingly, embodiments herein provide an MC service server for controlling ad hoc group communications using a security context for an MCX service. The MC service server includes an ad hoc group controller coupled to the processor and the memory. An ad hoc group controller detects ongoing ad hoc group communications between a first MC service client device and a second MC service client device. Further, the ad hoc group controller receives a modify ad hoc group call participant request message from the first MC service client device, wherein the modify ad hoc group call participant request message includes modification information. In addition, the ad hoc group controller determines whether the first MC service client device is authorized to modify the participant list of the detected ongoing ad hoc group communication. In addition, the ad hoc group controller modifies the participant list by performing an action based on the received modification information. Further, the ad hoc group controller notifies the second MC service client device of the first MC service client device and/or the modified participant list of the second MC service client device.

These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following description, while indicating preferred embodiments and numerous specific details thereof, is given by way of illustration and not of limitation. Many variations and modifications are possible within the scope of the embodiments herein, and the embodiments herein include all such modifications.

Drawings

The present disclosure is illustrated in the accompanying drawings, like reference numerals designate corresponding parts throughout the several views. The embodiments herein may be better understood from the following description with reference to the drawings, in which:

FIG. 1A illustrates a block diagram of a first MC service client device for controlling ad hoc group communications using a security context for a Mission Critical (MCX) service, in accordance with an embodiment of the present disclosure;

fig. 1B illustrates a block diagram of an MC service server for controlling ad hoc group communications using a security context for an MCX service, according to an embodiment of the present disclosure;

Fig. 2 illustrates a sequence diagram for initiating an ad hoc group call setup using non-preconfigured means, according to an embodiment of the present disclosure;

Fig. 3 illustrates a sequence diagram for removing an ad hoc group call participant from an ongoing ad hoc group communication in accordance with an embodiment of the present disclosure;

Fig. 4 illustrates a sequence diagram for initiating an ad hoc group call setup by an authorized user in accordance with an embodiment of the present disclosure;

fig. 5 illustrates a sequence diagram for initiating an ad hoc group call setup by an authorized user in accordance with another embodiment of the present disclosure;

Fig. 6 illustrates a sequence diagram for modifying an ad hoc group call participant from an ongoing ad hoc group communication in accordance with an embodiment of the present disclosure;

Fig. 7 illustrates a sequence diagram for initiating termination of an ongoing ad hoc group communication by a first MC service client device, in accordance with an embodiment of the present disclosure;

FIG. 8 illustrates a sequence diagram in which a first MC service client device leaves an ongoing ad hoc group communication in accordance with an embodiment of the present disclosure;

FIG. 9 illustrates a sequence diagram in which a MC service server requests a first MC service client device to rejoin an ongoing ad hoc group communication after returning from outside network coverage, in accordance with an embodiment of the present disclosure; and

Fig. 10 illustrates a sequence diagram in which a first MC service client device requests the MC service server to rejoin an ongoing ad hoc group communication after returning from outside network coverage, in accordance with an embodiment of the present disclosure.

Fig. 11 illustrates a structure of a UE according to an embodiment of the present disclosure; and

Fig. 12 is a block diagram illustrating an internal structure of a network entity according to an embodiment of the present disclosure.

Detailed Description

Hereinafter, embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. In the present disclosure, embodiments are depicted in the drawings and the related detailed description is set forth, but is not intended to limit the embodiments of the disclosure. Descriptions of well-known functions and constructions are omitted for clarity and conciseness.

The term coupled refers to any direct or indirect communication between two or more elements, whether or not those elements are in physical contact with each other. The terms transmit, receive, and communication encompass both direct and indirect communication. The terms including and comprising are meant to include, but not be limited to. The term or inclusion means and/or. The term controller means any device, system or part thereof that controls at least one operation. A controller may be implemented in hardware or a combination of hardware and software and/or firmware. The functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. When used with a list of items, at least one means that different combinations of one or more of the listed items can be used, and that only one item in the list is required. For example, at least one of A, B and C includes any one of the following combinations: A. b and C; a and B; a and C; b and C; and A and B and C. For example, at least one of A, B or C includes any one of the following combinations: A. b and C; a and B; a and C; b and C; and A and B and C.

Furthermore, the various functions described below may be implemented or supported by one or more computer programs, each of which is formed from computer readable program code and embodied in a computer readable medium. The terms application and program refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof adapted for implementation in a suitable computer readable program code. The phrase computer readable program code includes any type of computer code, including source code, object code, and executable code. The phrase computer readable medium includes any type of medium capable of being accessed by a computer, such as Read Only Memory (ROM), random Access Memory (RAM), a hard disk drive, a Compact Disc (CD), a Digital Video Disc (DVD), or any other type of memory. Non-transitory computer-readable media do not include wired, wireless, optical, or other communication links that transmit transitory electrical or other signals. Non-transitory computer readable media include media in which data can be permanently stored and media in which data can be stored and later overwritten, such as rewritable optical disks or removable memory devices.

The terminology used herein to describe embodiments of the present disclosure is not intended to limit and/or define the scope of the present disclosure. For example, unless defined otherwise, technical or scientific terms used in this disclosure should have the ordinary meaning as understood by one of ordinary skill in the art to which this disclosure pertains.

It should be appreciated that the first, second and similar terms used in this disclosure do not denote any order, quantity or importance, but rather are used to distinguish one element from another. Similar words such as singular form of one, one or the like do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced item unless the context clearly indicates otherwise.

As used herein, any reference to an example or illustration, an embodiment or embodiment means that a particular element, feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment. Phrases appearing in one embodiment or in one example in different places throughout the disclosure are not necessarily referring to the same embodiment.

The various embodiments discussed below for describing the principles of the present disclosure are provided by way of illustration only and should not be construed to limit the scope of the present disclosure in any way. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged wireless communication system. For example, although the following detailed description of embodiments of the present disclosure will be directed to LTE and 5G communication systems, it will be appreciated by those skilled in the art that the gist of the present disclosure may be applied to other communication systems having similar technical contexts and channel formats with slight modifications without departing from the scope of the present disclosure. For example, the communication system may include a global system for mobile communications (Global System for Mobile Communications, GSM) system, a Code Division Multiple Access (CDMA) system, a Wideband Code Division Multiple Access (WCDMA) system, a General Packet Radio Service (GPRS), a Long Term Evolution (LTE) system, an LTE Frequency Division Duplex (FDD) system, an LTE Time Division Duplex (TDD), a UMTS, a Worldwide Interoperability for Microwave Access (WiMAX) communication system, a 5G system, or a New Radio (NR), etc. In addition, the technical scheme of the embodiment of the application can be applied to future-oriented communication technologies.

According to existing 3GPP Technical Specifications (TS) 23.280 and TS23.379, MCX users perform group calls by merging existing two or more pre-configured groups or by selecting a list of users that should be invited for a group call. This function requires that a new temporary group be created at the group management server or MCX server before the group call is made to the group. The newly created temporary group will remain on the group management server or MCX server until deleted by the MCX user. There is no procedure in the existing 3GPP specifications that allows MCX users To select a list of users and perform MCX operations (e.g., ad hoc group communications, mission-Critical Push-To-Talk (MCPTT) calls, MC video (MCVideo) calls, or MC data (MCData) related operations) without first creating a new temporary group.

In addition, some existing systems use pre-configured group mechanisms to implement end-to-end encryption of MCX operations. However, the preconfigured group mechanism has a disadvantage in that any member of the preconfigured group can eavesdrop on or decrypt the media even though they are not participants in the ad hoc group communication.

It is therefore desirable to address the above-mentioned shortcomings or others, or at least to provide a useful alternative for controlling ad hoc group communications using security contexts for Mission Critical (MCX) services/MCX operations.

It is a primary object of embodiments herein to provide a method for controlling ad hoc group communications using a security context for Mission Critical (MCX) services. Wherein MCX users (e.g., MC clients/call initiators) select a random group of MCX users to initiate ad hoc group communications and communicate with them without using a preconfigured group. With the proposed mechanism, the MCX user does not have to worry about whether other MCX users (e.g., MCX participants) provide preconfigured groups in the UE.

Another object of embodiments herein is to generate a security context for ad hoc group communication by an MCX user (e.g., call initiator) of the communication and that is shared with other MCX users (e.g., participants) of the communication in an encrypted manner. With this mechanism, the MCX user does not have to worry about whether other MCX users provide preconfigured groups in their UEs. Unlike existing preconfigured group mechanisms in which any MCX user of the preconfigured group may eavesdrop or be able to decrypt the media even if not the participants of the ad hoc group communication, the secure material for the ad hoc group communication is only available to the participants of the call.

It is another object of embodiments herein to remove participants from ongoing ad hoc group communications.

It is another object of embodiments herein to provide the required information flow between MC clients and MC servers for supporting ad hoc group communication.

The embodiments herein, as well as various features and advantageous details thereof, are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. Furthermore, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments may be combined with one or more other embodiments to form new embodiments. The term "or" as used herein refers to a non-exclusive or, unless indicated otherwise. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

As is conventional in the art, the embodiments may be described and illustrated in terms of blocks that perform the one or more functions described. These blocks, which may be referred to herein as units or modules, are implemented by analog or digital circuit physics (such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired (hardwired) circuits, etc.), and may optionally be driven by firmware. The circuitry may be embodied, for example, in one or more semiconductor chips, or on a substrate support (substrate support) such as a printed circuit board or the like. The circuitry comprising a block may be implemented by dedicated hardware, or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware for performing some of the functions of the block and a processor for performing other functions of the block. Each block of an embodiment may be physically divided into two or more interacting and discrete blocks without departing from the scope of the invention. Likewise, the blocks of the embodiments may be physically combined into more complex blocks without departing from the scope of the invention.

The drawings are intended to facilitate an easy understanding of the various technical features, and it should be understood that the embodiments presented herein are not limited by the drawings. Accordingly, the disclosure should be interpreted to extend to any modifications, equivalents, and alternatives, other than those specifically listed in the drawings. Although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are generally only used to distinguish one element from another element.

Accordingly, embodiments herein disclose a method for controlling ad-hoc (ad-hoc) group communication using a security context for a Mission Critical (MCX) service. The method includes sending, by a first MC service client device, an ad hoc group communication request message to an MC service server to establish an ad hoc group communication with a second MC service client device. The MC service server determines whether ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request. Further, the method includes receiving, by the first MC service client device, an ad hoc group communication request return message from the MC service server when the ad hoc group communication is supported and successfully authorized. Further, the method includes generating, by the first MC service client device, a security context for a second MC service client device for ad hoc group communication. Further, the method includes establishing, by the first MC service client device, ad hoc group communication with the second MC service client device using the generated security context.

Unlike existing methods and systems, the proposed method uses security context for Mission Critical (MCX) services to control ad hoc group communications. Wherein an MCX user (e.g., an MC client/call initiator/first MC service client device) selects a random set of MCX users (e.g., one or more second MC service client devices/other MCX users/participants) to initiate ad hoc group communications and communicates with them without using a preconfigured set. With the proposed mechanism, the MCX user does not have to worry about whether other MCX users (e.g., MCX participants) provide preconfigured groups in their UEs.

Unlike existing methods and systems, the proposed method allows MCX users (e.g., call originators) of ad hoc group communications to generate security contexts that are used for ad hoc group communications and are cryptographically shared with other MCX users (e.g., participants) of the communications. With this mechanism, the MCX user does not have to worry about whether other MCX users provide preconfigured groups in their UEs. In contrast to existing preconfigured group mechanisms where any MCX user of the preconfigured group may eavesdrop or be able to decrypt the media even if not the participants of the ad hoc group communication, the secure material for the ad hoc group communication is only available to the participants of the call.

Unlike existing methods and systems, the proposed method allows the first MC service client device and/or MC service server to remove participants from ongoing ad hoc group communications.

Unlike existing methods and systems, the proposed method provides the required information flow between the MC client and the MC server for supporting ad hoc group communication.

Referring now to the drawings, and more particularly to fig. 1A-10, wherein like reference numerals designate corresponding features consistently throughout the figures, preferred embodiments are shown.

Fig. 1A illustrates a block diagram of a first MC service client device 100 for controlling ad hoc group communications using a security context for a Mission Critical (MCX) service, in accordance with an embodiment of the present disclosure. Examples of the first MC service client device 100 and the one or more second MC service client devices 300 include, but are not limited to, smartphones, user Equipment (UE), tablet computers, personal digital assistants (Personal DIGITAL ASSISTANCE, PDA), internet of things (IoT) devices, wearable devices, and the like.

In an embodiment, the first MC service client device 100 includes a memory 110, a processor 120, a communicator 130, and an ad hoc group controller 140.

In an embodiment, the memory 110 stores information related to various communication messages (e.g., ad hoc group communication requests) and security contexts. Memory 110 stores instructions to be executed by processor 120. The memory 110 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical hard disks, floppy disks, flash memory, or various forms of electrically programmable memory (EPROM) or Electrically Erasable Programmable (EEPROM) memory. Further, in some examples, memory 110 may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagated signal. However, the term "non-transitory" should not be construed as memory 110 being non-removable. In some examples, memory 110 may be configured to store a greater amount of information than memory. In some examples, a non-transitory storage medium may store data (e.g., in Random Access Memory (RAM) or cache) that may change over time. The memory 110 may be an internal storage unit or it may be an external storage unit of the first MC service client device 100, cloud storage or any other type of external storage.

The processor 120 is in communication with the memory 110, the communicator 130, and the ad hoc controller 140. Processor 120 is configured to execute instructions stored in memory 110 and perform various processes. Processor 120 may include one or more processors, which may be general-purpose processors (such as Central Processing Units (CPUs), application Processors (APs), etc.), purely graphics processing units (such as Graphics Processing Units (GPUs), vision Processing Units (VPUs)), and/or Artificial Intelligence (AI) specific processors (such as Neural Processing Units (NPUs)).

Communicator 130 is configured to communicate internally between internal hardware components and with external devices (e.g., eNodeB, gNodeB, servers, etc.) via one or more networks (e.g., radio technologies). Communicator 130 includes electronic circuitry specific to a standard that enables wired or wireless communication.

The ad hoc group controller 140 is implemented by processing circuitry, such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuitry, etc., and may optionally be driven by firmware. The circuitry may be embodied, for example, in one or more semiconductor chips, or on a substrate support such as a printed circuit board or the like.

Additionally, the operations of ad hoc group controller 140 may be performed by processor 120. For example, the first MC service client device 100 may include the processor 120 and the communicator 130 and may not include the ad hoc group controller 140, and the processor 120 may be configured to perform the operation of the ad hoc group controller 140. That is, the ad hoc group controller 140 is replaced by the processor 120.

In an embodiment, the ad hoc group controller 140 sends an ad hoc group communication request message to the MC service server 200 to establish an ad hoc group communication with the second MC service client device 300 (or one or more second MC service client devices (300A, 300B, 300C, etc.)), wherein the MC service server 200 determines whether the ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request. The ad hoc group communication request message includes: the list of invited second MC service client devices 300, encryption support information, a list of block sharing participants associated with the second MC service client devices 300, an MC service group Identification (ID), MC service client media parameters, an indication of an implicit floor request, a functional alias, location information, an emergency indicator, and an impending danger indicator.

When ad hoc group communication is supported and successfully authorized, the ad hoc group controller 140 receives an ad hoc group communication request return message from the MC service server 200. The ad hoc group communication request return message includes an MC service group Identification (ID) and authorization result information (e.g., failure, success, etc.).

The ad hoc group controller 140 generates a security context for the second MC service client device 300 for ad hoc group communication. The security context includes an ad hoc group communication key (AGCK) and an ad hoc group communication key identifier (AGCK-ID). The ad hoc group controller 140 encrypts the generated security context into a Unique Identifier (UID) associated with the second MC service client device 300. The ad hoc group controller 140 encapsulates the encrypted security context for the second MC service client device 300. The ad hoc group controller 140 transmits the security context of the encapsulated second MC service client device 300 to the MC service server 200, wherein the generated security context is transmitted by the ad hoc group communication security material request. The ad hoc controller 140 receives an ad hoc communication response from the MC service server 200 to establish an ad hoc communication with the second MC service client device 300 using the generated security context. The ad hoc group controller 140 uses the generated security context to establish ad hoc group communication with the second MC service client device 300.

While fig. 1A illustrates various hardware components of the first MC service client device 100, it should be understood that other embodiments are not so limited. In other embodiments, the first MC service client device 100 may include a fewer or greater number of components. Moreover, the labels or names of the components are for illustration purposes only and do not limit the scope of the present invention. One or more components may be combined to perform the same or substantially similar functions to control ad hoc group communications using security context for MCX services (e.g., calls).

Fig. 1B illustrates a block diagram of an MC service server 200 (e.g., an MCPTT server) for controlling ad-hoc group communications using a security context for an MCX service, according to an embodiment of the present disclosure.

In an embodiment, MC service server 200 includes memory 210, processor 220, communicator 230, and ad hoc group controller 240.

In an embodiment, memory 210 stores information related to various communication messages (e.g., ad hoc group communication requests) and security contexts. Memory 210 stores instructions to be executed by processor 220. Memory 210 may include non-volatile storage elements. Examples of such non-volatile storage elements may include magnetic hard disks, optical hard disks, floppy disks, flash memory, or various forms of electrically programmable memory (EPROM) or Electrically Erasable Programmable (EEPROM) memory. Further, in some examples, memory 210 may be considered a non-transitory storage medium. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or propagated signal. However, the term "non-transitory" should not be construed as memory 210 being non-removable. In some examples, memory 210 may be configured to store a greater amount of information than memory. In some examples, a non-transitory storage medium may store data (e.g., in Random Access Memory (RAM) or cache) that may change over time. The memory 210 may be an internal storage unit, or it may be an external storage unit of the MC service server 200, cloud storage, or any other type of external storage.

The processor 220 is in communication with the memory 210, the communicator 230, and the ad hoc controller 240. Processor 220 is configured to execute instructions stored in memory 210 and perform various processes. Processor 220 may include one or more processors, which may be general-purpose processors (such as Central Processing Units (CPUs), application Processors (APs), etc.), purely graphics processing units (such as Graphics Processing Units (GPUs), vision Processing Units (VPUs)), and/or Artificial Intelligence (AI) specific processors (such as Neural Processing Units (NPUs)).

Communicator 230 is configured to communicate internally between internal hardware components and with external devices (e.g., first MC service client device 100, one or more second MC service client devices 300, a server, etc.) via one or more networks (e.g., radio technologies). Communicator 230 includes electronic circuitry specific to a standard that enables wired or wireless communication.

The ad hoc group controller 240 is implemented by processing circuitry such as logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuitry, etc., and may optionally be driven by firmware. The circuitry may be embodied, for example, in one or more semiconductor chips, or on a substrate support such as a printed circuit board or the like.

Additionally, the operations of the ad hoc group controller 240 may be performed by the processor 220. For example, the MC service server 200 may include the processor 220 and the communicator 230, and may not include the ad hoc group controller 240, and the processor 220 may be configured to perform the operation of the ad hoc group controller 240. That is, the ad hoc group controller 240 is replaced by the processor 220.

In an embodiment, the ad hoc group controller 240 receives an ad hoc group communication request message from the first MC service client device 100 to establish an ad hoc group communication with the second MC service client device 300. The ad hoc controller 240 determines whether ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request. In response to determining that ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request, the ad hoc group controller 240 accepts the ad hoc group communication request and verifies the list of invited second MC service client devices based on the configured restrictions. In response to determining that ad hoc group communication is not supported by the MC service server 200 and is not successfully authorized based on the received ad hoc group communication request, the ad hoc group controller 240 denies the ad hoc group communication request. The ad hoc group controller 240 receives a security context of the second MC service client device 300 for ad hoc group communication.

The ad hoc group controller 240 transmits an ad hoc group communication request message to the second MC service client device 300 together with the generated security context to notify about the ad hoc group communication, wherein the MC service server 200 removes the list of block sharing participants associated with the second MC service client device 300 and the MC service group Identification (ID) list of the second MC service client device 300 that needs to be confirmed. When the second MC service client device 300 accepts the ad hoc group communication request message, the ad hoc group controller 240 receives an ad hoc group communication response from the second MC service client device 300, wherein the ad hoc group communication response includes the functional alias of the responding second MC service client device 300.

The ad hoc controller 240 determines whether the received ad hoc communication response is received within a configured time. In response to determining that the received ad hoc group communication response is not received within the configured time, the ad hoc group controller 240 relinquishes the ad hoc group communication. In response to determining that the received ad hoc group communication response is received within the configured time, the ad hoc group controller 240 transmits the received ad hoc group communication response to the first MC service client device 100 to establish the ad hoc group communication with the second MC service client device 300 using the generated security context.

The ad hoc group controller 240 detects an ongoing ad hoc group communication between the first MC service client device 100 and the second MC service client device 300. The ad hoc group controller 240 receives a modify ad hoc group call participant request message from the first MC service client device 100, wherein the modify ad hoc group call participant request message includes modification information. The modification information indicates that the second MC service client device 300 is removed from the detected ongoing ad hoc group communication and/or that a new MC service client device is added to the detected ongoing ad hoc group communication.

The ad hoc group controller 240 determines whether the first MC service client device 100 is authorized to modify the participant list of the detected ongoing ad hoc group communication. The ad hoc group controller 240 modifies the participant list (e.g., add/remove/rejoin, etc.) by performing an action based on the received modification information. The ad hoc group controller 240 notifies the second MC service client device 300 of the first MC service client device 100 and/or the modified participant list of the second MC service client device 300.

The ad hoc group controller 240 transmits an ad hoc group communication leaving request to the second MC service client device 300 based on the modification information to remove the second MC service client device 300 from the detected ongoing ad hoc group communication. The ad hoc group controller 240 receives an ad hoc group call departure response from the modified second MC service client device 300. The ad hoc controller 240 removes the modified second MC service client device 300 from the detected ongoing ad hoc communication upon receiving the ad hoc call departure response.

The ad hoc controller 240 transmits an ad hoc group call communication request to the new MC service client device based on the modification information to add the new MC service client device to the detected ongoing ad hoc group communication, wherein the ad hoc group call communication request includes the security context of the new MC service client device, the ad hoc group identification of the detected ongoing ad hoc group communication, and the session identification. The ad hoc group controller 240 receives an ad hoc group communication response from the new MC service client device. The ad hoc group controller 240 adds a new MC service client device to the detected ongoing ad hoc group communication. The ad hoc group controller 240 adds/removes/rejoins the first MC service client device 100 and/or the second MC service client device 300 in the detected ongoing ad hoc group communication. The ad hoc controller 240 releases the detected ongoing ad hoc communication.

Although fig. 1B illustrates various hardware components of MC service server 200, it should be understood that other embodiments are not so limited. In other embodiments, MC service server 200 may include a fewer or greater number of components. Moreover, the labels or names of the components are for illustration purposes only and do not limit the scope of the present invention. One or more components may be combined to perform the same or substantially similar functions to control ad hoc group communications using security context for MCX services (e.g., calls).

Fig. 2 illustrates a sequence diagram for initiating an ad hoc group call setup using a non-preconfigured means (appreach), according to an embodiment of the present disclosure.

Precondition for ad hoc group call establishment:

i. An authorized user at a first MC service client device 100 wants to invite other MC service users at one or more second MC service client devices (300A, 300B, 300C) for ad hoc group communication.

The number of participants invited for communication is within the limits of the non-preconfigured method/means.

End-to-end encryption is supported for the ad hoc group communication.

The first MC service client device 100 has all security-related information required for communication with participants of the ad hoc group communication, e.g., one or more second MC service client devices (300A, 300B, 300C).

At step S201, a user at the first MC service client device 100 (e.g., an MC service user) wishes to initiate ad hoc group communication. The first MC service client device 100 initiates an ad hoc group communication by sending an ad hoc group communication request containing a list of participants to the MC service server 200. Because end-to-end encryption is supported, the information element that the encryption supports should be set to true (true). The ad hoc group communication request may also contain a block shared participant list indicator information element set to true if an originating (registration) user (e.g., the first MC service client device 100) (i.e., the first MC service client device 100) wants to prohibit sharing of the list of participants to other users (e.g., one or more second MC service client devices (300A, 300B, 300C)). The ad hoc group communication request may include the MC service group ID created by the first MC service client device 100 or may not include the MC service group ID that allows the MC service server 200 to be assigned one for use. Including SDP offer (SDP offer) containing MC service client media parameters. If there is a floor (floor) request to send, the ad hoc communication request contains an indication of an implicit floor request. If the MC service user of the first MC service client device 100 has selected a functional alias, the ad hoc group communication request contains the functional alias. The ad hoc group communication request may also include location information if it comprises an implicit floor request.

If the MC service user at the first MC service client device 100 initiates an MC service emergency ad hoc group communication or has set an MC service emergency state for the first MC service client device 100 (due to a previously triggered MC service emergency alert):

the mc service ad hoc group communication request should contain an emergency indicator;

if the MC service emergency state has not been set, the first MC service client device 100 sets its MC service emergency state. The MC service emergency state of the first MC service client device 100 is preserved until explicitly cancelled by the user of the first MC service client device 100.

At step S202, if the ad hoc group communication is supported and authorized, the MC service server 200 accepts the ad hoc group communication request. Otherwise, the ad hoc group communication request is rejected and the remaining steps are not continued (e.g., S203-S214). If authorized, the MC service server 200 verifies whether the number of invited participants is within the configured limits before performing the communication setup (communication setup) (e.g., S203-S214).

I. if a functional alias exists, the MC service server 200 checks whether the provided functional alias is allowed to be used and has been activated for the user.

If the location information is included in the ad hoc group communication request, the MC service server 200 checks the privacy policy of the MC service user to determine whether the location information of the first MC service client device 100 can be provided to other users in the communication.

If an emergency indicator is present in the received MC service ad hoc communication request, the MC service ad hoc group is considered to be in an ongoing emergency state until the ad hoc communication is terminated; and

If an impending danger indicator exists in the received MC service Ad hoc group communication request, the MC service Ad hoc group is deemed to be in an impending danger state in progress until the Ad hoc group communication is terminated.

The MC service server 200 treats the ad hoc group communication participants as implicitly affiliated with the ad hoc group.

At step S203, the MC service server 200 transmits an ad hoc group communication request return message containing:

MC service ad hoc group IDs (e.g., provided by the first MC service client device 100 that are acceptable to the MC service server 200, or generated by the MC service server 200 in the case where the MC service ad hoc group ID created by the first MC service client device 100 is not acceptable, or in the case where the first MC service client device 100 does not provide an MC service ad hoc group ID); and

Results of whether ad hoc group communication is authorized (e.g., success or failure). If the ad hoc group communication request is not authorized, the first MC service client device 100 will not proceed with the remaining steps (e.g., S204-S214).

At steps S204 through S206, the first MC service client device 100 sends a security context (e.g., ad hoc group communication security material) request targeted to each of the participants, the request containing security material to be shared with the participants for ad hoc group communication. If end-to-end encryption is not supported, no ad hoc group communication security material request is sent.

At steps S207 to S209, the MC service server 200 transmits an ad hoc group communication request to the MC service client (e.g., one or more second MC service client devices (300A, 300B, 300C)) of the invited user based on step S201. At the same time as sending the ad hoc group communication request, the MC service server 200 removes information elements (e.g., block sharing participant list indicator, MC service ID list of users requiring acknowledgement) that do not need to be transmitted to the target MC service client/one or more second MC service client devices (300A, 300B, 300C).

At steps S210A-S210C, the receiving MC service client (e.g., one or more second MC service client devices (300A, 300B, 300C)) is notified of the ad hoc group communication regarding the incoming call. At steps S211A to S211C, the receiving MC service client accepts the ad hoc group communication request, and transmits an ad hoc group communication response to the MC service server 200. The response may also contain a functional alias of the responding MC service user (e.g., one or more second MC service client devices (300A, 300B, 300C)) that is verified (valid and activated for the user) by the MC service server 200. At step S212, the MC service server 200 transmits an ad hoc group communication response to the first MC service client device 100 through a signaling path to notify about successful communication establishment. Steps S207 to S211C may start to occur before all steps S204 to S206 are completed, because the MC service server 200 does not need to wait for the previous ad hoc group communication request to complete before sending the ad hoc group request to the other participants.

At step S213, if the initiating MC service user (e.g., the first MC service client device 100) needs an acknowledgment from the invited MC service user (e.g., the one or more second MC service client devices 300A, 300B, 300C) and the requested MC service user (e.g., the one or more second MC service client devices 300A, 300B, 300C) does not acknowledge the communication setup within the configured time ("acknowledged communication setup timeout"), the MC service server 200 may continue or relinquish the communication and then inform the initiating MC service user that the acknowledgment does not include all required members according to the ad hoc communication policy from the user profile configuration. The MC service server 200 may notify the originating MC service user of all MC service users that have not acknowledged the ad hoc group communication request within a configured time. When an MC service user joins or leaves an MC service ad hoc group communication, the notification may be sent by the MC service server 200 to the initiating MC service user more than once during the communication. At step S214, the first MC service client device 100 and the one or more second MC service client devices 300A, 300B, 300C establish a media plane (MEDIA PLANE) and floor control resources. Step S214 may occur at any time after step SS212 if the condition for continuing communication is satisfied.

Fig. 3 illustrates a sequence diagram for removing an ad hoc group call participant from an ongoing ad hoc group communication in accordance with an embodiment of the present disclosure.

Preconditions for modification of ad hoc group communication participants by the call initiator (i.e., the first MC service client device 100):

i. the first MC service client device 100 is the call initiator of ad hoc group communication.

MC service subscribers on the first MC service client device 100 and one or more second MC service client devices (e.g., 300A and 300B) are in ongoing ad hoc group communication.

The first MC service client device 100 requests that the user of the second MC service client device 300C be removed from the ad hoc group communication and that the user of the second MC service client device 300B be added to the ongoing ad hoc group communication.

At steps S301-S302, the first MC service client device 100 sends a modified ad hoc group call participant request to the MC service server 200 to remove the second MC service client device 300C from the ongoing ad hoc group communication and add the second MC service client device 300B to the ongoing ad hoc group communication.

At step S303, the MC service server 200 verifies whether the first MC service client device 100 is authorized to add or remove (modify) the participant of the ongoing ad hoc group communication. At step S304, the MC service server 200 transmits a modified ad hoc group communication participant response to the first MC service client device 100. At step S305, the MC service server 200 sends an ad hoc group call departure request to the second MC service client device 300C to remove it from the ongoing ad hoc group communication.

At step S306, the second MC service client device 300C notifies the user of the ad hoc group call departure request. At step S307, the second MC service client device 300C transmits an ad hoc group call departure response to the MC service server 200. At step S308, the MC service server 200 removes the second MC service client device 300C from the ongoing ad hoc group communication. At step S309, the first MC service client device 100 sends an ad hoc group communication security material request to the second MC service client device 300B that contains security material to be shared with the second MC service client device 300B for ad hoc group communication. Steps S309 to S312 may occur at any time after step S304.

At step S310, the MC service server 200 transmits an ad hoc group communication request to the second MC service client device 300B. At step S311, the receiving second MC service client device 300B notifies the user of the ad hoc group communication about the incoming call. At step S312, the second MC service client device 300B accepts the ad hoc group communication request and transmits an ad hoc group communication response to the MC service server 200. The response may also contain a functional alias for the responding MC service user that is verified (valid and activated for the user) by the MC service server.

At step S313, the MC service server 200 notifies the originating MC service user (e.g., the first MC service client device 100) about all users added to the ongoing ad hoc group communication. The notification may be sent by the MC service server 200 to the initiating MC service user more than once during the call when the MC service user joins or leaves the ad hoc group communication. At step S314, the MC service server 200 may notify the participant of a change in the participant list regarding the ongoing ad hoc group communication.

In general, an ad hoc group call allows an MCX user (e.g., the first MC service client device 100) to select two or more MCX users and perform MCX operations on them. This may be an MCPTT call, an MC video call, or an MC data operation. The proposed method uses MCPTT service as an example and describes the systems, procedures and configurations required to support ad hoc group call functions. To support ad hoc group calls, similar procedures are applied to other mission critical services (such as MC data and MC video). The proposed method for an MCPTT client (e.g., first MC service client device 100) may select a method based on configuration parameters from MCPTT user profile configuration data to support an end-to-end security mechanism for ad hoc group call participants.

Minimum participant count for preconfigured ad hoc group calls: the configuration carries the minimum number of participant counts required to initiate an ad hoc group call using the preconfigured group means. With the preconfigured group means, the MCPTT client (initiator) (e.g., first MC service client device 100) sends a list of participants (e.g., 300A, 300B, 300C) invited for the ad hoc group call as part of the ad hoc group call request (e.g., ad hoc group communication request) and the preconfigured group ID from which the security material is obtained and applied to the ad hoc group call.

If the number of participants is less than the count specified in the configuration parameters, the MCPTT client (initiator) sends an ad hoc group call request containing security material to each participant individually. The security material for implementing end-to-end encryption is dynamically generated by the originating MCPTT client (e.g., first MC service client device 100) and shared with the participants in a similar mechanism applicable to private MCPTT (private MCPTT) calls as specified in 3gpp TS 33.180. This approach is well suited for smaller numbers of participants.

Alternatively, there may be a configuration parameter "maximum participant count for non-preconfigured ad hoc group calls". If the number of participants invited for the ad hoc group call is less than or equal to the value specified in the configuration parameter, the MCPTT client may choose to use a non-preconfigured means for the ad hoc group call.

In general, the proposed approach is that the MCPTT client can choose which method to use for an ad hoc group call based on configuration parameters present in the MCPTT user profile configuration data or any other configuration data, as shown in tables 1 and 2.

TABLE 1

TABLE 2

Information flow for supporting ad hoc group calls: table 3 describes the information flow of ad hoc group call requests from MCPTT clients (e.g., 100, 300A, 300B, 300C) to MCPTT servers (e.g., MC service server 200) for non-preconfigured means, as shown in tables 3 and 4.

TABLE 3

TABLE 4

Table 5 depicts the information flow of ad hoc group call requests from an MCPTT server (e.g., MC service server 200) to MCPTT clients (e.g., 300A, 300B, 300C).

TABLE 5

Table 6 depicts the information flow of ad hoc group call responses (e.g., ad hoc group communication responses) from MCPTT clients (e.g., 300A, 300B, 300C) to MCPTT servers (e.g., MC service server 200).

TABLE 6

Table 7 depicts the information flow of an ad hoc group call response from an MCPTT server (e.g., MC service server 200) to an MCPTT client (e.g., first MC service client device 100).

TABLE 7

Information element	Status of	Description of the invention
			MCPTT ID	M	MCPTT ID of calling party
Functional alias	O	Functional alias for calling party
			MCPTT ID	M	MCPTT ID of called party
Functional alias	O	Functional alias of called party
			MCPTT group ID	M	MCPTT group ID for ad hoc group call
SDP acknowledgement	M	Selected media parameters
			Results	M	Results of group call requests (success or failure)

Without a preconfigured approach, if the originator of the ad hoc group call or any other authorized user (e.g., first MC service client device 100) wants to add a new participant (e.g., 300B), the MCPTT client sends an ad hoc group call request to the new participant. The MCPTT client must ensure that the same MCPTT ad hoc group ID is specified in these new requests and security materials. In the event that an authorized user wants to remove some participants from an ongoing ad hoc group call, the MCPTT client sends to the MCPTT server (e.g., MC service server 200) a modified ad hoc group call participant request (e.g., a modified ad hoc group communication participant request) as specified in patent application 202141042797 that contains a list of participant MCPTT IDs to be removed. The procedure shown in the proposed method may be applied to on-demand (on-demand) ad hoc group communication or ad hoc group call using a pre-established session. Based on the request received from the MCPTT user originating the ad hoc group call, the ad hoc group call request may carry the following information:

i. Emergency indicator: indicating that the ad hoc group call request is an MCPTT emergency call.

Alarm indicator: indicating whether an emergency alert is to be sent.

An impending hazard indicator: indicating that the ad hoc group call request is an impending danger call for MCPTT.

Key management (AGCK) for ad hoc group communication using non-preconfigured means: the purpose of this process is to allow multiple MCPX UE (e.g., 100, 300A, 300B, 300C) to create an end-to-end security context to protect MCX ad hoc group communications using non-preconfigured means. To create a security context, the initiating MCX UE (e.g., the first MC service client device 100) generates an ad hoc group communication key (AGCK) and securely transmits the key to all destination (terminating) MCX UEs (e.g., 300A, 300B, 300C) along with a key identifier (AGCK-ID) (the same as the PCK generated for the private call as specified in 3gpp TS 33.108). Prior to key distribution, all MCX UEs should be provided with a time-limited key material associated with the MCX user by a key management server (KEY MANAGEMENT SERVER, KMS) as described in clause 5.3 of 3gpp TS 33.180. Before initiation of MCX ad hoc group communication, the initiating MCX UE should generate AGCK and AGCK-IDs. For each of the participants, the originating MCX client should issue an ad hoc group communication request. Included in the MESSAGE is an SDP offer containing a MIKEY-SAKKE i_message, as defined in IETF RFC 6509[11 ]. I_message encapsulates AGCK for the end-point MC user, encrypting the key to the UID of the end-point user (derived from the user's URI). I_MESSAGE also contains the identifier (AGCK-ID) of AGCK. The i_message is signed using the UID of the initiating user (the key associated with it).

When some participants are not members of a preconfigured group, a process for ad hoc group communication using preconfigured means: in some cases, when using a preconfigured group means for an ad hoc group call, the participants invited for the ad hoc group call may not be group members of the preconfigured group. In this case, end-to-end security cannot be established because members of the non-preconfigured group cannot access the secure material for the ad hoc group call. To deal with this, the proposed method provides a hybrid approach. The MCPTT server (e.g., MC service server 200) checks, when it receives the ad hoc group call request using a preconfigured means, whether all the invited users for the ad hoc group call are members of the preconfigured group. If some users are not members of the preconfigured group, then the MCPTT server (e.g., MC service server 200) returns a list of those users to the originating MCPTT client (e.g., first MC service client device 100). Upon receiving the list from the MCPTT server (e.g., MC service server 200), the originating MCPTT client (e.g., first MC service client device 100) makes a separate ad hoc request for the security material needed for sharing. Alternatively, if the originating MCPTT client (e.g., first MC service client device 100) has access to a list of members of the preconfigured group, it may itself make an ad hoc group call to users that are members of the preconfigured group using the preconfigured method and send an ad hoc group call request individually to each of the participants that are not members of the preconfigured group. The MCPTT client (e.g., first MC service client device 100) ensures that the same ad-hoc group ID is used in all requests, which indicates to the MCPTT server (e.g., MC service server 200) that all such requests are for the same ad-hoc group communication. This approach would be particularly useful when an ad hoc group call involves users from different MCPTT domains and they are not part of a preconfigured group. Typically, authorized users want to initiate ad hoc group calls to participants in their vicinity, and in some cases, these users may come from different MCPTT domains. This approach helps to handle this situation without having to go through the hassle of creating/updating a preconfigured group to add participants who have not been members of the preconfigured group.

When some participants are not members of a preconfigured group, a secure process of ad hoc group communication using preconfigured means: when using the preconfigured method for ad hoc Group calls, the Group master key (Group MASTER KEY, GMK) and the Group master key identifier (Group MASTER KEY IDENTIFIER, GMK-ID) of the preconfigured Group are used to establish the security context for ad hoc Group communications. An ad hoc group call participant that is a member of the pre-configured group specified in the ad hoc group call request may have received the GMK and GMK-ID associated with the pre-configured group from the GMS.

In some cases, when using the preconfigured means, some of the invited participants may not be group members of the preconfigured group and do not own the GMK and GMK-ID of the preconfigured group. To handle this, the proposed method distributes GMK and GMK-ID to members of a non-preconfigured group through MCPT clients originating ad hoc group calls. Upon receiving a list of participants from the MCPTT server that are not members of the preconfigured group, the originating mcpx client separately targets those participants to send an ad hoc group request. For each of the participants, the originating MCX client should issue an ad hoc group communication request. Included in the MESSAGE is an SDP offer containing a MIKEY-SAKKE i_message, as defined in IETF RFC 6509[11 ]. The i_message encapsulates the GMK of the pre-configured group, encrypting the key to the UID of the end user (derived from the URI of the user). I_MESSAGE also contains the GMK-ID. The i_message is signed using the UID of the initiating user (the key associated with it).

Since the GMK and GMK-ID are shared with members of a group that is not pre-configured, the present invention proposes that once ad hoc group communication is terminated, the GMK and GMK-ID should be regenerated new. To enable regeneration of new GMKs and GMK-IDs for preconfigured groups, the proposed method allows an MCPTT server or MCPTT client (e.g., first MC service client device 100) to request a group management server to regenerate a new set of keys upon termination of an ad hoc group call. The request carries the group Id of the preconfigured group.

In another alternative, to work with this solution, the MCPTT server should use a random number generator to generate a temporary or short term identifier, such as RANDsessX. The random number generator generates a random number coordinated with the range of the identifier. This RANDsessX is provided to each ad hoc group call participant, which is a member of the preconfigured group specified in the ad hoc group call request, and has GMK and GMK-ID associated with the preconfigured group from the GMS. In the case of members of a non-preconfigured group, the MCPTT client or MCPTT server should generate RANDsessX and include it with the GMK and GMK-ID in the ad hoc group call request. This RANDsessX is a short session-specific identifier and expires once the session for a particular ad hoc call is ended.

In another alternative, if a member leaves or joins an ad hoc call in the same group, the MCPTT client (e.g., first MC service client device 100) or MCPTT server (e.g., MC service server 200) will provide new RANDsessX to all members of the group call to generate a new key for the ad hoc call.

In another alternative, a counter ad hoc (Counterad-hoc) value is associated with each session. The counter value is incremented for each new ad hoc group call session and when an member joins or leaves the ad hoc group, a new key will be generated by each member of the call using the counter value as an additional input to ensure that members leaving the group will not be able to decode future communications.

In another alternative, when the user is removed from the group, the group management server may choose to update the GMK associated with the group ID (depending on the security profile of the group) as defined in clause 5.7 in 3gpp TS 33.108.

When an ad hoc group call is initiated using a non-preconfigured means, and if any new member is invited to an ongoing session, the MCPTT client (initiator) sends an ad hoc group call request targeting new participants sharing the same group ID, session ID and security material (AGCK, AGCK-ID) of the ongoing session. Similarly, when an ad hoc group call is initiated using the preconfigured means, and if any new users (e.g., 300B) are invited to an ongoing session, and if they are not members of the preconfigured group, the MCPTT client (initiator) (e.g., first MC service client device 100) will share the GMK and GMK-ID of the preconfigured group to the new members (e.g., 300B) as part of the ad hoc group call request targeting each of the new participants (e.g., 300B).

Fig. 4 illustrates a sequence diagram for initiating an ad hoc group call setup by an authorized user, in accordance with an embodiment of the present disclosure.

The following are preconditions for initiating the establishment of an ad hoc group call:

The authorized user knows the MCPTT user to be invited to the ad hoc group call (e.g., MC service client device 300A, MC service client device 300B).

The group ID for the ad hoc group call is generated by the originating MCPTT client (e.g., first MC service client device 100).

The ad hoc group call setup procedure initiated by an authorized user (e.g., the first MC service client device 100) includes the following steps S401 to S410.

At step S401, the first MC service client device 100 initiates an ad hoc group call by sending an ad hoc group call request to the MC service server 200. The ad hoc group call request contains a list of MCPTT IDs of users (e.g., MC service client device 300A, MC service client device 300B) that are invited to the call. The ad hoc group call request may also contain a block shared participant list indicator information element set to true if the originating user (e.g., the first MC service client device 100) wants to prohibit sharing of the participant list to other users. If a user at first MC service client device 100 wants to create a permanent MCPTT group from participants of an ad hoc group communication, then the create group indication information element should be set to true.

At step S402, the MC service server 200 checks whether the first MC service client device 100 is authorized to initiate an ad hoc group call. At steps S403 and S405, MC service server 200 sends an ad hoc group call request to the MCPTT client (e.g., MC service client device 300A, MC service client device 300B) included in the ad hoc group call request in step S401.

At steps S404 and S406, the receiving MCPTT client (e.g., MC service client device 300A, MC service client device 300B) is notified about the incoming ad hoc group call. At steps S407 and S408, the receiving MCPTT client (e.g., MC service client device 300A, MC service client device 300B) accepts the ad hoc group call request and sends an ad hoc group call response to MC service server 200. At step S409, the MC service server 200 transmits an ad hoc group call response to the first MC service client device 100 through a signaling path to notify about successful call setup. At step S410, the first MC service client device 100, the MC service client device 300A, and the MC service client device 300B establish the media plane and the floor control resource.

The ad hoc group call request contains the information element block shared participant list indicator set to true and the MC service server 200 will not allow participants other than the originating user (e.g., the first MC service client device 100) or the authorized user to determine a list of users joining the ad hoc group call. If the ad hoc group call request contains an information element create group indication set to true, and if the user is authorized to create an MCPTT group, MC service server 200 will follow the procedure in sub-clause 10.2.3 "group creation" on behalf of the MCPTT client. An ad hoc group call response may be given to the originator (e.g., the first MC service client device 100) if the conditions specified in the ad hoc group call request are satisfied and the audio transmission may begin. For example, if all mandatory participants specified in the ad hoc group call request join the call, an ad hoc group call response may be sent to the originator (e.g., the first MC service client device 100) so that the audio transmission may begin.

Fig. 5 illustrates a sequence diagram for initiating an ad hoc group call setup by an authorized user in accordance with another embodiment of the present disclosure.

An authorized user (e.g., first MC service client device 100) knows the MCPTT user to be invited to the ad hoc group call (e.g., MC service client device 300A, MC service client device 300B).

MCPTT clients 1 (e.g., first MC service client device 100) to N are registered and their respective users, MCPTT user 1 to MCPTT user N (e.g., MC service client device (300N) (not shown in fig. 5)) are authenticated and authorized to use MCPTT services, as per the procedure in sub-clause 10.2 of 3gpp ts 23.379.

MC service client devices 300A-N (e.g., MC service client device (300N)

(Not shown in fig. 5)) has activated the same functional alias.

MC service server 200 has subscribed to the MCPTT function alias control server within the MC system for a function alias activation/deactivation update.

The steps of the ad hoc group call setup procedure initiated by the authorized user are as follows in steps S501 to S511.

At step S501, the first MC service client device 100 initiates an ad hoc group call by sending an ad hoc group call request to the MC service server 200. The ad hoc group call request contains a list of MCPTT IDs or functional aliases or both MCPTT IDs and functional aliases of users that are potential targets for the ad hoc group call. The ad hoc group call request may also contain a block shared participant list indicator information element set to true if the originating user (e.g., the first MC service client device 100) wants to prohibit sharing of the participant list to other users. If a user at first MC service client device 100 wants to create a permanent MCPTT group from participants of an ad hoc group communication, then the create group indication information element should be set to true.

At step S502, the MC service server 200 checks whether the first MC service client device 100 is authorized to initiate an ad hoc group call. At step S503, MC service server 200 determines a list of MCPTT users to send MCPTT ad hoc group call requests based on the set of potential target recipients (e.g., MC service client device 300A, MC serving client device 300B) obtained from the ad hoc group call request from first MC service client device 100. When the functional alias is used as the target address, MC service server 200 resolves the functional alias into a corresponding list of related MCPTT IDs of MC service client devices 300A-300B that have activated the functional alias. The functional alias must have been activated to identify the MCPTT ID of the called user.

At steps S504 and S506, MC service server 200 transmits an ad hoc group call request to the MCPTT client determined at step S503. At steps S505 and S507, the receiving MCPTT clients (e.g., MC service client device 300A and MC service client device 300B) are notified of the incoming ad hoc group call. At steps S508 to S509, the receiving MCPTT client accepts the ad hoc group call request and sends an ad hoc group call response to MC service server 200.

At step S510, the MC service server 200 transmits an ad hoc group call response to the first MC service client device 100 through a signaling path to notify about successful call setup. At step S511, the first MC service client device 100, the MC service client device 300A, and the MC service client device 300A establish the media plane and the floor control resource.

The ad hoc group call request contains the information element block shared participant list indicator set to true and the MC service server 200 will not allow participants other than the originating user (e.g., the first MC service client device 100) or the authorized user to determine to join the user list of the ad hoc group call. If the ad hoc group call request contains an information element create group indication set to true, and if the user is authorized to create an MCPTT group, MC service server 200 will follow the procedure in sub-clause 10.2.3 "group creation" on behalf of first MC service client device 100. An ad hoc group call response may be given to the originator (e.g., the first MC service client device 100) if the conditions specified in the ad hoc group call request are satisfied and the audio transmission may begin. For example, if all mandatory participants specified in the ad hoc group call request join the call, an ad hoc group call response may be sent to the originator (e.g., the first MC service client device 100) so that the audio transmission may begin.

Fig. 6 illustrates a sequence diagram for modifying ad hoc group call participants from ongoing ad hoc group communications in accordance with an embodiment of the present disclosure.

The following are preconditions for modifying ad hoc group call establishment:

MCPTT users on first MC service client device 100 and MC service client device 300A are on an ongoing ad hoc group call, as shown in step S601.

The first MC service client device 100 is the initiator of an ad hoc group call.

First MC service client device 100 indicates to remove the user of MC service client device 300A and add the MCPTT user of MC service client device 300B to the ongoing ad hoc group call.

The signaling control plane procedure for the initiator of the MCPTT ad-hoc group call to modify the participants of the ongoing ad-hoc group call is as follows in steps S602 to S612.

At step S602, the first MC service client device 100 sends a modify ad hoc group call participant request to the MC service server 200. At step S603, the MC service server 200 verifies whether the first MC service client device 100 is authorized to add or remove (modify) the participants of the ongoing ad hoc group call. At step S604, the MC service server 200 determines a list of participants that need to be added to and/or removed from the ongoing ad hoc call based on the request received in step S601.

At step S605, the MC service server 200 sends an ad hoc group call departure request to the MC service client device 300A to remove it from the ongoing ad hoc group call. At step S606, the MC service client device 300A notifies the user of an ad hoc group call departure request. At step S607, the MC service client device 300A transmits an ad hoc group call departure response to the MC service server 200.

At step S608, the MC service server 200 sends an ad hoc group call request to the MC service client device 300B to add it to the ongoing ad hoc group call. At step S609, the MC service client device 300B notifies the user of the incoming ad hoc group call request. At step S610, the MC service client device 300B transmits an ad hoc group call response to the MC service server 200. At step S611, the MC service server 200 sends a modified ad hoc group call participant response to the first MC service client device 100. At step S612, the MC service server 200 may notify the participants of the ad hoc group call about the change in the participant list.

Modifying ad hoc group call participant requests may carry the list of participants to add and remove in the same request, or it may be carried in different requests. Steps S405 and S408 may occur in parallel. In some cases, the MC service server 200 itself may remove participants from an ongoing ad hoc group call without a request from the originator of the ad hoc group call (e.g., the first MC service client device 100) or from an authorized user. The MC service server 200 may remove low priority users from an ongoing ad hoc group call in case of congestion. Furthermore, the initiator may add the removed user at some later point in time. In addition to the originator of the ad hoc group call, authorized users may also add or remove participants from the ongoing ad hoc group call.

Fig. 7 illustrates a sequence diagram for initiating termination of an ongoing ad hoc group communication by a first MC service client device 100, according to an embodiment of the present disclosure.

Procedure for the MC service server 200 to release the ad hoc group call. The process focuses on the case where the MC service server 200 initiates termination of an ongoing ad hoc call for all participants of the ad hoc call because one or more termination conditions are met, e.g. due to expiration of the hold time, last participant leaving, next to last participant leaving, initiator leaving.

At step S701, assume that MCPTT users on first MC service client device 100, MC service client device 300A, and MC service client device 300B are already part of an ongoing ad hoc group call. At step S702, MC service server 200 wishes to release the ongoing MCPTT ad hoc group call, for example, due to expiration of the hold time, last participant leaving, penultimate participant leaving, initiator leaving. At step S703, the MC service server 200 identifies the participants of the ongoing ad hoc group call and generates an ad hoc group call release request to release the ongoing session.

At steps S704, S705, and S706, the MC service server 200 transmits an ad hoc group call release request to each participant of the ongoing ad hoc group call via the SIP core. At steps S707, S709, and S710, the MCPTT user is notified of the release of the ad hoc group call. At steps S708, S711, and S712, the MCPTT client or clients that received the ad hoc group call release request confirms to the MC service server 200 by transmitting an ad hoc group call release response. At step S713, the first MC service client device 100, MC service client device 300A, and MC service client device 300B have successfully released the floor control and media plane resources associated with the terminated group call.

Fig. 8 shows a sequence diagram in which the first MC service client device 100 leaves the ongoing ad hoc group communication, according to an embodiment of the present disclosure.

The preconditions are as follows:

i. MCPTT users on first MC service client device 100 through MCPTT client n (e.g., MC service client device 300A, MC service client device 300B) are on an ongoing ad hoc group call.

The first MC service client device 100 indicates to leave the ad hoc group call.

The signaling control plane procedure for the MCPTT user leaving the ongoing MCPTT ad hoc group call is as follows in steps S801 to S804.

At step S801, the first MC service client device 100 transmits an ad hoc group call departure request to the MC service server 200. At step S802, the MC service server 200 transmits an ad hoc group call departure response to the first MC service client device 100. Floor control and media plane resources associated with the ad hoc group call for the first MC serving client device 100 are released at step S803. MC service server 200 checks if the group call termination condition is met, such as expiration of the hold time, last participant leave, next to last participant leave, initiator leave, and there are no minimum number of affiliated MCPTT group members (AFFILIATED MCPTT group members). If one or more group call termination conditions are met, the MC service server 200 releases the ad hoc group call for all participants as described in the procedure "MC service server 200 releases the ad hoc group call" of the proposed method. At step S804, the MCPTT user at MC service client device 300A-300B may be notified that first MC service client device 100 has left the ad hoc group call. The functional alias (if any) for the first MC service client device 100 is displayed. MC service server 200 does not perform a delayed entry for the MCPTT user who has left the ad hoc group call (LATE ENTRY).

Fig. 9 illustrates a sequence diagram in which the MC service server 200 requests the first MC service client device 100 to rejoin an ongoing ad hoc group communication after returning from outside of network coverage, according to an embodiment of the present disclosure.

The procedure is applicable to all types of ad hoc group calls including, for example, emergency calls, impending danger calls (MCPTT impending danger calls) and broadcast calls.

The preconditions are as follows:

assume that MCPTT users on MC service client device 300A-300B are on an ongoing ad hoc group call. Alternatively, the MCPTT user may use the activated functional alias.

Xv. during the initiation of the MCPTT ad hoc group call, first MC service client device 100 is not available.

The signaling control plane procedure for MC service server 200 requesting members returned from outside the coverage to join an ongoing MCPTT ad-hoc group call is as follows in steps S901 to S906.

At step S901, the MC service server 200 determines that the first MC service client device 100, which is part of the invited member, returns from outside the coverage area and must be invited to join the ongoing ad hoc group call (delayed entry). At step S902, MC service server 200 generates an ad hoc group call request including information such as an MCPTT service identifier (for the SIP core, the request may be routed to MC service server 200), an MCPTT group ID of the ad hoc group to which the join is invited, the one or more media types, and sends to first MC service client device 100 via the SIP core. At step S903, the MCPTT user at first MC service client device 100 is notified about the incoming ad hoc group call. At step S904, when the MCPTT user at first MC service client device 100 accepts the incoming group call request, first MC service client device 100 sends an ad hoc group call response including the selected media type to MC service server 200 through a signaling path. If the incoming ad hoc group call request is rejected by the first MC service client device 100, the MC service server 200 should not resend the ad hoc group call request. The ad hoc group call response may also contain a functional alias for the first MC service client device 100.

At step S905, first MC service client device 100 is successfully added to the ongoing ad hoc group call, and the MCPTT user at first MC service client device 100 to MCPTT client n (e.g., MC service client device 300B) may be notified about the first MC service client device 100 joining the group call, and the functional alias of first MC service client device 100 may be displayed. At step S906, a floor acquisition (floor token) with information of the current speaker is transmitted to the first MC service client device 100.

Fig. 10 illustrates a sequence diagram in which the first MC service client device 100 requests the MC service server 200 to rejoin an ongoing ad hoc group communication after returning from outside of network coverage, according to an embodiment of the present disclosure.

The preconditions are as follows:

Assume that MCPTT users on MC service client device 300A-300B are on an ongoing call. Alternatively, the MCPTT user may use the activated functional alias.

The signaling control plane procedure for the MCPTT client to rejoin the ongoing MCPTT ad-hoc call is as follows in steps S1001 to S1005.

At step S1001, the first MC service client device 100 has the necessary information for rejoining the ongoing ad hoc group call. The first MC service client device 100 initiates an ad hoc group call re-join request that includes ongoing ad hoc group call information. The ad hoc group call rejoin request may contain a functional alias of the first MC service client device 100 as selected by the MC service user. At step S1002, the MC service server 200 checks whether the first MC service client device 100 can rejoin the ongoing call.

At step S1003, the first MC service client device 100 is notified of the success of the ad hoc call rejoin by transmitting an ad hoc call rejoin response. If the ongoing ad hoc group call is an urgent or impending danger group call, the response should contain an urgent or impending danger indicator. At step S1004, the first MC service client device 100 is successfully added to the ongoing ad hoc group call, and the MCPTT user at the first MC service client device 100 to MCPTT client n may be notified about the first MC service client device 100 joining the ad hoc group call, and the functional alias of the first MC service client device 100 may be displayed. At step S1005, a floor acquisition with information of the current speaker is transmitted to the first MC service client device 100.

Ad hoc group call related configuration: in order to support ad hoc group calls, appropriate configuration is required. In addition to the configuration parameters specified in indian patent application No. 202141019166, the embodiments herein propose the following additional parameters:

xvii ad hoc group communication support: for any reason, some deployments may choose not to support ad hoc group call functionality. To achieve this function, the proposed method introduces configuration parameters in the MCX service configuration, as shown in table 8.

TABLE 8

When the configuration is set to false (false), then the MCPTT server (e.g., MC service server 200) denies any incoming ad hoc group call requests from MCPTT clients (e.g., first MC service client device 100, MC service client device 300A, MC service client device 300B, etc.). When the configuration is set to false, the MCPTT client will also not originate an ad hoc group call request.

Xviii. suspension timer for ad hoc group communication: as shown in table 9, this configuration instructs the MC service server 200 to release the ongoing ad hoc group communication after the expiration of the suspension timer. This may also be indicated by the originator of the MCPTT ad hoc call in the ad hoc group call request (e.g., first MC service client device 100), or it may be configured in MCPTT service configuration data or any other document.

TABLE 9

Maximum duration for ad hoc group communication: as shown in table 10, this configuration allows the MCPTT ad hoc group communication to be kept active for a maximum allowed duration that the MCPTT service administrator specifies. Alternatively, this may also be indicated by the originator of the MCPTT ad hoc group call in the ad hoc group call request (e.g., first MC service client device 100). Once this maximum duration is reached, the MC service server 200 should release the ongoing ad hoc group communication. If the ongoing ad hoc group communication is just an emergency call (MCPTT emergency call) or an impending danger call (MCPTT impending danger call), MC service server 200 may not release the call.

TABLE 10

Information flow for supporting ad hoc group calls: table 11 depicts the information flow of an ad hoc group call request from an MCPTT client (e.g., first MC service client device 100) to MC service server 200.

TABLE 11

Table 12 depicts the ad hoc group call request information elements when the combination of the functional alias and MCPTT ID is used as the target.

TABLE 12

Table 13 depicts the information flow of ad hoc group call requests from MC service server 200 to MCPTT clients (e.g., MC service client device 300A to MC service client device 300B). Table 13 depicts ad hoc group call request information elements.

TABLE 13

Table 14 depicts the flow of information requested from an MCPTT client (e.g., first MC service client device 100) to an MCPTT server (e.g., MC service server 200) and modified ad hoc group call participants between the MCPTT servers. Table 14 depicts the modified ad hoc group call participant request information elements.

TABLE 14

Table 15 depicts the information flow from the MCPTT client (e.g., MC service client device 300A) to the MCPTT server (e.g., MC service server 200) and the modified ad hoc group call participant responses between the MCPTT servers. Table 15 depicts modifying ad hoc group call participant response information elements.

TABLE 15

Table 16 depicts the information flow of ad hoc group call release requests from MCPTT server (e.g., MC service server 200) to MCPTT client (e.g., first MC service client device 100) and from MCPTT client (e.g., MC service client device 300A) to MCPTT server and between MCPTT servers. Table 16 depicts ad hoc group call release request information elements.

TABLE 16

Table 17 depicts the information flow of ad hoc group call release responses from MCPTT server (e.g., MC service server 200) to MCPTT client (e.g., first MC service client device 100) and from MCPTT client (e.g., MC service client device 300A) to MCPTT server and between MCPTT servers. Table 17 depicts ad hoc group call release response information elements.

TABLE 17

Table 18 depicts the information flow of ad hoc group call departure requests from the MCPTT server to the MCPTT clients.

TABLE 18

Table 19 depicts the information flow of ad hoc group call departure requests from the MCPTT client to the MCPTT server.

TABLE 19

Table 20 depicts the information flow of an ad hoc group call release response from an MCPTT client to an MCPTT server.

TABLE 20

Table 21 depicts the information flow of the ad hoc group call release response from the MCPTT server to the MCPTT client.

TABLE 21

Table 21

Table 22 depicts the information flow of an ad hoc group call rejoin request from an MCPTT client to an MCPTT server.

TABLE 22

Table 23 depicts the information flow of an ad hoc group call rejoin response from an MCPTT server to an MCPTT client.

TABLE 23

Fig. 11 illustrates a structure of a UE according to an embodiment of the present disclosure.

As shown in fig. 11, a UE according to an embodiment may include a transceiver 1110, a memory 1120, and a processor 1130. The transceiver 1110, the memory 1120, and the processor 1130 of the UE may operate according to the communication methods of the UE described above. However, components of the UE are not limited thereto. For example, the UE may include more or fewer components than those described above. Further, processor 1130, transceiver 1110, and memory 1120 may be implemented as a single chip. Further, the controller 1130 may include at least one processor. Further, the UE of fig. 11 corresponds to the first MC service client device of fig. 1A.

The transceiver 1110 is collectively referred to as a UE receiver and a UE transmitter, and may transmit signals to and receive signals from a base station/network entity. The signals transmitted to or received from the base station or network entity may include control information and data. Transceiver 1110 may include an RF transmitter for up-converting and amplifying the frequency of a transmitted signal, and an RF receiver for amplifying the frequency of a low noise and down-converted received signal. However, this is merely an example of transceiver 1110, and the components of transceiver 1110 are not limited to RF transmitters and RF receivers.

In addition, the transceiver 1110 may receive a signal through a wireless channel and output it to the processor 1130, and transmit a signal output from the processor 1130 through the wireless channel.

The memory 1120 may store programs and data required for the operation of the UE. Further, the memory 1120 may store control information or data included in a signal obtained by the UE. The memory 1120 may be a storage medium such as Read Only Memory (ROM), random Access Memory (RAM), hard disk, CD-ROM, and DVD, or a combination of storage media.

Processor 1130 may control a series of processes such that the UE operates as described above. For example, transceiver 1110 may receive a data signal that includes a control signal transmitted by a base station or a network entity, and processor 1130 may determine the result of receiving the control signal and the data signal transmitted by the base station or the network entity.

Fig. 12 is a block diagram illustrating an internal structure of a network entity according to an embodiment of the present disclosure. As shown in fig. 12, the network entity of the present disclosure can include a transceiver 1210, a memory 1220, and a processor 1230. The transceiver 1210, memory 1220 and processor 1230 of a network entity may operate according to the communication methods of the network entity described above. However, the components of the terminal are not limited thereto. For example, the network entity may include more or fewer components than those described above. In addition, the processor 1230, the transceiver 1210, and the memory 1220 may be implemented as a single chip. Further, the controller 1230 may include at least one processor. In addition, the network entity of fig. 12 corresponds to the MC service server 200 of fig. 1B.

According to the invention, the network entity comprises at least one entity of the core network. For example, the network entities include AMF (access and mobility management function), SMF (session management function), PCF (policy control function), NRF (network repository function), UPF (user plane function), NSSF (network slice selection function), AUSF (authentication server function), UDM (unified data management), and NEF (network exposure function). However, the network entity is not limited thereto.

The transceiver 1210 is collectively referred to as a network entity receiver and a network entity transmitter, and may transmit/receive signals to/from a base station or UE. The signal transmitted to or received from the base station or UE may include control information and data. In this regard, the transceiver 1210 may include an RF transmitter for up-converting and amplifying the frequency of a transmitted signal, and an RF receiver for amplifying the frequency of a low noise and down-converted received signal. However, this is merely an example of transceiver 1210, and components of transceiver 1210 are not limited to RF transmitters and RF receivers.

In addition, the transceiver 1210 may receive a signal through a wireless channel and output it to the processor 1230, and transmit the signal output from the processor 1230 through the wireless channel.

The memory 1220 may store programs and data required for operation of the network entity. Further, the memory 1220 may store control information or data included in signals obtained by the network entity. The memory 1220 may be a storage medium such as a ROM, RAM, hard disk, CD-ROM, and DVD, or a combination of storage media.

Processor 1230 may control a sequence of processes such that the network entity operates as described above. For example, the transceiver 1210 may receive a data signal including a control signal, and the processor 1230 may determine a result of receiving the data signal.

A method for controlling ad-hoc (ad-hoc) group communication using a security context for a Mission Critical (MCX) service is provided, wherein the method comprises: transmitting, by the first MC service client device, an ad hoc group communication request message to the MC service server to establish an ad hoc group communication with the at least one second MC service client device, wherein the MC service server determines whether the ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request, and when the ad hoc group communication is supported and successfully authorized, receiving, by the first MC service client device, an ad hoc group communication request return message from the MC service server, generating, by the first MC service client device, a security context for the second MC service client device for the ad hoc group communication; and establishing, by the first MC service client device, ad hoc group communication with the at least one second MC service client device using the generated security context.

The ad hoc group communication request message includes at least one of: the list of invited second MC service client devices, encryption support information, a list of block sharing participants associated with at least one second MC service client device, an MC service group Identification (ID), an MC service client media parameter, an indication of an implicit floor request, a functional alias, location information, an emergency indicator, and an impending danger indicator.

The ad hoc group communication request return message includes at least one of an MC service group Identification (ID) and authorization result information.

The security context includes at least one of an ad hoc group communication key (AGCK) and an ad hoc group communication key identifier (AGCK-ID).

Establishing, by the first MC service client device, ad hoc group communication with the at least one second MC service client device using the generated security context includes: the method includes transmitting, by a first MC service client device to an MC service server, a generated security context of at least one second MC service client device, wherein the generated security context is transmitted by an ad hoc group communication security material request, and receiving, by the first MC service client device, an ad hoc group communication response from the MC service server to establish an ad hoc group communication with the at least one second MC service client device using the generated security context.

Transmitting, by the first MC service client device 100 to the MC service server, the generated security context of the at least one second MC service client device includes: encrypting, by the first MC service client device, the generated security context into a Unique Identifier (UID) associated with the at least one second MC service client device, encapsulating, by the first MC service client device, the encrypted security context of the at least one second MC service client device, and transmitting, by the first MC service client device, the encapsulated security context for the at least one second MC service client device to the MC service server.

The method comprises the following steps: determining, by the MC service server, whether ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request, one of the following operations performed by the MC service server: the ad hoc group communication request is accepted in response to determining that the ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request, and the list of invited second MC service client devices is verified based on the configured restrictions, or rejected in response to determining that the ad hoc group communication is not supported and successfully authorized by the MC service server based on the received ad hoc group communication request.

The method comprises the following steps: transmitting, by the MC service server, an ad hoc group communication request message to the at least one second MC service client device along with the generated security context to notify about the ad hoc group communication, wherein the MC service server removes a list of block sharing participants associated with the at least one second MC service client device and a list of MC service group Identifications (IDs) of the at least one second MC service client device that need to be acknowledged, and when the at least one second MC service client device accepts the ad hoc group communication request message, receiving, by the MC service server, an ad hoc group communication response from the at least one second MC service client device, wherein the ad hoc group communication response includes a functional alias of the at least one responding second MC service client device, determining, by the MC service server, whether the received ad hoc group communication response was received within a configured time, one of the following operations is performed by the MC service server: responsive to determining that the received ad hoc communication response was not received within the configured time, discarding the ad hoc communication, responsive to determining that the received ad hoc communication response was received within the configured time, sending the received ad hoc communication response to the first MC service client device to establish the ad hoc communication with the at least one second MC service client device using the generated security context.

The ad hoc group communication includes one or more preconditions, wherein the MC service server authorizes the first MC service client device and the authorized first MC service client device invites the at least one second MC service client device to establish the ad hoc group communication; wherein at least one second MC service client device is invited for ad hoc group communication within the limits of the non-preconfigured method, wherein the ad hoc group communication supports end-to-end encryption, and wherein the authorized first MC service client device has a security context for the at least one second MC service client device for ad hoc group communication.

A method for controlling ad hoc group communications using a security context for a Mission Critical (MCX) service, wherein the method comprises: receiving, by the MC service server, an ad hoc group communication request message from a first MC service client device to establish an ad hoc group communication with at least one second MC service client device, determining, by the MC service server, whether the ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request, one of the following operations performed by the MC service server: responsive to determining that ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request, accepting the ad hoc group communication request, and verifying the list of invited second MC service client devices based on the configured restrictions, or responsive to determining that ad hoc group communication is not supported and successfully authorized by the MC service server based on the received ad hoc group communication request, rejecting the ad hoc group communication request, receiving, by the MC service server, a security context for at least one second MC service client device of the ad hoc group communication.

The method further comprises the steps of: transmitting, by the MC service server, an ad hoc group communication request message to the at least one second MC service client device along with the generated security context to notify the ad hoc group communication, wherein the MC service server removes a list of block sharing participants associated with the at least one second MC service client device and a list of MC service group Identifications (IDs) of the at least one second MC service client device that need to be acknowledged, and when the at least one second MC service client device accepts the ad hoc group communication request message, receiving, by the MC service server, an ad hoc group communication response from the at least one second MC service client device, wherein the ad hoc group communication response includes a functional alias of the at least one responding second MC service client device, determining, by the MC service server, whether the received ad hoc group communication response was received within a configured time, one of the following operations is performed by the MC service server: responsive to determining that the received ad hoc communication response is not received within the configured time, the ad hoc communication is aborted, or responsive to determining that the received ad hoc communication response is received within the configured time, the received ad hoc communication response is sent to the first MC service client device to establish the ad hoc communication with the at least one second MC service client device using the generated security context.

There is provided a method for controlling ad-hoc (ad-hoc) group communication using a security context for a Mission Critical (MCX) service, wherein the method comprises: detecting, by the MC service server, an ongoing ad hoc communication between the first MC service client device and the at least one second MC service client device, receiving, by the MC service server, a modify ad hoc call participant request message from the first MC service client device, wherein the modify ad hoc call participant request message includes modification information, determining, by the MC service server, whether the first MC service client device is authorized to modify the participant list of the detected ongoing ad hoc communication, modifying, by the MC service server, the participant list by performing at least one action based on the received modification information, and notifying, by the MC service server, at least one of the first MC service client device and the at least one second MC service client device of the modified participant list of the at least one second MC service client device.

The modification information indicates at least one of: the method includes removing at least one second MC service client device from the detected ongoing ad hoc group communication and adding a new MC service client device to the detected ongoing ad hoc group communication.

Modifying, by the MC service server, the participant list based on the received modification information includes: the method further includes sending, by the MC service server, an ad hoc group communication leave request to the at least one second MC service client device based on the modification information to remove the at least one second MC service client device from the detected ongoing ad hoc group communication, receiving, by the MC service server, an ad hoc group call leave response from the at least one modified second MC service client device, and removing, by the MC service server, the at least one modified second MC service client device from the detected ongoing ad hoc group communication upon receipt of the ad hoc group call leave response.

Modifying, by the MC service server, the participant list based on the received modification information includes: transmitting, by the MC service server, an ad hoc group call communication request to the new MC service client device based on the modification information to add the new MC service client device to the detected ongoing ad hoc group communication, wherein the ad hoc group call communication request includes at least one of a security context of the new MC service client device, an ad hoc group identification of the detected ongoing ad hoc group communication, and a session identification, receiving, by the MC service server, an ad hoc group communication response from the new MC service client device, and adding, by the MC service server, the new MC service client device to the detected ongoing ad hoc group communication.

The at least one action includes one of: the method includes re-joining, by the MC service server, the first MC service client device to the detected ongoing ad hoc communication, re-joining, by the MC service server, the at least one second MC service client device to the detected ongoing ad hoc communication, and releasing, by the MC service server, the detected ongoing ad hoc communication.

A first Mission Critical (MC) service client device for controlling ad-hoc (ad-hoc) group communication using a security context for a Mission Critical (MCX) service is provided, and includes a memory, a processor, and an ad-hoc controller operatively connected to the memory and the processor and configured to send an ad-hoc communication request message to an MC service server to establish ad-hoc communication with at least one second MC service client device, wherein the MC service server determines whether ad-hoc communication is supported and successfully authorized based on the received ad-hoc communication request, receives an ad-hoc communication request return message from the MC service server when the ad-hoc communication is supported and successfully authorized, generates a security context for the at least one second MC service client device for the ad-hoc communication, and establishes ad-hoc communication with the at least one second MC service client device using the generated security context.

There is provided a Mission Critical (MC) service server for controlling ad-hoc (ad-hoc) group communications using a security context for a Mission Critical (MCX) service, and the MC service server comprising a memory, a processor, and an ad-hoc group controller operatively connected to the memory and the processor and configured to receive an ad-hoc group communication request message from a first MC service client device to establish an ad-hoc group communication with at least one second MC service client device, determine whether the ad-hoc group communication is supported and successfully authorized based on the received ad-hoc group communication request, perform one of the following: responsive to determining that ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request, accepting the ad hoc group communication request, and verifying the list of invited second MC service client devices based on the configured restrictions, or responsive to determining that ad hoc group communication is not supported and successfully authorized by the MC service server based on the received ad hoc group communication request, rejecting the ad hoc group communication request, receiving, by the MC service server, a security context for at least one second MC service client device of the ad hoc group communication.

The ad hoc group controller is configured to send an ad hoc group communication request message to the at least one second MC service client device along with the generated security context to notify about the ad hoc group communication, wherein the MC service server removes a list of block sharing participants associated with the at least one second MC service client device and a list of MC service group Identifications (IDs) of the at least one second MC service client device that need to be acknowledged, receives an ad hoc group communication response from the at least one second MC service client device when the at least one second MC service client device accepts the ad hoc group communication request message, wherein the ad hoc group communication response includes a functional alias of the at least one responding second MC service client device, determines whether the received ad hoc group communication response was received within a configured time, performing one of: responsive to determining that the received ad hoc communication response is not received within the configured time, the ad hoc communication is aborted, or responsive to determining that the received ad hoc communication response is received within the configured time, the received ad hoc communication response is sent to the first MC service client device to establish the ad hoc communication with the at least one second MC service client device using the generated security context.

A Mission Critical (MC) service server for controlling ad-hoc (ad-hoc) group communications using a security context for a Mission Critical (MCX) service is provided, and includes a memory, a processor, and an ad-hoc group controller operatively connected to the memory and the processor and configured to detect an ongoing ad-hoc group communication between a first MC service client device and at least one second MC service client device, receive a modify ad-hoc group call participant request message from the first MC service client device, wherein the modify ad-hoc group call participant request message includes modification information, determine whether the first MC service client device is authorized to modify a participant list of the detected ongoing ad-hoc group communication, modify the participant list by performing at least one action based on the received modification information, and notify at least one of the first MC service client device and the at least one second MC service client device of the modified participant list of the at least one second MC service client device.

The embodiments disclosed herein may be implemented using at least one hardware device and performing network management functions to control elements.

The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Thus, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the scope of the embodiments described herein.

Claims

1. A method for controlling ad hoc group communications using a security context for a mission critical (MCX) service, wherein the method comprises:

The first MC service client device sends a self-organizing group communication request message to the MC service server to establish a self-organizing group communication with at least one second MC service client device, wherein the MC service server determines whether the self-organizing group communication is supported and successfully authorized based on the received self-organizing group communication request;

When the self-organizing group communication is supported and successfully authorized, the first MC service client device receives a self-organizing group communication request return message from the MC service server;

generating, by the first MC service client device, a security context for the at least one second MC service client device for ad hoc group communication; and

The generated security context is used by the first MC service client device to establish an ad hoc group communication with the at least one second MC service client device.

2. The method of claim 1, wherein the self-organizing group communication request message comprises at least one of: a list of invited second MC service client devices, encryption support information, a list of block sharing participants associated with the at least one second MC service client device, an MC service group identifier (ID), MC service client media parameters, an indication of an implicit right-to-speak request, a functional alias, location information, an emergency indicator, and an imminent danger indicator.

3 . The method according to claim 1 , wherein the ad hoc group communication request return message includes at least one of an MC service group identification (ID) and authorization result information.

4 . The method of claim 1 , wherein the security context comprises at least one of an ad hoc group communication key (AGCK) and an ad hoc group communication key identifier (AGCK-ID).

5. The method of claim 1, wherein the first MC service client device uses the generated security context to establish an ad hoc group communication with the at least one second MC service client device comprises:

The first MC service client device sends the generated security context of the at least one second MC service client device to the MC service server, wherein the generated security context is sent by a self-organizing group communication security material request; and

An ad hoc group communication response is received by the first MC service client device from the MC service server to establish an ad hoc group communication with the at least one second MC service client device using the generated security context.

6. The method according to claim 1, wherein the first MC service client device 100 sends the generated security context of the at least one second MC service client device to the MC service server comprises:

encrypting, by the first MC service client device, the generated security context into a unique identifier (UID) associated with the at least one second MC service client device;

encapsulating, by the first MC service client device, an encrypted security context for the at least one second MC service client device; and

The encapsulated security context for the at least one second MC service client device is sent by the first MC service client device to the MC service server.

7. The method according to claim 1, wherein the method comprises:

The MC service server determines, based on the received ad hoc group communication request, whether the ad hoc group communication is supported and successfully authorized;

The MC service server performs one of the following operations:

In response to determining that ad hoc group communication is supported and successfully authorized based on the received ad hoc group communication request, accepting the ad hoc group communication request and verifying the list of invited second MC service client devices based on configured restrictions, or

In response to determining that the ad hoc group communication is not supported by the MC service server and is not successfully authorized based on the received ad hoc group communication request, rejecting the ad hoc group communication request.

8. The method according to claim 1, wherein the method comprises:

sending, by the MC service server, a self-organizing group communication request message together with the generated security context to the at least one second MC service client device to notify about the self-organizing group communication, wherein the MC service server removes a list of block sharing participants associated with the at least one second MC service client device and a list of MC service group identifications (IDs) of the at least one second MC service client device that needs to be confirmed;

When the at least one second MC service client device accepts the self-organizing group communication request message, the MC service server receives a self-organizing group communication response from the at least one second MC service client device, wherein the self-organizing group communication response includes a functional alias of at least one responding second MC service client device;

The MC service server determines whether the received self-organizing group communication response is received within the configured time;

The MC service server performs one of the following operations:

In response to determining that the received ad hoc group communication response is not received within a configured time, abandoning the ad hoc group communication, or

In response to determining that the received ad hoc group communication response is received within a configured time, sending the received ad hoc group communication response to the first MC service client device to establish ad hoc group communication with the at least one second MC service client device using the generated security context.

9. The method of claim 1, wherein the ad hoc group communication comprises one or more preconditions:

The MC service server authorizes the first MC service client device, and the authorized first MC service client device invites the at least one second MC service client device to establish self-organizing group communication;

wherein the at least one second MC service client device is invited for ad hoc group communication within the constraints of a non-preconfigured method;

Wherein, the self-organizing group communication supports end-to-end encryption; and

The authorized first MC service client device has a security context of the at least one second MC service client device used for the self-organizing group communication.

10. A method for controlling ad hoc group communications using a security context for a mission critical (MCX) service, wherein the method comprises:

The MC service server receives a self-organizing group communication request message from the first MC service client device to establish a self-organizing group communication with at least one second MC service client device;

The MC service server performs one of the following operations: and

in response to determining that the ad hoc group communication is not supported by the MC service server and is not successfully authorized based on the received ad hoc group communication request, rejecting the ad hoc group communication request;

A security context of the at least one second MC service client device for ad hoc group communication is received by the MC service server.

11. The method according to claim 10, wherein the method further comprises:

The MC service server performs one of the following operations:

12. A method for controlling ad-hoc group communications using a security context for a mission critical (MCX) service, wherein the method comprises:

The MC service server detects an ongoing ad hoc group communication between the first MC service client device and at least one second MC service client device;

The MC service server receives a request message for modifying a self-organizing group call participant from the first MC service client device, wherein the request message for modifying a self-organizing group call participant includes modification information;

Determining, by the MC service server, whether the first MC service client device is authorized to modify a list of participants in the detected ongoing ad hoc group communication;

The MC service server modifies the participant list by performing at least one action based on the received modification information; and

At least one of the first MC service client device and the at least one second MC service client device of the modified participant list is notified by the MC service server of the modified participant list of the at least one second MC service client device.

13. The method of claim 12, wherein the modification information indicates at least one of: removing the at least one second MC service client device from the detected ongoing ad hoc group communication, and adding a new MC service client device to the detected ongoing ad hoc group communication.

14. The method according to claim 12, wherein modifying the participant list based on the received modification information by the MC service server comprises:

The MC service server sends a self-organizing group communication leaving request to the at least one second MC service client device based on the modification information, so as to remove the at least one second MC service client device from the detected ongoing self-organizing group communication;

receiving, by the MC service server, an ad hoc group call leaving response from at least one modified second MC service client device; and

The at least one modified second MC service client device is removed from the detected ongoing ad hoc group communication by the MC service server upon receiving the ad hoc group call leaving response.

15. The method according to claim 12, wherein modifying, by the MC service server, the participant list based on the received modification information comprises:

The MC service server sends a self-organizing group call communication request to the new MC service client device based on the modification information to add the new MC service client device to the detected ongoing self-organizing group communication, wherein the self-organizing group call communication request includes at least one of the following items: a security context of the new MC service client device, a self-organizing group identifier of the detected ongoing self-organizing group communication, and a session identifier;

receiving, by the MC service server, an ad hoc group communication response from the new MC service client device; and

The new MC service client device is added by the MC service server to the detected ongoing ad hoc group communication.