NETWORK RESOURCE ALLOCA PON FOR MISSION CRITICAL HTTP SER VICES

BACKGROUND

[0001] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features, and advantages of the enclosed embodiments will be apparent from the following description. [0002] Group communication is a fundamental concept in Mission Critical (MC) services. In group communication, it is required that the same information is delivered to multiple users comprised in the group. The size of the group in terms of the involved numbers of users is an important parameter to efficiently setup and manage the required Quality of Service (QoS) to distribute data within the group.

[0003] In currently available group communication systems such as, for example, those defined by Open Mobile Alliances Push-to-Talk over cellular (OMA PoC) or the Third Generation Partnership Project (3GPP) defined Mission Critical Push To Talk (MCPTT), different methods are defined to allocate needed network resources. These allocation methods include a fixed allocation of signaling resources as well as on demand allocation of resources for the data transmission, e.g., voice or video traffic. These methods also include allocating priorities for the group communication, where the priorities may be used in case of network congestion such that the data traffic with higher priority may have precedence and pre-empt data traffic with lower priority. Besides an absolute priority level, there are also other aspects to control, e.g., pre-emption as well as service vulnerability aspects.

[0004] A common data protocol used for multimedia communication is the Session Initiation Protocol (SIP). SIP is used to initiate, control, and terminate multimedia sessions between user agents and between user agents and multimedia servers. It may be used for both one-to-one communication as well as a group communication. Another aspect of SIP based multimedia services are that they in require real time characteristics in most cases. Allocating network resources to provide the required QoS is an important part of a real time services. In a 3GPP network, there are well-established procedures for network resource allocation when SIP based multimedia services are used. The 3GPP Technical Specification (TS) 23.280 and 3GPP TS 23.379 specify procedures to provide MCPTT service over 3GPP systems, e.g., an Evolved Packet System (EPS) as described in 3GPP TS 23.401, including network resource allocation. Figure 1

[0005] On the Internet or on private Internet Protocol (IP) based networks HyperText Transfer Protocol (HTTP) is commonly used for a wide range of multimedia applications. Services provided over HTTP are in many cases on-demand type of services such as, for example, providing or accessing static or dynamic data sources. The MC data (MCData) service, as specified in 3GPP TS 23.282 v17.5.0, provides HTTP-based capabilities, e.g., for the distribution of files to a target group. The functional architecture for MCData file distribution defined in 3GPP TS 23.282 v17.5.0, which is reproduced herein as Figure 1, shows the functional architecture for MCData file distribution, where the communication between the MCData content server and the MCData client is over the HTTP-based reference point MCData-FD-4. Likewise, the communication between the MCData message store and the MCData client is over the HTTP-based reference point MCData-FD-7. Further descriptions of the functional entities and reference points are described in 3GPP TS 23.282 V17.5.0.

[0006] Other aspects of MC services include resiliency, reliability, and ensuring that the required security level can be provided. MC services need to endure severe situations such as, e.g., minor or major network outages, disaster recovery, and different overload scenarios, both due to load from authorized users as well as denial of service attacks. [0007] Due to an increased variation of multimedia services for mission critical users, there is a clear need to guarantee that different levels of CoS can be provided. Hence, there are still needs for improved methods to properly provide network resources for mission critical users.

SUMMARY

[0008] There currently exist certain challenge(s). Multimedia services for mission critical services based on HTTP are many times provided with a best effort CoS. This means that the services can only be reliably provided when there is low or normal network load, but not when there are congested network loads.

[0009] An example of such mission critical services are the HTTP-based MCData services defined in 3GPP TS 23.282 v17.5.0. These multimedia services include methods for transmission control, which are used to control that authorized users get rights to transmit or receive data based on application layer decisions. However, these methods lack the interaction with the network to request the allocation of network resources with the required QoS. Also, these methods do not include receiving feedback from the network in cases when the network becomes overloaded or due to other reasons cannot provide the required services.

Figure 2 and 3

[0010] As specified in 3GPP TS 23.282 v17.5.0, the MCData server is the functional entity that provides network resource management functionalities to MCData services. The MCData server can request the 3GPP system, e.g., an EPS as described in 3GPP TS 23.401 or a Fifth Generation (5G) system as described in 3GPP TS 23.501, to allocate network resources with required QoS for MCData communications. In the case of MCData communications over EPS, the MCData server performs network resource management via the Rx interface, as defined in 3GPP TS 23.203.

However, as specified in 3GPP TS 23.282 v17.5.0 and reproduced herein as Figure 2, MCData communications for file distribution imply that MCData clients can directly upload files to an MCData content server over HTTP without the involvement of the MCData server. The files then become available to be downloaded by other MCData clients over HTTP also directly from the MCData content server, as specified in 3GPP TS 23.282 v17.5.0 and reproduced herein as Figure 3. Since the MCData server is not involved in these communications, the possibility to request the allocation of network resources with the required QoS cannot be provided.

[0011] Also, as specified in 3GPP TS 23.282 v17.5.0, for the file upload, the MCData client is required to indicate in the request to the MCData content server if it is in an emergency state. An emergency indicator is used to provide the MCData client a higher priority for the required communication. However, the MCData content server does not support the capability to send a request to the 3GPP system for the configuration of the required priority of the underlying bearers. This can only be done by the MCData server. Likewise, this is required to be supported for the file download case, where MCData clients in an emergency state require higher priorities for the corresponding communication.

[0012] Likewise, as specified in 3GPP TS 23.282 v17.5.0, the same issue occurs for other MCData communications like operations related to the MCData message store, where the MCData server is not involved in MCData communications between the MCData clients and the MCData message store.

[0013] Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Systems and methods are disclosed herein for requesting network resources for mission critical services provided over HTTP, e.g. MCData services (e.g., MCData file distribution and/or MCData message store operations) over 3GPP systems. This can be done with or without interaction with application layer transmission control mechanisms. The MC services can be denied or provided with limited QoS after a notification to the end users' including an optional consent.

[0014] There are, proposed herein, various embodiments which address one or more of the issues disclosed herein. In one embodiment, a method comprises, at a MC data client, sending an upload or download request to a MC data server, the upload or download request being a request to upload or download a particular file or message to or from a target MC data content server or a target MC data message store. The method further comprises, at the MC data server, receiving the upload or download request from the MC data client, determining whether the MC data client is authorized to upload or download files or messages to or from the target MC data content server or the target MC data message store, and sending a response to the MC data client that indicates whether the MC data client can proceed with the upload or download of the particular file or message to or from the target MC data content server or the target MC data message store, based on a result of the determining whether the MC data client is authorized to upload or download files or messages to or from the target MC data content server or the target MC data message store. The method further comprises, at the MC data client, receiving the response from the MC data server and proceeding with the upload or download of the particular file or message to or from the target MC data content server or the target MC data message store or not, in accordance with the response.

[0015] In one embodiment, the upload or download request comprises information about the MC data client and information about the target MC data content server or the target MC data message store. In one embodiment, the information about the MC data client comprises: (a) information that identifies the MC data client, (b) an Internet Protocol (IP) address of the MC data client, (c) a port associated to the MC data client, (d) a MC data identity (ID) associated to the MC data client, or (e) a combination of any two or more of (a)-(d). In one embodiment, the information about the target MC data content server or the target MC data message store comprises: (i) information that identifies the target MC data content server or the target MC data message store, (ii) a Uniform Resource Indicator (URI) or IP address associated to the target MC data content server or the target MC data message store, (iii) a port associated to the target MC data content server or the target MC data message store, (iv) a combination of any two or more of (i)-(iii). In one embodiment, the upload or download request further comprises metadata associated to the particular file or message. In one embodiment, the metadata comprises a size of the particular file or message, a target MC data group ID, or both.

[0016] In one embodiment, at the MC data sever, determining whether the MC data client is authorized to upload or download files or messages to or from the target MC data content server or the target MC data message store comprises determining that the MC data client is authorized to upload or download files or messages to or from the target MC data content server or the target MC data message store, and the response sent to the MC data client indicates that the MC data client can proceed with the upload or download of the particular file or message to or from the target MC data content server or the target MC data message store. At the MC data client, proceeding with the upload or download of the particular file or message to or from the target MC data content server or the target MC data message store or not, in accordance with the response, comprises proceeding with the upload or download of the particular file or message to or from the target MC data content server or the target MC data message store via a cellular communications system. In one embodiment, the method further comprises, at the MC data sever, responsive to determining that the MC data client is authorized to upload or download files or messages to or the target MC data content server or the target MC data message store, sending a request to the cellular communications system for dedicated resources with a required Quality of Service (QoS) for the upload or download of the particular file or message via the cellular communications system. At the MC data client, proceeding with the upload or download of the particular file or message to or from the target MC data content server or the target MC data message store via the cellular communications system comprises proceeding with the upload or download of the particular file or message to or from the target MC data content server or the target MC data message store via the cellular communications system using the requested dedicated resources with the required QoS. In one embodiment, the request sent to the cellular communications system for the dedicated resources with the required QoS is based on information comprised in the upload or download request. In one embodiment, the method further comprises, at the MC data client, sending a message to the MC data server that indicates that the upload or download of the particular file or message to or from the target MC data content server or the target MC data message store is complete and, at the MC data sever, receiving the message from the MC data client that indicates that the upload or download of the particular file or message to or from the target MC data content server or the target MC data message store is complete and, responsive to receiving the message, sending a request to release the dedicated resources to the cellular communications system. [0017] In one embodiment, at the MC data client, proceeding with the upload or download of the particular file or message to or from the target MC data content server or the target MC data message store via the cellular communications system comprises sending, to the target MC data content server or the target MC data message store via the cellular communications system, an upload or download data request to upload for download the particular file or message to or from the target MC data content server or the target MC data message store. In one embodiment, the method further comprises, at the target MC data content server or the target MC data message store, receiving, from the MC data client, the upload or download data request to upload or download the particular file or message to or from the target MC data content server or the target MC data message store and sending an upload or download data response to the MC data client. In one embodiment, the method further comprises, at the target MC data content server or the target MC data message store, applying a control policy before either storing the particular file or message in the case of an upload request or providing the particular file or message to the MC data client in the case of a download request.

[0018] In one embodiment, the method further comprises, at the MC data server, determining whether a file size of the particular file is below a maximum allowable file size for file distribution from a corresponding service configuration and/or determining whether the MC data client is authorized to upload or download a file targeting a corresponding MC data group. The response sent to the MC data client that indicates whether the MC data client can proceed with the upload or download of the particular file to or from the target MC data content server is further based on a result of the determining whether the file size of the particular file is below the maximum allowable file size for file distribution from the corresponding service configuration and/or a result of the determining whether the MC data client is authorized to upload or download a file targeting the corresponding MC data group.

[0019] In one embodiment, the method further comprises at the MC data server, verifying whether the particular file or message is stored at the MC data content server or the MC data message store and/or retrieving information related to the particular file or message.

[0020] Corresponding embodiments of a method of operation of a MC data client, a MC data server, a MC data content server, and a MC data message store are also disclosed. Corresponding embodiments of a MC data client, a MC data server, a MC data content server, and a MC data message store are also disclosed.

[0021] In one embodiment, a method comprises, at each of one or more MC data clients, receiving, from a MC data server, a MC data group standalone request or a MC data standalone request and sending, to the MC data server, a MC data group standalone response or a MC data standalone response. The method further comprises, at the MC data server, receiving one or more MC data group standalone responses or one or more MC data standalone responses from the one or more MC data clients, respectively, and, responsive thereto, sending a request to the cellular communications system for dedicated resources with a required QoS for download of a file from a MC data content server to at least one of the one or more MC data clients via the cellular communications system.

[0022] In one embodiment, the at least one of the one or more MC data clients consists of at least one of the one or more MC data clients for which the respective MC data group standalone response or the respective MC data standalone response indicates an acceptance of the MC data group standalone request or the MC data standalone request. In one embodiment, the method further comprises, at each of the at least one of the one or more MC data clients, downloading the file from the MC data content server via the cellular communications system using the dedicated resources.

[0023] In one embodiment, the method further comprises, at a MC data client, sending, to the MC data server, a MC data group standalone file distribution (FD) request or a MC data standalone FD request. The method further comprises, at the MC data server, receiving, from the MC data client, the MC data group standalone FD request or the MC data standalone FD request and sending, to the one or more MC data clients, the MC data group standalone request or the MC data standalone request responsive to receiving the MC data group standalone FD request or the MC data standalone FD request.

[0024] In one embodiment, the method further comprises, at the MC data server, receiving, from the at least one of the one or more MC data clients, a download completed report and sending, to the cellular communications system, a request to release the dedicated resources responsive to receiving the download completed report from the at least one of the one or more MC data clients.

[0025] In one embodiment, the method further comprises at the MC data server, verifying that a particular file or message requested by the MC data group standalone request or the MC data standalone request is stored by a respective MC data content server or a respective MC data message store, prior to sending the MC data group standalone response or the MC data standalone response.

[0026] In one embodiment, the method further comprises, at the MC data server, sending the one or more MC data group standalone responses or the one or more MC data standalone responses received from the one or more MC data clients to the MC data client.

[0027] Corresponding embodiments of a method of operation of a MC data client, a MC data server, a MC data content server, and a MC data message store are also disclosed. Corresponding embodiments of a MC data client, a MC data server, a MC data content server, and a MC data message store are also disclosed.

[0028] Certain embodiments may provide one or more of the following technical advantage(s). Providing the right level of QoS for mission critical services is essential for MC users. The proposed solution provides new methods to guarantee the QoS for MC services over HTTP.

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

Figure 1 shows the functional architecture for MCData file distribution, where the communication between the MCData content server and the MCData client is over the FITTP-based reference point MCData-FD-4; Figure 2 shows MCData communications for file distribution where a MCData clients directly upload files to an MCData content server; Figure 3 shows MCData communications for file distribution where a MCData clients directly download files from an MCData content server;

Figure 4 illustrates one example of a system 400 in which embodiments of the present disclosure may be implemented;

Figure 5 provides a description of an embodiment of the invention; Figure 6 provides a description of another embodiment of the invention; Figure 7 illustrates one example embodiment considering the group standalone file distribution using HTTP procedure;

Figure 8 illustrates one example of the cellular communications system 410 of Figure 4 in accordance with one embodiment of the present disclosure;

Figure 9 is a schematic block diagram of a network node 900 according to some embodiments of the present disclosure;

Figure 10 is a schematic block diagram that illustrates a virtualized embodiment of the network node 900 according to some embodiments of the present disclosure;

Figure 11 is a schematic block diagram of the network node 900 according to some other embodiments of the present disclosure;

Figure 12 is a schematic block diagram of a wireless communication device 1200 according to some embodiments of the present disclosure;

Figure 13 is a schematic block diagram of the wireless communication device 1200 according to some other embodiments of the present disclosure.

DETAILED DESCRIPTION

[0030] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. [0031] Radio Node: As used herein, a "radio node” is either a radio access node or a wireless communication device.

[0032] Radio Access Node: As used herein, a "radio access node” or "radio network node” or "radio access network node” is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.

[0033] Core Network Node: As used herein, a "core network node” is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

[0034] Communication Device: As used herein, a "communication device” is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehicle- mounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.

[0035] Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.

[0036] Network Node: As used herein, a "network node” is any node that is either part of the RAN or the core network of a cellular communications network/system or any node that hosts a Mission Critical (MC) network entity such as, e.g., a MCData server, a MCData content server, or a MCData message store.

[0037] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0038] Note that, in the description herein, reference may be made to the term "cell”; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

Figure 4 [0039] Figure 4 illustrates one example of a system 400 in which embodiments of the present disclosure may be implemented. The system 400 is similar to that described in 3GPP TS 23.282 v17.5.0. The system 400 includes a Mission Critical (MC) Data (MCData) server 402, a MCData content server 404, a MCData message store 406, and a MCData UE 408 communicatively coupled through a cellular communications system 410, e.g., a 3GPP system such as, e.g., an EPS or 5G system. The MCData server 402 includes a FD function 412 and a transmission/reception control function 414. The MCData content server 404 includes a media store function 416. The MCData UE 406 includes a MCData client 418, which itself includes a File Distribution (FD) function 420, a media storage client 422, and a message store client 424. For a description of the baseline operation of each of the various components of the system 400, the interested reader is directed to 3GPP TS 23.282 v17.5.0. The baseline operation is modified as described herein. In this regard, embodiments of the present disclosure are described below under separate headings. However, these embodiments may be used together in any suitable or desired manner.

1 File upload using HTTP including request of resources with required QoS from the MCData server

Figure 5

[0040] In an embodiment, when the MCData client 418 operating on the MC UE 408 intends to upload a file to the MCData content server 404 over HTTP for file distribution (FD), the MCData client 418 is required to first send a request to the MCData server 402 to obtain authorization to upload a file to the corresponding MCData content server 404. The MCData server 402 verifies if the MCData client 418 is authorized to upload the file and may apply transmission control. Based on this request, the MCData server 402 can send a request for dedicated network resources to the 3GPP system with a required QoS for the corresponding file upload. Upon the receipt of confirmation from the MCData server 402, the MCData client 418 proceeds to upload the file to the corresponding MCData content server 404. Figure 5 provides a complete description of this embodiment.

[0041] Pre-conditions:

1. The MCData user on the MCData client 418 is registered on the MCData server 402 for receiving MCData service.

[0042] Step 500: The MC user on the MCData client 418 intends to upload a file to the MCData content server 404 for file distribution (FD). For that, the MCData client 418 first prepares an MCData file upload request to the MCData server 402 about the upload of the chosen file. In one embodiment, the MCData client 418 verifies that the size of the file is within the maximum data size for file distribution (FD) for the intended MCData FD request (e.g., by checking the group configuration for a group FD request and by checking the service configuration for a one-to-one FD request). In one embodiment, if MCData emergency state is already set for the MCData client 418, the MCData client 418 sets the emergency indicator in the request.

[0043] Step 502: The MCData client 418 sends the MCData file upload request to the MCData server 402. In some embodiments, the request includes information about the MCData client 418 identification (e.g., IP address, port, and MCData ID), the target MCData content server 404 (e.g., associated URI or IP address, and port (e.g., standard port 80 for HTTP)), and metadata information associated to the file (e.g., file size, target MCData group ID).

[0044] Step 504: The MCData server 402 checks that the corresponding MCData client is authorized to upload files to the corresponding MCData content server 404. Also, in one embodiment, the MCData server 402 can check that the size of the file is below the maximum data size for FD from the service configuration and if the MCData client 418 is authorized to upload a file targeting a corresponding MCData group.

[0045] Step 506: If the MCData client 418 is authorized for the file upload, the MCData server 402 sends a request the allocation of dedicated network resources in the cellular communications system 410 with a required QoS for the corresponding file upload communication between the MCData client 418 and the MCData content server 404. For that, in one embodiment, the MCData server 402 utilizes the received information within the request, such as IP address and port associated to the MCData client 418, and URI and/or IP address, and port associated to the target MCData content server 404 and performs policy and charging control (PCC) procedures over the Rx reference point for the case of an EPS system, as described in 3GPP TS 23.203 and 3GPP TS 29.214, or over the Rx reference point or N5 reference point for the case of a 5GS system, as described in 3GPP TS 23.501 and 3GPP TS 23.503.

[0046] Step 508: The MCData server 402 indicates to the MCData client 418 if it can proceed with the file upload to the MCData content server.

[0047] Step 510: As defined in 3GPP TS 23.282 v17.5.0, the media storage client 422 on the MCData client 418 sends an MCData upload data request to the media storage function 416 on the MCData content server 404 to upload the file.

[0048] Step 512 (Optional): Upon the receipt of the upload data request ,in one embodiment, the MCData content server 404 may apply transmission control policy before storing the file. The MCData content server 404 communicates with the MCData server 402 over the MCData-FD-5 reference point to apply transmission control, e.g. to check if the MCData user is authorized to upload the file or if the file size is within the maximum data size for file distribution to the target MCData group. Also, in one embodiment, the MCData server 402 can indicate to the MCData content server 404 to stop the upload file transmission from the client due to detected congestion in the network.

[0049] Step 514: As defined in 3GPP TS 23.282 v17.5.0, the MCData content server 404 provides an MCData upload data response to the MCData client 418 indicating whether the file was successfully stored (along with file URL) or there was a failure.

[0050] Step 516: The MCData client 418 provides a report to the MCData server 402 about the file upload completion status. In one embodiment, the report indicates whether the file upload is completed. For the case of a successful upload, the report may include the corresponding URL of the stored file on the MCData content server 404. [0051] Step 518: Upon the receipt of the file upload completion status, in one embodiment, the MCData server 402 sends a request to the cellular communications system 410 to release the dedicated resources allocated for the corresponding file upload. [0052] Likewise, these embodiments can be further applied to MCData message store operations over HTTP defined in 3GPP TS 23.282 v17.5.0. Therefore, when an MCData client 418 operating on an MC UE 408 intends to perform an MCData message store related operation, e.g. upload or retrieve an object to/from the MCData message store 406, the MCData client 418 is required to first send a request to the MCData server 402 to obtain an indication to proceed with such an operation. For the case of retrieving an object, the MCData server 402 can additionally verify if the object is stored in the MCData message store 406. Based on this request, the MCData server 402 can send a request to the cellular communications system 410 for dedicated network resources with a required QoS for the corresponding message store operation. Upon the receipt of confirmation from the MCData server 402, the MCData client 418 proceeds with the corresponding operation with the MCData message store 404.

2 File download using HTTP including request of resources with required QoS from the MCData server

2.1 Request of resources from the MCData server based on file download request

Figure 6

[0053] In an embodiment, when the MCData client 418 operating on the MC UE 408 intends to download a file from the MCData content server 404 over HTTP, the MCData client 418 is required to first send a request to the MCData server 402 to obtain authorization to download the file from the corresponding MCData content server 404. The MCData server 402 verifies if the MCData client 418 is authorized to download the file and if the file is available in the MCData content server 404. The MCData server 402 may also apply reception control. Based on this request, the MCData server 402 can send a request to the cellular communications system 410 for dedicated network resources with a required QoS for the corresponding file download. Upon the receipt of confirmation from the MCData server 402, the MCData client 418 proceeds to download the file from the corresponding MCData content server 404. Figure 6 provides a complete description of this embodiment.

[0054] Pre-conditions:

1. The MCData user on the MCData client 418 is registered on the MCData server 402 for receiving MCData service.

2. The MCData user has received the URL of the file stored on the MCData content server 404.

[0055] Step 600: The MC user on the MCData client 418 intends to download a file from the MCData content server 404 based on the URL of the file on the MCData content server 404. For that, the MCData client 418 first prepares an MCData file download request to the MCData server 402 about the download of the corresponding file. In one embodiment, if MCData emergency state is already set for the MCData client 418, the MCData client 418 sets the emergency indicator in the request.

[0056] Step 602: The MCData client 418 sends the MCData file download request to the MCData server 402. In some embodiments, the request includes information about the MCData client 418 identification (e.g., IP address, port, MCData ID), the target MCData content server (e.g., associated URI or IP address, port (e.g., standard port 80 for HTTP)), file URL, and metadata information associated to the file (e.g., file size, target MCData group ID). [0057] Steps 604-606: The MCData server 402 checks that the corresponding MCData client 418 is authorized to download files from the corresponding MCData content server 404. In one embodiment, the MCData server 402 may also verify that the file is stored in the MCData content server 404 and if required retrieves information related to the file (e.g., target MCData group ID). In one embodiment, the MCData server 402 then checks if the size of the file is below the maximum data size for FD from the service configuration and if the MCData client is authorized to download a file targeting a corresponding MCData group, e.g. by checking that the MCData user on the MCData client 418 is a member of the MCData group.

[0058] Step 608: If the MCData client 418 is authorized for the file download, the MCData server 402 sends a request to the cellular communications system 410 for allocation of dedicated network resources with a required QoS for the corresponding file download communication between the MCData client 418 and the MCData content server 404. For that, in one embodiment, the MCData server 402 utilizes the received information within the request, such as IP address and port associated to the MCData client 418, and URI and/or IP address, and port associated to the target MCData content server 404 and performs policy and charging control (PCC) procedures over the Rx reference point for the case of an EPS system, as described in 3GPP TS 23.203 and 3GPP TS 29.214, or N5 reference point for the case of a 5GS system, as described in 3GPP TS 23.501 and 3GPP TS 23.503.

[0059] Step 610: The MCData server 402 indicates to the MCData client 418 whether it can proceed with the file download from the MCData content server.

[0060] Step 612: As defined in 3GPP TS 23.282 v17.5.0, the media storage client 422 on the MCData client 418 sends an MCData download data request to the media storage function 416 on the MCData content server 402 to download the file.

[0061] Step 614 (Optional): Upon the receipt of the upload data request ,in one embodiment, the MCData content server 404 may apply reception control policy before providing the file to the MCData client 418. The MCData content server 404 communicates with the MCData server 402 over the MCData-FD-5 reference point to apply reception control, e.g. to check if the MCData user is authorized to download the file or if the file size is within the maximum data size for file distribution to the target MCData group. Also, the MCData server 402 can indicate to the MCData content server to stop the download file transmission to the client due to detected congestion in the network.

[0062] Step 616: As defined in 3GPP TS 23.282 v17.5.0, the MCData content server 404 provides an MCData download data response to the MCData client 418 providing the corresponding file (in case of success) or failure response.

[0063] Step 618: The MCData client 418 provides a report to the MCData server 402 about the file download completion status. In one embodiment, the report indicates whether the file download is completed.

[0064] Step 620: Upon the receipt of the file download completion status, in one embodiment, the MCData server 402 sends a request to the cellular communications system 410 to release the dedicated resources allocated for the corresponding file download. 2.2 Request of resources from the MCData server based on received MCData FD response in the file distribution procedures using HTTP

Figure 7

[0065] In an embodiment, the MCData server 402 can send a request to the cellular communications system 410 for dedicated network resources with a required QoS for the corresponding file download based on the received MCData FD response from the target MCData client defined in the one-to-one file distribution using HTTP procedure in 3GPP TS 23.282 v17.5.0. Likewise, the MCData server 402 can request dedicated network resources based on the received MCData FD response(s) from the target MCData group's members in the group standalone file distribution using HTTP procedure defined in 3GPP TS 23.282 v17.5.0. Figure 7 illustrates one example embodiment considering the group standalone file distribution using HTTP procedure. The same method can also be applied for the one-to-one file distribution using HTTP procedure.

[0066] Pre-conditions:

1. The MCData users on the MCData clients 1 to N (denoted herein as MCData clients 418-1 to 418-N) belong to the same MCData group and are already registered and affiliated for receiving MCData service.

2. The file to be distributed is already uploaded on the MCData content server 404.

[0067] 702: As defined in 3GPP TS 23.282 v17.5.0, the MCData user on the MCData client 1 418-1 initiates a file distribution request to a target MCData group.

[0068] 704: As defined in 3GPP TS 23.282 v17.5.0, the MCData client 1 418-1 sends a MCData group standalone

FD request towards the MCData server 402. The MCData FD request contains the file URL and may contain the file metadata information. The MCData group standalone data request contains the selected target MCData group ID.

[0069] 706: As defined in 3GPP TS 23.282 v17.5.0, if either emergency indicator or imminent peril indicator is present in the received MCData group standalone FD request, the MCData server 402 implicitly affiliates the MCData client 1 418-1 to the MCData group if the MCData client 1 418-1 is not already affiliated.

[0070] 708: In an embodiment, the MCData server 402 may verify if the corresponding file is stored in the MCData content server 404 over the MCData-FD-5 reference point using the received file URL in the MCData group standalone FD request. If the MCData server 402 identifies that the corresponding file is not stored in the MCData content server 404, the MCData server 402 sends a response to the MCData client 1 418-1 rejecting the file distribution request. The response includes as a reason that the corresponding file is not available in the MCData content server 404.

[0071] 710: As defined in 3GPP TS 23.282 v17.5.0, the MCData server 402 checks whether the MCData user on the MCData client 1 418-1 is authorized to send an MCData group standalone FD request to the target MCData group and that the size of the file is below the maximum data size for FD from the group configuration. The MCData server 402 resolves the MCData group ID to determine the members of that group and their affiliation status, based on the information from a group management server 700.

[0072] 712: As defined in 3GPP TS 23.282 v17.5.0, the MCData server 402 sends the MCData group standalone

FD request towards each MCData user determined in step 710. In one embodiment, the MCData server 402 indicates in the request that MCData clients 2 to N 418-2 to 418-N accepting the request are required to provide a file download completed report to the MCData server 402.

[0073] 714: As defined in 3GPP TS 23.282 v17.5.0, the receiving MCData clients 2 to N 418-2 to 418-N notify the corresponding MCData users about the incoming MCData group standalone FD request when the request does not include a mandatory download indication. The request also includes the file URL and file metadata (if present). The target MCData users may accept, reject, or ignore the FD request.

[0074] 716: The MCData users on MCData clients 2 to N 418-2 to 418-N provide a response (accept or reject or ignore) to the request. The respective MCData clients 418-2 to 418-N then send respective MCData group standalone FD responses to the MCData server 402. Each of the MCData clients 2 to N 418-2 to 418-N automatically sends an accepted MCData group standalone FD response when the incoming request included a mandatory download indication. In one embodiment, the MCData clients 2 to N 418-2 to 418-N accepting the request also include in the respective responses information about the MCData client identification (e.g., IP address, port, MCData ID) and the target MCData content server (e.g., associated URI or IP address, port (e.g., standard port 80 for HTTP)) related to the download of the required file.

[0075] 718: In one embodiment, based on the received MCData group standalone FD response(s), the MCData server 402 decides to send a request to the cellular communications system 410 for allocation of dedicated network resources with a required QoS for each of the corresponding MCData clients 2 to N 418-2 to 418-N accepting the request. The dedicated resources will be then used for the file download communication between the corresponding MCData client 2 to N 418-2 to 418-N accepting the request and the MCData content server 404. For that, in one embodiment, the MCData server 402 utilizes the received information within the responses from the MCData clients 2 to N 418-2 to 418-N accepting the request, such as IP address and port associated to the corresponding MCData client, and URI and/or IP address, and port associated to the target MCData content server 404 and performs policy and charging control (PCC) procedures over the Rx reference point for the case of an EPS system, as described in 3GPP TS 23.203 and 3GPP TS 29.214, or over the N5 reference point for the case of a 5GS system, as described in 3GPP TS 23.501 and 3GPP TS 23.503.

[0076] 720: The MCData server 402 forwards the MCData group standalone FD response(s) to the MCData client

1 418-1. In one embodiment, the MCData server 402 removes, if present in the received MCData group standalone FD response(s), the information associated to the MCData client identification (e.g. IP address, port) , the target MCData content server (e.g., associated URI or IP address, port).

[0077] NOTE 1 : Step 718 can occur before step 716.

[0078] 722: The target MCData clients 418-2 to 418-N can proceed to directly download the file from the MCData content server 404 using HTTP without the involvement of the MCData server 402. The file download occurs either automatically (for mandatory download) or based upon the MCData user subsequent action. The MCData clients 2 to N 418-2 to 418-N that successfully download the file record the file download as completed and notify the MCData users. [0079] 724: In one embodiment, the MCData clients 2 to N 418-2 to 418-N that successfully download the file send an MCData download completed report to the MCData server 402 to indicate that the file download is completed. This report is used by the MCData server 402 to release the requested resources from the cellular communications system 410.

[0080] 726: As defined in 3GPP TS 23.282 v17.5.0, the MCData file download completed reports from the MCData clients 2 to N 418-2 to 418-N may be stored by the MCData server 402 for download history interrogation from authorized MCData users. The MCData file download completed report from each MCData user may be aggregated for the case that the MCData user on the MCData client 1 418-1 has requested to receive these reports.

[0081] 728: As defined in 3GPP TS 23.282 v17.5.0, an aggregated or individual MCData download completed report is sent by the MCData server 402 to the MCData user at MCData client 1 418-1, if requested by the MCData client 1 418-1.

[0082] 730: In one embodiment, the MCData server 402 sends a request to the cellular communication system

410 to the release the dedicated resources allocated for the corresponding file download based on received MCData download completed report(s).

[0083] NOTE 2: Step 730 can occur any time after step 724.

3 Additional Details

Figure 8

[0084] Figure 8 illustrates one example of the cellular communications system 410 of Figure 4 in accordance with one embodiment of the present disclosure. In the embodiments described herein, the cellular communications system 410 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC) or an Evolved Packet System (EPS) including an Evolved Universal Terrestrial RAN (E-UTRAN) and an Evolved Packet Core (EPC). In this example, the RAN includes base stations 802-1 and 802-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC) and in the EPS include eNBs, controlling corresponding (macro) cells 804-1 and 804-2. The base stations 802-1 and 802-2 are generally referred to herein collectively as base stations 802 and individually as base station 802. Likewise, the (macro) cells 804-1 and 804-2 are generally referred to herein collectively as (macro) cells 804 and individually as (macro) cell 804. The RAN may also include a number of low power nodes 806-1 through 806-4 controlling corresponding small cells 808-1 through 808-4.

The low power nodes 806-1 through 806-4 can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells 808-1 through 808-4 may alternatively be provided by the base stations 802. The low power nodes 806-1 through 806-4 are generally referred to herein collectively as low power nodes 806 and individually as low power node 806. Likewise, the small cells 808-1 through 808-4 are generally referred to herein collectively as small cells 808 and individually as small cell 808. The cellular communications system 800 also includes a core network 810, which in the 5G System (5GS) is referred to as the 5GC. The base stations 802 (and optionally the low power nodes 806) are connected to the core network 810. [0085] The base stations 802 and the low power nodes 806 provide service to wireless communication devices 812-1 through 812-5 in the corresponding cells 804 and 808. The wireless communication devices 812-1 through 812-5 are generally referred to herein collectively as wireless communication devices 812 and individually as wireless communication device 812. In the following description, the wireless communication devices 812 are oftentimes UEs, but the present disclosure is not limited thereto.

Figure 9

[0086] Figure 9 is a schematic block diagram of a network node 900 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The network node 900 may be, for example, a node that implements all or part of the functionality of the MCData server 402, the MCData content server 404, or the MCData message store 406, as described herein. As illustrated, the network node 900 includes one or more processors 904 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 906, and a network interface 908. The one or more processors 904 are also referred to herein as processing circuitry. The one or more processors 904 operate to provide one or more functions of the network node 900 as described herein (e.g., one or more functions of the MCData server 402, the MCData content server 404, or the MCData message store 406, as described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 906 and executed by the one or more processors 904.

Figure 10

[0087] Figure 10 is a schematic block diagram that illustrates a virtualized embodiment of the network node 900 according to some embodiments of the present disclosure. Again, optional features are represented by dashed boxes.

As used herein, a "virtualized” network node is an implementation of the network node 900 in which at least a portion of the functionality of the network node 900 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, the network node 900 includes one or more processing nodes 1000 coupled to or included as part of a network(s) 1002. Each processing node 1000 includes one or more processors 1004 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1006, and a network interface 1008. In this example, functions 1010 of the network node 900 described herein (e.g., one or more functions of the MCData server 402, the MCData content server 404, or the MCData message store 406, as described herein) are implemented at the one or more processing nodes 1000 or distributed across the two or more of the processing nodes 1000 in any desired manner. In some particular embodiments, some or all of the functions 1010 of the network node 900 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1000.

[0088] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 900 or a node (e.g., a processing node 1000) implementing one or more of the functions 1010 of the network node 900 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

Figure 11

[0089] Figure 11 is a schematic block diagram of the network node 900 according to some other embodiments of the present disclosure. The network node 900 includes one or more modules 1100, each of which is implemented in software. The module(s) 1100 provide the functionality of network node 900 described herein. This discussion is equally applicable to the processing node 1000 of Figure 10 where the modules 1100 may be implemented at one of the processing nodes 1000 or distributed across multiple processing nodes 1000.

Figure 12

[0090] Figure 12 is a schematic block diagram of a wireless communication device 1200 according to some embodiments of the present disclosure. The wireless communication device 1200 may be, for example, the MCData UE 408. As illustrated, the wireless communication device 1200 includes one or more processors 1202 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1204, and one or more transceivers 1206 each including one or more transmitters 1208 and one or more receivers 1210 coupled to one or more antennas 1212. The transceiver(s) 1206 includes radio-front end circuitry connected to the antenna(s) 1212 that is configured to condition signals communicated between the antenna(s) 1212 and the processor(s) 1202, as will be appreciated by on of ordinary skill in the art. The processors 1202 are also referred to herein as processing circuitry. The transceivers 1206 are also referred to herein as radio circuitry. In some embodiments, the functionality of the wireless communication device 1200 described above (e.g., one or functions of the MCData UE 408 described above) may be fully or partially implemented in software that is, e.g., stored in the memory 1204 and executed by the processor(s) 1202. Note that the wireless communication device 1200 may include additional components not illustrated in Figure 12 such as, e.g., one or more user interface components (e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker(s), and/or the like and/or any other components for allowing input of information into the wireless communication device 1200 and/or allowing output of information from the wireless communication device 1200), a power supply (e.g., a battery and associated power circuitry), etc.

[0091] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the wireless communication device 1200 according to any of the embodiments described herein (e.g., one or functions of the MCData UE 408 described above) is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

Figure 13

[0092] Figure 13 is a schematic block diagram of the wireless communication device 1200 according to some other embodiments of the present disclosure. The wireless communication device 1200 includes one or more modules 1300, each of which is implemented in software. The module(s) 1300 provide the functionality of the wireless communication device 1200 described herein (e.g., one or functions of the MCData UE 408 described above).

[0093] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0094] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

SOME EMBODIMENTS

Some embodiments described above may be summarized in the following manner:

1. A method comprising:

• at a Mission Critical, MC, data client (418): o sending (502; 602) an upload or download request to a MC data server (402), the upload or download request being a request to upload or download a particular file or message to or from a target MC data content server (404) or a target MC data message store (406);

• at the MC data server (402): o receiving (502; 602) the upload or download request from the MC data client (418); o determining (504; 606) whether the MC data client (418) is authorized to upload or download files or messages to or from the target MC data content server (404) or the target MC data message store (406); o sending (508; 610) a response to the MC data client (418) that indicates whether the MC data client (418) can proceed with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406), based on a result of the determining (504; 606) whether the MC data client (418) is authorized to upload or download files or messages to or from the target MC data content server (404) or the target MC data message store (406);

• at the MC data client (418): o receiving (508; 610) the response from the MC data server (402); and o proceeding with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) or not, in accordance with the response.

2. The method of embodiment 1 wherein the upload or download request comprises information about the MC data client (418) and information about the target MC data content server (404) or the target MC data message store (406).

3. The method of embodiment 2 wherein the information about the MC data client (418) comprises:

(a) information that identifies the MC data client (418),

(b) an Internet Protocol, IP, address of the MC data client (418),

(c) a port associated to the MC data client (418),

(d) a MC data identity, ID, associated to the MC data client (418), or

(e) a combination of any two or more of (a)-(d). 4. The method of embodiment 2 or 3 wherein the information about the target MC data content server (404) or the target MC data message store (406) comprises:

(i) information that identifies the target MC data content server (404) or the target MC data message store (406),

(ii) a Uniform Resource Indicator, URI, or Internet Protocol, IP, address associated to the target MC data content server (404) or the target MC data message store (406),

(iii) a port associated to the target MC data content server (404) or the target MC data message store (406), or

(iv) a combination of any two or more of (i)-(iii).

5. The method of any of embodiments 2 to 4 wherein the upload or download request further comprises metadata associated to the particular file or message.

6. The method of embodiment 5 wherein the metadata comprises a size of the particular file or message, a target MC data group ID, or both.

7. The method of any of embodiments 1 to 6 wherein:

• at the MC data sever (402): o determining (504; 606) whether the MC data client (418) is authorized to upload or download files or messages to or from the target MC data content server (404) or the target MC data message store (406) comprises determining (504; 606) that the MC data client (418) is authorized to upload or download files or messages to or from the target MC data content server (404) or the target MC data message store (406); and o the response sent to the MC data client (418) indicates that the MC data client (418) can proceed with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406); and

• at the MC data client (418): o proceeding with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) or not, in accordance with the response, comprises proceeding with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) via a cellular communications system (410).

8. The method of embodiment 7 further comprising:

• at the MC data sever (402): o responsive to determining (504; 606) that the MC data client (418) is authorized to upload or download files or messages to or the target MC data content server (404) or the target MC data message store (406), sending (506; 608) a request to the cellular communications system (410) for dedicated resources with a required Quality of Service, QoS, for the upload or download of the particular file or message via the cellular communications system (410);

• wherein, at the MC data client (418): o proceeding with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) via the cellular communications system (410) comprises proceeding with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) via the cellular communications system (410) using the requested dedicated resources with the required QoS.

9. The method embodiment 8 wherein the request sent to the cellular communications system (410) for the dedicated resources with the required QoS is based on information comprised in the upload or download request.

10. The method embodiment 8 or 9 further comprising:

• at the MC data client (418): o sending (516; 618) a message to the MC data server (402) that indicates that the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) is complete;

• at the MC data sever (402): o receiving (516; 618) the message from the MC data client (418) that indicates that the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) is complete; and o responsive to receiving (516; 618) the message, sending (518; 620) a request to release the dedicated resources to the cellular communications system (410).

11. The method of any of embodiments ? to 10 wherein:

• at the MC data client (418): o proceeding with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) via the cellular communications system (410) comprises:

^■ sending (510; 612), to the target MC data content server (404) or the target MC data message store (406) via the cellular communications system (410), an upload or download data request to upload for download the particular file or message to or from the target MC data content server (404) or the target MC data message store (406). The method of embodiment 11 further comprising:

• at the target MC data content server (404) or the target MC data message store (406): o receiving (510; 612), from the MC data client (418), the upload or download data request to upload or download the particular file or message to or from the target MC data content server (404) or the target MC data message store (406); o sending (514; 616) an upload or download data response to the MC data client (418). The method of embodiment 12 further comprising:

• at the target MC data content server (404) or the target MC data message store (406): o applying (512; 614) a control policy before either storing the particular file or message in the case of an upload request or providing the particular file or message to the MC data client (418) in the case of a download request. The method of any of embodiments 1 to 13 further comprising:

• at the MC data server (402): o determining (504; 606) whether a file size of the particular file is below a maximum allowable file size for file distribution from a corresponding service configuration and/or determining (504; 606) whether the MC data client (418) is authorized to upload or download a file targeting a corresponding MC data group; o wherein the response sent to the MC data client (418) that indicates whether the MC data client (418) can proceed with the upload or download of the particular file to or from the target MC data content server (404) is further based on:

^■ a result of the determining (504; 606) whether the file size of the particular file is below the maximum allowable file size for file distribution from the corresponding service configuration; and/or

^■ a result of the determining (504; 606) whether the MC data client (418) is authorized to upload or download a file targeting the corresponding MC data group. The method of any of embodiments 1 to 14 further comprising:

• at the MC data server (402): o verifying (604) whether the particular file or message is stored at the MC data content server (404) or the MC data message store (406); and/or o retrieving (604) information related to the particular file or message.

16. A method of operation of a Mission Critical, MC, data client (418) at a User Equipment, UE, (408), the method comprising: sending (502; 602) an upload or download request to a MC data server (402), the upload or download request being a request to upload or download a particular file or message to or from a target MC data content server (404) or a target MC data message store (406); receiving (508; 610) a response from the MC data server (402) that indicates whether the MC data client (418) can proceed with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406); and proceeding with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) or not, in accordance with the response.

17. The method of embodiment 16 wherein the upload or download request comprises information about the MC data client (418) and information about the target MC data content server (404) or the target MC data message store (406).

18. The method of embodiment 17 wherein the information about the MC data client (418) comprises:

(a) information that identifies the MC data client (418),

(b) an Internet Protocol, IP, address of the MC data client (418),

(c) a port associated to the MC data client (418),

(d) a MC data identity, ID, associated to the MC data client (418), or

(e) a combination of any two or more of (a)-(d).

19. The method of embodiment 17 or 18 wherein the information about the target MC data content server (404) or the target MC data message store (406) comprises:

(i) information that identifies the target MC data content server (404) or the target MC data message store (406),

(ii) a Uniform Resource Indicator, URI, or Internet Protocol, IP, address associated to the target MC data content server (404) or the target MC data message store (406),

(iii) a port associated to the target MC data content server (404) or the target MC data message store (406), or

(iv) a combination of any two or more of (i)-(iii).

20. The method of any of embodiments 17 to 19 wherein the upload or download request further comprises metadata associated to the particular file or message. 21. The method of embodiment 20 wherein the metadata comprises a size of the particular file or message, a target MC data group ID, or both.

22. The method of any of embodiments 16 to 21 wherein: the response received from the MC data server (402) indicates that the MC data client (418) can proceed with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406); and proceeding with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) or not, in accordance with the response, comprises proceeding with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) via a cellular communications system (410) responsive to the response indicating that the MC data client (418) can proceed with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406).

23. The method of embodiment 22 wherein proceeding with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) via the cellular communications system (410) comprises proceeding with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) via the cellular communications system (410) using requested dedicated resources with a required Quality of Service, QoS.

24. The method embodiment 23 further comprising: sending (516; 618) a message to the MC data server (402) that indicates that the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) is complete.

25. The method of any of embodiments 22 to 24 wherein proceeding with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) via the cellular communications system (410) comprises sending (510; 612), to the target MC data content server (404) or the target MC data message store (406) via the cellular communications system (410), an upload or download data request to upload or download the particular file or message to or from the target MC data content server (404) or the target MC data message store (406).

26. A user equipment (408) adapted to perform the method of any of embodiments 16 to 25. 27. A method performed by a Mission Critical, MC, data server (402), the method comprising: receiving (502; 602) an upload or download request from a MC data client (418), the upload or download request being a request to upload or download a particular file or message to or from a target MC data content server (404) or a target MC data message store (406); determining (504; 606) whether the MC data client (418) is authorized to upload or download files or messages to or from the target MC data content server (404) or the target MC data message store (406); sending (508; 610) a response to the MC data client (418) that indicates whether the MC data client (418) can proceed with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406), based on a result of the determining (504; 606) whether the MC data client (418) is authorized to upload or download files or messages to or from the target MC data content server (404) or the target MC data message store (406).

28. The method of embodiment 27 wherein the upload or download request comprises information about the MC data client (418) and information about the target MC data content server (404) or the target MC data message store (406).

29. The method of embodiment 28 wherein the information about the MC data client (418) comprises:

(a) information that identifies the MC data client (418),

(b) an Internet Protocol, IP, address of the MC data client (418),

(c) a port associated to the MC data client (418),

(d) a MC data identity, ID, associated to the MC data client (418), or

(e) a combination of any two or more of (a)-(d).

30. The method of embodiment 28 or 29 wherein the information about the target MC data content server (404) or the target MC data message store (406) comprises:

(i) information that identifies the target MC data content server (404) or the target MC data message store (406),

(ii) a Uniform Resource Indicator, URI, or Internet Protocol, IP, address associated to the target MC data content server (404) or the target MC data message store (406),

(iii) a port associated to the target MC data content server (404) or the target MC data message store (406), or

(iv) a combination of any two or more of (i)-(iii).

31. The method of any of embodiments 28 to 30 wherein the upload or download request further comprises metadata associated to the particular file or message. 32. The method of embodiment 31 wherein the metadata comprises a size of the particular file or message, a target MC data group ID, or both.

33. The method of any of embodiments 27 to 32 wherein: determining (504; 606) whether the MC data client (418) is authorized to upload or download files or messages to or from the target MC data content server (404) or the target MC data message store (406) comprises determining (504; 606) that the MC data client (418) is authorized to upload or download files or messages to or from the target MC data content server (404) or the target MC data message store (406); and the response sent to the MC data client (418) indicates that the MC data client (418) can proceed with the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406); and

34. The method of embodiment 33 further comprising: responsive to determining (504; 606) that the MC data client (418) is authorized to upload or download files or messages to or the target MC data content server (404) or the target MC data message store (406), sending (506; 608) a request to the cellular communications system (410) for dedicated resources with a required Quality of Service, QoS, for the upload or download of the particular file or message via the cellular communications system (410).

35. The method embodiment 34 wherein the request sent to the cellular communications system (410) for the dedicated resources with the required QoS is based on information comprised in the upload or download request.

36. The method embodiment 34 or 35 further comprising: receiving (516; 618) a message from the MC data client (418) that indicates that the upload or download of the particular file or message to or from the target MC data content server (404) or the target MC data message store (406) is complete; and responsive to receiving (516; 618) the message, sending (518; 620) a request to release the dedicated resources to the cellular communications system (410).

37. The method of any of embodiments 27 to 36 further comprising: determining (504; 606) whether a file size of the particular file is below a maximum allowable file size for file distribution from a corresponding service configuration and/or determining (504; 606) whether the MC data client (418) is authorized to upload or download a file targeting a corresponding MC data group; wherein the response sent to the MC data client (418) that indicates whether the MC data client (418) can proceed with the upload or download of the particular file to or from the target MC data content server (404) is further based on: a result of the determining (504; 606) whether the file size of the particular file is below the maximum allowable file size for file distribution from the corresponding service configuration; and/or a result of the determining (504; 606) whether the MC data client (418) is authorized to upload or download a file targeting the corresponding MC data group.

38. The method of any of embodiments 27 to 37 further comprising: verifying (604) whether the particular file or message is stored at the MC data content server (404) or the MC data message store (406); and/or retrieving (604) information related to the particular file or message.

39. A network node (900) adapted to perform the method of any of embodiments 27 to 38.

40. A method comprising:

• at each of one or more Mission Critical, MC, data clients (418-2 to 418-N): o receiving (712), from a MC data server (402), a MC data group standalone request or a MC data standalone request; o sending (716), to the MC data server (402), a MC data group standalone response or a MC data standalone response;

• at the MC data server (402): o receiving (716) one or more MC data group standalone responses or one or more MC data standalone responses from the one or more MC data clients (418-2 to 418-N), respectively; o responsive to receiving (716) the one or more MC data group standalone responses or the one or more MC data standalone responses from the one or more MC data clients (418-2 to 418-N), respectively:

^■ sending (718) a request to the cellular communications system (410) for dedicated resources with a required Quality of Service, QoS, for download of a file from a MC data content server (404) to at least one of the one or more MC data clients (418-2 to 418-N) via the cellular communications system (410).

41. The method of embodiment 40 wherein the at least one of the one or more MC data clients (418-2 to 418-N) consists of at least one of the one or more MC data clients (418-2 to 418-N) for which the respective MC data group standalone response or the respective MC data standalone response indicates an acceptance of the MC data group standalone request or the MC data standalone request. 42. The method of embodiment 40 or 41 further comprising, at each of the at least one of the one or more MC data clients (418-2 to 418-N), downloading the file from the MC data content server (404) via the cellular communications system (410) using the dedicated resources.

43. The method of any of embodiments 40 to 42 further comprising:

• at a MC data client (418-1): o sending (704), to the MC data server (402), a MC data group standalone file distribution, FD, request or a MC data standalone FD request;

• at the MC data server (402): o receiving (704), from the MC data client (418-1), the MC data group standalone FD request or the MC data standalone FD request; o sending (712), to the one or more MC data clients (418-2 to 418-N), the MC data group standalone request or the MC data standalone request responsive to receiving (704) the MC data group standalone FD request or the MC data standalone FD request.

44. The method of any of embodiments 40 to 43 further comprising:

• at the MC data server (402): o receiving (724), from the at least one of the one or more MC data clients (418-2 to 418-N), a download completed report; o sending (730), to the cellular communications system (410), a request to release the dedicated resources responsive to receiving (724) the download completed report from the at least one of the one or more MC data clients (418-2 to 418-N).

45. The method of any of embodiments 40 to 44 further comprising:

• at the MC data server (402): o verifying (708) that a particular file or message requested by the MC data group standalone request or the MC data standalone request is stored by a respective MC data content server (404) or a respective MC data message store (406), prior to sending the MC data group standalone response or the MC data standalone response.

46. The method of any of embodiments 40 to 45 further comprising:

• at the MC data server (402): o sending (720) the one or more MC data group standalone responses or the one or more MC data standalone responses received from the one or more MC data clients (418-2 to 418-N) to the MC data client (418-1). 47. A method of operation of a Mission Critical, MC, data client (418-2) at a User Equipment, UE, (408), the method comprising: receiving (712), from a MC data server (402), a MC data group standalone request or a MC data standalone request, for download of a file from a MC data content server (404); and sending (716), to the MC data server (402), a MC data group standalone response or a MC data standalone response.

48. The method of embodiment 47 further comprising downloading the file from the MC data content server (404) via a cellular communications system (410).

49. The method of embodiment 47 further comprising downloading the file from the MC data content server (404) via a cellular communications system (410)using dedicated resources.

50. A user equipment (408) adapted to perform the method of any of embodiments 47 to 49.

51. A method performed by a Mission Critical, MC, data server (402), the method comprising: sending (712) one or more MC data group standalone requests or one or more MC data standalone requests to one or more MC data clients (418), respectively, for download of a particular file from a MC data content server (404); receiving (716) one or more MC data group standalone responses or one or more MC data standalone responses from the one or more MC data clients (418), respectively; responsive to receiving (716) the one or more MC data group standalone responses or the one or more MC data standalone responses from the one or more MC data clients (418), respectively: sending (718) a request to the cellular communications system (410) for dedicated resources with a required Quality of Service, QoS, for download of a file from a MC data content server (404) to at least one of the one or more MC data clients (418-2 to 418-N) via the cellular communications system (410).

52. The method of embodiment 51 wherein the at least one of the one or more MC data clients (418-2 to 418-N) consists of at least one of the one or more MC data clients (418-2 to 418-N) for which the respective MC data group standalone response or the respective MC data standalone response indicates an acceptance of the MC data group standalone request or the MC data standalone request.

53. The method of any of embodiments 51 to 52 further comprising: receiving (704), from a MC data client (418-1), a MC data group standalone file distribution, FD, request or the MC data standalone FD request, for the particular file; wherein sending (712) the one or more MC data group standalone requests or the one or more MC data standalone requests to the one or more MC data clients (418-2 to 418-N), respectively, comprises sending (712) the MC data group standalone request or the MC data standalone request to the one or more MC data clients (418-2 to 418-N), respectively, responsive to receiving (704) the MC data group standalone FD request or the MC data standalone FD request.

54. The method of any of embodiments 51 to 53 further comprising: receiving (724), from the at least one of the one or more MC data clients (418-2 to 418-N), a download completed report; and sending (730), to the cellular communications system (410), a request to release the dedicated resources responsive to receiving (724) the download completed report from the at least one of the one or more MC data clients (418-2 to 418-N).

55. The method of any of embodiments 51 to 54 further comprising: verifying (708) that a particular file or message requested by the MC data group standalone request or the MC data standalone request is stored by a respective MC data content server (404) or a respective MC data message store (406), prior to sending the MC data group standalone response or the MC data standalone response.

56. The method of any of embodiments 51 to 55 further comprising: sending (720) the one or more MC data group standalone responses or the one or more MC data standalone responses received from the one or more MC data clients (418-2 to 418-N) to the MC data client (418-1).

57. A network node (900) adapted to perform the method of any of embodiments 51 to 56.