Method and apparatus for file distribution in an ad-HOC group

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. A method performed by a mission critical data (MCData) client includes identifying whether to initiate standalone file distribution (FD); transmitting, to an MCData server, a first ad hoc group standalone FD request comprising at least one of information on an identity associated with MCData, information on an identity associated with a conversation, information on a payload, or information on a content reference; and receiving, from the MCData server, an ad hoc group standalone FD request return comprising information on a result of whether the first ad hoc group standalone FD request is authorized or not.

Description

METHOD AND APPARATUS FOR FILE DISTRIBUTION IN AN AD-HOC GROUP

[0001] The present disclosure relates to Mission Critical Data (MCData) service. Particularly, but not exclusively, the present disclosure relates to support of Ad-hoc group standalone File distribution (FD) using signaling control plane involving single MCData system and / or multiple MCData systems (using HTTP).

[0002] 5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in "Sub 6GHz" bands such as 3.5GHz, but also in "Above 6GHz" bands referred to as mmWave including 28GHz and 39GHz. In addition, it has been considered to implement 6G mobile communication technologies (referred to as Beyond 5G systems) in terahertz bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

[0003] At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive MIMO for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BWP (BandWidth Part), new channel coding methods such as a LDPC (Low Density Parity Check) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

[0004] Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as V2X (Vehicle-to-everything) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, NR-U (New Radio Unlicensed) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, NR UE Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

[0005] Moreover, there has been ongoing standardization in air interface architecture / protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, IAB (Integrated Access and Backhaul) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and DAPS (Dual Active Protocol Stack) handover, and two-step random access for simplifying random access procedures (2-step RACH for NR). There also has been ongoing standardization in system architecture / service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

[0006] As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting AR (Augmented Reality), VR (Virtual Reality), MR (Mixed Reality) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

[0007] Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using OAM (Orbital Angular Momentum), and RIS (Reconfigurable Intelligent Surface), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and AI (Artificial Intelligence) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

[0008] 5th generation (5G) or new radio (NR) mobile communications is recently gathering increased momentum with all the worldwide technical activities on the various candidate technologies from industry and academia. The candidate enablers for the 5G / NR mobile communications include massive antenna technologies, from legacy cellular frequency bands up to high frequencies, to provide beamforming gain and support increased capacity, new waveform (e.g., a new radio access technology (RAT)) to flexibly accommodate various services / applications with different requirements, new multiple access schemes to support massive connections, and so on.

[0009] The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.

[0010] The existing technologies support cases where a Mission Critical Data (MCData) user is initiating one-to-one or group file distribution using HTTP for sending the file content and file metadata information to other an MCData user or an MCData group respectively. In the mission critical services for the public safety and railways, some situations require sending of the file content and file metadata information to the MCData users, which are determined and combined to form an Ad-hoc group based on policies, criteria and any other conditions. Thus, there is a need to provide a mechanism for sharing the file content and the file metadata information to the MCData users of the Ad-hoc group.

[0011] The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0012] In line with development of the communication systems, there is a need for effective method for distributing a file to an Ad-hoc group.

[0013] The technical subjects pursued in the disclosure may not be limited to the above mentioned technical subjects, and other technical subjects which are not mentioned may be clearly understood, through the following descriptions, by those skilled in the art to which the disclosure pertains.

[0014] One or more shortcomings discussed above are overcome, and additional advantages and features are provided by the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the disclosure.

[0015] The present disclosure discloses a method and system of distributing a file to an Ad-hoc group. The method comprises receiving, from an MCData client of the Ad-hoc group, a standalone file distribution request to distribute the file among one or more other MCData clients of the Ad-hoc group and determining whether a user of the MCData client is authorized for distributing the file among the one or more other MCData clients of the Ad-hoc group. The method further comprises distributing the file among the one or more MCData clients of the Ad-hoc group, upon determination that the MCData client is authorized for distributing the file.

[0016] In an embodiment, a method of distributing a file to an Ad-hoc group, being performed by a Mission Critical Data (MCData) client of the Ad-hoc group is disclosed. The method comprises initiating a file distribution operation to distribute the file among one or more other MCData clients of the Ad-hoc group and sending a standalone file distribution request to an MCData server to distribute the file.

[0017] In another embodiment, the file distribution request comprises one or more of an identity of a user of the MCData client, an identity of the Ad-hoc group, a conversation identifier, a MCData transaction identifier, a payload destination type to indicate whether payload of the request is for application consumption or MCData user consumption and a Uniform Resource Locator (URL) of the file, wherein the file is stored on an MCData content server.

[0018] In yet another embodiment, the method further comprises requesting to store the file at an MCData content server prior to sending the file distribution request, wherein the file comprises at least one of text, media, and other data formats.

[0019] In yet another embodiment, the one or more other MCData clients of the Ad-hoc group belong to one or more MCData systems.

[0020] In yet another embodiment, a method of distributing a file to an Ad-hoc group, being performed by a Mission Critical Data (MCData) server is disclosed. The method comprises receiving, from an MCData client of the Ad-hoc group, a standalone file distribution request to distribute the file among one or more other MCData clients of the Ad-hoc group and determining whether a user of the MCData client is authorized for distributing the file among the one or more other MCData clients of the Ad-hoc group. The method further comprises distributing the file among the one or more MCData clients of the Ad-hoc group, upon determination that the MCData client is authorized for distributing the file.

[0021] In yet another embodiment, the file distribution request comprises one or more of an identity of a user of the MCData client, an identity of the Ad-hoc group, a conversation identifier, a MCData transaction identifier, a payload destination type to indicate whether payload of the request is for application consumption or MCData user consumption and a Uniform Resource Locator (URL) of the file, wherein the file is stored on an MCData content server.

[0022] In yet another embodiment, distributing the file among the one or more other MCData clients comprises sending a request, to the one or more other MCData clients, to retrieve the file from an MCData content server, wherein the request comprises an identity of the Ad-hoc group and an URL of the file, wherein the file comprises at least one of text, media, and other data formats.

[0023] In yet another embodiment, the request further comprises a time-to-live value for the Ad-hoc group, wherein the time-to-live value indicates a period after which the group ceases to exist.

[0024] In yet another embodiment, the one or more other MCData clients of the Ad-hoc group belong to one or more MCData systems.

[0025] In yet another embodiment, before receiving the file distribution request, the method comprises, receiving, from the MCData client, an Ad-hoc group determination request to determine the one or more other MCData clients of the Ad-hoc group and determining whether the first MCData client is authorized for sending the Ad-hoc group determination request. The method further comprises determining the one or more MCData clients based on the Ad-hoc group distribution request, upon determination that the MCData client is authorized for determining the Ad-hoc group and forming the Ad-hoc group including the first MCData client and the one or more other MCData clients. The method further comprises sending an Ad-hoc group determination response to the first MCData client, wherein the Ad-hoc group determination response comprises the identity of the Ad-hoc group and a list of identities of the one or more other MCData clients of the Ad-hoc group.

[0026] In yet another embodiment, a User Equipment (UE), having a Mission Critical Data (MCData) client, to distribute a file to an Ad-hoc group is disclosed. The UE comprises a memory and one or more processors coupled with the memory, wherein the one or more processors are configured to initiate a file distribution operation to distribute the file among one or more other MCData clients of the Ad-hoc group and send a standalone file distribution request to an MCData server to distribute the file.

[0027] In yet another embodiment, the file distribution request comprises one or more of an identity of a user of the MCData client, an identity of the Ad-hoc group, a conversation identifier, a MCData transaction identifier, a payload destination type to indicate whether payload of the request is for application consumption or MCData user consumption and a Uniform Resource Locator (URL) of the file, wherein the file is stored on an MCData content server.

[0028] In yet another embodiment, the one or more processors are further configured to request to store the file at an MCData content server prior to sending the file distribution request, wherein the file comprises at least one of text, media, and other data formats.

[0029] In yet another embodiment, the one or more other MCData clients of the Ad-hoc group belong to one or more MCData systems.

[0030] In yet another embodiment, a Mission Critical Data (MCData) server to distribute a file to an Ad-hoc group is disclosed. The MCData server comprises a memory and one or more processors coupled with the memory, wherein the one or more processors are configured to receive, from an MCData client of the Ad-hoc group, a standalone file distribution request to distribute the file among one or more other MCData clients of the Ad-hoc group and determine whether a user of the MCData client is authorized for distributing the file among the one or more other MCData clients of the Ad-hoc group. The one or more processors are further configured to distribute the file among the one or more MCData clients of the Ad-hoc group, upon determination that the MCData client is authorized for distributing the file.

[0031] In yet another embodiment, the file distribution request comprises one or more of an identity of a user of the MCData client, an identity of the Ad-hoc group, a conversation identifier, a MCData transaction identifier, a payload destination type to indicate whether payload of the request is for application consumption or MCData user consumption and a Uniform Resource Locator (URL) of the file, wherein the file is stored on an MCData content server.

[0032] In yet another embodiment, to distribute the file among the one or more other MCData clients, the one or more processors are configured to send a request, to the one or more other MCData clients, to retrieve the file from an MCData content server, wherein the request comprises an identity of the Ad-hoc group and an URL of the file, wherein the file comprises at least one of text, media, and other data formats.

[0033] In yet another embodiment, the request further comprises a time-to-live value for the Ad-hoc group, wherein the time-to-live value indicates a period after which the group ceases to exist.

[0034] In yet another embodiment, the one or more other MCData clients of the Ad-hoc group belong to one or more MCData systems.

[0035] In yet another embodiment, before receiving the file distribution request, the one or more processors are configured to receive, from the MCData client, an Ad-hoc group determination request to determine the one or more other MCData clients of the Ad-hoc group and determine whether the first MCData client is authorized for sending the Ad-hoc group determination request. The one or more processors are further configured to determine the one or more MCData clients based on the Ad-hoc group distribution request, upon determination that the MCData client is authorized for determining the Ad-hoc group and form the Ad-hoc group including the first MCData client and the one or more other MCData clients. The one or more processors are further configured to send an Ad-hoc group determination response to the first MCData client, wherein the Ad-hoc group determination response comprises the identity of the Ad-hoc group and a list of identities of the one or more other MCData clients of the Ad-hoc group.

[0036] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.

[0037] The present disclosure provides an effective and efficient method for distributing a file to an Ad-hoc group. Advantageous effects obtainable from the disclosure may not be limited to the above mentioned effects, and other effects which are not mentioned may be clearly understood, through the following descriptions, by those skilled in the art to which the disclosure pertains.

[0038] To easily identify the discussion of any particular element or act, the most significant digit(s) in a reference number refer(s) to the figure number in which that element is first introduced.

[0039] FIG. 1A illustrates an environment for file distribution to an Ad-hoc group, in accordance with an embodiment of the present disclosure.

[0040] FIG. 1B illustrates another environment for file distribution to an Ad-hoc group in accordance with an embodiment of the present disclosure.

[0041] FIG. 2 illustrates a sequence diagram for determining an Ad-hoc group for file distribution in accordance with an embodiment of the present disclosure.

[0042] FIG. 3 illustrates a sequence diagram for uploading a file to an MCData content server in accordance with an embodiment of the present disclosure.

[0043] FIG. 4 illustrates a sequence diagram for file distribution to the Ad-hoc group in accordance with an embodiment of the present disclosure.

[0044] FIG. 5 illustrates a sequence diagram for file distribution to the Ad-hoc group in accordance with an embodiment of the present disclosure.

[0045] FIG. 6 illustrates a block diagram of a User Equipment (UE) in accordance with an embodiment of the present disclosure.

[0046] FIG. 7 illustrates a block diagram of a primary MCData server in accordance with an embodiment of the present disclosure.

[0047] FIG. 8 illustrates a flow diagram of a method, performed by an MCData client, for file distribution in an Ad-hoc group in accordance with an embodiment of the present disclosure.

[0048] FIG. 9 illustrates a flow diagram of a method, performed by an MCData server, for file distribution in an Ad-hoc group in accordance with an embodiment of the present disclosure.

[0049] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of the　illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flowcharts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown.

[0050] In the mission critical services for the public safety and railways, requires an ad hoc group file distribution using HTTP, with support of the participants determined by the MCData server using criteria shared by the MCData user or participants shared by the initiating MCData user. The ad hoc group file distribution using HTTP involves the MCData users from single MCData system or multiple MCData system. The primary MCData system is responsible for handling the ad hoc group file distribution using HTTP. The initiating MCData user can provide the list of MCData user or criteria to determine the MCData users. If the criteria is provided by the MCData user, the primary MCData system will determine the MCData users based on the criteria and if any of the partner MCData systems are to be involved based on the agreement and criteria for determining the MCData users then all the involved partner MCData systems should provide the list of MCData users those who meet the criteria from their MCData system only one time. The list of MCData users provided by initiating MCData user may contain the MCData users from partner MCData system. The ad hoc group will be formed using determined / supplied list of MCData users and pre-configured MCData group is assigned to use the configurations from it (e.g. security materials). If the MCData user require uploading file to the MCData content server using network resources with required QoS, primary MCData system shall request the network resources with required QoS based on the access resource details provided by initiating MCData user. The primary MCData system returns the list of MCData users, ad hoc group ID and pre-configured MCData group for the configuration to be applied to the initiating MCData user. The initiating MCData user uploads the file and followed by initiates the ad hoc group file distribution using HTTP with determined list of MCData users, ad hoc group ID and pre-configured MCData group. Once the ad hoc group file distribution using HTTP completes then the ad hoc group is deleted from the MCData server. The deleting of ad hoc group can consider any local policies which are defined in the MCData system.

[0051] The present disclosure discloses various mechanism which helps in supporting the ad hoc group file distribution using HTTP, as listed below:

[0052] 1. The file distribution initiating MCData user determines the ad hoc group ID, pre-configured MCData group ID and the list of MCData users (based on the criteria specified or list of users provided). The MCData user requests the network resource with required QOS if required for the file upload.

[0053] 2. Support for the ad hoc group file distribution using HTTP based on the list of MCData users provided by the initiating MCData user or criteria to determine the list of MCData users.

[0054] 3. Support for one time determination of MCData users from partner MCData system if the partner MCData system is required to involve based on the criteria.

[0055] 4. Distribute the uploaded file link with the determined list of users from the ad hoc group.

[0056] 5. Support the disposition notification from MCData users of the ad hoc group.

[0057] 6. Clearing of ad　hoc group once the ad hoc group file distribution using HTTP completes the download of file content and file metadata along with the local polices if anything defined.

[0058] According to an embodiment, the Ad hoc group file distribution using HTTP is used to transfer the URL reference to the file content which was uploaded to the content server and file metadata information using either initiating MCData user provided list of MCData users or MCData server determined list of MCData users based on the criteria. If the end-to-end encryption is required for the Ad hoc group file distribution using HTTP the server will determine the appropriate pre-configured group which can be used by all the list of MCData users for securely receiving the URL reference to the file content which was uploaded to the content server and file metadata information.

[0059] The below presented table describes the information flow for determine ad hoc group request sent from the MCData client to the MCData server.

[0060]

[0061] Below table describes the information flow to determine ad hoc group response from the MCData server to the MCData client. This response is to provide the server assigned MCData ad hoc group ID and preconfigured group identity of preconfigured group from which the configurations to be used (e.g. security related information).

[0062]

[0063] Further, the table describes the information flow for the Ad hoc group standalone FD request sent from the MCData client to the MCData server.

[0064]

[0065]

[0066] The table describes the information flow for the Ad　hoc group standalone FD request sent from the MCData server to the MCData client.

[0067]

[0068]

[0069] Table　below describes the information flow for the Ad　hoc group standalone FD response sent from the MCData client to the MCData server and from the MCData server to another MCData client.

[0070]

[0071] Table below describes the information flow Ad　hoc group standalone FD get userlist from one MCData server to another MCData server.

[0072]

[0073] Table below describes the information flow Ad　hoc group standalone FD get userlist response from one MCData server to another MCData server.

[0074]

[0075] The present disclosure describes about determining the MCData ad hoc group ID and preconfigured group identity of preconfigured group from which the configurations to be used (e.g. security related information), and also to request network resources with the required QoS for the corresponding file upload by MCData server. There are following preconditions:

[0076] 1. The MCData users belong to primary MCData system and partner MCData system and already registered for receiving MCData service. The selection of MCData IDs of the ad　hoc group members receiving the file can be manual or from the user profile configuration data or by any other means. This is left for the implementation.

[0077] 2. Number of ad　hoc group members receiving the file should be within the configured limit.

[0078] 3. If the MCData client require uploading file to the MCData content server using network resources with required QoS, the MCData client knows its IP address / port to be used for the file upload as well as the URI or IP address / port of the target MCData content server.

[0079] The user at MCData client　1 may want to initiate standalone file distribution to multiple MCData users with / without end-to-end encryption supported, with / without request for network resources with required QOS, and either by providing the list of MCData users in the request or by providing the certain criteria in the request.

[0080] The MCData client　1 may send a Determine ad　hoc group request towards the MCData server of the primary MCData system. The Determine ad　hoc group request contains either the criteria to be applied by the MCData server of the primary MCData system for determining the list of MCData users or the list of MCData users as selected by the user at MCData client　1. The request may also contain the indicator for file distribution is for emergency, imminent peril and ad　hoc group file distribution support requires end-to-end encryption. This request may also contains information about the MCData client (including IP address and port to be used for the file upload), and the target MCData content server (including associated URI or IP address, and port), if the network resources with required QoS are required for file upload.

[0081] If the ad hoc group communication is supported, the MCData server of the primary MCData system checks whether the MCData user at MCData client 1 is authorized to initiate a Determine ad hoc group request. If not authorized, the MCData server rejects the Determine ad　hoc group request as specified in the step　9 with an appropriate error response. If the request contains list of MCData users as selected by the user at MCData client　1, the MCData server of the primary MCData system validates whether the number of MCData users provided in the request are within the configured limit. If not within the configured limit, the MCData server rejects the Determine ad　hoc group request as specified in the step　9 with an appropriate error response.

[0082] If request contains the criteria, the MCData server of primary MCData system determines the list of MCData users from the primary MCData system and determines that the partner MCData system to be involved in the ad　hoc group standalone file distribution based on the criteria and according to local policy if required. This information element to determine the ad　hoc group member contains the criteria, indicator identifying pre-defined criteria, or a combination of both. The values of criteria, indicator identifying pre-defined criteria and determining the list of participants using these values by MCData server may be as per implementation.

[0083] The MCData server of primary MCData system involves the partner MCData system based on the agreement, based on the criteria for determining the list of MCData users, and according to local policy if required. It sends the Ad　hoc group standalone FD get userlist request to the MCData server of partner MCData system. This request carries the criteria received in the Determine ad　hoc group request.

[0084] The MCData server of partner MCData system determines the list of MCData users satisfying the criteria and sends the response containing the list of MCData users satisfying the criteria. The MCData server of partner MCData system may apply local policies if any while determining the participants satisfying the criteria. The determination of list of MCData users is performed only once.

[0085] The MCData server of primary MCData system compiles the list of MCData users for ad　hoc group standalone file distribution from primary MCData system and from partner MCData system, if requested. The step　4 to step　7 are applicable if the request contains the criteria for determining the ad　hoc group members from primary system and may be from partner system.

[0086] The MCData server of the primary MCData system forms the ad　hoc group by using MCData users' information received in the Determine ad　hoc group request and list of MCData users to be part of ad　hoc group. The MCData server further determines the preconfigured group to be used for the configuration (e.g. security related information) of the ad　hoc group if end-to-end encryption is required. The MCData server selects an MCData ad　hoc group ID for the newly formed ad　hoc group and optionally assign the time to live value. The MCData server ensure the list of MCData users determined in the step　7 are within the configured limit.

[0087] If the request contains information about the MCData client (including IP address and port to be used for the file upload), and the target MCData content server (including associated URI or IP address, and port), the MCData server sends a request to the 3GPP system for the allocation of network resources with the required QoS for the corresponding file upload communication between the MCData client and the MCData content server. For that, the MCData server performs policy and charging control (PCC) procedures, e.g., over the Rx reference point as described in 3GPP　TS　23.203

[0014] for the case of an EPS system. The MCData client provides to the MCData server an MCData file upload completion status indicating that the file upload is completed. Based on the MCData file upload completion status, the MCData server requests to the 3GPP system to release the network resources allocated for the corresponding file upload.

[0088] The MCData server of the primary MCData system send the Determine ad hoc group response message to MCData client　1 containing the below:

[0089] i. The MCData ad　hoc group ID (only included when the Determine ad　hoc group request is successful);

[0090] ii. The MCData group ID of the pre-configured group whose configuration is to be applied for this Ad　hoc group standalone file distribution if end-to-end encryption is required (only included when the Determine ad　hoc group request is successful);

[0091] iii. Indication whether the file upload to the MCData content server can proceed or not; and

[0092] iv. Result of whether the Determine ad　hoc group request successful or failure.

[0093] If the Determine ad　hoc group request not authorized or result not successful, the MCData client　1 shall not proceed with the file distribution.

[0094] The present disclosure describes standalone file distribution to an Ad hoc group involving single MCData system.

[0095] The present disclosure describes standalone file distribution to an Ad hoc group involving multiple MCData system.

[0096] Information flows for Ad hoc group standalone file distribution using HTTP:

[0097] 1: Ad　hoc group standalone FD request (MCData client - MCData server)

[0098] Table　-A describes the information flow for the Ad　hoc group standalone FD request sent from the MCData client to the MCData server.

[0099]

[0100]

[0101] Ad hoc group standalone FD request (MCData server - MCData client)

[0102] Table B describes the information flow for the Ad hoc group standalone FD request sent from the MCData server to the MCData client.

[0103]

[0104]

[0105] Ad　hoc group standalone FD request return (MCData server - MCData client)Table　C describes the information flow Ad　hoc group standalone FD request return from the MCData server to the MCData client.

[0106]

[0107] Ad　hoc group standalone FD response (MCData client - MCData server, MCData server - MCData client):

[0108] Table　D describes the information flow for the Ad　hoc group standalone FD response sent from the MCData client to the MCData server and from the MCData server to another MCData client.

[0109]

[0110] Detailed Procedures for Ad hoc group standalone file distribution using HTTP:

[0111] 3. Ad　hoc group standalone file distribution using HTTP involving single MCData system

[0112] General:

[0113] The initiation of Ad hoc group standalone file distribution using HTTP results in ad hoc group members from single MCData system receiving the file data.

[0114] Procedure:

[0115] The procedure describes the case where an MCData user is initiating ad hoc group standalone file distribution to multiple MCData users, with or without download completed report request from the MCData user.

[0116] The present disclosure describes standalone file distribution to an Ad hoc group involving single MCData system.

[0117] Pre-conditions:

[0118] 1. The MCData users on MCData clients　1 to n belong to the same MCData system and are already registered for receiving MCData service.

[0119] 2. Number of ad　hoc group members receiving the file data is within the configured limit.

[0120] 3. The MCData client　1 may have an activated functional alias to be used.

[0121] 4. The file to be distributed is uploaded to the media storage function on the MCData content server using the procedures defined in subclause　7.5.2.2 of TS 23.282. The ad hoc group identity and preconfigured group identity of preconfigured group from which the configurations to be used (e.g. security related information) are determined using the procedures defined in subclause 7.17.6.2.1 of TS 23.282.

[0122] 5. The preconfigured group identity and preconfigured group configuration (e.g. security related information) to be used for an ad　hoc group have been preconfigured in the MCData client　1 and other MCData clients of ad　hoc group have also received the relevant security related information.

[0123] Steps:

[0124] 1. The user at MCData client　1 wants to initiate standalone file distribution to ad　hoc group members from primary MCData system.

[0125] 2. The MCData client　1 sends an Ad　hoc group standalone FD request towards the MCData server. The request shall contain the MCData ad　hoc group ID, the conversation identifier for message thread indication, may include additional implementation specific information in the application metadata container, and may include associated functional alias of the user at MCData client　1. If end-to-end encryption is required, the request shall contain the Preconfigured MCData group ID. The request contains content payload in the form of file URL and may contain the file metadata information. If MCData user at MCData client　1 has requested to mandatory download at the recipient side, then the request contains mandatory download indication. The request may contain a download completed report indication if selected by the user at MCData client　1. If the MCData user at MCData client　1 has requested to deposit the file content into his / her MCData message store account, then the request contains deposit file indication set.

[0126] If the MCData user at MCData client　1 initiates an emergency ad　hoc group standalone file distribution or the MCData emergency state is already set for the MCData client　1 (due to a previously triggered MCData emergency alert):

[0127] i) the Ad　hoc group standalone FD request shall contain an emergency indicator;

[0128] ii) if the MCData emergency state is not set already, MCData client　1 sets its MCData emergency state. The MCData emergency state is retained until explicitly cancelled; and

[0129] iii) once an emergency file distribution has been initiated, the ad　hoc group is considered to be in an in-progress emergency state until file distribution is completed and the time to live value of ad　hoc group expires.

[0130] If the MCData user at MCData client　1 initiates an imminent peril ad　hoc group standalone file distribution:

[0131] i) the Ad　hoc group standalone FD request shall contain imminent peril indicator; and

[0132] ii) once an emergency file distribution has been initiated, the ad　hoc group is considered to be in an in-progress imminent peril state until file distribution is completed and the time to live value of ad　hoc group expires.

[0133] 3. If the ad hoc group communication is supported, the MCData server checks whether the MCData user at MCData client　1 is authorized to send Ad　hoc group standalone FD request. The MCData server checks whether any policy is to be asserted to limit certain types of message or content to certain members, for example, to location or user privilege. The MCData server also verifies whether the provided functional alias can be used and has been activated for the user.

[0134] 4. The MCData server sends the Ad　hoc group standalone FD request return to the MCData user at MCData client　1 containing the result of whether the Ad　hoc group standalone FD request is authorized or not. If the Ad　hoc group standalone FD request is not authorized, the MCData server and the MCData client　1 shall not proceed with the rest of the steps.

[0135] 5. The MCData server considers the ad　hoc group members as implicitly affiliated to the ad　hoc group.

[0136] i) If an emergency indicator is present in the received Ad　hoc group standalone FD request and if the ad　hoc group is not in the in-progress emergency state, the ad　hoc group is considered to be in the in-progress emergency state until file distribution is completed and the time to live value of ad　hoc group expires; and

[0137] ii) If an imminent peril indicator is present in the received Ad　hoc group standalone FD request and if the ad　hoc group is not in the in-progress imminent peril state, the ad　hoc group is considered to be in the in-progress imminent peril state until file distribution is completed and the time to live value of ad　hoc group expires.

[0138] 6. The MCData server may verify whether the corresponding file is available in the MCData content server (not shown in the figure) via the MCData-FD-5 reference point using the received file URL in the request. For that, the MCData server sends an MCData file availability request to the MCData content server. Upon the receipt of the request, the MCData content server provides an MCData file availability response to the MCData server. If the MCData server identifies that the file is not available in the MCData content server, the MCData server provides a response to the MCData client　1 indicating that the file distribution request cannot proceed due to the unavailability of the file in the MCData content server and skip rest of the steps. If the deposit file indication information element is set to true in the received request, the MCData server shall follow the procedure as defined in the subclause　7.13.3.8 with the retrieve file indication element set to true while depositing this MCData communication to the MCData message store account of the user at MCData client　1.

[0139] 7. The MCData server initiates the Ad　hoc group standalone FD request towards each of the target MCData users. While sending the Ad　hoc group standalone FD request, the MCData server shall remove the information elements that are not required to be conveyed to the target MCData clients (e.g. MCData ID list). The request should contain the ad　hoc group ID, pre-configured group if end-to-end encryption is required and time to live value for the ad　hoc group. The primary MCData server removes the ad　hoc group information from the dynamic data once the time to live value is expired and thus the ad　hoc group ceases to exist then the procedure stops. If the deposit file indication information element is set to true in the received MCData FD request, MCData server shall follow the procedure as defined in the subclause　7.13.3.8 with the retrieve file indication element set to true while depositing this MCData communication to the MCData message store account of the user at MCData client　1.

[0140] 8. The receiving MCData clients　2 to N notify the user about the incoming Ad　hoc group standalone FD request (including file metadata, if present) which may be either accepted or rejected or ignored.

[0141] 9. If the target MCData user on MCData clients　2 to n provides a response (accept or reject) to the notification, then respective MCData client sends the Ad　hoc group standalone FD response to the MCData server. The MCData client　2 to n automatically sends accepted Ad　hoc group standalone FD response when the incoming request included mandatory download indication.

[0142] 10. The MCData server forwards the Ad　hoc group standalone FD response to the MCData client　1.

[0143] 11. The receiving MCData clients　2 to n download the file followed by providing download completed reports for reporting file download completed using the procedure as described in the step　9 to step　12 of subclause　7.5.2.6.

[0144] 12. On receiving download completed reports from MCData clients　2 to n or time to live value is expired, the MCData server removes the ad hoc group information from the dynamic data held in the MCData server and the ad　hoc group ceases to exist.Ad　hoc group standalone file distribution using HTTP involving multiple MCData system:

[0145] General:

[0146] The initiation of Ad　hoc group standalone file distribution using HTTP results in ad　hoc group members from multiple MCData system receiving the file data.

[0147] Procedure:

[0148] The procedure describes the case where an MCData user is initiating ad　hoc group standalone file distribution to multiple MCData users, with or without download completed report request from the MCData user.The present disclosure describes standalone file distribution to an Ad hoc group involving multiple MCData system.

[0149] Pre-conditions:

[0150] 1. The security aspects of sharing the user information between primary and partner MCData systems shall be governed as per the service provider agreement between them. In this case, it is considered that the partner MCData system share their users' information to the primary MCData system.

[0151] 2. MCData users on MCData clients 1 to M belong to the primary MCData system and MCData users on MCData clients 1 to N belong to the partner MCData system and are already registered for receiving MCData service.

[0152] 3. The MCData server of the primary MCData system is where the authorized MCData user / dispatcher creates the ad　hoc group.

[0153] 4. Number of ad　hoc group members receiving the file data is within the configured limit.

[0154] 5. The file to be distributed is uploaded to the media storage function on the MCData content server using the defined procedures. The ad hoc group identity and preconfigured group identity of preconfigured group from which the configurations to be used (e.g. security related information) are determined using the defined procedures.

[0155] 6. The preconfigured group identity and preconfigured group configuration (e.g. security related information) to be used for an ad　hoc group have been preconfigured in the MCData client and other MCData users of ad　hoc group have also received the relevant security related information.

[0156] Steps:

[0157] 1. The user at MCData client　1 of the primary MCData system wants initiate standalone file distribution to ad　hoc group members from primary and partner MCData systems.

[0158] 2-6. Same steps as described in the steps　2 to 6 of subclause.

[0159] 7a-7b. The MCData server of the primary MCData system initiates an Ad　hoc group standalone FD request towards each of the target MCData users in the primary MCData system and the partner MCData system. While sending the Ad　hoc group standalone FD requests, the MCData server of the primary MCData system shall remove the information elements that are not required to be conveyed to the target MCData clients (e.g. MCData ID list). The request should contain the ad　hoc group ID, pre-configured group if end-to-end encryption is required and time to live value for the ad　hoc group. The primary MCData server removes the ad　hoc group information from the dynamic data once the time to live value is expired and thus the ad　hoc group ceases to exist then the procedure stops.

[0160] 8a-8b. The receiving MCData clients　2 to M and MCData clients　1 to N notify the user about the incoming Ad　hoc group standalone FD request (including file metadata, if present) which may be either accepted or rejected or ignored.

[0161] 9a-9b. If the target MCData user on MCData clients　2 to M and MCData clients　1 to N provides a response (accept or reject) to the notification, then respective MCData clients send the Ad　hoc group standalone FD response to the MCData server. The MCData clients　2 to M and MCData clients　1 to N automatically sends accepted Ad　hoc group standalone FD response when the incoming request included mandatory download indication.

[0162] 10a-10b. The MCData server forwards the Ad　hoc group standalone FD response to the MCData client　1.

[0163] 11a-11d. The receiving MCData clients　2 to M and MCData clients　1 to N download the file followed by providing download completed reports for reporting file download completed using the procedure as described in the step　9 to step　12 of subclause　7.5.2.6.

[0164] With respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application.　The various singular / plural permutations may be expressly set forth herein for sake of clarity.

[0165] For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the various embodiments and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates.

[0166] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are explanatory of the invention and are not intended to be restrictive thereof.

[0167] In the present document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.

[0168] While the disclosure　is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will be described in detail below. It should be understood, however, that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the spirit and the scope of the disclosure.

[0169] The terms "comprise", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device, or method that comprises a list of components or steps　does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a device or system or apparatus proceeded by "comprises... a" does not, without more constraints, preclude the existence of other elements or additional elements in the device or system or apparatus.

[0170] The terms like "at least one" and "one or more" may be used interchangeably throughout the description.　In the following detailed description of the embodiments of the disclosure, reference is made to the　accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense. In the following description, well known functions or constructions are not described in detail since they would obscure the description with unnecessary detail.

[0171] In the existing art, the MCData client can only send the file to another MCData client or a predetermined group of the MCData clients. The present disclosure relates to techniques to distribute a file in an Ad-hoc group. Particularly, the present disclosure provides method(s) and system(s) to determine an Ad-hoc group to which the file is to be distributed and to distribute file in the Ad-hoc group.

[0172] In the present disclosure, the term "Mission Critical Data (MCData)" relates to data associated with mission critical services like public safety, emergency services, healthcare, military, transportation, and critical infrastructure.

[0173] The term "MCData system" relates to a specialized data system designed to manage and prioritize critical data that is essential for high-stakes mission critical services where failure, delays, or interruptions could have severe consequences. In an example, an MCData system may be a security system for public safety, or a railway system of a region.

[0174] The term "MCData client" relates to a software application of a user equipment.

[0175] The term "Ad-hoc group" relates to a temporary group formed for distribution of file with other members to ensure public safety or to provide critical services. The Ad-hoc group ceases to exist or vanishes either after the file distribution process is completed or after a time period determined by an Ad-hoc group forming entity.

[0176] The terms like "MCData server", "primary MCData server", "primary server" "server" are same and may be used interchangeably throughout the description. The primary MCData server may be the Ad-hoc group forming entity.

[0177] The terms like "partner MCData server" and "partner server" are same and may be used interchangeably throughout the description.

[0178] The terms like "MCData content server" and "content server" are same and may be used interchangeably throughout the description.

[0179] The terms like "MCData client(s)" and "client(s)" are same and may be used interchangeably throughout the description.

[0180] The terms like "MCData user(s)" and "user(s)" are same and may be used interchangeably throughout the description

[0181] FIG. 1A illustrates an environment 100A for file distribution to an Ad-hoc group in accordance with an embodiment of the present disclosure. The environment 100A may comprise various elements such a plurality of MCData clients 102a, 102b, ..., 102n and an MCData server 104. The plurality of MCData clients 102a, 102b, ..., 102n may be associated with a single MCData sy stem. In an embodiment, the MCData server 104 may communicate with the MCData client 102a over a communication network and may communicate with rest of the plurality of MCData clients 102b, 102c,..., 102n over another communication network. In another embodiment, the MCData server 104 may communicate with each MCData client among the plurality of MCData clients 102b, 102c,..., 102n over a separate communication network. In another embodiment, the MCData server 104 may communicate with each MCData client among the plurality of MCData clients 102a, 102b, 102c,..., 102n over a common communication network. The plurality of MCData clients 102a, 102b, 102c,..., 102n together may be form the Ad-hoc group.

[0182] The MCData client 102a may receive an input to initiate a standalone file distribution process in the Ad-hoc group. The input may be received from a user via a user interface of a user equipment having the MCData client 102a. The MCData client 102a may send a standalone file distribution request to the MCData server 104 to distribute the file among the plurality of clients 102b, 102c,..., 102n. In an embodiment, the MCData client 102a may store the file to be distributed on a MCData content server (not shown in figures). The file may be at least one of a media file, a text file, a binary content file, other data formats, and a combination thereof, but not limited thereto. In an embodiment, the file may captured by the user of the MCData client 102b using the user equipment in real-time or may be a pre-existing file.

[0183] Upon receiving the request, the MCData server 104 may authenticate the user of the MCData client 102a to determine whether the MCData client 102a (i.e., the user of the MCData client 102a) is authorized to distribute the file among the plurality of MCData clients 102b, 102c,..., 102n, or not. If the MCData server 104 determines that the MCData client 102a is not authorized to distribute the file among the plurality of MCData clients 102b, 102c,..., 102n, the MCData server 104 may not distribute the file among the plurality of MCData clients 102b, 102c, ..., 102n and terminate the process.

[0184] If the MCData server 104 determines that the MCData client 102a is authorized to distribute the file among the plurality of MCData clients 102b, 102c,..., 102n, the MCData server 104 may send a request to the plurality of clients 102b, 102c,..., 102n which contains the URL to the file stored at the MCData content server.

[0185] FIG. 1B illustrates an environment 100B for file distribution to an Ad-hoc group in accordance with another embodiment of the present disclosure. The environment 100B may comprise various elements such the MCData server 104, the plurality of MCData clients 102a, 102b, ..., 102n and a plurality of MCData clients 106a, 106b,..., 106n. The plurality of MCData clients 102a, 102b, ..., 102n may be associated with a first MCData system and the plurality of MCData clients 106a, 102b,..., 102n may be associated with a second MCData system. In an embodiment, the plurality of clients 106a, 106b,..., 106n may be associated with a single MCData system (the second MCData system). In an embodiment, the plurality of clients 106a, 106b,..., 106n may be associated with different MCData systems. The MCData server 104 may communicate with the MCData client 102a over a communication network. The MCData server 104 may communicate with the plurality of MCData clients 102b, 102c,..., 102n, and the plurality of MCData clients 106a, 106b,..., 106n over another communication network. In an embodiment, the MCData server 104 may communicate with each client among the plurality of MCData clients 102b, 102c,..., 102n, and the plurality of MCData clients 106a, 106b,..., 106n over a separate communication network. In an embodiment, the MCData server 104 may communicate with each MCData client among the plurality of MCData clients 102b, 102c,...,102n, and the plurality of MCData clients 106a, 106b,..., 106n over a common communication network. The plurality of clients 102a, 102b, ..., 102n, and the plurality of clients 106a, 106b, and 106n together may be form the Ad-hoc group.

[0186] The MCData client 102a may receive an input to initiate a standalone file distribution process to an Ad-hoc group. The input may be received from a user via a user interface of a user equipment having the MCData client 102a. The MCData client 102a may send the standalone file distribution request to the MCData server 104 to distribute the file among the plurality of MCData clients 102b, 102c,..., 102n and the plurality of MCData clients 106a, 106b,..., 106n. In an embodiment, the MCData client 102a may store the file to be distributed on a MCData content server (not shown in figures). The file may be at least one of a media file, a text file, a binary content file, other data formats, and a combination thereof, but not limited thereto. In an embodiment, the file may captured by the user of the MCData client 102b using the user equipment in real-time or may be a pre-existing file.

[0187] Upon receiving the request, the MCData server 104 may authenticate the MCData client 102a to determine whether the MCData client 102a is authorized to distribute the file among the plurality of MCData clients 102b, 102c,...,102n, and the plurality of MCData clients 106a, 106b,..., 106n, or not. If the MCData server 104 determines that the client 102a is not authorized to distribute the file, the MCData server 104 may not distribute the file among the plurality of MCData clients 102b, 102c,..., 102n, and the plurality of MCData clients 106a, 106b,..., 106n.

[0188] If the MCData server 104 determines that the MCData client 102a is authorized to distribute the file among the plurality of MCData clients 102b, 102c,..., 102n, and the plurality of MCData clients 106a, 106b,..., 106n, the MCData server 104 may send a request to the plurality of MCData clients 102b, 102c,..., 102n, and the plurality of MCData clients 106a, 106b, ..., 106n which contains the URL to the file stored at the MCData content server.

[0189] FIG. 2 illustrates a sequence diagram 200 for determining an Ad-hoc group for file distribution in accordance with an embodiment of the present disclosure. At step 2.1, the client 102a may receive an input to determine the Ad-hoc group from the user and may initiate the standalone file distribution process. The MCData client 102a may receive one or more information elements for the determination of the Ad-hoc group.

[0190] At step 2.2, the MCData client 102a may send an Ad-hoc group determination request to a primary MCData server 202. The MCData client 102a and the primary MCData server 202 may be associated with a MCData system. In an embodiment, the primary MCData server 202 may be same as the MCData server 104 illustrated in FIG. 1A and FIG. 1B. The Ad-hoc group determination request may contain one or more information elements as described in Table-1 below.Table-1: Ad-hoc group determination request

[0191] Information elementStatusDescriptionMCData IDMThe identity of the MCData user sending the requestFunctional aliasOThe associated functional alias of the MCData user sending request.Encryption supportedMIndicates whether ad　hoc group file distribution support requires end-to-end encryption.MCData user ID list(NOTE　1)OMCData user IDs for the ad　hoc group file distribution.Criteria for determining the participants(NOTE　1)OCarries the details of criteria or meaningful label identifying the criteria or the combination of both which will be used by the MCData server for determining the list of MCData users e.g., it can be a location-based criteria to file distribution in a particular area.Access information(NOTE　2)OProvides access resource details to be used by the MCData client for the file upload, e.g. IP address and portMCData content server information(NOTE　2)OProvides information about the target MCData content server, where the file is intended to be uploaded, e.g. URI or IP address, and port (e.g. standard port 80 for HTTP)Emergency indicator(NOTE　3)OIndicates that the request is for an MCData emergency communicationImminent peril indicator(NOTE　3)OIndicates that the request is for an MCData Imminent peril communicationNOTE　1: Only one of these information elements is present.NOTE　2: This element is included only when the network resources with required QoS are required.NOTE　3: If used, only one of these information elements shall be present.

[0192] The status 'M' indicates a mandatory determination parameter and the status 'O' indicates an optional determination parameter.

[0193] In an embodiment, the functional alias may a dynamic data associated with the user. The MCData client 102a may attach the functional alias with the user only if the user is authorized to define a functional alias. The functional alias may define one or more working parameters associated with the user such as shift time during which the user is working, or an area in which user is working.

[0194] In an embodiment, the Ad-hoc group determination request may comprise a list of one or more MCData users for the formation of the Ad-hoc group. The list of one or more MCData users may comprise one or more identities associated with the one or more MCData users selected by the user of client 102a to distribute the file. In an embodiment, the Ad-hoc group determination request may comprise one or more criteria to determine one or more MCData users for the formation of the Ad-hoc group.

[0195] At step 2.3, the primary MCData server 202 may authenticate the MCData client 102a to determine whether the MCData client 102a is authorized to initiate the Ad-group determination request or not. If the MCData client 102a is not authorized to initiate the Ad-group determination request, the primary MCData server 202 may reject the Ad-group determination request and may send an error response to the MCData client 102a. If the MCData client 102a is authorized to initiate the Ad-group determination request and if the Ad-group determination request comprises the list of users for the formation of the Ad-hoc group, the primary MCData server 202 may determine whether the number of the one or more MCData users comprised in the list is within a configured limit or not. If the number of the one or more MCData users comprised in the list is not within the configured limit, the primary MCData server 202 may reject the Ad-hoc group determination request and may send an error response to the MCData client 102a.

[0196] If the number of the one or more MCData users comprised in the list is within the configured limit, the primary MCData server 202 may form an Ad-group comprising the MCData client 102a and one or more MCData clients associated with the one or more MCData users comprised in the list and may skip the steps 2.4-2.7.

[0197] At step 2.4, if the Ad-hoc group determination request comprises the one or more criteria to determine the one or more MCData clients for the formation of the Ad-hoc group, the primary MCData server 202 may determine a list of the one or more MCData clients associated with a primary MCData system based the one or more criteria. In an embodiment, the one or more criteria may include a distance and functional alias, but not be limited thereto. Based on the distance criteria, the primary MCData server 202 may determine the one or more MCData clients located within the defined distance only. In an embodiment, when the one or more criteria the functional alias, the primary MCData server 202 may determine the one or more MCData clients with the same functional alias attached to them. The primary server 202 may also determine if a partner MCData system needs to be involved for the formation of the Ad-hoc group based on the one or more criteria.

[0198] At step 2.5, if the partner MCData system needs to be involved, the primary MCData server 202 may send a request "Get MCData userlist request" to a partner MCData server 204 associated with the partner MCData system to obtain a list of one or more MCData users associated with the partner MCData system satisfying the one or more criteria. The primary MCData system and the partner MCData system may be pre-configured to share data with each other based on an agreement and / or a local policy. The request sent by the primary MCData server 202 to the partner MCData server 204 may contain one or more information elements as described in Table-2 below.

[0199] Table-2: Get MCData userlist request

[0200] Information elementStatusDescriptionMCData ad　hoc group IDOThe MCData group ID of the ad　hoc group to which the file is to be sent.Criteria for determining the participantsMCarries the details of criteria or meaningful label identifying the criteria or the combination of both which will be used by the MCData server for determining the list of MCData users e.g., it can be a location-based criteria for standalone file distribution in a particular area.

[0201] The status 'M' indicates a mandatory information element.At step 2.6, the partner MCData server 204 may determine the list of the one or more MCData clients associated with the partner MCData system based the one or more criteria. The partner MCData server 204 may determine the list of the one or more MCData clients only once. The partner MCData server 204 may send a response "Get MCData userlist response" to the primary MCData server 202. The response may contain one or more information elements as described in Table-3 below.

[0202] Table-3: Get MCData userlist response

[0203] Information elementStatusDescriptionMCData ad　hoc group IDOThe MCData group ID of the ad　hoc group to which the file is to be sentMCData ID listMList of MCData IDs meeting the criteria specified in the Ad　hoc group standalone FD get userlist

[0204] The status 'M' indicates a mandatory information element.

[0205] At step 2.7, after receiving the response from the partner MCData server 204, the primary MCData server 202 may compile the list of the one or more MCData clients associated with the primary MCData system and the list of the one or more clients associated with the partner MCData system.

[0206] The steps　2.4 to 2.7 may only be performed if the Ad-hoc determination request contains a criterion for determining the one or more MCData clients for the Ad-hoc group from the primary MCData system and from the partner MCData system, if required.

[0207] At step 2.8, the primary MCData server 202 may form the Ad-hoc group by using the list of the one or more MCData clients received from the partner MCData server 204 and the list of the one or more MCData clients associated with the primary MCData system. The primary MCData server 202 may further determine a preconfigured group to be used for the configuration (e.g. security related information) of the Ad-hoc group if end-to-end encryption is required. The primary MCData server 202 may select an MCData Ad-hoc group ID for the newly formed Ad-hoc group and may also optionally assign a time-to-live value. The primary MCData server 202 may ensure the list of the one or more MCData clients associated with the partner MCData system is within the configured limit.

[0208] At step 2.9, if the Ad-hoc group determination request contains information about the MCData client 102a (including IP address and port to be used for the file upload) and the target MCData content server (including associated URI or IP address, and port), the primary MCData server 202 may send a request to a 3GPP system for the allocation of network resources with the required QoS for communication between the MCData client 102a and the MCData content server for uploading the file on the MCData content server.

[0209] At step 2.10, the primary MCData server 202 may send an Ad-hoc group determination response to the MCData client 102a. The Ad-hoc group determination response may contain one or more information elements as described in Table-4 below.

[0210] Table-4: Ad-hoc group determination response

[0211] Information ElementStatusDescriptionMCData IDMThe identity of the MCData user sending the requestMCData ad　hoc group ID(NOTE　1)OThe MCData group ID associated with the ad　hoc group file distribution that is generated and assigned by the MCData server.Preconfigured MCData group ID(NOTE　2)OThe identity of the MCData group whose configuration is to be applied for ad　hoc group file distribution.File upload confirmation(NOTE　3)OIndicates whether the file upload to the MCData content server can proceed or notResultMResult of the Determine ad　hoc group request (success or failure)Time to liveOIndicates how long the ad　hoc group is persisted and members can respond to the file distribution (e.g. duration for 5 mins or until certain future time).NOTE　1: If the result is success then this IE shall be includedNOTE　2: If the result is success and the end-to-end encryption is required, then this IE shall be included.NOTE　3: This element is included only when the network resources with required QoS are requested.

[0212] The status 'M' indicates a mandatory determination parameter and the status 'O' indicates an optional determination parameter. However, if the Ad-hoc group determination request is not authorized or the result is not successful, the MCData client　102a may not proceed with the file distribution.

[0213] FIG. 3 illustrates a sequence diagram 300 for uploading the file to an MCData content server 302 in accordance with an embodiment of the present disclosure. In an embodiment the MCData content server 302 may be same as the MCData content server described in conjunction with FIG. 1A and FIG. 1B.

[0214] At step 3.1, the MCData client 102a may send a file upload request to the MCData content server 302 to upload the file, to be distributed to the Ad-hoc group, at the MCData content server. The file may be an image file, a video file, an audio file, a text file, a binary content file, and a combination thereof, but not limited thereto. In an embodiment, the file may be generated by the user of the MCData client 102a. In an embodiment, the client 102a may upload more than one file on the MCData content server 302. The file may contain data associated with a mission critical service for which the MCData client 102a is working.

[0215] At step 3.2, the MCData content server 302 may store the file shared by the MCData client 102a and generate a Uniform Resource Locator (URL) of the location at which the file is stored. The file may be retrieved by using the URL of the location at which the file is stored.

[0216] At step 3.3, the MCData content server 302 may send a file upload response to the MCData client 102a. The file upload response may contain the URL of the location at which the file is stored. After uploading the file to the MCData content server 302, the MCData client 102a may provide, to the primary server 202, an MCData file upload completion status indicating that the file upload is completed. Based on the MCData file upload completion status, the primary server 202 may request the 3GPP system to release the network resources allocated for the corresponding file upload.

[0217] FIG. 4 illustrates a sequence diagram 400 for file distribution to the Ad-hoc group in accordance with an embodiment of the present disclosure. The Ad-hoc group may include the one or more users associated with the primary MCData system only. One or more clients of the one or more users, associated with the primary MCData system, may together be known as primary target MCData clients 402.

[0218] At step 4.1, the MCData client 102a may receive the input from the user to initiate the standalone file distribution process in the Ad-hoc group. The MCData client 102a may receive one or more information elements associated with the file distribution from the user. The one or more information elements may include an identity (ID) of the user, ID of the Ad-hoc group, URL of the file, and / or information about consumer of the file, but not limited thereto.

[0219] At step 4.2, the MCData client 102a may send a standalone File Distribution (FD) request (Ad-hoc group standalone FD request) to the primary server 202. The FD request may contain one or more information elements as described in Table-5 below.

[0220] Table-5: Ad-hoc group standalone FD request

[0221] Information elementStatusDescriptionMCData IDMThe identity of the MCData user sending the FD requestFunctional aliasOThe associated functional alias of the MCData user sending the FD requestMCData ad　hoc group ID(NOTE　1)MThe MCData group ID of the ad　hoc group to which the file is to be sentPreconfigured MCData group ID(NOTE　2)OThe identity of the MCData group whose configuration (e.g. security related information) is to be applied for ad　hoc group file distribution.Conversation IdentifierMIdentifies the conversationTransaction IdentifierMIdentifies the MCData transactionEmergency indicator(NOTE　3)OIndicates that the standalone file distribution request is for emergency ad　hoc group standalone file distribution serviceImminent peril indicator (NOTE　3)OIndicates that the standalone file distribution request is for imminent peril ad　hoc group standalone file distribution serviceDisposition indicationOIndicates whether file download completed report is expected or notDownload indicationOIndicates mandatory downloadLocationOLocation of the Originating MCData user sending the filePayload Destination TypeMIndicates whether the payload is for application consumption or MCData user consumptionApplication identifier (NOTE　4)OIdentifies the application for which the payload is intended (e.g. text string, port address, URI)Application metadata containerOImplementation specific information that is communicated to the recipientContent referenceMURL reference to the content and file metadata informationDeposit file indicationOIndicates whether the file to be stored into the MCData message store account of the MCData userTime to liveOIndicates how long the ad　hoc group is persisted and members can respond to the file distribution (e.g. duration for 5 mins or until certain future time).NOTE　1: The MCData ad　hoc group ID is determined prior to by using the Determine ad　hoc group request.NOTE　2: If end-to-end encryption is required, then this element is included and the value is determined prior to by using the Determine ad　hoc group request.NOTE　3: If used, only one of these information elements shall be present.NOTE　4: The application identifier shall be included only if the payload destination type indicates that the SDS message is for application consumption.

[0222] The status 'M' indicates a mandatory determination parameter, and the status 'O' indicates an optional determination parameter.If the MCData client 102a initiates an emergency Ad-hoc group standalone file distribution or the MCData emergency state is already set for the MCData client 102a (due to a previously triggered MCData emergency alert), then:

[0223] i. the Ad-hoc group standalone FD request may contain an emergency indicator;

[0224] ii. if the MCData emergency state is not set already, the MCData client 102a may set its MCData emergency state. The MCData emergency state may be retained until explicitly cancelled; and

[0225] iii. once an emergency file distribution has been initiated, the Ad-hoc group may be considered to be in an in-progress emergency state until file distribution is completed and the time-to-live value of Ad-hoc group expires.

[0226] If the MCData client 102a initiates an imminent peril Ad-hoc group standalone file distribution, then:

[0227] i. the Ad-hoc group standalone FD request may contain an imminent peril indicator; and

[0228] ii. once an emergency file distribution has been initiated, the Ad-hoc group may be considered to be in an in-progress emergency state until file distribution is completed and the time-to-live value of Ad-hoc group expires.

[0229] At step 4.3, if the Ad-hoc group communication is supported, the primary server 202 may check whether the user of the MCData client　102a is authorized to send the Ad-hoc group standalone FD request. The primary server 202 may check whether any policy is to be asserted to limit certain types of messages or content to certain members of the Ad-hoc group, for example, to location or user privilege. The primary server 202 may also verify whether the provided functional alias can be used and has been activated for the user.

[0230] At step 4.4, the primary server 202 may send an Ad-hoc group standalone FD request return to the MCData client　102a. The Ad-hoc group standalone FD request return may contain the result of whether the Ad-hoc group standalone FD request is authorized or not. If the Ad-hoc group standalone FD request is not authorized, the primary server 202 and the MCData client　102a may not proceed with the rest of the steps 4.5-4.11. The Ad-hoc group standalone FD request return may contain one or more information elements as described in Table-6 below.

[0231] Table-6: Ad-hoc group standalone FD request return

[0232] Information elementStatusDescriptionMCData IDMThe identity of the MCData user sending the FD requestFunctional aliasOThe associated functional alias of the MCData user sending the FD requestAuthorization resultMIndicate if authorization is success or failure

[0233] The status 'M' indicates a mandatory determination parameter, and the status 'O' indicates an optional determination parameter.At step 4.5, if the Ad-hoc group standalone FD request is authorized, the primary server 202 may consider the Ad-hoc group members as implicitly affiliated with the Ad-hoc group.

[0234] i. if an emergency indicator is present in the received Ad-hoc group standalone FD request and if the Ad-hoc group is not in the in-progress emergency state, the Ad-hoc group may be considered to be in the in-progress emergency state until file distribution is completed, and the time-to-live value of ad　hoc group expires; and

[0235] ii. if an imminent peril indicator is present in the received Ad-hoc group standalone FD request and if the Ad-hoc group is not in the in-progress imminent peril state, the Ad-hoc group may be considered to be in the in-progress imminent peril state until file distribution is completed, and the time-to-live value of ad　hoc group expires.

[0236] At step 4.6, the primary server 202 may verify whether the corresponding file is available at the MCData content server 302 via an MCData-FD reference point using the received URL of the file in the FD request. For that, the primary server 202 may send an MCData file availability request to the content server 302. Upon the receipt of the request, the MCData content server 302 may provide an MCData file availability response to the primary server 202. If the primary server 202 identifies that the file is not available in the MCData content server 302, the primary server 202 may provide a response to the MCData client　102a indicating that the file distribution request cannot proceed due to the unavailability of the file at the MCData content server 302 and skip rest of the steps 4.7-4.11. If the deposit file indication information element is set to true in the received FD request, the primary server 202 may deposit this MCData communication to an MCData message store account of the user at MCData client　102a.

[0237] At step 4.7, the primary server 202 may send the Ad-hoc group standalone FD request to the primary target MCData clients 402. While sending the Ad-hoc group standalone FD request, the primary server 202 may remove one or more information elements that are not required to be conveyed to the primary target MCData clients 402 (e.g. MCData ID list). The MCData ID list may be maintained by the primary server 202 when forming the Ad-hoc group. The Ad-hoc group standalone FD request, sent from the primary server 202 to the primary target MCData clients 402, may contain one or more information elements as described in Table-7 below.

[0238] Table-7: Ad-hoc group standalone FD request

[0239] Information elementStatusDescriptionMCData IDMThe identity of the MCData user sending the FD requestFunctional aliasOThe associated functional alias of the MCData user sending the FD requestMCData ad　hoc group IDMThe MCData group ID of the ad　hoc group to which the file is to be sentPreconfigured MCData group ID(NOTE　1)OThe identity of the MCData group whose configuration (e.g. security related information) is to be applied for ad　hoc group file distribution.MCData IDMThe identity of the MCData user towards which the FD request is sentConversation IdentifierMIdentifies the conversationTransaction IdentifierMIdentifies the MCData transactionEmergency indicator(NOTE　2)OIndicates that the standalone file distribution request is for emergency ad　hoc group standalone file distribution serviceImminent peril indicator (NOTE　2)OIndicates that the standalone file distribution request is for imminent peril ad　hoc group standalone file distribution serviceDisposition indicationOIndicates whether file download completed report is expected or notDownload indicationOIndicates mandatory downloadLocationOLocation of the Originating MCData user sending the filePayload Destination TypeMIndicates whether the payload is for application consumption or MCData user consumptionApplication identifier (NOTE　4)OIdentifies the application for which the payload is intended (e.g. text string, port address, URI)Application metadata containerOImplementation specific information that is communicated to the recipientContent referenceMURL reference to the content and file metadata informationTime to liveOIndicates how long the ad　hoc group is persisted and members can respond to the file distribution (e.g. duration for 5 mins or until certain future time).NOTE　1: If end-to-end encryption is required, then this element is included.NOTE　2: If used, only one of these information elements shall be present

[0240] The status 'M' indicates a mandatory determination parameter, and the status 'O' indicates an optional determination parameter.At step 4.8, the primary target MCData clients　402 may notify the one or more users of the primary target MCData clients 402 about the incoming Ad-hoc group standalone FD request (including file metadata, if present). The one or more users of the primary target MCData clients　402 may either accept or reject or ignore the Ad-hoc group standalone FD request.

[0241] At step 4.9, if the one or more users of the primary target MCData clients　402 provide a response (accept or reject) to the notification, then respective MCData client(s) may send an Ad-hoc group standalone FD response to the primary server 202. The primary target MCData clients　402 may automatically send accepted Ad-hoc group standalone FD response when the incoming request included mandatory download indication. The Ad-hoc group standalone FD response may contain one or more information elements as described in Table-8 below.

[0242] Table-8: Ad-hoc group standalone FD response

[0243] Information elementStatusDescriptionMCData ad　hoc group IDMThe MCData group ID of the ad　hoc group to which the file is to be sentMCData IDMThe identity of the MCData user sending FD responseConversation IdentifierMIdentifies the conversationResultMIndicates if the request is accepted or not

[0244] The status 'M' indicates a mandatory determination parameter.At step 4.10, the primary server 202 may send the Ad-hoc group standalone FD response received from the primary target MCData clients 402 to the client　102a.

[0245] At step 4.11, the primary target MCData clients　402 may download the file using the URL of the file. The primary target MCData clients 402 may provide download completed reports, for reporting file download completed, to the primary server 202. On receiving the download completed reports from the primary target MCData clients　402 or the time-to-live value is expired, the primary server 202 may remove the Ad-hoc group information from dynamic data held in the primary server 202 and the Ad-hoc group ceases to exist.

[0246] FIG. 5 illustrates a sequence diagram 500 for file distribution in the Ad-hoc group in accordance with an embodiment of the present disclosure. The Ad-hoc group may include the one or more users associated with the primary MCData system and the partner MCData system. One or more clients of the one or more users, associated with the partner MCData system, may together be known as partner target MCData clients 502.

[0247] Step 5.1 to step 5.6 of the sequence diagram 500 may be same as step 4.1 to step 4.6 of the sequence diagram 400, and the same has not been repeated for the sake of brevity.

[0248] At steps 5.7a and 5.7b, the primary server 202 may send the Ad-hoc group standalone FD request to the primary target MCData clients 402 and the partner target MCData clients 502 respectively. While sending the Ad-hoc group standalone FD request, the primary server 202 may remove the one or more information elements that are not required to be conveyed to the primary target MCData clients 402 and the partner target MCData clients 502 (e.g. MCData ID list). The Ad-hoc group standalone FD request, sent from the primary server 202 to the primary target MCData clients 402 and the partner target MCData clients 502, may contain the one or more information elements as described in the Table-7, the same has not been repeated for the sake of brevity.

[0249] At steps 5.8a and 5.8b, the primary target MCData clients　402 may notify the one or more users of the primary target MCData clients 402 and the partner target MCData clients　502 may notify the one or more users of the partner target MCData clients 502 respectively, about the incoming Ad-hoc group standalone FD request (including file metadata, if present). The one or more users of the primary target MCData clients　402 and the partner target MCData clients　502 may either accept or reject or ignore the Ad-hoc group standalone FD request.

[0250] At steps 5.9a and 5.9b, if the one or more users of the primary target MCData clients　402 and the one or more users of the partner target MCData clients　502 provide a response (accept or reject) to the notification, then respective MCData client may send the Ad-hoc group standalone FD response to the primary server 202. The primary target MCData clients　402 and the partner target MCData clients　502 may automatically send accepted Ad-hoc group standalone FD response when the incoming request included mandatory download indication. The Ad-hoc group standalone FD response may contain the one or more information elements as described in the Table-8, the same has not been repeated for the sake of brevity.

[0251] At steps 5.10a and 5.10b, the primary server 202 may send the Ad-hoc group standalone FD response received from the primary target MCData clients 402 and the partner target MCData clients 502 respectively to the client　102a.

[0252] At steps 5.11a and 5.11b, the primary target MCData clients　402 and the partner target MCData clients 502 may download the file using the URL of the file respectively.

[0253] At steps 5.12a and 5.12b, the primary target MCData clients 402 and the partner target MCData clients　502 may provide download completed reports, for reporting file download completed, to the primary server 202 and the MCData client 102a. On receiving the download completed reports from the primary target MCData clients　402 and the partner target MCData clients　502, or the time-to-live value is expired, the server primary 202 may remove the Ad-hoc group information from the dynamic data held in the primary server 202 and the Ad-hoc group ceases to exist.

[0254] FIG. 6 illustrates a block diagram of a User Equipment (UE) 600 in accordance with an embodiment of the present disclosure. The UE 600 may comprise an input / output (I / O) interface 602, processor(s) 604, a memory 606, a camera module 614, an audio module 616, and a text file module 618, but not limited thereto. The memory 606 may include the MCData client 102a and one or more modules 608 such as a receiving module 610, and a sending module 612, but not limited thereto. It will be appreciated that such aforementioned modules may be represented as a single module or a combination of different modules. The modules may be implemented in any suitable hardware, software, firmware, or combination thereof. Further the modules may be implemented by various techniques comprising but not limited to computer programs, one or more neural networks, machine learning algorithms, embedded systems design and cloud computing architectures.

[0255] The I / O interface 602 may be in communication with the primary server 202 to send one or more requests and receive one or more responses. The I / O interface 602may employ communication protocols / methods such as, without limitation, audio, analog, digital, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS / 2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE 802.n / b / g / n / x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE) or the like), etc.

[0256] The memory 606 may store one or more instructions for the operation of one or more functions of the UE 600. In an embodiment, the instructions stored in the memory 606may be processed by the one or more modules 608 of the UE 600. The one or more modules 608 and the MCData client 102a may be stored within the memory 606as shown in FIG. 6. The MCData client 102a and the one or more modules 608 may be communicatively coupled to each other. In an embodiment, the one or more modules 608 and the MCData client 102a, communicatively coupled to the processor(s) 604, may also be present outside the memory 606.The processor(s) 604 may execute the one or more instructions stored in the memory 606 to perform the one or more functions of the UE 600. The processor(s) may be communicatively coupled with the client 102a to perform one or more operations in the file distribution process. The MCData client 102a an interface for the user to interact with the processor(s) 604 to carry out the one or more operations of the file distribution process.

[0257] In an embodiment, the MCData client 102a may determine the Ad-hoc group and / or initiate the standalone file distribution process in the Ad-hoc group. The MCData client 102a may receive one or more information elements from the user for the determination of the Ad-hoc group. The sending module 612 may send the Ad-hoc group determination request to the primary server 202 via the I / O interface 602. The Ad-hoc group determination request may contain the one or more information elements as described in the Table-1, the same has not been repeated here for the sake of brevity.

[0258] The primary server 202 may authenticate the MCData client 102a to determine whether the MCData client 102a is authorized to initiate the Ad-group determination request or not. If the MCData client 102a is not authorized to initiate the Ad-group determination request, the primary server 202 may reject the Ad-group determination request and may send an error response to the MCData client 102a. If the client 102a is authorized to initiate the Ad-group determination request, the primary server 202 may form an Ad-hoc group based on the one or more information elements contained in the Ad-hoc group determination request as described in conjunction with the steps 2.3-2.9 of FIG.2, hence the same has not been repeated here for the sake of brevity.

[0259] After the formation of the Ad-hoc group, the receiving module 610 may receive the Ad-hoc group determination response from the primary server 202 via the I / O interface 602. The Ad-hoc group determination response may contain the one or more information elements as described in the Table-4, the same has not been repeated here for the sake of brevity. If the Ad-hoc group determination request is not authorized or the result is not successful, the MCData client　102a may not proceed with the file distribution.

[0260] The file to be distributed in the Ad-hoc group may be at least one of the image file, the video file, the audio file, or the text file, but not limited thereto. The file may be using the camera module of the UE 600. The audio file may be generated using the audio module 616 of the UE 600. The text file may be generated using the text file module 618 of the UE 600. The generated file may be stored in the memory 606.

[0261] The client 102a may retrieve the file from the memory 606 and upload the file to the MCData content server 302. The sending module 612 may send the file upload request to the MCData content server 302 to upload the file to the MCData content server 302. In an embodiment, more than one file may be uploaded to the MCData content server 302. The file may contain the data associated with the mission critical service for which the user of the client 102a is working.

[0262] The MCData content server 302 may store the file and generate the URL of the location at which the file is stored. The file may be retrieved by using the URL of the location at which the file is stored. The receiving module 610 may receive the file upload response from the MCData content server 302 via the I / O interface. The file upload response may contain the URL of the location at which the file is stored.

[0263] In an embodiment, the sending module 612 may send the File Distribution (FD) request (Ad-hoc group standalone FD request) to the primary server 202 for file distribution to the Ad-hoc group comprising the one or more users associated with the primary MCData system only. The FD request may contain the one or more information elements as described in the Table-5, the same has not been repeated for the sake of brevity. The primary server 202 may check whether the MCData client 102a (i.e., the user of the MCData client 102a) is authorized to send the Ad-hoc group standalone FD request. The primary server 202 may check whether any policy is to be asserted to limit certain types of messages or content to certain members of the Ad-hoc group, for example, to location or user privilege. The primary server 202 may also verify whether the provided functional alias can be used and has been activated for the user. The receiving module 610 may receive the Ad-hoc group standalone FD request return from the primary server 202 via the I / O interface 602. The Ad-hoc group standalone FD request return may contain the result of whether the Ad-hoc group standalone FD request is authorized or not. If the Ad-hoc group standalone FD request is not authorized, the primary server 202 and the MCData client　102a may not proceed with the file distribution. The Ad-hoc group standalone FD request return may contain the one or more information elements as described in the Table-6, the same has not been repeated for the sake of brevity.

[0264] If the Ad-hoc group standalone FD request is authorized, the primary server 202 may verify whether the corresponding file is available at the MCData content server 302 via the MCData-FD reference point using the received URL of the file in the FD request. If the availability of the file at the content server 302 is confirmed, the primary server 202 may send the Ad-hoc group standalone FD request to the primary target MCData clients 402. While sending the Ad-hoc group standalone FD request, the primary server 202 may remove one or more information elements that are not required to be conveyed to the primary target MCData clients 402 (e.g. MCData ID list). The Ad-hoc group standalone FD request, sent from the primary server 202 to the primary target MCData clients 402, may contain the one or more information elements as described in the Table-7, the same has not been repeated for the sake of brevity.

[0265] The primary target MCData clients　402 may notify the primary target MCData clients 402 (i.e., the one or more users of the primary target MCData clients 402) about the incoming Ad-hoc group standalone FD request (including file metadata, if present). The one or more users of the primary target MCData clients　402 may either accept or reject or ignore the Ad-hoc group standalone FD request. If the one or more users of the primary target MCData clients　402 provide the response (accept or reject) to the notification, then the respective MCData client(s) may send an Ad-hoc group standalone FD response to the primary server 202. The primary target MCData clients　402 may automatically send accepted Ad-hoc group standalone FD response when the incoming request included mandatory download indication. The Ad-hoc group standalone FD response may contain the one or more information elements as described in the Table-8, the same has been repeated for the sake of brevity. The receiving module 610 may receive the Ad-hoc group standalone FD response, received from the primary target MCData clients 402, from the primary server 202 via the I / O interface 602.

[0266] In an embodiment, the sending module 612 may send the File Distribution (FD) request to the primary server 202 for file distribution in the Ad-hoc group comprising the one or more users associated with the primary MCData system and the partner MCData system. The FD request may contain the one or more information elements as described in the Table-5, the same has not been repeated for the sake of brevity. The primary server 202 may check whether the user of the client 102a is authorized to send the Ad-hoc group standalone FD request. The primary server 202 may check whether any policy is to be asserted to limit certain types of messages or content to certain members of the Ad-hoc group, for example, to location or user privilege. The primary server 202 may also verify whether the provided functional alias can be used and has been activated for the user. The receiving module 610 may receive the Ad-hoc group standalone FD request return from the primary server 202 via the I / O interface 602. The Ad-hoc group standalone FD request return may contain the result of whether the Ad-hoc group standalone FD request is authorized or not. If the Ad-hoc group standalone FD request is not authorized, the primary server 202 and the MCData client　102a may not proceed with the file distribution. The Ad-hoc group standalone FD request return may contain the one or more information elements as described in the Table-6, the same has not been repeated for the sake of brevity. If the Ad-hoc group standalone FD request is authorized, the primary server 202 may verify whether the corresponding file is available at the MCData content server 302 via the MCData-FD reference point using the received URL of the file in the FD request.

[0267] The primary server 202 may send the Ad-hoc group standalone FD request to the primary target MCData clients 402 and the partner target MCData clients 502. While sending the Ad-hoc group standalone FD request, the primary server 202 may remove the one or more information elements that are not required to be conveyed to the primary target MCData clients 402 and the partner target MCData clients 502 (e.g. MCData ID list). The Ad-hoc group standalone FD request, sent from the primary server 202 to the primary target MCData clients 402 and the partner target MCData clients 502, may contain the one or more information elements as described in the Table-7, the same has not been repeated for the sake of brevity.

[0268] The primary target MCData clients　402 may notify the one or more users of the primary target MCData clients 402 and the partner target MCData clients　502 may notify the one or more users of the partner target MCData clients 502 respectively, about the incoming Ad-hoc group standalone FD request (including file metadata, if present). The one or more users of the primary target MCData clients　402 and the partner target MCData clients　502 may either accept or reject or ignore the Ad-hoc group standalone FD request. If the one or more users of the primary target MCData clients　402 and the one or more users of the partner target MCData clients　502 provide a response (accept or reject) to the notification, then respective MCData client may send the Ad-hoc group standalone FD response to the primary server 202. The primary target MCData clients　402 and the partner target MCData clients　502 may automatically send accepted Ad-hoc group standalone FD response when the incoming request included mandatory download indication. The Ad-hoc group standalone FD response may contain the one or more information elements as described in the Table-8, the same has not been repeated for the sake of brevity. The receiving module 610 may receive the Ad-hoc group standalone FD response, received from the primary target MCData clients 402 and the partner target MCData clients 502, from the primary server 202 via the I / O interface 602.

[0269] FIG. 7 illustrates a block diagram of the primary MCData server 202 in accordance with an embodiment of the present disclosure. The primary server 202 may comprise an input / output (I / O) interface 702, processor(s) 704, and a memory 706, but not limited thereto. The memory 706 may include one or more modules 708 such as a receiving module 710, an authentication module 712, a verification module 714, a sending module 716 and a user determination module 718, but not limited thereto. It will be appreciated that such aforementioned modules may be represented as a single module or a combination of different modules. The modules may be implemented in any suitable hardware, software, firmware, or combination thereof. Further the modules may be implemented by various techniques comprising but not limited to computer programs, one or more neural networks, machine learning algorithms, embedded systems design and cloud computing architectures.

[0270] The I / O interface 702 may be in communication with the one or more MCData clients to send / receive one or more requests and send / receive one or more responses. The I / O interface 702may employ communication protocols / methods such as, without limitation, audio, analog, digital, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS / 2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE 802.n / b / g / n / x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE) or the like), etc. The memory 706 may store one or more instructions for the operation of one or more functions of the primary server 202. In an embodiment, the instructions stored in the memory 706may be processed by the one or more modules 708 of the primary server 202. The one or more modules 708 may be stored within the memory 706as shown in FIG. 7. The one or more modules 708 may be communicatively coupled to each other. In an embodiment, the one or more modules 708, communicatively coupled to the processor(s) 704, may also be present outside the memory 706.The processor(s) 704 may execute the one or more instructions stored in the memory 706 to perform the one or more functions of the primary server 202.

[0271] In an embodiment, the MCData client 102a may receive an input to determine the Ad-hoc group from the MCData user and initiate the standalone file distribution process in the Ad-hoc group. The receiving module 710 may receive the Ad-hoc group determination request from the MCData client 102a via the I / O interface 702. The MCData client 102a and the primary server 202 may be associated with the single MCData system. The Ad-hoc group determination request may contain the one or more information elements as described in the Table-1, the same has not been repeated for the sake of brevity. The authentication module 712 may authenticate the user of the MCData client 102a to determine whether the user of the client 102a is authorized to initiate the Ad-group determination request or not. In the user of the client 102a is not authorized to initiate the Ad-group determination request, the processor(s) 704 may reject the Ad-group determination request and the sending module (716) may send the error response to the MCData client 102a via the I / O interface 702.

[0272] If the MCData client 102a is authorized to initiate the Ad-group determination request and if the Ad-group determination request comprises the list of users for the formation of the Ad-hoc group, the processor(s) 704 may determine whether the number of the one or more MCData users comprised in the list is within the configured limit or not. If the number of the one or more MCData users comprised in the list is not within the configured limit, the processor(s) 704 may reject the Ad-hoc group determination request and the sending module 716 may send the error response to the client 102a via the I / O interface 702. If the number of the one or more MCData users comprised in the list is within the configured limit, the processor(s) 704 may form the Ad-group comprising the client 102a and one or more clients associated with the one or more MCData users comprised in the list.

[0273] If the Ad-hoc group determination request comprises the one or more criteria to determine the one or more users for the formation of the Ad-hoc group, the user determination module 718 may determine a list of one or more users associated with the primary MCData system based the one or more criteria. In an embodiment, the one or more criteria may include the distance parameter and the user determination module 718 may determine the one or more users located within the distance only. In an embodiment, the one or more criteria may include the functional alias and the user determination module 718 may determine the one or more users with the same functional alias attached to them. However, the one or more criteria may not be limited thereto. The processor(s) 704 may also determine if the partner MCData system needs to be involved for the formation of the Ad-hoc group based on the one or more criteria. If the partner MCData system needs to be involved, the sending module 716, via the I / O interface 702, may send the request (Get MCData userlist request) to the partner MCData server 204 associated with the partner MCData system to obtain the list of one or more MCData users associated with the partner MCData system satisfying the one or more criteria. The primary MCData system and the partner MCData system may be pre-configured to share data with each other based on the agreement and / or the local policy. The request sent by the sending module 716 to the partner server 204 may contain the one or more information elements as described in the Table-2, the same has not been repeated for the sake of brevity.

[0274] The partner server 204 may determine the list of the one or more users associated with the partner MCData system based the one or more criteria. The partner server 204 may determine the list of the one or more users only once. The receiving module 710 may receive the response (Get MCData userlist response) from the partner server 204. The response may contain the one or more information elements as described in the Table-3, the same has not been repeated for the sake of brevity. After receiving the response from the partner server 204, the processor(s) 704 may compile the list of the one or more users associated with the primary MCData system and the list of the one or more users associated with the partner MCData system. The processor(s) 704 may form the Ad-hoc group by using the list of the one or more users received from the partner server 204 and the list of the one or more users associated with the primary MCData system. The processor(s) 704 may further determine the preconfigured group to be used for the configuration (e.g. security related information) of the Ad-hoc group if end-to-end encryption is required. The processor(s) 704 may select the MCData Ad-hoc group ID for the newly formed Ad-hoc group and optionally assign a time-to-live value. The primary server 202 may ensure the list of the one or more users associated with the partner MCData system is within the configured limit. If the Ad-hoc group determination request contains information about the MCData client 102a (including IP address and port to be used for the file upload) and the target MCData content server 302 (including associated URI or IP address, and port), the sending module 716 may send, via the I / O interface 702, a request to the 3GPP system for the allocation of network resources with the required QoS for the corresponding file upload communication between the client 102a and the MCData content server 302. The sending module 716 may send, via the I / O interface 702, may send the Ad-hoc group determination response to the client 102a. The Ad-hoc group determination response may contain the one or more information elements as described in the Table-4, the same has not been repeated for the sake of brevity. After the formation of the Ad-hoc group, the user of client 102a may upload the file to be distributed in the Ad-hoc group to the content server 302 and receive the URL of the location at which the file is stored at the content server 302.

[0275] In an embodiment, the receiving module 710 may receive the standalone File Distribution (FD) request (Ad-hoc group standalone FD request) from the MCData client 102a for file distribution in the Ad-hoc group comprising the one or more users associated with the primary MCData system only. The standalone FD request may contain the one or more information elements as described in the Table-5, the same has not been repeated for the sake of brevity. If the Ad-hoc group communication is supported, the authentication module 712 may check whether the user of the MCData client　102a is authorized to send the Ad-hoc group standalone FD request. The authentication module 712 may check whether any policy is to be asserted to limit certain types of messages or content to certain members of the Ad-hoc group, for example, to location or user privilege. The authentication module 712 may also verify whether the provided functional alias can be used and has been activated for the user.

[0276] The sending module 716, via the I / O interface 702, may send the Ad-hoc group standalone FD request return to the MCData client　102a. The Ad-hoc group standalone FD request return may contain the result of whether the Ad-hoc group standalone FD request is authorized or not. If the Ad-hoc group standalone FD request is not authorized, the primary server 202 and the MCData client　102a may not proceed with the file distribution. The Ad-hoc group standalone FD request return may contain the one or more information elements as described in the Table-6, the same has not been repeated for the sake of brevity. If the Ad-hoc group standalone FD request is authorized, the processor(s) 704 may consider the Ad-hoc group members as implicitly affiliated with the Ad-hoc group. If the Ad-hoc group standalone FD request is authorized, the verification module 714 may verify whether the corresponding file is available at the MCData content server 302 via the MCData-FD reference point using the received URL of the file in the FD request. For that, the sending module 716, via the I / O interface 702, may send the MCData file availability request to the MCData content server 302. Upon the receipt of the request, the MCData content server 302 may provide an MCData file availability response to the receiving module 710 via the I / O interface 702. If the verification module 714 identifies that the file is not available in the content server 302, the sending module 716 may provide a response to the client　102a indicating that the file distribution request cannot proceed due to the unavailability of the file at the content server 302. If the deposit file indication information element is set to true in the received FD request, the processor(s) 704 may deposit this MCData communication to the MCData message store account of the user at the MCData client　102a.

[0277] If the file is available at the MCData content server 302, the sending module 716, via the I / O interface 702, may send the Ad-hoc group standalone FD request to the primary target MCData clients 402. While sending the Ad-hoc group standalone FD request, the processor(s) 704 may remove the one or more information elements that are not required to be conveyed to the primary target MCData clients 402 (e.g. MCData ID list). The Ad-hoc group standalone FD request, sent from the primary server 202 to the primary target MCData clients 402, may contain the one or more information elements as described in the Table-7, the same has not been repeated for the sake of brevity. The primary target MCData clients　402 may notify the one or more users of the primary target MCData clients 402 about the incoming Ad-hoc group standalone FD request (including file metadata, if present).

[0278] The one or more users of the primary target MCData clients　402 may either accept or reject or ignore the Ad-hoc group standalone FD request. If the one or more users of the primary target MCData clients　402 provide a response (accept or reject) to the notification, then respective MCData client(s) may send an Ad-hoc group standalone FD response to the receiving module 710. The primary target MCData clients　402 may automatically send accepted Ad-hoc group standalone FD response when the incoming request included mandatory download indication. The Ad-hoc group standalone FD response may contain the one or more information elements as described in the Table-8, the same has not been repeated for the sake of brevity. The sending module 716, via the I / O interface 702, may send the Ad-hoc group standalone FD response received from the primary target MCData clients 402 to the client　102a. The one or more users of the primary target MCData clients　402 may download the file using the URL of the file. The primary target MCData clients 402 may provide download completed reports, for reporting file download completed, to the primary server 202. On receiving the download completed reports from the primary target MCData clients　402 or the time-to-live value is expired, the processor(s) 704 may remove the Ad-hoc group information from the dynamic data held in the memory 706 and the Ad-hoc group ceases to exist.

[0279] In an embodiment, the receiving module 710, via the I / O interface, may receive the standalone File Distribution (FD) request from the MCData client 102a for file distribution in the Ad-hoc group comprising the one or more users associated with the primary MCData system and the partner MCData system. The FD request may contain the one or more information elements as described in the Table-5, the same has not been repeated for the sake of brevity. The authentication module 712 may check whether the user of the client 102a is authorized to send the Ad-hoc group standalone FD request. The authentication module 712 may check whether any policy is to be asserted to limit certain types of messages or content to certain members of the Ad-hoc group, for example, to location or user privilege. The authentication module 712 may also verify whether the provided functional alias can be used and has been activated for the user.

[0280] The sending module 716, via the I / O interface 702, may send the Ad-hoc group standalone FD request return to the client 102a. The Ad-hoc group standalone FD request return may contain the result of whether the Ad-hoc group standalone FD request is authorized or not. If the Ad-hoc group standalone FD request is not authorized, the primary server 202 and the client　102a may not proceed with the file distribution. The Ad-hoc group standalone FD request return may contain the one or more information elements as described in the Table-6, the same has not been repeated for the sake of brevity. If the Ad-hoc group standalone FD request is authorized, the processor(s) 704 may consider the Ad-hoc group members as implicitly affiliated with the Ad-hoc group. If the Ad-hoc group standalone FD request is authorized, the verification module 714 may verify whether the corresponding file is available at the MCData content server 302 via the MCData-FD reference point using the received URL of the file in the FD request. For that, the sending module 716, via the I / O interface 702, may send the MCData file availability request to the content server 302. Upon the receipt of the request, the content server 302 may provide an MCData file availability response to the receiving module 710 via the I / O interface 702. If the verification module 714 identifies that the file is not available in the content server 302, the sending module 716 may provide a response to the client　102a indicating that the file distribution request cannot proceed due to the unavailability of the file at the content server 302. If the deposit file indication information element is set to true in the received FD request, the processor(s) 704 may deposit this MCData communication to the MCData message store account of the user at client　102a.

[0281] If the file is available at the content server 302, the sending module 716, via the I / O interface 702, may send the Ad-hoc group standalone FD request to the primary target MCData clients 402 and the partner target MCData clients 502. While sending the Ad-hoc group standalone FD request, the processor(s) 704 may remove the one or more information elements that are not required to be conveyed to the primary target MCData clients 402 and the partner target MCData clients 502 (e.g. MCData ID list). The Ad-hoc group standalone FD request, sent from the primary server 202 to the primary target MCData clients 402 and the partner target MCData clients 502, may contain the one or more information elements as described in the Table-7, the same has not been repeated for the sake of brevity. The primary target MCData clients　402 may notify the one or more users of the primary target MCData clients 402 and the partner target MCData clients　502 may notify the one or more users of the partner target MCData clients 502 respectively, about the incoming Ad-hoc group standalone FD request (including file metadata, if present).

[0282] The one or more users of the primary target MCData clients　402 and the partner target MCData clients　502 may either accept or reject or ignore the Ad-hoc group standalone FD request. If the one or more users of the primary target MCData clients　402 and the one or more users of the partner target MCData clients　502 provide a response (accept or reject) to the notification, then respective MCData client may send the Ad-hoc group standalone FD response to the receiving module 710. The primary target MCData clients　402 and the partner target MCData clients　502 may automatically send accepted Ad-hoc group standalone FD response when the incoming request included mandatory download indication. The Ad-hoc group standalone FD response may contain the one or more information elements as described in the Table-8, the same has not been repeated for the sake of brevity. The sending module 716, via the I / O interface 702, may send the Ad-hoc group standalone FD response received from the primary target MCData clients 402 and the partner target MCData clients 502 to the client　102a. The one or more users of the primary target MCData clients　402 and the partner target MCData clients 502 may download the file using the URL of the file. The primary target MCData clients 402 and the partner target MCData clients 502 may provide download completed reports, for reporting file download completed, to the primary server 202. On receiving the download completed reports from the primary target MCData clients　402 and the partner target MCData clients 502, or the time-to-live value is expired, the processor(s) 704 may remove the Ad-hoc group information from the dynamic data held in the memory 706 and the Ad-hoc group ceases to exist.

[0283] FIG. 8 illustrates a flow diagram 800 of a method, performed by the MCData client 102a, for standalone file distribution to an Ad-hoc group in accordance with an embodiment of the present disclosure. The blocks of the flow diagram shown in FIG. 8 have been arranged in a generally sequential manner for ease of explanation, however, it is to be understood that this arrangement is merely　exemplary, and it should be recognized that the functionality / processing associated with method 800 (and the blocks shown in FIG. 8) can occur in a different order (for example, where at least some of the functionality / processing associated with the blocks is performed in parallel and / or in an event-driven manner).

[0284] At step 802, the method comprises initiating the standalone file distribution process in the Ad-hoc group upon receiving the input from the user of the client 102a. The MCData client 102a may receive one or more information elements associated with the file distribution. The one or more information elements may include an identity (ID) of the MCData user, ID of the Ad-hoc group, URL of the file, and / or information about consumer of the file, but not limited thereto.

[0285] At step 804, the method comprises sending the standalone File Distribution (FD) request (Ad-hoc group standalone FD request) to the primary MCData server 202 for file distribution in the Ad-hoc group. The FD request may contain the one or more information elements as described in the Table-5, the same has not been repeated for the sake of brevity. The primary MCData server 202 may check whether the MCData client 102a (the user of the MCData client 102a) is authorized to send the Ad-hoc group standalone FD request. The primary MCData server 202 may check whether any policy is to be asserted to limit certain types of messages or content to certain members of the Ad-hoc group, for example, to location or user privilege. The primary MCData server 202 may also verify whether the provided functional alias can be used and has been activated for the user. The primary MCData server 202 may send an Ad-hoc group standalone FD request return to the MCData client　102a. The Ad-hoc group standalone FD request return may contain the result of whether the Ad-hoc group standalone FD request is authorized or not. If the Ad-hoc group standalone FD request is not authorized, the primary MCData server 202 and the MCData client　102a may not proceed with the file distribution. The Ad-hoc group standalone FD request return may contain the one or more information elements as described in the Table-6, the same has not been repeated for the sake of brevity. If the Ad-hoc group standalone FD request is authorized, the primary MCData server 202 may verify whether the corresponding file is available at the MCData content server 302 via the MCData-FD reference point using the received URL of the file in the FD request.

[0286] If the availability of the file at the MCData content server 302 is confirmed, the primary MCData server 202 may send the Ad-hoc group standalone FD request to target MCData clients associated with the Ad-hoc group. While sending the Ad-hoc group standalone FD request, the primary MCData server 202 may remove one or more information elements that are not required to be conveyed to the target MCData clients (e.g. MCData ID list). The Ad-hoc group standalone FD request, sent from the primary MCData server 202 to the target MCData clients, may contain the one or more information elements as described in the Table-7, the same has not been repeated for the sake of brevity.

[0287] The target MCData clients　may notify the one or more associated users about the incoming Ad-hoc group standalone FD request (including file metadata, if present). The one or more users of the target MCData clients　may either accept or reject or ignore the Ad-hoc group standalone FD request. If the one or more users of the target MCData clients　provide the response (accept or reject) to the notification, then the respective MCData client(s) may send an Ad-hoc group standalone FD response to the primary server 202. The target MCData clients　may automatically send accepted Ad-hoc group standalone FD response when the incoming request included mandatory download indication. The Ad-hoc group standalone FD response may contain the one or more information elements as described in the Table-8, the same has been repeated for the sake of brevity. The primary server 202 may send the Ad-hoc group standalone FD response received from the primary target MCData clients 402 to the MCData client　102a.

[0288] FIG. 9 illustrates a flow diagram 900 of a method, performed by the MCData server 202, for file distribution in an Ad-hoc group in accordance with an embodiment of the present disclosure. The blocks of the flow diagram shown in FIG. 9 have been arranged in a generally sequential manner for ease of explanation, however, it is to be understood that this arrangement is merely　exemplary, and it should be recognized that the functionality / processing associated with method 900 (and the blocks shown in FIG. 9) can occur in a different order (for example, where at least some of the functionality / processing associated with the blocks is performed in parallel and / or in an event-driven manner).

[0289] At step 902, the method comprises receiving the File Distribution (FD) request (Ad-hoc group standalone FD request) from the client 102a for file distribution in the Ad-hoc group. The FD request may contain the one or more information elements as described in the Table-5, the same has not been repeated for the sake of brevity.

[0290] At step 904, the method comprises determining whether the user of the MCData client 102a is authorized to send the Ad-hoc group standalone FD request. The primary server 202 may check whether any policy is to be asserted to limit certain types of messages or content to certain members of the Ad-hoc group, for example, to location or user privilege. The primary MCData server 202 may also verify whether the provided functional alias can be used and has been activated for the user. The primary MCData server 202 may send an Ad-hoc group standalone FD request return to the client　102a. The Ad-hoc group standalone FD request return may contain the result of whether the Ad-hoc group standalone FD request is authorized or not. If the Ad-hoc group standalone FD request is not authorized, the primary MCData server 202 and the MCData client　102a may not proceed with the file distribution. The Ad-hoc group standalone FD request return may contain the one or more information elements as described in the Table-6, the same has not been repeated for the sake of brevity. If the Ad-hoc group standalone FD request is authorized, the primary MCData server 202 may verify whether the corresponding file is available at the MCData content server 302 via the MCData-FD reference point using the received URL of the file in the FD request.

[0291] At step 906, the method sending the Ad-hoc group standalone FD request to target MCData clients associated with the Ad-hoc group. While sending the Ad-hoc group standalone FD request, the primary MCData server 202 may remove one or more information elements that are not required to be conveyed to the target MCData clients (e.g. MCData ID list). The Ad-hoc group standalone FD request, sent from the primary MCData server 202 to the target MCData clients, may contain the one or more information elements as described in the Table-7, the same has not been repeated for the sake of brevity.

[0292] The target MCData clients　may notify the one or more users of the target MCData clients about the incoming Ad-hoc group standalone FD request (including file metadata, if present). The one or more users of the target MCData clients　may either accept or reject or ignore the Ad-hoc group standalone FD request. If the one or more users of the target MCData clients　provide the response (accept or reject) to the notification, then the respective MCData client(s) may send an Ad-hoc group standalone FD response to the primary server 202. The target MCData clients　may automatically send accepted Ad-hoc group standalone FD response when the incoming request included mandatory download indication. The Ad-hoc group standalone FD response may contain the one or more information elements as described in the Table-8, the same has been repeated for the sake of brevity. The primary MCData server 202 may send the Ad-hoc group standalone FD response received from the primary target MCData clients 402 to the MCData client　102a.

[0293] In this manner, the present disclosure may distribute a file among one or more MCData users associated with an Ad-hoc group.

[0294] While　various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art.　The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the detailed description.

[0295] The order in which the various operations of the methods are described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described herein. Furthermore, the methods can be implemented in any suitable hardware, software, firmware, or combination thereof.

[0296] It may be noted here that the subject matter of some or all embodiments described with reference to FIG. 1A-9 may be relevant for the methods and the same is not repeated for the sake of brevity. The various operations of methods described above may be performed by any suitable means capable of performing the corresponding functions. The means may include various hardware and / or software component(s) and / or module(s), including, but not limited to a circuit, an application specific integrated circuit (ASIC), or processor. Generally, where there are operations illustrated in Figures, those operations may be performed by any suitable corresponding counterpart means-plus-function components.

[0297] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term "computer-readable medium" should be understood to include tangible items and exclude carrier waves and transient signals, i.e., non-transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, nonvolatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media.

[0298] Certain aspects may comprise a computer program product for performing the operations presented herein. For example, such a computer program product may comprise a computer readable media having instructions stored (and / or encoded) thereon, the instructions being executable by one or more processors to perform the operations described herein. For certain aspects, the computer program product may include packaging material.

[0299] Various components, modules, or units are described in this disclosure to emphasize functional aspects of devices configured to perform the disclosed techniques, but do not necessarily require realization by different hardware units. Rather, as described above, various units may be combined in a hardware unit or provided by a collection of interoperative hardware units, including one or more processors as described above, in conjunction with suitable software and / or firmware.

[0300] As used herein, a phrase referring to "at least one" or "one or more" of a list of items refers to any combination of those items, including single members. As an example, "at least one of: a, b, or c" is intended to cover: a, b, c, a-b, a-c, b-c, and a-b-c. The terms "a", "an" and "the" mean "one or more", unless expressly specified otherwise. The terms "including", "comprising", "having" and variations thereof, when used in a claim, is used in a non-exclusive sense that is not intended to exclude the presence of other elements or steps in a claimed structure or method, unless expressly specified otherwise.

[0301] Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present disclosure are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the appended claims.

Claims

1.A method performed by a mission critical data (MCData) client, the method comprising:identifying whether to initiate standalone file distribution (FD);transmitting, to an MCData server, a first ad hoc group standalone FD request comprising at least one of information on an identity associated with MCData, information on an identity associated with a conversation, information on a payload, or information on a content reference; andreceiving, from the MCData server, an ad hoc group standalone FD request return comprising information on a result of whether the first ad hoc group standalone FD request is authorized or not.2.The method of claim 1,wherein a second ad hoc group standalone FD request is transmitted by the MCData server to at least one target MCData client, andwherein an ad hoc group standalone FD response is received by the MCData server from the at least one target MCData client.3.The method of claim 1, further comprising:receiving, from the MCData server, an ad hoc group standalone FD response.4.The method of claim 2,wherein the MCData server is an MCData server of a primary MCData system, andwherein the at least one target MCData client comprises a target MCData client of the primary MCData system and a target MCData user of a partner MCData system.5.A method performed by a mission critical data (MCData) server, the method comprising:receiving, from an MCData client, a first ad hoc group standalone file distribution (FD) request comprising at least one of information on an identity associated with MCData, information on an identity associated with a conversation, information on a payload, or information on a content reference;identifying whether the first ad hoc group standalone FD request is authorized or not; andtransmitting, to the MCData client, an ad hoc group standalone FD request return comprising information on a result of the whether the first ad hoc group standalone FD request is authorized or not.6.The method of claim 5, further comprising:transmitting, to at least one target MCData client, a second ad hoc group standalone FD request; andreceiving, from the at least one target MCData client, an ad hoc group standalone FD response,wherein the MCData server is an MCData server of a primary MCData system, andwherein the at least one target MCData client comprises a target MCData client of the primary MCData system and a target MCData user of a partner MCData system.7.The method of claim 5, further comprising:transmitting, to the MCData client, an ad hoc group standalone FD response.8.A mission critical data (MCData) client, the MCData client comprising:a transceiver; andat least one processor coupled with the transceiver and configured to:identify whether to initiate standalone file distribution (FD),transmit, to an MCData server, a first ad hoc group standalone FD request comprising at least one of information on an identity associated with MCData, information on an identity associated with a conversation, information on a payload, or information on a content reference, andreceive, from the MCData server, an ad hoc group standalone FD request return comprising information on a result of whether the first ad hoc group standalone FD request is authorized or not.9.The MCData client of claim 8,wherein a second ad hoc group standalone FD request is transmitted by the MCData server to at least one target MCData client, andwherein an ad hoc group standalone FD response is received by the MCData server from the at least one target MCData client.10.The MCData client of claim 8, wherein the at least one processor is further configured to:receive, from the MCData server, an ad hoc group standalone FD response.11.The MCData client of claim 9,wherein the MCData server is an MCData server of a primary MCData system, andwherein the at least one target MCData client comprises a target MCData client of the primary MCData system and a target MCData user of a partner MCData system.12.A mission critical data (MCData) server, the MCData server comprising:a transceiver; andat least one processor coupled with the transceiver and configured to:receive, from an MCData client, a first ad hoc group standalone file distribution (FD) request comprising at least one of information on an identity associated with MCData, information on an identity associated with a conversation, information on a payload, or information on a content reference,identify whether the first ad hoc group standalone FD request is authorized or not, andtransmit, to the MCData client, an ad hoc group standalone FD request return comprising information on a result of the whether the first ad hoc group standalone FD request is authorized or not.13.The MCData server of claim 12, wherein the at least one processor is further configured to:transmit, to at least one target MCData client, a second ad hoc group standalone FD request, andreceive, from the at least one target MCData client, an ad hoc group standalone FD response.14.The MCData server of claim 12, wherein the at least one processor is further configured to:transmit, to the MCData client, an ad hoc group standalone FD response.15.The MCData server of claim 13,wherein the MCData server is an MCData server of a primary MCData system, andwherein the at least one target MCData client comprises a target MCData client of the primary MCData system and a target MCData user of a partner MCData system.

Images