(57)【要約】モバイルノードを構成するためのシステム、方法、および手段を開示する。モバイルノードが、構成メッセージを受信することができる。構成メッセージは、ＡＮＤＳＦ（ａｃｃｅｓｓ  ｎｅｔｗｏｒｋ  ｄｉｓｃｏｖｅｒｙ  ａｎｄ  ｓｅｌｅｃｔｉｏｎ  ｆｕｎｃｔｉｏｎ）から受信することができ、ＡＮＤＳＦは、ＯＭＡ  ＤＭ（ｏｐｅｎ  ｍｏｂｉｌｅ  ａｌｌｉａｎｃｅ  ｄｅｖｉｃｅ  ｍａｎａｇｅｍｅｎｔ）サーバの一部とすることができる。構成メッセージは、モバイルノード規則を含むことができる。モバイルノードは、モバイルノード規則に従ってモバイルノードの構成を変更することができる。モバイルノード規則は、モバイルノードが、あるインタフェース上でアップリンクパケットを送信すべきであることを示すことができる。モバイルノードは、モバイルノード規則によって示されるインタフェースを介して、アップリンクパケットを送信することができる。
2014509495.tif 000002
【特許請求の範囲】
【請求項１】
モバイルノードに関連する論理インタフェース（ＬＩＦ）を構成する方法であって、
アクセスネットワーク発見・選択の機能（ＡＮＤＳＦ）から構成メッセージを受信するステップであって、前記構成メッセージがモバイルノード規則を含み、前記構成メッセージがオープン・モバイル・アライアンスのデバイス管理（ＯＭＡ  ＤＭ）メッセージである、ステップと、
前記モバイルノード規則に従って前記モバイルノードの構成を変更するステップと、
前記モバイルノード規則によって示されるインタフェースを介してアップリンクパケットを送信するステップと
を含む、方法。
【請求項２】
前記インタフェースは、ダウンリンクインタフェースとは異なる、請求項１に記載の方法。
【請求項３】
前記構成メッセージは、前記モバイルノードからのフィードバックに基づく、請求項１に記載の方法。
【請求項４】
前記モバイルノード規則は、アンカノード規則とは異なる、請求項１に記載の方法。
【請求項５】
前記モバイルノード規則は、アンカノード規則と一致する、請求項１に記載の方法。
【請求項６】
前記モバイルノード規則は、複数のモバイルノード規則のうちの１つである、請求項１に記載の方法。
【請求項７】
前記複数のモバイルノード規則は、優先順位付けされ、前記優先順位付けは、データタイプ、時刻、コストのうちの１つまたは複数に基づく、請求項６に記載の方法。
【請求項８】
前記構成メッセージは、アクションおよびパラメータを含む、請求項１に記載の方法。
【請求項９】
前記アップリンクパケットに関連する接着フローを決定するステップと、
前記モバイルノード規則によって示される前記インタフェースを介して前記接着フローを送信するステップと
をさらに含む、請求項１に記載の方法。
【請求項１０】
アクセスネットワーク発見・選択の機能（ＡＮＤＳＦ）から構成メッセージを受信するように構成された受信機であって、前記構成メッセージがモバイルノード規則を含み、前記構成メッセージがオープン・モバイル・アライアンスのデバイス管理（ＯＭＡ  ＤＭ）メッセージである、受信機と、
前記モバイルノード規則に従って前記モバイルノードの構成を変更するように構成されたプロセッサと、
前記モバイルノード規則によって示されるインタフェースを介してアップリンクパケットを送信するように構成された送信機と
を備える、モバイルノード。
【請求項１１】
前記インタフェースは、ダウンリンクインタフェースとは異なる、請求項１０に記載のモバイルノード。
【請求項１２】
前記構成メッセージは、前記モバイルノードからのフィードバックに基づく、請求項１０に記載のモバイルノード。
【請求項１３】
前記モバイルノード規則は、アンカノード規則とは異なる、請求項１０に記載のモバイルノード。
【請求項１４】
前記モバイルノード規則は、アンカノード規則と一致する、請求項１０に記載のモバイルノード。
【請求項１５】
前記モバイルノード規則は、複数のモバイルノード規則のうちの１つである、請求項１０に記載のモバイルノード。
【請求項１６】
前記複数のモバイルノード規則は、優先順位付けされ、前記優先順位付けは、データタイプ、時刻、コストのうちの１つまたは複数に基づく、請求項１５に記載のモバイルノード。
【請求項１７】
前記構成メッセージは、アクションおよびパラメータを含む、請求項１０に記載のモバイルノード。
【請求項１８】
前記プロセッサは、前記アップリンクパケットに関連する接着フローを決定するようにさらに構成され、前記送信機は、前記モバイルノード規則によって示される前記インタフェースを介して前記接着フローを送信するようにさらに構成される、請求項１０に記載のモバイルノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本願発明は、拡張／向上した論理インタフェース挙動のためのシステムおよび方法に関する。
【背景技術】
【０００２】
（関連出願の相互参照）
本出願は、２０１１年２月１１日に出願された米国特許仮出願第６１／４４１，８９５号明細書の利益を主張するものであり、この仮出願の内容は参照により本明細書に組み込まれる。
【０００３】
ネットワークベースのＩＰフローモビリティとは、データフローがネットワークエンティティによってどのように扱われるかを指すものとすることができる。現在、データフローの管理における問題がある。
【発明の概要】
【０００４】
この概要は、例示的な実施形態の詳細な説明においてさらに後述する概念の精選を、単純化した形で提供するものである。この概要は、特許請求する主題の重要な特徴または主要な特徴を特定するものとはせず、また、特許請求する主題の範囲を限定するのに使用されるものともしない。
【０００５】
モバイルノードを構成する（モバイルノードに関連する論理インタフェース（ＬＩＦ）を構成することを含み得る）ためのシステム、方法、および手段を開示する。モバイルノードが、構成メッセージを受信することができる。構成メッセージは、ＡＮＤＳＦ（ａｃｃｅｓｓ  ｎｅｔｗｏｒｋ  ｄｉｓｃｏｖｅｒｙ  ａｎｄ  ｓｅｌｅｃｔｉｏｎ  ｆｕｎｃｔｉｏｎ）から受信することができ、ＡＮＤＳＦは、ＯＭＡ  ＤＭ（ｏｐｅｎ  ｍｏｂｉｌｅ  ａｌｌｉａｎｃｅ  ｄｅｖｉｃｅ  ｍａｎａｇｅｍｅｎｔ）サーバの一部とすることができる。構成メッセージは、モバイルノード規則を含むことができる。例えば、構成メッセージは、どのようにモバイルデバイスが入来フローまたは送出フローを扱うことになるか（例えば、使用するインタフェース、処理方法など）を示すことができる。構成メッセージは、ＯＭＡ  ＤＭ（ｏｐｅｎ  ｍｏｂｉｌｅ  ａｌｌｉａｎｃｅ  ｄｅｖｉｃｅ  ｍａｎａｇｅｍｅｎｔ）メッセージとすることができる。構成メッセージは、モバイルノードからのフィードバックに基づくことができる。構成メッセージは、アクションおよびパラメータを含むことができる。
【０００６】
モバイルノードは、モバイルノード規則に従って構成を変更することができる。モバイルノード規則は、モバイルノードが、あるインタフェース上でアップリンクパケットを送信すべきであることを示すことができる。モバイルノードは、モバイルノード規則によって示されるインタフェースを介して、アップリンクパケットを送信することができる。例として、構成メッセージ受信前は、モバイルノードは、関連するダウンリンクパケットが受信された物理インタフェース上で、アップリンクパケットを送信するように構成されていた場合がある。受信された構成メッセージに応答して、モバイルノードは、関連するダウンリンクパケットが受信された物理インタフェースとは異なる物理インタフェース上で、アップリンクパケットを送信することができる。
【０００７】
モバイルノードの構成は、ローカルモビリティアンカ（ＬＭＡ）などのアンカノードによって実施することができる。アンカにおいて、ＯＭＡ  ＤＭサーバ機能を実施することができる。構成メッセージ中のモバイルノード規則は、関係するアンカノード規則と一致してよく、または、関係するアンカノード規則とは異なってよい。
【０００８】
モバイルノード規則は、複数のモバイルノード規則のうちの１つとすることができる。複数のモバイルノード規則には、優先順位を付けることができる。例えば、優先順位付けは、データタイプ、時刻、コストのうちの１つまたは複数に基づくことができる。
【図面の簡単な説明】
【０００９】
添付の図面と共に例として提供する後続の記述から、より詳細な理解を得ることができる。
【００１０】
【図１Ａ】１つまたは複数の開示する実施形態をその中で実現できる例示的な通信システムのシステム図である。
【図１Ｂ】図１Ａに示す通信システム内で使用できる例示的なワイヤレス送受信ユニット（ＷＴＲＵ）のシステム図である。
【図１Ｃ】図１Ａに示す通信システム内で使用できる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。
【図１Ｄ】図１Ａに示す通信システム内で使用できる別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。
【図１Ｅ】図１Ａに示す通信システム内で使用できる別の例示的な無線アクセスネットワークおよび別の例示的なコアネットワークのシステム図である。
【図２】例示的な論理インタフェース実装を示す図である。
【図３】ネットワークによって制御されるＩＰフローモビリティシーケンスの例示的な流れ図である。
【図４】デバイス管理プロトコルの段階の例示的な流れ図を示す図である。
【図５】例示的なコード化フォーマットを示す図である。
【図６】例示的なコード化フォーマットを示す図である。
【図７】例示的なコード化フォーマットを示す図である。
【発明を実施するための形態】
【００１１】
次に、図を参照しながら、例証的な実施形態に関する詳細な説明を述べる。しかし、本発明を例示的な実施形態に関して述べる場合があるが、本発明はこれらの実施形態に限定されず、本発明を逸脱することなく、本発明と同じ機能を実施するために、他の実施形態を使用してもよいこと、または述べる実施形態に修正および追加を行ってもよいことを理解されたい。加えて、図にはコールフローを示す場合があるが、これらは例示的であるものとする。他の実施形態を使用してもよいことを理解されたい。フローの順序は、適宜変えてもよい。また、フローが必要でなければ省略してもよく、追加のフローを加えてもよい。
【００１２】
図１Ａは、１つまたは複数の開示する実施形態をその中で実現できる例示的な通信システム１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のワイヤレスユーザに提供する、多元接続システムとすることができる。通信システム１００は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含めたシステムリソースの共有を通してこのようなコンテンツにアクセスするのを可能にすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）など、１つまたは複数のチャネルアクセス方法を採用することができる。
【００１３】
図１Ａに示すように、通信システム１００は、ワイヤレス送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄ（一般にまたは一括してＷＴＲＵ１０２と呼ぶ場合がある）と、無線アクセスネットワーク（ＲＡＮ）１０３／１０４／１０５と、コアネットワーク１０６／１０７／１０９と、公衆交換電話網（ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含んでよいが、開示する実施形態が任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することは理解されるであろう。各ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス環境で動作および／または通信するように構成された任意のタイプのデバイスとすることができる。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信および／または受信するように構成されてよく、ユーザ機器（ＵＥ）、移動局、固定またはモバイルの加入者ユニット、ページャ、セルラー電話機、パーソナルディジタルアシスタント（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、消費者電子機器などを含み得る。
【００１４】
通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂを含んでよい。各基地局１１４ａ、１１４ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つとワイヤレスにインタフェースして、コアネットワーク１０６／１０７／１０９、インターネット１１０、および／またはネットワーク１１２など、１つまたは複数の通信ネットワークへのアクセスを容易にするように構成された、任意のタイプのデバイスとすることができる。例として、基地局１１４ａ、１１４ｂは、ベーストランシーバステーション（ＢＴＳ）、ノードＢ、ｅノードＢ、ホームノードＢ、ホームｅノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ワイヤレスルータなどとすることができる。基地局１１４ａ、１１４ｂはそれぞれ単一の要素として描かれているが、基地局１１４ａ、１１４ｂが任意の数の相互接続された基地局および／またはネットワーク要素を含んでよいことは理解されるであろう。
【００１５】
基地局１１４ａはＲＡＮ１０３／１０４／１０５の一部とすることができ、ＲＡＮ１０３／１０４／１０５はまた、他の基地局、および／または、基地局コントローラ（ＢＳＣ）や無線ネットワークコントローラ（ＲＮＣ）や中継ノードなどのネットワーク要素（図示せず）を含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理領域内でワイヤレス信号を送信および／または受信するように構成されてよく、この地理領域はセル（図示せず）と呼ばれることもある。セルはさらに、セルセクタに分割することができる。例えば、基地局１１４ａに関連するセルを３つのセクタに分割することができる。したがって、一実施形態では、基地局１１４ａは、３つの送受信機、すなわちセルの各セクタにつき１つの送受信機を備えることができる。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用することができ、したがって、セルの各セクタにつき複数の送受信機を利用することができる。
【００１６】
基地局１１４ａ、１１４ｂは、エアインタフェース１１５／１１６／１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数と通信することができ、エアインタフェース１１５／１１６／１１７は、任意の適切なワイヤレス通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）とすることができる。エアインタフェース１１５／１１６／１１７は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立することができる。
【００１７】
より具体的には、上に言及したように、通信システム１００は、多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなど、１つまたは複数のチャネルアクセス方式を採用することができる。例えば、ＲＡＮ１０３／１０４／１０５中の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＴＲＡ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ（ＵＭＴＳ）Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）などの無線技術を実装することができ、これにより、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインタフェース１１５／１１６／１１７を確立することができる。ＷＣＤＭＡ（登録商標）は、ＨＳＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ）および／またはＨＳＰＡ＋（Ｅｖｏｌｖｅｄ  ＨＳＰＡ）などの通信プロトコルを含み得る。ＨＳＰＡは、ＨＳＤＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ  Ｄｏｗｎｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ）および／またはＨＳＵＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ  Ｕｐｌｉｎｋ  Ｐａｃｋｅｔ  Ａｃｃｅｓｓ）を含み得る。別の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、Ｅ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ  ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）などの無線技術を実装することができ、これにより、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）および／またはＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄ）を使用してエアインタフェース１１５／１１６／１１７を確立することができる。
【００１８】
他の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわちＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００  １Ｘ、ＣＤＭＡ２０００  ＥＶ−ＤＯ、ＩＳ−２０００（Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ  ２０００）、ＩＳ−９５（Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ  ９５）、ＩＳ−８５６（Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ  ８５６）、ＧＳＭ（登録商標）（Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＥＤＧＥ（Ｅｎｈａｎｃｅｄ  Ｄａｔａ  ｒａｔｅｓ  ｆｏｒ  ＧＳＭ  Ｅｖｏｌｕｔｉｏｎ）、ＧＳＭ  ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装することができる。
【００１９】
図１Ａ中の基地局１１４ｂは、例えばワイヤレスルータ、ホームノードＢ、ホームｅノードＢ、またはアクセスポイントとすることができ、事業所、家庭、車両、キャンパスなどの局所化されたエリア中でのワイヤレス接続性を容易にするために任意の適切なＲＡＴを利用することができる。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を確立することができる。別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を確立することができる。さらに別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラーベースのＲＡＴ（例えばＷＣＤＭＡ（登録商標）、ＣＤＭＡ２０００、ＧＳＭ（登録商標）、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立することができる。図１Ａに示すように、基地局１１４ｂは、インターネット１１０への直接接続を有することができる。したがって、基地局１１４ｂは、コアネットワーク１０６／１０７／１０９を介してインターネット１１０にアクセスすることは必要とされなくてよい。
【００２０】
ＲＡＮ１０３／１０４／１０５は、コアネットワーク１０６／１０７／１０９と通信してよく、コアネットワーク１０６／１０７／１０９は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に提供するように構成された、任意のタイプのネットワークとすることができる。例えば、コアネットワーク１０６／１０７／１０９は、呼制御、課金サービス、モバイル位置ベースのサービス、前払い電話、インターネット接続性、ビデオ配信などを提供することができ、かつ／または、ユーザ認証など、高レベルのセキュリティ機能を実施することができる。図１Ａには示されていないが、ＲＡＮ１０３／１０４／１０５、および／またはコアネットワーク１０６／１０７／１０９が、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと、直接にまたは間接的に通信してもよいことは理解されるであろう。例えば、コアネットワーク１０６／１０７／１０９は、Ｅ−ＵＴＲＡ無線技術を利用しているであろうＲＡＮ１０３／１０４／１０５に接続されるのに加えて、ＧＳＭ（登録商標）無線技術を採用する別のＲＡＮ（図示せず）と通信してもよい。
【００２１】
コアネットワーク１０６／１０７／１０９はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとしての働きをすることができる。ＰＳＴＮ１０８は、ＰＯＴＳ（ｐｌａｉｎ  ｏｌｄ  ｔｅｌｅｐｈｏｎｅ  ｓｅｒｖｉｃｅ）を提供する回路交換電話網を含み得る。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイート中の、伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスの地球規模のシステムを含み得る。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される、有線またはワイヤレス通信ネットワークを含み得る。例えば、ネットワーク１１２は、ＲＡＮ１０３／１０４／１０５と同じＲＡＴまたは異なるＲＡＴを採用するであろう１つまたは複数のＲＡＮに接続された、別のコアネットワークを含み得る。
【００２２】
通信システム１００中のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつかまたは全ては、マルチモード能力を備えることができる。すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、種々のワイヤレスリンクを介して種々のワイヤレスネットワークと通信するために、複数の送受信機を備えることができる。例えば、図１Ａに示すＷＴＲＵ１０２ｃは、セルラーベースの無線技術を採用するであろう基地局１１４ａと、また、ＩＥＥＥ８０２無線技術を採用するであろう基地局１１４ｂと、通信するように構成されてよい。
【００２３】
図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示すように、ＷＴＲＵ１０２は、プロセッサ１１８、送受信機１２０、送受信要素１２２、スピーカ／マイクロホン１２４、キーパッド１２６、表示装置／タッチパッド１２８、非取外し可能メモリ１３０、取外し可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および他の周辺装置１３８を備えてよい。ＷＴＲＵ１０２が、一実施形態との整合性を維持しながら前述の要素の任意のサブコンビネーションを備えてよいことは理解されるであろう。また、実施形態は、基地局１１４ａおよび１１４ｂ、ならびに／または基地局１１４ａおよび１１４ｂが表すことのできるノード（とりわけ、トランシーバステーション（ＢＴＳ）、ノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ホームノードＢ、発展型（ｅｖｏｌｖｅｄ）ホームノードＢ（ｅノードＢ）、ホーム発展型ノードＢ（ＨｅＮＢ）、ホーム発展型ノードＢゲートウェイ、およびプロキシノードなどだがこれらに限定されない）が、図１Ｂに描かれ本明細書に記述される要素のいくつかまたは全てを備えてよいことを企図する。
【００２４】
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、状態機械などとすることができる。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／または、ＷＴＲＵ１０２がワイヤレス環境で動作できるようにする他の任意の機能を実施することができる。プロセッサ１１８は送受信機１２０に結合されてよく、送受信機１２０は送受信要素１２２に結合されてよい。図１Ｂではプロセッサ１１８と送受信機１２０とを別々のコンポーネントとして描いているが、プロセッサ１１８と送受信機１２０とを共に電子パッケージまたはチップ中で統合してもよいことは理解されるであろう。
【００２５】
送受信要素１２２は、エアインタフェース１１５／１１６／１１７を介して基地局（例えば基地局１１４ａ）との間で信号を送信または受信するように構成されてよい。例えば、一実施形態では、送受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナとすることができる。別の実施形態では、送受信要素１２２は、例えばＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された、エミッタ／検出器とすることができる。さらに別の実施形態では、送受信要素１２２は、ＲＦ信号と光信号の両方を送受信するように構成されてよい。送受信要素１２２が任意の組合せのワイヤレス信号を送信および／または受信するように構成されてよいことは理解されるであろう。
【００２６】
加えて、図１Ｂでは送受信要素１２２が単一の要素として描かれているが、ＷＴＲＵ１０２は、任意の数の送受信要素１２２を備えてよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用することができる。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインタフェース１１５／１１６／１１７を介してワイヤレス信号を送受信するために、２つ以上の送受信要素１２２（例えば複数のアンテナ）を備えることができる。
【００２７】
送受信機１２０は、送受信要素１２２によって送信されることになる信号を変調し、送受信要素１２２によって受信された信号を復調するように構成されてよい。上に言及したように、ＷＴＲＵ１０２は、マルチモード能力を有することができる。したがって、送受信機１２０は、ＷＴＲＵ１０２が複数のＲＡＴ（例えばＵＴＲＡおよびＩＥＥＥ８０２．１１など）を介して通信できるようにするために、複数の送受信機を備えることができる。
【００２８】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロホン１２４、キーパッド１２６、および／または、表示装置／タッチパッド１２８（例えば液晶表示装置（ＬＣＤ）表示ユニットもしくは有機発光ダイオード（ＯＬＥＤ）表示ユニット）に結合されてよく、これらからユーザ入力データを受け取ることができる。プロセッサ１１８はまた、スピーカ／マイクロホン１２４、キーパッド１２６、および／または、表示装置／タッチパッド１２８にユーザデータを出力することができる。加えて、プロセッサ１１８は、非取外し可能メモリ１３０および／または取外し可能メモリ１３２など、任意のタイプの適切なメモリからの情報にアクセスすること、およびそのようなメモリにデータを記憶することができる。非取外し可能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含み得る。取外し可能メモリ１３２は、ＳＩＭ（ｓｕｂｓｃｒｉｂｅｒ  ｉｄｅｎｔｉｔｙ  ｍｏｄｕｌｅ）カード、メモリスティック、ＳＤ（ｓｅｃｕｒｅ  ｄｉｇｉｔａｌ）メモリカードなどを含み得る。他の実施形態では、プロセッサ１１８は、サーバやホームコンピュータ（図示せず）上のメモリなど、ＷＴＲＵ１０２上に物理的に位置しないメモリからの情報にアクセスすること、およびそのようなメモリにデータを記憶することができる。
【００２９】
プロセッサ１１８は、電源１３４から電力を受け取ることができ、ＷＴＲＵ１０２中の他のコンポーネントへの電力を分配および／または制御するように構成されてよい。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の適切なデバイスとすることができる。例えば、電源１３４は、１つまたは複数の乾電池バッテリ（例えばニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル金属水素化物（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池などを含み得る。
【００３０】
プロセッサ１１８は、ＧＰＳチップセット１３６にも結合されてよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば経度と緯度）を提供するように構成されてよい。ＧＰＳチップセット１３６からの情報に加えて、またはそれに代えて、ＷＴＲＵ１０２は、基地局（例えば基地局１１４ａ、１１４ｂ）からエアインタフェース１１５／１１６／１１７を介して位置情報を受け取ることができ、かつ／または、２つ以上の近隣基地局から受け取られている信号のタイミングに基づいてその位置を決定することができる。ＷＴＲＵ１０２が一実施形態との整合性を維持しながら任意の適切な位置決定方法を用いて位置情報を取得してよいことは、理解されるであろう。
【００３１】
プロセッサ１１８はさらに、他の周辺装置１３８にも結合されてよく、周辺装置１３８は、追加の機構、機能、および／または有線もしくはワイヤレス接続性をもたらす、１つまたは複数のソフトウェアおよび／またはハードウェアモジュールを含み得る。例えば、周辺装置１３８は、加速度計、電子コンパス、衛星送受信機、ディジタルカメラ（写真またはビデオ用）、ＵＳＢ（ｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ）ポート、振動デバイス、テレビジョン送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、ディジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含み得る。
【００３２】
図１Ｃは、一実施形態によるＲＡＮ１０３およびコアネットワーク１０６のシステム図である。上に言及したように、ＲＡＮ１０３は、Ｅ−ＵＴＲＡ無線技術を採用して、エアインタフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ１０３はまた、コアネットワーク１０６とも通信することができる。図１Ｃに示すように、ＲＡＮ１０３は、ノードＢ１４０ａ、１４０ｂ、１４０ｃを含んでよく、ノードＢ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、エアインタフェース１１５を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために、１つまたは複数の送受信機を備えてよい。ノードＢ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、ＲＡＮ１０３内の特定のセル（図示せず）に関連してよい。ＲＡＮ１０３は、ＲＮＣ１４２ａ、１４２ｂも含んでよい。ＲＡＮ１０３が一実施形態との整合性を維持しながら任意の数のノードＢおよびＲＮＣを含んでよいことは理解されるであろう。
【００３３】
図１Ｃに示すように、ノードＢ１４０ａ、１４０ｂは、ＲＮＣ１４２ａと通信することができる。加えて、ノードＢ１４０ｃは、ＲＮＣ１４２ｂと通信することができる。ノードＢ１４０ａ、１４０ｂ、１４０ｃは、Ｉｕｂインタフェースを介してそれぞれのＲＮＣ１４２ａ、１４２ｂと通信することができる。ＲＮＣ１４２ａ、１４２ｂは、Ｉｕｒインタフェースを介して相互と通信することができる。各ＲＮＣ１４２ａ、１４２ｂは、それが接続されているそれぞれのノードＢ１４０ａ、１４０ｂ、１４０ｃを制御するように構成されてよい。加えて、各ＲＮＣ１４２ａ、１４２ｂは、アウターループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、データ暗号化など、他の機能も実施またはサポートするように構成されてよい。
【００３４】
図１Ｃに示すコアネットワーク１０６は、メディアゲートウェイ（ＭＧＷ）１４４、移動交換センタ（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／またはゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含んでよい。これらの各要素はコアネットワーク１０６の一部として描かれているが、これらの要素のいずれか１つがコアネットワークオペレータ以外のエンティティによって所有および／または運営されてもよいことは理解されるであろう。
【００３５】
ＲＡＮ１０３中のＲＮＣ１４２ａは、ＩｕＣＳインタフェースを介してコアネットワーク１０６中のＭＳＣ１４６に接続されてよい。ＭＳＣ１４６は、ＭＧＷ１４４に接続されてよい。ＭＳＣ１４６およびＭＧＷ１４４は、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にすることができる。
【００３６】
ＲＡＮ１０３中のＲＮＣ１４２ａはまた、ＩｕＰＳインタフェースを介してコアネットワーク１０６中のＳＧＳＮ１４８に接続されてよい。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続されてよい。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる。
【００３７】
上に言及したように、コアネットワーク１０６はネットワーク１１２にも接続されてよく、ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線またはワイヤレスネットワークを含み得る。
【００３８】
図１Ｄは、一実施形態によるＲＡＮ１０４およびコアネットワーク１０７のシステム図である。上に言及したように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を採用して、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ１０４はまた、コアネットワーク１０７と通信することができる。
【００３９】
ＲＡＮ１０４は、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃを含んでよいが、ＲＡＮ１０４が一実施形態との整合性を維持しながら任意の数のｅノードＢを含んでよいことは理解されるであろう。ｅノードＢ１６０ａ、１６０ｂ、１６０ｃはそれぞれ、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために、１つまたは複数の送受信機を備えることができる。一実施形態では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装することができる。したがって、例えばｅノードＢ１６０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａとの間でワイヤレス信号を送受信することができる。
【００４０】
各ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、特定のセル（図示せず）に関連してよく、無線リソース管理決定、ハンドオーバ決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成されてよい。図１Ｄに示すように、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インタフェースを介して相互と通信することができる。
【００４１】
図１Ｄに示すコアネットワーク１０７は、モビリティ管理ゲートウェイ（ＭＭＥ）１６２、サービングゲートウェイ１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１６６を含んでよい。前述の各要素はコアネットワーク１０７の一部として描かれているが、これらの要素のいずれか１つがコアネットワークオペレータ以外のエンティティによって所有および／または運営されてもよいことは理解されるであろう。
【００４２】
ＭＭＥ１６２は、Ｓ１インタフェースを介してＲＡＮ１０４中の各ｅノードＢ１６０ａ、１６０ｂ、１６０ｃに接続されてよく、制御ノードとしての働きをすることができる。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラをアクティブ化／非アクティブ化すること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの最初の帰属中に特定のサービングゲートウェイを選択することなどを担うことができる。ＭＭＥ１６２はまた、ＲＡＮ１０４と、ＧＳＭ（登録商標）やＷＣＤＭＡ（登録商標）など他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を提供することもできる。
【００４３】
サービングゲートウェイ１６４は、Ｓ１インタフェースを介してＲＡＮ１０４中の各ｅノードＢ１６０ａ、１６０ｂ、１６０ｃに接続されてよい。サービングゲートウェイ１６４は一般に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとの間でユーザデータパケットをルーティングおよび転送することができる。サービングゲートウェイ１６４はまた、ｅノードＢ間のハンドオーバ中にユーザプレーンをつなぎ留めること、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能なときにページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなど、他の機能を実施することもできる。
【００４４】
サービングゲートウェイ１６４はまた、ＰＤＮゲートウェイ１６６に接続されてよく、ＰＤＮゲートウェイ１６６は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる。
【００４５】
コアネットワーク１０７は、他のネットワークとの通信を容易にすることができる。例えば、コアネットワーク１０７は、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にすることができる。例えば、コアネットワーク１０７は、コアネットワーク１０７とＰＳＴＮ１０８との間のインタフェースとしての働きをするＩＰゲートウェイ（例えばＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むか、またはそのようなＩＰゲートウェイと通信することができる。加えて、コアネットワーク１０７は、他のサービスプロバイダによって所有および／または運営される他の有線またはワイヤレスネットワークを含み得るネットワーク１１２へのアクセスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。
【００４６】
図１Ｅは、一実施形態によるＲＡＮ１０５およびコアネットワーク１０９のシステム図である。ＲＡＮ１０５は、ＩＥＥＥ８０２．１６無線技術を採用してエアインタフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信する、アクセスサービスネットワーク（ＡＳＮ）とすることができる。後でさらに論じるように、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、ＲＡＮ１０５、およびコアネットワーク１０９の種々の機能エンティティ間の通信リンクを、基準点として定義することができる。
【００４７】
図１Ｅに示すように、ＲＡＮ１０５は、基地局１８０ａ、１８０ｂ、１８０ｃ、およびＡＳＮゲートウェイ１８２を含んでよいが、ＲＡＮ１０５が一実施形態との整合性を維持しながら任意の数の基地局およびＡＳＮゲートウェイを含んでよいことは理解されるであろう。基地局１８０ａ、１８０ｂ、１８０ｃはそれぞれ、ＲＡＮ１０５中の特定のセル（図示せず）に関連してよく、エアインタフェース１１７を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために、１つまたは複数の送受信機をそれぞれ備えることができる。一実施形態では、基地局１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装することができる。したがって、例えば基地局１８０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａとの間でワイヤレス信号を送受信することができる。基地局１８０ａ、１８０ｂ、１８０ｃはまた、ハンドオフのトリガ、トンネル確立、無線リソース管理、トラフィック分類、サービス品質（ＱｏＳ）ポリシ施行など、モビリティ管理機能を提供することもできる。ＡＳＮゲートウェイ１８２は、トラフィック集約ポイントとしての働きをすることができ、ページング、加入者プロファイルのキャッシング、コアネットワーク１０９へのルーティングなどを担うことができる。
【００４８】
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＲＡＮ１０５との間のエアインタフェース１１７は、ＩＥＥＥ８０２．１６仕様を実装するＲ１基準点として定義することができる。加えて、各ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、コアネットワーク１０９との論理インタフェース（図示せず）を確立することができる。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとコアネットワーク１０９との間の論理インタフェースは、Ｒ２基準点として定義することができ、Ｒ２基準点は、認証、許可、ＩＰホスト構成管理、および／またはモビリティ管理に使用することができる。
【００４９】
各基地局１８０ａ、１８０ｂ、１８０ｃ間の通信リンクは、Ｒ８基準点として定義することができ、Ｒ８基準点は、ＷＴＲＵハンドオーバおよび基地局間のデータ転送を容易にするためのプロトコルを含む。基地局１８０ａ、１８０ｂ、１８０ｃとＡＳＮゲートウェイ１８２との間の通信リンクは、Ｒ６基準点として定義することができる。Ｒ６基準点は、各ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに関連するモビリティイベントに基づくモビリティ管理を容易にするためのプロトコルを含むことができる。
【００５０】
図１Ｅに示すように、ＲＡＮ１０５は、コアネットワーク１０９に接続されてよい。ＲＡＮ１０５とコアネットワーク１０９との間の通信リンクは、Ｒ３基準点として定義することができ、Ｒ３基準点は、例えばデータ転送およびモビリティ管理能力を容易にするためのプロトコルを含む。コアネットワーク１０９は、ＰＭＩＰ−ＬＭＡ（Ｐｒｏｘｙ  ｍｏｂｉｌｅ  ＩＰ  Ｌｏｃａｌ  Ｍｏｂｉｌｉｔｙ  Ａｎｃｈｏｒ）１８４、認証許可アカウンティング（ＡＡＡ）サーバ１８６と、ゲートウェイ１８８とを含んでよい。前述の各要素はコアネットワーク１０９の一部として描かれているが、これらの要素のいずれか１つがコアネットワークオペレータ以外のエンティティによって所有および／または運営されてもよいことは理解されるであろう。
【００５１】
ＰＭＩＰ−ＬＭＡは、ＩＰアドレス管理を担うことができ、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが種々のＡＳＮおよび／または種々のコアネットワーク間でローミングするのを可能にすることができる。ＰＭＩＰ−ＬＭＡ１８４は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる。ＡＡＡサーバ１８６は、ユーザ認証とユーザサービスのサポートとを担うことができる。ゲートウェイ１８８は、他のネットワークとのインターワーキングを容易にすることができる。例えば、ゲートウェイ１８８は、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にすることができる。加えて、ゲートウェイ１８８は、他のサービスプロバイダによって所有および／または運営される他の有線またはワイヤレスネットワークを含み得るネットワーク１１２へのアクセスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。
【００５２】
図１Ｅには示されていないが、ＲＡＮ１０５が他のＡＳＮに接続されてもよく、コアネットワーク１０９が他のコアネットワークに接続されてもよいことは、理解されるであろう。ＲＡＮ１０５と他のＡＳＮとの間の通信リンクは、Ｒ４基準点として定義することができ、Ｒ４基準点は、ＲＡＮ１０５と他のＡＳＮとの間におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティを調整するためのプロトコルを含むことができる。コアネットワーク１０９と他のコアネットワークとの間の通信リンクは、Ｒ５基準として定義することができ、Ｒ５基準は、ホームコアネットワークと訪問先コアネットワークとの間のインターワーキングを容易にするためのプロトコルを含むことができる。
【００５３】
モバイルノードを構成する（モバイルノードに関連する論理インタフェース（ＬＩＦ）を構成することを含み得る）ためのシステム、方法、および手段を開示する。モバイルノードが、構成メッセージを受信することができる。構成メッセージは、ＡＮＤＳＦ（ａｃｃｅｓｓ  ｎｅｔｗｏｒｋ  ｄｉｓｃｏｖｅｒｙ  ａｎｄ  ｓｅｌｅｃｔｉｏｎ  ｆｕｎｃｔｉｏｎ）から受信することができ、ＡＮＤＳＦは、ＯＭＡ  ＤＭ（ｏｐｅｎ  ｍｏｂｉｌｅ  ａｌｌｉａｎｃｅ  ｄｅｖｉｃｅ  ｍａｎａｇｅｍｅｎｔ）サーバの一部とすることができる。構成メッセージは、モバイルノード規則を含むことができる。例えば、構成メッセージは、どのようにモバイルデバイスが入来フローまたは送出フローを扱うことになるか（例えば、使用するインタフェース、処理方法など）を示すことができる。構成メッセージは、ＯＭＡ  ＤＭ（ｏｐｅｎ  ｍｏｂｉｌｅ  ａｌｌｉａｎｃｅ  ｄｅｖｉｃｅ  ｍａｎａｇｅｍｅｎｔ）メッセージとすることができる。構成メッセージは、モバイルノードからのフィードバックに基づくことができる。構成メッセージは、アクションおよびパラメータを含むことができる。
【００５４】
モバイルノードは、モバイルノード規則に従って構成を変更することができる。モバイルノード規則は、モバイルノードが、あるインタフェース上でアップリンクパケットを送信すべきであることを示すことができる。モバイルノードは、モバイルノード規則によって示されるインタフェースを介して、アップリンクパケットを送信することができる。例として、構成メッセージ受信前は、モバイルノードは、関連するダウンリンクパケットが受信された物理インタフェース上で、アップリンクパケットを送信するように構成されていた場合がある。受信された構成メッセージに応答して、モバイルノードは、関連するダウンリンクパケットが受信された物理インタフェースとは異なる物理インタフェース上で、アップリンクパケットを送信することができる。
【００５５】
モバイルノードの構成は、ローカルモビリティアンカ（ＬＭＡ）などのアンカノードによって実施することができる。ＯＭＡ  ＤＭサーバ機能をアンカにおいて実施することができる。構成メッセージ中のモバイルノード規則は、関係するアンカノード規則と一致してよく、または、関係するアンカノード規則とは異なってよい。
【００５６】
モバイルノード規則は、複数のモバイルノード規則のうちの１つとすることができる。複数のモバイルノード規則には、優先順位を付けることができる。例えば、優先順位付けは、データタイプ、時刻、コストのうちの１つまたは複数に基づくことができる。
【００５７】
インターネットプロトコル（ＩＰ）スタックは、ＩＰスイートのソフトウェア実装と呼ぶことができる。論理インタフェース（ＬＩＦ）は、オペレーティングシステム内部の構造を指すことができる。ＬＩＦ実装において、リンクレイヤは、物理インタフェースをＩＰスタックおよびネットワークノードから隠すことができる。モバイルネットワーク上における論理インタフェース実装の例を、図２の図面によって例示する。
【００５８】
ローカルモビリティアンカ（ＬＭＡ）などのアンカが、特定のフローをそのデフォルトパスから異なるパスへと移動させると決定したとき、ネットワークベースのＩＰフローモビリティが開始することができる。アンカは、特定のフローが開始したとき、どのアクセスゲートウェイ（ＡＧ）（例えばモバイルアクセスゲートウェイ（ＭＡＧ））を使用してこのフローを移行すべきかを決定することができる。例えば、この決定は、アプリケーションポリシプロファイルに基づくことができ、かつ／または、ネットワークベースもしくはモバイルベースのトリガの受信時のフローの生存期間中であってよい。論理インタフェースは、特定のプレフィックス／フローについて、ダウンリンク（ＤＬ）パケットが受信された物理インタフェース上でアップリンク（ＵＬ）パケットを送信するものと指定されていた。以下のうちの１つまたは複数が当てはまる場合がある。アンカにおいてなされたフローモビリティ決定は、モバイルノード（ＭＮ）において、同じフローに属するパケットが新しいインタフェースに到着するときに暗黙的な決定として理解することができる。モバイルノードは、ユーザ機器（ＵＥ）とすることができるが、これに限定されない。モバイルとアンカとの間、またはモバイルとアクセスゲートウェイとの間で、ＩＰフローモビリティを制御するための制御メッセージは交換されない。複数のＩＰｖ６プレフィックスが使用される場合は、新しいＰＭＩＰまたはＧＴＰメッセージを生み出す必要がある場合がある。これらのメッセージは、アクセスゲートウェイ中のフローモビリティ状態を生成、リフレッシュ、またはキャンセルするために、アンカによって送信することができる。
【００５９】
図３に、決定がローカルモビリティアンカ（ＬＭＡ）からである場合の、ネットワークによって制御されるＩＰフローモビリティシーケンスの例示的な流れ図を示す。図３で、ＣＮは対応ノード（ＣＮ、ｃｏｒｒｅｓｐｏｎｄｅｎｔ  ｎｏｄｅ）を表し、モバイルアクセスゲートウェイ（ＭＡＧ）はモバイルアクセスゲートウェイを表す。モバイルノードが、単一無線動作（一度に１つの無線送信）をサポートすることに限定されるとき、種々の媒体を介して種々のＭＡＧに帰属するのは逐次的（例えば、同時でないか、またはいくぶん同時）とすることができる。この場合、レイヤ２．５シグナリングを使用して、アクセス技術間ハンドオーバを実施し、所望のターゲットアクセス技術、ＭＮ−ＩＤ、フローＩＤ、およびプレフィックスをＬＭＡに通信することができる。
【００６０】
ネットワーク帰属時にポリシ構成を行うことができ、このポリシ構成は、レイヤ２シグナリングを使用して、または外部チャネルを介して動的に、ＭＮに転送することができる。例えば、Ｌ２シグナリングがこのような情報を搬送し、ＰＭＩＰｖ６シグナリングがＬＭＡとＭＡＧとの間でルーティングポリシを伝達することができるものとすることができる。バインド接続の生存期間中に、ポリシの更新を行うことができる。ポリシの更新の結果、進行中のフローを、あるアクセスネットワークから別のアクセスネットワークに移動する場合がある。
【００６１】
ＵＬフローの場合、ＭＮは、ユーザ選好、オペレータポリシ、アプリケーション要件などに基づいてローカルポリシを構成できるものとすることができる。ＭＮは、例えばネットワーク帰属の間に、または特定のレイヤ２のトリガ（例えばｌｉｎｋ  ｇｏｉｎｇ  ｄｏｗｎ）の受信時に、ポリシをＭＡＧに送信できるものとすることができる。この場合、ＭＮがフローモビリティプロシージャをトリガする、と言うことができる。ネットワークも、例えばネットワーク負荷条件に基づいて、フローモビリティプロシージャを等しく開始できるものとすることができる。
【００６２】
ＩＥＥＥ標準８０１．２１シグナリングを使用して、ＭＮからＭＡＧにフィルタを搬送することができる（ＭＩＨパケット用のＩＥＴＦ標準化されたＩＰトランスポート）。ＭＩＨサービスポイントは、ＭＡＧ機能と共に展開することができる。
【００６３】
例えばネットワーク帰属の間にまたはレイヤ２トリガ（例えばｌｉｎｋ  ｇｏｉｎｇ  ｄｏｗｎ）時にＭＮがサービングノードに規則を送ることによって、ＭＮとアンカとの間の動的な規則交換を実施することができる。指定されるようにＭＮおよびアンカ上で同じ規則を適用することによって、挙動を制限することができる。
【００６４】
ＯＭＡ  ＤＭ（ｏｐｅｎ  ｍｏｂｉｌｅ  ａｌｌｉａｎｃｅ  ｄｅｖｉｃｅ  ｍａｎａｇｅｍｅｎｔ）仕様は、携帯電話機、ＰＤＡ、およびパームトップコンピュータなどの小型モバイルデバイスの管理に関係する場合がある。通信プロトコルは、要求−応答プロトコルとすることができる。通信は、ＯＭＡ  ＤＭサーバによって開始することができ、この通信は、ＷＡＰ  ＰｕｓｈやＳＭＳなど、利用可能な方法のいずれかを使用して非同期で行うことができる。サーバからクライアントへの最初のメッセージは、通知またはアラートメッセージの形とすることができる。サーバとクライアントとの間で通信が確立された後は、メッセージのシーケンスを交換して所与のデバイス管理タスクを完了することができる。
【００６５】
ＯＭＡ  ＤＭは、アラートを可能にすることができる。アラートは、シーケンス外で発生するメッセージとすることができ、サーバおよび／またはクライアントによって開始することができる。このようなアラートを使用して、エラーや異常終了などを処理することができる。図４に、デバイス管理プロトコルの段階の例示的な流れ図を示す。通知メッセージ、アラートを使用して、サーバが管理セッションの実施をクライアントにアラートできる可能性をもたらすことができる。クライアントが、セッションを開始することができる。サーバが通知を送って、セッションを開始するようクライアントに知らせることができる。クライアントは、クライアント自体で、セッションの開始を決定することができる。通知メッセージは、トリガヘッダおよびトリガ本体を含むことができる。トリガヘッダは、ユーザ対話モード（ｕｉモード）を指定することができ、以下の値のうちの１つまたは複数を含むことができる。すなわち、（１）未指定、（２）バックグラウンド管理アクション、（３）情報管理アクション、および（４）管理アクション前のユーザ対話などである。トリガ本体は、ベンダ特有（ＴＬＶまたは他のタイプの表現）とすることができる。
【００６６】
ＡＮＤＳＦ（ａｃｃｅｓｓ  ｎｅｔｗｏｒｋ  ｄｉｓｃｏｖｅｒｙ  ａｎｄ  ｓｅｌｅｃｔｉｏｎ  ｆｕｎｃｔｉｏｎ）およびＵＥによって使用できる管理オブジェクトを、本明細書に開示することができる。管理オブジェクト（ＭＯ）は、ＡＮＤＳＦによって管理できるシステム間モビリティポリシおよびアクセスネットワーク発見情報についての関連パラメータを含むことができる。以下に、ＩＰフローモビリティおよびルーティング規則に関係する可能な構成の例示的な概要を示す。
【００６７】
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
ＶａｌｉｄｉｔｙＡｒｅａノードは、特定のシステム間ルーティングポリシ規則についての位置条件のためのプレースホルダとしての役割を果たすことができる。
5.102Z<X>/ISRP/<X>/ForFlowBased/<X>/RoutingCriteria/<X>/TimeOfDay     49
ＴｉｍｅＯｆＤａｙノードは、特定のシステム間ルーティングポリシ規則についての日条件のためのプレースホルダとしての役割を果たすことができる。
5.102AA<X>/ISRP/<X>/ForFlowBased/<X>/RoutingCriteria/<X>/ APN 49
ＡＰＮリーフは、特定のシステム間ルーティングポリシ規則が有効であるＡＰＮを示すことができる。
5.102AB    <X>/ISRP/<X>/ForFlowBased/<X>/RoutingRule  49
ＲｏｕｔｉｎｇＲｕｌｅノードは、システム間ルーティングポリシ規則についての好まれるアクセスを示すことができる。このノードおよびその子孫は、以下において定義することができる。
<X>/Policy/<X>/PrioritizedAccess.
5.7   <X>/Policy/<X>/PrioritizedAccess  14
ＰｒｉｏｒｉｔｉｚｅｄＡｃｃｅｓｓノードは、特定の規則についての好まれるアクセスを示すことができる。
5.8   <X>/Policy/<X>/PrioritizedAccess/<X>    14
この内部ノードは、１つまたは複数の優先されるアクセスのためのプレースホルダとしての役割を果たすことができる。
5.9   <X>/Policy/<X>/PrioritizedAccess/<X>/ AccessTechnology    14
ＡｃｃｅｓｓＴｅｃｈｎｏｌｏｇｙリーフは、優先されるアクセス技術を示すことができる。
5.10  <X>/Policy/<X>/PrioritizedAccess/<X>/ AccessId 15
ＡｃｃｅｓｓＩｄリーフは、アクセスネットワーク識別子を表すことができる。
5.10A <X>/Policy/<X>/PrioritizedAccess/<X>/ SecondaryAccessId    15
ＳｅｃｏｎｄａｒｙＡｃｃｅｓｓＩｄリーフは、２次アクセスネットワーク識別子を表すことができる。
5.11  <X>/Policy/<X>/PrioritizedAccess/<X>/ AccessNetworkPriority 15
ＡｃｃｅｓｓＮｅｔｗｏｒｋＰｒｉｏｒｉｔｙリーフは、アクセス技術の優先順位を表すことができる。
【００６８】
インターネット制御メッセージプロトコル（ＩＣＭＰ）は、インターネットプロトコルスイートの一部である。ＩＣＭＰメッセージは、ＩＰデータグラム中のエラーに応答して、または診断もしくはルーティングの目的で、生成される場合がある。一例では、インタフェースが使用可能になると、ホストは、ルータ要請を送出することができ、このルータ要請は、次のスケジュール済み時間にではなくすぐにルータ広告を生成するよう、ルータに要求する。ルータは、定期的に、またはルータ要請メッセージに応答して、ルータの存在を様々なリンクおよびインターネットパラメータと共に広告することができる。ルータ広告は、オンリンク決定および／またはアドレス構成に使用されるプレフィックス、提案されるホップ制限値などを含むことができる。エコー要求／エコー返答メッセージを使用して、ピアにピングすることができる。
【００６９】
ＤＨＣＰ動作は、以下の段階のうちの１つまたは複数を含むことができる。すなわち、ＩＰ発見、ＩＰリースオファー、ＩＰ要求、およびＩＰリース肯定応答である。クライアントは、物理サブネット上でメッセージをブロードキャストして、利用可能なＤＨＣＰサーバを発見することができる。ＤＨＣＰＤＩＳＣＯＶＥＲメッセージを使用することができる。ＤＨＣＰサーバがＩＰリース要求をクライアントから受信すると、ＤＨＣＰサーバは、このクライアント用にＩＰアドレスを予約し、ＤＨＣＰＯＦＦＥＲメッセージをクライアントに送信することによってＩＰリースオファーを拡張することができる。クライアントは、複数のサーバからＤＨＣＰオファーを受信する場合があるが、受諾を１つのＤＨＣＰオファーに制限してＤＨＣＰ要求メッセージをブロードキャストすることができる。ＤＨＣＰサーバがＤＨＣＰＲＥＱＵＥＳＴメッセージをクライアントから受信すると、構成プロセスは最終段階に入ることができる。肯定応答段階は、ＤＨＣＰＡＣＫパケットをクライアントに送信することを含むことができる。
【００７０】
ＤＨＣＰクライアントは、ＤＨＣＰ情報メッセージを使用して、サーバが元のＤＨＣＰＯＦＦＥＲによって送った情報よりも多くの情報を要求することができる。クライアントは、特定のアプリケーションについてリピートデータを要求することができる。クライアントは、ＤＨＣＰ解放メッセージを使用して、ＤＨＣＰ情報を解放するよう求める要求をＤＨＣＰサーバに送信することができ、クライアントは、そのＩＰアドレスを非アクティブ化することができる。
【００７１】
ＤＨＣＰサーバは、オプションの構成パラメータをクライアントに提供することができる。ＤＨＣＰクライアントは、ＤＨＣＰサーバによって提供されたパラメータを選択、操作、および上書きすることができる。構成パラメータおよび他の制御情報は、ＤＨＣＰメッセージの「オプション」フィールドに記憶されたタグ付きデータアイテム中で搬送することができる。これらのデータアイテム自体を、「オプション」と呼ぶことができる。
【００７２】
ＬＩＦ要件は、ＭＮが、ＤＬパケットが受信されたのと同じインタフェース上でＵＬパケットを送信することを言明する場合がある。この挙動を達成するために、ＭＮ上での入来パケットフィルタリングを実施して、入来フローと関連インタフェースとを含むマッピングテーブルを構築することができる。この入来フィルタリングは、ＣＰＵの負担が厳しい可能性があり、多くのＤＬパケットが受信され入来フィルタリングが受信プロセスを遅くしている状況では、パケットドロップにつながる可能性がある。
【００７３】
上記のＬＩＦ挙動では、ＵＥ上でのＬＩＦ実装は、フローごとのネットワークインタフェース選択をミラーリングしている。しかし、状況によっては、ＵＥが異なる挙動をする（例えばＤＬパケットとは異なるインタフェース上でＵＬパケットを送信する）のが有利な場合がある。リアルタイムの状況（例えばネットワーク条件）に基づいてフローを移動する必要がある場合があるので、機能（例えばＩＰフローモビリティ）をサポートするために動的構成能力が必要とされることがある。
【００７４】
種々のタイプのデータを転送するために複数のソケットを開いているアプリケーションは、複数のＩＰフローを有することがある。ネットワーク中でＬＩＦおよびアンカノードを使用して、これらのＩＰフローを、ＬＩＦに関連する物理インタフェース間で移動することができる。単一のアプリケーションに関係するＩＰフローは、別個に扱うことができる。例えば、これらのＩＰフローは、独立して、またはいくぶん独立して移動することができる。例えば、３つのＩＰフローを有するアプリケーションが、３つのフローを単一のインタフェース（例えばＩＦ＃１）上で送信させ、何らかの時点で、結局は３つの異なるインタフェース（例えばＩＦ＃１、ＩＦ＃２、およびＩＦ＃３）上の１つのフローで終わる場合がある。このような変化は、種々の理由で、例えばネットワーク輻輳、ネットワーク決定、構成された規則、選好などによって生じることがある。この場合にアプリケーションによって受信されるデータは、非同期である可能性がある。フローが独立しているとしても、これらのフローの内容を同期方式で表示および／または再生することが必要な場合がある。
【００７５】
所定の挙動に基づく代わりに、例えば構成された規則に基づいて、論理インタフェースの向上をもたらすことができる。構成された規則をこのように使用することにより、入来パケットフィルタリングを回避するのを可能にすることができる。規則は、ＭＮ上および／またはネットワーク上で、動的に構成することができる。開示するシステム、方法、および手段は、ＯＭＡ  ＤＭ、８０２．２１、ＤＨＣＰ、ＩＣＭＰなどに関係してよい。ネットワーク／アンカ（例えばダウンリンク）上の構成された規則は、ＭＮ（例えばアップリンク）上の規則とは異なってよい。複数の規則を同時に適用することができる（例えば組合せ）。規則の構成は、動的であってよく、例えば、ネットワーク条件や時刻など種々の状況に適合させることができる。アプリケーションおよび／またはセッションモビリティを提供することができる。開示するシステム、方法、および手段は、ネットワークベースのモビリティ領域（例えばＰＭＩＰまたはＧＴＰ）中のＬＩＦ挙動に関係してよく、関係するネットワークノードは、ＰＭＩＰｖ６またはＧＴＰ領域の一部とすることができる。
【００７６】
送出パケットに適用されることになる規則がＭＮにわかっているようにすることにより、ＭＮ上でのパケットフィルタリングを回避することができる。例えば、アンカによって適用される規則がＭＮにわかっている場合、ＭＮは、ＭＮが使用することになる規則がわかっていることになるので、入来パケットのフィルタリングの実施（例えばＵＬでどのインタフェースを使用するかを決定するために）の必要はなくてよい。ＭＮが入来パケットを調べてから送出パケットで挙動をミラーリングすることを必要とする代わりに、適用されることになる規則をＭＮ上で構成することができる。加えて、ＬＩＦ挙動はフレキシブルとすることができる（パケットを、フローが受信されたインタフェース上で送信することが必要とされるのとは対照的に）。
【００７７】
以下に、動的な規則構成の例を提供することができる。構成は、規則（例えば本明細書で述べる規則のタイプなど）に従って変更することができる。アンカが、ダウンリンク上で、２つのフロー（例えばフロー＃１およびフロー＃２）をあるインタフェース（例えばインタフェース＃１（ＩＦ＃１））上でＭＮに送信している場合がある。ＭＮは、あるフローに関係するＵＬパケットを、このフローのダウンリンクパケットを受信したインタフェース上で送信するように構成されている（例えば規則によって）場合がある。すなわち、ＭＮは、規則に従って、かつフロー＃１およびフロー＃２からの入来パケットに対するパケットフィルタリングを実施せずに、フロー＃１およびフロー＃２のＵＬパケットをＩＦ＃１上で送信することができる。アンカは、ＭＮの構成を変更することができる。例えば、アンカは、フロー＃１に関連するアップリンクパケットはＩＦ＃１上で送信し、フロー＃２に関連するアップリンクパケットはＩＦ＃２上で送信するようにＭＮを構成する新しい規則を、ＭＮに送ることができる。ＭＮに送られた規則は、アンカが従っている規則とすることができる。このような場合、かつ上の例を続けると、アンカは、フロー＃１をＩＦ＃１上でＭＮに送信し、フロー＃２をＩＦ＃２上でＭＮに送信することができる。ＭＮに送られた規則は、アンカが従っている規則とは異なる規則とすることもできる。このような場合、かつ上の例を続けると、アンカは、フロー＃１およびフロー＃２をＩＦ＃１上でＭＮに送信することができる。ＭＮは、アンカ規則とは異なるＭＮ規則に従って、フロー＃１パケットをＩＦ＃１上で送信し、フロー＃２パケットをＩＦ＃２上で送信することができる。すなわち、ＭＮは、入来パケットに対するパケットフィルタリングを実施せずに、その構成に従って（例えばその構成規則に従って）ＵＬパケットを送信することができる。
【００７８】
規則構成は、アンカによってＭＮに対して実施することができる。ＭＮがアンカ上の規則を動的に構成する場合、ＭＮは、フロートランスポート（例えば、ＭＮによって制御されるＩＰフローモビリティ、ＭＮによって制御されるインタフェースハンドオーバなど）を制御することができる。
【００７９】
規則の動的構成により、種々の状況（例えばネットワーク条件や時刻など）への適合を実現することができる。プッシュする（例えば通知を送る）ことができる可能性をもたらすプロトコルを、ＭＮまたはアンカによって使用することができる。情報の交換中に、ネットワーク中の制御エンティティが関与することができる。このような交換のために、サービングノード（例えばＭＡＧ）を使用することができる。例として、規則は、ＯＭＡ  ＤＭ、ＤＨＣＰ、ＩＣＭＰ、８０２．２１、ＩＫＥｖ２、ＩＰＣＰなどにおいて提供される方法を介して、送信することができる。
【００８０】
例えばＭＮからネットワークへ、またはネットワークからＭＮへ、規則を動的に構成するように、ＯＭＡ  ＤＭを修正することができる。ＯＭＡ  ＤＭサーバ機能は、アンカ、サービングノード、外部ＯＭＡ  ＤＭサーバ（例えばＡＮＤＳＦ）などにおいて実施することができる。
【００８１】
ＡＮＤＳＦは、ＭＮ、および／または、アンカ／サービングノードに、規則をプッシュすることができる。アンカは、例えばネットワーク特有プロトコル（例えばＰＭＩＰｖ６、ＧＴＰなど）またはＯＭＡ  ＤＭを使用して、サービングノードに（またはその逆に）規則をプッシュすることができ、サービングノードは、ＯＭＡ  ＤＭを使用してこれらの規則をＭＮに転送することができる。ＯＭＡ  ＤＭは、ＭＮおよびネットワーク上で最初に規則を構成する間に使用することができ、かつ／または、規則の動的構成に使用することができる。
【００８２】
通知（プッシュ）に関係して、トリガヘッダ／ユーザ対話モード（ｕｉモード）中で構成されることになる新しいモードを提供することができる。構成が読み取られる準備ができていることを言明するための、新しい値を提供することができる（例えば、ｒｅａｄ  ｉｍｍｅｄｉａｔｅｌｙ−ｉｍｍｅｄｉａｔｅ  ｍａｎａｇｅｍｅｎｔ  ａｃｔｉｏｎ）。読取準備完了の場合、情報を取り出す準備ができているものとすることができ、管理セッションを確立する必要があるものとすることができる。トリガ本体／ベンダ特有フィールドに情報が含まれていることを言明するための、新しい値を提供することができる。この情報はメッセージ自体の内で搬送されるので、このメッセージが受け取られたとき、管理アクションは必要とされなくてよく、かつ／または管理セッションを確立する必要はなくてよい。
【００８３】
トリガ本体／ベンダ特有フィールド中で搬送されることになる規則のフォーマットを提供することができる。例として、規則は、ＡＣＴＩＯＮ＋ＲＵＬＥ＋ＰＡＲＡＭＳのフォーマットに従うことができる。ＡＣＴＩＯＮは、追加、修正、または削除を指定することができる。規則は、ＴＬＶまたは他のタイプの表現を使用できることを指定することができる。例えば、関連する規則と共に、アクションを送ることができる（追加、修正、削除）。規則には番号を付けることができ、動的な構成の間の交換は、番号（複数可）に制限することができる。
【００８４】
以下は、構成できる規則の例である。すなわち、１＝受信したのと同じインタフェース上でＩＰフローを送信する、２＝あるＩＰフローをＩＦ＃Ｘ上で送信する、３＝ＴＣＰ  ＡＣＫをＩＦ＃Ｘ上で送る、４＝制御メッセージをＩＦ＃Ｘ上で送信する、５＝ＩＰフローを最も速いインタフェース上で送信する、６＝ＩＰフローを最も安価なインタフェース上で送信する、７＝ウィンドウイング方法を使用する、８＝ヒステリシスウィンドウを使用する、などである。規則には名前を付けることができる（例えば番号の代わりに文字列）。
【００８５】
以下は、ＰＡＲＡＭＳの例である。ＰＡＲＡＭは、５タプル（例えば、ＩＰソースアドレス、ＩＰ宛先アドレス、ＩＰソースポート、ＩＰ宛先ポート、プロトコルタイプ）とすることができる。ＰＡＲＡＭは、例えばＩＰｖ６が使用される場合には、６タプルとすることができる（例えば、５タプル＋ＩＰフローレベル）。ＰＡＲＡＭは、構成された規則に依存し得る値とすることができ、例えば、構成された規則＝ウィンドウイング方法またはヒステリシスウィンドウである場合は、ウィンドウサイズ値とすることができる。ＰＡＲＡＭは、例えば規則が上に指定された２、３、または４である場合には、インタフェース識別子とすることができる。ＰＡＲＡＭは、パケットフィルタリングのためにチェックすることのできる別のフィールドとすることができる。これはＴＣＰ／ＩＰヘッダに限定されなくてよい。
【００８６】
１つまたは複数のコード化修正が必要とされる場合がある。既存のカテゴリは、以下を含むことができる。
<X>/ISRP/<X>/ForFlowBased/<X>/RoutingRule/<X>/
【００８７】
フィールドを追加することができ、フィールドは以下のうちの１つまたは複数を含むことができる。
<X>/ISRP/<X>/ForFlowBased/<X>/RoutingRule/<X>/ConfiguredRule
Ｖａｌｕｅｓ：＜本明細書に開示されるような「ＲＵＬＥ」について定義された値、例えば１〜８とすることができる＞
<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.
【００８８】
追加されたフィールドのアクセスタイプ（例えば「ＡＣＴＩＯＮ」について指定されるような）は、追加、削除、および置換を含むことができるが、これらに限定されない。ＩＰフローを識別するタプルは、<X>/ISRP/<X>/ForFlowBased/<X>/IPFlow/<X>/中で定義することができ、ルーティング規則中に追加する必要はなくてよい。
【００８９】
ＩＣＭＰを使用して、ＭＮとアンカとの間でＬＩＦ規則を交換することができる。この目的で、ＩＣＭＰメッセージを定義することができる。ＲＳ／ＲＡ／Ｅｃｈｏメッセージが、規則を搬送することができる。規則は、標準に従って「オプション」に追加することができる。実施形態は、ＩＣＭＰの現バージョンに対して後方互換性を有することができ、例えば、導入されたオプションがサポートされていなければそのオプションをスキップすることができる。
【００９０】
「規則」と呼ばれるオプションを提供することができる。このオプションを使用して、ＭＮ上とネットワークノード上のいずれかでＬＩＦ規則を構成することができる。規則オプションの例示的なフォーマット、例えばＡＣＴＩＯＮ＋ＲＵＬＥ＋ＰＡＲＡＭＳについて本明細書に述べる。図５に、例示的なコード化フォーマットを示す。図５に示すようなコード化の例は、以下のフィールドのうちの１つまたは複数を含むことができる。すなわち、Ｔｙｐｅ−別のオプションにまだ使用されていない番号（例えば６）と、Ｌｅｎｇｔｈ−ｐａｒａｍｓ長さに依存する変数と、Ａｃｔｉｏｎ−１〜３（例えば本明細書に開示されるような）と、Ｒｕｌｅ１〜８（例えば本明細書に開示されるような）と、Ｐａｒａｍｓ−規則（本明細書に開示されるような）に依存し得る変数とである。規則オプションは、複数のアクション、規則、および／またはパラメータを含む場合がある。このオプションは、例えばフィルタメッセージ、ＲＳ／ＲＡメッセージ、エコーメッセージなどによって使用することができる。
【００９１】
以下は、ＩＣＭＰメッセージの例である。フィルタメッセージをＭＮからアンカに、またはアンカからＭＮに送信して、規則を追加、修正、または削除することができる。フィルタメッセージは、本明細書に開示されるような「規則」と呼ばれるオプションを含むことができる。フィルタメッセージへの応答として、フィルタ返答メッセージを送信することができる。フィルタ返答メッセージは、要求メッセージから受諾されたフィルタを含むことができる。
【００９２】
更新されるルータ要請および／またはルータ広告メッセージ（ＲＳ／ＲＡ）を開示することができる。オプションをＲＳ／ＲＡに追加して、ローカルに（例えばＭＮ上とアンカ上のいずれかで）適用されることになるＬＩＦ規則を伝達することができる。ＭＮがＩＰアドレスを有さない場合、ＲＳをルータに送信することができる。オプションは、ＭＮのＬＩＦ規則を含むことができる。ＭＮによって受け取られたＲＡメッセージは、オプション（複数可）中のＬＩＦ規則を含むことができる。これらの規則は、ネットワークによって構成された規則、または、ＲＳ上でＭＮによって指定され受諾された規則とすることができる。ＭＮのＩＰアドレスが取得済みの場合、ＲＳメッセージを使用してＬＩＦ規則を修正することができる（ＭＮによる制御）。このような場合、ＲＳメッセージを、アンカ（またはローカルＩＰアドレスの取得元であるネットワークノード）に、例えば宛先ＩＰアドレス＝アンカＩＰアドレスに送信することができる。関連するＲＡは、ＲＳからＭＮに、例えば宛先ＩＰアドレス＝ＭＮのＩＰアドレスに送信することができる。
【００９３】
エコー要求および／またはエコー返答メッセージを使用することができる。これらのメッセージを修正して、データフィールドに加えてオプションを搬送することができる。オプションフィールドは、本明細書に開示されるように定義することができる。
【００９４】
「フローフィルタ」と呼ばれるオプションを提供することができる。フローフィルタは、ＩＰフローモビリティを得るために適用されるフィルタを指定することができる。本明細書に開示されるような規則フォーマット、例えばＡＣＴＩＯＮ＋ＲＵＬＥ＋ＰＡＲＡＭＳを使用することができる。これは、送出パケットがどのインタフェース上で送信されるべきかを決定するのに使用できる、規則および／または関連パラメータのリストを含むことができる。パケットフィルタリングに使用されるフィールドを、ＰＡＲＡＭＳフィールド中で指定することができる（例えば、５タプルおよび所望の送出インタフェース）。
【００９５】
図６に、例示的なコード化フォーマットを示す。これは、どのように規則フォーマットを定義できるかの例である。他のフォーマットを選択して同様の挙動を達成することもできる（例えばアクションのリスト。これは、規則のリストに加えてコード化することができる）。図６に示すように、規則フォーマットは、規則フォーマット＝ＣＯＤＥ＿ＦＬＯＷ＿ＦＩＬＴＥＲ  ＬＥＮ  ＡＣＴＩＯＮ  ＲＵＬＥ  ＰＡＲＡＭＳとすることができる。
【００９６】
図６の例では、
ＣＯＤＥ＿ＦＬＯＷ＿ＦＩＬＴＥＲ＝１００
Ｌｅｎ＝ｎ（ｎは長さを表すことができる）
Ａｃｔｉｏｎは、値、例えば番号とすることができ、番号はアクションを表すことができる。例えば、１〜３の範囲を提供することができ、追加＝１、修正＝２、および削除＝３である。  
Ｒｕｌｅは、値、例えば番号とすることができ、番号はある規則を表すことができ、この規則は、表１に示すように、パラメータおよび／または長さに関連するものとすることができる。
【００９７】
【表１】
2014509495.tif 000003
【００９８】
図７に、２つの規則を追加する例示的な規則フォーマットを示す。図７において、上の例を続けると、アクションは、追加アクションを示す１としてリストされている。２つの規則インジケータがある。第１の規則インジケータは１としてリストされており、これは、ＩＰフローが、それが受信されたインタフェース上で送信されることを示す。第２の規則インジケータは７としてリストされており、これはウィンドウイング方法の使用を示す。第２の規則の後には、３としてリストされた値指示が続き、これは、ウィンドウサイズが３であることを示す。規則フォーマットは、図７の例で示すように様々な方法で変更することができる。
【００９９】
ＤＨＣＰＤＩＳＣＯＶＥＲ、ＤＨＣＰＯＦＦＥＲ、ＤＨＣＰＲＥＱＵＥＳＴ、ＤＨＣＰＡＣＫ、ＤＨＣＰＩＮＦＯＲＭなどのメッセージを使用して、ＩＰｖ４環境で規則をトランスポートすることができる。以下の例は、説明的なものである。ＤＨＣＰＤＩＳＣＯＶＥＲメッセージは、本明細書に開示されるようなオプションを使用して規則を指定することができる（例えばＭＮによる制御）。ＤＨＣＰＯＦＦＥＲメッセージは、本明細書に開示されるようなオプションを使用して、規則をトランスポートすることができる（例えば、受諾されたＭＮ規則（拒否された規則は含まれない）と、アンカ規則とのいずれか）。ＤＨＣＰＲＥＱＵＥＳＴメッセージは、本明細書に開示されるようなオプションを使用して、規則をトランスポートすることができる（例えば、修正された規則（ＭＮによる制御）と、ＤＨＣＰＯＦＦＥＲ上でアンカから受信された受諾済み規則とのいずれか）。これらは、ＭＮが規則を修正する必要があるときに送信することができる。例えば、ＤＨＣＰリニューアルトリガを待機する必要はなくてよい。ＤＨＣＰＡＣＫメッセージは、ＤＨＣＰＲＥＱＵＥＳＴまたはＤＨＣＰＩＮＦＯＲＭを使用してトランスポートされてアンカによって受諾された規則を含むことができる。これは、アンカ規則を含むことができる。拒否された規則は含まれないものとすることができる。ＤＨＣＰサーバは、ＤＨＣＰＡＣＫメッセージを使用して、新しい／修正された規則を構成することができる。この場合、ＭＮは、受諾された規則を含むＤＨＣＰＲＥＱＵＥＳＴまたはＤＨＣＰＩＮＦＯＲＭを送り返すことができる。拒否された規則は含まれないものとすることができる。ＤＨＣＰＩＮＦＯＲＭメッセージは、本明細書に開示されるようなオプションを使用して規則を指定することができる（例えばＭＮによる制御）。
【０１００】
ＩＰｖ６環境におけるＤＨＣＰの使用は、種々のメッセージを利用することができる。以下は、本明細書に開示されるようなオプションを搬送することのできる例示的なメッセージである。ＤＨＣＰＳＯＬＩＣＩＴメッセージは、オプションを使用して規則を指定することができる（例えばＭＮによる制御）。ＤＨＣＰＡＤＶＥＲＴＩＳＥメッセージは、オプションを使用して規則をトランスポートすることができる（例えば、受諾されたＭＮ規則（拒否された規則は含まれないものとすることができる）と、アンカ規則とのいずれか）。ＤＨＣＰＲＥＱＵＥＳＴ／ＤＨＣＰＲＥＮＥＷ／ＤＨＣＰＲＥＢＩＮＤメッセージは、本明細書に開示されるようなオプションを使用して、規則をトランスポートすることができる（例えば、修正された規則（ＭＮによる制御）と、受諾された規則（ＤＨＣＰＡＤＶＥＲＴＩＳＥまたはＤＨＣＰＲＥＱＵＥＳＴ上でアンカから受信された）とのいずれか）。このメッセージは、ＭＮが規則を修正しなければならないときに送信することができる。ＤＨＣＰＲＥＰＬＹメッセージは、アンカによって受諾された、ＭＮによって構成された規則を含むことができ、拒否された規則を含まないものとすることができる。このメッセージは、アンカ規則を含むことができる。ＤＨＣＰサーバは、ＤＨＣＰＲＥＣＯＮＦＯＧＵＲＥメッセージを使用して、新しい／修正された規則を構成することができる。この場合、ＭＮは、現在使用されている規則を含むＤＨＣＰＲＥＮＥＷまたはＤＨＣＰＩＮＦＯＲＭＡＴＩＯＮ−ＲＥＱを送り返すことができる。次いでＤＨＣＰサーバは、ＤＨＣＰＲＥＰＬＹメッセージを使用して、構成されることになる規則を送り返すことができる。ＤＨＣＰＩＮＦＯＲＭＡＴＩＯＮ−ＲＥＱメッセージは、本明細書に開示されるようなオプションを使用して、規則を指定することができる（例えばＭＮによる制御）。
【０１０１】
ＤＨＣＰサーバは、サービングノードと同じ場所に位置することができる。規則は、サービングノードとアンカノードとの間で送信することができる（例えばＰＭＩＰｖ６またはＧＴＰを使用して）。ＭＮは、ＤＨＣＰクライアントとしての役割を果たすことができる。ＤＨＣＰサーバは、アンカノードと同じ場所に位置することができ、規則は、アンカからサービングノードに転送することができる（例えばＰＭＩＰｖ６またはＧＴＰを使用して）。ＭＮは、ＤＨＣＰクライアントとしての役割を果たすことができる。ＤＨＣＰサーバは、外部ノード中で実現することができ、ＭＮおよびアンカは、ＤＨＣＰクライアントとしての役割を果たして、規則を取得および／または構成することができる。サービングノードは、ＤＨＣＰを使用して、ＤＨＣＰサーバと直接に対話することができ、またはアンカと対話することができる（例えばＰＭＩＰｖ６もしくはＧＴＰを使用して）。
【０１０２】
ＩＥＥＥ標準８０２．２１を使用して、ＭＮとネットワークとの間で規則をトランスポートすることができる。これは、いくつかの方法で、例えばコマンドサービス（ＣＳ）、イベントサービス（ＥＳ）、情報サービス（ＩＳ）などを使用して実施することができる。ＣＳ、ＥＳ、および／またはＩＳを扱うＭＩＨサーバは、ネットワーク上の別個のノード（例えばＡＮＤＳＦ）中に位置することができ、または、アンカ（例えばＬＭＡ）もしくはサービングノード（例えばＭＡＧ）と同じ場所に位置することができる。ＩＥＥＥ標準８０２．２１を使用して、例えばＭＮからネットワークへ、および／またはネットワークからＭＮへ、規則を動的に構成することができる。一例では、ＩＥＥ８０２．２１シグナリングを使用して、ＭＮからＭＡＧにフィルタを搬送することができる。
【０１０３】
本明細書に開示するメッセージの組合せを利用することができる。例えば、ＣＳ、ＥＳ、ＩＳなどの組合せを使用することができる。コマンドサービスに関しては、メッセージＭＩＨ＿Ｌｉｎｋ＿Ｃｏｎｆｉｇｕｒｅ＿Ｔｈｒｅｓｈｏｌｄ要求／応答を使用して、規則を構成することができる。パラメータにおけるいくつかの修正が必要とされる場合がある。例えば、追加のパラメータタイプ、例えばＬＩＮＫ＿ＰＡＲＡＭ＿ＬＩＦ＿ＲＵＬＥを受諾するように、ＬＩＮＫ＿ＰＡＲＡＭ＿ＴＹＰＥを修正することができる。「ａｌｌ」を有効値として受諾するように、ＬＩＮＫ＿ＴＹＰＥを修正することができる。追加のメッセージ、例えばＭＩＨ＿Ｓｅｔ＿Ｐａｒａｍｅｔｅｒｓ要求／応答を導入することができ、例えば、ＬＩＦ規則をサポートするようにＬＩＮＫ＿ＰＡＲＡＭ＿ＴＹＰＥを修正することができる。
【０１０４】
情報サービスに関しては、ＭＩＨ＿Ｐｕｓｈ＿Ｉｎｆｏｒｍａｔｉｏｎ指示メッセージを使用して、ＬＩＦ規則をトランスポートすることができる。このメッセージは、ＭＮまたはネットワークが、それぞれネットワークまたはＭＮ上で規則を動的にプッシュするのに使用することができる。ＭＩＨ＿Ｓｅｔ＿Ｉｎｆｏｒｍａｔｉｏｎ要求／応答メッセージを追加することができる。これらのメッセージは、ＧＥＴの代わりにＳＥＴを行えることを除いては、既存のＭＩＨ＿Ｇｅｔ＿Ｉｎｆｏｒｍａｔｉｏｎ要求／応答メッセージと同様とすることができる。
【０１０５】
これらのメッセージの組合せは、例えば、ネットワーク中の別個のノードを使用して８０２．２１  ＩＳが実施される場合に使用することができる。例としては以下を含めることができる。アンカがＭＮ上の規則を構成したい場合、ＭＩＨ＿Ｓｅｔ＿Ｉｎｆｏｒｍａｔｉｏｎ要求を使用して、８０２．２１  ＩＳノード上の情報を設定することができる。次いでこのノードは、ＭＩＨ＿Ｐｕｓｈ＿Ｉｎｆｏｒｍａｔｉｏｎ指示を使用して、ＭＮ上の規則を構成することができる。アンカノードが、ＭＩＨ＿ＰｕｓｈＩｎｆｏｒｍａｔｉｏｎ指示を使用して、独立ノード上のＬＩＦ規則を構成することができ、独立ノードは、ＭＩＨ＿Ｐｕｓｈ＿Ｉｎｆｏｒｍａｔｉｏｎ指示を使用して、新しい構成要素が利用可能であることをＭＮに知らせることができる。ＭＮは、ＬＩＦ規則を照会するための新しいパラメータにより、既存のＭＩＨ＿Ｇｅｔ＿Ｉｎｆｏｒｍａｔｉｏｎ要求を使用してネットワークノードに照会することができる。ＬＩＦ規則を搬送するように、ＭＩＨ＿Ｇｅｔ＿Ｉｎｆｏｒｍａｔｉｏｎ応答を修正することができる。
【０１０６】
イベントサービスに関しては、ＭＩＨ＿Ｌｉｎｋ＿Ｐａｒａｍｅｔｅｒ＿Ｒｅｐｏｒｔ指示を使用して、ＬＩＦ規則をトランスポートすることができる。新しいメッセージ、例えばＭＩＨ＿Ｎｅｗ＿Ｃｏｎｆｉｇ指示を導入することができる。
【０１０７】
ＭＮ上とアンカ上とで異なる規則を適用することによって、ＬＩＦ挙動を向上させることができる。例えば、アンカは、ダウンリンクパケットがＩＦ＃１上で送信される（例えば所与のフローについて）ことを言明する規則を有してよく、ＭＮは、アップリンクパケットがＩＦ＃２上で送信される（例えばこのフローについて）ことを言明する規則で構成されてよい。
【０１０８】
複数の規則（例えば多数）を組み合わせることができる。複数の規則には、優先順位を付けることができる。これらの規則は、優先順位付けに従って使用することができる。以下は、複数の規則を使用する例である。ダウンリンクパケットが受信されたインタフェース上でアップリンクパケットを送信する規則などの規則を、本明細書に述べるウィンドウイング機構と組み合わせることができる。ウィンドウサイズは、関連する規則と同時に構成することができる。
【０１０９】
複数の規則が、種々の情報タイプに関係する場合がある。最も信頼性の高いインタフェース（例えばＩＦ＃１）上で制御パケットが送信されるという規則などの規則を、最も速いインタフェース（例えばＩＦ＃２）上でデータが送信されるという規則と組み合わせることができる。これらの規則は、ＭＮ上および／またはアンカ上で適用することができる。
【０１１０】
規則は、送信のタイプに基づいて優先順位付けすることができる。ある規則は、再送（例えばＴＣＰレイヤによって実施される）が、最も信頼性の高いリンク上で送信され、通常のトラフィックが、最も速いかまたは最も安価なリンク上で送信されるように、優先順位付けを提供することができる。このような規則は、ＭＮおよび／またはアンカ上で構成することができる。
【０１１１】
規則は、時間（例えば時刻）および／コスト（例えば情報を送信するコスト）に基づいて優先順位付けすることができる。ある規則は、午前９時から午後５時までは、最も速いインタフェース（例えばＩＦ＃１）上でパケットが送信され、残りの時間帯は、最も安価なインタフェース（例えばＩＦ＃２）上でパケットが送信されるように、優先順位付けを提供することができる。これは例えば、仕事中は最も速いおよび／または制限のないリンクを使用し、仕事中以外は最も安価なリンクに切り替えるために行うことができる。
【０１１２】
ある規則は、ノードが、関連パケットを受信したインタフェース上でパケットを送信することを言明することができる（例えばミラーリング規則）。このような規則は、ＭＮおよび／またはアンカに適用することができる。以下は例である。アンカは、アップリンクパケットを受信したインタフェース上でダウンリンクパケットを送信するという規則で構成されてよい。この規則は、アンカ上での構成に限定することができる。このような規則は、シグナリングメッセージを必要とすることなく、ＭＮによって制御されるＩＦＯＭを可能にすることができ、例えば、ＭＮが、どこにパケットを送信するかを決定し、アンカはＭＮの決定に従う。
【０１１３】
論理インタフェース挙動を使用して、ＩＰフローモビリティを可能にすることができる。例えば、ＩＰフローを、あるインタフェースから別のインタフェースに独立して移動することができ、アプリケーションはこの移動に気付かない。論理インタフェースは、インタフェースが変更しつつあるより高いレイヤから隠れることができる。フロー同士を接着することができ、それにより、あるフローが移動されるとき、接着されたフローも同じようにして移動されてよい。接着されるフローは、例えば、アプリケーションに関連するフロー、または、アプリケーションに関連するフローのサブセットとすることができる（例えば、アプリケーションが３つのアクティブなフローを有し、これらのうちの２つは共に接着され、他の１つは独立している場合がある）。
【０１１４】
ネットワークは、いつフローが移動されることになるか、どのインタフェースにフローが移動されるべきか、他のどのフローが同時に移動されることになるか（例えば接着されたフロー）などを決定することができる。ＭＮ上で実装されるＬＩＦモジュールは、ネットワーク決定をミラーリングするために待機することができる。ＬＩＦモジュールは、フロー移動をアップリンクパケットに適用するまで一定時間待機して、接着されたフローが入来方向で移動される機会を与え、次いで、送出インタフェース変更を、影響を受けるフローに同時に適用することができる。ＬＩＦモジュールは、どのフロー同士が接着されているかを意識する必要はなくてよい。このような場合、このことを知っている必要性は、ネットワークに限定することができる。というのは、モバイル上のＬＩＦモジュールは、ネットワークによって開始された移動をミラーリングしていることができるからである。どのフロー同士が接着されているかをモバイル上のＬＩＦモジュールが知っている場合、ＬＩＦモジュールは、移動したフローについてのフロー移動をミラーリングし、接着されたフローに対して同じ移動を自律的に開始することができる。上記の手順は、モバイルとネットワークとの間で役割が反転された状態で適用することもできる。
【０１１５】
ネットワークおよびモバイルは、フロー移動を開始する能力を有することができる。競合解決を提供することができる。ネットワークは、フロー（例えばフロー＃１）を特定のインタフェースＸに移動することを必要とする場合があり、モバイルは、フロー＃１に接着されている別のフロー（例えばフロー＃２）を別のインタフェースＹに移動することを要求する（例えば、モバイルとネットワークとからの移動決定が許される場合）。この場合、モバイルまたはネットワークに優先権を与えることができ、例えば、ネットワークが移動の最終決定を有することができる。優先権は、ポリシに構成することができる。この例では、ネットワークが優先権を有することができる。前述の場合では、フロー＃１はインタフェースＸに移動されることになり、フロー＃２をインタフェースＹに移動することは拒否されることになる。というのは、この２つのフローは接着されており、この例ではネットワークがモバイルよりも優先されるからである。
【０１１６】
最初のフロー移動を受諾し、競合する後続のフロー移動を拒否する技法を実施することができる。ＩＰパケット中のタイムスタンプを使用して、どのフロー移動が最初のフロー移動かを決定することができる。
【０１１７】
接着されたフローの識別を提供することができる。ＩＰフローは、多くの方法で識別することができる。５タプルを使用することができる。すなわち、ＩＰソースアドレス、ＩＰ宛先アドレス、ソースポート、宛先ポート、およびプロトコルである。他のフィールドを使用することもでき、これら他のフィールドはポリシによって構成することができる。以下の考察では、５タプルを使用してＩＰフローが識別されるものとすることができる。
【０１１８】
フロー接着は、モバイル側で実施することができる。フローは、モバイル上でアプリケーションによってまたはフロー管理エンティティによって共に接着することができる。アプリケーションがフローを意識している場合、アプリケーションは、ソケットを開くときにフィールド（複数可）を指定して、アプリケーション自体（例えばａｐｐｌｉｃａｔｉｏｎＩＤ）と、ソケットまたはこの５タプルに関連する場合のあるフローグループ（ｆｌｏｗＧｒｏｕｐ）とを識別することができる。ＬＩＦモジュールは、この情報で構成されてよく、この情報をその既存のマッピングテーブルに統合することができる。例えば、表２は例示的なＬＩＦマッピングテーブルであり、表２では、最初の２つの識別されたフローを接着することができる（表２の行２および３）。
【０１１９】
【表２】
2014509495.tif 000004
【０１２０】
アプリケーションは、それらのフローを、ソケットＡＰＩとは別のインタフェースを使用して構成することができる。フロー管理エンティティが、アプリケーションのフローを動的に構成するためにアプリケーションによって呼び出すことができる関数、例えばＦｌｏｗＣｏｎｆｉｇ（ＡｐｐｌｉｃａｔｉｏｎＩＤ，ＦｌｏｗＧｒｏｕｐ）をエクスポートすることができる。ＬＩＦモジュールは、構成関数、例えばＬＩＦ＿ＦｌｏｗＣｏｎｆｉｇ（ＡｐｐｌｉｃａｔｉｏｎＩＤ，ＦｌｏｗＧｒｏｕｐ）をエクスポートすることができる。アプリケーションが、フローを意識しないレガシーアプリケーションである場合、フローは宛先ＩＰアドレスに基づいて接着することができ、宛先ＩＰアドレスは、コンテンツプロバイダを識別することができる。この場合、同じ宛先に行くフロー同士が接着されることになる。
【０１２１】
フロー接着は、ネットワーク側で実施することができる。ネットワーク側のフロー移動制御ノードは、ＩＰパケットを見ることによってアプリケーションに関する情報を得ることはない場合がある。このノードはソースＩＰアドレスを知るかもしれないが、これによってアプリケーションが識別されることはない場合がある。フローをアプリケーションに関連付けてからフロー同士を接着することができるためには、ネットワークノードは、ＩＰパケットを調べる前に情報を受け取る必要がある場合がある。アプリケーション／フローに関するこの追加情報は、モバイルから構成機構を介して受け取ることができる。
【０１２２】
ＡｐｐｌｉｃａｔｉｏｎＩＤおよびＦｌｏｗＧｒｏｕｐを指定するために、ヘッダをＩＰパケット中で提供することができる。ヘッダは、アプリケーションデータとトランスポートヘッダ（例えばＵＤＰ／ＴＣＰ）との間に追加することができる。ＡｐｐｌｉｃａｔｉｏｎＩＤおよびＦｌｏｗＧｒｏｕｐは、ここで指定することができる。ネットワークノードは、この情報を抽出して、内部フロー接着テーブルを構築することができる場合がある。このようなヘッダが使用されることになるかどうかは、ポリシが指定することができる。
【図１Ａ】
2014509495.tif 000005
【図１Ｂ】
2014509495.tif 000006
【図１Ｃ】
2014509495.tif 000007
【図１Ｄ】
2014509495.tif 000008
【図１Ｅ】
2014509495.tif 000009
【図２】
2014509495.tif 000010
【図３】
2014509495.tif 000011
【図４】
2014509495.tif 000012
【図５】
2014509495.tif 000013
【図６】
2014509495.tif 000014
【図７】
2014509495.tif 000015
【手続補正書】
【提出日】平成25年4月5日(2013.4.5)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
モバイルノードに関連する論理インタフェース（ＬＩＦ）を構成する方法であって、
アクセスネットワーク発見・選択の機能（ＡＮＤＳＦ）から構成メッセージを受信するステップであって、前記構成メッセージがモバイルノード規則を含み、前記構成メッセージがオープン・モバイル・アライアンスのデバイス管理（ＯＭＡ  ＤＭ）メッセージである、ステップと、
前記モバイルノード規則に従って前記モバイルノードの構成を変更するステップであって、前記モバイルノードが、データ・フローのアップリンクデータを指示された物理インタフェースと関連付けるようにする、ステップと、
前記指示された物理インタフェースにより前記データ・フローと関連付けられたアップリンクパケットを送信するステップと、
を含み、
前記指示された物理インタフェースは、前記モバイルノードが前記構成の変更の前に前記アップリンクデータを関連付けた前の物理インタフェースとは異なる、方法。
【請求項２】
前記指示された物理インタフェースは、前記モバイルノードが前記データ・フローと関連付けられたダウンリンクパケットを受信した物理インタフェースとは異なる、請求項１に記載の方法。
【請求項３】
前記構成メッセージは、前記モバイルノードからのフィードバックに基づく、請求項１に記載の方法。
【請求項４】
前記モバイルノード規則は、アンカノード規則とは異なる、請求項１に記載の方法。
【請求項５】
前記モバイルノード規則は、アンカノード規則と一致する、請求項１に記載の方法。
【請求項６】
前記モバイルノード規則は、複数のモバイルノード規則のうちの１つである、請求項１に記載の方法。
【請求項７】
前記複数のモバイルノード規則は、優先順位付けされ、前記優先順位付けは、データタイプ、時刻、コストのうちの１つまたは複数に基づく、請求項６に記載の方法。
【請求項８】
前記構成メッセージは、アクションおよびパラメータを含む、請求項１に記載の方法。
【請求項９】
前記アップリンクパケットに関連する接着フローを決定するステップと、
前記指示された物理インタフェースを介して前記接着フローを送信するステップと
をさらに含む、請求項１に記載の方法。
【請求項１０】
アクセスネットワーク発見・選択の機能（ＡＮＤＳＦ）から構成メッセージを受信するように構成された受信機であって、前記構成メッセージがモバイルノード規則を含み、前記構成メッセージがオープン・モバイル・アライアンスのデバイス管理（ＯＭＡ  ＤＭ）メッセージである、受信機と、
前記モバイルノード規則に従って前記モバイルノードの構成を変更するように構成されたプロセッサであって、前記モバイルノードが、データ・フローのアップリンクデータを指示された物理インタフェースと関連付けるようにする、プロセッサと、
前記指示された物理インタフェースにより前記データ・フローと関連付けられたアップリンクパケットを送信するように構成された送信機と
を備え、
前記指示された物理インタフェースは、前記モバイルノードが前記構成の変更の前に前記アップリンクデータを関連付けた前の物理インタフェースとは異なる、モバイルノード。
【請求項１１】
前記指示された物理インタフェースは、前記モバイルノードが前記データ・フローと関連付けられたダウンリンクパケットを受信した物理インタフェースとは異なる、請求項１０に記載のモバイルノード。
【請求項１２】
前記構成メッセージは、前記モバイルノードからのフィードバックに基づく、請求項１０に記載のモバイルノード。
【請求項１３】
前記モバイルノード規則は、アンカノード規則とは異なる、請求項１０に記載のモバイルノード。
【請求項１４】
前記モバイルノード規則は、アンカノード規則と一致する、請求項１０に記載のモバイルノード。
【請求項１５】
前記モバイルノード規則は、複数のモバイルノード規則のうちの１つである、請求項１０に記載のモバイルノード。
【請求項１６】
前記複数のモバイルノード規則は、優先順位付けされ、前記優先順位付けは、データタイプ、時刻、コストのうちの１つまたは複数に基づく、請求項１５に記載のモバイルノード。
【請求項１７】
前記構成メッセージは、アクションおよびパラメータを含む、請求項１０に記載のモバイルノード。
【請求項１８】
前記プロセッサは、前記アップリンクパケットに関連する接着フローを決定するようにさらに構成され、前記送信機は、前記指示された物理インタフェースを介して前記接着フローを送信するようにさらに構成される、請求項１０に記載のモバイルノード。
【国際調査報告】
2014509495.tif 000016
2014509495.tif 000017
2014509495.tif 000018