グローバルな接続性の基盤である電気通信業界は、5G、IoT(モノのインターネット)、クラウド・コンピューティング、AIなどのイノベーションによって推進され、技術的な再考を強いられています。その結果、ネットワークの管理はますます困難になってきました。日常的なタスクを処理し、ネットワークのヘルスを監視し、問題にリアルタイムで対応するには、オートメーションが必要です。しかし、通信サービス・プロバイダー(CSP)内の既存のスキルセットは、このような動的な状況で進化する需要と一致していない可能性があります。CSPが現代で成功するためには、データの解釈とオペレーションのためのデータサイエンティスト、ベンダーのアプリケーション・プログラミング・インターフェース(API)によるオートメーションのためのソフトウェア開発者、サービスの信頼性を確保する閉ループ設計のためのサービス保証エンジニアなど、多用途なチームが必要です。
CSPは、多様なエクスペリエンスを持つチームを構築することでギャップを埋めると同時に、同時にトレンド上の大きな進歩からもメリットを受けています。プログラミング言語はローコード/ノーコード・パラダイムに向けて進化し、生成AIの出現により、基盤モデルがタスクの自然言語記述に基づいて正式なコードを生成できる段階に達しています。これにより、意図ベースのネットワーク(IBN)の概念に新たな視点が生まれました。IBNでは、人間の管理者が「意図」と呼ばれる自然言語で高レベルのネットワーク目標を表現し、これらの人間の意図が自動的にネットワーク・ポリシーと構成に変換されます。IBNはネットワーク管理を改善する可能性を秘めており、通信企業内の人材ギャップに対処する上で大きな変革となる可能性があります。それをさらに一歩進めて、自律ネットワーク(AN)は、意図をインプットとして利用し、状況の進化に応じてネットワークを自律的に自己構成、自己最適化、自己修復することを目指しています。
IBNとANの両方にとって明るい未来が構想される一方で、実現可能性とプログラム・アプリケーション(意図の表現、ネットワーク構成への正確な変換、システムの透明性、複雑さなど)については根強い懸念があります。このブログでは、実用的なアプリケーションの可能性を掘り下げ、その過程で遭遇する可能性のある課題を分析します。
CSPチームとネットワーク間のやり取りを合理化する必要性を理解するために、新しいサービスのデプロイメントを例に挙げます。
CSPネットワークのオペレーションは、TMFが発行した「Autonomous Networks Technical Architecture」の入門ガイド1230(IG1230)に概説されている仕様に従って自動化されていると想定しています。その記載によると、CSPのOSSは(1)サービス・プロビジョニング、自動プロビジョニング、自動テストのためのオーケストレーター、(2)データを収集し、ネットワークの状態に関する洞察を作成し、閉ループ制御の状況でデータ駆動型の意思決定を容易にするネットワーク・インベントリーを備えた保証システム、(3)事前定義されたポリシーを使用してネットワークの動作を制御し、より広範なCSPのポリシーとの整合性を確保するポリシー管理者を有しています。一言で言えば、自動化されたオペレーションは、割り当てられた人間が設計したTOOSCAサービス記述子、構成、ポリシー、そして設計時にサービス設計者によってインテリジェンスと意思決定が追加される命令的なワークフローとの緊密な結合を中心に、展開しています。サービス設計者は、ネットワークで発生する可能性のある幅広い状況を事前に予測し、その対処方法について詳細な指示を与える必要があります。ゼロタッチ・エクスペリエンスは、将来の状況が予測され、それらに対処するためのポリシーがある限り達成されます。
当社では、サービス設計、サービスのインスタンス化、サービス保証というサービス・ライフサイクルのさまざまな段階に対して、0日目、1日目、2日目という用語を使用します。
図1:0日目のサービス設計プロセス – サービス資産の設計
図2:0日目/1日目/2日目のインタラクション
要約すると、新サービスの指示をネットワークに与える必要があるため、設計フェーズではかなりの量の手作業が必要になります。
IBNでは、CSPがネットワーク内で達成したい高レベルの目標を指して「意図」と言います。前述したように、0日目のオペレーション中に複雑な低レベルのネットワーク構成を扱う代わりに、エンジニアリング・チームは意図を用いて目標を表現し、意図を支えるロジックによってその意図の目的を達成するために必要なネットワーク構成に変換します。
ネットワークに設定を適用した後、ANはデプロイされたサービスを継続的に監視し、設定を適応させることで、オペレーションが指定された意図に沿ったものであることを確認します。ANは、意図の使用を「2日目」のオペレーションに拡張します。
次に、意図が意図以前の時代から確立された慣行に革命をもたらす可能性のある側面をいくつか紹介します。
対処すべき主な課題は2つあります。
TM Forumは、高レベルのネットワーク・インテントを定義するための構造化されたフレームワークを提供するTMF921 Intent-based Networking APIを導入しました。TM Forumは、意図を「意図とは、技術システムに与えられる要件、目標、制約を含むすべての期待の正式な仕様である」と定義しています。しかし、その一部の正式な仕様では問題が発生します。ネットワーク・エンジニアは、意図の概念の可能性を最大限に活用するために、この正式な言語に精通する必要があるからです。さらに、正式な仕様を備えた意図は、必ずしもそれとともに提供されなければならないパラメーターの数を減らすわけではありません。この側面で、通常IBNに関連するネットワーク管理の予想される合理化が課題となります。
さらに、意図の仕様を形式化することで、意図解釈のロジックを保持するIBNの中核コンポーネントである意図ハンドラーは、意図形式言語の決定論的インタープリターにすぎなくなります。ここで生じる疑問は、人間が潜在的なネットワーク状態をすべて予測し、その解決のための具体的な指示を出す必要のない宣言型の運用方法を備えた自律システムへと意図ハンドラーをどのように進化させるかという点です。そうでない場合、システム運用は自動化から自律化(TMF IG1230)に正常に移行できません。
今後のブログでは、IBNとANの課題と機会について、より詳しく取り上げます。ぜひご覧ください。