(57)【要約】  パケットデータネットワークにおいて、ソースネットワーク要素（例えば、基地局）がセッションにおいてキャッシングサーバとして働いて端末に向けてコンテンツデータを送信しているときに、ソースネットワーク要素からターゲットネットワーク要素（例えば、基地局）へと端末への接続をハンドオーバするシステム及び方法が説明されている。ハンドオーバ要求が、ソース基地局からターゲット基地局へと送信される。セッションの状態を特定するセッション状態パラメータを含むコンテクストデータメッセージ（例えば、ＣＸＴＰメッセージ）が、ソース基地局からターゲット基地局へと送信される。ターゲット基地局では、セッション状態パラメータが、コンテクストデータメッセージから取り出され、セッションの状態を特定するために使用される。次いで、コンテンツデータパケットが、セッションを続けるようにターゲット基地局から端末へと送信される。
2013505612.tif 000002
【特許請求の範囲】
【請求項１】
パケットデータネットワークの移動端末（２１）へとセッションにおけるキャッシュ済みのデータを送信するためのキャッシングサーバとして働くソースネットワーク要素（１２）であって、
前記ソースネットワーク要素に組み合わせられたキャッシュ記憶ユニット（１２ｃ）に保存されたキャッシュ済みのデータパケット（１２ｄ）の前記端末への提供を制御する制御ユニット（１２１）と、
前記制御ユニットに組み合わせられて、前記セッションの状態を規定するセッション状態パラメータ（１２７）を保存するローカル記憶媒体（１２３）と、
前記キャッシュ済みのデータパケットを前記端末へと送信する通信システム（１２５）と
を備えており、
前記ネットワーク内のターゲットネットワーク要素（１３）によって前記キャッシュ済みのデータパケットを前記同じセッションにおいて前記端末へと送信できるよう、前記制御ユニットが、前記ターゲットネットワーク要素へのハンドオーバの手順を実行し、前記ハンドオーバの手順が、
前記ローカル記憶媒体から前記セッション状態パラメータを取り出すステップと、
前記セッション状態パラメータをコンテクストデータメッセージ（１２８）に挿入するステップと、
前記通信システムを使用して前記コンテクストデータメッセージを前記ターゲットネットワーク要素へと送信するステップと
を含んでいる、ソースネットワーク要素。
【請求項２】
前記通信システム（１２５）が、さらに、前記端末（２１）が前記ターゲットネットワーク要素の範囲内で移動したことを特定し、前記ターゲットネットワーク要素（１３）へとハンドオーバ要求を送信することによって前記ハンドオーバの手順を開始する、請求項１に記載のソースネットワーク要素。
【請求項３】
前記コンテクストデータメッセージ（１２８）がＣＸＴＰデータメッセージである、請求項１又は請求項２に記載のソースネットワーク要素。
【請求項４】
前記制御ユニット（１２１）が、データ提供プロセス（１３１）、キャッシュ状態転送プロセス（１３３）、及びＣＸＴＰプロセス（１３５）を動作させ、前記キャッシュ状態転送プロセスが、前記データ提供プロセスから前記セッション状態パラメータを回復して前記ＣＸＴＰプロセスへと提供し、前記ＣＸＴＰプロセスが、前記パラメータを前記コンテクストデータメッセージへと挿入して前記ターゲットネットワーク要素（１３）へと送信する、請求項３に記載のソースネットワーク要素。
【請求項５】
パケットデータネットワークの移動端末（２１）へとキャッシュ済みのデータを送信するためのキャッシングサーバとして働くターゲットネットワーク要素（１３）であって、
前記ネットワーク要素に組み合わせられたキャッシュ記憶ユニット（１３ｃ）に保存されたキャッシュ済みのデータパケット（１３ｄ）の前記端末への前記提供を制御する制御ユニット（１２２）と、
前記制御ユニットに組み合わせられて、前記セッション状態を規定するセッション状態パラメータ（１２７）を保存するローカル記憶媒体（１２４）と、
前記キャッシュ済みのデータパケットを前記端末へと送信する通信システム（１２６）と
を備えており、
前記ターゲットネットワーク要素が、前記ネットワーク内のソースネットワーク要素（１２）によってそれまで取り扱われていたセッションにおける前記端末への前記キャッシュ済みのデータパケットの送信を続けることができるように、前記制御ユニットが、前記ソースネットワーク要素からのハンドオーバの手順を実行し、前記ハンドオーバの手順が、
前記セッションの状態を規定するセッション状態パラメータを包含するコンテクストデータメッセージ（１２８）を、前記ソースネットワーク要素から前記通信システムで受信するステップと、
前記セッション状態パラメータを前記ローカル記憶媒体へと挿入するステップと、
前記セッション状態パラメータから前記セッションの状態を特定するステップと、
前記特定した状態を使用して、前記端末へと送信すべき前記キャッシュ済みのデータパケットの開始点を特定するステップと
を含む、ターゲットネットワーク要素。
【請求項６】
前記通信システム（１２６）が、さらに、前記ハンドオーバの手順を開始させるために前記ソースネットワーク要素（１２）からハンドオーバ要求を受信する、請求項５に記載のターゲットネットワーク要素。
【請求項７】
前記コンテクストデータメッセージ（１２８）がＣＸＴＰデータメッセージである、請求項５又は請求項６に記載のターゲットネットワーク要素。
【請求項８】
前記制御ユニット（１２２）が、データ提供プロセス（１３２）、キャッシュ状態転送プロセス（１３４）、及びＣＸＴＰプロセス（１３６）を動作させ、前記キャッシュ状態転送プロセスが、前記ＣＸＴＰプロセスから前記セッション状態パラメータを回復して前記データ提供プロセスへと提供し、前記データ提供プロセスが、前記パラメータを前記ローカル記憶媒体へと提供するとともに、前記端末（２１）へのキャッシュ済みのデータパケットの提供を制御する、請求項７に記載のソースネットワーク要素。
【請求項９】
前記キャッシュ記憶ユニット（１２ｃ、１２ｄ）が前記ネットワーク要素に含まれている、請求項１〜８のいずれか一項に記載のネットワーク要素（１２、１３）。
【請求項１０】
基地局である請求項１〜９のいずれか一項に記載のネットワーク要素。
【請求項１１】
前記移動端末（２１）へと送信される前記キャッシュ済みのデータがストリーミングデータである、請求項１〜１０のいずれか一項に記載のネットワーク要素（１２、１３）。
【請求項１２】
前記ストリーミングデータがＨＴＴＰストリーミングデータである、請求項１１に記載のネットワーク要素（１２、１３）。
【請求項１３】
前記パケットがＲＴＰパケットである、請求項１〜１２のいずれか一項に記載のネットワーク要素（１２、１３）。
【請求項１４】
前記パケットデータネットワークが３ＧＰＰ又はＳＡＥ  ＬＴＥネットワークであり、前記ネットワーク要素がｅＮｏｄｅＢである、請求項１〜１３のいずれか一項に記載のネットワーク要素（１２、１３）。
【請求項１５】
パケットデータネットワークにおいて、ソース基地局がセッションにおいてキャッシングサーバとして働いて端末（２１）に向けてコンテンツデータを送信しているときに、前記ソース基地局（１２）からターゲット基地局（１３）へと前記端末への接続をハンドオーバする方法であって、
前記ソース基地局から前記ターゲット基地局へとハンドオーバ要求を送信するステップと、
前記セッションの状態を特定するセッション状態パラメータを含むコンテクストデータメッセージ（１２８）を、前記ソース基地局から前記ターゲット基地局へと送信するステップと、
前記ターゲット基地局において、前記コンテクストデータメッセージから前記セッション状態パラメータを取り出し、前記セッション状態パラメータを使用して前記セッションの状態を特定するステップと、
前記セッションを続けるように、前記ターゲット基地局から前記端末へと前記コンテンツデータパケットを送信するステップと
を含む方法。
【請求項１６】
パケットデータネットワークのソースネットワーク要素（１２）において実行されるコードを含むコンピュータプログラム製品であって、前記コードが、
前記ネットワーク要素に組み合わせられたキャッシュ記憶媒体（１２ｃ）からコンテンツデータパケット（１２ｄ）を取り出し、
セッションにおける前記コンテンツデータパケットを前記ネットワーク内の端末（２１）へと送信し、
前記ネットワーク内のターゲットネットワーク要素へとハンドオーバ要求を送信し、
現在のセッション状態パラメータ（１２７）をコンテクストデータメッセージ（１２８）へと挿入して、前記コンテクストデータメッセージを前記ターゲットネットワーク要素へと送信し、
前記端末への前記コンテンツデータパケットの送信を停止させる
ように動作可能なコンピュータプログラム製品。
【請求項１７】
パケットデータネットワークのターゲットネットワーク要素（１３）において実行されるコードを含むコンピュータプログラム製品であって、前記コードが、
前記ネットワーク内のソースネットワーク要素（１２）からハンドオーバ要求を受信し、
前記ネットワーク内の端末（２１）へのデータ提供セッションのセッション状態パラメータ（１２７）を含むコンテクストデータメッセージ（１２８）を、前記ソースネットワーク要素から受信し、
前記セッション状態パラメータをローカル記憶媒体（１２４）に保存し、
前記セッション状態パラメータを使用して前記データ提供セッションの状態を特定し、
前記データ提供セッション用のコンテンツデータパケット（１３ｄ）であって、前記端末への前記データ提供セッションを中断することなく続けることができるように選択されるコンテンツデータパケットを、前記ネットワーク要素に組み合わせられたキャッシュ記憶媒体から取り出し、
前記データ提供セッションを続けるべく前記端末へと前記コンテンツデータパケットを送信する
ように動作可能なコンピュータプログラム製品。
【請求項１８】
キャリア媒体に担持された請求項１６又は請求項１７に記載のコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モバイルパケットデータネットワークにおいてデータをキャッシュするためのシステムに関する。特に、本発明は、異なる基地局間をローミングするユーザへとデータをストリーミングするために適したキャッシングアーキテクチャに関する。本発明は、これに限られるわけではないが、ビデオオンデマンド（ＶｏＤ）システムにおいてコンテンツをキャッシュするための機構に適用可能である。
【背景技術】
【０００２】
典型的なファイルキャッシング方法は、ファイルサーバからファイルを受信してファイル全体を保存するキャッシュを含んでいる。後にクライアントがファイルを望むときに、ファイルがファイルサーバから提供される代わりに、キャッシュから提供される。キャッシュは、典型的には、クライアントにより近いサーバであり、又はファイルサーバよりも広い帯域幅を有するサーバであるため、ファイルがキャッシュから迅速にクライアントへと提供される。
【０００３】
例えば、ビデオオンデマンド（ＶｏＤ）ファイルなどのストリーミングメディアデータを含んでいるファイルへの典型的なファイルキャッシング方法の適用は、新たな問題につながる可能性がある。ＶｏＤシステムは、一般に、セットトップボックスを通じてコンテンツをストリーミングしてリアルタイムでの鑑賞を可能にするか、あるいはコンテンツをいつでも鑑賞できるようにコンピュータ、デジタルビデオレコーダ、パーソナルビデオレコーダ、又はポータブルメディアプレーヤなどの装置へとダウンロードする。そのようなコンテンツを提供するネットワークによってもたらされるデータは、きわめて大量になる可能性があり、キャッシングがきわめて有用となりうる。
【０００４】
これは、中央のロングテール（ｌｏｎｇ−ｔａｉｌ）サーバへの負荷を低減するために使用される分散キャッシュを備えるＶｏＤシステムの例示的なアーキテクチャの概略図である図１を参照して理解することができる。この例においては、ネットワークが、ペイロードがリアルタイムプロトコル（ＲＴＰ）パケットにてユーザデータグラムプロトコル（ＵＤＰ）を通じて搬送されるリアルタイムストリーミングプロトコル（ＲＴＳＰ）ストリーミングを使用すると仮定することができるが、多数の他のアプリケーション及びプロトコルが、同様のアーキテクチャを有し、同様の問題を抱えると考えられることを理解されよう。
【０００５】
図１のアーキテクチャは、オリジンサーバ１０１といくつかのキャッシュ１０２〜１０６とを有するネットワーク１００を含んでいる。クライアント１０７〜１０９が、オリジンサーバ１０１又はキャッシュ１０２〜１０６からファイル及び／又はストリーミングデータを受信する。クライアントは、ＲＴＰパケットのストリームを構成及び制御するためにＲＴＳＰを使用する。これは、結果として得られるＲＴＰストリームのコーデック、ビットレート、ポートなどのネゴシエーションを含んでいる。ＲＴＳＰにより、クライアントは、ストリーミングを開始及び停止させることが可能であり、あるいはストリームされたメディアクリップの早送り又は巻き戻しを行うことが可能である。
【０００６】
ＲＴＰパケットが、パケットの順番をクライアントに知らせる続き番号を有しつつ、順に送信される。これは、ストリーミングサーバ１０１が、自身が送り出す各々のデータパケットについて維持及び増加させる必要がある状態をプロトコルへと推論する。続き番号は、クライアント１０７〜１０９によってパケットの喪失を検出し、このパケットの喪失をリアルタイムトランスポートコントロールプロトコル（ＲＴＣＰ）を使用してストリーミングサーバへと報告するためにも使用される。
【０００７】
オリジンサーバ１０１の負荷を低減し、提供ネットワーク１００の帯域幅を節約するために、コンテンツの一部が、最終ユーザ１０７〜１０９により近いキャッシュ１０２〜１０６に保存される。これらのキャッシュを、可能な限り最終ユーザの近くにプッシュすることが望ましい。しかしながら、これは、特定の状況において、特にネットワークにモビリティが存在し、クライアントがセッションの最中にあちこち移動することができる場合（基地局間を移動する携帯端末など）に、問題を引き起こす可能性がある。上述の例を使用し、クライアントのうちの１つ（クライアント１０７）が、キャッシュのうちの１つ（キャッシュ１０４）からデータを受信していると仮定する。クライアント１０７が、今や別のキャッシュ１０５からデータを受信するような位置に移動する場合、セッションを中断することなく新たな場所において続けることができるよう、セッション状態などの動的パラメータ（この例では、ＲＴＰパケットの続き番号）を、該当のコンテンツを含んでいても含んでいなくてもよい新たなキャッシュ１０５へと移動させる必要がある。
【０００８】
キャッシングという技術的解決策は、転送ネットワークの負荷を軽減する効果的なやり方であることが示され、ビデオストリーミング用として提案されているが、これらの技術的解決策は、主として公共インターネットアーキテクチャを対象としており、３ＧＰＰネットワークの必要不可欠の要素であるモビリティの問題に対処していない。
【０００９】
システムアーキテクチャエボリューション／ロングタームエボリューション（ＳＡＥ／ＬＴＥ）ネットワークが、ポイントオブプレゼント（ＰｏＰ）の下方のモビリティを提供する。そのようなネットワークにおいては、キャッシングが、基本的に任意の場所に配置することができるが、トラフィックが（モビリティゆえに）ノード間でトンネルされる。キャッシングが基準アーキテクチャへと加えられる場合、トンネルからのトラフィックの出現が、サービングゲートウェイ又は基地局において行われることが好ましく、あるいはキャッシュがＰｏＰの上方に配置され、すなわちオペレータのＩＰサービスネットワーク内に配置されることが好ましい。これは、キャッシュにおけるアプリケーション状態を、キャッシュ間のハンドオーバで移動させなければならないことを意味し、きわめて複雑な状態転送を意味する。
【００１０】
ロングタームエボリューション（ＬＴＥ）は、第３世代パートナーシッププロジェクト（３ＧＰＰ）によって現在開発中の通信ネットワーク技術である。ＬＴＥは、ネットワークの容量を改善し、ネットワークの待ち時間を低減し、結果としてエンドユーザの体験を改善するように設計されたエボルブドユニバーサルテレストリアル無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）と呼ばれる新たな無線アクセス技術を必要とする。システムアーキテクチャエボリューション（ＳＡＥ）は、ＬＴＥ通信ネットワークのためのコアネットワークアーキテクチャである。
【００１１】
図２を参照すると、ＬＴＥ／ＳＡＥアーキテクチャが、シグナリングの制御を担当するモビリティ管理エンティティ（ＭＭＥ）２４を備えている。ＳＡＥゲートウェイ（ＳＡＥ−ＧＷ）が、ユーザデータを担当する。ＳＡＥ−ＧＷは、２つの異なる部分で構成され、すなわちユーザデータパケットを回送するサービングゲートウェイ２５と、ユーザデバイスと外部データネットワーク（ＩＰＴＶ２８及びＩＭＳ２９などのサービスを提供すべくオペレータが配置されるネットワーク２７など）との間の接続を提供するＰＤＮゲートウェイ２６とで構成される。これらのノードは、３ＧＰＰ技術仕様書（ＴＳ）２３．４０１に詳しく記載されている。これらのノードはすべて、ＩＰネットワークによって互いに接続されている。さらなるノードは、ネットワークにおいて基地局として働くｅＮｏｄｅＢ２２、２３である。ポリシー／課金ルール機能（ＰＣＲＦ）３０が、サービスの流れを検出し、課金ポリシーを行使する。これらの種類のノードの間に、３つの主要なプロトコル及びインターフェイスが存在する。これらは、Ｓ１−ＭＭＥ（ｅＮｏｄｅＢ２２、２３とＭＭＥ２４との間）、Ｓ１−Ｕ（ｅＮｏｄｅＢ２２、２３とＳＡＥ−ＧＷ２５との間、又はより正確にはｅＮｏｄｅＢ２２、２３とサービングゲートウェイとの間）、及びＸ２（ｅＮｏｄｅＢ２２、２３の間）である。これらのインターフェイスにおいて使用される対応のプロトコルは、Ｓ１ＡＰ（Ｓ１アプリケーションプロトコル）及びＸ２ＡＰ（Ｘ２アプリケーションプロトコル）である。これらのプロトコル及びインターフェイスはすべて、ＩＰに基づいている。加えて、ネットワークは、例えばホームｅＮｏｄｅＢとネットワークの残りのノードとの間のホームｅＮｏｄｅＢゲートウェイ（図２には示されていない）など、上述のインターフェイスの一部である他のノードを包含することができる。現時点において、モビリティは、ＰＤＮ  ＳＡＥ  ＧＷ２６の下方でもたらされている。
【００１２】
モビリティがどのようにキャッシュに影響を及ぼすのかを検討する前に、携帯端末２１がソースｅＮｏｄｅＢ（ｅＮＢ）２２からターゲットｅＮＢ２３へと移動する場合のＳＡＥ／ＬＴＥネットワークにおけるハンドオーバの手順を検討することが有益である。３ＧＰＰ  ＴＳ３６．３００によれば、ハンドオーバの手順は、エボルブドパケットコア（ＥＰＣ）の関与なしで実行され、すなわち準備メッセージがｅＮＢ２２、２３の間で直接交換される。ハンドオーバの完了段階におけるソース側のリソースの解放は、ソースｅＮＢ２２によってトリガされる。図３が、ＭＭＥ２４及びサービングゲートウェイ２５のいずれも換わらずにソースｅＮＢ２２からターゲットｅＮＢ２３へと移動する端末２１について、基本的なハンドオーバの筋書きを示している。図３に示されているステップは、以下のとおりである。
【００１３】
Ｓ０：ソースｅＮＢ２２におけるＵＥコンテクストが、接続の確立又は最後のＴＡ更新においてもたらされたローミング制限に関する情報を含んでいる。
Ｓ１：ソースｅＮＢ２２が、エリア制限情報に従って端末２１の測定手順を設定する。ソースｅＮＢ２２によってもたらされる測定が、端末の接続のモビリティを制御する機能を助けることができる。
Ｓ２：端末２１が、例えばシステム情報、仕様などによって設定されるルールによって測定報告（ＭＥＡＳＵＲＥＭＥＮＴ  ＲＥＰＯＲＴ）を送信するようにトリガされる。
Ｓ３：ソースｅＮＢ２２が、ＭＥＡＳＵＲＥＭＥＮＴ  ＲＥＰＯＲＴ及びＲＰＭ情報に基づいて端末２１をハンドオフする決定を行う。
Ｓ４：ソースｅＮＢ２２が、ターゲットｅＮＢ２３へとハンドオーバ要求（ＨＡＮＤＯＶＥＲ  ＲＥＱＵＥＳＴ）メッセージを発し、ターゲット側でのハンドオーバの準備に必要な情報（ソースｅＮＢにおけるＵＥ  Ｘ２シグナリングコンテクストリファレンス、ＵＥ  Ｓ１  ＥＰＣシグナリングコンテクストリファレンス、ターゲットセルＩＤ、ＫｅＮＢ＊、ソースｅＮＢにおける端末のＣ−ＲＮＴＩを含むＲＲＣコンテクスト、ＡＳ設定（物理層の設定を除く）、ソースセルのＥ−ＲＡＢコンテクスト及び物理層ＩＤ、ならびに考えられるＲＬＦ回復のためのＭＡＣ）を渡す。ＵＥ  Ｘ２／ＵＥ  Ｓ１シグナリングリファレンスにより、ターゲットｅＮＢ２３は、ソースｅＮＢ２２及びＥＰＣをアドレスすることができる。Ｅ−ＲＡＢコンテクストは、必要なＲＮＬ及びＴＮＬのアドレシング情報、ならびにＥ−ＲＡＢのＱｏＳプロフィルを含んでいる。
Ｓ５：リソースをターゲットｅＮＢ２２によって与えることができる場合に、ハンドオーバの成功の可能性を高めるために、アドミッション制御を、受信されたＥ−ＲＡＢ  ＱｏＳ情報に依存しているターゲットｅＮＢ２３によって実行することができる。ターゲットｅＮＢ２３が、受信されたＥ−ＲＡＢ  ＱｏＳ情報に従って必要とされるリソースを設定し、Ｃ−ＲＮＴＩを予約し、随意によりＲＡＣＨプレアンブルを予約する。ターゲットセルにおいて使用されるべきＡＳ設定を別個独立に指定（すなわち、「確立」）することができ、又はソースセルにおいて使用されたＡＳ設定と比べた差分として指定（すなわち、「再設定」）することができる。
Ｓ６：ターゲットｅＮＢ２３が、Ｌ１／Ｌ２によってハンドオーバを準備し、ハンドオーバ要求の受領確認（ＨＡＮＤＯＶＥＲ  ＲＥＱＵＥＳＴ  ＡＣＫＮＯＷＬＥＤＧＥ）をソースｅＮＢ２２へと送信する。ＨＡＮＤＯＶＥＲ  ＲＥＱＵＥＳＴ  ＡＣＫＮＯＷＬＥＤＧＥメッセージは、ハンドオーバを実行するためのＲＲＣメッセージとして端末２１へと送信されるトランスペアレントなコンテナを含んでいる。コンテナは、新たなＣ−ＲＮＴＩ及び選択されたセキュリティアルゴリズムに関するターゲットｅＮＢセキュリティアルゴリズム識別子を含み、専用のＲＡＣＨプレアンブルを含むことができ、おそらくは何らかの他のパラメータ、すなわちアクセスパラメータ、ＳＩＢなどを含むことができる。ＨＡＮＤＯＶＥＲ  ＲＥＱＵＥＳＴ  ＡＣＫＮＯＷＬＥＤＧＥメッセージは、必要であれば、転送トンネルのためのＲＮＬ／ＴＮＬ情報をさらに含むことができる。
【００１４】
ソースｅＮＢ２２がＨＡＮＤＯＶＥＲ  ＲＥＱＵＥＳＴ  ＡＣＫＮＯＷＬＥＤＧＥを受信し、又はハンドオーバコマンドの送信がダウンリンクにおいて開始されるや否や、データの転送を開始することができる。
【００１５】
ステップＳ７〜Ｓ１６が、ハンドオーバの際のデータの喪失を回避するための手段を提供し、３ＧＰＰ  ＴＳ３６．３００においてさらに詳しく検討されている。
Ｓ７：ソースｅＮＢ２２が、ハンドオーバを実行するためのＲＲＣメッセージを生成し、すなわち端末２１へのモビリティ制御情報（ｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ）を含むＲＲＣ接続設定変更（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを生成する。ソースｅＮＢ２２が、メッセージについて必要な完全性保護及び暗号化を実行する。端末２１が、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを必要なパラメータ（すなわち、新たなＣ−ＲＮＴＩ、ターゲットｅＮＢセキュリティアルゴリズム識別子、及び随意による専用のＲＡＣＨプレアンブル、ターゲットｅＮＢ  ＳＩＢなど）とともに受信し、ソースｅＮＢ２２によってハンドオーバを実行するように指令される。端末は、ソースｅＮＢ２２へとＨＡＲＱ／ＡＲＱ応答を提供するためにハンドオーバの実行を遅延させる必要がない。
Ｓ８：ソースｅＮＢ２２は、ＰＤＣＰステータス保存が適用される（すなわち、ＲＬＣ  ＡＭのための）Ｅ−ＲＡＢのアップリンクＰＤＣＰ  ＳＮレシーバステータス及びダウンリンクＰＤＣＰ  ＳＮトランスミッタステータスを伝えるべく、ＳＮステータス転送（ＳＮ  ＳＴＡＴＵＳ  ＴＲＡＮＳＦＥＲ）メッセージをターゲットｅＮＢ２３へと送信する。アップリンクＰＤＣＰ  ＳＮレシーバステータスは、第１の欠けているＵＬ  ＳＤＵの少なくともＰＤＣＰ  ＳＮを含んでおり、端末がターゲットセルにおける再送信を必要とする順番誤りＵＬ  ＳＤＵの受信状態のビットマップを、そのようなＳＤＵが存在する場合に含むことができる。ダウンリンクＰＤＣＰ  ＳＮトランスミッタステータスは、ターゲットｅＮＢがＰＤＣＰ  ＳＮを未だ有していない新たなＳＤＵへと割り当てるべき次のＰＤＣＰ  ＳＮを指示する。ソースｅＮＢ２２は、端末２１のいかなるＥ−ＲＡＢもＰＤＣＰステータス保存によって取り扱われるべきでない場合には、このメッセージの送信を省略することができる。
Ｓ９：ｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎを含むＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージの受信後に、端末２１は、ターゲットｅＮＢ２３への同期を実行し、専用のＲＡＣＨプレアンブルがハンドオーバ指令（ＨＡＮＤＯＶＥＲ  ＣＯＭＭＡＮＤ）に割り当てられている場合には競合なしの手順に従い、専用のプレアンブルが割り当てられていない場合には競合に基づく手順に従って、ＲＡＣＨを介してターゲットセルにアクセスする。端末２１が、ターゲットｅＮＢの特有のキーを導出し、ターゲットセルにおいて使用されるべき選択されたセキュリティアルゴリズムを設定する。
Ｓ１０：ネットワークが、ＵＬの割り当て及びタイミングアドバンスによって応答する。
Ｓ１１：端末２１は、ターゲットセルへのアクセスに成功したとき、端末についてハンドオーバの手順が完了したことを知らせるために、ハンドオーバを確認するためのＲＲＣ接続設定変更完了（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージ（Ｃ−ＲＮＴＩ）を、アップリンクバッファステータス報告（ｕｐｌｉｎｋ  Ｂｕｆｆｅｒ  Ｓｔａｔｕｓ  Ｒｅｐｏｒｔ）とともに、ターゲットｅＮＢへと可能ならばいつでも送信する。ターゲットｅＮＢ２３は、ハンドオーバ確認（ＨＡＮＤＯＶＥＲ  ＣＯＮＦＩＲＭ）メッセージにおいて送信されたＣ−ＲＮＴＩを検証する。ターゲットｅＮＢ２３は、今や端末２１へのデータの送信を始めることができる。
Ｓ１２：ターゲットｅＮＢ２３が、経路切換（ＰＡＴＨ  ＳＷＩＴＣＨ）メッセージをＭＭＥ２４へと送信し、端末２１がセルを変更したことを知らせる。
Ｓ１３：ＭＭＥ２４が、ユーザプレーン更新要求（ＵＳＥＲ  ＰＬＡＮＥ  ＵＰＤＡＴＥ  ＲＥＱＵＥＳＴ）メッセージをサービングゲートウェイ２５へと送信する。
Ｓ１４：サービングゲートウェイ２５が、ダウンリンクデータ経路をターゲット側へと切り換える。サービングゲートウェイ２５が、ソースｅＮＢ２２へと古い経路にて１つ又は複数の「終了マーカ」パケットを送信し、次いでＵプレーン／ＴＮＬリソースをソースｅＮＢに向けて解放することができる。
Ｓ１５：サービングゲートウェイ２５が、ユーザプレーン更新応答（ＵＳＥＲ  ＰＬＡＮＥ  ＵＰＤＡＴＥ  ＲＥＳＰＯＮＳＥ）メッセージをＭＭＥ２４へと送信する。
Ｓ１６：ＭＭＥ２４が、経路切換受領確認（ＰＡＴＨ  ＳＷＩＴＣＨ  ＡＣＫ）メッセージによって経路切換メッセージを確認する。
Ｓ１７：ＵＥコンテクスト解放（ＵＥ  ＣＯＮＴＥＸＴ  ＲＥＬＥＡＳＥ）を送信することによって、ターゲットｅＮＢ２３が、ソースｅＮＢ２２にハンドオーバの成功を知らせ、リソースの解放をトリガする。ターゲットｅＮＢ２３は、ＰＡＴＨ  ＳＷＩＴＣＨ  ＡＣＫメッセージがＭＭＥ２４から受信された後にこのメッセージを送信する。
Ｓ１８：ＵＥ  ＣＯＮＴＥＸＴ  ＲＥＬＥＡＳＥメッセージを受信すると、ソースｅＮＢ２２は、ＵＥコンテクストに関する無線及びＣプレーン関連のリソースを解放することができる。
【００１６】
ＳＡＥ／ＬＴＥネットワークアーキテクチャの場合に、ユーザのモビリティが、ネットワークへの付着点の変化を生じさせ、以下の問題を引き起こす。
・モビリティゆえのセッションの移転。キャッシュがモビリティのアンカ点の下方で使用される（すなわち、ユーザがキャッシュからキャッシュへと移動する）場合、アプリケーション状態をキャッシュ内に有する複雑さが、ハンドオフの際に複雑さを生成する。
・ポリシー制御とのやり取り。主たる問題の１つは、ストリーミングサーバなどのアプリケーションノードが、ＱｏＳの使用を制御するためにポリシー課金ルール機能（ＰＣＲＦ）とやり取りしなければならない点にある。しかしながら、ＰＣＲＦは、ＥＰＣアーキテクチャにおいてはアンカ点よりも上方に配置され、これがアンカ点よりも下方のキャッシュに対し問題を引き起こす。
・スケーラビリティ。ペイロードの中央集中型の生成ゆえに、高処理能力のノードが必要であり、より多くのトラフィックを生成する必要がある場合に拡大が難しいことが問題である。
【００１７】
このように、モバイルネットワークにおけるハンドオーバが、分散した一式のキャッシュの間でのアプリケーション状態の複雑な転送を生じさせることが理解できよう。ロバストなキャッシングの技術的解決策は、ＳＡＥ／ＬＴＥアーキテクチャの基地局間でセッション状態を転送するための上手く設計された柔軟な技術的解決策を必要とする。
【発明の概要】
【発明が解決しようとする課題】
【００１８】
本発明の目的は、上述の欠点の少なくとも一部を取り除くことにある。
【００１９】
オリジンサーバが端末へのストリームの提供をネットワークのエッジに配置されたキャッシュへと委任するハンドオーバの際に、ＵＤＰベースのストリーミングプロトコルにおいてストリーミングのセッション状態を維持することが望ましいと考えられる。
【課題を解決するための手段】
【００２０】
本発明の一態様によれば、パケットデータネットワークの移動端末へとセッションにおいてキャッシュ済みのデータを送信するためのキャッシングサーバとして働く「ソース」ネットワーク要素が提供される。このソースネットワーク要素は、ソースネットワーク要素に組み合わせられたキャッシュ記憶ユニットに保存されたキャッシュ済みのデータパケットの端末への提供を制御する制御ユニットを備えている。ローカル記憶媒体が、制御ユニットに組み合わせられ、セッションの状態を規定するセッション状態パラメータを保存する。さらに、このソースネットワーク要素は、キャッシュ済みのデータパケットをネットワーク内の端末へと送信する通信システムを備えている。ターゲットネットワーク要素によってキャッシュ済みのデータパケットを同じセッションにおいて端末へと送信できるよう、制御ユニットが、ネットワークのターゲットネットワーク要素へのハンドオーバの手順を実行する。このハンドオーバの手順が、ローカル記憶媒体からセッション状態パラメータを取り出すステップと、セッション状態パラメータをコンテクストデータメッセージに挿入するステップと、通信システムを使用してコンテクストデータメッセージをターゲットネットワーク要素へと送信するステップとを含んでいる。
【００２１】
このように、コンテクストメッセージをターゲットネットワーク要素へと送信することによって、フラットなキャッシングアーキテクチャを機能させ、キャッシングサーバとして働いているネットワーク要素間の親切な状態転送を可能にすることができる。
【００２２】
通信システムは、端末がターゲットネットワーク要素の範囲内で移動したことを特定した後で、ターゲットネットワーク要素へとハンドオーバ要求を送信することによってハンドオーバの手順を開始させるようにさらに構成することができる。
【００２３】
コンテクストデータメッセージは、ＣＸＴＰデータメッセージであってもよい。
【００２４】
制御ユニットは、データ提供プロセス、キャッシュ状態転送プロセス、及びＣＸＴＰプロセスを動作させることができる。キャッシュ状態転送プロセスは、データ提供プロセスからセッション状態パラメータを取り出し、ＣＸＴＰプロセスへと提供することができ、ＣＸＴＰプロセスは、パラメータをコンテクストデータメッセージへと挿入してターゲットネットワーク要素へと送信することができる。
【００２５】
本発明の別の態様によれば、パケットデータネットワークの移動端末へとキャッシュ済みのデータを送信するためのキャッシングサーバとして働く「ターゲット」ネットワーク要素が提供される。このターゲットネットワーク要素は、ネットワーク要素に組み合わせられたキャッシュ記憶ユニットに保存されたキャッシュ済みのデータパケットの端末への提供を制御する制御ユニットを備えている。ローカル記憶媒体が、制御ユニットに組み合わせられ、セッションの状態を規定するセッション状態パラメータを保存する。さらに、ターゲットネットワーク要素は、キャッシュ済みのデータパケットを端末へと送信する通信システムを備える。制御ユニットが、ターゲットネットワーク要素によってネットワーク内のソースネットワーク要素によってそれまで取り扱われていたセッションにおける端末へのキャッシュ済みのデータパケットの送信を続けることができるよう、ソースネットワーク要素からのハンドオーバの手順を実行する。このハンドオーバの手順が、セッションの状態を規定するセッション状態パラメータを含んでいるコンテクストデータメッセージを、通信システムでソースネットワーク要素から受信するステップと、セッション状態パラメータをローカル記憶媒体へと挿入するステップと、セッション状態パラメータからセッションの状態を特定するステップと、特定した状態を使用して、端末へと送信すべきキャッシュ済みのデータパケットの開始点を特定するステップとを含んでいる。
【００２６】
通信システムは、ハンドオーバの手順を開始させるためにソースネットワーク要素からハンドオーバ要求を受信するようにさらに構成することができる。
【００２７】
コンテクストデータメッセージは、ＣＸＴＰデータメッセージであってもよい。
【００２８】
制御ユニットは、データ提供プロセス、キャッシュ状態転送プロセス、及びＣＸＴＰプロセスを動作させることができる。キャッシュ状態転送プロセスは、ＣＸＴＰプロセスからセッション状態パラメータを回復し、データ提供プロセスへと提供することができ、データ提供プロセスは、パラメータをローカル記憶媒体へと提供するとともに、端末へのキャッシュ済みのデータパケットの提供を制御することができる。
【００２９】
ネットワーク要素は、上述に規定のとおりの「ターゲット」及び「ソース」の両方のネットワーク要素として働くことができることが理解できるであろう。いずれの場合も、キャッシュ記憶ユニットは、ネットワーク要素に含まれてもよい。ネットワーク要素は、基地局であってもよい。
【００３０】
移動端末へと送信されるキャッシュ済みのデータは、ストリーミングデータ、例えばＨＴＴＰストリーミングデータであってもよい。
【００３１】
パケットは、ＲＴＰパケットであってもよい。
【００３２】
パケットデータネットワークは、３ＧＰＰ又はＳＡＥ  ＬＴＥネットワークであってもよく、ネットワーク要素が、ｅＮｏｄｅＢであってもよい。
【００３３】
本発明の別の態様によれば、パケットデータネットワークにおいて、ソース基地局がセッションにおいてキャッシングサーバとして働いて端末へとコンテンツデータを送信しているときに、ソース基地局からターゲット基地局へと端末への接続をハンドオーバする方法が提供される。ハンドオーバ要求が、ソース基地局からターゲット基地局へと送信される。セッションの状態を特定するセッション状態パラメータを含んでいるコンテクストデータメッセージが、ソース基地局からターゲット基地局へと送信される。ターゲット基地局において、セッション状態パラメータが、コンテクストデータメッセージから取り出され、セッションの状態を特定するために使用される。次いで、コンテンツデータパケットが、セッションを続けるようにターゲット基地局から端末へと送信される。
【００３４】
本発明の別の態様によれば、パケットデータネットワークのソースネットワーク要素において実行されるコードを含んでいるコンピュータプログラム製品が提供される。コードが、ネットワーク要素に組み合わせられたキャッシュ記憶媒体からコンテンツデータパケットを取り出し、コンテンツデータパケットをセッションにおいてネットワーク内の端末へと送信し、ネットワーク内のターゲットネットワーク要素へとハンドオーバ要求を送信し、現在のセッション状態パラメータをコンテクストデータメッセージへと挿入するとともに、コンテクストデータメッセージをターゲットネットワーク要素へと送信し、端末へとコンテンツデータパケットの送信を停止させるように動作可能である。
【００３５】
本発明のさらなる態様によれば、パケットデータネットワークのターゲットネットワーク要素において実行されるコードを含んでいるコンピュータプログラム製品が提供される。コードが、ネットワーク内のソースネットワーク要素からハンドオーバ要求を受信し、ネットワーク内の端末へのデータ提供セッションのセッション状態パラメータを含んでいるコンテクストデータメッセージを、ソースネットワーク要素から受信し、セッション状態パラメータをローカル記憶媒体に保存し、セッション状態パラメータを使用してデータ提供セッションの状態を特定し、データ提供セッション用のコンテンツデータパケットであって、端末へのデータ提供セッションを中断なく続けることができるように選択されるコンテンツデータパケットを、ネットワーク要素に組み合わせられたキャッシュ記憶媒体から取り出し、データ提供セッションを続けるべく端末へとコンテンツデータパケットを送信する働きをする。
【００３６】
さらに、本発明は、上述のいずれかのプログラムを担持するキャリア媒体を含む。
【００３７】
次に、いくつかの好ましい実施形態を、添付の図面を参照しつつあくまでも例として説明する。
【図面の簡単な説明】
【００３８】
【図１】ネットワークアーキテクチャの概略図である。
【図２】ＬＴＥ／ＳＡＥネットワークの概略図である。
【図３】ＬＴＥ／ＳＡＥネットワークにおけるハンドオーバの手順を説明するシーケンス図である。
【図４】Ａ及びＢは、ＣＸＴＰメッセージの交換を説明するシーケンス図である。
【図５】コンテクスト転送要求（ＣＴ−Ｒｅｑ）のコンテンツを示している。
【図６】コンテクスト転送データ（ＣＴＤ）メッセージのコンテンツを示している。
【図７】コンテクストデータブロック（ＣＤＢ）のコンテンツを示している。
【図８】ＣＸＴＰにおいて予想されるＣＤＢにおけるＳＣＴＰペイロードデータチャンクを示している。
【図９】ＨＴＴＰストリーミングの動作の概略図である。
【図１０】図２のＬＴＥ／ＳＡＥネットワークの概略図であり、考えられるキャッシュの配置を示している。
【図１１】キャッシュコンテクストの転送を含むハンドオーバの手順を説明するシーケンス図である。
【図１２】ハンドオーバの際にキャッシュコンテクストを転送するソースｅＮｏｄｅＢ及びターゲットｅＮｏｄｅＢの概略図である。
【図１３】キャッシュ状態の転送において実行される動作を説明するシーケンス図である。
【発明を実施するための形態】
【００３９】
セッションパラメータの維持に関する原理を理解するために、例示的な実施形態が、ＬＴＥネットワークに関して説明される。この実施形態が、あくまでも例として提示されているにすぎず、同じ手法が、他のネットワークアーキテクチャ及び通信プロトコルに使用できることが理解されよう。さらに、ＲＴＳＰの使用が説明されるが、任意の他のＵＤＰベースのストリーミングプロトコル（例えば、ＭＰＥＧトランスポートストリーム（ＭＰＥＧ  ＴＳ））又はセッションにおけるデータ（例えば、大きなファイル）の伝送を制御する任意の他のプロトコルも使用可能である。
【００４０】
フラットモビリティアーキテクチャがＩＥＴＦにおいて提案されており、そこではネットワークのエッジが「アクセスルータ」と称されている。これらのルータは、組み込みのエアインターフェイスを有すると仮定され、ＳＡＥ／ＬＴＥの観点からは、一体化されたＳＡＥ／ＬＴＥノードとしてモデル化することができる。しかしながら、ＲＦＣ  ４０６７の主たる焦点は、エッジルータ間の状態転送プロトコルを規定することにあり、モビリティによって開始されるノード間の状態の転送のためのコンテナとして使用することができる。ＲＦＣの用語は、「先のアクセスルータ（ｐＡＲ）」と「次のアクセスルータ（ｎＡＲ）」との間の転送を指す。これらは、図２及び３に示したソースｅＮＢ２２及びターゲットｅＮＢ２３に相当する。
【００４１】
図４Ａ及び４Ｂが、コンテクスト（ＣＴ）トリガ４４への応答におけるＵＥ４１、ｐＡＲ４２、及びｎＡＲ４３の間のやり取りのシーケンス図の例である。図４Ａにおいては、ＣＴトリガがｐＡＲ４２によって受信され、図４Ｂにおいては、トリガがｎＡＲ４３によって受信される。ＵＥ４１、ｐＡＲ４２、及びｎＡＲ４３は、図２及び３に示したＵＥ２１、ソースｅＮＢ２２、及びターゲットｅＮＢ２３であってもよく、ＣＴトリガ４４は、図２に関してＳ３、Ｓ４で説明したハンドオーバの開始のメッセージ又は決定であってもよい。ステップは以下のとおりである。
【００４２】
Ｓ４１：ＣＴトリガ４４がｎＡＲ４３において開始される場合、コンテクスト転送要求（Ｃｏｎｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｒｅｑｕｅｓｔ（ＣＴ−Ｒｅｑ））メッセージが、コンテクストの転送の開始を要求するべくｎＡＲによってｐＡＲへと送信される。このメッセージは、コンテクストアクティベート（Ｃｏｎｔｅｘｔ  Ａｃｔｉｖａｔｅ（ＣＴＡＲ））メッセージへの応答として送信される。ＭＮの先のＩＰアドレスに続くフィールドが、ＣＴＡＲメッセージから文字どおりに含まれる。
Ｓ４２：コンテクスト転送データメッセージ（ＣＴＤ）が、ｐＡＲ４２からｎＡＲ４３へと送信され、特徴データ（ＣＸＴＰデータ）を含んでいる。このメッセージは、予測及び通常の両方のコンテクストを取り扱う。このメッセージに含まれる受領確認フラグ「Ａ」が、ｐＡＲ４２が応答を必要としているかどうかを示している。
Ｓ４３：ＣＴＡＲメッセージが、ＵＥ４１からｎＡＲ４３へと送信される。ＣＴＡＲメッセージは、ｎＡＲ４３のＩＰアドレス、ｐＡＲ４２におけるＵＥ４１  ＭＮのＩＰアドレス、転送すべき特徴コンテクストのリスト（初期設定では、すべてのコンテクストの転送が要求される）、及び転送を承認するトークンを提供する。
Ｓ４４：ＣＴＤ応答（ＣＴＤＲ）メッセージが、ｎＡＲ４３からｐＡＲ４２へと送信される。
【００４３】
ＣＴ−Ｒｅｑメッセージ（ステップＳ４１を参照）が、図５に示されており、以下のとおりのフィールドを含んでいる。
バージョン．５１：ＣＸＴＰプロトコルのバージョン番号＝０ｘ１。
種類５２：ＣＴＲＥＱ＝０ｘ７（コンテクスト転送要求）。
「Ｖ」フラグ５３：「０」に設定されたとき、ＩＰｖ６アドレスであり、「１」に設定されたとき、ＩＰｖ４アドレスである。
予備５４：送信者によってゼロに設定され、受信者によって無視される。
長さ５５：オクテット（ｏｃｔｅｔ）を単位とするメッセージ長。
ＵＥの先のＩＰアドレスフィールド５６：ＩＰｖ４［ＲＦＣ７９１］アドレス（４オクテット）、又はＩＰｖ６［ＲＦＣ３５１３］アドレス（１６オクテット）のいずれかを含む。
続き番号５７：ＣＴＡＲメッセージからコピーされ、ｐＡＲが要求を以前に送信されたコンテクストから区別することを可能にする。
ＵＥの承認トークン５８：偽造不可能（ｕｎｆｏｒｇｅａｂｌｅ）な値である。ＣＴＡＲの受信者がコンテクストの転送を行うことを承認する。ＣＴＡＲからコピーされる。
コンテクストデータ要求ブロック５９：コンテクストデータの要求ブロック。
【００４４】
ＣＴＤメッセージ（ステップＳ４２を参照）が、図６に示されており、以下のとおりのフィールドを含んでいる。
バージョン．５１：ＣＸＴＰプロトコルのバージョン番号＝０ｘ１。
種類６２：ＣＴＤ＝０ｘ３（コンテクスト転送データ）であり、ＰＣＴＤ＝０ｘ４（予測コンテクスト転送データ）である。
「Ｖ」フラグ５３：「０」に設定されたとき、ＩＰｖ６アドレスであり、「１」に設定されたとき、ＩＰｖ４アドレスである。
「Ａ」ビット６３：設定されたとき、ｐＡＲが受領確認を要求している。
長さ６５：オクテット（ｏｃｔｅｔ）を単位とするメッセージ長。
経過時間６６：このＭＮのための最初のＣＴＤメッセージの送信からのミリ秒数。
ＵＥの先のＩＰアドレスフィールド６７：ＩＰｖ４［ＲＦＣ７９１］アドレス（４オクテット）、又はＩＰｖ６［ＲＦＣ３５１３］アドレス（１６オクテット）のいずれかを含む。
コンテクストデータブロック６８、６９：後述。
【００４５】
コンテクストデータブロック（ＣＤＢ）６８、６９が、図７に示されており、以下のフィールドを含んでいる。
特徴プロフィルタイプ７１：１６ビットの整数であり、ＩＡＮＡによって割り当てられ、データフィールドに含まれるデータの種類を示している。
長さ７５：８オクテットワードを単位とするメッセージ長。
「Ｐ」ビット７６：０＝存在ベクトルなしであり、１＝存在ベクトルが存在する。
予備７７：将来の使用のための予備。送信者によってゼロに設定される。
データ７８：コンテクストの種類に依存するデータ。長さは、長さフィールドによって規定される。データが６４ビットに合わせられていない場合、データフィールドはゼロで埋められる。
【００４６】
特徴プロフィルタイプ（ＦＰＴ）コード７１が、データフィールド７８のデータの種類を示している。典型的には、この特徴プロフィルタイプ（ＦＰＴ）コード７１はコンテクストデータであるが、エラー表示であってもよい。「Ｐ」ビット７６は、「存在ベクトル」７９が使用されるかどうかを指定する。存在ベクトル７９が使用されている場合、「Ｐ」ビット７６は、特定のデータフィールドが存在するかどうか（及び、初期設定の値でない値を含んでいるかどうか）を示している。存在ベクトル７９におけるビットの順序は、コンテクストタイプの指定によるデータフィールドの順序と同じであり、データフィールドのサイズにかかわらずにデータフィールドごとに１ビットである。長さフィールド７５は、ＦＰＴ７１から始まる最初の４オクテットを含むＣＤＢ６８のサイズを８オクテットワードで示している。
【００４７】
コンテクストデータブロック６８の長さが、コンテクストタイプの仕様によって指定される各々のデータフィールド７８の長さに、「Ｐ」ビットが設定されている場合に４オクテットを加え、初期設定値として、暗黙裏に与えられるすべてのコンテクストデータの累積サイズを引き算した合計によって定められることに留意されたい。
【００４８】
ＣＸＴＰの展開が、ルータ間インターフェイスにおける転送プロトコルとしてストリーム制御トランスポートプロトコル（Ｓｔｒｅａｍ  Ｃｏｎｔｒｏｌ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ（ＳＣＴＰ））を使用すべきであることも決定されている。ＳＣＴＰは、輻輳制御、フラグメンテーション、及びプログラマブルな再送信タイマーに基づく部分的な再送信をサポートする。したがって、図７に示されるペイロードデータ７８は、図８に示されるとおりのフォーマットを有し、そのフィールドは以下のとおりである。
「Ｕ」ビット８１：オーダされていない（ｕｎｏｒｄｅｒｅｄ）ビット。１に設定されなければならない。
「Ｂ」ビット８２：始まりのフラグメントビット。
「Ｅ」ビット８３：終わりのフラグメントビット。
ＴＳＮ８４：送信続き番号。
ストリーム識別子Ｓ８５：コンテクストトランスファプロトコルストリームを特定する。
ストリーム続き番号ｎ８６：「Ｕ」ビットが１に設定されるため、受信者はこの数を無視する。
ペイロードプロトコル識別子８７：「ＣＸＴＰ」に設定される。
ユーザデータ８８：コンテクストトランスファプロトコルメッセージを包含する。
【００４９】
現在の業界の傾向は、ＨＴＴＰがビデオストリームを取り出すために使用されるということに向いている。これは、プログレッシブダウンロードの一変種である。主たる特徴は、元のビデオファイルが基本的には小さな個々のファイルであるセグメント又はチャンクへと分解され、これらがクライアントによって１つの大きなファイルの代わりにダウンロードされる。
【００５０】
この種の機構の発展の主たる理由は、ＲＴＳＰ／ＲＴＰプロトコルがファイアウォール及びＮＡＴにおける問題を抱えており、したがってインターネット上のプロトコルによるストリーミングが必ずしも常に可能ではないということに起因する。ＨＴＴＰはポート８０を使用し、このポートがすべてのウェブトラフィックによって使用されるがゆえに開いているため、ファイアウォール及びＮＡＴの横断における問題が存在しない。そのようなコンテンツのキャッシングが可能になり、また、重要な点は、スタートよりウェブコンテンツ（ＨＴＴＰによってフェッチされるファイル）のキャッシングが意図されているため、キャッシングインフラストラクチャ（ＣＤＮとして知られる）を変更する必要がない点にある。これは、既存のＣＤＮインフラストラクチャを容易に再使用できることを意味する。
【００５１】
傾向を、Ｍｏｖｅ  Ｎｅｔｗｏｒｋｓ、Ｍｉｃｒｏｓｏｆｔ、及びＡｐｐｌｅの活動に見て取ることができる。Ｍｏｖｅ  Ｎｅｔｗｏｒｋｓは、ＨＴＴＰを介してメディアの時間チャンクをフェッチすることによってストリーミングを提供するアダプティブストリーム（Ａｄａｐｔｉｖｅ  Ｓｔｒｅｅｍ）（ｈｔｔｐ：／／ｗｗｗ．ｍｏｖｅｎｅｔｗｏｒｋｓ．ｃｏｍ／ｍｏｖｅ−ｍｅｄｉａ−ｓｅｒｖｉｃｅｓ／ｍｏｖｅ−ａｄａｐｔｉｖｅ−ｓｔｒｅａｍｉｎｇ）と呼ばれる技術的解決策を有している。この技術的解決策は、ストリームの品質のオンザフライでの調整を可能にする。オンデマンド及びライブの両方のストリーミングがサポートされている。
【００５２】
Ｍｉｃｒｏｓｏｆｔは、Ｍｏｖｅ  Ｎｅｔｗｏｒｋｓに類似しているがＩＳＯファイルに基づいているスムースストリーミング（Ｓｍｏｏｔｈ  Ｓｔｒｅａｍｉｎｇ）（ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｄｏｗｎｌｏａｄｓ／ｄｅｔａｉｌｓ．ａｓｐｘ？ｄｉｓｐｌａｙｌａｎｇ＝ｅｎ＆ＦａｍｉｌｙｌＤ＝０３ｄ２２５８３−３ｅｄ６−４４ｄａ−８４６４−ｂ１ｂ４ｂ５ｃａ７５２０）を導入している。重要な対象は、ＭｉｃｒｏｓｏｆｔのＡｋａｍａｉとの協働である。ＡｋａｍａｉのグローバルＣＤＮが、後により短い待ち時間で提供されて最終ユーザのビデオ再生体験を改善するチャンクをキャッシュするために使用されている。
【００５３】
Ａｐｐｌｅは、ｉＰｈｏｎｅへのＨＴＴＰライブストリーミングを導入している。ＩＥＴＦの草案（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｎｔｅｍｅｔ−ｄｒａｆｔｓ／ｄｒａｆｔ−ｐａｎｔｏｓ−ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｍｉｎｇ−０１．ｔｘｔ）が、この技術的解決策を説明している。これは、Ｍｏｖｅ  Ｎｅｔｗｏｒｋｓに類似しているが、ＭＰＥＧ−２トランスポートストリームに基づいている。
【００５４】
図９は、どのようにＨＴＴＰチャンクに基づくストリーミングがクライアント９１とサーバ９２との間で働くかについての概要を示している。コンテンツ（ライブ又は保存済みである）が、特定の時間長のファイルへとチャンクされる。クライアントが、基本的には時間間隔をそれぞれのリンクへとマッピングするリストである「マニフェスト」をダウンロードすることによって、サーバとのやり取りを開始する。ライブのコンテンツにおいては、マニフェストが動的に更新される必要がある。「マニフェスト」ファイルがＰ２Ｐにおいて使用される「トレント（ｔｏｒｒｅｎｔ）」ファイルに、本来類似していることが、興味深い。
【００５５】
上述のように、ネットワークにおけるモビリティが、現時点においてＰＤＮ−ＧＷ２６に配置されるポイントオブプレゼント（ＰｏＰ）の下方で提供される。キャッシングは、原理的には任意の場所に配置することができるが、トラフィックは、（モビリティゆえに）ノード間をトンネルされる。キャッシングが基準アーキテクチャへと加えられる場合、トンネルからのトラフィックの出現が、サービングＳＡＥ−ＧＷ、又はｅＮｏｄｅＢにおいて行われることが好ましく、あるいはキャッシュがＰｏＰの上方に配置され、すなわちオペレータのＩＰサービスネットワーク内に配置されることが好ましい。
【００５６】
これが、図２のネットワークアーキテクチャに類似したネットワークアーキテクチャ１０を示している図１０に示されている。両方のアーキテクチャにおいて同じであるエンティティは、同じ参照番号を有している。図１０のアーキテクチャにおいて、キャッシュ記憶媒体１２ｃ、１３ｃ、１５ｃをｅＮｏｄｅＢ１２、１３、及び／又はサービングＳＡＥ  ＧＷ１５のそれぞれに組み合わせることができ、これらのネットワーク要素がキャッシュサーバとして働くことができる。さらに図１０は、オペレータが属するネットワーク２７に組み合わせられた記憶媒体１８ｃを示している。
【００５７】
これは、キャッシュサーバにおけるアプリケーション（すなわち、ＲＴＳＰ状態）の状態を、キャッシュサーバ（ｅＮｏｄｅＢ１２、１３／ＳＡＥ  ＧＷ１５）間のハンドオーバにおいて移動させなければならないことを意味する。
【００５８】
アンカ点の下方にキャッシュされることが知られているコンテンツについては、トラフィックの大部分であるｕｓｅｒ＿ｐｌａｎｅ  ＲＴＰペイロードが、クライアント２１に近い（すなわち、ＳＡＥ−ＧＷ４５又はｅＮｏｄｅＢ１２、１３内の）キャッシュサーバによって生成される。このアーキテクチャにおいては、アプリケーション依存性が最小限になり、セッション制御だけを中央に集中させればよいため、アプリケーションサーバが、改善されたスループットスケーラビリティを有するであろう。上述のように、ロバストなキャッシングの技術的解決策は、基地局間でセッション状態を転送するための柔軟な技術的解決策を必要とする。
【００５９】
コンテクストトランスファプロトコル（ＣＸＴＰ）が、技術的解決策を提供するが、種々の転送プロトコルをその現在の形態にてサポートする機能を欠いている。ＣＸＴＰは、エッジルータ間の状態転送プロトコルであり、モビリティによって開始される状態のノード間での転送のためのコンテナとして使用することができる。しかしながら、このプロトコルは、モビリティに起因するキャッシング状態の転送を提供するようには設計されていなかった。具体的には、特定の特徴コンテンツについてデータがオーガナイズされるやり方を特定する特徴プロフィルタイプ（ＦＰＴ）７１が、ノードがプロトコルメッセージに存在するコンテクストの種類及びコンテクストパラメータを曖昧さなく決定することを可能にする。ＲＦＣ４０６７が、ＳＣＴＰについてどのようにコンテクストの転送が行われるのかについての例を提供しているが、キャッシュされたデータのコンテクストの転送のための手段は提供していない。
【００６０】
２つのキャッシュサーバ間のハンドオーバの状態を転送するために、ＣＸＴＰメッセージが交換される。例えば、図２及び３に示されているソースｅＮＢ２２及びターゲットｅＮＢ２３を考える。ハンドオーバの決定がなされ（ステップＳ３）、ハンドオーバ要求が送信及び受領確認（Ｓ４及びＳ６）されるとき、ＣＸＴＰメッセージが同時に交換される。これが、追加のステップＳ１１６（ＣＴ−Ｒｅｑ）、及びＳ１１８（ＣＴＤ）を含む点を除いて図２と同一である図１１に示されている。
【００６１】
ターゲットｅＮＢ２３は、ハンドオーバ要求を受信（Ｓ４）し、アドミッション制御を実行（Ｓ５）するとき、上述のようにハンドオーバ要求受領確認ステップ（Ｓ６）を送信する。さらに、ターゲットｅＮＢ２３は、ソースｅＮＢ２２にセッション状態情報の提供を要求するために、別のＣＴ−ＲｅｑメッセージＳ１１６を送信する。ソースｅＮＢ２２が、この情報を提供するＣＴＤメッセージＳ１１８によって応答する。
【００６２】
ＣＸＴＰメッセージは、図５及び６に関して上述したものと同様である。転送されるべき状態情報は、図６及び７に示したとおりのコンテクストデータブロック（ＣＤＢ）６８、６９に含まれる。
【００６３】
ＣＤＢ６８において、ＦＰＴフィールド７１が、転送されるコンテクストがキャッシュデータに関係するものである旨の表示を含んでいる。これは、ＲＦＣ４０６７には含まれていない新規なプロフィルタイプである。データ７８自身は、ＳＣＴＰペイロードデータチャンクではないが、代わりに、アプリケーション（例えば、ＨＴＴＰ）の状態を規定する一式のパラメータである。
【００６４】
（上述のような）チャンクベースのＨＴＴＰストリーミングが使用されている場合、ＣＤＢ６８のデータ部分のデータ７８は、最後に送り出されたチャンク及び現在の解像度のインジケータ（例えば、ＳＤ、ＨＤなど）である。次いで、ターゲットｅＮＢ２３は、現在のネットワーク状態に最もよく適合する解像度によって、次に続くチャンクからストリーミングを続ける。
【００６５】
図１２は、図１０に示したソースｅＮｏｄｅＢ及びターゲットｅＮｏｄｅＢと同様であり、ＣＸＴＰプロトコルを使用してキャッシュ状態情報を交換するソースｅＮｏｄｅＢ１２及びターゲットｅＮｏｄｅＢ１３の概略図である。各々のｅＮｏｄｅＢ１２、１３が、制御ユニット１２１、１２２及びローカル記憶媒体１２３、１２４を含んでおり、コンテンツ（例えば、ＲＴＰパケット、ＨＴＴＰチャンク）１２ｄ、１３ｄであらかじめ満たされた  キャッシュ記憶媒体１２ｃ、１３ｃ（図１０にも示されているとおり）に組み合わせられている。
【００６６】
さらに、各々のｅＮｏｄｅＢ１２、１３は、それぞれのキャッシュ記憶媒体、他のｅＮｏｄｅＢ、ならびにネットワーク内の上流及び下流のノードと通信するための通信システム１２５、１２６を備えている。
【００６７】
端末（例えば、図１０に示されている端末２１）にソースｅＮｏｄｅＢ１２によってキャッシュされたデータが送信されている状況を考える。ソースｅＮｏｄｅＢ１２の制御ユニット１２１が、通信システム１２５に対して、キャッシュ済みのデータ１２ｄを関連のキャッシュ記憶媒体１２ｃから取り出して端末２１へと転送するように指示する。セッション状態パラメータ１２７が、ローカル記憶媒体１２３に保存される。これらのセッション状態パラメータは、セッションの状態を規定しており、例えばＨＴＴＰベースのストリーミングにおけるＲＴＳＰ続き番号又はチャンク識別子を含むことができる。この手法がデータのストリーミングだけに当てはまるのではなく、大きなファイルをより小さなチャンクでＴＣＰセッションにおいて転送することができ、セッション状態パラメータ１２７が、どのチャンクが送信済みであり、どのチャンクが未送信であるかを規定することができることが理解されよう。また、キャッシュ記憶媒体１２ｃが、（図１２に示されているように）別のエンティティであっても、あるいはｅＮｏｄｅＢ１２の一部であってもよく、後者の場合には、通信システム１２５を使用することなく、キャッシュされたデータ１２ｄをキャッシュ記憶媒体１２ｃから回復することができることが理解されよう。
【００６８】
端末２１がターゲットｅＮｏｄｅＢ１３の範囲内で移動する場合、担当がソースｅＮｏｄｅＢ１２からターゲットｅＮｏｄｅＢ１３へとハンドオーバされる。ハンドオーバの手順の一部として（図３にて説明したハンドオーバメッセージに加えて）、制御ユニット１２１が、ローカル記憶媒体１２３からセッション状態パラメータ１２７を取り出し、それをＣＸＴＰ  ＣＴＤメッセージ１２８へとカプセル化し、ＣＴＤメッセージ１２８をターゲットｅＮｏｄｅＢ１３の通信システムへと送信するように通信システム１２５に対して指示する。セッション状態パラメータは、図６及び７に示したコンテクストデータブロック６８、６９に含まれる。
【００６９】
ターゲットｅＮｏｄｅＢ１３の通信システム１２６が、ＣＴＤメッセージ１２８を受信する。制御ユニット１２２が、セッション状態パラメータを取り出し、それらをローカル記憶媒体１２４に保存する。これは、ターゲットｅＮｏｄｅＢ１３の通信システム１２６に、ひとたびハンドオーバが完了した場合に、端末２１へと正しい点から出発するキャッシュ済みのデータを送信すべく、該当のキャッシュ記憶媒体１３ｄから正しいデータ１３ｄを引き出すために必要な情報をもたらす。
【００７０】
図１３は、ソースｅＮｏｄｅＢ１２からターゲットｅＮｏｄｅＢ１３へとＣＴＤメッセージ１２８を送信するためのｅＮｏｄｅＢ１２、１３の制御ユニット１２１、１２２内の論理ブロックの動作を示すシーケンス図である。各々の制御ユニット１２１、１２２が、ＲＴＳＰプロセス１３１、１３２（又は、ＨＴＴＰプロセスなど）、キャッシュ状態転送モジュール１３３、１３４、及びＣＸＴＰプロセス１３５を動作させる。
【００７１】
制御ユニットは、キャッシュ状態転送モジュールによる現在の状態の取込み及び照会を可能にするＧＥＴ／ＳＥＴ動作をサポートすべきである。パラメータを交換する新たなクラスが、ＣＸＴＰプロセスに存在すべきである。クラスの実現の例は、以下のとおりである。
class CXTP_Exchange
{
List state_params;  // list of parameters
state_params GET(); // Get function
SET(state_params);   // Set function
}
state_ params GET()
{
return parameters from CDB 
}
SET(state_params)
{
populate CXTP CDB with parameters
}      
【００７２】
２つの代案が、ＲＴＳＰプロセスアプリケーションについて可能である。１つの代案においては、ＲＴＳＰソフトウェアを、新たなリード／ライト関数をサポートするように変更しなければならない。
class RSTP_Exchange
{
List state_params;         // list of parameters
state_params Read();      // Read function
Write(state_params);       // Write function
}
state_params Read()
{
return specified parameters from RTSP process state 
}
Write(state_params)
{
populate RTSP process state with parameters 
}
【００７３】
他の代案においては、ＲＴＳＰサーバを動作させるオペレーティングシステムのメモリが走査され、ＲＴＳＰプロセスの現在の状態がコピーされる。これは、ＲＴＳＰプロセスが明確に定義された時間間隔の定常状態にあるときに行われるべきである。
class RSTP_Exchange
{
List state_params;               // list of parameters
state_params ScanMem();         // Read function
PopulateMem(state_params); // Write function
}
state_params ScanMem()
{
suspend process at time T
scan memory used by RTSP process state and extract values
insert values into ‘parameters’ list
return ‘parameters’
}
PopulateMem(state_params)
{
interrupt RTTP process
populate RTSP process state with values from ‘parameters’ 
return RTSP process from interrupt
}      
【００７４】
したがって、図１３において、ステップは以下のとおりである。
Ｓ１３１：ソースｅＮｏｄｅＢ１２の制御ユニット１２１のキャッシュ状態転送モジュール１３３が、ＲＴＳＰプロセス状態１３１に対してセッション状態パラメータ（ローカル記憶媒体１２３に保存されている）を返すように指示する。
Ｓ１３２：パラメータがキャッシュ状態転送モジュールへと送信される。
Ｓ１３３：キャッシュ状態転送モジュール１３３が、パラメータをＣＸＴＰプロセス１３５へと提供する。
Ｓ１３４：ソースｅＮｏｄｅＢ１２のＣＸＴＰプロセス１３５が、パラメータを包含するＣＤＢを生成する。これが、ターゲットｅＮｏｄｅＢ１３のＣＸＴＰプロセス１３６へとｅＮｏｄｅＢの通信システム１２５、１２６を介して送信される。
Ｓ１３５：ターゲットｅＮｏｄｅＢ１３の制御ユニット１２２のキャッシュ状態転送モジュール１３４が、ＣＸＴＰプロセス１３６に対してセッション状態パラメータを送信するように指示する。
Ｓ１３６：パラメータが、キャッシュ状態転送モジュールへと送信される。
Ｓ１３７：パラメータが、ターゲットｅＮｏｄｅＢのＲＴＳＰプロセス１３２へと書き込まれる。次いで、それらをローカル記憶媒体に保存することができ、また、正しいキャッシュ済みのデータがターゲットｅＮｏｄｅＢ１３から端末２１へと送信されることを保証するために使用することができる。したがって、ひとたびハンドオーバが完了すると、ＲＴＳＰプロセス１３２が、正しい場所からストリーミング（又は、ファイルの送信）を開始することができる。
【００７５】
上述のシステムはＲＴＳＰプロセスに関して説明されているが、同じ手法が、ストリーミングＨＴＴＰ又はＴＣＰによる大きなファイルなど、他のデータの提供においても同様に機能することが理解されよう。
【００７６】
通信システム１２５、１２６及び制御ユニット１２１、１２２が、別々のエンティティとして示されているが、実際には同じ又は異なるプロセッサによって機能させることができることが理解されよう。さらには、それらをハードウェアによって機能させても、ソフトウェアによって機能させてもよい。ソフトウェアによって機能させられる場合には、一方又は両方が、ユニットに対して必要な動作の実行を指示するコンピュータプログラム製品を含めて、プロセッサとメモリとを含むことができる。
【００７７】
上述の手法は、ＬＴＥのｅＮｏｄｅＢ間でのキャッシュ状態情報の移送のために既存の状態転送プロトコル（ＣＸＴＰ）を再利用することを可能にする。標準化されたＩＥＴＦプロトコルを使用することで、標準化されたオープンなインターフェイスの生成が促進される。
【００７８】
さらに、この手法は、アプリケーションパラメータの一式をメモリから取り出し、ストリーミングプロトコル（例えば、チャンクベースのＨＴＴＰ）のためのＣＸＴＰにカプセル化することを可能にする。
【００７９】
この考え方は、中央集中型のキャッシングアーキテクチャと比べ、よりスケーラブルであるフラットなキャッシングアーキテクチャを可能にする。また、この手法は、標準的な転送機構の改変を提案しないが、各々のキャッシュに配置されたストリーミングサーバ間での丁寧な状態転送を可能にし、そのすべてをＩＥＴＦの方法を使用して展開することができる。
【００８０】
以上の説明は、キャッシングが有益となりうる１つの状況について述べているが、同じ原理を適用することができる多数の他の事例が存在することが理解されよう。例えば、同様のキャッシングプロセスを、ＵＤＰによるＲＴＰ、及びＴＣＰによるＨＴＴＰを使用するＶｏＤに適用することができる。データは、必ずしもストリーミングデータでなくてもよい。このプロセスを、長いＴＣＰセッションが作動している場合にも使用することができる。さらに、このプロセスを、ＬＴＥに加えて、２Ｇ及び３Ｇのネットワークにも使用することができる。そのような状況においては、上述のＬＴＥのユニットと同等のユニットが使用されることが理解されよう。例えば、基地局は、上述のようなｅＮｏｄｅＢでなく、該当のネットワークアーキテクチャが充当されるであろう。
【図１】
2013505612.tif 000003
【図２】
2013505612.tif 000004
【図３】
2013505612.tif 000005
【図４】
2013505612.tif 000006
【図５】
2013505612.tif 000007
【図６】
2013505612.tif 000008
【図７】
2013505612.tif 000009
【図８】
2013505612.tif 000010
【図９】
2013505612.tif 000011
【図１０】
2013505612.tif 000012
【図１１】
2013505612.tif 000013
【図１２】
2013505612.tif 000014
【図１３】
2013505612.tif 000015
【手続補正書】
【提出日】平成23年6月28日(2011.6.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
パケットデータネットワークの移動端末（２１）へとセッションにおけるキャッシュ済みのデータを送信するためのキャッシングサーバとして働くソースネットワーク要素（１２）であって、
前記ソースネットワーク要素に組み合わせられたキャッシュ記憶ユニット（１２ｃ）に保存されたキャッシュ済みのデータパケット（１２ｄ）の前記端末への提供を制御する制御ユニット（１２１）と、
前記制御ユニットに組み合わせられて、前記セッションの状態を規定するセッション状態パラメータ（１２７）を保存するローカル記憶媒体（１２３）と、
前記キャッシュ済みのデータパケットを前記端末へと送信する通信システム（１２５）と
を備えており、
前記ネットワーク内のターゲットネットワーク要素（１３）によって、当該ターゲットネットワーク要素に組み合わせられた別のキャッシュ記憶ユニット（１３ｃ）に保存済みのキャッシュ済みデータパケットを、前記同じセッションにおいて前記端末へと送信できるよう、前記制御ユニットが、前記ターゲットネットワーク要素へのハンドオーバの手順を実行し、前記ハンドオーバの手順が、
前記ローカル記憶媒体から前記セッション状態パラメータを取り出すステップと、
前記セッション状態パラメータを、当該パラメータがキャッシュ済みデータに関連していることを示す表示と共にコンテクストデータメッセージ（１２８）に挿入するステップと、
前記通信システムを使用して前記コンテクストデータメッセージを前記ターゲットネットワーク要素へと送信するステップと
を含んでいる、ソースネットワーク要素。
【請求項２】
前記通信システム（１２５）が、さらに、前記端末（２１）が前記ターゲットネットワーク要素の範囲内で移動したことを特定し、前記ターゲットネットワーク要素（１３）へとハンドオーバ要求を送信することによって前記ハンドオーバの手順を開始する、請求項１に記載のソースネットワーク要素。
【請求項３】
前記コンテクストデータメッセージ（１２８）がＣＸＴＰデータメッセージである、請求項１又は請求項２に記載のソースネットワーク要素。
【請求項４】
前記制御ユニット（１２１）が、データ提供プロセス（１３１）、キャッシュ状態転送プロセス（１３３）、及びＣＸＴＰプロセス（１３５）を動作させ、前記キャッシュ状態転送プロセスが、前記データ提供プロセスから前記セッション状態パラメータを回復して前記ＣＸＴＰプロセスへと提供し、前記ＣＸＴＰプロセスが、前記パラメータを前記コンテクストデータメッセージへと挿入して前記ターゲットネットワーク要素（１３）へと送信する、請求項３に記載のソースネットワーク要素。
【請求項５】
パケットデータネットワークの移動端末（２１）へとキャッシュ済みのデータを送信するためのキャッシングサーバとして働くターゲットネットワーク要素（１３）であって、
前記ネットワーク要素に組み合わせられたキャッシュ記憶ユニット（１３ｃ）に保存されたキャッシュ済みのデータパケット（１３ｄ）の前記端末への前記提供を制御する制御ユニット（１２２）と、
前記制御ユニットに組み合わせられて、前記セッション状態を規定するセッション状態パラメータ（１２７）を保存するローカル記憶媒体（１２４）と、
前記キャッシュ済みのデータパケットを前記端末へと送信する通信システム（１２６）と
を備えており、
前記ターゲットネットワーク要素が、前記ネットワーク内のソースネットワーク要素（１２）によってそれまで取り扱われていたセッションにおける前記端末への前記キャッシュ済みのデータパケットの送信を続けることができるように、前記制御ユニットが、前記ソースネットワーク要素からのハンドオーバの手順を実行し、前記ハンドオーバの手順が、
前記セッションの状態を規定するセッション状態パラメータを包含するコンテクストデータメッセージ（１２８）を、当該パラメータがキャッシュ済みデータに関連していることを示す表示と共に前記ソースネットワーク要素から前記通信システムで受信するステップと、
前記セッション状態パラメータを前記ローカル記憶媒体へと挿入するステップと、
前記セッション状態パラメータから前記セッションの状態を特定するステップと、
前記特定した状態を使用して、前記端末へと送信すべき、前記キャッシュ記憶ユニット（１３ｃ）に保存済みの前記キャッシュ済みデータパケットの開始点を特定するステップと
を含む、ターゲットネットワーク要素。
【請求項６】
前記通信システム（１２６）が、さらに、前記ハンドオーバの手順を開始させるために前記ソースネットワーク要素（１２）からハンドオーバ要求を受信する、請求項５に記載のターゲットネットワーク要素。
【請求項７】
前記コンテクストデータメッセージ（１２８）がＣＸＴＰデータメッセージである、請求項５又は請求項６に記載のターゲットネットワーク要素。
【請求項８】
前記制御ユニット（１２２）が、データ提供プロセス（１３２）、キャッシュ状態転送プロセス（１３４）、及びＣＸＴＰプロセス（１３６）を動作させ、前記キャッシュ状態転送プロセスが、前記ＣＸＴＰプロセスから前記セッション状態パラメータを回復して前記データ提供プロセスへと提供し、前記データ提供プロセスが、前記パラメータを前記ローカル記憶媒体へと提供するとともに、前記端末（２１）へのキャッシュ済みのデータパケットの提供を制御する、請求項７に記載のソースネットワーク要素。
【請求項９】
前記キャッシュ記憶ユニット（１２ｃ、１２ｄ）が前記ネットワーク要素に含まれている、請求項１〜８のいずれか一項に記載のネットワーク要素（１２、１３）。
【請求項１０】
基地局である請求項１〜９のいずれか一項に記載のネットワーク要素。
【請求項１１】
前記移動端末（２１）へと送信される前記キャッシュ済みのデータがストリーミングデータである、請求項１〜１０のいずれか一項に記載のネットワーク要素（１２、１３）。
【請求項１２】
前記ストリーミングデータがＨＴＴＰストリーミングデータである、請求項１１に記載のネットワーク要素（１２、１３）。
【請求項１３】
前記パケットがＲＴＰパケットである、請求項１〜１２のいずれか一項に記載のネットワーク要素（１２、１３）。
【請求項１４】
前記パケットデータネットワークが３ＧＰＰ又はＳＡＥ  ＬＴＥネットワークであり、前記ネットワーク要素がｅＮｏｄｅＢである、請求項１〜１３のいずれか一項に記載のネットワーク要素（１２、１３）。
【請求項１５】
パケットデータネットワークにおいて、ソース基地局がセッションにおいてキャッシングサーバとして働いて端末（２１）に向けてコンテンツデータを送信しているときに、前記ソース基地局（１２）からターゲット基地局（１３）へと前記端末への接続をハンドオーバする方法であって、
前記ソース基地局から前記ターゲット基地局へとハンドオーバ要求を送信するステップと、
前記セッションの状態を特定するセッション状態パラメータを含むコンテクストデータメッセージ（１２８）を、当該パラメータがキャッシュ済みデータに関連していることを示す表示と共に、前記ソース基地局から前記ターゲット基地局へと送信するステップと、
前記ターゲット基地局において、前記コンテクストデータメッセージから前記セッション状態パラメータを取り出し、前記セッション状態パラメータを使用して前記セッションの状態を特定するステップと、
前記ターゲット基地局に組み合わせられたキャッシュ記憶ユニット（１３ｃ）から前記コンテンツデータパケットを取り出すステップと、
前記セッションを続けるように、前記ターゲット基地局から前記端末へと前記コンテンツデータパケットを送信するステップと
を含む方法。
【請求項１６】
パケットデータネットワークのソースネットワーク要素（１２）において実行されるコードを含むコンピュータプログラム製品であって、前記コードが、
前記ネットワーク要素に組み合わせられたキャッシュ記憶媒体（１２ｃ）からコンテンツデータパケット（１２ｄ）を取り出し、
セッションにおける前記コンテンツデータパケットを前記ネットワーク内の端末（２１）へと送信し、
前記ネットワーク内のターゲットネットワーク要素へとハンドオーバ要求を送信し、
現在のセッション状態パラメータ（１２７）を、当該パラメータがキャッシュ済みデータに関連していることを示す表示と共にコンテクストデータメッセージ（１２８）へと挿入して、前記ターゲットネットワーク要素によって、当該ターゲットネットワーク要素に組み合わせられた別のキャッシュ記憶ユニット（１３ｃ）に保存済みのキャッシュ済みデータパケットを、前記同じセッションにおいて前記端末へと送信できるよう、前記コンテクストデータメッセージを前記ターゲットネットワーク要素へと送信し、
前記端末への前記コンテンツデータパケットの送信を停止させる
ように動作可能なコンピュータプログラム製品。
【請求項１７】
パケットデータネットワークのターゲットネットワーク要素（１３）において実行されるコードを含むコンピュータプログラム製品であって、前記コードが、
前記ネットワーク内のソースネットワーク要素（１２）からハンドオーバ要求を受信し、
前記ネットワーク内の端末（２１）へのデータ提供セッションのセッション状態パラメータ（１２７）を含むコンテクストデータメッセージ（１２８）を、当該パラメータがキャッシュ済みデータに関連していることを示す表示と共に前記ソースネットワーク要素から受信し、
前記セッション状態パラメータをローカル記憶媒体（１２４）に保存し、
前記セッション状態パラメータを使用して前記データ提供セッションの状態を特定し、
前記データ提供セッション用のコンテンツデータパケット（１３ｄ）であって、前記端末への前記データ提供セッションを中断することなく続けることができるように選択されるコンテンツデータパケットを、前記ネットワーク要素に組み合わせられたキャッシュ記憶媒体から取り出し、
前記データ提供セッションを続けるべく前記端末へと前記コンテンツデータパケットを送信する
ように動作可能なコンピュータプログラム製品。
【請求項１８】
キャリア媒体に担持された請求項１６又は請求項１７に記載のコンピュータプログラム製品。
【手続補正書】
【提出日】平成24年11月19日(2012.11.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
パケットデータネットワークの移動端末（２１）へとセッションにおけるキャッシュ済みのデータを送信するためのキャッシングサーバとして働くソースネットワーク要素（１２）であって、
前記ソースネットワーク要素に組み合わせられたキャッシュ記憶ユニット（１２ｃ）に保存されたキャッシュ済みのデータパケット（１２ｄ）の前記端末への提供を制御する制御ユニット（１２１）と、
前記制御ユニットに組み合わせられて、前記セッションの状態を規定するセッション状態パラメータ（１２７）を保存するローカル記憶媒体（１２３）と、
前記キャッシュ済みのデータパケットを前記端末へと送信する通信システム（１２５）と
を備えており、
前記ネットワーク内のターゲットネットワーク要素（１３）によって、当該ターゲットネットワーク要素に組み合わせられた別のキャッシュ記憶ユニット（１３ｃ）に保存済みのキャッシュ済みデータパケットを、前記同じセッションにおいて前記端末へと送信できるよう、前記制御ユニットが、前記ターゲットネットワーク要素へのハンドオーバの手順を実行し、前記ハンドオーバの手順が、
前記ローカル記憶媒体から前記セッション状態パラメータを取り出すステップと、
前記セッション状態パラメータを、当該パラメータがキャッシュ済みデータに関連していることを示す表示と共にコンテクストデータメッセージ（１２８）に挿入するステップと、
前記通信システムを使用して前記コンテクストデータメッセージを前記ターゲットネットワーク要素へと送信するステップと
を含んでいる、ソースネットワーク要素。
【請求項２】
前記通信システム（１２５）が、さらに、前記端末（２１）が前記ターゲットネットワーク要素の範囲内で移動したことを特定し、前記ターゲットネットワーク要素（１３）へとハンドオーバ要求を送信することによって前記ハンドオーバの手順を開始する、請求項１に記載のソースネットワーク要素。
【請求項３】
前記コンテクストデータメッセージ（１２８）がＣＸＴＰデータメッセージである、請求項１又は請求項２に記載のソースネットワーク要素。
【請求項４】
前記制御ユニット（１２１）が、データ提供プロセス（１３１）、キャッシュ状態転送プロセス（１３３）、及びＣＸＴＰプロセス（１３５）を動作させ、前記キャッシュ状態転送プロセスが、前記データ提供プロセスから前記セッション状態パラメータを回復して前記ＣＸＴＰプロセスへと提供し、前記ＣＸＴＰプロセスが、前記パラメータを前記コンテクストデータメッセージへと挿入して前記ターゲットネットワーク要素（１３）へと送信する、請求項３に記載のソースネットワーク要素。
【請求項５】
パケットデータネットワークの移動端末（２１）へとキャッシュ済みのデータを送信するためのキャッシングサーバとして働くターゲットネットワーク要素（１３）であって、
前記ネットワーク要素に組み合わせられたキャッシュ記憶ユニット（１３ｃ）に保存されたキャッシュ済みのデータパケット（１３ｄ）の前記端末への前記提供を制御する制御ユニット（１２２）と、
前記制御ユニットに組み合わせられて、前記セッション状態を規定するセッション状態パラメータ（１２７）を保存するローカル記憶媒体（１２４）と、
前記キャッシュ済みのデータパケットを前記端末へと送信する通信システム（１２６）と
を備えており、
前記ターゲットネットワーク要素が、前記ネットワーク内のソースネットワーク要素（１２）によってそれまで取り扱われていたセッションにおける前記端末への前記キャッシュ済みのデータパケットの送信を続けることができるように、前記制御ユニットが、前記ソースネットワーク要素からのハンドオーバの手順を実行し、前記ハンドオーバの手順が、
前記セッションの状態を規定するセッション状態パラメータを包含するコンテクストデータメッセージ（１２８）を、当該パラメータがキャッシュ済みデータに関連していることを示す表示と共に前記ソースネットワーク要素から前記通信システムで受信するステップと、
前記セッション状態パラメータを前記ローカル記憶媒体へと挿入するステップと、
前記セッション状態パラメータから前記セッションの状態を特定するステップと、
前記特定した状態を使用して、前記端末へと送信すべき、前記キャッシュ記憶ユニット（１３ｃ）に保存済みの前記キャッシュ済みデータパケットの開始点を特定するステップと
を含む、ターゲットネットワーク要素。
【請求項６】
前記通信システム（１２６）が、さらに、前記ハンドオーバの手順を開始させるために前記ソースネットワーク要素（１２）からハンドオーバ要求を受信する、請求項５に記載のターゲットネットワーク要素。
【請求項７】
前記コンテクストデータメッセージ（１２８）がＣＸＴＰデータメッセージである、請求項５又は請求項６に記載のターゲットネットワーク要素。
【請求項８】
前記制御ユニット（１２２）が、データ提供プロセス（１３２）、キャッシュ状態転送プロセス（１３４）、及びＣＸＴＰプロセス（１３６）を動作させ、前記キャッシュ状態転送プロセスが、前記ＣＸＴＰプロセスから前記セッション状態パラメータを回復して前記データ提供プロセスへと提供し、前記データ提供プロセスが、前記パラメータを前記ローカル記憶媒体へと提供するとともに、前記端末（２１）へのキャッシュ済みのデータパケットの提供を制御する、請求項７に記載のソースネットワーク要素。
【請求項９】
前記キャッシュ記憶ユニット（１２ｃ、１２ｄ）が前記ネットワーク要素に含まれている、請求項１〜８のいずれか一項に記載のネットワーク要素（１２、１３）。
【請求項１０】
基地局である請求項１〜９のいずれか一項に記載のネットワーク要素。
【請求項１１】
前記移動端末（２１）へと送信される前記キャッシュ済みのデータがストリーミングデータである、請求項１〜１０のいずれか一項に記載のネットワーク要素（１２、１３）。
【請求項１２】
前記ストリーミングデータがＨＴＴＰストリーミングデータである、請求項１１に記載のネットワーク要素（１２、１３）。
【請求項１３】
前記パケットがＲＴＰパケットである、請求項１〜１２のいずれか一項に記載のネットワーク要素（１２、１３）。
【請求項１４】
前記パケットデータネットワークが３ＧＰＰ又はＳＡＥ  ＬＴＥネットワークであり、前記ネットワーク要素がｅＮｏｄｅＢである、請求項１〜１３のいずれか一項に記載のネットワーク要素（１２、１３）。
【請求項１５】
パケットデータネットワークにおいて、ソース基地局がセッションにおいてキャッシングサーバとして働いて端末（２１）に向けてコンテンツデータを送信しているときに、前記ソース基地局（１２）からターゲット基地局（１３）へと前記端末への接続をハンドオーバする方法であって、
前記ソース基地局から前記ターゲット基地局へとハンドオーバ要求を送信するステップと、
前記セッションの状態を特定するセッション状態パラメータを含むコンテクストデータメッセージ（１２８）を、当該パラメータがキャッシュ済みデータに関連していることを示す表示と共に、前記ソース基地局から前記ターゲット基地局へと送信するステップと、
前記ターゲット基地局において、前記コンテクストデータメッセージから前記セッション状態パラメータを取り出し、前記セッション状態パラメータを使用して前記セッションの状態を特定するステップと、
前記ターゲット基地局に組み合わせられたキャッシュ記憶ユニット（１３ｃ）から前記コンテンツデータパケットを取り出すステップと、
前記セッションを続けるように、前記ターゲット基地局から前記端末へと前記コンテンツデータパケットを送信するステップと
を含む方法。
【請求項１６】
パケットデータネットワークのソースネットワーク要素（１２）において実行されるコードを含むコンピュータプログラムであって、前記コードが、
前記ネットワーク要素に組み合わせられたキャッシュ記憶媒体（１２ｃ）からコンテンツデータパケット（１２ｄ）を取り出し、
セッションにおける前記コンテンツデータパケットを前記ネットワーク内の端末（２１）へと送信し、
前記ネットワーク内のターゲットネットワーク要素へとハンドオーバ要求を送信し、
現在のセッション状態パラメータ（１２７）を、当該パラメータがキャッシュ済みデータに関連していることを示す表示と共にコンテクストデータメッセージ（１２８）へと挿入して、前記ターゲットネットワーク要素によって、当該ターゲットネットワーク要素に組み合わせられた別のキャッシュ記憶ユニット（１３ｃ）に保存済みのキャッシュ済みデータパケットを、前記同じセッションにおいて前記端末へと送信できるよう、前記コンテクストデータメッセージを前記ターゲットネットワーク要素へと送信し、
前記端末への前記コンテンツデータパケットの送信を停止させる
ように動作可能なコンピュータプログラム。
【請求項１７】
パケットデータネットワークのターゲットネットワーク要素（１３）において実行されるコードを含むコンピュータプログラムであって、前記コードが、
前記ネットワーク内のソースネットワーク要素（１２）からハンドオーバ要求を受信し、
前記ネットワーク内の端末（２１）へのデータ提供セッションのセッション状態パラメータ（１２７）を含むコンテクストデータメッセージ（１２８）を、当該パラメータがキャッシュ済みデータに関連していることを示す表示と共に前記ソースネットワーク要素から受信し、
前記セッション状態パラメータをローカル記憶媒体（１２４）に保存し、
前記セッション状態パラメータを使用して前記データ提供セッションの状態を特定し、
前記データ提供セッション用のコンテンツデータパケット（１３ｄ）であって、前記端末への前記データ提供セッションを中断することなく続けることができるように選択されるコンテンツデータパケットを、前記ネットワーク要素に組み合わせられたキャッシュ記憶媒体から取り出し、
前記データ提供セッションを続けるべく前記端末へと前記コンテンツデータパケットを送信する
ように動作可能なコンピュータプログラム。
【国際調査報告】
2013505612.tif 000016
2013505612.tif 000017