(57)【要約】本明細書の一開示は、ＡＭＦ（ａｃｃｅｓｓ  ａｎｄ  ｍｏｂｉｌｉｔｙ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードがＰＤＵ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｕｎｉｔ）セッション確立手順を処理する方法を提供する。前記方法は、ＰＤＵセッション確立要求を拒絶するかどうかを決定するステップを含む。ここで、前記決定ステップは、前記ＰＤＵセッション確立要求が既存ＰＤＵセッションの識別子を含む場合に実行される。前記既存ＰＤＵセッションの識別子に基づいて、ＳＭＦ（ｓｅｓｓｉｏｎ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードの識別子が取得される。前記ＳＭＦノードの識別子に基づいて前記ＳＭＦノード及び前記ＡＭＦノードが両方とも同じＰＬＭＮ（Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）に属すると決定される場合、前記ＰＤＵセッション確立要求は受諾される。前記ＳＭＦノードの識別子に基づいてＳＭＦノード及び前記ＡＭＦノードが両方ともＨＰＬＭＮ（Ｈｏｍｅ  ＰＬＭＮ）に属すると決定される場合、前記ＰＤＵセッション確立要求は受諾される。前記ＳＭＦノード及び前記ＡＭＦノードが両方とも同じＰＬＭＮに属しない、またはＨＰＬＭＮに属しないと決定される場合、前記ＰＤＵセッション確立要求は拒絶される。【選択図】図１４
2019521607.tif 000002
【特許請求の範囲】
【請求項１】
ＡＭＦ（ａｃｃｅｓｓ  ａｎｄ  ｍｏｂｉｌｉｔｙ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードがＰＤＵ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｕｎｉｔ）セッション確立手順を処理する方法であって、
ＰＤＵセッション確立要求を拒絶するかどうかを決定するステップを含み、
ここで、前記決定ステップは、前記ＰＤＵセッション確立要求が既存ＰＤＵセッションの識別子を含む場合に実行され、
前記既存ＰＤＵセッションの識別子に基づいて、ＳＭＦ（ｓｅｓｓｉｏｎ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードの識別子が取得され、
前記ＳＭＦノードの識別子に基づいて前記ＳＭＦノード及び前記ＡＭＦノードが両方とも同じＰＬＭＮ（Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）に属すると決定される場合、前記ＰＤＵセッション確立要求は受諾され、
前記ＳＭＦノードの識別子に基づいてＳＭＦノード及び前記ＡＭＦノードが両方ともＨＰＬＭＮ（Ｈｏｍｅ  ＰＬＭＮ）に属すると決定される場合、前記ＰＤＵセッション確立要求は受諾され、
前記ＳＭＦノード及び前記ＡＭＦノードが両方とも同じＰＬＭＮに属しない、またはＨＰＬＭＮに属しないと決定される場合、前記ＰＤＵセッション確立要求が拒絶されることを特徴とする方法。
【請求項２】
前記ＰＤＵセッション確立要求メッセージは、要求タイプをさらに含み、
前記要求タイプは、新しいＰＤＵセッションを設定するためのものである場合、要求タイプは“初期要求”を指示したり、
前記要求タイプは、既存ＰＤＵセッションが存在する場合、“既存ＰＤＵセッション”を指示したりすることを特徴とする請求項１に記載の方法。
【請求項３】
前記要求タイプが“既存ＰＤＵセッション”を指示する場合、
３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）ベースのアクセスネットワークと非３ＧＰＰ（ｎｏｎ−３ＧＰＰ）ベースのアクセスネットワークとの間にＰＤＵセッションの移動が要求されることを特徴とする請求項２に記載の方法。
【請求項４】
前記ＡＭＦノードは、ＰＤＵセッションの識別子と前記ＳＭＦノードの識別子とを関連付けられて格納していることを特徴とする請求項１に記載の方法。
【請求項５】
前記ＳＭＦノードの識別子は、ＰＬＭＮの識別子を含んで構成されることを特徴とする請求項１に記載の方法。
【請求項６】
前記ＰＤＵセッション確立要求が拒絶される場合、拒絶原因を含むメッセージを送信するステップをさらに含むことを特徴とする請求項１に記載の方法。
【請求項７】
ＰＤＵ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｕｎｉｔ）セッション確立手順を処理するＡＭＦ（ａｃｃｅｓｓ  ａｎｄ  ｍｏｂｉｌｉｔｙ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードであって、
送受信部と、
前記送受信部を制御し、ＰＤＵセッション確立要求を拒絶するかどうかを決定するプロセッサとを含み、
ここで、前記決定は、前記ＰＤＵセッション確立要求が既存ＰＤＵセッションの識別子を含む場合に実行され、
前記既存ＰＤＵセッションの識別子に基づいて、ＳＭＦ（ｓｅｓｓｉｏｎ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードの識別子が取得され、
前記ＳＭＦノードの識別子に基づいて前記ＳＭＦノード及び前記ＡＭＦノードが両方とも同じＰＬＭＮ（Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）に属すると決定される場合、前記ＰＤＵセッション確立要求は受諾され、
前記ＳＭＦノードの識別子に基づいてＳＭＦノード及び前記ＡＭＦノードが両方ともＨＰＬＭＮ（Ｈｏｍｅ  ＰＬＭＮ）に属すると決定される場合、前記ＰＤＵセッション確立要求は受諾され、
前記ＳＭＦノード及び前記ＡＭＦノードが両方とも同じＰＬＭＮに属しない、またはＨＰＬＭＮに属しないと決定される場合、前記ＰＤＵセッション確立要求は拒絶されることを特徴とするＡＭＦノード。
【請求項８】
前記ＰＤＵセッション確立要求メッセージは、要求タイプをさらに含み、
前記要求タイプは、新しいＰＤＵセッションを設定するためのものである場合、要求タイプは“初期要求”を指示したり、
前記要求タイプは、既存ＰＤＵセッションが存在する場合、“既存ＰＤＵセッション”を指示したりすることを特徴とする請求項７に記載のＡＭＦノード。
【請求項９】
前記要求タイプが“既存ＰＤＵセッション”を指示する場合、
３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）ベースのアクセスネットワークと非３ＧＰＰ（ｎｏｎ−３ＧＰＰ）ベースのアクセスネットワークとの間にＰＤＵセッションの移動が要求されることを特徴とする請求項８に記載のＡＭＦノード。
【請求項１０】
前記ＡＭＦノードは、ＰＤＵセッションの識別子と前記ＳＭＦノードの識別子とを関連付けられて格納していることを特徴とする請求項７に記載のＡＭＦノード。
【請求項１１】
前記ＳＭＦノードの識別子は、ＰＬＭＮの識別子を含んで構成されることを特徴とする請求項７に記載のＡＭＦノード。
【請求項１２】
前記プロセッサは、
前記ＰＤＵセッション確立要求が拒絶される場合、拒絶原因を含むメッセージを送信することを特徴とする請求項７に記載のＡＭＦノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、次世代移動通信に関する。
【背景技術】
【０００２】
移動通信システムの技術規格を制定する３ＧＰＰでは、４世代移動通信と関連した多様なフォーラム及び新しい技術に対応するために、２００４年末から３ＧＰＰ技術の性能を最適化させて向上させようとする努力の一環としてＬＴＥ／ＳＡＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ／Ｓｙｓｔｅｍ  Ａｒｃｈｉｔｅｃｔｕｒｅ  Ｅｖｏｌｕｔｉｏｎ）技術に対する研究を始めた。
【０００３】
３ＧＰＰ  ＳＡ  ＷＧ２を中心に進行されたＳＡＥは、３ＧＰＰ  ＴＳＧ  ＲＡＮのＬＴＥ作業と並行してネットワークの構造を決定し、異機種ネットワーク間の移動性をサポートすることを目的とするネットワーク技術に対する研究であって、最近３ＧＰＰの重要な標準化問題のうち一つである。これは３ＧＰＰシステムをＩＰベースの多様な無線接続技術をサポートするシステムに発展させるための作業であって、より向上したデータ送信能力で送信遅延を最小化する、最適化されたパケットベースのシステムを目標にして作業が進行されてきた。
【０００４】
３ＧＰＰ  ＳＡ  ＷＧ２で定義したＥＰＳ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｓｙｓｔｅｍ）上位水準参照モデル（ｒｅｆｅｒｅｎｃｅ  ｍｏｄｅｌ）は、非ローミングケース（ｎｏｎ−ｒｏａｍｉｎｇ  ｃａｓｅ）及び多様なシナリオのローミングケース（ｒｏａｍｉｎｇ  ｃａｓｅ）を含んでおり、詳細内容は、３ＧＰＰ標準文書ＴＳ２３.４０１とＴＳ２３.４０２で参照することができる。図１のネットワーク構造図は、これを簡略に再構成したものである。
【０００５】
図１は、進化した移動通信ネットワークの構造図である。
【０００６】
ＥＰＣは、多様な構成要素を含むことができ、図１は、そのうち一部に該当する、Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）５２、ＰＤＮ  ＧＷ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｎｅｔｗｏｒｋ  Ｇａｔｅｗａｙ）５３、ＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）５１、ＳＧＳＮ（Ｓｅｒｖｉｎｇ  ＧＰＲＳ（Ｇｅｎｅｒａｌ  Ｐａｃｋｅｔ  Ｒａｄｉｏ  Ｓｅｒｖｉｃｅ）  Ｓｕｐｐｏｒｔｉｎｇ  Ｎｏｄｅ）、ｅＰＤＧ（ｅｎｈａｎｃｅｄ  Ｐａｃｋｅｔ  Ｄａｔａ  Ｇａｔｅｗａｙ）を示す。
【０００７】
Ｓ−ＧＷ５２は、無線アクセスネットワーク（ＲＡＮ）とコアネットワークとの間の境界点として動作し、ｅＮｏｄｅＢ２２とＰＤＮ  ＧＷ５３との間のデータ経路を維持する機能をする要素である。また、端末（または、Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ：ＵＥ）がｅＮｏｄｅＢ２２によりサービング（ｓｅｒｖｉｎｇ）される領域にわたって移動する場合、Ｓ−ＧＷ５２は、ローカル移動性アンカーポイント（ａｎｃｈｏｒ  ｐｏｉｎｔ）の役割をする。即ち、Ｅ−ＵＴＲＡＮ（３ＧＰＰリリース８以後で定義されるＥｖｏｌｖｅｄ−ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ）  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）内での移動性のために、Ｓ−ＧＷ５２を介してパケットがルーティングされる。また、Ｓ−ＧＷ５２は、他の３ＧＰＰネットワーク（３ＧＰＰリリース８以前に定義されるＲＡＮ、例えば、ＵＴＲＡＮまたはＧＥＲＡＮ（ＧＳＭ（Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）／ＥＤＧＥ（Ｅｎｈａｎｃｅｄ  Ｄａｔａ  ｒａｔｅｓ  ｆｏｒ  Ｇｌｏｂａｌ  Ｅｖｏｌｕｔｉｏｎ）  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）との移動性のためのアンカーポイントとして機能することもできる。
【０００８】
ＰＤＮ  ＧＷ（または、Ｐ−ＧＷ）５３は、パケットデータネットワークに向かうデータインターフェースの終端点（ｔｅｒｍｉｎａｔｉｏｎ  ｐｏｉｎｔ）に該当する。ＰＤＮ  ＧＷ５３は、政策執行特徴（ｐｏｌｉｃｙ  ｅｎｆｏｒｃｅｍｅｎｔ  ｆｅａｔｕｒｅｓ）、パケットフィルタリング（ｐａｃｋｅｔ  ｆｉｌｔｅｒｉｎｇ）、課金サポート（ｃｈａｒｇｉｎｇ  ｓｕｐｐｏｒｔ）などをサポートすることができる。また、３ＧＰＰネットワークと非３ＧＰＰネットワーク（例えば、Ｉ−ＷＬＡＮ（Ｉｎｔｅｒｗｏｒｋｉｎｇ  Ｗｉｒｅｌｅｓｓ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）のような信頼されないネットワーク、ＣＤＭＡ（Ｃｏｄｅ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）ネットワークやＷｉＭａｘのような信頼されるネットワーク）との移動性管理のためのアンカーポイント役割をすることができる。
【０００９】
図１のネットワーク構造の例示は、Ｓ−ＧＷ５２とＰＤＮ  ＧＷ５３が別途のゲートウェイで構成されるものを示すが、二つのゲートウェイが単一ゲートウェイ構成オプション（Ｓｉｎｇｌｅ  Ｇａｔｅｗａｙ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｏｐｔｉｏｎ）によって具現されることもできる。
【００１０】
ＭＭＥ５１は、ＵＥのネットワーク連結に対するアクセス、ネットワークリソースの割当、トラッキング（ｔｒａｃｋｉｎｇ）、ページング（ｐａｇｉｎｇ）、ローミング（ｒｏａｍｉｎｇ）及びハンドオーバなどをサポートするためのシグナリング及び制御機能を実行する要素である。ＭＭＥ５１は、加入者及びセッション管理に関連した制御平面（ｃｏｎｔｒｏｌ  ｐｌａｎｅ）機能を制御する。ＭＭＥ５１は、数多くのｅＮｏｄｅＢ２２を管理し、他の２Ｇ／３Ｇネットワークに対するハンドオーバのための従来のゲートウェイの選択のためのシグナリングを実行する。また、ＭＭＥ５１は、セキュリティ過程（Ｓｅｃｕｒｉｔｙ  Ｐｒｏｃｅｄｕｒｅｓ）、端末−対−ネットワークセッションハンドリング（Ｔｅｒｍｉｎａｌ−ｔｏ−ｎｅｔｗｏｒｋ  Ｓｅｓｓｉｏｎ  Ｈａｎｄｌｉｎｇ）、アイドル端末位置決定管理（Ｉｄｌｅ  Ｔｅｒｍｉｎａｌ  Ｌｏｃａｔｉｏｎ  Ｍａｎａｇｅｍｅｎｔ）などの機能を遂行する。
【００１１】
ＳＧＳＮは、異なるアクセス３ＧＰＰネットワーク（例えば、ＧＰＲＳネットワーク、ＵＴＲＡＮ／ＧＥＲＡＮ）に対するユーザの移動性管理及び認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）といった全てのパケットデータをハンドリングする。
【００１２】
ｅＰＤＧは、信頼されない非３ＧＰＰネットワーク（例えば、Ｉ−ＷＬＡＮ、ＷｉＦｉホットスポット（ｈｏｔｓｐｏｔ）等）に対するセキュリティノードとしての役割をする。
【００１３】
図１を参照して説明したように、ＩＰ能力を有する端末（または、ＵＥ）は、３ＧＰＰアクセスはもちろん非３ＧＰＰアクセスに基づいても、ＥＰＣ内の多様な要素を経由して事業者（即ち、オペレータ（ｏｐｅｒａｔｏｒ））が提供するＩＰサービスネットワーク（例えば、ＩＭＳ）にアクセスすることができる。
【００１４】
また、図１は、多様なレファレンスポイント（例えば、Ｓ１−Ｕ、Ｓ１−ＭＭＥ等）を示す。３ＧＰＰシステムでは、Ｅ−ＵＴＲＡＮ及びＥＰＣの異なる機能エンティティ（ｆｕｎｃｔｉｏｎａｌ  ｅｎｔｉｔｙ）に存在する２個の機能を連結する概念的なリンクをレファレンスポイント（ｒｅｆｅｒｅｎｃｅ  ｐｏｉｎｔ）と定義する。以下の表１は、図１に示すレファレンスポイントを整理したものである。表１の例示外にもネットワーク構造によって多様なレファレンスポイントが存在できる。
【００１５】
【表１】
2019521607.tif 000003
【００１６】
＜次世代移動通信ネットワーク＞
【００１７】
４世代移動通信のためのＬＴＥ（ｌｏｎｇ  ｔｅｒｍ  ｅｖｏｌｕｔｉｏｎ）／ＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ−Ａ）の成功にこたえて、次世代、即ち、５世代（いわゆる５Ｇ）移動通信に対する関心も高まっており、研究も続々と進行している。
【００１８】
国際電気通信連合（ＩＴＵ）が定義する５世代移動通信は、最大２０Ｇｂｐｓのデータ送信速度とどこでも最小１００Ｍｂｐｓ以上の体感送信速度を提供するものを意味する。正式名称はＩＭＴ−２０２０’であり、世界的に２０２０年に商用化することを目標としている。
【００１９】
ＩＴＵでは３代使用シナリオ、例えば、ｅＭＢＢ（ｅｎｈａｎｃｅｄ  Ｍｏｂｉｌｅ  ＢｒｏａｄＢａｎｄ）ｍＭＴＣ（ｍａｓｓｉｖｅ  Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）及びＵＲＬＬＣ（Ｕｌｔｒａ  Ｒｅｌｉａｂｌｅ  ａｎｄ  Ｌｏｗ  Ｌａｔｅｎｃｙ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）を提示している。
【００２０】
まず、ＵＲＬＬＣは、高い信頼性と低い遅延時間を要求する使用シナリオに関する。例えば、自動走行、工場自動化、増強現実のようなサービスは、高い信頼性と低い遅延時間（例えば、１ｍｓ以下の遅延時間）を要求する。現在４Ｇ（ＬＴＥ）の遅延時間は、統計的に、２１−４３ｍｓ（ｂｅｓｔ１０％）、３３−７５ｍｓ（ｍｅｄｉａｎ）である。これは１ｍｓ以下の遅延時間を要求するサービスをサポートするに足りない。
【００２１】
次に、ｅＭＢＢ使用シナリオは、移動超広帯域を要求する使用シナリオに関する。
【００２２】
このような超広帯域の高速サービスは、既存ＬＴＥ／ＬＴＥ−Ａのために設計されたコアネットワークによっては受容されにくい。
【００２３】
したがって、いわゆる５世代移動通信ではコアネットワークの再設計が切実に要求される。
【００２４】
図２は、次世代移動通信の予想構造をノード観点で表した例示図である。
【００２５】
図２を参照して分かるように、ＵＥは、次世代ＲＡＮ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）を介してデータネットワーク（ＤＮ）と連結される。
【００２６】
図示された制御平面機能（Ｃｏｎｔｒｏｌ  Ｐｌａｎｅ  Ｆｕｎｃｔｉｏｎ；ＣＰＦ）ノードは、４世代移動通信のＭＭＥ（Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｅｎｔｉｔｙ）機能の全部または一部、Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ  Ｇａｔｅｗａｙ）及びＰ−ＧＷ（ＰＤＮ  Ｇａｔｅｗａｙ）の制御平面機能の全部または一部を実行する。前記ＣＰＦノードは、ＡＭＦ（Ａｃｃｅｓｓ  ａｎｄ  Ｍｏｂｉｌｉｔｙ  Ｍａｎａｇｅｍｅｎｔ  Ｆｕｎｃｔｉｏｎ）とＳＭＦ（Ｓｅｓｓｉｏｎ  Ｍａｎａｇｅｍｅｎｔ  Ｆｕｎｃｔｉｏｎ）を含む。
【００２７】
図示されたユーザ平面機能（Ｕｓｅｒ  Ｐｌａｎｅ  Ｆｕｎｃｔｉｏｎ；ＵＰＦ）ノードは、ユーザのデータが送受信されるゲートウェイの一種である。前記ＵＰＦノードは、４世代移動通信のＳ−ＧＷ及びＰ−ＧＷのユーザ平面機能の全部または一部を実行することができる。
【００２８】
図示されたＰＣＦ（Ｐｏｌｉｃｙ  Ｃｏｎｔｒｏｌ  Ｆｕｎｃｔｉｏｎ）は、事業者の政策を制御するノードである。
【００２９】
図示されたアプリケーション機能（Ａｐｐｌｉｃａｔｉｏｎ  Ｆｕｎｃｔｉｏｎ：ＡＦ）は、ＵＥに多様なサービスを提供するためのサーバである。
【００３０】
図示された統合データ格納管理（Ｕｎｉｆｉｅｄ  Ｄａｔａ  Ｍａｎａｇｅｍｅｎｔ：ＵＤＭ）は、４世代移動通信のＨＳＳ（Ｈｏｍｅ  ｓｕｂｓｃｒｉｂｅｒ  Ｓｅｒｖｅｒ）のように、加入者情報を管理するサーバの一種である。前記ＵＤＭは、前記加入者情報を統合データリポジトリ（Ｕｎｉｆｉｅｄ  Ｄａｔａ  Ｒｅｐｏｓｉｔｏｒｙ：ＵＤＲ）に格納して管理する。
【００３１】
図示された認証サーバ機能（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ  Ｆｕｎｃｔｉｏｎ：ＡＵＳＦ）は、ＵＥを認証及び管理する。
【００３２】
図示されたネットワークスライス選択機能（Ｎｅｔｗｏｒｋ  Ｓｌｉｃｅ  Ｓｅｌｅｃｔｉｏｎ  Ｆｕｎｃｔｉｏｎ：ＮＳＳＦ）は、後述のようにネットワークスライシングのためのノードである。
【００３３】
図３ａは、２個のデータネットワークを介した多重ＰＤＵセッションをサポートするためのアーキテクチャを示す例示図であり、図３ｂは、２個のデータネットワークに対する同時アクセスをサポートするためのアーキテクチャを示す例示図である。
【００３４】
図３ａでは、ＵＥが２個のデータネットワークに多重ＰＤＵセッションを利用して同時に接続できるようにするためのアーキテクチャが示されている。２個の互いに異なるＰＤＵセッションのために２個のＳＭＦが選択される。
【００３５】
図３ｂでは、ＵＥが一つのＰＤＵセッションを使用して２個のデータネットワークに同時アクセスするためのアーキテクチャが示されている。
【００３６】
＜ネットワークスライス（Ｎｅｔｗｏｒｋ  Ｓｌｉｃｅ）＞
【００３７】
以下、次世代移動通信で導入されるネットワークのスライシングを説明する。
【００３８】
次世代移動通信は、一つのネットワークを介して多様なサービスを提供するために、ネットワークのスライシングに対する概念を紹介している。ここで、ネットワークのスライシングは、特定サービスを提供する時、必要な機能を有するネットワークノードの組み合わせである。スライスインスタンスを構成するネットワークノードは、ハードウェア的に独立されたノードであり、または論理的に独立されたノードである。
【００３９】
各スライスインスタンスは、ネットワーク全体を構成するのに必要な全てのノードの組み合わせで構成される。この場合、一つのスライスインスタンスは、ＵＥに単独でサービスを提供することができる。
【００４０】
それに対し、スライスインスタンスは、ネットワークを構成するノードのうち一部ノードの組み合わせで構成されることもできる。この場合、スライスインスタンスは、ＵＥに単独でサービスを提供せずに、既存の他のネットワークノードと連係してＵＥにサービスを提供することができる。また、複数個のスライスインスタンスが互いに連係してＵＥにサービスを提供することもできる。
【００４１】
スライスインスタンスは、コアネットワーク（ＣＮ）ノード及びＲＡＮを含む全体ネットワークノードが分離されるという点で専用コアネットワークと異なる。また、スライスインスタンスは、単純にネットワークノードが論理的に分離されるという点で専用コアネットワークと異なる。
【００４２】
＜次世代移動通信ネットワークでローミング＞
【００４３】
一方、ＵＥが訪問ネットワーク、例えば、ＶＰＬＭＮ（Ｖｉｓｉｔｅｄ  Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）にローミングした状況でＵＥからのシグナリング要求を処理する方式には二つが存在する。１番目の方式であるＬＢＯ（ｌｏｃａｌ  ｂｒｅａｋｏｕｔ）方式は、ＵＥからのシグナリング要求を訪問ネットワークで処理する。２番目の方式であるＨＲ（Ｈｏｍｅ  Ｒｏｕｔｉｎｇ）方式によると、訪問ネットワークは、ＵＥからのシグナリング要求をＵＥのホームネットワークに伝達する。
【００４４】
図４ａは、ローミング時、ＬＢＯ（ｌｏｃａｌ  ｂｒｅａｋｏｕｔ）方式が適用されるアーキテクチャを示す例示図であり、図４ｂは、ローミング時、ＨＲ（ｈｏｍｅ  ｒｏｕｔｅｄ）方式が適用されるアーキテクチャを示す例示図である。
【００４５】
図４ａに示すように、ＬＢＯ方式が適用されるアーキテクチャでは、ユーザのデータは、ＶＰＬＭＮ内のデータネットワークに伝達される。そのために、ＶＰＬＭＮ内のＰＣＦがＶＰＬＭＮ内でのサービスのためのＰＣＣ規則を生成するために、ＡＦとインタラクションを実行する。前記ＶＰＬＭＮ内のＰＣＦノードは、ＨＰＬＭＮ（Ｈｏｍｅ  Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）事業者とのローミング協約によって内部に設定された政策に基づいてＰＣＣ規則を生成する。
【００４６】
図４ｂに示すように、ＨＲ方式が適用されるアーキテクチャでは、ＵＥのデータは、ＨＰＬＭＮ内のデータネットワークに伝達される。
【００４７】
＜非３ＧＰＰネットワークへのデータ迂回＞
【００４８】
次世代移動通信において、ＵＥのデータは、非３ＧＰＰネットワーク、例えば、ＷＬＡＮ（Ｗｉｒｅｌｅｓｓ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）またはＷｉ−Ｆｉに迂回される。
【００４９】
図５Ａ乃至図５Ｆは、非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。
【００５０】
ＷＬＡＮ（Ｗｉｒｅｌｅｓｓ  Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）またはＷｉ−Ｆｉは、信頼されない非３ＧＰＰネットワークと見なされる。前記非３ＧＰＰネットワークをコアネットワークに接続させるために、Ｎ３ＩＷＦ（Ｎｏｎ−３ＧＰＰ  ＩｎｔｅｒＷｏｒｋｉｎｇ  Ｆｕｎｃｔｉｏｎ）が追加される。
【００５１】
＜既存４世代移動通信システムとのインターワーキング＞
【００５２】
ＵＥが次世代ＲＡＮ（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）のカバレッジを外れても、ＵＥは、４世代（４Ｇ）移動通信システムを介してでもサービスを受けることが可能でなければならない。これをインターワーキングという。以下、インターワーキングに対して詳細に説明する。
【００５３】
図６ａは、ＵＥがローミングしない場合のインターワーキングのためのアーキテクチャを示し、図６ｂは、ＵＥがローミングした場合のインターワーキングのためのアーキテクチャを示す。
【００５４】
図６ａを参照すると、ＵＥがローミングしない場合、既存４世代ＬＴＥのためのＥ−ＵＴＲＡＮとＥＰＣと５世代移動通信ネットワークは、互いにインターワーキングされる。図６ａにおいて、既存ＥＰＣのためのＰＧＷ（Ｐａｃｋｅｔ  ｄａｔａ  ｎｅｔｗｏｒｋ  Ｇａｔｅｗａｙ）は、ユーザ平面のみを担当するＰＧＷ−Ｕと制御平面を担当するＰＧＷ−Ｃとに分けられる。そして、ＰＧＷ−Ｕは、５世代コアネットワークのＵＰＦノードに併合され、ＰＧＷ−Ｃは、５世代コアネットワークのＳＭＦノードに併合される。そして、既存ＥＰＣのためのＰＣＲＦ（Ｐｏｌｉｃｙ  ａｎｄ  Ｃｈａｒｇｉｎｇ  Ｒｕｌｅｓ  Ｆｕｎｃｔｉｏｎ）は、５世代コアネットワークのＰＣＦに併合される。そして、既存ＥＰＣのためのＨＳＳは、５世代コアネットワークのＵＤＭに併合される。ＵＥは、Ｅ−ＵＴＲＡＮを介してコアネットワークに接続することもできるが、ＵＥは、５Ｇ  ＲＡＮ（ｒａｄｉｏ  ａｃｃｅｓｓ  ｎｅｔｗｏｒｋ）とＡＭＦを介してコアネットワークに接続することもできる。
【００５５】
図６ａと図６ｂを相互比較して参照すると、ＵＥがＶＰＬＭＮ（Ｖｉｓｉｔｅｄ  Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）にローミングした場合、前記ＵＥのデータは、ＨＰＬＭＮ（Ｈｏｍｅ  ＰＬＭＮ）を経由して伝達される。
【００５６】
一方、図６ａ及び図６ｂに示すＮ２６インターフェースは、ＥＰＣとＮＧコアとの間にインターワーキングを円滑にするために、ＭＭＥとＡＭＦとの間に連結されるインターフェースである。このようなＮ２６インターフェースは、事業者によって選択的にサポートされる。即ち、ＥＰＣとのインターワーキングのために、ネットワーク事業者は、Ｎ２６インターフェースを提供してもよく、またはＮ２６インターフェースを提供しなくてもよい。
【００５７】
ローミング状況で、ＵＥは、ネットワークにＰＤＵセッション確立要求メッセージを送信し、これに対する応答を受けると、ＰＤＵセッションが確立されたことを知ることができる。しかし、ＵＥは、ＰＤＵセッションがＬＢＯ（Ｌｏｃａｌ  Ｂｒｅａｋｏｕｔ）方式で確立されたか、またはＨＲ（Ｈｏｍｅ  Ｒｏｕｔｅｄ）方式で確立されたかを知ることができない。したがって、ハンドオーバが実行できない状況が発生できる。しかし、ＵＥは、実際ハンドオーバが成功できるかどうかを知ることができないため、ハンドオーバを試みることができ、この場合、不要なシグナリングが発生するようになる。
【発明の概要】
【発明が解決しようとする課題】
【００５８】
したがって、本明細書の開示は、前述した問題点を解決することを目的とする。
【課題を解決するための手段】
【００５９】
前記のような目的を達成するために、本明細書の一開示は、ＡＭＦ（ａｃｃｅｓｓ  ａｎｄ  ｍｏｂｉｌｉｔｙ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードがＰＤＵ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｕｎｉｔ）セッション確立手順を処理する方法を提供する。前記方法は、ＰＤＵセッション確立要求を拒絶するかどうかを決定するステップを含む。ここで、前記決定ステップは、前記ＰＤＵセッション確立要求が既存ＰＤＵセッションの識別子を含む場合に実行される。前記既存ＰＤＵセッションの識別子に基づいて、ＳＭＦ（ｓｅｓｓｉｏｎ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードの識別子が取得される。前記ＳＭＦノードの識別子に基づいて前記ＳＭＦノード及び前記ＡＭＦノードが両方とも同じＰＬＭＮ（Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）に属すると決定される場合、前記ＰＤＵセッション確立要求は受諾される。前記ＳＭＦノードの識別子に基づいてＳＭＦノード及び前記ＡＭＦノードが両方ともＨＰＬＭＮ（Ｈｏｍｅ  ＰＬＭＮ）に属すると決定される場合、前記ＰＤＵセッション確立要求は受諾される。前記ＳＭＦノード及び前記ＡＭＦノードが両方とも同じＰＬＭＮに属しない、またはＨＰＬＭＮに属しないと決定される場合、前記ＰＤＵセッション確立要求が拒絶される。
【００６０】
前記ＰＤＵセッション確立要求メッセージは、要求タイプをさらに含む。前記要求タイプは、新しいＰＤＵセッションを設定するためのものである場合、要求タイプは“初期要求”を指示したり、前記要求タイプは、既存ＰＤＵセッションが存在する場合、“既存ＰＤＵセッション”を指示したりする。
【００６１】
前記要求タイプが“既存ＰＤＵセッション”を指示する場合、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）ベースのアクセスネットワークと非３ＧＰＰ（ｎｏｎ−３ＧＰＰ）ベースのアクセスネットワークとの間にＰＤＵセッションの移動が要求される。
【００６２】
前記ＡＭＦノードは、ＰＤＵセッションの識別子と前記ＳＭＦノードの識別子とを関連付けられて格納している。
【００６３】
前記ＳＭＦノードの識別子は、ＰＬＭＮの識別子を含んで構成される。
【００６４】
前記方法は、前記ＰＤＵセッション確立要求が拒絶される場合、拒絶原因を含むメッセージを送信するステップをさらに含む。
【００６５】
また、前記のような目的を達成するために、本明細書の一開示は、ＰＤＵ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｕｎｉｔ）セッション確立手順を処理するＡＭＦ（ａｃｃｅｓｓ  ａｎｄ  ｍｏｂｉｌｉｔｙ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードを提供する。前記ＡＭＦノードは、送受信部と、前記送受信部を制御し、ＰＤＵセッション確立要求を拒絶するかどうかを決定するプロセッサとを含む。前記決定は、前記ＰＤＵセッション確立要求が既存ＰＤＵセッションの識別子を含む場合に実行される。前記既存ＰＤＵセッションの識別子に基づいて、ＳＭＦ（ｓｅｓｓｉｏｎ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードの識別子が取得される。前記ＳＭＦノードの識別子に基づいて前記ＳＭＦノード及び前記ＡＭＦノードが両方とも同じＰＬＭＮ（Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）に属しないと決定される場合、前記ＰＤＵセッション確立要求は拒絶される。また、前記ＳＭＦノードの識別子に基づいてＳＭＦノード及び前記ＡＭＦノードが両方ともＨＰＬＭＮ  ＰＬＭＮ（Ｈｏｍｅ  ＰＬＭＮ）に属しないと決定される場合、前記ＰＤＵセッション確立要求は拒絶される。
【発明の効果】
【００６６】
本明細書の開示によると、既存問題点が解決される。
【図面の簡単な説明】
【００６７】
【図１】進化した移動通信ネットワークの構造図である。
【図２】次世代移動通信の予想構造をノード観点で表した例示図である。
【図３】〔図３ａ〕は２個のデータネットワークを介した多重ＰＤＵセッションをサポートするためのアーキテクチャを示す例示図であり、〔図３ｂ〕は２個のデータネットワークに対する同時アクセスをサポートするためのアーキテクチャを示す例示図である。
【図４】〔図４ａ〕はローミング時、ＬＢＯ（ｌｏｃａｌ  ｂｒｅａｋｏｕｔ）方式が適用されるアーキテクチャを示す例示図であり、〔図４ｂ〕はローミング時、ＨＲ（ｈｏｍｅ  ｒｏｕｔｅｄ）方式が適用されるアーキテクチャを示す例示図である。
【図５Ａ】非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。
【図５Ｂ】非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。
【図５Ｃ】非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。
【図５Ｄ】非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。
【図５Ｅ】非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。
【図５Ｆ】非３ＧＰＰネットワークにデータを迂回させるためのアーキテクチャを示す。
【図６】〔図６ａ〕はＵＥがローミングしない場合のインターワーキングのためのアーキテクチャを示し、〔図６ｂ〕はＵＥがローミングした場合のインターワーキングのためのアーキテクチャを示す。
【図７】例示的な登録手順を示す信号流れ図である。
【図８】例示的なＰＤＵセッション確立手順を示す信号流れ図である。
【図９】信頼されない非３ＧＰＰアクセスを介した登録手順を示す信号流れ図である。
【図１０】信頼されない非３ＧＰＰアクセスを介したＵＥのＰＤＵセッション確立手順を示す流れ図である。
【図１１】〔図１１ａ〕は信頼されない非３ＧＰＰアクセスから３ＧＰＰアクセスへのＰＤＵセッションハンドオーバ手順を示し、〔図１１ｂ〕は３ＧＰＰアクセスから信頼されない非３ＧＰＰアクセスへのＰＤＵセッションハンドオーバ手順を示す。
【図１２】ＰＤＵセッションを確立する時、本明細書の第１の開示によって該当ＰＤＵセッションがＬＢＯ方式またはＨＲ方式で確立されたかを示す方案を示す流れ図である。
【図１３】本明細書の第２の開示によって登録過程中にＵＥにハンドオーバが可能かどうかを知らせる方案を示す流れ図である。
【図１４】本明細書の第３の開示によってハンドオーバのためのＰＤＵセッション確立要求に対して拒絶原因値を含むメッセージを送信することによって、ＵＥの動作を制御する方案を示す流れ図である。
【図１５】ＰＤＵセッションを確立する過程で該当ＰＤＵセッションがＨＯ可能かどうかを知らせる方法である。
【図１６】本発明の実施例に係るＵＥ及びネットワークノードの構成ブロック図である。
【発明を実施するための形態】
【００６８】
本明細書で使われる技術的用語は、単に特定の実施例を説明するために使われたものであり、本発明を限定するものではないことに留意しなければならない。また、本明細書で使われる技術的用語は、本明細書で特別に他の意味で定義されない限り、本発明が属する技術分野において、通常の知識を有する者により一般的に理解される意味で解釈されなければならず、過度に包括的な意味または過度に縮小された意味で解釈されてはならない。また、本明細書で使われる技術的な用語が本発明の思想を正確に表現することができない技術的な用語である場合、当業者が正確に理解することができる技術的用語に変えて理解しなければならない。また、本発明で使われる一般的な用語は、辞書の定義によってまたは前後文脈によって解釈されなければならず、過度に縮小された意味で解釈されてはならない。
【００６９】
また、本明細書で使われる単数の表現は、文脈上、明白に異なる意味ではない限り、複数の表現を含む。本出願において、“構成される”または“有する”などの用語は、明細書上に記載された多様な構成要素、または複数のステップを必ず全て含むと解釈されてはならず、そのうち一部構成要素または一部ステップは含まれない場合もあり、または追加的な構成要素またはステップをさらに含む場合もあると解釈されなければならない。
【００７０】
また、本明細書で使われる第１及び第２などのように序数を含む用語は、多様な構成要素の説明に使われるが、前記構成要素は、前記用語により限定されてはならない。前記用語は、一つの構成要素を他の構成要素から区別する目的としてのみ使われる。例えば、本発明の権利範囲を外れない限り、第１の構成要素は第２の構成要素と命名することができ、同様に、第２の構成要素も第１の構成要素と命名することができる。
【００７１】
一構成要素が他の構成要素に“連結されている”または“接続されている”と言及された場合は、該当他の構成要素に直接的に連結されており、または接続されている場合もあるが、中間に他の構成要素が存在する場合もある。それに対し、一構成要素が他の構成要素に“直接連結されている”または“直接接続されている”と言及された場合は、中間に他の構成要素が存在しないと理解しなければならない。
【００７２】
以下、添付図面を参照して本発明による好ましい実施例を詳細に説明し、図面符号に関係なしで同じまたは類似の構成要素は同じ参照番号を付与し、これに対する重複説明は省略する。また、本発明を説明するにあたって、関連した公知技術に対する具体的な説明が本発明の要旨を不明にすると判断される場合、その詳細な説明を省略する。また、添付図面は、本発明の思想を容易に理解することができるようにするためのものであり、添付図面により本発明の思想が制限されると解釈されてはならないことに留意しなければならない。本発明の思想は、添付図面外に全ての変更、均等物乃至代替物にまで拡張されると解釈されなければならない。
【００７３】
添付図面には例示的にＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）が示されているが、図示された前記ＵＥは、端末（Ｔｅｒｍｉｎａｌ）、ＭＥ（Ｍｏｂｉｌｅ  Ｅｑｕｉｐｍｅｎｔ）などの用語で呼ばれる場合もある。また、前記ＵＥは、ノートブック、携帯電話、ＰＤＡ、スマートフォン（Ｓｍａｒｔ  Ｐｈｏｎｅ）、マルチメディア機器などのように携帯可能な機器であり、またはＰＣ及び車両搭載装置のように携帯不可能な機器である。
【００７４】
＜セッション及びサービス連続性（Ｓｅｓｓｉｏｎ  ａｎｄ  Ｓｅｒｖｉｃｅ  Ｃｏｎｔｉｎｕｉｔｙ）＞
【００７５】
次世代移動通信ネットワークではセッション及びサービス連続性（ＳＳＣ）をサポートするために、多様なモードを提供する。
【００７６】
１）ＳＳＣモード１
【００７７】
ＰＤＵセッション確立過程で、ＰＤＵセッションアンカーとして動作するＵＰＦは、アクセステクノロジー（即ち、アクセスタイプ及びセル）にかかわらず維持される。ＩＰタイプのＰＤＵセッションである場合、ＩＰ連続性がＵＥの移動にかかわらずサポートされる。ＳＳＣモード１は、どのようなＰＤＵセッションタイプにも適用されることができ、併せて、どのようなアクセスタイプにも適用される。
【００７８】
２）ＳＳＣモード２
【００７９】
ＰＤＵセッションは、一つのＰＤＵセッションアンカーを有する場合、ネットワークは、ＰＤＵセッションの解除をトリガし、ＵＥに同じＰＤＵセッションの確立を指示することができる。前記新しいＰＤＵセッションの確立過程でＰＤＵセッションアンカーとして動作するＵＰＦが新しく選択される。ＳＳＣモード２は、どのようなＰＤＵセッションタイプにも適用されることができ、併せて、どのようなアクセスタイプにも適用される。
【００８０】
３）ＳＳＣモード３
【００８１】
ＳＳＣモード３に対するＰＤＵセッションに対して、ネットワークは、ＵＥと以前ＰＤＵセッションアンカーとの間の接続（ｃｏｎｎｅｃｔｉｖｉｔｙ）を解除する前に、同じデータネットワークに対する新しいＰＤＵセッションを利用するＵＥの連結確立を許容することができる。トリガ条件が適用される場合、ネットワークは、ＵＥの新しい条件に適当なＰＤＵセッションアンカー、即ち、ＵＰＦを選択するかどうかを決定することができる。ＳＳＣモード３は、どのようなＰＤＵセッションタイプにも適用されることができ、併せて、どのようなアクセスタイプにも適用される。
【００８２】
４）ＳＳＣモードの選択
【００８３】
ＵＥのアプリケーションまたはＵＥのアプリケーショングループと関連したＳＳＣモードのタイプを決定するためにＳＳＣモード選択政策が使われる。
【００８４】
事業者は、ＵＥに前記ＳＳＣモード選択政策を提供することができる。前記政策は、一つ以上のＳＳＣモード選択政策規則を含むことができる。
【００８５】
＜登録手順＞
【００８６】
ＵＥは、移動追跡（ｍｏｂｉｌｉｔｙ  ｔｒａｃｋｉｎｇ）を可能にしてデータ受信を可能にして、そしてサービスを受信するために、認可（ａｕｔｈｏｒｉｓｅ）を得る必要がある。そのために、ＵＥは、ネットワークに登録しなければならない。登録手順は、ＵＥが５Ｇシステムに対する初期登録をすべき必要がある時に実行される。また、前記登録手順は、ＵＥが周期的な登録アップデートを実行する時、アイドルモードで新しいＴＡ（ｔｒａｃｋｉｎｇ  ａｒｅａ）へ移動する時、そしてＵＥが周期的な登録更新を実行すべき必要がある時、実行される。
【００８７】
初期登録手順の間に、ＵＥのＩＤがＵＥから取得される。ＡＭＦは、ＰＥＩ（ＩＭＥＩＳＶ）をＵＤＭ、ＳＭＦ及びＰＣＦに伝達できる。
【００８８】
図７は、例示的な登録手順を示す信号流れ図である。
【００８９】
１）ＵＥは、ＲＡＮにＡＮメッセージを送信することができる。前記ＡＮメッセージは、ＡＮパラメータ、登録要求メッセージを含むことができる。前記登録要求メッセージは、登録タイプ、加入者永久ＩＤまたは臨時ユーザＩＤ、セキュリティパラメータ、ＮＳＳＡＩ、ＵＥの５Ｇ能力、ＰＤＵセッション状態などの情報を含むことができる。
【００９０】
５Ｇ  ＲＡＮである場合、前記ＡＮパラメータは、ＳＵＰＩまたは臨時ユーザＩＤ、選択されたネットワーク及びＮＳＳＡＩを含むことができる。
【００９１】
登録タイプは、ＵＥが“初期登録”（即ち、ＵＥが非登録状態にある）か、“移動性登録アップデート”（即ち、ＵＥが登録された状態であり、移動性により登録手順を開始する）か、または“定期登録アップデート”（即ち、ＵＥが登録された状態であり、周期的なアップデートタイマ満了によって登録手順を開始する）かを示すことができる。臨時ユーザＩＤが含まれている場合、前記臨時ユーザＩＤは、最後のサービングＡＭＦを示す。ＵＥが３ＧＰＰアクセスのＰＬＭＮと異なるＰＬＭＮで非３ＧＰＰアクセスを介して既に登録された場合、ＵＥは、非３ＧＰＰアクセスを介して登録手順の間にＡＭＦにより割り当てられたＵＥ臨時ＩＤを提供しない。
【００９２】
セキュリティパラメータは、認証及び完全性保護のために使われる。
【００９３】
ＰＤＵセッション状態は、ＵＥで使用可能な（以前に設定された）ＰＤＵセッションを示す。
【００９４】
２）ＳＵＰＩが含まれ、または臨時ユーザＩＤが有効なＡＭＦを示さない場合、ＲＡＮは、（Ｒ）ＡＴ及びＮＳＳＡＩに基づいてＡＭＦを選択することができる。
【００９５】
（Ｒ）ＡＮが適切なＡＭＦを選択することができない場合、ローカル政策によって任意のＡＭＦを選択し、前記選択されたＡＭＦに登録要求を伝達する。選択されたＡＭＦがＵＥをサービスすることができない場合、選択されたＡＭＦは、ＵＥのために一層適切な他のＡＭＦを選択する。
【００９６】
３）前記ＲＡＮは、新しいＡＭＦにＮ２メッセージを送信する。前記Ｎ２メッセージは、Ｎ２パラメータ、登録要求を含む。前記登録要求は、登録タイプ、加入者永久識別子または臨時ユーザＩＤ、セキュリティパラメータ、ＮＳＳＡＩ及びＭＩＣＯモード基本設定などを含むことができる。
【００９７】
５Ｇ−ＲＡＮが使われる時、Ｎ２パラメータは、ＵＥがキャンプしているセルと関連した位置情報、セル識別子及びＲＡＴタイプを含む。
【００９８】
ＵＥにより指示された登録タイプが周期的な登録更新である場合、後述する過程４〜１７は実行されない。
【００９９】
４）前記新しく選択されたＡＭＦは、以前ＡＭＦに情報要求メッセージを送信することができる。
【０１００】
ＵＥの臨時ユーザＩＤが登録要求メッセージに含まれてサービングＡＭＦが最後の登録以後変更された場合、新しいＡＭＦは、ＵＥのＳＵＰＩ及びＭＭコンテキストを要求するために、完全な登録要求情報を含む情報要求メッセージを以前ＡＭＦに送信することができる。
【０１０１】
５）以前ＡＭＦは、前記新しく選択されたＡＭＦに情報応答メッセージを送信する。前記情報応答メッセージは、ＳＵＰＩ、ＭＭコンテキスト、ＳＭＦ情報を含むことができる。
【０１０２】
具体的に、以前ＡＭＦは、ＵＥのＳＵＰＩ及びＭＭコンテキストを含む情報応答メッセージを送信する。
【０１０３】
−以前ＡＭＦに活性ＰＤＵセッションに対する情報がある場合、前記以前ＡＭＦにはＳＭＦのＩＤ及びＰＤＵセッションＩＤを含むＳＭＦ情報を前記情報応答メッセージ内に含ませることができる。
【０１０４】
６）前記新しいＡＭＦは、ＳＵＰＩがＵＥにより提供されない、または以前ＡＭＦから検索されない場合、ＵＥにＩｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔメッセージを送信する。
【０１０５】
７）前記ＵＥは、前記ＳＵＰＩを含むＩｄｅｎｔｉｔｙ  Ｒｅｓｐｏｎｓｅメッセージを前記新しいＡＭＦに送信する。
【０１０６】
８）ＡＭＦは、ＡＵＳＦをトリガすると決定できる。この場合、ＡＭＦは、ＳＵＰＩに基づいて、ＡＵＳＦを選択することができる。
【０１０７】
９）ＡＵＳＦは、ＵＥ及びＮＡＳセキュリティ機能の認証を開始することができる。
【０１０８】
１０）前記新しいＡＭＦは、以前ＡＭＦに情報応答メッセージを送信することができる。
【０１０９】
もし、ＡＭＦが変更された場合、新しいＡＭＦは、ＵＥ  ＭＭコンテキストの伝達を確認するために、前記情報応答メッセージを送信することができる。
【０１１０】
−認証／セキュリティ手順が失敗すると、登録は拒絶され、新しいＡＭＦは、以前ＡＭＦに拒絶メッセージを送信することができる。
【０１１１】
１１）前記新しいＡＭＦは、ＵＥにＩｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔメッセージを送信することができる。
【０１１２】
ＰＥＩがＵＥにより提供されない、または以前ＡＭＦから検索されない場合、ＡＭＦがＰＥＩを検索するためにＩｄｅｎｔｉｔｙ  Ｒｅｑｕｅｓｔメッセージが送信される。
【０１１３】
１２）前記新しいＡＭＦは、ＭＥ識別子を検査する。
【０１１４】
１３）後述する過程１４が実行されると、前記新しいＡＭＦは、ＳＵＰＩに基づいてＵＤＭを選択する。
【０１１５】
１４）最終登録以後にＡＭＦが変更され、またはＡＭＦでＵＥに対する有効な加入コンテキストがない、またはＵＥがＡＭＦで有効なコンテキストを参照しないＳＵＰＩを提供すると、新しいＡＭＦは、位置更新（Ｕｐｄａｔｅ  Ｌｏｃａｔｉｏｎ）手順を開始する。または、ＵＤＭが以前ＡＭＦに対する位置取消（Ｃａｎｃｅｌ  Ｌｏｃａｔｉｏｎ）を開始する場合にも開始される。以前ＡＭＦは、ＭＭコンテキストを廃棄して可能な全てのＳＭＦ（ら）に通知し、新しいＡＭＦは、ＡＭＦ関連加入データをＵＤＭから得た後にＵＥに対するＭＭコンテキストを生成する。
【０１１６】
ネットワークスライシングが使われる場合、ＡＭＦは、要求されたＮＳＳＡＩ、ＵＥ加入及びローカル政策に基づいて許容されたＮＳＳＡＩを取得する。ＡＭＦが許容されたＮＳＳＡＩをサポートするのに適しない場合、登録要求を再びルーティングする。
【０１１７】
１５）前記新しいＡＭＦは、ＳＵＰＩに基づいてＰＣＦを選択することができる。
【０１１８】
１６）前記新しいＡＭＦは、ＵＥ  Ｃｏｎｔｅｘｔ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ  ＲｅｑｕｅｓｔメッセージをＰＣＦに送信する。前記ＡＭＦは、ＰＣＦにＵＥに対する運営者政策を要求することができる。
【０１１９】
１７）前記ＰＣＦは、ＵＥ  Ｃｏｎｔｅｘｔ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ａｃｋｎｏｗｌｅｄｇｅｄメッセージを前記新しいＡＭＦに送信する。
【０１２０】
１８）前記新しいＡＭＦは、ＳＭＦにＮ１１要求メッセージを送信する。
【０１２１】
具体的に、ＡＭＦが変更されると、新しいＡＭＦは、各ＳＭＦにＵＥをサービスする新しいＡＭＦを通知する。ＡＭＦは、利用可能なＳＭＦ情報でＵＥからのＰＤＵセッション状態を検証する。ＡＭＦが変更された場合、使用可能なＳＭＦ情報が以前ＡＭＦから受信される。新しいＡＭＦは、ＵＥで活性化されないＰＤＵセッションと関連したネットワークリソースを解除するようにＳＭＦに要求することができる。
【０１２２】
１９）前記新しいＡＭＦは、Ｎ１１応答メッセージをＳＭＦに送信する。
【０１２３】
２０）前記以前ＡＭＦは、ＵＥ  Ｃｏｎｔｅｘｔ  Ｔｅｒｍｉｎａｔｉｏｎ  ＲｅｑｕｅｓｔメッセージをＰＣＦに送信する。
【０１２４】
前記以前ＡＭＦがＰＣＦでＵＥコンテキストが設定されるように以前に要求した場合、前記以前ＡＭＦは、ＰＣＦでＵＥコンテキストを削除させることができる。
【０１２５】
２１）前記ＰＣＦは、以前ＡＭＦにＵＥ  Ｃｏｎｔｅｘｔ  Ｔｅｒｍｉｎａｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージを送信することができる。
【０１２６】
２２）前記新しいＡＭＦは、登録受諾メッセージをＵＥに送信する。前記登録受諾メッセージは、臨時ユーザＩＤ、登録領域、移動性制限、ＰＤＵセッション状態、ＮＳＳＡＩ、定期登録アップデートタイマ及び許容されたＭＩＣＯモードを含むことができる。
【０１２７】
前記ＡＭＦが新しい臨時ユーザＩＤを割り当てる場合、臨時ユーザＩＤが前記登録受諾メッセージ内にさらに含まれる。移動性制限がＵＥに適用される場合、移動性制限を指示する情報が前記登録受諾メッセージ内に追加的に含まれる。ＡＭＦは、ＵＥに対するＰＤＵセッション状態を示す情報を登録受諾メッセージ内に含ませることができる。ＵＥは、受信されたＰＤＵセッション状態で活性と表示されないＰＤＵセッションと関連した任意の内部リソースを除去することができる。ＰＤＵセッション状態情報がＲｅｇｉｓｔｒａｔｉｏｎ  Ｒｅｑｕｅｓｔにある場合、ＡＭＦは、ＵＥにＰＤＵセッション状態を示す情報を前記登録受諾メッセージ内に含ませることができる。
【０１２８】
２３）前記ＵＥは、前記新しいＡＭＦに登録完了メッセージを送信する。
【０１２９】
＜ＰＤＵセッション確立手順＞
【０１３０】
ＰＤＵセッション確立手順は、下記のように二つの類型のＰＤＵセッション確立手順が存在できる。
【０１３１】
−ＵＥが開始するＰＤＵセッション確立手順
【０１３２】
−ネットワークが開始するＰＤＵセッション確立手順。そのために、ネットワークは、装置トリガメッセージをＵＥのアプリケーション（ら）に送信できる。
【０１３３】
図８は、例示的なＰＤＵセッション確立手順を示す信号流れ図である。
【０１３４】
図８に示す手順は、図７に示す登録手順によって、ＵＥがＡＭＦ上に既に登録したと仮定する。したがって、ＡＭＦは、既にＵＤＭからユーザ加入データを取得したと仮定する。
【０１３５】
１）ＵＥは、ＡＭＦにＮＡＳメッセージを送信する。前記メッセージは、Ｓ−ＮＳＳＡＩ、ＤＮＮ、ＰＤＵセッションＩＤ、要求タイプ、Ｎ１  ＳＭ情報などを含むことができる。
【０１３６】
新しいＰＤＵセッションを確立するために、ＵＥは、新しいＰＤＵセッションＩＤを生成することができる。
【０１３７】
ＵＥは、ＰＤＵセッション確立要求メッセージをＮ１  ＳＭ情報内に含ませたＮＡＳメッセージを送信することによってＵＥにより開始されるＰＤＵセッション確立手順を開始することができる。前記ＰＤＵセッション確立要求メッセージは、要求タイプ、ＳＳＣモード、プロトコル構成オプションを含むことができる。
【０１３８】
ＰＤＵセッション確立が新しいＰＤＵセッションを設定するためのものである場合、要求タイプは“初期要求”を示す。しかし、３ＧＰＰアクセスと非３ＧＰＰアクセスとの間の既存ＰＤＵセッションが存在する場合、前記要求タイプは、“既存ＰＤＵセッション”を示すことができる。
【０１３９】
前記ＵＥにより送信されるＮＡＳメッセージは、ＡＮによりＮ２メッセージ内にカプセル化される。前記Ｎ２メッセージは、ＡＭＦに送信され、ユーザ位置情報及びアクセス技術タイプ情報を含むことができる。
【０１４０】
−Ｎ１  ＳＭ情報は、外部ＤＮによるＰＤＵセッション認証に対する情報が含まれたＳＭ  ＰＤＵ  ＤＮ要求コンテナを含むことができる。
【０１４１】
２）ＡＭＦは、メッセージが前記要求タイプが“初期要求”を示す場合、そして前記ＰＤＵセッションＩＤがＵＥの既存ＰＤＵセッションのために使われない場合、新しいＰＤＵセッションに対する要求に該当すると決定できる。
【０１４２】
ＮＡＳメッセージがＳ−ＮＳＳＡＩを含まない場合、ＡＭＦは、ＵＥ加入によって要求されたＰＤＵセッションに対するデフォルトＳ−ＮＳＳＡＩを決定することができる。ＡＭＦは、ＰＤＵセッションＩＤとＳＭＦのＩＤとを関連付けられて格納することができる。
【０１４３】
３）ＡＭＦは、ＳＭ要求メッセージをＳＭＦに送信する。前記ＳＭ要求メッセージは、加入者永久ＩＤ、ＤＮＮ、Ｓ−ＮＳＳＡＩ、ＰＤＵセッションＩＤ、ＡＭＦ  ＩＤ、Ｎ１  ＳＭ情報、ユーザ位置情報、アクセス技術類型を含むことができる。前記Ｎ１  ＳＭ情報は、ＰＤＵセッションＩＤ、ＰＤＵセッション確立要求メッセージを含むことができる。
【０１４４】
ＡＭＦ  ＩＤは、ＵＥをサービスするＡＭＦを識別するために使われる。Ｎ１  ＳＭ情報は、ＵＥから受信されたＰＤＵセッション確立要求メッセージを含むことができる。
【０１４５】
４ａ）ＳＭＦは、加入者データ要求メッセージをＵＤＭに送信する。前記加入者データ要求メッセージは、加入者永久ＩＤ、ＤＮＮを含むことができる。
【０１４６】
前記過程３における要求タイプが“既存ＰＤＵセッション”を示す場合、ＳＭＦは、該当要求が３ＧＰＰアクセスと非３ＧＰＰアクセスとの間のハンドオーバに起因したと決定する。ＳＭＦは、ＰＤＵセッションＩＤに基づいて既存ＰＤＵセッションを識別することができる。
【０１４７】
ＳＭＦがまだＤＮＮと関連したＵＥに対するＳＭ関連加入データを検索しない場合、ＳＭＦは、加入データを要求することができる。
【０１４８】
４ｂ）ＵＤＭは、加入データ応答メッセージをＳＭＦに送信できる。
【０１４９】
加入データには認証された要求タイプ、認証されたＳＳＣモード、基本ＱｏＳプロファイルに対する情報が含まれる。
【０１５０】
ＳＭＦは、ＵＥ要求がユーザ加入及びローカル政策を守るかどうかを確認することができる。または、ＳＭＦは、ＡＭＦにより伝達されたＮＡＳ  ＳＭシグナリング（関連ＳＭ拒否原因を含む）を介してＵＥ要求を拒絶し、ＳＭＦは、ＡＭＦにＰＤＵセッションＩＤが解除されたと見なされるべきことを知らせる。
【０１５１】
５）ＳＭＦは、ＵＰＦを介してＤＮにメッセージを送信する。
【０１５２】
具体的に、ＳＭＦがＰＤＵセッション確立を承認／認証しなければならない場合、ＳＭＦは、ＵＰＦを選択してＰＤＵをトリガする。
【０１５３】
ＰＤＵセッション確立認証／権限付与が失敗すると、ＳＭＦは、ＰＤＵセッション確立手順を終了してＵＥに拒絶を知らせる。
【０１５４】
６ａ）動的ＰＣＣが配布されると、ＳＭＦはＰＣＦを選択する。
【０１５５】
６ｂ）ＳＭＦは、ＰＤＵセッションに対する基本ＰＣＣ規則を得るためにＰＣＦ側にＰＤＵ−ＣＡＮセッション確立を開始することができる。過程３における要求タイプが“既存ＰＤＵセッション”を示す場合、ＰＣＦは、その代わりにＰＤＵ−ＣＡＮセッション修正を開始することができる。
【０１５６】
７）過程３の要求タイプが“初期要求”を示す場合、ＳＭＦは、ＰＤＵセッションに対するＳＳＣモードを選択する。過程５が実行されない場合、ＳＭＦは、ＵＰＦも選択できる。要求タイプＩＰｖ４またはＩＰｖ６の場合、ＳＭＦは、ＰＤＵセッションに対するＩＰアドレス／プレフィクス（ｐｒｅｆｉｘ）を割り当てることができる。
【０１５７】
８）動的ＰＣＣが配置され、ＰＤＵ−ＣＡＮセッション確立がまだ完了しない場合、ＳＭＦは、ＰＤＵ−ＣＡＮセッション開始を開始することができる。
【０１５８】
９）要求タイプが“初期要求”を示して過程５が実行されない場合、ＳＭＦは、選択されたＵＰＦを使用してＮ４セッション確立手順を開始し、または選択したＵＰＦを使用してＮ４セッション修正手順を開始することができる。
【０１５９】
９ａ）ＳＭＦは、ＵＰＦにＮ４セッション確立／修正要求メッセージを送信する。そして、前記ＳＭＦは、ＰＤＵセッションに対してＵＰＦに設置されるパケット探知、施行及び報告規則を提供することができる。ＳＭＦがＣＮトンネル情報を割り当てる場合、ＣＮトンネル情報がＵＰＦに提供される。
【０１６０】
９ｂ）ＵＰＦは、Ｎ４セッション確立／修正応答メッセージを送信することによって、応答できる。ＣＮトンネル情報がＵＰＦにより割り当てられる場合、ＣＮトンネル情報がＳＭＦに提供される。
【０１６１】
１０）前記ＳＭＦは、ＳＭ応答メッセージをＡＭＦに送信する。前記メッセージは、原因、Ｎ２  ＳＭ情報、Ｎ１  ＳＭ情報を含むことができる。前記Ｎ２  ＳＭ情報は、ＰＤＵセッションＩＤ、ＱｏＳプロファイル、ＣＮトンネル情報を含むことができる。前記Ｎ１  ＳＭ情報は、ＰＤＵセッション確立受諾メッセージを含むことができる。前記ＰＤＵセッション確立受諾メッセージは、許可されたＱｏＳ規則、ＳＳＣモード、Ｓ−ＮＳＳＡＩ、割り当てられたＩＰｖ４アドレスを含むことができる。
【０１６２】
Ｎ２  ＳＭ情報は、ＡＭＦがＲＡＮに伝達しなければならない情報として下記のようなもの等を含むことができる。
【０１６３】
−ＣＮトンネル情報：これはＰＤＵセッションに該当するＮ３トンネルのコアネットワークアドレスに該当する。
【０１６４】
−ＱｏＳプロファイル：これはＲＡＮにＱｏＳパラメータとＱｏＳ流れ識別子との間のマッピングを提供するために使われる。
【０１６５】
−ＰＤＵセッションＩＤ：これはＵＥに対するＡＮシグナリングによりＵＥに対するＡＮリソースとＰＤＵセッションとの間の関連をＵＥに示すために使われる。
【０１６６】
一方、Ｎ１  ＳＭ情報は、ＡＭＦがＵＥに提供しなければならないＰＤＵセッション受諾メッセージを含む。
【０１６７】
多重ＱｏＳ規則は、ＰＤＵセッション確立受諾メッセージ内のＮ１  ＳＭ情報及びＮ２  ＳＭ情報内に含まれる。
【０１６８】
−また、ＳＭ応答メッセージは、ＰＤＵセッションＩＤ及びＡＭＦがどのようなターゲットＵＥだけでなく、ＵＥのためにどのようなアクセスが使われなければならないかを決定することができるようにする情報を含む。
【０１６９】
１１）ＡＭＦは、ＲＡＮにＮ２  ＰＤＵセッション要求メッセージを送信する。前記メッセージは、Ｎ２  ＳＭ情報、ＮＡＳメッセージを含むことができる。前記ＮＡＳメッセージは、ＰＤＵセッションＩＤ、ＰＤＵセッション確立受諾メッセージを含むことができる。
【０１７０】
ＡＭＦは、ＰＤＵセッションＩＤ及びＰＤＵセッション確立受諾メッセージを含むＮＡＳメッセージを送信することができる。また、ＡＭＦは、ＳＭＦから受信Ｎ２  ＳＭ情報をＮ２  ＰＤＵセッション要求メッセージ内に含ませてＲＡＮに送信する。
【０１７１】
１２）ＲＡＮは、ＳＭＦから受信された情報と関連したＵＥとの特定シグナリング交換をすることができる。
【０１７２】
また、ＲＡＮは、ＰＤＵセッションに対してＲＡＮ  Ｎ３トンネル情報を割り当てる。
【０１７３】
ＲＡＮは、過程１０で提供されたＮＡＳメッセージをＵＥに伝達する。前記ＮＡＳメッセージは、ＰＤＵセッションＩＤ、Ｎ１  ＳＭ情報を含むことができる。前記Ｎ１  ＳＭ情報は、ＰＤＵセッション確立受諾メッセージを含むことができる。
【０１７４】
ＲＡＮは、必要なＲＡＮリソースが設定され、ＲＡＮトンネル情報の割当が成功裏になされる場合にのみＮＡＳメッセージをＵＥに送信する。
【０１７５】
１３）ＲＡＮは、ＡＭＦにＮ２  ＰＤＵセッション応答メッセージを送信する。前記メッセージは、ＰＤＵセッションＩＤ、原因、Ｎ２  ＳＭ情報を含むことができる。前記Ｎ２  ＳＭ情報は、ＰＤＵセッションＩＤ、（ＡＮ）トンネル情報、許容／拒否されたＱｏＳプロファイル目録を含むことができる。
【０１７６】
−ＲＡＮトンネル情報は、ＰＤＵセッションに該当するＮ３トンネルのアクセスネットワークアドレスに該当できる。
【０１７７】
１４）ＡＭＦは、ＳＭ要求メッセージをＳＭＦに送信できる。前記ＳＭ要求メッセージは、Ｎ２  ＳＭ情報を含むことができる。ここで、前記ＡＭＦは、ＲＡＮで受信したＮ２  ＳＭ情報をＳＭＦに伝達する。
【０１７８】
１５ａ）前記ＰＤＵセッションに対するＮ４セッションが既に設定されない場合、ＳＭＦは、ＵＰＦと共にＮ４セッション確立手順を開始することができる。そうでない場合、ＳＭＦは、ＵＰＦを使用してＮ４セッション修正手順を開始することができる。ＳＭＦは、ＡＮトンネル情報とＣＮトンネル情報を提供することができる。ＣＮトンネル情報は、ＳＭＦが過程８でＣＮトンネル情報を選択した場合にのみ提供すべきである。
【０１７９】
１５ｂ）前記ＵＰＦは、ＳＭＦにＮ４セッション確立／修正応答メッセージを送信することができる。
【０１８０】
１６）ＳＭＦは、ＳＭ応答メッセージをＡＭＦに送信できる。この過程が終われると、ＡＭＦは、関連イベントをＳＭＦに伝達できる。ＲＡＮトンネル情報が変更され、またはＡＭＦが再配置されるハンドオーバ時に発生する。
【０１８１】
１７）ＳＭＦは、ＵＰＦを介してＵＥに情報を送信する。具体的に、ＰＤＵ  Ｔｙｐｅ  ＩＰｖ６の場合、ＳＭＦは、ＩＰｖ６  Ｒｏｕｔｅｒ  Ａｄｖｅｒｔｉｓｅｍｅｎｔを生成し、これをＮ４とＵＰＦを介してＵＥに送信できる。
【０１８２】
１８）ＰＤＵセッション確立要求が３ＧＰＰアクセスと非３ＧＰＰアクセスとの間のハンドオーバに起因した場合、即ち、要求タイプが“既存ＰＤＵセッション”に設定されると、ＳＭＦは、ソースアクセス（３ＧＰＰまたは非３ＧＰＰアクセス）を介してユーザ平面を解除する。
【０１８３】
１９）ＳＭＦのＩＤがＤＮＮ加入コンテキストのＵＤＭにより過程４ｂに含まれない場合、ＳＭＦは、ＳＭＦアドレス及びＤＮＮを含んで“ＵＤＭ＿Ｒｅｇｉｓｔｅｒ  ＵＥ  ｓｅｒｖｉｎｇ  ＮＦサービス”を呼び出すことができる。ＵＤＭは、ＳＭＦのＩＤ、アドレス及び関連ＤＮＮを格納することができる。
【０１８４】
手順中にＰＤＵセッション確立が成功裏になされない場合、ＳＭＦはＡＭＦに知らせる。
【０１８５】
＜信頼されない非３ＧＰＰアクセスを介した登録手順＞
【０１８６】
本節ではＵＥが信頼されない非３ＧＰＰアクセスネットワークを介して５ＧＣネットワークに登録する手順に対して説明する。
【０１８７】
図９は、信頼されない非３ＧＰＰアクセスを介した登録手順を示す信号流れ図である。
【０１８８】
１）ＵＥは、信頼されない非３ＧＰＰアクセスネットワークに接続し、ＩＰアドレスの割当を受ける。この過程で、任意の非３ＧＰＰ認証方法が使われる。ＵＥが５ＧＣネットワークにアタッチ（ａｔｔａｃｈ）すると決定すると、ＵＥは、５Ｇ  ＰＬＭＮでＮ３ＩＷＦのＩＰアドレスを探す。
【０１８９】
２）ＵＥは、ＩＫＥｖ２シグナリング手順を始めてＮ３ＩＷＦと共にＩＰｓｅｃ  ＳＡを設定する。２ａ過程後に全ての後続ＩＫＥｖ２メッセージが暗号化されて完全性が保障される。Ｎ３ＩＷＦは、ＥＡＰ認証者として動作し、ＵＥのネットワークアクセス識別子（ＮＡＩ）を検索する。過程２ｄで、ＵＥは、登録タイプ、永久ユーザＩＤまたは臨時ユーザＩＤ及びネットワークスライスのような登録パラメータとＮＳＳＡＩを含む３ＧＰＰ−固有なＶＩＤ（Ｖｅｎｄｏｒ  Ｉｄ）ペイロードを伝達することができる。ＵＥが３ＧＰＰアクセスを介してＰＬＭＮに既に登録されており、過程１で選択されたＮ３ＩＷＦがＰＬＭＮに位置しない場合、ＵＥは、自分の臨時ＩＤを登録パラメータ内に含ませない。
【０１９０】
３）Ｎ３ＩＷＦは、受信された登録パラメータとローカル政策に基づいてＡＭＦを選択することができる。その後、ＵＥの代わりに登録要求メッセージを生成し、Ｎ２インターフェースを介してＡＭＦに送信できる。前記登録要求メッセージは、登録パラメータ、ＥＡＰ−ＲＥＳ／Ｉｄｅｎｔｉｔｙを含むことができる。前記登録要求メッセージは、Ｎ２メッセージ内にカプセル化される。前記Ｎ２メッセージは、“信頼されない非３ＧＰＰアクセス”を示すアクセスタイプを含むことができる。ＵＥの臨時ユーザＩＤが登録パラメータに含まれている場合、ＡＭＦは、他のＡＭＦからＵＥのＳＵＰＩ及びＭＭ  Ｃｏｎｔｅｘｔを要求することができる。
【０１９１】
４）ＡＭＦは、ＡＵＳＦを選択し、ＡＵＳＦにＡｕｔｈ＿Ｒｅｑメッセージを送ることによって、ＡＵＳＦにＵＥの認証を要求することができる。前記メッセージは、ＥＡＰ−ＲＥＳ／Ｉｄｅｎｔｉｔｙを含むことができる。ＡＵＳＦは、ＥＡＰサーバとして動作しなければならず、ＵＥを認証するためにＥＡＰ方法を選択しなければならない。ＵＥ加入情報及びＵＥのＮＡＩに含まれている情報に基づいて決定される。ＡＵＳＦは、ＵＤＭからＵＥ加入情報を取得することができる。
【０１９２】
５）ＥＡＰベースの相互認証手順は、ＵＥとＡＵＳＦとの間で実行する。選択されたＥＡＰ認証方法によって、ＵＥとＡＵＳＦとの間に多様なＥＡＰ要求／応答メッセージが送信される。ＵＥとＮ３ＩＷＦとの間でＥＡＰメッセージは、ＩＫＥｖ２メッセージ内にカプセル化される。Ｎ３ＩＷＦとＡＭＦとの間でＥＡＰメッセージは、ＮＡＳ認証要求／応答メッセージ内にカプセル化され、これは順序にＮ２  ＮＡＳ  ＤＬ／ＵＬ送信メッセージにカプセル化される。ＡＭＦとＡＵＳＦとの間でＥＡＰメッセージは、Ａｕｔｈ＿Ｒｅｑ／Ｒｅｓメッセージ内にカプセル化される。
【０１９３】
６ａ）ＥＡＰベースの相互認証手順が成功裏に完了すると、ＡＵＳＦは、Ａｕｔｈ＿ＲｅｓメッセージをＡＭＦに送信する。前記メッセージは、ＥＡＰ成功、セキュリティキーを含むことができる。セキュリティキーには、ＮＡＳセキュリティキーと、セキュリティキー（Ｎ３ＩＷＦ）を生成するためにＡＭＦで使用する一つ以上のマスターセッションキーと、が含まれる。
【０１９４】
６ｂ）ＡＭＦは、Ｎ３ＩＷＦにＤＬ  ＮＡＳ  Ｔｒａｎｓｐｏｒｔメッセージを送信する。このメッセージにはＥＡＰ成功メッセージ、Ｎ３ＩＷＦのセキュリティキー及びＮＡＳセキュリティモード命令（ＳＭＣ）要求が含まれる。この過程後、Ｎ３ＩＷＦは、ＵＥ身元、関連Ｎ２連結などのようなＵＥ特定情報を格納するＵＥ  Ｃｏｎｔｅｘｔを生成することができる。
【０１９５】
６ｃ−６ｄ）Ｎ３ＩＷＦは、ＩＫＥ＿ＡＵＴＨ応答メッセージをＵＥに送信できる。それによって、ＵＥとＮ３ＩＷＦとの間でＩＰｓｅｃ  ＳＡの設定が完了する。このＩＰｓｅｃ  ＳＡ（“ｓｉｇｎａｌｉｎｇ  ＩＰｓｅｃ  ＳＡ”という）は、ＵＥとＮ３ＩＷＦとの間にＮＡＳメッセージを安全に送信する時に使われる。ＮＡＳメッセージは、ＩＰｓｅｃを介してＧＲＥにカプセル化される。過程６ｃ以後に、ＩＫＥｖ２メッセージは、シグナリングＩＰｓｅｃ  ＳＡの設定を完了するために送信される。
【０１９６】
７）Ｎ３ＩＷＦは、設定されたシグナリングＩＰｓｅｃ  ＳＡを介して過程６ｂでＡＭＦから受信されたＮＡＳ  ＳＭＣ要求をＵＥに送信できる。ＵＥは、ＮＡＳ  ＳＭＣ完了メッセージを送信する。これはＮ３ＩＷＦによりＮ２  ＵＬ  ＮＡＳ送信メッセージ内で含まれてＡＭＦに伝達される。
【０１９７】
８）ＡＭＦは、Ｎ２初期コンテキスト設定要求メッセージ内にＮＡＳ登録承認メッセージを含ませてＮ３ＩＷＦに送信する。Ｎ２初期コンテキスト設定要求は、設定されたシグナリングＩＰｓｅｃ  ＳＡを介してＵＥに伝達される。最後に、ＵＥは、Ｎ３ＩＷＦによりＡＭＦにフォワーディングされなければならないＮＡＳ登録完了メッセージをＮ２初期コンテキスト設定応答メッセージ内に含ませて送信する。
【０１９８】
＜信頼されない非３ＧＰＰアクセスを介したＵＥのＰＤＵセッション確立手順＞
【０１９９】
本節では信頼されない非３ＧＰＰアクセスネットワークを介してＰＤＵセッションを確立する手順に対して説明する。
【０２００】
図１０は、信頼されない非３ＧＰＰアクセスを介したＵＥのＰＤＵセッション確立手順を示す流れ図である。
【０２０１】
まず、ＵＥは、信頼できない非３ＧＰＰアクセスネットワークを介して５ＧＣネットワークに登録手順を実行完了したと仮定する。
【０２０２】
１）ＵＥは、ＡＭＦにＰＤＵセッション確立要求メッセージを送信する。前記ＰＤＵセッション確立要求メッセージは、図８を参照して詳述したように、ＰＤＵセッションのＩＤ、要求タイプ、ＳＳＣモード、プロトコル構成オプションを含むことができる。前記ＰＤＵセッション確立要求メッセージは、ＮＡＳ信号のために設定されたＩＰｓｅｃ  ＳＡを介してＮ３ＩＷＦに送信される。前記Ｎ３ＩＷＦは、前記メッセージを５ＧＣネットワークのＡＭＦに伝達する。
【０２０３】
２ａ）３ＧＰＰアクセスを介したＰＤＵセッション確立手順が実行される。
【０２０４】
２ｂ）ＡＭＦは、Ｎ３ＩＷＦにＰＤＵセッションに対するアクセスリソースを設定するためにＮ２  ＰＤＵセッション確立要求メッセージを送信する。前記ＰＤＵセッション確立要求メッセージは、図８を参照して詳述したように、ＰＤＵセッションのＩＤ、要求タイプ、ＳＳＣモード、プロトコル構成オプションを含むことができる。また、前記メッセージは、要求されたＰＤＵセッションの事前許可されたＱｏＳ規則のＱｏＳプロファイルを含むことができる。Ｑ−タイプＱｏＳ規則の場合、Ｎ２  ＰＤＵセッション要求メッセージは、このようなＱｏＳプロファイルに対するＱｏＳパラメータを含む。また、Ｎ２  ＰＤＵセッション要求メッセージは、ＵＥにフォワーディングされなければならないＰＤＵセッション受諾活性化メッセージを含む。
【０２０５】
３）以前ステップで受信したＱｏＳプロファイルに基づいてそして政策及び設定に基づいて、Ｎ３ＩＷＦは、確立するＩＰｓｅｃ  ｃｈｉｌｄ  ＳＡ個数と各ＩＰｓｅｃ  ｃｈｉｌｄ  ＳＡと関連したＱｏＳプロファイルを決定する。例えば、Ｎ３ＩＷＦは、ＩＰｓｅｃ  ｃｈｉｌｄ  ＳＡを設定し、全てのＱｏＳプロファイルをＩＰｓｅｃ  ｃｈｉｌｄ  ＳＡと関連させることができる。この場合、ＰＤＵセッションの全てのＱｏＳフローは、一つのＩＰｓｅｃ  ｃｈｉｌｄ  ＳＡを介して送信される。
【０２０６】
４ａ）Ｎ３ＩＷＦは、第１のＩＰｓｅｃ  ｃｈｉｌｄ  ＳＡを確立するために、ＩＫＥ  ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ要求メッセージをＵＥに送信する。前記要求メッセージは、３ＧＰＰ−固有なＶＩＤペイロードを含むことができる。前記ＶＩＤペイロードは、ｃｈｉｌｄ  ＳＡと関連したＱｏＳプロファイル、ｃｈｉｌｄ  ＳＡと関連したＰＤＵセッションのＩＤ、そしてｃｈｉｌｄ  ＳＡと関連したＤＳＣＰ値を含むことができる。ＩＫＥ  Ｃｒｅａｔｅ＿Ｃｈｉｌｄ＿ＳＡ要求メッセージは、ＳＡペイロードＮ３ＩＷＦ及びＵＥのためのＴＳ（Ｔｒａｆｆｉｃ  Ｓｅｌｅｃｔｏｒ）のような他の情報を含むことができる。
【０２０７】
４ｂ）ＵＥが新しいＩＰｓｅｃ  ｃｈｉｌｄ  ＳＡを受諾すると、ＵＥは、ＩＫＥ  Ｃｒｅａｔｅ＿Ｃｈｉｌｄ＿ＳＡ応答メッセージを送信する。ＩＰｓｅｃ  ｃｈｉｌｄ  ＳＡを確立する間に、ＵＥにＩＰアドレスにまだ割り当てられない。
【０２０８】
４ｃ−４ｄ）過程３で、Ｎ３ＩＷＦがＰＤＵセッションに対して多様なＩＰｓｅｃ  ｃｈｉｌｄ  ＳＡを確立すると決定した場合、追加ＩＰｓｅｃ  ｃｈｉｌｄ  ＳＡが確立される。前記追加ＩＰｓｅｃ  ｃｈｉｌｄ  ＳＡは、一つ以上のＱｏＳプロファイルと各々連結される。
【０２０９】
５）全てのＩＰｓｅｃ  ｃｈｉｌｄ  ＳＡが確立されると、Ｎ３ＩＷＦは、ステップ２ｂで受信したＰＤＵセッション確立受諾メッセージをＮＡＳシグナリングのためのＩＰｓｅｃ  ＳＡを介してＵＥに伝達する。
【０２１０】
６）Ｎ３ＩＷＦは、ＡＭＦにＮ２  ＰＤＵセッション要求確認（Ａｃｋ）メッセージを送信する。
【０２１１】
７）３ＧＰＰアクセスを介したＰＤＵセッション確立手順が実行される。
【０２１２】
８）ユーザ平面で、
【０２１３】
ＵＥがＵＬ  ＰＤＵを送信する場合、ＵＥは（ＰＤＵにセッションのＱｏＳ規則を使用して）前記ＵＬ  ＰＤＵと関連したＱｏＳプロファイルを決定する。そして、前記ＵＥは、前記ＵＬ  ＰＤＵをＧＲＥパケット内にカプセル化した後、前記ＱｏＳプロファイルと関連したＩＰｓｅｃ  ｃｈｉｌｄ  ＳＡを介してＮ３ＩＷＦに送信できる。ＧＲＥパケットのヘッダは、ＵＬ  ＰＤＵと関連したＱｏＳプロファイルを送信する。
【０２１４】
−Ｎ３ＩＷＦは、Ｎ３を介してＤＬ  ＰＤＵを受信すると、Ｎ３ＩＷＦは、ＩＰＳｅｃ  ｃｈｉｌｄ  ＳＡを決定するためにＱｏＳマーキングとＰＤＵセッションの識別子を使用する。Ｎ３ＩＷＫは、ＧＲＥパケット内にＤＬ  ＰＤＵをカプセル化し、ＱｏＳマーキングをＧＲＥパケットのヘッダに複写する。したがって、Ｎ３ＩＷＦは、ＵＥにより使われるＲＩＦＩ（Ｒｅｆｌｅｃｔｉｖｅ  ＱｏＳ  Ｉｎｄｉｃａｔｏｒ）をＧＲＥヘッダに含むことができる。
【０２１５】
＜３ＧＰＰアクセスと信頼されない非３ＧＰＰアクセスとの間にＰＤＵセッションハンドオーバ手順＞
【０２１６】
図１１ａは、信頼されない非３ＧＰＰアクセスから３ＧＰＰアクセスへのＰＤＵセッションハンドオーバ手順を示す。
【０２１７】
図１１ａを参照して分かるように、ＵＥが３ＧＰＰアクセスに登録されていない場合、ＵＥは、登録手順を実行する。
【０２１８】
そして、ＵＥは、ＰＤＵセッション確立手順を実行する。
【０２１９】
図１１ｂは、３ＧＰＰアクセスから信頼されない非３ＧＰＰアクセスへのＰＤＵセッションハンドオーバ手順を示す。
【０２２０】
図１１ｂを参照して分かるように、ＵＥが信頼されない非３ＧＰＰアクセスに登録されていない場合、ＵＥは登録手順を実行する。
【０２２１】
そして、ＵＥは、ＰＤＵセッション確立手順を実行する。
【０２２２】
＜本明細書の開示＞
【０２２３】
ローミング状況で、ＵＥは、ネットワークにＰＤＵセッション確立要求メッセージを送信し、これに対する応答を受けると、ＰＤＵセッションが確立されたことを知ることができる。しかし、ＵＥは、ＰＤＵセッションがＬＢＯ（Ｌｏｃａｌ  Ｂｒｅａｋｏｕｔ）方式で確立されたか、またはＨＲ（Ｈｏｍｅ  Ｒｏｕｔｅｄ）方式で確立されたかを知ることができない。３ＧＰＰと非３ＧＰＰとの間にハンドオーバを実行するためには基本的にそれぞれの全ての同じＳＭＦが選択されて同じＵＰＦ／ＩＰアドレスの割当を受けることが必要である。もし、ローミング状況でＵＥが３ＧＰＰアクセスを介してＬＢＯ方式でＰＤＵセッションが確立した後、非３ＧＰＰにハンドオーバするためには非３ＧＰＰアクセスでもＬＢＯ方式でＰＤＵセッションが作られなければならない。しかし、ハンドオーバが考慮されずに、ＰＤＵセッションが生成された場合、問題が発生できる。例えば、非３ＧＰＰアクセスのためのＮ３ＩＷＦの選択時、ＵＥは、自分にサービスを提供しているＶＰＬＭＮ内のＮ３ＩＷＦでなくＨＰＬＭＮにあるＮ３ＩＷＦを選択することができる。この場合、３ＧＰＰアクセスではＬＢＯ方式でＰＤＵセッションが生成され、非３ＧＰＰアクセスでは非ローミング方式でＰＤＵセッションが作られることによって、ハンドオーバが実行できない状況が発生される。しかし、ＵＥは、実際ハンドオーバが成功できるかどうかを知ることができないため、ハンドオーバを試みることができ、この場合、不要なシグナリングが発生するようになる。
【０２２４】
したがって、本明細書の開示は、このような問題点を解決するための方案を提示する。
【０２２５】
Ｉ．第１の開示：ＰＤＵセッションを確立しながら、該当ＰＤＵセッションがＬＢＯ方式で確立されるか、またはＨＲ方式で確立されるかを知らせる方案
【０２２６】
現在はＵＥがＰＤＵセッションを作っても該当ＰＤＵセッションがＬＢＯ方式で作られたか、またはＨＲ方式で作られたかを知らない。第１の開示ではネットワークノード（例えば、ＳＭＦ）がＰＤＵセッション確立受諾（ＰＤＵ  Ｓｅｓｓｉｏｎ  Ｅｓｔａｂｌｉｓｈｍｅｎｔ  Ａｃｃｅｐｔ）メッセージ内にＰＤＵセッションがどのような方式で作られたかを知らせる情報を含ませることを提案する。ＵＥは、３ＧＰＰアクセス／非３ＧＰＰアクセスを介して登録を実行する時、どのようなＰＬＭＮに登録されるかを知っているため、ＰＬＭＮ情報とＰＤＵセッションが確立のために使われた方式（即ち、ＬＢＯ方式またはＨＲ方式）を知るようになると、自体的にハンドオーバが（ＨＯ）が可能かどうかを判断することができる。
【０２２７】
ａ）まず、３ＧＰＰアクセスを介して先登録された場合
【０２２８】
−ＵＥは、非３ＧＰＰアクセスに登録する前にＮ３ＩＷＦ選択を実行する。前記選択過程によって選択されたＮ３ＩＷＦが３ＧＰＰアクセスと同じＰＬＭＮに位置すると決定され、登録が成功裏に完了した場合、ＵＥは、ＰＤＵセッションの確立のために使われた方式がＬＢＯ方式か、またはＨＯ方式かにかかわらず、ＰＤＵセッションがハンドオーバされると判断できる。
【０２２９】
−しかし、前記選択過程によって選択されたＮ３ＩＷＦが３ＧＰＰアクセスと異なるＰＬＭＮに位置したと決定され、そして登録が成功裏に完了した場合、ＵＥは、３ＧＰＰアクセスのＰＤＵセッションがＨＲ方式で確立された場合にのみ、ＰＤＵセッションがハンドオーバされると判断できる。
【０２３０】
ｂ）非３ＧＰＰアクセスを介して先登録された場合、
【０２３１】
−ＵＥが３ＧＰＰアクセスに登録する過程で、非３ＧＰＰアクセスのためのＮ３ＩＷＦが位置するＰＬＭＮと同じＰＬＭＮに成功裏に登録されたと知るようになった場合、ＵＥは、ＰＤＵセッションの確立のために使われた方式がＬＢＯ方式か、またはＨＯ方式かにかかわらず、ＰＤＵセッションがハンドオーバされると判断できる。
【０２３２】
−ＵＥが３ＧＰＰアクセスに登録する過程で、非３ＧＰＰのＮ３ＩＷＦが位置するＰＬＭＮと異なるＰＬＭＮに成功裏に登録されたと知るようになった場合、ＵＥは、非３ＧＰＰアクセスを介したＰＤＵセッションがＨＲ方式で確立された場合にのみ、ＰＤＵセッションがハンドオーバされると判断できる。
【０２３３】
一方、ＳＭＦは、ＨＯ方式か、またはＬＢＯ方式かを直接的に知らせる代わりに、ハンドオーバが可能であるということを示す情報またはインジケーション（例えば、ＨＯ  ｉｎｄｉｃａｔｉｏｎ）を送信することができる。例えば、ＳＭＦは、ハンドオーバを介して生成されたＰＤＵセッションに対してハンドオーバが可能であるということを示すＨＯ  ｉｎｄｉｃａｔｉｏｎを送信することができる。ＵＥがハンドオーバ可能であるということを示すインジケーションを受信すると、３ＧＰＰアクセスを介したＰＤＵセッションと非３ＧＰＰアクセスを介したＰＤＵセッションが互いに同じＰＬＭＮ内で確立されたか、または異なるＰＬＭＮ内で確立されたかにかかわらず、ハンドオーバを実行することができる。もし、前記情報（または、インジケーション）を受信することができない場合、３ＧＰＰアクセスを介したＰＤＵセッションと非３ＧＰＰアクセスを介したＰＤＵセッションが互いに同じＰＬＭＮ内で確立された場合にのみ、ＵＥは、ハンドオーバを実行することができる。
【０２３４】
図１２は、ＰＤＵセッションを確立する時、本明細書の第１の開示によって該当ＰＤＵセッションがＬＢＯ方式でまたはＨＲ方式で確立されたかを示す方案を示す流れ図である。
【０２３５】
図１２を参照すると、ＵＥは、ＰＤＵセッション確立要求メッセージをＡＭＦに送信する。前記ＰＤＵセッション確立要求メッセージは、図８及び図１０を参照して詳述したように、ＰＤＵセッションのＩＤ、要求タイプ、ＳＳＣモード、プロトコル構成オプションを含むことができる。
【０２３６】
過程１０で、ＳＭＦは、ＰＤＵセッション受諾メッセージをＵＥに送信しながら、ＰＤＵセッションがＨＲ方式で確立されたか、またはＬＢＯ方式で確立されたかを示す情報またはインジケーションを含ませて送信できる。または、前記ＳＭＦは、ハンドオーバが可能かどうかを知らせるインジケーション（例えば、ＨＯ  Ｉｎｄｉｃａｔｉｏｎ）を含ませて送信できる。図１２の例示は、３ＧＰＰアクセスで手順を示すが、非３ＧＰＰアクセスでも同様に適用できる。
【０２３７】
II．第２の開示：登録過程中に、ＰＤＵセッションをハンドオーバさせることができるかどうかをＵＥに知らせる方案
【０２３８】
前述した第１の開示によると、ネットワークがＵＥにＰＤＵセッションがＬＢＯ方式で確立されたか、またはＨＲ方式で確立されたかを知らせなければならない。しかし、これはネットワークのトポロジー情報を提供することであるため、事業者が選好しない方案である。第２の開示では、第１の開示のような情報をＵＥに提供しない代りに、登録過程でＵＥにハンドオーバが可能であるという情報のみを知らせることを提案する。
【０２３９】
そのために、ＵＥは、ハンドオーバのために他のアクセスへの登録を実行する時、３ＧＰＰアクセスと非３ＧＰＰアクセスとの間のハンドオーバのために登録を実行することを知らせるインジケーションを伝達することができる。また、ＵＥは、前記インジケーション外に、ハンドオーバさせようとするＰＤＵセッションのＩＤも共に伝達できる。前記ＰＤＵセッションのＩＤを伝達することで、ＵＥは、どのようなＰＤＵセッションをハンドオーバさせるかを知らせることができる。
【０２４０】
また、ＡＭＦは、３ＧＰＰアクセスと非３ＧＰＰアクセスとの間のハンドオーバのために、ＵＥが登録手順を実行する場合、前記ＵＥから受信されたＰＤＵセッションＩＤに基づいてＵＤＭからＰＤＵセッション情報を取得する。そして、前記ＡＭＦは、前記ＵＤＭから取得されたＰＤＵセッション情報に基づいてハンドオーバさせようとするＰＤＵセッションＩＤを探り出す。前記ＰＤＵセッションＩＤとマッピングされるＰＤＵセッション情報をさがした場合、前記ＡＭＦは、コンテキスト情報に基づいて前記ＰＤＵセッションをハンドオーバさせるかどうかを判断する。そのために、ＳＭＦは、ＰＤＵセッションが作られる時、該当ＰＤＵセッションがＨＲ方式で確立されたか、またはＬＢＯ方式で確立されたかに対する情報をＵＤＭ内に格納することができる。即ち、図１２の過程１９で、ＳＭＦ情報とＰＤＵ情報を格納する時、該当ＰＤＵセッションがＨＲ方式で確立されたか、またはＬＢＯ方式で確立されたかに対する情報を共に格納することができる。
【０２４１】
一方、前述した通り、前記ＡＭＦは、ＰＤＵセッションＩＤとＳＭＦのＩＤを関連付けられて格納している。したがって、前記ＵＥから受信されたＰＤＵセッションＩＤが以前ＰＤＵセッションを指示する場合、前記ＡＭＦは、前記ＰＤＵセッションＩＤと関連付けられて格納されているＳＭＦのＩＤを探り出すことができる。ここで、ＳＭＦのＩＤは、ＰＬＭＮ  ＩＤを含んで構成される。したがって、ＡＭＦは、ＳＭＦのＩＤから抽出されるＰＬＭＮ  ＩＤに基づいてＡＭＦとＳＭＦが同じＰＬＭＮにあるかまたは異なるＰＬＭＮにあるかを知ることができる。もし、３ＧＰＰアクセスでローミング中であるＵＥが非３ＧＰＰアクセスでＨＰＬＭＮに連結されている状況に３ＧＰＰアクセスＰＤＵセッションを非３ＧＰＰにハンドオーバ要求する状況で、前記ＡＭＦと前記ＳＭＦが同じＰＬＭＮ内に位置する場合、該当ＰＤＵセッションがＨＲ方式で確立されたと判断できる。この場合、前記ＡＭＦは、ハンドオーバが可能であると判断できる。また、前記ＡＭＦと前記ＳＭＦが全てＨＰＬＭＮ内に位置する場合、該当ＰＤＵセッションがＨＲ方式で確立されたと判断できる。それに対し、前記ＡＭＦと前記ＳＭＦが互いに異なるＰＬＭＮに位置したと判断される場合、該当ＰＤＵセッションがＬＢＯ方式で確立されたと判断できる。この場合、ハンドオーバが不可能であると判断できる。
【０２４２】
一方、ＡＭＦは、ＵＥから受信したＰＤＵセッションＩＤとマッピングされているＰＤＵセッションが存在することを知っている場合、前記ＡＭＦは、該当ＰＤＵセッションを担当するＳＭＦを選択することができ、前記ＳＭＦにＳＭ  ｓｉｇｎａｌｌｉｎｇを伝達することができる場合、該当ＰＤＵセッションをハンドオーバさせることができると判断できる。もし、ＰＤＵセッションに対するコンテキストが存在すると、ＳＭＦが異なるＰＬＭＮ内に位置する場合にはＡＭＦがＳＭシグナリングを前記ＳＭＦに伝達することができないため、該当ＰＤＵセッションをハンドオーバさせることが不可能であると判断できる。
【０２４３】
もし、図５Ｅに示すように、３ＧＰＰアクセス及び非３ＧＰＰアクセスの両方ともＨＰＬＭＮでない他のＰＬＭＮに連結されている場合、ＰＬＭＮ情報にのみ基づいては該当ＰＤＵセッションがＨＲ方式で確立されたか、またはＬＢＯ方式で確立されたかを判断することができない。この場合、ＵＤＭに格納されているＰＤＵセッション情報に基づいて前記判断が実行される。または、ＡＭＦがＵＥのＨＰＬＭＮを知っており、ＳＭＦのＩＤがＰＬＭＮ  ＩＤを含む場合、前記ＡＭＦは、ＵＥのＨＰＬＭＮ  ＩＤとＳＭＦのＩＤから抽出可能なＰＬＭＮ  ＩＤを比較してＰＤＵセッションがＨＲ方式で確立されたかどうかを判断することができる。
【０２４４】
または、ＵＥがハンドオーバのための登録であることを知らせなくても、ＵＥが初期登録（ｉｎｉｔｉａｌ  ｒｅｇｉｓｔｒａｔｉｏｎ）または移動登録（ｍｏｂｉｌｉｔｙ  ｒｅｇｉｓｔｒａｔｉｏｎ）をする場合、ＡＭＦは、ＵＥに登録受諾メッセージを伝達しながら、ＤＮＮ別及び／またはＳ−ＮＳＳＡＩ別にハンドオーバが可能かどうかを知らせることができる。
【０２４５】
即ち、ＡＭＦは、登録受諾メッセージを送信しながら、３ＧＰＰアクセスと非３ＧＰＰアクセスとの間にハンドオーバが可能であるということを知らせることができる。ＵＥは、ＡＭＦが送るハンドオーバ可能可否に基づいて下記の通り動作できる。
【０２４６】
−ハンドオーバが可能な場合、ＵＥは、ハンドオーバ手順を実行する。
【０２４７】
−ハンドオーバが不可能な場合、ＵＥは、ＰＤＵセッションのＳＳＣモードに基づいて追加的な動作をするかどうかを決定することができる。
【０２４８】
例えば、ＵＥが移そうとしたＰＤＵセッションがＳＳＣモード２ベースのＰＤＵセッションに該当する場合、既存のＰＤＵセッションを切って新しく接続したアクセスネットワークを介して新しいＰＤＵセッションを作る。
【０２４９】
もし、ＵＥが移そうとしたＰＤＵセッションがＳＳＣモード３ベースのＰＤＵセッションに該当する場合、新しく接続したアクセスネットワークを介して既存のＰＤＵセッションを維持したまま新しいＰＤＵセッションを要求することができる。少しの間、二つのセッションを維持させることによって、前記ＵＥのアプリケーション階層が前記新しく作ったＰＤＵセッションにトラフィックを移ることができるようにする。一定時間が過ぎたり全てのトラフィックが新しいＰＤＵセッションに移動すると、ＵＥは、既存のＰＤＵセッションを切る。
【０２５０】
ＵＥが移そうとしたＰＤＵセッションがＳＳＣモード１ベースのＰＤＵセッションに該当する場合、ＳＳＣモード３のような動作を実行することができる。または、ハンドオーバを中断するようにすることができる。
【０２５１】
ＡＭＦは、登録を許容せずに登録拒絶メッセージを送信することができる。このとき、前記登録拒絶メッセージ内の原因フィールドは、ＨＯが不可能で拒絶されることを示す原因値を含むことができる。
【０２５２】
図１３は、本明細書の第２の開示によって登録過程中にＵＥにハンドオーバが可能かどうかを知らせる方案を示す流れ図である。
【０２５３】
図１３の過程１に示すように、ＵＥがハンドオーバのために新しいアクセスに登録手順を実行する場合、ＵＥは、登録要求メッセージにハンドオーバインジケーションとハンドオーバしようとするＰＤＵセッションの情報（例えば、ＰＤＵセッションＩＤ）を含めて送る。そのとき、過程２２に示すように、ＡＭＦは、前述した方案を利用してハンドオーバが可能かどうかを示す情報を含む登録受諾メッセージを送信する。前記例題は、３ＧＰＰアクセスにおける手順を示すが、前述した内容は、非３ＧＰＰでも同様に適用できる。
【０２５４】
III．第３の開示：ハンドオーバのためのＵＥのＰＤＵセッション確立要求に対して、拒絶理由値を含む拒絶メッセージを送信することによって、ＵＥの動作を制御する方案
【０２５５】
前述した第２の開示は、ネットワークがハンドオーバ可能かどうかに対する情報をＵＥに知らせる場合、ＵＥは、前記情報に基づいて直接判断してＰＤＵセッションを新しく作る等の動作を実行する。しかし、この場合、ネットワークでＵＥを所望の方向へ制御できない。したがって、本明細書の第３の開示は、後述するように提案する。具体的に、ＵＥが登録手順を実行した後、ハンドオーバのために、ＰＤＵセッション確立要求メッセージを送信すると、第３の開示は、ＡＭＦがハンドオーバ可能かどうかを判断し、前記ハンドオーバが不可能であると判断されると、拒絶原因値を含む拒絶メッセージを送信するようにする。ここで、前記ＡＭＦがハンドオーバ可能かどうかを判断する方案は、第２の開示で説明した方案と同じである。もし、拒絶原因の値が再確立要求（ｒｅ−ｅｓｔａｂｌｉｓｈ  ｒｅｑｕｉｒｅｄ）を示す場合、ＵＥは、ハンドオーバが失敗することを認知し、新しくアタッチしたアクセスネットワークを介して新しいＰＤＵセッションの確立を要求することができる。もし、拒絶原因の値がハンドオーバがサポートされない（ｈａｎｄｏｖｅｒ  ｎｏｔ  ｓｕｐｐｏｒｔｅｄ）のようにハンドオーバ不可能を示す場合、ＵＥは、ハンドオーバを中断する。拒絶原因の値は、事業者が設定した政策やＤＮＮに基づいて決定される。例えば、ＩＭＳ  ＤＮＮを使用する場合、拒絶原因の値は、再確立要求（ｒｅ−ｅｓｔａｂｌｉｓｈ  ｒｅｑｕｉｒｅｄ）を示すことによって、ＵＥがサービスを受け続けるようにすることができる。しかし、ＩｏＴ  ＤＮＮを使用する場合、前記拒絶原因の値は、ハンドオーバがサポートされない（ｈａｎｄｏｖｅｒ  ｎｏｔ  ｓｕｐｐｏｒｔｅｄ）ことを示すことによって、ＵＥがハンドオーバを実行しないようにできる。
【０２５６】
図１４は、本明細書の第３の開示によってハンドオーバのためのＰＤＵセッション確立要求に対して拒絶原因値を含むメッセージを送信することによって、ＵＥの動作を制御する方案を示す流れ図である。
【０２５７】
図１４を参照すると、前記ＵＥは、ＰＤＵセッション確立要求メッセージをＡＭＦに送信する。前記ＰＤＵセッション確立要求メッセージは、図８、図１０及び図１２を参照して詳述したように、ＰＤＵセッションのＩＤ、要求タイプ、ＳＳＣモード、プロトコル構成オプションを含むことができる。
【０２５８】
ＵＥがＰＤＵセッション確立要求メッセージを送信すると、ＡＭＦは、ハンドオーバが可能かどうかを判断する。具体的に、第２の開示で説明した通り、前記ＡＭＦは、前記受信したＰＤＵセッション確立要求メッセージ内の前記要求タイプが“既存ＰＤＵセッション”を指示し、前記受信したＰＤＵセッション確立要求メッセージ内のＰＤＵセッションＩＤが既存ＰＤＵセッションのＩＤを指示する場合、ハンドオーバが可能かどうかを判断することができる。
【０２５９】
より具体的に、前述した通り、前記ＡＭＦは、ＰＤＵセッションＩＤとＳＭＦのＩＤを関連付けられて格納している。したがって、前記ＵＥから受信した前記ＰＤＵセッション確立要求メッセージ内のＰＤＵセッションＩＤが既存ＰＤＵセッションを指示する場合、前記ＡＭＦは、前記ＰＤＵセッションＩＤと関連付けられて格納されているＳＭＦのＩＤを探り出すことができる。ここで、ＳＭＦのＩＤは、ＰＬＭＮ  ＩＤを含んで構成される。したがって、ＡＭＦは、ＳＭＦのＩＤから抽出されるＰＬＭＮ  ＩＤに基づいてＡＭＦとＳＭＦが同じＰＬＭＮにあるか、または異なるＰＬＭＮにあるかを知ることができる。もし、前記ＡＭＦと前記ＳＭＦが同じＰＬＭＮ内に位置する場合、該当ＰＤＵセッションがＨＲ方式で確立されたと判断できる。この場合、前記ＡＭＦは、ハンドオーバが可能であると判断できる。また、前記ＡＭＦと前記ＳＭＦが全てＨＰＬＭＮ内に位置する場合、該当ＰＤＵセッションがＨＲ方式で確立されたと判断できる。それに対して、前記ＡＭＦと前記ＳＭＦが互いに異なるＰＬＭＮに位置したと判断される場合、該当ＰＤＵセッションがＬＢＯ方式で確立されたと判断できる。
【０２６０】
一方、前記ＵＥから受信した前記ＰＤＵセッション確立要求メッセージ内のＰＤＵセッションＩＤが既存ＰＤＵセッションを指示する場合、前記ＡＭＦは、該当ＰＤＵセッションを担当するＳＭＦを選択することができ、前記ＳＭＦにＳＭ  ｓｉｇｎａｌｌｉｎｇを伝達することができる場合、該当ＰＤＵセッションをハンドオーバさせることができると判断できる。もし、ＰＤＵセッションに対するコンテキストが存在する場合、ＳＭＦが異なるＰＬＭＮ内に位置する時は、ＡＭＦがＳＭシグナリングを前記ＳＭＦに伝達できないため、該当ＰＤＵセッションをハンドオーバさせることが不可能であると判断できる。
【０２６１】
他方、前記ＵＥから受信した前記ＰＤＵセッション確立要求メッセージ内のＰＤＵセッションＩＤに指示される既存ＰＤＵセッションに対して前記ＡＭＦが知らない場合、前記ＡＭＦは、ＵＤＭから前記ＰＤＵセッションに対する情報を取得することができる。そして、前記ＡＭＦは、前記ＵＤＭから取得されたＰＤＵセッション情報に基づいて、前記ＰＤＵセッションをハンドオーバさせることができるかどうかを判断することができる。
【０２６２】
ハンドオーバが不可能であると判断される場合、ＡＭＦは、ＭＭ  ＮＡＳメッセージ内に拒絶原因値を含ませて送信できる。前記ＵＥは、前記拒絶原因値によって後続する動作を決定することができる。
【０２６３】
具体的に、ＵＥは、ＡＭＦが送った拒絶原因値にしたがって下記のような動作を実行することができる。
【０２６４】
（ａ）拒絶原因値が、ハンドオーバがサポートされない（ｈａｎｄｏｖｅｒ  ｎｏｔ  ｓｕｐｐｏｒｔｅｄ）、またはハンドオーバが許容されない（ＨＯ  ｉｓ  ｎｏｔ  ａｌｌｏｗｅｄ）またはペイロードがフォワーディングされないこと（ｐａｙｌｏａｄ  ｗａｓ  ｎｏｔ  ｆｏｒｗａｒｄｅｄ）を指示する場合
【０２６５】
前記ＵＥは、該当ＰＤＵセッションに対するハンドオーバをそれ以上要求しない。そして、前記ＵＥは（ＰＤＵセッションが切れたり、ＰＤＵセッションが作られたＰＬＭＮに登録解除したり、Ｎ３ＩＷＫが異なるＰＬＭＮにあるノードに変わったりする時まで）下記のような動作を実行することができる。
【０２６６】
もし、ＰＤＵセッションがＳＳＣモード１またはＳＳＣモード３である場合、ハンドオーバさせようとするＰＤＵセッションと同じＤＮＮ／Ｎ−ＳＳＡＩ／ＳＳＣモード／ＰＤＵタイプを有するＰＤＵセッションを他のアクセスを介して追加で生成する。以後、ＵＥのアプリケーション階層でハンドオーバさせようとするＰＤＵセッションにあるトラフィックを他のアクセスに移す時まで待った後、新しいＰＤＵセッションのみを残して以前のＰＤＵセッションは解除できる。
【０２６７】
もし、ＰＤＵセッションがＳＳＣモード２である場合、ＵＥは、ハンドオーバしようとするＰＤＵセッションを先に切り、新しいＰＤＵセッションを他のアクセスを介して確立した後、サービスを要求することができる。
【０２６８】
ＵＥは、ＳＳＣモードによる動作にかかわらず新しいＰＤＵセッションを要求しながら、ＰＤＵセッションをＨＲ方式で確立することを要求するインジケーションを送ることができる。ＡＭＦは、このような場合、事業者の政策または設定にしたがって前記ＵＥの加入者情報にＬＢＯが許容されていても、Ｖ−ＳＭＦとＨ−ＳＭＦを選択してＨＲ方式でＰＤＵセッションが作られるようにすることができる。この場合、選択的に、ＡＭＦは、Ｖ−ＳＭＦ／Ｈ−ＳＭＦにＰＤＵセッション確立要求メッセージを送信しながら、ＵＥがＨＲ方式を要求したことを知らせるインジケーションを含ませることもできる。Ｈ−ＳＭＦは、前記インジケーションを受信した場合、ＰＤＵセッション確立受諾メッセージにＰＤＵセッションがＨＲ方式で作られたことを示す情報を含ませることができる。前記ＵＥは、このような方法を介して作ったＰＤＵセッションの場合、ＡＭＦから同じＤＮＮ／Ｓ−ＮＳＳＡＩを有するＰＤＵセッションに対してハンドオーバが許容されないこと（ＨＯ  ｉｓ  ｎｏｔ  ａｌｌｏｗｅｄ  ｉｎｄｉｃａｔｉｏｎ）を示す拒絶原因値を含むメッセージを受信したとしても、再びハンドオーバを要求することができる。しかし、ＰＤＵセッションをＨＲ方式で確立することを要求するインジケーションを送信したにもかかわらず、ＡＭＦから再びＰＤＵセッションに対してハンドオーバが許容されないこと（ＨＯ  ｉｓ  ｎｏｔ  ａｌｌｏｗｅｄ  ｉｎｄｉｃａｔｉｏｎ）を示す拒絶原因値を含むメッセージを受信する場合、再び該当ＤＮＮ／Ｓ−ＮＳＳＡＩを有するＰＤＵセッションに対してはハンドオーバを要求しないべきである。
【０２６９】
（ｂ）拒絶原因値が混雑（Ｃｏｎｇｅｓｔｉｏｎ）を指示する場合
【０２７０】
ＡＭＦが送信するメッセージ内の拒絶原因値が混雑を指示する場合、前記メッセージは、バックオフタイマ（ｂａｃｋ−ｏｆｆ  ｔｉｍｅ）の値を共に含むことができる。前記ＵＥは、ＡＭＦから提供を受けた拒絶メッセージのバックオフタイマの値に基づいて、バックオフタイマを駆動する。この場合は、混雑状況によって拒絶される場合であるため、バックオフタイマが満了される前までは、前記ＵＥは、再び要求を試みない。即ち、ＵＥは、バックオフタイマが満了される前までハンドオーバを再びＡＭＦに要求しない。または、もし、ＡＭＦが拒絶原因値を混雑と指示したが、他のインジケーションを介してハンドオーバが許容されないこと（ＨＯ  ｉｓ  ｎｏｔ  ａｌｌｏｗｅｄ）をＵＥが知るようになった場合、前記ＵＥは、前記バックオフタイマが満了されても、再びハンドオーバを要求しない。以後の動作は、拒絶原因値がハンドオーバが許容されないこと（ＨＯ  ｉｓ  ｎｏｔ  ａｌｌｏｗｅｄ  ｉｎｄｉｃａｔｉｏｎ）を指示した時と同じである。
【０２７１】
その代案として、拒絶原因値が混雑（Ｃｏｎｇｅｓｔｉｏｎ）を指示したとしても、拒絶原因値がハンドオーバが許容されないこと（ＨＯ  ｉｓ  ｎｏｔ  ａｌｌｏｗｅｄ  ｉｎｄｉｃａｔｉｏｎ）を指示した時と同様に、ＵＥが動作できる。
【０２７２】
IV．第４の開示：ＵＥが同じＰＬＭＮを介してネットワークに連結された場合にのみハンドオーバを許容する方案
【０２７３】
ＵＥがハンドオーバのために、他のアクセスネットワークを介して登録手順を実行完了した場合、本明細書の第４の開示は、３ＧＰＰアクセスネットワーク及び非３ＧＰＰアクセスネットワークが全て同じＰＬＭＮに位置する場合にのみ、前記ＵＥのＰＤＵセッションをハンドオーバさせるようにすることができる。他の開示と比較して追加的なインジケーションや手順が必要でないという長所がある。しかし、状況によっては、ハンドオーバが可能であるにもかかわらず、ＵＥがハンドオーバできない場合が発生されることもある。
【０２７４】
Ｖ．第５の開示：ＰＤＵセッションを確立する過程で該当ＰＤＵセッションがハンドオーバ可能かを知らせる方案
【０２７５】
第５の開示によると、ネットワークは、ＰＤＵセッションがＨＲ方式で確立されたか、またはＬＢＯ方式で確立されたかに対する情報をＵＥに知らせない代わりに、ハンドオーバが可能かまたは不可能かを直接的に知らせる情報をＵＥに送信することができる。この場合、ＵＥは、ＰＤＵセッションがＨＲ方式で確立されたか、またはＬＢＯ方式で確立されたかを知らないまま、単純にハンドオーバが可能かどうかのみを示す情報に基づいて、ハンドオーバを実行するかどうかを判断することができる。例えば、ネットワークで同じＤＮＮでＰＤＵセッションを複数個確立でき、このうち、ＳＳＣモード１ベースのＰＤＵセッションはハンドオーバが可能であると知らせ、ＳＳＣモード２／３ベースのＰＤＵセッションはハンドオーバが不可能であると知らせることができる。この場合、ＵＥは、ＳＳＣモード１ベースのＰＤＵセッションのみをハンドオーバさせることができる。ＳＳＣモード２の場合は、ＳＳＣモードの定義にしたがって既存のＰＤＵセッションを切った後、新しいＰＤＵセッションを確立する作業をすることができる。この場合、ハンドオーバが実行されるものではなく、既存アクセスを介したＰＤＵセッションを切って新しいアクセスを介して新しいＰＤＵセッションを確立することができる。ＳＳＣモード３の場合、一定時間の間、平行に（ｐａｒａｌｌｅｌ）複数のＰＤＵセッションを確立することができるようにするため、以前アクセスを介した第１のＰＤＵセッションを維持したまま新しいアクセスを介して第２のＰＤＵセッションを確立し、トラフィックを新しく作った第２のＰＤＵセッションを経由するように移した以後、以前の第１のＰＤＵセッションを切る作業をする。
【０２７６】
または、ネットワークで作ったＰＤＵセッションが特定スライスと連結されており、該当スライスが特定アクセスでのみ使用可能になっている場合、ネットワークは、ハンドオーバが不可能であることをＵＥに知らせることができる。
【０２７７】
この方案を使用すると、ＵＥがあらかじめ両側アクセスを介して登録完了した場合、ＳＭＦは、ハンドオーバが可能かどうかをＵＥにあらかじめ知らせることができる。例えば、ＵＥが３ＧＰＰアクセス及び非３ＧＰＰアクセスの両方ともに登録されていると仮定する。このとき、現在ＵＥが３ＧＰＰアクセス及び非３ＧＰＰアクセスの両方ともに同じＡＭＦを介して登録されている場合、ＡＭＦは、ＵＥが同じ一つのＡＭＦを介して全て登録したということをＳＭＦに知らせることができる。ＳＭＦは、ＡＭＦが知らせた情報に基づいてＳＳＣモードを考慮してＰＤＵセッション確立受諾メッセージにハンドオーバが可能であると知らせることができる。もし、ＵＥが互いに異なるＡＭＦを介して登録完了した場合、いずれか一つのＡＭＦは、ＵＥが２個のアクセスに全て登録されているかを知ることができない。したがって、この場合、前記ＡＭＦは、ＳＭＦに何らの情報を送らない。前記ＳＭＦは、ＡＭＦからＵＥが２個のアクセスを介して登録完了したという情報を受けなかったため、ＰＤＵセッション確立受諾メッセージにハンドオーバが不可能であることを示す情報を含ませることができる。
【０２７８】
図１５は、ＰＤＵセッションを確立する過程で該当ＰＤＵセッションがＨＯ可能かどうかを知らせる方法である。
【０２７９】
図１５を参照すると、過程１で、ＵＥは、ハンドオーバのためにＰＤＵセッション確立要求メッセージを送信する時、ＡＭＦにハンドオーバのために送るメッセージであることを知らせるために、ハンドオーバインジケーション（例えば、ＨＯ  ｉｎｄｉｃａｔｉｏｎ）を含ませる。
【０２８０】
前記受信したメッセージ内に前記ハンドオーバインジケーション（ＨＯ  ｉｎｄｉｃａｔｉｏｎ）が含まれている場合、前記ＡＭＦは、ＵＥが一つのＡＭＦを介して３ＧＰＰアクセス及び非３ＧＰＰアクセスの両方ともに同時に登録されたかどうかを知らせるインジケーション（例えば、Ｓｉｍｕｌｔａｎｅｏｕｓ  ａｃｃｅｓｓ  ｉｎｄｉｃａｔｉｏｎ）を過程３のＰＤＵセッション確立要求メッセージ内に含ませて、ＳＭＦに送信する。
【０２８１】
過程１０で、前記ＳＭＦ前記インジケーション（例えば、Ｓｉｍｕｌｔａｎｅｏｕｓ  ａｃｃｅｓｓ  ｉｎｄｉｃａｔｉｏｎ）に基づいて、ハンドオーバが可能かどうかを判断することができる。または、前記ＳＭＦは、前記インジケーションがなくても、加入情報、ＵＥ能力情報などに基づいてハンドオーバが可能かどうかを判断することができる。
【０２８２】
以上、説明した内容は、ハードウェアで具現される。これに対して図面を参照して説明する。
【０２８３】
図１６は、本発明の実施例に係るＵＥ及びネットワークノードの構成ブロック図である。
【０２８４】
図１６に示すように、前記ＵＥ１００は、格納手段１０１、コントローラ１０２、及び送受信部１０３を含む。そして、前記ネットワークノードは、ＡＭＦ、ＳＭＦ、ＮＥＦ、及びＡＦのうちいずれか一つである。前記ネットワークノードは、格納手段５１１、コントローラ５１２、及び送受信部５１３を含む。
【０２８５】
前記格納手段は、前述した方法を格納する。
【０２８６】
前記コントローラは、前記格納手段及び前記送受信部を制御する。具体的に、前記コントローラは、前記格納手段に格納された前記方法をそれぞれ実行する。そして、前記コントローラは、前記送受信部を介して前記前述した信号を送信する。
【０２８７】
以上、本発明の好ましい実施例を例示的に説明したが、本発明の範囲は、このような特定実施例にのみ限定されるものではないため、本発明は、本発明の思想及び特許請求範囲に記載された範ちゅう内で多様な形態で修正、変更、または改善される。
【図１】
2019521607.tif 000004
【図２】
2019521607.tif 000005
【図３】
2019521607.tif 000006
【図４】
2019521607.tif 000007
【図５Ａ】
2019521607.tif 000008
【図５Ｂ】
2019521607.tif 000009
【図５Ｃ】
2019521607.tif 000010
【図５Ｄ】
2019521607.tif 000011
【図５Ｅ】
2019521607.tif 000012
【図５Ｆ】
2019521607.tif 000013
【図６ａ】
2019521607.tif 000014
【図６ｂ】
2019521607.tif 000015
【図７】
2019521607.tif 000016
【図８】
2019521607.tif 000017
【図９】
2019521607.tif 000018
【図１０】
2019521607.tif 000019
【図１１】
2019521607.tif 000020
【図１２】
2019521607.tif 000021
【図１３】
2019521607.tif 000022
【図１４】
2019521607.tif 000023
【図１５】
2019521607.tif 000024
【図１６】
2019521607.tif 000025
【手続補正書】
【提出日】平成31年1月11日(2019.1.11)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ＡＭＦ（ａｃｃｅｓｓ  ａｎｄ  ｍｏｂｉｌｉｔｙ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードがＰＤＵ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｕｎｉｔ）セッション確立手順を処理する方法であって、
ＰＤＵセッション確立要求を受信するステップと、
既存ＰＤＵセッションの識別子を含む前記ＰＤＵセッション確立要求に基づいて、ＳＭＦ（ｓｅｓｓｉｏｎ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードの識別子を決定するステップと、
前記ＳＭＦノードの識別子に基づいて、前記ＰＤＵセッション確立要求を拒絶するかを決定するステップと、
前記ＰＤＵセッション確立要求を拒絶する決定に基づいて、拒絶理由を含むメッセージを送信するステップと、を含み、
前記ＳＭＦノードの識別子に基づいて、前記ＰＤＵセッション確立要求を拒絶するかを決定するステップは、
（ｉ）前記ＳＭＦノードと前記ＡＭＦノードの識別子が同じＰＬＭＮ（Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）に属すること又は（ｉｉ）前記ＳＭＦノードの識別子がＨＰＬＭＮ（Ｈｏｍｅ  Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）に属することの決定に基づいて前記ＰＤＵセッション確立要求を拒絶しないことを決定するステップを含む、方法。
【請求項２】
前記ＰＤＵセッション確立要求のメッセージは、要求タイプをさらに含み、
前記要求タイプは、（ｉ）新しいＰＤＵセッションを設定するための“初期要求”、又は、（ｉｉ）“既存ＰＤＵセッション”を指示する、請求項１に記載の方法。
【請求項３】
“既存ＰＤＵセッション”を指示する前記要求タイプに基づいて、
３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）ベースのアクセスネットワークと非３ＧＰＰ（ｎｏｎ−３ＧＰＰ）ベースのアクセスネットワークとの間の前記既存ＰＤＵセッションの移動を要求するステップを更に含む、請求項２に記載の方法。
【請求項４】
前記既存ＰＤＵセッションの識別子と前記ＳＭＦノードの識別子とを相互に関連付けて格納するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記ＳＭＦノードの識別子は、ＰＬＭＮの識別子を含む、請求項１に記載の方法。
【請求項６】
（ｉ）前記ＳＭＦノードと前記ＡＭＦノードの識別子が同じＰＬＭＮに属すること又は（ｉｉ）前記ＳＭＦノードの識別子が前記ＨＰＬＭＮに属しないことの決定に基づいて前記ＰＤＵセッション確立要求を拒絶することを決定するステップをさらに含む、請求項１に記載の方法。
【請求項７】
ＰＤＵ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｕｎｉｔ）セッション確立手順を処理するように設定されたＡＭＦ（ａｃｃｅｓｓ  ａｎｄ  ｍｏｂｉｌｉｔｙ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードであって、
送受信部と、
少なくとも一つのプロセッサと、
前記少なくとも一つのプロセッサと動作的に結合でき、実行された時、前記少なくとも一つのプロセッサが、
ＰＤＵセッション確立要求を受信するステップと、
既存ＰＤＵセッションの識別子を含む前記ＰＤＵセッション確立要求に基づいて、ＳＭＦ（ｓｅｓｓｉｏｎ  ｍａｎａｇｅｍｅｎｔ  ｆｕｎｃｔｉｏｎ）ノードの識別子を決定するステップと、
前記ＳＭＦノードの識別子に基づいて前記ＰＤＵセッション確立要求を拒絶するかを決定するステップと、
前記ＰＤＵセッション確立要求を拒絶するかの決定に基づき、拒絶理由を含むメッセージを送信するステップと、
前記ＳＭＦノードの識別子に基づいて、前記ＰＤＵセッション確立要求を拒絶するかを決定するステップは、
（ｉ）前記ＳＭＦノードと前記ＡＭＦノードの識別子が同じＰＬＭＮ（Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）に属すること又は（ｉｉ）前記ＳＭＦノードの識別子がＨＰＬＭＮ（Ｈｏｍｅ  Ｐｕｂｌｉｃ  Ｌａｎｄ  Ｍｏｂｉｌｅ  Ｎｅｔｗｏｒｋ）に属することの決定に基づいて前記ＰＤＵセッション確立要求を拒絶しないことを決定するステップを含む動作を実行させる指示（インストラクション）を格納する少なくとも一つのコンピュータメモリとを含む、ＡＭＦノード。
【請求項８】
前記ＰＤＵセッション確立要求のメッセージは、要求タイプをさらに含み、
前記要求タイプは、新しいＰＤＵセッションを設定するための“初期要求”、又は、（ｉｉ）“既存ＰＤＵセッション”を指示する、請求項７に記載のＡＭＦノード。
【請求項９】
前記動作は、
“既存ＰＤＵセッション”を指示する前記要求タイプに基づいて、
３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）ベースのアクセスネットワークと非３ＧＰＰ（ｎｏｎ−３ＧＰＰ）ベースのアクセスネットワークとの間の前記既存ＰＤＵセッションの移動を要求するステップを更に含む、請求項８に記載のＡＭＦノード。
【請求項１０】
前記動作は、前記既存ＰＤＵセッションの識別子と前記ＳＭＦノードの識別子とを相互に関連付けて格納するステップをさらに含む、請求項７に記載のＡＭＦノード。
【請求項１１】
前記ＳＭＦノードの識別子は、ＰＬＭＮの識別子を含む、請求項７に記載のＡＭＦノード。
【請求項１２】
（ｉ）前記ＳＭＦノードと前記ＡＭＦノードの識別子が同じＰＬＭＮに属すること又は（ｉｉ）前記ＳＭＦノードの識別子が前記ＨＰＬＭＮに属しないことの決定に基づいて前記ＰＤＵセッション確立要求を拒絶することを決定するステップをさらに含む、請求項７に記載のＡＭＦノード。
【請求項１３】
前記ＳＭＦの識別子を決定するステップは、
前記ＰＤＵセッション確立要求に含まれる前記既存ＰＤＵセッションの識別子に基づいて前記ＳＭＦノードの識別子を決定するステップを含む、請求項１に記載の方法。
【請求項１４】
前記ＳＭＦの識別子を決定するステップは、
前記ＰＤＵセッション確立要求に含まれる前記既存ＰＤＵセッションの識別子に基づいて前記ＳＭＦノードの識別子を決定するステップを含む、請求項７に記載のＡＭＦノード。
【国際調査報告】
2019521607.tif 000026
2019521607.tif 000027
2019521607.tif 000028
2019521607.tif 000029