Method and apparatus for flexible broadcast service over MBMS

A method and an apparatus for flexible broadcast service over multimedia broadcast multicast service (MBMS). The method includes transmitting a request for a location of content to a server. The method also includes when a MBMS is available for the content, receiving a MBMS delivery description for the location of the content, and joining session for the MBMS that carries the content based on the MBMS delivery description. The method further includes receiving a non-MBMS uniform resource locator (URL) for the content when the MBMS is not available for the content.

TECHNICAL FIELD

This disclosure relates generally to multi-media broadcast/multicast services (MBMS). More specifically, this disclosure relates to a method and apparatus for flexible broadcast service over MBMS.

BACKGROUND

The MBMS specification is built around two delivery methods, download and streaming, which are used to build user services. A user service consists of one or more delivery methods, auxiliary delivery procedures, such as file repair and reception reporting, and a user service description to enable selection and access to the service. Over the past years, MBMS has proven to be most relevant for streaming of live events over a limited MBMS broadcast area and distribution of high popularity files such as firmware updates.

SUMMARY

Embodiments of the present disclosure provide a method and apparatus for flexible broadcast service over MBMS.

In one embodiment, a client device for flexible broadcast service over MBMS is provided. The method includes a memory; and one or more processors operably coupled to the memory. The one or more processors are configured to transmit a request for a location of content to a server. The one or more processors are also configured when a multimedia broadcast multicast service (MBMS) is available for the content, receive a MBMS delivery description for the location of the content, and join session for the MBMS that carries the content based on the MBMS delivery description. The one or more processors are further configured to receive a non-MBMS uniform resource locator (URL) for the content when a MBMS is not available for the content.

In another embodiment, a method for flexible broadcast service over MBMS is provided. The method includes transmitting a request for a location of content to a server. The method also includes when a multimedia broadcast multicast service (MBMS) is available for the content, receiving a MBMS delivery description for the location of the content, and joining session for the MBMS that carries the content based on the MBMS delivery description. The method further includes receiving a non-MBMS uniform resource locator (URL) for the content when a MBMS is not available for the content.

In another embodiment, a server for flexible broadcast service over MBMS is provided. The server includes a memory and one or more processors operably coupled to the memory. The one or more processors configured to receive a request for a location of content from a client device. The one or more processors are also configured to determine whether a multimedia broadcast multicast service (MBMS) is available for the content. The one or more processors are further configured to transmit a MBMS delivery description for the location of the content to enable the client device to join session for the MBMS that carries the content in response to a high demand for the content and transmit an indication that the content is unavailable over MBMS in response to low demand for the content.

DETAILED DESCRIPTION

An intuitive method of delivering the same content to a large group of users is to utilize a broadcasting mechanism instead of allocating dedicated network resources for every single user. Delivery of TV channels and push of large software updates over the air are examples of such services that benefit greatly from broadcast.

LTE defined the multimedia broadcast multicast service (MBMS) to address the needs of these services in the most cost-efficient way. It initially defined two different modes: broadcast and multicast. The multicast mode was however dropped as the savings were eliminated by the usage of tunneling of the user space multicast traffic.

FIG. 1illustrates an example computing system100according to this disclosure. The embodiment of the computing system100shown inFIG. 1is for illustration only. Other embodiments of the computing system100could be used without departing from the scope of this disclosure.

As shown inFIG. 1, the system100includes a network102, which facilitates communication between various components in the system100. For example, the network102may communicate internet protocol (IP) packets, frame relay frames, asynchronous transfer mode (ATM) cells, or other information between network addresses. The network102may include one or more local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), all or a portion of a global network such as the Internet, or any other communication system or systems at one or more locations.

The network102facilitates communications between at least one server104and various client devices106-114. Each server104includes any suitable computing or processing device that can provide computing services for one or more client devices. Each server104could, for example, include one or more processing devices, one or more memories storing instructions and data, and one or more network interfaces facilitating communication over the network102.

Each client device106-114represents any suitable computing or processing device that interacts with at least one server or other computing device(s) over the network102. In this example, the client devices106-114include a desktop computer106, a mobile telephone or smartphone108, a personal digital assistant (PDA)110, a laptop computer112, and a tablet computer114. However, any other or additional client devices could be used in the computing system100.

In this example, some client devices108-114communicate indirectly with the network102. For example, the client devices108-110communicate via one or more base stations116, such as cellular base stations or eNodeBs. Also, the client devices112-114communicate via one or more wireless access points118, such as IEEE 802.11 wireless access points. Note that these are for illustration only and that each client device could communicate directly with the network102or indirectly with the network102via any suitable intermediate device(s) or network(s).

FIGS. 2 and 3illustrate example devices in a computing system according to this disclosure. In particular,FIG. 2illustrates an example server200, andFIG. 3illustrates an example client device300. The server200could represent the server104inFIG. 1, and the client device300could represent one or more of the client devices106-114inFIG. 1.

As shown inFIG. 2, the server200includes a bus system205, which supports communication between at least one processing device210, at least one storage device215, at least one communications unit220, and at least one input/output (I/O) unit225.

The processing device210executes instructions that may be loaded into a memory230. The processing device210may include any suitable number(s) and type(s) of processors or other devices in any suitable arrangement. Example types of processing devices210include microprocessors, microcontrollers, digital signal processors, field programmable gate arrays, application specific integrated circuits, and discreet circuitry. The processing device210is configured to perform operations for unlocking an electronic device with an authenticated wearable device.

The memory230and a persistent storage235are examples of storage devices215, which represent any structure(s) capable of storing and facilitating retrieval of information (such as data, program code, and/or other suitable information on a temporary or permanent basis). The memory230may represent a random access memory or any other suitable volatile or non-volatile storage device(s). The persistent storage235may contain one or more components or devices supporting longer-term storage of data, such as a ready only memory, hard drive, flash memory, or optical disc.

The communications unit220supports communications with other systems or devices. For example, the communications unit220could include a network interface card or a wireless transceiver facilitating communications over the network102. The communications unit220may support communications through any suitable physical or wireless communication link(s).

The I/O unit225allows for input and output of data. For example, the I/O unit225may provide a connection for user input through a keyboard, mouse, keypad, touchscreen, or other suitable input device. The I/O unit225may also send output to a display, printer, or other suitable output device.

Note that whileFIG. 2is described as representing the server104ofFIG. 1, the same or similar structure could be used in one or more of the client devices106-114. For example, a laptop or desktop computer could have the same or similar structure as that shown inFIG. 2.

As shown inFIG. 3, the client device300includes an antenna305, a radio frequency (RF) transceiver310, transmit (TX) processing circuitry315, a microphone320, and receive (RX) processing circuitry325. The client device300also includes a speaker330, a main processor340, an input/output (I/O) interface (IF)345, a keypad350, a display355, and a memory360. The memory360includes a basic operating system (OS) program361and one or more applications362.

The main processor340is also coupled to the keypad350and the display unit355. The operator of the client device300can use the keypad350to enter data into the client device300. The display355may be a liquid crystal display or other display capable of rendering text and/or at least limited graphics, such as from web sites.

The memory360is coupled to the main processor340. Part of the memory360could include a random access memory (RAM), and another part of the memory360could include a flash memory or other read-only memory (ROM).

AlthoughFIGS. 2 and 3illustrate examples of devices in a computing system, various changes may be made toFIGS. 2 and 3. For example, various components inFIGS. 2 and 3could be combined, further subdivided, or omitted and additional components could be added according to particular needs. As a particular example, the main processor340could be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Also, whileFIG. 3illustrates the client device300configured as a mobile telephone or smartphone, client devices could be configured to operate as other types of mobile or stationary devices. In addition, as with computing and communication networks, client devices and servers can come in a wide variety of configurations, andFIGS. 2 and 3do not limit this disclosure to any particular client device or server.

FIG. 4illustrates an example reference model400for the relationships between the user services405, the delivery methods410, and the bearer services415.FIG. 5illustrates an example protocol stack500according to the various embodiments of the present disclosure. The embodiment of the reference model400illustrated inFIG. 4and the protocol stack500inFIG. 5are for illustration only.FIGS. 4 and 5do not limit the scope of this disclosure to any particular implementation of an electronic device.

MBMS for LTE (eMBMS) relies on broadcasting support on the air interface, usage of IP multicast for the transport of IP packets between the gateway and the base stations, and specific procedures for establishing and maintaining MBMS sessions. The key components of the MBMS solutions are the MBMS user services405and the MBMS bearer services415. An MBMS bearer service415is a point-to-multi-pointing content distribution channel that provides a set of specific functionality in the mobile network and the user equipments (UEs). The key network element in MBMS architecture is the broadcast multicast—service center (BM-SC) which establishes MBMS user services, created MBMS user bearers and performs the media delivery over MBMS as well as the other functions (security, service announcement, associated delivery procedures, . . . )

An MBMS user service405is an instantiation of a set of tools to deliver content to the UEs. It consists of one or more delivery methods, a service description and a service announcement procedure, associated delivery procedures, security and reporting tools.

Currently, there are three different delivery methods410that are defined streaming420, download425, and group communication430. Streaming420was designed as part of MBMS Release 6 to cater for mobile TV services. Streaming420relies on the RTP/RTCP protocol505for media data delivery and defines a FEC framework that supports protection of multiple media streams together. The download425delivery method provides the functionality of reliably delivering files to the UEs. The UEs uses the file delivery over unidirectional transport (FLUTE) protocol510with its FEC building block as well as file repair over HTTP to enhance the reliability of the service. With the emergence of media streaming over HTTP, the value of the streaming420delivery method has diminished significantly due to the high complexity of maintaining a streaming server that uses RTP/RTCP505. Instead, the download425delivery method has been enhanced slightly to support the delivery of HTTP streaming content over FLUTE510.

The third and most recent addition to the delivery methods of MBMS is the group communication (GC)430delivery method. The GC430delivery method has been added to address the needs of public safety services and other services that require higher flexibility that the one offered by the other two methods. For instance, services may wish to use different protocols, formats, and service announcement procedures than the ones that are defined by the download425and the streaming420delivery methods. As an example, a streaming420service provider might wish to deliver HLS formatted media data over the FCAST protocol. In this case, the download425delivery method cannot be used as it does neither support the format nor the protocol. Another example is the public safety service s that wishes to send encrypted speech data over a very low delay channel. The streaming method is not suitable for this case as the BM-SC would have to do the encryption on behalf of the service provider and the delays that e.g. the FEC framework enforces would not be acceptable to the service provider.

The file download profile is designed to be used for delivery of files using an offline-type delivery mode. Files are usually pushed by the broadcast multicast service center (BM-SC) at scheduled times and cached locally for later consumption by the applications on the user equipment (UE). The file download profile is identified by the following URI: “urn:3gpp:mbms:download:2015”. The uniform resource identifier (URI) is provided as part of the multimedia broadcast multicast services (MBMS) metadata envelope that carries the MBMS user service description metadata fragment.

The usage of the download session announcement shall be delivered in one of the following ways:

1. Over the air (OTA)—hypertext transfer protocol (HTTP) push bearer shall only carry the metadata envelope that contains a single metadata item, which contains the MBMS USD metadata fragment. The UE that is interested in the user service shall request all referenced fragments using HTTP.

2. Pre-configured MBMS user service that triggers the setup of MBMS bearer services on need basis and over a pre-configured service area.

3. MBMS is activated on-demand as a response to a request for popular content that the operator then decides to serve over MBMS.

The user service description (USD) shall contain the following metadata fragments:

1. A user service description metadata fragment that shall contain exactly one delivery method, which shall contain exactly one associatedProcedureDescriptionURI.

2. The associatedProcedureDescription fragment shall contain one postFileRepair element that supports byte-range repairs.

3. No protectionDescription for transport-level security shall be provided and content should be protected using a content protection solution such as open mobile alliance (OMA)—digital rights media (DRM).

4. A schedule fragment may be provided to indicate the transmission time(s) for each resource. The schedule fragment shall be present for an MBMS service that is announced over OTA-PUSH.

The delivery function uses FLUTE610as the transport protocol. There should be only one FLUTE session.

In addition, the delivery of the session content over unicast is not supported in this profile. The keep updated service should be supported.

A UE compatible with this profile should support MBMS on demand. The reception of a file over unicast may be redirected to MBMS for reception of the requested resource. The UE shall account for possible delays in the delivery.

Dynamic adaptive streaming over HTTP (DASH) Profile515

The DASH Profile515is a profile specifically defined for DASH content delivery over hybrid unicast/broadcast channels. The DASH presentation consists of a set of representations, some of which are delivered over broadcast (usually a main audio and video representation) and other complementary or alternative representations delivered over unicast. The DASH profile is identified by the URI: “urn:3gpp:mbms:dash:2015”.

The service announcement for DASH over MBMS shall be delivered in one of the following ways: a dedicated pre-configured MBMS channel that carries MBMS metadata envelopes. The media presentation description (MPD) and the session description protocol (SDP) files that describe the locations of the actual MBMS user service shall be delivered over the same announcement channel. Other metadata fragments may be delivered over the broadcast channel that carries the DASH content or it may be fetched over unicast.

The service announcement shall contain the following metadata fragments:

USD metadata fragment, which contains at least one deliveryMethod. No associatedDeliveryProcedureURI or protectionDescriptionURI shall be present. It shall contain a single appService element that references the MPD in the appServiceDescriptionURI. The initiation segments shall be distributed over the broadcast channel that carries the corresponding representation.

The delivery function uses FLUTE610as the transport protocol. Multiple FLUTE sessions may be used for the delivery of the content, where the contents of any broadcast representation shall be delivered over only one FLUTE session. Unicast fallback shall be supported.

The bearer415profile defines a bare minimum user service that allows for usage of an MBMS bearer service with minimal data and control plane components, thus giving more flexibility to the application that uses the MBMS delivery. The bearer415profile enables the UE to receive UDP datagrams sent to a given multicast address and without introducing any additional processing delays at the MBMS middleware.

The service announcement in the bearer profile is constrained as follows:

The service announcement consists of two metadata fragments only the USD metadata fragment and an SDP fragment. The SDP fragment shall be referenced by the USD fragment and not embedded. The deliveryMethod element shall only contain the sessionDescriptionURI element.

The service announcement is delivered in one of the following ways: as a response to an MBMS address resolution request. Made directly available to the UE by the sending application through a dedicated interface. The delivery function used by the bearer profile shall provide access to UDP datagrams delivered to a multicast address. The reception of the multicast stream may be triggered through external signaling received by the UE, e.g. using the GC1 interface of the group communication enabler.

No additional transport functionality is provided in this profile for higher flexibility. This profile allows, for instance to realize a group communication service using session initiation protocol (SIP) and (real-time protocol) RTP on top of MBMS. The SDP gives further details on the transport protocol and configuration that are used by the application.

FIGS. 6 and 7illustrate example flow diagrams600and700for resolving an MBMS URL according to the various embodiments of the present disclosure. For example, the process depicted inFIGS. 6 and 7may be performed by server200inFIG. 2or client device300inFIG. 3.

In operation605, the UE601resolves an MBMS URL with the name server602. The UE601requests content from the server. For example, a user selects a video to watch on a client device300and the client device300transmits a request for the video to a server200. The server200receives the requests and determines a demand for the video. The server200determines a high demand for the video when the requests for the video are greater than a threshold and a low demand when the requests for the video are less than the threshold. The threshold can be determined by capacity of the server, a predetermined number of requests, etc. The demand for the video can also be based on historic data of previous videos in a series, with similar creators, etc.

In operation610, the name server602delivers an MBMS description to the UE601or redirects the UE601to a HTTP URL. When the content is in high demand, the server200transmits an MBMS delivery description to the client device300. When the server200determines that there is a low demand for the content, the server200redirects the client device300with an HTTP URL. The MBMS delivery description includes the information to access the content from a BM-SC, depending on the API. When a file delivery API provides the MBMS delivery description, the receive MBMS delivery description include a broadcast file with a time frame when the file will become available to the UE601. When a DASH API provides the delivery description, the received MBMS delivery description includes an objectflow object with an initialization segment for the content and a rule for matching the segments of the content. When a socket API provides the MBMS delivery description, the received MBMS delivery description includes a socket object with a session description protocol containing a specific multicast destination. In operation615, the UE601joins the MBMS session.

In operation620, the UE601receives resource over MBMS from the BM-SC603. The client device300receives the resources through the BM-SC from the source. The resources pass-through the BM-SC without the BM-SC generating data.

In operation705, the UE701requests an HTTP URL from the proxy server702. The client device300requests content from the server200. The server200determines whether MBMS is available for the content requested by the client device300. When the server200determines that MBMS is not available, the server200transmits a HTTP URL for the client device to receive the content (not illustrated).

In operation710, the proxy server702redirects the UE701to an MBMS URL. When the server200determines that the MBMS is available, the server200redirects the client device300to a MBMS URL.

In operation715, the UE701resolves an MBMS URL with the name server703. The client device300transmits the MBMS URL to a server200. The server200determines the MBMS delivery description based on the MBMS URL.

In operation720, the name server703delivers an MBMS description to the UE701. The server200transmits an MBMS delivery description to the client device300for receiving the content. The MBMS delivery description includes the information to access the content from a BM-SC, depending on the API. When a file delivery API provides the MBMS delivery description, the receive MBMS delivery description include a broadcast file with a time frame when the file will become available to the UE601. When a DASH API provides the delivery description, the received MBMS delivery description includes an objectflow object with an initialization segment for the content and a rule for matching the segments of the content. When a socket API provides the MBMS delivery description, the received MBMS delivery description includes a socket object with a session description protocol containing a specific multicast destination. In operation725, the UE701joins the MBMS session.

In operation730, the UE701receives resource over MBMS from the BM-SC704. The client device300receives the resources through the BM-SC from the source. The resources pass-through the BM-SC without the BM-SC generating data.

An MBMS URI scheme is defined in this specification to simplify the access to resources and streams that are delivered over MBMS or that may potentially be made available over MBMS. The UE601registers the MBMS middleware as an MBMS protocol handler, in order to receive all resource requests that use the MBMS URI scheme.

“MBMS” URIs have the following ABNF syntax:

<host> and <port> are specified in RFC3986.

The “MBMS” URI scheme is used to reference a resource or a data stream that may be delivered over MBMS. The MBMS URI shall be resolved by the MBMS protocol handler using the procedure defined inFIGS. 6 and 7. If the resource or stream is not delivered over MBMS, the UE601is redirected to the unicast delivery alternative.

The address resolution procedure consists of the following steps:

Launch the MBMS protocol handler with the received MBMS URL. MBMS protocol handler sends a POST request to the pre-configured MBMS Address Resolution Server (ARS) with the MBMS URL as the value of a NVP with the name “URL”. The MBMS ARS responds with the MBMS metadata envelope. Alternatively, the MBMS ARS redirects the UE601to the unicast location of the requested resource.

If the URL references a single resource, the mapping between the MBMS URL and the FLUTE URL is either implicit (i.e. replacing the MBMS scheme with the http scheme) or it may be explicitly provided as part of the address resolution response. In addition, an indication by the ARS to the client that other related resources will also be available over MBMS may also be included as part of the response. The SDP shall carry the time information for the transmission provided in UTC time. Additionally, a schedule metadata fragment may be provided to specify the delivery time of a particular resource.

The file delivery API defines an API that provides client functionality for requesting and receiving files over MBMS. The API defines a BroadcastFile object that provides functions for requesting a resource, for receiving events about the status of requested files, and for accessing files delivered over MBMS.

The BroadcastFile object provides a method that takes the MBMS URL of the resource. It performs the following operations:

It resolves the MBMS URL and decides if delivery is happening over unicast or over broadcast. If the delivery is done over unicast, the response shall contain a redirection to the unicast address. If the delivery is done over broadcast, the response shall contain an indication of the time frame when the file will become available at the UE601. If the file is already received, the response shall contain a URL to the local location of the file on the UE601.

The BroadcastFile defines the following events:

A progress event occurs when the file reception is ongoing. A partial event occurs when the file reception is aborted with partial file content available. The received byte ranges are provided to the application. A received event occurs the requested file is received completely and is ready to be fetched. A purge event occurs when a requested file is scheduled to be removed from the local cache by an indicated time.

The DASH API defines an API that provides client functionality to access content of Representations of a DASH Presentation over MBMS. An ObjectFlow object is defined by the DASH API to retrieve a set of related files. The ObjectFlow provides an initiation method that takes the URL of the initialization segment for the Representation of interest and a rule for matching the segments of that Representation. The rule can either be a RepresentationID, a URL template, or a base URL.

The ObjectFlow defines the following events:

A received event occurs when an object of an object flow has been received. The first object that is received shall be the initiation segment. A partial event occurs when partial object of an object flow has been received. A gone event has occurred when an MBMS reception is not available anymore and unicast reception shall be used instead.

The plain Socket API defines an API that provides client functionality to access a UDP datagram stream delivered over MBMS. A socket object is defined by the socket API to open and receive UDP datagrams sent to a specific multicast destination address. The socket API provides a resolve function that takes as argument the MBMS URL and returns the SDP of the session. The socket API provides a connect function that takes as arguments the multicast destination address and the UDP port. The socket API provides a receive function that is used to receive a UDP datagram payload that was received over MBMS. The packets are forwarded to the application in the same order as they were received. The socket API also defines the following events:

A ready event occurs when the receiver is informed that one or more packets are ready for reception. A gone event occurs when the receiver is informed that the MBMS reception is not available anymore.

AlthoughFIGS. 6 and 7illustrate examples of flow diagrams600and700for resolving an MBMS URL, respectively, various changes could be made toFIGS. 6 and 7. For example, while shown as a series of steps, various steps in each figure could overlap, occur in parallel, occur in a different order, or occur multiple times.

FIG. 8illustrates an example MBMS framing for a bearer delivery method800according to the various embodiments of the present disclosure.FIG. 9illustrates an example MBMS framing header900according to the various embodiments of the present disclosure. The embodiment of the MBMS framing for a bearer delivery method800illustrated inFIG. 8and the MBMS framing header900illustrated inFIG. 9are for illustration only.FIGS. 8 and 9do not limit the scope of this disclosure to any particular implementation of an electronic device.

A configurable framing protocol, FEC framework, and buffering model are disclosed to adjust the quality of the transport based on delay and error requirements by the service. An MBMS framing protocol910is defined to encapsulate user plane UDP packets905to provide MBMS specific functionality. The MBMS framing protocol910allows for the addressing of UDP datagrams and the detection of missing packets. If FEC is used, the FEC repair data is delivered over a separate media session.

The source packets are modified to include the packet sequence number915immediately after the UDP header. The UDP checksum920shall be recalculated after the MBMS framing is performed. The SDP for the bearer delivery method is provided by the content origin at content ingestion and is transparent to the BM-SC603. The SDP is provided to the MBMS client directly via the application to the UE601. The SDP contains at least the following SDP parameters: the destination IP address and port number, the protocol ID for each media session, the temporary mobile group identity (TMGI) of the MBMS Bearer, the maximum delay tolerance attribute, and the requested QoE reporting as defined in section 8.3.2.1 as a media level attribute.

The “max-allowed-delay” is a media level SDP attribute that informs the receiver about the maximum allowed delay from the time of reception of the UDP datagram to the time of passing it to the receiving application. This time sets an upper boundary on time consumed for any operations such as FEC decoding. This value is indicated in milliseconds.

The identification of the MBMS framing protocol is provided as part of the protocol ID. For example, it could be UDP/MBMS/RTP for RTP traffic that is carried over the MBMS framing protocol and UDP.

In certain embodiments of the present disclosure, MBMS framing may be done by encapsulating UDP datagrams in MBMS/UDP/IP packets. In certain embodiments of the present disclosure, information about the measured quality of service (QoS) is reported back to the server.

The metric “UDP Datagram Loss” indicates the number of consecutive UDP datagram losses that are detected through a gap in MBMS framing packet sequence number. This metric is only applicable to the bearer delivery method.

Another metric “UDP_Datagram Jitter” provides the measured delay jitter that has been measured for example as the deviation from the average transmission delay. In order to get this measurement, the framing protocol must have a delivery timestamp that is set by the BM-SC when transmitting a UDP datagram.