WO2013181191A1 - Systems and methods for supporting cooperative streaming for multimedia multicast - Google Patents

Systems and methods for supporting cooperative streaming for multimedia multicast

Info

Publication number
WO2013181191A1
WO2013181191A1 PCT/US2013/042993 US2013042993W WO2013181191A1 WO 2013181191 A1 WO2013181191 A1 WO 2013181191A1 US 2013042993 W US2013042993 W US 2013042993W WO 2013181191 A1 WO2013181191 A1 WO 2013181191A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
network
gw
gateway
stream
example
Prior art date
Application number
PCT/US2013/042993
Other languages
French (fr)
Inventor
Osama Lotfallah
Hang Liu
Original Assignee
Interdigital Patent Holdings, Inc.
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

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/60Media handling, encoding, streaming or conversion
    • H04L65/601Media manipulation, adaptation or conversion
    • H04L65/605Media manipulation, adaptation or conversion intermediate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/40Services or applications
    • H04L65/4007Services involving a main real-time session and one or more additional parallel sessions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/80QoS aspects

Abstract

A system and method for cooperatively delivering a television (TV) broadcast is described. A broadcast and multicast - service center (BM-SC) (210) may split a compressed video stream associated with the TV broadcast into a plurality of compressed video streams. A first, second and third data gateway may receive a first, second and third one of the compressed video streams, respectively. A wireless transmit/receive unit (WTRU) (205) may use a service descriptor to register with the data gateways and receive the first, second and third video streams. The first data gateway may be a multimedia broadcast multicast service gateway (MBMS-GW) (215), the second data gateway may be a packet data network gateway (PDN-GW) (220), and the third data gateway may be a wireless local area network gateway (WLAN-GW) (225).

Description

SYSTEMS AND METHODS FOR SUPPORTING COOPERATIVE STREAMING FOR MULTIMEDIA MULTICAST

BACKGROUND

[0001] Enjoying the multimedia experience over wireless devices such as smart phones and/or consumer devices is a growing demand. For example, currently many wireless devices may provide mobile or wireless streaming to users. To provide mobile or wireless streaming, content providers may transmit multimedia content including services such as news, software updates, and multimedia streaming of live events or scheduled material to such wireless devices using broadcast or multicast channels to wireless devices using broadcast or multicast channels. To deliver such multimedia content and services, codecs, protocols, and/or other service specifications may be used. For example, the multimedia content may be compressed using one or more video coding and protocol techniques such as layer video coding (LVC) including, for example, Internet TV broadcasting protocols such as Octoshape, Zatto, or other peer-to-peer (P2P) live TV protocols, scalable video coding (SVC), multiple descriptions coding (MDC), broadcasting via forward error correction (FEC) coding, and the like and/or streamed via Multimedia Broadcast Multicast Service (MBMS), evolved MBMS, and the like such that the multimedia content may be multicast, unicast, and the like. Unfortunately, current mobile or wireless streaming techniques including the coding and/or streaming protocols used thereby may cause variability in latency and/or buffering, which may hinder the multimedia content from being displayed on the wireless device, when, for example, the wireless device may move from a region with one coding or streaming protocol such as MBMS to a region that may not support or use that particular coding or streaming protocol. Additionally, current multimedia content providers do not exploit multi-path diversity that may be used for multicast and/or unicast streaming protocols to generate a more reliable mobile experience for users of wireless devices. SUMMARY

[0002] Systems, methods, and/or techniques may be described for cooperatively delivering a television (TV) broadcast. In one architecture, a broadcast and multicast - service center (BM- SC) may split a compressed video stream associated with the TV broadcast into a plurality of compressed video streams. A first data gateway may receive a first one of the compressed video streams, a second data gateway may receive a second one of the compressed video streams, and a third data gateway may receive a third one of the compressed video stream. A wireless transmit/receive unit (WTRU) or user equipment (UE) may use a service descriptor to register with the data gateways and receive the first, second and third video streams. The first data gateway may be a multimedia broadcast multicast service gateway (MBMS-GW), the second data gateway may be a packet data network gateway (PDN-GW), and the third data gateway may be a wireless local area network gateway (WLAN-GW).

[0003] The Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, not is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to the limitations that solve one or more disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] A more detailed understanding of the embodiments disclosed herein may be had from the following description, given by way of example in conjunction with the accompanying drawings.

[0005] FIG. 1A depicts a diagram of an example communications system in which one or more disclosed embodiments may be implemented.

[0006] FIG. 1B depicts a system diagram of an example wireless transmit and/or receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A.

[0007] FIG. 1C depicts a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.

[0008] FIG. 1D depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.

[0009] FIG. 1E depicts a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A. [0010] FIGs. 2A-2B show architectures for a wireless transmit/receive unit (WTRU) and a network cooperative television (TV) broadcast for an evolved packet core (EPC);

[0011] FIG. 3 shows an architecture for a network cooperative TV broadcast for an EPC;

[0012] FIG. 4 shows an architecture for a WTRU, a network and content provider cooperative TV broadcast for an EPC;

[0013] FIG. 5 shows an architecture for a WTRU and a network cooperative peer-to-peer (P2P) TV broadcast for an EPC;

[0014] FIG. 6 shows a sample multimedia broadcast multicast service (MBMS) service descriptor with an accessGateway pointing to a wireless local area network (WLAN) within an accessGroup attribute;

[0015] FIG. 7 shows a sample MBMS service descriptor with an associatedUserGroup used for identifying a cooperative group between WTRUs;

[0016] FIG. 8 is a flow diagram of offloading third generation partnership (3GPP) MBMS services to WLAN networks;

[0017] FIG. 9 shows message sequences for offloading 3GPP MBMS to a WLAN network; and

[0018] FIG. 10 depicts a flow diagram of offloading 3GPP MBMS to a cloud. DETAILED DESCRIPTION

[0019] A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

[0020] Systems, methods, and/or techniques for cooperatively delivering a television (TV) broadcast may be provided as described herein. For example, in an embodiment, a broadcast and multicast - service center (BM-SC) may split a compressed video stream associated with the TV broadcast into a plurality of compressed video streams that may be provided on different paths. A first data gateway may receive a first one of the compressed video streams on a first path, a second data gateway may receive a second one of the compressed video streams on a second path, and a third data gateway may receive a third one of the compressed video stream on a third. In example embodiments, the first data gateway may be a multimedia broadcast multicast service gateway (MBMS-GW), the second data gateway may be a packet data network gateway (PDN- GW), and the third data gateway may be a wireless local area network gateway (WLAN-GW). A wireless device such as a WTRU or UE may then receive the data streams from the respective gateways such as the first, second, and third gateways. To receive such streams, the wireless device may use a service descriptor to register with the data gateways. As such, in example embodiments, LVC, SVC, and the like may be provided and/or used such that the multimedia content (e.g. the streams thereof) may be different for each path (e.g. may be a different version of the multimedia content, may have a different quality such as standard definition or high definition of the multimedia content, may have a portion of the multimedia content, and the like) rather than the same on each path.

[0021] FIG. 1A depicts a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.

[0022] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, and/or 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, and/or 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0023] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and/or 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112. By way of example, the base stations 114a and/or 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0024] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0025] The base stations 114a and/or 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, and/or 102d over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 115/116/117 may be established using any suitable radio access technology (RAT).

[0026] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, and/or 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA).

WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0027] In another embodiment, the base station 114a and the WTRUs 102a, 102b, and/or 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E- UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).

[0028] In other embodiments, the base station 114a and the WTRUs 102a, 102b, and/or 102c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA20001X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0029] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular- based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.

[0030] The RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, and/or 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network

106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0031] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, and/or 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

[0032] Some or all of the WTRUs 102a, 102b, 102c, and/or 102d in the communications system 100 may include multi-mode capabilities, i.e., the WTRUs 102a, 102b, 102c, and/or 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0033] FIG. 1B depicts a system diagram of an example WTRU 102. As shown in FIG. 1B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub- combination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. 1B and described herein.

[0034] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller,

Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the

transmit/receive element 122. While FIG. 1B depicts the processor 118 and the transceiver 120 as separate components, it may be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0035] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115/116/117. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0036] In addition, although the transmit/receive element 122 is depicted in FIG. 1B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.

[0037] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0038] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0039] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like. [0040] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0041] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0042] FIG. 1C depicts a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 1C, the RAN 103 may include Node-Bs 140a, 140b, and/or 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 115. The Node-Bs 140a, 140b, and/or 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a and/or 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0043] As shown in FIG. 1C, the Node-Bs 140a and/or 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC142b. The Node-Bs 140a, 140b, and/or 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an Iur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node- Bs 140a, 140b, and/or 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like. [0044] The core network 106 shown in FIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0045] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices.

[0046] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.

[0047] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0048] FIG. 1D depicts a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0049] The RAN 104 may include eNode-Bs 160a, 160b, and/or 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, and/or 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, and/or 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0050] Each of the eNode-Bs 160a, 160b, and/or 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. 1D, the eNode-Bs 160a, 160b, and/or 160c may communicate with one another over an X2 interface. [0051] The core network 107 shown in FIG. 1D may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0052] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and/or 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and/or 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and/or 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0053] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and/or 160c in the RAN 104 via the S1 interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, and/or 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and/or 102c, managing and storing contexts of the WTRUs 102a, 102b, and/or 102c, and the like.

[0054] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and IP-enabled devices.

[0055] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and/or 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0056] FIG. 1E depicts a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and/or 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, and/or 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0057] As shown in FIG. 1E, the RAN 105 may include base stations 180a, 180b, and/or 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, and/or 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and/or 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, and/or 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, and/or 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0058] The air interface 117 between the WTRUs 102a, 102b, and/or 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and/or 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, and/or 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and/or mobility management.

[0059] The communication link between each of the base stations 180a, 180b, and/or 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, and/or 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, and/or 102c.

[0060] As shown in FIG. 1E, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0061] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, and/or 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and/or 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and/or 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and/or 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, and/or 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0062] Although not shown in FIG. 1E, it should, may, and/or will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, and/or 102c between the RAN 105 and the other ASNs. The

communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0063] As described herein, providing a multimedia experience such as mobile or wireless streaming over smart phones and consumer devices is a growing demand that may be driving innovations in protocol design and enhanced video streaming architectures. To provide such multimedia experience and/or wireless streaming, the multimedia content may be transmitted to several receivers using Broadcast or multicast channels. For example, to deliver services such as news, software updates (e.g. via download); multimedia streaming of live events or scheduled material; and/or any other multimedia content, codecs, protocols, and/or service specifications may be provided. For example, in 3GPP, multimedia broadcast multicast service (MBMS) may be used to stream multimedia content. Additionally, other video coding and protocol techniques may be provided and/or used for broadcasting or streaming such as over the top TV broadcasting as described herein. [0064] For example, in an embodiment, to provide mobile or wireless streaming or broadcasts to devices such as WTRUs and/or UEs, layered video coding (LVC) may be used. In LVC, Internet TV broadcasting may use multiple content severs that may co-operative to provide higher quality level of services. In particular, Octoshape that may be used, for example, by CNN for live Internet broadcast and/or Zattoo, which may be a production live streaming provider in Europe, may be examples of such Internet TV broadcasting services. In an example embodiment, such services may be categorized as peer to peer live TV. Additionally, according to embodiments, such services such as Octoshape and Zattoo may use the Reed–Solomon (RS) codes for forward error correction (FEC). The RS code may be a systematic code of the n packets sent per segment where k packets (e.g. k < n packets) carry the live stream data and the remainder (e.g. n-k packets) may carry the redundant data. In an embodiment, once a client or device has received k packets (e.g. per segment), the client or device may reconstruct the remaining n-k packets. Additionally, the original broadcasting server may send the video stream to several dedicated receivers (or volunteered clients/peers) that may co-operate to generate n independent channels.

[0065] Additionally, scalable video coding (SVC) may be used to provide mobile or wireless streaming to devices such as WTRUs and/or UEs. SVD may decompose encoded video streams into multiple dependent layers in the spatial domain, temporal domain, and/or the quality domain. Additionally, SVC may enable the encoding of a high-quality video bitstream that may include one or more subset bitstreams (e.g. or into layers). For example, the bitstream may be encoded into a first layer and subsequent layers. The first may be a base layer that may typically have a small bit rate and may use a reliable transport protocol or more FEC codes. Subsequent layers may be enhancement layers, which require an increasing amount of bit rate and decreasing level of reliability.

[0066] According to an additional embodiment, multiple descriptions coding (MDC) may be used to provide mobile or wireless streaming. MDC may be a coding technique that may decompose the video stream into number of levels (e.g. equally important levels). For example, in MDC, 3D stereoscopic video coding may be provided by splitting the whole video frames into left frames and right frames. For other video applications, the video frames may be split into odd line frames and even line frames. In such an embodiment, one or more (e.g. two) independent single layer video codecs may be used with little overhead at the receiver or WTRU to reconstruct the whole video stream. MDC streams may be used, for example, where multiple independent paths may be available between the receiver and the video streaming server. [0067] As described herein, LVC such as SVC, MDC or TV broadcasting using FEC coding may use multiple data paths between the UE and the media streaming servers. Additionally, existing wireless networks (e.g. such as the communication networks described in FIGs. 1A and 1C-1E) may enable UEs (e.g. such as the WTRU described in FIG. 1B) to access IP networks using several packet data gateways (PDN). For example, non-seamless WLAN offloading may be provided to such networks and UEs. The non-seamless WLAN may enable direct IP connectivity with the UE using WLAN interface in addition to 3GPP IP connectivity via the 3GPP network or other wireless network. Although multiple paths for receiving content may be available, currently, multimedia service providers do not exploit such multi-path diversity at the UE or WTRU and, as such,, the multimedia content delivered to the UE may have variability in latency and/or buffering (e.g. when the UE moves from one region to another region that may support different protocols, codecs, and the like).

[0068] As such, systems and/or methods may be provided that may support and/or use such multi-path diversity. For example, as described herein, the multi-path diversity at the UE may be used for multicast and/or unicast streaming protocols to generate more reliable mobile or wireless streaming (e.g. TV) experience for the UE.

[0069] In an embodiment, to help provide a rich multimedia experience using the availability of multiple data gateways (GWs), (e.g. a MBMS-GW, a packet data network (PDN) GW or a WLAN-GW) at the UEs, the existing mobile TV broadcast architecture may be modified. For example, the multimedia content (e.g. the original multimedia content that may be broadcast by a content provider) may be split into multiple streams of equal or unequal importance at the broadcasting center or original content server (e.g. using SVC, MDC or FEC coding) and such streams may be provided on different paths to the UE as described herein.

[0070] Additionally, in an embodiment, a new access gateway such a WLAN-GW or a WiMax-GW for supporting unicast or multicast transport techniques may be provided and/or added to the existing architecture. In such an embodiment, the access gateway may be used by WTRU access managers or multimedia service providers to enable smart offloading techniques and avoid expensive deep packet inspection techniques.

[0071] Additionally, a group of WTRUs may be used for a complimentary service as described herein to facilitate with variability of the multimedia content and/or different protocols. For example, WTRUs may create a stream synchronization group that may enable them to synchronize their playout experience. Additionally, a group of WTRUs may be created to exchange missing or corrupted packets during the multimedia broadcast (e.g. a TV broadcast). For example, in a wireless domain, a cooperative video streaming technique may allow WTRU users to create a special group between themselves to exchange missing packets of the broadcast contents via network links (e.g. via 3GPP links). Such a group may be created over one of the interfaces such as the WLAN interface to offload multimedia broadcast multicast service (MBMS) traffic on third generation (3G) networks. Additionally, an FEC may be used rather than Raptor codes on MBMS that may be based on the WTRU cooperation (e.g. the groupings of the WTRUs), larger performance gains may be achieved by increasing the number of WTRU cooperating devices, and/or SVC may provide better quality of service (QoS) (e.g. measured as a peak signal-to-noise ratio (PSNR)) compared to non-scalable streaming of broadcast materials over 3G networks with such groupings and/or WTRU cooperation.

[0072] To support the modification of the architectures as described herein (e.g. splitting the multimedia content into different streams, a new access gateway, a complimentary service via groups of WTRUs), service description extensions may be used and/or modified as described herein. For example, in an embodiment, a service description extension may be provided to enable time-shifted video material to be recoded into a cloud service, another service descriptor may be provided to enable the WTRU to register to receive the streams via the different paths, and the like.

[0073] FIG. 2A illustrates an example embodiment of an architecture 200a for an evolved packet core (EPC) that may be used to provide a broadcast (e.g. a network cooperative TV broadcast) to a UE or WTRU 205 such as the WTRU of FIG. 1B. As shown in FIG. 2A, the architecture 200a may include a broadcast and multicast-service center (BM-SC) 210.

According to an embodiment, the BM-SC 210 may receive multimedia content such as an original compressed video stream (e.g. which may be a single layer H.264 stream) and may split such content into one or more compressed streams (e.g. video streams) such as a first stream s1, a second stream s2, and/or a third stream s3 of equal or different importance level. In one example embodiment, SVC or MDC may be used by the BM-SC 210 to split the multimedia content into streams of different qualities, having different parts, portions, or pieces of the content, of different frequencies, of different technologies, and the like. For example, in an embodiment, the BM-SC 210 may use a video compression scheme such as SVC to split and/or render the multimedia content into the streams s1, s2, and s3 where each of the streams may be different qualities (e.g. stream s1 may be a basic quality or standard definition (e.g. 480i) of the multimedia content, the stream s2 may be an enhanced quality such as a medium definition (e.g. 720p or other suitable definition between, for example, standard and high definition), and the stream s3 may be a high quality or high definition of the multimedia content). Furthermore, according to an embodiment, at the BM-SC 210 may use a video compression scheme such as MDC to apply stereoscopic temporal interleaving by splitting the multimedia content into such that even frames may carry left camera images (e.g. the s1 stream as shown) and odd frames may carry right camera images (e.g. the s2 stream as shown).

[0074] As shown, the compressed streams (e.g. s1, s2 and s3) may be sent to the UE via on different paths and via different networks such as a core network provided by a communication system such as communication system 100 and/or a WLAN network. For example, the streams s1, s2, and s3 may be sent by the BM-SC 210 to different data gateways such as a MBMS gateway (MBMS-GW) 215, a packet data network gateway (PDN-GW 220), and/or a wireless local access network gateway (WLAN-GW) 225. Such gateways may cover different frequency ranges and/or may use different access technologies such as a unicast or multicast transport.

[0075] For example, as shown in FIG. 2A, the BM-SC 210 may send the stream s1 to the MBMS-GW 215 on a first interface (e.g. that may be defined by 3GPP or another standard or protocol) such as a SGmb and/or SGi-mb. Additionally, the BM-SC 201 may send the stream s2 to the PDN-GW 220 on a second interface (e.g. that may be the same or different than the first interface and also may be defined by 3GPP or another network standard or protocol). As such, in an example embodiment, the first or second interface may be used without modification to connect the BM-SC 210 and the PDN-GW 220 and/or the BM-SC 210 and the MBMS-GW 215. According to an embodiment, the BM-SC 201 may send the stream s3 to the WLAN-GW 225 via a third interface. The third interface between a WLAN-GW 225 and the BM-SC 210 may include and/or use IPsec tunneling protocols.

[0076] The MBMS-GW 215, PDN-GW 220, and WLAN-GW 225 may further cooperate and communicate with the UE 205 to deliver the broadcast (e.g. the TV broadcast) via the air interfaces associated therewith. For example, the UE 205 may receive one or more compressed streams depending on the available bandwidth and/or a desired quality of experience (QoE) level from the gateways. In an embodiment, as shown in FIG. 2A, the UE 205 may receive the stream s1 from the MBMS-GW 215 and the stream s2 from the PDN-GW 220 (e.g. via multiple wireless broadcasts over UTRAN, E-TRAN, 3GPP, and the like). The UE 205 may further receive the stream s3 from the WLAN-GW 225 (e.g. via a wireless broadcast over an access point). As such, the UE 205 may receive the streams over multiple over-the-air interfaces at the same time (e.g. simultaneously).

[0077] According to an example embodiment, to receive the respective streams, the WTRU 205 may cooperate by registering to receive the streams from the data gateways at the same time (e.g. simultaneously). For example, the WTRU 205 may register with the MBMS-GW 215, the PDN-GW 220 and the WLAN-GW 225 to receive the stream s1 over multicast such as IP multicast, the stream s2 over transmission control protocol (TCP)/user datagram protocol (UDP) unicast and the stream s3 over TCP/UDP unicast respectively. Additionally, in an embodiment (not shown), the UE 205 may have an access to three MBMS-GWs such that the streams s1, s2 and s3 streams may be received through three different MBMS-GWs, respectively, in a core network.

[0078] To register with the gateways such as the MBMS-GW 215, the PDN-GW 220, and the WLAN-GW 225 and, as such, receive the broadcasted multimedia content and the streams associated therewith, the UE 205 may use a service descriptor such as a new service descriptor or an existing service descriptor that may be modified to connect and/or signal to the appropriate gateways characteristics of the UE and/or to attach the UE to the respective gateways to receive the multimedia contend and the streams associated therewith. For example, in an embodiment, one or more existing service descriptors may be extended (e.g. may include additional tags or information, for example, as described herein below) to include enough information to enable the UE 205 to receive the streams s1, s2 and s3 from the respective packet gateways (or content servers, for example, as described herein below).

[0079] As described herein, the architecture 200a may enable a multicast and unicast transport to be combined for the multimedia content (e.g. a TV broadcast stream), for example, using automatic IP multicast tunneling (AMT). For example, the BM-SC 210 may include an automatic IP multicast tunneling (AMT) relay 230 and/or the WLAN-GW 225 may include an AMT gateway (AMT-GW) 235. According to an example embodiment, the AMT relay 230 may be used within a multicast IP network to encapsulate multicast streams of the multimedia content into unicast streams that may be received by the AMT-GW 235 within the WLAN IP network. As such, the BM-the AMT relay 230 and the AMT-GW 235 may interact with each other to connect multicast and unicast transports. In such an embodiment (e.g. as shown, in FIG. 2A), the BM-SC 210 may receive the multimedia content from a content provider 240 and may divide or split it into the streams s1, s2, s3 as described herein. If the BM-SC 210 may use IP multicast to distribute the s3 stream to a WLAN IP network, the AMT relay 230 and an AMT-GW 235 may be used as intermediaries such that the stream s3 may be provided or sent from the BM-SC 210 to the AMT relay 230, from the AMT relay 230 to the AMT GW 235 where the AMT relay 230 and the AMT GW 235 may interact with each other to connect the stream s3 from multicast to unicast (e.g. which may be used by the WLAN access network), and the AMT GW 235 may subsequently send the stream s3 (e.g. which may now be in unicast) to the WLAN-GW 225 and then onto the UE 205 as described above. After receiving the streams (e.g. s1, s2, and s3), the UE 205 may combine the streams and then render the combined streams to display or output the multimedia content on the UE 205.

[0080] Additionally, in an embodiment, an architecture such as the architecture 200a shown in FIG. 2A may enable content to be delivered to a UE through WLAN access points using a MBMS such as when the UE may be streaming a multimedia service such as mobileTV service while roaming in hotspot area such as an airport vicinity, for example, as shown in FIG. 2B. For example, the architecture 200a shown in FIG. 2A may be modified to provide a different flow of streams which may enable a MBMS to use WLAN access points in combination with network components as shown by an architecture 200b in FIG. 2B. In such an embodiment shown in FIG. 2B, the BM-SC 210 may receive the content and may provide two streams (e.g. a first stream s1 and a second stream s2) directly to the MBMS-GW 215. The streams may be split as described herein by the BM-SC 210 and/or the content provider 240. The MBMS-GW215 may then send or deliver one of the streams (e.g. a first stream s1) to the UE or WTRU 205 via the 3GPP or other communications network. The MBMS-GW 215 may send another stream (e.g. a second stream s2) to a PDN such as an ePDN 250 or other network component in the core network, which may then send the stream to the UE 205 via a WiFi access point in

communication with the PDN. Additionally, in such an embodiment, one of the streams such as the first stream may be a base layer quality with a low bit rate to, for example, avoid overloading the communication network links such as the 3GPP links while the second stream may be an enhanced layer quality with higher bit rate. Moreover, the communication networks may co- operate with WLAN access provider to completely transfer the multicast video service to WLAN access point to provide the UE 205 with an enhanced version of the content.

[0081] FIG. 3 illustrates an example embodiment of an architecture 300 for an EPC that may be used to provide a broadcast (e.g. a network cooperative TV broadcast) to a UE or WTRU 305 such as the WTRU of FIG. 1B. As shown in FIG. 3 (and similar to FIG. 2), the architecture 300 may include a BM-SC 310. The BM-SC 310 may receive multimedia content from a content provider 340 and may split the original compressed video stream (e.g. which may be a single layer H.264 stream) into one or more compressed video streams such as a first stream s1, a second stream s2 and a third stream s3 that may be received by the UE 305 based on an available bandwidth and a desired QoE level.

[0082] As shown in FIG. 3 and described herein, the streams may be sent from the BM-SC 310 to different data gateways (e.g. the stream s1 may be sent to a WLAN-GW 325, the stream s2 may be sent to a MMBM-GW 315, and the stream s3 may be sent to a PDN-GW 320) and then may be sent onto the UE 305 directly and/or onto other gateways as shown. [0083] To receive the streams, in an embodiment (e.g. compared to example architecture 200a of FIG. 2A), the UE 305 may register and receive the streams from a single gateway based on criteria such as whether the gateway may be the closest in terms of network proximity, and the like. For example, rather than having a connection or interface with each of the gateways, the UE305 may attach to one of the gateways such as the WLAN-GW 325, which may be the closest in terms of network proximity, to provide a cooperative deployment that may be assisted by network operators.

[0084] As shown in FIG. 3, to receive the streams s1, s2, and s3, the UE 305 may register with and attach to the WLAN-GW 325 such that the UE 305 receive each of the streams s1, s2, and s3 from the WLAN-GW 325 such that the data traffic (e.g. associated with the multimedia content) may be offloaded to the WLAN networks. In such an embodiment, as shown in FIG. 3, the WLAN-GW 325 may receive the stream s1 from the BM-SC 310 and the streams s2 and s3 from a MBMS-GW 315 and a PDN-GW 320 respectively such that the WLAN-GW may have a direct connection with the PDN-GW 320 and the MBMS-GW 315 of the underlying network operators. As such, a cooperative interface may be established between the WLAN-GW 325, the MBMS-GW 315 and the PDN-GW 320 to deliver the multimedia content or streaming service with the support from wireless operators.

[0085] In an embodiment, the MBMS-GW 315 may use a multicast transport such as an IP multicast and the WLAN-GW 325 may use a unicast transport. In such an embodiment where the MBMS-GW 315 may use IP multicast while the WLAN network may use a unicast transport, an AMT relay 330 and AMT GW 335 at an EPC may assist in encapsulating the IP multicast into a unicast stream into the WLAN network as described herein (e.g. as described above with respect to FIG. 2).

[0086] After receiving the streams s1, s2, and s3, the WLAN-GW 325 may assemble the streams for the UE 305 and may then transmit the assembled streams to the UE 305. To assemble the s1, s2 and s3 streams on behalf of the UE 310, a service descriptor such as a new or existing service descriptor that may be modified may be provided and used by the WLAN-GW 325. For example, one or more existing service descriptors may be extended to include information that may enable the WLAN-GW 325 to receive the s1, s2 and s3 streams from the appropriate packet gateways or content servers and to assemble them into a single stream that may be a suitable protocol for the UE 305 to receive and render the multimedia content thereon.

[0087] FIG. 4 illustrates an example embodiment of an architecture 400 for an EPC that may be used to provide a broadcast (e.g. a network cooperative TV broadcast) to a UE or WTRU 405 such as the WTRU of FIG. 1B. As shown in FIG. 4, in the architecture 400, the content provider, the WLAN and/or core network, and the IP network and the components included therein (e.g. BM-SC 410a, 410b, a MBMS-GW 415, a PDN-GW 420, a WLAN-GW 425) that may participate in the multimedia streaming may cooperate to deliver an enhanced streaming service. For example, compared to the architectures 200a-b and 300 of FIGs. 2 and 3, respectively, a content provider 440 may split multimedia content such as an original video stream into one or more compressed streams such as first stream s1, second stream s2, and third stream s3 that may be coded using SVC, MDC or FEC coding. As such, the content provider 440 may perform at least a portion of the functionality of the BM-SC 210 and/or 310. For example, the content provider 440 may perform some intelligence (e.g. how to split the streams) that the BM-SC may perform in additional embodiments including sending particular streams of different qualities to different gateways (e.g. the content provider 440 may send standard or lower qualities via streams s1 and s2 and higher quality or high definition via stream s3).

[0088] At least a portion (e.g. some) of these compressed streams such as streams s1 and s2 may be sent from the content provider 440 to different BM-SCs such as BM-SC1 410a and BM- SC2410b respectively while other streams such as stream s3 may be sent directly to a WLAN- GW 425. As such, the content provider 440 may send specific streams to specific gateways or network components in the same or different networks.

[0089] Additionally, as shown in FIG. 4, the BM-SC1 410a and BM-SC2410b may further send the streams s1 and s2 to different data gateways. For example, the BM-SC1 410a may send the stream s1 received from the content provider 440 to a MBMS-GW 315 and the BM-SC2 410b may send the stream s2 from the content provider 440 to a PDN-GW 420.

[0090] The UE 405 may register and receive video streams from several data gateways at the same time. For example, the UE 405 may attach to a 3GPP network to receive the streams s1 and s2 from the MBMS-GW 415 and the PDN-GW 420 respectively and a WLAN network to receive the stream s3 from the WLAN-GW 425. As such, the WTRU 405 may register with and attach to the MBMS-GW 415, the PDN-GW 420 and the WLAN-GW 425 to receive the video streams s1, s2 and s3 respectively therefrom as described herein (e.g. as described above with respect to FIG. 2).

[0091] FIG. 5 illustrates an example embodiment of an architecture 500 and a network cooperative peer-to-peer (P2P) broadcast for an EPC that may be provided to a UE or WTRU 505 such as the WTRU of FIG. 1B. As shown in FIG. 5, the actual multimedia content may be split between various source or content providers similar, for example, to distribute P2P streaming. For example, the architecture 500 may include a first content provider 540a, a second content provider 540b, and a third content provider 540c that may separately may send streams s1, s2 and s3 of different qualities, characteristics, and the like (e.g. content provider 540a may provide video via stream s1 of the multimedia content, content provider 540b may provide audio via stream s2 of the multimedia content, and content provider 540c may provide closed captioning via stream s3 of the multimedia content) to a BM-SC1 510a, BM-SC2510b, and a WLAN-GW 525 respectively. The WTRU 505 may then receive the compressed streams s1, s2, and s3 depending on the available bandwidth and the desired QoE level, for example, as described herein (e.g. above). The BM-SC1 510a may send the stream s1 received from the first content provider 540a to a MBMS-GW 515, the BM-SC2510b may send the stream s2 received from the second content provider 540b to a PDN-GW 520, and the third content provider 540c may send the stream s3 directly to the WLAN-GW 525 such that the streams s1, s2, and s3 may be subsequently sent from the MBMS-GW 515, PDN-GW 520, and WLAN-GW 525 respectively to the UE 505 that may be registered therewith and attached thereto (e.g. as described above with respect to FIGs. 2 and 4).

[0092] As described herein, a UE or WTRU such as the UE or WTRU 205, 305, 405, and/or 505 may register with network components via a service descriptor. For example, typically, over the air TV broadcast may be advertised by service providers through emails, referral from other friends, and the like. The advertised message may carry a service description or descriptor that may be embedded in the actual message or referring to a uniform resource identifier (URI). The service descriptor may carry or include information about the video material, scheduled broadcast, access control (such as digital radio mondiale (DRM)), bandwidth requirements, transport protocols, and the like. The UE may use this data to connect and watch the desired TV broadcast. In an embodiment, a service descriptor may be defined (e.g. by 3GPP or other technologies) for MBMS applications. Additionally, Internet TV broadcasts may carry and/or define the service description or descriptor in the in-band signaling protocol using proprietary XML schema. According to an example embodiment, one or more of the service descriptors of an existing TV broadcast may further resemble a MBMS service descriptor.

[0093] As described herein, the service descriptor may be extended to provide, for example, the UE and/or other components or device with additional details about cooperative architectures (such as the architectures described above). For example, the service descriptor may be extended to include a fully descriptive URI of the media stream

http://domain_name/wireless_id/service_name/access_gw/media_descriptor where the domain_name may be a qualified domain name of the service provider, (e.g.,

www.videoprovider.com), and the wireless_id may indicate identifiers of the wireless network technology, (e.g., 3GPP, Broadband Forum (BBF), WiMax). Additionally, the service_name may be the identifier of the type of the TV broadcast, (e.g., MBMS, IPTV, P2PTV), the access_gw may be the type of access gateway, (e.g., MBMS-GW, WLAN-GW, PDN-GW), the media_descriptor may be the actual media details, (e.g. session description protocol (SDP), manifest hypertext transfer protocol (HTTP), dynamic adaptive streaming over HTTP (DASH), synchronized multimedia integration language (SMIL)).

[0094] The service descriptor may also be extended to include one or more attributes. For example, in one embodiment, the service descriptor may include an attribute to signal whether a stream may be multicast or unicast IP protocol. For example, an IP_type may be used where the IP_type may be based on the IP_version being IPv4/IPv6, unicast/multicast, or

tunneled=ON/OFF. The service descriptor may further an attribute to signal the availability of multiple data paths between sources and destinations based on cooperative broadcast being ON/OFF and the multi-path being ON/OF; an attribute to signal the type of the video codec and the number of streams that are available for reconstructing the TV broadcast (e.g. the video_codec may be SVC/MDC/FEC, the number_streams may be s1, s2, s3 and the decoding_order may provide the order of decoding sub-streams; an attribute to enable the creation of a group among the users to exchange missing packets and share the same synchronized playout experience (e.g. the user_group_id may uniquely identify the group, the user_group_reg may provide a reference to a registration URI for UEs to create/join/leave a group and/or the user_group_gw may provide a reference to the gateway that may be be used for the group communication); and the like.

[0095] FIGs. 6 and 7 illustrate example multimedia broadcast multicast service (MBMS) descriptor extensions that may be used by a UE or WTRU. As shown in FIG. 6, in one embodiment, a MBMS descriptor may be extended to provide information about multicast over a MBMS-GW and unicast over a WLAN-GW. For example, an accessGateway pointing to a wireless local area network (WLAN) within an accessGroup attribute may be provided (e.g. as shown in see the blocked off code in FIG. 6) to signal whether the MBMS-GW may be used for multicast and/or a WLAN-GW may be used for unicast.

[0096] As shown in FIG. 7, a MBMS descriptor may be extended to enable a group of UEs to be created over a gateway such as a WLAN-GW. For example, an associatedUserGroup may be provided and/or used to identify a cooperative group between UEs over a WLAN-GW.

According to an example embodiment, one or more UEs may create a cooperative group over the WLAN to, for example, exchange data, such as requesting a WTRU to send missing packets, QoE reports, control packets for synchronized playout of on-demand video clips, social interaction messages or tweets, and the like. Within the MBMS service descriptor, a new associatedUserGroup may be used for identifying the cooperative group between WTRUs (e.g. as shown in the blocked off code in FIG. 7).

[0097] According to an embodiment, by adopting these extensions to the MBMS service description, repair service may also be included as a cooperative user created service by pointing the repair server to the appropriate associatedUserGroupID. As such, repairing the missing packet of certain streaming and/or downloading delivery may be achieved using other UEs that may correctly receive the stream and/or file. In addition, the repair server may point to a peer-to- peer (P2P) tracker server such that the repairing of missing packets may be implemented using P2P streaming protocols outside MBMS multicast/broadcast resources and WLAN gateways.

[0098] As described herein, in an embodiment, a UE may offload reception of content (e.g. a TV broadcast service or other broadcast and/or content) to a WLAN-GW. For example, when cooperatively using a TV broadcast service, a UE may offload the reception of the TV broadcast service (available in wired and wireless networks) to a WLAN gateway. Such an embodiment may be used when a WTRU, which has access to a TV broadcast service (e.g. TV_Coop), may receive content using unicast or multicast over wired or wireless networks.

[0099] FIGs. 8 and 9 depict respectively a flow diagram of an example method 800 for offloading MBMS services (e.g. third generation partnership (3GPP) MBMS services) to a WLAN network and messages that may be exchanged during such an example method. In an example embodiment, the method 800 may occur or be performed when a mobility of a UE or WTRU (e.g. as described herein) may be below a certain threshold ( ) where the mobility may be calculated as a velocity of the UE. In such an embodiment, the WLAN-GW may be used to access the live streaming service instead of using expensive 3GPP resources such that the service may be offloaded.

[0100] Additionally, when offloading to a WLAN, the same IP address for the UE may or may not be maintained (i.e., seamless offloading may not be used here). Also, offloading may be implemented at the UE based on UE velocity, available access types, and TV broadcast service descriptors, (e.g., MBMS service descriptors), sent to the UE. In an embodiment, TV service extensions or descriptor extensions may be used to enable this UE based adaptation as described herein.

[0101] Offloading may be implemented at the network operator side, such as a BM-SC, MBMS-GW, PDN-GW or WLAN gateway (for network based adaptation). Collecting related data may be achieved using UE subscriptions that are retrieved from a home subscriber service (HSS). Furthermore, the BM-SC or MBMS-GW may estimate the velocity of a WTRU based on radio access layer statistics. WLAN gateways may cache as many service descriptors of scheduled TV broadcasting material as may be possible for some wireless network operators based on already established business service agreements. Additionally, in an embodiment, network operators may proactively push the scheduled TV broadcast material to some storage sub-system at the WLAN gateway to be ready for a UE that may offload from 3GPP to WLAN networks.

[0102] As shown in FIGs. 8 and 9 (e.g. which illustrates an example message flow for a UE that may offload the MBMS service from 3GPP to WLAN), a TV broadcast service starts in both wired and wireless networks (e.g. at a). The MBMS UE may receive (e.g. at 810 and 1) the service description of this broadcast using an in-bound (e.g., other dedicated MBMS bearers) or out of bound means (e.g. email, SMS, file download). Additionally, the MBMS UE may register (e.g. at 810 or 2) with an underlying BM-SC, may be activated (e.g. at 3), and may receive a MBMS data transfer from a MBMS delivery function (e.g. at 815 or 4). The WLAN offloading may be triggered by an event such as UE mobility decrease (e.g. at 5) to the level of being within the hot spot zone of a WLAN access gateway such as being mobile within the vicinity of an airport or a large hotel. When such triggering event happens, the UE may be able to activate the WLAN gateway (e.g. at 6) using service attributes. In addition, authorization and authentication messages (e.g. at 7) may be exchanged between a WLAN gateway and the BM-SC to enable such a kind of data plane transfer. AMT relays and AMT gateways may be established in the data path to allow offloading between multicast transmissions in the 3GPP network to a unicast transmission in the WLAN network. Upon the successful authorization (e.g. at 7), the data transfer may be resumed using the WLAN gateway (e.g. at 8).

[0103] Additionally, as shown in FIG. 8, a determination may be made (e.g. at the BM-SC) whether the UE velocity may be less than a threshold (e.g. at 820), whether a broadcast may be available to be used with WLAN (e.g. at 825), and/or whether the WLAN may be available (e.g. at 830). If, based on the determination, UE velocity may be less than the threshold, the broadcast may be available for a WLAN, and the WLAN may be available, the data transfer may be performed by the WLAN such that the UE receives the broadcast over WLAN (e.g. the data transfer may be transferred or offloaded form a 3GPP network resource to WLAN at 835).

Otherwise (e.g. if the velocity may be greater than the threshold, the WLAN may not be available, and/or the content may not be suitable for broadcast over WLAN), the broadcast may be maintained on, for example, the current network (e.g. 3GPP) such that the UE may continue to receive the broadcast over the current network (e.g. 3GPP) (e.g. at 840).

[0104] FIG. 10 depicts a flow diagram of an example method 1000 for offloading 3GPP MBMS to a cloud. For example, a UE or WTRU (e.g. as described herein) may use cloud storage for time-shifted TV broadcast services. Some TV broadcast services may allow a WTRU to record live programs (such as sport events) to be viewed at a later period in time. This kind of additional feature may be called time-shifted TV broadcast. As shown in FIG. 10, a TV broadcast over 3GPP MBMS may be recorded into a cloud service for a later consumption by the 3GPP UE where using WLAN access may be suitable for initiating and relaying the MBMS broadcast to cloud storage over the Internet. To provide such recording, a UE may register to receive the broadcast (e.g. at 1005), the UE may then receive the service descriptor for the broadcast (e.g. at 1010). After registering, the actual content may be broadcasted to the UE and received thereby at 1015). To time-shift, a determination may be made regarding whether a user may pause (e.g. at 1020) the content via his or her UE. If the UE does not pause the content and the UE ma still be active or may have been resumed from a sleep state (e.g. at 1025), the UE may continue to receive the content via the original network (e.g. 3GPP) (e.g. at 1030). Additionally, if the content has been paused (e.g. at 1020), a determination may be made regarding whether the cloud may be available (e.g. at 1035). If the cloud may be unavailable and the UE may be active or resumed (e.g. as described above at 1025), the UE may continue to receive the content via the original network (e.g. 3GPP). If, however, the content may be paused (e.g. at 1020) and can be recorded in the cloud (e.g. at 1035)(i.e. the cloud server may be available, may have enough storage, and the like), a cloud entry point may be joined with the content being broadcast (e.g. at 1040), cloud services may send details to the UE to receive the recorded material (e.g. at 1045), and the UE may release its attachment to the MBMS-GW (e.g. at 1050). After releasing the attachment, a determination may be made (e.g. at the UE) on whether the WLAN may be available (e.g. at 1055). If available, the UE attaches to the WLAN (e.g. at 1060) via an interface before registering with the cloud services (e.g. at 1065). If the WLAN may not be available, the UE may directly register with the cloud services (e.g. at 1065). After registering with the service, a determination may be made regarding whether a UE may be resumed or still active (e.g. at 1070) such that if the UE may be resumed or active the UE may receive the content from the cloud (e.g. at 1075). Otherwise, the content may be stored in the cloud until the UE may be resumed or activated to receive such content (e.g. at 1070)

[0105] As such, in this embodiment, the UE may release MBMS resources and attach to the WLAN-GW to initiate and relay the time shifted material. This change of access interfaces may be executed during the pause period, which results in very limited interruption to the perceived QoE at the end user. The sample message flow between MBMS WTRU and other network entities to enable such storage can follow a similar sequence to those shown in FIG. 9. [0106] Although the terms device, wireless device, UE, or WTRU may be used herein, it may and should be understood that the use of such terms may be used interchangeably and, as such, may not be distinguishable.

[0107] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer- readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

What is claimed: 1. A method for cooperatively delivering a broadcast, the method comprising: receiving compressed multimedia content associated with the broadcast;
splitting the compressed multimedia content into a plurality of compressed streams; sending the plurality of streams to a plurality of network components for simultaneous transmission to a wireless device, wherein at least a portion of the network components are associated with different networks.
2. The method of claim 1, wherein the plurality of streams comprise a first stream, a second stream, and a third stream.
3. The method of claim 2, wherein each of the first stream, second stream, and third stream comprise at least one of the following: a different qualities, different portions of the multimedia content, or different transport protocols.
4. The method of claim 2, wherein the plurality of network components comprise a first gateway, a second gateway, and a second gateway, and wherein the first stream is sent to the first gateway, the second stream is sent to the second gateway, and the third stream is sent to the third gateway.
5. The method of claim 4, wherein, before being sent to the third gateway, the third stream is sent to an automatic IP multicast tunneling (AMT) relay and an AMT gateway for encapsulating or converting a first transport associated with the third stream after splitting into a second transport supported by the third gateway.
6. The method of claim 4, wherein the first gateway comprises a multimedia broadcast multicast service gateway (MBMS-GW).
7. The method of claim 4, wherein the second gateway comprises a packet data network gateway (PDN-GW).
8. The method of claim 4, wherein the third gateway comprises a wireless local area network gateway (WLAN-GW).
9. The method of claim 2, wherein the plurality of network components comprise a first broadcast and multicast - service centers (BM-SC), a second BM-SC, and a gateway, and wherein the first stream is sent to the first BM-SC, the second stream is sent to the second BM- SC, and the third stream is sent to the gateway.
10. The method of claim 9, wherein the gateway comprises a wireless local area network gateway (WLAN-GW).
11. The method of claim 1, wherein the different networks comprises two or more of the following: a third generation partnership (3GPP), a WLAN network, or an Internet Protocol (IP) network.
12. A wireless transmit and receive unit (WTRU) for cooperatively delivering a broadcast, the WTRU configured to:
register with a plurality of gateways to receive a plurality of compressed streams split from multimedia content associated with the broadcast;
receive a stream of the plurality of compressed streams from each of the gateways simultaneously;
combine the streams from each of the gateways; and
render the combined streams to display the multimedia content.
13. The WTRU of claim 12, wherein the plurality of compressed streams comprise a first stream, a second stream, and a third stream.
14. The WTRU of claim 13, wherein each of the first stream, second stream, and third stream comprise at least one of the following: a different qualities , different portions of the multimedia content, or different transport protocols.
15. The WTRU of claim 13, wherein the plurality of gateways comprise a first gateway, a second gateway, and a second gateway, and wherein the WTRU is configured to receive the first stream from the first gateway, the second stream from the second gateway, and the third stream from the third gateway.
16. The WTRU of claim 15, wherein the WTRU is configured to receive the first stream from the first gateway, second gateway, and third gateway over at least one of the following: an Internet protocol (IP) multicast or a transmission control protocol (TCP)/ user datagram protocol (UDP) unicast.
17. The WTRU of claim 15, wherein the first gateway is a multimedia broadcast multicast service gateway (MBMS-GW).
18. The WTRU of claim 15, wherein the second gateway is a packet data network gateway (PDN-GW).
19. The WTRU of claim 15, wherein the third gateway is a wireless local area network gateway (WLAN-GW).
20. The WTRU of claim 12, wherein the WTRU is configured to register with a plurality of gateways using a service descriptor.
21. The WTRU of claim 20, wherein the service descriptor comprises an accessGateway descriptor, and wherein the accesGateway descriptor points to a network within an accessGroup attribute comprising at least one of the gateways.
22. The WTRU of claim 20, wherein the service descriptor is further configured to identify a group of WTRUs the WTRU may communicate with to receive additional packets or streams associated with the multimedia content.
23. The WTRU of claim 22, wherein the service descriptor comprises an associated UserGroup descriptor to identify the group of WTRUs.
24. A method of cooperatively delivering a broadcast, the method comprising: receiving, at a first gateway, a first compressed stream from a broadcast and multicast - service center (BM-SC) split from multimedia content associated with the broadcast; receiving, at the first gateway, a second compressed stream from a second gateway split from the multimedia content associated with the broadcast;
receiving, at the first gateway, a third compressed stream from a third gateway split from the multimedia content associated with the broadcast;
assembling, at the first gateway, the first stream, second stream, and third stream; and sending the assembled streams to a wireless device to output the multimedia content thereon.
25. The method of claim 24, wherein the first gateway is configured to assemble the first stream, second stream, and third stream based on a service descriptor.
26. The method of claim 24, wherein each of the first stream, second stream, and third stream comprise at least one of the following: a different qualities , different portions of the multimedia content, or different transport protocols.
27. The method of claim 24, wherein the first gateway is a wireless local area network gateway (WLAN-GW).
28. The method of claim 24, wherein the second data gateway is an automatic IP multicast tunneling gateway (AMT-GW) configured to receive the second stream from an AMT relay in communication with a packet data network gateway (PDN-GW).
29. The method of claim 28, wherein the AMT-GW and AMT relay are configured to encapsulate or convert a first transport associated with the third stream received from the PDN- GW into a second transport supported by the first gateway.
30. The method of claim 24, wherein the third gateway is a multimedia broadcast multicast service gateway (MBMS-GW).
PCT/US2013/042993 2012-05-29 2013-05-29 Systems and methods for supporting cooperative streaming for multimedia multicast WO2013181191A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US201261652617 true 2012-05-29 2012-05-29
US61/652,617 2012-05-29

Publications (1)

Publication Number Publication Date
WO2013181191A1 true true WO2013181191A1 (en) 2013-12-05

Family

ID=48626143

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2013/042993 WO2013181191A1 (en) 2012-05-29 2013-05-29 Systems and methods for supporting cooperative streaming for multimedia multicast

Country Status (1)

Country Link
WO (1) WO2013181191A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2934045A1 (en) * 2014-04-14 2015-10-21 Broadcom Corporation Systems and methods for splitting and recombining communications in multi-network environments
DE102014219686A1 (en) * 2014-09-29 2016-03-31 Bayerische Motoren Werke Aktiengesellschaft Adaptation of a video compression with a mobile server
WO2016149163A1 (en) * 2015-03-17 2016-09-22 Thomson Licensing Mobile atsc 3.0 receiver as remote antenna
US9888422B2 (en) 2013-06-03 2018-02-06 Avago Technologies General Ip (Singapore) Pte. Ltd. System and method for adaptive access and handover configuration based on prior history in a multi-RAT environment
US9907006B2 (en) 2013-06-03 2018-02-27 Avago Technologies General Ip (Singapore) Pte. Ltd. Cross radio access technology access with handoff and interference management using communication performance data

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020199203A1 (en) * 2001-05-18 2002-12-26 John Duffy Switched digital video gateway
DE202005008603U1 (en) * 2004-06-02 2005-11-17 Interdigital Technology Corporation, Wilmington Report of terminal capabilities to support short message service
US20100263012A1 (en) * 2006-10-25 2010-10-14 Nokia Corporation Layered Coded Streaming Control For Unicast/MBMS Interaction
US20120028655A1 (en) * 2010-07-29 2012-02-02 Intel Mobile Communications Technology GmbH Radio communication devices, information providers, methods for controlling a radio communication device and methods for controlling an information provider

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020199203A1 (en) * 2001-05-18 2002-12-26 John Duffy Switched digital video gateway
DE202005008603U1 (en) * 2004-06-02 2005-11-17 Interdigital Technology Corporation, Wilmington Report of terminal capabilities to support short message service
US20100263012A1 (en) * 2006-10-25 2010-10-14 Nokia Corporation Layered Coded Streaming Control For Unicast/MBMS Interaction
US20120028655A1 (en) * 2010-07-29 2012-02-02 Intel Mobile Communications Technology GmbH Radio communication devices, information providers, methods for controlling a radio communication device and methods for controlling an information provider

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Digital Video Broadcasting (DVB); Guidelines on implementation and usage of Service Information (SI)", TECHNICAL REPORT, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI), 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS ; FRANCE, no. V1.9.1, 1 June 2009 (2009-06-01), XP014044415 *
None

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9888422B2 (en) 2013-06-03 2018-02-06 Avago Technologies General Ip (Singapore) Pte. Ltd. System and method for adaptive access and handover configuration based on prior history in a multi-RAT environment
US9907006B2 (en) 2013-06-03 2018-02-27 Avago Technologies General Ip (Singapore) Pte. Ltd. Cross radio access technology access with handoff and interference management using communication performance data
EP2934045A1 (en) * 2014-04-14 2015-10-21 Broadcom Corporation Systems and methods for splitting and recombining communications in multi-network environments
DE102014219686A1 (en) * 2014-09-29 2016-03-31 Bayerische Motoren Werke Aktiengesellschaft Adaptation of a video compression with a mobile server
WO2016149163A1 (en) * 2015-03-17 2016-09-22 Thomson Licensing Mobile atsc 3.0 receiver as remote antenna

Similar Documents

Publication Publication Date Title
Lecompte et al. Evolved multimedia broadcast/multicast service (eMBMS) in LTE-advanced: overview and Rel-11 enhancements
Schierl et al. Mobile video transmission using scalable video coding
US20130036234A1 (en) Method and apparatus for transport of dynamic adaptive streaming over http (dash) initialization segment description fragments as user service description fragments
US20140115037A1 (en) Method and apparatus for automatically discovering and retrieving content based on content identity
US20140019593A1 (en) Quality-driven streaming
US20130007814A1 (en) Dynamic adaptive streaming proxy for unicast or broadcast/multicast services
US20130182643A1 (en) Method and system for transitions of broadcast dash service receptions between unicast and broadcast
US20130336222A1 (en) Machine-To-Machine (M2M) Interface Procedures For Announce and De-Announce of Resources
US20140019635A1 (en) Operation and architecture for dash streaming clients
US20110196973A1 (en) Method and apparatus for inter-device session continuity (idsc) of multi media streams
US20120164954A1 (en) Triggering devices that are not attached to a wireless network
US20130094445A1 (en) Method and apparatus for providing interfacing between content delivery networks
US20110252151A1 (en) Mobility in peer-to-peer communications
US20110110286A1 (en) Method and apparatus for multicast mobility
US20140313989A1 (en) Method and apparatus for video aware bandwidth aggregation and/or management
US20140245359A1 (en) Content Delivery Network Interconnection (CDNI) Mechanism
US20120281621A1 (en) Wireless peer-to-peer network topology
WO2012139016A2 (en) Method and apparatus for local data caching
US20120307794A1 (en) Method and apparatus for inter-device transfer (handoff) between ims and generic ip clients
US20110110275A1 (en) Collaborative session control transfer and inter-device transfer in internet protocol multimedia subsystem
US20120209952A1 (en) Method and apparatus for distribution and reception of content
US20110116473A1 (en) METHOD AND APPARATUS FOR INTER-DEVICE HANDOVER (HO) BETWEEN INTERNET PROTOCOL (IP) MULTIMEDIA SUBSYSTEM (IMS) AND CIRCUIT SWITCHED (CS) WIRELESS TRANSMIT/RECEIVE UNITS (WTRUs)
US20120084356A1 (en) Method and apparatus for media session sharing and group synchronization of multi media streams
WO2013022470A1 (en) Methods for switching between a mbms download and an http-based delivery of dash formatted content over an ims network
US20130007186A1 (en) Controlling content caching and retrieval

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: 13728886

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13728886

Country of ref document: EP

Kind code of ref document: A1