下記を具備する装置:少なくとも1つのサービスメッセージを発生するための制御モジュール;マルチプレクッスメッセージを発生するためのマルチプレックスモジュール、前記マルチプレクッスメッセージは下記を具備する:前記少なくとも1つのサービスメッセージ;前記少なくとも1つのサービスメッセージに関連する少なくとも1つの制御ポイントを識別するためのクライアントIDフィールド;前記少なくとも1つのサービスメッセージに関連するサービスエンティティを識別するためのサービスタイプフィールド。前記クライアントIDフィールドは、前記少なくとも1つのサービスメッセージに関連するすべての制御ポイントを識別する、請求項1の装置。前記クライアントIDフィールドは、前記少なくとも1つのサービスメッセージに関連するすべての制御ポイントを識別するために特定の値に設定される、請求項1の装置。前記制御モジュールは前記装置上の第1の制御ポイントである、請求項1の装置。前記少なくとも1つのサービスメッセージは要求メッセージを備え、前記マルチプレックスメッセージはさらに、前記マルチプレックスメッセージが要求メッセージを備えることを識別するためのメッセージタイプフィールドを備える、請求項4の装置。前記装置上に複数の制御ポイントをさらに備え、各制御ポイントは、少なくとも1つのサービスメッセージを発生するように構成可能である、請求項4の装置。前記制御モジュールは前記装置上の第1のサービスエンティティである、請求項1の装置。前記装置上に複数のサービスエンティティをさらに備え、各サービスエンティティは、少なくとも1つのサービスメッセージを発生するように構成可能である、請求項7の装置。前記少なくとも1つのサービスメッセージは応答メッセージを備え、前記マルチプレックスメッセージは、前記マルチプレクッスメッセージが応答メッセージを備えることを識別するためのメッセージタイプフィールドをさらに備える、請求項7の装置。前記少なくとも1つのサービスメッセージは、表示メッセージを備え、前記マルチプレックスメッセージは、前記マルチプレクッスメッセージが表示メッセージを備えることを識別するメッセージタイプフィールドをさらに備える、請求項7の装置。前記マルチプレックスモジュールはさらに、少なくとも1つの受信されたサービスメッセージと、前記少なくとも1つの受信されたサービスメッセージに関連する制御ポイントを識別するクライアントIDを記憶するクライアントIDフィールドと、前記少なくとも1つの受信されたサービスメッセージに関連するサービスエンティティを識別するサービスタイプを記憶するサービスタイプフィールドとを備えたマルチプレックスメッセージを受信するためにさらに構成可能であり、前記制御モジュールは、前記マルチプレクッスモジュールから前記少なくとも1つの受信されたサービスメッセージを受信するためにさらに構成可能である、請求項1の装置。前記制御モジュールはサービスエンティティである、請求項11の装置。前記サービスエンティティは、前記マルチプレックスモジュールから複数の受信されたサービスメッセージを受信する前記サービスエンティティに応答して複数のサービスメッセージを発生するようにさらに構成可能であり、前記マルチプレックスモジュールは前記発生された複数のサービスメッセージを備えたマルチプレックスメッセージを発生するようにさらに構成可能である、請求項12の装置。前記複数の受信されたサービスメッセージに応答して発生された前記複数のサービスメッセージは、前記複数の受信されたサービスメッセージのシーケンスに従って順序付けられる、請求項13の装置。前記サービスエンティティは、認識されない受信されたサービスメッセージを受信することに応答してエラーサービスメッセージを発生するように構成可能である、請求項14の装置。前記サービスエンティティは、複数の制御ポイントの中の衝突を解決するための共有状態変数を維持するように構成可能である、請求項12の装置。前記サービスエンティティは、複数の制御ポイントの各1つのための一意的な状態変数を維持するように構成可能である、請求項12の装置。前記制御モジュールは制御ポイントである、請求項11の装置。前記装置は、第2の装置マルチプレックスメッセージを発生するように動作可能な第2の装置にさらに接続され、前記第2の装置は:少なくとも1つの第2の装置サービスメッセージを発生するためのサービスエンティティと;下記を具備する第2の装置マルチプレクッスメッセージを発生するための第2の装置マルチプレックスモジュールと:前記サービスエンティティにより発生された前記少なくとも1つの第2の装置サービスメッセージと;前記サービスエンティティにより発生された前記少なくとも1つの第2の装置サービスメッセージに関連する制御ポイントを識別するためのクライアントIDフィールドと;前記サービスエンティティにより発生された前記少なくとも1つの第2の装置サービスメッセージに関連するサービスエンティティを識別するためのサービスタイプフィールドと;を備えた請求項18の装置。前記第2の装置はデータ通信装置である、請求項19の装置。前記データ通信装置は、無線エアーインターフェースを介して通信するように動作可能である、請求項20の装置。前記サービスエンティティは装置管理サービスエンティティである、請求項19の装置。前記サービスエンティティは無線データサービスエンティティである、請求項19の装置。前記サービスエンティティはネットワークアクセスサービスエンティティである、請求項19の装置。前記サービスエンティティはロケーションベースサービスエンティティである、請求項19の装置。前記制御モジュールは前記クライアントIDに関連する制御ポイントである、請求項11の装置。前記少なくとも1つのサービスメッセージの各々は、下記を具備する請求項11の装置:前記サービスメッセージを識別するためのメッセージIDフィールド;前記サービスメッセージの一部の長さを指定するためのメッセージレングスフィールド;メッセージ値フィールド。前記少なくとも1つのサービスメッセージの前記少なくとも1つの前記メッセージ値フィールドは、下記を具備する第1タイプレングス値TLVフィールドを備えた請求項27の装置:前記第1のTLVのタイプを識別するための第1のTLVタイプフィールド;前記第1のTLVタイプに関連する値を指定するための第1のTLV値フィールド;前記第1のTLV値フィールドのレングスを指定するための第1のTLVレングスフィールド。前記第1のTLVは、前記少なくとも1つのサービスメッセージの前記少なくとも1つのための必須のTLVである、請求項28の装置。前記第1のTLV値フィールドは複数の値フィールドを備える、請求項29の装置。前記少なくとも1つのサービスメッセージの少なくとも1つの前記メッセージ値フィールドはさらなるTLVをさらに備える、請求項28の装置。前記さらなるTLVはオプションTLVを備える、請求項31の装置。前記オプションTLVは、前記少なくとも1つのサービスメッセージの前記少なくとも1つを暗号化するための少なくとも1つの暗号化パラメーターを備える、請求項32の装置。前記オプションTLVは、前記少なくとも1つのサービスメッセージの前記少なくとも1つを認証するための少なくとも1つの認証パラメーターを備える、請求項32の装置。前記オプションTLVは前記少なくとも1つのサービスメッセージの前記少なくとも1つのインテグリティを検証するための少なくとも1つのインテグリティプロテクションパラメーターを備える、請求項32の装置。前記制御モジュールは、前記制御モジュールによりサポートされるよりもより高い比較的重要でないサービスバージョンを有する受信されたサービスメッセージを受信することに応答して、前記受信されたサービスメッセージ内の認識されないオプションTLVをスキップするように構成可能である、請求項11の装置。前記制御モジュールは、前記制御モジュールによりサポートされるよりもより高い比較的重要でないサービスバージョンを有する受信されたサービスメッセージを受信することに応答して、前記受信されたサービスメッセージを無視するように構成可能である、請求項11の装置。前記制御モジュールは、前記制御モジュールによりサポートされるよりもより低い比較的重要でないサービスバージョンを有する受信されたサービスメッセージを受信することに応答して、前記受信されたサービスメッセージと同じかまたは低いサービスバージョンを有するサービスメッセージのみを発生するように構成可能である、請求項11の装置。前記制御モジュールは認識されない受信されたサービスメッセージに応答して前記受信されたサービスメッセージをリジェクトするように構成可能である、請求項11の装置。前記制御モジュールは、認識されない受信サービスメッセージに応答して、前記受信されたサービスメッセージを無視するように構成可能である、請求項11の装置。前記マルチプレックスメッセージは、前記マルチプレクッスメッセージに関連するトランザクションIDを記憶するためのトランザクションIDフィールドをさらに備える、請求項1の装置。データチャネルを提供するための論理装置ドライバーと、前記マルチプレックスメッセージのための制御チャネルであって前記データチャネルとは独立した制御チャネルをさらに備えた、請求項1の装置。前記制御チャネルは、ATコマンドを発生するように構成可能であり、前記論理装置の前記制御チャネルは、前記制御モジュールにより発生された前記ATコマンドをトランスポートするように構成可能である、請求項42の装置。前記論理装置ドライバーはユニバーサルシリアルバスUSBで動作するように構成可能である、請求項42の装置。前記第1の制御ポイントのための割り当てられたクライアントIDを受信するCTLモジュールをさらに具備し、前記CTLモジュールは前記マルチプレックスモジュールのためのサービスメッセージを発生するように構成可能である、請求項4の装置。前記CTLモジュールはサービスエンティティのサービスメッセージバージョンを得るようにさらに動作可能である、請求項45の装置。前記装置はパーソナルコンピューターである、請求項1の装置。前記マルチプレックスメッセージはさらに前記制御モジュールが制御ポイントかまたはサービスエンティティかを示す制御フラッグフィールドをさらに備える、請求項1の装置。前記装置は、前記制御モジュールにより発生されたサービスメッセージを備えた非マルチプレックスメッセージを発生するようにさらに動作可能である、請求項1の装置。前記サービスメッセージはATコマンドメッセージを備える、請求項49の装置。下記を具備する装置:少なくとも1つのサービスメッセージを発生するための制御手段;共通チャネルを介して前記複数の制御モジュールにより発生された前記サービスメッセージを多重化するマルチプレックス手段。複数のサービスメッセージを受信し、前記受信されたサービスメッセージを前記複数の制御モジュールの関連するモジュールに配信するデマルチプレックス手段をさらに具備する、請求項51の装置。前記装置は、さらに少なくとも1つの制御モジュールを備えた第2の装置と、複数の制御モジュールにより発生されたサービスメッセージを多重化するマルチプレックス手段と、複数のサービスメッセージを受信し、前記受信したサービスメッセージを前記複数の制御モジュールの関連したモジュールに配信するデマルチプレックス手段とにさらに接続する、請求項52の装置。クライアントIDを前記複数の制御モジュールの1つに割り当てるCTL手段をさらに備えた、請求項51の装置。前記制御モジュールは、前記デマルチプレックス手段から異なるバージョンのサービスメッセージを受信することに応答して、サービスメッセージを発生するサービスバージョン差処理手段をさらに具備する、請求項52の装置。前記制御モジュールは制御ポイントである、請求項51の装置。前記制御モジュールはサービスエンティティである、請求項51の装置。複数の装置をインターフェースするための方法において、前記方法は下記を具備する:少なくとも1つのサービスメッセージを供給する;下記を具備するマルチプレックスメッセージを発生する;前記少なくとも1つのメッセージ;前記少なくとも1つのサービスメッセージに関連する制御ポイントを識別するためのクライアントIDフィールド;前記少なくとも1つのサービスメッセージに関連するサービスエンティティを識別するためのサービスタイプフィールド。前記マルチプレックスメッセージは、前記少なくとも1つのサービスメッセージのメッセージタイプを識別するためのメッセージタイプフィールドをさらに具備する、請求項58の方法。前記メッセージタイプは要求メッセージタイプである、請求項59の方法。受信されたマルチプレックスメッセージを逆多重化することをさらに具備し、前記受信されたマルチプレックスメッセージは下記を具備する、請求項58の方法:少なくとも1つの受信されたサービスメッセージ;前記少なくとも1つの受信されたサービスメッセージに関連する制御ポイントを識別するためのクライアントIDを記憶するためのクライアントIDフィールド;前記少なくとも1つの受信されたサービスメッセージに関連するサービスエンティティを識別するためのサービスタイプを記憶するサービスタイプフィールド。複数の逆多重化された要求サービスメッセージの各々に対して、関連した応答サービスメッセージを供給することをさらに具備する、請求項61の方法。対応する要求サービスメッセージが受信された順番に各応答サービスメッセージを多重化することをさらに具備する、請求項62の方法。認識されない受信された要求サービスメッセージに関連するエラー応答サービスメッセージを発生することをさらに具備する、請求項63の方法。前記マルチプレックスメッセージは、前記マルチプレックスメッセージに関連するトランザクションIDを記憶するトランザクションIDフィールドをさらに具備する、請求項61の方法。マルチプレックスメッセージが発生されるごとに前記トランザクションIDをインクリメントすることをさらに具備する、請求項65の方法。前記マルチプレクッスメッセージのための独立制御チャネル、および独立データチャネルを供給することをさらに具備する、請求項58の方法。ATコマンドを発生し、前記ATコマンドを前記独立制御チャネルを介してトランスポートすることをさらに具備する、請求項67の方法。認識されない受信されたサービスメッセージをスキップすることをさらに具備する、請求項61の方法。前記スキップすることは、認識されないサービスメッセージを受信することに応答する、請求項69の方法。前記少なくとも1つの受信されたサービスメッセージのバージョンと同じまたは低いサービスバージョンを有するサービスメッセージのみを発生することをさらに具備する、請求項58の方法。前記少なくとも1つのサービスメッセージの少なくとも1つは下記を具備する、請求項69の方法:前記サービスメッセージを識別するためのメッセージIDフィールド;前記サービスメッセージの一部の長さを指定するためのメッセージレングスフィールド;メッセージ値フィールド。現代のTE’sおよびDCD’sの特徴は、従来技術において容易に見出しえないあるクライアント-サービスインターフェース特徴の増大した必要性をもたらした。例えば、アプリケーションクライアントソフトウエアの実施を容易にするために、データ通信装置により使用される特定の技術と独立したクライアント-サービスインターフェースに対して定義された一連のサービスコマンドを持つことは望ましいであろう。さらに、制御の柔軟性のために、同時のデータおよび制御のセッションをサポートすることができる計算装置とデータ通信装置との間に通信チャネルを持つことが望ましいであろう。さらに、単一または複数の通信装置上で動作する複数のサービスと通信する単一または複数の計算装置上の複数のクライアントを同時にサポートすることができる多重化プロトコルを持つことが望ましいであろう。図1は端末装置TE118上のアプリケーションクライアントとデータ通信装置DCD119上で動作するサービスエンティティとの間の通信のために採用することができる階層化メッセージングアーキテクチャを示す。一実施形態において、データ通信装置は多数の特定用途向け集積回路ASICsを備えたモデムであってもよい。端末装置は、DCD119上で動作するサービスエンティティ114、115と通信するソフトウエアまたはハードウエアアプリケーションクライアントまたは制御ポイント101、102、103として知られるデバイスドライバーをサポートしてもよい。アプリケーションクライアントの例は、コネクションマネージャー、ボイスオーバーIPアプリケーション、または通信デバイスドライバーを含む。サービスエンティティの例は、無線リンクを介してデータを送信および受信する無線データサービスエンティティ、ネットワークシステムステータスをアクセスするためのネットワークアクセスサービスエンティティ、およびデバイス識別およびデバイス電力レベルステータスをアクセスするためのデバイス管理サービスエンティティを含む。また、この明細書とクレームにおいて、アプリケーションクライアントおよびサービスエンティティは集合的に制御モジュールと呼んでもよい。図1に示すように、サービスインターフェース107、108、109を介して制御ポイント101、102、103とサービスエンティティ114、115との間に送信されたピアツーピアメッセージは、一般にサービスインターフェースメッセージまたはサービスメッセージと呼ぶことができる。各サービスエンティティはサポートされた一連のサービスメッセージとサービスメッセージフォーマットを定義する。一実施形態において、サービスインターフェースメッセージのフォーマットは、この明細書において後に記載される一般化サービステンプレートに従って指定されてもよい。そのようなテンプレートは単一の統合されたインターフェースを用いてDCDによりサポートされる種々のサービスをアプリケーションクライアントが制御可能にする。一実施形態において、サービスメッセージは、論理制御チャネルを介して制御ポイントとサービスエンティティとの間の上位層のアプリケーションプログラムインターフェースAPIをカプセル化する制御メッセージであってもよい。そのようなAPIメッセージは各アプリケーションクライアントに対して特有であってもよい。一実施形態において、サービスインターフェースメッセージは、APIメッセージをカプセル化する必要はなく、各特定のサービスエンティティに対して別々に定義することができる。特別のCTL制御エンティティ104およびCTLサービス113は、クライアントIDをネゴシエートすることおよびTEおよび/またはDCDのサービスメッセージバージョンを取得することのような機能のために端末装置118およびDCD119上のクライアントまたはドライバーにより使用されてもよい。端末装置118上において、CTL制御104はドライバーの一部としてまたは別個のエンティティとして実施されてもよいことに留意する必要がある。図2はサービスエンティティの使用を要求する個々の制御ポイントにDCDがクライアントIDを割り当てるための手続を記載する。ドライバーは最初にブロック201においてクライアントIDのための要求をDCDに送信する。ブロック202において利用可能な未使用のクライアントIDがあるなら、要求されたサービスエンティティのためのハンドラーは、ブロック203においてクライアントIDを制御ポイントに割り当ててもよい。制御ポイントはドライバー、カーネルモジュール、ライブラリ、またはユーザーアプリケーション内で実施されてもよい。一実施形態において、各ドライバーに1つの制御ポイントがあり各アプリケーションにおいて1つ以上の制御ポイントがある。同じタイプのサービスを使用する複数のドライバーがあるなら、各ドライバーは専用の物理相互接続チャネル、例えば専用USBチャネルを介して自身にそのクライアントID割り当てを送信することができる。利用可能なクライアントIDが無いなら、ハンドラーは、ブロック204においてすべてのクライアントIDがサービスエンティティのために使い果たされたというメッセージをドライバーに送信してもよい。ドライバーがもはやサービスエンティティと通信する必要が無いなら、ドライバーは、リリースクライアントID要求を送信することによりクライアントIDをリリースすることができることに留意する必要がある。再び図1を参照すると、サービスインターフェース107、108、109を介して送信されたサービスメッセージは、TE上のMUXモジュール105およびDCD上のMUXモジュール116により実施されるように、MUX層を介してトランスポートのためにさらにカプセル化されてもよい。MUX層MUXは、ユニバーサルシリアルバスUSBのような単一の物理相互接続を介してサービスインターフェースメッセージの多重化を可能にする。また、MUXは特定のメッセージを送信したエンティティタイプ例えば、サービスまたは制御を識別してもよい。また、各サービスエンティティに対して、MUXはクライアントIDフィールドを指定することにより複数の制御ポイントをサポートしてもよく、従って、複数のクライアントが単一のサービスエンティティを利用することを可能にする。複数のクライアントを同時にサポートする能力は、サービスが、各制御ポイントに対して別個の通信経路を割り当てることを可能にすることに留意する必要がある。これは、例えば、制御ポイントが認証信任状をサービスエンティティと別個に交換することを可能とし、これにより、サービスがオーソライズされたクライアントに対してのみアクセスすることを可能とし、逆もまた同様である。さらに、サービスは、完全性保護および機密性保護のために各制御ポイントと暗号鍵をネゴシエートすることができる。リソースマネージメントの場合、サービスはまた同時にサービスをアクセスするクライアントの数を追跡し制限することができる。また、サービスは、各クライアントのためのクライアント特定状態情報を追跡し並びに複数のクライアントから受信した要求を調停することができる。上述した特徴の列挙は、複数の同時クライアントをサポートするこの発明の一実施形態の利点のいくつかを例証するように意図されているにすぎないことに留意する必要がある。特徴の列挙は、そのような特徴を有する実施形態のみにこの発明の範囲を限定することを意図していない。MUXメッセージは、デバイス層モジュール106および117により実施されるデバイス層を介したトランスポートのためにさらに処理されてもよい。デバイス層は、USB、RS-232、PCI、およびPCMCIAのような物理相互接続を介してまたはブルートゥース、IEEE802.11および共有メモリインターフェースのような無線リンクを介してデバイスインターフェース112を駆動する、機能ドライバー図示せず、論理デバイス図示せず、およびバスドライバー図示せずのようなモジュールを含んでいてもよい。一実施形態において、各論理デバイスはまたサービスエンティティと通信するための独立したデータチャネル図示せずを備えていてもよい。独立したデータチャネルは、制御チャネルと同時に動作することができる。例えば、データチャネルおよび制御チャネル並びに独立したフロー制御機構および独立したデータ送信スケジュールに対して別個の送信および受信経路キューイングが提供されてもよい。一実施形態において、ユニバーサルシリアルバスUSBインターフェース上のさらなるエンドポイントペアを利用して別個のデータチャネルおよび制御チャネルが実施される。データチャネルは、IEEE802.3イーサネット登録商標データリンク層プロトコルのような標準データリンク層プロトコルを採用することができる。データチャネルのためのリンク層フレーミングは物理相互接続ドライバー、例えばUSBドライバー内で実施されてもよい。パケットの終端はゼロレングスUSBフレームにより区切られる。一実施形態において、物理層例えば、USBがそのようなIPパケットのフレーミングおよび境界検出をサポートすることができるなら、インターネットプロトコルIPパケットはデータチャネルを介して直接送信することができる。特に、物理層フレームサイズは、IPパケット全体を含むように十分な長さでなければならない。一方物理層ドライバーは、正確に1IPパケットを含むようにフレーム境界をマークすることができなければならない。図6は、別個のデータチャネルおよび制御チャネルを介してDCD630と通信する端末装置600の一実施形態を示す。アプリケーション1に関連する制御ポイント601、アプリケーション2に関連する制御ポイント602、アプリケーション3に関連する制御ポイント603、アプリケーション4に関連する制御ポイント604は、サービスメッセージ612、613、614を発生し受信しているように図示されている。サービスメッセージ612、613、614は、論理装置618、619へ/から渡される。論理装置618は別個のデータチャネル621および制御チャネル624を提供し、論理装置619は別個のデータチャネル622および制御チャネル625を提供する。DCD630上で、対応する機能ヒエラルキーが実施されてもよい。例えば、各々が別個のデータチャネルおよび制御チャネルを駆動するための論理装置641、642、サービスエンティティ660、661、662と通信するためのサービスメッセージング650、651、652が実施されてもよい。また、端末装置600は、対応する論理装置620、データチャネル623、および制御チャネル626と共に、カスタムAPI/サービスフレームワークを介してサービスメッセージを発生し受信するアプリケーション605、606を含んでいてもよい。そのようなカスタムアプリケーションは、制御ポイント601、602、603、604と同じ物理相互接続層を共有してもよいし、またはカスタムアプリケーションは別個の物理相互接続を備えることができる。また、DCD630上には、対応する論理装置643と共にカスタムAPI/サービスフレームワーク653が、サービスエンティティ663、664と通信するために設けられてもよい。論理装置618、619、620は各々この実施形態において、別個のデータチャネルおよび制御チャネルをサポートするように示されているけれども、他の実施形態において、論理装置は、データと制御の両方をトランスポートするために単一のチャネルのみをサポートしてもよいことに留意する必要がある。一実施形態において、DCDは、カリフォルニア州、サンディエゴのQualcommIncから入手可能なモバイルステーションモデムMSMチップセットであり得、端末装置は、パーソナルコンピューターPC、ノートブックコンピューター、パーソナルデジタルアシスタントPDA、またはスマートフォンのような装置であり得る。図1および図6に示す実施形態は、例証に過ぎず、この発明の範囲を限定することを意図していない。例えば、通信の終端はDCDおよび端末装置である必要はない。むしろ、ハードウエアまたはソフトウエア内で動作するアプリケーションとサービスとの間の任意の通信はこの発明の技術を採用してもよい。例えば、USBケーブルを介してMP3プレーヤーに接続されたパーソナルコンピューター、または、任意の標準のプロセス間通信IPC機構を介して通信する、異なるプロセッサー上の同じ装置で動作する制御ポイントおよびサービスさえも採用してもよい。さらに、図1および6に明示的に示されるメッセージングプロトコル層を超えるさらなるメッセージングプロトコル層が存在してもよい。例えば、MUX層と装置層との間にさらなるトランスポート層が存在してもよい。上に示したアーキテクチャを容易にするためのメッセージングプロトコルについて記載する。図1を再び参照すると、端末装置118上で動作しているアプリケーションを表す制御ポイント101は、サービスメッセージを用いてサービスインターフェース107を介してDCD119上で動作するサービスエンティティ115と通信することができる。一実施形態において、サービスメッセージは3つのタイプの1つであり得る。要求メッセージ、応答メッセージおよび表示メッセージ。特定のメッセージのタイプは、メッセージと一緒に送信される対応するフィールドで示すことができる。要求メッセージは制御ポイントにより発行され、サービスエンティティにおけるパラメーター値、サービスエンティティからの問い合わせパラメーター値を設定してもよく、または、サービスエンティティにより表示メッセージの発生を構成してもよい。有効な要求は、一般的にサービスエンティティから対応する応答を引き出すであろう。制御ポイントは、新しい要求を送信する前に以前に送信した要求に対する応答を待つ必要は無い。これは、クライアントとサービスとの間の非同期動作を可能にする。応答メッセージは、受信された要求メッセージに応答してサービスエンティティにより発行される。応答は、要求された動作に応じて、成功、失敗、またはエラーステータスを示す結果コードを含んでいてもよい。要求に関連した他のデータを通信するために応答内にさらなるフィールドが存在していてもよい。表示メッセージは、要求に応答してまたは制御ポイントによる任意の教唆なしにサービスエンティティにより発行されてもよい。表示はすべての制御ポイントにブロードキャストしてもよいしまたは特定の制御ポイントにユニキャストしてもよい。ブロードキャスト表示は、その状態について並びに任意の関連するユーザーインターフェースの状態について制御ポイントを更新するために、例えばサービスエンティティにより使用されてもよい。他方、ユニキャスト表示は、特に目標とされる制御ポイントに配信されてもよい。ユニキャスト表示を発行するためにイベントがサービスを生じると、サービスは、メッセージ定義内の表示に関連する任意の要求をチェックしてもよく、関連する要求を発行した各制御ポイントにユニキャスト表示を送ってもよい。ユニキャスト表示が関連した要求を有さないなら、サービスはそれにもかかわらず、ユニキャスト表示、例えばクライアントIDを無効にするためのメッセージを適切な制御ポイントに発行してもよい。一実施形態において、制御ポイントは、制御ポイントが受信する任意のサポートされていない表示を無視してもよい。メッセージングプロトコルの1つの観点によれば、単一のクライアントから単一のサービスエンティティへのいくつかのサービスメッセージは、通信リンクを効率的に使用するために1つの送信に一緒に束ねてもよい。束ねられた送信はペイロードの形態であってもよい。これはまた、束ねられた送信に関連した他の制御パラメーターを運んでもよい。一実施形態において、いくつかのサービスメッセージが論理的にユニット、例えば単一のAPIコマンドを実施するのに必要なメッセージのセットまたは周期的に発行されたステータス問い合わせ要求のセットを形成するなら、それらは一緒に束ねられてもよい。一実施形態において、ペイロードは、例えば、メッセージが要求メッセージ、応答メッセージ、または表示メッセージであろうとなかろうと、束ねられたサービスメッセージのメッセージタイプを特定するフィールドを備えていてもよい。他の実施形態において、ペイロードはまた制御ポイントにより発行された各ペイロードに一意的に関連することができるトランザクションIDフィールドを指定してもよい。その後、サービスエンティティは同じトランザクションIDを要求メッセージに関連する応答メッセージに付加することができる。一実施形態において、制御ポイントは新しい要求メッセージが送信されるたびにトランザクションIDをインクリメントする。一実施形態において、サービスエンティティは束ねられた要求メッセージ内の各要求を処理し、束ねられた要求に受信されたのと同じ順番で単一の束ねられた応答メッセージにすべての対応する応答を戻す。認識されていない要求がバンドルに含まれているなら、サービスエンティティは要求に応答して送信されたバンドルにエラーメッセージを含んでいてもよい。束ねられた要求内の要求の長さが不正確に受信されるなら、サービスエンティティは、束ねられた応答内に、認識されていない受信された要求を示す単一のエラーメッセージ応答で束ねられた、間違いを含む要求に先行する任意の成功裏に処理された要求に対するすべての応答を含んでいてもよい。最後に、サービスメッセージが正しく受信されるが、サービスメッセージ内のパラメーターが間違いを含むなら、一般的なエラーメッセージまたはサービスメッセージに特有のエラーメッセージを戻してもよい。メッセージングプロトコルの多重化観点において、異なるサービスエンティティを対象にした異なる制御ポイントからのペイロード、逆もまた同様は、マルチプレックスメッセージを形成するために、各ペイロードに、関連するクライアントIDフィールドおよびサービスタイプフィールドを添付することにより同じ物理相互接続を介して送信することができる。例えば、図1において、サービスインターフェース107を介して制御ポイント101とサービスエンティティ115との間に送信された束ねられたサービスメッセージは、1に設定されたクライアントIDと2に設定されたサービスタイプを有していてもよい。同様に、サービスインターフェース108を介して制御ポイント102とサービスエンティティ114との間に送信されたペイロードは、1に設定されたクライアントIDと1に設定されたサービスタイプを有していてもよく、一方、サービスインターフェース108を介して制御ポイント103とサービスエンティティ114との間に送信されたペイロードは、2に設定されたクライアントIDと1に設定されたサービスタイプセットを有していてもよい。このように、すべてのサービスメッセージは、同じMUX層を介して送信されてもよい。特に留意する点は、メッセージングプロトコルのこの観点は、各制御ポイントにユニークなクライアントIDを割り当てることにより単一のサービスエンティティと、複数の制御ポイントが通信することを可能にする点である。一実施形態において、制御フィールドはまた、メッセージの発生源が制御ポイントかまたはサービスエンティティかどうかを示す制御フィールドをペイロードに付加してもよい。これは、サービスと制御ポイントが端末装置とDCDの両方に互換的に位置することを可能にする。クライアントIDフィールド、サービスタイプフィールドおよび制御フラッグフィールドのいずれかまたはすべてはプリアンブルまたはポストアンプルとしてペイロードに付加してもよく、または、それらはそのようなロケーションが特定のメッセージに従ってあらかじめ定義されている限り、ペイロード内のどこかに位置していてもよい。メッセージングプロトコルのための送信機の実施は、物理相互接続を介して送信する前にこれらのパラメーターをペイロードに付加してもよい。同様に、受信機実施がメッセージを受信すると、受信機はペイロードからフィールドを取り去り、ペイロードを指定された制御ポイントまたはサービスエンティティに送ってもよい。一般に、複数の制御ポイントは、上述した多重化スキームを用いて単一のサービスエンティティとインターフェースしてもよい。DCD上の共通リソースを共有する複数の制御ポイントの中の可能な衝突を解決するために、サービスエンティティはサービス共有状態変数を維持してもよい。サービスエンティティはポーリング例えば、要求メッセージおよび応答メッセージ、および/またはイベントベース表示メッセージを介して状態変数に制御ポイント情報を供給してもよい。代わりの実施形態において、サービスエンティティは各クライアントに割り当てるために、例えばサービスの質QoSフローを維持するために複数のリソースを割り当てることができる。この場合、各制御ポイントは各制御ポイントに対して別個のサービス状態変数を維持してもよい。メッセージングプロトコルの他の観点は、制御ポイントとサービスエンティティとの間のサービスメッセージフォーマットバージョンにおける差を処理することを提供する。実際の装置動作間において、制御ポイントによりサポートされるサービスメッセージが、サービスエンティティによりサポートされるサービスメッセージと異なるすなわち、早いまたは遅いバージョンである場合が起こる。特に、特定のメッセージフォーマットが以前のメッセージフォーマットと互換性が無くなるようにサービスが変化されると、主要なサービスバージョン差を生じる。主要なバージョンをインクリメントさせるであろう変化は、これに限定されないが、既存のメッセージの意味を変化させること、定義されたメッセージのリストからメッセージを完全に除去すること、メッセージIDに関連する必須パラメーターを除去すること、メッセージIDに関連する任意のパラメーターの意味を変化させること、任意の必須の意味論をメッセージフォーマットに追加することを含む。対照的に、同じ主要なバージョンの以前の仕様との下位互換性を破壊せずにサービス仕様が変化されるとき、比較的重要でないバージョンの差を生じる。これは、例えば、新しい特徴がサービスに追加されるとき生じてもよい。比較的重要でないバージョンをインクリメントするであろう変化は、これに限定されないが、新しいメッセージを追加すること、新しいオプションパラメーターを既存のメッセージに追加すること、新しいエラーコードを既存のメッセージに追加すること、既存の値の適用を変化させることなく既存のパラメーターに新しい値を追加することを含む。サービスエンティティがポール要求/応答メッセージングまたは表示メッセージングを介して、そのバージョンを示すとき、制御ポイントとサービスエンティティとの間のバージョン差を決定してもよい。異なるメッセージフォーマットバージョンを有する制御ポイントとサービスエンティティの相互運用を容易にするために、メッセージングプロトコルはそのようなバージョン差を処理する方法を指定してもよい。一実施形態によれば、制御ポイントは、異なる主要なバージョン番号を利用したサービスエンティティと相互運用しないであろう、逆もまた同様である。しかしながら、制御ポイントは、同じ主要なバージョンを利用するが異なる比較的重要でないバージョンを利用するサービスエンティティと相互運用してもよい。そのような相互運用は以下のように達成してもよい。制御ポイントの比較的重要でないバージョンがサービスエンティティの比較的重要でないバージョンより大きいすなわち、新しい場合には、制御ポイントとサービスエンティティは、ある動作ルールを守る。最初に、制御ポイントはサービスのより古い比較的重要でないバージョンを検出し、互換性のあるメッセージおよび/またはパラメーターのみを発行してもよい。サービスエンティティにおいてサポートされていない機能性をトリガーしてもよいより新しい制御メッセージはディスエーブルにしてもよい。例えば、一実施形態において、クライアントにおけるサポートされていないグラフィカルユーザーインターフェースボタンはディスエーブルにしてもよい。第2に、制御ポイントは、サービスの比較的重要でないバージョンを無視してもよく、より新しい要求を盲目的に発行してもよい。次に、サービスエンティティは、認識されていない要求を拒絶し、認識されていないパラメーターを無視するであろう。しかしながら、サービスエンティティがメッセージを認識し、すべての含まれるパラメーターが有効なら、サービスエンティティは要求を実行してもよい。第3に、応答するオプションパラメーターの欠落またはサービスエンティティからの表示メッセージが制御ポイントの適切な動作を中断しないように制御ポイントを構成することができる。また、第4に、サービスからの新しい表示メッセージの欠落が制御ポイントの適切な動作を中断しないように、制御ポイントを構成することができる。制御ポイントの比較的重要でないバージョンがサービスエンティティの比較的重要でないバージョンより少ないすなわち、より古い場合には、制御ポイントとサービスエンティティは、ある他の手続に従って動作することができる。より古い要求を発行する制御ポイントに応答して、サービスエンティティは、より古いパラメーターおよびより新しいパラメーターの両方に応答してもよい。この場合、制御ポイントは単により新しい認識されないパラメーターを無視してもよく、より古いサービスバージョンの下でするであろうより古いパラメーターを処理してもよい。また、制御ポイントは、より高いサービスバージョンである任意の表示メッセージを無視してもよい。上述した動作ルールは、例えば、単に、サポートされていないメッセージバージョンに対応する認識できないパラメーターまたはフィールドを処理することにより、物理相互接続により導入される破損により、受信されたメッセージが認識できないオプションパラメーターまたはフィールドを含むときはいつでも適用してもよいことに留意する必要がある。一実施形態において、異なる比較的重要でないサービスバージョンを利用する装置がそれにもかかわらず運用可能であることを保証するために、サービス仕様を定義する際に以下のルールを守ってもよい。第1に、サービスバージョンが指定された後は、必須のパラメーターは追加されたりまたは除去されたりしない。第2にオリジナル値が異なる方法で表されるように、または異なる意味を呈するように、オプションパラメーターは変化されない。一実施形態において、メッセージングプロトコルに対して定義されたサービスメッセージは、DCDによりサポートされた複数の技術にわたって共通のコマンドセットを提供してもよい。例えば、すべてのサポートされた技術に対してDCDからの信号強度ステータスを同時に検索するために、getsignalstrengthコマンドを発行してもよい。このように、アプリケーションは技術特有のコマンドを発行する必要はなく、アプリケーションソフトウエアの実施を緩和する。共通コマンドセットに加えて、定義されたサービスメッセージはまたさらなる技術特有のコマンド、例えば各データセッションに対して技術特有のプロファイルの構成を可能にするコマンドを含んでいてもよい。一実施形態において、DCDは、記憶された技術特有のプロファイルのセットを使用してもよいし、または二者択一的に共通コマンドメッセージのみを採用する装置デフォルトプロファイルを使用してもよい。アプリケーションまたはDCDはどのプロファイルを使用するかを決めてもよい。一実施形態において、メッセージングプロトコルに対して定義されたサービスメッセージは、ATコマンドプロトコルのような他のプロトコルに従って指定されたコマンドとともに使用されてもよい。これは、全体のMUXメッセージは、ATコマンドプロトコルのような他のプロトコルに従って定義されフォーマットされることを示すために、MUX層を介して送信されたメッセージのインターフェースタイプフィールドの値を設定することにより達成してもよい。代わりの実施形態において、MUXフォーマットは保存されてもよいが、サービスタイプフィールドは、対応するペイロードは他のプロトコルに従って定義されたメッセージを運ぶことを示す値に設定されてもよい。これは標準化団体により定義された良く知られたプロトコルであってもよいし、またはあらかじめ定義された独自仕様のプロトコルであってもよい。以下、サービスインターフェースメッセージおよびMUX層メッセージに対して使用されてもよいメッセージフォーマットの実施形態について記載する。この開示において記載したメッセージングプロトコルは本明細書に記載された特定のMUXフォーマットを採用する必要は無く、種々の並べ替え、削除、追加、及び/又は開示されたMUXフォーマット内のフィールドの代替ビット長はまた、意図されたメッセージングアーキテクチャおよびプロトコルの範囲内に入る。図3は図1に示されるサービスインターフェース107、108、109を介して交換されたメッセージのようなサービスメッセージnのための好適メッセージフォーマットを示す。図3において、バイトで表されたフィールドの長さは、対応するフィールドの上の数字により示される。図示されたフィールド長は好適フィールド長に過ぎず、フィールド長は一般に特定のMUXメッセージフォーマット実施において任意の長さであり得る。好適実施形態において、MUXメッセージ内のすべてのビットは、リトルエンディアンフォーマット、すなわち、最下位ビットを最初に設定するフォーマットで送信してもよい。この明細書において、ビットナンバリングのためのしきたりは、ビット0が最下位ビットであるということである。各サービスメッセージはタイプレングス値TLV構造を持つことができる。TLV構造は、どのメッセージが送信されるかを識別するメッセージID301と、レングスフィールドのすぐ後に続く値フィールド303の長さを指定するレングスフィールド302とを備える。一般に、タイプフィールドはTLV構造においてどのパラメーターが指定されるかの弁別を可能にする。一実施形態において、タイプフィールドの意味は所定のサービスメッセージ内のすべてのTLVパラメーターにわたって一意的であるが、サービスエンティティ内のすべてのメッセージにわたって、またはすべてのサービスエンティティにわたって一意的である必要はない。一実施形態において、値フィールドは別段の定めが無い限り、正のバイナリ値を含む。このように、バイナリデータは、このメッセージフォーマットにより本来的にサポートすることができる。特別のサービスメッセージに依存して、値フィールド303自身はさらに多数のTLVパラメーター319および320を備えていてもよく、各々は関連するタイプ、レングス、および値を有することに留意する必要がある。値フィールドの内容はさらにより多くのTLVパラメーター等を備えていてもよい。図3に図解される第1のTLVパラメーター319は、さらなるレングスサブフィールド315、317を有する値フィールドを示し、第1のTLV319の値フィールド306内の可変長パラメーターをサポートする。値サブフィールド314はメッセージ定義において与えられた固定長値なら、関連する長さを必要としなくてもよいことに留意する必要がある。従って、複数のパラメーターが単一のサービスメッセージ内に含まれていてもよく、タイプ、レングス、および値は各パラメーターに対して明示的に指定されてもよい。TLVフォーマットは、特定のサービスメッセージの定義がほかのものを指定していない限り、一般にサービスメッセージ内のパラメーターの任意の順序付けを容易にする。この場合、パラメーターが現れる順番はそのタイプを示してもよい。各パラメーターは必須であってもよいし、オプションであってもよい。必須パラメーターは特定のメッセージIDのメッセージ内に常に存在するパラメーターであり、一方オプションパラメーターは、特定のメッセージIDのメッセージ内に存在していてもよいし存在していなくてもよいパラメーターである。一実施形態において、サービスメッセージ内のオプションパラメーターの欠落はエラーを生じないしまたは制御ポイントまたはサービスエンティティの適切な動作を中断しない。サービスエンティティはメッセージを処理してもよいし、すべての必須のパラメーターが有効である限り、すべての示された行動を実行してもよい。一実施形態において、サービスメッセージ内のすべての必須のパラメーターはすべてのオプションパラメーターの前に配置される。一実施形態において、オプションTLVの提供はサービスメッセージの選択的暗号化をサポートする能力を可能にする。例えば、CTLサービスは、イニシャライゼーションの期間に暗号鍵パラメーターをネゴシエートすることができる。一方、暗号化される特定のサービスメッセージは、暗号化されたサービスメッセージの存在を示すオプションTLVを含むことができる。定義によりオプションTLVは、サービスメッセージ毎に供給される必要はないので、これはメッセージ毎に選択的暗号化を可能にする。サービスメッセージは、メッセージの送信者を認証するためにオプションTLVをメッセージに付加することにより、類似の機構を用いて選択的に認証することができる。また、選択的インテグリティ保護は、オプションTLVをメッセージに付加し、例えば、ハッシュ関数を適用する結果をメッセージのビットに付加することによりメッセージが改ざんされていないことを検証することにより実施することができる。特定のサービスメッセージで運ばれた任意の情報は、任意の数のTLVパラメーターの間で分割されてもよいことに留意する必要がある。一実施形態において、データ構造のすべての論理的に結合されたデータエレメントに対して単一のTLVが使用される。一実施形態において、サービスメッセージ内の各TLVのためのタイプフィールドは1バイトの長さである。タイプフィールドの最初の16の値すなわち、0x00乃至0x0fは、同じサービスタイプのすべてのメッセージにわたって共通である予約された意味を有していてもよい。各メッセージに対するオプションTLVおよびさらなるTLVは0x0fより大きなタイプフィールド値で始まってもよい。例えば、対応する値フィールドが必須パラメーターのセットを持っていることを示すためにすべての要求メッセージにおいてタイプ0x01が使用されてもよい。図3において、第1のTLVパラメーター319のタイプフィールド304は、0x01に設定されてもよく、対応する値フィールド306はさらに一連のパラメーターを備えていてもよい。それは各々値フィールド314、316、318およびレングスフィールド315、317により指定されてもよい。メッセージに対して定義された必須のパラメーターが無いなら、それは必須のTLVを省略してもよい。メッセージIDに対して定義されるならオプションパラメーターは、必須のTLVに続いてもよい。一実施形態において、応答タイプメッセージは各々、0x02に設定されたタイプフィールドを有した結果コードTLVとして知られる必須の第1のTLVを含んでいてもよい。受信された各要求に対して、サービスエンティティは、成功または失敗を示す値フィールドを有した結果コードTLVを戻してもよい。失敗が戻されるなら、エラーステータス値が戻されてもよく、次にメッセージは任意の次の必須のTLVパラメーターを省略してもよい。そのメッセージIDに対して定義されるなら応答メッセージに対する他の必須のフィールドは、結果コードTLVに続いて0x01に設定されたタイプを有する必須のTLV内に含まれてもよい。そうでなければ、応答メッセージは、必須のTLVを省略してもよい。オプションパラメーターは個々のTLVとして必須のTLVに続いてもよい。一実施形態において、表示タイプメッセージが必須のパラメーターを有するなら、これらのパラメーターは必須TLVの一部として第1のTLVの値フィールド内に含まれる。タイプフィールドは0x01に設定される。必須パラメーターが無いなら、表示メッセージは必須のTLVを省略してもよい。任意のオプションパラメーターは個々のTLVとして必須のTLVに続いてもよい。図4は図1に記載された階層化メッセージングアーキテクチャにおいて使用されてもよいペイロードフォーマットの一実施形態を示す。一実施形態において、いくつかのサービスメッセージ404、405、406は、図4に示すように単一のペイロードに一緒に束ねられてもよい。ペイロード401は一連のサービスメッセージ404、405、406の後に続いて、コントロールフラッグ402、トランザクションID403のようなフィールドを備えていてもよい。コントロールフラッグフィールド402およびトランザクションIDフィールド403は集合的に汎用サービスメッセージヘッダー407と呼んでもよい。一般に、ペイロードは任意の数のサービスメッセージをサポートするように構成されてもよいことに留意する必要がある。制御フラッグフィールド402は、ペイロードメッセージ内に含まれるサービスメッセージに関連するメッセージタイプ、例えば、要求、応答、または表示を指定してもよい。トランザクションIDフィールド403は、送信されたメッセージをインデックスするために、および/または応答メッセージを所定のクライアントIDのための対応する要求メッセージと関連づけるために使用することができる数値の識別子である。以下、図1のMUX層105、116のために採用することができる特定のMUXメッセージフォーマットについて記載する。ペイロードは図5に示すように制御チャネルメッセージ内に埋め込まれていてもよい。制御チャネルメッセージ501はMUXMSG502およびインターフェースタイプフィールド504を備えていてもよい。制御チャネルメッセージ501は、どのタイプのMUXフォーマットが使用されているかまたはMUXフォーマットが全く使用されないかどうかを指定するインターフェースタイプフィールド504を有していてもよい。インターフェースタイプフィールドは0x01の16進値に設定されてもよく、以下のメッセージは、本明細書に記載された好適MUXフォーマットに従ってフォーマットされることを示してもよい。それは代替フォーマットの使用を示すために別の値に設定されてもよい。このように、他の制御プロトコルとの相互運用を達成することができる。例えば、ATコマンドは、インターフェースタイプフィールド504に異なる値を指定することにより制御チャネルメッセージ501にカプセル化してもよい。MUXメッセージ502自体は、レングス505、制御フラッグ506、サービスタイプ507、クライアントID508、およびペイロード509のようなフィールドを備えていてもよい。レングス505、制御フラッグ506、サービスタイプ507、およびクライアントID508の各フィールドは、集合的にMUXヘッダーフィールド503と呼ばれてもよい。一実施形態において、レングスフィールド505は、バイトでMUXメッセージの全長を指定してもよい。他の実施形態において、レングスフィールド505は、ペイロードフィールド509のみの長さを指定してもよい。制御フラッグフィールド506は関心のある種々の制御パラメーターを指定してもよい。好適実施形態において、制御フラッグフィールド506のビット7は、メッセージの送信者がサービス1に設定されたビット7か、または制御ポイント0に設定されたビット7かを指定してもよい。制御フラッグフィールド506内の未使用ビットは、0に設定されてもよい。サービスタイプフィールド507はペイロードフィールド内に存在するメッセージのサービスエンティティタイプを指定してもよい。例えば、DCD上の装置マネージメントサービスエンティティへ通信されたまたは装置マネージメントサービスエンティティから通信されたメッセージは値0x01に設定されたサービスタイプフィールド507を有していてもよい。クライアントIDフィールド508は、メッセージが関連するアプリケーションクライアントを識別してもよい。好適実施形態において、このフィールドを0xffの値に設定することにより、表示メッセージは、サービスタイプフィールド507で指定されたサービスタイプを利用するすべての制御ポイントまたはクライアントに、サービスエンティティによりブロードキャストされてもよい。ペイロードフィールド509は、図1の制御ポイント101、102、103とサービスエンティティ114、115との間で交換される実際のサービスインターフェースメッセージ107、108、109を持っていてもよい。図7は、ブロック701において少なくとも1つのサービスメッセージを供給するステップと、ブロック701で発生された少なくとも1つのサービスメッセージを備えたブロック702において複数のメッセージを発生するステップと、少なくとも1つのサービスメッセージに関連する制御ポイントを識別するためのクライアントIDフィールド703と、少なくとも1つのサービスメッセージに関連するサービスエンティティを識別するためのサービスタイプフィールド704を備えた、この発明に従う複数の装置をインターフェースするための方法を示す。本明細書に記載された技術は、CDMAおよびUMTSファミリー技術、802.11、ブルートゥース、等のような種々の技術をサポートするデータ通信装置のために使用されてもよい。また、これらの技術は他の既存のおよび将来の無線ネットワーク技術に使用されてもよい。一般に、この技術は、単一無線ネットワーク技術をサポートする単一モード無線装置および複数の無線ネットワーク技術をサポートする複数モードの無線装置に対して使用されてもよい。本明細書に記載された技術は種々の手段により実施されてもよい。例えば、これらの技術は、ハードウエア、ソフトウエア、またはそれらの組み合わせ内で実施されてもよい。ハードウエア実施の場合、システム選択をサポートするために使用される処理ユニットは、1つ以上の特定用途向け集積回路ASICs、デジタルシグナルプロセッサーDSPs、デジタルシグナル処理装置DSPDs、プログラマブルロジックデバイスPLDs、フィールドプログラマブルゲートアレイFPGAs、プロセッサー、コントローラー、マイクロコントローラー、マイクロプロセッサー、本明細書に記載された機能を実行するように設計された他の電子ユニット、またはそれらの組み合わせ内で実施されてもよい。ソフトウエア実施の場合、システム選択技術は、本明細書に記載した機能を実行するモジュール例えば、手続、機能等で実施されてもよい。ソフトウエアコードはメモリユニットに記憶されプロセッサーにより実行されてもよい。メモリユニットはプロセッサー内部またはプロセッサー外部で実施されてもよい。プロセッサー外部で実施される場合、メモリユニットは、技術的に知られた種々の手段を介してプロセッサーに通信可能に接続することができる。開示された実施形態の上述の記載は、当業者がこの発明を製作または使用可能にするために提供される。これらの実施形態への種々の変更は当業者には容易に明白であり、本明細書で定義される包括的原理は、この発明の範囲から逸脱することなく他の実施形態に適用されてもよい。従って、この発明は、ここに示される実施形態に限定されることを意図したものではなく、ここに開示された原理および新規な特徴と一致する最も広い範囲が許容されるべきである。