テレコムアプリの実装の特徴と監視方法① 〜基地局編〜

テレコムAPLが具体的にどのように実装されているか、それに伴う監視ポイントがどこかがまとまっている資料がないので、公開情報からまとめてみた。今回は基地局である。

基地局

@DIMEの「携帯電話基地局の仕組み、設置料、メーカーなど知られざる秘密、こっそり教えます」や「携帯電話のしくみ」、「結局モバイルNWのお仕事って何？」を参考にして頂きたいが、一言で基地局と言っても複数の構成からできている。

装置構成

  • 無線
    • 装置と言って良いか分からないが、モバイルにおいては端末UE(User Equipment)とネットワークは電磁波を利用した無線で通信される。そのため、電磁波の物理的性質に基づいて「電波の特性」のような性質がある。
    • 無線は電磁波を利用して信号を運ぶため、周波数×時間×電力(振幅)を組み合わせることで限られた無線リソースを複数のユーザで共有する。
    • 電磁波に情報を載せるため、電磁波の振幅を加工する変調技術と、誤り訂正(FEC)や信号の再送(ARQ)を行うための符号化が行われる。こちらの論文「無線通信方式の基礎」がよくまとまっている。
    • これらの無線は特定の周波数(キャリア)毎にセルという単位で制御し、電磁波の放射エリアに指向性を持たせセクタを構成することで、他のセルの干渉を最小化したり、1セルのエリアを小さくして1セルあたりの収容ユーザ数を限定させたりして、限られた無線リソースを効率的に利用している。
    • 第2世代、第3世代、第4世代、第5世代・・・とは、これら無線リソースの共有方式や符号化技術を改良することで、限られた無線リソースで大容量の信号を運べるように改良している。
    • 異なる周波数(キャリア)のセルを重ね合わせる(オーバーレイ)によって、基地局やアンテナの故障への耐障害性を高めたり、キャリアアグリゲーションによって複数のキャリアと同時に通信することで通信速度を高めたりしている。
  • アンテナ
    • 無線の送受信を行う基地局の装置RRE(Remote Radio Equipment)であり、端末(UE)と基地局が通信するモバイルの要の装置である。
    • 一様に広がりがちな無線の放射に対して特定のエリアのみに無線を放射できるようにビーム性を持たせ、アンテナではこのビームの角度(チルト角)を制御している。
    • MIMO(Multiple Input and Multiple Output)によって送信機(基地局)と受信機(UE)でそれぞれ複数のアンテナを利用し、通信速度を向上させている。2×2 MIMO、4×4 MIMOとは基地局とUEがそれぞれ2本、4本のアンテナを搭載した通信方式である。5Gでは更に発展しMassive MIMOというビームフォーミング技術と大量のアンテナを利用し、更に通信速度を向上させている。
    • アンテナは設置場所によって、無線を放射するアンテナ、Duplex、光-電気変換器/電気-光変換器(EO Converter/OE Converter)、分光器の一部または全部が入っている。
    • アンテナが基地局本体から離れているときは増幅器(AMP)が必要となる。
  • 伝送
    • アンテナは設置場所(ビル、トンネル、鉄塔等)や該当エリアのユーザ数によって様々な条件があるため、RoF(Radio Over Fiber)によってアンテナ部と基地局本体を引き離して設置することが多々ある。RoFは2G/3Gなどの方式やアンテナの設置方法によって、MOF(Multi-drop Optical Feeder)やIMCS(Inbuilding Mobile Communication System)、OA-RA(Open Air Receive Amplifier)、OF-TRX(Optical Feeder Transmitter and Receiver)等、様々な機器で延伸している。
    • 4G以降はCPRI(Common Public Radio Interface)やeCPRI(enhanced CPRI)が利用され、O-RANでもFront Haulとして共通かされつつある。
  • 基地局本体
    • 無線によって受信した信号の符号化を解析し、ユーザ単位に信号を分割・パケット化してネットワーク(コアノード)へ送信いる基地局本体である。
    • アンテナから届いた信号を分離＆ネットワークからの信号を多重化するCPRI-MUX(CRPI MUltipleXer and demultiplexer)、アンテナと送受信するTRX(Transmitter and Receiver)があり、伝送と接続している。
    • 符号化された信号をパケット化するベースバンド処理部BBがプロトコルの終端処理(MACやPHY)、FECやARQなどの受信信号の解析、AMCなどの送信信号の最適化を行なっている。各処理共に収容しているユーザ数分同時に処理する必要があるため、厳格な時間制御(Time sensitive処理)が必要であり、どのように実装置として分離するかは実装依存と思われる。
    • UEと基地局はUE単位で上り(基地局がreceive)と下り(基地局がtransmit)の通信があり、それぞれチャネルという概念で分離して通信される。チャネルの考え方は3G/4G/5Gでそれぞれ異なるが、5Gでは以下のような考え方で音声とパケットを統合しつつ状態遷移をシンプルにしたチャネル構成になっている。
      • 物理チャネル: 符号化された信号のうち、時間により多重化された無線フレーム(10ms周期)の中のチャネル。
      • 伝送チャネル: 物理チャネルのPDSCHやPUSCHを利用して論理チャネルと物理チャネルを対応づけるチャネル
        • 下り共通(DownLink Shared CHannel): 下りの共通データ通信チャネル
        • 報知(Broadcast CHannel): 下りのシステム全体の情報をUEに通知する共通チャネル
        • 呼び出し(Paging CHannel): 下りのUEを呼び出すための共通チャネル
        • マルチキャスト(Multicast CHannel): 下りの共通データ通信チャネル
        • 上り共通(UpLink Shared CHannel): 上りの共通データ通信チャネル
        • ランダムアクセス(Random Access CHannel): 上りの通信開始時の同期通信チャネル
      • 論理チャネル:
        • C-Plane: 報知制御BCCH、呼び出し制御PCCH、共通制御CCCH、マルチキャスト制御MCCH、個別制御DCCH
        • U-Plane: 個別トラヒックDTCH、マルチキャストトラヒックMTCH
    • BBによって抽出された信号はプロトコルやチャネル毎にCNTによって呼処理シーケンスとして構築される。
これらをまとめると、典型的な実装イメージとしてはこのようなイメージになるだろう。性能や実装方法によって異なるだろうが、基本的にはセル - アンテナ - TRXの単位で複数インスタンス化可能であり、BBは収容するユーザ数によって複数インスタンス化することになるだろう。

実際にはRemoteに何を置くかによってどの機能部がRREに存在し、何がBDEに残るか変わるだろう。また、限られたスペースや部材で複数世代の無線に対応できるように3Gと4Gでアンテナを共用しているケースもあるため、実際の装置接続はこの図から様々なバリエーションが派生するだろう。

5Gになると、BDEがDUとCUに分割されるため更に実装バリエーションが増えるかもしれない。

監視方法

基地局の監視の難しいところは、実態のない“無線“も監視する必要があることだろう。無線エリアはちゃんと狙ったUEと通信できているかの確認が必要となるが、UEは移動するためHeartbeatのようなことを実施できない。そのため、「Sliceを管理するために必要な管理機能部」の説明のTestやPMが重要になっており、3GPPでも仕様規定されている。Testにおいては大きく2種類の試験が考えられ、テスト対象のUEのTracerouteと、エリア配下の試験用UEへのTest Callがある。PMについては、トレンド分析のようなものを行うことで、無線が正常に機能しているかを監視する方法がある。これらの実現のために、CNTはTraffic Itemとして各信号の処理数や失敗率をカウントしているようだ。

無線以外のアンテナ、伝送、基地局本体については物理装置のためHeartbeatやログによる監視が可能であるが、ここには2種類レイヤの監視が必要である。一つは各装置自体のHeartbeatやログ監視、もう一つはチャネルやセルなどのサービスの監視である。3GPP SA5のFMの仕様にはこれらの詳細なAlarmの仕様は規定されていないが、実際は装置とサービスの両方の障害をHeartbeatとログから分析し、FMを管理する必要があるだろう。

まとめると

  • Test: 無線エリアの正常性確認のためにUEと正しく接続できているかの確認
  • PM: 無線エリアの正常性や品質確認のために各信号処理をカウント
  • FM: 物理装置部分とサービス部分に対してHeartbeatやLogをベースにAlarm監視
  • Update: 物理装置部分とソフトウェア部分があるため、ソフトウェア部分のConfigの変更
  • 制御: 各装置やサービスの状態変更やリセット制御、チルト角の制御

(参考)実装例


テレコムの実装を調べてみると、内部の実装自体はシンプルだが、性能(特にTime Sensitive処理)を向上させるために物理HWで対応している範囲が広そうだった。とはいえ、アンテナを除けばCPU処理でも対応可能な内容ばかりだったので、今後仮想化やIAサーバ化が始まると実装方法は変わっていくかもしれない。

コメント

  1. Tanahashi2021年8月31日 20:51

    ＞PM: 無線エリアの正常性や品質確認のために各信号処理をカウント
    FM: 物理装置部分とサービス部分に対してHeartbeatたLogをベースにAlarm監視

    すごく参考になります。PMは特に何をもって、KPIや、ALMを上げてるのか、感覚がないと理解が難しかったので、勉強になりました。

    基地局本体のご説明もとても分かりやすかったです。　

    返信削除
    返信
    1. Yuya Kuno2021年8月31日 21:18

      コメントありがとうございます。PMは何をカウントしているかイメージにしくいと思いますが、3GPP-SA5のKPIと、RANベンダー様の実装形態のドキュメントなどを繋げていくと、このような考え方になるかと思いました。
      監視や保守運用については公開ドキュメントが少ないので、なかなか想像しにくいとは感じましたし、今回も様々なドキュメントを調べてかなり苦労しました。

      削除

コメントを投稿

このブログの人気の投稿

CISMとは？CCMとは？NFVでコンテナ管理はどうやるの？

イメージ
ETSI-NFV仕様の各Release機能 の通り、ETSI-NFVのRelease4ではコンテナの制御が追加される。Release4は IFA039のSBA の影響でService Baseの仕様が入っており、ETSI-NFVにおけるコンテナ管理は様々なバリエーションがある。そのため、どのように各仕様を使うかを理解するのは非常に難易度が高いだろう。なお、コンテナとは何か？については こちら を参照して頂きたい。 Kubernetesによるクラウド管理 Kubernetesは、コンテナという技術と各種管理機能を使ってプログラム(APL)を抽象化し、クラウド上でAPLを制御するフレームワークとそれを支える管理機能群である。ここでのクラウドとは、APLを抽象化することでインフラの制御を含む様々な資源を共通機能化し、それらをAPIでソフトウェア的に制御できるようにしていることだが、それを仮想化とクラウドの違いから図でまとめてみた。 仮想化だけした場合(単純仮想化)は、基本的にはAPLは物理装置自体と同じ構造であり、それをインストールしたり故障時の修理をしたりする作業も物理装置と同じ手順が必要だった。しかし、せっかくAPLを仮想化によりソフトウェア化し、HWとの依存関係を無くしている(抽象化している)ので、例えば初期構築やHW故障時の対応をAPI化したい。これがIaaS(Infrastructure As A Service)と呼ばれ、サーバやNW機能の一部を管理機能(ETSI-NFVの場合はVIM)で制御できるようにしている。これにより、物理装置の変更に伴う各種作業は削減され、VMだけ考慮すればよくなった。さらに一歩進んで、LBやDBなどの共通機能をインフラの一部として提供する(PaaS)ことで、HWに依存しない新しいタイプのAPLとプラットフォームへ進化することができ、この“何か分らない雲のようなところにリクエストを出すとサービスを得られる“というものがクラウドである。 Kubernetesは、このクラウドの効果を最大化するために、APLの範囲を最小限化している。 Kubernetesの世界では、APLはDataを持たず、Logicのみをコンテナとしてカプセル化しPodという単位で管理することで、外部から容易かつ高速に起動/停止が可能となっている。そのため、APLの冗長...
続きを読む

モバイルネットワークの保守運用の基礎

イメージ
O-RANや Sliceの管理 によって、最近モバイルネットワークの保守運用が脚光を浴びるようになってきた。しかし、運用方法や保守系装置は“オペレータやベンダ毎に異なる領域“というイメージであり、なかなかまとまったドキュメントや資料が見つからない。 保守運用の基本 これまでネットワークの保守運用のデファクトや標準仕様と言えばTM Forumの eTOM 程度しか無かったと思う。eTOMや各種標準化機能やOpen Sourceを踏まえると、大きく以下のような考え方がありそうだ。 保守運用のプロセス strategy： 新サービス導入やユーザの利用状況を踏まえた設備計画 保守運用の観点から見るとfulfillmentのInput情報 fulfilment(fulfillment)：設備計画に基づいたネットワーク装置(NF)や、それらを接続するネットワーク(NW)の設計・工事 assurance：運用しているNFやサービスの監視や復旧、更新作業 4Gまでの保守運用というと、assuranceを指すことが billing：利用状況に基づいた課金 保守運用の観点から見ると運用結果のOutput 保守運用レイヤ Business Management System (BMS)： 顧客の契約情報を管理 一般的にBusiness Support System (BSS)を利用 Service Management System (SMS)： 提供サービスの管理運用 Network Management System (NMS)： (サービスを実現する)NFの接続性の管理運用 4GまでのOperation Support System (OSS)と言うとNMSのことを指すことが多かったようだ Element Management System (EMS)： NF自体の管理運用 NFのFCAPSと言えば、EMSのことを指すことが多い 一般的にネットワークの保守運用というと、EMSまたはNMSのレイヤのfulfilment＋assuranceを指すことが多いように感じる。しかしながら、システムによる実装と人手での運用という観点では、4GまではEMSのassuranceまでを実装し、残りは手作業ということも多かったようだ。規模が大きな企業では、NMSやSMSの一部を取り入れてOSSを導入し...
続きを読む

VNFMとは？

仮想化された交換機等のテレコム設備(VNF: Virtualised Network Function)の管理機能部としてETSI-NFVではVNFM(VNF Manager)が定義されている。VNFMの主な役目として VNF LCM を行うというものがあるが、VNFMが入ることでNFVOやVIMとの機能的な違いが分かりにくくなっている。VNFMの役割とは何だろう？ ETSI-NFVにおけるVNFMの役割 ETSI GS NFV-MAN 001 の過去の提案資料(寄書)や議論状況を見ていると、どうやら以下のような考え方で機能部を検討してきたようだ。 テレコム設備(Network Function)の仮想化(VNF) Compute/Storage/Networkの仮想リソースプール化(NFVI: NFV Infrastructure) 複数のNFVIの管理/クラウド化(VIM: Virtual Infrastructure Manager) 複数のVIMのキャパシティ管理と既存保守機能部(OSS: Operation Support System)の接続と自動化(NFVO: NFV Orchestrator) 既存のNFのOAM部(EM: Element Manager)やVNFの仮想化に伴う不足機能の補完(VNFM) MAN001の議論状況だけ見ると、上記の通りNFVOとVIMしかなかったようだ。MAN001の発行直前に、既存のVNF/EM/OSSと新機能部であるNFVO/VIMの不足機能を補完するためにVNFMが定義されている。 問題はこの“不足機能“とは何かが不明瞭なため、VNFMは様々な機能部との境界ラインが曖昧になってしまっている。 VNFMの機能 ETSI GS NFV-IFA 010 を確認すると、VNFMが保持する機能としてはVirtualised Resource (VR) Mgmt、VNF  LCM、VNF Config Mgmt、VNF Info、VNF FM、VNF PM、VNF Indicator、Policy Mgmt、Snapshot Mgmt、VNF workload Mgmtがある。VNF LCMやVNF workload Mgmtは NFV-Tacker workshopのレポート「NFV＃34会合サマリとNFV-Work...
続きを読む