JP2020507289A - 多重パケット処理コア上の無線加入者パケット処理の負荷分散 - Google Patents

Abstract

電気通信システムのスループットを改善し、かつキャッシュミスの確率および発生率を低減させるための、所与の無線加入者に対するパケット処理の単一の「パケットハンドラ」コアへの閉じ込め、または「ピン留め」に関するシステムおよび方法。パケットヘッダデータは、加入者のトンネルエンドポイント識別子（「ＴＥＩＤ」）および／またはセッション識別子を含むことができる。負荷分散装置コアは、一方または両方の識別子を使用して、パケットの双方向トラフィックが方向付けられるパケットハンドラコアを選択することができる。ハッシュ化アルゴリズムを使用して、多重パケットハンドラコアの各々に多数のＵＥを分配することができる。他の実施形態は、区分されたマルチプロトコルラベルスイッチング（「ＭＰＬＳ」）ラベルスペースを使用して、システム開始プロキシトラフィックと、ダウンストリームＵＥトラフィックと、を区別することに関する。例えば、ＭＰＬＳラベルスペースは、ＵＥプールアドレスドメインと、プロキシループバックアドレスドメインと、に分割することができる。【選択図】図１５

Description

関連出願の相互参照
本出願は、２０１７年１月２５日に出願された米国仮特許出願第６２／４５０，１６２号に対する優先権を主張するものであり、同出願は、参照により本明細書に組み込まれる。

本発明の実施形態は、概して、電気通信システムに関し、具体的には、通信システムにおけるデータパケットの処理およびルーティングに関する。

データファイルが、電気通信ネットワークを介して移送されるとき、それらを、処理のために送信元から宛先へルーティングされるデータ「パケット」に分解することができる。パケットネットワークアプリケーションの複雑さが増すにつれて、多重プロセッサコアアーキテクチャ（「マルチコアネットワーク」）の使用がますます普及してきている。

開示されている主題に従って、通信システム内のパケットハンドラコアにパケットを送信するためにシステムおよび方法が提供されている。いくつかの実施形態では、開示されている主題は、加入者に対応する要求を受信してセッションを作成するためのコンピューティングデバイスを含む。いくつかの実施形態では、コンピューティングデバイスは、セッションにダウンストリーム識別子およびアップストリーム識別子を割り当て、セッションにセッション識別子を関連付ける。いくつかの実施形態では、セッション識別子は、加入者に関連付けられているセッションを一意的に識別する。いくつかの実施形態では、コンピューティングデバイスは、ダウンストリーム識別子またはアップストリーム識別子を含むデータパケットを受信し、受信したダウンストリーム識別子またはアップストリーム識別子に基づいて、データパケットに関連付けられているセッション識別子を識別する。いくつかの実施形態では、コンピューティングデバイスは次いで、セッション識別子に基づいて、データパケットをパケットハンドラコアにルーティングする。

いくつかの実施形態では、アップストリーム識別子は、トンネルエンドポイント識別子（「ＴＥＩＤ」）または暗号化キーを含む。いくつかの実施形態では、プロセッサは、暗号化キーを使用して、データパケットを暗号化または復号化し得る。いくつかの実施形態では、ダウンストリーム識別子は、ユーザ機器（「ＵＥ」）インターネットプロトコル（「ＩＰ」）アドレスまたはＴＥＩＤを含む。いくつかの実施形態では、アップストリーム識別子およびダウンストリーム識別子は、共通の値を共有する。例えば、共通の値は、アップストリーム識別子およびダウンストリーム識別子の最初の２４ビットを含み得る。いくつかの実施形態では、プロセッサは、セッション識別子にハッシュ化アルゴリズムを適用してパケットハンドラコアを判定し得る。いくつかの実施形態では、プロセッサは、データパケットに対するプロキシサービスを識別し、データパケットをプロキシサービスモジュールへとルーティングし、パケットハンドラコアの識別子をセッション識別子と相関させ得る。いくつかの実施形態では、プロセッサは、パケットハンドラコアに対する識別子に基づいて、データパケットをパケットハンドラコアにルーティングし得る。

いくつかの実施形態では、システム開始プロキシトラフィックは、区分されたマルチプロトコルラベルスイッチング（「ＭＰＬＳ」）ラベルスペースを使用して、ダウンストリーム加入者トラフィックと区別され得る。いくつかの実施形態では、ＭＰＬＳスペースは、ＵＥプールアドレスドメインと、プロキシループバックアドレスドメインと、に分割されてもよい。

開示されている主題のこれらおよび他の能力は、以下の図面、詳細な説明、および特許請求の範囲を検討した後にさらに十分に理解されるであろう。本明細書で採用されている言い回しおよび用語は、説明を目的としており、限定と見なされるべきではないことを理解されたい。

開示されている主題の様々な実施形態のより完全な理解のために、添付の図面に関連してなされる以下の説明をここで参照する。

開示されている主題のいくつかの実施形態による、マルチコア通信システムを通るパケットフローを説明する図である。 開示されている主題のいくつかの実施形態による、単一ルート入力／出力仮想化（「ＳＲ−ＩＯＶ」）を使用したデータプレーン開発キット（「ＤＰＤＫ」）ポートビットマスクを図示する。 開示されている主題のいくつかの実装形態による、ＳＲ−ＩＯＶデータポート接続性を説明する図である。 開示されている主題のいくつかの実装形態による、ＳＲ−ＩＯＶコアマッピングを説明する図である。 既存の負荷分散方法を説明する図である。 開示されている主題のいくつかの実施形態による、モバイルコンテンツクラウド（「ＭＣＣ」）を使用する非プロキシアプリケーションのための負荷分散ハッシュ化を説明する図である。 開示されている主題のいくつかの実施形態による、スタンドアロンパケットデータネットワークゲートウェイ（「ＰＧＷ」）およびスタンドアロンサービングゲートウェイ（「ＳＧＷ」）を有する非プロキシＭＣＣアプリケーションのための負荷分散ハッシュ化を説明する図である。 開示されている主題のいくつかの実施形態による、「Ｇ_ｉ」ゲートウェイとしてＭＣＣを使用する非プロキシアプリケーションのための負荷分散ハッシュ化を説明する図である。 開示されている主題のいくつかの実施形態による、信頼できる無線アクセスゲートウェイ（「ＷＡＧ」）を使用する非プロキシアプリケーションのための負荷分散ハッシュ化を説明する図である。 開示されている主題のいくつかの実施形態による、インターネットプロトコルセキュリティ（「ＩＰｓｅｃ」）暗号化を用いた信頼できるＷＡＧを使用する非プロキシアプリケーションのための負荷分散ハッシュ化を説明する図である。 開示されている主題のいくつかの実施形態による、進化したパケットデータゲートウェイ（「ｅＰＤＧ」）を使用した負荷分散ハッシュ化を説明する図である。 開示されている主題のいくつかの実施形態による、プロキシトラフィックアプリケーションのための負荷分散ハッシュ化を説明する図である。 開示されている主題のいくつかの実施形態による、プロキシおよび非プロキシマルチプロトコルラベルスイッチング（「ＭＰＬＳ」）トラフィックアプリケーションのための負荷分散ハッシュ化を説明する図である。 開示されている主題のいくつかの実施形態による例示的なネットワークアーキテクチャを説明する図である。 開示されている主題のいくつかの実施形態による、ＭＣＣの例示的構成を説明する図である。 開示されている主題のいくつかの実施形態によるセッションを確立することに関するフロー図である。 開示されている主題のいくつかの実施形態によるセッションを確立するための方法を説明するフローチャートである。 開示されている主題のいくつかの実施形態によるアップストリームデータパケットを処理するための方法を説明するフローチャートである。 開示されている主題のいくつかの実施形態によるダウンストリームデータパケットを処理するための方法を説明するフローチャートである。 開示されている主題のいくつかの実施形態による、プロキシサービスを含むデータパケットを処理するための方法を説明するフローチャートである。

本明細書に記載のいくつかの実施形態は、所与の無線加入者に対するパケット処理の単一の「パケットハンドラ」（パケット処理装置）のコアへの閉じ込め、または「ピン留め」に関し、それによって電気通信システムにおけるスループットを改善し、キャッシュミスの確率および発生率を低減する。例えば、パケットヘッダデータは、加入者のトンネルエンドポイント識別子（「ＴＥＩＤ」）および／またはセッション識別子（「セッションＩＤ」または「ワークフローセッションＩＤ」）を含むことができ、負荷分散装置コアは、一方または両方の識別子を使用して、パケットの双方向トラフィックが方向付けられるパケットハンドラ（パケット処理装置）コアを選択することができる。いくつかのそのような実施形態では、ハッシュ化アルゴリズムを使用して、多数のＵＥを多数のパケットハンドラコアの各々に分配し、多数のコアにわたって集合的な負荷を均衡させる。

他の実施形態は、区分されたマルチプロトコルラベルスイッチング（「ＭＰＬＳ」）ラベルスペースを使用して、システム開始プロキシトラフィックとダウンストリームＵＥ（例えば、非プロキシ）トラフィックとを区別することに関する。例えば、ＭＰＬＳラベルスペースは、ＵＥプールアドレスドメインと、プロキシループバックアドレスドメインと、に分割することができる。

アップストリームおよびダウンストリームのトラフィックを識別してルーティングするためのＴＥＩＤおよびワークフローセッションＩＤの使用
アクセスネットワークとパケットデータネットワークとの間で電気通信トラフィックをルーティングする従来の方法は、パケット送信元データおよびパケット宛先データ上のパケット処理コアの選択に基づいていた。対照的に、本開示の実施形態では、所与の無線加入者のユーザ機器（「ＵＥ」）について、ネットワークのアクセス側から受信されたパケットおよびインターネットコアから来る対応する応答パケットが識別され、対応する加入者のトンネルエンドポイント識別子（「ＴＥＩＤ」）およびワークフローセッションＩＤに基づいて、処理コアにルーティングされる。ＤＰＤＫ負荷分散装置コアは、特定のコアを選択／割り当てするためにＴＥＩＤおよびワークフローセッションＩＤの共通の値（例えば、それぞれの最初の２４ビット）を使用し、それによって、ワークフローセッションＩＤに対応するＵＥ加入者セッションがアクティブである限り、そのＵＥのパケット処理をそのコアにピン留めする。いくつかの実装形態では、ＴＥＩＤは、モビリティ管理エンティティ（「ＭＭＥ」）または進化したノードＢ（「ｅＮｏｄｅＢ」）と本開示のＭＣＣとの間でネゴシエートされる加入者特有の識別子である。例えば、いくつかの実施形態では、初期の「セッション作成」要求がＭＭＥ／ｅＮｏｄｅＢからＭＣＣに送信される。ＭＣＣは、ワークフローセッションＩＤ（例えば２４ビット）、ワークフローセッションＩＤを含むトンネリングＩＤ（「ＴＥＩＤ」）（例えば、２４ビットのワークフローセッションＩＤを含む３２ビット）、およびＵＥのＩＰアドレスを割り当てる。言い換えれば、ワークフローセッションＩＤの割り当ては、ＴＥＩＤの最初の２４ビットをワークフローセッションＩＤの２４ビットとして複製することを含むことができる（各々の最初の２４ビットが一致するのを確実にする）。ＭＣＣにおけるこれらの割り当ては、本明細書に記載の１つ以上のシステムによって実行することができる。ＭＣＣは、ＴＥＩＤおよびＵＥのＩＰアドレスをＭＭＥ／ｅＮｏｄｅＢに返送し、ＭＭＥ／ｅＮｏｄｅＢは修正されたＴＥＩＤをＭＣＣに返送する。いくつかのそのような実施形態では、修正されたＴＥＩＤは、元々提案されたＴＥＩＤのＴＥＩＤと同じ２４ビットのワークフローセッションＩＤを含む。関連付けられたセッション中に、指定されたユーザに割り当てられたデータパケットの識別および／またはルーティングのために後で使用される最終的なＴＥＩＤをもたらすのは、ＭＭＥ／ｅＮｏｄｅＢとＭＣＣとの間のこの往復のネゴシエーションである。ＭＣＣにおいて、最終的なＴＥＩＤは、後で使用するために、制御プレーンからＷＳＭおよびデータプレーン内の１つ以上のＩＯＭに転送される。ＴＥＩＤは、入出力多重化（「ＩＯＭ」）段階でパケットヘッダに追加することができる。ネゴシエートされたＴＥＩＤが確立されると、１つ以上のＵＥから発信されて、ＴＥＩＤを含むヘッダを有する加入者データパケットを、事実上、ＭＣＣへＧＴＰ−Ｕトンネリングすることができる。次いで、ハッシュ化アルゴリズムをパケットヘッダに対して使用して、利用可能なすべてのコアにわたって多数のＵＥを割り当てるまたは分配することができる。

図１４は、いくつかの実施形態による例示的なネットワークアーキテクチャを説明する図である。ユーザ機器（「ＵＥ」）１４０２は、ｅＮｏｄｅＢ１４０４と通信し、ｅＮｏｄｅＢ１４０４は、次にモビリティ管理エンティティ（「ＭＭＥ」）１４０６およびモバイルコンテンツクラウド（「ＭＣＣ」）１４１６と通信する。ＭＣＣ１４１６は、サービングゲートウェイ（「ＳＧＷ」）１４０８、パケットデータネットワークゲートウェイ（「ＰＧＷ」）１４１０、一連のワークフローサービスモジュール（「ＷＳＭ」）、および一連の入力／出力マルチプレクサ（「ＩＯＭ」）１４１４を含む、いくつかの論理ノードを含む。ＭＣＣ１４１６は、インターネット１４２２などのパケットデータネットワークにさらに接続されており、それを介して、ＭＣＣ１４１６は、外部サーバ１４２４にアクセスすることができる。ＭＣＣ１４１６は、ＵＥ１４０２に関連付けられているアップストリームデータパケット１４１８を受信する。ＭＣＣ１４１６はまた、ＵＥ１４０２に関連付けられているダウンストリームパケット１４２０も受信する。いくつかの実施形態では、アップストリームパケットは、一般にＵＥ１４０２から流れ出るパケットを指し、ダウンストリームパケットは、一般にＵＥ１４０２に向かって流れるパケットを指す。以下でさらに詳細に説明するように、ＭＣＣ１４１６は、ＴＥＩＤ、ＵＥのＩＰアドレス、およびセッションＩＤを使用して、ＵＥ１４０２に関連付けられたアップストリームおよびダウンストリームパケットの両方のルーティングおよび処理をＭＣＣ内の一定のパケットハンドラコアにピン留めする。

図１５は、ＭＣＣ１４１６の例示的構成を説明する図である。ＭＣＣ１４１６は、１つ以上の物理的または仮想的処理コアを有する処理マシン上に実装することができる。図示のように、論理ノードは、スイッチ１５０２を介して接続されている。例えば、一連のワークフローサービスモジュール（「ＷＳＭ」）１４１２、一連の入力／出力マルチプレクサ（「ＩＯＭ」）１４１４、および一連のＳＧＷ１４０８／ＰＧＷ１４１０モジュールのための論理ノードがスイッチ１５０２に接続されている。一連のワークフローサービスモジュール（「ＷＳＭ」）１４１２の各々は、負荷分散コア（「ＬＢＣ」）１５０４および一連のパケットハンドラコア（「ＰＨＣ」）１５０６を含む。入力／出力マルチプレクサは、アップストリームデータパケット１４１８およびダウンストリームデータパケット１４２０を受信するように構成されている。一連の入力／出力マルチプレクサ（「ＩＯＭ」）１４１４の各々はまた、特定のＷＳＭおよびＰＨＣを選択して着信データパケットに割り当てるために使用される１つ以上のテーブルを含む。

図１６は、いくつかの実施形態によるフロー図を図示する。ステップ１６０２において、ＭＣＣ１４１６は、ＭＭＥ１４０６からユーザデバイスのためのセッションを作成する要求を受信する。要求は、ＭＣＣ１４１６が、ユーザデバイスに向けられたダウンストリームトラフィックのために後で使用するＴＥＩＤ（「ＴＥＩＤ＿Ｄ」と表記される）を含む。ステップ１６０４で、ＭＣＣ１４１６は、新しいセッションに関連付けられ、ユーザデバイスに関連付けられたアップストリームトラフィックのためにｅＮｏｄｅＢ１４０４／ＭＭＥ１４０６によって使用されることになるＴＥＩＤ（「ＴＥＩＤ＿Ｕ」と表記される）を作成する。ＭＣＣ１４１６はまた、新しいセッションに関連付けられているセッションＩＤを作成する。いくつかの実施形態では、ＴＥＩＤ＿ＵおよびセッションＩＤは、共通の値を共有する。例えば、ＴＥＩＤ＿Ｕの最初の２４ビットは、セッションＩＤの最初の２４ビットと一致してもよい。ＴＥＩＤ＿ＵおよびセッションＩＤが作成されると、ＭＣＣ１４１６は、新たに作成されたＴＥＩＤ＿Ｕが新たに作成されたセッションＩＤに対応することをＭＣＣ１４１６内のすべてのＩＯＭに通知する。いくつかの実施形態では、個々のＩＯＭは、この情報の記録をテーブルに保存し得る。

ＭＣＣ１４１６はまた、新しいセッションに関連付けられているＵＥのＩＰアドレスも割り当てる。このＵＥのＩＰアドレスは、インターネット１４２２などの外部データネットワークへの発信トラフィックに対する送信元ＩＰアドレスとして使用される。それはまた、外部データネットワークからユーザデバイスへの着信トラフィックの宛先ＩＰアドレスとしても使用される。ＵＥのＩＰアドレスを作成すると、ＭＣＣ１４１６は、新たに作成されたＵＥのＩＰアドレスが新たに作成されたセッションＩＤと相関していることをＭＣＣ１４１６内のすべてのＩＯＭに通知する。いくつかの実施形態では、個々のＩＯＭは、この相関の記録をテーブルに保存し得る。ステップ１６０６において、ＭＣＣ１４１６は、ｅＮｏｄｅＢ１４０４／ＭＭＥ１４０６にセッション作成応答を送信する。セッション作成応答は、ＴＥＩＤ＿Ｕを含む。

ステップ１６０８において、ＭＣＣは、ｅＮｏｄｅＢ１４０４／ＭＭＥ１４０６からアップストリームデータパケットを受信する。アップストリームデータパケットは、以前に確立されたＴＥＩＤ＿Ｕを含む。ステップ１６１０において、ＭＣＣ１４１６は、ＴＥＩＤ＿Ｕに対応するセッションＩＤを識別する。いくつかの実施形態では、ＩＯＭは、ＴＥＩＤ＿Ｕをテーブルへのインデックスとして使用することによってセッションＩＤを識別する。次いで、ＩＯＭは、アップストリームデータパケットを処理するためにセッションＩＤに基づいて、ワークフローサービスモジュール（「ＷＳＭ」）を選択し、アップストリームデータパケットを選択されたＷＳＭにルーティングする。ＷＳＭは、セッションＩＤに基づいて、特定のパケットハンドラコア（「ＰＨＣ」）を選ぶ。いくつかの実施形態では、セッションＩＤに基づいて、アップストリームデータパケットをＰＨＣに分配するためにハッシュ化アルゴリズムが使用される。ステップ１６１２において、アップストリームデータパケットは、外部データネットワーク（例えば、インターネット１４２２）内のその宛先アドレスにルーティングされる。

ステップ１６１４において、ＭＣＣ１４１６は、ＵＥのＩＰアドレスを含むダウンストリームデータパケットを受信する。ＵＥのＩＰアドレスは、ダウンストリームデータパケットがデバイスユーザに関連付けられていることを指し示す。ステップ１６１６において、ＭＣＣ１４１６は、ＵＥのＩＰアドレスに対応するセッションＩＤを識別する。いくつかの実施形態では、ＩＯＭは、ＵＥのＩＰアドレスをテーブルへのインデックスとして使用することによってセッションＩＤを識別する。その後、ＩＯＭは、ダウンストリームデータパケットを処理するためにセッションＩＤに基づいて、ワークフローサービスモジュール（「ＷＳＭ」）を選択し、ダウンストリームデータパケットを選択されたＷＳＭにルーティングする。ＷＳＭは、セッションＩＤに基づいて、特定のパケットハンドラコア（「ＰＨＣ」）を選ぶ。いくつかの実施形態では、セッションＩＤに基づいて、ダウンストリームデータパケットをＰＨＣに分配するためにハッシュ化アルゴリズムが使用される。このダウンストリームデータパケット用に識別されたセッションＩＤは、アップストリームデータパケット用に識別されたセッションＩＤと一致するので、デバイスユーザに関連付けられたトラフィックは、特定のパケットハンドラコアに閉じ込めまたは「ピン留め」される。代替的に、いくつかの実施形態では、ステップ１６１４で受信されたＵＥのＩＰアドレスは、パケットハンドラコアに直接マッピングされる。例えば、ＩＯＭは、ＵＥのＩＰアドレスを対応するセッションＩＤに対して以前に識別されたパケットハンドラコアと相関させるテーブルを保持してもよい。パケットハンドラコアは、ダウンストリームデータパケットを処理する。ステップ１６１８において、ダウンストリームデータパケットは、ＴＥＩＤ＿Ｄを使用して、ｅＮｏｄｅＢ１４０４／ＭＭＥ１４０６にルーティングされる。

図１７は、いくつかの実施形態によるセッションを確立するための方法を説明するフローチャートである。ステップ１７０２において、セッションを作成する要求が受信される。ステップ１７０４において、両方とも新しいセッションに関連付けられたＴＥＩＤ＿ＵおよびセッションＩＤが作成される。ステップ１７０６において、ＩＯＭは、相関付けされたＴＥＩＤ＿ＵとセッションＩＤとを通知される。いくつかの実施形態では、ＩＯＭは、この相関の記録をテーブルに保存し得る。ステップ１７０８において、新しいセッションに対応するＵＥのＩＰアドレスが作成される。ステップ１７１０において、ＩＯＭは、ＵＥのＩＰアドレスと、その新しいセッションおよびセッションＩＤとの相関関係とを通知される。いくつかの実施形態では、個々のＩＯＭは、この相関の記録をテーブルに保存し得る。いくつかの実施形態では、ＵＥのＩＰアドレスは、パケットハンドラコアに直接マッピングされる。ステップ１７１２で、ＴＥＩＤ＿Ｕを含むセッション作成応答が送信される。

図１８は、いくつかの実施形態によるアップストリームデータパケットを処理するための方法を説明するフローチャートである。ステップ１８０２において、アップストリームデータパケットが受信される。アップストリームデータパケットは、セッションＩＤに対応するＴＥＩＤ＿Ｕを含む。ステップ１８０４において、ＴＥＩＤ＿Ｕが、アップストリームデータパケットから抽出される。ステップ１８０６において、ＴＥＩＤ＿Ｕに対応するセッションＩＤが、ルックアップテーブルに基づいて、識別される。ステップ１８０８において、アップストリームデータパケットが、識別されたセッションＩＤに基づいて、ＷＳＭに割り当てられる。ステップ１８１０において、アップストリームデータパケットが、セッションＩＤに基づいて、パケットハンドラコアにさらに割り当てられる。いくつかの実施形態では、アップストリームデータパケットは、セッションＩＤのハッシュ値に基づいて、特定のパケットハンドラコアに割り当てられる。

図１９は、いくつかの実施形態によるダウンストリームデータパケットを処理するための方法を説明するフローチャートである。ステップ１９０２において、ダウンストリームデータパケットが受信される。ダウンストリームデータパケットは、セッションＩＤに対応するＵＥのＩＰアドレスを含む。ステップ１９０４において、ＵＥのＩＰアドレスが、ダウンストリームデータパケットから抽出される。ステップ１９０６において、ＵＥのＩＰアドレスに対応するセッションＩＤが、ルックアップテーブルに基づいて、識別される。ステップ１９０８において、ダウンストリームデータパケットが、識別されたセッションＩＤに基づいて、ＷＳＭに割り当てられる。ステップ１９１０において、アップストリームデータパケットが、セッションＩＤに基づいて、パケットハンドラコアにさらに割り当てられる。いくつかの実施形態では、ダウンストリームデータパケットは、セッションＩＤのハッシュ値に基づいて、特定のパケットハンドラコアに割り当てられる。

インターネットコアに面するインターフェース上でシステム開始プロキシトラフィックからＵＥトラフィックを区別するためのＭＰＬＳラベルスペースの分割
いくつかの実施形態では、マルチプロトコルラベルスイッチング（「ＭＰＬＳ」）がコア側で使用されるとき、ダウンストリームＵＥトラフィックからシステム開始プロキシトラフィックを区別するために、ＭＰＬＳラベルスペースを２つの異なるドメイン：ＵＥプールアドレスドメインと、プロキシループバックアドレスドメインと、に分割することができる。所与のＵＥのＩＰアドレスに対応するスタティックルートは、ＵＥドメインからのラベルを使用して、アドバタイズすることができ、プロキシループバックアドレスに対応するスタティックルートは、マルチプロトコルボーダーゲートウェイプロトコル（「ＭＰ−ＢＧＰ」）によってループバックアドレスドメインからのラベルを使用して、アドバタイズすることができる。ＤＰＤＫ負荷分散装置コアは、次いでラベル範囲情報を使用して、ダウンストリームＵＥトラフィックからプロキシトラフィックを区別することができる。例えば、ダウンストリームプロキシトラフィックパケットが５タプル値（例えば、送信元アドレス、宛先アドレス、送信元ポート、宛先ポート、およびイーサタイプのうちの１つ以上）に基づいて、負荷分散されるとき、ＵＥパケットはセッションＩＤに基づいて、負荷分散することができる。

ダウンストリームプロキシトラフィックをピン留めするためのＩＰｖ４送信元ネットワークアドレス変換（「ＮＡＴ」）アドレス内へのコアＩＤ情報の埋め込み
システムが加入者／ＵＥに対するプロキシサービスを識別すると、その加入者／ＵＥからのすべてのパケットは、プロキシサービスのために付加価値サービス（「ＶＡＳ」）モジュールに導かれる。ワークフローサービスモジュールは、ＩＰｖ４ベースの送信元ＮＡＴを使用して、ＶＡＳモジュールと通信する。ＮＡＴアドレスの３番目のバイトは、コアＩＤ情報を搬送するためにエンコードされている。リターンパスでは、ワークフローサービスモジュール上の負荷分散装置コアがＮＡＴアドレスからコア情報を抽出し、ダウンストリーム処理のための対応するコアにパケットを導く。これは、確実にアップストリームおよびダウンストリームのＵＥプロキシトラフィックが同じコアで処理され、Ｌ２キャッシュの利用率を最大化し、システムのパフォーマンスを向上するようにする。

従来のソリューションは、パケットコアをピックアップするためのハッシュ値としてのＵＥアドレスに基づいていた。しかし、このソリューションは、様々なサービスプラットフォームにわたって機能しなかった。さらに、ワークフローサービスモジュールでのプロキシトラフィック負荷分散、ならびにＭＰＬＳラベルに基づいて、プロキシ対プロキシなしのダウンストリームトラフィックを識別するためのソリューションはなかった。

ＴＥＩＤとセッションＩＤとに基づいて、ＵＥトラフィックをピン留めすることは、データスループットを向上させるためのすべてのサービスプラットフォームにわたる包括的なソリューションである。ＭＰＬＳラベルを使用して、ダウンストリームＵＥトラフィックを識別し、コア情報をＮＡＴアドレスに埋め込むことは、ＵＥを特定のコアに結びつけることのさらなる補助となり、それによってより良好なユーザエクスペリエンスを強化する。

ここで図面に目を向けると、図１は、開示されている主題のいくつかの実施形態による、マルチコア通信ネットワークを通るパケットフローを説明する図である。例えば、ＷＳＭモジュール、ＩＯＭモジュール、または組み合わされたＷＳＭ／ＩＯＭモジュールは、図示のように実装され得る。図１に示すように、マルチコアシステム１００は、デバイス層、入力／出力（「Ｉ／Ｏ」）層、およびパケットハンドラ層（本明細書では「高速経路」層とも呼ばれる）を含む。一般に、本明細書で使用されるとき、データセンター内のあるサーバから発信されて別のサーバへと通るパケットは、東西（「Ｅ／Ｗ」）方向に進み、Ｅ／Ｗポート（１１２Ａ、１１２Ｂ）を通過すると言われる。一方で、モバイルデバイスまたはコンピュータなどの、ネットワーク加入者のユーザ機器（ＵＥ）とパケットデータネットワーク宛先（例えばインターネット）との間を通過するパケットは、南北（「Ｎ／Ｓ」）方向に進み、Ｎ／Ｓポート（１１４Ａ、１１４Ｂ）を通過すると言われる。マルチコアシステム１００では、Ｅ／Ｗポート１１２ＢおよびＮ／Ｓポート１１４Ｂは、任意選択的である。パケットトラフィックがＥ／ＷであるかＮ／Ｓであるかにかかわらず、対応するパケットは、データプレーン開発キット（「ＤＰＤＫ」）ポールモードドライバ（１１０Ａ、１１Ｂ）を介してＩ／Ｏ層に渡され、受信（Ｒｘ）コア（１０６Ａ、１０６Ｂ）によってＩ／Ｏ層内で受信される。Ｒｘコアは、それに動作可能に結合された関連負荷分散装置（「ＬＢ」）コア（１０４Ａ、１０４Ｂ）にパケットを渡す。次に、ＬＢコアは、それぞれのＬＢコアによって修正されている場合があるパケットを、サービス品質（「ＱｏＳ」）キューを介して複数のパケットハンドラ（「ＨＤ」）コア（１０２Ａ、１０２Ｂ）のうちの１つに渡す。多重パケットハンドラコア（例えば、高速経路層内の）の利用可能性およびそれを介したルーティングにより、パケットデータサブセットは、同じデータサブセットに対して調整されていない編集が行われているために破損する可能性があり、データ破損のリスクを軽減するために、データ構造を「ロック」するためのメカニズムが必要となり得る。処理のために要求されたデータがキャッシュメモリ内で見つからないというキャッシュミスも、パケットが多重コアを介してルーティングされるときに発生する可能性があり、処理の遅延をもたらす。本明細書で説明する技法を使用すると、キャッシュミスおよびロッキングメカニズムの必要性は、所与の加入者／ＵＥに対するパケットトラフィックをマルチコアシステム内の単一のパケットハンドラコアに「ピン留め」することによって低減または排除され、そのため、すべての対応するノースバウンドトラフィックとサウスバウンドトラフィックは、同じパケットハンドラコアを通過する。本明細書に記載の方法は、プロキシアプリケーションに対しても実装することができる。例えば、Ｎ／Ｓポート１１４を介してＵＥから来るパケットは、Ｒｘコア１０６Ｂを通過し、次いでＬＢコア１０４Ｂへと通過し得る。ＬＢコア１０４Ｂは、パケットハンドラコア（１０２Ｂ）のうちの１つをパケットに割り当てることができる。また、パケットがプロキシパケットであると判定すると、ＬＢコア１０４Ｂは、パケットの内部ネットワークアドレス変換（「ＮＡＴ」）変換を実行して、パケットが処理のために内部プロキシにルーティングされるように指示するＩＰアドレスおよび送信元ポートを埋め込むことができる。パケットを処理している間、パケットハンドラコア１０２Ｂは、（例えば、ＬＢコア１０４Ｂによってパケットに対して行われた修正に基づいて）そのパケットがプロキシパケットであると判定し、処理のために、パケットハンドラコア１０２Ｂと同じ場所にあるか、またはそれから離れている別のサーバにパケットを転送することができる。リターンパスを定義するために、サーバは、パケットがパケットハンドラコア１０２Ｂを介してＮ／Ｓポート１１４Ａに確実にルーティングバックされるようにするために、パケットからＩＰアドレスおよび宛先ポート番号を抽出する。

図２は、開示されている主題のいくつかの実施形態による、単一ルート入力／出力仮想化（「ＳＲ−ＩＯＶ」）を使用するＤＰＤＫポート２２０−ビットマスクを図示する。いくつかの実装形態では、システムは、内部使用のために、どのポートがＮ／Ｓポートであり、どのポートがＥ／Ｗポートであるかのマッピングを格納する。このマッピングは、各イーサネットポートを「Ｇ_ｉ」（例えば、インターネットに面する）ポートまたは「Ｇ_ｎ」（例えば、加入者からのトラフィック）ポートとして定義するために使用することができる。ＸＭＬコードで書かれた、このポートマッピングのスニペットの例は次のとおりである。
／ｅｔｃ／ｐｌａｔｆｏｒｍ／ｐｌａｔｆｏｒｍ．ｘｍｌ
ｐｌａｔｆｏｒｍ．ｘｍｌ−＞／ｅｔｃ／ｐｌａｔｆｏｒｍ／ｐｌａｔｆｏｒｍ＿ＳＲＩＯＶ＿ＲＥＤ．ｘｍｌ
＜！−−Ｖａｒｉａｂｌｅｓ ｆｏｒ ＤＰＤＫ−−＞
＜ｄｐｄｋ＞
＜ｓｒｉｏｖ＞ｔｒｕｅ＜／ｓｒｉｏｖ＞
＜ｌｏａｄｂａｌＤｐｄｋＰｏｒｔｓ＞３ｃ＜／ｌｏａｄｂａｌＤｐｄｋＰｏｒｔｓ＞
＜ｌｏａｄｂａｌＴｈｒｅａｄｓＣｏｕｎｔ＞１＜／ｌｏａｄｂａｌＴｈｒｅａｄｓＣｏｕｎｔ＞
＜ｌｏａｄｂａｌＨｕｇｅＰａｇｅＳｉｚｅ＞２５＜／ｌｏａｄｂａｌＨｕｇｅＰａｇｅＳｉｚｅ＞
＜ｌｏａｄｂａｌＨｕｇｅＰａｇｅＣｏｕｎｔ＞１５００＜／ｌｏａｄｂａｌＨｕｇｅＰａｇｅＣｏｕｎｔ＞
＜ｌｏａｄｂａｌＣｏｒｅＣｏｕｎｔ＞ｆｆｆｆｆｆｆ０＜／ｌｏａｄｂａｌＣｏｒｅＣｏｕｎｔ＞
＜ｌｏａｄｂａｌＩｏＣｏｒｅＰｏｒｔＭａｓｋ０＞２４＜／ｌｏａｄｂａｌＩｏＣｏｒｅＰｏｒｔＭａｓｋ０＞
＜ｌｏａｄｂａｌＩｏＣｏｒｅＰｏｒｔＭａｓｋ１＞１８＜／ｌｏａｄｂａｌＩｏＣｏｒｅＰｏｒｔＭａｓｋ１＞
＜ｌｏａｄｂａｌＩｏＦｃｔＧｒｏｕｐｉｎｇ＞ａｌｌ−ｓｅｐａｒａｔｅｄ＜／ｌｏａｄｂａｌＩｏＦｃｔＧｒｏｕｐｉｎｇ＞
＜ｗｏｒｋｆｌｏｗＤｐｄｋＰｏｒｔｓ＞２４＜／ｗｏｒｋｆｌｏｗＤｐｄｋＰｏｒｔｓ＞
＜ｗｏｒｋｆｌｏｗＴｈｒｅａｄｓＣｏｕｎｔ＞１＜／ｗｏｒｋｆｌｏｗＴｈｒｅａｄｓＣｏｕｎｔ＞
＜ｗｏｒｋｆｌｏｗＨｕｇｅＰａｇｅＳｉｚｅ＞２５＜／ｗｏｒｋｆｌｏｗＨｕｇｅＰａｇｅＳｉｚｅ
＜ｗｏｒｋｆｌｏｗＨｕｇｅＰａｇｅＣｏｕｎｔ＞１５００＜／ｗｏｒｋｆｌｏｗＨｕｇｅＰａｇｅＣｏｕｎｔ＞
＜ｗｏｒｋｆｌｏｗＣｏｒｅＣｏｕｎｔ＞ｆｆｆｆｆｆｆ０＜／ｗｏｒｋｆｌｏｗＣｏｒｅＣｏｕｎｔ＞
＜ｗｏｒｋｆｌｏｗＩｏＣｏｒｅＰｏｒｔＭａｓｋ０＞２４＜／ｗｏｒｋｆｌｏｗＩｏＣｏｒｅＰｏｒｔＭａｓｋ０＞
＜ｗｏｒｋｆｌｏｗＩｏＦｃｔＧｒｏｕｐｉｎｇ＞ａｌｌ−ｓｅｐａｒａｔｅｄ＜／ｗｏｒｋｆｌｏｗＩｏＦｃｔＧｒｏｕｐｉｎｇ＞

図３は、開示されている主題のいくつかの実装形態による、ＳＲ−ＩＯＶデータポートの接続性を説明する図である。図３に示すように、冗長Ｅ／Ｗスイッチ（３１２Ａ、３１２Ｂ）および冗長Ｎ／Ｓスイッチ（３１４Ａ、３１４Ｂ）は各々、複数のサーバ３２２（例えば、Ｃ７０００ブレードサーバ）に動作可能に結合されている。いくつかの実装形態では、各サーバ３２２は、単一のＮ／Ｓスイッチに接続されている。各スイッチは、多数の関連した仮想機能（「ＶＦ」）を有する単一の物理機能（「ＰＦ」：３２８Ａ〜３２８Ｄ）を有することができ、これらのＶＦは、関連ＶＭのインスタンス化時に各ＰＦにマッピングすることができる。各サーバ３２２は、以下のような多重仮想マシン（「ＶＭ」）を含むことができる。（１）デジタル制御モジュール「ＤＣＭ」ＶＭ３２４、例えば、内部仮想マシンであるためＥ／Ｗスイッチにのみ接続されている、（２）入力／出力マルチプレクサ「ＩＯＭ」ＶＭ３２６。各ＶＭは、図３に示すように、複数の論理インターフェース（「Ｅｔｈ−３」、「Ｅｔｈ−４」など）を含むことができ、例えば、関連するＶＭがインスタンス化されている場合は、これらの論理インターフェースをＧ_ｉまたはＧ_ｎインターフェースとして割り当てることができる。いくつかの実施形態では、各ＶＦは、ただ１つのそのような論理インターフェースに対応する。

図４は、開示されている主題のいくつかの実装形態による、ＳＲ−ＩＯＶコアマッピングを説明する図である。図４に提示されているように、コア０〜３は、ＶＭ上で実行されるＬｉｎｕｘオペレーションのために予約されている。コア４は、初期化中にＤＰＤＫ（Ｉｎｔｅｌ提供のライブラリ）によって使用され、その後Ｌｉｎｕｘ（登録商標）へとリリースされる。コア５は、バッファプールを定期的に監視するためにＤＰＤＫによって使用され、それ以外の場合はＬｉｎｕｘ（登録商標）によって使用される。図２を参照して先に図示および説明したように、コア６、８および１０は、それぞれ、ポートマスクグループ０に対応するＥ／Ｗファブリックポート用のＲｘ、Ｔｘ、およびＬＢに対応する。図２を参照して先に図示および説明したように、コア７、９および１１は、それぞれ、ポートマスクグループ１に対応するＮ／Ｓファブリックポート用のＲｘ、Ｔｘ、およびＬＢに対応する。コア１２〜１９（合計７コア）は、パケット処理用に使用される。コア１０および１１は、負荷分散アルゴリズムを含み、負荷分散は、コア１２〜１９にわたって実装されている。

一部の既存の設定では、デフォルトの負荷分散アルゴリズムは、送信元アドレスと宛先アドレスに基づいており、２段階で実行される。第１の段階において、ＬＢコアは、イーサタイプに基づいて、内部ＩＰパケットに対するプロトコルを判定する。ＭＰＬＳパケットはこの段階中に識別することができ、負荷分散アルゴリズムは、内部ＩＰパケットに対して５タプルに設定することができる。ファブリックパケットおよび他のパケット（または「ペイロード」）タイプは、イーサタイプを調べることによって識別することができる。イーサタイプは、ＩＯＭとＷＳＭとの間のパケットのルーティングの目的で、ならびにパケットの方向性（例えば、インターネット境界またはアクセス側境界）を判定するために、および／または、どのプロトコルがイーサネットフレームのペイロードでカプセル化されているかを示すために使用することができる。例えば、ＩＯＭは、ＵＥから受信したパケットを抽出し、宛先ＷＳＭ用のＭＡＣアドレスを判定し、パケットにイーサネットヘッダを追加して、パケットが確実に宛先ＷＳＭに適切に切り換え／ルーティングされるようにすることができる。

ここで図５を参照すると、ワークフローサービスモジュール（「ＷＳＭ」）５３０上で、汎用パケット無線サービス（ＧＰＲＳ）トンネリングプロトコル（「ＧＴＰ」）ネットワークフローモジュールからワークフローモジュールへ（ＧＮＦＭからＷＦＭ）（すなわち、ＵＥからインターネットへのパケットの進行−ＩＯＭ５２６ＡからＷＳＭ５３０を指す矢印を参照）のイーサタイプに対して、負荷分散アルゴリズムによって規定されるルーティングは、送信元アドレス（「ＳｒｃＡｄｄｒ」）または送信元アドレスと宛先アドレスとの組み合わせ（「（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒ」または「（Ｓ＋Ｄ）Ａｄｄｒ」）に基づくことができる。ＩＯＭ５２６Ｂ上で、ＷＦＭからＧｉＦＭへのイーサタイプに対して（ＷＳＭ５３０からＩＯＭ５２６Ｂを指す矢印を参照）のイーサタイプに対して、負荷分散アルゴリズムによって規定されるルーティングは、送信元アドレス（「ＳｒｃＡｄｄｒ」）または５タプルに基づくことができる。第２の段階において、第１の段階中に内部ＩＰパケットのプロトコルを判定したＬＢコアは、総称ルーティングカプセル化（「ＧＲＥ」）、カプセル化セキュリティペイロード（「ＥＳＰ」）、レイヤ２トンネリングプロトコル（「Ｌ２ＴＰ」）、および／または汎用パケット無線サービス（ＧＰＲＳ）トンネリングプロトコル（「ＧＴＰ」）パケットを識別する。いくつかの実装形態では、パケットはダウンストリームＵＥパケットであると想定されているので、Ｌ２ＴＰパケットは宛先アドレス（「ＤｓｔＡｄｄｒ」または「ＤＡｄｄｒ」）に基づいて、負荷分散されている。このような負荷分散は、図５のＧｉＦＭからＷＦＭへの矢印で示されるＩＰパケットにも適用することができる。ＧＴＰ−Ｕパケットの場合（すなわち、ＧＴＰパケットがユーザデータを搬送している−ＷＳＭ５３０からＩＯＭ５２６Ａを指す矢印を参照）、負荷分散アルゴリズムによって規定されるルーティングは、ＳｒｃＡｄｄｒまたは（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒに基づくことができる。プロトコルがＥＳＰである場合、負荷分散アルゴリズムによって規定されたルーティングは、ラウンドロビンまたは（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒに基づくことができる。しかしながら、この段落で説明されているアプローチを使用すると、着信プロキシパケットをダウンストリームＵＥパケットから区別するためのメカニズムはＧ_ｉインターフェースにはない。どちらの場合も、負荷分散は、５タプルを使用して実行される。ＩＰフラグメントを受信した場合、この方法は機能しない可能性がある。さらに、スタンドアロンのＳＧＷ／ＰＧＷアプリケーションの場合、パケットがＳＧＷとＰＧＷのどちらを対象としているかについて、Ｓ５／Ｓ８インターフェース上に区別はない。ＧＴＰ−Ｕパケットは、（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用して、負荷分散される。ＷＳＭ／ＳＳＭでは、ダウンストリームＵＥプロキシパケットは、５タプルを使用して、負荷分散される。ＮＡＴ変換により、ＵＥアドレスは、ＤＰＤＫレベルでは利用可能ではない。

上述したように、既存の通信アーキテクチャでは、アクセスネットワークからＷＳＭに到着するパケットは、識別され、送信元および宛先アドレスに基づいて、１つ以上のパケット処理コアにルーティングされ、パケットデータネットワークからＷＳＭに到着するパケットは識別され、および／または宛先アドレスによってルーティングされる。そのような設計は、それらがすべてのネットワークアーキテクチャと互換性があるというわけではないという点で、柔軟性を欠いている。対照的に、本明細書に記載の方法では（例えば、以下の例示的な実施形態では）、アクセスネットワークからＷＳＭに到着するパケットは識別され、ＴＥＩＤに基づいて、１つ以上のパケット処理コアにルーティングされ、パケットデータネットワークからＷＳＭに到着するパケットは識別され、セッションＩＤに基づいて、１つ以上のパケット処理コアにルーティングされる。ＴＥＩＤとセッションＩＤは、各々同じ最初の２４ビットを含む。その結果、本明細書に記載の方法およびシステムの（パケットの観点からの）負荷分散機能は、ネットワーク構成とは無関係の様式で実装することができる。

本明細書で使用する場合、「汎用パケット無線サービス（ＧＰＲＳ）トンネリングプロトコル（「ＧＴＰ」）ネットワークフローモジュールからワークフローモジュールへ」のイーサタイプを略した、「ＧｎＦＭからＷＦＭへ」のイーサタイプは、ネットワークフローモジュール（例えば、ネットワークのアクセス／ユーザ側）とワークフローモジュールとの間の通信を容易にするためにユーザデータをカプセル化する任意のイーサタイプを指す。同様に、「ＷＦＭからＧｎＦＭへ」のイーサタイプは、ワークフローモジュールとネットワークフローモジュールとの間の通信を容易にするためにユーザデータをカプセル化する任意のイーサタイプを指す。

本明細書で使用されるとき、「ＷＦＭからＧｉＦＭへ」のイーサタイプは、ワークフローモジュールとインターネットに面するモジュール（例えば、パケットデータネットワークと通信するＩＯＭ）との間の通信を容易にするためにユーザデータをカプセル化する任意のイーサタイプを指す。同様に、「ＧｉＦＭからＷＦＭへ」のイーサタイプは、インターネットに面するモジュールとワークフローモジュールとの間の通信を容易にするためにユーザデータをカプセル化する任意のイーサタイプを指す。

本明細書で使用されるとき、「ＳＥＣＭからＳＥＣＭへ」のイーサタイプは、通信ネットワーク内のネットワーク化されたセキュリティモジュール間の通信を容易にする任意のイーサタイプを指す。

本明細書で使用されるとき、「ＳＥＣＭからＩＯＭへ」のイーサタイプは、通信ネットワーク内のセキュリティモジュールと入出力マルチプレクサモジュールとの間の通信を容易にする任意のイーサタイプを指す。

図６は、開示されている主題のいくつかの実施形態による、モバイルコンテンツクラウド（「ＭＣＣ」）１００内で行われる非プロキシ（例えば、ＵＥとインターネットとの間の直接パケットトラフィック）アプリケーションのための負荷分散ハッシュ化を説明する図である。図６に示すように、ＵＥから発信されてアクセスネットワーク６１５の「Ｓ１Ｕ」インターフェース／ポートに到着するデータパケットは、ＩＯＭ６２６ＡへＧＴＰ−Ｕトンネリングされる。ＩＯＭ６２６Ａにおけるパケットは、送信元および宛先アドレス（「（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒ」）のハッシュ化によって識別され、ネゴシエートされたＴＥＩＤ（ＧＴＰ−ＵヘッダトンネルＩＤ）を含む。いくつかの実装形態では、すべてのＩＯＭが、戻り宛先ＩＰアドレスに基づいて、ＵＥをセッションＩＤに関連付けるデータを受信する。ＴＥＩＤは、このＩＯＭ段階でパケットヘッダに追加される（例えば、制御プレーンのｅＮｏｄｅＢによって追加され、次にデータプレーン内のＩＯＭに送信される）。パケットは、（上記のように、汎用パケット無線サービス（ＧＰＲＳ）トンネリングプロトコル（「ＧＴＰ」）ネットワークフローモジュールからワークフローモジュールへを略した）ＧｎＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ６２６ＡによってＷＳＭ６３０上のＷＦＭへ（すなわち、ＷＳＭ６３０ＡのＩＰアドレスへ）転送される。パケットは、ＷＳＭ上の負荷分散装置コアによって受信され、ＷＳＭ６３０は、どのパケットハンドラコアをパケットに割り当てるべきかを判定する。ＧｎＦＭからＷＦＭへのパケットの中には、ＵＥパケットがあり、そこからＧＴＰヘッダを抽出することができる。ＧＴＰヘッダは、ＴＥＩＤ（その最初の２４ビットは、セッションＩＤの最初の２４ビットと同じである）を搬送する。ＷＳＭ６３０において、パケットは、その２４ビットＴＥＩＤによって識別され、ＴＥＩＤは、パケットがルーティングされる適切なパケットハンドラコアを識別するためにハッシュ化される。パケットは、ＷＦＭからＧｉＦＭへのイーサタイプを使用して、ＷＳＭ６３０によってＩＯＭ６２６Ｂへ（すなわち、ＩＯＭ６２６ＢのＩＰアドレスへ）転送され、ここで、それは、５タプル（例えば、送信元アドレス、宛先アドレス、送信元ポート、宛先ポートおよびイーサタイプ）を使用して識別され、また、ＩＯＭ６２６Ｂに戻る前に、さらなる処理（例えば、ネットワークアクセス識別を含む）のためにパケットデータネットワーク６２５に送信することができ、ＩＯＭ６２６Ｂで、それは５タプルを使用して再度識別される。ＩＯＭ５２６Ｂは、ルックアップテーブルを使用して、パケットヘッダに追加するための適切なセッションＩＤを判定する。いくつかの実装形態では、ルックアップテーブルは、ＩＯＭ上に維持され、サービスを受けているすべての加入者についてのデータを含む。このルックアップテーブルには、例えば、加入者用のセッションの作成時に投入することができる。本明細書で説明されるように、セッションは、ＴＥＩＤおよびセッションＩＤの両方を搬送する。パケットがインターネット側からＭＣＣに入るとき、その宛先アドレスは加入者ＩＰアドレスである（これは加入者に向かうダウンストリームパケットである）。このＩＰアドレスを使用して、ルックアップテーブルに対して相互参照し、関連付けられている加入者のセッションＩＤを識別することができる。パケットがアクセス側から入るとき、その送信元アドレスは、加入者アドレスであり、その宛先アドレスは、ユーザがアクセスしようとしているインターネット内のサーバのアドレスである。この送信元アドレスを使用して、ルックアップテーブルに対して相互参照し、関連付けられているＴＥＩＤを識別することができる。４Ｇネットワークの性質のために、いくつかの実施形態では、セッションＩＤは、常にアクセス側で取得され得るわけではないが、ＴＥＩＤはアクセス可能である場合がある。同様に、ＰＤＮ側では、セッションＩＤは、アクセス可能である場合がある。このように、いくつかの実装形態では、パケット識別および／またはルーティングのために、ＴＥＩＤがアクセス側で使用され、セッションＩＤがＰＤＮ側で使用される。ＴＥＩＤおよびセッションＩＤの両方の上位２４ビットは同じになるように設計されているため、それらのビットは、同じコアにハッシュ化され、それによって加入者を特定のコアにピン留めする。

ＩＯＭ５２６Ｂは、適切なセッションＩＤをパケットヘッダに追加する。次に、そのリターンパスに沿って続けて、パケットは、ＧｉＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ６２６ＢによってＷＳＭ６３０上のＷＦＭへ転送され、またパケットは識別され、その２４ビットセッションＩＤに基づいてＷＳＭ６３０における処理コアへとルーティングされる。ＷＳＭ６３０は、対応するＴＥＩＤを識別するためにセッションＩＤをハッシュ化する。次いで、パケットは、アクセスネットワーク６１５およびパケット発信元ＵＥに返送される前に、ＷＦＭからＧｎＦＭへを使用して、ＷＳＭ６３０からＩＯＭ６２６ＡへＧＴＰ−Ｕトンネリングされて戻される。いくつかの実施形態において、ＩＯＭ６２６ＡおよびＩＯＭ６２６Ｂは、同じ物理的場所内に存在する。いくつかの実施形態では、ＩＯＭ６２６ＡおよびＩＯＭ６２６Ｂは、単一のＩＯＭを表す。

図７は、開示されている主題のいくつかの実施形態による、スタンドアロンパケットデータネットワークゲートウェイ（「ＰＧＷ」）（ゲートウェイＧＰＲＳサポートノード「ＧＧＳＮ」としても機能することができる）およびスタンドアロンサービングゲートウェイ（「ＳＧＷ」）（サービングＧＰＲＳサポートノード「ＳＧＳＮ」としても機能することができる）を有する非プロキシＭＣＣアプリケーションのための負荷分散ハッシュ化を説明する図である。図７に示すように、スタンドアロンＰＧＷ／ＧＧＳＮ経路をたどって、ＵＥから発信されたデータパケットは、アクセスネットワーク７１５の「Ｓ５／Ｓ８」インターフェース／ポートを介して通り、ＩＯＭ７２６ＡへＧＴＰ−Ｕトンネリングされ、その（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用して識別され、ネゴシエートされたＴＥＩＤ（ＧＴＰ−ＵヘッダートンネルＩＤ）を含むことができる。パケットは、ＧｎＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ７２６ＡによってＷＳＭ７３０Ａ上のＷＦＭへ（すなわち、ＷＳＭ７３０ＡのＩＰアドレスへ）転送され、そのＴＥＩＤに基づいて、識別され、かつ処理コアにルーティングされる。パケットは、ＷＦＭからＧｉＦＭへのイーサタイプを使用して、ＷＳＭ７３０ＡによってＩＯＭ７２６Ｂへ（すなわち、ＩＯＭ７２６ＢのＩＰアドレスへ）転送され、そこで５タプル（例えば、送信元アドレス、宛先アドレス、送信元ポート、宛先ポート、およびイーサタイプ）を使用して、識別およびルーティングされ、そしてＩＯＭ７２６Ｂ（ここで、それが５タプルを使用して再度識別される）に戻される前に、さらなる処理のためにパケットデータネットワーク７２５に送信されてもよい。そのリターンパスに沿って続けて、パケットは、ＧｉＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ７２６ＢによってＷＳＭ７３０Ａ上のＷＦＭへ転送され、そしてそのセッションＩＤに基づいて、識別され、かつ処理コアにルーティングされる。次いで、パケットは、アクセスネットワーク７１５およびパケット発信元ＵＥへと返送される前に、ＷＦＭからＧｎＦＭへを使用して、ＷＳＭ７３０ＡからＩＯＭ７２６ＡへＧＴＰ−Ｕトンネリングされて戻される。

図７のスタンドアロンＳＧＷ／ＳＧＳＮ経路に従って、ＵＥから発信されるデータパケットは、アクセスネットワーク７１５の「Ｓ１Ｕ」インターフェース／ポートを介して通り、かつＩＯＭ７２６ＣへＧＴＰ−Ｕトンネリングされ、その（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用して識別され、ネゴシエートされたＴＥＩＤ（ＧＴＰ−ＵヘッダートンネルＩＤ）を含むことができる。パケットは、ＧｎＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ７２６ＣによってＷＳＭ７３０Ｂ上のＷＦＭへ（すなわち、ＷＳＭ７３０ＢのＩＰアドレスへ）転送され、そのＴＥＩＤに基づいて、識別され、かつ処理コアにルーティングされる。パケットは、ＷＦＭからＧｉＦＭへのイーサタイプを使用して、ＷＳＭ７３０ＢによってＩＯＭ７２６ＤへＧＴＰ−Ｕトンネリングされ、そこでその（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用して識別され、そしてＩＯＭ７２６Ｄ（ここで、その（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用して再度識別される）に戻される前に、さらなる処理のためにパケットデータネットワーク７２５に送信されてもよい。ＩＯＭ７２６Ｄからパケットデータネットワーク７２５へのこの転送は、Ｓ５／Ｓ８インターフェースへのＧＴＰ−Ｕトンネリングとすることができ、ＧＧＳＮ、ＰＧＷ（「４Ｇ」規格）および／またはＧ１サービスを適用することができる。スタンドアロンＳＧＷを通るリターンパス上で、パケットは、ＧｉＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ７２６ＤによってＷＳＭ７３０Ｂ上のＷＦＭへ転送され、そのセッションＩＤに基づいて、識別され、かつ処理コアにルーティングされる。次いで、パケットは、アクセスネットワーク７１５およびパケット発信元ＵＥに返送される前に、ＷＦＭからＧｎＦＭを使用して、ＷＳＭ７３０ＢからＩＯＭ７２６ＣへＧＴＰ−Ｕトンネリングされて戻される。

図８は、開示されている主題のいくつかの実施形態による、「Ｇ_ｉ」ゲートウェイ（例えば、「Ｇ_ｉサービス」として知られる付加価値サービスを提供し得るインターネットに面するゲートウェイ）としてＭＣＣを使用する非プロキシアプリケーションのための負荷分散ハッシュ化を説明する図である。図８に示されるように、パケットは、アクセスネットワーク側またはパケットデータネットワーク側のどちらから来てもよい。着信データパケットの送信元を明確にするために、インターフェースアクセス属性が渡されて、パケットがアクセス側から到着するのか（その場合、送信元アドレスがハッシュ化に使用されることになる）、インターネット／パケットデータネットワーク側から到着するのか（その場合、宛先アドレスがハッシュ化に使用されることになる）を識別する。いくつかのそのような実装形態では、インターフェースのアクセス属性が、アクセスネットワークから来るパケットに対応しているために、ＵＥから発信されるデータパケットは、アクセスネットワーク８１５からＧｉアクセスインターフェースを介してＩＯＭ８２６Ａに渡され、その送信元アドレス（「ＳＡｄｄｒ」）を使用して識別される。この転送の一部として、インターフェース属性は、Ｇｉアクセスインターフェースを識別するためにＤＰＤＫにプッシュすることができる。パケットは、ＧｎＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ８２６ＡによってＷＳＭ８３０上のＷＦＭへ（すなわち、ＷＳＭ８３０のＩＰアドレスへ）転送され、そのＴＥＩＤに基づいて、識別され、かつ処理コアにルーティングされる。パケットは、ＷＦＭからＧｉＦＭへのイーサタイプを使用して、ＷＳＭ８３０によってＩＯＭ８２６Ｂへ（すなわち、ＩＯＭ８２６ＢのＩＰアドレスへ）転送され、そこでそれは５タプルを使用して識別され、そしてＩＯＭ８２６Ｂ（ここで、そのＤＡｄｄｒを使用してそれが識別される）に戻される前に、さらなる処理のためにパケットデータネットワーク８２５に送信されてもよい。そのリターンパスに沿って続けて、パケットは、ＧｉＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ８２６ＢによってＷＳＭ８３０上のＷＦＭへ転送され、そのセッションＩＤを使用することに基づいて、識別され、かつ処理コアへとルーティングされる。次いで、パケットは、アクセスネットワーク８１５およびパケット発信元ＵＥに返送される前に、ＷＦＭからＧｎＦＭへを使用して、ＷＳＭ８３０からＩＯＭ８２６Ａに渡される。

Ｗｉ−Ｆｉネットワークを使用してネットワークカバレッジを拡大し、マクロセルラーネットワーク上のトラフィックを低減すると、サービスプロバイダにとってコスト面での利点を有することができる。信頼できるＷｉ−Ｆｉネットワークは、例えば、サービスプロバイダが維持するホットスポット（例えば、空港のホストされたホットスポット）、またはプロバイダと連携して展開されたものとすることができる。サービスプロバイダは、モバイルまたは固定ネットワーク事業者とすることができる。例えば、ケーブルプロバイダのコムキャスト（Ｃｏｍｃａｓｔ）は、米国で展開されている何千もの無線ホットスポットを通じて、無線音声およびデータサービスの両方を現在提供している。

信頼できるネットワークは、サービスプロバイダが基本的なユーザ情報を検証し、アクセスポイントにわたってある程度のレベルの制御を行使することができるネットワークとして定義することができる。例えば、Ｗｉ−Ｆｉユーザは、信頼できるＷＬＡＮプロキシ（「ＴＷＡＰ」）を介してサービスプロバイダの認証、認可、およびアカウンティング（ＡＡＡ）システムによって認証することができ、一方で音声／データトラフィック自体は、信頼できるＷＬＡＮアクセスゲートウェイ（「ＴＷＡＧ」）を通過し、バックホールのためにデータネットワークにオフロードすることができる。本明細書に記載のいくつかの実施形態では、ポリシーエンフォースメント（例えば、サービス品質（「ＱｏＳ」）ポリシー）、コンテンツフィルタリング、ウェブ／ビデオ最適化、およびＮＡＴ、ファイアウォールおよびインターネットプロトコルセキュリティ（「ＩＰＳｅｃ」）のようなセキュリティサービスなどの、Ｇｉサービスは、加入者発信パケット上で実行される。

いくつかの実装形態では、付加価値サービスおよびシームレスなセッションハンドオフを含めて、加入者のネットワークエクスペリエンスを信頼できるＷｉ−Ｆｉネットワークに拡張することは、サービスプロバイダのコアネットワークとの緊密な統合を含む。信頼できるＷｉ−Ｆｉアクセスの一例は、大型のショッピングモールでの無線ローミングであり、そこでは、モバイル加入者は、いったんモールの内側に入るとモールの外側にあるマクロセルラーネットワークから無線ＬＡＮ（ＷＬＡＮ）へシームレスに移動することになる。このようなシナリオでは、加入者は、ネットワークにログオンすること、または既存のセッションを中断することを必要とせずに、屋内でより優れた無線受信を享受することになる。上述のように、ＴＷＡＰは、認証／認可のためにＡＡＡサーバとのセキュアな通信を確保することができ、一方でＴＷＡＧは、パケットデータネットワーク上に音声／データトラフィックをオフロードする（かつ、任意選択的に、そのトラフィックでポリシーを実施する）ことになる。しかしながら、すべてのトラフィックが、インターネットに直接ルーティングされ得るとは限らない。一定のトラフィックは、ＴＷＡＧを介してパケットコアネットワークにルーティングされ得る。本明細書に記載の実施形態は、業界標準のＳ２ａインターフェースをサポートすることができ、これはローカル仮想ＥＰＣソリューションの一部であるかまたは既存のサードパーティＥＰＣソリューションであるかにかかわらず、ＴＷＡＧが、任意の業界標準の進化したパケットコア（「ＥＰＣ」）ゲートウェイと直接通信することを可能にする。

何百万ものＷｉ−Ｆｉアクセスポイントを有する世界において、サービスプロバイダがユーザを認証することができない、またはネットワーク上のトラフィックの流れを制御することができない、信頼できないＷｉ−Ｆｉネットワークはよくあることである。信頼できないネットワークの例は、喫茶店のＷｉ−Ｆｉネットワーク、または競合プロバイダによってホストされるものである可能性がある。本明細書に記載のいくつかの実施形態では、信頼できないＷｉ−Ｆｉネットワークをコアネットワークに持ち込むことを容易にするために、進化したパケットデータゲートウェイ（「ｅＰＤＧ」）を展開することができる。

信頼できないネットワーク上の通信は、インターネットプロトコルセキュリティ（「ＩＰＳｅｃ」）暗号化として知られる追加レベルのセキュリティを用いて保護することができる。業界標準は、すべてのモバイルデバイスが、そのデバイス上でＩＰＳｅｃクライアントを特徴付けなければならないことを義務付けている。そのような場合、音声およびデータセッションは、ＩＰＳｅｃトンネルをセキュアに通過する。これらのトンネルは、着信コールまたは発信コールを見越してオープンのままにしておく必要がある場合が多く、そのため、いつでも何百万ものＩＰＳｅｃトンネルをネットワーク内でオープンのままにしておく必要があり得る。ハードウェアベースのｅＰＤＧは、オープンＩＰＳｅｃトンネルに対するこの高い要求を取り扱うように設計されているが、これらの同じ高い暗号化要件は、仮想化ｅＰＤＧインスタンスにとって問題があることが歴史的に証明されている。本明細書に記載のいくつかの実施形態によれば、堅牢な仮想ｅＰＤＧが実装され、それは単一のサーバ上で５ＧレベルのＩＰＳｅｃ暗号化通信を配信することができる。

図９は、開示されている主題のいくつかの実施形態による、Ｇｉサービスを有する信頼できる無線アクセスゲートウェイ（「ＷＡＧ」）を使用する非プロキシアプリケーションのための負荷分散ハッシュ化を説明する図である。図９の上部に示すように、ＵＥは、信頼できるＷｉ−Ｆｉ接続を通して、または３Ｇ／４Ｇ接続を介してパケットネットワークに接続することができ、またＧｉサービス（「ＧｉＳｖｃｓ」）９２７（例えば、ＴＷＡＰを介したＡＡＡ認証を備えた）またはＳＧＷをそれぞれ有するＴＷＡＧを介してパケットデータネットワークへパケットを転送することができる。図９の下部は、ＴＷＡＧ９２７における、アクセスネットワークを介してＵＥから発信されるデータパケットの処理を示す。パケットは、そのＳＡｄｄｒを使用して識別されたＧＲＥカプセル化トランスペアレントイーサネットブリッジング（「ＴＥＢ」）を介してＩＯＭ９２６Ａに到着する。パケットは、ＧｎＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ９２６ＡによってＷＳＭ９３０上のＷＦＭへ（すなわち、ＷＳＭ８３０のＩＰアドレスへ）転送され、そのＴＥＩＤに基づいて、識別され、かつ処理コアにルーティングされる。次いで、パケットは、ＷＦＭからＧｉＦＭへのイーサタイプを使用して、ＷＳＭ９３０によってＩＯＭ９２６Ｂへ（例えば、ＩＯＭ９２６ＢのＩＰアドレスへ、またはＧＴＰ−Ｕトンネリングされて）転送され、ここで、５タプル、またはその送信元および宛先アドレス（「（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒ」）を使用して識別され、そして（ユーザ設定：（１）ＴＷＡＧ９２７がＧｉサービスを提供している場合には、ＩＰパケットを直接ＰＤＮへ、または（２）ＴＷＡＧ９２７がＧｉサービスを提供していない場合には、Ｓ２Ａインターフェースを介する、に応じて）、ＩＯＭ９２６Ｂ（ここで、それがその５タプルまたはその送信元および宛先アドレス（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒのいずれかを使用して識別される）に戻される前に、さらなる処理のためにパケットデータネットワークへと送信されてもよい。そのリターンパスに沿って続けて、パケットは、ＧｉＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ９２６ＢによってＷＳＭ９３０上のＷＦＭへ転送され、そのセッションＩＤに基づいて、識別され、かつ処理コアにルーティングされる。次いで、パケットは、ＧＲＥカプセル化ＴＥＢを介してＷＦＭからＧｎＦＭへを使用して、ＷＳＭ９３０からＩＯＭ９２６Ａへ渡されて戻され、その時点で、パケットは、アクセスネットワークおよびパケット発信元ＵＥに返送される前に、そのＳＡｄｄｒによって識別される。

図１０は、開示されている主題のいくつかの実施形態による、インターネットプロトコルセキュリティ（「ＩＰＳｅｃ」）暗号化を有する信頼できるＷＡＧを使用する非プロキシアプリケーションのための負荷分散ハッシュ化を説明する図である。図１０の上部に示すように、ＵＥは、信頼できるＷｉ−Ｆｉ接続を通して、または３Ｇ／４Ｇ接続を介してパケットネットワークへ接続され、そしてＧｉサービス（「ＧｉＳｖｃｓ」）１０２７（例えば、ＴＷＡＰを介したＡＡＡ認証を備えた）またはＳＧＷをそれぞれ有するＴＷＡＧを介してパケットデータネットワークへパケットを転送することができる。図１０の下部は、ＴＷＡＧ１０２７における、ＩＰカプセル化セキュリティペイロード（「ＥＳＰ」）を介してアクセスネットワークからＩＯＭ１０２６ＡへのＵＥから発信されるデータパケットの処理を示し、その送信元および宛先アドレス（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用して識別される。パケットは、ＩＯＭ１０２６Ａによって、ＷＳＭ１０３０Ａ上の別のＳＥＣＭ（すなわち、ＷＳＭ１０３０のＩＰアドレスへ）（すなわち、ＳＥＣＭからＳＥＣＭへの転送）およびＩＰカプセル化セキュリティペイロード（「ＩＰ ＥＳＰ」）プロトコルへ転送される前に、ＩＯＭ１０２６Ａの内部にあるセキュリティモジュール（「ＳＥＣＭ」）によって処理され、そしてセッションＩＤに基づいて、識別され、かつ処理コアへとルーティングされる。ＷＳＭ１０３０Ａの内部では、パケットは、ＳＥＣＭからＩＯＭへと渡される。次いで、パケットは、ＧｎＦＭからＷＦＭへを使用して、ＷＳＭ１０３０ＡによってＷＳＭ１０３０Ｂ上のＷＦＭへ転送され、そのセッションＩＤに基づいて、再び識別され、かつ処理コアへルーティングされる。ＷＳＭ１０３０Ｂは、ＷＦＭからＧｉＦＭへのイーサタイプを使用して、パケットをＩＯＭ１０２６Ｂへ（例えば、ＩＯＭ１０２６ＢのＩＰアドレスへ、またはＧＴＰ−Ｕトンネリングされ）渡し、そこで５タプルまたはその送信元および宛先アドレス、（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用して識別され、そしてＩＯＭ１０２６Ｂ（ここでそれはその５タプルまたはその（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用して再度識別される）に戻される前に、さらなる処理のためにパケットデータネットワークに送信されてもよい。そのリターンパスに沿って続けて、パケットは、ＧｉＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ０２６ＢによってＷＳＭ１０３０Ｂ上のＷＦＭへ転送され、そのＴＥＩＤに基づいて、識別され、かつ処理コアへルーティングされる。次いで、パケットは、ＧＲＥカプセル化ＴＥＢを介してＷＦＭからＧｎＦＭへを使用してＷＳＭ１０３０ＢからＩＯＭ０２６Ａに渡されて戻り、その時点で、パケットは、そのＳＡｄｄｒによって識別される。その後、パケットは、暗号化のためにＳＥＣＭからＳＥＣＭへの転送によってＩＯＭ１０２６ＡのＳＥＣＭによってＷＳＭ０３０ＡのＳＥＣＭにリダイレクトされ、そしてアクセスネットワークおよびパケット発信元ＵＥへと返送される前に、ＳＥＣＭからＩＯＭへを介してＩＯＭ１０２６Ａに渡されて戻される。

図１１は、開示されている主題のいくつかの実施形態による、ｅＰＤＧを使用した負荷分散ハッシュ化を説明する図である。図１１の上部に示すように、ＵＥは、信頼できないＷｉ−Ｆｉ接続を通して、または３Ｇ／４Ｇ接続を介してパケットネットワークに接続することができ、またｅＰＤＧ１１２９を介してパケットデータネットワークへパケットを転送することができる。図１１の下部は、ｅＰＤＧ１１２９において、ＩＰ ＥＳＰイーサタイプを使用する、アクセスネットワークからＩＯＭ１１２６ＡへのＵＥから発信されるデータパケットの処理を示し、またその（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用してＩＯＭ１１２６Ａで識別される。ＩＯＭ１１２６Ａは、セッションを作成し、パケットのキー値をそのローカルセッションデータへとマッピングしてセッションＩＤを判定する。パケットは、ＩＰ ＥＳＰイーサタイプを使用して、ＩＯＭ１１２６ＡによってＷＳＭ１１３０上のＳＥＣＭへ転送（すなわち、ＳＥＣＭからＳＥＣＭへの転送）される前に、ＩＯＭ１１２６Ａの内部のＳＥＣＭによって処理され、またセッションＩＤに基づいて、識別され、かつ処理コアにルーティングされて復号化される。ＷＳＭ１１３０Ａの内部で、パケットは、ＳＥＣＭからＷＦＭへと渡され、そこでセッションＩＤを、パケットを処理コアへとルーティングするためにＷＦＭによって使用することができる。次いで、パケットは、ＷＦＭからＧｉＦＭへのイーサタイプを使用して、ＷＳＭ１１３０によってＩＯＭ１１２６Ｂへと転送され（例えば、ＧＴＰ−Ｕトンネリングされ）、ここで、それは、その（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用して、識別され、かつルーティングされ、そしてＩＯＭ１１２６Ｂ（ここで、それは（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用して識別され、かつルーティングされる）に戻される前に、さらなる処理のためにパケットデータネットワークに送信されてもよい。そのリターンパスに沿って続けて、パケットは、ＧｉＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ１１２６ＢによってＷＳＭ１１３０上のＷＦＭへと転送され、そのＴＥＩＤを使用して、識別されルーティングされる。ＷＳＭ１１３０Ａの内部では、パケットは、暗号化のためにＷＦＭからＳＥＣＭに渡され、ＩＰ ＥＳＰが適用される。次いで、パケットは、ＳＥＣＭからＩＯＭおよびＩＰ ＥＳＰイーサタイプを使用して、ＷＳＭ１１３０からＩＯＭ１１２６Ａに渡されて戻り、その時点で、パケットは、アクセスネットワークおよびパケット発信元ＵＥに返される前に、その（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒによって識別されルーティングされる。

図１２は、開示されている主題のいくつかの実施形態による、プロキシトラフィックアプリケーションのための負荷分散ハッシュ化を説明する図である。図１２に示すように、ＵＥから発信され、アクセスネットワーク１２１５の「Ｓ１Ｕ」インターフェース／ポートに到着するデータパケットは、ＩＯＭ１２２６ＡへＧＴＰ−Ｕトンネリングされ、（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを介して識別される。パケットは、ＧｎＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ１２２６ＡによってＷＳＭ１２３０上のＷＦＭへ（すなわち、ＷＳＭ１２３０のＩＰアドレスへ）転送され、そしてそのＴＥＩＤによって識別される。ＷＳＭ１２３０において、ＴＥＩＤは、コア選択の目的でハッシュ化される。ＷＳＭ１２３０の内部で、パケットは、プロキシサービスを必要とすると判定され、またＷＦＭからネットワークアドレス変換（「ＮＡＴ」）を実行するワークフロー転換モジュールへと渡され、ここでパケットトラフィックは、ユーザ送信元ＩＰアドレスとこのパケットに割り当てられている宛先ＭＡＣアドレスとのマッピングに基づいて転換される（ＵＥのＩＰアドレスを削除して）。したがって、パケットがＰＭから戻ったとき、ワークフロー転換モジュールは、逆引きを実行することができ、またＵＥのＩＰアドレスを元に戻すことができる。パケットトラフィックを転換するとき、ワークフロー転換モジュールは、ＨＴＴＰプロキシサービス（および／またはビデオ適応サービスなどの他のサービス）のために、１つ以上のサービスモジュールブレードＰＭプロキシモジュール（「ＰＭ」）１２３２へ、イーサタイプ（例えば、ＤＥＡ８〜ＤＥＡＦ）を有するパケットを渡す。転換されたパケットがＰＭに到着すると、ＴＣＰ接続は、ＮＡＴのために終了することができる（すなわち、ＰＭは、宛先ＩＰアドレスをそれ自身のものとして認識する）。ＷＳＭ１２３０からＰＭ１２３２にパケットを送信するとき、ＷＳＭ１２３０は、ＵＥのＩＰアドレスの代わりに「ローカル」ＩＰアドレスを使用する。このローカルＩＰアドレスは、ＵＥのＩＰアドレスをローカルＩＰアドレスへとマッピングすることによって、ＮＡＴ変換を介して生成される。これは、送信元アドレスとして（ＷＳＭ１２３０を離れるとき）、および宛先アドレスとして（パケットのリターンパスに沿ってＷＳＭ１２３０に到着するとき）機能し、ＩＰアドレスは、そのビットのサブセット内にコア情報を含む。言い換えれば、ＷＳＭ１２３０によって選択された「ローカルＩＰアドレス」は、利用可能なＩＰアドレスのリストから選択され、パケットのＴＥＩＤのハッシュ化に基づいて、パケットに対してＷＳＭ１２３０によって選択されたコアに対応する。

パケットは、所与のイーサタイプ（例えば、「ＢＥＥＦ」）を用いて、ＰＭ１２３２によってＩＯＭ１２２６Ｂへ（すなわち、ＩＯＭ１２２６ＢのＩＰアドレスへ）転送され、ここで、５タプルを使用して識別され、ＩＯＭ１２２６Ｂ（ここで、それは再び５タプルを使用して再度識別される）に戻される前に、さらなる処理のためにパケットデータネットワーク１２２５へ送信することができる。そのリターンパスに沿って続けて、パケットは、イーサタイプ（例えば、ＩＯＭ１２２６Ｂに、パケットがプロキシパケットであることを示すためのＤＥＡ８−ＤＥＡＦ）を用いて、ＰＭ１２３２上のループバックＩＰアドレス（例えば、外部世界がこれと通信することができるように、およびパケットがＷＳＭではなくＰＭへループバックするように、ＰＭが使用するＩＰアドレス）を使用して、ＩＯＭ１２２６ＢによってＨＴＴＰプロキシへと転送される。その後、パケットは、パケットの方向性（および、それに応じて、どのようにパケットがルーティングされ、処理されるべきか、など）を示すために、イーサタイプＢＥＥＦを用いて、ＰＭ１２３２からルーティングされ、ＷＳＭ１２３０のワークフロー転換モジュールに戻される。いくつかの実装形態では、ＷＦＭおよびワークフロー転換モジュールソフトウェアを、共通のコア上で実行しており（例えば、ＴＥＩＤ、セッションＩＤなどに関連付けられて）、そのため関連付けられたコアが常に使用されることになる。ＭＡＣＩＰアドレスが生成される前に、コア情報をＩＰアドレスの中へと埋め込んで、どのコアがＰＭに送信されるＭＡＣパケットを生成したかを示すことができる。それから、ＬＢコアは、それがプロキシパケットであることを認識することができる（例えば、コアを識別するために約７ビットを要する可能性がある）。ＷＳＭ１２３０の内部では、パケットは、ワークフロー転換モジュールからＷＦＭに渡される。パケットは、ＷＦＭからＧｎＦＭへのイーサタイプを使用して、ＷＳＭ１２３０によってＩＯＭ１２２６ＡへＧＴＰ−Ｕトンネリングされ、ここで、アクセスネットワーク１２１５へ（やはりＧＴＰ−Ｕトンネリングを介して）およびパケット発信元ＵＥに返送される前に、（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用して識別される。

図１３は、開示されている主題のいくつかの実施形態による、プロキシおよび非プロキシマルチプロトコルラベルスイッチング（「ＭＰＬＳ」）トラフィックアプリケーションの両方に対する負荷分散ハッシュ化を説明する図である。図１３に図示される実施形態のいくつかの実装形態において、ＷＳＭ１３３０は、ＩＯＭ１３２６Ａから受信したパケットをＰＭ１３３２に転換するかどうかに関して判定を下す。図１３に示すように、ＵＥから発信されてアクセスネットワーク１３１５の「Ｓ１Ｕ」インターフェース／ポートに到着するデータパケットは、ＩＯＭ１３２６ＡへＧＴＰ−Ｕトンネリングされ、（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを介して識別される。パケットは、ＧｎＦＭからＷＦＭへのイーサタイプを使用して、ＩＯＭ１３２６ＡによってＷＳＭ１３３０へ（すなわち、ＷＳＭ１３３０のＩＰアドレスへ）転送され、そのＴＥＩＤに基づいて、再び識別され、かつ処理コアへとルーティングされる。

ＷＳＭ１３３０の内部で、パケットが、プロキシサービスを必要とすると判定された場合、パケットは、ＤＥＡ８〜ＤＥＡＦイーサタイプを介して、ＷＳＭ１３３０からＨＴＴＰプロキシサービスのための１つ以上のＰＭ１３３２へと渡され、ネットワークアドレス変換（「ＮＡＴ」）が実行される。プロキシ経路（破線で示す）に従って、パケットは、ＢＥＥＦイーサタイプおよびマルチプロトコルラベルスイッチング（「ＭＰＬＳ」）を使用して、ＰＭ１３３２によってＩＯＭ１３２６Ｂへ（すなわち、ＩＯＭ１３２６ＢのＩＰアドレスへ）転送され、そこで、５タプルを使用して識別され、さらなる処理のためにＩＯＭ１３２６Ｂからパケットデータネットワーク１３２５に送信することができる。ＩＯＭ１３２６Ｂに戻ると、パケットは５タプルを使用して再び識別される。そのリターンパスに沿って続けて、パケットは、ＤＥＡ８〜ＤＥＡＦイーサタイプを使用して、ＰＭ１３３２上のループバックＩＰを使用してＩＯＭ１３２６ＢによってＨＴＴＰプロキシへ転送される。その後、パケットは、ＢＥＥＦイーサタイプを使用して、ＰＭ１３３２からＷＳＭ１３３０へルーティングして戻される。パケットは、ＷＦＭからＧｎＦＭへのイーサタイプを使用して、ＷＳＭ１３３０によってＧＴＰ−ＵトンネリングされＩＯＭ１３２６Ａに戻され、ここで、アクセスネットワーク１３１５およびパケット発信元ＵＥへＧＴＰ−Ｕトンネリングされて戻る前に、その（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用して識別される。

ＷＳＭ１３３０でのノースバウンドパケットがプロキシサービスを必要としないと判定された場合、パケットは、ＷＦＭからＧｎＦＭへを使用して、ＷＳＭ１３３０によってＩＯＭ１３２６Ｂへ（すなわち、ＩＯＭ１３２６ＢのＩＰアドレスへ）直接転送され、そこで、５タプルを使用して識別され、さらなる処理のためにＩＯＭ１３２６Ｂからパケットデータネットワーク１３２５へ送信することができる。ＩＯＭ１３２６Ｂへと戻ると、パケットは、５タプルを使用して再び識別される。そのリターンパスに沿って続けて、パケットは、ＧｉＦＭからＷＦＭへを使用して、ＩＯＭ１３２６ＢによってＷＳＭ１３３０へ転送され、そこで、そのセッションＩＤに基づいて、識別され、かつ処理コアへルーティングされる。プロキシリターンパスと同様に、その後、パケットは、ＷＦＭからＧｎＦＭへのイーサタイプを使用して、ＷＳＭ１３３０によってＧＴＰ−Ｕトンネリングされ、ＩＯＭ１３２６Ａに戻り、そこで、アクセスネットワーク１３１５およびパケット発信元ＵＥへＧＴＰ−Ｕトンネリングされて戻る前に、（Ｓｒｃ＋Ｄｓｔ）Ａｄｄｒを使用して識別される。

図２０は、上記のようなプロキシサービスを含むいくつかの実施形態によるフロー図を説明する。ステップ２００２において、ＭＣＣ１４１６は、ＭＭＥ１４０６からユーザデバイスのためのセッションを作成する要求を受信する。要求は、ＭＣＣ１４１６が、ユーザデバイスに向けられたダウンストリームトラフィックのために後で使用するＴＥＩＤ（「ＴＥＩＤ＿Ｄ」と表記される）を含む。ステップ２００４において、ＭＣＣ１４１６は、新しいセッションに関連付けられ、ユーザデバイスに関連付けられたアップストリームトラフィックのためにｅＮｏｄｅＢ１４０４／ＭＭＥ１４０６によって使用されることになるＴＥＩＤ（「ＴＥＩＤ＿Ｕ」と表記される）を作成する。ＭＣＣ１４１６はまた、新しいセッションに関連付けられているセッションＩＤを作成する。いくつかの実施形態では、ＴＥＩＤ＿ＵとセッションＩＤとは共通の値を共有する。例えば、ＴＥＩＤ＿Ｕの最初の２４ビットは、セッションＩＤの最初の２４ビットと一致してもよい。ＴＥＩＤ＿ＵおよびセッションＩＤが作成されると、ＭＣＣ１４１６は、新たに作成されたＴＥＩＤ＿Ｕが新たに作成されたセッションＩＤに対応することをＭＣＣ１４１６内のすべてのＩＯＭに通知する。いくつかの実施形態では、個々のＩＯＭは、この情報の記録をテーブルに保存し得る。

ステップ２００６において、ＭＣＣ１４１６は、ｅＮｏｄｅＢ１４０４からアップストリームデータパケットを受信する。アップストリームデータパケットは、以前に確立されたＴＥＩＤ＿Ｕを含む。ステップ２０１０において、ＭＣＣ１４１６は、ＴＥＩＤ＿Ｕに対応するセッションＩＤを識別する。いくつかの実施形態では、ＩＯＭは、テーブルへのインデックスとしてＴＥＩＤ＿Ｕを使用することによってセッションＩＤを識別する。次いで、ＩＯＭは、アップストリームデータパケットを処理するためにセッションＩＤに基づいてワークフローサービスモジュール（「ＷＳＭ」）を選択し、アップストリームデータパケットを選択されたＷＳＭにルーティングする。ＷＳＭは、セッションＩＤに基づいて特定のパケットハンドラコア（「ＰＨＣ」）を選択する。いくつかの実施形態では、ハッシュ化アルゴリズムが、セッションＩＤに基づいて、アップストリームデータパケットをＰＨＣに分配するために使用される。

ＭＣＣ１４１６は、アップストリームデータパケットが、プロキシサービスを必要とすると判定する。例えば、アップストリームデータパケットは、特別なビデオ符号化、キャッシュされたコンテンツへのアクセス、ＳＭＴＰ、および他のプロキシサービスを必要とする場合がある。このデータの処理を強化するために、プロキシサービスモジュールが使用されてもよい。ＭＣＣ１４１６は、次いで、既存のＩＰコールを終了させ、例えば、外部パケットデータネットワークとの通信のために新しいループバックＩＰアドレスを作成し得る。ループバックＩＰアドレスは、ユーザデバイスに関連する発信トラフィックの送信元アドレスとして、およびユーザデバイスに関連する着信トラフィックに対する宛先アドレスとして使用される。次いで、ＭＣＣ１４１６は、ループバックＩＰアドレスを、選択されたパケットハンドラコアに対応する識別子にマッピングし、この相関関係をネットワークアドレス変換テーブル（「ＮＡＴ」）に任意選択的に格納する。

ステップ２０１２において、アップストリームデータパケットが、送信元ＩＰアドレスとしてループバックＩＰアドレスを使用してインターネット１４２２に送信される。ステップ２０１４において、ダウンストリームデータパケットが、宛先アドレスとしてループバックＩＰアドレスと共に受信される。ステップ２０１６において、ＭＣＣ１４１６は、ループバックＩＰアドレスに基づいて、ダウンストリームデータパケットをプロキシサービスモジュールにルーティングする。ＭＣＣ１４１６は、ループバックＩＰアドレスに基づいて、ダウンストリームデータパケットを選ばれたパケットハンドラコアにマッピングするためにＮＡＴに格納された相関関係を使用する。ステップ２０１８において、ダウンストリームデータパケットは、ＴＥＩＤ＿Ｄを使用してｅＮｏｄｅＢ１４０４へルーティングして戻される。

本明細書に開示された技法およびシステムは、ネットワーク、コンピュータシステム、またはコンピュータ化された電子デバイスと共に使用するためのコンピュータプログラム製品として実装されてもよい。そのような実装形態は、コンピュータ可読媒体（例えば、ディスケット、ＣＤ−ＲＯＭ、ＲＯＭ、フラッシュメモリ、または他のメモリもしくは固定ディスク）のような有形の媒体上に固定されるか、あるいは、モデムもしくは媒体を覆うネットワークに接続された通信アダプタなどの他のインターフェースデバイスを介して、ネットワーク、コンピュータシステム、またはデバイスへ送信可能である、一連のコンピュータ命令、またはロジックを含んでもよい。

媒体は、有形の媒体（例えば、光またはアナログ通信回線）または無線技法（例えば、Ｗｉ−Ｆｉ、セルラー、マイクロ波、赤外線、もしくは他の伝送技術）を用いて実装された媒体のいずれかであってもよい。一連のコンピュータ命令は、システムに関して本明細書で説明されている機能性の少なくとも一部を具体化する。当業者は、そのようなコンピュータ命令を、多くのコンピュータアーキテクチャまたはオペレーティングシステムで使用するためにいくつかのプログラミング言語で書くことができることを理解されたい。

さらに、そのような命令は、半導体、磁気、光学、または他のメモリデバイスなどの任意の有形のメモリデバイスに格納されてもよく、光学、赤外線、マイクロ波、または他の伝送技術などの任意の通信技術を使用して送信されてもよい。

そのようなコンピュータプログラム製品は、印刷物もしくは電子文書を伴うリムーバブルメディア（例えば、シュリンクラップソフトウェア）として配布されてもよく、コンピュータシステムにプリロード（例えば、システムＲＯＭもしくは固定ディスクに）されてもよく、またはネットワーク（例えば、インターネットもしくはワールドワイドウェブ）を介してサーバもしくは電子掲示板から配布されてもよいことが予想される。当然のことながら、本発明のいくつかの実施形態は、ソフトウェア（例えば、コンピュータプログラム製品）とハードウェアの両方の組み合わせとして実装されてもよい。さらに本発明の他の実施形態は、完全にハードウェアとして、または完全にソフトウェア（例えば、コンピュータプログラム製品）として実装される。

前述の説明において、一定のステップまたはプロセスは、特定のサーバ上で、または特定のエンジンの一部として実行することができる。特定のステップは、サーバシステムおよび／またはモバイルデバイスを含むがこれらに限定されない、様々なハードウェアデバイス上で実行することができるので、これらの説明は単なる例示である。同様に、特定のステップが実行される場所の分割は、変化する可能性があり、分割がないことまたは異なる分割が本発明の範囲内であることが理解される。さらに、コンピュータシステム処理を説明するために使用される「モジュール」および／または他の用語の使用は、交換可能であり、機能を実行することができる論理または回路を表すことを意図している。

Claims (28)

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. 前記ＭＰＬＳラベルスペースが、ＵＥプールアドレスドメインと、プロキシループバックアドレスドメインと、に分割される、請求項２７に記載の方法。