英語が苦手でもグローバル人材を目指して

基地局編 と 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と処理ロジック...

今回のNFV#35(9/13〜22)もコロナの影響でeMeeting (電話会議による会議)となった。今回はNFV-Workshopのようなイベントは無かったようだが、いくつかの仕様検討は大きく進んだ。 最新のNFV仕様の全体像は こちら (ETSI-NFVのOpen area)で、前回NFV会合の説明は NFV34の会合サマリ を確認して頂きたい。 NFV#35のサマリ NFV#34と比較した重要な活動結果としては、 Release3のed351がPublishになった。 Release4のStudyが多数完了フェーズになり、今後Normativeに移行する。 Release5のNew Work Itemが承認され、活動が開始された。 コンテナ関連はあまり進んでいないが、新Usecaseや新機能に関するStudyが多数完了して、これから新しい機能に関するアーキテクチャの検討や機能分担が開始されそうだ。 Release3：LCMの高度化 IFA&SOLの第2版(ed351)がPublishされ、サポートするVNF関連の機能について大きな進展があった CoordinateLcmOperationが仕様化され、FEAT02 VNF Upgradeが完了した。ed361に向けた残機能はFEAT03 NFVI UpgradeとWIMのNorth Bound Interface (NBI)のみとなる。 SOL017 MSCS (Multi-Site Connectivity Service) stage 3 reportが完了し、IETF ACTNベースでWIM NBIが開始予定。 VipCpの導入によりVirtual IP address (VIP)がNFV-MANOでも管理可能となり、NFV-MANOがサポートできるVNFのNWの幅が広がった。 Rel2までは主にMAC Address＋VLAN (L2)のLinkのみがNFV-MANOの管理対象であり、IPアドレスはConfiguration(設定情報でありNFV-MANOの管理対象外)だった。そのため、例えばVNFC間で冗長構成になっていた場合も、その数だけExtCpが必要となるような管理方法だった。 Rel3からはVipCpを利用することで、複数のVNFCでVIPを共有するVRRPのようなNWも記述可能になっ...

引き続きテレコムアプリ(Network Function)の特徴と監視方法についてまとめてみた。今回はNFの監視機能部であるEM(Element Manager)についてまとめてみた。 EMの役割 テレコムアプリ(NF)はユーザに安定した通信を提供するため、長期間NFを動作させ続けるという要件があり、「 モバイルネットワークの保守運用の基礎 」のようなテレコムアプリの運用やメンテナンスのための様々な機能が実装されている。基本的な考え方はFCAPS (Fault management / Caonfiguration management / Accounting management / Performance management / Security management)となるが、近年はここにProvisioning + LCM (LifeCycle Management)やProve監視といった運用方法が追加されている。 EMのFCAPSの実装例 Open Sourceも含めて一般的にFCAPSは3つの機能とAPI GW(Gateway)で実装されていることが多い。 Data Collection: 監視対象からLogや信号を集める 通常のLinuxであればSyslogやSNMP、HW関連であればIPMIやRedfishなどを利用してDataを集めることが多い 昔であればvmstat + tail -f /var/log/messageなどを利用することが多かったと思うが、最近はZabbix Agent / Prometheus Exporter / SNMP agentなどのツール、更にはiLoやiDracなどの管理用の専用HWなどを利用することが多い 3GPP-SA5やNFVだとLog (FM/SM)やReport (PM/AM)と呼ばれ、実際にFM/PMなどで管理される情報の元ネタ相当となる Data Analysis: 集めた信号からコンポーネント単位の状態変化を判定し異常状態の有無を管理し、Alarm発生/回復を判断する 各管理コンポーネント(Managed Object)とマッピングされ、各MOの状態を生成する。障害時は1のCollectionが情報欠損することが多いため、SynchronizationやAuditの機能を保持していることが多い。...