特許 6909877 ホワイトボックスＯＴＮハードウェアデバイスを実現する方法および装置、記憶媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6909877

(24)【登録日】2021年7月7日

(45)【発行日】2021年7月28日

(54)【発明の名称】ホワイトボックスＯＴＮハードウェアデバイスを実現する方法および装置、記憶媒体

(51)【国際特許分類】

   G06F 8/30 20180101AFI20210715BHJP

   G06F 21/62 20130101ALI20210715BHJP

   H04B 10/07 20130101ALI20210715BHJP

   G06F 11/36 20060101ALI20210715BHJP

   H04L 12/24 20060101ALN20210715BHJP

【ＦＩ】

   G06F8/30

   G06F21/62

   H04B10/07

   G06F11/36 188

   !H04L12/24

【請求項の数】8

【全頁数】15

(21)【出願番号】特願2019-571933(P2019-571933)

(86)(22)【出願日】2018年6月29日

(65)【公表番号】特表2020-525931(P2020-525931A)

(43)【公表日】2020年8月27日

(86)【国際出願番号】CN2018093601

(87)【国際公開番号】WO2019001565

(87)【国際公開日】20190103

【審査請求日】2019年12月26日

(31)【優先権主張番号】201710520007.X

(32)【優先日】2017年6月30日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】511151662

【氏名又は名称】中興通訊股▲ふん▼有限公司

【氏名又は名称原語表記】ＺＴＥ ＣＯＲＰＯＲＡＴＩＯＮ

(74)【代理人】

【識別番号】110001195

【氏名又は名称】特許業務法人深見特許事務所

(72)【発明者】

【氏名】劉 大 偉

【審査官】 杉浦 孝光

(56)【参考文献】

【文献】 特表２０１３−５２９３２１（ＪＰ，Ａ）

【文献】 特表２０１５−５２４１２６（ＪＰ，Ａ）

【文献】 中国特許出願公開第１０３７４６７４６（ＣＮ，Ａ）

【文献】 熊川成正、外４名，仮想化ネットワーク適用に向けたホワイトボックススイッチ制御用ソフトウェアの実装，電子情報通信学会技術研究報告，日本，一般社団法人電子情報通信学会，２０１７年 ２月２３日，Vol.116 No.484，pp.217-222

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ８／００− ８／７７

Ｇ０６Ｆ １１／３６

Ｇ０６Ｆ ２１／６２

Ｈ０４Ｂ １０／０７

Ｈ０４Ｌ １２／２４

(57)【特許請求の範囲】

【請求項1】

ＯＴＮデバイスで採用されたハードウェアデバイスをグループ化処理して制約ルールを制定し、低階層アプリケーションプログラミングインターフェースＡＰＩを抽象化して形成するステップと、
ユーザが入力した低階層ＡＰＩのカスタマイズディスクリプションファイルを取得し、ユーザが入力した低階層ＡＰＩのカスタマイズディスクリプションファイルに基づいて共通コードとユーザコードとの接続コードを自動的に生成するステップと、を含み、
ＯＴＮデバイスで採用されたハードウェアデバイスをグループ化処理して制約ルールを制定するステップは、
前記ＯＴＮデバイスで採用されたハードウェアデバイスを、ビジネス処理系チップ、光電変換系チップ、及びクロススケジューリング系チップに分けるステップと、
前記ビジネス処理系チップ、光電変換系チップ、クロススケジュール系チップの制約ルールを制定し、ビジネスルールに基づいたＡＰＩの機能および前記ＡＰＩの機能の参入規定を形成するステップと、を含み、
前記カスタマイズディスクリプションファイルは、
分野特定言語ＤＳＬ技術を採用し、前記ビジネス処理系チップ、光電変換系チップ、クロススケジュール系チップの差分を抽出して前記カスタマイズディスクリプションファイルを形成するという方式によって形成される、
端末装置に応用されてホワイトボックス光伝送ネットワークＯＴＮハードウェアデバイスを実現する方法。

【請求項2】

前記ＯＴＮデバイスで採用されたハードウェアデバイスから標準オーバーヘッドフォーマットをエクスポートするステップと、
エクスポートされた標準オーバーヘッドフォーマットに基づいて、原子機能インターフェースを抽象化するステップと、
原子機能コードに共通コードを書き込むことができるように、抽象化された原子機能インターフェースに基づいて、原子機能コードを自動的に生成するステップと、を含む
請求項１に記載の方法。

【請求項3】

前記低階層ＡＰＩを抽象化処理して高階層ＡＰＩを形成するステップをさらに含む
請求項１に記載の方法。

【請求項4】

ＯＴＮデバイスで採用されたハードウェアデバイスをグループ化処理して制約ルールを制定し、低階層アプリケーションプログラミングインターフェースＡＰＩを抽象化して形成するように配置された第１の抽象化処理モジュールと、
低階層のビジネスロジックを共通処理するように、ユーザが入力した低階層ＡＰＩのカスタマイズディスクリプションファイルを取得し、ユーザが入力した低階層ＡＰＩのカスタマイズディスクリプションファイルから共通コードとユーザコードとの接続コードを自動的に生成するように配置されたコンパイラと、を含み、
前記第１の抽象化処理モジュールは、
前記ＯＴＮデバイスで採用されたハードウェアデバイスを、ビジネス処理系チップ、光電変換系チップ、クロススケジュール系チップに分けるように配置された抽象化手段と、
前記ビジネス処理系チップ、光電変換系チップ、クロススケジュール系チップの制約ルールを制定し、ビジネスルールに基づいたＡＰＩの機能および前記ＡＰＩの機能の参入規定を形成するように配置された制約ルール制定手段と、
分野特定言語ＤＳＬ技術を採用し、前記ビジネス処理系チップ、光電変換系チップ、クロススケジュール系チップの差分を抽出して前記カスタマイズディスクリプションファイルを形成するように配置されたディスクリプションファイル形成手段と、を含む、
ホワイトボックス光伝送ネットワークＯＴＮハードウェアデバイス。

【請求項5】

前記ＯＴＮデバイスで採用されたハードウェアデバイスから標準オーバーヘッドフォーマットをエクスポートするように配置されたエクスポートモジュールと、
エクスポートされた標準オーバーヘッドフォーマットに基づいて、原子機能インターフェースを抽象化するように配置された原子機能インターフェース抽象化モジュールと、をさらに含み、
前記コンパイラはさらに、原子機能コードに共通コードを書き込むことができるように、抽象化された原子機能インターフェースに基づいて原子機能コードを自動的に生成するように配置された
請求項４に記載のデバイス。

【請求項6】

前記低階層ＡＰＩを抽象化処理して高階層ＡＰＩを形成するように配置された第２の抽象化処理モジュールをさらに含む
請求項４に記載のデバイス。

【請求項7】

メモリと、プロセッサと、前記メモリに格納されかつ前記プロセッサ上で実行可能なホワイトボックスＯＴＮハードウェアデバイスの抽象化プログラムと、を含み、前記ホワイトボックスＯＴＮハードウェアデバイスの抽象化プログラムが前記プロセッサによって実行される時に請求項１〜３のいずれか１項に記載のホワイトボックスＯＴＮハードウェアデバイスを実現する方法のステップを実現する
ホワイトボックスＯＴＮハードウェアデバイス。

【請求項8】

プロセッサによって実行される時に請求項１〜３のいずれか１項に記載のホワイトボックスＯＴＮハードウェアデバイスを実現する方法のステップを実現する、ホワイトボックスＯＴＮハードウェアデバイスの抽象化プログラムが記憶されている、コンピュータ読み取り可能な記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本公開は、通信技術分野に関し、特に、ホワイトボックス光伝送ネットワーク（OTN）ハードウェアデバイスを実現する方法および装置、コンピュータ読み取り可能な記憶媒体に関するものである。

【背景技術】

【0002】

光ネットワーク伝送技術分野において、通信機器メーカーは伝送機器を開発する過程において、ソフトウェアとハードウェアを密にまとめ、すなわち、ソフトウェアとハードウェアの高度な結合という開発方式を採用するのが一般的である。

【発明の概要】

【0003】

一態様において、本公開は、OTNデバイスで採用されたハードウェアデバイスを抽象化処理して制約ルールを制定し、低階層アプリケーションプログラミングインターフェースAPIを形成するステップと、ユーザが入力した低階層APIのカスタマイズディスクリプションファイルを取得し、ユーザが入力した低階層APIのカスタマイズディスクリプションファイルに基づいて共通コードとユーザコードとの接続コードを自動的に生成するステップと、を含む、ホワイトボックス光伝送ネットワークOTNハードウェアデバイスを実現する方法を提供する。

【0004】

別の様態において、本公開は、OTNデバイスで採用されたハードウェアデバイスを抽象化処理して制約ルールを制定し、低階層アプリケーションプログラミングインターフェースAPIを形成するように配置された第1の抽象化処理モジュールと、低階層のビジネスロジックを共通処理するように、ユーザが入力した低階層APIのカスタマイズディスクリプションファイルを取得し、ユーザが入力した低階層APIのカスタマイズディスクリプションファイルから共通コードとユーザコードとの接続コードを自動的に生成するように配置されたコンパイラと、を含む、ホワイトボックス光伝送ネットワークOTNハードウェアデバイスを実現する装置を提供する。

【0005】

別の様態において、本公開は、メモリと、プロセッサと、前記メモリに格納されかつ前記プロセッサ上で実行可能なホワイトボックスOTNハードウェアデバイスの抽象化プログラムと、を含み、前記ホワイトボックスOTNハードウェアデバイスの抽象化プログラムが前記プロセッサによって実行される時に本文に記載のホワイトボックスOTNハードウェアデバイスを実現する方法のステップを実現する、ホワイトボックスOTNハードウェアデバイスを実現する装置を提供する。

【0006】

別の様態において、本公開は、プロセッサによって実行される時に本文に記載のホワイトボックスOTNハードウェアデバイスを実現する方法のステップを実現する、ホワイトボックスOTNハードウェアデバイスの抽象化プログラムが記憶されている、コンピュータ読み取り可能な記憶媒体を提供する。

【図面の簡単な説明】

【0007】

【図1】図1は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する方法のフロー模式図である。

【図2】図2は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する方法における抽象化処理および制約ルール制定のフロー模式図である。

【図3】図3は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する方法における原子機能抽象化のフロー模式図である。

【図4】図4は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する方法の別のフローチャートである。

【図5】図5は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する装置の構造模式図である。

【図6】図6は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する装置における第1の抽象化処理モジュールの構造模式図である。

【図7】図7は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する装置の別の構造模式図である。

【図8】図8は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する装置の構造模式図である。

【図9】図9は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイス抽象化のシステム構造模式図である。

【発明を実施するための形態】

【0008】

本公開の目的の実現、機能特徴、及び利点について、実施例を組み合わせて、図面を参照してさらに説明する。

【0009】

本公開が解決しようとする技術課題、技術案および有益な効果をより明瞭かつ明白にするために、以下、図面と実施例を組み合わせて、本公開についてさらに詳しく説明する。ここに記述する具体的な実施例は本公開を説明するためのものに過ぎず、本公開を限定するものではないと理解されたい。

【0010】

光ネットワーク伝送技術分野において、通信機器メーカーは伝送機器を開発する過程において、ソフトウェアとハードウェアを密にまとめ、すなわち、ソフトウェアとハードウェアの高度な結合という開発方式を採用するのが一般的である。

【0011】

このような開発方式には次のような不備がある。まず、デバイスボード間で、ハードウェアの違いにより上位のソフトウェアを多重化することができないため、大量の重複開発が存在するというものである。次に、ハードウェアの違いにより、毎回、各プロジェクトと各製品を最初から始めなければならず、人員の交代、開発者の変更に伴い、これまでの経験や優れた設計を効果的に引き継ぐことができず、ひいては数多くの設計、開発およびテストの無駄を招くほか、キャリアやインターネットの、開発サイクルに対する要求のさらなる短縮化に伴い、顧客からは機器メーカーの開発サイクルに対して新たな、より厳しい要求が提示され、従来の開発方式では、顧客のこのような要求を満たすことができないという点が挙げられる。さらに、開発サイクル短縮についての顧客の厳しい要求を満たすためには、機器メーカの開発、テストの自動化レベルを向上させなければならないが、従来の開発方式では自動化業務を展開していくことが困難である。また、SDN(Software Defined Network、ソフトウェア定義型ネットワーク)やNFV(Network Function Virtualization、ネットワーク機能仮想化)の急速な発展に伴い、将来のデバイスには益々オープンな相互運用性が要求され、かつ、デバイス性能、柔軟性、相互運用性に対しさらに高い要求が求められる。機器メーカーには、ハードウェアの違いを可能な限り抑制し、ハードウェアデバイスを高度に抽象化して、ソフトウェアとハードウェアの分離を実現することがさらに求められている。

【0012】

よって、本公開は、ホワイトボックス光伝送ネットワーク（OTN）ハードウェアデバイスを実現する方法および装置、コンピュータ読み取り可能な記憶媒体を特別に提供し、これは、関連技術の制限および欠点に起因する問題のうちの1つまたは複数を実質的に回避している。

【0013】

一態様において、本公開はホワイトボックス光伝送ネットワークOTNハードウェアデバイスを実現する方法を提供する。図1は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する方法のフロー模式図である。図1を参照すると、いくつかの実施例において、当該方法はステップS10を含んでよい。

【0014】

ステップS10では、OTN（Optical Transport Network、光伝送ネットワーク）デバイスで採用されたハードウェアデバイスを抽象化処理して制約ルールを制定し、低階層API（Application Programming Interface、アプリケーションプログラミングインターフェース）を形成する。

【0015】

図2は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する方法における抽象化処理および制約ルール制定のフロー模式図である。図2を参照すると、いくつかの実施例において、OTNデバイスで採用されたハードウェアデバイスを抽象化処理して制約ルールを制定する前記ステップは、ステップS102とステップS104を含んでよい。

【0016】

ステップS102では、前記OTNデバイスで採用されたハードウェアデバイスを、ビジネス処理系チップ、光電変換系チップ、及びクロススケジューリング系チップに抽象化する。

【0017】

ステップS104では、前記ビジネス処理系チップ、光電変換系チップ、クロススケジュール系チップの制約ルールを制定する。

【0018】

本公開の実施例ではホワイトボックス技術の思想を採用し、OTNデバイスの角度からは、OTNデバイスを構成するために採用されたハードウェアデバイスをビジネス処理系チップ、光電変換系チップ、及びクロススケジューリング系チップの3種類に抽象化し、光伝送デバイスビジネスの角度からは、OTNデバイスを構成した3種類のチップに対し制約ルールを制定し、ビジネスルールに基づいたAPIの機能およびその参入規定を形成する。ハードウェア選択過程において、いかなるメーカーのチップも当該機能を備えていなければならず、当該機能を実現可能なSDK（Software Development Kit、ソフトウェア開発キット）またはSDKの組み合わせを提供する必要がある。

【0019】

図1を参照すると、前記方法はステップS11をさらに含んでよい。ステップS11では、低階層のビジネスロジックを共通処理するように、ユーザが入力した低階層APIのカスタマイズディスクリプションファイルを取得し、ユーザが入力した低階層APIのカスタマイズディスクリプションファイルから共通コードとユーザコードとの接続コードを自動的に生成する。

【0020】

本公開の実施例では、DSL（Domain Specific Language、分野特定言語）技術を採用することができ、前記ビジネス処理系チップ、光電変換系チップ、クロススケジュール系チップの差分を抽象化して前記カスタマイズディスクリプションファイルを形成する。ハードウェアを私有化するユーザーコードと共通の制御ロジックとの相互分離を実現する。

【0021】

本公開の実施例をより良く説明するために、図9を参照して以下に説明する。図9は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイス抽象化のシステム構造模式図である。

【0022】

いくつかの実施例において、図9のシステムは、ビジネス処理チップドライバーライブラリ1001、光電変換チップドライバーライブラリ1002、クロスチップドライバーライブラリ1003、カスタマイズディスクリプションファイル1004、カスタムプライベートコード1005、Cコード自動生成コンパイラ1006、HDLビジネス処理モジュール1007、HDL光電変換モジュール1008、HDLクロススケジュールモジュール1009、HDL保護逆変換モジュール1010、HDL機能アラート保守管理モジュール1011、HDLクロック時間処理モジュール1012、HALビジネス処理モジュール1013、HAL光電変換モジュール1014、HALクロススケジュールモジュール1015、HAL保護逆変換モジュール1016、HAL機能アラート保守管理モジュール1017、HALクロック時間処理モジュール1018、自動テスト1019、高層ビジネス処理モジュール1020を含んでよい。

【0023】

OTNビジネスに対する理解に基づいて、(1)ビジネス配置管理、(2)光電変換配置管理、(3)クロススケジュール配置管理、(4)保護逆変換配置管理モジュール、(5)機能アラート配置管理モジュール、(6)クロック時間配置管理モジュール、(7)自動テストモジュールおよび(8)高層ビジネス処理モジュールという8つの機能を横方向に抽象化することができる。

【0024】

以下、(1)ビジネス配置管理を例として説明する。
ビジネス処理チップドライバーライブラリ1001において、ドライバーライブラリにチップaとチップbという2種類のチップが存在すると仮定し、OTN分割ビジネスの配置を実現する必要があると仮定する。SDKの制約ルールは、以下の形式を満たさなければならない。

【0025】

UINT32 xxxx_svc_cfg_otu_oduj21_api(TOduj32Para oduj21_para)。
以上の仮定によれば、チップaに対して、UINT32 sdk_a_svc_cfg_otu_oduj21_api(TOduj32Para oduj21_para)と、当該チップが自身のSDKを呼び出して分割ビジネスの配置機能を完成することを実現しなければならない。チップbに対しても、UINT32 sdk_b_svc_cfg_otu_oduj21_api(TOduj32Para oduj21_para)と、当該チップが自身のSDKを呼び出して分割ビジネスの配置機能を完成することを実現しなければならない。

【0026】

カスタマイズディスクリプションファイル1004において、ユーザが使用するのがチップaであるとすれば、ユーザは当該ディスクリプションファイルにおいて、ビジネスチップがチップaすなわち、{svc_chip_name, a}を使用していることを明示する。

【0027】

Cコード自動生成コンパイラ1006がカスタマイズディスクリプションファイル1004における記述{svc_chip_name, a}を読み出した時、HDL(Hardware Description Language、ハードウェア記述言語)ビジネス処理モジュール1007のADPTインターフェースの実現コードの下半分を自動的に生成する。すなわち、UINT32 adpt_svc_cfg_otu_oduj21_api(TOduj32Para oduj21_para) {return sdk_a_svc_cfg_otu_oduj21_api(TOduj32Para oduj21_para);}である。

【0028】

HDLビジネス処理モジュール1007の上半分はHAL(Hardware Abstraction Layer、ハードウェア抽象化層)ビジネス処理モジュール1013の分解した対応機能に基づいて、関連する共通処理を行い、入力構造oduj21_paraに基づいてadpt_svc_cfg_otu_oduj21_apiを呼び出して、当該層で実現する必要のある共通処理機能を実現する。

【0029】

(2)光電変換配置管理、(3)クロススケジュール配置管理は(1)ビジネス配置管理の処理方法に類似するため、ここでは説明を省略する。

【0030】

図3は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する方法における原子機能抽象化のフロー模式図である。図3を参照すると、いくつかの実施例において、保護逆変換の標準化処理を実現するために、前記方法はステップS12〜ステップS14をさらに含んでよい。

【0031】

ステップS12では、前記OTNデバイスで採用されたハードウェアデバイスから標準オーバーヘッドフォーマットをエクスポートする。

【0032】

いくつかの実施例において、FPGAを用いてSDKからITU-TG.709規格に適合するオーバーヘッドの方式をエクスポートし、形態の異なるチップの中から当該標準オーバーヘッドフォーマットをエクスポートすることができる。

【0033】

ステップS13では、エクスポートされた標準オーバーヘッドフォーマットに基づいて、原子機能インターフェースを抽象化する。

【0034】

ステップS14では、原子機能コードに共通コードを書き込むことができるように、抽象化された原子機能インターフェースに基づいて、原子機能コードを自動的に生成する。

【0035】

以下、図9を参照して、(4)保護逆変換配置管理モジュールを例として説明する。
(4)保護逆変換配置管理モジュールについて、当該モジュールは、主にビジネスチップのオーバヘッドをFPGA(Field Programmable Gate Array、フィールドプログラマブルゲートアレイ)にエクスポートし、FPGAの配置によって、アラームが変化して中断し、アラームの変化に基づきビジネスの逆変換を実現する。

【0036】

当該モジュールはビジネスの角度から、保護配置指令を機能的に抽象化し、若干の原子機能インターフェースを抽象化し、当該原子機能インターフェースに基づいて、FPGAハードウェア開発者を制約し、これらの原子機能を必ずカバーするようFPGA開発者に求める。

【0037】

これら原子機能インターフェースに基づいて、カスタマイズディスクリプションファイル1004に、当該原子機能インターフェースに対応するFPGAアドレスを記述し、カスタムプライベートコード1005に、当該FPGAアドレスを読み書きする読み書き関数を登録し、Cコード自動生成コンパイラ1006によってHDL層に必要な原子機能関数を自動的に生成し、HDL層によって原子機能の組み合わせを完成し、HAL層を使用に供する。

【0038】

(6)クロック時間配置管理モジュールは(4)保護逆変換配置管理モジュールの処理方法に類似するため、ここでは説明を省略する。

【0039】

(5)機能アラート配置管理モジュールについて、機能アラートモジュールは、機能アラートの数が夥しいということと、機能アラートの処理が簡単であって、1つのSDKの呼び出しまたは1つのレジスタアドレスの読み書きをするだけであるという特徴を有する。上記2つの特徴に基づいて、カスタマイズディスクリプションファイル1004の記述においては、あるアラームについて、どのSDKのAPIを使用する必要があるか、APIがどのようなパラメータを書き込む必要があるかについて記述するだけでよい。Cコード自動生成コンパイラ1006によって、HDL層に必要な機能アラート関数および、当該原子関数に基づく組み合わせ関数を自動的に生成し、HAL層呼び出しに供する。

【0040】

図4は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する方法の別のフローチャートである。図4を参照すると、いくつかの実施例において、前記方法はステップS10とステップS11（その詳しい説明は図1の記述を参照されたい）以外に、ステップS15をさらに含む。

【0041】

ステップS15では、前記低階層APIを抽象化処理して高階層APIを形成する。
本公開の実施例において、低階層のAPI粒度が比較的細かいので、これを基に再度抽象化し、ユーザの使い勝手のよい、より高階層のAPIを形成する必要がある。高層使用の角度から低階層APIをさらに抽象化し、コンパクトなAPIを形成して高層ユーザへ提供する。

【0042】

高階層APIは、NOS(Network Operating System、ネットワークオペレーティングシステム)、SDNなどの高層ユーザの使用に供されてもよく、さらに、高階層APIは、コンパクトで比較的安定しているため、これに基づいて自動化スクリプトを開発することが可能であり、迅速に生産される製品に迅速なフィードバック機構を提供する。また、コンパクトで高階層のAPIはハードウェアと関係がないため、SDNとそのNVFのニーズによく適合する。

【0043】

以下、図9の(7)自動テストモジュールおよび(8)高層ビジネス処理モジュールを例として説明する。

【0044】

(7)自動テストモジュールについては、HAL層の標準インターフェースに基づいて、自動受け入れテスト開発を行う。

【0045】

(8)高層アプリケーションモジュールについては、主にHAL層ハードウェアと関係のないインターフェースを呼び出して、SDN、WASON（WDM/OTN Automatically Switched Optical Network、WDM/OTNに基づく自動交換光ネットワーク）およびNOSなどの高級機能を完成する。

【0046】

本公開の実施例のホワイトボックスOTNハードウェアデバイスを実現する方法では、OTNデバイスで採用されたハードウェアデバイスを抽象化して低階層APIを形成し、ユーザが入力した低階層APIのカスタマイズディスクリプションファイルから共通コードとユーザコードとの接続コードを自動的に生成することによって、低階層のビジネスロジックを共通処理することを実現し、ホワイトボックスOTNのソフトウェアとハードウェアの分離を実現しており、ハードウェアの違いによるソフトウェアの重複開発を防止し、ハードウェア交換の過程で設計、開発、テストをゼロから始める必要がなく、開発から生産までの時間が省かれている。

【0047】

別の様態において、本公開はホワイトボックス光伝送ネットワークOTNハードウェアデバイスを実現する装置を提供する。図5は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する装置の構造模式図である。図5に示すように、いくつかの実施例において、ホワイトボックスOTNハードウェアデバイスを実現する装置は第1の抽象化処理モジュール21とコンパイラ22を含んでよい。

【0048】

前記第1の抽象化処理モジュール21はOTNデバイスで採用されたハードウェアデバイスを抽象化処理して制約ルールを制定し、低階層アプリケーションプログラミングインターフェースAPIを形成するように配置されてよい。

【0049】

図6は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する装置における第1の抽象化処理モジュールの構造模式図である。図6を参照すると、いくつかの実施例において、前記第1の抽象化処理モジュール21は抽象化手段212および制約ルール制定手段214を含んでよい。

【0050】

前記抽象化手段212は前記OTNデバイスで採用されたハードウェアデバイスを、ビジネス処理系チップ、光電変換系チップ、及びクロススケジューリング系チップに抽象化するように配置されてよい。

【0051】

前記制約ルール制定手段214は前記ビジネス処理系チップ、光電変換系チップ、クロススケジュール系チップの制約ルールを制定するように配置されてよい。

【0052】

本公開の実施例ではホワイトボックス技術の思想を採用し、OTNデバイスの角度からは、OTNデバイスを構成するために採用されたハードウェアデバイスをビジネス処理系チップ、光電変換系チップ、及びクロススケジューリング系チップの3種類に抽象化し、光伝送デバイスビジネスの角度からは、OTNデバイスを構成した3種類のチップに対し制約ルールを制定し、ビジネスルールに基づいたAPIの機能およびその参入規定を形成する。ハードウェア選択過程において、あらゆるメーカーのチップは当該機能を備えていなければならず、当該機能を実現可能なSDKまたはSDKの組み合わせを提供する必要がある。

【0053】

前記コンパイラ22は低階層のビジネスロジックを共通処理するように、ユーザが入力した低階層APIのカスタマイズディスクリプションファイルを取得し、ユーザが入力した低階層APIのカスタマイズディスクリプションファイルから共通コードとユーザコードとの接続コードを自動的に生成するように配置されてよい。

【0054】

引き続き図6を参照すると、いくつかの実施例において、前記装置はディスクリプションファイル形成手段216をさらに含む。

【0055】

前記ディスクリプションファイル形成手段216は、DSL技術を採用し、前記ビジネス処理系チップ、光電変換系チップ、クロススケジュール系チップの差分を抽象化して前記カスタマイズディスクリプションファイルを形成するように配置されてよい。ハードウェアを私有化するユーザーコードと共通の制御ロジックとの相互分離を実現する。

【0056】

本公開の実施例をより良く説明するために、図9を参照して以下に説明する。
いくつかの実施例において、図9のシステムはビジネス処理チップドライバーライブラリ1001、光電変換チップドライバーライブラリ1002、クロスチップドライバーライブラリ1003、カスタマイズディスクリプションファイル1004、カスタムプライベートコード1005、Cコード自動生成コンパイラ1006、HDLビジネス処理モジュール1007、HDL光電変換モジュール1008、HDLクロススケジュールモジュール1009、HDL保護逆変換モジュール1010、HDL機能アラート保守管理モジュール1011、HDLクロック時間処理モジュール1012、HALビジネス処理モジュール1013、HAL光電変換モジュール1014、HALクロススケジュールモジュール1015、HAL保護逆変換モジュール1016、HAL機能アラート保守管理モジュール1017、HALクロック時間処理モジュール1018、自動テスト1019、高層ビジネス処理モジュール1020を含んでよい。

【0057】

OTNビジネスに対する理解に基づいて、(1)ビジネス配置管理、(2)光電変換配置管理、(3)クロススケジュール配置管理、(4)保護逆変換配置管理モジュール、(5)機能アラート配置管理モジュール、(6)クロック時間配置管理モジュール、(7)自動テストモジュールおよび(8)高層ビジネス処理モジュールという8つの機能を横方向に抽象化することができる。

【0058】

以下、(1)ビジネス配置管理を例として説明する。
ビジネス処理チップドライバーライブラリ1001において、ドライバーライブラリにチップaとチップbという2種類のチップが存在すると仮定し、OTN分割ビジネスの配置を実現する必要があると仮定する。SDKの制約ルールは、以下の形態を満たさなければならない。

【0059】

UINT32 xxxx_svc_cfg_otu_oduj21_api(TOduj32Para oduj21_para)。
以上の仮定によれば、チップaに対して、UINT32 sdk_a_svc_cfg_otu_oduj21_api(TOduj32Para oduj21_para)と、当該チップが自身のSDKを呼び出して分割ビジネスの配置機能を完成することを実現しなければならない。チップbに対しても、UINT32 sdk_b_svc_cfg_otu_oduj21_api(TOduj32Para oduj21_para)と、当該チップが自身のSDKを呼び出して分割ビジネスの配置機能を完成することを実現しなければならない。

【0060】

カスタマイズディスクリプションファイル1004において、ユーザが使用するのがチップaであるとすれば、ユーザは当該ディスクリプションファイルにおいて、ビジネスチップがチップaすなわち、{svc_chip_name, a}を使用していることを明示する。

【0061】

Cコード自動生成コンパイラ1006がカスタマイズディスクリプションファイル1004における記述{svc_chip_name, a}を読み出した時、HDL(Hardware Description Language、ハードウェア記述言語)ビジネス処理モジュール1007のADPTインターフェースの実現コードの下半分を自動的に生成する。すなわち、UINT32 adpt_svc_cfg_otu_oduj21_api(TOduj32Para oduj21_para) {return sdk_a_svc_cfg_otu_oduj21_api(TOduj32Para oduj21_para);}である。

【0062】

HDLビジネス処理モジュール1007の上半分はHAL(Hardware Abstraction Layer，ハードウェア抽象化層)ビジネスプロセスモジュール1013の分解した対応機能に基づいて、関連する共通処理を行い、入力構造oduj21_paraに基づいてadpt_svc_cfg_otu_oduj21_apiを呼び出して、当該層で実現する必要のある共通処理機能を実現する。

【0063】

(2)光電変換配置管理、(3)クロススケジュール配置管理は(1)ビジネス配置管理の処理方法に類似するため、ここでは説明を省略する。

【0064】

図7は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する装置の別の構造模式図である。図7を参照すると、いくつかの実施例において、保護逆変換の標準化処理を実現するために、前記装置はエクスポートモジュール23および原子機能インターフェース抽象化モジュール24をさらに含んでよい。

【0065】

前記エクスポートモジュール23は、前記OTNデバイスで採用されたハードウェアデバイスから標準オーバーヘッドフォーマットをエクスポートするように配置されてよい。

【0066】

いくつかの実施例において、前記エクスポートモジュール23はFPGAを用いてSDKからITU-TG.709規格に適合するオーバーヘッド方式をエクスポートし、形態の異なるチップから当該標準オーバーヘッドフォーマットをエクスポートすることができる。

【0067】

前記原子機能インターフェース抽象化モジュール24はエクスポートされた標準オーバーヘッドフォーマットに基づいて、原子機能インターフェースを抽象化するように配置されてよい。

【0068】

いくつかの実施例において、前記コンパイラ22はさらに、原子機能コードに共通コードを書き込むことができるように、抽象化された原子機能インターフェースに基づいて原子機能コードを自動的に生成するように配置されてよい。

【0069】

以下、図9を参照し、(4)保護逆変換配置管理モジュールを例として説明する。
(4)保護逆変換配置管理モジュールについては、当該モジュールは、主にビジネスチップのオーバヘッドをFPGA (Field Programmable Gate Array、フィールドプログラマブルゲートアレイ)にエクスポートし、FPGAの配置によって、アラームが変化して中断し、アラームの変化に基づきビジネスの逆変換を実現する。

【0070】

当該モジュールはビジネスの角度から、保護配置指令を機能的に抽象化し、若干の原子機能インターフェースを抽象化し、当該原子機能インターフェースに基づいて、FPGAハードウェア開発者を制約し、これらの原子機能を必ずカバーするようFPGA開発者に求める。

【0071】

これら原子機能インターフェースに基づいて、カスタマイズディスクリプションファイル1004に、当該原子機能インターフェースに対応するFPGAアドレスを記述し、カスタムプライベートコード1005に、当該FPGAアドレスを読み書きする読み書き関数を登録し、Cコード自動生成コンパイラ1006によってHDL層に必要な原子機能関数を自動的に生成し、HDL層によって原子機能の組み合わせを完成し、HAL層を使用に供する。

【0072】

(6)クロック時間配置管理モジュールは(4)保護逆変換配置管理モジュールの処理方法に近似するため、ここでは説明を省略する。

【0073】

(5)機能アラート配置管理モジュールについて、機能アラートモジュールは、機能アラートの数が夥しいということと、機能アラートの処理が簡単であって、1つのSDKの呼び出しまたは1つのレジスタアドレスの読み書きをするだけであるという特徴を有する。上記2つの特徴に基づいて、カスタマイズディスクリプションファイル1004の記述においては、あるアラームについて、どのSDKのAPIを使用する必要があるか、APIがどのようなパラメータを書き込む必要があるかについて記述するだけでよい。Cコード自動生成コンパイラ1006によって、HDL層に必要な機能アラート関数および、当該原子関数に基づく組み合わせ関数を自動的に生成し、HAL層呼び出しに供する。

【0074】

図7を参照すると、いくつかの実施例において、前記装置は第2の抽象化処理モジュール25をさらに含む。

【0075】

前記第2の抽象化処理モジュール25は前記低階層APIを抽象化して高階層APIを形成するように配置されてよい。

【0076】

本公開の実施例において、低階層のAPI粒度が比較的細かいので、これを基に再度抽象化し、ユーザの使い勝手のよい、より高階層のAPIを形成する必要がある。高層使用の角度から低階層APIをさらに抽象化し、コンパクトなAPIを形成して高層ユーザへ提供する。

【0077】

高階層APIは、NOS(Network Operating System、ネットワークオペレーティングシステム)、SDNなどの高層ユーザの使用に供されてもよく、さらに、高階層APIは、コンパクトで比較的安定しているため、これに基づいて自動化スクリプトを開発することが可能であり、迅速に生産される製品に迅速なフィードバック機構を提供する。また、コンパクトで高階層のAPIはハードウェアと関係がないため、SDNとそのNVFのニーズによく適合する。

【0078】

以下、図9の(7)自動テストモジュールおよび(8)高層ビジネス処理モジュールを例として説明する。

【0079】

(7)自動テストモジュールについては、HAL層の標準インターフェースに基づいて、自動受け入れテスト開発を行う。

【0080】

(8)高層アプリケーションモジュールについては、主にHAL層ハードウェアと関係のないインターフェースを呼び出して、SDN、WASON（WDM/OTN Automatically Switched Optical Network、WDM/OTNに基づく自動交換光ネットワーク）およびNOSなどの高級機能を完成する。

【0081】

本公開の実施例のホワイトボックスOTNハードウェアデバイスを実現する装置では、OTNデバイスで採用されたハードウェアデバイスを抽象化して低階層APIを形成し、ユーザが入力した低階層APIのカスタマイズディスクリプションファイルから共通コードとユーザコードとの接続コードを自動的に生成することによって、低階層のビジネスロジックを共通処理することを実現し、ホワイトボックスOTNのソフトウェアとハードウェアの分離を実現しており、ハードウェアの違いによるソフトウェアの重複開発を防止し、ハードウェア交換の過程で設計、開発、テストをゼロから始める必要がなく、開発から生産までの時間が省かれている。

【0082】

別の様態において、本公開はホワイトボックス光伝送ネットワークOTNハードウェアデバイスを実現する装置を提供する。図8は、本公開の実施例による、ホワイトボックスOTNハードウェアデバイスを実現する装置の構造模式図である。図8を参照すると、いくつかの実施例において、前記ホワイトボックスOTNハードウェアデバイスを実現する装置は、メモリ31と、プロセッサ32と、前記メモリ31に格納されかつ前記プロセッサ32上で実行可能なホワイトボックスOTNハードウェアデバイスの抽象化プログラムと、を含み、前記ホワイトボックスOTNハードウェアデバイスの抽象化プログラムが前記プロセッサによって実行される時に本文に記載のホワイトボックスOTNハードウェアデバイスを実現する方法のステップを実現する。

【0083】

本公開の実施例のホワイトボックスOTNハードウェアデバイスを実現する装置では、OTNデバイスで採用されたハードウェアデバイスを抽象化して低階層APIを形成し、ユーザが入力した低階層APIのカスタマイズディスクリプションファイルから共通コードとユーザコードとの接続コードを自動的に生成することによって、低階層のビジネスロジックを共通処理することを実現し、ホワイトボックスOTNのソフトウェアとハードウェアの分離を実現しており、ハードウェアの違いによるソフトウェアの重複開発を防止し、ハードウェア交換の過程で設計、開発、テストをゼロから始める必要がなく、開発から生産までの時間が省かれている。

【0084】

別の様態において、本公開はコンピュータ読み取り可能な記憶媒体を提供する。いくつかの実施例において、前記コンピュータ読み取り可能な記憶媒体上には、プロセッサによって実行される時に本文に記載のホワイトボックスOTNハードウェアデバイスを実現する方法のステップを実現する、ホワイトボックスOTNハードウェアデバイスの抽象化プログラムが記憶されている。

【0085】

本公開の実施例のコンピュータ読み取り可能な記憶媒体では、OTNデバイスで採用されたハードウェアデバイスを抽象化して低階層APIを形成し、ユーザが入力した低階層APIのカスタマイズディスクリプションファイルから共通コードとユーザコードとの接続コードを自動的に生成することによって、低階層のビジネスロジックを共通処理することを実現し、ホワイトボックスOTNのソフトウェアとハードウェアの分離を実現しており、ハードウェアの違いによるソフトウェアの重複開発を防止し、ハードウェア交換の過程で設計、開発、テストをゼロから始める必要がなく、開発から生産までの時間が省かれている。

【0086】

なお、上記装置実施例と方法実施例は同一の思想に属し、その具体的な実現過程の詳細については方法実施例を参照されたく、かつ方法実施例における技術特徴は装置実施例においていずれも対応して適用されるため、ここではその説明を省略する。

【0087】

以上の実施の形態の説明から、上記実施例の方法はソフトウェアに、必要な汎用ハードウェアプラットフォームを加えるという形で実現でき、当然ながらハードウェアでも実現できるが、多くの場合、前者がより好適な実施の形態であるということを当業者は明瞭に理解できる。このような理解に基づいて、本公開の技術案の実質、または関連技術に貢献する部分は、ソフトウェア製品という形態で体現することができ、記憶媒体（例えば、ROM / RAM、磁気ディスク、光ディスク）に記憶された該コンピューターソフトウェア製品は、本公開の各実施例に記載の方法を端末装置(携帯電話、コンピュータ、サーバ、空調機、またはネットワークデバイスなどであってよい)に実行させるための若干のコマンドを含む。

【0088】

以上、図面を参照しながら本公開のいくつかの実施例について説明したが、本公開の請求範囲はこれにより限定されるのではない。当業者は、本公開の範囲及び趣旨から逸脱しない範囲で、本公開を様々な変形形態で実現することができ、例えば、1つの実施例の特徴として、別の実施例に用いてさらなる実施例を実現することができる。本公開の技術思想の中でなされたあらゆる修正、均等な置き換えおよび改善はいずれも、本公開の請求範囲内にある。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】