特許 7613818 ネットワークノード及び通信方法

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

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

(11)【特許番号】

(24)【登録日】2025-01-06

(45)【発行日】2025-01-15

(54)【発明の名称】ネットワークノード及び通信方法

(51)【国際特許分類】

   H04W 12/062 20210101AFI20250107BHJP

   H04W 12/75 20210101ALI20250107BHJP

【ＦＩ】

H04W12/062

H04W12/75

【請求項の数】 6

(21)【出願番号】P 2023506691

(86)(22)【出願日】2021-03-19

(86)【国際出願番号】 JP2021011495

(87)【国際公開番号】W WO2022195878

(87)【国際公開日】2022-09-22

【審査請求日】2024-01-29

(73)【特許権者】

【識別番号】392026693

【氏名又は名称】株式会社ＮＴＴドコモ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100124844

【弁理士】

【氏名又は名称】石原 隆治

(72)【発明者】

【氏名】鈴木 悠司

(72)【発明者】

【氏名】巳之口 淳

【審査官】伊東 和重

(56)【参考文献】

【文献】NEC，Correction/enhancement in CAPIF TS[online]，3GPP TSG SA WG3 #93，3GPP，2018年11月16日，S3-183341，[検索日 2024.11.19],インターネット：<URL:https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_93_Spokane/Docs/S3-183341.zip>

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

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

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

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

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

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

【請求項1】

端末を認証し暫定識別子を当該端末に送信する送信部と、
前記暫定識別子を含む要求又は前記暫定識別子に基づく認証コードを受信する受信部と、
前記暫定識別子を含む要求又は前記認証コードに基づいて、アクセストークンを発行する制御部とを有し、
前記送信部は、前記アクセストークンを前記端末又は外部アプリケーションに送信し、
前記受信部は、前記アクセストークンに基づくＡＰＩ（Application Programming Interface）呼び出し要求を前記端末又は前記外部アプリケーションから受信し、
前記制御部は、前記アクセストークンを検証して前記ＡＰＩ呼び出し要求が認可されたものであると判定した場合、前記ＡＰＩ呼び出し要求に基づいて処理を実行するネットワークノード。

【請求項2】

前記受信部は、前記端末又は前記外部アプリケーションからＡＰＩ呼び出しに使用するセキュリティメソッドに係る要求を受信し、
前記制御部は、セキュリティメソッドを選択し、
前記送信部は、前記選択したセキュリティメソッドを示す応答を前記端末又は外部アプリケーションに送信する請求項１記載のネットワークノード。

【請求項3】

前記送信部が前記アクセストークンを前記外部アプリケーションに送信する場合、前記制御部は、前記外部アプリケーションを予め認証し登録している請求項１記載のネットワークノード。

【請求項4】

前記送信部が前記アクセストークンを前記外部アプリケーションに送信する場合、前記制御部は、ユーザにＡＰＩ利用可否の確認を実施した後、前記アクセストークンを発行する請求項３記載のネットワークノード。

【請求項5】

前記制御部は、前記ＡＰＩ呼び出し要求が認可されたものであるかを判定するとき、少なくともユーザごとのスコープが設定される、許可されるＡＰＩ及び許可されるメソッドを参照する請求項１記載のネットワークノード。

【請求項6】

端末を認証し暫定識別子を当該端末に送信する送信手順と、
前記暫定識別子を含む要求又は前記暫定識別子に基づく認証コードを受信する受信手順と、
前記暫定識別子を含む要求又は前記認証コードに基づいて、アクセストークンを発行する制御手順と、
前記アクセストークンを前記端末又は外部アプリケーションに送信する手順と、
前記アクセストークンに基づくＡＰＩ（Application Programming Interface）呼び出し要求を前記端末又は前記外部アプリケーションから受信する手順と、
前記アクセストークンを検証して前記ＡＰＩ呼び出し要求が認可されたものであると判定した場合、前記ＡＰＩ呼び出し要求に基づいて処理を実行する手順とをネットワークノードが実行する通信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信システムにおけるネットワークノード及び通信方法に関する。

【背景技術】

【0002】

３ＧＰＰ（3rd Generation Partnership Project）では、システム容量の更なる大容量化、データ伝送速度の更なる高速化、無線区間における更なる低遅延化等を実現するために、５ＧあるいはＮＲ（New Radio）と呼ばれる無線通信方式（以下、当該無線通信方式を「５Ｇ」あるいは「ＮＲ」という。）の検討が進んでいる。５Ｇでは、１０Ｇｂｐｓ以上のスループットを実現しつつ無線区間の遅延を１ｍｓ以下にするという要求条件を満たすために、様々な無線技術の検討が行われている。

【0003】

ＮＲでは、ＬＴＥ（Long Term Evolution）のネットワークアーキテクチャにおけるコアネットワークであるＥＰＣ（Evolved Packet Core）に対応する５ＧＣ（5G Core Network）及びＬＴＥのネットワークアーキテクチャにおけるＲＡＮ（Radio Access Network）であるＥ－ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）に対応するＮＧ－ＲＡＮ（Next Generation - Radio Access Network）を含むネットワークアーキテクチャが検討されている（例えば非特許文献１）。

【0004】

また、例えば、５ＧシステムにおけるＮＥＦ（Network Exposure Function）とＡＦ（Application Function）間のＮｏｒｔｈｂｏｕｎｄインタフェースをＣＡＰＩＦ（Common API Framework）により構成するアーキテクチャが検討されている（例えば非特許文献２及び非特許文献３）。

【先行技術文献】

【非特許文献】

【0005】

【文献】３ＧＰＰ ＴＳ ２３．５０１ Ｖ１６．７．０（２０２０－１２）

【文献】３ＧＰＰ ＴＳ ２９．５２２ Ｖ１６．６．０（２０２０－１２）

【文献】３ＧＰＰ ＴＳ ２３．２２２ Ｖ１６．９．０（２０２０－０９）

【発明の概要】

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

【0006】

３ＧＰＰコアネットワークでは外部のアプリケーション向けにＡＰＩ（Application Programming Interface）を解放しており、サードパーティのアプリケーションからＡＰＩを呼び出すことができる。ここで、サードパーティのアプリケーションからＡＰＩを呼び出すとき、コアネットワークは、サードパーティのアプリケーションを利用するユーザを識別することが困難であるため、適切なサービスを提供することができなかった。

【0007】

本発明は上記の点に鑑みてなされたものであり、ネットワークにおいて加入者情報を識別可能とするインタフェースを提供することを目的とする。

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

【0008】

開示の技術によれば、端末を認証し暫定識別子を当該端末に送信する送信部と、前記暫定識別子を含む要求又は前記暫定識別子に基づく認証コードを受信する受信部と、前記暫定識別子を含む要求又は前記認証コードに基づいて、アクセストークンを発行する制御部とを有し、前記送信部は、前記アクセストークンを前記端末又は外部アプリケーションに送信し、前記受信部は、前記アクセストークンに基づくＡＰＩ（Application Programming Interface）呼び出し要求を前記端末又は前記外部アプリケーションから受信し、前記制御部は、前記アクセストークンを検証して前記ＡＰＩ呼び出し要求が認可されたものであると判定した場合、前記ＡＰＩ呼び出し要求に基づいて処理を実行するネットワークノードが提供される。

【発明の効果】

【0009】

開示の技術によれば、ネットワークにおいて加入者情報を識別可能とするインタフェースを提供することができる。

【図面の簡単な説明】

【0010】

【図1】通信システムの例を説明するための図である。

【図2】ローミング環境下の通信システムの例を説明するための図である。

【図3】ＡＰＩ呼び出しの例（１）を示す図である。

【図4】ＡＰＩ呼び出しの例（２－１）を示す図である。

【図5】ＡＰＩ呼び出しの例（２－２）を示す図である。

【図6】ＡＰＩ呼び出しの例（３－１）を示す図である。

【図7】ＡＰＩ呼び出しの例（３－２）を示す図である。

【図8】ＡＰＩ呼び出しの例（４）を示す図である。

【図9】本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例（１）を説明するための図である。

【図10】本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例（２）を説明するための図である。

【図11】本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例（３）を説明するための図である。

【図12】本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（１）を説明するための図である。

【図13】本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（２）を説明するための図である。

【図14】本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（３）を説明するための図である。

【図15】本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（４）を説明するための図である。

【図16】本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（５）を説明するための図である。

【図17】本発明の実施の形態におけるＡＰＩのスコープを説明するための図である。

【図18】本発明の実施の形態におけるＵＥ及びＡＦを含むシステムの例を示す図である。

【図19】本発明の実施の形態におけるＵＥを含むシステムの例を示す図である。

【図20】本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例を説明するためのシーケンス図である。

【図21】本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例を説明するためのシーケンス（１）図である。

【図22】本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例を説明するためのシーケンス（２）図である。

【図23】本発明の実施の形態における基地局１０の機能構成の一例を示す図である。

【図24】本発明の実施の形態における端末２０の機能構成の一例を示す図である。

【図25】本発明の実施の形態における基地局１０及び端末２０のハードウェア構成の一例を示す図である。

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

【0011】

以下、図面を参照して本発明の実施の形態を説明する。なお、以下で説明する実施の形態は一例であり、本発明が適用される実施の形態は、以下の実施の形態に限られない。

【0012】

本発明の実施の形態の無線通信システムの動作にあたっては、適宜、既存技術が使用される。ただし、当該既存技術は、例えば既存のＬＴＥであるが、既存のＬＴＥに限られない。また、本明細書で使用する用語「ＬＴＥ」は、特に断らない限り、ＬＴＥ－Ａｄｖａｎｃｅｄ、及び、ＬＴＥ－Ａｄｖａｎｃｅｄ以降の方式（例：ＮＲ）、又は無線ＬＡＮ（Local Area Network）を含む広い意味を有するものとする。

【0013】

また、本発明の実施の形態において、無線パラメータ等が「設定される（Configure）」とは、所定の値が予め設定（Pre-configure）されることであってもよいし、ネットワークノード３０又は端末２０から通知される無線パラメータが設定されることであってもよい。

【0014】

図１は、通信システムの例を説明するための図である。図１に示されるように、通信システムは、端末２０であるＵＥ、複数のネットワークノード３０から構成される。以下、機能ごとに１つのネットワークノード３０が対応するものとするが、複数の機能を１つのネットワークノード３０が実現してもよいし、複数のネットワークノード３０が１つの機能を実現してもよい。また、以下に記載する「接続」は、論理的な接続であってもよいし、物理的な接続であってもよい。

【0015】

ＲＡＮ（Radio Access Network）は、無線アクセス機能を有するネットワークノード３０であり、基地局１０を含んでもよく、ＵＥ、ＡＭＦ（Access and Mobility Management Function）及びＵＰＦ（User plane function）と接続される。ＡＭＦは、ＲＡＮインタフェースの終端、ＮＡＳ（Non-Access Stratum）の終端、登録管理、接続管理、到達性管理、モビリティ管理等の機能を有するネットワークノード３０である。ＵＰＦは、ＤＮ（Data Network）と相互接続する外部に対するＰＤＵ（Protocol Data Unit）セッションポイント、パケットのルーティング及びフォワーディング、ユーザプレーンのＱｏＳ（Quality of Service）ハンドリング等の機能を有するネットワークノード３０である。ＵＰＦ及びＤＮは、ネットワークスライスを構成する。本発明の実施の形態における無線通信ネットワークでは、複数のネットワークスライスが構築されている。

【0016】

ＡＭＦは、ＵＥ、ＲＡＮ、ＳＭＦ（Session Management function）、ＮＳＳＦ（Network Slice Selection Function）、ＮＥＦ（Network Exposure Function）、ＮＲＦ（Network Repository Function）、ＵＤＭ（Unified Data Management）、ＡＵＳＦ（Authentication Server Function）、ＰＣＦ（Policy Control Function）、ＡＦ（Application Function）と接続される。ＡＭＦ、ＳＭＦ、ＮＳＳＦ、ＮＥＦ、ＮＲＦ、ＵＤＭ、ＡＵＳＦ、ＰＣＦ、ＡＦは、各々のサービスに基づくインタフェース、Ｎａｍｆ、Ｎｓｍｆ、Ｎｎｓｓｆ、Ｎｎｅｆ、Ｎｎｒｆ、Ｎｕｄｍ、Ｎａｕｓｆ、Ｎｐｃｆ、Ｎａｆを介して相互に接続されるネットワークノード３０である。

【0017】

ＳＭＦは、セッション管理、ＵＥのＩＰ（Internet Protocol）アドレス割り当て及び管理、ＤＨＣＰ（Dynamic Host Configuration Protocol）機能、ＡＲＰ（Address Resolution Protocol）プロキシ、ローミング機能等の機能を有するネットワークノード３０である。ＮＥＦは、他のＮＦ（Network Function）に能力及びイベントを通知する機能を有するネットワークノード３０である。ＮＳＳＦは、ＵＥが接続するネットワークスライスの選択、許可されるＮＳＳＡＩ（Network Slice Selection Assistance Information）の決定、設定されるＮＳＳＡＩの決定、ＵＥが接続するＡＭＦセットの決定等の機能を有するネットワークノード３０である。ＰＣＦは、ネットワークのポリシ制御を行う機能を有するネットワークノード３０である。ＡＦは、アプリケーションサーバを制御する機能を有するネットワークノード３０である。ＮＲＦは、サービスを提供するＮＦインスタンスを発見する機能を有するネットワークノード３０である。ＵＤＭは、加入者データ及び認証データを管理するネットワークノード３０である。ＵＤＭは、当該データを保持するＵＤＲ（User Data Repository）と接続される。

【0018】

図２は、ローミング環境下の通信システムの例を説明するための図である。図２に示されるように、ネットワークは、端末２０であるＵＥ、複数のネットワークノード３０から構成される。以下、機能ごとに１つのネットワークノード３０が対応するものとするが、複数の機能を１つのネットワークノード３０が実現してもよいし、複数のネットワークノード３０が１つの機能を実現してもよい。また、以下に記載する「接続」は、論理的な接続であってもよいし、物理的な接続であってもよい。

【0019】

ＲＡＮは、無線アクセス機能を有するネットワークノード３０であり、ＵＥ、ＡＭＦ及びＵＰＦと接続される。ＡＭＦは、ＲＡＮインタフェースの終端、ＮＡＳの終端、登録管理、接続管理、到達性管理、モビリティ管理等の機能を有するネットワークノード３０である。ＵＰＦは、ＤＮと相互接続する外部に対するＰＤＵセッションポイント、パケットのルーティング及びフォワーディング、ユーザプレーンのＱｏＳハンドリング等の機能を有するネットワークノード３０である。ＵＰＦ及びＤＮは、ネットワークスライスを構成する。、本発明の実施の形態における無線通信ネットワークでは、複数のネットワークスライスが構築されている。

【0020】

ＡＭＦは、ＵＥ、ＲＡＮ、ＳＭＦ、ＮＳＳＦ、ＮＥＦ、ＮＲＦ、ＵＤＭ、ＡＵＳＦ、ＰＣＦ、ＡＦ、ＳＥＰＰ（Security Edge Protection Proxy）と接続される。ＡＭＦ、ＳＭＦ、ＮＳＳＦ、ＮＥＦ、ＮＲＦ、ＵＤＭ、ＡＵＳＦ、ＰＣＦ、ＡＦは、各々のサービスに基づくインタフェース、Ｎａｍｆ、Ｎｓｍｆ、Ｎｎｓｓｆ、Ｎｎｅｆ、Ｎｎｒｆ、Ｎｕｄｍ、Ｎａｕｓｆ、Ｎｐｃｆ、Ｎａｆを介して相互に接続されるネットワークノード３０である。

【0021】

ＳＭＦは、セッション管理、ＵＥのＩＰアドレス割り当て及び管理、ＤＨＣＰ機能、ＡＲＰプロキシ、ローミング機能等の機能を有するネットワークノード３０である。ＮＥＦは、他のＮＦに能力及びイベントを通知する機能を有するネットワークノード３０である。ＮＳＳＦは、ＵＥが接続するネットワークスライスの選択、許可されるＮＳＳＡＩの決定、設定されるＮＳＳＡＩの決定、ＵＥが接続するＡＭＦセットの決定等の機能を有するネットワークノード３０である。ＰＣＦは、ネットワークのポリシ制御を行う機能を有するネットワークノード３０である。ＡＦは、アプリケーションサーバを制御する機能を有するネットワークノード３０である。ＮＲＦは、サービスを提供するＮＦインスタンスを発見する機能を有するネットワークノード３０である。ＳＥＰＰは、非透過的なプロキシであり、ＰＬＭＮ（Public Land Mobile Network）間のコントロールプレーンのメッセージをフィルタリングする。図２に示されるｖＳＥＰＰは、ｖｉｓｉｔｅｄネットワークにおけるＳＥＰＰであり、ｈＳＥＰＰは、ｈｏｍｅネットワークにおけるＳＥＰＰである。

【0022】

図２に示されるように、ＵＥは、ＶＰＬＭＮ（Visited PLMN）においてＲＡＮ及びＡＭＦと接続されているローミング環境にある。ＶＰＬＭＮ及びＨＰＬＭＮ（Home PLMN）は、ｖＳＥＰＰ及びｈＳＥＰＰを経由して接続されている。ＵＥは、例えば、ＶＰＬＭＮのＡＭＦを介してＨＰＬＭＮのＵＤＭと通信が可能である。

【0023】

上述のＮＥＦは、ＡＦから呼び出し可能であるＡＰＩ（Application Programming Interface）を、ＣＡＰＩＦ（Common API Framework）アーキテクチャを適用して実装することが検討されている。ＣＡＰＩＦアーキテクチャは、サービスＡＰＩ運用をサポートするメカニズムを提供し、例えば、ＡＰＩ呼び出し元（invoker）にＡＰＩ提供者（provider）から提供されるサービスＡＰＩを発見させ、当該サービスＡＰＩを使用する通信を可能とする。また、ＣＡＰＩＦアーキテクチャは、例えば、ＰＬＭＮトラストドメインの外部からサービスＡＰＩにアクセスするＡＰＩ呼び出し元から、ＰＬＭＮトラストドメインの接続形態（topology）を隠蔽するメカニズムを有する。

【0024】

図３は、ＡＰＩ呼び出しの例（１）を示す図である。３ＧＰＰコアネットワークでは外部のアプリケーション向けにＡＰＩを解放しており、サードパーティのアプリケーションからＡＰＩを呼び出すことができる。ＡＰＩを呼び出すとき、コアネットワーク内にあるＣＡＰＩＦコア機能（CAPIF Core Function、ＣＣＦとも記載する。）によって、呼び出し元のアプリケーション（API invoker）を認証及び／又は認可し、いずれのアプリケーションがＡＰＩを呼び出すことができるかを管理する。

【0025】

図３に示されるように、ＡＰＩ呼び出し元のアプリケーション３０Ａが、ＣＡＰＩＦ－ＡＰＩを利用してＣＡＰＩＦコア機能３０Ｂに事前登録される。ＣＡＰＩＦコア機能３０Ｂでは、サードパーティのアプリケーション３０Ａを認証及び／又は認可する。また、図３に示されるように、ＡＰＩ呼び出し元のアプリケーション３０Ａが、コアネットワークのＡＰＩを呼び出すと、認証及び／又は認可された外部アプリケーション向けに、ＡＰＩ提供機能（API Exposing Function、ＡＥＦとも記載する。）３０ＣによってサービスＡＰＩを解放する。

【0026】

図４は、ＡＰＩ呼び出しの例（２－１）を示す図である。図５は、ＡＰＩ呼び出しの例（２－２）を示す図である。具体的なユースケースとして、ＱｏＳ変更オプションを想定する。ユーザは、契約により所望のタイミングでＱｏＳ変更リクエストを送ることにより、快適な通信環境が得られるものとする。図４に示されるように、ユーザのアプリケーションからＱｏＳ変更リクエストが５ＧＳ（5G System）に含まれるＮＥＦにコアネットワークのＡＰＩ呼び出しとして送信され、ＱｏＳ変更が実行される。

【0027】

しかしながら、従来技術では、いずれのユーザがいずれのユーザのＱｏＳを変更できるのか判断することができず、適切でないユーザのＱｏＳを変更することが可能となってしまう。例えば、図５に示されるように、ＣＡＰＩＦコア機能３０Ｂでは、どのユーザのＱｏＳ変更が許可されているかがわからず、ＡＰＩ提供機能３０Ｃでは、ＱｏＳ変更可の契約者が、ＱｏＳ変更不可ユーザのＱｏＳを変更することを受け入れてしまう。また、ＱｏＳ以外のサービスであっても、いずれのユーザのリソースにアクセスできるかを判断することができない。なお、図５では、ＡＰＩ呼び出し元はエンドユーザのスマホ等である。

【0028】

以降、本実施例ではＱｏＳ変更を具体例として案を説明するが、ユーザが利用するＡＰＩはＱｏＳ制御に限られず、オペレータがユーザ向けに提供しているすべてのＡＰＩとしてよい。例えば、特定のユーザのＵ－ｐｌａｎｅ通信路を変更するＡＰＩがあるが、エンドユーザが自ら当該ＡＰＩを利用する際にも、本実施例で説明する方式を適用してよい。

【0029】

図６は、ＡＰＩ呼び出しの例（３－１）を示す図である。図７は、ＡＰＩ呼び出しの例（３－２）を示す図である。具体的なユースケースとして、サードパーティ社製のスマートフォンゲームをプレイする場合を想定する。ユーザは課金すなわち契約により所望のタイミングでＱｏＳ変更リクエストを送ることにより、快適な通信環境が得られるものとする。図６に示されるように、ユーザのアプリケーションからＱｏＳ変更リクエストが、ゲームサーバを介して５ＧＳに含まれるＮＥＦにコアネットワークのＡＰＩ呼び出しとして送信され、ＱｏＳ変更が実行される。

【0030】

しかしながら、従来技術では、いずれのユーザがいずれのユーザのＱｏＳを変更できるのか判断することができず、ＱｏＳ変更オプションのない（又は一般に適切な契約のない）ユーザからのＱｏＳ変更リクエストを拒否することができない。例えば、図７に示されるように、ＣＡＰＩＦコア機能３０Ｂでは、どのユーザからの要求であるかがわからず、ＡＰＩ提供機能３０Ｃでは、ゲームサーバ自体が認証及び認可されていれば、ＡＰＩを呼び出すことが可能となってしまう。図７に示されるように、ＱｏＳ変更オプションありのゲームプレイヤーに対応するＵＥ２０ＡからのＱｏＳ変更リクエストを許容し、ＱｏＳ変更オプションなしのゲームプレイヤーに対応するＵＥ２０ＢからのＱｏＳ変更リクエストを拒否する動作が、ネットワーク側が意図する動作である。なお、図７では、ＡＰＩ呼び出し元はサードパーティのゲームサーバ等である。

【0031】

そこで、ＣＡＰＩＦコア機能３０Ｂが、個々の端末を認証してＡＰＩ利用を認可してもよい。また、個々の端末がいずれのＡＰＩを呼び出してよいかを規定するスコープを管理してもよい。また、当該スコープ内で、指定したＵＥのＱｏＳのみを変更できるようにしてもよい。

【0032】

図８は、ＡＰＩ呼び出しの例（４）を示す図である。図８は従来技術においてＡＦがＡＰＩを呼び出す例を示す。図８に示されるように、ＡＰＩ呼び出し元３０Ａは、ＣＡＰＩＦコア機能３０Ｂにｏｎｂｏａｒｄｉｎｇする。「ｏｎｂｏａｒｄｉｎｇ」とは、ここではＣＡＰＩＦコア機能３０ＢがＡＰＩ呼び出し元３０Ａを認証しワンタイム登録して、ＡＰＩ呼び出し元３０ＡにＣＡＰＩＦ及びサービスＡＰＩにアクセスすることを許可する動作をいう。続いて、ＡＰＩ呼び出し元３０ＡとＣＡＰＩＦコア機能３０Ｂはセキュリティメソッドを合意する。続いて、ＡＰＩ呼び出し元３０Ａは、アクセストークンをＣＡＰＩＦコア機能３０Ｂに要求し、ＣＡＰＩＦコア機能３０Ｂはアクセストークンを発行する。

【0033】

上記のセキュリティメソッドの合意は、ＯＡｕｔｈ ２．０ Ｃｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌ方式を用いており、リソースオーナーの許諾がなくてもクライアント（図８ではＡＰＩ呼び出し元）の認証のみでＡＰＩ呼び出しが認可される。

【0034】

図９は、本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例（１）を説明するための図である。ステップ１において、ＢＳＦ（Bootstrapping Server Function）３０Ｆ及びＵＤＭ３０Ｇは、Ｂｏｏｔｓｔｒａｐｐｉｎｇ手順の実行によりＵＥ２０を認証し、ＵＥ２０とＣＡＰＩＦコア機能３０Ｂが直接通信できるようにする。ＵＥ２０は、ＣＣＦ３０Ｂから暫定識別子を受け取る。暫定識別子は、例えば、ＮＡ－ＧＵＴＩ（Northbound Access Globally Unique Temporary Identifier）であってもよい。続くステップ２において、ＵＥ２０とＣＣＦ３０Ｂとの間でセキュリティメソッドが合意される。

【0035】

図１０は、本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例（２）を説明するための図である。続くステップ３において、ＵＥ２０は、暫定識別子及び呼び出したいＡＰＩを明示してＣＣＦ３０Ｂにアクセストークンの発行を要求する。なお、ステップ３の時点で、変更対象のユーザ情報等をＣＣＦ３０Ｂに送信し、当該ユーザ情報に基づいてアクセストークンがＣＣＦ３０Ｂから発行されてもよい。

【0036】

続くステップ４において、ＣＣＦ３０Ｂは暫定識別子から加入者を特定し、ＵＤＭ３０Ｇに加入者情報を確認する。続くステップ５において、ＵＤＭ３０Ｇは、加入者情報を返却する。図１０に示される許可ＡＰＩ、メソッド及び対象ユーザが関連付けられたテーブルを、ＵＤＭ３０Ｇは、加入者情報としてＣＣＦ３０Ｂに返却してもよい。

【0037】

続くステップ６において、ＣＣＦ３０Ｂは、当該テーブルの許可ＡＰＩ及びメソッドに基づいて、ＵＥ２０が目的のＡＰＩを呼び出すことが許容されるとＣＣＦ３０Ｂが判定できた場合、ＣＣＦ３０ＢはＵＥにアクセストークンを発行する。図１０に示される例では、例えば、ＡｓＳｅｓｓｉｏｎＷｉｔｈＱｏＳがＵＥ２０から呼び出されている場合、許可されているＡＰＩであるため、アクセストークンがＣＣＦ３０Ｂから発行される。

【0038】

続くステップ７において、ＵＥ２０は、受領したアクセストークンを用いて、ＡＥＦ３０Ｃ宛にサービスＡＰＩを呼び出す。例えば、図１０に示されるように、アクセストークンが＠＠＠＠＠＠、ＡＰＩがＡｓＳｅｓｓｉｏｎＷｉｔｈＱｏＳ及び変更対象ユーザのＩＰアドレスがｘｘｘ．ｘｘｘ．ｘｘｘ．ｘｘｘであることを示す情報をＵＥ２０はＡＥＦ３０Ｃに送ることで、サービスＡＰＩを呼び出してもよい。

【0039】

図１１は、本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例（３）を説明するための図である。続くステップ８において、ＡＥＦ３０Ｃは、ＣＣＦ３０Ｂに対し、ＡＰＩ要求を認可してよいか確認する。続くステップ９において、ＣＣＦ３０Ｂは、ＵＤＭ３０ＧにＡＰＩ呼び出し元の加入者の加入者情報を要求する。続くステップ１０において、ＵＤＭ３０Ｇは、加入者情報を返却する。図１１に示される許可ＡＰＩ、メソッド及び対象ユーザが関連付けられたテーブルを、ＵＤＭ３０Ｇは、加入者情報としてＣＣＦ３０Ｂに返却してもよい。続くステップ１１において、ＣＣＦ３０Ｂは、加入者情報及びＡＰＩ要求に基づいて、認可してよいＡＰＩ要求か否かを判定し、結果をＡＥＦ３０Ｃに返却する。

【0040】

例えば、ＣＣＦ３０Ｂは、「ＡＰＩ：ＡｓＳｅｓｓｉｏｎＷｉｔｈＱｏＳ、変更対象ユーザのＩＰアドレスがｘｘｘ．ｘｘｘ．ｘｘｘ．ｘｘｘ」という要求と、図１１に示される加入者情報の「対象ユーザ」とを比較し、目的のユーザへのＱｏＳ変更が加入者情報にて許可されていれば、当該ＡＰＩの利用を認可してよいと判定してもよい。続くステップ１２において、ＣＣＦ３０Ｂにおいて当該ＡＰＩ利用が認可された場合、ＡＥＦ３０Ｃは要求に従って処理を実行し、ＡＰＩ利用可否の結果をＵＥ２０に返却する。

【0041】

図１２は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（１）を説明するための図である。ステップ１において、ＡＰＩ呼び出し元３０Ａ（例えば、ゲームサーバ）は、ＣＡＰＩＦコア機能３０ＢにＯｎｂｏａｒｄｉｎｇする。当該Ｏｎｂｏａｒｄｉｎｇは、従来技術と同様であってもよい。ステップ１′において、ステップ１と並行して、ＢＳＦ３０Ｆ及びＵＤＭ３０Ｇは、Ｂｏｏｔｓｔｒａｐｐｉｎｇ手順の実行によりＵＥ２０を認証し、ＵＥ２０とＣＡＰＩＦコア機能３０Ｂが直接通信できるようにする。ＵＥ２０は、ＣＣＦ３０Ｂから暫定識別子を受け取る。暫定識別子は、例えば、ＮＡ－ＧＵＴＩであってもよい。

【0042】

図１３は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（２）を説明するための図である。続くステップ２において、ＡＰＩ呼び出し元３０Ａは、ＵＥトリガのＡＰＩ呼び出しが必要であることを、ＵＥ２０からの要求等により検知する。例えば、当該ＵＥトリガは、ＵＥ２０からゲームサーバに対してＱｏＳの変更要求を示す情報を送信することであってもよいし、ゲームサーバ側で当該ユーザに対してＱｏＳを変更する必要があると判定されたことであってもよい。

【0043】

続くステップ３において、ＡＰＩ呼び出し元３０ＡとＣＣＦ３０Ｂとの間で、個々の契約者の契約内容に関わるＡＰＩの呼び出しが必要な場合、ＡＰＩ呼び出し元３０ＡとＣＣＦ３０Ｂとの間で、セキュリティメソッドとしてＯＡｕｔｈ ２．０ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｆｌｏｗを用いた認可を行うことが合意される。

【0044】

図１４は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（３）を説明するための図である。続くステップ４において、ＡＰＩ呼び出し元３０Ａは、ＡＰＩを呼び出してよいかユーザに確認する。続くステップ５において、ＡＰＩを呼び出す許可がユーザから得られた場合、ＵＥ２０の暫定識別子及び呼び出したいＡＰＩを明示してＣＣＦ３０Ｂに認可リクエストを送信する。続くステップ６において、ＣＣＦ３０Ｂは、暫定識別子から対象ＵＥ（契約者）を特定し、ＵＤＭ３０Ｇに対して当該契約者の加入者情報を確認する。

【0045】

続くステップ７において、ＵＤＭ３０Ｇは、加入者情報を返却する。図１２に示される許可ＡＰＩ、メソッド及び対象ユーザが関連付けられたテーブルを、ＵＤＭ３０Ｇは、加入者情報としてＣＣＦ３０Ｂに返却してもよい。続くステップ８において、ＣＣＦ３０Ｂは、加入者情報及に基づいて、当該契約書が目的のＡＰＩを呼び出してよいか否かを判定し、結果をＵＥ２０に通知する。ここで、ＵＥ２０は、必要に応じてパスワード入力等でＡＰＩ利用を許諾してもよい。続くステップ９において、ＣＣＦ３０Ｂは、ＡＰＩ呼び出し元３０Ａに対し、ＡＰＩの利用が認可されたことを示すＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅを発行する。

【0046】

図１５は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（４）を説明するための図である。続くステップ１０において、ＡＰＩ呼び出し元３０Ａは、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅを用いて、ＡＰＩ呼び出しのアクセストークンを要求し、アクセストークンをＣＣＦ３０Ｂから受領する。続くステップ１１において、ＡＰＩ呼び出し元３０Ａは、アクセストークンを用いてサービスＡＰＩにアクセスする。

【0047】

図１６は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例（５）を説明するための図である。続くステップ１２において、ＡＥＦ３０Ｃは、ＣＣＦ３０Ｂに対し、ＡＰＩ要求を認可してよいか確認する。続くステップ１３において、ＣＣＦ３０Ｂは、ＵＤＭ３０ＧにＡＰＩ呼び出し元の加入者の加入者情報を要求する。続くステップ１４において、ＵＤＭ３０Ｇは、加入者情報を返却する。図１６に示される許可ＡＰＩ、メソッド及び対象ユーザが関連付けられたテーブルを、ＵＤＭ３０Ｇは、加入者情報としてＣＣＦ３０Ｂに返却してもよい。

【0048】

続くステップ１５において、ＣＣＦ３０Ｂは、加入者情報及びＡＰＩ要求に基づいて、認可してよいＡＰＩ要求か否かを判定し、結果をＡＥＦ３０Ｃに返却する。続くステップ１６において、ＣＣＦ３０Ｂにおいて当該ＡＰＩ利用が認可された場合、ＡＥＦ３０Ｃは要求に従って処理を実行し、ＡＰＩ利用可否の結果をＡＰＩ呼び出し元３０Ａに返却する。

【0049】

図１７は、本発明の実施の形態におけるＡＰＩのスコープを説明するための図である。図１７に示されるように、ＣＣＦ３０Ｂからの加入者識別子に基づく契約者情報の問い合わせに対して、ＵＤＭ３０Ｇは、個々の加入者情報に対して、当該加入者が許可されているＡＰＩ及び許可されたメソッド、許可されたユーザを一覧としてＣＣＦ３０Ｂに返却してもよい。例えば、ＵＤＭ３０Ｇは、図１７に示されるオプション１のように、許可ＡＰＩ、メソッド及び対象ユーザを関連付けて１エントリとしてＣＣＦ３０に返却してもよい。

【0050】

また、例えば、ＵＤＭ３０Ｇは、図１７に示されるオプション２のように、Ｒｏｌｅ対応表として、典型的なスコープの設定としてＲｏｌｅ、メソッド及び対象ユーザを１エントリとして関連付けて予め定義し、許可ＡＰＩといずれのＲｏｌｅかを示す情報を、ＣＣＦ３０Ｂに返却してもよい。すなわち、ＣＣＦ３０Ｂは、個々の加入者とＲｏｌｅを関連付けることで、各ＡＰＩで許可された動作を特定してもよい。

【0051】

図１８は、本発明の実施の形態におけるＵＥ及びＡＦを含むシステムの例を示す図である。図１８に示されるように、信頼済ドメインであるＰＬＭＮ（PLMN Trust domain）には、ＣＡＰＩＦ－ＡＰＩを含むＣＣＦ３０Ｂ、サービスＡＰＩを含むＡＥＦ３０Ｃ、ＡＰＦ（API Publishing Function）３０Ｄ、ＡＭＦ（API Management Function）３０Ｅ、コアネットワーク及びアクセスネットワークが属する。一方、ＰＬＭＮ外には、ＡＰＩ呼び出し元３０Ａ（例えばゲームサーバ）、ＵＥ２０が存在する。

【0052】

図１８に示されるように、ＡＰＩ呼び出し元３０Ａは、コアネットワークを介してＡＥＦ３０Ｃに接続されてもよいし、ＣＡＰＩＦ－ＡＰＩ及びサービスＡＰＩを呼び出し可能であってもよい。ＵＥ２０は、アクセスネットワーク及びコアネットワークを介して、ＡＰＩ呼び出し元３０Ａ、ＡＥＦ３０Ｃと接続されてもよい。

【0053】

図１９は、本発明の実施の形態におけるＵＥを含むシステムの例を示す図である。図１８に示されるように、信頼済ドメインであるＰＬＭＮには、ＣＡＰＩＦ－ＡＰＩを含むＣＣＦ３０Ｂ、サービスＡＰＩを含むＡＥＦ３０Ｃ、ＡＰＦ３０Ｄ、ＡＭＦ３０Ｅ、コアネットワーク及びアクセスネットワークが属する。一方、ＰＬＭＮ外には、ＵＥ２０が存在する。

【0054】

図１８に示されるように、ＵＥ２０は、アクセスネットワーク及びコアネットワークを介して、ＣＣＦ３０Ｂ、ＡＥＦ３０Ｃと接続されてもよいし、ＣＡＰＩＦ－ＡＰＩ及びサービスＡＰＩを呼び出し可能であってもよい。

【0055】

なお、図１８及び図１９はシステム構成の一例を示すものであり、これに限られない。例えば、ＡＥＦ３０Ｃ、ＡＰＦ３０Ｄ及びＡＭＦ３０Ｅが信頼済ＰＬＭＮドメイン外にあってもよい。

【0056】

図２０は、本発明の実施の形態におけるＵＥによるＡＰＩ呼び出しの例を説明するためのシーケンス図である。図２０を用いて、上述した図８から図１１までのＵＥによるＡＰＩ呼び出しの例の詳細な動作を説明する。

【0057】

ステップＳ１０１において、ＵＥ２０は、ＢＳＦ３０Ｆ及びＵＤＭ３０ＧとＢｏｏｔｓｔｒａｐｐｉｎｇ手順を実行する。続くステップＳ１０２において、ＵＥ２０は、ＣＣＦ２０Ｂとアプリケーション要求／応答を実行、ＣＣＦ２０Ｂは、ＢＳＦ３０Ｆと認証要求／応答を実行する。続くステップＳ１０３において、ＵＥ２０はＮＡ－ＧＵＴＩを取得する。続くステップＳ１０４において、ＵＥ２０はＣＣＦ３０Ｂから必要な通知を受けられるようＣＣＦ３０ＢにＳｕｂｓｃｒｉｂｅする。続くステップＳ１０５において、ＵＥ２０とＣＣＦ３０Ｂとの間のＴＬＳ（Transport Layer Security）接続が確立される。ステップＳ１０１からステップＳ１０５までの手順により、既存のＯｎｂｏａｒｄｉｎｇの代わりに、Ｂｏｏｔｓｔｒａｐｐｉｎｇにて端末２０を認証してからＵＥ－ＣＣＦ間で通信を行う。なお、ステップＳ１０４は、実行されてもよいし、実行されなくてもよい。

【0058】

ステップＳ１０６において、ＵＥ２０は、セキュリティメソッド要求をＣＣＦ３０Ｂに送信する。続くステップＳ１０７において、ＣＣＦ３０Ｂは、セキュリティメソッドを選択する。続くステップＳ１０８において、ＯＡｕｔｈ ２．０ Ｃｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌであるセキュリティメソッド応答が、ＣＣＦ３０ＢからＵＥ２０に送信される。ステップＳ１０６からステップＳ１０８までの手順により、ＡＰＩ呼び出しに使用するセキュリティメソッドが決定される。

【0059】

ステップＳ１０９において、ＵＥ２０は、ＮＡ－ＧＵＴＩを用いて、ＯＡｕｔｈ ２．０に基づいたアクセストークン要求をＣＣＦ３０Ｂに送信する。続くステップＳ１１０において、ＣＣＦ３０Ｂは、加入者情報の確認をＵＤＭ３０Ｇに対して行う。続くステップＳ１１１において、ＣＣＦ３０Ｂは、アクセストークン要求を検証する。続くステップＳ１１２において、ＣＣＦ３０Ｂは、ＯＡｕｔｈ ２．０によるアクセストークンをＵＥ２０に応答する。ステップＳ１０９からステップＳ１１２までの手順により、ＮＡ－ＧＵＴＩを用いてアクセストークンが発行され、ＡＰＩ呼び出しのためのアクセストークンを端末２０は取得する。

【0060】

ステップＳ１１３において、ＵＥ２０とＡＥＦ３０Ｃ間にＴＬＳ接続が確立される。続くステップＳ１１４において、ＵＥ２０は、ＯＡｕｔｈ ２．０によるアクセストークンによって、Ｎｏｒｔｈｂｏｕｎｄ ＡＰＩをＡＥＦ３０Ｃに対して呼び出す。続くステップＳ１１５において、ＣＣＦ３０Ｂは、加入者情報の確認をＵＤＭ３０Ｇに対して行う。続くステップＳ１１６において、ＡＥＦ３０Ｃは、アクセストークンを検証する。続くステップＳ１１７において、ＡＥＦ３０Ｃは、Ｎｏｒｔｈｂｏｕｎｄ ＡＰＩ呼び出しに係る応答をＵＥ２０に送信する。ステップＳ１１３からステップＳ１１７までの手順で、ＡＰＩ呼び出しが実行される。

【0061】

図２１は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例を説明するためのシーケンス（１）図である。図２２は、本発明の実施の形態におけるＵＥ及びＡＦによるＡＰＩ呼び出しの例を説明するためのシーケンス（２）図である。図２１及び図２２を用いて、上述した図１２から図１６までのＵＥ及びＡＦによるＡＰＩ呼び出しの例の詳細な動作を説明する。

【0062】

ステップＳ２０１において、ＡＭＦ３０Ｅは、Ｏｎｂｏａｄｉｎｇ登録情報（ＣＣＦ情報、ＯＡｕｔｈ ２．０アクセストークンを伴う）をＡＦ３０Ａに送信する。ステップＳ２０１はＡＦ３０Ａがオフラインの何らかの手法でＯｎｂｏａｄｉｎｇ登録情報を取得することでもよい。ステップＳ２０２において、ＡＦ３０ＡとＣＣＦ３０Ｂとの間にＴＬＳ接続が確立される。続くステップＳ２０３において、ＡＦ３０Ａは、Ｏｎｂｏａｒｄ ＡＰＩ呼び出し要求（ＯＡｕｔｈ ２．０アクセストークン、ＡＰＩ呼び出しパブリックキーを伴う）をＣＣＦ３０Ｂに送信する。続くステップＳ２０４において、ＣＣＦ３０Ｂは、Ｏｎｂｏａｒｄ ＡＰＩ呼び出し応答（ＡＰＩ呼び出しＩＤ、ＡＰＩ呼び出し証明書、Ｏｎｂｏａｒｄシークレットを伴う）をＡＦ３０Ａに送信する。ステップＳ２０１からステップＳ２０４までの動作で、ＡＦのＯｎｂｏａｒｄｉｎｇ（登録）が完了する。

【0063】

ステップＳ２０５において、ＵＥ２０は、ＢＳＦ３０Ｆ及びＵＤＭ３０ＧとＢｏｏｔｓｔｒａｐｐｉｎｇ手順を実行する。続くステップＳ２０６において、ＵＥ２０は、ＣＣＦ２０Ｂとアプリケーション要求／応答を実行、ＣＣＦ２０Ｂは、ＢＳＦ３０Ｆと認証要求／応答を実行する。続くステップＳ２０７において、ＵＥ２０はＮＡ－ＧＵＴＩを取得する。続くステップＳ２０８において、ＵＥ２０はＣＣＦ３０Ｂから必要な通知を受けられるようＣＣＦ３０ＢにＳｕｂｓｃｒｉｂｅする。ステップＳ２０５からステップＳ２０８までの手順により、Ｂｏｏｔｓｔｒａｐｐｉｎｇ完了する。すなわち、ＡＦ３０ＡはＯｎｂｏａｒｄｉｎｇを実施し、ＵＥ２０はＢｏｏｔｓｔｒａｐｐｉｎｇを実施する。

【0064】

ステップＳ２０９において、ＣＣＦ３０Ｂは、ＡＰＩ呼び出しのトリガを検知する。続くステップＳ２１０において、ＡＦ３０Ａは、セキュリティメソッド要求をＣＣＦ３０Ｂに送信する。続くステップＳ２１１において、ＣＣＦ３０Ｂは、セキュリティメソッドを選択する。続くステップＳ２１２において、ＣＣＦ３０Ｂは、ＯＡｕｔｈ ２．０ Ａｕｔｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｆｌｏｗによるセキュリティメソッド応答をＡＦ３０Ａに送信する。ステップＳ２０９からステップＳ２１２までの手順でＡＰＩ呼び出しに使用するセキュリティメソッドが決定される。

【0065】

ステップＳ２１３において、ＡＦ３０Ａは、ユーザにＡＰＩ利用可否の確認を行う。ＵＥ２０は必要に応じて応答をＡＦ３０Ａに送信する。続くステップＳ２１４において、ＡＦ３０Ａは、ＣＡＰＩＦセキュリティ要求及び認証要求（ＮＡ－ＧＵＴＩを伴う）をＣＣＦ３０Ｂに送信する。続くステップＳ２１５において、ＣＣＦ３０Ｂは、加入者情報の確認をＵＤＭ３０Ｇに対して行う。続くステップＳ２１６において、ＵＥ２０とＣＣＦ３０Ｂとの間でＴＬＳ接続が確立される。続くステップＳ２１７において、ＵＥ２０とＣＣＦ３０Ｂとの間で、ＣＡＰＩＦセキュリティ要求及び認証通知要求／応答が実行される。続くステップＳ２１８において、ＣＣＦ３０Ｂは、Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅを発行し、ＡＦ３０Ａに送信する。ステップＳ２１３からステップＳ２１８までの手順により、ユーザからの許可取得及びＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅの発行が実施される。

【0066】

ステップＳ２１９において、ＡＦ３０Ａは、Ａｕｔｈｏｒｉｚａｔｉｏｎ ＣｏｄｅによるＯＡｕｔｈ ２．０によるアクセストークン要求をＣＣＦ３０Ｂに送信する。続くステップＳ２２０において、ＣＣＦ３０Ｂは、アクセストークン要求を検証する。続くステップＳ２２１において、ＯＡｕｔｈ ２．０によるアクセストークン（アクセストークン、有効期限、スコープを伴う）をＡＦ３０Ａに応答する。ステップＳ２１９からステップＳ２２１までの手順によって、ＡＰＩ呼び出しのためのアクセストークンが取得される。

【0067】

ステップＳ２２２において、ＡＦ３０ＡとＡＥＦ３０Ｃ間にＴＬＳ接続が確立される。続くステップＳ２２３において、ＡＦ３０Ａは、ＯＡｕｔｈ ２．０によるアクセストークンによって、Ｎｏｒｔｈｂｏｕｎｄ ＡＰＩをＡＥＦ３０Ｃに対して呼び出す。続くステップＳ２２４において、ＣＣＦ３０Ｂは、加入者情報の確認をＵＤＭ３０Ｇに対して行う。続くステップＳ２２５において、ＡＥＦ３０Ｃは、アクセストークンを検証する。続くステップＳ２２６において、ＡＥＦ３０Ｃは、Ｎｏｒｔｈｂｏｕｎｄ ＡＰＩ呼び出しに係る応答をＡＦ３０Ａに送信する。ステップＳ２２２からステップＳ２２６までの手順で、ＡＰＩ呼び出しが実行される。

【0068】

上述の実施例により、回線利用者の立場においては、個々の契約者の契約情報に基づいて、エンドユーザ自身が端末からコアネットワークのＡＰＩを利用し、ネットワークの制御ができるようになる。オペレータの立場においては、ネットワークが解放するＡＰＩのうち、個々の契約者が利用できるＡＰＩの粒度を加入者情報に基づいて管理することで、必要最低限のＡＰＩのみを利用者に開放することができる。

【0069】

また、ＡＰＩ呼び出しの事前準備として、既存のＯｎｂｏａｒｄｉｎｇに代替して、端末のＳＩＭ情報を使って、個々の契約者を認証するＢｏｏｔｓｔｒａｐｐｉｎｇを用いることにより、ＡＰＩ呼び出しのトリガとなる個々の契約者を識別することができる。

【0070】

また、個々の契約者が利用できるＡＰＩの範囲を加入者情報に保持しておき、当該加入者情報をチェックすることで、個人の粒度でＡＰＩ利用の権限を管理することができる。

【0071】

また、ＵＥ２０及びＡＦ３０ＡによるＡＰＩ呼び出しの場合、ＯＡｕｔｈ ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｆｌｏｗ方式を利用することで、サードパーティのＡＦ及びオペレータのネットワークノードが契約者の承諾を安全に取得しつつ、個々の契約者に許可されたＡＰＩを利用することができる。

【0072】

すなわち、ネットワークにおいて加入者情報を識別可能とするインタフェースを提供することができる。

【0073】

（装置構成）
次に、これまでに説明した処理及び動作を実施する基地局１０、ネットワークノード３０及び端末２０の機能構成例を説明する。基地局１０、ネットワークノード３０及び端末２０は上述した実施例を実施する機能を含む。ただし、基地局１０、ネットワークノード３０及び端末２０はそれぞれ、実施例の中の一部の機能のみを備えることとしてもよい。

【0074】

＜基地局１０及びネットワークノード３０＞
図２３は、基地局１０の機能構成の一例を示す図である。図２３に示されるように、基地局１０は、送信部１１０と、受信部１２０と、設定部１３０と、制御部１４０とを有する。図２３に示される機能構成は一例に過ぎない。本発明の実施の形態に係る動作を実施できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。なお、ネットワークノード３０は、基地局１０と同様の機能構成を有してもよい。また、システムアーキテクチャ上で複数の異なる機能を有するネットワークノード３０は、機能ごとに分離された複数のネットワークノード３０から構成されてもよい。また、ネットワークノード３０は、コアネットワーク又はアクセスネットワークに存在するネットワークノードに限定されず、ＰＬＭＮドメインに属するネットワークノードに対応してもよい。

【0075】

送信部１１０は、端末２０又は他のネットワークノード３０に送信する信号を生成し、当該信号を有線又は無線で送信する機能を含む。受信部１２０は、端末２０又は他のネットワークノード３０から送信された各種の信号を受信し、受信した信号から、例えばより上位のレイヤの情報を取得する機能を含む。

【0076】

設定部１３０は、予め設定される設定情報、及び、端末２０に送信する各種の設定情報を記憶装置に格納し、必要に応じて記憶装置から読み出す。設定情報の内容は、例えば、ネットワークにおける加入者のプロファイル情報等である。

【0077】

制御部１４０は、実施例において説明したように、ネットワークにおける加入者のプロファイル情報の更新に係る処理を行う。また、制御部１４０は、端末２０との通信に係る処理を行う。制御部１４０における信号送信に関する機能部を送信部１１０に含め、制御部１４０における信号受信に関する機能部を受信部１２０に含めてもよい。

【0078】

＜端末２０＞
図２４は、端末２０の機能構成の一例を示す図である。図２４に示されるように、端末２０は、送信部２１０と、受信部２２０と、設定部２３０と、制御部２４０とを有する。図２４に示される機能構成は一例に過ぎない。本発明の実施の形態に係る動作を実施できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。

【0079】

送信部２１０は、送信データから送信信号を作成し、当該送信信号を無線で送信する。受信部２２０は、各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する。また、受信部２２０は、ネットワークノード３０から送信されるＮＲ－ＰＳＳ、ＮＲ－ＳＳＳ、ＮＲ－ＰＢＣＨ、ＤＬ／ＵＬ制御信号又は参照信号等を受信する機能を有する。

【0080】

設定部２３０は、受信部２２０によりネットワークノード３０から受信した各種の設定情報を記憶装置に格納し、必要に応じて記憶装置から読み出す。また、設定部２３０は、予め設定される設定情報も格納する。設定情報の内容は、例えば、接続が許可されるネットワークに係る情報等である。

【0081】

制御部２４０は、実施例において説明したように、ネットワーク及びネットワークスライスへの接続制御に係る処理を行う。制御部２４０における信号送信に関する機能部を送信部２１０に含め、制御部２４０における信号受信に関する機能部を受信部２２０に含めてもよい。

【0082】

（ハードウェア構成）
上記実施形態の説明に用いたブロック図（図２３及び図２４）は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及びソフトウェアの少なくとも一方の任意の組み合わせによって実現される。また、各機能ブロックの実現方法は特に限定されない。すなわち、各機能ブロックは、物理的又は論理的に結合した１つの装置を用いて実現されてもよいし、物理的又は論理的に分離した２つ以上の装置を直接的又は間接的に（例えば、有線、無線などを用いて）接続し、これら複数の装置を用いて実現されてもよい。機能ブロックは、上記１つの装置又は上記複数の装置にソフトウェアを組み合わせて実現されてもよい。

【0083】

機能には、判断、決定、判定、計算、算出、処理、導出、調査、探索、確認、受信、送信、出力、アクセス、解決、選択、選定、確立、比較、想定、期待、見做し、報知（broadcasting）、通知（notifying）、通信（communicating）、転送（forwarding）、構成（configuring）、再構成（reconfiguring）、割り当て（allocating、mapping）、割り振り（assigning）などがあるが、これらに限られない。たとえば、送信を機能させる機能ブロック（構成部）は、送信部（transmitting unit）や送信機（transmitter）と呼称される。いずれも、上述したとおり、実現方法は特に限定されない。

【0084】

例えば、本開示の一実施の形態におけるネットワークノード３０、端末２０等は、本開示の無線通信方法の処理を行うコンピュータとして機能してもよい。図２５は、本開示の一実施の形態に係る基地局１０及び端末２０のハードウェア構成の一例を示す図である。ネットワークノード３０は、基地局１０と同様のハードウェア構成を有してもよい。上述の基地局１０及び端末２０は、物理的には、プロセッサ１００１、記憶装置１００２、補助記憶装置１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。

【0085】

なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニット等に読み替えることができる。基地局１０及び端末２０のハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。

【0086】

基地局１０及び端末２０における各機能は、プロセッサ１００１、記憶装置１００２等のハードウェア上に所定のソフトウェア（プログラム）を読み込ませることによって、プロセッサ１００１が演算を行い、通信装置１００４による通信を制御したり、記憶装置１００２及び補助記憶装置１００３におけるデータの読み出し及び書き込みの少なくとも一方を制御したりすることによって実現される。

【0087】

プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインタフェース、制御装置、演算装置、レジスタ等を含む中央処理装置（ＣＰＵ：Central Processing Unit）で構成されてもよい。例えば、上述の制御部１４０、制御部２４０等は、プロセッサ１００１によって実現されてもよい。

【0088】

また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール又はデータ等を、補助記憶装置１００３及び通信装置１００４の少なくとも一方から記憶装置１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態において説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、図２３に示した基地局１０の制御部１４０は、記憶装置１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。また、例えば、図２４に示した端末２０の制御部２４０は、記憶装置１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。上述の各種処理は、１つのプロセッサ１００１によって実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップによって実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されてもよい。

【0089】

記憶装置１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ROM）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ROM）、ＲＡＭ（Random Access Memory）等の少なくとも１つによって構成されてもよい。記憶装置１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）等と呼ばれてもよい。記憶装置１００２は、本開示の一実施の形態に係る通信方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュール等を保存することができる。

【0090】

補助記憶装置１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ－ＲＯＭ（Compact Disc ROM）等の光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ－ｒａｙ（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップ等の少なくとも１つによって構成されてもよい。上述の記憶媒体は、例えば、記憶装置１００２及び補助記憶装置１００３の少なくとも一方を含むデータベース、サーバその他の適切な媒体であってもよい。

【0091】

通信装置１００４は、有線ネットワーク及び無線ネットワークの少なくとも一方を介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。通信装置１００４は、例えば周波数分割複信（ＦＤＤ：Frequency Division Duplex）及び時分割複信（ＴＤＤ：Time Division Duplex）の少なくとも一方を実現するために、高周波スイッチ、デュプレクサ、フィルタ、周波数シンセサイザなどを含んで構成されてもよい。例えば、送受信アンテナ、アンプ部、送受信部、伝送路インタフェース等は、通信装置１００４によって実現されてもよい。送受信部は、送信部と受信部とで、物理的に、または論理的に分離された実装がなされてもよい。

【0092】

入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサ等）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプ等）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。

【0093】

また、プロセッサ１００１及び記憶装置１００２等の各装置は、情報を通信するためのバス１００７によって接続される。バス１００７は、単一のバスを用いて構成されてもよいし、装置間ごとに異なるバスを用いて構成されてもよい。

【0094】

また、基地局１０及び端末２０は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）等のハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つを用いて実装されてもよい。

【0095】

（実施の形態のまとめ）
以上、説明したように、本発明の実施の形態によれば、端末を認証し暫定識別子を当該端末に送信する送信部と、前記暫定識別子を含む要求又は前記暫定識別子に基づく認証コードを受信する受信部と、前記暫定識別子を含む要求又は前記認証コードに基づいて、アクセストークンを発行する制御部とを有し、前記送信部は、前記アクセストークンを前記端末又は外部アプリケーションに送信し、前記受信部は、前記アクセストークンに基づくＡＰＩ（Application Programming Interface）呼び出し要求を前記端末又は前記外部アプリケーションから受信し、前記制御部は、前記アクセストークンを検証して前記ＡＰＩ呼び出し要求が認可されたものであると判定した場合、前記ＡＰＩ呼び出し要求に基づいて処理を実行するネットワークノードが提供される。

【0096】

上記の構成により、回線利用者の立場においては、個々の契約者の契約情報に基づいて、エンドユーザ自身が端末からコアネットワークのＡＰＩを利用し、ネットワークの制御ができるようになる。オペレータの立場においては、ネットワークが解放するＡＰＩのうち、個々の契約者が利用できるＡＰＩの粒度を加入者情報に基づいて管理することで、必要最低限のＡＰＩのみを利用者に開放することができる。また、ＡＰＩ呼び出しの事前準備として、既存のＯｎｂｏａｒｄｉｎｇに代替して、端末のＳＩＭ情報を使って、個々の契約者を認証するＢｏｏｔｓｔｒａｐｐｉｎｇを用いることにより、ＡＰＩ呼び出しのトリガとなる個々の契約者を識別することができる。また、個々の契約者が利用できるＡＰＩの範囲を加入者情報に保持しておき、当該加入者情報をチェックすることで、個人の粒度でＡＰＩ利用の権限を管理することができる。また、ＵＥ２０及びＡＦ３０ＡによるＡＰＩ呼び出しの場合、ＯＡｕｔｈ ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｆｌｏｗ方式を利用することで、サードパーティのＡＦ及びオペレータのネットワークノードが契約者の承諾を安全に取得しつつ、個々の契約者に許可されたＡＰＩを利用することができる。すなわち、ネットワークにおいて加入者情報を識別可能とするインタフェースを提供することができる。

【0097】

前記受信部は、前記端末又は前記外部アプリケーションからＡＰＩ呼び出しに使用するセキュリティメソッドに係る要求を受信し、前記制御部は、セキュリティメソッドを選択し、前記送信部は、前記選択したセキュリティメソッドを示す応答を前記端末又は外部アプリケーションに送信してもよい。当該構成により、ネットワークノードは、ＡＰＩ呼び出しに使用するセキュリティメソッドを選択し設定することができる。

【0098】

前記送信部が前記アクセストークンを前記外部アプリケーションに送信する場合、前記制御部は、前記外部アプリケーションを予め認証し登録してもよい。当該構成により、ネットワークノードは、認証された外部アプリケーションから、ＵＥに係るＡＰＩ呼び出しを受けることができる。

【0099】

前記送信部が前記アクセストークンを前記外部アプリケーションに送信する場合、前記制御部は、ユーザにＡＰＩ利用可否の確認を実施した後、前記アクセストークンを発行してもよい。当該構成により、ネットワークノードは、外部アプリケーションがＡＰＩ呼び出しを実行する場合、事前にユーザの意図を確認してからＡＰＩ呼び出しを実行することができる。

【0100】

前記制御部は、前記ＡＰＩ呼び出し要求が認可されたものであるかを判定するとき、少なくともユーザごとのスコープが設定される、許可されるＡＰＩ及び許可されるメソッドを参照してもよい。当該構成により、ネットワークノードは、ユーザごとの粒度のスコープで、ＡＰＩ呼び出しを制御することができる。

【0101】

また、本発明の実施の形態によれば、端末を認証し暫定識別子を当該端末に送信する送信手順と、前記暫定識別子を含む要求又は前記暫定識別子に基づく認証コードを受信する受信手順と、前記暫定識別子を含む要求又は前記認証コードに基づいて、アクセストークンを発行する制御手順と、前記アクセストークンを前記端末又は外部アプリケーションに送信する手順と、前記アクセストークンに基づくＡＰＩ（Application Programming Interface）呼び出し要求を前記端末又は前記外部アプリケーションから受信する手順と、前記アクセストークンを検証して前記ＡＰＩ呼び出し要求が認可されたものであると判定した場合、前記ＡＰＩ呼び出し要求に基づいて処理を実行する手順とをネットワークノードが実行する通信方法が提供される。

【0102】

上記の構成により、回線利用者の立場においては、個々の契約者の契約情報に基づいて、エンドユーザ自身が端末からコアネットワークのＡＰＩを利用し、ネットワークの制御ができるようになる。オペレータの立場においては、ネットワークが解放するＡＰＩのうち、個々の契約者が利用できるＡＰＩの粒度を加入者情報に基づいて管理することで、必要最低限のＡＰＩのみを利用者に開放することができる。また、ＡＰＩ呼び出しの事前準備として、既存のＯｎｂｏａｒｄｉｎｇに代替して、端末のＳＩＭ情報を使って、個々の契約者を認証するＢｏｏｔｓｔｒａｐｐｉｎｇを用いることにより、ＡＰＩ呼び出しのトリガとなる個々の契約者を識別することができる。また、個々の契約者が利用できるＡＰＩの範囲を加入者情報に保持しておき、当該加入者情報をチェックすることで、個人の粒度でＡＰＩ利用の権限を管理することができる。また、ＵＥ２０及びＡＦ３０ＡによるＡＰＩ呼び出しの場合、ＯＡｕｔｈ ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｆｌｏｗ方式を利用することで、サードパーティのＡＦ及びオペレータのネットワークノードが契約者の承諾を安全に取得しつつ、個々の契約者に許可されたＡＰＩを利用することができる。すなわち、ネットワークにおいて加入者情報を識別可能とするインタフェースを提供することができる。

【0103】

（実施形態の補足）
以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。実施の形態で述べた処理手順については、矛盾の無い限り処理の順序を入れ替えてもよい。処理説明の便宜上、ネットワークノード３０及び端末２０は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従ってネットワークノード３０が有するプロセッサにより動作するソフトウェア及び本発明の実施の形態に従って端末２０が有するプロセッサにより動作するソフトウェアはそれぞれ、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ－ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。

【0104】

また、情報の通知は、本開示で説明した態様／実施形態に限られず、他の方法を用いて行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Downlink Control Information）、ＵＣＩ（Uplink Control Information））、上位レイヤシグナリング（例えば、ＲＲＣ（Radio Resource Control）シグナリング、ＭＡＣ（Medium Access Control）シグナリング、報知情報（ＭＩＢ（Master Information Block）、ＳＩＢ（System Information Block））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、ＲＲＣメッセージと呼ばれてもよく、例えば、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージ、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージ等であってもよい。

【0105】

本開示において説明した各態様／実施形態は、ＬＴＥ（Long Term Evolution）、ＬＴＥ－Ａ（LTE-Advanced）、ＳＵＰＥＲ ３Ｇ、ＩＭＴ－Ａｄｖａｎｃｅｄ、４Ｇ（4th generation mobile communication system）、５Ｇ（5th generation mobile communication system）、ＦＲＡ（Future Radio Access）、ＮＲ（new Radio）、Ｗ－ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra Mobile Broadband）、ＩＥＥＥ ８０２．１１（Ｗｉ－Ｆｉ（登録商標））、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ（登録商標））、ＩＥＥＥ ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及びこれらに基づいて拡張された次世代システムの少なくとも一つに適用されてもよい。また、複数のシステムが組み合わされて（例えば、ＬＴＥ及びＬＴＥ－Ａの少なくとも一方と５Ｇとの組み合わせ等）適用されてもよい。

【0106】

本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャート等は、矛盾の無い限り、順序を入れ替えてもよい。例えば、本開示において説明した方法については、例示的な順序を用いて様々なステップの要素を提示しており、提示した特定の順序に限定されない。

【0107】

本明細書においてネットワークノード３０によって行われるとした特定動作は、場合によってはその上位ノード（upper node）によって行われることもある。ネットワークノード３０を有する１つ又は複数のネットワークノード（network nodes）からなるネットワークにおいて、端末２０との通信のために行われる様々な動作は、ネットワークノード３０及びネットワークノード３０以外の他のネットワークノード（例えば、ＭＭＥ又はＳ－ＧＷ等が考えられるが、これらに限られない）の少なくとも１つによって行われ得ることは明らかである。上記においてネットワークノード３０以外の他のネットワークノードが１つである場合を例示したが、他のネットワークノードは、複数の他のネットワークノードの組み合わせ（例えば、ＭＭＥ及びＳ－ＧＷ）であってもよい。

【0108】

本開示において説明した情報又は信号等は、上位レイヤ（又は下位レイヤ）から下位レイヤ（又は上位レイヤ）へ出力され得る。複数のネットワークノードを介して入出力されてもよい。

【0109】

入出力された情報等は特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルを用いて管理してもよい。入出力される情報等は、上書き、更新、又は追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。

【0110】

本開示における判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：true又はfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。

【0111】

ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。

【0112】

また、ソフトウェア、命令、情報などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、有線技術（同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ：Digital Subscriber Line）など）及び無線技術（赤外線、マイクロ波など）の少なくとも一方を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び無線技術の少なくとも一方は、伝送媒体の定義内に含まれる。

【0113】

本開示において説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。

【0114】

なお、本開示において説明した用語及び本開示の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及びシンボルの少なくとも一方は信号（シグナリング）であってもよい。また、信号はメッセージであってもよい。また、コンポーネントキャリア（ＣＣ：Component Carrier）は、キャリア周波数、セル、周波数キャリアなどと呼ばれてもよい。

【0115】

本開示において使用する「システム」及び「ネットワーク」という用語は、互換的に使用される。

【0116】

また、本開示において説明した情報、パラメータなどは、絶対値を用いて表されてもよいし、所定の値からの相対値を用いて表されてもよいし、対応する別の情報を用いて表されてもよい。例えば、無線リソースはインデックスによって指示されるものであってもよい。

【0117】

上述したパラメータに使用する名称はいかなる点においても限定的な名称ではない。さらに、これらのパラメータを使用する数式等は、本開示で明示的に開示したものと異なる場合もある。様々なチャネル（例えば、ＰＵＣＣＨ、ＰＤＣＣＨなど）及び情報要素は、あらゆる好適な名称によって識別できるので、これらの様々なチャネル及び情報要素に割り当てている様々な名称は、いかなる点においても限定的な名称ではない。

【0118】

本開示においては、「基地局（ＢＳ：Base Station）」、「無線基地局」、「基地局装置」、「固定局（fixed station）」、「ＮｏｄｅＢ」、「ｅＮｏｄｅＢ（ｅＮＢ）」、「ｇＮｏｄｅＢ（ｇＮＢ）」、「アクセスポイント（access point）」、「送信ポイント（transmission point）」、「受信ポイント（reception point）、「送受信ポイント（transmission/reception point）」、「セル」、「セクタ」、「セルグループ」、「キャリア」、「コンポーネントキャリア」などの用語は、互換的に使用され得る。基地局は、マクロセル、スモールセル、フェムトセル、ピコセルなどの用語で呼ばれる場合もある。

【0119】

基地局は、１つ又は複数（例えば、３つ）のセルを収容することができる。基地局が複数のセルを収容する場合、基地局のカバレッジエリア全体は複数のより小さいエリアに区分でき、各々のより小さいエリアは、基地局サブシステム（例えば、屋内用の小型基地局（ＲＲＨ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｈｅａｄ）によって通信サービスを提供することもできる。「セル」又は「セクタ」という用語は、このカバレッジにおいて通信サービスを行う基地局及び基地局サブシステムの少なくとも一方のカバレッジエリアの一部又は全体を指す。

【0120】

本開示においては、「移動局（ＭＳ：Mobile Station）」、「ユーザ端末（user terminal）」、「ユーザ装置（ＵＥ：User Equipment）」、「端末」などの用語は、互換的に使用され得る。

【0121】

移動局は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、又はいくつかの他の適切な用語で呼ばれる場合もある。

【0122】

基地局及び移動局の少なくとも一方は、送信装置、受信装置、通信装置などと呼ばれてもよい。なお、基地局及び移動局の少なくとも一方は、移動体に搭載されたデバイス、移動体自体などであってもよい。当該移動体は、乗り物（例えば、車、飛行機など）であってもよいし、無人で動く移動体（例えば、ドローン、自動運転車など）であってもよいし、ロボット（有人型又は無人型）であってもよい。なお、基地局及び移動局の少なくとも一方は、必ずしも通信動作時に移動しない装置も含む。例えば、基地局及び移動局の少なくとも一方は、センサなどのＩｏＴ（Internet of Things）機器であってもよい。

【0123】

また、本開示における基地局は、ユーザ端末で読み替えてもよい。例えば、基地局及びユーザ端末間の通信を、複数の端末２０間の通信（例えば、Ｄ２Ｄ（Device-to-Device）、Ｖ２Ｘ（Vehicle-to-Everything）などと呼ばれてもよい）に置き換えた構成について、本開示の各態様／実施形態を適用してもよい。この場合、上述のネットワークノード３０が有する機能を端末２０が有する構成としてもよい。また、「上り」及び「下り」などの文言は、端末間通信に対応する文言（例えば、「サイド（side）」）で読み替えられてもよい。例えば、上りチャネル、下りチャネルなどは、サイドチャネルで読み替えられてもよい。

【0124】

同様に、本開示におけるユーザ端末は、基地局で読み替えてもよい。この場合、上述のユーザ端末が有する機能を基地局が有する構成としてもよい。

【0125】

本開示で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定(judging)、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up、search、inquiry)（例えば、テーブル、データベース又は別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。また、「判断（決定）」は、「想定する（assuming）」、「期待する（expecting）」、「みなす（considering）」などで読み替えられてもよい。

【0126】

「接続された(connected)」、「結合された(coupled)」という用語、又はこれらのあらゆる変形は、２又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された２つの要素間に１又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。例えば、「接続」は「アクセス」で読み替えられてもよい。本開示で使用する場合、２つの要素は、１又はそれ以上の電線、ケーブル及びプリント電気接続の少なくとも一つを用いて、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギーなどを用いて、互いに「接続」又は「結合」されると考えることができる。

【0127】

参照信号は、ＲＳ（Reference Signal）と略称することもでき、適用される標準によってパイロット（Pilot）と呼ばれてもよい。

【0128】

本開示において使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

【0129】

本開示において使用する「第１の」、「第２の」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定しない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本開示において使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみが採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。

【0130】

上記の各装置の構成における「手段」を、「部」、「回路」、「デバイス」等に置き換えてもよい。

【0131】

本開示において、「含む（include）」、「含んでいる（including）」及びそれらの変形が使用されている場合、これらの用語は、用語「備える（comprising）」と同様に、包括的であることが意図される。さらに、本開示において使用されている用語「又は（or）」は、排他的論理和ではないことが意図される。

【0132】

本開示において、例えば、英語でのa, an及びtheのように、翻訳により冠詞が追加された場合、本開示は、これらの冠詞の後に続く名詞が複数形であることを含んでもよい。

【0133】

本開示において、「ＡとＢが異なる」という用語は、「ＡとＢが互いに異なる」ことを意味してもよい。なお、当該用語は、「ＡとＢがそれぞれＣと異なる」ことを意味してもよい。「離れる」、「結合される」などの用語も、「異なる」と同様に解釈されてもよい。

【0134】

本開示において説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。

【0135】

なお、本開示におけるＡＦは、外部アプリケーションの一例である。ＮＡ－ＧＵＴＩは、暫定識別子の一例である。

【0136】

以上、本開示について詳細に説明したが、当業者にとっては、本開示が本開示中に説明した実施形態に限定されるものではないということは明らかである。本開示は、請求の範囲の記載により定まる本開示の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本開示の記載は、例示説明を目的とするものであり、本開示に対して何ら制限的な意味を有するものではない。

【符号の説明】

【0137】

１０ 基地局
１１０ 送信部
１２０ 受信部
１３０ 設定部
１４０ 制御部
２０ 端末
２１０ 送信部
２２０ 受信部
２３０ 設定部
２４０ 制御部
３０ ネットワークノード
１００１ プロセッサ
１００２ 記憶装置
１００３ 補助記憶装置
１００４ 通信装置
１００５ 入力装置
１００６ 出力装置

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】