WO2022013190A1 - Fourniture de fichiers stockés en vue d'une distribution de fichiers de données essentielles à la mission sur des services multimédias de multidiffusion/diffusion - Google Patents

Fourniture de fichiers stockés en vue d'une distribution de fichiers de données essentielles à la mission sur des services multimédias de multidiffusion/diffusion Download PDF

Info

Publication number
WO2022013190A1
WO2022013190A1 PCT/EP2021/069406 EP2021069406W WO2022013190A1 WO 2022013190 A1 WO2022013190 A1 WO 2022013190A1 EP 2021069406 W EP2021069406 W EP 2021069406W WO 2022013190 A1 WO2022013190 A1 WO 2022013190A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
data
mbms
server
distribution
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2021/069406
Other languages
English (en)
Inventor
Camilo John SOLANO ARENAS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of WO2022013190A1 publication Critical patent/WO2022013190A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services

Definitions

  • the present disclosure relates generally to communications services, and more particularly to Mission Critical (MC) communication services.
  • MC Mission Critical
  • 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.
  • the MC communication services requires several resilience features that provides a guaranteed service level even if part of the network or backhaul infrastructure fails.
  • 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.
  • MCPTT Mission Critical Push To Talk
  • MC data or MCData Mission Critical Data
  • MCVideo Mission Critical Video
  • 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.
  • MBMS Multicast-Broadcast Multimedia Services
  • 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 .
  • 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).
  • GCS Group Communication System
  • UEs user equipment
  • 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.
  • 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.
  • 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.
  • UE user equipment
  • E-UTRAN 110 E-UTRAN 110 which may provide a unicast path 120 and a MBMS path 130 for communications with the MC service server 140.
  • the GCS AS transfers data to different groups over a single MBMS broadcast bearer.
  • 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).
  • BM-SC Broadcast-Multicast - Service Centre
  • 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.
  • 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.
  • 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.
  • FIG. 3 is a block diagram of an example MC data application plane functional model for file distribution.
  • the MC data functional model for file distribution 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.
  • the MC data server can decide to distribute the file over MBMS.
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Embodiments of present disclosure are described within the context of a 3GPP-based LTE network, i.e. an EPS including E-UTRAN and EPC.
  • EPS including E-UTRAN and EPC.
  • 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).
  • UE user-equipment
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Figure 1 is a block diagram of an example MC service architecture supporting unicast
  • 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
  • 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
  • FIG. 8 is a flowchart of operations by a MC data server in accordance with some embodiments of the present disclosure.
  • FIGS. 9 and 10 are flowcharts of operations by a BM-SC in accordance with some embodiments of the present disclosure.
  • the MC data service specification i.e. 3GPP TS 23.282
  • 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.
  • system instability may result as operational conflicting and/or incompatible implementations by different equipment providers are deployed in communication systems.
  • 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.
  • 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
  • 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.
  • the MC data server 404 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.
  • the MC data server 404 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.
  • the MC data server 404 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).
  • the MC data server 404 is always the one ingesting the file content into the BM-SC 400 via the xMB-U interface.
  • 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.
  • 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.
  • the file to be distributed is uploaded to the MC data content server 406.
  • 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.
  • the MC data server 404 fetches the file from the MC data content server 406 via the MC data-FD-5 reference point.
  • 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.
  • the MC data server 404 provides the file URL from which the BM-SC 400 will fetch the file.
  • the BM-SC 400 provides to the MC data server 404 the URL to be used to push the file into the MBMS session.
  • operation 414 may also occur before operation 412.
  • 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.
  • the file is ingested into the BM-SC 400 via the xMB-U interface.
  • the MC data server 404 pushes the file to the URL indicated by the BM-SC 400.
  • the BM-SC 400 pulls the file from the MC data server 404 based on the provided file URL.
  • the BM-SC 400 distributes the file over the established MBMS session.
  • 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.
  • 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.
  • 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 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.
  • the MC data server 404 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the BM-SC 400 fetches the file from the MC data content server 406 via the xMB-U interface.
  • the BM-SC 400 distributes the file over the established MBMS session.
  • 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.
  • 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.
  • 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.
  • 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.
  • the MC data server 404 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.
  • the MC data content server 406 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 illustrates a flowchart of operations by a MC data server 404 in accordance with some embodiments of the present disclosure.
  • 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.
  • a resource location e.g., a uniform resource locator (URL)
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the creating of the MBMS service and MBMS session comprises defining session properties that include identifying the resource location of the file.
  • 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.
  • the file distribution request 410, 510 contains a resource location of the file in the MC data content server 406.
  • 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.
  • 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.
  • FIG. 10 illustrates a flowchart of operations by a BM-SC 400 in accordance with some embodiments of the present disclosure.
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • 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.
  • the MCData server may provide in this step 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.
  • 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.
  • the MCData clients 2 to n automatically send accepted MCData group standalone FD response when the incoming request included mandatory download indication.
  • MCData clients may skip step 8.
  • the MCData server forwards the MCData group standalone FD responses to the MCData client 1.
  • the MCData clients receive the file delivered over MBMS.
  • the MCData clients may download the missing parts using the procedures defined in subclause 7.5.2.3.
  • the media storage client of the MCData client(s) can download the file using the procedure defined in subclause 7.5.2.3.
  • 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.
  • 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.
  • the procedure figure 7.3.5.3.1.2-1 shows only one of the receiving MCData clients using an MBMS user service.
  • 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]).
  • 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).
  • the MCData server activates an MBMS bearer over MB2-C for the MBMS user service.
  • 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 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.
  • 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.
  • the MCData server 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.
  • the MCData server signals the file transmission over the MBMS user service to the targeted MCData clients.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • the MCData server defines the ingest mode, pull or push, to provide the file into the BM-SC via xMB-U.
  • 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.
  • 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.
  • the pull ingest mode is defined, the MCData server also obtains the scheduling parameter for the file delivery.
  • the push ingest mode is defined, the MCData server obtains the URL to be used to push the file(s).a.
  • the MCData server activates an MBMS bearer over MB2-C for the MBMS user service.
  • 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.
  • the MCData server signals the file transmission over the MBMS user service to the targeted MCData clients.
  • 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.
  • 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.
  • 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.
  • the MCData content server provides the stored file associated to the established MBMS session.
  • MBMS user services can be used for any MC service group.
  • the MBMS user service architecture is described in 3GPP TS 26.346 [21]
  • 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.
  • 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.
  • the MCData server 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]
  • the MCData server 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).
  • the file to be distributed is uploaded to the MCData content server.
  • 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.
  • the MCData server decides to fetch the file from the MCData content server via the MCData-FD-5 reference point.
  • 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.
  • Step 3 may also occur before step 2.
  • 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.
  • 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.
  • 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.
  • 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.
  • the BM-SC fetches the file from the MCData content server via the xMB-U interface.
  • the BM-SC distributes the file over the established MBMS session.
  • the target MCData clients 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.
  • Embodiment 2 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.
  • 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.
  • 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.
  • 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.
  • MBMS multicast-broadcast multimedia services
  • 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.
  • BM-SC broadcast multicast service centre
  • 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.
  • a multicast- broadcast multimedia services MBMS
  • a uniform resource locator, URL indicating a location of the file on the MC data server (404)
  • URL uniform resource locator
  • 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).
  • BM-SC broadcast multicast service centre
  • 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.
  • a multicast-broadcast multimedia services, MBMS multicast-broadcast multimedia services
  • 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).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Emergency Management (AREA)
  • Environmental & Geological Engineering (AREA)
  • Public Health (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Certains aspects de la présente divulgation portent sur un procédé réalisé par un serveur de données essentielles à la mission (MC). Le procédé consiste à recevoir une demande de distribution de fichiers provenant d'un premier client de données MC qui est membre d'un groupe de clients de données MC enregistrés en vue de recevoir un service de données MC. La demande de distribution de fichier identifie un emplacement de ressource d'un fichier dans un serveur de contenu de données MC qui doit être distribué au groupe de clients de données MC. Le procédé consiste en outre à décider si le serveur de données MC ou un centre de service de diffusion/multidiffusion (BM-SC) va extraire le fichier d'un serveur de contenu de données MC pour le distribuer par l'intermédiaire d'une session MBMS au groupe de clients de données MC dans les limites d'une zone de couverture MBMS.
PCT/EP2021/069406 2020-07-13 2021-07-13 Fourniture de fichiers stockés en vue d'une distribution de fichiers de données essentielles à la mission sur des services multimédias de multidiffusion/diffusion Ceased WO2022013190A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202063051095P 2020-07-13 2020-07-13
US63/051095 2020-07-13

Publications (1)

Publication Number Publication Date
WO2022013190A1 true WO2022013190A1 (fr) 2022-01-20

Family

ID=77021327

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/069406 Ceased WO2022013190A1 (fr) 2020-07-13 2021-07-13 Fourniture de fichiers stockés en vue d'une distribution de fichiers de données essentielles à la mission sur des services multimédias de multidiffusion/diffusion

Country Status (1)

Country Link
WO (1) WO2022013190A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3133507A1 (fr) * 2022-03-14 2023-09-15 Airbus Ds Slc Procédé d’initiation de communication MCData au sein d’un regroupement de groupes de communication dans un réseau 3GPP MCS
EP4258137A1 (fr) * 2022-04-07 2023-10-11 Airbus DS SLC Procédé de distribution de fichier entre systèmes 3gpp mcdata interconnectés
WO2025174072A1 (fr) * 2024-02-13 2025-08-21 Samsung Electronics Co., Ltd. Procédé et appareil de distribution de fichiers dans un groupe ad-hoc

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Functional architecture and information flows to support Mission Critical Data (MCData); Stage 2 (Release 17)", vol. SA WG6, no. V17.3.0, 6 July 2020 (2020-07-06), pages 1 - 209, XP051924150, Retrieved from the Internet <URL:ftp://ftp.3gpp.org/Specs/archive/23_series/23.282/23282-h30.zip 23282-h30.doc> [retrieved on 20200706] *
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Northbound Application Programming Interface (API) for Multimedia Broadcast/Multicast Service (MBMS) at the xMB reference point (Release 16)", 20 March 2020 (2020-03-20), XP051867354, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_sa/WG4_CODEC/Specs_Update_After_SA%2387-e/26348-g20_ImplementedWIthCR_SP-200039_S4-200326_S4-200232.zip 26348-g20_ImplementedWIthCR_SP-200039_S4-200326_S4-200232.doc> [retrieved on 20200320] *
3GPP TS 23.280
3GPP TS 23.281
3GPP TS 23.282
3GPP TS 23.379
3GPP TS 23.468

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3133507A1 (fr) * 2022-03-14 2023-09-15 Airbus Ds Slc Procédé d’initiation de communication MCData au sein d’un regroupement de groupes de communication dans un réseau 3GPP MCS
EP4246928A1 (fr) * 2022-03-14 2023-09-20 Airbus DS SLC Procédé d'initiation de communication mcdata au sein d'un regroupement de groupes de communication dans un réseau 3gpp mcs
US12418786B2 (en) 2022-03-14 2025-09-16 Airbus Ds Slc Method for initiating MCData communication within a regroup of communication groups in a 3GPP MCS network
EP4258137A1 (fr) * 2022-04-07 2023-10-11 Airbus DS SLC Procédé de distribution de fichier entre systèmes 3gpp mcdata interconnectés
FR3134463A1 (fr) * 2022-04-07 2023-10-13 Airbus Ds Slc Procédé de distribution de fichier entre systèmes 3GPP MCData interconnectés
US11936728B2 (en) 2022-04-07 2024-03-19 Airbus Ds Slc Method for the file distribution between interconnected 3GPP MCData systems
WO2025174072A1 (fr) * 2024-02-13 2025-08-21 Samsung Electronics Co., Ltd. Procédé et appareil de distribution de fichiers dans un groupe ad-hoc

Similar Documents

Publication Publication Date Title
US12010609B2 (en) Towards robust notification mechanism in 5G SBA
JP5550627B2 (ja) 通信システムにおけるグループ通信
EP3613226B1 (fr) Procédé et système de notification d&#39;état de membres de groupes mission critical service (mcx)
JP4649328B2 (ja) 無線通信システムのブロードキャスト／マルチキャストサービスを利用してマルチパーティ会議サービスを実現する方法、装置及びシステム
EP4154586B1 (fr) Procédés et systèmes pour le transfert de données de multidiffusion pendant les procédures de mobilité dans les réseaux de communication sans fil
US11051078B2 (en) Video distribution method and device
EP3504864B1 (fr) Procédé de gestion de short data service (sds) dans un système de communication de données critiques pour la mission (données mc)
US20170257751A1 (en) Off-Network Wireless Mission Critical Session Initiation
WO2022013190A1 (fr) Fourniture de fichiers stockés en vue d&#39;une distribution de fichiers de données essentielles à la mission sur des services multimédias de multidiffusion/diffusion
US12538121B2 (en) Secure data collection in fifth generation system (5GS)
US20210321228A1 (en) Network location reporting broadcast bearer management
KR20180021846A (ko) 활성 그룹 호 병합
WO2022028984A1 (fr) Amélioration de resélection d&#39;instance de service de fonction de réseau dans un réseau central de 5e génération avec communication indirecte
WO2022218947A2 (fr) Procédés et systèmes de fourniture d&#39;informations concernant des caractéristiques prises en charge
EP4569802B1 (fr) Gestion de session d´application
US20080288643A1 (en) Session Initiation Protocol Signalling
US20240196191A1 (en) Supporting compatibility
CN118317367A (zh) 数据传输方法、装置和系统
WO2022041923A1 (fr) Procédé de connexion de tranche de réseau, terminal et support de stockage lisible par ordinateur
WO2025239708A1 (fr) Procédé et système de partage de notification de participation à une session d&#39;équipement utilisateur dans une gestion de ressources de réseau de couche d&#39;architecture d&#39;activateur de service
WO2022175510A1 (fr) Attribution de ressources de réseau pour des services http critiques de mission

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21745284

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21745284

Country of ref document: EP

Kind code of ref document: A1