6Gでも注目されるRestoration (復旧) とは？3GPP会合CT4#131参加レポート

はじめまして。ドコモ 6Gテック部の本田と申します。

移動通信業界において6Gに関する検討が本格化する中で、ついにCT領域においても10月より6Gの議論が開始されました。その中でも今回は、私が参加したCT4#131会合、およびそこで議論されていたテーマの一つであるRestoration (復旧) に関してレポートいたします。

会場紹介: ETSIとソフィア・アンティポリス
CT4の役割と位置づけ
ネットワークを支えるRestoration (復旧) とは
6G時代のResilience/Restoration検討動向
おわりに
参考文献

会場紹介: ETSIとソフィア・アンティポリス

今回の会場となったETSI (European Telecommunications Standards Institute) は欧州を代表する通信関連の標準化団体であり、通信技術の国際的な標準策定において中心的な役割を果たしています。 ETSI本部のあるソフィア・アンティポリスはフランス南部の町で、フランス・ニースのコート・ダジュール空港からバスで約40分の場所に位置する、欧州初のサイエンス・テクノパークです *1。日系企業を含む多くのテクノロジー系企業や学校が進出しており、ヨーロッパのイノベーション拠点でありながら自然が多く非常に過ごしやすい環境でした。日本でいうと筑波研究学園都市や我々6Gテック部の拠点があるYRP (横須賀リサーチパーク) に近い雰囲気かもしれません。

CT4の役割と位置づけ

3GPPにおけるCT4の役割を簡単に説明すると、モバイルコアネットワーク内のノード間インターフェースで用いる通信プロトコル (5GにおけるHTTP/2、4GにおけるDiameterなど) およびその周辺機能の詳細仕様を策定・維持する担当グループです。詳細は過去のブログ記事にて紹介されていましたので本記事での説明は割愛いたします。詳しくはこちらの記事*3 をご参照ください。

ネットワークを支えるRestoration (復旧) とは

上記の記事で紹介されていなかったCT4の扱う要素にRestorationがあり、6G議論の中でも重要なトピックの一つとなっています。

モバイルコアネットワークの各ノードは、サーバー上で動作しており、運用を続けている中で何らかの理由で突然停止してしまうことがあり得ます。サービスダウンの原因としては設備の故障だけでなく地震などの天災、サーバーのCPU/メモリやネットワークの高負荷、外部からの攻撃やその他想定外の事象など多岐にわたります。サーバールームを頑丈に作る、高額な設備を使う、Virtualized Network Function (VNF) やCloud-native Network Function (CNF) として仮想化・コンテナ化するなど、さまざまな対策を行っていますが100%壊れない装置は現状存在しません。特に日本は世界的に見ても地震が多い国であり、ドコモもオペレーターとして常に警戒しなければいけない事象となっています。

もし運用中のノードが停止してしまった場合、ちょうどその瞬間に通信を行っていた加入者データはどうなるのでしょうか？処理内容やタイミングによっては何も影響が出ずに処理が継続できるかもしれませんし、端末 (UE) もしくは周辺ノードが処理をやり直すことによって正常な通信フローに戻ることもあり得ます。そういったネットワーク内部での救済ができず、「データの書き換え中に落ちてしまったので、どこまで書き込んでいたかわからなくなってしまいデータが壊れてしまった」というような、回線を契約いただいているお客さまに対して影響が出てしまうケースというのが最悪のシナリオです。

いかにしてそういった最悪の事態を避けるのか、そして万が一起きてしまった場合にどのように復旧させるのかというのがRestorationの重要なテーマです。この辺りは製品を開発するベンダーだけでなく実際に運用するオペレーターの知見が非常に大きく、ドコモとしても3G/4Gの時代から現在の5Gまで継続して注力している領域となります。一見して地味な話に見えますが、個人的には最も移動通信会社の手腕が問われる分野の一つだと考えています。

(CT4で扱えるのはあくまでプロトコルやパラメーター関連となるため、復旧のために新しいサービスを構築しよう！というような提案はSA2という別グループの案件となるので少々ややこしいところではあります。)

HSS Reset-Requestの処理内容のイメージ (一部簡略化しています)

6G以前のRestorationの例として、4GにおけるHSS (Home Subscriber Server) のReset-Requestを紹介します*4。4Gネットワークにおいて、HSSは加入者データと登録状態を保管するデータベースで、MME (Mobility Management Entity)/SGSN (Serving GPRS Support Node) はその情報を用いて接続・位置管理などの制御を行います。このHSSが運用中に再起動したり、何らかの理由でHSS内の加入者データとMME/SGSN内のデータが食い違ってしまったりしたときに、HSSからMME/SGSNに対して「その加入者たちの覚えている情報を一旦クリアして、改めてHSSから取り直して！」と知らせる仕組みです。この機能が標準化されるまではHSSとMME/SGSNのデータを整合させるために全加入者に個別処理を行う必要があったところをReset-Requestにて一括で実施できるようになったため、全加入者への確実な対応やオペレーション負荷の低減による回線復旧時間の短縮につながりました。

6G時代のResilience/Restoration検討動向

今回のCT4#131会合よりCT4においても6Gに関する議論が開始され、今後どのようなトピックを中心に検討を進めていくかという方針も論点となりました。各社からさまざまな意見が挙がり会合中に結論には至りませんでしたが、暫定的な検討項目として6GにおけるControl Plane/User Planeのプロトコルに加えてResilience (耐障害性・復元力) というテーマも取り上げられました。Resilienceはネットワーク全体に影響のあるトピックです。CT4領域としては、そのResilienceを構成する一要素 (復旧手順・状態回復など) であるRestorationを扱っていくことになります。

今回の会合時点における各社からのResilience関連提案として、既存手順の適用性検討や自動化・異常系の切り離しなどの方向性が提示されていました。内容に関して合意までは至っておらず具体的な提案に関しては割愛しますが、6Gコアシステムに対して既存の手順が使えるかといった基礎的な部分のほか、6G時代の新しいRestoration手段を模索する動きもあり、各社とも注目しているトピックであることがうかがえます。今回の会合はあくまで今後議論を行うテーマの選定という部分が大きくソリューションなど各提案の詳細はこれから出てくることになります。

おわりに

会場で配布されていたETSIロゴ入りボトル
会場周辺にお店が少ない中でこのボトルに何人もの参加者の喉が救われました

私は今年 (2025年) 7月から標準化業務を担当することになり、今回がはじめての3GPP会合参加でした。これまでも5Gや4G/3Gのネットワーク業務に携わっていたため今回取り上げたRestorationも現場レベルで知るところではあったのですが、標準化においてはまた異なる視点から仕様を突き詰めていくということを体感し、大変勉強になりました。今後、Restorationだけでなくほかの6G関連のトピックも議論が活性化していくことになりますので、ドコモとしても積極的に提案を行い課題解決に取組んでいく所存です。

今後の6G議論の動向に関しても本ブログ内でお伝えしていく予定です。