JP2013502121A

JP2013502121A - （ｅ）ＮｏｄｅＢに対するローカルＩＰ接続性をサポートするシステムおよび方法

Info

Publication number: JP2013502121A
Application number: JP2012524154A
Authority: JP
Inventors: プンツ、ゴットフリート; シュミット、ステファン
Original assignee: NEC Europe Ltd
Current assignee: NEC Europe Ltd
Priority date: 2009-08-13
Filing date: 2010-08-13
Publication date: 2013-01-17
Also published as: EP2465274A1; CN102474713A; US20120188895A1; WO2011018235A1

Abstract

（ｅ）ＮｏｄｅＢに対するローカルＩＰ接続性をサポートするシステムを提供する。該システムは、ＰＤＮゲートウェイまたはＧＧＳＮを備えたモバイル事業者ネットワークと、前記（ｅ）ＮｏｄｅＢに関連づけられた少なくとも１つのユーザ機器（ＵＥ）とを有する。該システムは、ローカルゲートウェイ機能（Ｌ−ＧＷ）が前記（ｅ）ＮｏｄｅＢに対して設けられ、前記ローカルゲートウェイ機能（Ｌ−ＧＷ）と前記モバイル事業者ネットワークの前記ＰＤＮゲートウェイまたは前記ＧＧＳＮとの間に拡張トンネルが確立されることを特徴とする。また、対応するシステムが開示される。

Description

本発明は、（ｅ）ＮｏｄｅＢに対するローカルＩＰ接続性をサポートするシステムに関する。該システムは、ＰＤＮゲートウェイまたはＧＧＳＮを備えたモバイル事業者ネットワークと、前記（ｅ）ＮｏｄｅＢに関連づけられた少なくとも１つのユーザ機器（ＵＥ）とを有する。

また、本発明は、（ｅ）ＮｏｄｅＢに対するローカルＩＰ接続性をサポートする方法であって、特に、請求項１ないし２０のいずれか１項に記載のシステムで実行される方法に関する。ＰＤＮゲートウェイまたはＧＧＳＮを備えたモバイル事業者ネットワークが提供され、少なくとも１つのユーザ機器（ＵＥ）が前記（ｅ）ＮｏｄｅＢに関連づけられる。

３ＧＰＰにおいて、ローカルＩＰ接続性を効率的にサポートするために、アーキテクチャの高度化の探求が集中的に進められている。現在、このようなローカルＩＰ接続性は、トラフィックがＵＥ（User Equipment, ユーザ機器）のホームネットワーク向けである場合にはＬＩＰＡ（Local IP Access, ローカルＩＰアクセス）と略称され、あるいはトラフィックがインターネット向けである場合にはＳＩＰＴＯ（Selected IP Traffic Offload）と略称されている。３ＧＰＰの取り組みは、ホームセルおよびマクロセルの両方の場合に向けられ、ＥＰＳ（非特許文献１参照）および３ＧＧＰＲＳ（非特許文献２参照）を対象としている。３ＧＰＰＳＡ２は、S2-094867, "New WID for Local IP Access & Internet Offload" に従って、すでに標準化作業を開始している。本発明は、以下でさらに詳細に説明するように、これらの仕様および文書ならびに関連仕様に規定された仮定および原理に基づいている。

最新のモバイルネットワーク技術において、ＵＥから外部（ターゲット）ＰＤＮ（Packet Data Network, パケットデータネットワーク）向けのＩＰ接続性は、モバイルネットワーク事業者のコアネットワークにおけるＰＤＮゲートウェイによって提供される。モビリティトンネルが、（ｅ）ＮｏｄｅＢおよびサービングゲートウェイ（Serving-Gateway）を通じてトラフィックを伝送する。同様に、ＧＰＲＳの場合、ＩＰ接続性は、ＬＴＥの場合におけるＰＤＮゲートウェイに対応するＧＧＳＮ（Gateway GPRS Support Node, ゲートウェイＧＰＲＳサポートノード）によって提供される。また、ＵＴＲＡＮ無線アクセス（３Ｇ）では、モビリティトンネルが、ＮｏｄｅＢ、ＲＮＣ（Radio Network Controller, 無線ネットワークコントローラ）およびＳＧＳＮ（Serving GPRS Support Node, サービングＧＰＲＳサポートノード）を通じてトラフィックを伝送する。

一般的な問題は、単純（plain, "dumb"）なインターネットトラフィック、すなわちローカルサーバへの（例えばホームネットワークあるいは企業ネットワーク内の）トラフィックが、今後かなり増大すると予想されることである。この種のトラフィックは、３ＧＰＰ事業者の付加価値リソースを必要とすることはないので、できる限り事業者のネットワークから負荷軽減すべきである。ＩＰトラフィック分離（breakout）の可能性のある位置の１つは（ｅ）ＮｏｄｅＢにある。

最新技術には、ＡＰＮ（Access Point Name, アクセスポイント名）の概念がある。これにより、トラフィックを分離することが可能となる。ＡＰＮは、ＦＱＤＮ（Fully Qualified Domain Name, 完全修飾ドメイン名）の形をとり、最終的にはＩＰアドレスへと解決される。標準化に関する現在の議論では、ＬＩＰＡ／ＳＩＰＴＯトラフィックに対して、別個のＡＰＮが使用されるとほとんど仮定されている。また、１つの共通のＡＰＮをＬＩＰＡ／ＳＩＰＴＯ型および非ＬＩＰＡ／ＳＩＰＴＯ型のトラフィックに対して使用するという要求もなされている。これに対する具体的な解決法は与えられていない。両方の型のトラフィックに対する共通のＡＰＮは、インターネットへのローカルＩＰトラフィック（ＳＩＰＴＯ）のほとんどに当てはまると仮定されている。

3GPP TS 23.401 V8.6.0 (2009-06), "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access" 3GPP TS 23.060 V8.5.1 (2009-06), "General Packet Radio Service (GPRS); Service description"

したがって、本発明の目的は、頭書のような（ｅ）ＮｏｄｅＢに対するローカルＩＰ接続性をサポートするシステムおよび方法において、実施の容易なメカニズムを使用することにより、既存のＥＰＳ（Evolved Packet System）あるいは３Ｇ−ＧＰＲＳ標準に対する影響を最小限に抑えつつローカルＩＰアクセス（分離）を効率化するような改良およびさらなる展開を行うことである。

本発明によれば、上記の目的は、請求項１の構成を備えたシステムによって達成される。この請求項に記載の通り、本システムは、以下のことを特徴とする。すなわち、ローカルゲートウェイ機能（Ｌ−ＧＷ）が前記（ｅ）ＮｏｄｅＢに対して設けられ、前記ローカルゲートウェイ機能（Ｌ−ＧＷ）と前記モバイル事業者ネットワークの前記ＰＤＮゲートウェイまたは前記ＧＧＳＮとの間に拡張トンネルが確立される。

また、上記の目的は、独立請求項２１の構成を備えた方法によって達成される。この請求項に記載の通り、本方法は、以下のことを特徴とする。すなわち、ローカルゲートウェイ機能（Ｌ−ＧＷ）が前記（ｅ）ＮｏｄｅＢに対して設けられ、前記ローカルゲートウェイ機能（Ｌ−ＧＷ）と前記モバイル事業者ネットワークの前記ＰＤＮゲートウェイまたは前記ＧＧＳＮとの間に拡張トンネルが確立される。

本発明によって初めて認識されたこととして、ＩＰトラフィック分離のための最良の位置は（ｅ）ＮｏｄｅＢにある。また、認識されたこととして、（ｅ）ＮｏｄｅＢに対するローカルＩＰ接続性は、（ｅ）ＮｏｄｅＢに対して設けられるローカルゲートウェイ機能（local gateway function, Ｌ−ＧＷ）という新しい機能エンティティを、モバイル事業者ネットワークのＰＤＮゲートウェイまたはＧＧＳＮのそれぞれとの間のトンネリングメカニズムと組み合わせることによって効果的にサポートすることができる。

本発明によるローカルゲートウェイ機能と拡張トンネルを組み合わせることにより、ローカルＩＰ接続性をサポートするために実行されるすべてのステップがユーザ機器に対して完全に透過的となり、ユーザ機器は拡張トンネルの確立を全く認識しない。これは、例えばＶＰＮ（Virtual Private Network, 仮想私設ネットワーク）のように、ＵＥが積極的に関与するオーバーレイ手法とは非常に対照的である。

提案する解決法は、３ＧＰＰ標準化アーキテクチャ（ＥＰＳまたはＧＰＲＳ）の最小限のアーキテクチャ上の拡張しか必要としない。すなわち、本発明によるアーキテクチャは、現行（３ＧＰＰＲｅｌ．８）アーキテクチャをできる限り再利用し、それをスムーズに拡張する。

好ましい実施形態によれば、拡張トンネルは、ＰＤＮゲートウェイまたはＧＧＳＮのそれぞれにおいてエンドポイントとして終端してもよい。このようなアーキテクチャは、追加的エンティティを設けることを必要とせず、ＰＤＮゲートウェイまたはＧＧＳＮに対する最小限の変更しか必要としない。

別法として、拡張トンネルは、ＰＤＮゲートウェイまたはＧＧＳＮの外部の機能エンティティで終端するようにしてもよい。この機能エンティティは、ＰＤＮゲートウェイまたはＧＧＳＮのそれぞれとインタフェースする。この実施形態は、特別な場合に適用可能であり、ＰＤＮゲートウェイまたはＧＧＳＮのそれぞれに対する変更がさらに最小化されるという利点を有する。その結果、提案する解決法を既存の標準化システムに統合することに関して、この実施形態は特に有利である。

制御要求の低い一実施態様によれば、拡張トンネルは、（ｅ）ＮｏｄｅＢを通じてユーザ機器とＰＤＮゲートウェイ（またはＧＧＳＮ）との間でコネクションが確立されるたびに確立されるようにしてもよい。他方、不要なトンネル確立を避けるため、ＰＤＮゲートウェイ（またはＧＧＳＮ）が判定機能を備えるようにしてもよい。判定機能は、ローカルトラフィックに対する所定の条件を分析し、ローカルトラフィックに対する所定の条件に適合するＡＰＮを有するパケットデータネットワークへのコネクションをユーザ機器が確立した場合にのみ、拡張トンネル確立を実行する。

リソース使用を節約するため、Ｌ−ＧＷとＰＤＮゲートウェイ／ＧＧＳＮとの間の拡張トンネルが、複数のＵＥに対して１つだけ確立されるようにしてもよい。

有利な態様としては、Ｌ−ＧＷは（ｅ）ＮｏｄｅＢと共同配置されるが、本発明は、Ｌ−ＧＷが（ｅ）ＮｏｄｅＢとは別個のエンティティ上に配置される場合にも等しく適用可能である。（ｅ）ＮｏｄｅＢは、ホーム（ｅ）ＮｏｄｅＢであっても、マクロセル（ｅ）ＮｏｄｅＢであってもよいが、提案する解決法の主要な利益と、より広い適用場面の範囲とからは、ホーム（ｅ）ＮｏｄｅＢとなる。

好ましい実施形態によれば、ローカルゲートウェイ機能は、外部のパケットデータネットワークとの間でトラフィックをルーティングする機能を有する。特にこれは、トラフィックがＰＤＮゲートウェイまたはＧＧＳＮのそれぞれを通過することなく、ユーザ機器からのトラフィックが外部ネットワーク（例えば、インターネット、企業ネットワークおよび／またはホームネットワーク）へ直接ルーティングされることを意味する。

また、ローカルゲートウェイ機能は、ＰＤＮゲートウェイまたはＧＧＳＮのそれぞれとの間で拡張トンネルを通じてＩＰパケットをトンネリングする機能を有してもよい。特に、トンネルは、次の２つの具体的状況において使用される。第１に、ユーザ機器がアイドルモードにある間にダウンリンクトラフィックがローカルゲートウェイ機能に到着した場合、そして第２に、ユーザ機器が別の（ｅ）ＮｏｄｅＢへのハンドオーバーを実行済みの場合である。ＩＰパケットのトンネリングは、例えば、ＧＴＰ（GPRS Tunnelling Protocol）、ＰＭＩＰ（Proxy Mobile IP）、またはＩＰｉｎＩＰに基づいてもよい。

具体的実施形態によれば、ローカルゲートウェイ機能がユーザ機器にＩＰアドレスを割り当て、割り当てたＩＰアドレスをＰＤＮゲートウェイ／ＧＧＳＮに伝達するようにしてもよい。別法として、ＰＤＮゲートウェイ／ＧＧＳＮがユーザ機器にＩＰアドレスを割り当て、そのＩＰアドレスがローカルゲートウェイ機能に伝達されるようにしてもよい。その場合、ローカルゲートウェイ機能は、受信したＩＰアドレスのネットワークアドレス変換（ＮＡＴ）を実行してもよい。

さらに別の好ましい実施形態によれば、ローカルゲートウェイ機能は、ローカルＩＰトラフィック分離の使用に関して、（ｅ）ＮｏｄｅＢと協調する機能を有してもよい。すなわち、ローカルゲートウェイ機能は、ローカルトラフィックの処理を（ｅ）ＮｏｄｅＢにさせてもよい。一方では、判定機能は、アップリンクトラフィックに対するローカルな分離の使用に関係してもよい。随意選択で、これは（ｅ）ＮｏｄｅＢの一部であることも可能である。別法として、この判定機能の部分はＬ−ＧＷで実現されてもよいが、その場合、（ｅ）ＮｏｄｅＢは、正しいアップリンクルーティングを実行するために、この判定機能に問合せをしなければならない。他方では、判定機能は、これに加えて、または別法として、ダウンリンクトラフィックのルーティング、すなわち、ダウンリンクトラフィックが（ｅ）ＮｏｄｅＢに直接ルーティングされるか、または拡張トンネルを通じルーティングされるか、に関係してもよい。

課金の問題に関して、ローカルゲートウェイ機能は、トラフィック監視・報告機能を有するようにしてもよい。例えば、この機能は、定額課金が実行されていない場合に必要となる場合がある。ユーザ機器がマクロセル（そこでは、差別化課金制御および／またはポリシー制御が必要とされる）内に位置するとき、課金／ポリシー制御は、ＰＤＮゲートウェイ（ＥＰＳの場合）または通常通りＧＧＳＮ（ＧＰＲＳの場合）によって処理されてもよい。「ＬＩＰＡ／ＳＩＰＴＯトラフィック」に対するＱｏＳに関しては、課金およびポリシー制御の場合と同様である。すなわち、特別のＱｏＳプロビジョニングは不要である。

有益な（ｅ）ＮｏｄｅＢの構成に関して、（ｅ）ＮｏｄｅＢ機能は、（ｅ）ＮｏｄｅＢによってサービスされるセルに対するユーザ機器のアクセス状態をローカルゲートウェイ機能に提供するように拡張されてもよい。

ＩＰアドレス処理に関して、基本的に２つの異なる実施態様の可能性がある。第１の実施態様によれば、ユーザ機器は、それぞれのＰＤＮコネクション（例えば、ローカルネットワークへのコネクションおよび事業者ネットワークへのコネクション）ごとに別個のＩＰアドレスが割り当てられる。第２の別の実施態様によれば、ユーザ機器は、ＰＤＮ（例えば、ローカルネットワークおよび事業者ネットワーク）への複数の相異なるコネクションに対してただ１つのＩＰアドレスが割り当てられる。すなわち、２つの別個のＡＰＮ（１つはＬＩＰＡ／ＳＩＰＴＯトラフィック、１つは非ＬＩＰＡ／ＳＩＰＴＯトラフィック）の場合、ＵＥは、２つのＩＰアドレス（各ＰＤＮコネクションごとに１つずつ）が割り当てられ、ＬＩＰＡ／ＳＩＰＴＯＡＰＮに対するＩＰアドレスはローカルゲートウェイ機能によって割り当てられ、非ＬＩＰＡ／ＳＩＰＴＯＡＰＮに対するＩＰアドレスはＰＤＮゲートウェイまたはＧＧＳＮのそれぞれによって割り当てられる。ＬＩＰＡ／ＳＩＰＴＯＡＰＮの場合、以下のようにしてもよい。ＵＥがローカルである場合、（ｅ）ＮｏｄｅＢ／Ｌ−ＧＷにおけるパケットルーティングは、無線ベアラと、それぞれのＰＤＮコネクションにリンクされたＳ１ベアラ（これはＬ−ＧＷへの近道である）との間の既知のマッピングに基づいて実行されてもよい。ＵＥが非ローカルである場合、パケットルーティングは、拡張トンネルを通じてコアネットワーク内のＰＤＮゲートウェイ／ＧＧＳＮ経由で実行されてもよい。なお、Ｌ−ＧＷは、これらの機能の共同配置により、または専用通信チャネルにより、ＵＥがそれぞれの（ｅ）ＮｏｄｅＢに接続されていないことについて知っていることに注意すべきである。

非ＬＩＰＡ／ＳＩＰＴＯＡＰＮの場合、以下のようにしてもよい。ＵＥがローカルである場合、（ｅ）ＮｏｄｅＢ／Ｌ−ＧＷにおけるパケットルーティングは、無線ベアラと、それぞれのＰＤＮコネクションにリンクされたＳ１ベアラとの間の既知のマッピングに基づいて実行されてもよい。しかし、ここでは、通常の処理、すなわち、Ｓ１ベアラを通じてＳ−ＧＷ（Serving-Gateway, サービングゲートウェイ）へのルーティング、が行われる。ＵＥが非ローカルである場合には影響はなく、ＩＰパケット処理は通常の標準的な手順に従う。

ＬＩＰＡ／ＳＩＰＴＯおよび非ＬＩＰＡ／ＳＩＰＴＯトラフィックに対して１つのＡＰＮの場合のＩＰパケット処理は、以下の考慮に基づいてもよい。ＵＥは、すべてのトラフィックに対して使用されるただ１つのＩＰアドレスがＰＤＮゲートウェイ／ＧＧＳＮによって割り当てられる。ローカルゲートウェイ機能は、ＮＡＴ実行の目的で割り当てられた１つ以上のＩＰアドレスを有する。これに関して注意すべきであるが、１つの同じＡＰＮがＬＩＰＡ／ＳＩＰＴＯトラフィックおよび非ＬＩＰＡ／ＳＩＰＴＯトラフィックに対して使用される場合、ＮＡＴ（ネットワークアドレス変換）の技術的制限が当てはまる。ＵＥがローカルである場合、ＬＩＰＡ／ＳＩＰＴＯおよび非ＬＩＰＡ／ＳＩＰＴＯトラフィックに対するＩＰパケット処理に違いはない。（ｅ）ＮｏｄｅＢにおけるアップリンクのパケットルーティングは、ルーティングポリシーに基づく（例えば、宛先ＩＰアドレスまたはＵＥにリンクされたアイデンティティに基づく）。ＬＩＰＡ／ＳＩＰＴＯのルーティングポリシーに適合するトラフィックはＬ−ＧＷへルーティングされ、適合しないトラフィックは（通常通り）Ｓ−ＧＷへルーティングされる。ダウンリンクでは、パケットは（ｅ）ＮｏｄｅＢへルーティングされる。なお、この場合も、Ｌ−ＧＷは、（ｅ）ＮｏｄｅＢとのＵＥのコネクションステータスについて知っていることに注意すべきである。

ＵＥが非ローカルである場合、ＬＩＰＡ／ＳＩＰＴＯトラフィックは、拡張トンネルを通じてコアネットワーク内のＰＤＮゲートウェイ／ＧＧＳ経由でルーティングされる。Ｌ−ＧＷは、ＵＥがそれぞれの（ｅ）ＮｏｄｅＢに接続されていないことについて知っている。この場合も、非ＬＩＰＡ／ＳＩＰＴＯトラフィックに対する影響はなく、通常の標準的な手順が当てはまる。

有利な態様として、終端ローカルＩＰおよび／またはインターネットトラフィックがユーザ機器に到着し、ユーザ機器がスリープまたはアイドルモードにある場合、トラフィックは、ＰＤＮゲートウェイ／ＧＧＳＮへトンネリングされてもよい。そして、ＵＥを探索・起動するために、ページング手順が、モバイル事業者ネットワークで実行されてもよい。

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

さまざまなターゲット接続性の場合を例示する模式図である。３ＧＰＰアクセスの非ローミングアーキテクチャにおける本発明によるシステムの第１実施形態を例示する模式図である。３ＧＰＰアクセスの非ローミングアーキテクチャにおける本発明によるシステムの第２実施形態を例示する模式図である。ホーム（ｅ）ＮｏｄｅＢを有するＬＩＰＡに対する本発明によるシステムの実施形態を例示する模式図である。ＵＥがアイドルモードにある場合の本発明によるシステムの実施形態を例示する模式図である。ＵＥがアクティブモードにあり、アンカーホーム（ｅ）ＮｏｄｅＢセルに配置／サービスされている場合の本発明によるシステムの実施形態を例示する模式図である。ＵＥがアクティブモードにあるが、アンカーホーム（ｅ）ＮｏｄｅＢセルに配置／サービスされていない場合の本発明によるシステムの実施形態を例示する模式図である。

図１〜図７に関する説明全体において、簡単のため、「（ｅ）ＮｏｄｅＢ」という用語のみを使用する。この用語は、「（発展型）ＮｏｄｅＢ」、「ホーム（ｅ）ＮＢ」、「Ｈ（ｅ）ＮＢ」、「ノードＢ」、「ＮＢ」、「ホームＮＢ」、および「ＨＮＢ」という用語の省略として理解すべきである。

ＬＩＰＡ（Local IP Access）という用語は、以下では一般的に、（ｅ）ＮｏｄｅＢとローカルに接続されたＩＰネットワークへのアクセス（以下「ローカルトラフィックに対するＬＩＰＡ」という）に対して使用されるとともに、ＳＩＰＴＯ（Selected IP Traffic Offload）と呼ばれるインターネットアクセスに対しても使用される。ＳＩＰＴＯでは、インターネットは、（ｅ）ＮｏｄｅＢから何らかのローカルＩＳＰを通じて、したがって事業者コアネットワークを避けて、直接に到達可能である。本発明の特定の実施形態は、ＬＩＰＡ（すなわちローカルトラフィック）またはＳＩＰＴＯ（すなわちインターネットトラフィック）の一方に優先的に適用されても、両方に等しく適用されてもよい。

図面を参照して説明される本発明の実施形態は発展型ＵＴＲＡＮ（ＬＴＥ）無線アクセスに関するものであるが、実施形態はＵＴＲＡＮ無線アクセス（３Ｇ）にも等しく当てはまることは言うまでもない。

図１は、２つのホーム（ｅ）ＮｏｄｅＢを有するシステムを模式的に例示している。一方のホーム（ｅ）ＮｏｄｅＢ（左側）はアンカーホーム（ｅ）ＮｏｄｅＢとして機能する。これに関して、「アンカー」という用語は、ＵＥが現在関連づけられているホーム（ｅ）ＮｏｄｅＢを表すために使用される。ＵＥは、他のセル、例えば別のホーム（ｅ）ＮｏｄｅＢへのハンドオーバー（（Ａ）で示す）を行い、そこから他のアクセスネットワーク（３ＧＰＰでも非３ＧＰＰでもよい）へのハンドオーバー（（Ｂ）で示す）を行うこともあれば、アンカーホーム（ｅ）ＮｏｄｅＢから他のアクセスネットワークへ直接にハンドオーバー（（Ｃ）で示す）を行うこともある。

図１は、さまざまなターゲット接続性の場合を例示している。例えば、ＵＥがアンカーホーム（ｅ）ＮｏｄｅＢに接続されている場合、一点鎖線はインターネットへのローカルＩＰアクセスを示し、破線はＵＥのホームネットワークへのローカルＩＰアクセスを示し、点線はモバイル事業者のコアネットワーク（ＰＬＭＮ（ＣＮ）、Public Land Mobile Network (Core Network)）および関連する事業者のＩＰサービスへの３ＧＰＰアクセスを示す。

ＵＥが別のホーム（ｅ）ＮｏｄｅＢまたは別のアクセスネットワークへのハンドオーバーを実行している場合、ＵＥのローカルＩＰネットワークへのいわゆるマネージドリモートＩＰ（Managed Remote IP）アクセスがＰＬＭＮ（ＣＮ）を通じて実現される（実線で示す）。ローカルＩＰ接続性をサポートすることに関して、（タイプＡ、ＢまたはＣの）ＵＥモビリティが起こる場合であっても、連続的なサービスがターゲットアーキテクチャによってサポートされることを保証することが重要である。また、事業者によるフレキシブルな制御を提供すべきである。

図２は、３ＧＰＰＥＰＳアーキテクチャにおける本発明によるシステムの第１実施形態を模式的に例示している。このアーキテクチャの一般的側面は当業者に周知であるので、基礎となるアーキテクチャの詳細な説明はここでは省略し、本発明によるアーキテクチャ上の拡張についてのみ詳細に説明する。図２からわかるように、ＵＥは、ＬＥＴ−Ｕｕインタフェースを通じてホーム（ｅ）ＮｏｄｅＢに接続される。従来技術によれば、トラフィックはＳ１インタフェースを通じてサービングゲートウェイ（Ｓ−ＧＷ）へルーティングされ、そこからＳ５／Ｓ８インタフェースを通じてＰＤＮゲートウェイへルーティングされる。それぞれのＡＰＮに応じて、トラフィックはそこから事業者のＩＰサービス（例えば、ＩＭＳ（IP Multimedia Subsystem, ＩＰマルチメディアサブシステム）、ＰＳＳ（Packet Streaming Service, パケットストリーミングサービス）等）へ、または、インターネット、企業ネットワーク等（図示せず）のような他のネットワークへルーティングされる。

本発明によれば、ローカルゲートウェイ機能（Ｌ−ＧＷ）が設けられる。図２に示した実施形態によれば、Ｌ−ＧＷは、ホーム（ｅ）ＮｏｄｅＢと共同配置される。また、Ｌ−ＧＷと、終端エンドポイントとしてのＰＤＮゲートウェイとの間に、拡張トンネルが確立される。さまざまな応用場面におけるＬ−ＧＷおよび拡張トンネルの機能については、図５〜図７を参照して説明する。

図３は、３ＧＰＰアクセスに対する、図２に示したのと基本的に同じアーキテクチャを例示する図である。ただ、拡張トンネル確立に関してのみ相違する。ＰＤＮゲートウェイが拡張トンネルの一方のエンドポイントを構成している図２の実施形態とは異なり、図３の実施形態では、拡張トンネルエンドポイントとして、別個の機能エンティティが設けられる。この機能エンティティは、ＰＤＮゲートウェイと通信する別個のインタフェースを備える。

図４は、本発明の実施形態を模式的に例示する図である。基本的に、図４は、図１と同じネットワークアーキテクチャを示しており、ＵＥの同じハンドオーバー状況が破線で示されている。本発明によれば、ローカルゲートウェイ機能（Ｌ−ＧＷ）が設けられる。図４に示す実施形態において、Ｌ−ＧＷは、アンカーホーム（ｅ）ＮｏｄｅＢと共同配置される。Ｌ−ＧＷおよびモバイル事業者ネットワーク（ＰＬＭＮ（ＣＮ））のＰＤＮゲートウェイが、ＬＩＰＡ／ＳＩＰＴＯ拡張トンネルの２つの終端エンドポイントを構成する。

ほとんどの場合、すべての処理はＵＥごとに行われる。すなわち、Ｌ−ＧＷは、例えばＬＩＰＡ／ＳＩＰＴＯが可能かどうかをチェックし、ＩＰアドレス処理、トラフィックルーティング等を実行する。しかし、複数のＵＥに対して、Ｌ−ＧＷとＰＤＮゲートウェイの間でただ１つのＬＩＰＡ／ＳＩＰＴＯ拡張トンネルを使用することも可能である。

本発明による方法は、ＡＰＮ使用の２つの主な変形をサポートすることができる。これらは、ＬＩＰＡ／ＳＩＰＴＯに対する別個のＡＰＮ、または、ＬＩＰＡ／ＳＩＰＴＯおよび非ＬＩＰＡ／ＳＩＰＴＯトラフィックに対する共通のＡＰＮと、それらの組合せである。なお、注意すべきであるが、基本アーキテクチャおよびその機能においてＡＰＮの個数にほとんど制限はないので、ＡＰＮのさらなる差別化、例えば、１つを非ＬＩＰＡ／ＳＩＰＴＯトラフィックに、１つをローカルトラフィック（ＬＩＰＡ）に、そして第３のＡＰＮをインターネットとの間のトラフィック（ＳＩＰＴＯ）に、とすることも予想され、直接的な拡張である。

図５〜図７は、アンカーホーム（ｅ）ＮｏｄｅＢセル内外の両方における、アイドルモードおよびアクティブモードに対するトンネルおよび他の構成を示している。なお、ホーム（ｅ）ＮｏｄｅＢの場合を例示し詳細に説明しているが、マクロセル（ｅ）ＮｏｄｅＢでの応用例も同様に可能であることに注意すべきである。

図５は、ＵＥが３ＧＰＰアクセスにおいてどこかでアイドルモードにある間に終端トラフィックが到着する状況を例示している。なお、注意すべきであるが、非３ＧＰＰアクセスでは、アイドルモードの定義は一般に存在しない。ＵＥが非３ＧＰＰアクセスにある場合、ＰＤＮゲートウェイが詳細な位置について知っているので、ページングは不要である。図５で、ステップ［１］は、終端ローカルＩＰまたはインターネットトラフィックがＵＥに到着したことを例示している。トラフィックは、本発明によって設けられる拡張トンネルを通じて、ＰＬＭＮ（ＣＮ）のＰＤＮゲートウェイ（ＰＤＮ−ＧＷ）へトンネリングされる。ステップ［２］は、インタフェースＳ５／Ｓ８／Ｓ１１を通じてのページング手順を示している。ＥＰＳアーキテクチャでは、ページング手順はＭＭＥ（Mobility Management Entity, モビリティ管理エンティティ）によって実行される。ステップ［３］は、Ｓ１インタフェースを通じての異なる既存セルへのページングを示している。なお、注意すべきであるが、ホーム（ｅ）ＮｏｄｅＢにトラッキングエリアを特別に割り当てることに関する仮定は不要である。

ステップ［４］は、異なる場面におけるページングへのＵＥのそれぞれの応答を例示している。ステップ［４ａ］に例示したように、ＵＥがアンカーホーム（ｅ）ＮｏｄｅＢセル内に位置する場合、ホーム（ｅ）ＮｏｄｅＢは、Ｌ−ＧＷに対して、拡張トンネルを避けてＬ−ＧＷからＵＥへ直接にトラフィックをルーティングするように通知する。ステップ［４ｂ］に例示したように、ＵＥが別のホーム（ｅ）ＮｏｄｅＢセル内に位置する場合、ホーム（ｅ）ＮｏｄｅＢは、Ｌ−ＧＷに対して、拡張トンネルを使用するように通知する。その結果、トラフィックは、Ｌ−ＧＷからＰＤＮゲートウェイへトンネリングされ、そこから、通常通りＳ−ＧＷを通じて、ＵＥが位置するホーム（ｅ）ＮｏｄｅＢへトンネリングされる。ステップ［４ｃ］に例示したように、ＵＥが３ＧＰＰアクセスの他のセル内に位置する場合、通信は［４ｂ］の場合と同様であり、ホーム（ｅ）ＮｏｄｅＢは、Ｌ−ＧＷに対して、拡張トンネルを使用するように通知する。

図６は、ＵＥがアクティブモードにあり、アンカーホーム（ｅ）ＮｏｄｅＢのセル内に位置する場合を示している。この場合、Ｌ−ＧＷは、ＰＤＮ−ＧＷへの拡張トンネルの確立を開始しない。代わりに、パケットルーティングは、ホーム（ｅ）ＮｏｄｅＢおよびＬ−ＧＷによって、例えばインターネットおよびローカルＩＰネットワークとの間で直接に実行される。

図７は、ＵＥがアンカーホーム（ｅ）ＮｏｄｅＢのセル内に位置しないときの、アクティブモードの場合を例示している。ＵＥは、別のホーム（ｅ）ＮｏｄｅＢセル内（［ａ］の場合）、または、マクロ３ＧＰＰアクセス内（［ｂ］の場合）もしくは非３ＧＰＰアクセス内（［ｃ］の場合）に位置する。３つの場合（［ａ］、［ｂ］または［ｃ］）のいずれにおいても、Ｌ−ＧＷとＰＤＮゲートウェイの間に拡張トンネルが確立され、トラフィックがトンネリングされる。［ａ］および［ｂ］の場合、ＰＤＮゲートウェイに到着するトラフィックはＳ−ＧＷを通じて転送される。ＵＥが非３ＧＰＰアクセス内に位置する場合（［ｃ］の場合）、トラフィックはＰＤＮゲートウェイによって直接ルーティングされ、Ｓ−ＧＷは関与しない。

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

Claims

（ｅ）ＮｏｄｅＢに対するローカルＩＰ接続性をサポートするシステムにおいて、該システムは、ＰＤＮゲートウェイまたはＧＧＳＮを備えたモバイル事業者ネットワークと、前記（ｅ）ＮｏｄｅＢに関連づけられた少なくとも１つのユーザ機器（ＵＥ）とを有し、
ローカルゲートウェイ機能（Ｌ−ＧＷ）が前記（ｅ）ＮｏｄｅＢに対して設けられ、前記ローカルゲートウェイ機能（Ｌ−ＧＷ）と前記モバイル事業者ネットワークの前記ＰＤＮゲートウェイまたは前記ＧＧＳＮとの間に拡張トンネルが確立されることを特徴とする、（ｅ）ＮｏｄｅＢに対するローカルＩＰ接続性をサポートするシステム。
前記拡張トンネルが、前記ＰＤＮゲートウェイ内または前記ＧＧＳＮ内にエンドポイントとして終端することを特徴とする請求項１に記載のシステム。
前記拡張トンネルが、前記ＰＤＮゲートウェイの外部の機能エンティティにおいて終端し、該エンティティが、前記ＰＤＮゲートウェイまたは前記ＧＧＳＮとインタフェースすることを特徴とする請求項１に記載のシステム。
前記拡張トンネルが、前記（ｅ）ＮｏｄｅＢを通じてユーザ機器（ＵＥ）と前記ＰＤＮゲートウェイまたは前記ＧＧＳＮとの間でＰＤＮコネクションが確立されるたびに確立されることを特徴とする請求項１ないし３のいずれか１項に記載のシステム。
前記ＰＤＮゲートウェイまたは前記ＧＧＳＮが、ローカルトラフィックに対する所定の条件に適合するＡＰＮを有するＰＤＮへのコネクション確立の場合にのみ前記拡張トンネルの確立を実行する判定機能を有することを特徴とする請求項１ないし３のいずれか１項に記載のシステム。
前記ローカルゲートウェイ機能（Ｌ−ＧＷ）と前記ＰＤＮゲートウェイまたは前記ＧＧＳＮとの間の前記拡張トンネルが、複数のユーザ機器（ＵＥ）に対して同時並行して確立され使用されることを特徴とする請求項１ないし５のいずれか１項に記載のシステム。
前記ローカルゲートウェイ機能（Ｌ−ＧＷ）が前記（ｅ）ＮｏｄｅＢと共同配置されることを特徴とする請求項１ないし６のいずれか１項に記載のシステム。
前記（ｅ）ＮｏｄｅＢが、ホーム（ｅ）ＮｏｄｅＢまたはマクロセル（ｅ）ＮｏｄｅＢであることを特徴とする請求項１ないし７のいずれか１項に記載のシステム。
前記ローカルゲートウェイ機能（Ｌ−ＧＷ）が、外部のパケットデータネットワークとの間、特に、インターネットおよび前記ユーザ機器（ＵＥ）のホームネットワークとの間で、トラフィックをルーティングする機能を有することを特徴とする請求項１ないし８のいずれか１項に記載のシステム。
前記ローカルゲートウェイ機能（Ｌ−ＧＷ）が、前記ＰＤＮゲートウェイまたは前記ＧＧＳＮとの間で前記拡張トンネルを通じてＩＰパケットをトンネリングする機能を有することを特徴とする請求項１ないし９のいずれか１項に記載のシステム。
前記ローカルゲートウェイ機能（Ｌ−ＧＷ）が、前記ユーザ機器（ＵＥ）にＩＰアドレスを割り当て、該割り当てたＩＰアドレスを前記ＰＤＮゲートウェイまたは前記ＧＧＳＮに伝達する機能を有することを特徴とする請求項１ないし１０のいずれか１項に記載のシステム。
前記ローカルゲートウェイ機能（Ｌ−ＧＷ）が、前記ＰＤＮゲートウェイまたは前記ＧＧＳＮによって前記ユーザ機器に割り当てられたＩＰアドレスを受信し、該受信したＩＰアドレスのネットワークアドレス変換を実行する機能を有することを特徴とする請求項１ないし１１のいずれか１項に記載のシステム。
前記ローカルゲートウェイ機能（Ｌ−ＧＷ）が、ローカルな分離の使用に関して前記（ｅ）ＮｏｄｅＢと協調する機能を有することを特徴とする請求項１ないし１２のいずれか１項に記載のシステム。
前記（ｅ）ＮｏｄｅＢが、アップリンクトラフィックに対するローカルな分離の使用に関する判定機能を有することを特徴とする請求項１ないし１３のいずれか１項に記載のシステム。
前記ローカルゲートウェイ機能（Ｌ−ＧＷ）が、ダウンリンクトラフィックのルーティングに関する判定機能を有することを特徴とする請求項１ないし１４のいずれか１項に記載のシステム。
前記ローカルゲートウェイ機能（Ｌ−ＧＷ）が、トラフィック監視・報告機能を有することを特徴とする請求項１ないし１５のいずれか１項に記載のシステム。
前記（ｅ）ＮｏｄｅＢが、前記（ｅ）ＮｏｄｅＢによってサービスされるセルに対する前記ユーザ機器（ＵＥ）のアクセス状態を前記ローカルゲートウェイ機能（Ｌ−ＧＷ）に提供するように構成されることを特徴とする請求項１ないし１６のいずれか１項に記載のシステム。
前記ユーザ機器（ＵＥ）は、パケットデータネットワークへの各コネクションごとに別個のＩＰアドレスが割り当てられることを特徴とする請求項１ないし１７のいずれか１項に記載のシステム。
前記ユーザ機器（ＵＥ）は、パケットデータネットワークへの複数の相異なるコネクションに対してただ１つのＩＰアドレスが割り当てられることを特徴とする請求項１ないし１７のいずれか１項に記載のシステム。
終端ローカルＩＰおよび／またはインターネットトラフィックが前記ユーザ機器（ＵＥ）に到着し、前記ユーザ機器（ＵＥ）がアイドルモードにある場合、前記トラフィックが前記ＰＤＮゲートウェイまたはＧＧＳＮへトンネリングされ、ページング手順が前記モバイル事業者ネットワークで実行されることを特徴とする請求項１ないし１９のいずれか１項に記載のシステム。
（ｅ）ＮｏｄｅＢに対するローカルＩＰ接続性をサポートする方法であって、特に、請求項１ないし２０のいずれか１項に記載のシステムで実行される方法において、ＰＤＮゲートウェイまたはＧＧＳＮを備えたモバイル事業者ネットワークが提供され、少なくとも１つのユーザ機器（ＵＥ）が前記（ｅ）ＮｏｄｅＢに関連づけられ、
ローカルゲートウェイ機能（Ｌ−ＧＷ）が前記（ｅ）ＮｏｄｅＢに対して設けられ、前記ローカルゲートウェイ機能（Ｌ−ＧＷ）と前記モバイル事業者ネットワークの前記ＰＤＮゲートウェイまたは前記ＧＧＳＮとの間に拡張トンネルが確立されることを特徴とする、（ｅ）ＮｏｄｅＢに対するローカルＩＰ接続性をサポートする方法。