JP2023526542A

JP2023526542A - 無線通信システムで端末にローカルデータネットワーク情報を提供するための方法及び装置

Info

Publication number: JP2023526542A
Application number: JP2022571363A
Authority: JP
Inventors: イ，ジチョル; ジョン，サンス
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2020-05-22
Filing date: 2021-05-21
Publication date: 2023-06-21
Also published as: CN115699877A; US20230164855A1; KR20210144490A; WO2021235880A1; EP4132100A4; EP4132100A1

Abstract

【課題】ＬＴＥのような４Ｇ通信システム以後、さらに高いデータ送信率をサポートするために提供される５Ｇ又はｐｒｅ－５Ｇ通信システムを提供する。【解決手段】無線通信システムのセッション管理機能装置で端末にローカルデータネットワーク情報を提供するための方法であって、端末の移動性により第１情報に基づいてプロトコルデータユニットセッションに対するＰＤＵセッションアンカー－ユーザ平面の追加を決定する段階と、追加が決定されたＰＳＡ－ＵＰＦとＰＤＵセッションを形成する段階と、ＰＳＡ－ＵＰＦと端末間のダウンリンク及びアップリンクに対するＰＤＵ経路を設定する段階と、端末に新しいＰＳＡ－ＵＰＦの追加を指示するＰＤＵセッション変更コマンドを送信する段階と、を含み、第１情報は、ポリシー及び課金制御情報、ポリシー制御機能装置から受信されたローカルデータネットワーク構成情報のうち少なくとも一つを含む。【選択図】図７ａ

Description

本開示は、無線通信システムに係り、より具体的にはセルラー無線通信システム、例えば、５Ｇシステムにおいて端末の移動によりローカルデータネットワーク情報を提供するための方法及び装置に関する。

４Ｇ通信システムの商用化以来，増加傾向にある無線データトラフィック需要を満たすために、改善された５Ｇ通信システム又はｐｒｅ－５Ｇ通信システムを開発するための努力が行われている。このような理由により、５Ｇ通信システム又はｐｒｅ－５Ｇ通信システムは、４Ｇネットワークを超す（Ｂｅｙｏｎｄ４ＧＮｅｔｗｏｒｋ）通信システム又はＬＴＥシステム以降（ＰｏｓｔＬＴＥ）のシステムと呼ばれている。

高いデータ送信率を達成するために、５Ｇ通信システムは超高周波（ｍｍＷａｖｅ）帯域（例えば、６０ギガ（６０ＧＨｚ）帯域のような）での具現が考えられている。超高周波帯域での伝播の経路損失の緩和及び伝播の伝達距離を増加させるために、５Ｇ通信システムではビームフォーミング（ｂｅａｍｆｏｒｍｉｎｇ）、ｍａｓｓｉｖｅＭＩＭＯ、ＦＤ－ＭＩＭＯ（ＦｕｌｌＤｉｍｅｎｓｉｏｎａｌＭＩＭＯ）、アレイアンテナ（ａｒｒａｙａｎｔｅｎｎａ）、アナログビームフォーミング（ａｎａｌｏｇｂｅａｍ－ｆｏｒｍｉｎｇ）、及び大規模アンテナ（ｌａｒｇｅｓｃａｌｅａｎｔｅｎｎａ）技術が論議されている。

さらに、システムのネットワーク改善のために、５Ｇ通信システムでは進化した小型セル、改善された小型セル（ａｄｖａｎｃｅｄｓｍａｌｌｃｅｌｌ）、クラウド無線アクセスネットワーク（ｃｌｏｕｄｒａｄｉｏａｃｃｅｓｓｎｅｔｗｏｒｋ：ｃｌｏｕｄＲＡＮ）、超高密度ネットワーク（ｕｌｔｒａ－ｄｅｎｓｅｎｅｔｗｏｒｋ）、デバイス間通信（ＤｅｖｉｃｅｔｏＤｅｖｉｃｅｃｏｍｍｕｎｉｃａｔｉｏｎ：Ｄ２Ｄ）、無線バックホール（ｗｉｒｅｌｅｓｓｂａｃｋｈａｕｌ）、移動ネットワーク（ｍｏｖｉｎｇｎｅｔｗｏｒｋ）、協力通信（ｃｏｏｐｅｒａｔｉｖｅｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＣｏＭＰ（ＣｏｏｒｄｉｎａｔｅｄＭｕｌｔｉ－Ｐｏｉｎｔｓ）、及び受信干渉除去（ｉｎｔｅｒｆｅｒｅｎｃｅｃａｎｃｅｌｌａｔｉｏｎ）などの技術開発が行われている。

その他にも、５Ｇシステムでは進歩したコーディング変調（ＡｄｖａｎｃｅｄＣｏｄｉｎｇＭｏｄｕｌａｔｉｏｎ：ＡＣＭ）方式であるＦＱＡＭ（ＨｙｂｒｉｄＦＳＫａｎｄＱＡＭＭｏｄｕｌａｔｉｏｎ）及びＳＷＳＣ（ＳｌｉｄｉｎｇＷｉｎｄｏｗＳｕｐｅｒｐｏｓｉｔｉｏｎＣｏｄｉｎｇ）と、進歩した接続技術であるＦＢＭＣ（ＦｉｌｔｅｒＢａｎｋＭｕｌｔｉＣａｒｒｉｅｒ）、ＮＯＭＡ（ｎｏｎｏｒｔｈｏｇｏｎａｌｍｕｌｔｉｐｌｅａｃｃｅｓｓ）、及びＳＣＭＡ（ｓｐａｒｓｅｃｏｄｅｍｕｌｔｉｐｌｅａｃｃｅｓｓ）などが開発されている。

一方、セルラー移動通信標準を担当する３ＧＰＰ（登録商標）は既存の４ＧＬＴＥシステムから５Ｇシステムへの進化を図るために新しいコアネットワーク（ＣｏｒｅＮｅｔｗｏｒｋ）構造を５ＧＣｏｒｅ（５ＧＣ）と名付けて標準化を進めている。

５ＧＣは既存の４Ｇのためのネットワークコアである進化したパケットコア（ＥｖｏｌｖｅｄＰａｃｋｅｔＣｏｒｅ：ＥＰＣ）に対して次のような差別化された機能をサポートする。

第１に、５ＧＣにおいてはネットワークスライス（ＮｅｔｗｏｒｋＳｌｉｃｅ）機能が導入される。５Ｇの要求条件として、５ＧＣは多様な種類の端末タイプ及びサービスをサポートしなければならない。例えば、超広帯域移動通信（ｅｎｈａｎｃｅｄＭｏｂｉｌｅＢｒｏａｄｂａｎｄ：ｅＭＢＢ）、超高信頼低遅延通信（ＵｌｔｒａＲｅｌｉａｂｌｅＬｏｗＬａｔｅｎｃｙＣｏｍｍｕｎｉｃａｔｉｏｎｓ：ＵＲＬＬＣ）、大規模事物通信（ｍａｓｓｉｖｅＭａｃｈｉｎｅＴｙｐｅＣｏｍｍｕｎｉｃａｔｉｏｎｓ：ｍＭＴＣ）などがある。このような端末／サービスはそれぞれコアネットワークに求める要求条件が異なる。例えば、ｅＭＢＢサービスの場合には高いデータ送信速度（ｄａｔａｒａｔｅ）を求め、ＵＲＬＬＣサービスの場合には高安定性と低遅延を求める。このような多様なサービス要求条件を満たすために提案された技術がネットワークスライス（ＮｅｔｗｏｒｋＳｌｉｃｅ）方案である。

ＮｅｔｗｏｒｋＳｌｉｃｅは一つの物理的ネットワークを仮想化（Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）して多数の論理的ネットワークを構築する方法であって、各ＮｅｔｗｏｒｋＳｌｉｃｅＩｎｓｔａｎｃｅ（ＮＳＩ）は互いに異なる特性を持つことができる。したがって、各ＮＳＩごとにその特性に合うネットワーク機能（ＮｅｔｗｏｒｋＦｕｎｃｔｉｏｎ（ＮＦ））を持つことによって多様なサービス要求条件を満たすことができる。各端末ごとに求めるサービスの特性に合うＮＳＩを割り当てて多くの５Ｇサービスを効率的にサポートすることができる。

第２に、５ＧＣは、移動性管理機能とセッション管理機能の分離によってネットワーク仮想化パラダイムサポートを容易にすることができる。既存の４ＧＬＴＥではすべての端末が登録、認証、移動性管理、及びセッション管理機能を担当する移動性管理エンティティー（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ（ＭＭＥ））という単一コア装備とのシグナリング交換を介して網でサービスが提供されてきた。しかし、５Ｇでは端末の数が爆発的に増加し、端末のタイプによってサポートすべき移動性及びトラフィック／セッション特性が細分化されるにより、ＭＭＥのような単一装備ですべての機能をサポートすることになると、必要な機能ごとにエンティティーを追加する拡張性（Ｓｃａｌａｂｉｌｉｔｙ）が劣るしかない。したがって、制御平面を担当するコア装備の機能／具現複雑度とシグナリング負荷の側面で拡張性改善のために移動性管理機能とセッション管理機能を分離する構造に基づいて多様な機能が開発されている。

一方、最近にはエッジサーバー（ｅｄｇｅｓｅｒｖｅｒ）を用いてデータを送信するエッジコンピューティング（ｅｄｇｅｒｃｏｍｐｕｔｉｎｇ）技術を、無線通信システムに適用するための技術が論議されている。エッジコンピューティング技術は、例えば、ＭＥＣ（ｍｕｌｔｉ－ａｃｃｅｓｓｅｄｇｅｃｏｍｐｕｔｉｎｇ）又はフォグコンピューティング（ｆｏｇｃｏｍｐｕｔｉｎｇ）を含むことができる。エッジコンピューティング技術は、電子装置（端末又はユーザ装置）と地理的に近い位置、例えば、基地局内部又は基地局近くに設置された別途のサーバー（以下、エッジサーバー又はＭＥＣサーバー）を介して電子装置にデータを提供する技術を意味する。例えば、電子装置に設置された少なくとも一つのアプリケーションのうち低い遅延時間（ｌａｔｅｎｃｙ）を求めるアプリケーションは、外部データネットワーク（ｄａｔａｎｅｔｗｏｒｋ、ＤＮ）（例：インターネット）に位置したサーバーを介さず、地理的に近い位置に設置されたエッジサーバーを介してデータを送受信することができる。

エッジコンピューティングをサポートする５Ｇコア網で、ローカルデータネットワーク（ｌｏｃａｌＤＮ）に対するローカルＰＤＵセッションアンカー－ユーザ平面機能（ＰＤＵＳｅｓｓｉｏｎＡｎｃｈｏｒＵｓｅｒＰｌａｎｅＦｕｎｃｔｉｏｎ、ｌｏｃａｌＰＳＡ－ＵＰＦ）装置が追加／変更／削除される場合、応用サーバーの移動が発生することができる。このように、ＬｏｃａｌＰＳＡ－ＵＰＦが追加／変更／削除される場合、５Ｇコア網のセッション管理機能（ＳｅｓｓｉｏｎＭａｎａｇｅｍｅｎｔＦｕｎｃｔｉｏｎ、ＳＭＦ）装置は端末に上位ネットワーク階層に関する制御情報を知らせなければならない。また、端末は、ＳＭＦ装置から上位ネットワーク階層に関する制御情報を受信する場合、これに伴う適切な動作を行う。

しかし、５Ｇコアネットワークでは、このような手順が行われる動作を提供していない。また、端末もＳＭＦ装置から上位ネットワーク階層に関する制御情報を受信する場合の動作を行うことができない。

したがって、本発明では、ＬｏｃａｌＰＳＡ－ＵＰＦが追加／変更／削除される場合、５Ｇコア網で端末に上位ネットワーク階層に関する制御情報を知らせるための手順を提供する。

また、本発明では、端末が５Ｇコア網からＬｏｃａｌＰＳＡ－ＵＰＦの追加／変更／削除による上位ネットワーク階層に関する制御情報を受信する場合の処理装置及び方法を提供する。

本発明の一実施例による方法は、無線通信システムのセッション管理機能（ＳｅｓｓｉｏｎＭａｎａｇｅｍｅｎｔＦｕｎｃｔｉｏｎ、ＳＭＦ）装置で端末にローカルデータネットワーク情報を提供するための方法であって、前記端末の移動性により第１情報に基づいてプロトコルデータユニット（ｐｒｏｔｏｃｏｌｄａｔａｕｎｉｔ、ＰＤＵ）セッションに対するＰＤＵセッションアンカー－ユーザ平面（ＰＤＵＳｅｓｓｉｏｎＡｎｃｈｏｒ－ＵｓｅｒＰｌａｎｅＦｕｎｃｔｉｏｎ、ＰＳＡ－ＵＰＦ）の追加を決定する段階と、前記追加が決定されたＰＳＡ－ＵＰＦとＰＤＵセッションを形成する段階と、前記ＰＳＡ－ＵＰＦと前記端末間のダウンリンク及びアップリンクに対するＰＤＵ経路を設定する段階と、前記端末に新しいＰＳＡ－ＵＰＦの追加を指示するＰＤＵセッション変更コマンド（ＰＤＵＳｅｓｓｉｏｎＭｏｄｉｆｉｃａｔｉｏｎＣｏｍｍａｎｄ）を送信する段階と、を含み、
前記第１情報は、ポリシー及び課金制御（ＰｏｌｉｃｙａｎｄＣｈａｒｇｉｎｇＣｏｎｔｒｏｌ、ＰＣＣ）情報、ポリシー制御機能（ｐｏｌｉｃｙｃｏｎｔｒｏｌｆｕｎｃｔｉｏｎ、ＰＣＦ）装置から受信されたローカル（ｌｏｃａｌ）データネットワーク（ｄａｔａｎｅｔｗｏｒｋ、ＤＮ）構成情報のうち少なくとも一つを含むことができる。

本発明の他の一実施例による方法は、無線通信システムの端末においてセッション管理機能（ＳＭＦ）装置からローカルデータネットワーク情報の受信方法であって、前記端末に設定されたプロトコルデータユニット（ｐｒｏｔｏｃｏｌｄａｔａｕｎｉｔ、ＰＤＵ）セッションを用いてＰＤＵを送／受信する段階と、セッション管理機能（ＳｅｓｓｉｏｎＭａｎａｇｅｍｅｎｔＦｕｎｃｔｉｏｎ、ＳＭＦ）装置から新しいＰＤＵセッションアンカー－ユーザ平面（ＰＤＵＳｅｓｓｉｏｎＡｎｃｈｏｒ－ＵｓｅｒＰｌａｎｅＦｕｎｃｔｉｏｎ、ＰＳＡ－ＵＰＦ）の追加を指示するＰＤＵセッション変更コマンド（ＰＤＵＳｅｓｓｉｏｎＭｏｄｉｆｉｃａｔｉｏｎＣｏｍｍａｎｄ）を受信する段階と、前記新しいＰＳＡ－ＵＰＦを介して前記ＳＭＦが送信したルータ広告（ＲｏｕｔｅｒＡｄｖｅｒｔｉｓｅｍｅｎｔ、ＲＡ）メッセージを受信する段階と、前記新しいＰＳＡ－ＵＰＦを再構成（ｒｅ－ｃｏｎｆｉｇｕｒｅ）する段階と、前記新しいＰＳＡ－ＵＰＦの再構成に基づいて前記上位階層制御を行う段階と、を含むことができる。

本発明によれば、ｌｏｃａｌＰＳＡ－ＵＰＦの追加（又は変更／削除）時に、端末の上位階層ネットワークコンテキストは解除される必要がある。この場合、ＳＭＦが端末にｌｏｃａｌＤＮに関する情報を提供して端末が上位階層コンテキストを制御できるようにする。また、このような手順を定義することで、無線通信ネットワークではローカルＰＤＵセッションアンカー－ユーザ平面機能（ＰＤＵＳｅｓｓｉｏｎＡｎｃｈｏｒＵｓｅｒＰｌａｎｅＦｕｎｃｔｉｏｎ、ＬｏｃａｌＰＳＡ－ＵＰＦ）装置の追加／変更／削除による上位ネットワーク階層に関する制御情報を端末に提供することができる。なお、端末は無線通信ネットワークからＬｏｃａｌＰＳＡ－ＵＰＦの追加／変更／削除による上位ネットワーク階層に関する制御情報を受信し、適切な動作を行うことができる。

無線通信システムで参照点表現を用いた５Ｇシステムアーキテクチャーの一例を示す図面である。本発明の多様な実施例による無線通信システムでネットワークエンティティー（ｎｅｔｗｏｒｋｅｎｔｉｔｙ）の構成を例示した図面である。本発明の一実施例によってエッジコンピューティングをサポートする５Ｇコア網の他の構造を例示した図面である。本発明によって端末が移動する場合をネットワークのトポロジーによって説明するための例示図である。本発明の一実施例によって端末の内部構成及び無線通信ネットワーク及びデータネットワークとＰＤＵセッションを設定する場合を説明するための例示図である。本発明の一実施例によって端末の内部構成及び無線通信ネットワーク及びデータネットワークとＰＤＵセッションを設定する場合を説明するための例示図である。本発明の一実施例によるローカルＤＮバインディングコンテキストを説明するための例示図である。本発明の一実施例によってＳＭＦがＵＥにＰＤＵセッションｌｏｃａｌＤＮに関する情報と共に上位階層ネットワークコンテキストに関する制御情報を提供する場合の信号フローチャートである。本発明の一実施例によってＳＭＦがｌｏｃａｌＤＮ公知及び上位階層ネットワークコンテキスト制御情報を端末に提供する際の信号フローチャートである。本発明の一実施例によってＳＭＦがｌｏｃａｌＤＮ公知及び上位階層ネットワークコンテキスト制御情報を端末に提供する際の信号フローチャートである。本発明の実施例によるネットワークでＡＦ要請によってｌｏｃａｌＰＳＡを変更する際、端末に情報の提供及びそれによる各ノードの動作に関する信号フローチャートである。本発明の実施例によるネットワークでＡＦ要請によってｌｏｃａｌＰＳＡを変更する際、端末に情報の提供及びそれによる各ノードの動作に関する信号フローチャートである。本発明の一実施例によって端末にｌｏｃａｌＤＮ情報と上位階層ネットワークコンテキスト制御情報の提供手順及び端末における動作を説明するための例示図である。本発明の一実施例によって端末にｌｏｃａｌＤＮ情報と上位階層ネットワークコンテキスト制御情報の提供手順及び端末における動作を説明するための例示図である。本発明によるＮＦのブロック構成図である。

以下、本発明の実施例を添付した図面と共に詳細に説明する。また、本発明を説明するにあたり、関連する公知機能又は構成に対する具体的な説明が本発明の要旨を不明瞭にする可能性があると判断された場合、その詳細な説明は省略する。また、後述する用語は本発明での機能を考慮して定義された用語であって、これはユーザ、運用者の意図又は慣例などにより変わることができる。したがって。その定義は本明細書全般にわたった内容に基づいて下すべきである。以下、基地局は端末のリソース割り当てを行う主体として、ｅＮｏｄｅＢ、ＮｏｄｅＢ、ＢＳ（ＢａｓｅＳｔａｔｉｏｎ）、ＲＡＮ（ＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）、ＡＮ（ＡｃｃｅｓｓＮｅｔｗｏｒｋ）、ＲＡＮｎｏｄｅ、無線接続ユニット、基地局制御機、又はネットワーク上のノードのうち少なくとも一つであれば良い。端末は、ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ）、ＭＳ（ＭｏｂｉｌｅＳｔａｔｉｏｎ）、セルラーフォン、スマートフォン、コンピューター、又は通信機能を行うことができるマルチメディアシステムを含むことができる。本発明でダウンリンク（Ｄｏｗｎｌｉｎｋ；ＤＬ）は基地局が端末に送信する信号の無線送信経路であり、アップリンク（Ｕｐｌｉｎｋ；ＵＬ）は端末が基地局に送信する信号の無線送信経路を意味する。また、下記でＬＴＥ又はＬＴＥ－Ａシステムを一例として本発明の実施例を説明するが、類似した技術的背景又はチャンネル形態を持つその他の通信システムにも本発明の実施例が適用されることができる。また、本発明の実施例は、熟練された技術的知識を有する者の判断として本発明の範囲を大きく逸脱しない範囲で一部変形を介して他の通信システムにも適用されることができる。

下記では、無線通信システムで端末の移動によるセッションの管理に関する内容を説明する。また、本発明は、エッジコンピューティングシステムで端末の移動によって端末が接続する応用サーバーの再配置に関する手順も適用されることができる。

図１は、無線通信システムで参照点表現を用いた５Ｇシステムアーキテクチャーの一例を示す図面である。

図１を参照すれば、５Ｇシステムアーキテクチャーは多様な構成要素（すなわち、ネットワーク機能（ｎｅｔｗｏｒｋｆｕｎｃｔｉｏｎ、ＮＦ））を含むことができる。図１にはそのうちの一部に該当する、認証サーバー機能（ａｕｔｈｅｎｔｉｃａｔｉｏｎｓｅｒｖｅｒｆｕｎｃｔｉｏｎ、ＡＵＳＦ）装置１６０、アクセス及び移動性管理機能（（ｃｏｒｅ）ａｃｃｅｓｓａｎｄｍｏｂｉｌｉｔｙｍａｎａｇｅｍｅｎｔｆｕｎｃｔｉｏｎ、ＡＭＦ）装置１２０、セッション管理機能（ｓｅｓｓｉｏｎｍａｎａｇｅｍｅｎｔｆｕｎｃｔｉｏｎ、ＳＭＦ）装置１３０、ポリシー制御機能（ｐｏｌｉｃｙｃｏｎｔｒｏｌｆｕｎｃｔｉｏｎ、ＰＣＦ）装置１４０、アプリケーション機能（ａｐｐｌｉｃａｔｉｏｎｆｕｎｃｔｉｏｎ、ＡＦ）装置１５０、統合されたデータ管理（ｕｎｉｆｉｅｄｄａｔａｍａｎａｇｅｍｅｎｔ、ＵＤＭ）装置１７０、データネットワーク（ｄａｔａｎｅｔｗｏｒｋ、ＤＮ）１８０、ユーザ平面機能（ｕｓｅｒｐｌａｎｅｆｕｎｃｔｉｏｎ、ＵＰＦ）装置１１０、（無線）アクセスネットワーク（（ｒａｄｉｏ）ａｃｃｅｓｓｎｅｔｗｏｒｋ、（Ｒ）ＡＮ）２０、端末、すなわち、ユーザ装置（ｕｓｅｒｅｑｕｉｐｍｅｎｔ、ＵＥ）１０を例示した。

図１に例示したそれぞれの装置は、一つのサーバー又は装置で具現することができ、前述したように、ネットワークスライスインスタンスで具現されることもできる。ネットワークスライスインスタンスで具現される場合、一つのサーバー又は装置内に二つ以上の同一又は互いに異なるネットワークスライスインスタンスで具現されることができ、二つ以上のサーバー又は装置に一つのネットワークスライスインスタンスが具現されることもできる。

前記の各ＮＦは次のような機能をサポートすることができる。

ＡＵＳＦ１６０は、ＵＥの認証のためのデータを処理して格納することができる。

ＡＭＦ１２０は、ＵＥ単位の接続及び移動性管理のための機能を提供することができ、一つのＵＥごとに基本的に一つのＡＭＦに接続されることができる。具体的に、ＡＭＦ１２０は、３ＧＰＰ（登録商標）アクセスネットワークの間の移動性のためのＣＮノード間シグナリング、無線アクセスネットワーク（ｒａｄｉｏａｃｃｅｓｓｎｅｔｗｏｒｋ、ＲＡＮ）ＣＰインターフェース（すなわち、Ｎ２インターフェース）の終端（ｔｅｒｍｉｎａｔｉｏｎ）、ＮＡＳシグナリングの終端（Ｎ１）、ＮＡＳシグナリングセキュリティー（ＮＡＳ暗号化（ｃｉｐｈｅｒｉｎｇ）及び完全性保護（ｉｎｔｅｇｒｉｔｙｐｒｏｔｅｃｔｉｏｎ））、ＡＳセキュリティー制御、登録管理（登録領域（ｒｅｇｉｓｔｒａｔｉｏｎａｒｅａ）管理）、接続管理、アイドルモードＵＥ接近性（ｒｅａｃｈａｂｉｌｉｔｙ）（ページング再送信の制御及び実行を含む）、移動性管理制御（加入及びポリシー）、イントラ－システムの移動性及びインター－システムの移動性サポート、ネットワークスライシング（ｎｅｔｗｏｒｋｓｌｉｃｉｎｇ）のサポート、ＳＭＦ選択、合法的傍受（ｌａｗｆｕｌｉｎｔｅｒｃｅｐｔ）（ＡＭＦイベント及びＬＩシステムへのインターフェースに対する）、ＵＥとＳＭＦの間のセッション管理（ｓｅｓｓｉｏｎｍａｎａｇｅｍｅｎｔ、ＳＭ）メッセージの伝達提供、ＳＭメッセージルーティングのための透過型プロキシ（ｔｒａｎｓｐａｒｅｎｔｐｒｏｘｙ）、アクセス認証（ａｃｃｅｓｓａｕｔｈｅｎｔｉｃａｔｉｏｎ）、ローミング権限チェックを含むアクセス許可（ａｃｃｅｓｓａｕｔｈｏｒｉｚａｔｉｏｎ）、ＵＥとショートメッセージサービス機能（ＳｈｏｒｔＭｅｓｓａｇｅＳｅｒｖｉｃｅＦｕｎｃｔｉｏｎ、ＳＭＳＦ）装置の間のＳＭＳメッセージの伝達提供、セキュリティーアンカー機能（ｓｅｃｕｒｉｔｙａｎｃｈｏｒｆｕｎｃｔｉｏｎ、ＳＡＦ）及び／又はセキュリティーコンテキスト管理（ｓｅｃｕｒｉｔｙｃｏｎｔｅｘｔｍａｎａｇｅｍｅｎｔ、ＳＣＭ）などの機能をサポートすることができる。このようなＡＭＦ１２０の一部又は全体の機能は一つのＡＭＦで動作する単一ＡＭＦインスタンス（ｉｎｓｔａｎｃｅ）内でサポートされることができる。

ＤＮ１８０は、例えば、運営者サービス、インターネット接続又はサードパーティー（３ｒｄｐａｒｔｙ）サービスなどを意味する。ＤＮ１８０は、ＵＰＦ１１０にダウンリンクプロトコルデータユニット（ｐｒｏｔｏｃｏｌｄａｔａｕｎｉｔ、ＰＤＵ）を送信するか、ＵＥ１０から送信されたＰＤＵをＵＰＦ１１０を介して受信することができる。

ＰＣＦ１４０は、アプリケーションサーバーからパケットのフローに関する情報を受信し、移動性管理、セッション管理などのポリシーを決定する機能を提供することができる。具体的に、ＰＣＦ１４０はネットワーク動作をコントロールするための単一化したポリシーフレームワークのサポート、制御平面機能（例えば、ＡＭＦ、ＳＭＦなど）がポリシールールを施行できるようにポリシールールを提供、ユーザデータリポジトリ（ｕｓｅｒｄａｔａｒｅｐｏｓｉｔｏｒｙ、ＵＤＲ）内のポリシー決定のために関連した加入情報にアクセスするためのフロントエンド（ｆｒｏｎｔｅｎｄ）を具現するなどの機能をサポートすることができる。

ＳＭＦ１３０は、セッション管理機能を提供し、ＵＥが多数のセッションを有する場合、各セッション別に互いに異なるＳＭＦによって管理されることができる。具体的に、ＳＭＦ１３０は、セッション管理（例えば、ＵＰＦとＡＮノードの間のトンネル（ｔｕｎｎｅｌ）維持を含み、セッションの確立、修正及び解除）、ＵＥＩＰアドレス割り当て及び管理（選択的に認証を含む）、ＵＰ機能の選択及び制御、ＵＰＦでトラフィックを適切な目的地でルーティングするためのトラフィックステアリング（ｔｒａｆｆｉｃｓｔｅｅｒｉｎｇ）設定、ポリシー制御機能（ｐｏｌｉｃｙｃｏｎｔｒｏｌｆｕｎｃｔｉｏｎｓ）に向かったインターフェースの終端、ポリシー及びＱｏＳ（ｑｕａｌｉｔｙｏｆｓｅｒｖｉｃｅ）の制御部分施行、合法的傍受（ｌａｗｆｕｌｉｎｔｅｒｃｅｐｔ）（ＳＭイベント及びＬＩシステムへのインターフェースに対する）、ＮＡＳメッセージのＳＭ部分の終端、ダウンリンクデータ通知（ｄｏｗｎｌｉｎｋｄａｔａｎｏｔｉｆｉｃａｔｉｏｎ）、ＡＮ特定ＳＭ情報の開始子（ＡＭＦを経由してＮ２を介してＡＮに伝達）、セッションのＳＳＣモード決定、ローミング機能などの機能をサポートすることができる。前述したように、ＳＭＦ１３０の一部又は全体の機能は一つのＳＭＦで動作する単一ＳＭＦインスタンス（ｉｎｓｔａｎｃｅ）内でサポートされることができる。

ＵＤＭ１７０は、ユーザの加入データ、ポリシーデータなどを格納することができる。ＵＤＭ１７０は２つの部分、すなわちアプリケーションのフロントエンド（ｆｒｏｎｔｅｎｄ、ＦＥ）（図示せず）及びユーザデータリポジトリ（ｕｓｅｒｄａｔａｒｅｐｏｓｉｔｏｒｙ、ＵＤＲ）（図示せず）を含むことができる。

ＦＥは、位置管理、加入管理、資格証明（ｃｒｅｄｅｎｔｉａｌ）の処理などを担当するＵＤＭＦＥとポリシー制御を担当するＰＣＦ－ＦＥを含むことができる。ＵＤＲは、ＵＤＭ－ＦＥによって提供される機能のために求められるデータとＰＣＦによって求められるポリシープロフィールを格納することができる。ＵＤＲ内に格納されるデータは、加入識別子、セキュリティー資格証明（ｓｅｃｕｒｉｔｙｃｒｅｄｅｎｔｉａｌ）、アクセス、及び移動性関連の加入データ、並びにセッション関連の加入データを含むユーザ加入データとポリシーデータを含むことができる。ＵＤＭ－ＦＥは、ＵＤＲに格納された加入情報にアクセスし、認証資格証明処理（ａｕｔｈｅｎｔｉｃａｔｉｏｎｃｒｅｄｅｎｔｉａｌｐｒｏｃｅｓｓｉｎｇ）、ユーザ識別子ハンドリング（ｕｓｅｒｉｄｅｎｔｉｆｉｃａｔｉｏｎｈａｎｄｌｉｎｇ）、アクセス認証、登録／移動性管理、加入管理、ＳＭＳ管理などの機能をサポートすることができる。

ＵＰＦ１１０は、ＤＮ１８０から受信したダウンリンクＰＤＵを（Ｒ）ＡＮ２０を経由してＵＥ１０に伝達し、（Ｒ）ＡＮ２０を経由してＵＥ１０から受信したアップリンクＰＤＵをＤＮ１８０に伝達することができる。具体的に、ＵＰＦ１１０は、イントラ（ｉｎｔｒａ）／インター（ｉｎｔｅｒ）無線接続技術（ｒａｄｉｏａｃｃｅｓｓｔｅｃｈｎｏｌｏｇｙ、ＲＡＴ）移動性のためのアンカーポイント、データネットワーク（ＤａｔａＮｅｔｗｏｒｋ）への相互接続（ｉｎｔｅｒｃｏｎｎｅｃｔ）の外部ＰＤＵセッションポイント、パケットルーティング及びフォワーディング、パケット検査（ｉｎｓｐｅｃｔｉｏｎ）、並びにポリシールール施行のユーザ平面部分、合法的傍受（ｌａｗｆｕｌｉｎｔｅｒｃｅｐｔ）、トラフィック使用量の報告、データネットワークへのトラフィックフローのルーティングをサポートするためのアップリンク分類子（ｃｌａｓｓｉｆｉｅｒ）、マルチ－ホーム（ｍｕｌｔｉ－ｈｏｍｅｄ）ＰＤＵセッションをサポートするためのブランチポイント（ｂｒａｎｃｈｉｎｇｐｏｉｎｔ）、ユーザ平面のためのＱｏＳハンドリング（ｈａｎｄｌｉｎｇ）（例えば、パケットフィルタリング、ゲーティング（ｇａｔｉｎｇ）、アップリンク／ダウンリンクレート施行）、アップリンクトラフィックの検証（サービスデータフロー（ｓｅｒｖｉｃｅｄａｔａｆｌｏｗ、ＳＤＦ）とＱｏＳフローの間のＳＤＦマッピング）、アップリンク及びダウンリンク内の伝達レベル（ｔｒａｎｓｐｏｒｔｌｅｖｅｌ）パケットマーキング、ダウンリンクパケットバッファリング及びダウンリンクデータ通知トリガリング機能などをサポートすることができる。このようなＵＰＦ１１０の一部又は全体の機能は、一つのＵＰＦで動作する単一ＵＦＰインスタンス（ｉｎｓｔａｎｃｅ）内でサポートされることができる。

ＡＦ１５０は、サービス提供（例えば、トラフィックルーティング上でアプリケーションの影響、ネットワーク能力露出（ｎｅｔｗｏｒｋｃａｐａｂｉｌｉｔｙｅｘｐｏｓｕｒｅ）へのアクセス、ポリシー制御のためのポリシーフレームワークとの相互動作などの機能をサポート）のために３ＧＰＰ（登録商標）コアネットワークと相互動作することができる。

（Ｒ）ＡＮ２０は、４Ｇ無線アクセス技術の進化したバージョンである進化したＥ－ＵＴＲＡ（ｅｖｏｌｖｅｄＥ－ＵＴＲＡ）と新しい無線アクセス技術（ｎｅｗｒａｄｉｏ、ＮＲ）（例えば、ｇＮＢ）をいずれもサポートする新しい無線アクセスネットワークを総称することができる。

ｇＮＢは、無線資源管理のための機能（すなわち、無線ベアラ制御（ｒａｄｉｏｂｅａｒｅｒｃｏｎｔｒｏｌ）、無線許諾制御（ｒａｄｉｏａｄｍｉｓｓｉｏｎｃｏｎｔｒｏｌ）、接続移動性制御（ｃｏｎｎｅｃｔｉｏｎｍｏｂｉｌｉｔｙｃｏｎｔｒｏｌ）、アップリンク／ダウンリンクでＵＥに資源の動的割り当て（ｄｙｎａｍｉｃａｌｌｏｃａｔｉｏｎｏｆｒｅｓｏｕｒｃｅｓ）（すなわち、スケジューリング））、ＩＰ（ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌ）ヘッダ圧縮、ユーザデータストリームの暗号化（ｅｎｃｒｙｐｔｉｏｎ）及び整合性保護（ｉｎｔｅｇｒｉｔｙｐｒｏｔｅｃｔｉｏｎ）、ＵＥ１０に提供された情報からＡＭＦ１２０へのルーティングが決定されない場合、ＵＥ１０のアタッチ（ａｔｔａｃｈｍｅｎｔ）時のＡＭＦ１２０の選択、ＵＰＦ１１０へのユーザ平面データルーティング、ＡＭＦ１２０への制御平面情報ルーティング、接続セットアップ及び解除、ページングメッセージのスケジューリング及び送信（ＡＭＦから発生した）、システムブロードキャスト情報のスケジューリング及び送信（ＡＭＦ又は運営及び維持（ｏｐｅｒａｔｉｎｇａｎｄｍａｉｎｔｅｎａｎｃｅ、Ｏ＆Ｍ）から発生した）、移動性及びスケジューリングのための測定及び測定報告設定、アップリンクで伝達レベルパケットマーキング（ｔｒａｎｓｐｏｒｔｌｅｖｅｌｐａｃｋｅｔｍａｒｋｉｎｇ）、セッション管理、ネットワークスライシング（ｎｅｔｗｏｒｋｓｌｉｃｉｎｇ）のサポート、ＱｏＳフロー管理及びデータ無線ベアラへのマッピング、非活動モード（ｉｎａｃｔｉｖｅｍｏｄｅ）のＵＥのサポート、ＮＡＳメッセージの分配機能、ＮＡＳノード選択機能、無線アクセスネットワーク共有、二重接続性（ｄｕａｌｃｏｎｎｅｃｔｉｖｉｔｙ）、ＮＲとＥ－ＵＴＲＡの間の密接な相互動作（ｔｉｇｈｔｉｎｔｅｒｗｏｒｋｉｎｇ）などの機能をサポートすることができる。

ＵＥ１０は、ユーザ機器を意味する。ユーザ装置は、端末（ｔｅｒｍｉｎａｌ）、ＭＥ（ｍｏｂｉｌｅｅｑｕｉｐｍｅｎｔ）、ＭＳ（ｍｏｂｉｌｅｓｔａｔｉｏｎ）などの用語として言及され得る。また、ユーザ装置は、ノートパソコン、携帯電話、ＰＤＡ（ｐｅｒｓｏｎａｌｄｉｇｉｔａｌａｓｓｉｓｔａｎｔ）、スマートフォン、マルチメディア機器などのように携帯可能な機器であってもよく、又はパーソナルコンピューター（ｐｅｒｓｏｎａｌｃｏｍｐｕｔｅｒ、ＰＣ）、車両搭載装置のように携帯不可能な機器であってもよい。下記では、ユーザ装置（ＵＥ）又は端末として説明する。

図１では、説明の明確性のために、ネットワーク露出機能（ｎｅｔｗｏｒｋｅｘｐｏｓｕｒｅｆｕｎｃｔｉｏｎ、ＮＥＦ）装置及びＮＦリポジトリ機能（ＮＦｒｅｐｏｓｉｔｏｒｙｆｕｎｃｔｉｏｎ、ＮＲＦ）装置を図示していないが、後述する図５に図示するすべてのＮＦは必要に応じてＮＥＦ及びＮＲＦと相互動作を行うことができる。

ＮＲＦについて検討する。ＮＲＦ（図１に図示せず）は、サービスディスカバリー機能をサポートすることができる。第１のＮＦインスタンスから第２のＮＦディスカバリーの要請を受信する場合、第２のＮＦの発見動作を行った後、発見された第２のＮＦインスタンスの情報を第１のＮＦインスタンスに提供することができる。また、利用可能なＮＦインスタンスとそれがサポートするサービスを維持することができる。

一方、図１では、説明の便宜上、ＵＥが一つのＰＤＵセッションを用いて一つのＤＮにアクセスする場合に対する参照モデルを例示するが、本発明はこれに限定されない。

ＵＥ１０は、多重のＰＤＵセッションを用いて２つの（すなわち、ローカル的（ｌｏｃａｌ）そして中心の（ｃｅｎｔｒａｌ））データネットワークに同時にアクセスすることができる。この時、互いに異なるＰＤＵセッションのために２つのＳＭＦが選択されることができる。ただし、各ＳＭＦは、ＰＤＵセッション内のローカル的なＵＰＦ及び中心のＵＰＦをいずれも制御可能な能力を持つことができる。

また、ＵＥ１０は。単一のＰＤＵセッション内で提供される２つの（すなわち、ローカル的そして中心の）データネットワークに同時にアクセスすることもできる。

３ＧＰＰ（登録商標）システムでは、５Ｇシステム内のＮＦ間を接続する概念的なリンクを参照点（ｒｅｆｅｒｅｎｃｅｐｏｉｎｔ）と定義する。次に、図１で表現された５Ｇシステムのアーキテクチャーに含まれる参照点を例示する。

－Ｎ１：ＵＥとＡＭＦの間の参照点
－Ｎ２：（Ｒ）ＡＮとＡＭＦの間の参照点
－Ｎ３：（Ｒ）ＡＮとＵＰＦの間の参照点
－Ｎ４：ＳＭＦとＵＰＦの間の参照点
－Ｎ５：ＰＣＦとＡＦの間の参照点
－Ｎ６：ＵＰＦとデータネットワークの間の参照点
－Ｎ７：ＳＭＦとＰＣＦの間の参照点
－Ｎ８：ＵＤＭとＡＭＦの間の参照点
－Ｎ９：２つのコアＵＰＦの間の参照点
－Ｎ１０：ＵＤＭとＳＭＦの間の参照点
－Ｎ１１：ＡＭＦとＳＭＦの間の参照点
－Ｎ１２：ＡＭＦとＡＵＳＦの間の参照点
－Ｎ１３：ＵＤＭと認証サーバー機能（ａｕｔｈｅｎｔｉｃａｔｉｏｎｓｅｒｖｅｒｆｕｎｃｔｉｏｎ、ＡＵＳＦ）の間の参照点
－Ｎ１４：２つのＡＭＦの間の参照点
－Ｎ１５：非－ローミングシナリオの場合のＰＣＦとＡＭＦの間の参照点、ローミングシナリオの場合の訪問ネットワーク（ｖｉｓｉｔｅｄｎｅｔｗｏｒｋ）内のＰＣＦとＡＭＦの間の参照点

図２は、本発明の多様な実施例による無線通信システムでネットワークエンティティー（ｎｅｔｗｏｒｋｅｎｔｉｔｙ）の構成を例示した図面である。

本発明のネットワークエンティティーは、システムの具現によってネットワーク機能（ｎｅｔｗｏｒｋｆｕｎｃｔｉｏｎ）を含む概念である。下記で使用される「～部」、「～器」などの用語は、少なくとも一つの機能や動作を処理する単位を意味し、これはハードウェアやソフトウェア、又はハードウェア及びソフトウェアの結合で具現されることができる。また、各機能は、前述したように、一つの装置又はサーバー内で具現することができ、互いに異なる二つ以上のサーバーや装置を用いて一つの機能を行うように具現することもできる。

図２では、図１の構成要素と大枠同じであるが、下記のような差異がある。
図１と対比し、図２に追加のＮＥＦ１９０は、３ＧＰＰ（登録商標）ネットワーク機能によって提供される、例えば、第三者（３ｒｄｐａｒｔｙ）、内部露出（ｉｎｔｅｒｎａｌｅｘｐｏｓｕｒｅ）／再露出（ｒｅ－ｅｘｐｏｓｕｒｅ）、アプリケーション機能、エッジコンピューティング（ＥｄｇｅＣｏｍｐｕｔｉｎｇ）のためのサービス及び能力を安全に露出するための手段を提供することができる。ＮＥＦ１９０は、他のネットワーク機能から（他のネットワーク機能の露出された能力に基づいた）情報を受信することができる。ＮＥＦ１９０は、データ格納ネットワーク機能への標準化されたインターフェースを用い、構造化されたデータとして受信された情報を格納することができる。格納された情報は、ＮＥＦ１９０によって他のネットワーク機能及びアプリケーション機能に再露出（ｒｅ－ｅｘｐｏｓｅ）され、分析などの他の目的に用いられることができる。

また、図２では、互いに異なる３つのＵＰＦ２１０、２２０、２３０及び新しいＤＮ２４０を例示した。図１と同様に、ＡＮ２０と接続される第１のＵＰＦ２１０は、新しいＤＮ２４０と接続するための第３のＵＰＦ２３０とＮ９を用いて接続されることができる。また、第１のＵＰＦ２１０は既存のＤＮ１８０と第２のＵＰＦ２２０を介して接続されることができる。

図２に例示した構成は、エッジコンピューティングをサポートする５Ｇコア網の構造のうちの一つを例示した。図２に表示した５Ｇコア網の制御平面機能装置は、前述の図１と同一であり、同じ構成要素に対して同じ参照符号を与えた。第１のＵＰＦ２１０は、アップリンク分類器（ＵｐｌｉｎｋＣｌａｓｓｉｆｉｅｒ、ＵＬＣＬ）／プレンチンポイント（ＢｒａｎｃｈｉｎｇＰｏｉｎｔ、ＢＰ）であって、端末１０がエッジアプリケーションサーバー（ＥｄｇｅＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ、ＥＡＳ）と通信する５Ｇコア網構造を図示する。端末（ＵＥ）１０は、ユーザのプロトコルデータユニット（プロトコルデータユニット、ＰＤＵ）をＵＬＣＬ／ＢＰＵＰＦの役割を果たす第１ＵＰＦ２１０を介して第２ＵＰＦ２２０と接続され、データネットワーク（ＤａｔａＮｅｔｗｏｒｋ）；ＤＮ）１８０に接続することができる。この時、第２のＵＰＦ２２０は、図２では一番目のＰＤＵセッションアンカー－ユーザ平面機能（ＰＤＵＳｅｓｓｉｏｎＡｎｃｈｏｒＵｓｅｒＰｌａｎｅＦｕｎｃｔｉｏｎ、ＰＳＡ－ＵＰＦ）になる。

また、第１のＵＰＦ２１０は、第２のＵＰＦ２２０に接続されると同時に第３のＵＰＦ２３０に接続されることができる。この時、第３のＵＰＦ２３０は、二番目のＰＳＡ－ＵＰＦとして、ＵＥとローカル的に近い位置のＤＮ２４０に接続することができる。ローカル的に近いデータネットワーク２４０には、エッジコンピューティングサービスを提供するエッジアプリケーションサーバー（ＥｄｇｅＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ、ＥＡＳ）２４１が位置しており、端末１０は、ＥＡＳ２４１に通信してエッジコンピューティングサービスを提供することができる。ＳＭＦ１３０は、第１のＵＰＦ２１０、第２のＵＰＦ２２０、第３のＵＰＦ２３０とＮ４セッションを生成して各ＵＰＦ２１０、２２０、２３０に対するトラフィックをフォワーディングするためのルールを伝達し、各ＵＰＦ２１０、２２０、２３０を制御することができる。また、ＳＭＦ１３０では端末１０がローカル的に近い二番目のＰＳＡ－ＵＰＦである第３のＵＰＦ２３０に接続するようにＵＬＣＰとして動作する第１のＵＰＦ２１０に目的地ＩＰアドレス、目的地ポート番号、そしてプロトコル番号を含む３テュプル（Ｔｕｐｌｅ）情報をＵＬＣＬ／ＢＰＵＰＦ２１０に伝達し、端末１０のトラフィックをローカルデータネットワークにルーティングするか、一番目のＰＳＡ－ＵＰＦ２２０にルーティングするかを決定することができる。このような構造で、端末１０が近いｌｏｃａｌＰＳＡ－ＵＰＦ２３０を介してＥＡＳ２４１と通信するために、５Ｇコア網ではＵＬＣＬ／ＢＰ２１０及びＬｏｃａｌＰＳＡ－ＵＰＦ２３０の追加／変更／除去の手順を行うことができる。

一方、従来の３ＧＰＰ（登録商標）５Ｇコア網でＰＳＡ－ＵＰＦ（ＰＤＵｓｅｓｓｉｏｎａｎｃｈｏｒ－ｕｓｅｒｐｌａｎｅｆｕｎｃｔｉｏｎ）の再配置（ｒｅｌｏｃａｔｉｏｎ）は、データ経路遅延（ｄａｔａｐａｔｈｄｅｌａｙ）に関して考慮されていない。すなわち、従来の３ＧＰＰ（登録商標）５Ｇコア網では、ＳＭＦ（ｓｅｓｓｉｏｎｍａｎａｇｅｍｅｎｔｆｕｎｃｔｉｏｎ）で自体的にトポロジー情報（ｔｏｐｏｌｏｇｙｉｎｆｏｒｍａｔｉｏｎ）を活用してＰＳＡ－ＵＰＦの再配置（ｒｅｌｏｃａｔｉｏｎ）を決定した。本発明の多様な実施例は、低遅延サービスを必要とするアプリケーション機能（ａｐｐｌｉｃａｔｉｏｎｆｕｎｃｔｉｏｎ）の要請に基づき、５Ｇコアネットワーク及びアプリケーションがデータ経路の遅延時間を考慮してＰＳＡ－ＵＰＦの再配置（ｒｅｌｏｃａｔｉｏｎ）をするか否かを決定する方法を提供することができる。

本発明の多様な実施例によれば、５Ｇコアネットワーク及びアプリケーションがデータ経路の遅延を考慮してＰＳＡ－ＵＰＦの移動を決定する。一つ又はそれ以上のアプリケーションからサービス提供される端末が、現在に接続されたアプリケーションが配置されたサービス領域を外れるハンドオーバーが発生し、ＰＳＡ－ＵＰＦ移動を行うと、端末のＩＰアドレスが変更されてサービスの中断が発生する可能性がある。

本発明の多様な実施例によれば、アプリケーションで要請した遅延を考慮し、端末が移動したローカルで既存のデータ経路を介してアプリケーションが要請した遅延を満たす場合、ＰＳＡ－ＵＰＦ再配置（ｒｅｌｏｃａｔｉｏｎ）を行わないことによってサービスの中断を最小化することができる。

本発明の多様な実施例によれば、端末が移動して新しく変更された経路を介してサービスを提供することになる場合、又はアプリケーションで要請した遅延を満たさなくなる場合、新しいＰＳＡ－ＵＰＦで経路を再設定してアプリケーションが要請する遅延時間を満たすサービスを提供することができる。

図３は、本発明の一実施例によってエッジコンピューティングをサポートする５Ｇコア網の他の構造を例示した図面である。

前述したように、図３に表示した５Ｇコア網の制御平面機能は、図１及び図２での説明と同一の構成要素に対しては同一の参照符号を付した。したがって、同一の構成要素についての付加的説明は省略する。

図３では、ＵＬＣＬ／ＢＰを用いず、端末１０がＤＮ３２０に含まれたＥＡＳ３２１と通信する５Ｇコア網構造を例示した。このようなネットワーク構造では、端末１０が移動によって端末１０に近いＰＳＡ－ＵＰＦ３１０を介してＥＡＳ３２１に接近するためにサービス及びセッション連続性（ＳｅｒｖｉｃｅａｎｄＳｅｓｓｉｏｎＣｏｎｔｉｎｕｉｔｙ、ＳＳＣ）Ｍｏｄｅ２又はＳＳＣＭｏｄｅ３方式を用いてＰＳＡ－ＵＰＦを移動（ｒｅｌｏｃａｔｉｏｎ）する手順を行うことができる。

図４は、本発明によって端末が移動する場合をネットワークのトポロジーによって説明するための例示図である。
図４では、ＩＰｖ４ＵＬＣＬの環境で、ＬｏｃａｌＤａｔａＮｅｔｗｏｒｋ別に別途のＩＰ範囲を有するネットワークの構成図を例示した。

図４の構成を検討すると、端末１０内の特定アプリ（アプリケーション、図４に図示せず）が第１のデータネットワーク４１０、例えば、ＩＰアドレスが「１０．１０．１０．＊」と設定されたデータネットワークに接続した状態であり得る。このように、端末１０が第１のデータネットワーク４１０に接続する場合は、第１のデータネットワーク４１０に接続するためのＵＰＦであるＰＳＡ－ＵＰＦ＃１４１１とＵＬＣＬ／ＢＰ４０１及びＵＬＣＬ／ＢＰ４０１に接続されるＲＡＮ２０を介して接続することができる。また、端末１０は、インターネットに接続する場合、インターネットに接続するためのＵＰＦであるＵＬＣＬ／ＢＰ４０１と該当するＲＡＮ２０を介して接続することができる。この時、端末１０が第１のデータネットワーク４１０に接続する場合、端末はデータネットワーク接続識別子（ＤａｔａＮｅｔｗｏｒｋＡｃｃｅｓｓＩｄｅｎｔｉｆｉｅｒ、ＤＮＡＩ）として、前述したように、「１０．１０．１０．ｘｘ」を有することができる。

万一、端末が図４に例示したように移動して第２のＲＡＮ２１に移動する場合、新しいＵＰＦであるＵＬＣＬ／ＢＰ４０２を介し、新しいＰＳＡ－ＵＰＦ＃２４２１を介してＩＰアドレスが「１０．１０．２０．＊」に設定されたデータネットワークに接続することができる。また、他の例として、端末１０が第２のＲＮＡ２１に移動しても新しいＵＰＦであるＵＬＣＬ／ＢＰ４０２を介して以前に接続されたＰＳＡ－ＵＰＦ＃１４１１に接続されることもできる。

端末１０が新しいＵＰＦであるＵＬＣＬ／ＢＰ４０２を介し、新しいＰＳＡ－ＵＰＦ＃２４２１を介して接続する場合が発生することができる。この場合には、端末１０がＤＮＡＩ変更前には一番目のローカルデータネットワーク４１０に接続しており、端末１０のアプリがＥＡＳ＃１４１３に接続されているので、端末１０はＴＣＰコンテキストを生成することができる。また、前述したように、端末１０が移動によってＤＮＡＩが変更された場合、ＳＭＦ（図４に図示せず）が付加的な（Ａｄｄｉｔｉｏｎａｌ）ＰＳＡ追加手順を行うことができる。端末１０のアプリがＤＮＡＩ変更後には、二番目のローカルデータネットワーク４２０のＥＡＳ＃１４２３のＩＰアドレス、例えば「１０．１０．２０．１」に接続されなければならない。しかし、端末１０のＴＣＰコンテキストが維持されており、端末１０のアプリはローカルネットワークの変更を知らず、既存のＴＣＰコンテキストが続いて維持されているので、二番目のローカルデータネットワーク４２０のＥＡＳ＃１４２０と接続されない。

これをさらに詳しく説明すると、次のとおりである。
図４のネットワーク構成図において端末１０は、一番目のｌｏｃａｌＤＮ４１０が位置したところから二番目のｌｏｃａｌＤＮ４２０に接続するところに移動することができる。この場合、図４に例示したとおり、端末１０の一番目のＰＳＡ－ＵＰＦ４１１は変更されないこともある。すなわち、端末１０は、ＰＳＡ－ＵＰＦ＃１４１１を維持することができる。この場合、端末１０のＩＰアドレスは維持されるが、端末１０が一番目のｌｏｃａｌＰＳＡ－ＵＰＦ＃１４１１を介して接続される応用階層セッションは、一番目のｌｏｃａｌＤＮ４１０に対するＰＳＡ－ＵＰＦ４１１が解除される場合、端末１０のコンテキストは除去されなければならない。しかし、現在のＵＬＣＬ又はｌｏｃａｌＰＤＵ－ＵＰＦ削除動作では、端末１０にこれを知らせる情報が存在しない。この場合、端末１０が二番目のｌｏｃａｌＤＮ４２０に接続して同一のＥＡＳに接続しようと試みる場合、一番目のｌｏｃａｌＤＮ４１０に対する上位階層コンテキストが端末１０に残ることになる。したがって、端末１０は二番目のｌｏｃａｌＤＮ４２０のＥＡＳに接続できなくなる。これをさらに例を挙げて検討すると、このような上位階層コンテキストは、ＥＡＳの正規化されたドメイン名（ｆｕｌｌｙｑｕａｌｉｆｉｅｄｄｏｍａｉｎｎａｍｅ、ＦＱＤＮ）に対するドメインネームサーバー（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍｏｒＤｏｍａｉｎＮａｍｅｓｅｒｖｅｒ、ＤＮＳ）の情報になることができる。一番目のｌｏｃａｌＤＮから受信したＥＡＳのＤＮＳアドレスは、例えば、「１０．１０．１０．１」であり得る。このようなＤＮＳ手順は、ＤＮＳレコードのライフタイム分だけ端末１０のＤＮＳＣｌｉｅｎｔにおいてキャッシュされることができる。端末１０が移動又はＳＭＦ（図４に図示せず）の決定によって二番目のｌｏｃａｌＤＮに接続した場合にも、同一のＥＡＳ＃１のＤＮＳクエリーを行う場合、端末１０のＤＮＳｃｌｉｅｎｔにキャッシュされた情報によって「１０．１０．１０．１」のアドレスに接続を行うことになる。この場合、２番目のｌｏｃａｌＤＮにあるＥＡＳ＃１４２３にデータトラフィックの送受信が不可能である。

さらに他の例としては、一番目のｌｏｃａｌＤＮ４１０にＥＡＳ＃１４１３と接続指向的な上位階層セッションが繋がった場合である。例えば、端末１０のＴＣＰ接続が一番目のｌｏｃａｌＤＮ４１０とＥＡＳ＃１４１３の間に繋がることができる。このような状況でＳＭＦが端末１０の移動又はＳＭＦのローカル決定などによって一番目のｌｏｃａｌＤＮ４１０に接続されるＰＳＡ－ＵＰＦ４１１を除去し、二番目のｌｏｃａｌＤＮ４２０へのＰＳＡ－ＵＰＦ＃２４２１のセッションを接続した時、端末１０の上位階層ネットワークコンテキストのうちの一つであるＴＣＰ接続が以前のセッションから解除されずに維持されることになる。これにより、端末１０は二番目のｌｏｃａｌＤＮ４２０に位置したＥＡＳ＃１のＬＤＮ２４２３のＩＰアドレス、例えば、「１０．１０．２０．１」に接続できなくなる。

このような問題点を解決するために、本発明では図５ａ及び図５ｂのような端末内の構造を仮定する。
図５ａ及び図５ｂは、本発明の一実施例によって端末の内部構成及び無線通信ネットワーク及びデータネットワークとＰＤＵセッションを設定する場合を説明するための例示図である。

図５ａ及び図５ｂは、端末の構成及びネットワークの構成を一つの図面に全部表現しにくいので分離して例示した。また、特定の一つの構成要素内に含まれた構成要素、例えば、端末の通信プロセッサ又はモデム１０１０は、ＮＡＳ制御平面１０１１を含むことを図５ａ及び図５ｂによって確認することができる。

まず、図５ａを参照すると、端末１０は通信プロセッサ又はモデム１０１０とアプリケーションプロセッサ（ＡＰ）１０３０を含むことができる。下記で通信プロセッサ又はモデム１０１０は、「通信プロセッサ」と指し示めすか「モデム」と説明される全ての部分が図５ａ及び図５ｂの参照符号１０１０に該当することができる。また、図５ａ及び図５ｂで本発明を説明するにあたって、不要な要素は全て省略したことに留意すべきである。例えば、メモリー、電源（ｐｏｗｅｒ）、アンテナなどのように無線通信に必須的な要素をさらに含むことができる。その他にも、端末１０はユーザ便宜のための各種回路又はロジックを含むことができる。例えば、ＲＦ送受信回路、ディスプレイモジュール、タッチスクリーン、スピーカー、マイクなどのような多様な回路、ロジック及び／又はモジュールをさらに含むことができる。

アプリケーションプロセッサ１０３０は、基本的に少なくとも一つのアプリケーションが駆動されることができる。図５ａでは、互いに異なる２つのアプリケーション１０３１、１０３２が駆動される場合を例示した。アプリケーションプロセッサ１０３０内には、動作システムカーネル内にＴＣＰ／ＩＰスタック（ＴＣＰ／ＩＰｓｔａｃｋｉｎＯＳＫｅｒｎｅｌ）１０２０を含むことができる。下記では、説明の便宜のために「ＴＣＰ／ＩＰスタック」と称することにする。ＴＣＰ／ＩＰスタック１０２０内には第４の階層コンテキスト１０２１、１０２２を含むことができる。第４の階層コンテキスト１０２１、１０２２は、例えば、ソケット（ｓｏｃｋｅｔ）になることができる。ソケット１０２１、１０２２は、ソケットアプリケーションインターフェース（ａｐｐｌｉｃａｔｉｏｎｉｎｔｅｒｆａｃｅ、ＡＰＩ）を介して対応するアプリケーション１０３１、１０３２に接続されることができる。

また、通信プロセッサ１０１０とアプリケーションプロセッサ１０３０の間はネットワークインターフェース１０３１、１０３２、１０３３を介して接続されることができる。図５ａでは、互いに異なる３つのネットワークインターフェース１０３１、１０３２、１０３３を例示しており、そのうちの第１のネットワークインターフェース１０３１を介してソケット１０２１、１０２２に接続された形態を例示している。

端末１０は、基地局のようなアクセスネットワーク２０を介して５Ｇコア網５００に接続することができる。このように、端末１０が５Ｇコア網５００に接続された場合、端末１０と５Ｇコア網５００のＰＳＡ－ＵＰＦの間はＰＤＵセッションが形成されることができる。図５ａでは、一つの端末にＮ個のＰＤＵセッション５２１、５２２、５２３が設定可能な場合を例示している。

また、端末１０は、窮極的に５Ｇコア網５００内でサービスを提供されることができ、５Ｇコア網５００を介してデータネットワーク５１０、５１４、５１５のうち少なくとも一つのデータネットワーク５１０を介してデータサービスを提供されることもできる。図５ａでは、第１のデータネットワーク５１０がエッジコンピューティングデータネットワークである場合を例示した。しかし、データネットワーク５１０はローカルデータネットワーク（ｌｏｃａｌＤＮ）になり得る。

次に図５ｂを参照すれば、端末１０のＴＣＰ／ＩＰスタック１０２０内には、モデムに接続されるためのモデム制御インターフェース１０２１とＵＲＳＰマネージャ１０２２、ＤＮＳクライアント１０２３、コンテキストマネージャ１０２４、インターフェースマネージャ１０２５を含むことができる。また、端末１０のＴＣＰ／ＩＰスタック１０２０内には、図５ｂに説明した構成要素の他に必要に応じて追加的な構成要素をさらに有することもできる。

通信プロセッサ１０１０は、ＮＡＳ制御平面１０１１を含むことができる。

また、前述したように、５Ｇコア網５００は、ＡＭＦ１２０、ＳＭＦ１３０、ＰＣＦ１４０、ＵＤＭ１７０、ＮＥＦ１９０を含むことができる。追加的に、図１において前述したＵＤＲ５０４をさらに例示した。５Ｇコア網５００は、外部のＡＦ１５０とＮＥＦ１９０を介して接続されることができる。

端末１０の構成を図５ａ及び図５ｂに分離して例示したが、これらは当業者が図５ａ及び図５ｂに例示された図面から端末の全体的な構成を確認することができ、図５ａ及び図５ｂに例示された図面は、ネットワークインターフェースと上位階層コンテキストのための構成であることに留意しなければならない。

また、下記では図５ａ及び図５ｂを総称して図５と説明することにする。
図５で端末（ＵＥ；ＵｓｅｒＥｑｕｉｐｍｅｎｔ）１０は、前述したように、アプリケーションプロセッサ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｃｅｓｓｏｒ、ＡＰ）と通信プロセッサ（ＣｏｍｍｕｎｉｃａｔｉｏｎＰｒｏｃｅｓｓｏｒ、ＣＰ）で構成された形態を例示した。しかし、端末１０は、アプリケーションプロセッサと通信プロセッサを一つのワンチップで具現することもできる。この場合、アプリケーションプロセッサと通信プロセッサの構成が全て一つのプロセッサ内に含まれることができる。例えば、物理的に一つのプロセスが存在する場合であっても、ＡＰで行う機能とＣＰで行う論理的な機能は同一であることができる。ＡＰ内には端末１０のＡｐｐｌｉｃａｔｉｏｎが存在し、このようなＡｐｐｌｉｃａｔｉｏｎはソケット（ｓｏｃｋｅｔ）インターフェース１０４１を介してモバイル運営体制（例えば、アンドロイド（登録商標）、リナックス（登録商標）、タイジェン、ＢＳＤ系列のユニックス、そしてｉＯＳ）にネットワーク関連システム呼出及びシステムライブラリー呼出による要請及び応答を行うことができる。

また、前述したように、ＡＰで駆動されるモバイル運営体制内にはＴＣＰ／ＩＰスタック１０２０が存在し、ＴＣＰコンテキストを管理するためのカーネルソケットでＴＣＰＣｏｎｔｅｘｔを管理することができる。そして、モバイル運営体制ではネットワークインターフェース１０３１、１０３２、１０３３のうち少なくとも一つを介してＣＰ１０１０と通信することができる。また、ＡＰ１０３０内にはＵＲＳＰを処理するためのマネージャ（ＵＲＳＰＭａｎａｇｅｒ）１０２２、ＤＮＳクライアント１０２３、上位ネットワーク階層コンテキスト管理マネージャ（ＣｏｎｔｅｘｔＭａｎａｇｅｒ）１０２４、ネットワークインターフェースを管理するマネージャ（ＩｎｔｅｒｆａｃｅＭａｎａｇｅｒ）１０２５を含むことができる。また、このようなマネージャ１０２２、１０２３、１０２４、１０２５は、モデム制御インターフェース（ＭｏｄｅｍＣｏｎｔｒｏｌＩ／Ｆ）１０２１を介してＣＰ１０１０に接続され、制御目的として用いられることができる。ＣＰ１０１０は、３ＧＰＰ（登録商標）エアーインターフェース（ａｉｒｉｎｔｅｒｆａｃｅ）で提供する機能を具現して基地局と連動することができる。そして、ＣＰ１０１０内にはＮＡＳ制御平面１０１１を制御するモジュールが存在し、ＮＡＳ制御平面１０１１は５Ｇコア網５００のＡＭＦ１２０と連動することができる。セッションに関連するＮＡＳ制御メッセージは、ＡＭＦ１２０を介してＳＭＦ１３０に提供されることができる。

端末１０のネットワークインターフェースを介して送信されたプロトコルデータユニット（ＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ、ＰＤＵ）はＰＤＵセッションタイプがＩＰである場合、ＩＰデータグラムである。このようなＩＰデータグラムは、ＰＤＵセッション（図５の５２１）を介して５Ｇコア網５００のＰＳＡ－ＵＰＦ５０１まで到達することができる。ＰＳＡ－ＵＰＦ５０１は、受信されたＩＰデータグラムをＩＰ網であるデータネットワーク５１０に伝達することができる。

以下では、データネットワークがエッジコンピューティングデータネットワークである場合に仮定して説明する。データネットワーク５０１には、エッジアプリケーションサーバー（ＥｄｇｅＡｐｐｌｉｃａｔｉｏｎＳｅｒｖｅｒ、ＥＳＡ）５１１、５１２及びドメインネームサーバー（ＤｏｍａｉｎＮａｍｅＳｅｒｖｅｒ、ＤＮＳ）５１３が存在することができる。このようなＥＳＡ５１１、５１２とＤＮＳ５１３は、端末１０と通信することができる。５Ｇコア網５００内に存在するＵＤＭ、ＵＤＲ、ＮＥＦ、ＡＦ、ＡＭＦ、ＳＭＦ、ＰＣＦは、図１で説明したネットワーク機能と同様の機能を行うため、ここで重複説明は省略する。

図５で端末１０のネットワークインターフェースとＰＤＵセッションの間の関係は１：１接続を仮定して図示した。端末１０のアプリケーションがＴＣＰ接続を要請するとＴＣＰセッションが生成される。このような過程は「ｃｏｎｎｅｃｔ」システム呼出のような方法によってＴＣＰセッションの生成が要請されることができる。運営体制で成功的にＴＣＰセッションが生成されるとＴＣＰＣｏｎｔｅｘｔは端末のソースＩＰアドレスを有しているインターフェースにバインディング（ｂｉｎｄｉｎｇ）されることができる。

万一、ネットワークインターフェースがダウンすると、インターフェースにバインディングされたＴＣＰセッションに該当するコンテキストが全て除去される。このような動作によって、万一ＳＳＣＭｏｄｅ２の動作が行われる場合、ＳＭＦ１３０はＰＳＡ－ＵＰＦの移動のために一番目のＰＤＵセッションをリリースし、二番目のＰＤＵセッションを生成することができる。このような過程で、端末１０の一番目のＰＤＵセッションに接続されたＴＣＰコンテキストは全て除去され、セッションの連続性が保障できなくなる。

また、ＳＳＣＭｏｄｅ３で動作する場合、ＳＭＦ１３０はＰＳＡ－ＵＰＦの移動のために二番目のセッションを生成するように指示し、端末１０は２番目のＰＤＵセッションを生成し、一時的に一番目のＰＤＵセッションと二番目のＰＤＵセッションが同時にデータトラフィックを取り交わすことができる。このような状況で、端末１０内では一番目のＰＤＵセッションに相応する一番目のネットワークインターフェースが維持されながら二番目のＰＤＵセッションが生成された時、これに相応する二番目のネットワークインターフェースが生成される。その後、一番目のＰＤＵセッションがリリースされると、一番目のＰＤＵセッションに対するネットワークインターフェースがダウンし、このネットワークインターフェースにバインディングされたＴＣＰコンテキストが全で除去される。したがって、一番目のＰＤＵセッションの上位階層コンテキストは連続性が維持できなくなる。

本発明で提案する動作は、一番目のローカルＤＮが生成されるか解除される場合、ＳＭＦ１３０は端末１３０にＮＡＳシグナリングを介して、例えば、ＰＤＵセッション変更メッセージを介してＳＭＦ１３０で端末１０にｌｏｃａｌＤＮに関する情報を伝達する。これを受信した端末１０は、ＳＭＦ１３０で決定したポリシーに従って、ｌｏｃａｌＤＮから受信した情報を介して端末１０のＡＰ１０３０に存在する上位ネットワークコンテキストマネージャ、ＤＮＳｃｌｉｅｎｔ、ＵＲＳＰマネージャ１０２２などに関連する情報を伝達することができる。また、端末１０は、もし、ｌｏｃａｌＤＮと関連して上位ネットワーク階層で行うべきコマンドが存在する場合、このような情報を共に伝達することができる。端末のモデム（ＣＰ）１０１０では、このような上位階層に該当する情報を受信すると、このような情報及び指示事項をＡＰ１０３０に伝達し、ＡＰ１０３０では該当するマネージャがこれを行うことができる。例えば、もし、ＳＭＦ１３０が、新規ｌｏｃａｌＤＮが生成されて該当するｌｏｃａｌＤＮに対するＤＮＳサーバーアドレスを設定する場合、このような情報を受信したＡＰ１０３０は情報をＤＮＳｃｌｉｅｎｔ１０２３に伝達することができる。もしくは、ＳＭＦ１３０が新規ｌｏｃａｌＤＮを生成する時、該当するＩＰアドレスの範囲を端末１０のＣＰ１０１０に知らせる場合、端末のＣＰ１０１０はＡＰ１０３０に該当するＩＰアドレス範囲を上位階層コンテキストマネージャ１０２４に伝達して記録することができる。以後に、該当するｌｏｃａｌＤＮに対するｌｏｃａｌＰＳＡ－ＵＰＦを除去すると、ＳＭＦ１３０は端末１０のＣＰ１０１０にｌｏｃａｌＰＳＡ－ＵＰＦ除去情報を知らせることができる。これにより、ＳＭＦ１３０は、端末１０のＣＰ１０１０は該当するｌｏｃａｌＤＮに接続された上位階層コンテキスト１０２４に対する解除を要請する情報を追加に伝達することができる。すなわち、ＳＭＦ１３０は、これを受信した端末のＣＰ１０１０はＡＰ１０３０の上位階層コンテキストマネージャ１０２４にＳＭＦから受信された情報を知らせ、ＡＰ１０３０の上位階層コンテキストマネージャ１０２４はモバイル運営体制内で管理される上位階層コンテキスト（例えば、ＴＣＰｃｏｎｔｅｘｔ情報）を解除することができる。このような過程は、「ＵＲＳＰをｒｅ－ｅｖａｌｕａｔｉｏｎする」と表現することができる。

図５ｃは、本発明の一実施例によるローカルＤＮバインディングコンテキストを説明するための例示図である。

図５ｃは、図５ａ及び図５ｂで説明した端末１０の構成図の他の表現であり、特に本明細書で説明するＬｏｃａｌＤＮバインディングコンテキストについて追加的に説明する。別途に記述していない構成要素の説明は図５ａ及び図５ｂと同一である。図５ｃで参照符号が変わる部分は、本発明の説明のために新しく番号を付したものであり、図５ａ及び図５ｂと同様の観点でも理解されることができる。

図５ｃでは、端末のアプリケーション１１０３４は、ＬｏｃａｌＤＮ５５１のＥＡＳ＃１５５２とＴＣＰ接続を有しており、ＨｉｇｈＬａｙｅｒＯＳ内のＬａｙｅｒ４Ｃｏｎｔｅｘｔ＃１１０２１が生成される。また、端末のアプリケーション２１０３５は、ＣｅｎｔｒａｌＤＮ５４２に位置するＡＣ＃１５５３に接続している。ＬｏｃａｌＤＮ５４１のＥＡＳ＃１５５２に接続している端末のＬａｙｅｒ４Ｃｏｎｔｅｘｔ１０２１は、ｌｏｃａｌＤＮバインディングコンテキストの一例になることができる。本発明の動作中に上位階層ネットワークコンテキスト情報は、ＬｏｃａｌＤＮバインディングコンテキストになることができる。特に、ｌｏｃａｌＤＮ５４１の公知によって上位階層ネットワークコンテキストを制御する動作は、ｌｏｃａｌＤＮバインディングコンテキストを制御する動作に該当すると言え、ＬｏｃａｌＤＮバインディングコンテキスト動作は、例えば、図５ｃで図示したＬａｙｅｒＣｏｎｔｅｘｔ＃１の除去又は維持、又はＬｏｃａｌＤＮ５４１のために設定されたＤＮＳ５５１サーバーから受信したＤＮＳキャッシュ情報をリフレッシュする動作を含むことができる。

＜第１実施例＞
本発明の第１実施例は、ＳＭＦ１３０がＢＰ／ＵＬＣＬ及びｌｏｃａｌＰＳＡ－ＵＰＦの追加を決定する場合、ＳＭＦ１３０が端末１０にＰＤＵセッション変更メッセージを介して追加されるｌｏｃａｌＤＮに関する情報を知らせるための方式を提案する。ＳＭＦ１３０は、ＰＤＵセッションｌｏｃａｌＤＮに関する情報と共に上位階層ネットワークコンテキストに関する制御情報を共に伝達することができる。

図６は、本発明の一実施例によってＳＭＦがＵＥにＰＤＵセッションｌｏｃａｌＤＮに関する情報と共に上位階層ネットワークコンテキストに関する制御情報を提供する場合の信号フローチャートである。

図６を参照するに先立ち、まず、ローカルＤＮに関する設定情報は次の情報のうち少なくとも一つを含むことができる。
（１）ＤＮＳサーバーのアドレス、ＤＮＳサーバーが動作するドメイン名
（２）ＬｏｃａｌＤＮに対する識別子
（３）ＬｏｃａｌＤＮ追加／移動／削除を示す区分者：この区分者は、ＳＭＦ１３０がｌｏｃａｌＰＳＡ－ＵＰＦの追加を決定した場合、ｌｏｃａｌＤＮ追加を示し、ＳＭＦ１３０がｌｏｃａｌＰＳＡ－ＵＰＦを削除する場合、ｌｏｃａｌＤＮの削除を示す区分者である。
（４）追加するｌｏｃａｌＤＮのＩＰアドレス範囲に関する情報
（５）ＬｏｃａｌＤＮにルーティングしようとするトラフィックに対するサーバーＩＰアドレス又は目的地ＩＰアドレス、目的地Ｐｏｒｔ番号、そしてＩＰの上位階層ｐｒｏｔｏｃｏｌ番号、例えば、ＴＣＰ又はＵＤＰを指し示すプロトコル番号

次に、ローカルＤＮに関連した上位階層ネットワークコンテキスト制御情報は次の情報のうち少なくとも一つを含むことができる。
（１）ＬｏｃａｌＤＮに対する以前のＤＮＳｃａｃｈｅ情報を削除するか否か
（２）上位階層プロトコルに関するコンテキスト制御情報。例えば、上位階層プロトコル（例、ＴＣＰコンテキスト又はＨＴＴＰコンテキスト）維持指示者
（３）ＵＲＳＰに対するＲｅ－ｅｖａｌｕａｔｉｏｎ指示者：ＵＲＳＰの応用トラフィックに対するバインディングを解除し、ＵＲＳＰルールをｅｖａｌｕａｔｉｏｎすることを指示する。
（４）応用トラフィックのＰＤＵセッションバインディングに対するリフレッシュ指示者：特定の応用トラフィックがＰＤＵセッションに対するバインディングを解除し、コンテキストを削除することを指示する。

また、ＳＭＦ１３０はＰＣＦ１４０からＤＮＡＩを含むＡＦトラフィック制御情報（ＡＦＩｎｆｌｕｅｎｃｅｄＴｒａｆｆｉｃＳｔｅｅｒｉｎｇＥｎｆｏｒｃｅｍｅｎｔＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ）を受信することができる。端末１０の移動によってＳＭＦ１３０がＤＮＡＩの変更を感知すると、ＡｄｄｉｔｉｏｎａｌＰＳＡ追加とＬＤＮ追加情報を決定することができる。

ＳＭＦ１３０がＡｄｄｉｔｉｏｎａｌＰＳＡ追加を決定すると、ＳＭＦ１３０はＵＬＣＬ及びＬｏｃａｌＰＳＡ追加手順を行うことができる。

手順０の６１０動作において、端末１０は、既存に生成したＰＤＵセッションが存在し、ＰＳＡ１であるＵＰＦ６０２とＲＡＮ２０を介してトンネルが接続された状態であり得る。

手順１の６１２動作において、ＳＭＦ１３０は、ＵＥ移動性イベントに基づいて新規ＰＳＡであるＰＳＡ２に該当するＵＰＦ６０３を決定し、新規ＰＳＡ２とＮ４を生成することができる。ＳＭＦ１３０は、またＵＥ移動性イベントを受信（又は、検出）する時、ＰＣＣルール及び／又はＰＣＦ１４０から受信されたローカルＤＮ構成に基づいて「ＬｏｃａｌＤＮ公知制御情報」、「ＵＥ上位階層コンテキスト制御情報（すなわち、ＬｏｃａｌＤＮバインディングコンテキスト情報）」及びローカル処理トラフィックに対するステアリングを決定することができる。ＳＭＦ１３０はＡＦが要請したＥａｒｌｙＮｏｔｉｆｉｃａｔｉｏｎを送信することができる。そして、ＳＭＦ１３０は公知（Ｎｏｔｉｆｉｃａｔｉｏｎ）に対する応答を待機することができる。

手順２の６１４動作において、ＳＭＦ１３０は、新規ｌｏｃａｌＰＳＡ－ＵＰＦ６０３を選択し、ｌｏｃａｌＰＳＡ－ＵＰＦ６０３とＮ４セッションを生成することができる。

手順３の６１６動作において、ＳＭＦ１３０は、ＵＬＣＬ／ＢＰ６０１ＵＰＦを選択し、ＵＬＣＬ／ＢＰ６０１ＵＰＦとＰＳＡ１６０２とＰＳＡ２６０３に対するアップリンク伝達ルール（ＵＬＦｏｒｗａｒｄｉｎｇＲｕｌｅ）を生成することができる。ＳＭＦ１３０は、ＰＳＡ１６０２とＰＳＡ２６０３に向かうトラフィックルールをＵＬＣＬＵＰＦ６０１に伝達することができる。すなわち、ＳＭＦ１３０はＡＦトラフィック影響に対する遅延通知（ＴｒａｆｆｉｃＩｎｆｌｕｅｎｃｅＬａｔｅＮｏｔｉｆｉｃａｔｉｏｎ）をＡＦに送信することができる。その後、ＳＭＦ１３０は応答を待つことができる。

手順４の６１８動作において、ＳＭＦ１３０は、ＰＳＡ１６０２とのＮ４セッションを更新することができる。また、ＳＭＦ１３０は、ＤＬＴｒａｆｆｉｃに対してＵＬＣＬ－ＢＰ６０１に関するトンネル情報をＰＳＡ１６０２に提供することができる。

以後、ＰＳＡ１６０２は６２０動作において第１のＵＰＦ６０１にダウンリンクＰＤＵを送信することができる。これにより、第１のＵＰＦ６０１は受信されたダウンリンクＰＤＵを端末１０に提供することができる。また、端末１０は、６２２動作においてＰＳＡ１６０２に提供するためのアップリンクＰＤＵを、対応するトンネルを用いて送信することができる。６２０動作と６２２動作は、端末とＰＳＡ１６０２の間にトンネル情報を予め知っている場合、順序は変更されることができる。すなわち、トンネル情報を相互間に知っている場合、６２２動作の以後に６２０動作が行われることもある。

手順５の６２４動作において、ＳＭＦ１３０は、ＰＳＡ２６０３とのＮ４セッションを更新することができる。これにより、ＳＭＦ１３０は、ＤＬＴｒａｆｆｉｃに対してＵＬＣＬ－ＢＰ６０１に関するトンネル情報をＰＳＡ２６０３に提供することができる。

手順６Ａの６２６動作において、ＳＭＦ１３０は、端末１０にＬ－ＰＳＡ設定情報公知が必要な場合、ＳＭＦ１３０は端末１０にＰＤＵセッション変更コマンド（ＰＤＵＳｅｓｓｉｏｎＭｏｄｉｆｉｃａｔｉｏｎＣｏｍｍａｎｄ）を送信することができる。

ＬｏｃａｌＤＮ設定情報は、ＳＭＦ１３０に自体的に設定されているか、ＰＣＦ１４０に設定されていることができる。ＳＭＦ１３０は、ＳＭＰｏｌｉｃｙＡｓｓｏｃｉａｔｉｏｎの生成又は変更手順を介してＰＣＦ１４０から端末１０に関するポリシー及び課金制御（ＰｏｌｉｃｙａｎｄＣｈａｒｇｉｎｇＣｏｎｔｒｏｌ、ＰＣＣ）情報を受信する時、ＬｏｃａｌＤＮ設定情報を共に受信することができ、ＬｏｃａｌＤＮ設定情報は３－Ｔｕｐｌｅ情報、ＤＮＳアドレス、ＬｏｃａｌＤＮのｓｕｂｎｅｔアドレスを含むことができる。

ＳＭＦ１３０でＬｏｃａｌＰＳＡ－ＵＰＦに対する追加／変更／削除を決定すると、ＳＭＦ１３０はＬｏｃａｌＤＮイベントに関する情報としてこれを記録し、端末１０に伝達することができる。

ＳＭＦ１３０はＡＦ要請又はＰＣＦ１４０からＬｏｃａｌＤＮＢｉｎｄｉｎｇ制御情報を受信することができる。このような情報に基づき、ＳＭＦ１３０は次のような情報のうち少なくとも一つを含んで端末１０に伝達することができる。

（１）Ｌ－ＰＳＡ追加、
（２）追加された３－Ｔｕｐｌｅ目録、
（３）追加されたＳｕｂｎｅｔアドレス、
（４）ＤＮＳアドレス、
（５）既存のＤＮＳＲｅｆｒｅｓｈ指示者、
（６）上位ネットワークコンテキスト維持指示者、
（７）ＵＲＳＰトラフィックＴｒａｆｆｉｃＲｅ－ｅｖａｌｕａｔｉｏｎ指示者の情報

このような情報を受信した端末１０は、ＬＤＮ情報に明示された動作を行うことができる。すなわち、上位コンテキスト維持、ＵＲＳＰトラフィックＲｅ－ｅｖａｌｕａｔｉｏｎを行うことができる。その後、ＳＭＦ１３０は、手順６Ｂである６２８動作においてＮ１１を介してＮ２ＳＭ情報を、ＡＭＦ１２０を介してＲＡＮ２０に伝達することができる。すなわち、ＳＭＦ１３０は、新規ＣＮトンネル情報（ＵＬＣＬ／ＢＰトンネル情報）をＲＡＮ２０に伝達することができる。

一方、６３０動作において端末１０は、依然として以前のトンネルを用いて第１のＵＰＦ６０１を介してＰＳＡ１６０２にアップリンクＰＤＵを送信することができる。

手順７の６３２動作において、ＩＰｖ６Ｍｕｌｔｉ－Ｈｏｍｉｎｇ（ＭＨ）の場合、ＳＭＦ１３０は、ＰＳＡ２６０３を介してルータ広告（ＲｏｕｔｅｒＡｄｖｅｒｔｉｓｅｍｅｎｔ、ＲＡ）（ｎｅｗＩＰｐｒｅｆｉｘ、ｒｏｕｔｉｎｇｒｕｌｅ）メッセージを端末１０に伝達することができる。ＳＭＦ１３０は、また、遅延通知（ＬａｔｅＮｏｔｉｆｉｃａｔｉｏｎ）をＡＦに送信することができる。

手順８の６３４動作において、ＩＰｖ６ＭＨである場合、ＳＭＦ１３０はＰＳＡ１６０２を介して以前のＩＰｐｒｅｆｉｘを再設定するＲＡ（ｏｒｉｇｉｎａｌＩＰｐｒｅｆｉｘ、ｒｏｕｔｉｎｇｒｕｌｅ）を伝達することができる。

これにより、端末１０は、６３６動作において第１のＵＰＦ６０１にＰＳＡ１６０２に送信するためのアップリンクＰＤＵを送信することができる。そうすると、第１のＵＰＦ６０１はこれをＰＳＡ２６０３に提供することができる。

その後、６４０動作において端末１０は、上位階層制御、例えば、ＵＲＳＰ再評価、上位階層コンテキストリトレイン（ｒｅｔｒａｉｎ）又はリフレッシュ（ｒｅｆｒｅｓｈ）を行うことができる。

＜第２実施例＞
本発明による第２実施例は、端末１０の移動によってＳＭＦ１３０がＤＮＡＩ変更を感知し、ｌｏｃａｌＰＳＡを除去する手順時の端末とシステムへの動作を定義する。このような手順でＳＭＦ１３０は、ｌｏｃａｌＤＮ設定情報の公知を決定し、ｌｏｃａｌＤＮ設定変更公知と共に端末１０に上位階層ネットワークコンテキスト制御情報を伝達することができる。

第２実施例による手順は次のように行うことができる。下記の説明は、前述した図６の構成要素を用いて説明することにする。

１段階において端末１０は、ＬｏｃａｌＰＳＡ追加されたＰＤＵセッションが存在する（ＰＳＡ１を除去し、ＰＳＡ２を維持する手順）。

２段階においてＩＰｖ６ＭＨである場合、ＳＭＦ１３０はＰＳＡ１６０２とＰＳＡ２６０３に対するＵＥＩＰｖ６ｐｒｅｆｉｘを再設定することができる。

３段階においてＳＭＦ１３０は、多様な理由に基づいてＬｏｃａｌＰＳＡ除去を決定することができる。端末１０にＬ－ＰＳＡ設定情報公知が必要な場合、ＳＭＦ１３０は、端末１０にＰＤＵセッション変更コマンド（ＰＤＵＳｅｓｓｉｏｎＭｏｄｉｆｉｃａｔｉｏｎＣｏｍｍａｎｄ）を送信することができる。ＬＤＮ設定情報に含まれた情報は、ＬＤＮ除去、ＬＤＮ識別子、除去された３－Ｔｕｐｌｅ目録、除去されたＳｕｂｎｅｔアドレス、除去されたＤＮＳアドレス、既存ＤＮＳＲｅｆｒｅｓｈ指示者、上位ネットワークコンテキスト維持指示者、ＵＲＳＰトラフィックＴｒａｆｆｉｃＲｅ－ｅｖａｌｕａｔｉｏｎ指示者の情報を含んで伝達することができる

４段階においてＳＭＦ１３０は、ＲＡＮ２０にＰＳＡ２ＣＮトンネル情報を更新することができる。ＲＡＮ２０とＵＬＣＬ６０１の間の追加的なＵＰＦがあった場合（この場合は、ＵＰＦがｃａｓｃａｄｉｎｇされた場合（ｃａｓｃａｄｉｎｇＵＰＦ）に該当することができる）、そのＵＰＦに関するＣＮトンネル情報を更新することができる。

５段階においてＳＭＦ１３０は、ＰＳＡ２６０３に対するＮ４セッションにＡＮトンネル情報を更新することができる。ＲＡＮ２０とＵＬＣＬ６０１の間の追加的なＵＰＦがあった場合（この場合は、ＵＰＦがｃａｓｃａｄｉｎｇされた場合（ｃａｓｃａｄｉｎｇＵＦＰ）に該当することができる）、そのＵＰＦに対するＣＮトンネル情報を更新することができる。

６段階においてＳＭＦ１３０は、ＰＳＡ１６０２のＮ４をリリースすることができる。ＩＰｖ６ＭＨの場合、ＳＭＦ１３０はＩＰｖ６ｐｒｅｆｉｘをリリースすることができる。

７段階において、前述した段階４／５が行われた場合、ＳＭＦ１３０はＵＬＣＰ／ＢＰ６０１に該当するＮ４セッションをリリースすることができる。

＜第３実施例＞
本発明による第３実施例は、ｌｏｃａｌＤＮに対する事業者ポリシーに基づき、ＳＭＦ１３０がｌｏｃａｌＤＮ公知及び上位階層ネットワークコンテキスト制御情報を端末に伝達する方法を提供するための手順である。

図７ａ及び図７ｂは、本発明の一実施例によってＳＭＦがｌｏｃａｌＤＮ公知及び上位階層ネットワークコンテキスト制御情報を端末に提供する際の信号フローチャートである。

移動通信事業者は、ＰＣＦ１４０の事業者ポリシー情報にｌｏｃａｌＤＮに対する設定情報を事前に設定することができる。ＰＣＦ１４０に設定されている事業者ポリシー情報は、ＤＮＡＩ別にｌｏｃａｌＤＮに関する情報を含むことができる（ｏｐｅｒａｔｏｒｃｏｎｆｉｇｕｒｅｄｌｏｃａｌＤＮｉｎｆｏｒｍａｔｉｏｎ）。

事業者ポリシー情報を例示すると、下記のような情報のうち少なくとも一つを含むことができる。
●ＬｏｃａｌＤＮ識別子：ＤＮＡＩ
●ＬｏｃａｌＤＮに対するサービス領域：ＴｒａｃｋｉｎｇＡｒｅａｏｒＣｅｌｌｌｉｓｔ
●ＩＰアドレス範囲、例えば、１０．１０．１０．＊
●ＬｏｃａｌＤＮＳ運営をするか否か
●ＬｏｃａｌＤＮＳアドレス及びＬｏｃａｌＤＮＳに対するドメイン名
●Ｓｅｒｖｉｃｅ提供者識別子、又はスポンサー識別子
●ＬｏｃａｌＤＮ移動時、サービス連続性提供をするか否か
●ＬｏｃａｌＤＮ情報に対する端末公知をするか否か

ＰＣＦ１４０は、ｌｏｃａｌＤＮに対する設定情報に基づき、ＡＦトラフィックステアリング施行制御情報にｌｏｃａｌＤＮ制御情報を含むＰＣＣルールを生成し、ｌｏｃａｌＤＮ公知制御情報をＳＭＦ１３０に伝達することができる。ローカルＤＮ公知制御情報は、次のような情報のうち少なくとも一つを含むことができる。

●ＬｏｃａｌＤＮの識別子（例えば、ＤＮＡＩ（ＤａｔａＮｅｔｗｏｒｋＡｃｃｅｓｓＩｄｅｎｔｉｆｉｅｒ）
●ＬｏｃａｌＤＮ情報の端末公知をするか否か
●ＬｏｃａｌＤＮバインディング制御情報：ＬｏｃａｌＤＮバインディング制御情報はＬａｙｅｒ４（ＴＣＰ）ｃｏｎｔｅｘｔ維持／リフレッシュ情報及びＤＮＳキャッシュリフレッシュ情報を含むことができる。
●ＬｏｃａｌＤＮ離脱時、端末の上位ネットワークコンテキストリフレッシュ指示者
●ＬｏｃａｌＤＮ設定情報

ＳＭＦ１３０はＰＣＣルールを受信し、端末１０がＤＮＡＩ領域に進入すると、ｌｏｃａｌＰＳＡ及びＵＬＣＬ追加動作を行うことができる。したがって、端末１０は、ＬｏｃａｌＤＮ制御情報に従って動作することができる。

ＳＭＦ１３０は端末１０にｌｏｃａｌＤＮ追加公知を伝達し、上位ネットワーク階層制御情報を伝達することができる。

添付した図７ａ及び図７ｂを参照して本発明による信号フロー及びその動作について検討する。図７ａと図７ｂは順次に行われることができる。例えば、図７ａのフローが完了された後、図７ｂの信号フローが連続して行われることができる。他の例として、図７ｂは図７ａとは無関係に行われることもある。下記の説明では図７ａと図７ｂが順次に行われる場合を例にして説明することにする。

手順７０１～７０２において、端末１０は、ＰＤＵセッションの生成要請（ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭｃｏｎｔｅｘｔＲｅｑｕｅｓｔ）メッセージをＡＭＦ１２０を介してＳＭＦ１３０に伝達することができる。端末１０は、一番目のＰＤＵセッションの生成時に、ＬｏｃａｌＤＮ制御機能サポートをするか否か及び上位階層ネットワークコンテキスト制御機能サポートをするか否かを含む情報をＳＭＦ１３０に伝達することができる。

手順７０３において端末１０からＰＤＵセッション要請を受信したＳＭＦ１３０は、端末１０に関する加入者情報を確認するために、ＵＤＭ１７０から加入者情報を受信することができる。

手順７０４において端末１０に関する加入者情報を取得したＳＭＦ１３０は、ＡＭＦ１２０にＰＤＵセッションの生成コンテキスト応答（ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭｃｏｎｔｅｘｔＲｅｓｐｏｎｓｅ）メッセージを送信することができる。

手順７０５においてＳＭＦ１３０は、ＰＣＦ１４０とＳＭポリシーを受信するための接続を生成し、ＰＣＦ１４０から端末１０のＰＤＵセッションに関するＰＣＣルールを受信することができる。ＰＣＣルールには、ＡＦ要請したトラフィックステアリング施行制御情報（ＡＦＩｎｆｌｕｅｎｃｅｄＴｒａｆｆｉｃＳｔｅｅｒｉｎｇＥｎｆｏｒｃｅｍｅｎｔＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ）を含むことができる。ＡＦ要請トラフィックステアリング施行制御ルールには、次のような情報のうち少なくとも一つを含むことができる。

（１）ＤＮＡＩ（ＤａｔａＮｅｔｗｏｒｋＡｃｃｅｓｓＩｎｄｅｎｔｉｆｉｅｒ）
（２）ＬｏｃａｌＲｏｕｔｉｎｇサポートをするか否か：ＬｏｃａｌＲｏｕｔｉｎｇサポートをするか否かは、さらに詳しくＩＰｖ６Ｍｕｌｔｉｈｏｍｉｎｇサポートであるか、又はＵＬＣＬサポートであるかを示すことができる。
（３）ＩＰアドレス維持指示者（又はネットワークインターフェース維持指示者）
（４）上位階層コンテキスト維持指示者、又は上位階層ネットワークリフレッシュ指示者
（５）応用階層Ｒｅｌｏｃａｔｉｏｎ可能であるか否か
（６）Ｎ６ルーティング情報
（７）ローカルＤＮ制御情報

ローカルＤＮ制御情報は、ＳＭＦ１３０がｌｏｃａｌＤＮに接続できるようにｌｏｃａｌＰＳＡ－ＵＰＦを追加する場合、端末１０にｌｏｃａｌＤＮに関する情報を公知するか否か及び端末１０に公知すべき情報を含むことができる。

手順７０６においてＳＭＦ１３０は、端末が提供したＳＳＣサポートをするか否か、ＰＣＦ１３０から受信したＡＦ要請トラフィックステアリング施行制御をサポート可能な一番目のＰＳＡ－ＵＰＦ７０１を選択することができる。

手順７０７～７０８においてＳＭＦ１３０は、ＰＤＵセッションの生成を決定し、ＰＤＵセッション生成応答メッセージをＡＭＦ１２０を介して端末１０に伝達することができる。

手順７０９～７１０においてＳＭＦ１３０は、ＡＭＦ１２０からＲＡＮ２０で提供したＲＡＮトンネル情報を受信し、ＰＳＡ－ＵＰＦ１７９１のダウンリンクトラフィックに関するトンネル情報を設定することができる。

上記ではＰＤＵセッション設定手順（ＰＤＵＳｅｓｓｉｏｎＥｓｔａｂｌｉｓｈｍｅｎｔＰｒｏｃｅｄｕｒｅ）について検討した。下記では、ローカルＰＳＡが新しく追加される場合（ＴｒｉｇｇｅｒｉｎｇｏｆｌｏｃａｌＰＳＡｉｎｓｅｒｔｉｏｎ）について検討する。

手順７１１において端末１０が現在の登録領域の離脱を感知した場合、端末１０は登録要請メッセージをＲＡＮを介してＡＭＦ１２０に伝達することができる。もしくは、端末１０が基地局２０のコマンドによって他の基地局にハンドオーバーを行った場合に、ハンドオーバーの過程でＡＭＦ１２０は基地局２０からハンドオーバー発生を感知することができる。もしくは、端末１０が遊休状態（ＣＭ－ＩＤＬＥ；ＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｍｅｎｔＩＤＬＥ状態）でサービス要請を伝達する場合、ＡＭＦ１２０は端末１０が移動したことを感知することができる。ＡＭＦ１２０は、ＰＤＵＳｅｓｓｉｏｎを更新するためのＰＤＵＳｅｓｓｓｉｏｎ＿Ｕｐｄａｔｅ＿ＳＭＣｏｎｔｅｘｔ要請に端末１０の位置情報を含んでＳＭＦ１２０に伝達することができる。

手順７１２においてＰＣＦ１４０は、ＡＦからＡＦトラフィックステアリングに対する要請を受信するか、又は事業者内部のＡＦトラフィックステアリングルールが変更される場合、ＳＭＦ１３０にＡＦ要請トラフィックステアリング施行制御情報を含むＰＣＣ（ＰｏｌｉｃｙａｎｄＣｈａｒｇｉｎｇＣｏｎｔｒｏｌ）ルールを伝達することができる。ＡＦ要請トラフィックステアリング施行制御情報は、前述した手順７０５における情報、例えば、ｌｏｃａｌＤＮ制御情報及び上位階層ネットワークコンテキスト制御情報を含むことができる。

手順７１３においてＳＭＦ１３０は、端末１０の移動によって端末１０の位置の移動を感知した場合（手順７１１）、ＳＭＦ１３０に事前に設定されたか、ＰＣＣルールを介して登録されているＤＮＡＩに移動したか否かを識別（判断）することができる。もしくは、ＳＭＦ１３０は、ＰＣＣからＡＦ要請トラフィック制御施行情報を受信した場合、該当端末の位置がＤＮＡＩにマッピングされている位置に含まれているかを識別（判断）することができる。ＳＭＦ１３０がＵＬＣＬ／ＢＰとｌｏｃａｌＰＳＡ－ＵＰＦの追加を識別（判断）すると、ＳＭＦ１３０は図７のフェーズＣ（ＰｈａｓｅＣ）に該当する手順を行うことができる。

下記ではフェーズＣについて検討する。フェーズＣはＵＬＣＬ／ＢＰ及びｌｏｃａｌＰＳＡ－ＵＰＦの追加（挿入）手順（ＰｒｏｃｅｄｕｒｅｆｏｒＵＬＣＬ／ＢＰａｎｄｌｏｃａｌＰＳＡ－ＵＰＦｉｎｓｅｒｔｉｏｎ）になり得る。

手順７１４においてＳＭＦ１３０は、ＰＳＡ２７９２とＮ４セッションを生成することができる。

手順７１５においてＳＭＦ１３０は、ＵＬＣＬ／ＢＰＵＰＦ７９３とＮ４セッションを生成することができる。

手順７１６においてＳＭＦ１３０は、ダウンリンクトラフィックのためにＰＳＡ１のＮ４セッションを変更することができる。すなわち、ＲＡＮ２０に向かったトンネル情報を手順１５において生成したＵＬＣＬ／ＢＰＵＰＦ７９３のトンネル情報に更新することができる。その後、ＰＳＡ１７９１からのダウンリンクトラフィックはＵＬＣＬ／ＢＰ７９３に向かうことになる。

手順７１７においてＳＭＦ１３０は、ＰＳＡ２７９２とＮ４セッションを更新することができる。

手順７１８においてＳＭＦ１３０は、手順７１３におけるトリガー条件、すなわちＡＭＦ１２０からの端末１０の位置情報を介して端末１０の位置変更を感知し、これに該当するＤＮＡＩ変更をするか否かを識別（判断）することができる。もしくは、ＳＭＦ１３０はＰＣＦ１４０からＡＦ要請トラフィックステアリング施行制御情報を含むＰＣＣルールを受信することができる。ＰＣＣルールにはｌｏｃａｌＤＮ設定情報を含むｌｏｃａｌＤＮ制御情報及び端末の上位階層ネットワークコンテキスト制御情報が含まれることができる。ＬｏｃａｌＤＮ制御情報はｌｏｃａｌＤＮに接続される新しいｌｏｃａｌＵＰＦが追加される場合、端末にｌｏｃａｌＤＮ設定情報と共に端末の上位階層ネットワークコンテキスト制御情報の伝達を指示するｌｏｃａｌＤＮ制御情報が含まれることができる。ＳＭＦ１３０はこのようなｌｏｃａｌＤＮ制御情報を受信し、ｌｏｃａｌＰＳＡ－ＵＰＦ追加を決定すると、端末１０にｌｏｃａｌＤＮ設定情報及び上位階層ネットワークコンテキスト制御情報を端末１０に伝達するためのＰＤＵセッション更新コマンドメッセージ（ＰＤＵＳｅｓｓｉｏｎＭｏｄｉｆｉｃａｔｉｏｎＣｏｍｍａｎｄ）を、ＡＭＦ１２０を介して端末１０に伝達することを決定することができる。

手順７１９においてＳＭＦ１３０は、ＡＭＦ１２０にＰＤＵセッション更新コマンドメッセージが含まれたＮ１Ｎ２ＭｅｓｓａｇｅＴｒａｓｆｅｒメッセージを伝達することができる。本メッセージには、ＰＤＵセッション識別子、ｌｏｃａｌＤＮ設定情報、そして上位階層ネットワークコンテキスト制御情報が含まれることができ、これはＰＤＵセッションを修正するための情報になることができる。

ＬｏｃａｌＤＮ設定情報は、前述した第１実施例で記述したｌｏｃａｌＤＮ情報と同同じであることができる。また、上位階層ネットワークコンテキスト制御情報も前述した第１実施例で記述した上位階層ネットワークコンテキスト制御情報と同じであることができる。

ＳＭＦ１３０がＵＬＣＬ／ＢＰの追加を決定すると、ＵＬＣＬ／ＢＰとＰＳＡ１，またはＵＬＣＬ／ＢＰとＰＳＡ２のトンネル設定のために、ＣＮトンネル情報をＲＡＮ２０に伝達するために、Ｎ１Ｎ２ＭｅｓｓａｇｅＴｒａｎｓｆｅｒメッセージと共にＡＭＦ１２０に伝達することができる。

手順７２０においてＡＭＦ１２０は、Ｎ２メッセージでＳＭＦ１３０から受信した情報Ｎ１Ｎ２ＭｅｓｓａｇｅＴｒａｎｓｆｅｒに含まれた内容をＮ２メッセージの情報の全部又は少なくとも一部をＲＡＮ２０に伝達することができる。

手順７２１においてＲＡＮＮ２メッセージに含まれた内容のうち、ＲＡＮで受信したＬｏｃａｌＵＬＣＬ／ＢＰに対するアップリンクトラフィックのためのトンネル情報を設定することができる。ＲＡＮ２０は、端末１０にＡＮ－ｓｐｅｃｉｆｉｃｒｅｓｏｕｒｃｅｍｏｄｉｆｉｃａｔｉｏｎ手順を行い、Ｎ２メッセージに含まれているＰＤＵセッション変更コマンドメッセージを端末に伝達することができる。その後、ＲＡＮ２０は、端末１０からこれに対する応答を受信することができる。

手順７２２においてＲＡＮ２０は、ＰＳＡ２７９２のために新規において生成したトンネル情報と端末１０から受信したＰＤＵセッション変更コマンドに対する応答メッセージをＡＭＦ１２０に伝達することができる。

手順７２３においてＡＭＦ１２０は、ＲＡＮ１０から受信した情報をＳＭＦ１３０に伝達し、その応答を受信することができる。

手順７２４においてＳＭＦ１３０は、ＩＰｖ６ｍｕｌｔｉｈｏｍｉｎｇである場合、端末１０にＰＳＡ２７９２のための新規ＩＰｐｒｅｆｉｘを割り当て、端末１０に伝達することができる。

手順７２５においてＳＭＦ１３０は、ＩＰｖ６ｍｕｌｔｉｈｏｍｉｎｇである場合、端末１０にＰＳＡ１７９１に対する既存のＩＰｐｒｅｆｉｘ情報を再設定することができる。

＜第４実施例＞
第４実施例は、ＡＦ要請によりｌｏｃａｌＰＳＡを変更する手順中に端末にｌｏｃａｌＤＮ情報と上位階層ネットワークコンテキスト情報を伝達する手順及び各ノードの動作を提供する。

図８ａ及び図８ｂは、本発明の実施例によるネットワークにおいてＡＦ要請によってｌｏｃａｌＰＳＡを変更する際の端末への情報の提供、及びそれによる各ノードの動作に関する信号フローチャートである。下記では、特に図８ａと図８ｂを区分すべき場合でなければ、総称して図８と説明する。また、図８ａの動作以後に図８ｂの動作が行われることができる。他の例として、図８ａの動作なしに、他の動作を行った後、図８ｂの動作が行われることもできる。

手順８０１において端末１０は、ＳＭＦ１２０と共にＰＤＵセッションを生成することができる。ＳＭＦ１２０はこの過程でＰＳＡ－ＵＰＦ０８０２を選択することができる（手順８０１－１）。この手順に対するさらに詳細な手順は、第３実施例の手順７０１～手順７１０に記述されているので、重複説明は省略する。また、ＳＭＦ１２０は、ＵＬＣＰ／ＢＰ及びｌｏｃａｌＰＳＡ－ＵＰＦ１の追加を決定することができる（手順８０１－２）。このような手順は、第３実施例の手順７１１～手順７２５に記述されているので、これも重複説明は省略する。

手順８０２においてＳｏｕｒｃｅＥＥＳ８０７は、ＳｏｕｒｃｅＡＦとして動作してＡＦ要請をＰＣＦ８０５に伝達することができる。図８では、前述の図１～図３におけるＰＣＦ１４０とＮＥＦ１９０が一つのノードとして例示された。これは、互いに異なる動作を行うが、図面構成の便宜のためのものである。したがって、参照符号８９５に対して下記の説明では、ＰＣＦとして動作する場合はＰＣＦ８９５と説明し、ＮＥＦとして動作する場合はＮＥＦ８９５と説明する。ＡＦ要請をＰＣＦ８９５に伝達する方法は。ＮＥＦ８９５を介してＵＤＲ（図８に図示せず）にＡＦ要請を格納し、ＵＤＲ情報変更に対する公知を受信したＰＣＦ８９５が受信することができる。ＡＦ要請を受信したＰＣＦ８９５は、上記の第３実施例で記述したローカルＤＮに対する事業者ポリシーを考慮し、ＳＭＦ１３０にＡＦ要請トラフィックステアリング施行制御情報にｌｏｃａｌＤＮ制御情報と端末上位階層ネットワークコンテキスト制御情報を含んでＳＭＦ１３０に伝達することができる。ＬｏｃａｌＤＮ制御情報と端末上位階層ネットワークコンテキスト制御情報を含んでＳＭＦ１３０に伝達することができる。

手順８０３においてＳＭＦ１３０は、ＰＣＦ８９５から端末１０のＰＤＵセッションに対するＰＣＣルールを受信することができる。ＰＣＣルールには、ＡＦ要請したトラフィックステアリング施行制御情報（ＡＦＩｎｆｌｕｅｎｃｅｄＴｒａｆｆｉｃＳｔｅｅｒｉｎｇＥｎｆｏｒｃｅｍｅｎｔＣｏｎｔｒｏｌＩｎｆｏｒｍａｔｉｏｎ）を含むことができる。ＡＦ要請トラフィックステアリング施行制御ルールには、次のような情報のうち少なくとも一つを含むことができる。

（１）ＤＮＡＩ（ＤａｔａＮｅｔｗｏｒｋＡｃｃｅｓｓＩｎｄｅｎｔｉｆｉｅｒ）
（２）ＤＮＡＩとｍａｐｐｉｎｇされたサービス領域に関する情報
（３）ＬｏｃａｌＲｏｕｔｉｎｇサポートをするか否か：ＬｏｃａｌＲｏｕｔｉｎｇサポートをするか否かは、さらに詳しくＩＰｖ６Ｍｕｌｔｉｈｏｍｉｎｇサポートであるか、又はＵＬＣＬサポートであるかを示すことができる。
（４）ＩＰアドレス維持指示者（又はネットワークインターフェース維持指示者）
（５）上位階層コンテキスト維持指示者又は上位階層ネットワークリフレッシュ指示者
（６）応用階層Ｒｅｌｏｃａｔｉｏｎ可能であるか否か
（７）Ｎ６ルーティング情報
（８）ローカルＤＮ制御情報

手順８０４で端末１０が現在の登録領域の離脱を感知した場合、端末１０は登録要請メッセージをＲＡＮ２０を介してＡＭＦ１２０に伝達することができる。もしくは、端末１０が基地局のコマンドによって他の基地局にハンドオーバーを行った場合に、ハンドオーバー過程においてＡＭＦ１２０は基地局からハンドオーバー発生を感知することができる。もしくは、端末１０が遊休状態（ＣＭ－ＩＤＬＥ；ＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｍｅｎｔＩＤＬＥ状態）でサービス要請を伝達する場合、ＡＭＦ１２０は端末１０が移動したことを感知することができる。ＡＭＦ１２０は、ＰＤＵＳｅｓｓｉｏｎを更新するためのＰＤＵＳｅｓｓｓｉｏｎ＿Ｕｐｄａｔｅ＿ＳＭＣｏｎｔｅｘｔ要請に端末１０の位置情報を含んでＳＭＦ１２０に伝達することができる。

手順８０５においてＳＭＦ１２０は、上記の手順８０３において受信したＰＣＣルール、又は手順８０４において受信した端末１０の位置情報を介してｌｏｃａｌＰＳＡｒｅｌｏｃａｔｉｏｎするか否かを決定することができる。例えば、ｌｏｃａｌＤＮに関する情報が下記のように設定されていると仮定する。

１）ＬｏｃａｌＤＮ１に関する情報
●ＬｏｃａｌＤＮ識別子：ＤＮＡＩ－Ａ
●ＳｅｒｖｉｃｅＡｒｅａ：ＴＡ１、ＴＡ２
●ＡｓｓｏｃｉａｔｅｄｌｏｃａｌＰＳＡ－ＵＰＦ：ＰＳＡ－ＵＰＦ＃１
●ＩＰｓｕｂｎｅｔａｄｄｒｅｓｓ：１０．１０．１０．＊
●ＬｏｃａｌＤＮＳａｄｄｒｅｓｓ：１０．１０．１０．２００
●ＬｏｃａｌＤＮＳｄｏｍａｎｎａｍｅ：ｌｏｃａｌ１．ｅｘａｍｐｌｅ．ｃｏｍ

２）ＬｏｃａｌＤＮ２に関する情報
●ＬｏｃａｌＤＮ識別子：ＤＮＡＩ－Ｂ
●ＳｅｒｖｉｃｅＡｒｅａ：ＴＡ３、ＴＡ４
●ＡｓｓｏｃｉａｔｅｄｌｏｃａｌＰＳＡ－ＵＰＦ：ＰＳＡ－ＵＰＦ＃２
●ＩＰｓｕｂｎｅｔａｄｄｒｅｓｓ：１０．１０．２０．＊
●ＬｏｃａｌＤＮＳａｄｄｒｅｓｓ：１０．１０．２０．２００
●ＬｏｃａｌＤＮＳｄｏｍａｎｎａｍｅ：ｌｏｃａｌ２．ｅｘａｍｐｌｅ．ｃｏｍ

ＳＭＦ１３０は、またＰＣＦ８９５からｌｏｃａｌＤＮ制御情報を受信することができる。上記で説明したＬｏｃａｌＤＮ設定情報は、ＳＭＦで自体的に設定されていることができ、ＰＣＦ１４０に設定され、ＳＭＦ１３０がＰＣＦ１４０から受信することもできる。この情報は、次のような事業者ポリシーを含むことができる。このような事業者情報は、ＳＭＦ１３０内に事前にローカルに設定されていることもある。

－ＤＮＡＩ生成時、端末にｌｏｃａｌＤＮ設定情報公知をするか否か
－ＤＮＡＩ変更時、端末にｌｏｃａｌＤＮ変更情報公知をするか否か
－ＤＮＡＩ除去時、端末にｌｏｃａｌＤＮ除去情報公知をするか否か

ＳＭＦ１３０は、ＡＭＦ１２０に受信した端末１０の位置情報を介して関連したＤＮＡＩを識別（判断）し、ＤＮＡＩをサポートするＰＳＡ－ＵＰＦ＃２８０４へのｌｏｃａｌＰＳＡ－ＵＰＦの移動を決定することができる。このような決定は、ｌｏｃａｌＤＮの変更を意味し、ＳＭＦ１３０はＰＣＦ８９５から受信したｌｏｃａｌＤＮ制御情報ポリシーにしたがって、端末にｌｏｃａｌＤＮ設定情報を公知するか、又はｌｏｃａｌＤＮ変更情報を公知するか、以前のｌｏｃａｌＤＮ制御情報を公知することを決定することができる。ｌｏｃａｌＤＮが変更される場合、ＳＭＦ１３０は端末１０にｌｏｃａｌＤＮ設定情報を送信するためのＰＤＵセッション変更手順を行うことができる。

また、ＰＣＦ８０５はｌｏｃａｌＤＮ制御情報と共に、端末１０の上位階層ネットワークコンテキスト情報をＰＣＣルールに含んでＳＭＦ１２０に伝達することができる。これに対する設定情報は、次のような情報を含むことができる。

－ＤＮＡＩ変更時、端末に上位階層ネットワークコンテキスト維持又はリフレッシュ指示者
－ＤＮＡＩ除去時、端末に上位階層ネットワークコンテキスト維持又はリフレッシュ指示者

例えば、ｌｏｃａｌＤＮ１とｌｏｃａｌＤＮ２が前述した例のように互いに異なるＩＰアドレス範囲にあると、ＰＣＦ８９５は、ＤＮＡＩ変更時に上位階層ネットワークコンテキストのリフレッシュを指示するポリシーをＳＭＦ１３０に伝達することができる。このようなポリシーを受信したＳＭＦ１３０は、端末１０にＰＤＵセッション変更コマンドメッセージを介し、ポリシーに該当する指示者を選択して伝達することができる。例えば、ＳＭＦ１３０は端末１０に上位階層ネットワークコンテキストリフレッシュ指示者を伝達することができる。もしくは、ＳＭＦ１３０はＤＮＡＩが変更される場合、ｌｏｃａｌＤＮ情報のＩＰアドレスの範囲に基づいてコンテキストをリフレッシュすることを決定し、端末１０に上位階層コンテキストリフレッシュ指示者を含んで伝達することができる。

ＳＭＦ１３０は、ＤＮＡＩが変更され、既存に生成されたｌｏｃａｌＰＳＡ－ＵＰＦの解除を決定することができる。この場合、ＳＭＦ１３０は端末１０にｌｏｃａｌＤＮに関する削除情報と共に、上位階層ネットワークコンテキストリフレッシュ指示者を含んで伝達することができる。ＬｏｃａｌＤＮ削除情報はｌｏｃａｌＤＮに対する識別と削除されたことを示す区分者を含むことができる。

ユーザイベント公知に対する条件を満たすと、ＳＭＦ１３０は現在の端末１０の位置でＡＦ要請を満たせるＰＳＡ－ＵＰＦＲｅｌｏｃａｔｉｏｎを行うことができるかを決定し、これに対する公知をＡＦ（ＳｏｕｒｃｅＥＥＳ）８９７に伝達することができる。ＡＦのＥａｒｌｙ公知は、下のような内容のうち少なくとも一つを含むことができる。

－ＩＰアドレス維持可能であるか否か
－ＰＳＡ－Ｒｅｌｏｃａｔｉｏｎするか否か
－ＰＳＡ移動時、予想ＰＤＢに関する情報
－ＤＮＡＩが変更される場合、変更される目的地ＤＮＡＩ情報

ＳｏｕｒｃｅＥＥＳ８９７は、ＳＭＦ１３０からユーザ平面イベントに対するＥａｒｌｙ公知を受信することができる。ＳｏｕｒｃｅＥＥＳ８９７は、受信した情報を介してＡｐｐｌｉｃａｔｉｏｎコンテキスト移動をするか否かを決定することができる。ＳｏｕｒｃｅＥＥＳ８９７は、下記のような条件を満す場合、ＡｐｐｌｉｃａｔｉｏｎＣｏｎｔｅｘｔの移動を決定することができる。条件を満さない場合、ＳｏｕｒｃｅＥＥＳ８９７はＡｐｐｌｉｃａｔｉｏｎＣｏｎｔｅｘｔ移動を決定しないことができる。

ＳｏｕｒｃｅＥＥＳ８９７がＡｐｐｌｉｃａｔｉｏｎＣｏｎｔｅｘｔの移動を決定する場合、手順８１６及び手順８１７を行うことができる。

ＳｏｕｒｃｅＥＥＳ８９７がＰＳＡＲｅｌｏｃａｔｉｏｎを決定する場合、ＳｏｕｒｃｅＥＥＳ８９７はＡｐｐＲｅｌｏｃａｔｉｏｎＩｎｆｏメッセージに肯定的な応答を伝達することができる。もし、ＳｏｕｒｃｅＥＥＳ８９７がＰＳＡ－ＵＰＦの移動が必要ないと判断すると、ＳｏｕｒｃｅＥＥＳ８９７はＳＭＦ１３０に否定的な応答を伝達することができる。

ＳｏｕｒｃｅＥＥＳ８９７がＰＳＡＲｅｌｏｃａｔｉｏｎの実行に対する応答を肯定的に決定した場合、ＥＥＳ８９７はＡｐｐＲｅｌｏｃａｔｉｏｎＩｎｆｏメッセージに下記のような情報のうち少なくとも一つを含んで応答することができる。

－ＰＳＡＲｅｌｏｃａｔｉｏｎに対する肯定的な応答
－ＡＦ変更されるという指示者
－公知を受けるＴａｒｇｅｔＡＦに対する公知アドレス
－端末の上位階層ネットワークコンテキスト維持指示者

ＳＭＦ１３０は、ＳｏｕｒｃｅＥＥＳ（ＡＦ）８９７からＥａｒｌｙ公知に対する応答メッセージを受信することができる。応答メッセージに肯定的な結果を受信した場合、ＳＭＦ１３０は新しいＰＳＡ－ＵＰＦ１を選択してＮ４セッションを生成することができる。

ＳＭＦ１３０はＳｏｕｒｃｅＥＥＳ（ＡＦ）８９７にＬａｔｅ公知を伝達することができる。

ＳｏｕｒｃｅＥＥＳ８９７がＡＦに送信する遅延公知メッセージには、次のような情報のうち少なくとも一つを含むことができる。

－ＴａｒｇｅｔＤＮＡＩ
－端末のＩＰアドレス
－上位コンテキスト維持情報提供をするか否か
－ＬｏｃａｌＤＮ情報を端末に公知するか否か
－ＬｏｃａｌＤＮバインディング情報制御情報（例えば、ＬｏｃａｌＤＮにバインディングされたＬ４コンテキスト削除又は維持、又はＤＮＳキャッシュ情報削除をするか否か）

ＳｏｕｒｃｅＥＥＳ８９７は、遅延公知を受信した以後に手順８２３～手順８２４のようにＡｐｐｌｉｃａｔｉｏｎＣｏｎｔｅｘｔ送信を行うことができる。ＳｏｕｒｃｅＥＥＳ８９７は、手順８１４－２において端末１０のＥＥＣ（ＥｄｇｅＥｎａｂｌｅｒＣｌｉｅｎｔ）にＣｏｎｔｅｘｔＲｅｌｏｃａｔｉｏｎＲｅｓｐｏｎｓｅ情報を伝達することができる。

その後にＳｏｕｒｃｅＥＥＳ８９７は、手順８１５－１においてＡｐｐＲｅｌｏｃａｔｉｏｎＩｎｆｏに次のような情報のうち少なくとも一つを含んでＳＭＦ１３０に応答する。

－ＡｐｐＲｅｌｏｃａｔｉｏｎの成功的な実行ができるか否か
－ＴａｒｇｅｔＤＮＡＩ
－端末の加入者情報（ＧＰＳＩなど）

ＳＭＦ１３０は、遅延公知に対する応答を受信することができる。

手順８１６においてＳＭＦ１３０は、Ｎ４セッションに対する更新手順を行う。

手順８１７においてＳＭＦ１３０は、手順８０５において決定したとおりＰＤＵセッション更新メッセージをＡＭＦ１２０を介して端末１０に伝達することができる。ＰＤＵセッション更新メッセージには、第１実施例で記述したように、ｌｏｃａｌＤＮ情報と上位階層ネットワークコンテキスト制御情報を含んで端末１０に伝達することができる。

手順８１８においてＩＰｖ６ｍｕｌｔｉｈｏｍｉｎｇである場合、ＳＭＦ１３０はＰＳＡ２８９４で使用される新しいＩＰｖ６ｐｒｅｆｉｘを割り当て、端末１０に送信することができる。

手順８１９においてＩＰｖ６ｍｕｌｔｉｈｏｍｉｎｇである場合、ＳＭＦ１３０はＰＳＡ０８９２に対する端末のＩＰｖ６に対する設定を再設定することができる。

手順８２０においてＳＭＦ１３０は、既存に端末１０に接続したｌｏｃａｌＰＳＡ－ＵＰＦ１８０３に対するＮ４セッションをリリースすることができる。

＜第５実施例＞
第５実施例は、ＳＭＦ１３０からＡＭＦ１２０を介して端末１０に伝達したｌｏｃａｌＤＮ情報と上位階層ネットワークコンテキスト制御情報が、端末でどのように使用されたかについて定義する。

図９ａ及び図９ｂは、本発明の一実施例によって端末にｌｏｃａｌＤＮ情報と上位階層ネットワークコンテキスト制御情報を提供する手順及び端末における動作を説明するための例示図である。

図９ａ及び図９ｂを説明するに先立ち、図８の構成と同様な要素に対しては図８で使った参照符号を使うことにする。

手順９０１で端末１０は、ＳＭＦ１３０に新しいＰＤＵセッションの生成を要請することができる。ＳＭＦ１３０は、ＰＳＡ－ＵＰＦ０８９２を選択し、ＰＳＡ－ＵＰＦ０８９２とＲＡＮ２０とのトンネルを生成し、端末１０にＰＤＵセッション生成要請に対する許可メッセージを送信することができる。図５で説明したとおり、端末１０が新しいＰＤＵを生成したので、新しいＰＤＵセッションに相応するネットワークインターフェースを生成し、これらをマッピングすることができる。すなわち、端末１０内のＣＰ１０１０とＡＰ１０３０の間に新しいＰＤＵセッションに相応するネットワークインターフェースを生成し、新しいネットワークインターフェースと設定されたＰＤＵセッションの間をマッピングすることができる。また、これらのマッピングに該当するアプリケーションが共にマッピングされることができる。

手順９０２において端末１０は、ＰＳＡ－ＵＰＦ０８０２に接続されているＣｅｎｔｒａｌＤＮにあるサーバーとＴＣＰ接続を生成することができる。端末１０の上位階層にはＴＣＰコンテキストが生成されることができる。図９には参照符号（Ａ）で表示した。

手順９０３において前述した多様な実施例にしたがって、ＳＭＦ１３０は、ＬｏｃａｌＰＳＡ－ＵＰＦとＵＬＣＬ／ＢＰの追加を決定することができ、ＬｏｃａｌＰＳＡ－ＵＰＦ１８９３を選択し、ＵＬＣＬ／ＢＰ８８１にｌｏｃａｌＰＳＡ－ＵＰＦへ向かうトラフィックに対する３－Ｔｕｐｌｅ（目的地ＩＰアドレス、目的地Ｐｏｒｔ番号、そしてプロトコル番号）を含む情報をＵＬＣＬ／ＢＰ８９１に伝達することができる。ＳＭＦ１３０は、端末１０にｌｏｃａｌＤＮに関する情報を端末１０に伝達することができる。これを受信した端末１０は、ｌｏｃａｌＤＮに関する情報を格納することができる。詳細なｌｏｃａｌＤＮ情報は、前述した第１実施例で説明したので、ここでは説明を省略する。これに含まれた情報は、ｌｏｃａｌＤＮの識別子、ｓｕｂｎｅｔアドレス、ｌｏｃａｌＤＮＳアドレス、ｌｏｃａｌＤＮＳ内のＥＡＳアドレス、ＳＭＦがＵＬＣＬに送信した３－ｔｕｐｌｅアドレスなどを含むことができる。

手順９０４において端末１０は、応用階層の要請によってＥＡＳ＃１ＦＱＤＮに対するＤＮＳＱｕｅｒｙ手順を行うことができる。ＤＮＳＱｕｅｒｙ手順は、ＬｏｃａｌＤＮ１に位置したｌｏｃａｌＤＮＳサーバーで質問することもでき、ＣｅｎｔｒａｌＤＮにあるＤＮＳサーバーにＤＮＳ質問することもできる。これにより、端末１０は、ＥＡＳ＃１に対するＩＰアドレスを知ることになり、これはｌｏｃａｌＤＮ＃１が位置する。

手順９０５において端末１０は、ＤＮＳＱｕｅｒｙ手順を介して知るようになったＥＡＳ＃１の目的地ＩＰアドレスにＴＣＰ接続を要請してＴＣＰ接続を生成することができる。このように生成されたＴＣＰ接続は、図９では参照符号（Ｂ）で表示した。

手順９０６においてＳＭＦ１３０は、端末１０が移動し、ＤＮＡＩが変更を感知するか、ＡＦ要請によるトラフィックステアリング施行制御情報を含むＰＣＣルールを受信した場合、ＳＭＦ１３０はｌｏｃａｌ－ＰＳＡ移動を決定することができ、ｌｏｃａｌＰＳＡ－ＵＰＦを変更する手順を行うことができる。この過程においてＳＭＦ１３０は、端末１０に新しく二回目のｌｏｃａｌＤＮが追加されたことを知らせるｌｏｃａｌＤＮ追加公知を端末１０に伝達することができる。これとともに、ＳＭＦ１３０は、端末１０に以前に接続を提供した一番目のｌｏｃａｌＤＮ１が削除されたことを公知することができる。この時、一番目のｌｏｃａｌＤＮ１が除去されたという情報と共にｌｏｃａｌＤＮ１に関する上位コンテキスト制御情報を共に伝達することができる。上位コンテキスト制御情報には、ｌｏｃａｌＤＮ２の上位階層コンテキストリフレッシュ指示者が含まれていることができる。上位階層ネットワークコンテキスト制御情報にｌｏｃａｌＤＮ２に相応するコンテキスト情報リフレッシュ情報が含まれている場合、端末１０はｌｏｃａｌＤＮ２に相応する上位階層コンテキスト情報を除去することができる。例えば、前述した手順９０４において生成したＬｏｃａｌＤＮ１のＥＡＳ１に接続していたＴＣＰコンテキストを解除することができる。これとともに、上位階層制御情報にＤＮＳキャッシュリフレッシュ情報が共に含まれている。ＤＮＳキャッシュリフレッシュ指示者は、ＬｏｃａｌＤＮで提供するＦＱＤＮのドメイン名又はＬｏｃａｌＤＮ１のＩＰｓｕｂｎｅｔアドレスが共に含まれていることができる。このように含まれた情報を上位階層、すなわち、端末内のＡＰ１０３０が受信すると、要請に含まれたＳｕｂｎｅｔアドレスに関するＤＮＳキャッシュ情報を消すことができる。もしくは、ＴａｒｇｅｔＦＱＤＮ又はドメイン名の情報に該当するＤＮＳキャッシュ情報を消すことができる。

手順９０７においてアプリケーションは、ＥＡＳ＃１とのＴＣＰ接続が切れたという事実を知り、ＥＡＳ＃１と再び接続することを試みることができる。この時、該当するＤＮＳキャッシュ情報が削除されたので、新規でＤＮＳサーバーにＥＡＳ＃１ＦＱＤＮに関するアドレス情報を要請して受信することができる。

手順９０８においてアプリケーションの要請によりＥＡＳ＃１がＬｏｃａｌＤＮ２に存在する場合、ＬｏｃａｌＰＳＡ－ＵＰＦ２８９４を経てＬｏｃａｌＤＮ２にＴＣＰセッションを生成することができる。

手順９０９において端末１０がＤＮＡＩ－Ｂローカルを離脱するか、又はＡＦ要請を受信してＳＭＦ１３０がＬｏｃａｌＰＳＡ－ＵＰＦ２８９４に対する除去を行うことができる。ＳＭＦ１３０は、ＰＣＣルールから端末１０に、ｌｏｃａｌＤＮに関する情報を変更すべきであるというポリシーの決定又はＳＭＦ１３０自体の決定により、端末にＤＮＡＩ－Ｂに関してＬｏｃａｌＤＮ情報を伝達することができる。端末１０に送る情報は、ＬｏｃａｌＤＮの除去に関する情報であり、これと共にＬｏｃａｌＤＮ除去時に上位階層ネットワークコンテキスト制御情報を共に伝達することができる。上位階層ネットワークコンテキスト制御情報は、ＬｏｃａｌＤＮ２に対する上位階層ネットワークコンテキストリフレッシュ及びＤＮＳケシュィ削除要請が含まれることができる。このような要請を受信した端末のＡＰは、ＴＣＰコンテキストを除去してＤＮＳキャッシュを削除する。

一方、以上で説明された第１実施例～第５実施例は、独立的にそれぞれ行われることができるが、２つ以上の実施例が共に動作することもできる。例えば、第１実施例の場合、ＢＰ／ＵＬＣＬ及びｌｏｃａｌＰＳＡ－ＵＰＦの追加を説明しており、第２実施例の場合、ＤＮＡＩ変更を感知し、ｌｏｃａｌＰＳＡの除去を説明しており、第３実施例の場合、事業者ポリシーに基づいてｌｏｃａｌＤＮ公知及び上位階層ネットワークコンテキスト制御情報を端末に伝達する方法を説明しており、第４実施例の場合、ＡＦの要請に基づいてｌｏｃａｌＰＳＡを変更する手順中に端末にｌｏｃａｌＤＮ情報と上位階層ネットワークコンテキスト情報を伝達する手順を説明しており、第５実施例の場合、端末に伝達されたｌｏｃａｌＤＮ情報と上位階層ネットワークコンテキスト制御情報が端末でどのように使用されるかについて説明している。

したがって、第１実施例によって第５実施例が共に使われることができ、第２実施例によって第５実施例が共に使われることもできる。また、第１実施例によって一つのｌｏｃａｌＰＳＡ－ＵＰＦが追加されるので、他のｌｏｃａｌＰＳＡが除去される場合、第２実施例が共に使われることができる。また、第１実施例と第２実施例によって第５実施例が共に使われることもできる。

また、第３実施例が適用された後に第１実施例が適用される場合、又は第１実施例が適用された後に第３実施例が適用される場合のように、第１実施例と第３実施例が順次に行われることもできる。

また、他の例として第１実施例が第４実施例に基づいて行われる場合、第２実施例が共に行われることができるので、第５実施例が行われることもある。

このように、互いに異なる実施例が共に使われる場合、一部重なる動作は特定の実施例で省略されることができ、全て行われることもできる。

図１０は、本発明によるネットワーク機能（ＮＦ）装置のブロック構成図である。
図１０を参照すれば、ＮＦ装置は送受信部１１０１、制御部１１０２、及びメモリー１１０３を含むことができる。ＮＦ装置は、以上で説明されたＲＡＮ、ＡＭＦ、ＵＰＦ、ＳＭＦ、ＵＤＭ、ＰＣＦ、ＡＵＳＦ、ＡＦ、ＤＮに属する特定のＡＦなどになることができる。

送受信部１１０１は、他のネットワークエンティティーと通信するためのインターフェースを提供することができる。例えば、ＮＦがＡＭＦ１２０である場合、送受信部１１０１は、ＲＡＮ２０、ＡＵＳＦ１６０、ＳＭＦ１３０、ＰＣＦ１４０、及び他のＡＭＦと信号／メッセージ／情報の送信及び受信を行うことができる。また、ＮＦがＳＭＦ１３０である場合、送受信部１１０１は、ＡＭＦ１２０、ＵＤＭ１７０、ＵＰＦ１１０及びＰＣＦ１４０と信号／メッセージ／情報の送信及び受信を行うことができる。

制御部１１０２は、以上で説明した各ＮＦの動作の制御を行うことができる。例えば、図６～図９において説明した各ＮＦの動作に対する制御を行うことができる。制御部１１０２は一つ又は二つ以上のプロセッサで具現することができる。

メモリー１１０３は、該当するＮＦで必要なデータを格納することができ、説明した各種メッセージ／信号に含まれた情報を格納することができる。

上述では、発明の理解を助けるために具体的な例を説明した。しかし、本発明はこれに限定されず、上記に開示した内容に基づいて多様な形態に変更されることができる。

無線通信システムで端末のＰＤＵセッションの追加／変更／削除を行う場合に適用することができる。

１０ユーザ装置
２０（無線）アクセスネットワーク（（Ｒ）ＡＮ）
１１０ユーザ平面機能装置
１２０アクセス及び移動性管理機能装置
１３０セッション管理機能装置（ＳＭＦ）
１４０ポリシー制御機能装置
１５０アプリケーション機能装置
１６０認証サーバー機能装置
１７０データ管理装置
１８０データネットワーク
１９０ＮＥＦ
２１０第１のＵＰＦ
２２０第２のＵＰＦ
２３０第３のＵＰＦ
２４０ＤＮ
２４１エッジアプリケーションサーバー（ＥＡＳ）
３１０ＵＰＦ
３２０ＤＮ
３２１ＥＡ
４０１、４０２、６０１、８９１ＵＬＣＬ／ＢＰ
４１０第１のデータネットワーク
４１１ＰＳＡ－ＵＰＦ＃１
４１３ＥＡＳ＃
４２０二番目のローカルデータネットワーク
４２１ＰＳＡ－ＵＰＦ＃２
４２３ＥＡＳ＃１
５００５Ｇコア網
５０１ＰＳＡ－ＵＰＦ
５０４ＵＤＲ
５１０、５１４、５１５データネットワーク
５１１、５１２エッジアプリケーションサーバー
５１３ドメインネームサーバー
５２１、５２２、５２３ＰＤＵセッション
５４１ＬｏｃａｌＤＮ
５４２ＣｅｎｔｒａｌＤＮ
５５１ＬｏｃａｌＤＮ
５５２ＥＡＳ＃１
５５３ＡＳ＃１
６０２ＰＳＡ１
６０３ＰＳＡ２
７９１ＰＳＡ－ＵＰＦ
７９２ＰＳＡ２
７９３ＵＬＣＬ／ＢＰＵＰＦ
８９２ＰＳＡ０
８９３ｌｏｃａｌＰＳＡ－ＵＰＦ１
８９４ＰＳＡ２
８９５ＰＣＦ、ＮＥＦ
８９７ＡＦ
１０１０モデム
１０１１ＮＡＳ制御平面
１０２０ＴＣＰ／ＩＰスタック
１０２１、１０２２第４の階層コンテキスト
１０２３ＤＮＳクライアント
１０２４コンテキストマネージャ
１０２５インターフェースマネージャ
１０３０アプリケーションプロセッサ
１０３１、１０３２、１０３３ネットワークインターフェース
１０３４アプリケーション１
１０３５アプリケーション２
１０４１ソケットインターフェース
１１０１送受信部
１１０２制御部
１１０３メモリー

端末１０が新しいＵＰＦであるＵＬＣＬ／ＢＰ４０２を介し、新しいＰＳＡ－ＵＰＦ＃２４２１を介して接続する場合が発生することができる。この場合には、端末１０がＤＮＡＩ変更前には一番目のローカルデータネットワーク４１０に接続しており、端末１０のアプリがＥＡＳ＃１４１３に接続されているので、端末１０はＴＣＰコンテキストを生成することができる。また、前述したように、端末１０が移動によってＤＮＡＩが変更された場合、ＳＭＦ（図４に図示せず）が付加的な（Ａｄｄｉｔｉｏｎａｌ）ＰＳＡ追加手順を行うことができる。端末１０のアプリがＤＮＡＩ変更後には、二番目のローカルデータネットワーク４２０のＥＡＳ＃１４２３のＩＰアドレス、例えば「１０．１０．２０．１」に接続されなければならない。しかし、端末１０のＴＣＰコンテキストが維持されており、端末１０のアプリはローカルネットワークの変更を知らず、既存のＴＣＰコンテキストが続いて維持されているので、二番目のローカルデータネットワーク４２０のＥＡＳ＃１４２３と接続されない。

これをさらに詳しく説明すると、次のとおりである。
図４のネットワーク構成図において端末１０は、一番目のｌｏｃａｌＤＮ４１０が位置したところから二番目のｌｏｃａｌＤＮ４２０に接続するところに移動することができる。この場合、図４に例示したとおり、端末１０の一番目のＰＳＡ－ＵＰＦ４１１は変更されないこともある。すなわち、端末１０は、ＰＳＡ－ＵＰＦ＃１４１１を維持することができる。この場合、端末１０のＩＰアドレスは維持されるが、端末１０が一番目のｌｏｃａｌＰＳＡ－ＵＰＦ＃１４１１を介して接続される応用階層セッションは、一番目のｌｏｃａｌＤＮ４１０に対するＰＳＡ－ＵＰＦ４１１が解除される場合、端末１０のコンテキストは除去されなければならない。しかし、現在のＵＬＣＬ又はｌｏｃａｌＰＳＡ－ＵＰＦ削除動作では、端末１０にこれを知らせる情報が存在しない。この場合、端末１０が二番目のｌｏｃａｌＤＮ４２０に接続して同一のＥＡＳに接続しようと試みる場合、一番目のｌｏｃａｌＤＮ４１０に対する上位階層コンテキストが端末１０に残ることになる。したがって、端末１０は二番目のｌｏｃａｌＤＮ４２０のＥＡＳに接続できなくなる。これをさらに例を挙げて検討すると、このような上位階層コンテキストは、ＥＡＳの正規化されたドメイン名（ｆｕｌｌｙｑｕａｌｉｆｉｅｄｄｏｍａｉｎｎａｍｅ、ＦＱＤＮ）に対するドメインネームサーバー（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍｏｒＤｏｍａｉｎＮａｍｅｓｅｒｖｅｒ、ＤＮＳ）の情報になることができる。一番目のｌｏｃａｌＤＮから受信したＥＡＳのＤＮＳアドレスは、例えば、「１０．１０．１０．１」であり得る。このようなＤＮＳ手順は、ＤＮＳレコードのライフタイム分だけ端末１０のＤＮＳＣｌｉｅｎｔにおいてキャッシュされることができる。端末１０が移動又はＳＭＦ（図４に図示せず）の決定によって二番目のｌｏｃａｌＤＮに接続した場合にも、同一のＥＡＳ＃１のＤＮＳクエリーを行う場合、端末１０のＤＮＳｃｌｉｅｎｔにキャッシュされた情報によって「１０．１０．１０．１」のアドレスに接続を行うことになる。この場合、２番目のｌｏｃａｌＤＮにあるＥＡＳ＃１４２３にデータトラフィックの送受信が不可能である。

アプリケーションプロセッサ１０３０は、基本的に少なくとも一つのアプリケーションが駆動されることができる。図５ａでは、互いに異なる２つのアプリケーション１０３４、１０３５が駆動される場合を例示した。アプリケーションプロセッサ１０３０内には、動作システムカーネル内にＴＣＰ／ＩＰスタック（ＴＣＰ／ＩＰｓｔａｃｋｉｎＯＳＫｅｒｎｅｌ）１０２０を含むことができる。下記では、説明の便宜のために「ＴＣＰ／ＩＰスタック」と称することにする。ＴＣＰ／ＩＰスタック１０２０内には第４の階層コンテキスト１０２１、１０２２を含むことができる。第４の階層コンテキスト１０２１、１０２２は、例えば、ソケット（ｓｏｃｋｅｔ）になることができる。ソケット１０２１、１０２２は、ソケットアプリケーションインターフェース（ａｐｐｌｉｃａｔｉｏｎｉｎｔｅｒｆａｃｅ、ＡＰＩ）を介して対応するアプリケーション１０３１、１０３２に接続されることができる。

図５ｃでは、端末のアプリケーション１１０３４は、ＬｏｃａｌＤＮ５５１のＥＡＳ＃１５５２とＴＣＰ接続を有しており、ＨｉｇｈＬａｙｅｒＯＳ内のＬａｙｅｒ４Ｃｏｎｔｅｘｔ＃１１０２１が生成される。また、端末のアプリケーション２１０３５は、ＣｅｎｔｒａｌＤＮ５４２に位置するＡＳ＃１５５３に接続している。ＬｏｃａｌＤＮ５４１のＥＡＳ＃１５５２に接続している端末のＬａｙｅｒ４Ｃｏｎｔｅｘｔ１０２１は、ｌｏｃａｌＤＮバインディングコンテキストの一例になることができる。本発明の動作中に上位階層ネットワークコンテキスト情報は、ＬｏｃａｌＤＮバインディングコンテキストになることができる。特に、ｌｏｃａｌＤＮ５４１の公知によって上位階層ネットワークコンテキストを制御する動作は、ｌｏｃａｌＤＮバインディングコンテキストを制御する動作に該当すると言え、ＬｏｃａｌＤＮバインディングコンテキスト動作は、例えば、図５ｃで図示したＬａｙｅｒＣｏｎｔｅｘｔ＃１の除去又は維持、又はＬｏｃａｌＤＮ５４１のために設定されたＤＮＳ５５１サーバーから受信したＤＮＳキャッシュ情報をリフレッシュする動作を含むことができる。

手順７０６においてＳＭＦ１３０は、端末が提供したＳＳＣサポートをするか否か、ＰＣＦ１３０から受信したＡＦ要請トラフィックステアリング施行制御をサポート可能な一番目のＰＳＡ－ＵＰＦ７９１を選択することができる。

手順７１６においてＳＭＦ１３０は、ダウンリンクトラフィックのためにＰＳＡ１のＮ４セッションを変更することができる。すなわち、ＲＡＮ２０に向かったトンネル情報を手順７１５において生成したＵＬＣＬ／ＢＰＵＰＦ７９３のトンネル情報に更新することができる。その後、ＰＳＡ１７９１からのダウンリンクトラフィックはＵＬＣＬ／ＢＰ７９３に向かうことになる。

手順８０４で端末１０が現在の登録領域の離脱を感知した場合、端末１０は登録要請メッセージをＲＡＮ２０を介してＡＭＦ１２０に伝達することができる。もしくは、端末１０が基地局のコマンドによって他の基地局にハンドオーバーを行った場合に、ハンドオーバー過程においてＡＭＦ１２０は基地局からハンドオーバー発生を感知することができる。もしくは、端末１０が遊休状態（ＣＭ－ＩＤＬＥ；ＣｏｎｎｅｃｔｉｏｎＭａｎａｇｅｍｅｎｔＩＤＬＥ状態）でサービス要請を伝達する場合、ＡＭＦ１２０は端末１０が移動したことを感知することができる。ＡＭＦ１２０は、ＰＤＵＳｅｓｓｉｏｎを更新するためのＰＤＵＳｅｓｓｓｉｏｎ＿Ｕｐｄａｔｅ＿ＳＭＣｏｎｔｅｘｔ要請に端末１０の位置情報を含んでＳＭＦ１３０に伝達することができる。

手順８２０においてＳＭＦ１３０は、既存に端末１０に接続したｌｏｃａｌＰＳＡ－ＵＰＦ１８９３に対するＮ４セッションをリリースすることができる。

Claims

無線通信システムのセッション管理機能（ＳｅｓｓｉｏｎＭａｎａｇｅｍｅｎｔＦｕｎｃｔｉｏｎ、ＳＭＦ）装置で端末にローカルデータネットワーク情報を提供するための方法において、
前記端末の移動性により第１情報に基づいてプロトコルデータユニット（ｐｒｏｔｏｃｏｌｄａｔａｕｎｉｔ、ＰＤＵ）セッションに対するＰＤＵセッションアンカー－ユーザ平面（ＰＤＵＳｅｓｓｉｏｎＡｎｃｈｏｒ－ＵｓｅｒＰｌａｎｅＦｕｎｃｔｉｏｎ、ＰＳＡ－ＵＰＦ）の追加を決定する段階と、
前記追加が決定されたＰＳＡ－ＵＰＦとＰＤＵセッションを形成する段階と、
前記ＰＳＡ－ＵＰＦと前記端末間のダウンリンク及びアップリンクに対するＰＤＵ経路を設定する段階と、
前記端末に新しいＰＳＡ－ＵＰＦの追加を指示するＰＤＵセッション変更コマンド（ＰＤＵＳｅｓｓｉｏｎＭｏｄｉｆｉｃａｔｉｏｎＣｏｍｍａｎｄ）を送信する段階と、を含み、
前記第１情報は、
ポリシー及び課金制御（ＰｏｌｉｃｙａｎｄＣｈａｒｇｉｎｇＣｏｎｔｒｏｌ、ＰＣＣ）情報、ポリシー制御機能（ｐｏｌｉｃｙｃｏｎｔｒｏｌｆｕｎｃｔｉｏｎ、ＰＣＦ）装置から受信されたローカル（ｌｏｃａｌ）データネットワーク（ｄａｔａｎｅｔｗｏｒｋ、ＤＮ）構成情報のうち少なくとも一つを含む、ことを特徴とする無線通信システムのＳＭＦで端末にローカルデータネットワーク情報を提供するための方法。
前記ローカルＤＮ構成情報は、
ドメインネームサーバー（ＤｏｍａｉｎＮａｍｅＳｅｒｖｅｒ、ＤＮＳ）が動作するドメイン名、ローカルＤＮのインターネットプロトコル（ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌ、ＩＰ）アドレス範囲を含む、ことを特徴とする無線通信システムのＳＭＦで端末にローカルデータネットワーク情報を提供するための請求項１に記載の方法。
前記第１情報は、
ローカルＤＮ公知制御情報、前記端末の上位階層コンテキスト制御情報をさらに含む、ことを特徴とする無線通信システムのＳＭＦで端末にローカルデータネットワーク情報を提供するための請求項１に記載の方法。
前記ローカルＤＮ構成情報は、
前記ＳＭＦに自体的に設定されている、ことを特徴とする無線通信システムのＳＭＦで端末にローカルデータネットワーク情報を提供するための請求項１に記載の方法。
前記ローカルＤＮ構成情報は、
３－Ｔｕｐｌｅ情報、ドメインネームサーバー（ＤｏｍａｉｎＮａｍｅＳｅｒｖｅｒ、ＤＮＳ）アドレス、ローカルＤＮのサブネット（ｓｕｂｎｅｔ）アドレスを含む、ことを特徴とする無線通信システムのＳＭＦで端末にローカルデータネットワーク情報を提供するための請求項１に記載の方法。
前記ＰＤＵセッション変更コマンドと共に第２情報をさらに送信し、
前記第２情報は、
追加された３－Ｔｕｐｌｅ目録、追加されたＳｕｂｎｅｔアドレス、既存のＤＮＳＲｅｆｒｅｓｈ指示者のうち少なくとも一つを含む、ことを特徴とする無線通信システムのＳＭＦで端末にローカルデータネットワーク情報を提供するための請求項１に記載の方法。
無線通信システムの端末でセッション管理機能（ＳＭＦ）装置からローカルデータネットワーク情報の受信方法において、
前記端末に設定されたプロトコルデータユニット（ｐｒｏｔｏｃｏｌｄａｔａｕｎｉｔ、ＰＤＵ）セッションを用いてＰＤＵを送／受信する段階と、
セッション管理機能（ＳｅｓｓｉｏｎＭａｎａｇｅｍｅｎｔＦｕｎｃｔｉｏｎ、ＳＭＦ）装置から新しいＰＤＵセッションアンカー－ユーザ平面（ＰＤＵＳｅｓｓｉｏｎＡｎｃｈｏｒ－ＵｓｅｒＰｌａｎｅＦｕｎｃｔｉｏｎ、ＰＳＡ－ＵＰＦ）の追加を指示するＰＤＵセッション変更コマンド（ＰＤＵＳｅｓｓｉｏｎＭｏｄｉｆｉｃａｔｉｏｎＣｏｍｍａｎｄ）を受信する段階と、
前記新しいＰＳＡ－ＵＰＦを介して前記ＳＭＦが送信したルータ広告（ＲｏｕｔｅｒＡｄｖｅｒｔｉｓｅｍｅｎｔ、ＲＡ）メッセージを受信する段階と、
前記新しいＰＳＡ－ＵＰＦを再構成（ｒｅ－ｃｏｎｆｉｇｕｒｅ）する段階と、
前記新しいＰＳＡ－ＵＰＦの再構成に基づいて上位階層制御を行う段階と、を含む、ことを特徴とする無線通信システムの端末でローカルデータネットワーク情報を受信するための方法。
前記上位階層制御は、
上位階層コンテキストリトレイン（ｒｅｔｒａｉｎ）又は上位階層リフレッシュ（ｒｅｆｒｅｓｈ）のうち一つである、ことを特徴とする無線通信システムの端末でローカルデータネットワーク情報を受信するための請求項７に記載の方法。
無線通信システムの端末にローカルデータネットワーク情報を提供するためのセッション管理機能（ＳｅｓｓｉｏｎＭａｎａｇｅｍｅｎｔＦｕｎｃｔｉｏｎ、ＳＭＦ）装置において、
他のネットワークエンティティーと通信する送受信部と、
構成情報を格納するように構成されたメモリーと、
少なくとも一つのプロセッサと、を含み、
前記プロセッサは、
前記端末の移動性によって第１情報に基づいてＰＤＵセッションに対するＰＤＵセッションアンカー－ユーザ平面（ＰＤＵＳｅｓｓｉｏｎＡｎｃｈｏｒ－ＵｓｅｒＰｌａｎｅＦｕｎｃｔｉｏｎ、ＰＳＡ－ＵＰＦ）の追加を決定し、
前記送受信部を用いて前記追加が決定されたＰＳＡ－ＵＰＦとＰＤＵセッションの形成を制御し、
前記送受信部を用いて前記ＰＳＡ－ＵＰＦと前記端末間のダウンリンク及びアップリンクに対するＰＤＵ経路設定を制御し、
前記送受信部を介して前記端末に新しいＰＳＡ－ＵＰＦの追加を指示するＰＤＵセッション変更コマンド（ＰＤＵＳｅｓｓｉｏｎＭｏｄｉｆｉｃａｔｉｏｎＣｏｍｍａｎｄ）を送信するように制御し、
前記第１情報は、
ポリシー及び課金制御（ＰｏｌｉｃｙａｎｄＣｈａｒｇｉｎｇＣｏｎｔｒｏｌ、ＰＣＣ）情報、ポリシー制御機能（ｐｏｌｉｃｙｃｏｎｔｒｏｌｆｕｎｃｔｉｏｎ、ＰＣＦ）装置から受信されたローカル（ｌｏｃａｌ）データネットワーク（ｄａｔａｎｅｔｗｏｒｋ、ＤＮ）構成情報のうち少なくとも一つを含む、無線通信システムの端末にローカルデータネットワーク情報を提供する、ことを特徴とするＳＭＦ装置。
前記ローカルＤＮ構成情報は、
ドメインネームサーバー（ＤｏｍａｉｎＮａｍｅＳｅｒｖｅｒ、ＤＮＳ）が動作するドメイン名、ローカルＤＮのインターネットプロトコル（ｉｎｔｅｒｎｅｔｐｒｏｔｏｃｏｌ、ＩＰ）アドレス範囲を含む、無線通信システムの端末にローカルデータネットワーク情報を提供する、ことを特徴とする請求項９に記載のＳＭＦ装置。
前記第１情報は、
ローカルＤＮ公知制御情報、前記端末の上位階層コンテキスト制御情報をさらに含む、無線通信システムの端末にローカルデータネットワーク情報を提供する、ことを特徴とする請求項９に記載のＳＭＦ装置。
前記ローカルＤＮ構成情報は、
前記ＳＭＦに自体的に設定されている、無線通信システムの端末にローカルデータネットワーク情報を提供する、ことを特徴とする請求項９に記載のＳＭＦ装置。
前記ローカルＤＮ構成情報は、
３－Ｔｕｐｌｅ情報、ドメインネームサーバー（ＤｏｍａｉｎＮａｍｅＳｅｒｖｅｒ、ＤＮＳ）アドレス、ローカルＤＮのサブネット（ｓｕｂｎｅｔ）アドレスを含む、無線通信システムの端末にローカルデータネットワーク情報を提供する、ことを特徴とする請求項９に記載のＳＭＦ装置。
前記ＰＤＵセッション変更コマンドと共に第２情報をさらに送信し、
前記第２情報は、
追加された３－Ｔｕｐｌｅ目録、追加されたＳｕｂｎｅｔアドレス、既存のＤＮＳＲｅｆｒｅｓｈ指示者のうち少なくとも一つを含む、無線通信システムの端末にローカルデータネットワーク情報を提供する、ことを特徴とする請求項９に記載のＳＭＦ装置。