3GPP memo - TR38.801 V14.0.0 (2017-03)

38 series がいくつか TS (Technical Specification) になっていたので少しずつチェックしていく事に。

といいつつ、今回は TR38.801. Scope は Radio Access Architecture and Interface である。

https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3056

メイントピック

ざっと見て、議論されている部分は下記のようなところ。

  • 7 RAN Architecture and Interface
  • 8 Realization of Network Slicing
  • 10.1 Dual Connectivity between NR and LTE
  • 11.1 Function split between central and distributed unit

7 RAN Architecture and Interface / 8 Realization of Network Slicing

5G を機に、Core は Evolved Packet Core から 5G Core (NGC: Next Generation Core) へのマイグレーションが提案されている。

5G Core の特徴は下記。

  1. Slicing への対応
    • 5G では eMBB, URLLC, mMTC のユースケースが想定されているが、それらを単一のネットワークで実現するためには Slicing が必要である。
  2. CU 分離
  • Control Plane, User Plane それぞれの信号について、処理する論理ノードを分ける。
  • 具体的にメリットを述べている文献はほとんどない（TR でも明記はされていない）。

この NGC を使うか、EPC を使うかでまず選択肢が出てくる。NGC を使う場合は、新規に設備導入が必要となる。EPC の場合は、既存設備の改修で済むかもしれない。

続いて、これらの Core に gNB と eNB のどちらを接続するかというパターンが出てくる。全パターンを網羅すると、7.2 5G Architecture Options となる。

  • Option2: NGC - gNB
    • 5G として最も単純な構成
    • LTE という既存資源（オペレータ観点でいうとエリアの広さ）は全く使えない。
  • Option 3 and 3A: EPC - eNB - gNB
    • EPC と eNB が接続され、gNB はそれに付随する。
    • eNB のエリアがなければ、呼切断となる。
    • eNB から gNB に U-Plane を渡すのが Option3, EPC から直接 gNB に U-Plane を渡すのが Option3A.
    • C-Plane はいずれも EPC から eNB に渡される。
    • eNB のエリアがなければ、呼切断となる。
  • Option 4 and 4A: NGC - gNB - eNB
    • Option3 の真逆。
    • gNB のエリアがなければ、呼切断となる。
  • Option5: NGC - eNB
    • NGC が製品として出回ったころに LTE を導入するオペレータ向けと思われる。
  • Option 7 and 7A: NGC - eNB - gNB
    • Option3 の Core が EPC から NGC になったバージョン。
    • eNB のエリアがなければ、呼切断となる。

5G では 2.5GHz 以上、mmWare といった高い周波数帯を使う事から、単独でのエリア構築は心もとない。モビリティ確保の観点でいうと既存資源である LTE エリアと連続性を持たせたいというモチベーションがある。そういったオペレータにとっては、Option 3, 7 が良いだろう。

10.1 Dual Connectivity between NR and LTE

7.2 5G Architecture Options における Option 3/3A, 4/4A, 7/7A では、gNB と eNB が接続される。こうなってくると、NR と LTE 両方を使ってデータのやり取りをしたくなるというのが人情というもの。ここでは U-Plane をどの経路で流すかというところが議論されている。

eNB と gNB の連携は TS36.300 の Dual Connectivity をベースとしている。場合分けとしては 4 つが考えられる。

  • MCG で U-Plane を流す (MCG Bearer)
    • Dual Connectivity ではない
  • SCG で U-Plane を流す (SCG Bearer)
    • Option 3, 4, 7
  • MCG を経由し、MCG と SCG 両方で U-Plane を流す (Split Bearer)
    • Option 3a, 4a, 7a
  • SCG を経由し、MCG と SCG 両方で U-Plane を流す（SCG Split Bearer)
    • Option 3x, 4x, 7x

ここでいう Option 3 とか 3a とかいうのは、7.2 5G Architecture Options の Option 3 とか 3A とかとは別と考えた方がよい。後者は NGC/EPC と gNB/eNB が接続する際にどのような論理インターフェースを持つかという観点になっている。その上で、どのように U-Plane を流すかが 10.1 Dual Connectivity between NR and LTE となる。

11.1 Function split between central and distributed unit

Central Unit (CU) と Distributed Unit (DU) にノードを分けようという考えのもとで議論が行われている。CU, DU それぞれに、RRC/PDCP/RLC/MAC/PHY/RF というレイヤのどの機能を持たせるかというのがキーポイントとなる。とりあえず、全てのパターン（もっと言うと、RLC, MAC, PHY はそのレイヤ内でも）で分割させた場合のメリットデメリットを検討している。

Split の方法によっては、（CU をコアと同義と捉えると）DC の Option に近い形態となる。例えば、Option1 (1A-like split) では、RRC が CU に実装され、RLC 以下は DU に実装される。この状態で、2 つの DU に対して Dual Connectivity を実現させようとすると、CU から 2 つの DU の PDCP それぞれに対してトラフィックが流れる。これは、DC の 1A（コアから 2 つの eNB の PDCP それぞれにトラフィックが流れる）という形態と同様と捉える事ができる。

それぞれのメリット、デメリットは 11.1.2.9 Summary table にまとめられている。

  • Baseline available
    • LTE までの標準に準拠しているかどうか
    • Option 2 は 3C-like DC, Option 8 は CPRI なので、既に実装を済ませているベンダにとっては対応しやすい
  • Traffic aggregation
    • Option 1 では CU に RRC しか実装されない（C-Plane しか扱わない）ので、RAN のレベルで U-Plane を分割して複数経路で送信するという機構がない。
  • ARQ Location
    • RLC, MAC それぞれに再送制御の機構があるが、それらが CU 側にある方がロバストと言える（基地局が故障しても再送できるとか？）。
  • Resource Pooling in CU

とかとか。

（以下、後日追記）

日本国内の 5G 動向を踏まえて。

総務省の報道発表に前後して、通信事業者などで 5G に関する報道発表が多数なされた。
特に大きなものは、NTT docomo による「東京スカイツリータウン」での 5G トライアルサイトとなるだろう。

スカイツリーで5Gをいち早く体験――ドコモと東武鉄道が「5Gトライアルサイト」 - ケータイ Watch

総務省による実証実験でも、docomo のトライアルサイトでも、主としてビジネスパートナーと共にどのような協業の可能性があるかを実証実験を通じて明らかにしていくという色合いが強い。技術開発自体は装置ベンダにて盛んに行われているし、技術自体は 3GPP 標準ベースかつまだ標準化が完了していないというステータスとなっている。このタイミングで、LTE のように各社で独自に新技術導入についてアピールをしていくというよりは、まずは 5G を世間に幅広くアピールし、その可能性を広い視野で追及していくという段階になる。

そのような観点でみると、5G で何ができるか、というのが重要になる。当面は「5G = 4G よりも速く、スループットが落ちづらい」という部分がポイントとなる。なぜならば、5G の特徴として、高速大容量 (eMBB: enhanced Mobile Broad Band)、低遅延 (URLLC: Ultra Reliable and Low Latency)、他接続 (mMTC: massive Machine Type Communication) が挙げられるが、3GPP 自体は先行して eMBB の標準化完了を目指しているからだ。

NTT docomo の 5G トライアルサイトの話に戻ると、このトライアルサイトで公開されているコンテンツとしては、「リバティ車内での多ユーザ映像配信」「スカイツリーにおける4K/8K展望映像配信」と、映像配信が中心となる。また、その他の報道発表でも、映像配信関係が多い。具体的には下記の通り。

これを見て、「ユースケースとしては動画配信程度しかない」と捉えるか「動画配信を切り口に、どのようなビジネスモデル展開やマーケット展望があるか」と見るかによって、通信に関連する企業やそれを活用する企業に対する 5G への取り組み度合いが変わってくるのではないかと思う。その結果、5G が市場としてどのように発展するかが決まってくるだろう。今のフェーズは、まずは通信事業者が「どのようなサービスができるか」をパートナー企業と模索し、たたき台を作り、各業界が 5G に対して注目し議論してもらうためのきっかけを作るというところにある。

5G の行く先

What Will 5G Mean for Modern Businesses? - CommsTrader

5G の向こう 5 年程度の展望について述べられている。

5G としては、eMBB, URLLC, mMTC の 3 つのカテゴリがある。ただし、標準化の観点からも、最初は eMBB をビジネスユースケースとして想定するベンダ、オペレータが多いようだ。ただ、eMBB の次のケースとしては、URLLC が来るか mMTC が来るかは微妙なところだろう。

URLLC は 5G 特有といえるが、その分だけサービスに対する信頼性をどのように維持するか、QoS の保証をどのような形で行っていくか（また保証できないときにどうするか）といった様々な課題を乗り越えていく必要がある。自動運転や遠隔医療など、URLLC ではその制御を通信に委ねる事になる。

mMTC については、当面 IoT ユースを 5G で行うというニーズがあるか非常に微妙なところ。Cat-M や NB-IoT といった標準化が完了したばかりでこれから各オペレータがサービスを展開する事を考えると、当面は LTE をベースとしたサービス展開になるだろう。NB-IoT を超えるような端末収容ができるといったオペレータ観点での利点や、より端末管理がしやすくなるといった利用者観点での利点が一致しなければ、急速な普及は難しいだろう。

そうこうしているうちに、URLLC や mMTC は普及しないままそれ自体が陳腐化するという可能性も否定できない。NR, Cloud, Slicing など、多種多様な技術や概念の積み重なりで形成されるものが 5G だとすれば、詳細の可能性は無限大であると同時に、実態が掴めない霞のようなものに見えてしまうかもしれない。

5G News - 2017/04/09

法人向け Network Slicing

5G progress at Ericsson could help enterprises work worldwide

SK, Deutsche Telekom, Ericsson demo network slicing for 5G roaming | FierceWireless

Network Slicing のユースケース。上記リンクでは、ある企業が複数の国をまたぐようなセルラネットワーク越しに独自の（仮想的な）ネットワークを構築する事を想定している。

これまでは、様々なサービスタイプ (eMBB, URLLC, mMTC) を想定し、それら各種サービスを単一のネットワークで収容するためのソリューションとして Network Slicing が提案されていた。

Why 5G Network Slices

URLLC, mMTC では、B2B, B2B2C といったサービスの提供形態が想定される。これまでの 4G のようにあくまでコンシューマ用途メインというようなネットワークではなく、ローンチのタイミングから法人ニーズを想定したネットワーク機能の提供というのが重要になるかもしれない。

Nokia Boosts NFV

Nokia NFV orchestration plans set for boost from Comptel purchase

Nokia は Comptel という企業を買収するとのこと。

http://www.comptel.com/docs/default-source/ir-presentations-esitysmateriaalit/comptel-company-report-2016-inderes_oy.pdf

Comptel はヘルシンキの会社で、通信事業者向けに OSS を開発するなど、ソフトウェア開発に特化した会社とのこと。オーケストレータや自動化の開発も行っている。

Nokia はそこに目を付けて、NFV のオーケストレーション強化のために買収を決断したようだ。

仮想化環境では、ハードウェアとソフトウェアの分離される。これは、従来の非仮想化環境とは、設計、構築、運用の方法が大きく変わる。そのような中で、オーケストレータは重要になると踏んでのことだろう。

Network Slicing と NFV

Understanding network slicing, a key technology for 5G

Network Slicing は主にモバイルネットワークにおけるコア部分を論理的に分割する概念である。従来、通信事業者は RAN とコアネットワークをそれぞれ物理的に構築していたが、特に NFV の台頭によってそれらを論理的に区切る事が出来るようになってきた。例えば、LTE でいうと EPC 部分について今まではサービス毎に EPC を分けるためには、それぞれのサービス毎に EPC を個別に構築する必要があった。こういった事は規模の大きな事業者でしかできなかったものを、仮想的（論理的）に行おうというものである。Slice された Network はお互い別のものと認識されるので、例えば Network A の負荷や輻輳が Network B に与える影響というものが一切なくなる。

具体的な用途としては、(i) MVNO に対して個別に EPC 提供する、(ii) 法人向けに料金体系や要求品質にあった性能の EPC を提供する、(iii) 重要サービスとベストエフォート系サービスで収容を分ける、といったものが挙げられる。(iii) については、5G が eMBB, mMTC, URLLC と大きく分けて 3 つのタイプに分けられる事からも現実味がある。例えば、mMTC については予期せぬバーストトラフィックや安価な料金設定などが想定されるので、そういった「とにかく数を捌かさないといけないトラフィック」は専用の EPC に収容させた方が良い（eMBB や URLLC に影響を与えたくない）。しかし、mMTC 用に EPC を個別構築したのではコスト的に折り合いがつかなくなる。そういった観点からすると、Network Slicing を使って mMTC 用の EPC を切り出すという発想になってくる。

Network Slicing は NFV によって実現される事になるだろう。主として、論理的なネットワークの自動構築、処理性能が足りなくなった場合に処理性能を向上させる（割り当てリソースを増やす）スケールアウト、障害が発生した時に自動復旧させるためのオートヒールといった機能が活躍すると思われる。

仮想化のメリットの一つと言われていたのが集約によるコスト削減であったが、最近のトレンドは仮想化による付加価値の提供の方に寄っているように感じる。従来であれば仕方なく単一のネットワーク、単一のサービスになってしまっていたところが、仮想化（とそれを運用するために推進された自動化）によって、個別の顧客やサービスに見合ったインフラの提供が出来るようになるというのは、仮想化の大きな武器であろう。