JP2017536765A - モバイル環境におけるフローベースのアドレス指定のためのシステム及び方法 - Google Patents

Abstract

パケットのＩＰｖ６アドレス部分にフローハンドル（ＦＨ）を埋め込むことによって、フローベースのパケット転送における経路選択をサポートするのに必要なオーバーヘッド量が低減されてよい。ＦＨは、ＦＨが、ＩＰｖ６パケット自体に更なるオーバーヘッドを少しも追加しないように、標準的なＩＰｖ６アドレス内のインタフェース識別子を置換してよい。経路又はネクストホップを選択するために、ＩＰｖ６アドレスに埋め込まれたＦＨによって特定される情報が使用されてよい。加えて、ＦＨは、パケットに関連付けられたサービス品質（ＱｏＳ）要件を識別してよく、ルート選択機能は、ＱｏＳ要件を満たすことが可能な経路、サービス機能チェーン（ＳＦＣ）ＩＤ、アクセスポイント（ＡＰ）ＩＤ、無線ベアラＩＤ、経路ＩＤ、及び／又はデバイスＩＤを識別してよい。

Description

本特許出願は、２０１４年１１月１８日出願の、「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｆｌｏｗ−Ｂａｓｅｄ Ａｄｄｒｅｓｓｉｎｇ ｉｎ ａ Ｍｏｂｉｌｅ Ｅｎｖｉｒｏｎｍｅｎｔ」と題する米国仮出願第６２／０８１，３８３号、及び、２０１５年９月２日出願の、「Ｓｙｓｔｅｍ ａｎｄ ｍｅｔｈｏｄ ｆｏｒ Ｆｌｏｗ−Ｂａｓｅｄ Ａｄｄｒｅｓｓｉｎｇ ｉｎ ａ Ｍｏｂｉｌｅ Ｅｎｖｉｒｏｎｍｅｎｔ」と題する米国特許出願第１４／８４３，２７７号に対する優先権を主張し、その両方の内容が参照によって本明細書に組み込まれる。

本発明は、パケットベースの通信のためのシステム及び方法に関し、特定の実施形態においては、インターネットプロトコル（ＩＰ）を使用したモバイル環境におけるフローベースのアドレス指定のためのシステム及び方法に関する。

パケットベースの通信ネットワークは、異なるトラフィックフローが異なる経路で伝送され得るように、フローベースのパケット転送技術を利用してよい。例えば、同一ネットワークノード間のアップストリームパケットフローとダウンストリームパケットフローとは、様々な理由、例えば、パケット処理要件、利用可能なリンク容量等のために、異なるネットワーク経路で伝送されてよい。フローベースのパケット転送技術は、パケットフローのサービス品質（ＱｏＳ）要件を満たすべく、トラフィックエンジニアリングされた（ＴＥ）経路でパケットフローを転送してよい。加えて、フローベースのパケット転送技術は、トラフィックフローのパケットに対して特殊な処理（例えば、ファイアウォール、暗号化、圧縮）を実行するパケット処理要素又はノードを介してトラフィックフローを転送してよい。

インターネットプロトコルバージョン６（ＩＰｖ６）を使用する従来のパケットベースのネットワークでは、パケットが、パケットを受信するネットワークノードによってどのように処理されるべきかを判断するために、ＩＰパケットヘッダ内のフローラベル及びトラフィッククラスなどの様々なフィールドが使用されてよい。しかしながら、これらのフィールドは、一方向（例えば、ノードＡからノードＢへ）においてのみ重要性を持ち、逆方向（例えば、ノードＢからノードＡへ）に移動するフローの経路及び処理に影響を与えるのには使用され得ない。加えて、これらのフィールドは、パケットの送信元からその宛先への経路上のどこででも変更されてよく、従って、経路の端から端まで全体にわたり保存されなくてよい。

従来のパケットベースのネットワークでは、デバイスは、その接続ポイントを変更したときはいつも、新たなＩＰアドレスを取得しなければならない。このことは、かなりの量のシグナリングオーバーヘッドを招くことがある。加えて、このことは、前のＩＰアドレスに関連付けられた、進行中の現在の何れかのパケットフローを中断させることがある。

デバイスが、そのＩＰアドレスを変更することなく、１つのネットワーク接続ポイントから別のネットワーク接続ポイントに移動してよい従来のモバイル環境では、パケットが、ネットワークのイングレスノードから、デバイスが現在使用しているネットワーク接続ポイントへ転送されることを保証するために、トンネルヘッダなどの追加情報がパケットに付加される必要があるだろう。プロキシモバイルインターネットプロトコルバージョン６（ＰＭＩＰｖ６）を使用するものなどのトンネリング解決手段は、トンネルエンドポイントにおけるトンネルコンテキストの維持を要求し、トンネルエンドポイント間での制御シグナリングを要求し、トンネルパケットオーバーヘッドをもたらし、同一のトンネル内で、特定のデバイス又はデバイスインタフェースにアドレス指定された全てのフローをカプセル化し、特定のデバイス又はデバイスインタフェースにアドレス指定された全てのフローを強制的に、同一のネットワークのイングレス／エグレスノードを介してルーティングされるようにする。いくつかの、これらのプロトコルの変形したものが、異なるトンネル内での異なるパケットフローのカプセル化をサポートするが、これらの解決手段は、割り当てられなければならないトンネルアドレス数と、トンネルエンドポイントによって維持されなければならないコンテキスト情報の量と、トンネルエンドポイント間で交換されなければならないシグナリング量との比例した増加を招く。

従って、モバイル環境におけるパケットの転送に関連付けられたオーバーヘッドを低減しながら、同時に、ＱｏＳとサービス固有の処理要件とを満たすべく、フロー固有のパケット処理を可能にする必要がある。

モバイル環境におけるフローベースのアドレス指定のためのシステム及び方法を説明する本開示の実施形態によって、技術的な利点が概して実現される。

一実施形態に従って、通信ネットワークにおいてパケットフローを通信するための方法が提供される。本例では、当該方法は、第１のフローハンドル（ＦＨ）を、第１のパケットのインターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）アドレスの中に埋め込む段階と、当該第１のパケットを第２のネットワークノードに送信する段階とを備える。第２のネットワークノードは、第１のＦＨに含まれたフロー情報に従って第１のパケットを処理又は転送する。本方法を実行するための装置もまた提供される。

別の実施形態に従って、通信ネットワークを通じて受信されたパケットを処理又は転送するための方法が提供される。本例では、当該方法は、第１のネットワークノードからパケットを受信する段階を備える。フローハンドル（ＦＨ）が、パケットのインターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）アドレスに埋め込まれる。当該方法は、パケットのＩＰｖ６アドレスに埋め込まれたＦＨによって特定されるフロー情報に従ってパケットを処理又は転送する方法を更に備える。本方法を実行するための装置もまた提供される。

更に別の実施形態に従って、インターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）ネットワークアドレスを割り当てるための方法が提供される。本例では、当該方法は、デバイスに関連付けられた第１のパケットフローと、デバイスに関連付けられた第２のパケットフローとが開始されたと判断する段階と、利用可能なアドレスのプールから、第１のＩＰｖ６アドレスを第１のパケットフローに、及び第２のＩＰｖ６アドレスを第２のパケットフローに割り当てる段階とを備える。第１のＩＰｖ６アドレスは、第２のＩＰｖ６アドレスとは異なる。当該方法は、第１のＩＰｖ６アドレスを、第１のパケットフローに関連付けられた少なくとも１つのパケットのアドレスフィールドの中に挿入する段階と、第２のＩＰｖ６アドレスを、第２のパケットフローに関連付けられた少なくとも１つのパケットのアドレスフィールドの中に挿入する段階と、第１のパケットフロー及び第２のパケットフローに関連付けられたパケットをネットワークを通じて通信する段階とを更に備える。本方法を実行するための装置もまた提供される。

本発明及びその利点のより完全な理解を期して、ここで、次の添付の図面と併せて以下の説明を参照する。

一実施形態の無線ネットワークの図を例示する。

従来のインターネットプロトコルバージョン６（ＩＰｖ６）アドレス及びパケットヘッダの図を例示する。

一実施形態のフローハンドル（ＦＨ）の図を例示する。

送信元ノードにおけるフローベースのアドレス指定のための、一実施形態の方法のフローチャートを例示する。

トランジットネットワークノードにおけるフローベースのアドレス指定のための、一実施形態の方法のフローチャートを例示する。

モバイルデバイスを含む、一実施形態のフローベースのイングレス及びエグレス選択スキームの図を例示する。 モバイルデバイスを含む、一実施形態のフローベースのイングレス及びエグレス選択スキームの図を例示する。

一実施形態のフローベースの経路選択スキームの図を例示する。

一実施形態の、指定経路でのパケット転送スキームの図を例示する。

一実施形態のＱｏＳベースのフロー集約スキームの図を例示する。

ＩＰｖ６アドレスにおいてフローハンドリング命令をシグナリングするための、一実施形態の方法１０００のフローチャートを例示する。

一実施形態の通信デバイスの図を例示する。

一実施形態のコンピューティングプラットフォームの図を例示する。

別途指示されない限り、異なる図面における対応する番号及び記号は概して対応する部分を指す。図は、実施形態の関連する態様を明確に例示するために描かれているのであり、必ずしも縮尺通りに描かれているわけではない。本文献を通して、用語「ＩＰｖ６」及び「ＩＰ」は、同じ意味で使用されてよい。

開示される実施形態の構造、製造、及び使用が以下で詳細に説明される。しかしながら、本発明は、多種多様な特定の文脈において具体化され得る多数の適用可能な発明の概念を提供するということが理解されるべきである。説明される特定の実施形態は、本発明を作成及び使用するための特定のやり方を例示しているに過ぎず、本発明の範囲を限定しない。

インターネットプロトコルバージョン６（ＩＰｖ６）ネットワークでは、フローベースのパケット転送は概して、パケットのインターネットプロトコル（ＩＰ）ヘッダにフローハンドリング情報を付加することによって実現される。フローハンドリング情報は、フローラベル又は他の情報（例えば、ネクストホップアドレスのリスト、サービス品質（ＱｏＳ）要件）を含んでよく、中間ノードが、適切な経路、例えば、フローラベルによって特定された経路、指定されたネクストホップへの経路等、でパケットを転送することを保証してよい。モバイルＩＰ環境では、パケットが、デバイスによって現在使用されているネットワーク接続ポイントに転送されることを保証すべく、ＩＰパケットに、プロキシモバイルＩＰｖ６プロトコルによって使用されるものなどのトンネルヘッダが付加されることが多い。同様に、特定のサービス機能経路でパケットを向かわせるべく、ネットワークサービスヘッダをＩＰパケットへ付加することをサービス機能チェイニングが要求してよい。残念ながら、フローハンドリング情報のパケットへの付加は、更なるオーバーヘッドをトラフィックフローに追加し、更なるシグナリングを要求してフローハンドリング情報を調整することがあり、このことは、パケットのペイロードを伝送するために要求されるネットワークリソース量を増やす。従って、ＩＰｖ６ネットワークにおけるフローベースの転送を実現するために要求されるオーバーヘッド量を低減するための技術が望まれる。

本開示の態様は、パケットのＩＰｖ６アドレス部分にフローハンドル（ＦＨ）を埋め込み、フローベースのパケット転送において、経路選択をサポートするために必要とされるオーバーヘッドを低減する。より具体的には、ＦＨは、標準的なＩＰｖ６アドレス内のインタフェース識別子を置換してよく、その結果、ＩＰｖ６パケット自体に更なるオーバーヘッドを少しも追加しなくてよい。一実施形態では、ＦＨは、パケットのＩＰｖ６アドレスの最下位ビット（例えば、右端の６４ビット）部分に埋め込まれてよい。パケットのＩＰｖ６アドレス部分のＦＨは、パケット処理に使用される情報を提供してよい。ネットワークノードが、ＦＨを含むパケットを受信した場合、ネットワークノードは、（例えば、最長プレフィックスマッチ又はプロトコル忘却型フォワーディング機能などの従来のルート選択機能を使用して、）パケットのＩＰｖ６アドレス部分に埋め込まれたＦＨによって特定される情報に基づいて、経路又はネクストホップアドレスを識別してよく、次に、識別された経路で、又は、識別されたネクストホップにパケットを転送してよい。有利なことに、ＩＰｖ６アドレスに埋め込まれたＦＨによって特定される情報は、経路又はネクストホップを選択すべく、従来のルート選択機能／アルゴリズム（例えば、最長プレフィックスマッチ、プロトコル忘却型フォワーディング機能等）と併せて使用されてよい。このように、ＩＰｖ６アドレスに埋め込まれたＦＨは、レガシデバイスで使用されるルート選択機能／アルゴリズムと後方互換性があってよく、それにより、既存のルータ及び他のネットワークノードを変更又は再構成する必要なく、ＦＨが埋め込まれたＩＰｖ６アドレスを使用して、フローベースの転送を実装することが可能になる。加えて、ＦＨは、パケットに関連付けられたサービス品質（ＱｏＳ）要件を識別してよく、ルート選択機能は、（例えば、最長プレフィックスマッチ又はプロトコル忘却型フォワーディング機能などのルート選択機能を使用して、）ＱｏＳ要件を満たすことが可能な経路を識別してよい。ＦＨは、予め定義されたサービス機能チェーン（ＳＦＣ）に沿ってパケットを転送するために使用されるＳＦＣ ＩＤ、ネットワークアクセスポイント（ＡＰ）を識別するＡＰ ＩＤ、無線アクセスリンク接続を識別する無線ベアラＩＤ、予め定義された経路でパケットを転送するために使用される経路ＩＤ、パケットのサービス品質（ＱｏＳ）要件を識別するＱｏＳコードポイント、及び／又は、エンドノード（例えば、無線デバイス）を識別するデバイスＩＤを備えてよい。多くの場合、適切な経路又はネクストホップアドレスを識別すべく、最長プレフィックスマッチ又はプロトコル忘却型フォワーディング機能などのルート選択機能が有利に使用されてよい。これらの詳細、及び他の詳細が、以下でより詳しく説明されている。

ＦＨは、ネットワークノードによって構築されてよい、又は、ネットワークから受信された命令に基づいてデバイスによって構築されてよい。例えば、無線通信ネットワークにおいて、ネットワークノード（例えばＡＰ）は、パケットのＩＰｖ６アドレス部分の中にＦＨを構築及び挿入するよう無線デバイス（ＷＤ）に命令する命令コマンドを送信してよい。一例では、ＡＰが、デバイス固有の無線リソース制御（ＲＲＣ）シグナリングメッセージを使用して、命令コマンドをＷＤに送信してよい。別の例では、拡張ノードＢ（ｅＮＢ）（例えば、３ＧＰＰロングタームエボリューション（ＬＴＥ）システムにおけるＡＰ）が、システム情報ブロック（ＳＩＢ）を使用して、命令コマンドを１又は複数のＷＤにブロードキャストしてよい。そのような例において、命令コマンドは、パケットのＩＰｖ６送信元アドレス部分に埋め込まれたＦＨに含まれるべき情報を示すテンプレート及びポリシルールを含んでよい。

図１は、データを通信するための無線ネットワーク１００を例示する。無線ネットワーク１００は、カバレッジエリア１０１を有するアクセスポイント（ＡＰ）１１０と、複数の無線デバイス１２０と、バックホールネットワーク１３０とを含む。ＡＰ１１０は、とりわけ、無線デバイス１２０とのアップリンク（破線）接続、及び／又はダウンリンク（点線）接続を確立することによって、無線アクセスを提供可能な、基地局、拡張ノードＢ（ｅＮＢ）、フェムトセル、及び他の無線対応デバイスなどの任意のコンポーネントを含んでよい。無線デバイス１２０は、ＡＰ１１０との無線接続を確立可能な、移動局（ＳＴＡ）、マシンタイプ通信（ＭＴＣ）デバイス、ユーザ機器（ＵＥ）、又は他の無線対応デバイスなどの任意のコンポーネントを備えてよい。バックホールネットワーク１３０は、データがＡＰ１１０とリモートノードとの間で交換されることを可能にする任意のコンポーネント又はコンポーネントの集まりであってよい。いくつかの実施形態では、そのようなネットワークが複数あってよい、及び／又は、ネットワークは、リレー、低電力ノード等といった他の様々な無線デバイスを備えてよい。

図２は、従来のインターネットプロトコルバージョン６（ＩＰｖ６）アドレス２００の図を例示する。示されるように、１２８ビットのＩＰｖ６アドレス２００は、ルーティングプレフィックス２０５及びインタフェース識別子２２０を備える。ルーティングプレフィックス２０５は、ＩＰｖ６アドレスの最上位ビットに位置し、グローバルプレフィックス２１０及びサブネットプレフィックス２１５を含む。グローバルプレフィックス２１０は、インターネット全体内でパケットをルーティングするために使用され、一方、サブネットプレフィックス２１５は、ローカルネットワーク内でパケットをルーティングするために使用される。ＩＰｖ６アドレスの最下位ビットに位置するインタフェース識別子２２０は、エンドノードにおけるインタフェースを識別する。一般的に、ルーティングプレフィックス２０５は、アドレスの最上位６４ビットを占有し、インタフェース識別子２２０は、アドレスの最下位６４ビットを占有する。しかしながら、１２８ビットのアドレスの他の構成もまた可能である。ＩＰｖ６アドレス２００は、ＩＰｖ６ヘッダ２９０内の送信元アドレス２９１又は宛先アドレス２９２であってよい。パケットはインターネット全体をトラバースするように説明されてよいが、パケットの宛先は、パケットが受信されるネットワークセグメントの外部でなくてもよいことが理解されるべきである。例えば、無線通信ネットワークでは、宛先ノードは、無線アクセスネットワークの一部であってよい。

図３は、一実施形態の、フローハンドル（ＦＨ）３０１を保持するＩＰｖ６アドレス３００の図を例示する。示されるように、ＦＨ３０１は、ＩＰｖ６アドレス３００の最下位ビットに埋め込まれている。ＦＨ３０１は、ＩＰｖ６アドレス３００が付加されるパケットを処理するための命令を特定するコンテキスト情報を含んでよい。従って、ＦＨ３０１は、パケットを処理又は転送するために使用されるフローハンドリング情報をネットワークノードに伝達する。例えば、ネットワークノードが、ＩＰｖ６アドレス３００によってカプセル化されたパケットを受信した場合、ネットワークノードは、パケットのＩＰｖ６アドレス３００に埋め込まれたＦＨ３０１によって特定される情報（例えば，経路識別子（ＩＤ），ＱｏＳ要件等）に基づいて、経路又はネクストホップを識別し、次に、識別された経路で、又は識別されたネクストホップにパケットを処理又は転送する。

ＦＨ３０１は、論理フロー識別子（ＩＤ）３１２、サービス機能チェーン（ＳＦＣ）識別子（ＩＤ）３２２、アクセスポイント（ＡＰ）識別子（ＩＤ）３２３、無線ベアラ識別子（ＩＤ）３２４、経路識別子（ＩＤ）３３２、ＱｏＳコードポイント３３３、無線デバイス（ＷＤ）識別子（ＩＤ）３４３、又はそれらの組み合わせを含んでよい。論理フローＩＤ３１２は、特定の一連のパケットを識別する。ＳＦＣ ＩＤ３２２は、予め定義されたサービス機能チェーンを識別する。ＡＰ ＩＤ３２３は、ネットワークアクセスポイントを識別する。無線ベアラＩＤ３２４は、無線アクセスリンク接続を識別する。経路ＩＤ３３２は、ネットワークを通る予め定義された経路を識別する。ＱｏＳコードポイント３３３は、パケットのＱｏＳ要件を識別する。ＷＤ ＩＤ３４３は、無線デバイス及び／又はエンドノードを識別する。

ＦＨ３０１は、様々な異なるタイプの情報を保持する。情報のタイプは、ＦＨ３０１のクラス及び／又はフォーマットに依存してよい。一例では、ＦＨ３０１が第１のフォーマット（例えば、クラスＡ、フォーマット０）を有する場合、ＦＨ３０１は、フォーマットフィールド３１１及び論理フローＩＤフィールド３１２を保持する。別の例では、ＦＨ３０１が、第２のフォーマット（例えば、クラスＢ、フォーマットｍ）を有する場合、ＦＨ３０１は、フォーマットフィールド３２１、ＳＦＣ ＩＤフィールド３２２、ＡＰ ＩＤフィールド３２３、及び無線ベアラＩＤフィールド３２４を保持する。更に別の例では、ＦＨ３０１が、第３のフォーマット（例えば、クラスＢ、フォーマットｎ）を有する場合、ＦＨ３０１は、フォーマットフィールド３３１、経路ＩＤフィールド３３２、ＱｏＳコードポイントフィールド３３３、及び無線ベアラＩＤフィールド３３４を保持する。更に別の例では、ＦＨ３０１が、第４のフォーマット（例えば、クラスＤ、フォーマットｓ）を有する場合、ＦＨ３０１は、フォーマットフィールド３４１、ＡＰ ＩＤフィールド３４２、及びＷＤ ＩＤフィールド３４３を保持する。更に別の例では、ＦＨ３０１が、第５のフォーマット（例えば、クラスＦ、フォーマットｔ）を有する場合、ＦＨ３０１は、フォーマットフィールド３５１、及びＡＰ ＩＤフィールド３５２を保持する。フォーマットフィールド３１１、３２１、３３１、３４１、３５１は、ＦＨ３０１のフォーマットを識別する値（例えば、０、１ｙｙｙｙｙｙｙｙ、１１１１１１１１・・・１ｙｙｙｙｙｙｙｙ等、ここで、ｙは、フォーマット識別子のビットである）を含んでよい。異なるフォーマットは、様々な異なるタイプの情報を保持してよい。

図４は、パケットフロー送信が開始された場合に送信元ノードによって実行されるであろう、通信ネットワークにおけるフローベースのアドレス指定のための一実施形態の方法４００のフローチャートを例示する。

示されるように、方法４００は、段階４１０から開始する。段階４１０において、送信元ノードは、パケットフローに対して行われるべき処理を判断する。送信元ノードは、ネットワークノード（例えば、ＡＰ）、デバイス、又はネットワークノードからの命令を受けて動作するデバイスであってよい。送信元ノードは、ＩＰヘッダからの１又は複数のフィールド、伝送ヘッダ（例えば、ＴＣＰ、ＵＤＰ）、又はアプリケーションヘッダ（例えば、ＨＴＴＰ、ＲＴＰ）と、デバイスのタイプ（例えば、移動又は固定）と、デバイスのクラス（例えば、マシンタイプ通信デバイス又はヒューマンタイプ通信デバイス）と、デバイス上のアプリケーションから受信された情報と、トラフィック管理（ＴＭ）エンティティから受信された情報と、デバイスによって使用されるアクセスリンクのタイプ（例えば、有線又は無線）と、デバイスによって使用されるアクセスリンク（例えば、無線アクセスベアラチャネル）（の特性）とのうちの１又は複数に基づいて処理を判断してよい。段階４２０において、送信元ノードは、フローハンドルにおいて伝達される必要がある情報に基づいてフローハンドルの適切なフォーマットを判断して、パケットフローに対して行われるべき処理を反映する。当該情報は、特定の一連のパケットを識別するパケットフローＩＤ、予め定義されたサービス機能チェーン（ＳＦＣ）に沿ってパケットを転送するためのＳＦＣ ＩＤ、ネットワークアクセスポイント（ＡＰ）を識別するＡＰ ＩＤ、無線アクセスリンク接続を識別する無線アクセスベアラＩＤ、予め定義された経路でパケットを転送するための経路ＩＤ、パケットのサービス品質（ＱｏＳ）要件を識別するＱｏＳコードポイント、及び／又は、エンドノードを識別するデバイスＩＤを備えてよい。一実施形態では、ネットワークエッジノード（例えば、ＡＰ）が、パケットをＡＰに送信する前にパケットのＩＰｖ６アドレス部分にＦＨを埋め込むようデバイスに命令する。そのような実施形態では、ＡＰは、パケットのＩＰｖ６アドレス部分にＦＨを埋め込むための、選択されたフローハンドルフォーマット及びポリシルールを含んでよい命令コマンドをデバイスに送信する。無線ネットワークでは、当該命令は、例えばシステム情報ブロック（ＳＩＢ）において、専用無線リソース制御（ＲＲＣ）シグナリングメッセージ又はブロードキャストの何れかを使用して、無線デバイス（ＷＤ）に送信されてよい。当該命令は、フローごとに（例えば、新たなパケットフローが開始されたときはいつも）、又は、無線アクセスベアラ（ＲＡＢ）ごとに（例えば、特定のＲＡＢを通じて送信される全てのパケットフローに）、デバイスごと又はインタフェースごとに（例えば、そのデバイスによって、又は、特定のデバイスインタフェースを通じて送信される全てのパケットフローに）、又は、グループごとに（例えば、特定のグループのデバイスによって送信される全てのパケットフローに）提供されてよい。段階４３０において、送信元ノードは、処理情報を、選択されたフローハンドルの対応するフィールドの中に埋め込む。段階４４０において、送信元ノードは、フローハンドルを、ＩＰパケットヘッダのアドレス部分の中に挿入する。その後、段階４５０において、送信元ノードは、埋め込まれたフローハンドルを有するパケットを次のネットワークノードに転送する。ＦＨは、要求されるフローハンドリング処理に従ってパケットを処理又は転送するための情報を、次のネットワークノードに提供してよい。本開示の大半は、ＦＨが埋め込まれたＩＰｖ６アドレスを、ＩＰｖ６ヘッダの送信元アドレスフィールドの中に挿入することについて説明しているが、ＦＨが埋め込まれたＩＰｖ６アドレスをＩＰｖ６ヘッダの宛先アドレスフィールドの中に挿入する場合に、本発明の概念の多くが同様に適用され得ることが理解されるべきである。

図５は、別のネットワークノードからパケットを受信する場合にトランジットノードによって実行されるであろう、通信ネットワークノードにおけるフローベースのアドレス指定のための、一実施形態の方法５００のフローチャートを例示する。

示されるように、方法５００は段階５１０から開始する。段階５１０において、トランジットノードは、別のネットワークノードからパケットを受信する。段階５２０において、トランジットノードは、パケットのインターネットプロトコル（ＩＰ）アドレス部分からフローハンドルを取り出す。段階５３０において、トランジットノードは、フローハンドルのフォーマットを判断する。段階５４０において、フローハンドルのフォーマットに基づいて、トランジットノードは、パケットに提供されるべき処理を特定するハンドルからフロー処理情報を取り出す。その後、方法５００は段階５５０に進む。段階５５０において、トランジットノードは、ＦＨによって特定される情報に従って、パケットを処理又は転送する。一実施形態では、トランジットノードは、パケットのＩＰアドレス部分に埋め込まれたＦＨによって特定される情報に関連付けられた経路又はネクストホップを識別し、次に、識別された経路で、又は、識別されたネクストホップにパケットを転送する。別の実施形態では、トランジットノードは、ＦＨに関連付けられたサービス品質（ＱｏＳ）要件を識別し、次に、ＱｏＳ要件を満たすことが可能な経路でパケットを転送する。更に別の実施形態では、トランジットノードは、ＦＨに関連付けられた処理タスク（例えば、フィルタリング、ファイアウォール等）を定義するサービス機能チェーンを識別し、次に、パケットに対して処理タスクを実行する、又は、そうでなければ、処理タスクを実行可能な次のネットワークノードにパケットを転送する。

いくつかの実施形態では、ネットワークリソース及び／又は無線リソースの利用可能性、並びにネットワーク事業者のポリシに従って、個々のトラフィックフローの特性に基づいて、パケットフローのためのネットワークイングレスポイント及びネットワークエグレスポイントが判断されてよい。例えば、無線エッジノード（例えば、ＡＰ）を通過する各トラフィックフローは、１又は複数の基準、例えば、ＱｏＳ要件、利用可能な無線リソース、利用可能なバックホールリソース等に基づいて、無線アクセス技術（例えば、ロングタームエボリューション（ＬＴＥ）、米国電気電子学会（ＩＥＥＥ）８０２．１１等）と、協同する送信／受信ポイント（例えば、無線アクセスネットワーク送信ポイント（ＲＡＮ‐ＴＰ）及び／又はＲＡＮ受信ポイント（ＲＡＮ‐ＲＰ））のセットとに関連付けられてよい。或いは、ネットワークエッジノード（例えば、ボーダーゲートウェイ）を通過する各トラフィックフローは、移動体通信事業者のコスト及び／又はセキュリティポリシに基づいて、リモート対応ノード（ＲＣＮ）への／からのルート、及び／又は、エッジ処理機能（例えば、ファイアウォール、ネットワークアドレス変換（ＮＡＴ）、侵入検知）のセットに関連付けられてよい。図６Ａは、フローベースのイングレス及びエグレス選択スキーム６０１を例示する。図中、フローＡ、フローＢ、及びフローＣは、同時に無線デバイス６１０に関連付けられている。フローＡは、ＲＡＮ送信ポイント６２２及び６２４、並びにボーダーゲートウェイ６３２を介して転送され、同時に、フローＢは、ＲＡＮ送信ポイント６２４及び６２６、並びにボーダーゲートウェイ６３６を介して転送され、フローＣは、ＲＡＮ送信ポイント６２８及びボーダーゲートウェイ６３６を介して転送される。一実施形態では、ＲＡＮ送信ポイント６２２、６２４、６２６は第１のアクセスポイントに関連付けられており、ＲＡＮ送信ポイント６２８は、第２のアクセスポイントに関連付けられている。いくつかの実施形態では、無線デバイス６１０は、無線ネットワークの異なる位置に移動してよい。無線デバイス６１０のこの位置変更は、いくつかのフロー（例えば、フローＡ及びフローＢ）の経路に、他のフロー（例えば、フローＣ）の経路に影響を与えることなく、影響を与えてよい。図６Ｂは、無線デバイス６１０の位置変更の後の、フローベースのイングレス及びエグレス選択スキーム６０２を例示する。示されるように、この変更はフローＡ及びフローＢを異なる経路で流れさせ、フローＡが（ＲＡＮ‐ＴＰ６２４ではなく）ＲＡＮ‐ＴＰ６２６を介してルーティングされ、フローＢが、（ＲＡＮ‐ＴＰ６２４及び６２６ではなく）ＡＰ６２８を介してルーティングされている。フローＣの経路は変化しない。

いくつかの実施形態では、パケットフローのパケット転送経路及び処理スキームは、個々のパケットフローの特性（例えば、ＱｏＳ要件）、ネットワークリソース及び無線リソースの利用可能性、及び／又は、適用可能なサービス機能チェーン（ＳＦＣ）に基づいて判断されてよい。図７は、フローベースの経路選択スキーム７００を例示する。リモート対応ノード（ＲＣＮ）７５１からの第１のダウンリンクパケットフローが、ボーダーゲートウェイ７３０からのルータ７４１及び７４２を通る経路で、サービングアクセスポイント７２０を介して無線デバイス７１０に転送されてよい。ＲＣＮ（ＲＣＮ）７５２からの第２のダウンリンクパケットフローが、ボーダーゲートウェイ７３０からのルータ７４３及び７４４を通る異なる経路で、サービングＡＰ７２０を介して無線デバイス７１０に転送されてよい。ＲＣＮ７５１及び７５２は、同一のプラットフォーム上で実装されてよい。一方で、異なるＩＰアドレスが異なるパケットフローに割り当てられるので、各フローは個別に処理される。パケットフロー経路が、一方向スキーム又は双方向スキームの何れかによってハンドリングされてよい。例えば、双方向スキームでは、アップリンク方向のパケットフローは、ダウンリンク方向のパケットフローと同一の経路をたどり、一方、一方向スキームでは、アップリンク方向のパケットフロー（例えば、ＲＣＮに送信される要求）は、ダウンリンク方向のパケットフロー（例えば、ＲＣＮから受信された応答）とは異なる経路をたどってよく、異なる処理スキームに従ってハンドリングされてよい。パケットフローがたどる経路を判断するためにルータによって使用される転送情報ベース（ＦＩＢ）が、集中型のトラフィック管理（ＴＭ）エンティティによってポピュレートされてよい、又は、従来の分散型のルーティングプロトコルを使用してルータ間で交換された情報の結果であってよい。

いくつかの実施形態では、異なる可能性のあるインターネットプロトコルアドレスを、モバイルデバイスによって開始された各パケットフローに割り当てることによって、局所的なフローベースのモビリティ管理スキームが提供されてよい。パケットフローは、ウェブ閲覧行動では、１フロー当たり平均３０‐３５パケットの短命である傾向がある。その結果、パケットフローが完了されてよく、関連付けられたＩＰアドレスが解放されてよく、その後、モバイルデバイスはその接続ポイントをネットワークに変更する。これらの例では、プロキシモバイルＩＰｖ６などのプロトコルに関連付けられたトンネリングオーバーヘッド及び制御シグナリングオーバーヘッドを招くことなく、モバイルデバイスにサービス提供するネットワーク接続ポイントにダウンリンクフローが直接転送され得る。モバイルデバイスは、モバイルデバイスがアクティブなパケットフローを有さない非アクティブ期間又は休止期間の間に接続ポイントを変更してよく、これにより、パケットフロー又はＩＰアドレスの維持に関連する何れのアクションの必要性も除去されてよい。モバイル無線デバイス（ＷＤ）によって使用されてよいＲＡＮ送信ポイント及び／又はＲＡＮ受信ポイントは、パケットフローの生存期間中に変更されてよい。そのような変更は、モバイルＷＤの移動の結果、無線リンク環境の変化（例えば、増大する干渉）、及び／又は、ネットワークインフラストラクチャ条件の変化（例えば、バックホール輻輳）であってよい。いくつかの例では、それらの変化は、モバイルＷＤから発せられたパケットフローのサブセットのみに影響を与えてよい。例えば、図６Ｂに例示されるように、変化が、いくつかのトラフィックフロー（例えば、フローＡ及びフローＢ）の経路に、他のトラフィックフロー（例えば、フローＣ）の経路には影響を与えることなく、影響を与えてよい。変化が起こった場合、影響を受けたパケットフローは、隣接ＡＰに向け直されてよい。従って、モビリティ管理アクションは局在化されてよく、処理負荷は、ネットワークの無線エッジに、又はその近くに位置するネットワークノードにわたって分散されてよい。その結果、レイテンシ及びネットワークシグナリングオーバーヘッドが低減されてよく、特殊大容量モビリティアウェア（ｍｏｂｉｌｉｔｙ−ａｗａｒｅ）ルータ（例えば、コアネットワークにおけるサービングゲートウェイ（ＳＧＷ））の必要性が除去されてよい。

いくつかの実施形態では、ダウンリンクフロー及びアップリンクフローのパケットは、最短経路又は最小コスト経路の何れかで、ベストエフォート方式で転送されてよい。他の実施形態において、ダウンリンクフロー及び／又はアップリンクフローのパケットが、パケットのＱｏＳ要件に基づいて、又は、ネットワークトラフィックが複数の経路にわたって平衡を保たれることを保証すべく、予め定められた経路で転送されるべきであると、トラフィック管理（ＴＭ）エンティティが判断してよい。例えば、特定の経路は、指定エンドポイント（例えば、サービングＡＰ）へのベストエフォート経路、ＴＭエンティティによって識別されたトラフィックエンジニアリングされた経路、及び／又は、パケットのための一連のサービス機能を識別するサービス機能経路であってよい。図８は、指定経路でパケットを通信するための、一実施形態のパケット転送スキーム８００の図を例示する。無線リンクにわたるシグナリングオーバーヘッドを最小限に抑えるべく、ネットワークノード（例えば、サービングＡＰ）が、割り当てられたフローアドレスを、ＷＤから受信されたパケットのヘッダの中に挿入してよい。パケット転送スキーム８００の段階１において、ＷＤは、ＷＤとＡＰとの間の無線リンク上で定義された無線アクセスベアラを通じてアップリンクパケットを送信する。ＷＤは、パケットフローに関連付けられた送信元ＴＣＰ／ＵＤＰポート（例えば、ポート_Ａ）と共に、宛先アドレス（例えば、ＩＰ_ＲＣＮ）及びＴＣＰ／ＵＤＰポートをパケットヘッダの中に挿入してよい。一例では、ＷＤは、無線リンクを通じてパケットを送信する前に、指定されていない（例えば、ヌル）送信元ＩＰアドレスをパケットヘッダの中に挿入してよい。別の例では、ＷＤは、無線リンクを通じてパケットを送信する前に、リンクローカル送信元ＩＰアドレスをパケットヘッダの中に挿入してよい。

無線エッジネットワークノード（例えば、サービングＡＰ）がアップリンクパケットを受信した場合、無線エッジネットワークノードは、フローベースのアドレスをパケットに割り当ててよい。フローベースのアドレスは、パケットヘッダ内の送信元アドレスのＦＨ部分の中に埋め込まれてよい。フローベースのアドレスは、無線エッジノードによって自律的に生成されてよい。或いは、フローベースのアドレスは、ＴＭエンティティから受信された命令に基づいて生成されてよい。送信元アドレスは、（複数の）サービングＡＰを含む無線ネットワークのトポロジーを反映するルーティングプレフィックス（ＲＰ）を含んでよい。図８によって描写された例において明示されるように、送信元アドレスのＦＨ内のコンテキスト情報は、ダウンリンクパケットフローに関連付けられた経路と、無線アクセスベアラ（ＲＡＢ）とを識別してよい。例えば、ＦＨは、トラフィックエンジニアリングされた経路若しくはサービス機能経路、ＲＡＢ、ＱｏＳ要件、又はそれらの組み合わせを識別してよい。別の例では、ＦＨは、サービングＡＰへのベストエフォート経路とＲＡＢとを識別してよい。ＲＡＢ ＩＤが、パケットが受信されたアップリンク無線ベアラを識別してよい。或いは、ＲＡＢ ＩＤは、対応するダウンリンク無線ベアラに関連付けられてよい。当該対応するダウンリンク無線ベアラは、あらゆる戻りのダウンリンクパケットをＷＤに伝送するために使用されてよい。パケット転送スキーム８００の段階２において、ＡＰは、ＩＰパケットルーティングスキーム／機能、例えば、最長プレフィックスマッチ、プロトコル忘却型フォワーディング機能等を使用して、アップリンクパケットをエグレスボーダーゲートウェイに転送してよい。いくつかの状況では、各ルータが、その経路選択処理中に送信元アドレスに埋め込まれた経路ＩＤを含む場合、アップリンクトラフィックエンジニアリングされた経路が選択されてよい。パケット転送スキーム８００の段階３において、ボーダーゲートウェイは、ＩＰパケットルーティングスキームに従って、（例えば、インターネット全体を介して）パケットをＲＣＮに転送してよい。一実施形態では、ボーダーゲートウェイは、パケットの送信元アドレスに含まれたローカルなルーティングプレフィックスを、ネットワークにおける、例えば、インターネット全体におけるボーダーゲートウェイの位置を反映するグローバルなルーティングプレフィックスと置換する。

パケット転送スキーム８００の段階４において、ＲＣＮは、アップリンクパケットの送信元アドレス及び送信元ＴＣＰ／ＵＤＰポートをそれぞれ、ダウンリンクパケットのダウンリンクパケットヘッダの宛先アドレス及びポート部分の中に埋め込むことによって、ダウンリンクパケットを生成してよい。次にＲＣＮは、ダウンリンクパケットヘッダ内のルーティングプレフィックスに基づいて、ＩＰパケットルーティングスキームを使用して、インターネット全体を介してダウンリンクパケットをイングレスボーダーゲートウェイに転送してよい。特に、ダウンリンクパケットを受信するイングレスボーダーゲートウェイは、アップリンクパケットを送信するエグレスボーダーゲートウェイと同一でなくてよい。なぜなら、ルーティングの決定は、インターネット全体、及び／又は無線インフラストラクチャネットワーク内で異なっていてよいからである。ダウンリンク宛先ＩＰアドレスのＦＨに含まれたフロー情報は、アップリンクフロー及びダウンリンクフローが、異なるボーダーゲートウェイを介してルーティングされることを可能にするために、及び、ボーダーゲートウェイ間でコンテキスト情報を交換する必要性を除去するために使用されてよい。パケット転送スキーム８００の段階５において、例えば、フローベースの宛先アドレスに埋め込まれた（ローカルな）ルーティングプレフィックス、経路ＩＤ、ＱｏＳコードポイント、又はそれらの組み合わせを含む最長プレフィックスマッチに基づいて、ルート選択機能／アルゴリズムを使用して、イングレスボーダーゲートウェイは、無線インフラストラクチャネットワークを介してダウンリンクパケットをサービングＡＰにルーティングする。従来のルーティングプロトコルを使用してルータによって交換された情報によって、又は、集中型のＴＭエンティティによって、無線インフラストラクチャネットワークのルータにより使用される転送情報ベース（ＦＩＢ）がポピュレートされてよい。パケット転送スキーム８００の段階６において、サービングＡＰはダウンリンクパケットを受信し、次に、ダウンリンクパケットのフローベースの宛先アドレスに埋め込まれた情報（例えば、ＲＡＢ ＩＤ等）に基づいて、ダウンリンク無線ベアラ及びその関連付けられたコンテキスト情報を判断してよい。ダウンリンク無線ベアラは、次に、パケットをＷＤに配信するために使用されてよい。上述の実施形態のパケット転送スキームは、いくつかの便益を有するであろう。例えば、パケットはトンネルにカプセル化される必要がないので、トンネルオーバーヘッドが除去されてよい。別の例として、ダウンリンクパケットをＡＰに転送するために従来のＩＰルーティングスキームが使用されてよいので、ＡＰとモビリティアンカーポイントとの間で制御シグナリングオーバーヘッドが除去されてよい。更に別の例として、異なるパケットフローは、パケットの宛先アドレスのＦＨに埋め込まれたパケット転送情報に基づいて、無線インフラストラクチャネットワークを介して異なる経路をたどってよい。

いくつかの実施形態では、パケットフローに適用されるべきＱｏＳ要件を反映すべく、ＩＰアドレスがパケットフローに割り当てられてよい。従来のＩＰｖ６ヘッダ内のトラフィッククラスフィールドは、各ルータにおける待ち行列挙動を定義すべく使用されてよいが、従来のＩＰｖ６ヘッダ内のトラフィッククラスフィールドは、ネットワークノードのセットを通る転送経路を識別しなくてよい。有益に、ネットワークノードのセットを通るＱｏＳ対応のルートを識別すべく、フローベースのアドレスのＦＨに埋め込まれたＱｏＳラベルがルータによって使用されてよい。複数のパケットフローが同様のＱｏＳ要件を有する場合、ＱｏＳ対応のルートは、例えば、従来の最長プレフィックスマッチを使用して、各ルータにおけるより少ない数のＦＩＢエントリの中に集約されてよい。図９は、無線インフラストラクチャを通じてダウンリンクパケットをルーティングすべく、一実施形態のＩＰｖ６ヘッダ９０９を使用する、一実施形態のＱｏＳベースのフロー集約スキーム９００の図を例示する。示されるように、当該実施形態のＩＰｖ６ヘッダ９０９は、ＱｏＳラベル９９２及びエンドポイントＩＤ９９４を含むフローベースの宛先アドレス９９０を備える。一実施形態では、フローベースの宛先アドレス９９０はダウンリンクパケットの宛先アドレスであり、アップリンクパケットの送信元アドレスからコピーされる。

本例では、パケットフロー９０１はＲＣＮ９５１からＷＤ９１１に通信され、パケットフロー９０２は、ＲＣＮ９５２からＷＤ９１２に通信され、パケットフロー９０３は、ＲＣＮ９５３からＷＤ９１３に通信され、パケットフロー９０４は、ＲＣＮ９５４からＷＤ９１４に通信されている。パケットフロー９０１及び９０２は、同様のＱｏＳ要件を有してよい。ＷＤ９１１、９１２に関連付けられたＡＰ９２１、９２２は、ＩＰｖ６アドレスを、同一のＱｏＳラベル（例えば、ＱｏＳ‐Ａ）を含むパケットフロー９０１、９０２に割り当ててよい。同様に、ＷＤ９１３、９１４に関連付けられたＡＰ９２２、９２３は、ＩＰｖ６アドレスを、同一のＱｏＳラベル（例えば、ＱｏＳ‐Ｂ）を含むパケットフロー９０３、９０４に割り当ててよい。

ボーダーゲートウェイ９３０からＡＰ９２１、９２２への経路の途中のルータ９４１、９４２は、その宛先アドレスがＱｏＳラベル「ＱｏＳ‐Ａ」を含むパケットのためのネクストホップを識別する転送情報ベース（ＦＩＢ）テーブルを有してよい。同様に、ボーダーゲートウェイ９３０からＡＰ９２２、９２３への経路の途中のルータ９４３、９４４は、その宛先アドレスが、ＱｏＳラベル「ＱｏＳ‐Ｂ」を含むパケットのためのネクストホップを識別するＦＩＢテーブルを有してよい。ルータ９４１、９４２、９４３、９４４は、集中型のＴＭエンティティからの命令に基づいて、又は、分散型のルーティングプロトコル交換に基づいて、ＦＩＢテーブルを維持及び更新してよい。

ボーダーゲートウェイ９３０は、ＲＣＮ９５１及び９５２からパケットフロー９０１、９０２を受信し次第、ＱｏＳラベル「ＱｏＳ‐Ａ」を有するパケットフロー９０１、９０２をルータ９４１に向かわせてよい。ルータ９４１は次に、パケットフロー９０１、９０２をルータ９４２に向かわせてよい。一実施形態では、ボーダーゲートウェイ９３０は、ＱｏＳラベル「ＱｏＳ‐Ａ」を含む最長プレフィックスマッチに基づいて、パケットフロー９０１、９０２をルータ９４１に転送すると決定する。同様に、ルータ９４１は、ＱｏＳラベル「ＱｏＳ‐Ａ」を含む最長プレフィックスマッチに基づいて、パケットフロー９０１、９０２をルータ９４２に転送すると決定してよい。ルータ９４２は、パケットフロー９０１はＡＰ９２１に転送されるべきであり、パケットフロー９０２はＡＰ９２２に転送されるべきであると判断する。ルータ９４２は、ＱｏＳラベル「ＱｏＳ‐Ａ」と、パケットフロー９０１、９０２のパケットによって保持されたエンドポイントＩＤとに最長プレフィックスマッチアルゴリズムを適用することによって、この判断に至ってよい。

加えて、ボーダーゲートウェイ９３０は、ＲＣＮ９５３及び９５４からパケットフロー９０３、９０４を受信し次第、ＱｏＳラベル「ＱｏＳ‐Ｂ」を有するパケットフロー９０３、９０４をルータ９４３に向かわせてよい。ルータ９４３は次に、パケットフロー９０３、９０４をルータ９４４に向かわせてよい。これらのルーティングの決定は、ＱｏＳラベル「ＱｏＳ‐Ｂ」を含む最長プレフィックスマッチを判断することによって成されてよい。ルータ９４４は、パケットフロー９０３はＡＰ９２２に転送されるべきであり、パケットフロー９０４はＡＰ９２３に転送されるべきであると判断する。ルータ９４２は、ＱｏＳラベル「ＱｏＳ‐Ｂ」と、パケットフロー９０３、９０４のパケットによって保持されたエンドポイントＩＤとに最長プレフィックスマッチアルゴリズムを適用することによって、この判断に至ってよい。

いくつかの実施形態では、異なるＩＰアドレスが、同一のデバイスに関連付けられた異なるパケットフローに割り当てられてよく、これにより、パケットフローは、各ＩＰアドレスに関連付けられた異なるフローハンドリング命令に応じて処理／転送される。いくつかの実施形態では、フローハンドリング命令はＩＰアドレスに明示的に埋め込まれ、一方で、他の実施形態においては、アドレスは、先験的にアドレスに関連付けられた所望のフローハンドリングに従って選択される。図１０は、ネットワークノードによって実行されるであろう、ＩＰｖ６アドレスにおいてフローハンドリング命令をシグナリングするための、一実施形態の方法１０００を例示する。方法１０００は段階１０１０から開始し、段階１０１０において、ネットワークノードは、第１のパケットフロー及び第２のパケットフローが開始されたと判断する。第１のパケットフロー及び第２のパケットフローの両方は、同一のデバイスに関連付けられている。次に、方法１０００は段階１０２０に進む。段階１０２０において、ネットワークノードは、第１のＩＰｖ６アドレスを第１のパケットフローに、第２のＩＰｖ６アドレスを第２のパケットフローに割り当てる。ＩＰｖ６アドレスは、異なるフローハンドリング命令に関連付けられている。次に、方法１０００は段階１０３０に進む。段階１０３０において、ネットワークノードは、第１のパケットフローの少なくとも１つのパケットの中に第１のＩＰｖ６アドレスを挿入する。方法１０００は次に段階１０４０に進む。段階１０４０において、ネットワークノードは、第２のパケットフローの少なくとも１つのパケットの中に第２のＩＰｖ６アドレスを挿入する。段階１０５０において、ネットワークノードは、第１のパケットフロー及び第２のパケットフローに関連付けられたパケットをネットワークを通じて通信する。パケットフローがそれぞれ異なるＩＰｖ６アドレスに割り当てられるおかげで、第１のパケットフローに関連付けられたパケットは、第２のパケットフローに関連付けられたパケットとは異なるフローハンドリング命令に従って処理又は転送される。

いくつかのシナリオでは、無線デバイスから発せられた複数のパケットフローが、同一のコンテキストを共有（例えば、同一の処理を受信）してよく、同一のＩＰフローアドレスに関連付けられてよい。これらの例では、（例えば、カプセル化されたＴＣＰ又はＵＤＰヘッダ内のポート番号を使用することによって、）ＩＰパケットヘッダ外のフィールドを使用して、フローを区別すべく、既存の技術が使用されてよい。

データプレーン内において、フローベースのアドレスは、パケットフローの性質を識別すべく使用されてよい。例えば、ユニキャストパケットフローでは、制御情報（例えば、肯定応答又はレート制御）を含むパケットは、データのみを含むパケットと区別されてよい。ビデオストリームの場合、Ｉ‐フレームを含むパケットは、Ｂ‐フレーム又はＰ‐フレームを含むパケットと区別されてよい。ＮＡＣＫ指向の信頼性の高いマルチキャストの場合、初期データの送信を含む転送リンクパケットは、再送信を含むパケット、又は、ＦＥＣ符号化された再送信を含む転送リンクパケットと区別されてよい。

異なるタイプのデータプレーンパケットフロー間の区別に加えて、様々なタイプの制御プレーン及び管理プレーントラフィックを区別すべく、フローベースのアドレスもまた使用されてよい。

特に、ドメイン／ネットワークのイングレスポイントにおいてコンテキスト情報を維持することが、トラフィックフローをサポートするのに必要とされるストレージリソースの量を増やすだけでなく、例えば、適切なトンネルパケットの中に各着信パケットをカプセル化すべく、処理要件も増やす。本開示の実施形態は、パケットのＩＰｖ６アドレスに、何らかのコンテキスト情報を埋め込むことによって、ネットワークのイングレスポイントにおいて格納される必要があるコンテキスト情報の量を低減する。一実施形態では、デバイスは、フローハンドリング（例えば、ダウンリンクフローハンドリング）に関連する埋め込まれたコンテキスト情報を含むフローベースのＩＰｖ６アドレスを割り当てられてよい。これにより、ゲートウェイルータ及びアクセスポイントにおいてパケットフローコンテキストを格納する必要性が除去されるであろう。

ＦＨが埋め込まれたＩＰｖ６アドレスは、市販の、容易に入手可能なルータによって切り替え／処理され得る。このことは、特殊なルーティングプロトコル及びパケット転送エンジンを配置する必要性を除去してよい。予め定義されたサービス機能チェーンを介してフローを転送する、トラフィックエンジニアリングされた経路でフローを転送する、又は、転送テーブルエントリを集約して、同様のＱｏＳ要件でフローをハンドリングするために、標準的なルータ転送メカニズム（例えば、最長プレフィックスマッチ）が使用されてよい。パケットフローは、ネットワーク事業者によって使用されるポリシに応じてルーティングされ得る。

いくつかのシナリオでは、フローベースのアドレスのルーティングプレフィックスは、ローカルネットワーク内でのルーティングに使用されてよい領域プレフィックスを含んでよい。例えば、図６に例示されるように、領域プレフィックスは、フローベースのアドレスの上位６４ビット内の（６４−ｍ）ビットで構成されてよい。いくつかの場合において、領域プレフィックスは、ネットワークの異なる領域／ドメインにおいて、同一のフローハンドルを使用することを可能にしてよい。

いくつか例では、デバイスはまた、新たなパケットフローを識別及び分類するための支援を提供してよい。例えば、デバイスは、そのアプリケーションのうち１つが新たなフローを開始したときはいつも、新たなパケットフローインジケーション（ＮＰＦＩ）をネットワークに提供してよい。ＮＰＦＩは、ＩＰｖ６パケットヘッダに（例えば、フローラベル又はトラフィッククラスフィールドに）含まれてよい、若しくは、ＩＰｖ６送信元アドレスの予約値として符号化されてよい、又は、ＮＰＦＩは、無線アクセスベアラを通じて（例えば、ＭＡＣ制御要素において）シグナリングされてよい。

パケットを送信する前、デバイスは、ＩＰｖ６パケットヘッダの送信元アドレスフィールドの中にフローハンドルを構築及び挿入するよう、ネットワークによって命令されてよい。一例では、無線デバイス（ＷＤ）への命令は、無線リソース制御（ＲＲＣ）シグナリングを介してフローごとに判断される。このシナリオでは、無線デバイスは、新たなパケットフローが開始されていると判断したときはいつも、ＲＲＣ要求をサービングアクセスポイントに送信する。ＷＤによって提供される、又はＡＰによって導出される情報に基づいて、適切なフローハンドルがネットワークによって構築され、ＲＲＣ応答においてＷＤに通信される。

別の例では、命令は、ＲＲＣシグナリングを介してＲＡＢごとに判断される。このシナリオでは、無線デバイスは、新たな無線アクセスベアラがインスタンス化されていると判断したときはいつも、ＲＲＣ要求をサービングアクセスポイントに送信する。ＷＤによって提供される、又はＡＰによって導出される情報に基づいて、適切なフローハンドルを生成するためのテンプレート及びポリシルールが、ＲＲＣ応答においてＷＤに通信される。これらは、ＲＡＢを通じて送信される全てのパケットフローのためにフローハンドラーを生成すべく、ＷＤによって使用される。

更に別の例では、命令は、ＲＲＣシグナリングを介してデバイスごと又はインタフェースごとに判断される。このシナリオでは、アクセスポイントは、適切なフローハンドルを生成するためのテンプレート及びポリシルールを含む無線デバイスにＲＲＣコマンドを送信する。これらは、対応する無線リンクインタフェースを通じてネットワークに送信される全てのパケットフローのためにフローハンドルを生成すべく、ＷＤによって使用される。

更に別の例では、命令は、ＲＲＣシグナリング又はシステム情報ブロック（ＳＩＢ）ブロードキャストを介してＡＰごと又はグループごとに判断される。このシナリオでは、アクセスポイントは、適切なフロー識別子を生成するためのテンプレート及びポリシルールを含んでよい、そのカバレッジエリア内の無線デバイスの選択されたグループに（又は無線デバイスの全てに）ＲＲＣコマンドをマルチキャスト（又はブロードキャスト）する。これらのルールは、そのアクセスポイントを介してネットワークに送信される全てのパケットフローのためにフローハンドルを生成すべく、ターゲットとされた無線デバイスによって使用されてよい。

パケットが、デバイスによって提供されたフローハンドルと共に受信された場合、ネットワークエッジノード（例えば、サービングアクセスポイント）は、ネットワークエッジノードを含むネットワークのトポロジーを反映するルーティングプレフィックス（ＲＰ）と共に、ローカルに導出された情報をフローハンドル（例えば、アクセスポイント識別子、ＲＡＢ識別子）の中に挿入することによって、ＩＰｖ６フローベースの送信元アドレスの構築を完了してよい。

本開示の実施形態は、フローベースのアドレスのネットワーク割り当て解除のための技術を提供する。フローベースのアドレスは、そのアドレスに関連付けられたパケットフローの全てが終了したと見做されたときはいつも、ネットワークノード（例えば、アクセスポイント）によって、非アクティブと示されてよい。パケットフローの終了は、例えば、ＴＣＰヘッダ又はアプリケーションヘッダ（例えば、ＨＴＴＰ、ＲＴＰ）からの１又は複数のフィールドを調べることによって、パケットフローが受信された無線アクセスベアラ（ＲＡＢ）の特性の変化を識別することによって、又は、パケットフローの非アクティブタイマの満了によって、判断されてよい。

いくつかの例では、デバイスはまた、パケットフローの終了を識別するための支援を提供してよい。例えば、デバイスは、そのアプリケーションのうち１つがフローを終了したときはいつも、パケットフロー終了インジケーション（ＰＦＴＩ）をネットワークに提供してよい。ＰＦＴＩは、ＩＰｖ６パケットヘッダに（例えば、フローラベル又はトラフィッククラスフィールドに）含まれてよい、若しくは、ＩＰｖ６送信元アドレスの予約値として符号化されてよい、又は、ＰＦＴＩは、無線アクセスベアラを通じて（例えば、ＭＡＣ制御要素において）シグナリングされてよい。

モバイルＩＰ環境では、いくつかのパケットフローは短命であってよく、完了されてよく、デバイスがその接続ポイントを変更することなく、関連付けられたＩＰアドレスは解放されてよい。しかしながら、モバイルデバイスが、大きなデータオブジェクトの伝達に直面する機会があるかもしれない。これらの例では、データ伝達中における移動型であることの影響は、データオブジェクトを、単一のモノリシックエンティティとしてではなく、一連のより小さなチャンクとして伝達することによって緩和され得る。各チャンクは、各パケットフローがそれ自身のＩＰｖ６アドレスを割り当てられるよう、各チャンクの伝達が異なるパケットフローとして表されるように、別々に伝達され得る。チャンクのダウンロードは、割り当てられたＩＰｖ６アドレスを解放する前に、単一のアクセスポイントのカバレッジ内で短命のフローとして完了され得る。デバイスが移動型である場合、このことは、異なるチャンクが、異なるＩＰｖ６アドレスを使用して、異なる接続ポイントを介して伝達されることを可能にし、パケットフローのハンドオーバの必要性を除去し、ハンドオーバのオーバーヘッドを最小限に抑える。いくつかの例では、パケットフローがアクティブである間にデバイスがその接続ポイントを変更する場合、デバイスは、最初のパケットフローをアボートし、新たな接続ポイントに関連付けられた新たなＩＰｖ６アドレスを有する新たなパケットフローとして開始された新たな要求によって、中断されたチャンクの再送信を要求し得る。特に、ＨＴＴＰ ＧＥＴ要求及びＰＵＴ要求は、チャンクをデータオブジェクト内の一連のバイトと識別するＲＡＮＧＥによって認定され得る。この技術はまた、例えば、ＨＴＴＰでの動的アダプティブストリーミング（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）プロトコルを使用した、大きなビデオファイル及びストリームのダウンロードに適用され得る。

いくつかの状況では、デバイス上で実行されるアプリケーションが散発的に、パケットのショートバーストをリモート対応ノード（ＲＣＮ）と交換してよい。例えば、メールサーバ又はソーシャルネットワークサーバに更新のクエリを行うべく、又は、リモートサーバにアプリケーションステータスの最新情報を提供すべく、この種のバックグラウンドトラフィックが使用されてよい。

ＲＣＮとの交換期間におけるフローベースのアドレスの無線デバイスへの自動割り当ては、モビリティイベント及びそれらの制御シグナリングオーバーヘッドの必要性を除去して、ネットワークにおける転送コンテキストを更新し、アドレス割り当てに関連付けられたシグナリングオーバーヘッドの必要性を除去し、無線ネットワーク内でのトンネルの使用を回避して、その現在の接続ポイントにおいて、応答をＲＣＮからＷＤへ転送し、ネットワークによって維持されなければならないデバイス固有のコンテキストの量を低減してよい。

本開示の態様が、ＭＴＣトラフィック管理のための技術を提供する。フローごとのアドレス割り当ては、マシンタイプ通信デバイス（ＭＴＣＤ）への、及びＭＴＣＤからのトラフィックのハンドリングに関連する多くの態様を単純化する。一例において、ＭＴＣデバイスとは独立しており、かつＭＴＣデバイスに対して透過的な方式で、ＩＰアドレスの遅延結合をＭＴＣデバイスに提供すべく、ネットワークによるフローベースのアドレス割り当てが使用されてよい。これにより、商品であるＭＴＣデバイスの大規模な配置の間のＩＰアドレスのプロビジョニングに関連付けられたオーバーヘッドが回避され、ＭＴＣＤのバッテリ電力が保存されるであろう。

マシンタイプ通信（ＭＴＣ）トラフィックは、ＭＴＣデバイス（ＭＴＣＤ）がリモート対応ノードとパケットのショートバーストを散発的に交換してよいという点でバックグラウンドトラフィックと同一の特性の多くを共有してよい。従って、ユニキャストＭＴＣトラフィックについて、フローベースのアドレス指定を使用する便益は、バックグラウンドトラフィックにフローベースのアドレス指定を使用する便益と同様である。

図１１は、通信デバイス１１００の一実施形態のブロック図を例示している。通信デバイス１１００は、上記１又は複数のデバイス（例えば、無線デバイス、ネットワークノード等）と同等であってよい。通信デバイス１１００は、プロセッサ１１０４、メモリ１１０６、無線インタフェース１１１０、補足インタフェース１１１２、及び有線インタフェース１１１４を含んでよく、これらは図１１に示される通りに配置されてよい（又は、示される通りに配置されなくてよい）。プロセッサ１１０４は、計算及び／又は他の処理関連タスクを実行可能な任意のコンポーネントであってよく、メモリ１１０６は、プロセッサ１１０４のためのプログラミング及び／又は命令を格納可能な任意のコンポーネントであってよい。無線インタフェース１１１０は、通信デバイスが無線信号を使用して通信できるようにする任意のコンポーネント又はコンポーネントの集まりであってよく、例えば、３ＧＰＰロングタームエボリューション（ＬＴＥ）プロトコルを使用して無線アクセスネットワークの無線接続を通じて情報を受信及び／又は送信するために使用されてよい。オプションの補足インタフェース１１１２は、通信デバイスが補足的なプロトコルによってデータを通信する、又は情報を制御することを可能にする任意のコンポーネント又はコンポーネントの集まりであってよい。例えば、補足インタフェース１１１２は、無線フィデリティ（Ｗｉ−Ｆｉ）プロトコル又はブルートゥース（登録商標）プロトコルに従って通信するための補助的な無線インタフェースであってよい。或いは、補足インタフェース１１１２は、例えば、ユニバーサルシリアルバスプロトコルを使用する有線インタフェースであってよい。有線インタフェース１１１４は、任意で通信デバイスに含まれてよく、通信デバイスが、例えば、イーサネット（登録商標）プロトコルを使用して、有線ネットワークを介して、別のデバイスと通信できるようにする任意のコンポーネント又はコンポーネントの集まりを備えてよい。

図１２は、本明細書で開示されたデバイスおよび方法を実装するために使用されてよい処理システム１２００のブロック図である。特定のデバイスが、示されるコンポーネントの全てを、又は、それらのコンポーネントのサブセットのみを利用してよく、統合のレベルはデバイスによって異なっていてよい。更に、デバイスは、複数の処理ユニット、プロセッサ、メモリ、送信機、受信機等といった、コンポーネントの複数の例を含んでよい。処理システム１２００は、スピーカ、マイク、マウス、タッチスクリーン、キーパッド、キーボード、プリンタ、ディスプレイ、及び同様のものなどの１又は複数の入出力デバイス１２１６、１２２４を備えた処理ユニットを含んでよい。処理システム１２００は、中央処理装置（ＣＰＵ）１２０２、メモリ１２１０、大容量ストレージデバイス１２０４、ビデオアダプタ１２１５、及びＩ／Ｏインタフェース１２２１を備え、これら全てはバス１２０６に接続されていてよい。

バス１２０６は、メモリバス若しくはメモリコントローラ、周辺バス、ビデオバス、又は同様のものを含む、任意のタイプのいくつかのバスアーキテクチャのうちの１又は複数であってよい。ＣＰＵ１２０２は、任意のタイプの電子データプロセッサを含んでよい。メモリ１２１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、リードオンリメモリ（ＲＯＭ）、それらの組み合わせ、又は同様のものなどの、任意のタイプの非一時的システムメモリを含んでよい。一実施形態では、メモリ１２１０は、ブートアップ時に使用するためのＲＯＭと、プログラムを実行する間に使用するためのプログラム及びデータの格納用のＤＲＡＭとを含んでよい。

大容量ストレージデバイス１２０４は、データ、プログラム、及び他の情報を格納し、当該データ、プログラム、及び他の情報を、バス１２０６を介してアクセス可能にするよう構成された、任意のタイプの非一時的ストレージデバイスを含んでよい。大容量ストレージデバイス１２０４は、例えば、ソリッドステートドライブ、ハードディスクドライブ、磁気ディスクドライブ、光ディスクドライブ、又は同様のもののうちの１又は複数を含んでよい。

ビデオアダプタ１２１５及びＩ／Ｏインタフェース１２２１はインタフェースを提供して、外部の入出力デバイスを処理システム１２００に接続する。例示されるように、入出力デバイスの例は、ビデオアダプタ１２１５に接続されたディスプレイ１２１６、及び、Ｉ／Ｏインタフェース１２２１に接続されたマウス／キーボード／プリンタ１２２４を含む。他のデバイスが処理システム１２００に接続されてよく、追加の、又はより少ないインタフェース又はインタフェースカードが利用されてよい。例えば、プリンタ１２２４にインタフェースを提供すべく、ユニバーサルシリアルバス（ＵＳＢ）（図示せず）などのシリアルインタフェースが使用されてよい。

処理システム１２００はまた、ノード又は異なるネットワーク１２３０にアクセスすべく、イーサネット（登録商標）ケーブル若しくは同様のものなどの有線リンク、及び／又は、無線リンクを含んでよい、１又は複数のネットワークインタフェース１２０７を備える。ネットワークインタフェース１２０７は、処理システム１２００がネットワーク１２３０を介して遠隔ユニットと通信できるようにする。例えば、ネットワークインタフェース１２０７は、１又は複数の送信機／送信アンテナ、及び、１又は複数の受信機／受信アンテナを介して無線通信を提供してよい。一実施形態では、処理システム１２００は、データ処理と、他の処理ユニット、インターネット、遠隔記憶装置、又は同様のものなどの遠隔デバイスとの通信とのためのローカルエリアネットワーク１２３０又は広域ネットワーク１２３０に接続されている。

本発明は、例示的実施形態に関して説明されてきたが、本説明は、限定的意味で解釈されるように意図されていない。例示的実施形態の様々な変形形態及び組み合わせ、並びに、本発明の他の実施形態が、本説明を参照すれば当業者には明らかであろう。従って、添付の特許請求の範囲は、そのようなあらゆる変形形態又は実施形態を含むことが意図されている。

本発明は、例示的実施形態に関して説明されてきたが、本説明は、限定的意味で解釈されるように意図されていない。例示的実施形態の様々な変形形態及び組み合わせ、並びに、本発明の他の実施形態が、本説明を参照すれば当業者には明らかであろう。従って、添付の特許請求の範囲は、そのようなあらゆる変形形態又は実施形態を含むことが意図されている。

本特許出願は、２０１４年１１月１８日出願の、「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｆｌｏｗ−Ｂａｓｅｄ Ａｄｄｒｅｓｓｉｎｇ ｉｎ ａ Ｍｏｂｉｌｅ Ｅｎｖｉｒｏｎｍｅｎｔ」と題する米国仮出願第６２／０８１，３８３号、及び、２０１５年９月２日出願の、「Ｓｙｓｔｅｍ ａｎｄ ｍｅｔｈｏｄ ｆｏｒ Ｆｌｏｗ−Ｂａｓｅｄ Ａｄｄｒｅｓｓｉｎｇ ｉｎ ａ Ｍｏｂｉｌｅ Ｅｎｖｉｒｏｎｍｅｎｔ」と題する米国特許出願第１４／８４３，２７７号に対する優先権を主張し、その両方の内容が参照によって本明細書に組み込まれる。

本発明は、パケットベースの通信のためのシステム及び方法に関し、特定の実施形態においては、インターネットプロトコル（ＩＰ）を使用したモバイル環境におけるフローベースのアドレス指定のためのシステム及び方法に関する。

パケットベースの通信ネットワークは、異なるトラフィックフローが異なる経路で伝送され得るように、フローベースのパケット転送技術を利用してよい。例えば、同一ネットワークノード間のアップストリームパケットフローとダウンストリームパケットフローとは、様々な理由、例えば、パケット処理要件、利用可能なリンク容量等のために、異なるネットワーク経路で伝送されてよい。フローベースのパケット転送技術は、パケットフローのサービス品質（ＱｏＳ）要件を満たすべく、トラフィックエンジニアリングされた（ＴＥ）経路でパケットフローを転送してよい。加えて、フローベースのパケット転送技術は、トラフィックフローのパケットに対して特殊な処理（例えば、ファイアウォール、暗号化、圧縮）を実行するパケット処理要素又はノードを介してトラフィックフローを転送してよい。

インターネットプロトコルバージョン６（ＩＰｖ６）を使用する従来のパケットベースのネットワークでは、パケットが、パケットを受信するネットワークノードによってどのように処理されるべきかを判断するために、ＩＰパケットヘッダ内のフローラベル及びトラフィッククラスなどの様々なフィールドが使用されてよい。しかしながら、これらのフィールドは、一方向（例えば、ノードＡからノードＢへ）においてのみ重要性を持ち、逆方向（例えば、ノードＢからノードＡへ）に移動するフローの経路及び処理に影響を与えるのには使用され得ない。加えて、これらのフィールドは、パケットの送信元からその宛先への経路上のどこででも変更されてよく、従って、経路の端から端まで全体にわたり保存されなくてよい。

従来のパケットベースのネットワークでは、デバイスは、その接続ポイントを変更したときはいつも、新たなＩＰアドレスを取得しなければならない。このことは、かなりの量のシグナリングオーバーヘッドを招くことがある。加えて、このことは、前のＩＰアドレスに関連付けられた、進行中の現在の何れかのパケットフローを中断させることがある。

デバイスが、そのＩＰアドレスを変更することなく、１つのネットワーク接続ポイントから別のネットワーク接続ポイントに移動してよい従来のモバイル環境では、パケットが、ネットワークのイングレスノードから、デバイスが現在使用しているネットワーク接続ポイントへ転送されることを保証するために、トンネルヘッダなどの追加情報がパケットに付加される必要があるだろう。プロキシモバイルインターネットプロトコルバージョン６（ＰＭＩＰｖ６）を使用するものなどのトンネリング解決手段は、トンネルエンドポイントにおけるトンネルコンテキストの維持を要求し、トンネルエンドポイント間での制御シグナリングを要求し、トンネルパケットオーバーヘッドをもたらし、同一のトンネル内で、特定のデバイス又はデバイスインタフェースにアドレス指定された全てのフローをカプセル化し、特定のデバイス又はデバイスインタフェースにアドレス指定された全てのフローを強制的に、同一のネットワークのイングレス／エグレスノードを介してルーティングされるようにする。いくつかの、これらのプロトコルの変形したものが、異なるトンネル内での異なるパケットフローのカプセル化をサポートするが、これらの解決手段は、割り当てられなければならないトンネルアドレス数と、トンネルエンドポイントによって維持されなければならないコンテキスト情報の量と、トンネルエンドポイント間で交換されなければならないシグナリング量との比例した増加を招く。

従って、モバイル環境におけるパケットの転送に関連付けられたオーバーヘッドを低減しながら、同時に、ＱｏＳとサービス固有の処理要件とを満たすべく、フロー固有のパケット処理を可能にする必要がある。

モバイル環境におけるフローベースのアドレス指定のためのシステム及び方法を説明する本開示の実施形態によって、技術的な利点が概して実現される。

一実施形態に従って、通信ネットワークにおいてパケットフローを通信するための方法が提供される。本例では、当該方法は、第１のフローハンドル（ＦＨ）を、第１のパケットのインターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）アドレスの中に埋め込む段階と、当該第１のパケットを第２のネットワークノードに送信する段階とを備える。第２のネットワークノードは、第１のＦＨに含まれたフロー情報に従って第１のパケットを処理又は転送する。本方法を実行するための装置もまた提供される。

別の実施形態に従って、通信ネットワークを通じて受信されたパケットを処理又は転送するための方法が提供される。本例では、当該方法は、第１のネットワークノードからパケットを受信する段階を備える。フローハンドル（ＦＨ）が、パケットのインターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）アドレスに埋め込まれる。当該方法は、パケットのＩＰｖ６アドレスに埋め込まれたＦＨによって特定されるフロー情報に従ってパケットを処理又は転送する方法を更に備える。本方法を実行するための装置もまた提供される。

更に別の実施形態に従って、インターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）ネットワークアドレスを割り当てるための方法が提供される。本例では、当該方法は、デバイスに関連付けられた第１のパケットフローと、デバイスに関連付けられた第２のパケットフローとが開始されたと判断する段階と、利用可能なアドレスのプールから、第１のＩＰｖ６アドレスを第１のパケットフローに、及び第２のＩＰｖ６アドレスを第２のパケットフローに割り当てる段階とを備える。第１のＩＰｖ６アドレスは、第２のＩＰｖ６アドレスとは異なる。当該方法は、第１のＩＰｖ６アドレスを、第１のパケットフローに関連付けられた少なくとも１つのパケットのアドレスフィールドの中に挿入する段階と、第２のＩＰｖ６アドレスを、第２のパケットフローに関連付けられた少なくとも１つのパケットのアドレスフィールドの中に挿入する段階と、第１のパケットフロー及び第２のパケットフローに関連付けられたパケットをネットワークを通じて通信する段階とを更に備える。本方法を実行するための装置もまた提供される。

本発明及びその利点のより完全な理解を期して、ここで、次の添付の図面と併せて以下の説明を参照する。

一実施形態の無線ネットワークの図を例示する。

従来のインターネットプロトコルバージョン６（ＩＰｖ６）アドレス及びパケットヘッダの図を例示する。

一実施形態のフローハンドル（ＦＨ）の図を例示する。

送信元ノードにおけるフローベースのアドレス指定のための、一実施形態の方法のフローチャートを例示する。

トランジットネットワークノードにおけるフローベースのアドレス指定のための、一実施形態の方法のフローチャートを例示する。

モバイルデバイスを含む、一実施形態のフローベースのイングレス及びエグレス選択スキームの図を例示する。 モバイルデバイスを含む、一実施形態のフローベースのイングレス及びエグレス選択スキームの図を例示する。

一実施形態のフローベースの経路選択スキームの図を例示する。

一実施形態の、指定経路でのパケット転送スキームの図を例示する。

一実施形態のＱｏＳベースのフロー集約スキームの図を例示する。

ＩＰｖ６アドレスにおいてフローハンドリング命令をシグナリングするための、一実施形態の方法１０００のフローチャートを例示する。

一実施形態の通信デバイスの図を例示する。

一実施形態のコンピューティングプラットフォームの図を例示する。

別途指示されない限り、異なる図面における対応する番号及び記号は概して対応する部分を指す。図は、実施形態の関連する態様を明確に例示するために描かれているのであり、必ずしも縮尺通りに描かれているわけではない。本文献を通して、用語「ＩＰｖ６」及び「ＩＰ」は、同じ意味で使用されてよい。

開示される実施形態の構造、製造、及び使用が以下で詳細に説明される。しかしながら、本発明は、多種多様な特定の文脈において具体化され得る多数の適用可能な発明の概念を提供するということが理解されるべきである。説明される特定の実施形態は、本発明を作成及び使用するための特定のやり方を例示しているに過ぎず、本発明の範囲を限定しない。

インターネットプロトコルバージョン６（ＩＰｖ６）ネットワークでは、フローベースのパケット転送は概して、パケットのインターネットプロトコル（ＩＰ）ヘッダにフローハンドリング情報を付加することによって実現される。フローハンドリング情報は、フローラベル又は他の情報（例えば、ネクストホップアドレスのリスト、サービス品質（ＱｏＳ）要件）を含んでよく、中間ノードが、適切な経路、例えば、フローラベルによって特定された経路、指定されたネクストホップへの経路等、でパケットを転送することを保証してよい。モバイルＩＰ環境では、パケットが、デバイスによって現在使用されているネットワーク接続ポイントに転送されることを保証すべく、ＩＰパケットに、プロキシモバイルＩＰｖ６プロトコルによって使用されるものなどのトンネルヘッダが付加されることが多い。同様に、特定のサービス機能経路でパケットを向かわせるべく、ネットワークサービスヘッダをＩＰパケットへ付加することをサービス機能チェイニングが要求してよい。残念ながら、フローハンドリング情報のパケットへの付加は、更なるオーバーヘッドをトラフィックフローに追加し、更なるシグナリングを要求してフローハンドリング情報を調整することがあり、このことは、パケットのペイロードを伝送するために要求されるネットワークリソース量を増やす。従って、ＩＰｖ６ネットワークにおけるフローベースの転送を実現するために要求されるオーバーヘッド量を低減するための技術が望まれる。

本開示の態様は、パケットのＩＰｖ６アドレス部分にフローハンドル（ＦＨ）を埋め込み、フローベースのパケット転送において、経路選択をサポートするために必要とされるオーバーヘッドを低減する。より具体的には、ＦＨは、標準的なＩＰｖ６アドレス内のインタフェース識別子を置換してよく、その結果、ＩＰｖ６パケット自体に更なるオーバーヘッドを少しも追加しなくてよい。一実施形態では、ＦＨは、パケットのＩＰｖ６アドレスの最下位ビット（例えば、右端の６４ビット）部分に埋め込まれてよい。パケットのＩＰｖ６アドレス部分のＦＨは、パケット処理に使用される情報を提供してよい。ネットワークノードが、ＦＨを含むパケットを受信した場合、ネットワークノードは、（例えば、最長プレフィックスマッチ又はプロトコル忘却型フォワーディング機能などの従来のルート選択機能を使用して、）パケットのＩＰｖ６アドレス部分に埋め込まれたＦＨによって特定される情報に基づいて、経路又はネクストホップアドレスを識別してよく、次に、識別された経路で、又は、識別されたネクストホップにパケットを転送してよい。有利なことに、ＩＰｖ６アドレスに埋め込まれたＦＨによって特定される情報は、経路又はネクストホップを選択すべく、従来のルート選択機能／アルゴリズム（例えば、最長プレフィックスマッチ、プロトコル忘却型フォワーディング機能等）と併せて使用されてよい。このように、ＩＰｖ６アドレスに埋め込まれたＦＨは、レガシデバイスで使用されるルート選択機能／アルゴリズムと後方互換性があってよく、それにより、既存のルータ及び他のネットワークノードを変更又は再構成する必要なく、ＦＨが埋め込まれたＩＰｖ６アドレスを使用して、フローベースの転送を実装することが可能になる。加えて、ＦＨは、パケットに関連付けられたサービス品質（ＱｏＳ）要件を識別してよく、ルート選択機能は、（例えば、最長プレフィックスマッチ又はプロトコル忘却型フォワーディング機能などのルート選択機能を使用して、）ＱｏＳ要件を満たすことが可能な経路を識別してよい。ＦＨは、予め定義されたサービス機能チェーン（ＳＦＣ）に沿ってパケットを転送するために使用されるＳＦＣ ＩＤ、ネットワークアクセスポイント（ＡＰ）を識別するＡＰ ＩＤ、無線アクセスリンク接続を識別する無線ベアラＩＤ、予め定義された経路でパケットを転送するために使用される経路ＩＤ、パケットのサービス品質（ＱｏＳ）要件を識別するＱｏＳコードポイント、及び／又は、エンドノード（例えば、無線デバイス）を識別するデバイスＩＤを備えてよい。多くの場合、適切な経路又はネクストホップアドレスを識別すべく、最長プレフィックスマッチ又はプロトコル忘却型フォワーディング機能などのルート選択機能が有利に使用されてよい。これらの詳細、及び他の詳細が、以下でより詳しく説明されている。

ＦＨは、ネットワークノードによって構築されてよい、又は、ネットワークから受信された命令に基づいてデバイスによって構築されてよい。例えば、無線通信ネットワークにおいて、ネットワークノード（例えばＡＰ）は、パケットのＩＰｖ６アドレス部分の中にＦＨを構築及び挿入するよう無線デバイス（ＷＤ）に命令する命令コマンドを送信してよい。一例では、ＡＰが、デバイス固有の無線リソース制御（ＲＲＣ）シグナリングメッセージを使用して、命令コマンドをＷＤに送信してよい。別の例では、拡張ノードＢ（ｅＮＢ）（例えば、３ＧＰＰロングタームエボリューション（ＬＴＥ）システムにおけるＡＰ）が、システム情報ブロック（ＳＩＢ）を使用して、命令コマンドを１又は複数のＷＤにブロードキャストしてよい。そのような例において、命令コマンドは、パケットのＩＰｖ６送信元アドレス部分に埋め込まれたＦＨに含まれるべき情報を示すテンプレート及びポリシルールを含んでよい。

図１は、データを通信するための無線ネットワーク１００を例示する。無線ネットワーク１００は、カバレッジエリア１０１を有するアクセスポイント（ＡＰ）１１０と、複数の無線デバイス１２０と、バックホールネットワーク１３０とを含む。ＡＰ１１０は、とりわけ、無線デバイス１２０とのアップリンク（破線）接続、及び／又はダウンリンク（点線）接続を確立することによって、無線アクセスを提供可能な、基地局、拡張ノードＢ（ｅＮＢ）、フェムトセル、及び他の無線対応デバイスなどの任意のコンポーネントを含んでよい。無線デバイス１２０は、ＡＰ１１０との無線接続を確立可能な、移動局（ＳＴＡ）、マシンタイプ通信（ＭＴＣ）デバイス、ユーザ機器（ＵＥ）、又は他の無線対応デバイスなどの任意のコンポーネントを備えてよい。バックホールネットワーク１３０は、データがＡＰ１１０とリモートノードとの間で交換されることを可能にする任意のコンポーネント又はコンポーネントの集まりであってよい。いくつかの実施形態では、そのようなネットワークが複数あってよい、及び／又は、ネットワークは、リレー、低電力ノード等といった他の様々な無線デバイスを備えてよい。

図２は、従来のインターネットプロトコルバージョン６（ＩＰｖ６）アドレス２００の図を例示する。示されるように、１２８ビットのＩＰｖ６アドレス２００は、ルーティングプレフィックス２０５及びインタフェース識別子２２０を備える。ルーティングプレフィックス２０５は、ＩＰｖ６アドレスの最上位ビットに位置し、グローバルプレフィックス２１０及びサブネットプレフィックス２１５を含む。グローバルプレフィックス２１０は、インターネット全体内でパケットをルーティングするために使用され、一方、サブネットプレフィックス２１５は、ローカルネットワーク内でパケットをルーティングするために使用される。ＩＰｖ６アドレスの最下位ビットに位置するインタフェース識別子２２０は、エンドノードにおけるインタフェースを識別する。一般的に、ルーティングプレフィックス２０５は、アドレスの最上位６４ビットを占有し、インタフェース識別子２２０は、アドレスの最下位６４ビットを占有する。しかしながら、１２８ビットのアドレスの他の構成もまた可能である。ＩＰｖ６アドレス２００は、ＩＰｖ６ヘッダ２９０内の送信元アドレス２９１又は宛先アドレス２９２であってよい。パケットはインターネット全体をトラバースするように説明されてよいが、パケットの宛先は、パケットが受信されるネットワークセグメントの外部でなくてもよいことが理解されるべきである。例えば、無線通信ネットワークでは、宛先ノードは、無線アクセスネットワークの一部であってよい。

図３は、一実施形態の、フローハンドル（ＦＨ）３０１を保持するＩＰｖ６アドレス３００の図を例示する。示されるように、ＦＨ３０１は、ＩＰｖ６アドレス３００の最下位ビットに埋め込まれている。ＦＨ３０１は、ＩＰｖ６アドレス３００が付加されるパケットを処理するための命令を特定するコンテキスト情報を含んでよい。従って、ＦＨ３０１は、パケットを処理又は転送するために使用されるフローハンドリング情報をネットワークノードに伝達する。例えば、ネットワークノードが、ＩＰｖ６アドレス３００によってカプセル化されたパケットを受信した場合、ネットワークノードは、パケットのＩＰｖ６アドレス３００に埋め込まれたＦＨ３０１によって特定される情報（例えば，経路識別子（ＩＤ），ＱｏＳ要件等）に基づいて、経路又はネクストホップを識別し、次に、識別された経路で、又は識別されたネクストホップにパケットを処理又は転送する。

ＦＨ３０１は、論理フロー識別子（ＩＤ）３１２、サービス機能チェーン（ＳＦＣ）識別子（ＩＤ）３２２、アクセスポイント（ＡＰ）識別子（ＩＤ）３２３、無線ベアラ識別子（ＩＤ）３２４、経路識別子（ＩＤ）３３２、ＱｏＳコードポイント３３３、無線デバイス（ＷＤ）識別子（ＩＤ）３４３、又はそれらの組み合わせを含んでよい。論理フローＩＤ３１２は、特定の一連のパケットを識別する。ＳＦＣ ＩＤ３２２は、予め定義されたサービス機能チェーンを識別する。ＡＰ ＩＤ３２３は、ネットワークアクセスポイントを識別する。無線ベアラＩＤ３２４は、無線アクセスリンク接続を識別する。経路ＩＤ３３２は、ネットワークを通る予め定義された経路を識別する。ＱｏＳコードポイント３３３は、パケットのＱｏＳ要件を識別する。ＷＤ ＩＤ３４３は、無線デバイス及び／又はエンドノードを識別する。

ＦＨ３０１は、様々な異なるタイプの情報を保持する。情報のタイプは、ＦＨ３０１のクラス及び／又はフォーマットに依存してよい。一例では、ＦＨ３０１が第１のフォーマット（例えば、クラスＡ、フォーマット０）を有する場合、ＦＨ３０１は、フォーマットフィールド３１１及び論理フローＩＤフィールド３１２を保持する。別の例では、ＦＨ３０１が、第２のフォーマット（例えば、クラスＢ、フォーマットｍ）を有する場合、ＦＨ３０１は、フォーマットフィールド３２１、ＳＦＣ ＩＤフィールド３２２、ＡＰ ＩＤフィールド３２３、及び無線ベアラＩＤフィールド３２４を保持する。更に別の例では、ＦＨ３０１が、第３のフォーマット（例えば、クラスＢ、フォーマットｎ）を有する場合、ＦＨ３０１は、フォーマットフィールド３３１、経路ＩＤフィールド３３２、ＱｏＳコードポイントフィールド３３３、及び無線ベアラＩＤフィールド３３４を保持する。更に別の例では、ＦＨ３０１が、第４のフォーマット（例えば、クラスＤ、フォーマットｓ）を有する場合、ＦＨ３０１は、フォーマットフィールド３４１、ＡＰ ＩＤフィールド３４２、及びＷＤ ＩＤフィールド３４３を保持する。更に別の例では、ＦＨ３０１が、第５のフォーマット（例えば、クラスＦ、フォーマットｔ）を有する場合、ＦＨ３０１は、フォーマットフィールド３５１、及びＡＰ ＩＤフィールド３５２を保持する。フォーマットフィールド３１１、３２１、３３１、３４１、３５１は、ＦＨ３０１のフォーマットを識別する値（例えば、０、１ｙｙｙｙｙｙｙｙ、１１１１１１１１・・・１ｙｙｙｙｙｙｙｙ等、ここで、ｙは、フォーマット識別子のビットである）を含んでよい。異なるフォーマットは、様々な異なるタイプの情報を保持してよい。

図４は、パケットフロー送信が開始された場合に送信元ノードによって実行されるであろう、通信ネットワークにおけるフローベースのアドレス指定のための一実施形態の方法４００のフローチャートを例示する。

示されるように、方法４００は、段階４１０から開始する。段階４１０において、送信元ノードは、パケットフローに対して行われるべき処理を判断する。送信元ノードは、ネットワークノード（例えば、ＡＰ）、デバイス、又はネットワークノードからの命令を受けて動作するデバイスであってよい。送信元ノードは、ＩＰヘッダからの１又は複数のフィールド、伝送ヘッダ（例えば、ＴＣＰ、ＵＤＰ）、又はアプリケーションヘッダ（例えば、ＨＴＴＰ、ＲＴＰ）と、デバイスのタイプ（例えば、移動又は固定）と、デバイスのクラス（例えば、マシンタイプ通信デバイス又はヒューマンタイプ通信デバイス）と、デバイス上のアプリケーションから受信された情報と、トラフィック管理（ＴＭ）エンティティから受信された情報と、デバイスによって使用されるアクセスリンクのタイプ（例えば、有線又は無線）と、デバイスによって使用されるアクセスリンク（例えば、無線アクセスベアラチャネル）（の特性）とのうちの１又は複数に基づいて処理を判断してよい。段階４２０において、送信元ノードは、フローハンドルにおいて伝達される必要がある情報に基づいてフローハンドルの適切なフォーマットを判断して、パケットフローに対して行われるべき処理を反映する。当該情報は、特定の一連のパケットを識別するパケットフローＩＤ、予め定義されたサービス機能チェーン（ＳＦＣ）に沿ってパケットを転送するためのＳＦＣ ＩＤ、ネットワークアクセスポイント（ＡＰ）を識別するＡＰ ＩＤ、無線アクセスリンク接続を識別する無線アクセスベアラＩＤ、予め定義された経路でパケットを転送するための経路ＩＤ、パケットのサービス品質（ＱｏＳ）要件を識別するＱｏＳコードポイント、及び／又は、エンドノードを識別するデバイスＩＤを備えてよい。一実施形態では、ネットワークエッジノード（例えば、ＡＰ）が、パケットをＡＰに送信する前にパケットのＩＰｖ６アドレス部分にＦＨを埋め込むようデバイスに命令する。そのような実施形態では、ＡＰは、パケットのＩＰｖ６アドレス部分にＦＨを埋め込むための、選択されたフローハンドルフォーマット及びポリシルールを含んでよい命令コマンドをデバイスに送信する。無線ネットワークでは、当該命令は、例えばシステム情報ブロック（ＳＩＢ）において、専用無線リソース制御（ＲＲＣ）シグナリングメッセージ又はブロードキャストの何れかを使用して、無線デバイス（ＷＤ）に送信されてよい。当該命令は、フローごとに（例えば、新たなパケットフローが開始されたときはいつも）、又は、無線アクセスベアラ（ＲＡＢ）ごとに（例えば、特定のＲＡＢを通じて送信される全てのパケットフローに）、デバイスごと又はインタフェースごとに（例えば、そのデバイスによって、又は、特定のデバイスインタフェースを通じて送信される全てのパケットフローに）、又は、グループごとに（例えば、特定のグループのデバイスによって送信される全てのパケットフローに）提供されてよい。段階４３０において、送信元ノードは、処理情報を、選択されたフローハンドルの対応するフィールドの中に埋め込む。段階４４０において、送信元ノードは、フローハンドルを、ＩＰパケットヘッダのアドレス部分の中に挿入する。その後、段階４５０において、送信元ノードは、埋め込まれたフローハンドルを有するパケットを次のネットワークノードに転送する。ＦＨは、要求されるフローハンドリング処理に従ってパケットを処理又は転送するための情報を、次のネットワークノードに提供してよい。本開示の大半は、ＦＨが埋め込まれたＩＰｖ６アドレスを、ＩＰｖ６ヘッダの送信元アドレスフィールドの中に挿入することについて説明しているが、ＦＨが埋め込まれたＩＰｖ６アドレスをＩＰｖ６ヘッダの宛先アドレスフィールドの中に挿入する場合に、本発明の概念の多くが同様に適用され得ることが理解されるべきである。

図５は、別のネットワークノードからパケットを受信する場合にトランジットノードによって実行されるであろう、通信ネットワークノードにおけるフローベースのアドレス指定のための、一実施形態の方法５００のフローチャートを例示する。

示されるように、方法５００は段階５１０から開始する。段階５１０において、トランジットノードは、別のネットワークノードからパケットを受信する。段階５２０において、トランジットノードは、パケットのインターネットプロトコル（ＩＰ）アドレス部分からフローハンドルを取り出す。段階５３０において、トランジットノードは、フローハンドルのフォーマットを判断する。段階５４０において、フローハンドルのフォーマットに基づいて、トランジットノードは、パケットに提供されるべき処理を特定するハンドルからフロー処理情報を取り出す。その後、方法５００は段階５５０に進む。段階５５０において、トランジットノードは、ＦＨによって特定される情報に従って、パケットを処理又は転送する。一実施形態では、トランジットノードは、パケットのＩＰアドレス部分に埋め込まれたＦＨによって特定される情報に関連付けられた経路又はネクストホップを識別し、次に、識別された経路で、又は、識別されたネクストホップにパケットを転送する。別の実施形態では、トランジットノードは、ＦＨに関連付けられたサービス品質（ＱｏＳ）要件を識別し、次に、ＱｏＳ要件を満たすことが可能な経路でパケットを転送する。更に別の実施形態では、トランジットノードは、ＦＨに関連付けられた処理タスク（例えば、フィルタリング、ファイアウォール等）を定義するサービス機能チェーンを識別し、次に、パケットに対して処理タスクを実行する、又は、そうでなければ、処理タスクを実行可能な次のネットワークノードにパケットを転送する。

いくつかの実施形態では、ネットワークリソース及び／又は無線リソースの利用可能性、並びにネットワーク事業者のポリシに従って、個々のトラフィックフローの特性に基づいて、パケットフローのためのネットワークイングレスポイント及びネットワークエグレスポイントが判断されてよい。例えば、無線エッジノード（例えば、ＡＰ）を通過する各トラフィックフローは、１又は複数の基準、例えば、ＱｏＳ要件、利用可能な無線リソース、利用可能なバックホールリソース等に基づいて、無線アクセス技術（例えば、ロングタームエボリューション（ＬＴＥ）、米国電気電子学会（ＩＥＥＥ）８０２．１１等）と、協同する送信／受信ポイント（例えば、無線アクセスネットワーク送信ポイント（ＲＡＮ‐ＴＰ）及び／又はＲＡＮ受信ポイント（ＲＡＮ‐ＲＰ））のセットとに関連付けられてよい。或いは、ネットワークエッジノード（例えば、ボーダーゲートウェイ）を通過する各トラフィックフローは、移動体通信事業者のコスト及び／又はセキュリティポリシに基づいて、リモート対応ノード（ＲＣＮ）への／からのルート、及び／又は、エッジ処理機能（例えば、ファイアウォール、ネットワークアドレス変換（ＮＡＴ）、侵入検知）のセットに関連付けられてよい。図６Ａは、フローベースのイングレス及びエグレス選択スキーム６０１を例示する。図中、フローＡ、フローＢ、及びフローＣは、同時に無線デバイス６１０に関連付けられている。フローＡは、ＲＡＮ送信ポイント６２２及び６２４、並びにボーダーゲートウェイ６３２を介して転送され、同時に、フローＢは、ＲＡＮ送信ポイント６２４及び６２６、並びにボーダーゲートウェイ６３６を介して転送され、フローＣは、ＲＡＮ送信ポイント６２８及びボーダーゲートウェイ６３６を介して転送される。一実施形態では、ＲＡＮ送信ポイント６２２、６２４、６２６は第１のアクセスポイントに関連付けられており、ＲＡＮ送信ポイント６２８は、第２のアクセスポイントに関連付けられている。いくつかの実施形態では、無線デバイス６１０は、無線ネットワークの異なる位置に移動してよい。無線デバイス６１０のこの位置変更は、いくつかのフロー（例えば、フローＡ及びフローＢ）の経路に、他のフロー（例えば、フローＣ）の経路に影響を与えることなく、影響を与えてよい。図６Ｂは、無線デバイス６１０の位置変更の後の、フローベースのイングレス及びエグレス選択スキーム６０２を例示する。示されるように、この変更はフローＡ及びフローＢを異なる経路で流れさせ、フローＡが（ＲＡＮ‐ＴＰ６２４ではなく）ＲＡＮ‐ＴＰ６２６を介してルーティングされ、フローＢが、（ＲＡＮ‐ＴＰ６２４及び６２６ではなく）ＡＰ６２８を介してルーティングされている。フローＣの経路は変化しない。

いくつかの実施形態では、パケットフローのパケット転送経路及び処理スキームは、個々のパケットフローの特性（例えば、ＱｏＳ要件）、ネットワークリソース及び無線リソースの利用可能性、及び／又は、適用可能なサービス機能チェーン（ＳＦＣ）に基づいて判断されてよい。図７は、フローベースの経路選択スキーム７００を例示する。リモート対応ノード（ＲＣＮ）７５１からの第１のダウンリンクパケットフローが、ボーダーゲートウェイ７３０からのルータ７４１及び７４２を通る経路で、サービングアクセスポイント７２０を介して無線デバイス７１０に転送されてよい。ＲＣＮ（ＲＣＮ）７５２からの第２のダウンリンクパケットフローが、ボーダーゲートウェイ７３０からのルータ７４３及び７４４を通る異なる経路で、サービングＡＰ７２０を介して無線デバイス７１０に転送されてよい。ＲＣＮ７５１及び７５２は、同一のプラットフォーム上で実装されてよい。一方で、異なるＩＰアドレスが異なるパケットフローに割り当てられるので、各フローは個別に処理される。パケットフロー経路が、一方向スキーム又は双方向スキームの何れかによってハンドリングされてよい。例えば、双方向スキームでは、アップリンク方向のパケットフローは、ダウンリンク方向のパケットフローと同一の経路をたどり、一方、一方向スキームでは、アップリンク方向のパケットフロー（例えば、ＲＣＮに送信される要求）は、ダウンリンク方向のパケットフロー（例えば、ＲＣＮから受信された応答）とは異なる経路をたどってよく、異なる処理スキームに従ってハンドリングされてよい。パケットフローがたどる経路を判断するためにルータによって使用される転送情報ベース（ＦＩＢ）が、集中型のトラフィック管理（ＴＭ）エンティティによってポピュレートされてよい、又は、従来の分散型のルーティングプロトコルを使用してルータ間で交換された情報の結果であってよい。

いくつかの実施形態では、異なる可能性のあるインターネットプロトコルアドレスを、モバイルデバイスによって開始された各パケットフローに割り当てることによって、局所的なフローベースのモビリティ管理スキームが提供されてよい。パケットフローは、ウェブ閲覧行動では、１フロー当たり平均３０‐３５パケットの短命である傾向がある。その結果、パケットフローが完了されてよく、関連付けられたＩＰアドレスが解放されてよく、その後、モバイルデバイスはその接続ポイントをネットワークに変更する。これらの例では、プロキシモバイルＩＰｖ６などのプロトコルに関連付けられたトンネリングオーバーヘッド及び制御シグナリングオーバーヘッドを招くことなく、モバイルデバイスにサービス提供するネットワーク接続ポイントにダウンリンクフローが直接転送され得る。モバイルデバイスは、モバイルデバイスがアクティブなパケットフローを有さない非アクティブ期間又は休止期間の間に接続ポイントを変更してよく、これにより、パケットフロー又はＩＰアドレスの維持に関連する何れのアクションの必要性も除去されてよい。モバイル無線デバイス（ＷＤ）によって使用されてよいＲＡＮ送信ポイント及び／又はＲＡＮ受信ポイントは、パケットフローの生存期間中に変更されてよい。そのような変更は、モバイルＷＤの移動の結果、無線リンク環境の変化（例えば、増大する干渉）、及び／又は、ネットワークインフラストラクチャ条件の変化（例えば、バックホール輻輳）であってよい。いくつかの例では、それらの変化は、モバイルＷＤから発せられたパケットフローのサブセットのみに影響を与えてよい。例えば、図６Ｂに例示されるように、変化が、いくつかのトラフィックフロー（例えば、フローＡ及びフローＢ）の経路に、他のトラフィックフロー（例えば、フローＣ）の経路には影響を与えることなく、影響を与えてよい。変化が起こった場合、影響を受けたパケットフローは、隣接ＡＰに向け直されてよい。従って、モビリティ管理アクションは局在化されてよく、処理負荷は、ネットワークの無線エッジに、又はその近くに位置するネットワークノードにわたって分散されてよい。その結果、レイテンシ及びネットワークシグナリングオーバーヘッドが低減されてよく、特殊大容量モビリティアウェア（ｍｏｂｉｌｉｔｙ−ａｗａｒｅ）ルータ（例えば、コアネットワークにおけるサービングゲートウェイ（ＳＧＷ））の必要性が除去されてよい。

いくつかの実施形態では、ダウンリンクフロー及びアップリンクフローのパケットは、最短経路又は最小コスト経路の何れかで、ベストエフォート方式で転送されてよい。他の実施形態において、ダウンリンクフロー及び／又はアップリンクフローのパケットが、パケットのＱｏＳ要件に基づいて、又は、ネットワークトラフィックが複数の経路にわたって平衡を保たれることを保証すべく、予め定められた経路で転送されるべきであると、トラフィック管理（ＴＭ）エンティティが判断してよい。例えば、特定の経路は、指定エンドポイント（例えば、サービングＡＰ）へのベストエフォート経路、ＴＭエンティティによって識別されたトラフィックエンジニアリングされた経路、及び／又は、パケットのための一連のサービス機能を識別するサービス機能経路であってよい。図８は、指定経路でパケットを通信するための、一実施形態のパケット転送スキーム８００の図を例示する。無線リンクにわたるシグナリングオーバーヘッドを最小限に抑えるべく、ネットワークノード（例えば、サービングＡＰ）が、割り当てられたフローアドレスを、ＷＤから受信されたパケットのヘッダの中に挿入してよい。パケット転送スキーム８００の段階１において、ＷＤは、ＷＤとＡＰとの間の無線リンク上で定義された無線アクセスベアラを通じてアップリンクパケットを送信する。ＷＤは、パケットフローに関連付けられた送信元ＴＣＰ／ＵＤＰポート（例えば、ポート_Ａ）と共に、宛先アドレス（例えば、ＩＰ_ＲＣＮ）及びＴＣＰ／ＵＤＰポートをパケットヘッダの中に挿入してよい。一例では、ＷＤは、無線リンクを通じてパケットを送信する前に、指定されていない（例えば、ヌル）送信元ＩＰアドレスをパケットヘッダの中に挿入してよい。別の例では、ＷＤは、無線リンクを通じてパケットを送信する前に、リンクローカル送信元ＩＰアドレスをパケットヘッダの中に挿入してよい。

無線エッジネットワークノード（例えば、サービングＡＰ）がアップリンクパケットを受信した場合、無線エッジネットワークノードは、フローベースのアドレスをパケットに割り当ててよい。フローベースのアドレスは、パケットヘッダ内の送信元アドレスのＦＨ部分の中に埋め込まれてよい。フローベースのアドレスは、無線エッジノードによって自律的に生成されてよい。或いは、フローベースのアドレスは、ＴＭエンティティから受信された命令に基づいて生成されてよい。送信元アドレスは、（複数の）サービングＡＰを含む無線ネットワークのトポロジーを反映するルーティングプレフィックス（ＲＰ）を含んでよい。図８によって描写された例において明示されるように、送信元アドレスのＦＨ内のコンテキスト情報は、ダウンリンクパケットフローに関連付けられた経路と、無線アクセスベアラ（ＲＡＢ）とを識別してよい。例えば、ＦＨは、トラフィックエンジニアリングされた経路若しくはサービス機能経路、ＲＡＢ、ＱｏＳ要件、又はそれらの組み合わせを識別してよい。別の例では、ＦＨは、サービングＡＰへのベストエフォート経路とＲＡＢとを識別してよい。ＲＡＢ ＩＤが、パケットが受信されたアップリンク無線ベアラを識別してよい。或いは、ＲＡＢ ＩＤは、対応するダウンリンク無線ベアラに関連付けられてよい。当該対応するダウンリンク無線ベアラは、あらゆる戻りのダウンリンクパケットをＷＤに伝送するために使用されてよい。パケット転送スキーム８００の段階２において、ＡＰは、ＩＰパケットルーティングスキーム／機能、例えば、最長プレフィックスマッチ、プロトコル忘却型フォワーディング機能等を使用して、アップリンクパケットをエグレスボーダーゲートウェイに転送してよい。いくつかの状況では、各ルータが、その経路選択処理中に送信元アドレスに埋め込まれた経路ＩＤを含む場合、アップリンクトラフィックエンジニアリングされた経路が選択されてよい。パケット転送スキーム８００の段階３において、ボーダーゲートウェイは、ＩＰパケットルーティングスキームに従って、（例えば、インターネット全体を介して）パケットをＲＣＮに転送してよい。一実施形態では、ボーダーゲートウェイは、パケットの送信元アドレスに含まれたローカルなルーティングプレフィックスを、ネットワークにおける、例えば、インターネット全体におけるボーダーゲートウェイの位置を反映するグローバルなルーティングプレフィックスと置換する。

パケット転送スキーム８００の段階４において、ＲＣＮは、アップリンクパケットの送信元アドレス及び送信元ＴＣＰ／ＵＤＰポートをそれぞれ、ダウンリンクパケットのダウンリンクパケットヘッダの宛先アドレス及びポート部分の中に埋め込むことによって、ダウンリンクパケットを生成してよい。次にＲＣＮは、ダウンリンクパケットヘッダ内のルーティングプレフィックスに基づいて、ＩＰパケットルーティングスキームを使用して、インターネット全体を介してダウンリンクパケットをイングレスボーダーゲートウェイに転送してよい。特に、ダウンリンクパケットを受信するイングレスボーダーゲートウェイは、アップリンクパケットを送信するエグレスボーダーゲートウェイと同一でなくてよい。なぜなら、ルーティングの決定は、インターネット全体、及び／又は無線インフラストラクチャネットワーク内で異なっていてよいからである。ダウンリンク宛先ＩＰアドレスのＦＨに含まれたフロー情報は、アップリンクフロー及びダウンリンクフローが、異なるボーダーゲートウェイを介してルーティングされることを可能にするために、及び、ボーダーゲートウェイ間でコンテキスト情報を交換する必要性を除去するために使用されてよい。パケット転送スキーム８００の段階５において、例えば、フローベースの宛先アドレスに埋め込まれた（ローカルな）ルーティングプレフィックス、経路ＩＤ、ＱｏＳコードポイント、又はそれらの組み合わせを含む最長プレフィックスマッチに基づいて、ルート選択機能／アルゴリズムを使用して、イングレスボーダーゲートウェイは、無線インフラストラクチャネットワークを介してダウンリンクパケットをサービングＡＰにルーティングする。従来のルーティングプロトコルを使用してルータによって交換された情報によって、又は、集中型のＴＭエンティティによって、無線インフラストラクチャネットワークのルータにより使用される転送情報ベース（ＦＩＢ）がポピュレートされてよい。パケット転送スキーム８００の段階６において、サービングＡＰはダウンリンクパケットを受信し、次に、ダウンリンクパケットのフローベースの宛先アドレスに埋め込まれた情報（例えば、ＲＡＢ ＩＤ等）に基づいて、ダウンリンク無線ベアラ及びその関連付けられたコンテキスト情報を判断してよい。ダウンリンク無線ベアラは、次に、パケットをＷＤに配信するために使用されてよい。上述の実施形態のパケット転送スキームは、いくつかの便益を有するであろう。例えば、パケットはトンネルにカプセル化される必要がないので、トンネルオーバーヘッドが除去されてよい。別の例として、ダウンリンクパケットをＡＰに転送するために従来のＩＰルーティングスキームが使用されてよいので、ＡＰとモビリティアンカーポイントとの間で制御シグナリングオーバーヘッドが除去されてよい。更に別の例として、異なるパケットフローは、パケットの宛先アドレスのＦＨに埋め込まれたパケット転送情報に基づいて、無線インフラストラクチャネットワークを介して異なる経路をたどってよい。

いくつかの実施形態では、パケットフローに適用されるべきＱｏＳ要件を反映すべく、ＩＰアドレスがパケットフローに割り当てられてよい。従来のＩＰｖ６ヘッダ内のトラフィッククラスフィールドは、各ルータにおける待ち行列挙動を定義すべく使用されてよいが、従来のＩＰｖ６ヘッダ内のトラフィッククラスフィールドは、ネットワークノードのセットを通る転送経路を識別しなくてよい。有益に、ネットワークノードのセットを通るＱｏＳ対応のルートを識別すべく、フローベースのアドレスのＦＨに埋め込まれたＱｏＳラベルがルータによって使用されてよい。複数のパケットフローが同様のＱｏＳ要件を有する場合、ＱｏＳ対応のルートは、例えば、従来の最長プレフィックスマッチを使用して、各ルータにおけるより少ない数のＦＩＢエントリの中に集約されてよい。図９は、無線インフラストラクチャを通じてダウンリンクパケットをルーティングすべく、一実施形態のＩＰｖ６ヘッダ９０９を使用する、一実施形態のＱｏＳベースのフロー集約スキーム９００の図を例示する。示されるように、当該実施形態のＩＰｖ６ヘッダ９０９は、ＱｏＳラベル９９４及びエンドポイントＩＤ９９６を含むフローベースの宛先アドレス９９０を備える。一実施形態では、フローベースの宛先アドレス９９０はダウンリンクパケットの宛先アドレスであり、アップリンクパケットの送信元アドレスからコピーされる。

本例では、パケットフロー９０１はＲＣＮ９５１からＷＤ９１１に通信され、パケットフロー９０２は、ＲＣＮ９５２からＷＤ９１２に通信され、パケットフロー９０３は、ＲＣＮ９５３からＷＤ９１３に通信され、パケットフロー９０４は、ＲＣＮ９５４からＷＤ９１４に通信されている。パケットフロー９０１及び９０２は、同様のＱｏＳ要件を有してよい。ＷＤ９１１、９１２に関連付けられたＡＰ９２１、９２２は、ＩＰｖ６アドレスを、同一のＱｏＳラベル（例えば、ＱｏＳ‐Ａ）を含むパケットフロー９０１、９０２に割り当ててよい。同様に、ＷＤ９１３、９１４に関連付けられたＡＰ９２２、９２３は、ＩＰｖ６アドレスを、同一のＱｏＳラベル（例えば、ＱｏＳ‐Ｂ）を含むパケットフロー９０３、９０４に割り当ててよい。

ボーダーゲートウェイ９３０からＡＰ９２１、９２２への経路の途中のルータ９４１、９４２は、その宛先アドレスがＱｏＳラベル「ＱｏＳ‐Ａ」を含むパケットのためのネクストホップを識別する転送情報ベース（ＦＩＢ）テーブルを有してよい。同様に、ボーダーゲートウェイ９３０からＡＰ９２２、９２３への経路の途中のルータ９４３、９４４は、その宛先アドレスが、ＱｏＳラベル「ＱｏＳ‐Ｂ」を含むパケットのためのネクストホップを識別するＦＩＢテーブルを有してよい。ルータ９４１、９４２、９４３、９４４は、集中型のＴＭエンティティからの命令に基づいて、又は、分散型のルーティングプロトコル交換に基づいて、ＦＩＢテーブルを維持及び更新してよい。

ボーダーゲートウェイ９３０は、ＲＣＮ９５１及び９５２からパケットフロー９０１、９０２を受信し次第、ＱｏＳラベル「ＱｏＳ‐Ａ」を有するパケットフロー９０１、９０２をルータ９４１に向かわせてよい。ルータ９４１は次に、パケットフロー９０１、９０２をルータ９４２に向かわせてよい。一実施形態では、ボーダーゲートウェイ９３０は、ＱｏＳラベル「ＱｏＳ‐Ａ」を含む最長プレフィックスマッチに基づいて、パケットフロー９０１、９０２をルータ９４１に転送すると決定する。同様に、ルータ９４１は、ＱｏＳラベル「ＱｏＳ‐Ａ」を含む最長プレフィックスマッチに基づいて、パケットフロー９０１、９０２をルータ９４２に転送すると決定してよい。ルータ９４２は、パケットフロー９０１はＡＰ９２１に転送されるべきであり、パケットフロー９０２はＡＰ９２２に転送されるべきであると判断する。ルータ９４２は、ＱｏＳラベル「ＱｏＳ‐Ａ」と、パケットフロー９０１、９０２のパケットによって保持されたエンドポイントＩＤとに最長プレフィックスマッチアルゴリズムを適用することによって、この判断に至ってよい。

加えて、ボーダーゲートウェイ９３０は、ＲＣＮ９５３及び９５４からパケットフロー９０３、９０４を受信し次第、ＱｏＳラベル「ＱｏＳ‐Ｂ」を有するパケットフロー９０３、９０４をルータ９４３に向かわせてよい。ルータ９４３は次に、パケットフロー９０３、９０４をルータ９４４に向かわせてよい。これらのルーティングの決定は、ＱｏＳラベル「ＱｏＳ‐Ｂ」を含む最長プレフィックスマッチを判断することによって成されてよい。ルータ９４４は、パケットフロー９０３はＡＰ９２２に転送されるべきであり、パケットフロー９０４はＡＰ９２３に転送されるべきであると判断する。ルータ９４２は、ＱｏＳラベル「ＱｏＳ‐Ｂ」と、パケットフロー９０３、９０４のパケットによって保持されたエンドポイントＩＤとに最長プレフィックスマッチアルゴリズムを適用することによって、この判断に至ってよい。

いくつかの実施形態では、異なるＩＰアドレスが、同一のデバイスに関連付けられた異なるパケットフローに割り当てられてよく、これにより、パケットフローは、各ＩＰアドレスに関連付けられた異なるフローハンドリング命令に応じて処理／転送される。いくつかの実施形態では、フローハンドリング命令はＩＰアドレスに明示的に埋め込まれ、一方で、他の実施形態においては、アドレスは、先験的にアドレスに関連付けられた所望のフローハンドリングに従って選択される。図１０は、ネットワークノードによって実行されるであろう、ＩＰｖ６アドレスにおいてフローハンドリング命令をシグナリングするための、一実施形態の方法１０００を例示する。方法１０００は段階１０１０から開始し、段階１０１０において、ネットワークノードは、第１のパケットフロー及び第２のパケットフローが開始されたと判断する。第１のパケットフロー及び第２のパケットフローの両方は、同一のデバイスに関連付けられている。次に、方法１０００は段階１０２０に進む。段階１０２０において、ネットワークノードは、第１のＩＰｖ６アドレスを第１のパケットフローに、第２のＩＰｖ６アドレスを第２のパケットフローに割り当てる。ＩＰｖ６アドレスは、異なるフローハンドリング命令に関連付けられている。次に、方法１０００は段階１０３０に進む。段階１０３０において、ネットワークノードは、第１のパケットフローの少なくとも１つのパケットの中に第１のＩＰｖ６アドレスを挿入する。方法１０００は次に段階１０４０に進む。段階１０４０において、ネットワークノードは、第２のパケットフローの少なくとも１つのパケットの中に第２のＩＰｖ６アドレスを挿入する。段階１０５０において、ネットワークノードは、第１のパケットフロー及び第２のパケットフローに関連付けられたパケットをネットワークを通じて通信する。パケットフローがそれぞれ異なるＩＰｖ６アドレスに割り当てられるおかげで、第１のパケットフローに関連付けられたパケットは、第２のパケットフローに関連付けられたパケットとは異なるフローハンドリング命令に従って処理又は転送される。

いくつかのシナリオでは、無線デバイスから発せられた複数のパケットフローが、同一のコンテキストを共有（例えば、同一の処理を受信）してよく、同一のＩＰフローアドレスに関連付けられてよい。これらの例では、（例えば、カプセル化されたＴＣＰ又はＵＤＰヘッダ内のポート番号を使用することによって、）ＩＰパケットヘッダ外のフィールドを使用して、フローを区別すべく、既存の技術が使用されてよい。

データプレーン内において、フローベースのアドレスは、パケットフローの性質を識別すべく使用されてよい。例えば、ユニキャストパケットフローでは、制御情報（例えば、肯定応答又はレート制御）を含むパケットは、データのみを含むパケットと区別されてよい。ビデオストリームの場合、Ｉ‐フレームを含むパケットは、Ｂ‐フレーム又はＰ‐フレームを含むパケットと区別されてよい。ＮＡＣＫ指向の信頼性の高いマルチキャストの場合、初期データの送信を含む転送リンクパケットは、再送信を含むパケット、又は、ＦＥＣ符号化された再送信を含む転送リンクパケットと区別されてよい。

異なるタイプのデータプレーンパケットフロー間の区別に加えて、様々なタイプの制御プレーン及び管理プレーントラフィックを区別すべく、フローベースのアドレスもまた使用されてよい。

特に、ドメイン／ネットワークのイングレスポイントにおいてコンテキスト情報を維持することが、トラフィックフローをサポートするのに必要とされるストレージリソースの量を増やすだけでなく、例えば、適切なトンネルパケットの中に各着信パケットをカプセル化すべく、処理要件も増やす。本開示の実施形態は、パケットのＩＰｖ６アドレスに、何らかのコンテキスト情報を埋め込むことによって、ネットワークのイングレスポイントにおいて格納される必要があるコンテキスト情報の量を低減する。一実施形態では、デバイスは、フローハンドリング（例えば、ダウンリンクフローハンドリング）に関連する埋め込まれたコンテキスト情報を含むフローベースのＩＰｖ６アドレスを割り当てられてよい。これにより、ゲートウェイルータ及びアクセスポイントにおいてパケットフローコンテキストを格納する必要性が除去されるであろう。

ＦＨが埋め込まれたＩＰｖ６アドレスは、市販の、容易に入手可能なルータによって切り替え／処理され得る。このことは、特殊なルーティングプロトコル及びパケット転送エンジンを配置する必要性を除去してよい。予め定義されたサービス機能チェーンを介してフローを転送する、トラフィックエンジニアリングされた経路でフローを転送する、又は、転送テーブルエントリを集約して、同様のＱｏＳ要件でフローをハンドリングするために、標準的なルータ転送メカニズム（例えば、最長プレフィックスマッチ）が使用されてよい。パケットフローは、ネットワーク事業者によって使用されるポリシに応じてルーティングされ得る。

いくつかのシナリオでは、フローベースのアドレスのルーティングプレフィックスは、ローカルネットワーク内でのルーティングに使用されてよい領域プレフィックスを含んでよい。例えば、図３に例示されるように、領域プレフィックスは、フローベースのアドレスの上位６４ビット内の（６４−ｍ）ビットで構成されてよい。いくつかの場合において、領域プレフィックスは、ネットワークの異なる領域／ドメインにおいて、同一のフローハンドルを使用することを可能にしてよい。

いくつか例では、デバイスはまた、新たなパケットフローを識別及び分類するための支援を提供してよい。例えば、デバイスは、そのアプリケーションのうち１つが新たなフローを開始したときはいつも、新たなパケットフローインジケーション（ＮＰＦＩ）をネットワークに提供してよい。ＮＰＦＩは、ＩＰｖ６パケットヘッダに（例えば、フローラベル又はトラフィッククラスフィールドに）含まれてよい、若しくは、ＩＰｖ６送信元アドレスの予約値として符号化されてよい、又は、ＮＰＦＩは、無線アクセスベアラを通じて（例えば、ＭＡＣ制御要素において）シグナリングされてよい。

パケットを送信する前、デバイスは、ＩＰｖ６パケットヘッダの送信元アドレスフィールドの中にフローハンドルを構築及び挿入するよう、ネットワークによって命令されてよい。一例では、無線デバイス（ＷＤ）への命令は、無線リソース制御（ＲＲＣ）シグナリングを介してフローごとに判断される。このシナリオでは、無線デバイスは、新たなパケットフローが開始されていると判断したときはいつも、ＲＲＣ要求をサービングアクセスポイントに送信する。ＷＤによって提供される、又はＡＰによって導出される情報に基づいて、適切なフローハンドルがネットワークによって構築され、ＲＲＣ応答においてＷＤに通信される。

別の例では、命令は、ＲＲＣシグナリングを介してＲＡＢごとに判断される。このシナリオでは、無線デバイスは、新たな無線アクセスベアラがインスタンス化されていると判断したときはいつも、ＲＲＣ要求をサービングアクセスポイントに送信する。ＷＤによって提供される、又はＡＰによって導出される情報に基づいて、適切なフローハンドルを生成するためのテンプレート及びポリシルールが、ＲＲＣ応答においてＷＤに通信される。これらは、ＲＡＢを通じて送信される全てのパケットフローのためにフローハンドルを生成すべく、ＷＤによって使用される。

更に別の例では、命令は、ＲＲＣシグナリングを介してデバイスごと又はインタフェースごとに判断される。このシナリオでは、アクセスポイントは、適切なフローハンドルを生成するためのテンプレート及びポリシルールを含む無線デバイスにＲＲＣコマンドを送信する。これらは、対応する無線リンクインタフェースを通じてネットワークに送信される全てのパケットフローのためにフローハンドルを生成すべく、ＷＤによって使用される。

更に別の例では、命令は、ＲＲＣシグナリング又はシステム情報ブロック（ＳＩＢ）ブロードキャストを介してＡＰごと又はグループごとに判断される。このシナリオでは、アクセスポイントは、適切なフロー識別子を生成するためのテンプレート及びポリシルールを含んでよい、そのカバレッジエリア内の無線デバイスの選択されたグループに（又は無線デバイスの全てに）ＲＲＣコマンドをマルチキャスト（又はブロードキャスト）する。これらのルールは、そのアクセスポイントを介してネットワークに送信される全てのパケットフローのためにフローハンドルを生成すべく、ターゲットとされた無線デバイスによって使用されてよい。

パケットが、デバイスによって提供されたフローハンドルと共に受信された場合、ネットワークエッジノード（例えば、サービングアクセスポイント）は、ネットワークエッジノードを含むネットワークのトポロジーを反映するルーティングプレフィックス（ＲＰ）と共に、ローカルに導出された情報をフローハンドル（例えば、アクセスポイント識別子、ＲＡＢ識別子）の中に挿入することによって、ＩＰｖ６フローベースの送信元アドレスの構築を完了してよい。

本開示の実施形態は、フローベースのアドレスのネットワーク割り当て解除のための技術を提供する。フローベースのアドレスは、そのアドレスに関連付けられたパケットフローの全てが終了したと見做されたときはいつも、ネットワークノード（例えば、アクセスポイント）によって、非アクティブと示されてよい。パケットフローの終了は、例えば、ＴＣＰヘッダ又はアプリケーションヘッダ（例えば、ＨＴＴＰ、ＲＴＰ）からの１又は複数のフィールドを調べることによって、パケットフローが受信された無線アクセスベアラ（ＲＡＢ）の特性の変化を識別することによって、又は、パケットフローの非アクティブタイマの満了によって、判断されてよい。

いくつかの例では、デバイスはまた、パケットフローの終了を識別するための支援を提供してよい。例えば、デバイスは、そのアプリケーションのうち１つがフローを終了したときはいつも、パケットフロー終了インジケーション（ＰＦＴＩ）をネットワークに提供してよい。ＰＦＴＩは、ＩＰｖ６パケットヘッダに（例えば、フローラベル又はトラフィッククラスフィールドに）含まれてよい、若しくは、ＩＰｖ６送信元アドレスの予約値として符号化されてよい、又は、ＰＦＴＩは、無線アクセスベアラを通じて（例えば、ＭＡＣ制御要素において）シグナリングされてよい。

モバイルＩＰ環境では、いくつかのパケットフローは短命であってよく、完了されてよく、デバイスがその接続ポイントを変更することなく、関連付けられたＩＰアドレスは解放されてよい。しかしながら、モバイルデバイスが、大きなデータオブジェクトの伝達に直面する機会があるかもしれない。これらの例では、データ伝達中における移動型であることの影響は、データオブジェクトを、単一のモノリシックエンティティとしてではなく、一連のより小さなチャンクとして伝達することによって緩和され得る。各チャンクは、各パケットフローがそれ自身のＩＰｖ６アドレスを割り当てられるよう、各チャンクの伝達が異なるパケットフローとして表されるように、別々に伝達され得る。チャンクのダウンロードは、割り当てられたＩＰｖ６アドレスを解放する前に、単一のアクセスポイントのカバレッジ内で短命のフローとして完了され得る。デバイスが移動型である場合、このことは、異なるチャンクが、異なるＩＰｖ６アドレスを使用して、異なる接続ポイントを介して伝達されることを可能にし、パケットフローのハンドオーバの必要性を除去し、ハンドオーバのオーバーヘッドを最小限に抑える。いくつかの例では、パケットフローがアクティブである間にデバイスがその接続ポイントを変更する場合、デバイスは、最初のパケットフローをアボートし、新たな接続ポイントに関連付けられた新たなＩＰｖ６アドレスを有する新たなパケットフローとして開始された新たな要求によって、中断されたチャンクの再送信を要求し得る。特に、ＨＴＴＰ ＧＥＴ要求及びＰＵＴ要求は、チャンクをデータオブジェクト内の一連のバイトと識別するＲＡＮＧＥによって認定され得る。この技術はまた、例えば、ＨＴＴＰでの動的アダプティブストリーミング（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）プロトコルを使用した、大きなビデオファイル及びストリームのダウンロードに適用され得る。

いくつかの状況では、デバイス上で実行されるアプリケーションが散発的に、パケットのショートバーストをリモート対応ノード（ＲＣＮ）と交換してよい。例えば、メールサーバ又はソーシャルネットワークサーバに更新のクエリを行うべく、又は、リモートサーバにアプリケーションステータスの最新情報を提供すべく、この種のバックグラウンドトラフィックが使用されてよい。

ＲＣＮとの交換期間におけるフローベースのアドレスの無線デバイスへの自動割り当ては、モビリティイベント及びそれらの制御シグナリングオーバーヘッドの必要性を除去して、ネットワークにおける転送コンテキストを更新し、アドレス割り当てに関連付けられたシグナリングオーバーヘッドの必要性を除去し、無線ネットワーク内でのトンネルの使用を回避して、その現在の接続ポイントにおいて、応答をＲＣＮからＷＤへ転送し、ネットワークによって維持されなければならないデバイス固有のコンテキストの量を低減してよい。

本開示の態様が、ＭＴＣトラフィック管理のための技術を提供する。フローごとのアドレス割り当ては、マシンタイプ通信デバイス（ＭＴＣＤ）への、及びＭＴＣＤからのトラフィックのハンドリングに関連する多くの態様を単純化する。一例において、ＭＴＣデバイスとは独立しており、かつＭＴＣデバイスに対して透過的な方式で、ＩＰアドレスの遅延結合をＭＴＣデバイスに提供すべく、ネットワークによるフローベースのアドレス割り当てが使用されてよい。これにより、商品であるＭＴＣデバイスの大規模な配置の間のＩＰアドレスのプロビジョニングに関連付けられたオーバーヘッドが回避され、ＭＴＣＤのバッテリ電力が保存されるであろう。

マシンタイプ通信（ＭＴＣ）トラフィックは、ＭＴＣデバイス（ＭＴＣＤ）がリモート対応ノードとパケットのショートバーストを散発的に交換してよいという点でバックグラウンドトラフィックと同一の特性の多くを共有してよい。従って、ユニキャストＭＴＣトラフィックについて、フローベースのアドレス指定を使用する便益は、バックグラウンドトラフィックにフローベースのアドレス指定を使用する便益と同様である。

図１１は、通信デバイス１１００の一実施形態のブロック図を例示している。通信デバイス１１００は、上記１又は複数のデバイス（例えば、無線デバイス、ネットワークノード等）と同等であってよい。通信デバイス１１００は、プロセッサ１１０４、メモリ１１０６、無線インタフェース１１１０、補足インタフェース１１１２、及び有線インタフェース１１１４を含んでよく、これらは図１１に示される通りに配置されてよい（又は、示される通りに配置されなくてよい）。プロセッサ１１０４は、計算及び／又は他の処理関連タスクを実行可能な任意のコンポーネントであってよく、メモリ１１０６は、プロセッサ１１０４のためのプログラミング及び／又は命令を格納可能な任意のコンポーネントであってよい。無線インタフェース１１１０は、通信デバイスが無線信号を使用して通信できるようにする任意のコンポーネント又はコンポーネントの集まりであってよく、例えば、３ＧＰＰロングタームエボリューション（ＬＴＥ）プロトコルを使用して無線アクセスネットワークの無線接続を通じて情報を受信及び／又は送信するために使用されてよい。オプションの補足インタフェース１１１２は、通信デバイスが補足的なプロトコルによってデータを通信する、又は情報を制御することを可能にする任意のコンポーネント又はコンポーネントの集まりであってよい。例えば、補足インタフェース１１１２は、無線フィデリティ（Ｗｉ−Ｆｉ）プロトコル又はブルートゥース（登録商標）プロトコルに従って通信するための補助的な無線インタフェースであってよい。或いは、補足インタフェース１１１２は、例えば、ユニバーサルシリアルバスプロトコルを使用する有線インタフェースであってよい。有線インタフェース１１１４は、任意で通信デバイスに含まれてよく、通信デバイスが、例えば、イーサネット（登録商標）プロトコルを使用して、有線ネットワークを介して、別のデバイスと通信できるようにする任意のコンポーネント又はコンポーネントの集まりを備えてよい。

図１２は、本明細書で開示されたデバイスおよび方法を実装するために使用されてよい処理システム１２００のブロック図である。特定のデバイスが、示されるコンポーネントの全てを、又は、それらのコンポーネントのサブセットのみを利用してよく、統合のレベルはデバイスによって異なっていてよい。更に、デバイスは、複数の処理ユニット、プロセッサ、メモリ、送信機、受信機等といった、コンポーネントの複数の例を含んでよい。処理システム１２００は、スピーカ、マイク、マウス、タッチスクリーン、キーパッド、キーボード、プリンタ、ディスプレイ、及び同様のものなどの１又は複数の入出力デバイス１２１６、１２２４を備えた処理ユニットを含んでよい。処理システム１２００は、中央処理装置（ＣＰＵ）１２０２、メモリ１２１０、大容量ストレージデバイス１２０４、ビデオアダプタ１２１５、及びＩ／Ｏインタフェース１２２１を備え、これら全てはバス１２０６に接続されていてよい。

バス１２０６は、メモリバス若しくはメモリコントローラ、周辺バス、ビデオバス、又は同様のものを含む、任意のタイプのいくつかのバスアーキテクチャのうちの１又は複数であってよい。ＣＰＵ１２０２は、任意のタイプの電子データプロセッサを含んでよい。メモリ１２１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、リードオンリメモリ（ＲＯＭ）、それらの組み合わせ、又は同様のものなどの、任意のタイプの非一時的システムメモリを含んでよい。一実施形態では、メモリ１２１０は、ブートアップ時に使用するためのＲＯＭと、プログラムを実行する間に使用するためのプログラム及びデータの格納用のＤＲＡＭとを含んでよい。

大容量ストレージデバイス１２０４は、データ、プログラム、及び他の情報を格納し、当該データ、プログラム、及び他の情報を、バス１２０６を介してアクセス可能にするよう構成された、任意のタイプの非一時的ストレージデバイスを含んでよい。大容量ストレージデバイス１２０４は、例えば、ソリッドステートドライブ、ハードディスクドライブ、磁気ディスクドライブ、光ディスクドライブ、又は同様のもののうちの１又は複数を含んでよい。

ビデオアダプタ１２１５及びＩ／Ｏインタフェース１２２１はインタフェースを提供して、外部の入出力デバイスを処理システム１２００に接続する。例示されるように、入出力デバイスの例は、ビデオアダプタ１２１５に接続されたディスプレイ１２１６、及び、Ｉ／Ｏインタフェース１２２１に接続されたマウス／キーボード／プリンタ１２２４を含む。他のデバイスが処理システム１２００に接続されてよく、追加の、又はより少ないインタフェース又はインタフェースカードが利用されてよい。例えば、プリンタ１２２４にインタフェースを提供すべく、ユニバーサルシリアルバス（ＵＳＢ）（図示せず）などのシリアルインタフェースが使用されてよい。

処理システム１２００はまた、ノード又は異なるネットワーク１２３０にアクセスすべく、イーサネット（登録商標）ケーブル若しくは同様のものなどの有線リンク、及び／又は、無線リンクを含んでよい、１又は複数のネットワークインタフェース１２０７を備える。ネットワークインタフェース１２０７は、処理システム１２００がネットワーク１２３０を介して遠隔ユニットと通信できるようにする。例えば、ネットワークインタフェース１２０７は、１又は複数の送信機／送信アンテナ、及び、１又は複数の受信機／受信アンテナを介して無線通信を提供してよい。一実施形態では、処理システム１２００は、データ処理と、他の処理ユニット、インターネット、遠隔記憶装置、又は同様のものなどの遠隔デバイスとの通信とのためのローカルエリアネットワーク１２３０又は広域ネットワーク１２３０に接続されている。

本発明の一実施形態において、インターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）ネットワークアドレスを割り当てるための方法が提供される。当該方法は、
デバイスに関連付けられた第１のパケットフローと、デバイスに関連付けられた、第１のパケットフローとは異なる第２のパケットフローとが開始されたと判断する段階と、
利用可能なアドレスのプールから、第１のＩＰｖ６アドレスを第１のパケットフローに割り当て、第２のＩＰｖ６アドレスを第２のパケットフローに割り当てる段階であって、第１のＩＰｖ６アドレスは第２のＩＰｖ６アドレスとは異なる、段階と、
第１のＩＰｖ６アドレスを、第１のパケットフローに関連付けられた少なくとも１つのパケットのアドレスフィールドの中に挿入する段階と、
第２のＩＰｖ６アドレスを、第２のパケットフローに関連付けられた少なくとも１つのパケットのアドレスフィールドの中に挿入する段階と、
第１のパケットフロー及び第２のパケットフローに関連付けられたパケットを、ネットワークを通じて通信する段階とを備える。

本実施形態の第２の方法は第１の方法を含み、更に、
第１のパケットフローが終了されたと判断する段階と、
第１のＩＰｖ６アドレスを、利用可能なアドレスのプールに戻す段階とを備える。

本実施形態の第３の方法は、第２の方法に基づいており、第１のＩＰｖ６アドレスを挿入する段階は、第１のＩＰｖ６アドレスを、第１のパケットフローに関連付けられた全パケットのアドレスフィールドの中に挿入する段階を含み、第２のＩＰｖ６アドレスを挿入する段階は、第２のＩＰｖ６アドレスを、第２のパケットフローに関連付けられた全パケットのアドレスフィールドの中に挿入する段階とを含む。

本実施形態の第４の方法は、第３の方法に基づいており、割り当てる段階は、ネットワーク内の第２のノードにおける第１のパケットフローの所望の転送又は処理に従って、第１のＩＰｖ６アドレスを選択する段階を含む。

本発明は、例示的実施形態に関して説明されてきたが、本説明は、限定的意味で解釈されるように意図されていない。例示的実施形態の様々な変形形態及び組み合わせ、並びに、本発明の他の実施形態が、本説明を参照すれば当業者には明らかであろう。従って、添付の特許請求の範囲は、そのようなあらゆる変形形態又は実施形態を含むことが意図されている。
［項目１］
通信ネットワークにおいてパケットフローを通信するための方法であって、
第１のパケットのインターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）アドレスの中に、第１のフローハンドル（ＦＨ）を第１のネットワークノードによって埋め込む段階であって、上記第１のＦＨは、上記第１のパケットを処理するためのフロー情報を含む、段階と、
上記第１のＦＨに含まれる上記フロー情報に従って、上記第１のパケットの転送又は処理のうち一方のために、上記第１のパケットを第２のネットワークノードに送信する段階と
を備える方法。
［項目２］
第２のパケットのＩＰｖ６アドレスの中に第２のＦＨを上記第１のネットワークノードによって埋め込む段階であって、上記第２のパケットは、上記第１のパケットとは異なるパケットフローに関連付けられており、上記第２のＦＨは、上記第１のＦＨとは異なるフロー情報を含む、段階と、
上記第２のＦＨに含まれる上記情報に従って、上記第２のパケットの転送又は処理のうち一方のために、上記第２のパケットを上記第２のネットワークノードに送信する段階であって、上記第２のパケットの上記転送又は上記処理は、上記第１のパケットの上記転送又は上記処理とは異なる、段階と
を更に備える項目１に記載の方法。
［項目３］
上記フロー情報は、特定の一連のパケットを識別するパケットフローＩＤを備える、項目１に記載の方法。
［項目４］
上記フロー情報は、予め定義されたサービス機能チェーン（ＳＦＣ）を識別するＳＦＣ ＩＤを更に備える、項目１に記載の方法。
［項目５］
上記フロー情報は、ネットワークアクセスポイント（ＡＰ）を識別するＡＰ ＩＤを更に備える、項目１に記載の方法。
［項目６］
上記フロー情報は、無線アクセスリンク接続を識別する無線ベアラＩＤを更に備える、項目１に記載の方法。
［項目７］
上記フロー情報は、予め定義された経路を識別する経路ＩＤを更に備える、項目１に記載の方法。
［項目８］
上記フロー情報は、上記パケットのサービス品質（ＱｏＳ）要件を識別するＱｏＳコードポイントを更に備える、項目１に記載の方法。
［項目９］
上記フロー情報は、エンドノードを識別するデバイスＩＤを更に備える、項目１に記載の方法。
［項目１０］
上記第１のネットワークノードと上記第２のネットワークノードとの間に、１又は複数の中間ネットワークノードが配置される、項目１に記載の方法。
［項目１１］
上記第１のネットワークノードはエンドノードである、項目１に記載の方法。
［項目１２］
上記第１のネットワークノードはネットワークアクセスポイントである、項目１に記載の方法。
［項目１３］
プロセッサと、
上記プロセッサによる実行のためのプログラミングを格納するコンピュータ可読記憶媒体であって、上記プログラミングは、
第１のパケットのインターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）アドレスの中に、上記第１のパケットを処理するためのフロー情報を含む第１のフローハンドル（ＦＨ）を埋め込み、
上記第１のＦＨに含まれる上記フロー情報に従って、上記第１のパケットの転送又は処理のうち一方のために、上記第１のパケットを第２のネットワークノードに送信するための命令を含む、コンピュータ可読記憶媒体と
を備える第１のネットワークノード。
［項目１４］
通信ネットワークを通じて受信されたパケットを処理又は転送するための方法であって、
パケットのインターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）アドレスに埋め込まれたフローハンドル（ＦＨ）を有する上記パケットを、第２のネットワークノードによって第１のネットワークノードから受信する段階であって、上記ＦＨは、上記パケットの処理に関連付けられたフロー情報を含む、段階と、
上記パケットの上記ＩＰｖ６アドレスに埋め込まれた上記ＦＨによって特定される上記フロー情報に従って、上記第２のネットワークノードによって上記パケットを処理又は転送する段階と
を備える方法。
［項目１５］
上記第２のノードによって実行される上記処理又は上記転送は、前に受信されたパケットのＩＰｖ６アドレスに埋め込まれたＦＨを有する上記前に受信されたパケットに対して上記第２のノードによって実行される上記処理又は上記転送とは異なる、項目１４に記載の方法。
［項目１６］
上記パケットの上記ＩＰｖ６アドレスに埋め込まれた上記ＦＨによって特定される上記フロー情報に従って、上記パケットを処理又は転送する段階は、
上記パケットの上記ＩＰｖ６アドレスに埋め込まれた上記ＦＨによって特定されるフロー情報に関連付けられた経路又はネクストホップを識別する段階と、
上記識別された経路で、又は、上記識別されたネクストホップに、上記パケットを転送する段階とを含む、項目１４に記載の方法。
［項目１７］
上記パケットの上記ＩＰｖ６アドレスに埋め込まれた上記ＦＨによって特定される上記フロー情報に従って、上記パケットを処理又は転送する段階は、
上記パケットの上記ＩＰｖ６アドレスに埋め込まれた上記ＦＨに関連付けられたサービス品質（ＱｏＳ）要件を識別する段階と、
上記ＱｏＳ要件を満たすことが可能な経路を選択する段階と、
上記経路で上記パケットを転送する段階とを含む、項目１４に記載の方法。
［項目１８］
上記パケットの上記ＩＰｖ６アドレスに埋め込まれた上記ＦＨによって特定される上記フロー情報に従って、上記パケットを処理又は転送する段階は、
上記パケットの上記ＩＰｖ６アドレスに埋め込まれた上記ＦＨに関連付けられたサービス機能を識別する段階と、
上記サービス機能を上記パケットに適用する段階とを含む、項目１４に記載の方法。
［項目１９］
上記ＦＨによって特定される上記フロー情報は、特定の一連のパケットを識別するパケットフローＩＤを備える、項目１４に記載の方法。
［項目２０］
上記ＦＨによって特定される上記フロー情報は、予め定義されたサービス機能チェーン（ＳＦＣ）を識別するＳＦＣ ＩＤを更に備える、項目１４に記載の方法。
［項目２１］
上記ＦＨによって特定される上記フロー情報は、ネットワークアクセスポイント（ＡＰ）を識別するＡＰ ＩＤを更に備える、項目１４に記載の方法。
［項目２２］
上記ＦＨによって特定される上記フロー情報は、無線アクセスリンク接続を識別する無線ベアラＩＤを更に備える、項目１４に記載の方法。
［項目２３］
上記ＦＨによって特定される上記フロー情報は、予め定義された経路を識別する経路ＩＤを更に備える、項目１４に記載の方法。
［項目２４］
上記ＦＨによって特定される上記フロー情報は、上記パケットのサービス品質（ＱｏＳ）要件を識別するＱｏＳコードポイントを更に備える、項目１４に記載の方法。
［項目２５］
上記ＦＨによって特定される上記フロー情報は、エンドノードを識別するデバイスＩＤを更に備える、項目１４に記載の方法。
［項目２６］
プロセッサと、
上記プロセッサによる実行のためのプログラミングを格納するコンピュータ可読記憶媒体であって、上記プログラミングは、
パケットのインターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）アドレスに埋め込まれた、上記パケットの処理に関連付けられたフロー情報を含むフローハンドル（ＦＨ）を有する上記パケットを第１のネットワークノードから受信し、
上記パケットの上記ＩＰｖ６アドレスに埋め込まれた上記ＦＨによって特定される上記フロー情報に従って、上記パケットを処理又は転送するための命令を含む、コンピュータ可読記憶媒体と
を備える第２のネットワークノード。
［項目２７］
インターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）ネットワークアドレスを割り当てるための方法であって、
デバイスに関連付けられた第１のパケットフローと、上記デバイスに関連付けられた、上記第１のパケットフローとは異なる第２のパケットフローとが開始されたと判断する段階と、
利用可能なアドレスのプールから、第１のＩＰｖ６アドレスを上記第１のパケットフローに割り当て、第２のＩＰｖ６アドレスを上記第２のパケットフローに割り当てる段階であって、上記第１のＩＰｖ６アドレスは、上記第２のＩＰｖ６アドレスとは異なる、段階と、
上記第１のＩＰｖ６アドレスを、上記第１のパケットフローに関連付けられた少なくとも１つのパケットのアドレスフィールドの中に挿入する段階と、
上記第２のＩＰｖ６アドレスを、上記第２のパケットフローに関連付けられた少なくとも１つのパケットのアドレスフィールドの中に挿入する段階と、
ネットワークを通じて、上記第１のパケットフロー及び上記第２のパケットフローに関連付けられたパケットを通信する段階と
を備える方法。
［項目２８］
上記第１のパケットフローが終了したと判断する段階と、
上記第１のＩＰｖ６アドレスを、利用可能なアドレスの上記プールに戻す段階と
を更に備える項目２７に記載の方法。
［項目２９］
上記第１のＩＰｖ６アドレスを挿入する段階は、上記第１のＩＰｖ６アドレスを、上記第１のパケットフローに関連付けられた全パケットの上記アドレスフィールドの中に挿入する段階を含み、上記第２のＩＰｖ６アドレスを挿入する段階は、上記第２のＩＰｖ６アドレスを、上記第２のパケットフローに関連付けられた全パケットの上記アドレスフィールドの中に挿入する段階を含む、
項目２８に記載の方法。
［項目３０］
上記割り当てる段階は、上記ネットワーク内の第２のノードにおいて、上記第１のパケットフローの所望の転送又は処理に従って、上記第１のＩＰｖ６アドレスを選択する段階を含む、項目２９に記載の方法。

Claims (30)

1. 通信ネットワークにおいてパケットフローを通信するための方法であって、
   第１のパケットのインターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）アドレスの中に、第１のフローハンドル（ＦＨ）を第１のネットワークノードによって埋め込む段階であって、前記第１のＦＨは、前記第１のパケットを処理するためのフロー情報を含む、段階と、
   前記第１のＦＨに含まれる前記フロー情報に従って、前記第１のパケットの転送又は処理のうち一方のために、前記第１のパケットを第２のネットワークノードに送信する段階と
   を備える方法。
2. 第２のパケットのＩＰｖ６アドレスの中に第２のＦＨを前記第１のネットワークノードによって埋め込む段階であって、前記第２のパケットは、前記第１のパケットとは異なるパケットフローに関連付けられており、前記第２のＦＨは、前記第１のＦＨとは異なるフロー情報を含む、段階と、
   前記第２のＦＨに含まれる前記情報に従って、前記第２のパケットの転送又は処理のうち一方のために、前記第２のパケットを前記第２のネットワークノードに送信する段階であって、前記第２のパケットの前記転送又は前記処理は、前記第１のパケットの前記転送又は前記処理とは異なる、段階と
   を更に備える請求項１に記載の方法。
3. 前記フロー情報は、特定の一連のパケットを識別するパケットフローＩＤを備える、請求項１に記載の方法。
4. 前記フロー情報は、予め定義されたサービス機能チェーン（ＳＦＣ）を識別するＳＦＣ ＩＤを更に備える、請求項１に記載の方法。
5. 前記フロー情報は、ネットワークアクセスポイント（ＡＰ）を識別するＡＰ ＩＤを更に備える、請求項１に記載の方法。
6. 前記フロー情報は、無線アクセスリンク接続を識別する無線ベアラＩＤを更に備える、請求項１に記載の方法。
7. 前記フロー情報は、予め定義された経路を識別する経路ＩＤを更に備える、請求項１に記載の方法。
8. 前記フロー情報は、前記パケットのサービス品質（ＱｏＳ）要件を識別するＱｏＳコードポイントを更に備える、請求項１に記載の方法。
9. 前記フロー情報は、エンドノードを識別するデバイスＩＤを更に備える、請求項１に記載の方法。
10. 前記第１のネットワークノードと前記第２のネットワークノードとの間に、１又は複数の中間ネットワークノードが配置される、請求項１に記載の方法。
11. 前記第１のネットワークノードはエンドノードである、請求項１に記載の方法。
12. 前記第１のネットワークノードはネットワークアクセスポイントである、請求項１に記載の方法。
13. プロセッサと、
    前記プロセッサによる実行のためのプログラミングを格納するコンピュータ可読記憶媒体であって、前記プログラミングは、
    第１のパケットのインターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）アドレスの中に、前記第１のパケットを処理するためのフロー情報を含む第１のフローハンドル（ＦＨ）を埋め込み、
    前記第１のＦＨに含まれる前記フロー情報に従って、前記第１のパケットの転送又は処理のうち一方のために、前記第１のパケットを第２のネットワークノードに送信するための命令を含む、コンピュータ可読記憶媒体と
    を備える第１のネットワークノード。
14. 通信ネットワークを通じて受信されたパケットを処理又は転送するための方法であって、
    パケットのインターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）アドレスに埋め込まれたフローハンドル（ＦＨ）を有する前記パケットを、第２のネットワークノードによって第１のネットワークノードから受信する段階であって、前記ＦＨは、前記パケットの処理に関連付けられたフロー情報を含む、段階と、
    前記パケットの前記ＩＰｖ６アドレスに埋め込まれた前記ＦＨによって特定される前記フロー情報に従って、前記第２のネットワークノードによって前記パケットを処理又は転送する段階と
    を備える方法。
15. 前記第２のノードによって実行される前記処理又は前記転送は、前に受信されたパケットのＩＰｖ６アドレスに埋め込まれたＦＨを有する前記前に受信されたパケットに対して前記第２のノードによって実行される前記処理又は前記転送とは異なる、請求項１４に記載の方法。
16. 前記パケットの前記ＩＰｖ６アドレスに埋め込まれた前記ＦＨによって特定される前記フロー情報に従って、前記パケットを処理又は転送する段階は、
    前記パケットの前記ＩＰｖ６アドレスに埋め込まれた前記ＦＨによって特定されるフロー情報に関連付けられた経路又はネクストホップを識別する段階と、
    前記識別された経路で、又は、前記識別されたネクストホップに、前記パケットを転送する段階とを含む、請求項１４に記載の方法。
17. 前記パケットの前記ＩＰｖ６アドレスに埋め込まれた前記ＦＨによって特定される前記フロー情報に従って、前記パケットを処理又は転送する段階は、
    前記パケットの前記ＩＰｖ６アドレスに埋め込まれた前記ＦＨに関連付けられたサービス品質（ＱｏＳ）要件を識別する段階と、
    前記ＱｏＳ要件を満たすことが可能な経路を選択する段階と、
    前記経路で前記パケットを転送する段階とを含む、請求項１４に記載の方法。
18. 前記パケットの前記ＩＰｖ６アドレスに埋め込まれた前記ＦＨによって特定される前記フロー情報に従って、前記パケットを処理又は転送する段階は、
    前記パケットの前記ＩＰｖ６アドレスに埋め込まれた前記ＦＨに関連付けられたサービス機能を識別する段階と、
    前記サービス機能を前記パケットに適用する段階とを含む、請求項１４に記載の方法。
19. 前記ＦＨによって特定される前記フロー情報は、特定の一連のパケットを識別するパケットフローＩＤを備える、請求項１４に記載の方法。
20. 前記ＦＨによって特定される前記フロー情報は、予め定義されたサービス機能チェーン（ＳＦＣ）を識別するＳＦＣ ＩＤを更に備える、請求項１４に記載の方法。
21. 前記ＦＨによって特定される前記フロー情報は、ネットワークアクセスポイント（ＡＰ）を識別するＡＰ ＩＤを更に備える、請求項１４に記載の方法。
22. 前記ＦＨによって特定される前記フロー情報は、無線アクセスリンク接続を識別する無線ベアラＩＤを更に備える、請求項１４に記載の方法。
23. 前記ＦＨによって特定される前記フロー情報は、予め定義された経路を識別する経路ＩＤを更に備える、請求項１４に記載の方法。
24. 前記ＦＨによって特定される前記フロー情報は、前記パケットのサービス品質（ＱｏＳ）要件を識別するＱｏＳコードポイントを更に備える、請求項１４に記載の方法。
25. 前記ＦＨによって特定される前記フロー情報は、エンドノードを識別するデバイスＩＤを更に備える、請求項１４に記載の方法。
26. プロセッサと、
    前記プロセッサによる実行のためのプログラミングを格納するコンピュータ可読記憶媒体であって、前記プログラミングは、
    パケットのインターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）アドレスに埋め込まれた、前記パケットの処理に関連付けられたフロー情報を含むフローハンドル（ＦＨ）を有する前記パケットを第１のネットワークノードから受信し、
    前記パケットの前記ＩＰｖ６アドレスに埋め込まれた前記ＦＨによって特定される前記フロー情報に従って、前記パケットを処理又は転送するための命令を含む、コンピュータ可読記憶媒体と
    を備える第２のネットワークノード。
27. インターネットプロトコル（ＩＰ）バージョン６（ＩＰｖ６）ネットワークアドレスを割り当てるための方法であって、
    デバイスに関連付けられた第１のパケットフローと、前記デバイスに関連付けられた、前記第１のパケットフローとは異なる第２のパケットフローとが開始されたと判断する段階と、
    利用可能なアドレスのプールから、第１のＩＰｖ６アドレスを前記第１のパケットフローに割り当て、第２のＩＰｖ６アドレスを前記第２のパケットフローに割り当てる段階であって、前記第１のＩＰｖ６アドレスは、前記第２のＩＰｖ６アドレスとは異なる、段階と、
    前記第１のＩＰｖ６アドレスを、前記第１のパケットフローに関連付けられた少なくとも１つのパケットのアドレスフィールドの中に挿入する段階と、
    前記第２のＩＰｖ６アドレスを、前記第２のパケットフローに関連付けられた少なくとも１つのパケットのアドレスフィールドの中に挿入する段階と、
    ネットワークを通じて、前記第１のパケットフロー及び前記第２のパケットフローに関連付けられたパケットを通信する段階と
    を備える方法。
28. 前記第１のパケットフローが終了したと判断する段階と、
    前記第１のＩＰｖ６アドレスを、利用可能なアドレスの前記プールに戻す段階と
    を更に備える請求項２７に記載の方法。
29. 前記第１のＩＰｖ６アドレスを挿入する段階は、前記第１のＩＰｖ６アドレスを、前記第１のパケットフローに関連付けられた全パケットの前記アドレスフィールドの中に挿入する段階を含み、前記第２のＩＰｖ６アドレスを挿入する段階は、前記第２のＩＰｖ６アドレスを、前記第２のパケットフローに関連付けられた全パケットの前記アドレスフィールドの中に挿入する段階を含む、
    請求項２８に記載の方法。
30. 前記割り当てる段階は、前記ネットワーク内の第２のノードにおいて、前記第１のパケットフローの所望の転送又は処理に従って、前記第１のＩＰｖ６アドレスを選択する段階を含む、請求項２９に記載の方法。