Special Articles

3GPP Release 18標準化活動(2)
3GPP Release 18における5GCの高度化技術概要―システムアーキテクチャ―

3GPP Release 18 SA

Jari Mutikainen Malla Reddy Sama
Riccardo Guerzoni

ドコモ欧州研究所
畑中 芳隆(はたなか よしたか) 魚島 淳平(うおしま じゅんぺい)
巳之口 淳(みのくち あつし)

6Gテック部

あらまし
3GPP Rel-18では,5GCのアーキテクチャに対して,VR,AR,XRなどによる拡張現実感とメディアサービス,時刻サービスと確定性通信,ネットワークスライシング,RNAA,インテント駆動管理を中心とした,機能改善と新しい技術領域の追加を行った.本稿では,3GPP Rel-18で拡張された5GCの高度化技術の概要を解説する.

01. まえがき

  • 3GPP(3rd Generation Partnership Project) Release 15(以下,Rel-15) ...

    開く

    3GPP(3rd Generation Partnership Project) Release 15(以下,Rel-15)で策定された5GC(5G Core network)*1のアーキテクチャは,Rel-16およびRel-17での拡張に引き続き,5G-Advancedの最初のリリースと位置づけられるRel-18においても,さまざまな分野で拡張があった.特に,VR(Virtual Reality)*2,AR(Augmented Reality)*3,XR(Extended Reality)*4などによる拡張現実感(以下,「拡張現実感」)とメディアサービス,時刻サービスと確定性通信*5,ネットワークスライシング*6,RNAA(Resource owner-aware Northbound Application Program Interface Access)*7,インテント駆動管理において,以下の機能改善と新しい技術領域の追加が行われた.

    • 拡張現実感を与えるアプリケーション,および,大容量低遅延の通信を必要とする対話型メディアサービスでは,輻輳*8状況におけるQoS(Quality of Service)*9の機能が拡張された.また,端末の電力消費削減のための機能が拡張された.
    • 時刻サービスと確定性通信では,既存の時刻同期の機能が拡張され,端末に時刻を提供するサービスが導入された.また,確定性通信がトランスポートネットワーク(TN:Transport Network)*10に導入され,基地局やアプリケーションと連携することで,さらなる低遅延通信が可能となった.さらに,DetNet(Deterministic Networking)と呼ばれるIPベースの確定性通信の仕組みが導入された.
    • ネットワークスライシングでは,スライスの可用性に問題がある場合の対処,スライスが地域限定の場合の対処,必要なネットワークスライスに必要なときだけ接続させるためのポリシーに関する機能が拡張された.
    • RNAAは,Northbound API*11アクセスを管理するCAPIF(Common API Framework)*12に,IETF(Internet Engineering Task Force)*13 OAuth 2.0*14をベースとした,API利用により影響を受けるユーザの認可のもとでAPIアクセスを許容する仕組みを追加したものであり,この仕組みが5GCに導入された.
    • インテント駆動管理は,ネットワークに関する詳細な知識を必要とせずに,実現したい状態(インテント)を提供できるようにシステムを駆動していく管理手法であり,この管理手法に関する仕様が拡張された.

    本稿では,これらの拡張について解説する.

    1. 5GC:5Gのアクセス技術向けに3GPPで規定された第5世代のコアネットワーク.
    2. VR:仮想現実のこと.
    3. AR:現実世界を写した映像に,電子的な情報を重ねて,ユーザに提示する技術.
    4. XR:仮想空間と現実空間との融合で新たな体験を提供する技術の総称.
    5. 確定性通信:許容遅延時間内にデータ到達を保証する通信のこと.
    6. ネットワークスライシング:5G時代の次世代ネットワークの実現形態の1つ.ユースケースやビジネスモデルなどのサービス単位で論理的に分離したネットワーク.
    7. RNAA:API使用者がリソースオーナ(*117参照)からの認可を必要とする,API起動シナリオ.
    8. 輻輳:通信の要求が短期間に集中してネットワークの処理能力を超え,通信に支障が発生した状態.
    9. QoS:通信サービスの品質.帯域幅や遅延などが代表的な指標となる.
    10. トランスポートネットワーク(TN):無線アクセスネットワークとコアネットワークを接続するネットワーク.かつ,それぞれのネットワーク内の装置間を接続するネットワーク.
    11. Northbound API:3rd party事業者などに対してモバイルネットワークの機能やリソースを提供するためのAPI.
    12. CAPIF:ノースバウンドAPIを提供するための共通的な機能をまとめた3GPPのフレームワーク.
    13. IETF:インターネット技術標準の開発,推進を行っている標準化組織.
    14. OAuth 2.0:正当なクライアントに対してシステムの操作を認可する仕組み.RFC6749.

02. 拡張現実感とメディアサービス

  • Rel-18では,「XRサービス(AR/VRサービス)」および高速データレートと ...

    開く

    Rel-18では,「XRサービス(AR/VRサービス)」および高速データレートと低遅延通信を必要とする「対話型メディアサービス」の処理効率化を図るために,いくつかの拡張機能が導入されている.これらのサービスは,WebRTC(Web Real-Time Communication)*15ベースまたはIMS(Internet protocol Multimedia Subsystem)*16ベースの通話サービスであり,メディア転送にRTP(Realtime Transport Protocol)*17/SRTP(Secure RTP)*18を使用する.

    メディア転送は,多くの場合,トラフィックバースト*19の安定した周期性が必要とされる.例えば,H.264*20またはH.265*21ビデオコーデックが使用されるビデオ通話またはビデオストリーミングサービスでは,ビデオフレームは一定の間隔(例えば,毎秒60フレーム)で送信される.各ビデオフレームは,(Iフレーム*22のように)他のフレームから独立しているか,(PおよびBフレーム*23*24のように)前または将来のフレームとの違いを表す.

    Rel-18より前の5GS(5G System)*25QoSの枠組みでは,これらのフレームを伝送するすべてのPDU(Protocol Data Unit)*26は,QoSフロー*27ごとに設定された同一のQoSパラメータを使用して処理される.

    Rel-18では,NG-RAN(Next Generation-Radio Access Network)*28の無線リソーススケジューリングを改善するために,このようなフレームを伝送する個々のPDUに対して異なるQoS処理(異なる優先順位など)を使用できる.これにより,特に輻輳状況において,NG-RANがアプリケーションのPDUの内容と重要性をより良く認識している場合に,サービスのユーザ体験が向上する.

    Rel-18で行われた別の機能改善は,スマートグラスなどのXRデバイスの電力消費である.メディアストリームの周期性とバースト性に基づいてConnectedモードDRX(Discontinuous Reception)*29パラメータを調整することで,端末の電力消費を削減することができる.

    2.1 XRアプリケーションの無線リソーススケジューリングの最適化

    Rel-17以前のリリースでは,QoSフローがQoSを区別する最も細かい粒度であった.Rel-18では,メディアストリーム内のPDUの目的を識別し,1つのQoSフローの中で,NG-RANでのQoSの扱い(すなわち無線リソーススケジューリング)をPDUごとに変えることができる.

    (1)DL(DownLink)方向

    メディアストリームのDL方向では,AF(Application Function)*30からC-Plane*31経由で受信した指示と,アプリケーションサーバからU-Plane*32経由で受信したPDUの内容に基づいて,PDUの識別と分類がUPF(User Plane Function)*33で行われる.

    (a)PDUセットQoSパラメータ

    AFは,Nnef_AFsessionWithQoSサービス*34を用いて,メディアストリームのPDUセットQoSパラメータ(PDUセット遅延要件(PSDB:PDU Set Delay Budget),PDUセット損失率(PSER:PDU Set Error Rate),PDUセット統合処理情報(PSIHI:PDU Set Integrated Handling Information),および,プロトコル記述(Protocol Description))をNEF(Network Exposure Function)*35に提供する.

    PDUセットQoSパラメータのうちPSDB,PSER,PSIHIは,PCF(Policy Control Function)*36およびSMF(Session Management Function)*37を介してNG-RANに提供され,無線リソーススケジューリングに使用される.プロトコル記述は,PCFおよびSMFを介してUPFに提供される.

    PSDBは,単一のPDUセットに属するすべてのPDUを送信するための最大遅延を設定し,PSERは,PDUセットの最大エラーレートを設定する.また,PSIHIは,PDUセットのすべてのPDUがアプリケーションに必要かどうかをNG-RANに示す.ここでは,例えば輻輳のために,NG-RANがPDUセットの1つのPDUを破棄する必要がある場合,PDUセットの1つのPDUが失われるとすぐに,NG-RANは無線リソースを解放するために残りのPDUを破棄することができる.

    プロトコル記述には,UPFがストリームのPDUを識別し,PDUからPDUセットを構築するために必要な詳細情報が含まれている.PDUセットは,ビデオフレームなどを表すPDUの集合体である.

    なおパラメータは,UL(UpLink),DLごとに異なる場合がある.AFは,以前のリリースと同様に,メディアストリームに関するその他の関連情報もNEFに提供する.例えば,ストリームの識別に使用されるIP 5タプル*38である.

    (b)RTPヘッダ拡張

    Rel-18において,3GPPはPDUセット識別のために,TS26.522[1]で新たなRTPヘッダ拡張(以下,3GPP RTPヘッダ拡張)を仕様化した.アプリケーションサーバなどのRTP送信者は,RTPメディアストリームのPDUのマーキングにRTPヘッダ拡張を使用し,拡張ヘッダ内で,PDUセットシーケンス番号,PDUセット内のPDUシーケンス番号,PDUセットの終わり,PDUセットサイズ,PDUセット内のPDU数,およびPDUセットの重要性(PSI:PDU Set Importance)を示すことができる.なお,アプリケーションサーバが3GPP RTPヘッダ拡張を使用しない場合に関して,TS26.522[1]には,UPFがRTP/SRTPで送信される一般的なビデオコーデック(例:H.264およびH.265)のPDUを識別する方法に関するガイドラインが記載されている.

    UPFは,ストリームに使用されるトランスポートプロトコル*39とコーデック,および3GPP RTPヘッダ拡張が含まれるかどうか,を決定するために,AFから(NEF,PCF,SMF経由で)受信したプロトコル記述も使用する.UPFはPDUセットを識別した後,NG-RAN向けのGTP-U(GPRS Tunneling Protocol for User Plane)*40ヘッダでPDUセットをマークする.

    拡張ヘッダのPSIは,QoSフロー内の他のPDUセットと比較した重要度を示す.通常,オーディオPDUの重要度は他のPDUよりも高く設定される.輻輳状況では,NG-RANはPSIを使用して重要度の低いPDUを破棄することがある.また,破棄の決定にPSDBとPSIHIの値を考慮することもある.

    (2)UL方向

    UL方向では,端末はNAS(Non-Access Stratum)*41メッセージでSMFから(AMF(Access and Mobility management Function)*42経由で)ULのプロトコル記述を受信し,それをPDUセットの識別に使用することができる.また,NG-RANは,DRB(Data Radio Bearer)*43の破棄の操作に関する設定を端末に行い,端末に破棄タイマの値を提供することもできる.端末は,送信時に,PDUセットの1つのPDUが破棄タイマの満了のために破棄されると,PDUセット内のすべてのPDUを破棄する.

    2.2 XRサービスの端末省電力の機能強化

    (1)DRXの概要

    DRXは,端末の電力消費を節約するための仕組みである.端末は,受信のために定期的に無線を活性化し,その他の時間は無線をスリープすることで,端末のバッテリの残電量の低下を遅らせる.DRXは,Idleモード(以下,IdleモードDRX)またはConnectedモード(以下,ConnectedモードDRX)に適用できる.

    IdleモードDRXは,端末がIdleモードにあり,ネットワークからのページング信号*44の可能性に対して無線を開く必要がある場合に使用される.eDRX(extended DRX)は,超低消費電力IoT(Internet of Things)端末向けのIdleモードDRXの拡張機能であり,アプリケーションのページング遅延に対する許容度に応じて,IdleモードDRXのスリープサイクルを最大で数時間延長することもできる.

    これに対し,ConnectedモードDRXは,アプリケーションサーバからのメディアストリームの受信など,端末アプリケーションが通信中の場合に適用される.端末の無線は,RRC(Radio Resource Control)*45接続状態を保ちながら,一方,ほとんどの時間でスリープ状態となり,DRXサイクルタイマ*46が端末を定期的に起動する場合にのみ,アプリケーションサーバからのDLデータを監視できる.DRXサイクルタイマが満了し端末を起動すると,端末は,NG-RANからデータ受信しない限り,DRX on-durationタイマ*47により設定された時間だけ,起動したままになる.一方,データを受信すると,端末はDRX inactivityタイマ*48を開始する.なお,これらのDRXタイマは,NG-RANによって端末に設定される.

    (2)ConnectedモードDRXの拡張

    Rel-18では,ConnectedモードDRXが拡張され,ネットワークはXRメディアストリームの周期性に基づいてDRXタイマを調整することができる.また,DRXサイクルタイマを,ビデオフレームレートと一致するように設定することができる.例えば,フレームレートが60フレーム/秒の場合,DRXサイクルタイマは16.66ミリ秒=50/3ミリ秒の非整数値に設定できる.

    ConnectedモードDRXの拡張では,UPFは,N6*49インタフェース(つまり,UPFとアプリケーションサーバの間のインタフェース)におけるDLメディアストリームの周期性のジッタ*50を測定するように指示される場合があり,UPFによって測定されたジッタは,C-Planeで(SMF経由で)NG-RANに送信され,NG-RANはそれを使用してDRX on-durationタイマを調整することができる.AFは,ストリームの計画上の周期性を示した上で,(Nnef_AFsessionWithQoSサービスを用いて)NEFを介してジッタ測定を活性化することができる.

    UPFは,DLのビデオフレームの最後のPDUのGTP-Uヘッダでデータバーストの終了を示すことができる.NG-RANは,この表示を使用して,DRX inactivityタイマ満了前に端末をスリープモードに戻すことができる.また,UPFは,前述したプロトコル記述または3GPP RTPヘッダ拡張,あるいはその両方を使用して,データバーストの終了表示のマーキングを行うPDUを識別する.

    UL方向では,端末はQoSフローごとにNG‐RANに支援情報(UL周期性とジッタ)を提供できる.

    2.3 L4SのためのECNマーキングのサポート

    L4S(Low Latency,Low Loss,Scalable Throughput)(低遅延,低損失,スケーラブルなスループット)は,IETF RFC 9331[2]で定義された新しいスケーラブルな輻輳制御メカニズムである.L4Sでは,ネットワーク内のキューがいっぱいになり,パケットを破棄する必要が生じる前に,IP層でネットワーク輻輳の通知(L4S ECN(Explicit Congestion Notification)マーキング*51)を生成・送信する.データ送信側はL4S ECNマーキングを検出し,ビットレートを削減する.

    L4SはIP層でECN(明示的輻輳通知)方式を利用するが,TCP(Transmission Control Protocol)*52に対してIETF RFC3168で最初に定義されたECN方式とは異なり,より頻繁にECNマーキングを行いデータ送信側もスムーズに反応する.L4Sを用いることで,ネットワークの輻輳や遅延を低減することができる.

    ネットワークでL4Sを使用するには,L4S対応トラフィックと他のL4S非対応トラフィックを別々のキューで処理する必要がある.Rel-18では,L4S対応トラフィック(例えばQUIC(Quick User Datagram Protocol Internet Connections)*53)と他のL4S非対応トラフィックに対して別々のQoSフローを確立する.なお,データ送信側はIP層でトラフィックのL4S ECN対応を示す.

    NG-RANは輻輳を監視し,輻輳が生じた場合にIP層でECNマーキングを生成し端末に送信する.あるいは,NG-RANはULパケットのGTP-Uヘッダを介してUPFにバッファ状態を報告し,UPFがIP層でECNマーキングを実行し端末に送信する.いずれの場合も,ECNマーク付きIPパケットを受信すると,端末はECNマークを送信者にエコーバック*54する.例えば,QUICがメディアストリームのトランスポートプロトコルとして使用される場合,端末のQUICスタック*55は,QUIC層の累積ECNカウンタを送信者(アプリケーションなど)に送り返すことによって,送信者にECNマーキングを受信したことを示す.このようにして,送信者は輻輳を認識し,受信したECNカウンタが値の増加を報告しなくなるまで,データレートを調整する.

    1. WebRTC:APIを経由して,Webブラウザやモバイルアプリケーション間で音声や映像・その他ファイルのリアルタイム通信を行う仕組みであり,ソースコードが公開されているオープンな規格.
    2. IMS:3GPP移動通信網におけるIPマルチメディアサービス(VoIP(Voice over IP),メッセージング,プレゼンスなど)を提供するサブシステム. 呼制御プロトコルとしてSIP(Session Initiation Protocol)を用いる.
    3. RTP:IETFで規格化された,音声や映像などをリアルタイムに配信するためのプロトコル.
    4. SRTP:IETFで規格化された,音声や映像などを安全にリアルタイムに配信するためのプロトコル.
    5. トラフィックバースト:短時間のうちに流れるデータ.
    6. H.264:動画データの符号化方式の1つ.
    7. H.265:動画データの符号化方式の1つ.H.264の後継規格.
    8. Iフレーム:フレーム予測符号化を用いず,ある画像を単独で符号化した映像データ.
    9. Pフレーム:Iフレームを参照しないと再現できないフレーム.
    10. Bフレーム:Iフレーム,Pフレームを参照しないと再現できないフレーム.
    11. 5GS:コアネットワーク,無線アクセスネットワーク,および通信端末で構成される5Gのネットワークシステム.
    12. PDU:プロトコルが処理するデータの単位.
    13. QoSフロー:5GSにおけるQoS転送処理の最小粒度.
    14. NG-RAN:5Gコアネットワークに接続されるRAN.無線アクセス技術としてNR,E-UTRA(Evolved Universal Terrestrial Radio Access)を用いる.
    15. DRX:端末の消費電力削減を目的とした間欠受信.
    16. AF:アプリケーションを提供する,ネットワーク機能.
    17. C-Plane:通信で送受信される信号のうち,制御にかかわる部分.
    18. U-Plane:通信で送受信される信号のうち,ユーザが送受信するデータの部分.
    19. UPF:5Gコアネットワーク内のユーザデータの送受信処理機能.
    20. Nnef_AFsessionWithQoSサービス:AFからのQoSにかかわる制御を受け付ける,NEF(*35参照)が提供するサービス.
    21. NEF:5G向けの3GPPシステムがもつ機能の一部を3GPPドメイン外に提供するための論理ノード.
    22. PCF:QoS制御,ポリシー制御,課金制御などを担う,5Gコアネットワークのネットワーク機能.
    23. SMF:5GCにおいてセッションを管理するネットワーク機能.
    24. IP 5タプル:IPヘッダ,TCP(*52参照)/UDP(*60参照)ヘッダに格納されている宛先IPアドレス(*86参照),宛先ポート番号,送信元IPアドレス,送信元ポート番号,プロトコル番号の5つの情報の総称.
    25. トランスポートプロトコル:プロトコル記述の中で用いられる場合,RTPやSRTPを指す.その他一般的には,トランスポート層で用いるプロトコルを指す.
    26. GTP-U:無線基地局やコアネットワークの装置がユーザデータを伝送するために使用するトンネリングプロトコル.
    27. NAS:端末とコアネットワークとの間のプロトコルスタックにおける機能レイヤ.
    28. AMF:基地局(gNB)を収容し,モビリティ制御などを提供する論理ノード.
    29. DRB:無線区間においてU-planeデータを流すベアラ.
    30. ページング信号:待受状態の移動端末に,着信あるいはネットワーク情報更新を通知する無線信号.
    31. RRC:無線回線を制御するレイヤ3プロトコル.
    32. DRXサイクルタイマ:Connected-mode DRXの周期を規定するタイマ.
    33. DRX on-durationタイマ:Connected-mode DRXの1つのDRXサイクルにおいて,端末の起動時間を規定するタイマ.
    34. DRX inactivityタイマ:Connected-mode DRXの1つのDRXサイクルにおいて,起動中に端末が信号を受信した場合に,端末が次にスリープ状態に入るまでの時間を規定するタイマ.
    35. N6:UPFとDNの間の参照点.
    36. ジッタ:信号やユーザデータにおける,遅延時間の揺らぎのこと.
    37. L4S ECNマーキング:L4Sを用いるためにIPパケットに情報を設定すること.
    38. TCP:インターネットで標準的に利用されるIPの上位プロトコルの1つ.UDPよりも信頼性が高い.
    39. QUIC:インターネットで利用されるIP/UDPの上位プロトコルの1つ.
    40. エコーバック:受信した情報をそのまま送り返すこと.
    41. QUICスタック:QUICを扱う機能.

03. 確定性通信

  • Rel-16は,IEEE(Institute of Electrical and Electronics Engineers) ...

    開く

    Rel-16は,IEEE(Institute of Electrical and Electronics Engineers) 802*56ネットワークで確定性通信を提供するIEEE TSN(Time-Sensitive Networking)*57ネットワークと5GSとの統合をサポートしている.

    IEEE TSN仕様全体の中で重要な構成技術の1つは,時刻同期である.Rel-16には,IEEE 1588[3]のイーサネットブリッジ*58用のプロトコルプロファイルであるgPTP(generic Precision Time Protocol)*59(IEEE 802.1AS[4])のサポートが含まれている.Rel-17は,業務用のオーディオ/ビデオアプリケーションなどで使用される,UDP(User Datagram Protocol)*60/IPを用いたTNにおけるPTPのサポートを導入した.Rel-16,Rel-17どちらの場合も,5GSはPTPインスタンス*61として機能し,PTPクライアントに対してPTP時刻同期メッセージを配信する.また,Rel-17では,ローカルGNSSを使用する場合などPTPを使用しないで無線インタフェース経由で端末に5G参照時刻を配信する別の方式も導入した.本方式は,「5Gアクセスストラタム時刻配信方式(ASTI:Access Stratum Time distribution)」とも呼ばれる.このとき,端末は,独自の手段で端末内などのアプリケーションに5G参照時刻を配信することができる.

    以下では,Rel-18での時刻同期の改善と確定性通信のその他の機能強化について解説する.なお,Rel-18ではIETF DetNetのサポートが導入されており,DetNetルータとして機能するように5GSを構成できる.

    3.1 5GSでの時刻同期の改善

    Rel-18では,以前のリリースで導入された時刻同期機能にいくつかの改善が加えられている.

    (1)5G時刻サービスの回復力

    5GSの時刻サービスは,端末,gNB(gNodeB)*62,およびUPFの内部クロックの同期に依存している.この同期を実現するには,gNBとUPFの間にPTPの通信プロファイル(例:ITU-T G.8265.1[5])をサポートするTNを展開するか,gNBとUPFの時刻源としてローカルGNSS(Global Navigation Satellite System)*63を使用する.

    一方,ローカルGNSSを使用する方式において,GNSS信号性能の問題などによる5GS内部クロックの潜在的な劣化は,5G時刻サービスの精度に影響を与える可能性がある.金融セクタやスマートグリッド*64などで使用される一部のアプリケーションは,このような時刻精度の劣化に,より敏感である.

    (a)クロック品質受入れ基準の提供

    Rel-18では,アプリケーション機能(AF)が5GSの時刻同期サービスのクロック品質受入れ基準を提供する手段が規定されている.AFは,例えば,5GSの時刻同期サービスに時刻情報を依存している(複数の)端末を管理しており,クロック品質受入れ基準を5GSに提供することで,それらの端末が適切な精度の時刻情報を得ているかを監視することができる.この基準が提供されている場合,5GSはNG-RANおよびUPFの5G内部クロックのネットワーク時刻同期状態を監視する.監視対象のネットワーク時刻同期状態属性には,クロック精度,UTC(Coordinated Universal Time)*65へのトレーサビリティ,GNSSへのトレーサビリティ,周波数安定性,親時刻源*66が含まれる.

    クロック品質の受入れ基準は,AFからTSCTSF(Time Sensitive Communication and Time Synchronization Function)*67に,さらにPCFおよびAMFを介してNG-RANに提供される.NG-RANには,ネットワーク時刻同期状態属性のしきい値が事前に設定されている.いずれかのネットワーク時刻同期状態属性がしきい値を超えた場合,NG-RANは端末コンテキスト内の受入れ基準とNG-RAN内の5G内部クロックの現在の時刻同期状態を比較し,受入れ基準を満たしていない場合は,端末に「受入れ不可」と通知する.

    この通知は,端末がまだ接続されていない場合,次回ネットワークに接続したときに,RRC信号によって端末に送信される.RRC-IdleまたはRRC-Inactiveの端末にクロック状態が劣化または改善したことを認識させるために,NG-RANは,クロック状態が変化するたびにイベントIDを変更し,SIB(System Information Block)*68情報を介してイベントIDを報知する.端末は,報知情報によってイベントIDがそれまで端末に格納されていた値から変更されたことを認識すると,ネットワークに再接続し,RRC信号を介してNG-RANによって提供される新しいクロック状態を学習する.

    なお,ASTIが使用されている場合,端末は「受入れ不可」の通知を受信したこと,現在のクロック品質がサービス基準を満たしていないことを端末内のアプリケーションに通知する.

    (b)クロック品質メトリック*69の提供

    クロック品質受入れ基準の代わりにAFは,端末にクロック品質メトリック(すなわち,NG-RAN内のネットワーク時刻同期状態属性の各々の実際の値)を提供するように,5GSに指示することができる.なお,クロック品質メトリックの使用方法は端末次第である.

    (c)ネットワーク時刻同期状態属性のTSCTSFへの通知方法とTSCTSFの動作

    NG-RANは現在の網ネットワーク時刻同期状態属性をTSCTSFに通知する.このために2つの仕組みが定義されている.1つは,OAM(Operations,Administration and Maintenance)*70経由でTSCTSFに通知する方法であり,もう1つは,端末に関連しないNGAP(Next Generation Application Protocol)*71信号を介してAMFに通知し,AMFからNamf_Communicationサービス*72を介してTSCTSFに通知する方法である.UPFはクロック状態をOAM,またはSMFとPCFを介してTSCTSFに通知する.

    通知された属性に基づいて,TSCTSFはどの端末が影響を受けているかどうか,AFが示したクロック品質の受入れ基準が満たされているかどうかを判断する.端末が影響を受けているかどうかを判断するために,TSCTSFはAMFから端末位置報告を取得する必要がある.端末がクロック状態の劣化したNG-RANノード*73よって収容されている場合,AMFはTSCTSFに端末識別子を通知する.受入れ基準が満たされていないと判断したTSCTSFは,時刻同期サービスの状態をAFに報告するか,端末がPTPインスタンスの一部である場合,端末のPTPポートをPTPインスタンスから一時的に削除する.

    (2)5G時刻サービスのカバレッジ地域

    前述したように,Rel-17は,5GSがPTPインスタンスとして動作する,ASTIと呼ばれる方式で)無線インタフェースを介してNG-RANから端末に5G参照時刻を配信する,といった2つの方法によって,時刻同期サービスをサポートする.Rel-18では,AFが時刻同期サービスのカバレッジ*74地域を提供できるようにすることで,両方の方法が改善された.

    AFは,NEFに,カバレッジ地域を「TA(Tracking Area)*75のリスト」または「NEFがTAのリストに変換する地理的地域」として示す.TSCTSFは,端末の位置の通知をAMFに依頼する.端末がカバレッジ地域の内部または外部に移動したことがAMFからTSCTSFに通知されるたびに,TSCTSFは端末の時刻同期サービスをそれぞれ有効または無効にする.つまり,端末がPTPインスタンスの一部である場合は,端末のPTPポートを活性化または一時的に非活性化にし,そうでない場合は,5Gアクセスストラタム時刻配信を有効または無効にする.TSCTSFは,端末の対応するサービス状態(すなわち,PTPポートあるいはASTIが活性か非活性か)についてもAFに通知する.

    なおAMFは,RA(Registration Area)*76の粒度を超えて端末の位置を認識しない可能性があるため,AMFは依頼されたカバレッジ地域を端末の現在の登録地域に合わせる.これは,RA内の一部のTAがAFによって要求されなかった場合でも,RA内のすべてのTAは時刻同期カバレッジ地域として扱われることを意味する.

    (3)ユーザ加入者情報によって制御される5G時刻サービス

    Rel-17では,AFが端末の時刻同期サービスを制御する.AFは,3GPP TS29.522[6]で定義されているように,PTPの場合のNnef_TimeSyncExposureサービスまたはASTIの場合のNnef_ASTIサービスを使用した制御ができる.

    Rel-18では,時刻同期サービスはユーザ加入者情報によって決定できる.この場合,AFからのサービスインタフェースは特定のユーザに対して無効になる.加入者データはUDM(Unified Data Management)*77に格納され,それらにはAFによって提供されるものと同じ時刻同期のサービスパラメータが含まれる.UDMのサービスデータは,TSCTSFにPTPサービスパラメータを指示する時刻同期加入者データと,AMFにASTIを指示するアクセス・モビリティ加入者データの2つの部分で構成される.

    Rel-18では,オペレータは,AFが端末に対するサービス要求で使用するサービスパラメータ値に関して,取り得る範囲を設定することもできる.例えば,UDMのユーザ加入者情報で許可されているカバレッジ地域からのみ,AFがカバレッジ地域を要求できる場合がある.その検証は,AFがサービスパラメータを5GSに送信するときにTSCTSFによって行われる.

    3.2 TNに展開されたTSN機能の5GSへの統合

    Rel-18では,TNに配備されたTSN機能の5GSへの統合がサポートされている.その目的は,確定的なトラフィックを伝送する5GS QoSフローのQoS要件とトラフィック特性(例:バースト到着時間,バースト間隔,要求最大遅延)をTNに示すことによって,TNでの確定的な通信を可能にすることである.5GSとTNの間のインタフェースは,IEEE Std 802.1Q[7]およびIEEE P802.1Qdj[8]で定義されているTSN UNI (User-Network Interface)である.

    5GSは,TNの中央ネットワーク制御(CNC:Central Network Controller)*78エンティティ*79に対する中央ユーザ制御(CUC:Central User Controller)*80エンティティとして機能する.5GSのCUCエンティティは,対応するPDU(Protocol Data Unit)セッション*81のSMFと併置される.CUCエンティティは,PDUセッション確立時にSMFからストリーム要件を取得し,それをTN CNCに渡す.また,CUCエンティティは,それぞれNG-RANのAN-TL(Access Network TSN Talker/Listener)*82およびUPFのCN-TL(Core Network TSN Talker/Listener)*83に実装されているTSN Talker/Listenerと通信する.SMF/CUCとAN-TLおよびCN-TL間のTSNパラメータは,TS23.501[9]のAnnex M.2で定義されているTL-Containerで伝達される.なお,TL-Containerのデータモデルは,IEEE Std 802.1Q[7],IEEE P802.1Qdj[8]およびIEEE Std 802.1CBdb[10]に基づいている.

    AN-TLおよびCN-TLは,NG-RANおよびUPFではオプションである.機能がサポートされている場合,TN CNCの制御に従って,AN-TLおよびCN-TLはストリーム変換を実行する.ストリーム変換にあたって,例えば,AN-TLおよびCN-TLは,TN CNCによって割り当てられたグループ宛先MACアドレス*84(TN CNCに割り当てられたグループMACアドレス空間から割り当てられる1つのMACアドレス)をストリームの宛先MACアドレスとして使用する.TNは宛先MACアドレスを使用してストリームを識別することができる.なお,TNは識別されたストリームごとに異なる処理を適用することができる.

    ストリーム変換を使用する以外のやり方として,TNはN3*85トンネルのIPアドレス*86を使用して,あるいはIEEE Std 802.1CBdb[10]の6.8節で定義されているmask-and-matchストリーム識別機能がサポートされている場合,GTP-UヘッダのN3 TEID(Tunnel Endpoint Identifier)*87およびQFI(QoS Flow ID)*88も使用して,ストリームを識別することができる.

    3.3 確定的ストリームの無線リソース割当て

    Rel-16では,トラフィックパターン,つまり確定的TSNストリームのバースト到着時刻(BAT:Burst Arrival Time)*89と周期性に基づいて,NG-RANでの無線リソース割当て(UL方向でのconfigured grant*90やDL方向でのsemi-persistent scheduling*91のタイミングなど)を支援する機能が導入された.Rel-17では,同じ機能が,5GSがTSNブリッジとして動作していない場合にも,任意の確定的ストリームに対する汎用機能となった.

    Rel-18では,NG-RANがAFにBAT補正値を提供できるようにすることで機能が改善された.これにより,BATを,NG-RANで次に予想されるストリームのバーストの送信機会に合わせることができる.この機能改善は,非常に低い遅延(例:2ミリ秒)を満たす必要があるアプリケーションを対象としている.NG-RANからAFに提供されるBAT補正値は,AFからのNnef_AFsessionWithQoSサービス要求でNG-RANが受信した元のBATとの違いを示す相対値である.BAT補正値はNnef_AFsessionWithQoS_Notifyサービス*92でAFに通知され,アプリケーションはそれに応じてデータ送信のタイミングを調整する.

    BAT補正値を決定するために,能動的と受動的の2つの方法が定義されている.能動的方法では,NG-RANはQoSフローの確立または変更要求に応答する際,SMFにBAT補正値を提供する.受動的方法では,NG-RANはU-Planeのトラフィックを測定する.バーストのタイミングのためにQoSフローの遅延要件を満たすことができないとNG-RANが判断した場合,NG-RANはトラフィックバーストの到着時刻と次に予想されるトラフィックバーストの送信機会の時刻との間の時間を短縮するよう,BAT補正値を決定する.

    同様に,NG-RANは,トラフィックバーストの周期を後続の送信機会の間の予想される間隔に合わせるために,AFに,調整後のトラフィックの周期性を通知することもできる.調整後の周期性は,AFへBAT補正値とともに提供される.アプリケーションはそれに応じてデータ送信のタイミングを調整する.

    3.4 IETF DetNet

    (1)IETF DetNetの概要

    IETF DetNetでは,リアルタイムアプリケーション用に指定されたIPデータフロー(以下,IPフロー)を,非常に低いデータ損失率,保証された帯域幅,制限された遅延で伝送するためのアーキテクチャを定義する.DetNet機能はIEEE TSNに似ているが,IEEE TSNはレイヤ2*93技術であり,IETF DetNetはレイヤ3*94技術であるため,複数のサブネット*95で構成される広範囲のネットワークに適している.さらに,5GSのTSNはイーサネットPDUセッションで動作し,DetNetはIP PDUセッションで動作するため,DetNetでは,端末はイーサネットPDUセッションをサポートする必要がない.

    (2)DetNetコントローラによる5GSの制御

    IETF DetNetに基づく確定性通信をサポートするために,5GSはIETF RFC 8655[11]で定義されている論理中継DetNetルータ(以下,5GSルータ)として機能する(図1).TSCTSFは,5GSのIPフローの処理を制御するために,RESTCONF*96(IETF RFC 8040[12])またはNETCONF(Network Configuration Protocol)*97(IETF RFC 6241[13])制御インタフェースをDetNetコントローラに公開する.インタフェースのデータモデルは,IETF DetNet YANGモデル*98に基づいており,TS29.565[14]のAnnex Bで定義されているように3GPPで拡張されている.

    TSCTSFによって開示される制御インタフェースを使用することで,DetNetコントローラは5GSルータの接続情報(例えば,PDUセッションに割り当てられたIPアドレスまたはIPv6プレフィックス*99,PDUセッションを介して到達可能なIPv4*100アドレスの範囲またはIPv6プレフィックス,各ポートのインタフェース識別子)を収集し,ネットワークトポロジ*101を構成することができる.ここで,インタフェース識別子は5GSルータ内で一意であり,例えばポート番号を基に5GS内で生成される.

    DetNetコントローラは,これらの情報を収集すると,上記の制御インタフェースを使用してIPフローのトラフィック特性とQoS要件を5GSルータに送信する.また,DetNetコントローラは,3GPP固有の「5GS-node-max-latency」パラメータを使用して,5GSルータ内のIPフローに最大遅延を通知する.

    TSCTSFは,コントローラが示すインタフェース識別子に基づいて,またはコントローラからのインタフェース識別子が使用できない場合はIPフローの送信元IPアドレスに基づいて,対応するPDUセッションを決定し,PDUセッションごとに,対応するPCFに情報を送信する.(PCF,SMF,UPFなどがかかわる)5GSの内部手順は,UPFと端末のトラフィックフィルタがイーサネットヘッダではなくIP 5タプルに基づいていることを除いて,TSNブリッジとして機能する5GSの手順とほぼ同じである.

    図1 5GSでのIETF DetNetのサポート
    1. IEEE 802:IEEEにおいてLANおよびMAN(Metropolitan Area Network)に関する標準を規定する委員会.
    2. IEEE TSN:遅延やジッタの許容値を超えずに配送されることが要求されるデータストリームを扱うために,IEEEで規定された一連の規格,あるいは,それらを基に構築されるネットワーク.
    3. イーサネットブリッジ:イーサネット上で,フレームを転送するノード.
    4. gPTP:IEEE 1588(PTP)のプロトコルプロファイルの1つであり,IEEE 802.1ASで規格化されたもの.
    5. UDP:インターネットで標準的に利用されるIPの上位プロトコルの1つ.
    6. PTPインスタンス:必要な設定がされた,PTPを処理する実体.
    7. gNB:NR無線を提供する無線基地局.
    8. ローカルGNSS:GNSSは,GPSや準天頂衛星などの衛星測位システムの総称.
    9. スマートグリッド:電力システムに無線センサを組み込み,供給側と需要側の電力をリアルタイムかつ自律的に監視・制御し,最適化できる送電網.
    10. UTC:世界各地の標準時刻の基準となる時刻.
    11. 親時刻源:時刻情報を提供する機器.
    12. TSCTSF:5GSがIEEE TSNと統合されていない場合に,5GSの時刻同期と確定通信サービスを管理する.
    13. SIB:セル選択やPLMN選択の判断に必要となる情報などを含み,基地局から端末に一斉同報される.
    14. メトリック:対象の属性や状態を一定の基準に基づいて数値化したもの.
    15. OAM:ネットワークにおける保守運用管理機能.
    16. NGAP:5GSにおける基地局とコアネットワークの間のインタフェースで用いられる上位プロトコル.
    17. Namf_Communicationサービス:基地局と情報のやり取りを行えるよう,AMFがコアネットワーク機能に提供するサービス.
    18. ノード:ネットワークにおいて一定の機能の集合を実現する機器.
    19. カバレッジ:電波の送受信,あるいは,特定のサービスの利用が可能なエリア.
    20. TA:1つまたは複数のセルから構成される位置を示す単位.
    21. RA:1つまたは複数のTAから構成され,ネットワーク上で管理される移動端末の位置を示す単位.
    22. UDM:5GCにおける加入者データ,移動機の在圏情報,セッション情報などの格納や情報提供を行う情報管理装置.
    23. 中央ネットワーク制御(CNC):IEEE TSNネットワークにおいて,ブリッジを設定するノード.
    24. エンティティ:論理アーキテクチャにおいて,機能を提供する構成要素.
    25. 中央ユーザ制御(CUC):IEEE TSNネットワークにおいて,ストリーム送信を行うノードからストリームの要求条件を取得し,CNCに伝えるノード.
    26. PDUセッション:端末とデータネットワーク間の論理接続.
    27. AN-TL:TNに配備されたTSNを用いるために,基地局でのTSNとの境界におかれた機能.
    28. CN-TL:TNに配備されたTSNを用いるために,UPFでのTSNとの境界におかれた機能.
    29. MACアドレス:各イーサネットボードに割り振られる,12桁の固有の物理アドレス.
    30. N3:無線アクセスネットワークとコアネットワークの間でユーザデータを転送する経路.
    31. IPアドレス:インターネットやイントラネットなどのIPネットワークに接続されたコンピュータや通信機器1台1台に割り振られた識別番号.
    32. TEID:GTPのプロトコル上で使用される,接続パスの宛先の識別子.
    33. QFI:QoSフローの識別子.
    34. バースト到着時刻(BAT):データバーストが到着する時刻.
    35. configured grant:基地局からあらかじめユーザにULデータ送信リソースを割り当てておくこと.
    36. semi-persistent scheduling:基地局からあらかじめユーザにDLデータ送信リソースを割り当てておくこと.
    37. Nnef_AFsessionWithQoS_Notifyサービス:AFからのQoSにかかわる制御を受け付けた場合に,その制御に関するイベントの発生をAFに通知する,NEFが提供するサービス.
    38. レイヤ2:OSI参照モデルの第2層.データリンク層を指す.
    39. レイヤ3:OSI参照モデルの第3層.IP層を指す.
    40. サブネット:1つのネットワークを細分化したもの.
    41. RESTCONF:ネットワーク機器を制御するプロトコルの1つ.
    42. NETCONF:ネットワーク機器を制御するプロトコルの1つ.
    43. IETF DetNet YANGモデル:IETF DetNetが規定したYANGモデル.YANGモデルはデータモデルのこと.
    44. IPv6プレフィックス:IPv6アドレスの一部を指し,当該IPv6アドレスが属するグループを指す.
    45. IPv4:現状のインターネットで利用されているインターネットプロトコル.アドレス資源を32bitで管理している.
    46. ネットワークトポロジ:ネットワーク構成のこと.

04. ネットワークスライス

  • 3GPPは,Rel-15以降の仕様でネットワークスライス機能を提供している. ...

    開く

    3GPPは,Rel-15以降の仕様でネットワークスライス機能を提供している.ネットワークスライスを使用すれば,異なる顧客のサービス要求が競合する場合でも,論理的なネットワークセグメントを分離することで,さまざまなビジネスニーズを満たすことができる.Rel-15の策定の後,GSMA(Global System for Mobile Communications Association)*102において,顧客によるネットワークスライスのリソース使用をネットワークが制御するための改善が検討され,その結果がまとめられた[15].

    Rel-18では,ネットワークスライスまたはネットワークスライスインスタンス*103がPDUセッションを提供できない場合や,アプリケーションのパフォーマンス要件を満たすことができない場合のサービス継続性など,複数の側面に対応した.また,有効期間が制限されているネットワークスライスのサポートも対応した.なお,この機能は,突然のPDUセッション解放を回避し,ネットワークスライスを正常に終了する方法を含む.有効期間が長いネットワークスライスにも適用できる.以下では,Rel-18でのネットワークスライスの仕組みの改善について解説する.

    4.1 一時的な可用性や予期しないネットワーク動作が発生した場合のネットワークスライス管理のサポート

    ネットワークスライスは,さまざまな顧客のニーズを満たすために展開される.例えば,オペレータは,エリア内のすべての端末,または限られた数の端末のために,スライスを配備できる.また,ネットワークスライスが限られた時間に配備されることもあり(例えば,試合中のスタジアム内の観客のためにスライスが配備されるなど),こういったケースに関しても最適化したネットワーク処理が求められる.さらに,ネットワークは,輻輳などの予期しない状況にも対処できる必要があり,他のスライスに影響を与えず,合意されたSLA(Service Level Agreement)*104にも準拠する慎重な修復手順を実行する必要がある.そのため,Rel-18では次の仕組みが定義されている.

    (1)一時的に利用可能なネットワークスライスの最適化された処理

    OAMや加入者情報などによってネットワークで事前に知られている限られた時間(一時的または周期的に活動的である時間)の間のみ,すべての端末または限られた数の端末に対して利用可能となるネットワークスライスがある.3GPPは,ネットワークスライスの登録管理およびセッション管理の状態の遷移に関連する信号負荷を軽減するために,ネットワークと端末が処理できるS-NSSAI(Single-Network Slice Selection Assistance Information)*105有効期間を定義した.

    AMFは,OAM設定または,UDMまたはNSSF(Network Slice Selection Function)*106から受信した情報に基づいて,Configured NSSAI内の1つ以上のS-NSSAIの有効期間を,Registration AcceptメッセージまたはUE(User Equipment) Configuration Update手順を介して,端末に示す.

    Configured NSSAI内のS-NSSAIに付随する有効期間の情報に基づいて,有効期間がS-NSSAIが利用できないことを示している場合,端末はRequested NSSAI*107に当該のS-NSSAIを含めない.端末がS-NSSAIの有効期間内に登録手順を終えており,S-NSSAIがすでにAllowed NSSAI*108またはPartially Allowed NSSAI*109の一部である場合,有効期間がS-NSSAIが利用できないことを示すと,端末はローカルに保存されたAllowed NSSAIまたはPartially Allowed NSSAIから当該のS-NSSAIを削除し,S-NSSAIに関連付けられたPDUセッションをローカルに解放する.

    同様にAMFも,有効期間がS-NSSAIが利用できないことを示している場合,Allowed NSSAIまたはPartially Allowed NSSAIからS-NSSAIをローカルに削除(つまり,端末に信号を送信せずに削除)する.S-NSSAIに対してPDUセッションが確立されている場合,AMFはSMFにPDUセッションの解放を要求する.

    有効期間がS-NSSAIがふたたび利用できないことを示している場合,端末はローカルに保存されたConfigured NSSAIから当該S-NSSAIを削除する.

    (2)ネットワークスライス置換のサポート

    ネットワークスライス置換機能は,S-NSSAIが(いかなる理由であれ)利用できなくなった場合,または輻輳した場合に,一時的にS-NSSAIをAlternative S-NSSAIに置き換える機能である(図2).

    S-NSSAIが利用できなくなった場合または輻輳した場合,NSSF,PCF,およびOAMが発生した事象の検出を行う.検出後の動作では,例えば,NSSFが検知すると,S-NSSAIのネットワークスライス可用性通知をAMFに送信し,PCFが検知すると,アクセスおよびモビリティ関連のポリシー通知をAMFに送信する.NSSF,PCFまたはOAMからの上記の通知は,S-NSSAIを置き換えるAlternative S-NSSAIを含む.AMFはS-NSSAIとAlternative S-NSSAIのマッピングを記憶し,UE Configuration UpdateメッセージまたはRegistration Acceptメッセージで端末にスライス置換を通知する.

    Alternative S-NSSAI でのPDUセッション確立の際に,端末はS-NSSAIとAlternative S-NSSAIの両方をAMFに通知し,AMFはS-NSSAIのSMF選択加入者データを使用して,適切なSMFを選択する.SMFはAlternative S-NSSAIと端末から受信したDNN(Data Network Name)*110を使用してPDUセッション確立を続行する.

    S-NSSAIがふたたび使用可能になった場合(例えば,S-NSSAIの輻輳が緩和された場合),AMFは,置き換えられたS-NSSAIからAlternative S-NSSAIへのマッピングを削除し,Allowed NSSAIとConfigured NSSAIからAlternative S-NSSAIを削除することで,置き換えられたS-NSSAIをふたたび使用するように(例えば,UE Configuration Update手順を使用して,または次の登録手順で)端末を再設定する.

    図2 代替スライスに置き換えられたネットワークスライス

    4.2 ネットワークスライスの使用制御のサポート

    Rel-18までの5GS仕様では,通信事業者は,端末がネットワークスライスに登録あるいは登録解除するタイミング,PDUセッションを確立あるいは解放するタイミングを制御することはできない.例えば,通信事業者は,ネットワークスライスでの接続が実際に必要な場合にのみ,端末を当該ネットワークスライスに登録させることはできない.また,URSP(User equipment Route Selection Policy)*111の設定において,アプリケーションに対応するHPLMN(Home Public Land Mobile Networks)*112スライスが端末の接続オプションに含まれている場合でも,在圏PLMN(すなわち,HPLMNまたはVPLMN(Visited PLMN)*113)が(アプリケーションに対応するHPLMNスライスに対応する)在圏PLMNの望ましいスライスに端末をルーティングする方法はない.

    そのため,Rel-18ではAMFが,端末の1つ(または複数)のネットワークスライスの使用を制御するために,この(またはこれらの)ネットワークスライスのスライス使用ポリシーを決定し,Configured NSSAIとともにこの情報を使用して端末を設定する新しい仕組みが規定された.このネットワーク制御のスライス使用ポリシーは,Registration AcceptまたはUE Configuration Updateコマンドで,在圏PLMNのためのConfigured NSSAIとともに,端末に提供され,端末は,受信したスライス使用ポリシーを端末内に格納する.

    このスライス使用ポリシーには,端末内のアプリケーションがネットワークスライスでのデータ転送を必要とする場合にのみ,端末がネットワークを使用してネットワークスライスに登録する設定が含まれる.また,オプションとして,S-NSSAIに関連付けられている最後のPDUセッションが解放された後にネットワークスライスを登録解除するための登録解除不活性タイマも含めることができる.

    4.3 サービス地域の制限

    一般に,ネットワークスライスはTAごとの粒度で定義されるが,プライベートネットワークおよび産業用IoTアプリケーションを扱う場合には,必ずしも既存のTA境界と一致しない,地理的に限定された可用性をもつネットワークスライスが使用できると通信事業者にとって便利である.スライスが使用可能であるべきTAのセルでネットワークスライスのリソースを構成すること,および,使用できない領域(リソースがない領域)を設定することは,通信事業者の責務である.

    AMFは,(TAの一部のセルでネットワークスライスが使用できないという)ネットワークスライスの可用性に関する情報としてNS-AoS(Network Slice Area of Service)*114をOAMから受信する.OAMから受信したNS-AoS情報に基づいて導出した後述のS-NSSAI位置可用性情報を使用して端末を設定する.また,S-NSSAIの使用状況を監視し,特にS-NSSAI位置可用性情報をサポートしない端末に対し,NS-AoSを適用する.

    S-NSSAI位置可用性情報は,ネットワークスライスの可用性がTAの境界と一致しないTAでのS-NSSAIの使用に関する追加の制限を定義する.S-NSSAI位置可用性情報を受信した端末は,端末が滞在しているセルでS-NSSAIが使用可能であることをS-NSSAI位置可用性情報が示している場合にのみ,S-NSSAIを要求できる.

    1. GSMA:世界中の移動通信事業者およびモバイル産業界に関連するメンバにて構成され,移動通信業界全体の発展をめざした活動を行っている団体.
    2. ネットワークスライスインスタンス:ネットワークスライスを構成するNF,およびそれらに必要な資源(例えば計算資源,ストレージ資源,ネットワーキング資源).
    3. SLA:サービス提供者とサービス消費者との間の契約.
    4. S-NSSAI:5GCにおいて用いられるNetwork Sliceを特定する識別子.
    5. NSSF:加入者が利用するネットワークスライスを選択するNF.
    6. Requested NSSAI:登録手順時に,端末が使用することを要求するネットワークスライス.
    7. Allowed NSSAI:登録手順時に,ネットワークが使用を許可したネットワークスライス.
    8. Partially Allowed NSSAI:登録手順時に,ネットワークが,RA内のいくつかのTAにおける使用を許可したネットワークスライス.
    9. DNN:端末の通信先.端末がコアネットワークを介して接続するデータネットワークの識別名.
    10. URSP:トラフィックごとに適切な経路を選択するために,端末が用いるポリシー.
    11. HPLMN:加入者が契約しているオペレータのこと.
    12. VPLMN:加入者がローミングした先のオペレータのこと.
    13. NS-AoS:ネットワークスライスが利用可能な地域.

05. RNAA

  • 5.1 CAPIF

    開く

    3GPPでは,モバイルネットワークがもつ機能やリソースをサードパーティの事業者などに対して開放するNorthbound API機能部として,NEFやSCEF(Service Capability Exposure Function)*115を規定しており,各種のサービスAPIを提供している.CAPIFは,これらのAPIの発行や管理,セキュリティ面の考慮などの共通的な課題を解決するための統一的なフレームワークであり,3GPP TSG SA(Technical Specification Group Service and System Aspects)*116WG(Working Group)6(以下,SA6)において仕様策定が進められ,Rel-15で標準化された.

    5.2 RNAA導入の目的

    RNAAは,Rel-18でドコモが提案し標準化されたCAPIFの認可にかかわるオプション機能であり,この機能によりCAPIFはリソースオーナ*117に対しリソースの使用のための認可を求めることが実現可能となった.ユースケースの一例として,オンライン対戦ゲームの利用者が対戦相手と同程度の回線速度の条件で対戦ゲームを実施したい場合,リソースオーナである対戦相手に対し通信帯域制御であるQoS変更を求めるといったことが可能となる.

    RNAAは,IETFで標準化されているOAuth 2.0をベースとしており,Webサービスなどで広く利用されている認可プロトコルをCAPIFに適用することで,さまざまなサードパーティの事業者や開発者へのニーズに対応し,CAPIFの技術をより広く利用してもらうことを目的としている.

    Rel-18では,RNAAで用いる認可付与方式は複数規定されているが,本稿では代表的な認可コード付与方式によるRNAAを解説する.

    5.3 RNAAのアーキテクチャ

    RNAAの代表的なアーキテクチャを図3に示す.リソースオーナはRNAAを通じて保持するリソースの権限に対する許可をAPI呼出し元に付与する.なおCAPIFやRNAAの技術的な詳細は文献[1]や文献[2]および文献[9]などを参照されたい.

    各機能などの詳細を以下に述べる.

    1. リソースオーナ機能
      リソースオーナへの認可要求を管理するために,CAPIFコア機能内にある認可機能と連携するRNAAの機能部である.OAuth 2.0ではリソースオーナに相当する.
    2. 認可機能
      リソースオーナ機能と連携し,認可コード発行のための認可を実施するRNAAの機能部である.OAuth 2.0では認可サーバに相当する.
    3. API呼出し元
      CAPIF APIおよびサービスAPIの呼出し元であり,ネットワークオペレータや端末上にあるサードパーティのアプリケーションを指す.OAuth 2.0ではクライアントに相当する.
    4. CAPIFコア機能
      CAPIF APIを提供し,API呼出し元の認証・認可やサービスAPIの登録,ポリシーの管理など,CAPIFで提供する各種機能においての中心的な役割を果たすCAPIFの機能部である.RNAAにおける認可処理はCAPIFコア機能内の(2)認可機能が担う.
    5. APIプロバイダドメイン機能
      サービスAPIを提供し,「API開示機能」「API発行機能」「API管理機能」を総称するCAPIFの機能部である.
    6. API開示機能
      API呼出し元からのサービスAPI呼出しを受け入れるCAPIFの機能部である.OAuth 2.0ではリソースサーバに相当する.
    7. API発行機能
      サービスAPIをAPI呼出し元が利用できるようにするために,CAPIFコア機能宛にサービスAPI情報を発行するCAPIFの機能部である.
    8. API管理機能
      発行されたサービスAPIの管理を担い,サービスAPI呼出しログの監査やサービスAPIの状態の監視などを行うCAPIFの機能部.

    なお,(7)と(8)の機能に関しては以降の説明にかかわらず参考情報として記載する.

    図3 RNAAのアーキテクチャ

    5.4 RNAAの機能

    API呼出し元がCAPIFのサービスAPIを呼び出す際のオプションとして,リソースオーナの同意を取得するケースがあり,その際にRNAAの機能を用いる.RNAAの手順例を図4に示す.

    なお,RNAAを用いる前提として,事前に下記の条件を満たしている必要がある.

    • CAPIF側にAPI呼出し元がオンボード登録されている.
    • CAPIF側でサービスAPIの発行が完了されており,サービスAPIが発見可能な状態となっている.
    • CAPIF側にAPI呼出し元が認証されている.
    • CAPIF側で,API呼出し元とAPI開示機能間の認証認可を実施する際のセキュリティメソッド(本稿ではOAuthトークン*118を用いたTLS(Transport Layer Security)*119方式とする)が決定されている.
    • CAPIF側でRNAA利用時のリソースオーナの同意を取得する際の認可の付与方式(本稿では認可コード付与方式とする)が決定されている.

    図4にある各手順について以下に解説する.

    1. API開示機能によるAPI呼出し元の認証
      API呼出し元はAPI開示機能に対し,事前に決定されたセキュリティメソッドを用いて認証を要求し,内容を検証したAPI開示機能はAPI呼出し元の認証を実施する.
    2. サービスAPIの認可要求
      API呼出し元は,CAPIFコア機能内にある認可機能に対し,サービスAPIの認可要求を送信する.
    3. リソースオーナからの認可同意取得
      認可要求を受信した認可機能はリソースオーナを認証し,認可要求に対する同意/不同意を求める.リソースオーナが同意すると.認可機能はAPI呼出し元への権限移譲を実施する.このときAPI呼出し元は認可機能から認可コードを受け取る.
    4. サービスAPIの認可
      API呼出し元は認可機能に対し認可コードを送信し,認可機能はAPI呼出し元の認証や認可コードの検証を行い,問題がなければAPI呼出し元に対しアクセストークンを発行する.
    5. サービスAPIの実行
      API呼出し元はAPI開示機能に対し,アクセストークンを含むサービスAPIの実行を要求するメッセージを送信し,内容を検証したAPI開示機能は,CAPIFコア機能と連携して,サービスAPIを実行する.
    図4 RNAAの手順例

    5.5 今後のRNAAの展望

    Rel-18においてはRNAAの基本的なアーキテクチャや機能を規定したが,Rel-19以降も機能面での拡張や複雑な条件下での仕様の追加などを目的として,RNAAの拡張,詳細な仕様の検討が計画されている.加えてRel-19においても,SA6でドコモがラポータ*120となり,RNAAを含むCAPIFの使用方法をより分かりやすくまとめるため,3GPPの外部向けテクニカルレポートとして「CAPIF使用方法に関するガイドライン」を作成する取組みを実施している.今後もRNAAやCAPIFが広く認知され,多くの国とサービスでの利用が促進されるために国際標準化活動への貢献を継続していく.

    1. SCEF:4G向けの3GPPシステムがもつ機能の一部を3GPPドメイン外に提供するための論理ノード.
    2. TSG SA:3GPPにおいて,技術仕様の策定を担うグループの1つ.サービス要求条件,アーキテクチャ,セキュリティに関する仕様などを策定する.
    3. リソースオーナ:リソースを保持する所有者.
    4. トークン:本稿ではアクセストークンを指す.提示することでAPIへのアクセスが認可される文字列のこと.
    5. TLS:通信の暗号化プロトコルの1つ.
    6. ラポータ:個々のWIや仕様ごとに,仕様の編集,作業進捗の管理やWG会合への報告を行う役割.

06. インテント駆動管理

  • 3GPP TSG SA WG5では,移動通信ネットワークに関する管理機能を規定 ...

    開く

    3GPP TSG SA WG5では,移動通信ネットワークに関する管理機能を規定しており,インテント駆動管理が活発に議論されている.Rel-17にて,インテント駆動管理に関する技術仕様書(TS28.312[16])が導入され,Rel-18にて拡張された.以下では,インテント駆動管理に関する基本概念,データモデル,実現するための手順,今後の展望を解説する.

    6.1 基本概念

    現在の移動通信ネットワークの運用は複雑性が増している.運用するためには,ネットワークの詳細を把握した上で,細かい設定を行う必要があり,通信事業者の負担が増している.また,多様化するビジネスニーズに対応するため,ビジネス目標や顧客の期待に合わせて運用を適応させる必要があり,「どのように実現する」という観点より「何を実現したい」という観点の把握が通信事業者にとって重要となる.インテント駆動管理とは,実現したい状態として表現されたインテントに従い,ネットワークに関する詳細な知識を必要とせずに,実現したい状態を提供できるようにシステムを駆動していく管理手法である.

    インテントは,特定のサービスまたはネットワーク管理ワークフローの要件,目標,制約などに関する期待を指定する.インテントに関する説明として,TS28.312[16]にて下記が記載されている.

    • インテントは,人間が理解でき,機械が曖昧さなく解釈できるものである.
    • インテントは,達成する必要がある「何(What)」を説明することに重点を置いており,必要な結果を達成するための「方法(How)」にはあまり焦点を当てていない.これにより,インテントの要求元は,実装の詳細を知る負担が軽減され,インテントの処理先は代替オプションを検討し,最適なソリューションを見つける余地が生まれる.
    • インテントによって表現される期待は,基盤となるシステムの実装,テクノロジ,インフラストラクチャ*121に依存しない.
    • インテントは,達成状況を測定および評価できるように,ネットワークデータから定量化できる必要がある.

    (1)インテントの分類

    インテントは,図5(TS28.312[16])に示す内容に分類されている.

    • 通信サービスカスタマ(CSC:Communication Service Customer)からのインテント(Intent-CSC):インテントを使用することにより,CSCは,通信サービスの詳細な管理方法を知らなくても,通信サービスプロバイダ(CSP:Communication Service Provider)に要求する通信サービスの特徴を表現できる.例として,「特定の時間内に,ある車両のグループに対してV2X(Vehicle to Everything)通信*122サービスを有効にする」といったものがある.
    • CSPからのインテント(Intent-CSP):インテントを使用することにより,CSPは,ネットワークの詳細な管理方法を知らなくても,ネットワークに要求する内容を表現できる.例として「高速道路417号線のV2X通信をサポートするネットワークサービスを提供し,同時に500台の車両をサポートする」といったものがある.
    • ネットワークオペレータ(NOP:Network OPerator)からのインテント(Intent-NOP):インテントを使用することにより,NOPは,ネットワーク要素の詳細な管理方法を知らなくても,ネットワーク要素のグループ(サブネットワークなど)の管理と制御に対して自身が要求する内容を表現できる.例として,「特定のエリアで指定されたカバレッジ要件と端末スループット要件を満たす無線ネットワークサービスを提供する」といったものがある.

    (2)インテントの数値目標

    インテントは,下記のようにネットワーク管理のニーズによって異なる特定の数値目標を記述できる.

    • ネットワークおよびサービス関連オブジェクト*123を配置するためのインテント期待値*124の場合では,例えば「指定された周波数情報・トランスポート情報・無線情報(PCI(Physical Cell ID)*125の範囲・セルID*126など),ネットワーク容量および性能情報を使用して,指定されたエリアに無線ネットワークを配置する」といった設定を行うことができる.
    • ネットワークおよびサービス関連オブジェクトに対するインテント期待値の場合では,例えば「指定されたエリアの無線ネットワークが,特定の予想されるRANと端末間のスループット目標を満たしていること」といった設定を行うことができる.
    図5 役割ごとに異なるインテント

    6.2 データモデル

    TS28.312[16]では,データモデルが規定されている.データモデルはインテントがもっている属性(期待内容や優先度など)が定義されている.

    図6[16]に示すように,インテント処理機能には,インテントとインテント報告というデータモデルが定義されている.本データモデルを用いて,インテントの管理を行っていく.

    図7[16]に示すようにインテントには,期待内容,制約条件が含まれており,期待内容はさらに,インテントの対象,インテントのターゲットを含んでいる.インテントの対象は,インテントを適用する対象を示すものであり,インテントのターゲットは,インテントの具体的な内容を示している.

    図8[16]に示すように,インテント報告には達成状況,衝突状況,実現可能性が含まれている.

    図6 インテント処理機能のデータモデル、図7 インテントのデータモデル、図8 インテント報告のデータモデル

    6.3 手順

    TS28.312[16]では,インテントの要求元と処理先にてインテントをやり取りするさまざまな手順が定められている.

    • Create:インテントを生成する手順.本手順を用いて,要求元よりインテントの期待内容,制約条件を伝える.
    • Modify:インテントを変更する手順.本手順を用いて,要求元よりインテントの変更内容を伝える.
    • Delete:インテントを削除する手順.本手順を用いて,要求元よりインテントの削除内容を伝える.
    • Query:インテントに関する現在の設定内容などを取得する手順.
    • インテント衝突の解決:複数のインテントに記載されている内容が矛盾した場合に解決を行う一連の手順.
    • インテント報告管理:インテントの状況を報告する手順.本手順を用いて,インテントの達成状況,衝突状況,実現可能性を伝える.

    6.4 今後の展望

    インテントの基本機能はRel-18にて検討が完了したが,Rel-19においても拡張機能については引き続き検討が行われている.一例として,インテント要求元と処理先の間で調停を行う機能がある.これは処理先で要求されたインテントが実現できない場合に,代替を伝えるなどの調停を行う機能であり,人手を介さずにシステム全体が動作するために必要な機能である.

    また,インテントは3GPPに限らず,TM forum(TeleManagement forum)*127,ETSI ZSM(European Telecommunications Standards Institute Zero Touch Network and Service Management)*128,ETSI NFV(ETSI Network Functions Virtualisation)*129などの他の標準化団体でも活発に議論されている.Rel-18検討においても各団体と情報交換を行いながら進めてきており,今後も整合性を取れるように情報交換が求められる.

    1. インフラストラクチャ:アプリケーションを実行するのに必要な物理的もしくは仮想的なデータセンタやサーバ,ネットワークなどの総称.
    2. V2X通信:V2Xは,自動車と他の自動車の間(車車間(V2V:Vehicle to Vehicle)),自動車と信号機や道路標識などのインフラ(路車間(V2I:Vehicle to Infrastructure)),あるいはスマートフォンを持った歩行者と車の間(車歩行者間(V2P:Vehicle to Pedestrian))が直接に相互通信することを目的とした無線通信システムの総称.
    3. オブジェクト:現実世界に実体や概念として存在するものをプログラム上で扱えるように表現したもの.表現対象となる実体の属性を表すデータと,実体に対する操作の組合せとして表現される.
    4. インテント期待値:インテントの数値目標のこと.
    5. PCI:物理的なセル識別子.
    6. セルID:セルごとに付与される識別情報.
    7. TM forum:電気通信分野のオペレーション業務における標準仕様を策定する非営利団体.
    8. ETSI ZSM:ETSIは欧州電気通信標準化機構.ヨーロッパの標準化団体.電気通信技術に関する標準化を行っている.ETSI ZSMは,ネットワーク運用自動化技術の標準化を行う団体.
    9. ETSI NFV:ETSIは欧州電気通信標準化機構.ヨーロッパの標準化団体.電気通信技術に関する標準化を行っている.ETSI NFVは,ネットワーク仮想化基盤に関する標準化を行う団体.

07. あとがき

  • 本稿では,Rel-18で規定された5GCの拡張について,拡張現実感とメディア ...

    開く

    本稿では,Rel-18で規定された5GCの拡張について,拡張現実感とメディアサービス,時刻サービスと確定性通信,ネットワークスライシング,RNAA,インテント駆動管理に焦点を当てて解説した.3GPPは,現在Rel-19の検討を進めており,5G-Advancedのさらなる拡張をめざしている.ドコモは,今後も3GPPにおける5G-Advanced標準化に寄与し,移動通信のさらなる発展に貢献していく.

  • 文献

    開く

    • [1] 3GPP TS26.522 V18.1.0:“5G Real-time Media Transport Protocol Configurations,”Jun. 2024.
    • [2] IETF RFC 9331:“The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S),”Jan. 2023.
    • [3] IEEE Std 1588:“IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems,” Edition 2019.
    • [4] IEEE Std 802.1AS-2020:“IEEE Standard for Local and metropolitan area networks--Timing and Synchronization for Time-Sensitive Applications.”
    • [5] ITU-T G.8265.1:“Precision time protocol telecom profile for frequency synchronization,”Nov. 2022.
    • [6] 3GPP TS 29.522 V18.6.1:“5G System; Network Exposure Function Northbound APIs; Stage 3,”Jul. 2024.
    • [7] IEEE Std 802.1Q-2022:“IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks.”
    • [8] IEEE Std P802.1Qdj-d1.3:“IEEE Draft Standard for Local and metropolitan area networks - Bridges and Bridged Networks - Amendment XX: Configuration Enhancements for Time-Sensitive Networking.”
    • [9] 3GPP TS23.501 V18.6.0:“System architecture for the 5G System (5GS);Stage 2,”Jun. 2024.
    • [10] IEEE Std 802.1CBdb-2017:“IEEE Standard for Local and metropolitan area networks-Frame Replication and Elimination for Reliability.”
    • [11] IETF RFC 8655:“Deterministic Networking Architecture,”Oct. 2019.
    • [12] IETF RFC 8040:“RESTCONF Protocol,”Jan. 2017.
    • [13] IETF RFC 6241:“Network Configuration Protocol (NETCONF),”Jun. 2011.
    • [14] 3GPP TS29.565 V18.6.0:“5G System;Time Sensitive Communication and Time Synchronization Function Services;Stage 3,”Jun. 2024.
    • [15] GSMA NG.116 V1.0: “Generic Network Slice Template,”May 2019.
    • [16] 3GPP TS28.312 V18.4.0:“Management and orchestration;Intent driven management services for mobile networks,”Jun. 2024.
このページのトップへ