特許 6487076 インターネットプロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）ベースのピアツーピア（Ｐ２Ｐ）コンテンツ配信

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6487076

(24)【登録日】2019年3月1日

(45)【発行日】2019年3月20日

(54)【発明の名称】インターネットプロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）ベースのピアツーピア（Ｐ２Ｐ）コンテンツ配信

(51)【国際特許分類】

   H04W 80/10 20090101AFI20190311BHJP

   H04W 76/10 20180101ALI20190311BHJP

   H04W 88/18 20090101ALI20190311BHJP

【ＦＩ】

   H04W80/10

   H04W76/10

   H04W88/18

【請求項の数】23

【外国語出願】

【全頁数】26

(21)【出願番号】特願2018-5526(P2018-5526)

(22)【出願日】2018年1月17日

(62)【分割の表示】特願2015-561333(P2015-561333)の分割

【原出願日】2013年12月24日

(65)【公開番号】特開2018-82489(P2018-82489A)

(43)【公開日】2018年5月24日

【審査請求日】2018年1月17日

(31)【優先権主張番号】61/808,597

(32)【優先日】2013年4月4日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】514045555

【氏名又は名称】インテル アイピー コーポレイション

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】オイマン，オズグル

【審査官】 松野 吉宏

(56)【参考文献】

【文献】 国際公開第２０１３／０２２４７０（ＷＯ，Ａ１）

【文献】 国際公開第２０１３／０１９２６７（ＷＯ，Ａ１）

【文献】 Jani Hautakorpi,Arturo Salinas,Erkki Harjula,Mika Ylianttila，Interconnecting P2PSIP and IMS，2008 The Second International Conference on Next Generation Mobile Applications, Services, and Technologies，米国，IEEE，２００９年 １月２０日，Pages 83-88

【文献】 France Telecom，IMS based HTTP adaptive Streaming，3GPP TSG-SA WG4#60 S4-100622，フランス，3GPP，２０１０年 ８月１１日，Section 3

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４ − ７／２６

Ｈ０４Ｗ ４／００ − ９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

Ｐ２Ｐアプリケーションサーバーを介するピアツーピア（Ｐ２Ｐ）コンテンツ配信を提供するための命令を有するプログラムであって、
前記命令は、１つ以上のプロセッサによって実行されると、前記Ｐ２Ｐアプリケーションサーバーに、
インターネットプロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）コアネットワーク（ＩＭ ＣＮ）サブシステムを介して、第１のＵＥから受信されたセッション記述プロトコル（ＳＤＰ）オファーを伴うセッション開始プロトコル（ＳＩＰ）招待を復号することと、
前記ＳＤＰオファーを伴う前記ＳＩＰ招待を、前記ＩＭ ＣＮサブシステムを介する第２のＵＥへの送信のために符号化することと、
前記第２のＵＥから前記ＩＭ ＣＮサブシステムを介して受信されたＳＤＰを伴うＳＩＰ確認を復号することと、
前記ＳＤＰを伴う前記ＳＩＰ確認を、前記ＩＭ ＣＮサブシステムを介する前記第１のＵＥへの送信のために符号化することと、
を実行させ、
更に、前記１つ以上のプロセッサによって実行されると、前記Ｐ２Ｐアプリケーションサーバーに、
前記第１のＵＥから前記第２のＵＥにコンテンツメタデータを転送することであって、前記コンテンツメタデータは、ＤＡＳＨ（Dynamic Adaptive Streaming over HyperText Transfer Protocol（ＨＴＴＰ））用のメディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルまたはＭＢＭＳ（Multimedia Broadcast and Multicast Service）用のユーザーサービス記述（ＵＳＤ）ファイルを含み、ＭＢＭＳはｅＭＢＭＳ（Enhanced Multimedia Broadcast and Multicast Service）を含むことと、
セッション開始プロトコル（ＳＩＰ）ベースの制御機構を用いて、Ｐ２Ｐセッションを制御することと、
を実行させる命令を有する、プログラム。

【請求項2】

前記１つ以上のプロセッサによって実行されると、前記Ｐ２Ｐアプリケーションサーバーに、
前記第１のＵＥと前記第２のＵＥとの間のハイパーテキスト転送プロトコルベース（ＨＴＴＰベース）のダウンロード配信を管理することと、
前記第１のＵＥと前記第２のＵＥとの間のＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）ストリームを管理することと、
送信側ＵＥから複数の受信側ＵＥへのＦＬＵＴＥ（File Delivery over Unidirectional Transport）ベースのインターネットプロトコル（ＩＰ）マルチキャストを管理することと、
を実行させる命令を更に有する、請求項１に記載のプログラム。

【請求項3】

前記ＨＴＴＰベースダウンロード配信は、３ＧＰＰ（Third Generation Partnership Project）ファイル形式（３ＧＰ）ファイルを含み、
前記ＤＡＳＨストリームは、メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイル、または異なるリプレゼンテーションを伴うＤＡＳＨ形式コンテンツを含み、
前記ＦＬＵＴＥベースのＩＰマルチキャストは、非同期階層符号化（asynchronous layered coding：ＡＬＣ）、階層符号化トランスポート（layered coding transport：ＬＣＴ）ビルディングブロックまたはユーザーサービス記述（ＵＳＤ）ファイルを含む、
請求項２に記載のプログラム。

【請求項4】

前記１つ以上のプロセッサによって実行されると、前記Ｐ２Ｐアプリケーションサーバーに、
Ｐ２Ｐコンテンツをコード交換すること、または、
前記Ｐ２Ｐコンテンツをリパッケージすること、または、
前記Ｐ２ＰコンテンツをＤＡＳＨ（Dynamic Adaptive Streaming over HyperText Transfer Protocol（ＨＴＴＰ））形式化すること、または、
前記Ｐ２Ｐコンテンツをセグメント化すること、または、
前記Ｐ２ＰコンテンツのＦＬＵＴＥ（File Delivery over Unidirectional Transport）ベースの配信を提供すること、
を実行させる命令を更に有する、請求項１に記載のプログラム。

【請求項5】

前記１つ以上のプロセッサによって実行されると、前記Ｐ２Ｐアプリケーションサーバーに、
セッション開始プロトコル（ＳＩＰ）Ｂ２ＢＵＡ（back-to-back user agent）をホストすること、または、
前記ＳＩＰ Ｂ２ＢＵＡを介して、前記２つのＵＥ間でＰ２Ｐコンテンツ 配信セッションを確立すること、または、
前記ＳＩＰ Ｂ２ＢＵＡを介して、前記２つのＵＥ間でＰ２Ｐセッションパラメータをネゴシエートすること、または、
セッション記述プロトコル（ＳＤＰ）により、前記Ｐ２Ｐコンテンツ配信セッションを管理すること、または、
メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルまたはユーザーサービス記述（ＵＳＤ）ファイルの変更により、Ｐ２Ｐコンテンツ配信のための新しいメタデータを生成すること、
を実行させる命令を更に有する、請求項１に記載のプログラム。

【請求項6】

前記１つ以上のプロセッサによって実行されると、前記Ｐ２Ｐアプリケーションサーバーに、
Ｐ２Ｐコンテンツ配信サービスをホストすること、または、
Ｐ２Ｐセッション開始およびＰ２Ｐセッション変更の間に、サービス認証およびピア選択を実行すること、または、
ユーザーのＰ２Ｐサービス加入を検証すること、または、
要求コンテンツに対するユーザー権利を検証すること、または、
Ｐ２Ｐサービスに対するアクセスを許可または拒否すること、
を実行させる命令を更に有する、請求項１に記載のプログラム。

【請求項7】

前記Ｐ２Ｐアプリケーションサーバーはサービス制御機能（ＳＣＦ）に含まれる、請求項１に記載のプログラム。

【請求項8】

Ｐ２Ｐアプリケーションサーバーを介するピアツーピア（Ｐ２Ｐ）コンテンツ配信を提供するための命令を有するプログラムであって、
前記命令は、１つ以上のプロセッサによって実行されると、前記Ｐ２Ｐアプリケーションサーバーに、
２つのユーザーイクイップメント（ＵＥ）間のインターネットプロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）コンテンツ配信を管理すること、
を実行させ、
更に、前記１つ以上のプロセッサによって実行されると、前記Ｐ２Ｐアプリケーションサーバーに、
前記２つのＵＥ間でコンテンツメタデータを共有することであって、前記コンテンツメタデータは、ＤＡＳＨ（Dynamic Adaptive Streaming over HyperText Transfer Protocol（ＨＴＴＰ））用のメディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルまたはＭＢＭＳ（Multimedia Broadcast and Multicast Service）用のユーザーサービス記述（ＵＳＤ）ファイルを含み、ＭＢＭＳはｅＭＢＭＳ（Enhanced Multimedia Broadcast and Multicast Service）を含むことと、
セッション開始プロトコル（ＳＩＰ）ベースの制御機構を用いて、前記２つのＵＥ間のＰ２Ｐセッションを制御することと、
を実行させる命令を有する、プログラム。

【請求項9】

前記１つ以上のプロセッサによって実行されると、前記Ｐ２Ｐアプリケーションサーバーに、
２つのＵＥ間のハイパーテキスト転送プロトコル（ＨＴＴＰ）ベースのダウンロード配信を管理すること、または、
２つのＵＥ間のＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）ストリームを管理すること、または、
送信側ＵＥから複数の受信側ＵＥへのＦＬＵＴＥ（File Delivery over Unidirectional Transport）ベースのインターネットプロトコル（ＩＰ）マルチキャストを管理すること、
を実行させる命令を更に有する、請求項８に記載のプログラム。

【請求項10】

前記ＨＴＴＰベースダウンロード配信は、３ＧＰＰ（Third Generation Partnership Project）ファイル形式（３ＧＰ）ファイルを含み、
前記ＤＡＳＨストリームは、メディア・プレゼンテーション記述（ＭＰＤ）メタデータ
ファイル、または異なるリプレゼンテーションを伴うＤＡＳＨ形式コンテンツを含み、
前記ＦＬＵＴＥベースのＩＰマルチキャストは、非同期階層符号化（asynchronous layered coding：ＡＬＣ）、階層符号化トランスポート（layered coding transport：ＬＣＴ）ビルディングブロックまたはユーザーサービス記述（ＵＳＤ）ファイルを含む、
請求項９に記載のプログラム。

【請求項11】

前記１つ以上のプロセッサによって実行されると、前記Ｐ２Ｐアプリケーションサーバーに、
Ｐ２Ｐコンテンツをコード交換すること、または、
前記Ｐ２Ｐコンテンツをリパッケージすること、または、
前記Ｐ２ＰコンテンツをＤＡＳＨ（Dynamic Adaptive Streaming over HyperText Transfer Protocol（ＨＴＴＰ））形式化すること、または、
前記Ｐ２Ｐコンテンツをセグメント化すること、または、
前記Ｐ２ＰコンテンツのＦＬＵＴＥ（File Delivery over Unidirectional Transport）ベースの配信を提供すること、
を実行させる命令を更に有する、請求項８に記載のプログラム。

【請求項12】

前記１つ以上のプロセッサによって実行されると、前記Ｐ２Ｐアプリケーションサーバーに、
セッション開始プロトコル（ＳＩＰ）Ｂ２ＢＵＡ（back-to-back user agent）をホストすること、または、
前記ＳＩＰ Ｂ２ＢＵＡを用いて、前記２つのＵＥ間でＰ２Ｐコンテンツ配信セッションを確立すること、または、
前記ＳＩＰ Ｂ２ＢＵＡを用いて、前記２つのＵＥ間でＰ２Ｐセッションパラメータをネゴシエートすること、または、
セッション記述プロトコル（ＳＤＰ）を用いて前記Ｐ２Ｐコンテンツ配信セッションを管理すること、または、
メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルまたはユーザーサービス記述（ＵＳＤ）ファイルの変更により、Ｐ２Ｐコンテンツ配信のための新しいメタデータを生成すること、
を実行させる命令を更に有する、請求項８に記載のプログラム。

【請求項13】

前記１つ以上のプロセッサによって実行されると、前記Ｐ２Ｐアプリケーションサーバーに、
Ｐ２Ｐコンテンツ配信サービスをホストすること、または、
Ｐ２Ｐセッションの開始およびＰ２Ｐセッションの変更の間に、サービス認証およびピア選択を実行すること、または、
ユーザーのＰ２Ｐサービス加入を検証すること、または、
送信側ＵＥからの要求コンテンツに対するユーザー権利を検証すること、
を実行させる命令を更に有する、請求項８に記載のプログラム。

【請求項14】

前記Ｐ２Ｐアプリケーションサーバーはサービス制御機能（ＳＣＦ）に含まれる、請求項８に記載のプログラム。

【請求項15】

ピアツーピア（Ｐ２Ｐ）コンテンツ配信を提供するように動作するサービス制御機能（ＳＣＦ）モジュールの装置であって、１つ以上のプロセッサと、メモリとを備え、
前記プロセッサは、
インターネットプロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）コアネットワーク（ＩＭ ＣＮ）サブシステムを介して、第１のＵＥから受信されたセッション記述プロトコル（ＳＤＰ）オファーを伴うセッション開始プロトコル（ＳＩＰ）招待を復号するように構成され、
前記ＳＤＰオファーを伴う前記ＳＩＰ招待を、前記ＩＭ ＣＮサブシステムを介する第２のＵＥへの送信のために符号化するように構成され、
前記第２のＵＥから前記ＩＭ ＣＮサブシステムを介して受信されたＳＤＰを伴うＳＩＰ確認を復号するように構成され、
前記ＳＤＰを伴う前記ＳＩＰ確認を、前記ＩＭ ＣＮサブシステムを介する前記第１のＵＥへの送信のために符号化するように構成され、
前記プロセッサは更に、
前記第１のＵＥから前記第２のＵＥにコンテンツメタデータを転送するように構成され、前記コンテンツメタデータは、ＤＡＳＨ（Dynamic Adaptive Streaming over HyperText Transfer Protocol（ＨＴＴＰ））用のメディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルまたはＭＢＭＳ（Multimedia Broadcast and Multicast Service）用のユーザーサービス記述（ＵＳＤ）ファイルを含み、ＭＢＭＳはｅＭＢＭＳ（Enhanced Multimedia Broadcast and Multicast Service）を含み、
セッション開始プロトコル（ＳＩＰ）ベースの制御機構を用いて、Ｐ２Ｐセッションを制御するように構成される、
装置。

【請求項16】

送受信器を更に備え、前記送受信器は、
第１のＵＥからインターネットプロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）コアネットワーク（ＩＭ ＣＮ）サブシステムを介して、セッション記述プロトコル（ＳＤＰ）オファーを伴うセッション開始プロトコル（ＳＩＰ）招待を受信するように構成され、
前記ＳＤＰオファーを伴う前記ＳＩＰ招待を、前記ＩＭ ＣＮサブシステムを介して第２のＵＥに送信するように構成され、
前記第２のＵＥから前記ＩＭ ＣＮサブシステムを介して、ＳＤＰを伴うＳＩＰ確認を受信するように構成され、
前記ＳＤＰを伴う前記ＳＩＰ確認を、前記ＩＭ ＣＮサブシステムを介して前記第１のＵＥに送信するように構成される、
請求項１５に記載の装置。

【請求項17】

前記１つ以上のプロセッサは更に、
前記第１のＵＥと前記第２のＵＥとの間のハイパーテキスト転送プロトコルベース（ＨＴＴＰベース）のダウンロード配信を管理するように構成され、
前記第１のＵＥと前記第２のＵＥとの間のＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）ストリームを管理するように構成され、
送信側ＵＥから複数の受信側ＵＥへのＦＬＵＴＥ（File Delivery over Unidirectional Transport）ベースのインターネットプロトコル（ＩＰ）マルチキャストを管理するように構成される、
請求項１５に記載の装置。

【請求項18】

前記ＨＴＴＰベースのダウンロード配信は、３ＧＰＰ（Third Generation Partnership Project）ファイル形式（３ＧＰ）ファイルを含み、
前記ＤＡＳＨストリームは、メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイル、または異なるリプレゼンテーションを伴うＤＡＳＨ形式コンテンツを含み、
前記ＦＬＵＴＥベースのＩＰマルチキャストは、非同期階層符号化（asynchronous layered coding：ＡＬＣ）、階層符号化トランスポート（layered coding transport：ＬＣＴ）ビルディングブロックまたはユーザーサービス記述（ＵＳＤ）ファイルを含む、
請求項１７に記載の装置。

【請求項19】

前記１つ以上のプロセッサは更に、
Ｐ２Ｐコンテンツをコード交換するように構成されるか、または、
前記Ｐ２Ｐコンテンツをリパッケージするように構成されるか、または、
前記Ｐ２ＰコンテンツをＤＡＳＨ（Dynamic Adaptive Streaming over HyperText Transfer Protocol（ＨＴＴＰ））形式化するように構成されるか、または、
前記Ｐ２Ｐコンテンツをセグメント化するように構成されるか、または、
前記Ｐ２ＰコンテンツのＦＬＵＴＥ（File Delivery over Unidirectional Transport）ベースの配信を提供するように構成される、
請求項１７に記載の装置。

【請求項20】

前記１つ以上のプロセッサは更に、
セッション開始プロトコル（ＳＩＰ）Ｂ２ＢＵＡ（back-to-back user agent）をホストするように構成されるか、または、
前記ＳＩＰ Ｂ２ＢＵＡを介して、前記２つのＵＥ間でＰ２Ｐコンテンツ 配信セッションを確立するように構成されるか、または、
前記ＳＩＰ Ｂ２ＢＵＡを介して、前記２つのＵＥ間でＰ２Ｐセッションパラメータをネゴシエートするように構成されるか、または、
セッション記述プロトコル（ＳＤＰ）により、前記Ｐ２Ｐコンテンツ配信セッションを管理するように構成されるか、または、
メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルまたはユーザーサービス記述（ＵＳＤ）ファイルの変更により、Ｐ２Ｐコンテンツ配信のための新しいメタデータを生成するように構成される、
請求項１７に記載の装置。

【請求項21】

前記１つ以上のプロセッサは更に、
Ｐ２Ｐコンテンツ配信サービスをホストするように構成されるか、または、
Ｐ２Ｐセッション開始およびＰ２Ｐセッション変更の間に、サービス認証およびピア選択を実行するように構成されるか、または、
ユーザーのＰ２Ｐサービス加入を検証するように構成されるか、または、
要求コンテンツに対するユーザー権利を検証するように構成されるか、または、
Ｐ２Ｐサービスに対するアクセスを許可または拒否するように構成される、
請求項１７に記載の装置。

【請求項22】

請求項１乃至７のいずれか一項に記載のプログラムを格納した、少なくとも１つの機械可読記憶媒体。

【請求項23】

請求項８乃至１４のいずれか一項に記載のプログラムを格納した、少なくとも１つの機械可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本願は、２０１３年４月４日付けで出願された米国特許仮出願第６１／８０８，５９７号（代理人整理番号Ｐ５５４８３Ｚ）の利益を主張し、参照により援用する。

【背景技術】

【0002】

無線モバイル通信技術は、様々な規格およびプロトコルを用いて、ノード（例えば送信基地局）と無線装置（例えばモバイルデバイス）との間でデータを伝送する。一部の無線装置は、ダウンリンク（ＤＬ）伝送では直交周波数分割多元接続（ＯＦＤＭＡ）、アップリンク（ＵＬ）伝送ではシングルキャリア周波数分割多重接続（ＳＣ−ＦＤＭＡ）を用いて、通信を行う。信号伝送に直交周波数分割多重（ＯＦＤＭ）を用いる規格およびプロトコルの例として、３ＧＰＰ（Third Generation Partnership Project）のロング・ターム・エボリューション（ＬＴＥ）、電気電子技術者協会（ＩＥＥＥ）の８０２．１６規格（例えば、８０２．１６ｅ、８０２．１６ｍ）（業界団体には一般にＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）として知られる）、ＩＥＥＥの８０２．１１規格（業界団体には一般にＷｉ−Ｆｉとして知られる）が挙げられる。

【0003】

３ＧＰＰの無線アクセスネットワーク（ＲＡＮ）ＬＴＥシステムでは、ノードは、Ｅ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）ノードＢ（一般には進化型（evolved）ノードＢ、強化型（enhanced）ノードＢ、ｅＮｏｄｅＢ、ｅＮＢとも示される）と、無線装置（ユーザーイクイップメント（ＵＥ）として知られる）と通信する無線ネットワークコントローラ（ＲＮＣ）との組合わせであってよい。ダウンリンク（ＤＬ）伝送はノード（例えばｅＮｏｄｅＢ）から無線装置（例えばＵＥ）への通信であってよく、アップリンク（ＵＬ）伝送は無線装置からノードへの通信であってよい。

【0004】

無線装置を用いて、ハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミング等の様々なプロトコルにより、インターネットビデオのマルチメディア配信を受信することができる。ビデオストリーミングのＨＴＴＰベースの配信を提供するプロトコルの例として、ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）が挙げられる。

【図面の簡単な説明】

【0005】

本開示の特徴を例示として示す添付の図面と併せて、以下の詳細な説明から、本開示の特徴および効果が明らかになるであろう。

【図1】一実施例に係る、インターネットプロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）ベースのピアツーピア（Ｐ２Ｐ）コンテンツ配信システムのブロック図である。

【図2】一実施例に係るＤＡＳＨ（Dynamic Adaptive Streaming over HyperText Transfer Protocol（ＨＴＴＰ））のためのクライアントおよびサーバーのブロック図である。

【図3】一実施例に係る、メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイル構成のブロック図である。

【図4】一実施例に係る、ＭＢＭＳ（Multimedia Broadcast and Multicast Service）ユーザーサービスのためのブロードキャスト・マルチキャスト・サービス・センター（ＢＭＳＣ）ユーザープレーン・サブファンクション（ＵＰＦ）（ＢＭＳＣ．ＵＰＦ）のブロック図である。

【図5】一実施例に係る、ピアツーピア（Ｐ２Ｐ）アプリケーショサーバーを用いたインターネットプロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）ベースのパケット交換ストリーミングサービス（ＰＳＳ）およびＭＢＭＳ（Multimedia Broadcast and Multicast Service）機能的アーキテクチャのブロック図である。

【図6】一実施例に係る、インターネットプロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）ベースのピアツーピア（Ｐ２Ｐ）コンテンツ配信を確立するためのセッション開始プロトコル（ＳＩＰ）ベースのセッション制御機構のメッセージフローチャートの一例を示す図である。

【図7】一実施例に係る、ピアツーピア（Ｐ２Ｐ）コンテンツ配信に使用可能なサービス制御機能（ＳＣＦ）モジュールのコンピューター回路の機能性を示す図である。

【図8】一実施例に係る、Ｐ２Ｐアプリケーションサーバーを介してピアツーピア（Ｐ２Ｐ）コンテンツ配信を提供する方法のフローチャートである。

【図9】一実施例に係る、ピアツーピア（Ｐ２Ｐ）アプリケーションサーバー、ノード（例えばｅＮＢ）およびユーザーイクイップメント（ＵＥ）の図である。

【図10】一実施例に係る無線装置（例えばＵＥ）の図である。 以下、図示された例示的実施形態を参照する。本明細書では、特殊言語を用いて例示的実施形態を説明する。とはいえ、それにより本発明の範囲を限定する意図はないことが理解されるであろう。

【発明を実施するための形態】

【0006】

本発明が開示され説明される前に、本発明は本明細書に開示される特定の構造、プロセスステップまたは材料に限定されず、当該技術分野の当業者に認められ得るそれらの均等物にまで拡張されることを理解されたい。また、本明細書で採用される用語は、特定の実施例を説明することを目的として使用されるに過ぎず、限定を目的としないことも理解されたい。同じ参照符号は、異なる図面において同じ要素を表す。フローチャートおよびプロセスにおいて設けられる番号は、ステップおよび工程の図示を明確にする目的で設けられ、必ずしも特定の順序またはシーケンスを示さない。

【0007】

例示的実施形態
以下、最初に技術的実施形態を概観してから、特定の技術的実施形態を詳述する。この最初の要約は、読者が技術をより早く理解するのを助けることを目的とするものであり、該技術の重要な特徴または必須の特徴の特定や、特許請求の範囲の限定を目的とするものではない。

【0008】

インターネットビデオのマルチメディア配信の形式として、ハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミングを用いることができる。ＨＴＴＰとＨＴＴＰの基本となるプロトコル（例えば伝送制御プロトコル（ＴＣＰ）／インターネットプロトコル（ＩＰ））との両方が広く採用されているので、ＨＴＴＰベースの配信により、信頼性およびデプロイメントの単純さがもたらされる。ＨＴＴＰベースの配信では、ネットワーク・アドレス交換（NAT）およびファイアウォールのトラバース問題を回避することにより、簡単で楽なストリーミングサービスが可能となる。また、ＨＴＴＰベースの配信またはストリーミングにより、専用のストリーミングサーバーの代わりに標準的なＨＴＴＰサーバーおよびキャッシュを使用することができるようになる。ＨＴＴＰベースの配信では、サーバー側の状態情報が最小化または低減されるので、拡張性がもたらされる。

【0009】

ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）は、マルチメディアファイルを１以上のセグメントに分割し、ＨＴＴＰを用いてクライアントに配信することのできるマルチメディアストリーミング技術である。ＤＡＳＨは、規格化されたＨＴＴＰストリーミングプロトコルであってよい。一例として、ＤＡＳＨは、３ＧＰＰ技術仕様書（ＴＳ）２６．２４７Ｖｌｌ．１．０（２０１２−１２）において規格化されたものであってよい。また、ＤＡＳＨ技術は、ムービング・ピクチャー・エクスパーツ・グループ（ＭＰＥＧ）、Ｏｐｅｎ ＩＰＴＶ Ｆｏｒｕｍ（ＯＩＰＦ）、ハイブリッド・ブロードキャスト・ブロードバンド・ＴＶ（ＨｂｂＴＶ）等の他の組織によっても規格化されている。

【0010】

ＤＡＳＨクライアントは、一連のＨＴＴＰ要求応答トランザクションを通じてセグメントをダウンロードすることにより、マルチメディアコンテンツを受信することができる。ＤＡＳＨにより、利用可能な帯域幅の変化に従って、メディアコンテンツの異なるリプレゼンテーション（例えばビットレートや符号化タイプ）を動的に切り替える能力を提供することができる。したがって、ＤＡＳＨにより、ネットワークおよび無線リンクの変化する状態、ユーザー嗜好および装置の機能（ディスプレイ解像度、採用される中央演算処理装置（ＣＰＵ）の種類、利用可能なメモリリソース等）に素早く適応することができる。ＤＡＳＨの動的な適応により、起動の遅延が短縮され再バッファリングイベントが減少するので、ユーザーの経験品質（ＱｏＥ）を向上することができる。

【0011】

インターネットプロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）またはＩＰマルチメディア・コアネットワーク・サブシステム（ＩＭ ＣＮ）は、ＤＡＳＨコンテンツ等のＩＰマルチメディアサービスを配信するための３ＧＰＰのアーキテクチャ・フレームワークである。ＩＰマルチメディア・コアネットワーク・サブシステムは、規格化されたインターフェースによってリンクされた異なるコアネットワークとアクセスネットワークの機能の集合であってよく、グループ化されると１つのＩＭＳ管理ネットワークを形成し得る。

【0012】

ピアツーピア（Ｐ２Ｐ）通信を採用すると、モバイルデバイスへのストリーミングメディアの配信を大幅に改善することができる。メディアコンテンツの消費が爆発的に増加するに伴い、ストリーミングサービスを提供するメディアサーバーの数は、ユーザーの数に対してほぼ直線的に増加する可能性がある。更に、集中型ストリーミングメディアサーバーには、基幹ＩＰネットワークの帯域幅に対するかなりの需要がある。所望のサービス品質（ＱｏＳ）および／または経験品質（ＱｏＥ）を提供するために、ますます多くのエッジサーバーがＵＥに近接して配置され得る。エッジサーバーは、ローカルでサービスを受けるＵＥからの要求を処理することができ、また、隣接するエッジサーバーから伝送される要求も処理することができる。

【0013】

ＵＥに近接して配置される必要のあるエッジサーバーの数を低減するために、エッジサーバーとＵＥとの間でピアツーピア技術を用いることができる。モバイルデバイス（例えばＵＥ）の機能が許せば、ＵＥはストリーミングデータ用に予備のアップリンク帯域幅および記憶空間を提供することができる。ストリーミングデータは、他の要求された宛先にアップロードすることができる。コンテンツをセグメント化して送信することができ、トラフィックのほとんどがネットワークの端まで広がり得るので、集中型サーバーの記憶空間および帯域幅の需要を低減するのに役立つ。よって、Ｐ２Ｐ技術によりシステム能力を改善することができ、Ｐ２Ｐサーバーとして機能するエッジサーバーおよび／またはＵＥの数を増やすことができる。

【0014】

一実施形態において、ＩＭＳは、マルチメディアサービスを提供するために、固定またはモバイルの覆域コアネットワークを有することができる。更に、ＩＭＳは、ユーザー認証、登録、サービス発見およびマルチメディアセッション制御のためのインフラストラクチャを提供することができる。図１に、ＩＭＳベースのＰ２Ｐコンテンツ配信システム１００の概観を示す。一実施形態において、ＩＭＳが構成されたＵＥ１１０は、固定またはモバイルのアクセスネットワークを介して、ＩＭＳ ＣＮサブシステム１０２に対してコンテンツ配信を開始することができる。ＩＭＳ ＵＥはポータル１０４にリダイレクトされてよく、ポータル１０４はコンテンツ索引作成機能、ブラウジング機能および検索機能を提供することができる。コンテンツは、ＵＥ用のネットワークサーバー１０６等のコンテンツサーバーに保存されてよい。コンテンツ配信の速度を上げるために、コンテンツキャッシュサーバー１０８は、ユーザーに近接して配置することができる。

【0015】

ユーザープロファイルはＩＭＳ１００に保存されてよく、ＵＥ１１０等の端末の機能（すなわち処理機能、画面サイズ、３ＧＰＰ機能）は、ユーザー嗜好と共にＰ２Ｐアプリケーションサービス（例えばＰ２Ｐアプリケーションサーバー）に保存されてよい。ＵＥの機能を用いて、ＵＥまたはＵＥ上で動作するクライアントが要求されたコンテンツを受信できるか否かを判定することができる。コンテンツ制御を用いて、コンテンツがネットワークにおいてどのように配信されるかと、ＵＥが要求されたコンテンツをどこで受信することができるかとを制御することができる。

【0016】

ＩＭＳベースのピアツーピアコンテンツ配信機能は、３ＧＰＰ（Third Generation Partnership Project）のＩＭＳベースのパケット交換ストリーミングサービス（ＰＳＳ）（３ＧＰＰ技術仕様書（ＴＳ）２６．２３４Ｖ１１．１．０（２０１２−０９）に記載）およびＭＢＭＳ（Multimedia Broadcast and Multicast Service）（３ＧＰＰ技術仕様書（ＴＳ）２６．３４６Ｖ１１．３．０（２０１２−１２）に記載）において適用することのできる機能性であってよい。かかるＩＭＳベースのストリーミングおよびダウンロードサービス機能は、統合マルチメディア・サブシステム（ＩＭＳ）ベースのＰＳＳおよびＭＢＭＳ（Multimedia Broadcast and Multicast Service）（３ＧＰＰ技術仕様書（ＴＳ）２６．２３７Ｖ１１．０．０（２０１２−０６）に記載されるようにＩＭＳ＿ＰＳＳ＿ＭＢＭＳと略称される）に適用することができる。一部のＩＭＳベースのピアツーピアコンテンツ配信 サービスは、多数のオンラインユーザーに対するコンテンツ・オンデマンド・サービス、ライブ・ストリーミング・サービスまたは効率的なソフトウェア配信を含むことができる。

【0017】

ＤＡＳＨコンテンツは、ＩＭＳベースのピアツーピアコンテンツ配信サービスを介して配信することができる。ＤＡＳＨでは、メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルは、サーバーに保存されるメディアコンテンツ・リプレゼンテーションの構造および異なるバージョン（例えば異なるビットレート、フレームレート、解像度、コーデックの種類）についての情報を提供することができる。更に、ＤＡＳＨは、セグメント形式と指定することができる。ＭＰＤメタデータファイルは、他のリプレゼンテーションとの切替えおよび同期提示のためにセグメントをメディア・プレゼンテーション・タイムラインにマップするために、メディアプレーヤーに関する初期化セグメントおよびメディアセグメントについての情報を含むことができる（例えば、メディアプレーヤーは初期化セグメントを検討して、コンテナ形式およびメディアタイミング情報を決定することができる）。メディア・プレゼンテーションの形成におけるセグメントの関係を記述するこのＭＰＤメタデータ情報に基づいて、クライアント（またはクライアント装置）は、ＨＴＴＰ ＧＥＴまたは部分的なＧＥＴ方法を用いて、セグメントを要求することができる。クライアントは、ストリーミングセッションを完全に制御することができる。例えば、クライアントは、定時要求と、セグメントのシーケンスの滑らかなプレイアウトとを管理し、潜在的にはビットレートその他の特質を（例えば、装置の状態またはユーザー嗜好の変化に反応するために）調節することができる。

【0018】

図２に示されるように、ＤＡＳＨにおいて、メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルは、ウェブおよび／またはメディアサーバー２１２に保存されるメディアコンテンツ・リプレゼンテーションの構造および異なるバージョンについての情報を提供することができる。メディアコンテンツ・リプレゼンテーションの異なるバージョンの例として、異なるビットレート、フレームレート、解像度、コーデックの種類その他の類似の種類の情報が挙げられる。更に、ＤＡＳＨは、セグメント形式を特定することもでき、他のリプレゼンテーションとの切替えおよび同期提示のためにセグメントをメディア・プレゼンテーション・タイムラインにマップするために、メディアエンジンに関する初期化およびメディアセグメントについての情報を含むことができる。ＭＰＤメタデータ情報（セグメントの関係と、セグメントがどのようにメディア・プレゼンテーションを形成するのかとを記述する）に基づいて、クライアント２２０は、ＨＴＴＰ ＧＥＴ２４０メッセージまたは一連の部分的なＧＥＴメッセージを用いて、セグメントを要求することができる。クライアントは、定時要求とセグメントのシーケンスの滑らかなプレイアウトとを管理したり、潜在的には装置の状態またはユーザー嗜好の変化に反応するためにビットレートその他の特質を調節する等、ストリーミングセッションを制御することができる。

【0019】

図２は、ＤＡＳＨベースのストリーミングフレームワークを示す。ウェブ／メディアサーバー２１２のメディアエンコーダー２１４は、オーディオ／ビデオ入力２１０からの入力メディアを、保存の形式またはストリーミングの形式に符号化することができる。メディアセグメンタ２１６は、入力メディアを一連のフラグメントまたはチャンクに分ける際に用いることができ（２３２）、一連のフラグメントまたはチャンク２３２はウェブサーバー２１８に供給されてよい。クライアント２２０は、ウェブサーバー（例えばＨＴＴＰサーバー）に送られるＨＴＴＰ ＧＥＴメッセージを用いて、新しいデータをチャンクで要求することができる（２３４）。

【0020】

例えば、クライアント２２０のウェブブラウザ２２２は、ＨＴＴＰ ＧＥＴメッセージ２４０を用いてマルチメディアコンテンツを要求することができる。ウェブサーバー２１８は、マルチメディアコンテンツに関するＭＰＤ２４２をクライアントに提供することができる。関連メタデータ情報２５２に示されるように、ＭＰＤを用いて、各セグメントのインデックスおよびセグメントの対応する場所を伝達することができる。２３６に示されるように、ウェブブラウザは、ＭＰＤ２４２に従って、サーバーからセグメントごとにメディアを引き出すことができる。例えば、ウェブブラウザは、ＨＴＴＰ ＧＥＴ ＵＲＬ（ｆｒａｇ １ ｒｅｑ）２４４を用いて第１のフラグメントを要求することができる。ユニフォーム・リソース・ロケーター（ＵＲＬ）またはユニバーサル・リソース・ロケーターを用いて、クライアントがどのセグメントを要求するのかをウェブサーバーに伝えることができる（２５４）。ウェブサーバーは、第１のフラグメント（すなわちフラグメント１（２４６））を提供することができる。後続のフラグメントについて、ウェブブラウザは、ＨＴＴＰ ＧＥＴ ＵＲＬ（ｆｒａｇ ｉ ｒｅｑ）２４８を用いてフラグメントｉを要求することができる。ｉはフラグメントの整数インデックスである。結果として、ウェブサーバーはフラグメントｉ（２５０）を提供することができる。フラグメントは、メディアデコーダーおよび／またはプレーヤー２２４を介してクライアントに対して提示することができる。

【0021】

図３に示されるように、ＤＡＳＨは、メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイル４０２の異なる形式を指定することができる。メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイル４０２は、セグメント形式（またはフラグメント形式）だけでなく、サーバーに保存されるメディアコンテンツ・リプレゼンテーションの構造および異なるバージョンについての情報を提供する。ＤＡＳＨにおいて、メディア・プレゼンテーション記述（ＭＰＤ）メタデータ４０２は、ウェブおよび／またはメディアサーバーに保存されるメディアコンテンツ・リプレゼンテーションの構造および異なるバージョンについての情報を提供することができる。図３に示される例では、ＭＰＤメタデータは、所定の長さ（この例では６０秒）をもつ期間４０４に時間的に分割されてよい。各期間は、複数の適応セット４０６を含むことができる。各適応セットは、複数の符号化代替をもつ１以上のメディアコンポーネントについての情報を提供することができる。例えば、この例の適応セット０は、異なるビットレート、モノ、ステレオ、サラウンドサウンド等の、符号化の異なる様々なオーディオ代替を含み得る。期間ＩＤによるマルチメディア・プレゼンテーションのために異なる品質のオーディオを提供することに加えて、適応セットは異なる言語のオーディオを含んでもよい。適応セットにおいて提供される異なる代替は、リプレゼンテーション４０８と称することができる。

【0022】

図３において、適応セット１は、様々なビットレート（例えば５メガビット／秒（Ｍｂｐｓ）、２Ｍｂｐｓ、５００キロビット／秒（ｋｂｐｓ））またはトリックモードでビデオを提供するものとして示される。トリックモードは、探索、早送り、巻き戻しその他の、マルチメディアストリーミングファイルの場所の変更に用いることができる。更に、ビデオは異なる形式で利用可能であってもよく、例えば２次元（２Ｄ）または３次元の（３Ｄ）ビデオや、縦長書式または横長書式のビデオであってよい。各リプレゼンテーション４０８はセグメント情報４１０を含むことができる。セグメント情報は、初期化情報４１２および実際のメディアセグメントデータ４１４を含むことができる。この例では、ＭＰＥＧ−４（ＭＰ４）ファイルがサーバーからモバイルデバイスへストリーミング配信される。この例ではＭＰ４を用いたが、多種多様な異なるコーデックが用いられてよい。コーデックは、デジタルデータストリームまたは信号を符号化または復号することのできる装置、アプリケーション、要素またはコンピュータープログラムである。

【0023】

適応セットのマルチメディアは、更に小さなセグメントに分割することができる。図３の例では、適応セット１の６０秒のビデオセグメントが、更に各１５秒の４つのサブセグメント４１４に分割される。これらの例は限定を意図していない。適応セットおよび各メディアセグメントまたはサブセグメントの実際の長さは、メディアの種類、システム要件、可能性のある干渉の種類等によって決まる。実際のメディアセグメントまたはサブセグメントは、１秒未満から数分の長さを有してよい。

【0024】

ＤＡＳＨコンテンツは、ＭＢＭＳ（Multimedia Broadcast and Multicast Service）を用いて配信されてよい。ＭＢＭＳは、セルラーネットワーク向けのポイントツーマルチポイントのインターフェース仕様であり、コアネットワーク内だけでなくセル内でも、ブロードキャスト・マルチキャスト・サービスの効率のよい配信を提供することができる。ｅＭＢＭＳ（Enhanced Multimedia Broadcast and Multicast Service）はＭＢＭＳのＬＴＥバージョンであってよく、ＬＴＥネットワークで展開されてよい。ＬＴＥのｅＭＢＭＳは、利用可能な無線リソースのサブセットを用いながら、同じコンテンツ情報をセル内のユーザー全員に送信する（すなわちブロードキャスト）か、或いはセル内の所与のユーザー群（加入者）に送信する（すなわちマルチキャスト）ためのトランスポート機能を提供することができ。残りの利用可能な無線リソースは、特定のユーザーへの伝送のサポートに用いることができる（例えばユニキャストサービス）。

【0025】

ｅＭＢＭＳのデプロイメントにより、コアＭＢＭＳユーザーサービス機能の性能およびユーザビリティを向上することができる。ＭＢＭＳダウンロード配信は、ＨＴＴＰベースのユニキャストダウンロード配信をオフロードするためのサービス代替となり得る。利点の例として、非リアルタイムサービスのサポートが可能になること、ＭＢＭＳストリーミングサービスを補完するコンテンツを提供すること、装置（例えばサーバー）上の増大する記憶容量を活用することが挙げられる。ＤＡＳＨセグメント形式は、ＨＴＴＰを用いたユニキャストトランスポートにも使用可能であるが、配信環境がユニキャストであるかマルチキャストであるかには依存しない。ＭＢＭＳユーザーサービスの仕様書（例えば３ＧＰＰのＴＳ２６．３４６）によ、ＦＬＵＴＥ（File Delivery over Unidirectional Transport）プロトコルを用いたＭＢＭＳダウンロード配信により、ＤＡＳＨ形式コンテンツを伝送することが可能となる。

【0026】

ＦＬＵＴＥは、インターネットを介したファイルの一方向配信のためのプロトコルであり、特にマルチキャストネットワークに適する。ＦＬＵＴＥは非同期階層符号化（ＡＬＣ）を基礎とし、大規模マルチキャスト配信向けに設計された基礎プロトコルである。ＦＬＵＴＥは、階層符号化トランスポート（layered coding transport：ＬＣＴ）ビルディングブロックのインスタンス化を提供することができる。ＡＬＣプロトコルは、ＬＣＴビルディングブロックと、混雑状態制御（ＣＣ）ビルディングブロックと、前方誤り訂正（ＦＥＣ）ビルディングブロックとを組み合わせて、混雑状態が制御された信頼できる非同期配信を提供することができる。ＬＣＴは、信頼性の高いコンテンツ配信プロトコルおよびストリーム配信プロトコルのために、トランスポートレベルのサポートを提供することができる。ストリーミングデータまたはダウンロードは、ＭＢＭＳベアラを用いて配信する場合、リアルタイム・トランスポート・プロトコル（ＲＴＰ）でカプセル化し、ＦＬＵＴＥプロトコルを用いてトランスポートすることができる。ＲＴＰは、電話通信、ビデオ電話会議アプリケーション、テレビサービス、ウェブベースのプッシュツートーク機能等の、ストリーミングメディアを用いる通信システムおよび娯楽システムで使用することができる。

【0027】

図４は、ブロードキャスト・マルチキャスト・サービスセンター（ＢＭ−ＳＣ）１４２の機能的アーキテクチャおよび動作を示す。ＢＭ−ＳＣ１４２は、ＤＡＳＨ形式コンテンツ配信用のＭＢＭＳベースのユーザーサービスをホストすることができる。図４は、ＢＭＳＣ（ＢＭ−ＳＣ）の補助機能的アーキテクチャと、ＵＥとＢＭＳＣとの間の関連インターフェースとを示す。ＢＭ−ＳＣは、コンテンツ・プロバイダ／マルチキャスト・ブロードキャストソース１４６と通信することができ、かつ／またはコンテンツ・プロバイダ／マルチキャスト・ブロードキャストソース１４６を制御することができる。ＢＭ−ＳＣは、対話型アナウンス機能、ユーザーサービス発見および／またはアナウンス、セッション・伝送機能、キー管理機能等の様々な機能を提供することができる。セッション・伝送機能は、ＭＢＭＳ配信機能１４４および関連の配信機能を提供することができ、キー管理機能は、キー要求機能およびキー配信機能を提供することができる。ＢＭ−ＳＣは、ＨＴＴＰ（ｈｔｔｐ）、ユーザー・データグラム・プロトコル（ＵＤＰ）、リアルタイム・トランスポート・プロトコル（ＲＴＰ）、ＦＬＵＴＥおよび／またはマルチメディア・インターネット・キーイング（ＭＩＫＥＹ）のプロトコルを用いて、ＵＥと通信することができる。ＢＭ−ＳＣは、ＳＧｍｂインターフェースを用いてＭＢＭＳゲートウェイ（ＭＢＭＳ−ＧＷ）と通信することができる。また、ＢＭ−ＳＣは、Ｇｍｂインターフェースを用いて、ゲートウェイ汎用パケット無線システム（ＧＰＲＳ）対応ノード（ＧＧＳＮ）と通信することができる。

【0028】

本明細書に記載の技術（例えば、Ｐ２Ｐアプリケーションサーバー、セッション制御機能（ＳＣＦ）、ＩＭ ＣＮサブシステム、クライアント装置または端末、ユーザーイクイップメント（ＵＥ）、方法、コンピューター回路、システム、機構、プロセス、プロシージャ）は、ＩＭＳネットワークを介するピアツーピア（Ｐ２Ｐ）コンテンツ配信をサポートすることができる。Ｐ２Ｐコンテンツ配信は、様々なストリーミングおよびダウンロードのプロトコルおよび形式によって行われてよく、例として、１つのＵＥから別のＵＥへの（例えば３ＧＰＰファイル形式（３ＧＰ）ファイルの）ＨＴＴＰベースのダウンロード配信、送信側ＵＥが異なるリプレゼンテーション（例えば品質レベル、ビットレート、コーデック等）を伴うＤＡＳＨ形式コンテンツを有する場合のＨＴＴＰベースの適応ストリーミング（例えば、ＤＡＳＨによる）、送信側ＵＥから複数の受信側ＵＥに配信する場合のＦＬＵＴＥベースのＩＰマルチキャストが挙げられる。ユーザー作成コンテンツ（ＵＧＣ）のライブＨＴＴＰベースの適応ストリーミング（例えばＤＡＳＨによる）の場合、ＵＥは、受信側ＵＥにより信頼性の高い配信を確実にするために、コンテンツをＤＡＳＨ形式で適応的にキャプチャおよび／または符号化してよい。ユーザー作成コンテンツ（ＵＧＣ）のライブＦＬＵＴＥベースＩＰストリーミングの場合、ＵＥは、受信側ＵＥにより信頼性の高い配信を確実にするために、コンテンツを適応的にキャプチャおよび／または符号化してよい。

【0029】

一例では、Ｐ２Ｐコンテンツの配信は、図５に示されるように、Ｐ２Ｐアプリケーションサーバー１３０を用いたＩＭＳベースのパケット交換ストリーミングサービス（ＰＳＳ）およびＭＢＭＳユーザーサービス機能的アーキテクチャにおいて実施することができる。Ｐ２Ｐアプリケーションサーバーの機能性は以下に詳述する。別の例において、Ｐ２Ｐアプリケーションサーバーの機能性は、セッション制御機能（ＳＣＦ）にホストされてよい。ＳＣＦは、サービス論理と、サービス論理の実行をサポートする機能とを提供することができる。例えば、ＳＣＦは、セッション開始およびセッション変更の間にサービス認証を提供することができ、これは、サービスへのアクセスを許可または拒否するために、ＰＳＳおよびＭＢＭＳユーザーのサービス加入を確認することを含んでよい。ＳＣＦは、関連するＰＳＳおよびＭＢＭＳメディア機能を選択することができる。ＨＴＴＰベースの配信に関して、ＳＣＦはプロキシまたはＢ２ＢＵＡ（back-to-back user agent）として機能することができる。ＭＢＭＳに関して、ＳＣＦは終端ユーザーエージェント（ＵＡ）として機能することができる。

【0030】

ＩＭＳベースのピアツーピアコンテンツ配信サービスには、様々な機能的ブロックまたはモジュールを用いることができる。例えば、ＩＭＳコアネットワークサブシステム（ＩＭ ＣＮサブシステム）１２０は、ユーザー登録および認証、移動性およびローミング、マルチメディアセッションの制御、サービス品質（ＱｏＳ）制御、ポリシー制御、課金、回路交換ネットワークとの相互作用をサポートすることができる。ＩＭ ＣＮサブシステムの機能は、３ＧＰＰのＴＳ２３．２２８Ｖ１１．７．０（２０１２−１２）において更に説明され得る。

【0031】

ユーザーイクイップメント（ＵＥ）１１０は、汎用ブートストラッピング・アーキテクチャ（ＧＢＡ）、ＩＭＳ、ＰＳＳおよび／またはＭＢＭＳクライアントを含んでよく、サービス発見および選択を実行し、サービスの開始、変更および停止を処理し、かつ／またはコンテンツを受信しユーザーに提示することができる。一例では、ＵＥ１１０は、ＨＴＴＰ／ＳＩＰアダプタ１５０、ＨＴＴＰサーバー１６０およびＢＭＳＣ．ＵＰＦ１４０をホストしてもよい。

【0032】

ＨＴＴＰ／ＳＩＰアダプタ１５０の機能は、セッション開始プロトコル（ＳＩＰ）セッションをＨＴＴＰ着呼要求と相互に関連付けることができる。ＨＴＴＰ／ＳＩＰアダプタは、ＩＭ ＣＮサブシステム１２０、ＳＣＦ１３２およびＨＴＴＰサーバー１６０とインターフェースで連結することができる。ＨＴＴＰサーバーは、ＨＴＴＰベースの配信のためのＤＡＳＨ形式化されたコンテンツを提供することができる。ＨＴＴＰサーバーの機能は、３ＧＰＰのＴＳ２６．２４７において更に説明され得る。

【0033】

ＢＭＳＣ．ＵＰＦ１４０は、ブロードキャスト・マルチキャスト・サービス・センター（ＢＭＳＣ）ユーザープレーン・サブファンクション（ＵＰＦ）を含むことができる。ＢＭＳＣ．ＵＰＦは、ＭＢＭＳダウンロードのためにＤＡＳＨ形式化されたコンテンツを提供することができる。ＢＭＳＣ．ＵＰＦ（またはＢＭＳＣ．ＵＰＦまたはＢＭ−ＳＣ（図４の１４２））は、コンテンツ・プロバイダ／マルチキャスト・ブロードキャスト・ソース（図４の１４６）と通信することができ、かつ／またはコンテンツ・プロバイダ／マルチキャスト・ブロードキャスト・ソース（図４の１４６）を制御することができる。ＢＭＳＣまたはＢＭＳＣ．ＵＰＦの機能は、３ＧＰＰのＴＳ２６．２４６Ｖ１１．３．０（２０１２−１２）において更に説明され得る。

【0034】

ＰＣＲＦ（Policy and Charging Rule Function）１７０は、ＲＡＮおよびパケット交換（ＰＳ）コアネットワーク１８０における課金およびリソースの確立を制御することができる。ＰＣＲＦの機能は、３ＧＰＰのＴＳ２３．２０３Ｖｌｌ．８．０（２０１２−１２）において更に説明され得る。

【0035】

サービス選択機能（ＳＳＦ）１９０は、利用可能なＰＳＳ（ＨＴＴＰベースのＤＡＳＨを含む）およびＭＢＭＳのユーザーサービスのリストと、関連ユーザーサービス記述情報を提供することができる。ＳＳＦモジュールは、クライアントの識別情報に対してカスタマイズすることができる。

【0036】

Ｐ２Ｐ ＩＭＳサービスは、ＩＭＳベースのＰＳＳおよびＭＢＭＳユーザーサービス機能的アーキテクチャを用いてよい。例えば、送信側ＵＥは、Ｐ２Ｐサーバー機能の一部をホスト（例えば、ＨＴＴＰ、ＨＴＴＰ／ＳＩＰアダプタおよびＢＭＳＣ／ＦＬＵＴＥサーバー機能をサポート）してよい。Ｐ２Ｐ ＩＭＳサービスは、集中型の方式でＵＧＣトラフィックを管理することができる。例えば、Ｐ２Ｐアプリケーションサーバー１３０は（すなわちＵＥの外部で）、ＨＴＴＰサーバー１６０、ＨＴＴＰ／ＳＩＰアダプタ１５０およびＢＭＳＣ／ＦＬＵＴＥサーバー１４０の機能を実行することができ、送信側ＵＥは、コンテンツおよび／または関連メタデータ（例えば、ＤＡＳＨのメディア・プレゼンテーション記述（ＭＰＤ）またはＭＢＭＳのユーザーサービス記述（ＵＳＤ））をＰ２Ｐアプリケーションサーバーにアップロードしてよい。例えば、ＵＥ１１０は、ＨＴＴＰサーバー／クライアントと、ＳＩＰクライアントと、ＨＴＴＰサーバー／クライアントとＳＩＰクライアントとの間で連動するＨＴＴＰ／ＳＩＰアダプタとを有してよい。そして、Ｐ２Ｐアプリケーションサーバーは、コード交換、リパッケージング（例えばＤＡＳＨ形式化）、セグメンテーション、ＦＬＵＴＥベースの配信等を実行することができる。

【0037】

別の構成では、Ｐ２Ｐアプリケーションサーバー１３０は、２つのＵＥ間でピアツーピアコンテンツ配信セッションを確立しＰ２Ｐセッションパラメータをネゴシエートするために、セッション開始プロトコル（ＳＩＰ）Ｂ２ＢＵＡ（back-to-back user agent）として機能することができる。例えば、Ｐ２Ｐアプリケーションサーバーは、ＨＴＴＰベースのダウンロード配信、ＨＴＴＰベースの適応ストリーミング（例えばメディア・プレゼンテーション記述すなわちＭＰＤ）およびＦＬＵＴＥベースのＩＰマルチキャスティング（例えばＭＢＭＳのユーザーサービス記述すなわちＵＳＤ）に関するメタデータを受信し処理することができる。Ｐ２Ｐアプリケーションサーバーは、ＩＭＳベースのＰ２Ｐセッションを管理し制御することができ（例えば、セッション記述プロトコル（ＳＤＰ）を用いたセッション管理により）、また、Ｐ２Ｐコンテンツ配信のための新しいメタデータを生成することができる（例えば、ＭＰＤまたはＵＳＤの変更により）。

【0038】

別の例において、Ｐ２Ｐアプリケーションサーバー１３０は、Ｐ２Ｐコンテンツ配信サービスをホストし、セッション開始およびセッション変更の間にサービス認証およびピア選択を行ってよく、これには、コンテンツ配信サービスへのアクセスを許可または拒否するための、ユーザーのＰ２Ｐサービス加入の検証が含まれてよい。別の構成では、ＩＭＳベースのＰ２Ｐ共有は、実際のメディアではなくメタデータ（例えば、ＤＡＳＨのＭＰＤまたはＭＢＭＳのＵＳＤ）の共有を含んでよい。例えば、メタデータを受信すると、受信側ＵＥは、対応するサービス（例えば、ＤＡＳＨベースのストリーミングまたはＭＢＭＳベースの配信サービス）をホストするサーバーとセッションを確立して、該対応するメディアコンテンツをフェッチしてよい。メタデータのみのＰ２Ｐ共有は、ユーザー作成コンテンツ（ＵＧＣ）よりも、ネットワークにホストされるコンテンツに適用可能であってよい。この例について、Ｐ２Ｐアプリケーションサーバーの役割は、ＳＩＰベースのセッション制御機構を用いて、２つのＵＥ間の関連メタデータのＰ２Ｐ共有を確立することができる。

【0039】

Ｐ２Ｐ共有には、ＩＭＳベースのＰ２Ｐストリーミングおよび／またはコンテンツおよび／またはサービスメタデータ共有等の様々なプロセスを用いることができる。図６は、ＩＭＳベースのＰＳＳおよびＭＢＭＳユーザーサービス機能的アーキテクチャを用いてＩＭＳベースのＰ２Ｐコンテンツ配信を確立するための、ＳＩＰベースのセッション制御機構を示す。ＵＥ１（１１２）はＩＭ ＣＮサブシステム１２２を介してＰ２Ｐアプリケーションサーバー１３０（またはＳＣＦ１３２）と通信することができ、ＵＥ２（１１４）はＩＭ ＣＮサブシステム１２４を介してＰ２Ｐアプリケーションサーバー（またはＳＣＦ）と通信することができる。ＵＥ１は、ＨＴＴＰクライアント、ＳＩＰクライアントおよびＨＴＴＰ／ＳＩＰアダプタをホストすることができる。ＵＥ２は、ＨＴＴＰサーバー、ＳＩＰクライアントおよびＨＴＴＰ／ＳＩＰアダプタをホストすることができる。ＳＣＦは、ＳＩＰ Ｂ２ＢＵＡとして機能して（例えば、ＵＥ１およびＵＥ２のＳＩＰクライアントと通信する）、ＵＥ１とＵＥ２との間のＰ２Ｐコンテンツ配信セッションを確立し、Ｐ２Ｐセッション用のＳＤＰをネゴシエートすることができる。また、ＳＣＦは、Ｐ２Ｐサービスへのユーザー加入と、要求コンテンツに対するユーザー権利とを検証することができる。

【0040】

例えば、ＵＥ１（１１２）は、ＳＤＰオファーを伴うＳＩＰ ＩＮＶＩＴＥメッセージ３０２をＩＭ ＣＮサブシステム１２２に送ることにより、ＵＥ２（１１４）とのＳＩＰ Ｐ２Ｐセッションを開始することができ、ＩＭ ＣＮサブシステム１２２は、ＳＩＰ ＩＮＶＩＴＥ３０４をＳＣＦ１３２に転送することができる。ＳＣＦは、ＳＤＰオファーを伴うＳＩＰ ＩＮＶＩＴＥメッセージ３０６をＩＭ ＣＮサブシステム１２４に送ることができ、ＩＭ ＣＮサブシステム１２４はＳＩＰ ＩＮＶＩＴＥ３０８をＵＥ２に転送することができる。ＵＥ２は、ＳＤＰを伴うＳＩＰ２００ＯＫメッセージ３１０を用いてＩＭ ＣＮサブシステム１２４に応答することができ、ＩＭ ＣＮサブシステム１２４は、ＳＩＰ２００ＯＫ３１２をＳＣＦに転送することができる。ＳＣＦは、ＳＤＰを伴うＳＩＰ２００ＯＫ３１４をＩＭ ＣＮサブシステム１２２に送ることができ、ＩＭ ＣＮサブシステム１２２は、ＳＩＰ２００ＯＫ３１６をＵＥ１に転送することができる。ＳＤＰを受信すると、ＵＥ１は、Ｐ２Ｐコンテンツ配信３１８をＵＥ２から受信することができる。

【0041】

ＤＡＳＨベースのＰ２Ｐストリーミングに関して、ＵＥ１は最初にＳＩＰセッション（例えばＳＩＰ ＩＮＶＩＴＥまたはＲＥ−ＩＮＶＩＴＥ）を確立して、ＵＥ２から（例えばＳＣＦを介して）ＭＰＤをフェッチしてよい。ＭＰＤの受信が成功した後、ＵＥ１はＳＩＰセッションを更新し、受信されたＭＰＤに基づいて、ＤＡＳＨ形式化コンテンツの配信のために新しいＳＤＰをネゴシエートすることができる。一例では、ＵＥ１は、図６に示されるシーケンスに類似のシグナリングを用いて、ＳＩＰセッションを更新することができる。この場合、ＳＩＰ ＩＮＶＩＴＥよりも、ＳＩＰ ＲＥ−ＩＮＶＩＴＥメッセージまたはＳＩＰ ＵＰＤＡＴＥメッセージが用いられる。

【0042】

ＩＭＳベースのコンテンツおよび／またはサービスメタデータ共有に関して、ピアツーピア配信は、ＭＰＤの配信（ＵＥ１へのＤＡＳＨコンテンツ配信のため）またはＵＳＤの配信（ＵＥ１へのＭＢＭＳサービス配信のため）を含むことができる。この場合、ＵＥ２はＤＡＳＨ／ＭＢＭＳサービスの詳細をＵＥ１と共有することができ、そうして、ＵＥ１はＵＥ２と同じサービスおよび／またはコンテンツにアクセスすることができる。

【0043】

Ｐ２Ｐ ＩＭＳサービスは、ＩＭＳベースのＰ２Ｐマルチキャストストリーミングに用いられてもよい。例えば、ＵＥ１は、ＢＭ−ＳＣベースのサーバー機能性およびＳＩＰクライアントをホストすることができる。ＵＥ１にＢＭ−ＳＣ機能性を設けることにより、ＵＥまたはホームゲートウェイの複雑性を高めることができる。ＵＥ２は、ＭＢＭＳクライアントおよびＳＩＰクライアントをホストすることができる。ＳＣＦは、ＳＩＰ Ｂ２ＢＵＡとして機能して（例えば、ＵＥ１およびＵＥ２のＳＩＰクライアントと通信する）、ＵＥ１とＵＥ２との間で、マルチキャストプロトコル（例えば、ＦＬＵＴＥおよびＩＰマルチキャスト）に基づいてＰ２Ｐコンテンツ配信セッションを確立し、Ｐ２ＰマルチキャストセッションのためのＳＤＰをネゴシエートすることができる。また、ＳＣＦは、Ｐ２Ｐサービスへのユーザー加入と、要求コンテンツに対するユーザー権利とを検証することができる。ＳＩＰシグナリングは、図６に示されるシーケンスと類似してよい。ＩＭＳにより（例えばＦＬＵＴＥ／ＩＰを用いて）確立されたＭＢＭＳセッションを通じて、ＵＥ２は、ＵＳＤおよび関連メディア／データコンテンツをＵＥ１から受信することができる。

【0044】

別の例は、図７のフローチャートに示すように、ピアツーピア（Ｐ２Ｐ）コンテンツ配信に使用可能なサービス制御機能（ＳＣＦ）モジュールのコンピューター回路の機能性５００を提供する。本機能性は方法として実施されてよく、或いは、本機能性は命令として機械上で実行されてよい。この場合、命令は、少なくとも１つのコンピューター可読媒体または１つの非一時的な機械可読記憶媒体に含まれてよい。コンピューター回路は、ブロック５１０に示されるように、２つのユーザーイクイップメント（ＵＥ）間のインターネットプロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）コンテンツ配信を管理するように動作するＰ２Ｐアプリケーションサーバーをホストするように構成されてよい。

【0045】

一例では、Ｐ２Ｐアプリケーションサーバーをホストするように構成されるコンピューター回路は更に、２つのＵＥ間のハイパーテキスト転送プロトコル（ＨＴＴＰ）ベースのダウンロード配信を管理するように構成されるか、２つのＵＥ間のＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）ストリームを管理するように構成されるか、送信側ＵＥから複数の受信側ＵＥに対するＦＬＵＴＥ（File Delivery over Unidirectional Transport）ベースのインターネットプロトコル（ＩＰ）マルチキャストを管理するように構成されてよい。ＨＴＴＰベースダウンロード配信は、３ＧＰＰ（Third Generation Partnership Project）ファイル形式（３ＧＰ）ファイルを含むことができる。ＤＡＳＨストリームは、メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイル、または異なるリプレゼンテーションを伴うＤＡＳＨ形式コンテンツを含むことができる。ＦＬＵＴＥベースのＩＰマルチキャストは、非同期階層符号化（asynchronous layered coding：ＡＬＣ）、階層符号化トランスポート（layered coding transport：ＬＣＴ）ビルディングブロックまたはユーザーサービス記述（ＵＳＤ）ファイルを含むことができる。

【0046】

別の例において、Ｐ２Ｐアプリケーションサーバーをホストするように構成されるコンピューター回路は更に、Ｐ２Ｐコンテンツをコード変換するように構成されるか、Ｐ２Ｐコンテンツをリパッケージするように構成されるか、Ｐ２ＰコンテンツをＤＡＳＨ（Dynamic Adaptive Streaming over HyperText Transfer Protocol（ＨＴＴＰ））形式化するように構成されるか、Ｐ２Ｐコンテンツをセグメント化するように構成されるか、Ｐ２ＰコンテンツのＦＬＵＴＥ（File Delivery over Unidirectional Transport）ベースの配信を提供するように構成されてよい。Ｐ２Ｐアプリケーションサーバーをホストするように構成されるコンピューター回路は更に、セッション開始プロトコル（ＳＩＰ）Ｂ２ＢＵＡ（back-to-back user agent）をホストするように構成されるか、ＳＩＰ Ｂ２ＢＵＡを用いて、２つのＵＥ間でＰ２Ｐコンテンツ配信セッションを確立するように構成されるか、ＳＩＰ Ｂ２ＢＵＡを用いて、２つのＵＥ間でＰ２Ｐセッションパラメータをネゴシエートするように構成されるか、セッション記述プロトコル（ＳＤＰ）を用いてＰ２Ｐコンテンツ配信セッションを管理するように構成されるか、メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルまたはユーザーサービス記述（ＵＳＤ）ファイルの変更により、Ｐ２Ｐコンテンツ配信のための新しいメタデータを生成するように構成されてよい。

【0047】

別の構成では、Ｐ２Ｐアプリケーションサーバーをホストするように構成されるコンピューター回路は更に、Ｐ２Ｐコンテンツ配信サービスをホストするように構成されるか、Ｐ２Ｐセッション開始およびＰ２Ｐセッション変更の間に、サービス認証およびピア選択を実行するように構成されるか、Ｐ２Ｐサービスへのユーザー加入を検証するように構成されるか、送信側ＵＥからの要求コンテンツに対するユーザー権利を検証するように構成されてよい。Ｐ２Ｐアプリケーションサーバーをホストするように構成されるコンピューター回路は更に、２つのＵＥ間で、ＤＡＳＨ（Dynamic Adaptive Streaming over HyperText Transfer Protocol（ＨＴＴＰ））用のメディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルまたはＭＢＭＳ（Multimedia Broadcast and Multicast Service）用のユーザーサービス記述（ＵＳＤ）ファイルを含むコンテンツメタデータを共有するように構成されるか、セッション開始プロトコル（ＳＩＰ）ベースの制御機構を用いて、２つのＵＥ間のＰ２Ｐセッションを制御するように構成されてよい。

【0048】

別の例は、図８のフローチャートに示されるような、ピアツーピア（Ｐ２Ｐ）アプリケーションサーバーを介してＰ２Ｐコンテンツ配信を提供する方法６００を提供する。本方法は、機械またはコンピューター回路上で命令として実行されてよく、この場合、命令は、少なくとも１つのコンピューター可読媒体または１つの非一時的な機械可読記憶媒体に含まれる。本方法は、ブロック６１０に示されるように、第１のＵＥから、インターネットプロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）コアネットワーク（ＩＭ ＣＮ）サブシステムを介して、セッション記述プロトコル（ＳＤＰ）オファーを伴うセッション開始プロトコル（ＳＩＰ）招待を受信する工程を有する。次に、ブロック６２０に示すように、ＩＭ ＣＮサブシステムを介して、第２のＵＥにＳＤＰオファーを伴うＳＩＰ招待を転送する工程が続く。本方法の次の工程は、ブロック６３０に示されるように、第２のＵＥからＩＭ ＣＮサブシステムを介して、ＳＤＰを伴うＳＩＰ確認を受信する工程であってよい。本方法は更に、ブロック６４０に示されるように、ＩＭ ＣＮサブシステムを介して、第１のＵＥにＳＤＰを伴うＳＩＰ確認を転送する工程を含んでよい。

【0049】

一例では、本方法は更に、第１のＵＥと第２のＵＥとの間のハイパーテキスト転送プロトコル（ＨＴＴＰ）ベースのダウンロード配信を管理する工程、または、第１のＵＥと第２のＵＥとの間のＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）ストリームを管理する工程、または、送信側ＵＥから複数の受信側ＵＥに対するＦＬＵＴＥ（File Delivery over Unidirectional Transport）ベースのインターネットプロトコル（ＩＰ）マルチキャストを管理する工程を有することができる。ＨＴＴＰベースのダウンロード配信は、３ＧＰＰ（Third Generation Partnership Project）ファイル形式（３ＧＰ）ファイルを含んでよい。ＤＡＳＨストリームは、メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイル、または異なるリプレゼンテーションを伴うＤＡＳＨ形式コンテンツを有することができる。ＦＬＵＴＥベースのＩＰマルチキャストは、非同期階層符号化（asynchronous layered coding：ＡＬＣ）、階層符号化トランスポート（layered coding transport：ＬＣＴ）ビルディングブロックまたはユーザーサービス記述（ＵＳＤ）ファイルを含む。

【0050】

別の例において、本方法は更に、Ｐ２Ｐコンテンツをコード交換する工程、または、Ｐ２Ｐコンテンツをリパッケージする工程、または、Ｐ２ＰコンテンツをＤＡＳＨ（Dynamic Adaptive Streaming over HyperText Transfer Protocol（ＨＴＴＰ））形式化する工程、または、Ｐ２Ｐコンテンツをセグメント化する工程、または、Ｐ２ＰコンテンツのＦＬＵＴＥ（File Delivery over Unidirectional Transport）ベースの配信を提供する工程を有することができる。本方法は更に、セッション開始プロトコル（ＳＩＰ）Ｂ２ＢＵＡ（back-to-back user agent）をホストする工程、または、ＳＩＰ Ｂ２ＢＵＡを用いて、２つのＵＥ間でＰ２Ｐコンテンツ配信セッションを確立する工程、または、ＳＩＰ Ｂ２ＢＵＡを用いて、２つのＵＥ間でＰ２Ｐセッションパラメータをネゴシエートする工程、または、セッション記述プロトコル（ＳＤＰ）を用いてＰ２Ｐコンテンツ配信セッションを管理する工程、または、メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルまたはユーザーサービス記述（ＵＳＤ）ファイルの変更により、Ｐ２Ｐコンテンツ配信のための新しいメタデータを生成する工程を有することができる。

【0051】

別の構成では、本方法は更に、Ｐ２Ｐコンテンツ配信サービスをホストする工程、または、Ｐ２Ｐセッション開始およびＰ２Ｐセッション変更の間に、サービス認証およびピア選択を実行する工程、または、ユーザーのＰ２Ｐサービス加入を検証する工程、または、要求コンテンツに対するユーザー権利を検証する工程、または、Ｐ２Ｐサービスへのアクセスを許可または拒否する工程を有することができる。本方法は更に、第１のＵＥから第２のＵＥに、ＤＡＳＨ（Dynamic Adaptive Streaming over HyperText Transfer Protocol（ＨＴＴＰ））用のメディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルまたはＭＢＭＳ（Multimedia Broadcast and Multicast Service）用のユーザーサービス記述（ＵＳＤ）ファイルを含むコンテンツメタデータを転送する工程と、セッション開始プロトコル（ＳＩＰ）ベースの制御機構を用いてＰ２Ｐセッションを制御する工程と、を有することができる。Ｐ２Ｐアプリケーションサーバーはサービス制御機能（ＳＣＦ）に含まれる。

【0052】

図９は、例示的なユーザーイクイップメント（ＵＥ）７２０と、ＩＭＳコア、ＥＰＣ、ＰＳコアおよび／またはＲＡＮ７８０内のノード７１０と、Ｐ２Ｐコンテンツ配信を提供するためのＰ２Ｐアプリケーションサーバー１３０（またはＳＣＦ１３２）とを示す。例えばＳＣＦは、図７の５００に記載されるように、Ｐ２Ｐコンテンツ配信に使用可能であってよい。別の構成では、Ｐ２Ｐアプリケーションサーバーは、図８の６００に記載されるように、Ｐ２Ｐコンテンツ配信を提供するように構成されてよい。一例では、ＵＥはノードを介して、ＳＣＦまたはＰ２Ｐアプリケーションサーバーと通信することができる。ノード７１０の例として、基地局（ＢＳ）、ノードＢ（ＮＢ）、進化型ノードＢ（ｅＮＢ）、ベースバンド装置（ＢＢＵ）、リモート・ラジオ・ヘッド（ＲＲＨ）、リモート無線機器（ＲＲＥ）、リモート無線装置（ＲＲＵ）、中央処理モジュール（ＣＰＭ）が挙げられる。

【0053】

ＵＥ７２０（例えばクライアント装置）は、プロセッサ７２２および送受信器７２４を有してよい。ＵＥは、Ｐ２Ｐコンテンツ配信用に構成されてよい。プロセッサは、セッション開始プロトコル（ＳＩＰ）クライアントと、インターネットプロトコル（ＩＰ）マルチメディア・サブシステム（ＩＭＳ）ベースのＰ２Ｐストリーミングまたはコンテンツメタデータ共有のためのハイパーテキスト転送プロトコル／ＳＩＰ（ＨＴＴＰ／ＳＩＰ）アダプタとをホストするように構成されるか、または、セッション開始プロトコル（ＳＩＰ）クライアントと、ＩＭＳベースのＰ２ＰマルチキャストストリーミングのためのＭＢＭＳ（Multimedia Broadcast and Multicast Service）クライアントとをホストするように構成されてよい。送受信器は、サービス制御機能（ＳＣＦ）のＰ２ＰアプリケーションサーバーからＰ２Ｐコンテンツ配信セッションパラメータを受信するように構成されてよい。

【0054】

ＩＭＳベースのＰ２Ｐストリーミングまたはコンテンツメタデータ共有の例では、プロセッサは更に、ＨＴＴＰクライアントをホストし、ＳＩＰセッションを確立するように構成されてよい。送受信器は更に、別のＵＥからメディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルを受信し、ＭＰＤメタデータファイルに基づいて、セッション記述プロトコル（ＳＤＰ）を用いて、該別のＵＥからＤＡＳＨ形式化コンテンツを受信するように構成されてよい。ＤＡＳＨ形式化コンテンツは、Ｐ２Ｐアプリケーションサーバーによって制御されてよい。

【0055】

ＩＭＳベースのＰ２Ｐストリーミングまたはコンテンツメタデータ共有の別の例において、プロセッサは更に、ＨＴＴＰサーバーをホストし、ＳＩＰセッションを確立するように構成されてよい。送受信器は更に、別のＵＥにメディア・プレゼンテーション記述（ＭＰＤ）メタデータファイルを送信し、ＭＰＤメタデータファイルに基づいて、セッション記述プロトコル（ＳＤＰ）を用いて、該別のＵＥにＤＡＳＨ形式化コンテンツを送信するように構成されてよい。ＤＡＳＨ形式化コンテンツは、Ｐ２Ｐアプリケーションサーバーによって制御されてよい。

【0056】

ＩＭＳベースのＰ２Ｐストリーミングまたはコンテンツメタデータ共有の別の構成において、プロセッサは更に、ＳＩＰセッションを確立するように構成されてよい。送受信器は更に、別のＵＥからＰ２Ｐマルチキャストストリームにおいて、ユーザーサービス記述（ＵＳＤ）ファイルおよび関連データコンテンツを受信するように構成されてよい。Ｐ２Ｐマルチキャストストリームは、Ｐ２Ｐアプリケーションサーバーによって制御されてよい。別の例において、プロセッサは更に、ブロードキャスト・マルチキャスト・サービス・センター・ユーザープレーン・サブファンクション（ＢＭＳＣ．ＵＰＦ）またはＦＬＵＴＥ（File Delivery over Unidirectional Transport）サーバーをホストし、ＳＩＰセッションを確立するように構成されてよい。送受信器は更に、ユーザーサービス記述（ＵＳＤ）ファイルおよび関連データコンテンツを、Ｐ２Ｐマルチキャストストリームにおいて別のＵＥにアップロードするように構成されてよい。Ｐ２Ｐマルチキャストストリームは、Ｐ２Ｐアプリケーションサーバーによって制御されてよい。

【0057】

別の例において、送受信器は更に、別のＵＥからハイパーテキスト転送プロトコル（ＨＴＴＰ）ベースのダウンロードを受信するか、別のＵＥからＤＡＳＨ（Dynamic Adaptive Streaming over ＨＴＴＰ）ストリームを受信するか、送信側ＵＥからＦＬＵＴＥ（File Delivery over Unidirectional Transport）ベースのインターネットプロトコル（ＩＰ）マルチキャストを受信するか、ＨＴＴＰベースのアップロードを別のＵＥに送信するか、ＤＡＳＨストリームを別のＵＥにアップロードするか、ＦＬＵＴＥベースのＩＰマルチキャストを複数の受信側ＵＥに配信するように構成されてよい。ＨＴＴＰベースダウンロード配信は、３ＧＰＰ（Third Generation Partnership Project）ファイル形式（３ＧＰ）ファイルを含むことができる。ＤＡＳＨストリームは、メディア・プレゼンテーション記述（ＭＰＤ）メタデータファイル、または異なるリプレゼンテーションを伴うＤＡＳＨ形式コンテンツを含むことができる。ＦＬＵＴＥベースのＩＰマルチキャストは、非同期階層符号化（asynchronous layered coding：ＡＬＣ）、階層符号化トランスポート（layered coding transport：ＬＣＴ）ビルディングブロックまたはユーザーサービス記述（ＵＳＤ）ファイルを含むことができる。

【0058】

別の構成では、プロセッサは更に、ユーザー作成コンテンツ（ＵＧＣ）をキャプチャし、ＵＧＣをＤＡＳＨ（Dynamic Adaptive Streaming over HyperText Transfer Protocol（ＨＴＴＰ））形式またはＭＢＭＳ（Multimedia Broadcast and Multicast Service）形式に符号化するように構成されてよい。送受信器は更に、サービス制御機能（ＳＣＦ）のＰ２Ｐアプリケーションサーバーを介して、ＵＧＣを別のＵＥにアップロードするように構成されてよい。

【0059】

図１０は、ユーザーイクイップメント（ＵＥ）（例えばモバイル端末（ＭＴ）、モバイルノード、クライアント装置、移動局（ＭＳ）、モバイル無線装置、モバイル通信装置、タブレット、ハンドセットその他の種類の無線装置）の例示である。ＵＥは、ノード、マクロノード、低電力ノード（ＬＰＮ）または伝送基地局（例えば基地局（ＢＳ）、進化型ノードＢ（ｅＮＢ）、ベースバンド装置（ＢＢＵ）、リモート・ラジオ・ヘッド（ＲＲＨ）、リモート無線機器（ＲＲＥ）、中継基地局（ＲＳ）、無線機器（ＲＥ）、リモート無線装置（ＲＲＵ）、中央処理モジュール（ＣＰＭ）その他の種類の無線広域ネットワーク（ＷＷＡＮ）アクセスポイント）と通信するように構成される１以上のアンテナを有することができる。無線装置は、３ＧＰＰのＬＴＥ、ＷｉＭＡＸ、ＨＳＰＡ（High Speed Packet Access）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＷｉＦｉ等の少なくとも１つの無線通信規格を用いて通信するように構成することができる。無線装置は、各無線通信規格について個別のアンテナを用いて通信することができ、或いは、複数の無線通信規格について共用のアンテナを用いて通信することができる。無線装置は、無線ローカルエリアネットワーク（ＷＬＡＮ）、無線パーソナルエリアネットワーク（ＷＰＡＮ）および／またはＷＷＡＮにおいて通信することができる。

【0060】

また、図１０は、ＵＥからのオーディオ入力および出力に関して使用可能なマイクおよび１以上のスピーカーを示す。表示画面は、液晶ディスプレイ（ＬＣＤ）画面であってよく、或いは有機発光ダイオード（ＯＬＥＤ）ディスプレイ等の他の種類の表示画面であってよい。表示画面は、タッチスクリーンとして構成することができる。タッチスクリーンは、容量性、抵抗性その他の種類のタッチスクリーン技術を採用してよい。処理機能および表示機能を提供するために、アプリケーションプロセッサおよびグラフィックスプロセッサを内部メモリに結合することができる。データの入出力オプションをユーザーに提供するために、不揮発性メモリポートを用いることもできる。不揮発性メモリポートは、無線装置のメモリ機能を拡張するために用いられてもよい。追加的なユーザー入力を提供するために、キーボードが無線装置に一体化されてよく、或いは無線装置に無線接続されてよい。タッチスクリーンを用いて仮想キーボードが提供されてもよい。

【0061】

様々な技術、或いはそれらの特定の態様または部分は、フロッピー（登録商標）ディスケット、コンパクトディスク・リードオンリーメモリ（ＣＤ−ＲＯＭ）、ハードドライブ、非一時的なコンピューター可読記憶媒体その他の機械可読記憶媒体のような有形媒体において具現化されるプログラムコード（すなわち命令）の形をとってよい。プログラムコードがコンピューター等の機械にロードされ該機械によって実行される場合、該機械が様々な技術を実施するための装置となる。回路は、ハードウェア、ファームウェア、プログラムコード、実行コード、コンピューター命令および／またはソフトウェアを含むことができる。非一時的なコンピューター可読記憶媒体は、信号を含まないコンピューター可読記憶媒体であってよい。プログラマブルコンピューター上でのプログラムコード実行の場合、コンピューティングデバイスは、プロセッサと、プロセッサによって可読の記憶媒体（揮発性および不揮発性のメモリおよび／または記憶素子を含む）と、少なくとも１つの入力装置と、少なくとも１つの出力装置とを有してよい。揮発性および不揮発性のメモリおよび／または記憶素子は、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ（erasable programmable read-only memory）、フラッシュドライブ、光学ドライブ、磁気ハードドライブ、半導体ドライブその他の電子データを保存する媒体であってよい。ノードおよび無線装置は、送受信器モジュール（すなわち送受信器）、カウンターモジュール（すなわちカウンター）、処理モジュール（すなわちプロセッサ）および／または時計モジュール（すなわち時計）もしくはタイマーモジュール（すなわちタイマー）を有してもよい。本明細書に記載の様々な技術を実施または利用することのできる１以上のプログラムは、アプリケーション・プログラムミング・インターフェース（ＡＰＩ）、再使用可能制御（reusable control）等を用いてよい。かかるプログラムは、コンピューターシステムと通信するために、高度なプロシージャ言語またはオブジェクト指向のプログラミング言語で実施されてよい。しかしながら、プログラムは、必要に応じてアセンブリまたは機械言語で実施されてよい。いずれの場合でも、言語はコンパイラ型またはインタープリタ型の言語であってよく、ハードウェア実装と組み合わされてよい。

【0062】

なお、本明細書に記載の機能ユニットの多くは、それらの実施の独立性をよりはっきりと強調するために、モジュールとして称されている。例えば、モジュールは、カスタム超大規模集積回路（ＶＬＳＩ）またはゲートアレイ、既製の半導体（論理チップ、トランジスタ等）その他の個別のコンポーネントを備えるハードウェア回路として実施されてよい。また、モジュールは、フィールド・プログラマブル・ゲートアレイ、プログラマブル・アレイ論理、プログラマブル論理デバイス等の、プログラマブルハードウェア装置として実施されてもよい。

【0063】

また、モジュールは、様々な種類のプロセッサによる実行用のソフトウェアで実施されてもよい。実行コードの特定モジュールは、例えば、コンピューター命令の１以上の物理ブロックまたは論理ブロックを備えてよく、それらは、例えば、オブジェクト、プロシージャまたは機能としてまとめられてよい。とはいえ、特定モジュールの実行ファイルは物理的に一緒に配置される必要はなく、異なる場所に保存された異種の命令を備えてよく、論理的にまとめられる場合、モジュールを備え該モジュールの上述の目的を達成する。

【0064】

実際、実行コードのモジュールは、単一の命令であっても複数の命令であってもよく、更には、いくつかの異なるコードセグメント、異なるプログラム、いくつかのメモリデバイスに分散されてよい。同様に、動作データは、本明細書ではモジュールで特定され示される場合があるが、任意の適切な形式で具現化されてよく、また、任意の適切な種類のデータ構造にまとめられてよい。動作データは、単一のデータセットとして収集されてよく、或いは、異なる記憶装置等の異なる場所に分散されてよく、また、少なくとも部分的に、単にシステムまたはネットワーク上の電気信号として存在してよい。モジュールは、所望の機能を実行するように動作するエージェントを含め、パッシブであってもアクティブであってもよい。

【0065】

本明細書で「例」または「例示」という場合、該例に関連して記載される特定の特徴、構造または特性が本発明の少なくとも１つの実施形態に含まれることを意味する。よって、「一例では」という語句または「例示」という単語が本明細書の様々な箇所で用いられるが、全てが同じ実施形態に言及するわけではない。

【0066】

本明細書で用いられる場合、複数の項目、構造的要素、組成的要素および／または材料は、便宜上共通のリストに提示される場合がある。しかしながら、かかるリストは該リストの各要素がそれぞれ別々の固有の要素として特定されるかのように解釈されるべきである。よって、かかるリストの個々の要素は、反対の指示なく共通のグループに提示されているというだけで、同じリストの任意の他の要素の事実上の均等物として解釈されるべきではない。更に、本発明の様々な実施形態および例は、それらの様々なコンポーネントの代替と共に言及される場合がある。かかる実施形態、例および代替は、お互いの事実上の均等物として解釈されるものではなく、本発明の別々の自立した表現として解釈されるものである。

【0067】

更に、記載された特徴、構造または特性は、１以上の実施形態において任意の適切な方法で組み合わされてよい。以下の記載では、本発明の実施形態の完全な理解を提供するために、レイアウト、距離、ネットワークの例等の多数の具体的な詳細が提供される。しかし、当該技術分野の当業者であれば、具体的な詳細の１以上がなくても本発明が実施され得ること、或いは、他の方法、コンポーネント、レイアウト等と共に実施され得ることを認識するであろう。他の例では、本発明の態様を不明瞭にしないように、周知の構造、材料または工程は図示または記載されていない。

【0068】

上述の説明は、１以上の特定の適用において本発明の原理を説明するものであるが、当該技術分野の当業者には明らかであるように、発明力の発揮がなくとも、本発明の原理および概念から逸脱することなく、実施の形式、利用法、詳細について多くの変更を行うことができる。したがって、特許請求の範囲によるものを除いて、本発明は限定されない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】