Cisco Japan Blog
Share

5G-シスコが考えるサービスプロバイダー E2E アーキテクチャ 第5章 5G 時代のエンドツーエンド ネットワークスライシング(2)


2020年1月16日


第 5 章  5G 時代のエンドツーエンド ネットワークスライシング(2)

前回は、5G 時代の多様な要求条件に対応するための技術の一つであるネットワークスライシングについて、概要、エンドツーエンドでの考察の必要性と現状についてご紹介しました。

また、トランスポート部分に関するネットワークスライシング実現手法については第 2 章(1)に、モバイルパケットコア部分に関するネットワークスライシングについて、第 3 章(2)でご紹介しています。

ネットワークスライシングは、 5G 時代のネットワークシステムアーキテクチャを検討する上で重要な項目であることは間違いありません。しかし、共通の物理ネットワーク上に複数の論理ネットワークを実現するという考え方は旧来より存在し、新しい概念ではありません。

そこで本稿では、ネットワークスライシングについて一歩立ち戻って検討し、今後の展望に繋げたいと思います。

 

5.5 今なぜネットワークスライシングなのか

前述のとおり、共通の物理ネットワーク上に複数の論理ネットワークを実現するという考え方は旧来より存在します。VPN で仮想の専用ネットワークを実現することができ、QoS やトラフィック エンジニアリング技術によって SLA 特性の差別化が可能です。(今では、セグメントルーティング技術、および Flex Algo や TE Policy を使って、よりシンプルに VPN や異なる SLA を提供することができます。第 2 章参照。)また、APN でサービスを分けることも可能です。

では、今なぜネットワークスライシングが注目されているのでしょうか。それは、5G というモバイルネットワークにおける世代進化は、単なる Radio 技術の進化ではなく、ネットワークシステムアーキテクチャ全体に関わる大きな変遷契機であるからです。”モバイルファースト”と言われるように、現代のほとんどのシステムは、スマートフォン、 タブレットなどモバイルでの使用を前提としています。つまり、モバイルは今や普遍的にほとんどのシステムに組み込まれており、もはや特殊なシステムではありません。そして何よりも、現代の、着目すべきより大きな潮流は、デジタル トランスフォーメーションとデジタル ディスラプションです。このデジタル ディスラプション(非連続的、破壊的な変化)は、様々な市場の勢力図を塗り替え再定義する可能性を秘めており、デジタル ボルテックスによると、それぞれの業界の市場シェア上位 10 社のうち平均 4 社がデジタル ディスラプションによってその地位を失うと考えられています [1]。

そのような中、ネットワークシステムは、より利便性と提供価値を高める必要があります。これまでのやり方で、これまでのドメイン毎に、帯域増強や信頼性向上などの改善を行うのでは立ち往きません。例えば 5G の一つの要件とされるURLLC は、Radio 部分だけが超低遅延を実現しても、システム全体として超低遅延性・高信頼性を実現しないとあまり意味がありません。デジタル時代の進展を念頭に、時期を同じくして起こっている技術進化 ― SDN・プログラマビリティ、仮想化・クラウドネイティヴ、自動化、機械学習、IoT プラットフォーム、エッジコンピューティング、オープン・ディスアグリゲーション ― なども併せて、アーキテクチャ全体を俯瞰してシステムを再定義する必要があります。その再定義の一つがネットワークスライシングであると考えます。

現在多く業界団体や標準化団体において、ネットワークスライシングの検討が行われています。本章の Appendix として、スナップショット的ではありますが、業界団体や標準化団体においてどのような議論が行われているかを示します(2019 年中盤時点)。当然のことかもしれませんが、エンドツーエンドの検討は概念的なものに留まり、詳細の検討は専らドメイン毎に個別に行われているのが現状です。

 

5.6 ドメイン間の検討

多様な SLA やこれまでとは全く異なるユーザー体験を提供するためには、システム全体の検討が必要です。モバイルネットワークシステムは、3GPP 用語で言う所の RAN、CN、TN、DN などのドメインから構成され、現在それぞれのドメイン毎にネットワークスライシングの検討が進んでいますので、それらを統合することが求められます。まずは、ドメインを統合するオーケストレータが、それぞれのドメインのオーケストレータと連携し、エンドツーエンド オーケストレーションを実現することが考えられます(図 5-3)。エンドツーエンドオーケストレーションの具体的方法論については、第 6 章で記述します。

 

図 5-3 エンドツーエンド ネットワークスライシングとサービス ライフサイクル向けのクロスドメイン オーケストレーション(Source: John Mullooly)

図 5-3 エンドツーエンド ネットワークスライシングとサービス ライフサイクル向けのクロスドメイン オーケストレーション(Source: John Mullooly)

 

また、実際のトラフィックを適切なネットワーク側スライスにマッピングするために、データプレーンのマッピング方式も必要になります。前回述べたように既存の VLAN ID を使うことが考えられますが、新たな ID(MNTC-ID: Mobile Network Transport Context ID, SLID: Slice ID)を導入する提案も出てきています(draft-clt-dmm-tn-aware-mobility [2], draft-filsfils-spring-srv6-stateless-slice-id [4])。

 

5.7 ドメインを超えた検討と今後の展望

より革新的に考えると、ドメイン間連携の検討だけでは不十分で、必ずしも既存アーキテクチャを踏襲するのでなく、新たなドメイン境界を定義することも含めてドメインを超えて検討することが必要になります。前述例の URLLC サービスでは、システム全体で超低遅延を実現するために、コンピューティングやストレージをどう分散配置するかも重要な要素になります。さらに、これからのデジタル時代のサービスを考えると、これまでのコネクション中心ネットワークアーキテクチャ(どのように接続性を提供するか)ではなく、データ中心アーキテクチャ(どのようなデータをどう収集・蓄積・分析するか)にシフトする必要があると考えます。今までの慣習にとらわれていたら、ネットワークシステムの価値を高めることはできません。

これは一つの例ですが、例えばモバイルパケットコアは、CUPS(図 5-4)により、コントロール プレーンとユーザー プレーンが完全に分離され、UPF はデータ転送に特化するように進化しました。このことにより、モビリティを支えるためのアンカーポイントをコントロール プレーンとは独立して偏在させることができるため、より柔軟なコンピューティングやストレージの配置や、ローカル 5G のような、企業システムとの新たな形態での融合が可能になります。そうであれば、もう一歩論を進めて、gNB や UPF などデータプレーンを司るエンティティを、モバイル側でなく TN 側もしくは DC ファブリックやエンタープライズ スイッチ ファブリック 側に属させる方が、アーキテクチャがシンプルになる可能性があります。現状では、これらが別ドメインであるため、まず、データプレーンとしてトラフィックを識別し、適切なスライスにマッピングするための VLAN-ID 等の余計な ID を割り当て・管理する必要があります。また、ネットワーク側との接続点が Single Point of Failure/Bottleneck になるため、それを避けるために MC-LAG や制御プロトコルを駆使して冗長化する必要があります(図 5-5)。これらは、スライスの数が増えた時にそのまま複雑化とコスト増大の要因になり得るため、アーキテクチャ見直しによる効果は大きいと考えます。そこで筆者を含めたグループは、ドメイン境界見直しの必要性について、IETF DMM WG で議論を開始しました(draft-kohno-srv6mob-arch [3])。

 

図 5-4 CUPS(Reference - 3GPP TS23.501)

図 5-4 CUPS(Reference – 3GPP TS23.501)

 

図 5-5 ドメインを超えたアーキテクチャ見直しの例: UPF, gNBをネットワーク側のエンティティとする

図 5-5 ドメインを超えたアーキテクチャ見直しの例: UPF, gNBをネットワーク側のエンティティとする

 

このように、デジタル時代の新たなアプリケーションやサービスを効率的に提供するためには、ドメイン間連携のみならず、ドメインを超えたアーキテクチャを見直しも必要であると考えます。既存のドメインを踏襲するだけでは、Distributed/Edge Computing の有効活用や、データ中心アーキテクチャ(どのようなデータをどう収集・蓄積・分析するか)へのシフトは困難です。

 

5.8 終わりに

本章では、ネットワークスライシングというテーマを中心に、現在の検討状況と今後のアーキテクチャ展望について議論しました。ネットワークスライシングを、デジタル時代に真に有用なプラットフォームサービスにするためには、ドメイン間の検討のみならず、システムを俯瞰し、ドメイン境界を見直す必要があります。そしてさらに重要なのは、このネットワークスライシングを使っていかに優れたシステムを構築できるか、ということです。そのためには、接続対象となるシステムに対し良い抽象化と API を提供すること、ポリシーや ID の連携ができることなどが必要になります。この辺に関しては、第 7 章「5G/Hetnet の企業向け活用」でも少し触れようと思います。

 

←「はじめに」へ戻る

第 5 章(1)へ

第 5 章(2)トップへ

第 5 章(Appendix)へ

 

参考文献

[1] Digital Vortex – デジタル・ディスラプションによる諸業界の再定義

https://www.cisco.com/c/dam/m/ja_jp/offers/164/never-better/core-networking/digital_vortex.pdf

[2] U. Chundri et al, “Transport Network aware Mobility for 5G”, draft-clt-dmm-tn-aware-mobility

[3] M.Kohno et al, “Architecture Discussion on SRv6 Mobile User plane”, draft-kohno-dmm-srv6mob-arch

[4] C.Filsfils et al, “Stateless and Scalable Network Slice Identification for SRv6”, draft-filsfils-spring-srv6-stateless-slice-id

 

用語集

VPN : Virtual Private Network

APN : Access Point Name

URLLC : Ultra Reliability and Low Latency Communication

RAN : Radio Acces Network

CN : Core Network – Mobile Packet Core

TN : Transport Network – RANとCN、CN同士を接続するためのネットワーク

DN : Data Network – インターネット、データセンタなどのネットワーク

UPF : User Plane Function, 5GC Mobile Packet CoreでUser Plane 転送を司る Function

CUPS : Control – User Plane Separation

gNB : Next generation Node B – 5G 無線基地局

IETF DMM WG : Internet Engineering Task Force Distributed Mobility Management Working Group

 

Tags:
コメントを書く

1 コメント

  1. 5G-Cisco Thinks of Service Provider E2E Architecture Chapter 5 End-to-End Network Slicing in 5G Era (2)