特許 7541052 無線通信システムでサービスをフレキシブルに提供する方法及び装置

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

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

(11)【特許番号】

(24)【登録日】2024-08-19

(45)【発行日】2024-08-27

(54)【発明の名称】無線通信システムでサービスをフレキシブルに提供する方法及び装置

(51)【国際特許分類】

   H04W 76/22 20180101AFI20240820BHJP

   H04W 80/10 20090101ALI20240820BHJP

   H04W 88/14 20090101ALI20240820BHJP

   H04W 92/24 20090101ALI20240820BHJP

【ＦＩ】

H04W76/22

H04W80/10

H04W88/14

H04W92/24

【請求項の数】 12

(21)【出願番号】P 2022081662

(22)【出願日】2022-05-18

(62)【分割の表示】P 2021556294の分割

【原出願日】2020-05-12

(65)【公開番号】P2022103356

(43)【公開日】2022-07-07

【審査請求日】2023-05-10

(31)【優先権主張番号】10-2019-0055889

(32)【優先日】2019-05-13

(33)【優先権主張国・地域又は機関】KR

(31)【優先権主張番号】10-2019-0066626

(32)【優先日】2019-06-05

(33)【優先権主張国・地域又は機関】KR

(31)【優先権主張番号】10-2019-0122217

(32)【優先日】2019-10-02

(33)【優先権主張国・地域又は機関】KR

(73)【特許権者】

【識別番号】503447036

【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100154922

【弁理士】

【氏名又は名称】崔 允辰

(72)【発明者】

【氏名】サンス・ジョン

(72)【発明者】

【氏名】ホヨン・イ

【審査官】齋藤 浩兵

(56)【参考文献】

【文献】米国特許第０９０７８２３６（ＵＳ，Ｂ２）

【文献】米国特許出願公開第２０１７／０２９００５２（ＵＳ，Ａ１）

【文献】国際公開第２０１８／１２７１９０（ＷＯ，Ａ１）

【文献】Ericsson，SMF context transfer[online]，3GPP TSG SA WG2 #133 S2- 1905060，2019年05月07日，Internet<URL:https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_133_Reno/Docs/S2-1905060.zip>

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

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

Ｈ０４Ｗ ４／００－９９／００

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

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

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

【請求項1】

通信システムのＡＭＦ（ａｃｃｅｓｓ ａｎｄ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）によって行われる方法であって、
ＳＭ（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ）コンテキスト（ｃｏｎｔｅｘｔ）を第２ＳＭＦ（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）に伝達することが必要であることを指示する情報を含む第１メッセージを第１ＳＭＦから受信する段階と、
前記第２ＳＭＦが前記第１ＳＭＦから前記ＳＭコンテキストを受信するようにリクエストする第２メッセージを前記第２ＳＭＦに送信する段階と、
前記第２メッセージの送信によってタイマーを開始する段階と、
前記タイマーの満了前に、前記第２メッセージの応答として第３メッセージを前記第２ＳＭＦから受信する段階と、を含み、
前記第３メッセージの受信前に、端末の移動によるＵＥ（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）コンテキスト伝達リクエストを他のＡＭＦから受信する段階と、
前記第３メッセージを受信するまで前記第２ＳＭＦとの前記ＵＥコンテキスト伝達リクエストの処理をディレーする段階と、をさらに含む方法。

【請求項2】

前記第３メッセージを受信する前に前記タイマーが満了した場合、ＳＭコンテキスト伝達手順は失敗したと判断する段階をさらに含むことを特徴とする、請求項１に記載の方法。

【請求項3】

前記第３メッセージは、コンテキスト生成手続が完了したことを指示することを特徴とする、請求項１に記載の方法。

【請求項4】

前記第３メッセージを受信する前に、前記ＳＭコンテキストと連関したＰＤＵ（ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）セッション（ｓｅｓｓｉｏｎ）の端末からサービスリクエストを受信する段階と、
前記第３メッセージを受信するまで前記第２ＳＭＦとの前記サービスリクエストの処理をディレーする段階と、をさらに含むことを特徴とする、請求項１に記載の方法。

【請求項5】

前記第１メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＳＭＣｏｎｔｅｘｔＳｔａｔｕｓＮｏｔｉｆｙメッセージを含み、前記第２メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔ ｒｅｑｕｅｓｔメッセージを含み、前記第３メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔ ｒｅｓｐｏｎｓｅメッセージを含むことを特徴とする、請求項１に記載の方法。

【請求項6】

前記第２メッセージを送信する段階は、
前記第１メッセージに基づいて前記第２ＳＭＦを選択する段階をさらに含むことを特徴とする、請求項１に記載の方法。

【請求項7】

通信システムのＡＭＦ（ａｃｃｅｓｓ ａｎｄ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）であって、
送受信部と、
ＳＭ（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ）コンテキスト（ｃｏｎｔｅｘｔ）を第２ＳＭＦ（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）に伝達することが必要であることを指示する情報を含む第１メッセージを第１ＳＭＦから前記送受信部を介して受信し、前記第２ＳＭＦが前記第１ＳＭＦから前記ＳＭコンテキストを受信するようにリクエストする第２メッセージを前記第２ＳＭＦに前記送受信部を介して送信し、前記第２メッセージの送信によってタイマーを開始し、前記タイマーの満了前に、前記第２メッセージの応答として第３メッセージを前記第２ＳＭＦから前記送受信部を介して受信する制御部と、を含み、
前記制御部は、
前記第３メッセージの受信前に、端末の移動によるＵＥ（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）コンテキスト伝達リクエストを他のＡＭＦから前記送受信部を介して受信し、前記第３メッセージを受信するまで前記第２ＳＭＦとの前記ＵＥコンテキスト伝達リクエストの処理をディレーするＡＭＦ。

【請求項8】

前記制御部は、
前記第３メッセージを受信する前に前記タイマーが満了した場合、ＳＭコンテキスト伝達手順は失敗したと判断することを特徴とする、請求項７に記載のＡＭＦ。

【請求項9】

前記制御部は、
前記第３メッセージは、コンテキスト生成手続が完了したことを指示することを特徴とする、請求項７に記載のＡＭＦ。

【請求項10】

前記制御部は、
前記第３メッセージを受信する前に、前記ＳＭコンテキストと連関したＰＤＵ（ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）セッション（ｓｅｓｓｉｏｎ）の端末からサービスリクエストを前記送受信部を介して受信し、前記第３メッセージを受信するまで前記第２ＳＭＦとの前記サービスリクエストの処理をディレーすることを特徴とする、請求項７に記載のＡＭＦ。

【請求項11】

前記第１メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＳＭＣｏｎｔｅｘｔＳｔａｔｕｓＮｏｔｉｆｙメッセージを含み、前記第２メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔ ｒｅｑｕｅｓｔ メッセージを含み、前記第３メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔ ｒｅｓｐｏｎｓｅメッセージを含むことを特徴とする、請求項７に記載のＡＭＦ。

【請求項12】

前記制御部は、
前記第１メッセージに基づいて前記第２ＳＭＦを選択することを特徴とする、請求項７に記載のＡＭＦ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、移動通信システムで端末の識別子及び状態情報（ｃｏｎｔｅｘｔ）を管理するための技術に関する。

【背景技術】

【0002】

４Ｇ(４ｔｈ ｇｅｎｅｒａｔｉｏｎ）通信システム商用化以後の増加趨勢にある無線データトラフィック需要を満たすために、改善された５Ｇ(５ｔｈ ｇｅｎｅｒａｔｉｏｎ)通信システム又はｐｒｅ－５Ｇ通信システムを開発するための努力が行われている。このような理由で、５Ｇ通信システム又はｐｒｅ－５Ｇ通信システムは４Ｇネットワーク以後(Ｂｅｙｏｎｄ ４Ｇ Ｎｅｔｗｏｒｋ)通信システム又はＬＴＥ(Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）システム以後(Ｐｏｓｔ ＬＴＥ)のシステムと呼ばれている。

【0003】

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

【0004】

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

【0005】

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

【0006】

５Ｇシステムでは既存の４Ｇシステム対比多様なサービスに対するサポートを考慮している。

【0007】

例えば、最も代表的なサービスはモバイル超広帯域通信サービス（ｅＭＢＢ：ｅｎｈａｎｃｅｄ ｍｏｂｉｌｅ ｂｒｏａｄ ｂａｎｄ）、超高信頼性／低遅延通信サービス（ＵＲＬＬＣ：ｕｌｔｒａ－ｒｅｌｉａｂｌｅ ａｎｄ ｌｏｗ ｌａｔｅｎｃｙ ｃｏｍｍｕｎｉｃａｔｉｏｎ）、大規模機器間の通信サービス（ｍＭＴＣ：ｍａｓｓｉｖｅ ｍａｃｈｉｎｅ ｔｙｐｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）、次世代放送サービス（ｅＭＢＭＳ：ｅｖｏｌｖｅｄ ｍｕｌｔｉｍｅｄｉａ ｂｒｏａｄｃａｓｔ／ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）などがあり得る。そして、前記ＵＲＬＬＣサービスを提供するシステムをＵＲＬＬＣシステム、ｅＭＢＢサービスを提供するシステムをｅＭＢＢシステムなどで称することができる。また、サービスとシステムという用語は混用して用いられる。

【0008】

この中、ＵＲＬＬＣサービスは既存の４Ｇシステムと異なり５Ｇシステムで新しく考慮しているサービスであり、他のサービス対比超高信頼性（例えば、パケットエラー率が約１０^－５）と低遅延（ｌａｔｅｎｃｙ）（例えば、約０．５ｍｓｅｃ）条件満足を要求する。このような厳格な要求条件を満足させるためにＵＲＬＬＣサービスはｅＭＢＢサービスより短い送信時間間隔（ＴＴＩ：ｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅ ｉｎｔｅｒｖａｌ）の適用が必要であり、これを活用した多様な操作方式が考慮されている。

【0009】

一方、インターネットは人間が情報を生成して消費する人間中心の接続網から、事物などの分散された構成要素の間に情報を取り交わして処理するＩｏＴ(Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ、モノのインターネット)網へ進化しつつある。クラウドサーバーなどとの接続を通じるビックデータ処理技術などがＩｏＴ技術に結合されたＩｏＥ(Ｉｎｔｅｒｎｅｔ ｏｆ Ｅｖｅｒｙｔｈｉｎｇ)技術も台頭されている。ＩｏＴを具現するために、センシング技術、有無線通信及びネットワークインフラ、サービスインターフェース技術、及び保安技術のような技術要素が要求され、最近には事物間の接続のためのセンサーネットワーク(ｓｅｎｓｏｒ ｎｅｔｗｏｒｋ)、マシンツーマシン(Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ、Ｍ２Ｍ)、ＭＴＣ(Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ)などの技術が研究されている。

【0010】

ＩｏＴ環境では接続された事物で生成されたデータを収集、分析して人間の生活に新しい価値を創出する知能型ＩＴ(Ｉｎｔｅｒｎｅｔ Ｔｅｃｈｎｏｌｏｇｙ)サービスが提供されることができる。ＩｏＴは既存のＩＴ(ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ)技術と多様な産業間のコンバージェンス及び複合を介してスマートホーム、スマートビルディング、スマートシティ、スマートカー又はコネクテッドカー、スマートグリッド、ヘルスケア、スマート家電、先端医療サービスなどの分野に応用されることができる。

【0011】

これに、５Ｇ通信システムをＩｏＴ網に適用するための多様な試みが行われている。例えば、センサーネットワーク(ｓｅｎｓｏｒ ｎｅｔｗｏｒｋ)、マシンツーマシン(Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ、Ｍ２Ｍ)、ＭＴＣ(Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ)などの技術が５Ｇ通信技術であるビームフォーミング、ＭＩＭＯ、及びアレイアンテナなどの技法によって具現されていることである。前述したビックデータ処理技術としてクラウド無線アクセスネットワーク(ｃｌｏｕｄ ＲＡＮ)が適用されることも５Ｇ技術とＩｏＴ技術コンバージェンスの一例と言えるだろう。

【0012】

上述した情報は本開示の理解を助けるために背景情報としてのみ提示される。上述した事項のうちのいずれかが本開示に係って先行技術として適用されるか否かについては、何の決定もされておらず、主張もされていない。

【発明の概要】

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

【0013】

本発明の一実施例では５Ｇシステムで通信の効率性の増大及び顧客サービス品質改善のためにＮＦ（ｎｅｔｗｏｒｋ ｆｕｎｃｔｉｏｎ）が処理するデータを分離して別に記憶する構造を提案する。さらに、本発明の一実施例ではこのような構造の導入時に発生することができるＮＦの間のＩＤ（識別子）衝突イシューを解決するためのＩＤ処理方法を提案する。

【0014】

本発明において達成しようとする技術的課題は、前記で言及した技術的課題に制限されず、言及しない他の技術的課題は以下の記載から本発明が属する技術分野で通常の知識を有する者に明確に理解されることができるだろう。

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

【0015】

本発明の一実施例による無線通信システムのＡＭＦ（ａｃｃｅｓｓ ａｎｄ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）エンティティーによって行われる方法が提供される。前記方法は、ＳＭ（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ）コンテキスト（ｃｏｎｔｅｘｔ）を第２ＳＭＦ（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）エンティティーに伝達するための第１メッセージを第１ＳＭＦエンティティーから受信する段階と、前記第２ＳＭＦエンティティーが前記第１ＳＭＦエンティティーから前記ＳＭコンテキストを受信するようにリクエストする第２メッセージを前記第２ＳＭＦエンティティーに送信する段階と、
前記第２メッセージの送信によってタイマーを開始する段階と、及び前記タイマーの満了の前に、前記第２メッセージの応答で第３メッセージを前記第２ＳＭＦエンティティーから受信する段階と、を含むことができる。

【0016】

一実施例によって、前記方法は前記第３メッセージを受信する前に前記タイマーが満了された場合、ＳＭコンテキスト伝達手順は失敗したことで判断する段階をさらに含むことができる。

【0017】

一実施例によって、前記第１メッセージは前記ＳＭコンテキストの伝達を指示する情報を含むことができる。

【0018】

一実施例によって、前記方法は前記第３メッセージの受信の前にサービスリクエストメッセージを端末から受信する段階と、及び前記第３メッセージを受信するまで前記ＳＭコンテキストと連関された動作をディレーする段階をさらに含むことができる。

【0019】

一実施例によって、前記方法は前記第３メッセージの受信の前にＵＥ（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）コンテキスト伝達リクエストメッセージを他のＡＭＦエンティティーから受信する段階と、及び前記第３メッセージを受信するまで前記ＳＭコンテキストと連関された動作をディレーする段階をさらに含むことができる。

【0020】

一実施例によって、前記第１メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＳＭＣｏｎｔｅｘｔＳｔａｔｕｓＮｏｔｉｆｙメッセージを含み、前記第２メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔ ｒｅｑｕｅｓｔメッセージを含み、前記第３メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔ ｒｅｓｐｏｎｓｅメッセージを含むことができる。

【0021】

一実施例によって、前記第２メッセージを送信する段階は、前記第１メッセージに基づいて前記第２ＳＭＦエンティティーを選択する段階をさらに含むことができる。

【0022】

本発明の一実施例にによる無線通信システムのＡＭＦ（ａｃｃｅｓｓ ａｎｄ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）がさらに提供される。前記ＡＭＦは送受信部と、及びＳＭ（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ）コンテキスト（ｃｏｎｔｅｘｔ）を第２ＳＭＦ（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）エンティティーに伝達するための第１メッセージを第１ＳＭＦエンティティーから前記送受信部を介して受信し、前記第２ＳＭＦエンティティーが前記第１ＳＭＦエンティティーから前記ＳＭコンテキストを受信するようにリクエストする第２メッセージを前記第２ＳＭＦエンティティーに前記送受信部を介して送信し、前記第２メッセージの送信によってタイマーを開始し、前記タイマーの満了の前に、前記第２メッセージの応答で第３メッセージを前記第２ＳＭＦエンティティーから前記送受信部を介して受信する制御部と、を含むことができる。

【発明の効果】

【0023】

本発明の一実施例を適用する場合、ＮＦの間に端末のコンテキストを共有することにより、処理量を自由に分配するか、障害が発生したＮＦが提供したサービスを他のＮＦが引き継いで顧客サービス品質低下無しにサポートすることができる。さらに、本発明の一実施例を適用する場合、互いコンテキストを共有するＮＦが用いるＩＤをシステム容量／性能、顧客サービス特性によって決定して管理するので、ＩＤの衝突によるサービス間のエラーや顧客サービス品質低下を防止することができる。

【0024】

本発明で得られる効果は以上で言及した効果に制限されず、言及しないその他の効果は以下の記載から本開示が属する技術分野で通常の知識を有する者に明確に理解されることができる。

【図面の簡単な説明】

【0025】

本開示及びその利点に対するより完全な理解のために、添付図面と共に取られる次の説明を参照し、図面で類似の参照番号は類似の部分を示す。

【0026】

【図1】本発明の一実施例によるＳＢＡ基盤の５Ｇシステム構造を示す図面である。

【図2】本発明の一実施例によるＮＦとコンテキストの分離構造を示す図面である。

【図3】本発明の一実施例による端末、基地局、コアを含む５Ｇシステムの動作の一例を示す図面である。

【図4】本発明の一実施例による５Ｇシステム（端末、基地局、ＮＦ）の動作の他の一例を示す図面である。

【図5】本発明の一実施例によって、動的に変動される５Ｇシステム構造でも効果的に臨時識別子を管理することができる例を示す図面である。

【図6】本発明のまた他の実施例によって毎度ｔｒａｎｓａｃｔｉｏｎを処理するたびに臨時識別子をリクエストして割り当てることではないＮＦ ｓｅｔで共有する識別子のｐｏｏｌをｃｈｕｎｋ単位で分け、ｃｈｕｎｋ単位で割り当て及び管理、収去する方案を示す図面である。

【図7】本発明の一実施例による特定ＮＦが割り当てられたＩＤに対する使用が終了されてこれを返る過程を示す図面である。

【図8】本発明の一実施例によってｃｏｎｔｅｘｔ ｓｔｏｒａｇｅやＮＦの間にコンテキストを交換してサービスを提供する場合、コンテキストを受信するＮＦの容量を考慮して対象となるＮＦを選択する方案を示す図面である。

【図9】本発明の一実施例によってＮＦでコンテキストを管理する方法を示す図面である。

【図10】本発明の一実施例によってコンテキスト送信及びＮＦ変更による誤動作、過負荷を防止するための方法を示す図面である。

【図11】本発明の一実施例によるＡＭＦの詳細動作を示す。

【図12】本発明の一実施例によるＡＭＦの詳細動作を示す。

【図13】本発明による端末の構成を示す図面である。

【図14】本発明によるネットワークエンティティー（ｎｅｔｗｏｒｋ ｅｎｔｉｔｙ）の構成を示す図面である。

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

【0027】

以下の詳細な説明を行う前に、この特許文書全体で用いられる特定単語及び句の定義を提示することができる。用語“包含”及び“構成”及びその派生語は制限無しに含むことを意味する。用語“又は”は“及び／又は”の意味を含み；句節“連関された”及び“それに係る”及びその派生語は包含、内部に含まれる、相互接続された、内部に含む、接続する又は接続された、カップル又は通信可能な、協力された、インタリーブ、併置、隣接、結合、所有又はそれと類似のことを含み；用語“コントローラー(制御部)”は少なくとも一つの動作を制御する任意の装置、システム又はその一部を意味し、このような装置はハードウェア、ファームウェア又はソフトウェア、又はこれらのうちの少なくとも２個の組み合せで具現されることができる。特定制御部に係る機能はローカル又は遠隔に関わらず中央集中化されたり分散されることができる。

【0028】

さらに、後述する多様な機能は一つ以上のコンピュータープログラムによって具現されたりサポートされることができ、これらの各々はコンピューター可読プログラムコードで形成され、コンピューター可読媒体に具現される。用語“アプリケーション”及び“プログラム”は一つ以上のコンピュータープログラム、ソフトウェアコンポネント、命令語セット、手続、機能、客体、クラス、インスタンス、関連データ又は適切なコンピューター可読プログラムで具現するように採択されたこの一部を意味する。 コンピューター可読プログラムコード”という文句にはソースコード、オブジェクトコード及び実行可能なコードを含むすべての類型のコンピューターコードが含まれる。“コンピューター可読媒体”という文句は、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、ＲＡＭ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ハードディスクドライブ、コンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、又はその他の類型のメモリーのようにコンピューターによってアクセスされることができるすべての類型の媒体を含む。“非一時的”コンピューター可読媒体は一時的な電気的な又はその他の信号を送信する有線、無線、光学又はその他の通信リンクを除く。非－一時的コンピューター可読媒体はデータが永久的に記憶される媒体、及び再記録が可能な光ディスク又は消去可能なメモリー装置のような、データが記憶されて後で上書きされる媒体を含む。

【0029】

特定単語及び句に対する定義は本特許文書全体にかけて提供され、通常の技術者は大部分の場合ではないがこのような定義がこのような定義された単語及び句の以前及び以後の使用に適用されるということを理解すべきである。

【0030】

以下で論議される図１乃至１４、及び本特許文書で本開示の原理を説明するために用いられた多様な実施例は例示のみのためのもので、本開示の範囲を制限する方式で解釈されてはいけない。当業者は本開示の原理が任意適切に配列されたシステム又は装置で具現されることができることを理解することであろう。

【0031】

以下、添付図面を参照し、本発明の動作原理を詳しく説明する。以下で、本開示を説明するに当り関連された公知機能又は構成に対する具体的な説明が本開示の要旨を不明瞭にすることができると決定される場合にはその詳細な説明は省略する。そして、後述される用語は本開示における機能を考慮して定義された用語として、これはユーザ、運用者の意図又は慣例などによって変わることができる。したがって、用語の定義は詳細な内容に基づいて定義されるべきである。

【0032】

以下、説明で用いられる接続ノード（ｎｏｄｅ）を識別するための用語、網客体（ｎｅｔｗｏｒｋ ｅｎｔｉｔｙ）又はＮＦ（ｎｅｔｗｏｒｋ ｆｕｎｃｔｉｏｎ）を指称する用語、メッセージを指称する用語、網客体の間のインターフェースを指称する用語、多様な識別情報を指称する用語などは説明の便宜のために例示されたことである。したがって、本発明が後述される用語に限定されるのではなく、同等な技術的意味を有する対象を指称する他の用語が用いられることができる。

【0033】

以下、説明の便宜のために、本発明は３ＧＰＰ（登録商標） ＬＴＥ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）及び５Ｇ規格で定義している用語及び名称を用いる。しかし、本発明が前記用語及び名称によって限定されることではなく、他の規格によるシステムにも同様に適用されることができる。

【0034】

一方、本発明の実施例を記述するに当り、ＮＦが処理／管理した端末の情報（ＵＥ ｃｏｎｔｅｘｔ）を別に分離して記憶し、検索する機能を有するノード／ＮＦをｃｏｎｔｅｘｔ ｓｔｏｒａｇｅと称し、これは構造化されていないｄａｔａを記憶／共有するＮＦであるＵＤＳＦ（ｕｎｓｔｒｕｃｔｕｒｅｄ ｄａｔａ ｓｔｏｒａｇｅ ｆｕｎｃｔｉｏｎ）及びコンテキストを記憶／送信するＮＦであるＣＴＳＦ（ｃｏｎｔｅｘｔ ｔｒａｎｓｆｅｒ ｓｔｏｒａｇｅ ｆｕｎｃｔｉｏｎ）を含む概念である。

【0035】

一方、本発明でサービス（ｓｅｒｖｉｃｅ）という用語は特定通信装備（又はＮＦ）が他の通信装備（又はＮＦ）のリクエストを行うこと、すなわち、ＮＦ ｓｅｒｖｉｃｅを指称するために用いられ、実際ユーザ（Ｅｎｄ－Ｕｓｅｒ）で伝達するサービスを特別に限定して指称する場合には顧客サービスという用語で区分して用いる。

【0036】

５Ｇの多様なサービスをサポートするために新しいシステム構造及びプロトコルが必要となり、３ＧＰＰ（登録商標）ではサービス基盤構造（ＳＢＡ：ｓｅｒｖｉｃｅ－ｂａｓｅｄ ａｒｃｈｉｔｅｃｔｕｒｅ）という新規技術を取り入れることに決定した。

【0037】

図１は、本発明の一実施例にによるＳＢＡ基盤の５Ｇシステム構造を示す図面である。

【0038】

図１を参考すれば、ＡＭＦ（ａｃｃｅｓｓ ａｎｄ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）１２０は端末（ＵＥ）１１０に対する無線網接続（ａｃｃｅｓｓ）及び移動性（ｍｏｂｉｌｉｔｙ）を管理するＮＦ（ｎｅｔｗｏｒｋ ｆｕｎｃｔｉｏｎ）である。ＳＭＦ（ｓｅｓｓｉｏｎ ｍａｎａｇｅｍｅｎｔ ｆｕｎｃｔｉｏｎ）１３０は端末１１０に対するセッション（ｓｅｓｓｉｏｎ）を管理するＮＦであり、セッション情報にはＱｏＳ情報、課金情報、パケット処理に対する情報を含む。ＵＰＦ（ｕｓｅｒ ｐｌａｎｅ ｆｕｎｃｔｉｏｎ）１２５はユーザトラフィック（ｕｓｅｒ ｐｌａｎｅ ｔｒａｆｆｉｃ）を処理するＮＦであり、ＳＭＦ１３０によって制御を受ける。図１には図示せずが、５ＧシステムにはＵＤＳＦが含まれることができ、ＵＤＳＦは構造化されない（ｕｎｓｔｒｕｃｔｕｒｅｄ）データを記憶するＮＦでどんな類型のデータもＮＦのリクエストに従って記憶（ｓｔｏｒｅ）するかリトリーブ （ｒｅｔｒｉｅｖｅ）することができる。

【0039】

図２は、本発明の一実施例にによるＮＦとコンテキストの分離構造を示す図面である。

【0040】

図２を参考すれば、本発明の実施例でＮＦ内部のデータ（ＵＥ ｃｏｎｔｅｘｔ）はＮＦから分離されて別途のｃｏｎｔｅｘｔ ｓｔｏｒａｇｅに記憶され、これを共有して用いることができるＮＦの集合をＮＦ ｓｅｔと称する。具現環境によって特定ＮＦはＮＦ ｉｎｓｔａｎｃｅという形態で操作／管理されることができ、本発明の主な要旨はＮＦ又はＮＦ ｉｎｓｔａｎｃｅのうちのどんな形態の運営管理環境でも適用されることができる。さらに、ＮＦ単位の具現／構築ではないＮＦサービス単位の動作時のＮＦはＮＦ ｓｅｒｖｉｃｅで取り替えられることができる。したがって、本発明のＮＦという用語はＮＦ ｉｎｓｔａｎｃｅ、ＮＦ ｓｅｒｖｉｃｅ、ＮＦ ｓｅｒｖｉｃｅ ｉｎｓｔａｎｃｅを含むことができる。もし、いくつかのＮＦ ｓｅｔが共存する場合、各ＮＦ ｅｔを区分するために互いに識別可能な識別子又は名前が付与されることができ、ＮＦ ｓｅｔ内部のＮＦが互いコンテキストを共有して動作する場合でも管理／操作次元で各ＮＦは互いに異なる識別子／名前を付与することができる。

【0041】

図３は、本発明の一実施例にによる端末、基地局、コアを含む５Ｇシステムの動作の一例を示す図面である。

【0042】

図３を参考すれば、３０１段階はＮＦ ｓｅｔに含まれるどんなＮＦ３８３でサービスをリクエストする主体３８２がＲＡＮ（ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ）(基地局）の場合に発生することができ、端末３８１とＲＡＮ３８２の間で無線リソースを用いてシグナリング／データ送受信ができるようにＲＲＣ（ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ）接続（ｃｏｎｎｅｃｔｉｏｎ）を生成することである。

【0043】

３０５段階でリクエスタ３８２はＮＦ３８３に特定ＮＦサービスをリクエストする。もし、リクエスタがＲＡＮ３８２の場合、対象ＮＦ３８３はＡＭＦとなることができる。この時にリクエストに対する受信者３８３はリクエスタ３８２が特定ＮＦと指定して伝達されることもでき、特定ＮＦに限定せずＮＦ ｓｅｔで伝達する場合、ＮＦ ｓｅｔ内の任意のＮＦが受信することができる。

【0044】

３０９段階で受信ＮＦ３８３はＮＦサービスリクエストによる動作を行う。リクエストされたＮＦサービスが既にＮＦ ｓｅｔ内、すなわち、ＮＦ内部又はｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４に予め記憶されたＵＥ ｃｏｎｔｅｘｔを要することかを確認する。もし、ＮＦ内部に情報が既に記憶（ｃａｃｈｅ）されていると、記憶された情報を直接用い、３１３～３２１段階は省略されることができる。

【0045】

ＮＦ３８３はｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４に記憶されたＵＥ ｃｏｎｔｅｘｔが必要な場合、３１３段階でｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４に コンテキスト検索をリクエストする。この時、ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４がＵＤＳＦの場合、前記コンテキスト検索リクエストのためにＮｕｄｓｆ＿ＵｎｓｔｒｕｃｔｕｒｅｄＤａｔａＭａｎａｇｅｍｅｎｔ＿Ｑｕｅｒｙサービス（リクエスト）を用い、前記リクエストメッセージには検索するデータを識別することができる識別子（ｄａｔａ ｉｄｅｎｔｉｆｉｅｒ）を含むことができる。前記データを識別することができる識別子は、もし、ＮＦ３８３が正確なｄａｔａ ｉｄｅｎｔｉｆｉｅｒが分かっている場合には、当該値を、そうではなければ特定端末に対する識別子を含むことができる。特定端末（加入者）に対する識別子はＳＵＰＩ（ｓｕｂｓｃｒｉｐｔｉｏｎ ｐｅｒｍａｎｅｎｔ ＩＤ：ＩＭＳＩ又はＮＡＩの形態）又は特定ＮＦ ｓｅｔ内でｕｎｉｑｕｅな臨時（ｔｅｍｐｏｒａｒｙ）識別子（５Ｇ－ＧＵＴＩ（ｇｌｏｂａｌｌｙ ｕｎｉｑｕｅ ｔｅｍｐｏｒａｒｙ ｉｄｅｎｔｉｆｉｅｒ）、ＩＰ（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）住所、ＴＥＩＤ（ｔｕｎｎｅｌ ｅｎｄｐｏｉｎｔ ＩＤ）、ｆｌｏｗ ＩＤ、ａｐｐｌｉｃａｔｉｏｎ／ｓｅｒｖｉｃｅ ＩＤ、ｃｈａｒｇｉｎｇ ＩＤなど一つで予め付与された場合）を含む。

【0046】

３１７段階でｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４はＮＦ３８３のリクエストに従って検索するデータがあるかを検索し、ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４はこれに対する応答を ３２１段階でＮＦ３８３に送信する。もし、リクエストが有効で、すなわち、ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４がリクエストメッセージに含まれた識別子で有効なコンテキストを検索することができる場合、３２１段階で送信される応答メッセージは当該コンテキストを含む。この過程でＮＦ３８３のリクエストに対する有効性チェック及び検索するコンテキストを探すためにｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４はリクエストに含まれた識別子（ｄａｔａ ｉｄｅｎｔｉｆｉｅｒ又はＵＥ／加入者識別子）及びリクエストしたＮＦ３８３のｔｙｐｅ（ＡＭＦ／ＳＭＦなどのｔｙｐｅ）を考慮することができる。もし、ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４がＵＤＳＦの場合、応答はＮｕｄｓｆ＿ＵｎｓｔｒｕｃｔｕｒｅｄＤａｔａＭａｎａｇｅｍｅｎｔ＿Ｑｕｅｒｙサービスのｒｅｓｐｏｎｓｅに対応される。もし、３１３段階でリクエスト時の特定ｄａｔａ ｉｄｅｎｔｉｆｉｅｒを利用せず、端末（加入者）の識別子を利用したが、ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４に既に特定ｄａｔａ ｉｄｅｎｔｉｆｉｅｒが割り当てられた場合、３２１段階で送信されるｒｅｓｐｏｎｓｅはｄａｔａ ｉｄｅｎｔｉｆｉｅｒを含むことができる。そして、これを受信したＮＦ３８３はｄａｔａ ｉｄｅｎｔｉｆｉｅｒを記憶し、以後に発生するｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４に対するリクエスト時の当該ｄａｔａ ｉｄｅｎｔｉｆｉｅｒを用いることができる。これを介してｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４がＵＥ（加入者）識別子を用いて記憶されたコンテキストを検索する時間を減らすか、負荷を減らすことができる。

【0047】

３２５段階で当該コンテキストを用いて３０５段階でリクエストしたｐｒｏｃｅｄｕｒｅ／ｔｒａｎｓａｃｔｉｏｎが処理される。本発明の実施例においてｐｒｏｃｅｄｕｒｅ／ｔｒａｎｓａｃｔｉｏｎは特定ＮＦ内部の処理動作だけではなく、これにより他のＮＦと連動してメッセージ送受信、サービスをリクエストする動作がいずれも含まれる。

【0048】

もし、リクエストによってＵＥ ｃｏｎｔｅｘｔが更新又は新規ＵＥ ｃｏｎｔｅｘｔがｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４に記憶されなければならない場合、ＮＦ３８３は３２９段階でｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４にコンテキスト記憶／更新リクエストをし、このリクエストには新規又は更新されなければならないｃｏｎｔｅｘｔ及びｄａｔａに対する識別子が含まれる。もし、ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４がＵＤＳＦの場合、当該動作はＮｕｄｓｆ＿ＵｎｓｔｒｕｃｔｕｒｅｄＤａｔａＭａｎａｇｅｍｅｎｔ＿Ｃｒｅａｔｅ（記憶）、Ｎｕｄｓｆ＿ＵｎｓｔｒｕｃｔｕｒｅｄＤａｔａＭａｎａｇｅｍｅｎｔ＿Ｕｐｄａｔｅ（更新）のサービスを用いることができる。ｕｐｄａｔｅの場合、もし、ＮＦ３８３がｄａｔａ ｉｄｅｎｔｉｆｉｅｒを明示的に分かるか受信した場合、ＮＦ３８３は当該ｄａｔａ ｉｄｅｎｔｉｆｉｅｒを用いてＵＥ ｃｏｎｔｅｘｔ ｕｐｄａｔｅを行うことができる。そして、ｃｒｅａｔｅの場合、ＮＦ３８３は端末（加入者）の識別子及び記憶するコンテキストをｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４に伝達することができる。

【0049】

３３３段階でｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ３８４はＮＦ３８３が伝達したコンテキストを記憶し、もし、ｄａｔａ ｉｄｅｎｔｉｆｉｅｒの新規生成が必要な場合（３２９段階で端末又は加入者識別子を用いた場合）、ｄａｔａ ｉｄｅｎｔｉｆｉｅｒを新規生成して３３７段階で応答を介してＮＦ３８３に伝達することができる。

【0050】

ＮＦ３８３及び他のノード３８１、３８２は３４１段階で残りｐｒｏｃｅｄｕｒｅ／ｔｒａｎｓａｃｔｉｏｎを処理する。もし、当該ｐｒｏｃｅｄｕｒｅ／ｔｒａｎｓａｃｔｉｏｎを介してＵＥ（加入者）に対する新規ｔｅｍｐｏｒａｒｙ ＩＤ（５Ｇ－ＧＵＴＩ、ＴＥＩＤ、ＩＰ 住所のうちの一つ以上）が割り当てられた場合、当該ＩＤは端末３８１まで伝達し、端末３８１はこれを記憶して以後のｐｒｏｃｅｄｕｒｅに用いる。

【0051】

前述の実施例で多数のＮＦをＮＦ ｓｅｔにグループ化し、コンテキストを分離／共有する方案を説明した。５Ｇシステムを介してユーザにｃｏｎｎｅｃｔｉｖｉｔｙを提供するための過程の実行時に多くの種類の臨時（ｔｅｍｐｏｒａｒｙ）識別子を割り当てるようになる。本発明の実施例では以下の臨時識別子を対象で実施例を説明するが、本発明の要旨は通信システムで用いられるどんな類型の臨時識別子を割り当て／管理する時にも適用されることができる。

【0052】

－５Ｇ－ＧＵＴＩ：ｇｌｏｂａｌｌｙ ｕｎｉｑｕｅな臨時識別子であり、端末をｓｅｒｖｉｎｇするＡＭＦの識別子ＧＵＡＭＩと端末に割り当てられたＭ－ＴＭＳＩ（ＭＭＥ ｔｅｍｐｏｒａｒｙ ｍｏｂｉｌｅ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ）から構成される。一つのＡＭＦ ｓｅｔ内でＭ－ＴＭＳＩは端末別でｕｎｉｑｕｅな方法で割り当てられるべきである。

【0053】

－ＴＥＩＤ：通信装備（基地局－ＮＦ及びＮＦの間、特にＵＰＦ）の間のパケットを送信するＧＴＰ（ＧＰＲＳ（ｇｅｎｅｒａｌ ｐａｃｋｅｔ ｒａｄｉｏ ｓｙｓｔｅｍ）ｔｕｎｎｅｌｉｎｇ ｐｒｏｔｏｃｏｌ）ｔｕｎｎｅｌを区分するｅｎｄｐｏｉｎｔ ＩＤであり、ＮＦが用いるＩＰ内でｕｎiｑｕｉｅな方法で割り当てられるべきである。

【0054】

－ＵＥ ＩＰ住所：端末がＩＰ通信を用いる場合、端末に割り当てられるＩＰ住所であり、一つのＩＰドメイン内から端末別でuｎｉｑｕｅな方法で割り当てられるべきである。

【0055】

－ｆｌｏｗ ＩＤ：特定トラフィックフローを区分して制御するために割り当てられる識別子である。

【0056】

－ａｐｐｌｉｃａｔｉｏｎ ＩＤ：特定のサービス適用するために割り当てられる識別子である。

【0057】

－ａｎａｌｙｔｉｃ ＩＤ：ＮＷ内部の情報を収集／分析するために割り当られる識別子であり、ＮＷＤＡＦ（Ｎ／Ｗ ｄａｔａ ａｎａｌｙｔｉｃ ｆｕｎｃｔｉｏｎ）で用いられる。

【0058】

－ｂａｃｋｇｒｏｕｎｄ ｄａｔａ ｔｒａｎｓｆｅｒ ｒｅｆｅｒｅｎｃｅ ＩＤ：端末にｂａｃｋｇｒｏｕｎｄでデータを送信する時に用いる識別子である。

【0059】

－ＣＤＲ（ｃｈａｒｇｉｎｇ ｄａｔａ ｒｅｃｏｒｄ） ＩＤ：特定課金情報を制御するために用いられる識別子である。

【0060】

もし、ＮＦが特定端末（加入者）に対して臨時識別子を割り当てる場合、特定条件によってｕｎｉｑｕｅｎｅｓｓ保障が必要であり、これが充足されない場合、エラーが発生するようになり、サービス品質が低下されたりエラーを復旧するための過程が行なわなければならない。一つのＮＦ内部ですべてのリソースを消耗したシステムと異なり前記実施例で説明した構造ではＮＦ ｓｅｔ内のＮＦがコンテキストを共有し、一端末（加入者）をｓｅｒｖｉｎｇするＮＦが同一ｓｅｔ内では常に変更されることができる。このようなシステムでは臨時識別子の全体ｐｏｏｌもＮＦ内で共有されるので、一つの臨時識別子を２つのＮＦが２つの端末（加入者）に同時に割り当てる問題が発生することができる。

【0061】

図４は、本発明の一実施例にによる５Ｇシステム（端末、基地局、ＮＦ）の動作の他の一例を示す図面である。

【0062】

図４を参考すれば、４０１は特定ＮＦでＮＦサービスをリクエスト／誘発することができる連動ノードであり、ＵＥ、ＲＡＮ（基地局）、又は他のＮＦであれば良い。

【0063】

４０２は通信機能を提供するためのＮＦを意味し、３ＧＰＰ（登録商標）標準で定義したＮＦ及び類似の形態のネットワーク装備を含む。もし、特定ＮＦをインスタンス（ｉｎｓｔａｎｃｅ）形態で具現／操作する場合、ＮＦ ｉｎｓｔａｎｃｅで取り替えられることができる。ＮＦ単位の具現／構築ではないＮＦサービス単位の動作時のＮＦはＮＦ ｓｅｒｖｉｃｅで取り替えられることができる。

【0064】

４０３のｃｏｎｆ．ｓｅｒｖｅｒ（ｃｏｎｆｉｇｕｒａｔｉｏｎ ｓｅｒｖｅｒ）は通信装備（ＲＡＮ、ＮＦ など）を管理／設定する機能を有するサーバーで通常的にＥＭＳ（ｅｌｅｍｅｎｔ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ）又はＯＡＭ（ｏｐｅｒａｔｉｏｎ ａｎｄ ｍａｉｎｔｅｎａｎｃｅ）システムと呼ばれる。４０４のＶＮＦＭ（ｖｉｒｔｕａｌｉｚｅｄ ｎｅｔｗｏｒｋ ｆｕｎｃｔｉｏｎ ｍａｎａｇｅｒ）／ｏｒｃｈｅｓｔｒａｔｏｒは仮想化されたシステムでＮＦを設定／管理するシステムである。本発明においては２つのシステムが分離した場合を想定して実施例を説明するが、２つのシステムは一つに統合されることができ、この場合、２つのシステム間のメッセージ交換は省略されたり内部ｐｒｏｃｅｄｕｒｅによって処理されることができる。

【0065】

４３１段階でＮＦ４０２が初期設置されたり設定されている動作が行われる。

【0066】

４３４段階でＶＮＦＭ／ｏｒｃｈｅｓｔｒａｔｏｒ４０４はｃｏｎｆｉｇｕｒａｔｉｏｎ ｓｅｒｖｅｒ４０３にＮＦのｓｉｚｅ（通常的に最大容量に対応され、同時処理可能な加入者数、セッション数などの値や相対的なｃａｐａｃｉｔｙを示す値など）とＮＦ ｓｅｔのｓｉｚｅ（ＮＦ ｓｅｔに含まれるＮＦの数、全体ｓｅｔの最大容量）を通知する。

【0067】

４３７段階でｃｏｎｆ．ｓｅｒｖｅｒ４０３は受信したＮＦ／ＮＦ ｓｅｔのｓｉｚｅを用いてＮＦ ｓｅｔが共有する臨時識別子の全体ｐｏｏｌを分けてＮＦ別で用いる使用可能な識別子を決定し、ＮＦ４０２別で割り当てられた情報を伝達することができる。使用可能な識別子情報は類型によってＮＦ４０２に伝達することができ、ｃｏｎｆ．ｓｅｒｖｅｒ４０３は臨時識別子の開始値、全体個数の形態又は臨時識別子のｒａｎｇｅ（開始～終了を示す値）、又は割り当てられたすべての識別子のｌｉｓｔをＮＦ４０２に伝達することもできる。ｃｏｎｆ．ｓｅｒｖｅｒ４０３が臨時識別子を管理するのに当り、今後のＮＷの構成（ＮＦの大きさ、Ｓｅｔの大きさなど）の変更を考慮して一部区間を予約（ｒｅｓｅｒｖｅ）し、残り部分を用いて初期割り当てを進行することができる。

【0068】

４４１段階でＮＦ４０２は受信された情報によって自分が用いる臨時識別子のｐｏｏｌを記憶する。

【0069】

４４５段階で特定ＮＦサービスが端末（又はＲＡＮ、又は他のＮＦ）４０１からＮＦ４０２にリクエストされ、端末（加入者）別で臨時識別子割り当てが必要な場合、４４９段階でＮＦ４０２は記憶されたｐｏｏｌ内で識別子を割り当てることができる。そして、４５３段階でＮＦ４０２は端末（又はＲＡＮ、又は他のＮＦ）４０１に応答することができる。

【0070】

前記実施例はＮＦ ｓｅｔ内に多数のＮＦが含まれた場合、活用されることができる方案である。もし、ＮＦ ｓｅｔ内のＮＦの数が動的に変更されるか（障害又は負荷によってｓｃａｌｉｎｇ－ｓｉｚｅ変更発生）、又は各ＮＦのｓｉｚｅが変更される場合、識別子のｐｏｏｌを状況に合わせて変更することが難しい制約がある。

【0071】

図５は、本発明の一実施例によって、動的に変動される５Ｇシステム構造でも効果的に臨時識別子を管理することができる例を示す図面である。

【0072】

図５を参考すれば、５０１は特定ＮＦでＮＦサービスをリクエスト／誘発することができる連動ノードであり、ＵＥ、ＲＡＮ（基地局）、又は他のＮＦであれば良い。

【0073】

５０２は通信機能を提供するためのＮＦを意味し、３ＧＰＰ（登録商標）標準で定義したＮＦ及び類似の形態のネットワーク装備を含む。もし、特定ＮＦをインスタンス（ｉｎｓｔａｎｃｅ）形態で具現／操作する場合、ＮＦ ｉｎｓｔａｎｃｅで取り替えられることができる。ＮＦ単位の具現／構築ではないＮＦ サービス単位の動作時のＮＦはＮＦ ｓｅｒｖｉｃｅで取り替えられることができる。

【0074】

５０３のＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒは全体ＮＦの識別子ｐｏｏｌを管理する機能を有するサーバーである。ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ５０３は別途の機能（ＮＦ）から構成されるか又は前記実施例で説明したｃｏｎｔｅｘｔ ｓｅｒｖｅｒと統合されてｃｏｎｔｅｘｔ ｓｅｒｖｅｒが提供する詳細機能から構成されることもできる。

【0075】

５３１段階は連動ノード（ＵＥ／ＲＡＮ／ＮＦ）５０１とＮＦ５０２が互いにメッセージを交換して連動動作を行うことができる状態であることを意味する。

【0076】

５３５段階で端末又は連動ＮＦ５０１はＮＦサービスをＮＦ５０２にリクエストする。連動ＮＦ５０１がＮＦサービスをリクエストすることは端末のリクエスト、ＲＡＮのリクエスト又はＮＦ内部動作及び他のＮＦのリクエストによるサービスを処理する過程のうちに発生することができる。

【0077】

５３９段階でＮＦ５０２は受信されたｔｒａｎｓａｃｔｉｏｎを処理し、新規コンテキスト生成が必要であるか又は臨時識別子割り当てが必要な場合であるかを判断する。

【0078】

５４４段階でＮＦ５０２はＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ５０３にＩＤ割り当てリクエスト又はコンテキスト生成／更新リクエストを送信することができる。この時、ＮＦ５０２はＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ５０３に端末（加入者）に割り当てる臨時識別子をリクエストすることができる。リクエストメッセージは用いる臨時識別子のｔｙｐｅ 情報を含むことができる。ｔｙｐｅ情報はＭ－ＴＭＳＩ、５Ｇ－ＧＵＴＩ、ＧＴＰ ＴＥＩＤ、ＩＰ 住所などの前述の識別子中の一つ以上を含むことができる。また、ＮＦ６０２は臨時識別子を割り当てる時にｒａｎｄｏｍｉｚｅを適用するか否かを明示的にＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ５０３にリクエストすることができる。もし、ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ５０３がＵＤＳＦのサービスをサポートする場合、前記図２の実施例で説明したサービスを用いてリクエスト／応答が処理されることができる。

【0079】

５４９段階でＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ５０３は、もし、コンテキスト処理リクエストを受けた場合にコンテキストを記憶／更新し、リクエストされた臨時識別子を割り当てる。もし、リクエストされた臨時識別子がｒａｎｄｏｍｉｚｅが必要であるか（例えば、５Ｇ－ＧＵＴＩ又はＭ－ＴＭＳＩの場合）、それとも別に明示的にｒａｎｄｏｍｉｚｅがリクエストされた場合、ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ５０３は臨時識別子を割り当てる時にｒａｎｄｏｍｉｚｅを適用する。

【0080】

５５４段階でＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ５０３はＮＦ５０２に割り当てた臨時識別子、コンテキスト処理リクエストを受けた場合にはコンテキスト処理に対する応答を送信する。

【0081】

５５９段階でＮＦ５０２は割り当てられた臨時識別子を用いて残りｐｒｏｃｅｄｕｒｅ／ｔｒａｎｓａｃｔｉｏｎを処理する。

【0082】

５６４段階で割り当てられた臨時識別子は連動ノード（端末／基地局又は連動 ＮＦ）５０１に伝達し、これを受信した連動ノード５０１は受信された臨時識別子を記憶して以後に用いる。

【0083】

図６は、本発明のまた他の実施例によって毎度ｔｒａｎｓａｃｔｉｏｎを処理する度に臨時識別子をリクエストして割り当てることではないＮＦ ｓｅｔで共有する識別子のｐｏｏｌをｃｈｕｎｋ単位で分け、ｃｈｕｎｋ単位で割り当て及び管理、収去する方法を示す図面である。

【0084】

ｃｈｕｎｋ単位の割り当て方法は識別子管理のためのＮＦの間のシグナリングを減らすことができ、各ＮＦがｃｈｕｎｋ内で自由に識別子を割り当てながらも衝突を防止することができるので効果的な方法である。

【0085】

図６を参考すれば、６０１は特定ＮＦでＮＦサービスをリクエスト／誘発することができる連動ノードであり、ＵＥ、ＲＡＮ（基地局）、又は他のＮＦであれば良い。

【0086】

６０２は通信機能を提供するためのＮＦを意味し、３ＧＰＰ（登録商標）標準で定義したＮＦ及び類似の形態のネットワーク装備を含む。もし、特定ＮＦをインスタンス（ｉｎｓｔａｎｃｅ）形態で具現／操作する場合、ＮＦ ｉｎｓｔａｎｃｅで取り替えられることができる。ＮＦ単位の具現／構築ではないＮＦサービス単位の動作時のＮＦはＮＦ ｓｅｒｖｉｃｅで取り替えられることができる。

【0087】

６０３のＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒは全体ＮＦの識別子ｐｏｏｌを管理する機能を有するサーバーである。ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３は別途の機能（ＮＦ）から構成されるか又は前記実施例で説明したｃｏｎｔｅｘｔ ｓｅｒｖｅｒと統合されてｃｏｎｔｅｘｔ ｓｅｒｖｅｒが提供する詳細機能から構成されることもできる。ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３は特定ＮＦ ｓｅｔ別で構築されることもでき、多くのＮＦ ｓｅｔをサポートするように構成されることもできる。

【0088】

６３０段階は連動ノード（ＵＥ／ＲＡＮ／ＮＦ）６０１とＮＦ６０２が互いにメッセージを交換して連動動作を行うことができる状態であることを意味する。

【0089】

６３５段階で端末又は連動ＮＦ６０１はＮＦ６０２にＮＦサービスをリクエストする。連動ＮＦ６０１がＮＦサービスをリクエストすることは端末のリクエスト、ＲＡＮのリクエスト又はＮＦ内部動作及び他のＮＦのリクエストによるサービスを処理する過程のうちの発生することができる。

【0090】

６４０段階でＮＦ６０２は受信されたｔｒａｎｓａｃｔｉｏｎを処理し、臨時識別子割り当てが必要な場合であるかを判断する。６４０段階を行うために６３５段階が必ず必要なことではなく、ＮＦ６０２はサービスリクエストを処理するための初期化（ｉｎｉｔｉａｔｉｏｎ）過程又は一般的な動作状況でＩＤ ｐｏｏｌ割り当てが必要であれば６４０段階から開始することができる。

【0091】

６４５段階でＮＦ６０２はＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３にＩＤ割り当てリクエストを送信することができる。この時、ＮＦ６０２はＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３に端末（加入者）に割り当てる臨時識別子のｃｈｕｎｋ割り当てをリクエストすることができる。リクエストメッセージには用いる臨時識別子のｔｙｐｅ情報を含むことができ、ｃｈｕｎｋ大きさ（すなわち、割り当てられるＩＤの数）を含むことができる。ｔｙｐｅ情報はＭ－ＴＭＳＩ、５Ｇ－ＧＵＴＩ、ＧＴＰ ＴＥＩＤ、ＩＰ住所など前述した識別子のうちの一つ以上を含むことができる。もし、ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３が多くのＮＦ ｓｅｔを同時にサポートするように構成された場合、ＮＦ６０２はリクエストメッセージに自分が属したＮＦ ｓｅｔの名前又は情報をＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３に通知することができる。また、ＮＦ６０２は臨時識別子を割り当てる時にｒａｎｄｏｍｉｚｅを適用するか否かをＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３に明示的にリクエストすることができる。もし、ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３がＵＤＳＦのサービスをサポートする場合、前記図２の実施例で説明したサービスを用いてリクエスト／応答が処理されることができ、ＩＤ ｃｈｕｎｋに対する割り当てを特定コンテキストをｃｒｅａｔｅするｏｐｅｒａｔｉｏｎで具現することができる。又は、ＵＤＳＦに明示的にＩＤ割り当てをリクエストする別途のサービスを用いることもできる。

【0092】

６５０段階でＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３はリクエストされた臨時識別子を割り当てる。もし、リクエストされた臨時識別子がｒａｎｄｏｍｉｚｅが必要であるか（例えば、５Ｇ－ＧＵＴＩやＭ－ＴＭＳＩの場合）、それとも別に明示的にｒａｎｄｏｍｉｚｅをリクエストされた場合、ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３は臨時識別子を割り当てる時にｒａｎｄｏｍｉｚｅを適用する。ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３はリクエストされたｃｈｕｎｋの大きさをいずれも収容して割り当てることもでき、より小さい大きさのｃｈｕｎｋを割り当てることもできる。ｃｈｕｎｋに対する情報はｃｈｕｎｋの識別子を含み、これは今後のｃｈｕｎｋ単位の管理（返還など）に用いられる。

【0093】

６５５段階でＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３はＮＦ６０２に割り当てた臨時識別子ｃｈｕｎｋを伝達することができる。ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３はＮＦ６０２に成功可否、ｃｈｕｎｋの大きさ情報を共に伝達することができる。

【0094】

６６０段階でＮＦ６０２は割り当てられた臨時識別子を用いて残りｐｒｏｃｅｄｕｒｅ／ｔｒａｎｓａｃｔｉｏｎを処理する。

【0095】

６６５段階で割り当てられた臨時識別子は連動ノード（端末／基地局又は連動 ＮＦ）６０１に伝達し、これを受信した連動ノード６０１は受信された臨時識別子を記憶して以後に用いる。

【0096】

一方、本発明のまた他の実施例でｃｈｕｎｋ単位でＩＤを割り当て／管理する動作はｃｈｕｎｋ割り当てが発生する時の前記実施例のようにｃｈｕｎｋに含まれた識別子の情報（開始、個数、ｒａｎｇｅなど）を明示して伝達することだけではなく、ＮＦ６０２とＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ６０３が事前にｃｈｕｎｋの情報を予め交換し、割り当て／返還など実際動作時にはｃｈｕｎｋの識別子（又はｉｎｄｅｘ）だけ伝達する動作に変更されることができる。

【0097】

図７は、本発明の一実施例にによる特定ＮＦが割り当てられたＩＤに対する使用が終了されてこれを返す過程を示す図面である。

【0098】

図７を参考すれば、７０１は特定ＮＦでＮＦサービスをリクエスト／誘発することができる連動ノードでＵＥ、ＲＡＮ（基地局）、又は他のＮＦであっても良い。

【0099】

７０２は通信機能を提供するためのＮＦを意味し、３ＧＰＰ（登録商標）標準で定義したＮＦ及び類似の形態のｎｅｔｗｏｒｋ装備を含む。もし、特定ＮＦをインスタンス（ｉｎｓｔａｎｃｅ）形態で具現／操作する場合、ＮＦ ｉｎｓｔａｎｃｅで取り替えられることができる。ＮＦ単位の具現／構築ではないＮＦサービス単位の動作時のＮＦはＮＦ ｓｅｒｖｉｃｅで取り替えられることができる。

【0100】

７０３のＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒは全体ＮＦの識別子ｐｏｏｌを管理する機能を有するサーバーである。ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ７０３は別途の機能（ＮＦ）から構成されるか又は前記実施例で説明したｃｏｎｔｅｘｔ ｓｅｒｖｅｒと統合されてｃｏｎｔｅｘｔ ｓｅｒｖｅｒが提供する詳細機能で構成されることもできる。ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ７０３は特定ＮＦ ｓｅｔ別で構築されることもでき、多くのＮＦ ｓｅｔをサポートするように構成されることもできる。

【0101】

７３０段階は連動ノード（ＵＥ／ＲＡＮ／ＮＦ）７０１とＮＦ７０２が互いにメッセージを交換して連動動作を行うことができる状態であることを意味する。

【0102】

７３５段階で端末又は連動ＮＦ７０１はＮＦサービスをＮＦ７０２にリクエストする。連動ＮＦ７０１がＮＦサービスをリクエストすることは端末のリクエスト、ＲＡＮのリクエスト又はＮＦ内部動作及び他のＮＦのリクエストによるサービスを処理する過程のうちで発生することができる。この時、リクエストされたサービスは特定の臨時識別子に対する使用が終了されることを特徴とし、ｄｅ－ｒｅｇｉｓｔｒａｔｉｏｎ過程のうちのＭ－ＴＭＳＩ（又は５Ｇ－ＧＵＴＩ）、ｓｅｓｓｉｏｎ ｒｅｌｅａｓｅ過程のうちのＧＴＰ ＴＥＩＤ及びＩＰ住所など前述した識別子に対する使用も終了されることができる。具現／設定によって臨時識別子に対する使用及びコンテキスト削除を直ちに行うことではない一定時間内に保存しているから時間が満了された後に行うこともできる。

【0103】

７４０段階でＮＦ７０２は受信されたｔｒａｎｓａｃｔｉｏｎを処理し、臨時識別子返還が必要な場合であるかを判断する。７４０段階を行うために７３５段階を必ず必要としなく、ＮＦ７０２はタイマー満了や一般的な動作状況でＩＤ返還を必要とすれば７４０段階から開始することができる。

【0104】

７４５段階でＮＦ７０２はＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ７０３にＩＤ返還リクエストを送信することができる。この時、ＮＦ７０２はＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ７０３に端末（加入者）に割り当てる臨時識別子のｃｈｕｎｋ返還をリクエストすることができる。リクエストメッセージには用いる臨時識別子のｃｈｕｎｋ識別子を含むことができる。もし、ＩＤ管理がコンテキスト管理と同時に行われる場合、特定端末（加入者）に割り当てられた臨時識別子に対する返還は、特定端末（加入者）に対するコンテキスト削除と同時に行われることができる。もし、ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ７０３がＵＤＳＦのサービスをサポートする場合、前記図２の実施例で説明したサービスを用いてリクエスト／応答が処理されることができ、ＩＤ ｃｈｕｎｋに対する割り当てを特定コンテキストを削除する操作で具現することができる。又はＵＤＳＦに明示的にＩＤ削除をリクエストする別途のサービスを用いることができる。

【0105】

７５０段階でＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ７０３はリクエストされた臨時識別子をこれ以上使用しない状態で転換し、７５５段階でＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ７０３は返還に対する応答をＮＦ７０２に送信する。もし、コンテキスト処理を介してＩＤ返還が行われる場合、ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒ７０３はコンテキスト削除に対する応答を送信することができる。

【0106】

７６０段階でＮＦ７０２は残りのｐｒｏｃｅｄｕｒｅ／ｔｒａｎｓａｃｔｉｏｎを処理する。

【0107】

７６５段階でｐｒｏｃｅｄｕｒｅ処理によって臨時識別子に対する削除通知がノード（端末／基地局又は連動ＮＦ）７０１に伝達する。

【0108】

図８は、本発明の一実施例によってｃｏｎｔｅｘｔ ｓｔｏｒａｇｅやＮＦの間にｃｏｎｔｅｘｔを交換するよサービスを提供する場合、コンテキストを受信するＮＦの容量を考慮して対象となるＮＦを選択する方法を示す図面である。

【0109】

図８を参考すれば、ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１は通信サービス提供のためにＮＦが生成／管理する ｄａｔａ（ＵＥ ｃｏｎｔｅｘｔ）を記憶／送信することができる機能を示し、ＣＴＳＦ、ＵＤＳＦなどを含む。ＮＲＦ（ｎｅｔｗｏｒｋ ｒｅｐｏｓｉｔｏｒｙ ｆｕｎｃｔｉｏｎ）、ＳＣＰ（ｓｅｒｖｉｃｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｐｒｏｘｙ）８０２はＮＦの間の接続情報、状態情報を用いてＮＦの間のサービス提供のためのｄｉｓｃｏｖｅｒｙ、ｓｅｌｅｃｔｉｏｎ、ｍｅｓｓａｇｅ ｒｏｕｔｉｎｇを助けるＮＦである。

【0110】

８１０段階でｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１が新規でサービスを開始するか、状態を変更することができる。

【0111】

８２０段階でｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１は自分の情報（ＮＦ ｐｒｏｆｉｌｅ）をＮＲＦ／ＳＣＰ８０２に新規登録するか、更新（状態／設定が変更された場合）しても良い。この時、ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１のｐｒｏｆｉｌｅにはｃｏｎｔｅｘｔ ｓｔｏｒａｇｅが提供することができる最大容量（ｃａｐａｃｉｔｙ）、現在負荷状態、単位時間当り処理（送信／受信）することができるコンテキストの個数を示す処理量、一度のｔｒａｎｓａｃｔｉｏｎで記憶することができるコンテキストの大きさなどのうちの少なくとも一つを含むことができる。ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１のｐｒｏｆｉｌｅが最大容量、負荷状態、処理量及び大きさを示す場合、最大値を基準に算定した相対的な値を用いて表現することができる。又は最大容量、負荷状態、処理量及び大きさは絶対的な数値、例えば、最大容量は特定ｃｏｎｔｅｘｔ ｔｙｐｅ（例えば、ＳＭ ｃｏｎｔｅｘｔ）と最大収容可能な個数の組み合せで、一度に処理することができるコンテキストの個数は特定ｃｏｎｔｅｘｔ ｔｙｐｅと最大処理することができる個数の組み合せで表現することもできる。前記８２０段階の動作のためにｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１はＮＲＦ／ＳＣＰ８０２にＮＲＲｅｇｉｓｔｅｒ ｒｅｑｕｅｓｔ又はＮＦＵｐｄａｔｅ ｒｅｑｕｅｓｔなどのようなメッセージを送信することができる。

【0112】

８３０段階でＮＲＦ／ＳＣＰ８０２はｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１から受信した容量、状態情報など（ＮＦ ｐｒｏｆｉｌｅ）を記憶することができる。

【0113】

８４０段階で他のＮＦ（ＳＭＦ、ＡＭＦ など）８０３はＮＦ８０３が記憶している情報が不足な場合、コンテキスト記憶及び送信をリクエストするためのｃｏｎｔｅｘｔ ｓｔｏｒａｇｅのｄｉｓｃｏｖｅｒｙ／ｓｅｌｅｃｔｉｏｎリクエストをＮＲＦ／ＳＣＰ８０２に送信することができる。ｄｉｓｃｏｖｅｒｙ／ｓｅｌｅｃｔｉｏｎリクエストには明示的に見付けようとする対象がｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ（ＣＴＳＦ又はＵＤＳＦ）や、リクエストするＮＦ ｓｅｒｖｉｃｅがコンテキスト記憶（ｃｏｎｔｅｘｔ ｃｒｅａｔｅ、ｕｐｄａｔｅ、又はｐｕｓｈ）又は送信（ｃｏｎｔｅｘｔ ｔｒａｎｓｆｅｒ）であることを含むことができる。前記８４０段階のリクエストはＮＦＤｉｓｃｏｖｅｒｙ ｒｅｑｕｅｓｔメッセージであれば良い。

【0114】

８５０段階でＮＲＦ／ＳＣＰ８０２はリクエストによるｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ（又は候補のセット）８０１を選択し、これに対する応答を８６０段階でリクエストしたＮＦ８０３に送信することができる。この時、応答には８２０段階で受信して記憶していたｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１のＮＦ ｐｒｏｆｉｌｅ中の必要な情報（ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅの識別子、接続住所、最大容量、現在負荷状態、処理量及び同時送信能力などに対する組み合せ）を含み、具体的な情報の構成及び意味は前記８２０段階で説明した内容と同一であれば良い。８６０段階で送信される応答はＮＦＤｉｓｃｏｖｅｒｙ ｒｅｓｐｏｎｓｅメッセージであっても良い。

【0115】

８７０段階でＮＦ８０３は８６０段階で受信した情報を記憶し、もし、応答に一つのｃｏｎｔｅｘｔ ｓｔｏｒａｇｅを特定することができる応答が受信された場合、該当ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅを、もし対象となる複数個のｃｏｎｔｅｘｔ ｓｔｏｒａｇｅの候補が受信された場合、ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅの候補のうちの一つを選択することができる。この時、選択過程が発生する場合、ＮＦ８０３は前記８６０段階で受信した情報（最大容量、負荷状態など）を考慮してサービスが効果的に提供されることができるｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１を選択することができる。ＮＦ８０３が選択されたｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１にコンテキスト関連サービスをリクエストする場合にも８６０段階で受信された情報を考慮することができ、特にｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１が提供する送信量に制限がある場合、ＮＦ８０３は送信量を超過しないようにリクエストを生成することができ、リクエストに含まれるコンテキストの大きさ（個数や大きさなど）が超過しないようにリクエストを生成することができる。

【0116】

８８０段階でＮＦ８０３はｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１にサービスリクエストを送信する。以後ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１の処理結果に対する応答を受信し、他のｐｒｏｃｅｄｕｒｅがトリガー(ｔｒｉｇｇｅｒ)されることができ、本実施例で詳しい説明は省略する。前記８８０段階でサービスリクエストのためにＮＦ８０３はｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ８０１にＣＴＳＦ ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔメッセージを送信することができる。

【0117】

図９は、本発明の一実施例によってＮＦでコンテキストを管理する方法を示す図面である。

【0118】

図９を参考すれば、９１０段階でＮＦ９０３、９０４及びｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ ＮＦ９０１は相互サービス提供をリクエスト／受信するためのｒｅｇｉｓｔｒａｔｉｏｎ、ｄｉｓｃｏｖｅｒｙ、ｓｅｌｅｃｔｉｏｎ過程を行うことができる。

【0119】

９２０段階でＮＦ ＃１（９０３）はＮＦ変更作業の必要性を判断することができる。

【0120】

９３０段階で、ＮＦ ＃１（９０３）はｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ（ＣＴＳＦ／ＵＤＳＦ）９０１にコンテキストを送信し、ＮＦを変更するためのサービスリクエストを送信する。この時、用いるサービスはｓｅｒｖｉｃｅ ｃｏｎｔｅｘｔ ｐｕｓｈ ｒｅｑｕｅｓｔであっても良く、リクエストメッセージにはコンテキスト送信及びＮＦ変更の対象となるｃｏｎｔｅｘｔを区分することができる識別子（ｃｏｎｔｅｘｔ ＩＤ）、ｃｏｎｔｅｘｔのｔｙｐｅ、対象となる端末（加入者）の識別子、対象となるＰＤＵ ｓｅｓｓｉｏｎの識別子（ｃｏｎｔｅｘｔ ｔｙｐｅがＳＭ ｃｏｎｔｅｘｔの場合）のうちの少なくとも一つが含まれることができる。もし、ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ９０１でリクエストする動作がコンテキストに対する記憶だけではなく、ＮＦに対する変更を伴う場合、リクエストメッセージには追加的にＮＦ変更の対象となるＮＦの識別子が含まれることができる。この時、ＮＦ ＃１（９０３）が変更の対象となるＮＦを選択するために、もし、ｂａｃｋｕｐ ＮＦが予め設定された場合にＮＦ＃１（９０３）はｂａｃｋｕｐ ＮＦのうちの一つを、そうではない場合、ＮＦ ＃１（９０３）は同一なＮＦ ｓｅｔ内でＮＦを選択することができる。もし、ＮＦ変更が必要ではない場合、９６０の次の段階が行われない。

【0121】

９４０段階で、ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ９０１はリクエストに従ってｃｏｎｔｅｘｔを記憶し、これに対する応答をＮＦ ＃１（９０３）に９５０段階で送信する。もし、９３０段階でＮＦ変更まで共にリクエストされた場合、９３０段階で受信されたサービスリクエストに対する９５０段階の応答はＮＦ変更の結果まで受信（９８０段階）された後に伝達することもできる。前記９５０段階の応答はｓｅｒｖｉｃｅ ｃｏｎｔｅｘｔ ｐｕｓｈ ｒｅｓｐｏｎｓｅであれば良い。

【0122】

ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ９０１がＮＦ変更が伴うサービスリクエストを前記９３０段階で受信した場合、９６０段階でｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ９０１はＮＦ変更の対象となるＮＦ（ＮＦ ＃２）９０４にｃｏｎｔｅｘｔを伝達する動作を行う。この時、用いるサービスはｓｅｒｖｉｃｅ ｃｏｎｔｅｘｔ ｐｕｓｈ ｒｅｑｕｅｓｔであっても良く、リクエストメッセージにはｃｏｎｔｅｘｔ 送信及びＮＦ変更の対象となるコンテキストを区分することができる識別子（ｃｏｎｔｅｘｔ ＩＤ）、コンテキストのｔｙｐｅ、対象となる端末（加入者）の識別子、対象となるＰＤＵ ｓｅｓｓｉｏｎの識別子（ｃｏｎｔｅｘｔ ｔｙｐｅがＳＭ ｃｏｎｔｅｘｔの場合）のうちの少なくとも一つが含まれることができる。また、リクエストメッセージにはｃｏｎｔｅｘｔ ｐｕｓｈサービスリクエストがコンテキスト記憶のためのことであるか、ＮＦ変更を伴うことであるかを示す情報が含まれることができる。

【0123】

９７０段階でＮＦ ＃２（９０４）は受信されたコンテキストを記憶し、９８０段階でこれに対する結果をｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ９０１に応答することができる。この時、９８０段階で応答メッセージはｓｅｒｖｉｃｅ ｃｏｎｔｅｘｔ ｐｕｓｈ ｒｅｓｐｏｎｓｅであれば良い。そして、９９０段階でＮＦ ＃２（９０４）はコンテキスト受信及びＮＦ変更によって伴う他のｐｒｏｃｅｄｕｒｅ／ｔｒａｎｓａｃｔｉｏｎを行う。９７０段階／９８０段階／９９０段階の順序は互いに変更されることができる。

【0124】

以下の［表１］は本発明の一実施例でコンテキスト送受信するＮＦがＡＭＦの場合、コンテキストの類型及び構造を示す。

【0125】

【表1】

【0126】

前記［表１］に示されたようにＡＭ ｃｏｎｔｅｘｔはＡＭＦが生成／管理するコンテキストを意味し、ＡＭＦの間にコンテキストを共有するか、ＡＭＦ変更のために直接送受信されるかｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ（ＣＴＳＦ）を介して送信されるデータを意味する。ＡＭ ｃｏｎｔｅｘｔを管理して閲覧し、特定ＡＭ ｃｏｎｔｅｘｔを指称するためのｄａｔａｋｅｙは加入者の識別子（ＳＵＰＩ）であることを示す。

【0127】

図１０は、本発明の一実施例によってコンテキスト送信及びＮＦ変更による誤動作、過負荷を阻むための方法を示す図面である。

【0128】

図１０を参考すれば、１０１０段階でＮＦ１００１は他のＮＦ１００２をｄｉｓｃｏｖｅｒｙ／ｓｅｌｅｃｔｉｏｎする過程を行うことができる。

【0129】

１０２０段階でＮＦ＃１(１００１）は他のＮＦ（ＮＦ ＃２）１００２にコンテキスト送信が必要であるか、伴うＮＦ変更が必要であることを判断し、１０３０段階でＮＦ＃１（１００１）は対象 ＮＦ（ＮＦ ＃２）１００２にｃｏｎｔｅｘｔ ｐｕｓｈサービスをリクエストする。ｃｏｎｔｅｘｔ ｐｕｓｈサービスをリクエストするメッセージにはｃｏｎｔｅｘｔ送信及びＮＦ変更の対象となるコンテキストを区分することができる識別子（ｃｏｎｔｅｘｔ ＩＤ）、ｃｏｎｔｅｘｔのｔｙｐｅ、対象となる端末（加入者）の識別子、対象となるＰＤＵ ｓｅｓｓｉｏｎの識別子（ｃｏｎｔｅｘｔ ｔｙｐｅがＳＭ ｃｏｎｔｅｘｔの場合）のうちの少なくとも一つが含まれることができる。また、ｃｏｎｔｅｘｔ ｐｕｓｈサービスのリクエストメッセージにはｃｏｎｔｅｘｔ ｐｕｓｈサービスリクエストがｃｏｎｔｅｘｔ記憶のためのことであるか、ＮＦ変更を伴うことであるかを示す情報が含まれることができる。前記リクエストメッセージはｓｅｒｖｉｃｅ ｃｏｎｔｅｘｔ ｐｕｓｈ ｒｅｑｕｅｓｔであれば良い。

【0130】

１０４０段階でＮＦ＃２（１００２)は受信されたコンテキストを記憶し、もし、ＮＦ変更が伴わなければならない場合、ＮＦ変更によって伴う他のｐｒｏｃｅｄｕｒｅ／ｔｒａｎｓａｃｔｉｏｎを行うことができる。

【0131】

１０５０段階でＮＦ＃２(１００２）はサービスリクエストに対する結果をさらにＮＦ＃１(１００１)に送信し、この時、応答メッセージには結果だけではなく現在ＮＦの負荷状態及びｃｏｎｔｅｘｔを処理するための情報が含まれることができる。より具体的に、ＮＦ＃２(１００２）が提供することができる最大容量（ｃａｐａｃｉｔｙ）、現在負荷状態、単位時間当たり処理（送信／受信）することができるコンテキストの個数を示す処理量、一度のｔｒａｎｓａｃｔｉｏｎで記憶することができるコンテキストの大きさのうちの一つ以上を含むことができる。前記応答メッセージはｓｅｒｖｉｃｅ ｃｏｎｔｅｘｔ ｐｕｓｈ ｒｅｓｐｏｎｓｅであれば良い。そして、応答を受信したＮＦ＃１(１００１）は情報が含まれた場合、記憶し、今後のコンテキスト送信やＮＦ変更が必要な場合、対象に対する選択、コンテキスト処理リクエストをする時、当該情報を考慮することができる。

【0132】

図１１は、本発明の一実施例にによるＡＭＦの詳細動作を示す。本実施例において、特定ＳＭＦに対して端末のコンテキストを他のＳＭＦで送信するための事前動作がＳＭＦによってトリガーされた状態であることを仮定する。

【0133】

図１１を参考すれば、１１１０段階でＡＭＦはＳＭＦから（ｏｌｄ ＳＭＦで称する）特定ＵＥ及びｓｅｓｓｉｏｎに対するコンテキストを他のＳＭＦに送信する必要があることを通知するメッセージを受信する。このメッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＳＭＣｏｎｔｅｘｔＳｔａｔｕｓＮｏｔｉｆｙであっても良く、これを受信するためにＡＭＦはｏｌｄ ＳＭＦに状態変更に対するＮｏｔｉｆｙを受信するための登録（ｓｕｂｓｃｒｉｂｅ）を予め行うことができる。

【0134】

１１２０段階でＡＭＦはＳＭＦのリクエストメッセージに含まれた情報を用いて対象となる ＳＭＦ（ｎｅｗ ＳＭＦと称する）を選択することができる。そして、ＡＭＦは対象端末及び ｓｅｓｓｉｏｎに対するコンテキストをｏｌｄ ＳＭＦから受信するためのリクエストをｎｅｗ ＳＭＦに送信することができる。この時、用いるメッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔ ｒｅｑｕｅｓｔであれば良い。

【0135】

１１３０段階でＡＭＦは選択的にＳＭＦのｓｅｓｓｉｏｎ関連コンテキスト送信及び処理の成功可否を判断するためのタイマーを開始されることができる。

【0136】

１１４０段階でＡＭＦは、もし、１１３０段階でタイマーを設定し、設定したタイマーがｅｘｐｉｒｅされるまでｎｅｗ ＳＭＦから応答を受信することができなかった場合、ｎｅｗ ＳＭＦにリクエストしたコンテキスト処理手続が失敗したと見做すことができる。又はＡＭＦがｎｅｗ ＳＭＦからコンテキスト処理手続が失敗したことを通知するメッセージを明示的に受信した場合、手続が失敗したと分かる。又は、ＡＭＦはＡＭＦ内部の具現や、又は他のＮＦ又はＯＡＭなどからの情報受信などの方法を介して手続の成功有無を把握することもできる。

【0137】

１１５０段階でＡＭＦは、もし、Ｎｅｗ ＳＭＦでリクエストしたコンテキスト処理が失敗したと判断した場合、当該セッションがｒｅｌｅａｓｅされたと見做してＰＤＵ ｓｅｓｓｉｏｎを削除（ｒｅｌｅａｓｅ）するための手続を行うことができる。又はＡＭＦはコンテキスト処理が失敗したということをｏｌｄ ＳＭＦで通知し、ｏｌｄ ＳＭＦが後続措置を行う。

【0138】

図１２は、本発明の一実施例にによるＡＭＦの詳細動作を示す。本実施例において、特定ＳＭＦに対して端末のコンテキストを他のＳＭＦで送信するための事前動作がＳＭＦによってトリガーされた状態であることを仮定する。

【0139】

図１２を参考すれば、１２１０段階でＡＭＦはＳＭＦから（ｏｌｄ ＳＭＦと称する）特定 ＵＥ及びｓｅｓｓｉｏｎに対するｃｏｎｔｅｘｔを他のＳＭＦに送信する必要があることを通知するメッセージを受信する。このメッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＳＭＣｏｎｔｅｘｔＳｔａｔｕｓＮｏｔｉｆｙであっても良く、これを受信するためにＡＭＦはｏｌｄ ＳＭＦに状態変更に対するＮｏｔｉｆｙを受信するための登録（ｓｕｂｓｃｒｉｂｅ）を予め行うことができる。

【0140】

１２２０段階でＡＭＦはＳＭＦのリクエストメッセージに含まれた情報を用いて対象となる ＳＭＦ（ｎｅｗ ＳＭＦと称する）を選択することができる。そして、ＡＭＦは対象端末及び ｓｅｓｓｉｏｎに対するコンテキストをｏｌｄ ＳＭＦから受信するためのリクエストをｎｅｗ ＳＭＦに送信する。この時、用いるメッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔ ｒｅｑｕｅｓｔであれば良い。この動作を行い、ＡＭＦは選択的にＳＭＦのｓｅｓｓｉｏｎ関連コンテキスト送信及び処理の成功可否を判断するためのタイマーを開始することができる。

【0141】

１２３０段階でＡＭＦは前記１２２０段階でｎｅｗ ＳＭＦでリクエストしたコンテキスト処理手続が完了したことを通知するメッセージを受信する前に、当該端末に対する別途のリクエスト（例えば、ｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔ又はｒｅｇｉｓｔｒａｔｉｏｎ過程のうちの他のＡＭＦから受信するｃｏｎｔｅｘｔ ｔｒａｎｓｆｅｒ ｒｅｑｕｅｓｔなど）を受信することができる。これは一般的に端末の移動性によることであるか、又はアイドル状態の端末にサービス（通話又はデータ送信）が発生して生ずるリクエストであっても良い。

【0142】

１２４０段階でＡＭＦは１２３０段階で受信したリクエストを処理するに当り、対象となる ＵＥ及びｓｅｓｓｉｏｎに現在変更中のＳＭＦが含まれるかを判断する。より具体的に、もし、端末に対して処理すべき動作がｓｅｒｖｉｃｅ ｒｅｑｕｅｓｔの場合、端末に対して処理すべきＰＤＵ ｓｅｓｓｉｏｎに対してサービスを提供したＳＭＦに現在変更中のＳＭＦが含まれるかを判断する。もし、端末に対して処理すべき動作が他のＡＭＦがリクエストしたｃｏｎｔｅｘｔ ｔｒａｎｓｆｅｒ ｒｅｑｕｅｓｔの場合、端末のｓｅｓｓｉｏｎを管理するＳＭＦに現在変更中のＳＭＦが含まれるかを判断する。もし、連関されたＳＭＦに現在変更中のＳＭＦが含まれる場合、１２５０段階へ進行し、そうではない場合、１２６０段階へ進行する。

【0143】

１２５０段階でＡＭＦはｎｅｗ ＳＭＦからコンテキスト生成処理が完了されたことを通知するメッセージを受信するまで１２３０段階で受信したリクエストに対する処理を遅延させる。すなわち、ＡＭＦは１２３０段階で受信したリクエストを記憶して待機する。ＡＭＦはこの段階で、ｎｅｗ ＳＭＦからコンテキスト生成処理が完了したことを通知するメッセージを受信すれば、これによってＵＥ ｃｏｎｔｅｘｔを更新（ＳＭＦ住所含む）して１２６０段階へ進行する。もし、１２２０段階でＡＭＦがｔｉｍｅｒを設定し、設定したｔｉｍｅｒがｅｘｐｉｒｅされるまでＡＭＦがｎｅｗ ＳＭＦから応答を受信することができなかった場合、ｎｅｗ ＳＭＦでリクエストしたコンテキスト処理手続が失敗したと見做すことができる。又はＡＭＦがｎｅｗ ＳＭＦからコンテキスト処理手続が失敗したことを通知するメッセージを明示的に受信した場合、手続が失敗したと分かる。又は、ＡＭＦはＡＭＦ内部の具現や、又は他のＮＦ又はＯＡＭなどからの情報受信などの方法を介して手続の成功有無を把握することもできる。もし、ｎｅｗ ＳＭＦでリクエストしたコンテキスト処理が失敗した場合、ＡＭＦは当該セッションがｒｅｌｅａｓｅされたと見做して１２３０段階で受信されたリクエストを処理することができる。又はＡＭＦはコンテキスト処理が失敗したということをｏｌｄ ＳＭＦで通知し、ｏｌｄ ＳＭＦが後続措置を行う。

【0144】

図１３は、本発明による端末の構成を示す図面である。

【0145】

図１３を参考すれば、本発明の一実施例にによる端末は送受信部１３２０及び端末の全般的な動作を制御する制御部１３１０を含むことができる。そして、前記送受信部１３２０は送信部１３２１及び受信部１３２３を含むことができる。

【0146】

送受信部１３２０は他のネットワークエンティティーと信号を送受信することができる。

【0147】

制御部１３１０は上述した実施例のうちのいずれか一つの動作を行うように端末を制御することができる。一方、前記制御部１３１０及び送受信部１３２０は必ず別途のモジュールで具現されるわけではなく、単一チップのような形態で一つの構成部で具現されることができることは勿論である。そして、前記制御部１３１０及び送受信部１３２０は電気的に接続されることができる。そして、例えば、制御部１３１０は回路（ｃｉｒｃｕｉｔ）、アプリケーション特定（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ） 回路、又は少なくとも一つのプロセッサ（ｐｒｏｃｅｓｓｏｒ）であれば良い。また、端末の動作は当該プログラムコードを記憶したメモリー装置を端末内の任意の構成部に備えることによって実現することができる。

【0148】

図１４は、本発明によるネットワークエンティティー（ｎｅｔｗｏｒｋ ｅｎｔｉｔｙ）の構成を示す図面である。

【0149】

本発明のネットワークエンティティーはシステム具現によってネットワークファンクション（ｎｅｔｗｏｒｋ ｆｕｎｃｔｉｏｎ）を含む概念である。

【0150】

図１４を参考すれば、本発明の一実施例にによるネットワークエンティティーは送受信部１４２０及びネットワークエンティティーの全般的な動作を制御する制御部１４１０を含むことができる。そして、前記送受信部１４２０は送信部１４２１及び受信部１４２３を含むことができる。

【0151】

送受信部１４２０は他のネットワークエンティティーと信号を送受信することができる。

【0152】

制御部１４１０は上述した実施例のうちのいずれか一つの動作を行うようにネットワークエンティティーを制御することができる。一方、前記制御部１４１０及び送受信部１４２０は必ず別途のモジュールで具現されるわけではなく、単一チップのような形態で一つの構成部で具現されることができることは勿論である。そして、前記制御部１４１０及び送受信部１４２０は電気的に接続されることができる。そして、例えば、制御部１２１０は回路（ｃｉｒｃｕｉｔ）、アプリケーション特定（ａｐｐｌｉｃａｔｉｏｎ－ｓｐｅｃｉｆｉｃ）回路、又は少なくとも一つのプロセッサ（ｐｒｏｃｅｓｓｏｒ）であれば良い。また、ネットワークエンティティーの動作は当該プログラムコードを記憶したメモリー装置をネットワークエンティティー内の任意の構成部に備えることによって実現することができる。

【0153】

前記ネットワークエンティティーは基地局（ＲＡＮ）、ＡＭＦ、ＳＭＦ、ＵＰＦ、ＮＦ、ＮＥＦ、ＮＲＦ、ＣＦ、ＮＳＳＦ、ＵＤＭ、ＡＦ、ＡＵＳＦ、ＳＣＰ、ＵＤＳＦ、ｃｏｎｔｅｘｔ ｓｔｏｒａｇｅ、ＯＡＭ、ＥＭＳ、ｃｏｎｆｉｇｕｒａｔｉｏｎ ｓｅｒｖｅｒ、ＩＤ ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｅｒのうちのいずれか一つであれば良い。

【0154】

前記図１乃至図１４が例示する構成図、制御／データ信号送信方法の例示図、動作手続例示図、構成図は本開示の権利範囲を限定するための意図がないことを留意すべきである。すなわち、前記図１乃至図１４に記載したすべての構成部、エンティティー、又は動作の段階が開示の実施のための必須構成要素であることに解釈されてはいけなく、一部構成要素のみを含んでも開始の本質を害しない範囲内で具現されることができる。

【0155】

前述した基地局や端末の動作は当該プログラムコードを記憶したメモリー装置を基地局又は端末装置内の任意の構成部に備えることによって実現することができる。すなわち、基地局又は端末装置の制御部はメモリー装置内に記憶されたプログラムコードをプロセッサ又はＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）によって読み出して行うことによって前述した動作を行うことができる。

【0156】

本明細書で説明されるエンティティー、基地局又は端末装置の多様な構成部と、モジュール（ｍｏｄｕｌｅ）などはハードウェア（ｈａｒｄｗａｒｅ）回路、例えば、相補的金属酸化物半導体（ｃｏｍｐｌｅｍｅｎｔａｒｙ ｍｅｔａｌ ｏｘｉｄｅ ｓｅｍｉｃｏｎｄｕｃｔｏｒ）基盤論理回路と、ファームウェア（ｆｉｒｍｗａｒｅ）と、ソフトウェア（ｓｏｆｔｗａｒｅ）及び／又はハードウェアとファームウェア及び／又はマシン可読媒体に挿入されたソフトウェアの組み合せのようなハードウェア回路を用いて動作されることもできる。例えば、多様な電気構造及び方法はトランジスター（ｔｒａｎｓｉｓｔｏｒ）と、論理ゲート（ｌｏｇｉｃ ｇａｔｅ）と、注文型半導体のような電気回路を用いて実施されることができる。

【0157】

一方、本開示の詳細な説明では具体的な実施例に関して説明したが、本開示の範囲から逸脱せず限度内で様々な変形が可能であることは勿論である。したがって、本開示の範囲は説明された実施例に限って決定されてはいけなく、後述する特許請求の範囲だけではなくこの特許請求の範囲と均等なものなどによって決定すべきである。

【符号の説明】

【0158】

1310 制御部
1320 送受信部
1321 送信部
1323 受信部
1410 制御部
1420 送受信部
1421 送信部
1423 受信部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】