JP2022103356A

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

Info

Publication number: JP2022103356A
Application number: JP2022081662A
Authority: JP
Inventors: サンス・ジョン; Sangsoo Jeong; ホヨン・イ; Hoyong Lee
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2019-05-13
Filing date: 2022-05-18
Publication date: 2022-07-07
Also published as: AU2020276949A1; AU2020276949B2; US20220109972A1; JP2022519387A; EP4117325A1; US11812504B2; AU2022203982B2; US11206526B2; CN113508611B; JP7077492B2; AU2022203982A1; CN114845291A; JP2022103357A; CN114845292A; CN113508611A; KR20200131149A; US20200367045A1

Abstract

【課題】本開示は、ＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ）のような４Ｇ（４ｔｈｇｅｎｅｒａｔｉｏｎ）通信システム以後より高いデータ送信率をサポートするための５Ｇ（５ｔｈｇｅｎｅｒａｔｉｏｎ）又はｐｒｅ－５Ｇ通信システムをＩｏＴ技術とコンバージェンスする通信技法及びそのシステムを提供する。【解決手段】本開示は、５Ｇ通信技術及びＩｏＴ関連技術を基盤で知能型サービス（例えば、スマートホーム、スマートビルディング、スマートシティ、スマートカー又はコネクテッドカー、ヘルスケア、デジタル教育、スマート小売、保安及び安全サービス）に適用されることができる。本発明の多様な実施例によって移動通信システムで端末のコンテキストを管理する方法を提供することができる。【選択図】図６

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本発明の一実施例によるＳＢＡ基盤の５Ｇシステム構造を示す図面である。本発明の一実施例によるＮＦとコンテキストの分離構造を示す図面である。本発明の一実施例による端末、基地局、コアを含む５Ｇシステムの動作の一例を示す図面である。本発明の一実施例による５Ｇシステム（端末、基地局、ＮＦ）の動作の他の一例を示す図面である。本発明の一実施例によって、動的に変動される５Ｇシステム構造でも効果的に臨時識別子を管理することができる例を示す図面である。本発明のまた他の実施例によって毎度ｔｒａｎｓａｃｔｉｏｎを処理するたびに臨時識別子をリクエストして割り当てることではないＮＦｓｅｔで共有する識別子のｐｏｏｌをｃｈｕｎｋ単位で分け、ｃｈｕｎｋ単位で割り当て及び管理、収去する方案を示す図面である。本発明の一実施例による特定ＮＦが割り当てられたＩＤに対する使用が終了されてこれを返る過程を示す図面である。本発明の一実施例によってｃｏｎｔｅｘｔｓｔｏｒａｇｅやＮＦの間にコンテキストを交換してサービスを提供する場合、コンテキストを受信するＮＦの容量を考慮して対象となるＮＦを選択する方案を示す図面である。本発明の一実施例によってＮＦでコンテキストを管理する方法を示す図面である。本発明の一実施例によってコンテキスト送信及びＮＦ変更による誤動作、過負荷を防止するための方法を示す図面である。本発明の一実施例によるＡＭＦの詳細動作を示す。本発明の一実施例によるＡＭＦの詳細動作を示す。本発明による端末の構成を示す図面である。本発明によるネットワークエンティティー（ｎｅｔｗｏｒｋｅｎｔｉｔｙ）の構成を示す図面である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

無線通信システムのＡＭＦ（ａｃｃｅｓｓａｎｄｍｏｂｉｌｉｔｙｍａｎａｇｅｍｅｎｔｆｕｎｃｔｉｏｎ）エンティティーによって行われる方法であって、
ＳＭ（ｓｅｓｓｉｏｎｍａｎａｇｅｍｅｎｔ）コンテキスト（ｃｏｎｔｅｘｔ）を第２ＳＭＦ（ｓｅｓｓｉｏｎｍａｎａｇｅｍｅｎｔｆｕｎｃｔｉｏｎ）エンティティーに伝達するための第１メッセージを第１ＳＭＦエンティティーから受信する段階と、
前記第２ＳＭＦエンティティーが前記第１ＳＭＦエンティティーから前記ＳＭコンテキストを受信するようにリクエストする第２メッセージを前記第２ＳＭＦエンティティーに送信する段階と、
前記第２メッセージの送信によってタイマーを開始する段階と、及び
前記タイマーの満了の前に、前記第２メッセージの応答で第３メッセージを前記第２ＳＭＦエンティティーから受信する段階と、を含む方法。
前記第３メッセージを受信する前に前記タイマーが満了された場合、ＳＭコンテキスト伝達手順は失敗したことで判断する段階をさらに含むことを特徴とする、請求項１に記載の方法。
前記第１メッセージは前記ＳＭコンテキストの伝達を指示する情報を含むことを特徴とする、請求項１に記載の方法。
前記第３メッセージの受信の前にサービスリクエストメッセージを端末から受信する段階と、及び
前記第３メッセージを受信するまで前記ＳＭコンテキストと連関された動作をディレーする段階と、をさらに含むことを特徴とする、請求項１に記載の方法。
前記第３メッセージの受信の前にＵＥ（ｕｓｅｒｅｑｕｉｐｍｅｎｔ）コンテキスト伝達リクエストメッセージを他のＡＭＦエンティティーから受信する段階と、及び
前記第３メッセージを受信するまで前記ＳＭコンテキストと連関された動作をディレーする段階と、をさらに含むことを特徴とする、請求項１に記載の方法。
前記第１メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＳＭＣｏｎｔｅｘｔＳｔａｔｕｓＮｏｔｉｆｙメッセージを含み、前記第２メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔｒｅｑｕｅｓｔメッセージを含み、前記第３メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔｒｅｓｐｏｎｓｅメッセージを含むことを特徴とする、請求項１に記載の方法。
前記第２メッセージを送信する段階は、
前記第１メッセージに基づいて前記第２ＳＭＦエンティティーを選択する段階をさらに含むことを特徴とする、請求項１に記載の方法。
無線通信システムのＡＭＦ（ａｃｃｅｓｓａｎｄｍｏｂｉｌｉｔｙｍａｎａｇｅｍｅｎｔｆｕｎｃｔｉｏｎ）であって、
送受信部と、及び
ＳＭ（ｓｅｓｓｉｏｎｍａｎａｇｅｍｅｎｔ）コンテキスト（ｃｏｎｔｅｘｔ）を第２ＳＭＦ（ｓｅｓｓｉｏｎｍａｎａｇｅｍｅｎｔｆｕｎｃｔｉｏｎ）エンティティーに伝達するための第１メッセージを第１ＳＭＦエンティティーから前記送受信部を介して受信し、前記第２ＳＭＦエンティティーが前記第１ＳＭＦエンティティーから前記ＳＭコンテキストを受信するようにリクエストする第２メッセージを前記第２ＳＭＦエンティティーに前記送受信部を介して送信し、前記第２メッセージの送信によってタイマーを開始し、前記タイマーの満了の前に、前記第２メッセージの応答で第３メッセージを前記第２ＳＭＦエンティティーから前記送受信部を介して受信する制御部と、を含むＡＭＦ。
前記制御部は、
前記第３メッセージを受信する前に前記タイマーが満了された場合、ＳＭコンテキスト伝達手順は失敗したことで判断することを特徴とする、請求項８に記載のＡＭＦ。
前記第１メッセージは前記ＳＭコンテキストの伝達を指示する情報を含むことを特徴とする、請求項８に記載のＡＭＦ。
前記制御部は、
前記第３メッセージの受信の前にサービスリクエストメッセージを端末から前記送受信部を介して受信し、前記第３メッセージを受信するまで前記ＳＭコンテキストと連関された動作をディレーすることを特徴とする、請求項８に記載のＡＭＦ。
前記制御部は、
前記第３メッセージの受信の前にＵＥ（ｕｓｅｒｅｑｕｉｐｍｅｎｔ）コンテキスト伝達リクエストメッセージを他のＡＭＦエンティティーから前記送受信部を介して受信し、前記第３メッセージを受信するまで前記ＳＭコンテキストと連関された動作をディレーすることを特徴とする、請求項８に記載のＡＭＦ。
前記第１メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＳＭＣｏｎｔｅｘｔＳｔａｔｕｓＮｏｔｉｆｙメッセージを含み、前記第２メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔｒｅｑｕｅｓｔメッセージを含み、前記第３メッセージはＮｓｍｆ＿ＰＤＵＳｅｓｓｉｏｎ＿ＣｒｅａｔｅＳＭＣｏｎｔｅｘｔｒｅｓｐｏｎｓｅメッセージを含むことを特徴とする、請求項８に記載のＡＭＦ。
前記制御部は、
前記第１メッセージに基づいて前記第２ＳＭＦエンティティーを選択することを特徴とする、請求項８に記載のＡＭＦ。