Cisco Japan Blog / アーキテクチャ / 5G－シスコが考えるサービスプロバイダー E2E アーキテクチャ 第5章 5G 時代のエンドツーエンド ネットワークスライシング（Appendix）

第5章  5G 時代のエンドツーエンド ネットワークスライシング （Appendix）

本エントリーは第 5 章の Appendix として、ネットワークスライシングについて、業界団体や標準化団体でどのような議論が行われているかの概略をまとめたものです（2019 年中盤時点）。ネットワークスライシングというトピックについて、いかに多くの業界団体・標準化団体がその策定に取り組んでいるか、ということがわかります。ただし、一時点の非網羅的なスナップショットに過ぎず、正確な検討内容については、各団体の出版物をご参照ください。また2020年中盤時点のアップデートを 追記 として記述しています。

5.9.1 NGMN

NGMN（Net Generation Mobile Networks [1]）は、次世代モバイルネットワークに関する標準化、実用化を策定するアライアンスであり、日本からも NTTドコモが参画しています。NGMN は、5G whitepaper [2]を発行し、その中でネットワークスライシング を「共通の物理インフラ上で，仮想的に独立した事業として複数の論理ネットワークを運用する概念」と定義しています。また、「ひとつのネットワーク スライスは，仮想的に独立したエンドツーエンドネットワークと捉えられる」と、RAN、パケットコアなどのドメインを越えてエンドツーエンドで検討することの重要性を強調しています（図 5-6）。

図 5-6　共通基板上に実現されるネットワークスライス（NGMN）

5.9.2 GSMA

GSMA（GSM Association [3]）は、800 社近くの移動体通信事業者や端末製造メーカー、ソフトウェア企業が加盟する世界最大の携帯通信事業者の業界団体で、Mobile World Congress の主催でも有名です。GSMA では Future Network Program の一環としてネットワークスライシングへの手引き[4]を発行しており、その中で、ネットワークスライシングはモバイル通信事業者が SLA に準拠した特定のビジネス要件に合わせた接続性とデータ処理を提供するために必要と述べています（図 5-7）。スライシングにより、データ速度、品質、待ち時間、信頼性、セキュリティ、およびサービスなどを、顧客要望に合わせてカスタマイズ可能であるとしています。

図 5-7　各ビジネス要求に最適化された仮想ネットワーク（GSMA）

5.9.3 ITU-T

ITU-T（International Telecommunication Union –  Telecommunication Standardization Sector [5]）は、国際電気通信連合の部門の一つで、通信分野の標準策定を担当しています。ITU-T は将来のネットワークのあり方を検討する FG-IMT2020（Focus Group on IMT-2020）を設置し、そこでネットワークスライシングについても議論されました。実際の技術標準化は 3GPP 等で行われるため、ITU-T では主にアーキテクチャ概念が整理され、スライスの階層化とマネジメント、オーケストレーションとの関係が重視されています（図 5-8）。

図 5-8　ネットワーク仮想化のフレームワーク（ITU-T Y.3011）

5.9.4 IEEE

IEEE は米国に籍を置く、世界最大の電気工学、電子工学に関する学会かつ標準化組織です。IEEE 自体ではネットワークスライシングに関する標準化を行っていませんが、IEEE 主催カンファレンスである Netsoft（International Conference on Network Softwarization [6]）において、スライシングに関する特集を行っています。図 5-9 は、Netsoft で行われたネットワークスライシング Tutorial によるもので、ネットワーク スライスのタイプと、それぞれの管理責任主体について整理しています。

図 5-9　ネットワークスライシング Landscape（IEEE Netsoft Tutorial）

5.9.5 ONF

ONF（Open Networking Foundation）[7]は、あらゆるネットワークをソフトウェアで定義可能にする SDN（Software Define Network）を推進する非営利団体です。ONF では、5G スライシングも SDN の一つのアプリケーションとして定義しています[8]。図 5-10 は SDN をベースにしたスライスの抽象化を示しています。

図 5-10　SDN based Slice Abstraction

5.9.6  IETF

IETF（Internet Engineering Task Force）は、インターネットや IP に関わるプロトコルの標準化を行う団体です。いくつかの BoF や Working Group においてネットワークスライシングに関連する議論が行われています。

ACTN（Abstraction and Control of Transport Networks）[9]  BoF では、トランスポートネットワークの制御および抽象化をどのように行うかを議論しました。図 5-11 は、トラフィックエンジニアパスをどのように抽象化し、また仮想ネットワーク（VN）をどのように定義するかを示しています。

図 5-11　ACTN framework for ネットワークスライシング

さらに、複数のドメインにまたがるエンド to エンドスライスをどのようにモデル化してどのようにサービス定義するか、などを議論するため、COMS（Common Operation and Management on network Slices）[10]が、BoF として設定されました。しかし、議論のポイントを絞るのが難しく、また IETF で議論すべきなのか、という根源的な問いも提起され、一旦この BoF も終結してしています。しかし、IETF で議論すべきかは別として、このような検討は必要と思われます。図 5-12 は、COMS が検討しようとしたサービス デリバリー インターフェース、カスタマー サービス インターフェースおよびフレームワークを示しています。

図 5-12　“COMS motivation” IETF101 COMS BOF

IETF の本領は IP プロトコル周辺であり、ネットワークスライシングを構成する要素技術の多くが（L2/L3VPN、セグメントルーティング、トラフィック エンジニアリングなど）IETF で検討・標準化されています。ここではその中でも、現在セグメントルーティングを標準化する SPRING WG で議論されている Flex Algo によるネットワークスライシングの実装可能性について紹介します。

IGP Flex Algo [11]は、IGP extension により、各ノードは、そのノードが属するアルゴリズム番号、およびそのノードが持つ prefix をアルゴリズム番号に紐づけて広報します。アルゴリズムに持たせる意味はネットワークオペレータが任意に定義できますが、これをネットワークスライシングに適用することにより、ネットワークオペレータは、Slice ごとに異なるトポロジーを生成可能です。このことにより、ポリシーの適用を完全自動的に行うことができ、またパスを指定するための SID 段数も最小化することができます。

図 5-13　IGP Flex アルゴリズムによる Multi Plane の実現

なお、セグメントルーティング関連技術を利用したネットワークスライシングについては、“Building blocks for Slicing in Segment Routing Network [12] “に記述しています。

5.9.7 MEF

MEFは、以前はMetro Ethernet Forumという名称で EFM（Ethernet in the First Mile）/ Carrier Ethernet に関する標準化を行っていた非営利のコンソーシアムですが、最近では MEF と改名し、イーサネットだけを前面に出すのではなく、Optical, IP, SD-WAN, Cloud Service, LSO (Life Cycle Orchestration) などにも領域を広げています。 MEF で行われたセミナー[13]では、トランスポート スライスにおいてスライシングをどのように表現するかについて記述しています（図 5-14）。

図 5-14　Network Slice Representation

5.9.8 3GPP

3GPP（3^rd Generation Partnership Program）は、モバイルブロードバンドの標準化を司る標準化団体です。団体名称は 3GPP ですが、3G だけでなく 4G、5G の標準化も行っています。3GPP では、5GC Architecture（TS 23.501）を中心に、ネットワークスライシングの定義を行っています。3GPP における検討の対象は AMF, SMF, UPF, PCF などの Mobile Gateway Node であり、スライスの定義をまとめると下記のようになります。

• 動的に作成される論理的なエンドツーエンド 根とワークである
• ネットワークスライスは、RAN 部分と CN 部分から構成される
• UE は複数のスライスにアクセスすることができる
• 各スライスは、SLA で合意したサービスタイプを提供する

図 5-15 に示すように、Mobile Gateway は共有または分離され、どのように Gateway Node もしくはスライスを選択するか、ということが検討の中心です。

図 5-15　3GPP におけるスライス [14]

また、3GPP ではスライス識別子を定義しています。スライス識別子（S-NSSAI, Sub Network Slice Selection Assist Information）は、スライスサービスタイプ（SST）およびスライス区別（SD）から構成され、ネットワークスライスの識別・選択は、S-NSSAI を介して行われます。 UE は最大で 8つまでの S-NSSAI を持つことができます。代表的な SST 値として下記が定義されています。

RAN においても、スライシングの議論が行われています。UE からどのようにスライスを選択するかが主なポイントです。UE からダイナミックに指定する、予め UE を特定のスライスに登録しておくなど、いくつかの方法が検討されています。特に無線区間は、リソース（Spectrum）が限られており、また Handover などのケアが必要なため、効果のあるスライス範囲を吟味し、複雑化させないための検討が必要です。

図 5-16　Radio Access Networkにおけるスライス選択例（TS 38.300）

5-9-9 ETSI ISG NFV

ETSI ISG NFV は、ETSI（欧州電気通信標準化機構）においてネットワーク機能仮想化に関する、特にオーケストレーション周りの標準化を行うために発足されたグループです。 NFV Framework においてネットワークスライシングをどのようにサポートするかが主要テーマですが、NFV release 3.0 にて、エンドツーエンド ネットワークスライシングに必要となる「NFV におけるネットワークスライシングのサポート」、「複数の管理ドメインのサポート」、「複数サイト間のネットワーク接続性」をカヴァーすることを発表しました[15]、[16]。

図 5-17　ETSI NFVフレームワークにおけるネットワーク スライス マネジメント（ETSI GR NFV-EVE 012）

←「はじめに」へ戻る

第 5 章（1）へ

第 5 章（2）へ

第 5 章（Appendix）トップへ

参考文献

[1] https://www.ngmn.org/

[2] NGMN 5G whitepaper v1.0

[3] https://www.gsma.com/

[4] GSMA “An Introduction to ネットワークスライシング”

[5] https://www.itu.int/en/ITU-T/Pages/default.aspx

[6] http://netsoft2019.ieee-netsoft.org/

[7] https://www.opennetworking.org/

[8] ONF TR-526: “Applying SDN architecture to 5G slicing”

[9] https://datatracker.ietf.org/wg/actn/about/

[10] https://datatracker.ietf.org/wg/coms/about/

[11] draft-ietf-lsr-flex-algo

[12] draft-ali-spring-ネットワークスライシング-building-blocks

[13] MEF 3.0 & The Road to 5G

[14] https://sdn.ieee.org/newsletter/december-2017/ネットワークスライシング-and-3gpp-service-and-systems-aspects-sa-standard

[15] Report on ネットワークスライシング Support with ETSI NFV Architecture Framework

[16] https://www.etsi.org/newsroom/press-releases/1622-2019-07-etsi-nfv-announces-new-features-to-its-architecture-to-support-5g

Authors

Miya Kohno

Distinguished Systems Engineer, CTO for GSP Japan