JP2022123746A - 中継端末、コアネットワーク装置及び通信方法 - Google Patents

Abstract

【課題】ネットワークのリソースが十分ではない場合であっても、端末のＱｏＳ要求を満たすことを可能とする中継端末を提供すること。【解決手段】第１端末からＱｏＳ要求を受信した場合に、前記ＱｏＳ要求をネットワーク装置に送信する第１送信部と、前記ネットワーク装置から、前記ＱｏＳ要求を拒否することを示す情報を受信する受信部と、前記情報を受信した場合に、当該中継端末と通信する１以上の端末の中から第２端末を選択する制御部と、前記第２端末のＱｏＳ要求を変更することを要求するメッセージを前記ネットワーク装置に送信する第２送信部と、を有する中継端末を提供する。【選択図】図１１

Description

本開示は、中継端末、コアネットワーク装置及び通信方法に関する。

国際標準化団体であるThird Generation Partnership Project（３ＧＰＰ）では、第３．９世代の無線アクセス技術（Radio Access Technology：ＲＡＴ）であるLong Term Evolution（ＬＴＥ）、第４世代のＲＡＴであるＬＴＥ－Ａｄｖａｎｃｅｄの後継として、第５世代（Fifth Generation：５Ｇ）のＲＡＴであるNew Radio（ＮＲ）のリリース１５が仕様化されている（例えば、非特許文献１）。

また、第４世代のコアネットワーク（Core Network：ＣＮ）であるEvolved Packet Core（ＥＰＣ）の後継として、第５世代のＣＮである5G Core Network（５ＧＣ）のリリース１５も仕様化されている（例えば、非特許文献２）。

3GPP TS 38.300 V15.2.0 (2018-06) 3GPP TS 23.501 V15.2.0 (2018-06)

現在、近接サービス（Proximity based Services：ＰｒｏＳｅ）と呼ばれる、デバイス間通信の検討が進められている。５Ｇで検討されている近接サービスは、５Ｇ ＰｒｏＳｅとも呼ばれる。また、５Ｇ ＰｒｏＳｅでは、リモート端末（Remote UE）が、リレー端末（Relay UE）を経由してネットワークと通信を行う、リレー方式による通信の検討も進められている。

ここで、５Ｇのネットワークは、インターネットなどのベストエフォート通信、低遅延が要求される通信、高信頼性が求められる通信など、多様な通信に対応しており、端末は、所望の通信品質に応じたＱｏＳ（Quality of Service）を指定して通信を行うことが可能である。

従って、リモート端末がリレー端末を経由して５Ｇネットワークと通信を行う場合においても、リモート端末は、所望の通信品質に対応するＱｏＳを指定して通信を行うことが考えられる。

通常、ネットワークのリソースが十分ではなく、リモート端末が要求するＱｏＳを満たすことができない場合、リモート端末のＱｏＳ要求は拒否されることになる。しかしながら、リモート端末が優先度の高い通信を行う端末である場合、ＱｏＳ要求を拒否することは好ましくないと考えられる。

本開示はこのような事情に鑑みてなされたものであり、ネットワークのリソースが十分ではない場合であっても、端末のＱｏＳ要求を満たすことを可能とする中継端末、コアネットワーク装置及び通信方法を提供することを目的とする。

本開示の一態様に係る中継端末は、第１端末からＱｏＳ要求を受信した場合に、前記ＱｏＳ要求をネットワーク装置に送信する第１送信部と、前記ネットワーク装置から、前記ＱｏＳ要求を拒否することを示す情報を受信する受信部と、前記情報を受信した場合に、当該中継端末と通信する１以上の端末の中から第２端末を選択する制御部と、前記第２端末のＱｏＳ要求を変更することを要求するメッセージを前記ネットワーク装置に送信する第２送信部と、を有する。

本開示によれば、ネットワークのリソースが十分ではない場合であっても、端末のＱｏＳ要求を満たすことを可能とする中継端末、コアネットワーク装置及び通信方法を提供することができる。

本実施形態に係る通信システムの概要の一例を示す図。 端末及びネットワーク間リレーにおける課題を説明するための図。 ＱｏＳ状態を通知する際の処理手順の一例（パターン１）を示すシーケンス図。 ＱｏＳ状態を通知する際の処理手順の一例（パターン２）を示すシーケンス図。 ＱｏＳ状態を通知する際の処理手順の一例（パターン３）を示すシーケンス図。 優先度に基づくＱｏＳ制御における処理手順の一例（パターン１）を示すシーケンス図。 優先度に基づくＱｏＳ制御における処理手順の一例（パターン２）を示すシーケンス図。 優先度に基づくＱｏＳ制御における処理手順の一例（パターン３）を示すシーケンス図。 優先度に基づくＱｏＳ制御における処理手順の一例（パターン４）を示すシーケンス図。 本実施形態に係る通信システム内の各装置のハードウェア構成の一例を示す図。 リレー端末の機能ブロック構成例を示す図。 基地局の機能ブロック構成例を示す図。 ＡＭＦの機能ブロック構成例を示す図。 ＳＭＦの機能ブロック構成例を示す図。

添付図面を参照して、本開示の実施形態について説明する。なお、各図において、同一の符号を付したものは、同一又は同様の構成を有してもよい。

＜システム構成＞
図１は、本実施形態に係る通信システムの概要の一例を示す図である。図１に示すように、通信システム１は、リレー端末（中継端末）１０Ａと、リモート端末１０Ｂと、基地局２０と、コアネットワーク３０と、Data Network（ＤＮ）４０とを含む。なお、図１に示す端末１０、基地局２０、コアネットワーク３０内の各ノードの数は例示にすぎず、図示する数に限られない。以下の説明において、リレー端末（Relay UE）１０Ａと、リモート端末（Remote UE）１０Ｂとを区別しない場合、「端末１０」と記載する。

端末１０は、例えば、スマートフォンや、パーソナルコンピュータ、車載端末、車載装置、静止装置、テレマティクス制御ユニット（Telematics control unit：ＴＣＵ）等、所定の端末又は装置である。端末１０は、ユーザ装置（User Equipment：ＵＥ）、移動局（Mobile Station：ＭＳ）、端末（User Terminal）、無線装置（Radio apparatus）、加入者端末、アクセス端末等と呼ばれてもよい。端末１０は、移動型であってもよいし、固定型であってもよい。

端末１０は、基地局２０に対する無線アクセス技術（Radio Access Technology：ＲＡＴ）ＲＡＴとして、例えば、ＬＴＥ、ＬＴＥ－Ａｄｖａｎｃｅｄ、ＮＲ等を用いて通信可能に構成されるが、これに限られず、第６世代以降のＲＡＴを用いて通信可能に構成されてもよい。また、端末１０は、上記のような３ＧＰＰが規定したアクセス網（3GPP access network）に限られず、例えば、Ｗｉ－Ｆｉ等の非３ＧＰＰアクセス網（non-3GPP access network）を介して基地局２０にアクセスしてもよい。

基地局２０は、一以上のセルＣを形成し、当該セルＣを用いて端末１０と通信する。端末１０と基地局２０間のインタフェースはＵｕと呼ばれる。基地局２０は、gNodeB(gNB)、en-gNB、無線アクセスネットワーク（Radio Access Network：ＲＡＮ）、アクセスネットワーク（Access Network：ＡＮ）、次世代無線アクセスネットワーク（Next Generation‐Radio Access Network：ＮＧ－ＲＡＮ）ノード、低電力ノード（low-power node）、中央ユニット（Central Unit：ＣＵ）、分散ユニット（Distributed Unit：ＤＵ）、gNB-DU、リモート無線ヘッド（Remote Radio Head：ＲＲＨ）、統合アクセス及びバックホール（Integrated Access and Backhaul/Backhauling：ＩＡＢ）ノード等と呼ばれてもよい。基地局２０は、一つのノードに限られず、複数のノード（例えば、DU等の下位ノードとCU等の上位ノードの組み合わせ）で構成されてもよい。

コアネットワーク３０は、例えば、５ＧＣであるが、これに限られず、ＥＰＣ又は第６世代以降のコアネットワーク等であってもよい。コアネットワーク３０は、例えば、Access and Mobility Management Function（ＡＭＦ）３１、Session Management Function（ＳＭＦ）３２、User Plane Function（ＵＰＦ）３３、Policy and Control Function（ＰＣＦ）３４、Application Function（ＡＦ）３５等を含む。

ＡＭＦ３１は、端末１０のモビリティ（mobility）管理を行うモビリティ管理装置である。ＡＭＦ３１は、Ｎ２インタフェースで基地局２０に接続されるとともに、Ｎ１インタフェースで端末１０に接続される。ＡＭＦ３１は、制御プレーンに関する処理（例えば、登録管理、コネクション管理、モビリティ管理）等を行う。また、ＡＭＦ３１は、Non-access stratum（ＮＡＳ）に関する処理を行い、ＮＡＳメッセージを端末１０との間で送信及び／又は受信する。

ＳＭＦ３２は、セッションを管理するセッション管理装置であり、例えば、端末１０がＤＮ４０と通信を行うために用いるＵＰＦ３３を選択し、端末１０及びＤＮ４０の間におけるＰＤＵ（Protocol Data Unit）セッションの確立、更新及び解放等を制御する。ＳＭＦ３２は、Ｎ１１インタフェースを介してＡＭＦ３１に接続されるとともに、Ｎ４インタフェースを介してＵＰＦ３３に接続される。

ＵＰＦ３３は、ＤＮ４０に対する接続ポイントであり、例えば、パケットのルーティング、転送等を行う。ＵＰＦ３３は、Ｎ４インタフェースを介してＳＭＦ３２に接続されるとともに、Ｎ３インタフェースを介して基地局２０に接続される。ＵＰＦ３３は、端末１０及びＤＮ４０間の接続関係を示すＰＤＵセッションに従い、パケットのルーティングや転送を行う。

ＰＣＦ３４は、ポリシーの管理及び制御を行う、ポリシー管理制御装置であり、例えば、所定のポリシーに基づいてトラフィックに適用すべきＱｏＳの決定等を行う。ＲＣＦ３４は、Ｎ７インタフェースを介してＳＭＦ３２に接続されるとともに、Ｎ５インタフェースを介してＡＦ３５に接続される。

ＡＦ３５は、サービス提供（例えばＰｒｏＳｅなど）を提供する際に必要な情報をコアネットワーク３０に提供する装置である。ＡＦ３５は、Ｎ５インタフェースを介してＰＣＦ３４に接続される。

ＤＮ４０は、例えば、インターネット、企業ネットワーク、IP Multimedia Subsystem（ＩＭＳ）などである。

なお、コアネットワーク３０に含まれる機能は、図１に示すものに限られない。また、図１に示す各機能及びインタフェースの名称は例示にすぎず、図１に示すものに限られず、同等又は類似の機能を有すれば、他の名称が用いられてもよい。また、図１に示す複数のコアネットワーク機能が単一の装置内に設けられてもよいし、図１に示す一つのコアネットワーク機能が複数の装置で構成されてもよい。コアネットワーク３０の各機能の一部又は全部を構成する装置を、「コアネットワーク装置」ともいう。

ＤＮ４０からの下りデータは、ＵＰＦ３３からＮ３トンネルを介して基地局２０に伝送され、基地局２０から無線ベアラを介して端末１０に伝送される。一方、端末１０からの上りデータは、無線ベアラを介して端末１０から基地局２０に伝送され、基地局２０からＮ３トンネルを介してＵＰＦ３３に伝送され、ＵＰＦ３３からＤＮ４０に伝送される。なお、Ｎ３トンネルは、カプセル化されたＩＰ（Encapsulated Internet Protocol）パケットを伝送するトンネルであり、ユーザプレーントンネル等と呼ばれてもよい。

（ＱｏＳ制御）
５ＧにおけるＱｏＳ制御は、ＰＤＵセッション内で定義される、１又は複数ＱｏＳフロー（QoS Flow）の単位で行われる。ＱｏＳフローは、QoS Flow ID（ＱＦＩ）を用いて一意に識別される。また、各ＱｏＳフローは、ＱｏＳプロファイル（QoS Profile）と、ＱｏＳルール（QoS Rule）と、ＵＬ／ＤＬ ＰＤＲ（Uplink/Downlink Packet Detection Rule）により定められる。

ＱｏＳプロファイルは、ＳＭＦ３２からＡＭＦ３１を介して基地局２０に通知される情報である。基地局２０は、ＱｏＳフローをデータ無線ベアラ（Data Radio Bearer：ＤＲＢ）にマッピングするとともに、ＱｏＳプロファイルにより指定されるＱｏＳ特性に基づいて、データ無線ベアラのスケジューリングを行う。ＱｏＳプロファイルには、5G QoS Identifier（５ＱＩ）、Allocation and Retention Priority（ＡＲＰ）、Reflective QoS Attribute（ＲＯＡ）及び通知コントロール（Notification control）といったＱｏＳパラメータが含まれる。５ＱＩは、３ＧＰＰ仕様によって予め定められたＱｏＳ特性を識別する指示子である。５ＧにおけるＱｏＳ特性には、例えば、リソースタイプ（ビットレート保障（ＧＢＲ）、ビットレート非保障（Ｎｏｎ－ＧＢＲ）、遅延クリティカルＧＢＲ）、保証フロービットレート（Guaranteed Flow Bit Rate：ＧＦＢＲ）、最大フロービットレート（Maximum Flow Bit Rate：ＭＦＢＲ）、優先レベル、パケット遅延バジェット、パケットエラー率等が含まれる。通知コントロールは、ＱｏＳフローにおけるＧＦＢＲが保証できなくなった場合又は再び保証できる状態になった場合に、基地局２０に対し、コアネットワーク３０への通知を要求するか否かを示す情報である。

ＱｏＳルールは、ＳＭＦ３２からＡＭＦ３１を介して端末１０に通知される情報である。端末１０は、ＱｏＳルールに基づいて、ＵＬデータをＱｏＳフローにマッピングする。ＱｏＳルールには、ＱＦＩ及びパケットフィルタセット等が含まれる。

ＰＤＲは、ＳＭＦ３２からＵＰＦ３３に通知される情報である。ＵＰＦ３３は、ＰＤＲに基づいて、ＤＮ４０から受信したＤＬデータを分類してＱｏＳフローへのマーキングを行う（カプセル化ヘッダにＱＦＩを付与する）。

ＱｏＳフロー（QoS Flow）は、ＳＭＦ３２により管理される。ＱｏＳフローの設定／変更は、ＰＤＵセッション確立手順（PDU Session Establishment procedure）又はＰＤＵセッション変更手順（PDU Session Modification procedure）により行われる。つまり、ＱｏＳルール、ＱｏＳプロファイル及びＰＤＲは、ＰＤＵセッション確立手順又はＰＤＵセッション変更手順により、それぞれ、端末１０、基地局２０及びＵＰＦ３３に通知される。また、１つのＰＤＵセッションには、１又は複数のＱｏＳフローを関連づけることができる。

（端末及びネットワーク間リレー）
現在３ＧＰＰでは、端末間通信を用いる近接サービス（ＰｒｏＳｅ）の仕様として、リモート端末１０Ｂが、リレー端末１０Ａを経由してネットワーク（基地局２０及びコアネットワーク３０）と通信を行う、端末及びネットワーク間リレー（UE-to-Network Relay）の検討が進められている。リモート端末１０Ｂは、Remote UEと呼ばれてもよいし、ProSe UE-to-Network Relayと呼ばれてもよい。また、リレー端末１０Ａ及びリモート端末１０Ｂは、端末間通信（D2D通信、Sidelink通信）をサポートする。

リモート端末１０Ｂ及びリレー端末１０Ａ間のインタフェースは、ＰＣ５と呼ばれる。

リレー端末１０Ａとリモート端末１０Ｂは、同一の機能を備えており、リレー端末１０Ａとして動作するのか、又は、リモート端末１０Ｂとして動作するのかを任意に切替可能であってもよい。若しくは、リレー端末１０Ａとリモート端末１０Ｂは、それぞれ異なる機能を有する端末１０であってもよい。また、リレー端末１０Ａ及びリモート端末１０Ｂは、通常の端末１０として動作する機能を備えていてもよい。

また、３ＧＰＰでは、端末及びネットワーク間リレーとして、レイヤ３リレー（Layer 3 UE-to-Network Relay）と、リモート端末１０ＢがＮＡＳレイヤを終端する形態であるレイヤ２リレー（Layer 2 UE-to-Network Relay）とが検討されている。

レイヤ３リレーは、リレー端末１０ＡがＮＡＳ（Non Access Stratum）レイヤを終端し、リモート端末１０Ｂの通信に用いられるＰＤＵセッションの確立をリレー端末１０Ａが行う形態である。

レイヤ３リレーにおいてエンドツーエンド（End to End）のＱｏＳを実現する場合、リレー端末１０Ａ及びリモート端末１０Ｂ間におけるＱｏＳ制御は、端末間通信用のＱｏＳフローである「ＰＣ５ ＱｏＳフロー」が適用されることとしてもよい。ＰＣ５ ＱｏＳフローでは、ＱｏＳ特性を示す識別子として、ＰＱＩ（PC5 5QIs）が用いられてもよい。また、ＰＣ５ ＱｏＳフローを一意に識別する識別子として、ＰＦＩ（PC5 QoS Flow Identifier）が用いられてもよい。なお、リモート端末１０Ｂ及びＤＮ４０間におけるＱｏＳ制御には、上述の「ＱｏＳ制御」で説明したＱｏＳフローが適用されることとしてもよい。以下の説明では、上述の「ＱｏＳ制御」で説明したＱｏＳフローを、ＰＣ５ ＱｏＳフローと区別するため、便宜上、「Ｕｕ ＱｏＳフロー」と言う。

レイヤ３リレーでは、エンドツーエンド（End to End）のＱｏＳを実現するため、リレー端末１０Ａは、「ＰＣ５ ＱｏＳフロー」のＰＱＩと「Ｕｕ ＱｏＳフロー」の５ＱＩとを、ＰＱＩと５ＱＩとをマッピングする情報（以下、「マッピングテーブル」と言う。）に基づいて相互に変換する。これにより、リモート端末１０Ｂ及びＤＮ４０の間におけるエンドツーエンドのＱｏＳ制御を実現することができる。

レイヤ２リレーは、リモート端末１０ＢがＮＡＳレイヤを終端し、リモート端末１０Ｂの通信に適用されるＰＤＵセッションの確立を、リモート端末１０Ｂ自身が行う形態である。

レイヤ２リレーの場合、ＰＣ５ ＱｏＳフローは存在せず、Ｕｕ ＱｏＳフローが、リモート端末１０Ｂ及びＤＮ４０の間に適用される。従って、リレー端末１０Ａは、Ｕｕリンクにおける無線ベアラのＱｏＳ制御に用いられるＱｏＳプロファイルに従って、ＰＣ５リンクにおける無線ベアラのＱｏＳ制御を行うこととしてもよい。

（端末及びネットワーク間リレーの課題）
図２は、端末及びネットワーク間リレーにおける課題を説明するための図である。

ステップＳ１１で、例えば、多くのリモート端末１０Ｂ－１～ｎ（ｎは任意の正の整数）が、リレー端末１０Ａを介してネットワークに接続し、通信を行っているものとする。

ステップＳ１２で、新たなリモート端末１０Ｂ－Ｘが通信を開始するため、リレー端末１０Ａを介してネットワークとの間でコネクションを確立する。このとき、ＱｏＳとして、デフォルトのＱｏＳ（ビットレート非保障のＱｏＳ）が割り当てられる。

ステップＳ１３で、リモート端末１０Ｂ－Ｘは、所望のＱｏＳをリレー端末１０Ａに通知する。ここで、リモート端末１０Ｂ－Ｘが所望するＱｏＳ（所望するＱｏＳ条件）は、ビットレート保障型など、デフォルトＱｏＳよりも厳しい条件のＱｏＳであるものとする。

ステップＳ１４で、リレー端末１０Ａは、リモート端末１０Ｂ－Ｘが所望するＱｏＳをネットワークに通知する。リレー端末１０Ａ及びネットワークは、既にリレー端末１０Ａを介して多くのリモート端末１０Ｂ－１～ｎが通信を行っている状態であることから、リモート端末１０Ｂ－Ｘが所望するＱｏＳの要求を受け入れることはできないと認識する。 ステップＳ１５で、リレー端末１０Ａは、リモート端末１０Ｂ－Ｘに対し、リモート端末１０Ｂ－Ｘが所望するＱｏＳ要求の受け入れを拒否することを通知する。

ステップＳ１６で、リモート端末１０Ｂ－Ｘは、所望するＱｏＳの要求が拒否された場合、リレー端末１０Ａを介した通信を諦めて、他のリレー端末１０Ａを介した通信を試みる。

このように、ＱｏＳ要求が拒否されると、リモート端末１０Ｂ－Ｘが行ったステップＳ１２～ステップＳ１５の処理手順は、無駄になってしまうという課題がある（第１の課題）。

また、仮に、リモート端末１０Ｂ－Ｘが、ミッションクリティカル通信など優先度の高い重要な通信を行う端末１０である場合、リモート端末１０Ｂ－Ｘが所望するＱｏＳの受け入れを拒否することは好ましくないと考えられる（第２の課題）。

なお、図２において、多くのリモート端末１０Ｂ－１～ｎが、リレー端末１０Ａを介してネットワークに接続し、通信を行っていることとしたが、これに限定されない。例えばリレー端末１０Ａ及び基地局２０間の無線品質が悪い場合や、コアネットワーク３０のトラフィックが逼迫している場合であっても、同様の問題が生じ得る。

本実施形態では、第１の課題を解決するため、リレー端末１０Ａは、ネットワークがより要件（Requirement）の厳しいＱｏＳの要求を受け入れることが可能な状態であるのか又は受け入れることができない状態であるのかを示す情報（以下、「ＱｏＳ状態情報」と言う。）を、周囲に存在する端末１０に通知する。

また、本実施形態では、第２の課題を解決するため、既に接続しているリモート端末１０Ｂ－１～ｎのうち、リモート端末１０Ｂ－Ｘよりも優先度の低いリモート端末１０ＢのＱｏＳを、より要件の緩いＱｏＳに変更する（以下、「優先度に基づくＱｏＳ制御」と言う。）。これにより、ネットワークのリソースが十分ではない場合であっても、リモート端末１０Ｂ－Ｘが所望するＱｏＳを満たすために必要なネットワークリソースを確保できるように制御する。

＜処理手順＞
（１）ＱｏＳ要求の受け入れ可否の通知
（１．１）
図３は、ＱｏＳ状態を通知する際の処理手順の一例（パターン１）を示すシーケンス図である。図３の例では、ＳＭＦ３２によりＱｏＳ要求（ＰＤＵセッション変更）が拒否された場合、リレー端末１０Ａは、ネットワークのリソースが逼迫していると判断し、ＱｏＳ要求を受け入れることができない状態であることを示すＱｏＳ状態情報を送信する。

ステップＳ１０１で、リモート端末１０Ｂは、レイヤ３リレーとして動作するリレー端末１０Ａとの間で直接通信をするためのコネクションを確立する。当該コネクションは、Ｌ２リンク、ＰＣ５リンク、ユニキャストリンクなどと呼ばれてもよい。また、リモート端末１０Ｂは、リレー端末１０Ａとの間で「ＰＣ５ ＱｏＳフロー」を確立する。ここでは、ＰＣ５ ＱｏＳフローには、デフォルトのＱｏＳが適用されるものとする。

続いて、リレー端末１０Ａは、ＰＤＵセッション確立手順を実行し、リモート端末１０Ｂに対応するＵｕ ＱｏＳフロー（より詳細には、リモート端末１０Ｂのトラフィックを流すために用いられるＵｕ ＱｏＳフロー）を作成する。ここでは、作成されるＵｕ ＱｏＳフローにはデフォルトのＱｏＳが適用されるものとする。なお、既に、リレー端末１０ＡがＰＤＵセッションを確立済みである場合、ＰＤＵセッション確立手順に代えてＰＤＵセッション更新手順を実行することで、リモート端末１０Ｂに対応するＵｕ ＱｏＳフローを作成することとしてもよい。

リモート端末１０Ｂに対応するＵｕ ＱｏＳフローが作成されると、リモート端末１０Ｂからの上りデータは、ＰＣ５ ＱｏＳフロー及びＵｕ ＱｏＳフローに従い、リレー端末１０Ａを経由してＤＮ４０に運ばれる。同様に、ＤＮ４０からの下りデータは、Ｕｕ ＱｏＳフロー及びＰＣ５ ＱｏＳフローに従い、リレー端末１０Ａを経由してリモート端末１０Ｂに運ばれる。

リレー端末１０Ａは、作成したＵｕ ＱｏＳフローのＱＦＩと、ＰＣ５ ＱｏＳフローのＰＦＩとを対応づけて管理することで、リモート端末１０ＢにおけるエンドツーエンドのＱｏＳフローを管理することとしてもよい。

ステップＳ１０２で、リモート端末１０Ｂは、ＰＣ５ ＱｏＳフローに適用されるＱｏＳを、所望のＱｏＳ（ここでは、デフォルトＱｏＳよりも要件が厳しいＱｏＳであるものとする）に変更するため、リレー端末１０Ａに対し、所望のＱｏＳを示す情報（以下、「ＱｏＳ指示子」と言う。）を含むＬ２リンク変更要求（L2 link Modification Request）をリレー端末１０Ａに送信する。ＱｏＳ指示子は、Requested QoSと呼ばれてもよい。ＱｏＳ指示子は、例えば、所望のＱｏＳ要件に対応するＰＱＩであってもよいし、エンドツーエンドのＱｏＳ要件に対応する識別子であってもよい。また、ＱｏＳ指示子には、通信品質を指定する他のパラメータが含まれていてもよい。

ステップＳ１０３で、リレー端末１０Ａは、マッピングテーブルに基づき、ＱｏＳ指示子に含まれるＰＱＩ若しくはエンドツーエンドのＱｏＳ要件に対応する識別子を、５ＱＩに変換する。マッピングテーブルは、ＮＡＳメッセージ又はＲＲＣメッセージを介して、コアネットワーク３０からリレー端末１０Ａに設定されることとしてもよいし、リレー端末１０Ａに予め事前設定（Preconfigured）されていてもよい。

続いて、リレー端末１０Ａは、リモート端末１０Ｂに対応するＵｕ ＱｏＳフローのＱｏＳを変更するため、基地局２０を介して、ＮＡＳメッセージ（ＰＤＵセッション変更要求（PDU session modification request））をＡＭＦ３１に送信する。ＰＤＵセッション変更要求には、例えば、ＰＤＵセッションＩＤ、リモート端末１０Ｂに対応するＵｕ ＱｏＳフローの識別子、及び、ＱｏＳ指示子が含まれる。なお、「リモート端末１０Ｂに対応するＵｕ ＱｏＳフローの識別子」は、例えば、ＱＦＩやパケットフィルタなどであってもよい（以降の説明でも同様）。

ステップＳ１０４で、基地局２０、ＡＭＦ３１、ＳＭＦ３２及びＵＰＦ３３の間でＰＤＵセッション変更処理（PDU Session Modification Procedure）が行われる。

ここで、ＰＤＵセッション変更処理の概要について説明する。まず、ＡＭＦ３１は、ＰＤＵセッション変更要求に含まれる各種情報を、ＰＤＵセッション更新要求メッセージ（Nsmf_PDUSession_UpdateSMContext）に含めてＳＭＦ３２に送信する。ＳＭＦ３２は、ネットワークのトラフィック状況等に基づき、ＱｏＳ要求を受け入れ可能か否かを判定する。ＳＭＦ３２はどのような方法で判定してもよいが、例えば、既に各端末１０との間で確立済みのＰＤＵセッション数や、ビットレート保障型のＱｏＳフローの数などに応じて、ＱｏＳ要求を受け入れ可能か否かを判定するようにしてもよい。

ＳＭＦ３２は、ＱｏＳ要求を受け入れる場合、ＱｏＳ要求に対応するＱｏＳプロファイル及びＱｏＳルールを、ＡＭＦ３１に送信する。ＡＭＦ３１は、ＱｏＳプロファイルをＮ２メッセージに含めて基地局２０に送信し、ＱｏＳルールを、ＮＡＳメッセージに含めてリレー端末１０Ａに送信する。また、ＳＭＦ３２は、ＱｏＳ要求に対応するＵＬ／ＤＬ ＰＤＲをＵＰＦ３３に送信する。

一方、ＳＭＦ３２は、ＱｏＳ要求を受け入れることができないと判定した場合、ＳＭＦ３２は、ＱｏＳ要求を通知したノード（ＡＭＦ３１又はＰＣＦ３４等）に対し、ＱｏＳ要求を拒否することを示す情報（以下、「ＱｏＳ拒否情報」と言う。）を送信する。ＱｏＳ拒否情報は、ＱｏＳ変更不可情報と呼ばれてもよい。また、ＱｏＳ拒否情報は、ＰＤＵセッション変更拒否メッセージであってもよい。また、ＱｏＳ拒否情報には、ＱｏＳ要求を拒否した理由を示す情報（例えばCause値など）が含まれていてもよい。

図３の例では、ＳＭＦ３２は、ＡＭＦ３１から受信したＱｏＳ要求を受け入れることができないと判定したものとする。また、ＳＭＦ３２は、ＡＭＦ３１に対し、ＰＤＵセッション変更拒否メッセージを送信したものとする。

ステップＳ１１０で、ＡＭＦ３１は、ＮＡＳメッセージ（ＰＤＵセッション変更コマンド（PDU Session Modification Command））をリレー端末１０Ａに送信する。ＰＤＵセッション変更コマンドには、ＱｏＳ拒否情報が含まれる。

ステップＳ１１１で、リレー端末１０Ａは、ＱｏＳ拒否情報を含むＰＤＵセッション変更コマンドを受信した場合、ネットワークリソースが逼迫しており、ＱｏＳ要求を受け入れることができない状態であると認識する。続いて、リレー端末１０Ａは、ネットワークが、より要件の厳しいＱｏＳ要求を受け入れることができない状態であることを示すＱｏＳ状態情報（QoS=Full）を送信する。

本実施形態では、リレー端末１０Ａは、ＱｏＳ状態情報を、所定の周期でブロードキャストするようにしてもよい。例えば、リレー端末１０Ａは、ＱｏＳ状態情報を、ブロードキャスト用のチャネルで送信してもよい。また、リレー端末１０Ａは、ＱｏＳ状態情報を、物理サイドリンクディスカバリーチャネル（Physical Sidelink Discovery Channel：ＰＳＤＣＨ）で送信してもよいし、物理サイドリンク共通チャネル（Physical Sidelink Shared Channel：ＰＳＳＣＨ）で送信してもよい。また、リレー端末１０Ａは、ＱｏＳ状態情報を、ディスカバリーメッセージ（Discovery message：発見信号）内の所定の領域（フィールド）に含めて送信してもよい。

ステップＳ１１２で、リレー端末１０Ａは、リモート端末１０Ｂに、Ｌ２リンク変更応答（L2 link Modification Accept）を送信する。Ｌ２リンク変更応答には、ＱｏＳ拒否情報が含まれる。Ｌ２リンク変更応答はＱｏＳ状態による接続拒否を伝達するためのL2 Link Modification Accept以外のメッセージでもよい。

次に、基地局２０は、リレー端末１０Ａに接続している他のリモート端末１０Ｂが、リレー端末１０Ａとの接続を終了したり、リレー端末１０Ａがより帯域幅の広いバンドにハンドオーバーしたりといった理由により、ネットワークリソースに空きが生じたことを検出したとする。この場合、ステップＳ１５０で、基地局２０は、リレー端末１０Ａに対し、より要件の厳しいＱｏＳ要求を受け入れることが可能な状態であることを示す情報（以下、「ＱｏＳ許可情報」と言う。）ＡＮ固有リソース変更メッセージ（AN specific resource modification）を送信するようにしてもよい。ＡＮ固有リソース変更メッセージは、ＲＲＣメッセージであってもよい。

また、ＳＭＦ３２は、ネットワークリソースに空きが生じた結果、ＱｏＳ要求を受け入れることが可能になったことを検出した場合、リレー端末１０Ａに対し、ＡＭＦ３１を介して、ＱｏＳ許可情報を含むＮＡＳメッセージを送信するようにしてもよい。ＳＭＦ３２は、ＳＭＦ３２がＰＤＵセッションを管理している全てのリレー端末１０Ａに対して、ＱｏＳ許可情報を含むＮＡＳメッセージを送信するようにしてもよい。

ステップＳ１５１で、リレー端末１０Ａは、基地局２０又はＡＭＦ３１から、ＱｏＳ要求を受け入れることが可能な状態であることを示すＡＮ固有リソース変更メッセージ又はＮＡＳメッセージを受信した場合、ＱｏＳ要求を受け入れることが可能な状態であることを示すＱｏＳ状態情報（QoS=Normal）を送信する。

以上説明した処理手順において、リモート端末１０Ｂがレイヤ２リレーの場合、ステップＳ１０２及びステップＳ１１２の処理手順は省略される。また、ステップＳ１０３の処理手順では、リレー端末１０Ａではなくリモート端末１０Ｂが直接、所望するＱｏＳに対応するＱｏＳ指示子（例えば５ＱＩ等）を含むＰＤＵセッション変更要求をＡＭＦ３１に送信する。またステップＳ１１０の処理手順において、ＡＭＦ３１は、ＱｏＳ拒否情報が含まれるＰＤＵセッション変更コマンドを、リモート端末１０Ｂに送信する。

また、リモート端末１０Ｂがレイヤ２リレーの場合、リモート端末１０Ｂは、ＮＡＳメッセージ及びＲＲＣメッセージを受信することができないことが考えられる。そこで、ＡＭＦ３１は、ステップＳ１１０の処理手順において、基地局２０に対し、ＱｏＳ拒否情報を含むＮ２メッセージ（Ｎ２インタフェース上のメッセージ）を送信し、基地局２０は、ＱｏＳ拒否情報を含むＭＡＣメッセージ（ＭＡＣレイヤのメッセージ、例えばＭＡＣ ＰＤＵ（Protocol Data Unit）又はＭＡＣ ＣＥ（Control Element））を、リレー端末１０Ａに通知するようにしてもよい。レイヤ２リレーのリレー端末１０Ａは、ＭＡＣメッセージでＱｏＳ拒否情報を基地局２０から受信した場合、これ以上ＱｏＳ要求を受け入れることができない状態であることを示すＱｏＳ状態情報（QoS=Full）を送信するようにしてもよい。ステップＳ１５０の処理手順についても、基地局２０は、ＭＡＣメッセージに、ＱｏＳ許可情報を含めてリレー端末１０Ａに送信するようにしてもよい。レイヤ２リレーのリレー端末１０Ａは、ＭＡＣメッセージでＱｏＳ許可情報を基地局２０から受信した場合、ＱｏＳ要求を受け入れることが可能な状態であることを示すＱｏＳ状態情報（QoS=Normal）を送信するようにしてもよい。

（１．２）
図４は、ＱｏＳ状態を通知する際の処理手順の一例（パターン２）を示すシーケンス図である。図４の例は、基地局２０によりＱｏＳ要求が拒否された場合、リレー端末１０Ａは、ネットワークのリソースが逼迫していると判断し、ＱｏＳ要求を受け入れることができない状態であることを示すＱｏＳ状態情報を送信する。

ステップＳ１０１～ステップＳ１０３の処理手順は、それぞれ、図３のステップＳ１０１～ステップＳ１０３の処理手順と同一であるため、説明を省略する。

ステップＳ１０４で、基地局２０、ＡＭＦ３１、ＳＭＦ３２及びＵＰＦ３３の間でＰＤＵセッション変更処理（PDU Session Modification Procedure）が行われる。図４の例では、ＳＭＦ３２は、ＱｏＳ要求を受け入れると判定し、ＱｏＳ要求に対応するＱｏＳプロファイル及びＱｏＳルールを、ＡＭＦ３１に送信する。ＡＭＦ３１は、ＱｏＳプロファイルをＮ２メッセージに含めて基地局２０に送信し、ＱｏＳルールを、ＮＡＳメッセージに含めてリレー端末１０Ａに送信する。また、ＳＭＦ３２は、ＱｏＳ要求に対応するＰＤＲをＵＰＦ３３に送信する。

ここで、基地局２０は、例えば、リレー端末１０Ａから受信する無線信号の品質が劣化している等の理由で、これ以上のＱｏＳ要求を受け入れることができないと判定したとする。この場合、ステップＳ１２０で、基地局２０は、リレー端末１０Ａに対し、ＱｏＳ拒否情報を含むＡＮ固有リソース変更メッセージ（AN specific resource modification）を送信する。ＡＮ固有リソース変更メッセージは、ＲＲＣメッセージであってもよい。

ステップＳ１２１で、リレー端末１０Ａは、ＱｏＳ拒否情報を含むＡＮ固有リソース変更メッセージを受信した場合、ネットワークのリソースが逼迫しており、ＱｏＳ要求を受け入れることができない状態であると認識する。続いて、リレー端末１０Ａは、ネットワークが、より要件の厳しいＱｏＳ要求を受け入れることができない状態であることを示すＱｏＳ状態情報（QoS=Full）を送信する。

ステップＳ１２２、ステップＳ１５０及びステップＳ１５１の処理手順は、図３のステップＳ１１２、ステップＳ１５０及びステップＳ１５１の処理手順と同一であるため、説明を省略する。

リモート端末１０Ｂがレイヤ２リレーの場合、基地局２０は、ステップＳ１２０の処理手順において、ＭＡＣメッセージに、ＱｏＳ拒否情報を含めてリレー端末１０Ａに送信するようにしてもよい。

（１．３）
図５は、ＱｏＳ状態を通知する際の処理手順の一例（パターン３）を示すシーケンス図である。図５の例は、基地局２０がＱｏＳ要求を拒否する場合、基地局２０はＡＭＦ３１にＱｏＳ要求を拒否することを通知し、ＡＭＦ３１が、ＱｏＳ要求を拒否することをリレー端末１０Ａに通知する。リレー端末１０Ａは、ネットワークのリソースが逼迫していると判断し、ＱｏＳ要求を受け入れることができない状態であることを示すＱｏＳ状態情報を送信する。

ステップＳ１０１～ステップＳ１０４の処理手順は、それぞれ、図４のステップＳ１０１～ステップＳ１０４の処理手順と同一であるため、説明を省略する。

ＡＭＦ３１から、ＱｏＳ要求に対応するＱｏＳプロファイルを含むＮ２メッセージを受信した基地局２０は、例えば、リレー端末１０Ａから受信する無線信号の品質が劣化している等の理由で、ＱｏＳ要求を受け入れることができないと判定したとする。この場合、ステップＳ１３０で、基地局２０は、ＡＭＦ３１に対し、ＱｏＳ拒否情報を含むＮ２メッセージ（ＲＡＮリソース通知）を送信する。

なお、基地局２０は、無線品質が事後的に劣化した場合など、ＱｏＳ要求を満たすことが出来なくなったことを、ＰＤＵセッション変更完了後に検出した場合、ＱｏＳ要求を満たすことができなくなったＵｕ ＱｏＳフローのＱＦＩ及びＱｏＳ拒否情報を含むＮ２メッセージをＡＭＦ３１に送信するようにしてもよい。

ステップＳ１３１で、ＱｏＳ拒否情報を含むＮ２メッセージを受信したＡＭＦ３１は、ＮＡＳメッセージ（ＰＤＵセッション変更コマンド（PDU Session Modification Command））をリレー端末１０Ａに送信する。ＰＤＵセッション変更コマンドには、ＱｏＳ拒否情報が含まれる。

ステップＳ１３２、ステップＳ１３３、ステップＳ１５０及びステップＳ１５１の処理手順は、それぞれ、図３のステップＳ１１１、ステップＳ１１２、ステップＳ１５０及びステップＳ１５１の処理手順と同一であるため、説明を省略する。

リモート端末１０Ｂがレイヤ２リレーの場合、ＡＭＦ３１は、ステップ１３１の処理手順において、基地局２０に対し、ＱｏＳ拒否情報を含むＮ２メッセージ（Ｎ２インタフェース上のメッセージ）を送信し、基地局２０は、ＱｏＳ拒否情報を含むＭＡＣメッセージを、リレー端末１０Ａに通知するようにしてもよい。レイヤ２リレーのリレー端末１０Ａは、ＭＡＣメッセージでＱｏＳ拒否情報を基地局２０から受信した場合、これ以上ＱｏＳ要求を受け入れることができない状態であることを示すＱｏＳ状態情報（QoS=Full）を送信するようにしてもよい。

以上説明したように、ＱｏＳ要求が拒否された場合、リレー端末１０Ａは、ネットワークのリソースが逼迫していると判断し、ネットワークが、ＱｏＳ要求を受け入れることができない状態であることを示すＱｏＳ状態情報を送信する。これにより、リモート端末１０Ｂは、リレー端末１０Ａを探して通信を開始する際、ＱｏＳの要求を受け入れることが可能なリレー端末１０Ａを選択して通信を試みることが可能になり、ＱｏＳの要求を受け入れることができないリレー端末１０Ａとの間で無駄に通信を行うことなく、通信を開始することが可能になる。

以上説明した（１．１）～（１．３）において、ＱｏＳ拒否情報には、受入可能なＱｏＳ又は受入不可能なＱｏＳを示す情報が含まれるようにしてもよい。例えば、受入可能なＱｏＳを示す情報として、受入可能なＱｏＳ特性を示す識別子（５ＱＩ等）が含まれていてもよい。同様に、受入不可能なＱｏＳを示す情報として、受入不可能なＱｏＳ特性を示す識別子（５ＱＩの値等）が含まれていてもよい。また、リレー端末１０Ａは、ＱｏＳ状態情報に、受入可能なＱｏＳ又は受入不可能なＱｏＳを示す情報を含めて送信するようにしてもよい。このとき、リレー端末１０Ａは、レイヤ３リレーとして動作する場合、基地局２０から通知された、受入可能なＱｏＳ特性又は受入不可能なＱｏＳ特性を示す識別子を、マッピングテーブルに基づき、ＰＣ５インタフェースで用いられるＱｏＳ特性を示す識別子（ＰＱＩ等）に変換し、変換後のＱｏＳ特性を示す識別子を、ＱｏＳ状態情報に含めて送信するようにしてもよい。これにより、リレー端末１０Ａに接続しているリモート端末１０Ｂが多い環境であっても、リモート端末１０Ｂは、ＱｏＳ要求を受け入れ可能なリレー端末１０Ａを発見できる可能性を高めることが可能になる。

（２）優先度に基づくＱｏＳ制御
（２．１）
図６は、優先度に基づくＱｏＳ制御における処理手順の一例（パターン１）を示すシーケンス図である。図６の例では、リモート端末１０Ｂ－ＹのＱｏＳ要求がＳＭＦ３２により拒否された場合、リレー端末１０Ａは、リレー端末１０Ａと通信をしている複数のリモート端末１０Ｂ－Ｘのうち、優先度が低いリモート端末１０Ｂ－ＸのＱｏＳを、より要件の緩いＱｏＳに変更又は解除する。

ステップＳ２０１、ステップＳ２０２及びステップＳ２２０の処理手順は、図３のステップＳ１０１、ステップＳ１０２及びステップＳ１０３における説明において、リモート端末１０Ｂを、リモート端末１０Ｂ－Ｙに置き換えたものと同一であるため、説明は省略する。

ステップＳ２２１で、ＡＭＦ３１は、ＰＤＵセッション変更要求に含まれる、リモート端末１０Ｂ－Ｙに関するＱｏＳ指示子等を、ＰＤＵセッション更新要求メッセージ（Nsmf_PDUSession_UpdateSMContext）に含めてＳＭＦ３２に送信する。

ステップＳ２２２で、ＳＭＦ３２は、例えば、ネットワークのトラフィック状況等に基づき、当該メッセージに含まれるＱｏＳ指示子で示されるＱｏＳ要求を受け入れ可能か否かを判定する。ＳＭＦ３２はどのような方法で判定してもよいが、例えば、既に各端末１０との間で確立済みのＰＤＵセッション数や、ビットレート保障型のＱｏＳフローの数などに応じて、ＱｏＳ要求を受け入れ可能か否かを判定するようにしてもよい。ここでは、ＳＭＦ３２は、ＱｏＳ要求を受け入れることはできないと判定したとする。

ステップＳ２２３で、ＳＭＦ３２は、リモート端末１０Ｂ－ＹのＱｏＳ要求を拒否するＱｏＳ拒否情報を含むＰＤＵセッション変更応答（Response of Nsmf_PDUSession_UpdateSMContext）を、ＡＭＦ３１に送信する。なお、「リモート端末１０Ｂ－ＹのＱｏＳ要求」とは、リモート端末１０Ｂ－Ｙに対応するＵｕ ＱｏＳフローについてのＱｏＳ要求を意味する。

ステップＳ２２４で、ＡＭＦ３１は、リモート端末１０Ｂ－ＹのＱｏＳ要求を拒否するＱｏＳ拒否情報を含むＰＤＵセッション変更コマンド（PDU Session Modification Command）を、リレー端末１０Ａに送信する。

ステップＳ２２５で、ＡＭＦ３１から、ＱｏＳ拒否情報を含むＰＤＵセッション変更コマンドを受信したリレー端末１０Ａは、当該リレー端末１０Ａと通信をしている複数のリモート端末１０Ｂ－Ｘのうち、優先度が低いリモート端末１０Ｂ－Ｘを選択する。複数のリモート端末１０Ｂ－Ｘの優先度はどのように定められていてもよいが、例えば、各リモート端末１０Ｂ－ＸのＰＱＩ（又は変換後の５ＱＩ）により示される優先レベルが、各リモート端末１０Ｂ－Ｘの優先度に対応することとしてもよい。

ステップＳ２２６で、リレー端末１０Ａは、ステップＳ２２５の処理手順で選択した、優先度が低いリモート端末１０Ｂ－ＸのＱｏＳを、より要件の緩いＱｏＳに変更又は解除するために、当該リモート端末１０Ｂ－Ｘに対応するＵｕ ＱｏＳフローのＱｏＳ指示子を含むＰＤＵセッション変更要求をＡＭＦ３１に送信する。

ステップＳ２２７で、基地局２０、ＡＭＦ３１、ＳＭＦ３２及びＵＰＦ３３の間でＰＤＵセッション変更処理（PDU Session Modification Procedure）が行われ、リモート端末１０Ｂ－Ｘに対応するＵｕ ＱｏＳフローが、より要件の緩いＱｏＳに変更又は解除される。

ステップＳ２２８で、ＡＭＦ３１は、ステップＳ２２７の処理手順で変更されたＱｏＳの値（５ＱＩ）、又はＵｕ ＱｏＳフローの解除を指示する情報を、ＰＤＵセッション変更コマンドに含めてリレー端末１０Ａに通知する。

ステップＳ２２９で、リレー端末１０Ａは、ステップＳ２２８の処理手順で通知されたＱｏＳ値（５ＱＩ）を、マッピングテーブルに基づいてＰＱＩに変換する。続いて、リレー端末１０Ａは、変換後のＰＱＩを含むＬ２リンク変更信号又はＰＣ５ ＱｏＳフローの解除を指示する情報を、リモート端末１０Ｂ－Ｘに送信する。これにより、リモート端末１０Ｂ－ＸのＰＣ５ ＱｏＳフロー及びＵｕ ＱｏＳフローが、より要件の緩いＱｏＳに変更又は解除される。なお、リモート端末１０Ｂ－ＸのＰＣ５ ＱｏＳフロー及び／又はＵｕ ＱｏＳフローが解除されることは、リモート端末１０Ｂ－Ｘの通信が切断されることと同義であってもよい。

リレー端末１０Ａは、リモート端末１０Ｂ－ＹにおけるＱｏＳ要求が許可されるまで、ステップＳ２２０～ステップＳ２２９の処理手順を繰り返すことで、優先度の低いリモート端末１０Ｂ－ＸのＱｏＳを、より要件の緩いＱｏＳに変更又は解除していく。

ここで、優先度の低いリモート端末１０Ｂ－ＸのＱｏＳが、より要件の緩いＱｏＳに変更又は解除されることで、ネットワークリソースに空きが生じたことを検出したとする。この場合、ステップＳ２２２の処理手順で、ＳＭＦ３２は、ＱｏＳ要求を許可する。この場合、ステップＳ２４０の処理手順に進む。

ステップＳ２４０で、基地局２０、ＡＭＦ３１、ＳＭＦ３２及びＵＰＦ３３の間でＰＤＵセッション変更処理（PDU Session Modification Procedure）が行われ、リモート端末１０Ｂ－Ｙに対応するＵｕ ＱｏＳフローが、要求されたＱｏＳに変更される。

ステップＳ２４１で、ＡＭＦ３１は、ステップＳ２４０の処理手順で変更された、リモート端末１０Ｂ－ＹのＱｏＳ値（５ＱＩ）を、ＰＤＵセッション変更コマンドに含めてリレー端末１０Ａに通知する。

ステップＳ２４２で、リレー端末１０Ａは、ステップＳ２４１の処理手順で通知されたＱｏＳ値（５ＱＩ）を、マッピングテーブルに基づいてＰＱＩに変換し、リモート端末１０Ｂ－Ｙとの間におけるＰＣ５ ＱｏＳフローのＱｏＳを、変換後のＰＱＩに変更する。続いて、リレー端末１０Ａは、変換後のＰＱＩを含むＬ２リンク変更応答を、リモート端末１０Ｂ－Ｙに送信する。これにより、リモート端末１０Ｂ－ＹのＰＣ５ ＱｏＳフロー及びＵｕ ＱｏＳフローが、より条件の厳しいＱｏＳ要求を反映したフローに変更される。

次に、リレー端末１０Ａは、ステップＳ２２０～ステップＳ２２９の処理手順を繰り返すことで、優先度の低い全てのリモート端末１０Ｂ－ＸのＱｏＳを、より要件の緩いＱｏＳに変更、あるいは優先度の低いリモート端末１０Ｂ－Ｘの切断処理によってもネットワークリソースに空きが生じなかった（つまり、ステップＳ２４１の処理手順で示すメッセージを受信できなかった）と仮定する。この場合、ステップＳ２６０の処理手順に進む。

ステップＳ２６０で、リレー端末１０Ａは、ＱｏＳ拒否情報を含むＬ２リンク変更応答を、リモート端末１０Ｂ－Ｙに送信する。

（２．２）
図７は、優先度に基づくＱｏＳ制御における処理手順の一例（パターン２）を示すシーケンス図である。図７の例では、リモート端末１０Ｂ－ＹのＱｏＳ要求がＳＭＦ３２により拒否された場合、優先度が高いリモート端末１０Ｂ－ＹのＱｏＳを変更するために、優先度が低いリモート端末１０Ｂ－ＸのＱｏＳを変更又は解除することをＳＭＦ３２に通知する。ＳＭＦ３２は、優先度が低いリモート端末１０Ｂ－ＸのＱｏＳを変更又は解除することで、ネットワークリソースの消費量が削減され、優先度が高いリモート端末１０Ｂ－ＹのＱｏＳ要求を許可することが可能であるか否かを判断する。リモート端末１０Ｂ－ＹのＱｏＳ要求を許可する場合、ＳＭＦ３２は、リモート端末１０Ｂ－Ｘ及びリモート端末１０Ｂ－ＹのＱｏＳを変更又はリモート端末１０Ｂ－ＸのＱｏＳを解除する。

ステップＳ３０１、ステップＳ３０２、ステップＳ３０３、ステップＳ３０４、ステップＳ３０５、ステップＳ３０６、ステップＳ３０７及びステップＳ３２０の処理手順は、それぞれ、図６のステップＳ２０１、ステップＳ２０２、ステップＳ２２０、ステップＳ２２１、ステップＳ２２２、ステップＳ２２３、ステップＳ２２４及びステップＳ２２５の処理手順と同一であるため、説明は省略する。

ステップＳ３２１で、リレー端末１０Ａは、リモート端末１０Ｂ－ＹのＱｏＳ指示子と、ステップＳ３２０の処理手順で選択された、優先度が低いリモート端末１０Ｂ－ＸのＱｏＳがＱｏＳ変更の対象であることを示す情報を含む、ＰＤＵセッション変更要求をＡＭＦ３１に送信する。なお、「ＱｏＳ変更」とは、ＱｏＳをより要件の緩いＱｏＳ（デフォルトＱｏＳであってもよい）に変更すること、あるいは優先度の低い端末の切断（当該ＱｏＳフローの解除）を意味している。

ステップＳ３２２で、ＡＭＦ３１は、リモート端末１０Ｂ－ＹのＱｏＳ指示子と、優先度が低いリモート端末１０Ｂ－ＸのＱｏＳがＱｏＳ変更対象であることを示す情報を含む、ＰＤＵセッション更新要求をＳＭＦ３２に送信する。

ステップＳ３２３で、ＳＭＦ３２は、優先度が低いリモート端末１０Ｂ－ＸのＱｏＳを、より要件の緩いＱｏＳに変更又はＱｏＳフローを解除することで、優先度が高いリモート端末１０Ｂ－ＹのＱｏＳ要求を許可することが可能であるか否かを判断する。許可することができないと判断された場合はステップＳ３２４の処理手順に進み、許可可能と判断された場合はステップＳ３４０の処理手順に進む。

ステップＳ３２４及びステップＳ３２５の処理手順は、それぞれ、ステップＳ３０６及びステップＳ３０７の処理手順と同一であるため説明は省略する。

ステップＳ３４０で、基地局２０、ＡＭＦ３１、ＳＭＦ３２及びＵＰＦ３３の間でＰＤＵセッション変更処理（PDU Session Modification Procedure）が行われ、リモート端末１０Ｂ－Ｘに対応するＵｕ ＱｏＳフローが、より要件の緩いＱｏＳに変更又は解除される。

ステップＳ３４１で、ＡＭＦ３１は、ステップＳ３４０の処理手順で変更された、リモート端末１０Ｂ－ＸのＱｏＳ値（５ＱＩ）又はＵｕ ＱｏＳフローの解除を指示する情報を、ＰＤＵセッション変更コマンドに含めてリレー端末１０Ａに通知する。

ステップＳ３４２で、リレー端末１０Ａは、ステップＳ３４１の処理手順で通知されたＱｏＳ値（５ＱＩ）を、マッピングテーブルに基づいてＰＱＩに変換し、リモート端末１０Ｂ－Ｘとの間におけるＰＣ５ ＱｏＳフローのＱｏＳを、変換後のＰＱＩに変更する。続いて、リレー端末１０Ａは、変換後のＰＱＩ又はＰＣ５ ＱｏＳフローの解除を指示する情報を含むＬ２リンク変更メッセージを、リモート端末１０Ｂ－Ｘに送信する。これにより、リモート端末１０Ｂ－ＸのＰＣ５ ＱｏＳフロー及びＵｕ ＱｏＳフローが、より要件の緩いＱｏＳに変更又は解除される。

ステップＳ３４３で、基地局２０、ＡＭＦ３１、ＳＭＦ３２及びＵＰＦ３３の間でＰＤＵセッション変更処理（PDU Session Modification Procedure）が行われ、リモート端末１０Ｂ－Ｙに対応するＵｕ ＱｏＳフローが、要求されたＱｏＳに変更される。

ステップＳ３４４で、ＡＭＦ３１は、ステップＳ３４３の処理手順で変更された、リモート端末１０Ｂ－ＹのＱｏＳ値（５ＱＩ）を、ＰＤＵセッション変更コマンドに含めてリレー端末１０Ａに通知する。

ステップＳ３４５で、リレー端末１０Ａは、ステップＳ３４４の処理手順で通知されたＱｏＳ値（５ＱＩ）を、マッピングテーブルに基づいてＰＱＩに変換し、リモート端末１０Ｂ－Ｙとの間におけるＰＣ５ ＱｏＳフローのＱｏＳを、変換後のＰＱＩに変更する。続いて、リレー端末１０Ａは、変換後のＰＱＩを含むＬ２リンク変更応答を、リモート端末１０Ｂ－Ｙに送信する。これにより、リモート端末１０Ｂ－ＹのＰＣ５ ＱｏＳフロー及びＵｕ ＱｏＳフローが、要求されたＱｏＳを反映したフローに変更される。

次に、リレー端末１０Ａは、ステップＳ３２０～ステップＳ３２５の処理手順を繰り返すことで、優先度の低い全てのリモート端末１０ＢのＱｏＳを、より要件の緩いＱｏＳに変更あるいは解除しても、ネットワークリソースに空きが生じなかった（つまり、ステップＳ３４１又はステップＳ３４４の処理手順で示すメッセージを受信できなかった）と仮定する。この場合、ステップＳ３６０の処理手順に進む。

ステップＳ３６０の処理手順は、図６のステップＳ２６０と同一であるため、説明は省略する。

（２．３）
図８は、優先度に基づくＱｏＳ制御における処理手順の一例（パターン３）を示すシーケンス図である。ＳＭＦ３２は、リモート端末１０Ｂ－ＹのＱｏＳ要求を許可できない場合、ＳＭＦ３２は、リレー端末１０Ａと通信をしている複数のリモート端末１０Ｂ－Ｘのうち、優先度が低いリモート端末１０Ｂ－ＸのＱｏＳを、より要件の緩いＱｏＳに変更又は解除する。

ステップＳ４０１、ステップＳ４０２、ステップＳ４０３及びステップＳ４０４の処理手順は、それぞれ、図６のステップＳ２０１、ステップＳ２０２、ステップＳ２２０及びステップＳ２２１の処理手順と同一であるため、説明は省略する。

ステップＳ４２０で、ＳＭＦ３２は、例えば、ネットワークのトラフィック状況等に基づき、ＰＤＵセッション変更要求メッセージに含まれるＱｏＳ指示子で示されるＱｏＳ要求を受け入れ可能か否かを判定する。受入不可能と判断した場合はステップＳ４２１の処理手順に進み、受入可能と判断した場合はステップＳ４４０の処理手順に進む。

ステップＳ４２１で、ＳＭＦ３２は、リレー端末１０Ａと通信をしている複数のリモート端末１０Ｂ－Ｘのうち、優先度が低いリモート端末１０Ｂ－Ｘを選択する。例えば、ＳＭＦ３２は、ステップＳ４０１の処理手順でＰＤＵセッションを確立（又は変更）する際、リレー端末１０Ａから、リレー端末１０Ａと通信をしている複数のリモート端末１０Ｂ－Ｘの優先順位リストを取得することとしてもよい。当該優先順位リストには、例えば、ＰＤＵセッションＩＤ及びＱＦＩにより特定されるＱｏＳフローと端末優先順位とが対応づけられていてもよい。ＳＭＦ３２は、当該優先順位リストに基づいて、優先度が低いリモート端末１０Ｂ－Ｘ（若しくは、優先度が低いリモート端末１０Ｂ－Ｘに対応するＵｕ ＱｏＳフロー）を選択するようにしてもよい。

また、ＳＭＦ３２は、リレー端末１０Ａとの間で確立されている１又は複数のＰＤＵセッションに対応づけられる全てのＱｏＳフロー（Ｕｕ ＱｏＳフロー）のうち、各ＱｏＳフローにおける５ＱＩの値により示される優先レベルが、各リモート端末１０Ｂ－Ｘの優先度に対応するとみなすようにしてもよい。また、最も優先レベルの低いＱｏＳフローが複数存在する場合、ＳＭＦ３２は、これらの複数のＱｏＳフローの中からいずれか１つのＱｏＳフローを選択することとしてもよい。

ステップＳ４２２、ステップＳ４２３及びステップＳ４２４の処理手順は、それぞれ、図７のステップＳ３４０、ステップＳ３４１及びステップＳ３４２の処理手順と同一であるため、説明は省略する。

なお、ＳＭＦ３２は、ステップＳ４２０の処理手順において、リモート端末１０Ｂ－ＹのＱｏＳ要求を受け入れ可能と判断できるまで、ステップＳ４２０～ステップＳ４２２の処理手順を繰り返し実行することとしてもよい。これにより、優先度が低いリモート端末１０Ｂ－Ｘに対して、ステップＳ４２３及びステップＳ４２４の処理手順が実行され、より要件の緩いＱｏＳに変更若しくはＱｏＳフローが解除さることになる。また、ＳＭＦ３２は、ステップＳ４２０及びステップＳ４２１の処理手順において、リモート端末１０Ｂ－ＹのＱｏＳ要求を受け入れるために、より要件の緩いＱｏＳに変更又は解除が必要な１以上のリモート端末１０Ｂ－Ｘを予め決定し、決定した１以上のリモート端末１０Ｂ－Ｘの各々について、ステップＳ４２２の処理手順を実行することとしてもよい。これにより、優先度が低いリモート端末１０Ｂ－Ｘに対して、ステップＳ４２３及びステップＳ４２４の処理手順が実行され、より要件の緩いＱｏＳに変更若しくはＱｏＳフローが解除さることになる。

ステップＳ４４０、ステップＳ４４１及びステップＳ４４２の処理手順は、それぞれ、図７のステップＳ３４３、ステップＳ３４４及びステップＳ３４５の処理手順と同一であるため、説明は省略する。

次に、ＳＭＦ３２は、優先度の低い全てのリモート端末１０Ｂ－ＸのＱｏＳを、より要件の緩いＱｏＳに変更又は解除しても、リモート端末１０Ｂ－ＹのＱｏＳ要求を受け入れることができないと判断した場合、ステップＳ４６０の処理手順に進む。

ステップＳ４６０、ステップＳ４６１及びステップＳ４６２の処理手順は、それぞれ、図７のステップＳ３０６、ステップＳ３０７及びステップＳ３６０の処理手順と同一であるため、説明は省略する。

（２．４）
図９は、優先度に基づくＱｏＳ制御における処理手順の一例（パターン４）を示すシーケンス図である。図９の例では、リモート端末１０Ｂ－ＹのＱｏＳ要求を、ＡＦ３５から送信する。また、ＳＭＦ３２は、ＡＦ３５から要求されたＱｏＳを許可できない場合、ＳＭＦ３２は、リレー端末１０Ａと通信をしている複数のリモート端末１０Ｂ－Ｘのうち、優先度が低いリモート端末１０Ｂ－ＸのＱｏＳを、より要件の緩いＱｏＳに変更又は解除する。

ステップＳ５０１の処理手順は、図６のステップＳ２０１の処理手順と同一であるため、説明を省略する。

ステップＳ５０２で、リモート端末１０Ｂ－Ｙは、ＡＦ３５との間で、アプリケーションレイヤのインタフェースを用いてサービスセットアップ手順を行う。

ステップＳ５０３で、ＡＦ３５は、ＰＣＦ３４に、リモート端末１０Ｂ－ＹのＵｕ ＱｏＳフローを特定する情報（例えばＰＤＵセッションＩＤ及びＱＦＩ等）と、当該Ｕｕ ＱｏＳフローについてのＱｏＳ指示子を含むサービス要件（Service Requirement）を、Ｎ５インタフェースのメッセージを用いて送信する。

ステップＳ５０４で、ＰＣＦ３４は、リモート端末１０Ｂ－ＹのＵｕ ＱｏＳフローを特定する情報と、当該Ｕｕ ＱｏＳフローについてのＱｏＳ指示子とを含むＱｏＳ変更要求メッセージ（QoS Modification）をＳＭＦ３２に送信する。

ステップＳ５２０で、ＳＭＦ３２は、ネットワークのトラフィック状況等に基づき、ＱｏＳ変更要求メッセージに含まれるＱｏＳ指示子で示されるＱｏＳ要求を受け入れ可能か否かを判定する。受入不可能と判断した場合はステップＳ５２１の処理手順に進み、受入可能と判断した場合はステップＳ５４０の処理手順に進む。

ステップＳ５２１の処理手順は、図８のステップＳ４２２の処理手順と同一であるため説明を省略する。

ステップＳ５２２で、ＳＭＦ３２は、優先度の低いリモート端末１０Ｂ－ＸのＱｏＳを、より要件の緩いＱｏＳに変更又は解除することを示すＰＤＵセッション変更通知メッセージ（Nsmf_PDUSession_SMContextStatusNotify）をＡＭＦ３１に送信する。

ステップＳ５２３で、ＡＭＦ３１は、リモート端末１０Ｂ－Ｘに対応するＵｕ ＱｏＳフローのＱｏＳを変更又はＵｕ ＱｏＳフローを解除することを示す、ＮＡＳメッセージ（ＰＤＵセッション変更コマンド（PDU Session Modification Command））をリレー端末１０Ａに送信する。

ステップＳ５２４で、リレー端末１０Ａは、リモート端末１０Ｂ－ＸのＱｏＳを変更又は解除することを示す、ＮＡＳメッセージ（ＰＤＵセッション変更要求（PDU Session Modification Request））を、ＡＭＦ３１に送信する。

ステップＳ５２５、ステップＳ５２６及びステップＳ５２７の処理手順は、それぞれ、図７のステップＳ３４０、ステップＳ３４１及びステップＳ３４２の処理手順と同一であるため、説明は省略する。

ステップＳ５４０、ステップＳ５４１及びステップＳ５４２の処理手順は、それぞれ、図７のステップＳ３４３、ステップＳ３４４及びステップＳ３４５の処理手順と同一であるため、説明は省略する。

次に、ＳＭＦ３２は、優先度の低い全てのリモート端末１０Ｂ－ＸのＱｏＳを、より要件の緩いＱｏＳに変更又は解除しても、リモート端末１０Ｂ－ＹのＱｏＳ要求を受け入れることができないと判断した場合、ステップＳ５６０の処理手順に進む。

ステップＳ５６０で、ＳＭＦ３２は、ＱｏＳ拒否情報を含む、ＱｏＳ変更応答メッセージをＰＣＦ３４に送信する。

ステップＳ５６１で、ＰＣＦ３４は、ＱｏＳ拒否情報を含むサービス要件応答を、Ｎ５インタフェースのメッセージを用いて送信する。

以上説明したように、ＱｏＳ要求が拒否された場合、より優先度の低いリモート端末１０ＢのＱｏＳを変更又は解除することで、ネットワークリソースの消費量を削減し、ＱｏＳ要件が厳しいリモート端末１０Ｂが通信を行うことができるようにした。これにより、ミッションクリティカル通信など優先度の高い通信を行うリモート端末１０Ｂは、ネットワークのリソースが逼迫している状況であっても、ネットワークの所望するＱｏＳ要件に従って通信を開始することが可能になる。

＜ハードウェア構成＞
図１０は、本実施形態に係る通信システム内の各装置のハードウェア構成の一例を示す図である。通信システム１内の各装置は、図１に示されるどの装置であってもよく、例えば、端末１０、基地局２０、コアネットワーク３０内のコアネットワーク装置である。図１０における符号「３０」は、コアネットワーク３０内のコアネットワーク装置を意味し、ＡＭＦ３１、ＳＭＦ３２、ＵＰＦ３３、ＰＣＦ３４及びＡＦ３５を総称するものとする。

通信システム１内の各装置は、プロセッサ１１、記憶装置１２、有線又は無線通信を行う通信装置１３、各種の入力操作を受け付ける入力装置や各種情報の出力を行う入出力装置１４を含む。

プロセッサ１１は、例えば、ＣＰＵ（Central Processing Unit）であり、通信システム１内の各装置を制御する。プロセッサ１１は、プログラムを記憶装置１２から読み出して実行することで、本実施形態で説明する各種の処理を実行してもよい。通信システム１内の各装置は、１又は複数のプロセッサ１１により構成されていてもよい。また、当該各装置は、コンピュータと呼ばれてもよい。

記憶装置１２は、例えば、メモリ、ＨＤＤ（Hard Disk Drive）及び／又はＳＳＤ（Solid State Drive）等のストレージから構成される。記憶装置１２は、プロセッサ１１による処理の実行に必要な各種情報（例えば、プロセッサ１１によって実行されるプログラム等）を記憶してもよい。

通信装置１３は、有線及び／又は無線ネットワークを介して通信を行う装置であり、例えば、ネットワークカード、通信モジュール、チップ、アンテナ等を含んでもよい。また、端末１０及び基地局２０の場合、通信装置１３には、アンプ、無線信号に関する処理を行うＲＦ（Radio Frequency）装置と、ベースバンド信号処理を行うＢＢ（BaseBand）装置とを含んでいてもよい。

入出力装置１４は、例えば、キーボード、タッチパネル、マウス及び／又はマイク等の入力装置と、例えば、ディスプレイ及び／又はスピーカ等の出力装置とを含む。

以上説明したハードウェア構成は一例に過ぎない。通信システム１内の各装置は、図１０に記載したハードウェアの一部が省略されていてもよいし、図１０に記載されていないハードウェアを備えていてもよい。また、図１０に示すハードウェアが１又は複数のチップにより構成されていてもよい。

＜機能ブロック構成＞
（リレー端末）
図１１は、リレー端末１０Ａの機能ブロック構成例を示す図である。図１１に示すように、リレー端末１０Ａは、受信部１０１と、送信部１０２と、制御部１０３とを、有する。

なお、受信部１０１と送信部１０２とが実現する機能の全部又は一部は、通信装置１３を用いて実現することができる。また、受信部１０１と送信部１０２とが実現する機能の全部又は一部と、制御部１０３とは、プロセッサ１１が、記憶装置１２に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体（Non-transitory computer readable medium）であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、ＵＳＢメモリ又はＣＤ－ＲＯＭ等の記憶媒体であってもよい。

受信部１０１は、下り信号を受信する。また、受信部１０１は、下り信号を介して伝送された情報及び／又はデータを受信してもよい。ここで、「受信する」とは、例えば、無線信号の受信、デマッピング、復調、復号、モニタリング、測定の少なくとも一つ等の受信に関する処理を行うことを含んでもよい。

送信部１０２は、上り信号を送信する。また、送信部１０２は、上り信号を介して伝送される情報及び／又はデータを送信してもよい。ここで、「送信する」とは、例えば、符号化、変調、マッピング、無線信号の送信の少なくとも一つ等の送信に関する処理を行うことを含んでもよい。以下の説明では、ＱｏＳの変更には、ＱｏＳの解除（ＱｏＳフローの解除）も含まれる。

制御部１０３は、リレー端末１０Ａにおける各種制御を行う。例えば、制御部１０３は、リモート端末１０Ｂと基地局２０及びコアネットワーク３０（ネットワーク装置）との間における通信を中継する制御を行う。また、制御部１０３は、リモート端末１０Ｂ間のＱｏＳフロー（第１ＱｏＳフロー、ＰＣ５ ＱｏＳフロー）のＱｏＳ要件を示す値（第１ＱｏＳ値、ＰＱＩ）と、基地局２０及びコアネットワーク３０（ネットワーク装置）との間のＱｏＳフロー（第２ＱｏＳフロー、Ｕｕ ＱｏＳフロー）のＱｏＳ要件を示す値（第２ＱｏＳ値、５ＱＩ）とを、マッピングテーブルを用いて、相互に変換する。

また、送信部１０２（第１送信部）は、受信部１０１がリモート端末１０Ｂ（端末１０）からＱｏＳ要求（ＱｏＳ指示子）を受信した場合に、ＱｏＳ要求をＡＭＦ３１（ネットワーク装置）に送信する（図３、図４、図５）。

また、受信部１０１は、ＡＭＦ３１から、ＱｏＳ要求を拒否することを示すＱｏＳ拒否情報（第１情報）を受信する（図３、図４、図５）。また、受信部１０１は、ＱｏＳ拒否情報を含むＲＲＣメッセージを受信するようにしてもよい（図４）。また、受信部１０１は、ＱｏＳ拒否情報を含むＮＡＳメッセージを受信するようにしてもよい（図３、図５）。また、ＱｏＳ拒否情報は、ＱｏＳ要求を拒否することを示す情報であり、ＱｏＳ要求を拒否した理由を示す情報を含んでいてもよい（図３のＳ１１０）。

また、送信部１０２（第２送信部）は、ＱｏＳ拒否情報を受信した場合に、ＱｏＳ要求を受け入れることができない状態であることを示す情報を含むＱｏＳ状態情報（メッセージ）を送信する（図３、図４、図５）。なお、送信部１０２は、ＱｏＳ状態情報を、周囲の端末１０に向けてブロードキャストするようにしてもよい。

また、受信部１０１は、ＡＭＦ３１（ネットワーク装置）又は基地局２０から、ＱｏＳ要求を許可することを示すＱｏＳ許可情報（第２情報）を受信するようにしてもよい（図３、図４、図５）。

また、送信部１０２（第２送信部）は、受信部１０１でＱｏＳ許可情報を受信した場合に、ＱｏＳ要求を受け入れることが可能な状態であることを示すＱｏＳ状態情報（メッセージ）を送信するようにしてもよい（図３、図４、図５）。

送信部１０２は、受信部１０１がリモート端末１０Ｂ－Ｙ（第１端末）からＱｏＳ要求（ＱｏＳ指示子）を受信した場合に、ＱｏＳ要求をＡＭＦ３１（ネットワーク装置）に送信する（図６のＳ２２０）。

また、受信部１０１は、ＡＭＦ３１（ネットワーク装置）から、ＱｏＳ要求を拒否することを示すＱｏＳ拒否情報を受信する（図６のＳ２２４）。

また、制御部１０３は、受信部１０１でＱｏＳ拒否情報を受信した場合に、リレー端末１０Ａと通信する１以上のリモート端末１０Ｂの中からリモート端末１０Ｂ－Ｘ（第２端末）を選択する。制御部１０３は、１以上のリモート端末１０Ｂの中から、リモート端末１０Ｂ－Ｙ（第１端末）よりも優先度が低いリモート端末１０Ｂ－Ｘ（第２端末）を選択するようにしてもよい（図６のＳ２２５）。

また、送信部（第２送信部）は、リモート端末１０Ｂ－Ｘ（第２端末）のＱｏＳ要求を変更することを要求するメッセージ（ＰＤＵセッション変更要求）を、ＡＭＦ３１（ネットワーク装置）に送信する（図６のＳ２２６）。

（基地局）
図１２は、基地局２０の機能ブロック構成例を示す図である。図１２に示すように、基地局２０は、受信部２０１と、送信部２０２と、制御部２０３とを、有する。

なお、受信部２０１と送信部２０２とが実現する機能の全部又は一部は、通信装置１３を用いて実現することができる。また、受信部２０１と送信部２０２とが実現する機能の全部又は一部と、制御部２０３とは、プロセッサ１１が、記憶装置１２に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、ＵＳＢメモリ又はＣＤ－ＲＯＭ等の記憶媒体であってもよい。

受信部２０１は、上り信号を受信する。また、受信部１０１は、上り信号を介して伝送された情報及び／又はデータを受信してもよい。ここで、「受信する」とは、例えば、無線信号の受信、デマッピング、復調、復号、モニタリング、測定の少なくとも一つ等の受信に関する処理を行うことを含んでもよい。

送信部２０２は、下り信号を送信する。また、送信部１０２は、下り信号を介して伝送される情報及び／又はデータを送信してもよい。ここで、「送信する」とは、例えば、符号化、変調、マッピング、無線信号の送信の少なくとも一つ等の送信に関する処理を行うことを含んでもよい。

制御部２０３は、無線レイヤにおけるスケジューリング処理を行う。また、制御部２０３は、リレー端末１０Ａとの間の無線リソース（ネットワークリソース）に空きが生じたか否かを検出する。より具体的には、無線リソースの使用率が所定の閾値以下になったことを検出した場合であってもよい。制御部２０３により、無線リソースに空きが生じたことが検出された場合、送信部２０２は、リレー端末１０Ａに対し、ＱｏＳ要求を許可することを示すＱｏＳ許可情報（第２情報）を送信するようにしてもよい。また、送信部２０２は、当該ＱｏＳ許可情報を、ＲＲＣメッセージでリレー端末１０Ａに送信してもよいし、ＭＡＣメッセージでリレー端末１０Ａに送信してもよい。

（ＡＭＦ）
図１３は、ＡＭＦ３１の機能ブロック構成例を示す図である。図１３に示すように、ＡＭＦ３１は、受信部３０１と、送信部３０２と、制御部３０３とを、有する。

なお、受信部３０１と送信部３０２とが実現する機能の全部又は一部は、通信装置１３を用いて実現することができる。また、受信部３０１と送信部３０２とが実現する機能の全部又は一部と、制御部３０３とは、プロセッサ１１が、記憶装置１２に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、ＵＳＢメモリ又はＣＤ－ＲＯＭ等の記憶媒体であってもよい。

受信部３０１は、基地局２０又はコアネットワーク３０内の他の装置から信号を受信する。また、受信部３０１（第１受信部）は、リレー端末１０Ａから、ＱｏＳ要求を受信する（図５のＳ１０３）。

送信部３０２は、基地局２０又はコアネットワーク３０内の他の装置に対して信号を送信する。また、送信部３０２（第１送信部）は、ＱｏＳ要求をＳＭＦ３２（他のコアネットワーク装置）に送信する（図５のＳ１０４）。

制御部３０３は、ＡＭＦ３１が本実施形態で説明した各種動作を行うために必要な制御を行う。

また、受信部３０１（第２受信部）は、ＳＭＦ３２からＱｏＳ要求を受信する（図５のＳ１０４）。

また、送信部３０２（第２送信部）は、ＱｏＳ要求を基地局２０に送信する（図５のＳ１０４）。また、受信部３０１が、基地局２０から、ＱｏＳ要求を拒否することを示す情報を受信した場合（図５のＳ１３０）、送信部３０２（第３送信部）は、リレー端末１０Ａに対して、ＱｏＳ要求を拒否することを示すＱｏＳ拒否情報（第１情報）をリレー端末１０Ａに送信する（図５のＳ１３１）。

（ＳＭＦ）
図１４は、ＳＭＦ３２の機能ブロック構成例を示す図である。図１４に示すように、ＳＭＦ３２は、受信部４０１と、送信部４０２と、制御部４０３とを、有する。

なお、受信部４０１と送信部４０２とが実現する機能の全部又は一部は、通信装置１３を用いて実現することができる。また、受信部４０１と送信部４０２とが実現する機能の全部又は一部と、制御部４０３とは、プロセッサ１１が、記憶装置１２に記憶されたプログラムを実行することにより実現することができる。また、当該プログラムは、記憶媒体に格納することができる。当該プログラムを格納した記憶媒体は、コンピュータ読み取り可能な非一時的な記憶媒体であってもよい。非一時的な記憶媒体は特に限定されないが、例えば、ＵＳＢメモリ又はＣＤ－ＲＯＭ等の記憶媒体であってもよい。

受信部４０１は、コアネットワーク３０内の他の装置から信号を受信する。

送信部４０２は、コアネットワーク３０内の他の装置に対して信号を送信する
制御部４０３は、ＳＭＦ３２が本実施形態で説明した各種動作を行うために必要な制御を行う。また、制御部４０３は、ネットワークのトラフィック状態に基づき、ＱｏＳ要求を受け入れることが可能か否かを判断する（図７のＳ３０５）。

また、受信部４０１は、リレー端末１０Ａから、ＡＭＦ３１を介して、リレー端末１０Ａと通信するリモート端末１０Ｂ－Ｙ（第１端末）のＱｏＳ要求と、リモート端末１０Ｂ－Ｘ（第２端末）のＱｏＳを変更する要求とを含むメッセージを受信する（図７のＳ３２１）。

また、制御部４０３は、リモート端末１０Ｂ－Ｘ（第２端末）のＱｏＳ要求を変更することで、リモート端末１０Ｂ－Ｙ（第１端末）のＱｏＳ要求を受け入れ可能になる場合に、リモート端末１０Ｂ－Ｘ（第２端末）のＱｏＳを、所定のＱｏＳに変更する処理を行う（図７のＳ３４０）。所定のＱｏＳは、例えばデフォルトＱｏＳであってもよい。

受信部４０１は、リレー端末１０Ａ又はＡＦ３５（他のコアネットワーク装置）から、ＡＭＦ３１又はＰＣＦ３４を介して、リレー端末１０Ａと通信するリモート端末１０Ｂ－Ｙ（第１端末）のＱｏＳ要求を受信する（図８のＳ４０３、Ｓ４０４、図９のＳ５０３、Ｓ５０４）。

また、制御部４０３は、リレー端末１０Ａと通信する１以上のリモート端末１０Ｂの中から選択した１以上のリモート端末１０Ｂ－Ｘ（第２端末）のＱｏＳを変更することで、リモート端末１０Ｂ－Ｙ（第１端末）のＱｏＳ要求を受け入れ可能になる場合に、前記１以上のリモート端末１０Ｂ－Ｘ（第２端末）のＱｏＳを、所定のＱｏＳに変更する処理を行う（図８のＳ４４０、図９のＳ５２５）。所定のＱｏＳは、例えばデフォルトＱｏＳであってもよい。

また、制御部４０３は、１以上のリモート端末１０Ｂの中から、リモート端末１０Ｂ－Ｙ（第１端末）よりも優先度が低い１以上のリモート端末１０Ｂ－Ｘ（第２端末）を選択するようにしてもよい。制御部４０３が、各リモート端末１０Ｂに対応するＱｏＳフローごとに指定されている優先レベルに基づいて、リモート端末１０Ｂ－Ｙ（第１端末）よりも優先度が低い１以上のリモート端末１０Ｂ－Ｘ（第２端末）を選択してもよい。

また、制御部４０３により、ＱｏＳ要求を受け入れることが可能になったと判断された場合、送信部４０２は、ＡＭＦ３１に、ＱｏＳ要求を許可することを示す情報を送信するようにしてもよい。

＜その他の実施形態＞
上記実施形態における各種の信号、情報、パラメータは、どのようなレイヤでシグナリングされてもよい。すなわち、上記各種の信号、情報、パラメータは、上位レイヤ（例えば、Non Access Stratum（ＮＡＳ）レイヤ、ＲＲＣレイヤ、ＭＡＣレイヤ等）、下位レイヤ（例えば、物理レイヤ）等のどのレイヤの信号、情報、パラメータに置き換えられてもよい。また、所定情報の通知は明示的に行うものに限られず、黙示的に（例えば、情報を通知しないことや他の情報を用いることによって）行われてもよい。

また、上記実施形態における各種のメッセージ、信号、情報、パラメータの名称は、例示にすぎず、他の名称に置き換えられてもよい。例えば、スロットは、所定数のシンボルを有する時間単位であれば、どのような名称であってもよい。また、ＲＢは、所定数のサブキャリアを有する周波数単位であれば、どのような名称であってもよい。

また、上記実施形態における端末１０の用途は、例示するものに限られず、同様の機能を有する限り、どのような用途（例えば、ｅＭＢＢ、ＵＲＬＬＣ、Device-to-Device（Ｄ２Ｄ）、Vehicle-to-Everything（Ｖ２Ｘ）等）で利用されてもよい。また、各種情報の形式は、上記実施形態に限られず、ビット表現（０又は１）、真偽値（Boolean：true又はfalse）、整数値、文字等適宜変更されてもよい。また、上記実施形態における単数、複数は相互に変更されてもよい。

以上説明した実施形態は、本開示の理解を容易にするためのものであり、本開示を限定して解釈するためのものではない。実施形態で説明したフローチャート、シーケンス、実施形態が備える各要素並びにその配置、インデックス、条件等は、例示したものに限定されるわけではなく適宜変更することができる。また、上記実施形態で説明した少なくとも一部の構成を部分的に置換し又は組み合わせることが可能である。

１…通信システム、１０…端末、１０Ａ…リレー端末、１０Ｂ…リモート端末、１１…プロセッサ、１２…記憶装置、１３…通信装置、１４…入出力装置、２０…基地局、３０…コアネットワーク、１０１…受信部、１０２…送信部、１０３…制御部、２０１…受信部、２０２…送信部、２０３…制御部、３０１…受信部、３０２…送信部、３０３…制御部、４０１…受信部、４０２…送信部、４０３…制御部

Claims (8)

1. 第１端末からＱｏＳ要求を受信した場合に、前記ＱｏＳ要求をネットワーク装置に送信する第１送信部と、
   前記ネットワーク装置から、前記ＱｏＳ要求を拒否することを示す情報を受信する受信部と、
   前記情報を受信した場合に、当該中継端末と通信する１以上の端末の中から第２端末を選択する制御部と、
   前記第２端末のＱｏＳ要求を変更することを要求するメッセージを前記ネットワーク装置に送信する第２送信部と、
   を有する中継端末。
2. 前記制御部は、前記１以上の端末の中から、前記第１端末よりも優先度が低い前記第２端末を選択する、
   請求項１に記載の中継端末。
3. 中継端末から、当該中継端末と通信する第１端末のＱｏＳ要求と、第２端末のＱｏＳを変更する要求とを含むメッセージを受信する受信部と、
   前記第２端末のＱｏＳを変更することで、前記第１端末のＱｏＳ要求を受け入れ可能になる場合に、前記第２端末のＱｏＳを変更する処理を行う制御部と、
   を有するコアネットワーク装置。
4. 中継端末又は他のコアネットワーク装置から、前記中継端末と通信する第１端末のＱｏＳ要求を受信する受信部と、
   前記中継端末と通信する１以上の端末の中から選択した１以上の第２端末のＱｏＳを変更することで、前記第１端末のＱｏＳ要求を受け入れ可能になる場合に、前記１以上の第２端末のＱｏＳを変更する処理を行う制御部と、
   を有するコアネットワーク装置。
5. 前記制御部は、前記１以上の端末の中から、前記第１端末よりも優先度が低い前記１以上の第２端末を選択する、
   請求項３に記載のコアネットワーク装置。
6. 第１端末からＱｏＳ要求を受信した場合に、前記ＱｏＳ要求をネットワーク装置に送信するステップと、
   前記ネットワーク装置から、前記ＱｏＳ要求を拒否することを示す情報を受信するステップと、
   前記情報を受信した場合に、当該中継端末と通信する１以上の端末の中から第２端末を選択するステップと、
   前記第２端末のＱｏＳ要求を変更することを要求するメッセージを前記ネットワーク装置に送信するステップと、
   を含む中継端末が実行する中継方法。
7. 中継端末から、当該中継端末と通信する第１端末のＱｏＳ要求と、第２端末のＱｏＳを変更する要求とを含むメッセージを受信するステップと、
   前記第２端末のＱｏＳを変更することで、前記第１端末のＱｏＳ要求を受け入れ可能になる場合に、前記第２端末のＱｏＳを変更する処理を行うステップと、
   を含む、コアネットワーク装置が実行する通信方法。
8. 中継端末又は他のコアネットワーク装置から、前記中継端末と通信する第１端末のＱｏＳ要求を受信するステップと、
   前記中継端末と通信する１以上の端末の中から選択した１以上の第２端末のＱｏＳを変更することで、前記第１端末のＱｏＳ要求を受け入れ可能になる場合に、前記１以上の第２端末のＱｏＳを変更する処理を行うステップと、
   を含む、コアネットワーク装置が実行する通信方法。

Images