こんにちは。ドコモ6Gテック部の巳之口 淳（みのくち あつし）です。 2025年11月17日～21日に米国・ダラスで開催された3GPP SA2#172会合に参加しました。 本記事では、会合の結果、特に、6Gアーキテクチャで議論されたKey issue(=検討課題）をご紹介します。
今回の内容は、10月の武漢会合レポートの続編です。過去の記事はこちらの開発者ブログでご確認ください。
※本記事は2025年末の現在の状況と個人の見解を反映したものであり、将来の展開を保証するものではありません。
SA2#172会合概要
今回の会合では、6Gネットワークアーキテクチャに関する、アーキテクチャの仮定と要求条件、および、Key issue(=検討課題）を確定しました。次回の会合から、個々のKey issueに対し、各社がSolution提案を持ち込みます。つまり、アーキテクチャの仮定と要求条件が"従うべき前提条件"で、Key issueが”問題”であり、Solutionが”答え”という位置づけです。今回の会合の結果は、TR 23.801-01*1という文書にまとめられており、誰でも見ることができます。アーキテクチャの仮定と要求条件は4章、Key issueは5章に記載があります。本記事では、いくつかの注目すべき事項を抜粋してご紹介いたします。
6Gの新領域に関わるKey issue
まず、6Gらしい新領域をご紹介いたします。
6GのためのAI(KI#18):
5Gのコアネットワークでは、AIは追加機能として扱われておりました。6Gでは、当初からAIを導入する予定です。
6G時代の新しい試みとして、端末や外部アプリがインテントを送信し、AIがそれを解釈して処理を進める仕組みも検討します。ここでインテントを送信するとは、結果への”期待”を示すことをさします。従来は、要求元から要求先へ実行方法を逐一指示しておりましたが、要求元はサービスや処理の期待を示し、要求先にて、必要な実行方法を判断し、実行します。ここにAIが使われることが期待されています。インテントの表現にどの程度の自由度を持たせるかも、今後検討します。
また、AIが、臨機応変に複数の要素手順を組み合わせて、サービスや処理を完遂するための全体の手順を構成することも検討します。これに関しては、要素手順そのものをどう設計すれば良いかも検討します。なお、AIに関する学習機能、監視機能も導入します。AIのための6G(KI#19):
端末や外部アプリにあるAIエージェントが互いに通信するためのサポート機能を検討します。また、コアネットワークのネットワーク機能がもつAIが、前記のAIエージェントにAIサービスを提供する機能も検討します。
ここで、AIエージェントは現時点で「ユーザー/システム/アプリケーションに代わってタスクを自律的に実行するエージェントの一般的な概念をさす」とだけしており、ユースケースや要求条件を扱う検討グループである、SA1が用語を詳細定義することを待っている状況です。AIエージェントにつきましては、こちらの開発者ブログもご確認ください。 nttdocomo-developers.jpセンシングと通信の統合(KI#20):
端末や基地局がセンシングを行う機能を検討します。6Gのユースケースを集めたTR 22.870*2に記載があるように、ドローンの監視、ドローンによるセンシング、ロボット間の相互センシング、スマートシティ/トランスポートで必要となるセンシング、災害時復旧や歩行者安全確保のサポートなど、多様なユースケースに対応します。
なお、プライバシ問題には、セキュリティを扱う検討グループである、SA3と連携して取組みます。データフレームワーク(KI#21):
AIやセンシングに関わるデータの取得/伝送/処理/格納を統一的に扱う基盤を整備します。6Gでは、端末からのデータ収集(端末が用いるAIモデルの訓練データの端末からの収集、端末がセンシングしたデータの収集)も広く扱います。5Gでも関連の機能が既に導入されていますから、それとの差分を確認しながら検討を進める予定です。コンピューティング(KI#22):
ネットワークがコンピューティングリソースを提供し、端末の処理を助ける機能です。通信リソースとコンピューティングリソースの最適な割り当て手法を検討します。端末移動時、あるいは、コンピューティングリソース移動時の、サービスの継続も検討します。なお、関連するドコモ内での取組みについては、下記のリンクもご参照下さい。 www.docomo.ne.jp
通信サービスに関わるKey issue
5Gから存在する通信サービスは、KI#1~17, 23~24にて議論されます。音声、緊急呼(例,119等の緊急電話）などのKey issueでは、5Gネットワークが議論の出発点とされています。
6G導入時にも場所によっては4G、5Gのネットワークが使われ続けることが予想されるため、6Gと4Gや5Gが共存する場合の考慮も必要です。KI#12, #13、#17にて、6Gと5Gの間に加えて、 6Gと4Gの間のインターワーク(異なるネットワークへの移動や切替）も検討します。
Key issueに関わる残課題
ここまで述べたKey issueでカバーされていない、既存の仕組みがいくつかあります。これらのうちの何をどう6Gで残すのかに関し、今回の会合前に、SA2参加各社にアンケートが実施され、今回の会合で、その結果が紹介されました。この部分に関しては、今後、どうスタディで取り扱っていくか、検討を継続する予定です。
アーキテクチャ仮定と要求条件
ここまで、Key issueを説明してきました。今後のSolutionの検討では、以下の前提も考慮する必要があります。
6G CN:
上記のTR 23.801-01の3章に、5G時代の5Gコアネットワーク（すなわち5GC）に相当する6G時代の6Gコアネットワークを意味する言葉として、”6G CN”という用語を定義しました。そこに、“6G CN がどの程度 5GC の進化形とみなされるか、または、新しいコアネットワークとみなされるかはスタディで検討する”、という記載があります。SBAとIMS:
上記のTR 23.801-01の4章に、アーキテクチャの仮定として、“議論の出発点として、5GCで規定された SBA のフレームワークを想定する”、”音声およびビデオ サービスは、IMSによって提供される”、という記載があります。
ここで、SBAですが、Service Based Architectureと呼ばれる、5Gで導入した、プロトコルとしてHTTPを用いる各ネットワークノードがAPIを介して連携するアーキテクチャをさします。IMSは、4Gで導入した、プロトコルとしてSIPを用いる音声やビデオなどのためのサブシステムをさします。
おわりに
ごくおおざっぱでしたが、3GPP SA2における6G議論の最新の結果をご紹介しました。 ドコモは、引き続き、世界中の技術者と議論を重ね、日本の技術やユースケースを反映させながら、よりよい6Gの仕様策定をリードしていきたいと考えています。
次回の2月会合での進捗状況に関し、またこのブログでご報告できればと思います。
