特許 6816252 ＰＤＵセッション確立手順を処理する方法及びＡＭＦノード

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

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

(11)【特許番号】6816252

(24)【登録日】2020年12月25日

(45)【発行日】2021年1月20日

(54)【発明の名称】ＰＤＵセッション確立手順を処理する方法及びＡＭＦノード

(51)【国際特許分類】

   H04W 76/11 20180101AFI20210107BHJP

   H04W 36/14 20090101ALI20210107BHJP

   H04W 80/10 20090101ALI20210107BHJP

【ＦＩ】

   H04W76/11

   H04W36/14

   H04W80/10

【請求項の数】14

【全頁数】38

(21)【出願番号】特願2019-501466(P2019-501466)

(86)(22)【出願日】2018年4月11日

(65)【公表番号】特表2019-521607(P2019-521607A)

(43)【公表日】2019年7月25日

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

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

(87)【国際公開日】20181025

【審査請求日】2019年1月11日

(31)【優先権主張番号】62/486,982

(32)【優先日】2017年4月19日

(33)【優先権主張国】US

(31)【優先権主張番号】62/489,996

(32)【優先日】2017年4月25日

(33)【優先権主張国】US

(31)【優先権主張番号】62/581,036

(32)【優先日】2017年11月3日

(33)【優先権主張国】US

(31)【優先権主張番号】10-2018-0034808

(32)【優先日】2018年3月27日

(33)【優先権主張国】KR

(73)【特許権者】

【識別番号】502032105

【氏名又は名称】エルジー エレクトロニクス インコーポレイティド

(74)【代理人】

【識別番号】100099759

【弁理士】

【氏名又は名称】青木 篤

(74)【代理人】

【識別番号】100123582

【弁理士】

【氏名又は名称】三橋 真二

(74)【代理人】

【識別番号】100165191

【弁理士】

【氏名又は名称】河合 章

(74)【代理人】

【識別番号】100114018

【弁理士】

【氏名又は名称】南山 知広

(74)【代理人】

【識別番号】100159259

【弁理士】

【氏名又は名称】竹本 実

(72)【発明者】

【氏名】ヨン ミョンジュン

(72)【発明者】

【氏名】キム レヨン

(72)【発明者】

【氏名】キム チェヒョン

(72)【発明者】

【氏名】キム ヒョンソク

(72)【発明者】

【氏名】リュ チンソク

(72)【発明者】

【氏名】パク サンミン

【審査官】 石原 由晴

(56)【参考文献】

【文献】 Huawei, Hisilicon，Comparison of the options for session ID allocation and routing of subsequent SM signalling[online]，SA WG2 Meeting #118 S2-167000，Internet<URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_118_Reno/Docs/S2-167000.zip>，２０１６年１１月２１日

【文献】 CATT，Update of PDU session establishment procedure[online]，3GPP TSG SA WG2 Meeting #120 S2-172136，Internet<URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_120_Busan/Docs/S2-172136.zip>，２０１７年 ３月２１日

【文献】 Ericsson，P-CR on PDU Session establishment procedure and message coding[online]，3GPP TSG-CT WG1 Meeting #103 C1-171961，Internet<URL:http://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_103_Spokane/docs/C1-171961.zip>，２０１７年 ４月１０日

【文献】 Nokia, Nokia Shanghai Bell, Verizon，Inability to route a 5GSM message forwarding to SMF in non-V/HPLMN[online]，3GPP TSG-CT WG1 Meeting #109 C1-181782，Internet<URL:https://www.3gpp.org/ftp/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_109_Montreal/Docs/C1-181782.zip>，２０１８年 ３月 ２日

【文献】 Ericsson，23.502: Handover between 3GPP and non-3GPP access[online]，SA WG2 Meeting #120 S2-171752，Internet<URL:http://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_120_Busan/Docs/S2-171752.zip>，２０１７年 ３月２１日

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

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

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

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

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

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

【請求項1】

ＡＭＦ（ａｃｃｅｓｓ ａｎｄ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）エンティティがＰＤＵ（Ｐａｃｋｅｔ Ｄａｔａ Ｕｎｉｔ）セッション確立手順を処理する方法であって、
ＵＥから、ＰＤＵセッション識別子と、３ＧＰＰアクセスと非３ＧＰＰアクセスの間のハンドオーバが要求される指示を含むＰＤＵセッション確立要求を受信するステップと、
前記ＰＤＵセッション識別子に対応するＳＭＦ（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）識別子を取得するステップと、
前記ＳＭＦ識別子に対応するＳＭＦエンティティと、前記ＡＭＦエンティティが同じＰＬＭＮ（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）に属することに基づいて、前記ＰＤＵセッション確立要求を拒絶しないと決定するステップと、
前記ＳＭＦエンティティと前記ＡＭＦエンティティが同一ＰＬＭＮに属する決定は、前記ＳＭＦ識別子に基づき、
前記ＰＤＵセッション確立要求を拒絶する決定に基づいて、前記ＵＥに拒絶理由を送信するステップとを含む、方法。

【請求項2】

前記ＰＤＵセッション確立要求のメッセージは、要求タイプをさらに含み、
前記要求タイプは、既存ＰＤＵセッションがある “既存ＰＤＵセッション”を指示する、請求項１に記載の方法。

【請求項3】

“既存ＰＤＵセッション”を指示する前記要求タイプに基づいて、
ＰＤＵセッションの移動は、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）ベースのアクセスネットワークと非３ＧＰＰ（ｎｏｎ−３ＧＰＰ）ベースのアクセスネットワークとの間で要求されることを更に含む、請求項２に記載の方法。

【請求項4】

前記ＰＤＵセッション識別子と前記ＳＭＦ識別子とを相互に関連付けて格納するステップをさらに含む、請求項１に記載の方法。

【請求項5】

前記ＳＭＦ識別子は、ＰＬＭＮ識別子を含む、請求項１に記載の方法。

【請求項6】

前記ＳＭＦ識別子に対応する前記ＳＭＦエンティティがホームＰＬＭＮ（ＨＰＬＭＮ）に属するとの決定に基づいて、前記ＰＤＵセッション確立要求を拒絶しないと決定するステップと、
（ｉ）前記ＳＭＦ識別子に対応する前記ＳＭＦエンティティと前記ＡＭＦエンティティが同じＰＬＭＮに属しないこと及び、（ｉｉ）前記ＳＭＦ識別子に対応する前記ＳＭＦエンティティが前記ＨＰＬＭＮに属しないとの決定に基づいて前記ＰＤＵセッション確立要求を拒絶することを決定するステップをさらに含む、請求項１に記載の方法。

【請求項7】

ＰＤＵ（Ｐａｃｋｅｔ Ｄａｔａ Ｕｎｉｔ）セッション確立手順を処理するように設定されたＡＭＦ（ａｃｃｅｓｓ ａｎｄ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）エンティティであって、
送受信部と、
少なくとも一つのプロセッサと、
前記少なくとも一つのプロセッサと動作的に結合でき、実行された時、前記少なくとも一つのプロセッサが、
ＵＥから、ＰＤＵセッション識別子と、３ＧＰＰアクセスと非３ＧＰＰアクセスの間のハンドオーバが要求される指示を含むＰＤＵセッション確立要求を受信し、
前記ＰＤＵセッション識別子に対応するＳＭＦ（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）識別子を取得し、
前記ＳＭＦ識別子に対応するＳＭＦエンティティと、前記ＡＭＦエンティティが同じＰＬＭＮ（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）に属することに基づいて、前記ＰＤＵセッション確立要求を拒絶しないと決定し、
前記ＳＭＦエンティティと前記ＡＭＦエンティティが同一ＰＬＭＮに属するとの決定は、前記ＳＭＦ識別子に基づき、
前記ＰＤＵセッション確立要求を拒絶する決定に基づいて、前記ＵＥに拒絶理由を送信することを含む動作を実行させる指示（インストラクション）を格納する少なくとも一つのコンピュータメモリとを含む、ＡＭＦエンティティ。

【請求項8】

前記ＰＤＵセッション確立要求のメッセージは、要求タイプをさらに含み、
前記要求タイプは、既存ＰＤＵセッションがある“既存ＰＤＵセッション”を指示する、請求項７に記載のＡＭＦエンティティ。

【請求項9】

前記動作は、
“既存ＰＤＵセッション”を指示する前記要求タイプに基づいて、
３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）ベースのアクセスネットワークと非３ＧＰＰ（ｎｏｎ−３ＧＰＰ）ベースのアクセスネットワークとの間のＰＤＵセッションの移動を要求することを更に含む、請求項８に記載のＡＭＦエンティティ。

【請求項10】

前記動作は、前記ＰＤＵセッション識別子と前記ＳＭＦ識別子とを相互に関連付けて格納することをさらに含む、請求項７に記載のＡＭＦエンティティ。

【請求項11】

前記ＳＭＦ識別子は、ＰＬＭＮ識別子を含む、請求項７に記載のＡＭＦエンティティ。

【請求項12】

前記ＳＭＦ識別子に対応する前記ＳＭＦエンティティがホームＰＬＭＮ（ＨＰＬＭＮ）に属するとの決定に基づいて、前記ＰＤＵセッション確立要求を拒絶しないと決定することと、
（ｉ）前記ＳＭＦ識別子に対応する前記ＳＭＦエンティティと前記ＡＭＦエンティティが同じＰＬＭＮに属しないこと及び（ｉｉ）前記ＳＭＦ識別子に対応する前記ＳＭＦエンティティが前記ＨＰＬＭＮに属しないことの決定に基づいて前記ＰＤＵセッション確立要求を拒絶することを決定することをさらに含む、請求項７に記載のＡＭＦエンティティ。

【請求項13】

前記ＳＭＦ識別子を決定するステップは、
前記ＰＤＵセッション確立要求に含まれる前記ＰＤＵセッション識別子に基づいて前記ＳＭＦ識別子を決定するステップを含む、請求項１に記載の方法。

【請求項14】

前記ＳＭＦ識別子を決定することは、
前記ＰＤＵセッション確立要求に含まれる前記ＰＤＵセッション識別子に基づいて前記ＳＭＦ識別子を決定することを含む、請求項７に記載のＡＭＦエンティティ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、次世代移動通信に関する。

【背景技術】

【0002】

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

【0003】

３ＧＰＰ ＳＡ ＷＧ２を中心に進行されたＳＡＥは、３ＧＰＰ ＴＳＧ ＲＡＮのＬＴＥ作業と並行してネットワークの構造を決定し、異機種ネットワーク間の移動性をサポートすることを目的とするネットワーク技術に対する研究であって、最近３ＧＰＰの重要な標準化問題のうち一つである。これは３ＧＰＰシステムをＩＰベースの多様な無線接続技術をサポートするシステムに発展させるための作業であって、より向上したデータ送信能力で送信遅延を最小化する、最適化されたパケットベースのシステムを目標にして作業が進行されてきた。

【0004】

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

【0005】

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

【0006】

ＥＰＣは、多様な構成要素を含むことができ、図１は、そのうち一部に該当する、Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）５２、ＰＤＮ ＧＷ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）５３、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）５１、ＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｓｕｐｐｏｒｔｉｎｇ Ｎｏｄｅ）、ｅＰＤＧ（ｅｎｈａｎｃｅｄ Ｐａｃｋｅｔ Ｄａｔａ Ｇａｔｅｗａｙ）を示す。

【0007】

Ｓ−ＧＷ５２は、無線アクセスネットワーク（ＲＡＮ）とコアネットワークとの間の境界点として動作し、ｅＮｏｄｅＢ２０とＰＤＮ ＧＷ５３との間のデータ経路を維持する機能をする要素である。また、端末（または、Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ＵＥ）がｅＮｏｄｅＢ２０によりサービング（ｓｅｒｖｉｎｇ）される領域にわたって移動する場合、Ｓ−ＧＷ５２は、ローカル移動性アンカーポイント（ａｎｃｈｏｒ ｐｏｉｎｔ）の役割をする。即ち、Ｅ−ＵＴＲＡＮ（３ＧＰＰリリース８以後で定義されるＥｖｏｌｖｅｄ−ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ） Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）内での移動性のために、Ｓ−ＧＷ５２を介してパケットがルーティングされる。また、Ｓ−ＧＷ５２は、他の３ＧＰＰネットワーク（３ＧＰＰリリース８以前に定義されるＲＡＮ、例えば、ＵＴＲＡＮまたはＧＥＲＡＮ（ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）／ＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ Ｇｌｏｂａｌ Ｅｖｏｌｕｔｉｏｎ） Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）との移動性のためのアンカーポイントとして機能することもできる。

【0008】

ＰＤＮ ＧＷ（または、Ｐ−ＧＷ）５３は、パケットデータネットワークに向かうデータインターフェースの終端点（ｔｅｒｍｉｎａｔｉｏｎ ｐｏｉｎｔ）に該当する。ＰＤＮ ＧＷ５３は、政策執行特徴（ｐｏｌｉｃｙ ｅｎｆｏｒｃｅｍｅｎｔ ｆｅａｔｕｒｅｓ）、パケットフィルタリング（ｐａｃｋｅｔ ｆｉｌｔｅｒｉｎｇ）、課金サポート（ｃｈａｒｇｉｎｇ ｓｕｐｐｏｒｔ）などをサポートすることができる。また、３ＧＰＰネットワークと非３ＧＰＰネットワーク（例えば、Ｉ−ＷＬＡＮ（Ｉｎｔｅｒｗｏｒｋｉｎｇ Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）のような信頼されないネットワーク、ＣＤＭＡ（Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）ネットワークやＷｉＭａｘのような信頼されるネットワーク）との移動性管理のためのアンカーポイント役割をすることができる。

【0009】

図１のネットワーク構造の例示は、Ｓ−ＧＷ５２とＰＤＮ ＧＷ５３が別途のゲートウェイで構成されるものを示すが、二つのゲートウェイが単一ゲートウェイ構成オプション（Ｓｉｎｇｌｅ Ｇａｔｅｗａｙ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｏｐｔｉｏｎ）によって具現されることもできる。

【0010】

ＭＭＥ５１は、ＵＥのネットワーク連結に対するアクセス、ネットワークリソースの割当、トラッキング（ｔｒａｃｋｉｎｇ）、ページング（ｐａｇｉｎｇ）、ローミング（ｒｏａｍｉｎｇ）及びハンドオーバなどをサポートするためのシグナリング及び制御機能を実行する要素である。ＭＭＥ５１は、加入者及びセッション管理に関連した制御平面（ｃｏｎｔｒｏｌ ｐｌａｎｅ）機能を制御する。ＭＭＥ５１は、数多くのｅＮｏｄｅＢ２２を管理し、他の２Ｇ／３Ｇネットワークに対するハンドオーバのための従来のゲートウェイの選択のためのシグナリングを実行する。また、ＭＭＥ５１は、セキュリティ過程（Ｓｅｃｕｒｉｔｙ Ｐｒｏｃｅｄｕｒｅｓ）、端末−対−ネットワークセッションハンドリング（Ｔｅｒｍｉｎａｌ−ｔｏ−ｎｅｔｗｏｒｋ Ｓｅｓｓｉｏｎ Ｈａｎｄｌｉｎｇ）、アイドル端末位置決定管理（Ｉｄｌｅ Ｔｅｒｍｉｎａｌ Ｌｏｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ）などの機能を遂行する。

【0011】

ＳＧＳＮは、異なるアクセス３ＧＰＰネットワーク（例えば、ＧＰＲＳネットワーク、ＵＴＲＡＮ／ＧＥＲＡＮ）に対するユーザの移動性管理及び認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）といった全てのパケットデータをハンドリングする。

【0012】

ｅＰＤＧは、信頼されない非３ＧＰＰネットワーク（例えば、Ｉ−ＷＬＡＮ、ＷｉＦｉホットスポット（ｈｏｔｓｐｏｔ）等）に対するセキュリティノードとしての役割をする。

【0013】

図１を参照して説明したように、ＩＰ能力を有する端末（または、ＵＥ）は、３ＧＰＰアクセスはもちろん非３ＧＰＰアクセスに基づいても、ＥＰＣ内の多様な要素を経由して事業者（即ち、オペレータ（ｏｐｅｒａｔｏｒ））が提供するＩＰサービスネットワーク（例えば、ＩＭＳ）にアクセスすることができる。

【0014】

また、図１は、多様なレファレンスポイント（例えば、Ｓ１−Ｕ、Ｓ１−ＭＭＥ等）を示す。３ＧＰＰシステムでは、Ｅ−ＵＴＲＡＮ及びＥＰＣの異なる機能エンティティ（ｆｕｎｃｔｉｏｎａｌ ｅｎｔｉｔｙ）に存在する２個の機能を連結する概念的なリンクをレファレンスポイント（ｒｅｆｅｒｅｎｃｅ ｐｏｉｎｔ）と定義する。以下の表１は、図１に示すレファレンスポイントを整理したものである。表１の例示外にもネットワーク構造によって多様なレファレンスポイントが存在できる。

【0015】

【表1】

【0016】

＜次世代移動通信ネットワーク＞

【0017】

４世代移動通信のためのＬＴＥ（ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ）／ＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）の成功にこたえて、次世代、即ち、５世代（いわゆる５Ｇ）移動通信に対する関心も高まっており、研究も続々と進行している。

【0018】

国際電気通信連合（ＩＴＵ）が定義する５世代移動通信は、最大２０Ｇｂｐｓのデータ送信速度とどこでも最小１００Ｍｂｐｓ以上の体感送信速度を提供するものを意味する。正式名称はＩＭＴ−２０２０’であり、世界的に２０２０年に商用化することを目標としている。

【0019】

ＩＴＵでは３代使用シナリオ、例えば、ｅＭＢＢ（ｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ ＢｒｏａｄＢａｎｄ）ｍＭＴＣ（ｍａｓｓｉｖｅ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）及びＵＲＬＬＣ（Ｕｌｔｒａ Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）を提示している。

【0020】

まず、ＵＲＬＬＣは、高い信頼性と低い遅延時間を要求する使用シナリオに関する。例えば、自動走行、工場自動化、増強現実のようなサービスは、高い信頼性と低い遅延時間（例えば、１ｍｓ以下の遅延時間）を要求する。現在４Ｇ（ＬＴＥ）の遅延時間は、統計的に、２１−４３ｍｓ（ｂｅｓｔ１０％）、３３−７５ｍｓ（ｍｅｄｉａｎ）である。これは１ｍｓ以下の遅延時間を要求するサービスをサポートするに足りない。

【0021】

次に、ｅＭＢＢ使用シナリオは、移動超広帯域を要求する使用シナリオに関する。

【0022】

このような超広帯域の高速サービスは、既存ＬＴＥ／ＬＴＥ−Ａのために設計されたコアネットワークによっては受容されにくい。

【0023】

したがって、いわゆる５世代移動通信ではコアネットワークの再設計が切実に要求される。

【0024】

図２は、次世代移動通信の予想構造をノード観点で表した例示図である。

【0025】

図２を参照して分かるように、ＵＥは、次世代ＲＡＮ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）を介してデータネットワーク（ＤＮ）と連結される。

【0026】

図示された制御平面機能（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ；ＣＰＦ）ノードは、４世代移動通信のＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）機能の全部または一部、Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）及びＰ−ＧＷ（ＰＤＮ Ｇａｔｅｗａｙ）の制御平面機能の全部または一部を実行する。前記ＣＰＦノードは、ＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）とＳＭＦ（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）を含む。

【0027】

図示されたユーザ平面機能（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ；ＵＰＦ）ノードは、ユーザのデータが送受信されるゲートウェイの一種である。前記ＵＰＦノードは、４世代移動通信のＳ−ＧＷ及びＰ−ＧＷのユーザ平面機能の全部または一部を実行することができる。

【0028】

図示されたＰＣＦ（Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）は、事業者の政策を制御するノードである。

【0029】

図示されたアプリケーション機能（Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ：ＡＦ）は、ＵＥに多様なサービスを提供するためのサーバである。

【0030】

図示された統合データ格納管理（Ｕｎｉｆｉｅｄ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ：ＵＤＭ）は、４世代移動通信のＨＳＳ（Ｈｏｍｅ ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）５４のように、加入者情報を管理するサーバの一種である。前記ＵＤＭは、前記加入者情報を統合データリポジトリ（Ｕｎｉｆｉｅｄ Ｄａｔａ Ｒｅｐｏｓｉｔｏｒｙ：ＵＤＲ）に格納して管理する。

【0031】

図示された認証サーバ機能（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ：ＡＵＳＦ）は、ＵＥを認証及び管理する。

【0032】

図示されたネットワークスライス選択機能（Ｎｅｔｗｏｒｋ Ｓｌｉｃｅ Ｓｅｌｅｃｔｉｏｎ Ｆｕｎｃｔｉｏｎ：ＮＳＳＦ）は、後述のようにネットワークスライシングのためのノードである。

【0033】

図３ａは、２個のデータネットワークを介した多重ＰＤＵセッションをサポートするためのアーキテクチャを示す例示図であり、図３ｂは、２個のデータネットワークに対する同時アクセスをサポートするためのアーキテクチャを示す例示図である。

【0034】

図３ａでは、ＵＥが２個のデータネットワークに多重ＰＤＵセッションを利用して同時に接続できるようにするためのアーキテクチャが示されている。２個の互いに異なるＰＤＵセッションのために２個のＳＭＦが選択される。

【0035】

図３ｂでは、ＵＥが一つのＰＤＵセッションを使用して２個のデータネットワークに同時アクセスするためのアーキテクチャが示されている。

【0036】

＜ネットワークスライス（Ｎｅｔｗｏｒｋ Ｓｌｉｃｅ）＞

【0037】

以下、次世代移動通信で導入されるネットワークのスライシングを説明する。

【0038】

次世代移動通信は、一つのネットワークを介して多様なサービスを提供するために、ネットワークのスライシングに対する概念を紹介している。ここで、ネットワークのスライシングは、特定サービスを提供する時、必要な機能を有するネットワークノードの組み合わせである。スライスインスタンスを構成するネットワークノードは、ハードウェア的に独立されたノードであり、または論理的に独立されたノードである。

【0039】

各スライスインスタンスは、ネットワーク全体を構成するのに必要な全てのノードの組み合わせで構成される。この場合、一つのスライスインスタンスは、ＵＥに単独でサービスを提供することができる。

【0040】

それに対し、スライスインスタンスは、ネットワークを構成するノードのうち一部ノードの組み合わせで構成されることもできる。この場合、スライスインスタンスは、ＵＥに単独でサービスを提供せずに、既存の他のネットワークノードと連係してＵＥにサービスを提供することができる。また、複数個のスライスインスタンスが互いに連係してＵＥにサービスを提供することもできる。

【0041】

スライスインスタンスは、コアネットワーク（ＣＮ）ノード及びＲＡＮを含む全体ネットワークノードが分離されるという点で専用コアネットワークと異なる。また、スライスインスタンスは、単純にネットワークノードが論理的に分離されるという点で専用コアネットワークと異なる。

【0042】

＜次世代移動通信ネットワークでローミング＞

【0043】

一方、ＵＥが訪問ネットワーク、例えば、ＶＰＬＭＮ（Ｖｉｓｉｔｅｄ Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）にローミングした状況でＵＥからのシグナリング要求を処理する方式には二つが存在する。１番目の方式であるＬＢＯ（ｌｏｃａｌ ｂｒｅａｋｏｕｔ）方式は、ＵＥからのシグナリング要求を訪問ネットワークで処理する。２番目の方式であるＨＲ（Ｈｏｍｅ Ｒｏｕｔｉｎｇ）方式によると、訪問ネットワークは、ＵＥからのシグナリング要求をＵＥのホームネットワークに伝達する。

【0044】

図４ａは、ローミング時、ＬＢＯ（ｌｏｃａｌ ｂｒｅａｋｏｕｔ）方式が適用されるアーキテクチャを示す例示図であり、図４ｂは、ローミング時、ＨＲ（ｈｏｍｅ ｒｏｕｔｅｄ）方式が適用されるアーキテクチャを示す例示図である。

【0045】

図４ａに示すように、ＬＢＯ方式が適用されるアーキテクチャでは、ユーザのデータは、ＶＰＬＭＮ内のデータネットワークに伝達される。そのために、ＶＰＬＭＮ内のＰＣＦがＶＰＬＭＮ内でのサービスのためのＰＣＣ規則を生成するために、ＡＦとインタラクションを実行する。前記ＶＰＬＭＮ内のＰＣＦノードは、ＨＰＬＭＮ（Ｈｏｍｅ Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）事業者とのローミング協約によって内部に設定された政策に基づいてＰＣＣ規則を生成する。

【0046】

図４ｂに示すように、ＨＲ方式が適用されるアーキテクチャでは、ＵＥのデータは、ＨＰＬＭＮ内のデータネットワークに伝達される。

【0047】

＜非３ＧＰＰネットワークへのデータ迂回＞

【0048】

次世代移動通信において、ＵＥのデータは、非３ＧＰＰネットワーク、例えば、ＷＬＡＮ（Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）またはＷｉ−Ｆｉに迂回される。

【0049】

図５Ａ乃至図５Ｆは、非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。

【0050】

ＷＬＡＮ（Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）またはＷｉ−Ｆｉは、信頼されない非３ＧＰＰネットワークと見なされる。前記非３ＧＰＰネットワークをコアネットワークに接続させるために、Ｎ３ＩＷＦ（Ｎｏｎ−３ＧＰＰ ＩｎｔｅｒＷｏｒｋｉｎｇ Ｆｕｎｃｔｉｏｎ）が追加される。

【0051】

＜既存４世代移動通信システムとのインターワーキング＞

【0052】

ＵＥが次世代ＲＡＮ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）のカバレッジを外れても、ＵＥは、４世代（４Ｇ）移動通信システムを介してでもサービスを受けることが可能でなければならない。これをインターワーキングという。以下、インターワーキングに対して詳細に説明する。

【0053】

図６ａは、ＵＥがローミングしない場合のインターワーキングのためのアーキテクチャを示し、図６ｂは、ＵＥがローミングした場合のインターワーキングのためのアーキテクチャを示す。

【0054】

図６ａを参照すると、ＵＥがローミングしない場合、既存４世代ＬＴＥのためのＥ−ＵＴＲＡＮとＥＰＣと５世代移動通信ネットワークは、互いにインターワーキングされる。図６ａにおいて、既存ＥＰＣのためのＰＧＷ（Ｐａｃｋｅｔ ｄａｔａ ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）は、ユーザ平面のみを担当するＰＧＷ−Ｕと制御平面を担当するＰＧＷ−Ｃとに分けられる。そして、ＰＧＷ−Ｕは、５世代コアネットワークのＵＰＦノードに併合され、ＰＧＷ−Ｃは、５世代コアネットワークのＳＭＦノードに併合される。そして、既存ＥＰＣのためのＰＣＲＦ（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ）は、５世代コアネットワークのＰＣＦに併合される。そして、既存ＥＰＣのためのＨＳＳは、５世代コアネットワークのＵＤＭに併合される。ＵＥは、Ｅ−ＵＴＲＡＮを介してコアネットワークに接続することもできるが、ＵＥは、５Ｇ ＲＡＮ（ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ）とＡＭＦを介してコアネットワークに接続することもできる。

【0055】

図６ａと図６ｂを相互比較して参照すると、ＵＥがＶＰＬＭＮ（Ｖｉｓｉｔｅｄ Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）にローミングした場合、前記ＵＥのデータは、ＨＰＬＭＮ（Ｈｏｍｅ ＰＬＭＮ）を経由して伝達される。

【0056】

一方、図６ａ及び図６ｂに示すＮ２６インターフェースは、ＥＰＣとＮＧコアとの間にインターワーキングを円滑にするために、ＭＭＥとＡＭＦとの間に連結されるインターフェースである。このようなＮ２６インターフェースは、事業者によって選択的にサポートされる。即ち、ＥＰＣとのインターワーキングのために、ネットワーク事業者は、Ｎ２６インターフェースを提供してもよく、またはＮ２６インターフェースを提供しなくてもよい。

【0057】

ローミング状況で、ＵＥは、ネットワークにＰＤＵセッション確立要求メッセージを送信し、これに対する応答を受けると、ＰＤＵセッションが確立されたことを知ることができる。しかし、ＵＥは、ＰＤＵセッションがＬＢＯ（Ｌｏｃａｌ Ｂｒｅａｋｏｕｔ）方式で確立されたか、またはＨＲ（Ｈｏｍｅ Ｒｏｕｔｅｄ）方式で確立されたかを知ることができない。したがって、ハンドオーバが実行できない状況が発生できる。しかし、ＵＥは、実際ハンドオーバが成功できるかどうかを知ることができないため、ハンドオーバを試みることができ、この場合、不要なシグナリングが発生するようになる。

【発明の概要】

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

【0058】

したがって、本明細書の開示は、前述した問題点を解決することを目的とする。

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

【0059】

前記のような目的を達成するために、本明細書の一開示は、ＡＭＦ（ａｃｃｅｓｓ ａｎｄ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）ノードがＰＤＵ（Ｐａｃｋｅｔ Ｄａｔａ Ｕｎｉｔ）セッション確立手順を処理する方法を提供する。前記方法は、ＰＤＵセッション確立要求を拒絶するかどうかを決定するステップを含む。ここで、前記決定ステップは、前記ＰＤＵセッション確立要求が既存ＰＤＵセッションの識別子を含む場合に実行される。前記既存ＰＤＵセッションの識別子に基づいて、ＳＭＦ（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）ノードの識別子が取得される。前記ＳＭＦノードの識別子に基づいて前記ＳＭＦノード及び前記ＡＭＦノードが両方とも同じＰＬＭＮ（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）に属すると決定される場合、前記ＰＤＵセッション確立要求は受諾される。前記ＳＭＦノードの識別子に基づいてＳＭＦノード及び前記ＡＭＦノードが両方ともＨＰＬＭＮ（Ｈｏｍｅ ＰＬＭＮ）に属すると決定される場合、前記ＰＤＵセッション確立要求は受諾される。前記ＳＭＦノード及び前記ＡＭＦノードが両方とも同じＰＬＭＮに属しない、またはＨＰＬＭＮに属しないと決定される場合、前記ＰＤＵセッション確立要求が拒絶される。

【0060】

前記ＰＤＵセッション確立要求メッセージは、要求タイプをさらに含む。前記要求タイプは、新しいＰＤＵセッションを設定するためのものである場合、要求タイプは“初期要求”を指示したり、前記要求タイプは、既存ＰＤＵセッションが存在する場合、“既存ＰＤＵセッション”を指示したりする。

【0061】

前記要求タイプが“既存ＰＤＵセッション”を指示する場合、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）ベースのアクセスネットワークと非３ＧＰＰ（ｎｏｎ−３ＧＰＰ）ベースのアクセスネットワークとの間にＰＤＵセッションの移動が要求される。

【0062】

前記ＡＭＦノードは、ＰＤＵセッションの識別子と前記ＳＭＦノードの識別子とを関連付けられて格納している。

【0063】

前記ＳＭＦノードの識別子は、ＰＬＭＮの識別子を含んで構成される。

【0064】

前記方法は、前記ＰＤＵセッション確立要求が拒絶される場合、拒絶原因を含むメッセージを送信するステップをさらに含む。

【0065】

また、前記のような目的を達成するために、本明細書の一開示は、ＰＤＵ（Ｐａｃｋｅｔ Ｄａｔａ Ｕｎｉｔ）セッション確立手順を処理するＡＭＦ（ａｃｃｅｓｓ ａｎｄ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）ノードを提供する。前記ＡＭＦノードは、送受信部と、前記送受信部を制御し、ＰＤＵセッション確立要求を拒絶するかどうかを決定するプロセッサとを含む。前記決定は、前記ＰＤＵセッション確立要求が既存ＰＤＵセッションの識別子を含む場合に実行される。前記既存ＰＤＵセッションの識別子に基づいて、ＳＭＦ（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）ノードの識別子が取得される。前記ＳＭＦノードの識別子に基づいて前記ＳＭＦノード及び前記ＡＭＦノードが両方とも同じＰＬＭＮ（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）に属しないと決定される場合、前記ＰＤＵセッション確立要求は拒絶される。また、前記ＳＭＦノードの識別子に基づいてＳＭＦノード及び前記ＡＭＦノードが両方ともＨＰＬＭＮ ＰＬＭＮ（Ｈｏｍｅ ＰＬＭＮ）に属しないと決定される場合、前記ＰＤＵセッション確立要求は拒絶される。

【発明の効果】

【0066】

本明細書の開示によると、既存問題点が解決される。

【図面の簡単な説明】

【0067】

【図1】進化した移動通信ネットワークの構造図である。

【図2】次世代移動通信の予想構造をノード観点で表した例示図である。

【図3】〔図３ａ〕は２個のデータネットワークを介した多重ＰＤＵセッションをサポートするためのアーキテクチャを示す例示図であり、〔図３ｂ〕は２個のデータネットワークに対する同時アクセスをサポートするためのアーキテクチャを示す例示図である。

【図4】〔図４ａ〕はローミング時、ＬＢＯ（ｌｏｃａｌ ｂｒｅａｋｏｕｔ）方式が適用されるアーキテクチャを示す例示図であり、〔図４ｂ〕はローミング時、ＨＲ（ｈｏｍｅ ｒｏｕｔｅｄ）方式が適用されるアーキテクチャを示す例示図である。

【図5A】非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。

【図5B】非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。

【図5C】非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。

【図5D】非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。

【図5E】非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。

【図5F】非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。

【図6】〔図６ａ〕はＵＥがローミングしない場合のインターワーキングのためのアーキテクチャを示し、〔図６ｂ〕はＵＥがローミングした場合のインターワーキングのためのアーキテクチャを示す。

【図7】例示的な登録手順を示す信号流れ図である。

【図8】例示的なＰＤＵセッション確立手順を示す信号流れ図である。

【図9】信頼されない非３ＧＰＰアクセスを介した登録手順を示す信号流れ図である。

【図10】信頼されない非３ＧＰＰアクセスを介したＵＥのＰＤＵセッション確立手順を示す流れ図である。

【図11】〔図１１ａ〕は信頼されない非３ＧＰＰアクセスから３ＧＰＰアクセスへのＰＤＵセッションハンドオーバ手順を示し、〔図１１ｂ〕は３ＧＰＰアクセスから信頼されない非３ＧＰＰアクセスへのＰＤＵセッションハンドオーバ手順を示す。

【図12】ＰＤＵセッションを確立する時、本明細書の第１の開示によって該当ＰＤＵセッションがＬＢＯ方式またはＨＲ方式で確立されたかを示す方案を示す流れ図である。

【図13】本明細書の第２の開示によって登録過程中にＵＥにハンドオーバが可能かどうかを知らせる方案を示す流れ図である。

【図14】本明細書の第３の開示によってハンドオーバのためのＰＤＵセッション確立要求に対して拒絶原因値を含むメッセージを送信することによって、ＵＥの動作を制御する方案を示す流れ図である。

【図15】ＰＤＵセッションを確立する過程で該当ＰＤＵセッションがＨＯ可能かどうかを知らせる方法である。

【図16】本発明の実施例に係るＵＥ及びネットワークノードの構成ブロック図である。

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

【0068】

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

【0069】

また、本明細書で使われる単数の表現は、文脈上、明白に異なる意味ではない限り、複数の表現を含む。本出願において、“構成される”または“有する”などの用語は、明細書上に記載された多様な構成要素、または複数のステップを必ず全て含むと解釈されてはならず、そのうち一部構成要素または一部ステップは含まれない場合もあり、または追加的な構成要素またはステップをさらに含む場合もあると解釈されなければならない。

【0070】

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

【0071】

一構成要素が他の構成要素に“連結されている”または“接続されている”と言及された場合は、該当他の構成要素に直接的に連結されており、または接続されている場合もあるが、中間に他の構成要素が存在する場合もある。それに対し、一構成要素が他の構成要素に“直接連結されている”または“直接接続されている”と言及された場合は、中間に他の構成要素が存在しないと理解しなければならない。

【0072】

以下、添付図面を参照して本発明による好ましい実施例を詳細に説明し、図面符号に関係なしで同じまたは類似の構成要素は同じ参照番号を付与し、これに対する重複説明は省略する。また、本発明を説明するにあたって、関連した公知技術に対する具体的な説明が本発明の要旨を不明にすると判断される場合、その詳細な説明を省略する。また、添付図面は、本発明の思想を容易に理解することができるようにするためのものであり、添付図面により本発明の思想が制限されると解釈されてはならないことに留意しなければならない。本発明の思想は、添付図面外に全ての変更、均等物乃至代替物にまで拡張されると解釈されなければならない。

【0073】

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

【0074】

＜セッション及びサービス連続性（Ｓｅｓｓｉｏｎ ａｎｄ Ｓｅｒｖｉｃｅ Ｃｏｎｔｉｎｕｉｔｙ）＞

【0075】

次世代移動通信ネットワークではセッション及びサービス連続性（ＳＳＣ）をサポートするために、多様なモードを提供する。

【0076】

１）ＳＳＣモード１

【0077】

ＰＤＵセッション確立過程で、ＰＤＵセッションアンカーとして動作するＵＰＦは、アクセステクノロジー（即ち、アクセスタイプ及びセル）にかかわらず維持される。ＩＰタイプのＰＤＵセッションである場合、ＩＰ連続性がＵＥの移動にかかわらずサポートされる。ＳＳＣモード１は、どのようなＰＤＵセッションタイプにも適用されることができ、併せて、どのようなアクセスタイプにも適用される。

【0078】

２）ＳＳＣモード２

【0079】

ＰＤＵセッションは、一つのＰＤＵセッションアンカーを有する場合、ネットワークは、ＰＤＵセッションの解除をトリガし、ＵＥに同じＰＤＵセッションの確立を指示することができる。前記新しいＰＤＵセッションの確立過程でＰＤＵセッションアンカーとして動作するＵＰＦが新しく選択される。ＳＳＣモード２は、どのようなＰＤＵセッションタイプにも適用されることができ、併せて、どのようなアクセスタイプにも適用される。

【0080】

３）ＳＳＣモード３

【0081】

ＳＳＣモード３に対するＰＤＵセッションに対して、ネットワークは、ＵＥと以前ＰＤＵセッションアンカーとの間の接続（ｃｏｎｎｅｃｔｉｖｉｔｙ）を解除する前に、同じデータネットワークに対する新しいＰＤＵセッションを利用するＵＥの連結確立を許容することができる。トリガ条件が適用される場合、ネットワークは、ＵＥの新しい条件に適当なＰＤＵセッションアンカー、即ち、ＵＰＦを選択するかどうかを決定することができる。ＳＳＣモード３は、どのようなＰＤＵセッションタイプにも適用されることができ、併せて、どのようなアクセスタイプにも適用される。

【0082】

４）ＳＳＣモードの選択

【0083】

ＵＥのアプリケーションまたはＵＥのアプリケーショングループと関連したＳＳＣモードのタイプを決定するためにＳＳＣモード選択政策が使われる。

【0084】

事業者は、ＵＥに前記ＳＳＣモード選択政策を提供することができる。前記政策は、一つ以上のＳＳＣモード選択政策規則を含むことができる。

【0085】

＜登録手順＞

【0086】

ＵＥは、移動追跡（ｍｏｂｉｌｉｔｙ ｔｒａｃｋｉｎｇ）を可能にしてデータ受信を可能にして、そしてサービスを受信するために、認可（ａｕｔｈｏｒｉｓｅ）を得る必要がある。そのために、ＵＥは、ネットワークに登録しなければならない。登録手順は、ＵＥが５Ｇシステムに対する初期登録をすべき必要がある時に実行される。また、前記登録手順は、ＵＥが周期的な登録アップデートを実行する時、アイドルモードで新しいＴＡ（ｔｒａｃｋｉｎｇ ａｒｅａ）へ移動する時、そしてＵＥが周期的な登録更新を実行すべき必要がある時、実行される。

【0087】

初期登録手順の間に、ＵＥのＩＤがＵＥから取得される。ＡＭＦは、ＰＥＩ（ＩＭＥＩＳＶ）をＵＤＭ、ＳＭＦ及びＰＣＦに伝達できる。

【0088】

図７は、例示的な登録手順を示す信号流れ図である。

【0089】

１）ＵＥは、ＲＡＮにＡＮメッセージを送信することができる。前記ＡＮメッセージは、ＡＮパラメータ、登録要求メッセージを含むことができる。前記登録要求メッセージは、登録タイプ、加入者永久ＩＤまたは臨時ユーザＩＤ、セキュリティパラメータ、ＮＳＳＡＩ、ＵＥの５Ｇ能力、ＰＤＵセッション状態などの情報を含むことができる。

【0090】

５Ｇ ＲＡＮである場合、前記ＡＮパラメータは、ＳＵＰＩまたは臨時ユーザＩＤ、選択されたネットワーク及びＮＳＳＡＩを含むことができる。

【0091】

登録タイプは、ＵＥが“初期登録”（即ち、ＵＥが非登録状態にある）か、“移動性登録アップデート”（即ち、ＵＥが登録された状態であり、移動性により登録手順を開始する）か、または“定期登録アップデート”（即ち、ＵＥが登録された状態であり、周期的なアップデートタイマ満了によって登録手順を開始する）かを示すことができる。臨時ユーザＩＤが含まれている場合、前記臨時ユーザＩＤは、最後のサービングＡＭＦを示す。ＵＥが３ＧＰＰアクセスのＰＬＭＮと異なるＰＬＭＮで非３ＧＰＰアクセスを介して既に登録された場合、ＵＥは、非３ＧＰＰアクセスを介して登録手順の間にＡＭＦにより割り当てられたＵＥ臨時ＩＤを提供しない。

【0092】

セキュリティパラメータは、認証及び完全性保護のために使われる。

【0093】

ＰＤＵセッション状態は、ＵＥで使用可能な（以前に設定された）ＰＤＵセッションを示す。

【0094】

２）ＳＵＰＩが含まれ、または臨時ユーザＩＤが有効なＡＭＦを示さない場合、ＲＡＮは、（Ｒ）ＡＴ及びＮＳＳＡＩに基づいてＡＭＦを選択することができる。

【0095】

（Ｒ）ＡＮが適切なＡＭＦを選択することができない場合、ローカル政策によって任意のＡＭＦを選択し、前記選択されたＡＭＦに登録要求を伝達する。選択されたＡＭＦがＵＥをサービスすることができない場合、選択されたＡＭＦは、ＵＥのために一層適切な他のＡＭＦを選択する。

【0096】

３）前記ＲＡＮは、新しいＡＭＦにＮ２メッセージを送信する。前記Ｎ２メッセージは、Ｎ２パラメータ、登録要求を含む。前記登録要求は、登録タイプ、加入者永久識別子または臨時ユーザＩＤ、セキュリティパラメータ、ＮＳＳＡＩ及びＭＩＣＯモード基本設定などを含むことができる。

【0097】

５Ｇ−ＲＡＮが使われる時、Ｎ２パラメータは、ＵＥがキャンプしているセルと関連した位置情報、セル識別子及びＲＡＴタイプを含む。

【0098】

ＵＥにより指示された登録タイプが周期的な登録更新である場合、後述する過程４〜１７は実行されない。

【0099】

４）前記新しく選択されたＡＭＦは、以前ＡＭＦに情報要求メッセージを送信することができる。

【0100】

ＵＥの臨時ユーザＩＤが登録要求メッセージに含まれてサービングＡＭＦが最後の登録以後変更された場合、新しいＡＭＦは、ＵＥのＳＵＰＩ及びＭＭコンテキストを要求するために、完全な登録要求情報を含む情報要求メッセージを以前ＡＭＦに送信することができる。

【0101】

５）以前ＡＭＦは、前記新しく選択されたＡＭＦに情報応答メッセージを送信する。前記情報応答メッセージは、ＳＵＰＩ、ＭＭコンテキスト、ＳＭＦ情報を含むことができる。

【0102】

具体的に、以前ＡＭＦは、ＵＥのＳＵＰＩ及びＭＭコンテキストを含む情報応答メッセージを送信する。

【0103】

−以前ＡＭＦに活性ＰＤＵセッションに対する情報がある場合、前記以前ＡＭＦにはＳＭＦのＩＤ及びＰＤＵセッションＩＤを含むＳＭＦ情報を前記情報応答メッセージ内に含ませることができる。

【0104】

６）前記新しいＡＭＦは、ＳＵＰＩがＵＥにより提供されない、または以前ＡＭＦから検索されない場合、ＵＥにＩｄｅｎｔｉｔｙ Ｒｅｑｕｅｓｔメッセージを送信する。

【0105】

７）前記ＵＥは、前記ＳＵＰＩを含むＩｄｅｎｔｉｔｙ Ｒｅｓｐｏｎｓｅメッセージを前記新しいＡＭＦに送信する。

【0106】

８）ＡＭＦは、ＡＵＳＦをトリガすると決定できる。この場合、ＡＭＦは、ＳＵＰＩに基づいて、ＡＵＳＦを選択することができる。

【0107】

９）ＡＵＳＦは、ＵＥ及びＮＡＳセキュリティ機能の認証を開始することができる。

【0108】

１０）前記新しいＡＭＦは、以前ＡＭＦに情報応答メッセージを送信することができる。

【0109】

もし、ＡＭＦが変更された場合、新しいＡＭＦは、ＵＥ ＭＭコンテキストの伝達を確認するために、前記情報応答メッセージを送信することができる。

【0110】

−認証／セキュリティ手順が失敗すると、登録は拒絶され、新しいＡＭＦは、以前ＡＭＦに拒絶メッセージを送信することができる。

【0111】

１１）前記新しいＡＭＦは、ＵＥにＩｄｅｎｔｉｔｙ Ｒｅｑｕｅｓｔメッセージを送信することができる。

【0112】

ＰＥＩがＵＥにより提供されない、または以前ＡＭＦから検索されない場合、ＡＭＦがＰＥＩを検索するためにＩｄｅｎｔｉｔｙ Ｒｅｑｕｅｓｔメッセージが送信される。

【0113】

１２）前記新しいＡＭＦは、ＭＥ識別子を検査する。

【0114】

１３）後述する過程１４が実行されると、前記新しいＡＭＦは、ＳＵＰＩに基づいてＵＤＭを選択する。

【0115】

１４）最終登録以後にＡＭＦが変更され、またはＡＭＦでＵＥに対する有効な加入コンテキストがない、またはＵＥがＡＭＦで有効なコンテキストを参照しないＳＵＰＩを提供すると、新しいＡＭＦは、位置更新（Ｕｐｄａｔｅ Ｌｏｃａｔｉｏｎ）手順を開始する。または、ＵＤＭが以前ＡＭＦに対する位置取消（Ｃａｎｃｅｌ Ｌｏｃａｔｉｏｎ）を開始する場合にも開始される。以前ＡＭＦは、ＭＭコンテキストを廃棄して可能な全てのＳＭＦ（ら）に通知し、新しいＡＭＦは、ＡＭＦ関連加入データをＵＤＭから得た後にＵＥに対するＭＭコンテキストを生成する。

【0116】

ネットワークスライシングが使われる場合、ＡＭＦは、要求されたＮＳＳＡＩ、ＵＥ加入及びローカル政策に基づいて許容されたＮＳＳＡＩを取得する。ＡＭＦが許容されたＮＳＳＡＩをサポートするのに適しない場合、登録要求を再びルーティングする。

【0117】

１５）前記新しいＡＭＦは、ＳＵＰＩに基づいてＰＣＦを選択することができる。

【0118】

１６）前記新しいＡＭＦは、ＵＥ Ｃｏｎｔｅｘｔ Ｅｓｔａｂｌｉｓｈｍｅｎｔ ＲｅｑｕｅｓｔメッセージをＰＣＦに送信する。前記ＡＭＦは、ＰＣＦにＵＥに対する運営者政策を要求することができる。

【0119】

１７）前記ＰＣＦは、ＵＥ Ｃｏｎｔｅｘｔ Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ａｃｋｎｏｗｌｅｄｇｅｄメッセージを前記新しいＡＭＦに送信する。

【0120】

１８）前記新しいＡＭＦは、ＳＭＦにＮ１１要求メッセージを送信する。

【0121】

具体的に、ＡＭＦが変更されると、新しいＡＭＦは、各ＳＭＦにＵＥをサービスする新しいＡＭＦを通知する。ＡＭＦは、利用可能なＳＭＦ情報でＵＥからのＰＤＵセッション状態を検証する。ＡＭＦが変更された場合、使用可能なＳＭＦ情報が以前ＡＭＦから受信される。新しいＡＭＦは、ＵＥで活性化されないＰＤＵセッションと関連したネットワークリソースを解除するようにＳＭＦに要求することができる。

【0122】

１９）前記新しいＡＭＦは、Ｎ１１応答メッセージをＳＭＦに送信する。

【0123】

２０）前記以前ＡＭＦは、ＵＥ Ｃｏｎｔｅｘｔ Ｔｅｒｍｉｎａｔｉｏｎ ＲｅｑｕｅｓｔメッセージをＰＣＦに送信する。

【0124】

前記以前ＡＭＦがＰＣＦでＵＥコンテキストが設定されるように以前に要求した場合、前記以前ＡＭＦは、ＰＣＦでＵＥコンテキストを削除させることができる。

【0125】

２１）前記ＰＣＦは、以前ＡＭＦにＵＥ Ｃｏｎｔｅｘｔ Ｔｅｒｍｉｎａｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信することができる。

【0126】

２２）前記新しいＡＭＦは、登録受諾メッセージをＵＥに送信する。前記登録受諾メッセージは、臨時ユーザＩＤ、登録領域、移動性制限、ＰＤＵセッション状態、ＮＳＳＡＩ、定期登録アップデートタイマ及び許容されたＭＩＣＯモードを含むことができる。

【0127】

前記ＡＭＦが新しい臨時ユーザＩＤを割り当てる場合、臨時ユーザＩＤが前記登録受諾メッセージ内にさらに含まれる。移動性制限がＵＥに適用される場合、移動性制限を指示する情報が前記登録受諾メッセージ内に追加的に含まれる。ＡＭＦは、ＵＥに対するＰＤＵセッション状態を示す情報を登録受諾メッセージ内に含ませることができる。ＵＥは、受信されたＰＤＵセッション状態で活性と表示されないＰＤＵセッションと関連した任意の内部リソースを除去することができる。ＰＤＵセッション状態情報がＲｅｇｉｓｔｒａｔｉｏｎ Ｒｅｑｕｅｓｔにある場合、ＡＭＦは、ＵＥにＰＤＵセッション状態を示す情報を前記登録受諾メッセージ内に含ませることができる。

【0128】

２３）前記ＵＥは、前記新しいＡＭＦに登録完了メッセージを送信する。

【0129】

＜ＰＤＵセッション確立手順＞

【0130】

ＰＤＵセッション確立手順は、下記のように二つの類型のＰＤＵセッション確立手順が存在できる。

【0131】

−ＵＥが開始するＰＤＵセッション確立手順

【0132】

−ネットワークが開始するＰＤＵセッション確立手順。そのために、ネットワークは、装置トリガメッセージをＵＥのアプリケーション（ら）に送信できる。

【0133】

図８は、例示的なＰＤＵセッション確立手順を示す信号流れ図である。

【0134】

図８に示す手順は、図７に示す登録手順によって、ＵＥがＡＭＦ上に既に登録したと仮定する。したがって、ＡＭＦは、既にＵＤＭからユーザ加入データを取得したと仮定する。

【0135】

１）ＵＥは、ＡＭＦにＮＡＳメッセージを送信する。前記メッセージは、Ｓ−ＮＳＳＡＩ、ＤＮＮ、ＰＤＵセッションＩＤ、要求タイプ、Ｎ１ ＳＭ情報などを含むことができる。

【0136】

新しいＰＤＵセッションを確立するために、ＵＥは、新しいＰＤＵセッションＩＤを生成することができる。

【0137】

ＵＥは、ＰＤＵセッション確立要求メッセージをＮ１ ＳＭ情報内に含ませたＮＡＳメッセージを送信することによってＵＥにより開始されるＰＤＵセッション確立手順を開始することができる。前記ＰＤＵセッション確立要求メッセージは、要求タイプ、ＳＳＣモード、プロトコル構成オプションを含むことができる。

【0138】

ＰＤＵセッション確立が新しいＰＤＵセッションを設定するためのものである場合、要求タイプは“初期要求”を示す。しかし、３ＧＰＰアクセスと非３ＧＰＰアクセスとの間の既存ＰＤＵセッションが存在する場合、前記要求タイプは、“既存ＰＤＵセッション”を示すことができる。

【0139】

前記ＵＥにより送信されるＮＡＳメッセージは、ＡＮによりＮ２メッセージ内にカプセル化される。前記Ｎ２メッセージは、ＡＭＦに送信され、ユーザ位置情報及びアクセス技術タイプ情報を含むことができる。

【0140】

−Ｎ１ ＳＭ情報は、外部ＤＮによるＰＤＵセッション認証に対する情報が含まれたＳＭ ＰＤＵ ＤＮ要求コンテナを含むことができる。

【0141】

２）ＡＭＦは、メッセージが前記要求タイプが“初期要求”を示す場合、そして前記ＰＤＵセッションＩＤがＵＥの既存ＰＤＵセッションのために使われない場合、新しいＰＤＵセッションに対する要求に該当すると決定できる。

【0142】

ＮＡＳメッセージがＳ−ＮＳＳＡＩを含まない場合、ＡＭＦは、ＵＥ加入によって要求されたＰＤＵセッションに対するデフォルトＳ−ＮＳＳＡＩを決定することができる。ＡＭＦは、ＰＤＵセッションＩＤとＳＭＦのＩＤとを関連付けられて格納することができる。

【0143】

３）ＡＭＦは、ＳＭ要求メッセージをＳＭＦに送信する。前記ＳＭ要求メッセージは、加入者永久ＩＤ、ＤＮＮ、Ｓ−ＮＳＳＡＩ、ＰＤＵセッションＩＤ、ＡＭＦ ＩＤ、Ｎ１ ＳＭ情報、ユーザ位置情報、アクセス技術類型を含むことができる。前記Ｎ１ ＳＭ情報は、ＰＤＵセッションＩＤ、ＰＤＵセッション確立要求メッセージを含むことができる。

【0144】

ＡＭＦ ＩＤは、ＵＥをサービスするＡＭＦを識別するために使われる。Ｎ１ ＳＭ情報は、ＵＥから受信されたＰＤＵセッション確立要求メッセージを含むことができる。

【0145】

４ａ）ＳＭＦは、加入者データ要求メッセージをＵＤＭに送信する。前記加入者データ要求メッセージは、加入者永久ＩＤ、ＤＮＮを含むことができる。

【0146】

前記過程３における要求タイプが“既存ＰＤＵセッション”を示す場合、ＳＭＦは、該当要求が３ＧＰＰアクセスと非３ＧＰＰアクセスとの間のハンドオーバに起因したと決定する。ＳＭＦは、ＰＤＵセッションＩＤに基づいて既存ＰＤＵセッションを識別することができる。

【0147】

ＳＭＦがまだＤＮＮと関連したＵＥに対するＳＭ関連加入データを検索しない場合、ＳＭＦは、加入データを要求することができる。

【0148】

４ｂ）ＵＤＭは、加入データ応答メッセージをＳＭＦに送信できる。

【0149】

加入データには認証された要求タイプ、認証されたＳＳＣモード、基本ＱｏＳプロファイルに対する情報が含まれる。

【0150】

ＳＭＦは、ＵＥ要求がユーザ加入及びローカル政策を守るかどうかを確認することができる。または、ＳＭＦは、ＡＭＦにより伝達されたＮＡＳ ＳＭシグナリング（関連ＳＭ拒否原因を含む）を介してＵＥ要求を拒絶し、ＳＭＦは、ＡＭＦにＰＤＵセッションＩＤが解除されたと見なされるべきことを知らせる。

【0151】

５）ＳＭＦは、ＵＰＦを介してＤＮにメッセージを送信する。

【0152】

具体的に、ＳＭＦがＰＤＵセッション確立を承認／認証しなければならない場合、ＳＭＦは、ＵＰＦを選択してＰＤＵをトリガする。

【0153】

ＰＤＵセッション確立認証／権限付与が失敗すると、ＳＭＦは、ＰＤＵセッション確立手順を終了してＵＥに拒絶を知らせる。

【0154】

６ａ）動的ＰＣＣが配布されると、ＳＭＦはＰＣＦを選択する。

【0155】

６ｂ）ＳＭＦは、ＰＤＵセッションに対する基本ＰＣＣ規則を得るためにＰＣＦ側にＰＤＵ−ＣＡＮセッション確立を開始することができる。過程３における要求タイプが“既存ＰＤＵセッション”を示す場合、ＰＣＦは、その代わりにＰＤＵ−ＣＡＮセッション修正を開始することができる。

【0156】

７）過程３の要求タイプが“初期要求”を示す場合、ＳＭＦは、ＰＤＵセッションに対するＳＳＣモードを選択する。過程５が実行されない場合、ＳＭＦは、ＵＰＦも選択できる。要求タイプＩＰｖ４またはＩＰｖ６の場合、ＳＭＦは、ＰＤＵセッションに対するＩＰアドレス／プレフィクス（ｐｒｅｆｉｘ）を割り当てることができる。

【0157】

８）動的ＰＣＣが配置され、ＰＤＵ−ＣＡＮセッション確立がまだ完了しない場合、ＳＭＦは、ＰＤＵ−ＣＡＮセッション開始を開始することができる。

【0158】

９）要求タイプが“初期要求”を示して過程５が実行されない場合、ＳＭＦは、選択されたＵＰＦを使用してＮ４セッション確立手順を開始し、または選択したＵＰＦを使用してＮ４セッション修正手順を開始することができる。

【0159】

９ａ）ＳＭＦは、ＵＰＦにＮ４セッション確立／修正要求メッセージを送信する。そして、前記ＳＭＦは、ＰＤＵセッションに対してＵＰＦに設置されるパケット探知、施行及び報告規則を提供することができる。ＳＭＦがＣＮトンネル情報を割り当てる場合、ＣＮトンネル情報がＵＰＦに提供される。

【0160】

９ｂ）ＵＰＦは、Ｎ４セッション確立／修正応答メッセージを送信することによって、応答できる。ＣＮトンネル情報がＵＰＦにより割り当てられる場合、ＣＮトンネル情報がＳＭＦに提供される。

【0161】

１０）前記ＳＭＦは、ＳＭ応答メッセージをＡＭＦに送信する。前記メッセージは、原因、Ｎ２ ＳＭ情報、Ｎ１ ＳＭ情報を含むことができる。前記Ｎ２ ＳＭ情報は、ＰＤＵセッションＩＤ、ＱｏＳプロファイル、ＣＮトンネル情報を含むことができる。前記Ｎ１ ＳＭ情報は、ＰＤＵセッション確立受諾メッセージを含むことができる。前記ＰＤＵセッション確立受諾メッセージは、許可されたＱｏＳ規則、ＳＳＣモード、Ｓ−ＮＳＳＡＩ、割り当てられたＩＰｖ４アドレスを含むことができる。

【0162】

Ｎ２ ＳＭ情報は、ＡＭＦがＲＡＮに伝達しなければならない情報として下記のようなもの等を含むことができる。

【0163】

−ＣＮトンネル情報：これはＰＤＵセッションに該当するＮ３トンネルのコアネットワークアドレスに該当する。

【0164】

−ＱｏＳプロファイル：これはＲＡＮにＱｏＳパラメータとＱｏＳ流れ識別子との間のマッピングを提供するために使われる。

【0165】

−ＰＤＵセッションＩＤ：これはＵＥに対するＡＮシグナリングによりＵＥに対するＡＮリソースとＰＤＵセッションとの間の関連をＵＥに示すために使われる。

【0166】

一方、Ｎ１ ＳＭ情報は、ＡＭＦがＵＥに提供しなければならないＰＤＵセッション受諾メッセージを含む。

【0167】

多重ＱｏＳ規則は、ＰＤＵセッション確立受諾メッセージ内のＮ１ ＳＭ情報及びＮ２ ＳＭ情報内に含まれる。

【0168】

−また、ＳＭ応答メッセージは、ＰＤＵセッションＩＤ及びＡＭＦがどのようなターゲットＵＥだけでなく、ＵＥのためにどのようなアクセスが使われなければならないかを決定することができるようにする情報を含む。

【0169】

１１）ＡＭＦは、ＲＡＮにＮ２ ＰＤＵセッション要求メッセージを送信する。前記メッセージは、Ｎ２ ＳＭ情報、ＮＡＳメッセージを含むことができる。前記ＮＡＳメッセージは、ＰＤＵセッションＩＤ、ＰＤＵセッション確立受諾メッセージを含むことができる。

【0170】

ＡＭＦは、ＰＤＵセッションＩＤ及びＰＤＵセッション確立受諾メッセージを含むＮＡＳメッセージを送信することができる。また、ＡＭＦは、ＳＭＦから受信Ｎ２ ＳＭ情報をＮ２ ＰＤＵセッション要求メッセージ内に含ませてＲＡＮに送信する。

【0171】

１２）ＲＡＮは、ＳＭＦから受信された情報と関連したＵＥとの特定シグナリング交換をすることができる。

【0172】

また、ＲＡＮは、ＰＤＵセッションに対してＲＡＮ Ｎ３トンネル情報を割り当てる。

【0173】

ＲＡＮは、過程１０で提供されたＮＡＳメッセージをＵＥに伝達する。前記ＮＡＳメッセージは、ＰＤＵセッションＩＤ、Ｎ１ ＳＭ情報を含むことができる。前記Ｎ１ ＳＭ情報は、ＰＤＵセッション確立受諾メッセージを含むことができる。

【0174】

ＲＡＮは、必要なＲＡＮリソースが設定され、ＲＡＮトンネル情報の割当が成功裏になされる場合にのみＮＡＳメッセージをＵＥに送信する。

【0175】

１３）ＲＡＮは、ＡＭＦにＮ２ ＰＤＵセッション応答メッセージを送信する。前記メッセージは、ＰＤＵセッションＩＤ、原因、Ｎ２ ＳＭ情報を含むことができる。前記Ｎ２ ＳＭ情報は、ＰＤＵセッションＩＤ、（ＡＮ）トンネル情報、許容／拒否されたＱｏＳプロファイル目録を含むことができる。

【0176】

−ＲＡＮトンネル情報は、ＰＤＵセッションに該当するＮ３トンネルのアクセスネットワークアドレスに該当できる。

【0177】

１４）ＡＭＦは、ＳＭ要求メッセージをＳＭＦに送信できる。前記ＳＭ要求メッセージは、Ｎ２ ＳＭ情報を含むことができる。ここで、前記ＡＭＦは、ＲＡＮで受信したＮ２ ＳＭ情報をＳＭＦに伝達する。

【0178】

１５ａ）前記ＰＤＵセッションに対するＮ４セッションが既に設定されない場合、ＳＭＦは、ＵＰＦと共にＮ４セッション確立手順を開始することができる。そうでない場合、ＳＭＦは、ＵＰＦを使用してＮ４セッション修正手順を開始することができる。ＳＭＦは、ＡＮトンネル情報とＣＮトンネル情報を提供することができる。ＣＮトンネル情報は、ＳＭＦが過程８でＣＮトンネル情報を選択した場合にのみ提供すべきである。

【0179】

１５ｂ）前記ＵＰＦは、ＳＭＦにＮ４セッション確立／修正応答メッセージを送信することができる。

【0180】

１６）ＳＭＦは、ＳＭ応答メッセージをＡＭＦに送信できる。この過程が終われると、ＡＭＦは、関連イベントをＳＭＦに伝達できる。ＲＡＮトンネル情報が変更され、またはＡＭＦが再配置されるハンドオーバ時に発生する。

【0181】

１７）ＳＭＦは、ＵＰＦを介してＵＥに情報を送信する。具体的に、ＰＤＵ Ｔｙｐｅ ＩＰｖ６の場合、ＳＭＦは、ＩＰｖ６ Ｒｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔを生成し、これをＮ４とＵＰＦを介してＵＥに送信できる。

【0182】

１８）ＰＤＵセッション確立要求が３ＧＰＰアクセスと非３ＧＰＰアクセスとの間のハンドオーバに起因した場合、即ち、要求タイプが“既存ＰＤＵセッション”に設定されると、ＳＭＦは、ソースアクセス（３ＧＰＰまたは非３ＧＰＰアクセス）を介してユーザ平面を解除する。

【0183】

１９）ＳＭＦのＩＤがＤＮＮ加入コンテキストのＵＤＭにより過程４ｂに含まれない場合、ＳＭＦは、ＳＭＦアドレス及びＤＮＮを含んで“ＵＤＭ＿Ｒｅｇｉｓｔｅｒ ＵＥ ｓｅｒｖｉｎｇ ＮＦサービス”を呼び出すことができる。ＵＤＭは、ＳＭＦのＩＤ、アドレス及び関連ＤＮＮを格納することができる。

【0184】

手順中にＰＤＵセッション確立が成功裏になされない場合、ＳＭＦはＡＭＦに知らせる。

【0185】

＜信頼されない非３ＧＰＰアクセスを介した登録手順＞

【0186】

本節ではＵＥが信頼されない非３ＧＰＰアクセスネットワークを介して５ＧＣネットワークに登録する手順に対して説明する。

【0187】

図９は、信頼されない非３ＧＰＰアクセスを介した登録手順を示す信号流れ図である。

【0188】

１）ＵＥは、信頼されない非３ＧＰＰアクセスネットワークに接続し、ＩＰアドレスの割当を受ける。この過程で、任意の非３ＧＰＰ認証方法が使われる。ＵＥが５ＧＣネットワークにアタッチ（ａｔｔａｃｈ）すると決定すると、ＵＥは、５Ｇ ＰＬＭＮでＮ３ＩＷＦのＩＰアドレスを探す。

【0189】

２）ＵＥは、ＩＫＥｖ２シグナリング手順を始めてＮ３ＩＷＦと共にＩＰｓｅｃ ＳＡを設定する。２ａ過程後に全ての後続ＩＫＥｖ２メッセージが暗号化されて完全性が保障される。Ｎ３ＩＷＦは、ＥＡＰ認証者として動作し、ＵＥのネットワークアクセス識別子（ＮＡＩ）を検索する。過程２ｄで、ＵＥは、登録タイプ、永久ユーザＩＤまたは臨時ユーザＩＤ及びネットワークスライスのような登録パラメータとＮＳＳＡＩを含む３ＧＰＰ−固有なＶＩＤ（Ｖｅｎｄｏｒ Ｉｄ）ペイロードを伝達することができる。ＵＥが３ＧＰＰアクセスを介してＰＬＭＮに既に登録されており、過程１で選択されたＮ３ＩＷＦがＰＬＭＮに位置しない場合、ＵＥは、自分の臨時ＩＤを登録パラメータ内に含ませない。

【0190】

３）Ｎ３ＩＷＦは、受信された登録パラメータとローカル政策に基づいてＡＭＦを選択することができる。その後、ＵＥの代わりに登録要求メッセージを生成し、Ｎ２インターフェースを介してＡＭＦに送信できる。前記登録要求メッセージは、登録パラメータ、ＥＡＰ−ＲＥＳ／Ｉｄｅｎｔｉｔｙを含むことができる。前記登録要求メッセージは、Ｎ２メッセージ内にカプセル化される。前記Ｎ２メッセージは、“信頼されない非３ＧＰＰアクセス”を示すアクセスタイプを含むことができる。ＵＥの臨時ユーザＩＤが登録パラメータに含まれている場合、ＡＭＦは、他のＡＭＦからＵＥのＳＵＰＩ及びＭＭ Ｃｏｎｔｅｘｔを要求することができる。

【0191】

４）ＡＭＦは、ＡＵＳＦを選択し、ＡＵＳＦにＡｕｔｈ＿Ｒｅｑメッセージを送ることによって、ＡＵＳＦにＵＥの認証を要求することができる。前記メッセージは、ＥＡＰ−ＲＥＳ／Ｉｄｅｎｔｉｔｙを含むことができる。ＡＵＳＦは、ＥＡＰサーバとして動作しなければならず、ＵＥを認証するためにＥＡＰ方法を選択しなければならない。ＵＥ加入情報及びＵＥのＮＡＩに含まれている情報に基づいて決定される。ＡＵＳＦは、ＵＤＭからＵＥ加入情報を取得することができる。

【0192】

５）ＥＡＰベースの相互認証手順は、ＵＥとＡＵＳＦとの間で実行する。選択されたＥＡＰ認証方法によって、ＵＥとＡＵＳＦとの間に多様なＥＡＰ要求／応答メッセージが送信される。ＵＥとＮ３ＩＷＦとの間でＥＡＰメッセージは、ＩＫＥｖ２メッセージ内にカプセル化される。Ｎ３ＩＷＦとＡＭＦとの間でＥＡＰメッセージは、ＮＡＳ認証要求／応答メッセージ内にカプセル化され、これは順序にＮ２ ＮＡＳ ＤＬ／ＵＬ送信メッセージにカプセル化される。ＡＭＦとＡＵＳＦとの間でＥＡＰメッセージは、Ａｕｔｈ＿Ｒｅｑ／Ｒｅｓメッセージ内にカプセル化される。

【0193】

６ａ）ＥＡＰベースの相互認証手順が成功裏に完了すると、ＡＵＳＦは、Ａｕｔｈ＿ＲｅｓメッセージをＡＭＦに送信する。前記メッセージは、ＥＡＰ成功、セキュリティキーを含むことができる。セキュリティキーには、ＮＡＳセキュリティキーと、セキュリティキー（Ｎ３ＩＷＦ）を生成するためにＡＭＦで使用する一つ以上のマスターセッションキーと、が含まれる。

【0194】

６ｂ）ＡＭＦは、Ｎ３ＩＷＦにＤＬ ＮＡＳ Ｔｒａｎｓｐｏｒｔメッセージを送信する。このメッセージにはＥＡＰ成功メッセージ、Ｎ３ＩＷＦのセキュリティキー及びＮＡＳセキュリティモード命令（ＳＭＣ）要求が含まれる。この過程後、Ｎ３ＩＷＦは、ＵＥ身元、関連Ｎ２連結などのようなＵＥ特定情報を格納するＵＥ Ｃｏｎｔｅｘｔを生成することができる。

【0195】

６ｃ−６ｄ）Ｎ３ＩＷＦは、ＩＫＥ＿ＡＵＴＨ応答メッセージをＵＥに送信できる。それによって、ＵＥとＮ３ＩＷＦとの間でＩＰｓｅｃ ＳＡの設定が完了する。このＩＰｓｅｃ ＳＡ（“ｓｉｇｎａｌｉｎｇ ＩＰｓｅｃ ＳＡ”という）は、ＵＥとＮ３ＩＷＦとの間にＮＡＳメッセージを安全に送信する時に使われる。ＮＡＳメッセージは、ＩＰｓｅｃを介してＧＲＥにカプセル化される。過程６ｃ以後に、ＩＫＥｖ２メッセージは、シグナリングＩＰｓｅｃ ＳＡの設定を完了するために送信される。

【0196】

７）Ｎ３ＩＷＦは、設定されたシグナリングＩＰｓｅｃ ＳＡを介して過程６ｂでＡＭＦから受信されたＮＡＳ ＳＭＣ要求をＵＥに送信できる。ＵＥは、ＮＡＳ ＳＭＣ完了メッセージを送信する。これはＮ３ＩＷＦによりＮ２ ＵＬ ＮＡＳ送信メッセージ内で含まれてＡＭＦに伝達される。

【0197】

８）ＡＭＦは、Ｎ２初期コンテキスト設定要求メッセージ内にＮＡＳ登録承認メッセージを含ませてＮ３ＩＷＦに送信する。Ｎ２初期コンテキスト設定要求は、設定されたシグナリングＩＰｓｅｃ ＳＡを介してＵＥに伝達される。最後に、ＵＥは、Ｎ３ＩＷＦによりＡＭＦにフォワーディングされなければならないＮＡＳ登録完了メッセージをＮ２初期コンテキスト設定応答メッセージ内に含ませて送信する。

【0198】

＜信頼されない非３ＧＰＰアクセスを介したＵＥのＰＤＵセッション確立手順＞

【0199】

本節では信頼されない非３ＧＰＰアクセスネットワークを介してＰＤＵセッションを確立する手順に対して説明する。

【0200】

図１０は、信頼されない非３ＧＰＰアクセスを介したＵＥのＰＤＵセッション確立手順を示す流れ図である。

【0201】

まず、ＵＥは、信頼できない非３ＧＰＰアクセスネットワークを介して５ＧＣネットワークに登録手順を実行完了したと仮定する。

【0202】

１）ＵＥは、ＡＭＦにＰＤＵセッション確立要求メッセージを送信する。前記ＰＤＵセッション確立要求メッセージは、図８を参照して詳述したように、ＰＤＵセッションのＩＤ、要求タイプ、ＳＳＣモード、プロトコル構成オプションを含むことができる。前記ＰＤＵセッション確立要求メッセージは、ＮＡＳ信号のために設定されたＩＰｓｅｃ ＳＡを介してＮ３ＩＷＦに送信される。前記Ｎ３ＩＷＦは、前記メッセージを５ＧＣネットワークのＡＭＦに伝達する。

【0203】

２ａ）３ＧＰＰアクセスを介したＰＤＵセッション確立手順が実行される。

【0204】

２ｂ）ＡＭＦは、Ｎ３ＩＷＦにＰＤＵセッションに対するアクセスリソースを設定するためにＮ２ ＰＤＵセッション確立要求メッセージを送信する。前記ＰＤＵセッション確立要求メッセージは、図８を参照して詳述したように、ＰＤＵセッションのＩＤ、要求タイプ、ＳＳＣモード、プロトコル構成オプションを含むことができる。また、前記メッセージは、要求されたＰＤＵセッションの事前許可されたＱｏＳ規則のＱｏＳプロファイルを含むことができる。Ｑ−タイプＱｏＳ規則の場合、Ｎ２ ＰＤＵセッション要求メッセージは、このようなＱｏＳプロファイルに対するＱｏＳパラメータを含む。また、Ｎ２ ＰＤＵセッション要求メッセージは、ＵＥにフォワーディングされなければならないＰＤＵセッション受諾活性化メッセージを含む。

【0205】

３）以前ステップで受信したＱｏＳプロファイルに基づいてそして政策及び設定に基づいて、Ｎ３ＩＷＦは、確立するＩＰｓｅｃ ｃｈｉｌｄ ＳＡ個数と各ＩＰｓｅｃ ｃｈｉｌｄ ＳＡと関連したＱｏＳプロファイルを決定する。例えば、Ｎ３ＩＷＦは、ＩＰｓｅｃ ｃｈｉｌｄ ＳＡを設定し、全てのＱｏＳプロファイルをＩＰｓｅｃ ｃｈｉｌｄ ＳＡと関連させることができる。この場合、ＰＤＵセッションの全てのＱｏＳフローは、一つのＩＰｓｅｃ ｃｈｉｌｄ ＳＡを介して送信される。

【0206】

４ａ）Ｎ３ＩＷＦは、第１のＩＰｓｅｃ ｃｈｉｌｄ ＳＡを確立するために、ＩＫＥ ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求メッセージをＵＥに送信する。前記要求メッセージは、３ＧＰＰ−固有なＶＩＤペイロードを含むことができる。前記ＶＩＤペイロードは、ｃｈｉｌｄ ＳＡと関連したＱｏＳプロファイル、ｃｈｉｌｄ ＳＡと関連したＰＤＵセッションのＩＤ、そしてｃｈｉｌｄ ＳＡと関連したＤＳＣＰ値を含むことができる。ＩＫＥ Ｃｒｅａｔｅ＿Ｃｈｉｌｄ＿ＳＡ要求メッセージは、ＳＡペイロードＮ３ＩＷＦ及びＵＥのためのＴＳ（Ｔｒａｆｆｉｃ Ｓｅｌｅｃｔｏｒ）のような他の情報を含むことができる。

【0207】

４ｂ）ＵＥが新しいＩＰｓｅｃ ｃｈｉｌｄ ＳＡを受諾すると、ＵＥは、ＩＫＥ Ｃｒｅａｔｅ＿Ｃｈｉｌｄ＿ＳＡ応答メッセージを送信する。ＩＰｓｅｃ ｃｈｉｌｄ ＳＡを確立する間に、ＵＥにＩＰアドレスにまだ割り当てられない。

【0208】

４ｃ−４ｄ）過程３で、Ｎ３ＩＷＦがＰＤＵセッションに対して多様なＩＰｓｅｃ ｃｈｉｌｄ ＳＡを確立すると決定した場合、追加ＩＰｓｅｃ ｃｈｉｌｄ ＳＡが確立される。前記追加ＩＰｓｅｃ ｃｈｉｌｄ ＳＡは、一つ以上のＱｏＳプロファイルと各々連結される。

【0209】

５）全てのＩＰｓｅｃ ｃｈｉｌｄ ＳＡが確立されると、Ｎ３ＩＷＦは、ステップ２ｂで受信したＰＤＵセッション確立受諾メッセージをＮＡＳシグナリングのためのＩＰｓｅｃ ＳＡを介してＵＥに伝達する。

【0210】

６）Ｎ３ＩＷＦは、ＡＭＦにＮ２ ＰＤＵセッション要求確認（Ａｃｋ）メッセージを送信する。

【0211】

７）３ＧＰＰアクセスを介したＰＤＵセッション確立手順が実行される。

【0212】

８）ユーザ平面で、

【0213】

ＵＥがＵＬ ＰＤＵを送信する場合、ＵＥは（ＰＤＵにセッションのＱｏＳ規則を使用して）前記ＵＬ ＰＤＵと関連したＱｏＳプロファイルを決定する。そして、前記ＵＥは、前記ＵＬ ＰＤＵをＧＲＥパケット内にカプセル化した後、前記ＱｏＳプロファイルと関連したＩＰｓｅｃ ｃｈｉｌｄ ＳＡを介してＮ３ＩＷＦに送信できる。ＧＲＥパケットのヘッダは、ＵＬ ＰＤＵと関連したＱｏＳプロファイルを送信する。

【0214】

−Ｎ３ＩＷＦは、Ｎ３を介してＤＬ ＰＤＵを受信すると、Ｎ３ＩＷＦは、ＩＰＳｅｃ ｃｈｉｌｄ ＳＡを決定するためにＱｏＳマーキングとＰＤＵセッションの識別子を使用する。Ｎ３ＩＷＫは、ＧＲＥパケット内にＤＬ ＰＤＵをカプセル化し、ＱｏＳマーキングをＧＲＥパケットのヘッダに複写する。したがって、Ｎ３ＩＷＦは、ＵＥにより使われるＲＩＦＩ（Ｒｅｆｌｅｃｔｉｖｅ ＱｏＳ Ｉｎｄｉｃａｔｏｒ）をＧＲＥヘッダに含むことができる。

【0215】

＜３ＧＰＰアクセスと信頼されない非３ＧＰＰアクセスとの間にＰＤＵセッションハンドオーバ手順＞

【0216】

図１１ａは、信頼されない非３ＧＰＰアクセスから３ＧＰＰアクセスへのＰＤＵセッションハンドオーバ手順を示す。

【0217】

図１１ａを参照して分かるように、ＵＥが３ＧＰＰアクセスに登録されていない場合、ＵＥは、登録手順を実行する。

【0218】

そして、ＵＥは、ＰＤＵセッション確立手順を実行する。

【0219】

図１１ｂは、３ＧＰＰアクセスから信頼されない非３ＧＰＰアクセスへのＰＤＵセッションハンドオーバ手順を示す。

【0220】

図１１ｂを参照して分かるように、ＵＥが信頼されない非３ＧＰＰアクセスに登録されていない場合、ＵＥは登録手順を実行する。

【0221】

そして、ＵＥは、ＰＤＵセッション確立手順を実行する。

【0222】

＜本明細書の開示＞

【0223】

ローミング状況で、ＵＥは、ネットワークにＰＤＵセッション確立要求メッセージを送信し、これに対する応答を受けると、ＰＤＵセッションが確立されたことを知ることができる。しかし、ＵＥは、ＰＤＵセッションがＬＢＯ（Ｌｏｃａｌ Ｂｒｅａｋｏｕｔ）方式で確立されたか、またはＨＲ（Ｈｏｍｅ Ｒｏｕｔｅｄ）方式で確立されたかを知ることができない。３ＧＰＰと非３ＧＰＰとの間にハンドオーバを実行するためには基本的にそれぞれの全ての同じＳＭＦが選択されて同じＵＰＦ／ＩＰアドレスの割当を受けることが必要である。もし、ローミング状況でＵＥが３ＧＰＰアクセスを介してＬＢＯ方式でＰＤＵセッションが確立した後、非３ＧＰＰにハンドオーバするためには非３ＧＰＰアクセスでもＬＢＯ方式でＰＤＵセッションが作られなければならない。しかし、ハンドオーバが考慮されずに、ＰＤＵセッションが生成された場合、問題が発生できる。例えば、非３ＧＰＰアクセスのためのＮ３ＩＷＦの選択時、ＵＥは、自分にサービスを提供しているＶＰＬＭＮ内のＮ３ＩＷＦでなくＨＰＬＭＮにあるＮ３ＩＷＦを選択することができる。この場合、３ＧＰＰアクセスではＬＢＯ方式でＰＤＵセッションが生成され、非３ＧＰＰアクセスでは非ローミング方式でＰＤＵセッションが作られることによって、ハンドオーバが実行できない状況が発生される。しかし、ＵＥは、実際ハンドオーバが成功できるかどうかを知ることができないため、ハンドオーバを試みることができ、この場合、不要なシグナリングが発生するようになる。

【0224】

したがって、本明細書の開示は、このような問題点を解決するための方案を提示する。

【0225】

Ｉ．第１の開示：ＰＤＵセッションを確立しながら、該当ＰＤＵセッションがＬＢＯ方式で確立されるか、またはＨＲ方式で確立されるかを知らせる方案

【0226】

現在はＵＥがＰＤＵセッションを作っても該当ＰＤＵセッションがＬＢＯ方式で作られたか、またはＨＲ方式で作られたかを知らない。第１の開示ではネットワークノード（例えば、ＳＭＦ）がＰＤＵセッション確立受諾（ＰＤＵ Ｓｅｓｓｉｏｎ Ｅｓｔａｂｌｉｓｈｍｅｎｔ Ａｃｃｅｐｔ）メッセージ内にＰＤＵセッションがどのような方式で作られたかを知らせる情報を含ませることを提案する。ＵＥは、３ＧＰＰアクセス／非３ＧＰＰアクセスを介して登録を実行する時、どのようなＰＬＭＮに登録されるかを知っているため、ＰＬＭＮ情報とＰＤＵセッションが確立のために使われた方式（即ち、ＬＢＯ方式またはＨＲ方式）を知るようになると、自体的にハンドオーバが（ＨＯ）が可能かどうかを判断することができる。

【0227】

ａ）まず、３ＧＰＰアクセスを介して先登録された場合

【0228】

−ＵＥは、非３ＧＰＰアクセスに登録する前にＮ３ＩＷＦ選択を実行する。前記選択過程によって選択されたＮ３ＩＷＦが３ＧＰＰアクセスと同じＰＬＭＮに位置すると決定され、登録が成功裏に完了した場合、ＵＥは、ＰＤＵセッションの確立のために使われた方式がＬＢＯ方式か、またはＨＯ方式かにかかわらず、ＰＤＵセッションがハンドオーバされると判断できる。

【0229】

−しかし、前記選択過程によって選択されたＮ３ＩＷＦが３ＧＰＰアクセスと異なるＰＬＭＮに位置したと決定され、そして登録が成功裏に完了した場合、ＵＥは、３ＧＰＰアクセスのＰＤＵセッションがＨＲ方式で確立された場合にのみ、ＰＤＵセッションがハンドオーバされると判断できる。

【0230】

ｂ）非３ＧＰＰアクセスを介して先登録された場合、

【0231】

−ＵＥが３ＧＰＰアクセスに登録する過程で、非３ＧＰＰアクセスのためのＮ３ＩＷＦが位置するＰＬＭＮと同じＰＬＭＮに成功裏に登録されたと知るようになった場合、ＵＥは、ＰＤＵセッションの確立のために使われた方式がＬＢＯ方式か、またはＨＯ方式かにかかわらず、ＰＤＵセッションがハンドオーバされると判断できる。

【0232】

−ＵＥが３ＧＰＰアクセスに登録する過程で、非３ＧＰＰのＮ３ＩＷＦが位置するＰＬＭＮと異なるＰＬＭＮに成功裏に登録されたと知るようになった場合、ＵＥは、非３ＧＰＰアクセスを介したＰＤＵセッションがＨＲ方式で確立された場合にのみ、ＰＤＵセッションがハンドオーバされると判断できる。

【0233】

一方、ＳＭＦは、ＨＯ方式か、またはＬＢＯ方式かを直接的に知らせる代わりに、ハンドオーバが可能であるということを示す情報またはインジケーション（例えば、ＨＯ ｉｎｄｉｃａｔｉｏｎ）を送信することができる。例えば、ＳＭＦは、ハンドオーバを介して生成されたＰＤＵセッションに対してハンドオーバが可能であるということを示すＨＯ ｉｎｄｉｃａｔｉｏｎを送信することができる。ＵＥがハンドオーバ可能であるということを示すインジケーションを受信すると、３ＧＰＰアクセスを介したＰＤＵセッションと非３ＧＰＰアクセスを介したＰＤＵセッションが互いに同じＰＬＭＮ内で確立されたか、または異なるＰＬＭＮ内で確立されたかにかかわらず、ハンドオーバを実行することができる。もし、前記情報（または、インジケーション）を受信することができない場合、３ＧＰＰアクセスを介したＰＤＵセッションと非３ＧＰＰアクセスを介したＰＤＵセッションが互いに同じＰＬＭＮ内で確立された場合にのみ、ＵＥは、ハンドオーバを実行することができる。

【0234】

図１２は、ＰＤＵセッションを確立する時、本明細書の第１の開示によって該当ＰＤＵセッションがＬＢＯ方式でまたはＨＲ方式で確立されたかを示す方案を示す流れ図である。

【0235】

図１２を参照すると、ＵＥは、ＰＤＵセッション確立要求メッセージをＡＭＦに送信する。前記ＰＤＵセッション確立要求メッセージは、図８及び図１０を参照して詳述したように、ＰＤＵセッションのＩＤ、要求タイプ、ＳＳＣモード、プロトコル構成オプションを含むことができる。

【0236】

過程１０で、ＳＭＦは、ＰＤＵセッション受諾メッセージをＵＥに送信しながら、ＰＤＵセッションがＨＲ方式で確立されたか、またはＬＢＯ方式で確立されたかを示す情報またはインジケーションを含ませて送信できる。または、前記ＳＭＦは、ハンドオーバが可能かどうかを知らせるインジケーション（例えば、ＨＯ Ｉｎｄｉｃａｔｉｏｎ）を含ませて送信できる。図１２の例示は、３ＧＰＰアクセスで手順を示すが、非３ＧＰＰアクセスでも同様に適用できる。

【0237】

II．第２の開示：登録過程中に、ＰＤＵセッションをハンドオーバさせることができるかどうかをＵＥに知らせる方案

【0238】

前述した第１の開示によると、ネットワークがＵＥにＰＤＵセッションがＬＢＯ方式で確立されたか、またはＨＲ方式で確立されたかを知らせなければならない。しかし、これはネットワークのトポロジー情報を提供することであるため、事業者が選好しない方案である。第２の開示では、第１の開示のような情報をＵＥに提供しない代りに、登録過程でＵＥにハンドオーバが可能であるという情報のみを知らせることを提案する。

【0239】

そのために、ＵＥは、ハンドオーバのために他のアクセスへの登録を実行する時、３ＧＰＰアクセスと非３ＧＰＰアクセスとの間のハンドオーバのために登録を実行することを知らせるインジケーションを伝達することができる。また、ＵＥは、前記インジケーション外に、ハンドオーバさせようとするＰＤＵセッションのＩＤも共に伝達できる。前記ＰＤＵセッションのＩＤを伝達することで、ＵＥは、どのようなＰＤＵセッションをハンドオーバさせるかを知らせることができる。

【0240】

また、ＡＭＦは、３ＧＰＰアクセスと非３ＧＰＰアクセスとの間のハンドオーバのために、ＵＥが登録手順を実行する場合、前記ＵＥから受信されたＰＤＵセッションＩＤに基づいてＵＤＭからＰＤＵセッション情報を取得する。そして、前記ＡＭＦは、前記ＵＤＭから取得されたＰＤＵセッション情報に基づいてハンドオーバさせようとするＰＤＵセッションＩＤを探り出す。前記ＰＤＵセッションＩＤとマッピングされるＰＤＵセッション情報をさがした場合、前記ＡＭＦは、コンテキスト情報に基づいて前記ＰＤＵセッションをハンドオーバさせるかどうかを判断する。そのために、ＳＭＦは、ＰＤＵセッションが作られる時、該当ＰＤＵセッションがＨＲ方式で確立されたか、またはＬＢＯ方式で確立されたかに対する情報をＵＤＭ内に格納することができる。即ち、図１２の過程１９で、ＳＭＦ情報とＰＤＵ情報を格納する時、該当ＰＤＵセッションがＨＲ方式で確立されたか、またはＬＢＯ方式で確立されたかに対する情報を共に格納することができる。

【0241】

一方、前述した通り、前記ＡＭＦは、ＰＤＵセッションＩＤとＳＭＦのＩＤを関連付けられて格納している。したがって、前記ＵＥから受信されたＰＤＵセッションＩＤが以前ＰＤＵセッションを指示する場合、前記ＡＭＦは、前記ＰＤＵセッションＩＤと関連付けられて格納されているＳＭＦのＩＤを探り出すことができる。ここで、ＳＭＦのＩＤは、ＰＬＭＮ ＩＤを含んで構成される。したがって、ＡＭＦは、ＳＭＦのＩＤから抽出されるＰＬＭＮ ＩＤに基づいてＡＭＦとＳＭＦが同じＰＬＭＮにあるかまたは異なるＰＬＭＮにあるかを知ることができる。もし、３ＧＰＰアクセスでローミング中であるＵＥが非３ＧＰＰアクセスでＨＰＬＭＮに連結されている状況に３ＧＰＰアクセスＰＤＵセッションを非３ＧＰＰにハンドオーバ要求する状況で、前記ＡＭＦと前記ＳＭＦが同じＰＬＭＮ内に位置する場合、該当ＰＤＵセッションがＨＲ方式で確立されたと判断できる。この場合、前記ＡＭＦは、ハンドオーバが可能であると判断できる。また、前記ＡＭＦと前記ＳＭＦが全てＨＰＬＭＮ内に位置する場合、該当ＰＤＵセッションがＨＲ方式で確立されたと判断できる。それに対し、前記ＡＭＦと前記ＳＭＦが互いに異なるＰＬＭＮに位置したと判断される場合、該当ＰＤＵセッションがＬＢＯ方式で確立されたと判断できる。この場合、ハンドオーバが不可能であると判断できる。

【0242】

一方、ＡＭＦは、ＵＥから受信したＰＤＵセッションＩＤとマッピングされているＰＤＵセッションが存在することを知っている場合、前記ＡＭＦは、該当ＰＤＵセッションを担当するＳＭＦを選択することができ、前記ＳＭＦにＳＭ ｓｉｇｎａｌｌｉｎｇを伝達することができる場合、該当ＰＤＵセッションをハンドオーバさせることができると判断できる。もし、ＰＤＵセッションに対するコンテキストが存在すると、ＳＭＦが異なるＰＬＭＮ内に位置する場合にはＡＭＦがＳＭシグナリングを前記ＳＭＦに伝達することができないため、該当ＰＤＵセッションをハンドオーバさせることが不可能であると判断できる。

【0243】

もし、図５Ｅに示すように、３ＧＰＰアクセス及び非３ＧＰＰアクセスの両方ともＨＰＬＭＮでない他のＰＬＭＮに連結されている場合、ＰＬＭＮ情報にのみ基づいては該当ＰＤＵセッションがＨＲ方式で確立されたか、またはＬＢＯ方式で確立されたかを判断することができない。この場合、ＵＤＭに格納されているＰＤＵセッション情報に基づいて前記判断が実行される。または、ＡＭＦがＵＥのＨＰＬＭＮを知っており、ＳＭＦのＩＤがＰＬＭＮ ＩＤを含む場合、前記ＡＭＦは、ＵＥのＨＰＬＭＮ ＩＤとＳＭＦのＩＤから抽出可能なＰＬＭＮ ＩＤを比較してＰＤＵセッションがＨＲ方式で確立されたかどうかを判断することができる。

【0244】

または、ＵＥがハンドオーバのための登録であることを知らせなくても、ＵＥが初期登録（ｉｎｉｔｉａｌ ｒｅｇｉｓｔｒａｔｉｏｎ）または移動登録（ｍｏｂｉｌｉｔｙ ｒｅｇｉｓｔｒａｔｉｏｎ）をする場合、ＡＭＦは、ＵＥに登録受諾メッセージを伝達しながら、ＤＮＮ別及び／またはＳ−ＮＳＳＡＩ別にハンドオーバが可能かどうかを知らせることができる。

【0245】

即ち、ＡＭＦは、登録受諾メッセージを送信しながら、３ＧＰＰアクセスと非３ＧＰＰアクセスとの間にハンドオーバが可能であるということを知らせることができる。ＵＥは、ＡＭＦが送るハンドオーバ可能可否に基づいて下記の通り動作できる。

【0246】

−ハンドオーバが可能な場合、ＵＥは、ハンドオーバ手順を実行する。

【0247】

−ハンドオーバが不可能な場合、ＵＥは、ＰＤＵセッションのＳＳＣモードに基づいて追加的な動作をするかどうかを決定することができる。

【0248】

例えば、ＵＥが移そうとしたＰＤＵセッションがＳＳＣモード２ベースのＰＤＵセッションに該当する場合、既存のＰＤＵセッションを切って新しく接続したアクセスネットワークを介して新しいＰＤＵセッションを作る。

【0249】

もし、ＵＥが移そうとしたＰＤＵセッションがＳＳＣモード３ベースのＰＤＵセッションに該当する場合、新しく接続したアクセスネットワークを介して既存のＰＤＵセッションを維持したまま新しいＰＤＵセッションを要求することができる。少しの間、二つのセッションを維持させることによって、前記ＵＥのアプリケーション階層が前記新しく作ったＰＤＵセッションにトラフィックを移ることができるようにする。一定時間が過ぎたり全てのトラフィックが新しいＰＤＵセッションに移動すると、ＵＥは、既存のＰＤＵセッションを切る。

【0250】

ＵＥが移そうとしたＰＤＵセッションがＳＳＣモード１ベースのＰＤＵセッションに該当する場合、ＳＳＣモード３のような動作を実行することができる。または、ハンドオーバを中断するようにすることができる。

【0251】

ＡＭＦは、登録を許容せずに登録拒絶メッセージを送信することができる。このとき、前記登録拒絶メッセージ内の原因フィールドは、ＨＯが不可能で拒絶されることを示す原因値を含むことができる。

【0252】

図１３は、本明細書の第２の開示によって登録過程中にＵＥにハンドオーバが可能かどうかを知らせる方案を示す流れ図である。

【0253】

図１３の過程１に示すように、ＵＥがハンドオーバのために新しいアクセスに登録手順を実行する場合、ＵＥは、登録要求メッセージにハンドオーバインジケーションとハンドオーバしようとするＰＤＵセッションの情報（例えば、ＰＤＵセッションＩＤ）を含めて送る。そのとき、過程２２に示すように、ＡＭＦは、前述した方案を利用してハンドオーバが可能かどうかを示す情報を含む登録受諾メッセージを送信する。前記例題は、３ＧＰＰアクセスにおける手順を示すが、前述した内容は、非３ＧＰＰでも同様に適用できる。

【0254】

III．第３の開示：ハンドオーバのためのＵＥのＰＤＵセッション確立要求に対して、拒絶理由値を含む拒絶メッセージを送信することによって、ＵＥの動作を制御する方案

【0255】

前述した第２の開示は、ネットワークがハンドオーバ可能かどうかに対する情報をＵＥに知らせる場合、ＵＥは、前記情報に基づいて直接判断してＰＤＵセッションを新しく作る等の動作を実行する。しかし、この場合、ネットワークでＵＥを所望の方向へ制御できない。したがって、本明細書の第３の開示は、後述するように提案する。具体的に、ＵＥが登録手順を実行した後、ハンドオーバのために、ＰＤＵセッション確立要求メッセージを送信すると、第３の開示は、ＡＭＦがハンドオーバ可能かどうかを判断し、前記ハンドオーバが不可能であると判断されると、拒絶原因値を含む拒絶メッセージを送信するようにする。ここで、前記ＡＭＦがハンドオーバ可能かどうかを判断する方案は、第２の開示で説明した方案と同じである。もし、拒絶原因の値が再確立要求（ｒｅ−ｅｓｔａｂｌｉｓｈ ｒｅｑｕｉｒｅｄ）を示す場合、ＵＥは、ハンドオーバが失敗することを認知し、新しくアタッチしたアクセスネットワークを介して新しいＰＤＵセッションの確立を要求することができる。もし、拒絶原因の値がハンドオーバがサポートされない（ｈａｎｄｏｖｅｒ ｎｏｔ ｓｕｐｐｏｒｔｅｄ）のようにハンドオーバ不可能を示す場合、ＵＥは、ハンドオーバを中断する。拒絶原因の値は、事業者が設定した政策やＤＮＮに基づいて決定される。例えば、ＩＭＳ ＤＮＮを使用する場合、拒絶原因の値は、再確立要求（ｒｅ−ｅｓｔａｂｌｉｓｈ ｒｅｑｕｉｒｅｄ）を示すことによって、ＵＥがサービスを受け続けるようにすることができる。しかし、ＩｏＴ ＤＮＮを使用する場合、前記拒絶原因の値は、ハンドオーバがサポートされない（ｈａｎｄｏｖｅｒ ｎｏｔ ｓｕｐｐｏｒｔｅｄ）ことを示すことによって、ＵＥがハンドオーバを実行しないようにできる。

【0256】

図１４は、本明細書の第３の開示によってハンドオーバのためのＰＤＵセッション確立要求に対して拒絶原因値を含むメッセージを送信することによって、ＵＥの動作を制御する方案を示す流れ図である。

【0257】

図１４を参照すると、前記ＵＥは、ＰＤＵセッション確立要求メッセージをＡＭＦに送信する。前記ＰＤＵセッション確立要求メッセージは、図８、図１０及び図１２を参照して詳述したように、ＰＤＵセッションのＩＤ、要求タイプ、ＳＳＣモード、プロトコル構成オプションを含むことができる。

【0258】

ＵＥがＰＤＵセッション確立要求メッセージを送信すると、ＡＭＦは、ハンドオーバが可能かどうかを判断する。具体的に、第２の開示で説明した通り、前記ＵＥは、前記ＰＤＵセッション確立要求メッセージ内の前記要求タイプが“既存ＰＤＵセッション”を指示し、前記受信したＰＤＵセッション確立要求メッセージ内のＰＤＵセッションＩＤが既存ＰＤＵセッションのＩＤを指示する場合、前記ＡＭＦはハンドオーバが可能かどうかを判断することができる。

【0259】

より具体的に、前述した通り、前記ＡＭＦは、ＰＤＵセッションＩＤとＳＭＦのＩＤを関連付けられて格納している。したがって、前記ＵＥから受信した前記ＰＤＵセッション確立要求メッセージ内のＰＤＵセッションＩＤが既存ＰＤＵセッションを指示する場合、前記ＡＭＦは、前記ＰＤＵセッションＩＤと関連付けられて格納されているＳＭＦのＩＤを探り出すことができる。ここで、ＳＭＦのＩＤは、ＰＬＭＮ ＩＤを含んで構成される。したがって、ＡＭＦは、ＳＭＦのＩＤから抽出されるＰＬＭＮ ＩＤに基づいてＡＭＦとＳＭＦが同じＰＬＭＮにあるか、または異なるＰＬＭＮにあるかを知ることができる。もし、前記ＡＭＦと前記ＳＭＦが同じＰＬＭＮ内に位置する場合、該当ＰＤＵセッションがＨＲ方式で確立されたと判断できる。この場合、前記ＡＭＦは、ハンドオーバが可能であると判断できる。また、前記ＡＭＦと前記ＳＭＦが全てＨＰＬＭＮ内に位置する場合、該当ＰＤＵセッションがＨＲ方式で確立されたと判断できる。それに対して、前記ＡＭＦと前記ＳＭＦが互いに異なるＰＬＭＮに位置したと判断される場合、該当ＰＤＵセッションがＬＢＯ方式で確立されたと判断できる。

【0260】

一方、前記ＵＥから受信した前記ＰＤＵセッション確立要求メッセージ内のＰＤＵセッションＩＤが既存ＰＤＵセッションを指示する場合、前記ＡＭＦは、該当ＰＤＵセッションを担当するＳＭＦを選択することができ、前記ＳＭＦにＳＭ ｓｉｇｎａｌｌｉｎｇを伝達することができる場合、該当ＰＤＵセッションをハンドオーバさせることができると判断できる。もし、ＰＤＵセッションに対するコンテキストが存在する場合、ＳＭＦが異なるＰＬＭＮ内に位置する時は、ＡＭＦがＳＭシグナリングを前記ＳＭＦに伝達できないため、該当ＰＤＵセッションをハンドオーバさせることが不可能であると判断できる。

【0261】

他方、前記ＵＥから受信した前記ＰＤＵセッション確立要求メッセージ内のＰＤＵセッションＩＤに指示される既存ＰＤＵセッションに対して前記ＡＭＦが知らない場合、前記ＡＭＦは、ＵＤＭから前記ＰＤＵセッションに対する情報を取得することができる。そして、前記ＡＭＦは、前記ＵＤＭから取得されたＰＤＵセッション情報に基づいて、前記ＰＤＵセッションをハンドオーバさせることができるかどうかを判断することができる。

【0262】

ハンドオーバが不可能であると判断される場合、ＡＭＦは、ＭＭ ＮＡＳメッセージ内に拒絶原因値を含ませて送信できる。前記ＵＥは、前記拒絶原因値によって後続する動作を決定することができる。

【0263】

具体的に、ＵＥは、ＡＭＦが送った拒絶原因値にしたがって下記のような動作を実行することができる。

【0264】

（ａ）拒絶原因値が、ハンドオーバがサポートされない（ｈａｎｄｏｖｅｒ ｎｏｔ ｓｕｐｐｏｒｔｅｄ）、またはハンドオーバが許容されない（ＨＯ ｉｓ ｎｏｔ ａｌｌｏｗｅｄ）またはペイロードがフォワーディングされないこと（ｐａｙｌｏａｄ ｗａｓ ｎｏｔ ｆｏｒｗａｒｄｅｄ）を指示する場合

【0265】

前記ＵＥは、該当ＰＤＵセッションに対するハンドオーバをそれ以上要求しない。そして、前記ＵＥは（ＰＤＵセッションが切れたり、ＰＤＵセッションが作られたＰＬＭＮに登録解除したり、Ｎ３ＩＷＫが異なるＰＬＭＮにあるノードに変わったりする時まで）下記のような動作を実行することができる。

【0266】

もし、ＰＤＵセッションがＳＳＣモード１またはＳＳＣモード３である場合、ハンドオーバさせようとするＰＤＵセッションと同じＤＮＮ／Ｎ−ＳＳＡＩ／ＳＳＣモード／ＰＤＵタイプを有するＰＤＵセッションを他のアクセスを介して追加で生成する。以後、ＵＥのアプリケーション階層でハンドオーバさせようとするＰＤＵセッションにあるトラフィックを他のアクセスに移す時まで待った後、新しいＰＤＵセッションのみを残して以前のＰＤＵセッションは解除できる。

【0267】

もし、ＰＤＵセッションがＳＳＣモード２である場合、ＵＥは、ハンドオーバしようとするＰＤＵセッションを先に切り、新しいＰＤＵセッションを他のアクセスを介して確立した後、サービスを要求することができる。

【0268】

ＵＥは、ＳＳＣモードによる動作にかかわらず新しいＰＤＵセッションを要求しながら、ＰＤＵセッションをＨＲ方式で確立することを要求するインジケーションを送ることができる。ＡＭＦは、このような場合、事業者の政策または設定にしたがって前記ＵＥの加入者情報にＬＢＯが許容されていても、Ｖ−ＳＭＦとＨ−ＳＭＦを選択してＨＲ方式でＰＤＵセッションが作られるようにすることができる。この場合、選択的に、ＡＭＦは、Ｖ−ＳＭＦ／Ｈ−ＳＭＦにＰＤＵセッション確立要求メッセージを送信しながら、ＵＥがＨＲ方式を要求したことを知らせるインジケーションを含ませることもできる。Ｈ−ＳＭＦは、前記インジケーションを受信した場合、ＰＤＵセッション確立受諾メッセージにＰＤＵセッションがＨＲ方式で作られたことを示す情報を含ませることができる。前記ＵＥは、このような方法を介して作ったＰＤＵセッションの場合、ＡＭＦから同じＤＮＮ／Ｓ−ＮＳＳＡＩを有するＰＤＵセッションに対してハンドオーバが許容されないこと（ＨＯ ｉｓ ｎｏｔ ａｌｌｏｗｅｄ ｉｎｄｉｃａｔｉｏｎ）を示す拒絶原因値を含むメッセージを受信したとしても、再びハンドオーバを要求することができる。しかし、ＰＤＵセッションをＨＲ方式で確立することを要求するインジケーションを送信したにもかかわらず、ＡＭＦから再びＰＤＵセッションに対してハンドオーバが許容されないこと（ＨＯ ｉｓ ｎｏｔ ａｌｌｏｗｅｄ ｉｎｄｉｃａｔｉｏｎ）を示す拒絶原因値を含むメッセージを受信する場合、再び該当ＤＮＮ／Ｓ−ＮＳＳＡＩを有するＰＤＵセッションに対してはハンドオーバを要求しないべきである。

【0269】

（ｂ）拒絶原因値が混雑（Ｃｏｎｇｅｓｔｉｏｎ）を指示する場合

【0270】

ＡＭＦが送信するメッセージ内の拒絶原因値が混雑を指示する場合、前記メッセージは、バックオフタイマ（ｂａｃｋ−ｏｆｆ ｔｉｍｅ）の値を共に含むことができる。前記ＵＥは、ＡＭＦから提供を受けた拒絶メッセージのバックオフタイマの値に基づいて、バックオフタイマを駆動する。この場合は、混雑状況によって拒絶される場合であるため、バックオフタイマが満了される前までは、前記ＵＥは、再び要求を試みない。即ち、ＵＥは、バックオフタイマが満了される前までハンドオーバを再びＡＭＦに要求しない。または、もし、ＡＭＦが拒絶原因値を混雑と指示したが、他のインジケーションを介してハンドオーバが許容されないこと（ＨＯ ｉｓ ｎｏｔ ａｌｌｏｗｅｄ）をＵＥが知るようになった場合、前記ＵＥは、前記バックオフタイマが満了されても、再びハンドオーバを要求しない。以後の動作は、拒絶原因値がハンドオーバが許容されないこと（ＨＯ ｉｓ ｎｏｔ ａｌｌｏｗｅｄ ｉｎｄｉｃａｔｉｏｎ）を指示した時と同じである。

【0271】

その代案として、拒絶原因値が混雑（Ｃｏｎｇｅｓｔｉｏｎ）を指示したとしても、拒絶原因値がハンドオーバが許容されないこと（ＨＯ ｉｓ ｎｏｔ ａｌｌｏｗｅｄ ｉｎｄｉｃａｔｉｏｎ）を指示した時と同様に、ＵＥが動作できる。

【0272】

IV．第４の開示：ＵＥが同じＰＬＭＮを介してネットワークに連結された場合にのみハンドオーバを許容する方案

【0273】

ＵＥがハンドオーバのために、他のアクセスネットワークを介して登録手順を実行完了した場合、本明細書の第４の開示は、３ＧＰＰアクセスネットワーク及び非３ＧＰＰアクセスネットワークが全て同じＰＬＭＮに位置する場合にのみ、前記ＵＥのＰＤＵセッションをハンドオーバさせるようにすることができる。他の開示と比較して追加的なインジケーションや手順が必要でないという長所がある。しかし、状況によっては、ハンドオーバが可能であるにもかかわらず、ＵＥがハンドオーバできない場合が発生されることもある。

【0274】

Ｖ．第５の開示：ＰＤＵセッションを確立する過程で該当ＰＤＵセッションがハンドオーバ可能かを知らせる方案

【0275】

第５の開示によると、ネットワークは、ＰＤＵセッションがＨＲ方式で確立されたか、またはＬＢＯ方式で確立されたかに対する情報をＵＥに知らせない代わりに、ハンドオーバが可能かまたは不可能かを直接的に知らせる情報をＵＥに送信することができる。この場合、ＵＥは、ＰＤＵセッションがＨＲ方式で確立されたか、またはＬＢＯ方式で確立されたかを知らないまま、単純にハンドオーバが可能かどうかのみを示す情報に基づいて、ハンドオーバを実行するかどうかを判断することができる。例えば、ネットワークで同じＤＮＮでＰＤＵセッションを複数個確立でき、このうち、ＳＳＣモード１ベースのＰＤＵセッションはハンドオーバが可能であると知らせ、ＳＳＣモード２／３ベースのＰＤＵセッションはハンドオーバが不可能であると知らせることができる。この場合、ＵＥは、ＳＳＣモード１ベースのＰＤＵセッションのみをハンドオーバさせることができる。ＳＳＣモード２の場合は、ＳＳＣモードの定義にしたがって既存のＰＤＵセッションを切った後、新しいＰＤＵセッションを確立する作業をすることができる。この場合、ハンドオーバが実行されるものではなく、既存アクセスを介したＰＤＵセッションを切って新しいアクセスを介して新しいＰＤＵセッションを確立することができる。ＳＳＣモード３の場合、一定時間の間、平行に（ｐａｒａｌｌｅｌ）複数のＰＤＵセッションを確立することができるようにするため、以前アクセスを介した第１のＰＤＵセッションを維持したまま新しいアクセスを介して第２のＰＤＵセッションを確立し、トラフィックを新しく作った第２のＰＤＵセッションを経由するように移した以後、以前の第１のＰＤＵセッションを切る作業をする。

【0276】

または、ネットワークで作ったＰＤＵセッションが特定スライスと連結されており、該当スライスが特定アクセスでのみ使用可能になっている場合、ネットワークは、ハンドオーバが不可能であることをＵＥに知らせることができる。

【0277】

この方案を使用すると、ＵＥがあらかじめ両側アクセスを介して登録完了した場合、ＳＭＦは、ハンドオーバが可能かどうかをＵＥにあらかじめ知らせることができる。例えば、ＵＥが３ＧＰＰアクセス及び非３ＧＰＰアクセスの両方ともに登録されていると仮定する。このとき、現在ＵＥが３ＧＰＰアクセス及び非３ＧＰＰアクセスの両方ともに同じＡＭＦを介して登録されている場合、ＡＭＦは、ＵＥが同じ一つのＡＭＦを介して全て登録したということをＳＭＦに知らせることができる。ＳＭＦは、ＡＭＦが知らせた情報に基づいてＳＳＣモードを考慮してＰＤＵセッション確立受諾メッセージにハンドオーバが可能であると知らせることができる。もし、ＵＥが互いに異なるＡＭＦを介して登録完了した場合、いずれか一つのＡＭＦは、ＵＥが２個のアクセスに全て登録されているかを知ることができない。したがって、この場合、前記ＡＭＦは、ＳＭＦに何らの情報を送らない。前記ＳＭＦは、ＡＭＦからＵＥが２個のアクセスを介して登録完了したという情報を受けなかったため、ＰＤＵセッション確立受諾メッセージにハンドオーバが不可能であることを示す情報を含ませることができる。

【0278】

図１５は、ＰＤＵセッションを確立する過程で該当ＰＤＵセッションがＨＯ可能かどうかを知らせる方法である。

【0279】

図１５を参照すると、過程１で、ＵＥは、ハンドオーバのためにＰＤＵセッション確立要求メッセージを送信する時、ＡＭＦにハンドオーバのために送るメッセージであることを知らせるために、ハンドオーバインジケーション（例えば、ＨＯ ｉｎｄｉｃａｔｉｏｎ）を含ませる。

【0280】

前記受信したメッセージ内に前記ハンドオーバインジケーション（ＨＯ ｉｎｄｉｃａｔｉｏｎ）が含まれている場合、前記ＡＭＦは、ＵＥが一つのＡＭＦを介して３ＧＰＰアクセス及び非３ＧＰＰアクセスの両方ともに同時に登録されたかどうかを知らせるインジケーション（例えば、Ｓｉｍｕｌｔａｎｅｏｕｓ ａｃｃｅｓｓ ｉｎｄｉｃａｔｉｏｎ）を過程３のＰＤＵセッション確立要求メッセージ内に含ませて、ＳＭＦに送信する。

【0281】

過程１０で、前記ＳＭＦ前記インジケーション（例えば、Ｓｉｍｕｌｔａｎｅｏｕｓ ａｃｃｅｓｓ ｉｎｄｉｃａｔｉｏｎ）に基づいて、ハンドオーバが可能かどうかを判断することができる。または、前記ＳＭＦは、前記インジケーションがなくても、加入情報、ＵＥ能力情報などに基づいてハンドオーバが可能かどうかを判断することができる。

【0282】

以上、説明した内容は、ハードウェアで具現される。これに対して図面を参照して説明する。

【0283】

図１６は、本発明の実施例に係るＵＥ及びネットワークノードの構成ブロック図である。

【0284】

図１６に示すように、前記ＵＥ１００は、格納手段１０１、コントローラ１０２、及び送受信部１０３を含む。そして、前記ネットワークノードは、ＡＭＦ、ＳＭＦ、ＮＥＦ、及びＡＦのうちいずれか一つである。前記ネットワークノードは、格納手段５１１、コントローラ５１２、及び送受信部５１３を含む。

【0285】

前記格納手段は、前述した方法を格納する。

【0286】

前記コントローラは、前記格納手段及び前記送受信部を制御する。具体的に、前記コントローラは、前記格納手段に格納された前記方法をそれぞれ実行する。そして、前記コントローラは、前記送受信部を介して前記前述した信号を送信する。

【0287】

以上、本発明の好ましい実施例を例示的に説明したが、本発明の範囲は、このような特定実施例にのみ限定されるものではないため、本発明は、本発明の思想及び特許請求範囲に記載された範ちゅう内で多様な形態で修正、変更、または改善される。

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図5C】

【図5D】

【図5E】

【図5F】

【図6a】

【図6b】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】