JP7447339B2

JP7447339B2 - サービス管理およびオーケストレーションにおける通信方法、および、システム

Info

Publication number: JP7447339B2
Application number: JP2023088942A
Authority: JP
Inventors: 致▲ウェ▼ 蘇; 佩萱林
Original assignee: 光寶科技股フン有限公司
Priority date: 2022-10-11
Filing date: 2023-05-30
Publication date: 2024-03-11
Anticipated expiration: 2043-05-30
Also published as: ES3055260T3; EP4203415C0; CN115835178B; JP2023109988A; US20230189193A1; EP4203415B1; EP4203415A3; US12389360B2; EP4203415A2; CN115835178A

Description

本発明は、オープン無線アクセスネットワーク（ＯｐｅｎＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ、Ｏ－ＲＡＮ）技術に関するものであって、特に、サービス管理およびオーケストレーションにおける通信方法、および、システムに関するものである。

全ソフトウェアライゼーション（ＳｏｆｔｗａｒｉｚａｔｉｏｎｏｆＥｖｅｒｙｔｈｉｎｇ）は、近年、ネットワーク、計算、通信領域において、受け入れられるようになった概念である。近年、ソフトウェア無線（ｓｏｆｔｗａｒｅ－ｄｅｆｉｎｅｄｒａｄｉｏ）の理論から、次第に、モバイル通信ネットワーク中で実施されるようになっていて、ソフトウェアライゼーション（Ｓｏｆｔｗａｒｉｚａｔｉｏｎ）、仮想化（Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）、および、ネットワーク機能の分解（ｄｉｓａｇｇｒｅｇａｔｉｏｎｏｆｎｅｔｗｏｒｋｉｎｇｆｕｎｃｔｉｏｎａｌｉｔｉｅｓ）等のキー実現技術（ｋｅｙｅｎａｂｌｉｎｇｔｅｃｈｎｏｌｏｇｉｅｓ）に基づいたソフトウェア定義のセルラーネットワーク（ｓｏｆｔｗａｒｅ－ｄｅｆｉｎｅｄｃｅｌｌｕｌａｒｎｅｔｗｏｒｋ）は、すでに、Ｂ５Ｇ／６Ｇをサポートし、高速ネットワーク最適化を実行することができる未来の主要技術としてみなされている。これまでの４Ｇネットワークは、ブラックボックス（ｂｌａｃｋｂｏｘ）の形式で設計され、未来の高度に柔軟な配置条件に耐えることができない。多くのテレコム事業者は、次第に、彼らの注目を、オープン無線アクセスネットワーク（ＯｐｅｎＲＡＮ）の研究と実現に向けている。オープンユーザーインターフェースにより、ＯｐｅｎＲＡＮは、異なる通信接続業者のハードウェアとソフトウェアのネットワーク統合と部署に至るまで、多くの注目を集めている。Ｏ－ＲＡＮ連合の成立は、単一の製造業者の研究開発が、多くの人材、および、費用を必要とする問題を解決し、疑いようもなく、ＯｐｅｎＲＡＮの研究開発を大きく後押しする。Ｏ－ＲＡＮソフトウェアコミュニティ（Ｏ－ＲＡＮＳＣ）は、Ｏ－ＲＡＮ機能定義に必要なオープンソースソフトウェアモジュールの開発の責任を負うとともに、ワイヤレスアクセスネットワークに関連する全ソフトウェア開発（各種オープンソフトウェアの技術文書、テストと整合を含む）、コードストレージ、ツールとデベロッパー整合テスト作業を管理して、ソフトウェアコードと、Ｏ－ＲＡＮ連合のオープン構造および仕様とを一致させる。

Ｏ－ＲＡＮは、Ｏ－ＲＡＮ連合により標準化されたＯｐｅｎＲＡＮバージョンである。Ｏ－ＲＡＮは、３ＧＰＰ（登録商標）ＴＳ３８．４０１の基礎上に築かれ、新しい機能、および、オープン、相互運用可能なインターフェースを有する。ＲＡＮ構造に対するこの新しいアプローチは、増加したサプライチェーン多様性と減少した部署コストに関連するいくつかの長所をもたらすと同時に、ネットワーク集積コストと複雑性を増加させる。

図１は、Ｏ－ＲＡＮシステム１００の構造図である。図１に示されるように、Ｏ－ＲＡＮシステム１００は、非リアルタイム無線アクセスネットワーク（ＲＡＮ）インテリジェントコントローラー（Ｎｏｎ－ＲＴＲＩＣ）１１１２を有するサービス管理およびオーケストレーション（ＳＭＯ）フレームワーク１１０、ニアリアルタイムＲＡＮインテリジェントコントローラー（Ｎｅａｒ－ＲＴＲＩＣ）１２０、Ｏ－ＲＡＮ中央装置コントロールプレーン（Ｏ－ＣＵ－ＣＰ）１３０２およびＯ－ＲＡＮ中央装置ユーザープレーン（Ｏ－ＣＵ－ＵＰ）１３０４で構成されるＯ－ＲＡＮ中央装置（Ｏ－ＣＵ）、Ｏ－ＲＡＮ分散ユニット（Ｏ－ＤＵ）１４０、Ｏ－ＲＡＮ無線装置（Ｏ－ＲＵ）１５０、Ｏ－ＲＡＮ進化型ノードＢ（Ｏ－ｅＮＢ）１６０、並びに、Ｏ－ＲＡＮクラウド（Ｏ－Ｃｌｏｕｄ）１７０という７つのメインパーツで構成される。

上記のパーツは、Ｏ－ＲＡＮにより定義される標準のインターフェースＯ１、Ｏ２、Ａ１、Ｅ２、ＯｐｅｎＦＨＭ－Ｐｌａｎｅ、および、ＯｐｅｎＦＨＣＵＳ－Ｐｌａｎｅにより、互いに接続される。Ｏ－ＣＵ－ＣＰ１３０２、Ｏ－ＣＵ－ＵＰ１３０４、および、Ｏ－ＤＵ１４０は、３ＧＰＰＴＲ３８．８０１「Ｓｔｕｄｙｏｎｎｅｗｒａｄｉｏａｃｃｅｓｓｔｅｃｈｎｏｌｏｇｙ：Ｒａｄｉｏａｃｃｅｓｓａｒｃｈｉｔｅｃｔｕｒｅａｎｄｉｎｔｅｒｆａｃｅｓ」，３ＧＰＰＴＲ３８．８０６「ＳｔｕｄｙｏｆｓｅｐａｒａｔｉｏｎｏｆＮＲＣｏｎｔｒｏｌＰｌａｎｅ（ＣＰ）ａｎｄＵｓｅｒＰｌａｎｅ（ＵＰ）ｆｏｒｓｐｌｉｔｏｐｔｉｏｎ２」，３ＧＰＰＴＲ３８．８１６「ＳｔｕｄｙｏｎＣｅｎｔｒａｌＵｎｉｔ（ＣＵ）－分散型Ｕｎｉｔ（ＤＵ）ｌｏｗｅｒｌａｙｅｒｓｐｌｉｔｆｏｒＮＲ」，３ＧＰＰＴＳ３８．４７ｘ「ｓｅｒｉｅｓｓｔｕｄｙＣＵ／ＤＵｓｐｌｉｔａｒｃｈｉｔｅｃｔｕｒｅ」、および、３ＧＰＰＴＳ３８．４６ｘ「ｓｅｒｉｅｓｓｔｕｄｙｃｏｎｔｒｏｌ－ｕｓｅｒｐｌａｎｅｓｅｐａｒａｔｉｏｎ」により定義されるインターフェースＥ１、Ｆ１－ｃ、Ｆ１－ｕ、ＮＧ－ｕ、ＮＧ－ｃ、Ｘ２－ｕ、Ｘ２－ｃ、Ｘｎ－ｕ、Ｘｎ－ｃにより、互いに接続される。

図２は、ＳＭＯフレームワーク２００の構造図である。ＳＭＯフレームワーク２００は、主に、エレメント管理システム（ＥＭＳ）２１０、および、非リアルタイムＲＡＮインテリジェントコントローラー（Ｎｏｎ－ＲＴＲＩＣ）２２０を有する。Ｎｏｎ－ＲＴＲＩＣ２２０は、Ｏ－ＲＡＮ構造中のＳＭＯフレームワーク２００の内部機能であり、且つ、Ａ１インターフェースを、Ｎｅａｒ－ＲＴＲＩＣに提供する。

Ｏ１インターフェースは、ＳＭＯフレームワーク２００と端末装置（Ｏ－ｅＮＢ）を接続するために用いられ、Ｏ２インターフェースは、ＳＭＯフレームワーク２００とＯ－ＲＡＮクラウドを接続するために用いられ、且つ、ＯｐｅｎＦＨＭ－Ｐｌａｎｅインターフェースは、ＳＭＯフレームワーク２００とＯ－ＲＡＮ無線ユニットを接続するために用いられる。

Ｎｏｎ－ＲＴＲＩＣ２２０は、Ｎｏｎ－ＲＴＲＩＣフレームワーク２２２、および、Ｎｏｎ－ＲＴＲＩＣアプリケーションプログラム（ｒＡｐｐｓ）２２４で構成される。Ｎｏｎ－ＲＴＲＩＣ２２０は、Ｒ１インターフェースにより、必要とされるサービスを、Ｎｏｎ－ＲＴＲＩＣアプリケーション２２４に公開する。

しかし、現在のＳＭＯフレームワーク２００は、ＥＭＳ２１０がどのように情報をＮｏｎ－ＲＴＲＩＣ２２０に提供するかについて、はっきりと定義していない。よって、ＥＭＳ２１０とＮｏｎ－ＲＴＲＩＣ２２０間の操作プロセスを定義して、ＳＭＯフレームワークをさらに完全にするサービス管理およびオーケストレーションにおける通信の方法、および、システムが必要である。

よって、本発明は、サービス管理およびオーケストレーションにおける通信の方法、および、システムを提供し、ＳＭＯフレームワークを、さらに完全にすることを目的とする。

例示的な一実施形態において、サービス管理およびオーケストレーションにおける通信方法が提供される。本方法は、非リアルタイム無線アクセスネットワーク（ＲＡＮ）インテリジェントコントローラー（Ｎｏｎ－ＲＴＲＩＣ）フレームワークにより、エレメント管理システム（ＥＭＳ）から送信された、Ｎｏｎ－ＲＴＲＩＣアプリケーション（ｒＡｐｐ）を実行するのに必要な第二データを要求するための第一サブスクリプションメッセージを受信する工程と、Ｎｏｎ－ＲＴＲＩＣフレームワークにより、第一サブスクリプションメッセージにしたがって、第一コールバックメッセージを、ｒＡｐｐに送信して、ＥＭＳが第二データを要求することを通知する工程と、ｒＡｐｐにより、第一コールバックメッセージにしたがって、第二データを、ＥＭＳに送信する工程と、を有する。

いくつかの実施形態において、ｒＡｐｐが、第一コールバックメッセージにしたがって、第二データをＥＭＳに送信する前に、本方法はさらに、ｒＡｐｐにより、第二データを生成するのに必要な第一データの取得を要求するための第二サブスクリプションメッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信する工程と、Ｎｏｎ－ＲＴＲＩＣフレームワークにより、第二サブスクリプションメッセージにしたがって、第二コールバックメッセージを、ＥＭＳに送信する工程と、ＥＭＳにより、第二コールバックメッセージにしたがって、第一データを、ｒＡｐｐに送信する工程と、ｒＡｐｐにより、第一データにしたがって、第二データを取得する工程と、を有する。

いくつかの実施形態において、本方法はさらに、ＥＭＳにより、第二データを読み取るとともに、応答し、且つ、第二データを、ウェブサービスページ上で表示する工程を有する。

いくつかの実施形態において、Ｎｏｎ－ＲＴＲＩＣフレームワークが、ＥＭＳから送信された第一サブスクリプションメッセージを受信する前に、本方法はさらに、ＥＭＳにより、Ｎｏｎ－ＲＴＲＩＣフレームワークに、第一登録プロセスを実行する工程、および、ｒＡｐｐにより、Ｎｏｎ－ＲＴＲＩＣフレームワークに、第二登録プロセスを実行する工程を有する。

いくつかの実施形態において、第一登録プロセスは、ＥＭＳにより、第一登録要求メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ＥＭＳの登録を要求する工程と、ＥＭＳにより、第一サブスクリプション要求メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ＥＭＳに必要なデータのサブスクリプションを要求する工程と、ＥＭＳにより、第一情報タイプの登録メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ＥＭＳにより提供される情報タイプの登録を要求する工程と、ＥＭＳにより、第一情報提供者登録メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ＥＭＳを情報提供者として登録することを要求する工程と、を有する。

いくつかの実施形態において、ｒＡｐｐにより、第二登録要求メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ｒＡｐｐの登録を要求する工程と、ｒＡｐｐにより、第二サブスクリプション要求メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ｒＡｐｐに必要なデータのサブスクリプションを要求する工程と、ｒＡｐｐにより、第二情報タイプの登録メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ｒＡｐｐにより提供される情報タイプの登録を要求する工程と、ｒＡｐｐにより、第二情報提供者登録メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ｒＡｐｐを情報提供者として登録することを要求する工程と、を有する。

いくつかの実施形態において、ＥＭＳのＩＰアドレスは、第一サブスクリプションメッセージ、および、第一コールバックメッセージ中に含まれる。

いくつかの実施形態において、ｒＡｐｐのＩＰアドレスは、第二サブスクリプションメッセージ、および、第二コールバックメッセージ中に含まれる。

いくつかの実施形態において、Ｎｏｎ－ＲＴＲＩＣフレームワークは、サービス管理およびオーケストレーション（ｓｅｒｖｉｃｅｍａｎａｇｅｍｅｎｔａｎｄｏｒｃｈｅｓｔｒａｔｉｏｎ、ＳＭＯ）内部インターフェースにより、ＥＭＳと接続される。

いくつかの実施形態において、Ｎｏｎ－ＲＴＲＩＣフレームワークは、Ｒ１インターフェースにより、ｒＡｐｐと接続される。

例示的な一実施形態において、サービス管理およびオーケストレーションにおける通信システムが提供され、本システムは、エレメント管理システム（ＥＭＳ）、非リアルタイム無線アクセスネットワークインテリジェントコントローラー（（Ｎｏｎ－ｒｅａｌｔｉｍｅＲＡＮＩｎｔｅｌｌｉｇｅｎｔＣｏｎｔｒｏｌｌｅｒａｐｐｌｉｃａｔｉｏｎ、ｒＡｐｐ）、および、Ｎｏｎ－ＲＴＲＩＣフレームワークを有する。Ｎｏｎ－ＲＴＲＩＣフレームワークは、ＥＭＳとｒＡｐｐに結合される。Ｎｏｎ－ＲＴＲＩＣフレームワークは、ＥＭＳから送信された、ｒＡｐｐの実行に必要な第二データを要求するための第一サブスクリプションメッセージを受信する。Ｎｏｎ－ＲＴＲＩＣフレームワークは、第一サブスクリプションメッセージにしたがって、第一コールバックメッセージを、ｒＡｐｐに送信して、ＥＭＳが第二データを要求することを通知する。ｒＡｐｐは、第一コールバックメッセージにしたがって、第二データを、ＥＭＳに送信する。

本発明の実施形態は、サービス管理およびオーケストレーションにおける通信のシステム、および、方法を提供し、ＥＭＳとＮｏｎ－ＲＴＲＩＣ間の操作仕様を定義して、Ｏ－ＲＡＮ機能をさらに改善する。

Ｏ－ＲＡＮシステムの構造図である。ＳＭＯフレームワークの構造図である。本発明の一実施形態によるＳＭＯフレームワークを示す図である。本発明の一実施形態によるＥＭＳ、および、ｒＡｐｐが、Ｎｏｎ－ＲＴＲＩＣフレームワークに、登録プロセスを実行することを説明するフローチャートである。本発明の一実施形態によるＥＭＳ、および、ｒＡｐｐが、Ｎｏｎ－ＲＴＲＩＣフレームワークに、データのサブスクリプションのプロセスを実行することを説明するフローチャートである。本発明の一実施形態によるＥＭＳ、および、ｒＡｐｐが、Ｎｏｎ－ＲＴＲＩＣフレームワークに、サービスにより提供される情報タイプを登録するプロセスを説明するフローチャートである。本発明の一実施形態によるＥＭＳ、および、ｒＡｐｐが、Ｎｏｎ－ＲＴＲＩＣフレームワークに、情報提供者として登録するプロセスを説明するフローチャートである。本発明の一実施形態によるＮｏｎ－ＲＴＲＩＣフレームワークによるＥＭＳとｒＡｐｐ間の通信を説明するフローチャートである。本発明の一実施形態によるサービス管理およびオーケストレーションにおける通信方法を説明するフローチャートである。本発明の実施形態を実施する例示的な動作環境を説明する図である。

図３は、本発明の一実施形態によるＳＭＯフレームワーク３００を示す図である。ＳＭＯフレームワーク３００は、主に、エレメント管理システム（ＥＭＳ）３１０、および、非リアルタイムＲＡＮインテリジェントコントローラー（Ｎｏｎ－ＲＴＲＩＣ）３２０を有する。

ＥＭＳ３１０は、Ｏ１インターフェースにより、Ｏ－ＲＡＮネットワークの故障、配置、監査、パフォーマンス、および、セキュリティ（ＦＣＡＰＳ）をサポートする機能を提供する。

Ｎｏｎ－ＲＴＲＩＣ３２０の主要機能は、ガイダンスポリシー、機械学習（ＭＬ）モデルマネジメント、および、情報を、Ｎｅａｒ－ＲＴＲＩＣに提供することにより、インテリジェントＲＡＮを最適化して、ＲＡＮを、ある条件下で最適化することである。Ｎｏｎ－ＲＴＲＩＣ３２０は、また、非リアルタイムインターバル（すなわち、１秒より長い）で、インテリジェント無線リソースマネジメント機能を実行する。Ｎｏｎ－ＲＴＲＩＣ３２０は、データ分析、および、ＡＩ／ＭＬトレーニング／推測を用いて、ＳＭＯサービスを利用するＲＡＮ最適操作を判断する。

Ｎｏｎ－ＲＴＲＩＣ３２０は、Ｎｏｎ－ＲＴＲＩＣフレームワーク３２２、および、Ｎｏｎ－ＲＴＲＩＣアプリケーション（ｒＡｐｐｓ）３２４を有し、サービスが、Ｎｏｎ－ＲＴＲＩＣフレームワーク３２２から、あるいは、ＳＭＯフレームワーク３００からであるにかかわらず、Ｎｏｎ－ＲＴＲＩＣフレームワーク３２２は、Ｒ１インターフェースにより、必要なサービスを、ｒＡｐｐ３２４に公開して、ｒＡｐｐ３２４は、Ａ１、Ｏ１、Ｏ２、および、ＯｐｅｎＦＨＭ－Ｐｌａｎｅインターフェースにより、情報を得るとともに、操作（たとえば、分配物理層ＩＤ（ＰＣＩ）３２４２、カバレッジと容量最適化（ＣｏｖｅｒａｇｅａｎｄＣａｐａｃｉｔｙＯｐｔｉｍｉｚａｔｉｏｎ、ＣＣＯ）３２４４、自動近隣関係（ＡｕｔｏＮｅｉｇｈｂｏｒＲｅｌａｔｉｏｎ、ＡＮＲ）３２４６、あるいは、その他の第三者ｒＡｐｐ３３０により提供される操作）をトリガーする。

ＥＭＳ３１０は、ウェブサービス３１２に接続される。ウェブサービス３１２は、オペレーター／マネージャーが、ヒューマンマシンインターフェース（たとえば、ウェブサービスの形式）により、管理意図（ｉｎｔｅｎｔ）を、ＥＭＳ３１０に送信することを提供する。ＥＭＳ３１０は、受信された意図を、対応するプラグラム命令に変換するとともに、関連する動作を、下層でトリガーして、調整と管理の目的を達成する。ＥＭＳ３１０は、サービス管理およびオーケストレーション（ＳＭＯ）内部インターフェース３５０により、Ｎｏｎ－ＲＴＲＩＣフレームワーク３２２に接続される。

注意すべきことは、ＳＭＯフレームワーク３００中のＥＭＳ３１０、Ｎｏｎ－ＲＴＲＩＣフレームワーク３２２、および、ｒＡｐｐ３２４は、専用のハードウェア（たとえば、コンピュータ装置、サーバー、あるいは、コンピュータ装置、または、サーバー中のプロセッサの処理回路）上のネットワーク素子として実施されてもよく、専用のハードウェアを実行するソフトウェアインスタンスとして実施されてもよく、あるいは、適切なプラットフォーム（たとえば、クラウドインフラストラクチャー）に実装されたバーチャル機能として実施されてもよいことである。

理解すべきことは、ＥＭＳ３１０、Ｎｏｎ－ＲＴＲＩＣフレームワーク３２２、および、ｒＡｐｐ３２４が、専用のハードウェアとして用いられるとき、ＥＭＳ３１０、Ｎｏｎ－ＲＴＲＩＣフレームワーク３２２、および、ｒＡｐｐ３２４は、任意のタイプの電子装置、たとえば、図１０に示されるように、図１０に関連して記述される電子装置１０００により実施されることである。

図４～図７は、ＥＭＳ、および、ｒＡｐｐが、Ｎｏｎ－ＲＴＲＩＣフレームワークに、登録プロセス、データのサブスクリプション、サービスにより提供される情報タイプの登録、および、情報提供者として登録するプロセスを説明する。

注意すべきことは、図４～図７中、ｒＡｐｐにより実行される操作は、カバレッジと容量最適化（ＣＣＯ）を例としているが、当業者は、この実施形態にしたがって、適当な代替や調整を行うことができることである。

図４は、本発明の一実施形態によるＥＭＳ、および、ｒＡｐｐが、Ｎｏｎ－ＲＴＲＩＣフレームワークに、登録プロセスを実行することを説明するフローチャート４００である。

工程Ｓ４０５において、ＥＭＳは、第一登録要求メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ＥＭＳの登録を要求する。該第一登録要求メッセージは、ＨＴＴＰ要求（ＰＵＴ）メッセージであり、アプリケーションプログラミングインターフェース（ＡＰＩ）、および、ＥＭＳ識別子を有する。たとえば、図４中の第一登録要求メッセージは、「ＰＵＴ／ｓｅｒｖｉｃｅｓ／ＥＭＳ」）として表現される。

工程Ｓ４１０において、第一登録要求メッセージの受信に応答して、Ｎｏｎ－ＲＴＲＩＣフレームワークは、ＨＴＴＰリプライメッセージを、ＥＭＳに送信する。一例において、ＨＴＴＰリプライメッセージは、２０１ＯＫメッセージである。

工程Ｓ４１５において、ｒＡｐｐは、第二登録要求メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ＣＣＯの登録を要求する。該第二登録要求メッセージは、ＨＴＴＰ要求（ＰＵＴ）メッセージであり、ＡＰＩ、および、ＣＣＯ識別子を有する。たとえば、図４中の第二登録要求メッセージは、「ＰＵＴ／ｓｅｒｖｉｃｅｓ／ＣＣＯ」として表現される。

工程Ｓ４２０において、第二登録要求メッセージの受信に応答して、Ｎｏｎ－ＲＴＲＩＣフレームワークは、ＨＴＴＰリプライメッセージを、ｒＡｐｐに送信する。一例において、ＨＴＴＰリプライメッセージは、２０１ＯＫメッセージである。

図５は、本発明の一実施形態によるＥＭＳ、および、ｒＡｐｐが、Ｎｏｎ－ＲＴＲＩＣフレームワークに、データのサブスクリプションのプロセスを実行することを説明するフローチャート５００である。

工程Ｓ５０５において、ＥＭＳは、第一サブスクリプション要求メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ＥＭＳに必要なデータのサブスクリプションを要求する。該第一サブスクリプション要求メッセージは、ＨＴＴＰ要求（ＰＵＴ）メッセージであり、ＡＰＩ、および、ｒＡｐｐ（たとえば、ＣＣＯ）を実行するのに必要なデータを有する。たとえば、図５中の第一サブスクリプション要求メッセージは、「ＰＵＴ／ｄａｔａ－ｃｏｎｓｕｍｅｒ／ｖ１／ｉｎｆｏ－ｊｏｂｓ／ｃｃｏ＿ｏｕｔｐｕｔ」として表現される。

工程Ｓ５１０において、第一サブスクリプション要求メッセージの受信に応答して、Ｎｏｎ－ＲＴＲＩＣフレームワークは、ＨＴＴＰリプライメッセージを、ＥＭＳに送信する。一例において、ＨＴＴＰリプライメッセージは、２０１ＯＫメッセージである。

工程Ｓ５１５において、ｒＡｐｐは、第二サブスクリプション要求メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ｒＡｐｐに必要なデータのサブスクリプションを要求する。該第二サブスクリプション要求メッセージは、ＨＴＴＰ要求（ＰＵＴ）メッセージであり、ＡＰＩ、および、ｒＡｐｐ（たとえば、ＣＣＯ）を実行するのに必要なデータを有する。たとえば、図５中の第二サブスクリプション要求メッセージは、「ＰＵＴ／ｄａｔａ－ｃｏｎｓｕｍｅｒ／ｖ１／ｉｎｆｏ－ｊｏｂｓ／ｃｃｏ＿ｉｎｐｕｔ」として表現される。

工程Ｓ５２０において、第二サブスクリプション要求メッセージの受信に応答して、Ｎｏｎ－ＲＴＲＩＣフレームワークは、ＨＴＴＰリプライメッセージを、ｒＡｐｐに送信する。一例において、ＨＴＴＰリプライメッセージは、２０１ＯＫメッセージである。

図６は、本発明の一実施形態によるＥＭＳ、および、ｒＡｐｐが、Ｎｏｎ－ＲＴＲＩＣフレームワークに、サービスにより提供されるタイプを登録するプロセスを説明するフローチャート６００である。

工程Ｓ６０５において、ＥＭＳは、第一情報タイプの登録メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ＥＭＳにより提供される情報タイプ（ＩｎｆｏｒｍａｔｉｏｎＴｙｐｅ）の登録を要求する。該第一情報タイプの登録メッセージは、ＨＴＴＰ要求（ＰＵＴ）メッセージであり、ＥＭＳにより提供される情報タイプを有する。たとえば、図６中の第一情報タイプの登録メッセージは、「ＰＵＴ／ｄａｔａ－ｐｒｏｄｕｃｅｒ／ｖ１／ｉｎｆｏ－ｔｙｐｅｓ／ｃｃｏ＿ｉｎｐｕｔ」として表現される。

工程Ｓ６１０において、第一情報タイプの登録メッセージの受信に応答して、Ｎｏｎ－ＲＴＲＩＣフレームワークは、ＨＴＴＰリプライメッセージを、ＥＭＳに送信する。一例において、ＨＴＴＰリプライメッセージは、２０１ＯＫメッセージである。

工程Ｓ６１５において、ｒＡｐｐは、第二情報タイプの登録メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ｒＡｐｐにより提供される情報タイプの登録を要求する。該第二情報タイプの登録メッセージは、ＨＴＴＰ要求（ＰＵＴ）メッセージであり、ｒＡｐｐにより提供される情報タイプを有する。たとえば、図６中の第二情報タイプの登録メッセージは、「ＰＵＴ／ｄａｔａ－ｐｒｏｄｕｃｅｒ／ｖ１／ｉｎｆｏ－ｔｙｐｅｓ／ｃｃｏ＿ｏｕｔｐｕｔ」として表現される。

工程Ｓ６２０において、第二情報タイプの登録メッセージの受信に応答して、Ｎｏｎ－ＲＴＲＩＣフレームワークは、ＨＴＴＰリプライメッセージを、ｒＡｐｐに送信する。一例において、ＨＴＴＰリプライメッセージは、２０１ＯＫメッセージである。

図７は、本発明の一実施形態によるＥＭＳ、および、ｒＡｐｐが、Ｎｏｎ－ＲＴＲＩＣフレームワークに、情報提供者として登録するプロセスを説明するフローチャート７００である。

工程Ｓ７０５において、ＥＭＳは、第一情報提供者登録メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ＥＭＳを情報提供者として登録することを要求する。該第一情報提供者登録メッセージは、ＨＴＴＰ要求（ＰＵＴ）メッセージであり、ＥＭＳが工程Ｓ６０５中の情報タイプの情報提供者であることを示す。たとえば、図７中の第一情報提供者登録メッセージは、「ＰＵＴ／ｄａｔａ－ｐｒｏｄｕｃｅｒ／ｖ１／ｉｎｆｏ－ｐｒｏｄｕｃｅｒｓ／ｓｍｏ＿ｉｎｐｕｔ」として表現される。

工程Ｓ７１０において、第一情報提供者登録メッセージの受信に応答して、Ｎｏｎ－ＲＴＲＩＣフレームワークは、ＨＴＴＰリプライメッセージを、ＥＭＳに送信する。一例において、ＨＴＴＰリプライメッセージは、２０１ＯＫメッセージである。

工程Ｓ７１５において、ｒＡｐｐは、第二情報提供者登録メッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ｒＡｐｐを情報提供者として登録することを要求する。該第二情報提供者登録メッセージは、ＨＴＴＰ要求（ＰＵＴ）メッセージであり、ｒＡｐｐが工程Ｓ６１５中の情報タイプの情報提供者であることを示す。たとえば、図７中の第二情報提供者登録メッセージは、「ＰＵＴ／ｄａｔａ－ｐｒｏｄｕｃｅｒ／ｖ１／ｉｎｆｏ－ｐｒｏｄｕｃｅｒｓ／ｃｃｏ＿ｏｕｔｐｕｔ」として表現される。

工程Ｓ７２０において、第二情報提供者登録メッセージの受信に応答して、Ｎｏｎ－ＲＴＲＩＣフレームワークは、ＨＴＴＰリプライメッセージを、ｒＡｐｐに送信する。一例において、ＨＴＴＰリプライメッセージは、２０１ＯＫメッセージである。

ＥＭＳ、および、ｒＡｐｐが、Ｎｏｎ－ＲＴＲＩＣフレームワークに、登録プロセス、データのサブスクリプション、サービスにより提供される情報タイプの登録、および、情報提供者としての登録のプロセスを完成させた後、ＥＭＳは、Ｎｏｎ－ＲＴＲＩＣ中のｒＡｐｐと通信する。

図８は、本発明の一実施形態によるＮｏｎ－ＲＴＲＩＣフレームワークによるＥＭＳとｒＡｐｐの通信を説明するフローチャート８００である。

注意すべきことは、図８中で、ｒＡｐｐにより実行される操作は、カバレッジと容量最適化（ＣＣＯ）を例としているが、当業者は、この実施形態にしたがって、適当な代替や調整を行うことができることである。

工程Ｓ８０５において、ＥＭＳは、ウェブサービスにより送信された信号を受信する。該信号は、ＥＭＳに、ｒＡｐｐ中のＣＣＯを実行するように指示する。

工程Ｓ８１０において、ＥＭＳは、第一サブスクリプションメッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、ｒＡｐｐ中のＣＣＯを実行するのに必要な第二データ（ｃｃｏ＿ｏｕｔｐｕｔ）を要求する。該第一サブスクリプションメッセージは、ＨＴＴＰ要求（ＰＵＴ）メッセージであり、且つ、ＥＭＳのＩＰアドレスを有する。たとえば、図８において、第一サブスクリプションメッセージは、「ＰＵＴ／ｄａｔａ－ｃｏｎｓｕｍｅｒ／ｖ１／ｉｎｆｏ－ｊｏｂｓ／ｃｃｏ＿ｏｕｔｐｕｔ」として表現される。

Ｎｏｎ－ＲＴＲＩＣフレームワークは、第一サブスクリプションメッセージの受信後、第二データを提供する提供者がｒＡｐｐであると判断する。工程Ｓ８１５において、Ｎｏｎ－ＲＴＲＩＣフレームワークは、第一サブスクリプションメッセージにしたがって、第一コールバックメッセージを、ｒＡｐｐに送信して、ＥＭＳが第二データを要求することを通知する。第一コールバックメッセージは、ＨＴＴＰ要求（ＰＯＳＴ）メッセージであり、且つ、ＥＭＳのＩＰアドレスを有する。たとえば、図８中の第一コールバックメッセージは、「ＰＯＳＴ／ｄａｔａ－ｐｒｏｄｕｃｅｒ／ｉｎｆｏ＿ｊｏｂ／ｃｃｏ」として表現される。

工程Ｓ８２０において、ｒＡｐｐは、ｒＡｐｐ自身が、第一データ（ｃｃｏ＿ｉｎｐｕｔ）を必要とすると判断する。

工程Ｓ８２５において、ｒＡｐｐは、第二サブスクリプションメッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信する。該第二サブスクリプションメッセージは、第二データを生成するのに必要な第一データ（ｃｃｏ＿ｉｎｐｕｔ）を取得することを要求するために用いられる。該第二サブスクリプションメッセージは、ＨＴＴＰ要求（ＰＵＴ）メッセージであり、且つ、ｒＡｐｐのＩＰアドレスを有する。たとえば、図８中の第二サブスクリプションメッセージは、「ＰＵＴ／ｄａｔａ－ｃｏｎｓｕｍｅｒ／ｖ１／ｉｎｆｏ－ｊｏｂｓ／ｃｃｏ＿ｉｎｐｕｔ」として表現される。

Ｎｏｎ－ＲＴＲＩＣフレームワークは、第二サブスクリプションメッセージの受信後、第一データを提供する提供者がＥＭＳであると判断する。工程Ｓ８３０において、Ｎｏｎ－ＲＴＲＩＣフレームワークは、第二サブスクリプションメッセージにしたがって、第二コールバックメッセージを、ＥＭＳに送信して、ｒＡｐｐが第一データを要求することを通知する。該第二コールバックメッセージは、ＨＴＴＰ要求（ＰＯＳＴ）メッセージであり、且つ、ｒＡｐｐのＩＰアドレスを有する。たとえば、図８の第二コールバックメッセージは、「ＰＯＳＴ／ｄａｔａ－ｐｒｏｄｕｃｅｒ／ｉｎｆｏ＿ｊｏｂ／ｅｍｓ」として表現される。

工程Ｓ８３５において、ＥＭＳは、第二コールバックメッセージ中のｒＡｐｐのＩＰアドレスにしたがって、第一データをｒＡｐｐに送信する。該第一データは、ＨＴＴＰ（ＰＯＳＴ）メッセージである。たとえば、図８中の第一データは、「ＰＯＳＴ／ｊｏｂ＿ｒｅｓｕｌｔ／ｃｃｏ＿ｉｎｐｕｔ」として表現される。

工程Ｓ８４０において、ｒＡｐｐは、第一データを書き込む。

ｒＡｐｐが、第一データを書き込んだ後、工程８４５において、ｒＡｐｐは、ＨＴＴＰリプライメッセージを、ＥＭＳに送信して、工程Ｓ８３５中の第一データの受信に応答する。一例において、ＨＴＴＰリプライメッセージは、２００ＯＫメッセージである。

工程Ｓ８５０において、工程Ｓ８３０中の第二コールバックメッセージの受信に応答して、ＥＭＳは、ＨＴＴＰリプライメッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信する。一例において、ＨＴＴＰリプライメッセージは、２００ＯＫメッセージである。

工程Ｓ８５５において、工程Ｓ８２５中の第二サブスクリプションメッセージの受信に応答して、Ｎｏｎ－ＲＴＲＩＣフレームワークは、ＨＴＴＰリプライメッセージを、ｒＡｐｐに送信する。一例において、ＨＴＴＰリプライメッセージは、２００ＯＫメッセージである。

工程Ｓ８６０において、ｒＡｐｐは、第一データを読み取るとともに、ＣＣＯを実行して、第二データを生成する。

工程Ｓ８６５において、ｒＡｐｐは、第一コールバックメッセージ中のＥＭＳのＩＰアドレスにしたがって、第二データをＥＭＳに送信する。該第二データは、ＨＴＴＰ（ＰＯＳＴ）メッセージである。たとえば、図８中の第二データは、「ＰＯＳＴ／ｊｏｂ＿ｒｅｓｕｌｔ／ｃｃｏ＿ｏｕｔｐｕｔ」として表現される。

工程Ｓ８７０において、ＥＭＳは、第二データを書き込む。

ＥＭＳが、第二データを書き込んだ後、工程Ｓ８７５において、ＥＭＳは、ＨＴＴＰリプライメッセージを、ｒＡｐｐに送信して、工程Ｓ８６５中の第二データの受信に応答する。一例において、ＨＴＴＰリプライメッセージは、２００ＯＫメッセージである。

工程Ｓ８８０において、工程Ｓ８１５中の第一コールバックメッセージの受信に応答して、ｒＡｐｐは、ＨＴＴＰリプライメッセージを、Ｎｏｎ－ＲＴＲＩＣフレームワークに送信する。一例において、ＨＴＴＰリプライメッセージは、２００ＯＫメッセージである。

工程Ｓ８８５において、工程Ｓ８１０中の第一サブスクリプションメッセージの受信に応答して、Ｎｏｎ－ＲＴＲＩＣフレームワークは、ＨＴＴＰリプライメッセージを、ＥＭＳに送信する。一例において、ＨＴＴＰリプライメッセージは、２００ＯＫメッセージである。

工程Ｓ８９０において、ＥＭＳは、第一データを実行するＣＣＯにより生成される第二データを読み取るとともに、応答し、且つ、工程Ｓ８０５のウェブサービスページ上で表示する。

図９は、本発明の一実施形態によるサービス管理およびオーケストレーションにおける通信の方法９００を説明するフローチャートである。この方法は、図３のＥＭＳ３１０、Ｎｏｎ－ＲＴＲＩＣフレームワーク３２２、および、ｒＡｐｐ３２４により実施される。

工程Ｓ９０５において、Ｎｏｎ－ＲＴＲＩＣフレームワークは、ＥＭＳから送信された第一サブスクリプションメッセージを受信する。該第一サブスクリプションメッセージは、ｒＡｐｐを実行するのに必要な第二データを要求するために用いられ、且つ、第一サブスクリプションメッセージは、ＥＭＳのＩＰアドレスを有する。

工程Ｓ９１０において、Ｎｏｎ－ＲＴＲＩＣフレームワークは、第一サブスクリプションメッセージにしたがって、第一コールバックメッセージを、ｒＡｐｐに送信して、ＥＭＳが第二データを要求することを通知する。該第一コールバックメッセージは、ＥＭＳのＩＰアドレスを有する。

工程Ｓ９１５において、ｒＡｐｐは、第一コールバックメッセージにしたがって、第二データを、ＥＭＳに送信する。

一実施形態において、Ｎｏｎ－ＲＴＲＩＣフレームワークは、サービス管理およびオーケストレーション（ＳＭＯ）内部インターフェースにより、ＥＭＳと接続される。

上述のように、本発明で提供されるサービス管理およびオーケストレーションにおける通信方法、および、システムは、サービス管理およびオーケストレーション内部インターフェースにより、ＥＭＳとＮｏｎ－ＲＴＲＩＣフレームワークを接続するとともに、ＥＭＳ、Ｎｏｎ－ＲＴＲＩＣフレームワーク、および、ｒＡｐｐ間の相互作用仕様を定義して、ＳＭＯフレームワークにおけるＥＭＳとｒＡｐｐ間のデータ送信の目的が達成される。

本発明の記述された実施形態に対し、以下で、本発明の実施形態を実現する例示的な動作環境が記述される。図１０を参照すると、本発明の実施形態を実現する例示的な動作環境が示され、一般的に、電子装置１０００として知られる。電子装置１０００は、単に、適当なコンピュータ環境の一例であり、且つ、本開示の使用や機能性の範囲を制限することを意図しない。電子装置１０００は、説明されるコンポーネントの任意の一つ、あるいは、組み合わせに関連する任意の依存性、あるいは、要求を有するものとして解釈されるべきでもない。

本開示は、コンピュータコード、あるいは、機械使用可能命令の手段により実現され、命令は、たとえば、プログラムモジュールのコンピュータ実行可能命令であり、プログラムモジュールは、コンピュータ、あるいは、その他の機械、たとえば、ＰＤＡ、あるいは、その他の携帯端末により実行される。一般的に、プログラムモジュールは、ルーティン、プログラム、オブジェクト、コンポーネンツ、データ構造等を有し、プログラムモジュールは、特定のタスクを実行する、あるいは、特定の抽象データタイプを実施するコードを指す。本開示は、各種システム構成で実現され、携帯用デバイス、家電製品、汎用コンピュータ、さらに専門的なコンピュータデバイス等を有する。本開示は、また、分散型コンピュータ環境で実現され、通信ネットワークにより接続される装置を処理する。

図１０を参照すると、電子装置１０００は、一つ以上のメモリ１０１２、一つ以上のプロセッサ１０１４、一つ以上のディスプレイコンポーネント１０１６、一つ以上の入／出力（Ｉ／Ｏ）ポート１０１８、一つ以上の入／出力コンポーネント１０２０、および、示例的な電源１０２２に、直接、あるいは、間接的に結合されるバス１０１０を有する。バス１０１０は、一種以上のバス（たとえば、アドレスバス、データバス、あるいは、それらの任意の組み合わせ）を表す。図１０の各種ブロックは、わかりやすくするため、線で示されているが、実際は、各種素子の境界は、具体的ではない。たとえば、ディスプレイコンポーネント、たとえば、ディスプレイ装置は、Ｉ／Ｏコンポーネントとみなされ、且つ、プロセッサは、メモリを有する。

電子装置１０００は、通常、各種コンピュータ可読媒体を有する。コンピュータ可読媒体は、電子装置１０００によりアクセス可能な任意の可用媒体であり、媒体は、同時に、揮発性と不揮発性媒体、リムーバブルと非リムーバブル媒体を有する。例として、これに制限されないが、コンピュータ可読媒体は、コンピュータストレージ媒体、および、通信媒体を有する。コンピュータ可読媒体は、同時に、たとえば、コンピュータ可読命令、データ構造、プログラムモジュール、あるいは、その他のデータ等の情報の任意の方法、あるいは、技術中で実現される揮発性、および、不揮発性、リムーバブル、および、非リムーバブル媒体を有する。コンピュータストレージ媒体は、これに制限されないが、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、電気的消去可能プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、あるいは、その他のメモリ技術、コンパクトディスクリードオンリメモリ（ＣＤ－ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、あるいは、その他の光学ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、あるいは、その他の磁気ストレージデバイス、あるいは、所望の情報を保存するのに用いられるとともに、電子装置１０００によりアクセスされる任意のその他の媒体を有する。コンピュータストレージ媒体自身は、信号を有さない。

通信媒体は、通常、コンピュータ可読命令、データ構造、プログラムモジュール、あるいは、たとえば、搬送波、あるいは、その他の輸送機構を採用するモジュール化データ信号形式のデータを有するとともに、任意の情報伝送媒体を有する。用語「モジュール化データ信号」は、一つ以上の特集集合、あるいは、信号中で、情報を符号化する一方式で変化した信号のことを意味する。例として、これに制限されないが、通信媒体は、たとえば、有線ネットワーク、あるいは、直接有線接続の有線媒体、および、無線媒体、たとえば、音響、ＲＦ、赤外線、および、その他の無線媒体、あるいは、それらの任意の組み合わせを有する。

メモリ１０１２は、揮発性と不揮発性メモリの形式のコンピュータストレージ媒体を有する。メモリは、リムーバブル、非リムーバブル、あるいは、それらの組み合わせである。例示的なハードウェアデバイスは、ソリッドステートメモリ、ハードドライブ、光学ディスクドライブ等を有する。電子装置１０００は、一つ以上のプロセッサを有し、たとえば、メモリ１０１２、あるいは、Ｉ／Ｏコンポーネント１０２０からの各エンティティのデータを読み取る。ディスプレイコンポーネント１０１６は、データ指示を、ユーザー、あるいは、別の装置に示す。例示的な表示コンポーネンツは、ディスプレイ装置、スピーカー、印刷素子、振動素子等を有する。

Ｉ／Ｏポート１０１８は、電子装置１０００を、論理的に、Ｉ／Ｏコンポーネント１０２０を有するその他の装置に結合できるようにし、それらのいくつかは、内蔵装置である。事例的コンポーネンツは、マクロフォン、ジョイスティック、ゲームパッド、サテライトデッシュ、スキャナー、プリンター、ワイヤレス装置等を有する。Ｉ／Ｏコンポーネント１０２０は、ユーザーにより生成されるジェスチャー、音声、あるいは、その他の生理的入力を処理するナチュラルユーザーインターフェース（ＮＵＩ）を提供する。例において、これらの入力は、適切なネットワーク素子に送信されて、さらに処理される。電子装置１０００は、深度カメラ、たとえば、立体カメラシステム、赤外線システム、ＲＧＢカメラシステム、あるいは、それらの任意の組み合わせを備えていて、検出と識別を実現する。このほか、電子装置１０００は、センサー（たとえば、レーダー、光センサー）を有し、周期的に、周辺のセンサー範囲内の近隣環境を感知し、自身と周辺環境に関連する感知情報を表示する。さらに、電子装置１０００は、動きの検出を可能にする加速度計、あるいは、ジャイロスコープを備えている。加速度計、あるいは、ジャイロスコープの出力が、電子装置１０００のディスプレイに提供されて表示される。

さらに、電子装置１０００中のプロセッサ１０１４は、メモリ１０１２中のプログラム、および、命令を実行して、上記の動作、および、工程、あるいは、ここで記述されるその他のことを実行することができる。

本発明では好ましい実施例を前述の通り開示したが、これらは決して本発明に限定するものではなく、当該技術を熟知する者なら誰でも、本発明の思想を脱しない範囲内で各種の変形を加えることができる。

１００Ｏ－ＲＡＮシステム
１１０、２００、３００ＳＭＯフレームワーク
１１１２、２２０、３２０非リアルタイム無線アクセスネットワーク（ＲＡＮ）インテリジェントコントローラー（Ｎｏｎ－ＲＴＲＩＣ）
１２０Ｎｅａｒ－ＲＴＲＩＣ
１３０２Ｏ－ＣＵ－ＣＰ
１３０４Ｏ－ＣＵ－ＵＰ
１４０Ｏ－ＤＵ
１５０Ｏ－ＲＵ
１６０Ｏ－ｅＮＢ
１７０Ｏ－ＲＡＮクラウド
２１０、３１０エレメント管理システム
２２２、３２２Ｎｏｎ－ＲＴＲＩＣフレームワーク
２２４、３２４ｒＡｐｐｓ
３１２ウェブサービス
３２４２ＰＣＩ
３２４４ＡＮＲ
３２４６ＣＣＯ
３３０第三者ｒＡｐｐｓ
３５０ＳＭＯ内部インターフェース
４００フローチャート
Ｓ４０５、Ｓ４１０、Ｓ４１５、Ｓ４２０、Ｓ４２０、Ｓ５０５、Ｓ５１０、Ｓ５１５、Ｓ５２０、Ｓ６０５、Ｓ６１０、Ｓ６１５、Ｓ６２０、Ｓ７０５、Ｓ７１０、Ｓ７１５、Ｓ７２０、Ｓ８０５、Ｓ８１０、Ｓ８１５、Ｓ８２０、Ｓ８２５、Ｓ８３０、Ｓ８３５、Ｓ８４０、Ｓ８４５、Ｓ８５０、Ｓ８５５、Ｓ８６０、Ｓ８６５、Ｓ８７０、Ｓ８７５、Ｓ８８０、Ｓ８８５、Ｓ８９０、Ｓ９０５、Ｓ９１０、Ｓ９１５工程
５００、６００、７００、８００、９００フローチャート
１０００電子装置
１０１０バス
１０１２メモリ
１０１４プロセッサ
１０１６ディスプレイコンポーネント
１０１８Ｉ／Ｏポート
１０２０Ｉ／Ｏコンポーネンツ
１０２２電源
Ｏ１、Ｏ２、Ａ１、Ｅ２、ＯｐｅｎＦＨＭ－Ｐｌａｎｅ、ＯｐｅｎＦＨＣＵＳ－Ｐｌａｎｅ、ＯｐｅｎＦＨＭ－Ｐｌａｎｅ、Ｅ１、Ｆ１－ｃ、Ｆ１－ｕ、ＮＧ－ｕ、ＮＧ－ｃ、Ｘ２－ｕ、Ｘ２－ｕ、Ｘｎ－ｕ、Ｘｎ－ｃ、Ｒ１インターフェース

Claims

サービス管理およびオーケストレーションにおける通信方法であって、
非リアルタイム無線アクセスネットワーク（ＲＡＮ）インテリジェントコントローラー（Ｎｏｎ－ＲＴＲＩＣ）フレームワークにより、エレメント管理システム（ＥＭＳ）から送信された、Ｎｏｎ－ＲＴＲＩＣアプリケーション（ｒＡｐｐ）を実行するのに必要な第二データを要求するための第一サブスクリプションメッセージを受信する工程と、
前記Ｎｏｎ－ＲＴＲＩＣフレームワークにより、前記第一サブスクリプションメッセージにしたがって、第一コールバックメッセージを、前記ｒＡｐｐに送信して、前記ＥＭＳが前記第二データを要求することを通知する工程と、
前記ｒＡｐｐにより、前記第一コールバックメッセージにしたがって、前記第二データを、前記ＥＭＳに送信する工程と、
を有することを特徴とする方法。
前記ｒＡｐｐが、前記第一コールバックメッセージにしたがって、前記第二データを、前記ＥＭＳに送信する前に、さらに、
前記ｒＡｐｐにより、前記第二データを生成するのに必要な第一データを取得することを要求するための第二サブスクリプションメッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信する工程と、
前記Ｎｏｎ－ＲＴＲＩＣフレームワークにより、前記第二サブスクリプションメッセージにしたがって、第二コールバックメッセージを、前記ＥＭＳに送信する工程と、
前記ＥＭＳにより、前記第二コールバックメッセージにしたがって、前記第一データを、前記ｒＡｐｐに送信する工程と、
前記ｒＡｐｐにより、前記第一データにしたがって、前記第二データを取得する工程と、
を有することを特徴とする請求項１に記載の方法。
さらに、前記ＥＭＳにより、前記第二データを読み取るとともに、応答し、且つ、ウェブサービスページ上で表示する工程を有することを特徴とする請求項１に記載の方法。
前記Ｎｏｎ－ＲＴＲＩＣフレームワークが、前記ＥＭＳから送信された前記第一サブスクリプションメッセージを受信する前に、さらに、
前記ＥＭＳにより、第一登録プロセスを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに実行する工程、および、
前記ｒＡｐｐにより、第二登録プロセスを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに実行する工程、
を有することを特徴とする請求項１に記載の方法。
前記第一登録プロセスは、
前記ＥＭＳにより、第一登録要求メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ＥＭＳの登録を要求する工程と、
前記ＥＭＳにより、第一サブスクリプション要求メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ＥＭＳに必要なデータのサブスクリプションを要求する工程と、
前記ＥＭＳにより、第一情報タイプの登録メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ＥＭＳにより提供される情報タイプの登録を要求する工程と、
前記ＥＭＳにより、第一情報提供者登録メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ＥＭＳを情報提供者として登録することを要求する工程と、
を有することを特徴とする請求項４に記載の方法。
前記第二登録プロセスは、
前記ｒＡｐｐにより、第二登録要求メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ｒＡｐｐの登録を要求する工程と、
前記ｒＡｐｐにより、第二サブスクリプション要求メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ｒＡｐｐに必要なデータのサブスクリプションを要求する工程と、
前記ｒＡｐｐにより、第二情報タイプの登録メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ｒＡｐｐにより提供される情報タイプの登録を要求する工程と、
前記ｒＡｐｐにより、第二情報提供者登録メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ｒＡｐｐを情報提供者として登録することを要求する工程と、
を有することを特徴とする請求項４に記載の方法。
前記ＥＭＳのＩＰアドレスは、前記第一サブスクリプションメッセージ、および、前記第一コールバックメッセージ中に含まれることを特徴とする請求項１に記載の方法。
前記ｒＡｐｐのＩＰアドレスは、前記第二サブスクリプションメッセージ、および、前記第二コールバックメッセージ中に含まれることを特徴とする請求項２に記載の方法。
前記Ｎｏｎ－ＲＴＲＩＣフレームワークは、サービス管理およびオーケストレーション（ＳＭＯ）内部インターフェースにより、前記ＥＭＳと接続されることを特徴とする請求項１に記載の方法。
前記Ｎｏｎ－ＲＴＲＩＣフレームワークは、Ｒ１インターフェースにより、前記ｒＡｐｐと接続されることを特徴とする請求項１に記載の方法。
サービス管理およびオーケストレーションにおける通信システムであって、
エレメント管理システム（ＥＭＳ）と、
非リアルタイム無線アクセスネットワーク（ＲＡＮ）インテリジェントコントローラー（Ｎｏｎ－ＲＴＲＩＣ）アプリケーション（ｒＡｐｐ）と、
前記ＥＭＳ、および、前記ｒＡｐｐに結合されるＮｏｎ－ＲＴＲＩＣフレームワークと、を有し、
前記Ｎｏｎ－ＲＴＲＩＣフレームワークは、前記ＥＭＳから送信された第一サブスクリプションメッセージを受信し、前記第一サブスクリプションメッセージは、前記ｒＡｐｐを実行するのに必要な第二データを要求するために用いられ、
前記Ｎｏｎ－ＲＴＲＩＣフレームワークは、前記第一サブスクリプションメッセージにしたがって、第一コールバックメッセージを、前記ｒＡｐｐに送信して、前記ＥＭＳが前記第二データを要求することを通知し、
前記ｒＡｐｐは、前記第一コールバックメッセージにしたがって、前記第二データを、前記ＥＭＳに送信する、
ことを特徴とするシステム。
前記ｒＡｐｐが、前記第一コールバックメッセージにしたがって、前記第二データを、前記ＥＭＳに送信する前に、さらに、
前記ｒＡｐｐは、第二サブスクリプションメッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信し、前記第二サブスクリプションメッセージは、前記第二データを生成するのに必要な第一データの取得を要求するために用いられ、
前記Ｎｏｎ－ＲＴＲＩＣフレームワークは、前記第二サブスクリプションメッセージにしたがって、第二コールバックメッセージを、前記ＥＭＳに送信し、
前記ＥＭＳは、前記第二コールバックメッセージにしたがって、前記第一データを、前記ｒＡｐｐに送信し、
前記ｒＡｐｐは、前記第一データにしたがって、前記第二データを取得する、
ことを特徴とする請求項１１に記載のシステム。
さらに、前記ＥＭＳが、前記第二データを読み取るとともに、応答し、且つ、ウェブサービスページ上で表示することを特徴とする請求項１１に記載のシステム。
前記Ｎｏｎ－ＲＴＲＩＣフレームワークが、前記ＥＭＳから送信された前記第一サブスクリプションメッセージを受信する前に、さらに、
前記ＥＭＳが、第一登録プロセスを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに実行し、
前記ｒＡｐｐが、第二登録プロセスを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに実行する、
ことを特徴とする請求項１１に記載のシステム。
前記第一登録プロセスは、
前記ＥＭＳが、第一登録要求メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ＥＭＳの登録を要求する工程と、
前記ＥＭＳが、第一サブスクリプション要求メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ＥＭＳに必要なデータのサブスクリプションを要求する工程と、
前記ＥＭＳが、第一情報タイプの登録メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ＥＭＳにより提供される情報タイプの登録を要求する工程と、
前記ＥＭＳが、第一情報提供者登録メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ＥＭＳを情報提供者として登録することを要求する工程と、
を有することを特徴とする請求項１４に記載のシステム。
前記第二登録プロセスは、
前記ｒＡｐｐが、第二登録要求メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ｒＡｐｐの登録を要求する工程と、
前記ｒＡｐｐが、第二サブスクリプション要求メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ｒＡｐｐに必要なデータのサブスクリプションを要求する工程と、
前記ｒＡｐｐが、第二情報タイプの登録メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ｒＡｐｐにより提供される情報タイプの登録を要求する工程と、
前記ｒＡｐｐが、第二情報提供者登録メッセージを、前記Ｎｏｎ－ＲＴＲＩＣフレームワークに送信して、前記ｒＡｐｐを情報提供者として登録することを要求する工程と、
を有することを特徴とする請求項１４に記載のシステム。
前記ＥＭＳのＩＰアドレスは、前記第一サブスクリプションメッセージ、および、前記第一コールバックメッセージ中に含まれることを特徴とする請求項１１に記載のシステム。
前記ｒＡｐｐのＩＰアドレスは、前記第二サブスクリプションメッセージ、および、前記第二コールバックメッセージ中に含まれることを特徴とする請求項１２に記載のシステム。
前記Ｎｏｎ－ＲＴＲＩＣフレームワークは、サービス管理およびオーケストレーション（ＳＭＯ）内部インターフェースにより、前記ＥＭＳと接続されることを特徴とする請求項１１に記載のシステム。
前記Ｎｏｎ－ＲＴＲＩＣフレームワークは、Ｒ１インターフェースにより、前記ｒＡｐｐと接続されることを特徴とする請求項１１に記載のシステム。