はじめに
NTTドコモ ６Ｇテック部の魚島です。
本日はモバイル通信規格を規定している国際標準化プロジェクトである3GPPでドコモがリードし、規格化したRNAA(Resource owner-aware Northbound API Access)の技術についてご紹介いたします。 私は現在3GPP SA6(3GPPネットワークを活用するアプリケーション向けのアーキテクチャを中心に仕様検討するワーキンググループ)でRNAAと関連するCAPIFのガイドラインを策定するアイテム(CAPIF_EXT)のラポータ(3GPPでの議論をリードする役割)を務めています。
- はじめに
- モバイル通信分野における「Network Exposure」とは
- Network Exposure分野の全体像
- 3GPP RNAAとCAPIFの関係性
- 3GPP RNAAの仕様
- 3GPP RNAA PoC
- まとめ
モバイル通信分野における「Network Exposure」とは
モバイル通信分野における「Network Exposure1」とはモバイルネットワークの機能やリソースの一部を外部の3rd Partyに開放(Exposure)することです。ここでいう3rd Partyとはモバイルネットワークを用いたサービスの提供企業などをさします。 Network Exposureの代表的なユースケースとしては、QoS(Quality of Service)をAPIとして開放し、3rd PartyはこのAPIを用いることで、モバイル通信の帯域制御や優先制御を3rd Partyの立場から使用可能になるというものです。 例えば、スタジアムにおいてイベント参加者向けにスマートフォンを利用した映像配信サービスを行う場合、通常であればモバイル通信事業者が予め決めた通信帯域しか使えないことに対し、3rd PartyのサービスがQoS APIを用いた帯域制御や優先制御を行い、映像伝送に必要な帯域を確保することで、サービスの利用者としては十分な通信品質で視聴が可能になるというものです。
Network Exposure分野の全体像
現在のNetwork Exposure分野の全体像をモバイル通信の国際業界団体であるGSMAがまとめています。
https://www.gsma.com/solutions-and-impact/technologies/networks/wp-content/uploads/2023/05/The-Ecosystem-for-Open-Gateway-NaaS-API-development.pdfwww.gsma.com
この全体像は関連するステークホルダを全て記載したので大変複雑なのですが、モバイル通信事業者は全ての機能を必須で使う必要はなく、利用する機能を取捨選択できます。注目していただきたいのは図の上部にある「CAMARA」というLinux FoundationのOSSプロジェクトです。この「CAMARA」はGSMAと連携しており、GSMAでは「OpenGateway」においてモバイル事業者共通のAPIとして、「CAMARA」で開発したAPIを規定しています。この「OpenGateway」には2024年時点で全世界で60を超えるモバイル通信事業者が参画しており、弊社も2023年から参画しています。 規定されているAPIも増加しており、使用する3rd Partyも含め、Network Exposure分野におけるエコシステムが拡大しています。
3GPP RNAAとCAPIFの関係性
これまでNetwork Exposure分野の解説をしてきましたが、これからは本題であるRNAAの解説をしていきます。 RNAAの解説に入る前にその元の規格であるCAPIF(Common API Framework for 3GPP northbound APIs)を説明します。 RNAAやCAPIFは3GPPで規格化されましたので、先ほどの「Network Exposure分野における全体像」の下部の「3GPP」の部分の技術となります。 CAPIFとは3GPPで規定するAPIの共通のフレームワークであり、APIの発行、管理、セキュリティ課題の解決などを実施します。3GPPでは4G向けのSCEF、5G向けのNEF等の「Network API」を提供する機能部があり、CAPIFはAPIのライフサイクルマネジメント等を担います。
3GPP RNAAの仕様
RNAAはCAPIFの認可に関わる機能であり，この機能によりCAPIFは保護された情報や帯域等のリソースを保持するリソースオーナに対しリソースの使用のための認可を求めることが実現可能となりました。認可の仕組みとしてはインターネット技術の標準化団体であるIETFで標準化されているOAuth 2.0をベースとしており，Webサービスなどで広く利用されている認可プロトコルをCAPIFに適用することで，さまざまな3rd Partyの事業者や開発者へのニーズに対応し，CAPIFの技術をより広く利用していただくことが可能となります。 RNAAのユースケースの一例として、オンライン対戦ゲームのプレイヤーがゲームの開始前に対戦相手の回線速度を自身の回線速度と同程度にあわせたいと考えた場合，リソースオーナである対戦相手に対しQoS変更による通信帯域の変更を求めるといったことが可能となります。
RNAAの代表的なアーキテクチャを図に記します。
次に、RNAAのシーケンス例を図に記します。
RNAAについて詳しくは、10月に発表したNTTドコモ・テクニカル・ジャーナル「3GPP Release 18における5GCの高度化技術概要―システムアーキテクチャ―」の5章「RNAA」に記載しています。 www.docomo.ne.jp
3GPP RNAA PoC
RNAAは3GPP Release-18(2022年3月から2024年6月での仕様化)で初めて規定された3GPP規格であり、弊社が提案しリードしてきたということもあり、弊社でもPoCを実施し、3rd Partyからの要求に応じて適切な認可を行いQoS変更が期待通りに動作することを確認しました。
RNAAには下記の二通りの方式があり、それぞれのユースケースを見立てて検証しました。
- UE Oriented方式
API呼び出し元であるUEから直接 リソースオーナ機能に対しリソース認可要求を実施する方式。 オンライン対戦ゲームを実施する二人のプレイヤーがいて、UE上のアプリケーションが対戦相手のQoSを変更するためにQoS APIを直接呼び出すユースケースを想定します。API呼び出し元であるプレイヤーのUE上のゲームからのトリガに基づき、対戦相手はリソースオーナとして、リソースオーナ機能を介してAPIの呼び出しを承認します。
- AF(Application Function) Oriented方式
API呼び出し元であるアプリケーションサーバがリソースオーナ機能に対しリソース認可要求を実施する方式。 オンラインゲームのプレイヤーがゲーム・サーバーをトリガし、ゲーム体験を向上させるユースケースを想定します。プレイヤーのUE上のゲーム・アプリケーションからのトリガにより、API呼び出し元として動作するゲーム・サーバはQoS変更のAPI呼び出しを要求し、リソースオーナであるプレイヤーがリソースオーナ機能を介してこのAPI呼び出しを承認します。
まとめ
本記事ではRNAAのご紹介と、それを取り巻くNetwork Exposure分野の解説を実施しました。この分野は変化が早く、新しい情報が次々と発表されます。来年3月に開催されるモバイル業界の国際イベントであるMWC(Mobile World Congress) Barcelona 2025でも大きく扱われる可能性があると考えられますので、ご注目いただければと思います。
