JP6301358B2 - 通信ネットワークにおけるマルチパス伝送制御プロトコル信号伝達の処理 - Google Patents

通信ネットワークにおけるマルチパス伝送制御プロトコル信号伝達の処理 Download PDF

Info

Publication number
JP6301358B2
JP6301358B2 JP2015546870A JP2015546870A JP6301358B2 JP 6301358 B2 JP6301358 B2 JP 6301358B2 JP 2015546870 A JP2015546870 A JP 2015546870A JP 2015546870 A JP2015546870 A JP 2015546870A JP 6301358 B2 JP6301358 B2 JP 6301358B2
Authority
JP
Japan
Prior art keywords
mptcp
node
proxy function
access network
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2015546870A
Other languages
English (en)
Other versions
JP2016508308A (ja
Inventor
ディナン ルーラント，
ディナン ルーラント，
グンナル ミルデ，
グンナル ミルデ，
ステファン ロンメル，
ステファン ロンメル，
ヤリ タピオ ヴィクベリィ，
ヤリ タピオ ヴィクベリィ，
Original Assignee
テレフオンアクチーボラゲット エルエム エリクソン（パブル）
テレフオンアクチーボラゲット エルエム エリクソン（パブル）
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エルエム エリクソン（パブル）, テレフオンアクチーボラゲット エルエム エリクソン（パブル） filed Critical テレフオンアクチーボラゲット エルエム エリクソン（パブル）
Publication of JP2016508308A publication Critical patent/JP2016508308A/ja
Application granted granted Critical
Publication of JP6301358B2 publication Critical patent/JP6301358B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/14—Multichannel or multilink protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/08—Reselecting an access point

Description

本発明は、通信ネットワークにおけるマルチパスＴＣＰ信号伝達処理の分野に関し、具体的には、プロキシ機能を介して送信されるマルチパスＴＣＰ信号伝達に関する。
伝送制御プロトコル（ＴＣＰ）セッションは、「ＴＣＰをプロトコルとして使用する、２つのアプリケーション間の論理エンドツーエンドデータ通信リンク」として定義可能である。通常のＴＣＰは、通信を１セッションにつき単一パスに制限する。インターネットエンジニアリングタスクフォース（ＩＥＴＦ）は現在、通常のＴＣＰセッションで複数のパスを同時に使用する機能を追加するためのメカニズムを開発している。「マルチパスＴＣＰ」（ＭＰＴＣＰ）と呼ばれるＴＣＰの拡張機能は、インターネットドラフト「ｄｒａｆｔ−ｉｅｔｆ−ｍｐｔｃｐ−ｍｕｌｔｉａｄｄｒｅｓｓｅｄ」に記載されている。マルチパスＴＣＰ開発に関するアーキテクチャ面でのガイドラインは、ＲＦＣ ６１８２で公開されている。ＲＦＣ ６１８２は、「パス」を「この文脈では、ソースおよび宛先のアドレスペアとして定義される、送信者と受信者との間の一連のリンク」として定義している。
多くの場合、ピア間には複数のパスが存在する。この一例が、エンドデバイスの一方または両方がマルチホームである場合、および／または、複数のアクセス技術を介して接続している場合である。たとえば、第３世代パートナーシッププロジェクト（３ＧＰＰ）マルチアクセスシナリオにおいて、ユーザ機器（ＵＥ）デバイスは、３ＧＰＰアクセス（ＧＥＲＡＮ、ＵＴＲＡＮ、Ｅ−ＵＴＲＡＮなど）およびワイヤレスローカルエリアネットワーク（ＷＬＡＮ）アクセスの両方を介して、同時に接続可能である。これらの複数のパスをＴＣＰセッション用に同時に用いることで、ネットワーク内のリソース使用率を向上させ、より高いスループットによってユーザ体感を向上させ、ネットワーク障害に対する回復力を向上させることになる。複数のアクセスを介したＭＰＴＣＰの使用により、ユーザトラフィックが、アクセスのうちの１つのみを介して、または同時に複数のアクセスを介してのいずれかで、ルーティングできることになる。さらにトラフィックは、カバレッジ、無線リンク品質、または他の要因に応じて、アクセス間でシームレスに移動できるようになる。
通常のＴＣＰにおいて、２つのホスト間の１つのＴＣＰセッションは、単一パスを介して搬送されるそれらのホスト間の１つのＴＣＰフローに対応する。本明細書の図１を参照すると、ＭＰＴＣＰにおいて、２つのホスト１、２間の１つのＴＣＰセッションは、それぞれパスを介して搬送されるそれらのホスト間の１つまたは複数のＭＰＴＣＰサブフローに対応する。サブフローは５タプル（ソースアドレス、ソースポート、宛先アドレス、宛先ポート、プロトコル）によって定義される。
図１に示されたモデルは、両方のホストがＭＰＴＣＰ対応であることが必要である。実際に、ＭＰＴＣＰはネットワークに導入される場合、増分的に導入される確率が高い。したがって、１つのホストのみがＭＰＴＣＰをサポートすることになる高リスクが存在する。この問題を克服するため、図２に示されるように、ＭＰＴＣＰプロキシ３が使用可能であることが提案されてきた。１つの使用事例は、ＭＰＴＣＰプロキシがオペレータのネットワーク内に配置され、ＭＰＴＣＰ対応ホストがオペレータによって制御されるＵＥである、ということであり得る。
図２に示されるように、ホストＡ １とホストＢ ２との間の単一のＴＣＰセッションは、ホストＡ １とプロキシノード３との間の１つまたは複数のＭＰＴＣＰサブフロー、およびプロキシノード３とホストＢ ２との間の単一のＴＣＰフローに対応する。プロキシノード３は、ホストＢ ２に向かうＭＰＴＣＰサブフローを単一ＴＣＰフローに多重化し、ホストＡ １に向かう単一フローをサブフローに逆多重化する。ＭＰＴＣＰプロキシ機能３は現在、ＩＥＴＦによって、インターネットドラフト「ｄｒａｆｔ−ｈａｍｐｅｌ−ｍｐｔｃｐ−ｐｒｏｘｉｅｓ−ａｎｃｈｏｒｓ」に規定されている。
ＲＦＣ ６１８２は、通常の／単一パスＴＣＰを、ＩＰアドレスおよびポートの単一ペア間で動作する、使用されているＴＣＰの標準バージョンとして定義している。マルチパスＴＣＰは、ホスト間での複数パスの同時使用をサポートする、ＴＣＰプロトコルの修正バージョンとして定義されている。パスは、この文脈ではソースおよび宛先のアドレスペアとして定義される送信者と受信者との間の一連のリンクとして定義されている。ホストは、マルチパスＴＣＰ接続の起点または終端となるエンドホストとして定義されている。サブフローは、より大きなマルチパスＴＣＰ接続の一部を形成する、個別のパスを介して動作するＴＣＰセグメントのフローとして定義されている。ＭＰＴＣＰ接続は、ホスト側のアプリケーションに単一のマルチパスＴＣＰサービスを提供するために組み合わされた、１つまたは複数のサブフローのセットとして定義されている。ＲＦＣ ６１８２は、ＭＰＴＣＰが、パスごとに下位の移送を提供して所望のネットワーク機能を保持するために、「サブフロー」と呼ばれる標準ＴＣＰセッション（であるようにネットワークには見える）を使用することにも言及している。ＭＰＴＣＰ特有の情報はＴＣＰ互換方法で搬送されるが、このメカニズムは転送される実際の情報とは分離している。
ネットワーク内のＭＰＴＣＰプロキシ ３の位置については異なるオプションがある。ＭＰＴＣＰプロキシ ３を「パケットデータネットワークゲートウェイ（ＰＧＷ）の下または中」、言い換えればＰＧＷとホストＡとの間、または例示のホストＡ １のアクセスネットワーク内に、配置することが可能である。これによって、両方のアクセスネットワーク（たとえば３ＧＰＰおよびＷＬＡＮアクセス）が共通のＭＰＴＣＰプロキシ ３をいかにして見つけられるか、および、両方のアクセスネットワークがその共通のＭＰＴＣＰプロキシにＭＰＴＣＰトラフィックをいかにしてルーティングできるか、という２つの問題が生じる。現在、解決策は存在していない。
ＭＰＴＣＰプロキシ機能がＰＧＷにまたはＰＧＷの下に配置された場合、２つのアクセスネットワークに共通のＭＰＴＣＰプロキシ機能の位置を両方のアクセスネットワークが特定する際に使用可能なメカニズムを提供することが、目的である。
第１の態様によれば、通信ネットワークにおいてマルチパス伝送制御プロトコル（ＭＰＴＣＰ）信号伝達を処理する方法が提供される。通信ネットワークは、ＭＰＴＣＰプロキシ機能をホストする第１のノード、および第２のアクセスネットワーク内の第２のノードを含む。第２のノードは、モバイル端末からアタッチメント要求を受信する。その後、第２のノードは、リモートデータベースにメッセージを送信して、第１のノードの識別子を含む応答を受信する。その後ＭＰＴＣＰデータパスは、第２のアクセスネットワークからＭＰＴＣＰプロキシ機能へとリダイレクトすることができる。これには、ＭＰＴＣＰプロキシ機能がＰＤＮゲートウェイおよびモバイル端末に、またはこれらの間に配置された場合であっても、第２のアクセスがＭＰＴＣＰプロキシ機能の位置に気付き、これに応じてＭＰＴＣＰデータトラフィックをルーティングできるという利点がある。
オプションとして、第２のノードはＭＰＴＣＰデータを受信し、少なくとも受信したＭＰＴＣＰデータを、ＭＰＴＣＰプロキシ機能を介してルーティングする。しかしながら、第２のノードはこの機能を実行するノードではない可能性があることに留意されたい。
他のオプションとして、第２のノードに送信されるデータがＭＰＴＣＰデータを含むかどうかが判別される。データがＭＰＴＣＰデータを含まない場合、その宛先に直接送信される。これにより、非ＭＰＴＣＰデータが不必要にリルーティングされないことが保証される。
オプションとして、リモートデータベースはユーザコンテキストデータベース（ＵＤＣ）であり、メッセージはＭＰＴＣＰプロキシ機能をホストする第１のノードの識別子に関する照会を含む。代替オプションとして、リモートデータベースはホーム加入者サーバを含む記憶機能である。
方法は、オプションとして、第２のノードとＭＰＴＣＰプロキシ機能との間にトンネルを確立することを含み、トンネルは少なくともＭＰＴＣＰデータを送信するために使用される。代替として、第２のノード自体がＭＰＴＣＰデータを処理しない場合、方法はオプションとして、ＭＰＴＣＰプロキシ機能とＭＰＴＣＰノードとの間にトンネルを確立するための命令を、第２のアクセスネットワーク内のＭＰＴＣＰノードに送信することを含み、トンネルは少なくともＭＰＴＣＰデータを送信するために使用される。
アタッチメント要求はオプションとして、モバイル端末がＭＰＴＣＰセッションの処理が可能であることを示す、ＭＰＴＣＰアタッチメントタイプインジケータを含む。
オプションとして、ＭＰＴＣＰプロキシ機能は第１のアクセスネットワーク内に配置される。
オプションの実施形態において、第２のアクセスネットワークは、ワイヤレスローカルエリアネットワーク、進化型ユニバーサル地上無線アクセスネットワーク、ＧＳＭ ＥＤＧＥ無線アクセスネットワーク、ユニバーサル地上無線アクセスネットワーク、広帯域符号分割多重アクセスネットワーク、および高速パケットアクセスネットワークのうちの、いずれかから選択される。
第２のノードはオプションとして、アクセスコントローラ、ｅノードＢ、無線ネットワークコントローラ、サービングＧＰＲＳサポートノード、モビリティ管理エンティティ、およびサービングゲートウェイのうちの、いずれかから選択される。
ＭＰＴＣＰプロキシ機能をホストする第１のノードはオプションとして、パケットデータネットワークゲートウェイ、アクセスコントローラ、ｅノードＢ、無線ネットワークコントローラ、およびサービングゲートウェイのうちの、いずれかから選択される。
第２の態様によれば、ＭＰＴＣＰプロキシ機能を介して送信される、通信ネットワーク内のＭＰＴＣＰデータを処理する方法が提供される。第１のアクセスネットワーク内の第１のノードは、モバイル端末からアタッチメント要求を受信する。第１のノードはリモートデータベースにメッセージを送信して応答を受信し、応答は、第１のノードがＭＰＴＣＰプロキシ機能をホストしてよいことを示す。次に第１のノードは、第２のアクセスネットワークからルーティングされたＭＰＴＣＰデータを受信することができる。これは有利なことに、ＭＰＴＣＰデータが２つのアクセスネットワークを介して送信されること、および１つのＭＰＴＣＰプロキシ機能を介してルーティングされることを可能にする。
第１のノードはオプションとして、パケットデータネットワークゲートウェイ、アクセスコントローラ、ｅノードＢ、無線ネットワークコントローラ、およびサービングゲートウェイのうちの、いずれかを含む。
他のオプションとして、メッセージは、ＭＰＴＣＰプロキシ機能をホストする第１のノードの識別子を記憶させるための、リモートデータベースに対する命令を含む。これによってデータベースは、他のアクセスネットワーク内のノードに情報を提供することができる。
第３の態様によれば、通信ネットワークにおいてＭＰＴＣＰプロキシ機能の識別子を判別するためのノードが提供される。ノードには、モバイル端末からアタッチメント要求を受信するための第１の受信器、リモートデータベースにメッセージを送信するための第１の送信器、およびリモートデータベース（１４、１５）から応答を受信するための第２の受信器が設けられ、応答は、ＭＰＴＣＰプロキシ機能をホストする第１のノードの識別子を含む。これによって、有利なことにノードが、ＭＰＴＣＰプロキシ機能の識別子を発見すること、およびＭＰＴＣＰトラフィックをＭＰＴＣＰプロキシ機能にルーティングする（またはルーティングを命令する）ことを可能にする。
オプションとして、ノードには、ＭＰＴＣＰデータを受信するための第３の受信器、および、受信されたＭＰＴＣＰデータをＭＰＴＣＰプロキシ機能に向けて送信するための第２の送信器が設けられる。
第４の態様によれば、ＭＰＴＣＰプロキシ機能を介して送信される通信ネットワーク内のＭＰＴＣＰ信号伝達を処理するように構成された、ノードが提供される。ノードには、モバイル端末からアタッチメント要求を受信するための第１の受信器が設けられる。リモートデータベースにメッセージを送信するための、第１の送信器が設けられる。リモートデータベースから応答を受信するための第２の受信器が設けられ、応答は、ノードがＭＰＴＣＰプロキシ機能をホストしてよいことを示す。第２のアクセスネットワーク内のノードからルーティングされたＭＰＴＣＰデータを受信するための、第３の受信器が設けられる。
第５の態様によれば、通信ネットワーク内で使用するためのモバイル端末が提供される。モバイル端末は、第１のアクセスネットワークにアタッチするための第１の要求を送信するための、第１の送信器を含み、第１の要求は、モバイル端末がＭＰＴＣＰセッションを処理できる旨のインジケータを含む。モバイル端末には、第２のアクセスネットワークにアタッチするための第２の要求を送信するための、第２の送信器も設けられ、第２の要求はインジケータを含む。
第６の態様によれば、ノード側のプロセッサ内のメモリの形式のコンピュータ可読媒体から実行された場合、第１または第２の態様において上記で説明したような方法をノードに実行させる、コンピュータ可読コードを含む、コンピュータプログラムが提供される。
第７の態様によれば、第６の態様において上記で説明したようなコンピュータ可読媒体およびコンピュータプログラムを含む、コンピュータプログラム製品が提供され、コンピュータプログラムはコンピュータ可読媒体上に記憶される。
第８の態様によれば、船舶または車両上で動作される場合、第１または第２の態様のいずれかにおいて上記で説明したような方法が提供される。
第９の態様によれば、船舶または車両に適用される場合、第３、第４、または第５の態様のうちのいずれかにおいて説明したようなノードまたはデバイスが提供される。
２つのホスト間の複数のＭＰＴＣＰサブフローを概略的に示すブロック図である。 プロキシを使用する２つのホスト間の複数のＭＰＴＣＰサブフローを概略的に示すブロック図である。 例示のネットワークアーキテクチャを概略的に示すブロック図である。 例示の実施形態に従った信号伝達を示す信号伝達図である。 ＵＥが最初に３ＧＰＰ無線アクセスネットワークを介してアタッチし、ＭＰＴＣＰプロキシ機能がｅノードＢに配置されている、例示の信号伝達を示す信号伝達図である。 ＵＥが最初に３ＧＰＰ無線アクセスネットワークを介してアタッチし、ＭＰＴＣＰプロキシ機能がＳＧＷに配置されている、例示の信号伝達を示す信号伝達図である。 ＵＥが最初にＷＬＡＮアクセスネットワークを介してアタッチし、ＭＰＴＣＰプロキシ機能がＡＣに配置されている、例示の信号伝達を示す信号伝達図である。 ＵＥが最初にＷＬＡＮアクセスネットワークを介してアタッチし、ＭＰＴＣＰプロキシ機能がＡＣに配置されている、代替の例示の信号伝達を示す信号伝達図である。 ＵＥが最初にＷＬＡＮアクセスネットワークを介してアタッチし、ＭＰＴＣＰプロキシ機能がＡＣに配置されている、他の代替の例示の信号伝達を示す信号伝達図である。 ＵＥが最初に３ＧＰＰ無線アクセスネットワークを介してアタッチし、ＭＰＴＣＰプロキシ機能がＰＧＷに配置されている、例示の信号伝達を示す信号伝達図である。 ＵＥが最初にＷＬＡＮアクセスネットワークを介してアタッチし、ＭＰＴＣＰプロキシ機能がＰＧＷに配置されている、例示の信号伝達を示す信号伝達図である。 ＵＥが最初に３ＧＰＰ無線アクセスネットワークを介してアタッチし、ＭＰＴＣＰプロキシ機能がｅノードＢに配置されており、ＭＰＴＣＰトラフィックのブレークアウトが実行される、例示の信号伝達を示す信号伝達図である。 実施形態の原理を示す汎用ネットワークアーキテクチャを概略的に示すブロック図である。 例示の実施形態に従った第１のノードでのステップを示すフロー図である。 例示の実施形態に従った第２のノードでのステップを示すフロー図である。 例示の実施形態に従った第１および第２のノードでのステップを示すフロー図である。 例示の第２のノードを概略的に示すブロック図である。 例示の第１のノードを概略的に示すブロック図である。 例示のモバイル端末を概略的に示すブロック図である。 例示の船舶または車両を概略的に示すブロック図である。
本明細書の図３を参照すると、例示のネットワークアーキテクチャが示されている。これは、３ＧＰＰ ＴＳ ２３．４０１および３ＧＰＰ ＴＳ ２３．４０２に記載されたアーキテクチャの簡略図であり、主にユーザプレーン部分を示す。図３は３ＧＰＰ側のロングタームエボリューション（ＬＴＥ）アーキテクチャを示しているが、ＷＣＤＭＡ／ＨＳＰＡなどの他のタイプの通信ネットワークに同様の技法が適用可能であることに留意されたい。この場合、ｅＮＢ ６に対応するノードは、無線ネットワークコントローラ（ＲＮＣ）またはノードＢとＲＮＣの複合となる。
ユーザ機器（ＵＥ）４などのモバイル端末は、二重無線、すなわち、１つの３ＧＰＰ無線（たとえばＬＴＥまたはＷＣＤＭＡ／ＨＳＰＡ）、および１つのＷＬＡＮ無線を有する。３ＧＰＰアクセスネットワーク５を使用する場合、ＵＥ ４は、ｅノードＢ ６およびサービングゲートウェイ（ＳＧＷ）７、続いてＰＧＷ ８を介して、ＰＤＮネットワーク内のピア９と通信する。ＷＬＡＮアクセスネットワーク１０を使用する場合、ＰＧＷ ８とＵＥ ４との間の通信は、アクセスルータであるアクセスコントローラ（ＡＣ）１１をトラバースする。この例では、ＵＥ ４はＷｉＦｉ（登録商標）のアクセスポイント（ＡＰ）を介してＡＣ １１に接続する。
アクセスネットワーク５、１０は、ＰＤＮ内のピア９への接続をＵＥ ４に提供する。こうしたＰＤＮ接続は、ＵＥ ４とＰＤＮとの間の仮想（ＩＰ）トンネルとみなすことができる。ＰＧＷ ８はＰＤＮ接続を終端する。
図３に示されたアーキテクチャは機能的であることに留意されたい。いくつかの機能を単一ノードに共同配置することが可能であるか、または機能を異なるノードに配置することができる。たとえば、ＳＧＷ ７およびＰＧＷ ８を組み合わせて単一ノードにすること、およびＡＣ １１とＲＮＣ（図示せず）とを組み合わせることが知られている。
図４の信号伝達図は、ＵＥ ４を２つのアクセスネットワーク５、１０にアタッチするための例示の信号伝達を示す。ステップＳ４０１からＳ４１１は３ＧＰＰ無線アクセスネットワーク５へのアタッチメントを示し、ステップＳ４１２からＳ４１７はＷＬＡＮ無線アクセスネットワーク１０へのアタッチメントを示す。これは、３ＧＰＰ ＴＳ ２３．４０１（セクション５．３．２）に記載されたアタッチメント手順と、３ＧＰＰ ＴＳ ２３．４０２（セクション６．２／１６．２）に記載された手順とを組み合わせた、簡略化バージョンである。たとえばステップＳ４１２は、典型的には認証およびＤＨＣＰなどの複数のステップを含む。
しかしながら、ＭＰＴＣＰプロキシ３の概念は、ＵＥ ４のトラフィックが共通ポイントを介してルーティングされる場合にのみ動作することができる。したがって、ＭＰＴＣＰプロキシ３は、その共通ポイントに配置することができる。ＭＰＴＣＰプロキシ３のアーキテクチャ的な配置に関して、いくつかのオプションが存在する。１つのオプションは、ＭＰＴＣＰプロキシ３をＰＧＷの「右に」、すなわちＩＥＴＦインターネットドラフト「ＭＰＴＣＰ ｐｒｏｘｉｅｓ ａｎｄ ａｎｃｈｏｒｓ（ＭＰＴＣＰプロキシおよびアンカ）」に記載されるように、ＰＤＮ内に配置することである。他のオプションは、ＭＰＴＣＰプロキシ３をＰＧＷ ８内に、もしくはＰＧＷ ８とＵＥ ４との間、たとえばＳＧＷ ７、ＲＮＣ、ｅＮＢ ６、またはＷｉ−Ｆｉ ＡＣ １１内に、配置することである。
ＭＰＴＣＰ対応エンドホスト（ＵＥ ４またはピア９など）は、ネットワークがＭＰＴＣＰプロキシ３を配備していることに気付かなくてもよい。このモデルは「トランスペアレントプロキシ」と呼ばれる。異なるアクセスを介するＭＰＴＣＰサブフローが同じＭＰＴＣＰプロキシ３を介してルーティングされるように保証することは、ネットワークの責務である。
代替として、ＭＰＴＣＰ対応エンドホストは、最初のＭＰＴＣＰサブフローのセットアップ時にＭＰＴＣＰプロキシ３の存在を発見してもよい。そのセットアップの一部として、ＭＰＴＣＰプロキシ３はそのＩＰアドレスをエンドホストに信号伝達する。エンドホストは、追加の（その後の）サブフローをセットアップするときにそのアドレスを使用する。このモデルでは、追加のＭＰＴＣＰサブフローが２つのエンドホスト間のルーティングパス上にある必要はない。
他の代替モデルは、明示的なＭＰＴＣＰプロキシを使用する。このモデルでは、ＭＰＴＣＰ対応エンドホストは、最初のＭＰＴＣＰサブフローのセットアップの際に、ＭＰＴＣＰプロキシ３を明示的にアドレス指定する。これには、エンドホストがＭＰＴＣＰプロキシ３のアドレスを用いて事前に設定されていることが必要である。
暗黙的および明示的なプロキシのモデルは、現在、ＩＥＴＦによってインターネットドラフト「ＭＰＴＣＰ ｐｒｏｘｉｅｓ ａｎｄ ａｎｃｈｏｒｓ（ＭＰＴＣＰプロキシおよびアンカ）」で標準化されている途中である。トランスペアレントモデルの利点は、ＩＥＴＦ標準化の必要がなく、オペレータが自身で所有するソリューションを提供できることである。
第１の例示の実施形態において、異なるアクセスからのＰＤＮ接続が共通ポイントを介してルーティングされるようにセットアップされることを保証することにより、ＵＥ ４のトラフィックは共通ポイントを介してルーティングされる。ＰＤＮ接続セットアップはアタッチメント時に実行される。これは、ＵＥ ４のトラフィック、ＴＣＰトラフィック、および他のトラフィックのすべてが、共通ポイントを介してルーティングされることを意味する。
共通ポイントは、この例ではＰＧＷ ８、ｅＮＢ ６、ＳＧＷ ７、またはＡＣ １１とすることができる。どちらのアクセスも、共通ポイントを見つけることが可能な必要がある。これを達成するための１つの方法は、ＵＥコンテキストを記憶することが可能な、ユーザコンテキストデータベース（ＵＣＤ）１４と呼ばれる共通データベースを提供することである。どちらのアクセスにおけるノードも、ＰＤＮ接続セットアップ手順の一部としてそのデータベース１４に照会することができる。ＵＤＣ １４は、ホーム加入者サーバ（ＨＳＳ）と共同配置すること、またはＨＳＳから分離されたデータベースであることが可能である。ＵＣＤ概念を動作させるために、ＵＥは、どちらのアクセスネットワーク５、１０に対しても同じＵＥとして識別され得なければならない。ＩＭＳＩが使用可能な場合、これを共通識別子として使用することができる。しかしながら、無線アクセスネットワーク１０ではＩＭＳＩが使用できない場合がある。この場合、他の識別子の使用が必要な可能性がある。
ＰＤＮ接続セットアップは、ＵＥ ４のあらゆるユーザデータ信号伝達の前に実行される。このソリューションは、ＭＰＴＣＰプロキシ３がいかにしてアドレス指定される（呼び出される）かに関係なく動作する。ＭＰＴＣＰプロキシ３は、完全にトランスペアレントとすることが可能であり、この場合、ＭＰＴＣＰプロキシ３は、この移動トラフィックがＭＰＴＣＰトラフィックであるかどうかを確かめるために、ＴＣＰオプションを検査する。ＭＰＴＣＰプロキシ３は明示的プロキシとすることが可能であり、この場合、ＭＰＴＣＰプロキシ３は、トラフィックがＭＰＴＣＰトラフィックであるかどうかを判別するために、パケットのターゲットＩＰアドレスを検査するだけでよい。暗黙的ＭＰＴＣＰプロキシ３は、最初のサブフローに対して前者を、追加のサブフローに対して後者を実行する必要がある。
以下の例では、ＵＥ ４が最初にアタッチするアクセス内にＭＰＴＣＰプロキシ機能３が存在することが想定される。そのアクセス内にＭＰＴＣＰプロキシ機能３が存在しない場合、ＭＰＴＣＰプロキシサービスは提供できない。ＭＰＴＣＰプロキシ３が両方のアクセスネットワーク５、１０に設けられていることもあるし、または、ＵＥ ４が通常は常に３ＧＰＰ無線アクセスネットワーク５に最初に接続されることが想定され得る。
図５に進むと、ＵＥ ４が最初に３ＧＰＰ無線アクセスネットワーク５を介してアタッチし、ＭＰＴＣＰプロキシ３がｅＮＢ ６に配置されているケースを示す、信号伝達図が示されている（別の変形は、ＭＰＴＣＰプロキシノード３がＲＮＣに配置される場合であることに留意されたい）。その後ＵＥは、ＷＬＡＮ無線アクセスネットワーク１０を介してアタッチする。前述のように、ＵＥ ４とピア９との間のＰＤＮ接続セットアップは、ＷＬＡＮ ＰＤＮ接続がＭＰＴＣＰプロキシ機能３を含むｅＮＢ ６を介してもルーティングされるように確立されることを保証することが重要である。以下の番号は、図５の番号に対応する。
Ｓ５０１：ＵＥ ４はアタッチ要求をｅＮＢ ６に送信する。
Ｓ５０２：ｅＮＢ／プロキシ６／３はＵＣＤ １４に照会する。ＵＣＤ １４は、ＵＥ ４が他のアクセスネットワーク内のＭＰＴＣＰプロキシ機能３を介してすでにルーティングされているかどうかを応答する。この例では、該当する他のＭＰＴＣＰプロキシ機能３は未だにない。ｅＮＢ ６は、このＵＥ ４に対してＭＰＴＣＰプロキシ３として動作する旨をＵＣＤ １４に通知する。
Ｓ５０３：ｅＮＢ ６はＭＭＥ １２を選択する。
Ｓ５０４：アタッチ要求がｅＮＢからＭＭＥ １２に送信される。
Ｓ５０５：ＭＭＥ １２はＳＧＷ ７およびＰＧＷ ８を選択する。
Ｓ５０６：ＭＭＥ １２はセッション生成要求（Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ）メッセージを選択されたＳＧＷ ７に送信する。
Ｓ５０７：ＳＧＷ ７は、セッション生成要求メッセージを、選択されたＰＧＷ ８に送信する。
Ｓ５０８：ＰＧＷ ８は、セッション生成アクノリッジメント（Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージを、ＳＧＷ ７に送信する。
Ｓ５０９：ＳＧＷ ７は、セッション生成アクノリッジメントメッセージを、ＭＭＥ １２に送信する。
Ｓ５１０：ＭＭＥはアタッチアクノリッジメント（Ａｔｔａｃｈ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージをｅＮＢ ６に送信する。
Ｓ５１１：ｅＮＢ ６はアタッチアクノリッジメントメッセージをＵＥ ４に送信する。
Ｓ５１２：この時点で、３ＧＰＰアクセスネットワーク５を介してＰＧＷ ８とＵＥ ４との間にＰＤＮ接続が確立される。
Ｓ５１３：ＷＬＡＮ無線アクセスネットワーク１０を介しても接続するために、ＵＥ ４はアタッチ要求（Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ）メッセージをＡＣ １１に送信する。
Ｓ５１４：ＡＣ １１は照会をＵＣＤ １４に送信し、ＵＣＤ １４はＵＥ ４がすでに３ＧＰＰアクセスネットワーク５内のＭＰＴＣＰプロキシ機能３を使用している旨をＡＣ １１に通知することで応答する。ＡＣ １１は、ＭＰＴＣＰプロキシ機能３のＩＰアドレスを受信する。
Ｓ５１５：ＡＣ １１は（ｅＮＢ ６によって選択されたＰＧＷ ８とは異なってよい）ＰＧＷ １３を選択する。
Ｓ５１６：ＡＣ １１は、ｅＮＢ ６のＭＰＴＣＰプロキシ３にリダイレクト要求（Ｒｅｄｉｒｅｃｔ Ｒｅｑｕｅｓｔ）メッセージを送信する。リダイレクト要求メッセージは、セッション生成要求メッセージをカプセル化しており、セッション生成要求メッセージは正常であれば選択された他のＰＧＷ １３に進む。
Ｓ５１７：ｅＮＢ ６は、選択された他のＰＧＷ １３に、セッション生成要求メッセージを送信する。
Ｓ５１８：他のＰＧＷ １３は、セッション生成アクノリッジメントメッセージを、ｅＮＢ ６に送信する。
Ｓ５１９：ｅＮＢ ６は、リダイレクトアクノリッジメントメッセージをＡＣ １１に送信する。
Ｓ５２０：ＡＣ １１は、アタッチアクノリッジメントメッセージをＵＥ ４に送信する。
Ｓ５２１：この時点で、ＷＬＡＮアクセスネットワーク１０を介して他のＰＧＷ １３とＵＥ ４との間にＰＤＮ接続が確立される。この場合、ＰＤＮ接続はＭＰＴＣＰプロキシ３をホストするｅＮＢ ６を介する。
ＵＣＤ １４は、いくつかの方法で実装可能な新機能であることに留意されたい。これはたとえば別の、既存のＨＳＳとしての機能と共同配置可能である。さらにＵＣＤへの信号伝達は、いくつかの方法のうちの１つで実装可能である。図５に示された信号伝達は例である。代替は、既存のインターフェースを用いて、ｅＮＢ ６とＵＣＤ １４との間のＭＭＥ １２を通過する信号伝達を含む。ステップＳ５０２に示された、ＵＥコンテキスト（ＭＰＴＣＰプロキシ機能３の識別子を含む）の照会／記憶は、別個の照会および記憶ステップに分割することができる。たとえば、照会は前述のようにステップＳ５０２で実施可能であるが、記憶はステップＳ５１０によってトリガ可能である。いずれのケースでも、ＵＣＤ １４は、潜在的な競合条件（すなわち、ＵＥ ４が他のアクセスネットワーク１０に同時にアタッチし、最初のアクセスネットワーク５内のＭＰＴＣＰプロキシ機能３の識別子を記憶する前に、他のアクセスネットワーク１０から照会が来る場合）を処理できる必要がある。
次に図６に進むと、ＵＥ ４が最初に３ＧＰＰ無線アクセスネットワーク５を介してアタッチし、ＭＰＴＣＰプロキシ機能３がＳＧＷ ７に配置されている、信号伝達図が示されている。
ステップＳ６０１からＳ６２１は、以下の例外を除き、ステップＳ５０１からＳ５２１に対応する。
Ｓ６０６は、（図５のステップＳ５０２の代わりに）ここではＳＧＷ／プロキシ７／３から開始される。したがって、ＳＧＷ ７に配置されたＭＰＴＣＰプロキシ機能３の識別子は、ＵＣＤ １４に記憶される。
Ｓ６１６のリダイレクト要求メッセージは、ここでもＭＰＴＣＰプロキシ機能３に向けて送信されるが、この例では、ＭＰＴＣＰプロキシ機能３はＳＧＷ ７に配置されている。
図７は、ＵＥ ４が第１にＷＬＡＮ無線アクセスネットワーク１０内でアタッチし、ＭＰＴＣＰプロキシ機能３がＡＣ １１に配置されているケースを示す。以下の番号は図７の番号に対応する。
Ｓ７０１：ＵＥ ４はアタッチ要求メッセージをＡＣ １１に送信する。
Ｓ７０２：ＡＣ １１はメッセージをＵＣＤ １４に送信する。ＭＰＴＣＰプロキシノードがすでにＵＥ ４に提供されている場合、それが使用される。この例では、ＭＰＴＣＰプロキシ機能が未だに提供されていないため、ＵＣＤ １４は、ＭＰＴＣＰプロキシ機能３がＡＣ １１に配置されている旨を示す情報を記憶する。
Ｓ７０３：ＡＣ １１は他のＰＧＷ １３を選択する。
Ｓ７０４：セッション生成要求メッセージが、他のＰＧＷ １３に送信される。
Ｓ７０５：セッション生成アクノリッジメントメッセージが、他のＰＧＷ １３からＡＣ １１に送信される。
Ｓ７０６：アタッチアクノリッジメントメッセージが、ＡＣ １１からＵＥ ４に送信される。
Ｓ７０７：この時点で、ＵＥ ４はＷＬＡＮアクセスネットワーク１０を介して他のＰＧＷ １３とのＰＤＮ接続を確立する。
Ｓ７０８：ＵＥ ４はアタッチ要求メッセージを３ＧＰＰアクセスネットワーク５内のｅＮＢ ６に送信する。
Ｓ７０９：ｅＮＢ ６は照会をＵＤＣ １４に送信し、ＵＣＤ １４は、ＭＰＴＣＰプロキシ機能３がＷＬＡＮアクセスネットワーク１０内のＡＣ １１に配置されている旨をｅＮＢ ６に通知する。
Ｓ７１０：ｅＮＢ ６はＭＭＥ １２を選択する。
Ｓ７１１：アタッチ要求メッセージをＭＭＥ １２に直接送信する代わりに、ｅＮＢ ６はリダイレクト要求メッセージに封入（カプセル化）されたその要求をＡＣ １１にリダイレクトする。
Ｓ７１２：ＡＣ １１はアタッチ要求メッセージをＭＭＥ １２に送信する。
Ｓ７１３：ＭＭＥ １２はＳＧＷ ７およびＰＧＷ ８を選択する。
Ｓ７１４：ＭＭＥ １２は、セッション生成要求メッセージを、ＳＧＷ ７に送信する。
Ｓ７１５：ＳＧＷは、セッション生成要求メッセージを、ＰＧＷ ８に送信する。
Ｓ７１６：ＰＧＷ ８は、セッション生成アクノリッジメントメッセージを、ＳＧＷ ７に送信する。
Ｓ７１７：ＳＧＷ ７は、セッション生成アクノリッジメントメッセージを、ＭＭＥ １２に送信する。
Ｓ７１８：ＭＭＥ １２は、Ｓ１ＡＰ初期コンテキストセットアップ要求（Ｓ１ＡＰ Ｉｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ）メッセージを、ＡＣ １１に送信する。
Ｓ７１９：ＡＣ １１のＭＰＴＣＰプロキシ３は、リダイレクトアクノリッジメント（Ｒｅｄｉｒｅｃｔ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージをｅＮＢ ６に送信する。
Ｓ７２０：ｅＮＢ ６は、Ｓ１ＡＰ初期コンテキストセットアップ応答メッセージで、ＡＣ １１のＭＰＴＣＰプロキシ機能３に応答する。
Ｓ７２１：ＡＣ １１のＭＰＴＣＰプロキシ機能３は、Ｓ１ＡＰ初期コンテキストセットアップ応答（Ｓ１ＡＰ Ｉｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅ）メッセージをＭＭＥ １２に送信する。
Ｓ７２３：ＭＭＥ １２は、ベアラ修正要求（Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ）メッセージをＳＧＷ ７に送信する。
Ｓ７２６：ＳＧＷ ７は、ベアラ修正応答メッセージをＭＭＥ １２に送信する。
Ｓ７２７：この時点で、３ＧＰＰアクセスネットワークを介して、ＵＥ ４とＰＧＷ ８との間にＰＤＮ接続が確立され、パケットが、ＷＬＡＮアクセスネットワーク１０内のＡＣ １１に配置されたＭＰＴＣＰプロキシ機能３を介して送信される。
ステップＳ７１２で、ｅＮＢ ６とＭＭＥ １２との間のＳ１−ＭＭＥインターフェース信号伝達は、ＵＥ ４に関するＧＴＰ−ＵトンネルをＡＣ １１を介してリダイレクトする目的で、ＡＣ １１を介して送信される。このリダイレクトを達成するために、ＡＣ １１は、Ｓ１ＡＰ初期コンテキストセットアップ要求／応答メッセージ（または、ｅＮＢとＳＧＷとの間にＧＴＰトンネルをセットアップするために使用される任意の他のメッセージ）を以下のように修正する。
・ ＡＣ １１が、Ｓ１ＡＰ初期コンテキストセットアップ要求メッセージをＭＭＥ １２から受信する時、トランスポート層アドレスおよびＧＴＰ−ＴＥＩＤ ＩＥはＳＧＷ ７によって設定された値を含む。ＡＣ １１は、ｅＮＢ ６にＡＣ １１へのアップリンクトラフィックを転送させるために、それ自体のＩＰアドレスおよび（選択された）ＴＥＩＤでＩＥを上書きする。また、ＡＣ １１は、正しいＧＴＰ−Ｕトンネル上のアップリンクトラフィックをＳＧＷ ７に向けて転送する目的で、初期のトランスポート層アドレスおよびＧＴＰ−ＴＥＩＤ ＩＥを記憶する。
・ ＡＣ １１が、Ｓ１ＡＰ初期コンテキストセットアップ応答メッセージをｅＮＢ ６から受信する時、トランスポート層アドレスおよびＧＴＰ−ＴＥＩＤの情報要素（ＩＥ）はｅＮＢ ６によって設定された値を含む。ＡＣ １１は、ＳＧＷ ７にＡＣ １１へのダウンリンクトラフィックを転送させるために、ＡＣ １１自体のＩＰアドレスおよび（選択された）ＴＥＩＤでこれらのＩＥを上書きする。また、ＡＣ １１は、正しいＧＴＰ−Ｕトンネル上のダウンリンクトラフィックをｅＮＢ ６に向けて転送する目的で、初期のトランスポート層アドレスおよびＧＴＰ−ＴＥＩＤ ＩＥを記憶する。
別の変形は、ｅＮＢ ６とＭＭＥ １２との間のＳ１−ＭＭＥインターフェースをそのまま維持することである。ここでは代わりに、ステップＳ７０９の結果（ＵＥ ４のためのＭＰＴＣＰプロキシノード３がＡＣ １１に配置されている）に基づき、ｅＮＢ ６とＡＣ １１との間に以下のように新しい信号伝達が追加される。
１．ｅＮＢ ６は、ＧＴＰ−Ｕトンネル識別子、すなわち、ＳＧＷのＩＰアドレスおよびトンネルエンドポイント識別子（ＴＥＩＤ）を含む、任意のメッセージを受信した場合、以下の動作を実行する。
・ ２つのローカル識別子、ＵＥ ＩＤおよびベアラＩＤを作成し、これらをこのベアラのためのローカルＵＥコンテキスト内に記憶する。ＵＥ ＩＤはたとえばｅＮＢとＵＥのＳ１ＡＰのＩＤとすることが可能であり、ベアラＩＤはたとえばＥＲＡＢ−ＩＤとすることが可能である。
・ また、ローカルＧＴＰ−Ｕトンネル識別子、すなわちｅＮＢのＩＰアドレスおよびＴＥＩＤも選択する。
・ アップリンクのためにＳＧＷのＩＰアドレスおよびＴＥＩＤ、ダウンリンクのためにｅＮＢのＩＰアドレスおよびＴＥＩＤ、ＵＥ ＩＤ、ならびにベアラＩＤを含む、第１の新規メッセージを作成する。
・ 第１の新規メッセージはＡＣ １１に送信される。
・ 加えて、ｅＮＢ ６は上記の情報をすべてローカルに記憶する。
２．ＡＣ １１は第１の新規メッセージを受信すると、以下の動作を実行する。
・ 受信した情報は、２つの異なるＧＴＰ−Ｕトンネルを、１つはｅＮＢとＡＣとの間、およびもう１つはＡＣ １１とＳＧＷ ７との間に作成するために使用される。
・ ＡＣ １１とＳＧＷ ７との間のＧＴＰ−Ｕトンネルのために、ＡＣ １１は、受信したＳＧＷのＩＰアドレスおよびＴＥＩＤを、ＳＧＷ ７に向かうＧＴＰ−Ｕトンネルに関する宛先情報として使用し始める。また、ＡＣ １１は、ローカルＧＴＰ−Ｕトンネル識別子、すなわちＳＧＷ ７がＡＣ １１に向けて使用するためのＡＣのＩＰアドレス２およびＴＥＩＤ−２を選択する。
・ ＡＣ １１とｅＮＢ ６との間のＧＴＰ−Ｕトンネルのために、ＡＣ １１は、受信したｅＮＢのＩＰアドレスおよびＴＥＩＤを、ｅＮＢ ６に向かうＧＴＰ−Ｕトンネルに関する宛先情報として使用し始める。また、ＡＣ １１は、ローカルＧＴＰ−Ｕトンネル識別子、すなわちｅＮＢ ６がＡＣ １１に向けて使用するためのＡＣのＩＰアドレス１およびＴＥＩＤ−１を選択する。
・ ＡＣ １１は第２の新規メッセージを第１の新規メッセージに対する応答として作成し、ＵＥ ＩＤおよびベアラＩＤ、ＡＣのＩＰアドレス１およびＴＥＩＤ−１、ならびにＡＣのＩＰアドレス２およびＴＥＩＤ−２を含める。
・ このメッセージはｅＮＢ ６に返送される。
３．ｅＮＢ ６はＡＣ １１から応答メッセージを受信すると、以下の動作を実行する。
・ ＡＣのＩＰアドレス１およびＴＥＩＤ−１に関する受信した情報は、ＡＣ １１に向かうＧＴＰ−ＵトンネルのためにｅＮＢによって使用される。
・ ＡＣのＩＰアドレス２およびＴＥＩＤ−２に関する受信した情報は、ＲＡＮにおける宛先ＧＴＰ−Ｕトンネル情報として、コアネットワーク（すなわちＭＭＥ）に向けて応答するために、ｅＮＢ ６によって使用される。このケースでは、ＩＰアドレスはＡＣ １１に向かう。
上記のステップは、図８のステップＳ８０１からＳ８２８でより詳細に示される。
代替実施形態として、ｅＮＢ ６が照会をＵＣＤ １４に送信する代わりに、図９のステップＳ９０１からＳ９２６に示された信号伝達図に示されるように、ＭＭＥ １２がこのステップを実行することができる。結果として生じるＰＤＮ接続のルートは、同様に、ＵＥ−ｅＮＢ−ＡＣ−ＳＧＷ−ＰＧＷである。
他の変形は、ＳＧＷ ７がＵＣＤ １４の照会／記憶ステップを実行することであることを理解されよう。この場合、結果として生じるＰＤＮ接続は、ＵＥ−ｅＮＢ−ＳＧＷ−ＡＣ−ＰＧＷとルーティングされる。
上記で説明され、図５から図９に示される実施形態は、ネットワークベースのＰＤＮ接続セットアップリダイレクトが実装される場合である。図５から図９に示される手順は、ネットワーク内で完全に実装されるソリューションを提供する。ＵＥ ４は、ＰＤＮ接続セットアップに関しては、影響を受けない。しかしながら、アタッチメント時には、信号伝達をＵＥ ４からネットワークに延長することが可能である。
ＭＰＴＣＰプロキシ機能３がＰＧＷ ８に配置される場合を想定してみる。ＵＥ ４は、アタッチ要求メッセージに「ＭＰＴＣＰ」を示すことができる。ＡＰＮ（アクセスポイント名、ＰＤＮの名前）と共に、ネットワークは、異なるアクセス上のＰＤＮ接続が同じＰＧＷ ８に行き着くことを保証することができる。手順は、３ＧＰＰ無線アクセスとＷＬＡＮ無線アクセスとの間のハンドオーバの既存の手順に非常に類似するものとなる。
図１０の信号伝達は、ＵＥ ４が最初に３ＧＰＰ無線に接続する場合の手順を示し、以下の番号は図１０の番号に対応する。
Ｓ１００１：ＵＥ ４はアタッチ要求メッセージをｅＮＢ ６に送信する。このアタッチ要求メッセージは新規の「要求タイプ」を示す。既存の要求タイプは「初期アタッチ（Ｉｎｉｔｉａｌ Ａｔｔａｃｈ）」および「ハンドオーバアタッチ（Ｈａｎｄｏｖｅｒ Ａｔｔａｃｈ）」を含む。「ＭＰＴＣＰアタッチ（ＭＰＴＣＰ Ａｔｔａｃｈ）」などの新規の要求タイプが使用可能である。要求タイプは、オプションのＡＰＮと共にステップＳ１００１に含まれる。
Ｓ１００２：ｅＮＢ ６はＭＭＥ １２を選択する。
Ｓ１００３：ｅＮＢ ６は要求タイプをＭＭＥ １２に転送する。ＭＭＥは加入者データをキャッシュに入れているか、または入れていない場合、ＨＳＳ １５に照会し（ステップＳ１００４およびＳ１００５）、ＵＥ ４がすでにいずれか（すなわち非３ＧＰＰアクセス上）にアタッチされているかどうかを見つける。この例では、このケースには当てはまらず、アタッチ手順が続行される。
Ｓ１００６〜Ｓ１０１２：３ＧＰＰアクセスネットワーク５へのアタッチメントが完了する。
Ｓ１０１３：ＭＭＥ １２はこのＵＥ ４について選択されたＰＧＷ ８、ＡＰＮ、およびアタッチメントタイプを、ＨＳＳ １５に通知する。
Ｓ１０１４：この時点で、ＵＥ ４は３ＧＰＰアクセスネットワーク５を介したＰＧＷ ８とのＰＤＮ接続を有する。
Ｓ１０１５：ＵＥ ４は、ＷＬＡＮアクセスネットワーク１０を介してもアタッチする。この場合、ＵＥ ４はＡＣ １１にアタッチ要求メッセージを送信し、アタッチ要求メッセージは要求タイプに「ＭＰＴＣＰアタッチ」と示している。
Ｓ１０１６〜Ｓ１０１７：ＡＣ １１は認証の一部としてＵＥ ４のプロファイルを受信する。このＵＥ ４のプロファイルから、ＡＣ １１は、ＵＥ ４がすでに３ＧＰＰアクセスネットワーク５を介して「ＭＰＴＣＰアタッチ」されているものと判定する。
Ｓ１０１８：ＰＧＷ ＩＤがＵＥプロファイルに含まれる場合、ＡＣ １１は３ＧＰＰアクセスネットワーク５で選択済のと同じＰＧＷを選択する。結果として、両方のＰＤＮ接続が１つの同じＰＧＷ ８を介してルーティングされる。したがって、これが、ＭＰＴＣＰプロキシ機能３にとって最善のロケーションである。
Ｓ１０１９〜Ｓ１０２２：アタッチメント手順は、ＵＥ ４とＰＧＷ ８との間にＰＤＮ接続が確立されるまで続行される。
ＵＥ ４が最初にＷＬＡＮアクセスネットワーク１０にアタッチする場合、同様の呼フローが実行可能であることを理解されよう。これが、図１１のステップＳ１１０１からＳ１１２２に示されている。ここでは、ＨＳＳ １５への通知は、ＰＧＷ ８から送信される（ステップＳ１１０６）。ＭＭＥ １２は、ロケーション更新アクノリッジメント（Ｕｐｄａｔｅ ｌｏｃａｔｉｏｎ ａｃｋｎｏｅｌｅｄｇｅｍｅｎｔ）メッセージの一部として、ＵＥ ４のプロファイルを受信する（ステップＳ１１１４）。
図１０および１１の呼フローに伴う潜在的な問題は、３ＧＰＰ仕様（３ＧＰＰ Ｒｅｌ １１）が、ＵＥ ４がデタッチするときにＨＳＳ内のユーザプロファイルがクリーンアップされることを義務付けていないという事実から生じる。ＵＥ ４が常に「ＭＰＴＣＰアタッチ」を示す場合、ロケーション更新アクノリッジメントメッセージ（３ＧＰＰアクセスネットワーク５）または認証アクノリッジメントメッセージ（ＷＬＡＮアクセスネットワーク１０）のいずれかで受信されたこのＵＥ ４のプロファイルおよびＡＰＮは、常に、選択されたＰＧＷのＩＤを示すことになる。これは、ＵＥ ４が他のアクセスネットワークからすでにデタッチしている場合であっても生じることになる。この結果、ＵＥ ４は、その寿命全体にわたって１つの同じＰＧＷ ８に「スタック」される（とどめられる）ことになる。これにより、システム全体のスケーラビリティが大幅に制限される。上記の呼フローを動作させるためには、ＨＳＳ １５のクリーンアップ機能が必要である。これはたとえば、ＵＥ ４がデタッチする時のＰＧＷ ８からＨＳＳ １５への明示的なクリーンアップ信号の形を取ることができる。別の例は、ＵＥ ４が依然としてアタッチされているかどうかをＨＳＳ １５が定期的にチェックすることであり得る。アタッチされていない場合、ＨＳＳ １５はＵＥ ４プロファイルをクリーンアップする。
他の変形は、最初のアクセスネットワークにアクセスする際にＵＥ ４にＭＰＴＣＰプロキシ機能３のアドレスを通知し、その後ＵＥ ４は、最初のアクセスにおけるＭＰＴＣＰプロキシ機能のアドレス／ロケーションを、第２のアクセスネットワークに通知することである。これによって、（３ＧＰＰ Ｒｅｌ １１ではサポートされていない）両方のアクセスネットワークを介して同じＡＰＮにアタッチする必要がなくなる。これにより、前述のクリーンアップ問題も解決される。
他の実施形態において、ＵＥに支援されるセットアップおよびネットワークベースのセットアップの組み合わせが提案される。このケースでは、ＵＥ ４は、ＰＤＮ接続確立信号伝達内に「ＭＰＴＣＰアタッチ」インジケーションを提供し、ネットワークはこのインジケーションを使用して、図５から９のいずれかに関して上記したネットワークベースのＰＤＮ接続セットアップリダイレクトを実行すべきであるかどうかを決定する。こうした手法に伴う特典は、ＵＥ ４がＭＰＴＣＰの使用を明示的に要求するシナリオにおいて、ネットワークが、ネットワークベースのＰＤＮ接続セットアップリダイレクトのみを実行することである。
「ＭＰＴＣＰアタッチ」要求は（３ＧＰＰアクセスネットワーク５内の）ＮＡＳ信号伝達で送信され、ＭＭＥ １２によって解析されることになるであろうから、この手法は、少なくとも、ＭＰＴＣＰプロキシ機能３がＳＧＷ ７またはＡＣ １１内に配置される場合に奏功する。ＭＰＴＣＰプロキシ機能３がｅＮＢ ６内に配置される場合には、たとえばＵＥ ４の要求をｅＮＢ ６に送信するために、ＭＭＥ １２からｅＮＢ ６へのさらなる信号伝達が必要である。
図５から１１に関して上記した実施形態は、第２のアクセスネットワークを介したＰＤＮ接続全体がＭＰＴＣＰプロキシ機能３を介してルーティングされるソリューションを提案している。代替のソリューションは、第２のアクセスネットワーク内にも通常のＰＤＮ接続をセットアップし、そのＰＤＮ接続から第１のアクセスネットワーク内のＭＰＴＣＰプロキシ機能３へのＭＰＴＣＰトラフィックのみをブレークアウトするものということになろう。
図１２は、ＵＥ ４が最初に３ＧＰＰアクセスネットワークにアタッチし、ＭＰＴＣＰプロキシ機能３がｅＮＢ ６に配置されている例を示す。ＳＧＷ ７またはＡＣ １１がＭＰＴＣＰプロキシ機能を含む場合にも、同様の概念が適用可能である。この観念は、ＭＰＴＣＰプロキシ機能３がＰＧＷ ８内に共同配置されている場合にも適用可能である。ＵＥが最初にアタッチするアクセス内に、ＭＰＴＣＰプロキシ機能が存在するものと想定される。そのアクセス内にＭＰＴＣＰプロキシ機能が存在しない場合、ＭＰＴＣＰプロキシサービスは提供できない。オペレータは両方のアクセスネットワーク内にＭＰＴＣＰプロキシ機能を設けることができるか、または、ＵＥ ４が通常は常に３ＧＰＰ無線アクセスに最初に接続されることが想定され得る。以下の番号は図１２の番号に対応する。
Ｓ１２０１：ＵＥ ４はアタッチ要求メッセージをｅＮＢ ６に送信する。
Ｓ１２０２：ｅＮＢ／プロキシ６／３はＵＣＤ １４に照会する。ＵＣＤ １４は、ＵＥ ４がすでに他のアクセスネットワーク内のＭＰＴＣＰプロキシ機能３を介してルーティングされているかどうかを応答する。この例では、該当する他のＭＰＴＣＰプロキシ機能３は未だにない。ｅＮＢ ６は、このＵＥ ４に対してＭＰＴＣＰプロキシ機能３を提供する旨をＵＣＤ １４に通知する。
Ｓ１２０３：ｅＮＢ ６はＭＭＥ １２を選択する。
Ｓ１２０４：アタッチ要求メッセージがｅＮＢからＭＭＥ １２に送信される。
Ｓ１２０５：ＭＭＥ １２はＳＧＷ ７およびＰＧＷ ８を選択する。
Ｓ１２０６：ＭＭＥ １２はセッション生成要求メッセージを選択されたＳＧＷ ７に送信する。
Ｓ１２０７：ＳＧＷ ７は、セッション生成要求メッセージを、選択されたＰＧＷ ８に送信する。
Ｓ１２０８：ＰＧＷ ８は、セッション生成アクノリッジメントメッセージを、ＳＧＷ ７に送信する。
Ｓ１２０９：ＳＧＷは、セッション生成アクノリッジメントメッセージを、ＭＭＥ １２に送信する。
Ｓ１２１０：ＭＭＥはアタッチアクノリッジメントメッセージをｅＮＢ ６に送信する。
Ｓ１２１１：ｅＮＢ ６はアタッチアクノリッジメントメッセージをＵＥ ４に送信する。
Ｓ１２１２：この時点で、３ＧＰＰアクセスネットワーク５を介してＰＧＷ ８とＵＥ ４との間にＰＤＮ接続が確立される。
Ｓ１２１３：ＷＬＡＮ無線アクセスネットワーク１０を介しても接続するために、ＵＥ ４はアタッチ要求メッセージをＡＣ １１に送信する。
Ｓ１２１４：ＡＣ １１は照会をＵＣＤ １４に送信し、ＵＣＤ １４はＵＥ ４がすでに３ＧＰＰアクセスネットワーク５内のＭＰＴＣＰプロキシ機能３を使用している旨をＡＣ １１に通知することで応答する。ＡＣ １１は、ＭＰＴＣＰプロキシ機能３のＩＰアドレスを受信する。ＡＣはＭＰＴＣＰプロキシ機能３へのトンネルをセットアップすることができる（フローチャートには図示せず）。したがって、その後、そのトンネルを使用して、ＡＣ １１からＭＰＴＣＰプロキシ機能３にＭＰＴＣＰパケットを移送することができる。
Ｓ１２１５：ＡＣ １１は（ｅＮＢ ６によって選択されたＰＧＷ ８とは異なってよい）他のＰＧＷ １３を選択する。
Ｓ１２１６：ＡＣ １１は、選択された他のＰＧＷ １３に、セッション生成要求メッセージを送信する。
Ｓ１２１７：他のＰＧＷ １３は、セッション生成アクノリッジメントメッセージを、ＡＣ １１に送信する。
Ｓ１２１８：ＡＣ １１は、アタッチアクノリッジメントメッセージをＵＥ ４に送信する。
Ｓ１２１９：この時点で、ＷＬＡＮアクセスネットワーク１０を介してさらなるＰＧＷ １３とＵＥ ４との間にＰＤＮ接続が確立される。
Ｓ１２２０からＳ１２２５：ＩＥＴＦインターネットドラフト「ｄｒａｆｔ−ｉｅｔｆ−ｍｐｔｃｔ−ｍｕｌｔｉａｄｄｒｅｓｓｅｄ」に規定されるように、最初のＭＰＴＣＰサブフローがセットアップされる。
Ｓ１２２６からＳ１２３０：第２のＭＰＴＣＰサブフローが、インターネットドラフトに記載されているような「ジョイン（ｊｏｉｎ）」メッセージを用いてセットアップされる。しかしながら、ＡＣ １１は「ＭＰＴＣＰブレークアウト機能」（ＭＢＦ）を含む。ＭＢＦはＷＬＡＮ ＰＤＮ接続を介して移送されるパケットのＴＣＰヘッダを検査する。非ＭＰＴＣＰパケットは、単にＰＤＮ接続を介して他のＰＧＷ １３に移送される。しかしながら、ＭＰＴＣＰパケットはＰＤＮ接続からブレークアウトされ、ステップＳ１２１４でセットアップされたトンネルを介してＭＰＴＣＰプロキシ機能３にルーティングされる。ＭＰＴＣＰプロキシ機能３がトランスペアレントでない場合、ＵＥ ４はステップＳ１２２６で、ＭＰＴＣＰプロキシ機能３のＩＰアドレスを使用することになる。そのため、ＴＣＰヘッダ内のＭＰＴＣＰオプションを検査する必要がなくなる。
図１２に示された実施形態は、ブレークアウト機能がＡＣ １１に配置されたシナリオに関することに留意されたい。ブレークアウト機能は、ＰＧＷ ８、ｅＮＢ ６、またはＳＧＷ ７などの、代替機能にも配置可能であることを理解されよう。
図１３に進むと、上記で説明した原理を示す汎用ネットワークアーキテクチャが示されている。ＵＥ ４などのモバイル端末は、ＰＧＷ ８とのＰＤＮ接続を確立するために、第１のアクセスネットワーク１７内の第１のノード１６を介してアタッチする。前述のように、例示の実施形態において、第１のノード１６はＭＰＴＣＰプロキシ機能３に対するホストとなる。ＵＥ ４は、ＰＧＷ ８（または他のＰＧＷ １３）との他のＰＤＮ接続を確立するために、第２のアクセスネットワーク１９内の第２のノード１８を介してもアタッチする。第２のアクセスネットワーク１９内の第２のノード１８がＭＰＴＣＰデータを処理できるか、またはＭＰＴＣＰデータは、別のＭＰＴＣＰノード１８ａによって第２のアクセスネットワーク１９内で処理され得ることに留意されたい。この場合、第２のノード１８は、ＭＰＴＣＰデータを、第１のノードに配置されたＭＰＴＣＰプロキシ機能３にリダイレクトするようにＭＰＴＣＰノード１８ａに命じるか、または他の方法でこれを保証することが必要である。第１および第２のノード１６、１８は、リモートデータベース（前述のように、これはＵＣＤ １４、ＨＳＳ １５、または他のタイプのデータベースとすることができる）へのアクセスを有する。第１のアクセスネットワーク１７および第２のアクセスネットワーク１９は、ＷＬＡＮアクセスネットワーク、３ＧＰＰアクセスネットワーク、または任意の他のタイプの無線アクセスネットワークのうちの、いずれかとすることができることが明らかであろう。
図５に示された例では、第１のノードはｅＮＢ ６であり、第２のノードはＡＣ １１である。図６の例では、第１のノードはＳＧＷ ７であり、第２のノードはＡＣ １１である。図７および８の例では、第１のノードはＡＣ １１であり、第２のノードはｅＮＢ ６である。図９の例では、第１のノードはＡＣ １１であり、第２のノードはＭＭＥ １２である。図１０の例では、第１のノードはｅＮＢ ６であり、第２のノードはＡＣ １１である。図１１の例では、第１のノードはＡＣ １１であり、第２のノードはｅＮＢ ６である。図１の例では、第１のノードはｅＮＢ ６であり、第２のノードはＡＣ １１である。
図１４、１５、および１６に進むと、前述の様々な実施形態に従ったステップを示すフロー図が示されている。以下の番号は図１４から１６の番号に対応する。
Ｓ１４０１：第１のアクセスネットワーク１７内の第１のノード１６は、ＵＥ ４からアタッチ要求メッセージを受信する。
Ｓ１４０２：第１のノード１６は、リモートデータベース１４、１５に向けてメッセージを送信する。
Ｓ１４０３：リモートデータベースは応答し、第１のノードはＭＰＴＣＰプロキシ機能３との共同配置となる。リモートデータベースには第１のノード１６の識別子が提供される。
Ｓ１５０１：第２のアクセスネットワーク１９内の第２のノード１８は、ＵＥ ４からアッタッチメント要求を受信する。
Ｓ１５０２：第２のノード１８は、リモートデータベース１４、１５にメッセージを送信する。
Ｓ１５０３：リモートデータベースは、ＭＰＴＣＰプロキシ機能３と共同配置された第１のノード１６の識別子を、第２のノード１８に返信する。
Ｓ１５０４：第２のアクセスネットワーク１９はＭＰＴＣＰデータを受信する（これは、第２のアクセスネットワーク１９内の第２のノード１８またはＭＰＴＣＰノード１８ａで受信してもよい）。
Ｓ１５０５：第２のアクセスネットワーク１９に送信されるＭＰＴＣＰサブフローは、第１のノード１６に配置されたＭＰＴＣＰプロキシ機能３を介してルーティングされる。
Ｓ１４０４：第１のノード１６にあるＭＰＴＣＰ機能３は、第２のアクセスネットワーク１９からリダイレクトされたＭＰＴＣＰトラフィックを受信する。
このように、セッションに関するすべてのＭＰＴＣＰサブフローはＭＰＴＣＰプロキシ機能３をトラバースする。
図１７は、第２のノード１８を概略的に示すブロック図である。前述のように、第２のノード１８は、たとえばＰＤＮ、ＡＣ、ｅノードＢ（ｅＮＢ）、ＲＮＣ、ＳＧＷ、ＭＭＥ、ＳＧＳＮなどとすることができる。第２のノード１８には、ＵＥ ４からアタッチメント要求を受信するための第１の受信器２０が設けられている。ＵＣＤ／ＨＳＳ １４、１５にメッセージを送信するために、第１の送信器２１が設けられている。ＵＣＤ／ＨＳＳ １４、１５から応答を受信するために、第２の受信器２２も設けられている。応答は、ＭＰＴＣＰプロキシ機能３をホストするノード１６の識別子を含む。ノード１８がＭＰＴＣＰデータトラフィックを処理する本発明の実施形態において、ノードには、ＭＰＴＣＰデータを受信するための第３の受信器２３、および受信したＭＰＴＣＰデータをＭＰＴＣＰプロキシ機能３に向けて送信するための第２の送信器２４も設けられている。
図１７に示される様々な送信器および受信器は機能的表現でのみ説明されており、物理的表現では、異なるメッセージを送信するために同じ送信器を使用することが可能であり、異なるメッセージを受信するために同じ受信器を使用することが可能であることを理解されよう。第２のノード１８には、メッセージの送信および受信のために、いかなる数の物理的な送信器、受信器、または送受信器を設けてもよい。
第２のノード１８および信号伝達を制御するために、プロセッサ２５が設けられている。メモリ２６の形のコンピュータ可読媒体を設けてもよい。これは、プロセッサ２５によって実行された場合、ノード１８を前述のように挙動させるプログラム２７を記憶するために使用可能である。
図１８は、図１３に示されるような第１のアクセスネットワーク１７内の第１のノード１６を概略的に示す。第１のノード１６には、ＵＥ ４からアタッチメント要求を受信するための第１の受信器２８が設けられている。ＵＣＤ／ＨＳＳ １４、１５にメッセージを送信するために、第１の送信器２９が設けられている。ＵＣＤ／ＨＳＳ １４、１５から応答を受信するために、第１の受信器３０も設けられている。応答は、第１のノード１６がＭＰＴＣＰプロキシ機能３をホストしてよいことを示す。第１のノードには、第２のアクセスネットワーク１９から送信されるＭＰＴＣＰデータを受信するための第３の受信器３１も設けられている。
図１８に示される様々な送信器および受信器は機能的表現でのみ説明されており、物理的表現では、異なるメッセージを送信するために同じ送信器を使用することが可能であり、異なるメッセージを受信するために同じ受信器を使用することが可能であることを理解されよう。第１のノード１６には、メッセージの送信および受信のために、いかなる数の物理的な送信器、受信器、または送受信器を設けてもよい。
第１のノード１６および信号伝達を制御するために、プロセッサ３３が設けられている。メモリ３４の形のコンピュータ可読媒体を設けてもよい。これは、プロセッサ３３によって実行された場合、第１のノード１６を前述のように挙動させるプログラム３５を記憶するために使用可能である。
図１９は、ＵＥ ４などのモバイル端末を概略的に示す。ＵＥ ４には、第１のアクセスネットワーク１７にアタッチするための第１の要求を送信するために、第１の送信器３６が設けられている。この要求は、ＵＥ ４がＭＰＴＣＰセッションを処理できる旨のインジケータを含む。第２のアクセスネットワーク１９にアタッチするための第２の要求を送信するために、第２の送信器３７も設けられ、第２の要求もこのインジケータを含む。これにより、ＵＥ ４がＭＰＴＣＰセッションを処理可能であること、および、アクセスネットワークのうちの１つにある単一のＭＰＴＣＰ（または１つのＰＧＷにある単一のＭＰＴＣＰ）が使用可能であることを保証するように協調可能であることに、両方のアクセスネットワークが気付くことが保証される。
図１９に示される送信器は機能的表現でのみ説明されており、物理的表現では、両方のメッセージを送信するために同じ送信器を使用することが可能であることを理解されよう。ＵＥ ４には、メッセージを送信および受信するために、いかなる数の物理的な送信器、受信器、または送受信器を設けてもよい。
ＵＥ ４および信号伝達を制御するために、プロセッサ３８が設けられている。メモリ３９の形のコンピュータ可読媒体が設けられてもよい。これは、プロセッサ３８によって実行された場合、ＵＥ ４を前述のように挙動させるプログラム４０を記憶するために使用可能である。
図２０を参照すると、船、列車、乗用車、トラックなどの車両または船舶４１がブロック図内に概略的に示されている。この船舶または車両４１には、第１のノード１６、第２のノード１８、またはＵＥ ４のうちのいずれかを配置することができる。
前述の技法により、ＭＰＴＣＰプロキシの識別子をネットワークアーキテクチャ内で特定することができる。この技法は、ＭＰＴＣＰプロキシ機能３の存在に気付くことが必要な他のノードに、ＭＰＴＣＰプロキシ機能の存在を気付かせる際に使用可能なメカニズムも提供する。当業者であれば、本開示の範囲を逸脱することなく、前述の実施形態に対して様々な修正が実行可能であることを理解されよう。たとえば、ネットワークノードの機能は単一ノードで具体化されるように説明されているが、異なるネットワークノードで異なる機能が提供可能であることを理解されよう。さらに、上記の説明はＵＥがモバイル端末であるものと想定しているが、同じ技法が、様々なタイプのモバイル端末、およびモバイル端末が複数のアクセスネットワークを介してネットワークにアクセスできるＭＰＴＣＰを使用する通信ネットワークを使用する、任意のタイプの通信アクセスネットワーク内で使用可能であることを理解されよう。
上記の説明では、以下の頭字語が使用されている。
３ＧＰＰ 第３世代パートナーシッププロジェクト
ＡＣ アクセスコントローラ
ＡＰ アクセスポイント
ｅＮＢ ｅノードＢ
Ｅ−ＵＴＲＡＮ 進化型ユニバーサル地上無線アクセスネットワーク
ＧＥＲＡＮ ＧＳＭ ＥＤＧＥ無線アクセスネットワーク
ＨＳＰＡ 高速パケットアクセス
ＨＳＳ ホーム加入者サーバ
ＩＥＴＦ インターネットエンジニアリングタスクフォース
ＩＭＳＩ 国際移動電話加入者識別番号
ＩＰ インターネットプロトコル
ＬＡＮ ローカルエリアネットワーク
ＬＴＥ ロングタームエボリューション
ＭＢＦ ＭＰＴＣＰブレークアウト機能
ＭＭＥ モビリティ管理エンティティ
ＭＰＴＣＰ マルチパスＴＣＰ
ＰＤＮ パケットデータネットワーク
ＰＧＷ ＰＤＮゲートウェイ
ＲＡＮ 無線アクセスネットワーク
ＲＮＣ 無線ネットワークコントローラ
ＳＧＳＮ サービングＧＰＲＳサポートノード
ＳＧＷ サービングゲートウェイ
ＴＣＰ 伝送制御プロトコル
ＵＥ ユーザ機器
ＵＴＲＡＮ ユニバーサル地上無線アクセスネットワーク
ＷＣＤＭＡ 広帯域符号分割多重アクセス
ＷＬＡＮ ワイヤレスＬＡＮ

Claims (25)

  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. 船舶または車両（４１）に適用される請求項１８から２０のいずれか一項に記載のノード。
JP2015546870A 2012-12-14 2012-12-14 通信ネットワークにおけるマルチパス伝送制御プロトコル信号伝達の処理 Active JP6301358B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2012/075619 WO2014090335A1 (en) 2012-12-14 2012-12-14 Handling multipath transmission control protocol signalling in a communications network

Publications (2)

Publication Number Publication Date
JP2016508308A JP2016508308A (ja) 2016-03-17
JP6301358B2 true JP6301358B2 (ja) 2018-03-28

Family

ID=47469965

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015546870A Active JP6301358B2 (ja) 2012-12-14 2012-12-14 通信ネットワークにおけるマルチパス伝送制御プロトコル信号伝達の処理

Country Status (6)

Country Link
US (1) US9998569B2 (ja)
EP (1) EP2932675B1 (ja)
JP (1) JP6301358B2 (ja)
KR (1) KR101820583B1 (ja)
CN (1) CN104854837B (ja)
WO (1) WO2014090335A1 (ja)

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2854357A1 (en) * 2013-09-30 2015-04-01 Thomson Licensing Method for connecting a first host and a second host within at least one communication network through a relay module, corresponding relay module
CN106465436A (zh) * 2014-04-04 2017-02-22 诺基亚技术有限公司 利用多路径传输进行访问管理
EP3175595B1 (en) 2014-07-31 2018-07-11 Telefonaktiebolaget LM Ericsson (publ) Routing of mptcp subflows
EP3195683A1 (en) * 2014-08-25 2017-07-26 Nokia Technologies Oy Methods and apparatus for wireless connection management
EP3213584B1 (en) * 2014-10-30 2020-02-26 Telefonaktiebolaget LM Ericsson (publ) Handling of backup path in a wireless communication system
US9681481B2 (en) 2014-12-19 2017-06-13 At&T Intellectual Property I, L.P. Mobility management of wireless networks based on multipath transfer control protocol
EP3269109B1 (en) 2015-03-12 2019-01-09 Telefonaktiebolaget LM Ericsson (publ) Methods and arrangements for multipath traffic aggregation
GB2539677A (en) * 2015-06-23 2016-12-28 Vodafone Ip Licensing Ltd Multi-path telecommunications networks
US10602560B2 (en) * 2015-06-26 2020-03-24 Telefonaktiebolaget Lm Ericsson (Publ) First network node and methods therein, for determining whether a second multi path transmission control protocol connection is to be initiated
FR3038475A1 (fr) * 2015-07-01 2017-01-06 Orange Procede d' optimisation de la charge d' un concentrateur de connexions reseau
CN107431872A (zh) * 2015-07-28 2017-12-01 松下电器（美国）知识产权公司 终端装置及通信方法
KR102411188B1 (ko) * 2015-11-30 2022-06-21 삼성전자주식회사 무선 통신 시스템에서의 혼잡 관리 장치 및 방법
US10880413B2 (en) * 2016-01-26 2020-12-29 Nec Corporation Method and server for establishing a TCP connection
US9992786B2 (en) 2016-03-31 2018-06-05 At&T Intellectual Property I, L.P. Facilitation of multipath scheduling
US10193781B2 (en) 2016-04-14 2019-01-29 At&T Intellectual Property I, L.P. Facilitation of multipath transmission control protocols
FR3053196A1 (fr) * 2016-06-24 2017-12-29 Orange Procede de communication udp via des chemins multiples entre deux terminaux
KR101769344B1 (ko) * 2016-06-30 2017-08-21 (주)넷비젼텔레콤 다중 경로 환경에서의 서비스 플로우 별 mp-gw 포트 매핑 방법 및 시스템
CN108075987B (zh) 2016-11-17 2020-12-08 华为技术有限公司 一种多路径数据传输方法及设备
DE102016225892A1 (de) * 2016-12-21 2018-06-21 Robert Bosch Gmbh Verfahren zum Übertragen von Daten
GB2563251A (en) * 2017-06-07 2018-12-12 Sony Mobile Communications Inc Terminal device, data processing apparatuses and methods
CN109218186B (zh) 2017-07-05 2021-02-23 华为技术有限公司 一种多路径数据传输处理方法及网络设备
US11051239B2 (en) 2017-07-07 2021-06-29 Nokia Solutions And Networks Oy Multiple air interface aggregation supporting multivendor 4G/5G networks
CN117354961A (zh) * 2017-07-10 2024-01-05 摩托罗拉移动有限责任公司 移动网络中的多接入数据连接
CN108540519B (zh) * 2018-01-29 2021-05-25 北京奇艺世纪科技有限公司 一种均衡下载控制方法和装置
CN110120932B (zh) * 2018-02-06 2020-10-23 华为技术有限公司 多路径建立方法及装置
US11316871B2 (en) 2018-02-08 2022-04-26 Cisco Technology, Inc. Encrypted traffic analytics over a multi-path TCP connection
CN112005533B (zh) * 2018-02-22 2023-11-07 瑞典爱立信有限公司 代理多路径协议连接的方法和设备
US10979355B2 (en) 2018-04-02 2021-04-13 Apple Inc. Multipath transmission control protocol proxy use in a cellular network
US11191121B2 (en) * 2018-07-23 2021-11-30 Parallel Wireless, Inc. Multipath TCP with mesh access
CN109144032B (zh) * 2018-09-05 2021-02-05 中国铁路昆明局集团有限公司昆明车辆段 客车网络控制部件通信试验装置
CN110650089B (zh) * 2019-10-24 2020-06-30 北京大学 一种支持多路聚合通信的中间设备
US20230112305A1 (en) * 2021-10-08 2023-04-13 Comcast Cable Communications, Llc Diverse pathway integration

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080148399A1 (en) 2006-10-18 2008-06-19 Microsoft Corporation Protection against stack buffer overrun exploitation
US9455897B2 (en) * 2010-04-06 2016-09-27 Qualcomm Incorporated Cooperative bandwidth aggregation using multipath transport
CN101925125B (zh) 2010-04-23 2013-01-30 清华大学 一种与移动ip结合的具有移动性的多路径tcp的方法
US8566944B2 (en) 2010-04-27 2013-10-22 Microsoft Corporation Malware investigation by analyzing computer memory
WO2011153415A1 (en) 2010-06-04 2011-12-08 Interdigital Patent Holdings, Inc. Mptcp and mobil ip interworking
US8400923B2 (en) 2010-10-15 2013-03-19 Telefonaktiebolaget L M Ericsson (Publ) Multipath transmission control protocol proxy
EP2495927B1 (en) * 2011-03-02 2014-10-08 Alcatel Lucent Concept for providing information on a data packet association and for forwarding a data packet
US20130007286A1 (en) * 2011-06-29 2013-01-03 Juniper Networks, Inc. User session routing between mobile network gateways
US9531606B2 (en) * 2012-12-07 2016-12-27 Nokia Technologies Oy Packet measurements and reporting in wireless network

Also Published As

Publication number Publication date
EP2932675B1 (en) 2017-11-01
JP2016508308A (ja) 2016-03-17
CN104854837B (zh) 2017-10-20
EP2932675A1 (en) 2015-10-21
KR20150089057A (ko) 2015-08-04
US9998569B2 (en) 2018-06-12
WO2014090335A1 (en) 2014-06-19
CN104854837A (zh) 2015-08-19
KR101820583B1 (ko) 2018-01-19
US20150312383A1 (en) 2015-10-29

Similar Documents

Publication Publication Date Title
JP6301358B2 (ja) 通信ネットワークにおけるマルチパス伝送制御プロトコル信号伝達の処理
EP2272272B1 (en) Self-backhauling in lte
EP2286615B1 (en) Data forwarding during handover in a self-backhauled cell
EP2250827B1 (en) A method and an apparatus for providing route optimisation
US10098042B2 (en) MME, local server, MME-local server interface, and data transmission method for optimized data path in LTE network
WO2014077352A1 (ja) ネットワークシステムと方法と装置並びにプログラム
US9788353B2 (en) Mobile network communications method, communications apparatus, and communications system
JP2019521588A (ja) 通信制御方法および関連するネットワーク要素
US9693218B2 (en) Mobility management system, mobility management method, access GW apparatus, mobility management control apparatus, and computer-readable medium
US10299181B2 (en) Method and apparatus for configuring disconnected TCP connection in communication system, handover support method and apparatus therefor
WO2017000866A1 (zh) 一种节点间数据传输的方法、网关节点及节点
CN107431917B (zh) 分离会话锚点与转发锚点的方法和系统
US9942928B2 (en) Routing method between base stations, serving gateway, and base station
US9668176B2 (en) Method for selecting shunt gateway and controller
EP3454588B1 (en) Method and device for transmitting messages
JP2011509611A (ja) 通信ネットワークにおいて、ルートを最適化するためのテクニック

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160630

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160802

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161028

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170411

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180130

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180228

R150 Certificate of patent or registration of utility model

Ref document number: 6301358

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250