CN107438991B

CN107438991B - Method and apparatus for flexible broadcast service via multimedia broadcast multicast service

Info

Publication number: CN107438991B
Application number: CN201680020002.4A
Authority: CN
Inventors: I.鲍亚齐兹; 朴勍模
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2015-04-07
Filing date: 2016-04-07
Publication date: 2021-04-30
Anticipated expiration: 2036-04-07
Also published as: EP3281382A4; EP3281382A1; CN107438991A

Abstract

A method and apparatus for a flexible broadcast service via Multimedia Broadcast Multicast Service (MBMS). The method includes sending a request to a server for a location of content. The method further comprises the following steps: when an MBMS is available for the content, an MBMS transmission description for a location of the content is received and a session of the MBMS carrying the content is joined based on the MBMS transmission description. The method further comprises the following steps: when the MBMS is not available for the content, a non-MBMS Uniform Resource Locator (URL) for the content is received.

Description

Method and apparatus for flexible broadcast service via multimedia broadcast multicast service

Technical Field

The present disclosure relates generally to multimedia broadcast/multicast services (MBMS). More particularly, the present disclosure relates to a method and apparatus for a flexible broadcast service via MBMS.

Background

The MBMS specification is built around two transmission modes, i.e., downloading and streaming, for building a user service. The user service includes one or more delivery methods, auxiliary delivery procedures such as file repair and reception reporting, and a user service description for enabling selection and access to services. In the last years, MBMS has proven to be most suitable for live streaming in limited MBMS broadcast areas and distribution of high-popularity files such as firmware updates.

Disclosure of Invention

Technical problem

An aspect of the present disclosure provides a broadcast service with higher performance.

Solution to the problem

Embodiments of the present disclosure provide methods and apparatus for flexible broadcast services via MBMS.

In one embodiment, a client device for flexible broadcast services via MBMS is provided. The method comprises the following steps: a memory; and one or more processors operatively coupled to the memory. The one or more processors are configured to: a request for a location of the content is sent to a server. The one or more processors are further configured to: when a Multimedia Broadcast Multicast Service (MBMS) is available for the content, an MBMS delivery description for a location of the content is received and a session of the MBMS carrying the content is joined based on the MBMS delivery description. The one or more processors are further configured to: when the MBMS is not available for the content, a non-MBMS Uniform Resource Locator (URL) for the content is received.

In another embodiment, a method for flexible broadcast service via MBMS is provided. The method includes sending a request to a server for a location of content. The method further comprises the following steps: when a Multimedia Broadcast Multicast Service (MBMS) is available for the content, an MBMS delivery description for a location of the content is received and a session of the MBMS carrying the content is joined based on the MBMS delivery description. The method further comprises the following steps: when the MBMS is not available for the content, a non-MBMS Uniform Resource Locator (URL) for the content is received.

In another embodiment, a server for a flexible broadcast service via MBMS is provided. The server includes: a memory; and one or more processors operatively coupled to the memory. The one or more processors are configured to: a request for a location of content is received from a client device. The one or more processors are further configured to: determining whether a Multimedia Broadcast Multicast Service (MBMS) is available for the content. The one or more processors are further configured to: in response to a high demand for content, sending an MBMS delivery description of a location for the content to enable a client device to join a session of an MBMS carrying the content; and in response to a low demand for content, sending an indication that the content is not available via MBMS.

Other technical features may be readily apparent to one skilled in the art from the figures, descriptions, and claims.

Before proceeding with the following detailed description, it may be helpful to set forth definitions of certain words and phrases used in this patent document. The term "couple" and its derivatives refer to direct or indirect communication between two or more elements, whether or not those elements are in physical contact with one another. The terms "send," "receive," and "communicate," as well as derivatives thereof, encompass both direct and indirect communication. The terms "include" and "comprise," as well as derivatives thereof, mean inclusion without limitation. The term "or" is inclusive, meaning and/or. The phrase "associated with …" and derivatives thereof means including, included within …, interconnected with …, contained within …, connected to or with …, coupled to or with …, communicable with …, cooperative with …, interwoven, juxtaposed, proximate, bound to or with …, having the property of …, having a relationship with …, and the like. The term "controller" means any device, system, or part thereof that controls at least one operation. Such controllers may be implemented in hardware, or a combination of hardware and software and/or firmware. The functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. The phrase "at least one of …, when used with a list of items, means that different combinations of one or more of the listed items can be used and only one item in the list can be required. For example, "at least one of A, B and C" includes any of the following combinations: A. b, C, A and B, A and C, B and C, and A and B and C.

Further, the various functions described below may be implemented or supported by one or more computer programs, each formed from computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or portions thereof adapted for implementation in suitable computer readable program code. The phrase "computer readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer readable medium" includes any type of medium capable of being accessed by a computer, such as Read Only Memory (ROM), Random Access Memory (RAM), a hard disk drive, a Compact Disc (CD), a Digital Video Disc (DVD), or any other type of memory. A "non-transitory" computer-readable medium excludes wired, wireless, optical, or other communication links that convey transitory electrical or other signals. Non-transitory computer readable media include media in which data can be stored permanently, as well as media in which data can be stored and subsequently overwritten, such as rewritable optical disks or erasable storage devices.

Definitions for certain other words and phrases are provided throughout this patent document. Those of ordinary skill in the art should understand that in many, if not most instances, such definitions apply to prior, as well as future uses of such defined words and phrases.

Advantageous effects of the invention

The performance of the broadcast service can be improved.

Drawings

For a more complete understanding of the present disclosure and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which like reference numbers represent like parts:

FIG. 1 illustrates an example computing system in accordance with various embodiments of the present disclosure;

FIGS. 2 and 3 illustrate example devices in a computing system according to various embodiments of the present disclosure;

FIG. 4 illustrates an example reference model for a relationship between user services, delivery methods, and bearer services according to various embodiments of the present disclosure;

fig. 5 illustrates an example protocol stack in accordance with various embodiments of the present disclosure;

fig. 6 illustrates an example flow diagram for resolving an MBMS URL in accordance with various embodiments of the present disclosure;

fig. 7 illustrates another example flow diagram for resolving an MBMS URL in accordance with various embodiments of the present disclosure;

fig. 8 illustrates example MBMS framing (framing) for a bearer delivery method according to various embodiments of the present disclosure; and

fig. 9 illustrates an example MBMS framing header, in accordance with various embodiments of the present disclosure.

Detailed Description

Figures 1 through 9, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the disclosure may be implemented in any suitably arranged system or device.

An intuitive way to deliver the same content to a large user base is to use a broadcast mechanism instead of allocating dedicated network resources for each individual user. Over-the-air delivery of TV channels and over-the-air delivery of large software updates are examples of such services that are highly beneficial from broadcasting.

LTE defines Multimedia Broadcast Multicast Services (MBMS) that fulfill the needs of these services in the most cost-effective way. It initially defines two different modes: broadcast and multicast. However, the multicast mode is discarded because the savings are eliminated due to the use of tunneling for user-space multicast traffic.

FIG. 1 illustrates an example computing system 100 in accordance with this disclosure. The embodiment of computing system 100 shown in FIG. 1 is for illustration only. Other embodiments of the computing system 100 may be used without departing from the scope of this disclosure.

As shown in FIG. 1, system 100 includes a network 102 that facilitates communication between various components in system 100. For example, the network 102 may communicate Internet Protocol (IP) packets, frame relay frames, Asynchronous Transfer Mode (ATM) cells, or other information between network addresses. Network 102 may 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 at one or more locations.

The network 102 facilitates communication between at least one server 104 and

various client devices

106 and 114. Each server 104 includes any suitable computing or processing device that may provide computing services for one or more client devices. For example, each server 104 may include one or more processing devices, one or more memories storing instructions and data, and one or more network interfaces that facilitate communication via network 102.

Each client device 106 represents any suitable computing or processing device that interacts with at least one server or other computing device via network 102. In this example,

client devices

106 and 114 include desktop computers 106, mobile phones or smart phones 108, Personal Digital Assistants (PDAs) 110, laptop computers 112, and tablet computers 114. However, any other or additional client devices may be used in computing system 100.

In this example, some

client devices

108 and 114 communicate indirectly with the network 102. For example, the

client devices

108 and 110 communicate via one or more base stations 116 (such as cellular base stations or enodebs). Further, the

client devices

112 and 114 communicate via one or more wireless access points 118, such as IEEE 802.11 wireless access points. Note that these are for illustration only, and each client device may communicate directly with network 102, or indirectly with network 102 via any suitable intermediate device or network.

Although FIG. 1 illustrates one example of a computing system 100, various changes may be made to FIG. 1. For example, system 100 may include any number of each component in any suitable arrangement. In general, computing and communication systems have a wide variety of configurations, and fig. 1 does not limit the scope of the present disclosure to any particular configuration. Although FIG. 1 illustrates one operating environment in which the various features disclosed in this patent document may be used, the features may be used in any other suitable system.

Fig. 2 and 3 illustrate example devices in a computing system according to this disclosure. In particular, fig. 2 illustrates an example server 200, and fig. 3 illustrates an example client device 300. Server 200 may represent server 104 in fig. 1, and client device 300 may represent one or more of

client devices

106 and 114 in fig. 1.

As shown in FIG. 2, server 200 includes a bus system 205 that supports communication between at least one processing device 210, at least one storage device 215, at least one communication unit 220, and at least one input/output (I/O) unit 225.

Processing device 210 executes instructions that may be loaded into memory 230. Processing device 210 may include any suitable number and type of processors or other devices in any suitable arrangement. Example types of processing devices 210 include microprocessors, microcontrollers, digital signal processors, field programmable gate arrays, application specific integrated circuits, and discrete circuits. The processing device 210 is configured to perform operations for unlocking the electronic device with the authenticated wearable device.

Memory 230 and persistent storage 235 are examples of storage 215, which represents any structure capable of storing information (e.g., data, program code, and/or other suitable information, whether temporary or permanent) and facilitating retrieval of the information. Memory 230 may represent a random access memory or any other suitable volatile or non-volatile storage device. Persistent storage 235 may contain one or more components or devices that support long-term storage of data, such as read-only memory, hard drives, flash memory, or optical disks.

The communication unit 220 supports communication with other systems or devices. For example, the communication unit 220 may include a network interface card or a wireless transceiver that facilitates communication via the network 102. The communication unit 220 may support communications over any suitable physical or wireless communication link.

I/O unit 225 allows input and output of data. For example, the I/O unit 225 may provide a connection for user input through a keyboard, mouse, keypad (keypad), touch screen, or other suitable input device. I/O unit 225 may also send output to a display, a printer, or other suitable output device.

Note that although FIG. 2 is described as representing server 104 of FIG. 1, the same or similar structures may be used in one or more of

client devices

106 and 114. For example, a laptop computer or desktop computer may have the same or similar structure as that shown in FIG. 2.

As shown in fig. 3, client device 300 includes an antenna 305, a Radio Frequency (RF) transceiver 310, Transmit (TX) processing circuitry 315, a microphone 320, and Receive (RX) processing circuitry 325. Client device 300 also includes speaker 330, main processor 340, input/output (I/O) Interface (IF)345, keypad 350, display 355, and memory 360. Memory 360 includes a basic Operating System (OS) program 361 and one or more applications 362.

RF transceiver 310 receives an incoming RF signal from antenna 305 that is transmitted by another component in the system. The RF transceiver 310 downconverts the incoming RF signal to generate an Intermediate Frequency (IF) or baseband signal. The IF or baseband signal is sent to RX processing circuitry 325, which RX processing circuitry 325 generates a processed baseband signal by filtering, decoding, and/or digitizing the baseband or IF signal. RX processing circuitry 325 sends the processed baseband signal to speaker 330 (e.g., for voice data) or to main processor 340 for further processing, such as for web browsing data.

TX processing circuitry 315 receives analog or digital voice data from microphone 320 or other outgoing baseband data (e.g., network data, email, or interactive video game data) from main processor 340. TX processing circuitry 315 encodes, multiplexes, and/or digitizes the outgoing baseband data to generate a processed baseband or IF signal. RF transceiver 310 receives the outgoing processed baseband or IF signals from TX processing circuitry 315 and upconverts the baseband or IF signals to RF signals, which are transmitted via antenna 305.

Main processor 340 may include one or more processors or other processing devices and executes basic OS program 361 stored in memory 360 to control overall operation of client device 300. For example, main processor 340 may control the reception of forward channel signals and the transmission of reverse channel signals by RF transceiver 310, RX processing circuitry 325, and TX processing circuitry 315 in accordance with well-known principles. In some embodiments, main processor 340 includes at least one microprocessor or microcontroller.

Main processor 340 may also be capable of executing other processes and programs resident in memory 360 such as operations for flexible broadcast services via MBMS. Main processor 340 may move data into or out of memory 360 as required by the processing being performed. In some embodiments, main processor 340 is configured to execute applications 362 based on OS program 361 or in response to signals received from an external device or operator. Main processor 340 is also coupled to I/O interface 345, I/O interface 345 providing client device 300 with the ability to connect to other devices, such as laptop computers and handheld computers. The I/O interface 345 is the communication path between these accessories and the main controller 340.

Main processor 340 is also coupled to keypad 350 and display unit 355. An operator of client device 300 may enter data into client device 300 using keypad 350. Display 355 may be a liquid crystal display or other display capable of presenting text and/or at least limited graphics, such as from a website.

Memory 360 is coupled to main processor 340. A portion of memory 360 may include Random Access Memory (RAM) and another portion of memory 360 may include flash memory or other Read Only Memory (ROM).

Although fig. 2 and 3 illustrate examples of devices in a computing system, various changes may be made to fig. 2 and 3. For example, the various components in fig. 2 and 3 may be combined, further subdivided, or omitted, and additional components may be added according to particular needs. As a specific example, main processor 340 may be divided into multiple processors, such as one or more Central Processing Units (CPUs) and one or more Graphics Processing Units (GPUs). Additionally, although fig. 3 illustrates the client device 300 configured as a mobile phone or smart phone, the client device may be configured to operate as other types of mobile or fixed devices. Further, with respect to computing and communication networks, client devices and servers may have a wide variety of configurations, and fig. 2 and 3 do not limit the present disclosure to any particular client device or server.

Fig. 4 shows an example reference model 400 for the relationship between a user service 405, a delivery method 410, and a bearer service 415. Fig. 5 illustrates an example protocol stack 500 in accordance with various embodiments of the present disclosure. The embodiments of the reference model 400 shown in fig. 4 and the protocol stack 500 in fig. 5 are for illustration only. Fig. 4 and 5 do not limit the scope of the present disclosure to any particular implementation of an electronic device.

MBMS (embms) for LTE relies on broadcast support of the air interface, the use of IP multicast for transporting IP packets between the gateway and the base station, and specific procedures for establishing and maintaining MBMS sessions. The key components of the MBMS solution are MBMS user service 405 and MBMS bearer service 415. The MBMS bearer service 415 is a point-to-multipoint content distribution channel that provides a specific set of functions in the mobile network and User Equipment (UE). A key network element in the MBMS architecture is the broadcast multicast service center (BM-SC) which establishes MBMS user services, creates MBMS user bearers, and performs media delivery via MBMS as well as other functions (security, service announcement, related delivery procedures … …).

The MBMS user service 405 is an instantiation of a set of tools for delivering content to a UE. It consists of one or more delivery methods, service description and service announcement procedures, related delivery procedures, security and reporting tools.

Currently, there are three different delivery methods 410, defined as streaming 420, downloading 425, and group communication 430. Streaming 420 is designed as part of MBMS release 6 to provide mobile TV services. Streaming 420 relies on the RTP/RTCP protocol 505 for media data transport and defines an FEC framework that supports protecting multiple media streams together. The download 425 delivery method provides the functionality to deliver the file reliably to the UE. The UE uses file delivery via the unidirectional transport (FLUTE) protocol 510 with its FEC building blocks, and file repair via HTTP to enhance the reliability of the service. With the advent of media streaming over HTTP, the value of the streaming 420 delivery method is significantly reduced due to the high complexity of maintaining a streaming server using RTP/RTCP 505. Instead, the download 425 delivery method has been slightly enhanced to support delivery of HTTP streaming content via FLUTE 510.

A third, also recently added delivery method for MBMS is the Group Communication (GC)430 delivery method. The GC 430 delivery method is added to address the need for public safety services and other services that require greater flexibility than provided by the other two methods. For example, the service may wish to use a different protocol, format, and service announcement procedure than defined by the download 425 and streaming 420 delivery methods. As an example, a streaming 420 service provider may wish to transmit media data in HLS format via the FCAST protocol. In this case, the download 425 delivery method cannot be used because it neither supports the format nor the protocol. Another example is a public safety service that wishes to send encrypted voice data via a very low latency channel. The streaming approach is not suitable for this case because the BM-SC would need to encrypt on behalf of the service provider and the delay imposed by, for example, the FEC framework, is unacceptable to the service provider.

The file download profile is designed to be used to transfer files using an offline transfer mode. Files are typically pushed by a broadcast multicast service center (BM-SC) at predetermined times and cached locally for subsequent use by applications on User Equipment (UE). The file download configuration file is identified by the following URI: "urn: 3gpp: mbms: download: 2015". A Uniform Resource Identifier (URI) is provided as part of a Multimedia Broadcast Multicast Service (MBMS) metadata envelope carrying MBMS user service description metadata fragments.

The use of the download session announcement should be communicated in one of the following ways:

1. over-the-air (OTA) -hypertext transfer protocol (HTTP) push bearers should only carry a metadata envelope containing a single metadata item containing the MBMS USD metadata fragment. UEs interested in user services should request all referenced fragments using HTTP.

2.A pre-configured MBMS user service that triggers the establishment of an MBMS bearer service as needed and over a pre-configured service area.

3. The MBMS is activated on demand in response to a request by the operator to subsequently decide on popular content to provide the service via the MBMS.

The User Service Description (USD) shall contain the following pieces of metadata:

1. the user service description metadata fragment, which should contain only one delivery method, should contain only one associatedprocedurescriptionuri.

An associatedProcedureDescription fragment shall contain one postfilereparator element that supports byte range repair.

3. Protection description for transport level security should not be provided and content protection solutions such as Open Mobile Alliance (OMA) -Digital Rights Media (DRM) should be used to protect content.

4. A scheduling segment may be provided to indicate the transmission time of each resource. For MBMS services announced via OTA-PUSH (PUSH), there should be a scheduled segment.

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

Furthermore, the delivery of session content via unicast is not supported in this profile. A keep-alive service should be supported.

UEs compatible with this profile should support MBMS running on demand. Receiving the file via unicast may be redirected to MBMS to receive the requested resources. The UE should take into account possible transmission delays.

Dynamic adaptive streaming via HTTP (DASH) profile 515

DASH profile 515 is a profile defined specifically for DASH content delivery over a hybrid unicast/broadcast channel. DASH presentation consists of a set of representations: some of the representations are transmitted via broadcast (typically the main audio and video representations), and other supplemental or alternative representations are transmitted via unicast. DASH configuration file is represented by URI: "urn: 3gpp: mbms: dash: 2015".

Service announcements via DASH for MBMS should be delivered in one of the following ways: a dedicated pre-configured MBMS channel carrying an MBMS metadata envelope. A Media Presentation Description (MPD) and a Session Description Protocol (SDP) file describing the location of the actual MBMS user service should be transmitted via the same announcement channel. Other metadata fragments may be delivered via a broadcast channel carrying DASH content, or may be grabbed via unicast.

The service announcement should contain the following pieces of metadata:

a USD metadata fragment comprising at least one deliveryMethod. There should be no associatedprocedurescriptionuri or protectDescriptionURI. It should contain a single appService element that references the MPD in the appServiceDescriptionURI. The start segment should be distributed via a broadcast channel carrying the corresponding representation.

The delivery function uses FLUTE 610 as the transport protocol. Multiple FLUTE sessions can be used to deliver content, where any broadcast-represented content should be delivered via only one FLUTE session. Unicast fallback (fallback) should be supported.

Bearer configuration file 415

The bearer 415 profile defines a minimum of user services that allow the MBMS bearer service to be used with a minimum of data and control plane components, thereby giving more flexibility to applications using MBMS delivery. The bearer 415 profile enables the UE to receive UDP datagrams sent to a given multicast address without introducing any additional processing delay at the MBMS middleware.

The service announcement constraints in the bearer profile are as follows:

the service announcement consists of only two metadata fragments, the USD metadata fragment and the SDP fragment. The SDP fragment shall be referenced by the USD fragment without being embedded. The deliveryMethod element should contain only a sessionDescriptionURI element.

The service announcement is transmitted in one of the following ways: as a response to the MBMS address resolution request. Is directly available to the UE over the dedicated interface by means of the sending application. The transport function used by the bearer profile should provide access to UDP datagrams transported to the multicast address. The reception of the multicast stream may be triggered by external signaling received by the UE, for example using the GC1 interface of the group communication enabler (enabler).

No additional transfer functionality is provided in this configuration file for greater flexibility. This profile allows group communication services using Session Initiation Protocol (SIP) and (real time protocol) RTP to be implemented on top of MBMS, for example. SDP gives further details about the transport protocols and configurations used by the application.

Fig. 6 and 7 illustrate example flow diagrams 600 and 700 for resolving an MBMS URL according to various embodiments of the present disclosure. For example, the processes depicted in fig. 6 and 7 may be performed by server 200 in fig. 2 or client device 300 in fig. 3.

In operation 605, the UE 601 parses an MBMS URL with the name server 602. The UE 601 requests content from the server. For example, the user selects a video to be viewed on the client device 300, and the client device 300 sends a request for the video to the server 200. The server 200 receives the request and determines the need for the video. When the request for video is greater than the threshold, the server 200 determines a high demand for video, and when the request for video is less than the threshold, the server 200 determines a low demand for video. The threshold may be determined by the capacity of the server, a predetermined number of requests, etc. The demand for video may also be based on historical data of previous videos in the same series, with similar creators, etc.

In operation 610, the name server 602 transmits the MBMS description to the UE 601 or redirects the UE 601 to an HTTP URL. When the content is in high demand, the server 200 sends an MBMS delivery description to the client device 300. When server 200 determines that demand for content is low, server 200 redirects client device 300 with an HTTP URL. The MBMS transmission description includes information for accessing content from the BM-SC according to the API. When the file transfer API provides an MBMS transfer description, the received MBMS transfer description includes a broadcast file with a time frame when the file will be available to the UE 601. When the DASH API provides a delivery description, the received MBMS delivery description includes an object stream object having rules for an initialization segment of the content and for a segment matching the content. When the socket API provides the MBMS transfer description, the received MBMS transfer description includes a socket object having a session description protocol that contains a particular multicast destination. In operation 615, the UE 601 joins the MBMS session.

In operation 620, the UE 601 receives resources via MBMS from the BM-SC 603. The client device 300 receives resources from a source through the BM-SC. Resources generate data through the BM-SC, not the BM-SC.

In operation 705, the UE 701 requests an HTTP URL from the proxy server 702. The client device 300 requests content from the server 200. Server 200 determines whether MBMS is available for the content requested by client device 300. When server 200 determines that MBMS is not available, server 200 transmits an HTTP URL (not shown) for the client device to receive the content.

In operation 710, the proxy server 702 redirects the UE 701 to the MBMS URL. When server 200 determines that the MBMS is available, server 200 redirects client device 300 to the MBMS URL.

In operation 715, the UE 701 parses the MBMS URL with the name server 703. The client device 300 transmits the MBMS URL to the server 200. Server 200 determines the MBMS transmission description based on the MBMS URL.

In operation 720, the name server 703 transmits the MBMS description to the UE 701. The server 200 sends an MBMS transmission description for receiving the content to the client device 300. The MBMS transmission description includes information for accessing content from the BM-SC according to the API. When the file transfer API provides an MBMS transfer description, the received MBMS transfer description includes a broadcast file with a time frame when the file will be available to the UE 601. When the DASH API provides a delivery description, the received MBMS delivery description includes an object stream object having rules for an initialization segment of the content and for a segment matching the content. When the socket API provides the MBMS transfer description, the received MBMS transfer description includes a socket object having a session description protocol that contains a particular multicast destination. In operation 725, the UE 701 joins the MBMS session.

In operation 730, the UE 701 receives resources from the BM-SC 704 via the MBMS. The client device 300 receives resources from a source through the BM-SC. Resources generate data through the BM-SC, not the BM-SC.

In this specification, an MBMS URI scheme (scheme) is defined to simplify access to resources and streams that are delivered via MBMS or that may be available via MBMS. The UE 601 registers the MBMS middleware as an MBMS protocol processor in order to receive all resource requests using the MBMS URI scheme.

The "MBMS" URI has the following ABNF syntax:

scheme＝“mbms”“：”host[“：”port]“/”path

the < host > and < port > are specified in RFC 3986.

The "MBMS" URI scheme is used to reference resources or data streams that can be transported via MBMS. The MBMS URI should be parsed by the MBMS protocol processor using the procedures defined in fig. 6 and 7. If the resource or stream is not transmitted via MBMS, the UE 601 is redirected to a unicast transmission alternative.

The address resolution process includes the following steps:

the MBMS protocol processor is started using the received MBMS URL. The MBMS protocol processor sends a POST request to a preconfigured MBMS Address Resolution Server (ARS) using the MBMS URL as a value with NVP named "URL". The MBMS ARS responds with an MBMS metadata envelope. Alternatively, the MBMS ARS redirects the UE 601 to a unicast location of the requested resource.

The mapping between MBMS URL and FLUTE URL is implicit (i.e. MBMS scheme is replaced by http scheme) if the URL refers to a single resource, or it can be explicitly provided as part of the address resolution response. Further, the following indication of the ARS to the client may also be included as part of the response: other related resources will also be available via MBMS. The SDP should carry the transport information provided at UTC time. In addition, a schedule metadata fragment may be provided to specify the transmission time of a particular resource.

The file transfer API defines an API that provides client functions for requesting and receiving files via MBMS. The API defines a BroadcastFile object that provides a function for requesting resources, a function for receiving events regarding the status of a requested file, and a function for accessing a file transferred via MBMS.

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

it parses the MBMS URL and decides whether to transmit via unicast or broadcast. If the transfer is done via unicast, the response should contain a redirect to a unicast address. If the transmission is done via broadcast, the response should contain an indication of the time frame when the file is available at the UE 601. If the file has been received, the response should contain a URL to the local location of the file on the UE 601.

BroadcastFile defines the following events:

while file reception is in progress, a progress event (progress event) occurs. A partial event occurs when file reception is suspended and partial file content is available. The received byte range is provided to the application. A receive event occurs when a requested file is fully received and ready to be crawled. A flush event occurs when a requested file is scheduled to be removed from the local cache at the indicated time.

The DASH API defines an API that provides client functionality for accessing the content of a representation of a DASH presentation via MBMS. ObjectFlow objects are defined by the DASH API to retrieve a set of related files. ObjectFlow provides a startup method to get the URL of the initialized segment of the representation of interest and the rules for matching the segment of the representation. The rule may be a RepresentationID, a URL template, or a base URL.

ObjectFlow defines the following events:

when an object of the object stream is received, a receive event occurs. The first object received should be the start segment. When a partial object of the object stream is received, a partial event occurs. A leaving event (one event) occurs when MBMS reception is no longer available and unicast reception should be used instead.

A simple (play) Socket API (Socket API) defines an API that provides client functionality for accessing UDP datagram streams transmitted via MBMS. The socket object is defined by the socket API for opening and receiving UDP datagrams sent to a particular multicast destination address. The socket API provides a parsing function that takes the MBMS URL as an argument and returns the SDP of the session. The socket API provides a connection function with the multicast destination address and UDP port as arguments. The socket API provides a receiving function for receiving UDP datagram payloads received via MBMS. The packets are forwarded to the application in the same order in which they were received. The socket API also defines the following events:

a ready event occurs when a recipient is notified that one or more packets are ready to be received. An elapsed event occurs when the recipient is notified that MBMS reception is no longer available.

Although fig. 6 and 7 show examples of

flowcharts

600 and 700, respectively, for resolving an MBMS URL, various changes may be made to fig. 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. 8 illustrates example MBMS framing for a bearer delivery method 800 according to various embodiments of the present disclosure. Fig. 9 illustrates an example MBMS framing header 900 according to various embodiments of the present disclosure. The MBMS framing for the bearer transport method 800 shown in fig. 8 and the embodiment for the MBMS framing header 900 shown in fig. 9 are for illustration only. Fig. 8 and 9 do not limit the scope of the present disclosure to any particular implementation of an electronic device.

Configurable framing protocols, FEC frameworks, and buffering models are disclosed to adjust transmission quality based on delay and error requirements of the service. The MBMS framing protocol 910 is defined to encapsulate the user plane UDP packet 905 to provide MBMS specific functionality. The MBMS framing protocol 910 allows addressing UDP datagrams and detecting lost packets. If FEC is used, FEC repair data is transmitted via a separate media session.

The source packet is modified to include a packet sequence number 915 immediately following the UDP header. After MBMS framing is performed, the UDP checksum should be recalculated 920. The SDP for carrying the delivery method is provided by the content source at the time of content ingestion and is transparent to the BM-SC 603. The SDP is provided directly to the MBMS client by an application to the UE 601. SDP contains at least the following SDP parameters: destination IP address and port number, protocol ID for each media session, Temporary Mobile Group Identity (TMGI) for MBMS bearer, maximum delay tolerance attribute, and requested QoE report as media level attributes defined in section 8.3.2.1.

The "maximum allowed delay" is a media level SDP attribute that informs the recipient of the maximum allowed delay from the time a UDP datagram is received until the UDP datagram is delivered to the receiving application. This time sets an upper limit on the time it takes for any operation, such as FEC decoding. This value is expressed in milliseconds.

The identity of the MBMS framing protocol is provided as part of the protocol ID. For example, it may be UDP/MBMS/RTP via RTP traffic carried by the MBMS framing protocol and UDP.

In certain embodiments of the present disclosure, MBMS framing may be accomplished 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 detected by a gap in the MBMS framing packet sequence number. This metric is only applicable to the bearer transport method.

Another metric, UDP _ Datagram _ Jitter, provides a measured delay Jitter, e.g., measured as a deviation from the average transmission delay. To get this measure the framing protocol must have a transmission time stamp set by the BM-SC when sending the UDP datagram.

Although the present disclosure has been described with respect to exemplary embodiments, various changes and modifications may be suggested to one skilled in the art. It is intended that the present disclosure encompass such changes and modifications as fall within the scope of the appended claims.

The description in this application should not be taken as implying that any particular element, step, or function is an essential element that must be included in the claim scope. The scope of patented subject matter is defined only by the claims. Furthermore, the claims are not intended to refer to paragraph 112(f) of 35u.s.c. unless the exact word "means for …" is followed by a word separator.

Claims

1. A method for flexible broadcast services via multimedia broadcast/multicast service (MBMS), the method comprising:

sending a request to a server for a location of content;

receiving an MBMS delivery description for a location of the content if MBMS is available for the content and joining a session of an MBMS carrying the content based on the MBMS delivery description; and

receiving a non-MBMS Uniform Resource Locator (URL) of the content if MBMS is not available for the content,

wherein the MBMS delivery description comprises information for accessing content from a broadcast multicast service center (BM-SC),

wherein the information is determined based on a type of an Application Programming Interface (API) used to provide the MBMS delivery description, an

Wherein the type of API includes at least one of a file delivery API, a dynamic adaptive streaming over hypertext protocol (DASH) API, or a socket API.

2. The method of claim 1, wherein the file delivery API is configured to receive the requested content from the MBMS client.

3. The method of claim 1, wherein the DASH API is to receive one or more object streams, each object stream comprising one or more objects of the same object stream corresponding to the selected DASH representation, and wherein each of the one or more objects corresponds to a DASH segment.

4. The method of claim 1, wherein receiving an MBMS transmission description comprises: a socket API is used to receive multicast IP packets of the multicast stream carrying the requested content and an MBMS session description is passed to the MBMS client to trigger reception of the multicast stream using the socket API.

5. The method of claim 1, wherein receiving the MBMS transmission description of the location of the content comprises: a Forward Error Correction (FEC) framework is used to receive resources for content via an MBMS session.

6. The method of claim 1, wherein sending the request for the location of the content comprises: an MBMS URL is sent to the server for the server to determine whether the MBMS is available.

7. The method of claim 1, wherein,

sending the request for the location of the content includes: sending an HTTP URL to a server for the server to determine whether an MBMS URL for the content is available for parsing, and

after the MBMS URL is parsed, an MBMS transmission description for the content is received.

8. An apparatus, comprising:

a memory configured to store instructions; and

one or more processors operatively coupled to the memory, the one or more processors configured to execute the instructions to:

sending a request to a server for a location of content;

9. A server, comprising:

a memory configured to store instructions; and

receiving a request for a location of content from a client device;

determining whether a Multimedia Broadcast Multicast Service (MBMS) is available for the content;

if an MBMS is available for the content, sending an MBMS delivery description for the location of the content to enable the client device to join a session of the MBMS carrying the content; and

if the MBMS is not available for the content, sending an indication that the content is not available via MBMS,

wherein the MBMS delivery description comprises information for accessing the content from a broadcast multicast service center (BM-SC),

10. The server of claim 9, wherein the one or more processors are configured to determine whether MBMS is available for the content based on a demand for content and a threshold.

11. The server of claim 9, wherein the MBMS delivery description comprises a method for delivering the content via a passing BM-SC.

12. The server of claim 9, wherein the one or more processors are further configured to use a Forward Error Correction (FEC) framework to transmit resources for the content via an MBMS session.