JP7526713B2 - ネットワーク装置及びその制御方法、通信システム並びにプログラム - Google Patents

Description

本発明は、コアネットワークに配置されるネットワーク装置及びその制御方法、通信システム並びにプログラムに関する。

モバイル通信システム（移動体通信システム）において、ユーザ端末（ＵＥ）は、無線アクセスネットワーク（ＲＡＮ）を経由して、コアネットワーク（モバイルコア）にアクセスする。モバイルコアは、ユーザデータの伝送を担うユーザプレーン（Ｕ－Ｐｌａｎｅ）機能と、モビリティ管理やセッション管理等の制御を担う制御プレーン（Ｃ－Ｐｌａｎｅ）機能を有する。モバイルコアのセッション制御機能は、ユーザセッション情報の管理、及び通信経路であるベアラの確立及び解放を行う。モバイルコアにおいて、ユーザデータの伝送はゲートウェイ（ＧＷ）によって行われる。ユーザ端末がデータ通信のために接続するＧＷの選択等のベアラ設定は、セッション制御機能によって行われる。なお、第５世代（５Ｇ）モバイル通信システムにおいて、ＧＷは、「ＵＰＦ（User Plane Function）」と称され、セッション制御機能は「ＳＭＦ（Session Management Function）」と称される。非特許文献１及び２には、このようなモバイル通信システムが規定されている。

将来のモバイル通信システムでは、転送されるユーザデータの大容量化が見込まれる。非特許文献３には、複数のベアラを用いて通信を行う技術が記載されている。このような技術は、大容量通信の実現のために活用されうる。また、非特許文献４には、第６世代（６Ｇ）モバイル通信システムにて実用化が期待される「Cell-free Massive MIMO」を規定している。セルフリー（Cell-free）アーキテクチャは、１つの基地局ＣＰＵと複数のアクセスポイント（ＡＰ）から成る。このようなアーキテクチャにおいて、ＵＥは、複数のＡＰとベアラを確立して通信を行うことが想定される。

3GPP TS 23.501 V17.0.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 17)" 3GPP TS 23.502 V17.0.0, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 17)" IEEE/ACM Transactions on Networking (Volume: 14, Issue: 6, Dec. 2006), "Multi-Path TCP: A Joint Congestion Control and Routing Scheme to Exploit Path Diversity in the Internet" IEEE Transactions on Wireless Communications (Volume: 16, Issue: 3, March 2017), "Cell-Free Massive MIMO Versus Small Cells"

上述のようなモバイル通信システムにおいて、転送されるユーザデータの容量がＧＷの容量を超えると、ユーザ端末によるデータ通信にデータロスが発生する可能性が高まる。また、輻輳によるデータロスが発生すると、ＴＣＰの輻輳制御により、データ通信がスロースタートフェーズから輻輳回避フェーズに移行する。輻輳回避フェーズでは、データ転送量の増加が線形になる。例えば数百Ｇｂｐｓを必要とする大容量通信において、所望の速度に到達する前にデータロスが発生し、輻輳回避フェーズに移行してしまうことで、所望の通信速度を速やかに達成できない可能性がある。

大容量通信の実現のために、上述のように複数のベアラから成る通信セッションを確立するマルチセッション技術をモバイル通信システムに適用する場合、データ通信に使用されるベアラの本数を決定する機構が必要になる。例えば、帯域の不足の検知に応じてベアラを逐次追加する場合、ベアラの確立に一定の時間を要するため、アプリケーションの通信等のデータ通信を開始するまでに時間がかかりうる。

また、輻輳回避フェーズに移行する通信セッションは、通信中のデータロスの有無に依存するため、事前に必要以上に多数のベアラを確立しない限り、所望の通信速度を達成することは難しい。一方で、大量の通信セッションを１つのユーザ端末又はそのアプリケーションに割り当てるには、モバイルコアの処理性能が不足する可能性がある。

そこで、本発明は、１つのユーザ端末が１つ以上のＡＰとの間にデータ通信用の複数のベアラを確立することが可能なモバイル通信システムにおいて、より効率的なユーザ端末の収容を可能にする技術を提供することを目的とする。

本発明の一態様に係るネットワーク装置は、複数のアクセスポイント（ＡＰ）に接続可能なユーザ端末に対して、当該ユーザ端末がデータ通信用に確立する複数のベアラのそれぞれを収容するＡＰとゲートウェイ（ＧＷ）とを決定する、コアネットワークに配置されたネットワーク装置であって、前記コアネットワークに配置された複数のＧＷのそれぞれに生じている負荷を示す負荷情報を、各ＧＷから取得する取得手段と、複数のベアラから成る通信セッションの確立を求める確立要求が前記ユーザ端末から行われると、前記取得手段によって取得された前記負荷情報と、前記複数のＡＰ及び前記複数のＧＷに関連するネットワーク構成情報とに基づいて、１つ以上のアクティブベアラ及び１つ以上のスタンバイベアラを含む、確立するベアラの本数と、当該本数のベアラのそれぞれを収容するＡＰ及びＧＷを決定する決定手段と、前記決定手段による決定に従って、前記ユーザ端末によるデータ通信用のベアラを確立する処理の実行を、前記コアネットワークに配置されたセッション制御機能に対して要求する要求手段と、を備えることを特徴とする。

本発明によれば、１つのユーザ端末が１つ以上のＡＰとの間にデータ通信用の複数のベアラを確立することが可能なモバイル通信システムにおいて、より効率的なユーザ端末の収容が可能になる。これにより、モバイル通信システムにおいてユーザ端末による大容量通信を実現することを可能にする。

モバイル通信システムの構成例を示す図 セレクタの機能構成例を示すブロック図 セレクタのハードウェア構成例を示すブロック図 ＧＷの機能構成例を示すブロック図 バルクセッション確立処理のシーケンスを示すシーケンス図 ベアラのアクティブ化制御のシーケンスを示すシーケンス図

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態で説明されている特徴の組み合わせの全てが発明に必須のものとは限らない。実施形態で説明されている複数の特徴のうち二つ以上の特徴が任意に組み合わされてもよい。また、同一若しくは同様の構成には同一の参照番号を付し、重複した説明は省略する。

本実施形態では、ユーザ端末（ＵＥ）による大容量通信（例えば、ＵＥに搭載されたアプリケーションによる大容量通信）を実現するために、モバイル通信システムは、ＵＥが複数のベアラを確立して使用できるように構成される。本明細書において、複数のベアラから成る通信セッションを確立することを「バルクセッション確立」と称する。

また、本実施形態では、ＵＥが確立できるベアラとして、２種類のベアラ（「アクティブベアラ」及び「スタンバイベアラ」）を定義する。「アクティブベアラ」は、データ伝送に使用されるベアラを示す。「スタンバイベアラ」は、ベアラとして確立されているがデータ伝送に使用できないベアラであって、アクティブ化が行われることでアクティブベアラへの切り替えが可能なベアラである。例えば、帯域が不足することが明らかになり、データ伝送用のベアラの追加が必要になった場合に、予め確立しておいたスタンバイベアラのアクティブ化が行われる。これにより、ベアラ（アクティブベアラ）を新たに確立するよりも、速やかにベアラの追加を行うことが可能である。なお、本実施形態では、同じ組み合わせのＡＰ－ＧＷ間に複数のベアラを確立可能であるものとする。

＜モバイル通信システムの構成＞
図１は、本実施形態に係るモバイル通信システムの構成例を示している。図１に示すように、本実施形態のモバイルコア３０には、移動管理機能（移動管理部）３１、セッション制御機能（セッション制御部）３２、及び複数のＧＷ３４に加えて、セレクタ（Selector）３４が新たに導入される。本実施形態のセレクタ３４は、複数のＡＰに接続可能なＵＥに対して、当該ＵＥがデータ通信用に確立する複数のベアラのそれぞれを収容するＡＰとＧＷとを決定する、コアネットワーク（モバイルコア３０）に配置されたネットワーク装置の一例である。

モバイル通信システムは、無線基地局の機能を提供する構成として、複数のアクセスポイント（ＡＰ）２０を備えている。複数のＡＰ２０は、モバイルコア３０に接続される。本実施形態のモバイル通信システムには、上述のセルフリーアーキテクチャが適用されている。このため、ＵＥ１０は、複数のＡＰ２０に接続し、当該接続したＡＰ２０を介してモバイルコア３０にアクセスし、更にデータネットワーク４０にアクセスすることが可能である。

セッション制御部３２は、ユーザセッション情報の管理、及び通信経路であるベアラの確立及び解放を行うように構成される。本実施形態では、セッション制御部３２は、ＵＥ１０がデータ伝送に使用するベアラを、セレクタ３３によって選択されたＡＰ２０及びＧＷ３４に収容するように、ベアラの確立を行う。セレクタ３３は、ＵＥ１０に対して確立するベアラ（アクティブベアラ及びスタンバイベアラ）の本数の決定、確立する各ベアラの収容先の選択、及びベアラタイプの切り替えの判断を行うように構成される。

＜セレクタの構成＞
図２は、セレクタ３３の機能構成例を示すブロック図である。図２に示すように、セレクタ３３は、ベアラ本数決定部２０１、収容先選択部２０２、ベアラ切替判断部２０３、及び通信部２０４を有する。

ベアラ本数決定部２０１は、ＵＥ１０に対して確立するベアラ（アクティブベアラ及びスタンバイベアラ）の本数を決定する機能を提供する。収容先選択部２０２は、ＵＥ１０に対して確立するベアラの収容先となるＡＰ及びＧＷを選択（決定）する機能を提供する。ベアラ切替判断部２０３は、ＵＥ１０に対して確立済みのスタンバイベアラのアクティブ化するか（アクティブベアラに切り替えるか）を判断する機能を提供する。通信部２０４は、モバイルコアの他のネットワーク機能（セッション制御部３２及びＧＷ３４）と通信する機能を提供する。

また、セレクタ３３は、以下の情報を記憶装置３０４（図３）に保持する。
‐ＧＷ負荷情報
‐ＮＷ構成（ネットワーク構成）情報
‐ユーザセッション情報
‐ベアラ確立拒否時の原因値（Cause Value）

ＮＷ構成情報は、複数のＡＰ及び複数のＧＷに関連するネットワーク構成情報の一例であり、例えば、ＮＷトポロジ、無線リンク容量、及びＡＰ－ＧＷ間のリンク容量を含む。なお、ＡＰ－ＧＷ間のリンク容量は静的に設定されうる。ユーザセッション情報は、例えば、各ベアラのＩＤ、通信セッションのセッションＩＤとそれに関連付けられたベアラＩＤリスト（マップ）、各ベアラの収容先ＡＰ、収容先ＧＷ、及び、通信セッションに対してユーザが要求している通信速度、を含む。ＧＷ負荷情報は、ＧＷの空き容量（空きリンク容量）を示す情報を含みうる。

セレクタ３３は、ベアラの確立が拒否された場合の原因を示す原因値（Cause Value）を保持する。この原因値は、ベアラ切替判断部２０３による、スタンバイベアラのアクティブ化に関する判断に使用されうる。また、セレクタ３３は、ＧＷに生じている負荷を示すＧＷ負荷情報を、定期的に各ＧＷから取得して保持する。ＧＷ負荷情報の取得周期は、オペレータのポリシに従って設定される（例えば、３０秒周期）。

なお、セレクタ３３の各機能は、モバイルコア３０内のネットワーク機能のいずれかに包含されてもよい。

セレクタ３３は、汎用サーバとして構成される場合、一例として、図３に示されるようなハードウェア構成を有する。具体的には、セレクタ３３は、ＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、ＨＤＤ等の記憶装置（ストレージ）３０４、及び通信デバイス３０５を備える。

セレクタ３３では、例えばＲＯＭ３０２、ＲＡＭ３０３及び記憶装置３０４のいずれかに格納された、上述の各機能を実現するプログラムがＣＰＵ３０１によって実行される。なお、ＣＰＵ３０１は、ＡＳＩＣ（特定用途向け集積回路）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）、ＤＳＰ（デジタルシグナルプロセッサ）等の１つ以上のプロセッサによって置き換えられてもよい。通信デバイス３０５は、ＣＰＵ３０１による制御下で、外部装置との通信を行うための通信インタフェースである。セレクタ３３は、それぞれ接続先が異なる複数の通信デバイス３０５を有していてもよい。

セッション制御部３２及びＧＷ３４も、セレクタ３３と同様のハードウェア構成を有していてもよい。また、セッション制御部３２、ＧＷ３４及びセレクタ３３は、本明細書で説明する各機能を実行する専用のハードウェアを備えてもよいし、一部をハードウェアで実行し、プログラムを動作させるコンピュータでその他の部分を実行してもよい。また、全機能がコンピュータとプログラムにより実行されてもよい。

＜ＧＷの構成＞
図４は、ＧＷ３４の機能構成例を示すブロック図である。ＧＷ３４は、ＡＰ２０とデータネットワーク４０との間のユーザデータの伝送に関連する既存機能（図示せず）に加えて、負荷監視部４０１、負荷通知部４０２、及び通信部４０３を有する。負荷監視部４０１は、ＧＷ３４に生じている負荷を監視し、負荷を示す負荷情報を出力する。負荷通知部４０２は、負荷監視部４０１から出力される負荷情報を、所定の通知頻度でセレクタ３３へ通知する。この通知頻度は、オペレータのポリシに従って設定される。

＜ＵＥの機能＞
本実施形態のモバイル通信システムにおいて、ＵＥ１０は下記の機能を有する。ＵＥ１０は、アプリケーション（以下、「アプリ」と称する。）による通信等の大容量通信を開始する際、複数のベアラから成る通信セッションを確立するためのバルクセッション確立要求を、モバイルコア３０へ送信する。ＵＥ１０は、送信する要求メッセージに以下の情報を含める。
‐所望の通信速度
‐ＵＥ１０が接続済みのＡＰのリスト
‐接続候補ＡＰとその電波強度のリスト
‐アプリ用の通信セッションのために確立可能なベアラ数の上限値

なお、接続候補ＡＰとは、ＡＰからの電波を受信可能であるが、ＵＥとの接続は確立されていないＡＰを指す。ＵＥ１０は、このリストを適宜更新する能力を有する。

本実施形態のモバイル通信システムには、上述のセルフリーアーキテクチャが適用されている。このため、ＵＥ１０は、セルフリーの概念に則って、複数のＡＰに接続してデータ通信を行うことが可能であり、即ち、複数のＡＰとの間で複数のベアラを確立することができるように構成される。なお、ＵＥ１０は、１つのＡＰとの間に複数のベアラを確立できるように構成される。

ＵＥ１０は、バルクセッション確立時に、モバイルコア３０から、ベアラごとの通信速度期待値を受信し、それを保存する。ＵＥ１０は、大容量通信用に確立したベアラが輻輳回避モードに入り、保存済みの通信速度期待値を達成できないと判断した場合、モバイルコア３０のセッション制御部３２に対して、その旨を通知する。この通知により、セッション制御部３２は、（後述する図６の手順で）ＵＥ１０についての通信セッションのアクティブ化制御を開始する。

また、ＵＥ１０に搭載されているアプリ（以下、「端末アプリ」とも称する。）には、所望の通信速度が設定されている。端末アプリは、バルクセッション確立要求の送信時に、ＵＥ１０と連携して、所望の通信速度を示す情報を、要求メッセージに含めて送信する機能を有する。

＜バルクセッション確立処理＞
図５は、本実施形態に係るモバイル通信システムにおける、ＵＥ１０のためのバルクセッション確立処理のシーケンスを示すシーケンス図である。図５に示す処理の開始時には、ＵＥ１０が以下の状態にあることを前提としている。ＵＥ１０は、電源オン／機内モードオフ等をトリガとして、既に通信セッションを確立している。なお、多くの場合、１つの通信セッションに１つのベアラが設定される。これに伴い、ＵＥ１０は、１つ以上のＡＰと接続済みの状態にある。

まずＳ５０１で、ＵＥ１０は、ユーザによる端末アプリの操作等により、複数のベアラを用いる通信（大容量通信）の開始を決定する。

この決定に従って、Ｓ５０２で、端末アプリは、確立済みの通信セッションを介して、通信相手となるアプリサーバ５０が、複数のベアラを用いる通信に対応しているか否か（即ち、マルチセッションに対応しているか否か）を確認する。端末アプリは、例えば、Multi-path TCPを活用する場合には3-way handshakeを行うことで、このような確認を行う。ただし、例えば、複数のベアラを用いる通信にアプリサーバ５０が対応しているか否かを既に確認済みであるか、又は複数のベアラを用いる通信にアプリサーバ５０が対応していることが端末アプリに予め設定されている場合には、Ｓ５０２の確認処理は省略されてもよい。

次にＳ５０３で、ＵＥ１０は、バルクセッションの確立要求をセッション制御部３２へ送信する。この要求メッセージには、以下の情報が含められる。
‐所望の通信速度
‐ＵＥ１０が接続済みのＡＰのリスト
‐接続候補ＡＰとその電波強度のリスト
‐最大ベアラ数
‐通信セッションに関連付けられた情報（例：セッションＩＤ、Ｓ－ＮＳＳＡＩ（スライス決定情報）、及びＤＮＮ（出口ネットワーク））

なお、最大ベアラ数は、予め設定されている、ＵＥ１０が使用可能な最大ベアラ数から、ＵＥ１０が使用中のベアラ数を差し引いた数（即ち、この通信セッションのために用意可能なベアラ数の上限値）である。また、所望の通信速度は、端末アプリに予め設定されている。

バルクセッション確立要求を受信したセッション制御部３２は、Ｓ５０４で、ＵＥ１０の端末アプリによるバルクセッション確立の可否を確認する。この確認処理は、オペレータのポリシ（例えば、最大収容ユーザ数を超えたら受け付けない、又は、サービス提供可能ＡＰが接続候補ＡＰのリストに存在しない場合は受け付けない）及び契約者情報（サービス契約の有無）を参照することで行われる。

セッション制御部３２は、上記の確認の結果、バルクセッション確立不可と判断した場合、Ｓ５０５ａで、バルクセッション確立拒否を示す応答メッセージをＵＥ１０へ送信し、図５のシーケンスによる処理を終了する。一方、セッション制御部３２は、バルクセッション確立可能と判断した場合、Ｓ５０５ｂで、端末アプリの通信要件（例えば、Ｓ－ＮＳＳＡＩ及びＤＮＮ）に応じて、ベアラの収容先候補となるＡＰ及びＧＷを選択（決定）する。例えば、端末アプリが専用スライスを使用する場合、そのスライスのＩＤ（Ｓ－ＮＳＳＡＩ）に対応しているＧＷを、収容先候補として選択する。

次にＳ５０６で、セッション制御部３２は、セレクタ３３に対して、確立するベアラの本数の決定、各ベアラの収容先となるＡＰ及びＧＷの選択、及び各ベアラのタイプ（アクティブ／スタンバイ）の選択を要求するための処理要求メッセージを送信する。この処理要求メッセージには、以下の情報が含められる。
‐セッションＩＤ
‐所望の通信速度
‐ＵＥ１０が接続済みのＡＰのリスト
‐接続候補ＡＰとその電波強度のリスト
‐最大ベアラ数
‐ＡＰ及びＧＷの収容先候補

Ｓ５０７で、セレクタ３３は、処理要求メッセージを受信すると、受信した当該メッセージに従って処理を実行する。具体的には、セレクタ３３は、記憶装置３０４に保持している情報（例えば、ＧＷの空き容量、ＡＰ－ＧＷ間の物理的な帯域、ＡＰ－ＵＥ間の無線区間の帯域、及び／又は当該無線区間のロス率）に基づいて、ＵＥが接続可能なＡＰ及びＧＷについてのそれぞれの組み合わせでベアラを確立した場合の、ベアラ１本当たりの通信速度期待値を導出する。例えば、通信速度期待値は、ＵＥ－ＡＰ１－ＧＷ１のベアラについては１０［Ｇｂｐｓ］、ＵＥ－ＡＰ１－ＧＷ２のベアラについては５［Ｇｂｐｓ］等と導出される。

通信速度期待値の導出後、セレクタ３３は、Ｓ５０７の処理の完了後の空き容量が、複数のＧＷ間で可能な限り均等になるように、ＧＷの空き容量に応じて、確立するアクティブベアラの収容先となるＡＰ及びＧＷを決定（選択）する。収容先ＡＰ及びＧＷは、受信した処理要求メッセージに含まれる収容先候補から選択される。更に、セレクタ３３は、端末アプリの所望の通信速度に基づいて、確立するアクティブベアラの本数を決定する。例えば、セレクタ３３は、アクティブベアラの本数を、当該所望の通信速度の達成が期待される本数に決定する。なお、セレクタ３３は、オペレータのポリシに従って冗長の本数を追加して、アクティブベアラの本数を決定してもよい。

また、セレクタ３３は、確立するスタンバイベアラの本数とその収容先ＡＰ及びＧＷも決定する。この決定は、例えば、端末アプリの所望の通信速度と、決定されたアクティブベアラの本数と、各アクティブベアラの収容先ＡＰ及びＧＷとに基づいて、オペレータのポリシに従って行われうる。例えば、アクティブベアラと同じ本数のスタンバイベアラを用意し、アクティブベアラの収容先ＡＰ及びＧＷの組み合わせごとに、同じ本数のスタンバイベアラを配置するように、上記の決定が行われうる。

このように、セレクタ３３は、複数のベアラから成る通信セッションの確立を求める確立要求（バルクセッション確立要求）がＵＥ１０から行われると（Ｓ５０３）、Ｓ５０７において、取得された負荷情報と、ＮＷ構成情報とに基づいて、１つ以上のアクティブベアラ及び１つ以上のスタンバイベアラを含む、確立するベアラの本数と、当該本数のベアラのそれぞれを収容するＡＰ及びＧＷを決定する。また、この決定は、確立するベアラごとに、Ｓ５０５ｂにおいてセッション制御機能３２によってＵＥ１０に対して選択された収容先候補のＡＰ及びＧＷのうちで当該ベアラを収容するＡＰ及びＧＷを選択することによって行われる。

Ｓ５０７の処理の完了後、Ｓ５０８で、セレクタ３３は、受信した処理要求メッセージに対する応答メッセージをセッション制御部３２へ送信する。この応答メッセージには、
セッションＩＤとともに、Ｓ５０７において決定したベアラの本数分、各ベアラに関する以下の情報が含められる。
‐ベアラＩＤ
‐ベアラタイプ（アクティブ／スタンバイ）
‐収容先ＧＷのＩＤ
‐収容先ＡＰのＩＤ
‐ベアラの通信速度期待値
なお、セレクタ３３は、新たに確立すべきベアラが無いと判断した場合、その旨の情報を含む応答メッセージを送信する。

セッション制御部３２は、新たに確立すべきベアラが無いことを示す情報を含む応答メッセージをセレクタ３３から受信すると、Ｓ５０９ａで、その旨を示すバルクセッション確立応答メッセージをＵＥ１０へ送信し、図５のシーケンスによる処理を終了する。一方、セッション制御部３２は、確立すべきベアラに関する上記の情報を含む応答メッセージを受信すると、ベアラごとに、Ｓ５０９ｂ～Ｓ５１７の処理を実行する。なお、Ｓ５０９ｂ～Ｓ５１７の処理は、複数のベアラについて並列に実行されてもよい。

Ｓ５０９ｂ～Ｓ５１４の処理は、Ｓ５０７におけるセレクタ３３の決定（選択）に従って、ＵＥ－ＡＰ間及びＡＰ－ＧＷ間にベアラを確立するベアラ確立処理である。

まずＳ５０９ｂで、セッション制御部３２は、ＵＥ－ＡＰ間のベアラの確立を求めるベアラ確立要求をＡＰ２０へ送信する。このベアラ確立要求は、セッションＩＤ、ベアラＩＤ、ベアラタイプ、ＧＷのＩＤ、及び通信速度期待値、を含む。なお、ＡＰ２０がベアラ確立要求を拒否する場合、以下のＳ５１０及びＳ５１１はスキップされる。

Ｓ５１０で、ＡＰ２０は、ベアラ確立要求をＵＥ１０へ送信する。このベアラ確立要求は、セッションＩＤ、ベアラＩＤ、ベアラタイプ、及び通信速度期待値、を含む。ＵＥ１０は、ベアラ確立要求を受信したタイミングで、ベアラＩＤと通信速度期待値とを対応付けて保存する。ＵＥ１０が、保存した情報に基づいて、端末アプリによる通信のために通信速度が不足していると判断した場合等に、後述する図６に示すシーケンスによる、ベアラのアクティブ化制御が行われる。

Ｓ５１１で、ＵＥ１０は、受信したベアラ確立要求に従ってベアラの確立を試み、その結果を示すベアラ確立応答をＡＰ２０へ送信する。ベアラの確立に成功した場合、このベアラ確立応答は、セッションＩＤ、ベアラＩＤ、及びベアラ確立結果、を含む。なお、ＵＥ１０が原因となりベアラの確立に失敗した場合、ベアラ確立応答には、その旨を示す原因値（Cause Value）も含められる。ＵＥ１０からのベアラ確立応答の受信に応じて、ＡＰ２０は、Ｓ５１２で、ＵＥ－ＡＰ間のベアラ確立結果を示すベアラ確立応答をセッション制御部３２へ送信する。

ここで、ＵＥ－ＡＰ間のベアラ確立に失敗した場合、以下のＳ５１３及びＳ５１４はスキップされる。また、Ｓ５０９ｂ及びＳ５１２において、ＡＰ２０が原因となりベアラの確立に失敗した場合、ＡＰ２０は、その旨を示す原因値（Cause Value）もベアラ確立応答に含めてセッション制御部３２へ送信する。また、Ｓ５１１においてＵＥ１０から原因値を受信した場合、セッション制御部３２は、受信した原因値をベアラ確立応答に含めてセッション制御部３２へ送信する。セッション制御部３２は、ＡＰ２０から受信した各原因値を、対応するセッションＩＤ及びベアラＩＤに関連付けて管理する。

次にＳ５１３で、セッション制御部３２は、ＡＰ－ＧＷ間のベアラの確立を求めるベアラ確立要求をＧＷ３４へ送信する。このベアラ確立要求は、セッションＩＤ、ベアラＩＤ、ベアラタイプ、及びＡＰのＩＤ、を含む。

Ｓ５１４で、ＧＷ３４は、受信したベアラ確立要求に従ってベアラの確立を試み、その結果を示すベアラ確立応答をセッション制御部３２へ送信する。ベアラの確立に成功した場合、このベアラ確立応答は、セッションＩＤ、ベアラＩＤ、及びベアラ確立結果、を含む。ＧＷ３４が原因となりベアラの確立に失敗した場合、ベアラ確立応答には、その旨を示す原因値（Cause Value）も含められる。

このようにして、Ｓ５０９ｂ～Ｓ５１４のベアラ確立処理がベアラごとに実行されることで、ＵＥ－ＡＰ－ＧＷの区間に複数のベアラが並列に確立される。Ｓ５０９ｂ～Ｓ５１４の処理が完了すると、Ｓ５１５で、セッション制御部３２は、バルクセッション確立応答メッセージをＵＥ１０へ送信する。このメッセージは、セッションＩＤ、ベアラＩＤ、及びベアラの確立結果、を含む。

ベアラの確立が成功していた場合には、このメッセージの受信をトリガとして、ＵＥ１０は、Ｓ５１６で、確立されたベアラを用いてユーザデータの伝送を開始する。一方、ベアラの確立に失敗していた場合には、ＡＰ２０及びＵＥ１０のそれぞれにおいて、ＡＰ－ＵＥ間のベアラを解放する処理が行われる。

その後Ｓ５０７で、セッション制御部３２は、ベアラ確立応答メッセージをセレクタ３３へ送信する。このメッセージは、セッションＩＤ、ベアラＩＤ、及びベアラの確立結果、を含む。Ｓ５０９ｂ～Ｓ５１４のベアラ確立処理において、いずれかのベアラの確立に失敗していた場合（即ち、ＵＥ１０、ＡＰ２０及び／又はＧＷ３４から送信された原因値（cause value）をセッション制御部３２が受信していた場合）、ベアラの確立失敗の原因を示す原因値も、ベアラ確立応答メッセージに含められてセレクタ３３へ送信される。セレクタ３３は、セッション制御部３２から受信した各原因値を、対応するセッションＩＤ及びベアラＩＤに関連付けて管理する。セレクタ３３は、管理している原因値を、バルクセッション確立処理のリセット判断（Ｓ５１９）及び確立すべきベアラの追加判断（Ｓ５２１）に活用する。

複数のベアラを用いた通信（ユーザデータの伝送）が行われる間に、所定のイベントの発生に応じて、Ｓ５１８で、セレクタ３３は、バルクセッション確立のリセットの実行に関する判断を行いうる。例えば、セレクタ３３は、ＧＷ３４の障害等に起因して、バースト的なベアラ確立失敗が発生し、端末アプリに求められる通信速度を提供不可能であることが判明した場合、バルクセッション確立のリセットを実行すると判断する。セレクタ３３は、バルクセッション確立のリセットを実行すると判断した場合にのみ、Ｓ５１９及びＳ５２０の処理を行う。

Ｓ５１９で、セレクタ３３は、バルクセッション確立リセット要求を、セッション制御部３２へ送信する。この要求に応じて、Ｓ５２０で、セッション制御部３２は、バルクセッションのリセットを求める要求をＧＷ３４、ＡＰ２０及びＵＥ１０へ送信することで、ＵＥ－ＡＰ－ＧＷの区間に確立されているベアラ（複数のベアラ）を解放する。

また、複数のベアラを用いた通信（ユーザデータの伝送）が行われる間に、セレクタ３３は、確立失敗が生じたベアラの本数が所定の本数を超えた場合等、ベアラを新たに追加する必要があると判断した場合、Ｓ５２１の処理を行う。Ｓ５２１で、セレクタ３３は、Ｓ５０７と同様の処理により、新たに確立するベアラの本数の決定、各ベアラの収容先となるＡＰ及びＧＷの選択、及び各ベアラのタイプ（アクティブ／スタンバイ）の選択を行う。なお、Ｓ５２１における処理では、各ベアラの収容先となるＡＰ及びＧＷの選択は、セレクタ３３が保持している原因値も考慮して実行される。例えば、セレクタ３３は、あるＡＰ２０においてバースト的な確立失敗が生じた場合、そのＡＰ２０を除外して、各ベアラの収容先を決定してもよい。その後、セレクタ３３は、Ｓ５０８に処理を戻し、Ｓ５０８以降の処理を再び行う。

＜ベアラのアクティブ化制御＞
図６は、本実施形態に係るモバイル通信システムにおける、ＵＥ１０のためのベアラのアクティブ化制御のシーケンスを示すシーケンス図である。図６に示すシーケンスによる処理は、ＵＥ１０が使用中のベアラの輻輳回避モードへの移行を検知したことに応じて開始される。

ＵＥ１０は、Ｓ６０１で、使用中のいずれかのベアラが輻輳回避モードへ移行したことを検知すると、Ｓ６０２へ処理を進める。Ｓ６０２で、ＵＥ１０は、輻輳回避モードへの移行が検知されたベアラ（対象ベアラ）についてのベアラタイプの切り替えを求めるベアラタイプ切替要求メッセージを、セッション制御部３２へ送信する。ベアラタイプ切替要求メッセージには、対象ベアラのベアラＩＤ及び通信速度が含められる。

Ｓ６０３で、セッション制御部３２は、ＵＥ１０からの上記メッセージの受信に応じて、受信したメッセージから取得した情報（対象ベアラのベアラＩＤ及び通信速度）を切替判断要求メッセージに含めて、それをセレクタ３３へ送信する。

Ｓ６０４で、セレクタ３３は、セッション制御部３２からの切替判断要求メッセージの受信に応じて、対象ベアラについてのベアラタイプの切り替えが必要であるか否かを判断する処理を行う。セレクタ３３は、対象ベアラについてのベアラタイプの切り替えが必要であると判断した場合、ベアラタイプを切り替えるベアラの本数及びベアラタイプ切り替えの対象とするベアラを、ＧＷの空き容量及びベアラの通信速度期待値等の情報に基づいて決定（選択）する。

Ｓ６０４の処理の完了後、Ｓ６０５で、セレクタ３３は、受信した切替判断要求メッセージに対する応答メッセージをセッション制御部３２へ送信する。この応答メッセージには、ベアラタイプの切替処理の対象となるベアラのベアラＩＤのリストが含められる。なお、セレクタ３３は、ベアラタイプの切替処理が不要と判断した場合、その旨の情報を含む応答メッセージを送信する。

セッション制御部３２は、ベアラタイプの切替処理が不要であることを示す情報を含む応答メッセージをセレクタ３３から受信すると、Ｓ６０６ａで、その旨を示す通知をＵＥ１０へ送信し、図６のシーケンスによる処理を終了する。一方、セッション制御部３２は、ベアラタイプの切替処理の対象となるベアラのベアラＩＤのリストを含む応答メッセージを受信すると、対象ベアラごとに、Ｓ６０６ｂ～Ｓ６１１の処理を実行する。なお、Ｓ６０６ｂ～Ｓ６１１の処理は、複数のベアラについて並列に実行されてもよい。また、Ｓ６０５～Ｓ６１５の処理と、Ｓ６１６以降の処理とは、並列に実行可能である。

Ｓ６０６ｂ～Ｓ６１１の処理は、Ｓ６０４におけるセレクタ３３の決定（選択）に従って、対象ベアラについてベアラタイプを切り替える切替処理である。なお、Ｓ６０６ｂ～Ｓ６１１のベアラタイプ切替処理は、Ｓ５０９ｂ～Ｓ５１４のベアラ確立処理と類似した手順で行われる。

まずＳ６０６ｂで、セッション制御部３２は、ＵＥ－ＡＰ間の対象ベアラについてのベアラタイプ切り替えを求めるベアラタイプ切替要求をＡＰ２０へ送信する。このベアラタイプ切替要求は、セッションＩＤ、ベアラＩＤ、ターゲットベアラタイプ（切り替え後のベアラタイプ）、を含む。なお、ＡＰ２０がベアラ切替要求を拒否する場合、以下のＳ６０７及びＳ６０８はスキップされる。

Ｓ６０７で、ＡＰ２０は、ベアラタイプ切替要求をＵＥ１０へ送信する。このベアラタイプ切替要求は、セッションＩＤ、ベアラＩＤ、及びターゲットベアラタイプ、を含む。

Ｓ６０８で、ＵＥ１０は、受信したベアラタイプ切替要求に従って、対象ベアラについてのターゲットベアラタイプへのベアラタイプの切り替え（例えば、スタンバイベアラからアクティブベアラへの切り替え）を試みる。ＵＥ１０は、切り替えの結果を示すベアラタイプ切替応答をＡＰ２０へ送信する。ベアラタイプ切り替えに成功した場合、このベアラタイプ切替応答は、セッションＩＤ、ベアラＩＤ、及びベアラタイプ切替結果、を含む。なお、ＵＥ１０が原因となりベアラタイプ切り替えに失敗した場合、ベアラタイプ切替応答には、その旨を示す原因値（Cause Value）も含められる。ＵＥ１０からのベアラタイプ切替応答の受信に応じて、ＡＰ２０は、Ｓ６０９で、ＵＥ－ＡＰ間のベアラタイプ切り替え結果を示すベアラタイプ切替応答をセッション制御部３２へ送信する。

ここで、ＵＥ－ＡＰ間のベアラタイプ切り替えに失敗した場合、以下のＳ６１０及びＳ６１１はスキップされる。また、Ｓ６０６ｂ及びＳ６０９において、ＡＰ２０が原因となりベアラタイプ切り替えに失敗した場合、ＡＰ２０は、その旨を示す原因値（Cause Value）もベアラタイプ切替応答に含めてセッション制御部３２へ送信する。また、Ｓ６０８においてＵＥ１０から原因値を受信した場合、セッション制御部３２は、受信した原因値をベアラタイプ切替応答に含めてセッション制御部３２へ送信する。セッション制御部３２は、ＡＰ２０から受信した各原因値を、対応するセッションＩＤ及びベアラＩＤに関連付けて管理する。

次にＳ６１０で、セッション制御部３２は、ＡＰ－ＧＷ間の対象ベアラについてのベアラタイプ切り替えを求めるベアラタイプ切替要求をＧＷ３４へ送信する。このベアラタイプ切替要求は、セッションＩＤ、ベアラＩＤ、及びターゲットベアラタイプ、を含む。

Ｓ６１１で、ＧＷ３４は、受信したベアラタイプ切替要求に従って、対象ベアラについてのターゲットベアラタイプへのベアラタイプの切り替え（例えば、スタンバイベアラからアクティブベアラへの切り替え）を試みる。ＧＷ３４は、ベアラタイプ切り替えの結果を示すベアラタイプ切替応答をセッション制御部３２へ送信する。ベアラタイプ切り替えに成功した場合、このベアラタイプ切替応答は、セッションＩＤ、ベアラＩＤ、及びベアラタイプ切り替え結果、を含む。ＧＷ３４が原因となりベアラタイプ切り替えに失敗した場合、ベアラタイプ切替応答には、その旨を示す原因値（Cause Value）も含められる。

このようにして、Ｓ６０６ｂ～Ｓ６１１のベアラタイプ切替処理が対象ベアラごとに実行されることで、ＵＥ－ＡＰ－ＧＷの区間に確立されているベアラのベアラタイプが（スタンバイベアラからアクティブベアラ）へ切り替えられる。Ｓ６０６ｂ～Ｓ６１１の処理が完了すると、Ｓ６１２で、セッション制御部３２は、ベアラタイプ切替応答メッセージをＵＥ１０へ送信する。このメッセージは、セッションＩＤ、ベアラＩＤ、及びベアラタイプ切り替え結果、を含む。

ベアラタイプ切り替えに成功していた場合、このメッセージの受信をトリガとして、ＵＥ１０は、Ｓ６１３で、アクティブベアラへ切り替えられたベアラを用いたユーザデータ伝送を開始する。

その後Ｓ６１４で、セッション制御部３２は、ベアラタイプ切替通知をセレクタ３３へ送信する。この通知は、セッションＩＤ、ベアラＩＤ、及びベアラタイプ切り替え結果、を含む。Ｓ６０６ｂ～Ｓ６１１のベアラタイプ切替処理において、いずれかのベアラについてのベアラタイプ切り替えに失敗していた場合（即ち、ＵＥ１０、ＡＰ２０及び／又はＧＷ３４から送信された原因値（cause value）をセッション制御部３２が受信していた場合）、ベアラタイプ切り替えの失敗の原因を示す原因値も、ベアラタイプ切替通知に含められてセレクタ３３へ送信される。セレクタ３３は、セッション制御部３２から受信した各原因値を、対応するセッションＩＤ及びベアラＩＤに関連付けて管理する。セレクタ３３は、管理している原因値を、スタンバイベアラの追加判断（Ｓ６１６）等に活用する。

セレクタ３３は、ベアラの切り替え失敗が生じたベアラの本数が所定の本数を超えた場合等、ベアラタイプ切り替えの対象とするベアラを追加する必要があると判断した場合、Ｓ６１５の処理を行う。Ｓ６１５で、セレクタ３３は、Ｓ６０４と同様の処理により、ベアラタイプを切り替えるベアラの本数及びベアラタイプ切り替えの対象とするベアラを決定（選択）する。なお、Ｓ６１５における処理では、ベアラタイプ切り替えの対象とするベアラの選択は、セレクタ３３が保持している原因値も考慮して実行される。例えば、セレクタ３３は、あるＡＰ２０においてバースト的な切り替え失敗が生じた場合、そのＡＰ２０以外のＡＰに収容されているベアラを、ベアラタイプ切り替えの対象として選択してもよい。その後、セレクタ３３は、Ｓ６０５に処理を戻し、Ｓ６０５以降の処理を再び行う。

Ｓ６１６で、セレクタ３３は、Ｓ６０４又はＳ６１５の処理をトリガとして、新たにスタンバイベアラを確立する必要があるか否かを判断する処理を行う。セレクタ３３は、新たにスタンバイベアラを確立する必要があると判断した場合、新たに確立するスタンバイベアラの本数の決定と、各スタンバイベアラの収容先となるＡＰ及びＧＷの選択とを、オペレータポリシに基づいて行い、Ｓ６１７以降の処理を行う。一方、セレクタ３３は、新たにスタンバイベアラを確立する必要はないと判断された場合、Ｓ６１７以降の処理は行わない。

（スタンバイベアラの確立処理）
Ｓ６１７で、セレクタ３３は、スタンバイベアラの確立を求めるベアラ確立要求メッセージを、セッション制御部３２へ送信する。このメッセージには、セッションＩＤ、ベアラＩＤ、ベアラタイプ、ＧＷのＩＤ、ＡＰのＩＤ、及び通信速度期待値、が含められる。セッション制御部３２は、受信したベアラ確立要求メッセージに従って、スタンバイベアラの確立処理を行う。

Ｓ６１８の処理は、ベアラ確立要求メッセージに従って、ＵＥ－ＡＰ間及びＡＰ－ＧＷ間にスタンバイベアラを確立するベアラ確立処理である。Ｓ６１８の処理は、ベアラごとに実行されるものであり、複数のベアラについて並列に実行されてもよい。ここで、Ｓ６１８の処理は、Ｓ５０９ｂ～Ｓ５１４の処理と同様である。ただし、セッション制御部３２からＡＰ２０及びＧＷ３４へ送信されるベアラ確立要求メッセージと、ＡＰ２０からＵＥ１０へ送信されるベアラ確立要求メッセージにおいて、確立対象のベアラタイプとしてスタンバイベアラが指定される。

Ｓ６１８のベアラ確立処理がベアラごとに実行されることで、ＵＥ－ＡＰ－ＧＷの区間に、決定された本数のスタンバイベアラが並列に確立される。Ｓ６１８の処理が完了すると、Ｓ６１９で、セッション制御部３２は、ベアラ確立通知をＵＥ１０へ送信する。この通知は、セッションＩＤ、ベアラＩＤ、及びスタンバイベアラの確立結果、を含む。

更にＳ６２０で、セッション制御部３２は、ベアラ確立応答メッセージをセレクタ３３へ送信する。このメッセージは、セッションＩＤ、ベアラＩＤ、及びベアラの確立結果、を含む。Ｓ６１８のベアラ確立処理において、いずれかのスタンバイベアラの確立に失敗していた場合（即ち、ＵＥ１０、ＡＰ２０及び／又はＧＷ３４から送信された原因値（cause value）をセッション制御部３２が受信していた場合）、スタンバイベアラの確立失敗の原因を示す原因値も、ベアラ確立応答メッセージに含められてセレクタ３３へ送信される。セレクタ３３は、セッション制御部３２から受信した各原因値を、対応するセッションＩＤ及びベアラＩＤに関連付けて管理する。セレクタ３３は、管理している原因値を、スタンバイベアラの追加判断（Ｓ６１６）等に活用する。

セレクタ３３は、確立失敗が生じたスタンバイベアラの本数が所定の本数を超えた場合等、更なるスタンバイベアラの追加が必要であると判断した場合、Ｓ６２１の処理を行う。Ｓ６２１で、セレクタ３３は、Ｓ６１６と同様の処理により、新たに確立するスタンバイベアラの本数の決定と、各スタンバイベアラの収容先となるＡＰ及びＧＷの選択とを、オペレータポリシに基づいて行う。なお、Ｓ６２１における処理では、各スタンバイベアラの収容先となるＡＰ及びＧＷの選択は、セレクタ３３が保持している原因値も考慮して実行される。例えば、セレクタ３３は、あるＡＰ２０においてバースト的なスタンバイベアラの確立失敗が生じた場合、そのＡＰ２０を除外して、各スタンバイベアラの収容先を決定してもよい。その後、セレクタ３３は、Ｓ６１７に処理を戻し、Ｓ６１７以降の処理を再び行う。

以上説明したように、本実施形態のセレクタ３３（ネットワーク装置）は、モバイルコア３０に配置され、複数のＡＰに接続可能なＵＥに対して、当該ＵＥがデータ通信用に確立する複数のベアラのそれぞれを収容するＡＰとＧＷとを決定する。セレクタ３３は、モバイルコア３０に配置された複数のＧＷのそれぞれに生じている負荷を示す負荷情報を、各ＧＷから取得する。セレクタ３３は、複数のベアラから成る通信セッションの確立を求める確立要求がＵＥから行われると、取得された負荷情報と、複数のＡＰ及び複数のＧＷに関連するＮＷ構成情報とに基づいて、１つ以上のアクティブベアラ及び１つ以上のスタンバイベアラを含む、確立するベアラの本数と、当該本数のベアラのそれぞれを収容するＡＰ及びＧＷを決定する。セレクタ３３は更に、当該決定に従って、ＵＥによるデータ通信用のベアラを確立する処理の実行を、モバイルコア３０に配置されたセッション制御機能３２に対して要求する。

このように、ＵＥ（ユーザ端末）に対して、アクティブベアラに加えてスタンバイベアラを確立することで、帯域不足等に起因してベアラを逐次追加するのではなく、スタンバイベアラをアクティブベアラに切り替えて使用することが可能になる。これにより、ＵＥがベアラを新たに確立するよりも、アクティブベアラを短時間で確保してデータ通信を行うことが可能になる。また、負荷情報及びＮＷ構成情報に基づいて、確立するベアラの本数と、当該本数のベアラのそれぞれを収容するＡＰ及びＧＷを決定することで、所望の通信速度を達成しつつ、必要以上に多数のベアラを確立せずに、複数のベアラを用いて通信（大容量通信）を行うＵＥをより効率的に収容することが可能になる。

［その他の実施形態］
上述の実施形態に係るネットワーク装置（セレクタ３３）は、コンピュータをネットワーク装置として機能させるためのコンピュータプログラムにより実現することができる。当該コンピュータプログラムは、コンピュータが読み取り可能な記憶媒体に記憶されて配布が可能なもの、又は、ネットワーク経由で配布が可能なものである。

なお、本発明により、例えば、セルラーネットワークにおいてより効率的なユーザ端末の収容が可能となることから、国連が主導する持続可能な開発目標（ＳＤＧｓ）の目標９「産業と技術革新の基盤をつくろう」に貢献することが可能となる。

発明は上記の実施形態に制限されるものではなく、発明の要旨の範囲内で、種々の変形・変更が可能である。

１０：ＵＥ、２０：ＡＰ、３０：モバイルコア、３１：移動管理機能、３２：セッション制御機能（セッション制御部）、３３：ＧＷ、３４：セレクタ

Claims (15)

1. 複数のアクセスポイント（ＡＰ）に接続可能なユーザ端末に対して、当該ユーザ端末がデータ通信用に確立する複数のベアラのそれぞれを収容するＡＰとゲートウェイ（ＧＷ）とを決定する、コアネットワークに配置されたネットワーク装置であって、
   前記コアネットワークに配置された複数のＧＷのそれぞれに生じている負荷を示す負荷情報を、各ＧＷから取得する取得手段と、
   複数のベアラから成る通信セッションの確立を求める確立要求が前記ユーザ端末から行われると、前記取得手段によって取得された前記負荷情報と、前記複数のＡＰ及び前記複数のＧＷに関連するネットワーク構成情報とに基づいて、１つ以上のアクティブベアラ及び１つ以上のスタンバイベアラを含む、確立するベアラの本数と、当該本数のベアラのそれぞれを収容するＡＰ及びＧＷを決定する決定手段と、
   前記決定手段による決定に従って、前記ユーザ端末によるデータ通信用のベアラを確立する処理の実行を、前記コアネットワークに配置されたセッション制御機能に対して要求する要求手段と、
   を備えることを特徴とするネットワーク装置。
2. 前記決定手段は、確立するベアラごとに、前記セッション制御機能によって前記ユーザ端末に対して選択された収容先候補のＡＰ及びＧＷのうちで当該ベアラを収容するＡＰ及びＧＷを選択する
   ことを特徴とする請求項１に記載のネットワーク装置。
3. 前記収容先候補のＡＰ及びＧＷは、前記ユーザ端末に搭載されたアプリケーションの通信要件に基づいて決定される
   ことを特徴とする請求項２に記載のネットワーク装置。
4. 前記負荷情報は、ＧＷの空きリンク容量を示す情報を含み、
   前記決定手段は、前記セッション制御機能によるベアラ確立処理の完了後の空きリンク容量が複数のＧＷ間で均等になるように、確立する各ベアラの収容先となるＡＰ及びＧＷを決定する
   ことを特徴とする請求項１乃至３のいずれか１項に記載のネットワーク装置。
5. 前記決定手段は、前記ユーザ端末に搭載されたアプリケーションの所望の通信速度に基づいて、確立するアクティブベアラの本数を決定する
   ことを特徴とする請求項１乃至４のいずれか１項に記載のネットワーク装置。
6. 前記決定手段は、オペレータポリシに従って、確立するスタンバイベアラの本数を決定する
   ことを特徴とする請求項１乃至５のいずれか１項に記載のネットワーク装置。
7. 前記要求手段による要求に応じて前記セッション制御機能によりベアラの確立処理が行われた際に、ベアラの確立が失敗すると、前記ユーザ端末、前記ＡＰ及び前記ＧＷの１つ以上から、ベアラの確立失敗の原因を示す原因値が送信され、
   前記要求手段は、前記ユーザ端末、前記ＡＰ及び前記ＧＷの１つ以上から送信された前記原因値に基づいて、前記ユーザ端末に対する新たなベアラの追加を前記セッション制御機能に対して要求する
   ことを特徴とする請求項１乃至６のいずれか１項に記載のネットワーク装置。
8. 前記決定手段は、前記ユーザ端末が接続可能なＡＰとＧＷとのそれぞれの組み合わせについて、確立したベアラを当該組み合わせのＡＰ及びＧＷに収容した場合の、当該ベアラの通信速度期待値を導出し、各ベアラの通信速度期待値を前記ユーザ端末へ通知し、
   前記要求手段は、前記ユーザ端末から、各ベアラの前記通信速度期待値に基づいて、スタンバイベアラをアクティブベアラへ切り替えることを求める切替要求が行われると、前記ユーザ端末に対して確立されている１つ以上のスタンバイベアラをアクティブベアラへ切り替える切替処理の実行を、前記セッション制御機能に対して要求する
   ことを特徴とする請求項１乃至７のいずれか１項に記載のネットワーク装置。
9. 前記負荷情報は、ＧＷの空きリンク容量を示す情報を含み、
   前記決定手段は、前記負荷情報と各ベアラの前記通信速度期待値とに基づいて、前記ユーザ端末に対して確立されているスタンバイベアラのうちで、前記切替処理においてベアラタイプをアクティブベアラへ切り替えるベアラの本数とアクティブベアラへ切り替える対象ベアラとを決定する
   ことを特徴とする請求項８に記載のネットワーク装置。
10. 前記要求手段による要求に応じて前記セッション制御機能により前記切替処理が行われた際に、ベアラタイプの切り替えが失敗すると、前記ユーザ端末、前記ＡＰ及び前記ＧＷの１つ以上から、ベアラタイプの切り替え失敗の原因を示す原因値が送信され、
    前記要求手段は、前記ユーザ端末、前記ＡＰ及び前記ＧＷの１つ以上から送信された前記原因値に基づいて、前記ユーザ端末に対する新たなスタンバイベアラの追加を前記セッション制御機能に対して要求する
    ことを特徴とする請求項８又は９に記載のネットワーク装置。
11. 前記ユーザ端末は、前記ネットワーク装置から通知された各ベアラの通信速度期待値に基づいて、前記確立されたアクティブベアラを用いて、前記ユーザ端末に搭載されたアプリケーションの所望の通信速度を達成できないと判定すると、前記切替要求を行う
    ことを特徴とする請求項８又は９に記載のネットワーク装置。
12. 前記アクティブベアラは、データ伝送に使用されるベアラであり、
    前記スタンバイベアラは、ベアラとして確立されているがデータ伝送に使用できないベアラであって、アクティブ化が行われることで前記アクティブベアラへの切り替えが可能なベアラである
    ことを特徴とする請求項１乃至１１のいずれか１項に記載のネットワーク装置。
13. 請求項１乃至１２のいずれか１項に記載のネットワーク装置と、
    前記コアネットワークに配置され、前記ネットワーク装置と通信可能な前記セッション制御機能と、
    を備えることを特徴とする通信システム。
14. 複数のアクセスポイント（ＡＰ）に接続可能なユーザ端末に対して、当該ユーザ端末がデータ通信用に確立する複数のベアラのそれぞれを収容するＡＰとゲートウェイ（ＧＷ）とを決定する、コアネットワークに配置されたネットワーク装置の制御方法であって、
    前記コアネットワーク上の複数のＧＷのそれぞれに生じている負荷を示す負荷情報を、各ＧＷから取得する取得工程と、
    複数のベアラから成る通信セッションの確立を求める確立要求が前記ユーザ端末から行われると、前記取得工程で取得された前記負荷情報と、前記複数のＡＰ及び前記複数のＧＷに関連するネットワーク構成情報とに基づいて、１つ以上のアクティブベアラ及び１つ以上のスタンバイベアラを含む、確立するベアラの本数と、当該本数のベアラのそれぞれを収容するＡＰ及びＧＷを決定する決定工程と、
    前記決定工程における決定に従って、前記ユーザ端末によるデータ通信用のベアラを確立する処理の実行を、前記コアネットワーク上のセッション制御機能に対して要求する要求工程と、
    を含むことを特徴とするネットワーク装置の制御方法。
15. ネットワーク装置が備えるコンピュータに、請求項１４に記載のネットワーク装置の制御方法の各工程を実行させるためのプログラム。

Images