WO2022013190A1

WO2022013190A1 - Providing stored files for mission critical data file distribution over multicast-broadcast multimedia services

Info

Publication number: WO2022013190A1
Application number: PCT/EP2021/069406
Authority: WO
Inventors: Camilo John SOLANO ARENAS
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2020-07-13
Filing date: 2021-07-13
Publication date: 2022-01-20
Anticipated expiration: 2023-01-13

Abstract

Some embodiments of the present disclosure are directed to a method by a MC data server. The method includes receiving a file distribution request from a first MC data client which is a member of a group of MC data clients registered for receiving MC data service. The file distribution request identifies a resource location of a file in a MC data content server that is to be distributed to the group of MC data clients. The method further includes deciding whether the MC data server or a BM-SC will fetch the file from a MC data content server for distribution through a MBMS session to the group of MC data clients within a MBMS coverage area.

Description

PROVIDING STORED FILES FOR MISSION CRITICAL DATA FILE DISTRIBUTION OVER MULTICAST-BROADCAST MULTIMEDIA SERVICES

FIELD

[0001] The present disclosure relates generally to communications services, and more particularly to Mission Critical (MC) communication services.

BACKGROUND

[0002] Mission Critical (MC) communication services are essential for the work performed by public safety users e.g. police and fire brigade. The MC communications service requires preferential handling compared to normal telecommunication services including handling of prioritized MC calls for emergency and imminent threats. Furthermore, the MC communication services requires several resilience features that provides a guaranteed service level even if part of the network or backhaul infrastructure fails.

[0003] 3GPP based networks supporting Mission Critical (MC) services like Mission Critical Push To Talk (MCPTT), Mission Critical Data (MC data or MCData) and Mission Critical Video (MCVideo) are specified in 3GPP TS 23.280 v17.2.0, 3GPP TS 23.379 v17.2.0, 3GPP TS 23.281 v17.2.0 and 3GPP TS 23.282 v17.2.1.

[0004] Each MC service supports several types of communications amongst the MC users, e.g. group communications and one-to-one communications. Furthermore, MC services can be provided by utilizing different transmission modes. One important aspect in MC services is that in group communications the same information is delivered to multiple users. If many users are located within the same area, multicast-broadcast based transmissions using e.g. Multicast-Broadcast Multimedia Services (MBMS) is more efficient. In 3GPP LTE, broadcast transmissions across multiple cells is defined as evolved MBMS.

[0005] The Group Communication System Enablers (GCSE) architecture is developed for the group communication which is utilized by public safety for mission critical services. The GCSE architecture is specified in 3GPP TS 23.468 v15.0.1 . Based on the GCSE architecture, a Group Communication System (GCS) application server (AS), e.g. an MCPTT server or MC data server, uses EPS bearer services and can use in addition MBMS bearer services for transferring application signaling and data between the GCS AS and the user equipment (UEs). In uplink direction, the UE uses an EPS bearer service to exchange application signaling with the GCS AS or when it wants to send data to the GCS AS. In downlink direction the GCS AS may transfer application signaling and data via the UE individual EPS bearer services and/or via MBMS bearer services. The UEs register with their GCS AS using application signaling for participating in one or multiple groups, e.g. MCPTT groups.

Figure 1

[0006] The MC service architecture, based on the GCSE architecture, with the MC service server assuming the role of the GCS AS, is shown in the figure below, as described in 3GPP TS 23.280. Figure 1 is a block diagram of an example MC service architecture supporting unicast and MBMS transmissions. The MC service architecture includes a MC service client 105, which may be an application executed by a user equipment (UE) 100, a MC service server 140, and an E-UTRAN 110 which may provide a unicast path 120 and a MBMS path 130 for communications with the MC service server 140.

[0007] When MBMS bearer services are used, i.e. when the MBMS path is used, the GCS AS transfers data to different groups over a single MBMS broadcast bearer. For that, the MC service server establishes the MBMS bearer services with the Broadcast-Multicast - Service Centre (BM-SC) (as described in 3GPP TS 23.468 v15.0.1). The application signaling and data transferred via MBMS bearer(s) are transparent to the BM-SC and the MBMS bearer service. The GCS AS provides the UEs via application signaling with all configuration information that the UE needs to receive application data over MBMS bearer services and to handle that data appropriately.

[0008] This architecture works for MCPTT and MCVideo services. However, the MBMS bearer service offered by the GCSE architecture may not be enough for all MC data service. Therefore, the MBMS user service architecture, specified in 3GPP TS 26.346 v16.4.1, can instead be utilized, e.g. for the MC data file distribution. The MBMS user service architecture offers a set of delivery methods to applications. The MBMS download delivery method is used for the delivery of files over MBMS sessions and provides reliability control by means of forward-error-correction techniques and associated delivery procedures such as file-repair.

Figure 2

[0009] The MC data service can use the MBMS download delivery method for file distribution based on the MBMS user service architecture. The MC data architecture implementing the GCSE architecture as well as the MBMS user service architecture is shown in the figure below (as described in 3GPP TS 23.282). Figure 2 is a block diagram of an example MC data architecture supporting unicast and MBMS transmissions.

Figure 3

[0010] As described in 3GPP TS 23.282, for the support of the file distribution capability, the MC data functional model is described below. Figure 3 is a block diagram of an example MC data application plane functional model for file distribution.

[0011] As shown in the Figure 3, the MC data functional model for file distribution (FD) contains an MC data content server that provides a repository area for authorized MC data users to temporarily store files that are intended to be distributed to other MC data users. MC data users can request to the MC data server to distribute a file stored in the MC data content server to another MC data user or to an MC data group targeting several MC data users. For the distribution of a file targeting a group of MC data users, the MC data server can decide to distribute the file over MBMS.

[0012] The example MC data functional model includes a MC data server 340, a MC data UE 300, a MC data content server 320 containing a media storage function 325, and a MC data message store 330. The MC data server 340 can include a file distribution (FD) function 342 and a transmission/reception control 344. The MC data UE 300 can include a MC data client 310 that includes a FD function 314, a media storage client 314, and a message store client 316. The MC data UE 300 communicates model elements through an EPS 350.

[0013] As specified in 3GPP TS 23.282, MC data-FD-1 reference point is used for MC data application signalling for establishing a session in support of MC data file distribution. The bearer is also used for both uplink and downlink unicast data (e.g., URL associated to file, file download completed report).

[0014] MC data-FD-2 reference point carries uplink and downlink unicast file data between the FD functions of the MC data server and the MC data UE.

[0015] MC data-FD-3 reference point carries downlink multicast file data from the FD function of the MC data server to the FD function of the MC data UE.

[0016] MC data-FD-4 reference point carries uplink and downlink unicast file data between the media storage function of the MC data Content server and the media storage client of the MC data UE.

[0017] MC data-FD-5 reference point supports the MC data server to access the stored files in the MC data content server for certain file distribution functions, such as retrieval a file to be distributed through multicast etc. This reference points also supports any necessary operational requirements. [0018] The MC data-7 reference point, which exists between the Message store client and the MC data message store, is used by the Message store client to manage the information stored in the MC data message store, to subscribe to changes in the MC data message store and to synchronize between the MC data client and the MC data message store.

[0019] The MC data-8 reference point, which exists between the MC data server and the MC data message store, is used by the MC data server to access and manage the MC data message store such as creating MC data user folders and depositing the communications history.

[0020] For the case that the MBMS user service architecture is used over the xMB interface (specified in 3GPP TS 26.348 v16.3.0), two modes, push or pull ingest modes, can be defined by the MC data server to ingest the file into the BM-SC for distribution over MBMS sessions.

[0021] Embodiments of present disclosure are described within the context of a 3GPP-based LTE network, i.e. an EPS including E-UTRAN and EPC. However, the problems and solutions described herein are equally applicable to wireless access networks and user-equipment (UE) implementing other access technologies and standards (e.g. a 5G system including 5G core and 5G radio access). LTE is used as an example technology where the invention is suitable and using LTE in the description therefore is particularly useful for understanding the problem and solutions solving the problem.

SUMMARY

[0022] Some embodiments of the present disclosure are directed to a method by a MC data server. The method includes receiving a file distribution request from a first MC data client which is a member of a group of MC data clients registered for receiving MC data service. The file distribution request identifies a resource location of a file in a MC data content server that is to be distributed to the group of MC data clients. The method further includes deciding whether the MC data server or a BM-SC will fetch the file from a MC data content server for distribution through a MBMS session to the group of MC data clients within a MBMS coverage area.

[0023] Some other corresponding embodiments of the present disclosure are directed to a method by a BM-SC. The method includes receiving a file from a MC data server. The method further includes distributing the file through a MBMS session to a group of MC data clients registered for receiving MC data service and which are within a MBMS coverage area. [0024] Some other corresponding embodiments of the present disclosure are directed to a method by a BM-SC. The method includes receiving from a MC data server a resource location for a file to be distributed to a group of MC data clients. The method further includes fetching the file from the resource location in a MC data content server. The method further includes distributing the file through a MBMS session to the group of MC data clients registered for receiving MC data service and which are within a MBMS coverage area.

[0025] Corresponding embodiments of the apparatuses are disclosed herein.

[0026] Some apparatus embodiments of the present disclosure are directed to a MC data server. The MC data server is operative to receive a file distribution request from a first MC data client which is a member of a group of MC data clients registered for receiving MC data service. The file distribution request identifies a resource location of a file in a MC data content server that is to be distributed to the group of MC data clients. The MC data server is further operative to decide whether the MC data server or a BM-SC will fetch the file from a MC data content server for distribution through a MBMS session to the group of MC data clients within a MBMS coverage area.

[0027] Some other apparatus embodiments of the present disclosure are directed to a BM- SC. The BM-SC is operative to receive a file from a MC data server. The BM-SC is also operative to distribute the file through a MBMS session to a group of MC data clients registered for receiving MC data service and which are within a MBMS coverage area.

[0028] Some other apparatus embodiments of the present disclosure are directed to another BM-SC. The BM-SC is operative to receive from a MC data server a resource location for a file to be distributed to a group of MC data clients. The BM-SC is also operative to fetch the file from the resource location in a MC data content server. The BM-SC is also operative to distribute the file through a MBMS session to the group of MC data clients registered for receiving MC data service and which are within a MBMS coverage area.

[0029] Potential advantages of these embodiments include that operations by a MC data server and by a BM-SC are defined for reliably and resource efficiently distributing files over MBMS from a MC data content server to a group of MC data clients.

[0030] It is noted that aspects described with respect to one embodiment may be incorporated in different embodiments although not specifically described relative thereto. That is, all embodiments and/or features of any embodiments can be combined in any way and/or combination. Moreover, other MC data servers and BM-SCs and corresponding methods and computer program products according to embodiments will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such other MC data servers and BM- SCs and corresponding methods and computer program products be included within this description and protected by the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain nonlimiting embodiments of inventive concepts. In the drawings:

Figure 1 is a block diagram of an example MC service architecture supporting unicast and

MBMS transmissions;

Figure 2 is a block diagram of an example MC data architecture supporting unicast and MBMS transmissions;

Figure 3 is a block diagram of an example MC data application plane functional model for file distribution;

Figure 4 illustrates a flow diagram of file fetching by the MC data server for file distribution over

MBMS according to some embodiments of the present disclosure;

Figure 5 illustrates a flow diagram of file fetching by the BM-SC for file distribution over MBMS according to some embodiments of the present disclosure;

Figure 6 illustrates a flow diagram of file fetching by the BM-SC with authorization check for file distribution over MBMS according to some embodiments of the present disclosure; Figure 7 illustrates a block diagram of a node in accordance with some embodiments of the present disclosure;

Figure 8 is a flowchart of operations by a MC data server in accordance with some embodiments of the present disclosure; and

Figures 9 and 10 are flowcharts of operations by a BM-SC in accordance with some embodiments of the present disclosure. DETAILED DESCRIPTION

[0032] Inventive concepts will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present/used in another embodiment.

[0033] The following description presents various embodiments of the disclosed subject matter. These embodiments are presented as teaching examples and are not to be construed as limiting the scope of the disclosed subject matter. For example, certain details of the described embodiments may be modified, omitted, or expanded upon without departing from the scope of the described subject matter.

[0034] A problem arises with the MC data file distribution capability that includes an option for MC data users to request the MC data server to distribute a file stored in the MC data content server to one or several MC data users. However, the MC data service specification, i.e. 3GPP TS 23.282, does not specify how a file stored in the MC data content server is provided for distribution to the target MC data users over unicast or MBMS transmissions. Without defining any operations and methods for how file distribution shall be performed to MC data users, system instability may result as operational conflicting and/or incompatible implementations by different equipment providers are deployed in communication systems.

[0035] Various embodiments of the present disclosure define MC data methods that specify how a file stored in the MC data content server is provided for distribution to a group of MC data users over MBMS.

[0036] Potential advantages of these embodiments include that operations by a MC data server and by a BM-SC are defined for reliably and resource efficiently distributing files over MBMS from a MC data content server to a group of MC data clients.

[0037] Providing stored files in the MC data content server for distribution over MBMS will now be discussed below.

[0038] A first approach will now be discussed in which a MC data server is configured to fetch a file from a MC data content server to make the file available over MBMS to a BM-SC according to some embodiments of the present disclosure. Figure 4

[0039] Figure 4 illustrates a flow diagram of file fetching by the MC data server 404 for file distribution over MBMS according to some embodiments of the present disclosure.

[0040] When the MC data server 404 receives a file distribution request from MC data users to distribute a file stored in the MC data content server 406 to a group of MC data users, the MC data server 404 can decide to distribute the file over MBMS and to directly fetch the file from the MC data content server 406 over the MC data-FD-5 reference point, described in Figure 3 and specified in 3GPP TS 23.282. To directly fetch the file, the MC data server 404 uses the file URL provided by MC data users within the request. The MC data server 404, thus, enables via the xMB-U interface (specified in 3GPP TS 26.348) that the file is ingested, either by pull or push, into the BM-SC 400 for distribution over MBMS. The file also becomes available for the case that the MC data server 404 decides to distribute the file over unicast transmissions to MC data users within the target group.

[0041] When the MC data server 404 defines a pull ingest mode, the MC data server 404 provides via the xMB-C interface the resource location from which the BM-SC 400 will fetch the file as well as other session properties (e.g. file earliest fetch time), as described in 3GPP TS 26.348.

[0042] When the MC data server 404 defines a push ingest mode, the MC data server 404 directly ingests, i.e. pushes, into the BM-SC 400 via the xMB-U interface the file obtained from the MC data content server 406). The BM-SC 400 shall provide to the MC data server 404 the URL to be used to push the file(s). For the push ingest mode, the MC data server 404 is always the one ingesting the file content into the BM-SC 400 via the xMB-U interface.

[0043] The MC data server 404 can decide to define a pull ingest mode to avoid overloading the BM-SC 400 by pushing files that cannot be directly handled by the BM-SC 400. This case may be preferred, e.g., when the MC data server 404 requires to distribute several files over the same MBMS session. Thereby, the BM-SC 400 can decide to pull the corresponding files as early as it can manage it for distribution over the MBMS session.

[0044] The procedure in Figure 4 is directed to the operational case where the file to be distributed over MBMS is fetched by the MC data server 404 from the MC data content server 406.

[0045] A precondition to performing this operational case may include that the MC data users on the MC data client 402a to MC data client n 402n belong to the same MC data group X and are already registered and affiliated for receiving MC data service.

[0046] The file to be distributed is uploaded to the MC data content server 406. [0047] With continued reference to Figure 4, in operation 410 the MC data server 404 receives a request from the MC data user on MC data client 402a to distribute a file to the MC data group X. The MC data file distribution request contains the resource location, i.e. the file URL) in the MC data content server 406.

[0048] In operation 412, the MC data server 404 fetches the file from the MC data content server 406 via the MC data-FD-5 reference point.

[0049] In operation 414, the MC data server 404 creates an MBMS service and session for file delivery using xMB procedures via the xMB-C interface, as described in 3GPP TS 26.348. The MC data server 404 indicates, among other session properties, the ingest mode, i.e. push or pull. For the case of pull ingest mode, the MC data server 404 provides the file URL from which the BM-SC 400 will fetch the file. For the case of push ingest mode, the BM-SC 400 provides to the MC data server 404 the URL to be used to push the file into the MBMS session.

[0050] Note that operation 414 may also occur before operation 412.

[0051] In operation 416, the MC data server 404 provides the MC data users from the target MC data group X the application signalling related to the MBMS session and the file distribution, as described in 3GPP TS 23.282.

[0052] In operation 418, the file is ingested into the BM-SC 400 via the xMB-U interface.

[0053] In operation 418, when push ingest mode 420 is defined, the MC data server 404 pushes the file to the URL indicated by the BM-SC 400.

[0054] Alternatively, in operation 418, when pull ingest mode 422 is defined, the BM-SC 400 pulls the file from the MC data server 404 based on the provided file URL.

[0055] In operation 424, the BM-SC 400 distributes the file over the established MBMS session. When the target MC data client 402a, 402b, 402n have activated the reception for that service and are located within the MBMS area coverage, the MC data client 402a, 402b, 402n receive the file, i.e. each MC data UE within the MBMS coverage area that hosts a MC data client that has activated said reception will receive the file.

[0056] The MC Data server 404 is responsible for deciding if the MC data server 404 or the BM-SC 400 gets the file directly from the MC data content server 406. If the MC Data server 404 decides the MC data server 404 is to get the file directly from the MC data content server 406, then the BM-SC 400 does not communicate with the MC data content server 406. [0057] The MC Data server 404 is also responsible for deciding if the ingest mode in operation 418 will be a push ingest mode 420 or a pull ingest mode 422.

[0058] A more general implementation of the operations illustrated in Figure 4 are discussed further below regarding Figures 8 and 9.

[0059] A second approach will now be discussed in which a BM-SC 400 is configured to fetch a file from a MC data content server over MBMS using information received from a MC data server 404 according to some embodiments of the present disclosure.

Figure 5

[0060] Figure 5 illustrates a flow diagram of file fetching by the BM-SC 400 for file distribution over MBMS according to some embodiments of the present disclosure.

[0061] When the MC data server 404 receives a file distribution request from MC data users to distribute a file stored in the MC data content server 406 to a group of MC data users, the MC data server 404 can decide to distribute the file over MBMS and to decide a pull ingest mode. In this case, the MC data server 404 can alternatively decide providing to the BM-SC 400 the received resource location in the MC data content server 406, i.e. the file URL contained within the file distribution request. Thereby, the MC data server 404 decides that the BM-SC 400 directly fetches the file from the MC data content server 406.

[0062] In order to enable that the BM-SC 400 fetches the file from the MC data content server 406, the MC data content server 406 supports the xMB-U interface to the BM-SC 400. Supporting the xMB-U interface at the MC data content server 406 does not introduce higher complexity since it is an HTTP based interface (HTTP is supported by the MC data content server 406).

[0063] In this case where the file is ingested into the BM-SC 400 from the MC data content server 406, only the pull ingest mode is supported. When push ingest mode is required, the solution described above for that mode may be used. Flence, it is avoided that higher complexity is implemented between the MC data server 404 and the MC data content server 406 to enable that the MC data content server 406 pushes the file into the BM-SC 400 at the correct required time.

[0064] As explained, the procedure in Figure 5 corresponds to the case where the file to be distributed over MBMS is fetched by the BM-SC 400 from the MC data content server 406. Pre-conditions to this procedure may include that the MC data users on the MC data client 402a to n belong to the same MC data group X and are already registered and affiliated for receiving MC data service; and the file to be distributed is uploaded to the MC data content server 406. [0065] Referring to Figure 5, in operation 510 the MC data server 404 receives a request from the MC data user on MC data client 402a to distribute a file to the MC data group X. The MC data file distribution request contains the resource location i.e. the file URL in the MC data content server 406.

[0066] In operation 512, the MC data server 404 creates an MBMS service and session for file delivery using xMB procedures via the xMB-C interface (3GPP TS 26.348). The MC data server 404 defines, among other session properties, the ingest mode to pull. The MC data server 404 provides the file URL from which the BM-SC 400 will fetch the file from the MC data content server 406.

[0067] In operation 514, the MC data server 404 provides the MC data users from the target MC data group X the application signalling related to the MBMS session and the file distribution, as described in 3GPP TS 23.282.

[0068] In operation 516, the BM-SC 400 fetches the file from the MC data content server 406 via the xMB-U interface.

[0069] In operation 518, the BM-SC 400 distributes the file over the established MBMS session. When the target MC data client 402a, 402b, 402n have activated the reception for that service and are located within the MBMS area coverage, the MC data client 402a, 402b, 402n receive the file, i.e. each MC data UE within the MBMS coverage area and that hosts a MC data client that has activated said reception will receive the file.

[0070] A more general implementation of the operations illustrated in Figure 5 will be discussed further below with reference to Figures 8 and 10.

Figure 6

[0071] Figure 6 illustrates another flow diagram of file fetching by the BM-SC 400 with authorization check for file distribution over MBMS according to some embodiments of the present disclosure. Figure 6 differs from Figure 5 by adding a file fetching authorization process that may be performed by the MC data content server 406 (operations 618) or by the MC data server 404 (operations 620 and 622).

[0072] When the BM-SC 400 directly fetches the file from the MC data content server 406, as described in the aforementioned section, the MC data content server 406 may be required to verify if the requested file can be provided or not to the BM-SC 400. For that and taking into consideration that the xMB-U interface is an HTTP interface, i.e. the fetch file request is based on HTTP, the BM-SC 400 and MC data content server 406 can perform the authentication and authorization procedures following existing mechanisms, which may use the xMB procedures in 3GPP TS 29.116. [0073] Another mechanism can be based on URL signing, where the BM-SC 400 provides a secret key to the MC data content server 406 to securely sign into the file URL. For when the MC data server 404 decides that the file is pulled by the BM-SC 400 from the MC data content server 406 for distribution over MBMS, the MC data server 404 requests the MC data content server 406 a secret key to access the corresponding file URL. The MC data server 404 provides this secret key to the BM-SC 400 during the MBMS session creation request.

[0074] As an alternative mechanism, upon the reception at the MC data content server 406 of a file request from the BM-SC 400, the MC data content server 406 sends a file fetching authorization request to the MC data server 404 to obtain an authorization response. The file fetching authorization request contains the MBMS session ID and file URL, which need to be provided by the BM-SC 400 within the file request. The MC data content server 406 may also include within the file fetching authorization request additional information like MC data group ID related to the stored file (if known by the MC data content server 406. Based on the information provided within the file fetching authorization request, the MC data server 404 decides and response to the MC data content server 406 if the requested file is authorized to be fetched by the requesting BM-SC 400.

[0075] The procedure in Figure 6 is directed to the case where the file to be distributed over MBMS is fetched by the BM-SC 400 from the MC data content server 406. The MC data content server 406 performs an authorization check to determine if the requested file is authorized to be fetched by the BM-SC 400.

[0076] Pre-conditions that may be required before the operations of Figure 6 are performed may include: the MC data users on the MC data client 402a to n belong to the same MC data group X and are already registered and affiliated for receiving MC data service; and the file to be distributed is uploaded to the MC data content server 406.

[0077] Referring to Figure 6, in operation 510 the MC data server 404 receives a request from the MC data user on MC data client 402a to distribute a file to the MC data group X. The MC data file distribution request contains the resource location (i.e. the file URL) in the MC data content server 406.

[0078] In operation 512, the MC data server 404 creates an MBMS service and session for file delivery using xMB procedures via the xMB-C interface (3GPP TS 26.348). The MC data server 404 defines, among other session properties, the ingest mode to pull. The MC data server 404 provides the file URL from which the BM-SC 400 will fetch the file from the MC data content server 406. [0079] In operation 514, the MC data server 404 provides the MC data users from the target MC data group X the application signalling related to the MBMS session and the file distribution, as described in 3GPP TS 23.282.

[0080] In operation 516, the BM-SC 400 fetches the file from the MC data content server 406 via the xMB-U interface. For that, the MC data content server 406 performs an authorization check to determine if the requested file can be provided. If authorized, the file is provided to the BM-SC 400.

[0081] As an authorization check alternative, the MC data content server 406 performs authentication and authorization procedures 618, such as based on authentication and authorization procedures defined in 3GPP TS 29.116 or URL signing.

[0082] Another authorization check alternative, illustrated in operations 620 and 622, the MC data content server 406 sends 620 a file fetching authorization request to the MC data server 404. The authorization is based on the received file fetching authorization response 622.

[0083] In operation 518, the BM-SC 400 distributes the file over the established MBMS session. When the target MC data client 402a, 402b, 402n have activated the reception for that service and are located within the MBMS area coverage, the MC data client 402a, 402b, 402n receive the file, i.e. each MC data UE within the MBMS coverage area and that hosts a MC data client that has activated said reception will receive the file.

[0084] A more general implementation of the operations illustrated in Figure 6 will be discussed further below with reference to Figures 8 and 10.

[0085] Figures 4, 5, and 6 has been illustrated and described according to a rather particular example implementation. Some of the operations may be optimal. A more general implementation of the operations by the MC data server and BM-SC is illustrated in the flow charts of Figures 8, 9, and 10.

Figure 8

[0086] Figure 8 illustrates a flowchart of operations by a MC data server 404 in accordance with some embodiments of the present disclosure.

[0087] Referring to Figures 4 and 8, some embodiments of the present disclosure are directed to operations performed by a MC data server 404. The MC data server 404 is operative to receive 410, 800 a file distribution request 410, 510 from a first MC data client 402a which is a member of a group of MC data clients 402a, 402b, 402n registered for receiving MC data service. The file distribution request identifies a resource location (e.g., a uniform resource locator (URL)) of a file in a MC data content server 406 that is to be distributed to the group of MC data clients 402a, 402b, 402n. The MC data server 404 is further operative to decide 802 whether the MC data server 404 or a BM-SC 400 will fetch the file from a MC data content server 406 for distribution 424, 518 through a MBMS session to the group of MC data clients 402a, 402b, 402n within a MBMS coverage area.

[0088] Some further embodiments are directed to the MC data server 404 being further operative to fetch the file from the MC data content server 406 for distribution 424 through the MBMS session to the group of MC data clients 402a, 402b, 402n based on deciding 802 the MC data server 404. The MC data server 404 is also further operative to send 413a a request file message to the MC data content server 406 requesting the file from the resource location. The MC data server 404 is also further operative to receive 413b the file from the MC data content server 406 responsive to the request file message. The MC data server 404 is also further operative to communicate 418 the file through the MBMS session to the BM-SC 400 for distribution 424 to the group of MC data clients 402a, 402b, 402n within the MBMS coverage area.

[0089] In some further embodiments, the sending 413a the request file message to the MC data content server 406 uses a MCData-FD-5 reference point.

[0090] In some further embodiments, the communicating 418 of the file through the MBMS session to the BM-SC 400 for distribution 424 to the group of MC data clients 402a, 402b, 402n within the MBMS coverage area includes receiving a uniform resource locator URL from the BM-SC 400. The communicating 418 further includes pushing 420 the file to the URL for distribution 424 through the MBMS session.

[0091] In some further embodiments, the communicating 418 of the file through the MBMS session to the BM-SC 400 for distribution 424 to the group of MC data clients 402a, 402b, 402n within the MBMS coverage area includes communicating 418 to the BM-SC 400 a URL indicating a location of the file on the MC data server 404. The communicating 418 further includes receiving 423a from the BM-SC 400 a request message containing the URL. The communicating 418 further includes communicating 423b the file at the URL to the BM-SC 400.

[0092] Some further embodiments are directed to the MC data server 404 further operative to fetch the file from the MC data content server 406 for distribution 518 through the MBMS session to the group of MC data clients 402a, 402b, 402n based on deciding 802 the BM-SC 400. The MC data server 404 is also further operative to communicate 512 the resource location of the file to the BM-SC 400 to fetch the file for distribution 518 to the group of MC data clients 402a, 402b, 402n. [0093] In some further embodiments, communicating 512 of the resource location of the file to the BM-SC 400 to fetch the file for distribution 518 to the group of MC data clients 402a, 402b, 402n includes creating a multicast-broadcast multimedia services, MBMS, service and MBMS session for file distribution 518 using xMB procedures via a xMB-C interface.

[0094] In some further embodiments, the creating of the MBMS service and MBMS session comprises defining session properties that include identifying the resource location of the file.

[0095] In some further embodiments, the MBMS service and MBMS session creation comprises defining session properties that identify whether the BM-SC 400 is to push or pull the file from the MC data content server 406.

[0096] Some further embodiments are directed to the MC data server 404 further operative to receive 620 a file authorization request from the MC data content server 406, the file authorization request comprises a MBMS session identification and the resource location of the file in the MC data content server 406. The MC data server 404 is also further operative to generate a file authorization response indicating whether the MBMS session identification is authorized to fetch the resource location of the file in the MC data content server 406. The MC data server 404 is also further operative to communicate 622 the file authorization response to the MC data content server 406.

[0097] In some further embodiments, the file distribution request 410, 510 contains a resource location of the file in the MC data content server 406.

[0098] Some embodiments of the present disclosure are directed to a computer program product comprising a non-transitory computer readable medium storing instructions executable by at least one processor of a MC data server 404 to operate the at least one processor to perform the operations of any of the embodiments discussed above.

Figure 9

[0099] Figure 9 illustrates a flowchart of operations by a BM-SC 400 in accordance with some embodiments of the present disclosure.

Referring to Figures 4 and 9, some embodiments of the present disclosure are directed to operations performed by a BM-SC 400. The BM-SC 400 is operative to receive 420, 423b, 900 a file from a MC data server 404. The BM-SC 400 is also operative to distribute 424, 902 the file through a MBMS to a group of MC data clients 402a, 402b, 402n registered for receiving MC data service and are within a MBMS coverage area. [0100] In some further embodiments, the receiving of the file through the MBMS session includes communicating a URL to the MC data server 404, and receiving 420 the file from the MC data server 404.

[0101] In some further embodiments, the receiving of the file through the MBMS session includes receiving a URL indicating a location of the file in the MC data server 404 from the MC data server 404. The receiving of the file through the MBMS session also includes communicating 423a a request message containing the URL to the MC data server 404, and receiving 423b the file from the MC data server 404 responsive to the request message.

[0102] Some embodiments of the present disclosure are directed to a computer program product comprising a non-transitory computer readable medium storing instructions executable by at least one processor of a BM-SC 400 to operate the at least one processor to perform the operations of any of the embodiments discussed above.

Figure 10

[0103] Figure 10 illustrates a flowchart of operations by a BM-SC 400 in accordance with some embodiments of the present disclosure.

[0104] Referring to Figures 5 and 10, some embodiments of the present disclosure are directed to operations performed by a BM-SC 400. The BM-SC 400 is operative to receive 512, 1000 from a MC data server 404 a resource location for a file to be distributed to a group of MC data clients 402a, 402b, 402n. The BM-SC 400 is also operative to fetch 516, 1002 the file from the resource location in a MC data content server 406. The BM-SC 400 is also operative to distributing 518, 1004 the file through a MBMS to the group of MC data clients 402a, 402b, 402n registered for receiving MC data service and are within a MBMS coverage area.

[0105] In some further embodiments, the fetching 516 of the file from the resource location in the MC data content server 406 is performed through a xMB-U interface.

[0106] In some further embodiments, the receiving 512 from the MC data server 404 the resource location for the file comprises creating a MBMS service and the MBMS session for file distribution using xMB procedures via a xMB-C interface. The creating of the MBMS service and MBMS session comprises defining session properties that include identifying the resource location of the file in the MC data content server 406. [0107] In some further embodiments, the MBMS service and session creation comprises defining session properties that include whether the BM-SC 400 is to push or pull the file from the MC data content server 406.

[0108] Some embodiments of the present disclosure are directed to a computer program product comprising a non-transitory computer readable medium storing instructions executable by at least one processor of a BM-SC 400 to operate the at least one processor to perform the operations of any of the embodiments discussed above.

Figure 7

[0109] Figure 7 illustrates a block diagram of a node 700 in accordance with some embodiments of the present disclosure. The node 700 which may be configured to implement any of the BM-SC 400, MC data clients 402a, 402b, 402n, MC data server 404, and/or the MC data content server 406 and contain elements that are configured according to one or more embodiments disclosed herein.

The network node 700 can include one or more network interfaces 730 referred to as "network interface" for brevity, one or more processors 710 referred to as "processor" for brevity, and one or more memories 720 referred to as "memory" for brevity containing program code 722.

[0110] The network interface 730 may be configured to communicate through a wired interface, e.g., Ethernet, and/or wireless interface, e.g., wireless transceiver, according to one or more proprietary protocols and/or industry standardized protocols, e.g., WiFi, 3GPP 4G, 5G NR, etc. The processor 710 may include one or more data processing circuits, such as a general purpose and/or special purpose processor e.g., microprocessor and/or digital signal processor that may be collocated or distributed across one or more networks. The processor 710 is configured to execute program code 722 in the memory 720, described below as a computer readable medium, to perform some or all of the operations and methods that are described above for one or more of the embodiments of a BM-SC 400, MC data clients 402a, 402b, 402n, MC data server 404, and/or the MC data content server 406, such as regarding one or more of the embodiments described herein.

[0111] Various of the above embodiments have been described in the context of the example nodes of the communications network shown in Figures 4-6. Flowever, these embodiments are limited thereto and may be embodied in any type of one or more network nodes of any type of communications network, such as a 4G/LTE or other 5G network.

[0112] Aspects of the present disclosure have been described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable instruction execution apparatus, create a mechanism for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

[0113] These computer program instructions may also be stored in a computer readable medium that when executed can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions when stored in the computer readable medium produce an article of manufacture including instructions which when executed, cause a computer to implement the function/act specified in the flowchart and/or block diagram block or blocks. The computer program instructions may also be loaded onto a computer, other programmable instruction execution apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatuses or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

[0114] It is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of embodiments of the present disclosure. Unless otherwise defined, all terms (including technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense expressly so defined herein.

[0115] The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various aspects of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0116] The terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting of the disclosure. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items. Like reference numbers signify like elements throughout the description of the figures.

[0117] The corresponding structures, materials, acts, and equivalents of any means or step plus function elements in the claims below are intended to include any disclosed structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present disclosure has been presented for purposes of illustration and description, but the description is not intended to be exhaustive or limited to the disclosure in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the disclosure. The aspects of the disclosure herein were chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure with various modifications as are suited to the particular use contemplated. [0118] APPENDIX

3GPP TSG-SA WG6 Meeting #38-e S6-200xxx e-meeting, 20^th - 31^st July 2020

(revision of S6-xxxxxx)

For HELP on using this form: comprehensive instructions can be found at http: //www.3gpp.org/Change-Requests.

Proposed change affects: UICC appsQ ME[X] Radio Access Network | | Core Network|^~X^~|

^{* * *} First change ^{* * *}

7.5.2.10.2 Procedure

The procedure in figure 7.5.2.10.2-1 describes the case where a MCData user is initiating group standalone data communication for sending file to multiple MCData users, with or without download completed report request.

Pre-conditions:

1. The MCData users on the MCData client 1 to n belong to the same group and are already registered for receiving MCData service and affiliated.

2. The file to be distributed is uploaded to the media storage function on the MCData content server using the procedure defined in subclause 7.5.2.2.

Figure 7.5.2.10.2-1: Group standalone FD using the MBMS download delivery method-4. Steps 1-4 are the same as in the procedure for Group standalone FD using HTTP (7.5.2.6). . The MCData server executes the procedure described in subclause 7.3.5. The MCData server defines, in the MBMS session properties (subclause 5.4 of 3GPP TS 26.348 [19]), the ingest mode to provide the file into the BM-SC via xMB-U. As described in clause 7.3.5.3.x, the MCData server decides how the file stored in the MCData content server is provided for distribution over the MBMS session.

If the pull ingest mode is defined, the MCData server may provide in this step the file list. As described in 3GPP TS 26.348 [19], the file list includes, among other information, the file URL to be used by the BM-SC to fetch the file and the earliest fetch time. The earliest fetch time shall be configured with a long enough delay so that the MBMS session is established and steps 6 to 8 are executed before the delivery over MBMS. The MCData server can also update the MBMS session with the file list in a later step.

If the push ingest mode is defined, the MCData server obtains the URL from the BM-SC to be used to push the file via xMB-U. The MCData server ingests the content into the BM-SC after the MBMS session is established and steps 6 to 8 are performed. . The MCData server initiates the MCData group standalone FD over MBMS request towards each MCData user determined in step 3. The request is sent over unicast or within an MBMS bearer for application level control signalling. 7. The receiving MCData clients 2 to n notify the users about the incoming MCData group standalone FD request (including file metadata, if present).

8. The MCData clients 2 to n automatically send accepted MCData group standalone FD response when the incoming request included mandatory download indication.

NOTE 1 : When the UE is in idle mode, MCData clients may skip step 8.

NOTE 2: If the pull ingest mode was defined in step 5 and the file list has not been provided yet, the MCData server updates the MBMS session with the file list. If the push ingest mode was defined, the MCData server can start pushing the file for distribution over MBMS.

9. The MCData server forwards the MCData group standalone FD responses to the MCData client 1.

NOTE 3 : Step 8 can occur at any time following step 6, and prior to step 10 depending on the conditions to proceed with the file transmission.

10. The MCData clients receive the file delivered over MBMS.

11. If losses occurred during the file delivery over MBMS, the MCData clients may download the missing parts using the procedures defined in subclause 7.5.2.3.

NOTE 4: If the file is not successfully received over MBMS, e.g. due to a poor MBMS reception quality, the media storage client of the MCData client(s) can download the file using the procedure defined in subclause 7.5.2.3.

12. The MCData clients, after a successful reception, initiate a MCData download completed report for reporting file download completed, if requested by the user at MCData client 1.

13. The MCData file download completed reports from the MCData clients may be stored by the MCData server for download history interrogation from authorized MCData users. The MCData file download completed report from each MCData user may be aggregated.

14. Aggregated or individual MCData download completed report is sent by the MCData server to the MCData user at MCData client 1.

3GPP TSG-SA WG6 Meeting #38-e S6-200xxx e-meeting, 20^th - 31^st July 2020

(revision of S6-xxxxxx)

For HELP on using this form: comprehensive instructions can be found at http: //www.3gpp. org/Change-Requests.

^{* * *} First change ^{* * *}

7.3.5.3.1.2 Procedure

Editor's note: The procedure in this clause needs to be revised considering that MBMS user services, as specified in 3GPP TS 26.346 [21], cannot be supported over the MB2 interface.

The procedure figure 7.3.5.3.1.2-1 shows only one of the receiving MCData clients using an MBMS user service.

Pre-conditions:

- The participating users are already affiliated.

Figure 7.3.5.3.1.2-1: Use of pre-established MBMS user service

1. The MCData server determines to create an MBMS user service with a given MBMS user service id. If the MCData server makes use of the xMB interface, the MCData server creates an MBMS user service over xMB-C (subclause 5.3 from 3 GPP TS 26.348 [19]).

NOTE 1: The procedure to determine the creation of MBMS user services is implementation specific.

2. If the MCData server makes use of the xMB interface, the MCData server creates an MBMS session over xMB-C for the MBMS user service (subclause 5.4 from 3GPP TS 26.348 [19]), with the type set to "Files" to use the MBMS download delivery method. Additionally, the MCData server defines the ingest mode, pull or push, to provide the file into the BM-SC via xMB-U. This MBMS session will be used for fde distribution. In response, the MCData server gets the TMGI of the MBMS bearer used for the MBMS session, and the SA file containing the metadata of the MBMS user service. When the push ingest mode is defined, the MCData server also obtains the URL to be used to push the file(s).

3a. Else, the MCData server activates an MBMS bearer over MB2-C for the MBMS user service.

3b. The MCData server, if not already in the possession of the SA file, generates the SA file containing the metadata of the MBMS user service.

4. The MCData server passes using control plane signalling the MBMS user service info for the service description associated with the pre-established MBMS user service to the MCData client. The MCData client obtains the TMGI, identifying the MBMS bearer, from the SA file included in the MBMS user service description. 5. The MCData client stores the information associated with the MBMS user service. The MCData client uses the TMGI and other MBMS user service related information to activate the monitoring of the MBMS bearer.

6. The MCData client that enters or is in the service area of at least one announced TMGI indicates to the MCData server that the MCData client is able to receive file distributed over MBMS, whereby the MCData server may decide to use this MBMS user service instead of unicast bearer for MC communication sessions.

NOTE 2: Step 4 is optional for the MCData UE on subsequent MBMS user service announcements.

NOTE 3: The information flow is specified in subclause 10.7.2.2 from 3GPP TS 23.280 [5]

7. If the MCData server makes use of the xMB interface and wants to deliver a file to a group, the MCData server updates the MBMS session to provide the file list when the pull ingest mode is defined. As described in 3GPP TS 26.348 [19], the file list includes, among other information, the file URL to be used by the BM- SC to fetch the file and the earliest fetch time.

8. The MCData server signals the file transmission over the MBMS user service to the targeted MCData clients.

NOTE 4: After step 8, the file can be provided for distribution over the MBMS session. If the pull ingest mode is defined, the BM-SC fetches the file from the indicated file URL. If the push ingest mode is defined, the MCData server can start pushing the file to the corresponding URL.

9. The file, transmitted with the MBMS download delivery method, is received by the MCData clients. If the MCData server does not make use of the xMB interface, the MCData server fragments the file to be sent, applies error correction according to the MBMS download delivery method (3GPP TS 26.346 [21]) and sent the FLUTE packets over MB2-U.

^{* * *} Next change ^{* * *}

7.3.5.3.2 Use of dynamic MBMS user service establishment

In this scenario depicted in figure 7.3.5.3.2-1, the MCData server decides to establish an MBMS user service for the distribution of a given file. The MBMS user service is announced to the MCData client, together with the file information to be received.

NOTE 1 : The MCData server logic for determining when to establish the new MBMS user service is implementation specific. For example, the MCData server could decide to establish the MBMS delivery based on the location of the UE's that are a part of the targeted group.

Figure 7.3.5.3.2-1 : Use of dynamic MBMS user service establishment . The MCData server determines to create a MBMS user service with a given an MBMS user service id for the group communication session. If the MCData server makes use of the xMB interface, the MCData server creates an MBMS user service over xMB-C (subclause 5.3 from 3GPP TS 26.348 [19]). . If the MCData server makes use of the xMB interface, the MCData server creates a MBMS session for the MBMS user service (subclause 5.4 from 3GPP TS 26.348 [19]), with the type set to "Files" to use the MBMS download delivery method. Additionally, the MCData server defines the ingest mode, pull or push, to provide the file into the BM-SC via xMB-U. When the pull ingest mode is defined, the MCData server provides the file list. The file list includes, among other information, the file URL to be used by the BM-SC to fetch the file and the earliest fetch time. In response, the MCData server gets the TMGI of the MBMS bearer used for the MBMS session and the SA file containing the metadata of the MBMS user service. When the pull ingest mode is defined, the MCData server also obtains the scheduling parameter for the file delivery. When the push ingest mode is defined, the MCData server obtains the URL to be used to push the file(s).a. Else, the MCData server activates an MBMS bearer over MB2-C for the MBMS user service. b. The MCData server, if not already in the possession of the SA file, generates the SA file containing the metadata of the MBMS user service. . The MCData server passes using control plane signalling the SA file to the MCData client. The MCData client obtains the TMGI, identifying the MBMS bearer, from the SA file included in the MBMS user service description. . The MCData client stores the information associated with the MBMS user service. The MCData client uses the TMGI and other MBMS user service related information to activate the monitoring of the MBMS bearer. 6. The MCData client that enters or is in the service area of at least one announced TMGI indicates to the MCData server that the MCData client is able to receive file distributed over MBMS, whereby the MCData server may decide to use this MBMS user service instead of unicast bearer for MC communication sessions.

7. The MCData server signals the file transmission over the MBMS user service to the targeted MCData clients.

NOTE 2: After step 7, the file can be provided for distribution over the MBMS session. If the pull ingest mode is defined, the BM-SC fetches the file from the indicated file URL. If the push ingest mode is defined, the MCData server can start pushing the file to the corresponding URL.

8. The file, transmitted with the MBMS download delivery method, is received by the MCData clients. If the MCData server does not make use of the xMB interface, the MCData server fragments the file to be sent, applies error correction according to the MBMS download delivery method (3GPP TS 26.346 [21]) and sent the FLUTE packets over MB2-U.

3GPP TSG-SA WG6 Meeting #38-e S6-200xxx e-meeting, 20^th - 31^st July 2020

(revision of S6-xxxxxx)

For on using this form: comprehensive instructions can be found at http: //www.3gpp. org/Change-Requests.

^{* * *} First change ^{* * *}

6.6.3.1.5 MCData content server

The MCData content server functional entity provides a repository area in the MCData trust domain allowing authorized MCData users to temporarily store files that are intended to share to other MCData users. It provides common pool of storage area (i.e. size) to all authorized MCData users to use, no personal space is allocated. An authorized MCData user can use the supported operations on the defined reference point to upload shared files and download the files that are shared to him. The MCData server will use the defined reference point to access the files stored in the MCData content server and support the necessary operational functionalities. As part of the file life cycle management the temporarily stored files will be removed periodically based on the Mission Critical service provider policy. An MCData content server may share files with another MCData content server in another MCData system to support interconnection.

If the MBMS user service architecture described in 3GPP TS 26.346 [21] is utilized for file distribution, the MCData content server provides the stored file associated to the established MBMS session.

NOTE: The security aspects of the MCData content server and its operational supports are the responsibility of SA3 and thus outside the scope of the present document.

^{* * *} Next change ^{* * *}

7.3.5.1 General

This subclause defines information flows and procedures for usage of MBMS user services that applies to MCData file distribution. MBMS user services can be used for any MC service group.

The MBMS user service architecture is described in 3GPP TS 26.346 [21]

^{* * *} Next change ^{* * *} 7.3.5.3.x Providing stored files in the MCData content server for distribution over MBMS

7.3.5.3.X.1 General

As described in clause 6.6.3.1.5, the MCData content server provides a repository area where authorized MCData users temporarily store files that are intended to be shared with other MCData users. The distribution of such files targeting a group of MCData users can be performed over MBMS.

For the case that the MBMS user service architecture is used over the xMB interface (specified in 3GPP TS 26.348 [19]), two ingest modes, push and pull, can be defined by the MCData server to ingest the file into the BM-SC for distribution over the MBMS sessions.

7.3.5.3.X.2 File fetching by the MCData server

A file can be fetched by the MCData server from the MCData content server over the MCData- FD-5 reference point using the file URL provided by MCData users. The MCData server, thus, enables via the xMB-U interface that the file is ingested, either by pull or push, into the BM-SC for distribution over MBMS.

NOTE 1 : The file also becomes available for the case that the MCData server decides to distribute the file over unicast transmissions to MCData users from the target MCData group.

When the MCData server defines a pull ingest mode, the MCData server provides via the xMB- C interface the resource location from which the BM-SC will fetch the file as well as other session properties (e.g. file earliest fetch time), as described in 3GPP TS 26.348 [19]

When the MCData server defines a push ingest mode, the MCData server directly ingests into the BM-SC via the xMB-U interface the file obtained from the MCData content server. The BM- SC shall provide to the MCData server the URL to be used to push the file(s).

NOTE 2: For the push ingest mode, the MCData server is always the functional entily ingesting the file content into the BM-SC via the xMB-U interface.

The procedure in figure 7.3.5.3.x.2-1 describes the case where the file to be distributed over MBMS is fetched by the MCData server from the MCData content server.

Pre-conditions:

- The MCData users on the MCData client 1 to n belong to the same MCData group and are already registered and affiliated for receiving MCData service.

- The file to be distributed is uploaded to the MCData content server.

Figure 7.3.5.3.X.2-1 : File fetching by the MCData server for file distribution over MBMS

1. The MCData server receives a request from the MCData client 1 to distribute a file to a target MCData group. The MCData file distribution request contains the resource location (i.e. the file URL) in the MCData content server.

2. The MCData server decides to fetch the file from the MCData content server via the MCData-FD-5 reference point.

3. The MCData server creates an MBMS service and session for file delivery using xMB procedures via the xMB-C interface, as described in 3GPP TS 26.348 [19] The MCData server indicates, among other session properties, the ingest mode. For the case of pull ingest mode, the MCData server provides the file URL from which the BM-SC will fetch the file. For the case of push ingest mode, the BM-SC provides to the MCData server the URL to be used to push the file into the MBMS session.

NOTE 3: Step 3 may also occur before step 2.

4. The MCData server provides to the MCData users from the target MCData group the application signalling related to the MBMS session and the file distribution.

5a. For the case that the file is ingested into the BM-SC based on the push ingest mode, the MCData server pushes the file to the URL indicated by the BM-SC.

5b. For the case that the file is ingested into the BM-SC based on the pull ingest mode, the BM-SC pulls the file from the MCData server based on the provided file URL. 6. The BM-SC distributes the file over the established MBMS session. When the target MCData clients have activated the reception for that service and are located within the MBMS area coverage, the MCData clients receive the file.

7.3.5.3.X.3 File fetching by the BM-SC

When the MCData server defines a pull ingest mode, the MCData server can alternatively provide to the BM-SC the resource location in the MCData content server (i.e. the file URL contained within the received file distribution request). The BM-SC, thus, will directly fetch the file from the MCData content server.

NOTE 1 : In order to the enable that the BM-SC fetches the file from the MCData content server, the MCData content server supports the xMB-U interface to the BM-SC.

NOTE 2: For the case that the file is ingested into the BM-SC from the MCData content server, only the pull ingest mode is supported. When push ingest mode is required, the procedure is described in clause 7.3.5.3.X.2.

The procedure in figure 7.3.5.3.x.3-1 describes the case where the file to be distributed over MBMS is fetched by the BM-SC from the MCData content server.

Pre-conditions:

- The file to be distributed is uploaded to the MCData content server.

Figure 7.3.5.3.X.3-1 : File fetching by the BM-SC for file distribution over MBMS 1. The MCData server receives a request from the MCData client 1 to distribute a file to a target MCData group. The MCData file distribution request contains the resource location (i.e. the file URL) in the MCData content server.

2. The MCData server creates an MBMS service and session for file delivery using xMB procedures via the xMB-C interface, as described in 3GPP TS 26.348 [19] The MCData server defines, among other session properties, the ingest mode to pull. The MCData server provides the file URL from which the BM-SC will fetch the file from the MCData content server.

3. The MCData server provides to the MCData users from the target MCData group the application signalling related to the MBMS session and the file distribution.

4. The BM-SC fetches the file from the MCData content server via the xMB-U interface.

5. The BM-SC distributes the file over the established MBMS session. When the target MCData clients have activated the reception for that service and are located within the MBMS area coverage, the MCData clients receive the file.

LISTING OF SOME EMBODIMENTS:

[0119] Some of the embodiments described above are summarized below. Reference numbers/letters are provided in parenthesis by way of example/illustration without limiting example embodiments to particular elements indicated by reference numbers/letters:

1. A method by a mission critical, MC, data server (404), the method comprising: receiving (410, 800) a file distribution request (410, 510) from a first MC data client (402a) which is a member of a group of MC data clients (402a, 402b, 402n) registered for receiving MC data service, the file distribution request identifies a resource location of a file in a MC data content server (406) that is to be distributed to the group of MC data clients (402a, 402b, 402n), and deciding (802) whether the MC data server (404) or a broadcast multicast service centre, BM-SC (400), will fetch the file from a MC data content server (406) for distribution (424, 518) through a multicast-broadcast multimedia services, MBMS, session to the group of MC data clients (402a, 402b, 402n) within a MBMS coverage area.

2. The method of Embodiment 1, further comprising: based on deciding (802) the MC data server (404) will fetch the file from the MC data content server (406) for distribution (424) through the MBMS session to the group of MC data clients (402a, 402b, 402n), sending (413a) a request file message to the MC data content server (406) requesting the file from the resource location, receiving (413b) the file from the MC data content server (406) responsive to the request file message, and communicating (418) the file through the MBMS session to the BM-SC (400) for distribution (424) to the group of MC data clients (402a, 402b, 402n) within the MBMS coverage area.

3. The method of Embodiment 2, wherein the sending (413a) the request file message to the MC data content server (406) uses a MCData-FD-5 reference point.

4. The method of any of Embodiments 2 to 3, wherein the communicating (418) of the file through the MBMS session to the BM-SC (400) for distribution (424) to the group of MC data clients (402a, 402b, 402n) within the MBMS coverage area, comprises: receiving a uniform resource locator, URL, from the BM-SC (400); and pushing (420) the file to the URL for distribution (424) through the MBMS session.

5. The method of any of Embodiments 2 to 3, wherein the communicating (418) of the file through the MBMS session to the BM-SC (400) for distribution (424) to the group of MC data clients (402a, 402b, 402n) within the MBMS coverage area, comprises: communicating (418) to the BM-SC (400) a uniform resource locator, URL, indicating a location of the file on the MC data server (404); receiving (423a) from the BM-SC (400) a request message containing the URL; and communicating (423b) the file at the URL to the BM-SC (400).

6. The method of Embodiment 1 , further comprising: based on deciding (802) the BM-SC (400) will fetch the file from the MC data content server (406) for distribution (518) through the MBMS session to the group of MC data clients (402a, 402b, 402n), communicating (512) the resource location of the file to the BM-SC (400) to fetch the file for distribution (518) to the group of MC data clients (402a, 402b, 402n). 7. The method of Embodiment 6, wherein the communicating (512) of the resource location of the file to the BM-SC (400) to fetch the file for distribution (518) to the group of MC data clients (402a, 402b, 402n), comprises: creating a multicast-broadcast multimedia services, MBMS, service and MBMS session for file distribution (518) using xMB procedures via a xMB-C interface.

8. The method of Embodiment 7, wherein the creating of the MBMS service and MBMS session comprises defining session properties that include identifying the resource location of the file.

9. The method of any of Embodiments 7 to 8, wherein the MBMS service and MBMS session creation comprises defining session properties that identify whether the BM-SC (400) is to push or pull the file from the MC data content server (406).

10. The method of any of Embodiments 6 to 9, further comprising: receiving (620) a file authorization request from the MC data content server (406), the file authorization request comprises a MBMS session identification and the resource location of the file in the MC data content server (406); generating a file authorization response indicating whether the MBMS session identification is authorized to fetch the resource location of the file in the MC data content server (406); and communicating (622) the file authorization response to the MC data content server (406).

11. The method of any of Embodiments 1 to 10, wherein the file distribution request (410, 510) contains a resource location of the file in the MC data content server (406).

12. A computer program product comprising a non-transitory computer readable medium storing instructions executable by at least one processor of a mission critical, MC, data server (404), to operate the at least one processor to perform the method of any of Embodiments 1 to 11.

13. A method by a broadcast multicast service centre, BM-SC (400), the method comprising: receiving (420, 423b, 900) a file from a mission critical, MC, data server (404); and distributing (424, 902) the file through a multicast-broadcast multimedia services, MBMS, session to a group of MC data clients (402a, 402b, 402n) registered for receiving MC data service and are within a MBMS coverage area.

14. The method of Embodiment 13, wherein the receiving of the file through the MBMS session comprises: communicating a uniform resource locator, URL, to the MC data server (404); and receiving (420) the file from the MC data server (404).

15. The method of Embodiment 13, wherein the receiving of the file through the MBMS session comprises: receiving a uniform resource locator, URL, indicating a location of the file in the MC data server (404) from the MC data server (404); communicating (423a) a request message containing the URL to the MC data server (404); and receiving (423b) the file from the MC data server (404) responsive to the request message.

16. A computer program product comprising a non-transitory computer readable medium storing instructions executable by at least one processor of a broadcast multicast service centre, BM-SC (400), to operate the at least one processor to perform the method of any of Embodiments 13 to 15.

17. A method by a broadcast multicast service centre, BM-SC (400), the method comprising: receiving (512, 1000) from a mission critical, MC, data server (404) a resource location for a file to be distributed to a group of MC data clients (402a, 402b, 402n); fetching (516, 1002) the file from the resource location in a MC data content server (406); and distributing (518, 1004) the file through a multicast-broadcast multimedia services, MBMS, session to the group of MC data clients (402a, 402b, 402n) registered for receiving MC data service and are within a MBMS coverage area.

18. The method of Embodiment 17, wherein the fetching (516) of the file from the resource location in the MC data content server (406) is performed through a xMB-U interface. 19. The method of any of Embodiments 17 to 18, wherein the receiving (512) from the MC data server (404) the resource location for the file comprises creating a MBMS service and the MBMS session for file distribution using xMB procedures via a xMB-C interface, wherein the creating of the MBMS service and MBMS session comprises defining session properties that include identifying the resource location of the file in the MC data content server (406).

20. The method of any of Embodiments 17 to 19, wherein the MBMS service and session creation comprises defining session properties that include whether the BM-SC (400) is to push or pull the file from the MC data content server (406).

21. A computer program product comprising a non-transitory computer readable medium storing instructions executable by at least one processor of a broadcast multicast service centre, BM-SC (400), to operate the at least one processor to perform the method of any of Embodiments 17 to 20.

22. A mission critical, MC, data server (404) operative to: receive a file distribution request from a first MC data client (402a) which is a member of a group of MC data clients (402a, 402b, 402n) registered for receiving MC data service, the file distribution request identifies a resource location of a file in a MC data content server (406) that is to be distributed to the group of MC data clients (402a, 402b, 402n), and decide whether the MC data server (404) or a broadcast multicast service centre, BM-SC (400), will fetch the file from a MC data content server (406) for distribution through a multicast- broadcast multimedia services, MBMS, session to the group of MC data clients (402a, 402b, 402n) within a MBMS coverage area.

23. The MC data server (404) of Embodiment 22, further operative to: based on deciding the MC data server (404) will fetch the file from the MC data content server (406) for distribution through the MBMS session to the group of MC data clients (402a, 402b, 402n), send a request file message to the MC data content server (406) requesting the file from the resource location, receive the file from the MC data content server (406) responsive to the request file message, and communicate the file through the MBMS session to the BM-SC (400) for distribution to the group of MC data clients (402a, 402b, 402n) within the MBMS coverage area.

24. The MC data server (404) of Embodiment 23, wherein the sending the request file message to the MC data content server (406) uses a MCData-FD-5 reference point.

25. The MC data server (404) of any of Embodiments 23 to 24, wherein the communicating of the file through the MBMS session to the BM-SC (400) for distribution to the group of MC data clients (402a, 402b, 402n) within the MBMS coverage area, comprises: receiving a uniform resource locator, URL, from the BM-SC (400); and pushing the file to the URL for distribution through the MBMS session.

26. The MC data server (404) of any of Embodiments 23 to 24, wherein the communicating of the file through the MBMS session to the BM-SC (400) for distribution to the group of MC data clients (402a, 402b, 402n) within the MBMS coverage area, comprises: communicating to the BM-SC (400) a uniform resource locator, URL, indicating a location of the file on the MC data server (404); receiving from the BM-SC (400) a request message containing the URL; and communicating the file at the URL to the BM-SC (400).

27. The MC data server (404) of Embodiment 22, further operative to: based on deciding the BM-SC (400) will fetch the file from the MC data content server (406) for distribution through the MBMS session to the group of MC data clients (402a, 402b, 402n), communicate the resource location of the file to the BM-SC (400) to fetch the file for distribution to the group of MC data clients (402a, 402b, 402n).

28. The MC data server (404) of Embodiment 27, wherein the communicating of the resource location of the file to the BM-SC (400) to fetch the file for distribution to the group of MC data clients (402a, 402b, 402n), comprises: create a multicast-broadcast multimedia services, MBMS, service and MBMS session for file distribution using xMB procedures via a xMB-C interface.

29. The MC data server (404) of Embodiment 28, wherein the creating of the MBMS service and MBMS session comprises defining session properties that include identifying the resource location of the file.

30. The MC data server (404) of any of Embodiments 28 to 29, wherein the MBMS service and MBMS session creation comprises defining session properties that identify whether the BM-SC (400) is to push or pull the file from the MC data content server (406).

31. The MC data server (404) of any of Embodiments 27 to 30, further operative to: receiving a file authorization request from the MC data content server (406), the file authorization request comprises a MBMS session identification and the resource location of the file in the MC data content server (406); generating a file authorization response indicating whether the MBMS session identification is authorized to fetch the resource location of the file in the MC data content server (406); and communicating the file authorization response to the MC data content server (406).

32. The MC data server (404) of any of Embodiments 22 to 31 , wherein the file distribution request contains a resource location of the file in the MC data content server (406).

33. A broadcast multicast service centre, BM-SC (400), operative to: receive a file from a mission critical, MC, data server (404); and distribute the file through a multicast-broadcast multimedia services, MBMS, session to a group of MC data clients (402a, 402b, 402n) registered for receiving MC data service and are within a MBMS coverage area.

34. The BM-SC (400) of Embodiments 33, wherein the receiving of the file through the MBMS session comprises: communicate a uniform resource locator, URL, to the MC data server (404); and receive the file from the MC data server (404).

35. The BM-SC (400) of Embodiment 33, wherein the receiving of the file through the MBMS session comprises: receive a uniform resource locator, URL, indicating a location of the file in the MC data server (404) from the MC data server (404); communicate a request message containing the URL to the MC data server (404); and receive the file from the MC data server (404) responsive to the request message.

36. A broadcast multicast service centre, BM-SC (400), operative to: receive from a mission critical, MC, data server (404) a resource location for a file to be distributed to a group of MC data clients (402a, 402b, 402n); fetch the file from the resource location in a MC data content server (406). distribute the file through a multicast-broadcast multimedia services, MBMS, session to the group of MC data clients (402a, 402b, 402n) registered for receiving MC data service and are within a MBMS coverage area.

37. The BM-SC (400) of Embodiment 36, wherein the fetching of the file from the resource location in the MC data content server (406) is performed through a xMB-U interface.

38. The BM-SC (400) of any of Embodiments 36 to 37, wherein the receiving from the MC data server (404) the resource location for the file comprises creating a MBMS service and the MBMS session for file distribution using xMB procedures via a xMB-C interface, wherein the creating of the MBMS service and MBMS session comprises defining session properties that include identifying the resource location of the file in the MC data content server (406).

39. The BM-SC (400) of any of Embodiments 36 to 38, wherein the MBMS service and session creation comprises defining session properties that include whether the BM-SC (400) is to push or pull the file from the MC data content server (406). ABBREVIATIONS

[0120] At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).

[0121] Various abbreviations used herein include the following:

Abbreviation Explanation

EPS Evolved Packet System

EPC Evolved Packet Core eNB Evolved Node B

GCSE Group Communication System Enablers

MC Mission Critical

MBMS Multicast-Broadcast Multimedia Services

BM-SC Broadcast Multicast Service Centre

UE User equipment

FDFile distribution

HTTP Hypertext T ransfer Protocol

[0122] Further definitions and embodiments are discussed below.

[0123] In the above-description of various embodiments of present inventive concepts, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of present inventive concepts. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which present inventive concepts belong. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

[0124] When an element is referred to as being "connected", "coupled", "responsive", or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected", "directly coupled", "directly responsive", or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, "coupled", "connected", "responsive", or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and/or clarity. The term "and/or" includes any and all combinations of one or more of the associated listed items.

[0125] It will be understood that although the terms first, second, third, etc. may be used herein to describe various elements/operations, these elements/operations should not be limited by these terms. These terms are only used to distinguish one element/operation from another element/operation. Thus a first element/operation in some embodiments could be termed a second element/operation in other embodiments without departing from the teachings of present inventive concepts. The same reference numerals or the same reference designators denote the same or similar elements throughout the specification.

[0126] As used herein, the terms "comprise", "comprising", "comprises", "include",

"including", "includes", "have", "has", "having", or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof. Furthermore, as used herein, the common abbreviation "e.g.", which derives from the Latin phrase "exempli gratia," may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation "i.e.", which derives from the Latin phrase "id est," may be used to specify a particular item from a more general recitation.

[0127] Example embodiments are described herein with reference to block diagrams and/or flowchart illustrations of computer-implemented methods, apparatus (systems and/or devices) and/or computer program products. It is understood that a block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and/or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions/acts specified in the block diagrams and/or flowchart block or blocks, and thereby create means (functionality) and/or structure for implementing the functions/acts specified in the block diagrams and/or flowchart block(s).

[0128] These computer program instructions may also be stored in a tangible computer- readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which implement the functions/acts specified in the block diagrams and/or flowchart block or blocks. Accordingly, embodiments of present inventive concepts may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as "circuitry," "a module" or variants thereof.

[0129] It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated, and/or blocks/operations may be omitted without departing from the scope of inventive concepts. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.

[0130] Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present inventive concepts. All such variations and modifications are intended to be included herein within the scope of present inventive concepts.

Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the examples of embodiments are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of present inventive concepts. Thus, to the maximum extent allowed by law, the scope of present inventive concepts are to be determined by the broadest permissible interpretation of the present disclosure including the examples of embodiments and their equivalents, and shall not be restricted or limited by the foregoing detailed description.

Claims

CLAIMS What is claimed is:

2. The method of claim 1, further comprising: based on deciding (802) the MC data server (404) will fetch the file from the MC data content server (406) for distribution (424) through the MBMS session to the group of MC data clients (402a, 402b, 402n), sending (413a) a request file message to the MC data content server (406) requesting the file from the resource location, receiving (413b) the file from the MC data content server (406) responsive to the request file message, and communicating (418) the file through the MBMS session to the BM-SC (400) for distribution (424) to the group of MC data clients (402a, 402b, 402n) within the MBMS coverage area.

3. The method of claim 2, wherein the communicating (418) of the file through the MBMS session to the BM-SC (400) for distribution (424) to the group of MC data clients (402a, 402b, 402n) within the MBMS coverage area, comprises: receiving a uniform resource locator, URL, from the BM-SC (400); and pushing (420) the file to the URL for distribution (424) through the MBMS session.

4. The method of claim 2, wherein the communicating (418) of the file through the MBMS session to the BM-SC (400) for distribution (424) to the group of MC data clients (402a, 402b, 402n) within the MBMS coverage area, comprises: communicating (418) to the BM-SC (400) a uniform resource locator, URL, indicating a location of the file on the MC data server (404); receiving (423a) from the BM-SC (400) a request message containing the URL; and communicating (423b) the file at the URL to the BM-SC (400).

5. The method of claim 1 , further comprising: based on deciding (802) the BM-SC (400) will fetch the file from the MC data content server (406) for distribution (518) through the MBMS session to the group of MC data clients (402a, 402b, 402n), communicating (512) the resource location of the file to the BM-SC (400) to fetch the file for distribution (518) to the group of MC data clients (402a, 402b, 402n).

6. The method of claim 5, wherein the communicating (512) of the resource location of the file to the BM-SC (400) to fetch the file for distribution (518) to the group of MC data clients (402a, 402b, 402n), comprises: creating a multicast-broadcast multimedia services, MBMS, service and MBMS session for file distribution (518) using xMB procedures via a xMB-C interface.

7. The method of any one of claim 5 to 6, further comprising: receiving (620) a file authorization request from the MC data content server (406), the file authorization request comprises a MBMS session identification and the resource location of the file in the MC data content server (406); generating a file authorization response indicating whether the MBMS session identification is authorized to fetch the resource location of the file in the MC data content server (406); and communicating (622) the file authorization response to the MC data content server (406).

8. A computer program product comprising a non-transitory computer readable medium storing instructions executable by at least one processor of a mission critical, MC, data server (404), to operate the at least one processor to perform the method of any one of claim 1 to 7.

9. A mission critical, MC, data server (404) operative to: receive a file distribution request from a first MC data client (402a) which is a member of a group of MC data clients (402a, 402b, 402n) registered for receiving MC data service, the file distribution request identifies a resource location of a file in a MC data content server (406) that is to be distributed to the group of MC data clients (402a, 402b, 402n), and decide whether the MC data server (404) or a broadcast multicast service centre, BM-SC (400), will fetch the file from a MC data content server (406) for distribution through a multicast- broadcast multimedia services, MBMS, session to the group of MC data clients (402a, 402b, 402n) within a MBMS coverage area.

10. The MC data server (404) of claim 9, further operative to: based on deciding the MC data server (404) will fetch the file from the MC data content server (406) for distribution through the MBMS session to the group of MC data clients (402a, 402b, 402n), send a request file message to the MC data content server (406) requesting the file from the resource location, receive the file from the MC data content server (406) responsive to the request file message, and communicate the file through the MBMS session to the BM-SC (400) for distribution to the group of MC data clients (402a, 402b, 402n) within the MBMS coverage area.

11. The MC data server (404) of claim 10, wherein the communicating of the file through the MBMS session to the BM-SC (400) for distribution to the group of MC data clients (402a, 402b, 402n) within the MBMS coverage area, comprises: receiving a uniform resource locator, URL, from the BM-SC (400); and pushing the file to the URL for distribution through the MBMS session.

12. The MC data server (404) of claim 10, wherein the communicating of the file through the MBMS session to the BM-SC (400) for distribution to the group of MC data clients (402a, 402b, 402n) within the MBMS coverage area, comprises: communicating to the BM-SC (400) a uniform resource locator, URL, indicating a location of the file on the MC data server (404); receiving from the BM-SC (400) a request message containing the URL; and communicating the file at the URL to the BM-SC (400).

13. The MC data server (404) of claim 9, further operative to: based on deciding the BM-SC (400) will fetch the file from the MC data content server (406) for distribution through the MBMS session to the group of MC data clients (402a, 402b, 402n), communicate the resource location of the file to the BM-SC (400) to fetch the file for distribution to the group of MC data clients (402a, 402b, 402n).

14. The MC data server (404) of claim 13, wherein the communicating of the resource location of the file to the BM-SC (400) to fetch the file for distribution to the group of MC data clients (402a, 402b, 402n), comprises: create a multicast-broadcast multimedia services, MBMS, service and MBMS session for file distribution using xMB procedures via a xMB-C interface.

15. The MC data server (404) of any one of claim 13 to 14, further operative to: receiving a file authorization request from the MC data content server (406), the file authorization request comprises a MBMS session identification and the resource location of the file in the MC data content server (406); generating a file authorization response indicating whether the MBMS session identification is authorized to fetch the resource location of the file in the MC data content server (406); and communicating the file authorization response to the MC data content server (406).

16. The MC data server (404) of any one of claim 9 to 15, wherein the file distribution request contains a resource location of the file in the MC data content server (406).

17. A broadcast multicast service centre, BM-SC (400), operative to: receive a file from a mission critical, MC, data server (404); and distribute the file through a multicast-broadcast multimedia services, MBMS, session to a group of MC data clients (402a, 402b, 402n) registered for receiving MC data service and are within a MBMS coverage area.

18. The BM-SC (400) of claim 17, wherein the receiving of the file through the MBMS session comprises: communicate a uniform resource locator, URL, to the MC data server (404); and receive the file from the MC data server (404).

19. The BM-SC (400) of claim 17, wherein the receiving of the file through the MBMS session comprises: receive a uniform resource locator, URL, indicating a location of the file in the MC data server (404) from the MC data server (404); communicate a request message containing the URL to the MC data server (404); and receive the file from the MC data server (404) responsive to the request message.

20. A broadcast multicast service centre, BM-SC (400), operative to: receive from a mission critical, MC, data server (404) a resource location for a file to be distributed to a group of MC data clients (402a, 402b, 402n); fetch the file from the resource location in a MC data content server (406). distribute the file through a multicast-broadcast multimedia services, MBMS, session to the group of MC data clients (402a, 402b, 402n) registered for receiving MC data service and are within a MBMS coverage area.

21. The BM-SC (400) of claim 20, wherein the fetching of the file from the resource location in the MC data content server (406) is performed through a xMB-U interface.

22. The BM-SC (400) of any one of claim 20 to 21 , wherein the receiving from the MC data server (404) the resource location for the file comprises creating a MBMS service and the MBMS session for file distribution using xMB procedures via a xMB-C interface, wherein the creating of the MBMS service and MBMS session comprises defining session properties that include identifying the resource location of the file in the MC data content server (406).

23. The BM-SC (400) of any one of claim 20 to 22, wherein the MBMS service and session creation comprises defining session properties that include whether the BM-SC (400) is to push or pull the file from the MC data content server (406).