特許 5768138 通信デバイスとターゲットネットワーク内の宛先デバイスとの間のコネクションにおける中間ノードでパケットに対するアクションを実行する方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5768138

(24)【登録日】2015年6月26日

(45)【発行日】2015年8月26日

(54)【発明の名称】通信デバイスとターゲットネットワーク内の宛先デバイスとの間のコネクションにおける中間ノードでパケットに対するアクションを実行する方法および装置

(51)【国際特許分類】

   H04W 28/06 20090101AFI20150806BHJP

   H04W 80/04 20090101ALI20150806BHJP

【ＦＩ】

   H04W28/06 110

   H04W80/04

【請求項の数】19

【全頁数】12

(21)【出願番号】特願2013-540241(P2013-540241)

(86)(22)【出願日】2010年11月29日

(65)【公表番号】特表2014-501087(P2014-501087A)

(43)【公表日】2014年1月16日

(86)【国際出願番号】EP2010007220

(87)【国際公開番号】WO2012072091

(87)【国際公開日】20120607

【審査請求日】2013年5月27日

(73)【特許権者】

【識別番号】508342183

【氏名又は名称】エヌイーシー ヨーロッパ リミテッド

【氏名又は名称原語表記】ＮＥＣ ＥＵＲＯＰＥ ＬＴＤ．

(74)【代理人】

【識別番号】100097157

【弁理士】

【氏名又は名称】桂木 雄二

(72)【発明者】

【氏名】コルベ、ハンス−ヨルク

(72)【発明者】

【氏名】クンツ、アンドレアス

【審査官】 伊東 和重

(56)【参考文献】

【文献】 特開２００９−２０６７６９（ＪＰ，Ａ）

【文献】 特表２０１１−５２５３１９（ＪＰ，Ａ）

【文献】 国際公開第２００９／１４９１１１（ＷＯ，Ａ２）

【文献】 特開２００８−３１１９７４（ＪＰ，Ａ）

【文献】 Qualcomm Europe，Enhanced security support for S2c，3GPP TSG SA WG2 Meeting #71，3GPP，２００９年 ２月２０日，TD S2-090902

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４−７／２６

Ｈ０４Ｗ ４／００−９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−２

ＣＴ ＷＧ１

(57)【特許請求の範囲】

【請求項1】

中間ネットワークノード経由での通信デバイスとターゲットネットワーク内の宛先デバイスとの間のコネクションをサポートする方法において、
前記通信デバイスと前記宛先デバイスとの間でデータがトンネル経由で送信され、
該トンネルは、前記通信デバイスまたは該通信デバイスが接続された基地局を第１のトンネルエンドポイントとし、前記ターゲットネットワーク内のゲートウェイを第２のトンネルエンドポイントとして、該トンネルエンドポイント間で確立され、
該方法は、
１つ以上のダミーパケットが前記第１のトンネルエンドポイントから前記第２のトンネルエンドポイントへ前記トンネル経由で送信され、
該１つ以上のダミーパケットのパケットヘッダに情報が符号化され、
前記中間ネットワークノードのうちの少なくとも１つは、前記１つ以上のダミーパケットを受信した後、前記符号化された情報を検出および／または復号するステップと、前記符号化された情報に応じた所定のアクションを実行するステップとを実行する
ことを特徴とする、中間ネットワークノード経由での通信デバイスとターゲットネットワーク内の宛先デバイスとの間のコネクションをサポートする方法。

【請求項2】

インターネットプロトコル（ＩＰ）ベースの通信において前記コネクションがサポートされることを特徴とする請求項１に記載の方法。

【請求項3】

前記情報を伝達するために、前記ダミーパケットの１つのパケットヘッダフィールドまたはパケットヘッダフィールドの組合せが使用されることを特徴とする請求項１または２に記載の方法。

【請求項4】

前記情報が、前記パケットヘッダの長さフィールドに符号化されることを特徴とする請求項１ないし３のいずれか１項に記載の方法。

【請求項5】

前記情報が、前記パケットヘッダのＴＴＬ（有効期間）フィールドまたは最大ホップ数フィールドに符号化されることを特徴とする請求項１ないし４のいずれか１項に記載の方法。

【請求項6】

前記パケットヘッダに符号化される前記情報が、所定のアクションを起動するネットワークポリシーおよび／またはコマンドを含むことを特徴とする請求項１ないし５のいずれか１項に記載の方法。

【請求項7】

前記パケットヘッダに符号化される前記情報が、前記中間ネットワークノードによって検出および／または復号されるために、所定のマッチング基準を含むことを特徴とする請求項１ないし６のいずれか１項に記載の方法。

【請求項8】

前記マッチング基準がダミーパケットの所定のシーケンスを含むことを特徴とする請求項７に記載の方法。

【請求項9】

前記マッチング基準がワンタイムマッチング基準として使用されることを特徴とする請求項７または８に記載の方法。

【請求項10】

前記マッチング基準が前記中間ネットワークノードに事前に配布されることを特徴とする請求項７ないし９のいずれか１項に記載の方法。

【請求項11】

前記情報が符号化される前記パケットヘッダが、ＩＰ（Internet Protocol）トンネリング上のプロトコルの外側のＩＰ（Internet Protocol）ヘッダであることを特徴とする請求項１ないし１０のいずれか１項に記載の方法。

【請求項12】

前記ＩＰトンネリング上のプロトコルが、ＩＰＳｅｃ（Internet Protocol Security）、ＧＲＥ（Generic Routing Encapsulation）、Ｌ２ＴＰ（Layer 2 TunnellingProtocol）またはＧＴＰ（GPRS TunnellingProtocol）であることを特徴とする請求項１１に記載の方法。

【請求項13】

前記ダミーパケットが、前記第２のトンネルエンドポイント経由で前記宛先デバイスへ送信され、前記宛先デバイスによって抽出される前記ダミーパケットにペイロードが含まれることを特徴とする請求項１ないし１２のいずれか１項に記載の方法。

【請求項14】

前記ダミーパケットが、前記第２のトンネルエンドポイント経由で前記宛先デバイスへ送信され、前記宛先デバイスが、前記ダミーパケットを受信した後、前記ダミーパケットに基づくアクションを実行することを特徴とする請求項１ないし１３のいずれか１項に記載の方法。

【請求項15】

双方向通信が提供され、前記宛先デバイスが、ダミーパケットを受信した後、前記第１のトンネルエンドポイントへ応答パケットを送信することを特徴とする請求項１ないし１４のいずれか１項に記載の方法。

【請求項16】

請求項１ないし１５のいずれか１項に記載の方法における、
前記通信デバイスと前記宛先デバイスとの間でデータがトンネル経由で送信されること、
該トンネルは、前記通信デバイスを第１のトンネルエンドポイントとし、前記ターゲットネットワーク内のゲートウェイを第２のトンネルエンドポイントとして、該トンネルエンドポイント間で確立されること、
１つ以上のダミーパケットが前記第１のトンネルエンドポイントから前記第２のトンネルエンドポイントへ前記トンネル経由で送信されること、および
該１つ以上のダミーパケットのパケットヘッダに情報が符号化されること、
を実行するように構成され、
前記パケットヘッダに符号化される前記情報が、前記中間ネットワークノードによって検出および／または復号されるため、ならびに、前記中間ネットワークノードにおいて所定のアクションを起動するための情報を含む
ことを特徴とする通信デバイス。

【請求項17】

第１のトンネルエンドポイントと第２のトンネルエンドポイントとの間の中間ネットワークノードとして機能するネットワークノードにおいて、請求項１ないし１５のいずれか１項に記載の方法における、
前記第１のトンネルエンドポイントから前記第２のトンネルエンドポイントへ向けて送信された前記１つ以上のダミーパケットを受信した後、該ネットワークノードによって読み取り可能な前記ダミーパケットのパケットヘッダに符号化された情報を検出および／または復号するステップと、前記符号化された情報に応じた所定のアクションを実行するステップ
を実行するように構成されたことを特徴とするネットワークノード。

【請求項18】

中間ネットワークノード経由での、接続された通信デバイスとターゲットネットワーク内の宛先デバイスとの間のコネクションをサポートする基地局において、
該基地局は、該基地局を第１のトンネルエンドポイントとし、前記ターゲットネットワーク内のゲートウェイを第２のトンネルエンドポイントとして、該ゲートウェイとの間でトンネルを確立するように構成され、該トンネルは、前記通信デバイスと前記宛先デバイスとの間でデータを送信し、
該基地局は、前記トンネル経由で前記ゲートウェイへ１つ以上のダミーパケットを送信するようにさらに構成され、
該１つ以上のダミーパケットのパケットヘッダに情報が符号化され、
該情報は、前記１つ以上のダミーパケットを受信した前記トンネルエンドポイント間の少なくとも１つの中間ネットワークノードによって実行される所定のアクションを起動する
ことを特徴とする基地局。

【請求項19】

フェムトセルであることを特徴とする請求項１８に記載の基地局。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、特にインターネットプロトコル（ＩＰ）ベースの通信において、中間ネットワークノード経由での通信デバイスとターゲットネットワーク内の宛先デバイスとの間のコネクションをサポートする方法に関する。前記通信デバイスと前記宛先デバイスとの間でデータがトンネル経由で送信される。該トンネルは、前記通信デバイスまたは該通信デバイスが接続された基地局を第１のトンネルエンドポイントとし、前記ターゲットネットワーク内のゲートウェイを第２のトンネルエンドポイントとして、該トンネルエンドポイント間で確立される。

【0002】

また、本発明は、中間ネットワークノード経由での、接続された通信デバイスとターゲットネットワーク内の宛先デバイスとの間のコネクションをサポートする基地局、特にフェムトセルに関する。該基地局は、該基地局を第１のトンネルエンドポイントとし、前記ターゲットネットワーク内のゲートウェイを第２のトンネルエンドポイントとして、該ゲートウェイとの間でトンネルを確立するように構成され、該トンネルは、前記通信デバイスと前記宛先デバイスとの間でデータを送信する。

【背景技術】

【0003】

近年、インターネットプロトコル（ＩＰ）ベースの通信において、頭書のような方法およびデバイスが実用的に知られている。すなわち、３ＧＰＰ（3rd Generation Partnership Project）におけるフェムトセルと、非３ＧＰＰアクセス経由の携帯電話は両方とも、信頼できないネットワーク経由で３ＧＰＰコアネットワークに接続しなければならないときには、ほとんどの配備事例においてＩＰＳｅｃ（Internet Protocol Security）トンネルを使用する。これにより、中間ネットワークから見るとエンドツーエンド暗号化が行われることになる。

【0004】

ＩＰＳｅｃを用いる場合、送信パケットは暗号化可能であり、それにより、データパス内の中間ネットワークノードにとって読み取り不可能となる。このため、中間ネットワークノード経由での通信デバイスとターゲットネットワーク内の宛先デバイスとの間のコネクション、特にデータフローが、例えばネットワーク性能、サービス品質（ＱｏＳ）、あるいは課金等の目的で拡張される場合に、中間ネットワークノードを制御あるいは調整することが課題となる。これに関して、従来の解決手段は、ＱｏＳシグナリングや課金のために、不十分で複雑な専用のシグナリング手続きあるいはコネクションを必要とする。

【発明の概要】

【発明が解決しようとする課題】

【0005】

したがって、本発明の目的は、中間ノード経由での通信デバイスとターゲットネットワーク内の宛先デバイスとの間のコネクションをサポートする頭書のような方法において、実施の容易なメカニズムを使用することにより、中間ネットワークノードが効率的に調整可能であるような改良およびさらなる展開を行うことである。また、対応する通信デバイス、ネットワークノードおよび基地局が開示される。

【課題を解決するための手段】

【0006】

本発明によれば、上記の目的は、請求項１の構成を備えた方法によって達成される。この請求項に記載の通り、該方法は、以下のことを特徴とする。すなわち、１つ以上のダミーパケットが前記第１のトンネルエンドポイントから前記第２のトンネルエンドポイントへ前記トンネル経由で送信され、該１つ以上のダミーパケットのパケットヘッダに情報が符号化される。前記中間ネットワークノードのうちの少なくとも１つは、前記１つ以上のダミーパケットを受信した後、前記符号化された情報を検出および／または復号するステップと、前記符号化された情報に応じた所定のアクションを実行するステップとを実行する。

【0007】

また、上記の目的は、請求項１４の構成を備えた通信デバイスによって達成される。この請求項に記載の通り、該通信デバイスは、本発明による方法を実行するように構成される。

【0008】

また、上記の目的は、請求項１５の構成を備えたネットワークノードによって達成される。この請求項に記載の通り、該ネットワークノードは、中間ネットワークノードとして機能し、本発明による方法を実行するように構成される。

【0009】

最後に、上記の目的は、請求項１６の構成を備えた基地局によって達成される。この請求項に記載の通り、該基地局は、前記トンネル経由で前記ゲートウェイへ１つ以上のダミーパケットを送信するようにさらに構成され、該１つ以上のダミーパケットのパケットヘッダに情報が符号化される。該情報は、前記１つ以上のダミーパケットを受信した前記トンネルエンドポイント間の少なくとも１つの中間ネットワークノードによって実行される所定のアクションを起動する。

【0010】

本発明によって初めて認識されたこととして、トンネル経由で送信されるパケットのペイロードは一般的に暗号化されるが、このようなパケットのヘッダフィールドは中間ネットワークノードによって読み取り可能であり、このことを有利に利用して、中間ネットワークノードを調整することができる。すなわち、認識されたこととして、このようなヘッダフィールドは、中間ネットワークノードへ所定の情報を伝達するために使用可能である。これを達成するため、１つ以上のダミーパケット、すなわち専用パケットが、第１のトンネルエンドポイントから第２のトンネルエンドポイントへトンネル経由で送信され、該１つ以上のダミーパケットのパケットヘッダに情報が符号化される。中間ネットワークノードのうちの少なくとも１つは、ダミーパケットを受信した後、符号化された情報の検出および／または復号を実行する。１つ以上のダミーパケットの符号化された情報に応じて、前記少なくとも１つの中間ネットワークノードが所定のアクションを実行する。こうして、本発明による方法ならびに対応する通信デバイス、ネットワークノードおよび基地局は、中間ネットワークノードを効率的に調整することができる。その結果、中間ネットワークノードは、符号化された情報を読むことができ、別個の制御チャネルを必要とせずにアクションを実行することが可能となる。

【0011】

好ましい実施形態によれば、情報を伝達するために１つのパケットヘッダフィールドまたは複数のダミーパケットのパケットヘッダフィールドの組合せが使用されてもよい。上記ですでに述べたように、トンネルを使用する場合、送信されるパケットのペイロードは一般的に暗号化されるため、データパス内の中間ネットワークノードにとって読み取り不可能である。しかし、読み取り可能なフィールドとして、例えばＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）あるいはＩＰ（Internet Protocol）の以下のようなヘッダフィールド、すなわち、バージョン（Version）、ＩＨＬ（IP Header Length, ＩＰヘッダ長）、ＤｉｆｆＳｅｒｖ（Differentiated Services）、全長（Total length）、識別（Identification）、フラグ（Flags）、フラグメントオフセット（Fragment offset）、ＴＴＬ（Time to Live, 有効期間）、プロトコル（Protocol）、ヘッダチェックサム（Header checksum）、ソースＩＰアドレス（Source IP address）または宛先アドレス（Destination address）のようなヘッダフィールドがある。このため、適当なダミーパケットを作成することにより、中間ネットワークノードに対する情報をヘッダフィールドに符号化することが可能である。なお、これにより、宛先ＩＰアドレスフィールドのような、パケットの正しい機能にとって必須でない内容または値をもつフィールドのみが使用可能である。この場合、正しい機能とは、パケットがその宛先ノードに到達することを意味する。

【0012】

有利な態様として、情報は、ダミーパケットのパケットヘッダの長さフィールドに符号化されてもよい。パケットの長さフィールドの値は、当該パケットの宛先ノードへの到達に必須ではないので、このフィールドは、パケットに情報を挿入するために円滑に使用可能である。ただし、長さフィールドで使用される値に対応したサイズのパケットを生成することによって、パケットヘッダの妥当性が保持されるべきである。使用されるＩＰバージョンに応じて、ＩＰｖ４においては全長フィールドが使用可能であり、ＩＰｖ６においてはペイロード長フィールドが使用可能である。

【0013】

好ましい実施形態によれば、情報は、パケットヘッダのＴＴＬ（有効期間）フィールドまたは最大ホップ数（Hop Limit）フィールドに符号化されてもよい。この場合、ＩＰｖ４においてはＴＴＬフィールドが使用され、ＩＰｖ６においては最大ホップ数フィールドが使用される。有利な態様として、ＴＴＬフィールドまたは最大ホップ数フィールドが長さフィールドとともに使用されてもよい。例えば、他のＴＴＬ値を有する中間パケットが送信されるときに中間ネットワークノードがパケットを関連づけることができるようにするために、ＴＴＬフィールドまたは最大ホップ数フィールドが使用されてもよい。

【0014】

好ましい実施形態によれば、パケットヘッダに符号化される情報は、所定のアクションを起動するネットワークポリシーおよび／またはコマンドを含む。これにより、１つ以上の中間ネットワークノードを調整または制御するために、インラインで定義されるコマンドがそれらの中間ネットワークノードへ伝達されてもよい。例えば、コマンドは、セッションの変更または破棄のために定義されてもよい。また、中間ネットワークノードがポリシーを実行および／または導入するために必要となる任意の他のコマンドが可能である。例えば、中間ネットワークノードは、課金手続きを実施してもよい。有利な態様として、複数のコマンドを１つのダミーパケットに、および／またはダミーパケット列に符号化することが可能である。この場合、コマンドどうしが互いに関連している必要はない。例えば、ＱｏＳポリシーコマンドおよびアカウンティングコマンドが１つのパケット列に符号化される。

【0015】

好ましい実施形態によれば、パケットヘッダに符号化される情報は、中間ネットワークノードによって検出および／または復号されるために、所定のマッチング基準を含んでもよい。マッチング基準は、中間ネットワークノードにおいてダミーパケットの検出を起動することができる。例えば、ダミーパケットに対する非常に稀なパケット長の使用は、便利なマッチング基準となり得る。これにより、マッチング基準を含むダミーパケットは、所定のアクションを起動するため、または、コマンドが後続することを中間ネットワークノードに通知するために使用可能である。

【0016】

誤りやすさを低減することに関して、マッチング基準がダミーパケットの所定のシーケンスを含むようにしてもよい。このため、所定のパターンマッチングを可能にするためにいくつかのダミーパケット使用してもよい。すなわち、中間ネットワークノードにおいて検出を起動するために、少なくとも２つのダミーパケットを含むトレーニングシーケンスを定義してもよい。こうして、トレーニングシーケンスを用いることで、通常のパケットが中間ネットワークノードによる不要なコマンドの実行を起動する可能性を低減してもよい。このトレーニングシーケンスあるいはパターンは、適切に定義され、ダミーパケットに符号化された情報を処理しなければならない中間ネットワークノードまたはすべての中間ネットワークノードに事前に既知とされる必要がある。したがって、あらかじめ合意したシーケンスが、対応する中間ネットワークノードに事前に配布されるべきである。

【0017】

セキュリティに関して、マッチング基準は、パケットスヌーピングによるネットワークノード機能へのアクセスを防止するために、各パケットまたはセッションに適用されるワンタイムマッチング基準として定義されるようにしてもよい。例えば、複数のトレーニングシーケンスからなるリストが中間ネットワークノードに配布されてもよい。

【0018】

有利な態様として、マッチング基準は、対応するダミーパケットに符号化された情報を処理する予定の中間ネットワークノードに事前に配布されてもよい。

【0019】

好ましい実施形態によれば、情報が符号化されるパケットヘッダは、ＩＰ（Internet Protocol）トンネリング上のプロトコル、特にＩＰＳｅｃ（Internet Protocol Security）、ＧＲＥ（Generic Routing Encapsulation）、Ｌ２ＴＰ（Layer 2 Tunnelling Protocol）またはＧＴＰ（GPRS Tunnelling Protocol）の外側のＩＰ（Internet Protocol）ヘッダであってもよい。

【0020】

好ましい実施形態によれば、ダミーパケットは、第２のトンネルエンドポイント経由で宛先デバイスへ送信され、宛先デバイスによって抽出されるダミーパケットにペイロードが含まれてもよい。

【0021】

好ましい実施形態によれば、ダミーパケットは、第２のトンネルエンドポイント経由で宛先デバイスへ送信され、宛先デバイス、例えばターゲットホストが、ダミーパケットを受信した後、ダミーパケットに基づくアクションを実行してもよい。宛先デバイスは、受信したダミーパケット（特に、意味のあるペイロードの有無は問わない）に基づいて、アカウンティング、ポリシー制御サブシステムへの通知等のアクションを実行してもよい。宛先デバイスに対する追加情報がパケットのペイロードに符号化されることも可能である。

【0022】

好ましい実施形態によれば、双方向通信が提供され、宛先デバイスは、ダミーパケットを受信した後、第１のトンネルエンドポイントへ応答パケットを送信してもよい。例えば、応答パケットは、ダミーパケットのシーケンスの受信の確認を含んでもよい。

【0023】

なお、本発明による方法は、通信デバイスまたは基地局とターゲットネットワーク内のゲートウェイとの間の通信に必要な通常のパケットのヘッダを変更する必要がない。代わりに、通信デバイスまたは基地局は、特定のルールに従ってダミーパケットを作成し、そのダミーパケットをトンネル経由でターゲットネットワーク内の特定の宛先デバイス、例えば特定のホストへ送信する。この場合、ヘッダフィールドは、マッチング基準に適合するように必要に応じて書き込まれることが可能である。さらに、第２のエンドポイントまたはターゲットネットワーク内の宛先デバイスがダミーパケットを作成し逆方向に送信することも可能である。

【0024】

本発明を好ましい態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。

【図面の簡単な説明】

【0025】

【図1】３ＧＰＰアクセスにおける本発明による方法の適用場面の模式図である。

【図2】３ＧＰＰアクセスにおける本発明による方法の別の適用場面の模式図である。

【図3】非３ＧＰＰアクセスにおける本発明による方法の別の適用場面の模式図である。

【図4】ダミーパケットのレイアウトを例示する模式図である。

【図5】ダミーパケットのパスを示した特定実施形態における本発明による方法を例示する模式図である。

【図6】本発明による方法の適用場面において使用されるパケットヘッダの全長フィールドを示す模式図である。

【発明を実施するための形態】

【0026】

図１は、３ＧＰＰアクセスにおける本発明による方法の適用場面を示している。３ＧＰＰにおいて、フェムトセル（ホームノードＢともいう）は、信頼できないネットワーク経由で３ＧＰＰコアネットワークに接続しなければならないときには、ほとんどの配備事例において図１に示すようなＩＰＳｅｃトンネルを使用する。これにより、中間ネットワークから見るとエンドツーエンド暗号化が行われることになる。図１は、フェムトセルがＩＰＳｅｃトンネルでターゲットネットワーク内のゲートウェイに接続される場合を示している。通信デバイスＵＥ（ユーザ機器ともいう）はフェムトセルに接続される。図１に例示したホームゲートウェイは、フェムトセルから分離され、したがって、アグリゲーションおよびエッジネットワークノードとともに、信頼できない中間ネットワークの一部である。中間ネットワークの中間ネットワークノードは、特に定義されたダミーパケットをＩＰＳｅｃトンネルの一端または両端がトンネルを通じて送信するようにすることによって、暗号化されたＩＰＳｅｃトンネル経由で送信されたコマンドを識別することができる。この場合、ダミーパケットのパケットヘッダが、コマンドおよびマッチング基準を含む。これは、中間ネットワークノードがダミーパケットをスヌープして所定のマッチング基準と照合することを意味する。中間ネットワークノードがマッチングパケットを検出した場合、アクションが中間ネットワークノード内で起動される。

【0027】

図２は、３ＧＰＰアクセスにおける（図１と類似の）本発明による方法の別の適用場面を示している。図２において、フェムトセルはホームゲートウェイと共同配置されている。

【0028】

図３は、非３ＧＰＰアクセスにおける本発明による方法の別の適用場面を示している。図３に例示した非３ＧＰＰアクセスの場合、通信デバイスＵＥがＩＰＳｅｃトンネルでターゲットネットワークに接続される。図３の適用場面における中間ネットワークは、ホームゲートウェイならびにアグリゲーションおよびエッジネットワークノードからなる。アグリゲーションおよびエッジノードは、例えば固定回線アクセスネットワークであることが可能である。

【0029】

図４は、ダミーパケットのレイアウトを示している。ダミーパケットは、ＩＰヘッダ、ＩＰＳｅｃヘッダおよびＩＰパケットの暗号化されたペイロードを含む。ＩＰヘッダは、符号化された情報、すなわち、中間ネットワークノードに対するマッチング基準／パターンおよび／またはコマンドを含む。ダミーパケットのペイロードは、ターゲットネットワーク内の宛先デバイスに対するコマンドを含むことが可能である。

【0030】

図５は、ダミーパケットのパスを示した特定実施形態における本発明による方法を例示する模式図である。また、図５は、ＩＰＳｅｃトンネルのエンドポイントアドレスおよびダミーパケットのエンドポイントアドレスを例示している。図５に例示した実施形態によれば、フェムトセルが、例えば通信デバイスＵＥがサービス要求メッセージを送信したときに、ＩＰＳｅｃトンネル上で音声チャネルを確立する必要性を検出する。メディアが流れることを可能にする前に、フェムトセルは、ダミーＩＰパケットのセットをトレーニングシーケンスとしてＩＰＳｅｃトンネル上に送信し、コマンドが後続することを中間ノードに通知する。フェムトセルおよび中間ノードには、アクションを起動するシーケンスがあらかじめ設定されている。このようなシーケンスの一例として、次の特性を有する３個のダミーＩＰパケットが挙げられる。

【0031】

【表1】

【0032】

なお、ＩＰエンドポイントとは、ＩＰＳｅｃトンネルの両端である。ＩＰＳｅｃトンネル内で、カプセル化されたＩＰパケットは、ゲートウェイの先のターゲットネットワーク内の宛先ノードへ送られる。ＩＰヘッダの全長フィールドは、ダミーパケット全体の実際の長さを含む。不正確に書き込まれているヘッダはない。さらに、他のＴＴＬ値を有する中間パケットが送信されるときに中間ネットワークノードがパケットを関連づけることができるようにするために、ＴＴＬフィールドも使用される。

【0033】

ホームゲートウェイは、侵入検知システム（Intrusion Detection System, ＩＤＳ）と同様のエンジンを用いて、長さ４１のパケット（これはきわめて稀であるため、この例ではトレーニングシーケンスのパケット＃１として選択されている）に対して起動して、後続のパケット（符号化されたメッセージを含む）をチェックするように構成される。トレーニングシーケンスは、通常のパケットが、中間ノードで不要なコマンドを起動する可能性を低減するために使用される。

【0034】

次に、コマンドを含む第４のパケットが中間ネットワークノードに到着する。

【0035】

【表2】

【0036】

中間ノードは、このパケットの長さフィールドを次のごとく読むように構成される。すなわち、１６ビットからなる長さフィールドが２バイトに分割され、下位バイトを値として、上位バイトをコマンドとして読む。長さフィールドのビット１０がセットされ、上位ビット１１〜１６がセットされていない場合、下位ビット０〜９はｋｂｐｓ単位での帯域予約の値として使用される。この機能およびポリシーを備えた中間ノードは、その後に起こると期待されるマルチメディアセッションに対する帯域予約および適当なスケジューリングルールを割り当てることになる。

【0037】

図６は、帯域予約が２００ｋｂｐｓの例示的なコマンドを有するパケットヘッダの全長フィールドを示している。

【0038】

セッション解放時に、フェムトセルは、前に許可された帯域を解放できるようになったことを示すフォローアップパケットを有する同様のトレーニングシーケンスを送信する。これは、逆の形で示すことができる。すなわち、ビット１０および上位ビット１１〜１６がセットされていない場合、下位ビット０〜９はｋｂｐｓ単位での帯域縮小の値として使用される。

【0039】

中間ノードが、ダミーパケットで要求された要求帯域を予約することができない場合、その要求を含むダミーパケットは廃棄される。ターゲットホストは、欠けているコマンドパケットを認識し、タイムアウト後に、ターゲットホストは、否定応答として解釈可能なパケットを通信デバイスＵＥまたはフェムトセルへ送信する。通信デバイスＵＥまたはフェムトセルは、パケットが他の理由で失われた可能性もあるので、リソース予約をリトライしてもよい。

【0040】

別の可能性として、中間ネットワークノードが、要求された帯域を提供することができないことを示す新たなパケットを生成してターゲットホストへ送信してもよい。ターゲットホストは、否定応答として解釈可能なパケットを通信デバイスＵＥまたはフェムトセルへ返送することになる。

【0041】

上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】