モバイルにおけるハンドオーバーとは？オーバーレイとは？

モバイルネットワークの難しいところとして、利用者が移動することによる通信先の基地局の変更(ハンドオーバー)や、他の拠点の基地局のアンテナや3Gや4Gなどの既存設備を利用したエリアの冗長化(オーバーレイ)と言った、複雑なエリア設計がある。各接続先の装置特性によって技術特性が全く異なるため、モバイルネットワークの理解も、インフラ設計や監視の検討などが非常に難易度の高いものになっている。今回は、かなり乱暴になり、間違いも多いとは思うが、監視の観点でハンドオーバーやオーバーレイとは何かを解説してみたい。

ハンドオーバーやオーバーレイの必要性

結局モバイルNWのお仕事って何？のとおり、お客様が移動してもお客様の通信(専用トンネル＝ベアラ)を維持し続けることがモバイルNWのミッションとなる。そのため、モバイルとしては“通信先の基地局が動的に変わる“ことを想定しなければいけない。新幹線や自動車で移動していたとしてもモバイル通信が継続できているように、基地局の切り替えはかなり速い速度で頻繁に変わることもありえる。

そのため、モバイル網としては、お客様の端末(UE)から通信先への仮想的な専用トンネルを複数本用意するという手法を用意している。端末UEが通信している基地局の電波が弱くなると、別の専用トンネルを利用することで専用トンネルの維持を実現している。このような利用する専用トンネルの変更がハンドオーバーである。
(なお、実際に専用トンネルをどこまで事前に作っておくかは接続先や採用している技術の世代によって異なる)

この図では、異なるアンテナや異なる基地局で3本の仮想的な専用トンネルを作っている図となる。基地局の設置と、各基地局から放出アンテナの関係は様々なパターンや制約があるが、仮想的な専用トンネルを作るためには当然同一エリアに異なる設備から放出された電波が必要となる。少し古い資料となるがセル構成技術の進展のように、これらは電波特性や周波数の衝突、世代による符号化技術、無線パラメータの一貫性等様々な制約があるが、ハンドオーバーできるようにエリアを重ねたり、信頼度を上げるために他の装置によって該当エリアをカバーするような構成(オーバーレイ)にしたりする。

赤とオレンジの切替であれば基地局と端末UE間での切替となるし、赤から青への切り替えであれば交換機と連動した切替が必要となる。または、4Gのような旧世代でエリアをカバーしている場合、5Gから4Gへの世代間変更のようなEPS Fallbackのようなものもある。1つのアンテナによって提供可能なエリア(Cell)は限られているため、これらの様々な資源や設備を最大限活用することでお客様の専用トンネル＝ベアラを維持し続けなければならず、これらの例のように様々な専用トンネルの切替パターンがある。各専用トンネルの特徴や装置の繋がりによってハンドオーバーの仕組みやシーケンスは異なってくるため、ハンドオーバーはバリエーションも多く、非常に難しい技術となっている。

専用トンネルを維持＆高速化するための工夫

モバイル網は複数の専用トンネル(作成するレベル間でベアラと言ったりパスと言ったりする)を作成し、それらを切り替えることでお客様端末UEが移動しても専用トンネルを維持し続ける必要があるわけだが、切替のためだけに専用トンネルを常に維持し続けることは効率的ではない。そのため、高速化の工夫が必要となる。主な工夫としては

  • 実際にリソースを消費する専用トンネルの範囲を最小限化し残りはリザーブだけにとどめる
  • 複数の専用トンネルを使い分ける or 束ねて使う(Carrier AggregationやMassive MIMO、ULとDLの分離など)
  • 複数の装置をグルーピングすることでダイナミックなルート変更を行う(グルーピング)
  • (端末を探すための)呼び出し範囲を最適化することで専用トンネルの再作成頻度を減らす(LAI単位のPagingなど)

これらを各世代や各機能部で効率化することで、モバイル網は専用トンネルを効率化しつつ、ハンドオーバーを効率的に行えるようにしている。またこの効率化のための無線パラメータの設計や収容する基地局や交換機の設計、エリアの単位はモバイルオペレータのノウハウとなっているようだ。

オーバーレイやハンドオーバーを踏まえた監視方法

これらの仕組みを踏まえると、基地局の監視ポイントは複数出てくる。5GのgNBであれば、

  • gNBを中心とした接続性の監視: Xn, X2, NG, S1,N3 × プール内の装置数
  • サービスを監視するためのセルサービス監視: Cell、オーバーレイ、Slice(？)
これらの正常性を確認するためには、様々な監視ポイントが必要となる

  • CU & DU & RUのFault監視
  • CellサービスのFault監視
  • 専用トンネルの確立のためのRRCやSCTP 等の各プロトコルのError率
  • Slice監視のためのEnd To Endの帯域やQoEなどの監視
特に、オーバーレイなどを考慮し、どのエリアをどのようなトポロジーでサービスを提供しており、どこの故障でどのようなサービスの影響があるのか(影響がないのか)が必要になるだろう。特に基地局は数が膨大な上に、保守拠点から距離が離れていることも多々あるため、なかなかすぐに直せないことも多いだろう。そうなると、今の各エリアのサービスがどれだけの影響を受けているかを可視化することが大切になるのかもしれない。

オーバーレイやハンドオーバーはモバイルの難しい技術の一つであり、3G/4G/5GやRANやCNなどの各機能部毎に大きな機能やシーケンスの差がある。一方で、各UEからの再接続が高速化されたら、もしかするとハンドオーバーは段々不要になるかもしれない。

(参考資料)

コメント

コメントを投稿

このブログの人気の投稿

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