ネットワーク機能をプログラミングする新しいアプリの枠組み– ネットワークAPI –

　KDDIが、通信事業者間で共通のネットワークAPIを利用したアプリ開発を後押しするAdunaへ出資するというニュースがありました。このネットワークAPIとは何でしょうか。これにより、どのようなアプリが実現されるようになるのでしょうか。今回は、このネットワークAPIとはどんなものか、またどのように利用できるようになるのか見ていきます。

スマホのAPIとネットワークAPI

　スマホのアプリは私達誰でも開発することが可能となっています。これは、ディスプレイやマイク、スピーカーなどを操作したり、ボタンが押されたことを検知する基本ソフトウェアの機能がアプリ開発用に開放されているためです。この基本ソフトウェアはOS（Operating System）と呼ばれ、iPhoneのiOSやAndroidスマホのAndroidが代表例です。

　ボタンやディスプレイなどのスマホユーザーとのやりとり、カメラ撮影や音声録音・再生の操作、スマホの持つ位置情報の取得などは、それぞれAPI（Application Programming Interface）と呼ばれるソフトウェアの切り口を通して利用します。アプリの開発のプログラミングにおいて、必要に応じてこのAPIを利用することができます。

　実際のアプリは、App StoreやGoogle Playなどのアプリストアからスマホ上にダウンロードしたプログラムと、クラウドなどにあるサーバー上のプログラムが連携して動作します。サーバー上のプログラムは各種データや決済システムへのアクセスなど、スマホOSのAPIとは異なるさまざまなAPIを利用します。

　ネットワークAPIというのは上記のスマホOSの機能を利用するのと同じように、モバイルネットワークの持つ機能や情報をアプリから利用するための切り口です。

これまでのネットワークAPI

　モバイルネットワークにおいては、従来個々の通信事業者がたとえば、音声通話、SMS、認証など独自のネットワークAPIを提供してきました。これらのAPIは、企業ユーザーなどがさまざまな目的で個別に利用しています。

　TwilioやVonageなどCPaaS（Communication Platform as a Service）プロバイダーと呼ばれる業者が複数の通信事業者のAPIを利用して多様なアプリを開発し、企業などに提供する形態も一般的です。ユーザーは複数の通信事業者ネットワークで同様のアプリを利用できますが、APIは標準化されたものではなく通信事業者ごとにCPaaSプロバイダーが個別対応しています。

ネットワークAPIの標準化

　このようにネットワーク毎に個別に提供されてきたネットワークAPIですが、実は国際間での標準化が進んできており、5Gの進化に伴い、いよいよ広く、本格的に利用できるようになりつつあります。

　モバイルネットワークはスマホと直接無線で接続する基地局からなる無線アクセスネットワーク（RAN: Radio Access Network）と通信パスの設定・開放やユーザー認証などの制御を行うコアネットワーク（CN: Core Network）からなりますが、現状標準化されているネットワークAPIはCNが対象となります。

　ネットワークAPIは4Gでも標準化されているのですが、4Gではスマホなど人が利用するための機能ではなくガスメーターや温度センサー、監視カメラなどIoT（Internet of Things）デバイスに対象が限定されています。

　現在日本の5Gは4Gネットワークに5G基地局を追加する構成で、4GのCNを利用するノンスタンドアローン（NSA: Non-standalone）が主に利用されています。一方で、徐々に大きな割合を占めつつあるのが5Gスタンドアローン（SA: Standalone）で、5Gの進化版として5G　RANと5Gに特化したCNである5G コア（5GC: 5G Core Network）から構成されます。

　5GCでは、IoTだけではなくスマホなど人が利用するための機能も含めてネットワークAPIとして規定しています。標準化の中では、APIを通してネットワーク機能を開放する仕組みを特にネットワークエクスポージャー（Network Exposure）と呼んでいます。

　ネットワークAPIの利用が本格化すると、図1に示すようにスマホのiOSやAndroid上のAPI、クラウド上のアプリケーションサーバが利用する決済システムやデータベースなどとの間のAPIに対して、言わば「モバイルアプリにおける第三のAPI」として利用されるようになります。

この第三のAPIを利用することにより、これまでとは異なるより多様で有益なアプリが通信事業者間や国際間にまたがり、広く実現できる可能性があります。

5GのネットワークAPI

　図2に示すように、5GCではその構成要素が機能・役割ごとにNetwork Function（NF）として規定されています。たとえばAMF（Access and Mobility Management Function）は、各エリアに移動してきた端末の登録（在圏の通知）や無線接続の管理を行います。SMF（Session Management Function）は、アプリの利用するデータ通信パスの設定や開放を行います。

　UDM（Unified Data Management）は、各ユーザーの加入契約情報やスマホ認証情報、スマホの在圏位置情報を保持します。PCF（Policy Control Function）は各アプリからの要件に基づき、利用するデータ通信パスの速度や遅延時間などの品質を設定します。

　以上はユーザーの移動を検知したり通信を制御するための「制御」用NFですが、ユーザーが利用するアプリのデータをモバイルネットワークの中、そしてアプリサーバーなどにルーティングするUPF（User Plane Function）というNFもあります。
User Planeというのはユーザーのデータが送られる「面」という意味です。

　一方で、上記の制御用NFが制御信号を送る「面」をControl Planeと呼び、5GCではこれら2つの面が明確に分離されています。

　制御用NFの一つがネットワークエクスポージャーの役割を果すNEF（Network Exposure Function）です。異なる制御用NF同士はSBI（Service-Based Interface）と呼ばれる（インターネットの）ウェブアクセス技術をベースにした内部通信を行いますが、NEFもSBIを通してほかのNFとやりとりします。

　図2に、AMF、SMF、UDM、PCFなどの機能をNEFを介して外部サーバーにAPIとして提供する仕組みも示します。セキュリティ関連など一部の機能を除いて、Control Planeの多くのNFの機能がNEFを介してAPIとして開放されます。User Plane、つまりUPFの機能は直接は開放されません。

　モバイルネットワーク関連の標準化を行っている3GPP（3rd Generation Partnership Project）では、NEFが提供可能なAPIとしてさまざまな種類合わせて数百個定義しています。各通信事業者にはこれら全てを実装することが求められている訳ではなく、ネットワーク設計や市場ニーズに基づいて実装します。

GSMA Open Gateway

　ネットワークAPIを利用するアプリ開発者の立場からすると、個々の通信事業者の提供するAPIを利用してその事業者のネットワークでしか使えないアプリを開発するよりも、できるだけ多くの事業者に共通で使えるアプリを開発するほうがより多くのユーザーに使ってもらえ、より多くの収益を得られる可能性があります。

　そのような観点から生まれたのが、世界のモバイル通信事業者の業界団体であるGSMA（GSM Association）のOpen Gatewayイニシアティブです。Open Gatewayには、世界の50社以上の通信事業者が参画しており、日本からもKDDI、ソフトバンク、NTTドコモが名を連ねています。

　Open Gatewayの取り組みでは3GPP NEF APIをベースに、新たなアプリの創出を促し通信事業者の収益に貢献しそうなものを選択し、アプリとして利用し易いように簡便化したり複数のNEF APIを組み合わすなどにより使い勝手を良くしています。

　現在、Open Gatewayでは27個の実績があるとされるAPIが規定されていますが、市場ニーズに基づき新たなAPIが追加されたり、役割が重複しているため削除されるなど、時間とともにこの数は変化しています。

　上の表1に、Open Gatewayの代表的なAPIの名称とその主な役割を示します。以下、少し込み入りますが幾つかのAPIについて見てみましょう。

CAMARAによるオープンソース

　Open GatewayのAPIは、すぐに市場で利用が可能なように「CAMARA」と呼ばれるLinux Foundationが運営するオープンソースプロジェクトで、通信事業者間で共通に利用できるAPIプログラムの開発を推進し、実装まで含めた標準化を進めています。つまり、オープンソースとして公開し、アプリの開発のために誰でも利用できるようにしています。

　CAMARAのオープンソースにより、複雑なネットワーク機能を理解することなく直感的でシンプルなコードを使うだけ（いわゆるLow Code）で5GCのAPIを容易に利用することが可能になります。アプリ開発のハードルが低くなることで、ネットワークAPIがより幅広い開発者に利用してもらえ、多くの有益なアプリが市場に出てくることが期待されます。

　さて、Open GatewayのAPIは実際には5GCだけではなく、通信事業者の運用支援システム（OSS: Operational Support System）やビジネス支援システム（BSS: Business Support System）の機能も活用することが前提で規定されています。OSSはネットワークの監視、障害管理、性能管理などを担い、BSSは課金、請求、顧客管理、契約管理などを担っています。

　OSSでは通信事業者ごとに運用プロセスや使用しているツールが異なり、またBSSでは課金や顧客管理の仕方がビジネスモデルに依存することから、統一的なAPIの提供の障害となります。しかし、CAMARAを通したオープンソースの公開、標準化により、各事業者がミドルウェアなどを介してOpen GatewayのAPIを提供することが可能となります。

ネットワークAPIのユースケース

　それでは、これらのAPIは具体的にどのように利用するのでしょうか。具体的な事例を見てみましょう。

　図3に海上に設置された風力発電機を、5G通信モジュールを搭載したカメラ付き自動飛行ドローンで検査するユースケースを示します。ドローンは運用者による遠隔操作も可能とします。ドローンアプリとドローンの間には、ドローン操作用とビデオ送信用で異なる2つの接続が設定されています。

　ここでは、ドローンが特定のエリア（ジオフェンス内）に進入するとGeofencing Subscriptions APIにより、アプリにそれが知らされるようにプログラムしておきます。

　実際の流れとしては、まず最初にドローン操作用接続を使ってアプリからドローンに飛行ルートと目的地のデータを送り、自動運転による離陸を指令します。ドローンが海岸から飛び立ち海上の風力発電機に近いジオフェンス内に進入すると、Geofencing Subscriptions APIを介してアプリに検査準備完了と知らせます。

　アプリはドローンにカメラのビデオ接続を高精細モードに切り替えるよう指示すると同時に、QoD APIを介して5GCにカメラのビデオ接続を高速・高信頼品質に設定するように要求します。また、ドローンを自動飛行から運用者による遠隔操作による飛行に切り替えると同時に、QoD APIを介して5GCにドローン操作用接続を高信頼・低遅延品質に設定するように要求します。

　このユースケースは5GCの機能を利用するAPIのみを使っていますが、実際のネットワークにおいてはオンライン詐欺やサイバー犯罪防止のためのアプリなど、BSSやOSSの機能を利用するアプリから市場に投入されていく可能性があります。

APIアグリゲーター

　本記事冒頭でKDDIがAdunaに出資するというニュースについて触れました。このAdunaというのはOpen Gatewayで規定するネットワークAPIの実装を推進するために、エリクソンと世界の通信事業者12社によって設立されましたが、そこにKDDIも出資して参画するということです。Adunaに参画する通信事業者は全てOpen Gatewayのメンバーです。

　Open Gateway APIはCAMARAプロジェクトによってオープンソースとして公開されますが、それでも各通信事業者が独自に実装すると、利用の仕方や機能にばらつきが生じる可能性があります。それに対処するため、Adunaはグローバルな共通APIの実装と提供を推進することになると想定されます。

　統一された実装レベルのネットワークAPIを通じて、アプリ開発者やサービスプロバイダーが各事業者間の違いを意識することなく、ネットワーク機能を活用できる環境が整備されます。また、この共通の土台の上でVonageやGoogle CloudなどのCPaaSプロバイダーも異なる事業者に共通のアプリを提供することが可能となります。

　つまり、AdunaというネットワークAPIアグリゲーターの下にAPIエコシステムができることになります。これに参画する通信事業者の間では同じアプリが利用できるということになり、サービスプロバイダーにとって大きな市場が形成されるという訳です。

　スマホのアプリについては、iOSやAndroid向けのアプリストアが世界の通信事業者に共通に設けられていますが、APIアグリゲーターはネットワークAPIについて同じような仕組みを作っていこうというということだと考えられます。

　長期的にはAPIアグリゲーターは1社ということではなく、複数のアグリゲーターが競争しながら市場が大きくなっていくと想定されます。実際、たとえばノキアはNetwork as CodeというネットワークAPI上アプリの開発環境を通してAPIアグリゲーターの役割を担うという意向のようです。

　通信事業者の立場からすると、ネットワークAPIをなるだけ広く利用してもらうことにより収益の機会を増やそうとすると思われます。そういう意味では、図4に示すように通信事業者は複数のAPIアグリゲーターを通してアプリ開発者と連携するというのも現実的なアプローチかも知れません。

　また、ネットワークAPIのソフトウェアをとりそろえ、アプリ開発者に提供するAPIマーケットプレースのようなプラットフォームができることにより、アプリ開発者による開発が促進されることも期待されます。

なお、APIアグリゲーターは通信事業者と協力してOpen Gatewayで規定していない独自のAPIを設け、ほかのアグリゲーターとの差別化を図るようにして競争する可能性もあります。

おわりに

　ビジネス的には、通信事業者はAPIの利用回数や時間などにより使用料を課金し、サービスプロバイダーから直接あるいはAPIアグリゲーターを介して収益を得るモデルになると考えられます。

　そうすると、サービスプロバイダーとAPIアグリゲーター、通信事業者との間での取り決め、課金や料金請求の仕組みなどが必要となりますが、そのような仕組みまで含めてネットワークAPIが本格的に大きな収益につながるビジネスとなるまでには少し時間が掛かりそうです。

　5Gが商用化されて約5年になりますが、あまり5Gらしいサービスが提供されていないと言われています。5Gスタンドアローン（SA）のサービスエリアが広がり5G特有の機能が利用できるようになると同時に、ネットワークAPIがさまざまなアプリで利用されるようになれば、5Gらしいサービスがどんどん提供されるようになると期待されます。