テレコムアプリの実装の特徴と監視方法③ 〜交換機＆Cloud Native編〜

基地局編とEM編の続きである。

交換機

電話交換機とは、電話が繋がる仕組、VoiceのPBXの主要メーカー4社比較を見て頂くと、交換機の基本的な役割が分かるだろう。

装置構成

交換機はモバイルに求められる要件に応じて、アーキテクチャが大きく変わってきている。論理エンティティとしての機能分担は3GPPの仕様を確認頂くとして、ここでは監視の観点で主な機能部の種類を紹介する。

  • 加入者DB: UE(端末)や契約者の顧客情報に関するネットワーク上のマスターとなるDB
    • サービス加入状況等の契約情報、UEの認証情報やデバイス情報、位置情報
    • 4GまではHSS、5G以降はUDM/UDR
  • マルチメディアサービス: 交換処理の上で契約情報に基づいてテレコムサービスを提供するApplication群
    • 基本呼制御、QoS制御、トーン/アナウンス、音声通話、留守番電話
    • 3GまではMSC内だったが、交換機のIP化の頃からIMS
  • 他網接続: 他網へ接続し各種プロトコルを終端
    • 固定網(PSTN/ISDN)、インターネット(PDN)、他モバイル網(PLMN)
  • 交換処理: 交換機としてUEからの通信の接続先を切り替える中心処理
    • 3GはMSC
    • IP化に伴ってパケット交換処理部はGSN
    • 4GではEPC
    • 5GではU-PlaneをUPF、C-Planeを5GCの他の論理機能部が担当
  • 無線通信の終端: 無線からの信号を受けて無線通信を終端

従来のUE〜UEを擬似的な専用線で接続する“回線交換“から、徐々にインターネットへ通信するためのパケット転送に最適化された機能部に変化している。特に5Gでは、C-PlaneとU-Planeを分離することで、大容量のデータトラヒックに耐えられる思想になっているようだ。

監視方法

『スマートフォン時代の大容量通信を支える新3Gコアネットワークパケット処理ノードの開発』(NTT DOCOMO Technical Journal)や『NECのUPF』を見る限り、交換機の実装は、U-Plane系の処理(U-Plane processor)はRouterに近い実装となっており、O&M機能部やC-Plane系(Protocol termination)はIT系の実装に近い実装となっていることが多いようだ。

一般的なIT系技術の実装と異なる点は、DBと処理ロジック部が分離されているわけではなく、接続の維持のために各コンポーネントがデータを保持している点だろう。そのため、一般的に各処理部はAct-Sby構成になっており、Act-Sby間でデータの同期やHearbeatを行なっている。

O＆M機能部は『テレコムアプリの実装の特徴と監視方法②〜EM編〜』の通り各U-Plane processor、Protocol termination、LBの障害管理(Fault mgmt)、トラヒック管理(Performance mgmt)、課金情報の出力(Accounting mgmt)を行なっている。また、O＆M機能部はEMから指定された接続先情報やネットワーク情報の設定を管理設定(Config mgmt)も行なっている。

Cloud Native時代に向けた監視の課題

従来の交換機は、物理的なラックのようにStaticな構成だったため、O＆M機能部を中心としたStatic Configurationをベースにした監視運用方法が主だったように見える。しかし、Cloud Native時代になると仮想化基盤(NFV-MANOやNFVI)が動的にコンポーネントを起動したりネットワークトポロジーを変えてしまうため、Dynamic Configurationになる。この結果、監視のポイントや手法も大きく異なることになる。

Dynamic Configurationになることで、監視上の課題としては

  • “正しい”Configurationが分からない
    • 仮想化基盤が勝手にNF(Network Function)を起動/停止するため、どのNFが起動/停止しているのが正解か不明
    • どのNF同士が接続されるかの正解が不明
    • 冗長構成としての設備がどれか分からないので、冗長設備が機能しているか不明
  • 共有コンポーネント(PaaS/CaaS/NW設備等)の監視方法と責任分担のベストプラクティスが未成熟
    • ServiceMeshやLBのRouting情報の管理を担当する装置が不明
    • 問題発生時の切り分け方法が不明
    • そもそもPaaS/CaaSの監視方法が標準上も未成熟
  • ネットワーク全体の性能や能力が不明
    • Scale前提のため、ボトルネック箇所がどこか不明
    • NFが動的変更になると、“今“どんなKPIを監視すれば良いのか不明
    • 障害発生後の復旧時にどうやって再度組み込むのかベストプラクティスが未成熟

(参考)実装例



最近の交換機は、従来の回線交換型の交換機から、IT系装置と似たような実装になってきている。そのため、監視方法もIT系の機能を今後利用できるようになっていくだろう。しかし、総務省『論点整理』のとおり監視を行うのは人なので、複数世代のネットワークを監視運用できる人材の確保は今後大きな課題になるかもしれない。

コメント

コメントを投稿

このブログの人気の投稿

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...
続きを読む