基盤技術の進化から見る5GCの標準化動向 Service Based Architecture採用のメリットと3つの事例

自己紹介

石川寛氏（以下、石川）：それでは「Service Based Architectureを採用する5GCの標準化動向」ということで、石川寛のほうからご説明したいと思います。よろしくお願いします。

まずは、本日の資料の構成になります。最初に、3GPP（3rd Generation Partnership Project）で策定した5GC（5th Generation Core network）システムの技術仕様について紹介します。そのあと、5GCで採用されるService Based Architectureとはどういうものかを簡単に説明します。そのあとに、事例紹介として、標準化で追加された拡張機能ついて少し説明します。

初めに自己紹介します。石川寛と言います。NTTドコモのネットワーク開発部に勤めています。ネットワーク開発部というのは、コアネットワークに関する開発を中心に行っていますが、その中で私の業務としては、コアネットワークの標準化活動を行っています。

現在は、3GPPのCTワーキンググループと、GSMA（Global System for Mobile Communications）の活動を行っております。特に、3GPPのCT4というところでは、2021年4月から副議長をやらせていただいています。

3GPPで策定した5Gシステムの技術仕様

では最初に、3GPPで策定した5Gシステムの技術仕様について紹介します。

その前にまず3GPPが何かと言うと、こちら、3rdGeneration Partnership Projectというものになります。移動体通信仕様を策定している団体ですが、名前から察するとおり、3Gの世代に作成されたものです。

欧米、アジアに各地域の標準化団体がありますが、これらの団体で「共通した移動体通信の仕様を作ったほうがいいね」ということが3Gの時代に話され、その結果、「Partnership Projectを作って、共通仕様を作っていこう」と。そのためにできた組織が、3GPPというものになります。

3GPPは、大きく3つのグループから構成されています。RAN、CT、SAというグループです。RANについては、基本的に無線系の仕様を作成しています。（スライドを指して）右側のSAと書いてあるところがありますが、こちらはサービス要求条件であったり、システムアーキテクチャの全体像を描いたりします。

真ん中にあるCTは、コアネットワークおよび端末におけるプロトコル仕様などを中心に作っているグループです。

先ほどCT4というグループの副議長をしていると言いましたが、こちらでは、コアネットワーク間のプロトコルを中心に規定しております。

3GPPにおける技術書の進化

3GPPでは、3Gから始まり、現在の4G、5Gまでつながる世代の変化に応じて、各世代のシステムを標準化してきました。

10年スパンで大きく作成されていますが、その間にも、数年スパンで規定されるリリースがあります。こちらに各種要求条件を取り込んで、いろいろな仕様が拡張してきている、向上してきています。

例えば、現在VoLTEで使われているIMS（Internet protocol Multimedia Subsystem）という基盤がありますが、こちらも、広く使われるようになったのは4G世代ですが、3Gの時代のリリース5のタイミングで3GPPに規定されたものです。

こういったかたちで、各リリースの中でいろいろなものが規定されて、それらが拡張、エンハンスされていくような流れで作られています。

システムで動作する基盤技術の進化

このような3GPPにおける技術書の進化とは別に、システムで動作する基盤技術も進化してきております。

3Gの時代では専用ハードウェアを使っていましたが、汎用サーバー化していくことが行われました。4Gの世代になると、さらに仮想化技術を導入することも行われてきています。

ただ、5Gに関しては少し違った毛色があります。こちらでは「クラウド系技術を導入していこうね」ということが標準仕様を策定する段階で早くから言われ、クラウド系技術を導入した標準仕様が作られてきました。

Service Based Architectureについて

では次に、5GCで採用されたService Based Architectureについて紹介したいと思います。5GCでは、Control Plane、User Planeの分離、制御信号とユーザーデータのパスを分離するところから行われています。これ自体は4G以前でもやっていましたが、5Gでは完全に分離した仕様が作成されています。

その上で、Control Planeに関してはService Based化を行いました。Service Based化というものがどういったことを言ってるかというと、わかりやすくするために、4Gと5Gの2つのアーキテクチャの比較を持ってきました。

（スライドを指して）左側に紹介している4GのアーキテクチャはP2P（Point-to-Point）のアーキテクチャになります。各装置が線で結ばれていて、各インターフェイスに、番号とインターフェイス名が与えられています。このインターフェイスごとに能力を規定していくということで、標準仕様が作成されています。

一方でService Basedに関して言うと、（スライドを指して）ピンク色の部分がService Based化されたところですが、これは真ん中にバスと呼ばれるものがあります。そのバスに対して、各装置のAPIがつながっていることになります。そのAPIの能力を規定していくということで、標準仕様が作成される。こちらがService Based Architectureです。

こういった変化があるというのが、この5Gにおける仕様化になります。

Service Based Architectureを採用するメリット

では「Service Based Architectureを採用するメリットってなんなの？」ということになります。いろいろあるかとは思いますが、一言で言うのであれば、ネットワークリソースを柔軟に確保できることになると思います。つまり、需要に応じてスケールさせることが可能だということです。

では具体的にどうやってそれやっているのかというと、みなさんからいろいろな意見があるかと思いますが、この場では3つに集約しました。

1つが、Network Functionで提供するインスタンスを柔軟に生成できること。2つ目に、Network Functionの処理を行うところと状態を保持する部分の機能の分離を行い、柔軟性を確保していることです。3つ目に、（Service Based Architectureでは）NRF（Network Repository Function）という装置を規定していますが、これによるNFの一括管理を行うということがあります。

この3つで、Service Based化をする、そして需要に応じてスケールさせることを実現していると考えます。

ネットワークインスタンスを柔軟に作成できるとは

「ネットワークインスタンスを柔軟に作成できるってどういうこと？」という話になります。こちらは図で紹介していきたいと思います。

（スライドを指して）左側で紹介しているような例です。NF Consumerがクライアントになります。それが、NF Producerサーバーのサービスを使いたい。NFサービスをコンシュームしたいというような事例があったとします。

たくさんあるNF Consumerは、NF ProducerのあるInstanceを選んで通信をすることになります。この例では、2つのInstanceと通信しています。ただ、どんどんConsumerが増えていくと、これらの2つのInstanceではだんだん処理がしきれなくなってきて、負荷が増大していきます。新たなNF Consumerとの通信は、大変になってくるというのがある例です。

こういった場合には3つ目のInstanceを作ればいいということで、右側の図で示しているような、新たなInstanceをNF Producer内に生成します。これによって、新たなNF Consumerは、新しいInstanceと通信すればいいし、既存のConsumerも新しいInstanceに切り替えて通信していけばいい。

Instanceを作ることで、Instanceの負荷を軽減でき、サーバー側がNF Producer側全体の処理負荷を軽減できます。

次に、NF処理部と状態保持するところを分解するということです。こちらは何を言っているかというと、先ほども紹介したNF Producerが、あるInstanceで通信していますが、その状態というのは、実はUDSF（Unstructured Data Storage Function）に状態を保存するということで、Instance側で何も保持しなくてもいいような設計になっています。

（スライドを指して）こういうことを行うと、左側で映しているような例で、Instance AでNF Producerの処理をしてたところが、右側のように、仮にInstance Bでの処理に変わったとする。

Instance Bで処理するように変わったとしても、UDSFに格納している状態は変わらないので、サービス全体は継続できると、NF Consumer側からすると通信している相手が変わっているので、もちろんIP通信上のなんらかの変更は生じますが、全体で見ると処理が継続できる設計になります。

ただ、やみくもに代替できると言っても、それだけでは処理はややこしくなってきます。

そのために、5GCに導入する際には、各APIで目的や用途ごとのトランザクションを整理した経緯があります。

その比較のために、2つの位置登録の手順を示しています。（スライドを指して）左側がEPC（Evolved Packet Core）、4Gの世代の位置登録の手順。右側が5GCにおける位置登録の手順の紹介をしています。

これらはコアネットワークのところにフォーカスしているので、一部抜粋したかたちで紹介しています。左側のEPCの例だと、在圏交換機であるMME（Mobility Management Entity）が、HSS（Home Subscriber Server）という加入者データベースであり、状態を格納するところがあります。

こちらに位置登録をする際には、1つのトランザクションでいろいろなことを行います。具体的には、3つの処理を行います。位置登録をする。加入者データベースを取ってくる。それから、変更があった場合に何か通知する。この3つの要項を1つのトランザクションでまとめて行っています。当然、信号数が削減できて非常に効率的です。

これに対して、5Gコアでは「用途が3つあるのであれば、3つで規定しましょう」と。仮に1つの処理、Instanceが落ちたとしても、ほかのものでやっているので、1つだけやり直せばいいということで、それぞれ明確になっています。

コールフロー上のトランザクションは増えますが、処理を分けていることで、設計が簡素化できるメリットがあります。

次に、NRFによるNFの管理があります。NFのInstanceを一括管理しているのがNRFになりますが、基本的には3つのことをやっています。

まずサービスを提供するNFであるNF Producerが、自身のNFをほかの人に「使ってね」ということで、NRFに登録しておきます。発見してもらうために登録しますが、“登録する”という行為になります。

それから2つ目。今度は逆にNF Consumer側が「こういったNF Producerを探しているので、使いたいんですけど」ということで、「特定のNF Instanceはありますか」と問い合わせにいきます。NRFは、その問い合わせに対する回答を行う。NF Discoveryというものを行うのが1つの用途になります。

NF Producerについては、ずっとサービスが立ち上がっているわけではなく、なんらかの状態変更、例えばあるタイミングで「サービスを停止しますよ」といったこと。あるいは「負荷が上がってきているから、もし可能だったらほかのNFを選択してくださいね」といった負荷情報を通知するとか、いろいろなことができます。このような、情報を通知する役割も果たします。

情報を通知するにあたっては、各NF InstanceがNF Managementで登録し、他のNFが発見する。発見する時に「Subscribeして情報通知をしてくださいね」ということを要求しておく。それを利用して、必要な時にNRFは通知する。やることはたくさんありますが、NRF自身がこういったAPIを提供することによって、NF構成の変化に柔軟に対応できます。

これで、システム全体のフレキシビリティを確保できているというものになります。

拡張機能事例1：NFの通信処理の負荷軽減

こういった、基本的な仕様ができてきました。5Gで要求される各種サービスや機能を追加するために、いろいろなものも追加されていますが、では5GC、Service Based Architectureの基本的な部分はもうすでに仕様化が終わっているのかというと実はそうでもなくて、いろいろ機能拡張が行われています。

この場では、どういう拡張がなされてきたかを、一部事例として紹介したいと思います。ここでは3つほど述べますが、実際にはもっとたくさんあるので、興味のある方は3GPPの検討状況を見てもらえればと思います。

まず1つは、NFの通信処理の負荷を軽減するということです。最初に5GCを作った時には、各NFはEnd-to-Endで通信するという前提でした。そのため、真ん中にプロキシのようなものを置いて、何か処理を行うことは想定していませんでした。

しかし、2つ目の世代のリリース16を規定する際に、「サービスメッシュなどを取り入れる場合に、このままでいいんだろうか」と。「特に、NFの通信処理とアプリケーションの処理は分離したほうがいいんではないか」といったような議論が行われました。

そのために、SCP（Service Communication Proxy）を導入して、NFの通信処理を簡素化できないかということが議論されてきました。もちろん簡素化したほうがいいとは思いますが、「じゃあ、どう簡素化するの」というところで、けっこう揉めました。

揉めた結果、2つの仕様が作成されてます。スライドの下のほうに表示している例が、2つできたものになります。左側のモデルCとされるもの。こちらについては、NF Consumerにおける、NRFに対するDiscovery自身は、引き続きNF Consumer自身が行います。

ただ、「どこを通って」という信号のルーティングを中心に、「これはSCPに任せる」といったようなことをする仕組みが1つできました。

それに対して、右側のモデルDで表示しているものは、Discovery自身もSCPに任せたいというとこで、「どういう条件のものをDiscoverしたいんです」といった必要なパラメーターもSCPに送って、「あとは適当にやっといて」というような仕組みの2つが作成されました。

さらにTLS（Transport Layer Security）の通信を必要とするかなど、いろいろ細かい違いはありますが、こういった基本的な概念を行うことで、NF Consumerにおける通信処理の負荷を軽減する拡張がなされています。

拡張機能事例2：相互接続の際の処理軽減

2つ目は、SEPP（Security Edge Protection Proxy）。各事業者でローミングを行う際、相互接続する時に、ファイアウォール的な装置を置く必要があります。この処理を軽減するための検討が行われました。

先ほどSCPを紹介しましたが、SCPの時に、NF間とNFとSCPの間でTLS通信をしてしまうと、HTTPの信号では、AuthorityヘッダにSCPと宛先の両方入れないと最終的なところに通信できないものの、どうやって入れたらいいかがわからない。わからないというかできないということで、3GPPのカスタムヘッダである3gpp-Sbi-Target-apiRootヘッダというものが導入されました。

この仕組みは、実はSEPPにおける通信にもヒントになるということで、結果的に採用されました。

最初のSEPPにともなう通信では、Telescopic URIというものを使っていました。（スライドを指して）左下におけるような通信のモデルになっていて、真ん中の装置のSEPPがTelescopic URIで、代替のURIを払い出しています。

これと本来の宛先の対応関係を管理していて、各装置はそのTelescopic URIを使って変換していくかたちで通信をしていました。

ただ、こうするとMapping Tableを誰かが保持していかなきゃいけない。1つぐらいならいいですが、実際にはもっと多数のユーザーが多数の装置と通信するので、たくさんのMapping Tableが必要になります。いつ要らなくなるかもよくわからないので、このMapping Tableの管理は非現実的だということが言われていました。

先ほども紹介した、「このSCPの時に導入する」というカスタムヘッダを使えば、右側のモデルになるように、SEPPでは特にMapping Tableの管理をしなくてよく、AuthorityヘッダでSEPP宛にして、本来の宛先をTarget-apiRootヘッダ、カスタムヘッダで通知することで、問題なく通信できるというような処理がありました。

リリース16では両方使えますが、おそらく新しい方式を採用する事業者がほとんどになるかなと思います。こういった拡張がされました。

拡張機能事例3：格納プロファイルが破損した場合の復旧方法

事例3としては、格納プロファイルが破損した場合の復旧方法です。UDR（Unified Data Repository）という装置があり、加入者のデータベースや状態を登録するところです。こちらは、UDM（Unified Data Management）というフロントエンド装置のバックエンドです。

このバックエンドの装置がほかの装置と通信できなくなると、非常に困ります。この復旧際に生じる各NFの状態とのミスマッチを解消する方法が、現在は仕様にありません。「これは必要なんだっけ、必要じゃないんだっけ」という賛成派と反対派の意見がいろいろあります。

揉めてしまうのでどうするかというと、結局はStudy itemという、Feasibility Studyを行う検討を行い、どういう仕様を作っていけばいいという議論がされるかたちになりました。これは現在もオンゴーイングなので、また何か決まったら、なにかの場で紹介できればと思います。

以上が、私のプレゼンテーションとなります。テレコムの業界は、もともと専用ハードを作ったり、専用の技術を使ってきましたが、5Gになるにしたがって、IT系の技術を導入し、かつ、汎用的な装置などを使ってきています。

今後汎用的にテレコムの世界でもクラウド系の技術も使っていくと思うので、ここにいるみなさま方と、いろいろディスカッションさせていただいて、さらに発展できればいいかなと思っています。

以上です。ご清聴いただきありがとうございました。