JP6433999B2 - １つまたは複数のサービスによるコンテンツ配信の調停 - Google Patents
１つまたは複数のサービスによるコンテンツ配信の調停 Download PDFInfo
- Publication number
- JP6433999B2 JP6433999B2 JP2016519718A JP2016519718A JP6433999B2 JP 6433999 B2 JP6433999 B2 JP 6433999B2 JP 2016519718 A JP2016519718 A JP 2016519718A JP 2016519718 A JP2016519718 A JP 2016519718A JP 6433999 B2 JP6433999 B2 JP 6433999B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- mbms
- unit
- data
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 claims description 130
- 230000004044 response Effects 0.000 claims description 50
- 238000004891 communication Methods 0.000 claims description 23
- 238000003860 storage Methods 0.000 claims description 23
- 238000009826 distribution Methods 0.000 claims description 18
- 238000012546 transfer Methods 0.000 claims description 17
- 230000003213 activating effect Effects 0.000 claims description 16
- 230000007246 mechanism Effects 0.000 claims description 15
- 238000013507 mapping Methods 0.000 claims 1
- 238000010586 diagram Methods 0.000 description 52
- 230000006870 function Effects 0.000 description 50
- 230000000875 corresponding effect Effects 0.000 description 35
- 239000012634 fragment Substances 0.000 description 23
- 230000005540 biological transmission Effects 0.000 description 22
- 230000011664 signaling Effects 0.000 description 22
- 239000008186 active pharmaceutical agent Substances 0.000 description 21
- 230000006978 adaptation Effects 0.000 description 18
- 238000005538 encapsulation Methods 0.000 description 17
- 230000008859 change Effects 0.000 description 16
- 238000005516 engineering process Methods 0.000 description 16
- 238000012545 processing Methods 0.000 description 16
- 238000007726 management method Methods 0.000 description 15
- 230000002776 aggregation Effects 0.000 description 14
- 238000004220 aggregation Methods 0.000 description 14
- 238000002360 preparation method Methods 0.000 description 13
- 210000004027 cell Anatomy 0.000 description 11
- 230000003044 adaptive effect Effects 0.000 description 8
- 230000001413 cellular effect Effects 0.000 description 7
- 230000002123 temporal effect Effects 0.000 description 6
- 238000006243 chemical reaction Methods 0.000 description 5
- 230000001976 improved effect Effects 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 238000009877 rendering Methods 0.000 description 5
- 230000009471 action Effects 0.000 description 4
- 238000013459 approach Methods 0.000 description 4
- 230000006835 compression Effects 0.000 description 4
- 238000007906 compression Methods 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 230000007704 transition Effects 0.000 description 4
- 230000007723 transport mechanism Effects 0.000 description 4
- 230000006399 behavior Effects 0.000 description 3
- 238000013500 data storage Methods 0.000 description 3
- 238000005259 measurement Methods 0.000 description 3
- 230000005012 migration Effects 0.000 description 3
- 238000013508 migration Methods 0.000 description 3
- 238000010295 mobile communication Methods 0.000 description 3
- 230000008520 organization Effects 0.000 description 3
- 101100421134 Schizosaccharomyces pombe (strain 972 / ATCC 24843) sle1 gene Proteins 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 230000003190 augmentative effect Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 239000000470 constituent Substances 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 238000005304 joining Methods 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 239000012092 media component Substances 0.000 description 2
- 230000036651 mood Effects 0.000 description 2
- 239000013598 vector Substances 0.000 description 2
- FMYKJLXRRQTBOR-UBFHEZILSA-N (2s)-2-acetamido-4-methyl-n-[4-methyl-1-oxo-1-[[(2s)-1-oxohexan-2-yl]amino]pentan-2-yl]pentanamide Chemical group CCCC[C@@H](C=O)NC(=O)C(CC(C)C)NC(=O)[C@H](CC(C)C)NC(C)=O FMYKJLXRRQTBOR-UBFHEZILSA-N 0.000 description 1
- 101150014328 RAN2 gene Proteins 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- TZSMWSKOPZEMAJ-UHFFFAOYSA-N bis[(2-methoxyphenyl)methyl] carbonate Chemical compound COC1=CC=CC=C1COC(=O)OCC1=CC=CC=C1OC TZSMWSKOPZEMAJ-UHFFFAOYSA-N 0.000 description 1
- 210000004271 bone marrow stromal cell Anatomy 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 235000014510 cooky Nutrition 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000009849 deactivation Effects 0.000 description 1
- 238000002716 delivery method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000005923 long-lasting effect Effects 0.000 description 1
- 230000003340 mental effect Effects 0.000 description 1
- 238000011017 operating method Methods 0.000 description 1
- 239000013307 optical fiber Substances 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000000644 propagated effect Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 238000005067 remediation Methods 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000012216 screening Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000000153 supplemental effect Effects 0.000 description 1
- 230000008093 supporting effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
-
- 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/60—Network streaming of media packets
-
- 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
- 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/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
-
- 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/60—Network streaming of media packets
- H04L65/70—Media network packetisation
-
- 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/60—Network streaming of media packets
- H04L65/75—Media network packet handling
-
- 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/60—Network streaming of media packets
- H04L65/75—Media network packet handling
- H04L65/765—Media network packet handling intermediate
-
- 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
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/14—Reselecting a network or an air interface
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
- H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/14—Reselecting a network or an air interface
- H04W36/142—Reselecting a network or an air interface over the same radio air interface technology
-
- 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
- H04W76/00—Connection management
- H04W76/40—Connection management for selective distribution or broadcast
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
本出願は、2013年6月17日に出願した米国仮特許出願第61/836,143号の優先権を主張するものであり、この仮出願の内容全体は、参照により本明細書に組み込まれる。
本開示は、符号化されたデータの記憶および転送に関する。
デジタルテレビ、デジタル直接放送システム(digital direct broadcast system)、ワイヤレス放送システム、携帯情報端末(PDA)、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレイヤー、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、ビデオ遠隔会議デバイスなどを含む広範なデバイスにデジタルビデオ能力が組み込まれる可能性がある。デジタルビデオデバイスは、より効率的にデジタルビデオ情報を送信および受信するために、MPEG-2、MPEG-4、ITU-T H.263またはITU-T H.264/MPEG-4、パート10、高度ビデオ符号化(AVC: Advanced Video Coding)、およびそのような規格の拡張によって定義された規格に記載されたビデオ圧縮技術などのビデオ圧縮技術を実装する。
ビデオ圧縮技術は、空間的予測および/または時間的予測を実行してビデオシーケンスに固有の冗長性を削減または削除する。ブロックに基づくビデオ符号化のために、ビデオフレームまたはスライスが、マクロブロックに分けられる可能性がある。各マクロブロックは、さらに分けられ得る。イントラ符号化された(I)フレームまたはスライスのマクロブロックは、近隣のマクロブロックに関連する空間的予測を用いて符号化される。インター符号化(PまたはB)フレームまたはスライスのマクロブロックは、同じフレームもしくはスライスの近隣のマクロブロックに関連する空間的予測、またはその他の基準フレームに関連する時間的予測を使用する可能性がある。
ビデオデータは、符号化された後、送信または記憶のためにパケット化される可能性がある。ビデオデータは、国際標準化機構(ISO)に基づくメディアファイルフォーマットおよびAVCなどのその拡張などの様々な規格のいずれかに準拠するビデオファイルへと組み立てられる可能性がある。
3GPP技術仕様26.346、「Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs (Release 12)」、V12.1.0、2014年3月
Fieldingら、「Hypertext Transfer Protocol - HTTP/1.1」、Internet Engineering Task Force (IETF)、RFC 2616、1999年6月
S4-140327、「MI-MooD: MBMS Service Configuration」、Qualcomm contribution to SA4 #78
T. Pailaら、「FLUTE - File Delivery over Unidirectional Transport」、IETF、RFC 6726、2012年11月
3GPP技術仕様23.246、「Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description, (Release 12)」v12.1.0、2014年3月
Open Mobile Alliance、「OMA Device Management Protocol」、Approved Version 1.2.1、2008年6月
Open Mobile Alliance、「Enabler Release Definition for OMA Device Management」、Approved Version 1.2.1、2008年6月
Berners-Leeら、「Uniform Resource Identifier (URI): Generic Syntax」、IETF、RFC 3986、2005年1月
Mockapetris、「Domain Names - Implementation and Specification」、IETF、RFC 1035、1987年11月
3GPP技術仕様23.003、「Numbering, addressing and identification, (Release 12)」、v12.2.0、2014年3月
一例においては、ストリーミングデータを受信する方法が、クライアントデバイスのプロキシユニットによって、ストリーミングデータが第1のサービスを介して受信されるべきかまたは第2のサービスを介して受信されるべきかの指示を受信するステップであって、指示が、サービスプロバイダネットワークのブロードキャストマルチキャストサービスセンター(BM-SC)から送信され、クライアントデバイスが、ブロードキャストまたはマルチキャストミドルウェアユニットをさらに含み、プロキシユニットが、ミドルウェアユニットとクライアントデバイスの少なくとも1つのプロセッサによって実行されるクライアントアプリケーションとの間の通信経路に配置される、ステップと、指示がストリーミングデータが第2のサービスを介して受信されるべきであることを示すとき、第2のサービスを介してストリーミングデータを受信するためにミドルウェアユニットをアクティブ化するステップであって、第2のサービスが、ブロードキャストサービスまたはマルチキャストサービスのうちの少なくとも1つを含む、ステップと、プロキシユニットによって、ミドルウェアユニットからストリーミングデータを受信するステップとを含む。
一例においては、ストリーミングデータを受信する方法が、クライアントデバイスのプロキシユニットによって、ストリーミングデータが第1のサービスを介して受信されるべきかまたは第2のサービスを介して受信されるべきかの指示を受信するステップであって、指示が、サービスプロバイダネットワークのブロードキャストマルチキャストサービスセンター(BM-SC)から送信され、クライアントデバイスが、マルチメディアブロードキャストマルチキャストサービス(MBMS)または進化型MBMS(eMBMS)ミドルウェアユニットをさらに含み、プロキシユニットが、ミドルウェアユニットとクライアントデバイスの少なくとも1つのプロセッサによって実行されるクライアントアプリケーションとの間の通信経路に配置される、ステップと、指示がストリーミングデータが第1のサービスを介して受信されるべきであることを示すとき、ミドルウェアユニットを無効化するステップであって、ミドルウェアユニットが、第2のサービスを介してストリーミングデータの少なくとも一部を受信済みであり、第2のサービスが、ブロードキャストサービスまたはマルチキャストサービスのうちの少なくとも1つを含む、ステップと、プロキシユニットによって、第1のサービスを介してストリーミングデータを受信するステップであって、第1のサービスがユニキャストサービスを含む、ステップとを含む。
一例においては、ストリーミングデータを受信するためのデバイスが、第2のサービスを介してストリーミングデータを受信するように構成されたブロードキャストまたはマルチキャストミドルウェアユニットと、ミドルウェアユニットとデバイスの少なくとも1つのプロセッサによって実行されるクライアントアプリケーションとの間の通信経路に配置されるように構成されたプロキシユニットであって、サービスプロバイダネットワークのブロードキャストマルチキャストサービスセンター(BM-SC)から、ストリーミングデータが第1のサービスを介して受信されるべきかまたは第2のサービスを介して受信されるべきかの指示を受信すること、指示がストリーミングデータが第1のサービスを介して受信されるべきであることを示すとき、ミドルウェアユニットを無効化すること、および第1のサービスを介してストリーミングデータを受信することであって、第1のサービスがユニキャストサービスを含む、受信すること、ならびに指示がストリーミングデータが第2のサービスを介して受信されるべきであることを示すとき、第2のサービスを介してストリーミングデータを受信するためにミドルウェアユニットをアクティブ化することであって、第2のサービスが、ブロードキャストサービスまたはマルチキャストサービスのうちの少なくとも1つを含む、アクティブ化すること、およびミドルウェアユニットからストリーミングデータを受信することを行うようにさらに構成される、プロキシユニットとを含む。
一例においては、コンピュータ可読ストレージ媒体が、実行されるときにクライアントデバイスの少なくとも1つのプロセッサにストリーミングデータが第1のサービスを介して受信されるべきかまたは第2のサービスを介して受信されるべきかの指示をクライアントデバイスのプロキシユニットに受信させることであって、指示が、サービスプロバイダネットワークのブロードキャストマルチキャストサービスセンター(BM-SC)から送信され、クライアントデバイスが、ブロードキャストまたはマルチキャストミドルウェアユニットを含み、プロキシユニットが、ブロードキャストまたはマルチキャストミドルウェアユニットとクライアントデバイスの少なくとも1つのプロセッサによって実行されるクライアントアプリケーションとの間の通信経路に配置される、受信させることと、指示がストリーミングデータが第1のサービスを介して受信されるべきであることを示すとき、ミドルウェアユニットを無効化することと、第1のサービスを介してストリーミングデータを受信することであって、第1のサービスがユニキャストサービスを含む、受信することと、指示がストリーミングデータが第2のサービスを介して受信されるべきであることを示すとき、第2のサービスを介してストリーミングデータを受信するためにミドルウェアユニットをアクティブ化することであって、第2のサービスが、ブロードキャストサービスまたはマルチキャストサービスのうちの少なくとも1つを含む、アクティブ化することと、ミドルウェアユニットからストリーミングデータを受信することとを行わせる、ストリーミングデータを受信するための命令を記憶する。
一例においては、ストリーミングデータを受信するためのデバイスが、ストリーミングデータが第1のサービスを介して受信されるべきかまたは第2のサービスを介して受信されるべきかの指示をデバイスのプロキシユニットに受信させるための手段であって、指示が、サービスプロバイダネットワークのブロードキャストマルチキャストサービスセンター(BM-SC)から送信され、デバイスが、ブロードキャストまたはマルチキャストミドルウェアユニットをさらに含み、プロキシユニットが、ブロードキャストまたはマルチキャストミドルウェアユニットとクライアントデバイスの少なくとも1つのプロセッサによって実行されるクライアントアプリケーションとの間の通信経路に配置される、手段と、指示がストリーミングデータが第1のサービスを介して受信されるべきであることを示すときにミドルウェアユニットを無効化するための手段と、指示がストリーミングデータが第1のサービスを介して受信されるべきであることを示すときにプロキシユニットによって第1のサービスを介してストリーミングデータを受信するための手段であって、第1のサービスがユニキャストサービスを含む、手段と、指示がストリーミングデータが第2のサービスを介して受信されるべきであることを示すときに第2のサービスを介してストリーミングデータを受信するためにミドルウェアユニットをアクティブ化するための手段であって、第2のサービスが、ブロードキャストサービスまたはマルチキャストサービスのうちの少なくとも1つを含む、手段と、指示がストリーミングデータが第2のサービスを介して受信されるべきであることを示すときにミドルウェアユニットからストリーミングデータを受信するための手段とを含む。
1つまたは複数の例の詳細が、添付の図面および以下の説明に記載されている。その他の特徴、目標、および利点は、説明および図面から、ならびに請求項から明らかになるであろう。
ワイヤレス通信ネットワークが、音声、ビデオ、パケットデータ、メッセージング、放送などの様々な通信サービスを提供するために広く展開されている。これらのワイヤレスネットワークは、利用可能なネットワークリソースを共有することによって複数のユーザをサポートすることができる多元接続ネットワークである可能性がある。そのような多元接続ネットワークの例は、符号分割多元接続(CDMA)ネットワーク、時分割多元接続(TDMA)ネットワーク、周波数分割多元接続(FDMA)ネットワーク、直交FDMA(OFDMA)ネットワーク、およびシングルキャリアFDMA(SC-FDMA)ネットワークを含む。
ワイヤレス通信ネットワークは、モバイルデバイスまたはモバイルエンティティとも呼ばれる多くのユーザ機器(UE)に関する通信をサポートすることができる多くの基地局を含む可能性がある。UEは、ダウンリンクおよびアップリンクを介して基地局と通信し得る。ダウンリンク(または順方向リンク)は基地局からUEへの通信リンクを指し、アップリンク(または逆方向リンク)はUEから基地局への通信リンクを指す。「基地局」は、eNodeB(eNB)、NodeB、ホームNodeB、またはワイヤレス通信システムの同様のネットワーク構成要素を指す可能性がある。
第3世代パートナーシッププロジェクト(3GPP)ロングタームエボリューション(LTE)は、セルラーテクノロジーの大きな進歩を移動体通信用グローバルシステム(GSM（登録商標）: Global System for Mobile communications)およびユニバーサル移動体通信システム(UMTS: Universal Mobile Telecommunications System)の発展として示す。LTE物理レイヤ(PHY)は、進化型NodeB(eNB)などの基地局とUEなどのモバイルデバイスとの間でデータと制御情報との両方を運ぶ非常に効率的な方法を提供する。以前の応用において、マルチメディアのための高帯域幅の通信を容易にするための方法は、単一周波数ネットワーク(SFN)動作でであった。SFNは、たとえば、eNBなどの無線送信機を利用して加入者UEと通信する。ユニキャスト動作では、各eNBが、1つまたは複数の特定の加入者UEに向けられた情報を運ぶ信号を送信するように制御される。ユニキャストシグナリングの特定性は、たとえば、音声通話、テキストメッセージング、またはビデオ通話などの個人対個人のサービスを可能にする。
ブロードキャスト動作では、ブロードキャストエリア(broadcast area)内のいくつかのeNBが、ブロードキャストエリア内の任意の加入者UEによって受信およびアクセスされ得る情報を運ぶブロードキャスト信号を同期してブロードキャストする。ブロードキャスト動作の一般性は、一般大衆の関心を集める情報の送信、たとえば、様々な種類のオーディオビデオコンテンツをエンドユーザに提供するマルチメディアブロードキャストおよびマルチメディアユニキャストサービスにおいてより高い効率を可能にする。マルチメディアコンテンツの需要およびシステムの能力が高まったので、システムの運用者は、柔軟で適応的な方法でマルチメディアまたはその他のコンテンツのための無線リソースの使用を制御するためのツールを必要としている。
概して、本開示は、ネットワークを通じてストリーミングメディアデータ(たとえば、オーディオおよび/またはビデオデータ)を含む様々な種類のデータを送信するための様々な種類の転送メカニズムをサポートするための技術を説明する。たとえば、UEの1つまたは複数の構成要素(たとえば、アプリケーション、ストリーミング/ファイルダウンロードクライアント、プロキシユニット、またはその他の構成要素)は、データが第1の(たとえば、ユニキャスト)サービスを介して受信されるべきかまたは第2の(たとえば、ブロードキャストもしくはマルチキャスト)サービスを介して受信されるべきかの指示を受信するように構成される可能性がある。指示は、一部の例において、HTTPリダイレクト、プッシュメッセージ、無線インターフェースシグナリングメッセージ、またはその他のメッセージである可能性がある。データが第1のサービスを介して受信されるべきであることを指示が示すとき、UEは、マルチメディアブロードキャストマルチキャストサービス(MBMS)ミドルウェアユニット、進化型MBMS(eMBMS)ミドルウェアユニット、またはマルチキャストサービスデバイスクライアント(MSDC)などの、第2のサービスを介してデータを受信するための望ましいユニットである可能性があり、第1の配信モード(たとえば、ユニキャスト配信モード)を用いて第1のサービスを介してデータを受信する可能性がある。データが第2のサービスを介して受信されるべきであることを指示が示すとき、UEは、第2のサービスを介してデータを受信するためのユニットをアクティブ化し、第2のサービスを介してデータを受信するためのユニットからデータを受信する可能性がある。第2のサービスを介してデータを受信するためのユニットは、第1の配信モード(たとえば、ユニキャスト配信モード)または第2の配信モード(たとえば、ブロードキャストもしくはマルチキャスト配信モード)を介してデータを受信する可能性がある。
言い換えれば、本開示の1つまたは複数の技術は、MBMSオペレーションオンデマンド(MooD)を提供することによるMBMS動作に対する改善を伴う可能性がある。本明細書において説明される技術は、一部の例において、MBMSユーザサービスのオンザフライの設定と、MBMSユーザサービスへの既存のサービスの切れ目のないマイグレーションとを可能にし得る。つまり、一部の例においては、最初にユニキャストネットワークを介して配信される特定のコンテンツが、トラフィックの量が特定の閾値を超えるときにネットワークリソースを効率的に使用するためにMBMSユーザサービスに変えられ得る。ユニキャスト配信からMBMS配信へのそのような変換は、「MBMSオフローディング(MBMS offloading)」とも呼ばれる可能性がある。MBMSオフローディングは、HTTPまたはリアルタイムトランスポートプロトコル(RTP)/リアルタイムストリーミングプロトコル(RTSP)で運ばれるユニキャストトラフィックに当てはまる可能性がある。前者(たとえば、HTTPで運ばれるユニキャストトラフィック)の場合、MBMSダウンロード配信方法が、オフロードされたコンテンツを配信するために使用され得る。後者(たとえば、RTP/RTSPで運ばれるユニキャストトラフィック)の場合、RTPに基づくMBMSストリーミング方法が、オフロードされたコンテンツを配信するために使用され得る。
一部の例において、MBMSオフローディングは、UEによって選ばれる可能性がある。UEによって選ばれたオフローディングは、MooD対応UEがMBMSサービスとしての配信に変換されるのにふさわしいコンテンツのユニキャスト要求を指定されたプロキシサーバに送信することを指す可能性がある。特定のコンテンツの変換のふさわしさは、要求ドメイン(request domain)に基づいてオープンモバイルアライアンスデバイス管理(OMA-DM: open mobile alliance device management)のMooD管理オブジェクト(MO: MooD Management Object)によって記述され得る。UEは、(たとえば、3GPPで規定されたMooDヘッダフィールドを含む)MooDリダイレクト応答を受信する場合、すでにプロビジョニングされているかまたはMooDヘッダフィールドで提供されるユーザサービス記述(USD: user service description)へのエントリポイント情報をミドルウェアに提供することによってMBMSミドルウェアクライアントをアクティブ化し得る。その後、MBMSミドルウェアクライアントが動作可能であるとき、新しいMBMSサービスに関する(HTTPを介した動的適応ストリーミング(DASH: Dynamic Adaptive Streaming over HTTP)フォーマットのコンテンツの場合はメディアプレゼンテーション記述(Media Presentation Description)フラグメントを含む)USDフラグメントを獲得し、MBMSベアラ上でコンテンツを受信し始めた後、ストリーミングクライアント(たとえば、DASHクライアント)によるコンテンツの将来の要求が、MBMSクライアントによって満たされ得る。
OMA-DM(デバイス管理)によって、UEは、(たとえば、MooD構成管理オブジェクト(MooD configuration management object)を用いて)Mood動作に関する構成情報をプロビジョニングされ得る。構成パラメータは、ユニキャストコンテンツ要求が送信されるべきプロキシサーバの指示、MBMSへのオフローディングがふさわしい可能性があるコンテンツの識別情報、およびUEがサービス告知情報を獲得するためのUSDの位置を含み得る。
UEは、BM-SCのリダイレクトメッセージを扱うことができない場合、要求のためにプロキシサーバを使用しない可能性がある。つまり、一部のUEが、本明細書において説明される技術に従って構成される可能性があり、リダイレクトメッセージの処理をサポートし得る一方、その他のUEは、リダイレクトメッセージを扱うことができない可能性がある。
さらに、本明細書において説明される技術は、サービスがブロードキャストを用いてより良く提供されるのかまたはユニキャストを用いてより良く提供されるのかを判定するためにユニキャストサービスの性能を評価すること、および前にいずれもアクティブでなかった場合に進行中のMBMSユーザサービスのためのMBMSブロードキャストセッションを有効化するための技術を含む可能性がある。
一部の例において、本明細書において説明される技術は、(たとえば、サービスネットワークの)1つまたは複数の構成要素が、非MBMSユニキャストサービスがMBMSユーザサービスに変換されるべきであるかどうかを判定し、変換されるべきである場合に、非MBMSユニキャストサービスをMBMSユーザサービスに変換するためにブロードキャストマルチキャストサービスセンター(BM-SC)を有効化することを可能にし得る。MBMSユーザサービスは、3GPP技術仕様26.346、「Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs (Release 12)」、V12.1.0、2014年3月で規定されている。一部のそのような例において、本明細書において説明される技術は、サービスネットワークがMBMSユーザサービスを記述するUSDまたはその他のマニフェストファイルを関心のあるUEに配布することを可能にし得る。
加えて、本明細書において説明される技術は、一部の例において、サービスの消費レベルを決定することと、サービスがユニキャスト送信によってより良く提供されるのかまたはブロードキャスト/マルチキャスト送信によってより良く提供されるのかを判定するのを支援し得る要素を評価することとを含む可能性がある。消費レベルは、一部の例において、サービスを消費している特定のエリア内のUEの数、サービスを消費しているエリア内のUEの割合、サービスを消費しているMooD対応UEの割合、またはサービスの消費のその他の測定値を表す可能性がある。本明細書において説明される技術は、一部の例において、受領が多い場合にUSDまたはその他のマニフェストファイルが既存のMBMSユーザサービスにMBMSダウンロードまたはストリーミングセッションを追加することを可能にし得る。一部の例において、本明細書において説明される技術は、プレR12(pre-R12)MBMSをサポートするUEに関するMooDのサポートのレベルを調査する可能性がある。様々な例において、本開示の技術は、MBMSブロードキャストサービスおよび/またはMBMSマルチキャストサービスを用いて適用され得る。
本開示の技術は、ストリーミングメディアデータための様々なアプリケーションレイヤプロトコルと併せて使用される可能性がある。たとえば、本開示の技術は、DASH、HTTPライブストリーミング(HLS)、およびメディアデータをストリーミングするためにHTTPを利用するSmoothStreamingなどの適応的なHTTPストリーミングテクノロジーと併せて使用される可能性がある。さらなる例として、本開示の技術は、RTP、RTSP、および/またはパケット交換ストリーミングサービス(PSS)プログレッシブダウンロードなどのファイルダウンロードプロトコルと併せて使用され得る。これらのおよびその他の場合、ストリーミングクライアント(たとえば、RTPクライアント、RTSPクライアント、DASHクライアントなど)は、メディアデータを取り出すために使用される転送メカニズムを知っている必要がないという意味で転送に関知しない可能性がある。たとえば、一部の例において、ストリーミングクライアントは、基礎をなすトランスポートメカニズムがユニキャスト配信モードによるユニキャストサービスに対応するのかまたはブロードキャストもしくはマルチキャスト配信モードによるブロードキャストもしくはマルチキャストサービスに対応するのかを知っている必要がない。
以下でより詳細に検討されるように、UEは、ネットワークを介して要求を送信するように構成される可能性があり、要求は、コンテンツサービスの特定のデータ(たとえば、メディアデータまたはその他のファイルデータ)を指定する。UEの1つまたは複数の構成要素が、データが特定の転送メカニズム、たとえば、ブロードキャストサービスまたはユニキャストサービスを用いて取り出され得るかどうかの指示を受信する可能性がある。たとえば、UEのプロキシユニットが、要求を送信することに応じて指示を受信し得る。そして、プロキシユニットは、ストリーミング/ファイルダウンロードクライアントに(可用性、プリファレンス、信頼性、および/またはその他の要因に基づいて)トランスポートメカニズムのうちの1つを用いてデータを受信させ得る。たとえば、ブロードキャストサービスが利用可能である場合、プロキシユニットは、ストリーミング/ファイルダウンロードクライアントに(たとえば、ブロードキャスト配信モードを用いて)ブロードキャストサービスを介してデータを受信させる可能性がある一方、ブロードキャストサービスが利用可能でない場合、プロキシユニットは、ストリーミング/ファイルダウンロードクライアントにユニキャストサービスを介してデータを受信し続けさせる可能性がある。
一例として、DASHに関連して、メディアデータは、1つまたは複数のサーバ、たとえば、ブロードキャストサーバおよびユニキャストサーバから入手可能である可能性がある。場合によっては、同じサーバデバイスが、ブロードキャストサービスとユニキャストサービスとの両方を提供する可能性がある。したがって、ブロードキャストサーバおよびユニキャストサーバは、同じサーバデバイスに対応する可能性がある。DASHクライアントは、メディアデータが(サーバではなく)ローカルホストから入手可能であることを示すメディアデータに関する修正されたメディアプレゼンテーション記述(MPD)を受信し得る。DASHクライアントがプロキシユニットにメディアデータの要求を送信するとき、プロキシユニットは、要求されたメディアデータを取り出すためにユニキャストサービスが利用可能であるのかまたはブロードキャストサービスが利用可能であるのかを(受信された指示に基づいて)判定し得る。ブロードキャストサービスが利用可能である場合、ブロードキャスト受信ユニット(たとえば、MBMSまたはeMBMSミドルウェアユニットまたはMSDC)が、マルチキャストまたはブロードキャスト配信モードによってメディアデータを受信する可能性があり、プロキシユニットが、DASHクライアントにブロードキャスト受信ユニットへメディアデータの要求を送信させる可能性がある。一方、ブロードキャストサービスが利用可能でない場合、プロキシユニットは、ユニキャストサービスを用いてメディアデータを取り出すために、DASHクライアントにユニキャストサーバへメディアデータの要求を送信させる可能性がある。代替的に、ブロードキャストサービスが利用可能でない場合、プロキシユニットが、ユニキャストサーバからメディアデータを取り出し、それから、取り出されたメディアデータをDASHクライアントに提供する可能性がある。
別の例として、RTPおよび/またはRTSPに関連して、(追加的にまたは代替的にRTSPクライアントに対応する可能性がある)RTPクライアントは、プロキシユニットにDESCRIBE、SETUP、およびPLAYコマンドを送る可能性がある。DESCRIBEコマンドに応答して、プロキシユニットは、RTPクライアントにセッション記述プロトコル(SDP)メッセージを与える可能性がある。SDPメッセージは、ユニキャストサーバのアドレスをメディアデータが入手可能であるアドレスとして指定する可能性がある。このSDPメッセージは、RTPクライアントにユニキャストサーバへSETUPおよびPLAYコマンドを送信させる可能性がある。プロキシユニットは、ブロードキャストサービスが利用可能であると(受信された指示に基づいて)判定するとき、SETUPおよびPLAYコマンドをブロードキャスト受信ユニット(たとえば、MBMSまたはeMBMSミドルウェアユニットまたはMSDC)に送信する可能性があり、ブロードキャスト受信ユニットが、ブロードキャストまたはマルチキャスト配信モードによってメディアデータを受信し、メディアデータをRTPクライアントに転送する可能性がある。一方、プロキシユニットは、ブロードキャストサービスが利用可能でないと判定するとき、ユニキャストサーバからメディアデータを取り出し、それから、取り出されたメディアデータをRTPクライアントに提供する可能性がある。
一部の例において、本開示の技術を実行するための構成要素は、ストリーミング/ファイルダウンロードクライアントおよびブロードキャスト受信ユニットを含む可能性がある。様々な例において、クライアントデバイスは、これらの構成要素のどちらかまたは両方を単独でまたは任意の組合せで含む可能性がある。一部の例において、クライアントデバイスは、プロキシユニット、ショートメッセージサービス(SMS)受信ユニット、OMA-DM受信ユニット、ワイヤレスアプリケーションプロトコル(WAP)メッセージ受信ユニット、通信ユニット(たとえば、モデム)、またはその他の構成要素などのその他の構成要素を含む可能性がある。様々な例において、UEのプロキシユニット、UEのストリーミング/ファイルダウンロードクライアント、および/またはUEのクライアントアプリケーションのうちの1つまたは複数によって実行されるものとして説明されるが、一部の例においては、様々な機能が、本明細書において説明される技術に従ってその他の構成要素によって実行される可能性がある。たとえば、一部の例においては、プロキシユニットが、ストリーミング/ファイルダウンロードクライアント機能とプロキシ/リダイレクト機能との両方を提供する可能性がある。一部の例においては、クライアントデバイス(またはユーザ機器)の一部として説明されるが、様々な構成要素が、本明細書において説明される機能を有するが、互いに分かれており、異なる可能性がある。たとえば、クライアントデバイスが、ストリーミング/ファイルダウンロードクライアントを含む可能性があり、1つまたは複数のその他の構成要素が、クライアントデバイスとは分かれている1つまたは複数のデバイスに含まれる可能性がある。
本開示の技術は、ISOに基づくメディアファイルフォーマット、スケーラブルビデオ符号化(SVC: Scalable Video Coding)ファイルフォーマット、高度ビデオ符号化(AVC)ファイルフォーマット、第3世代パートナーシッププロジェクト(3GPP)ファイルフォーマット、および/またはマルチビュービデオ符号化(MVC: Multiview Video Coding)ファイルフォーマット、またはその他の同様のビデオファイルフォーマットのいずれかによってカプセル化されるビデオデータに準拠するビデオファイルに適用され得る。本開示の1つまたは複数の技術は、ファイルデータまたはその他のアプリケーションデータなどのその他の種類のデータにもさらに当てはまる可能性がある。つまり、特定の例においてはストリーミングメディアデータに関連して説明されるが、本開示の技術は、1つまたは複数のサービスおよび/または配信モードを選択的に使用することによって1つまたは複数のネットワークを介して任意の種類のデータを取得することに当てはまる可能性がある。
HTTPストリーミングでは、頻繁に使用される動作が、HEAD、GET、およびpartial GETを含む。HEAD動作は、ユニフォームリソースロケータ(URL)またはユニフォームリソース名(URN)に関連するペイロードを取り出すことなく所与のURLまたはURNに関連するファイルのヘッダを取り出す。GET動作は、所与のURLまたはURNに関連するファイル全体を取り出す。partial GET動作は、バイト範囲を入力パラメータとして受信し、受信されたバイト範囲に対応するファイルの連続するいくつかのバイトを取り出す。したがって、partial GET動作が、1つまたは複数の個々の動画フラグメント(movie fragment)を取得することができるので、動画フラグメントが、HTTPストリーミングのために提供され得る。動画フラグメントに、異なるトラックのいくつかのトラックフラグメント(track fragment)が存在する可能性がある。HTTPストリーミングでは、メディアプレゼンテーション(media presentation)が、クライアントがアクセス可能であるデータの構築された集合である可能性がある。クライアントは、ユーザにストリーミングサービスを提示するためにメディアデータ情報を要求し、ダウンロードし得る。
HTTPストリーミングを用いて3GPPデータをストリーミングする例においては、マルチメディアコンテンツのビデオおよび/またはオーディオデータに関して複数のリプレゼンテーション(representation)が存在する可能性がある。異なるリプレゼンテーションは、異なる符号化の特徴(たとえば、ビデオ符号化規格の異なるプロファイルまたはレベル)、異なる符号化規格または(マルチビューのおよび/もしくはスケーラブルな拡張などの)符号化規格の拡張、あるいは異なるビットレートに対応する可能性がある。そのようなリプレゼンテーションのマニフェストは、メディアプレゼンテーション記述(MPD)データ構造で定義され得る。メディアプレゼンテーションが、HTTPストリーミングクライアントデバイスがアクセス可能であるデータの構築された集合に対応する可能性がある。HTTPストリーミングクライアントデバイスは、クライアントデバイスのユーザにストリーミングサービスを提示するためにメディアデータ情報を要求し、ダウンロードし得る。メディアプレゼンテーションは、MPDの更新を含む可能性があるMPDデータ構造で記述され得る。
メディアプレゼンテーションは、1つまたは複数の期間のシーケンスを含む可能性がある。期間は、MPDのPeriod要素によって定義され得る。各期間は、MPDの属性startを有する可能性がある。MPDは、各期間に関するstart属性およびavailableStartTime属性を含む可能性がある。ライブサービスに関して、期間のstart属性およびMPD属性availableStartTimeの合計が、期間の可用時間(availability time)、特に対応する期間の各々のリプレゼンテーションの第1のメディアセグメント(Media Segment)をUTCフォーマットで指定する可能性がある。オンデマンドサービスに関して、第1の期間のstart属性は、0である可能性がある。任意のその他の期間に関して、start属性は、第1のPeriodの開始時間に対する対応するPeriodの開始時間の間の時間オフセットを指定する可能性がある。各期間は、次のPeriodの開始まで、または最後の期間の場合はメディアプレゼンテーションの終了まで延びる可能性がある。期間の開始時間は、正確であり得る。それらの開始時間は、すべての前の期間のメディアを再生した結果である実際のタイミングを反映し得る。
各期間は、同じメディアコンテンツに関する1つまたは複数のリプレゼンテーションを含む可能性がある。リプレゼンテーションは、オーディオまたはビデオデータのいくつかの代替的な符号化されたバージョンのうちの1つである可能性がある。リプレゼンテーションは、符号化の種類毎、たとえば、ビデオデータのビットレート、解像度、および/またはコーデック、ならびにオーディオデータのビットレート、言語、および/またはコーデック毎に異なる可能性がある。リプレゼンテーションという用語は、マルチメディアコンテンツの特定の期間に対応し、特定の方法で符号化された符号化されたオーディオまたはビデオデータのセクションを指すために使用され得る。
特定の期間のリプレゼンテーションが、MPDの属性によって示されたグループに割り当てられる可能性がある。概して、同じ適応セット(adaptation set)のリプレゼンテーションは、クライアントデバイスが、たとえば、帯域幅の適応を実行するためにこれらのリプレゼンテーションの間を動的に切れ目なく切り替えることができるという点で互いの代替であると考えられる。たとえば、特定の期間のビデオデータの各々のリプレゼンテーションは、対応する期間のマルチメディアコンテンツのビデオデータまたはオーディオデータなどのメディアデータを提示するために復号するためにリプレゼンテーションのいずれかが選択され得るように同じ適応セットに割り当てられる可能性がある。一部の例において、1つの期間内のメディアコンテンツは、存在する場合、グループ0からの1つのリプレゼンテーションか、またはそれぞれの非ゼロのグループから最大で1つのリプレゼンテーションの組合せかのどちらかによって表される可能性がある。期間の各々のリプレゼンテーションに関するタイミングデータは、期間の開始時間に対して相対的に表される可能性がある。
リプレゼンテーションは、1つまたは複数のセグメントを含む可能性がある。各リプレゼンテーションが、初期化セグメントを含む可能性があり、またはリプレゼンテーションの各セグメントが、自己初期化している可能性がある。存在するとき、初期化セグメントは、リプレゼンテーションにアクセスするための初期化情報を含み得る。概して、初期化セグメントは、メディアデータを含まない。セグメントは、URL、URN、または統一資源識別子(URI)などの識別子によって一意に参照され得る。MPDは、各セグメントに関する識別子を提供し得る。一部の例において、MPDは、URL、URN、またはURIによってアクセス可能なファイル内のセグメントに関するデータに対応する可能性があるバイト範囲をrange属性の形式でさらに提供し得る。
異なる種類のメディアデータに関する実質的に同時の取り出しのために、異なるリプレゼンテーションが選択される可能性がある。たとえば、クライアントデバイスは、セグメントを取り出すべきオーディオリプレゼンテーション、ビデオリプレゼンテーション、およびタイミングを指定されたテキストリプレゼンテーションを選択し得る。一部の例において、クライアントデバイスは、帯域幅の適応を実行するために特定の適応セットを選択し得る。つまり、クライアントデバイスは、ビデオリプレゼンテーションを含む適応セット、オーディオリプレゼンテーションを含む適応セット、および/またはタイミングを指定されたテキストを含む適応セットを選択し得る。代替的に、クライアントデバイスは、特定の種類のメディア(たとえば、ビデオ)に関する適応セットを選択し、その他の種類のメディア(たとえば、オーディオおよび/またはタイミングを指定されたテキスト)に関するリプレゼンテーションを直接選択し得る。
それぞれのリプレゼンテーションは、1つまたは複数のメディア構成要素も含む可能性があり、それぞれのメディア構成要素は、オーディオ、ビデオ、または(たとえば、字幕をつけるための)タイミングを指定されたテキストなどの1つの個々のメディアの種類の符号化されたバージョンに対応する可能性がある。メディア構成要素は、1つのリプレゼンテーション内の連続するメディアセグメントの境界をまたいで時間的に連続している可能性がある。
本明細書において説明される技術は、CDMA、TDMA、FDMA、OFDMA、SC-FDMA、およびその他のネットワークなどの様々な有線またはワイヤレス通信ネットワークのために使用され得る。「ネットワーク」および「システム」という用語は、多くの場合、交換可能であるように使用される。CDMAネットワークは、ユニバーサル地上無線アクセス(UTRA)、CDMA2000などの無線テクノロジーを実装し得る。UTRAは、広帯域CDMA(WCDMA（登録商標）)およびCDMAのその他の変形形態を含む。CDMA2000は、IS-2000、IS-95、およびIS-856規格を包含する。TDMAネットワークは、移動体通信用グローバルシステム(GSM（登録商標）)などの無線テクノロジーを実装し得る。OFDMAネットワークは、進化型UTRA(E-UTRA)、ウルトラモバイルブロードバンド(UMB)、IEEE 802.11(Wi-Fi)、IEEE 802.16(WiMAX)、IEEE 802.20、Flash-OFDMAなどの無線テクノロジーを実装し得る。UTRAおよびE-UTRAは、ユニバーサル移動体通信システム(UMTS: Universal Mobile Telecommunication System)の一部である。3GPPロングタームエボリューション(LTE)およびLTE-Advanced(LTE-A)は、E-UTRAを使用するUMTSの新しいリリースである。UTRA、E-UTRA、UMTS、LTE、LTE-A、およびGSM（登録商標）は、「第3世代パートナーシッププロジェクト」(3GPP)と名付けられた組織からの文書に記載されている。CDMA2000およびUMBは、「第3世代パートナーシッププロジェクト2」(3GPP2)と名付けられた組織からの文書に記載されている。本明細書において説明される技術は、上述のワイヤレスネットワークおよび無線テクノロジーならびにその他のワイヤレスネットワークおよび無線テクノロジーのために使用され得る。明確にするために、技術の特定の態様が、LTEに関して以下で説明され、LTEの用語が、以下の説明の多くで使用される。
様々なネットワークにおいて、コンテンツは、ユニキャストまたはブロードキャストによって配信され得る。UEがコンテンツを要求するとき、コンテンツに関するMBMSユーザサービスが利用可能でない可能性があり、したがって、MBMSクライアントは関与させられない。一部の例においては、UEがネットワークの異なるエリアに入るとき、またはネットワークのデバイスが十分なUEがコンテンツにアクセスしていると判定するときなどに、ネットワークのデバイスは、MBMSベアラサービスを有効化し得る。たとえば、高アタッチレートに基づいてネットワークのデバイスがコンテンツのためにMBMS送信を有効化すると決定するとき、コンテンツを要求するUEのMBMSクライアントをアクティブ化するための方法が必要とされる。本開示は、一例において、ローカルプロキシがネットワークリダイレクトされるときにMBMSクライアントをアクティブ化するようにローカルプロキシを含めることを提案する。つまり、UEは、UEがMBMSユーザサービスに潜在的に切り替えられ得るようにユニキャストサービスのためのローカルプロキシを含み得る。加えて、MBMSクライアントは、ブロードキャストまたはマルチキャスト配信モードによってMBMSユーザサービスからデータを受信し始める可能性があり、ローカルプロキシは、UEがそれによってユニキャスト配信モードからブロードキャスト配信モードに切り替えることを可能にする可能性がある。ローカルプロキシを含むことによって、アプリケーションは、コンテンツ配信のためにユニキャストベアラが使用されるのかまたはMBMSベアラが使用されるのか、およびユニキャスト配信モードが使用されるのかまたはブロードキャスト配信モードが使用されるのかに関知しない。つまり、一部の例においては、コンテンツが配信されるアプリケーションが、コンテンツがユニキャスト配信モードによって配信されるのか、ブロードキャスト配信モードによって配信されるのか、またはマルチキャスト配信モードによって配信されるのかについての情報を受信する必要がない。
本明細書において説明される技術は、特定のコンテンツの人気が原因で特定のトラフィックの量に達するリアルタイムまたは非リアルタイムの特定のコンテンツのユニキャスト配信をオフロードするためのMBMSユーザサービスの動的な確立を提供し得る。さらに、本明細書において説明される技術は、そのコンテンツの消費のその後の減少が原因である前に確立されたMBMSユーザサービスの終了を提供し得る。そのようなオンデマンドのMBMSをサポートするように構成されたBM-SCおよびUEの機能の態様も、説明される。つまり、本開示は、MooDに関連した高レベルのMBMSおよびユニキャストネットワークアーキテクチャの説明、MooD動作の例を示すメッセージシーケンス図、および/または(たとえば、構成データを含む)MooD動作を可能にし得るソリューションのフレームワークの説明、ならびに新たに確立されたMBMSユーザサービスの受信のためにMBMSクライアントをアクティブ化またはトリガするためのBM-SCとUEとの間のインタラクション、およびMBMSサービスに関する継続している需要の測定を可能にするためのそのサービスの継続している消費の報告を提供し得る。
本開示の技術は、MBMSサービスの動的な、需要に基づくプロビジョニングを提供し得る。つまり、MBMSユーザサービスは、サービスプロバイダ(たとえば、モバイルネットワーク事業者)によって静的に、または特定の時間にわたって変わり得るようにプロビジョニングされる必要がない可能性がある。本明細書において説明される技術によれば、サービスプロバイダは、MBMSベアラでの配信への動的な変換を可能にするために、ユニキャストベアラによるコンテンツの消費のリアルタイムの、需要に基づく測定を使用し得る。たとえば、本明細書において説明される技術を用いて、サービスプロバイダは、複数のUEによる共通の地理的地域内での同じコンテンツまたはサービスへのユニキャストアクセスの十分に高いレート/量を検出すると、ユニキャストサービスをブロードキャスト配信のためにMBMSユーザサービスに動的に変換し得る。さらに、本明細書において説明される技術は、サービスプロバイダネットワークがMBMSユーザサービスに関するユニキャストサービスのふさわしさをUEに示すための手段と、ユニキャストサービスによってコンテンツを現在消費しているUEがブロードキャストサービスを介してコンテンツを受信するためのUEの能力(またはその欠如)に関してサービスプロバイダネットワークに知らせることを可能にし得る方法との基準を定める説明を提供し得る。
本明細書において説明される技術は、追加的にまたは代替的に、MBMSサービスの動的な、需要に基づく終了を含む可能性がある。つまり、本開示は、継続しているMBMSユーザサービスを終了するためにサービスプロバイダネットワークが使用し得る方法を提供する。たとえば、MBMSユーザサービスの登録解除イベントの(たとえば、コンテンツプロバイダおよび/またはサービスプロバイダによって設定された)特定の閾値が超えられた、または実際のコンテンツの消費のネットワークに基づく集計の何らかの形態が特定の最小レベル未満になるとネットワーク内のデバイスが判定するとき、ネットワークによって開始されたMBMSユーザサービスの終了がトリガされ得る。
本開示の技術は、追加的にまたは代替的に、スケーラブルな方法で潜在的MBMSユーザサービスについてMBMS対応UEに知らせるためにサービスプロバイダネットワーク(たとえば、サービスプロバイダネットワーク内のBM-SC)が使用し得る方法を提供する。潜在的MBMSユーザサービスは、MBMSユーザサービスに潜在的にマイグレーションされる得る非MBMSユーザサービスである可能性がある。たとえば、本明細書において説明される技術は、ネットワークが静的な構成を用いて動作することを可能にする可能性があり、UEは、特定のサービスが常に潜在的MBMSユーザサービスであるように構成される。別の例として、ネットワークは、特定のサービスがMBMSユーザサービスであるようにネットワークの運用者がUEを動的に構成し得るデバイス管理方法を使用する可能性がある。別の例として、ネットワークのデバイスは、サービスを特定のMBMSユーザサービスとして告知する特定のUSDを使用することによって、MBMSユーザサービスの使用を介してUEに通知し得る。さらに、本明細書において説明される技術は、UEが潜在的MBMSユーザサービスの消費についてサービスプロバイダネットワーク(たとえば、BM-SC)に継続的に知らせることを可能にし得る。一部の例において、UEは、位置または消費のメタデータなどのその他の情報をサービスプロバイダネットワークに知らせる可能性もある。たとえば、UEは、サービスに直接登録する可能性があり、特定のAPIまたはプロトコルを用いてBM-SCが通知され続けるようにし得る。別の例として、UEは、クエリパラメータおよび/またはクッキーによって強化された、(たとえば、特定のプロキシへの)構成に従って生成される特定のHTTP要求を使用し得る。
また、本明細書において説明される技術は、サービスプロバイダネットワークがMBMSユーザサービスを確立し、MBMSユーザサービスがすでに確立されていると、サービスを現在消費しているMBMS対応UEまたは潜在的MBMSユーザサービスに加わっているMBMS対応UEにMBMSユーザサービスを告知することを可能にし得る。たとえば、ネットワークのデバイスは、構成で定義されているあらかじめ構成されたAPI/プロトコルを用いてMBMS対応UEにUSDを送信し得る。別の例として、ネットワークのデバイスは、USDを、サービス配信の一部、サービスプロトコルの一部かまたはフォーマットの一部かのどちらかとして送信し得る。加えて、本明細書において説明される技術は、一部の例においては、UEのサービスの終了についてサービスプロバイダネットワークに知らせることを含め、UEがスケーラブルな方法でUEの消費についてサービスプロバイダネットワーク(たとえば、BM-SC)に継続的に知らせることを可能にし得る。
様々な例において、本開示の技術は、1つまたは複数の仮定に基づく可能性がある。たとえば、一部の例において、本明細書において説明される技術は、MBMSユーザサービスのユニキャスト配信モードとブロードキャスト配信モードとの間の動的な切り替えに関する以下の仮定に基づく可能性があり、すなわち、第1に、ビジネスの合意(business agreement)が、名目的なユニキャストコンテンツまたはサービスの需要が高いと、(たとえば、サービスプロバイダネットワークの)運用者が様々なコンテンツフィードをユニキャストからブロードキャスト配信に変換することを可能にすると仮定される可能性があり、第2に、運用者が、UEの能力、UEの位置、および時間シフトなどのユーザのアクションを考慮に入れてサービスの消費を正確に集計したいと仮定される可能性がある。もちろん、本開示の技術がこれらの仮定のいずれも必要としないことは理解されるであろう。
図1は、ネットワークを介してメディアデータをストリーミングするための技術を実装する例示的なシステム10を示すブロック図である。この例において、システム10は、コンテンツ準備デバイス20、サーバデバイス60、およびクライアントデバイス40を含む。クライアントデバイス40およびサーバデバイス60は、インターネットを含む可能性があるネットワーク74によって通信可能なように結合される。一部の例において、コンテンツ準備デバイス20およびサーバデバイス60は、さらに、ネットワーク74もしくは別のネットワークによって結合される可能性があり、または直接通信可能なように結合される可能性がある。一部の例において、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを含む可能性がある。
図1の例のコンテンツ準備デバイス20は、オーディオソース22およびビデオソース24を含む。オーディオソース22は、たとえば、オーディオエンコーダ26によって符号化されるキャプチャされたオーディオデータを表す電気信号を生成するマイクロフォンを含み得る。代替的に、オーディオソース22は、前に記録されたオーディオデータを記憶するストレージ媒体、コンピュータ化されたシンセサイザなどのオーディオデータジェネレータ、またはオーディオデータの任意のその他のソースを含み得る。ビデオソース24は、ビデオエンコーダ28によって符号化されるビデオデータを生成するビデオカメラ、前に記録されたビデオデータを有する符号化されたストレージ媒体、コンピュータグラフィックスソースなどのビデオデータ生成ユニット、またはビデオデータの任意のその他のソースを含み得る。コンテンツ準備デバイス20は、必ずしもすべての例においてサーバデバイス60に通信可能なように結合されず、サーバデバイス60によって読まれる別個の媒体にマルチメディアコンテンツを記憶する可能性がある。
生オーディオおよびビデオデータは、アナログまたはデジタルデータを含む可能性がある。アナログデータは、オーディオエンコーダ26および/またはビデオエンコーダ28によって符号化される前にデジタル化される可能性がある。オーディオソース22は、発話する参加者が話している間に発話する参加者からオーディオデータを得る可能性があり、ビデオソース24は、発話する参加者のビデオデータを同時に得る可能性がある。その他の例において、オーディオソース22は、記憶されたオーディオデータを含むコンピュータ可読ストレージ媒体を含む可能性があり、ビデオソース24は、記憶されたビデオデータを含むコンピュータ可読ストレージ媒体を含む可能性がある。このようにして、本開示において説明される技術は、ライブ、ストリーミング、リアルタイムオーディオおよびビデオデータに、またはアーカイブされたあらかじめ記録されたオーディオおよびビデオデータに適用され得る。
概して、ビデオフレームに対応するオーディオフレームは、ビデオフレーム内に含まれるビデオソース24によってキャプチャされた(または生成された)ビデオデータと同時にオーディオソース22によってキャプチャされた(または生成された)オーディオデータを含むオーディオフレームである。たとえば、概して、発話する参加者が話すことによって音声データを生成する間に、オーディオソース22がオーディオデータをキャプチャし、同時に、つまり、オーディオソース22がオーディオデータをキャプチャしている間に、ビデオソース24が発話する参加者のビデオデータをキャプチャする。ゆえに、オーディオフレームは、1つまたは複数の特定のビデオフレームに時間的に対応する可能性がある。したがって、概して、ビデオフレームに対応するオーディオフレームは、オーディオデータおよびビデオデータが同時にキャプチャされ、オーディオフレームおよびビデオフレームが同時にキャプチャされたオーディオデータおよびビデオデータをそれぞれ含む状況に対応する。
一部の例において、オーディオエンコーダ26は、符号化されたオーディオフレームに関するオーディオデータが記録された時間を表すタイムスタンプをそれぞれの符号化されたオーディオフレームに符号化する可能性があり、同様に、ビデオエンコーダ28は、符号化されたビデオフレームに関するビデオデータが記録された時間を表すタイムスタンプをそれぞれの符号化されたビデオフレームに符号化する可能性がある。そのような例においては、ビデオフレームに対応するオーディオフレームが、タイムスタンプを含むオーディオフレームと同じタイムスタンプを含むビデオフレームとを含む可能性がある。コンテンツ準備デバイス20は、オーディオエンコーダ26および/もしくはビデオエンコーダ28がタイムスタンプを生成する可能性があり、またはオーディオおよびビデオデータをそれぞれタイムスタンプに関連付けるためにオーディオソース22およびビデオソース24が使用する可能性がある内部クロックを含み得る。
一部の例において、オーディオソース22は、オーディオデータが記録された時間に対応するデータをオーディオエンコーダ26に送信する可能性があり、ビデオソース24は、ビデオデータが記録された時間に対応するデータをビデオエンコーダ28に送信する可能性がある。一部の例において、オーディオエンコーダ26は、符号化されたオーディオデータの相対的な時間的順序を示すが、オーディオデータが記録された絶対的な時間を必ずしも示さないシーケンス識別子を符号化されたオーディオデータに符号化する可能性があり、同様に、ビデオエンコーダ28は、符号化されたビデオデータの相対的な時間的順序を示すためにシーケンス識別子をやはり使用する可能性がある。同様に、一部の例においては、シーケンス識別子が、タイムスタンプにマッピングされるかまたはその他の方法で相互に関連付けられる可能性がある。
概して、オーディオエンコーダ26は、符号化されたオーディオデータのストリームを生成し、一方、ビデオエンコーダ28は、符号化されたビデオデータのストリームを生成する。(オーディオかまたはビデオかにかかわらず)データの各々の個々のストリームは、エレメンタリストリーム(elementary stream)と呼ばれる可能性がある。エレメンタリストリームは、リプレゼンテーションの単一のデジタル式に符号化された(おそらくは圧縮された)構成要素である。たとえば、リプレゼンテーションの符号化されたビデオまたはオーディオ部分が、エレメンタリストリームである可能性がある。エレメンタリストリームは、ビデオファイル内にカプセル化される前にパケット化エレメンタリストリーム(PES: packetized elementary stream)に変換され得る。同じリプレゼンテーション内で、1つのエレメンタリストリームに属するPESパケットをその他と区別するためにストリームIDが使用され得る。エレメンタリストリームのデータの基本単位は、パケット化エレメンタリストリーム(PES)パケットである。したがって、概して、符号化されたビデオデータは、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数の各々のエレメンタリストリームに対応する。
ITU-T H.264/AVCおよび近く登場する高効率ビデオ符号化(HEVC: High Efficiency Video Coding)規格などの多くのビデオ符号化規格は、エラーのないビットストリームのためのシンタックス、セマンティックス、および復号プロセスを定義し、それらのビットストリームのいずれもが、特定のプロファイルまたはレベルに準拠する。典型的に、ビデオ符号化規格は、エンコーダを規定しないが、エンコーダは、デコーダのために生成されたビットストリームが規格に準拠していることを保証するタスクを与えられる。ビデオ符号化規格に関連して、「プロファイル」は、アルゴリズム、特徴、またはツール、およびそれらに当てはまる制約のサブセットに対応する。たとえば、H.264規格によって定義されるように、「プロファイル」は、H.264規格によって規定されるビットストリームのシンタックス全体のサブセットである。「レベル」は、たとえば、ピクチャの解像度、ビットレート、およびブロック処理レートに関連するデコーダのメモリおよび計算などのデコーダのリソースの消費の制限に対応する。プロファイルは、profile_idc(プロファイルインジケータ)の値によってシグナリングされ得る一方、レベルは、level_idc(レベルインジケータ)の値によってシグナリングされ得る。
たとえば、H.264規格は、所与のプロファイルのシンタックスによって課された限界内で、復号されるピクチャの指定されたサイズなどのビットストリームのシンタックス要素によって取られる値に応じてエンコーダおよびデコーダの性能の大きな変動を必要とすることが引き続きあり得ることを認識する。H.264規格は、多くの応用において、特定のプロファイル内のシンタックスのすべての仮定に基づく使用を扱うことができるデコーダを実装することが現実的でなく、経済的でもないことをさらに認識する。したがって、H.264規格は、ビットストリームのシンタックス要素の値に課される規定された1組の制約として「レベル」を定義する。これらの制約は、値に対する単純な制限である可能性がある。代替的に、これらの制約は、値の算術的な組合せ(たとえば、ピクチャの幅×ピクチャの高さ×毎秒復号されるピクチャの数)に対する制約の形態を取る可能性がある。H.264規格は、個々の実装がそれぞれのサポートされるプロファイルに関して異なるレベルをサポートし得ることをさらに規定する。
プロファイルに準拠するデコーダは、通常、プロファイルで定義されたすべての特徴をサポートする。たとえば、符号化の特徴として、Bピクチャの符号化が、H.264/AVCの基底プロファイルではサポートされないが、H.264/AVCのその他のプロファイルではサポートされる。レベルに準拠するデコーダは、レベルで定義された制限を超えてリソースを必要としない任意のビットストリームを復号することができるべきである。プロファイルおよびレベルの定義は、解釈の可能性に寄与し得る。たとえば、ビデオ送信中、プロファイルの定義とレベルの定義との対が、送信セッション全体に関してネゴシエーションされ、合意される可能性がある。より詳細には、H.264/AVCにおいては、レベルが、処理される必要があるマクロブロックの数、復号ピクチャバッファ(DPB)サイズ、符号化ピクチャバッファ(CPB)サイズ、垂直動きベクトルの範囲、2つの連続するMB毎の動きベクトルの最大数、およびBブロックが8x8ピクセル未満のサブマクロブロックの区画を有することができるかどうかに関する制限を定義し得る。このようにして、デコーダは、デコーダがビットストリームを適切に復号することができるかどうかを判定し得る。
図1の例においては、コンテンツ準備デバイス20のカプセル化ユニット30が、ビデオエンコーダ28からの符号化されたビデオデータを含むエレメンタリストリームと、オーディオエンコーダ26からの符号化されたオーディオデータを含むエレメンタリストリームとを受信する。一部の例において、ビデオエンコーダ28およびオーディオエンコーダ26は、それぞれ、符号化されたデータからPESパケットを形成するためのパケタイザを含み得る。その他の例において、ビデオエンコーダ28およびオーディオエンコーダ26は、それぞれ、符号化されたデータからPESパケットを形成するための各々のパケタイザとインターフェースをとり得る。さらにその他の例においては、カプセル化ユニット30が、符号化されたオーディオおよびビデオデータからPESパケットを形成するためのパケタイザを含み得る。
ビデオエンコーダ28は、様々なビットレートで、ピクセル解像度、フレームレート、様々な符号化規格への準拠、様々な符号化規格に関する様々なプロファイルおよび/もしくはプロファイルのレベルへの準拠、(たとえば、2次元もしくは3次元再生のための)1つもしくは複数のビュー(view)を有するリプレゼンテーション、またはその他のそのような特徴などの様々な特徴を有するマルチメディアコンテンツの異なるリプレゼンテーションを生成するためにマルチメディアコンテンツのビデオデータを様々な方法で符号化し得る。本開示において使用されるとき、リプレゼンテーションは、オーディオデータ、ビデオデータ、(たとえば、字幕のための)テキストデータ、またはその他のそのようなデータのうちの1つを含み得る。リプレゼンテーションは、オーディオエレメンタリストリームまたはビデオエレメンタリストリームなどのエレメンタリストリームを含み得る。各PESパケットは、PESパケットが属するエレメンタリストリームを特定するstream_idを含み得る。カプセル化ユニット30は、様々なリプレゼンテーションのビデオファイル(たとえば、セグメント)へとエレメンタリストリームを組み立てる責任を負う。
カプセル化ユニット30は、オーディオエンコーダ26およびビデオエンコーダ28からリプレゼンテーションのエレメンタリストリームに関するPESパケットを受信し、PESパケットから対応するネットワーク抽象化レイヤ(NAL: network abstraction layer)ユニットを形成する。H.264/AVC(高度ビデオ符号化)の例においては、符号化されたビデオセグメントが、テレビ電話、ストレージ、ブロードキャスト、またはストリーミングなどの応用に対応する「ネットワークに適した」ビデオリプレゼンテーションを提供するNALユニットへと編成される。NALユニットは、ビデオ符号化レイヤ(VCL)NALユニットおよび非VCL NALユニットにカテゴリ分けされ得る。VCLユニットは、コア圧縮エンジンを含む可能性があり、ブロック、マクロブロック、および/またはスライスレベルのデータを含む可能性がある。その他のNALユニットは、非VCL NALユニットである可能性がある。一部の例においては、通常は主符号化ピクチャ(primary coded picture)として提示される1つのタイムインスタンス(time instance)の符号化されたピクチャが、1つまたは複数のNALユニットを含み得るアクセスユニットに含まれる可能性がある。
非VCL NALユニットは、とりわけ、パラメータセットNALユニットおよびSEI NALユニットを含み得る。パラメータセットは、(シーケンスパラメータセット(SPS)に)シーケンスレベルのヘッダ情報を含み、(ピクチャパラメータセット(PPS)に)頻繁に変わらないピクチャレベルのヘッダ情報を含む可能性がある。パラメータセット(たとえば、PPSおよびSPS)により、頻繁に変わらない情報がそれぞれのシーケンスまたはピクチャに関して繰り返される必要がなく、したがって、符号化効率が改善され得る。さらに、パラメータセットの使用は、重要なヘッダ情報の帯域外送信を可能にし、誤り耐性のための冗長な送信の必要を避ける可能性がある。帯域外送信の例において、パラメータセットNALユニットは、SEI NALユニットなどのその他のNALユニットとは異なるチャネルで送信され得る。
補足強化情報(SEI: Supplemental Enhancement Information)は、VCL NALユニットから符号化されたピクチャサンプルを復号するために必要でない情報を含む可能性があるが、復号、表示、誤り耐性、およびその他の目的に関連するプロセスを支援し得る。SEIメッセージは、非VCL NALユニットに含まれる可能性がある。SEIメッセージは、いくつかの規格の仕様の基準を定める部分であり、したがって、標準に準拠するデコーダの実装に常に必須であるわけではない。SEIメッセージは、シーケンスレベルのSEIメッセージまたはピクチャレベルのSEIメッセージである可能性がある。一部のシーケンスレベルの情報は、SVCの例のスケーラビリティ情報SEIメッセージおよびMVCのビュースケーラビリティ情報SEIメッセージなどのSEIメッセージに含まれる可能性がある。これらの例示的なSEIメッセージは、たとえば、動作点(operation point)および動作点の特徴の抽出に関する情報を運ぶ可能性がある。加えて、カプセル化ユニット30は、リプレゼンテーションの特徴を記述するメディアプレゼンテーション記述子(MPD: media presentation descriptor)などのマニフェストファイルを形成し得る。カプセル化ユニット30は、拡張可能マークアップ言語(XML)に従ってMPDをフォーマットする可能性がある。(マニフェストファイル66などの)マニフェストファイルは、一部の例において、様々なリプレゼンテーション(たとえば、リプレゼンテーション68)に関する識別子を対応するリソースの位置にマッピングし得る。つまり、マニフェストファイルは、リプレゼンテーション(またはその一部)が取得され得る場所を示す情報を含む可能性がある。一部の例において、リソースの位置は、ユニフォームリソースロケータ(URL)、統一資源識別子(URI)、および/またはその他の位置識別子である可能性がある。たとえば、マニフェストファイルは、様々なリプレゼンテーションのセグメントに関するURLを定義するデータを含む可能性がある。
カプセル化ユニット30は、マルチメディアコンテンツの1つまたは複数のリプレゼンテーションに関するデータをマニフェストファイル(たとえば、MPD)とともに出力インターフェース32に提供し得る。出力インターフェース32は、ネットワークインターフェース、またはユニバーサルシリアルバス(USB)インターフェース、CDもしくはDVDライタもしくはバーナ、磁気もしくはフラッシュストレージ媒体へのインターフェースなどのストレージ媒体への書き込むためのインターフェース、またはメディアデータを記憶もしくは送信するためのその他のインターフェースを含み得る。カプセル化ユニット30は、ネットワーク送信またはストレージ媒体によってサーバデバイス60にデータを送信し得る出力インターフェース32にマルチメディアコンテンツのリプレゼンテーションの各々のデータを提供し得る。図1の例において、サーバデバイス60は、それぞれがそれぞれのマニフェストファイル66および1つまたは複数のリプレゼンテーション68A〜68N(リプレゼンテーション68)を含む様々なマルチメディアコンテンツ64を記憶するストレージ媒体62を含む。一部の例において、出力インターフェース32は、ネットワーク74にデータを直接送信する可能性もある。
一部の例において、リプレゼンテーション68は、適応セットに分けられる可能性がある。つまり、リプレゼンテーション68の様々なサブセットが、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントに関するファイルフォーマット、リプレゼンテーション、および/または復号され、たとえばスピーカによって与えられるオーディオデータとともに表示されるテキストの言語またはその他の特徴を特定し得るテキストタイプ情報、適応セットのリプレゼンテーションに関するシーンのカメラアングルまたは現実の世界のカメラパースペクティブを記述し得るカメラアングル情報、特定の視聴者に関するコンテンツの好適さを記述するレーティング情報などの特徴の各々の共通の組を含む可能性がある。
マニフェストファイル66は、特定の適応セットに対応するリプレゼンテーション68のサブセットと、適応セットに関する共通の特徴とを示すデータを含む可能性がある。マニフェストファイル66は、適応セットの個々のリプレゼンテーションに関するビットレートなどの個々の特徴を表すデータも含む可能性がある。このようにして、適応セットは、単純化されたネットワーク帯域幅の適応を提供し得る。適応セットのリプレゼンテーションは、マニフェストファイル66の適応セット要素の子要素を用いて示される可能性がある。
サーバデバイス60は、要求処理ユニット70およびネットワークインターフェース72を含む。一部の例において、サーバデバイス60は、複数のネットワークインターフェースを含む可能性がある。さらに、サーバデバイス60の特徴のいずれかまたはすべては、ルータ、ブリッジ、プロキシデバイス、スイッチ、またはその他のデバイスなどのコンテンツ配信ネットワークのその他のデバイスで実装される可能性がある。一部の例においては、コンテンツ配信ネットワークの中間デバイスが、マルチメディアコンテンツ64のデータをキャッシュし、サーバデバイス60の構成要素に実質的に適合する構成要素を含む可能性がある。概して、ネットワークインターフェース72は、ネットワーク74を介してデータを送信および受信するように構成される。
要求処理ユニット70は、ストレージ媒体62のデータに関してクライアントデバイス40などのクライアントデバイスからネットワーク要求を受信するように構成される。たとえば、要求処理ユニット70は、Fieldingら、「Hypertext Transfer Protocol - HTTP/1.1」、Internet Engineering Task Force (IETF)、RFC 2616、1999年6月によって記載されたハイパーテキスト転送プロトコル(HTTP)バージョン1.1を実装する可能性がある。つまり、要求処理ユニット70は、HTTP GETまたはpartial GET要求を受信し、要求に応答してマルチメディアコンテンツ64のデータを提供するように構成され得る。要求は、たとえば、セグメントのURLを用いてリプレゼンテーション68のうちの1つのセグメントを指定する可能性がある。一部の例において、要求は、セグメントの1つまたは複数のバイト範囲を指定し、したがって、partial GET要求を含む可能性がある。要求処理ユニット70は、HTTP HEAD要求にサービスを提供して、リプレゼンテーション68のうちの1つのセグメントのヘッダデータを提供するようにさらに構成される可能性がある。いずれにせよ、要求処理ユニット70は、要求を処理して、クライアントデバイス40などの要求元のデバイスに要求されたデータを提供するように構成され得る。
追加的にまたは代替的に、要求処理ユニット70は、eMBMSなどのブロードキャストまたはマルチキャストプロトコルによってメディアデータを配信するように構成され得る。コンテンツ準備デバイス20は、説明されたのと実質的に同じ方法でDASHセグメントおよび/またはサブセグメントを生成する可能性があるが、サーバデバイス60は、eMBMSまたは別のブロードキャストもしくはマルチキャストネットワーク転送プロトコルを用いてこれらのセグメントまたはサブセグメントを配信する可能性がある。たとえば、要求処理ユニット70は、クライアントデバイス40からマルチキャストグループ加入要求を受信するように構成される可能性がある。つまり、サーバデバイス60は、特定のメディアコンテンツ(たとえば、ライブイベントのブロードキャスト)に関連するクライアントデバイス40を含むクライアントデバイスにマルチキャストグループに関連するインターネットプロトコル(IP)アドレスをアドバタイズし得る。そして今度は、クライアントデバイス40が、マルチキャストグループに加わる要求を送る可能性がある。この要求は、ルータがクライアントデバイス40などの加入しているクライアントデバイスにマルチキャストグループに関連するIPアドレスに宛てられたトラフィックを導くようにされるように、ネットワーク74、たとえば、ネットワーク74を構成するルータ全体を通じて伝播され得る。
図1の例に示されたように、マルチメディアコンテンツ64は、メディアプレゼンテーション記述(MPD)に対応する可能性があるマニフェストファイル66を含む。マニフェストファイル66は、異なる代替的なリプレゼンテーション68(たとえば、異なる品質のビデオサービス)の記述を含む可能性があり、記述は、たとえば、リプレゼンテーション68のコーデック情報、プロファイルの値、レベルの値、ビットレート、およびその他の記述的な特徴を含む可能性がある。クライアントデバイス40は、リプレゼンテーション68のセグメントにどのようにしてアクセスすべきかを決定するためにメディアプレゼンテーションのMPDを取り出し得る。
特に、取り出しユニット52が、ビデオデコーダ48の復号能力およびビデオ出力44のレンダリング能力を決定するためにクライアントデバイス40の構成データ(図示せず)を取り出し得る。構成データは、クライアントデバイス40のユーザによって選択された言語のプリファレンス、クライアントデバイス40のユーザによって設定された深さのプリファレンスに対応する1つもしくは複数のカメラパースペクティブ、および/またはクライアントデバイス40のユーザによって選択されたレーティングのプリファレンスのいずれかまたはすべてを含む可能性もある。取り出しユニット52は、たとえば、HTTP GETおよびPartial GET要求を送るように構成されたウェブブラウザまたはメディアクライアントを含み得る。取り出しユニット52は、クライアントデバイス40の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行されるソフトウェア命令に対応する可能性がある。一部の例において、取り出しユニット52に関して説明される機能のすべてまたは一部は、ハードウェアにおいて実装される可能性があり、または必要なハードウェアがソフトウェアもしくはファームウェアの命令を実行するために提供され得る、ハードウェア、ソフトウェア、および/もしくはファームウェアの組合せにおいて実装される可能性がある。
取り出しユニット52は、クライアントデバイス40の復号およびレンダリング能力を、マニフェストファイル66の情報によって示されるリプレゼンテーション68の特徴と比較し得る。取り出しユニット52は、リプレゼンテーション68の特徴を判定するためにマニフェストファイル66の少なくとも一部を最初に取り出す可能性がある。たとえば、取り出しユニット52は、1つまたは複数の適応セットの特徴を記述するマニフェストファイル66の一部を要求する可能性がある。取り出しユニット52は、クライアントデバイス40の符号化およびレンダリング能力によって満足され得る特徴を有するリプレゼンテーション68のサブセット(たとえば、適応セット)を選択する可能性がある。そして、取り出しユニット52は、適応セットのリプレゼンテーションに関するビットレートを判定し、ネットワーク帯域幅の現在利用可能な量を判定し、ネットワーク帯域幅によって満足され得るビットレートを有するリプレゼンテーションのうちの1つからセグメントを取り出す可能性がある。
概して、より高いビットレートのリプレゼンテーションは、より高い品質のビデオ再生を生じる可能性があり、一方、より低いビットレートのリプレゼンテーションは、利用可能なネットワーク帯域幅が減るときに十分な品質のビデオ再生を提供する可能性がある。したがって、利用可能なネットワーク帯域幅が比較的高いとき、取り出しユニット52は、比較的高いビットレートのリプレゼンテーションからデータを取り出す可能性があり、一方、利用可能なネットワーク帯域幅が低いとき、取り出しユニット52は、比較的低いビットレートのリプレゼンテーションからデータを取り出す可能性がある。このようにして、クライアントデバイス40は、ネットワーク74の変化するネットワーク帯域幅の可用性にやはり適応しながらネットワーク74を介してマルチメディアデータをストリーミングし得る。
追加的にまたは代替的に、取り出しユニット52は、eMBMSまたはIPマルチキャストなどのブロードキャストまたはマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。そのような例において、取り出しユニット52は、特定のメディアコンテンツに関連するマルチキャストネットワークグループに加わる要求を送る可能性がある。マルチキャストグループに加わった後、取り出しユニット52は、サーバデバイス60またはコンテンツ準備デバイス20に要求がさらに発せされることなくマルチキャストグループのデータを受信し得る。取り出しユニット52は、マルチキャストグループのデータがもはや必要とされないときにマルチキャストグループを離れる、たとえば、再生を停止するかまたは異なるマルチキャストグループにチャネルを変更する要求を送る可能性がある。
ネットワークインターフェース54は、選択されたリプレゼンテーションのセグメントのデータを受信し、取り出しユニット52に提供する可能性があり、そして今度は、取り出しユニット52が、カプセル化解除ユニット50にセグメントを提供する可能性がある。カプセル化解除ユニット50は、ビデオファイルの要素を構成要素のPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化されたデータを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化されたデータがオーディオストリームの一部であるかまたはビデオストリームの一部であるかに応じてオーディオデコーダ46かまたはビデオデコーダ48かのどちらかに符号化されたデータを送信し得る。オーディオデコーダ46は、符号化されたオーディオデータを復号し、復号されたオーディオデータをオーディオ出力42に送信し、一方、ビデオデコーダ48は、符号化されたビデオデータを復号し、ストリームの複数のビューを含み得る復号されたビデオデータをビデオ出力44に送信する。
ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取り出しユニット52、およびカプセル化解除ユニット50は、適用可能な場合、それぞれ、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組合せなどの様々な好適な処理回路として実装される可能性がある。ビデオエンコーダ28およびビデオデコーダ48の各々は、1つまたは複数のエンコーダまたはデコーダに含まれる可能性があり、それらのエンコーダまたはデコーダのどちらかが、組み合わされたビデオエンコーダ/デコーダ(コーデック)の一部として組み込まれる可能性がある。同様に、オーディオエンコーダ26およびオーディオデコーダ46の各々は、1つまたは複数のエンコーダまたはデコーダに含まれる可能性があり、それらのエンコーダまたはデコーダのどちらかが、組み合わされたコーデックの一部として組み込まれる可能性がある。ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取り出しユニット52、および/またはカプセル化解除ユニット50を含む装置は、集積回路、マイクロプロセッサ、および/またはセルラー電話などのワイヤレス通信デバイスを含み得る。
クライアントデバイス40、サーバデバイス60、および/またはコンテンツ準備デバイス20は、本開示の技術に従って動作するように構成され得る。例を目的として、本開示は、クライアントデバイス40およびサーバデバイス60に関してこれらの技術を説明する。しかし、コンテンツ準備デバイス20が、サーバデバイス60の代わりに(またはそれに加えて)これらの技術を実行するように構成される可能性があることを理解されたい。
カプセル化ユニット30は、NALユニットが属するプログラムを特定するヘッダと、ペイロード、たとえば、オーディオデータ、ビデオデータ、またはNALユニットが対応するトランスポートもしくはプログラムストリームを記述するデータとを含むNALユニットを形成し得る。たとえば、H.264/AVCにおいて、NALユニットは、1バイトのヘッダおよび可変サイズのペイロードを含む。自身のペイロードにビデオデータを含むNALユニットは、ビデオデータの様々な粒度のレベルを含む可能性がある。たとえば、NALユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータのピクチャ全体を含む可能性がある。カプセル化ユニット30は、符号化されたビデオデータをビデオエンコーダ28からエレメンタリストリームのPESパケットの形式で受信する可能性がある。カプセル化ユニット30は、それぞれのエレメンタリストリームを対応するプログラムに関連付け得る。
カプセル化ユニット30は、複数のNALユニットからアクセスユニットを組み立てる可能性もある。概して、アクセスユニットは、ビデオデータのフレームと、フレームに対応するオーディオデータが利用可能なときはそのようなオーディオデータとを表すための1つまたは複数のNALユニットを含み得る。概して、アクセスユニットは、1つの出力タイムインスタンスに関するすべてのNALユニット、たとえば、1つのタイムインスタンスに関するすべてのオーディオおよびビデオデータを含む。たとえば、それぞれのビューが20フレーム毎秒(fps)のフレームレートを有する場合、各タイムインスタンスは、0.05秒の時間間隔に対応する可能性がある。この時間間隔の間に、同じアクセスユニット(同じタイムインスタンス)のすべてのビューに関する特定のフレームが、同時にレンダリングされる可能性がある。一例において、アクセスユニットは、主符号化ピクチャとして提示され得る1つのタイムインスタンスの符号化されたピクチャを含み得る。
したがって、アクセスユニットは、共通の時間的機会のすべてのオーディオおよびビデオフレーム、たとえば、時間Xに対応するすべてのビューを含む可能性がある。本開示は、特定のビューの符号化されたピクチャを「ビュー構成要素(view component)」とも呼ぶ。つまり、ビュー構成要素は、特定の時間の特定のビューに関する符号化されたピクチャ(またはフレーム)を含み得る。したがって、アクセスユニットは、共通の時間的機会のすべてのビュー構成要素として定義され得る。アクセスユニットの復号の順序は、必ずしも出力または表示の順序と同じである必要はない。
メディアプレゼンテーションは、異なる代替的なリプレゼンテーション(たとえば、異なる品質のビデオサービス)の記述を含み得るメディアプレゼンテーション記述(MPD)を含む可能性があり、記述は、たとえば、コーデック情報、プロファイルの値、およびレベルの値を含む可能性がある。MPDは、マニフェストファイル66などのマニフェストファイルの一例である。クライアントデバイス40は、様々なプレゼンテーションの動画フラグメントにどのようにしてアクセスすべきかを判定するためにメディアプレゼンテーションのMPDを取り出し得る。動画フラグメントは、ビデオファイルの動画フラグメントボックス(movie fragment box)(moofボックス(moof box))内にある可能性がある。
(たとえば、MPDを含み得る)マニフェストファイル66は、リプレゼンテーション68のセグメントの可用性をアドバタイズし得る。つまり、MPDは、リプレゼンテーション68のうちの1つの第1のセグメントが利用可能になる実時間(wall-clock time)を示す情報と、リプレゼンテーション68内のセグメントの継続時間を示す情報とを含み得る。このようにして、クライアントデバイス40の取り出しユニット52は、開始時間と特定のセグメントに先立つセグメントの継続期間とに基づいて各セグメントが利用可能であるときを判定し得る。
カプセル化ユニット30は、NALユニットおよび/またはアクセスユニットを受信されたデータに基づいてビデオファイルへと組み立てた後、出力するために出力インターフェース32にビデオファイルを渡す。一部の例において、カプセル化ユニット30は、ビデオファイルをクライアントデバイス40に直接送信するのではなく、ビデオファイルをローカルに記憶するか、またはビデオファイルを出力インターフェース32を介して遠隔のサーバに送信する可能性がある。出力インターフェース32は、たとえば、送信機、トランシーバ、たとえば、光学ドライブ、磁気媒体ドライブ(たとえばフロッピー（登録商標）ドライブ)、ユニバーサルシリアルバス(USB)ポートなどのコンピュータ可読媒体にデータを書き込むためのデバイス、ネットワークインターフェース、またはその他の出力インターフェースを含み得る。出力インターフェース32は、たとえば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、またはその他のコンピュータ可読媒体などのコンピュータ可読媒体34にビデオファイルを出力する。
ネットワークインターフェース54は、ネットワーク74を介してNALユニットまたはアクセスユニットを受信し、NALユニットまたはアクセスユニットを取り出しユニット52を介してカプセル化解除ユニット50に提供し得る。カプセル化解除ユニット50は、ビデオファイルの要素を構成要素のPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化されたデータを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化されたデータがオーディオストリームの一部であるかまたはビデオストリームの一部であるかに応じてオーディオエンコーダ46かまたはビデオデコーダ48かのどちらかに符号化されたデータを送信し得る。オーディオデコーダ46は、符号化されたオーディオデータを復号し、復号されたオーディオデータをオーディオ出力42に送信し、一方、ビデオデコーダ48は、符号化されたビデオデータを復号し、ストリームの複数のビューを含み得る復号されたビデオデータをビデオ出力44に送信する。
このようにして、クライアントデバイス40は、本開示の1つまたは複数の態様による、メディアデータを取り出すためのデバイスの例を表し、デバイスは、コンテンツサービスのメディアデータが第1のサービスを介して受信されるべきかまたは第2のサービスを介して受信されるべきかの指示を受信するための手段を含む。メディアデータが第1のサービスを介して受信されるべきであると指示が示すとき、クライアントデバイス40は、第2のサービスを介してデータを受信するためのユニットを無効化し、第1のサービスを介してメディアデータを受信する可能性がある。代替的に、メディアデータが第2のサービスを介して受信されるべきであることを指示が示すとき、クライアントデバイス40は、第2のサービスを介してデータを受信するためのユニットをアクティブ化し、第2のサービスを介してデータを受信するためのユニットからメディアデータを受信する可能性がある。第2のサービスを介してデータを受信するためのユニットは、ブロードキャストまたはマルチキャスト配信モードによってメディアデータを受信し得る。
言い換えれば、本開示の技術は、ユニキャストおよびブロードキャスト転送によるコンテンツ配信の調停を対象とする。つまり、本開示は、非MBMSユニキャストサービスがネットワークによってMBMSユーザサービスに変換されるときにMBMSミドルウェアをアクティブ化するための様々な技術を提供する。様々な例において、本開示は、ユニキャストおよびブロードキャスト(またはマルチキャスト)サービスからデータを受信することと、ブロードキャスト(またはマルチキャスト)サービスのユニキャストおよびブロードキャスト(またはマルチキャスト)配信モードによってデータを潜在的に受信することとの間を切り替えるようにクライアント(たとえば、eMBMSクライアント)をトリガするための調停レイヤを含むUEに基づく解決策とネットワークに基づく解決策との両方を含む。1つの例示的なUEに基づく解決策においては、MBMSミドルウェアが、任意のアプリケーションがオンであるときにアクティブ化される。UEは、すべてのアプリケーションに関してMBMSミドルウェアをトリガすることを避けるために、潜在的にブロードキャストコンテンツに切り替えられ得るアプリケーションを用いてあらかじめ構成される可能性がある。例示的なネットワークに基づく解決策においては、UEがネットワークから何らかの「指示」または「トリガ」を受信すると、MBMSミドルウェアがアクティブ化される。一部の例においては、ネットワークのデバイスが様々なUEの能力についての情報を有する場合、デバイス(たとえば、ネットワークのBM-SC)は、ユニキャストサービスからデータを受信しているUEがMood対応である(たとえば、MBMSユーザサービスを介してデータを受信することに切り替えることができる)かどうかを判定し得る。たとえば、ネットワークのデバイス(たとえば、OMA-DMサーバ)が、非MooD対応UEがMooD構成において指定されたプロキシサーバを使用しないことを保証しながらMooD対応UEにMooD構成データを送信し得る。MooD構成は、S4-140327、「MI-MooD: MBMS Service Configuration」、Qualcomm contribution to SA4 #78にさらに記載されており、この文献の内容全体は、参照により本明細書に組み込まれる。
指示は、UEがUSDを受信し、その後、MBMSベアラ上でデータを受信するためのトリガである可能性があり、またはUSD自体である可能性がある。一部の例において、ネットワークのデバイス(たとえば、BM-SC)は、ブロードキャストおよび/またはユニキャスト配信を介して新しいMBMSユーザサービスおよびそのMBMSユーザサービスの可用性を告知することによってUSDまたは更新されたUSDを送信し得る(たとえば、その他のMBMSサービスがすでに使用中である場合)。USDまたは更新されたUSDは、一部の例においては、コンテンツがブロードキャストおよび/またはユニキャスト転送を介して運ばれるかどうかを特定するために、userServiceDescription要素のdeliveryMethod子要素の下のr12:broadcastAppServiceおよび/またはr12:unicastAppService要素を利用する可能性がある。一部の例においては、アプリケーションサービスのアクセスのユニキャストフォールバックおよびモビリティに基づく転送の切り替えをサポートするために定義された(たとえば、3GPP TS 26.346のsection 7.6:「Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs」に見られる)既存のメカニズムも、MooD動作に適用可能である可能性がある。
一部の例において、USDまたは更新されたUSDは、MooD動作またはネットワークポリシーの要件(たとえば、UEがブロードキャストの受信にリダイレクトされ、UEがMBMSのカバレッジ内にあるとき、コンテンツのブロードキャストの受信のみが許されるという要件)に従って、互いの代わりにされ得るアプリケーションサービスのコンテンツアイテムの同一のおよび代替的なバージョンの識別情報を提供するためにuserServiceDescription要素のr12:appService子要素を利用する可能性がある。ブロードキャストのリプレゼンテーションとユニキャストのリプレゼンテーションとの両方を記述する(たとえば、対応するメディアプレゼンテーション記述のフラグメントによる)統合されたMPDが、UEがユニキャストを通じて受信されているサービスをMBMSユーザサービスに関連付けることを可能にするために、更新されたUSDに含まれる可能性がある。
一部の例において、BM-SCは、USDの配信のために一方向転送を介したファイル配信(FLUTE: file delivery over unidirectional transport)セッションをすでに確立済みである場合、そのブロードキャストチャネルを介してUSD(または更新されたUSD)を送信し得る。そうでない場合、BM-SCは、既存のMBMSセッション確立手順を用いてUSDまたは更新されたUSDを送信するためにFLUTEセッションを確立することができる。FLUTEは、T. Pailaら、「FLUTE - File Delivery over Unidirectional Transport」、IETF、RFC 6726、2012年11月に記載されている。
新たに確立されたMBMSユーザサービスに関するUSD/更新されたUSDを準備すると、ネットワークのデバイス(たとえば、BM-SC)は、ユニキャストからブロードキャストの受信に切り替えるためにUEをリダイレクトするためにUEにリダイレクト/トリガメッセージを送信し得る。第1の例として、ネットワークのデバイスは、ユニキャストまたはMBMSベアラ上でのUSD/更新されたUSDへのUEのアクセスをトリガするために、HTTP応答で提供されるコンテンツと一緒に指示を送信する可能性がある。たとえば、コンテンツの要求に応答して、ネットワークのデバイスは、USD/USD更新のUEの受信をトリガするための指示を含む3GPP拡張ヘッダとともにHTTP 200 OKメッセージを送信する可能性がある。つまり、HTTP 200 OKメッセージは、UEが要求したコンテンツおよびリダイレクトを含み得る。別の例として、コンテンツの要求に応答して、ネットワークのデバイスは、USD/更新されたUSDの受信を開始するようにUEを促す3GPP拡張ヘッダとともにHTTP 3xxリダイレクトメッセージを送信する可能性がある。HTTP 3xxリダイレクトメッセージに含まれるリダイレクトURLは、同じ要求されたリソースに関する異なる位置を表す可能性がある。たとえば、元の要求のURLがhttp://example.com/per-x/rep-y/seg-z.3gpであった場合、リダイレクトURLが、http://example.com/redirect/per-x/rep-y/seg-z.3gpである可能性がある。3GPPで定義されたHTTP拡張ヘッダは、「Trigger-MBMS」と名付けられ、値「Get-USD」を有する可能性がある。結果として、3xxステータスコードを有するUEによるコンテンツ要求へのHTTP応答メッセージは、応答ヘッダ「Trigger-MBMS: Get-USD」を添えられる可能性がある。
UEが通常のリダイレクトメッセージ(たとえば、HTTPリダイレクトステータスコードまたはRTSPリダイレクト要求)とMBMSオフローディング要求とを区別するために、新しいヘッダフィールド(たとえば、MooDヘッダフィールド)が使用される可能性がある。MooDヘッダフィールドは、RTSPリダイレクトとHTTPリダイレクトとの両方に当てはまる可能性がある。UEは、MooDヘッダの存在を検出する場合、リダイレクトがMBMSクライアントをアクティブ化する指示であると判定する可能性がある。MBMSクライアントがすでにアクティブ化されているかまたは動作可能である場合、UEは、リダイレクトが更新されたUSDフラグメントが獲得されるべきであるという暗黙的な通知を表すと判定する可能性がある。MooDヘッダフィールドは、動的に確立されたMBMSサービスへのエントリポイントとして働くMBMS USBDフラグメントの位置を示すURLを含み得る。MooDヘッダの受信の結果として起こるUSDフラグメントのUEの獲得に関する優先順の規則の例示的な組は、優先度の降順で以下に与えられる。
1. URLがMooDヘッダ内にある場合、MBMSクライアントは、URLを用いてユニキャストを介してUSBDフラグメントを取り出し得る。
2. USBDフラグメントへのURLがMooDヘッダ内に存在しないが、USD情報へのURL(たとえば、/<X>/USDLocation/URL)がMO内に存在する場合、MBMSクライアントは、URLを用いてユニキャストを介してUSDフラグメントを取り出し得る。
1. URLがMooDヘッダ内にある場合、MBMSクライアントは、URLを用いてユニキャストを介してUSBDフラグメントを取り出し得る。
2. USBDフラグメントへのURLがMooDヘッダ内に存在しないが、USD情報へのURL(たとえば、/<X>/USDLocation/URL)がMO内に存在する場合、MBMSクライアントは、URLを用いてユニキャストを介してUSDフラグメントを取り出し得る。
MBMSクライアントがUSDフラグメントの獲得を開始するときから始まってそのMBMSクライアントがMBMSベアラ上でオンデマンドMBMSサービスのコンテンツを受信し終えるまでの合間の期間中に、UEは、サービスの中断、またはユニキャストからブロードキャストコンテンツの受信への「ブレイクビフォアメイク(break before make)」切り替えを避けるために、ユニキャストネットワークを介してコンテンツを要求し続ける可能性がある。アプリケーションクライアントにMBMS配信を介して受信されたコンテンツを供給するMBMSミドルウェアクライアントの準備が整うと、ユニキャストからブロードキャストへの受信モードの切り替えが行われ得る。
一部の例においては、MOの情報によって、MooDプロキシサーバにUEの現在の位置を示すように要求される場合、そのようにするためにそのUEによってMooDヘッダフィールドが使用され得る。そのような場合、UEの現在の位置は、以下で図21に示されるように、「LocationType」の値に従ってフォーマットされ得る。MooDヘッダフィールドに関する増補バッカス-ナウア記法(ABNF: Augmented Backus-Naur Form)シンタックスは、次のように定義される。
MooD="3gpp-mbms-offloading" [":" (absoluteURI | relativeURI|currentLocation)]
MooD="3gpp-mbms-offloading" [":" (absoluteURI | relativeURI|currentLocation)]
ユニキャストからブロードキャストの受信に切り替えるためにUEをリダイレクトするためのリダイレクト/トリガメッセージの第2の例として、ネットワークのデバイスは、要求されたコンテンツ(たとえば、セグメント)およびUSD/更新されたUSDをマルチパートMIMEコンテナにカプセル化することによって、UEへのHTTP応答において提供されるコンテンツと一緒にUSD/更新されたUSDを送信し得る。第3の例として、ネットワークのデバイスは、(たとえば、3GPP TS 26.346のSection 7.4:「Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs」に見られる)OMAプッシュメカニズムまたはその他のプッシュメカニズムを用いてユニキャストチャネルを介してUEにUSD/更新されたUSDを送信する可能性がある。UEは、ユニキャスト転送かまたはブロードキャスト転送かのどちらかを介して新しいUSDまたは更新されたUSDを獲得している間、コンテンツをフェッチするためにユニキャストチャネルを使用し続ける可能性がある。UEがMBMSベアラからコンテンツを完全に受信することができると、ユニキャストチャネルは解放され得る。
様々なトリガ方法が、UEのMBMSミドルウェアをアクティブ化するためのネットワークに基づく解決策を実現するために使用される可能性がある。第1の代替においては、UEのアプリケーションが、何らかの情報を得る可能性があり、そして、UEのMBMSミドルウェアに登録する可能性がある。第2の代替においては、UEのHTTPプロキシまたはRTPプロキシが、MBMSミドルウェアに指示を与える何らかのリダイレクトを得る可能性がある。第3の代替においては、SMS、WAPプッシュ、OMA-DMなどの何らかのプッシュメカニズムが、MBMSミドルウェアを直接ウェイクアップする可能性がある。たとえば、プッシュメカニズムは、MBMSのトリガのために使用されるSMSのための新しいAPPポートID(たとえば、新しいUDPポート)を指定する可能性がある。SMSレイヤが新しく指定されたAPPポートIDを伴うトリガを受信するとき、そのAPPポートIDは、MBMSミドルウェアに渡される。別の例においては、OMA-DMサーバが、MBMSミドルウェアを始動するためにUEに管理開始メッセージを送信する。第4の代替においては、ネットワークが、システム情報ブロック(SIB)ブロードキャスト、セルブロードキャスト、MBMS制御情報有効性および変更(MCCH: MBMS control information validity and change)変更通知、USD変更通知、またはその他のシグナリング方法などの無線インターフェースシグナリングを使用する可能性がある。第5の代替においては、ネットワークが、非アクセス層(NAS)シグナリング、プロトコル構成オプション(PCO: protocol configuration option)、またはその他のシグナリング方法などのパケットゲートウェイシグナリングを使用する可能性がある。様々なその他の代替が、本開示の1つまたは複数の技術に従って使用され得る。
図2は、例示的なマルチメディアコンテンツ102の要素を示す概念図である。マルチメディアコンテンツ102は、コンテンツが受信されるときにそのコンテンツが消費されるストリーミングサービス、または後で消費するためにコンテンツがダウンロードされ、記憶されるダウンロード配信サービスに含まれる可能性がある。つまり、マルチメディアコンテンツ102は、リアルタイムまたは非リアルタイムのレンダリングのために1つまたは複数のUEによってアクセスされ得る任意のデータを表す可能性がある。図2の例において、マルチメディアコンテンツ102は、メディアプレゼンテーション記述(MPD)104および複数のリプレゼンテーション110〜120を含む。リプレゼンテーション110が、任意のヘッダデータ112およびセグメント114A〜114N(セグメント114)を含む一方、リプレゼンテーション120は、任意のヘッダデータ122およびセグメント124A〜124N(セグメント124)を含む。文字Nは、便宜上、リプレゼンテーション110、120の各々の最後の動画フラグメントを指定するために使用される。一部の例においては、リプレゼンテーション110、120の間に異なる数の動画フラグメントが存在し得る。
MPD 104は、リプレゼンテーション110〜120とは別のデータ構造を含み得る。MPD 104は、図1のマニフェストファイル66に対応する可能性がある。同様に、リプレゼンテーション110〜120は、図1のリプレゼンテーション68に対応する可能性がある。概して、MPD 104は、概して、符号化およびレンダリングの特徴、適応セット、MPD 104が対応するプロファイル、テキストタイプ情報、カメラアングル情報、レーティング情報、トリックモード(trick mode)情報(たとえば、時間的なサブシーケンスを含むリプレゼンテーションを示す情報)、ならびに/または(たとえば、再生中のメディアコンテンツへの対象を定めた広告挿入のための)遠隔の期間(remote period)を取り出すための情報などのリプレゼンテーション110〜120の特徴を記述するデータを含み得る。
存在するとき、ヘッダデータ112は、セグメント114の特徴、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の時間的な位置、セグメント114のうちのどれがランダムアクセスポイントを含むか、セグメント114内のランダムアクセスポイントに対するバイトオフセット、セグメント114のユニフォームリソースロケータ(URL)、またはセグメント114のその他の点を記述し得る。存在するとき、ヘッダデータ122は、セグメント124の同様の特徴を記述し得る。追加的にまたは代替的に、そのような特徴は、MPD 104内に完全に含まれる可能性がある。
セグメント114、124は、1つまたは複数の符号化されたビデオサンプルを含み、それらのビデオサンプルの各々は、ビデオデータのフレームまたはスライスを含み得る。セグメント114の符号化されたビデオサンプルの各々は、同様の特徴、たとえば、高さ、幅、および帯域幅の要件を有する可能性がある。そのような特徴が、MPD 104のデータによって記述される可能性があるが、そのようなデータは、図2の例に示されていない。MPD 104は、本開示において説明されるシグナリングされる情報のいずれかまたはすべてを加えた、3GPPの仕様によって記載された特徴を含み得る。
セグメント114、124の各々は、一意のユニフォームリソースロケータ(URL)に関連付けられ得る。したがって、セグメント114、124の各々は、DASHなどのストリーミングネットワークプロトコルを用いて独立に取り出され得る可能性がある。このようにして、クライアントデバイス40などの送信先デバイスが、HTTP GET要求を用いてセグメント114または124を取り出し得る。一部の例において、クライアントデバイス40は、HTTP partial GET要求を用いてセグメント114または124の特定のバイト範囲を取り出し得る。
MPDは、ユニキャストコンテンツ、マルチキャストコンテンツ、ブロードキャストコンテンツ、またはこれらの何らかの組合せをどのようにして取り出すべきかを記述し得る。つまり、MPDは、UEが1つまたは複数の配信モードによってコンテンツにアクセスすることを可能にするためにUEの1つまたは複数の構成要素(たとえば、ストリーミングクライアント)に情報を提供し得る。一部の例においては、MPDの一部またはすべてが修正され、それによって、ストリーミングクライアントが受信する可能性がある命令を変更する可能性がある。たとえば、MPDに含まれるメディアデータを取り出すためのURLが、新しい位置からメディアデータを取得するようにストリーミングクライアントに命令するために変更される必要がある可能性がある。一部の例においては、ストリーミングクライアントに新しい位置からメディアデータを取得させるために、URLの基底部分が修正される可能性がある。URLの基底部分は、ストリーミングクライアントを異なるネットワークアドレスまたはローカルアドレスに振り向けるために変更される可能性がある。つまり、一部の例においては、修正されたURLの基底部分が、(クライアントデバイス40のストリーミングクライアントなどの)ストリーミングクライアントにクライアントデバイス40自体の中の1つまたは複数の構成要素からメディアデータを取得させる可能性がある。このようにして、ストリーミングクライアントは、ネットワークのコンテンツサーバからではなく、MBMSミドルウェアユニットなどのUEのその他の構成要素からメディアデータを取り出し得る。
あるサービスから別のサービスにメディアデータの取り出しを移行するための様々な技術が、本明細書において説明される。そのような技術は、異なるサービスのプロビジョニングを開始するまたは止めるサービスプロバイダネットワークに従って使用され得る。1つの使用事例として、サービスプロバイダネットワークが、リアルタイム(RT)コンテンツのための需要に基づくeMBMSを可能にする可能性がある。たとえば、スポーツ/ニュースコンテンツプロバイダが、そのプロバイダのオンラインマルチメディアスポーツプログラムおよびニュースサービスをインターネットを介して利用可能にする可能性がある(別名「オーバーザトップ」またはOTTサービス)。サービスへのLTEユニキャストアクセスが、特定の国においてモバイルネットワーク事業者によって提供される可能性がある。様々な理由で、スポーツ/ニュースコンテンツプロバイダによって提供される特定のスポーツイベントの生放送が、国において非常に人気になる可能性がある。つまり、国の多数のユーザが、生放送をフォローするために(たとえば、スマートフォンによって)スポーツ/ニュースコンテンツプロバイダのサイトにアクセスする可能性がある。eMBMSサービスも提供するモバイルネットワーク事業者は、高まった人気が原因で、スポーツ/ニュースコンテンツプロバイダのサイトへの/からのその事業者のLTEユニキャストネットワーク上のトラフィックの高く長時間続くレベルにさらされる可能性がある。
そのような多いトラフィックの量は、サービスプロバイダのユニキャストネットワークの容量に負担をかける可能性があるのみならず、コンテンツの受信中のより頻繁な停止が原因でユーザエクスペリエンス全体を損なう可能性もある(これは、スポーツ/ニュースコンテンツプロバイダにとっても懸念されることである可能性がある)。本明細書において説明される技術によれば、モバイルネットワーク事業者のネットワークが、任意の外部サイトへのその事業者のユニキャストネットワーク上の動的なOTTトラフィックの増加を検出することができる可能性があり、ユニキャストトラフィックのオフローディングのためにeMBMSサービスを動的にプロビジョニングするための手段を有する可能性がある。一部の例において、モバイルネットワーク事業者は、必要に応じて需要に基づくeMBMSサービスを構成するためのコンテンツプロバイダとのビジネスの合意を有する可能性がある。
第2の使用事例として、サービスプロバイダネットワークは、非リアルタイム(NRT)コンテンツのための需要に基づくeMBMSを可能にする可能性がある。たとえば、上述のスポーツ/ニュースコンテンツプロバイダは、スポーツニュース、インタビュー、ハイライトなどの異なるカテゴリを包含するRSS(「RDFサイトサマリ」または「真に単純なシンジケーション(Really Simple Syndication)」)フィード(別名「ポッドキャスト」)を公開する可能性もある。最近の任意が原因で、ポッドキャストの講読が、急激に増加する可能性がある。サービスプロバイダのユニキャストネットワーク上のそのようなRSSコンテンツ配信がブロードキャストまたはeMBMSベアラ上で配信されることが、より効率的である可能性がある。一部の例において、コンテンツプロバイダは、コンテンツプロバイダによって提供される様々なRSSフィードの講読イベントが測定され、サービスプロバイダと共有されることを可能にし得るサービスプロバイダとの関係を有する可能性がある。一部の例においては、所与のRSSフィードに関する特定の閾値に到達すると、サービスプロバイダが、ブロードキャストスケジュールに従ってRSSコンテンツを配信するためにeMBMSダウンロード配信サービスを動的にプロビジョニングする可能性がある。
第3の使用事例として、サービスプロバイダネットワークは、eMBMSサービスの需要に基づく非アクティブ化を可能にする可能性がある。たとえば、国のスポーツのファンは、スポーツ/ニュースコンテンツプロバイダのコンテンツへの関心を失い始める可能性がある。最近プロビジョニングされたeMBMSサービスを介したスポーツ/ニュースコンテンツプロバイダのサイトへのユーザのアクセスの大きな減少が、検出される。サービスプロバイダは、スポーツ/ニュースコンテンツプロバイダのサービスの専用のeMBMSブロードキャストを維持することがネットワーク利用全体のためにもはや有益でないと判定し得る。コンテンツプロバイダと正式に合意されたビジネスの条項に従って、サービスプロバイダは、eMBMSサービスを非アクティブ化し得る。一部の例においては、関連するネットワークの容量が、ユニキャストトラフィックの搬送のために再割り振りされ得る。
第4の使用事例として、サービスネットワーク事業者は、オンデマンドのeMBMS動作を制御し、それによって、ライブストリーミングサービスのサポートを提供する可能性がある。たとえば、ショッピングモールまたはその他のエリアにおいて、多くのユーザが、DASHプロトコルを用いて第1のライブプログラムを見ている可能性がある。ショッピングモールをカバーするサービスネットワークのセルが、非常に混雑させられる可能性がある。ショッピングモールに到着する新しいユーザは、サービスネットワークを用いてコンテンツにアクセスするのに苦労する可能性がある。この例においては、DASHストリーミングコンテンツにアクセスするUEの多くが、eMBMSに対応している可能性がある。混在状況が、ネットワーク事業者に知られるようになる可能性がある。混雑を緩和するために、ネットワークの1つまたは複数のデバイスは、UEと通信して、UEにMBMSベアラ上でのDASHストリーミングコンテンツの受信を開始させ得る。つまり、ネットワークが、MBMSベアラ上でライブストリーミングコンテンツをブロードキャストする可能性があり、MBMSユーザサービスの講読が、アクティブ化され、命令によりネットワークから受信され、eMBMS対応UEが、eMBMSシステムに切り替わり、それによって、セルの混雑を和らげる可能性がある。
一部の例においては、第1のライブプログラムが継続している間に、何人かのユーザが、プログラムを見ることを止める可能性がある。加えて、第2のライブプログラムが、セル内で人気を高める可能性がある。セルが、再び混雑する可能性がある。そのような場合、ネットワークのデバイスが、第1のライブプログラムの視聴者の数が第2のライブプログラムの視聴者の数未満であると判定する可能性がある。この判定に基づいて、ネットワークのデバイスは、第1のライブプログラムのためのMBMSベアラを終了し、その代わりに、MBMSベアラ上で第2のライブプログラムをブロードキャストする可能性がある。本明細書において説明される技術によれば、第1のライブプログラムを取得するそれらのUEが、MBMSユーザサービスを止め、その後、DASHを介して第1のライブプログラムを取得する可能性がある。一方、第2のライブプログラムの視聴者は、ブロードキャストサービスに加入し、MBMSベアラ上での第2のライブプログラムの受信を開始する可能性がある。
第5の使用事例として、サービスプロバイダは、集約されたコンテンツへの効率的なアクセスを可能にする可能性がある。たとえば、コンテンツプロバイダは、DASHに基づいて多くのライブテレビチャネルを有するサービスを提供する可能性がある。言い換えれば、コンテンツプロバイダは、その他のコンテンツ製作者およびコンテンツ消費者のための集約者として働き得る。TVチャネルは、パーソナライズされたレポータ、ローカルニュース、および/またはその他の少量作成のフィードの多数のサービスを含む可能性がある。この使用事例においては、サービスのチャネルが、ソーシャルネットワークを通じて共有される可能性があり、時折、そのようなチャネルは人気になり、結局は再び落ち込むだけである可能性がある。様々な要因で、人気の推移は、比較的に漸進的に起こる可能性があり、地域によって異なる可能性がある。サービスプロバイダは、この高需要の場合に、すべてのMBMS対応デバイスが、高品質の、ユーザエクスペリエンスを邪魔しない制限するサービス(たとえば、切れ目のないサービス、タイムシフトバッファリングの可用性、チャネルのさらなるビューおよび構成要素、ならびにその他の特徴)を消費することができることを保証したい可能性がある。つまり、サービスプロバイダは、無線の効率が良い方法でそのような人気のあるコンテンツを配信したい。
図3は、選択的に1つまたは複数のサービスを用いて(たとえば、ストリーミングサービスまたはファイルダウンロードサービスに関する)データを取得するための技術を実装する例示的なシステム150を示す概念図である。図3の例に示されるように、システム150は、UE側およびネットワーク側を含む。図3のUE側にある構成要素は、一部の例において、図1に示されたクライアントデバイス40の構成要素を表す可能性がある。ネットワーク側にある構成要素は、一部の例において、(必ずしも図1に示されていない)コンテンツ準備デバイス20、サーバデバイス60、および/またはネットワーク74の構成要素を表す可能性がある。その他の例においては、UE側の構成要素が、クライアントデバイスに含まれない可能性があり、その代わりに、ネットワーク74の一部である可能性がある。
図3の例において、システム150のネットワーク側は、アプリケーションサーバ(「appサーバ」)152、パケットデータネットワークゲートウェイ(P-GW)154、ならびにブロードキャストおよびマルチキャストサービスセンター(BM-SC)156を含む。アプリケーションサーバ152、P-GW 154、およびBM-SC 156の各々は、ハードウェア、ファームウェア、ソフトウェア、またはこれらの任意の組合せを含む可能性がある。アプリケーションサーバ152は、一部の例においては、サーバデバイス60の1つまたは複数の構成要素と同じまたは同様の機能を有する可能性がある。つまり、アプリケーションサーバ152は、データの要求を受信し、要求されたデータを提供するように動作可能である可能性がある。P-GW 154は、UEに関するトラフィックの出口および入口の点であることによって外部パケットデータネットワークへのUEのための接続性を提供し得る。一部の例においては、2つ以上のパケットデータネットワークへの同時接続性をUEに提供するために複数のP-GWが使用され得る。様々な例において、P-GWは、ポリシーの施行、パケットのフィルタリング、課金のサポート、パケットのスクリーニング、または様々なその他の活動を実行し得る。たとえば、図3の例において、P-GWは、UEの構成要素にコンテンツを得るためのアプリケーションサーバ152へのアクセスを提供し得る。BM-SC 156は、一部の例において、処理ユニット70の機能と同じまたは同様の機能を有する可能性がある。つまり、BM-SC 156は、MBMSまたはeMBMSなどのブロードキャストまたはマルチキャストプロトコルによってUEにデータを配信するように構成され得る。BM-SC 156は、アプリケーションサーバ152からデータを受信し、1つまたは複数のUEによる使用のためにデータをブロードキャストし得る。
システム150のUE側は、図3に示されるように、アプリケーション158、ストリーミング/ファイルダウンロードクライアント160、MBMSユニット(「MBMSクライアント(ミドルウェア)/ローカルサーバ」)162、IPスタック164、およびモデム166を含む。アプリケーション158は、データを受信することができる任意のアプリケーションを表す可能性がある。一部の例において、アプリケーション158は、ストリーミングメディアデータを受信し、ユーザに対して提示するためにオーディオ、ビデオ、またはテキストを出力することができる可能性がある。たとえば、アプリケーション158は、メディアプレイヤー、ウェブブラウザ、またはその他のアプリケーションである可能性がある。一部の例において、アプリケーション158は、コンテンツがストリーミングサービスによって配信されるか、またはストリーミングクライアントによってアクセスされるときにメディアコンテンツをリアルタイムで消費する可能性がある。一部の例において、アプリケーション158は、ファイル配信サービスによって配信されるか、またはファイルダウンロードクライアントによってアクセスされるコンテンツの時間をずらされた消費に携わる可能性がある。ストリーミング/ファイルダウンロードクライアント160は、本明細書において説明される機能のいずれかまたはすべてを実行するように動作可能なハードウェア、ファームウェア、ソフトウェア、またはこれらの何らかの組合せである可能性がある。一部の例において、ストリーミング/ファイルダウンロードクライアント160は、取り出しユニット52によって実行される動作と同様の動作を実行する可能性がある。たとえば、ストリーミング/ファイルダウンロードクライアント160は、アプリケーション158からストリーミングメディアデータの要求を受信し、ユーザに対して提示するためにビデオデータ、オーディオデータ、および/またはテキストデータをアプリケーション158に提供するように動作可能である可能性がある。ストリーミング/ファイルダウンロードクライアント160は、たとえば、DASHクライアント、RTP/RTSPクライアント、FTPクライアント、HTTPクライアント、またはコンピュータネットワークを介してストリーミングサービスデータもしくはファイル配信サービスデータを受信するように構成されたその他のクライアントを含み得る。
MBMSユニット162は、(ブロードキャストおよびマルチキャスト配信モードを含む)ブロードキャストまたはマルチキャストサービスを介してデータを受信し、1つまたは複数のその他の構成要素によるアクセスのためにデータを記憶するように動作可能である任意のユニットを表す可能性がある。たとえば、MBMSユニット162は、MBMS、eMBMS、またはIPマルチキャストなどの様々なブロードキャストまたはマルチキャストネットワークプロトコルに従って動作し得る。ブロードキャストまたはマルチキャストサービスが特定のコンテンツに関して利用可能であるとき、MBMSユニット162は、特定のコンテンツに関連するマルチキャストネットワークグループに加わる要求を送り、その後、いかなるさらなる要求も発する必要なくマルチキャストグループのデータを受信し得る。図3の例において、MBMSユニット162は、アプリケーション158から指示を受信することによって有効化される可能性がある。指示は、アプリケーション158がブロードキャストサービスまたはマルチキャストが利用可能であるデータを要求していることを示し得る。一部の例において、MBMSユニット162は、特定のコンテンツの少なくとも一部を受信したとき、ストリーミング/ファイルダウンロードクライアント160と通信して、ストリーミング/ファイルダウンロードクライアント160にMBMSミドルウェアからストリーミングサービスデータまたはファイル配信サービスデータを取得させ得る。つまり、MBMSユニット162は、受信されるデータに関してMBMSクライアントとローカルサーバとの両方として働き得る。
図3の例において、MBMSユニット162は、APIを介するなどしてストリーミング/ファイルダウンロードクライアント160と通信するための機能を含み得る。MBMSユニット162およびストリーミング/ファイルダウンロードクライアント160は、MPD/SDPのURL(もしくはアクセスされている提示のためのMPDをeMBMSレイヤに通知するためのメカニズム)、MBMSトリガ情報(もしくはeMBMSレイヤがユーザサービス記述(USD)の更新を調べることを引き起こす/トリガするためのメカニズム)、および/またはリダイレクト構成などの様々な情報を1つまたは複数のAPIを介してやりとりするように動作可能である可能性がある。たとえば、MBMSクライアントとストリーミング/ファイルダウンロードクライアントとの間のAPIが、データに関するマニフェストファイルを送信するか、またはストリーミング/ファイルダウンロードクライアント160にそのストリーミング/ファイルダウンロードクライアント160の設定を構成させる(たとえば、アプリケーションサーバ152上のコンテンツへのアクセスからMBMSユニット162上のコンテンツへのアクセスに変更させる)ための情報をやりとりするために使用される可能性がある。
図3の例において、ストリーミング/ファイルダウンロードクライアント160およびMBMSユニット162は、IPスタック164およびモデム166を介してシステム150のネットワーク側と通信し得る。様々な例において、IPスタック164は、インターネットプロトコルスイートまたはその他のプロトコルスイートなどの、ネットワーク通信に使用可能な任意のレイヤ化されたプロトコルスイートを表す。モデム166は、ケーブル、光ファイバを介するなど物理媒体で、または電磁波を用いることによってデータを送信することができる任意のユニットを表す。
図3の例のステップ1においては、アプリケーション158が、(たとえば、ユニキャスト配信モードを用いて)ユニキャストサービスを通じてアプリケーションサーバ152からデータを得る。つまり、UEは、はじめ、第1のサービスを用いてデータを受信し得る。図3の例のステップ2においては、ネットワーク内の高アタッチレート検出(HARD)ユニット(図示せず)が、高アタッチレートを検出する。たとえば、HARDは、閾値の数のUEが特定のコンテンツに関してサーバ152にアクセスしていると判定する可能性がある。HARDユニットは、高アタッチレートをBM-SC 156に示し、BM-SC 156が、MBMSセッション(たとえば、MBMSベアラ)を有効化する。BM-SC 156は、アプリケーションサーバ152にMBMSセッションを示す可能性があり、アプリケーションサーバ152は、システム150のUE側のアプリケーション158にMBMSセッションの可用性を示す可能性がある。このようにして、システム150のネットワーク側は、第2のサービス(たとえば、MBMSベアラまたはその他のマルチキャストもしくはブロードキャストサービス)の可用性をUEのアプリケーション158に示し得る。第2のサービスは、ブロードキャストまたはマルチキャスト配信モードを用いてでも、ユニキャスト配信モードを用いてでも利用可能である可能性がある。
図3の例のステップ3において、アプリケーション158は、MBMSサービスが利用可能であるという通知を受信するとき、MBMSミドルウェア(たとえば、MBMSユニット162)に登録する。MBMSユニット162は、(たとえば、APIを介して)ストリーミング/ファイルダウンロードクライアント160と通信して、ストリーミング/ファイルダウンロードクライアント160にMBMSミドルウェアからストリーミングサービスデータまたはファイル配信サービスデータを取得させ得る。つまり、本開示の1つまたは複数の技術によれば、第1のサービス(たとえば、ユニキャストサービス)を介したデータの受信中に、アプリケーション158は、何らかの情報(たとえば、指示)を得て、それからMBMSミドルウェアに登録する。
図3の例のステップ4において、アプリケーション158は、ブロードキャストまたはマルチキャストサービスを用いてMBMSベアラ(たとえば、BM-SC 156)からデータを得る。言い換えれば、UEは、データが第2のサービスを介して受信されるべきであるという指示を受信するとき、第2のサービスを介してデータを受信するためのユニット(たとえば、MBMSユニット162)をアクティブ化し、第2のサービスを介してデータを受信するためのユニットからデータを受信する可能性がある。MBMSユニット162は、ブロードキャスト配信モードまたはマルチキャスト配信モードによってデータを取得し得る。図3のこの手法は、ファームウェアオーバージエア(FOTA: firmware over the air)テクノロジー、ポッドキャストなどのファイルダウンロードにより好適である可能性がある。図3の例において、アプリケーション158は、転送に関知しない。つまり、アプリケーション158は、指示を受信し、ブロードキャストまたはマルチキャストサービスを介したデータの受信を可能にするためにMBMSミドルウェアに登録しなければならない。
図4は、選択的に1つまたは複数のサービスを用いてデータを取得するための技術を実装する例示的なシステム200を示す概念図である。図4の例に示されるように、システム200は、UE側およびネットワーク側を含む。システム200のネットワーク側は、アプリケーションサーバ(「appサーバ」)202、P-GW 204、リダイレクト/プロキシユニット205、およびBM-SC 206を含む。アプリケーションサーバ(「appサーバ」)202、P-GW 204、およびBM-SC 206は、それぞれ、図3のアプリケーションサーバ152、P-GW 154、およびBM-SC 156の機能と同じまたは同様である機能を含み得る。リダイレクト/プロキシユニット205は、HTTP GET要求またはRTPメッセージなどの要求を受信し、命令に基づいて1つまたは複数のソースに要求を導くためのハードウェア、ファームウェア、ソフトウェア、またはこれらの何らかの組合せを表す可能性がある。たとえば、リダイレクト/プロキシユニット205は、UEからデータの要求を受信し、要求をアプリケーションサーバ202に転送するように動作可能である可能性がある。
図4の例において、システム200のUE側は、アプリケーション208、ストリーミング/ファイルダウンロードクライアント210、MBMSユニット(「MBMSクライアント(ミドルウェア)/ローカルサーバ」)212、プロキシユニット(「HTTP/RTPプロキシ」)213、IPスタック214、およびモデム216を含む。アプリケーション208、IPスタック214、およびモデム216は、それぞれ、図3のアプリケーション158、IPスタック164、およびモデム166の機能と同じまたは同様である機能を含み得る。一部の例において、ストリーミング/ファイルダウンロードクライアント210は、図3のストリーミング/ファイルダウンロードクライアント160の機能と同じまたは同様である機能を含み得る。その他の例において、ストリーミング/ファイルダウンロードクライアント210は、異なるまたはさらなる機能を含み得る。一部の例において、ストリーミング/ファイルダウンロードクライアント210は、様々なフォーマットを用いて符号化されたデータを処理することができる構成要素(たとえば、DASHクライアントおよびRTPクライアント)の集合である可能性がある。MBMSユニット212は、図3のMBMSユニット162の機能と同じまたは同様である機能を含み得る。図4の例において、MBMSユニット212は、異なるまたはさらなる機能を含み得る。
図4の例において、MBMSユニット212は、APIを介するなどしてプロキシユニット213と通信するための機能も含み得る。MBMSユニット212およびプロキシユニット213は、MPD/SDPのURL(もしくはアクセスされている提示のためのMPDをeMBMSレイヤに通知するためのメカニズム)、MBMSトリガ情報(もしくはeMBMSレイヤがユーザサービス記述(USD)の更新を調べることを引き起こす/トリガするためのメカニズム)、および/またはリダイレクト構成などの様々な情報を1つまたは複数のAPIを介してやりとりするように動作可能である可能性がある。たとえば、MBMSクライアントとローカルプロキシとの間のAPIが、MBMSユニット212がデータの受信を開始し、ストリーミングサービスデータもしくはファイル配信サービスデータに関するマニフェストファイルを送信し、および/またはプロキシユニット213にそのプロキシユニット213のリダイレクト設定を構成させる(たとえば、アプリケーションサーバ202上のコンテンツへのアクセスからMBMSユニット212上のコンテンツへのアクセスに変更させる)ことを可能にするための情報をやりとりするために使用される可能性がある。
プロキシユニット213は、要求(たとえば、データの要求)を受信し、適切な送信先に要求を転送するための機能を含み得る。プロキシユニット213は、リダイレクト命令に準拠するように受信された要求(たとえば、要求に含まれるURL)を修正するための機能も含み得る。たとえば、プロキシユニット213は、ストリーミング/ファイルダウンロードクライアント210がアプリケーションサーバ202から(たとえば、ユニキャストサービスから)ではなくMBMSユニット212(たとえば、ブロードキャストまたはマルチキャストサービスから)データを受信するようにネットワークアドレスを修正するように動作可能である可能性がある。その後、MBMSユニット212は、利用可能である場合、ブロードキャスト配信モードでブロードキャストサービスからデータを受信し得る。
図4の例のステップ1においては、アプリケーション208が、ユニキャストサービスを通じてアプリケーションサーバ202からデータを得る。つまり、UEは、はじめ、第1のサービスを用いてデータを受信し得る。リダイレクト/プロキシユニット205は、ユニキャストユーザトラフィックの経路上にある可能性がある。つまり、アプリケーションサーバ202とUE側との間のユニキャストトラフィックは、リダイレクト/プロキシユニット205を通って流れる可能性がある。図4の例のステップ2においては、ネットワーク内のHARDユニット(図示せず)が、高アタッチレートを検出する。様々な例において、HARDユニットは、アプリケーションサーバ202、リダイレクト/プロキシユニット205、P-GW 204、またはその他のネットワークエンティティの一部である可能性がある。HARDユニットは、高アタッチレートをBM-SC 206に示してMBMSセッション(たとえば、MBMSベアラ)を有効化する。BM-SC 206は、ローカルサーバに行くようにUEをリダイレクトするようにリダイレクト/プロキシユニット205に要求する(ユーザプレーンまたは制御プレーン内にある可能性がある)。リダイレクト/プロキシユニット205は、たとえば、HTTPリダイレクトもしくは成功メッセージまたはRTSPリダイレクトもしくは成功メッセージを用いてUEに指示を送信し得る。一例として、HTTPまたはRTSPリダイレクトメッセージは、3xxリダイレクト(たとえば、300または303タイプのHTTP応答)に対応する可能性がある。リダイレクトは、ヘッダの拡張を伴ってまたはヘッダの拡張なしに送信される可能性がある。HTTPまたはRTSP成功メッセージは、ヘッダの拡張を含む2xx成功(たとえば、200タイプのHTTP応答)に対応する可能性がある。このようにして、システム200のネットワーク側は、第2のサービス(たとえば、MBMSベアラまたはその他のマルチキャストもしくはブロードキャストサービス)の可用性をUEのプロキシユニット213に示し得る。
図4の例のステップ3においては、プロキシユニット213が指示(たとえば、リダイレクトまたは成功メッセージ)を受信するとき、プロキシユニット213(たとえば、HTTP/RTPプロキシ)は、MBMSミドルウェア(たとえば、MBMSユニット212)に登録する。つまり、本開示の1つまたは複数の技術によれば、HTTPプロキシ(またはRTPプロキシ)は、何らかの指示を得て、それから、MBMSミドルウェアをアクティブ化する。
図4の例のステップ4において、アプリケーション208は、ブロードキャストまたはマルチキャストサービスを用いて(たとえば、ブロードキャストまたはマルチキャスト配信モードによって)MBMSユニット212が取得したデータをMBMSユニット212から間接的に取得することによってMBMSベアラ(たとえば、BM-SC 206)からデータを得る。言い換えれば、UEは、データが第2のサービスを介して受信されるべきであるという指示を受信するとき、第2のサービスを介してデータを受信するためのユニット(たとえば、MBMSユニット212)をアクティブ化し、第2のサービスを介してデータを受信するためのユニットからデータを受信する可能性がある。そして、第2のサービスを介して受信されたデータは、(たとえば、プロキシユニット213およびストリーミング/ファイルダウンロードクライアント210を介して)間接的にアプリケーション208に提供され得る。一部の例においては、ストリーミング/ファイルダウンロードクライアント210とローカルプロキシ(たとえば、プロキシユニット213)との間のHTTPインターフェースが、MBMSを介して配信されるコンテンツのアプリケーションの要求がローカルHTTPサーバから取り出されることを可能にするように動作可能である。図4の手法は、ニュース速報などのストリーミングサービスにより好適である可能性がある。図4の例において、アプリケーション208は、転送に関知しない。つまり、アプリケーション208は、データがどのようにして取得されるのかのいかなる指示も持つ必要がない。むしろ、プロキシユニット213が、自動的に、ルーティング情報を更新し、アプリケーションサーバ202の代わりにMBMSユニット212にデータの要求を送信する可能性がある。
図5A〜図5Dは、選択的に1つまたは複数のサービスを用いてストリーミングメディアデータを取得するための例示的な動作を示す概念図である。図5A〜図5Dの例示的な動作が、以下で、図4のシステム200の通常の文脈の中で説明される。図5A〜図5Dの例において、ストリーミング/ファイルダウンロードクライアント210は、DASHクライアントである可能性があり、リダイレクト/プロキシユニット205は、プロキシ/リダイレクタである可能性があり、MBMSユニット212は、MBMSクライアントおよびローカルHTTPサーバである可能性があり、プロキシユニット213は、HTTPプロキシである可能性があり、アプリケーションサーバ202は、DASHメディアコンテンツを提供することができるHTTPサーバである可能性がある。
本開示の1つまたは複数の技術によれば、アプリケーション208は、ストリーミング/ファイルダウンロードクライアント210を用いて(たとえば、DASHプロトコルを用いて)メディアデータを取得し得る。たとえば、アプリケーション208は、ストリーミング/ファイルダウンロードクライアント210にマニフェストファイル(たとえば、MPD)の位置を示すURLを送信する可能性があり、そしてさらに、マニフェストファイルが、第1のサービス(たとえば、ユニキャスト)によってメディアデータを取り出すための1つまたは複数のリソースの位置を定義する。ストリーミング/ファイルダウンロードクライアント210は、プロキシユニット213にHTTP GET要求を送信することによってMPDを取得し得る。プロキシユニット213は、HTTP GET要求を受信し、IPスタック214、モデム216、P-GW 204、およびリダイレクト/プロキシユニット205を介してアプリケーションサーバ202に要求を導き得る。図5Aの例において、プロキシユニット213は、さらに、(たとえば、APIを呼び出すことによって)MPDのURLの指示をMBMSユニット212に送信し得る。
一部の例において、UEは、そのUEが最初のMPDのフェッチを行うときにそのUEがeMBMSに対応していることを示し得る。このようにして、UEは、いくつのeMBMS対応デバイスがエリア内にあるかをネットワークが知ることを可能にし得る。また、eMBMSの能力を示すことは、ネットワークがUEのアドレスからの将来のトランザクションを追跡することを可能にする。一部の例において、UEは、そのUEが最初のMPDのフェッチを行うときにそのUEの位置を示す可能性もある。
アプリケーションサーバ202は、HTTP GET要求を受信し、それに応答して200タイプのHTTP OKメッセージを送信する可能性があり、プロキシユニット213が、そのHTTP OKメッセージを受信し、ストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。OKメッセージは、ユニキャストのMPDを含む可能性がある。ストリーミング/ファイルダウンロードクライアント210は、MPDを受信し、取得するメディアデータのリプレゼンテーション、期間、およびセグメント(たとえば、期間3、リプレゼンテーション256、セグメント1)を決定し得る。MPDに少なくとも部分的に基づいて、ストリーミング/ファイルダウンロードクライアント210は、決定されたセグメントに関するURLを探し、決定されたURL(たとえば、「http://example.com/per-3/rep-256/seg-1.3gp」)を用いてHTTP GET要求を送信する可能性があり、プロキシユニット213が、そのHTTP GET要求を受信し、リダイレクト/プロキシユニット205を介してアプリケーションサーバ202に送信する可能性がある。アプリケーションサーバ202は、GET要求を受信する可能性があり、それに応答して、要求されたメディアデータ(たとえば、「seg1」)を含む200タイプのHTTP OKメッセージを送信する可能性があり、プロキシユニット213が、リダイレクト/プロキシユニット205を介してそのHTTP OKメッセージを受信する可能性があり、ストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。このようにして、ストリーミング/ファイルダウンロードクライアント210は、ユニキャストサービスを用いてアプリケーションサーバ202からストリーミングメディアデータを取得し得る。
ネットワーク側で、BM-SC 206は、MBMS(たとえば、ブロードキャスト)サービスを有効化し、MBMSベアラを開始し得る。BM-SC 206は、共通のMPDおよび/またはその他のパラメータを含むユーザサービス記述(USD)をブロードキャストし得る。たとえば、共通のMPDは、サービスのためのブロードキャスト配信モードに対応するURLの基底部分と、サービスのためのユニキャスト配信モードに対応するURLの基底部分とを含み得る。また、BM-SC 206は、メディアデータが特定のメディアコンテンツに関してMBMSサービスを介して受信されるべきであるという指示をリダイレクト/プロキシユニット205に送信し得る。
ストリーミング/ファイルダウンロードクライアント210は、元のMPDからの対応するURL(たとえば、「http://example.com/per-3/rep-256/seg-M.3gp」)を含む、セグメントMの要求などのメディアデータのHTTP GET要求を送信し続ける可能性がある。リダイレクト/プロキシユニット205は、セグメントMのGET要求を受信するとき、図5Aの例においては、3xxタイプのHTTPリダイレクトメッセージをUEに送信する可能性がある。リダイレクトメッセージは、MBMSユニット212に登録するための、ローカルプロキシユニット213に示すリダイレクトURL(たとえば、「http://example.com/redirect/per-3/rep-256/seg-M.3gp」)を含む拡張ヘッダを含み得る。つまり、リダイレクトURLは、同じ要求されたリソースに関する異なる位置を表す可能性がある。たとえば、元の要求のURLがhttp://example.com/per-x/rep-y/seg-z.3gpである場合、リダイレクトURLが、http://example.com/redirect/per-x/rep-y/seg-z.3gpである可能性がある。3GPPで定義されたHTTP拡張ヘッダは、「Trigger-MBMS」と名付けられ、値「Get-USD」を有する可能性があり、その場合、UEによるコンテンツ要求に対するHTTP応答メッセージは、応答ヘッダ「Trigger-MBMS: Get USD」を添えられる可能性がある。
一部の例において、リダイレクト/プロキシユニット205は、代替的に、リダイレクトURLと、プロキシユニット213がMBMSユニット212に登録することを引き起こすためのローカルプロキシユニット213への指示とを含むエンティティボディ(entity body)を有する3xxタイプのHTTPリダイレクトメッセージを使用する可能性がある。つまり、リダイレクトメッセージが、エンティティヘッダ(entity header)および/またはエンティティボディからなる(たとえば、HTTPによって定義されたような)エンティティを含み得る。一部の例において、リダイレクト/プロキシユニット205は、代替的に、HTTP応答において提供されるコンテンツと一緒に指示を送信する可能性がある。指示は、ユニキャストまたはMBMSベアラを介したUSDまたはUSDの更新へのUEのアクセスをトリガし得る。たとえば、リダイレクト/プロキシユニット205は、UEがUSDまたはUSDの更新を取得/受信することをトリガし得る指示を含む3GPP拡張ヘッダを伴う200タイプのHTTP OKメッセージを送信する可能性がある。つまり、200タイプのHTTP OKメッセージが、UEが要求したコンテンツ(たとえば、セグメントM)および指示を含み得る。
UEのプロキシユニット213は、リダイレクトメッセージを受信し、リダイレクトURLへの同じセグメントMの新しいHTTP GET要求をリダイレクト/プロキシユニット205を介してアプリケーションサーバ202に送信することによってユニキャストサービスを介してコンテンツデータを取り出し続ける可能性がある。リダイレクトURLに送信される要求は、指示のプロキシユニット213の受信の、リダイレクト/プロキシユニット205へのプロキシユニット213の肯定応答を表す可能性がある。一部の例において、リダイレクト/プロキシユニット205は、新しいHTTP GET要求を受信し、修正されていない要求をアプリケーションサーバ202に転送する可能性がある。アプリケーションサーバ202は、リダイレクトURLに向けられた新しい要求を受信し、それに応答して、セグメントMを送信する可能性があり、プロキシユニット213が、そのセグメントMをリダイレクト/プロキシユニット205を介して受信し、ストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。一部の例において、リダイレクト/プロキシユニット205は、リダイレクトURLに向けられた新しいHTTP GET要求を受信し、修正された新しい要求をアプリケーションサーバ202に転送する前に新しい要求を修正する可能性がある。たとえば、リダイレクト/プロキシユニット205は、修正された新しい要求がリダイレクトURLに向けられず、代わりに元のURL(たとえば、「http://example.com/per-3/rep-256/seg-M.3gp」)に向けられるように新しい要求を修正する可能性がある。アプリケーションサーバ202は、修正された要求を受信し、それに応答して、セグメントMを送信する可能性があり、プロキシユニット213が、そのセグメントMをリダイレクト/プロキシユニット205を介して受信し、ストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。
新しいGET要求を送信することに加えて、プロキシユニット213は、(たとえば、MBMSユニット212の)APIを利用してMBMSユニット212を有効化する可能性がある。つまり、リダイレクト要求を受信することに応じて、プロキシユニット213は、MBMSユニット212を有効化するが、データがブロードキャストサービスを使用して利用可能になるまでユニキャストサービスを介してデータセグメントをフェッチするために(リダイレクト/プロキシユニット205を介して)appサーバ202に新しいHTTP GET要求を転送し続ける可能性がある。プロキシユニット213は、受信されたリダイレクトURLにユニキャストコンテンツの後続の要求をリダイレクトする可能性がありまたはリダイレクトしない可能性がある。つまり、リダイレクト要求を受信し、リダイレクトURLを介してコンテンツのGET要求を送信した後、プロキシユニット213は、様々な例において、修正なしに要求が通過することを可能にする可能性があり、またはリダイレクトの位置に基づいて要求を導くために要求を修正する可能性がある。
MBMSユニット212は、ローカルプロキシユニット213からトリガを受信すると、確立されたブロードキャストサービスを用いてBM-SC 206からUSDを受信する可能性があり、またはBM-SC 206と通信してユニキャストサービスを通じてUSDを獲得する可能性がある。USDは、MPDのURLおよびMPDのメタデータのフラグメントを含み、後者は、DASHフォーマットのコンテンツを運ぶ各MBMSサービスに関する適応セットまたはリプレゼンテーションを記述する。MBMSユニット212は、(たとえば、図5Aのステップ3において受信された)ストリーミング/ファイルダウンロードクライアント210から最初に受信されたMPDに関するURLをBM-SC 206から受信されたMPDに関するURLと比較する可能性がある。URLが一致する場合、MBMSユニット212は、(たとえば、ブロードキャストまたはマルチキャスト配信モードを用いて)ブロードキャストサービスを介してメディアデータを受信し始める可能性がある。
たとえば、MBMSユニット212は、ブロードキャストサービスの一部としてブロードキャスト配信モードによって送信されているメディアデータを受信するために、MBMS一方向転送を介したファイル配信(FLUTE: file delivery over MBMS unidirectional transport)を有効化する可能性がある。MBMSユニット212は、十分なメディアデータ(たとえば、バッファ)を受信すると、プロキシユニット213のためにリダイレクトを構成するためのAPIを呼び出す可能性がある。一部の例において、MBMSユニット212は、1つまたは複数の更新されたリソースの位置をプロキシユニット213に送信する可能性がある。たとえば、MBMSユニット212は、アプリケーションサーバ202から取り出された元のMPDの代わりに、MBMSユニット212から入手可能な修正されたMPDを使用するようにプロキシユニット213に命令する可能性がある。このようにして、ストリーミング/ファイルダウンロードクライアント210は、それから、(たとえば、ブロードキャスト配信モードを用いて)ブロードキャストサービスを介して取得された、MBMSユニット212からのメディアデータを受信し始める可能性がある。
図5B、図5C、および図5Dは、4つの例示的なケースの例示的な動作を提供する。ケース1においては、(たとえば、図5Aのステップ15において受信される)BM-SC 206からMBMSユニット212によって取得される共通のMPDが、ユニキャストのMPDと同じメディアコンテンツのリプレゼンテーション(たとえば、リプレゼンテーション256)を含み、同じリプレゼンテーションが、MBMSを介して利用可能である。ケース1において、MBMSユニット212は、要求において示されたURLの基底部分(たとえば、アプリケーションサーバ202に対応する基底部分)をMBMSユニット212(たとえば、コンテンツを含むローカルサーバ)に対応する基底部分に変更することによってメディアコンテンツの将来の要求を修正するようにプロキシユニット213に命令する可能性がある。
たとえば、MBMSユニット212は、セグメントNに関するURLを「http://example.com/per-3/rep-256/seg-N」から「http://localhost/per-3/rep-256/seg-N」に変更するためのAPIを呼び出す可能性がある。つまり、一部の例においては、第1の基底部分が、第1のサービス(たとえば、ユニキャスト)に対応するネットワークの位置である可能性があり、一方、第2の基底部分は、第2のサービス(たとえば、ブロードキャスト)に対応するMBMSユニット212の位置である可能性がある。プロキシユニット213は、ストリーミング/ファイルダウンロードクライアント210からHTTP GET要求を受信し続ける可能性がある。プロキシユニット213は、ローカルホストサーバである更新されたリソースの位置(たとえば、MBMSユニット212)に要求をリダイレクトする可能性がある。
MBMSユニット212は、要求を受信し、要求されたメディアデータを含む200タイプのHTTP OKメッセージを送信する可能性があり、プロキシユニット213が、そのHTTP OKメッセージを受信し、ストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。このようにして、プロキシユニット213は、メディアデータがブロードキャストサービスを介して受信されるべきであるという指示(たとえば、リダイレクトメッセージ)を受信するとき、第2のサービスを介してデータを受信するためのユニット(たとえば、MBMSユニット212)をアクティブ化し、アプリケーションサーバ202などの遠隔のアプリケーションサーバの代わりにMBMSユニット212(たとえば、ローカルサーバ)からメディアデータを受信し得る。
ケース2においては、BM-SC 206からMBMSユニット212によって取得される共通のMPDが、ユニキャストのMPDのリプレゼンテーション(たとえば、リプレゼンテーション256およびリプレゼンテーション512)と同じメディアコンテンツのリプレゼンテーションを含む。しかし、唯1つのリプレゼンテーションが、MBMSを介して利用可能である(たとえば、リプレゼンテーション512)。ケース2において、MBMSユニット212は、両方のリプレゼンテーションに関してURLの基底部分を変更することによって要求を修正するようにプロキシユニット213に命令する可能性がある。したがって、プロキシユニット213は、アプリケーションサーバ202に向けられた任意の要求のURLを、代わりにMBMSユニット212のローカルHTTPサーバに送信されるように修正する可能性がある。また、MBMSユニット212は、ブロードキャストを介して利用可能でないリプレゼンテーション(たとえば、リプレゼンテーション256)の要求のURLをブロードキャストを介して利用可能なリプレゼンテーション(たとえば、リプレゼンテーション512)に修正するようにプロキシユニット213に命令する可能性がある。その後、プロキシユニット213は、MBMSを介して利用可能でないリプレゼンテーションを要求するストリーミング/ファイルダウンロードクライアント210からのHTTP GET要求を受信する可能性がある。
GET要求を受信することに応じて、プロキシユニット213は、MBMSユニット212から入手可能なリプレゼンテーションに関するリダイレクトURLを用いてストリーミング/ファイルダウンロードクライアント210にHTTPリダイレクトメッセージを送信する可能性がある。一部の例において、リダイレクトメッセージのURLは、「Location」ヘッダに含まれる可能性がある。その他の例において、リダイレクトメッセージは、リダイレクトURL(たとえば、「http://example.com/per-3/rep-512/seg-N.3gp」)を含む拡張ヘッダを含む可能性がある。さらにその他の例において、ローカルプロキシユニット213は、代替的に、リダイレクトURLを含むボディエンティティを有する3xxタイプのHTTPリダイレクトメッセージを使用する可能性がある。いずれの場合も、ストリーミング/ファイルダウンロードクライアント210は、リダイレクトメッセージを受信し、リダイレクトURLを伴う新しいGET要求を送信する可能性がある。プロキシユニット213は、新しいGET要求をMBMSユニット212に導く可能性があり、MBMSユニット212は、要求されたメディアデータを提供する可能性があり、プロキシユニット213が、そのメディアデータを受信し、ストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。
ケース3においては、BM-SC 206からMBMSユニット212によって取得される共通のMPDが、ユニキャストのMPDに含まれないリプレゼンテーション(たとえば、リプレゼンテーション512)を含まず、除外されるリプレゼンテーションは、MBMSを介して利用可能な唯一のリプレゼンテーションである。ケース3において、MBMSユニット212は、MBMSを介して利用可能なリプレゼンテーション(たとえば、リプレゼンテーション512)に関するそれらの要求のみの基底部分を変更することによって(たとえば、元々アプリケーションサーバ202を指している)要求のURLを修正するようにプロキシユニット213に命令する可能性がある。一部の例において、MBMSユニット212は、MBMSを介して利用可能でないリプレゼンテーション(たとえば、リプレゼンテーション256)に関する要求に関するURLをMBMSを介して利用可能なリプレゼンテーション(たとえば、リプレゼンテーション512)に修正するようにプロキシユニット213に命令する可能性もある。その後、プロキシユニット213は、(たとえば、MBMSユーザサービスでなく)ユニキャストサービスを介して利用可能なリプレゼンテーションからのセグメントを要求するストリーミング/ファイルダウンロードクライアント210からのHTTP GET要求を受信する可能性がある。一例においては、GET要求を受信することに応じて、プロキシユニット213が、ユニキャストのMPDに含まれていないユニキャストを介して利用可能なリプレゼンテーションに関するリダイレクトURLを用いてストリーミング/ファイルダウンロードクライアント210にHTTPリダイレクトメッセージを送信する可能性がある。リダイレクトメッセージは、リダイレクトURL(たとえば、「http://example.com/per-3/rep-512/seg-N.3gp」)を含み、MPDがストリーミング/ファイルダウンロードクライアント210によって再フェッチされる必要があることを示す拡張ヘッダを含む可能性がある。プロキシユニット213は、代替的に、リダイレクトURLとMPDが再フェッチされる必要があるという指示とを含むボディエンティティを有する3xxタイプのHTTPリダイレクトメッセージを用いる可能性がある。別の例においては、GET要求を受信することに応じて、プロキシユニット213が、MPDがストリーミング/ファイルダウンロードクライアント210によって再フェッチされる必要があることを示すためにストリーミング/ファイルダウンロードクライアント210にエラーコード(たとえば、4xxタイプのHTTPエラーコード)を送信する可能性がある。いずれの場合も、ストリーミング/ファイルダウンロードクライアント210は、新しいMPDが必要とされると判定する可能性があり、MPDのURLを含むHTTP GET要求を送信する可能性がある。プロキシユニット213は、GET要求を受信し、GET要求を修正されたマニフェストファイル(たとえば、MBMSユニット212によって取得された更新されたMPD)にリダイレクトする可能性がある。MBMSユニット212は、更新されたMPDを送信する可能性があり、プロキシユニット213が、その更新されたMPDを受信し、ストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。別の例においては、修正されたマニフェストファイルのGET要求を受信することに応じて、プロキシユニット213が、更新されたMPDをストリーミング/ファイルダウンロードクライアント210にプッシュする可能性がある。いずれの場合も、更新されたMPDを受信した後、ストリーミング/ファイルダウンロードクライアント210は、MBMSを介して利用可能なリプレゼンテーションからのセグメントの新しいHTTP GET要求を送信する可能性があり、プロキシユニット213は、適切なセグメントをフェッチするために(たとえば、ローカルサーバを含む)MBMSユニット212に要求をリダイレクトする可能性がある。MBMSユニット212は、メディアデータの要求されたセグメントを提供する可能性があり、プロキシユニット213が、そのメディアデータの要求されたセグメントを受信し、ストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。
ケース4においては、BM-SC 206からMBMSユニット212によって取得される共通のMPDが、ユニキャストのMPDに含まれない2つ以上のリプレゼンテーション(たとえば、リプレゼンテーション512およびリプレゼンテーション1024)を含み、除外されるリプレゼンテーションは、MBMSを介して利用可能な唯一のリプレゼンテーションである。ケース4において、MBMSユニット212は、(たとえば、ネットワークに基づくサービスを名目的に指す)要求のURLの基底部分をMBMSを介して利用可能なリプレゼンテーション(たとえば、リプレゼンテーション512およびリプレゼンテーション1024)に関するURLの基底部分に修正するようにプロキシユニット213に命令する可能性がある。
その後、プロキシユニット213は、ユニキャストサービスを介して利用可能なリプレゼンテーションのうちの1つを要求するストリーミングクライアント210からのHTTP GET要求を受信する可能性がある。一例においては、GET要求を受信することに応じて、プロキシユニット213が、ユニキャストのMPDに含まれていないブロードキャスト配信を介して利用可能なリプレゼンテーションに関する複数のリダイレクトURLを用いてストリーミングクライアント210にHTTPリダイレクトメッセージを送信する可能性がある。一部の例において、リダイレクトメッセージは、複数のリダイレクトURL(たとえば、http://example.com/per-3/rep-512/seg-N.3gpおよびhttp://example.com/per-3/rep-1024/seg-N.3gp)を含む拡張ヘッダを含み、MPDがストリーミング/ファイルダウンロードクライアント210によって再フェッチされる必要があることを示す可能性がある。その他の例において、ローカルプロキシユニット213は、複数のリダイレクトURLと、MPDが再フェッチされる必要があることを示すインジケータとを含むボディエンティティを有する3xxタイプのHTTPリダイレクトメッセージを使用する可能性がある。別の例においては、GET要求を受信することに応じて、プロキシユニット213が、MPDが再フェッチされる必要があることを示すためにストリーミング/ファイルダウンロードクライアント210にエラーコード(たとえば、4xxタイプのHTTPエラーメッセージ)を送信する可能性がある。
いずれの場合も、ストリーミング/ファイルダウンロードクライアント210は、新しいMPDが必要とされると判定する可能性があり、MPDのURLを含むHTTP GET要求を送信する可能性がある。プロキシユニット213は、GET要求を受信し、GET要求を更新されたマニフェストファイル(たとえば、MBMSユニット212によって取得された更新されたMPD)に導く可能性がある。MBMSユニット212は、更新されたMPDを送信する可能性があり、プロキシユニット213が、その更新されたMPDを受信し、ストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。別の例においては、GET要求を受信することに応じて、プロキシユニット213が、更新されたMPDをストリーミング/ファイルダウンロードクライアント210にプッシュする可能性がある。そして、ストリーミング/ファイルダウンロードクライアント210は、ブロードキャストサービスを介して利用可能なリプレゼンテーションからの好ましいリプレゼンテーションの新しいHTTP GET要求を送信する可能性があり、プロキシユニット213は、要求されたデータをフェッチするために(たとえば、ローカルサーバを含む)MBMSユニット212に要求を導く可能性がある。MBMSユニット212は、要求されたデータを提供する可能性があり、プロキシユニット213が、その要求されたデータを受信し、ストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。
このようにして、プロキシユニット213は、MBMSユニット212を用いてDASHメディアデータまたは任意のその他の好適なデータを受信することを可能にし得る。これは、少なくとも部分的に、ストリーミング/ファイルダウンロードクライアント210が共通のMPD内にない1つまたは複数のリプレゼンテーションの指示を受信する(たとえば、リダイレクトまたはエラーコードを受信する)ときにそのストリーミング/ファイルダウンロードクライアント210の挙動を修正することによって実現され得る。たとえば、MPD内にないリプレゼンテーションの指示を受信することが、ストリーミングクライアント210にMPDのフェッチまたはその他のアクションをトリガさせる可能性がある。
図6は、リダイレクトメッセージに関するボディエンティティ400の一例を示す概念図である。一部の例において、図6のボディエンティティ400は、3xxタイプのHTTPリダイレクトメッセージのボディを表す可能性がある。ボディエンティティ400は、図6の例に示されるように、拡張可能マークアップ言語(XML)または任意のその他のフォーマットなどの構造化されたファイルの言語に従ってフォーマットされる可能性がある。図6は、リダイレクトメッセージに関するボディエンティティの一例を示すにすぎず、様々なその他のボディエンティティおよび/またはリダイレクトメッセージが、本開示の1つまたは複数の技術に従って使用され得る。
図6の例に示されるように、ボディエンティティ400は、種類「EntityBodyType」を有する。エンティティボディの種類は、1つまたは複数の代替的なリソース402A〜402N(集合的に「代替的なリソース402」)を含み得る。代替的なリソース402は、コンテンツまたはコンテンツデータ(たとえば、ストリーミングサービスデータまたはファイルダウンロードサービスデータ)に関する代替的なリソースの位置を表す可能性がある。たとえば、図5A〜図5Dに関連して、代替的なリソース402は、メディアデータの様々なリプレゼンテーションおよびそれぞれのリプレゼンテーションのセグメントに関する(たとえば、MBMSユニット212によって提供される)ローカルの位置をそれぞれ指す可能性がある。
代替的なリソース402は、図6の例に示されるように、それぞれ、種類「AlternativeResourceType」を有し、属性404を含む可能性がある。属性404は、それぞれの代替的なリソースに関する属性(たとえば、URL自体)を含む可能性がある。一部の例において、代替的なリソース402は、MPDURIオブジェクト406または任意のその他の情報などのその他の情報を含む可能性がある。3xxタイプのHTTPリダイレクトメッセージにボディエンティティ400を含めることによって、MBMSミドルウェアユニットが、(たとえば、マルチキャストまたはブロードキャストサービスに関連する)ローカルコンテンツサーバなどの異なる位置に第1のサービス(たとえば、ユニキャストサービス)に関連するコンテンツの要求をその後プロキシユニットおよび/またはストリーミング/ファイルダウンロードクライアントが送信することを引き起こし得る。つまり、本開示の1つまたは複数の技術によれば、ボディエンティティ400は、その後、第2の配信モードによってデータを受信するためのユニット(たとえば、MBMSミドルウェアユニット)から第2の配信モードによってデータを受信するためにそのユニットをアクティブ化した後に使用され得る。
図7Aおよび図7Bは、RTP/RTSPを介して選択的に1つまたは複数のサービスを用いてストリーミングメディアデータを取得するための例示的な動作を示す概念図である。図7Aおよび図7Bの例示的な動作が、以下で、図4のシステム200の通常の文脈の中で説明される。図7Aおよび図7Bの例において、ストリーミング/ファイルダウンロードクライアント210は、RTP/RTSPクライアントである可能性があり、リダイレクト/プロキシユニット205は、プロキシ/リダイレクタである可能性があり、MBMSユニット212は、MBMSクライアントおよびローカルRTSPサーバである可能性があり、プロキシユニット213は、RTSPプロキシである可能性があり、アプリケーションサーバ202は、RTPメディアデータを提供することができるRTSPサーバとセッションの記述のHTTP GET要求への応答を行うためのウェブサーバとの両方である可能性がある。本開示の1つまたは複数の技術によれば、アプリケーション208は、ストリーミング/ファイルダウンロードクライアント210を用いて(たとえば、RTPプロトコルを用いて)メディアデータを取得し得る。たとえば、アプリケーション208は、ストリーミング/ファイルダウンロードクライアント210にマニフェストファイル(たとえば、セッションの記述)の位置を示すURLを送信する可能性があり、マニフェストファイルが、メディアデータに関する識別子を第1のサービス(たとえば、ユニキャスト)に関するリソースの位置にマッピングする。ストリーミング/ファイルダウンロードクライアント210は、プロキシユニット213にHTTP GET要求を送信することによってセッションの記述を取得し得る。プロキシユニット213は、HTTP GET要求を受信し、IPスタック214、モデム216、P-GW 204、およびリダイレクト/プロキシユニット205を介してアプリケーションサーバ202に要求を導き得る。図7Aの例において、プロキシユニット213は、さらに、(たとえば、APIを呼び出すことによって)ユニキャストのセッションの記述のURLの指示をMBMSユニット212に送信し得る。
一部の例において、UEは、そのUEがセッションの記述の最初のフェッチを行うときにそのUEがeMBMSに対応していることを示し得る。このようにして、UEは、いくつのeMBMS対応デバイスがエリア内にあるかをネットワークが知ることを可能にし得る。また、eMBMSの能力を示すことは、ネットワークがUEのアドレスからの将来のトランザクションを追跡することを可能にする。一部の例において、UEは、そのUEがセッションの記述の最初のフェッチを行うときにそのUEの位置を示す可能性もある。いずれの場合も、アプリケーションサーバ202は、HTTP GET要求を受信し、200タイプのHTTP OKメッセージを送信する可能性があり、プロキシユニット213が、そのHTTP OKメッセージを受信し、それに応じてストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。OKメッセージは、ユニキャストのセッションの記述を含み得る。
ストリーミング/ファイルダウンロードクライアント210は、セッションの記述を受信する可能性があり、プロキシユニット213を介してアプリケーションサーバ202にRTSP SETUP要求を送信する可能性がある。SETUP要求は、セッションの記述のURLを含む可能性があり、(たとえば、RTPに従って)メディアデータがどのようにして転送されるのかを指定する可能性がある。一部の例において、SETUP要求は、データを受信するためのローカルポートなどのより多くのまたはその他の情報を含む可能性がある。いずれの場合も、アプリケーションサーバ202は、SETUP要求に応答する可能性があり、ユニキャストセッションが、ストリーミング/ファイルダウンロードクライアント210とアプリケーションサーバ202との間で生成される可能性がある。ストリーミング/ファイルダウンロードクライアント210は、プロキシユニット213を介してアプリケーションサーバ202に1つまたは複数のRTSP PLAY要求を送信する可能性がある。PLAY要求を受信することに応じて、アプリケーションサーバ202は、RTPオーディオおよび/またはRTPビデオデータなどのストリーミングメディアデータを送信する可能性があり、プロキシユニット213が、そのストリーミングメディアデータを受信し、ストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。ストリーミング/ファイルダウンロードクライアント210は、メディアデータを受信し、関連するコンテンツを再生する可能性がある。
ネットワーク側で、BM-SC 206は、コンテンツに関するMBMSサービスを有効化し、MBMSベアラを開始し得る。BM-SC 206は、利用可能なブロードキャストサービスの記述を含む新しいセッションの記述と、関連配信手順(ADP: associated delivery procedure)の記述とを含むUSDをブロードキャストし得る。たとえば、新しいセッションの記述は、ブロードキャスト配信モードに対応するURLと、ユニキャストサービスに対応するフォールバックURLとを含む可能性がある。また、BM-SC 206は、メディアデータが特定のメディアコンテンツに関してMBMSサービスを介して受信されるべきであるという指示をリダイレクト/プロキシユニット205に送信し得る。
指示を受信することに応じて、リダイレクト/プロキシユニット205は、プロキシユニット213にRTSP REDIRECT要求を送信する可能性がある。REDIRECT要求は、UEが新しいURLにコンテンツの後続の要求を発することを引き起こすためにURLを含む新しい拡張を含む可能性がある。REDIRECT要求は、MBMSユニット212をアクティブ化するようにローカルプロキシユニット213に示す可能性がある。一部の例において、REDIRECT要求は、UEが新しいURLに要求を発し始めるべきである時間を示すタイムスタンプを含む可能性がある。タイムスタンプにおいて示される時間の前は、ストリーミング/ファイルダウンロードクライアント210が、プロキシユニット213を介してアプリケーションサーバ202に要求を送信し、アプリケーションサーバ202からメディアデータを受信し続ける可能性がある。
プロキシユニット213は、リダイレクト/プロキシユニット205によって送信されたREDIRECT要求を受信するとき、(たとえば、MBMSユニット212の)APIを利用してMBMSユニット212を有効化する可能性がある。つまり、REDIRECT要求を受信することに応じて、プロキシユニット213は、ブロードキャストサービスを用いてデータを取得するためにMBMSユニット212に指示を送信する可能性がある。MBMSユニット212は、BM-SC 206と通信して(新しいセッションの記述を含む)USDを獲得する可能性がある。MBMSユニット212は、(たとえば、図7Aのステップ3において)ストリーミング/ファイルダウンロードクライアント210から最初に受信されたセッションの記述に関するURLをBM-SC 206から受信されたセッションの記述に関するURLと比較する可能性がある。URLが一致する場合、MBMSユニット212は、ブロードキャスト配信モードによってメディアデータを受信し始める可能性がある。たとえば、MBMSユニット212は、ブロードキャスト配信モードによって送信されているRTPメディアデータを受信するためにFLUTEをアクティブ化する可能性がある。MBMSユニット212は、十分なメディアデータ(たとえば、バッファ)を受信すると、メディアデータに関するローカルサーバとして働く準備が整う可能性がある。
図7Bは、2つのあり得るケースに関する例示的な動作を提供する。第1の選択肢において、MBMSユニット212は、ストリーミング/ファイルダウンロードクライアント210に既存のセッションを破棄させるために(たとえば、プロキシユニット213の)APIを呼び出す可能性がある。たとえば、プロキシユニット213は、すでに受信されたREDIRECT要求の修正されたバージョンをMBMSユニット212のローカルアドレスとともにストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。REDIRECT要求を受信することに応じて、ストリーミング/ファイルダウンロードクライアント210は、RTSP TEARDOWNメッセージを送信し、新しいRTSP SETUPメッセージを送信する可能性がある。新しいSETUPメッセージは、受信されたREDIRECT要求において示されるURL(たとえば、MBMSユニット212の位置)に送信され得る。MBMSユニット212は、プロキシユニット213を介して要求を受信し、プロキシユニット213を介してストリーミング/ファイルダウンロードクライアント210と通信してRTPオーディオおよび/またはRTPビデオデータを提供する可能性がある。つまり、ストリーミング/ファイルダウンロードクライアント210は、MBMSユニット212内に含まれるローカルサーバにプロキシユニット213を介して1つまたは複数のRTSP PLAY要求を送信する可能性があり、ローカルサーバは、それに応じてRTPメディアデータを送信する可能性があり、プロキシユニット213が、そのRTPメディアデータを受信し、ストリーミング/ファイルダウンロードクライアント210に送信する可能性がある。
第2の選択肢において、MBMSユニット212は、プロキシユニット213が特定のメディアコンテンツに対応するRTPメディアデータの要求をMBMSユニット212にリダイレクトすることを引き起こすためのAPIを呼び出す可能性がある。たとえば、プロキシユニット213は、ストリーミング/ファイルダウンロードクライアント210からRTSP PLAY要求を受信し、アプリケーションサーバ202の代わりにMBMSユニット212に要求をリダイレクトする可能性がある。その後、ストリーミング/ファイルダウンロードクライアント210は、MBMSユニット212からRTPオーディオデータおよび/またはRTPビデオデータをプロキシユニット213を介して受信する可能性がある。このようにして、プロキシユニット213は、RTPメディアデータを受信するために様々なサービスおよび配信モードの間で選択を行うためにMBMSユニット212を選択的に有効化または無効化し得る。
図8は、選択的に1つまたは複数のサービスを用いてデータを取得するための技術を実装する例示的なシステム250を示す概念図である。図8の例に示されるように、システム250は、UE側およびネットワーク側を含む。システム250のネットワーク側は、アプリケーションサーバ(「appサーバ」)252、P-GW 254、メッセージサービス(「SMS/OMA/WAP」)255、およびBM-SC 256を含む。アプリケーションサーバ(「appサーバ」)252、P-GW 254、およびBM-SC 256は、それぞれ、図3のアプリケーションサーバ152、P-GW 154、およびBM-SC 156の機能と同じまたは同様である機能を含み得る。メッセージサービス205は、1つまたは複数のUEと通信するためのハードウェア、ファームウェア、ソフトウェア、またはこれらの何らかの組合せを表す可能性がある。たとえば、メッセージサービス205は、ショートメッセージサービス(SMS)センター、OMA-DMサーバ、WAPサーバ、またはその他のプロトコルなどの1つまたは複数のプロトコルを用いてUEと通信するように動作可能なサーバである可能性がある。
図8の例において、システム250のUE側は、アプリケーション258、ストリーミング/ファイルダウンロードクライアント260、MBMSユニット(「MBMSクライアント(ミドルウェア)/ローカルサーバ」)262、メッセージクライアント(「SMS/OMA-DM/WAP」)263、IPスタック264、およびモデム266を含む。アプリケーション258、IPスタック264、およびモデム266は、それぞれ、図3のアプリケーション158、IPスタック164、およびモデム166の機能と同じまたは同様である機能を含み得る。一部の例において、ストリーミング/ファイルダウンロードクライアント260は、図4のストリーミング/ファイルダウンロードクライアント210の機能と同じまたは同様である機能を含み得る。その他の例において、ストリーミング/ファイルダウンロードクライアント260は、異なるまたはさらなる機能を含み得る。MBMSユニット262は、図3のMBMSユニット162の機能と同じまたは同様である機能を含み得る。
図8の例において、MBMSユニット262は、APIを介するなどしてメッセージクライアント263と通信するための機能も含み得る。メッセージクライアント263は、ユニキャストのMPD/セッションの記述のURL(もしくはアクセスされている提示のためのMPDをeMBMSレイヤに通知するためのメカニズム)、MBMSトリガ情報(たとえば、eMBMSレイヤがUSDの更新を調べることを引き起こす/トリガするためのメカニズム)、またはその他の情報などの様々な情報をMBMSユニット262に提供するように動作可能である可能性がある。たとえば、メッセージクライアント263は、MBMSユニット212にブロードキャストサービスを介したデータの受信を開始させるためにMBMSユニット212に情報を送信する可能性がある。
図8のステップ1においては、アプリケーション258が、ストリーミング/ファイルダウンロードクライアント260を介してユニキャストサービスを通じてアプリケーションサーバ252からデータを得る。MBMSユニット262は、無効化される可能性がある。つまり、UEは、データが第1のサービスを介して受信されるべきであるという指示を受信したとき(たとえば、第1のサービスが利用可能な唯1つのサービスであるとき)、第2のサービスを介してデータを受信するためのユニットを無効化する可能性がある。図8の例のステップ2においては、ネットワーク内のHARDユニット(図示せず)が、高アタッチレートを検出する。HARDユニットは、高アタッチレートをBM-SC 256に示してMBMSセッション(たとえば、MBMSベアラ)を有効化する。BM-SC 256は、UEに指示を送信するようにメッセージサービス255(たとえば、SMSセンター、OMA-DM/WAPサーバ)に要求する。メッセージサービス255は、UEのSMS/OMA-DM/WAPレイヤ(たとえば、メッセージクライアント263)にメッセージを送信する可能性がある。このようにして、ネットワークは、データがブロードキャストサービスを介して受信されるべきであるという指示(たとえば、メッセージ)を送信し得る。メッセージは、ブロードキャストサービスに関するUSD更新を含み得る。
図8の例のステップ3においては、メッセージクライアント263が指示(たとえば、MBMSユニット262をアクティブ化する命令)を受信するとき、UE内のメッセージクライアント263(たとえば、SMS/OMA-DM/WAPレイヤ)は、MBMSミドルウェア(たとえば、MBMSユニット262)に登録する。つまり、本開示の1つまたは複数の技術によれば、システム250のネットワーク側は、(SMS、WAPプッシュ、OMA-DMなどの)プッシュメカニズムを用いてMBMSミドルウェアを直接ウェイクアップし得る。
図8の例のステップ4において、アプリケーション258は、ブロードキャストまたはマルチキャストサービスを用いて(たとえば、ブロードキャストまたはマルチキャスト配信モードを用いて)MBMSユニット262が取得したデータをMBMSユニット262から間接的に取得することによってMBMSベアラ(たとえば、BM-SC 256)からデータを得る。言い換えれば、UEは、データが第2のサービスを介して受信されるべきであるという指示を受信するとき、第2のサービスを介してデータを受信するためのユニット(たとえば、MBMSユニット262)をアクティブ化し、第2のサービスを介してデータを受信するためのユニットからデータを受信する可能性がある。そして、第2のサービスを介して受信されたデータは、(たとえば、ストリーミング/ファイルダウンロードクライアント260を介して)間接的にアプリケーション258に提供され得る。図8の例において、システム250のネットワーク側の1つまたは複数の構成要素は、状態情報を保有するように動作可能である可能性がある。つまり、図8の例は、ネットワークの状態を必要とする可能性があり、どのUEが「PUSH」通知を送信すべきかを特定する必要がある。一部の例においては、プッシュされるコンテンツが、USD自体を含む可能性がある。図8の例において、アプリケーション258は、転送に関知しない。つまり、アプリケーション258は、データがどのようにして取得されるのかのいかなる指示も持つ必要がない。むしろ、ストリーミング/ファイルダウンロードクライアント260は、(たとえば、新しいMPD、セッションの記述、またはその他のマニフェストファイルを含む)更新されたUSDを受信し、アプリケーションサーバ252の代わりにMBMSユニット262にデータの要求を送信する可能性がある。
図9は、選択的に1つまたは複数のサービスを用いてデータを取得するための技術を実装する例示的なシステム300を示す概念図である。図9の例に示されるように、システム300は、UE側およびネットワーク側を含む。システム300のネットワーク側は、アプリケーションサーバ(「appサーバ」)302、P-GW 304、ノード303、MBMSゲートウェイ(MBMS-GW)305、およびBM-SC 306を含む。アプリケーションサーバ(「appサーバ」)302、P-GW 304、およびBM-SC 306は、それぞれ、図4のアプリケーションサーバ202、P-GW 204、およびBM-SC 206の機能と同じまたは同様である機能を含み得る。ノード303は、UEと直接通信するためのネットワークハードウェア、ファームウェア、ソフトウェア、またはこれらの任意の組合せを表す可能性がある。たとえば、ノード303は、システム300のUE側の1つまたは複数の構成要素と無線インターフェーステクノロジーによって通信するように動作可能なセルラーネットワークの「NodeB」または「eNodeB」を表す可能性がある。MBMS-GW 305は、MBMS制御機能を実行するように動作可能なハードウェア、ファームウェア、ソフトウェア、またはこれらの任意の組合せを表す可能性がある。たとえば、MBMS-GW 305は、ノード303などのネットワークの様々なノードにマルチキャストまたはブロードキャストデータを送信するように動作可能である可能性がある。MBMS-GW 305は、BM-SC 306からブロードキャストまたはマルチキャストデータを受信し、1つまたは複数のノードへのブロードキャストを調整し得る。
図9の例において、システム300のUE側は、アプリケーション308、ストリーミング/ファイルダウンロードクライアント310、MBMSユニット(「MBMSクライアント(ミドルウェア)/ローカルサーバ」)312、IPスタック314、およびモデム316を含む。アプリケーション308、ストリーミング/ファイルダウンロードクライアント310、IPスタック314、およびモデム316は、それぞれ、図4のアプリケーション218、ストリーミング/ファイルダウンロードクライアント210、IPスタック214、およびモデム216の機能と同じまたは同様である機能を含み得る。MBMSユニット312は、図4のMBMSユニット212の機能と同じまたは同様である何らかの機能を含み得る。図9の例において、MBMSユニット312は、異なるまたはさらなる機能を含み得る。たとえば、MBMSユニット312は、システム300のネットワークから命令を受信するための機能を含み得る。つまり、MBMSユニット312は、ノード303、MBMS-GW 305、および/またはBM-SC 306などの1つまたは複数の構成要素から様々な情報を受信し得る。
図9の例のステップ1においては、アプリケーション308が、ストリーミング/ファイルダウンロードクライアント310を介してユニキャストサービスを通じてアプリケーションサーバ302からデータを得る。図9の例のステップ2においては、ネットワーク内のHARDユニット(図示せず)が、高アタッチレートを検出する。HARDユニットは、高アタッチレートをBM-SC 306に示してMBMSセッション(たとえば、MBMSベアラ)を有効化する。BM-SC 306は、新しい一時モバイルグループ識別子(TMGI: temporary mobile group identifier)を追加するためにMBMSセッション設定を送信することによってMBMSを有効化し、そのことが、eNodeBおよび/またはマルチセル/マルチキャスト調整エンティティ(MCE)(たとえば、ノード303)がUSD変更通知などの無線インターフェースシグナリングを送信することをトリガする。無線インターフェースシグナリングは、UE側のモデム316によって受信され得る。このようにして、システム300のネットワーク側は、無線インターフェースシグナリングを用いて、第2のサービス(たとえば、MBMSベアラまたはその他のマルチキャストもしくはブロードキャストサービス)の可用性をUEに示し得る。
図9の例のステップ3において、モデム316は、指示(たとえば、USD変更通知)を受信するとき、USDの変更をMBMSミドルウェア(たとえば、MBMSユニット312)に示す。つまり、本開示の1つまたは複数の技術によれば、システム300のネットワーク側は、SIBブロードキャスト、MCCH通知、USD変更通知、またはその他のシグナリングなどの無線インターフェースシグナリングを使用して、UEにマルチキャストまたはブロードキャストサービスの可用性を示し得る。
図9の例のステップ4において、アプリケーション308は、ブロードキャストまたはマルチキャストサービスを用いて(たとえば、ブロードキャストまたはマルチキャスト配信モードによって)MBMSユニット312が取得したデータをMBMSユニット312から間接的に取得することによってMBMSベアラ(たとえば、BM-SC 306)からデータを得る。言い換えれば、UEは、メディアデータが第2のサービスを介して受信されるべきであるという指示を受信するとき、第2のサービスを介してデータを受信するためのユニット(たとえば、MBMSユニット312)をアクティブ化し、第2のサービスを介してデータを受信するためのユニットからメディアデータを受信する可能性がある。そして、第2のサービスを介して受信されたデータは、(たとえば、ストリーミング/ファイルダウンロードクライアント310を介して)間接的にアプリケーション308に提供され得る。図9のこの手法は、ストリーミングサービスとファイルダウンロードとの両方のために使用され得る。図9の例において、アプリケーション308は、転送に関知しない。つまり、アプリケーション308は、データがどのようにして取得されるのかのいかなる指示も持つ必要がない。一部の例において、MCCH変更通知は、ネットワークがその他の周波数でサービスを追加することがこの周波数に関するMCCH変更通知をトリガしないので、多帯域/多周波数環境ではうまく働かない可能性がある。
図10は、選択的に1つまたは複数のサービスを用いてデータを取得するための技術を実装する例示的なシステム350を示す概念図である。図10の例に示されるように、システム350は、UE側およびネットワーク側を含む。システム350のネットワーク側は、アプリケーションサーバ(「appサーバ」)352、P-GW 354、およびBM-SC 356を含む。アプリケーションサーバ(「appサーバ」)352、P-GW 354、およびBM-SC 356は、それぞれ、図4のアプリケーションサーバ202、P-GW 204、およびBM-SC 206の機能と同じまたは同様である機能を含み得る。BM-SC 356は、P-GW 304などのシステム350のネットワーク側のその他の構成要素にブロードキャストの可用性を示すための機能を含み得る。
図10の例において、システム350のUE側は、アプリケーション358、ストリーミング/ファイルダウンロードクライアント360、MBMSユニット(「MBMSクライアント(ミドルウェア)/ローカルサーバ」)362、IPスタック364、およびモデム366を含む。アプリケーション358、ストリーミング/ファイルダウンロードクライアント360、IPスタック364、およびモデム366は、それぞれ、図4のアプリケーション218、ストリーミング/ファイルダウンロードクライアント210、IPスタック214、およびモデム216の機能と同じまたは同様である機能を含み得る。MBMSユニット362は、図4のMBMSユニット212の機能と同じまたは同様である何らかの機能を含み得る。図9の例において、MBMSユニット362は、異なるまたはさらなる機能を含み得る。たとえば、MBMSユニット362は、システム350のネットワーク側から命令を受信するための機能を含み得る。つまり、MBMSユニット362は、P-GW 354などの1つまたは複数の構成要素から様々な情報を受信し得る。
図10の例のステップ1においては、アプリケーション358が、ストリーミング/ファイルダウンロードクライアント360を介してユニキャストサービスを通じてアプリケーションサーバ352からデータを得る。図10の例のステップ2においては、ネットワーク内のHARDユニット(図示せず)が、高アタッチレートを検出する。HARDユニットは、高アタッチレートをBM-SC 356に示してMBMSセッション(たとえば、MBMSベアラ)を有効化する。BM-SC 356は、P-GW 354がUEに指示を送信することを引き起こすためにP-GW 354に要求を送信する。指示は、PCOまたはNASシグナリングを使用する可能性がある。
図10の例のステップ3において、モデム366は、指示を受信するとき、ブロードキャストまたはマルチキャストサービスの可用性をMBMSミドルウェア(たとえば、MBMSユニット362)に示す。つまり、本開示の1つまたは複数の技術によれば、システム350のネットワーク側は、NASシグナリング、PCO、またはその他のシグナリングなどのP-GWシグナリングを用いてUEにマルチキャストまたはブロードキャストサービスの可用性を示し得る。
図10の例のステップ4において、アプリケーション358は、ブロードキャストまたはマルチキャストサービスを用いて(たとえば、ブロードキャストまたはマルチキャスト配信モードによって)MBMSユニット362が取得したデータをMBMSユニット362から間接的に取得することによってMBMSベアラ(たとえば、BM-SC 356)からデータを得る。言い換えれば、UEは、データが第2のサービスを介して受信されるべきであるという指示を受信するとき、第2のサービスを介してデータを受信するためのユニット(たとえば、MBMSユニット362)をアクティブ化し、第2のサービスを介してデータを受信するためのユニットからデータを受信する可能性がある。そして、第2のサービスを介して受信されたデータは、(たとえば、ストリーミング/ファイルダウンロードクライアント360を介して)間接的にアプリケーション358に提供され得る。図10の例において、システム350のネットワーク側の1つまたは複数の構成要素は、状態情報を保有するように動作可能である可能性がある。つまり、図10の例は、ネットワークの状態を必要とする可能性があり、どのUEが指示を送信すべきかを特定する必要がある。図10の例において、アプリケーション358は、転送に関知しない。つまり、アプリケーション358は、データがどのようにして取得されるのかのいかなる指示も持つ必要がない。
図11Aおよび図11Bは、1つまたは複数のサービスを用いてネットワークを介してデータを取得するための例示的な動作を示す概念図である。図11Aおよび図11Bの例においては、UEで実行されるアプリケーションが、コンテンツ(たとえば、メディアコンテンツ、ファイル、またはその他のコンテンツ)を要求する可能性がある。UEの1つまたは複数の構成要素(たとえば、ストリーミングまたはファイルダウンロードクライアント)が、ネットワークの構成要素と通信して、コンテンツに関するデータを受信するためにどんなサービスが利用可能であるかを判定し得る。UEは、データがユニキャストサービスのみを介して利用可能であると判定する可能性があり、ユニキャストサービスに登録する可能性がある。UEは、いかなるマルチキャストまたはブロードキャストサービスも利用可能でないと判定されるときにユニキャストモードになる可能性があり、その後、ユニキャストサービスを介して(たとえば、ユニキャスト配信モードを用いて)データを受信する可能性がある。UEは、USDに対する更新を周期的に調べて、ブロードキャストまたはマルチキャストサービスが利用可能であるかどうかを判定する可能性がある。ブロードキャストサービスが利用可能であると判定すると、UEは、ブロードキャストサービスを介してデータを受信し、ブロードキャストモードになり、ユニキャストチャネルを破棄する可能性がある。
図12は、1つまたは複数のサービスを用いてネットワークを介してデータを取得するための例示的な動作を示す概念図である。図12の例においては、UEが、(たとえば、UEのストリーミングまたはファイルダウンロードクライアントから)データの要求を受信する可能性があり、eMBMSをアクティブ化する可能性がある。UEは、ブロードキャストまたはマルチキャストサービスが利用可能でないときなどにユニキャストサービスを用いてデータを受信する可能性がある。ネットワークのHARDは、高アタッチレートまたはコンテンツの高い需要を検出し、BM-SCに高い需要を通知する可能性がある。1ステップの手法においては、BM-SCが、ユニキャストサービスをeMBMSブロードキャストサービスに直接変換する可能性があり、UEが、図11Aおよび図11Bのステップ2、3、および8〜15に示されるようにブロードキャストサービスに登録する可能性がある。2ステップの手法においては、BM-SCが、最初に、ユニキャストサービスをユニキャストを介したeMBMSサービスに変換する可能性があり、UEが、図11Aおよび図11Bのステップ2〜15に示されるようにeMBMSユニキャストサービスからeMBMSブロードキャストサービスに移行する可能性がある。
図13Aおよび図13Bは、1つまたは複数のサービスを用いてネットワークを介してデータを取得するための例示的な動作を示す概念図である。特に、図13Aおよび図13Bの例は、非eMBMSユニキャストサービスのeMBMSブロードキャストサービスへの切り替えを説明し得る。一部の例においては、非eMBMSユニキャストサービスからeMBMSブロードキャストサービスに切り替えるときに、BM-SCが、非eMBMSサービスへの高アタッチメントレートを判定する(たとえば、その高アタッチメントレートの指示を受信する)可能性がある。そして、BM-SCは、サービスのeMBMS送信を有効化し、コンテンツ配信をユニキャスト配信からブロードキャスト配信に切り替える可能性がある。そのような移行は、名目的なユニキャストコンテンツまたはサービスの高い需要が検出されるときなどにサービスネットワークプロバイダがコンテンツプロバイダの様々なコンテンツフィードをユニキャスト配信からブロードキャスト配信に変換することを可能にするビジネスの合意に従って行われ得る。
図13Aおよび図13Bの例においては、UEのアプリケーションが非eMBMSユニキャストサービスを用いて始動するとき、UEのeMBMSクライアントは、アクティブ化されない可能性がある。本明細書に記載の技術によれば、eMBMSクライアントは、UEがユニキャストまたはブロードキャスト配信を通じてUSDを獲得することをトリガするネットワークリダイレクションによるなど様々な方法で有効化され得る。たとえば、ネットワークリダイレクトは、HTTP/RTSPリダイレクト、OMAプッシュ、またはネットワークエンティティから送信されるその他のシグナリングである可能性がある。
図13Aおよび図13Bの例においては、UEのアプリケーションが、コンテンツアイテムを要求する可能性がある。アプリケーション(たとえば、ストリーミングまたはファイルダウンロードクライアント)からの要求に応じて、UEは、オーバーザトップコンテンツ(OTT)サービスまたはパケット交換ストリーミングサービス(PSS)を用いてユニキャストサービスを介してデータを取得し得る。その後、BM-SCは、非eMBMSユニキャストサービスがサービスのeMBMS送信に切り替えられるべきであると判定する可能性がある。たとえば、そのような判定は、取得される情報に基づいて、イベントに基づいて、および/または非eMBMSユニキャストサービスの高アタッチメントレートの検出に基づいてなされる可能性がある。一部の例において、BM-SCは、そのような情報がBM-SCに知られている場合、アタッチされたUEのMBMS切り替え能力へのユニキャストを利用する可能性もある。非eMBMSユニキャストサービスがeMBMS送信に切り替えられるべきであると判定する一例として、ネットワークのHARDが、高アタッチレートを判定し、BM-SCに高アタッチレートを示す可能性がある。BM-SCは、指示を受信することに応じてeMBMSセッションを設定することを決定する可能性がある。図13Aおよび図13Bの例においては別々の構成要素として示されているが、HARDおよびBM-SCは、一部の例において、単一の構成要素の一部である可能性がある。
eMBMSセッションを設定することを決定した後、BM-SCは、更新されたUSDをブロードキャストする可能性がある。一部の例において、ユーザサービスは、ブロードキャストおよびユニキャストに関連する情報を含む可能性がある。その他の例において、ユーザサービスは、ブロードキャストに関連する情報のみを含む可能性がある。BM-SCは、USD(たとえば、USDブロードキャストチャネル)のためのeMBMSセッションをすでに確立した場合、確立されたブロードキャストチャネルを介して更新されたUSDを送信し得る。一部の例において、BM-SCは、後の時点で(たとえば、図13Aのステップ9において)更新されたUSDのためのeMBMSセッションを確立するか、またはユニキャストからブロードキャストへの切り替えのトリガに更新されたUSDを含める可能性がある。つまり、BM-SCは、更新されたUSDをブロードキャスト、ユニキャスト、またはその他の手段によって利用され得るようにする可能性がある。
BM-SCは、(たとえば、3GPP技術仕様23.246、「Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description, (Release 12)」v12.1.0、2014年3月において規定されているように)MBMSセッションを設定し得る。一部の例において、BM-SCは、更新されたUSDを送信することと平行してMBMSセッションを設定し得る。eNBが、eMBMSセッションを開始する可能性があり、SIB、またはその他の通知方法を用いてUEに更新を送信し得る。つまり、eNBは、必要な場合、RRCを適用し、更新されたSIB13およびSIB15メッセージを送信し得る。eNBは、eMBMSサービスの存在をすべてのUEに知らせるためにMCCH変更通知を実行し得る。
MBMSセッションが確立されると、トリガが、非eMBMSサービスを消費するUEに(たとえば、ネットワークのデバイスによって)送信され、サービスまたはコンテンツに関するMBMSユーザサービスの可用性を示す可能性がある。たとえば、ネットワークのデバイスが、UEをユニキャストの消費からブロードキャストの消費に切り替えさせるための指示を送信する可能性がある。一部の例において、ネットワークのデバイスは、さらに、USDの更新を送信する可能性がある。MCCH通知またはその他のトリガを受信した後、UEは、ユニキャストサービスを使用することからブロードキャストサービスを使用することにリダイレクトされる可能性がある。つまり、本明細書に記載の技術に従って構成されたUEに関して、UEは、MBMSクライアントをアクティブ化する可能性がある。UEは、利用可能である場合はブロードキャストチャネルを通じて、またはユニキャストベアラを通じてUSDを受信するためにサービス発見手順を開始し得る。UEは、USDを受信し、適切なカバレッジの範囲内にあり、サービスを消費しているとき、ユニキャストからブロードキャストの受信に切り替わり得る。UEは、ユニキャストかまたはブロードキャストかのどちらかのサービスを通じてBM-SCからUSDを獲得し得る。任意で、UEのMBMSクライアントは、BM-SCに登録し、キーを要求する可能性がある。つまり、UEが新しく確立されたMBMSサービスに登録しておらず、USDがサービス登録が必要とされることを示す場合、UEは、MBMSサービス登録を実行し、(たとえば、サービス保護が有効化される場合)サービスキーを取得する可能性がある。一部の例において、UEは、そのUEが関心のある周波数をeNBに示す可能性があり、eNBは、適切な周波数へのUEのハンドオーバを実行する可能性がある。つまり、UEは、無線でSIB15から受信された情報および/またはBM-SCからのUSDから、対応するMBMSサービスが異なる周波数で送信されていると判定する可能性がある。結果として、UEは、示された周波数に切り替えたいというUEの望みを示すために「MBMSInterestIndication」メッセージを送信する可能性がある。それから、eNBが、UEを適切な周波数にハンドオーバし得る。そして、UEは、新しい周波数で送信されたSIBからシステム情報を更新し得る。
BM-SCは、コンテンツサーバなどからコンテンツを受信し、ブロードキャストサービスを用いてデータを送信する可能性がある。図13Aおよび図13Bの例においてはコンテンツサーバからコンテンツを取得するものとして示されているが、BM-SCは、一部の例において、PSSサーバまたはその他の位置からコンテンツを取得する可能性がある。様々な例において、BM-SCは、MBMSセッションを確立した後、いつでもコンテンツを取得し得る。そして、BM-SCは、取得したコンテンツをMBMSベアラを介して送信し得る。その後、UEは、ブロードキャストモードで動作する可能性があり、(たとえば、その他のユニキャストサービスが存在しない場合)ユニキャストチャネルを破棄する可能性がある。図13Aおよび図13Bの例においては、ステップ3、4、5、6、9、10、11、および/またはその他の動作のうちの一部またはすべてなどの様々な動作のための基準を定める新しいシグナリングが、MooDの下で定義される可能性がある。
図14は、1つまたは複数のサービスを用いてネットワークを介してデータを取得するための例示的な動作を示す概念図である。図14の例においては、UEが、(たとえば、UEのストリーミング/ファイルダウンロードクライアントから)データの要求を受信する可能性がある。UEは、OTTまたはPSSを用いるユニキャストサービスを用いてデータを受信する可能性がある。ネットワークのHARDは、高アタッチレートまたはサービスの高い需要を検出し、BM-SCに通知する可能性がある。BM-SCは、ユニキャストサービスをユニキャストを介したeMBMSサービスに変換し、(たとえば、eMBMSユニキャストサービスが利用可能であることを示す)更新されたUSDが利用可能であるという指示を送信する可能性がある。その後、UEは、非eMBMSユニキャストサービスからeMBMSユニキャストサービスにリダイレクトされる可能性がある。UEは、eMBMSをアクティブ化する可能性があり、図13Aおよび図13Bのステップ3〜15に示されるようにeMBMSユニキャスト配信モードからブロードキャスト配信モードに移行する可能性がある。
図15Aおよび図15Bは、1つまたは複数のサービスを用いてネットワークを介してデータを取得するための例示的な動作を示す概念図である。ステップ1から5までにおいて、UEは、コンテンツを通常のMBMSユーザサービスとして消費する可能性がある。一部の例において、サービスは、はじめ、非MBMSユーザサービスであった可能性がある。図15Aおよび図15Bの例においては、アプリケーション(たとえば、ストリーミング/ファイルダウンロードクライアント)からの要求に応じて、UEが、ブロードキャストまたはユニキャストサービスを用いてUSDを取得する可能性がある。要求されたコンテンツは、MBMSユーザサービスを通じて利用可能である可能性がある。一部の例において、USDは、eMBMSがブロードキャストとユニキャストとの両方の配信モードを介して利用可能であることを示す可能性がある。一部の例において、USDは、MBMSユーザサービスがユニキャストとブロードキャストとの両方の配信モードを介して利用可能であることを示す可能性がある。様々な例において、USDは、ユニキャストチャネルに関連する情報を含めないことによってMBMSユーザサービスがブロードキャストを介してのみ利用可能であることを示す可能性がある。
UEのMBMSユニットは、コンテンツサーバに登録し、キーを要求する可能性がある。一例として、UEは、MBMSユーザサービスの登録によってそのUEがMBMSユーザサービスを獲得したいことをBM-SCに知らせる可能性がある。つまり、UEは、サービス保護が有効化される場合、サービスキー(MSK)を取得する可能性がある。一部の例において、MBMSユーザサービスの登録は、UEの消費の意図を示す可能性がある。一部の例において、MBMSユーザサービスの登録は、必要な情報を取得するためにサービスに登録されるUEの意図を示す可能性がある。その後、UEは、ブロードキャスト配信モードがメディアコンテンツのために利用可能であることを検出する可能性があり、ブロードキャストモードに入る可能性がある。BM-SCは、コンテンツサーバからコンテンツを受信し、ブロードキャスト配信モードによってデータを送出する可能性がある。
一部の例において、図15Aおよび図15Bの後続のステップは、MooDの態様をサポートし得る。つまり、ステップ6以降は、MBMSユーザサービスを非eMBMSユーザサービスに変えることを可能にし得る。ステップ6において、サービスの動作の手順が、集められる可能性がある。これらの手順は、MCEの集計手順、(たとえば、登録/登録解除、もしくはその他の手段に基づく)BM-SCに基づく集計手順、またはその他の動作の見地(たとえば、MBMSユーザサービスもしくはその他の非MBMSサービスの人気)を含む可能性がある。一例として、BM-SCは、いくつのUEがブロードキャストサービスの受信に関心があるかについてMCEから無線アクセスネットワーク(RAN)の集計の結果を得る可能性がある。ある時点で、収集された情報に基づいて、BM-SCは、配信モードがブロードキャスト配信からユニキャスト配信に切り替えられるべきであると判定する可能性がある。BM-SCは、集計、登録/登録解除情報、および/またはその他の情報(たとえば、あらかじめ構成されたタイマーが切れることなど)に基づいて判定を行い得る。一例として、MCEの入力および/またはその他の情報(たとえば、登録もしくは登録解除情報)に基づいて、BM-SCは、ユニキャストサービスへの切り替えを決定する可能性がある。
判定の後、BM-SCは、MBMS送信が間もなく停止することを示す可能性がある。BM-SCは、USDを更新すること、帯域内スケジュールフラグメント(Schedule Fragment)を用いてMBMS送信の終わりを示すこと、またはその他の方法などの様々な方法で差し迫った停止を示す可能性がある。UEは、(たとえば、帯域内スケジュールフラグメント情報またはUSDの更新を用いて)ブロードキャスト配信モードの時間の終わりの指示を受信する可能性がある。
図15Bに目を向けると、UEは、eMBMSセッションが間もなく停止することを検出する可能性があり、無線リソース接続(RRC)を設定する可能性がある。RRCは、MBMSブロードキャスト配信セッションの終了時間の前に確立される可能性がある。UEは、PDNが前に設定された場合、パケットデータネットワーク(PDN)接続を設定する可能性もある。つまり、UEは、必要に応じてPDN接続を確立する可能性がある。BM-SCは、ブロードキャスト配信モードを停止する可能性があり、eNBは、SIB、MCCH通知、またはその他の通知方法を用いてUEに通知する可能性がある。たとえば、BM-SCは、3GPP TS 23.246、「Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description」で規定されたようにMBMSブロードキャスト配信セッション停止手順を実行する可能性がある。一部の例において、BM-SCは、MBMSユーザサービスがユニキャスト配信モードを介してのみ利用可能であることを示すためにUSDを更新する可能性がある。一部の例において、MBMSユーザサービスは、USDからサービスを取り除くことによってBM-SCによって終了される。
ブロードキャスト配信モードが止まった後、UEは、ブロードキャストまたはユニキャストを介して新しいUSDを獲得する可能性がある。新しいUSDは、eMBMSサービスがユニキャスト配信モードでのみ利用可能であると指定する可能性がある。結果として、UEは、ユニキャストモードになる可能性があり、ユニキャスト配信モードによってメディアデータを受信する可能性がある。図15Aおよび図15Bの例においては、MooD WIが、ステップ3、6、7、8、13、および/またはその他の動作のうちの一部またはすべてなどの様々な動作のための基準を定める新しいシグナリングを定義する可能性がある。
図16は、1つまたは複数のサービスを用いてネットワークを介してデータを取得するための例示的なシステムを示す概念図である。図16の例は、高レベルのMooDアーキテクチャを表す可能性がある。図16の例は、本明細書に記載の技術を実行するためのシステムの一例を表すにすぎず、様々なその他のシステムが、本開示に従って使用され得る。
図16の例は、公衆ネットワーク500(たとえば、インターネット)、セルラーデータネットワーク(CDN)502、パケット交換サービス(PSS)サーバ504、パケットデータネットワークゲートウェイ(PDN-GW)506、eNodeB(eNB) 508、ブロードキャストおよびマルチキャストサービスセンター(BM-SC)510、MBMSゲートウェイ(MBMS-GW)512、ならびにユーザ機器(UE)515を含む。一部の例において、公衆ネットワーク500、CDN 502、PSSサーバ504、PDN-GW 506、eNB 508、BM-SC 510、および/またはMBMS-GW 512は、ワイヤレスまたはセルラーサービスプロバイダネットワークなどのサービスプロバイダネットワークの構成要素を表す可能性がある。UE 515は、サービスプロバイダの加入者のユーザ機器を表す可能性がある。
図16の例において、UE 515は、オーバーザトップ(OTT)サービス520A、PSSサービス522A、およびMBMSサービス524Aなどの、eNB 508およびPDN-GW 506を通じたユニキャスト配信を介した様々なコンテンツまたはサービスにアクセスする可能性がある。一部の例において、MBMSサービス524Aは、unicastAccessURIを用いて提供される可能性がある。PDN-GW 506は、様々なソースからそのようなサービスを取得する可能性がある。たとえば、PDN-GW 506は、CDN 502と通信してOTTサービス520Bを取得する可能性があり、および/または公衆ネットワーク500と通信してOTTサービス520Cを取得する可能性がある。PDN-GW 506は、CDN 502と通信してPSSサービス522Bを取得する可能性があり、および/またはPSSサーバ504と通信してPSSサービス522Cを取得する可能性がある。PDN-GW 506は、CDN 502と通信してMBMSサービス524Bを取得する可能性があり、PSSサーバ504と通信してMBMSサービス524Cを取得する可能性があり、および/またはBM-SC 510と通信してMBMSサービス524Dを取得する可能性がある。
OTTサービス520A〜C、PSSサービス522A〜C、またはMBMSサービス524A〜Dのいずれかの高アタッチメントレートを(たとえば、BM-SC 510によって)サービスプロバイダが判定すると、BM-SC 510は、MBMSベアラを介して同じコンテンツを運ぶためにeMBMSユーザサービスをアクティブ化し得る。たとえば、BM-SC 510は、公衆ネットワーク500および/またはCDN 502と通信して、ユニキャスト配信を介してOTTサービス530を取得し、サービスをブロードキャスト配信に変換し得る。BM-SC 510は、CDN 502と通信して、ユニキャスト配信を介してPSSサービス532および/またはMBMSサービス534を取得し、サービスをブロードキャスト配信に変換し得る。
その後、BM-SC 510は、ブロードキャスト配信を介してサービス530、532、および/または534を提供し得る。UE 515は、ブロードキャスト配信を用いてMBMSサービス540を介してサービス530、532、および/または534のうちの1つまたは複数を取得し得る。このようにして、本明細書に記載の技術は、UEが複数の配信モードによってコンテンツおよび/またはサービスを取得することを可能にし得る。
図17Aおよび図17Bは、1つまたは複数のサービスを用いてネットワークを介してデータを取得するための例示的な動作を示す概念図である。図17Aおよび図17Bの例示的な動作は、たとえば、UEがMooD動作をサポートし、MBMS対応UEが少なくともサービスの消費の指示をネットワークに(たとえば、BM-SCに)提供し得るときに使用され得る。一部の例において、BM-SCは、ユニキャスト、ブロードキャスト、および/またはマルチキャスト配信モードおよび/またはサービスに関する決定の実行の中心となり得る。図17Aおよび図17Bの例においては単一の構成要素として示されているが、BM-SCの物理的実装は、様々な例において(たとえば、ユニキャストコンテンツのスケーラブルな配布のためのプロキシサーバを用いて)分散される可能性がある。同様に、図17Aおよび図17Bの例においては単一の構成要素として示されているが、MBMS対応UEは、様々な例において、MBMS UEおよびアプリケーションクライアントなどの複数の構成要素に分割される可能性がある。
図17Aの例のステップ1において、コンテンツサーバは、ストリーミングメディアまたはダウンロード可能なコンテンツなどのサービスを提供する可能性がある。一部の例において、BM-SCは、このサービスが存在的MBMSユーザサービスであることを知らされ得る。潜在的MBMSユーザサービスは、一部の例において、MBMSユーザサービスに潜在的にマイグレーションされる得る非MBMSユーザサービスと定義され得る可能性がある。図17Aの例のステップ2において、BM-SCは、潜在的MBMSユーザサービスについてMBMS対応UEに知らせる。ステップ3において、MBMS対応UEは、潜在的MBMSユーザサービスのUEの消費についてBM-SCに知らせる。一部の例において、UEは、UEの消費についてBM-SCに継続的に最新情報を与える可能性がある。一部の例において、UEは、UEについての位置および/または消費のメタデータをさらに含む可能性がある。この情報を送信することは、BM-SCが潜在的MBMSユーザサービスをMBMSユーザサービスにマイグレーションすることへのUEによる暗黙的な同意として働く可能性がある。そのようなマイグレーションは、以下の方法のうちの1つまたは複数において、つまり、サービスへの直接の登録によって、または通常のデータ要求(たとえば、潜在的MBMSユーザサービスの要求)を用いる間接的な登録によってUEにより扱われ得る。一部の例において、UEがBM-SCに潜在的MBMSユーザサービスのUEの消費を知らせる方法、および/またはUEがマイグレーションを扱う方法は、スケーラビリティの考慮に依存する可能性がある。
図17Aのステップ4において、BM-SCは、潜在的MBMSユーザサービスがMBMSユーザサービスにマイグレーションされるべきかどうかを判定する。BM-SCは、登録からの情報および/またはその他の情報を用いて判定を行う可能性がある。一部の例において、そのような判定は、潜在的MBMSユーザサービス全体を通じて定期的に起こる可能性がある。つまり、BM-SCは、周期的に(たとえば、5秒毎、30秒毎などに)、各UEが潜在的MBMSユーザサービスの消費を開始もしくは終了した後、または何らかのその他の間隔で判定を行う可能性がある。ステップ5において、UEは、コンテンツサーバと直接通信することによって、またはBM-SCを要求に関するプロキシとして使用することによって(たとえば、BM-SCが、コンテンツサーバに要求を転送する可能性がある)潜在的ユーザサービスからのデータを要求する。ステップ6において、UEは、要求されたデータを通常のユニキャストサービスとして受信する。
図17Aのステップ7において、BM-SCは、ある時点で、コンテンツがブロードキャストモードによってより効率的に提供されると判定する可能性があり、潜在的MBMSユーザサービスに関するMBMSユーザサービスを開始する可能性がある。ステップ8において、BM-SCは、ブロードキャストモードでMBMSユーザサービスを確立し、コンテンツを消費しているMBMS対応UEにMBMSユーザサービスを介したコンテンツの可用性について知らせる。ステップ9において、BM-SCは、コンテンツサーバからコンテンツを取り出し始める。ステップ10において、BM-SCは、通常、ブロードキャストモードが有効化されるようにして、確立されたMBMSユーザサービスを介して取り出されたコンテンツの配布を開始する。
ここで図17Bに目を向けると、ステップ11において、UEは、MBMSユーザサービスに加わり、MBMSユーザサービスを通じてコンテンツを受信し始める。図17Bのステップ12において、UEは、MBMSユーザサービスを通じて受信されたコンテンツを消費し始める。ステップ13において、UEは、サービスの消費についてBM-SCに継続的に知らせる(たとえば、アカウントのスケーラビリティを取得する)可能性がある。一部の例において、UEは、サービスの登録解除の指示を与える可能性もある。ステップ14において、BM-SCは、MBMSユーザサービスを介してコンテンツを配信することがもはや最も効率的ではないと判定する可能性がある。BM-SCは、登録情報および/またはその他の情報などのUEから受信された情報を使用する可能性がある。
図17Bのステップ15において、BM-SCは、MBMSユーザサービスを消費するUEにMBMSユーザサービスの終了について知らせる。ステップ16において、UEは、MBMSユーザサービスを離れる。ステップ17において、UEは、そのUEがMBMSユーザサービスを離れたことをBM-SCに知らせる。ステップ18において、UEは、(たとえば、コンテンツサーバと直接通信することによって、またはBM-SCを要求のためのプロキシとして使用することによって)ユニキャストを通じた潜在的MBMSユーザサービスのデータを再び要求し始める。ステップ19において、BM-SCは、MBMSユーザサービスを終了するが、潜在的MBMSユーザサービスを提供し続ける。図17Aおよび図17Bの例においては、MooD WIが、ステップ2、3、8、13、17、および/またはその他の動作などの様々な動作のための基準を定める新しいシグナリングを定義する可能性がある。
記載された例のうちの1つまたは複数において、BM-SCは、同じサービスまたはコンテンツのユニキャスト配信の代わりに、または同じサービスまたはコンテンツのユニキャスト配信に加えて、需要に基づくeMBMSサービスをプロビジョニングすることができる可能性がある。一部の例において、BM-SCは、ユニキャストサービスをMBMSユーザサービスに動的に移行させると、ユニキャストベアラのみを介して、MBMSベアラを介して、または両方のベアラの種類を介してサービス配信を提供する可能性がある。一部の例において、BM-SCは、非MBMSユニキャストサービスとMBMSユーザサービスとの間で切り替えられるのにふさわしい各サービスの指示をUEにスケーラブルな方法で提供することができる可能性がある。既存のMBMSユーザサービスのブロードキャスト配信への低アタッチメントレート/量の認識を得ると、BM-SCは、一部の例において、MBMSユーザサービスを非アクティブ化する可能性がある。既存のMBMSユーザサービスのブロードキャスト配信への低アタッチメントレート/量の認識を得ると、BM-SCは、一部の例において、MBMSユーザサービスをユニキャストのみの配信モードに制限する可能性がある。
記載された例のうちの1つまたは複数は、UEに利用可能なサービスおよび配信モードを知らせるために必要とされる必要なシグナリングを提供し得る。記載された例のうちの1つまたは複数は、潜在的MBMSユーザサービスの数と、ユニキャストモードおよびブロードキャストモードで動作するときに含まれるUEとの点でスケーラブルな解決策を提供し得る。記載された例のうちの1つまたは複数は、アップリンクおよび/またはダウンリンクのリソースの効率的な使用を提供し得る。記載された例のうちの1つまたは複数は、関連する規制およびプライバシーの考慮事項を考慮に入れ得る。記載された例のうちの1つまたは複数は、強化されたMBMS動作などのRel-12中のその他の作業項目で開発された特徴を含む既存のMBMSの特徴を可能な限り再利用し得る。記載された例のうちの1つまたは複数は、追加的にまたは代替的に、よくあるウェブテクノロジーおよびHTTPの特徴などのその他の既存の特徴を再利用し得る。
記載された例のうちの1つまたは複数は、潜在的MBMSユーザサービスから実際のMBMSユーザサービスにマイグレーションするとき、ユーザへの影響を最小化し得る。記載された例のうちの1つまたは複数は、ブロードキャストのみのモードならびに/またはブロードキャストおよびユニキャストモードでMBMSユーザサービスを実行する能力を提供し得る。記載された例のうちの1つまたは複数は、通常のHTTPサーバを通じて修復を行う関連配信手順によって増強され得るMBMSを介したDASHおよびMBMSダウンロード配信サービスのために有効化され得る。記載された例のうちの1つまたは複数は、(たとえば、MBMSユーザサービスのフォーマットにコード変換することなく)サービスを実際のMBMSユーザサービスに移動させるときに潜在的MBMSユーザサービスのフォーマットを維持することを可能にし得る。記載された例のうちの1つまたは複数は、BMSCおよびその他のネットワーク構成要素に関して最小の処理オーバーヘッドで動作し得る。記載された例のうちの1つまたは複数は、オーバーヘッド、ネットワーク使用、およびUEのバッテリー消費の点で効率的であり得る。
図18は、消費の報告のためのエンティティの一例を示す概念図である。図18の例は、サービス(たとえば、ユニキャスト、ブロードキャスト、またはマルチキャストサービス)の消費を判定するかまたは判定することを支援し、それによって、サービスがユニキャスト、ブロードキャスト、および/またはマルチキャスト送信を介してより効率的に提供されるかどうかをより正確に判定するために使用可能な1つのエンティティを表す可能性がある。図18の例は、MBMSユーザサービスの継続している需要のより正確な知識をMBMSサービス事業者(たとえば、サービスプロバイダネットワーク)に提供する可能性があり、したがって、事業者は、MBMSユーザサービスを終了すべきか、またはサービスのユニキャストのみの配信に一時的に切り替わるべきかをよりうまく判定することができる可能性がある。
一部の例においては、MBMSユーザサービスを消費するUEの数が特定のエリア内で(たとえば、サービスプロバイダネットワークによってあらかじめ構成された)特定の閾値未満であるときにネットワークがMBMS送信を無効化することが、有益である可能性がある。MBMSユーザサービスを終了すべきであるときを判定するための様々な例示的な方法が、使用され得る。図18の例において、MBMSユーザサービスを終了すべきであるときを判定することは、MBMSサービスの消費の報告方法に少なくとも部分的に基づく可能性がある。そのような方法は、UEによるMBMSユーザサービス消費報告の要件をシグナリングするための関連配信手順(ADP)の記述への拡張として定義される可能性があり、または(たとえば、新しい報告の種類を規定することによる)既存の受信報告への拡張として定義される可能性がある。
図18は、MBMSサービス消費報告パラメータ602を含む関連手順記述(APD: Associated Procedure Description)600の1つの例示的な拡張を含む。APD 600の拡張によって、BM-SCは、sampleReportPercentage属性604においてMBMSユーザサービス報告を実行するためのMBMS受信機の百分率のサブセットを指定し得る。BM-SCは、UEがreportInterval属性606においてUEが報告すべき頻度を指定し得る。また、BM-SCは、reportFlag属性608において、UEがUSDのMBMSユーザサービスの受信を開始または停止するときに報告を行うことを要求されるか否かを指定し得る。
sampleReportPercentage属性604がMBMSユーザサービスに関して提供され、値が100未満である場合、UEは、0から100までの範囲内で一様に分布する乱数を生成し得る。UEは、生成された乱数がsampleReportPercentage属性604の値よりも小さい値であるとき、周期的に(たとえば、reportInterval属性606において指定された報告頻度に従って)MBMSユーザサービス報告を送信し得る。
reportFlag属性608が「真」に設定される場合、UEは、MBMSユーザサービスの受信をUEが開始するとき(たとえば、UEがMBMSのカバレッジ内に移動するときを含む)または停止するとき(たとえば、UEがeMBMSのカバレッジの外に移動するとき)にMBMSユーザサービス報告を送信する可能性がある。一部の例においては、(たとえば、MBMSサービスアプリケーションのオンおよびオフを連続して高速に行うユーザの不作法な行為が原因であるか、またはUEがMBMSのカバレッジの境界近くにあり、カバレッジを得ることと失うこととを繰り返すことが原因である)報告の過度な変動を避けることなどのために、UEは、消費の報告を減らすためのヒステリシスに基づくアルゴリズムを実装する可能性がある。
UEは、MBMSユーザサービス報告を送信するとき、そのUEの位置をBM-SCに示す可能性がある(たとえば、MooD構成に基づくサービスエリア識別情報(SAI: service area identity)、セルグローバル識別情報(CGI: Cell Global Identity)、または進化型セルグローバル識別情報(ECGI: Evolved Cell Global Identity))。
MBMSユーザサービスを終了すべきであるときを判定するためのその他の例示的な方法においては、ネットワークのデバイスが、あらかじめ構成されたタイマーが切れると送信を無効化する可能性がある。タイマーに基づくメカニズムは、MBMS送信をオンにする以前の決定が特定のイベントによって開始されたときに使用するのに好適である可能性がある。別の例において、ネットワークのデバイスは、MCE集計手順を用いてMBMSユーザサービスを終了すべきであるときを判定し得る。たとえば、MCEは、MBMSユーザサービスに関心のあるUEの数が特定の閾値(たとえば、100 UE、1000 UEなど)未満になることを検出した後、BM-SCに通知を送信する可能性がある。しかし、一部の例において、MCEの集計は、アイドル状態のMBMSユーザサービスを受信しているUEを含まない可能性がある。さらに、MCEの集計は、3GPP RAN2の範囲内にある。MCEの集計に関する改善された解決策は、RRC_CONNECTED状態のUEに加えてRRC_IDLE状態のそれらのUEを含むように現在のRANの集計を強化する可能性がある。追加的にまたは代替的に、改善されたMCEの集計は、UEが所与のMBMSユーザサービスの消費を開始または停止するときにUEが自律的に報告することを可能にし得る。改善されたMCEの集計は、UEが所与のMBMSユーザサービスの消費を周期的に報告することを可能にし得る。最後に、改善されたMCEの集計は、ネットワークのBM-SCへのRANの集計の測定の送信を可能にし得る。
MBMSユーザサービスを終了すべきであるときを判定する別の例として、MBMSユーザサービスの登録/登録解除に基づくBM-SCに基づく集計手順が使用される可能性がある。一部の例において、MBMSユーザサービスの登録のセマンティックスは、エンドユーザの消費の意図を指す可能性があり、UEがeMBMSユーザサービスを実際に消費している(たとえば、eMBMSユーザサービスの受信を実行している)かどうかを示さない可能性がある。
図18の例においてはconsumptionReportingパラメータ602として示されているが、本開示の技術は、一部の例において、APD 600のreportProceduresTypeの下にMBMSサービス消費報告パラメータを含めることによってADP 600を拡張する可能性がある。一部の例においては、一部のパラメータ(たとえば、samplePercentage)が、MBMSサービス消費報告のために再利用可能である可能性がある。
図19は、消費の報告のための例示的な動作を示す概念図である。図19の例示的な動作は、MBMSユーザサービス消費報告を提供するためのMooD対応UEとBM-SCとの間の1つのあり得る呼び出しフローを表す可能性がある。
最初に、BM-SCが、(たとえば、ADPの記述への拡張として)Mood対応UEに消費報告パラメータを送信する可能性がある。図19の例において、消費報告パラメータは、報告の間隔、サンプルの報告の百分率、および報告フラグを含み得る。様々なその他のパラメータが、その他の例において含まれる可能性がある。図19の例のステップ1においては、UEが、MBMSユーザサービスを介してコンテンツ(たとえば、サービスX)を消費し始める可能性がある。たとえば、UEは、本明細書に記載の技術に従ってサービスXのユニキャスト配信からMBMSユーザサービスに切り替わる可能性がある。別の例として、UEは、サービスXに関するMBMSカバーエリアに入る可能性がある。ステップ1において、UEは、サービスXに対応する報告間隔タイマーを開始し得る。
図19の例のステップ2において、UEは、MBMSユーザサービス報告をBM-SCに送信する可能性がある。MBMSユーザサービス報告は、UEが(たとえば、MBMSユーザサービス報告の種類が「開始」タイプであることを示すことによる)MBMSユーザサービスを介してサービスXを消費し始めたという指示、TMGI、およびUEの位置を含む可能性がある。図19の例のステップ3において、UEは、MBMSユーザサービスを介してサービスXを消費しながら報告間隔タイマーのカウントダウンを続ける可能性がある。ステップ4において、UEは、サービスXに対応する報告間隔タイマーが切れたことを検出し得る。結果として、ステップ5において、UEは、報告が暫定的更新(interim update)である(たとえば、報告が「暫定的更新」タイプである)という指示、TMGI、およびUEの位置を含む別のMBMSユーザサービス報告を送信し得る。MBMSユーザサービス報告を送信した後、UEは、ステップ6において、サービスXに対応する報告間隔タイマーをリセットし得る。ステップ7において、UEは、報告間隔タイマーを再びカウントダウンし得る。
UEがサービスXを消費し続けているとき、ステップ4から7までは、何度か繰り返す可能性がある。図19のステップ8において、UEは、サービスXの消費を停止し得る。たとえば、UEは、サービスXを受信していたアプリケーションの実行を止める可能性があり、またはサービスXに関するMBMSカバーエリアから外に移動する可能性がある。図19のステップ9において、UEは、(たとえば、報告が「停止」タイプであることを示すことによる)UEがMBMSユーザサービスを介してサービスXを消費することを停止したという指示、ならびにTMGIおよびUEの位置を含む別のMBMSユーザサービス報告をBM-SCに送信し得る。MBMSユーザサービス報告をBM-SCに送信することによって、UEは、ユニキャスト、ブロードキャスト、および/またはマルチキャスト配信モードを介してコンテンツを提供すべきかどうかを判定するためのより正確な情報をBM-SCに提供し得る。
図20Aおよび図20Bは、選択的に1つまたは複数のサービスを用いてストリーミングメディアデータを取得するための例示的な動作を示す概念図である。図20Aおよび図20Bの例示的な動作が、以下で、図4のシステム200の通常の文脈の中で説明されるが、様々な例においてはその他のシステムによって実行される可能性がある。図20Aおよび図20Bの例において、ストリーミング/ファイルダウンロードクライアント210は、DASHクライアントである可能性があり、MBMSユニット212は、MBMSクライアント(たとえば、MBMSミドルウェア)およびローカルHTTPサーバである可能性があり、プロキシユニット213は、ローカルHTTPプロキシである可能性がある。さらに、図20Aおよび図20Bの例において、BM-SC 206およびリダイレクト/プロキシユニット205は、プロキシサーバ機能ならびにサービス告知およびセッション&送信機能を含む単一のBM-SCユニットの一部として表される可能性がある。Appサーバ202は、DASHセグメントを提供することができるコンテンツサーバおよびMPDを提供するコンテンツサーバである可能性がある。
本開示の1つまたは複数の技術によれば、アプリケーション208は、ストリーミング/ファイルダウンロードクライアント210を用いて(たとえば、DASHプロトコルを用いて)メディアデータを取得し得る。たとえば、アプリケーション208は、ストリーミング/ファイルダウンロードクライアント210にマニフェストファイル(たとえば、MPD)の位置を示すURLを送信する可能性があり、そしてさらに、マニフェストファイルが、第1のサービス(たとえば、ユニキャスト)によってメディアデータを取り出すための1つまたは複数のリソースの位置を定義する。ストリーミング/ファイルダウンロードクライアント210は、(たとえば、プロキシユニット213を通じて)アプリケーションサーバ202にHTTP GET要求を送信することによってMPDを取得する可能性がある。プロキシユニット213は、IPスタック214、モデム216、P-GW 204、およびリダイレクト/プロキシユニット205を介してアプリケーションサーバ202までHTTP GET要求が通過することを可能にし得る。図20Aの例において、プロキシユニット213は、さらに、(たとえば、APIを呼び出すことによって)MPDのURLの指示をMBMSユニット212に送信し得る。
アプリケーションサーバ202は、HTTP GET要求を受信し、それに応じて200タイプのHTTP OKメッセージを送信する可能性がある。OKメッセージは、修正なしにBM-SCプロキシサーバおよびローカルHTTPプロキシを通過する可能性がある。OKメッセージは、ユニキャストのMPDを含む可能性がある。ストリーミング/ファイルダウンロードクライアント210は、MPDを受信し、取得するメディアデータのリプレゼンテーション、期間、およびセグメント(たとえば、期間3、リプレゼンテーション256、セグメント1)を決定し得る。MPDに少なくとも部分的に基づいて、ストリーミング/ファイルダウンロードクライアント210は、決定されたセグメントに関するURLを探し、決定されたURL(たとえば、「http://example.com/per-3/rep-256/seg-1.3gp」)を用いてHTTP GET要求を送信する可能性がある。HTTP GET要求は、修正なしにローカルHTTPプロキシおよびBM-SCプロキシサーバ機能を通過する可能性がある。
アプリケーションサーバ202は、GET要求を受信する可能性があり、それに応答して、要求されたメディアデータ(たとえば、「seg1」)を含む200タイプのHTTP OKメッセージを送信する可能性がある。HTTP OKメッセージは、修正なしにBM-SCプロキシサーバ機能およびローカルHTTPプロキシを通過する可能性がある。このようにして、ストリーミング/ファイルダウンロードクライアント210は、ユニキャストサービスを用いてアプリケーションサーバ202からストリーミングメディアデータを取得し得る。
ネットワーク側で、BM-SC 206のプロキシサーバ機能は、ユニキャストサービスの高い需要を検出し得る。それに応じて、BM-SC 206は、コンテンツに関するMBMS(たとえば、ブロードキャスト)サービスを有効化し得る。BM-SC 206は、アプリケーションサーバ202からのコンテンツに関するユニキャストのMPDを要求し、受信し得る。そして、BM-SC 206は、共通のMPDおよび/またはその他のパラメータを含むユーザサービス記述(USD)をブロードキャストし得る。コンテンツの後続のMBMS配信全体を通じて、BM-SC 206は、アプリケーションサーバ202からのコンテンツを要求し、受信し続ける可能性があるMBMSユーザサービスを有効化した後、BM-SC 206(および/またはリダイレクト/プロキシユニット205)は、プロキシサーバ機能を利用してコンテンツに関してUEをリダイレクトし得る。
その後、ストリーミング/ファイルダウンロードクライアント210は、元のMPDからの対応するURL(たとえば、「http://example.com/per-3/rep-256/seg-M.3gp」)を含む、セグメントMの要求などのメディアデータのHTTP GET要求を送信し続ける可能性がある。GET要求は、修正なしにローカルHTTPプロキシを通過する可能性がある。しかし、BM-SC 206のプロキシサーバ機能(たとえば、リダイレクト/プロキシユニット205)がセグメントMのGET要求を受信するとき、BM-SC 206は、図20Aの例において、HTTPリダイレクトメッセージをUEに送信し得る。リダイレクトメッセージは、MBMSユニット212に登録するための、ローカルプロキシユニット213に示すリダイレクトURLおよび/または応答ヘッダを含む拡張ヘッダを含み得る。リダイレクトURLは、同じ要求されたリソースに関する異なる位置を表す可能性がある。たとえば、元の要求のURLがhttp://example.com/per-x/rep-y/seg-z.3gpである場合、リダイレクトURLが、http://example.com/redirect/per-x/rep-y/seg-z.3gpである可能性がある。3GPPで定義されたHTTP拡張ヘッダは、「Trigger-MBMS」と名付けられ、値「Get-USD」を有する可能性があり、その場合、UEによるコンテンツ要求に対するHTTP応答メッセージは、応答ヘッダ「Trigger-MBMS: Get USD」を添えられる可能性がある。
ローカルプロキシユニット213は、HTTPリダイレクトを受信し、示されたメディアデータ(たとえば、セグメントM)のHTTP GET要求をリダイレクトにおいて指定されたURLに送信し得る。BM-SC 206のプロキシサーバ機能は、セグメントを取り出すためにアプリケーションサーバ202にHTTP GET要求を導き得る。一部の例において、BM-SC 206のプロキシサーバ機能は、新しいURLに送信されたHTTP GET要求を受信し、修正されていない要求をアプリケーションサーバ202に転送し得る。一部の例において、BM-SC 206のプロキシサーバ機能は、新しいURLに送信されたHTTP GET要求を受信し、要求を元のURLに導くように要求を修正し得る。つまり、一部の例において、BM-SC 206のプロキシサーバ機能は、(たとえば、アプリケーションサーバ202がリダイレクトの位置に導かれた要求を扱うように構成されるとき)要求がリダイレクトURLまで通過することを可能にし得る一方、その他の例においては、BM-SC 206のプロキシサーバ機能は、(たとえば、アプリケーションサーバ202がリダイレクトの位置に導かれた要求を扱うように構成される必要がないように)通常のURLに要求を転送し得る。アプリケーションサーバ202は、HTTP GET要求を受信し、要求されたセグメントを含む200タイプのHTTP OKメッセージを送信し得る。このようにして、ローカルHTTPプロキシは、UEがMBMSサービスを介したコンテンツの受信に移行する間にDASHクライアントによって要求されたコンテンツが受信されることを保証し得る。
HTTPリダイレクトを受信することに応じて、ローカルプロキシユニット213は、MBMSクライアント/ローカルHTTPサーバ212と(たとえば、APIを介して)通信してMBMSクライアントをトリガ(たとえば、MBMSサービスを介したコンテンツの受信を開始)し得る。
ここで図20Bに目を向けると、UEは、HTTP GETメッセージを送信し、HTTPリダイレクトを受信し、対応するHTTP GETメッセージをリダイレクトにおいて指定されたURLに送信し、要求されたコンテンツを受信することによってMBMSセッションが設定される間にコンテンツを取得し続ける可能性がある。ローカルプロキシユニット213からトリガを受信した後、MBMSクライアント/ローカルHTTPサーバ212は、(たとえば、BM-SC 206から受信されたHTTPリダイレクトにおいて指定された)更新されたUSDを獲得し得る。USDは、ブロードキャストまたはユニキャストを介して獲得される可能性がある。USDを獲得した後、MBMSクライアント/ローカルHTTPサーバ212は、サービス(たとえば、サービスX)に関する新しいMPDのURLがユニキャストサービスに関して受信されたMPDのURLと一致すると判定する可能性がある。結果として、MBMSクライアント/ローカルHTTPサーバ212は、サービスXに関するFLUTEセッションをアクティブ化し得る。
BM-SC 206は、FLUTEを介してサービスXに関するセグメントおよび/またはMPDを送信し得る。MBMSクライアント/ローカルHTTPサーバ212は、十分なコンテンツを受信し、MBMSユーザサービスが設定されると判定する可能性がある。USDがユニキャストのMPDに含まれる同じリプレゼンテーション(たとえば、rep-256)が統合されたMPDにやはり含まれることを示し、リプレゼンテーションがブロードキャスト配信を介して利用可能である場合、MBMSクライアント/ローカルHTTPサーバ212は、(たとえば、APIを用いて)ローカルプロキシユニット213と通信して、サービスXのコンテンツの要求をMBMSクライアント/ローカルHTTPサーバ212にリダイレクトするようにローカルプロキシユニット213を構成し得る。つまり、MBMSクライアント/ローカルHTTPサーバ212は、ローカルプロキシユニット213がサービスXのMPDの要求をMBMSクライアント/ローカルHTTPサーバ212のMPDにリダイレクトすることを引き起こす可能性があり、ローカルプロキシユニット213がサービスXのセグメントの要求をMBMSクライアント/ローカルHTTPサーバ212のサービスXのセグメントにリダイレクトすることを引き起こす可能性がある。
その後、ストリーミングクライアント210が特定のセグメント(たとえば、セグメントN)のHTTP GET要求を送信するとき、ローカルプロキシユニット213は、要求をMBMSクライアント/ローカルHTTPサーバ212にリダイレクトし得る。MBMSクライアント/ローカルHTTPサーバ212は、要求を受信し、セグメントNを200タイプのHTTP OKメッセージの一部として送信し得る。
図21は、MooD構成のための管理オブジェクトの一例を示す概念図である。一部の例において、図21の管理オブジェクトは、UEに送信されたHTTPリダイレクトのヘッダに含まれ、それによって、ストリーミングデータがブロードキャストおよび/またはマルチキャストサービスを介して利用可能であることをUEに示す可能性がある。一部の例において、OMA-DMが、MooD構成情報を指定するために使用される可能性がある。そのようなDM構成オブジェクトがUEに存在する場合、UEは、そのUEがMBMSオフローディングをサポートすることを選択するときにはいつもそのDM構成オブジェクトを使用し得る。OMA DM管理オブジェクトは、追加的にまたは代替的に、HTTPまたはRTPを介してユニキャストネットワーク上でアクセスされる任意の種類のふさわしいコンテンツに関するオフローディングを構成するために使用され得る。
一部の例においては、管理オブジェクト識別子が、urn:oma:mo:ext-3gpp-mbmsmood:1.0に設定される可能性がある。MOは、(Open Mobile Alliance、「OMA Device Management Protocol」、Approved Version 1.2.1、2008年6月によって規定されている)OMAデバイス管理プロトコル仕様、バージョン1.2以降と適合し、Open Mobile Alliance、「Enabler Release Definition for OMA Device Management」、Approved Version 1.2.1、2008年6月に記載されているOMA DMデバイス記述フレームワークを用いて定義される。
図21の例は、MBMSミドルウェアクライアントが記載された特徴をサポートする場合、3GPP_MBMS MooD MOの下に含まれるノードおよび葉オブジェクトを示す。
ノード700(たとえば、ノード: /<X>)は、図21の例において、MBMS MooD管理オブジェクトの一意オブジェクトIDを指定する可能性がある。この内部ノードは、単一のオブジェクトのパラメータをまとめてグループ化する可能性がある。
- 発生: ZeroOrOne
- フォーマット: node
- 最小アクセスタイプ: Get
- 発生: ZeroOrOne
- フォーマット: node
- 最小アクセスタイプ: Get
以降の内部ノードは、UEが「MBMS MooD管理オブジェクト」をサポートする場合に含まれる可能性がある。
図21の例において、ノード702(たとえば、/<X>/Enabled)は、MooDがBM-SCによってサポートされるかどうかを示す可能性がある。
- 発生: One
- フォーマット: bool
- 最小アクセスタイプ: Get
- 発生: One
- フォーマット: bool
- 最小アクセスタイプ: Get
ノード704(たとえば、/<X>/ProxyServer)は、図21の例において、UEがMBMSを介して潜在的に受信することを選択する、UEがすべてのユニキャスト要求に関して使用し得る1つまたは複数のプロキシサーバを表す可能性がある。
- 発生: One
- フォーマット: node
- アクセスタイプ: Get、Replace
- 値: N/A
- 発生: One
- フォーマット: node
- アクセスタイプ: Get、Replace
- 値: N/A
図21の例において、ノード706(たとえば、/<X>/ProxyServer/<X>)は、プロキシサーバの選択のためのコンテンツ制限識別子に関連するアドレスとしてのProxyServer情報の1つまたは複数のインスタンスのためのプレースホルダーとして働く可能性がある。2つ以上のプロキシサーバがコンテンツ制限の条件を満たす場合、UEは、プロキシサーバのうちの1つを無作為に選択する可能性がある。
- 発生: OneOrMore
- フォーマット: node
- アクセスタイプ: Get、Replace
- 発生: OneOrMore
- フォーマット: node
- アクセスタイプ: Get、Replace
ノード708(たとえば、/<X>/ProxyServer/<X>/Address)は、図21の例において、完全修飾ドメイン名(FQDN)の形式でProxyServerの1つまたは複数のアドレスを示す可能性がある。それぞれのProxyServerは、1組のコンテンツ制限に関連付けられる可能性があり、その1組のコンテンツ制限のうちの少なくとも1つが、UEがMBMSを介して潜在的に受信することを選択するリソースへのすべてのそのUEのユニキャスト要求のためにそのUEがその/それらのプロキシサーバを使用するために満たされなければならない。
- 発生: OneOrMore
- フォーマット: chr
- アクセスタイプ: Get、Replace
- 値: FQDN(1つまたは複数)
- 発生: OneOrMore
- フォーマット: chr
- アクセスタイプ: Get、Replace
- 値: FQDN(1つまたは複数)
ノード710(たとえば、/<X>/ProxyServer/<X>/ContentRestriction)は、図21の例において、要求されたコンテンツがユニキャストアクセスからMBMSユーザサービスへの変換にふさわしいかどうかを判定し、ふさわしい場合に使用すべき対応するプロキシサーバを決定するためにUEによって発せられたリソース要求のHTTPまたはRTSP URLと付き合わせるための1つまたは複数のドメイン名を含む葉ノードである可能性がある。この値と要求されたリソースのURLとの間の一致は、要求されたリソースがMBMS配信に切り替えられ得ることを示す可能性があり、関連するプロキシサーバが、そのリソースのユニキャストアクセスのためにUEによって使用される。
- 発生: OneOrMore
- フォーマット: chr
- アクセスタイプ: Get、Replace
- 値: Berners-Leeら、「Uniform Resource Identifier (URI): Generic Syntax」、IETF、RFC 3986、2005年1月において定義されたURIスキームと、Mockapetris、「Domain Names - Implementation and Specification」、IETF、RFC 1035、1987年11月において定義されたドメイン名との連結
- 発生: OneOrMore
- フォーマット: chr
- アクセスタイプ: Get、Replace
- 値: Berners-Leeら、「Uniform Resource Identifier (URI): Generic Syntax」、IETF、RFC 3986、2005年1月において定義されたURIスキームと、Mockapetris、「Domain Names - Implementation and Specification」、IETF、RFC 1035、1987年11月において定義されたドメイン名との連結
図21の例において、ノード712(たとえば、/<X>/ProxyServer/<X>/Ext)は、プロキシサーバのUEの選択に関連して、ベンダーに固有の(アプリケーションベンダー、デバイスベンダーなどの)情報が置かれる可能性がある内部ノードである可能性がある。一部の例においては、ベンダーの拡張が、Extノードの下のベンダーに固有の名前によって特定される可能性がある。特定されたベンダーの下の木構造は、定義されず、したがって、1つまたは複数の標準化されていない部分木を含む可能性がある。
- 発生: ZeroOrOne
- フォーマット: node
- 最小アクセスタイプ: Get、Replace
- 発生: ZeroOrOne
- フォーマット: node
- 最小アクセスタイプ: Get、Replace
ノード714(たとえば、/<X>/USD)は、図21の例において、MBMSユーザサービス発見/告知情報の定義の開始点を表す可能性がある。
- 発生: ZeroOrOne
- フォーマット: node
- 最小アクセスタイプ: Get、Replace
- 発生: ZeroOrOne
- フォーマット: node
- 最小アクセスタイプ: Get、Replace
図21の例において、ノード716(たとえば、/<X>/USD/URL)は、UEがユニキャストチャネルを用いてフェッチし得る、需要に基づくMBMSユーザサービスに関するすべての関連するメタデータのフラグメントをカプセル化する集約されたサービス告知ドキュメントへのURLを提供する可能性がある。ノード716は、MBMS受信を切り替えるためにネットワークのデバイスがUEをリダイレクトするときにネットワークによって使用される可能性もある。リダイレクトメッセージがサービス告知情報への代替的なリダイレクトリンクを提供する場合、そのリダイレクトメッセージは、MOによって提供されるURLよりも優先される。
- 発生: ZeroOrOne
- フォーマット: chr
- 最小アクセスタイプ: Get
- 値: <HTTP(S) URL>
- 発生: ZeroOrOne
- フォーマット: chr
- 最小アクセスタイプ: Get
- 値: <HTTP(S) URL>
ノード718(たとえば、/<X> USD/Ext)は、図21の例において、ベンダーに固有の情報が置かれ得る内部ノードである可能性がある。一部の例においては、ベンダーの拡張が、Extノードの下のベンダーに固有の名前によって特定される。特定されたベンダーの下の木構造は、定義されない可能性があり、したがって、1つまたは複数の標準化されていない部分木を含む可能性がある。
- 発生: ZeroOrOne
- フォーマット: node
- 最小アクセスタイプ: Get
- 発生: ZeroOrOne
- フォーマット: node
- 最小アクセスタイプ: Get
図21の例において、ノード720(たとえば、/<X>/LocationType)は、ユニキャストコンテンツ要求においてUEが報告するための位置の種類を提供する可能性がある。以降のエントリ、すなわち、(たとえば、セルグローバル識別情報(CGI)またはE-UTRANセルグローバル識別情報(ECGI: E-UTRAN Cell Global Identification)の形式の)セルIDのうちの1つが、存在する可能性がある。CGIおよびECGIは、3GPP技術仕様23.003、「Numbering, addressing and identification, (Release 12)」、v12.2.0、2014年3月において定義されている。存在するとき、UEは、そのUEがMooDプロキシサーバに送信する要求と一緒にMooDヘッダフィールドの一部としてそのUEの位置を送信し得る。
- 発生: ZeroOrOne
- フォーマット: chr
- 最小アクセスタイプ: Get
- 値:以降の位置情報の種類、すなわち、CGI、ECGIのうちの丁度1つ
- 発生: ZeroOrOne
- フォーマット: chr
- 最小アクセスタイプ: Get
- 値:以降の位置情報の種類、すなわち、CGI、ECGIのうちの丁度1つ
ノード722(たとえば、/<X>/Ext)は、図21の例において、ベンダーに固有の情報が置かれ得る内部ノードである可能性がある。一部の例においては、ベンダーの拡張が、Extノードの下のベンダーに固有の名前によって特定される可能性がある。特定されたベンダーの下の木構造は、定義されない可能性があり、したがって、1つまたは複数の標準化されていない部分木を含む可能性がある。
- 発生: ZeroOrOne
- フォーマット: node
- 最小アクセスタイプ: Get
- 発生: ZeroOrOne
- フォーマット: node
- 最小アクセスタイプ: Get
1つまたは複数の例において、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、コンピュータ可読媒体上の1つまたは複数の命令またはコードとして記憶または送信され、ハードウェアに基づく処理ユニットによって実行され得る。コンピュータ可読媒体は、データストレージ媒体などの有形の媒体に対応するコンピュータ可読ストレージ媒体、またはたとえば通信プロトコルによるある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体を含む可能性がある。このようにして、概して、コンピュータ可読媒体は、(1)非一時的である有形のコンピュータ可読ストレージ媒体または(2)信号もしくは搬送波などの通信媒体に対応する可能性がある。データストレージ媒体は、本開示において説明された技術の実装のための命令、コード、および/またはデータ構造を取り出すために1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体である可能性がある。コンピュータプログラム製品は、コンピュータ可読媒体を含む可能性がある。
限定ではなく例として、そのようなコンピュータ可読ストレージ媒体は、RAM、ROM、EEPROM、CD-ROMもしくはその他の光ディスクストレージ、磁気ディスクストレージもしくはその他の磁気ストレージデバイス、フラッシュメモリ、または命令もしくはデータ構造の形態で所望のプログラムコードを記憶するために使用可能であり、コンピュータによってアクセス可能である任意のその他の媒体を含み得る。また、当然、任意の接続がコンピュータ可読媒体と呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者線(DSL)、または赤外線、ラジオ波、およびマイクロ波などのワイヤレステクノロジーを用いてウェブサイト、サーバ、またはその他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、ラジオ波、およびマイクロ波などのワイヤレステクノロジーは、媒体の定義に含まれる。しかし、コンピュータ可読ストレージ媒体およびデータストレージ媒体は、接続、搬送波、信号、またはその他の一時的媒体を含まず、その代わりに、非一時的な有形のストレージ媒体を対象とすることを理解されたい。本明細書において使用されるとき、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD: compact disc)、レーザディスク(laser disc)、光ディスク(optical disc)、デジタルバーサタイルディスク(DVD: digital versatile disc)、フロッピー（登録商標）ディスク(floppy disk)、およびブルーレイディスク(Blu-ray（登録商標） disc)を含み、ディスク(disk)が、通常、磁気的にデータを再生する一方、ディスク(disc)は、レーザを用いて光学的にデータを再生する。上記のものの組合せも、コンピュータ可読媒体の範囲に含まれるべきである。
命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルロジックアレイ(FPGA)、またはその他の等価な集積もしくはディスクリート論理回路などの1つまたは複数のプロセッサによって実行され得る。したがって、「プロセッサ」という用語は、本明細書において使用されるとき、上述の構造または本明細書において説明された技術の実装に好適な任意のその他の構造のいずれかを指す可能性がある。加えて、一部の態様において、本明細書において説明された機能は、符号化および復号のために構成された専用のハードウェアおよび/もしくはソフトウェアモジュール内に設けられるか、または組み合わされたコーデックに組み込まれる可能性がある。また、技術は、1つまたは複数の回路または論理要素においてすべて実装される可能性がある。
本開示の技術は、ワイヤレスハンドセット、集積回路(IC)、または1組のIC(たとえば、チップセット)を含む多種多様なデバイスまたは装置において実装される可能性がある。様々な構成要素、モジュール、またはユニットが、開示された技術を実行するように構成されたデバイスの機能の態様を強調するために本開示において説明されているが、異なるハードウェアユニットによる実現を必ずしも必要としない。むしろ、上述のように、様々なユニットが、コーデックハードウェアユニットにおいて組み合わされるか、または好適なソフトウェアおよび/もしくはファームウェアと連携した、上述の1つもしくは複数のプロセッサを含む相互運用性のあるハードウェアユニットの集合によって提供される可能性がある。
様々な例が説明された。これらのおよびその他の例は、添付の請求項の範囲に含まれる。
10 システム
20 コンテンツ準備デバイス
22 オーディオソース
24 ビデオソース
26 オーディオエンコーダ
28 ビデオエンコーダ
30 カプセル化ユニット
32 出力インターフェース
40 クライアントデバイス
44 ビデオ出力
46 オーディオデコーダ
48 ビデオデコーダ
50 カプセル化解除ユニット
52 取り出しユニット
54 ネットワークインターフェース
60 サーバデバイス
62 ストレージ媒体
64 マルチメディアコンテンツ
66 マニフェストファイル
68 リプレゼンテーション
70 要求処理ユニット
72 ネットワークインターフェース
74 ネットワーク
102 マルチメディアコンテンツ
104 MPD
110 リプレゼンテーション
112 ヘッダデータ
114 セグメント
120 リプレゼンテーション
122 ヘッダデータ
124 セグメント
150 システム
152 アプリケーションサーバ
154 P-GW
156 BM-SC
158 アプリケーション
160 ストリーミング/ファイルダウンロードクライアント
162 MBMSユニット
164 IPスタック
166 モデム
200 システム
202 アプリケーションサーバ
204 P-GW
205 リダイレクト/プロキシユニット
206 BM-SC
208 アプリケーション
210 ストリーミング/ファイルダウンロードクライアント
212 MBMSユニット
213 プロキシユニット
214 IPスタック
216 モデム
250 システム
252 アプリケーションサーバ
254 P-GW
255 メッセージサービス
256 BM-SC
258 アプリケーション
260 ストリーミング/ファイルダウンロードクライアント
262 MBMSユニット
263 メッセージクライアント
264 IPスタック
266 モデム
300 システム
302 アプリケーションサーバ
303 ノード
304 P-GW
305 MBMSゲートウェイ
306 BM-SC
308 アプリケーション
310 ストリーミング/ファイルダウンロードクライアント
312 MBMSユニット
314 IPスタック
316 モード
350 システム
352 アプリケーションサーバ
354 P-GW
356 BM-SC
358 アプリケーション
360 ストリーミング/ファイルダウンロードクライアント
362 MBMSユニット
364 IPスタック
366 モデム
400 ボディエンティティ
402 代替的なリソース
404 属性
406 MPDURIオブジェクト
500 公衆ネットワーク
502 セルラーデータネットワーク
504 パケット交換サービス(PSS)サーバ
506 パケットデータネットワークゲートウェイ
508 eNodeB
510 ブロードキャストおよびマルチキャストサービスセンター
512 MBMSゲートウェイ
515 ユーザ機器
520A オーバーザトップ(OTT)サービス
520B OTTサービス
520C OTTサービス
522A PSSサービス
522B PSSサービス
522C PSSサービス
524A MBMSサービス
524B MBMSサービス
524C MBMSサービス
524D MBMSサービス
532 PSSサービス
534 MBMSサービス
540 MBMSサービス
600 関連手順記述
602 MBMSサービス消費報告パラメータ
604 sampleReportPercentage属性
606 reportInterval属性
608 reportFlag属性
700 ノード
702 ノード
704 ノード
706 ノード
708 ノード
710 ノード
712 ノード
714 ノード
716 ノード
718 ノード
720 ノード
722 ノード
20 コンテンツ準備デバイス
22 オーディオソース
24 ビデオソース
26 オーディオエンコーダ
28 ビデオエンコーダ
30 カプセル化ユニット
32 出力インターフェース
40 クライアントデバイス
44 ビデオ出力
46 オーディオデコーダ
48 ビデオデコーダ
50 カプセル化解除ユニット
52 取り出しユニット
54 ネットワークインターフェース
60 サーバデバイス
62 ストレージ媒体
64 マルチメディアコンテンツ
66 マニフェストファイル
68 リプレゼンテーション
70 要求処理ユニット
72 ネットワークインターフェース
74 ネットワーク
102 マルチメディアコンテンツ
104 MPD
110 リプレゼンテーション
112 ヘッダデータ
114 セグメント
120 リプレゼンテーション
122 ヘッダデータ
124 セグメント
150 システム
152 アプリケーションサーバ
154 P-GW
156 BM-SC
158 アプリケーション
160 ストリーミング/ファイルダウンロードクライアント
162 MBMSユニット
164 IPスタック
166 モデム
200 システム
202 アプリケーションサーバ
204 P-GW
205 リダイレクト/プロキシユニット
206 BM-SC
208 アプリケーション
210 ストリーミング/ファイルダウンロードクライアント
212 MBMSユニット
213 プロキシユニット
214 IPスタック
216 モデム
250 システム
252 アプリケーションサーバ
254 P-GW
255 メッセージサービス
256 BM-SC
258 アプリケーション
260 ストリーミング/ファイルダウンロードクライアント
262 MBMSユニット
263 メッセージクライアント
264 IPスタック
266 モデム
300 システム
302 アプリケーションサーバ
303 ノード
304 P-GW
305 MBMSゲートウェイ
306 BM-SC
308 アプリケーション
310 ストリーミング/ファイルダウンロードクライアント
312 MBMSユニット
314 IPスタック
316 モード
350 システム
352 アプリケーションサーバ
354 P-GW
356 BM-SC
358 アプリケーション
360 ストリーミング/ファイルダウンロードクライアント
362 MBMSユニット
364 IPスタック
366 モデム
400 ボディエンティティ
402 代替的なリソース
404 属性
406 MPDURIオブジェクト
500 公衆ネットワーク
502 セルラーデータネットワーク
504 パケット交換サービス(PSS)サーバ
506 パケットデータネットワークゲートウェイ
508 eNodeB
510 ブロードキャストおよびマルチキャストサービスセンター
512 MBMSゲートウェイ
515 ユーザ機器
520A オーバーザトップ(OTT)サービス
520B OTTサービス
520C OTTサービス
522A PSSサービス
522B PSSサービス
522C PSSサービス
524A MBMSサービス
524B MBMSサービス
524C MBMSサービス
524D MBMSサービス
532 PSSサービス
534 MBMSサービス
540 MBMSサービス
600 関連手順記述
602 MBMSサービス消費報告パラメータ
604 sampleReportPercentage属性
606 reportInterval属性
608 reportFlag属性
700 ノード
702 ノード
704 ノード
706 ノード
708 ノード
710 ノード
712 ノード
714 ノード
716 ノード
718 ノード
720 ノード
722 ノード
Claims (13)
- ストリーミングデータを受信する方法であって、
クライアントデバイスによって、第1のサービスを介して少なくとも1つのリソースの位置に前記ストリーミングデータに関する識別子をマッピングするマニフェストファイルを取得するステップであって、前記第1のサービスがユニキャストサービスを含む、ステップと、
前記クライアントデバイスによって、前記第1のサービスに従って、前記第1のサービスを介して前記ストリーミングデータの少なくとも一部を取得するために前記少なくとも1つのリソースの位置に前記ストリーミングデータの少なくとも前記一部の要求であって、ハイパーテキスト転送プロトコル(HTTP)GET要求を含む前記ストリーミングデータの少なくとも前記一部の前記要求を送信するステップと、
前記クライアントデバイスのプロキシユニットによって、前記ストリーミングデータの少なくとも前記一部の前記要求に対する応答を受信するステップであって、前記要求に対する前記応答が、3xxタイプのHTTPリダイレクトメッセージまたは200タイプのHTTP OKメッセージのうちの少なくとも1つを含み、前記応答が、前記ストリーミングデータが前記第1のサービスを介して受信されるべきかまたは第2のサービスを介して受信されるべきかの指示をさらに含み、前記応答が、サービスプロバイダネットワークのブロードキャストマルチキャストサービスセンター(BM-SC)から送信され、前記BM-SCおよび前記少なくとも1つのリソースの位置と通信するプロキシユニットを介して中継され、前記3xxタイプのHTTPリダイレクトメッセージまたは前記200タイプのHTTP OKメッセージのうちの前記少なくとも1つが、前記指示を含む第3世代パートナーシッププロジェクト(3GPP)拡張ヘッダを含み、前記クライアントデバイスが、ブロードキャストまたはマルチキャストミドルウェアユニットをさらに含み、前記プロキシユニットが、前記ミドルウェアユニットと前記クライアントデバイスの少なくとも1つのプロセッサによって実行されるクライアントアプリケーションとの間の通信経路に配置される、ステップと、
前記プロキシユニットが、前記ストリーミングデータが前記第2のサービスを介して受信されるべきであることを前記指示が示すと判定するとき、
前記第2のサービスを介して前記ストリーミングデータを受信するために前記ミドルウェアユニットをアクティブ化するステップであって、前記第2のサービスが、ブロードキャストサービスまたはマルチキャストサービスのうちの少なくとも1つを含む、ステップと、
前記プロキシユニットによって、前記ミドルウェアユニットから前記ストリーミングデータを受信するステップとを含む、方法。 - 前記ミドルウェアユニットが、マルチメディアブロードキャストマルチキャストサービス(MBMS)または進化型MBMS(eMBMS)ミドルウェアユニットを含む請求項1に記載の方法。
- 前記要求に対する前記応答が、前記3xxタイプのHTTPリダイレクトメッセージを含み、前記3xxタイプのHTTPリダイレクトメッセージが、前記ストリーミングデータの少なくとも前記一部を取得すべきリダイレクトの位置を含むエンティティボディを含む請求項1に記載の方法。
- 前記ミドルウェアユニットから前記ストリーミングデータを受信するステップが、
前記プロキシユニットによって、前記ミドルウェアユニットから少なくとも1つの新しいリソースの位置を取得するステップであって、前記少なくとも1つの新しいリソースの位置が前記第2のサービスに基づく、ステップを含む請求項1に記載の方法。 - 前記少なくとも1つの新しいリソースの位置を取得するステップの後に、前記プロキシユニットによって、前記クライアントアプリケーションから、前記ストリーミングデータの少なくとも第2の一部のクライアントの要求を受信するステップであって、前記クライアントの要求が、前記少なくとも1つのリソースの位置に基づく、ステップと、
前記クライアントの要求において指定されたデータが前記少なくとも1つの新しいリソースの位置によって指定されたデータと一致するかどうかを判定するステップと、
前記クライアントの要求において指定された前記データが前記少なくとも1つの新しいリソースの位置によって指定された前記データと一致するときに、前記プロキシユニットによって、前記ミドルウェアユニットに、前記ストリーミングデータの少なくとも前記第2の一部のプロキシの要求を送信するステップであって、前記プロキシの要求が、前記少なくとも1つの新しいリソースの位置に基づく、ステップとをさらに含む請求項4に記載の方法。 - 前記少なくとも1つのリソースの位置がユニフォームリソースロケータ(URL)の第1の基底部分を含み、前記第1の基底部分が前記第1のサービスに対応し、前記少なくとも1つの新しいリソースの位置がURLの第2の基底部分を含み、前記第2の基底部分が前記第2のサービスに対応する請求項4に記載の方法。
- 前記第2のサービスが、少なくともブロードキャスト配信モードによって利用可能なサービスを含み、前記ミドルウェアユニットが、マルチメディアブロードキャストマルチキャストサービス(MBMS)または進化型MBMS(eMBMS)ミドルウェアユニットを含み、前記ミドルウェアユニットから前記ストリーミングデータを受信するステップが、
前記プロキシユニットによって、前記ミドルウェアユニットから前記ストリーミングデータを取り出すステップと、
前記プロキシユニットによって、前記クライアントアプリケーションに前記ストリーミングデータを送信するステップとを含む請求項1に記載の方法。 - 前記ミドルウェアユニットをアクティブ化するステップが、前記プロキシユニットによって前記ミドルウェアユニットをアクティブ化するステップを含む請求項1に記載の方法。
- 前記指示が、プッシュメカニズムによって送信されたメッセージを含む請求項1に記載の方法。
- 前記第1のサービスが、ユニキャスト配信モードによって利用可能なサービスを含む請求項1に記載の方法。
- ストリーミングデータを受信する方法であって、
クライアントデバイスによって、第2のサービスを介して前記ストリーミングデータを受信するステップと、
前記クライアントデバイスのプロキシユニットによって、前記ストリーミングデータが第1のサービスを介して受信されるべきかまたは前記第2のサービスを介して受信されるべきかの指示からなるメッセージを受信するステップであって、前記メッセージが、サービスプロバイダネットワークのブロードキャストマルチキャストサービスセンター(BM-SC)から送信され、前記BM-SCおよび前記少なくとも1つのリソースの位置と通信するプロキシユニットを介して中継され、前記メッセージが、3xxタイプのHTTPリダイレクトメッセージまたは200タイプのHTTP OKメッセージのうちの少なくとも1つを含み、前記3xxタイプのHTTPリダイレクトメッセージまたは前記200タイプのHTTP OKメッセージのうちの前記少なくとも1つが、前記指示を含む第3世代パートナーシッププロジェクト(3GPP)拡張ヘッダを含み、前記クライアントデバイスが、マルチメディアブロードキャストマルチキャストサービス(MBMS)または進化型MBMS(eMBMS)ミドルウェアユニットをさらに含み、前記プロキシユニットが、前記ミドルウェアユニットと前記クライアントデバイスの少なくとも1つのプロセッサによって実行されるクライアントアプリケーションとの間の通信経路に配置される、ステップと、
前記プロキシユニットが、前記ストリーミングデータが前記第1のサービスを介して受信されるべきであることを前記指示が示すと判定するとき、
前記ミドルウェアユニットを無効化するステップであって、前記ミドルウェアユニットが、前記第2のサービスを介して前記ストリーミングデータの少なくとも一部を受信済みであり、前記第2のサービスが、ブロードキャストサービスまたはマルチキャストサービスのうちの少なくとも1つを含む、ステップと、
前記クライアントデバイスによって、前記第1のサービスに従って、前記第1のサービスを介して前記ストリーミングデータの少なくとも前記一部を取得するために前記第1のサービスに関連するリソースの位置に前記ストリーミングデータの少なくとも前記一部の要求を送信するステップと、
前記プロキシユニットによって、前記第1のサービスを介して前記ストリーミングデータを受信するステップであって、前記第1のサービスがユニキャストサービスを含む、ステップとを含む、方法。 - 実行されるときにクライアントデバイスの少なくとも1つのプロセッサに請求項1乃至11の何れか1項に記載の方法を実施させる、ストリーミングデータを受信するための命令を記憶するコンピュータ可読ストレージ媒体。
- ストリーミングデータを受信するためのデバイスであって、
第1のサービスを介して少なくとも1つのリソースの位置に前記ストリーミングデータに関する識別子をマッピングするマニフェストファイルを取得するための手段と、
前記第1のサービスに従って、前記第1のサービスを介して前記ストリーミングデータの少なくとも一部を取得するために前記少なくとも1つのリソースの位置に前記ストリーミングデータの少なくとも前記一部の要求であって、ハイパーテキスト転送プロトコル(HTTP)GET要求を含む前記ストリーミングデータの少なくとも前記一部の前記要求を送信するための手段と、
前記ストリーミングデータの少なくとも前記一部の前記要求に対する応答を前記デバイスのプロキシユニットに受信させるための手段であって、前記要求に対する前記応答が、3xxタイプのHTTPリダイレクトメッセージまたは200タイプのHTTP OKメッセージのうちの少なくとも1つを含み、前記応答が、前記ストリーミングデータが第1のサービスを介して受信されるべきかまたは第2のサービスを介して受信されるべきかの指示をさらに含み、前記応答が、サービスプロバイダネットワークのブロードキャストマルチキャストサービスセンター(BM-SC)から送信され、前記BM-SCおよび前記少なくとも1つのリソースの位置と通信するプロキシユニットを介して中継され、前記3xxタイプのHTTPリダイレクトメッセージまたは前記200タイプのHTTP OKメッセージのうちの前記少なくとも1つが、前記指示を含む第3世代パートナーシッププロジェクト(3GPP)拡張ヘッダを含み、前記デバイスが、ブロードキャストまたはマルチキャストミドルウェアユニットをさらに含み、前記プロキシユニットが、前記ブロードキャストまたはマルチキャストミドルウェアユニットとクライアントデバイスの少なくとも1つのプロセッサによって実行されるクライアントアプリケーションとの間の通信経路に配置される、手段と、
前記指示が前記ストリーミングデータが前記第1のサービスを介して受信されるべきであることを示すときに前記ミドルウェアユニットを無効化するための手段と、
前記指示が前記ストリーミングデータが前記第1のサービスを介して受信されるべきであることを示すときに前記プロキシユニットによって前記第1のサービスを介して前記ストリーミングデータを受信するための手段であって、前記第1のサービスがユニキャストサービスを含む、手段と、
前記指示が前記ストリーミングデータが前記第2のサービスを介して受信されるべきであることを示すときに前記第2のサービスを介して前記ストリーミングデータを受信するために前記ミドルウェアユニットをアクティブ化するための手段であって、前記第2のサービスが、ブロードキャストサービスまたはマルチキャストサービスのうちの少なくとも1つを含む、手段と、
前記指示が前記ストリーミングデータが前記第2のサービスを介して受信されるべきであることを示すときに前記ミドルウェアユニットから前記ストリーミングデータを受信するための手段とを含む、デバイス。
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201361836143P | 2013-06-17 | 2013-06-17 | |
| US61/836,143 | 2013-06-17 | ||
| US14/305,557 US9674251B2 (en) | 2013-06-17 | 2014-06-16 | Mediating content delivery via one or more services |
| US14/305,557 | 2014-06-16 | ||
| PCT/US2014/042752 WO2014204968A1 (en) | 2013-06-17 | 2014-06-17 | Mediating content delivery via one or more services |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2016528763A JP2016528763A (ja) | 2016-09-15 |
| JP2016528763A5 JP2016528763A5 (ja) | 2017-07-13 |
| JP6433999B2 true JP6433999B2 (ja) | 2018-12-05 |
Family
ID=52020246
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2016519718A Active JP6433999B2 (ja) | 2013-06-17 | 2014-06-17 | １つまたは複数のサービスによるコンテンツ配信の調停 |
Country Status (9)
| Country | Link |
|---|---|
| US (2) | US9674251B2 (ja) |
| EP (1) | EP3011719B1 (ja) |
| JP (1) | JP6433999B2 (ja) |
| KR (1) | KR102188606B1 (ja) |
| CN (1) | CN105308932B (ja) |
| BR (1) | BR112015031512B1 (ja) |
| CA (1) | CA2912409C (ja) |
| ES (1) | ES2702103T3 (ja) |
| WO (1) | WO2014204968A1 (ja) |
Families Citing this family (121)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8560604B2 (en) | 2009-10-08 | 2013-10-15 | Hola Networks Ltd. | System and method for providing faster and more efficient data communication |
| US9762639B2 (en) | 2010-06-30 | 2017-09-12 | Brightcove Inc. | Dynamic manifest generation based on client identity |
| US9838450B2 (en) | 2010-06-30 | 2017-12-05 | Brightcove, Inc. | Dynamic chunking for delivery instances |
| US9160779B2 (en) | 2011-06-30 | 2015-10-13 | Qualcomm Incorporated | Dynamic adaptive streaming proxy for unicast or broadcast/multicast services |
| US9445138B2 (en) | 2012-04-12 | 2016-09-13 | Qualcomm Incorporated | Broadcast content via over the top delivery |
| US9820259B2 (en) | 2012-05-04 | 2017-11-14 | Qualcomm Incorporated | Smooth transition between multimedia broadcast multicast service (MBMS) and unicast service by demand |
| US10015437B2 (en) | 2013-01-15 | 2018-07-03 | Qualcomm Incorporated | Supporting transport diversity and time-shifted buffers for media streaming over a network |
| US9191742B1 (en) * | 2013-01-29 | 2015-11-17 | Rawles Llc | Enhancing audio at a network-accessible computing platform |
| US9781181B2 (en) * | 2013-06-17 | 2017-10-03 | Qualcomm Incorporated | Multiple file delivery over unidirectional transport protocol sessions for a service |
| US9674251B2 (en) | 2013-06-17 | 2017-06-06 | Qualcomm Incorporated | Mediating content delivery via one or more services |
| JP2015012305A (ja) * | 2013-06-26 | 2015-01-19 | ソニー株式会社 | コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム |
| GB2516115A (en) * | 2013-07-12 | 2015-01-14 | Canon Kk | Methods and devices for exchanging data |
| CN104378395B (zh) * | 2013-08-14 | 2019-02-05 | 华为技术有限公司 | 访问ott应用、服务器推送消息的方法及装置 |
| US9432204B2 (en) * | 2013-08-24 | 2016-08-30 | Nicira, Inc. | Distributed multicast by endpoints |
| US9241044B2 (en) | 2013-08-28 | 2016-01-19 | Hola Networks, Ltd. | System and method for improving internet communication by using intermediate nodes |
| US9473566B2 (en) * | 2013-09-14 | 2016-10-18 | Qualcomm Incorporated | Delivering services using different delivery methods |
| US9258747B2 (en) * | 2013-09-17 | 2016-02-09 | Intel IP Corporation | User equipment and methods for fast handover failure recovery in 3GPP LTE network |
| US9332047B2 (en) | 2013-09-30 | 2016-05-03 | Brightcove Inc. | Dynamic chunk manipulation for streaming mixed live and on-demand media: dynamic permutation layer |
| US9344857B1 (en) * | 2013-11-06 | 2016-05-17 | Sprint Spectrum L.P. | Frequency band allocation in a wireless communication network |
| US9602392B2 (en) | 2013-12-18 | 2017-03-21 | Nicira, Inc. | Connectivity segment coloring |
| US9602385B2 (en) | 2013-12-18 | 2017-03-21 | Nicira, Inc. | Connectivity segment selection |
| WO2015096160A1 (zh) | 2013-12-27 | 2015-07-02 | 华为技术有限公司 | 一种保持业务连续性的方法及设备 |
| KR102299004B1 (ko) * | 2014-03-10 | 2021-09-09 | 삼성전자주식회사 | 메시지들을 대쉬 클라이언트로 송신하는 방법 및 장치 |
| US9397848B2 (en) * | 2014-03-20 | 2016-07-19 | Cellco Partnership | Interface for accessing evolved multimedia broadcast multicast services (eMBMS) middleware services |
| US9794079B2 (en) | 2014-03-31 | 2017-10-17 | Nicira, Inc. | Replicating broadcast, unknown-unicast, and multicast traffic in overlay logical networks bridged with physical networks |
| ES2842589T3 (es) * | 2014-03-31 | 2021-07-14 | British Telecomm | Transmisión de flujos por multidifusión |
| KR101868628B1 (ko) * | 2014-04-30 | 2018-06-18 | 엘지전자 주식회사 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
| US9591054B2 (en) * | 2014-06-26 | 2017-03-07 | Adobe Systems Incorporated | Multiprotocol multicast streaming proxy |
| JP2016046598A (ja) * | 2014-08-20 | 2016-04-04 | キヤノン株式会社 | 通信装置、通信方法、及び、プログラム |
| US9338715B1 (en) * | 2014-08-21 | 2016-05-10 | Sprint Spectrum L.P. | Method and system for facilitating transition from broadcast to unicast |
| WO2016042359A1 (en) * | 2014-09-16 | 2016-03-24 | Nokia Technologies Oy | Method and apparatus for anonymous access and control of a service node |
| US11943289B2 (en) * | 2014-10-14 | 2024-03-26 | Comcast Cable Communications, Llc | Manipulation of content transmissions |
| US11917002B2 (en) * | 2014-10-14 | 2024-02-27 | Comcast Cable Communications, Llc | Manipulation and recording of content transmissions |
| MX2017005216A (es) * | 2014-10-28 | 2017-10-04 | Sony Corp | Dispositivo de recepcion, dispositivo de transmision, y metodo de procesamiento de datos. |
| EP3223517B1 (en) * | 2014-11-20 | 2020-03-11 | LG Electronics Inc. | Broadcast signal tranmission device, broadcast signal reception device, broadcast signal tranmission method, and broadcast signal reception method |
| US9553918B1 (en) * | 2014-11-26 | 2017-01-24 | Ensighten, Inc. | Stateful and stateless cookie operations servers |
| US9723095B2 (en) * | 2014-12-05 | 2017-08-01 | At&T Intellectual Property I, L.P. | Multi delivery method policy controlled client proxy |
| WO2016093537A1 (ko) | 2014-12-10 | 2016-06-16 | 엘지전자 주식회사 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
| WO2016114638A1 (ko) | 2015-01-18 | 2016-07-21 | 엘지전자 주식회사 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
| MX358332B (es) * | 2015-02-27 | 2018-08-15 | Sony Corp | Aparato de recepcion, metodo de recepcion, aparato de transmision, y metodo de transmision. |
| JP6774957B2 (ja) * | 2015-04-07 | 2020-10-28 | サムスン エレクトロニクス カンパニー リミテッド | マルチメディアブロードキャストマルチキャストサービスに基づくフレキシブルブロードキャストサービスのための方法及び装置 |
| EP3281382A4 (en) * | 2015-04-07 | 2018-04-25 | Samsung Electronics Co., Ltd. | Method and apparatus for flexible broadcast service over mbms |
| US20160321318A1 (en) * | 2015-04-30 | 2016-11-03 | Hewlett-Packard Development Company, L.P. | Service provider dependency mapping |
| US11057446B2 (en) | 2015-05-14 | 2021-07-06 | Bright Data Ltd. | System and method for streaming content from multiple servers |
| KR20160143145A (ko) * | 2015-06-04 | 2016-12-14 | 삼성전자주식회사 | 멀티미디어 서비스를 제공하기 위한 방법 및 그 전자 장치 |
| US10448435B2 (en) * | 2015-06-25 | 2019-10-15 | Telefonaktiebolaget Lm Ericsson (Publ) | Setting up a dedicated bearer in a radio communication network |
| CN107810625B (zh) * | 2015-06-30 | 2020-12-08 | 英国电讯有限公司 | 通过客户端从服务器流传输媒体序列的方法和装置 |
| CN105049954B (zh) * | 2015-07-02 | 2020-07-10 | 中兴通讯股份有限公司 | Ott媒体的组播传输方法、装置及系统 |
| KR102014800B1 (ko) | 2015-07-06 | 2019-08-27 | 엘지전자 주식회사 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
| US20170048681A1 (en) * | 2015-08-11 | 2017-02-16 | At&T Intellectual Property I, L.P. | On-demand time-shifted access of broadcast content |
| CN105263100B (zh) * | 2015-08-31 | 2018-12-14 | 北京邮电大学 | 内容信息传输方法及装置 |
| US10149122B2 (en) | 2015-09-14 | 2018-12-04 | Qualcomm Incorporated | Techniques for in-band signaling of service description updates in RTP |
| KR102454746B1 (ko) * | 2015-10-01 | 2022-10-17 | 삼성전자주식회사 | 통신 시스템에서 미디어 리소스 식별 정보를 송수신하는 장치 및 방법 |
| EP3363159B1 (en) * | 2015-10-13 | 2020-12-02 | Telefonaktiebolaget LM Ericsson (PUBL) | Adaptive precision for reporting consumption of streamed content |
| EP3391608B1 (en) * | 2015-12-18 | 2023-08-09 | Telefonaktiebolaget LM Ericsson (publ) | Handling of content delivery in a client node |
| US10567468B2 (en) * | 2015-12-28 | 2020-02-18 | Check Point Software Technologies Ltd. | Method and system for transparently manipulating downloaded files |
| US10129358B2 (en) * | 2016-01-15 | 2018-11-13 | Verizon Digital Media Services Inc. | Partitioned serialized caching and delivery of large files |
| US10470000B2 (en) * | 2016-02-12 | 2019-11-05 | Samsung Electronics Co., Ltd. | Methods and apparatus for enhanced MBMS content provisioning and content ingestion |
| US10440680B2 (en) * | 2016-02-12 | 2019-10-08 | Electronics And Telecommunications Research Institute | Method and apparatus for controlling location based MBMS service |
| EP3419297B1 (en) * | 2016-02-17 | 2021-07-21 | Samsung Electronics Co., Ltd. | Method and device for controlling the delivery type of mmt based multimedia service |
| US10873637B2 (en) * | 2016-05-02 | 2020-12-22 | Microsoft Technology Licensing, Llc | Controlling service discovery and activation among peers |
| US10701040B2 (en) | 2016-05-23 | 2020-06-30 | Amazon Technologies, Inc. | Protecting content-stream portions from modification or removal |
| CN111107588B (zh) | 2016-05-30 | 2021-03-05 | 华为技术有限公司 | 无线通信的方法、核心网实体和用户设备 |
| DE112016006932T5 (de) * | 2016-06-01 | 2019-02-28 | Intel IP Corporation | Benutzergerät (User Equipment, UE) und Verfahren zum Empfang von Downlink-Datendiensten |
| MX2018014751A (es) * | 2016-06-08 | 2019-04-29 | Sony Corp | Dispositivo de recepcion, dispositivo de transmision y metodo de procesamiento de datos. |
| US20170374581A1 (en) * | 2016-06-23 | 2017-12-28 | Huawei Technologies Co., Ltd. | System and method for delivering unicast and broadcast traffic in a communication network |
| KR101863598B1 (ko) * | 2016-07-29 | 2018-06-01 | 주식회사 에어브로드 | 스트리밍 서비스를 위한 클라이언트의 동작 방법 |
| WO2018028986A1 (en) | 2016-08-11 | 2018-02-15 | Telefonaktiebolaget Lm Ericsson (Publ) | Improved adaptive bit rate streaming of live content |
| EP3497909B1 (en) * | 2016-08-11 | 2022-06-01 | Telefonaktiebolaget LM Ericsson (publ) | Improved adaptive bit rate streaming of live content with manifest update push notification or long poll |
| BR112019002867A2 (pt) * | 2016-08-19 | 2019-05-14 | Sony Corporation | aparelho de processamento de informação, método de processamento de dados, e, aparelho cliente. |
| US10979495B2 (en) | 2016-08-29 | 2021-04-13 | Saturn Licensing Llc | Information processing apparatus, information processing method, and information processing system |
| US10749925B1 (en) * | 2016-09-02 | 2020-08-18 | Snap Inc. | Video streaming optimization for quick start of video display |
| US10686855B2 (en) * | 2016-09-22 | 2020-06-16 | Verizon Patent And Licensing Inc. | HLS over multimedia broadcast multicast service (MBMS) |
| US10355916B2 (en) * | 2016-09-27 | 2019-07-16 | Mcafee, Llc | Survivable networks that use opportunistic devices to offload services |
| US10542409B2 (en) * | 2016-10-07 | 2020-01-21 | Qualcomm Incorporated | Access for group call services through a broadcast channel |
| CA3040829C (en) * | 2016-10-27 | 2024-05-21 | Sony Corporation | Information processing device and information processing method |
| CN109863796B (zh) | 2016-10-28 | 2023-11-07 | 瑞典爱立信有限公司 | eMBMS MooD的高级切换策略 |
| KR102540459B1 (ko) * | 2016-12-22 | 2023-06-05 | 한화비전 주식회사 | Rtp/rtsp 표준을 따르는 서버와 클라이언트에서 실시간 영상 스트리밍 방법 |
| KR20190110557A (ko) * | 2017-02-06 | 2019-09-30 | 퀄컴 인코포레이티드 | 멀티미디어 브로드캐스트 멀티캐스트 서비스를 위한 성능 및 커버리지 결정 |
| US9872062B1 (en) * | 2017-02-22 | 2018-01-16 | Wyse Technology L.L.C. | Enforcing synchronization by embedding audio within video frame data |
| EP3373524B1 (en) * | 2017-03-08 | 2023-08-23 | Robert Bosch GmbH | Audio stream network with network components and method for running and/or configuring the network with network components |
| US10291941B2 (en) | 2017-03-09 | 2019-05-14 | At&T Mobility Ii Llc | Pre-caching video content to devices using LTE broadcast |
| CN108810973B (zh) * | 2017-05-05 | 2022-01-14 | 华为技术有限公司 | 网络过载控制的方法及装置 |
| KR101966284B1 (ko) * | 2017-06-16 | 2019-04-08 | 성균관대학교 산학협력단 | 상태 기반 포워딩을 수행하는 네트워크에서의 능동적인 요청 패킷 관리 장치 및 그 방법 |
| JP6797755B2 (ja) * | 2017-06-20 | 2020-12-09 | キヤノン株式会社 | 撮像装置、撮像装置の処理方法およびプログラム |
| WO2018235025A1 (en) * | 2017-06-22 | 2018-12-27 | Reliance Jio Infocomm Limited | SYSTEM AND METHOD FOR REVERSE INTERROGATION EVALUATION |
| EP4199479A1 (en) | 2017-08-28 | 2023-06-21 | Bright Data Ltd. | Improving content fetching by selecting tunnel devices grouped according to geographic location |
| US11190374B2 (en) | 2017-08-28 | 2021-11-30 | Bright Data Ltd. | System and method for improving content fetching by selecting tunnel devices |
| US20190075545A1 (en) * | 2017-09-02 | 2019-03-07 | Qualcomm Incorporated | Method and apparatus for providing unicast representations within a broadcast coverage area |
| US10461884B2 (en) | 2017-10-05 | 2019-10-29 | Comcast Cable Communications, Llc | Server selected variable bitrate streaming |
| US10791003B2 (en) * | 2017-10-30 | 2020-09-29 | Intel Corporation | Streaming on diverse transports |
| FR3074004B1 (fr) * | 2017-11-20 | 2019-11-22 | Airbus Ds Slc | Systeme de communication de groupe pour la transmission de donnees multimedia |
| GB201719654D0 (en) | 2017-11-27 | 2018-01-10 | Nchain Holdings Ltd | Computer-implemented system and method |
| US10728303B2 (en) * | 2017-12-05 | 2020-07-28 | At&T Intellectual Property I, L.P. | Codec selection for end-to-end communication without intermediate transcoding |
| WO2019223005A1 (en) * | 2018-05-25 | 2019-11-28 | Qualcomm Incorporated | Mixed mode multicast architecture |
| US10924775B2 (en) * | 2018-06-26 | 2021-02-16 | Qualcomm Incorporated | Uplink and downlink methods for efficient operation of live uplink streaming services |
| US10681503B2 (en) | 2018-09-06 | 2020-06-09 | Verizon Patent And Licensing Inc. | Systems and methods for caching and managing multicast content |
| CN110891246B (zh) * | 2018-09-11 | 2022-07-05 | 成都鼎桥通信技术有限公司 | 一种组播媒体数据的处理方法 |
| US11372977B2 (en) * | 2018-11-12 | 2022-06-28 | Thirdwayv, Inc. | Secure over-the-air firmware upgrade |
| US11625806B2 (en) * | 2019-01-23 | 2023-04-11 | Qualcomm Incorporated | Methods and apparatus for standardized APIs for split rendering |
| FR3092720B1 (fr) * | 2019-02-12 | 2021-03-05 | Groupe Canal | Streaming adaptatif et contextuel |
| US11349764B2 (en) | 2019-02-15 | 2022-05-31 | Qualcomm Incorporated | Methods and apparatus for signaling offset in a wireless communication system |
| LT3780547T (lt) * | 2019-02-25 | 2023-03-10 | Bright Data Ltd. | Turinio parsisiuntimo, naudojant url bandymų mechanizmą, sistema ir būdas |
| CN111835697B (zh) | 2019-04-23 | 2021-10-01 | 华为技术有限公司 | 一种媒体流发送方法、装置、设备和系统 |
| US10778457B1 (en) | 2019-06-18 | 2020-09-15 | Vmware, Inc. | Traffic replication in overlay networks spanning multiple sites |
| US11470041B2 (en) * | 2019-06-20 | 2022-10-11 | Disney Enterprises, Inc. | Software defined network orchestration to manage media flows for broadcast with public cloud networks |
| US11234054B2 (en) | 2019-07-22 | 2022-01-25 | Qatar Foundation For Education, Science And Community Development | Edge network system for service-less video multicast |
| WO2021014591A1 (ja) * | 2019-07-23 | 2021-01-28 | 日本電信電話株式会社 | コンテンツ配信システム、マルチキャストユニキャスト／マルチキャストマルチキャスト変換装置、マルチキャストユニキャスト変換装置、コンテンツ配信方法及びコンテンツ配信プログラム |
| US11172501B2 (en) | 2019-09-05 | 2021-11-09 | Qualcomm Incorporated | Methods and apparatus for signaling offset in a wireless communication system |
| US11909535B2 (en) * | 2019-10-24 | 2024-02-20 | Qualcomm Incorporated | Operating in a radio link control acknowledged mode using a multicast or broadcast radio bearer |
| TWI734326B (zh) * | 2019-12-30 | 2021-07-21 | 新唐科技股份有限公司 | 音訊同步處理電路及其方法 |
| CN113573248B (zh) * | 2020-04-28 | 2023-06-20 | 华为技术有限公司 | 用于传输数据的方法与装置 |
| CN115918034A (zh) * | 2020-05-21 | 2023-04-04 | Idac控股公司 | 多媒体广播/多播服务(mbms)传送模式切换的方法 |
| EP4297481A1 (en) * | 2021-02-18 | 2023-12-27 | LG Electronics Inc. | Mbs-related communication method |
| CN115314758A (zh) * | 2021-05-06 | 2022-11-08 | 武汉斗鱼鱼乐网络科技有限公司 | 一种视频播放方法及相关设备 |
| US20220377503A1 (en) * | 2021-05-19 | 2022-11-24 | Tencent America LLC | Method and apparatus for real time uav connection monitoring and location reporting |
| US20230004619A1 (en) * | 2021-07-02 | 2023-01-05 | Vmware, Inc. | Providing smart web links |
| US11784922B2 (en) | 2021-07-03 | 2023-10-10 | Vmware, Inc. | Scalable overlay multicast routing in multi-tier edge gateways |
| US11695822B2 (en) * | 2021-07-16 | 2023-07-04 | Adp, Inc. | Unified integration pattern protocol for centralized handling of data feeds |
| CN114025192B (zh) * | 2021-11-04 | 2024-05-28 | 广州方硅信息技术有限公司 | 直播数据加密、解密方法、装置、存储介质及计算机设备 |
| CN116455686B (zh) * | 2023-06-15 | 2023-09-01 | 银河互联网电视有限公司 | 应急广播平台的消息播发方法和设备 |
Family Cites Families (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050043035A1 (en) * | 2003-08-21 | 2005-02-24 | Diesen Michael J. | Method and apparatus for providing multimedia broadcast multicast service data to a subscriber to a multimedia broadcast multicast service |
| GB0402739D0 (en) * | 2004-02-09 | 2004-03-10 | Saviso Group Ltd | Methods and apparatus for routing in a network |
| CA2608705A1 (en) * | 2005-05-17 | 2006-11-23 | Telcordia Technologies, Inc. | Secure virtual point of service for 3g wireless networks |
| US7738863B2 (en) | 2005-08-25 | 2010-06-15 | Nokia Corporation | IP datacasting middleware |
| WO2007078663A2 (en) | 2005-12-16 | 2007-07-12 | Interdigital Technology Corporation | Mobility middleware architecture for multiple radio access technology apparatus |
| CN101051996B (zh) * | 2006-06-16 | 2010-12-08 | 华为技术有限公司 | 实现以太网穿越移动ip的设备、系统和方法 |
| US20080130548A1 (en) * | 2006-11-03 | 2008-06-05 | Nokia Corporation | Control signaling for multimedia broadcast multicast service point-to-multipoint over high speed downlink packet access information |
| US8495228B2 (en) * | 2007-04-23 | 2013-07-23 | Nokia Corporation | System and method for optimizing download user service delivery to roaming clients |
| WO2008155698A1 (en) * | 2007-06-18 | 2008-12-24 | Nokia Corporation | Determining a transmission window for transmission bursts of broadcast service |
| EP2104290A1 (en) * | 2008-03-17 | 2009-09-23 | NEC Corporation | Method for accelerating the activation of an MBMS service |
| WO2011068784A1 (en) | 2009-12-01 | 2011-06-09 | Azuki Systems, Inc. | Method and system for secure and reliable video streaming with rate adaptation |
| US9026671B2 (en) * | 2011-04-05 | 2015-05-05 | Qualcomm Incorporated | IP broadcast streaming services distribution using file delivery methods |
| US9226265B2 (en) | 2011-04-15 | 2015-12-29 | Qualcomm Incorporated | Demand-based multimedia broadcast multicast service management |
| US9160779B2 (en) | 2011-06-30 | 2015-10-13 | Qualcomm Incorporated | Dynamic adaptive streaming proxy for unicast or broadcast/multicast services |
| US9826502B2 (en) * | 2011-07-25 | 2017-11-21 | Qualcomm Incorporated | Managing handoff triggering between unicast and multicast services |
| WO2013053448A1 (en) * | 2011-10-11 | 2013-04-18 | Telefonaktiebolaget L M Ericsson (Publ) | Technique for delivering schedule information for an mbms user service |
| US9712891B2 (en) | 2011-11-01 | 2017-07-18 | Nokia Technologies Oy | Method and apparatus for selecting an access method for delivery of media |
| US20130182643A1 (en) | 2012-01-16 | 2013-07-18 | Qualcomm Incorporated | Method and system for transitions of broadcast dash service receptions between unicast and broadcast |
| US9606845B2 (en) * | 2012-03-05 | 2017-03-28 | Hewlett-Packard Development Company, L.P. | Proxy for accessing a middleware subsystem |
| US8949451B2 (en) * | 2012-04-27 | 2015-02-03 | Mobitv, Inc. | Combined broadcast and unicast delivery |
| US9820259B2 (en) | 2012-05-04 | 2017-11-14 | Qualcomm Incorporated | Smooth transition between multimedia broadcast multicast service (MBMS) and unicast service by demand |
| US9729603B2 (en) * | 2012-09-27 | 2017-08-08 | Alcatel Lucent | Content stream delivery using variable cache replacement granularity |
| US20140089467A1 (en) * | 2012-09-27 | 2014-03-27 | Andre Beck | Content stream delivery using pre-loaded segments |
| US10015437B2 (en) | 2013-01-15 | 2018-07-03 | Qualcomm Incorporated | Supporting transport diversity and time-shifted buffers for media streaming over a network |
| US9674251B2 (en) | 2013-06-17 | 2017-06-06 | Qualcomm Incorporated | Mediating content delivery via one or more services |
| US10560509B2 (en) | 2013-07-05 | 2020-02-11 | Qualcomm Incorporated | Method and apparatus for using HTTP redirection to mediate content access via policy execution |
-
2014
- 2014-06-16 US US14/305,557 patent/US9674251B2/en active Active
- 2014-06-17 ES ES14739611T patent/ES2702103T3/es active Active
- 2014-06-17 EP EP14739611.3A patent/EP3011719B1/en active Active
- 2014-06-17 JP JP2016519718A patent/JP6433999B2/ja active Active
- 2014-06-17 CA CA2912409A patent/CA2912409C/en active Active
- 2014-06-17 CN CN201480034047.8A patent/CN105308932B/zh active Active
- 2014-06-17 BR BR112015031512-7A patent/BR112015031512B1/pt active IP Right Grant
- 2014-06-17 WO PCT/US2014/042752 patent/WO2014204968A1/en active Application Filing
- 2014-06-17 KR KR1020167001079A patent/KR102188606B1/ko active IP Right Grant
-
2017
- 2017-04-26 US US15/497,820 patent/US9986003B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| US9674251B2 (en) | 2017-06-06 |
| US20170230434A1 (en) | 2017-08-10 |
| BR112015031512B1 (pt) | 2023-03-14 |
| WO2014204968A1 (en) | 2014-12-24 |
| KR102188606B1 (ko) | 2020-12-08 |
| CN105308932A (zh) | 2016-02-03 |
| CA2912409C (en) | 2023-01-03 |
| EP3011719B1 (en) | 2018-09-19 |
| US9986003B2 (en) | 2018-05-29 |
| CN105308932B (zh) | 2018-08-21 |
| CA2912409A1 (en) | 2014-12-24 |
| US20140372624A1 (en) | 2014-12-18 |
| EP3011719A1 (en) | 2016-04-27 |
| ES2702103T3 (es) | 2019-02-27 |
| KR20160019958A (ko) | 2016-02-22 |
| JP2016528763A (ja) | 2016-09-15 |
| BR112015031512A2 (pt) | 2017-07-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9986003B2 (en) | Mediating content delivery via one or more services | |
| KR102203162B1 (ko) | Dash 클라이언트 qoe 메트릭들의 미들웨어 전달 | |
| JP6487076B2 (ja) | インターネットプロトコル（ｉｐ）マルチメディア・サブシステム（ｉｍｓ）ベースのピアツーピア（ｐ２ｐ）コンテンツ配信 | |
| US10433327B2 (en) | Presence service using IMS based DASH service | |
| US10193994B2 (en) | Signaling cached segments for broadcast | |
| US9537902B2 (en) | Enabling devices without native broadcast capability to access and/or receive broadcast data in an efficient manner | |
| CN111225256A (zh) | 基于视频定向的多媒体适应的终端、服务器、方法和装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20170601 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20170601 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20180222 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20180409 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180629 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20181015 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20181107 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6433999 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |