JP4577683B2 - 異なるプロトコル間での相互データ伝送のための共通プロトコル階層構造とデータ伝送方法及び共通プロトコルパケット - Google Patents

Description

本特許出願は、異機種プロトコルとマルチメディアデータの統合処理方法及び装置の２００２年９月１８日出願した大韓民国出願特許第１０−２００２−００５６７２５号に係わるのである。

本発明は、異なるプロトコル間での相互データ伝送のための共通プロトコル構造に関し、より詳しくはＩＰ、ブルートゥース、ＩＥＥＥ１３９４及びＬｏｎＴａｌｋ等の多様なプロトコルを収容してこれら間の相互通信を可能にさせる共通プロトコル階層の構造及び共通プロトコルパケット構造に関する。

開放型システム相互接続（Ｏｐｅｎ Ｓｙｓｔｅｍ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ：ＯＳＩ）の参照モデルは、世界各国の異なるコンピュータや端末装置を相互接続してアプリケーションプログラム間の通信をスムーズに処理するための標準的な規則を提供している。

ＯＳＩ参照モデルを用いるネットワークにおいて、システム相互間のデータ流れはＯＳＩ環境を介して行われる。ＯＳＩでは７つの階層が存在し、前記７つの階層は大きく上位階層と下位階層に分けられる。上位階層は、使用者と網運用管理のためのプロトコルを行って使用者の中央処理装置の間で通信が可能にさせるアプリケーション階層（Ａｐｐｌｉｃａｔｉｏｎ Ｌａｙｅｒ）、アプリケーション階層の機能モジュールの間で通信する構造を持つ情報の表現形式を扱うプレゼンテーション階層（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｌａｙｅｒ）及びアプリケーション階層間の対話を制御するセッション階層（Ｓｅｓｓｉｏｎ Ｌａｙｅｒ）をいう。

下位階層は、上位階層が回線品質や通信の附加的なシステムの物理的な構成を意識しなくても両方の端末装置の間で正確な通信が成り立つようにする役目を遂行するトランスポート階層（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ）、トランスポート階層の通信機能にデータ伝送サービスを提供するネットワーク階層（Ｎｅｔｗｏｒｋ Ｌａｙｅｒ）、論理ネットワークで物理的リンクのネーム・バリューを高めてデータを正確でなだらかに送る役目をするデータリンク階層（Ｄａｔａ Ｌｉｎｋ Ｌａｙｅｒ）及び物理媒体間の物理的なインタフェースを定義し、データリンク階層からのデータ伝送要求によってビットを受信する物理階層（Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ）をいう。

開放型システムでシステムＡの使用者プログラムデータはＯＳＩ環境に入力されて、アプリケーション階層から順に物理階層方向へ移って伝送媒体に送り出しされる。この時、データはＨＤＬＣ（Ｈｉｇｈ ｌｅｖｅｌ Ｄａｔａ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）手順に使われるフレームを用いて伝送される。このフレームはＯＳＩで中継開放型システムと呼ばれるデータ交換網の中を経て、開放型システムから宛て先コンピュータに到着する。この中でデータは下位である物理階層から順番どおり各階層を経てアプリケーション階層まで到逹して、最後に開放型システムからシステムＢの目的地であるアプリケーションプロセスＢに移る。

システム相互間のデータ流れはシステムとシステム間、又は、システムと他のシステムに繋がれた端末機間で行われる。しかしながら、異なるプロトコルの２以上のコンピュータシステム間の通信の場合、相互の通信は制限される。このため、異なる通信ネットワーク間の効率的な通信を可能にするためにプロトコル変換器が必要になった。

従来技術の米国特許第５８５２６６０号明細書には、プロトコル変換器を使ったネットワークシステム内のネットワークプロトコル変換モジュールが提示されている。これは、例えばＯＳＩ階層の中でアプリケーション層データを含む遠隔通信ＳＳ７プロトコルを利用してネットワークの通信を互換可能にさせる方法に関するものである。

従来のプロトコル変換器は両方の中央処理装置（ＣＰＵ）の間で異なる二つのプロトコルがデータの交換を成すようにした。すなわち、相互ソフトウェア間の直接的なデータ交換または、単純な論理を用いた相互ハードウェア間のデータ交換が成り立つようにする。このようなプロトコル変換器は、中央処理装置が他の動作を遂行する期間に、遅延が発生し、一方の側の中央処理装置が信号を受けて応答をシステムの内部と取り交わす間、中央処理装置に負担がかかり、時間無駄使い要素が発生し、性能的な面で損失の多い問題点が発生する。
多様なプロトコル間の通信のための従来のアドレス変換方法はプロトコル変換過程と密接な関係がある。プロトコル変換方法によるアドレス変換方法は大きく３タイプに分類することができる。

一番目の方法は、１：１プロトコル変換方法である。７階層のＯＳＩ参照モデルに基づき、特定プロトコルの特定階層を他のプロトコルの対応する階層に変換する方法である。これは変換しなければならない階層の数がｍ個の場合、ｍ個の変換方法が必要で、また変換しようとするプロトコル個数がｎ個ならｎＣ２位の変換方法が必要なので、結果として、ｍ・ｎＣ２の変換方法が必要となる。したがって多様なプロトコル階層を持つ多様なプロトコルの間の相互データ交換のためには、多くの変換方法が必要であり、非常に複雑になるという短所があった。

二番目の方法は、特定プロトコルへの変換方法である。ｎ個のプロトコルの中で、特定のプロトコルを基準にしてプロトコル変換をする方法である。すなわちｎ個のプロトコルをこの中の一つの基準プロトコルに変換する方法は、（ｎ−１）個の変換方法が必要で、それぞれに対して各階層別に変換しなければならない場合の数がｍ個の場合、ｍ個の変換方法が必要なので、結果として、ｍ・（ｎ−１）個の変換方法が存在する。これは上の一番目の方法に比較すればプロトコル変換の際の複雑度の割合は減少するが、やはり多くのプロトコル変換をしなければならないという短所があった。

三番目の方法は、米国特許第５７１５２５０号明細書のように、オーバレイの方法を用いるアドレス変換方法である。これは、例えばＩＰ−ｏｖｅｒ−ＩＥＥＥ１３９４、ＩＰ−ｏｖｅｒ−ＡＴＭ等がこれに当たる。これは、ＩＰプロトコルがＩＥＥＥ１３９４またはＡＴＭ階層の上にある構造で、特別な変換は行われなく、異なるプロトコルの間のデータ交換方法ではない。

すなわち、ＩＰ−ｏｖｅｒ−ＩＥＥＥ１３９４の場合、ＩＥＥＥ１３９４ネットワーク内の装置が、ＩＰプロトコルのＩＥＥＥ１３９４データを送れば、ＩＰを介して再び受ける。ＩＰプロトコルを介して受信したデータは、ＩＥＥＥ１３９４階層を通るので、ＩＥＥＥ１３９４装置がデータを受けることが出来る。従って、これは、異なるネットワークプロトコル間のデータ交換でない。
しかしながら、前記のような従来のプロトコル変換方法は、変換方法の複雑性、異なるプロトコル間の階層構造の複雑性及びプロトコルの役目の複雑性、そして異なるネットワーク内の装置をアクセスする複雑性を内在している。すなわち、変換しようとするプロトコル間の階層数及びプロトコル数に比例する変換方法が必要であり、複雑度が増加する。ＯＳＩ ７階層を基準として、各プロトコルが持っているプロトコル階層構造及び各階層の役目がかなり異なるので、変換の際、複雑度は増加する。このような複雑なプロトコル変換をしてそれぞれ異なるネットワーク間に通信が成り立つと仮定する時、これら間に相互認識することができる共通的なアドレス体系がないという問題点があった。

本発明は前述した従来の問題点を解決するために案出されたものであり、多様なプロトコルを同時に収容することができる共通プロトコル階層構造と共通プロトコルパケット構造を設計して、一般的なプロトコル階層構造のアプリケーション階層の下位に共通プロトコル階層を挿入して、すべてのネットワーク内の装置に共通アドレスを付与して、共通プロトコルを利用して各ネットワーク内の装置の動作状態の可否がわかる技法を提供する点に本発明の目的がある。

本発明の前記目的は、
各階層が持っている特性で通信処理を階層別に分けることができるようにするＯＳＩ参照モデルのネットワークプロトコル階層構造において、
階層の最上段に位置するアプリケーション階層と；
前記アプリケーション階層の次に位置する、異なるプロトコル間のデータ通信を可能にさせる共通プロトコル階層と；
前記共通プロトコル階層の次に位置するプレゼンテーション階層と；
前記プレゼンテーション階層の次に位置するセッション階層と；
前記セッション階層の次に位置するトランスポート階層と；
前記トランスポート階層の次に位置するネットワーク階層と；
前記ネットワーク階層の次に位置するデータリンク階層と；
前記データリンク階層の次に位置する物理階層とによって逹成される。

本発明の他の目的は、
通信処理を各階層が持っている特性で階層別に分けることができるようにするＯＳＩ参照モデルのネットワークプロトコル階層を用いた相互データ伝送方法において、異なるプロトコル間の相互データ伝送のための共通プロトコル階層を介してデータが伝送される段階を含むことを特徴とする、異なるプロトコル間の相互データ伝送方法によって逹成される。

本発明のまた他の目的は、
異なるプロトコル間でデータを伝送するための共通プロトコルパケットにおいて、前記共通プロトコルパケットは、
パケットに関する情報を含む共通プロトコルヘッダーと、データの内容を持つペイロードとで構成されることを特徴とする、異なるプロトコル間の相互データ伝送のための共通プロトコルパケットによって逹成される。

したがって、本発明の異なるプロトコル間の相互データ伝送のための共通プロトコル階層構造および方法と共通プロトコルパケットは、アプリケーション階層または下位に共通階層を挿入することにより、ＯＳＩの７階層を基準として特定のプロトコルの特定階層を他のプロトコルのそれに相応する階層へ変換する方法のように、既存のプロトコル階層間の変換なしで一般なプロトコル階層構造のアプリケーション階層の下位に共通プロトコル階層を挿入することにより、前記共通プロトコルを用いてアプリケーションプログラムだけで相互通信が可能であり、共通プロトコルを使うすべてのネットワーク内の全装置に共通アドレスを付与ことによりこれら装置の管理および相互通信が可能であり、多様なプロトコルを用いる装置の動作状態がゲートウェイで分かるという長所があり、多様なプロトコルを同時に収容することが可能な共通プロトコル階層および共通プロトコルパケット構造の設計でプロトコル間の互換性が増加できるという効果がある。

本発明では、多様なプロトコルをすべて収容することができる共通プロトコル構造及び異なるプロトコル間の相互通信のためのプロトコル階層面での変換技法に対して説明する。

本発明の前記目的と技術的構成及びそれによる作用効果に関する詳しい事項は、本発明の望ましい実施例を示している図面を参照し、以下の詳細な説明によって明確に理解されるはずである。

先ず、図１は本発明による共通プロトコル階層の構造図である。共通プロトコル階層はアプリケーション階層１０の一部であることができるし、また既存のアプリケーション階層のすぐ下に設けることができる。

共通プロトコルを含むネットワークプロトコルは、ワールドワイドウェップコンソーシアムであるＷ３Ｃのネットワーク間の通信標準規約で指定したＯＳＩ標準規約に基づくすべてのネットワークプロトコルになることができる。そのようなプロトコルの例としては、インターネット、イントラネットまたはエックストラネットのような網で使われるＴＣＰ／ＩＰプロトコル、リナックスオペレーティングシステムでのネットワーク通信に使われるＩＥＥＥ１３９４プロトコル、使用者中心のシステムを具現するＬｏｎＴａｌｋプロトコル、無線ネットワークで使われるブルートゥースプロトコル等がある。

共通プロトコル階層を介してデータが伝送される段階を含むネットワークプロトコル階層を用いたデータ伝送方法は、二つのターミナルの利用者間で通信サービスを可能にさせるアプリケーション階層をデータが伝送される段階、パケットスイチング、ブロードキャストまたはマルチキャスト、アドレス変換、装置制御、パケット分類、保安、輻輳制御及び資源管理などを遂行する共通プロトコル階層を介してデータが伝送される段階、入力または出力されるデータを一つの表現形態から他の表現形態に変換するプレゼンテーション階層を介してデータが伝送される段階、ターミナルホストプログラム間でメッセージを取り交わすための設定をして、データを受ける同期を制御し、通信セッションを構成するセッション階層を介してデータが伝送される段階、ターミナル間で信頼性あるデータ伝送を保障するための制御とエラーを管理するトランスポート階層を介してデータが伝送される段階、パケットが正確な受信者に送られるようにデータ経路を制御するネットワーク階層を介してデータが伝送される段階、物理的レベルのエラー制御と同期を実行し、伝送確認と管理を担当するデータリンク階層を介してデータが伝送される段階、及び電気機械的に体系を取り揃えたネットワークを介してビット列を送信し、伝送媒体を介してデータをハードウェア手段に提供する物理階層を介してデータを送る段階を含んでいる。

このようなプロトコル階層を用いたデータ伝送方法の例としては、インターネット、イントラネットまたはエックストラネットのような網で使われるＴＣＰ／ＩＰプロトコルを介してデータを送る方法、リナックスオペレーティングシステムでのネットワーク通信に使われるＩＥＥＥ１３９４プロトコルを介してデータを送る方法、使用者中心のシステムを具現するＬｏｎＴａｌｋプロトコルを介してデータを送る方法、無線ネットワークで使われるブルートゥースプロトコルを介してデータを送る方法等がある。

図２は、本発明による共通プロトコルのアプリケーションを示す図である。ネットワークＡの装置の中で装置ＡＡが共通プロトコルを支援するチップセットを使って他のネットワークＢにある装置ＢＡにデータを伝逹しようとする場合の例である。この時チップセットで支援するプロトコル階層とホームステーションのプロトコル階層は図３のようである。

装置ＡＡのアプリケーション階層でのデータは共通プロトコル階層を通る。この際、アプリケーションデータの前にプリアンブル（ｐｒｅａｍｂｌｅ）と共通プロトコルヘッダーを付けて最終アプリケーションプロトコルデータ単位（ａｐｐｌｉｃａｔｉｏｎ ＰＤＵ、以下、ＡＰＵＤという）を作る。そして、プレゼンテーション（階層６）階層から物理階層を通る際、各プロトコル階層に対応するヘッダー（ｈｅａｄｅｒ）及びトレーラー（ｔｒａｉｌｅｒ）が、ＡＰＤＵに付加される。

このように完成されたパケットは、各プロトコルネットワーク上の伝送媒体を介して共通プロトコルを処理することができるチップセット外部のインタフェースモジュール装置ＡＺに到逹する。この装置では物理階層から階層６までのプロトコル階層を通りながら該当の階層のヘッダーとトレーラーを引き離して、モジュールＡＺのアプリケーション（ａｐｐｌｉｃａｔｉｏｎ）階層まで到逹するようになる。この時、装置ＡＺのアプリケーションでは、受信したアプリケーションプロトコルデータ単位パケットのプリアンブルを調査して、プリアンブルが共通プロトコルを使っていることを識別する。そして、もしプリアンブルが共通プロトコルを用いている場合、モジュールＡＺはパケットからプリアンブルを取り除き、共通プロトコルパケットのみ伝逹する。プリアンブルが共通プロトコルを用いていない場合、モジュールＡＺは受信したパケットが、自分の装置を目的地にして来たパケットであることを認識して自分のアプリケーション階層でデータ処理をする。

この後、共通プロトコルパケットを受信したチップセット内部では共通プロトコルヘッダー２１０内のアドレス情報によってスイチングを行い、共通プロトコルパケットを外部インタフェースモジュール装置ＢＺに送る。

装置ＢＺはこのパケットをアプリケーションデータとして認識し、共通プロトコル階層２０に送り、プリアンブルと共通プロトコルヘッダー２１０を付加する。この後、階層６から物理階層８０に送られ、伝送媒体を介して目的地である装置ＢＡに送られる。

装置ＢＺでは、伝送を受けたパケットは、物理階層８０から階層６までの処理手続きを経て共通プロトコル階層２０に到逹する。アプリケーション階層では受信したパケットのプリアンブルを調査してアプリケーションプロトコルデータ単位が他のネットワークから伝送され、共通プロトコル階層２０を経て来たパケットであることを認識する。

図３は、共通プロトコルをサポートするチップセット及びホームステーションのプロトコルの構造図である。共通プロトコル階層構造の共通プロトコル階層はパケットスイチング、ブロードキャストまたはマルチキャスト、アドレス変換、装置制御、パケット分類、保安、輻輳制御及び資源管理などを遂行する。

図４は、共通プロトコルを支援する装置のプロトコルの階層図である。ネットワーク内で共通プロトコルを支援する装置は、必ず共通プロトコル階層を使わなければならない。この時装置のプロトコル階層構造は下の図４のようである。ここで（１）の経路は、同じネットワークプロトコルを利用して同じプロトコルを使い、同じネットワーク内の装置と通信する場合１１０で、（２）の経路は、共通プロトコルを使って他のネットワーク内の装置と通信する場合１２０を現わした図面である。また、経路（３）では、共通プロトコルと既存のプロトコルの間の円滑な通信のため、共通プロトコル階層では既存プロトコルのアプリケーション階層との通信のために特定のＡＰＩをサポート１３０しなければならない。

図５は本発明による共通プロトコルパケットの構造図である。先ず、ＡＰＤＵ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）は、アプリケーション階層において、生成されたデータで、異なるネットワークの装置と通信する場合、共通プロトコル階層に伝送されるようになる。

共通プロトコルパケット２００は総３２バイトで構成され、１６バイトのプリアンブルと１６バイトの共通プロトコルヘッダー２１０とで構成される。ヘッダーは発地アドレス２２０、目的地アドレス２３０、オプションフィールド２４０、シーケンスフィールド２５０、長さフィールド２６０及び今後の使用のための予約フィールド２７０で構成される。

プリアンブルは１６バイトで構成されて、このフィールドの用途は大きく２種である。第１は、入力されたパケットが共通プロトコル階層を経て来たパケットなのかを知らせる為に用いられ、第２は、許可なく内部ネットワークへのアクセスを防ぐための認証キー又は認証パスワードを含むように用いられる。

発地アドレス２２０は送信側の共通アドレスを現わし、共通プロトコル階層２０及び共通プロトコル階層２０に対応するアプリケーション階層１０のみによって理解することができる。このアドレスは実際ネットワーク内のすべての装置の物理アドレス（ｐｈｙｓｉｃａｌ ａｄｄｒｅｓｓ）に１：１にマッピングされるアドレスで、このアドレスはこの共通プロトコルを受け入れるゲートウェーで一括的に管理されなければならない。この場合、装置の物理アドレスとこれに相応する共通アドレスとを同時に管理すべきである。

またアプリケーション階層１０及び使用者が、発地アドレスと内部ネットワーク構造とネットワークで用いられる装置とを識別することが出来るように設計されていれば管理的な側面でさまざまな長所がありえる。そうするために、共通プロトコル内でのアドレス体系に決まった規則がなければならない。目的地アドレス２３０は発地アドレス２２０と同じ構造で、受信側の共通アドレスを現わす。

図６はオプションフィールド２４０の構造の例示図である。オプションフィールド２４０は２バイトで構成され、現在パケットのトラフィックタイプ（Ｔｒａｆｆｉｃ Ｔｙｐｅ：ＴＴ）３１０、パケットタイプ（Ｐａｃｋｅｔ Ｔｙｐｅ：ＰＴ）３２０及び管理パケット（Ｍａｎａｇｅｍｅｎｔ Ｐａｃｋｅｔ：ＭＰ）３３０で構成される。

図７はオプションフィールド２４０の細部内容であるトラフィックタイプ３１０の例示図である。トラフィックタイプはパケットの緊急度の割合及びＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）のために制御命令データとリアルタイムデータ及び非リアルタイムデータに区分される。制御命令データは家内の装置を制御する時に使われるデータを意味し、リアルタイムデータはオーディオ、ビデオ及びゲーム等のエンターテイメント用のリアルタイム処理を要するデータを現わす為に使われる。非リアルタイムデータは、インターネットデータなど、他のデータを現わす時に使われる。

図８はドメインネットワークとクラスタネットワークの定義を現わした図面である。ホームネットワークは一つ以上のレジデンシャルゲートウェー（ＲＧ）またはホームゲートウェー（ＨＧ）で構成されることができる。この時一つのＲＧまたはＨＧで構成されるネットワークをドメインネットワークと定義する。そして、ＲＧまたはＨＧに繋がれるプロトコルネットワークをクラスタネットワークと定義する。

図９はオプションフィールド２４０の細部内容であるパケットタイプ３２０の例示図である。パケットタイプフィールドはパケットの伝送方法を定義するフィールドで、ユニキャスト（ｕｎｉｃａｓｔ）、ブロードキャスト（ｂｒｏａｄｃａｓｔ）及び多様なマルチキャスト（ｍｕｌｔｉｃａｓｔ）方法を提供する。前記の構造で、通信可能な方法は、基本的に１：１通信のためのユニキャストと、１：あらゆる装置間通信のためのブロードキャストと、１：多数の装置間通信のためのマルチキャスト方法を含む。マルチキャストの例としては、クラスタ内の装置間だけの通信のためのクラスタ−マルチキャスト、ドメイン内の装置間だけの通信のためのドメイン−マルチキャスト、ＲＧ間だけの通信のためのＲＧ−マルチキャストがありえる。

図１０と図１１はオプションフィールド２４０の細部内容である管理パケットタイプ３３０の例示図である。管理パケットフィールドは、共通プロトコルで提供するホームネットワーク管理のために特別に定義されたフィールドである。１バイトで構成されてそれぞれのフィールド値は図１０と図１１の内容のようである。

図１２は、シーケンスフィールド２５０の構造の例示図である。共通プロトコル階層は、アプリケーション階層とプレゼンテーション階層３０との間に存在するので、各プロトコル毎に上、下の階層とデータ交換をする時、各層は、それぞれの層でサポートする、異なるＭＴＵ（Ｍａｘｉｍｕｍ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ）を用いる。従って、共通プロトコルパケット中のペイロード部分は、セグメンテーションして送る必要がある。もちろん受信側ではこれらをまたリアッセンブルする必要がある。シーケンスフィールドは、セグメンテーション及びリアッセンブル処理において用いられ、セグメンテーションにおける一連番号を示すシーケンス番号フィールド４１０と最後のパケットを知らせるためのラストパケットフィールド４２０とで構成される。

また、長さフィールド（ｌｅｎｇｔｈ ｆｉｅｌｄ）２６０は、共通プロトコルヘッダー２１０の後のアプリケーションデータの大きさを現わす。

次に、管理パケットフィールド３３０の細部項目に対して説明する。管理パケットフィールドの値に従って、共通プロトコルパケットは、装置登録（Ｄｅｖｉｃｅ Ｒｅｇｉｓｔｒａｔｉｏｎ）パケット、ＲＧまたはホームステーション登録（Ｈｏｍｅ Ｓｔａｔｉｏｎ Ｒｅｇｉｓｔｒａｔｉｏｎ）パケット、アライブ−チェック（Ａｌｉｖｅ−Ｃｈｅｃｋ）パケット、状態報告パケット、ＶＯＤ又はブロードキャスト用ＭＰＥＧストリームパケット、ＷＡＮ又はストリームゲートウェー・インタフェースパケット、装置の追加、除去及び初期化に係わるパケットになる。

図１３は装置登録（Ｄｅｖｉｃｅ Ｒｅｇｉｓｔｒａｔｉｏｎ）パケットに対する例示図である。装置登録パケットには、装置登録を要請するＤＲＲＥＱ（Ｄｅｖｉｃｅ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｒｅｑｕｅｓｔ）、装置登録に応答するＤＲＲＥＳ（Ｄｅｖｉｃｅ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）パケットがあり、このパケットを使うことで、装置のプラグアンドプレイ機能（以下、ＰｎＰ機能という）を提供することができる。

図１４は、ＲＧまたはホームステーション登録パケットに対する例示図である。ＲＧまたはホームステーション登録パケットには、ホームステーション登録のスタートを要請するＨＲＳＲＥＱ（Ｈｏｍｅ Ｓｔａｔｉｏｎ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｓｔａｒｔ Ｒｅｑｕｅｓｔ）、ホームステーション登録のスタート要請に応答するＨＲＳＲＥＳ（Ｈｏｍｅ Ｓｔａｔｉｏｎ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｓｔａｒｔ Ｒｅｓｐｏｎｓｅ）、ホームステーション登録を要請するＨＲＲＥＱ（Ｈｏｍｅ Ｓｔａｔｉｏｎ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｒｅｑｕｅｓｔ）、ホームステーション登録要請に応答するＨＲＲＥＳ（Ｈｏｍｅ Ｓｔａｔｉｏｎ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｒｅｓｐｏｎｓｅ）及びホームステーション登録を表示するＨＲＩＮＤ（Ｈｏｍｅ Ｓｔａｔｉｏｎ Ｒｅｇｉｓｔｒａｔｉｏｎ Ｉｎｄｉｃａｔｉｏｎ）パケットがあり、このパケットを使うことでホームステーションのＰｎＰ機能を提供することができる。

図１５は、アライブ−チェックパケットを示す図である。アライブ−チェックパケットは、アライブ−チェックを要請するＡＣＲＥＱ（Ａｌｉｖｅ−Ｃｈｅｃｋ Ｒｅｑｕｅｓｔ）、アライブ−チェックリクエストに応答するＡＣＲＥＳ（Ａｌｉｖｅ−Ｃｈｅｃｋ Ｒｅｓｐｏｎｓｅ）パケットで構成されて、ホームネットワーク内の装置またはＲＧが動作している のかを確認するためのパケットである。ＡＣＲＥＱを送った後、３秒中にＡＣＲＥＳを受けることができなければ、該当の装置はホームネットワークからログアウトしたことで見做して、図１５のようにＤＤＥＶ（Ｄｅｌｅｔｅ Ｄｅｖｉｃｅ）パケットをホームネットワーク内のすべての装置にブロードキャスト（ｂｒｏａｄｃａｓｔ）する。

図１６は、アライブ−チェックパケット使用の例としてＡＣＲＥＱ、ＡＣＲＥＳパケットのタイム−ラインを示している。Ｃａｓｅ １は、装置又はホームステーションが、ＡＣＲＥＱパケットを送った後、３秒以内にＡＣＲＥＳ応答パケットを受けた場合である。したがってＡＣＲＥＱパケットを送った装置は、他の装置がまだホームネットワークにログオンしていることがわかる。

Ｃａｓｅ ２はＡＣＲＥＱパケットを送った後、３秒以内に応答がない場合の例である。この場合、ＡＣＲＥＱパケットを送った装置又はホームステーションは、他の装置又はホームステーションにＤＤＥＶ（ｄｅｌｅｔｅ ｄｅｖｉｃｅ）パケットをブロードキャストし、該当の装置がホームネットワークからログアウトしたことを知らせ、自分が管理するアドレステーブルから該当の装置又はホームステーションのアドレスを削除する。

図１７は状態報告（Ｒｅｐｏｒｔ−Ｓｔａｔｕｓ）パケットの例を示す図である。状態報告（Ｒｅｐｏｒｔ−Ｓｔａｔｕｓ）パケットは、状態報告を要請するＲＳＲＥＱ（Ｒｅｐｏｒｔ−Ｓｔａｔｕｓ Ｒｅｑｕｅｓｔ）、状態報告に応答するＲＳＲＥＳ（Ｒｅｐｏｒｔ−Ｓｔａｔｕｓ Ｒｅｓｐｏｎｓｅ）及び状態報告を初期化するＲＳＩＮＤ（Ｒｅｐｏｒｔ−Ｓｔａｔｕｓ Ｉｎｄｉｃａｔｉｏｎ）パケットで構成される。

図１８は状態報告パケットの使用例として、ＲＳＲＥＱを受けた装置が、要求した項目に対して自分の状態をチェックして、結果をＲＳＲＥＳで送る。状態報告要求項目及び要求項目に対するデータはＲＳＲＥＱパケットのペイロード部分に挿入される。ＲＳＩＮＤパケットは、装置自らが自分の緊急な状況などを自分のドメインネットワーク内のホームステーションに送るために用いられる。

図１９はＶＯＤ ＭＰＥＧストリームパケットの例である。ＶＯＤ ＭＰＥＧストリームパケットは、ＶＯＤ ＭＰＥＧストリームサービスを要請するＶＯＤＲＥＱ（ＶＯＤ Ｒｅｑｕｅｓｔ）、ＶＯＤ ＭＰＥＧストリームサービスの要請に応答するＶＯＤＲＥＳ（ＶＯＤ Ｒｅｓｐｏｎｓｅ）、及びＶＯＤＳＴＲ（ＶＯＤ Ｓｔｒｅａｍ）のパケットで構成される。
図２０は、ブロードキャスト用ＭＰＥＧストリームパケットの例である。ブロードキャスト用ＭＰＥＧストリームパケットは、ブロードキャスト用ＭＰＥＧストリームサービスを要請するＢＲＣＴＲＥＱ（Ｂｒｏａｄｃａｓｔｉｎｇ Ｒｅｑｕｅｓｔ）、ブロードキャスト用ＭＰＥＧストリームサービスの要請に応答するＢＲＣＴＲＥＳ（Ｂｒｏａｄｃａｓｔｉｎｇ Ｒｅｓｐｏｎｓｅ）、及びＢＲＣＴＳＴＲ（Ｂｒｏａｄｃａｓｔｉｎｇ Ｓｔｒｅａｍ）パケットで構成される。

ＶＯＤ及びブロードキャスト用ストリームサービスを希望する装置はＶＯＤＲＥＱ及びＢＲＣＴＲＥＱパケットをストリームゲートウェー・インタフェースに送る。この時ストリーム情報と必要な帯域幅を要求する。ストリームゲートウェー・インタフェースは要求した内容に対する結果と実際割り当てた帯域幅をＶＯＤＲＥＳ及びＢＲＣＴＲＥＳパケットで知らせる。実際のストリームは、ＶＯＤＳＴＲ及びＢＲＣＴＳＴＲパケットのペイロード内に１８８バイトのＭＰＥＧストリームで送られる。

図２１は ＷＡＮ又はストリームゲートウェー・インタフェースパケットの例である。ＷＡＮに接続し、ストリームサービスを希望する装置は該当のゲートウェー・インタフェースのアドレスが分かれば、相互通信ができる。したがってこれらゲートウェー・インタフェースアドレスの要求、要求に対する応答及びゲートウェー・インタフェースを持っているホームステーションが自動でアドレスを知らせてくれるための機能を遂行するパケットが必要である。図２１に示すように、ＷＡＮ又はストリームゲートウェー・インタフェースパケットは、ＷＡＮ ゲートウェー・インタフェースのアドレスを要請するＷＧＩＲＥＱ（ＷＡＮ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ Ｒｅｑｕｅｓｔ）、ＷＡＮ ゲートウェー・インタフェースのアドレス要請に応答するＷＧＩＲＥＳ（ＷＡＮ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ Ｒｅｓｐｏｎｓｅ）、ＷＡＮ ゲートウェー・インタフェースのアドレスを初期化するＷＧＩＩＮＤ（ＷＡＮ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ Ｉｎｄｉｃａｔｉｏｎ）、ストリームゲートウェー・インタフェースアドレスを要請するＳＧＩＲＥＱ（Ｓｔｒｅａｍ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ Ｒｅｑｕｅｓｔ）、ストリームゲートウェー・インタフェースアドレス要請に応答するＳＧＩＲＥＳ（Ｓｔｒｅａｍ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ Ｒｅｓｐｏｎｓｅ）及びストリームゲートウェー・インタフェースのアドレスを初期化するＳＧＩＩＮＤ（Ｓｔｒｅａｍ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ Ｉｎｄｉｃａｔｉｏｎ）パケットで構成される。アドレス要請に対して該当のゲートウェー・インタフェースを持っているホームステーションが、ペイロードに自分のアドレスを付けて応答パケットで送る。

図２２はアドレステーブル管理パケットの例である。図２２のようにＡＤＥＶ（Ａｄｄ Ｄｅｖｉｃｅ）、ＤＤＥＶ（Ｄｅｌｅｔｅ Ｄｅｖｉｃｅ）、ＩＤＥＶ（Ｉｎｉｔ Ｄｅｖｉｃｅ）パケットで構成される。装置がホームネットワークにログインするかログアウトする場合、当該装置に繋がれているホームステーションが、他の装置に新しい装置のログオンまたは既存装置のログアウトを知らせるためにＡＤＥＶ、ＤＤＥＶパケットをブロードキャストする。このパケットの伝逹を受けた他の装置は、自分が持っているアドレステーブルから該当の装置のアドレスを追加又は削除する。ＩＤＥＶパケットは、ホームステーションの装置が持っているアドレステーブルを初期化しようとする時に使われる。

図２３はＵＨＣＰ（Ｕｎｉｖｅｒｓａｌ Ｈｏｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）パケットの例である。家にある装置を制御するためのＵＨＣＰパケットは、共通プロトコルパケットのペイロードに積まれ、ペイロードに積まれた内容が装置制御パケットであることを示すために、管理パケットフィールドは、図１１のように０ｘＦＦにセッティングされる。ＵＨＣＰパケットの形式は、図２３のように４バイトのＵＨＣＰヘッダーとペイロードとで構成される。

ＵＨＣＰヘッダーフィールドは、メッセージタイプ（ＭＴ）、アクションタイプ （ＡＴ）、トランザクションＩＤ（ＴＩＤ）及び長さフィールド（ＬＥＮ）等で構成される。メッセージタイプ（ＭＴ）はメッセージタイプを現わす。メッセージタイプは実行（ｅｘｅｃｕｔｉｏｎ、０ｘ１）、照会（ｑｕｅｒｙ、０ｘ２）、報告（ｎｏｔｉｆｉｃａｔｉｏｎ、０ｘ３）の三タイプに分類される。アクションタイプ（ＡＴ）はメッセージの動作を詳細に示している。メッセージのタイプによってそれぞれ動作が定義される。トランザクションＩＤ（ＴＩＤ）は、多くの応答メッセージが到着した時、特定の要求メッセージに対する応答メッセージを区別するために使うＩＤである。長さフィールド（ＬＥＮ）はペイロードの長さをバイト数で現わす。ＵＨＣＰメッセージのタイプでは実行メッセージ、照会メッセージ、報告メッセージがある。

図２４は実行メッセージ（Ｅｘｅｃｕｔｉｏｎ Ｍｅｓｓａｇｅ）を有するＵＨＣＰパケットの例である。実行メッセージは、図２４のようにアクト、レジスタ、応答（Ｒｅｓｐｏｎｓｅ）三タイプのＡＴフィールドを持って、前記ＡＴフィールドを実行する時に使われるメッセージである。アクトは、装置をペイロード内にある命令を遂行するようにするメッセージで、レジスタは、装置の属性（ａｔｔｒｉｂｕｔｅ）をホームステーションに登録する時使われ、特性はペイロード内に存在する。また応答はアクト、レジスタパケットに対する応答のために使われる。

図２５は照会メッセージ（Ｑｕｅｒｙ Ｍｅｓｓａｇｅ）を有するＵＨＣＰパケットの例である。照会メッセージは、図２５のように、アクト、デバイスディレクトリ、属性ディレクトリ、応答の４種のＡＴフィールドを持って、前記ＡＴフィールド内容を照会する時に使われるメッセージである。アクトは装置の状態情報を要求する時に使われて、デバイスディレクトリは、ホームネットワークでの装置のディレクトリ情報を要求する時使われて、ペイロードには何も積まれない。また、属性ディレクトリは属性情報を要求する時使われて、ペイロードには何も積まれない。応答は、アクト、デバイスディレクトリ、属性ディレクトリ要請に対する応答のために使われる。

図２６は報告メッセージ（Ｎｏｔｉｆｉｃａｔｉｏｎ Ｍｅｓｓａｇｅ）を有するＵＨＣＰパケットの例である。報告メッセージは図２６のような構造を持って、ホームネットワーク内の装置が自分の特定イベントやアラームなどを知らせる時に使われる。ＡＴ、ＴＩＤの二つのフィールドは使われない。

本発明による共通プロトコル階層の構造図である。 本発明による共通プロトコルのアプリケーションの例示図である。 共通プロトコルをサポートするチップセット及びホームステーションのプロトコルの構造図である。 共通プロトコルをサポートする装置のプロトコルの階層図である。 本発明による共通プロトコルパケットの構造図である。 オプションフィールドの構造の例示図である。 オプションフィールドの細部内容の中でトラフィックタイプの例示図である。 ドメインネットワークとクラスタネットワークの定義図である。 オプションフィールドの細部内容の中でパケットタイプの例示図である。 オプションフィールドの細部内容の中で管理パケットタイプの例示図である。 オプションフィールドの細部内容の中で管理パケットタイプの例示図である。 シーケンスフィールドの構造の例示図である。 装置登録パケットの例示図である。 ホームステーション登録パケットの例示図である。 アライブ−チェックパケットの例示図である。 アライブ−チェックパケット使用の例示図である。 状態報告パケットの例示図である。 状態報告パケット使用の例示図である。 ＶＯＤ ＭＰＥＧストリームパケットの例示図である。 ブロードキャスト用ＭＰＥＧストリームパケットの例示図である。 ＷＡＮ又はストリームゲートウェー・インタフェースパケットの例示図である。 アドレステーブル管理パケットの例示図である。 ＵＨＣＰパケットの例示図である。 ＵＨＣＰ実行メッセージの構造図である。 ＵＨＣＰ照会メッセージの構造図である。 ＵＨＣＰ報告メッセージの構造図である。

符号の説明

１０ ：アプリケーション階層
２０ ：共通プロトコル階層
３０ ：プレゼンテーション階層
４０ ：セッション階層
５０ ：トランスポート階層
６０ ：ネットワーク階層
７０ ：データリンク階層
８０ ：物理階層
１１０ ：同じプロトコルを使う装置間の通信段階
１２０ ：他のプロトコルを使う装置間の通信段階
１３０ ：既存アプリケーションとの通信のためのＡＰＩ提供段階
２００ ：共通プロトコルパケット
２１０ ：共通プロトコルヘッダー
２２０ ：発地アドレス
２３０ ：目的地アドレス
２４０ ：オプションフィールド
２５０ ：シーケンスフィールド
２６０ ：長さフィールド
２７０ ：予約フィールド
２８０ ：ペイロード
３１０ ：トラフィックタイプフィールド
３２０ ：パケットタイプフィールド
３３０ ：パケット管理フィールド
４１０ ：一連番号フィールド
４２０ ：最後のパケットフィールド

Claims (20)

1. ＯＳＩ参照モデルのネットワークプロトコル階層構造において使用される共通プロトコル階層構造であって、前記共通プロトコル階層構造は、前記ＯＳＩ参照モデルのネットワークプロトコルのアプリケーション階層の直下層部に配置されており、且つ前記共通プロトコル階層構造は、共通プロトコルを含み、異なるプロトコル間でのデータ通信を可能にさせる機能を有するものであり、然も、受信したデータパケット内で、前記共通プロトコルが用いられているか否かの判断に応答して、前記データパケット内の発地アドレス、目的地アドレス、オプションフィールド、シーケンスフィールド、長さフィールド、及び予約されたフィールドを含む共通プロトコルヘッダーを処理するか否かが判断され、当該判断に基づいて、前記データパケットを処理するか、処理しないで、前記データパケットを前記アプリケーション階層に伝達する機能を有する事を特徴とする共通プロトコル階層構造。
2. 前記 ＯＳＩ参照モデルのネットワークプロトコルはＴＣＰ／ＩＰ、ＩＥＥＥ１３９４、ＬｏｎＴａｌｋ及びブルートゥースプロトコルの内の何れか一つである事を特徴とする請求項１に記載の異なるプロトコル間の相互データ伝送のための共通プロトコル階層構造。
3. 前記共通プロトコル階層は、ホームステーションチップ内部でサービス品質、保安及び通信管理の内部的なインタフェースを遂行することを特徴とする請求項１記載の異なるプロトコル間の相互データ伝送のための共通プロトコル階層構造。
4. 共通プロトコル階層を用いるネットワーク装置で使用される、ＯＳＩ参照モデルのネットワークプロトコルのアプリケーション階層の直下層に設けられた、異なるプロトコル間でのデータ通信を可能にする共通プロトコル階層で形成される、共通プロトコルパケットであって、前記共通プロトコルパケットは、パケットに関する情報を含む共通プロトコルヘッダーと、データの内容を持つペイロードとで構成されており、
   前記共通プロトコルヘッダーは、
   送信される信号の発地に対する情報を持つ発地アドレスと；
   前記送信される信号の目的地に対する情報を持つ目的地アドレスと；
   トラフィックの種類、パケットの伝送方法及びホームネットワーク管理に関連したオプションフィールドと；
   セグメンテーション処理及びリアッセンブル処理に使われるシーケンスフィールドと；
   アプリケーションデータの大きさを示す長さフィールドと；
   今後の使用のために予約された予約フィールドと；
   で構成されており、
   且つ、前記共通プロトコルパケットは、前記共通プロトコルパケットが、前記アプリケーション階層に伝達されるに際し、前記ネットワーク装置による、前記共通プロトコルパケットが前記共通プロトコル階層の前記共通プロトコルを用いているか否かの判断に基づいて、前記共通プロトコルヘッダーが処理されるか処理されないかが決定される様に構成されている事を特徴とする異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
5. 前記オプションフィールドは、
   制御命令データとリアルタイムデータ及び非リアルタイムデータを区分するトラフィックタイプフィールドと；
   パケットの伝送方法を定義するパケットタイプフィールドと；
   共通プロトコルで提供するホームネットワーク管理のための管理パケットフィールドと；
   で構成されることを特徴とする請求項４に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
6. 前記管理パケットフィールドは、
   装置のＰｎＰ機能を提供する装置登録パケットと；
   ホームステーションのＰｎＰ機能を提供するホームステーション登録パケットと；
   ホームネットワーク内の装置またはＲＧの動作の有無を確認するアライブ−チェックパケットと；
   状態報告の要請を受けた装置の状態をチェックして結果を送る状態報告パケットと；
   ＶＯＤストリームサービスを願う装置の要請に対する結果を応答するＶＯＤ ＭＰＥＧストリームパケットと；
   ブロードキャスト用ストリームサービスを願う装置の要請に対する結果を応答するブロードキャスト用ＭＰＥＧストリームパケットと；
   ホームステーションが装置のゲートウェー・インタフェースアドレスを自動で知らせてくれるＷＡＮ又はストリームゲートウェー・インタフェースアドレス要求パケットと；
   該当の装置と繋がれているホームステーションに新しい装置の追加、削除、初期化をするアドレステーブル管理パケットと；
   を含んで構成されることを特徴とする請求項５に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
7. 前記装置登録パケットは、
   装置登録の開始時に、当該装置によりホームステーションに送られる装置登録を要請するＤＲＲＥＱパケットと；
   前記ホームステーションが前記ＤＲＲＥＱパケットを受け取った後、前記装置登録の要請に応答して、前記ホームステーションから前記装置に送られるＤＲＲＥＳパケットと；
   を含んで構成されることを特徴とする請求項６に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
8. 前記ホームステーション登録パケットは、
   ホームステーション登録の開始を要請するＨＲＳＲＥＱパケットと；
   ホームステーション登録の開始要請に応答するＨＲＳＲＥＳパケットと；
   ホームステーション登録を要請するＨＲＲＥＱパケットと；
   ホームステーション登録要請に応答するＨＲＲＥＳパケットと；
   ホームステーション登録を表示するＨＲＩＮＤパケットと；
   を含んで構成されることを特徴とする請求項６に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
9. 前記アライブ−チェックパケットは、
   装置が動作中か確認要請をするＡＣＲＥＱパケットと；
   前記装置が、前記ホームネットワークにログオンしているかについて応答をするＡＣＲＥＳパケットとを含んで構成されることを特徴とする請求項６に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
10. 前記状態報告パケットは、
    状態報告の要求項目及び要求項目に対するデータを含むＲＳＲＥＱパケットと；
    要求項目に対する装置の状態をチェックした結果が含まれるＲＳＲＥＳパケットと；
    装置の緊急な状況をホームステーションに送るＲＳＩＮＤパケットと；
    を含んで構成されることを特徴とする請求項６に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
11. 前記ＶＯＤ ＭＰＥＧストリームパケットは、
    ＶＯＤ ＭＰＥＧストリームサービスを要請するＶＯＤＲＥＱパケットと；
    ＶＯＤ ＭＰＥＧストリームサービスの要請に応答するＶＯＤＲＥＳパケットと；
    ペイロード内にＭＰＥＧストリームを積んで送るＶＯＤＳＴＲパケットと；
    を含んで構成されることを特徴とする請求項１４に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
12. 前記ブロードキャスト用ＭＰＥＧストリームパケットは、
    ブロードキャスト用ＭＰＥＧストリームサービスを要請するＢＲＣＴＲＥＧパケットと；
    ブロードキャストＭＰＥＧストリームサービスの要請に応答するＢＲＣＴＲＥＳパケットと；
    ペイロード内にＭＰＥＧストリームを積んで送るＢＲＣＴＳＴＲパケットと；
    を含んで構成されることを特徴とする請求項６に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
13. 前記ＷＡＮ又はストリームゲートウェー・インタフェースアドレス要求パケットは、
    ＷＡＮ ゲートウェー・インタフェースのアドレスを要請するＷＧＩＲＥＱパケットと；
    ＷＡＮ ゲートウェー・インタフェースのアドレスの要請に応答するＷＧＩＲＥＳパケットと；
    ＷＡＮ ゲートウェー・インタフェースのアドレスを初期化するＷＧＩＩＮＤパケットと；
    ストリームゲートウェー・インタフェースアドレスを要請するＳＧＩＲＥＱパケットと；
    ストリームゲートウェー・インタフェースアドレスの要請に応答するＳＧＩＲＥＳパケットと；
    ストリームゲートウェー・インタフェースのアドレスを初期化するＳＧＩＩＮＤパケットと；
    を含んで構成されることを特徴とする請求項６に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
14. 前記アドレステーブル管理パケットは、
    ホームステーションに新しい装置のログオンを知らせるＡＤＥＶパケットと；
    ホームステーションに新しい装置のログアウトを知らせるＤＤＥＶパケットと；
    ホームステーションの装置が持っているアドレステーブルを初期化するＩＤＥＶのパケットと；
    を含んで構成されることを特徴とする請求項６に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
15. 前記ペイロードには、装置を制御するためのＵＨＣＰパケットを積むように構成したことを特徴とする請求項４に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
16. 前記ＵＨＣＰパケットのヘッダーフィールドは、
    メッセージタイプを現わすメッセージタイプフィールドと；
    メッセージ動作を詳細に示すアクションタイプフィールドと；
    同時に到着した複数のメッセージを区別するためのトランザクションＩＤフィールドと；
    前記ＵＨＣＰパケットのペイロードの長さを現わす長さフィールドと；
    を含んで構成されることを特徴とする請求項１５に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
17. 前記メッセージタイプは、
    前記アクションタイプフィールドを実行する時に使われる実行メッセージと；
    前記アクションタイプフィールドを照会する時に使われる照会メッセージと；
    ホームネットワーク内の装置のイベントやアラームを知らせる時に使われる報告メッセージと；
    を含むことを特徴とする請求項１６に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
18. 前記実行メッセージは、
    装置がペイロード内にある命令を遂行するようにするアクトと；
    装置の属性をホームステーションに登録する時に使うレジスタと；
    前記アクト、レジスタパケットに対する応答のために使う応答と；
    を含むことを特徴とする請求項１７に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
19. 前記照会メッセージは、
    装置の状態に関する情報を要求する時に使われるアクトと；
    装置のディレクトリ情報を要求する時に使われるデバイスディレクトリと；
    属性情報を要求する時に使われる属性ディレクトリと；
    アクト、デバイスディレクトリ、属性ディレクトリ要請に対する応答のために使われる応答と；
    を含むことを特徴とする請求項１７に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。
20. 前記シーケンスフィールドは、セグメンテーションになった一連番号フィールドと、最後のパケットであることを示す最後のパケットフィールドと、で構成されることを特徴とする請求項４に記載の異なるプロトコル間の相互データ伝送のための共通プロトコルパケット。

Images