次に、図を参照しながら、例証的な実施形態に関する詳細な説明を述べる。しかし、本発明を例示的な実施形態に関して述べる場合があるが、本発明はこれらの実施形態に限定されず、本発明を逸脱することなく、本発明と同じ機能を実施するために、他の実施形態を使用してもよいこと、または述べる実施形態に修正および追加を行ってもよいことを理解されたい。加えて、図にはコールフローを示す場合があるが、これらは例示的であるものとする。他の実施形態を使用してもよいことを理解されたい。フローの順序は、適宜変えてもよい。また、フローが必要でなければ省略してもよく、追加のフローを加えてもよい。
図1Aは、1つまたは複数の開示する実施形態をその中で実現できる例示的な通信システム100の図である。通信システム100は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のワイヤレスユーザに提供する、多元接続システムとすることができる。通信システム100は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含めたシステムリソースの共有を通してこのようなコンテンツにアクセスするのを可能にすることができる。例えば、通信システム100は、符号分割多元接続(CDMA)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交FDMA(OFDMA)、シングルキャリアFDMA(SC−FDMA)など、1つまたは複数のチャネルアクセス方法を採用することができる。
図1Aに示すように、通信システム100は、ワイヤレス送受信ユニット(WTRU)102a、102b、102c、および/または102d(一般にまたは一括してWTRU102と呼ぶ場合がある)と、無線アクセスネットワーク(RAN)103/104/105と、コアネットワーク106/107/109と、公衆交換電話網(PSTN)108と、インターネット110と、他のネットワーク112とを含んでよいが、開示する実施形態が任意の数のWTRU、基地局、ネットワーク、および/またはネットワーク要素を企図することは理解されるであろう。各WTRU102a、102b、102c、102dは、ワイヤレス環境で動作および/または通信するように構成された任意のタイプのデバイスとすることができる。例として、WTRU102a、102b、102c、102dは、ワイヤレス信号を送信および/または受信するように構成されてよく、ユーザ機器(UE)、移動局、固定またはモバイルの加入者ユニット、ページャ、セルラー電話機、パーソナルディジタルアシスタント(PDA)、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、消費者電子機器などを含み得る。
通信システム100はまた、基地局114aおよび基地局114bを含んでよい。各基地局114a、114bは、WTRU102a、102b、102c、102dのうちの少なくとも1つとワイヤレスにインタフェースして、コアネットワーク106/107/109、インターネット110、および/またはネットワーク112など、1つまたは複数の通信ネットワークへのアクセスを容易にするように構成された、任意のタイプのデバイスとすることができる。例として、基地局114a、114bは、ベーストランシーバステーション(BTS)、ノードB、eノードB、ホームノードB、ホームeノードB、サイトコントローラ、アクセスポイント(AP)、ワイヤレスルータなどとすることができる。基地局114a、114bはそれぞれ単一の要素として描かれているが、基地局114a、114bが任意の数の相互接続された基地局および/またはネットワーク要素を含んでよいことは理解されるであろう。
基地局114aはRAN103/104/105の一部とすることができ、RAN103/104/105はまた、他の基地局、および/または、基地局コントローラ(BSC)や無線ネットワークコントローラ(RNC)や中継ノードなどのネットワーク要素(図示せず)を含んでもよい。基地局114aおよび/または基地局114bは、特定の地理領域内でワイヤレス信号を送信および/または受信するように構成されてよく、この地理領域はセル(図示せず)と呼ばれることもある。セルはさらに、セルセクタに分割することができる。例えば、基地局114aに関連するセルを3つのセクタに分割することができる。したがって、一実施形態では、基地局114aは、3つの送受信機、すなわちセルの各セクタにつき1つの送受信機を備えることができる。別の実施形態では、基地局114aは、多入力多出力(MIMO)技術を採用することができ、したがって、セルの各セクタにつき複数の送受信機を利用することができる。
基地局114a、114bは、エアインタフェース115/116/117を介してWTRU102a、102b、102c、102dのうちの1つまたは複数と通信することができ、エアインタフェース115/116/117は、任意の適切なワイヤレス通信リンク(例えば、無線周波数(RF)、マイクロ波、赤外線(IR)、紫外線(UV)、可視光など)とすることができる。エアインタフェース115/116/117は、任意の適切な無線アクセス技術(RAT)を使用して確立することができる。
より具体的には、上に言及したように、通信システム100は、多元接続システムとすることができ、CDMA、TDMA、FDMA、OFDMA、SC−FDMAなど、1つまたは複数のチャネルアクセス方式を採用することができる。例えば、RAN103/104/105中の基地局114a、およびWTRU102a、102b、102cは、UTRA(Universal Mobile Telecommunications System(UMTS)Terrestrial Radio Access)などの無線技術を実装することができ、これにより、広帯域CDMA(WCDMA(登録商標))を使用してエアインタフェース115/116/117を確立することができる。WCDMA(登録商標)は、HSPA(High−Speed Packet Access)および/またはHSPA+(Evolved HSPA)などの通信プロトコルを含み得る。HSPAは、HSDPA(High−Speed Downlink Packet Access)および/またはHSUPA(High−Speed Uplink Packet Access)を含み得る。別の実施形態では、基地局114aおよびWTRU102a、102b、102cは、E−UTRA(Evolved UMTS Terrestrial Radio Access)などの無線技術を実装することができ、これにより、LTE(Long Term Evolution)および/またはLTE−A(LTE−Advanced)を使用してエアインタフェース115/116/117を確立することができる。
他の実施形態では、基地局114aおよびWTRU102a、102b、102cは、IEEE802.16(すなわちWiMAX(Worldwide Interoperability for Microwave Access))、CDMA2000、CDMA2000 1X、CDMA2000 EV−DO、IS−2000(Interim Standard 2000)、IS−95(Interim Standard 95)、IS−856(Interim Standard 856)、GSM(登録商標)(Global System for Mobile communications)、EDGE(Enhanced Data rates for GSM Evolution)、GSM EDGE(GERAN)などの無線技術を実装することができる。
図1A中の基地局114bは、例えばワイヤレスルータ、ホームノードB、ホームeノードB、またはアクセスポイントとすることができ、事業所、家庭、車両、キャンパスなどの局所化されたエリア中でのワイヤレス接続性を容易にするために任意の適切なRATを利用することができる。一実施形態では、基地局114bおよびWTRU102c、102dは、IEEE802.11などの無線技術を実装して、ワイヤレスローカルエリアネットワーク(WLAN)を確立することができる。別の実施形態では、基地局114bおよびWTRU102c、102dは、IEEE802.15などの無線技術を実装して、ワイヤレスパーソナルエリアネットワーク(WPAN)を確立することができる。さらに別の実施形態では、基地局114bおよびWTRU102c、102dは、セルラーベースのRAT(例えばWCDMA(登録商標)、CDMA2000、GSM(登録商標)、LTE、LTE−Aなど)を利用して、ピコセルまたはフェムトセルを確立することができる。図1Aに示すように、基地局114bは、インターネット110への直接接続を有することができる。したがって、基地局114bは、コアネットワーク106/107/109を介してインターネット110にアクセスすることは必要とされなくてよい。
RAN103/104/105は、コアネットワーク106/107/109と通信してよく、コアネットワーク106/107/109は、音声、データ、アプリケーション、および/またはボイスオーバインターネットプロトコル(VoIP)サービスをWTRU102a、102b、102c、102dのうちの1つまたは複数に提供するように構成された、任意のタイプのネットワークとすることができる。例えば、コアネットワーク106/107/109は、呼制御、課金サービス、モバイル位置ベースのサービス、前払い電話、インターネット接続性、ビデオ配信などを提供することができ、かつ/または、ユーザ認証など、高レベルのセキュリティ機能を実施することができる。図1Aには示されていないが、RAN103/104/105、および/またはコアネットワーク106/107/109が、RAN103/104/105と同じRATまたは異なるRATを採用する他のRANと、直接にまたは間接的に通信してもよいことは理解されるであろう。例えば、コアネットワーク106/107/109は、E−UTRA無線技術を利用しているであろうRAN103/104/105に接続されるのに加えて、GSM(登録商標)無線技術を採用する別のRAN(図示せず)と通信してもよい。
コアネットワーク106/107/109はまた、WTRU102a、102b、102c、102dがPSTN108、インターネット110、および/または他のネットワーク112にアクセスするためのゲートウェイとしての働きをすることができる。PSTN108は、POTS(plain old telephone service)を提供する回路交換電話網を含み得る。インターネット110は、TCP/IPインターネットプロトコルスイート中の、伝送制御プロトコル(TCP)、ユーザデータグラムプロトコル(UDP)、およびインターネットプロトコル(IP)など、共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスの地球規模のシステムを含み得る。ネットワーク112は、他のサービスプロバイダによって所有および/または運営される、有線またはワイヤレス通信ネットワークを含み得る。例えば、ネットワーク112は、RAN103/104/105と同じRATまたは異なるRATを採用するであろう1つまたは複数のRANに接続された、別のコアネットワークを含み得る。
通信システム100中のWTRU102a、102b、102c、102dのいくつかまたは全ては、マルチモード能力を備えることができる。すなわち、WTRU102a、102b、102c、102dは、種々のワイヤレスリンクを介して種々のワイヤレスネットワークと通信するために、複数の送受信機を備えることができる。例えば、図1Aに示すWTRU102cは、セルラーベースの無線技術を採用するであろう基地局114aと、また、IEEE802無線技術を採用するであろう基地局114bと、通信するように構成されてよい。
図1Bは、例示的なWTRU102のシステム図である。図1Bに示すように、WTRU102は、プロセッサ118、送受信機120、送受信要素122、スピーカ/マイクロホン124、キーパッド126、表示装置/タッチパッド128、非取外し可能メモリ130、取外し可能メモリ132、電源134、全地球測位システム(GPS)チップセット136、および他の周辺装置138を備えてよい。WTRU102が、一実施形態との整合性を維持しながら前述の要素の任意のサブコンビネーションを備えてよいことは理解されるであろう。また、実施形態は、基地局114aおよび114b、ならびに/または基地局114aおよび114bが表すことのできるノード(とりわけ、トランシーバステーション(BTS)、ノードB、サイトコントローラ、アクセスポイント(AP)、ホームノードB、発展型(evolved)ホームノードB(eノードB)、ホーム発展型ノードB(HeNB)、ホーム発展型ノードBゲートウェイ、およびプロキシノードなどだがこれらに限定されない)が、図1Bに描かれ本明細書に記述される要素のいくつかまたは全てを備えてよいことを企図する。
プロセッサ118は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、ディジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアと関連する1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、他の任意のタイプの集積回路(IC)、状態機械などとすることができる。プロセッサ118は、信号符号化、データ処理、電力制御、入出力処理、および/または、WTRU102がワイヤレス環境で動作できるようにする他の任意の機能を実施することができる。プロセッサ118は送受信機120に結合されてよく、送受信機120は送受信要素122に結合されてよい。図1Bではプロセッサ118と送受信機120とを別々のコンポーネントとして描いているが、プロセッサ118と送受信機120とを共に電子パッケージまたはチップ中で統合してもよいことは理解されるであろう。
送受信要素122は、エアインタフェース115/116/117を介して基地局(例えば基地局114a)との間で信号を送信または受信するように構成されてよい。例えば、一実施形態では、送受信要素122は、RF信号を送信および/または受信するように構成されたアンテナとすることができる。別の実施形態では、送受信要素122は、例えばIR、UV、または可視光信号を送信および/または受信するように構成された、エミッタ/検出器とすることができる。さらに別の実施形態では、送受信要素122は、RF信号と光信号の両方を送受信するように構成されてよい。送受信要素122が任意の組合せのワイヤレス信号を送信および/または受信するように構成されてよいことは理解されるであろう。
加えて、図1Bでは送受信要素122が単一の要素として描かれているが、WTRU102は、任意の数の送受信要素122を備えてよい。より具体的には、WTRU102は、MIMO技術を採用することができる。したがって、一実施形態では、WTRU102は、エアインタフェース115/116/117を介してワイヤレス信号を送受信するために、2つ以上の送受信要素122(例えば複数のアンテナ)を備えることができる。
送受信機120は、送受信要素122によって送信されることになる信号を変調し、送受信要素122によって受信された信号を復調するように構成されてよい。上に言及したように、WTRU102は、マルチモード能力を有することができる。したがって、送受信機120は、WTRU102が複数のRAT(例えばUTRAおよびIEEE802.11など)を介して通信できるようにするために、複数の送受信機を備えることができる。
WTRU102のプロセッサ118は、スピーカ/マイクロホン124、キーパッド126、および/または、表示装置/タッチパッド128(例えば液晶表示装置(LCD)表示ユニットもしくは有機発光ダイオード(OLED)表示ユニット)に結合されてよく、これらからユーザ入力データを受け取ることができる。プロセッサ118はまた、スピーカ/マイクロホン124、キーパッド126、および/または、表示装置/タッチパッド128にユーザデータを出力することができる。加えて、プロセッサ118は、非取外し可能メモリ130および/または取外し可能メモリ132など、任意のタイプの適切なメモリからの情報にアクセスすること、およびそのようなメモリにデータを記憶することができる。非取外し可能メモリ130は、ランダムアクセスメモリ(RAM)、読取専用メモリ(ROM)、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含み得る。取外し可能メモリ132は、SIM(subscriber identity module)カード、メモリスティック、SD(secure digital)メモリカードなどを含み得る。他の実施形態では、プロセッサ118は、サーバやホームコンピュータ(図示せず)上のメモリなど、WTRU102上に物理的に位置しないメモリからの情報にアクセスすること、およびそのようなメモリにデータを記憶することができる。
プロセッサ118は、電源134から電力を受け取ることができ、WTRU102中の他のコンポーネントへの電力を分配および/または制御するように構成されてよい。電源134は、WTRU102に電力を供給するための任意の適切なデバイスとすることができる。例えば、電源134は、1つまたは複数の乾電池バッテリ(例えばニッケルカドミウム(NiCd)、ニッケル亜鉛(NiZn)、ニッケル金属水素化物(NiMH)、リチウムイオン(Li−ion)等)、太陽電池、燃料電池などを含み得る。
プロセッサ118は、GPSチップセット136にも結合されてよく、GPSチップセット136は、WTRU102の現在位置に関する位置情報(例えば経度と緯度)を提供するように構成されてよい。GPSチップセット136からの情報に加えて、またはそれに代えて、WTRU102は、基地局(例えば基地局114a、114b)からエアインタフェース115/116/117を介して位置情報を受け取ることができ、かつ/または、2つ以上の近隣基地局から受け取られている信号のタイミングに基づいてその位置を決定することができる。WTRU102が一実施形態との整合性を維持しながら任意の適切な位置決定方法を用いて位置情報を取得してよいことは、理解されるであろう。
プロセッサ118はさらに、他の周辺装置138にも結合されてよく、周辺装置138は、追加の機構、機能、および/または有線もしくはワイヤレス接続性をもたらす、1つまたは複数のソフトウェアおよび/またはハードウェアモジュールを含み得る。例えば、周辺装置138は、加速度計、電子コンパス、衛星送受信機、ディジタルカメラ(写真またはビデオ用)、USB(universal serial bus)ポート、振動デバイス、テレビジョン送受信機、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)無線ユニット、ディジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含み得る。
図1Cは、一実施形態によるRAN103およびコアネットワーク106のシステム図である。上に言及したように、RAN103は、E−UTRA無線技術を採用して、エアインタフェース115を介してWTRU102a、102b、102cと通信することができる。RAN103はまた、コアネットワーク106とも通信することができる。図1Cに示すように、RAN103は、ノードB140a、140b、140cを含んでよく、ノードB140a、140b、140cはそれぞれ、エアインタフェース115を介してWTRU102a、102b、102cと通信するために、1つまたは複数の送受信機を備えてよい。ノードB140a、140b、140cはそれぞれ、RAN103内の特定のセル(図示せず)に関連してよい。RAN103は、RNC142a、142bも含んでよい。RAN103が一実施形態との整合性を維持しながら任意の数のノードBおよびRNCを含んでよいことは理解されるであろう。
図1Cに示すように、ノードB140a、140bは、RNC142aと通信することができる。加えて、ノードB140cは、RNC142bと通信することができる。ノードB140a、140b、140cは、Iubインタフェースを介してそれぞれのRNC142a、142bと通信することができる。RNC142a、142bは、Iurインタフェースを介して相互と通信することができる。各RNC142a、142bは、それが接続されているそれぞれのノードB140a、140b、140cを制御するように構成されてよい。加えて、各RNC142a、142bは、アウターループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、データ暗号化など、他の機能も実施またはサポートするように構成されてよい。
図1Cに示すコアネットワーク106は、メディアゲートウェイ(MGW)144、移動交換センタ(MSC)146、サービングGPRSサポートノード(SGSN)148、および/またはゲートウェイGPRSサポートノード(GGSN)150を含んでよい。これらの各要素はコアネットワーク106の一部として描かれているが、これらの要素のいずれか1つがコアネットワークオペレータ以外のエンティティによって所有および/または運営されてもよいことは理解されるであろう。
RAN103中のRNC142aは、IuCSインタフェースを介してコアネットワーク106中のMSC146に接続されてよい。MSC146は、MGW144に接続されてよい。MSC146およびMGW144は、PSTN108などの回路交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cと従来の陸線通信デバイスとの間の通信を容易にすることができる。
RAN103中のRNC142aはまた、IuPSインタフェースを介してコアネットワーク106中のSGSN148に接続されてよい。SGSN148は、GGSN150に接続されてよい。SGSN148およびGGSN150は、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cとIP対応デバイスとの間の通信を容易にすることができる。
上に言及したように、コアネットワーク106はネットワーク112にも接続されてよく、ネットワーク112は、他のサービスプロバイダによって所有および/または運営される他の有線またはワイヤレスネットワークを含み得る。
図1Dは、一実施形態によるRAN104およびコアネットワーク107のシステム図である。上に言及したように、RAN104は、E−UTRA無線技術を採用して、エアインタフェース116を介してWTRU102a、102b、102cと通信することができる。RAN104はまた、コアネットワーク107と通信することができる。
RAN104は、eノードB160a、160b、160cを含んでよいが、RAN104が一実施形態との整合性を維持しながら任意の数のeノードBを含んでよいことは理解されるであろう。eノードB160a、160b、160cはそれぞれ、エアインタフェース116を介してWTRU102a、102b、102cと通信するために、1つまたは複数の送受信機を備えることができる。一実施形態では、eノードB160a、160b、160cは、MIMO技術を実装することができる。したがって、例えばeノードB160aは、複数のアンテナを使用して、WTRU102aとの間でワイヤレス信号を送受信することができる。
各eノードB160a、160b、160cは、特定のセル(図示せず)に関連してよく、無線リソース管理決定、ハンドオーバ決定、アップリンクおよび/またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成されてよい。図1Dに示すように、eノードB160a、160b、160cは、X2インタフェースを介して相互と通信することができる。
図1Dに示すコアネットワーク107は、モビリティ管理ゲートウェイ(MME)162、サービングゲートウェイ164、およびパケットデータネットワーク(PDN)ゲートウェイ166を含んでよい。前述の各要素はコアネットワーク107の一部として描かれているが、これらの要素のいずれか1つがコアネットワークオペレータ以外のエンティティによって所有および/または運営されてもよいことは理解されるであろう。
MME162は、S1インタフェースを介してRAN104中の各eノードB160a、160b、160cに接続されてよく、制御ノードとしての働きをすることができる。例えば、MME162は、WTRU102a、102b、102cのユーザを認証すること、ベアラをアクティブ化/非アクティブ化すること、WTRU102a、102b、102cの最初の帰属中に特定のサービングゲートウェイを選択することなどを担うことができる。MME162はまた、RAN104と、GSM(登録商標)やWCDMA(登録商標)など他の無線技術を採用する他のRAN(図示せず)との間で切り替えるための制御プレーン機能を提供することもできる。
サービングゲートウェイ164は、S1インタフェースを介してRAN104中の各eノードB160a、160b、160cに接続されてよい。サービングゲートウェイ164は一般に、WTRU102a、102b、102cとの間でユーザデータパケットをルーティングおよび転送することができる。サービングゲートウェイ164はまた、eノードB間のハンドオーバ中にユーザプレーンをつなぎ留めること、ダウンリンクデータがWTRU102a、102b、102cに利用可能なときにページングをトリガすること、WTRU102a、102b、102cのコンテキストを管理および記憶することなど、他の機能を実施することもできる。
サービングゲートウェイ164はまた、PDNゲートウェイ166に接続されてよく、PDNゲートウェイ166は、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cとIP対応デバイスとの間の通信を容易にすることができる。
コアネットワーク107は、他のネットワークとの通信を容易にすることができる。例えば、コアネットワーク107は、PSTN108などの回路交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cと従来の陸線通信デバイスとの間の通信を容易にすることができる。例えば、コアネットワーク107は、コアネットワーク107とPSTN108との間のインタフェースとしての働きをするIPゲートウェイ(例えばIPマルチメディアサブシステム(IMS)サーバ)を含むか、またはそのようなIPゲートウェイと通信することができる。加えて、コアネットワーク107は、他のサービスプロバイダによって所有および/または運営される他の有線またはワイヤレスネットワークを含み得るネットワーク112へのアクセスを、WTRU102a、102b、102cに提供することができる。
図1Eは、一実施形態によるRAN105およびコアネットワーク109のシステム図である。RAN105は、IEEE802.16無線技術を採用してエアインタフェース117を介してWTRU102a、102b、102cと通信する、アクセスサービスネットワーク(ASN)とすることができる。後でさらに論じるように、WTRU102a、102b、102c、RAN105、およびコアネットワーク109の種々の機能エンティティ間の通信リンクを、基準点として定義することができる。
図1Eに示すように、RAN105は、基地局180a、180b、180c、およびASNゲートウェイ182を含んでよいが、RAN105が一実施形態との整合性を維持しながら任意の数の基地局およびASNゲートウェイを含んでよいことは理解されるであろう。基地局180a、180b、180cはそれぞれ、RAN105中の特定のセル(図示せず)に関連してよく、エアインタフェース117を介してWTRU102a、102b、102cと通信するために、1つまたは複数の送受信機をそれぞれ備えることができる。一実施形態では、基地局180a、180b、180cは、MIMO技術を実装することができる。したがって、例えば基地局180aは、複数のアンテナを使用して、WTRU102aとの間でワイヤレス信号を送受信することができる。基地局180a、180b、180cはまた、ハンドオフのトリガ、トンネル確立、無線リソース管理、トラフィック分類、サービス品質(QoS)ポリシ施行など、モビリティ管理機能を提供することもできる。ASNゲートウェイ182は、トラフィック集約ポイントとしての働きをすることができ、ページング、加入者プロファイルのキャッシング、コアネットワーク109へのルーティングなどを担うことができる。
WTRU102a、102b、102cとRAN105との間のエアインタフェース117は、IEEE802.16仕様を実装するR1基準点として定義することができる。加えて、各WTRU102a、102b、102cは、コアネットワーク109との論理インタフェース(図示せず)を確立することができる。WTRU102a、102b、102cとコアネットワーク109との間の論理インタフェースは、R2基準点として定義することができ、R2基準点は、認証、許可、IPホスト構成管理、および/またはモビリティ管理に使用することができる。
各基地局180a、180b、180c間の通信リンクは、R8基準点として定義することができ、R8基準点は、WTRUハンドオーバおよび基地局間のデータ転送を容易にするためのプロトコルを含む。基地局180a、180b、180cとASNゲートウェイ182との間の通信リンクは、R6基準点として定義することができる。R6基準点は、各WTRU102a、102b、102cに関連するモビリティイベントに基づくモビリティ管理を容易にするためのプロトコルを含むことができる。
図1Eに示すように、RAN105は、コアネットワーク109に接続されてよい。RAN105とコアネットワーク109との間の通信リンクは、R3基準点として定義することができ、R3基準点は、例えばデータ転送およびモビリティ管理能力を容易にするためのプロトコルを含む。コアネットワーク109は、PMIP−LMA(Proxy mobile IP Local Mobility Anchor)184、認証許可アカウンティング(AAA)サーバ186と、ゲートウェイ188とを含んでよい。前述の各要素はコアネットワーク109の一部として描かれているが、これらの要素のいずれか1つがコアネットワークオペレータ以外のエンティティによって所有および/または運営されてもよいことは理解されるであろう。
PMIP−LMAは、IPアドレス管理を担うことができ、WTRU102a、102b、102cが種々のASNおよび/または種々のコアネットワーク間でローミングするのを可能にすることができる。PMIP−LMA184は、インターネット110などのパケット交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cとIP対応デバイスとの間の通信を容易にすることができる。AAAサーバ186は、ユーザ認証とユーザサービスのサポートとを担うことができる。ゲートウェイ188は、他のネットワークとのインターワーキングを容易にすることができる。例えば、ゲートウェイ188は、PSTN108などの回路交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cと従来の陸線通信デバイスとの間の通信を容易にすることができる。加えて、ゲートウェイ188は、他のサービスプロバイダによって所有および/または運営される他の有線またはワイヤレスネットワークを含み得るネットワーク112へのアクセスを、WTRU102a、102b、102cに提供することができる。
図1Eには示されていないが、RAN105が他のASNに接続されてもよく、コアネットワーク109が他のコアネットワークに接続されてもよいことは、理解されるであろう。RAN105と他のASNとの間の通信リンクは、R4基準点として定義することができ、R4基準点は、RAN105と他のASNとの間におけるWTRU102a、102b、102cのモビリティを調整するためのプロトコルを含むことができる。コアネットワーク109と他のコアネットワークとの間の通信リンクは、R5基準として定義することができ、R5基準は、ホームコアネットワークと訪問先コアネットワークとの間のインターワーキングを容易にするためのプロトコルを含むことができる。
モバイルノードを構成する(モバイルノードに関連する論理インタフェース(LIF)を構成することを含み得る)ためのシステム、方法、および手段を開示する。モバイルノードが、構成メッセージを受信することができる。構成メッセージは、ANDSF(access network discovery and selection function)から受信することができ、ANDSFは、OMA DM(open mobile alliance device management)サーバの一部とすることができる。構成メッセージは、モバイルノード規則を含むことができる。例えば、構成メッセージは、どのようにモバイルデバイスが入来フローまたは送出フローを扱うことになるか(例えば、使用するインタフェース、処理方法など)を示すことができる。構成メッセージは、OMA DM(open mobile alliance device management)メッセージとすることができる。構成メッセージは、モバイルノードからのフィードバックに基づくことができる。構成メッセージは、アクションおよびパラメータを含むことができる。
モバイルノードは、モバイルノード規則に従って構成を変更することができる。モバイルノード規則は、モバイルノードが、あるインタフェース上でアップリンクパケットを送信すべきであることを示すことができる。モバイルノードは、モバイルノード規則によって示されるインタフェースを介して、アップリンクパケットを送信することができる。例として、構成メッセージ受信前は、モバイルノードは、関連するダウンリンクパケットが受信された物理インタフェース上で、アップリンクパケットを送信するように構成されていた場合がある。受信された構成メッセージに応答して、モバイルノードは、関連するダウンリンクパケットが受信された物理インタフェースとは異なる物理インタフェース上で、アップリンクパケットを送信することができる。
モバイルノードの構成は、ローカルモビリティアンカ(LMA)などのアンカノードによって実施することができる。OMA DMサーバ機能をアンカにおいて実施することができる。構成メッセージ中のモバイルノード規則は、関係するアンカノード規則と一致してよく、または、関係するアンカノード規則とは異なってよい。
モバイルノード規則は、複数のモバイルノード規則のうちの1つとすることができる。複数のモバイルノード規則には、優先順位を付けることができる。例えば、優先順位付けは、データタイプ、時刻、コストのうちの1つまたは複数に基づくことができる。
インターネットプロトコル(IP)スタックは、IPスイートのソフトウェア実装と呼ぶことができる。論理インタフェース(LIF)は、オペレーティングシステム内部の構造を指すことができる。LIF実装において、リンクレイヤは、物理インタフェースをIPスタックおよびネットワークノードから隠すことができる。モバイルネットワーク上における論理インタフェース実装の例を、図2の図面によって例示する。
ローカルモビリティアンカ(LMA)などのアンカが、特定のフローをそのデフォルトパスから異なるパスへと移動させると決定したとき、ネットワークベースのIPフローモビリティが開始することができる。アンカは、特定のフローが開始したとき、どのアクセスゲートウェイ(AG)(例えばモバイルアクセスゲートウェイ(MAG))を使用してこのフローを移行すべきかを決定することができる。例えば、この決定は、アプリケーションポリシプロファイルに基づくことができ、かつ/または、ネットワークベースもしくはモバイルベースのトリガの受信時のフローの生存期間中であってよい。論理インタフェースは、特定のプレフィックス/フローについて、ダウンリンク(DL)パケットが受信された物理インタフェース上でアップリンク(UL)パケットを送信するものと指定されていた。以下のうちの1つまたは複数が当てはまる場合がある。アンカにおいてなされたフローモビリティ決定は、モバイルノード(MN)において、同じフローに属するパケットが新しいインタフェースに到着するときに暗黙的な決定として理解することができる。モバイルノードは、ユーザ機器(UE)とすることができるが、これに限定されない。モバイルとアンカとの間、またはモバイルとアクセスゲートウェイとの間で、IPフローモビリティを制御するための制御メッセージは交換されない。複数のIPv6プレフィックスが使用される場合は、新しいPMIPまたはGTPメッセージを生み出す必要がある場合がある。これらのメッセージは、アクセスゲートウェイ中のフローモビリティ状態を生成、リフレッシュ、またはキャンセルするために、アンカによって送信することができる。
図3に、決定がローカルモビリティアンカ(LMA)からである場合の、ネットワークによって制御されるIPフローモビリティシーケンスの例示的な流れ図を示す。図3で、CNは対応ノード(CN、correspondent node)を表し、モバイルアクセスゲートウェイ(MAG)はモバイルアクセスゲートウェイを表す。モバイルノードが、単一無線動作(一度に1つの無線送信)をサポートすることに限定されるとき、種々の媒体を介して種々のMAGに帰属するのは逐次的(例えば、同時でないか、またはいくぶん同時)とすることができる。この場合、レイヤ2.5シグナリングを使用して、アクセス技術間ハンドオーバを実施し、所望のターゲットアクセス技術、MN−ID、フローID、およびプレフィックスをLMAに通信することができる。
ネットワーク帰属時にポリシ構成を行うことができ、このポリシ構成は、レイヤ2シグナリングを使用して、または外部チャネルを介して動的に、MNに転送することができる。例えば、L2シグナリングがこのような情報を搬送し、PMIPv6シグナリングがLMAとMAGとの間でルーティングポリシを伝達することができるものとすることができる。バインド接続の生存期間中に、ポリシの更新を行うことができる。ポリシの更新の結果、進行中のフローを、あるアクセスネットワークから別のアクセスネットワークに移動する場合がある。
ULフローの場合、MNは、ユーザ選好、オペレータポリシ、アプリケーション要件などに基づいてローカルポリシを構成できるものとすることができる。MNは、例えばネットワーク帰属の間に、または特定のレイヤ2のトリガ(例えばlink going down)の受信時に、ポリシをMAGに送信できるものとすることができる。この場合、MNがフローモビリティプロシージャをトリガする、と言うことができる。ネットワークも、例えばネットワーク負荷条件に基づいて、フローモビリティプロシージャを等しく開始できるものとすることができる。
IEEE標準801.21シグナリングを使用して、MNからMAGにフィルタを搬送することができる(MIHパケット用のIETF標準化されたIPトランスポート)。MIHサービスポイントは、MAG機能と共に展開することができる。
例えばネットワーク帰属の間にまたはレイヤ2トリガ(例えばlink going down)時にMNがサービングノードに規則を送ることによって、MNとアンカとの間の動的な規則交換を実施することができる。指定されるようにMNおよびアンカ上で同じ規則を適用することによって、挙動を制限することができる。
OMA DM(open mobile alliance device management)仕様は、携帯電話機、PDA、およびパームトップコンピュータなどの小型モバイルデバイスの管理に関係する場合がある。通信プロトコルは、要求−応答プロトコルとすることができる。通信は、OMA DMサーバによって開始することができ、この通信は、WAP PushやSMSなど、利用可能な方法のいずれかを使用して非同期で行うことができる。サーバからクライアントへの最初のメッセージは、通知またはアラートメッセージの形とすることができる。サーバとクライアントとの間で通信が確立された後は、メッセージのシーケンスを交換して所与のデバイス管理タスクを完了することができる。
OMA DMは、アラートを可能にすることができる。アラートは、シーケンス外で発生するメッセージとすることができ、サーバおよび/またはクライアントによって開始することができる。このようなアラートを使用して、エラーや異常終了などを処理することができる。図4に、デバイス管理プロトコルの段階の例示的な流れ図を示す。通知メッセージ、アラートを使用して、サーバが管理セッションの実施をクライアントにアラートできる可能性をもたらすことができる。クライアントが、セッションを開始することができる。サーバが通知を送って、セッションを開始するようクライアントに知らせることができる。クライアントは、クライアント自体で、セッションの開始を決定することができる。通知メッセージは、トリガヘッダおよびトリガ本体を含むことができる。トリガヘッダは、ユーザ対話モード(uiモード)を指定することができ、以下の値のうちの1つまたは複数を含むことができる。すなわち、(1)未指定、(2)バックグラウンド管理アクション、(3)情報管理アクション、および(4)管理アクション前のユーザ対話などである。トリガ本体は、ベンダ特有(TLVまたは他のタイプの表現)とすることができる。
ANDSF(access network discovery and selection function)およびUEによって使用できる管理オブジェクトを、本明細書に開示することができる。管理オブジェクト(MO)は、ANDSFによって管理できるシステム間モビリティポリシおよびアクセスネットワーク発見情報についての関連パラメータを含むことができる。以下に、IPフローモビリティおよびルーティング規則に関係する可能な構成の例示的な概要を示す。
5.102E<X>/ISRP/ 44
5.102F<X>/ISRP/<X> 44
5.102G<X>/ISRP/<X>/RulePriority 44
5.102H<X>/ISRP/<X>/ForFlowBased 45
5.102I<X>/ISRP/<X>/ForFlowBased/<X>/45
5.102J<X>/ISRP/<X>/ForFlowBased/<X>/IPFlow45
5.102K<X>/ISRP/<X>/ForFlowBased/<X>/IPFlow/<X>/ 45
5.102L<X>/ISRP/<X>/ForFlowBased/<X>/IPFlow/<X>/ AddressType 45
5.102M <X>/ISRP/<X>/ForFlowBased/<X>/IPFlow/<X>/ StartSourceIPaddress 46
5.102N<X>/ISRP/<X>/ForFlowBased/<X>/IPFlow/<X>/ EndSourceIPaddress 46
5.102O<X>/ISRP/<X>/ForFlowBased/<X>/IPFlow/<X>/ StartDestIPaddress 46
5.102P<X>/ISRP/<X>/ForFlowBased/<X>/IPFlow/<X>/ EndDestIPaddress 46
5.102Q<X>/ISRP/<X>/ForFlowBased/<X>/IPFlow/<X>/ ProtocolType 47
5.102R<X>/ISRP/<X>/ForFlowBased/<X>/IPFlow/<X>/ StartSourcePortNumber47
5.102S<X>/ISRP/<X>/ForFlowBased/<X>/IPFlow/<X>/ EndSourcePortNumber 47
5.102T<X>/ISRP/<X>/ForFlowBased/<X>/IPFlow/<X>/ StartDestPortNumber 47
5.102U<X>/ISRP/<X>/ForFlowBased/<X>/IPFIow/<X>/ EndDestPortNumber 48
5.102V<X>/ISRP/<X>/ForFlowBased/<X>/IPFlow/<X>/QoS 48
5.102W <X>/ISRP/<X>/ForFlowBased/<X>/RoutingCriteria 48
5.102X<X>/ISRP/<X>/ForFlowBased/<X>/RoutingCriteria/<X>/ 48
5.102Y<X>/ISRP/<X>/ForFlowBased/<X>/RoutingCriteria/<X>/ValidityArea 48
ValidityAreaノードは、特定のシステム間ルーティングポリシ規則についての位置条件のためのプレースホルダとしての役割を果たすことができる。
5.102Z<X>/ISRP/<X>/ForFlowBased/<X>/RoutingCriteria/<X>/TimeOfDay 49
TimeOfDayノードは、特定のシステム間ルーティングポリシ規則についての日条件のためのプレースホルダとしての役割を果たすことができる。
5.102AA<X>/ISRP/<X>/ForFlowBased/<X>/RoutingCriteria/<X>/ APN 49
APNリーフは、特定のシステム間ルーティングポリシ規則が有効であるAPNを示すことができる。
5.102AB <X>/ISRP/<X>/ForFlowBased/<X>/RoutingRule 49
RoutingRuleノードは、システム間ルーティングポリシ規則についての好まれるアクセスを示すことができる。このノードおよびその子孫は、以下において定義することができる。
<X>/Policy/<X>/PrioritizedAccess.
5.7 <X>/Policy/<X>/PrioritizedAccess 14
PrioritizedAccessノードは、特定の規則についての好まれるアクセスを示すことができる。
5.8 <X>/Policy/<X>/PrioritizedAccess/<X> 14
この内部ノードは、1つまたは複数の優先されるアクセスのためのプレースホルダとしての役割を果たすことができる。
5.9 <X>/Policy/<X>/PrioritizedAccess/<X>/ AccessTechnology 14
AccessTechnologyリーフは、優先されるアクセス技術を示すことができる。
5.10 <X>/Policy/<X>/PrioritizedAccess/<X>/ AccessId 15
AccessIdリーフは、アクセスネットワーク識別子を表すことができる。
5.10A <X>/Policy/<X>/PrioritizedAccess/<X>/ SecondaryAccessId 15
SecondaryAccessIdリーフは、2次アクセスネットワーク識別子を表すことができる。
5.11 <X>/Policy/<X>/PrioritizedAccess/<X>/ AccessNetworkPriority 15
AccessNetworkPriorityリーフは、アクセス技術の優先順位を表すことができる。
インターネット制御メッセージプロトコル(ICMP)は、インターネットプロトコルスイートの一部である。ICMPメッセージは、IPデータグラム中のエラーに応答して、または診断もしくはルーティングの目的で、生成される場合がある。一例では、インタフェースが使用可能になると、ホストは、ルータ要請を送出することができ、このルータ要請は、次のスケジュール済み時間にではなくすぐにルータ広告を生成するよう、ルータに要求する。ルータは、定期的に、またはルータ要請メッセージに応答して、ルータの存在を様々なリンクおよびインターネットパラメータと共に広告することができる。ルータ広告は、オンリンク決定および/またはアドレス構成に使用されるプレフィックス、提案されるホップ制限値などを含むことができる。エコー要求/エコー返答メッセージを使用して、ピアにピングすることができる。
DHCP動作は、以下の段階のうちの1つまたは複数を含むことができる。すなわち、IP発見、IPリースオファー、IP要求、およびIPリース肯定応答である。クライアントは、物理サブネット上でメッセージをブロードキャストして、利用可能なDHCPサーバを発見することができる。DHCPDISCOVERメッセージを使用することができる。DHCPサーバがIPリース要求をクライアントから受信すると、DHCPサーバは、このクライアント用にIPアドレスを予約し、DHCPOFFERメッセージをクライアントに送信することによってIPリースオファーを拡張することができる。クライアントは、複数のサーバからDHCPオファーを受信する場合があるが、受諾を1つのDHCPオファーに制限してDHCP要求メッセージをブロードキャストすることができる。DHCPサーバがDHCPREQUESTメッセージをクライアントから受信すると、構成プロセスは最終段階に入ることができる。肯定応答段階は、DHCPACKパケットをクライアントに送信することを含むことができる。
DHCPクライアントは、DHCP情報メッセージを使用して、サーバが元のDHCPOFFERによって送った情報よりも多くの情報を要求することができる。クライアントは、特定のアプリケーションについてリピートデータを要求することができる。クライアントは、DHCP解放メッセージを使用して、DHCP情報を解放するよう求める要求をDHCPサーバに送信することができ、クライアントは、そのIPアドレスを非アクティブ化することができる。
DHCPサーバは、オプションの構成パラメータをクライアントに提供することができる。DHCPクライアントは、DHCPサーバによって提供されたパラメータを選択、操作、および上書きすることができる。構成パラメータおよび他の制御情報は、DHCPメッセージの「オプション」フィールドに記憶されたタグ付きデータアイテム中で搬送することができる。これらのデータアイテム自体を、「オプション」と呼ぶことができる。
LIF要件は、MNが、DLパケットが受信されたのと同じインタフェース上でULパケットを送信することを言明する場合がある。この挙動を達成するために、MN上での入来パケットフィルタリングを実施して、入来フローと関連インタフェースとを含むマッピングテーブルを構築することができる。この入来フィルタリングは、CPUの負担が厳しい可能性があり、多くのDLパケットが受信され入来フィルタリングが受信プロセスを遅くしている状況では、パケットドロップにつながる可能性がある。
上記のLIF挙動では、UE上でのLIF実装は、フローごとのネットワークインタフェース選択をミラーリングしている。しかし、状況によっては、UEが異なる挙動をする(例えばDLパケットとは異なるインタフェース上でULパケットを送信する)のが有利な場合がある。リアルタイムの状況(例えばネットワーク条件)に基づいてフローを移動する必要がある場合があるので、機能(例えばIPフローモビリティ)をサポートするために動的構成能力が必要とされることがある。
種々のタイプのデータを転送するために複数のソケットを開いているアプリケーションは、複数のIPフローを有することがある。ネットワーク中でLIFおよびアンカノードを使用して、これらのIPフローを、LIFに関連する物理インタフェース間で移動することができる。単一のアプリケーションに関係するIPフローは、別個に扱うことができる。例えば、これらのIPフローは、独立して、またはいくぶん独立して移動することができる。例えば、3つのIPフローを有するアプリケーションが、3つのフローを単一のインタフェース(例えばIF#1)上で送信させ、何らかの時点で、結局は3つの異なるインタフェース(例えばIF#1、IF#2、およびIF#3)上の1つのフローで終わる場合がある。このような変化は、種々の理由で、例えばネットワーク輻輳、ネットワーク決定、構成された規則、選好などによって生じることがある。この場合にアプリケーションによって受信されるデータは、非同期である可能性がある。フローが独立しているとしても、これらのフローの内容を同期方式で表示および/または再生することが必要な場合がある。
所定の挙動に基づく代わりに、例えば構成された規則に基づいて、論理インタフェースの向上をもたらすことができる。構成された規則をこのように使用することにより、入来パケットフィルタリングを回避するのを可能にすることができる。規則は、MN上および/またはネットワーク上で、動的に構成することができる。開示するシステム、方法、および手段は、OMA DM、802.21、DHCP、ICMPなどに関係してよい。ネットワーク/アンカ(例えばダウンリンク)上の構成された規則は、MN(例えばアップリンク)上の規則とは異なってよい。複数の規則を同時に適用することができる(例えば組合せ)。規則の構成は、動的であってよく、例えば、ネットワーク条件や時刻など種々の状況に適合させることができる。アプリケーションおよび/またはセッションモビリティを提供することができる。開示するシステム、方法、および手段は、ネットワークベースのモビリティ領域(例えばPMIPまたはGTP)中のLIF挙動に関係してよく、関係するネットワークノードは、PMIPv6またはGTP領域の一部とすることができる。
送出パケットに適用されることになる規則がMNにわかっているようにすることにより、MN上でのパケットフィルタリングを回避することができる。例えば、アンカによって適用される規則がMNにわかっている場合、MNは、MNが使用することになる規則がわかっていることになるので、入来パケットのフィルタリングの実施(例えばULでどのインタフェースを使用するかを決定するために)の必要はなくてよい。MNが入来パケットを調べてから送出パケットで挙動をミラーリングすることを必要とする代わりに、適用されることになる規則をMN上で構成することができる。加えて、LIF挙動はフレキシブルとすることができる(パケットを、フローが受信されたインタフェース上で送信することが必要とされるのとは対照的に)。
以下に、動的な規則構成の例を提供することができる。構成は、規則(例えば本明細書で述べる規則のタイプなど)に従って変更することができる。アンカが、ダウンリンク上で、2つのフロー(例えばフロー#1およびフロー#2)をあるインタフェース(例えばインタフェース#1(IF#1))上でMNに送信している場合がある。MNは、あるフローに関係するULパケットを、このフローのダウンリンクパケットを受信したインタフェース上で送信するように構成されている(例えば規則によって)場合がある。すなわち、MNは、規則に従って、かつフロー#1およびフロー#2からの入来パケットに対するパケットフィルタリングを実施せずに、フロー#1およびフロー#2のULパケットをIF#1上で送信することができる。アンカは、MNの構成を変更することができる。例えば、アンカは、フロー#1に関連するアップリンクパケットはIF#1上で送信し、フロー#2に関連するアップリンクパケットはIF#2上で送信するようにMNを構成する新しい規則を、MNに送ることができる。MNに送られた規則は、アンカが従っている規則とすることができる。このような場合、かつ上の例を続けると、アンカは、フロー#1をIF#1上でMNに送信し、フロー#2をIF#2上でMNに送信することができる。MNに送られた規則は、アンカが従っている規則とは異なる規則とすることもできる。このような場合、かつ上の例を続けると、アンカは、フロー#1およびフロー#2をIF#1上でMNに送信することができる。MNは、アンカ規則とは異なるMN規則に従って、フロー#1パケットをIF#1上で送信し、フロー#2パケットをIF#2上で送信することができる。すなわち、MNは、入来パケットに対するパケットフィルタリングを実施せずに、その構成に従って(例えばその構成規則に従って)ULパケットを送信することができる。
規則構成は、アンカによってMNに対して実施することができる。MNがアンカ上の規則を動的に構成する場合、MNは、フロートランスポート(例えば、MNによって制御されるIPフローモビリティ、MNによって制御されるインタフェースハンドオーバなど)を制御することができる。
規則の動的構成により、種々の状況(例えばネットワーク条件や時刻など)への適合を実現することができる。プッシュする(例えば通知を送る)ことができる可能性をもたらすプロトコルを、MNまたはアンカによって使用することができる。情報の交換中に、ネットワーク中の制御エンティティが関与することができる。このような交換のために、サービングノード(例えばMAG)を使用することができる。例として、規則は、OMA DM、DHCP、ICMP、802.21、IKEv2、IPCPなどにおいて提供される方法を介して、送信することができる。
例えばMNからネットワークへ、またはネットワークからMNへ、規則を動的に構成するように、OMA DMを修正することができる。OMA DMサーバ機能は、アンカ、サービングノード、外部OMA DMサーバ(例えばANDSF)などにおいて実施することができる。
ANDSFは、MN、および/または、アンカ/サービングノードに、規則をプッシュすることができる。アンカは、例えばネットワーク特有プロトコル(例えばPMIPv6、GTPなど)またはOMA DMを使用して、サービングノードに(またはその逆に)規則をプッシュすることができ、サービングノードは、OMA DMを使用してこれらの規則をMNに転送することができる。OMA DMは、MNおよびネットワーク上で最初に規則を構成する間に使用することができ、かつ/または、規則の動的構成に使用することができる。
通知(プッシュ)に関係して、トリガヘッダ/ユーザ対話モード(uiモード)中で構成されることになる新しいモードを提供することができる。構成が読み取られる準備ができていることを言明するための、新しい値を提供することができる(例えば、read immediately−immediate management action)。読取準備完了の場合、情報を取り出す準備ができているものとすることができ、管理セッションを確立する必要があるものとすることができる。トリガ本体/ベンダ特有フィールドに情報が含まれていることを言明するための、新しい値を提供することができる。この情報はメッセージ自体の内で搬送されるので、このメッセージが受け取られたとき、管理アクションは必要とされなくてよく、かつ/または管理セッションを確立する必要はなくてよい。
トリガ本体/ベンダ特有フィールド中で搬送されることになる規則のフォーマットを提供することができる。例として、規則は、ACTION+RULE+PARAMSのフォーマットに従うことができる。ACTIONは、追加、修正、または削除を指定することができる。規則は、TLVまたは他のタイプの表現を使用できることを指定することができる。例えば、関連する規則と共に、アクションを送ることができる(追加、修正、削除)。規則には番号を付けることができ、動的な構成の間の交換は、番号(複数可)に制限することができる。
以下は、構成できる規則の例である。すなわち、1=受信したのと同じインタフェース上でIPフローを送信する、2=あるIPフローをIF#X上で送信する、3=TCP ACKをIF#X上で送る、4=制御メッセージをIF#X上で送信する、5=IPフローを最も速いインタフェース上で送信する、6=IPフローを最も安価なインタフェース上で送信する、7=ウィンドウイング方法を使用する、8=ヒステリシスウィンドウを使用する、などである。規則には名前を付けることができる(例えば番号の代わりに文字列)。
以下は、PARAMSの例である。PARAMは、5タプル(例えば、IPソースアドレス、IP宛先アドレス、IPソースポート、IP宛先ポート、プロトコルタイプ)とすることができる。PARAMは、例えばIPv6が使用される場合には、6タプルとすることができる(例えば、5タプル+IPフローレベル)。PARAMは、構成された規則に依存し得る値とすることができ、例えば、構成された規則=ウィンドウイング方法またはヒステリシスウィンドウである場合は、ウィンドウサイズ値とすることができる。PARAMは、例えば規則が上に指定された2、3、または4である場合には、インタフェース識別子とすることができる。PARAMは、パケットフィルタリングのためにチェックすることのできる別のフィールドとすることができる。これはTCP/IPヘッダに限定されなくてよい。
1つまたは複数のコード化修正が必要とされる場合がある。既存のカテゴリは、以下を含むことができる。
<X>/ISRP/<X>/ForFlowBased/<X>/RoutingRule/<X>/
フィールドを追加することができ、フィールドは以下のうちの1つまたは複数を含むことができる。
<X>/ISRP/<X>/ForFlowBased/<X>/RoutingRule/<X>/ConfiguredRule
Values:<本明細書に開示されるような「RULE」について定義された値、例えば1〜8とすることができる>
<X>/ISRP/<X>/ForFlowBased/<X>/RoutingRule/<X>/Params
<X>/ISRP/<X>/ForFlowBased/<X>/RoutingRule/<X>/Params/WindowSize
<X>/ISRP/<X>/ForFlowBased/<X>/RoutingRule/<X>/Params/HysteresisValue.
追加されたフィールドのアクセスタイプ(例えば「ACTION」について指定されるような)は、追加、削除、および置換を含むことができるが、これらに限定されない。IPフローを識別するタプルは、<X>/ISRP/<X>/ForFlowBased/<X>/IPFlow/<X>/中で定義することができ、ルーティング規則中に追加する必要はなくてよい。
ICMPを使用して、MNとアンカとの間でLIF規則を交換することができる。この目的で、ICMPメッセージを定義することができる。RS/RA/Echoメッセージが、規則を搬送することができる。規則は、標準に従って「オプション」に追加することができる。実施形態は、ICMPの現バージョンに対して後方互換性を有することができ、例えば、導入されたオプションがサポートされていなければそのオプションをスキップすることができる。
「規則」と呼ばれるオプションを提供することができる。このオプションを使用して、MN上とネットワークノード上のいずれかでLIF規則を構成することができる。規則オプションの例示的なフォーマット、例えばACTION+RULE+PARAMSについて本明細書に述べる。図5に、例示的なコード化フォーマットを示す。図5に示すようなコード化の例は、以下のフィールドのうちの1つまたは複数を含むことができる。すなわち、Type−別のオプションにまだ使用されていない番号(例えば6)と、Length−params長さに依存する変数と、Action−1〜3(例えば本明細書に開示されるような)と、Rule1〜8(例えば本明細書に開示されるような)と、Params−規則(本明細書に開示されるような)に依存し得る変数とである。規則オプションは、複数のアクション、規則、および/またはパラメータを含む場合がある。このオプションは、例えばフィルタメッセージ、RS/RAメッセージ、エコーメッセージなどによって使用することができる。
以下は、ICMPメッセージの例である。フィルタメッセージをMNからアンカに、またはアンカからMNに送信して、規則を追加、修正、または削除することができる。フィルタメッセージは、本明細書に開示されるような「規則」と呼ばれるオプションを含むことができる。フィルタメッセージへの応答として、フィルタ返答メッセージを送信することができる。フィルタ返答メッセージは、要求メッセージから受諾されたフィルタを含むことができる。
更新されるルータ要請および/またはルータ広告メッセージ(RS/RA)を開示することができる。オプションをRS/RAに追加して、ローカルに(例えばMN上とアンカ上のいずれかで)適用されることになるLIF規則を伝達することができる。MNがIPアドレスを有さない場合、RSをルータに送信することができる。オプションは、MNのLIF規則を含むことができる。MNによって受け取られたRAメッセージは、オプション(複数可)中のLIF規則を含むことができる。これらの規則は、ネットワークによって構成された規則、または、RS上でMNによって指定され受諾された規則とすることができる。MNのIPアドレスが取得済みの場合、RSメッセージを使用してLIF規則を修正することができる(MNによる制御)。このような場合、RSメッセージを、アンカ(またはローカルIPアドレスの取得元であるネットワークノード)に、例えば宛先IPアドレス=アンカIPアドレスに送信することができる。関連するRAは、RSからMNに、例えば宛先IPアドレス=MNのIPアドレスに送信することができる。
エコー要求および/またはエコー返答メッセージを使用することができる。これらのメッセージを修正して、データフィールドに加えてオプションを搬送することができる。オプションフィールドは、本明細書に開示されるように定義することができる。
「フローフィルタ」と呼ばれるオプションを提供することができる。フローフィルタは、IPフローモビリティを得るために適用されるフィルタを指定することができる。本明細書に開示されるような規則フォーマット、例えばACTION+RULE+PARAMSを使用することができる。これは、送出パケットがどのインタフェース上で送信されるべきかを決定するのに使用できる、規則および/または関連パラメータのリストを含むことができる。パケットフィルタリングに使用されるフィールドを、PARAMSフィールド中で指定することができる(例えば、5タプルおよび所望の送出インタフェース)。
図6に、例示的なコード化フォーマットを示す。これは、どのように規則フォーマットを定義できるかの例である。他のフォーマットを選択して同様の挙動を達成することもできる(例えばアクションのリスト。これは、規則のリストに加えてコード化することができる)。図6に示すように、規則フォーマットは、規則フォーマット=CODE_FLOW_FILTER LEN ACTION RULE PARAMSとすることができる。
図6の例では、
CODE_FLOW_FILTER=100
Len=n(nは長さを表すことができる)
Actionは、値、例えば番号とすることができ、番号はアクションを表すことができる。例えば、1〜3の範囲を提供することができ、追加=1、修正=2、および削除=3である。
Ruleは、値、例えば番号とすることができ、番号はある規則を表すことができ、この規則は、表1に示すように、パラメータおよび/または長さに関連するものとすることができる。
図7に、2つの規則を追加する例示的な規則フォーマットを示す。図7において、上の例を続けると、アクションは、追加アクションを示す1としてリストされている。2つの規則インジケータがある。第1の規則インジケータは1としてリストされており、これは、IPフローが、それが受信されたインタフェース上で送信されることを示す。第2の規則インジケータは7としてリストされており、これはウィンドウイング方法の使用を示す。第2の規則の後には、3としてリストされた値指示が続き、これは、ウィンドウサイズが3であることを示す。規則フォーマットは、図7の例で示すように様々な方法で変更することができる。
DHCPDISCOVER、DHCPOFFER、DHCPREQUEST、DHCPACK、DHCPINFORMなどのメッセージを使用して、IPv4環境で規則をトランスポートすることができる。以下の例は、説明的なものである。DHCPDISCOVERメッセージは、本明細書に開示されるようなオプションを使用して規則を指定することができる(例えばMNによる制御)。DHCPOFFERメッセージは、本明細書に開示されるようなオプションを使用して、規則をトランスポートすることができる(例えば、受諾されたMN規則(拒否された規則は含まれない)と、アンカ規則とのいずれか)。DHCPREQUESTメッセージは、本明細書に開示されるようなオプションを使用して、規則をトランスポートすることができる(例えば、修正された規則(MNによる制御)と、DHCPOFFER上でアンカから受信された受諾済み規則とのいずれか)。これらは、MNが規則を修正する必要があるときに送信することができる。例えば、DHCPリニューアルトリガを待機する必要はなくてよい。DHCPACKメッセージは、DHCPREQUESTまたはDHCPINFORMを使用してトランスポートされてアンカによって受諾された規則を含むことができる。これは、アンカ規則を含むことができる。拒否された規則は含まれないものとすることができる。DHCPサーバは、DHCPACKメッセージを使用して、新しい/修正された規則を構成することができる。この場合、MNは、受諾された規則を含むDHCPREQUESTまたはDHCPINFORMを送り返すことができる。拒否された規則は含まれないものとすることができる。DHCPINFORMメッセージは、本明細書に開示されるようなオプションを使用して規則を指定することができる(例えばMNによる制御)。
IPv6環境におけるDHCPの使用は、種々のメッセージを利用することができる。以下は、本明細書に開示されるようなオプションを搬送することのできる例示的なメッセージである。DHCPSOLICITメッセージは、オプションを使用して規則を指定することができる(例えばMNによる制御)。DHCPADVERTISEメッセージは、オプションを使用して規則をトランスポートすることができる(例えば、受諾されたMN規則(拒否された規則は含まれないものとすることができる)と、アンカ規則とのいずれか)。DHCPREQUEST/DHCPRENEW/DHCPREBINDメッセージは、本明細書に開示されるようなオプションを使用して、規則をトランスポートすることができる(例えば、修正された規則(MNによる制御)と、受諾された規則(DHCPADVERTISEまたはDHCPREQUEST上でアンカから受信された)とのいずれか)。このメッセージは、MNが規則を修正しなければならないときに送信することができる。DHCPREPLYメッセージは、アンカによって受諾された、MNによって構成された規則を含むことができ、拒否された規則を含まないものとすることができる。このメッセージは、アンカ規則を含むことができる。DHCPサーバは、DHCPRECONFOGUREメッセージを使用して、新しい/修正された規則を構成することができる。この場合、MNは、現在使用されている規則を含むDHCPRENEWまたはDHCPINFORMATION−REQを送り返すことができる。次いでDHCPサーバは、DHCPREPLYメッセージを使用して、構成されることになる規則を送り返すことができる。DHCPINFORMATION−REQメッセージは、本明細書に開示されるようなオプションを使用して、規則を指定することができる(例えばMNによる制御)。
DHCPサーバは、サービングノードと同じ場所に位置することができる。規則は、サービングノードとアンカノードとの間で送信することができる(例えばPMIPv6またはGTPを使用して)。MNは、DHCPクライアントとしての役割を果たすことができる。DHCPサーバは、アンカノードと同じ場所に位置することができ、規則は、アンカからサービングノードに転送することができる(例えばPMIPv6またはGTPを使用して)。MNは、DHCPクライアントとしての役割を果たすことができる。DHCPサーバは、外部ノード中で実現することができ、MNおよびアンカは、DHCPクライアントとしての役割を果たして、規則を取得および/または構成することができる。サービングノードは、DHCPを使用して、DHCPサーバと直接に対話することができ、またはアンカと対話することができる(例えばPMIPv6もしくはGTPを使用して)。
IEEE標準802.21を使用して、MNとネットワークとの間で規則をトランスポートすることができる。これは、いくつかの方法で、例えばコマンドサービス(CS)、イベントサービス(ES)、情報サービス(IS)などを使用して実施することができる。CS、ES、および/またはISを扱うMIHサーバは、ネットワーク上の別個のノード(例えばANDSF)中に位置することができ、または、アンカ(例えばLMA)もしくはサービングノード(例えばMAG)と同じ場所に位置することができる。IEEE標準802.21を使用して、例えばMNからネットワークへ、および/またはネットワークからMNへ、規則を動的に構成することができる。一例では、IEE802.21シグナリングを使用して、MNからMAGにフィルタを搬送することができる。
本明細書に開示するメッセージの組合せを利用することができる。例えば、CS、ES、ISなどの組合せを使用することができる。コマンドサービスに関しては、メッセージMIH_Link_Configure_Threshold要求/応答を使用して、規則を構成することができる。パラメータにおけるいくつかの修正が必要とされる場合がある。例えば、追加のパラメータタイプ、例えばLINK_PARAM_LIF_RULEを受諾するように、LINK_PARAM_TYPEを修正することができる。「all」を有効値として受諾するように、LINK_TYPEを修正することができる。追加のメッセージ、例えばMIH_Set_Parameters要求/応答を導入することができ、例えば、LIF規則をサポートするようにLINK_PARAM_TYPEを修正することができる。
情報サービスに関しては、MIH_Push_Information指示メッセージを使用して、LIF規則をトランスポートすることができる。このメッセージは、MNまたはネットワークが、それぞれネットワークまたはMN上で規則を動的にプッシュするのに使用することができる。MIH_Set_Information要求/応答メッセージを追加することができる。これらのメッセージは、GETの代わりにSETを行えることを除いては、既存のMIH_Get_Information要求/応答メッセージと同様とすることができる。
これらのメッセージの組合せは、例えば、ネットワーク中の別個のノードを使用して802.21 ISが実施される場合に使用することができる。例としては以下を含めることができる。アンカがMN上の規則を構成したい場合、MIH_Set_Information要求を使用して、802.21 ISノード上の情報を設定することができる。次いでこのノードは、MIH_Push_Information指示を使用して、MN上の規則を構成することができる。アンカノードが、MIH_PushInformation指示を使用して、独立ノード上のLIF規則を構成することができ、独立ノードは、MIH_Push_Information指示を使用して、新しい構成要素が利用可能であることをMNに知らせることができる。MNは、LIF規則を照会するための新しいパラメータにより、既存のMIH_Get_Information要求を使用してネットワークノードに照会することができる。LIF規則を搬送するように、MIH_Get_Information応答を修正することができる。
イベントサービスに関しては、MIH_Link_Parameter_Report指示を使用して、LIF規則をトランスポートすることができる。新しいメッセージ、例えばMIH_New_Config指示を導入することができる。
MN上とアンカ上とで異なる規則を適用することによって、LIF挙動を向上させることができる。例えば、アンカは、ダウンリンクパケットがIF#1上で送信される(例えば所与のフローについて)ことを言明する規則を有してよく、MNは、アップリンクパケットがIF#2上で送信される(例えばこのフローについて)ことを言明する規則で構成されてよい。
複数の規則(例えば多数)を組み合わせることができる。複数の規則には、優先順位を付けることができる。これらの規則は、優先順位付けに従って使用することができる。以下は、複数の規則を使用する例である。ダウンリンクパケットが受信されたインタフェース上でアップリンクパケットを送信する規則などの規則を、本明細書に述べるウィンドウイング機構と組み合わせることができる。ウィンドウサイズは、関連する規則と同時に構成することができる。
複数の規則が、種々の情報タイプに関係する場合がある。最も信頼性の高いインタフェース(例えばIF#1)上で制御パケットが送信されるという規則などの規則を、最も速いインタフェース(例えばIF#2)上でデータが送信されるという規則と組み合わせることができる。これらの規則は、MN上および/またはアンカ上で適用することができる。
規則は、送信のタイプに基づいて優先順位付けすることができる。ある規則は、再送(例えばTCPレイヤによって実施される)が、最も信頼性の高いリンク上で送信され、通常のトラフィックが、最も速いかまたは最も安価なリンク上で送信されるように、優先順位付けを提供することができる。このような規則は、MNおよび/またはアンカ上で構成することができる。
規則は、時間(例えば時刻)および/コスト(例えば情報を送信するコスト)に基づいて優先順位付けすることができる。ある規則は、午前9時から午後5時までは、最も速いインタフェース(例えばIF#1)上でパケットが送信され、残りの時間帯は、最も安価なインタフェース(例えばIF#2)上でパケットが送信されるように、優先順位付けを提供することができる。これは例えば、仕事中は最も速いおよび/または制限のないリンクを使用し、仕事中以外は最も安価なリンクに切り替えるために行うことができる。
ある規則は、ノードが、関連パケットを受信したインタフェース上でパケットを送信することを言明することができる(例えばミラーリング規則)。このような規則は、MNおよび/またはアンカに適用することができる。以下は例である。アンカは、アップリンクパケットを受信したインタフェース上でダウンリンクパケットを送信するという規則で構成されてよい。この規則は、アンカ上での構成に限定することができる。このような規則は、シグナリングメッセージを必要とすることなく、MNによって制御されるIFOMを可能にすることができ、例えば、MNが、どこにパケットを送信するかを決定し、アンカはMNの決定に従う。
論理インタフェース挙動を使用して、IPフローモビリティを可能にすることができる。例えば、IPフローを、あるインタフェースから別のインタフェースに独立して移動することができ、アプリケーションはこの移動に気付かない。論理インタフェースは、インタフェースが変更しつつあるより高いレイヤから隠れることができる。フロー同士を接着することができ、それにより、あるフローが移動されるとき、接着されたフローも同じようにして移動されてよい。接着されるフローは、例えば、アプリケーションに関連するフロー、または、アプリケーションに関連するフローのサブセットとすることができる(例えば、アプリケーションが3つのアクティブなフローを有し、これらのうちの2つは共に接着され、他の1つは独立している場合がある)。
ネットワークは、いつフローが移動されることになるか、どのインタフェースにフローが移動されるべきか、他のどのフローが同時に移動されることになるか(例えば接着されたフロー)などを決定することができる。MN上で実装されるLIFモジュールは、ネットワーク決定をミラーリングするために待機することができる。LIFモジュールは、フロー移動をアップリンクパケットに適用するまで一定時間待機して、接着されたフローが入来方向で移動される機会を与え、次いで、送出インタフェース変更を、影響を受けるフローに同時に適用することができる。LIFモジュールは、どのフロー同士が接着されているかを意識する必要はなくてよい。このような場合、このことを知っている必要性は、ネットワークに限定することができる。というのは、モバイル上のLIFモジュールは、ネットワークによって開始された移動をミラーリングしていることができるからである。どのフロー同士が接着されているかをモバイル上のLIFモジュールが知っている場合、LIFモジュールは、移動したフローについてのフロー移動をミラーリングし、接着されたフローに対して同じ移動を自律的に開始することができる。上記の手順は、モバイルとネットワークとの間で役割が反転された状態で適用することもできる。
ネットワークおよびモバイルは、フロー移動を開始する能力を有することができる。競合解決を提供することができる。ネットワークは、フロー(例えばフロー#1)を特定のインタフェースXに移動することを必要とする場合があり、モバイルは、フロー#1に接着されている別のフロー(例えばフロー#2)を別のインタフェースYに移動することを要求する(例えば、モバイルとネットワークとからの移動決定が許される場合)。この場合、モバイルまたはネットワークに優先権を与えることができ、例えば、ネットワークが移動の最終決定を有することができる。優先権は、ポリシに構成することができる。この例では、ネットワークが優先権を有することができる。前述の場合では、フロー#1はインタフェースXに移動されることになり、フロー#2をインタフェースYに移動することは拒否されることになる。というのは、この2つのフローは接着されており、この例ではネットワークがモバイルよりも優先されるからである。
最初のフロー移動を受諾し、競合する後続のフロー移動を拒否する技法を実施することができる。IPパケット中のタイムスタンプを使用して、どのフロー移動が最初のフロー移動かを決定することができる。
接着されたフローの識別を提供することができる。IPフローは、多くの方法で識別することができる。5タプルを使用することができる。すなわち、IPソースアドレス、IP宛先アドレス、ソースポート、宛先ポート、およびプロトコルである。他のフィールドを使用することもでき、これら他のフィールドはポリシによって構成することができる。以下の考察では、5タプルを使用してIPフローが識別されるものとすることができる。
フロー接着は、モバイル側で実施することができる。フローは、モバイル上でアプリケーションによってまたはフロー管理エンティティによって共に接着することができる。アプリケーションがフローを意識している場合、アプリケーションは、ソケットを開くときにフィールド(複数可)を指定して、アプリケーション自体(例えばapplicationID)と、ソケットまたはこの5タプルに関連する場合のあるフローグループ(flowGroup)とを識別することができる。LIFモジュールは、この情報で構成されてよく、この情報をその既存のマッピングテーブルに統合することができる。例えば、表2は例示的なLIFマッピングテーブルであり、表2では、最初の2つの識別されたフローを接着することができる(表2の行2および3)。
アプリケーションは、それらのフローを、ソケットAPIとは別のインタフェースを使用して構成することができる。フロー管理エンティティが、アプリケーションのフローを動的に構成するためにアプリケーションによって呼び出すことができる関数、例えばFlowConfig(ApplicationID,FlowGroup)をエクスポートすることができる。LIFモジュールは、構成関数、例えばLIF_FlowConfig(ApplicationID,FlowGroup)をエクスポートすることができる。アプリケーションが、フローを意識しないレガシーアプリケーションである場合、フローは宛先IPアドレスに基づいて接着することができ、宛先IPアドレスは、コンテンツプロバイダを識別することができる。この場合、同じ宛先に行くフロー同士が接着されることになる。
フロー接着は、ネットワーク側で実施することができる。ネットワーク側のフロー移動制御ノードは、IPパケットを見ることによってアプリケーションに関する情報を得ることはない場合がある。このノードはソースIPアドレスを知るかもしれないが、これによってアプリケーションが識別されることはない場合がある。フローをアプリケーションに関連付けてからフロー同士を接着することができるためには、ネットワークノードは、IPパケットを調べる前に情報を受け取る必要がある場合がある。アプリケーション/フローに関するこの追加情報は、モバイルから構成機構を介して受け取ることができる。
ApplicationIDおよびFlowGroupを指定するために、ヘッダをIPパケット中で提供することができる。ヘッダは、アプリケーションデータとトランスポートヘッダ(例えばUDP/TCP)との間に追加することができる。ApplicationIDおよびFlowGroupは、ここで指定することができる。ネットワークノードは、この情報を抽出して、内部フロー接着テーブルを構築することができる場合がある。このようなヘッダが使用されることになるかどうかは、ポリシが指定することができる。