特許第5872737号(P5872737)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 華為技術有限公司の特許一覧

特許5872737コンテンツ配信方法、eNB及び通信システム
<>
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000002
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000003
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000004
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000005
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000006
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000007
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000008
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000009
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000010
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000011
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000012
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000013
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000014
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000015
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000016
  • 特許5872737-コンテンツ配信方法、eNB及び通信システム 図000017
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5872737
(24)【登録日】2016年1月22日
(45)【発行日】2016年3月1日
(54)【発明の名称】コンテンツ配信方法、eNB及び通信システム
(51)【国際特許分類】
   H04W 4/06 20090101AFI20160216BHJP
   H04W 92/20 20090101ALI20160216BHJP
   H04M 11/00 20060101ALI20160216BHJP
【FI】
   H04W4/06 170
   H04W92/20
   H04M11/00 302
【請求項の数】13
【全頁数】20
(21)【出願番号】特願2015-516459(P2015-516459)
(86)(22)【出願日】2013年11月6日
(65)【公表番号】特表2015-523017(P2015-523017A)
(43)【公表日】2015年8月6日
(86)【国際出願番号】CN2013086650
(87)【国際公開番号】WO2014183390
(87)【国際公開日】20141120
【審査請求日】2014年2月5日
(31)【優先権主張番号】2166/CHE/2013
(32)【優先日】2013年5月16日
(33)【優先権主張国】IN
(73)【特許権者】
【識別番号】503433420
【氏名又は名称】華為技術有限公司
【氏名又は名称原語表記】HUAWEI TECHNOLOGIES CO.,LTD.
(74)【代理人】
【識別番号】100117787
【弁理士】
【氏名又は名称】勝沼 宏仁
(74)【代理人】
【識別番号】100082991
【弁理士】
【氏名又は名称】佐藤 泰和
(74)【代理人】
【識別番号】100096921
【弁理士】
【氏名又は名称】吉元 弘
(72)【発明者】
【氏名】マドハヴァン,スリーカンス
(72)【発明者】
【氏名】ナンディラジュ,ラヴィ シャンカー
【審査官】 遠山 敬彦
(56)【参考文献】
【文献】 国際公開第2013/004261(WO,A1)
【文献】 国際公開第2012/139016(WO,A2)
【文献】 中国特許出願公開第101686228(CN,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04B 7/24− 7/26
H04M 11/00
H04W 4/00−99/00
(57)【特許請求の範囲】
【請求項1】
LTE方式の無線アクセスネットワーク(RAN)におけるコンテンツ配信方法であって、
コンテンツデータを要求するクライアントリクエストをeNBがUEから受信するステップと、
前記クライアントリクエストに従って、前記eNBがセグメントマップを検査するステップであって、前記セグメントマップは、複数のセグメントに分割された前記コンテンツデータのインデックス情報を保存するように形成されており、前記複数のセグメントは前記RANの中に分散されている、ステップと、
前記セグメントマップの前記インデックス情報に従って、前記eNBが前記RANのうちの1つ以上のeNBから前記複数のセグメントを取得するステップと、
前記複数のセグメントを利用することで前記コンテンツデータを生成するステップと、
前記コンテンツデータを前記eNBが前記UEに送信するステップと
を有するコンテンツ配信方法。
【請求項2】
コンテンツデータをアップロードするためのユーザ生成コンテンツ(UGC)リクエストを、前記eNBが前記UEから受信するステップと、
前記UGCリクエストに従って前記eNBが前記セグメントマップを検査するステップと、
前記eNBが、前記コンテンツデータの複数のセグメントを、前記RANのうちの1つ以上のeNBに別々に送信するステップと
を更に有する請求項1に記載のコンテンツ配信方法。
【請求項3】
前記1つ以上のセグメントが前記RANの中に無かった場合に、前記eNBが、コアネットワーク(CN)又はコンテンツ配信ネットワーク(CDN)から1つ以上のセグメントを取得するステップを更に有する請求項1に記載のコンテンツ配信方法。
【請求項4】
前記アップロードの結果に応じて前記セグメントマップを更新するステップを更に有する請求項3に記載のコンテンツ配信方法。
【請求項5】
前記UEが前記eNBからターゲットeNBへハンドオーバされる場合に、前記クライアントリクエスト又はUGCリクエストに対応するコンテキスト情報を、前記eNBが前記ターゲットeNBに転送するステップを更に有する請求項1−4の何れか1項に記載のコンテンツ配信方法。
【請求項6】
コンテキスト情報が複数の伝送制御プロトコル(TCP)のパラメータを有する、請求項5に記載のコンテンツ配信方法。
【請求項7】
基地局(eNB)であって、
コンテンツデータを要求するクライアントリクエストをUEから受信するように形成された第1の受信部と、
前記クライアントリクエストに従ってセグメントマップを検査するように形成された第1の検査部であって、前記セグメントマップは、複数のセグメントに分割された前記コンテンツデータのインデックス情報を保存するように形成されており、前記複数のセグメントは前記RANの中に分散されている、第1の検査部と、
前記セグメントマップの前記インデックス情報に従って、前記RANのうちの1つ以上のeNBから前記複数のセグメントを取得するように形成された取得部と、
前記複数のセグメントを利用することで前記コンテンツデータを生成するように形成された生成部と、
前記コンテンツデータを前記UEに送信するように形成された第1の送信部と
を有するeNB。
【請求項8】
コンテンツデータをアップロードするためのユーザ生成コンテンツ(UGC)リクエストを、前記UEから受信するように形成された第2の受信部と、
前記UGCリクエストに従って前記セグメントマップを検査するように形成された第2の検査部と、
前記コンテンツデータの複数のセグメントを、前記RANのうちの1つ以上のeNBに別々に送信するように形成された第2の送信部と
を更に有する請求項7に記載のeNB。
【請求項9】
前記1つ以上のセグメントが前記RANの中に無かった場合に、前記取得部が、コアネットワーク(CN)又はコンテンツ配信ネットワーク(CDN)から1つ以上のセグメントを取得するように更に形成されている、請求項7に記載のeNB。
【請求項10】
前記アップロードの結果に応じて前記セグメントマップを更新するように形成された更新部を更に有する請求項9に記載のeNB。
【請求項11】
前記UEが当該eNBからターゲットeNBへハンドオーバされる場合に、前記クライアントリクエスト又はUGCリクエストに対応するコンテキスト情報を、前記ターゲットeNBに転送するプッシュ部を更に有する請求項7−10の何れか1項に記載のeNB。
【請求項12】
複数のセグメントに分割された前記コンテンツデータを保存するように形成された複数のeNBであって、前記複数のセグメントは前記eNBに分散されており、セグメントマップが前記コンテンツデータのインデックス情報を保存するように構成されている、前記複数のeNBと
を有し、
前記複数のeNBのうちの一つは、UEからコンテンツデータを要求するためのクライアントリクエストを受信することが可能であり、前記クライアントリクエストに従ってセグメントマップを検査し、前記セグメントマップにおける前記インデックス情報に従って前記複数のeNBのうちの他のeNBから前記複数のセグメントを取得し、前記複数のセグメントを利用することで前記コンテンツデータを生成し、前記UEに前記コンテンツデータを送信する通信システム。
【請求項13】
前記eNBが、前記コンテンツデータのインデックス情報を保存するセグメントマップを維持するように更に形成されている、請求項12に記載の通信システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は通信の技術分野に関連し、特にロングタームエボリューション(Long Term Evolution:LTE)方式の無線アクセスネットワーク(Radio Access Network:RAN)、基地局(evolved Node B:eNB)及び通信システム等に関連する。
【背景技術】
【0002】
今日、スマートフォンやタブレット等の普及により、インターネットコンテンツデータ(例えば、ビデオ、オーディオ等)へのアクセスが急増している。インターネットビデオがモバイル装置(ユーザ装置[User Equipment:UE]と呼ぶことも可能である)によりアクセスされる場合、インターネットビデオはコンテンツ配信ネットワーク(Content Delivery Network:CDN)のサーバから取得されなければならない。
【0003】
CDNは、インターネットの帯域幅消費量及び関連する遅延/ジッタの低減を促すために使用される。これにより体感品質が改善される。CDNシステムは進歩してきており、無線アクセスネットワーク(RAN)にキャッシュが用意され、インターネットCDNから取得しなければならないとするのではなく、多くのビデオリクエストはRANのキャッシュから提供できる。
【0004】
図1はCDNが配備されている状態を示す図である。図1に示されているように、キャッシュがコアネットワーク(Core Network:CN)に設けられかつRANのノードにも設けられている。
【0005】
(図1に示されているような)従来の方法は、RANのエッジでビデオのキャッシュを可能にし、多くのビデオリクエストが、インターネットCDNから取得されなければならないとするのではなく、RANのキャッシュから提供できるようにしている。これは多数のキャッシュを必要とすることになり、RANノードの各々は小さなサイズのキャッシュを有する。
【0006】
これらのキャッシュは、トラフィックがCNを介してルーティングされる必要なしに、ビデオリクエストに応じる。(例えばeNBのような)RANでキャッシュミスが生じると、CNのパケットゲートウェイ(Packet GateWay:P-GW)又はCDNのサービスプロバイダ(Service Provider:SP)等のような次の(上位の)レベルからデータが取得されることになる。
【発明の概要】
【発明が解決しようとする課題】
【0007】
しかしながら出願人(発明者)は次のことに着目した:(ビデオのような)コンテンツデータは、モバイル装置に届く前に、更に無線キャリアCN及びRANを経て伝送されなければならない。ビデオに遅延が加わるだけでなく、要求されたビデオをインターネットCDNから取得することは、キャリアのCN及びRANバックホール(RAN backhaul)に多大な負担を課すおそれがある。これは、同時に発生した多数のビデオリクエストに対応するネットワーク能力により、輻輳、深刻な遅延及び制限等を招くおそれがある。
【0008】
従来の技術に関する主な問題は:何百万ものビデオを保存できるインターネットCDNで使用される膨大なサイズのキャッシュと比較して、RANは僅か数千のビデオしか保存できず、これによりキャッシュヒット率に影響が及んでいる。場合によっては、必要なデータが隣接するノードに存在するかもしれないのにRANキャッシュミスが発生する。この場合、CN又はインターネットCDNからデータが取得されなければならず、キャリアのCN及びRANバックホールに負担をかけてしまう。
【課題を解決するための手段】
【0009】
実施の形態によるコンテンツ配信方法は、
LTE方式の無線アクセスネットワーク(RAN)におけるコンテンツ配信方法であって、
コンテンツデータを要求するクライアントリクエストをeNBがUEから受信するステップと、
前記クライアントリクエストに従って、前記eNBがセグメントマップを検査するステップであって、前記セグメントマップは、複数のセグメントに分割された前記コンテンツデータのインデックス情報を保存するように形成されており、前記複数のセグメントは前記RANの中に分散されている、ステップと、
前記セグメントマップの前記インデックス情報に従って、前記RANのうちの1つ以上のeNBから前記複数のセグメントを取得するステップと、
前記複数のセグメントを利用することで前記コンテンツデータを生成するステップと、
前記コンテンツデータを前記eNBが前記UEに送信するステップと
を有するコンテンツ配信方法である。
【図面の簡単な説明】
【0010】
図1】CDNが配備されている形態を示す図。
図2】本発明の第1の実施の形態によるLTE-RANにおけるコンテンツ配信方法のフローチャートを示す図。
図3】コンテンツデータがRAN内の複数のノードに分散されている形態を示す図。
図4】本発明の第1の実施の形態によるLTE-RANにおけるコンテンツ配信方法の別のフローチャートを示す図。
図5】システム構造を示す概略図。
図6】本発明及び従来例によるキャッシュヒット率を示す図。
図7】本発明の第2の実施の形態によるLTE-RANにおけるコンテンツ配信方法のフローチャートを示す図。
図8】本発明の第2の実施の形態によるLTE-RANにおけるコンテンツ配信方法の別のフローチャートを示す図。
図9】従来技術においてハンドオーバが通常どのようにしてなされるかを示す概略図。
図10】本発明においてハンドオーバが通常どのようにしてなされるかを示す概略図。
図11】本発明の第3の実施の形態によるLTE-RANにおけるコンテンツ配信方法の別のフローチャートを示す図。
図12】本発明の第4の実施の形態によるeNBの概略図。
図13】本発明の第5の実施の形態によるeNBの概略図。
図14】本発明の第6の実施の形態によるeNBの概略図。
図15】本発明の第6の実施の形態によるeNBの概略図。
図16】本発明の第7の実施の形態による通信システムの概略図。
【発明を実施するための形態】
【0011】
<実施の形態の概要>
本発明の実施の形態は、LTE-RANにおけるコンテンツ配信方法、eNB及び通信システム等に関連する。実施の形態の課題は、可能な限りRANの隣接ノードからコンテンツデータを取得し、キャッシュヒット率を改善しかつRAN及びCN間のリンクリソースを節約することである。
【0012】
本発明の第1の実施形態による方法は、
LTE方式の無線アクセスネットワーク(RAN)におけるコンテンツ配信方法であって、
コンテンツデータを要求するクライアントリクエストをeNBがUEから受信するステップと、
前記クライアントリクエストに従って、前記eNBがセグメントマップを検査するステップであって、前記セグメントマップは、複数のセグメントに分割された前記コンテンツデータのインデックス情報を保存するように形成されており、前記複数のセグメントは前記RANの中に分散されている、ステップと、
前記セグメントマップの前記インデックス情報に従って、前記RANのうちの1つ以上のeNBから前記複数のセグメントを取得するステップと、
前記複数のセグメントを利用することで前記コンテンツデータを生成するステップと、
前記コンテンツデータを前記eNBが前記UEに送信するステップと
を有するコンテンツ配信方法である。
【0013】
本発明の別の実施形態によるコンテンツ配信方法は、
前記1つ以上のセグメントが前記RANの中に無かった場合に、前記eNBが、コアネットワーク(CN)又はコンテンツ配信ネットワーク(CDN)から1つ以上のセグメントを取得するステップを更に有してもよい。
【0014】
本発明の別の実施形態によるコンテンツ配信方法は、
コンテンツデータをアップロードするためのユーザ生成コンテンツ(UGC)リクエストを、前記eNBが前記UEから受信するステップと、
前記UGCリクエストに従って前記eNBが前記セグメントマップを検査するステップと、
前記eNBが、前記コンテンツデータの複数のセグメントを、前記RANのうちの1つ以上のeNBに別々に送信するステップと
を更に有してもよい。
【0015】
本発明の別の実施形態によるコンテンツ配信方法は、
前記アップロードの結果に応じて前記セグメントマップを更新するステップを更に有してもよい。
【0016】
本発明の別の実施形態によるコンテンツ配信方法は、
前記UEが前記eNBからターゲットeNBへハンドオーバされる場合に、前記クライアントリクエスト又はUGCリクエストに対応するコンテキスト情報を、前記eNBが前記ターゲットeNBに転送するステップを更に有してもよい。
【0017】
本発明の別の実施形態によるコンテンツ配信方法においては、
前記コンテキスト情報が複数の伝送制御プロトコル(TCP)のパラメータを有してもよい。
【0018】
本発明の別の実施形態による基地局(eNB)は、
コンテンツデータを要求するクライアントリクエストをUEから受信する第1の受信部と、
前記クライアントリクエストに従ってセグメントマップを検査するように形成された第1の検査部であって、前記セグメントマップは、複数のセグメントに分割された前記コンテンツデータのインデックス情報を保存するように形成されており、前記複数のセグメントは前記RANの中に分散されている、第1の検査部と、
前記セグメントマップの前記インデックス情報に従って、前記RANのうちの1つ以上のeNBから前記複数のセグメントを取得するように形成された取得部と、
前記複数のセグメントを利用することで前記コンテンツデータを生成するように形成された生成部と、
前記コンテンツデータを前記UEに送信するように形成された第1の送信部と
を有するeNBである。
【0019】
本発明の別の実施形態によるeNBは、
前記1つ以上のセグメントが前記RANの中に無かった場合に、前記取得部が、コアネットワーク(CN)又はコンテンツ配信ネットワーク(CDN)から1つ以上のセグメントを取得するように更に形成されてもよい。
【0020】
本発明の別の実施形態によるeNBは、
コンテンツデータをアップロードするためのユーザ生成コンテンツ(UGC)リクエストを、前記UEから受信するように形成された第2の受信部と、
前記UGCリクエストに従って前記セグメントマップを検査するように形成された第2の検査部と、
前記コンテンツデータの複数のセグメントを、前記RANのうちの1つ以上のeNBに別々に送信するように形成された第2の送信部と
を更に有してもよい。
【0021】
本発明の別の実施形態によるeNBは、
前記アップロードの結果に応じて前記セグメントマップを更新するように形成された更新部を更に有してもよい。
【0022】
本発明の別の実施形態によるeNBは、
前記UEが当該eNBからターゲットeNBへハンドオーバされる場合に、前記クライアントリクエスト又はUGCリクエストに対応するコンテキスト情報を、前記ターゲットeNBに転送するプッシュ部を更に有してもよい。
【0023】
本発明の第3の実施形態による通信システムは、
コンテンツデータをダウンロード又はアップロードするように形成されたUEと、
複数のセグメントに分割された前記コンテンツデータを保存するように形成された1つ以上のeNBであって、前記複数のセグメントは前記1つ以上のeNBに分散されている、1つ以上のeNBと
を有する通信システムである。
【0024】
本発明の別の実施形態による通信システムにおいては、
前記eNBが、前記コンテンツデータのインデックス情報を保存するセグメントマップを維持するように更に形成されていてもよい。
【0025】
本発明による利点の1つは、コンテンツデータが複数のセグメントに分割され、それらのセグメントがRAN内に分散している点にある。更に、コンテンツは可能な限りRANの隣接ノードから取得され、キャッシュヒット率が向上し、RAN及びCN間のリンク(リソース)が節約される。
【0026】
本発明に関する上記及び更なる形態及び特徴は、以下の詳細な説明及び添付図面を参照することで更に明らかになる。以下の説明及び図面において、本発明の特定の実施の形態が発明の原理を利用する一例として詳細に説明されているが、本発明の範囲はそのような具体例に限定されないことが理解される。むしろ本発明は添付の特許請求の範囲の文言及び精神に由来する全ての変形例、修正例及び均等物を包含する。
【0027】
ある実施の形態に関して説明及び/又は図示された特徴は、1つ以上の他の実施の形態において及び/又は他の実施の形態の特徴との組み合わせにおいて、又は他の実施の形態の特徴によらず、同一の方法又は類似する方法で使用されてもよい。
【0028】
本明細書で使用されている「有する/有している」等の用語は、言及されている特徴、要素、ステップ又は素子が存在することを示すために使用されているが、1つ以上の他の特徴、要素、ステップ又は素子或いはそれらの組み合わせが存在することを排除してはいない点に留意すべきである。
【0029】
本発明の多くの実施の形態は添付図面と共に以下の詳細な説明により更に理解できるであろう。図中の要素は必ずしも寸法(スケール)を表してはおらず、むしろ本発明の原理を明らかにすることに着目して強調されている。本発明の或る部分の説明及び解説を促すために、図中の対応する部分の大きさは強調され、例えば本発明により実際に形成される装置例の中の他の部分と比較して拡大されているかもしれない。ある図面に記述された要素及び特徴又は本発明の実施の形態は、1つ以上の追加的な図面又は実施の形態に含まれる要素及び特徴と組み合わせられてもよい。更に、図面において、図中の同様な要素は、対応する部分を示し、1つより多い実施の形態における同様な又は類似する部分を示すために使用されている。
【0030】
<実施の形態の詳細な説明>
図面は本発明の更なる理解を促すために本願に含まれており、明細書を補完しかつ本発明の実施の形態を説明しており、本発明の原理を説明するために説明の際に使用されている。図中、同一の要素は同一の参照番号で表現されている。
【0031】
実施の形態に関する多くの特徴及び有利な効果が以下の詳細な説明から更に明らかになり、本発明の精神及び範囲に属する実施の形態に関するそのような特徴及び有利な効果の全てを添付の特許請求の範囲は包含していることが意図されている。更に、多くの修正例及び変形例が当業者にとって明らかであり、本発明は説明及び図示された個々の構造及び動作に限定されず、適切な全ての修正例及び均等物が特許請求の範囲に包含される。
【0032】
以下、本発明の実施の形態が図面を参照しながら説明される。
【0033】
<< 実施の形態1 >>
本発明の実施の形態はLTE-RANにおけるコンテンツの配信方法をもたらす。
【0034】
図2は本発明の実施の形態によるLTE-RANにおけるコンテンツ配信方法のフローチャートを示し、図2に示されているように本方法は以下のステップを含む:
ステップ201,eNBがクライアントリクエストをUEから受信する;クライアントリクエストはコンテンツデータを要求するために使用される。
【0035】
ステップ202,eNBが、クライアントリクエストに従ってセグメントマップを検査する。ここで、セグメントマップは、複数のセグメントに分割されたコンテンツデータのインデックス情報を保存するように形成されており、それらのセグメントはRANの中に分散されている。
【0036】
ステップ203,eNBがセグメントマップのインデックス情報に従って、RANのうちの1つ以上のeNBから複数のセグメントを取得する。
【0037】
ステップ204,eNBが複数のセグメントを利用することでコンテンツデータを生成する。
【0038】
ステップ205,eNBがコンテンツデータをUEに送信する。
【0039】
実施の形態において、コンテンツデータ(例えば、ビデオ、オーディオ)は複数のセグメントに分割される(例えば、M個の等分されたセグメントに分割され、各々のセグメントは一定の持続時間を有する)。これらのセグメントはRANの中のいくつかのノードに分散される(ノードは、基地局、eNB又はeNodeBであってもよい)。コンテンツデータは或るランダムなノードに設けられるのではなく、ある特定の複数の場所(ロケーション)に設けられるように、管理されたオーバーレイ又は管理された分布状態(managed overlay)が形成される。
【0040】
実施の形態において、RANの中の全てのノードは1つの交換局又は移動管理部(Mobile
Management Entity:MME)により管理されてもよい。各々のノードは協調システム(cooperative system)の一部をなしてもよい。RAN方式の協調ストリーミングがなされ、各々のノードは、分散した協調キャッシュを行うようにストレージの一部に寄与する。これにより、セグメントはコンテンツデータに基づいてやり取りされる。
【0041】
実施の形態において、各々のノード(ピア)はセグメントマップを保持又は維持し、セグメントマップは、ストレージキャッシュコンテンツに基づく全てのセグメントのピアインデックス情報を含む。各々ノードはセグメントマップをそれぞれ管理し、例えば、他のノードが協調システムに参加した(又は加わった)場合又は協調システムから脱退した(又は抜けた)場合にセグメントマップを更新する。
【0042】
オーバーレイの管理の仕方の詳細については、フルフィンガテーブルのコード(chord with full finger table)又はO(1)DHTアルゴリズムを利用することが考えられる。しかしながら実施の形態はこの例に限定されず、必要に応じて具体的な方法が決定されてよい。
【0043】
図3は、コンテンツデータがRAN内の複数のノードに分散されている形態を示す。図3に示されているように、コンテンツデータに関していくつかのセグメント(又はチャンク[chunk])が存在し;これらのチャンクは、P2P(ピアツーピア)方式のオーバーレイが形成されるようにいくつかのノード(ピア)に分散されている。
【0044】
図3に示されているように、eNBがクライアントリクエスト(VoD)を受信すると、eNBは他のノードに何らかのセグメントを要求してもよい。これにより、UEはeNBからコンテンツをダウンロードしてもよい。
【0045】
この実施の形態において、本方法は更に、1つ以上のセグメントがRANの中に無かった場合に、eNBが、CN又はCDNから1つ以上のセグメントを取得するステップを更に有してもよい。
【0046】
図4は、本発明の実施の形態によるLTE-RANにおけるコンテンツ配信方法の別のフローチャートを示す。図4に示されているように、RANの3つのeNB(eNB1、eNB2及びeNB3)と、UEと、CNのP-GWと、CDNのSPとが存在している。コンテンツデータのいくつかのセグメントはRANの中に分散され、協調システムがeNB1、eNB2及びeNB3の間で形成されている。
【0047】
図4に示されているように、本方法は以下のステップを含む:
ステップ401,eNB1がクライアントリクエストをUEから受信する;
ステップ402,eNB1がクライアントリクエストに従ってセグメントマップを検査する;
この実施の形態において、コンテンツデータのピア情報(例えば、インデックス情報)は、セグメントマップを検査することで知ることが可能である。例えば、コンテンツデータについて7つのセグメント(A-G)が存在し、3つのセグメント(A、C、D)はeNB1に存在し、2つのセグメント(B、F)はeNB2に存在し、2つのセグメント(E、G)はeNB3に存在している;
ステップ403,eNB1はセグメントをeNB2から取得する;
ステップ404,eNB1はセグメントをeNB3から取得する;
この実施の形態において、1つ以上のセグメントがRANに無かった場合、eNBはCN又はCDNからそのセグメントを取得する。例えば、セグメントDがRANに存在しなかった場合に、選択的なステップ405が行われる。
【0048】
ステップ405,eNB1は、CNのP-GW又はCDNのSPから、セグメントを取得する。
【0049】
ステップ406,eNB1は複数のセグメントを利用することでコンテンツデータを生成する;
この実施の形態において、例えば、eNB1は、eNB2から2つのセグメント(B、F)及びeNB3から2つのセグメント(E、G)を取得し、3つのセグメント(A、C、D)は元々持っている。そして、eNB1は7つのセグメントを利用してコンテンツデータを生成する。
【0050】
ステップ407,eNB1はコンテンツデータをUEに送信する。
【0051】
この実施の形態において、eNBは少ない帯域幅のリンクを利用して複数の隣接ノードから(P2P方式で)少数のチャンクを取得している。これは、S1リンク(CN及びRANの間のリンク)の帯域幅を節約し、従ってS-GWは(少なくともその分だけ)更なるeNBをサポートできる。将来のLTEアドバンストネットワークは、より多くのユーザプレーントラフィックのためにX2インタフェースを利用することを推奨している。
【0052】
図5は本発明に関するシステム構造を概略的に示す。図5に示されているように、従来技術のように70%のデータがS1を介して取得されるのではなく、本発明では、可能な限りX2を介してデータが取得され、(それでも取得できなかった)残りの30%のみがS1を介して取得される。従って、キャッシュヒット率は30%近く改善される。
【0053】
図6は本発明及び従来例によるキャッシュヒット率を概略的に示す。図6に示されているように、明らかに、本発明によるキャッシュヒット率(「協調あり」のグラフ)は従来例(「協調なし」のグラフ)を上回っている。
【0054】
上記の実施の形態から分かるように、コンテンツデータは複数のセグメントに分割され、その複数のセグメントはRAN内に分散している。更に、コンテンツデータは可能な限りRANの隣接ノードから取得され、キャッシュヒット率が改善されかつRAN及びCN間のリンクリソースが節約される。
【0055】
<< 実施の形態2 >>
実施の形態1に基づいて、本発明の実施の形態はLTE-RANにおけるコンテンツ配信方法を提供する。以下に説明する本実施の形態は、実施の形態1のようなダウンロードではなく、データをアップロードすることに着目している;同じ内容については繰り返し説明されない。
【0056】
図7は本発明の実施の形態によるLTE-RANにおけるコンテンツ配信方法のフローチャートを示し、図7に示されているように、本方法は以下のステップを含む:
ステップ701:eNBがUGC(ユーザが生成したコンテンツ)リクエストをUEから受信する;UGCリクエストはコンテンツデータをアップロードするために使用される;
ステップ702:eNBがUGCリクエストに従ってセグメントマップを検査する;
ステップ703:eNBが、コンテンツデータの複数のセグメントを、RANのうちの1つ以上のeNBに別々に送信する。
【0057】
図7に示されているように、本方法は以下のステップを更に含んでもよい。
【0058】
ステップ704:eNBがアップロードの結果に応じてセグメントマップを更新する。
【0059】
図8は本発明の実施の形態によるLTE-RANにおけるコンテンツ配信方法の別のフローチャートを示す。図8に示されているように、RANの3つのeNB(eNB1、eNB2及びeNB3)と、UEと、CNのP-GWと、CDNのSPとが存在している。
【0060】
図8に示されているように、本方法は以下のステップを含む:
ステップ801,eNB1がUGCリクエストをUEから受信する;
ステップ802,eNB1がUGCリクエストに従ってセグメントマップを検査する;
この実施の形態において、コンテンツデータがUGCリクエストに含まれており、コンテンツデータは複数のセグメントに分割されていてもよい。更に、eNB1は、セグメントマップを検査することで、何れのセグメントが他のノードに送信されるべきかを決定してよい。
【0061】
例えば、コンテンツデータは7つのセグメント(A-G)に分割されていてもよい。セグメントマップを検査した結果、eNB1は、3つのセグメント(A、C、D)がeNB1に存在し、2つのセグメント(B、F)がeNB2に存在し、2つのセグメント(E、G)がeNB3に存在していると判断する。
【0062】
ステップ803,eNB1はコンテンツデータのセグメントをeNB2に送信し;
ステップ804,eNB1はコンテンツデータのセグメントをeNB3に送信する;
例えば、2つのセグメント(B、F)がeNB2に送信され、2つのセグメント(E、G)がeNB3に送信される。こうして、コンテンツデータをなす7つのセグメントがRANの中に分散される。
【0063】
図8に示されているように、本方法は以下のステップを更に含んでいてもよい:
ステップ805,eNB1がアップロードの結果に従ってセグメントマップを更新する。更に、eNB2及びeNB3もセグメントマップをそれぞれ更新してもよい。
【0064】
本実施の形態において、UEはCNのP-GW又はCDNのSPにコンテンツデータを更に送信してもよい。
【0065】
上記の実施の形態から分かるように、コンテンツデータは複数のセグメントに分割され、その複数のセグメントはRAN内に分散している。更に、コンテンツデータは可能な限りRANの隣接ノードから取得され、キャッシュヒット率が改善されかつRAN及びCN間のリンクリソースが節約される。
【0066】
<< 実施の形態3 >>
実施の形態1及び2に基づいて、本発明の実施の形態はLTE-RANにおけるコンテンツ配信方法を提供する。以下に説明する実施の形態はハンドオーバ(HO)の状態に着目している;同じ内容については繰り返し説明されない。
【0067】
今日、ユーザのモビリティ及びシームレスなサービス継続性は、CDNサービスを提供する際の他の重要な関心事になっている。3GPPは隣接するeNBをP2P方式で接続するX2インタフェースを規定し、ハンドオーバを支援し、無線リソースの迅速な処理手段を提供している。
【0068】
図9は、従来技術においてハンドオーバが通常どのようにしてなされるかを概略的に示す。図9に示されているように、エボルブドユニバーサル地上無線アクセスネットワーク(E-UTRAN)及びエボルブドパケットコア(EPC)が示されている。更に、アクセスレイヤ、プレアグリゲーションレイヤ、アグリゲーションレイヤ及びバックボーンレイヤも示されている。この場合において、MME、S-GW及びP-GWは何らかのルータの中に存在している。
【0069】
図9に示されているように、UEが或るeNBから別のeNBにハンドオーバされる場合において、コンテンツデータを取得する場合、ユーザの移動に起因してキャッシュミス率は大きくなる。更に、UEは、アグリゲーションレイヤのルータを介して、S1ハンドオーバによりCN又はCDNからコンテンツデータを取得しなければならず;これはキャリアのCN及びRANバックホールに負担をかけてしまう。
【0070】
本実施の形態による方法は以下のステップを含む:UEがソースeNBからターゲットeNBにハンドオーバされる場合に、ソースeNBはコンテキスト情報をターゲットeNBに転送又はプッシュ(push)し;そのコンテキスト情報はクライアントリクエスト又はUGCリクエストに対応する。
【0071】
図10は本発明においてハンドオーバが通常どのようにしてなされるかを概略的に示す。図10に示されているように、ハンドオーバが生じると(UEがeNB1のセルのエリアから移動してeNB2のセルのエリアに入る)、eNB1はコンテキスト情報(例えば、Appセッションコンテキストハンドオーバ[App-Session Context Handover])をeNB2に転送する。
【0072】
コンテキスト情報(例えば、Appセッションコンテキストハンドオーバ)は、例えばシーケンス番号(seqno)、輻輳ウィンドウサイズ(cwnd)、SPアドレス等のような複数の伝送制御プロトコル(TCP)のパラメータを含む。しかしながら、実施の形態はこれらに限定されず、具体的な内容は適宜決定されてよい。
【0073】
図11は本発明の実施の形態によるLTE-RANにおけるコンテンツ配信方法の別のフローチャートを示す。図11に示されているように、RANの2つのeNB(ソースeNB及びターゲットeNB)と、UEと、MMEと、S-GWとが示されている。
【0074】
図11に示されているように、本方法は以下のステップを含む:
ステップ1101,UEはソースeNB及びS-GWと共にコンテンツデータ(パケットデータ)を通信している。
【0075】
ステップ1102,UEはソースeNBからターゲットeNBへハンドオーバされる。
【0076】
例えば、UEはメジャーメントレポートをソースeNBに送信し;ソースeNBがHOの判断を実行し;ソースeNBが、ハンドオーバリクエストをターゲットeNBに送信し、ACKを受信する。
【0077】
ステップ1103,ソースeNBがコンテキスト情報をターゲットeNBに転送又はプッシュする。
【0078】
例えば、ソースeNBは、AppセッションCtxトランスファを実行し、TCPパラメータ(例えば、SeqNO、cwnd、SPアドレス等)をターゲットeNBに送信し、ACKを受信する。
【0079】
ステップ1104,ハンドオーバの他の処理が実行される。
【0080】
例えば、RRCコネクション再設定(RRCコネクションリコンフィギュレーション);データ転送;同期;ULアロケーション+UEのためのTA;RRCコネクション再設定完了(RRCコネクションリコンフィギュレーションコンプリート)等が実行される。
【0081】
この実施の形態では、サービスの継続性を確保するために、アプリケーションセッションコンテキストハンドオーバが使用されている。ハンドオーバはプッシュモデルを用いて生じており、ソースノードがコンテキスト情報をターゲットノードにプッシュ又は転送している。
【0082】
上記の実施の形態から分かるように、コンテンツデータは複数のセグメントに分割され、その複数のセグメントはRAN内に分散している。更に、コンテンツデータは可能な限りRANの隣接ノードから取得され、キャッシュヒット率が改善されかつRAN及びCN間のリンクリソースが節約される。
【0083】
更に、UEがソースeNBからターゲットeNBへハンドオーバされる場合に、ソースeNBはコンテキスト情報をターゲットeNBに転送又はプッシュする。これにより、ユーザが移動する場合でさえキャッシュミス率を減らすことができる。
【0084】
<< 実施の形態4 >>
本発明の実施の形態はeNBを更に提供する。この実施の形態は、上記の実施の形態1による方法に対応しており、同じ内容については説明しない。
【0085】
図12は本発明の実施の形態によるeNBを概略的に示す。図12に示されているように、eNB1200は、第1の受信部1201、第1の検査部1202、取得部1203、生成部1204及び第1の送信部1205を含む。eNBの他の部分は従来技術に関連し、本願においては説明されない。ただし、実施の形態は図示の例に限定されず、実際に必要性に応じて具体的な実現手段が決定されてよい。
【0086】
第1の受信部1201は、コンテンツデータを要求するクライアントリクエストをUEから受信するように形成されている;第1の検査部1202は、クライアントリクエストに従ってセグメントマップを検査するように形成されており、セグメントマップは、複数のセグメントに分割されたコンテンツデータのインデックス情報を保存するように形成されており、複数のセグメントはRANの中に分散されており;取得部1203は、セグメントマップの前記インデックス情報に従って、RANのうちの1つ以上のeNBから複数のセグメントを取得するように形成されており;生成部1204は、複数のセグメントを利用することでコンテンツデータを生成するように形成されており;第1の送信部1205は、コンテンツデータをUEに送信するように形成されている。
【0087】
別の実施の形態において、取得部1204は、1つ以上のセグメントがRANに無かった場合に、CN又はCDNから1つ以上のセグメントを取得するように更に形成されている。
【0088】
上記の実施の形態から分かるように、コンテンツデータは複数のセグメントに分割され、その複数のセグメントはRAN内に分散している。更に、コンテンツデータは可能な限りRANの隣接ノードから取得され、キャッシュヒット率が改善されかつRAN及びCN間のリンクリソースが節約される。
【0089】
<< 実施の形態5 >>
本発明の実施の形態はeNBを更に提供する。この実施の形態は、上記の実施の形態2による方法に対応しており、同じ内容については説明しない。
【0090】
図13は、本発明の実施の形態によるeNBを概略的に示す。図13に示されているように、eNB1300は、第1の受信部1201、第1の検査部1202、取得部1203、生成部1204及び第1の送信部1205を含む。この点は実施の形態4と同様である。
【0091】
図13に示されているように、eNB1300は、第2の受信部1301、第2の検査部1302及び第2の送信部1303を更に含む。第2の受信部1301は、コンテンツデータをアップロードするためのUGCリクエストをUEから受信するように形成されており;第2の検査部1302は、UGCリクエストに従ってセグメントマップを検査するように形成されており;第2の送信部1303は、コンテンツデータの複数のセグメントを、RANのうちの1つ以上のeNBに別々に送信するように形成されている。
【0092】
図13に示されているように、eNB1300は更新部1304を更に含んでいてもよい。更新部1304は、アップロードの結果に応じてセグメントマップを更新するように形成されている。
【0093】
上記の実施の形態から分かるように、コンテンツデータは複数のセグメントに分割され、その複数のセグメントはRAN内に分散している。更に、コンテンツデータは可能な限りRANの隣接ノードから取得され、キャッシュヒット率が改善されかつRAN及びCN間のリンクリソースが節約される。
【0094】
<< 実施の形態6 >>
本発明の実施の形態はeNBを更に提供する。この実施の形態は、上記の実施の形態3による方法に対応しており、同じ内容については説明しない。
【0095】
図14は本発明の実施の形態によるeNBを概略的に示す。図14に示されているように、eNB1400は、第1の受信部1201、第1の検査部1202、取得部1203、生成部1204及び第1の送信部1205を含む。この点は実施の形態4と同様である。
【0096】
図14に示されているように、eNB1400はプッシュ部1401を更に含んでおり;プッシュ部1401は、UEがeNBからターゲットeNBへハンドオーバされる場合に、クライアントリクエスト又はUGCリクエストに対応するコンテキスト情報を、ターゲットeNBに転送又はプッシュするように形成されている。
【0097】
図15は本発明の実施の形態による別のeNBを概略的に示す。図15に示されているように、eNB1500は、第1の受信部1201、第1の検査部1202、取得部1203、生成部1204及び第1の送信部1205を含む。この点は実施の形態4と同様である。
【0098】
図15に示されているように、eNB1500は、第2の受信部1301、第2の検査部1302、第2の送信部1303及び更新部1304を更に含む。この点は実施の形態5と同様である。
【0099】
図15に示されているように、eNB1500はプッシュ部1501を更に含んでおり;プッシュ部1501は、UEがeNBからターゲットeNBへハンドオーバされる場合に、クライアントリクエスト又はUGCリクエストに対応するコンテキスト情報を、ターゲットeNBに転送又はプッシュするように形成されている。
【0100】
上記の実施の形態から分かるように、コンテンツデータは複数のセグメントに分割され、その複数のセグメントはRAN内に分散している。更に、コンテンツデータは可能な限りRANの隣接ノードから取得され、キャッシュヒット率が改善されかつRAN及びCN間のリンクリソースが節約される。
【0101】
更に、UEがソースeNBからターゲットeNBへハンドオーバされる場合に、ソースeNBはコンテキスト情報をターゲットeNBに転送又はプッシュする。これにより、ユーザが移動する場合でさえキャッシュミス率を減らすことができる。
【0102】
<< 実施の形態7 >>
本発明の実施の形態は通信システムを更に提供する。この実施の形態は、上記の実施の形態1-3の方法に対応しており、同じ内容については説明しない。
【0103】
図16は本発明の実施の形態による通信システムを概略的に示す。図16に示されているように、通信システム1600はUE1601及び1つ以上のeNB1602を含む。通信システムの他の部分は従来技術に関連し、本願においては説明されない。
【0104】
UE1601は、コンテンツデータをダウンロード又はアップロードするように形成されている。eNB1602は、複数のセグメントに分割されたコンテンツデータを保存するように形成されており、それらのセグメントは1つ以上のeNBに分散されている。本実施の形態は上記の実施の形態4-6にも関連している。
【0105】
eNB1602は、コンテンツデータのインデックス情報を保存するセグメントマップを維持するように更に形成されていてもよい。
【0106】
上記の実施の形態から分かるように、コンテンツデータは複数のセグメントに分割され、その複数のセグメントはRAN内に分散している。更に、コンテンツデータは可能な限りRANの隣接ノードから取得され、キャッシュヒット率が改善されかつRAN及びCN間のリンクリソースが節約される。
【0107】
本発明の一部をなす各々はハードウェア、ソフトウェア、ファームウェア又はそれらの組み合わせにより実現されてもよいことが、理解されるべきである。上記の実施の形態において、複数のステップ又は方法は、メモリに保存されかつ適切な命令実行システムにより実行されるソフトウェア又はファームウェアにより実現されてもよい。例えば、本発明がハードウェアにより実現される場合、従来技術に属する以下の任意の手段又は他の実施の形態による組み合わせにより実現されてもよい:データ信号の論理的な機能を実現する論理ゲート回路を有する個別論理回路、適切に組み合わせられた論理ゲート回路を有する特定用途向け集積回路、プログラマブルゲートアレイ(PGA)、及びフィールドプログラマブルゲートアレイ(FPGA)等。
【0108】
フローチャートに関する説明又はブロック、或いは他の観点からの任意のプロセス又は方法に関する説明又はブロックは、特定の論理的な機能又は処理におけるステップの実行可能な命令のコードを実現する1つ上のモジュール、セグメント又は部分を含むことを表すように理解され、本発明の実施の形態の範囲は説明したもの以外の実施の形態をも含み、実施の形態による機能は図示又は説明されたものとは異なる方法で実行されてもよく、そのような機能は、説明されたステップを実質的に同時に又は逆の順序で実行する機能も含み、これらも本発明に包含されることが当業者に理解されるべきである。
【0109】
本願においてフローチャートで示された又は他の方法で説明された論理及び/又はステップは、例えば、論理的な機能を実現する実行可能な命令の一連のリストとして理解されてもよく、その命令は、コンピュータで読み取ることが可能な任意の媒体に含まれ、コンピュータ実行システム、デバイス又は装置(例えば、コンピュータを含むシステム、プロセッサを含むシステム、命令実行システム、デバイス又は装置から命令を取得しかつその命令を実行することが可能な他のシステム)により実行され、或いは命令実行システム、デバイス又は装置との組み合わせと共に使用される。
【0110】
上記の文字通りの説明及び図面は本発明に関する様々な特徴を示している。当業者は、ステップの各々を実行するために適切なコンピュータコードを使用し、上述及び図示のように処理を行うことが、理解されるべきである。端末、コンピュータ、サーバ及びネットワークの全てが任意のタイプでよいこと、及び装置を利用することで本発明を実行するように本願に従ってコンピュータコードが用意されてよいことも、理解されるべきである。
【0111】
本願により本発明に関する特定の実施の形態が説明されてきた。当業者は、本発明が他の環境に適用可能であることを当然に認めるであろう。実際、多くの実施の形態及び実現手段が存在する。添付の特許請求の範囲は、本発明の範囲を上記の特定の実施の形態に限定するように解釈されてはならない。更に、「〜する装置」のような何らかの表現は、要素及び請求項を特定する際に装置プラス機能の内容を含み、「装置」という用語が請求項に含まれている場合でさえ「〜する装置」という表現を使用していない任意の要素が装置プラス機能の要素として解釈されることは望まれていない。
【0112】
特定の実施の形態が示されかつ本発明が説明されてきたが、本説明及び図面を参照及び理解すれば、等価な修正例及び変形例が当業者に理解可能であることは明らかである。特に、(部分、構造、装置及び構成物等のような)上記の要素により実行される様々な機能に関し、別段の説明がない限り、それらの要素を説明する用語(「装置」又は「デバイス」を指す用語を含む)は、これらの要素の特定の機能を実行する任意の要素(すなわち、機能的に等価なもの)に対応しており、たとえその要素が構造に関して本発明で説明された実施例又は実施形態の機能を実行するものと異なっていたとしても、そのように対応していることが望ましい。更に、本発明の具体的な特徴が1つ以上の図示の実施形態のみに関して説明されたが、必要に応じて及び所定の又は特定の用途による有利な形態の観点から、そのような特徴は他の実施形態の1つ以上の他の特徴と組み合わせられてもよい。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16