JP2015144489A - 移動通信ネットワーク内で制御プレーンを担当するサーバー及び該サーバーでサービスを制御する方法 - Google Patents

Abstract

【課題】移動通信ネットワーク内において制御プレーンを担当するサーバーでサービスを制御する方法を提供する。【解決手段】Ｈｏｍｅ （ｅ）ＮｏｄｅＢから、ＡＰＮ、ローカルゲートウェイの識別子を表すパラメータ、ＳＩＰＴＯサービス関連指示子のうち一つ以上を含む第１メッセージを受信する。第１メッセージは、端末による要請メッセージを含む。Ｈｏｍｅ （ｅ）ＮｏｄｅＢでＳＩＰＴＯサービスが可能である場合、ＡＰＮに基づいて、端末のデータに対してＳＩＰＴＯを適用可能であるか否か判断する。判断段階では、保存されているＡＰＮ関連情報に基づいて、第１メッセージ内に含まれたＡＰＮがＳＩＰＴＯ適用可能なものであるか否か判断する。ＳＩＰＴＯが適用可能な場合、ＳＩＰＴＯサービスに対するユーザーの同意情報に基づいて、端末にＳＩＰＴＯサービスを提供するか否かを決定し、ＳＩＰＴＯサービス通知をＨｏｍｅ （ｅ）ＮｏｄｅＢに伝送する。【選択図】図６

Description

本発明は、移動通信ネットワーク内で制御プレーン（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ）を担当するサーバー及び該サーバーでサービスを制御する方法に関する。

３世代移動通信システムの技術規格を制定する３ＧＰＰでは、４世代移動通信に関する様々なフォーラム及び新しい技術に対応するべく、２００４年末頃から３ＧＰＰ技術の性能を最適化し且つ向上させようとする努力の一環としてＬＴＥ／ＳＡＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ／Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ）技術の研究を行ってきている。

３ＧＰＰ ＳＡ ＷＧ２を中心に行われたＳＡＥは、３ＧＰＰ ＴＳＧ ＲＡＮのＬＴＥ作業と共にネットワークの構造を決定し、異機種網間の移動性を支援することを目的とする網技術に関する研究であって、最近の３ＧＰＰの重要な標準化イッシュ（ｉｓｓｕｅ）の一つである。これは、３ＧＰＰシステムを、ＩＰに基づいて様々な無線接続技術を支援するシステムへと発展させるための作業であって、より向上したデータ伝送能力により伝送遅延を最小化させる、最適化したパケットベースのシステムを目指して作業が進行されてきた。

３ＧＰＰ ＳＡ ＷＧ２で定義したＳＡＥ上位レベル参照モデル（ｒｅｆｅｒｅｎｃｅ ｍｏｄｅｌ）は、非ローミングケース（ｎｏｎ−ｒｏａｍｉｎｇ ｃａｓｅ）及び様々なシナリオのローミングケース（ｒｏａｍｉｎｇ ｃａｓｅ）を含んでおり、詳細内容は３ＧＰＰ標準文書ＴＳ ２３．４００ａとＴＳ２３．４００ｂを参照すればよい。図１のネットワーク構造図は、これを簡略に再構成したものである。

図１は、進展した移動通信ネットワークの構造図である。

図１のネットワーク構造における最大の特徴の一つは、進展した（Ｅｖｏｌｖｅｄ）ＵＴＲＡＮのｅＮｏｄｅＢと、コアネットワーク（Ｃｏｒｅ Ｎｅｔｗｏｒｋ）のゲートウェイ（Ｇａｔｅｗａｙ）と、の２層モデル（２ Ｔｉｅｒ Ｍｏｄｅｌ）に基づいているという点であり、正確に一致するものではないが、ｅＮｏｄｅＢ ２０は、既存のＵＭＴＳシステムにおけるＮｏｄｅＢ及びＲＮＣの機能を有しており、ゲートウェイは、既存のシステムにおけるＳＧＳＮ／ＧＧＳＮ機能を有しているとすればよい。

また、もう一つの重要な特徴は、接続ネットワーク（Ａｃｃｅｓｓ ｎｅｔｗｏｒｋ）とコアネットワークとの間の制御プレーン（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ）及びユーザープレーン（Ｕｓｅｒ Ｐｌａｎｅ）が、相互に異なったインターフェース（Ｉｎｔｅｒｆａｃｅ）で交換されるという点である。既存のＵＭＴＳシステムではＲＮＣとＳＧＳＮとの間にＩｕという一つのインターフェースが存在したのに対し、制御信号（Ｃｏｎｔｒｏｌ Ｓｉｇｎａｌ）の処理を担当するＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）５１がＧＷ（Ｇａｔｅｗａｙ）と分離された構造を有することから、Ｓ１−ＭＭＥ、Ｓ１−Ｕといった２つのインターフェースがそれぞれ用いられることになった。該ＧＷには、サービングゲートウェイ（Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ）（以下、「Ｓ−ＧＷ」）５２及びパケットデータネットワークゲートウェイ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）（以下、「ＰＤＮ−ＧＷ」又は「Ｐ−ＧＷ」という。）５３がある。

図２は、（ｅ）ＮｏｄｅＢとＨｏｍｅ（ｅ）ＮｏｄｅＢとの関係を示す図である。

上記の３世代又は４世代の移動通信システムにおいて、マルチメディアコンテンツ、ストリーミングなどの高容量サービスと両方向サービスを支援するためにセル容量を増やす試みが続いている。

すなわち、通信の発達及びマルチメディア技術の普及に伴って様々な大容量伝送技術が要求されるにつれ、無線容量を増大させるための方法としてより多い周波数リソースを割り当てる方法が提供されてきたが、限られた周波数リソースを多数の使用者に割り当てるには限界があった。

セル容量を増やすために高い周波数帯域を使用し、セル半径を減らすというアプローチが行われてきた。ピコセル（ｐｉｃｏ ｃｅｌｌ）のような、セル半径の小さいセルを適用すると、既存のセルラーシステムで用いた周波数よりも高い帯域を用いるようになり、より多い情報を伝達することが可能になるという利点があるが、同一の面積に対してより多い基地局を設置しなければならず、高コストとなる欠点があった。

このように小さいセルを用いてセル容量を上げるアプローチのうち、最近では、Ｈｏｍｅ（ｅ）ＮｏｄｅＢ ３０のようなフェムト基地局が提案された。

このＨｏｍｅ（ｅ）ＮｏｄｅＢ ３０は、３ＧＰＰ Ｈｏｍｅ（ｅ）ＮｏｄｅＢのＲＡ ＮＷＧ３を中心に研究され始め、最近、ＳＡＷＧでも本格的に研究されている。

図２に示す（ｅ）ＮｏｄｅＢ ２０はマクロ基地局であり、図２に示すＨｏｍｅ（ｅ）ＮｏｄｅＢ ３０がフェムト基地局であってよい。本明細書では３ＧＰＰの用語に基づいて説明するものとし、（ｅ）ＮｏｄｅＢは、ＮｏｄｅＢ或いはｅＮｏｄｅＢのことを指し、Ｈｏｍｅ（ｅ）ＮｏｄｅＢは、Ｈｏｍｅ ＮｏｄｅＢ或いはＨｏｍｅ ｅＮｏｄｅＢのことを指す。

点線で示すインターフェースは、（ｅ）ＮｏｄｅＢ ２０及びＨｏｍｅ（ｅ）ＮｏｄｅＢ ３０とＭＭＥ ５１０との間の制御信号伝送のためのものである。そして、実線で示すインターフェースは、ユーザープレーンのデータの伝送のためのものである。

図３は、従来技術における問題点を示す図である。

図３に示すように、（ｅ）ＮｏｄｅＢ ２０とＳ−ＧＷ ５２間のインターフェースにトラフィックが過負荷（ｏｖｅｒｌｏａｄ）又は混雑（ｃｏｎｇｅｓｔｉｏｎ）になったり、Ｈｏｍｅ（ｅ）ＮｏｄｅＢ ３０とＳ−ＧＷ ５２間のインターフェースにトラフィックが過負荷又は混雑になったりすれば、ＵＥ １０へのダウンリンクデータ或いはＵＥ １０からのアップロードデータは正しく伝送されず、失敗となることがある。

或いは、Ｓ−ＧＷ ５２とＰＤＮ−ＧＷ ５３間のインターフェース、或いはＰＤＮ−ＧＷ ５３と移動通信事業者のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）サービスネットワーク間のインターフェースが過負荷（ｏｖｅｒｌｏａｄ）又は混雑（ｃｏｎｇｅｓｔｉｏｎ）となる場合にも、ＵＥ １０へのダウンリンクデータ或いはＵＥ １０からのアップロードデータは正しく伝送されず、失敗となることがある。

また、ＵＥが、サービスを受けている現在セルから他のセルへとハンドオーバーするとき、他のセルが過負荷の状態であれば、当該ＵＥのサービスはドロップ（ｄｒｏｐ）する問題が発生する。

このような問題点を解決するために、移動通信事業者はＳ−ＧＷ ５２及びＰＤＮ−ＧＷ ５３を高容量に変えたり、新しい装備を増設してきたが、これは、極めて高いコストがかかるという不具合があった。しかも、送受信されるデータの量は幾何級数的に増加し、すぐに過負荷になることもあった。

一方、このように移動通信ネットワークを増設することなく、Ｓ−ＧＷ ５２及びＰＤＮ−ＧＷ ５３を最適化する種々の方案が提示されたことがある。例えば、ＵＥの特定ＩＰトラフィック（例えば、インターネットサービス）を、マクロアクセスネットワークでは最適経路を選択して伝送し、フェムトアクセスネットワーク（Ｆｅｍｔｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ）（例えば、Ｈｏｍｅ（ｅ）ＮＢ）では移動通信ネットワークを通る経路で送受信せず、移動通信ネットワーク以外の公衆網、すなわち、有線ネットワークのノードを通る経路に迂回（Ｓｅｌｅｃｔｅｄ ＩＰ ｔｒａｆｆｉｃ ｏｆｆｌｏａｄ）させる技術、すなわち、ＳＩＰＴＯが提示されたことがある。

図４は、ＳＩＰＴＯ（Ｓｅｌｅｃｔｅｄ ＩＰ Ｔｒａｆｆｉｃ Ｏｆｆｌｏａｄ）の概念を示す図である。

図４を参照すると、例示的にＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）のような移動通信システムが示されている。このＥＰＳシステムは、（ｅ）ＮｏｄｅＢ ２０、ＭＭＥ ５１、Ｓ−ＧＷ ５２、Ｐ−ＧＷ ５３を含んでいる。そしてＨｏｍｅ（ｅ）ＮｏｄｅＢ ３０が示されている。

同図に示すように、ＳＩＰＴＯ（Ｓｅｌｅｃｔｅｄ ＩＰ ｔｒａｆｆｉｃ ｏｆｆｌｏａｄ）技術は、ＵＥ １０の特定ＩＰトラフィック（例えば、インターネットサービス）を、移動通信事業者のＩＰサービスネットワーク６０内のノードを経由せず、有線ネットワーク７０のノードに迂回させる。

例えば、ＵＥ １０の（ｅ）ＮｏｄｅＢ ２０へのアクセスが許可されると、ＵＥ １０は、（ｅ）ＮｏｄｅＢ ２０を通って公衆通信網のような有線ネットワーク７０を経由するセッションを生成し、該セッションを通じてＩＰネットワークサービスを行えばよい。このとき、事業者政策及び加入情報が考慮されるとよい。

このように上記セッションを生成可能にするには、ゲートウェイ、すなわち、ＵＭＴＳではＧＧＳＮの機能の一部を担当するローカルゲートウェイ、或いはＥＰＳではＰ−ＧＷ（ＰＤＮ Ｇａｔｅｗａｙ）の機能の一部を担当するローカルゲートウェイを、（ｅ）ＮｏｄｅＢ ２０に近接して設置されたものにすればよい。

このようなローカルゲートウェイをローカルＧＧＳＮ或いはローカルＰ−ＧＷと呼ぶ。ローカルＧＧＳＮ或いはローカルＰ−ＧＷの機能は、ＧＧＳＮ又はＰ−ＧＷのそれに似ている。

以上のように、ＳＩＰＴＯ技術は、ＵＥのデータを（ｅ）ＮｏｄｅＢ ２０、すなわち、マクロ基地局を通して公衆通信網のような有線網へと迂回（Ｏｆｆｌｏａｄ）させるためにセッションを生成する概念を提案した。

しかしながら、このような従来のＳＩＰＴＯ技術は、ユーザーのデータがマクロ基地局、すなわち、（ｅ）ＮｏｄｅＢ ２０を通るようにするから、（ｅ）ＮｏｄｅＢ ２０が過負荷状態の場合には依然として問題が発生する。

したがって、本明細書は、ユーザーのデータを、Ｈｏｍｅ（ｅ）ＮｏｄｅＢを経由しても公衆通信網のような有線網へと迂回（Ｏｆｆｌｏａｄ）可能にさせる技術を提示することを目的とする。

上記の目的を達成するために、本明細書は、ユーザーのデータをＨｏｍｅ （ｅ）ＮｏｄｅＢを通しても公衆通信網のような有線網に迂回（Ｏｆｆｌｏａｄ）させることができるようにする技術を提示する。

具体的に、本明細書は、移動通信ネットワーク内において制御プレーン（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ）を担当するサーバーでサービスを制御する方法を提供する。この制御方法は、Ｈｏｍｅ （ｅ）ＮｏｄｅＢから、ＡＰＮ（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ）、ローカルゲートウェイの識別子を表すパラメータ、及びＳＩＰＴＯ（Ｓｅｌｅｃｔｅｄ ＩＰ Ｔｒａｆｆｉｃ ｏｆｆｌｏａｄ）サービス関連指示子のうち一つ以上を含む第１メッセージを受信するステップを含むとよい。前記第１メッセージは、端末による要請メッセージを含むとよい。前記制御方法は、前記受信した第１メッセージに基づいて、前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢでＳＩＰＴＯサービスが可能であることが確認される場合に、前記第１メッセージ内のＡＰＮに基づいて、前記端末のデータに対してＳＩＰＴＯを適用させることが可能であるか否か判断するステップを含むとよい。ここで、前記判断段階では、あらかじめ保存されているＡＰＮ関連情報に基づいて、前記第１メッセージ内に含まれたＡＰＮがＳＩＰＴＯ適用可能なものであるか否か判断すればよい。前記制御方法は、前記端末のデータに対してＳＩＰＴＯを適用させることが可能である場合に、前記ＳＩＰＴＯサービスに対するユーザーの同意情報に基づいて、前記端末にＳＩＰＴＯサービスを提供するか否かを決定するステップと、前記決定に基づいて、ＳＩＰＴＯサービス通知を前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢに伝送するステップと、をさらに含んでもよい。

一方、本明細書は、ネットワーク内において制御プレーン（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ）を担当するサーバーを提供する。前記サーバーは、Ｈｏｍｅ （ｅ）ＮｏｄｅＢからＡＰＮ（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ）、ローカルゲートウェイの識別子を表すパラメータ、及びＳＩＰＴＯ（Ｓｅｌｅｃｔｅｄ ＩＰ Ｔｒａｆｆｉｃ ｏｆｆｌｏａｄ）サービス関連指示子のうち一つ以上を含む第１メッセージを受信する送受信部を備えるとよい。前記第１メッセージは、端末による要請メッセージを含むとよい。前記サーバーは、前記第１メッセージに基づいて、前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢでＳＩＰＴＯサービスが可能であることが確認される場合に、前記ＡＰＮに基づいて、前記端末のデータに対してＳＩＰＴＯを適用させることが可能であるか否か判断し、前記端末のデータに対してＳＩＰＴＯを適用させることが可能である場合に、前記ＳＩＰＴＯサービスに対するユーザーの同意情報に基づいて、前記端末にＳＩＰＴＯサービスを提供するか否かを決定する制御部をさらに含んでもよい。前記送受信部は、前記制御部の前記決定に基づいてＳＩＰＴＯサービス通知を前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢに伝送すればよい。

前記ＳＩＰＴＯを適用させることが可能であるか否か判断するために、前記制御部は、あらかじめ保存されているＡＰＮ関連情報に基づいて、前記第１メッセージ内に含まれたＡＰＮがＳＩＰＴＯ適用可能なものであるか否かを判断してもよい。

前記ＳＩＰＴＯサービスに対するユーザーの同意情報は、前記端末に情報要請メッセージを伝送し、前記情報要請メッセージに対する応答として受信される情報応答メッセージ内に含まれていてもよい。

前記ＳＩＰＴＯサービスに対するユーザーの同意情報が含まれた情報応答メッセージは、前記端末がアタッチ手順、ＴＡＵ（Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ）手順、ハンドオーバー手順を行う時に受信されてもよい。

前記ＳＩＰＴＯサービスに対するユーザーの同意情報は、加入者情報サーバーから獲得されたものであってもよい。

前記制御方法は、ＬＩＰＡ（Ｌｏｃａｌ ＩＰ Ａｃｃｅｓｓ）サービスを前記端末に提供するか否かを決定するステップと、前記決定に基づいて、ＬＩＰＡサービス許可情報又はフィルタ情報を前記ローカルゲートウェイに伝送するステップと、前記ＬＩＰＡサービス許可情報、フィルタ情報、そしてＬＩＰＡサービスに対する通知のうち一つ以上を前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢに伝送するステップ、のうち一つ以上をさらに含んでもよい。

ここで、前記ＬＩＰＡサービス許可情報又はフィルタ情報は、前記端末により発生したＬＩＰＡサービスのためのデータを前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢ又はローカルゲートウェイが遮断すべきか否かを決定するのに用いられるとよい。そして、前記ＬＩＰＡサービスに対する通知は、前記端末にＬＩＰＡサービスが許容されるか否かを知らせるために用いられるとよい。

前記ＳＩＰＴＯサービス通知は、ＳＩＰＴＯフェムトが適用されたことを表すものであってもよい。前記ＳＩＰＴＯフェムトは、前記端末のデータが前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢに接続したホームネットワークを通って迂回することを意味すればよい。

前記ＳＩＰＴＯフェムトが適用されたことを知らせるＳＩＰＴＯサービス通知は、前記ＳＩＰＴＯマクロが適用されたことを知らせる通知とは異なる専用の通知メッセージであればよい。或いは、前記ＳＩＰＴＯフェムトが適用されたことを知らせるＳＩＰＴＯサービス通知は、ＳＩＰＴＯサービスが適用されたことを知らせる通知内の属性値で表現されるとよい。

本明細書の開示によれば、ユーザーのデータをＨｏｍｅ （ｅ）ＮｏｄｅＢを通しても公衆通信網のような有線網に迂回（Ｏｆｆｌｏａｄ）させることが可能になる。

一方、ユーザーのデータをＨｏｍｅ （ｅ）ＮｏｄｅＢを通しても公衆通信網のような有線網に迂回させる時、ユーザー又はＵＥによってＬＩＰＡサービスは選択的に支援するようにする。

進展した移動通信ネットワークの構造図である。 （ｅ）ＮｏｄｅＢとＨｏｍｅ（ｅ）ＮｏｄｅＢとの関係を示す図である。 従来技術における問題点を示す図である。 ＳＩＰＴＯ（Ｓｅｌｅｃｔｅｄ ＩＰ Ｔｒａｆｆｉｃ Ｏｆｆｌｏａｄ）の概念を示す図である。 本明細書で提示するアーキテクチャーを例示する図である。 Ｈｏｍｅ（ｅ）ＮｏｄｅＢを通してＳＩＰＴＯサービスを提供するための基本的な手順を示す例示図である。 本発明のＳＩＰＴＯサービスのための制御手順を簡略に示すフローチャートである。 図７に示した制御手順を詳細に示すフローチャートである。 図８に示したメッセージのプロトコルを例示する図である。 本発明に係るＨｏｍｅ（ｅ）ＮｏｄｅＢ ３００及びＭＭＥ ５１０の構成ブロック図である。

本発明は、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）及びＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）に基づいて説明されるが、本発明は、このような通信システムに限定されず、本発明の技術的思想が適用されうるいかなる通信システム及び方法に適用されてもよい。

本明細書で使われる技術的用語は、単に、特定の実施例を説明するためのもので、本発明を限定するためのものではないことに留意されたい。また、本明細書で使われる技術的用語は、本明細書で特別に定義しない限り、本発明の属する技術の分野における通常の知識を有する者にとって一般的に理解される意味として解釈されなければならず、過度に包括的な意味や過度に縮小した意味として解釈されてはならない。また、本明細書で使われる技術的用語が本発明の思想を正確に表現していない誤った技術的用語になっていると、それは、当業者が正しく理解できるような技術的用語に直して理解されるべきである。また、本発明で使われる一般的な用語は、辞書に定義されている通りに、又は前後文脈に照らして解釈されなければならず、過度に縮小した意味として解釈されてはならない。

また、本明細書で使われる単数の表現は、文脈から明らかでない限り、複数の表現をも含む。本出願で、「構成される」又は「備える」などの用語は、明細書上に記載された種々の構成要素又は種々の段階の全てを必ず備えるという意味で解釈されるものではなく、それらの一部の構成要素又は一部の段階を備えないこともあり、又は追加の構成要素又は段階をさらに備えることもあるという意味で解釈されるべきである。

また、本明細書で使われる第１、第２のような序数を含む用語は、種々の構成要素を説明するのに使われているが、これらの構成要素を限定する目的ではなく、一つの構成要素を他の構成要素から区別する目的にのみ使われている。例えば、本発明の権利範囲から逸脱することなく、第１構成要素が第２構成要素と命名されてもよく、同様に第２構成要素が第１構成要素と命名されてもよい。

ある構成要素が他の構成要素に「連結」又は「接続」されているとした場合、ある構成要素が他の構成要素に直接連結又は接続されていることもあり、両構成要素の間にさらに他の構成要素が介在されていることもある。一方、ある構成要素が他の構成要素に「直接連結」又は「直接接続」されているとした場合は、両構成要素の間にさらに他の構成要素が存在していないと理解すべきである。

以下、添付の図面を参照して、本発明の好適な実施例について詳細に説明する。ただし、図面を通じて同一又は類似の構成要素には同一の参照番号を付し、その重複説明は省略するものとする。また、本発明を説明するにあって、関連の公知技術に関する具体的な説明が本発明の要旨をあいまいにさせる可能性があると判断される場合にはその詳細な説明を省略する。また、添付の図面は、本発明の思想を容易に理解させるためのもので、本発明の思想を制限するためのものではないことに留意しなければならない。本発明の思想は、添付の図面の他、あらゆる変更、均等物又は代替物にまでも拡張されるものとして解釈されるべきである。

添付の図面では例示的にＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）が示されているが、このＵＥは、端末（Ｔｅｒｍｉｎａｌ）、ＭＥ（Ｍｏｂｉｌｅ Ｅｑｕｉｐｍｅｎｔ）などの用語に代えてもよい。また、ＵＥは、ノートパソコン、携帯電話、ＰＤＡ、スマートフォン（Ｓｍａｒｔ Ｐｈｏｎｅ）、マルチメディア機器などのように携帯可能な機器であってもよく、ＰＣ、車両搭載装置のように携帯不可能な機器であってもよい。

用語の定義

以下、図面を参照して本発明を説明するに先立って、本発明の理解を助けるために、本明細書で使われる用語を簡略に定義する。

ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍの略語で、３世代移動通信ネットワークを意味する。

ＥＰＳ：Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍの略語で、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）ネットワークを支援するコアネットワークを意味する。ＵＭＴＳが進展した形態のネットワーク

ＰＤＮ（Ｐｕｂｌｉｃ Ｄａｔａ Ｎｅｔｗｏｒｋ）：サービスを提供するサーバーが位置している独立した網。

ＡＰＮ（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ）：ネットワークで管理する接続ポイントの名前で、ＵＥに提供される。すなわち、ＰＤＮの名前（文字列）のことを指す。この接続ポイントの名前に基づいて、データの送受信のための該当のＰＤＮが決定される。

接続制御（Ａｃｃｅｓｓ ｃｏｎｔｒｏｌ）：Ｈｏｍｅ（ｅ）ＮｏｄｅＢのようなアクセスシステムにＵＥの使用を許可したり、他のアクセスシステムへと移動させる制御手順。

ＴＥＩＤ（Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ Ｉｄｅｎｔｉｆｉｅｒ）：ネットワーク内のノード同士に設定されたトンネルのエンドポイント（Ｅｎｄｐｏｉｎｔ）ＩＤ。各ＵＥのベアラ（ｂｅａｒｅｒ）単位に区間別に設定される。

ＮｏｄｅＢ：ＵＭＴＳネットワークの基地局。屋外に設置され、セルカバレッジ規模はマクロセルに該当する。

ｅＮｏｄｅＢ：ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）の基地局。屋外に設置され、セルカバレッジ規模はマクロセルに該当する。

（ｅ）ＮｏｄｅＢ：ＮｏｄｅＢとｅＮｏｄｅＢを総称する。

Ｈｏｍｅ ＮｏｄｅＢ：ＵＭＴＳ網の基地局。屋内に設置され、セルカバレッジ規模はフェムトセルに該当する。

Ｈｏｍｅ ｅＮｏｄｅＢ：ＥＰＳ網の基地局。屋内に設置され、セルカバレッジ規模はフェムトセルに該当する。

Ｈｏｍｅ （ｅ）ＮｏｄｅＢ：Ｈｏｍｅ ＮｏｄｅＢとＨｏｍｅ ｅＮｏｄｅＢを総称する。

Ｈｏｍｅ （ｅ）ＮｏｄｅＢゲートウェイ：一つ以上のＨｏｍｅ （ｅ）ＮｏｄｅＢと接続してコアネットワークとインターフェーシングする役割を担うゲートウェイである。

Ｈｏｍｅ （ｅ）ＮｏｄｅＢ Ｓｕｂｓｙｓｔｅｍ：Ｈｏｍｅ （ｅ）ＮｏｄｅＢとＨｏｍｅ （ｅ）ＮｏｄｅＢ Ｇａｔｅｗａｙとを一つのセットにして無線網を管理する形態である。このＨｏｍｅ （ｅ）ＮｏｄｅＢサブシステムとＨｏｍｅ （ｅ）ＮｏｄｅＢはいずれも無線網を管理し、コアネットワークと連動する役割を担うから、一つの集合体の形態と考えればよい。そのため、以下ではＨｏｍｅ （ｅ）ＮｏｄｅＢとＨｏｍｅ （ｅ）ＮｏｄｅＢサブシステムという用語を同一の意味で使うものとする。

ＭＭＥ：Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙの略語で、ＵＥに対するセッションと移動性を提供するためにＥＰＳ内で各エンティティを制御する役割を担う。

閉鎖加入者グループ（Ｃｌｏｓｅｄ Ｓｕｂｓｃｒｉｂｅｒ Ｇｒｏｕｐ：ＣＳＧ）：一つ以上のＨｏｍｅ （ｅ）ＮｏｄｅＢのグループを意味する。ＣＳＧに属したＨｏｍｅ （ｅ）ＮｏｄｅＢは同一のＣＳＧ ＩＤを有する。各ユーザーはＣＳＧ別に使用許可を受ける。

閉鎖接続モード（Ｃｌｏｓｅｄ Ａｃｃｅｓｓ Ｍｏｄｅ）：Ｈｏｍｅ （ｅ）ＮｏｄｅＢがＣＳＧセルとして動作することを指す。当該セルに許容されたユーザー端末に限ってアクセスを許容する方式で動作することをいう。すなわち、Ｈｏｍｅ （ｅ）ＮｏｄｅＢが支援する特定ＣＳＧ ＩＤに対する権限を持つ端末のみがアクセス可能である。

開放接続モード（Ｏｐｅｎ Ａｃｃｅｓｓ Ｍｏｄｅ）：Ｈｏｍｅ （ｅ）ＮｏｄｅＢが、ＣＳＧの概念ではなく一般セル（ｎｏｒｍａｌ ｃｅｌｌ、ｎｏｎ−ＣＳＧ ｃｅｌｌ）のような方式で動作することを指す。すなわち、一般（ｅ）ＮｏｄｅＢと同様に動作することをいう。

混合アクセスモード（Ｈｙｂｒｉｄ ａｃｃｅｓｓ ｍｏｄｅ）：Ｈｏｍｅ （ｅ）ＮｏｄｅＢがＣＳＧセルとして動作するが、ｎｏｎ−ＣＳＧ加入者にもアクセスを許容することを指す。当該セルに支援可能な特定ＣＳＧ ＩＤを持つユーザー端末にアクセスを許容してＨｏｍｅ （ｅ）ＮｏｄｅＢサービスを提供することができ、且つＣＳＧ権限のない端末にもアクセスを許容する方式で動作するモードをいう。

Ｓｅｌｅｃｔｅｄ ＩＰ Ｔｒａｆｆｉｃ Ｏｆｆｌｏａｄ（ＳＩＰＴＯ）：ＵＥがＨｏｍｅ （ｅ）ＮｏｄｅＢや（ｅ）ＮｏｄｅＢを通して特定ＩＰトラフィックを伝送する時、移動通信事業者のネットワーク（例えば、３ＧＰＰ、３ＧＰＰ２）ではなくインターネットなどの有線ネットワークへと迂回させる技術。

ＳＩＰＴＯフェムト（又はフェムトＳＩＰＴＯ）：ＵＥがＨｏｍｅ （ｅ）ＮｏｄｅＢを通して特定ＩＰトラフィックを伝送する時、移動通信事業者のネットワーク（例えば、３ＧＰＰ、３ＧＰＰ２）ではなくインターネットなどの有線ネットワークへと迂回させる技術。

ＳＩＰＴＯマクロ（又はマクロＳＩＰＴＯ）：ＵＥが（ｅ）ＮｏｄｅＢを通して特定ＩＰトラフィックを伝送する時、移動通信事業者のネットワーク（例えば、３ＧＰＰ、３ＧＰＰ２）ではなくインターネットなどの有線ネットワークへと迂回させる技術。

Ｌｏｃａｌ ＩＰ Ａｃｃｅｓｓ（ＬＩＰＡ）：Ｈｏｍｅ （ｅ）ＮｏｄｅＢをローカルネットワーク（すなわち、小規模のネットワーク、例えば、家庭のホームネットワークや会社ネットワーク）に接続させ、該Ｈｏｍｅ （ｅ）ＮｏｄｅＢ内にあるＵＥがそのＨｏｍｅ （ｅ）ＮｏｄｅＢを通って当該ローカルネットワークに接続できるようにする技術。

ローカルゲートウェイ（Ｌｏｃａｌ Ｇａｔｅｗａｙ）：Ｈｏｍｅ （ｅ）ＮｏｄｅＢを通るＬＩＰＡやＳＩＰＴＯを可能にするための、すなわち、コアネットワークを経由せずにホームネットワークや有線網にデータを直接伝送可能にするためのゲートウェイである。該ローカルゲートウェイはＨｏｍｅ （ｅ）ＮｏｄｅＢと有線網との間に設けられて、Ｈｏｍｅ （ｅ）ＮｏｄｅＢと有線網との間にベアラを生成したり、Ｈｏｍｅ （ｅ）ＮｏｄｅＢとローカルネットワークとの間にベアラを生成したりするようにし、該生成されたベアラを通じてデータ伝送が可能となるようにする。

セッション（Ｓｅｓｓｉｏｎ）：セッションはデータ伝送のための通路で、その単位はＰＤＮ、ベアラ（Ｂｅａｒｅｒ）、ＩＰフロー（ｆｌｏｗ）単位などとすればよい。各単位は、３ＧＰＰで定義したように、対象ネットワーク全体単位（ＡＰＮ又はＰＤＮ単位）、この単位内においてＱｏＳで区別する単位（ベアラ単位）、あて先ＩＰアドレス単位に区別するとよい。

ＰＤＮ接続（ｃｏｎｎｅｃｔｉｏｎ）：端末からＰＤＮへの接続、すなわち、ｉｐアドレスで表現される端末とＡＰＮで表現されるＰＤＮとの連係（接続）のことを指す。これは、セッションが形成されるようにするコアネットワーク内におけるエンティティ間の接続（端末−ＰＤＮ ＧＷ）を意味する。

ＵＥ Ｃｏｎｔｅｘｔ：ネックワークでＵＥを管理するために使われるＵＥの状況情報、すなわち、ＵＥ ｉｄ、移動性（現在位置など）、セッションの属性（ＱｏＳ、優先順位など）で構成された状況情報

ローカルＰＤＮ：外部ＰＤＮではなくホームネットワークや企業ネットワークのような独立した個別ネットワーク

ローカルＨｏｍｅ （ｅ）ＮｏｄｅＢネットワーク：ローカルＰＤＮに接続するためのネットワークを意味し、Ｈｏｍｅ （ｅ）ＮｏｄｅＢとＬ−ＧＷで構成されている。

ローカルネットワーク：ローカルＨｏｍｅ （ｅ）ＮｏｄｅＢネットワーク及びローカルＰＤＮを含むネットワーク

以下では、本明細書で提示される方案について簡略に説明する。

Ｈｏｍｅ （ｅ）ＮｏｄｅＢでＳＩＰＴＯサービスを提供するための方案についての説明

本明細書によれば、３ＧＰＰ ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）／ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）のような移動通信システムにおいてＨｏｍｅ （ｅ）ＮｏｄｅＢを通してＵＥの特定ＩＰトラフィック（例えば、インターネットサービス）を移動通信ネットワークではなく公衆網、すなわち、有線ネットワークのノードへの経路に迂回（Ｓｅｌｅｃｔｅｄ ＩＰ ｔｒａｆｆｉｃ ｏｆｆｌｏａｄ）させるためのアーキテクチャーが提示される。

これについて図５を参照して説明する。

図５は、本明細書で提示されるアーキテクチャーを例示する図である。

図５を参照すると、例示的にＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）のような移動通信システムが示されている。このＥＰＳシステムは、ソース基地局３００ａ、ターゲット基地局３００ｂ、ソースローカルＰ−ＧＷ ４００ａ、ターゲットローカルＰ−ＧＷ ４００ｂ、ソースＭＭＥ ５１０ａ、ターゲットＭＭＥ ５１０ｂ、ソースＳ−ＧＷ ５２０ａ、ターゲットＳ−ＧＷ ５２０ｂ、ソースＰ−ＧＷ ５３１、ターゲットＰ−ＧＷ ５３２を含んでいる。ソース基地局３００ａ及びターゲット基地局３００ｂはｅＮｏｄｅＢ或いはＨｏｍｅ （ｅ）ＮｏｄｅＢであってよい。

図５に示す基地局３００ａ，３００ｂ（以下、３００と総称する）、ＭＭＥ５１０ａ，５１０ｂ（以下、５１０と総称する）、Ｓ−ＧＷ５２０ａ，５２０ｂ（以下、５２０と総称する）、Ｐ−ＧＷ５３１，５３２（以下、５３０と総称する）は、ＥＰＳに基づくものである。

ローカルゲートウェイ４００ａ，４００ｂ（以下、４００と総称する）は、基地局３００と有線網７００との間に位置して、基地局３００を通るＳＩＰＴＯを可能にするためのゲートウェイである。ローカルゲートウェイ４００は、基地局３００と有線網７００との間の経路を通じてセッションを生成できるようにし、該生成されたベアラを通じてデータ伝送を可能にさせる。

このようなローカルゲートウェイ４００は、ＥＰＳのためのＰＤＮ−ＧＷの機能の一部或いは全部を含むこともあり、ＵＭＴＳのためのＧＧＳＮ（Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）の機能の一部或いは全部を含むこともある。しかし、このローカルゲートウェイ４００は、基地局３００と有線網７００間の経路を通じてベアラを生成できるようにするもので、移動通信ネットワーク６００への経路を通じてベアラを生成するＥＰＳのＰ−ＧＷ ５２０或いはＵＭＴＳのＧＧＳＮと区別されるから、ＥＰＳではローカルＰ−ＧＷと呼ばれてもよく、ＵＭＴＳではローカルＧＧＳＮと呼ばれてもよい。

一方、図５に示したシステムはＥＰＳに基づくものであるが、図５に示したＳＩＰＴＯは、３ＧＰＰ ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）にも適用可能である。３ＧＰＰ ＵＭＴＳでは、ＭＭＥ ５１０の制御プレーンの機能とＳ−ＧＷ ５２０のユーザープレーン機能が両方ともＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）（図示せず）で行われてもよい。

図５を参照して動作を説明すると、下記の通りである。

ＵＥ１００がサービス要請をすると、コアネットワーク内の制御エンティティであるＳＧＳＮやＭＭＥは、ＵＥ１００の要請されるサービスのデータを有線網７００に迂回させ得るか否かを判断する。この時、公衆網のような有線網７００を通るとしても、提供される接続ポイントは、移動通信ネットワーク６００におけると同一であればよい。すなわち、接続ポイントの名前を表すＡＰＮ（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ）は同一に使われ、各ＡＰＮにＳＩＰＴＯ許可を別途に指定すればよい。

このようにＵＥ１００が接続を試みる時、コアネットワーク内のエンティティに特定のＡＰＮを提供し、ＵＥ１００の接続を公衆網のような有線網７００のノードに迂回（ｏｆｆｌｏａｄ）させるか否かは、コアネットワーク内のエンティティ、例えば、ＥＰＳのＭＭＥ ５１０或いはＵＭＴＳのＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）が判断するとよい。この時、コアネットワーク内の制御エンティティ、例えばＭＭＥ ５１０は、ＵＥ１００の接続した基地局が（ｅ）ＮｏｄｅＢであるか或いはＨｏｍｅ （ｅ）ＮｏｄｅＢであるかと、該基地局がＳＩＰＴＯを支援するか否かと、を考慮して、当該要請されるサービスによるデータを、公衆網のような有線網７００に迂回させるか否かを決定すればよい。

上記データを迂回させると決定すれば、該サービスのデータのためのセッションを、有線網７００を経由して迂回するように設定する。言い換えれば、ＵＥ１００と送受信されるデータのためのセッションは、ソース基地局３００ａ、例えばＨｏｍｅ （ｅ）ＮｏｄｅＢとの無線区間と、ソースローカルゲートウェイ（すなわち、ローカル−ＧＧＳＮ又はローカルＰ−ＧＷ）４００ａとの有線網ベースのセッションであるか否かを判断するために、ソースＭＭＥ ５１０ａは、当該ＵＥコンテクスト内のパラメータ、例えばＳＩＰＴＯ＿Ｓｅｓｓｉｏｎ＿ｉｎｄｉｃａｔｏｒを確認すればよい。

上記進行中のセッションのために移動性を提供する場合、既存のモビリティ手順（Ｍｏｂｉｌｉｔｙ ｐｒｏｃｅｄｕｒｅ）に従うが、ソースＭＭＥ ５１０ａは、適切なターゲットＭＭＥ ５１０ｂを決定し、決定されたターゲットＭＭＥ ５１０ｂにＵＥコンテクストを伝達する。このとき、上記進行中のセッションがＳＩＰＴＯベースのセッションであるか否かを表すパラメータ、例えばＳＩＰＴＯ＿Ｓｅｓｓｉｏｎ＿ｉｎｄｉｃａｔｏｒを含めて伝送してもよく、ＵＥコンテクストに基づいて、加入者情報サーバーであるＨＳＳに問い合わせてＳＩＰＴＯ＿Ｓｅｓｓｉｏｎ＿ｉｎｄｉｃａｔｏｒを受け取ってもよい。

すると、ターゲットＭＭＥ ５１０ｂは、ターゲット基地局３００ｂでＳＩＰＴＯを支援するか否か、事業者政策、ＱｏＳなどを考慮して、ＳＩＰＴＯベースのセッションを維持させるか否かを決定するとよい。

また、ＵＥ １００がターゲット基地局３００ｂのカバレッジ内に移動する場合は、該ＵＥ １００のデータが経由するローカルＰ−ＧＷ或いはローカルＧＧＳＮが変更される必要があることもある。このような場合、無線接続（Ｒａｄｉｏ Ａｃｃｅｓｓ）の能力、セッションで要求されるＱｏＳ、移動性（Ｍｏｂｉｌｉｔｙ）などが考慮されなければならない。

もしローカルＰ−ＧＷ或いはローカルＧＧＳＮを変更すべきであれば、ソースＭＭＥ ５１０ａ又はＳＧＳＮは、このような理由をＵＥ １００に伝達し、ＵＥ １００が現在のセッションを切って（終了して）から、新しいセッションを要請するように誘導すればよい。この誘導は、ソース基地局のためのソースＭＭＥ又はＳＧＳＮ、或いはターゲット基地局のためのターゲットＭＭＥ／ＳＧＳＮによってなされるとよい。

以上では、Ｈｏｍｅ （ｅ）ＮｏｄｅＢを通してＳＩＰＴＯサービスを提供するための、本明細書で提示されるアーキテクチャーについて説明した。

以下では、図面を参照して、Ｈｏｍｅ （ｅ）ＮｏｄｅＢを通してＳＩＰＴＯサービスを提供するための基本的な手順について説明する。

図６は、Ｈｏｍｅ （ｅ）ＮｏｄｅＢを通してＳＩＰＴＯサービスを提供するための基本的な手順を示す例示図である。

図６を参照して説明するに先立ち、ＵＥ １００及びコアネットワーク内のエンティティは、多重（Ｍｕｌｔｉｐｌｅ）ＰＤＮ機能を支援し、ＬＩＰＡを支援し、及びマクロ基地局、（ｅ）ＮｏｄｅＢを通るＳＩＰＴＯも支援すると仮定する。

図示のＵＥ １００は、マクロ基地局、すなわち、（ｅ）ＮｏｄｅＢ ２００に接続した場合には、マクロＳＩＰＴＯ、すなわちコアネットワーク（ｃｏｒｅ ｎｅｔｗｏｒｋ）内のＰ−ＧＷ ５３０を通じてトラフィックが外部ネットワークへと経由され、以降、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００に移動した場合は、フェムトＳＩＰＴＯ、すなわちローカルネットワークを通じてトラフィックが外部ネットワークへと経由されるとよい。

このように、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００に移動したとき、フェムトＳＩＰＴＯ、すなわちローカルネットワークを通じてトラフィックが外部ネットワークに経由されることについて、ユーザーに受諾又は同意を問うのが好ましいことがある。

したがって、ＭＭＥ ５１０は、ユーザーの受諾又は同意に応じて、フェムトＳＩＰＴＯのために、ＰＤＮ経路を再設定するか否か決定してもよい。また、再設定されたＰＤＮの使用目的、すなわち、ＬＩＰＡのためのもの（例、ホームネットワークデータ）か、ＳＩＰＴＯのためのもの（例、インターネットデータ）か、又はＳＩＰＴＯ及びＬＩＰＡの両方のためのものかについて確認する必要がある。

その具体的な手順を図６を参照して説明すると、下記の通りである。

０）まず、ＵＥ １００はマクロ基地局、すなわち（ｅ）ＮｏｄｅＢ ２００に接続しており、ＵＥのデータにはマクロＳＩＰＴＯが適用される。すなわち、該ＵＥのデータはコアネットワーク内のＰ−ＧＷ ５３０を通じてトラフィックが外部ネットワークに伝達される。

１）以降、ＵＥ １００はＴＡＵ／ＲＡＵ手順又はハンドオーバー手順によってＨｏｍｅ （ｅ）ＮｏｄｅＢ ３００へと接続を試みる。

２）この時、ＭＭＥ ５１０は、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００のタイプ（すなわち、閉鎖接続モードで動作するか、開放接続モードで動作するか、或いは混合接続モードで動作するか）、Ｌ−ＧＷのアドレス、ＳＩＰＴＯ／ＬＩＰＡの許容されるか否か、を考慮して、ＳＩＰＴＯフェムトを適用させるか否かを決定する。もし、ＳＩＰＴＯフェムトを適用させないと決定する場合には、ゲートウェイ選択過程を行う。

ＳＩＰＴＯフェムトを適用させるか否かの決定について詳細に説明すると、下記の通りである。

まず、ＵＥ １００はＨｏｍｅ （ｅ）ＮｏｄｅＢ ３００に接続した場合であるから、本発明ではＬＩＰＡやＳＩＰＴＯが可能であるか判断し、ＳＩＰＴＯが可能であれば、ＳＩＰＴＯフェムトが可能であるか否かをさらに判断すればよい。

まず、ＭＭＥ ５１０は、ＬＩＰＡやＳＩＰＴＯが可能であるか否か（能力情報）を、伝達されたＬ−ＧＷアドレスから分かる。さらに、ＭＭＥ ５１０は、Ｈｏｍｅ （ｅ）ＮｏｄｅＢのタイプを考慮して可能であるか否かを判断することもできるが、これを考慮して混合（Ｈｙｂｒｉｄ）モードで動作する場合にもＬＩＰＡやＳＩＰＴＯを支援することができる。

次に、ＳＩＰＴＯフェムトが可能か否かは、下記３つの方法で判断するとよい。第一は、ＳＩＰＴＯが許容されるか否かを表す因子（又はインジケータ）（例えば、ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎ）とＬＩＰＡを許容するか否かを表す因子（又はインジケータ）（例えば、ＬＩＰＡ ｐｅｒｍｉｓｓｉｏｎ）を用いる方法で、これら２つの因子から、
ＳＩＰＴＯが許容されながらＬＩＰＡも許容されると確認される場合に、ＵＥ １００の接続したＨｏｍｅ （ｅ）ＮｏｄｅＢ ３００にＬ−ＧＷが存在し、それによりＳＩＰＴＯフェムトが許容されるものと決定すればよい。第二は、ＳＩＰＴＯフェムトが許容されることを示す専用の因子又はインジケータ、すなわち、ＳＩＰＴＯ ｆｅｍｔｏ ｐｅｒｍｉｓｓｉｏｎ因子を用いる方法である。第三は、ＳＩＰＴＯが許容されるか否かを表す因子（又はインジケータ）（例えば、ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎ）の属性値としてＡｌｌｏｗｅｄ、Ｐｒｏｈｉｂｉｔｅｄ、ＳＩＰＴＯ ｆｅｍｔｏ ａｌｌｏｗｅｄを用いる方法である。

第一の方法について詳細に説明すると、下記の通りである。

ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎとＬＩＰＡ ｐｅｒｍｉｓｓｉｏｎは次のような値を有する。

−．ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎ：Ａｌｌｏｗｅｄ、Ｐｒｏｈｉｂｉｔｅｄ

−．ＬＩＰＡ ｐｅｒｍｉｓｓｉｏｎ：ＬＩＰＡ−ｐｒｏｈｉｂｉｔｅｄ、ＬＩＰＡ−ｏｎｌｙ ａｎｄ ＬＩＰＡ−ｃｏｎｄｉｔｉｏｎａｌ

したがって、上記のＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎとＬＩＰＡ ｐｅｒｍｉｓｓｉｏｎとを組み合わせることで、ＳＩＰＴＯフェムトが許容されるかも判断することができる。

すなわち、２因子が有し得る値を組み合わせると合計６個の組み合わせが出るが、その一部をＳＩＰＴＯ ｆｅｍｔｏ許容と定めるとよい。

一方、このようにＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎとＬＩＰＡ ｐｅｒｍｉｓｓｉｏｎとを組み合わせて、ＳＩＰＴＯフェムトが許容されるか否かを判断するようにすると、新しい因子を追加しなくて済むという利点があるが、各ＰＤＮ別に適用するには困難がある。

そこで、第二の方法について説明すると、次の通りである。

もし使用目的別にＰＤＮを区別しておくとすれば、ＩＭＳなどの事業者ＰＤＮ、企業ＰＤＮ、ホームネットワークＰＤＮ、インターネットＰＤＮなどに区別可能である。このとき、上記の第一方法のように、ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎとＬＩＰＡ ｐｅｒｍｉｓｓｉｏｎとを組み合わせて、ＳＩＰＴＯフェムトの許容されるか否かを判断するとすれば、企業ＰＤＮでは一般ＳＩＰＴＯを許容し、保安などの諸理由からＳＩＰＴＯフェムトは許容しないように設定することが困難である。

そのため、表１のようにＳＩＰＴＯ ｆｅｍｔｏ ｐｅｒｍｉｓｓｉｏｎを別に使用することが好ましいことがある。

上記表１のように、ＳＩＰＴＯフェムトが許容されるか否かを表す専用の因子、すなわち、ＳＩＰＴＯ ｆｅｍｔｏ ｐｅｒｍｉｓｓｉｏｎを使用するようになると、各ＰＤＮ別に、一般ＳＩＰＴＯ許容の有無とＳＩＰＴＯフェムト許容の有無を異なるように設定することができる。上記表１で、ＳＩＰＴＯマクロのみ可能な場合と、ＳＩＰＴＯマクロ及びＳＩＰＴＯフェムトの両方が許容される場合は、インターネットＰＤＮとなっている。また、上記表１で、ＳＩＰＴＯマクロのみ可能な場合は、事業者ＰＤＮとなっている。

一方、第三の方法について説明すると、ＳＩＰＴＯが許容されるか否かを表す因子（又はインジケータ）（例えば、ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎ）の属性値としてＡｌｌｏｗｅｄ、Ｐｒｏｈｉｂｉｔｅｄ、ＳＩＰＴＯ ｆｅｍｔｏ ａｌｌｏｗｅｄを使用する。

上記表２のように、第三の方法は、ＳＩＰＴＯフェムトが許容されるか否かを表す専用の因子、すなわちＳＩＰＴＯ ｆｅｍｔｏ ｐｅｒｍｉｓｓｉｏｎを追加せずに、ＳＩＰＴＯ許容の有無を表す因子（又はインジケータ）（例えば、ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎ）の属性値として、Ａｌｌｏｗｅｄ、Ｐｒｏｈｉｂｉｔｅｄ、ＳＩＰＴＯ ｆｅｍｔｏ ａｌｌｏｗｅｄを使用する。

３）再び図６を参照して説明すると、もし、フェムトＳＩＰＴＯを適用すると決定されると、ＭＭＥ ５１０は、ユーザーのトラフィックをローカルネットワーク経由で伝送することをユーザーが受諾又は同意するかどうか問う。

具体的に、ＭＭＥ ５１０は、ユーザーのトラフィックをローカルネットワークを経由させて伝送することをユーザーが受諾又は同意するかを問うために、情報要請メッセージ、例えば、ＥＳＭ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅを、ＵＥ １００に伝送する。この情報要請メッセージ、例えば、ＥＳＭ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅは、ＳＩＰＴＯフェムトの受諾又は同意を要請する指示子、例えば、Ｒｅｑｕｅｓｔ ｆｏｒ ａｌｌｏｗａｎｃｅ ｆｏｒ ＳＩＰＴＯ ｆｅｍｔｏを含めばよい。このようにユーザーの受諾又は同意を問う理由は、ユーザーのトラフィックをローカルネットワークに迂回させて伝送すると、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）が保障されないことがあるためである。

ＵＥ １００は、情報応答メッセージ、例えばＥＳＭ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｐｌｙ ｍｅｓｓａｇｅを伝送する。この情報応答メッセージ、例えばＥＳＭ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｐｌｙ ｍｅｓｓａｇｅ内には、受諾又は同意についてユーザーから入力された応答が含まれてもよく、又は、あらかじめ保存された受諾又は同意についての応答が含まれてもよい。

一方、ＭＭＥ ５１０がＵＥ １００に問う過程は省略されてもよい。例えば、ユーザーの受諾又は同意についての応答は、あらかじめ加入者情報サーバー、例えばＨＳＳに保存さていてもよい。これは、事業者やサーバー管理者が事前にユーザーに受諾又は同意について尋ね、その結果を加入者情報に保存しておく方法である。これは、端末に尋ねることなくユーザーの受諾又は同意の結果を記録する方法で、端末とのインタラクション（ｉｎｔｅｒａｃｔｉｏｎ）無しで記録しておく方法である。もしユーザーの意向が変わると、意向が変わる時点に上記ＨＳＳに変更事項を保存すればよい。

このようにＭＭＥ ５１０がＵＥ １００に意向を問う過程が省略されるに代え、ＭＭＥ ５１０がユーザーの受諾又は同意の有無に関する情報をＨＳＳから獲得する過程が追加されるとよい。この獲得過程は、ＭＭＥ ５１０とＨＳＳ間のプロトコルに基づくメッセージ、例えばＩｎｓｅｒｔ Ｓｕｂｓｃｒｉｂｅｒ Ｄａｔａ ｐｒｏｃｅｄｕｒｅを用いて行えばよい。

４）即座のユーザーの応答によって又はあらかじめ設定されたユーザーの応答によってＵＥ １００が許容の有無に関する情報（例えば、ＥＳＭ ｉｎｆｏｒｍａｔｉｏｎ）を伝送すると、ＭＭＥ ５１０は、この許容の有無に関する情報に基づいて、フェムトＳＩＰＴＯ機能を活性化するか否かを決定する。すなわち、ユーザーの応答が拒絶であれば、ＭＭＥ ５１０は、前述のように、ゲートウェイ選択過程を行う。

５）しかし、ユーザーの応答が受諾又は同意であれば、ＭＭＥ ５１０は、（ｅ）ＮｏｄｅＢを経由して活性化されているＰＤＮコネクションを非活性化する。

６）一方、ＵＥ １００は、同一のＰＤＮを用いて新しいＰＤＮコネクションの設定を要請する。

７）ＭＭＥ ５１０は、Ｈｏｍｅ （ｅ）ＮｏｄｅＢを経由する新しいＰＤＮコネクションを活性化するために、Ｌ−ＧＷ ４００に要請する。

８）ＭＭＥ ５１０は、上記新しいＰＤＮコネクションが生成されると、ＰＤＮコネクション受諾又は同意をＵＥ １００に知らせ、この時、ＳＩＰＴＯ及びＬＩＰＡのいずれか一つ以上が可能であることをＵＥ １００に通知する。このような通知は、ＵＥ １００が将来ＬＩＰＡを要請できるようにする。ＵＥ １００は当該通知を受けることによって、生成されたＰＤＮが、ＬＩＰＡ用か、ＳＩＰＴＯ用か、又は両方を支援するかを区別し、これに基づいて、各ＩＰパケットが伝送されるべき経路を選択することができる。

すなわち、端末はＨｏｍｅ （ｅ）ＮｏｄｅＢ接続状態は分かるが、Ｌ−ＧＷの支援状態、すなわち、生成されたＰＤＮでＳＩＰＴＯ ｆｅｍｔｏやＬＩＰＡを支援するか否かは分からない。そのため、それぞれの支援の有無を知るにはさらなる通知が必要である。

このようにＳＩＰＴＯ ｆｅｍｔｏやＬＩＰＡの支援の有無を端末に知らせる通知方法には、２種類のものが挙げられる。

第一は、ＳＩＰＴＯ ｆｅｍｔｏの支援を知らせる通知と、ＬＩＰＡの支援を知らせる通知を別々に用いる方法であり、第二は、一つの通知を用いて、ＳＩＰＴＯ ｆｅｍｔｏを支援するかと、ＬＩＰＡを支援するかを知らせる方法である。

まず、第一の方法について説明すると、下記の通りである。

ＬＩＰＡ支援可能を知らせる通知のみがＭＭＥ ５１０から伝達されると、ＵＥ １００はＬＩＰＡ ＰＤＮであることが分かり、関連したホームネットワークなどのローカルＩＰアクセスに関連したデータのみを伝送する。一方、ＳＩＰＴＯ支援可能を知らせる通知のみがＭＭＥ ５１０から伝達されると、ＵＥ １００は、ＳＩＰＴＯ用ＰＤＮであることがわかる。この時、ＵＥ １００はＬＩＰＡ許容に対する通知を受けなかったため、ローカルネットワークに向かうデータは伝送されてはならない。すなわち、ＳＩＰＴＯ支援可能を知らせる通知のみをＵＥ １００に伝達することは、目的に応じて伝送制御をして、インターネットのような外部ネットワークに向かうデータのみを許容する時に用いられてよい。一方、ＬＩＰＡ支援可能を知らせる通知とＳＩＰＴＯ支援可能を知らせる通知の両方がＭＭＥ ５１０からＵＥ １００に伝達されてもよい。

第二の方法について説明すると、ＭＭＥ ５１０は、ＬＩＰＡ支援可能を知らせる通知をＵＥ １００に伝達する。このように、ＬＩＰＡ支援可能を知らせる通知のみを受けると、ＵＥ １００は、生成されたＰＤＮがＬＩＰＡ用か、ＳＩＰＴＯ用かを判断し、ＳＩＰＴＯ用であれば、当該通知の内容をＳＩＰＴＯが支援されることを表すものと解釈する。逆に、生成されたＰＤＮがＬＩＰＡ用であれば、当該通知の内容をＬＩＰＡが支援されることを表すものと解釈する。

一方、上記２種類の通知方法を、前述したＳＩＰＴＯ許容の有無を表す因子（又はインジケータ）（例えばＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎ）と、ＬＩＰＡ許容の有無を表す因子（又はインジケータ）によってまとめると、下記の通りである。

まず、Ｈｏｍｅ （ｅ）ＮｏｄｅＢがＬ−ＧＷを支援する場合に、ＳＩＰＴＯ許容の有無を表す因子（又はインジケータ）（例えばＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎ）とＬＩＰＡ許容の有無を表す因子（又はインジケータ）との組み合わせによって、ＳＩＰＴＯ ｆｅｍｔｏの支援を知らせる通知と、ＬＩＰＡの支援を知らせる通知を別々に独立して用いることをまとめると、下記表３の通りである。

次に、Ｈｏｍｅ （ｅ）ＮｏｄｅＢがＬ−ＧＷを支援しない場合に、ＳＩＰＴＯ許容の有無を表す因子（又はインジケータ）（例えばＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎ）と、ＬＩＰＡ許容の有無を表す因子（又はインジケータ）との組み合わせによって、ＳＩＰＴＯ ｆｅｍｔｏの支援を知らせる通知と、ＬＩＰＡの支援を知らせる通知を別々に独立して使用することをまとめると、下記表４の通りである。

まず、ＬＩＰＡの場合、ＬＩＰＡ−ｃｏｎｄｉｔｉｏｎａｌであればＰＤＮは生成されてよい。しかし、Ｌ−ＧＷ支援の有無によって、ＬＩＰＡ用である場合もあり、コアネットワークに伝送される経路である場合もある。したがって、Ｌ−ＧＷが支援される場合に、ＬＩＰＡ ＰＤＮであることを表す通知（ｎｏｔｉｆｉｃａｔｉｏｎ）が必要である。ＳＩＰＴＯの場合も、ＭＭＥ ５１０が要請をして生成したＰＤＮであるから、ＳＩＰＴＯが許容されるかを通知すればよい。この時、その応用によって、ＳＩＰＴＯ ｍａｃｒｏとＳＩＰＴＯ ｆｅｍｔｏのいずれが許容されるかについて通知を区別する必要がある。

また、一つのＰＤＮが両者とも支援する場合もあり、許容しない場合もあるが、この場合にも上記の組み合わせによって決定すればよい。

要するに、ＬＩＰＡ ｎｏｔｉｆｉｃａｔｉｏｎとＳＩＰＴＯ要請時又はＳＩＰＴＯＰＤＮ設定完了時（ｆｅｍｔｏやｍａｃｒｏの場合）におけるｉｎｄｉｃａｔｏｒ／ｃａｕｓｅ ｖａｌｕｅを用いて通知を提供すればよい。

一方、Ｈｏｍｅ （ｅ）ＮｏｄｅＢがＬ−ＧＷを支援する場合に、ＳＩＰＴＯフェムトが許容されることを表す専用の因子又はインジケータ、すなわち、ＳＩＰＴＯ ｆｅｍｔｏ ｐｅｒｍｉｓｓｉｏｎ因子を用いるとき、ＳＩＰＴＯ ｆｅｍｔｏの支援を知らせる通知と、ＬＩＰＡの支援を知らせる通知を別々に独立して用いることをまとめると、下記表５の通りである。

一方、Ｈｏｍｅ （ｅ）ＮｏｄｅＢがＬ−ＧＷを支援しない場合に、ＳＩＰＴＯフェムトが許容されることを表す専用の因子又はインジケータ、すなわち、ＳＩＰＴＯ ｆｅｍｔｏ ｐｅｒｍｉｓｓｉｏｎ因子を使用するとき、ＳＩＰＴＯ ｆｅｍｔｏの支援を知らせる通知と、ＬＩＰＡの支援を知らせる通知を別々に独立して用いることをまとめると、下記表６の通りである。

上記表５を参照すると、Ｌ−ＧＷを支援する場合に、ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎによらずに表３と同一に動作する。Ｌ−ＧＷを支援しない場合には、ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎによってＳＩＰＴＯ ｍａｃｒｏのみ生成される。したがって、表６は表４と異なってはいるが、つまるところ、ＬＩＰＡ ｎｏｔｉｆｉｃａｔｉｏｎとＳＩＰＴＯ要請時又はＳＩＰＴＯ ＰＤＮ設定完了時（ｆｅｍｔｏやｍａｃｒｏの場合）におけるｉｎｄｉｃａｔｏｒ／ｃａｕｓｅ ｖａｌｕｅを用いて通知を提供することができる。

以上では、図６を参照して、手順を中心に説明してきた。以下では、各手順を行う時、要求される情報を中心に説明する。

１．加入者情報

前述したＨＳＳやＨＬＲに記録される情報である。

ＨＳＳやＨＬＲに記録された上記加入者情報は、ＭＭＥ ５１０に伝達される。この加入者情報に含まれるべき情報は、下記表７のように、ＣＳＧ加入者情報、訪問ネットワークでＬＩＰＡ許容の有無、各ＰＤＮ別ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎ、ＬＩＰＡ許可の有無（ＬＩＰＡ ｐｅｒｍｉｓｓｉｏｎ）、ＳＩＰＴＯ ｆｅｍｔｏ ｐｅｒｍｉｓｓｉｏｎ、ユーザー許与の有無である。

上記表７を参照すると、前述したように、ＬＩＰＡが許容されなくても、ＳＩＰＴＯは許容されることがあるので、ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎとＬＩＰＡ許可の有無（ＬＩＰＡ ｐｅｒｍｉｓｓｉｏｎ）は別個に用いられるとよい。また、追加的にＳＩＰＴＯ ｆｅｍｔｏ ｐｅｒｍｉｓｓｉｏｎが用いられるとよい。或いは、ＳＩＰＴＯ ｆｅｍｔｏ ｐｅｒｍｉｓｓｉｏｎ無しに、ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎの属性値として、ＳＩＰＴＯ ｆｅｍｔｏ ａｌｌｏｗｅｄが追加されてもよい。

一方、上記加入者情報内にユーザーの受諾又は同意の有無に関する情報が含まれていると、ＭＭＥ ５１０は、ＵＥ １００に尋ねることなく、ＨＳＳからの情報に基づいてユーザーの同意を判断すればいいので、より迅速な処理が可能となる。

２．Ｈｏｍｅ （ｅ）ＮｏｄｅＢの能力（ｃａｐａｂｉｌｉｔｙ）

Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００がＬＩＰＡ及びＳＩＰＴＯを支援するか否かに関する能力情報をＭＭＥ ５１０に提供しなければならない。このとき、ＬＩＰＡ及びＳＩＰＴＯを支援するにはＬ−ＧＷが必要である。

ここで、Ｌ−ＧＷは、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００内に含まれたものであってもよく、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００と物理的に独立したものであってもよい。

まず、Ｌ−ＧＷがＨｏｍｅ （ｅ）ＮｏｄｅＢ ３００内に含まれて運用される場合に、ＳＩＰＴＯを支援するか否かに関する能力情報は、Ｌ−ＧＷのアドレスを伝達することによって知らせられるとよい。この時、ＬＩＰＡとＳＩＰＴＯの機能のそれぞれを支援するかを区別したい場合には、ＳＩＰＴＯ ｃａｐａｂｉｌｉｔｙ ｉｎｄｉｃａｔｏｒやＬＩＰＡ ｃａｐａｂｉｌｉｔｙ ｉｎｄｉｃａｔｏｒを併せて伝達する。これは、ＭＭＥでそれぞれの機能を区別して処理しようとする時に必要な付加情報である。

次に、Ｌ−ＧＷがＨｏｍｅ （ｅ）ＮｏｄｅＢ ３００と物理的に独立している場合に、Ｈｏｍｅ （ｅ）ＮｏｄｅＢはＬ−ＧＷアドレスを知らず、よって、アドレス形態のみでは伝送することができない。ただし、ＯｐｅｒａｔｏｒやＨｏｍｅ （ｅ）ＮｏｄｅＢ所有主の設定により各ＳＩＰＴＯ ｃａｐａｂｉｌｉｔｙやＬＩＰＡ ｃａｐａｂｉｌｉｔｙを伝達することができる。すなわち、Ｌ−ＧＷのアドレスやＦＱＤＮ形式の名前又は別途のｉｎｄｉｃａｔｏｒなどで伝達すると、ＭＭＥにその支援有無を知らせることができる。又は、ＭＭＥが位置情報などを用いて直接Ｌ−ＧＷを検索し、その支援有無を確認してもよい。

上記２つの場合とも共通的にＨｏｍｅ （ｅ）ＮｏｄｅＢのタイプを考慮して可能の有無を判断できるが、これを考慮して混合（Ｈｙｂｒｉｄ）モードで動作する場合には、ＣＳＧ加入のない場合もＬＩＰＡやＳＩＰＴＯを支援することができる。

３．ＬＩＰＡ ｎｏｔｉｆｉｃａｔｉｏｎ

３ＧＰＰ ＳＡ１標準仕様に定義された要求事項によれば、Ｈｏｍｅ （ｅ）ＮｏｄｅＢは、ホーム／会社ネットワークのＩＰネットワークに接続を提供することをＵＥに知らせることができるようになっている。これは、ＵＥがネットワークにアタッチ（Ａｔｔａｃｈ）する前や完了後に伝達されればよい。

アタッチ（Ａｔｔａｃｈ）前の場合は、放送（Ｂｒｏａｄｃａｓｔｉｎｇ）で知らせられる場合であり、この場合、ＵＥ １００はＳＩＰＴＯ ａｃｃｅｐｔａｎｃｅやｄｅｃｌｉｎｅ情報を伝達すればよい。このようなＵＥの情報は事前に保存されたものでよい。又は放送（Ｂｒｏａｄｃａｓｔｉｎｇ）情報に基づいてユーザーに尋ねて許可を受けると、その情報を伝送してもよい。

アタッチ（Ａｔｔａｃｈ）完了時には、ＮＡＳやＡＳメッセージで伝達すればよく、ＵＥ １００は、当該情報に応じて追加的にＳＩＰＴＯ ａｃｃｅｐｔａｎｃｅやｄｅｃｌｉｎｅ情報を伝達する。又は、ＵＥは、当該情報とｃｏｎｔｅｘｔ情報のｐｅｒｍｉｓｓｉｏｎ情報に基づいて生成されたＰＤＮがローカルネットワークと設定されたことが分かる。

図７は、本発明のＳＩＰＴＯサービスのための制御手順を簡略に示すフローチャートである。図８は、図７に示した制御手順を詳細に示すフローチャートである。図９は、図８に示したメッセージのプロトコルを例示する図である。

図７及び図８を参照して各手順を具体的に説明するに先立って、図示のメッセージについて図９を参照して簡略に説明する。

ＵＥ １００と基地局、例えば（ｅ）ＮｏｄｅＢ ２００又はＨｏｍｅ （ｅ）ＮｏｄｅＢ ３００間に送受信されるメッセージはＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）プロトコルに基づくメッセージである。基地局、例えば（ｅ）ＮｏｄｅＢ ２００又はＨｏｍｅ （ｅ）ＮｏｄｅＢ ３００とＭＭＥ ５１０又はＳＧＳＮ（図示せず）間に送受信されるメッセージはＳ１−ＡＰ（Ｓ１ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）に基づくメッセージである。

ＵＥ １００とＭＭＥ ５１０又はＳＧＳＮ（図示せず）間に送受信されるメッセージはＮＡＳ（Ｎｏｎ-Ａｃｃｅｓｓ ｓｔｒａｔｕｍ）プロトコルに基づくメッセージである。ＮＡＳプロトコルに基づくメッセージは、ＲＲＣプロトコルに基づくメッセージとＳ１−ＡＰメッセージにそれぞれカプセル化して伝送される。

また、図７及び図８に示す制御手順を説明するに先立ち、図示のメッセージ内のパラメータについて簡略に説明する。

ＳＩＰＴＯ ａｃｃｅｐｔａｎｃｅ：ＳＩＰＴＯサービスの受諾又は同意又は拒絶を表す。

Ｌ−ＧＷ ａｄｄｒｅｓｓ：ローカルゲートウェイのアドレスで、Ｈｏｍｅ （ｅ）ＮｏｄｅＢがＳＩＰＴＯサービスを提供できるか否か（ＳＩＰＴＯ ｃａｐａｂｉｌｉｔｙ）も表す。すなわち、Ｈｏｍｅ （ｅ）ＮｏｄｅＢが伝送するメッセージ内にローカルゲートウェイのアドレスが含まれていると、Ｈｏｍｅ （ｅ）ＮｏｄｅＢがＳＩＰＴＯサービスを提供できるということを意味する。

ＳＩＰＴＯ ｃａｐａｂｉｌｉｔｙ ｉｎｄｉｃａｔｏｒ：ＳＩＰＴＯ機能指示子で、ＳＩＰＴＯサービスを提供できるか否かを表す。

ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎ：ＳＩＰＴＯサービスの許可権で、ＳＩＰＴＯサービスが許与されるか否かを表す。

ＬＩＰＡ許可の有無（ＬＩＰＡ ｐｅｒｍｉｓｓｉｏｎ）：ＬＩＰＡサービスの許可権で、ＬＩＰＡサービスが許与されるか否かを表す。

ＳＩＰＴＯ ｆｅｍｔｏ ｐｅｒｍｉｓｓｉｏｎ：Ｈｏｍｅ （ｅ）ＮｏｄｅＢを通るＳＩＰＴＯサービスの許可権で、Ｈｏｍｅ （ｅ）ＮｏｄｅＢを通るＳＩＰＴＯサービスが許与されるか否かを表す。

Ｕｓｅｒ Ａｌｌｏｗａｎｃｅ：ユーザーがＨｏｍｅ （ｅ）ＮｏｄｅＢを通るＳＩＰＴＯサービスの利用を受諾又は同意するか否かを表す。

ＬＩＰＡ ｎｏｔｉｆｉｃａｔｉｏｎ：ＬＩＰＡサービスに関する通知（ｎｏｔｉｆｉｃａｔｉｏｎ）で、ＬＩＰＡサービスが許容されるか否かを表す。

Ｐａｃｋｅｔ ｆｉｌｔｅｒ：ＭＭＥ ５１０からＨｏｍｅ （ｅ）ＮｏｄｅＢやローカルゲートウェイに伝達される情報で、Ｈｏｍｅ （ｅ）ＮｏｄｅＢやローカル−ゲートウェイ（Ｌ−ＧＷ）が、ＵＥ １００のトラフィックが小規模のネットワーク、例えばホームネットワーク又は会社ネットワークへ向かう時、遮断したり通過させるフィルタである。

以下では、図７及び図８を参照してＳＩＰＴＯサービスの制御手順についてより詳細に説明する。

０）まず、図７を参照すると、ＭＭＥ ５１０は、図示のＨＳＳ ５４０からＵＥ １００の加入者情報を獲得する。ＵＥ １００の加入者情報は、各ＰＤＮ別に異なるように設定されていてもよい。各ＰＤＮ単位に設定された加入者情報は、前述したＳＩＰＴＯ許可権（ＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎ）に関する情報、ＬＩＰＡ許可権（ＬＩＰＡ許可の有無（ＬＩＰＡ ｐｅｒｍｉｓｓｉｏｎ））に関する情報、ＳＩＰＴＯフェムト許可権（ＳＩＰＴＯ ｆｅｍｔｏ ｐｅｒｍｉｓｓｉｏｎ）、ＵＥ １００のユーザーがＳＩＰＴＯフェムトサービスを受諾又は同意したか否かに関するＳＩＰＴＯ受諾又は同意情報のうち一つ以上を含むとよい。

１）次に、図７を参照すると、ＵＥ １００は、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００に接続するために、アタッチ手順、ＴＡＵ手順、又はハンドオーバー手順を行う。

１−１）具体的に、図８を参照すると、ＵＥ １００はアイドル（ＩＤＬＥ）モードであり、ＴＡＵ（Ｔｒａｃｋｉｎｇ Ａｒｅａ Ｕｐｄａｔｅ）を要請するために、領域更新要請メッセージ（例えばＴＡＵ Ｒｅｑｕｅｓｔメッセージ）を生成する。このメッセージは、ＵＥ １００に提供される接続ポイントの名前を表すＡＰＮを含むとよい。そして、ＵＥ １００は、上記領域更新要請メッセージ、すなわちＴＡＵ Ｒｅｑｕｅｓｔメッセージを、ＲＲＣプロトコルに基づくメッセージにカプセル化（ｅｎｃａｐｓｕｌａｔｉｏｎ）し、該カプセル化したメッセージを（ｅ）ＮｏｄｅＢ ２００又はＨｏｍｅ （ｅ）ＮｏｄｅＢ ３００に伝送する。上記アタッチ要請メッセージは、ＵＥ １００のユーザーがＳＩＰＴＯサービスを受諾又は同意したか否かに関するＳＩＰＴＯ受諾又は同意情報（例えば、図示のＳＩＰＴＯ ａｃｃｅｐｔａｎｃｅ）を含むことができる。

１−２）Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００はＵＥ １００からＲＲＣメッセージを受信すると、該ＲＲＣメッセージ内に含まれた領域更新要請メッセージ、すなわち、ＴＡＵ Ｒｅｑｕｅｓｔメッセージを抽出する。そして、該抽出されたメッセージと共に、ローカル−ゲートウェイのアドレス（Ｌ−ＧＷ ａｄｄｒｅｓｓ）及びＳＩＰＴＯ機能指示子（ＳＩＰＴＯ ｃａｐａｂｉｌｉｔｙ ｉｎｄｉｃａｏｒ）のうち一つ以上を追加して、コネクション要請メッセージ、すなわち初期メッセージ（例えば、ｉｎｉｔｉａｌ ＵＥ ｍｅｓｓａｇｅ）を生成して、ＭＭＥ ５１０に伝送する。該コネクション要請メッセージ、すなわち初期メッセージはＳ１−ＡＰに基づく。この初期メッセージは、例えば、図示のようにＩｎｉｔｉａｌ ＵＥ Ｍｅｓｓａｇｅでよい。

上記コネクション要請メッセージ、すなわち初期メッセージは、Ｈｏｍｅ （ｅ）ＮｏｄｅＢの情報、例えば、ＣＳＧ ｉｄ、Ｈｏｍｅ （ｅ）ＮｏｄｅＢの機能に関する情報、ＬＩＰＡサービス機能指示子（ＬＩＰＡ ｃａｐａｂｉｌｉｔｙ ｉｎｄｉｃａｔｏｒ）又はＳＩＰＴＯサービス機能指示子（例えば、ＳＩＰＴＯ ｃａｐａｂｉｌｉｔｙ ｉｎｄｉｃａｔｏｒ）などをさらに含むとよい。このとき、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００はＬＩＰＡ及びＳＩＰＴＯの両方を支援することもあり、或いはいずれか一方のみを支援することもあるから、上記２つの指示子が全て含まれることもあり、一方のみ含まれることもある。すなわち、ＬＩＰＡ及びＳＩＰＴＯが両方とも支援される場合に、上記２つのパラメータが全て含まれる。

ＭＭＥ ５１０（又は、ＵＭＴＳの場合はＳＧＳＮ）が上記コネクション要請メッセージ、すなわち初期メッセージを受信すると、該コネクション要請メッセージ、すなわち初期メッセージ（Ｉｎｉｔｉａｌ ＵＥ ｍｅｓｓａｇｅ）内の領域更新要請メッセージ、すなわちＴＡＵ Ｒｅｑｕｅｓｔメッセージ（Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ）を抽出する。そして、該コネクション要請メッセージ、すなわち初期メッセージ内に含まれた指示子又は情報を抽出する。ＭＭＥ ５１０は、当該抽出した指示子又は情報を保存する。

そして、ＭＭＥ ５１０（又は、ＵＭＴＳの場合はＳＧＳＮ）は、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００を通して領域更新受諾又は同意メッセージ、例えばＴＡＵ ＡｃｃｅｐｔメッセージをＵＥ １００に伝送する。具体的に、ＭＭＥ ５１０（又は、ＵＭＴＳの場合はＳＧＳＮ）は、領域更新受諾又は同意メッセージ、例えばＴＡＵ ＡｃｃｅｐｔメッセージはＳ１−ＡＰプロトコルに基づいてカプセル化して、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００に伝達する。そして、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００は、該カプセル化したメッセージから、領域更新受諾又は同意メッセージ、例えばＴＡＵ Ａｃｃｅｐｔメッセージを抽出し、この抽出されたメッセージをＲＲＣプロトコルに基づいてカプセル化してＵＥ １００に伝達する。

以上の１）過程は、例示的にＴＡＵ手順を中心に説明したが、ＲＡＵ（Ｒａｄｉｏ Ａｒｅａ Ｕｐｄａｔｅ）手順、ハンドオーバー手順、又はアタッチ手順に変形されてもよい。ＲＡＵ手順に変形される場合に、ＵＥ １００が伝送するメッセージはＲＡＵ要請メッセージであればよい。ハンドオーバー手順に変形される場合に、ＵＥ １００が伝送するメッセージはハンドオーバー要請メッセージであればよい。又は、アタッチ手順に変形される場合に、ＵＥ １００が伝送するメッセージはアタッチ要請メッセージであればよい。このようなＲＡＵ、ハンドオーバー又はアタッチ手順は、本明細書を理解した当業者であれば容易に具現できるから、その詳細は説明を省略する。

２）次に、図７を参照すると、ＭＭＥ ５１０（又は、ＵＭＴＳの場合はＳＧＳＮ）は、アタッチ手順、ＴＡＵ手順、又はハンドオーバー手順において受信した情報に基づいて、ＳＩＰＴＯフェムト、すなわちＨｏｍｅ （ｅ）ＮｏｄｅＢを通るＳＩＰＴＯを適用するか否かを決定する。

具体的に、ＭＭＥ ５１０（又は、ＵＭＴＳの場合はＳＧＳＮ）は、上記の加入者情報、保存された情報又は指示子のうち一つ以上に基づいて、ＵＥ １００にＳＩＰＴＯフェムトサービスを提供するか否かを決定するとよい。すなわち、ＭＭＥ ５１０は、上記の加入者情報、保存された情報又は指示子のうち一つ以上に基づいて、ＵＥ １００のＰＤＮ接続（ｃｏｎｎｅｃｔｉｏｎ）をＨｏｍｅ （ｅ）ＮｏｄｅＢ ３００及び有線網７００内のノードを通る経路を経由するように設定するか否かを決定するとよい。

具体的に、ＭＭＥ ５１０は、上記ＴＡＵ要請メッセージ内にローカル−ゲートウェイのアドレス情報とＳＩＰＴＯ機能指示子のうち一つ以上が含まれていると、Ｈｏｍｅ （ｅ）ＮｏｄｅＢがＳＩＰＴＯサービスを提供できると判断する。

すなわち、ローカルゲートウェイのアドレス情報（すなわち、識別子）、そしてＳＩＰＴＯサービス関連指示子のうち一つ以上を考慮して、Ｈｏｍｅ （ｅ）ＮｏｄｅＢをＳＩＰＴＯサービスを提供できるものと判断する。

このようにＨｏｍｅ （ｅ）ＮｏｄｅＢでＳＩＰＴＯサービスが可能であると、ＭＭＥ ５１０は、ＡＰＮに基づいて端末のデータに対してＳＩＰＴＯを適用させることが可能であるか否か判断する。

このような判断のために、ＭＭＥ ５１０は事業者政策を追加的に考慮すればよい。また、ＭＭＥ ５１０は、ＵＥに要求されるベアラのＱｏＳを考慮してもよい。具体的に、公衆網のような有線網７００内のノードを通る経路を経由するように設定されるベアラのＱｏＳが、要求されるＱｏＳを満たすと、ＭＭＥ ５１０は、ＵＥ １００にＳＩＰＴＯサービスを提供するものと決定すればよい。

一方、ＭＭＥ ５１０は、上記の加入者情報、保存された情報又は指示子のうち一つ以上に基づいて、ＵＥ １００にＬＩＰＡサービスを提供するか否かをさらに決定してもよい。

また、ＵＥ １００がＨｏｍｅ （ｅ）ＮｏｄｅＢのＣＳＧメンバーであるか否かが考慮されてもよい。このＣＳＧメンバーシップに関する情報は、ＨＳＳ ５４０から獲得される加入者情報に含まれていればよい。

３）一方、図７を参照すると、ＨＳＳ ５４０から獲得した情報にＳＩＰＴＯ受諾又は同意情報が含まれておらず、且つＴＡＵ要請メッセージ内にＳＩＰＴＯ受諾又は同意情報が含まれていないと、ＭＭＥ ５１０はＵＥ １００に受諾又は同意を問うために、情報要請メッセージ、例えば、ＥＳＭ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅをＵＥ １００に伝送する。この情報要請メッセージ、例えばＥＳＭ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔ ｍｅｓｓａｇｅは、ＳＩＰＴＯフェムトの受諾又は同意を要請する指示子、例えばＲｅｑｕｅｓｔ ｆｏｒ ａｌｌｏｗａｎｃｅ ｆｏｒ ＳＩＰＴＯ ｆｅｍｔｏを含めばよい。

４）そして、図７を参照すると、ＵＥ １００は、情報応答メッセージ、例えばＥＳＭ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｐｌｙ ｍｅｓｓａｇｅを伝送する。この情報応答メッセージ、例えばＥＳＭ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｐｌｙ ｍｅｓｓａｇｅ内には受諾又は同意についてユーザーから入力された応答が含まれてもよく、又はあらかじめ保存された受諾又は同意についての応答が含まれてもよい。

５）そして、図７を参照すると、上記ＳＩＰＴＯ受諾又は同意情報を確認した結果、ＵＥ １００のユーザーがＳＩＰＴＯフェムトサービスを受けることを希望することが確認されると、ＭＭＥ ５１０はＵＥ １００にＳＩＰＴＯフェムトサービスを提供すると決定すればよい。又は、ＴＡＵ要請メッセージ内にＳＩＰＴＯ受諾又は同意情報が含まれていなくても、上記獲得した加入者情報から、ＵＥ １００がＳＩＰＴＯサービスを受けることを希望することが確認されると、ＭＭＥ ５１０はＵＥ １００にＳＩＰＴＯフェムトサービスを提供すると決定すればよい。

６）上のような決定により、ＵＥのベアラがＳＩＰＴＯフェムトサービスで処理されると決定されると、言い換えれば、ＵＥのベアラが公衆網のような有線網７００内のノードを通る経路を経由するように決定されると、図７に示すように、ＭＭＥ ５１０は、既存のＰＤＮコネクションを非活性化した後、ＵＥ １００にＨｏｍｅ （ｅ）ＮｏｄｅＢを通るＳＩＰＴＯを再び活性化要請（すなわち、ＵＥに再活性化のための非活性化を要請）する。

６−１）具体的に、図８を参照すると、ＭＭＥ ５１０は、コアネットワーク、例えばサービングゲートウェイ（Ｓ−ＧＷ）５２０又はＳＧＳＮとＰＤＮゲートウェイＰ−ＧＷ ５３０との間に既存に設定されていたセッションを削除するために、セッション削除要請メッセージ、例えばＤｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔメッセージをサービングゲートウェイ（Ｓ−ＧＷ）５２０又はＳＧＳＮに伝送する。サービングゲートウェイ（Ｓ−ＧＷ）５２０又はＳＧＳＮは、このセッション削除要請メッセージを受信すると、該セッション削除要請メッセージをＰＤＮゲートウェイ（Ｐ−ＧＷ）５３０に伝達する。

６−２）ＰＤＮゲートウェイ（Ｐ−ＧＷ）５３０は応答メッセージ、例えばＤｅｌｅｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅメッセージをサービングゲートウェイ（Ｓ−ＧＷ）５２０又はＳＧＳＮに伝達し、サービングゲートウェイ（Ｓ−ＧＷ）５２０又はＳＧＳＮはそれをＭＭＥ ５１０又はＳＧＳＮに伝達する。

６−３）すると、ＭＭＥ ５１０は、ＵＥ １００が生成した既存のベアラを非活性化した後、ＳＩＰＴＯのために再活性化（ｄｅａｃｔｉｖａｔｉｏｎ ｗｉｔｈ ｒｅａｃｔｉｖａｔｉｏｎ）するように、ベアラ非活性要請メッセージを伝達する。このベアラ非活性化要請メッセージは、ｃａｕｓｅ ｖａｌｕｅ、例えばＳＩＰＴＯのための再活性化を指示する指示子、例えばＲｅａｃｔｉｖａｔｉｏｎ ｆｏｒ ＳＩＰＴＯを含むとよい。

７〜８）図７を参照すると、ＵＥ １００はＰＤＮ接続を行い、ＭＭＥがＨｏｍｅ （ｅ）ＮｏｄｅＢを通るＳＩＰＴＯを設定する。

７−１）具体的に、図８を参照すると、ＵＥ １００はＰＤＮ接続要請メッセージをＭＭＥ ５１０に伝送する。このＰＤＮ接続要請メッセージは、ＵＥ １００が受けるための接続ポイントの名前を表すＡＰＮを含む。この時、ＵＥ １００は、一般的なサービスのためのＰＤＮ（ＡＰＮ）と同じＰＤＮ（ＡＰＮ）を、接続要請メッセージ内に含めるとよい。

８−１）すると、ＭＭＥ ５１０は、ＳＩＰＴＯのためのＰＤＮ接続（ｃｏｎｎｅｃｔｉｏｎ）を生成するために、ＡＰＮと、ローカル−ゲートウェイ（Ｌ−ＧＷ）のアドレス（Ｌ−ＧＷ Ａｄｄｒｅｓｓ）を含むセッション生成要請メッセージ、例えばＣｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔをサービングゲートウェイ（Ｓ−ＧＷ）５２０に伝送する。

一方、ＭＭＥ ５１０は、前述の過程で上記加入者情報、保存された情報又は指示子のうち一つ以上に基づいて、ＵＥ １００にＬＩＰＡサービスを提供するか否かを決定した場合に、該決定に応じてＬＩＰＡ許可権（ＬＩＰＡ許可の有無（ＬＩＰＡ ｐｅｒｍｉｓｓｉｏｎ））又はパケットフィルタ情報をセッション生成要請メッセージ内に含めてもよい。すなわち、ＵＥ １００にＬＩＰＡサービスを提供すると決定した場合、ＭＭＥ ５１０はＬＩＰＡ許可権をセッション生成要請メッセージ内に含めればよい。仮に、ＵＥ １００にＬＩＰＡサービスを提供しないと決定した場合に、ＭＭＥ ５１０はＬＩＰＡ許可権を含めず、フィルタ情報のみをセッション生成要請メッセージに含めればよい。

或いは、前述の過程でＵＥ １００にＬＩＰＡサービスを提供するか否かが決定されなかった場合には、ＵＥ １００からのＰＤＮ接続要請メッセージを受信すると、決定してもよい。

８−２）サービング−ゲートウェイ（Ｓ−ＧＷ）５２０は、セッション生成要請メッセージを受信すると、セッション生成要請メッセージ内のパラメータ、例えばローカル−ゲートウェイのアドレスを確認する。パラメータ、例えばローカル−ゲートウェイのアドレスがあれば、ローカル−ゲートウェイ（Ｌ−ＧＷ）４００に上記セッション生成要請メッセージを伝達する。

この時、ローカル−ゲートウェイ（Ｌ−ＧＷ）４００は、セッション生成要請メッセージ内にＬＩＰＡ許可権又はフィルタ情報のうち一つ以上が含まれているか確認する。仮に、ＬＩＰＡ許可権が含まれていれば、後でＵＥ １００から受信されるデータが、ローカル−ゲートウェイ（Ｌ−ＧＷ）４００に接続した小規模ネットワーク、例えばホームネットワーク又は会社ネットワークへ向かう場合に、それを許容する。しかし、ＬＩＰＡ許可権が含まれていないか、又は、フィルタ情報が含まれていると、後でＵＥ １００から受信されるデータが、ローカル−ゲートウェイ（Ｌ−ＧＷ）４００に接続した小規模ネットワーク、例えばホームネットワーク又は会社ネットワークへ向かう場合に、そのデータを遮断すればよい。

８−３）ローカル−ゲートウェイ（Ｌ−ＧＷ）４００は、セッション生成応答メッセージ、例えば、Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅメッセージをサービングゲートウェイ５２０に伝達し、このメッセージをサービングゲートウェイ５２０はＭＭＥ ５１０に伝達する。

７−２）一方、ＭＭＥ ５１０が上記セッション生成応答メッセージを受信すると、接続受諾又は同意メッセージ（例えば、Ｃｏｎｎｅｃｔｉｖｉｔｙ Ａｃｃｅｐｔメッセージ）を生成する。該生成されたメッセージはＮＡＳプロトコルに基づくものでよい。この時、ＭＭＥ ５１０はＵＥ １００にＬＩＰＡサービスを許与するか否かを決定し、該決定に基づいて、ＬＩＰＡサービスに対する通知を上記生成されたメッセージ内に含めるとよい。

続いて、ＭＭＥ ５１０は、上記生成されたメッセージをＳ１ ＡＰベースの初期コンテクスト設定応答メッセージ（Ｉｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージ）にカプセル化する。この時、ＭＭＥ ５１０はＵＥ １００にＬＩＰＡサービスを許与するか否かの決定に応じて、ＬＩＰＡ許可権、パケットフィルタ情報のうち一つ以上を初期コンテクスト設定応答メッセージ内に含めればよい。

続いて、ＭＭＥ ５１０は初期コンテクスト設定応答メッセージをＨｏｍｅ （ｅ）ＮｏｄｅＢ ３００に伝送する。

７−３）Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００は、初期コンテクスト設定応答メッセージを受信すると、上記接続受諾又は同意メッセージを抽出し、抽出された接続受諾又は同意メッセージをＲＲＣコネクション再構成メッセージ内にカプセル化する。

また、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００は、上記初期コンテクスト設定応答メッセージ内にあるパラメータの一部のみを上記ＲＲＣコネクション再構成メッセージに含めてもよく、或いは、パラメータ全部を含めてもよい。また、上記受信した接続受諾又は同意メッセージ内にあるパラメータの一つ以上を除外させてもよく、或いは、一つ以上の情報又はパラメータを追加してもよい。例示的に、図８には、上記接続受諾又は同意メッセージ内に、ＬＩＰＡサービスに対する通知パラメータ、例えば、ＬＩＰＡ ｎｏｔｉｆｉｃａｔｉｏｎの他にＥ−ＲＡＢ ｉｄパラメータがさらに含まれているとした。

Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００は、上記ＲＲＣコネクション再構成メッセージをＵＥ １００に伝送する。

一方、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００は、上記接続受諾又は同意メッセージ内にあった、ＬＩＰＡ通知パラメータ、ＬＩＰＡ許可権又はフィルタ情報のうち一つ以上を抽出して保存する。そして、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００は、ＬＩＰＡ通知パラメータ及びＬＩＰＡ許可権のうち一つ以上に基づいて、ＵＥ １００に対してＬＩＰＡサービスが許与されるか否かを判断する。仮に、ＬＩＰＡサービスが許与されないならば、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００は、ＵＥ １００から小規模ネットワーク、例えばホームネットワーク又は会社ネットワークへのデータを受信するようになっても、それを廃棄したり、遮断する。又は、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００は、ＵＥ １００から小規模ネットワーク、例えばホームネットワーク又は会社ネットワークへ向かうデータを受信するようになると、上記フィルタ規則にしたがって遮断したり、廃棄する。

一方、ＲＲＣコネクション再構成メッセージを受信すると、ＵＥ １００は、ＲＲＣコネクション再構成完了メッセージをＨｏｍｅ （ｅ）ＮｏｄｅＢ ３００に伝送するとよい。

そして、ＵＥ １００は、上記ＲＲＣコネクション再構成メッセージ内にＬＩＰＡサービスに対する通知パラメータ（例えば、ＬＩＰＡ ｎｏｔｉｆｉｃａｔｉｏｎ）が存在するか確認し、存在すると、ＬＩＰＡサービスに対する通知パラメータを確認する。ＬＩＰＡサービスに対する通知パラメータによりＬＩＰＡサービスが許与されない場合、ＵＥ １００は、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００を通る小規模ネットワーク、例えばホームネットワーク又は会社ネットワークへのデータが発生しないようにしたり、或いは、当該データが発生したとしても伝送しない。

以上、図７及び図８ではＥＰＣを基準にしてＭＭＥ ５１０、Ｓ−ＧＷ ５２０を示したが、本発明の概念はＵＭＴＳにも同様の適用が可能である。ＵＭＴＳでは、ＭＭＥ ５１０とＳ−ＧＷ ５２０の両方がＳＧＳＮに統合されるとよい。そのため、同図のＭＭＥ ５１０とＳ−ＧＷ ５２０間の信号送受信を行われず、ＳＧＳＮ内部で全て処理される。

以上では図面を参照して、手順を中心に説明してきた。以下では、図示の各主体の動作を中心に説明する。

１．ＵＥ

ＳＩＰＴＯ ａｃｃｅｐｔａｎｃｅ（受諾又は同意）／ｄｅｃｌｉｎｅ（拒否）に関する情報をＭＭＥ ５１０に提供する。ＭＭＥは、この情報を受信した後、諸決定要素と比較してＳＩＰＴＯ ｆｅｍｔｏを適用するか否かを決定する。

ＵＥ １００が上記情報を伝達する時点は、情報要請メッセージ、例えばＥＳＭ ｉｎｆｏｒｍａｔｉｏｎ ｒｅｑｕｅｓｔメッセージの受信に応答して行う時点にしてもよく、又は事業者の要請に応じてＨＳＳ ５４０の加入者情報に記録する時点にしてもよい。

表８は、上記のＵＥ動作事項を整理したものである。

また、ＵＥ １００は、ＳＩＰＴＯ ｆｅｍｔｏが可能になった後、政策に基づいてデータ伝送（Ｏｆｆｌｏａｄｉｎｇ）をするようになる。この政策は、事前に伝達（ｓｔａｔｉｃ、ｄｙｎａｍｉｃ）されてＵＥ １００に保存される。

新しいＰＤＮ ｃｏｎｎｅｃｔｉｏｎ生成完了後に、ＵＥ １００は、ＭＭＥ ５１０からＬＩＰＡやＳＩＰＴＯのｎｏｔｉｆｉｃａｔｉｏｎを受信する。各ｎｏｔｉｆｉｃａｔｉｏｎを受信することによって、ＵＥ １００は、生成されたＰＤＮがＬＩＰＡ用か、ＳＩＰＴＯ用か、又は両方とも支援するものかを区別し、それに基づいて各ＩＰ ｐａｃｋｅｔが伝送されるべき経路を選択する。

２．ＭＭＥ

まず、ＭＭＥ ５１０は、ＳＩＰＴＯ ｆｅｍｔｏを適用するか否かを決定する。そのために、ＭＭＥ ５１０は、１．加入者情報、２．Ｈｏｍｅ （ｅ）ＮｏｄｅＢ（Ｌ−ＧＷアドレスなど）３．ユーザーの受諾又は同意の有無に関する情報に基づいて、ＳＩＰＴＯ ｆｅｍｔｏを適用するか否かを判断する。

この時、ユーザーの受諾又は同意の有無に関する情報は、ＭＭＥ ５１０が情報要請メッセージ、例えばＥＳＭ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔを伝送することによって受信することができる。

ＭＭＥ ５１０がユーザーの受諾又は同意の有無に関する情報を受信する時点は、ＵＥ １００のアタッチ時点であってもよく、又はアタッチやＬＩＰＡが完了する時点であってもよい。アタッチやＬＩＰＡが完了する時点にユーザーの受諾又は同意の有無に関する情報を受信するために、ＭＭＥ ５１０は、Ａｔｔａｃｈ Ａｃｃｅｐｔ、ＰＤＮ ｃｏｎｎｅｃｔｉｖｉｔｙ Ａｃｃｅｐｔメッセージにユーザーの受諾又は同意の有無に関する情報を問う指示子を含めてもよい。

一方、ＭＭＥ ５１０がユーザーの受諾又は同意の有無に関する情報を受信する時点は、ＳＩＰＴＯ ｆｅｍｔｏを適用するか否かを決定する時点であってよい。この時、ＳＩＰＴＯ ｆｅｍｔｏを適用するか否かを決定する時点は、ＴＡＵ／ＲＡＵ以降やハンドオーバー時になればいいので、ＭＭＥ ５１０がユーザーの受諾又は同意の有無に関する情報を受信する時点もＴＡＵ／ＲＡＵ以降やハンドオーバー時点になればよい。

一方、ＭＭＥ ５１０はＳＩＰＴＯ ＰＤＮ及びＬＩＰＡ ＰＤＮを統合して運用してもよく、別々に運用してもよい。別々に運営する方法は、ＳＩＰＴＯ ＰＤＮとＬＩＰＡ ＰＤＮを個別に運営する方式である。統合して運営する方法では、もしＬＩＰＡ ＰＤＮが既に存在していると、ＳＩＰＴＯ ＰＤＮをそれと結合する。ＳＩＰＴＯ ＰＤＮがＬＩＰＡ ＰＤＮに吸収又は共有される概念となる。結果として統合されたコンテクスト（Ｃｏｎｔｅｘｔ）が生成される。

下記表９は、ＭＭＥ動作事項を整理したものである。

ここで注目すべき点は、ＬＩＰＡを提供しない場合に、ＳＩＰＴＯを提供してもＬＩＰＡの場合と同様にＬ−ＧＷが割り当てられるため、ＵＥがホームネットワークにデータを伝送することがあるということである。すなわち、ＳＩＰＴＯセッションを作る過程が既存ＬＩＰＡと同一であり、よって、ＬＩＰＡトラフィックが伝送されることがある。しかし、ＳＩＰＴＯ ｔｒａｆｆｉｃのみ伝送され、ＬＩＰＡ用のトラフィックはドロップ（ｄｒｏｐ）又は制止されなければならない。そこで、ＭＭＥ ５１０は、Ｈｏｍｅ （ｅ）ＮｏｄｅＢやＬ−ＧＷに、ＬＩＰＡは許容されていない旨を知らせる指示子を伝送するか、ＬＩＰＡやＳＩＰＴＯ ｐｅｒｍｉｓｓｉｏｎ ｉｎｄｉｃａｔｏｒ又はフィルタ情報（ｔａｒｇｅｔ ｉｐ ａｄｄｒｅｓｓなど）、ＣＳＧ ｉｄ、ＡＰＮなどを伝達して、当該ネットワークに伝達されるトラフィックを遮断したり伝達する制御機能を行うようにする。

３．Ｈｏｍｅ （ｅ）ＮｏｄｅＢ

Ｈｏｍｅ （ｅ）ＮｏｄｅＢ動作事項を整理すると、下記表１０の通りである。

図１０は、本発明に係るＨｏｍｅ （ｅ）ＮｏｄｅＢ ３００及びＭＭＥ ５１０の構成ブロック図である。

図１０に示すように、Ｈｏｍｅ （ｅ）ＮｏｄｅＢ ３００は、保存手段３０１と、コントローラ３０２と、送受信部３０３とを備えている。一方、ＭＭＥ ５１０は、保存手段５１１と、コントローラ５１２と、送受信部５１３と、を備えている。

保存手段３０１，５１１は、図５乃至図９に示す方法を保存する。

コントローラ３０２，５１２は、保存手段３０１，５１１及び送受信部ら３０３，５１３を制御する。具体的に、コントローラ３０２，５１２は、保存手段３０１，５１１に保存された上記方法をそれぞれ実行する。そして、コントローラ３０２，５１２は、送受信部３０３，５１３を介して上述の信号を伝送する。

以上では本発明の好適な実施例を例示的に説明したが、本発明の範囲はそれらの特定実施例に限定されるものではなく、本発明は、本発明の思想及び特許請求の範囲に記載された範ちゅう内で様々な形態に修正、変更又は改善が可能である。

Claims (15)

1. ネットワーク内において制御プレーンを担当するサーバーでサービスを制御する方法であって、
   Ｈｏｍｅ （ｅ）ＮｏｄｅＢからＡＰＮ、ローカルゲートウェイの識別子を表すパラメータ、及びＳＩＰＴＯサービス関連指示子のうち一つ以上を含む第１メッセージを受信するステップであって、前記第１メッセージは、端末による要請メッセージを含むステップと、
   前記受信した第１メッセージに基づいて、前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢでＳＩＰＴＯサービスが可能であると確認される場合に、前記第１メッセージ内のＡＰＮに基づいて、前記端末のデータに対してＳＩＰＴＯを適用させることが可能か否か判断するステップであって、この判断ステップにおいて、あらかじめ保存されているＡＰＮ関連情報に基づいて、前記第１メッセージ内に含まれたＡＰＮがＳＩＰＴＯ適用可能なものであるか否かを判断するステップと、
   前記端末のデータに対してＳＩＰＴＯを適用させることが可能である場合に、前記ＳＩＰＴＯサービスに対するユーザーの同意情報に基づいて、前記端末にＳＩＰＴＯサービスを提供するか否かを決定するステップと、
   前記決定に基づいてＳＩＰＴＯサービス通知を前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢに伝送するステップと、
   を含み、
   前記ＳＩＰＴＯサービスに対する前記ユーザーの同意情報は、前記端末に情報要請メッセージを伝送し、該情報要請メッセージに対する応答として受信される情報応答メッセージ内に含まれていることを特徴とする、サーバーでのサービス制御方法。
2. 前記ＳＩＰＴＯサービスに対する前記ユーザーの同意情報が含まれている情報応答メッセージは、前記端末がアタッチ手順、ＴＡＵ手順、ハンドオーバー手順を行う時に受信されることを特徴とする、請求項１に記載のサーバーでのサービス制御方法。
3. 前記ＳＩＰＴＯサービスに対する前記ユーザーの同意情報は、加入者情報サーバーから獲得されたものであることを特徴とする、請求項１に記載のサーバーでのサービス制御方法。
4. ＬＩＰＡサービスを前記端末に提供するか否かを決定するステップと、
   前記決定に基づいて、ＬＩＰＡサービス許可情報又はフィルタ情報を前記ローカルゲートウェイに伝送するステップと、
   前記ＬＩＰＡサービス許可情報、フィルタ情報、及びＬＩＰＡサービスに対する通知のうち一つ以上を前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢに伝送するステップと、
   のうち一つ以上をさらに含むことを特徴とする、請求項１に記載のサーバーでのサービス制御方法。
5. 前記ＬＩＰＡサービス許可情報又はフィルタ情報は、前記端末により発生したＬＩＰＡサービスのためのデータを、前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢ又はローカルゲートウェイが遮断すべきか否かを決定するのに用いられ、
   前記ＬＩＰＡサービスに対する通知は、前記端末にＬＩＰＡサービスが許容されるか否かを知らせるために用いられることを特徴とする、請求項４に記載のサーバーでのサービス制御方法。
6. 前記ＳＩＰＴＯサービス通知は、ＳＩＰＴＯフェムトが適用されたことを表すことを特徴とする、請求項１に記載のサーバーでのサービス制御方法。
7. 前記ＳＩＰＴＯフェムトは、前記端末のデータが、前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢに接続しているホームネットワークを通って迂回することを意味することを特徴とする、請求項６に記載のサーバーでのサービス制御方法。
8. 前記ＳＩＰＴＯフェムトが適用されたことを知らせるＳＩＰＴＯサービス通知は、ＳＩＰＴＯマクロが適用されたことを知らせる通知とは異なる専用の通知メッセージであることを特徴とする、請求項６に記載のサーバーでのサービス制御方法。
9. 前記ＳＩＰＴＯフェムトが適用されたことを知らせるＳＩＰＴＯサービス通知は、ＳＩＰＴＯサービスが適用されたことを知らせる通知における属性値で表現されることを特徴とする、請求項６に記載のサーバーでのサービス制御方法。
10. 前記受信した第１メッセージに基づいて前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢでＳＩＰＴＯサービスが可能であるか確認することは、
    前記第１メッセージ内のローカルゲートウェイの識別子、そして前記ＳＩＰＴＯサービス関連指示子のうち一つ以上を考慮して、前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢでＳＩＰＴＯサービスが可能であるか否か判断することを含むことを特徴とする、請求項１に記載のサーバーでのサービス制御方法。
11. ネットワーク内において制御プレーンを担当するサーバーであって、
    Ｈｏｍｅ （ｅ）ＮｏｄｅＢからＡＰＮ、ローカルゲートウェイの識別子を表すパラメータ、及びＳＩＰＴＯサービス関連指示子のうち一つ以上を含む第１メッセージを受信する送受信部であって、前記第１メッセージは、端末による要請メッセージを含む、送受信部と、
    前記受信した第１メッセージに基づいて、前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢでＳＩＰＴＯサービスが可能であると確認される場合に、前記ＡＰＮに基づいて、前記端末のデータに対してＳＩＰＴＯを適用させることが可能であるか否か判断し、前記端末のデータに対してＳＩＰＴＯを適用させることが可能であると、前記ＳＩＰＴＯサービスに対するユーザーの同意情報に基づいて、前記端末にＳＩＰＴＯサービスを提供するか否かを決定する制御部と、
    を備え、
    前記制御部は、前記ＳＩＰＴＯを適用させることが可能であるか否かを判断するために、あらかじめ保存されているＡＰＮ関連情報に基づいて、前記第１メッセージ内に含まれたＡＰＮがＳＩＰＴＯ適用可能なものであるか否か判断し、
    前記送受信部は、前記制御部の前記決定に基づいて、ＳＩＰＴＯサービス通知を前記Ｈｏｍｅ （ｅ）ＮｏｄｅＢに伝送し、
    前記ＳＩＰＴＯサービスに対する前記ユーザーの同意情報は、前記端末に情報要請メッセージを伝送し、前記情報要請メッセージに対する応答として受信される情報応答メッセージ内に含まれていることを特徴とする、サーバー。
12. 前記ＳＩＰＴＯサービスに対する前記ユーザーの同意情報が含まれる情報応答メッセージは、前記端末がアタッチ手順、ＴＡＵ手順、ハンドオーバー手順を行う時に受信されることを特徴とする、請求項１１に記載のサーバー。
13. 前記ＳＩＰＴＯサービスに対する前記ユーザーの同意情報は、加入者情報サーバーから獲得されたものであることを特徴とする、請求項１１に記載のサーバー。
14. 前記ＳＩＰＴＯサービス通知は、ＳＩＰＴＯフェムトが適用されたことを表すことを特徴とする、請求項１１に記載のサーバー。
15. 前記ＳＩＰＴＯフェムトが適用されたことを知らせるＳＩＰＴＯサービス通知は、前記ＳＩＰＴＯマクロが適用されたことを知らせる通知とは異なる専用の通知メッセージであることを特徴とする、請求項１４に記載のサーバー。

Images