WO2013022470A1 - Methods for switching between a mbms download and an http-based delivery of dash formatted content over an ims network - Google Patents

Methods for switching between a mbms download and an http-based delivery of dash formatted content over an ims network Download PDF

Info

Publication number
WO2013022470A1
WO2013022470A1 PCT/US2011/065586 US2011065586W WO2013022470A1 WO 2013022470 A1 WO2013022470 A1 WO 2013022470A1 US 2011065586 W US2011065586 W US 2011065586W WO 2013022470 A1 WO2013022470 A1 WO 2013022470A1
Authority
WO
WIPO (PCT)
Prior art keywords
http
sip
delivery
session
content
Prior art date
Application number
PCT/US2011/065586
Other languages
French (fr)
Inventor
Gerhard Schrom
Ravi Sankar VUNNAM
Original Assignee
Intel Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corporation filed Critical Intel Corporation
Priority to JP2014525000A priority Critical patent/JP5706046B2/en
Priority to BR112014003030-8A priority patent/BR112014003030B1/en
Priority to CN201180073198.0A priority patent/CN103748810B/en
Priority to ES11870588.8T priority patent/ES2574805T3/en
Priority to RU2014107662/07A priority patent/RU2557256C1/en
Priority to KR1020147005141A priority patent/KR101497287B1/en
Priority to US13/994,118 priority patent/US9887852B2/en
Priority to EP11870588.8A priority patent/EP2742614B1/en
Publication of WO2013022470A1 publication Critical patent/WO2013022470A1/en
Priority to US14/581,747 priority patent/US9960926B2/en
Priority to US15/881,620 priority patent/US10778458B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/24—Radio transmission systems, i.e. using radiation field for communication between two or more posts
    • H04B7/26—Radio transmission systems, i.e. using radiation field for communication between two or more posts at least one of which is mobile
    • H04B7/2603—Arrangements for wireless physical layer control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0037—Inter-user or inter-terminal allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6131—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via a mobile phone network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64707—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless for transferring content from a first network to a second network, e.g. between IP and wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H04W4/08—User group management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/30—Resource management for broadcast services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/40—Connection management for selective distribution or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

  • Wireless mobile communication technology uses various standards and protocols to transmit data between a transmission station and a wireless mobile device.
  • Some wireless devices communicate using orthogonal frequency-division multiplexing (OFDM) combined with a desired digital modulation scheme via a physical layer.
  • OFDM orthogonal frequency-division multiplexing
  • Standards and protocols that use OFDM include the third generation partnership project (3 GPP) long term evolution (LTE), the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard (e.g., 802.16e, 802.16m), which is commonly known to industry groups as WiMAX (Worldwide).
  • the transmission station can be a combination of Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node Bs (also commonly denoted as evolved Node Bs, enhanced Node Bs, eNodeBs, or eNBs) and Radio Network Controllers (RNCs), which communicates with the wireless mobile device, known as a user equipment (UE).
  • E-UTRAN Evolved Universal Terrestrial Radio Access Network
  • Node Bs also commonly denoted as evolved Node Bs, enhanced Node Bs, eNodeBs, or eNBs
  • RNCs Radio Network Controllers
  • a downlink (DL) transmission can be a communication from the transmission station (or eNodeB) to the wireless mobile device (or UE)
  • an uplink (UL) transmission can be a communication from the wireless mobile device to the transmission station.
  • the transmission station can communicate with a single wireless mobile device with a unicast subframe using a unicast service.
  • a unicast delivery can have a one-to-one relationship, referring to one message to one mobile device.
  • the transmission station can communicate with a plurality of wireless mobile devices with a multicast ⁇ broadcast single-frequency network (MBSFN) subframe using a multimedia broadcast multicast service (MBMS).
  • MMSFN multicast single-frequency network
  • MBMS multimedia broadcast multicast service
  • the transport multicast and broadcast traffic in a MBMS can have a one-to-many relationship, referring to one message to many mobile devices.
  • FIG. 1 illustrates a block diagram of an internet protocol (IP) multimedia subsystem (IMS) based packet switch streaming (PSS) and multimedia broadcast multicast services (MBMS) functional architecture in accordance with an example;
  • IP internet protocol
  • IMS internet protocol multimedia subsystem
  • PSS packet switch streaming
  • MBMS multimedia broadcast multicast services
  • FIG. 2 illustrates a block diagram of a broadcast multicast service center (BMSC) sub- functional architecture in accordance with an example
  • FIG. 3 depicts an example process for switching from a multimedia broadcast multicast services (MBMS) download to a hypertext transfer protocol (HTTP)-based delivery of dynamic adaptive streaming over HTTP (DASH) formatted content in an internet protocol (IP) multimedia subsystem (IMS) network in accordance with an example;
  • MBMS multimedia broadcast multicast services
  • HTTP hypertext transfer protocol
  • DASH dynamic adaptive streaming over HTTP
  • IP internet protocol
  • IMS multimedia subsystem
  • FIG. 4 depicts an example process for switching from a multimedia broadcast multicast services (MBMS) download to a hypertext transfer protocol (HTTP)-based delivery of dynamic adaptive streaming over HTTP (DASH) formatted content in an internet protocol (IP) multimedia subsystem (IMS) network including a request for a media presentation description (MPD) in accordance with an example;
  • MBMS multimedia broadcast multicast services
  • HTTP hypertext transfer protocol
  • DASH dynamic adaptive streaming over HTTP
  • IP internet protocol
  • IMS multimedia subsystem
  • MPD media presentation description
  • FIG. 5 depicts an example process for switching from a hypertext transfer protocol (HTTP)-based delivery to a multimedia broadcast multicast services (MBMS) download delivery of DASH formatted content in an internet protocol (IP) multimedia subsystem (IMS) network in accordance with an example;
  • HTTP hypertext transfer protocol
  • MBMS multimedia broadcast multicast services
  • IP internet protocol
  • IMS multimedia subsystem
  • FIG. 6 depicts a flow chart of a method for switching from a multimedia broadcast multicast services (MBMS) download to a hypertext transfer protocol (HTTP)-based delivery of dynamic adaptive streaming over HTTP (DASH) formatted content in an internet protocol (IP) multimedia subsystem (IMS) network in accordance with an example;
  • MBMS multimedia broadcast multicast services
  • HTTP hypertext transfer protocol
  • DASH dynamic adaptive streaming over HTTP
  • IP internet protocol
  • IMS internet protocol
  • FIG. 7 depicts a flow chart of a method for switching from a hypertext transfer protocol (HTTP)-based delivery to a multimedia broadcast multicast services (MBMS) download delivery of DASH formatted content in an internet protocol (IP) multimedia subsystem (IMS) network in accordance with an example
  • IP internet protocol
  • IMS internet protocol multimedia subsystem
  • FIG. 8 illustrates a diagram of a user equipment (UE) in accordance with an example.
  • HTTP Hypertext transfer protocol
  • HTTP -based delivery can provide reliability and deployment simplicity due to a broad adoption of both HTTP and HTTP's underlying protocols, including transmission control protocol (TCP)/internet protocol (IP).
  • HTTP -based delivery can enable easy and effortless streaming services by avoiding network address translation (NAT) and firewall traversal issues.
  • HTTP-based delivery or streaming can also provide the ability to use standard HTTP servers and caches instead of specialized streaming servers.
  • HTTP-based delivery can provide scalability due to minimal or reduced state information on a server side.
  • Dynamic adaptive streaming over HTTP is a multimedia streaming technology where a multimedia file can be partitioned into one or more segments and delivered to a client using HTTP.
  • a DASH client can receive multimedia content by downloading the segments through a series of HTTP request-response transactions.
  • DASH can provide the ability to dynamically switch between different bit rate representations of the media content as the available bandwidth changes.
  • DASH can allow for fast adaptation to changing network and wireless link conditions, user preferences and device capabilities, such as display resolution, the type of central processing unit (CPU) employed, or memory resources available.
  • the dynamic adaptation of DASH can provide a better quality of experience (QoE) for a user, with shorter startup delays and fewer rebuff ering events.
  • QoE quality of experience
  • IP multimedia subsystem or IP multimedia core network subsystem (IMS) is an architectural framework in 3 GPP for delivering IP multimedia services.
  • IP multimedia core network subsystem can be a collection of different core network and access network functions, linked by standardized interfaces, which grouped together can form one IMS administrative network.
  • IMS can use session initiation protocol (SIP).
  • SIP session initiation protocol
  • CSCF call session control function
  • Fixed access e.g., digital subscriber line (DSL), cable modems, or Ethernet
  • mobile access e.g., W-CDMA, CDMA2000, GSM, or GPRS
  • wireless access e.g., WLAN or WiMax
  • POTS plain old telephone
  • VoIP Voice over IP
  • DASH-formatted content can be delivered over an IMS network in a multicast frame, such as a multimedia broadcast multicast services (MBMS) download delivery, or in a unicast frame, such as an HTTP -based delivery.
  • a content delivery session including DASH content can be delivered using a MBMS download method, then switched to an HTTP-based delivery method in the middle of the session (mid session).
  • the content delivery session can be delivered using the HTTP-based delivery method, then switched to the MBMS download method mid session. Switching in an IMS-based network between the MBMS download method and HTTP-based delivery method during the transmission of DASH-formatted content to the user can be desirable.
  • a mobile device such as a user equipment (UE) 210, can send a session initiation protocol (SIP) re- invitation to a service control function (SCF) 230 module while the mobile device is receiving a MBMS download in a current content delivery session including DASH content.
  • SIP session initiation protocol
  • SCF service control function
  • the SIP re- invitation can include a SIP Re-TNVITE message.
  • the SIP re-invitation can include a request uniform resource identifier (URI) for an HTTP server 260 to provide DASH content via the HTTP -based delivery in the same content delivery session.
  • URI uniform resource identifier
  • the request URI can include a domain name or a content identifier identifying (or referencing) an HTTP server to provide the HTTP -based delivery.
  • the SCF module can be included in an internet protocol (IP) multimedia subsystem (IMS). After receiving the SIP re-invitation via an IP multimedia core network (IM CN) subsystem 220, the SCF module can send a SIP invitation to an HTTP/SIP adapter 250 to select an HTTP server 260 for the HTTP-based delivery.
  • IP internet protocol
  • IM CN IP multimedia core network
  • the SIP invitation can include a SIP INVITE message with the request URI, where the SCF module previously used a domain name or a content identifier associated with (or referencing) a broadcast multicast service center (BMSC) or BMSC user plane sub-functions (UPF) (BMSC.UPF) 240 to establish the MBMS download of the DASH formatted content via the BMSC.
  • BMSC broadcast multicast service center
  • UPF BMSC user plane sub-functions
  • the domain name and the content identifier referencing the HTTP server can differ from the domain name and the content identifier associated with the BMSC.
  • the SCF module 230 can also send a termination request to the BMSC to terminate the MBMS download for the content delivery session.
  • the HTTP/SIP adapter can setup the HTTP server for the HTTP-based delivery of the DASH formatted content for the same content delivery session previously used for the MBMS download.
  • the HTTP/SIP adapter can send a SIP acknowledgement to the SCF module indicating a selection of the HTTP server for the content delivery session.
  • the SIP acknowledgement can include a SIP 200 OK message.
  • the SCF module can forward the SIP acknowledgement to the mobile device via the IM CN subsystem indicating a switch to the HTTP server for the content delivery session.
  • the mobile device can then receive the DASH formatted content of the content delivery session via the HTTP-based delivery instead of the MBMS download.
  • the mobile device can send a SIP re-invitation to the SCF 230 module while the mobile device is receiving an HTTP-based delivery of DASH formatted content in a content delivery session.
  • the SIP re-invitation can include a request URI for the BMSC or the
  • the BMSC.UPF 240 to provide DASH formatted content via the MBMS download in the same content delivery session.
  • the request URI can include a domain name or a content identifier identifying (or referencing) an the BMSC to provide the MBMS download.
  • the SCF module can send an invitation message to the BMSC or the BMSC.UPF to initialize (or setup) the BMSC for the MBMS download of the content delivery session.
  • the invitation message can include a request URI, where the SCF module previously used a domain name or a content identifier associated with (or referencing) the HTTP server 260 to establish the HTTP -based delivery of the DASH formatted content via the HTTP server.
  • the domain name and the content identifier referencing the HTTP server can differ from the domain name and the content identifier associated with the BMSC.
  • the SCF module can receive a BMSC acknowledgement from the BMSC indicating a selection of the BMSC for the content delivery session after the BMSC is setup for the MBMS download.
  • the SCF module can send a SIP termination request to the HTTP/SIP adapter 250 to release the HTTP server and/or to terminate the HTTP-based delivery for the content delivery session.
  • the SIP termination request can include a SIP BYE message.
  • the HTTP/SIP adapter can send a SIP acknowledgement to the SCF module 230 indicating a termination of the HTTP-based delivery for the content delivery session and/or a setup of the BMSC for the content delivery session.
  • the SIP acknowledgement can include a SIP 200 OK message.
  • the SCF module can forward the SIP acknowledgement to the mobile device via the IM CN subsystem indicating a switch to the BMSC for the content delivery session.
  • the mobile device can receive the DASH formatted content of the content delivery session via the MBMS download instead of the HTTP -based delivery.
  • MBMS download delivery can be an alternative service for offloading HTTP-based unicast download delivery.
  • Benefits of using a MBMS download delivery can include enabling support for non-real-time service types, enabling the provision of contents that complement MBMS streaming services, and leveraging the increasing storage capacity on mobile devices.
  • the DASH segment format although mainly intended for unicast transport with HTTP, can be agnostic of the delivery environment being unicast or multicast.
  • DASH-formatted content can be transmitted using MBMS download delivery with a file delivery over unidirectional transport (FLUTE) protocol.
  • FLUTE can be a protocol for the unidirectional delivery of files over the Internet, which can be particularly suited to multicast networks.
  • FLUTE can build on asynchronous layered coding (ALC), a base protocol designed for massively scalable multicast distribution.
  • FLUTE can provide instantiation of a layered coding transport (LCT) building block.
  • the ALC protocol can combine the LCT building block, a congestion control (CC) building block and a forward error correction (FEC) building block to provide congestion controlled reliable asynchronous delivery.
  • the LCT can provide transport level support for reliable content delivery and stream delivery protocols.
  • Streaming data or downloads can be encapsulated in real-time transport protocol (RTP) and transported using the FLUTE protocol when delivering over MBMS bearers.
  • RTP can be used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications, television services and web-based push-to-talk features.
  • the bearers layer can provide a mechanism by which IP data can be transported.
  • Bearers can include a unicast bearer or a MBMS bearer.
  • the delivery layer can provide functionality such as security and key distribution, reliability control by means of forward-error-correction (FEC) techniques and associated delivery procedures such as file-repair, delivery verification. Delivery methods can include download and streaming.
  • FEC forward-error-correction
  • the MBMS user service can enable applications.
  • a user service can include multimedia messaging service or packet-switched streaming service (PSS).
  • DASH-based adaptive streaming over HTTP can be different from real time streaming protocol (RTSP)-based adaptive streaming.
  • RTSP can be a network control protocol used in entertainment and communications systems to control streaming media servers.
  • the RTSP protocol can be used for establishing and controlling media sessions between end points in a push-based and server controlled fashion, while DASH-based adaptive streaming can be pull- based and client-controlled.
  • Clients of media servers can issue videocassette recorder (VCR)- like commands, such as play and pause, to facilitate real-time control of playback of media files from the server.
  • VCR videocassette recorder
  • RTSP can define control sequences useful in controlling multimedia playback.
  • HTTP can be stateless
  • RTSP can have a state or an identifier used when needed to track concurrent sessions.
  • Disadvantages of HTTP-based progressive download can include that bandwidth may be wasted if a user decides to stop watching the content after progressive download has started (e.g., switching to another content), the download is not really bitrate adaptive, or the download does not support live media services.
  • DASH technology can address the weaknesses of RTP/RTSP- based streaming and HTTP-based progressive download.
  • the media presentation description (MPD) metadata file can provide information on the structure and different versions of the media content representations stored in the server, including different bitrates, frame rates, resolutions, codec types, and similar information.
  • the MPD information can be use to ensure mapping of segments into media presentation timeline for switching and synchronizing the presentation with other representations.
  • DASH can also specify the segment formats, such as information on the initialization and media segments for a media engine. The media engine can view the initialization segment to determine a container format and media timing information.
  • DASH technologies can include Microsoft IIS Smooth Streaming, Apple HTTP Live Streaming, and Adobe HTTP Dynamic Streaming.
  • DASH technology has also been standardized by organizations, such as the third generation partnership project (3GPP), moving picture experts group (MPEG), and open IPTV forum (OIPF).
  • 3GPP third generation partnership project
  • MPEG moving picture experts group
  • OIPF open IPTV forum
  • a mobile device can switch between an HTTP -based delivery and a MBMS download depending on certain circumstances, such as changing between packet-switch streaming service (PSS) and MBMS coverage, or triggered by a specific user action, such as trick play.
  • Trick play or trick modes can include fast forward, fast rewind, slow motion, slow rewind, pause and resume.
  • Trick play or trick modes can be based on a processing of received segments by a mobile device.
  • the received (or downloaded) segments can be provided to the decoder at a speed lower or higher than the segment's nominal timeline (the internal timestamps) may mandate, thus producing a desired trick effect on the screen or media presentation.
  • a mobile device may have already established MBMS download or HTTP-based DASH-formatted content delivery session.
  • the mobile device may be capable of switching to the other delivery method, such as an HTTP-based delivery if receiving a MBMS download, or switching to a MBMS download if receiving an HTTP-based delivery.
  • Examples of some relevant switching events for switching from MBMS download to HTTP-based delivery method can be provided without changing a channel and with changing a channel. For example, without a channel change, a user may be viewing an MBMS user service and move out of MBMS coverage. Or the user may initiate trick play mode action facilitating a switch to an HTTP-based delivery.
  • the content may only be available on packet switch streaming (PSS)/DASH with a change of a channel.
  • PSS packet switch streaming
  • Examples of some relevant switching events for switching from HTTP-based delivery to MBMS download can be provided without changing a channel and with changing a channel. For example, without a channel change, the user may return back from trick play mode to a normal MBMS user service. In another example, the content may only be available on MBMS with a change of a channel.
  • FIG. 1 illustrates an IMS based PSS and MBMS user service functional architecture.
  • Functional blocks that can facilitate the switching between the MBMS download and HTTP- based DASH delivery can include IM CN subsystem 220, the UE 210, the SCF 230, the HTTP/SIP adapter 250, the HTTP server 260, the BMSC.UPF 240, a policy and charging rules function (PCRF) 270 module, service selection function (SSF) 290 module, and a PSS adapter 292.
  • Another functional block IMS based PSS and MBMS user service functional architecture can be an evolved packet core (EPC)/packet-switch streaming (PS)/RAN 280.
  • An EPC or system architecture evolution (SAE) can include a mobility management entity (MME), a serving gateway (SGW), and packet data network (PDN) gateway (PGW).
  • MME mobility management entity
  • SGW serving gateway
  • PGW packet data network gateway
  • the IM CN subsystem 220 can support user registration and authentication, mobility and roaming, control of multimedia sessions, quality of service (QoS) control, policy control, charging, and/or interworking with circuit switched networks.
  • the UE 210 can contain the generic bootstrapping architecture (GBA)/IMS/PSS/MBMS clients, which can perform service discovery and selection, handle service initiation, modification and termination, and/or receive and present the content to the user.
  • GBA generic bootstrapping architecture
  • the SCF 230 can provide service logic and functions to support the execution of such service logic.
  • the SCF can provide service authorization during session initiation and session modification, which can include checking the PSS and the MBMS user's service subscription in order to allow or deny access to the service.
  • the SCF can select the relevant PSS and MBMS media functions.
  • the SCF can act as a proxy or back-to-back user agent (B2BUA).
  • B2BUA back-to-back user agent
  • MBMS the SCF can act as a terminating user agent (UA).
  • the HTTP/SIP adapter 250 can correlate a SIP session with HTTP incoming requests.
  • the HTTP server 260 can provide the DASH formatted content for the HTTP-based delivery.
  • the PCRF 270 module can control the charging and the establishment of resources in the RAN and PS core network 280.
  • the SSF 290 module can provide a list of available PSS (including HTTP-based DASH) and MBMS user services and relevant user service description information.
  • the SSF module can be personalized to the client's identity.
  • the PSS adapter 292 can performs bi-directional protocol translation between SIP and RTSP to offer control of PSS servers.
  • the BMSC.UPF 240 can include broadcast multicast service center (BMSC) user plane sub-functions (UPF).
  • BMSC.UPF can provide the DASH formatted content for the MBMS download.
  • FIG. 2 illustrates the BMSC sub-functional architecture and associated interfaces between the UE and BMSC.
  • the BMSC or BM-SC 242 can be in communication with and/or control a content provider/multicast broadcast source 246.
  • the BM-SC can provide the MBMS delivery functions 244.
  • FIG. 3 illustrates an example of switching from a MBMS download to an HTTP-based delivery of DASH formatted content in an IMS-based content delivery session.
  • a FLUTE-based MBMS download 300a-c delivery may have been previously initiated and the UE 210 may be receiving the DASH-formatted content from the BMSC.UPF 240.
  • the MBMS download can be a mechanism used by a MBMS user service to deliver content.
  • the MBMS download can refer to a MBMS delivery method that uses MBMS bearers in delivering content and may make use of associated procedures.
  • the MBMS download method used herein can be applicable for both delivery of continuous media (e.g. real-time video) or delivery of discrete objects (e.g. files).
  • the UE 210 may start HTTP streaming by fetching media segments from the HTTP server after obtaining an MPD.
  • a session initiation protocol (SIP) Re-INVITE 302 can be issued by the UE and sent to the IM CN subsystem 220.
  • a session description protocol (SDP) offer and a request uniform resource identifier (URI) can be included in the SIP Re-LNVITE message.
  • SDP session description protocol
  • URI uniform resource identifier
  • the request URI can be related to the HTTP -based delivery session or a SIP session that a user wishes to activate.
  • the request URI can be composed of a user part and domain part.
  • the user part can contain the content identifier, retrieved from user service description information from the SSF module.
  • the content identifier can be retrieved from service selection information.
  • the domain part can include the service provider domain name, obtained from the SSF module.
  • the 'To' header of a SIP Re-INVITE 302 and 304 or INVITE 306 message can contain the same URI as in the request URI.
  • the 'From' header of a SIP Re-INVITE or INVITE message can indicate a public user identity of the user.
  • the content identifier can be retrieved from the service selection information.
  • the SDP offer can include the media capabilities and policies available for the HTTP streaming session.
  • the SDP offer can carry the parameters indicating the type of the recommended service, (e.g. PSS, MBMS, or HTTP streaming service), the content identifier, and the identifier of a target UE.
  • the SDP offer may be derived based on the analysis of the
  • the SDP offer may be derived based on parameters received during a procedure for retrieving missing parameters by a SIP OPTIONS message.
  • a request to the HTTP server for the MPD may not be necessary as the UE may already have fetched the MPD during the MBMS download.
  • the UE may send an HTTP GET request to the HTTP server in order to download the MPD.
  • the SDP offer may include previously negotiated media descriptions with a port set to zero and two or more additional media descriptions.
  • the media descriptions can include a media control channel (i.e., MPD delivery channel) and a media delivery channel (i.e. delivery channel for the unicast streams over HTTP).
  • the SDP offer can include information for the HTTP -based delivery, such as a media description, a media control channel, a media delivery channel, a MPD control channel, a delivery channel for a unicast stream over HTTP, media capabilities available at the HTTP server, policies available at the HTTP server, and a combination of this information.
  • the SDP offer for media delivery may be similar to a previous SDP offer done for broadcast in terms of codecs and a transport protocol.
  • the HTTP-based delivery can run on top of TCP whereas FLUTE-based MBMS download delivery can run on top of user datagram protocol (UDP).
  • TCP and UDP can be protocols in the transport layer.
  • the change in the underlying protocol, such as UDP to TCP, can be indicated in the SDP.
  • UDP is one of the members of the Internet Protocol Suite. With UDP, computer applications can send messages, referred to as datagrams, to other hosts on an IP network without requiring prior communications to set up special transmission channels or data paths.
  • the IM CN subsystem 220 may forward the SIP Re-INVITE 304 message to the SCF
  • the SCF can determine if the program currently broadcasted has MBMS to HTTP switching support (a MBMS-to-HTTP switching support). If MBMS to HTTP switching is not available for the UE 210, the session modification can be rejected and the original MBMS download or session (along with the previous reserved resources) may be maintained.
  • MBMS-to-HTTP switching support a MBMS-to-HTTP switching support
  • the SCF 230 can act as a B2BUA.
  • the SCF can check or verify the user rights for the requested DASH formatted content, identify that the request is for HTTP streaming, select an HTTP/SIP adapter 250, and forward the SIP request (a SIP INVITE 306) to the HTTP/SIP adapter which can be in charge of the HTTP streaming service by changing the request URI accordingly.
  • the SCF may not forward the 301 or 302 response message to the UE.
  • the HTTP/SIP adapter can return a 301 response if the content requested is not managed by this HTTP/SIP adapter.
  • the HTTP/SIP adapter can return a 302 response for any other reasons, other than not managing the content request (a 301 response). For instance, a 302 response message may be sent for a reason such as load balancing.
  • the SCF 230 can select a suitable HTTP/SIP adapter 250 and generate a SIP INVITE 306 request to the selected HTTP/SIP adapter.
  • the 'To' header of the SIP INVITE request can contain the same content identifier as in the request URI of the SIP modification request received from the UE 210 by the SCF.
  • the SCF 230 can send the SIP INVITE 306 request to the HTTP/SIP adapter 250 with the SDP parameters including the media capabilities and policies available for the HTTP streaming session.
  • the SIP INVITE request may be derived based on the analysis of the MPD.
  • the SDP offer may include previously negotiated media descriptions with a port set to zero and two or more additional media descriptions.
  • the media descriptions can include a media control channel (i.e., MPD delivery channel) and a media delivery channel (i.e. delivery channel for the unicast streams over HTTP).
  • the SCF 230 can tear down the FLUTE-based MBMS download session between the BMSC.UPF 240 and the UE 210.
  • the SCF can send a MBMS termination 310 request or message to the BMSC.UPF.
  • the communication protocol between the SCF and the BMSC.UPF can be defined by 3 GPP technical specification (TS) 26.346 VIO.0.0 published March 2011.
  • the BMSC.UPF may release any content provider/multicast broadcast source (246 of FIG. 2) and terminate the MBMS download.
  • the BMSC.UPF can send an acknowledgement (ACK) 312 message to the SCF indicating a successful termination or send a negative acknowledgement (NACK) message to the SCF indicating a failed termination or release of resources.
  • ACK acknowledgement
  • NACK negative acknowledgement
  • the HTTP/SIP adapter 250 can examine the content identifier present in the user part of the 'To' header and the media parameters in the SDP and select an HTTP server 260 according to the request URI.
  • the HTTP/SIP adapter can send an HTTP POST message to the HTTP server including the IP address of the UE.
  • the HTTP/SIP adapter may decide to redirect the request to another HTTP/SIP adapter server. In the case of a redirect the request to another HTTP/SIP adapter server, the HTTP/SIP adapter can return a 301 response if the content is not managed by this HTTP/SIP adapter or a 302 response for any other reasons, such as load balancing.
  • the redirecting HTTP/SIP adapter can indicate one or more destination HTTP/SIP adapter addresses in the contact header.
  • the HTTP/SIP adapter 250 can return an SIP acknowledgement message, such as a SIP OK 308 message (e.g., a SIP 200 OK message), to the SCF 230.
  • the SIP acknowledgement can include a SDP answer.
  • the SDP answer can describe the HTTP streaming session (or the SIP session).
  • the SDP answer can include information for the HTTP -based delivery, such as a media description, a media control channel, a media delivery channel, a media presentation description (MPD) control channel, a delivery description, and a combination of this information.
  • MPD media presentation description
  • the SCF 230 can forward the SIP OK 314 to the IM CN subsystem 220.
  • the IM CN subsystem can interact with the policy charging and rules function (PCRF) 270 module of the policy charging and control (PCC) architecture to commit the QoS reservation for QoS bearer enforcement 316a.
  • the PCRF module can provide QoS bearer enforcement 316b-d between the UE and the IMS.
  • the IM CN subsystem can then forward the SIP OK 318 (e.g., a SIP 200 OK message) to the UE 210.
  • the proxy call session control function can be used as the application function in the PCC architecture.
  • the PCRF 270 can decide how policy control of the QoS is performed for an IMS initiated and controlled PSS and MBMS user service.
  • the PCRF can use the SDP received from the P-CSCF during session establishment to calculate a proper QoS authorization.
  • the appropriate existing bearers can be used or new required bearers can be allocated by the PCRF.
  • Network initiated bearer control and UE initiated bearer control may be possible.
  • the UE 210 may initiate the establishment of the required bearers unless a network initiated bearer allocation procedure is already ongoing. Alternatively, the UE has been configured to use network initiated resource control.
  • the UE 210 After receiving the SIP OK 318, the UE 210 can leave the multicast channel and can start downloading DASH-formatted content over HTTP (adaptive HTTP-based DASH content delivery 320a-c), such that the media segments can be delivered to the UE using the reserved QoS.
  • HTTP adaptive HTTP-based DASH content delivery 320a-c
  • an air interface between a mobile device, such as a UE, and a transmission station, such as an eNB may support unicast and multicast delivery of content to allow the switching between the MBMS download and the HTTP-based delivery of DASH formatted content.
  • the eNB of the RAN can be in communication with the IMS and modules within the IMS, such as the SCF module.
  • the air interface can include the 3 GPP LTE or the 802.16 standard.
  • the mobile device and/or the transmission station can use the 3GPP LTE or the 802.16 protocol.
  • the 3 GPP LTE standard can include LTE Rel-8 (2008), LTE Rel-9 (2009), and LTE Rel-10 (2011).
  • the IEEE 802.16 standard can include IEEE 802.16e-2005, IEEE 802.16k- 2007, IEEE 802.16-2009, IEEE 802.16j-2009, IEEE 802.16h-2010, and IEEE 802.16m-2011.
  • FIG. 4 illustrates an example of switching from a MBMS download to an HTTP-based delivery of DASH formatted content in a content delivery session, where a MPD metadata file is obtained prior to a SIP Re-INVITE.
  • the UE 210 can make a request for the MPD 322 from the HTTP server 260.
  • the HTTP server can send the MPD 324 to the UE.
  • the UE can use the information in the MPD to generate the SIP Re-TNVITE 302 to be sent to the IM CN subsystem 220.
  • the rest of the operations in FIG. 4 can be similar to the operations of FIG. 3, which were previously discussed.
  • FIG. 5 illustrates an example of switching from HTTP -based delivery to MBMS download of DASH formatted content in a content delivery session.
  • An HTTP -based delivery (e.g., adaptive HTTP -based DASH content delivery 330a-c) may have been previously initiated and the UE 210 may be receiving the DASH-formatted content over HTTP from the HTTP server 260.
  • the DASH formatted content may be delivered in an existing SIP session.
  • a session modification request such as SIP Re-INVITE 332
  • SIP Re-INVITE 332 can be issued by the UE 210 and sent to the IM CN subsystem 220.
  • a session description protocol (SDP) offer indicating the chosen MBMS download service and FLUTE session information and a request uniform resource identifier (URI) can be included in the SIP Re-INVITE message.
  • the SDP offer can be performed in accordance with the parameters received during a UE service selection procedure and with media capabilities and required bandwidth available for the MBMS download service.
  • the SDP offer for media delivery may be similar to the previous SDP offer performed for HTTP-based delivery in terms of codecs and transport protocol.
  • the SDP offer can include information for the MBMS download, such as a media description, a media control channel, a media delivery channel, a MPD control channel, a delivery channel for a multicast stream over MBMS, media capabilities available at the BMSC, policies available at the BMSC, and a combination of this information.
  • the MPD may include information to switch from HTTP-based delivery to MBMS download delivery and the UE may utilize such information when issuing the session modification request, e.g., SIP Re-INVITE, to switch to the MBMS download.
  • the SIP Re-INVITE message can also contain the request URI which can include the public service identifier (PSI) of a MBMS download service.
  • PSI public service identifier
  • the 'To' header of the SIP Re-INVITE can contain the same URI as in the request URI and the 'From' header of the SIP Re-INVITE can indicate the public user identity of the user.
  • the IM CN subsystem 220 can forward the SIP Re-INVITE 334 message to the SCF
  • the SCF can perform service authorization procedures to check the service rights of requested MBMS download service according to the user subscription information.
  • the SCF 230 can determine if the content currently delivered has HTTP to MBMS switching support (e.g., an HTTP-to-MBMS switching support). If HTTP to MBMS switching is not available for the UE 210, the session modification can be rejected and the original HTTP session (along with the previous reserved resources) may be maintained. If HTTP to MBMS switching is available for the UE, the SCF can act as a B2BUA to establish the FLUTE-based MBMS download session between the BMSC.UPF and UE.
  • HTTP to MBMS switching support e.g., an HTTP-to-MBMS switching support
  • the communication protocol between the SCF and the BMSC.UPF can be defined by 3 GPP technical specification (TS) 26.346 VIO.0.0 published March 2011.
  • the SCF can send a MBMS invitation 340 to the BMSC.UPF.
  • the BMSC.UPF can send a MBMS
  • the SCF can send a SIP BYE 336 message (an HTTP termination request) to the HTTP/SIP adapter 250 to terminate the SIP session between the SCF and the HTTP/SIP adapter.
  • the HTTP/SIP adapter 250 can then release the HTTP server 260, and can send a SIP acknowledgement message, such as a SIP OK 338 message, to the SCF 230.
  • a SIP acknowledgement message such as a SIP OK 338 message
  • the SCF can send a SIP OK 344 message to IM CN subsystem 220.
  • the SIP acknowledgement can include a SDP answer.
  • the SDP answer can include information for the MBMS download, such as a media description, a media control channel, a media delivery channel, a media presentation description (MPD) control channel, a delivery description, and a combination of this information.
  • MPD media presentation description
  • the IM CN subsystem 220 can forward the SIP OK 348 message to the UE 210.
  • the SIP OK message can include the SDP answer.
  • the P-CSCF can be used as the application function in the PCC architecture.
  • the PCRF can decide how policy control of the QoS is performed for the IMS initiated and controlled MBMS user service and communication for QoS bearer enforcement 346a-d (similar to the process for QoS bearer enforcement 316a-d illustrated in FIG. 3 between the IM CN subsystem, the PCRF module, and the UE). For a switch to the MBMS download, the PCRF may not initiate the establishment of a specific bearer.
  • the UE can activate a corresponding MBMS user service as described in the SDP, such as the MBMS download service based on FLUTE 350a-c.
  • the MBMS download reception initiation may correspond to the MBMS broadcast mode activation procedure or the MBMS multicast mode activation procedure.
  • the UE can examine the FLUTE session parameters in the received SDP, and receive the MBMS download data accordingly.
  • a file delivery table FDT
  • the UE can get the FDT according to an fdt address attribute in the SDP answer.
  • the FDT can contain content description information for the files delivered in the FLUTE session.
  • the UE can execute the file repair procedures towards the repair server indicated by a repair-server-address attribute in the SDP answer.
  • the switching between the MBMS download and the HTTP-based delivery can be agnostic of specific air interface (e.g., RAN) characteristics. Any air interface or combination of multiple air interfaces may be applicable as long as associated networks can host the IMS-based HTTP delivery and MBMS download delivery functions.
  • the switching between the MBMS download and the HTTP-based delivery can be used in 3GPP-based or 802.16-based wireless wide area networks (WWANs), and IMS-based applications, where optimized delivery of
  • DASH-formatted multimedia content over these networks is desired.
  • the signaling procedures for enabling the switching between HTTP -based delivery and MBMS download delivery for streaming DASH formatted content can improve the quality of experience for the user.
  • Another example provides a method 500 for switching from a multimedia broadcast multicast services (MBMS) download to a hypertext transfer protocol (HTTP)-based delivery of dynamic adaptive streaming over HTTP (DASH) formatted content, as shown in the flow chart in FIG. 6.
  • the method includes the operation of receiving a session initiation protocol (SIP) re- invitation at a service control function (SCF) module from a mobile device while the mobile device is receiving a MBMS download in a content delivery session including DASH formatted content, as in block 510.
  • SCF service control function
  • the operation of sending a SIP invitation from the SCF module to an HTTP/SIP adapter to select an HTTP server for an HTTP -based delivery follows, as in block 520.
  • the next operation of the method can be receiving a SIP acknowledgement at the SCF module from the HTTP/SIP adapter indicating a selection of the HTTP server for the content delivery session, as in block 530.
  • the method can further include forwarding the SIP acknowledgement from the SCF module to the mobile device indicating a switch to the HTTP server for the content delivery session, as in block 540.
  • Another example provides a method 600 for switching from a hypertext transfer protocol (HTTP)-based delivery of dynamic adaptive streaming over HTTP (DASH) formatted content to a multimedia broadcast multicast services (MBMS) download, as shown in the flow chart in FIG. 7.
  • the method includes the operation of receiving a session initiation protocol (SIP) re-invitation at a service control function (SCF) module from a mobile device while the mobile device is receiving an HTTP-based delivery in a content delivery session including DASH formatted content, as in block 610.
  • SCF service control function
  • the operation of sending an invitation message from the SCF module to the BMSC to initialize a broadcast multicast service center (BMSC) for a MBMS download follows, as in block 620.
  • SIP session initiation protocol
  • SCF service control function
  • the next operation of the method can be sending a SIP termination request from the SCF module to an HTTP/SIP adapter to terminate the HTTP- based delivery, as in block 630.
  • the operation of receiving a SIP acknowledgement at the SCF module from the HTTP/SIP adapter indicating a termination of the HTTP-based delivery follows, as in block 640.
  • the method can further include forwarding the SIP acknowledgement from the SCF module to the mobile device indicating a switch to the BMSC for the content delivery session, as in block 650.
  • the SCF can include a transceiver module configured to receive a multicast-to-unicast session modification request, where the transceiver can perform the operations related to the SCF illustrated in FIG. 3.
  • the transceiver module of the SCF can be configured to receive a unicast-to-multicast session modification request, where the transceiver can perform the operations related to the SCF illustrated in FIG. 5.
  • the mobile device can include a transceiver configured to send a multicast-to-unicast session modification request to an IM CN subsystem, where the transceiver can perform the operations related to the mobile device illustrated in FIG. 3.
  • the transceiver module of the SCF can be configured to send a unicast-to-multicast session modification request, where the transceiver can perform the operations related to the mobile device illustrated in FIG. 5.
  • the transceiver can be configured to receive a SIP acknowledgement or SIP termination message from the IM CN subsystem.
  • the mobile device can include a processing module configured to switch between the MBMS download and the HTTP-based delivery for the DASH formatted content.
  • a transmission station can be in wireless communication with a mobile device.
  • FIG. 8 provides an example illustration of the mobile device, such as a user equipment (UE), a mobile station (MS), a mobile wireless device, a mobile communication device, a tablet, a handset, or other type of mobile wireless device.
  • the mobile device can include one or more antennas configured to communicate with a node, macro node, low power node (LPN), or, transmission station, such as a base station (BS), an evolved Node B (eNB), a base band unit (BBU), a remote radio head (RRH), a remote radio equipment (RRE), a relay station (RS), a radio equipment (RE), or other type of wireless wide area network (WWAN) access point.
  • BS base station
  • eNB evolved Node B
  • BBU base band unit
  • RRH remote radio head
  • RRE remote radio equipment
  • RS relay station
  • RE radio equipment
  • the mobile device can be configured to communicate using at least one wireless communication standard including 3 GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi.
  • the mobile device can communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards.
  • the mobile device can communicate in a wireless local area network (WLAN), a wireless personal area network (WPAN), and/or a WWAN.
  • WLAN wireless local area network
  • WPAN wireless personal area network
  • WWAN Wide Area Network
  • FIG. 8 also provides an illustration of a microphone and one or more speakers that can be used for audio input and output from the mobile device.
  • the display screen may be a liquid crystal display (LCD) screen, or other type of display screen such as an organic light emitting diode (OLED) display.
  • the display screen can be configured as a touch screen.
  • the touch screen may use capacitive, resistive, or another type of touch screen technology.
  • An application processor and a graphics processor can be coupled to internal memory to provide processing and display capabilities.
  • a non- volatile memory port can also be used to provide data input/output options to a user.
  • the non- volatile memory port may also be used to expand the memory capabilities of the mobile device.
  • a keyboard may be integrated with the mobile device or wirelessly connected to the mobile device to provide additional user input.
  • a virtual keyboard may also be provided using the touch screen.
  • Various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD- ROMs, hard drives, non-transitory computer readable storage medium, or any other machine- readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques.
  • the computing device may include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device.
  • the volatile and non-volatile memory and/or storage elements may be a RAM, EPROM, flash drive, optical drive, magnetic hard drive, or other medium for storing electronic data.
  • the base station and mobile station may also include a transceiver module, a counter module, a processing module, and/or a clock module or timer module.
  • One or more programs that may implement or utilize the various techniques described herein may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.
  • API application programming interface
  • modules may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components.
  • a module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
  • Modules may also be implemented in software for execution by various types of processors.
  • An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
  • a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices.
  • operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network.
  • the modules may be passive or active, including agents operable to perform desired functions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

A method for switching from a multimedia broadcast multicast services (MBMS) download to a hypertext transfer protocol (HTTP)-based delivery of dynamic adaptive streaming over HTTP (DASH) formatted content in an internet protocol (IP) multimedia subsystem (IMS) network is disclosed. The method can include a service control function (SCF) module receiving a session initiation protocol (SIP) re-invitation from a mobile device while the mobile device is receiving a MBMS download in a content delivery session including DASH formatted content. The SCF module can send a SIP invitation to an HTTP/SIP adapter to select an HTTP server for an HTTP-based delivery. The SCF module can receive a SIP acknowledgement from the HTTP/SIP adapter indicating a selection of the HTTP server for the content delivery session. The SCF module can forward the SIP acknowledgement to the mobile device indicating a switch to the HTTP server for the content delivery session.

Description

METHODS FOR SWITCHING BETWEEN A MBMS DOWNLOAD AND AN HTTP- BASED DELIVERY OF DASH FORMATTED CONTENT OVER AN IMS NETWORK RELATED APPLICATIONS
This application claims the benefit of and hereby incorporates by reference U.S. Provisional Patent Application Serial No. 61/522,623, filed August 11, 2011, with a docket number P39106Z.
BACKGROUND
Wireless mobile communication technology uses various standards and protocols to transmit data between a transmission station and a wireless mobile device. Some wireless devices communicate using orthogonal frequency-division multiplexing (OFDM) combined with a desired digital modulation scheme via a physical layer. Standards and protocols that use OFDM include the third generation partnership project (3 GPP) long term evolution (LTE), the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard (e.g., 802.16e, 802.16m), which is commonly known to industry groups as WiMAX (Worldwide
interoperability for Microwave Access), and the IEEE 802.11 standard, which is commonly known to industry groups as WiFi.
In 3 GPP radio access network (RAN) LTE systems, the transmission station can be a combination of Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node Bs (also commonly denoted as evolved Node Bs, enhanced Node Bs, eNodeBs, or eNBs) and Radio Network Controllers (RNCs), which communicates with the wireless mobile device, known as a user equipment (UE). A downlink (DL) transmission can be a communication from the transmission station (or eNodeB) to the wireless mobile device (or UE), and an uplink (UL) transmission can be a communication from the wireless mobile device to the transmission station.
In a downlink transmission, the transmission station can communicate with a single wireless mobile device with a unicast subframe using a unicast service. A unicast delivery can have a one-to-one relationship, referring to one message to one mobile device. Alternatively, the transmission station can communicate with a plurality of wireless mobile devices with a multicast\broadcast single-frequency network (MBSFN) subframe using a multimedia broadcast multicast service (MBMS). The transport multicast and broadcast traffic in a MBMS can have a one-to-many relationship, referring to one message to many mobile devices.
BRIEF DESCRIPTION OF THE DRAWINGS
Features and advantages of the disclosure will be apparent from the detailed description which follows, taken in conjunction with the accompanying drawings, which together illustrate, by way of example, features of the disclosure; and, wherein:
FIG. 1 illustrates a block diagram of an internet protocol (IP) multimedia subsystem (IMS) based packet switch streaming (PSS) and multimedia broadcast multicast services (MBMS) functional architecture in accordance with an example;
FIG. 2 illustrates a block diagram of a broadcast multicast service center (BMSC) sub- functional architecture in accordance with an example;
FIG. 3 depicts an example process for switching from a multimedia broadcast multicast services (MBMS) download to a hypertext transfer protocol (HTTP)-based delivery of dynamic adaptive streaming over HTTP (DASH) formatted content in an internet protocol (IP) multimedia subsystem (IMS) network in accordance with an example;
FIG. 4 depicts an example process for switching from a multimedia broadcast multicast services (MBMS) download to a hypertext transfer protocol (HTTP)-based delivery of dynamic adaptive streaming over HTTP (DASH) formatted content in an internet protocol (IP) multimedia subsystem (IMS) network including a request for a media presentation description (MPD) in accordance with an example;
FIG. 5 depicts an example process for switching from a hypertext transfer protocol (HTTP)-based delivery to a multimedia broadcast multicast services (MBMS) download delivery of DASH formatted content in an internet protocol (IP) multimedia subsystem (IMS) network in accordance with an example;
FIG. 6 depicts a flow chart of a method for switching from a multimedia broadcast multicast services (MBMS) download to a hypertext transfer protocol (HTTP)-based delivery of dynamic adaptive streaming over HTTP (DASH) formatted content in an internet protocol (IP) multimedia subsystem (IMS) network in accordance with an example;
FIG. 7 depicts a flow chart of a method for switching from a hypertext transfer protocol (HTTP)-based delivery to a multimedia broadcast multicast services (MBMS) download delivery of DASH formatted content in an internet protocol (IP) multimedia subsystem (IMS) network in accordance with an example; and FIG. 8 illustrates a diagram of a user equipment (UE) in accordance with an example.
Reference will now be made to the exemplary embodiments illustrated, and specific language will be used herein to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended.
DETAILED DESCRIPTION
Before the present invention is disclosed and described, it is to be understood that this invention is not limited to the particular structures, process steps, or materials disclosed herein, but is extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular examples only and is not intended to be limiting. The same reference numerals in different drawings represent the same element. Numbers provided in flow charts and processes are provided for clarity in illustrating steps and operations and do not necessarily indicate a particular order or sequence.
EXAMPLE EMBODIMENTS
An initial overview of technology embodiments is provided below and then specific technology embodiments are described in further detail later. This initial summary is intended to aid readers in understanding the technology more quickly but is not intended to identify key features or essential features of the technology nor is it intended to limit the scope of the claimed subject matter.
Hypertext transfer protocol (HTTP) streaming can be used as a form of multimedia delivery of Internet video. HTTP -based delivery can provide reliability and deployment simplicity due to a broad adoption of both HTTP and HTTP's underlying protocols, including transmission control protocol (TCP)/internet protocol (IP). HTTP -based delivery can enable easy and effortless streaming services by avoiding network address translation (NAT) and firewall traversal issues. HTTP-based delivery or streaming can also provide the ability to use standard HTTP servers and caches instead of specialized streaming servers. HTTP-based delivery can provide scalability due to minimal or reduced state information on a server side.
Dynamic adaptive streaming over HTTP (DASH) is a multimedia streaming technology where a multimedia file can be partitioned into one or more segments and delivered to a client using HTTP. A DASH client can receive multimedia content by downloading the segments through a series of HTTP request-response transactions. DASH can provide the ability to dynamically switch between different bit rate representations of the media content as the available bandwidth changes. Thus, DASH can allow for fast adaptation to changing network and wireless link conditions, user preferences and device capabilities, such as display resolution, the type of central processing unit (CPU) employed, or memory resources available. The dynamic adaptation of DASH can provide a better quality of experience (QoE) for a user, with shorter startup delays and fewer rebuff ering events.
The internet protocol (IP) multimedia subsystem or IP multimedia core network subsystem (IMS) is an architectural framework in 3 GPP for delivering IP multimedia services. The IP multimedia core network subsystem can be a collection of different core network and access network functions, linked by standardized interfaces, which grouped together can form one IMS administrative network. To ease the integration with the Internet, IMS can use session initiation protocol (SIP). Several roles of SIP servers or proxies, which can collectively be called a call session control function (CSCF), can be used to process SIP signaling packets in the IMS. Fixed access (e.g., digital subscriber line (DSL), cable modems, or Ethernet), mobile access (e.g., W-CDMA, CDMA2000, GSM, or GPRS) and wireless access (e.g., WLAN or WiMax) can be supported by the IMS. Other phone systems like plain old telephone (POTS— analog telephones) and non IMS-compatible Voice over IP (VoIP) systems can be supported through gateways.
DASH-formatted content can be delivered over an IMS network in a multicast frame, such as a multimedia broadcast multicast services (MBMS) download delivery, or in a unicast frame, such as an HTTP -based delivery. A content delivery session including DASH content can be delivered using a MBMS download method, then switched to an HTTP-based delivery method in the middle of the session (mid session). Alternatively, the content delivery session can be delivered using the HTTP-based delivery method, then switched to the MBMS download method mid session. Switching in an IMS-based network between the MBMS download method and HTTP-based delivery method during the transmission of DASH-formatted content to the user can be desirable.
As illustrated in the example block diagram of FIG. 1 , in the switch from the MBMS download to the HTTP-based delivery of DASH formatted content in the IMS network, a mobile device, such as a user equipment (UE) 210, can send a session initiation protocol (SIP) re- invitation to a service control function (SCF) 230 module while the mobile device is receiving a MBMS download in a current content delivery session including DASH content. The SIP re- invitation can include a SIP Re-TNVITE message. The SIP re-invitation can include a request uniform resource identifier (URI) for an HTTP server 260 to provide DASH content via the HTTP -based delivery in the same content delivery session. The request URI can include a domain name or a content identifier identifying (or referencing) an HTTP server to provide the HTTP -based delivery. The SCF module can be included in an internet protocol (IP) multimedia subsystem (IMS). After receiving the SIP re-invitation via an IP multimedia core network (IM CN) subsystem 220, the SCF module can send a SIP invitation to an HTTP/SIP adapter 250 to select an HTTP server 260 for the HTTP-based delivery. The SIP invitation can include a SIP INVITE message with the request URI, where the SCF module previously used a domain name or a content identifier associated with (or referencing) a broadcast multicast service center (BMSC) or BMSC user plane sub-functions (UPF) (BMSC.UPF) 240 to establish the MBMS download of the DASH formatted content via the BMSC.
The domain name and the content identifier referencing the HTTP server can differ from the domain name and the content identifier associated with the BMSC. The SCF module 230 can also send a termination request to the BMSC to terminate the MBMS download for the content delivery session. The HTTP/SIP adapter can setup the HTTP server for the HTTP-based delivery of the DASH formatted content for the same content delivery session previously used for the MBMS download. The HTTP/SIP adapter can send a SIP acknowledgement to the SCF module indicating a selection of the HTTP server for the content delivery session. The SIP acknowledgement can include a SIP 200 OK message. The SCF module can forward the SIP acknowledgement to the mobile device via the IM CN subsystem indicating a switch to the HTTP server for the content delivery session. The mobile device can then receive the DASH formatted content of the content delivery session via the HTTP-based delivery instead of the MBMS download.
In the switch from the HTTP-based delivery to the MBMS download of DASH formatted content, the mobile device can send a SIP re-invitation to the SCF 230 module while the mobile device is receiving an HTTP-based delivery of DASH formatted content in a content delivery session. The SIP re-invitation can include a request URI for the BMSC or the
BMSC.UPF 240 to provide DASH formatted content via the MBMS download in the same content delivery session. The request URI can include a domain name or a content identifier identifying (or referencing) an the BMSC to provide the MBMS download. After receiving the SIP re-invitation via the IM CN subsystem 220, the SCF module can send an invitation message to the BMSC or the BMSC.UPF to initialize (or setup) the BMSC for the MBMS download of the content delivery session. The invitation message can include a request URI, where the SCF module previously used a domain name or a content identifier associated with (or referencing) the HTTP server 260 to establish the HTTP -based delivery of the DASH formatted content via the HTTP server. The domain name and the content identifier referencing the HTTP server can differ from the domain name and the content identifier associated with the BMSC. The SCF module can receive a BMSC acknowledgement from the BMSC indicating a selection of the BMSC for the content delivery session after the BMSC is setup for the MBMS download. The SCF module can send a SIP termination request to the HTTP/SIP adapter 250 to release the HTTP server and/or to terminate the HTTP-based delivery for the content delivery session. The SIP termination request can include a SIP BYE message.
The HTTP/SIP adapter can send a SIP acknowledgement to the SCF module 230 indicating a termination of the HTTP-based delivery for the content delivery session and/or a setup of the BMSC for the content delivery session. The SIP acknowledgement can include a SIP 200 OK message. The SCF module can forward the SIP acknowledgement to the mobile device via the IM CN subsystem indicating a switch to the BMSC for the content delivery session. The mobile device can receive the DASH formatted content of the content delivery session via the MBMS download instead of the HTTP -based delivery.
The following provides additional details of the examples. MBMS download delivery can be an alternative service for offloading HTTP-based unicast download delivery. Benefits of using a MBMS download delivery can include enabling support for non-real-time service types, enabling the provision of contents that complement MBMS streaming services, and leveraging the increasing storage capacity on mobile devices. The DASH segment format, although mainly intended for unicast transport with HTTP, can be agnostic of the delivery environment being unicast or multicast. DASH-formatted content can be transmitted using MBMS download delivery with a file delivery over unidirectional transport (FLUTE) protocol.
FLUTE can be a protocol for the unidirectional delivery of files over the Internet, which can be particularly suited to multicast networks. FLUTE can build on asynchronous layered coding (ALC), a base protocol designed for massively scalable multicast distribution. FLUTE can provide instantiation of a layered coding transport (LCT) building block. The ALC protocol can combine the LCT building block, a congestion control (CC) building block and a forward error correction (FEC) building block to provide congestion controlled reliable asynchronous delivery. The LCT can provide transport level support for reliable content delivery and stream delivery protocols. Streaming data or downloads can be encapsulated in real-time transport protocol (RTP) and transported using the FLUTE protocol when delivering over MBMS bearers. RTP can be used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications, television services and web-based push-to-talk features.
Three functional layers can be used for the delivery of MBMS-based services, which can include a bearers layer, a delivery method layer, and a user service layer or application layer. The bearers layer can provide a mechanism by which IP data can be transported. Bearers can include a unicast bearer or a MBMS bearer. The delivery layer can provide functionality such as security and key distribution, reliability control by means of forward-error-correction (FEC) techniques and associated delivery procedures such as file-repair, delivery verification. Delivery methods can include download and streaming. The MBMS user service can enable applications. A user service can include multimedia messaging service or packet-switched streaming service (PSS).
DASH-based adaptive streaming over HTTP can be different from real time streaming protocol (RTSP)-based adaptive streaming. RTSP can be a network control protocol used in entertainment and communications systems to control streaming media servers. The RTSP protocol can be used for establishing and controlling media sessions between end points in a push-based and server controlled fashion, while DASH-based adaptive streaming can be pull- based and client-controlled. Clients of media servers can issue videocassette recorder (VCR)- like commands, such as play and pause, to facilitate real-time control of playback of media files from the server. While similar in some ways to HTTP, RTSP can define control sequences useful in controlling multimedia playback. While HTTP can be stateless, RTSP can have a state or an identifier used when needed to track concurrent sessions.
Prior to the use of DASH-based adaptive streaming techniques, progressive download methods were also available for media delivery from standard HTTP web servers.
Disadvantages of HTTP-based progressive download can include that bandwidth may be wasted if a user decides to stop watching the content after progressive download has started (e.g., switching to another content), the download is not really bitrate adaptive, or the download does not support live media services. DASH technology can address the weaknesses of RTP/RTSP- based streaming and HTTP-based progressive download.
In DASH, the media presentation description (MPD) metadata file can provide information on the structure and different versions of the media content representations stored in the server, including different bitrates, frame rates, resolutions, codec types, and similar information. The MPD information can be use to ensure mapping of segments into media presentation timeline for switching and synchronizing the presentation with other representations. In addition, DASH can also specify the segment formats, such as information on the initialization and media segments for a media engine. The media engine can view the initialization segment to determine a container format and media timing information.
Examples of DASH technologies can include Microsoft IIS Smooth Streaming, Apple HTTP Live Streaming, and Adobe HTTP Dynamic Streaming. DASH technology has also been standardized by organizations, such as the third generation partnership project (3GPP), moving picture experts group (MPEG), and open IPTV forum (OIPF).
To provide a consistent user experience for an entire adaptive streaming session or content delivery session. A mobile device can switch between an HTTP -based delivery and a MBMS download depending on certain circumstances, such as changing between packet-switch streaming service (PSS) and MBMS coverage, or triggered by a specific user action, such as trick play. Trick play or trick modes can include fast forward, fast rewind, slow motion, slow rewind, pause and resume. Trick play or trick modes can be based on a processing of received segments by a mobile device. The received (or downloaded) segments can be provided to the decoder at a speed lower or higher than the segment's nominal timeline (the internal timestamps) may mandate, thus producing a desired trick effect on the screen or media presentation.
A mobile device may have already established MBMS download or HTTP-based DASH-formatted content delivery session. The mobile device may be capable of switching to the other delivery method, such as an HTTP-based delivery if receiving a MBMS download, or switching to a MBMS download if receiving an HTTP-based delivery. Examples of some relevant switching events for switching from MBMS download to HTTP-based delivery method can be provided without changing a channel and with changing a channel. For example, without a channel change, a user may be viewing an MBMS user service and move out of MBMS coverage. Or the user may initiate trick play mode action facilitating a switch to an HTTP-based delivery. In another example, the content may only be available on packet switch streaming (PSS)/DASH with a change of a channel. Examples of some relevant switching events for switching from HTTP-based delivery to MBMS download can be provided without changing a channel and with changing a channel. For example, without a channel change, the user may return back from trick play mode to a normal MBMS user service. In another example, the content may only be available on MBMS with a change of a channel.
FIG. 1 illustrates an IMS based PSS and MBMS user service functional architecture. Functional blocks that can facilitate the switching between the MBMS download and HTTP- based DASH delivery can include IM CN subsystem 220, the UE 210, the SCF 230, the HTTP/SIP adapter 250, the HTTP server 260, the BMSC.UPF 240, a policy and charging rules function (PCRF) 270 module, service selection function (SSF) 290 module, and a PSS adapter 292. Another functional block IMS based PSS and MBMS user service functional architecture can be an evolved packet core (EPC)/packet-switch streaming (PS)/RAN 280. An EPC or system architecture evolution (SAE) can include a mobility management entity (MME), a serving gateway (SGW), and packet data network (PDN) gateway (PGW).
The IM CN subsystem 220 can support user registration and authentication, mobility and roaming, control of multimedia sessions, quality of service (QoS) control, policy control, charging, and/or interworking with circuit switched networks. The UE 210 can contain the generic bootstrapping architecture (GBA)/IMS/PSS/MBMS clients, which can perform service discovery and selection, handle service initiation, modification and termination, and/or receive and present the content to the user.
The SCF 230 can provide service logic and functions to support the execution of such service logic. The SCF can provide service authorization during session initiation and session modification, which can include checking the PSS and the MBMS user's service subscription in order to allow or deny access to the service. The SCF can select the relevant PSS and MBMS media functions. For HTTP-based delivery, the SCF can act as a proxy or back-to-back user agent (B2BUA). For MBMS, the SCF can act as a terminating user agent (UA). The HTTP/SIP adapter 250 can correlate a SIP session with HTTP incoming requests. The HTTP server 260 can provide the DASH formatted content for the HTTP-based delivery. The PCRF 270 module can control the charging and the establishment of resources in the RAN and PS core network 280. The SSF 290 module can provide a list of available PSS (including HTTP-based DASH) and MBMS user services and relevant user service description information. The SSF module can be personalized to the client's identity. The PSS adapter 292 can performs bi-directional protocol translation between SIP and RTSP to offer control of PSS servers. The BMSC.UPF 240 can include broadcast multicast service center (BMSC) user plane sub-functions (UPF). The BMSC.UPF can provide the DASH formatted content for the MBMS download.
FIG. 2 illustrates the BMSC sub-functional architecture and associated interfaces between the UE and BMSC. The BMSC or BM-SC 242 can be in communication with and/or control a content provider/multicast broadcast source 246. The BM-SC can provide the MBMS delivery functions 244.
FIG. 3 illustrates an example of switching from a MBMS download to an HTTP-based delivery of DASH formatted content in an IMS-based content delivery session. A FLUTE-based MBMS download 300a-c delivery may have been previously initiated and the UE 210 may be receiving the DASH-formatted content from the BMSC.UPF 240. The MBMS download can be a mechanism used by a MBMS user service to deliver content. The MBMS download can refer to a MBMS delivery method that uses MBMS bearers in delivering content and may make use of associated procedures. The MBMS download method used herein can be applicable for both delivery of continuous media (e.g. real-time video) or delivery of discrete objects (e.g. files).
The UE 210 may start HTTP streaming by fetching media segments from the HTTP server after obtaining an MPD. In order to switch from the MBMS download to HTTP-based delivery of DASH formatted content, a session initiation protocol (SIP) Re-INVITE 302 can be issued by the UE and sent to the IM CN subsystem 220. A session description protocol (SDP) offer and a request uniform resource identifier (URI) can be included in the SIP Re-LNVITE message.
The request URI can be related to the HTTP -based delivery session or a SIP session that a user wishes to activate. The request URI can be composed of a user part and domain part. The user part can contain the content identifier, retrieved from user service description information from the SSF module. The content identifier can be retrieved from service selection information. The domain part can include the service provider domain name, obtained from the SSF module. The 'To' header of a SIP Re-INVITE 302 and 304 or INVITE 306 message can contain the same URI as in the request URI. The 'From' header of a SIP Re-INVITE or INVITE message can indicate a public user identity of the user. The content identifier can be retrieved from the service selection information.
The SDP offer can include the media capabilities and policies available for the HTTP streaming session. For example, the SDP offer can carry the parameters indicating the type of the recommended service, (e.g. PSS, MBMS, or HTTP streaming service), the content identifier, and the identifier of a target UE. The SDP offer may be derived based on the analysis of the
MPD as well as based on parameters received from the SSF module during the service selection procedure. The SDP offer may be derived based on parameters received during a procedure for retrieving missing parameters by a SIP OPTIONS message.
A request to the HTTP server for the MPD may not be necessary as the UE may already have fetched the MPD during the MBMS download. In an example, if the MPD has not been previously obtained, the UE may send an HTTP GET request to the HTTP server in order to download the MPD. In another example, the SDP offer may include previously negotiated media descriptions with a port set to zero and two or more additional media descriptions. For instance, the media descriptions can include a media control channel (i.e., MPD delivery channel) and a media delivery channel (i.e. delivery channel for the unicast streams over HTTP). The SDP offer can include information for the HTTP -based delivery, such as a media description, a media control channel, a media delivery channel, a MPD control channel, a delivery channel for a unicast stream over HTTP, media capabilities available at the HTTP server, policies available at the HTTP server, and a combination of this information.
In another example, the SDP offer for media delivery may be similar to a previous SDP offer done for broadcast in terms of codecs and a transport protocol. The HTTP-based delivery can run on top of TCP whereas FLUTE-based MBMS download delivery can run on top of user datagram protocol (UDP). TCP and UDP can be protocols in the transport layer. The change in the underlying protocol, such as UDP to TCP, can be indicated in the SDP. UDP is one of the members of the Internet Protocol Suite. With UDP, computer applications can send messages, referred to as datagrams, to other hosts on an IP network without requiring prior communications to set up special transmission channels or data paths.
The IM CN subsystem 220 may forward the SIP Re-INVITE 304 message to the SCF
230. When receiving the SIP modification request in the SIP Re-INVITE, the SCF can determine if the program currently broadcasted has MBMS to HTTP switching support (a MBMS-to-HTTP switching support). If MBMS to HTTP switching is not available for the UE 210, the session modification can be rejected and the original MBMS download or session (along with the previous reserved resources) may be maintained.
If MBMS to HTTP switching is available for the UE 210, the SCF 230 can act as a B2BUA. Upon reception of the SIP Re-INVITE 304 from the UE, the SCF can check or verify the user rights for the requested DASH formatted content, identify that the request is for HTTP streaming, select an HTTP/SIP adapter 250, and forward the SIP request (a SIP INVITE 306) to the HTTP/SIP adapter which can be in charge of the HTTP streaming service by changing the request URI accordingly. When receiving a 301 or 302 response from the HTTP/SIP adapter, the SCF may not forward the 301 or 302 response message to the UE. The HTTP/SIP adapter can return a 301 response if the content requested is not managed by this HTTP/SIP adapter. The HTTP/SIP adapter can return a 302 response for any other reasons, other than not managing the content request (a 301 response). For instance, a 302 response message may be sent for a reason such as load balancing.
If the request URI contains a content identifier in the user part and a domain name in the domain part, the SCF 230 can select a suitable HTTP/SIP adapter 250 and generate a SIP INVITE 306 request to the selected HTTP/SIP adapter. The 'To' header of the SIP INVITE request can contain the same content identifier as in the request URI of the SIP modification request received from the UE 210 by the SCF.
The SCF 230 can send the SIP INVITE 306 request to the HTTP/SIP adapter 250 with the SDP parameters including the media capabilities and policies available for the HTTP streaming session. The SIP INVITE request may be derived based on the analysis of the MPD. In an example, the SDP offer may include previously negotiated media descriptions with a port set to zero and two or more additional media descriptions. For example, the media descriptions can include a media control channel (i.e., MPD delivery channel) and a media delivery channel (i.e. delivery channel for the unicast streams over HTTP).
The SCF 230 can tear down the FLUTE-based MBMS download session between the BMSC.UPF 240 and the UE 210. The SCF can send a MBMS termination 310 request or message to the BMSC.UPF. The communication protocol between the SCF and the BMSC.UPF can be defined by 3 GPP technical specification (TS) 26.346 VIO.0.0 published March 2011. The BMSC.UPF may release any content provider/multicast broadcast source (246 of FIG. 2) and terminate the MBMS download. The BMSC.UPF can send an acknowledgement (ACK) 312 message to the SCF indicating a successful termination or send a negative acknowledgement (NACK) message to the SCF indicating a failed termination or release of resources.
Upon reception of the HTTP streaming session initiation request (e.g., SIP INVITE 306), the HTTP/SIP adapter 250 can examine the content identifier present in the user part of the 'To' header and the media parameters in the SDP and select an HTTP server 260 according to the request URI. The HTTP/SIP adapter can send an HTTP POST message to the HTTP server including the IP address of the UE. The HTTP/SIP adapter may decide to redirect the request to another HTTP/SIP adapter server. In the case of a redirect the request to another HTTP/SIP adapter server, the HTTP/SIP adapter can return a 301 response if the content is not managed by this HTTP/SIP adapter or a 302 response for any other reasons, such as load balancing. The redirecting HTTP/SIP adapter can indicate one or more destination HTTP/SIP adapter addresses in the contact header.
The HTTP/SIP adapter 250 can return an SIP acknowledgement message, such as a SIP OK 308 message (e.g., a SIP 200 OK message), to the SCF 230. The SIP acknowledgement can include a SDP answer. The SDP answer can describe the HTTP streaming session (or the SIP session). The SDP answer can include information for the HTTP -based delivery, such as a media description, a media control channel, a media delivery channel, a media presentation description (MPD) control channel, a delivery description, and a combination of this information.
The SCF 230 can forward the SIP OK 314 to the IM CN subsystem 220. The IM CN subsystem can interact with the policy charging and rules function (PCRF) 270 module of the policy charging and control (PCC) architecture to commit the QoS reservation for QoS bearer enforcement 316a. The PCRF module can provide QoS bearer enforcement 316b-d between the UE and the IMS. The IM CN subsystem can then forward the SIP OK 318 (e.g., a SIP 200 OK message) to the UE 210.
The proxy call session control function (P-CSCF) can be used as the application function in the PCC architecture. The PCRF 270 can decide how policy control of the QoS is performed for an IMS initiated and controlled PSS and MBMS user service. The PCRF can use the SDP received from the P-CSCF during session establishment to calculate a proper QoS authorization. The appropriate existing bearers can be used or new required bearers can be allocated by the PCRF. Network initiated bearer control and UE initiated bearer control may be possible. When receiving a final SDP, the UE 210 may initiate the establishment of the required bearers unless a network initiated bearer allocation procedure is already ongoing. Alternatively, the UE has been configured to use network initiated resource control.
After receiving the SIP OK 318, the UE 210 can leave the multicast channel and can start downloading DASH-formatted content over HTTP (adaptive HTTP-based DASH content delivery 320a-c), such that the media segments can be delivered to the UE using the reserved QoS.
In another example, an air interface between a mobile device, such as a UE, and a transmission station, such as an eNB, may support unicast and multicast delivery of content to allow the switching between the MBMS download and the HTTP-based delivery of DASH formatted content. The eNB of the RAN can be in communication with the IMS and modules within the IMS, such as the SCF module. The air interface can include the 3 GPP LTE or the 802.16 standard. The mobile device and/or the transmission station can use the 3GPP LTE or the 802.16 protocol. The 3 GPP LTE standard can include LTE Rel-8 (2008), LTE Rel-9 (2009), and LTE Rel-10 (2011). The IEEE 802.16 standard can include IEEE 802.16e-2005, IEEE 802.16k- 2007, IEEE 802.16-2009, IEEE 802.16j-2009, IEEE 802.16h-2010, and IEEE 802.16m-2011.
FIG. 4 illustrates an example of switching from a MBMS download to an HTTP-based delivery of DASH formatted content in a content delivery session, where a MPD metadata file is obtained prior to a SIP Re-INVITE. The UE 210 can make a request for the MPD 322 from the HTTP server 260. The HTTP server can send the MPD 324 to the UE. The UE can use the information in the MPD to generate the SIP Re-TNVITE 302 to be sent to the IM CN subsystem 220. The rest of the operations in FIG. 4 can be similar to the operations of FIG. 3, which were previously discussed.
FIG. 5 illustrates an example of switching from HTTP -based delivery to MBMS download of DASH formatted content in a content delivery session. An HTTP -based delivery (e.g., adaptive HTTP -based DASH content delivery 330a-c) may have been previously initiated and the UE 210 may be receiving the DASH-formatted content over HTTP from the HTTP server 260. The DASH formatted content may be delivered in an existing SIP session.
In order to switch from HTTP-based delivery to MBMS download reception of DASH formatted content, a session modification request, such as SIP Re-INVITE 332, can be issued by the UE 210 and sent to the IM CN subsystem 220. A session description protocol (SDP) offer indicating the chosen MBMS download service and FLUTE session information and a request uniform resource identifier (URI) can be included in the SIP Re-INVITE message. The SDP offer can be performed in accordance with the parameters received during a UE service selection procedure and with media capabilities and required bandwidth available for the MBMS download service. In an example, the SDP offer for media delivery may be similar to the previous SDP offer performed for HTTP-based delivery in terms of codecs and transport protocol. The SDP offer can include information for the MBMS download, such as a media description, a media control channel, a media delivery channel, a MPD control channel, a delivery channel for a multicast stream over MBMS, media capabilities available at the BMSC, policies available at the BMSC, and a combination of this information.
In another example, the MPD may include information to switch from HTTP-based delivery to MBMS download delivery and the UE may utilize such information when issuing the session modification request, e.g., SIP Re-INVITE, to switch to the MBMS download. The SIP Re-INVITE message can also contain the request URI which can include the public service identifier (PSI) of a MBMS download service. The 'To' header of the SIP Re-INVITE can contain the same URI as in the request URI and the 'From' header of the SIP Re-INVITE can indicate the public user identity of the user.
The IM CN subsystem 220 can forward the SIP Re-INVITE 334 message to the SCF
230. Upon receipt of SIP Re-INVITE request, the SCF can perform service authorization procedures to check the service rights of requested MBMS download service according to the user subscription information. When receiving the SIP modification request (e.g., SIP Re-INVITE), the SCF 230 can determine if the content currently delivered has HTTP to MBMS switching support (e.g., an HTTP-to-MBMS switching support). If HTTP to MBMS switching is not available for the UE 210, the session modification can be rejected and the original HTTP session (along with the previous reserved resources) may be maintained. If HTTP to MBMS switching is available for the UE, the SCF can act as a B2BUA to establish the FLUTE-based MBMS download session between the BMSC.UPF and UE. The communication protocol between the SCF and the BMSC.UPF can be defined by 3 GPP technical specification (TS) 26.346 VIO.0.0 published March 2011. The SCF can send a MBMS invitation 340 to the BMSC.UPF. When the BMSC.UPF is setup for the MBMS download, the BMSC.UPF can send a MBMS
acknowledgement 342 message to the SCF. If HTTP to MBMS switching is available for the UE, the SCF can send a SIP BYE 336 message (an HTTP termination request) to the HTTP/SIP adapter 250 to terminate the SIP session between the SCF and the HTTP/SIP adapter.
The HTTP/SIP adapter 250 can then release the HTTP server 260, and can send a SIP acknowledgement message, such as a SIP OK 338 message, to the SCF 230. Once receiving a SIP OK message from HTTP adapter, the SCF can send a SIP OK 344 message to IM CN subsystem 220. The SIP acknowledgement can include a SDP answer. The SDP answer can include information for the MBMS download, such as a media description, a media control channel, a media delivery channel, a media presentation description (MPD) control channel, a delivery description, and a combination of this information.
The IM CN subsystem 220 can forward the SIP OK 348 message to the UE 210. The SIP OK message can include the SDP answer. The P-CSCF can be used as the application function in the PCC architecture. The PCRF can decide how policy control of the QoS is performed for the IMS initiated and controlled MBMS user service and communication for QoS bearer enforcement 346a-d (similar to the process for QoS bearer enforcement 316a-d illustrated in FIG. 3 between the IM CN subsystem, the PCRF module, and the UE). For a switch to the MBMS download, the PCRF may not initiate the establishment of a specific bearer.
Once the UE 210 receives the SIP OK response, the UE can activate a corresponding MBMS user service as described in the SDP, such as the MBMS download service based on FLUTE 350a-c. The MBMS download reception initiation may correspond to the MBMS broadcast mode activation procedure or the MBMS multicast mode activation procedure. The UE can examine the FLUTE session parameters in the received SDP, and receive the MBMS download data accordingly. In the case where a file delivery table (FDT) may be unavailable, the UE can get the FDT according to an fdt address attribute in the SDP answer. The FDT can contain content description information for the files delivered in the FLUTE session. In the case of an incomplete download, the UE can execute the file repair procedures towards the repair server indicated by a repair-server-address attribute in the SDP answer.
The switching between the MBMS download and the HTTP-based delivery can be agnostic of specific air interface (e.g., RAN) characteristics. Any air interface or combination of multiple air interfaces may be applicable as long as associated networks can host the IMS-based HTTP delivery and MBMS download delivery functions. The switching between the MBMS download and the HTTP-based delivery can be used in 3GPP-based or 802.16-based wireless wide area networks (WWANs), and IMS-based applications, where optimized delivery of
DASH-formatted multimedia content over these networks is desired. The signaling procedures for enabling the switching between HTTP -based delivery and MBMS download delivery for streaming DASH formatted content can improve the quality of experience for the user.
Another example provides a method 500 for switching from a multimedia broadcast multicast services (MBMS) download to a hypertext transfer protocol (HTTP)-based delivery of dynamic adaptive streaming over HTTP (DASH) formatted content, as shown in the flow chart in FIG. 6. The method includes the operation of receiving a session initiation protocol (SIP) re- invitation at a service control function (SCF) module from a mobile device while the mobile device is receiving a MBMS download in a content delivery session including DASH formatted content, as in block 510. The operation of sending a SIP invitation from the SCF module to an HTTP/SIP adapter to select an HTTP server for an HTTP -based delivery follows, as in block 520. The next operation of the method can be receiving a SIP acknowledgement at the SCF module from the HTTP/SIP adapter indicating a selection of the HTTP server for the content delivery session, as in block 530. The method can further include forwarding the SIP acknowledgement from the SCF module to the mobile device indicating a switch to the HTTP server for the content delivery session, as in block 540.
Another example provides a method 600 for switching from a hypertext transfer protocol (HTTP)-based delivery of dynamic adaptive streaming over HTTP (DASH) formatted content to a multimedia broadcast multicast services (MBMS) download, as shown in the flow chart in FIG. 7. The method includes the operation of receiving a session initiation protocol (SIP) re-invitation at a service control function (SCF) module from a mobile device while the mobile device is receiving an HTTP-based delivery in a content delivery session including DASH formatted content, as in block 610. The operation of sending an invitation message from the SCF module to the BMSC to initialize a broadcast multicast service center (BMSC) for a MBMS download follows, as in block 620. The next operation of the method can be sending a SIP termination request from the SCF module to an HTTP/SIP adapter to terminate the HTTP- based delivery, as in block 630. The operation of receiving a SIP acknowledgement at the SCF module from the HTTP/SIP adapter indicating a termination of the HTTP-based delivery follows, as in block 640. The method can further include forwarding the SIP acknowledgement from the SCF module to the mobile device indicating a switch to the BMSC for the content delivery session, as in block 650.
In another example, the SCF can include a transceiver module configured to receive a multicast-to-unicast session modification request, where the transceiver can perform the operations related to the SCF illustrated in FIG. 3. The transceiver module of the SCF can be configured to receive a unicast-to-multicast session modification request, where the transceiver can perform the operations related to the SCF illustrated in FIG. 5.
In another example, the mobile device can include a transceiver configured to send a multicast-to-unicast session modification request to an IM CN subsystem, where the transceiver can perform the operations related to the mobile device illustrated in FIG. 3. The transceiver module of the SCF can be configured to send a unicast-to-multicast session modification request, where the transceiver can perform the operations related to the mobile device illustrated in FIG. 5. The transceiver can be configured to receive a SIP acknowledgement or SIP termination message from the IM CN subsystem. The mobile device can include a processing module configured to switch between the MBMS download and the HTTP-based delivery for the DASH formatted content.
In another example, a transmission station can be in wireless communication with a mobile device. FIG. 8 provides an example illustration of the mobile device, such as a user equipment (UE), a mobile station (MS), a mobile wireless device, a mobile communication device, a tablet, a handset, or other type of mobile wireless device. The mobile device can include one or more antennas configured to communicate with a node, macro node, low power node (LPN), or, transmission station, such as a base station (BS), an evolved Node B (eNB), a base band unit (BBU), a remote radio head (RRH), a remote radio equipment (RRE), a relay station (RS), a radio equipment (RE), or other type of wireless wide area network (WWAN) access point. The mobile device can be configured to communicate using at least one wireless communication standard including 3 GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi. The mobile device can communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards. The mobile device can communicate in a wireless local area network (WLAN), a wireless personal area network (WPAN), and/or a WWAN.
FIG. 8 also provides an illustration of a microphone and one or more speakers that can be used for audio input and output from the mobile device. The display screen may be a liquid crystal display (LCD) screen, or other type of display screen such as an organic light emitting diode (OLED) display. The display screen can be configured as a touch screen. The touch screen may use capacitive, resistive, or another type of touch screen technology. An application processor and a graphics processor can be coupled to internal memory to provide processing and display capabilities. A non- volatile memory port can also be used to provide data input/output options to a user. The non- volatile memory port may also be used to expand the memory capabilities of the mobile device. A keyboard may be integrated with the mobile device or wirelessly connected to the mobile device to provide additional user input. A virtual keyboard may also be provided using the touch screen.
Various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD- ROMs, hard drives, non-transitory computer readable storage medium, or any other machine- readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. In the case of program code execution on programmable computers, the computing device may include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements may be a RAM, EPROM, flash drive, optical drive, magnetic hard drive, or other medium for storing electronic data. The base station and mobile station may also include a transceiver module, a counter module, a processing module, and/or a clock module or timer module. One or more programs that may implement or utilize the various techniques described herein may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.
It should be understood that many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.
Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The modules may be passive or active, including agents operable to perform desired functions.
Reference throughout this specification to "an example" means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment of the present invention. Thus, appearances of the phrases "in an example" in various places throughout this specification are not necessarily all referring to the same embodiment.
As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. In addition, various embodiments and example of the present invention may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as defacto equivalents of one another, but are to be considered as separate and autonomous representations of the present invention.
Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of layouts, distances, network examples, etc., to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, layouts, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
While the forgoing examples are illustrative of the principles of the present invention in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation can be made without the exercise of inventive faculty, and without departing from the principles and concepts of the invention. Accordingly, it is not intended that the invention be limited, except as by the claims set forth below.

Claims

CLAIMS What is claimed is:
1. A computer program product, comprising a non-transitory computer readable storage medium having a computer readable program code embodied therein, the computer readable program code adapted to be executed to implement a method for switching from a multimedia broadcast multicast services (MBMS) download to a hypertext transfer protocol (HTTP)-based delivery of dynamic adaptive streaming over HTTP (DASH) formatted content, comprising:
receiving a session initiation protocol (SIP) re-invitation at a service control function (SCF) module from a mobile device while the mobile device is receiving a MBMS download in a content delivery session including DASH formatted content; sending a SIP invitation from the SCF module to an HTTP/SIP adapter to select an HTTP server for an HTTP-based delivery;
receiving a SIP acknowledgement at the SCF module from the HTTP/SIP adapter indicating a selection of the HTTP server for the content delivery session; and forwarding the SIP acknowledgement from the SCF module to the mobile device indicating a switch to the HTTP server for the content delivery session.
2. The computer program product of claim 1, further comprising sending a termination request from the SCF module to a broadcast multicast service center (BMSC) to terminate the MBMS download after receiving the SIP re-invitation at the SCF module.
3. The computer program product of claim 1 , wherein the SCF module previously
referenced a domain name or a content identifier associated with a broadcast multicast service center (BMSC) providing the DASH formatted content via the MBMS download in the content delivery session when the mobile device is receiving the MBMS download, and the SIP re-invitation includes a request uniform resource identifier (URI) for the HTTP server to provide DASH formatted content via the HTTP -based delivery in the same content delivery session, and the HTTP server for the HTTP-based delivery is selected based on a domain name or a content identifier included in the request URI referencing the HTTP server, and the domain name and the content identifier referencing the HTTP server differs from the domain name and the content identifier associated with the BMSC.
4. The computer program product of claim 1, further comprising determining at the SCF module if the content delivery session has a MBMS-to-HTTP switching support prior to sending the SIP invitation from the SCF module to an HTTP/SIP adapter.
5. The computer program product of claim 1, wherein the SIP re-invitation is received at the SCF module from the mobile device via an internet protocol (IP) multimedia subsystem (IMS) core network (IM CN) subsystem, and the SIP acknowledgement is forwarded from the SCF module to the mobile device via the IM CN subsystem.
6. The computer program product of claim 1, wherein an air interface between the mobile device and a transmission station of a radio access network (RAN) in communication with the SCF module supports unicast and multicast delivery of content.
7. The computer program product of claim 1 , wherein the mobile device uses a protocol selected from the group consisting of a third generation partnership project (3GPP) long term evolution (LTE) standard and an Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard.
8. The computer program product of claim 1, wherein the SIP acknowledgement includes a session description protocol (SDP) answer that includes information for the HTTP-based delivery selected from the group consisting of a media description, a media control channel, a media delivery channel, a media presentation description (MPD) control channel, a delivery description, and combinations thereof.
9. The computer program product of claim 1, wherein the SIP re-invitation includes a
session description protocol (SDP) offer that includes information for the HTTP-based delivery selected from the group consisting of a media description, a media control channel, a media delivery channel, a media presentation description (MPD) control channel, a delivery channel for a unicast stream over HTTP, media capabilities available at the HTTP server, policies available at the HTTP server, codecs and transport protocols, and combinations thereof.
10. The computer program product of claim 9, wherein the media capabilities and policies available at the HTTP server for the HTTP streaming session are obtained during MBMS download from a previously received MPD metadata file.
1 1. The computer program product of claim 1, further comprising verifying the user rights for the DASH formatted content via an HTTP -based delivery before sending the SIP invitation from the SCF module to the HTTP/SIP adapter.
12. The computer program product of claim 1, wherein the SIP re-invitation includes a SIP Re-TNVITE message, the SIP invitation includes a SIP INVITE message, and the SIP acknowledgement includes a SIP 200 OK.
13. The computer program product of claim 1, wherein the HTTP-based delivery operates using a transmission control protocol (TCP) in the transport layer, and the MBMS download operates using a user datagram protocol (UDP) in the transport layer and a file delivery over unidirectional transport (FLUTE) protocol.
14. The computer program product of claim 1, wherein the SCF module is included in an internet protocol (IP) multimedia subsystem (IMS).
15. A computer program product, comprising a non-transitory computer readable storage medium having a computer readable program code embodied therein, the computer readable program code adapted to be executed to implement a method for switching from a hypertext transfer protocol (HTTP)-based delivery of dynamic adaptive streaming over HTTP (DASH) formatted content to a multimedia broadcast multicast services (MBMS) download, comprising:
receiving a session initiation protocol (SIP) re-invitation at a service control function (SCF) module from a mobile device while the mobile device is receiving an HTTP-based delivery in a content delivery session including DASH formatted content;
sending an invitation message from the SCF module to a broadcast multicast service center (BMSC) to initialize the BMSC for a MBMS download of the content delivery session;
sending a SIP termination request from the SCF module to an HTTP/SIP adapter to terminate the HTTP-based delivery; receiving a SIP acknowledgement at the SCF module from the HTTP/SIP adapter indicating a termination of the HTTP-based delivery; and
forwarding the SIP acknowledgement from the SCF module to the mobile device indicating a switch to the BMSC for the content delivery session.
16. The computer program product of claim 15, further comprising receiving a BMSC
acknowledgement at the SCF module from the BMSC indicating a selection of the BMSC for the content delivery session after sending the invitation message from the SCF module to the BMSC.
17. The computer program product of claim 15, wherein the SCF module previously
referenced a domain name or a content identifier associated with an HTTP server providing the DASH formatted content via the HTTP-based delivery in the content delivery session when the mobile device is receiving the HTTP-based delivery, and the SIP re-invitation includes a request uniform resource identifier (URI) for the BMSC to provide DASH formatted content via the MBMS download in the same content delivery session, and the different request URI is used to select the BMSC for the MBMS download of the content delivery session, and the BMSC for the MBMS download is selected based on a domain name or a content identifier included in the request URI referencing the BMSC, and the domain name and the content identifier associated with the HTTP server differs from the domain name and the content identifier referencing the BMSC.
18. The computer program product of claim 15, wherein an air interface between the mobile device and a transmission station of a radio access network (RAN) in communication with the SCF module supports unicast and multicast delivery of content.
19. The computer program product of claim 15, wherein the mobile device uses a protocol selected from the group consisting of a third generation partnership project (3GPP) long term evolution (LTE) standard and an Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard.
20. The computer program product of claim 15, wherein the SIP re-invitation includes a session description protocol (SDP) offer that includes information for the MBMS download selected from the group consisting of a media description, a media control channel, a media delivery channel, a media presentation description (MPD) control channel, a delivery channel for a multicast stream over MBMS, media capabilities available at the BMSC, policies available at the BMSC, codecs and transport protocols, and combinations thereof.
21. The computer program product of claim 15, wherein the SIP acknowledgement
forwarded from the SCF module includes a session description protocol (SDP) answer that includes information for the MBMS download selected from the group consisting of a media description, a media control channel, a media delivery channel, a media presentation description (MPD) control channel, a delivery description, codecs and transport protocols, and combinations thereof.
22. The computer program product of claim 15, further comprising performing a service authorization procedure to check service rights of the DASH formatted content via the MBMS download according to user subscription information before sending the invitation message from the SCF module to the BMSC.
23. The computer program product of claim 15, wherein the SIP re-invitation includes a SIP Re-TNVITE message, the SIP termination includes a SIP BYE message, and the SIP acknowledgement includes a SIP 200 OK message.
24. The computer program product of claim 15, wherein the HTTP-based delivery operates using a transmission control protocol (TCP) in the transport layer, and the MBMS download operates using a user datagram protocol (UDP) in the transport layer and a file delivery over unidirectional transport (FLUTE) protocol.
25. A service control function (SCF) module in an internet protocol (IP) multimedia
subsystem (IMS), comprising:
a transceiver module configured to receive a multicast-to-unicast session modification request from a mobile device after a prior multicast request uniform resource identifier (URI) referenced a broadcast multicast service center (BMSC) providing DASH formatted content via a multimedia broadcast multicast services (MBMS) download in a content delivery session, wherein the multicast-to-unicast session modification request includes a unicast request URI for an HTTP server to provide DASH formatted content via an HTTP-based delivery in the same content delivery session;
the transceiver module further configured to receive a unicast-to-multicast session modification request from the mobile device after a prior unicast request URI referenced the HTTP server providing DASH formatted content via the HTTP -based delivery in the content delivery session, wherein the unicast-to-multicast session modification request includes a multicast request URI for the BMSC to provide DASH formatted content via the MBMS download in the same content delivery session;
the transceiver module further configured to send the multicast-to-unicast session modification request to an HTTP/SIP adapter to select the HTTP server for the HTTP-based delivery, and send the unicast-to-multicast session modification request to the BMSC to initialize the BMSC for the MBMS download;
the transceiver module further configured to send an HTTP termination request to an HTTP/SIP adapter to terminate the HTTP -based delivery, and send a MBMS termination request to the BMSC to terminate the MBMS download;
the transceiver module further configured to receive a SIP acknowledgement from the HTTP/SIP adapter indicating a selection of the HTTP server for the content delivery session, receive a BMSC acknowledgement from the BMSC indicating a selection of the BMSC for the content delivery session, and receive a SIP termination message from the HTTP/SIP adapter indicating a termination of the HTTP-based delivery; and
the transceiver module further configured to forward the SIP acknowledgement from the SCF module to the mobile device indicating a switch to the HTTP server for the content delivery session, and forward the SIP termination message to the mobile device indicating a switch to the BMSC for the content delivery session.
26. The SCF module of claim 25, further comprising a processing module configured to verify the user rights for the DASH formatted content via an HTTP-based delivery and perform a service authorization procedure to check service rights of the DASH formatted content via the MBMS download according to user subscription information.
27. A mobile device configured for switching between a multicast download and a unicast delivery of dynamic adaptive streaming over HTTP (DASH) formatted content, comprising:
a transceiver configured to send a multicast-to-unicast session modification request to an internet protocol (IP) multimedia subsystem (IMS) core network (IM CN) subsystem while receiving DASH formatted content via a multimedia broadcast multicast services (MBMS) download in a content delivery session, wherein the multicast-to-unicast session modification request includes a unicast request URI for an HTTP server to provide DASH formatted content via an HTTP-based delivery in the same content delivery session;
the transceiver further configured to send a unicast-to-multicast session modification request to the IM CN subsystem while receiving DASH formatted content via the HTTP-based delivery in the content delivery session, wherein the unicast-to-multicast session modification request includes a multicast request URI for a broadcast multicast service center (BMSC) to provide DASH formatted content via the MBMS download in the same content delivery session;
the transceiver further configured to receive the SIP acknowledgement from the IM CN subsystem indicating a switch to the HTTP server for the content delivery session, and receive a SIP termination message from the IM CN subsystem indicating a switch to the BMSC for the content delivery session; and
a processing module configured to switch between the MBMS download and the HTTP-based delivery for the DASH formatted content.
28. The mobile device of claim 27, wherein the mobile device communicates with the IM CN subsystem via an air interface supporting unicast and multicast delivery of content.
29. The mobile device of claim 27, wherein the mobile device uses a protocol selected from the group consisting of a third generation partnership project (3 GPP) long term evolution (LTE) standard and an Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard.
30. The mobile device of claim 27, wherein the mobile device is configured to connect to at least one of a wireless local area network (WLAN), a wireless personal area network (WPAN), and a wireless wide area network (WWAN), and the mobile device includes an antenna, a touch sensitive display screen, a speaker, a microphone, a graphics processor, an application processor, internal memory, a non-volatile memory port, or combinations thereof.
PCT/US2011/065586 2011-08-11 2011-12-16 Methods for switching between a mbms download and an http-based delivery of dash formatted content over an ims network WO2013022470A1 (en)

Priority Applications (10)

Application Number Priority Date Filing Date Title
JP2014525000A JP5706046B2 (en) 2011-08-11 2011-12-16 Method for switching between DMS formatted content on an IMS network between MBMS download and HTTP based distribution
BR112014003030-8A BR112014003030B1 (en) 2011-08-11 2011-12-16 METHOD FOR SWITCHING FROM A DOWNLOAD OF MBMS TO AN HTTP-BASED DELIVERY OF DASH FORMATTED CONTENT, METHOD OF SWITCHING FROM AN HTTP-BASED DELIVERY OF DASH FORMATTED CONTENT TO A DOWNLOAD OF MBMS AND MOBILE DEVICE
CN201180073198.0A CN103748810B (en) 2011-08-11 2011-12-16 Methods and equipment for switching from a mbms download to an http-based delivery of dash formatted content
ES11870588.8T ES2574805T3 (en) 2011-08-11 2011-12-16 Methods for switching between an MBMS download and an HTTP-based delivery of content in DASH format over an IMS network
RU2014107662/07A RU2557256C1 (en) 2011-08-11 2011-12-16 Method for switching between mbms download and http-based delivery of dash formatted content over ims network
KR1020147005141A KR101497287B1 (en) 2011-08-11 2011-12-16 Methods for switching between a mbms download and an http-based delivery of dash formatted content over an ims network
US13/994,118 US9887852B2 (en) 2011-08-11 2011-12-16 Methods for switching between a MBMS download and an HTTP-based delivery of DASH formatted content over an IMS network
EP11870588.8A EP2742614B1 (en) 2011-08-11 2011-12-16 Methods for switching between a mbms download and an http-based delivery of dash formatted content over an ims network
US14/581,747 US9960926B2 (en) 2011-08-11 2014-12-23 Methods for switching between a MBMS download and an HTPP-based delivery of DASH formatted content over an IMS network
US15/881,620 US10778458B2 (en) 2011-08-11 2018-01-26 Methods for switching between a MBMS download and an HTPP-based delivery of DASH formatted content over an IMS network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161522623P 2011-08-11 2011-08-11
US61/522,623 2011-08-11

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US13/994,118 A-371-Of-International US9887852B2 (en) 2011-08-11 2011-12-16 Methods for switching between a MBMS download and an HTTP-based delivery of DASH formatted content over an IMS network
US14/581,747 Continuation US9960926B2 (en) 2011-08-11 2014-12-23 Methods for switching between a MBMS download and an HTPP-based delivery of DASH formatted content over an IMS network

Publications (1)

Publication Number Publication Date
WO2013022470A1 true WO2013022470A1 (en) 2013-02-14

Family

ID=47668759

Family Applications (3)

Application Number Title Priority Date Filing Date
PCT/US2011/065586 WO2013022470A1 (en) 2011-08-11 2011-12-16 Methods for switching between a mbms download and an http-based delivery of dash formatted content over an ims network
PCT/US2011/065838 WO2013022472A1 (en) 2011-08-11 2011-12-19 Technology for triggering groups of wireless devices
PCT/US2012/032922 WO2013106060A2 (en) 2011-08-11 2012-04-10 Reduced signaling overhead during radio resource control (rrc) state transitions

Family Applications After (2)

Application Number Title Priority Date Filing Date
PCT/US2011/065838 WO2013022472A1 (en) 2011-08-11 2011-12-19 Technology for triggering groups of wireless devices
PCT/US2012/032922 WO2013106060A2 (en) 2011-08-11 2012-04-10 Reduced signaling overhead during radio resource control (rrc) state transitions

Country Status (11)

Country Link
US (5) US9887852B2 (en)
EP (3) EP2742614B1 (en)
JP (2) JP5706046B2 (en)
KR (3) KR101497287B1 (en)
CN (3) CN103748810B (en)
BR (2) BR112014003030B1 (en)
ES (2) ES2574805T3 (en)
HU (2) HUE029183T2 (en)
IN (1) IN2014CN01083A (en)
RU (2) RU2557256C1 (en)
WO (3) WO2013022470A1 (en)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130246846A1 (en) * 2012-01-23 2013-09-19 Ozgur Oyman Ip multimedia subsystem and method for mbms file repair using http servers
US20140019587A1 (en) * 2012-07-11 2014-01-16 Futurewei Technologies, Inc. Dynamic Adaptive Streaming over Hypertext Transfer Protocol as Hybrid Multirate Media Description, Delivery, and Storage Format
WO2014168414A1 (en) * 2013-04-09 2014-10-16 Samsung Electronics Co., Ltd. Methods and apparatuses for dynamic content offloading
WO2015032032A1 (en) * 2013-09-03 2015-03-12 华为技术有限公司 Method and device for transmitting media stream and user equipment
CN105027499A (en) * 2013-04-04 2015-11-04 英特尔Ip公司 Internet protocol (IP) multimedia subsystem (IMS) based peer-to-peer (P2P) content distribution
US9197717B2 (en) 2013-11-27 2015-11-24 At&T Intellectual Property I, Lp Server-side scheduling for media transmissions according to client device states
EP2901619A4 (en) * 2012-09-28 2016-05-04 Intel Corp Ims based p2p streaming and download services
EP3001602A4 (en) * 2013-07-02 2016-06-01 Huawei Tech Co Ltd Method, related device and system supporting streaming media multicast
US9363333B2 (en) 2013-11-27 2016-06-07 At&T Intellectual Property I, Lp Server-side scheduling for media transmissions
CN105900445A (en) * 2014-01-16 2016-08-24 高通股份有限公司 Robust live operation of DASH
JP2016536914A (en) * 2013-09-13 2016-11-24 ホアウェイ・テクノロジーズ・カンパニー・リミテッド Streaming media transmission method and system, user equipment and server
US9560512B2 (en) 2013-02-22 2017-01-31 Intel IP Corporation Reporting of user plane congestion (UPCON) using a UPCON container
WO2017023462A1 (en) * 2015-08-04 2017-02-09 Qualcomm Incorporated Hybrid pocket router
KR20170130428A (en) * 2015-03-27 2017-11-28 퀄컴 인코포레이티드 Point-to-multipoint broadcast assisted vehicle-to-x broadcast
US9887852B2 (en) 2011-08-11 2018-02-06 Intel Corporation Methods for switching between a MBMS download and an HTTP-based delivery of DASH formatted content over an IMS network
JP2018186551A (en) * 2018-07-13 2018-11-22 ホアウェイ・テクノロジーズ・カンパニー・リミテッド Streaming media transmission method and system, user equipment, and server
EP3348081B1 (en) * 2015-09-08 2023-07-12 Telefonaktiebolaget LM Ericsson (publ) Streaming session continuation
US11824904B1 (en) 2022-11-18 2023-11-21 T-Mobile Usa, Inc. Verifying delivery of rich call data object to a terminating wireless device

Families Citing this family (91)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8472792B2 (en) 2003-12-08 2013-06-25 Divx, Llc Multimedia distribution system
US7519274B2 (en) 2003-12-08 2009-04-14 Divx, Inc. File format for multiple track digital data
WO2007106844A2 (en) 2006-03-14 2007-09-20 Divx, Inc. Federated digital rights management scheme including trusted systems
EP4184341A1 (en) 2007-01-05 2023-05-24 DivX, LLC Video distribution system including progressive playback
KR20100106327A (en) 2007-11-16 2010-10-01 디브이엑스, 인크. Hierarchical and reduced index structures for multimedia files
US8032164B2 (en) * 2008-09-22 2011-10-04 Interdigital Patent Holdings, Inc. Method and apparatus for communicating short message service and supplementary services messages
CA2782825C (en) 2009-12-04 2016-04-26 Divx, Llc Elementary bitstream cryptographic material transport systems and methods
US8914534B2 (en) 2011-01-05 2014-12-16 Sonic Ip, Inc. Systems and methods for adaptive bitrate streaming of media stored in matroska container files using hypertext transfer protocol
US9736619B2 (en) * 2011-05-11 2017-08-15 Lg Electronics Inc. Method and apparatus for MTC in a wireless communication system
US8812662B2 (en) 2011-06-29 2014-08-19 Sonic Ip, Inc. Systems and methods for estimating available bandwidth and performing initial stream selection when streaming content
US8879667B2 (en) 2011-07-01 2014-11-04 Intel Corporation Layer shifting in open loop multiple-input, multiple-output communications
US9590814B2 (en) * 2011-08-01 2017-03-07 Qualcomm Incorporated Method and apparatus for transport of dynamic adaptive streaming over HTTP (DASH) initialization segment description fragments as user service description fragments
EP2742748A4 (en) 2011-08-12 2015-08-26 Intel Corp System and method of uplink power control in a wireless communication system
CN108989847B (en) 2011-08-30 2021-03-09 帝威视有限公司 System and method for encoding and streaming video
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
US8787570B2 (en) 2011-08-31 2014-07-22 Sonic Ip, Inc. Systems and methods for automatically genenrating top level index files
US8799647B2 (en) 2011-08-31 2014-08-05 Sonic Ip, Inc. Systems and methods for application identification
US8964977B2 (en) 2011-09-01 2015-02-24 Sonic Ip, Inc. Systems and methods for saving encoded media streamed using adaptive bitrate streaming
US8909922B2 (en) 2011-09-01 2014-12-09 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US9877139B2 (en) 2011-10-03 2018-01-23 Intel Corporation Device to device (D2D) communication mechanisms
WO2013050216A1 (en) * 2011-10-04 2013-04-11 International Business Machines Corporation Pre-emptive content caching in mobile networks
US8774804B2 (en) * 2011-10-31 2014-07-08 Intel Corporation Context-retention controller and method for context retention in wirless access networks
CN103188725B (en) * 2011-12-29 2018-01-30 中兴通讯股份有限公司 A kind of adaptation of cooperation service, shunting transmission and stream switching method and system
CN103188616B (en) * 2011-12-31 2017-10-27 中兴通讯股份有限公司 The management method and system of a kind of set of terminal
US20130179199A1 (en) 2012-01-06 2013-07-11 Rovi Corp. Systems and methods for granting access to digital content using electronic tickets and ticket tokens
US8924581B1 (en) * 2012-03-14 2014-12-30 Amazon Technologies, Inc. Managing data transfer using streaming protocols
EP2837156B1 (en) * 2012-04-09 2018-08-22 Telefonaktiebolaget LM Ericsson (publ) Method, apparatus and computer readable medium for providing quality of service functionality supporting a plurality of different data streams in a single ims session for machine-to-machine mtm device communications
CN102710361B (en) * 2012-06-01 2015-09-30 华为技术有限公司 A kind of distributed base station signal transmission system and communication system
WO2013189031A1 (en) * 2012-06-19 2013-12-27 华为技术有限公司 Communication system, base station, user equipment and signalling transmission method
CN103517404B (en) * 2012-06-26 2018-08-31 南京中兴软件有限责任公司 The communication means and system of machine type communication user equipment
CN103517414A (en) * 2012-06-26 2014-01-15 中兴通讯股份有限公司 Method and apparatus for paging of machine type communication user equipment
EP2683202A3 (en) * 2012-07-03 2014-03-12 HTC Corporation A method of group based mtc messaging through cell broadcast and apparatuses using the same
US9936267B2 (en) 2012-08-31 2018-04-03 Divx Cf Holdings Llc System and method for decreasing an initial buffering period of an adaptive streaming system
JP6348251B2 (en) * 2012-09-13 2018-06-27 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ Terminal device, receiving method, and program
CN103906023B (en) * 2012-12-28 2019-06-18 中兴通讯股份有限公司 The processing method and processing device of the triggering information of machine type equipment MTC device
US9313510B2 (en) 2012-12-31 2016-04-12 Sonic Ip, Inc. Use of objective quality measures of streamed content to reduce streaming bandwidth
US9191457B2 (en) 2012-12-31 2015-11-17 Sonic Ip, Inc. Systems, methods, and media for controlling delivery of content
KR101685515B1 (en) * 2013-01-16 2016-12-13 후아웨이 테크놀러지 컴퍼니 리미티드 Storing and transmitting content for downloading and streaming
US9565228B2 (en) * 2013-03-01 2017-02-07 Comcast Cable Communications, Llc Streaming and downloading of content
US10397292B2 (en) 2013-03-15 2019-08-27 Divx, Llc Systems, methods, and media for delivery of content
US9668197B2 (en) 2013-04-10 2017-05-30 Huawei Technologies Co., Ltd. System and method for wireless network access MAP and applications
US9094737B2 (en) 2013-05-30 2015-07-28 Sonic Ip, Inc. Network video streaming with trick play based on separate trick play files
US9100687B2 (en) 2013-05-31 2015-08-04 Sonic Ip, Inc. Playback synchronization across playback devices
US9380099B2 (en) 2013-05-31 2016-06-28 Sonic Ip, Inc. Synchronizing multiple over the top streaming clients
TWI548260B (en) * 2013-06-14 2016-09-01 國立臺灣大學 A system and method of trigger service
US9271149B2 (en) * 2013-10-18 2016-02-23 Verizon Patent And Licensing Inc. Managing hidden security features in user equipment
US10045333B2 (en) * 2013-11-07 2018-08-07 Lg Electronics Inc. Method for updating terminal-centered coverage
US9386067B2 (en) 2013-12-30 2016-07-05 Sonic Ip, Inc. Systems and methods for playing adaptive bitrate streaming content by multicast
US9755901B2 (en) * 2014-01-21 2017-09-05 Huawei Technologies Co., Ltd. System and method for a software defined protocol network node
CN106105363B (en) * 2014-03-19 2020-04-10 诺基亚技术有限公司 Broadcast signaling optimization for machine type communications
US9866878B2 (en) 2014-04-05 2018-01-09 Sonic Ip, Inc. Systems and methods for encoding and playing back video at different frame rates using enhancement layers
US10057937B2 (en) * 2014-05-02 2018-08-21 Nokia Solutions And Networks Oy Communications via multiple access points
CN103929277A (en) * 2014-05-08 2014-07-16 北京华力创通科技股份有限公司 Message transmission method based on CBCH
KR102157185B1 (en) * 2014-07-04 2020-09-18 삼성전자주식회사 Apparatus and method for providing a service connection through access layer in wireless communication system
US9801228B2 (en) * 2014-07-22 2017-10-24 Intel IP Corporation Systems, apparatuses, and methods for lightweight over-the-air signaling mechanisms in data communications
SG11201609457UA (en) 2014-08-07 2016-12-29 Sonic Ip Inc Systems and methods for protecting elementary bitstreams incorporating independently encoded tiles
US9912985B2 (en) * 2014-09-26 2018-03-06 Intel Corporation Content distribution
DE102014221956A1 (en) * 2014-10-28 2016-05-12 Bayerische Motoren Werke Aktiengesellschaft Apparatus, vehicle, method and computer program for a relay transceiver and a network component
EP3197151B1 (en) * 2014-10-28 2019-08-14 Huawei Technologies Co. Ltd. Mosaic service presentation/delivery method and apparatus
US9723651B2 (en) * 2014-11-10 2017-08-01 Qualcomm Incorporated Enhanced connection management for multiple access networks
CN104540107A (en) * 2014-12-03 2015-04-22 东莞宇龙通信科技有限公司 Management method and management system for machine type communication (MTC) terminal cluster, and network side equipment
WO2016112112A1 (en) 2015-01-06 2016-07-14 Sonic Ip, Inc. Systems and methods for encoding and sharing content between devices
WO2016138493A1 (en) 2015-02-27 2016-09-01 Sonic Ip, Inc. Systems and methods for frame duplication and frame extension in live video encoding and streaming
CN106254300B (en) * 2015-06-08 2020-04-21 中兴通讯股份有限公司 Streaming media transmission method, playing method, transmission device and playing device
US10743209B2 (en) * 2015-08-05 2020-08-11 Nec Corporation Communication system, communication control apparatus, communication control method, and program
EP3360374B1 (en) * 2015-10-09 2020-03-25 Telefonaktiebolaget LM Ericsson (PUBL) Network node, wireless device and methods performed thereby for the network node to provide information to the wireless device
JP6751253B2 (en) * 2015-12-10 2020-09-02 セイコーエプソン株式会社 Electronic device, system including electronic device and management device, and method executed by electronic device
WO2017101028A1 (en) * 2015-12-15 2017-06-22 华为技术有限公司 Data transmission method, m2m server, pgw, sgw and serving network node
EP3408984B1 (en) 2016-01-25 2022-11-16 Telefonaktiebolaget LM Ericsson (publ) Key management for ciot
CN105848224A (en) * 2016-03-11 2016-08-10 深圳市金立通信设备有限公司 Cell switching method and system, and related devices
US10075292B2 (en) 2016-03-30 2018-09-11 Divx, Llc Systems and methods for quick start-up of playback
CN108476384B (en) 2016-04-01 2021-03-23 华为技术有限公司 Data transmission method and related device
CN109314878B (en) * 2016-04-08 2022-04-01 诺基亚技术有限公司 Method and apparatus for U-plane sub-service flow mapping
US10129574B2 (en) 2016-05-24 2018-11-13 Divx, Llc Systems and methods for providing variable speeds in a trick-play mode
US10231001B2 (en) 2016-05-24 2019-03-12 Divx, Llc Systems and methods for providing audio content during trick-play playback
US10148989B2 (en) 2016-06-15 2018-12-04 Divx, Llc Systems and methods for encoding video content
DK3429241T3 (en) 2016-06-24 2021-06-28 Guangdong Oppo Mobile Telecommunications Corp Ltd DATA TRANSMISSION PROCEDURE AND DEVICE
US11115793B2 (en) * 2016-08-04 2021-09-07 At&T Mobility Ii Llc LTE gateways for home and commercial sensor data
RU2727163C1 (en) 2016-09-30 2020-07-21 Телефонактиеболагет Лм Эрикссон (Пабл) Basic network awareness on user equipment (ue) state
US10542409B2 (en) * 2016-10-07 2020-01-21 Qualcomm Incorporated Access for group call services through a broadcast channel
KR102381335B1 (en) * 2016-10-18 2022-03-31 이엑스피웨이 How to deliver content to mobile user devices
US10498795B2 (en) 2017-02-17 2019-12-03 Divx, Llc Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming
EP3603178B1 (en) * 2017-03-23 2024-10-02 Nokia Technologies Oy Quality of service flow relocation
CN109548079A (en) * 2017-09-22 2019-03-29 中兴通讯股份有限公司 A kind of method and device for the user-plane function management resource indicating communication system
US10931725B2 (en) * 2017-09-29 2021-02-23 Apple Inc. Multiway audio-video conferencing
RU2746604C1 (en) * 2018-01-19 2021-04-16 Нокиа Текнолоджиз Ой Control plane signaling for integrated access nodes and transport network
US11917707B2 (en) 2018-11-01 2024-02-27 Telefonaktiebolaget Lm Ericsson (Publ) Handling of reestablishment failure ambiguity
EP4398582A3 (en) 2019-03-21 2024-08-07 DivX, LLC Systems and methods for multimedia swarms
CN110099061B (en) * 2019-05-07 2020-05-01 北京邮电大学 Cloud platform video streaming service selection method and device
CN114051750B (en) * 2019-05-31 2024-04-09 苹果公司 Systems and methods for performance data streaming, performance data file reporting, and performance threshold monitoring
CN111597092B (en) * 2020-07-27 2020-11-27 翱捷科技股份有限公司 Synchronous transmission method and device of nonvolatile storage file and embedded equipment

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080307041A1 (en) * 2007-01-10 2008-12-11 Nokia Corporation System and method for implementing mbms handover during downloaded delivery
US20090219848A1 (en) * 2005-06-21 2009-09-03 Thorsten Lohmar Provision of multimedia broadcast/multicast service (mbms) for roaming subscribers
US20090316615A1 (en) * 2007-06-19 2009-12-24 Nokia Corporation System and method for an improved mbms to pss handover

Family Cites Families (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2398968B (en) * 2003-02-27 2005-07-27 Motorola Inc Reduction in signalling load in a wireless communication system
US8942716B2 (en) * 2005-02-24 2015-01-27 Ntt Docomo, Inc. Radio resource control method, radio base station, and radio network controller
WO2008028318A1 (en) * 2006-08-25 2008-03-13 Huawei Technologies Co., Ltd. Method for setting up a call
CN101743717B (en) * 2007-04-23 2014-06-18 诺基亚公司 System and method for optimizing download user service delivery to roaming clients
CN103260202B (en) * 2007-04-30 2016-08-17 交互数字技术公司 For processing method and the subscriber equipment of cell reselection
CN101483898B (en) * 2008-01-07 2012-08-08 华为技术有限公司 Method and apparatus for accelerating RRC connection establishment
US8396081B2 (en) * 2008-02-01 2013-03-12 Panasonic Corporation Communication terminal and base station communication method using MAC control information priorities and SRB priorities
KR101153628B1 (en) * 2008-05-05 2012-06-18 엘지전자 주식회사 Mehtod for detecting cell in mobile communications system
CN101582730B (en) 2008-05-15 2011-06-01 华为技术有限公司 Method, system, corresponding device and communication terminal for providing MBMS service
US9001731B2 (en) * 2008-08-11 2015-04-07 Koninklijke Philips N.V. Method for communicating in a network, a secondary station and system therefor
KR101503842B1 (en) * 2008-11-03 2015-03-18 삼성전자주식회사 Method and apparatus for controlling discontinuous reception at mobile communication system
KR101622219B1 (en) * 2008-11-03 2016-05-18 엘지전자 주식회사 Method and apparatus for RRC connection reestablishment in wireless communication system
JP5005785B2 (en) * 2009-03-16 2012-08-22 宏達國際電子股▲ふん▼有限公司 Method and associated communication apparatus for reconfiguration of radio link control in a radio communication system
EP2415231B1 (en) 2009-04-01 2016-05-18 Telefonaktiebolaget LM Ericsson (publ) Security key management in ims-based multimedia broadcast and multicast services (mbms)
US20100291939A1 (en) * 2009-05-15 2010-11-18 Yu-Chih Jen Method of Handling Radio Resource Control Connection and Related Communication Device
CN101959133A (en) * 2009-07-15 2011-01-26 华为技术有限公司 M2M user equipment as well as operation control method and system thereof
WO2011006768A1 (en) * 2009-07-17 2011-01-20 Koninklijke Kpn N.V. Information transmission in a machine-to-machine telecommunications network
WO2011025876A1 (en) * 2009-08-27 2011-03-03 Interdigital Patent Holdings, Inc. Method and apparatus for solving limited addressing space in machine-to-machine (m2m) environments
CN104936242B (en) * 2009-09-29 2019-07-05 北京三星通信技术研究有限公司 The method for handling radio link failure report
ES2640769T3 (en) * 2009-10-05 2017-11-06 Nederlandse Organisatie Voor Toegepast- Natuurwetenschappelijk Onderzoek Tno Procedure and telecommunications network to control the activation of at least one terminal in a machine-type communication application
JP4703758B2 (en) * 2009-11-19 2011-06-15 株式会社東芝 Electronic device and communication control method
KR101752625B1 (en) * 2009-11-25 2017-06-29 인터디지탈 패튼 홀딩스, 인크 Machine type communication preregistration
MY156150A (en) * 2009-12-22 2016-01-15 Interdigital Patent Holdings Group-based machine to machine communication
US9167517B2 (en) * 2010-01-29 2015-10-20 Interdigital Patent Holdings, Inc. Group-based machine to machine communication
WO2011098993A1 (en) * 2010-02-15 2011-08-18 Telefonaktiebolaget Lm Ericsson (Publ) M2m group based addressing using cell broadcast service
EP2369890A1 (en) * 2010-03-26 2011-09-28 Panasonic Corporation Connection peak avoidance for machine-type-communication (MTC) devices
CN102238477B (en) * 2010-04-30 2014-02-19 华为终端有限公司 Method for triggering group of MTC (Machine Type Communication) devices to communicate with MTC server and MTC device
HUE036108T2 (en) * 2010-08-10 2018-06-28 Ericsson Telefon Ab L M A method in a media client, a media client, a control entity and a method in a control entity
US20120069782A1 (en) * 2010-09-22 2012-03-22 Richard Lee-Chee Kuo Method and apparatus for improving drx in a wireless communication system
MY168733A (en) * 2010-11-02 2018-11-29 Ericsson Telefon Ab L M Methods and devices for media description delivery
US9253178B2 (en) * 2011-01-17 2016-02-02 Telefonaktiebolaget L M Ericsson Method and apparatus for authenticating a communication device
EP2884812B1 (en) * 2011-04-01 2016-12-28 Interdigital Patent Holdings, Inc. Apparatus and method for sharing a common PDP context
US9026671B2 (en) 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
US20130013792A1 (en) * 2011-07-04 2013-01-10 Nederlandse Organisatie Voor Toegepast-Natuurwetenschappelijk Onderzoek Tno Triggering With QoS Parameters
US9590814B2 (en) * 2011-08-01 2017-03-07 Qualcomm Incorporated Method and apparatus for transport of dynamic adaptive streaming over HTTP (DASH) initialization segment description fragments as user service description fragments
BR112014003030B1 (en) 2011-08-11 2021-09-08 Apple Inc METHOD FOR SWITCHING FROM A DOWNLOAD OF MBMS TO AN HTTP-BASED DELIVERY OF DASH FORMATTED CONTENT, METHOD OF SWITCHING FROM AN HTTP-BASED DELIVERY OF DASH FORMATTED CONTENT TO A DOWNLOAD OF MBMS AND MOBILE DEVICE
US9712891B2 (en) * 2011-11-01 2017-07-18 Nokia Technologies Oy Method and apparatus for selecting an access method for delivery of media

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090219848A1 (en) * 2005-06-21 2009-09-03 Thorsten Lohmar Provision of multimedia broadcast/multicast service (mbms) for roaming subscribers
US20080307041A1 (en) * 2007-01-10 2008-12-11 Nokia Corporation System and method for implementing mbms handover during downloaded delivery
US20090316615A1 (en) * 2007-06-19 2009-12-24 Nokia Corporation System and method for an improved mbms to pss handover

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
INTERDIGITAL COMMUNICATIONS: "S4-110397, IMS-based PSS and MBMS Enhancement to Support Cross-Device Synchronization", 3GPP TSG-SA WG4 MEETING #64, 11 April 2011 (2011-04-11) - 15 April 2011 (2011-04-15), XP050527876 *
See also references of EP2742614A4 *

Cited By (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9960926B2 (en) 2011-08-11 2018-05-01 Intel Corporation Methods for switching between a MBMS download and an HTPP-based delivery of DASH formatted content over an IMS network
US9887852B2 (en) 2011-08-11 2018-02-06 Intel Corporation Methods for switching between a MBMS download and an HTTP-based delivery of DASH formatted content over an IMS network
US10778458B2 (en) 2011-08-11 2020-09-15 Apple Inc. Methods for switching between a MBMS download and an HTPP-based delivery of DASH formatted content over an IMS network
US9888045B2 (en) 2012-01-23 2018-02-06 Intel Corporation IP multimedia subsystem and method for MBMS file repair using HTTP servers
US20130246846A1 (en) * 2012-01-23 2013-09-19 Ozgur Oyman Ip multimedia subsystem and method for mbms file repair using http servers
US9213605B2 (en) * 2012-01-23 2015-12-15 Intel Corporation IP multimedia subsystem and method for MBMS file repair using HTTP servers
US10581929B2 (en) 2012-01-23 2020-03-03 Apple Inc. IP multimedia subsystem and method for MBMS file repair using HTTP servers
US20140019587A1 (en) * 2012-07-11 2014-01-16 Futurewei Technologies, Inc. Dynamic Adaptive Streaming over Hypertext Transfer Protocol as Hybrid Multirate Media Description, Delivery, and Storage Format
US9954717B2 (en) * 2012-07-11 2018-04-24 Futurewei Technologies, Inc. Dynamic adaptive streaming over hypertext transfer protocol as hybrid multirate media description, delivery, and storage format
US9398498B2 (en) 2012-09-28 2016-07-19 Intel Corporation IMS based P2P streaming and download services
EP2901619A4 (en) * 2012-09-28 2016-05-04 Intel Corp Ims based p2p streaming and download services
US9560512B2 (en) 2013-02-22 2017-01-31 Intel IP Corporation Reporting of user plane congestion (UPCON) using a UPCON container
JP2016517648A (en) * 2013-04-04 2016-06-16 インテル アイピー コーポレイション Internet Protocol (IP) Multimedia Subsystem (IMS) based Peer to Peer (P2P) content delivery
CN105027499A (en) * 2013-04-04 2015-11-04 英特尔Ip公司 Internet protocol (IP) multimedia subsystem (IMS) based peer-to-peer (P2P) content distribution
JP2018082489A (en) * 2013-04-04 2018-05-24 インテル アイピー コーポレイション Internet protocol (ip) multimedia subsystem (ims) based peer-to-peer (p2p) content distribution
US11388700B2 (en) 2013-04-04 2022-07-12 Apple Inc. Internet protocol (IP) multimedia subsystem (IMS) based peer-to-peer (P2P) content distribution
EP2982078A4 (en) * 2013-04-04 2017-05-24 Intel IP Corporation Internet protocol (ip) multimedia subsystem (ims) based peer-to-peer (p2p) content distribution
CN105308910A (en) * 2013-04-09 2016-02-03 三星电子株式会社 Methods and apparatuses for dynamic content offloading
KR20150143424A (en) * 2013-04-09 2015-12-23 삼성전자주식회사 Methods and apparatuses for dynamic content offloading
CN105308910B (en) * 2013-04-09 2019-11-19 三星电子株式会社 Method and apparatus for dynamic content off-loading
JP2016516379A (en) * 2013-04-09 2016-06-02 サムスン エレクトロニクス カンパニー リミテッド Method and apparatus for dynamic content offloading
US9807188B2 (en) 2013-04-09 2017-10-31 Samsung Electronics Co., Ltd. Methods and apparatuses for dynamic content offloading
KR102243529B1 (en) 2013-04-09 2021-04-22 삼성전자주식회사 Methods and apparatuses for dynamic content offloading
WO2014168414A1 (en) * 2013-04-09 2014-10-16 Samsung Electronics Co., Ltd. Methods and apparatuses for dynamic content offloading
EP3001602A4 (en) * 2013-07-02 2016-06-01 Huawei Tech Co Ltd Method, related device and system supporting streaming media multicast
US10440077B2 (en) 2013-09-03 2019-10-08 Huawei Technologies Co., Ltd. Method and apparatus for media stream transmission, and user equipment
CN104641575A (en) * 2013-09-03 2015-05-20 华为技术有限公司 Method and device for transmitting media stream and user equipment
WO2015032032A1 (en) * 2013-09-03 2015-03-12 华为技术有限公司 Method and device for transmitting media stream and user equipment
JP2016536914A (en) * 2013-09-13 2016-11-24 ホアウェイ・テクノロジーズ・カンパニー・リミテッド Streaming media transmission method and system, user equipment and server
US9769284B2 (en) 2013-11-27 2017-09-19 At&T Intellectual Property I, L.P. Server-side scheduling for media transmissions according to client device states
US9197717B2 (en) 2013-11-27 2015-11-24 At&T Intellectual Property I, Lp Server-side scheduling for media transmissions according to client device states
US10063656B2 (en) 2013-11-27 2018-08-28 At&T Intellectual Property I, L.P. Server-side scheduling for media transmissions
US10356208B2 (en) 2013-11-27 2019-07-16 At&T Intellectual Property I, L.P. Server-side scheduling for media transmissions according to client device states
US9363333B2 (en) 2013-11-27 2016-06-07 At&T Intellectual Property I, Lp Server-side scheduling for media transmissions
US10827032B2 (en) 2013-11-27 2020-11-03 At&T Intellectual Property I, L.P. Server-side scheduling for media transmissions according to client device states
US10516757B2 (en) 2013-11-27 2019-12-24 At&T Intellectual Property I, L.P. Server-side scheduling for media transmissions
CN105900445A (en) * 2014-01-16 2016-08-24 高通股份有限公司 Robust live operation of DASH
CN105900445B (en) * 2014-01-16 2019-03-29 高通股份有限公司 The method and apparatus of steady live operation for dynamic self-adapting stream transmission
KR102387211B1 (en) * 2015-03-27 2022-04-14 퀄컴 인코포레이티드 Point-to-multipoint broadcast assisted vehicle-to-x broadcast
KR20170130428A (en) * 2015-03-27 2017-11-28 퀄컴 인코포레이티드 Point-to-multipoint broadcast assisted vehicle-to-x broadcast
WO2017023462A1 (en) * 2015-08-04 2017-02-09 Qualcomm Incorporated Hybrid pocket router
US20170041361A1 (en) * 2015-08-04 2017-02-09 Qualcomm Incorporated Hybrid pocket router
US10270822B2 (en) 2015-08-04 2019-04-23 Qualcomm Incorporated Hybrid pocket router
EP3348081B1 (en) * 2015-09-08 2023-07-12 Telefonaktiebolaget LM Ericsson (publ) Streaming session continuation
JP2018186551A (en) * 2018-07-13 2018-11-22 ホアウェイ・テクノロジーズ・カンパニー・リミテッド Streaming media transmission method and system, user equipment, and server
US11824904B1 (en) 2022-11-18 2023-11-21 T-Mobile Usa, Inc. Verifying delivery of rich call data object to a terminating wireless device
US12088641B2 (en) 2022-11-18 2024-09-10 T-Mobile Usa, Inc. Verifying delivery of rich call data object to a terminating wireless device

Also Published As

Publication number Publication date
KR20150092356A (en) 2015-08-12
US20150288530A1 (en) 2015-10-08
CN103765798A (en) 2014-04-30
WO2013022472A1 (en) 2013-02-14
CN103765928A (en) 2014-04-30
KR20140042913A (en) 2014-04-07
EP2742614A1 (en) 2014-06-18
RU2578666C2 (en) 2016-03-27
CN103765798B (en) 2017-03-15
CN103748810A (en) 2014-04-23
US9887852B2 (en) 2018-02-06
JP5706046B2 (en) 2015-04-22
KR101631194B1 (en) 2016-06-16
EP2742621B1 (en) 2016-04-06
BR112014003028A2 (en) 2017-10-24
EP2742614A4 (en) 2015-03-18
KR20140041912A (en) 2014-04-04
RU2557256C1 (en) 2015-07-20
HUE029183T2 (en) 2017-02-28
JP5763275B2 (en) 2015-08-12
BR112014003030B1 (en) 2021-09-08
US20150256959A1 (en) 2015-09-10
US10778458B2 (en) 2020-09-15
EP2742621A2 (en) 2014-06-18
EP2742621A4 (en) 2015-05-20
WO2013106060A3 (en) 2013-10-24
US20150131657A1 (en) 2015-05-14
US20180152309A1 (en) 2018-05-31
WO2013106060A2 (en) 2013-07-18
IN2014CN01083A (en) 2015-04-10
ES2581306T3 (en) 2016-09-05
EP3021554A1 (en) 2016-05-18
HUE029945T2 (en) 2017-04-28
ES2574805T3 (en) 2016-06-22
RU2014107661A (en) 2015-09-10
JP2014527355A (en) 2014-10-09
KR101497287B1 (en) 2015-02-27
CN103748810B (en) 2017-05-10
US9960926B2 (en) 2018-05-01
BR112014003030A2 (en) 2017-10-24
EP2742614B1 (en) 2016-03-23
JP2014525699A (en) 2014-09-29
US20140226576A1 (en) 2014-08-14

Similar Documents

Publication Publication Date Title
US10778458B2 (en) Methods for switching between a MBMS download and an HTPP-based delivery of DASH formatted content over an IMS network
US9398498B2 (en) IMS based P2P streaming and download services
JP6487076B2 (en) Internet Protocol (IP) Multimedia Subsystem (IMS) based Peer to Peer (P2P) content delivery
US10433327B2 (en) Presence service using IMS based DASH service
US10581929B2 (en) IP multimedia subsystem and method for MBMS file repair using HTTP servers
JP6418665B2 (en) Method of supplying presence information by presence server in IMS-based DASH service, and user equipment (UE) receiving presence information via presence server

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014525000

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20147005141

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2014107662

Country of ref document: RU

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2011870588

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13994118

Country of ref document: US

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112014003030

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112014003030

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20140207

REG Reference to national code

Ref country code: BR

Ref legal event code: B01E

Ref document number: 112014003030

Country of ref document: BR

Kind code of ref document: A2

ENP Entry into the national phase

Ref document number: 112014003030

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20140207