特開 2024-141722 ステートレスコアネットワークシステム、リクエスト管理装置およびリクエスト管理方法

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024141722

(43)【公開日】2024-10-10

(54)【発明の名称】ステートレスコアネットワークシステム、リクエスト管理装置およびリクエスト管理方法

(51)【国際特許分類】

   H04W 8/22 20090101AFI20241003BHJP

   H04W 76/10 20180101ALI20241003BHJP

   H04W 88/18 20090101ALI20241003BHJP

   H04W 24/00 20090101ALI20241003BHJP

【ＦＩ】

H04W8/22

H04W76/10

H04W88/18

H04W24/00

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2023053517

(22)【出願日】2023-03-29

(71)【出願人】

【識別番号】000208891

【氏名又は名称】ＫＤＤＩ株式会社

(74)【代理人】

【識別番号】110003281

【氏名又は名称】弁理士法人大塚国際特許事務所

(72)【発明者】

【氏名】城 哲

(72)【発明者】

【氏名】植田 一暁

(72)【発明者】

【氏名】加藤 尭彦

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA21

5K067DD23

5K067DD34

5K067EE02

5K067EE10

5K067EE16

5K067LL01

(57)【要約】

【課題】リクエストの処理にステートを必要としないステートレスコアネットワークにおいて、同一のＵＥから複数のリクエストを短時間に受けた際に、適切に制御を行なうことを可能にする。
【解決手段】前記端末から送信される前記リクエストを受け付ける受付層２００と、前記受付層から前記リクエストを受信し、前記端末の状況を把握して前記リクエストを管理する管理層３００と、前記管理層から転送される前記リクエストを、その種類に応じて処理する複数のソフトウェアを有する処理層４００と、前記端末に関する情報を保持し、前記処理層に前記情報を提供する保持層５００と、を備え、前記管理層３００は、前記端末の状況に基づいて前記リクエストに対する処理を判定し、前記リクエストを実行すると判定された場合、前記リクエストの内容に応じたソフトウェア４１０へ転送する。
【選択図】図１

【特許請求の範囲】

【請求項1】

移動通信システムに用いられ、端末から送信されるリクエストの処理にステートを必要としないステートレスコアネットワークシステムであって、
前記端末から送信される前記リクエストを受け付ける受付層と、
前記受付層から前記リクエストを受信し、前記端末の状況を把握して前記リクエストを管理する管理層と
前記管理層から転送される前記リクエストを、その種類に応じて処理する複数のソフトウェアを有する処理層と、
前記端末に関する情報を保持し、前記処理層に前記情報を提供する保持層と、を備え、
前記管理層は、前記端末の状況に基づいて前記リクエストに対する処理を判定し、前記リクエストを実行すると判定された場合、前記リクエストの内容に応じたソフトウェアへ転送することを特徴とするステートレスコアネットワークシステム。

【請求項2】

前記管理層は、前記端末の状況を把握するために、前記保持層から前記端末に関する情報を取得することを特徴とする請求項１に記載のステートレスコアネットワークシステム。

【請求項3】

前記処理層は、前記保持層において前記端末に関する情報を更新する場合、前記管理層に前記端末に関する情報の更新を要求することを特徴とする請求項２に記載のステートレスコアネットワークシステム。

【請求項4】

前記管理層は、対応する端末の前記リクエストを管理する複数のリクエスト管理部を有し、
前記受付層は、少なくとも前記端末の情報に基づいて、前記受け付けたリクエストをいずれかの前記リクエスト管理部に転送する振り分け部を備えることを特徴とする請求項１または２に記載のステートレスコアネットワークシステム。

【請求項5】

請求項１または２記載のステートレスコアネットワークシステムの管理層に適用されるリクエスト管理装置であって、
リクエストを送信した端末に関する情報を保持する情報保持部と、
前記情報保持部に保持される情報に基づいて、前記リクエストの種類を判別する判別部と、
前記リクエストを前記判別した種類に応じたソフトウェアへ転送部と、を備えることを特徴とするリクエスト管理装置。

【請求項6】

請求項１記載のステートレスコアネットワークシステムの管理層に適用されるリクエスト管理方法であって、
リクエストを送信した端末に関する情報に基づいて、受信した前記リクエストに対する処理を判定する工程と、
前記リクエストに対して実行すると判定された場合、前記リクエストの内容に応じたソフトウェアへ転送する工程と、を含むことを特徴とするリクエスト管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、移動通信システムに用いられ、端末から送信されるリクエストの処理にステートを必要としないステートレスコアネットワークシステム、リクエスト管理装置およびリクエスト管理方法に関する。

【背景技術】

【0002】

非特許文献１に記載の第５世代移動通信システム（５Ｇ）では、ユーザ端末（UE：User Equipment）、ＲＡＮ（Radio Access Network）、コアネットワーク（CN：Core Network）から構成される。ＲＡＮは、ＵＥと通信を行なう無線アンテナの制御や無線信号とパケット信号の変換など、無線通信区間に関する制御を行なう。コアネットワークは、ＵＥの接続認証やＵＥの通信時における通信パケットの通り道となる通信セッションの構築・変更・開放等の制御、ＵＥの移動に伴う通信セッション更新等の移動管理制御等、５Ｇ全体にまたがる制御を行なう。

【0003】

非特許文献１では、複数のネットワーク機能（NF ：Network Function）と呼ばれる機能部の集合体としてコアネットワークを定義している。ネットワーク機能としてはAccess and Mobility Management Function（AMF）やSession Management Function（SMF）等が挙げられる。各ネットワーク機能はＵＥのステートやポリシーなどのＵＥ情報を部分的に保持し、保持する情報を用いてコアネットワーク内で特定の処理を行なう。

【0004】

しかしながら、非特許文献１では、コアネットワーク内の各ネットワーク機能でステートを保持することから、システムの耐障害性やスケール性が低下してしまうことが課題として挙げられる。この課題に対して、非特許文献２では、図８に示される受付層、処理層および保持層からなる３層のステートレスコアネットワークを提案している。

【0005】

非特許文献２の３層ステートレスコアネットワークでは、受付層としてＵＥからのリクエストを受け付けるメッセージキュー（MQ）、処理層としてリクエストに対応する一連の処理を実行するFunction（Fn）と呼ばれる複数のソフトウェア、保持層として各種ＵＥ情報を一律で保持する中央集権型のデータベースから構成される。メッセージキューがＵＥからリクエストを受け取り、処理に適したＦｎに転送することでリクエストが処理される。この際、ＦｎがＵＥの処理情報を事前に保持しない。すなわち、Ｆｎがステートレスであるため、Ｆｎが故障した場合に、代わりのＦｎであってもリクエストの処理が容易に実施できる。

【先行技術文献】

【非特許文献】

【0006】

【非特許文献1】3GPP, System architecture for the 5G System(5GS). Technical Specification(TS) 23.501

【非特許文献2】渡邊大記，「プロシージャ型処理を用いたステートレスな5Gコアネットワークの実現」，電子情報通信学会、ネットワークシステム研究会，2022年12月， NS2022-139，pp.54-59

【発明の概要】

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

【0007】

ＵＥから短い期間で同じ内容のリクエストを複数受信した場合に、従来のステートフルなコアネットワークでは、前後のリクエストの状態に応じてリクエストの破棄や待機もしくはＵＥへの一時応答やエラー応答等、適切に対応することができる。しかしながら、非特許文献２に記載の３層ステートレスコアネットワークでは、処理層でステートを保持しないため、前後のリクエストの状態に応じて適切に制御することができない。

【0008】

そのため、非特許文献２に記載の３層ステートレスコアネットワークは、図９に示すように、リクエストの応答待ちの間に、先に送られたリクエストのキャンセルや、再送されたリクエストの一時的な保持もしくは破棄等の制御を行なわずに他のＦｎへ転送してしまうため、処理層で処理の重複が連鎖的に発生してしまう。

【0009】

これにより、アクティブなＵＥの数が多いときや災害時などＵＥからのリクエストが増加するときなど、コアネットワーク内の処理量が増加しリクエストに対する応答遅延が増える場合に、コアネットワークの処理資源が不足するおそれがある。

【0010】

本発明は、このような事情に鑑みてなされたものであり、移動通信システムに用いられ、端末から送信されるリクエストの処理にステートを必要としないステートレスコアネットワークにおいて、同一のＵＥから複数のリクエストを短時間に受けた際に、適切に制御を行なうことを可能にするステートレスコアネットワークシステム、リクエスト管理装置およびリクエスト管理方法を提供することを目的とする。

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

【0011】

（１）上記の目的を達成するため、本発明は以下のような手段を講じた。すなわち、本発明のステートレスコアネットワークシステムは、移動通信システムに用いられ、端末から送信されるリクエストの処理にステートを必要としないステートレスコアネットワークシステムであって、前記端末から送信される前記リクエストを受け付ける受付層と、前記受付層から前記リクエストを受信し、前記端末の状況を把握して前記リクエストを管理する管理層と前記管理層から転送される前記リクエストを、その種類に応じて処理する複数のソフトウェアを有する処理層と、前記端末に関する情報を保持し、前記処理層に前記情報を提供する保持層と、を備え、前記管理層は、前記端末の状況に基づいて前記リクエストに対する処理を判定し、前記リクエストを実行すると判定された場合、前記リクエストの内容に応じたソフトウェアへ転送することを特徴とする。

【0012】

これにより、リクエストの処理にステートを必要としないステートレスコアネットワークシステムであっても、管理層において端末の状況を把握してリクエストを管理するから、同一のＵＥから複数のリクエストを短時間に受けた際に、適切に制御を行なうことができる。また、管理層において端末の状況に基づいてリクエストに対する処理を判定し、リクエストを実行すると判定された場合、リクエストの内容に応じたソフトウェアへ転送するから、処理層でスムーズにリクエストを処理することができる。

【0013】

（２）また、上記（１）記載のステートレスコアネットワークシステムにおいて、前記管理層は、前記端末の状況を把握するために、前記保持層から前記端末に関する情報を取得することを特徴とする。

【0014】

これにより、管理層で端末の状況を把握するために、保持層から端末に関する情報を取得する頻度を減らすことができ、処理速度を向上させることができる。

【0015】

（３）また、上記（１）または（２）記載のステートレスコアネットワークシステムにおいて、前記処理層は、前記保持層において前記端末に関する情報を更新する場合、前記管理層に前記端末に関する情報の更新を要求することを特徴とする。

【0016】

これにより、管理層において保持する端末に関する情報を最新の状態に保つことができる。したがって、更新されていない端末に関する情報に基づいてリクエストを管理することを防止できる。

【0017】

（４）また、上記（１）～（３）いずれかに記載のステートレスコアネットワークシステムにおいて、前記管理層は、対応する端末の前記リクエストを管理する複数のリクエスト管理部を有し、前記受付層は、少なくとも前記端末の情報に基づいて、前記受け付けたリクエストを前記いずれかの前記リクエスト管理部に転送する振り分け部を備えることを特徴とする。

【0018】

管理層がリクエスト管理部を複数有するから、障害が生じても他のリクエスト管理部で対応できる。そのため、障害によるリクエスト管理への影響を抑えることができる。また、受付層がいずれかのリクエスト管理部に転送する振り分け部を有するから、管理層が複数のリクエスト管理部を有しても適切にリクエストを管理することができる。

【0019】

（５）また、本発明のリクエスト管理装置は、上記（１）～（４）いずれかに記載のステートレスコアネットワークシステムの管理層に適用されるリクエスト管理装置であって、リクエストを送信した端末に関する情報を保持する情報保持部と、前記情報保持部に保持される情報に基づいて、前記リクエストの種類を判別する判別部と、前記リクエストを前記判別した種類に応じたソフトウェアへ転送部と、を備えることを特徴とする。

【0020】

これにより、リクエストの処理にステートを必要としないステートレスコアネットワークシステムであっても、管理層において端末の状況を把握してリクエストを管理するから、同一のＵＥから複数のリクエストを短時間に受けた際に、適切に制御を行なうことができる。また、管理層においてリクエストの種類を判別し、判別した種類に応じたソフトウェアへ転送するから、処理層でスムーズにリクエストを処理することができる。

【0021】

（６）また、本発明のリクエスト管理方法は、上記（１）記載のステートレスコアネットワークシステムの管理層に適用されるリクエスト管理方法であって、リクエストを送信した端末に関する情報に基づいて、受信した前記リクエストに対する処理を判定する工程と、前記リクエストに対して実行すると判定された場合、前記リクエストの内容に応じたソフトウェアへ転送する工程と、を含むことを特徴とする。

【0022】

これにより、端末の情報に関する情報に基づいて、リクエストの種類に応じた適切なソフトウェアへ転送することができる。

【発明の効果】

【0023】

移動通信システムに用いられ、端末から送信されるリクエストの処理にステートを必要としないステートレスコアネットワークにおいて、同一のＵＥから複数のリクエストを短時間に受けた際に、適切に制御を行なうことを可能にする。

【図面の簡単な説明】

【0024】

【図1】第一実施形態に係る移動通信システムの構成を示す構成図である。

【図2】第一実施形態に係る移動通信システムにおける初期登録要求の処理を示す構成図である。

【図3】本発明に係る移動通信システムを用いたリクエストの処理における遅延が多い処理を説明するシーケンス図である。

【図4】本発明に係る移動通信システムを用いたリクエストの処理におけるＦｎの構成を説明するシーケンス図である。

【図5】第二実施形態に係る移動通信システムの構成を示す構成図である。

【図6】第二実施形態に係る移動通信システムにおける初期登録要求の処理を示す構成図である。

【図7】第二実施形態に係る移動通信システムにおける初期登録要求の処理を示す構成図である。

【図8】従来の３層コアネットワークを用いた移動通信システムの構成を示す構成図である。

【図9】従来の３層コアネットワークを用いた移動通信システムにおける同一のＵＥから複数のリクエストを短期間に受けた状態を説明するシークエンス図である。

【図10】従来の３層コアネットワークを含む移動通信システムを用いたリクエストの処理における遅延が多い処理を説明するシーケンス図である。

【図11】従来の３層コアネットワークを含む移動通信システムを用いたリクエストの処理におけるＦｎの構成を説明するシーケンス図である。

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

【0025】

本発明者らは、図８に示す３層ステートレスコアネットワーク６００では、すべてのリクエストを処理層４００に転送していることに着目し、処理層４００に転送する前にＵＥの状況を把握してリクエストを管理する管理層を新たに設けることで、同一のＵＥから複数のリクエストを短時間に受けた際に、適切に制御を行なうことを見出し、本発明に至った。

【0026】

すなわち、本発明のステートレスコアネットワークシステムは、移動通信システムに用いられ、端末から送信されるリクエストの処理にステートを必要としないステートレスコアネットワークシステムであって、前記端末から送信される前記リクエストを受け付ける受付層と、前記受付層から前記リクエストを受信し、前記端末の状況を把握して前記リクエストを管理する管理層と前記管理層から転送される前記リクエストを、その種類に応じて処理する複数のソフトウェアを有する処理層と、前記端末に関する情報を保持し、前記処理層に前記情報を提供する保持層と、を備え、前記管理層は、前記端末の状況に基づいて前記リクエストに対する処理を判定し、前記リクエストを実行すると判定された場合、前記リクエストの内容に応じたソフトウェアへ転送することを特徴とする。

【0027】

これにより、本発明者らは、移動通信システムに用いられ、端末から送信されるリクエストの処理にステートを必要としないステートレスコアネットワークにおいて、同一のＵＥから複数のリクエストを短時間に受けた際に、適切に制御を行なうことを可能にする。

【0028】

次に、本発明の実施の形態について、図面を参照しながら説明する。説明の理解を容易にするため、各図面において同一の構成要素に対しては同一の参照番号を付し、重複する説明は省略する。

【0029】

［第１実施形態］
（移動通信システムの構成）
図１は、第１実施形態に係る移動通信システムの構成を示す構成図である。本発明の移動通信システム１０００は、ＵＥ１～ｎ、ＲＡＮ２０およびコアネットワーク１００から構成されている。

【0030】

ＲＡＮ２０は、ＵＥ１～ｎからメッセージを受信し、メッセージをステートレスな状態にしてコアネットワーク１００に向けて送信する。ＲＡＮ２０は、例えば基地局とＮ１Ｎ２ＧＷとを含み、Ｎ１Ｎ２ＧＷがＳＣＴＰアソシエーションの終端となり、Ｎ２メッセージに送信元の基地局のＩＤを付加してメッセージキューに送信する。

【0031】

コアネットワーク１００は、受付層２００、管理層３００、処理層４００および保持層５００の４層で構成される。受付層２００は、ＲＡＮ２０から受信したメッセージを管理層３００に転送するメッセージキュー２５０を有する。

【0032】

管理層３００は、リクエストの種類を判別し、リクエストの処理を判定するＵＲＭ（UE Request Manager）３１０を有する。ＵＲＭ３１０は、Ｎ２インターフェース３１１と、ＵＥ関連情報格納部３１３－１～３１３－ｎと、リクエスト共通情報格納部３１５と、判定部３１７とを有する。Ｎ２インターフェース３１１は、ＵＥ１～ｎから送信されたＮ２メッセージを解析し、Ｎ２メッセージからＵＥの識別子を取り出すとともに、Ｎ２メッセージに含まれるリクエストの種類を判別する。

【0033】

ＵＥ関連情報格納部３１３－１～３１３－ｎは個々のＵＥ１～ｎと対応するように設けられ、対象のＵＥに関する情報の一部を保持する。ＵＥ関連情報格納部３１３－１～３１３－ｎは、ＵＥに関する情報の一部を保持層５００から取得する。ＵＥ関連情報格納部３１３－１～３１３－ｎに保持される情報としては、各ＵＥから受信したリクエストの処理状況や各ＵＥのNG-AP情報、各ＵＥとの共通鍵が挙げられる。また、ＵＥ関連情報格納部３１３は、一定時間以上リクエストを受信しなかった場合、削除される仕様であることが好ましい。ＵＥ関連情報格納部３１３が削除されることによってコアネットワーク１００内の資源利用効率が高められる。

【0034】

リクエスト共通情報格納部３１５は、各種リクエストの特徴に関する情報を保持する。リクエストの特徴に関する情報としては、処理の完了までにかかる許容可能な時間やリクエストの種別間の順序、リクエストの種別間の依存関係が挙げられる。

【0035】

判定部３１７は、処理ロジックに基づいてリクエストの処理を判定する。具体的には、判定部３１７は、Ｎ２インターフェース３１１から対象のリクエストのＵＥ識別子およびリクエストの種類を取得する。そして、判定部３１７は、必要に応じて取得したＵＥ識別子に基づいて対応するＵＥ関連情報格納部３１３からリクエストの解析に必要な鍵情報等を取得する。また、判定部３１７は、キュー３１９における処理状況を取得する。判定部３１７は、ＵＥ関連情報格納部３１３から取得した情報およびキュー３１９における処理状況に基づいてリクエストを解析し、リクエスト種別を判別する。判定部３１７は、判別したリクエストの種類をリクエスト共通情報格納部３１５に送信してリクエストの特徴に関する情報を取得する。判定部３１７は、ＵＥ関連情報格納部３１３から取得した情報、キュー３１９における処理状況およびリクエスト共通情報格納部３１５から取得した情報を処理ロジックに入力し、リクエストの処理を判定する。

【0036】

処理ロジックは、入力された情報からリクエストに対する処理を判定する。処理ロジックは、まず、対象のＵＥにおけるリクエストの処理状況を確認し、判定対象のリクエストと同じ内容のリクエストが処理されていないか確認する。同じ内容のリクエストが処理されていない場合、「リクエストを実行する」と判定し、キュー３１９にリクエストを格納する。キュー３１９は適切なＦｎ４１０へリクエストを転送する。同じ内容のリクエストが処理されている場合、処理層４００に処理状況を確認し、上手く実行されていない場合には、「現在処理中のリクエストを破棄し、新たなリクエストで処理を実行する」と判定する。処理中のリクエストが順調に進んでいる場合には、「リクエストの破棄」や「リクエストの待機」と判定する。また、「リクエストを実行する」と判定した場合には、前後に受信したリクエストを考慮して処理層４００へ転送するタイミングを決定する。「リクエストの破棄」や「リクエストの待機」と判定した場合には、ＵＥに対する一時応答や暫定応答について定めてもよい。

【0037】

処理層４００は少なくとも１種類のリクエストを実行可能なＦｎ４１０－１～４１０－ｉを有する。処理層４００はＵＥから送信されたリクエストだけでなく、コアネットワーク１００内からのリクエストについても処理する。

【0038】

保持層５００は、各ＵＥに関する情報を保持する、中央集権型のデータベースを有する。保持層５００は、各ＵＥに関する情報として、Ｎ２情報、共通鍵、ステート、ポリシー、セッション情報などの他に、各ＵＥに対応するＵＲＭ３１０のエンドポイントに関する情報（ＵＲＭエンドポイント情報）を保持する。

【0039】

（リクエストの処理方法）
次に、ＵＥから送信されるリクエストの処理方法について説明する。以下では、リクエストを送信したＵＥがＵＥｎの場合について説明する。

【0040】

ＵＥｎから送信されたメッセージは、ＲＡＮ２０を通じてステートレスな状態で受付層２００に転送される。受付層２００では、メッセージキュー２５０でメッセージを受け取り、管理層３００へ転送する。管理層３００では、受付層から転送されたメッセージをＮ２インターフェース３１１で受け取り、メッセージを解析する。Ｎ２インターフェース３１１は解析結果を合わせてメッセージを判定部３１７へ転送する。

【0041】

判定部３１７は、ＵＥ識別子に基づいてＵＥ関連情報格納部３１３－ｎからＵＥｎに関する情報を取得するとともに、取得したリクエストの種類をリクエスト共通情報格納部３１５に送信してリクエストの特徴に関する情報を取得する。判定部３１７は、取得した情報を処理ロジックに入力し、リクエストの処理を判定する。リクエストを実行すると判定した場合、判定部３１７は、内容に応じて適したＦｎ４１０へリクエストを転送する。

【0042】

Ｆｎ４１０では、受信したリクエストの処理を終えるまで一連の処理を実行する。Ｆｎ４１０は、リクエストの処理にＵＥｎに関する情報が必要な場合には、データベース５１０から取得する。また、データベース５１０に保存されている情報に更新がある場合には、データベース５１０およびＵＲＭ３１０に更新要求する。データベース５１０およびＵＲＭ３１０に更新要求する具体的な方法については後述する。Ｆｎ４１０は、作成したリクエストメッセージを、ＵＥｎのＵＲＭエンドポイント情報に沿ってＵＲＭ３１０へ送信する。

【0043】

ＵＲＭ３１０は、受信したリクエストメッセージをＮ２インターフェース３１１からメッセージキュー２５０に送信する。メッセージキュー２５０はメッセージの送信元であるＲＡＮ２０に向けてリクエストメッセージを転送し、ＲＡＮ２０を通じてＵＥｎにリクエストメッセージが届けられる。

【0044】

（ＵＥ情報の更新）
次に、第１実施形態に係るＵＥに関する情報が更新されるリクエストの処理について説明する。図２は、ＵＥの初期登録要求の処理工程を含む構成図を示している。ＵＥに関する情報が更新されるリクエストとして、ＵＥｎの初期登録要求を例に挙げて説明する。

【0045】

ＵＥｎから送信された初期登録要求は、ＲＡＮ２０を通じてステートレスな状態で受付層２００に転送され、メッセージキュー２５０介して管理層３００へ転送される（Ｓ１）。初期登録要求を受け取った管理層３００は、ＵＥの初期登録を処理するＦｎ４１０－ｉへ初期登録要求を転送する（Ｓ２）。

【0046】

初期登録要求を受信したＦｎ４１０は、データベース５１０を参照および更新し（Ｓ３）、ＵＲＭ３１０に対してＵＥに関する情報の更新を要求する（Ｓ４）。管理層３００は、初期登録要求を送信したＵＥと対応するＵＥ関連情報格納部３１３を新たに作成し、その内部にＵＥに関する情報を格納する。

【0047】

これにより、データベースにおける情報の更新に合わせて、ＵＲＭで保持されるＵＥに関する情報についても更新されるため、直近の情報に基づいて管理層でリクエストの管理を行なうことができる。

【0048】

（ハンドオーバ）
ＲＡＮ２０が切り替えるＸｎハンドオーバが生じる際には、ＲＡＮ２０からコアネットワーク１００に対して通信パス切り替え要求（Path switch）が送信される。通信パス切り替え要求に含まれるＮ２情報は、ＵＲＭ３１０やデータベース５１０に保持されている情報から変更されているため、情報を更新する必要がある。

【0049】

メッセージキュー２５０を介して通信パス切り替え要求を受信したＵＲＭ３１０は、Ｎ２インターフェース３１１で識別子を取得し、通信パス切り替え要求を送信したＵＥと対応するＵＥ関連情報格納部３１３で保持される情報を更新する。

【0050】

一方でＵＲＭ３１０は、通信パス切り替え要求をＦｎ４１０へ送信し、データベース５１０で保持される情報も更新する。

【0051】

以上から本発明のコアネットワークを含む移動通信システムでは、処理層でステートを持たなくても、同一のＵＥから複数のリクエストを短時間に受けた際に、適切に制御を行なうことを可能にする。

【0052】

また、本発明のコアネットワークシステムでは、図３のように、ＵＲＭ３１０でリクエストの内容を判別してから適した処理層に転送する。そのため、データベース５１０へアクセスする回数を減らすことができ、処理速度が向上する。これに対して、従来の３層コアネットワーク６０００では、図１０に示すように、処理層４００においてリクエストの内容を判別してリクエストを処理する。そのため、リクエストの種類の判別と、リクエストを処理するタイミングでデータベース５１０からＵＥに関する情報を取得する必要がある。データベース５１０へのアクセスは遅延が大きいため、リクエストの処理速度が低下してしまう。

【0053】

また、本発明のコアネットワークでは、受付層、管理層および処理層が単一もしくは複数のサーバで実現されてもよく、個々が単一もしくは複数のサーバで実現されてもよい。受付層、管理層および処理層のうち少なくとも１つが実現されるサーバは物理サーバおよび仮想サーバのどちらでもよい。コアネットワークを基地局の近傍に位置するクラウド環境（エッジクラウド）で分散配置して運用する場合、図３のように、リクエストの識別に関する処理を中央集権型のデータベース（セントラルクラウド）を参照せずに実行できるため、制御処理の遅延を低減できる。

【0054】

また、本発明のコアネットワークでは、処理層が少なくとも１種類のリクエストを処理可能であればよいため、図４のように、リクエストの種別に合わせた細分化が可能となる。図４では、処理１用Ｆｎ４１０－１と、処理２用Ｆｎ４１０－２が複数設けられている。これに対して、従来の３層コアネットワーク６０００では、図１１に示すように、受付層２００から転送されるリクエストを受信する処理層４００が、全種類のリクエストに対応可能である必要がある。

【0055】

［第２実施形態］
次に、第２実施形態について説明する。第２実施形態の移動通信システム２０００は、管理層３００に複数のＵＲＭ３１０が含まれる点が第１実施形態と異なる。以下では、第１実施形態との相違点を中心に説明し、第１実施形態と同様の構成については同じ符号を付してその説明を省略する。

【0056】

図５は、第２実施形態に係る移動通信システムの構成を示す構成図である。コアネットワーク１０２では、管理層３００に複数のＵＲＭ３１０を含むため、受付層２００で適切なＵＲＭ３１０へ転送する機能が必要となる。受付層２００は、適切なＵＲＭ３１０へメッセージを転送するＵＬＢ（UE Load Balancer）２１０から構成される。ＵＬＢ２１０は、Ｎ２インターフェース２１１と、ＵＲＭアクセス情報格納部２２０と、メッセージキュー２５０と、を有する。

【0057】

Ｎ２インターフェース２１１は、ＲＡＮ２０から受信するメッセージを解析し、リクエストのＮ２情報の識別および転送先のＵＲＭの特定を行なう。転送先のＵＲＭの特定は、メッセージに含まれるＵＥに関する情報を送信してＵＲＭアクセス情報格納部２２０から情報を取得することで特定する。ＵＲＭアクセス情報格納部２２０内部に対象のＵＥに関する情報がない場合には、データベース５１０からＵＲＭエンドポイント情報を取得する必要がある。この際、Ｆｎを介してデータベース５１０からＵＲＭエンドポイント情報を取得してもよいし、直接データベース５１０から取得してもよい。

【0058】

図６では、Ｆｎを介してデータベース５１０からＵＲＭエンドポイント情報を取得する処理工程を示している。ＵＬＢ２１０は、ＵＲＭアクセス情報格納部２２０内部に対象のＵＥに関する情報がない場合、ＵＥ情報検索用Ｆｎ４１０－ｓへ対象となるＵＥのＵＲＭエンドポイント情報の検索を要求する（Ｔ１）。ＵＥ情報検索用Ｆｎ４１０－ｓは、データベース５１０から検索し、取得したＵＲＭエンドポイント情報をＵＬＢ２１０へ送信し、ＵＲＭアクセス情報格納部２２０における情報の更新を要求する（Ｔ２）。ＵＬＢ２１０は、取得したＵＲＭエンドポイント情報に基づいて、適切なＵＲＭへリクエストを転送する（Ｔ３）。

【0059】

ＵＲＭアクセス情報格納部２２０は、Ｎ２情報のうち、ＵＥの識別に関する情報（NG-AP等）と各ＵＥに対応するＵＲＭエンドポイント情報を保持する。メッセージキュー２５０は、Ｎ２インターフェース３１１で特定されたＵＲＭへメッセージを転送する。

【0060】

管理層３００は、複数のＵＲＭ３１０を有する。ＵＲＭ３１０は単一のＵＥと対応するように設けられてもよいし、複数のＵＥと対応するように設けられてもよい。図５では、単一のＵＥ１～ｎと対応するように、ＵＲＭ（ＵＥ１）～ＵＲＭ（ＵＥｎ）３１０－１～３１０－ｎを設けられている。各ＵＲＭ３１０では、ＵＥ関連情報格納部３１３、リクエスト共通情報格納部３１５、判定部３１７およびキュー３１９を有する。キュー３１９は受付層２００からのメッセージを受信する。

【0061】

（リクエストの処理方法）
次に、第２実施形態に係るリクエストの処理方法として、ＵＥｎから送信されるリクエストの処理方法について説明する。

【0062】

受付層２００は、ＵＥｎから送信されたメッセージをＮ２インターフェース２１１で受け取り、メッセージを解析する。Ｎ２インターフェース２１１は送信元がＵＥｎであることを特定し、ＵＲＭアクセス情報格納部２２０からＵＥｎのＵＲＭエンドポイント情報を取得する。メッセージキュー２５０を介して適切なＵＲＭ（ＵＥｎ）４１０－ｎにメッセージを転送する。ＵＲＭ３１０－ｎでは、ＵＥｎに関する処理状況やリクエストの特徴に基づいてリクエストに対する処理を判定し、リクエストを実行する場合にはリクエストの種類に適したＦｎ４１０へ転送する。

【0063】

（ＵＥの登録要求）
次に、第２実施形態に係るＵＥｎの初期登録要求について説明する。図７は、第２実施形態に係るＵＥの初期登録要求の処理工程を含む構成図を示している。第２実施形態では、ＵＲＭを複数有するため、ＵＥの収容先となるＵＲＭを定めるか、ＵＲＭを新規生成する必要がある。以下では、ＵＲＭを新規生成する場合の初期登録要求について説明する。

【0064】

管理層３００では、新しいＵＲＭ（ｎｅｗ）３１０－ｗを予め作成する（Ｕ１）。受付層２００は、Ｎ２インターフェース２１１においてＵＥｎから送信された初期登録要求を受信し、収容先となるＵＲＭがない場合、ＵＲＭ（ｎｅｗ）３１０－ｗに転送する（Ｕ２）。ＵＲＭ（ｎｅｗ）３１０－ｗは、ＵＥｎに関するＮ２情報とＵＲＭエンドポイント情報をＵＲＭアクセス情報格納部２２０に格納するように、ＵＬＢ２１０に要求する（Ｕ３）。

【0065】

これらとは別に、ＵＲＭ（ｎｅｗ）３１０－ｗは、登録用Ｆｎ４１０－ｒにも初期登録要求を転送する。登録用Ｆｎ４１０－ｒは、データベース５１０に登録処理を要求する。（Ｕ４）そして、登録用Ｆｎ４１０－ｒは、ＵＲＭ３１０に対して一定時間以上リクエストを受信していないＵＥに関する情報の削除を要求する（Ｕ５）。このとき、ＵＲＭ３１０ごと削除してもよいし、ＵＥに関する情報のみ削除してもよい。ＵＥに関する情報のみ削除する場合には、ＵＥに関する情報を削除したＵＲＭ３１０に新たなＵＥを収容してもよい。

【0066】

（ハンドオーバ）
第２実施形態では、ＵＲＭ３１０およびデータベース５１０に加えて、さらにＵＬＢ２１０でＮ２情報を有する。そのため、ＵＲＭ３１０およびデータベース５１０における情報更新に加えて、Ｎ２インターフェース２１１で通信パス切り替え要求を検知し、ＵＲＭアクセス情報格納部２２０に保持される情報も更新する。

【0067】

このように、本発明のコアネットワークシステムでは、移動通信システムに用いられ、端末から送信されるリクエストの処理にステートを必要としないステートレスコアネットワークにおいて、同一のＵＥから複数のリクエストを短時間に受けた際に、適切に制御を行なうことを可能にする。

【符号の説明】

【0068】

１～ｎ ＵＥ
２０ ＲＡＮ
１００、１０２ コアネットワーク
２００ 受付層
２１０ ＵＬＢ
２１１ Ｎ２インターフェース
２２０ ＵＲＭアクセス情報格納部
２５０ メッセージキュー
３００ 管理層
３１０ ＵＲＭ
３１０－１～３１０－ｎ ＵＲＭ（ＵＥ１）～ＵＲＭ（ＵＥｎ）
３１０－ｗ ＵＲＭ（ＵＥｎｅｗ）
３１１ Ｎ２インターフェース
３１３ ＵＥ関連情報格納部
３１３－１～３１３－ｎ ＵＥ１関連情報格納部～ＵＥｎ関連情報格納部
３１５ リクエスト共通情報格納部
３１７ 判定部
３１９ キュー
４００ 処理層
４１０ Ｆｎ
４１０－１～４１０－ｉ 処理１用Ｆｎ～処理ｉ用Ｆｎ
４１０－２ 処理２用Ｆｎ
４１０－ｓ ＵＥ情報検索用Ｆｎ
４１０－ｒ 登録用Ｆｎ
５００ 保持層
５１０ データベース
６００ ３層コアネットワーク
１０００、２０００ 移動通信システム
６０００ （従来の）移動通信システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】