JP2003520551A

JP2003520551A - デジタル無線基地局

Info

Publication number: JP2003520551A
Application number: JP2001553680A
Authority: JP
Inventors: フェリス・ギャビン・ロバート
Original assignee: レイディオスケープリミテッド
Priority date: 2000-01-24
Filing date: 2001-01-24
Publication date: 2003-07-02
Also published as: US20030008684A1; WO2001054300A3; WO2001054300A2; GB0101889D0; GB2382498A; EP1260028A2; US20070005327A1; GB2382498B

Abstract

(57)【要約】【課題】１以上のベースバンド処理用アルゴリズムを高水準ソフトウェアを用いて表すことを可能にするのに適したハードウェア抽象化層を用いてプログラムされるデジタル無線基地局が開示される。【解決手段】一般用プロトコルとハードウェアとによって、基地局（従来、非常に高価な、ベンダによりロックされたアプリケーション専用製品）が、単にソフトウェアの変更にすぎない多くの様々な変調規格を実行する能力を持つ汎用性のある、調整可能なベースバンド・プラットフォームに変えられる。ＩＰは、このデバイスをバックネットと接続するために使用される。またＩＰは、公開されたデータと制御書式とを用いて、サード・パーティのＲＦモジュールからデジタル化されたＩＦを送出したり、サード・パーティのＲＦモジュールへ送出したりするためにも利用される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

本発明はデジタル無線基地局に関する。基地局とはＵＭＴＳ（ユニバーサル移
動電話システム）のような無線通信システムにおける送受信装置用ノードである
。従来の方式では、１つの基地局は複数のユーザ用装置（ＵＥ）の端末と交信す
るようになっている。‘通信する’及び‘通信’という用語は１方向通信（無線
放送など）、２方向通信（ＵＭＴＳなど）及び１対１と１対多の通信をカバーす
るものである。

【０００２】

【従来の技術】

デジタル無線通信基地局におけるデジタル信号処理は、低いラテンシと、高い
数値命令ローディングと、大容量ＤＭＡチャネルとを有する広い（すなわち高度
に並列の）アルゴリズムによって特徴づけられる。基地局を取り囲む環境は厳し
い環境であり、従来は、ＡＳＩＣ（特定用途向け集積回路）がしばしば利用され
るアプリケーション専用ハードウェアによって満されてきた。これらの種類のハ
ードウェア・ベースのデジタル無線通信基地局は製造に１年以上を要する場合が
あり、さらに、これらの基地局に関連する多大の開発費用を要する場合がある。
また、デジタル無線通信基地局においてソフトウェア・アーキテクチャも利用さ
れてきたが、これらのアーキテクチャは、Ｃ言語などの非オブジェクト指向言語
と、制限されたバーチャル・マシン（ＲＴＯＳ層）と、ＶＨＤＬなどの非直感的
ハードウェア記述システムとをベースとしているため、切り離せないように一体
化されて、扱い難い傾向があった。

【０００３】この結果、実際には、基地局ベンダが、ネットワーク・プロバイダに、ハード
ウェア、ソフトウェア、ＲＦコンポーネント（これらすべては最適ではない構成
である場合が非常に多い）の一括購入を強いることが可能であった。基地局の中
へ閉じ込められた（または実質的に閉鎖された）インターフェースのために、や
はりそのベンダの基地局コントローラを使用せざるを得ず、それがさらに、品質
についての選択肢を狭め、品質の低下へつながることになった。また、基底を成
す通信規格の重要な変更により、‘大幅な（forklift）グレードアップ’が非常
に頻繁に求められ、オンサイトでのハードウェアの改変を余儀なくされてきた。

【０００４】しかし（ＵＭＴＳのような）デジタル無線規格は非常に複雑なものであるため
、また、非常に急速に変更されるため、これらの従来方式のハードウェアベース
の設計による解決方法の適用がますます困難になりつつある。ＰＣの非アナログ
領域（arena）へ目を移せば、現在のデジタル無線通信基地局の設計上の柔軟性
の無さを最も硬直した対照的な形で見ることができる。ＰＣによって、ハードウ
ェア抽象化層（ウィンドウズＴＭのバーチャル・マシン）の中にまとめて包みこ
まれた（wrapped up）適切なセットのハードウェア資源（スクリーン、メモリ、
プロセッサ、キーボードなど）が提供され、これらのハードウェア資源は広範囲
のアプリケーションの要求を満たすのに十分であり、その場合、これらのアプリ
ケーションは高レベルのソフトウェアを十全に用いる開発も可能となる。ソフト
ウェア内のアプリケーション・ニーズの解決にとって多くの利点がある。すなわ
ち製造スピードが早まり、相対的に製造コストが低くなり（これにより多数のプ
レイヤのマーケットへの参入が可能となり、競争が生じる）、最終製品の配送コ
ストと在庫コストはほとんどゼロとなる。

【０００５】また、ＰＣは汎用性のある拡張可能なハードウェアによる設計が行われ、複数
のハードウェア・ベンダが競争して改良されたハードウェアや周辺機器の組立て
を行うことが可能となり、利用可能性と品質のアップと、エンドユーザのコスト
ダウンが促進される。

【０００６】非アナログのデジタル信号処理（ＤＳＰ）の世界（特に基地局の設計）への同
一パラダイムの適用は現在まで着想されたことはなかった。その理由として、Ｄ
ＳＰ／基地局の世界が、ビジネス用／家庭用アプリケーションの空間とは全く異
なるセットのアルゴリズム要件を持っていたということが挙げられる。

【０００７】

【発明が解決しようとする課題】

本発明の第１の態様では、ベースバンド信号処理に適したバーチャル・マシン
層を備えてデジタル無線通信基地局がプログラムされる。このバーチャル・マシ
ン層は、基底を成す‘エンジン’に対して高ＭＩＰＳ機能の呼出しを行う高水準
ソフトウェアを用いて１以上のベースバンド処理用データ・フローを表すことを
可能にするのに適している。

【０００８】本発明の１つの実施構成では、一般用（commodity）プロトコルとハードウェ
アとが利用され、（通常、非常に高価な、ベンダによりロックされたアプリケー
ション専用製品である）基地局は、単にソフトウェアの変更にすぎない多くの様
々な変調規格の実行能力を持つ汎用性のある、調整可能なベースバンド・プラッ
トフォームに変えられる。ＩＰは、このデバイスをバックネットと接続するため
に使用される。またＩＰは、公開されたデータフォーマットと制御フォーマット
とを用いて、サード・パーティのＲＦモジュールからデジタル化されたＩＦを送
出したり、サード・パーティのＲＦモジュールへＩＦを送出したりするためにも
利用される。一般用ハードウェアと、分解（decomposition）と、公開された規
格とを用いて、基地局をソフトウェア領域（arena）の中へ移すことに焦点を合
わせる本アプローチは大きな利点の提供を約束するものであり、同時に、新しい
通信プロトコルの採用に伴う固有技術に関わるリスクを大幅に減少させるもので
もある。これらの一般原則は以下のように拡張を行うことが可能である：すなわ
ち、実施構成において、ハードウェア抽象化層はＰＣＩバス・バックプレーンを
含むハードウェア上で稼動する。業界規格３２ビット×３３ＭＨｚＰＣＩ−バッ
クプレーンを使用することにより、以下の（ｉ）〜（ｉｉ）が利用可能となる：
（ｉ）ＰＣ領域に予め限定した、広範囲の優れたかつ低価格のデバイス（バス・
マスターリングＤＭＡブリッジ・チップなど）；（ｉｉ）（その広範囲の開発用
ツールと周辺機器に対するサポートとを備えた）開発用プラットフォームとして
のＰＣ。また、遠隔モニタ用プラットフォームとしてＰＣの利用が可能にもなる
。バーチャル・マシン内のハードウェア・エレメントは、適切な、アーキテクチ
ャから見てニュートラルなメッセージ通信システムを利用する通信を行うことも
可能である。例えば、Ｉ２０対応メッセージ通信の利用が可能である：業界で広
く使用されているメッセージ通信の使用は閉鎖型専有システムから、多くの様々
なサプライヤが開発を目指すことができるオープン・システムに向けての本発明
の一般的アプローチを例示するものである。

【０００９】このアプローチのさらなる例として、開放型インターフェースであるインター
フェースを介して基地局と接続するＲＦエレメント向けのアプローチがある。従
来、閉鎖型専有インターフェースが標準的なインターフェースであった。これら
のインターフェースのために、非常に専門的なアナログ設計の熟練技術を持つＲ
Ｆサプライヤでも製品開発を行うことは困難とされてきた。それは、複雑で急速
に変化するデジタル基地局の設計についての知識が要求されることに起因してい
た。しかし、インターフェースをオープンなものにすることにより、代わりに、
単純なインターフェース仕様を満すＲＦエレメントを設計することで、基地局の
基底を成す、複雑な要件についての詳細な知識がなくても製品開発が可能となる
ため、ＲＦサプライヤでも実際上競争に参入することが可能となる。開放型イン
ターフェースを以下のコンポーネントの中の１以上のものと定義することもでき
る：（ｉ）給電（ｉｉ）データ（ｉｉｉ）制御（ｉｖ）タイミング／同期（ｖ）状態

【００１０】また、実施構成では標準的ＩＰベースのプロトコルが使用される：基地局はＩ
ＰベースのデジタルＩＦフィードを無線塔へ送る。ＩＰフィードは、複数のＲＦ
ユニットまで出力される。また、無線塔で受信した信号から得られるＩＰフィー
ドを下の複数のプロセッサ・ボードへ受け渡すことができる。標準的ＩＰベース
のプロトコルを使用して、広範囲のＩＰベースのコンポーネントと専門的技術と
の利用が可能となり、コストが低下し、サード・パーティの設計による貢献が促
進される。１つの望ましい実施構成では、ベアラを介してＲＴＰ／ＵＤＰ／ＩＰ
プロトコルをサポートするＲＦの‘ヘッド’から及びＲＦの‘ヘッド’へ送信さ
れるデータ・コンポーネント用の基底を成すベアラとしてバスＬＶＤＨ（低電圧
差分信号）が使用される。別の実施構成では、（ファイバ・チャネルなどの）光
ファイバ・ベアラがベアラとして使用される。光ファイバ・ベアラの使用は、プ
ロパーの基地局とＲＦヘッドとの間の距離が大きくなるにつれて、また、（より
高いＩＦ名目搬送波周波数中心周波数の結果として、若しくは、ＡＤＣ／ＤＡＣ
Ｓの中で使用されるビット数の増加としてのいずれか、あるいは、これらファク
タ双方の組合せの結果として）ＩＦ帯域が広くなるにつれて魅力的なものになる
。

【００１１】基地局には通常、複数の並列処理ノードを利用して調整可能な処理を実行でき
るようにプログラムされたスケジュラが具備されている。このスケジュラはＩ２
０ベースの資源自己発見機能を利用し、この関数によって、スケジュラはランタ
イム時にそのスケジューリング活動の動的な修正が可能となる。上記スケジュラ
は、序列的分画用ファイルを読み出して、どのデータ・パスがどの処理ユニット
で実行をすべきかに関するスケジュラの決定に役立てることも可能である。

【００１２】基地局は、ソフトなデータ・パスまたはハードなデータ・パス（あるいはこれ
ら２つのパスの組合せ）のいずれかで実現される基底を成す‘エンジン’への変
更を単に行うことにより、１つの組のベースバンド処理用アルゴリズムから別の
組のアルゴリズムへのオペレーションの変更を行うことができる。但し、ハード
なデータ・パスとはＡＳＩＣまたはＦＰＧＡで実現されるフローであり、ソフト
なデータ・パスとは、従来のプログラム可能なＤＳＰプログラマブルを介して実
現されるフローである。さらに、単一の基地局での複数の規格の同時実行を行う
ことも可能である。

【００１３】本発明の基礎を成す１つの特性として、デジタル無線基地局に適用されるバー
チャル・マシンすなわちハードウェア抽象化層というコンセプトがある。付属説
明1には、ハードウェア抽象化層の意味、目的及び細目、並びに、ＵＭＴＳノー
ド−ｂなどのデジタル無線基地局で見られるような２方向放送スタックへのそれ
の一般的利用がさらに詳細に記載されている。本要約の目的として、ハードウェ
ア抽象化層サポートによって、高度の複雑さを持ちながら低ＭＩＰＳの、標準規
格専用コード（この専用コードは、アーキテクチャ上ニュートラルな方法で書き
込むことができる）を基底を成す高ＭＩＰＳエンジンから切り離すことが可能と
なる。上記エンジンの実施構成は、特定のアーキテクチャと結びついてはいるが
、複数の様々な通信システムに対して応用できるものである。

【００１４】さらに広義には、ハードウェア抽象化層とは、様々なコア処理及び／又はコア
構造及び／又はコア機能及び／又はフロー制御及び／又は状態管理機能を持つよ
うにプログラムされたソフトウェアである。コア処理の中の１つには、ソース符
号化、チャネル符号化、変調の各ステップ、あるいはそれらの逆のステップ、す
なわちソース復号化、チャネル復号化及び復調の各ステップを実行するアルゴリ
ズムが含まれる。

【００１５】バーチャル・マシン・ハードウェア層の実施構成はＣＶＭ（通信用バーチャル
・マシン）と呼ばれる。ＣＶＭとは、デジタル信号処理製品開発用プラットフォ
ームと、当該製品を稼動するためのランタイム（runtime）との双方を指すもの
である。ＣＶＭは、基本的に、バーチャル・マシン層と関連する複雑さの管理手
法をリアルタイム・デジタル信号処理に導入するものであるが、この信号処理は
、（ｉ）（アーキテクチャ独自の方法で実現可能な）高ＭＩＰＳデジタル信号処
理計算をバーチャル・マシン層の一方の側の‘エンジン’の中へ配置すること、
（ｉｉ）アーキテクチャから見て中立な低ＭＩＰＳコード（様々な低ＭＩＰＳ処
理を定義する層１コードなど）をもう一方の側に配置することにより実行される
。さらに具体的には、ＣＶＭは、低ＭＩＰＳ制御プレーンとデータ‘処理とパラ
メータ’フローを除くすべての高度の複雑さを、（ビタビ復号化、ＦＦＴ、相関
などの）多量の資源を必要とする処理を実行する高ＭＩＰＳ‘エンジン’から切
り離すものである。この切り離しによって、‘アーキテクチャから見て中立な’
高い移植性を持つ方法で、複雑な通信用ベースバンド・スタックの構築が可能に
なる。なぜならば、基底を成すハードウェア上ではなく、ＣＶＭ上で実行される
ベースバンド・スタックの設計が可能となるからである。ＣＶＭは、これらのス
タックの高度の複雑さを有する低ＭＩＰＳ制御コードに対して均一なセットのＡ
ＰＩを示し、多くの様々な種類のスタック用として高ＭＩＰＳエンジンの再利用
を可能にする（例えば、ＧＳＭとＵＭＴＳスタック双方のためのビタビ復号用エ
ンジンの利用が可能となるなど）。

【００１６】バーチャル・マシン層は、いくつかの様々なベースバンド処理用アルゴリズム
に共通の基底を成す高ＭＩＰＳアルゴリズムをサポートし、これらのアルゴリズ
ムを、高水準の、アーキテクチャから見て中立なスケジュラ・インターフェース
の中を通る、潜在的に高度の複雑さを有する低ＭＩＰＳ制御フローへのアクセス
を可能にし、このアクセスによって、ランタイム、メモリ、相互接続帯域のうち
の１以上に応じて、１組の資源制約包絡と共に、制御フローによるアルゴリズム
の実行指定を可能にする。この１以上の相互接続帯域の内側で発信者は処理の実
行が行われることを望む。

【００１７】デジタル信号処理製品の開発段階中、（最少の数のプロセッサで実行するな
どの）最適のアクセス・コストを示す構成を特定することを目的として、デジタ
ル信号処理製品の様々な設計上のＭＩＰＳ要件の、ＣＶＭによるシミュレーショ
ンやモデル化の実施が可能である。決定論的関数とは対照的な、少なくとも１つ
の確率論的統計分布関数（及び／又は統計的測定関数）を利用するモデル化を行
うための資源割当て処理が利用される。様々なＤＳＰチップとＦＰＧＡとから成
る実現構成のシミュレーションが可能である。高ＭＩＰＳの速度と並列処理能力
とに起因して、ＦＰＧＡの中に高ＭＩＰＳ演算処理を配置することが非常に望ま
しい。

【００１８】実際の演算処理中、最適の演算処理を維持するために、ＣＶＭ内のスケジュラ
がリアルタイムで知的にタスクの割り当てを行うことが可能となる。本明細書で
はこのアプローチを‘２段階スケジュリング’と呼ぶ。様々なエンジンの資源要
件が、（ｉ）設計時に明示的にモデル化が可能であること、（ｉｉ）ランタイム
中、知的に利用が可能であること、という理由により、いくつかの様々なベンダ
からのエンジンを単一製品の中に混ぜることが可能となる。上述したように、こ
れらのエンジンは、層１と直接の接続を行うのではなく、代わりにＣＶＭバーチ
ャル・マシン層の中継を介して制御コードを層１と接続する。さらに、ＤＳＰと
ＦＰＧＡとの組合せを利用するＰＣＴ非リアルタイム・プロトタイプからランタ
イムプロトタイプへの移行、次いで、カスタムＡＳＩＣ上への効率のよい移動が
ＣＶＭを用いることにより可能となる。

【００１９】ＣＶＭでは以下の３つの主な特長が実現される：＊同時スケジュリングのためのサポートを備えた、ダイナミック、マルチ・
メモリ空間用マルチプロセッサ分散型スケジュラ＊アーキテクチャ固有の実現構成を備えた、デジタル放送及び通信用として
共用される高ＭＩＰＳ演算処理用ＡＰＩ＊（固有のＲＴＯＳを介して供給される）資源管理及び正常化層（normaliz
ation layer）

【００２０】本発明の第２の態様では、第１の態様で定義されたような基地局のベースバン
ド・スタックを形成するベースバンド・スタックが存在する。

【００２１】本発明の第３の態様では、第２の態様のベースバンド・スタックのシミュレー
ションを行うための設計用ツールが存在する。この態様では、上記設計用ツール
は、複数の標準的接続タイプ、及び、パイプラインにより処理されるデータによ
るパイプラインの管理の決定を可能にする同期方法を用いて、ソフトウェアとハ
ードウェア・コンポーネントとを一緒にリンクすることができる。上記設計用ツ
ールは、複数の並列データ・パスに対するロード（バーチャル・マシンの基底を
成す‘エンジン’の分布）の確率的シミュレーションをサポートすることができ
る。但し非対称メモリ・トポロジの範囲内の様々な位置に対するこれらのデータ
・パスの分布の影響（コンポーネントはローカルなものもあれば、争奪が行われ
る（contested）バスの両端にわたってアクセス可能なものなどもある）を、所
定の予め計算された使用シナリオの予想されるローディング・パターンに関して
調査を行うこともできる。このような設計用ツールの出力として、設計用‘エン
ジン’（高ＭＩＰＳコンポーネント）の、様々に分布した‘ハードな’及び‘ソ
フトな’データ・パスへの最初の分割が行われる（但し、ハードのデータ・パス
とはＡＳＩＣまたはＦＰＧＡの中で実現されるフローであり、ソフトなデータ・
パスとは、従来のプログラム可能なＤＳＰプログラマブルを介して実現されるフ
ローである）。この分割は、動的スケジューリング・エンジン（このエンジンに
よって、アーキテクチャから見てニュートラルな高レベルのソフトウェアが、基
底を成すエンジンへ処理要求の実行指令を出す）にとって可視の分割であり、上
記エンジンは上記分割を利用して、ランタイムのスケジューリング決定を最適ま
たは最適に近いものにする処理を行う際の補助を行う。

【００２２】第４の態様には、基地局デバイスの一部またはすべての設計方法がある。この
方法では、ベースバンド信号処理にとって適切なバーチャル・マシン層上にプロ
グラムされたソフトウェアを使用するステップが行われる。

【００２３】第５の態様では、デジタル無線基地局に適したコンピュータ・ソフトウェアが
あり、該ソフトウェアはハードウェア抽象化層として機能し、このソフトウェア
によって１以上のベースバンド処理用アルゴリズムを高水準ソフトウェアを用い
て表すことが可能になる。好適には、上記基地局は、第１の態様で定義されるよ
うな基地局であることが望ましい。

【００２４】本発明の第６の態様には、第５の態様のコンピュータ・ソフトウェアを用いて
プログラムされたコンピュータ・ハードウェアがある。

【００２５】第７の態様では、デジタル無線基地局との接続に適した１以上のＲＦエレメン
トがある。この態様では、基地局は第１の態様で定義されたような基地局である
。

【００２６】本発明のさらなる詳細とその様々な態様は請求項の中に含まれる。

【００２７】

【発明の実施の形態】

以下、添付図面を参照しながら本発明について説明する。汎用ベースバンド・
プロセッサ（“ＧＢＰＴＭ”）を介して実行されるソフトウェア定義無線（“Ｓ
ＤＲ”）基地局から成る、ＲａｄｉｏＳｃａｐｅ有限責任会社（英国、ロンドン
）から得られる実施構成との関連で本発明について説明する。この基地局はＵＭ
ＴＳノード−ｂである。上述したように、ＲａｄｉｏＳｃａｐｅ社のアプローチ
の本質は、一般用プロトコルとハードウェアとを利用して、（従来、非常に高価
な、ベンダによりロックされたアプリケーション専用製品である）基地局を単に
ソフトウェアの変更にすぎない多くの様々な変調規格の実行能力を持つ汎用性の
ある、調整可能なベースバンド・プラットフォームに変えることである。Ｒａｄ
ｉｏＳｃａｐｅ社のシステムでは、ＩＰは、このデバイスをバックネットと接続
するために使用される。またＩＰは、公開されたデータ・フォーマットと制御フ
ォーマットとを用いて、サード・パーティのＲＦモジュールからデジタル化され
たＩＦを送出したり、サード・パーティのＲＦモジュールへ送出したりするため
にも利用される。

【００２８】ＳＤＲベースのＵＭＴＳノード−ｂ基地局とは、ＧＢＰを介して実行される（
Ｃ＋＋、ＤＳＰアセンブラ及びＨａｎｄｅｌ−Ｃ／ＶＨＤＬで書かれた）ソフト
ウェア記述である。ＧＢＰは、ＭＩＰＳと、無線通信用デジタル信号処理タスク
に要求されるスループットとを供給するように設計された強力なハードウェア・
プラットフォームである。ＧＢＰは、ＩＰを利用するネットワーク基盤と接続し
、ＵＤＰを介するＲＴＰ（リアルタイム・プロトコル）を用いて、デジタル化さ
れたＩＦ信号を搬送するＩＰバスを介して単数または複数のＲＦモジュールと交
信を行う。オンボード処理用資源が複数のＦＰＧＡ（フィールド・プログラマブ
ル・ゲート・アレイ）と、高スペックＤＳＰ（デジタル信号プロセッサ）とによ
り供給される。最適化例では、コスト効率を図るために、ＦＰＧＡ上のハードの
データ・パスの若干あるいはすべてのＡＳＩＣへの変換が考慮される場合もある
。ＲａｄｉｏＳｃａｐｅ社のランタイム、ＣＶＭ（すなわち通信用バーチャル・
マシン）は、システムＲＴＯＳ（サード・パーティである）の上位に在るハード
ウェア抽象化層を提供するものである。このＣＶＭによって、プラットフォーム
から見てニュートラルな方法でスタックの高ＭＩＰＳ機能を呼び出すことが可能
となる。ノード−ｂ制御フロー・コード自体はＧＢＰ上のＣＶＭを介して処理を
実行する。

【００２９】データ及びソフトウェア・プロバイダがＵＭＴＳネットワーク‘を引っかける
（hook into）’ことができる手段としての１組の制御用ＡＰＩの利用が可能で
ある。この企ての問題点として、データ（ますますフラットになるバックホール
・コアの両端にわたってＩＰパケット・データ用のより高いバースティな帯域）
のニーズにより３Ｇ開発全体が駆動されていると評価されるにも拘らず、実際に
は、ソフトウェアまたはデータ・ベンダが、基底を成すネットワークにより提供
されるファシリティを利用することが困難であるという点が挙げられる。この目
的のために、ＲａｄｉｏＳｃａｐｅ社のＡＰＩによって、開放型ＣＯＭ（コンポ
ーネント・オブジェクト・モデル）、ＸＭＬ（拡張可能マークアップ言語）及び
ＳＮＭＰ（シンプル・ネットワーク管理プロトコル）ベースのシステムが提供さ
れる。このシステムによって、外部のプログラマは無線ネットの特性と接続し、
この特性を利用することが可能となる。‘ドライバ’の利用を通じて、（例えば
ＣＤＭＡ２０００、ブルートゥースなどの）任意の高帯域ネットワークを介して
このフレームワークの実現が可能であり、さらに、ＵＭＴＳ３Ｇネットワークの
任意のベンダの実施構成用として上記フレームの実現が可能である。上述したよ
うに、ＲＦインターフェース（制御、タイミング同期及びデジタル化されたＩＦ
）が、ＲａｄｉｏＳｃａｐｅ社により、完全にオープンになり、公開されている
。したがって、‘最善のＲＦプロバイダを求めて‘いくつかの店を見て回る（sh
opping around）’ことが、ＧＢＰパラダイムを利用するネットワーク・プロバ
イダにとって現実のものとなる。

【００３０】ＧＢＰパラダイムＰＣの成功については誰もが熟知している。この成功の理由として、適切なセ
ットのハードウェア資源（スクリーン、メモリ、プロセッサ、キーボードなど）
がＰＣにより提供されることが挙げられる。これらの資源は、ハードウェア抽象
化層（ウィンドウズのバーチャル・マシン）の中にまとめて包みこまれ（wrappe
d up）、広範囲のアプリケーションの要求を満たすのに十分な資源であり、高レ
ベルのソフトウェアを用いてこれらのアプリケーションの完全な開発を行うこと
も可能となる。さらに、ソフトウェア内でのアプリケーションのニーズの解決に
とって多くの利点がある。すなわち製造がスピードアップされ、相対的に製造コ
ストが安くなり（これにより多数のプレイヤのマーケットへの参入が可能となり
、競争が生じる）、最終製品の配送コストと在庫コストはほとんどゼロとなる。

【００３１】また、ＰＣは汎用性のある拡張可能なハードウェア設計されたものであり、複
数のハードウェア・ベンダが競争して改良品や周辺機器の組立てを行うことが可
能となり、利用可能性と品質のアップ、及び、エンドユーザのコストダウンが促
進される。本発明の洞察として、デジタル信号処理（ＤＳＰ）の業界に類似のパ
ラダイムの適用が可能であれば魅力的であろうという点が挙げられる。しかし、
遺憾ながら最近までこの業界の友好関係は、ＰＣプラットフォームから切り離さ
れて、石器時代の技術で機能していた。その理由として、この友好関係がビジネ
ス用／家庭用アプリケーションの空間とは全く異なるセットのアルゴリズム要件
を持っているという点が挙げられる。前述したように、高い数値命令ローディン
グと大容量ＤＭＡチャネルを備えた、広い（すなわち高度に並列の）アルゴリズ
ムに対する要望は、しばしばＡＳＩＣを使用するアプリケーション専用ハードウ
ェアの開発へと導かれる傾向がある。これらのデバイスは製造に１年以上を要す
る場合があり、さらに、これらのデバイスに関連する多大の開発費用を必要とす
る場合もある。さらに、存在するこのようなソフトウェア・アーキテクチャはＣ
などの非オブジェクト指向言語と、制限されたバーチャル・マシン（ＲＴＯＳ層
）と、ＶＨＤＬなどの非直感的ハードウェア記述システムとに基づいているため
、切り離せないように一体化されていて、扱い難い傾向があった。

【００３２】上記すべての結果として、無線通信基地局のような複雑なシステムの場合、基
地局ベンダが、ネットワーク・プロバイダに、ハードウェア、ソフトウェア、Ｒ
Ｆコンポーネント（これらすべては最適ではない構成である場合が非常に多い）
の一括購入を強いることが可能であった。基地局の中へ閉じ込められた（または
実質的に閉鎖された）インターフェースのために、やはりそのベンダの基地局コ
ントローラを使用せざるを得ず、それがさらに、品質についての選択肢を狭め、
品質の低下へつながることになった。また、基底を成す通信規格の重要な変更に
より、‘大幅な（forklift）グレードアップ’が非常に頻繁に求められ、オンサ
イトでのハードウェアの改変を余儀なくされてきた。

【００３３】１.１ＣＶＭとＧＢＰの統合以上見てきたように、重要なコンセプトとして、適切なバーチャル・マシンの
中にまとめて包み込まれた、はっきり定義されたハードウェア・アーキテクチャ
によって、スピーディな開発、敏速な修正時間、カプセル化などを行うためのす
べての利点を備え、高レベルのソフトウェアを用いて表されるＵＭＴＳ用のアル
ゴリズムを含むほとんどまたはすべての複雑なベースバンド処理用アルゴリズム
の許容が可能となるという点が挙げられる。

【００３４】ハードウェアという用語は汎用ベースバンド・プロセッサ（すなわちＧＢＰ）
を示す。ハードウェア抽象化層という用語は通信用バーチャル・マシン（すなわ
ちＣＶＭ）を示す。上記２つを統合して、純粋なソフトウェア・コンポーネント
としてプラットフォーム・サポート用変調スタックが形成される。次に、このア
ーキテクチャの実現方法をさらに少し詳細に見ることにしよう。

【００３５】ＧＢＰは従来型のＰＣＩバス用バックプレーンを利用するものである。このバ
ックプレーンははっきり定義された、比較的高帯域規格のものであり、このバッ
クプレーン用として、ＰＬＸ-９０８０のような優れたバス・マスターリングＤ
ＭＡブリッジ・チップが低価格で容易に入手可能である。最初のＧＢＰでは‘従
来型の’３２ビット×３３ＭＨｚＰＣＩバスを使用することになるが、後続バー
ジョンでは、必要に応じて、より高速で、より広いバスを利用することも可能で
ある。

【００３６】業界規格Ｉ２０メッセージング層が、追加の抽象化層としてＰＣＩバスを介し
てサポートされ、利用対象の様々な基底を成す通信用トポロジ（例えばＰＣＩ、
ＲａｃｅＷａｙなど）の利用が可能となる。

【００３７】ＰＣＩアーキテクチャの別の利点として、このアーキテクチャがＰＣによって
サポートされるという点が挙げられる。ＰＣは、ベースバンド処理用の直接のサ
ブストレートとして使用するのに決して好適なものであるとはいえない（ＰＣは
、あまりに待ち時間が長く、コストがかかりすぎ、かつ非並列的で、さらに、不
適当なバーチャル・マシンであるウィンドウズを実行する）が、それにもかかわ
らず、ＰＣによって、プラットフォームの遠隔モニタ用として優れたプラットフ
ォームが提供され、他に並ぶもののない周辺機器サポートを備え、さらに業界を
先導する開発用ツールを備えている。したがって、ＧＢＰの第１のコンポーネン
トは、Ａｄｖａｎｔｅｃｈ社により供給されるようなプラグ・イン型ＰＣカード
であり、別の非常に重要なアプリケーション（Ｅ−１４７デジタル放送用マルチ
プレクサなど）でＲａｄｉｏＳｃａｐｅ社製品により成功裡に利用されているコ
ンポーネントである。上記カードはＮＴを実行するが、ＧＢＰのメインストリー
ム処理に深く関与することはなく、逆に、このカードの機能は、到来用及び送出
用Ｉｕｂメッセージのためのバックネット上へのバス・マスターリング高速イー
サネット（登録商標）用ＩＰインターフェースの配備に加えて、ブート制御、プ
ロセッサ・カード構成、及び、遠隔モニタ用サポートに関与するものである。

【００３８】ＧＢＰのメインストリーム機能は、１以上の一般処理用モジュールにより実行
されるが、このモジュールは、ＲａｄｉｏＳｃａｐｅ社により最初に作成された
標準設計のＰＣＩカードとして供給される。各カードには、高速Ｃ６４×ＴＩ
ＤＳＰと、Ｘｉｌｉｎｘ社製数百万ゲートのＦＰＧＡ、３２ＭＢのＳＤＲＡＭ、
ＰＣＩバス・マスターリング・ブリッジ・チップ（オプションとして、以下解説
するように、このＸｉｌｉｎｘ社製パーツから成るＰＣＩインターフェースを使
用してもよい）が含まれる。ＦＰＧＡは、ブート時に（またはブート後に）ＰＣ
モジュールによりプログラムされる。これが可能となるのは、ＰＣモジュールの
制御ポートが、ブリッジ・チップによってＰＣＩバス上のアドレス可能なメモリ
空間の中へ対応づけられるためである。ＴＩ社製ＤＳＰも同じようにブート時に
プログラムされる。通常動作のパラダイムでは、データは、（ＰＣカード上の高
速イーサネット・プロトコルを介してサポートされる）ＩＰポートから入り、指
定デフォルトの処理用モジュールのメモリの中へＤＭＡ（ダイレクト・メモリ・
アクセス）されてる。上記モジュールでは、（Ｉｕｂメッセージの定義されたＡ
ＳＮ.１マップを使用する）高レベルのＩＰメッセージ構文解析／フォーマット
用コードとスケジュラを実行するタスクが行われる。

【００３９】上記スケジュラは、指定された入力データと、処理要件と、（優先順位などの
）制約と共に、或る特定の処理ボード上の或る特定のデバイス（ＤＳＰまたはＦ
ＰＧＡ）上の或る所定のアルゴリズムの実行要求を当該アルゴリズムの或る特定
のインスタンスへの実行要求に対応づける。このプロセスが図１のダイアグラム
に示されている。ここで留意すべき点として、スケジュラが設計処理中行われた
最初の予め与えられた分割決定を認知しているという点と、但し上記スケジュラ
は単に、当該設計処理中完全なタイミング・モデルに従う必要はなく、データ・
フローに対する重要な‘ランタイム’態様が存在するという点とが挙げられる。

【００４０】いったん、実行の決定が行われると、スケジュラにより、（ＰＣＩバスの両端
にわたって対応づけられたメモリを用いて、Ｉ２０メッセージ通信用インターフ
ェースを最終的に用いて）ターゲットのプロセッサ・カード上のキューの中へ当
該メモリ・ブロックのＩＤ記録が書き込まれる。上述したように、カード上の各
アルゴリズムの各インスタンスはそれ自身のキューを保持し、従来のデータ・パ
ス分割設計フローの一部として生成される物理構成ファイルによりスケジュラは
ＧＢＰの論理構成（そのインストールされているカード及びアルゴリズム）につ
いての通知を受ける。カード上のキューへの更新は完了時にＰＣＩバスに対する
割込みによって信号で知らせることができる。キューメモリへのアクセスはＰＣ
Ｉブリッジ・デバイスにより制御されるミューテックス（mutex）により保護さ
れる。

【００４１】所定のカード上の各アルゴリズムのインスタンスは、１以上のメモリ・ブロッ
クのＩＤ記録（ＭＢＩＲ）が‘キュー’の中に発見されるまでブロックを行う。
このような記録の発見時に、上記インスタンスは（ＭＢＩＲ内で指定される）そ
の現在位置からデータのＤＭＡ（ダイレクト・メモリ・アクセス）を行う。上記
現在位置は、別のカードのバス上でアクセス可能なメモリ・マップ内に位置し、
そのローカルな作業用記憶装置の中へ入れることができる。同一カード上でのア
ルゴリズム間での転送は最適化されて出力され、スケジュラによって、上記最適
化が生じる確率を最大化するための呼出しを行うための次に予想されるアルゴリ
ズムに関するヒントに対する考慮をシステムの現時点での物理構成に応じて行う
ことができる。

【００４２】図２のダイアグラムには、ＧＢＰの高レベルのハードウェア・アーキテクチャ
が示されている（特殊なＩＦ処理用カードを除く）。いったんデータがローカル
・メモリへ転送されると、（カード間ＤＭＡが必要であると仮定して）元のメモ
リブロックが再利用のために解放され、データ処理が開始される。言うまでもな
く、ＦＰＧＡ上での様々なアルゴリズムの処理は並列して正確に行われ、オンカ
ード・メモリへアクセスするために競合を受ける場合もある。ＤＳＰ上でのアル
ゴリズムの処理は、ＴＩ社のＤＳＰのようなマルチタスク用ＲＴＯＳ（リアルタ
イム・オペレーティング・システム）の監視の下で行われる。

【００４３】ここで留意すべきことは、アルゴリズム用のデータ・ブロックにも、このデー
タ・ブロックの初期化用として使用されるパラメータ・ブロックが含まれるとい
う点である。スケジュラによって保持されるセッション状態というコンセプトも
存在する。より高いレベルのコードがＡＰＩにアクセスして、新しいセッション
を開き、セッション用ＩＤを取得し、セッションを閉じることが可能である。次
いで、可能な場合に、同一セッション内で論理演算を実行するという制約を伴う
論理演算スケジュールの作成が可能となる（上記制約は、あちこちとＤＭＡ（ダ
イレクト・メモリ・アクセス）を行う必要があるセッション状態が妨げられるた
め、実質的に、同一物理カード上での論理演算の実行を制約することになる）。
これらのアルゴリズム自体は、実行セッション・アルゴリズムとの付随状態を構
成することも可能であり、同一物理ボード上に後続する呼出しスケジュールの作
成ができない場合、次のボードのメモリ空間へ上記状態のＤＭＡ（ダイレクト・
メモリ・アクセス）が行われる。

【００４４】ＲａｄｉｏＳｃａｐｅ社のＣＶＭ（通信用バーチャル・マシン）は、各プロセ
ッサ上のボードを介する処理を実行するものであり、その範囲内で処理を実行す
るための低レベルの処理を行うための共通環境を設けて、スケジュラ・データ、
セッション状態、共通ＤＭＡチャネルなどへのアクセスを可能にするものである
。多量のリソースを必要とするアルゴリズム自体は、そのほとんどの部分が、Ｃ
ＶＭＡＰＩによりアクセスできる一般信号処理用アルゴリズムの実施構成とし
て組み込まれている。図３に図示のように、ＣＶＭは高水準ソフトウェアからハ
ードウェアを遮蔽するものである。

【００４５】複数のデータ・パスが、利用可能な冗長性サポートと、複数の変調規格に対し
てハードウェア・サブストレートとして機能する能力と、ＩＰネットワークとを
介して遠隔地でコードのローディングを任意に変更する能力（例えば、新しいあ
るいは更新された変調規格を含む新しいコードの更新を遠隔地の基地局で行うこ
とができる）というコンセプトはＧＢＰアーキテクチャに固有のものである。

【００４６】（例えば）プロセッサにわたるアルゴリズムの転送を変更するために、当該デ
バイス用のいずれのエントリも含まない新しい物理マッピング・ファイルをアッ
プロードすることによりターゲット・プロセッサがまず閉じられる。次いで、タ
ーゲット・ボード上のＤＳＰまたはＦＰＧＡのいずれかに割り当てられているす
べての保留中のアルゴリズムがクリアになったとき、ＰＣカードは、（ＤＳＰ用
の新しいマシーン・コード、あるいは、ＦＰＧＡ用のヒューズ・マップのいずれ
に拘らず）データのＤＭＡ（ダイレクト・メモリ・アクセス）を行って、デバイ
スの中へ入力し、次いで、処理用カードの再起動を行う。最終段階で、新しいア
ルゴリズムの可用性を反映する物理マッピングの修正が再度行われる。この修正
によってボードに対する呼出しスケジュールの作成が再び行われる。冗長性を利
用する場合、再プログラミング時間中のＧＢＰに対する唯一の影響として容量全
体への影響が生じることになる（その場合でも、単純なｎ＋１のハードウェアの
冗長性を用いて、単にバックアップ・カードを代りに再構成し、次いで、‘古い
’ロードを持つカードに対して代わりに論理バックアップを施すことにより上記
問題の未然の防止が可能となる。

【００４７】システムの２つのバージョンが予想される。一方のバージョンはＰＣＩカード
自体の‘ホット・スワップ（hot swap）’能力（この能力はＰＣＩバックプレー
ン上の各カードのブリッジに関係する）を持つバージョンであり、もう一方のバ
ージョンは、より長いブリッジされたセクションを持つバージョンであり、前者
よりも低価格の代替バージョンである（但し、ハードウェアの故障が生じた場合
、ＧＢＰの交換を行う前にＧＢＰ全体の電源を落す必要があるため、このバージ
ョンでは柔軟性が犠牲となる）。

【００４８】使用中、ＰＣコードにより、すべてのカードに対して‘鼓動（heartbeat）’
テストが行われ、ＳＮＭＰを用いていずれの故障も報告される。ＰＣカード自体
は、ウォッチ・ドッグ・タイマにより機能中断（hanging）に対する保護が施さ
れる。

【００４９】処理用カード及び（潜在的に）バックプレーンとＰＣカードは、汎用デバイス
であるため、予備部品の保有についてはずっと単純化されている。ＣＶＭは、特
定タスクを利用するためのＧＢＰの寸法設計を行う際、大きな助けとなる予め与
えられた資源予測能力を開発者に対して提供するものである。ＣＶＭの別の利点
として、ＣＶＭがデバイス・プラットフォームを大きく抽象化し、プリミティブ
を相互に接続し、それによって、（例えば）ＦＰＧＡボードが利用可能になった
とき、さらに広いゲートを持つこれらのＦＰＧＡボードへの切替えが可能になる
という点が挙げられる。

【００５０】１.２ＲＦモジュールとのインターフェースＧＢＰの最終ポイントとして、柔軟性のあるソフトウェアにより定義される方
法で、高帯域層−１エア・インターフェース・アルゴリズムの実行がある。した
がって、ＧＢＰ設計の非常に重要な部分として、ＧＢＰ設計方法が高周波（ＲＦ
）エレメントと相互接続を行う方法が挙げられる（この設計方法という言葉によ
ってアップコンバージョンとダウンコンバージョン用エレメント及び電力増幅の
すべてが意味されている）。

【００５１】理想的な世界では、ＲＦデータは単にアンテナから直接デジタル化され、目標
中心周波数で直接合成が行われるにすぎない。残念ながら、現在のＡＤＣ／ＤＡ
Ｃと信号処理用サブストレートではこれを実現するには不十分である。したがっ
て、出力用データを目標中心周波数までアップコンバートし、次いで、送信用と
して該データを増幅するタスクを行う何らかのハードウェアが求められている。
また同様に、該入力データのデジタル化を行うことが可能な適切なＩＦ（中間周
波数）まで入力データをダウンコンバートするタスクを行う何らかのハードウェ
アが求められている。

【００５２】送信時（複数の出力ポイントに固定される同じアナログ・ストリーム・タイム
）の単純なアンテナ・ダイバーシティと、（出力値のグリッドが計算され、複数
のＤＡＣへ送信される）‘スマート’アンテナ・アレイと、（複数のアンテナか
らの入力信号が受信され、チャネル・フェージングの影響を和らげるためにその
後合成が行われる）入力ダイバーシティとを利用したいという要望のためにさら
なる複雑さが付加される。

【００５３】ＲＦインターフェース・アーキテクチャ全体が図４ａに図示されている。ＧＢ
Ｐに関するコアの設計思想として、アナログ技術に必要な設計の熟練技術を持つ
適切な部品会社によりＲＦモジュール（及び後続の増幅段階とアンテナ段階）が
供給されるということが挙げられる。但し、これらの部品会社は複雑なアルゴリ
ズムの実現に要求されるデジタル・ベースバンド・ソフトウェア設計のレベルの
見通しに対して非常に怖じ気づいている。これを解決するために、ＧＢＰとＲＦ
モジュールとの間で開放型インターフェースの指定が行われる。

【００５４】したがって、ＲＦモジュールとＧＢＰとの間のインターフェースは、５つの要
素、すなわち、（簡易）給電と、データ（双方向の高帯域デジタル化ＩＦデータ
の通過）と、2種類の制御（出力用中心周波数の設定、増幅レベルの変更などの
ような目的のためのＧＢＰからＲＦへのメッセージと、ＲＦからＧＢＰへ逆方向
に渡される状態及び警報メッセージ）と、（特定のタイム・コードを基準とする
相対的処理の実行を可能にするための）ＧＢＰからＲＦモジュールへのタイミン
グ／同期信号とを有する。ＧＢＰ内では、このタイム・コードは、ＧＰＳユニッ
トから外部の１ＰＰＳ信号の使用を通じてＩＦカードの中へ出力されるか、もし
くは、長期評価値を上記カードの中へ出力するためのネットワーク・タイム・プ
ロトコルを使用して出力されるかのいずれかの出力が可能である。カード自体に
も、分周され、次いで、ＧＰＳまたはＮＴＰ信号のいずれかに固定される高い精
度のＴＣＸＯが含まれる。図４Ｂはベースバンド処理用カードの概略図である。

【００５５】制御と、状態と、警報メッセージのメッセージ符号化を行うためにＳＮＭＰは
使用しなければならない。このＳＮＭＰは、下記の範囲から選択できる高速ＩＰ
チャネルを介して実現しなければならない：＊高速イーサネット＊ギガビット・イーサネット＊バスＬＶＤＨファイバ・チャネル＊ファイア・ワイアなど

【００５６】ＷＣＤＭＡなどのような広帯域システムにおける無線への出力／無線からの入
力用データ処理の最終段階で要求される処理時の大きなステップアップ、及び、
このようなシステムで求められるデータＤＭＡの高帯域幅に起因して、デフォル
トのＩＦトランスポート・チャネルとしてＰＣＩバスが使用されることはない。
代わりに、一般処理用カードの特別のＩＦバージョンが提供され、このＩＦバー
ジョンが与えられ、このバージョンには高帯域デジタルＩＦベースバンドと、ベ
ースバンドＩＦモジュール（ＦＰＧＡ上で実現されるかさ上げルート余弦フィル
タリングなど）と、上述の計時システムと、高帯域ＩＦＩＰコントローラとが
含まれる。バスＬＶＤＨ（低電圧差分信号）はＵＭＴＳノード−ｂの実施構成の
初期の選択システムになる。このシステムでは基地局処理ユニットとアンテナ間
との距離は比較的短距離（≦１０ｍ）が予想される。

【００５７】上記アーキテクチャにより、ＰＣＩバスに対するロードが最少化され、ＩＰ‘
デジタルフィーダ’の転送が無線塔のＲＦハードウェアまで行われ、従来型のア
ナログ・フィーダで経験される熱膨張／収縮及び損失に起因する問題が取り除か
れる。上記接続でのＩＰ放送の利用により、複数のＲＦユニットが送信ダイバー
シティを目的として、所望の場合、同じ入力を共有することが可能になる。した
がって、その１つのＲＦユニットからの従来型の複数のアナログ・フィードを用
いるか、同じデジタル・フィーダに取り付けられた複数のＲＦユニットを用いる
かのいずれかによって送信ダイバーシティの管理が可能となる。

【００５８】別々のｃｏａｘ（同軸ケーブル）のフィードに沿ってＲＦカードから転送され
る１ＰＰＳ信号を持つパケット用ＵＤＰ／ＩＰを介してＲＴＰを用いて出力の同
期が行われる。ＲＦインターフェースにおいて、上記同期の実行により、ＵＤＰ
／ＩＰパケットからＤＡＣの中へのデータのローディングが制御される。制御情
報がタイム・スタンプされたＳＭＴＰメッセージで送信され、この制御情報はＲ
Ｆモジュール／増幅器により適時に同様に利用される。

【００５９】デジタルＩＦトランスポートの承認された規格を用いる開放型インターフェー
スに起因して、ベースバンド処理用コードに左右されずに特定の周波数／パワー
要件のためのＲＦモジュールの調達が可能となる。このことは、品質の向上とよ
り良い価格設定を行うことができる潜在的可能性をネットワーク・コミッショナ
に与えるものである。

【００６０】１.３エア・インターフェース規格ＲａｄｉｏＳｃａｐｅ社のノード−ｂはＷＣＤＭＡ−２０００対応であり、、
さらに、該ノードによって上記エア・インターフェース用のハードウェアとソフ
トウェアとが供給される。しかし、もし適切なアプリケーション専用コードのロ
ードが利用可能で、かつ、必要なＲＦアダプタ・モジュールが供給されれば、Ｒ
ａｄｉｏＳｃａｐｅ社のハードウェアは、２Ｇ／ＧＳＭ、ＢＲＡＮ、ＴＥＴＲＡ
、ＤＡＢ、ＤＴＴ技術用として再構成が可能である。これはＧＢＰコンセプトの
利点の中の１つであり、共有送電線鉄塔の目標とうまく合致するものである。複
数の無線インターフェース規格用として同じハードウェアを保持することにより
、単純化された予備部品の保有と冗長性管理とがネットワーク・プロバイダにと
って可能となる。

【００６１】ＲＦユニット実施構成の問題点１.４システムの接続上記に説明したように、ＧＢＰＩＦカードからＲＦユニットへの転送は５つ
の要素を持つことになる。＊（簡易）給電＊高速の低ＩＦサンプル・データ（ＤＡＣへ進むか、ＡＤＣから送信される
かのいずれか）。この情報はＵＤＰ／ＩＰを用いて送信される。パケットは、‘
リアルタイム・プロトコル’（ＲＴＰ）に準拠するタイムスタンプを担持する。
バスＬＶＤＨは基底を成す最初のトランスポートとして使用される。＊ＲＦモジュールのパフォーマンスを構成するために利用され、ＲＦモジュ
ールに関する状態を提供するために返送されるＳＮＭＰ管理メッセージ（したが
って、これは２つの要素としてカウントする）。ＲａｄｉｏＳｃａｐｅ社はこの
インターフェース用としてＭＩＢを公開している。ＭＩＢはデータとして同一バ
スＬＶＤＨリンクを介して送信され、配線の複雑さの節減が図られる。ＳＮＭＰ
メッセージには、サンプル・データ・ストリームと同じ時間ベース制御を利用す
るためのＲＴＰタイムスタンプ・フィールドが含まれる。＊クロック同期に使用される１ＰＰＳｃｏａｘ転送。この１ＰＰＳｃｏａｘ
転送は、ＧＰＳユニット（推奨）からの外部１ＰＰＳのパススルーとしてか、主
要な転送用ネットワーク（但しこのネットワークは細粒度ロケーション・サービ
ス用としては十分正確なものではない）からのＮＴＰメッセージに一致するロー
カル・オンボード・クロックの出力としてのいずれでマスタＩＦカードからＧＢ
Ｐ上で生成される。

【００６２】ＲＦモジュールにおいて、小型の低コストプロセッサ（ＡＲＭなど）により制
御メッセージが復号化され、次いで、コア・パラメータ（中心周波数、出力用Ｒ
Ｆパワーなど）への定時更新の管理が行われる。各更新は最終的に１ＰＰＳフィ
ードに設定されたＲＴＰクロックに固定される。

【００６３】この場合ＩＰの使用に起因してある程度の複雑さが追加されることを理解すべ
きである。しかし、このＩＰの使用には、多数のトランスポート（このなかには
非常に汎用的で、費用対効果の良いものもある）を接続用として利用できるとい
う利点がある。ＲａｄｉｏＳｃａｐｅ社は、当初、このＩＰ接続用として少なく
ともギガビット・イーサネットのサポートを意図している。

【００６４】ＲａｄｉｏＳｃａｐｅ社は、図面、ＡＲＭコード及びすべての必要なＩＰドラ
イバ、ＭＩＢとタイミング図、を含むＲＦカード設計パックを、ＧＢＰと相互接
続するＲＦモジュールの組立てを望む、関心を持ついずれのパーティに対しても
ＮＤＡ（機密保持契約）により提供する予定である。

【００６５】留意すべき点として、本明細書での解説ではＲＦヘッドが送受信装置であるこ
とが想定されてはいるものの、この送受信処理が適切である或る特定の規格（Ｄ
ＡＢやＤＶＢ−Ｔのような放送システムなど）用として、送信専用サブストレー
ト、あるいは、受信専用サブストレートとしてＧＢＰの利用も完全に可能である
という点が挙げられる。十分な処理資源とメモリ資源、及び、十分なインターフ
ェース帯域とが与えられていれば、単一のＧＢＰ上で複数の規格を同時に実行で
きるという点にも留意されたい。

【００６６】１.５. ＲＦモジュール本アーキテクチャは、アンテナに非常に近接したＲＦモジュールの配置を可能
とし、これにより長々しいアナログ・フィーダの配置という要件を未然に防止す
ることが意図される。ＩＰを介するデジタルＩＦフィーダの実現に伴う若干の追
加コストと複雑さとが生じるが、一般用（commodity）技術が用いられるためこ
れらのコストは低く抑えられる。

【００６７】ある程度までのＲＦモジュールの電力増幅要件によって、或る特定のＲＦアー
キテクチャのターゲットに対して、送信塔の最上部に完全なヘッド・エンドの配
置が可能か否かの決定が行われることは明らかである。但し、（ＵＭＴＳを含む
）ほとんどのシステムについては、このヘッド・エンドの配置は可能である。も
しＩＦ転送用として使用されるＩＰネットワークが、構成アンテナ・セグメント
の各々についての変調ペイロードを担持するのに十分な帯域を持っていれば、ス
マート・アンテナの利用も本アーキテクチャにより容易になる。 ―附属説明１―：ＣＶＭＣＶＭすなわち通信用バーチャル・マシンは本発明の基礎を成すものである。
この事実は本添付書類はＣＶＭについて、及び、基地局などにおいて見られるよ
うな２方向放送用ベースバンド・スタックへのＣＶＭの適用についてさらに詳細
に記述するものである。技術背景：デジタル信号処理（ＤＳＰ）及びベースバンド・スタックデジタル信号処理とは、アナログ及び／又はデジタル量のデジタル表現を操作
する処理であり、チャネルを介して伝播される有用な情報の伝送または回復を目
的とするものである。高速で、高精度の数値計算の利用により、デジタル信号プ
ロセッサによるデジタル信号処理が実行されるが、一般に、これらのデジタル信
号プロセッサは高速の、リアルタイムのデータ操作用として最適化された集積回
路として形成される。デジタル信号プロセッサは、音声、通信、ビデオなどの多
くのデータ収集、処理及び制御環境で使用される。デジタル信号プロセッサは、
集積回路に加えて別の方法で実現が可能である。例えば、デジタル信号プロセッ
サは、マイクロプロセッサ、及び、プログラムされたコンピュータにより実現が
可能である。本明細書で用いる用語'ＤＳＰ'は、任意のデバイスあるいはシステ
ムもカバーするものであり、デジタル信号処理の実行が可能なソフトウェアまた
はハードウェアあるいはこの２つの組合せのいずれでもよい。したがって用語'
ＤＳＰ'は、１以上のデジタル信号プロセッサ・チップをカバーし、さらに以下
のものをカバーするものである。すなわち：ＦＰＧＡ（フィールド・プログラマ
ブル・ゲート・アレイ）やデジタル信号処理を実行するようにプログラムされた
ＡＳＩＣ、並びに、以上のいずれかの任意のチューリング均等物などのような１
以上の外部コプロセッサを用いて機能する１以上のデジタル信号プロセッサ・チ
ップ通信セクタでは、ＤＳＰでベースバンド・スタックを実行するとき、ＤＳＰは
ベースバンド・スタック用の非常に重要なエレメントとなる。ＤＳＰと共にスタ
ックによりデジタル信号処理が実行される。本明細書で使用する用語'ベースバ
ンド・スタック'とは、１組の処理ステップ（またはこれらのステップを実行す
る構造）を意味し、これらの処理ステップには以下のステップ、すなわち：ソー
ス符号化、チャネル符号化、変調の各ステップ、あるいはそれらの逆、すなわち
ソース復号化、チャネル復号化及び復調の各ステップが含まれる。さらに、用語
'ベースバンド・スタック'は、いかなる形のダウンコンバージョンも持たない、
デジタル信号処理能力を持つ構造と解釈することが望ましい。ソフトウェアによ
る無線装置にはこのようなベースバンド・スタックが含まれることになろう。当
業者であれば理解できるように、ソース符号化は、ビットレートを下げるための
信号（原信号）圧縮に利用される。チャネル符号化によって、復号器能力の改善
を図るための構造化された冗長性が付加され、破損の可能性がある受信信号から
情報が取り出される。変調により、伝播対象情報に応じてアナログ波形の変更が
行われる。ベースバンド・スタックは、移動電話（ＧＳＭスタックやＵＭＴＳスタックな
ど）あるいはデジタル無線受信機（ＤＡＢスタックなど）の中でのみならずその
他の１方向及び２方向デジタル通信用デバイスの中でも使用される。本明細書で
使用する用語'通信'とは、１方向乃至２方向、あるいは、１対１の通信と放送及
び１対多の通信と放送のすべての形をカバーするものである。用語'設計'と'モ
デル化'には、一般に、１以上のエミュレーション処理、資源計算、診断的分析
、ハードウェア・サイジング、デバッギング、パフォーマンス評価が含まれる。通信システムの増大する複雑さに起因して、ベースバンド・スタックの開発に
対して激しい圧力がかけられている。通信システムの複雑さはほぼ毎日のように
増大しつつある。この複雑さに対応するいくつかのドライバが存在する：インタ
ーネット上のトラフィックは毎年１０００％で増加している。（主としてバース
ティな）このデータの多くは、無線キャリアへ移動するが、このようなサービス
を提供する利用可能なスペクトルがだんだん少なくなっている。これらの事実は
、できるだけ多くのデータを圧搾して最小の可能帯域の中へ入れることを目的と
するさらに複雑な信号処理アルゴリズムの利用へとつながる。実際、これらのア
ルゴリズムの複雑さは、ムーアの法則（計算機の能力は１８ヶ月ごとに２倍にな
る）よりも速く増加し続けている。その結果、従来のＤＳＰの能力では不十分に
なりつつある。したがって、複雑な端末用として、非常に大きな並列処理ロード
の処理が可能なＡＳＩＣを形成する必要がある。しかし、実際には問題はここか
ら始まる。なぜなら、使用されるアルゴリズムが信号処理フロントで複雑である
ばかりでなく、主として音声トラフィックから主としてインターネット関連トラ
フィックへの、バースティな、可変ＱｏＳのしばしば短命なトランスポート・チ
ャネルの利用は、（ハードウェアによるリアルタイム・コードが要求される）層
１において、さらに優れた制御プレーン・ソフトウェアを必要とするからである
。従来のＤＳＰツールセットでは、この問題を処理する適切なメカニズムが提供
されていない。その結果、現在の多くの設計は'現実の世界'のデータ・アプリケ
ーションの処理をするための調整を行うことができない。しかし、最新の通信システムの高度のＭＩＰＳ要件は、この話のほんの一部を
表すものであるにすぎない。単一のＳｏＣ（チップ・オン・システム）内で多数
の規格（ＧＳＭ、ＩＳ-１３６、ＵＭＴＳ、ＩＳ-９５など）を利用する必要があ
る場合に別の問題が生じる。複数の規格をサポートするＳｏＣデバイスは、様々
な国々の様々なマーケットを効率的に利用しようと努めているデバイスのベンダ
にとってますます魅力的なものになるであろう。また、次世代ＵＭＴＳ電話は、
ＧＳＭ（すなわち現在の世代）の能力を持つだけでなく、ＤＡＢ（デジタル無線
放送）受信機のような付加された特性も持つようになることが予想される。その
ため、ＵＭＴＳ、ＧＳＭ及びＤＡＢ用のベースバンド・スタックが必要となる。
通信用プロトコルの複雑さのために、現在では、上記問題のすべてに対するソリ
ューションの提供を希望できる企業は１つとして存在しないような状態になって
いる。しかし、（上記リストした３つの異なるベースバンド・スタックのＩＰな
どの）ＩＰを統合化して、だんだん短くなる時間スケールで単一の統合化された
パッケージの中へ一緒に入れるＳｏＣの構築という深刻な問題が複数のベンダの
ＩＰから生じる。複数のベンダのＩＰの相互接続を可能にする商用システムは現
在マーケットには存在しない。層２と層３のソフトウェア（一般的には、ソフト
によるリアルタイム・コード）の方が単純である。なぜなら、ＤＳＰまたは別の
汎用プロセッサの多くのソフトウェアの中の１つの処理としてこのソフトウェア
を単純に実行することができるからである。しかし、（ハードによるリアルタイ
ムの、しばしば並列処理が行われる）層１のＩＰアルゴリズムはさらに困難な問
題を提示する。というのは、必要なハードウェアによる加速処理が、一般的でな
い、ぜい弱な、ソリューション独自のＩＰが設けられた層全体のアーキテクチャ
に対して優位を占めることが多いからである。ベースバンド・スタック開発の現在のモデルにおける欠陥の概観過去において、ベースバンド・スタックは比較的単純で、求められる高ＭＩＰ
Ｓ機能の量は比較的小さく、マルチ規格の、マルチベンダの統合化が行われてき
た。しかし、上述したように、現在では上記の事実はいずれも当てはまらない：
すなわち:（ａ）ハードウェアの使用を必要とする、さらに複雑なアルゴリズム
（ターボ復号化、ＭＵＤ、ＲＡＫＥなど）が採用される帯域圧力手段、（ｂ）さ
らに多くのデータ作成／破壊イベント（birth/death event）と再構成をハード
ウェアによるアルタイムで処理する必要があるので、パケット・データ・トラフ
ィックの増加が層１制御プレーンの複雑さを増大させる。（ｃ）研究開発から製
品化までの期間や、規格の多様化さらに差別化圧力のために、ベンダは、ますま
す複雑な機能（３Ｇ、ブルートゥース、８０２.１１など）を単一デバイスの中
へレコード時間内に統合化する傾向があるが、これは特定のアプリケーション用
ＳｏＣ（システム・オン・チップ）を形成する層１のＩＰの使用許諾を必要とす
る。現在、この問題の適切な解決方法は存在しない。ＶＨＤＬツールセット・プロ
バイダ（CadenceやSynopsisなど）は'ボトムアップ'からこの問題にアプローチ
している。プロバイダのツールは機能の個々の高ＭＩＰＳユニット（ビタビ・ア
クセラレータなど）の製造については有効であるが、層１フレームワークや制御
コードのためのツールや統合化を与えるものではない。ＤＳＰのベンダ（ＴＩ社
、アナログ・デバイシズ（Analog Devices）社など）は、ソフトウェア開発用ツ
ールを確かに供給しているが、これらの会社のリアルタイム・モデルはスタティ
ックで（そのためパケット・データのバースト性にうまく対処していない）、こ
れらの会社のＤＳＰは、ＤＳＰの有用性にブレーキとして働くムーアの法則によ
って制限を受ける。さらに、通信用スタック・ソフトウェアは状態マシンとして
最適にモデル化されるが、この状態マシンにとってＣまたはＣ＋＋（ＤＳＰベン
ダにより通常サポートされている言語である）は適していない代用言語である。ベースバンド・スタック開発の現在のモデルにおける欠陥の詳細な分析従来、デジタル通信のためのベースバンド・スタック開発は細分化され、高度
に専門化されている。例えば、ベースバンド・スタックの中心である信号処理ア
ルゴリズムの初期開発は数学モデリング環境（Ｍａｔｌａｂなど）で一般に行わ
れるが、特定メモリとＭＩＰＳ（毎秒１００万命令）に対する最終ターゲットの
ＤＳＰの予算査定は、従来方式のスプレッドシートを用いる正確な評価により行
われる。いったん、このモデル化処理が良好に実行されると、コード・モジュー
ルと、スタック用のインフラ・ストラクチャ・ソフトウェアとが書き込まれ、可
能な場合には既存ライブラリが適合化される（またおそらくＲＴＯＳ（リアルタ
イム・オペレーティング・システム）が書き込まれる）。次いで、任意の必要な
ハードウェアによる加速処理が、可能な場合にはＰＬＤ（プログラマブル論理素
子）上にプロトタイプ化される'リアルタイム'のプロトタイプ・ハードウェア・
システム（'ＲＡＣＫ'と呼ばれる場合もある）が構築される。これは、ネットワ
ークとの接続なしでテストされ、コードに対する必要な変更が行われる。いった
ん満足のゆくものになると、このスタックは固定化され、（オンチップ周辺機器
としてハードウェアの加速用モジュールが組み込まれる）最終的ＡＳＩＣ（特定
用途向け集積回路）が形成される。この結果つくられたベースバンドＤＳＰまた
はＤＳＰコンポーネントが検査され、次いで、出荷される。この'従来の'アプローチに関していくつかの問題が存在する。これらの問題の
中でより重要なものとして以下のことが挙げられる：＊結果として生じるこれらのスタックにはその構造の中に多くのアーキテク
チャの独自性が含まれる傾向があり、そのため別のハードウェアのプラットフォ
ーム（別のメーカー製のＤＳＰなど）への'移植'処理は時間のかかるものになる
。＊また上記スタックは、修正が困難で、ぜい弱なものとなる傾向もあるため
、インハウス（in-house）での変更の実施（バグの修正や、規格の中へ導入され
た新しい特性の調整など）と、スタックのわずかな変更を望む他の人々へスタッ
クの使用許諾を効果的に与えることとの双方を困難なものにしている。＊ＭＭＩ（マン・マシーン・インターフェース）との統合化が貧弱なものに
なる傾向があり、このことは、一般に、このＭＭＩの機能用の別個のマイクロ・
コントローラをターゲットのデバイス内で使用することを意味する。このためチ
ップ・カウントとチップ・コストとが増加することになる。＊処理がきわめて低速であり、ＤＡＢ（デジタル・オーディオ放送）などの
著しく複雑なシステム用ベースバンド・プロセッサの形成に最低約１年の経過時
間を伴う。＊この処理は、バッファの割り振り、ダウンコンバージョンの管理、デジタ
ル・フィルタの挿入、好適なチャネル・モデルの作成等々を行うための全体的最
善の方法を決定する技術当局者（いわゆる'グル（guru）'）に大きなストレスを
かけるものとなっている。以上の点は一般に不利な点である。というのは、これ
によって、非常に重要なパスとメイン・スタッフへの依存がスタック製造プロジ
ェクトに付加され、製造のタイム・ラインを長引かせることになるからである。
この結果得られる製品は、適切な現在の技術のすべてを必ずしも含むとは限らな
いことが大いに予想される。その理由として、支配的な最善の実施技術のすべて
にわたって完全に熟練している個人がいないこと、また、グルあるいはグルのチ
ームが可能な技術革新のすべてを（たとえ彼らがその技術革新について知ってい
たとしても）スタック製造プロジェクトの中に組み込むだけの時間的余裕が必ず
しもあるわけではないということが挙げられる。＊ＭＩＰＳの手動計算及びメモリ要件への依存、並びに、スタック用のＤＳ
Ｐモジュール及びインフラ・ストラクチャ・コードのカスタムメイド的性質は、
製品の中に欠陥が生じる大きな確率があることを意味する。＊１つの関連する問題点として、一般に、'ＲＡＣＫ'が組み立てられるまで
は、スタックのリアルタイムのプロトタイピングは可能ではないことが挙げられ
る。その時点でも利用可能な高視度デバッガの不足は、最終スタックと資源の'
固定化'が不必要な遅れと、ハードウェア製造のタイム・スケールの超過を意味
する。高視度デバッガは、利用可能であれば、非常に有用なものとなるであろう
。というのは、Ｃ＋＋のような高水準言語で開発されている場合、デバッガは、
コードの中にブレイク・ポイントを入れ、そのポイントにおける処理を停止し、
メモリ内容をチェックし、単一ステップ命令の効果を調べるために単一ステップ
を実行する開発用ツールの能力を与えるからである。またその場合、特定の条件
が生じたとき、実行を停止させ、デバッガを起動させるトリガーをコードの中に
入れることもできる。これらはアプリケーション・ソフトウェアを開発するとき
非常に強力なツールとなる。'ロック・オフ'とは、プロジェクトの１つの段階が
完了したとき、開発が次の段階へ進むことができるという事実を意味する。ハー
ドウェアの開発では、各反復は費用や時間のかかる製造を必要とするので、ソフ
トウェアの場合のように容易に反復を行うことはできない。＊製造中のスタック用の低レベル・モジュールあるいはハードウェアによる
加速処理用'コントローラ'を開発しなければならないため、開発者はターゲット
・プロセッサのアセンブリ言語に熟知している必要があり、また、彼らは当該プ
ロセッサ用として与えられる開発用ツールに依存することになる。＊インフラ・ストラクチャ・コードが再使用されないという事実に伴うモジ
ュール性の不足は、次のデジタル放送スタック用としてほとんど同じ作業を再び
行う必要があることを意味する。スタック開発へのこのタイプのアプローチから生じる、関連するセットとなる
'戦略的'問題が上記の困難な問題と結びつき、このタイプのアプローチでは、ス
タックは必然的に特定のハードウェア環境と強く結びつくものとなる。＊スタック・メーカの視点から見ると、選択されたＤＳＰのハードウェア・
プラットフォームと接近しすぎる近い関係が存在する。錯誤に起因して、コスト
のかかる（また時間のかかる）移植処理が必要となるため、このＤＳＰハードウ
ェア・プラットフォームの注意深い選択を行う必要があるだけでなく、開発用ツ
ール、低水準アセンブリ言語、テスト用'ラック'のハードウェアの開発及び最終
的プラットフォームＡＳＩＣの製造がすべてそのアーキテクチャ独自のものとな
る。別のハードウェア・プラットフォームでスタックを使用する機会が生じた場
合、まずそのスタックを移植しなければならないが、これにはきわめて長い時間
がかかり、多重コード・ベースが導入される（また、これによりプラットフォー
ム独自のバグという大きなリスクが伴うことになる）。コード・ベースとはプロ
ジェクトの基礎を成すソースコードのことである。理想的には、ソフトウェアの
開発の際、ソースコードと機能との間の１対１の対応付けが行われることになる
。そのため、ある特定の機能を必要とする場合、いくつかのプロジェクトはすべ
て同じ実施構成を共有することになる。したがって、この実施構成が改善されれ
ば、すべてのプロジェクトがその利益を享受することになる。しかし、起こりが
ちなこととして、個々のプロジェクトがコードの個々のコピーを持ち、実施構成
が（自然界における遺伝子にいくぶん類似して）時間中分岐するということが挙
げられる。プロジェクトが、従来方式の開発パラダイムの下で異なるハードウェ
アを使用する場合、同じコードの使用が不可能となる場合が時として生じること
がある。さらに、たとえ同じハードウェア・プラットフォームがグレードアップ
された仕様により利用可能になったとしても、コードは依然'ミニ移植'を受け、
それらの付加特性（例えば、より多くのオンボード・メモリや別のＭＡＣ（積和
演算）ユニットなど）を利用できるようにする必要がある。＊ハードウェア・メーカの視点から見ると、ソフトウェア・スタックとの接
近しすぎる近い関係が存在する。ハードウェア・メーカは、（概して）スタック
製造ビジネスの専業になることを望まない。それにもかかわらず、（そのデバイ
スを有用な製品に変える）このようなスタックがなければハードウェア・メーカ
はユニットの販売を行うことはできない。マーケット用として、利用可能な'ソ
フトウェア・ベース'という表現は、ハードウェア・メーカの製品がもっと適切
に競合の対象とすべきその他の特性（利用可能なＭＩＰＳ、電力消費量、利用可
能なハードウェアのＩＰなど）を不明瞭にする可能性がある。＊（シンビアン社のような）オペレーティング・システムのプロバイダは、
そのＯＳをベースバンド通信スタックとインターフェースすることを非常に重要
であると考えている。実際問題として、従来方式のスタックのモノリシックな、
多量の電力を必要とする、リアルタイム要件に起因して、このベースバンド通信
スタックとのインターフェースは達成が非常に困難となる可能性がある。テキサス・インスツルメント社から出ている「ｅＸｐｒｅｓｓＤＳＰ（eXpres
sDSP）リアルタイム・ソフトウェア技術」を参考として考えることができる。こ
の製品セットによって、ＤＳＰ用ソフトウェアの開発時間と統合化時間の削減が
可能になる。しかし、この製品セットは従来方式の設計アプローチの欠点を例示
するものである。なぜならこのセットは、バーチャル・マシン層ではないからで
ある。ＣＶＭのキー・コンセプトＣＶＭとは、デジタル信号処理の設計、モデル化、あるいは実行のためのソフ
トウェアであり、該ソフトウェアは、通信用ＤＳＰ用として最適化されたバーチ
ャル・マシン層を含むものである。 'バーチャル・マシン'とは、一般に、本発明に関連するタイプのアプリケーシ
ョンを実現するための理想的マシンの機能とインターフェースとを定義するもの
である。このマシンは、一般に、進行中のタスク用として最適化された理想的マ
シンを使用アプリケーションに対して提示し、実際のハードウェアの不規則性と
欠陥とを隠すようにするものである。また、通信処理をモデル化したり、通信処
理を表示したりする１以上の状態マシンの管理及び／又は維持を行うことも可能
である。その場合'バーチャル・マシン層'は、現実のマシンをこの理想的マシン
のように見えるようにするソフトウェアである。この層は、一般に、すべての現
実のマシン・タイプについて異なるものとなる。'バーチャル・マシン層'とは、
一般に、ソフトウェアから成る層を意味し、この層は、何らかのタスクまたは１
組のタスク（デジタル信号処理など）を実行する１組の１以上のＡＰＩ（アプリ
ケーション・プログラム・インターフェース）を供給し、使用プログラム間で割
り当てられ、共有する必要のある非常に重要な（メモリやＣＰＵのような資源な
ど）資源を所有している。好適には、資源を割り当て、共有し、切り替えられるように、バーチャル・マ
シン層を最適化して、デジタル信号処理を行うために最善となるようにすること
が望ましい。これと対照的に、典型的オペレーティング・システムは、ワード・
プロセッサのような一般的ユーザ・インターフェースプログラム用として最適化
されている。したがって、例えば、上記ケースの資源切替えアルゴリズムは、一
般に、エンドユーザのオペレーティング・システムの時間増分値よりもはるかに
小さな時間増分値で機能し、並列処理の制御を行うことを可能とするものでもあ
る。通信用ＤＳＰ用として最適化されたバーチャル・マシン層では、処理を実行し
なければならないハードウェアからのソフトウェア・ベースバンド・スタックの
切り離しが図られる。このため、ベースバンド・スタックを非常に移植し易いも
のにすることが可能となる。それは、基底を成すハードウェアの変化からのこれ
らのベースバンド・スタックの切り離しがバーチャル・マシン層により可能とな
ることに起因する。また、上記バーチャル・マシン層では（各々が様々な機能を
実行する）様々な接続モジュール間でのフロー制御の管理を行うことも可能であ
り、この管理を同時ベースで行うことも可能である。さらに上記バーチャル・マ
シン層では、信号処理用の共通データ構造の定義を行うことも可能である。これ
について以下さらに詳述する。ＣＶＭは、（ベースバンド・スタック、または、特に、様々なベンダからのい
くつかのベースバンド・スタックや、移動電話のような最終製品を含むＳｏＣ全
体などの）通信用デバイスをモデル化し、開発し、実際にベースバンド処理の実
行を可能にする開発環境において利用が可能である。 'バーチャル・マシン層'というコンセプトを通信用ＤＳＰの領域に対して適用
する利点は、非アナログ分野からの一例を通じてもっとも良く理解することが可
能となる。ＰＣソフトウェアの分野では、（システムＢＩＯＳの上位に在る）マ
イクロソフトのウィンドウズＴＭオペレーティング・システムは、使用中の実際
のマシンから、及び、そのマシンと接続されたデバイスの細部からソフトウェア
開発者を切り離している。換言すれば、マイクロソフトのウィンドウＴＭオペレ
ーティング・システムは、コードが実行可能な'バーチャル・マシン層'を提供し
ている。このバーチャル・マシン層に起因して、ワード・プロセッサを使っても
のを書いている人が、例えば、彼らのコードを実行するのがデルのマシンかコン
パックのマシンかどうかとかということや、ユーザが、（いずれかのプリンタが
）接続している場合そのプリンタがどのような種類のものであるかなどというこ
とは知る必要はない。さらに、このオペレーティング・システムによって、１組
の共有のコンポーネント（ファイル・ダイアログ・ボックス、メモリ割付けメカ
ニズム及びスレッド管理ＡＰＩのような）機能とサービスとが提供される。'共
通コード'が１回しか書き込まれないため、各アプリケーションが'共通コード'
を何度も再実行しなければならなかった場合に比べて、このような'共通コード'
の厳密性、範囲及び信頼性が大幅に上昇する。さらに、ＰＣハードウェアのメー
カーはソフトウェア開発の複雑さから保護され、適切なウィンドウズのＡＰＩか
ら得られるＢＩＯＳとドライバを提供するだけで、当該プラットフォーム用の膨
大な範囲の既存ソフトウェアの利用が可能となる。各アプリケーションがそれ自
身のカスタムＧＵＩコードを内包していることが多かったプレ・ウィンドウズ状
況と、現在の状況とを対比することができる。ＰＣウィンドウズの'バーチャル・マシン層'アプローチのための主要なイネイ
ブラ（enabler）として、多数のアプリケーションにより、同じ基底を成す'バー
チャル・マシン'の機能が広く求められることが挙げられる。もし、ただ１つの
アプリケーションが、プリンタを使用する必要があったり、ただ１つのアプリケ
ーションがマルチスレッドを必要としたりするのであれば、上記サービスがウィ
ンドウズの'バーチャル・マシン層'の一部であることは効率的であるとは言えな
いであろう。しかし事実はそうではない。なぜなら、（ウィンドウ、アイコン、
マウス、ポインタ、プリンタ、ディスク記憶装置などの）類似のＩ/Ｏ要件と、
類似の'共通コード'要件とを持つ多数のアプリケーションが存在して、それがＰ
Ｃ'バーチャル・マシン層'を'魅力的なソリューションとしているからである。しかし、ＣＶＭに先行して、'バーチャル・マシン'というコンセプトを通信用
ＤＳＰまたは基地局の分野に適用することを考えた者はいままで誰一人としてい
なかった。このコンセプトを適用することによりＣＶＭによって、専用ＤＳＰに
ではなく、バーチャル・マシンにソフトウェアの書込みを行うことが可能となり
、製造上のいずれか１つのソースから生じるＤＳＰのアーキテクチャに起因する
制約から技術者を切り離すことが可能になる。このＤＳＰからの独立という形は
、マイクロソフト社のウィンドウズ・オペレーティング・システムにより提供さ
れる、ＰＣの世界におけるハードウェアの独立性と同様に潜在的に有用なもので
ある。したがって、本発明の様々な実現構成にとっていくつかの主要な利点が存在す
る。＊ＤＳＰのアーキテクチャの両端にわたって、かつ、様々なメディア・アク
セス・ハードウェアへベースバンド・スタックを移植すること（例えば９００Ｍ
Ｈｚで作動するＧＳＭ電話用スタックを１８００ＭＨｚで機能するＧＳＭ電話へ
移植するなど）はずっと高速になる。なぜなら、ＣＶＭによって、アーキテクチ
ャ独自の、あるいは、スペクトル独自のものではないスタック設計が可能になる
からである。研究開発から製品化までの期間のような非常に重要な利点がさらに
一段と重要になる。したがって、スタックは、バーチャル・マシン層が移植され
る相手先の任意のＤＳＰのアーキテクチャで機能することになる。同様に、バー
チャル・マシン層が移植される相手先ＤＳＰは、バーチャル・マシン層用として
書き込まれたすべてのスタックを実行することになる。＊高ＭＩＰＳ複素コード（ビタビ復号器など）の多くは、各ＤＳＰのアーキ
テクチャの場合、何回も書き変えられるのとは対照的に、バーチャル・マシン層
の場合には１回しか書き込まれない。このため、この複素コードの品質と信頼性
の経済的な改善が可能となる。これは、ベースバンド・スタック自身が以前より
少ないコードしか必要としないこと、及び、どのようなスタック・コードであれ
存在するコードが複雑さの少ないものを必要とすることを意味し、これによって
スタック・コードの信頼性が上がる。＊このバーチャル・マシン層によって、完全にソフトウェアの中で、あるい
は、ソフトウェアと、通常使用されているＤＳＰコンポーネントとの混成物を用
いるかのいずれかによってプロトタイプの形成能力が与えられ、それによって、
開発サイクルにおけるアルゴリズムの欠陥と資源要件との早めの特定が可能とな
る。バーチャル・マシン層が、様々なコア処理及び／又はコア構造及び／又はコア
機能及び／又はフロー制御及び／又は状態管理を用いてプログラムされるか、も
しくは、様々なコア処理及び／又はコア構造及び／又はコア機能及び／又はフロ
ー制御及び／又は状態管理へのアクセスを可能にすることが望ましい。バーチャ
ル・マシン層がプログラムされる（あるいはバーチャル・マシン層がアクセスを
行うことを可能にする対象としての）コア処理には'１以上の共通エンジン'が含
まれる。これらの'共通エンジン'は、１以上のベースバンド・スタック機能、す
なわち、ソース符号化、チャネル符号化、変調及びそれらの逆（ソース復号化、
チャネル復号化及び復調）を実行する。これらの'共通エンジン'には、高速フー
リエ変換（ＦＦＴ）、（様々な拘束長、ガロア多項式及びパンクチャリング・ベ
クトルを持つ）ビタビ復号器、リード・ソロモン（Reed Solomon）エンジン、Ｍ
ＰＥＧ復号器用離散余弦変換（ＤＣＴ）、エラー・デコヒーレンス（error deco
herence）のための時間及び周波数ビット毎の再オーダリング、複素ベクトル乗
算及びオイラー合成が含まれる。さらに広範囲のリストが添付書類２の中に含ま
れている。これらのパラメータ化された変換の中の１以上が、通信用ベースバン
ド・スタックにより共通に求められる。上記従属特性は、ほとんどすべての主要
なデジタル放送システムの範囲内に見いだされるという本発明による洞察に基づ
くものである。一例として、ＧＳＭとＤＡＢとの類似性が挙げられる。例えばＧ
ＳＭとＤＡＢの双方においてインターリービングとビタビ復号化が利用される。
したがって共通性とは共通の数学的基礎に基づくものである。さらに、'コア構造'は各ケースの中に存在してもよい。この'コア構造'は、（
当該シンボルの範囲内に保持されているすべての情報が利用可能か否かにかかわ
らず、フル・シンボルの処理に関係する）シンボル処理部と、関連情報を保持す
る当該ビットのみの処理が行われるデータ指示型処理部とを復号化チェーンに分
割する処理部に関与する。各ケースで、これらの処理用モジュールが、中間の、
整合メモリ・バッファの割り当て、共有、配置を行い、処理用モジュール間でイ
ベントを渡し、モジュラ型開発を可能にする枠組みの範囲内に存在できるように
することが非常に望ましい。上記コア機能は、以下の処理のうちの１以上を含む資源割当てとスケジュリン
グ（メモリ割付け、リアルタイムの資源割当て及び同時性管理）に関するもので
あってもよい。好適には、このソフトウェアは、パフォーマンスと能力の点でＤ
ＳＰ設計用ツールよりもずっと優れた、ＰＣのデバグ用ツールにアクセスが可能
であることが望ましい。このソフトウェアは、適合性スクリプト（conformance
scripting）に従うものであってもよい。このスクリプトについては以下に定義
する。さらに、このソフトウェアは、コンポーネントを用いて機能するものであ
ってもよい。このコンポーネントの中で上記ソフトウェアの機能及び／又は別様
にコンポーネントのパフォーマンスのモデル化を可能にするために必要な当該情
報だけが上記コンポーネントの知的財産の所有者により供給される。このことに
よって、（内部の詳細事項、設計、操作のような貴重な企業秘密情報である可能
性がある）知的財産の所有者がその情報を隠し、サポートされている機能、ＡＰ
Ｉに必要なパラメータ、タイミングと資源のインタラクション、特性評価のため
の予想パフォーマンスなどのようなずっと重要性の小さい情報だけを公開するこ
とが可能になる。本明細書では、本発明に従うソフトウェアの実施例を通信用マシン層（ＣＶＭ
）と呼ぶ。ＣＶＭは、上記に導入した着想を一緒に引き出すので、以下のセクシ
ョンにおいて要約する。ＣＶＭの実現構成についての要約ＣＶＭとは、デジタル信号処理製品開発用プラットフォームと、当該製品を実
行するためのランタイム（runtime）との双方を指すものである。ＣＶＭは、基
本的に、バーチャル・マシン層と関連する複雑さの管理手法をリアルタイム・デ
ジタル信号処理へもたらすものであるが、この信号処理は、（ｉ）（アーキテク
チャ独自の方法で実現可能な）高ＭＩＰＳデジタル信号処理計算をバーチャル・
マシン層の一方の側の'エンジン'の中へ配置すること、（ii）アーキテクチャか
ら見て中立な低ＭＩＰＳコード（様々な低ＭＩＰＳプロセスを定義する層１コー
ドなど）をもう一方の側に配置することにより実行される。さらに具体的には、
ＣＶＭは、低ＭＩＰＳ制御プレーンとデータ'操作及びパラメータ'フローを除く
すべての高度の複雑さを、（ビタビ復号化、ＦＦＴ、相関などの）多量の資源を
必要とする処理を実行する高ＭＩＰＳ'エンジン'から切り離すものである。この
切り離しによって、'アーキテクチャから見て中立な'高い移植性を持つ方法で、
複雑な通信用ベースバンド・スタックの構築が可能になる。なぜなら、基底を成
すハードウェア上ではなく、ＣＶＭ上で実行するベースバンド・スタックの設計
が可能となるからである。ＣＶＭは、これらのスタックの高度の複雑さ、低ＭＩ
ＰＳ制御コードに対して均一なセットのＡＰＩを示し、多くの様々な種類のスタ
ック用として高ＭＩＰＳエンジンの再使用を可能にするものである（例えば、Ｇ
ＳＭとＵＭＴＳスタック双方のためのビタビ復号用エンジンの利用が可能となる
など）。デジタル信号処理製品の開発段階中、（最少の数のプロセッサで実行するなど
の）最適のアクセス・コストを示す構成を特定することを目的として、デジタル
信号処理製品の様々な設計上のＭＩＰＳ要件の、ＣＶＭによるシミュレーション
やモデル化の実施が可能である。確定論的関数とは対照的な、少なくとも１つの
確率的統計分布関数を利用する資源割当て処理が利用される。様々なＤＳＰチッ
プとＦＰＧＡとから成る実現構成のシミュレーションが可能である。高ＭＩＰＳ
の速度と並列処理能力とに起因して、ＦＰＧＡの中に高ＭＩＰＳ演算処理を配置
することが非常に望ましい。実際の処理中、最適の処理を維持するために、ＣＶＭ内のスケジュラがリアル
タイムで知的にタスクの割り当てを行うことが可能である。本明細書ではこのア
プローチを'２段階スケジュリング'と呼ぶ。様々なエンジンの資源要件が、（ｉ
）設計時に明示的にモデル化が可能であること、（ｉｉ）ランタイム中、知的に
利用が可能であること、という理由により、いくつかの様々なベンダからのエン
ジンを単一製品の中に混ぜることが可能となる。上述したように、これらのエン
ジンは、層１と直接の接続を行うのではなく、代わりにＣＶＭバーチャル・マシ
ン層の中継を介して制御コードを層１と接続する。さらに、ＤＳＰとＦＰＧＡと
の組合せを利用する非リアルタイム・プロトタイプから実行時プロトタイプへの
移行、次いで、カスタムＡＳＩＣ上への効率のよい移行がＣＶＭを用いることに
より可能となる。ＣＶＭでは以下の３つの主な特長が実現される：＊同時スケジュリングのためのサポートを備えた、ダイナミック、マルチ・
メモリ空間用マルチプロセッサ分散型スケジュラ＊アーキテクチャ固有の実現構成を備えた、デジタル放送及び通信用として
共用される高ＭＩＰＳ演算処理用ＡＰＩ＊資源管理及び正常化層（normalization layer）（固有のＲＴＯＳを介し
て供給される）ＣＶＭは'パイプライン'という形で存在することが可能である。'パイプライ
ン'とは、ある構造または１組の相互作動するハードウェア・デバイスまたはソ
フトウェア・デバイス、及び、１つのデバイスまたは処理から別のデバイスまた
は処理へ情報を渡すルーチンである。ＤＳＰ環境では、このような複数の情報は
'シンボル'と呼ばれることが多い。パイプラインは、データ・フローアーキテク
チャとして、並びに、従来の手続き用コードとして実現が可能であり、このよう
な変形例のすべては本発明の範囲内に属するものである。また、ＣＶＭは、状態
マシンとして、または、手続き用コードとして概念化し、実現することも可能で
あり、再言するが、このような変形例のすべては本発明の範囲内に属するもので
ある。ＣＶＭの１つの例には、解釈されたパイプライン・マネージャが含まれ、この
パイプライン・マネージャにはＣＶＭコアの実行時バージョンが組み込まれる。
'解釈された'という用語が意味するものとして、そのパイプラインの仕様が基底
を成すマシンコードにまだ翻訳されていず、ベーシック言語のような解釈された
言語の場合と全く同じように、プログラムの実行につれて繰り返し再翻訳が行わ
れることが挙げられる。別の例として、ＣＶＭコアの実行時バージョンが組み込まれた、計装化された
解釈パイプライン・マネージャ（Instrumented Interpreted Pipeline Manager
）がある。この計装された解釈パイプライン・マネージャは、解釈されたパイプ
ライン・マネージャと同じように機能するが、開発者に役立つメトリックと計測
値も生成する。解釈された非計装化（non-instrumented）バージョンもまた開発
とデバッギング用として有用であり、コンパイルされ、計装化された（instrume
nted）バージョンもまた有用である。後者のバージョンは開発とデバッギング用
の最適ツールとなる場合もある。ＣＶＭの別のバージョンはパイプライン・ビルダ（Pipeline Builder）である
。実行の代わりに、パイプライン・ビルダは、Ｃのようなコンピュータ・ソース
コードを出力し、このソースコードをコンパイルして、パイプラインの実現構成
を形成することができる。この理由のため、パイプライン・ビルダはＣＶＭライ
ブラリを利用できなければならない。パイプライン・ビルダは、コンパイルされ
た非計装の変形例と考えることもできる。ＣＶＭ装置は、通信用コンポーネントの特性（非インターフェースの振舞いを
含む）の標準化された記述を含むか、この記述に関するものであるようにして、
シミュレータがコンポーネントを利用する上でのシステムの資源要件の正確な推
定ができるようにする。ＣＶＭ装置で時間及び同時性制限のモデル化を行って、
リアルタイムＯＳ上への対応付けを可能にし、並列処理を実行できる可能性を持
たせるようにすることも可能である。本発明の別の特性と態様は本明細書の請求項において定義される。添付図面を
参照しながら本発明について以下説明する。ＣＶＭついての詳細な説明ＣＶＭの概観ＣＶＭとは、デジタル信号処理製品開発用プラットフォームと、当該製品を実
行するためのランタイム（runtime）との双方を指すものである。ＣＶＭは、基
本的に、バーチャル・マシン層と関連する複雑さの管理手法をリアルタイム・デ
ジタル信号処理へもたらすものであるが、この信号処理は、（ｉ）（アーキテク
チャ独自の方法で実現可能な）高ＭＩＰＳデジタル信号処理計算をバーチャル・
マシン層の一方の側の'エンジン'の中へ配置すること、（ii）アーキテクチャか
ら見て中立な低ＭＩＰＳコード（様々な低ＭＩＰＳプロセスを定義する層１コー
ドなど）をもう一方の側に配置することにより実行される。さらに具体的には、
ＣＶＭは、低ＭＩＰＳ制御プレーンとデータ'操作及びパラメータ'フローを除く
すべての高度の複雑さを、（ビタビ復号化、ＦＦＴ、相関などの）多量の資源を
必要とする処理を実行する高ＭＩＰＳ'エンジン'から切り離すものである。この
切り離しによって、'アーキテクチャから見て中立な'高い移植性を持つ方法で、
複雑な通信用ベースバンド・スタックの構築が可能になる。なぜなら、基底を成
すハードウェア上ではなく、ＣＶＭ上で実行するベースバンド・スタックの設計
が可能となるからである。ＣＶＭは、これらのスタックの高度の複雑さ、低ＭＩ
ＰＳ制御コードに対して均一なセットのＡＰＩを示し、多くの様々な種類のスタ
ック用として高ＭＩＰＳエンジンの再使用を可能にするものである（例えば、Ｇ
ＳＭとＵＭＴＳスタック双方のためのビタビ復号用エンジンの利用が可能となる
など）。バーチャル・マシン層は、いくつかの様々なベースバンド処理用アルゴリズム
に共通の基底を成す高ＭＩＰＳアルゴリズムをサポートし、これらのアルゴリズ
ムを、高水準の、アーキテクチャから見て中立な、スケジュラ・インターフェー
スの中を通る、潜在的に高度の複雑さをもつ低ＭＩＰＳ制御フローにアクセス可
能にし、このアクセスによって、ランタイム、メモリ、相互接続帯域のうちの１
以上に応じて、１組の資源制約包絡と共に、制御フローによるアルゴリズムの実
行指定が可能になる。上記資源制約包絡の内側で発信者は処理の実行が行われる
ことを望む。デジタル信号処理製品の開発段階中、（最少の数のプロセッサで実行するなど
の）最適のアクセス・コストを示す構成を特定することを目的として、デジタル
信号処理製品の様々な設計上のＭＩＰＳ要件の、ＣＶＭによるシミュレーション
やモデル化の実施が可能である。確定論的関数とは対照的な、少なくとも１つの
確率的統計分布関数（及び／又は統計的測定関数）を利用するモデル化を行うた
めの資源割当て処理が利用される。様々なＤＳＰチップとＦＰＧＡとから成る実
現構成のシミュレーションが可能である。高ＭＩＰＳの速度と並列処理能力とに
起因して、ＦＰＧＡの中に高ＭＩＰＳ演算処理を配置することが非常に望ましい
。実際の演算処理中、最適の演算処理を維持するために、ＣＶＭ内のスケジュラ
がリアルタイムで知的にタスクの割り当てを行うことが可能となる。本明細書で
はこのアプローチを'２段階スケジュリング'と呼ぶ。様々なエンジンの資源要件
が、（ｉ）設計時に明示的にモデル化が可能であること、（ｉｉ）ランタイム中
、知的に利用が可能であること、という理由により、いくつかの様々なベンダか
らのエンジンを単一製品の中に混ぜることが可能となる。上述したように、これ
らのエンジンは、層１と直接の接続を行うのではなく、代わりにＣＶＭバーチャ
ル・マシン層の中継を介して制御コードを層１と接続する。さらに、ＤＳＰとＦ
ＰＧＡとの組合せを利用するＰＣＴ非リアルタイム・プロトタイプから実行時プ
ロトタイプへの移行、次いで、カスタムＡＳＩＣ上への効率のよい移動がＣＶＭ
を用いることにより可能となる。ＣＶＭでは以下の３つの主な特長が実現される：＊同時スケジュリングのためのサポートを備えた、ダイナミック、マルチ・
メモリ空間用マルチプロセッサ分散型スケジュラ＊アーキテクチャ固有の実現構成を備えた、デジタル放送及び通信用として
共用される高ＭＩＰＳ演算処理用ＡＰＩ＊資源管理及び正常化層（normalization layer）（固有のＲＴＯＳを介し
て供給される）ＣＶＭとは設計フロー・ソリューション並びにランタイムである。ＣＶＭは、ランタイムを補う完全な設計フローを提供するものである。このＣ
ＶＭによって、完全に統合化された数学モデルと、（バースティなデータに関す
る演算処理に必須の）統計的シミュレーション・ツールと、（データ・パスがハ
ードウェアの中へ入るべきか、ＤＳＰコア上のソフトウェアの中で実行すべきか
を決定するための）演繹的分割シミュレーション・ツールが技術者に与えられる
。数学モデリング用ツール（Ｍａｔｌａｂ／Ｓｉｍｕｌｉｎｋなど）のカスタム
・ライブラリの利用によって、ＣＶＭは、様々なデータ・パスがどれだけの数の
ビット幅を持つ必要があるかなどを前もって決定するために、詳細に、かつ、ビ
ットレベルの（bit-exact）精度で、高ＭＩＰＳエンジンの機能のモデル化を行
うことができる。しかし、また、このシステムでは、データ作成／破壊イベント
（birth/death event）とをモデルのコンテキストの内で処理することを可能に
する統計的シミュレーションが行われる制御プレーンからＸＭＬコマンドを受け
入れることもできる。さらに、スケジュラの間接インターフェースを介してシミ
ュレーション・エンジンにまでもアクセスが行われるので、実際のハードウェア
などの実現構成に対してプラグ・インコールを行って、シミュレーションの実行
速度を上げることが可能となる。また、重要なことは、様々なシステム分割の決定により資源ローディングのシ
ミュレーションの実行が可能なことである。様々な統計的ロードの下で十分なカ
バーを行うためには、特定のアルゴリズム'エンジン'（ビタビ復号器、レイク受
信デバイス・エレメント、ブロックＦＦＴの演算処理など）のインスタンスがい
くつ必要なのか？データ・パスがバスのような遅延を生じる及び／又は同時争奪
を生じる資源にわたって移動する場合、何が起こるのか？データ・パスがソフト
ウェアではなくハードウェアの中で実現される場合何が起こるのか？これらの問
題の解決のすべては非常に重要であるが、既存のツールセットではこれらの解決
はまだ行われていない。さらに、複数のサード・パーティのＩＰエンジンまたは
エンジン（下記を参照）に関して、分割問題の解決を行うとき、これは２重の意
味で真である。ＣＶＭ設計フローによって、これらの種類の設計上の問題解決に
対する回答を与えることが可能となることは明らかである。さらに、初期の分割
情報は、設計用ツールセットから'順方向に'転送されてランタイムスケジュラの
中へ入り、これによって、システムが実際の動的ロードを行っているとき、この
ランタイムスケジュラが、実現のための好適なエンジン・インスタンスへ要求の
配分を行うことが可能となる。 'ボトムアップ'から見ると、このソフトウェアを実質的に２次的重要性をもつ
ものとして扱うことは、もはや販売のための製品開発を行う方法ではない。この
ようなやり方では単に長い時間がかかりすぎるだけで、あまりにもアーキテクチ
ャ独自の結果が生じ、基底を成す領域の並列状態マシンの性質にとって不都合な
'マッチング'が生じることになる。'トップ・ダウン'から見ると、ＣＶＭが利用
するパラダイムにより、はるかにずっと強力で拡張可能なソリューションが得ら
れる。ＣＶＭに関する最終ポイントとして、基底を成すエンジンから制御フロー・コ
ードを切り離すことにより、実際の組み込まれたターゲットと矛盾することなく
、従来の（ＰＣなどの）プラットフォーム上で多くの開発作業の実行が可能にな
ることが挙げられる。これによって、特定のベンダの最終ターゲットの開発用プ
ラットフォームを利用する場合に比べて設計上ずっと早い方向転換が可能になる
。例：ＣＶＭとは、３Ｇシステム用ＳｏＣのような、ハードウェアによるリアル
タイムの、マルチベンダの、マルチプロトコル環境に対する設計上のソリューシ
ョンである。ＣＶＭのコア・エレメントの中の１つとして、ハードウェアによるリアルタイ
ムの、マルチベンダの、マルチプロトコル環境における（潜在的に衝突する）サ
ード・パーティのソフトウェア／ハードウェアの資源要件を処理する能力がある
。この能力はＣＶＭの主要な利点であり、システム・オン・チップ（ＳｏＣ）の
設計の際、特別な重要性を持つものである。これを理解するために、３Ｇ携帯電
話マーケット向けのベースバンド・チップの将来のプロバイダが直面する問題点
について考えることにする。第１に、層１の必要となる処理の複雑さに起因して
、在庫のＤＳＰ用として単純にコードを書き込むことはオプションではない。Ａ
ＳＩＣでは、複雑な拡張やターボ復号化などの処理を行うことが求められる。第
２に、ＵＭＴＳは少数の地下鉄の場所に当初導入されるにすぎないため、チップ
にはＧＳＭのサポートも可能である必要がある。ベースバンド・チップメーカが
これら双方の分野で広範囲の技術を持っていることはありそうもなく、したがっ
て、ＩＰの使用許諾を受ける必要が生じる。この点は、絶えず長引くことになる
、研究開発から製品化までの期間という圧力を考慮すると技術会社にとって特に
関係の深い事柄である。しかし、一部はハードウェア、一部はソフトウェアから
成るＩＰエンジンの使用許諾を層１の複数のベンダから得ることは１つの現実的
な問題を現出することになる。第１に、上記方法での'互換性対非互換性'（mix
and match）ＩＰについての共通の単純な基準は現在存在していない。必要とさ
れること、及び、ＣＶＭ設計フローが提示することとして、静的及び動的双方の
サード・パーティのＩＰブロックの資源要件を特徴づける１つの方法がある。こ
の方法によって、潜在的に、全く異なるサプライヤからの別のＩＰエンジンを用
いてリアルタイムで当該サード・パーティのＩＰブロックを同時スケジュール化
し、次いで、より高いレベルの層１制御コードとの透過的な接続が可能となる。
さらに、ＣＶＭの性質として、（ＡＮＳＩＣへコンパイルされたＳＤＬなどの）
アーキテクチャから見て中立な言語でこれら高レベルの呼構造及び制御プレーン
全体の形成が可能であるということが挙げられる。その場合、低いレベルで、高
ＭＩＰＳ部分だけがアーキテクチャ独自の形式で直接実現されることになる。上述したように、エンジン内に内包される高ＭＩＰＳ機能は、完全な処理ルー
チンを表すものである。これらのエンジンは、ハードウェアまたはソフトウェア
、あるいは両者の何らかの組合せで実現可能であるが、このことは高水準の'呼
出し'コードという観点から見ると重要な問題ではない。高レベルのＩＰは、Ｃ
ＶＭスケジュラ呼出しを介して基底を成すエンジンと交信を行い、この呼出しに
より、ハードによるリアルタイムの動的資源制約の指定が可能になる。次いで、
スケジュラは、適切なデータ・パスへこの要求の実行指令を出す。この実行指令
にはＤＳＰの関数呼出しや、ＦＰＧＡまたはＡＳＩＣへのデータの受渡しが含ま
れる場合もある。重要なことは、このスケジュラが複数のハードウェアのデータ
・パスを処理することができるという点である。これらのデータ・パスは様々な
アクセス用プロファイルと実行用プロファイル（例えばオンバス・ビタビ復号器
、オンチップ・ソフトウェアベースの復号器、及び、外部ＤＭＡを介してアクセ
スされるオフチップ専用ＡＳＩＣなど）を持つことが可能であり、さらに、呼出
し用の高レベルのコードから完全に独立した適切なユニットへ特定の要求を渡す
ことが可能である。また、このことは、２つの異なる通信スタックがいくつかの共通の高ＭＩＰＳ
エンジンを必要とする場合、適切な（プラットフォーム独自の）エンジンの実現
構成（この実現構成がハードウェア、ソフトウェアまたはその双方の何らかの組
合せのいずれで設計されているかにかかわらず）のベンダが、上記２つの異なる
通信スタックのマーケットへ販売を行うことができることを意味し、さらに、単
一ＳｏＣ上に２つの規格が実装されている場合、双方のスタックが同じアクセラ
レータを潜在的に共有できることを意味する。加えて、１組の１００以上のコア
・オペレーションが指定され、これらのコア・オペレーションを考慮に入れると
、デジタル放送用プロトコル及び通信用プロトコルの膨大な部分の中で得られる
高ＭＩＰＳ機能の８０％近くがこのＣＶＭにより提供されることになる。また、
ＣＶＭランタイムは基底を成すＲＴＯＳの周りにラッパを与え、（スレッド、メ
モリ、外部アクセスを含む）資源管理のための規格に準拠したインターフェース
を高レベルのコードに示すものである。ＣＶＭを用いることにより、通信ＳｏＣ製品用の統合化された開発用プラット
フォームの構築が可能となる。その場合、いくつかのサード・パーティのベンダ
は、高レベルのアーキテクチャから見て中立なＳＤＬあるいはＣ＋＋コンポーネ
ントもしくはアーキテクチャ独自の、資源プロファイル化されたエンジン（ハー
ドウェア、ソフトウェア、またはその双方の組合せであってもよい）のいずれか
として、彼らのＩＰを公開することができる。統合化された設計フローによって
、ＳｏＣの設計者は、（特定のベンダから選択された）適切なエンジンを含むシ
ステム全体を形成し、ＣＶＭの両側またはいずれかの側に自分のＩＰを付加し、
次いで、（アクセラレータと共にいくつかのＶＨＤＬで定義されたコアとして）
利用可能なハードウェア仕様とソフトウェア・コンポーネントの双方を作成する
ことが可能になる。数学モデリングと、分割、プロトコル検証及び最終的システ
ム形成のための統計的、演繹的、確率的シミュレーションとによって完全なフロ
ーを提供するツールセットの組立てと、好適なメカニズムの提供と、設計の範囲
内の'パッケージ化された'ＩＰライブラリの特徴づけ、公開、列挙及び利用が可
能となる。このシステムは、ＳｏＣの設計者用の主要ワークベンチになる潜在的可能性を
有する。ＳｏＣの設計者は、高ＭＩＰＳエンジンの開発を行うために、層１制御
構造（fabric）の中のいずれにも入らず、ＶＨＤＬツールの中へ入るだけでよく
なるからである。ＣＶＭにより設計層１内でのＳＤＬの利用が可能となる。上述したように、ＡＮＳＩＣ＋＋または好適にはＳＤＬ（このＳＤＬはその
後ＡＮＳＩＣへコンパイルしてもよい）のいずれかを用いて、アーキテクチャ
から見て中立な方法で低ＭＩＰＳコードを書き込むことがＣＶＭにより可能とな
る。ＳＤＬとは、層２及び層３スタックを表現するために電気通信業界内で広く
使用されている言語であり、状態マシン・フォーマットで最も経済的に表現され
るシステムにとって特に好適な言語である。従来の方式で使用するには、ＳＤＬ
は層２（'ソフトによるリアルタイム'領域の端）より下位で使用するのに適切な
ものではない。ＳＤＬコードは様々なアーキテクチャ間での完全な移植が可能で
あり、ＴＴＣＮなどのようなツールを用いて通常の方法でテストを行うことも可
能である。開発時のコードとサブストレートの相互接続とから成る様々な部分に
（動的資源の天井などのような）システム上の制約を設けることが可能であり、
次いで現実の負荷モデルを用いてシミュレーションを行って、ハードウェアとソ
フトウェアへのデータ・パスの予行分割を行うことが可能となる。重要なことは
、ＣＶＭスケジュールが、開発プロセスの１回の設計時間部分中に行われたデー
タ・パス分割決定を認識しているということである。ツールフローは、Ｍａｔｌ
ａｂ及びＳｉｍｕｌｉｎｋと完全に統合化され、高ＭＩＰＳ機能のビットレベル
でのテストが可能となる。層１の範囲内での高レベルの論理フロー用推奨言語と
してＳＤＬの使用は偶発的なものではない。ＳＤＬは、ＧＳＭのような通信スタ
ック層２と３内で広く使用されてきたが、この２つの層の深い溝（chasm）の間
をかけ渡してハードウェアによるリアルタイム領域の中へ入ってきたことは従来
なかったことである。これと対照的に、ＣＶＭでは、ＳＤＬ制御フローからの並
列の、ハードウェアによるリアルタイムの実行指令の呼出しが可能となり、それ
によってＳＤＬの非常に強力で、かつ、自然な、状態マシンの表現性を利用して
、高水準の層１アルゴリズムの作成が可能になる。これらのアルゴリズムは、低
ＭＩＰＳを有しているにもかかわらず、ほんの２、３名前を挙げるだけでも、バ
ースティなレート・マッチング、ユーザ・トランスポート・チャネルのデータ作
成／破壊イベント（birth/death event）、複数の規格間のハンドオーバ、負荷
によるＱｏＳと結びついたグレースフル・デグラデーションのような問題を処理
しなければならないので、ますます極度に複雑になっている。リアルタイムの処
理用としては設計されていない他の言語（Ｃ＋＋やＪａｖａなど）もＳＤＬの代
替言語として設計層１での使用が可能である。ＣＶＭに対する理論的背景現在のデジタル通信システムは、チャネルに起因するきわめて厳しい影響に直
面する中で信頼性の高い、情報の無線による最善の伝送方法についての、最近の
１５年かそこらで出現した実質的に共通の同意に基づいて構築されている。２方
向システムは、（例えば、輻輳状態のスペクトル帯域に直面してグレースフル・
デグラデーションを生じるＣＤＭＡを利用し、いくつかの'ハードウェアによる'
リアルタイム要件を含むような）放送型システムとは多少異なるチャネル要件と
変調要件とを持っているが、全体として多くの共通性が存在する。例えば、（１方向の）放送システムの特定のケースでは、復号器と符号器は単
に並列の'プロトコル・スタック'と考えることができよう。ほとんどの放送送信
システムは、（ビットレートを落とすために入力信号を圧縮するＭＰＥＧのよう
な）ソース符号化から始まり、その後（信号破損にもかかわらず情報を取り出す
受信機の能力の向上のための構造化された冗長性を付加する畳み込み符号化とリ
ード・ソロモン（Reed-Solomon）符号化のような）チャネル符号化が後続し、そ
の後、（この時点で、複数の副搬送波が（周波数または位相の）角度や振幅の何
らかの組合せで修正され、情報が保持される）変調が後続する。次いで、図５の
線図を（１つのレベルで）生み出す逆の処理が受信機で実行される。したがって
、ほとんどすべての主要なデジタル放送システムの中で１組の共通の処理用エン
ジンが見いだされ、各ケースで共通の処理構造の適用が可能となる。ＣＶＭの実施例は、上記の事実を以下のように利用するものである。すなわち
、共通エンジン（または関数やライブラリ）には、１以上のステップ（ソース符
号化、チャネル符号化、変調の各ステップ）、あるいはそれらの逆のステップ（
ソース復号化、チャネル復号化及び復調の各ステップ）を実行するアルゴリズム
が含まれる。これらのアルゴリズムには、例えば、高速フーリエ変換（ＦＦＴ）
、（様々な拘束長、ガロア多項式及びパンクチャリング・ベクトルを備えた）ビ
タビ復号器、リード・ソロモン（Reed Solomon）エンジン、ＭＰＥＧ復号器用離
散余弦変換（ＤＣＴ）、エラー・デコヒーレンス（error decoherence）のため
の時間及び周波数ビット毎の再オーダリング、複素ベクトル乗算及びオイラー合
成などが含まれる。さらに広範囲のリストが添付書類２の中に含まれている。上
記アルゴリズムは高ＭＩＰＳルーチンであり、したがって、理想的にはアーキテ
クチャ独自の方法で（アセンブリ・コードまたはハードウェアによる加速処理の
いずれかを介して）ＣＶＭの中で実現される。上記の事実にかかわらず、共通の
高水準ＡＰＩを通じてＣＶＭ内のこれらのアルゴリズムのアクセスすることがで
きる。これらのパラメータ化された変換の各々は、この各変換について設けられ
る並列的数学モデリング・ブロックが含まれる。この共通構造は、（当該シンボルの範囲内に保持されているすべての情報が利
用できるか否かにかかわらず、フル・シンボルの処理に関係する）シンボル処理
部と、関連情報を保持する当該ビットのみを処理するデータ指示型処理との復号
化チェーンへの分割に関与するものである。各ケースで、これらの処理用モジュ
ールが、中間の整合メモリ・バッファの割り当て、共有、配置を行い、処理用モ
ジュール間でイベントを渡し、モジュラ型開発を可能にする枠組みの範囲内に存
在できるようにすることが非常に重要である。この共通構造は、数学モデリング
環境の適切な場所に並列化され、グラフ記述言語（ＧＤＬ）を介して記述される
。図６は、ＣＶＭで利用されるこの共通ブロック及び共通構造によるアプローチ
を概略的に描くものである。追加のＣＣＳ（同時システムの微積分法）要件と資源割当て問題が存在すると
いう点と、処理用エンジンの必要な'臨界容量'がわずかに異なるという点とを除
いて、２方向システムについても同様の分析を行うこともできる。現在の世代のサード・パーティ・アプリケーションの開発用ツールと、ハード
ウェア配置用プラットフォーム（ＤＳＰ及びＤＳＰコア）とが、上述の構造的現
実を反映していないこと、及び、（概して）通信ベースバンド・アプリケーショ
ンに合わせて仕立てられたハードウェアによる加速処理を行わないこと、また、
２段階スケジューリング・アプローチ（下記を参照のこと）も行わないことは興
味深いことである。また、現在の組み込まれたオペレーティング・システムでも
系統的なあるいは統合化された方法での上記処理やアプローチのサポートは行わ
れていない。しかし、デジタル通信システムの数は急速に増加しつつあり、ベースバンド・
スタックの研究開発から製品化までの短い期間内の市場への投入に対する要望が
生まれている。以上説明したように、本発明の中核を成す革新的アプローチは、
ソフトウェアにより提供された'バーチャル・マシン層'（ＣＶＭの実施例により
例示される）を提供し、これらの能力とソフトウェア構造とを具体化することに
より、基底を成す共通性とこのようなシステム要件とを利用することである。１
つの主要な市販アプリケーションは、（上述したような）ＳｏＣなどのハードに
よるリアルタイムの、マルチベンダの、マルチプロトコル環境に対する設計上の
ソリューションのようなものである。ＣＶＭ開発方法論ＣＶＭで用いられる開発方法論は、層化された開発と層化された配置を用いる
方法論から出発し、この方法論を利用するものである。これらのコンセプトにつ
いて最初に解説する：層化された開発とは、（必要に応じて）数学モデルから、
Ｃ＋＋またはＳＤＬコードを通じて、ターゲット・アセンブラの実現構成へ進む
プロセスを意味する。このプロセスを通じてずっと、当該モジュールの各々は、
必要なレベル（例えば、並列的数学モデル、Ｃ＋＋実現構成、ＳＩＭＤモデル及
び様々なターゲット言語によるアセンブラの実現構成として畳み込み復号器が存
在する）の各々に維持される。層化された配置とは、受信機のスタックが実際に実現されたとき、基底を成す
ハードウェア及びホストのオペレーティング・システムから可能な限りコードを
切り離すためにライブラリを利用することを意味する。したがって、可能な限り
多くのコード（高度の複雑さと共に低ＭＩＰＳ要件）が、一般的ＳＤＬまたはＡ
ＮＳＩ対応Ｃ＋＋（これはその後、ターゲット・プラットフォーム用として単純
に再コンパイルされる）として保持される。例えば、単純なＩ/Ｏ、メモリ・バ
ッファの割当てなどのようなプラットフォームに依存する機能を提供するために
ライブラリが利用される。（ＦＦＴ、ビタビ復号器などのような）反復して使用
される回数の多いルーチンをアーキテクチャ独自の方法で提供するために別のラ
イブラリが利用される。このアーキテクチャ独自の方法には、好適に設計された
アセンブラル・ルーチンの利用や、専門用ハードウェアによる加速処理用エンジ
ンに対するコールスルー（callthrough）の利用までも含むこともできる。上記２つのライブラリは、基底を成すハードウェア及びオペレーティング・シ
ステムのサブストレートの如何に関らず、移植中修正を行う必要がない'コア'コ
ードとの共通のＡＰＩとして明白なものである。修正すべき唯一のコード、すな
わちライブラリの実現構成の内容は、意味のあるカプセル化と数学モデルから生
成される多種多様のテスト・ベクトルから利益を得る。その理由として、スタッ
クの移植を高速に行うことが可能なアーキテクチャ内の接続ポイント（point of
articulation）が、上述のアプローチを用いて適切に配置されているというこ
とが挙げられる。さらに、開発用プラットフォームとして、上記アプローチには、数学モデルを
実行するのではなく、逆に完全なリアルタイム送受信装置を実行する１つのアー
キテクチャ（インテルのプラットフォームなど）上で開発を行い、次いで、単純
にライブラリのスワップを行い、ターゲットのアーキテクチャで再コンパイルを
行うことが可能であるという大きな利点がある。これは、等化器モジュールの同
調などを試みる際非常に有用なものとなる。ＣＶＭによるアプローチは上記のような作業方法を利用するものである。しか
し、これに加えて、すべてのデジタル通信用ベースバンド処理作業にとって有用
な主要サービス及び機能と共に、可能な限り多くの共通の機能が分離されて'バ
ーチャル・マシン'のハードウェアの分離層の中へ入れられる。以下の図７は、上記のことがアーキテクチャのレベルで機能する方法を示すも
のである。プラットフォームＡとプラットフォームＢ用の異なるライブラリの実
現構成を備えて与えられるスタックを出荷する代わりに、ＣＶＭの中に、プラッ
トフォームＡとプラットフォームＢの各々のための共通の'ベースバンド・オペ
レーティング・システム'層が存在し、共通のＡＰＩが与えられる。この共通の
ＡＰＩの上で（再コンパイルを除いて）変らない状態のままさらに高いレベルの
コードの実行が可能となる。さらに、シンボル指示型処理のためのシンボル・サブスクライバ（symbol sub
scriber）アーキテクチャやデータ指示型処理のためのパイプライン・アーキテ
クチャのような、別様の場合、Ｃ＋＋コアの範囲内に存在するような機能の多く
をこの層の中へ組み込むことが可能である。具体的なＣＶＭ開発方法論：２段階スケジュリング段階Ｉベースバンド通信システムを構築する際の１つの重要な側面として、アプリケ
ーションが実行される、ハードウェアとソフトウェアのプラットフォームとの要
件の定量化がある。アプリケーションが要求するＭＩＰＳ（１００万命令毎秒）
の回数のベースライン計算は比較的簡単であり、単に、１つの処理を実行するた
めの、各コンポーネントの要求条件を計算し、処理回数を乗算し、それらすべて
を一緒に加算するだけのものにすぎない。しかし、上記の中には並列要因のよう
な側面は考慮されていない。２×５００ＭＩＰＳのプロセッサは理論的には１０
００ＭＩＰＳの処理パワーを転送するとはいえ、別のチップでの処理の完了を待
機している場合、アルゴリズムがこのパワーを利用できない場合もある。また、
スケジュラの特別の処理要件、及び、考慮すべきデータ転送オーバーヘッドも存
在する。２つのプロセッサが同じボード上に存在する場合、データ転送ペナルテ
ィはおそらく小さなものであるが、２つのプロセッサが１つの外部バスの中へプ
ラグ・インされた別個の独立のボード上に存在する場合には、データ転送ペナル
ティはさらに大きなものとなる。バスの競合（２以上のプロセッサが同時にデー
タの転送を望むこと）によっても能率全体が低下する可能性がある。ＣＶＭによ
って、この種の分散型環境におけるシステムの実現を容易にするいくつかの方法
が提供される。最初に、添付書類２に記載されている信号処理用の関数などの個々の計算用コ
ンポーネント要件、及び、添付書類２に記載されている信号処理機能に基づいて
組み立てられるさらにアプリケーション独自のエンジン要件の定量化が可能であ
る。３Ｇ移動通信のような環境では、１つのブロックの内を通過するデータ量は
時間中変動するため、１回のデータ転送速度で１つのブロックの要件を計算する
だけでは十分ではない。その代わりに、プロファイルは潜在的入力ベクトル・サ
イズの範囲にわたって組み立てられる。ＣＶＭによって、一方の端でデータを注入し、もう一方の端で消費するデータ
・フロー（パイプライン）のコレクションとしてシステムを定義することが可能
となる。これらのパイプラインのエンジンは、入力ベクトル・サイズの関数とし
てエンジンがどれだけ多くの処理を必要とするかという点から特徴づけられる。
ＭＩＰＳの使用計算の第１のパスとして、このパイプラインに沿う、変動するサ
イズのエンジンの通過シミュレーションと、入力ブロック・サイズの関数として
の上記使用合計の計算とが行われる。これにより、単一のプロセッサにおいて完
了まで連続して実行したと仮定した場合のエンジンのＭＩＰＳ要件の合計が計算
される。さらに優れたモデルによってプロセッサを切り離すためにエンジンが割り当て
られ、真のパイプライン接続が可能になる。このアーキテクチャに基づくソリュ
ーションは、単一のスレッドされたソリューションよりもさらに多くのＭＩＰＳ
を必要とすることになるが、いったんパイプラインがロードされると、より短い
経過時間でデータ・エンジンを処理できる可能性が生じることになる。Ｎをプロ
セッサの数、Ｅ（Ｎ）をプロセッサの利用効率（１＝１００％、０＝ゼロ）、Ｍ
ｐを単一プロセッサのＭＩＰＳの定格、Ｍを当該ＭＩＰＳ要件の合計とすると、
１秒のデータ処理時間Ｔは、下式で表される：Ｔ＝Ｍ／（Ｅ（Ｎ）×Ｎ×Ｍｐ）上式の目的はＮの最小値を見つけることである。但しＴは"ゆとりのある（com
fortable）"マージンの１未満の数とする。Ｅ（Ｎ）は、単一のボードの場合１
に接近し、（スケジュリングとデータ転送により導入されるオーバーヘッドに起
因して）ボード数の増加に伴い低下する。Ｅ（Ｎ）は、処理用エンジンがボード
間でどのように分散されるかによっても変動する（この変動は、変動するデータ
転送要件と、不規則な負荷バランスがプロセッサをしばらくの間アイドル状態に
放置する可能性とに起因する）。スケジュリング処理と、バスの特性と、エンジンの特性とに関する情報を持っ
ているＣＶＭシミュレータは、様々な数のボードとエンジン構成についてＥ（Ｎ
）したがってＴの計算を行うことができる。また若干のエンジンの"ダブルアッ
プ（doubling up）"（２以上のボード上で同じ機能を持つこと）の影響を調査す
ることも可能となる。あるタスクのために必要な一続きのエンジンをいったん認知すると、ＣＶＭが
セットされ、エンジンとボードの構成を介して最適解を探す探索が可能となる。
ボードの個々のＭｐ値を出し（Ｎ×Ｍｐをこの個々のＭｐの和で置き換える）、
特定のエンジンを特定のボードに結びつけることも可能となる。例えば、ビタビ
復号器はＤＳＰよりも高いＭＩＰＳ定格を持つＦＰＧＡ上で常に実行する。多数
のエンジンについての網羅的探索は実行不可能となるため技術者からの何らかの
助けが必要となる。段階ＩＩいったんエンジンとボードの受け入れ可能な構成が得られると、"本気で実行
する"スケジュリング処理の段階ＩＩへ進むことができる。段階Ｉは、正しいボ
ード上へのエンジンのロードに使用することはできないシステム構成を生成した
ことになる。メインボードのスケジュラもこの情報を利用することが可能となる
。いったんシステムが実行すると、データ・エンジンはスケジュラから、データ
に対して機能するエンジンへ流れる。ほとんどの時間、このスケジュラは単に、
処理を必要とする順にデータを先へ送るにすぎないが、より多くの知能的処理の
適用が可能となる場合が生じてくる。同等の優先順位を持つ複数のエンジンが存
在する場合、スケジュラは、作業ロードが最少となるようにスケジュリングを行
うことにより、すべてのボード上でキュー・サイズのバランスをとることを試み
る。２以上のボード上に同じ機能が存在する場合、スケジュラはスケジュリング
を行うための最適ボードを再び探索する。同じボード上の２つのエンジン間でエ
ンジンのルート選定を行う際にメインのスケジュラの関与が不要となるように、
すべてのボードにはローカルなスケジュラが設けられる。スケジュラは、作業を
送るボード選択権がある場合、可能であれば自分のボードを常に選択する。また
スケジュラは、ログ・メッセージのルート選定やモニタ用コンソールへの情報の
モニタ・バックなどのような緊急性の少ない活動のスケジュリングが可能な場合
には、処理時の潜在的小休止状態（lull）を探索することにより、最も緊急を要
するエンジンの絶対的緊急性をモニタする必要がある。さらなるＣＶＭ開発方法論：ＵＭＴＳでの実現構成で使用されるようなＭＩＰ
Ｓカウンタ上述したように、ＣＶＭは、ＣＶＭスケジュラによって接続され、制御される
複数の分散型エンジンから構成される。これらのエンジンは同じハードウェア上
に位置するものであってもよいが、異なるハードウェア（ＣＰＵ、ＤＳＰまたは
ＦＰＧＡ）上に位置することも可能である。ＣＶＭのＵＭＴＳでの実現構成の場
合、障害を特定し、エンジン／ブロックの連続化を助けるシステムが開発されて
いる。まずデータ・ブロック用の処理ルートが与えられているものと仮定する。
例えば、ＵＭＴＳ規格２５.２１２と２５.２２２にはＴｒＣＨ段階でのブロック
の多重化方法が提案されている。その場合、ＢＥＲのような何らかの客観的判断
基準に応じてルート間で処理の若干を切り替えてもよい。しかし、必要なエンジ
ンについては認知されている。次いで、データ・サイズとユーザの数という点か
らエンジンのサイズを決定しなければならない。例えば、ベクトルが長さｎで、
かつ、エンジンが以下、 for (int i=0, i < n, i++) { for (int j=O, j < n, j++) { // Do something... } } から構成されている場合、この処理はｎ２またはＯ（ｎ２）の次数であるという
ことができる。次に、基本命令（（//Do something'）内の'＋'，'−'，...）の
数をカウントすることができる。例えば、ＦＦＴによってｎＬｏｇ（ｎ）回の演
算処理が行われることになる。次いで、この演算回数に１基本命令当たりのデバ
イスの実行命令の回数を乗算し、次いで、これをＭＩＰＳの回数で除して、タス
クの実行にデバイスが要する時間を得ることができる。或いは、単に相対時間を
設定してもよい。ユーザの数（Ｋ）について同じ処理を繰り返すことができる。例えばＭＵは２
Ｋのような数になる場合もある。最終的に、各ブロックはビットレートの変更を
行ってもよいし、行わなくてもよい。ターボ符号化によってビットレートは３倍
だけ増え、ＣＲＣの使用により１２ビットが加算される。（バスの待ち時間、ス
ケジュラ、並列化／連続化はすべてエンジンと考えることができることに留意さ
れたい）重要な点は当該データ転送速度がわかっているという点である。上記処理によ
り解答が得られる問題として、エンジン（エンジンのＭＩＰＳ予算など）をどの
ように配分してその調整を行うようにすることができるかということが挙げられ
る。トップ・ダウン方式による設計状態制御とデータ制御とを必要とする場合、処理用チェーンの走査はきわめて
複雑となる。この処理手順を用いて、標準的アダプタを介してＲＳの中にＣ＋＋
ブロックが結びつけられ、Ｓｉｍｕｌｉｎｋとの統合化が行われる。基本的に、
上記処理の意図は階層の中を移動することである。層を上位へ移動するほど抽象
のレベルがだんだん高くなる。その意図は、３つのサービスについて'ユーザ'が
作成するデータのラウンド・トリップを行うことである。ＵＥによって、ある一
定のプロパティを持つ物理チャネルを介してＢＳへのデータの送信が行われる。
ＢＳは上記データを受信し、復号化する。この場合、ＢＳは簡単なバックホール
を持ち、物理チャネルを介してデータを再転送して元のＵＥへ戻し、このＵＥで
上記データは入力データと比較される。このシステムによってエンジンの入替え
が可能になり、種々のチャネルにおけるＢＥＲと時間という点からパフォーマン
スの改善が図られる。ＣＶＭの特性ＣＶＭは、ベースバンド処理スタックが必要とする種類の機能を提供する最低
限のＯＳと考えることもできる（また、上述したように、これらのスタックはＧ
ＳＭやブルートゥースのような２方向スタックであってもよい）。したがって、
ＣＶＭは、マイクロソフト社のウィンドウズＣＥやシンビアン社のＥＰＯＣのよ
うな、本格的な内蔵型オペレーティング・システムと相補うものである。ＣＶＭでは、（特に）下記の機能が提供される：＊ＦＦＴフィルタ、ＦＩＲフィルタ、ＩＩＲフィルタ及びウェーブ・ディジ
タル・フィルタ、及び、デシメーション、相関、複素乗算などのようなオペレー
ションをカバーする広範囲のセットのベクトル処理用プリミティブ（さらに多く
のプリミティブが添付書類２に完全にリストされている）上記オペレーションは
、基底を成すハードウェアで加速処理が利用可能なハードウェアによる加速処理
を利用することが望ましく、さらにこれらのオペレーションは、ライブラリの拡
張バージョンを並列化する１組のライブラリ呼出しを介してアクセスされること
になる。ある意味では、ＣＶＭのこの側面は、デジタル通信を行うための理想化
されたデジタル信号処理用エンジンのソフトウェアまたはＡＰＩの抽象的な形を
表すものである。＊整列バッファの割当てと、メモリ'ハンドシェーキング'（ピンポン・バッ
ファ）とのサポート＊単純な種類のプリエンプティブ・マルチスレッドのオプションを備えた高
度スケジュリング管理ハードウェアによるリアルタイム・パフォーマンス（すな
わち、ある特定の時点に１つのコードが処理を実行する）がアーキテクチャの主
要なコンポーネントとしてサポートされる。プロセス間通信構造（少なくとも共
有メモリ）とスレッド同期ファシリティとが提供される。主要な特長として、確
率的並列スケジュラがあり、このスケジュラは計算用異種サブストレートの両端
にわたるＣＶＭエンジンに対する設計時間の分割の決定を認識するものである。＊シンボル指示型及びデータ指示型処理についての概念の明示的サポートこ
れは、シンボル・サブスクライバ（symbol subscriber）とパイプライン段階と
を構造の中へ付加してモジュラ型の開発を可能にする能力を直接サポートするも
のである。＊シリアルポート、パラレルポート及び表示制御装置を含む主要なＩ／Ｏ周
辺機器のサポート＊特に、モジュラ型Ｉ／ＯサポートのＯ／Ｓの範囲の拡大を可能にする拡張
性＊数学モデルとリアルタイム・プロトタイプとが、ターゲット・サブストレ
ートと相互接続とのパフォーマンスのシミュレーションを高度の正確さで行うこ
とを可能にする特定の実現構成についての特性ライブラリ＊リアルタイム・プロトタイプの製造を可能にするＰＣバージョン＊ホスト（アプリケーション）のＯＳとの通信のサポート：この通信はコー
ルバック等々を可能にする双方向通信となる。２進'グルー'を行うためにコンポ
ーネント相互通信技術（ＣＯＭなど）を利用してもよい。好適なアプリケーショ
ン用ＯＳとしては、例えばＥＰＯＣ３２やウィンドウズＣＥであってもよい。な
ぜなら、これらのＯＳは、より一般的なユーザ・レベルのＩ/Ｏと、構造化され
た記憶管理とを実行するように設計されたＯＳであるからである。＊最小の（したがって最終的にはチップ面積の）ＲＯＭの利用を保証するた
めに組立てタイム（build time）においてＣＶＭのＲＯＭ画像を'削減する（par
e down）'能力これはＣＶＭの最低限の実現構成を利用するものである。＊状態マシンの機能管理（ＳＤＬとの潜在的統合化を含む）＊データ構造のサポート＊（固定小数点や浮動小数点などのような）異なる表現間の変換ＣＶＭの目標は、開発段階での多数のアプリケーションを用いて、特定アプリ
ケーションの高速な利用を特定のターゲット上で可能にすることである。従来の
ＯＳは、ＯＳがロードされたとき実質的に未知の種々のアプリケーションの実行
時サポート用として設計されているが、一般にＣＶＭについては事実はそうでは
ない。さらに、ＣＶＭは、'ホスト'のＯＳが提供するポータルを介するプレゼン
テーション・ストリームのサポートによる処理を除いて、ユーザとのインタラク
ション処理を必要としない。ＣＶＭは、インフラ・ストラクチャ・レベル（シンボル指示型及びデータ指示
型処理の開発のための適切なモジュラ型構造など）の中へＤＡＢスタックの高レ
ベルのＣ＋＋コードの中に現在存在するいくつかの特性を組み込んでおり、単な
る'ライブラリ・ラッパ'ではない。ＣＶＭというコンセプトは、共通機能の分離と、（重要なことであるが）最新
のデジタル放送及び通信規格によって求められる処理構造の分離とが可能であり
、系統的に層化された開発環境と結合された適切なソフトウェア分離層を介して
、これらの分離のエレガントな達成が可能であるという着想（様々な規格のレビ
ューによってしか達成できないドメイン情報と、実際のスタックの構築処理とに
大きく依存する）に基づくものである。ＣＶＭの利点ＣＶＭでは、スタックの開発者たちは使用中の特定のハードウェアから切り離
される。ＣＶＭとは、（シンボル指示型及びデータ指示型パイプライン及び状態
マシンなどの）構造と、（メモリ割付け、リアルタイム資源、同時性管理など）
機能と、デジタル通信用ベースバンド・スタックにより求められる（ＦＦＴ、ビ
タビ、畳み込みなどの）ライブラリとをサポートし、それによって、高水準言語
（ＳＤＬ、ＡＮＳＩＣ／Ｃ＋＋またはＪａｖａ）によるコードの１回の書込みと
、単なる再コンパイル（必要な場合には、Ｊａｖａを用いてコードの再コンパイ
ルを行わずに、ＣＯＭまたはコンポーネントの相互通信技術の何らかの別の形に
より'２進レベルの'グルーを行ってモジュールを一緒にリンクすることも可能で
ある）とが可能になるようにして、特定のプラットフォーム上で実行し、それに
よってＣＶＭ層により供給されるハードウェア分離層を介して呼出しを行うよう
にするものである。ＣＶＭを用いるプロトタイピングは非常に高速なものとなり、ＤＳＰモジュー
ルの各々は数学モデルにより並列に設けられる。メモリ割付けと分割は、推測作
業に依拠するのではなく、（所望のターゲット・ハードウェアによりパラメータ
化された）自動化されたツールセットによりサポートされる。いったん処理用チ
ェーンがモデルに対して設定され（この設定は、符号化の代わりにこのグラフィ
ック構成とパラメータ化とによりオプションとして実行される）、作業が首尾よ
く行われていると、リアルタイムのＰＣベースのバージョンの実行が可能になる
（RadioScape社の汎用ベースバンド・プロセッサ・モジュールを備えたＣＶＭの
ＩｎｔｅｌＭＭＸ／ＳＩＭＤバージョンが用いられる）。（カスタム等化器な
どの）標準的コードに対する任意の変更をモジュラ型増分方法で統合化すること
が可能であり、さらに（ＰＣベースの）符号化／テスト／編集サイクルはすべて
の最新のＰＣ開発用ツールを利用することもでき、非常に高速なものとすること
も可能となる。ターゲット・プラットフォームでのハードウェア加速処理の利用
がＣＶＭによりカバーされている（これは、デジタル通信のベースバンド処理の
ための、多くのサイクルを要する所要の特性がＣＶＭＡＰＩでのライブラリ呼
出しとして提供されるためである）。好適に適合された基底を成すハードウェア
・ユニットによって、所望の機能のほとんどのためのターゲットとする加速が与
えられることは明らかである。多くのアプリケーションの場合、軽量のプリエン
プティブ・マルチスレッドと、ＣＶＭ自体でのその他の低レベルの機能とをサポ
ートすることにより、何らかの別のＲＴＯＳの利用は不要となるが、（ウィンド
ウズＣＥやシンビアンのＥＰＯＣなどのような）ユーザのＯＳとのインタラクシ
ョンは上述のＡＰＩを介してサポートされ、単純になる。このアプローチでは、いったん書き込まれたＣＶＭ互換スタックは、特別の作
業を伴うことなく、ＣＶＭ自身が移植されたハードウェアのプラットフォームの
いずれへも瞬時に移植可能となる（言うまでもなく、リアルタイムで所望のスタ
ックを実行するための十分な資源（ＭＩＰＳ、メモリ、帯域）がターゲット・マ
シンに常に存在するものと仮定する）。こののことは、（多くのタイプのハード
ウェアで使用できる適正なＣＶＭのプラットフォームが市場に浸透すると仮定す
ると）スタック・ベンダにとって実質的な販売の機会が生じることを表すもので
ある。というのは、これはハードウェアの特殊性からスタック・ベンダの開発を
実質的に切り離すものであるからである。また、マルチベンダＳｏＣ製品を設計
するための特にめざましいビジネス・チャンスも生じる。ハードウェア・ベンダの視点から見ると、ＣＶＭの利点として、ＣＶＭがいっ
たん所定のプロセッサ用として移植されると、当該プロセッサが、（資源が許せ
ば）ＣＶＭＡＰＩに対して書き込まれたすべてのスタックを自動的にサポート
するということが挙げられる。言うまでもなく、このことによって、ハードウェ
ア・プロバイダはアプリケーション・ビジネスの中へ入ってゆくことが不要にな
る。彼らはＣＶＭを移植するだけで十分となる。またこのことは、（少なくとも
デジタル通信マーケット向けの）スタック・ベンダが、その場合、ＡＮＳＩＣ
／Ｃ＋＋またはＪａｖａで純粋にコードを開発することができるので、完全仕様
の開発環境とツールセットを形成しサポートする必要性が少なくなることも意味
する。ＣＶＭというコンセプトは、例えば、自動車用ブレーキ・システムで使用
されるＰＩＤコントローラを作るというような、すべてのデジタル信号処理タス
クに適用されるというわけではないことに留意されたい。ＣＶＭのコンセプトが
デジタル通信用ベースバンドの処理用として機能する理由として、上記に説明し
たように、利用が可能なこのようなシステムの中に共通性を示す広いプールが存
在することが挙げられる。しかし、ＣＶＭは、別のデジタル信号処理タスクに必
要とされるようなすべてのツール、構造あるいは機能を必ずしも提供するもので
はない。言うまでもなく、共通の機能を示す別のそのような'島（island）'を特
定し、それらの'島'のニーズをカバーするＣＶＭのイディオム（idiom）の拡張
を行うことは潜在的には可能であろう。しかし、本願出願者は本明細書において
ベースバンドの側面に焦点を絞っている。なぜなら、ベースバンドの側面が現在
非常に求められており、さらに必要な共通性が強く示されているからである。Ｃ
ＶＭによるアプローチは、ハードウェア・ベンダが、既存のアプリケーション・
セットではなく、代わりに、それらのハードウェアの長所（ＭＩＰＳ、ターゲッ
トの加速、メモリ、電力消費量など）に関して自由に競争ができるようにするも
のである。ＣＶＭ開発サイクル実際にＣＶＭを利用してベースバンド・スタックを開発するプロセスについて
以下説明する。本明細書の目的として、デバイスが、デジタル無線装置などのよ
うな開発中の目標であることが挙げられる。ソフトウェア、ハードウェアあるい
はその双方のいずれかであるコンポーネントは上記デバイスの特定可能な或る特
定の一部である。'解釈される'という表現は、実行時に構成を読み込む（おそら
くコンパイルされた）コードを意味する。開発サイクルは'コンポーネント定義言語'から始まる。この言語によって、コ
ンポーネントの完全な外部からの可視属性の特定並びにその振舞いが可能になる
。その意図として、メーカーがこの可視属性を書き込むことが可能であること、
あるいは（後程見るように）計装化ＣＶＭの試運転によりこの可視属性の生成が
可能であることが挙げられる。プラグ・インを介して、業界でポピュラーなＭａｔｌａｂやＭｔｈｅｍａｔｉ
ｃａのような数学モデリング用ツールに１組のコンポーネント定義言語を読み込
むことができる。モデリング用ツールを用いて、デバイスで使用するすべてのコ
ンポーネントの理論上の振舞いが利用され、理解される。上記調査の結果は、開発される別のプラグ・インを介して、'デバイス定義言
語'の中へ転記または出力のいずれかが行われる。ちょうどコンポーネント定義
言語がコンポーネントを定義するように、この'デバイス定義言語'は、構築され
ているターゲット・デバイスを定義し、さらに、どのコンポーネントが使用され
ているかというような要素を含むことになる。言い替えれば、デバイス定義言語は、開発中の通信用'パイプライン'を定義す
るものである。ほとんどの通信用デバイスは、パイプラインを介して情報を動か
し、その途中で変換を実行するプロセスであると考えることができるので、この
パイプラインというコンセプトは重要である。このパイプラインは実際には電子
的なアセンブリ・ラインであるが、自動車の部品で機能するようなものではなく
、一般に'シンボル'と呼ばれるデータ項目に対して機能するものである。このよ
うにして、無線信号が最終的にオーディオ信号へ変換されることになる。言うま
でもなく、'現実の'デバイスは単純なパイプラインよりも複雑であることが多く
、２以上のパイプライン、ブランチまたはループを備えている場合もある。完全
なハードウェア・バージョンを組み立てる前に、このＣＶＭ開発プロセスにより
パイプライン設計のテストを行うことが可能となる。これは開発期間の短縮につ
ながるものとなる。ターゲット・デバイスまたはパイプラインを完全に定義するためにはさらに多
くの情報が必要となる。また、本発明のターゲットで利用可能な（ＣＰＵの速度
などのような）資源についての説明も必要であり、これは'適合性記述用言語'と
相互接続とで定義される。また各コンポーネント（物理的及びソフトウェアの双
方のＡＰＩ）がどのように使用されるかを知っている必要がある。これはコンポ
ーネントＡＰＩ仕様を用いて達成される。これらの３つの資源：デバイス定義言語、適合性記述用言語及びコンポーネン
トＡＰＩ仕様はいくつかの可能なＣＶＭの中の１つの範囲内で使用される。第１
のＣＶＭは'計装化され解釈された'ものパイプライン・マネージャ（あるいは、
好適には、計装化され解釈されたバージョンよりもさらに高速に作動する計装化
されコンパイルされたＣＶＭのほうが望ましい）である。このパイプライン・マ
ネージャは、ソフトウェアＩＣＥとの或る類似性を有するものである。このマネ
ージャは上記３つの資源を読み出し、パイプラインのエミュレーション（エミュ
レーションはリアルタイムであってもよい）を行う。したがって、このマネージ
ャはターゲットが無線装置である場合、無線装置として実行する。適合性記述用
言語に起因して、このマネージャはターゲット・デバイス上に存在するいずれの
障害または資源の限界のシミュレーションをも行うことができ、また、開発とデ
バッギングとを行うために有用なものである。実行に加えて、計装化され解釈さ
れた／または計装化されコンパイルされたパイプライン・マネージャは、各デバ
イス内コンポーネント定義言語のための診断情報も出力する。この診断情報は重
要である。というのは、この情報を今度は開発サイクルの中へフィードバックし
、元のコンポーネント定義言語による記述とマージして、その記述の微調整を行
うことができるからである。したがって、何らかのハードウェアの組立てを行う
前に設計者が実際のパフォーマンスに関する情報を利用することが可能となり、
これによって（実質的に）開発の節減が行われる。これによって開発サイクルの
内部ループが閉じられる。計装化され解釈された、あるいは、計装化されコンパ
イルされたパイプライン・マネージャにより、ＣＶＭコアの実行時バージョンが
組み込まれる。計装化され解釈された、あるいは、計装化されコンパイルされた
パイプライン・マネージャのソフトウェア・エレメントをハードウェアのバージ
ョンと交換する（バグが生じたときバグの検出が可能となるように理想的には１
回一度）ことが可能である。この交換されたエレメントは別の開発プロセスのた
めの改善でとなる。この改善は、計算用サブストレートの両端にわたるエンジン
の設計時間段階のスケジュリング処理（上記を参照されたい）に対応するもので
ある。第２のＣＶＭは'解釈されたパイプライン・マネージャ'である。この第２のＣ
ＶＭは計装化されたものではないが、別の点では第１のＣＶＭと同一のものであ
る。この第２のＣＶＭは開発とデバッギング時に利用することができ、また、メ
ーカーが完成製品を製造するために利用することができる。このＣＶＭには、通
信用デバイスの書込み時の作業の多くを予め行うという第３の利点がある。この
ＣＶＭにもやはりＣＶＭコアの実行時バージョンが組み込まれている。第３のＣＶＭは'パイプライン・ビルダ'である。この第３のＣＶＭはコンパイ
ルされた非計装化変形例と考えることができる。他の２つのＣＶＭのように、こ
の第３のＣＶＭも３つの資源を読み出すが、実行する代わりに、Ｃのようなコン
ピュータ・ソースコードを出力し、このコードをコンパイルしてパイプラインの
実現構成の形成が可能となる。この理由のため、パイプライン・ビルダは、ＣＶ
Ｍライブラリを利用できなければならない。利用できるか否かをチェックするこ
とにより開発サイクルの外側のループが閉じられる。ＣＶＭ開発サイクルのアプ
ローチ全体が図８と９に概略的に示されている。 ―附属説明２― コア処理の例信号変換と周波数領域分析＊信号フローグラフ（ＳＦＧ）離散周波数ＤＦＴ＊ウィンドウ操作（ハミング、ハニングなど）デジタル・フィルタリング＊デジタルＦＩＲフィルタ＊インパルス応答＊周波数応答＊ＦＩＲ低域デジタル・フィルタ＊無限インパルス応答デジタル・フィルタ適応信号処理＊適応型デジタル・フィルタを含む適応信号処理用コンポーネント＊チャネル識別＊エコー・キャンセレーション＊音響エコー・キャンセレーション＊暗騒音抑制＊チャネル等化＊適応型ライン拡張機能（ＡＬＥ）＊以下を含む適応型アルゴリズム：＊平均２乗誤差の最少化＊ＦＩＲフィルタ用適応型アルゴリズム＊平均２乗誤差＊最小平均２乗誤差の解＊ウィーナ／ホップ（Wiener-Hopf）解＊傾度法１＊傾度法２＊ＬＭＳアルゴリズム＊再帰的最小２乗法＊適応型ＩＩＲフィルタリング＊勾配ＩＩＲフィルタリング技術＊ FeintuchのＩＩＲＬＭＳ＊等式誤差ＬＭＳアルゴリズム＊直接モード（ＤＤＭ）＊サブバンド適応型フィルタ（ＳＡＦ）構造マルチレート信号処理＊アップサンプリング＆ダウンサンプリング＊内挿ローパス・フィルタ＊オーバーサンプリングと再構成＊シグマ／デルタ処理アーキテクチャ＊サブバンド処理＊反復によるＭチャネル・フィルタ・バンク＊変調フィルタ・バンク＊多相フィルタ・バンク＊ＱＭＦフィルタ・バンクオーディオ信号ソース符号化＊無損失ハフマン（Huffman）符号化／復号化＊線形ＰＣＭ＊圧伸＊適応型量子化ツール＊線形予測符号化＊長期予測＊デルタ変調（ＤＭ）＊差分パルス符号変調＊適応型ＤＰＣＭ（ＡＤＰＣＭ）ＬＰＣボコーダ＊符号励振線形予測（ＣＥＬＰ）＊代数的ＣＥＬＰ（ＡＣＥＬＰ）＊サブバンド符号化＊精神聴覚学用ツール＊スペクトル・マスキング＊時間マスキング＊精度適応型サブバンド符号化及びビット割当て及びビット・ストリーム・
フォーマッティング・ツールデジタル変調＊ＸＯＲ長短コード拡散／逆拡散＊振幅変調＊直角振幅変調（ＱＡＭ）＊直角位相復調＊複雑な直角位相変調＊複雑な直角位相復調＊ＱＰＳＫ＊ｎ−ＰＳＫ＊Ｍ−ａｒｙ振幅偏移キーイング＊ π／ｎＱＰＳＫ＊ユニポーラＲＺ及びＮＲＺシグナリング＊極座標及びバイポーラＲＺ及びＮＲＺシグナリング＊以下を含む帯域通過偏移キーイング＊振幅（ＯＮ−ＯＦＦ）偏移キーイング＊２進位相偏移キーイング（ＢＰＳＫ）＊以下を含む周波数偏移キーイング＊ＢＰＳＫ用帯域フィルタリング＊以下を含むパルス成形＊ナイキスト・パルス成形＊２乗余弦パルス成形＊平方根２乗余弦パルス成形拡散スペクトル・ツール＊擬似乱数コード生成＊黄金シーケンス＊カサミ・シーケンス＊直交拡散符号＊可変長ＯＣ生成＊直交ウォルシュ・コード＊コード検出＊レイク受信装置実装＊以下を含むＮＢＩ拒絶技術＊予測フィルタ＊変換領域におけるＮＢＩ拒絶＊決定フィードバックＮＢＩ拒絶多元接続＆検出管理用ツール＊以下を含むＴＤＭＡ＊ＴＤＭＡフレーム＊ＦＤＭＡと合成されたＴＤＭＡ＊以下を含むＣＤＭＡ＊直接シーケンス（ＤＳ）ＣＤＭＡ＊電力制御＊ビーム成形用ツール＊周波数ホッピングＣＤＭＡ＊マルチユーザ検出（ＭＵＤ）＊多元接続干渉抑制＊非相関性＊干渉キャンセラ＊適応型ＭＭＳＥ＊ＭＭＳＥ受信機トレーニング＊適応型ＭＭＳＥ受信機ＤＤＭ移動チャネル＊レイリー・フェージング抑制メカニズム（ガウス、Riceian）＊以下を含むモデリング及び抑制用ツール：＊タイム・スプレディング＊タイム・スプレディング：コヒーレンス帯域＊タイム・スプレディング：平坦フェージング＊タイム・スプレディング：Ｆｒｅｑ選択フェージング＊チャネルのタイム変形振舞い＊ドップラ効果チャネル符号化＊巡回符号器＊リード・ソロモン（Reed Solomon）符号器＊畳み込み符号器＊ＣＥパンクチャリング＊インターリービング＊畳み込み復号器＊ビタビ復号器（ハード及びソフト決定）＊ターボ・コード＊ターボ符号化＊ターボ復号化等化＊適応型チャネル等化＊ＦＩＲ等化器＊決定フィードバック等化器＊直接変換ツールキット＊ＱＡＭアナログＲＦ／ＩＦアーキテクチャ＊ＱＡＭＩＦダウンコンバージョン・サポート＊帯域通過シグマ・デルタサポート＊ベースバンド・サポートへの帯域通過シグマ・デルタ＊帯域通過及びｆｓ／４システム信号処理ライブラリ関数このセクションはＣＶＭで利用可能な信号処理関数の若干について説明する。ベクトル操作関数 AutoCorrelate 入力ベクトルの通常の、バイアスをかけたあるいはバイアスをか
けていない自己相関を推定し、その結果を第２のベクトルに格納する Conjugate (vector) ベクトルの複素共役を計算し、その結果を対応する当該レ
ジスタ又は別のベクトルに返すことが可能である。 Conjugate (value) 複素数値の共役を返す。 Extended Conjugate 対応する当該レジスタ又は新しいベクトルでベクトルの共
役／対称拡張を計算する。 Exp 各エレメントが、入力ベクトル内の対応するエレメントのパワーに対してｅ
であるベクトルを計算する。この結果は対応する当該レジスタ又は別のベクトル
に返すことができる。 InverseThreshold 閾値を用いてベクトルの逆エレメントを計算する。この結果
は対応する当該レジスタ又は別のベクトルに返すことができる。 Threshold ベクトルで閾値演算処理を実行する。この結果は対応する当該レジス
タ又は別のベクトルに返すことができる。 CrossCorrelate ２つのベクトルの相互相関を推定し、第３のベクトルにその結
果を格納すする。 DotProduct ２つのベクトルに対してExtendedConjucate演算を適用後、２つのベ
クトルの点乗積を計算する ExtendedDotProd ２つの共役シンメトリック拡張ベクトルの点乗積を計算する DownSample 或る信号をダウンサンプルし、概念的に或る整数係数分だけそのサ
ンプリング速度を落とす。第２のベクトルにその結果を返す。 Max ベクトルで最大値を返す。 Mean ベクトルでエレメントの平均値を計算する。 Min ベクトルで最小値を返す。 UpSample 或る信号をアップサンプルし、概念的に或る整数係数分だけそのサン
プリング速度を上げる。第２のベクトルにその結果を返す。 PowerSpectrum (1) 第２のベクトルで複素ベクトルのパワー・スペクトルを返す
PowerSpectrum (2) 実数成分と虚数成分が２つのベクトルで表される複素ベクト
ルのパワー・スペクトルを計算する。第３のベクトルにその結果を格納する。 Add ２つのベクトルを加算し、第３のベクトルにその結果を格納する。 Subtract １つのベクトルを別のベクトルから減じ、第３のベクトルにその結果
を格納する。 Multiply ２つのベクトルを乗算し、第３のベクトルにその結果を格納する。 Divide １つのベクトルを別のベクトルで除し、第３のベクトルにその結果を格
納する。複素ベクトル演算 ImaginaryPart 第２のベクトルで複素ベクトルの虚数部分を返す。 RealPart 第２のベクトルで複素ベクトルの実数部分を返す。 Magnitude (1) 複素ベクトルの要素の振幅を計算し、第２のベクトルにその結果
を格納する。 Magnitude (2) この第２のバージョンは、個々の実ベクトルで指定された実数成
分と虚数成分を持つ複素ベクトルの要素の振幅を計算し、第３のベクトルにその
結果を格納する。 Phase (1) 第２のベクトルで複素ベクトルの要素の位相角を返す Phase (2) それぞれ実ベクトルと、虚ベクトルで指定される実数成分と虚数成分
とを持つ複素入力ベクトルの要素の位相角を計算する。この関数は、第３のベク
トルに結果として生じる位相角を格納する。 ComplexToPolar 個々の入力ベクトルの実数／虚数（デカルト座標Ｘ／Ｙ）の対
を極座標形式に変換する。１つのバージョンは、１つのベクトルに各要素の成分
の振幅（半径）を格納し、別のベクトルに各要素の位相（角）成分を格納する。 ComplexToPolar 第２のバージョンは、単一ベクトルで（振幅、位相の）対とし
て極座標を返す。 PolarToComplex ベクトルに格納される極形式（振幅、位相）の対を複素ベクト
ルに変換する。この結果を第２のベクトルで返す。 PolarToComplex 個々のベクトルに格納された極形式の振幅／位相の対を複素ベ
クトルに変換する。この関数は第３のベクトルにその結果の実数成分を格納し、
第４のベクトルに虚数成分を格納する。 PolarToComplex ２つの個々のベクトルに格納された極形式の振幅／位相の対を
複素ベクトルに変換する。この関数は、第３のベクトルにその結果の実数成分を
格納し、第４のベクトルに虚数成分を格納する。サンプル量子化これらの方法は線形と非線形量子化方式との間での変換を行う。使用ビット数と
、使用非線形パラメータとは変更してもよい。 ALawToLinear Ａ−ｌａｗ符号化サンプルのベクトルを線形サンプルへ変換する
。この結果は対応する当該レジスタ又は別のベクトルに返すことができる。 LinearToALaw 線形サンプルベクトルを符号化する。この結果は、Ａ−ｌａｗフ
ォーマットを用いて、対応する当該レジスタ又は別のベクトルに返すことができ
る。 LinearToMuLaw μ−ｌａｗを用いてベクトルで線形サンプルを符号化する。この
結果は対応する当該レジスタ又は別のベクトルに返すことができる。 MulawToLinear ８ビットμ−ｌａｗの符号化されたサンプルのベクトルを線形フ
ォーマットに変換する。この結果は対応する当該レジスタ又は別のベクトルに返
すことができる。サンプル生成関数 RandomGaussian ガウス分布を用いて疑似ランダム・サンプルのベクトルを計算
する。 InitialiseTone 所定の周波数、位相及び振幅を用いて正弦波発生装置を初期化
する。 NextTone InitialiseToneを用いて指定された周波数、位相、振幅の正弦波の次
のサンプルを生成する。 InitialiseTriangle 所定の周波数、位相及び振幅を用いて三角波発生装置を初
期化する。 NextTriangle InitialiseTriangleのパラメータを用いて生成された三角形波の
次のサンプルを生成する。ウィンドウ関数 BartlettWindow ベクトルにBardentウィンドウ関数を乗算する。その結果は第２
のベクトルで返される。 BlackmanWindow ユーザ指定パラメータを用いてベクトルにBlackmanウィンドウ
関数を乗算する。その結果は第２のベクトルで返される。 HammingWindow ベクトルにHammingウィンドウ関数を乗算する。その結果は第２
のベクトルで返される。 HannWindow ベクトルにHannウィンドウ関数を乗算する。その結果は第２のベク
トルで返される。 KaiserWindow ベクトルにKaiserウィンドウ関数を乗算する。その結果は第２の
ベクトルで返される。畳み込み関数 Convolve ２つのシーケンスの有限、線形畳み込みを実行する。 Convolve2D ２つの２次元信号の有限、線形畳み込みを実行する。 Filter2D Convolveと類似の２次元信号をフィルタする。但し、同じサイズの入
出力配列を用いる。フーリエ変換関数これらの方法のバージョンは、複数の異なるデータ格納（固定型、浮動型、整数
型）フォーマット用のものが存在する。 DiscreteFT 対応する当該レジスタ又は別のベクトルで離散フーリエ変換を計算
する。 InitialiseGoertz Goertzel関数により使用されるデータを初期化する。 ResetGoertz Goertzel関数により使用される内部遅延ラインをリセットする。 GoertzFT(1) 単一信号カウント用の所定の周波数についてＤＦＴを計算する。 GoertzFT(2) 連続する信号カウント・ブロック用の所定の周波数についてＤＦＴ
を計算する。 FFT (1) 対応する当該レジスタ又は別のベクトルのいずれかでベクトルの複素高
速フーリエ変換を計算する。 FFT (2) 対応する当該レジスタ又は別のベクトルのいずれかで２つの共役左右対
称信号の順方向高速フーリエ変換を計算する。 FFT (3) 対応する当該レジスタ又は別のベクトルのいずれかで１つの共役左右対
称信号の順方向高速フーリエ変換を計算する。 FFT (4) 複素ベクトルの高速フーリエ変換を計算し、その結果を２つの別々の（
実数と虚数）ベクトルで返す。 FFT (5) ２つの別々の（実数と虚数）ベクトルとして与えられた複素ベクトルの
高速フーリエ変換を計算し、その結果を２つの別々の（実数と虚数）ベクトルで
返す。 IFFT (1) 対応する当該レジスタ又は別のベクトルのいずれかでベクトルの逆高
速フーリエ変換を計算する。 IFFT (2) 対応する当該レジスタ又は別のベクトルのいずれかで２つの共役左右
対称信号の逆高速フーリエ変換を計算する。 IFFT (3) 対応する当該レジスタ又は別のベクトルのいずれかで共役左右対称信
号の逆高速フーリエ変換を計算する。有限のインパルス応答フィルタ関数 InitialiseFIR １セットの；１組の遅延ライン値とタップとを用いて低レベル、
単一レート有限インパルス応答フィルタを初期化する。 FIR InitialiseFIRを用いて前に構成された低レベル、有限インパルス応答フィ
ルタを介して単一サンプルをフィルタする。 BlockFIR 低レベル有限インパルス応答フィルタを介してサンプルのブロックを
フィルタする。 GetFIRDelays 低レベル有限インパルス応答フィルタのための遅延ライン値をゲ
ットする。 GetFIRTaps 低レベル有限インパルス応答フィルタのためのタップ係数をゲット
する。 SetFIRDelays 低レベル有限インパルス応答フィルタのための遅延ライン値を変
更する。 SetFIRTaps 低レベル有限インパルス応答フィルタのためのタップ係数を変更す
る。 InitialiseMultiFIR 低レベル・マルチレート有限インパルス応答フィルタを初
期化する。 MultiFIR InitisliseMultiFirを用いて前に構成された低レベル・マルチレート
有限インパルス応答フィルタを介して単一サンプルをフィルタする。 BlockMultiFIR InitisliseMultiFIRを用いて前に構成された低レベル・マルチレ
ート有限インパルス応答フィルタを介してサンプル・ブロックをフィルタする。最小乗平均適合化フィルタ関数 InitialiseSALF 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レ
ート適応型ＦＩＲフィルタを初期化する。 InitialiseMALF 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マル
チレート適応型ＦＩＲフィルタを初期化する。 InitALFDelay 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型Ｆ
ＩＲフィルタ用遅延ラインを初期化する。 SALF 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート適応型
ＦＩＲフィルタを介してサンプルをフィルタする。 MALF 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレート適
応型ＦＩＲフィルタを介してサンプルをフィルタする。 SLF 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート適応型Ｆ
ＩＲフィルタを介してサンプルをフィルタするが、２次信号用としてフィルタの
適合は行わない。 MLF 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレート適応
型ＦＩＲフィルタを介してサンプルをフィルタするが、２次信号用としてフィル
タの適合は行わない。 EnginesALF 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート
適応型ＦＩＲフィルタを介してサンプルのブロックをフィルタする。 BlockMALF 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレー
ト適応型ＦＩＲフィルタを介してサンプルのブロックをフィルタする。 EnginesLF 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル単一レート適
応型ＦＩＲフィルタを介してサンプルのブロックをフィルタするが、２次信号用
としてフィルタの適合は行わない。 BlockMLF 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル・マルチレー
ト適応型ＦＩＲフィルタを介してサンプルのブロックをフィルタするが、２次信
号用としてフィルタの適合は行わない。 SetALFDelays 低レベル適応型最小２乗平均（ＬＭＳ）アルゴリズムを用いるＦ
ＩＲフィルタ用として遅延ライン値をセットする。 SetALFLeaks 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩ
Ｒフィルタ用として漏れ値をセットする。 SetALFSteps 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩ
Ｒフィルタ用ステップ値をセットする。 SetALFTaps 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩ
Ｒフィルタ用としてタップ係数をセットする。 GetALFDelays 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型Ｆ
ＩＲフィルタ用として遅延ライン値をゲットする。 GetALFLeaks 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩ
Ｒフィルタ用として漏れ値をゲットする。 GetALFSteps 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩ
Ｒフィルタ用としてステップ値をゲットする。 GetALFTaps 最小２乗平均（ＬＭＳ）アルゴリズムを用いる低レベル適応型ＦＩ
Ｒフィルタ用としてタップ係数をゲットする。無限インパルス応答フィルタ関数 InitialiseIIR 指定されたオーダーの低レベル無限インパルス応答フィルタを初
期化する。 InitialiseBiquadIIR 低レベル無限インパルス応答（ＩＩＲ）フィルタをbiquad
s（二次オーダーＩＩＲセクション）のカスケード基準信号に初期化する。 InitialiseIIRDelay 低レベル無限インパルス応答（ＩＩＲ）フィルタ用として
遅延ラインを初期化する。 IIR 低レベル無限インパルス応答フィルタを介して単一サンプルをフィルタする
。 BlockIIR 低レベル無限のインパルス応答フィルタを介してサンプルのブロック
をフィルタする。ウェーブレット関数 DecomposeWavelet 信号をウェーブレット連続に分解する。 ReconstructWavelet ウェーブレット分解から信号を再構成する。離散余弦変換関数 DCT 離散余弦変換（ＤＣＴ）を実行する。ベクトル・データ変換関数このセクションで記述したすべての関数は、（様々な整数長、異なる浮動小数点
フォーマット及び浮動小数点数の固定小数点表示のような）複数の様々なデータ
・フォーマットでの機能が可能である。この信号処理ライブラリには、サポート
されているフォーマットのすべての対の間で単一値とベクトルとを変換する方法
が含まれる。

【図面の簡単な説明】

【図１】ＧＢＰでアルゴリズムによるスケジューリングを示す概略図である。

【図２】本発明のＧＢＰアーキテクチャ（“汎用ベースバンド・プロセッサ”）の実施
構成を示す概略図である。

【図３】ＣＶＭＴＭ（“通信用バーチャル・マシン”）が、高水準ソフトウェアからハ
ードウェアを遮蔽する方法を示す概略図である。

【図４Ａ】ＧＢＰＲＦインターフェースと、デジタル化されたＩＦフィーダと、サード
・パーティのＲＦモジュールとを示す概略図である。

【図４Ｂ】ベースバンド処理用カードを示す概略図である。

【図５】ベースバンド通信用スタック内の構造を示す概略図である。

【図６】ＣＶＭの共通ブロック及び構造を示す概略図である。

【図７】ＣＶＭと、ハードウェアと、スタックとの間の関係を示す概略図である。

【図８】＆

【図９】ＣＶＭを用いる開発サイクルでのステップを示す概略図である。

【用語の説明】

Software-Level Logical Architecture ソフトウェア・レベル論理的アーキテク
チャ C++ algorithms, some SDL, ASN.1 (mapped to C) also Ｃ＋＋アルゴリズム、
（Ｃ対応）何らかのＡＳＮ.１ Logical Requests + Constraints 論理要求＋制約 CVM Ops Library ＣＶＭＯｐライブラリ Algorithm Requests + Constraints アルゴリズム要求＋制約 Physical System Map 物理システム・マップ CVM Scheduler ＣＶＭスケジュラ The scheduler is a process that executes on a 'blessed' card (along wit
h the high level IP/ Iub parsing algorithms) スケジュラは（高レベルＩＰ
／Ｉｕｂ構文解析アルゴリズムを持つ）‘blessed’カード上での実行プロセス
である。 MBIR -> Queue Dispatch ＭＢＩＲ -> キュー実行指令 DSP A1I1 Q ＤＳＰＡ１Ｉ１Ｑ Deterministic physical queues maintained on a per-algorithm instance bas
is アルゴリズム毎のインスタンス・ベース上に保持される決定論的物理キュー
FPGA A2I1 Q ＦＰＧＡＡ２Ｉ１Ｑ Access to Resources, DMA, etc. 資源、ＤＭＡなどへのアクセス CVM Resource Library ＣＶＭ資源ライブラリ Execution of Resource Management 資源管理の実行指令 3rd Party RTOS サード・パーティＲＴＯＳ

【図１】 1：ソフトウェア・レベル論理的アーキテクチャ 2：Ｃ＋＋アルゴリズム、（Ｃ対応）何らかのＡＳＮ.１ 3：論理要求＋制約 4：ＣＶＭＯｐライブラリ 5：アルゴリズム要求＋制約 6：物理システム・マップ 7：ＣＶＭスケジュラ 8：スケジュラは（高レベルＩＰ／Ｉｕｂ構文解析アルゴリズムを持つ）‘bless
ed’カード上での実行プロセスである。 9：ＭＢＩＲ -> キュー実行指令 10：ＤＳＰＡ１Ｉ１Ｑ 11：アルゴリズム毎のインスタンス・ベース上に保持される決定論的物理キュー
12：ＦＰＧＡＡ２Ｉ１Ｑ 13：資源、ＤＭＡなどへのアクセス 14：ＣＶＭ資源ライブラリ 15：資源管理の実行指令 16：サード・パーティＲＴＯＳ

【図２】 1：単一カードＮＴＰＣ（ブート、モニタ） 2：ＲＡＭ 3：Ｉｕｂ／ＩＰ（＋オプションＮＴＰ） 4：周辺機器サポート 5：Ｐ−ＩＩＩ 6：ＳＤＲＡＭ 7：ＴＩＣ６４ｘ 8：ＰＬＸ９０８０ 9：Ｘｉｌｉｎｘ社製ＦＰＧＡ 10：（ｎ個の）汎用処理用カード 11：受動ＰＣＩバックプレーン、ＰＳＵ 12：ＮＢ−ＩＦカード（図示せず）

【図３】 1：ＤＡＢ 2：ＵＭＴＳ 3：ＵＷＢ 4：ＣＶＭ 5：ＭＰＧ 6：ＦＩＲ，ＩＩＲ 7：ＦＦＴ 8：ＭｅｍＭｇｔ 9：フロー制御 10：ＤＭＡ（ダイレクト・メモリ・アクセス） 11：ｘ８６ 12：ＴＩ 13：ＡＲＣ

【図４Ａ】 1：塔へのフィード 2：開放型インターフェースによってサード・パーティによるＲＦ／ａｍｐモジ
ュールの供給が可能になる 3：ＤＡＣＡＤＣ 4：高速ＩＰインターフェース 5：サード・パーティＲＦモジュール 6：ＲＴＰ／ＵＤＰ／ＩＰｖ６デジタル化ＩＦ 7：サード・パーティ・アンテナ 8：ＳＮＭＰ／ＩＰＭｇｔ報告 9：ＳＤＲＡＭ 10：ＴＩＣ６４x（ＩＦカードは汎用処理用カード設計の改良品である） 11：ＴＣＸＯ 12：ＰＬＸ９０８０ 13：Ｘｉｌｉｎｘ社製ＦＰＧＡ 14：パワー 15：オプションのＧＰＳ１ｐｐｓ 16：Ｉｕｂ／ＩＰ（＋オプションのＮＴＰ）（高速イーサネット） 17：ＲＴＰタイムスタンプ用クロック基準をセットするための分散型１ｐｐｓ

【図４Ｂ】 1：最低限のブートＰＲＯＭしかカード上にない；その場合ＰＣはＤＳＰコード
画像とＦＰＧＡヒューズマップをアップロードする 2：オプションのＧＰＳのイン 3：０×００００ 4：ＲＡＭ 5：ＦＰＧＡＩ／Ｏ 6：ＤＳＰＩ／Ｏ 7：１ｐｐｓまたはＮＴＰ調整ＴＣＸＯ用オプション・パッドアウト 8：ブートＰＲＯＭ 9：ＴＩＣ６４ｘ 10：ＳＤＲＡＭ（３２ mb） 11：オプションのパッドout 高速ＩＦＩＰｖ６インターフェース用オプション
・パッドアウト 12：ＰＬＸ９０８０ 13：Ｘｉｌｉｎｘ社製ＦＰＧＡ 14：インテリジェント・ブリッジ・チップによってＩＯのマッピングと、グルー
バルなＰＣＩメモリ・マップ上への割込みとローカル・メモリ空間とが可能にな
る。 15：直接シリアル・リンクのサポート

【図５】 1：コンテンツ生成 2：ソース符号化 3：チャネル符号化 4：変調 5：復調 6：チャネル復号化 7：ソース復号化 8：コンテンツ・プレゼンテーション用アプリケーション

【図６】 1：Ｉ／Ｏ 2：ＡＥＣ 3：ＦＦＴ 4：ＣｈａｎＰｒｏｃ 5：Ｄｅｍｏｄ 6：ＭＭＩコード 7：パイプライン段階 8：シンボル指示型処理 9：データ指示型処理

【図７】 1：スタック境界 2：Ｃ＋＋コア・コード 3：ＣＶＭＡ 4：ハードウェア＋Ｏ／ＳＡ 5：スタック境界 6：Ｃ＋＋コア・コード 7：ＣＶＭＢ 8：ハードウェア＋Ｏ／ＳＢ

【図８】 1：初期アーキテクチャ仕様書 2：数学モデリング用ツール（Ｍａｒｌａｂ） 3：グラフ記述言語（ＧＤＬ） 4：ＰＣ開発環境（ＭＳＤｅｖ．Ｓｔｕｄｉｏ，Ｔａｕ） 5：アーキテクチャから見て中立な通信スタック（Ｃ＋＋／ＳＤＬ） 6：ＲａｄｉｏＳｃａｐｅプラグ・イン拡張 7：ＲａｄｉｏＳｃａｐｅライブラリ 8：ＲａｄｉｏＳｃａｐｅターゲット内蔵ＣＶＭ環境 9：ＲａｄｉｏＳｃａｐｅＩｎｔｅｌＭＭＸ／ＳＩＭＤＣＶＭ環境 10：プラグ・イン内蔵コンパイラ 11：アーキテクチャ・レポート（ＭＩＰＳ、メモリ、ＣＣＳ） 12：ＲａｄｉｏＳｃａｐｅアーキテクチャ解析ツール 13：ＲａｄｉｏＳｃａｐｅＰＣ内ＲＦプロトタイピング用ＰＣＩボード 14：ＦＰＧＡ／ＤＳＰ処理用ボード

【図９】 1：ＣＶＭ開発サイクル 2：モデリング用ツール（Ｍａｔｌａｂ数学など） 3：パイプライン 4：プラグイン（ＲＳ） 5：ＴＢＡ 6：手で 7：定義する 8：コンポーネント定義言語 9：コンポーネントＡＰＩ 10：コンポーネントの振舞い 11：デバイス定義言語 12：適合性記述用言語 13：コンポーネント“ＡＰＩ”仕様 14：計装化 15：解釈された 16：パイプライン・マネージャ 17：実行＆ログ 18：実行 19：コンポーネント定義言語 20：ソースコード 21：パイプライン・ビルダ 22：ＶＭライブラリ 23：コンポーネント・ライブラリ 24：コンパイル 25：パイプライン 26：アーキテクチャ分析用ツール整理番号８８６

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＪＰ，ＵＳ

Claims

【特許請求の範囲】

【請求項１】ベースバンド信号処理に好適なバーチャル・マシン層を備え
て、プログラムされたデジタル無線通信基地局。
【請求項２】請求項１に記載の基地局において、上記バーチャル・マシン
層が、高水準ソフトウェアを用いて１以上のベースバンド処理用アルゴリズムを
表すことを可能にするのに適していることを特徴とする基地局。
【請求項３】請求項１に記載の基地局において、上記バーチャル・マシン
層がＰＣＩ−バス・バックプレーンを具備するハードウェア上で実行されること
を特徴とする基地局。
【請求項４】請求項１に記載の基地局において、上記バーチャル・マシン
内の上記ハードウェア・エレメントがオープンな、アーキテクチャから見てニュ
ートラルなメッセージ通信システムを用いてと交信することを特徴とする基地局
。
【請求項５】請求項４に記載の基地局において、Ｉ２０対応メッセージ通
信が使用されることを特徴とする基地局。
【請求項６】請求項１に記載の基地局において、単にソフトウェアの変更
のみによって、１つの組のベースバンド処理用アルゴリズムから別の組のアルゴ
リズムへのオペレーションの変更が可能であることを特徴とする基地局。
【請求項７】請求項６に記載の基地局において、ソフトなデータ・パスま
たはハードなデータ・パス、あるいはこれら２つのパスの組合せのいずれかで実
現され、基底を成す‘エンジン’への変更を単に行うことにより、１つの組のベ
ースバンド処理用アルゴリズムから別の組のアルゴリズムへのオペレーションの
変更が可能であることを特徴とする基地局。
【請求項８】請求項１に記載の基地局において、開放型インターフェース
であるインターフェースを介してＲＦエレメントの接続を行うことを特徴とする
基地局。
【請求項９】請求項６に記載の基地局において、上記開放型インターフェ
ースが、以下のコンポーネント、（ｉ）給電（ｉｉ）データ（ｉｉｉ）制御（ｉｖ）タイミング／同期（ｖ）状態、のうちの１以上を定義することを特徴とする基地局。
【請求項１０】請求項１に記載の基地局において、ＩＰベースのデジタル
ＩＦフィードを無線塔へ送ることを特徴とする基地局。
【請求項１１】請求項１０に記載の基地局において、上記ＩＰフィードが
複数のＲＦユニットまで送出されることを特徴とする基地局。
【請求項１２】請求項１に記載の基地局において、上記無線塔で受信した
信号から得られるＩＰフィードが複数のプロセッサ・ボードへ受け渡されること
を特徴とする基地局。
【請求項１３】請求項１に記載の基地局において、複数の並列処理ノード
を利用して調整可能な処理を可能にするようにプログラムされたスケジュラを具
備することを特徴とする基地局。
【請求項１４】請求項１３に記載の基地局において、上記スケジュラがＩ
２０ベースの資源自己発見機能を利用して、或る最適な方法で上記スケジュラが
当該資源を利用できるようにすることを特徴とする基地局。
【請求項１５】請求項１３に記載の基地局において、上記スケジュラが、
序列的分画用ファイルを読み出して、どのデータ・パスがどの処理ユニットを実
行すべきかに関するスケジュラの決定に役立てることを特徴とする基地局。
【請求項１６】請求項１に記載の基地局において、複数の規格を同時に実
行するように作動可能であることを特徴とする基地局。
【請求項１７】請求項１に記載の基地局において、上記バーチャル・マシ
ン層が、いくつかの異るベースバンド処理用アルゴリズムに共通の基底を成す高
ＭＩＰＳアルゴリズムをサポートし、さらに、スケジュラ・インターフェースを
介して、高水準の、アーキテクチャから見て中立な潜在的に高度の複雑さを持ち
ながら、しかも低ＭＩＰＳの制御フローに上記アルゴリズムがアクセスすること
を可能にするソフトウェアにおいて、上記スケジュラ・インターフェースは、（
ｉ）ランタイム、（ｉｉ）メモリ、（ｉｉｉ）起呼者が実行命令の実行を望む帯
域のいずれかあるいはすべての内側に在る相互接続帯域、のうちの１以上に関連
する１組の資源制約包絡線と共に、上記制御フローが実行すべきアルゴリズムを
指定することを特徴とする基地局。
【請求項１８】請求項１に記載の基地局において、上記バーチャル・マシ
ン層が、１以上のＤＳＰアーキテクチャ、１以上のＦＰＧＡアーキテクチャ及び
／又は１以上のＡＳＩＣアーキテクチャへ移植可能となるように設計されたソフ
トウェアであることを特徴とする基地局。
【請求項１９】請求項１に記載の基地局において、上記バーチャル・マシ
ン層が様々なコア処理及び／又はコア構造及び／又はコア機能及び／又はフロー
制御及び／又は状態管理を用いてプログラムされたソフトウェアであることを特
徴とする基地局。
【請求項２０】請求項１９に記載の基地局において、上記コア処理が、１
以上の以下のステップ、すなわちソース符号化ステップと、チャネル符号化ステ
ップと、変調ステップ、または、それらの逆のステップ、すなわちソース復号化
ステップと、チャネル復号化ステップと、復調ステップとを実行するアルゴリズ
ムを含むことを特徴とする基地局。
【請求項２１】請求項１９または２０に記載の基地局において、上記コア
構造が（当該シンボルの範囲内に保持されているすべての情報が利用できるか否
かにかかわらず、フル・シンボル処理と関係する）シンボル処理部と、関連情報
を保持する当該ビットのみを処理するデータ指向型処理部とを有することを特徴
とする基地局。
【請求項２２】請求項２１に記載の基地局において、シンボル・レート処
理がＣＤＭＡシステム内でのチップ・レート処理を含むことを特徴とする基地局
。
【請求項２３】請求項２１に記載の基地局において、上記コア構造が、中
間の整合メモリ・バッファの割当て、共有、配置を行うように作動可能な処理用
モジュールから構成され、さらに、該モジュール間でイベントを渡すようにする
ことを特徴とする基地局。
【請求項２４】請求項１９に記載の基地局において、上記コア機能が、１
以上の以下のステップ、すなわち、メモリ割当てと、リアルタイム資源割当てと
、同時性管理とを含む資源割当てステップと、スケジューリング・ステップとを
含むことを特徴とする基地局。
【請求項２５】請求項１９に先行するいずれの請求項にも記載の基地局に
おいて、ＰＣ用デバッグ・ツールにアクセスするように作動可能であることを特
徴とする基地局。
【請求項２６】請求項１９に先行するいずれの請求項にも記載の基地局に
おいて、上記コンポーネントのパフォーマンスを用いるソフトウェアの動作及び
／又は上記コンポーネントのパフォーマンスの別様のモデル化を可能にするため
に必要な当該情報だけが、上記コンポーネント内の知的財産の所有者により供給
されるように成されるコンポーネントを用いて機能できることを特徴とする基地
局。
【請求項２７】請求項１９に先行するいずれの請求項にも記載の基地局に
おいて、非対称アクセス・アーキテクチャでこのようなコンポーネントが分配さ
れるする場合であっても、また、上記基底を成すデータ・ストリームの固有の‘
群発性’、あるいは、それ自身のＱｏＳ及び発生-消滅（birth-death）タイミン
グを持つ複数のストリームの各々の利用のようなファクタに起因して、上記コン
ポーネントの利用パターンを決定論的ではなく単に統計的にモデル化することし
かできない場合であっても、シミュレータ、エミュレータあるいはモデリング用
ツールが、通信用コンポーネントを用いてシステムの上記資源要件の正確な評価
を可能にする当該通用コンポーネントの（インターフェースの振舞い及び非イン
ターフェースの振舞いを含む）特性に関する標準化された記述を用いて作動可能
であることを特徴とする基地局。
【請求項２８】請求項１９に記載の基地局において、時間、ＣＰＵ、メモ
リ、スケジューリング及び同時性制限をモデル化するように作動可能で、リアル
タイムＯＳ、非リアルタイムＯＳ、バーチャル・マシンあるいはハードウェア上
へのマッピング可能にすることを特徴とする基地局。
【請求項２９】請求項１乃至２８のいずれかに確定されるような基地局の
ベースバンド・スタックをことを特徴とするベースバンド・スタック。
【請求項３０】請求項２９に記載のベースバンド・スタックにおいて、複
数の標準的接続タイプと、データ自身が上記パイプラインの管理の決定を可能に
するような同期方法とを用いて、実際のまたは模擬のコンポーネントがパイプラ
インの中一体的に一緒にリンクされることを特徴とするベースバンド・スタック
。
【請求項３１】請求項２９または３０のベースバンド・スタックをシミュ
レートするための設計用ツールにおいて、複数の標準的接続タイプと、上記デー
タ・フローにより処理されたデータによって上記パイプラインの管理の決定を可
能にする同期方法とを用いて、ソフトウェア・コンポーネントとハードウェア・
コンポーネントとを一体的にリンクすることが可能であることを特徴とする設計
用ツール。
【請求項３２】請求項３１に記載の設計用ツールにおいて、高レベル・フ
ローの中の少なくとも若干がＣや、Ｃ＋＋などのような手続型言語で指定される
ことを特徴とする設計用ツール。
【請求項３３】請求項３１に記載の設計用ツールにおいて、高レベル・フ
ローの中の少なくとも若干がＳＤＬなどのような状態マシーン言語で指定される
ことを特徴とする設計用ツール。
【請求項３４】デジタル無線基地局デバイスの一部またはすべてを設計す
る方法において、ベースバンド信号処理にとって適切なバーチャル・マシン層を
用いてプログラムされたソフトウェアを使用するステップを有することを特徴と
する方法。
【請求項３５】デジタル無線基地局に適したコンピュータ・ソフトウェア
において、ハードウェア抽象化層として機能し、さらに、１以上のベースバンド
処理用アルゴリズムを高水準ソフトウェアを用いて表すことを可能にすることを
特徴とするソフトウェア。
【請求項３６】請求項３５に記載のコンピュータ・ソフトウェアにおいて
、上記基地局が、請求項１乃至２８に記載のような基地局であることを特徴とす
るコンピュータ・ソフトウェア。
【請求項３７】請求項３５乃至３６のコンピュータ・ソフトウェアを用い
てプログラムされることを特徴とするコンピュータ・ハードウェア。
【請求項３８】デジタル無線基地局との接続に適したＲＦエレメントにお
いて、上記基地局が請求項１乃至２８のいずれかに記載のような基地局であるこ
とを特徴とするＲＦエレメント。